Modelo de cascada

El modelo de cascada es el proceso de realizar las fases típicas del ciclo de vida del desarrollo de software (SDLC) en orden secuencial . Cada fase se completa antes de que comience la siguiente, y el resultado de cada fase impulsa las fases subsiguientes. ^{[ 1 ]} En comparación con metodologías SDLC alternativas como Agile , es una de las menos iterativas y flexibles, ^{[ 1 ]} ya que el progreso fluye en gran medida en una dirección (como una cascada ) a través de las fases de concepción, análisis de requisitos , diseño , construcción , pruebas , despliegue y mantenimiento . ^{[ 2 ]} El modelo de cascada es la metodología SDLC más antigua. ^{[ 3 ]} Cuando se adoptó por primera vez, no había alternativas reconocidas para el trabajo creativo basado en el conocimiento. ^{[ 4 ]}

La primera presentación conocida que describía el uso de dichas fases en la ingeniería de software fue realizada por Herbert D. Benington en el Simposio sobre Métodos Avanzados de Programación para Computadoras Digitales el 29 de junio de 1956. ^{[ 5 ]} Esta presentación versó sobre el desarrollo de software para SAGE . En 1983, Benington republicó su artículo con un prólogo en el que explicaba que las fases se habían organizado deliberadamente según la especialización de las tareas, y señalaba que el proceso no se realizaba de forma estrictamente jerárquica, sino que dependía de un prototipo. ^{[ 6 ]}

Aunque el término "cascada" no se utiliza en el artículo, el primer diagrama formal y detallado del proceso se cita a menudo ^{[ 7 ]} como proveniente de un artículo de 1970 de Winston W. Royce . ^{[ 8 ] [ 9 ] [ 10 ]} Sin embargo, comentó que tenía fallas importantes derivadas de cómo las pruebas solo se realizaban al final del proceso, lo que describió como "arriesgado y [propenso a] fallar". ^{[ 8 ]} El resto de su artículo introdujo cinco pasos que consideró necesarios para "eliminar la mayoría de los riesgos de desarrollo" asociados con el enfoque de cascada sin modificar. ^{[ 8 ]} Los cinco pasos adicionales de Royce (que incluían escribir documentación completa en varias etapas del desarrollo) nunca se generalizaron, pero su diagrama de lo que consideraba un proceso defectuoso se convirtió en el punto de partida al describir un enfoque de "cascada". ^{[ 11 ] [ 12 ]}

El primer uso del término "cascada" puede haber sido en un artículo de 1976 de Bell y Thayer. ^{[ 13 ]}

En 1985, el Departamento de Defensa de los Estados Unidos adoptó el modelo de cascada en la norma DOD-STD-2167 para trabajar con contratistas de desarrollo de software. Esta norma se refería a las iteraciones de un desarrollo de software ^{[ 14 ]} como "las fases secuenciales de un ciclo de desarrollo de software" y establecía que "el contratista deberá implementar un ciclo de desarrollo de software que incluya las siguientes seis fases: Análisis de requisitos de software, Diseño preliminar, Diseño detallado, Codificación y pruebas unitarias, Integración y Pruebas". ^{[ 14 ] [ 15 ]}

El modelo describe una secuencia lineal de pasos. Aunque existen varias versiones diferentes, a continuación se describe su esencia. ^{[ 16 ] [ 17 ] [ 18 ] [ 19 ]}

El tiempo invertido al inicio del ciclo de producción de software puede reducir los costos en etapas posteriores. Por ejemplo, un problema detectado en las primeras etapas (como la especificación de requisitos) es más barato de corregir que el mismo error detectado más adelante en el proceso (entre 50 y 200 veces más barato). ^{[ 23 ]}

En la práctica común, las metodologías en cascada dan como resultado un cronograma de proyecto con un 20-40% del tiempo invertido en las dos primeras fases, un 30-40% en codificación y el resto dedicado a pruebas e implementación. Dado que la organización del proyecto debe ser altamente estructurada, la mayoría de los proyectos medianos y grandes incluirán un conjunto detallado de procedimientos y controles que regulan cada proceso del proyecto. ^{[ 24 ]}

