El modelo en cascada es una descomposición de las actividades de desarrollo en fases secuenciales lineales , lo que significa que se transmiten unas a otras, donde cada fase depende de los entregables de la anterior y corresponde a una especialización de tareas. [1] El enfoque es típico para ciertas áreas de 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 SDLC que se utilizó 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, el artículo fue republicado con un prólogo de Benington que explicaba que las fases estaban organizadas a propósito de acuerdo con 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 un artículo de 1970 de Winston W. Royce . [8] [9] [10] Sin embargo, también sentía que tenía importantes defectos derivados del hecho de que las pruebas solo se realizaban al final del proceso, lo que describió como "arriesgado e invita 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 se haya revisado y verificado 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. [8] Estas variaciones incluían volver al ciclo anterior después de encontrar fallas aguas abajo, o volver a la fase de diseño si las fases aguas abajo se consideraban 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. 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. [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 o incluso equipos totalmente nuevos deberían poder familiarizarse 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. Tal vez sea por esta razón que el modelo en cascada se utiliza como un ejemplo inicial de un modelo de desarrollo en muchos textos y cursos de ingeniería de software. [20]
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 sepan exactamente cuáles son sus requisitos antes de ver un software en funcionamiento y, por lo tanto, cambien sus requisitos, lo que lleva a un rediseño, un nuevo desarrollo y nuevas pruebas, y a un aumento de los 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 es mejor revisar el diseño que persistir en un diseño que no tenga en cuenta ninguna restricción, requisito o problema recientemente descubierto. [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] 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". [17]
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 intención de mejorar 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 nuevamente a la especificación de requisitos (ya que los problemas de diseño pueden requerir la eliminación de requisitos conflictivos o insatisfactorios/no diseñables). 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:
pobre en agua;diseño