El modelo en cascada es una descomposición de las actividades de desarrollo en fases secuenciales lineales , lo que significa que cada fase se transmite a las demás, donde cada fase depende de los entregables de la anterior y corresponde a una especialización de tareas. [1]
Este enfoque es típico para 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]
El modelo en cascada es el primer enfoque del ciclo de vida del desarrollo de sistemas ( SDLC ) utilizado en el desarrollo de software. [3]
El modelo de desarrollo en cascada se originó en las industrias manufactureras y de construcción , [ cita requerida ] donde los entornos físicos altamente estructurados significaban que los cambios de diseño se volvían prohibitivamente costosos mucho antes en el proceso de desarrollo. [ cita requerida ] Cuando se adoptó por primera vez para el desarrollo de software, no había alternativas reconocidas para el trabajo creativo basado en el conocimiento. [4]
La primera presentación conocida que describe 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 trataba sobre el desarrollo de software para SAGE . En 1983, Benington volvió a publicar su artículo con un prólogo que explicaba que las fases se organizaban a propósito según la especialización de las tareas y señalaba que el proceso no se realizaba de hecho de manera estricta de arriba hacia abajo, sino que dependía de un prototipo. [6] [ se necesita una mejor fuente ]
Aunque el término "cascada" no se utiliza en el documento, el primer diagrama detallado formal del proceso conocido posteriormente como "modelo de cascada" se cita a menudo [7] como procedente de un artículo de 1970 de Winston W. Royce . [8] [9] [10] Sin embargo, comentó que tenía importantes defectos derivados de que las pruebas solo se realizaban al final del proceso, lo que describió como "arriesgado y [invitante] al fracaso". [8] El resto de su documento introdujo cinco pasos que consideró necesarios para "eliminar la mayoría de los riesgos de desarrollo" asociados con el enfoque de cascada inalterado. [8]
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 para 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] [ se necesita una mejor fuente ]
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]
Aunque Royce nunca recomendó ni describió un modelo de cascada, [16] critica la adherencia rígida a las siguientes fases:
Así, el modelo en cascada sostiene que uno debe pasar a una fase sólo cuando su fase anterior haya sido revisada y verificada.
Sin embargo, varios modelos de cascada modificados (incluido el modelo final de Royce) pueden incluir variaciones leves o importantes en este proceso. [8] Estas variaciones incluyen volver al ciclo anterior después de que se encuentran fallas aguas abajo, o volver a la fase de diseño si las fases aguas abajo se consideran insuficientes.
El tiempo invertido en las primeras etapas del ciclo de producción de software puede reducir los costos en etapas posteriores. Por ejemplo, es más económico solucionar un problema detectado en las primeras etapas (como la especificación de requisitos) que solucionar el mismo error detectado más adelante en el proceso (por un factor de 50 a 200). [17]
En la práctica habitual, las metodologías en cascada dan como resultado un cronograma de proyecto en el que entre el 20% y el 40% del tiempo se invierte en las dos primeras fases, entre el 30% y el 40% en la codificación y el resto en las pruebas y la implementación. Como la organización 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. [18] [ verificación fallida ]
Otro argumento a favor del modelo en cascada es que pone énfasis en la documentación (como los documentos de requisitos y de diseño) así como en el código fuente . [ cita requerida ] En metodologías menos diseñadas y documentadas, se pierde conocimiento si los miembros del equipo se van antes de que se complete el proyecto, y puede ser difícil que un proyecto se recupere de la pérdida. Si existe un documento de diseño en pleno funcionamiento (como es la intención del gran diseño inicial y del modelo en cascada), los nuevos miembros del equipo y los nuevos equipos deberían poder familiarizarse con el proyecto leyendo los documentos. [19]
El modelo en cascada ofrece un enfoque estructurado; el modelo en sí mismo progresa linealmente a través de fases discretas, fácilmente comprensibles y explicables, y por lo tanto es fácil de entender. También proporciona hitos fácilmente identificables en el proceso de desarrollo, y a menudo se utiliza como un ejemplo inicial de un modelo de desarrollo en muchos textos y cursos de ingeniería de software. [20]
De manera similar, la simulación puede desempeñar un papel valioso dentro del modelo en cascada. Al crear simulaciones matemáticas o computarizadas 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 refinar 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 conozcan los requisitos exactos antes de ver el software en funcionamiento y, por lo tanto, cambien sus requisitos más adelante, lo que genera rediseño, rediseño y nuevas pruebas, y mayores costos. [21]
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 revisar el diseño inicialmente puede aumentar la eficiencia en comparación con un diseño que no está diseñado para tener en cuenta las restricciones, los requisitos o los problemas recién descubiertos. [22]
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 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, [23] ya que la implementación de cualquier sistema no trivial a menudo expondrá problemas y casos extremos que el analista de sistemas no consideró.
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 . [24]
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".
Entre ellos se encuentran los modelos de desarrollo rápido que Steve McConnell denomina "cascadas modificadas": [17] el "modelo sashimi" de Peter DeGrace (cascada con fases superpuestas), la cascada con subproyectos y la cascada con reducción de riesgos. También existen otras combinaciones de modelos de desarrollo de software, como el "modelo de cascada incremental". [25]
El modelo final de Winston W. Royce , su mejora prevista sobre su "modelo en cascada" inicial, ilustró que la retroalimentación podría (debería, y a menudo lo haría) llevar de la prueba de código al diseño (ya que la prueba de código descubre fallas en el diseño) y del 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 insatisfacibles/no diseñables). [ cita requerida ] En el mismo artículo, Royce también abogó por grandes cantidades de documentación, hacer el trabajo "dos veces si es posible" (un sentimiento similar al de Fred Brooks , famoso por escribir Mythical Man Month, un libro influyente en la gestión de proyectos de software , que abogó por planificar para "tirar uno a la basura"), 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 las siguientes:
