SlideShare una empresa de Scribd logo
ANALOGÍAS PARA EL DESARROLLO DE TECNOLOGÍA DE
                          INFORMACIÓN1
                                  ALEJANDRO DOMÍNGUEZ TORRES
                            DIVISIÓN DE ESTUDIOS DE POSGRADO, UNITEC
                            JADOMING@MAIL.UNITEC.MX, WWW.UNITEC.MX

Introducción
Cada vez con mayor frecuencia aparecen noticias sobre el impulso que el desarrollo de tecnología
de información (TI) ha estado y está recibiendo por los diferentes niveles de gobierno (federal,
estatal y municipal) y por las empresas relacionadas con esta tecnología. Como consecuencia de
lo anterior, las instituciones de educación superior y las organizaciones públicas y privadas
relacionadas con la TI están preparando planes y programas de trabajo que permitan instrumentar
diferentes iniciativas que van desde la creación de fabricas de software hasta la de parques de TI.
Sin centrarse en la iniciativa que se desee fomentar, al final el propósito es desarrollar productos
y servicios relacionados con la TI; entendiéndose por TI la agrupación y conjunción de software,
hardware y telecomunicaciones.
Por lo general, los desarrolladores de TI son (o deben ser) personas con habilidades y
conocimientos propios del producto o servicio de TI a desarrollar. En particular deben conocer
los métodos de desarrollo apropiado, las técnicas para optimizar y sacar mayor provecho de esos
métodos, y contar con habilidades en el uso y explotación de herramientas para instrumentar el
desarrollo.
Sin embargo, no todos los desarrolladores cuentan con un manejo equilibrado y apropiado de
métodos, técnicas y herramientas. Por ejemplo, en el desarrollo de software, existen algunas
personas con una habilidad extraordinaria en el manejo y explotación de un lenguaje de
programación y el compilador correspondiente, pero con un conocimiento cercano a la nada de
los métodos y técnicas existentes para identificar todos los requerimientos del desarrollo y reducir
las posibilidades de fracaso. Lo más común en la vida diaria es que el desarrollo se base en la
técnica denominada como “codificar y corregir”, la cual no siempre arroja buenos resultados
(McConnell).
Así, el presente artículo tiene como objetivo principal hacer una reflexión sobre la importancia de
los métodos generales de desarrollo de TI, tomando como referencia eventos análogos y con los
que tenemos cierta familiaridad, y así poder identificar algunas de las problemáticas y
consecuencias de no seguir y aplicar de forma apropiada los métodos correspondientes.

El modelo general de desarrollo de TI
En la vida académica y de forma particular en las asignaturas correspondientes al desarrollo de TI
(como por ejemplo, Ingeniería de Software o Ingeniería de Sistemas) es común, y casi de carácter
obligatorio, mostrar la forma en la cual se lleva a cabo el desarrollo a través de una serie de fases

1
    Conferencia en UNITEC, enero de 2006.


                                                                                         Página 1 de 6
o etapas, como por ejemplo: identificación del problema, análisis del problema, diseño del
producto o servicio, instrumentación del producto o servicio y seguimiento del producto o
servicio.
La forma en que se suele mostrar la conexión entre cada una de las fases es, por lo general, lineal
y se le conoce como “modelo en cascada”. Sin embargo, el desarrollo en la vida real no siempre
sigue este modelo. En la literatura se han distinguido al menos 10 formas de combinar estas fases
de desarrollo, conocidas por lo general como “ciclos de desarrollo” (McConnell pp. 145-175).
Sin importar el ciclo de desarrollo que se siga, el éxito de este (o mejor dicho, la reducción de las
probabilidades de fracaso) depende de los niveles de especificación de cada fase. Esta
especificación consiste en la desagregación de cada fase en diferentes niveles procesos
específicos y a la vez complementarios. Lo recomendable es que cada fase se desagregue en
alrededor de 7 procesos generales, cada proceso general en alrededor de 7 procesos específicos, y
así sucesivamente hasta llegar a un nivel de profundidad de alrededor de 7 niveles. En este último
y séptimo nivel la desagregación del proceso original es tan puntual que ya se tienen tareas
concretas, las cuales se pueden asignar a responsables (con nombre y apellido) y recursos
directos.
La razón de desagregar en alrededor de 7 partes cada proceso y cada nivel, se debe a que por lo
general existe un límite (conocido en la literatura como “Límite de Miller”) en la capacidad del
intelecto humano para procesar información. En efecto, cuando se excede este número de partes,
los errores que se pueden cometer en el manejo de los procesos puede crecer forma desorbitada
(Miller).
¿Qué pasaría en caso de alguna de estas fases no se llevara a cabo cuando, por ejemplo, se visita
al médico por alguna enfermedad, o cuando se desea hacer una fiesta o irse de vacaciones?

Cuando las fases de desarrollo no se cumplen
Existen al menos dos formas principales para que no se cumplan del todo las fases de desarrollo.
La primera de ellas es que haya una falta de entendimiento y precisión en los procesos de cada
fase, y la segunda es que se omitan una o más fases.

Falta de entendimiento y precisión en las fases de desarrollo
La falta de entendimiento y precisión en cada fase ha sido tema de preocupación en el desarrollo
de TI desde tiempos remotos. Los textos y artículos de investigación relativos al tema hacen
fuerte énfasis en la importancia que tiene cada fase, y es por eso que han estado preocupados por
que en las aulas y en la práctica estas fases se enseñen y apliquen de forma correcta. A pesar de lo
anterior, no siempre los egresados de los programas académicos de TI aplican de forma apropiada
estas fases, por lo que en los textos se ha llegado a caricaturizar este fenómeno (ver Figura 1).




                                                                                         Página 2 de 6
Figura 1. Falta de entendimiento y precisión en las fases de desarrollo.

