El modelo de cascada es un desglose de las actividades de desarrollo en fases secuenciales lineales , lo que significa que se transmiten entre sí, donde cada fase depende de los entregables de la anterior y corresponde a una especialización de tareas. [1] El enfoque es típico de ciertas áreas del diseño de ingeniería . En el desarrollo de software , [1] tiende a estar entre los enfoques menos iterativos y flexibles, ya que el progreso fluye en gran medida en una dirección ("hacia abajo" como una cascada ) a través de las fases de concepción, iniciación, análisis , diseño , construcción , prueba , implementación y mantenimiento . [2] [ se necesita una mejor fuente ] El modelo en cascada es el primer enfoque SDLC que se utilizó en el desarrollo de software. [ cita necesaria ]
El modelo de desarrollo en cascada se originó en las industrias manufacturera y de la construcción , [ cita necesaria ] donde los entornos físicos altamente estructurados significaron que los cambios de diseño se volvieron prohibitivamente costosos mucho antes en el proceso de desarrollo. [ cita necesaria ] Cuando se adoptó por primera vez para el desarrollo de software, no existían alternativas reconocidas para el trabajo creativo basado en el conocimiento. [3] [ se necesita una mejor fuente ]
La primera presentación conocida que describe el uso de tales fases en la ingeniería de software fue realizada por Herbert D. Benington en el Simposio sobre métodos de programación avanzados para computadoras digitales el 29 de junio de 1956. [4] Esta presentación trataba sobre el desarrollo de software para SAGE . En 1983, el artículo se volvió a publicar con un prólogo de Benington que explicaba que las fases estaban organizadas deliberadamente según la especialización de las tareas y señalaba que, de hecho, el proceso no se realizaba de forma estricta de arriba hacia abajo, sino que dependía de un prototipo. . [3]
Aunque el término "cascada" no se utiliza en el artículo, el primer diagrama formal detallado del proceso conocido más tarde como "modelo en cascada" a menudo se cita como un artículo de 1970 de Winston W. Royce . [5] [6] [7] Sin embargo, también sintió que tenía fallas importantes derivadas del hecho de que las pruebas solo se realizaban al final del proceso, lo que describió como "arriesgado e invita al fracaso". [5] 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 inalterada. [5]
Los cinco pasos adicionales de Royce (que incluían escribir documentación completa en varias etapas de desarrollo) nunca se generalizaron, pero su diagrama de lo que él consideraba un proceso defectuoso se convirtió en el punto de partida al describir un enfoque en "cascada". [8] [ se necesita una mejor fuente ]
El primer uso del término "cascada" puede haber sido en un artículo de 1976 de Bell y Thayer. [9] [ se necesita una mejor fuente ]
En 1985, el Departamento de Defensa de los Estados Unidos capturó este enfoque en DOD-STD-2167A [ cita necesaria ] , sus estándares para trabajar con contratistas de desarrollo de software, que establecían que "el contratista deberá implementar un ciclo de desarrollo de software que incluya las siguientes seis fases : Análisis de Requerimientos de Software, Diseño Preliminar, Diseño Detallado, Codificación y Pruebas Unitarias, Integración y Pruebas". [10]
Aunque Royce nunca recomendó ni describió un modelo en cascada [ cita necesaria ] , critica la estricta adherencia a las siguientes fases:
Así, el modelo en cascada sostiene que uno debe pasar a una fase sólo cuando se revisa y verifica la fase anterior.
Sin embargo, varios modelos de cascada modificados (incluido el modelo final de Royce) pueden incluir variaciones leves o importantes en este proceso. [5] Estas variaciones incluían regresar al ciclo anterior después de que se encontraron fallas aguas abajo, o regresar completamente a la fase de diseño si las fases aguas abajo se consideraban insuficientes.
El tiempo dedicado al inicio del ciclo de producción de software puede reducir los costos en etapas posteriores. Por ejemplo, un problema encontrado en las primeras etapas (como la especificación de requisitos) es más barato de solucionar que el mismo error encontrado más adelante en el proceso (por un factor de 50 a 200). [11]
En la práctica común, las metodologías en cascada dan como resultado un cronograma de proyecto en el que se invierte entre el 20% y el 40% del tiempo en las dos primeras fases, entre el 30% y el 40% del tiempo en codificación y el resto se dedica a pruebas e implementación. La organización real del proyecto debe estar muy 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. [12] [ verificación fallida ]
Otro argumento a favor del modelo en cascada es que pone énfasis en la documentación (como documentos de requisitos y documentos de diseño), así como en el código fuente . [ cita necesaria ] En metodologías menos diseñadas y documentadas, el conocimiento se pierde si los miembros del equipo se van antes de que se complete el proyecto, y puede ser difícil para un proyecto recuperarse de la pérdida. Si está presente un documento de diseño completamente funcional (como es la intención del gran diseño inicial y el modelo en cascada), los nuevos miembros del equipo o incluso equipos completamente nuevos deberían poder familiarizarse leyendo los documentos. [13]
El modelo en cascada proporciona un enfoque estructurado; el modelo en sí progresa linealmente a través de fases discretas, fácilmente comprensibles y explicables y, por tanto, es fácil de entender; también proporciona hitos fácilmente identificables en el proceso de desarrollo. Quizás sea por esta razón que el modelo en cascada se utiliza como ejemplo inicial de un modelo de desarrollo en muchos textos y cursos de ingeniería de software. [14]
La simulación puede desempeñar un papel valioso dentro del modelo en cascada. Al crear simulaciones computarizadas o matemáticas del sistema que se está desarrollando, los equipos pueden obtener información sobre cómo funcionará el sistema antes de pasar a la siguiente fase. Las simulaciones permiten probar y perfeccionar el diseño, identificar posibles problemas o cuellos de botella y tomar decisiones informadas sobre la funcionalidad y el rendimiento del sistema.
Es posible que los clientes no sepan exactamente cuáles son sus requisitos antes de ver el software funcional y, por lo tanto, cambien sus requisitos, lo que lleva a rediseños, redesarrollos y nuevas pruebas, y a mayores costos. [15]
Es posible que los diseñadores no sean conscientes de las dificultades futuras al diseñar un nuevo producto o característica de software, en cuyo caso es mejor revisar el diseño que persistir en un diseño que no tenga en cuenta restricciones, requisitos o problemas recién descubiertos. [dieciséis]
Las organizaciones pueden intentar hacer frente a la falta de requisitos concretos de los clientes empleando analistas de sistemas para examinar los sistemas manuales existentes y analizar qué hacen y cómo podrían ser reemplazados. Sin embargo, en la práctica, es difícil mantener una separación estricta entre el análisis de sistemas y la programación. [17] Esto se debe a que la implementación de cualquier sistema no trivial casi inevitablemente expondrá problemas y casos extremos que el analista de sistemas no consideró.
En respuesta a los problemas percibidos con el modelo de cascada puro , se introdujeron modelos de cascada modificados, como "Sashimi (cascada con fases superpuestas), cascada con subproyectos y cascada con reducción de riesgos". [11]
Algunas organizaciones, como el Departamento de Defensa de los Estados Unidos, ahora tienen una preferencia declarada contra las metodologías de tipo cascada, comenzando con MIL-STD-498 lanzado en 1994, que fomenta la adquisición evolutiva y el desarrollo iterativo e incremental . [18]
En respuesta a los problemas percibidos con el modelo de cascada "puro", se han introducido muchos "modelos de cascada modificados". Estos modelos pueden abordar algunas o todas las críticas al modelo de cascada "puro".
Estos incluyen los modelos de Desarrollo Rápido que Steve McConnell llama "cascadas modificadas": [11] 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 en cascada incremental". [19]
El modelo final de Winston W. Royce , su intención de mejorar su "modelo en cascada" inicial, ilustró que la retroalimentación podría (debería, y a menudo conduciría) desde la prueba del código hasta el diseño (ya que las pruebas del código descubrieron fallas en el diseño) y desde diseño de nuevo 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 insatisfactorios/indiseñables). En el mismo artículo, Royce también abogaba por grandes cantidades de documentación, haciendo el trabajo "el doble si es posible" (un sentimiento similar al de Fred Brooks , famoso por escribir Mythical Man Month, un influyente libro sobre gestión de proyectos de software , que defendía la planificación para "tirar uno"), e involucrar al cliente tanto como sea posible (un sentimiento similar al de la programación extrema ).
Las notas de Royce sobre el modelo final son:
