2b. La Ingeniería. Ing. Carlos Ernesto García, M.Sc.

Proceso de desarrollo de artefactos de Ingeniería.

1. El ciclo de vida.
Introducción. El concepto “ciclo de vida” se refiere a las etapas que
ocurren en el lapso de tiempo que comprende la aparición, el
desarrollo y la extinción de la funcionalidad de una determinada clase
de sistema. El término tiene su origen en la Biología, en la que se
refiere al período que comprende el nacimiento, el desarrollo y la
muerte de los seres vivos. El ciclo de vida del humano comprende
las siguientes etapas: prenatal (desde la concepción), infancia, niñez,
pubertad, adolescencia, juventud, madurez, adultez, vejez, y muerte.
En una pareja humana, las etapas podrían ser: cortejo, noviazgo,
identidad, intimidad, formalización y permanencia o disolución. El
concepto se aplica actualmente a todo tipo de sistema. En mercadeo,
por ejemplo, el ciclo de vida de un producto abarca el tiempo desde
su lanzamiento al mercado hasta su retiro al dejar de generar ganancia.
2. Qué es un problema?
En general, existen dos clases de problema: los de connotación negativa y los de connotación positiva.
Problemas de connotación negativa. Son aquellos cuya solución implica destruir, retirar o liberarse de
algo perjudicial o indeseable que está presente. Por ejemplo: un ruido, un dolor de cabeza, una enfermedad
o una preocupación. La solución de estos problemas implica eliminar alguna fuente de insatisfacción.
Problemas de connotación positiva. Son aquellos que suponen acceder a alguna fuente de satisfacción a
través de su solución. Por ejemplo: conectar una ciudad con otras vía aérea, comunicar inalámbricamente a
los ciudadanos de un país, o excavar el suelo del planeta Marte.
Los problemas de los que trata la Ingeniería son invariablemente de connotación positiva: las soluciones
conllevan siempre la construcción de algún artefacto del que se deriva alguna forma de satisfacción o
beneficio para seres humanos. Por ejemplo: una nave aérea, un teléfono móvil, o un robot a control remoto.
3. El ciclo de vida en Ingeniería.
Todos los artefactos que se construyen en Ingeniería, independientemente de la disciplina y el artefacto de
que se trate, son soluciones a algún problema, y sus desarrollos siguen el mismo proceso general que se le
conoce como “ciclo de vida”. El ciclo de vida provee la base para establecer la estrategia para el desarrollo
del artefacto y es un patrón esencial para la administración del proyecto de desarrollo del artefacto.
En este contexto, “desarrollo” se refiere al proceso de construir un artefacto, que va desde el momento en
que se concibe la primera idea hasta el momento en que se pone el artefacto a disposición del interesado
para su uso. Y por “artefacto” se entiende cualquier cosa cuyo diseño requiera del conocimiento de la
Ingeniería: un edificio, un cohete espacial, una máquina, un proceso industrial, un procedimiento
administrativo, un sistema informático, un software, etc.
En el ámbito de la Ingeniería, el término “ciclo de vida” surgió a finales de los años 1960’s como un modelo
para el desarrollo de software; pero actualmente se utiliza al referirse al proceso de desarrollo de cualquier
tipo de artefacto. Lo cierto es que al analizar la literatura de esa época sobre los procesos de la Ingeniería,
se encuentra que, aunque no se les llama ciclo de vida, en conjunto presentan prácticamente la misma idea.
1
Krick, por ejemplo, se refiere al ciclo de vida como “proceso solucionador de problemas”.
Hay dos grandes clases de ciclo de vida: desarrollo total y desarrollo incremental.
4. Ciclo de vida desarrollo total.
El ciclo de vida desarrollo total es el proceso más tradicional en Ingeniería, y durante mucho tiempo el único
existente. Todos los otros ciclos de vida se derivan de éste, y han sido propuestos como respuesta al
problema de incorporar al proceso de desarrollo, características emergentes del ciclo de vida visto como un
todo desde la perspectiva del enfoque de sistemas.
La característica fundamental del desarrollo total es que el artefacto en cuestión se pone a disposición para
el uso de los interesados hasta que se completa totalmente el ciclo. Se adopta en situaciones en la que no

