Modelo de cascada

El modelo en cascada es un desglose de las actividades del proyecto 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. El enfoque es típico para ciertas áreas del diseño de ingeniería. En el desarrollo de software, tiende a estar entre los enfoques menos iterativos y flexibles, ya que el progreso fluye principalmente 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, pruebas, despliegue y mantenimiento. El modelo de cascada es el enfoque SDLC más antiguo que se utilizó en el desarrollo de software.

El modelo de desarrollo en cascada se originó en las industrias de fabricación y construcción, 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. Cuando se adoptó por primera vez para el desarrollo de software, no había alternativas reconocidas para el trabajo creativo basado en el conocimiento.

Historia

La primera presentación conocida que describe el uso de tales fases en la ingeniería de software fue realizada por Felix Torres y Herbert D. Benington en el Simposio sobre métodos de programación avanzada para computadoras digitales el 29 de junio de 1956. Esta presentación fue sobre el desarrollo de software para SAGE. En 1983, el artículo se volvió a publicar con un prólogo de Benington que explica que las fases se organizaron a propósito de acuerdo con la especialización de las tareas y señala que el proceso no se llevó a cabo estrictamente de arriba hacia abajo, sino que dependía de un prototipo..

Aunque el término "cascada" no se utiliza en el documento, el primer diagrama formal detallado del proceso más tarde conocido como el "modelo de cascada" a menudo se cita como un artículo de 1970 de Winston W. Royce. Sin embargo, también sintió que tenía fallas importantes derivadas del hecho de que las pruebas solo se realizaron al final del proceso, lo que describió como "arriesgado e invita al fracaso". El resto de su documento introdujo cinco pasos que consideró necesarios para "eliminar la mayoría de los riesgos de desarrollo" asociado con el enfoque de cascada inalterado.

Los cinco pasos adicionales de Royce (que incluían escribir la 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 una "cascada& #34; Acercarse.

El primer uso del término "cascada" pudo haber estado en un artículo de 1976 de Bell y Thayer.

En 1985, el Departamento de Defensa de los Estados Unidos capturó este enfoque en DOD-STD-2167A, sus estándares para trabajar con contratistas de desarrollo de software, que establecían que "el contratista implementará un ciclo de desarrollo de software que incluya lo siguiente seis fases: análisis de requisitos de software, diseño preliminar, diseño detallado, codificación y pruebas unitarias, integración y pruebas.

Modelo

En el modelo de cascada original de Royce, se siguen las siguientes fases en orden:

1. Requisitos de sistema y software: capturado en un documento de requisitos de producto
2. Análisis: resultado en modelos, esquemas y reglas de negocio
3. Diseño: resultado de la arquitectura de software
4. Codificación: desarrollo, prueba e integración del software
5. Pruebas: el descubrimiento sistemático y depuración de defectos
6. Operaciones: instalación, migración, apoyo y mantenimiento de sistemas completos

Por lo tanto, el modelo de cascada sostiene que uno debe pasar a una fase solo cuando se revisa y verifica su fase anterior.

Varios modelos de cascada modificados (incluido el modelo final de Royce), sin embargo, pueden incluir variaciones leves o importantes en este proceso. 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.

Argumentos de apoyo

El tiempo que se dedica al principio del ciclo de producción de software puede reducir los costos en etapas posteriores. Por ejemplo, un problema que se encuentra en las primeras etapas (como la especificación de requisitos) es más económico de solucionar que el mismo error que se encuentra más adelante en el proceso (por un factor de 50 a 200).

En la práctica común, las metodologías en cascada dan como resultado un cronograma de proyecto con 20 a 40 % del tiempo invertido en las dos primeras fases, 30 a 40 % del tiempo en codificación y el resto dedicado a pruebas e implementación. La organización real del proyecto debe estar altamente estructurada. La mayoría de los proyectos medianos y grandes incluirán un conjunto detallado de procedimientos y controles, que regulan todos los procesos del proyecto.

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) además del código fuente. En metodologías diseñadas y documentadas menos a fondo, 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 de Big Design Up Front y el modelo en cascada), los nuevos miembros del equipo o incluso los equipos completamente nuevos deberían poder familiarizarse leyendo los documentos.

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 lo 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.

Crítica

Es posible que los clientes no sepan exactamente cuáles son sus requisitos antes de ver el software en funcionamiento y, por lo tanto, cambien sus requisitos, lo que lleva a rediseñar, volver a desarrollar, volver a probar y aumentar los costos.

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 tiene en cuenta las restricciones, los requisitos o los problemas recién descubiertos.

Las organizaciones pueden intentar lidiar con 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 y la programación de sistemas. 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 riesgo Reducción".

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 publicado en 1994, que fomenta la adquisición evolutiva y < i>Desarrollo iterativo e incremental.

Mientras que los defensores del desarrollo ágil de software argumentan que el modelo en cascada es un proceso ineficaz para desarrollar software, algunos escépticos sugieren que el modelo en cascada es un argumento falso que se usa únicamente para comercializar metodologías de desarrollo alternativas.

Las fases de Rational Unified Process (RUP) reconocen la necesidad programática de hitos, para mantener un proyecto encaminado, pero alientan las iteraciones (especialmente dentro de las Disciplinas) dentro de las Fases. Las fases de RUP a menudo se denominan "en cascada".

Modelos de cascada modificados

En respuesta a los problemas percibidos con el "puro" modelo de cascada, se han introducido muchos 'modelos de cascada modificados. Estos modelos pueden abordar algunas o todas las críticas de los "puros" modelo de cascada

Estos incluyen los modelos de desarrollo rápido que Steve McConnell llama "cascadas modificadas": el "modelo sashimi" de Peter DeGrace; (cascada con fases superpuestas), cascada con subproyectos y cascada con reducción de riesgos. Otras combinaciones de modelos de desarrollo de software como "modelo de cascada incremental" también existen.

Modelo final de Royce

Modelo final de Royce

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) conducir desde la prueba del código hasta el diseño (como prueba del código descubrió fallas en el diseño) y desde el diseño hasta la especificación de requisitos (ya que los problemas de diseño pueden requerir la eliminación de requisitos conflictivos o insatisfactorios/no designables). En el mismo documento, Royce también abogó por grandes cantidades de documentación, haciendo 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 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:

1. Diseño completo del programa antes de que comience el análisis y la codificación
2. La documentación debe ser actualizada y completa
3. Hacer el trabajo dos veces si es posible
4. Los exámenes deben ser planificados, controlados y supervisados
5. Involucrar al cliente