¿Qué pasaría si los procesos de cada fase no son precisados y entendidos en un consultorio
médico? Imaginemos que una persona sufre una caída de consideración en la cual se lesiona un
brazo. Esta lesión le provoca que la parte del miembro afectado sufra de fuertes dolores y se
inflame. En este momento la persona reconoce que tiene un problema (aunque no lo conozca con
precisión) y acude al médico. El médico procede ha hacer una auscultación (fase de
identificación del problema), la cual consiste en hacer una serie de preguntas a la persona,
examinar la zona afectada y, tal vez, tomar alguna radiografía. Los datos arrojados por esta
auscultación son analizados por el médico (fase de análisis del problema) con el fin de
determinar como proceder (fase de diseño de la solución). Sin embargo, dependiendo de la
precisión con que se haya llevado a cabo la auscultación, el médico puede llegar a diferentes
conclusiones; por ejemplo, si por alguna razón las radiografías no fueron tomadas de forma
correcta el médico puede concluir que lo más conveniente es llevar a cabo una operación
quirúrgica. Lo primero que la persona puede pensar es que su problema es grave y que
posiblemente tenga que hacer un gasto fuerte o que tal vez sería conveniente tener una segunda
opinión.
En este caso, el segundo médico lleva a cabo otra auscultación (fase de identificación del
problema) y observa que las radiografías anteriores no arrojan mucha información debido a que
no fueron tomadas de forma correcta, por lo que ordena otras nuevas en diferentes ángulos con el
fin de tener una visión más precisa de la zona afectada. Después de analizar los datos y las nuevas
radiografías (fase de análisis del problema) comunica al paciente la forma en que se llevará a
cabo el tratamiento (fase de diseño de la solución), el cual consistirá de dos partes: un
tratamiento para desinflamar el brazo y mitigar los dolores, seguido de otro para recuperar la
funcionalidad y estructura del brazo.
La situación anterior y algunas similares son frecuentes, no siempre se tiene una solución
satisfactoria. En efecto, existen casos extremos como el que le sucedió a un familiar del autor:
por una falta de información en las fases de identificación y análisis del problema se diseño un
tratamiento (diseño de la solución) que al momento de llevarlo a cabo (instrumentación del
producto o servicio) a su vez provocó la amputación de un miembro inferior, siendo esta última
una situación irreversible.

                                                                                            Página 3 de 6
Cambiando de tema a otro menos dramático, que pasaría si en la contratación de un paquete
vacacional a una playa no se hace énfasis en lo que incluye y lo que no incluye, seguramente se
originará una situación de descontento y muchas de las veces una erogación considerable y
adicional de dinero en el momento de la instrumentación del servicio. ¿Cuántas veces nos ha
pasado esto?
Finalmente, si se desea hacer una fiesta, las preguntas que surgen se refieren al tipo de fiesta a
realizar, el día en que se llevará a cabo, el número y tipo de personas a ser invitadas, el tipo de
bocadillos y bebida que se ofrecerá, el presupuesto disponible, etc. Estas preguntas corresponden
a las fases de identificación y análisis del problema. Una vez que se tienen respuestas (con
suficiente información o no) a estas preguntas, se distribuyen las tareas entre los organizadores y
hace la planeación general (fase de diseño del producto o servicio). Si por alguna razón faltó
control o información en el número de invitados, bebida o bocadillos; al momento de llevar a
cabo la fiesta (fase de instrumentación), con seguridad se presentarán situaciones incomodas
que pueden provocar que la fiesta finalice de forma no tan feliz.
Si los actores de estas situaciones son personas que reflexionan en cómo es que se dieron los
procesos intermedios y las consecuencias que arrojaron éstos, entonces en próximas ocasiones no
repetirán los mismos errores. Si embargo, esto siempre es así y los actores cometen los mismos
errores.
En el desarrollo de TI las cosas pueden ser más pronunciadas. Algunos desarrolladores
minimizan la importancia de las fases de desarrollo, piensan que dar seguimiento a estas fases es
una perdida de tiempo, y que con sus habilidades en el manejo de las herramientas es más que
suficiente. Esta forma de actuar casi siempre lleva a consecuencias fatales, como se muestra a
continuación.

Omisión de una o varias fases de desarrollo
Una forma bastante utilizada por los desarrolladores de TI es aquella que consiste en instrumentar
el producto o servicio y después corregirlo en caso de que se hayan cometido errores en la
instrumentación [McConnell, pp. 152-153]. Si no se ha seleccionado explícitamente el ciclo de
desarrollo del producto o servicio, por omisión los desarrolladores estarán utilizando el ciclo
“instrumentar y corregir”. Cuando se utiliza este ciclo, se inicia con una idea general de lo que se
necesita instrumentar con o sin una especificación formal del desarrollo a realizar. Durante la
instrumentación se utiliza cualquier combinación informal de diseño, orden en la realización de
las tareas, depuración y métodos de prueba no formales, los cuales se utilizan sin orden alguno
hasta que se tiene el producto o servicio listo para entregarlo
Para los desarrolladores de TI. El ciclo de instrumentar y corregir ofrece varias “ventajas”:
     Puede mostrar de forma inmediata indicios de progreso en la instrumentación.
     No conlleva ningún proceso de gestión.
     No se pierde tiempo en
       o Identificar de forma puntual el problema;
       o Documentar los procesos a realizar;
       o Gestionar el control de la calidad del producto o servicio;
       o Utilizar estándares;


                                                                                        Página 4 de 6
o Realizar cualquier otra actividad diferente a la de instrumentar el producto o servicio.
Estas “ventajas”, conforme se avanza en la instrumentación, por lo general llegan a convertirse en
desventajas, tales como:
     Resultan peligrosas para el desarrollo de productos o servicios relativamente pequeños (de
      nueva cuenta se invoca al “Límite de Miller”).
     Aunque no supongan gestión alguna, tampoco ofrece medios de evaluación del progreso.
     No proporcionan medios de evaluación de la calidad o de identificación de riesgos.