1
Krick, E. V., “An Introduction to Engineering and Engineering Design”, Wiley, New York, 1965.
se prevé cambio o aumento significativo en los requerimientos a corto plazo, como en la construcción de un
puente; o cuando estos pueden ser reducidos o eliminados anticipando futuros crecimientos o cambios en
las necesidades. Por ejemplo, se puede desarrollar una casa con ambientes adicionales a los requeridos
actualmente, anticipando un crecimiento de la familia que la habitará.
También los requerimientos pueden resultar bastante fijos por factores económicos, políticos, operativos o
medioambientales. Por ejemplo, desarrollar un vehículo de exploración espacial antes de que termine un
período presidencial o antes de que la competencia lo desarrolle; o desarrollar un sistema informático para
un sistema electoral antes de una fecha determinada; o desarrollar un puente sobre un río antes de que
comience el invierno.
El ciclo de desarrollo comprende 6 etapas, las cuales en un principio se suponía que deberían llevarse a
cabo estrictamente de manera secuencial, una detrás de la otra, y la ejecución de cada una estaba
subordinada a la conclusión de la etapa previa (Ver Figura 2).

Figura 2. Ciclo de vida desarrollo total (Lineal).

Formul. del Análisis del Construc-
problema problema. Diseño Prueba Instalación
ción

Definición del problema

Tiempo después se reconoció que este modelo era impráctico en la

realidad y se modificó para que cada etapa se traslapara hasta un cierto Figura 3. Ciclo de vida
punto con la siguiente, como se muestra en la Figura 3. Las etapas del desarrollo total (Cascada).
ciclo son las siguientes:
i. Formulación del problema. Formulación
ii. Análisis del problema [Análisis de requerimientos].
Análisis
iii. Diseño.
iv. Construcción (Implementación}. Diseño
v. Prueba.
vi. Instalación (Puesta en marcha). Construcción
Definición del problema. A las primeras dos fases del ciclo de vida de la
Prueba
Ingeniería o proceso solucionador de problemas combinadas constituyen
lo que Krick las denomina la “definición del problema”. Instalación
i. Formulación del problema.
La formulación de un problema de Ingeniería tiene el esencial propósito de describir de modo inequívoco el
problema que se busca solucionar. Y esta descripción ocupa una sola frase (ver Figura 4):
“Diseñar un artefacto que cambie un estado A en un estado B”
El estado A es una condición existente antes de la transformación deseada; el estado B es una condición
existente después de transformación deseada
En otras palabras, un problema de Ingeniería queda completamente formulado al conocer exhaustivamente
los estados A y B del problema. No se requiere hacer nada
Figura 4. Problema de Ingeniería.
más. Por ejemplo:
a. Diseñar un artefacto que transforme ropa sucia (A) Estado A Estado B
en ropa limpia (B). Artefacto
b. Diseñar un artefacto que incorpore a una base de
datos central (B) los datos capturados en cada
municipio del país (A).
c. Diseñar un artefacto para trasladar vehículos de una orilla de un río (A) a la otra (B).
Cuando el artefacto en cuestión es un sistema informático Figura 5. El artefacto es un SI.
(ver Figura 5), el estado A siempre será un conjunto de datos
específicos, y el B cierta información requerida. Por tanto, el {Datos} {Información}
problema siempre se formulará con un enunciado similar a: Sist. Inf.
“Diseñar un sistema informático que transforme <ciertos A B
datos específicos> (A) en <información requerida> (B)”.
(Lo que está entre <> debe especificarse en detalle).

