Modelo de Cascada - Sistemas 2

Modelo de Cascada

Descripción

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas. Después de cada etapa se realiza una revisión para comprobar si se puede pasara la siguiente.

Estructura Modelo en Cascada(Bennington 1956)

El más conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:

Ingeniería y Análisis 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 algún subconjunto de estos requisitos al software.

Análisis de los requisitos del software: el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software debe comprender el ámbito de la información del software,así como la función,el rendimiento y las interfaces requeridas.

Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software,el detalle procedimental y la caracterización de la interfaz.

Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea.

Prueba: La prueba se centra en la lógica 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 después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo(sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcional eso del rendimiento.

Características 

• Es el más utilizado.
• Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios.
• Para que el proyecto tenga éxito deben desarrollarse todas las fases.
• Las fases continúan hasta que los objetivos se han cumplido.
• Si se cambia el orden de las fases, el producto final será de inferior calidad.

Ventajas

• La planificación es sencilla.
• La calidad del producto resultante es alta.
• Permite trabajar con personal poco cualificado.

•

Desventajas

• No refleja realmente el proceso de desarrollo del software
• Se tarda mucho tiempo en pasar por todo el ciclo
• Perpetua el fracaso de la industria del software en su comunicación con el usuario final
• El mantenimiento se realiza en el código fuente
• Las revisiones de proyectos de gran complejidad son muy difíciles
• Impone una estructura de gestión de proyectos

La metodología en cascada se suele emplear, especialmente, en aquellos proyectos cuyos requisitos y procesos se pueden describir de forma precisa durante la fase de planificación, en los que cabe suponer que las hipótesis no van a sufrir una gran variación durante el transcurso del proyecto. Los procedimientos estrictamente lineales se adaptan, así, especialmente bien a proyectos de software pequeños, sencillos y claramente estructurados. A esta misma conclusión llegó Royce en los años 1970. Por este motivo, la alternativa al procedimiento lineal que propuso, y que más tarde se conocería como waterfall model, incluía tres ampliaciones principales:

Verificación tras cada fase de proyecto

Según Royce, los resultados de cada una de las fases de proyecto se deben comparar y verificar inmediatamente con los documentos elaborados previamente. Es decir, inmediatamente después de desarrollar un módulo, por ejemplo, se debería garantizar que este cumple con las exigencias definidas con anterioridad sin esperar a que concluya el proceso de desarrollo.

Al menos, dos iteraciones

Según Royce, el modelo se debería ejecutar en, al menos, dos ocasiones: primero para elaborar un prototipo y, a continuación, para desarrollar el producto de software en sí.

Pruebas que incluyen al usuario final

La tercera ampliación del modelo en cascada propuesta por Royce en su ensayo es una medida que, a día de hoy, se ha convertido en un procedimiento estándar en el desarrollo de productos: la inclusión del usuario final en el proceso de producción. Royce propone incluir al usuario en tres momentos diferentes del proceso de desarrollo de software: durante la planificación del software en la fase de análisis, entre el diseño del software y su implementación y en la fase de prueba que precede al lanzamiento del software.

Procedimientos alternativos al modelo en cascada

Debido a la secuencia estrictamente lineal de las fases sucesivas de proyecto, el modelo en cascada se adaptaría, en el mejor de los casos, a proyectos de software de poca envergadura. Por el contrario, los procesos complejos de varios niveles serían difícilmente representables con este modelo. Por este motivo, con el paso del tiempo han ido surgiendo enfoques alternativos.

Mientras que algunos modelos, como el modelo en espiral o el modelo en V, se consideran una evolución del waterfall model clásico, algunos métodos, como la programación extrema, el desarrollo ágil de software o el desarrollo iterativo, se centran en un enfoque completamente diferente y suelen permitir una adaptación a los cambios más recientes o a las exigencias más actuales.