En conclusión, el ciclo de instrumentar y corregir conlleva un modelo no formal que se utiliza
porque es simple, pero no porque funcione bien.
¿Qué pasaría si un médico utiliza ciclo de desarrollo? ¿Se puede confiar en un médico que con
poca información y casi nulos identificación y análisis del problema ingresara a una persona
directamente al quirófano? La respuesta a esta pregunta es, desde cualquier punto de vista,
negativa.
Siendo menos trágicos, si se efectúa una fiesta conociendo vagamente el número de invitados, el
presupuesto disponible, los bocadillos que se ofrecerán, el día en la cual se llevará a cabo, etc.,
con seguridad, si se llega a efectuar la fiesta, ésta será un desastre.
En la vida diaria la aplicación del ciclo de desarrollo “instrumentar y corregir” lleva por lo
general a un fracaso rotundo. Entonces, ¿por qué es la forma más invocada y aplicada en el
desarrollo de TI?
Puede existir un gran número de “razones válidas” para utilizarla. Entre estas razones se
encuentra la que tal vez tiene mayor peso “el cliente me solicito un desarrollo hoy y quiere ver
avances para mañana a primera hora”. En esta situación ¿quién comete el error mas grave? ¿El
cliente que cree que la TI ha avanzado tanto que se pueden desarrollar productos o servicios de
un día para otro? o ¿el desarrollador que tiene un exceso de confianza en sus conocimientos y que
no es capaz de decir al cliente que es necesario cubrir las fases de desarrollo (siguiendo algún
ciclo) y que por lo tanto se requiere de mas tiempo para tal desarrollo?
Tal vez el desarrollador pensará que “el que paga, manda” y que esto implica satisfacer las
necesidades del cliente. Si esta “razón” fuera cierta en lo general, entonces ¿por qué un médico
no puede curar de inmediato una enfermedad que requiere un tratamiento largo?
Esta discusión podría continuar indefinidamente, pero mejor se dará por terminada y se pasará a
las conclusiones.

Conclusiones
Después de realizar y dirigir un sinnúmero de desarrollos de TI y de interactuar con un número
igual o superior de clientes y usuarios, he llegado a algunas conjeturas relacionadas con lo
discutido hasta el momento. Estas conjeturas de dividen en dos grupos: las relacionadas con el
cliente o usuario y aquellas que competen al desarrollador.
Las conjeturas relacionas con el cliente o usuario son:
     No siempre tiene idea de la magnitud y del desarrollo del producto servicio solicitado.


                                                                                       Página 5 de 6
   A veces piensa que los desarrollos tecnológicos surgen como por arte de magia.
     Cree que proveer únicamente con recursos al desarrollo es suficiente para que se obtenga el
      producto o servicio requerido.
     Cree que sus deseos deben ser ordenes para los desarrolladores.
     No alcanza a distinguir entre la ciencia-ficción y la ciencia verdadera.
Las conjeturas relacionadas con el desarrollador de TI son las siguientes, siendo algunas de ellas
consecuencia de las del cliente:
     No alcanza a distinguir entre armar un producto o servicio y desarrollarlo.
     Se tiene demasiada confianza, por lo que siempre piensa que tendrá momentos de
      inspiración que lo llevarán a la solución correcta (esta técnica se conoce como el “método
      de inspiración divina”).
     Piensa que las fases de desarrollo de TI lo único que generan es una perdida de tiempo.
     No siempre tiene idea de la magnitud del desarrollo de TI.
     Piensa que “el que paga, manda”.
Para finalizar, se harán dos observaciones. Primero, es importante tomar en consideración que
muchos de los procesos que se realizan en el desarrollo de TI son irreversibles, en el sentido que
existe a menos una variable involucrada en la ejecución de los procesos que no se puede
recuperar: Esta es el tiempo invertido en el proceso. Como segunda observación, es primordial
remarcar que el seguir un ciclo particular de desarrollo no asegura el éxito en el desarrollo
de TI, pero si asegura identificar y reducir el número de riesgos, así como la definición de
los correspondientes planes de contingencia.

Referencias
McConnell, Steve. Desarrollo y gestión de proyectos informáticos. Microsoft Press, McGraw-
Hill, España, 1996.
Miller, George. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity
for Processing Information. The Psychological Review, 1956, vol. 63, pp. 81-97.




                                                                                      Página 6 de 6

Más contenido relacionado

Destacado

Los hackers con ética
Los hackers con éticaLos hackers con ética
Requiero una oficina de proyectos
Requiero una oficina de proyectosRequiero una oficina de proyectos
Requiero una oficina de proyectos
Universidad Tecnológica de México - UNITEC
 
Regreso a los negocios
Regreso a los negociosRegreso a los negocios
La ingeniería social y la seguridad en it
La ingeniería social y la seguridad en itLa ingeniería social y la seguridad en it
La ingeniería social y la seguridad en it
Universidad Tecnológica de México - UNITEC
 
El riesgo de no considerar la gestión de riesgos
El riesgo de no considerar la gestión de riesgosEl riesgo de no considerar la gestión de riesgos
El riesgo de no considerar la gestión de riesgos
Universidad Tecnológica de México - UNITEC
 
Prepa UNITEC
Prepa UNITECPrepa UNITEC
Prepa UNITEC es
Prepa UNITEC esPrepa UNITEC es

Destacado (7)

Los hackers con ética
Los hackers con éticaLos hackers con ética
Los hackers con ética
 
Requiero una oficina de proyectos
Requiero una oficina de proyectosRequiero una oficina de proyectos
Requiero una oficina de proyectos
 
Regreso a los negocios
Regreso a los negociosRegreso a los negocios
Regreso a los negocios
 
La ingeniería social y la seguridad en it
La ingeniería social y la seguridad en itLa ingeniería social y la seguridad en it
La ingeniería social y la seguridad en it
 
El riesgo de no considerar la gestión de riesgos
El riesgo de no considerar la gestión de riesgosEl riesgo de no considerar la gestión de riesgos
El riesgo de no considerar la gestión de riesgos
 
Prepa UNITEC
Prepa UNITECPrepa UNITEC
Prepa UNITEC
 
Prepa UNITEC es
Prepa UNITEC esPrepa UNITEC es
Prepa UNITEC es
 

Similar a Analogías para el desarrollo de ti v1

