Ingeniera del Software II

Richard Rojas #01-34587

Israel Boucchechter # 97-29307

1/17/2005
Ciclos de Vida de Ingeniera del Software

Modelo en Cascada1(Bennington 1956):

El ms conocido, esta basado en el ciclo convencional de una ingeniera, el paradigma del
ciclo de vida abarca las siguientes actividades:
Ingeniera y Anlisis
del Sistema
Anlisis de los
Requisitos
Diseo
Codificacin
Prueba
Mantenimiento

Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte de un sistema mayor
el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego
asignando algn subconjunto de estos requisitos al software.
Anlisis de los requisitos del software: el proceso de recopilacin de los requisitos se centra e
intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el
mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces
requeridas.
Diseo: el diseo del software se enfoca en cuatro atributos distintos del programa: la estructura
de los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la
interfaz. El proceso de diseo traduce los requisitos en una representacin del software con la
calidad requerida antes de que comience la codificacin.
Codificacin: el diseo debe traducirse en una forma legible para la maquina. El paso de
codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada la codificacin
puede realizarse mecnicamente.
Prueba: una vez que se ha generado el cdigo comienza la prueba del programa. La prueba se
centra en la lgica interna del software, y en las funciones externas, realizando pruebas que
aseguren que la entrada definida produce los resultados que realmente se requieren.
Mantenimiento: el software sufrir cambios despus de que se entrega al cliente. Los cambios
ocurrirn debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del
entorno externo (sistema operativo o dispositivos perifricos), o debido a que el cliente requiera
ampliaciones funcionales o del rendimiento.
Desventajas:
Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre
hay iteraciones y se crean problemas en la aplicacin del paradigma.
1

Ingeniera del Software: Un enfoque practico, Roger S. Presuman, 3ra Edicin, Pag. 26-30.

Normalmente, es difcil para el cliente establecer explcitamente al principio todos los

requisitos. El ciclo de vida clsico lo requiere y tiene dificultades en acomodar posibles
incertidumbres que pueden existir al comienzo de muchos productos.
El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estar
disponible una versin operativa del programa. Un error importante no detectado hasta que
el programa este funcionando puede ser desastroso.
La ventaja de este mtodo radica en su sencillez ya que sigue los pasos intuitivos
necesarios a la hora de desarrollar el software.
Modelo V (Ministerio de Defensa de Alemania, 1992):
El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una
evolucin del mismo.

ANALISIS DE
REQUERIMIENTOS

Los planes de prueba son

el nexo entre el desarrollo
y la verificacin

OPERACION
Y
MANTENIMIENTO

Plan de
Pruebas
de Aceptacin

PRUEBA DE
ACEPTACION

Validar
requerimientos
DISEO DEL
SISTEMA

Plan de
Pruebas
del Sistema

PRUEBA DEL
SISTEMA

Verificar
diseo
DISEO
DETALLADO

Plan de
Pruebas
de Integracin

PRUEBA DE
INTEGRACION

IMPLEMENTACION
DE PROGRAMAS Y
PRUEBA UNITARIA

Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra mitad tiene
como finalidad hacer pruebas e integracin asociado a cada una de las etapas de la mitad
anterior.
Se puede identificar una ventaja principal con respecto al Modelo Cascada ms simple, y
se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de
cascada.
Desventajas:
El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptacin
al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la
implementacin, lo que puede traer como consecuencia un roll-back de todo un proceso
que cost tiempo y dinero.
El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores,
cosa que en la realidad puede ocurrir.
Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de
desarrollo, lo que disminuye el riesgo.
A pesar de todo lo antes mencionado, definitivamente se trata de un modelo ms robusto y
completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el
modelo de cascada.