Otro argumento a favor del modelo en cascada es que pone énfasis en la documentación (como los documentos de requisitos y los documentos de diseño), así como en el código fuente . En metodologías menos elaboradas y documentadas, se pierde conocimiento si los miembros del equipo se marchan antes de que finalice el proyecto, y puede resultar difícil para el proyecto recuperarse de dicha pérdida. Si se dispone de un documento de diseño completo y funcional (como pretenden el diseño inicial exhaustivo y el modelo en cascada), los nuevos miembros del equipo y los nuevos equipos deberían poder familiarizarse con el proyecto leyendo la documentación. ^{[ 25 ]}

El modelo de cascada proporciona un enfoque estructurado; el modelo en sí progresa linealmente a través de fases discretas, fáciles de comprender y explicar, lo que facilita su comprensión. Además, proporciona hitos fácilmente identificables en el proceso de desarrollo, y se utiliza con frecuencia como ejemplo inicial de un modelo de desarrollo en muchos textos y cursos de ingeniería de software. ^{[ 26 ]}

Es posible que los clientes no conozcan los requisitos exactos antes de ver el software en funcionamiento y, por lo tanto, cambien sus requisitos posteriormente, lo que conlleva rediseño, redesarrollo y nuevas pruebas, y un aumento de los costos. ^{[ 27 ]}

Es posible que los diseñadores no sean conscientes de las dificultades futuras al diseñar un nuevo producto o función de software, en cuyo caso revisar el diseño inicialmente puede aumentar la eficiencia en comparación con un diseño que no se haya creado teniendo en cuenta las restricciones, los requisitos o los problemas recién descubiertos. ^{[ 28 ]}

Las organizaciones pueden intentar abordar la falta de requisitos concretos por parte de los clientes empleando analistas de sistemas para examinar los sistemas manuales existentes y analizar su funcionamiento y cómo podrían reemplazarse. Sin embargo, en la práctica, es difícil mantener una separación estricta entre el análisis de sistemas y la programación, ^{[ 29 ]} ya que la implementación de cualquier sistema no trivial suele revelar problemas y casos límite que el analista de sistemas no había considerado.

Algunas organizaciones, como el Departamento de Defensa de los Estados Unidos, ahora tienen una preferencia declarada en contra de las metodologías de tipo cascada, comenzando con MIL-STD-498 publicado en 1994, que fomenta la adquisición evolutiva y el desarrollo iterativo e incremental . ^{[ 30 ]}

En respuesta a los problemas percibidos con el modelo de cascada puro original, se han ideado muchas versiones modificadas para abordar dichos problemas. Estas incluyen los modelos de desarrollo rápido que Steve McConnell llama "cascadas modificadas": ^{[ 23 ]} el "modelo sashimi" de Peter DeGrace (cascada con fases superpuestas), cascada con subproyectos y cascada con reducción de riesgos. También existen otras combinaciones de modelos de desarrollo de software, como el "modelo de cascada incremental". ^{[ 31 ]}

El modelo final de Royce ilustró que la retroalimentación podía (debería, y a menudo lo haría) conducir de las pruebas de código al diseño (ya que las pruebas de código revelaban fallas en el diseño) y del diseño de vuelta a la especificación de requisitos (ya que los problemas de diseño pueden requerir la eliminación de requisitos conflictivos o de otro modo insatisfacibles/no diseñables). En el mismo documento, Royce también abogó por grandes cantidades de documentación, hacer el trabajo "dos veces si es posible" ^{[ 32 ]} (un sentimiento similar al de Fred Brooks , famoso por escribir El hombre-mes mítico —un libro influyente en la gestión de proyectos de software— que abogaba por planificar para "desecharlo"), e involucrar al cliente tanto como sea posible (un sentimiento similar al de la programación extrema ).

Las observaciones de Royce sobre el modelo final son las siguientes:

1. El diseño completo del programa debe realizarse antes de que comience el análisis y la codificación.
2. La documentación debe estar actualizada y completa.
3. Haz el trabajo dos veces si es posible.
4. Las pruebas deben planificarse, controlarse y supervisarse.
5. Involucre al cliente

• Understanding the pros and cons of the Waterfall Model of software development
• Project lifecycle models: how they differ and when to use them
• Going Over the Waterfall with the RUP by Philippe Kruchten
• CSC and IBM Rational join to deliver C-RUP and support rapid business change
• c2:WaterFall