Ingeniera del Software 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.

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.
Los planes de prueba son el nexo entre el desarrollo y la verificacin
ANALISIS DE REQUERIMIENTOS 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.