2
Ejemplo. Un ejemplo de formulación del problema extraído de un proyecto real es el siguiente: la idea inicial
del problema era poder configurar de forma
remota una computadora tipo PC desde Figura 6. Problema: configuración remota de PCs.
otra. A la solución a desarrollar se le llamó PC con PC con
Sistema de Actualización Remota (SAR). configuración Configuración
Los estados A y B se definieron así (Fig. 6): Cx
SAR Cp
A. Una computadora tipo PC con una Estado A Estado B
configuración Cx cualquiera.
B. La misma computadora con una configuración preferida Cp.
La formulación del problema quedó expresada así:
Diseñar un sistema para cambiar de manera remota una configuración Cx cualquiera de una
computadora tipo PC a una configuración preferida Cp.
En este caso, a manera de aclaración, se consideró conveniente complementar la formulación del problema
con una explicación del término “configuración”:
Una configuración Ci de una PC en un momento i cualquiera queda definida inequívocamente por un n-tuplo
conformado por la concatenación de cuatro conjuntos:
a. El conjunto de identificadores de sus recursos de hardware relevantes.
b. El conjunto de identificadores de componentes de software relevantes que tiene instalados.
c. El conjunto de valores de los atributos configurables de los recursos de hardware.
d. El conjunto de valores de los atributos configurables de componentes de software que tiene instalados.
A simple vista, la fase de formulación del problema puede parecer muy simple; pero no lo es. La formulación
del problema determina el éxito o fracaso del proceso solucionador de problemas; por lo que el esfuerzo
dedicado a ella no debe subestimarse. Al respecto dice Krick: “Aún cuando la sentencia comúnmente
conocida que dice: un problema adecuadamente planteado, virtualmente está resuelto, es una aseveración
2
bastante exagerada, no deja de tener el aspecto positivo de recalcar la importancia de esa etapa”.
Errores comunes. Algunos errores que suelen cometer frecuentemente los analistas al ejecutar esta etapa,
y que deben evitarse a toda costa son los siguientes:
a. Formulan el problema con una lista de problemas de connotación negativa. Por ejemplo: la cola de
clientes se hace demasiado larga, el tiempo no alcanza para atender todas las órdenes de compra,
sólo se sirve agua potable a la ciudad ocho horas diarias, o las trabazones de autos son enormes.
b. Establecen como estado B la negación de un estado A. Establecen como estado A un problema sin
solución y como estado B, el mismo problema con solución. Por ejemplo: estado A: ciudadanos sin
trasporte público, estado B: ciudadanos con trasporte público; estado A: familias sin casa, estado B:
familias con casa; o estado A: vehículos sin puente autopista, estado B: vehículos con autopista.
c. Atacan la solución actual del problema documentando el porqué no funciona (análisis causal). Esto
es pérdida de tiempo, pues si se busca una solución a un problema es porque la actual no sirve; y si
no sirve, para qué analizarla?
d. Se subestima la importancia de la correcta formulación improvisando cualquier cosa que suene
problemática. Esto conduce a la absurda situación de lograr al final del ciclo de vida, una “solución
sin problema”.
Análisis contextual. La solución a cualquier problema de
Ingeniería tiene, como todo sistema, un contexto en el Sistema
cual se instalará y operará, al que se le denomina sistema contextual
contextual El sistema contextual, es un supersistema del Equipo
sistema a desarrollar; es su entorno inmediato. Ver Fig; 7. Leyes Clientes
El análisis contextual del problema a resolver es esencial
para llegar a una correcta formulación y análisis de éste.
Artefacto a desarrollar
Consiste en identificar todas las entidades del contexto Otros Procesos
relevantes al problema, y las interacciones previsibles de SI
estas entidades con el artefacto a desarrollar. Al concluir
su desarrollo, el artefacto quedará integrado a su sistema Figura 7. Análisis contextual.
contextual si y sólo si es capaz de interactuar con el resto
de elementos de su entorno. El análisis contextual se realiza durante la definición del problema.