Uso de los conocimientos técnicos y de las tic para la resolución de problema...
Uso de los conocimientos técnicos y de las tic para la resolución de problema...Uso de los conocimientos técnicos y de las tic para la resolución de problema...
Uso de los conocimientos técnicos y de las tic para la resolución de problema...
Jaime David Diaz
 
Trabajo requerimientos
Trabajo requerimientosTrabajo requerimientos
Trabajo requerimientos
edward2815
 
Trabajo requerimientos
Trabajo requerimientosTrabajo requerimientos
Trabajo requerimientos
edward2815
 
150400
150400150400
150400
Dana Patiño
 
Presentacion del marco logico
Presentacion del marco logicoPresentacion del marco logico
Presentacion del marco logico
JNHP30
 
HtasAdmi34p7
HtasAdmi34p7HtasAdmi34p7
HtasAdmi34p7
JonatanHernandez28
 
Guía de Diagnóstico
Guía de DiagnósticoGuía de Diagnóstico
Guía de Diagnóstico
Unipap Hotelería
 
Técnicas de identificación y resolución de problemas
Técnicas de identificación y resolución de problemasTécnicas de identificación y resolución de problemas
Técnicas de identificación y resolución de problemas
Fran Cedeño
 
Taller Tecnología 1 .pdf
Taller Tecnología 1 .pdfTaller Tecnología 1 .pdf
Taller Tecnología 1 .pdf
Valentinavivas11
 
Taller Tecnología .pdf
Taller Tecnología .pdfTaller Tecnología .pdf
Taller Tecnología .pdf
DanielaN29
 
Taller #1 Tecnología 2022.docx
Taller #1 Tecnología 2022.docxTaller #1 Tecnología 2022.docx
Taller #1 Tecnología 2022.docx
julianaquinteroherre
 
Taller Tecnología .docx
Taller Tecnología .docxTaller Tecnología .docx
Taller Tecnología .docx
DanielaN29
 
Gerencia De Proyectos En Sistemas De InformacióN
Gerencia De Proyectos En Sistemas De InformacióNGerencia De Proyectos En Sistemas De InformacióN
Gerencia De Proyectos En Sistemas De InformacióN
monikita02132
 
INVESTIGACION AREA SISTEMAS INFORMATICOS
INVESTIGACION AREA SISTEMAS INFORMATICOSINVESTIGACION AREA SISTEMAS INFORMATICOS
INVESTIGACION AREA SISTEMAS INFORMATICOS
JOHNNY SURI MAMANI
 
Alejandro13
Alejandro13Alejandro13
Alejandro13
nigthfox31
 
Proyecto tecnológico
Proyecto tecnológicoProyecto tecnológico
Proyecto tecnológico
Peter11-3
 
Analisis e interpretación de encuestas de clima
Analisis e interpretación de encuestas de climaAnalisis e interpretación de encuestas de clima
Analisis e interpretación de encuestas de clima
Universidad del Salvador | Buenos Aires
 
La metodología del proceso y el proyecto de investigación
La metodología del proceso y el proyecto de investigaciónLa metodología del proceso y el proyecto de investigación
La metodología del proceso y el proyecto de investigación
AnaGonzalez643
 
Ciclovida
CiclovidaCiclovida
Ciclovida
OLy Jimenez
 
Como elaborar un diagnosticdo
Como elaborar un diagnosticdoComo elaborar un diagnosticdo
Como elaborar un diagnosticdo
Héctor A. Lux Osorio
 

Similar a Analogías para el desarrollo de ti v1 (20)

Uso de los conocimientos técnicos y de las tic para la resolución de problema...
Uso de los conocimientos técnicos y de las tic para la resolución de problema...Uso de los conocimientos técnicos y de las tic para la resolución de problema...
Uso de los conocimientos técnicos y de las tic para la resolución de problema...
 
Trabajo requerimientos
Trabajo requerimientosTrabajo requerimientos
Trabajo requerimientos
 
Trabajo requerimientos
Trabajo requerimientosTrabajo requerimientos
Trabajo requerimientos
 
150400
150400150400
150400
 
Presentacion del marco logico
Presentacion del marco logicoPresentacion del marco logico
Presentacion del marco logico
 
HtasAdmi34p7
HtasAdmi34p7HtasAdmi34p7
HtasAdmi34p7
 
Guía de Diagnóstico
Guía de DiagnósticoGuía de Diagnóstico
Guía de Diagnóstico
 
Técnicas de identificación y resolución de problemas
Técnicas de identificación y resolución de problemasTécnicas de identificación y resolución de problemas
Técnicas de identificación y resolución de problemas
 
Taller Tecnología 1 .pdf
Taller Tecnología 1 .pdfTaller Tecnología 1 .pdf
Taller Tecnología 1 .pdf
 
Taller Tecnología .pdf
Taller Tecnología .pdfTaller Tecnología .pdf
Taller Tecnología .pdf
 
Taller #1 Tecnología 2022.docx
Taller #1 Tecnología 2022.docxTaller #1 Tecnología 2022.docx
Taller #1 Tecnología 2022.docx
 
Taller Tecnología .docx
Taller Tecnología .docxTaller Tecnología .docx
Taller Tecnología .docx
 
Gerencia De Proyectos En Sistemas De InformacióN
Gerencia De Proyectos En Sistemas De InformacióNGerencia De Proyectos En Sistemas De InformacióN
Gerencia De Proyectos En Sistemas De InformacióN
 
INVESTIGACION AREA SISTEMAS INFORMATICOS
INVESTIGACION AREA SISTEMAS INFORMATICOSINVESTIGACION AREA SISTEMAS INFORMATICOS
INVESTIGACION AREA SISTEMAS INFORMATICOS
 
Alejandro13
Alejandro13Alejandro13
Alejandro13
 
Proyecto tecnológico
Proyecto tecnológicoProyecto tecnológico
Proyecto tecnológico
 
Analisis e interpretación de encuestas de clima
Analisis e interpretación de encuestas de climaAnalisis e interpretación de encuestas de clima
Analisis e interpretación de encuestas de clima
 
