Cascada

El modelo de la cascada es uno de los primeros modelos empleados en el desarrollo de software, se popularizo en 1970 por Winston Royce y aún está vigente en algunos desarrollos. Éste modelo se define como una secuencia de actividades a ser seguidas en orden, donde la estrategia principal es definir y seguir el progreso del desarrollo de software hacia puntos de revisión bien definidos, es decir, se codifica y reparan los errores; es un proceso continuo de codificación y reparación.

Sus características principales son:

• Es lineal
• Las actividades están relacionadas secuencialmente.
• Cada etapa tiene una entrada y una salida.
• Es rígido y sistemático: La entrada de una actividad es la salida de la etapa anterior, por lo cual no se puede dar inicio a la siguiente fase.
• Es monolítico: Existe una única fecha de entrega.
• La implementación se pospone hasta que no se comprendan los objetivos.
• Los documentos a entregar rigen el proceso de software.
• Las fases que contempla el modelo de la cascada son al Análisis y especificación de requerimientos, diseño, codificación, integración y pruebas, liberación y mantenimiento.

Su ciclo de vida abarca las siguientes actividades:

• Análisis de requisitos.
• Diseño del Sistema.
• Codificación.
• Pruebas.
• Verificación.
• Mantenimiento.

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

Si 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. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.

Codificación

El diseño debe traducirse en una forma legible para la maquina. Si el diseño se realiza de una manera detallada, la codificación puede realizarse mecánicamente.

Prueba

Una vez que se ha generado el código comienza la prueba del programa. 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 debidos a que se haya encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos) o a que el cliente requiera ampliaciones funcionales o del rendimiento.

Ventajas

• Sencillez.
• Se tiene todo bien organizado y no se mezclan las fases.
• Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.
• Ayuda a minimizar los gastos de la planificación porque permite realizarla sin planificación porque permite realizarla sin problemas.
• La calidad del producto resultante es alta.

Desventajas

• Gran dependencia en los requerimientos iníciales.
• Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.
• El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresión de un desarrollo lento, existe la incertidumbre de los clientes si sus proyectos serán entregados a tiempo.
• Inicio de la codificación muy tarde en el ciclo de vida del proyecto.
• Es difícil incorporar nuevas cosas si se quiere actualizar

Características

• Es el más utilizado.
• Es una visión del proceso de desarrollo de software como una sucesión de etapas que produce productos intermedios.
• Si se cambia el orden de las fases, el producto final será de inferior calidad.
• Las actividades están relacionadas secuencialmente.

El modelo en cascada puede ser apropiado, en general, para proyectos estables (especialmente los proyectos con requisitos no cambiantes) y donde es posible y probable que los diseñadores predigan totalmente áreas de problema del sistema y produzcan un diseño correcto antes de que empiece la implementación.

Funciona bien para proyectos pequeños donde los requisitos están bien entendidos.

Es un modelo en el que todo está bien organizado y no se mezclan las fases. Es simple y fácil de usar.

Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene entregables