2
Krick, E. V., Introducción a la Ingeniería y al Proyecto en la Ingeniería, Limusa-Wiley, México, 1973. P. 134.
3
Por ejemplo, si el artefacto a desarrollar se tratara de un edificio de apartamentos para vivienda, el análisis
contextual llevaría a considerar elementos del ambiente tales como: el terreno, el suelo, corrientes eólicas,
temperatura ambiental, precipitación pluvial, calles de acceso, nivel económico-social de los potenciales
inquilinos, normativa sobre medioambiente, y los servicios públicos de alcantarillado, agua potable, energía,
telefonía y transporte público.
Si el artefacto se tratara de un sistema informático para control de inventarios de una empresa, el sistema
contextual podría incluir al sistema de producción, el sistema de mercadeo, el sistema contable, el sistema
informático corporativo, los clientes, los proveedores y la tecnología disponible.
Y si el artefacto se tratara de un sistema informático de registro académico para un colegio de educación
media, se podrían considerar elementos relevantes del sistema contextual: el sistema de administración
académica; el sistema informático del colegio, los profesores, los alumnos, los padres de familia, el
Ministerio de Educación y la normativa educativa.
ii. Análisis del problema.
En la fase de formulación del problema dice Krick, el problema “se define en una forma relativamente
amplia, sin consideración de detalles, y haciendo hincapié respecto a la identificación de los estados A y B”.
Es en la fase de análisis del problema, donde “el problema se define en una forma relativamente más
detallada”, determinando las características específicas del problema.
En la fase de análisis del problema se documentan características cualitativas y cuantitativas relevantes del
estado A (entradas), del estado B (salidas) y de la solución; características que delinean en última instancia
restricciones que deberán satisfacerse durante el proceso de diseño. Estas características se clasifican en:
a. Características de entradas [Estado A]. Fuentes, medios, volumen y frecuencia.
b. Características de salidas [Estado B]. Destinos, usos, volúmenes y frecuencias.
c. Restricciones operativas. Restricciones bajo las cuales se requiere que el artefacto opere.
d. Restricciones de desarrollo. Restricciones bajo las cuales se requiere que el artefacto se desarrolle.
e. Variables de solución. Características de soluciones alternativas que diferenciarán unas de otras. En
el caso de un sistema informático, por ejemplo, podrían ser variables de solución: topografía de red,
clase de equipo de computación, medio de transmisión de datos, sistema operativo, sistema de energía,
sistema de seguridad, ubicación de equipo, etc. Cualquier solución se expresará con un valor en cada
una de estas variables.
f. Criterios. Criterios que se aplicarán para evaluar las soluciones alternativas que se lleguen a considerar
para seleccionar la mejor. En el caso de sistemas informáticos los criterios suelen ser: costo, seguridad,
confiabilidad, tiempo de respuesta, facilidad de uso y mantenibilidad. A cada criterio se le asigna una
ponderación relativa al resto de criterios.
Los criterios no son igualmente importantes, por lo que es necesario ponderarlos. Los criterios más
altamente ponderados determinarán más fuertemente los tipos de solución que se lleguen a considerar.
g. Uso esperado. La cantidad de veces que se espera que el artefacto desarrollado repita la trasformación
del estado A al estado B; es decir, la cantidad de veces que se usará la solución del problema. Cuando
se trata de un sistema informático, el uso podría ser: una sola vez, diario, semanal, mensual o continuo
Una buena estimación del uso esperado es importante porque está influye determinantemente en el tipo
de soluciones a considerar. No es lo mismo que el uso sea una vez al año que 10 veces diarias.
h. Volumen de producción. Se refiere a la cantidad de veces que se replicará la solución. En el caso de
un sistema informático, lo más frecuente es una sola vez. En el caso de un software informático para
una sucursal bancaria, si este debiera instalarse en 90 sucursales, el volumen de producción sería 90
porque se requerirían 90 copias del software, una por sucursal.
Esta estimación podría requerir una investigación de mercado para valorar el potencial de “venta” por
mes o por año de la solución.
Al igual que el uso esperado, una buena estimación del volumen de producción es importante porque
está influye determinantemente en el tipo de soluciones a considerar. No es lo mismo un software que
se reproducirá únicamente 3 veces que uno que se reproducirá 50,000 veces; una por “cliente”.
El análisis del problema demanda bastante tiempo de trabajo en recolección, procesamiento y análisis de la
información pertinente. Pero vale la pena pues el producto de este análisis es una definición del problema
en gran detalle que facilitará concebir creativamente las mejores soluciones. En algunos contextos esta
etapa se le llama “análisis de requerimientos” o “definición de requerimientos”, por el hecho de que por el
análisis quedan plasmados todos los requerimientos que las soluciones factibles deben satisfacer.
4
Restricción ficticia. Es una restricción (o requerimiento) a la solución del problema que injustificadamente
se asume durante la fase de análisis del problema o durante la fase de diseño. La mayoría de las veces este
tipo de restricciones no se escriben porque no provienen de decisiones explícitas sino de supuestos
mentales que se dan por sentados, aceptados de manera automática e inconciente por el ingeniero. Por
ejemplo, al considerar el problema de trasladar vehículos de una orilla de un río a la otra se suele asumir la
restricción, sin escribirla, de que debe de ser por medio de una estructura semejante a un puente.
Al respecto dice Krick "La naturaleza elusiva de las restricciones ficticias proviene del hecho de que,
ordinariamente, no son resultado de deliberaciones concienzudas, sino de una actitud laxa o subjetiva; ya
que si las restricciones ficticias se enunciaran explícitamente, inmediatamente saltaría a la vista su
3
naturaleza ficticia y frecuentemente, absurda".
La mayoría de ingenieros tiende a asumir restricciones ficticias. Tales restricciones deben eliminarse por
completo de la definición del problema, dando así cabida un espacio de soluciones factibles más amplio, lo
que conduce inevitablemente a mejores soluciones.
Producto. El producto principal de la etapa de análisis del problema es un documento denominado algo así
como: “Requerimientos del Sistema X” o “Definición del Problema X” el cual contiene la formulación del
problema y el análisis del problema.
Ejemplo:
El análisis del problema formulado anteriormente como: “Diseñar un sistema para cambiar de manera
remota una configuración Cx cualquiera de una computadora tipo PC a una configuración preferida Cp”, es:
Sea la H [Host) la computadora a configurar y sea G (Guest) la computadora desde la cual se hará la
configuración remota de H. Las restricciones a las que estará sujeta cualquier solución factible son:
Características de entradas [Estado A] y salidas [Estado B].
1. Las computadoras H y G deben ser del tipo IBM compatible y deben tener instalado disco duro.
2. Las computadoras H y G deben estar interconectadas por redes del tipo packed-switched.
3. Las computadoras H y G deben tener instalado el protocolo TCP/IP, independientemente de si están
interconectadas por Internet o por una red LAN, MAN o WAN.
4. El sistema operativo de ambas PCs H y G debe ser Windows, en cualquier versión.
Restricciones operativas.
1. El enlace efectivo entre las PC G y H debe lograrse en un tiempo máximo de 15 segundos.
2. Desde la computadora G debe poderse cambiar la configuración de cualquier computadora H conectada
a su misma red; independientemente de si sus direcciones IP son públicas o privadas.
3. La computadora G debe poder cambiar la configuración de cualquier computadora H conectada a
Internet, siempre que la dirección IP de la computadora H sea pública; independientemente de si la
dirección IP de la computadora G es pública o privada.
4. El cambio de configuración de Cx a Cp en la computadora H debe realizarse desde la computadora G
ubicada físicamente a cualquier distancia de la PC H: (A metros, kilómetros o miles de kilómetros).
5. El acceso a la computadora H desde la computadora G debe ocurrir sólo si la computadora H y el
sistema de seguridad de la red a que está conectada autorizan tal acceso.
6. Una vez logrado el acceso a la computadora H, deben poderse hacer desde la computadora G, como si
se estuviesen haciendo desde la computadora H, las siguientes operaciones:
a. Apagar, encender y reinicializar la computadora H;
b. Operar cualquier dispositivo de hardware esclavo a la computadora H, tales como teclado, mouse,
discos duros, USBs, dispositivos ópticos, unidades de cinta e impresores;
c. Ejecutar cualquier programa instalado en la computadora H;
d. Obtener información sobre los programas de software que se estén ejecutando en la PC H;
e. Inhabilitar y rehabilitar el funcionamiento del teclado y mouse de la PC H;
f. Capturar y monitorear en tiempo real los movimientos del mouse y las pulsaciones del teclado
realizados por un usuario en la computadora H;
g. Visualizar en tiempo real en la pantalla de la PC G, la imagen de la pantalla de la PC H;
h. Cambiar la configuración de cualquier elemento de hardware o de software de la PC H.
7. El SAR debe permitir intercambiar mensajes en tiempo real, entre el operador de G y el usuario de H.
8. El SAR debe mantener en cada computadora H un inventario actualizado de los recursos de la
computadora H y facilitar el acceso a este inventario desde la computadora G.