La metodología del proceso y el proyecto de investigación
La metodología del proceso y el proyecto de investigaciónLa metodología del proceso y el proyecto de investigación
La metodología del proceso y el proyecto de investigación
 
Ciclovida
CiclovidaCiclovida
Ciclovida
 
Como elaborar un diagnosticdo
Como elaborar un diagnosticdoComo elaborar un diagnosticdo
Como elaborar un diagnosticdo
 

Más de Universidad Tecnológica de México - UNITEC

5 cosas que no sabías acerca de la cofia de una enfermera
5 cosas que no sabías acerca de la cofia de una enfermera5 cosas que no sabías acerca de la cofia de una enfermera
5 cosas que no sabías acerca de la cofia de una enfermera
Universidad Tecnológica de México - UNITEC
 
Ventajas de titularte por maestria
Ventajas de titularte por maestriaVentajas de titularte por maestria
Ventajas de titularte por maestria
Universidad Tecnológica de México - UNITEC
 
Infografía: Oportunidades en el Turismo de Reuniones UNITEC
Infografía: Oportunidades en el Turismo de Reuniones UNITECInfografía: Oportunidades en el Turismo de Reuniones UNITEC
Infografía: Oportunidades en el Turismo de Reuniones UNITEC
Universidad Tecnológica de México - UNITEC
 
Gastronomía UNITEC: El chef bajo la lupa
Gastronomía UNITEC: El chef bajo la lupaGastronomía UNITEC: El chef bajo la lupa
Gastronomía UNITEC: El chef bajo la lupa
Universidad Tecnológica de México - UNITEC
 
De Buen corazón, prevención cardíaca
De Buen corazón, prevención cardíacaDe Buen corazón, prevención cardíaca
De Buen corazón, prevención cardíaca
Universidad Tecnológica de México - UNITEC
 
Creando éxito en mi juventud (webinar)
Creando éxito en mi juventud (webinar)Creando éxito en mi juventud (webinar)
Creando éxito en mi juventud (webinar)
Universidad Tecnológica de México - UNITEC
 
Actitud, la clave para el éxito laboral (webinar)
Actitud, la clave para el éxito laboral (webinar)Actitud, la clave para el éxito laboral (webinar)
Actitud, la clave para el éxito laboral (webinar)
Universidad Tecnológica de México - UNITEC
 
Alimentación sin trucos (webinar)
Alimentación sin trucos (webinar)Alimentación sin trucos (webinar)
Alimentación sin trucos (webinar)
Universidad Tecnológica de México - UNITEC
 
Diseñando Arquitectura para México
Diseñando Arquitectura para MéxicoDiseñando Arquitectura para México
Diseñando Arquitectura para México
Universidad Tecnológica de México - UNITEC
 
Claves del Nuevo Sistema Penal
Claves del Nuevo Sistema PenalClaves del Nuevo Sistema Penal
Claves del Nuevo Sistema Penal
Universidad Tecnológica de México - UNITEC
 
UNITEC en un 2X3 Los pasos para tu inscripción (webinar)
UNITEC en un 2X3 Los pasos para tu inscripción (webinar)UNITEC en un 2X3 Los pasos para tu inscripción (webinar)
UNITEC en un 2X3 Los pasos para tu inscripción (webinar)
Universidad Tecnológica de México - UNITEC
 
Conoce el mundo de la Educación en Línea
Conoce el mundo de la Educación en LíneaConoce el mundo de la Educación en Línea
Conoce el mundo de la Educación en Línea
Universidad Tecnológica de México - UNITEC
 
Creando Multimedia
Creando MultimediaCreando Multimedia
Con vocación de Ingeniero (webinar)
Con vocación de Ingeniero (webinar)Con vocación de Ingeniero (webinar)
Con vocación de Ingeniero (webinar)
Universidad Tecnológica de México - UNITEC
 
Mi empleo, mi desarrollo (webinar)
Mi empleo, mi desarrollo (webinar)Mi empleo, mi desarrollo (webinar)
Mi empleo, mi desarrollo (webinar)
Universidad Tecnológica de México - UNITEC
 
Estudia con Financiamientos
Estudia con FinanciamientosEstudia con Financiamientos
Cuidando la salud de los mexicanos
Cuidando la salud de los mexicanosCuidando la salud de los mexicanos
Cuidando la salud de los mexicanos
Universidad Tecnológica de México - UNITEC
 
Trade Marketing y Administración de Ventas (webinar)
Trade Marketing y Administración de Ventas (webinar)Trade Marketing y Administración de Ventas (webinar)
Trade Marketing y Administración de Ventas (webinar)
Universidad Tecnológica de México - UNITEC
 
Tus estudios cuentan
Tus estudios cuentanTus estudios cuentan
La Realidad Virtual en Cine y Video
La Realidad Virtual en Cine y VideoLa Realidad Virtual en Cine y Video
La Realidad Virtual en Cine y Video
Universidad Tecnológica de México - UNITEC
 

Más de Universidad Tecnológica de México - UNITEC (20)

5 cosas que no sabías acerca de la cofia de una enfermera
5 cosas que no sabías acerca de la cofia de una enfermera5 cosas que no sabías acerca de la cofia de una enfermera
5 cosas que no sabías acerca de la cofia de una enfermera
 
Ventajas de titularte por maestria
Ventajas de titularte por maestriaVentajas de titularte por maestria
Ventajas de titularte por maestria
 
Infografía: Oportunidades en el Turismo de Reuniones UNITEC
Infografía: Oportunidades en el Turismo de Reuniones UNITECInfografía: Oportunidades en el Turismo de Reuniones UNITEC
Infografía: Oportunidades en el Turismo de Reuniones UNITEC
 
Gastronomía UNITEC: El chef bajo la lupa
Gastronomía UNITEC: El chef bajo la lupaGastronomía UNITEC: El chef bajo la lupa
Gastronomía UNITEC: El chef bajo la lupa
 
De Buen corazón, prevención cardíaca
De Buen corazón, prevención cardíacaDe Buen corazón, prevención cardíaca
De Buen corazón, prevención cardíaca
 
