modelo de cascada
El modelo en cascada es un desglose de las actividades del proyecto en fases secuenciales lineales , 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 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 , desplieguey mantenimiento [2] .
El modelo de desarrollo en cascada se originó en las industrias de fabricación y construcción [ cita requerida ] ; 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 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. [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 [ cita requerida ] . [4] 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. . [3]
Aunque el término "cascada" no se usa en el documento, el primer diagrama formal detallado del proceso, más tarde conocido como el "modelo de cascada", a menudo [ cita requerida ] 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 ocurrieron al final del proceso, que describió como "arriesgado e invita al fracaso". [5] 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. [5]
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 un enfoque de "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 ]