3
Ibid. Pág. 155.
5
9. El SAR debe mantener en cada computadora H una bitácora sobre todas las actividades realizadas por
la computadora G y facilitar el acceso a esta bitácora desde la computadora G.
10. El SAR debe poder recuperar los datos que mantiene en cualquier computadora H cuando estos se
estropeen debido a condiciones de error.
11. El SAR debe comprobar por sí mismo durante su instalación, que existan las condiciones mínimas para
operar sin fallas.
Restricciones de desarrollo.
1. El SAR debe desarrollarse en un tiempo máximo de 6 meses.
2. El SAR debe estar constituido exclusivamente por componentes de software instalables en PCs H y G.
Para llevar la intercomunicación G-H se debe utilizar componentes de hardware ya existentes.
Variables de solución. Las soluciones que se consideren durante el proceso de diseño se diferenciarán las
unas las otras esencialmente por cuatro variables de solución:
a. Bibliotecas de componentes de software pertinentes que se adopten.
b. Medios de enlace de comunicación entre la computadora G y la computadora H.
c. Arquitectura de las bitácoras de actividad del SAC.
d. Estándares de seguridad que se adopten
Criterios: En orden de importancia, los criterios para evaluar las alternativas de solución que se presenten,
para seleccionar de entre ellas la mejor son los siguientes:
Criterio %Ponder.
1. Máxima velocidad de intercomunicación. 20
2. Mínimo costo de intercomunicación. 15
3. Máxima flexibilidad para lograr una interconexión. 15
4. Mínimo tiempo de conexión para efectuar un cambio de configuración. 10
5. Mínimo costo de construcción. 10
6. Máxima expandibilidad funcional. 10
7. Mínimo requerimiento de memoria y disco duro para operación. 5
8. Máxima facilidad de instalación. 5
9. Mínimo costo de producción. 5
10. Máximo atractivo para personas encargadas de administrar recursos informáticos. 5
TOTAL: 100
Uso. Se estima que el artefacto a desarrollar se usará, en promedio, 10 veces al mes por computadora PC
sujeta a configuración remota por el artefacto. Por ejemplo, en una empresa con 50 PCs instaladas.se
realizarían en promedio 500 configuraciones remotas mensuales, equivalente a 6,000 anuales.
Volumen de producción. De un estudio de mercado realizado se infiere que en el año de lanzamiento se
requerirán 20,000 copias del SAR, y otras 10,000 en el segundo año. Estas se distribuirán en un CD-ROM
empacado junto con su Manual de Operación.
Errores comunes. Algunos errores que suelen cometer frecuentemente los analistas al ejecutar esta etapa,
y que deben evitarse a toda costa son los siguientes:
a. Restricciones ficticias. Especificación de restricciones ficticias.
b. Realizar esta etapa saltándose la formulación del problema. Suena ilógico hacerlo, pero es bastante
frecuente.
c. Recolectar información a diestra y siniestra, sin tomar en cuenta su pertinencia y relevancia respecto al
problema a resolver. Lo que termina sucediendo tardíamente es que se cuenta con toda clase de datos
inútiles y se carece de la información que en realidad se necesita.
d. Concentrase en investigar, analizar y documentar la solución actual. ¿Para qué?
e. No auxiliarse de cuadros, gráficos, modelos matemáticos e ilustraciones
f. Falta de información cuantitativa, prevaleciendo la información cualitativa. El lenguaje de la Ingeniería
es esencialmente cuantitativo. Términos como: mucho, poco, insuficiente, excesivo, etc. son impropios
por sí solos en Ingeniería. Se requiere saber cuánto es mucho, poco, insuficiente o excesivo.
iii. Diseño.
La etapa de diseño es aquélla en la cual todo ingeniero se realiza como tal, ya que es en ella en la que pone
en juego su creatividad y su ingeniosidad para concebir soluciones factibles al problema que se busca
solucionar.