Creando éxito en mi juventud (webinar)
Creando éxito en mi juventud (webinar)Creando éxito en mi juventud (webinar)
Creando éxito en mi juventud (webinar)
 
Actitud, la clave para el éxito laboral (webinar)
Actitud, la clave para el éxito laboral (webinar)Actitud, la clave para el éxito laboral (webinar)
Actitud, la clave para el éxito laboral (webinar)
 
Alimentación sin trucos (webinar)
Alimentación sin trucos (webinar)Alimentación sin trucos (webinar)
Alimentación sin trucos (webinar)
 
Diseñando Arquitectura para México
Diseñando Arquitectura para MéxicoDiseñando Arquitectura para México
Diseñando Arquitectura para México
 
Claves del Nuevo Sistema Penal
Claves del Nuevo Sistema PenalClaves del Nuevo Sistema Penal
Claves del Nuevo Sistema Penal
 
UNITEC en un 2X3 Los pasos para tu inscripción (webinar)
UNITEC en un 2X3 Los pasos para tu inscripción (webinar)UNITEC en un 2X3 Los pasos para tu inscripción (webinar)
UNITEC en un 2X3 Los pasos para tu inscripción (webinar)
 
Conoce el mundo de la Educación en Línea
Conoce el mundo de la Educación en LíneaConoce el mundo de la Educación en Línea
Conoce el mundo de la Educación en Línea
 
Creando Multimedia
Creando MultimediaCreando Multimedia
Creando Multimedia
 
Con vocación de Ingeniero (webinar)
Con vocación de Ingeniero (webinar)Con vocación de Ingeniero (webinar)
Con vocación de Ingeniero (webinar)
 
Mi empleo, mi desarrollo (webinar)
Mi empleo, mi desarrollo (webinar)Mi empleo, mi desarrollo (webinar)
Mi empleo, mi desarrollo (webinar)
 
Estudia con Financiamientos
Estudia con FinanciamientosEstudia con Financiamientos
Estudia con Financiamientos
 
Cuidando la salud de los mexicanos
Cuidando la salud de los mexicanosCuidando la salud de los mexicanos
Cuidando la salud de los mexicanos
 
Trade Marketing y Administración de Ventas (webinar)
Trade Marketing y Administración de Ventas (webinar)Trade Marketing y Administración de Ventas (webinar)
Trade Marketing y Administración de Ventas (webinar)
 
Tus estudios cuentan
Tus estudios cuentanTus estudios cuentan
Tus estudios cuentan
 
La Realidad Virtual en Cine y Video
La Realidad Virtual en Cine y VideoLa Realidad Virtual en Cine y Video
La Realidad Virtual en Cine y Video
 

