Este documento discute la importancia de seguir los métodos generales de desarrollo de tecnología de la información (TI), tomando como referencia eventos análogos como visitas médicas y planificación de eventos. Explica que cuando las fases de desarrollo como identificación del problema, análisis, diseño e implementación no se llevan a cabo de manera precisa y completa, pueden surgir consecuencias negativas como tratamientos médicos incorrectos, fiestas fallidas o productos de TI defectuosos. También advierte sobre

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