Ingeniería de Software | Modelo de cascada clásica

El modelo de cascada clásico es el modelo básico del ciclo de vida del desarrollo de software . Es muy simple pero idealista. Anteriormente, este modelo era muy popular, pero hoy en día no se usa. Pero es muy importante porque todos los demás modelos de ciclo de vida de desarrollo de software se basan en el modelo de cascada clásico. 
El modelo clásico de cascada divide el ciclo de vida en un conjunto de fases. Este modelo considera que se puede iniciar una fase después de la finalización de la fase anterior. Es decir, la salida de una fase será la entrada a la siguiente fase. Así, el proceso de desarrollo puede considerarse como un flujo secuencial en la cascada. Aquí las fases no se superponen entre sí. Las diferentes fases secuenciales del modelo clásico de cascada se muestran en la siguiente figura: 
 

Conozcamos ahora cada una de estas fases en breve detalle: 
 

1. Estudio de factibilidad : el objetivo principal de esta fase es determinar si sería financiera y técnicamente factible desarrollar el software. 
   El estudio de viabilidad implica comprender el problema y luego determinar las diversas estrategias posibles para resolver el problema. Estas diferentes soluciones identificadas se analizan en función de sus ventajas e inconvenientes. Se elige la mejor solución y todas las demás fases se llevan a cabo según esta estrategia de solución. 
    
2. Análisis y especificación de requisitos: el objetivo de la fase de análisis y especificación de requisitos es comprender los requisitos exactos del cliente y documentarlos adecuadamente. Esta fase consta de dos actividades diferentes. 
   • Recopilación y análisis de requisitos: en primer lugar, todos los requisitos relacionados con el software se recopilan del cliente y luego se analizan los requisitos recopilados. El objetivo de la parte de análisis es eliminar la incompletitud (un requisito incompleto es aquel en el que se han omitido algunas partes de los requisitos reales) y las incoherencias (un requisito incoherente es aquel en el que una parte del requisito contradice otra parte).
   • Especificación de requisitos: estos requisitos analizados se documentan en un documento de especificación de requisitos de software (SRS). El documento SRS sirve como un contrato entre el equipo de desarrollo y los clientes. Cualquier disputa futura entre los clientes y los desarrolladores se puede resolver examinando el documento SRS.
3. Diseño : El objetivo de esta fase es convertir los requisitos adquiridos en el SRS a un formato que pueda codificarse en un lenguaje de programación. Incluye un diseño detallado y de alto nivel, así como la arquitectura general del software. Se utiliza un documento de diseño de software para documentar todo este esfuerzo (SDD)
    
4. Codificación y pruebas unitarias : en la fase de codificación, el diseño del software se traduce en código fuente utilizando cualquier lenguaje de programación adecuado. Así, cada módulo diseñado está codificado. El objetivo de la fase de pruebas unitarias es comprobar si cada módulo funciona correctamente o no. 
    
5. Integración y pruebas del sistema : la integración de diferentes módulos se lleva a cabo poco después de que se hayan codificado y probado la unidad. La integración de varios módulos se lleva a cabo de forma incremental en una serie de pasos. Durante cada paso de integración, los módulos planificados previamente se agregan al sistema parcialmente integrado y se prueba el sistema resultante. Finalmente, después de que todos los módulos se hayan integrado y probado con éxito, se obtiene el sistema de trabajo completo y se lleva a cabo la prueba del sistema. 

   Las pruebas del sistema consisten en tres tipos diferentes de actividades de prueba, como se describe a continuación: 

   • Prueba alfa: la prueba alfa es la prueba del sistema realizada por el equipo de desarrollo.
   • Prueba beta: la prueba beta es la prueba del sistema realizada por un conjunto amigable de clientes.
   • Pruebas de aceptación: después de que se entregó el software, el cliente realizó pruebas de aceptación para determinar si aceptaba el software entregado o lo rechazaba.
6. Mantenimiento: El mantenimiento es la fase más importante del ciclo de vida de un software. El esfuerzo dedicado al mantenimiento es el 60% del esfuerzo total dedicado a desarrollar un software completo. Existen básicamente tres tipos de mantenimiento: 
   • Mantenimiento Correctivo: Este tipo de mantenimiento se realiza para corregir errores que no fueron descubiertos durante la fase de desarrollo del producto.
   • Mantenimiento Perfectivo: Este tipo de mantenimiento se realiza para mejorar las funcionalidades del sistema en base a la solicitud del cliente.
   • Mantenimiento adaptativo: el mantenimiento adaptativo generalmente se requiere para migrar el software para que funcione en un nuevo entorno, como trabajar en una nueva plataforma informática o con un nuevo sistema operativo.

Ventajas del modelo de cascada clásica

El modelo de cascada clásico es un modelo idealista para el desarrollo de software. Es muy simple, por lo que puede considerarse la base para otros modelos de ciclo de vida de desarrollo de software. A continuación se presentan algunas de las principales ventajas de este modelo SDLC: 
 

• Este modelo es muy simple y fácil de entender.
• Las fases en este modelo se procesan una a la vez.
• Cada etapa del modelo está claramente definida.
• Este modelo tiene hitos muy claros y bien entendidos.
• El proceso, las acciones y los resultados están muy bien documentados.
• Refuerza los buenos hábitos: definir-antes-de-diseñar, 
  diseñar-antes-de-codificar.
• Este modelo funciona bien para proyectos más pequeños y proyectos en los que se 
  entienden bien los requisitos.

Inconvenientes del modelo de cascada clásico

El modelo de cascada clásico adolece de varias deficiencias, básicamente, no podemos usarlo en proyectos reales, pero usamos otros modelos de ciclo de vida de desarrollo de software que se basan en el modelo de cascada clásico. A continuación se presentan algunos de los principales inconvenientes de este modelo: 
 

• Sin ruta de retroalimentación: en el modelo clásico en cascada, la evolución del software de una fase a otra es como una cascada. Asume que los desarrolladores nunca cometen ningún error durante ninguna fase. Por tanto, no incorpora ningún mecanismo de corrección de errores. 
   
• Difícil adaptarse a las requests de cambio: este modelo supone que todos los requisitos del cliente se pueden definir completa y correctamente al comienzo del proyecto, pero en realidad los requisitos de los clientes siguen cambiando con el tiempo. Es difícil acomodar cualquier solicitud de cambio después de que se completa la fase de especificación de requisitos. 
   
• Sin superposición de fases: este modelo recomienda que una nueva fase pueda comenzar solo después de la finalización de la fase anterior. Pero en proyectos reales, esto no se puede mantener. Para aumentar la eficiencia y reducir los costos, las fases pueden superponerse.