Analogías para el desarrollo de ti v1

  • 1. ANALOGÍAS PARA EL DESARROLLO DE TECNOLOGÍA DE INFORMACIÓN1 ALEJANDRO DOMÍNGUEZ TORRES DIVISIÓN DE ESTUDIOS DE POSGRADO, UNITEC JADOMING@MAIL.UNITEC.MX, WWW.UNITEC.MX Introducción Cada vez con mayor frecuencia aparecen noticias sobre el impulso que el desarrollo de tecnología de información (TI) ha estado y está recibiendo por los diferentes niveles de gobierno (federal, estatal y municipal) y por las empresas relacionadas con esta tecnología. Como consecuencia de lo anterior, las instituciones de educación superior y las organizaciones públicas y privadas relacionadas con la TI están preparando planes y programas de trabajo que permitan instrumentar diferentes iniciativas que van desde la creación de fabricas de software hasta la de parques de TI. Sin centrarse en la iniciativa que se desee fomentar, al final el propósito es desarrollar productos y servicios relacionados con la TI; entendiéndose por TI la agrupación y conjunción de software, hardware y telecomunicaciones. Por lo general, los desarrolladores de TI son (o deben ser) personas con habilidades y conocimientos propios del producto o servicio de TI a desarrollar. En particular deben conocer los métodos de desarrollo apropiado, las técnicas para optimizar y sacar mayor provecho de esos métodos, y contar con habilidades en el uso y explotación de herramientas para instrumentar el desarrollo. Sin embargo, no todos los desarrolladores cuentan con un manejo equilibrado y apropiado de métodos, técnicas y herramientas. Por ejemplo, en el desarrollo de software, existen algunas personas con una habilidad extraordinaria en el manejo y explotación de un lenguaje de programación y el compilador correspondiente, pero con un conocimiento cercano a la nada de los métodos y técnicas existentes para identificar todos los requerimientos del desarrollo y reducir las posibilidades de fracaso. Lo más común en la vida diaria es que el desarrollo se base en la técnica denominada como “codificar y corregir”, la cual no siempre arroja buenos resultados (McConnell). Así, el presente artículo tiene como objetivo principal hacer una reflexión sobre la importancia de los métodos generales de desarrollo de TI, tomando como referencia eventos análogos y con los que tenemos cierta familiaridad, y así poder identificar algunas de las problemáticas y consecuencias de no seguir y aplicar de forma apropiada los métodos correspondientes. El modelo general de desarrollo de TI En la vida académica y de forma particular en las asignaturas correspondientes al desarrollo de TI (como por ejemplo, Ingeniería de Software o Ingeniería de Sistemas) es común, y casi de carácter obligatorio, mostrar la forma en la cual se lleva a cabo el desarrollo a través de una serie de fases 1 Conferencia en UNITEC, enero de 2006. Página 1 de 6
  • 2. o etapas, como por ejemplo: identificación del problema, análisis del problema, diseño del producto o servicio, instrumentación del producto o servicio y seguimiento del producto o servicio. La forma en que se suele mostrar la conexión entre cada una de las fases es, por lo general, lineal y se le conoce como “modelo en cascada”. Sin embargo, el desarrollo en la vida real no siempre sigue este modelo. En la literatura se han distinguido al menos 10 formas de combinar estas fases de desarrollo, conocidas por lo general como “ciclos de desarrollo” (McConnell pp. 145-175). Sin importar el ciclo de desarrollo que se siga, el éxito de este (o mejor dicho, la reducción de las probabilidades de fracaso) depende de los niveles de especificación de cada fase. Esta especificación consiste en la desagregación de cada fase en diferentes niveles procesos específicos y a la vez complementarios. Lo recomendable es que cada fase se desagregue en alrededor de 7 procesos generales, cada proceso general en alrededor de 7 procesos específicos, y así sucesivamente hasta llegar a un nivel de profundidad de alrededor de 7 niveles. En este último y séptimo nivel la desagregación del proceso original es tan puntual que ya se tienen tareas concretas, las cuales se pueden asignar a responsables (con nombre y apellido) y recursos directos. La razón de desagregar en alrededor de 7 partes cada proceso y cada nivel, se debe a que por lo general existe un límite (conocido en la literatura como “Límite de Miller”) en la capacidad del intelecto humano para procesar información. En efecto, cuando se excede este número de partes, los errores que se pueden cometer en el manejo de los procesos puede crecer forma desorbitada (Miller). ¿Qué pasaría en caso de alguna de estas fases no se llevara a cabo cuando, por ejemplo, se visita al médico por alguna enfermedad, o cuando se desea hacer una fiesta o irse de vacaciones? Cuando las fases de desarrollo no se cumplen Existen al menos dos formas principales para que no se cumplan del todo las fases de desarrollo. La primera de ellas es que haya una falta de entendimiento y precisión en los procesos de cada fase, y la segunda es que se omitan una o más fases. Falta de entendimiento y precisión en las fases de desarrollo La falta de entendimiento y precisión en cada fase ha sido tema de preocupación en el desarrollo de TI desde tiempos remotos. Los textos y artículos de investigación relativos al tema hacen fuerte énfasis en la importancia que tiene cada fase, y es por eso que han estado preocupados por que en las aulas y en la práctica estas fases se enseñen y apliquen de forma correcta. A pesar de lo anterior, no siempre los egresados de los programas académicos de TI aplican de forma apropiada estas fases, por lo que en los textos se ha llegado a caricaturizar este fenómeno (ver Figura 1). Página 2 de 6
  • 3. Figura 1. Falta de entendimiento y precisión en las fases de desarrollo. ¿Qué pasaría si los procesos de cada fase no son precisados y entendidos en un consultorio médico? Imaginemos que una persona sufre una caída de consideración en la cual se lesiona un brazo. Esta lesión le provoca que la parte del miembro afectado sufra de fuertes dolores y se inflame. En este momento la persona reconoce que tiene un problema (aunque no lo conozca con precisión) y acude al médico. El médico procede ha hacer una auscultación (fase de identificación del problema), la cual consiste en hacer una serie de preguntas a la persona, examinar la zona afectada y, tal vez, tomar alguna radiografía. Los datos arrojados por esta auscultación son analizados por el médico (fase de análisis del problema) con el fin de determinar como proceder (fase de diseño de la solución). Sin embargo, dependiendo de la precisión con que se haya llevado a cabo la auscultación, el médico puede llegar a diferentes conclusiones; por ejemplo, si por alguna razón las radiografías no fueron tomadas de forma correcta el médico puede concluir que lo más conveniente es llevar a cabo una operación quirúrgica. Lo primero que la persona puede pensar es que su problema es grave y que posiblemente tenga que hacer un gasto fuerte o que tal vez sería conveniente tener una segunda opinión. En este caso, el segundo médico lleva a cabo otra auscultación (fase de identificación del problema) y observa que las radiografías anteriores no arrojan mucha información debido a que no fueron tomadas de forma correcta, por lo que ordena otras nuevas en diferentes ángulos con el fin de tener una visión más precisa de la zona afectada. Después de analizar los datos y las nuevas radiografías (fase de análisis del problema) comunica al paciente la forma en que se llevará a cabo el tratamiento (fase de diseño de la solución), el cual consistirá de dos partes: un tratamiento para desinflamar el brazo y mitigar los dolores, seguido de otro para recuperar la funcionalidad y estructura del brazo. La situación anterior y algunas similares son frecuentes, no siempre se tiene una solución satisfactoria. En efecto, existen casos extremos como el que le sucedió a un familiar del autor: por una falta de información en las fases de identificación y análisis del problema se diseño un tratamiento (diseño de la solución) que al momento de llevarlo a cabo (instrumentación del producto o servicio) a su vez provocó la amputación de un miembro inferior, siendo esta última una situación irreversible. Página 3 de 6
  • 4. Cambiando de tema a otro menos dramático, que pasaría si en la contratación de un paquete vacacional a una playa no se hace énfasis en lo que incluye y lo que no incluye, seguramente se originará una situación de descontento y muchas de las veces una erogación considerable y adicional de dinero en el momento de la instrumentación del servicio. ¿Cuántas veces nos ha pasado esto? Finalmente, si se desea hacer una fiesta, las preguntas que surgen se refieren al tipo de fiesta a realizar, el día en que se llevará a cabo, el número y tipo de personas a ser invitadas, el tipo de bocadillos y bebida que se ofrecerá, el presupuesto disponible, etc. Estas preguntas corresponden a las fases de identificación y análisis del problema. Una vez que se tienen respuestas (con suficiente información o no) a estas preguntas, se distribuyen las tareas entre los organizadores y hace la planeación general (fase de diseño del producto o servicio). Si por alguna razón faltó control o información en el número de invitados, bebida o bocadillos; al momento de llevar a cabo la fiesta (fase de instrumentación), con seguridad se presentarán situaciones incomodas que pueden provocar que la fiesta finalice de forma no tan feliz. Si los actores de estas situaciones son personas que reflexionan en cómo es que se dieron los procesos intermedios y las consecuencias que arrojaron éstos, entonces en próximas ocasiones no repetirán los mismos errores. Si embargo, esto siempre es así y los actores cometen los mismos errores. En el desarrollo de TI las cosas pueden ser más pronunciadas. Algunos desarrolladores minimizan la importancia de las fases de desarrollo, piensan que dar seguimiento a estas fases es una perdida de tiempo, y que con sus habilidades en el manejo de las herramientas es más que suficiente. Esta forma de actuar casi siempre lleva a consecuencias fatales, como se muestra a continuación. Omisión de una o varias fases de desarrollo Una forma bastante utilizada por los desarrolladores de TI es aquella que consiste en instrumentar el producto o servicio y después corregirlo en caso de que se hayan cometido errores en la instrumentación [McConnell, pp. 152-153]. Si no se ha seleccionado explícitamente el ciclo de desarrollo del producto o servicio, por omisión los desarrolladores estarán utilizando el ciclo “instrumentar y corregir”. Cuando se utiliza este ciclo, se inicia con una idea general de lo que se necesita instrumentar con o sin una especificación formal del desarrollo a realizar. Durante la instrumentación se utiliza cualquier combinación informal de diseño, orden en la realización de las tareas, depuración y métodos de prueba no formales, los cuales se utilizan sin orden alguno hasta que se tiene el producto o servicio listo para entregarlo Para los desarrolladores de TI. El ciclo de instrumentar y corregir ofrece varias “ventajas”:  Puede mostrar de forma inmediata indicios de progreso en la instrumentación.  No conlleva ningún proceso de gestión.  No se pierde tiempo en o Identificar de forma puntual el problema; o Documentar los procesos a realizar; o Gestionar el control de la calidad del producto o servicio; o Utilizar estándares; Página 4 de 6
  • 5. o Realizar cualquier otra actividad diferente a la de instrumentar el producto o servicio. Estas “ventajas”, conforme se avanza en la instrumentación, por lo general llegan a convertirse en desventajas, tales como:  Resultan peligrosas para el desarrollo de productos o servicios relativamente pequeños (de nueva cuenta se invoca al “Límite de Miller”).  Aunque no supongan gestión alguna, tampoco ofrece medios de evaluación del progreso.  No proporcionan medios de evaluación de la calidad o de identificación de riesgos. En conclusión, el ciclo de instrumentar y corregir conlleva un modelo no formal que se utiliza porque es simple, pero no porque funcione bien. ¿Qué pasaría si un médico utiliza ciclo de desarrollo? ¿Se puede confiar en un médico que con poca información y casi nulos identificación y análisis del problema ingresara a una persona directamente al quirófano? La respuesta a esta pregunta es, desde cualquier punto de vista, negativa. Siendo menos trágicos, si se efectúa una fiesta conociendo vagamente el número de invitados, el presupuesto disponible, los bocadillos que se ofrecerán, el día en la cual se llevará a cabo, etc., con seguridad, si se llega a efectuar la fiesta, ésta será un desastre. En la vida diaria la aplicación del ciclo de desarrollo “instrumentar y corregir” lleva por lo general a un fracaso rotundo. Entonces, ¿por qué es la forma más invocada y aplicada en el desarrollo de TI? Puede existir un gran número de “razones válidas” para utilizarla. Entre estas razones se encuentra la que tal vez tiene mayor peso “el cliente me solicito un desarrollo hoy y quiere ver avances para mañana a primera hora”. En esta situación ¿quién comete el error mas grave? ¿El cliente que cree que la TI ha avanzado tanto que se pueden desarrollar productos o servicios de un día para otro? o ¿el desarrollador que tiene un exceso de confianza en sus conocimientos y que no es capaz de decir al cliente que es necesario cubrir las fases de desarrollo (siguiendo algún ciclo) y que por lo tanto se requiere de mas tiempo para tal desarrollo? Tal vez el desarrollador pensará que “el que paga, manda” y que esto implica satisfacer las necesidades del cliente. Si esta “razón” fuera cierta en lo general, entonces ¿por qué un médico no puede curar de inmediato una enfermedad que requiere un tratamiento largo? Esta discusión podría continuar indefinidamente, pero mejor se dará por terminada y se pasará a las conclusiones. Conclusiones Después de realizar y dirigir un sinnúmero de desarrollos de TI y de interactuar con un número igual o superior de clientes y usuarios, he llegado a algunas conjeturas relacionadas con lo discutido hasta el momento. Estas conjeturas de dividen en dos grupos: las relacionadas con el cliente o usuario y aquellas que competen al desarrollador. Las conjeturas relacionas con el cliente o usuario son:  No siempre tiene idea de la magnitud y del desarrollo del producto servicio solicitado. Página 5 de 6
  • 6. A veces piensa que los desarrollos tecnológicos surgen como por arte de magia.  Cree que proveer únicamente con recursos al desarrollo es suficiente para que se obtenga el producto o servicio requerido.  Cree que sus deseos deben ser ordenes para los desarrolladores.  No alcanza a distinguir entre la ciencia-ficción y la ciencia verdadera. Las conjeturas relacionadas con el desarrollador de TI son las siguientes, siendo algunas de ellas consecuencia de las del cliente:  No alcanza a distinguir entre armar un producto o servicio y desarrollarlo.  Se tiene demasiada confianza, por lo que siempre piensa que tendrá momentos de inspiración que lo llevarán a la solución correcta (esta técnica se conoce como el “método de inspiración divina”).  Piensa que las fases de desarrollo de TI lo único que generan es una perdida de tiempo.  No siempre tiene idea de la magnitud del desarrollo de TI.  Piensa que “el que paga, manda”. Para finalizar, se harán dos observaciones. Primero, es importante tomar en consideración que muchos de los procesos que se realizan en el desarrollo de TI son irreversibles, en el sentido que existe a menos una variable involucrada en la ejecución de los procesos que no se puede recuperar: Esta es el tiempo invertido en el proceso. Como segunda observación, es primordial remarcar que el seguir un ciclo particular de desarrollo no asegura el éxito en el desarrollo de TI, pero si asegura identificar y reducir el número de riesgos, así como la definición de los correspondientes planes de contingencia. Referencias McConnell, Steve. Desarrollo y gestión de proyectos informáticos. Microsoft Press, McGraw- Hill, España, 1996. Miller, George. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Review, 1956, vol. 63, pp. 81-97. Página 6 de 6