6
La palabra “diseño” tiene dos acepciones en el ámbito de la Ingeniería: a) Diseño, proceso creativo (mental)
del que surgen soluciones; y b) Diseño, documento que contiene especificaciones de una solución. La etapa
de diseño es el proceso, y como producto de la etapa surgen documentos de diseño.
Solución factible. Una solución a un problema es factible sí y sólo sí satisface todos los requerimientos
especificados en la definición del problema, en el marco de las variables de solución especificadas en el
análisis del problema. En el proceso de diseño sólo pueden tomarse en consideración soluciones factibles; y
además, para que el proceso se considere un proceso de diseño válido, es indispensable que se generen
durante el mismo al menos dos soluciones factibles. De aquí en adelante, cuando se refiera a soluciones se
entenderá que se trata de soluciones factible; pues en realidad, toda solución infactible no es solución.
En el proceso de diseño pueden identificarse cuatro actividades generales:
i. Generación de soluciones alternativas. Proceso mental iterativo basado sobre todo en creatividad, la
cual se enriquece con el conocimiento y experiencia del ingeniero.
ii. Evaluación de soluciones alternativas. Se lleva a cabo aplicando los criterios especificados en la etapa
de análisis del problema.
iii. Selección de la mejor solución de entre las alternativas evaluadas. La solución seleccionada es la que
se construirá en la etapa de construcción o implementación.
iv. Especificación detallada de la solución seleccionada documentada con planos, prototipos, modelos y
todo lo que fuere necesario para una especificación completa.
v. Planificación de la construcción de la solución, documentada en un Plan de Implementación, y de las
pruebas de funcionalidad e idoneidad general de la solución.
Producto. El producto principal de la etapa de diseño es un documento denominado: “Diseño del Sistema
X” o “Especificaciones de Diseño del Sistema X”, el cual contiene las especificaciones precisas de la
solución seleccionada. El diseño de la solución seleccionada se manifiesta en uno o varios modelos del
sistema o artefacto a construir, cada modelo presentando una vista diferente del mismo artefacto o sistema.
También son productos de la etapa de diseño otros documentos, entre los que se cuentan los siguientes:
a. Plan de Implementación del Sistema X. Calendarización de las actividades de construcción de la solución
con base a su diseño y presupuesto de recursos para desarrollar dicho plan.
b. Plan de Prueba del Sistema X. Especificación y calendarización de las actividades de prueba del sistema
X (validación y de verificación) durante y al final de su construcción.
iv. Construcción (o implementación).
Es la etapa en la que se construye el artefacto diseñado en la etapa previa, con base a las especificaciones
de diseño contenidas en el documento Diseño del Sistema X (o Especificaciones de Diseño del Sistema);
ejecutándose la etapa según lo planificado en el Plan de Implementación del Sistema X.
Producto. Por supuesto, el producto de esta etapa es el artefacto ya construido, acompañado del “Manual
de Especificaciones Técnicas del Sistema X”.
v. Prueba.
En esta etapa se realizan las pruebas previstas en el Plan de Prueba del Sistema X; lo cual se lleva acabo
en el marco cronológico que establece el Plan de Implementación del Sistema X.
vi. Instalación.
Esta etapa consiste en integrar debidamente la solución construida al entorno para el que fue concebida
hasta dejar dicha solución funcionando plenamente.
5. Anteproyecto, operación y disposición final.
Es importante destacar que a las seis etapas del ciclo de vida de desarrollo les precede una etapa de
anteproyecto y les siguen dos etapas: operación y disposición final.
Anteproyecto. Esta etapa tiene por objetivo esencial estimar la factibilidad técnica, económica, financiera y
operativa del desarrollo del artefacto en cuestión. El artefacto se desarrollará sólo si resulta factible en los
cuatro aspectos.
Operación. Incluye actividades de mantenimiento para prevenir fallas (mantenimiento preventivo), para
corregir las que ocurran (mantenimiento correctivo) o para incorporar nuevas funciones menores
(mantenimiento obligado). También incluye actividades de evaluación para verificar su correcta operación y
anticipar oportunamente su obsolescencia para planificar su sustitución y disposición para deshacerse del
artefacto obsoleto.
Disposición final. Es la etapa en la que se ejecutan actividades que tienen por objetivo deshacerse del
artefacto, normalmente por consideraciones de obsolescencia.

7
6. Ciclo de vida desarrollo incremental.
En el ciclo de desarrollo incremental el artefacto se desarrolla en subciclos consecutivos (ver Fig. 8), con
incrementos de funcionalidad en cada uno de ellos. En el primer subciclo se produce lo que se denomina un
“sistema básico” y en cada subciclo sucesivo se va incrementando la funcionalidad del sistema básico,
retroalimentándose con los resultados del subciclo previo en un afinamiento constante. Es importante
resaltar que cada subciclo se desarrolla como un ciclo de desarrollo total; es decir que, el modelo
incremental es una secuencia de subciclos de desarrollo total.
Por ejemplo, una autopista de seis carriles se podría desarrollar en cuatro subciclos. En el primero se
desarrollarían dos carriles, en el segundo otros dos, en el tercero los últimos dos; y en el cuarto las
estaciones de peaje y los retornos.
El ciclo de de vida de desarrollo incremental
se adopta a menudo, en varias modalidades, Figura 8. Ciclo de vida desarrollo incremental.
en proyectos de desarrollo de sistemas
informáticos y en proyectos de desarrollo de
software. Un sistema informático integrado al Análisis del
problema Diseño
nivel corporativo se suele desarrollar de
manera incremental, desarrollando un
subsistema en cada subciclo.
La selección de la funcionalidad inicial y la Inicio
de subciclos siguientes se hace con base a: Formul. del Construc-
a. Requerimientos prioritarios problema ción
b. Máxima utilidad a corto plazo.
Las ventajas de este proceso, con respecto
desarrollo total son: Fin
a. Facilidad de prueba en cada subciclo.
b. La utilidad palpable que se obtiene en
cada incremento. Instalación Prueba
c. La disponibilidad inmediata de la
experiencia en subciclos previos.

Bibliografía.
Bhamidimarri R., Liu A, editors; “Engineering and Enterprise: Inspiring Innovation”, Springer, London, 2016.
Jonassen, D. H.; ”Learning to Solve Problems: An Instructional Design Guide”, Pfeiffer, San Francisco, 2004.
Ackoff, R. L.; “The Art of Problem Solving, Accompanied by Ackoff’s Fables”, John Wiley & Sons, NY, 1978.