Modelo de cascada

Modelado de un proyecto en fases secuenciales

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 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 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]

Historia

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 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 un artículo de 1970 de Winston W. Royce . [8] [9] [10] Sin embargo, también sentía 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". [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]

Modelo

Aunque Royce nunca recomendó ni describió un modelo de cascada, [16] critica la adherencia rígida a las siguientes fases:

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

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.

Argumentos de apoyo

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

Crítica

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 las restricciones, requisitos o problemas recientemente 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] 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]

Modelos de cascada modificados

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 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) 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:

  1. Diseño completo del programa antes de comenzar el análisis y la codificación.
  2. La documentación debe estar actualizada y completa.
  3. Haz el trabajo dos veces si es posible
  4. Las pruebas deben planificarse, controlarse y monitorearse.
  5. Involucrar al cliente

Véase también

Referencias

  1. ^ ab Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). "El modelo en cascada en el desarrollo a gran escala". En Bomarius, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka (eds.). Mejora de procesos de software centrada en el producto . Apuntes de clase sobre procesamiento de información empresarial. Vol. 32. Berlín, Heidelberg: Springer . págs. 386–400. Código Bibliográfico :2009pfsp.book..386P. doi :10.1007/978-3-642-02152-7_29. ISBN: 978-3-642-02152-7.
  2. ^ Tom Gilb . "Entrega evolutiva versus el 'modelo de cascada'"". Notas de ingeniería de software de ACM SIGSOFT . 10 (3): 49–61. doi :10.1145/1012483.1012490.Icono de acceso abierto
  3. ^ Linda Sherrell (2013). "Modelo de cascada". Enciclopedia de ciencias y religiones (ALC Runehov; L. Oviedo (Eds.)) . Dordrecht , Países Bajos: Springer : 2343–2344. doi :10.1007/978-1-4020-8265-8_200285. ISBN 978-1-4020-8264-1.
  4. ^ Andreas P. Schmidt; Christine Kunzmann (16 de septiembre de 2014). Diseño para la maduración del conocimiento: desde el software impulsado por el conocimiento hasta el apoyo a la facilitación del desarrollo del conocimiento . i-KNOW '14: Actas de la 14.ª Conferencia internacional sobre tecnologías del conocimiento y negocios impulsados ​​por datos. ACM . págs. 1–7. doi :10.1145/2637748.2638421.
  5. ^ Estados Unidos, Navy Mathematical Computing Advisory Panel (29 de junio de 1956), Simposio sobre métodos avanzados de programación para computadoras digitales , [Washington, DC]: Oficina de Investigación Naval, Departamento de la Marina, OCLC  10794738
  6. ^ Benington, Herbert D. (1 de octubre de 1983). "Producción de grandes programas informáticos" (PDF) . IEEE Annals of the History of Computing . 5 (4). Departamento de Actividades Educativas del IEEE: 350–361. doi :10.1109/MAHC.1983.10102. S2CID  8632276. Consultado el 21 de marzo de 2011 .Archivado el 18 de julio de 2011 en Wayback Machine .
  7. ^ Larman, Craig; Basili, Victor (junio de 2003). "Desarrollo iterativo e incremental: una breve historia" (PDF) . Computer . 36 (6): 47–56. doi :10.1109/MC.2003.1204375.
  8. ^ abcd Royce, Winston (1970), "Gestión del desarrollo de grandes sistemas de software" (PDF) , Actas de IEEE WESCON , 26 (agosto): 1–9
  9. ^ "Cascada". Universidad de Bremen - Matemáticas y Ciencias de la Computación .
  10. ^ Abbas, Noura; Gravell, Andrew M.; Wills, Gary B. (2008). "Raíces históricas de los métodos ágiles: ¿de dónde surgió el "pensamiento ágil"?" (PDF) . En Abrahamsson, Pekka; Baskerville, Richard; Conboy, Kieran; Fitzgerald, Brian; Morgan, Lorraine; Wang, Xiaofeng (eds.). Procesos ágiles en ingeniería de software y programación extrema . Apuntes de clase sobre procesamiento de información empresarial. Vol. 9. Berlín, Heidelberg: Springer . págs. 94–103. doi :10.1007/978-3-540-68255-4_10. ISBN . 978-3-540-68255-4.
  11. ^ Conrad Weisert, Metodología en cascada: ¡no existe tal cosa!
  12. ^ Lineberger, Rob (25 de abril de 2024). Heredar Agile: Guía para profesionales de TI sobre cómo gestionar el desarrollo de software en un mundo post-Agile. Durham, Carolina del Norte: Sandprint Press. pág. 36. ISBN 9798989149605.
  13. ^ Bell, Thomas E. y TA Thayer. Requisitos de software: ¿son realmente un problema? Actas de la 2.ª conferencia internacional sobre ingeniería de software. IEEE Computer Society Press, 1976.
  14. ^ ab DOD-STD-2167 - Norma militar: Desarrollo de software para sistemas de defensa" . Departamento de Defensa, Estados Unidos de América. 1985-06-04. pág. 11.
  15. ^ "Desarrollo de software para sistemas de defensa estándar militares" (PDF) .
  16. ^ Lineberger, Rob (25 de abril de 2024). Heredar Agile: Guía para profesionales de TI sobre cómo gestionar el desarrollo de software en un mundo post-Agile. Durham, Carolina del Norte: Sandprint Press. pág. 37. ISBN 9798989149605.
  17. ^ abc McConnell, Steve (1996). Desarrollo rápido: cómo dominar los cronogramas de software salvajes. Microsoft Press. ISBN 1-55615-900-5.
  18. ^ "Modelo de desarrollo de software en cascada". 5 de febrero de 2014. Consultado el 11 de agosto de 2014 .
  19. ^ Arcisphere Technologies (2012). "Tutorial: El ciclo de vida del desarrollo de software (SDLC)" (PDF) . Consultado el 13 de noviembre de 2012 .
  20. ^ Hughey, Douglas (2009). "Comparación del análisis y diseño de sistemas tradicionales con metodologías ágiles". Universidad de Missouri – St. Louis . Consultado el 11 de agosto de 2014 .
  21. ^ Parnas, David L.; Clements, Paul C. (1986). "Un proceso de diseño racional: cómo y por qué fingirlo" (PDF) . IEEE Transactions on Software Engineering (2): 251–257. doi :10.1109/TSE.1986.6312940. S2CID  5838439. Consultado el 21 de marzo de 2011 .
  22. ^ McConnell, Steve (2004). Code Complete, 2.ª edición. Microsoft Press. ISBN 1-55615-484-4.
  23. ^ Ensmenger, Nathan (2010). Los chicos de la informática toman el control . MIT Press. pág. 42. ISBN 978-0-262-05093-7.
  24. ^ Larman, Craig; Basili, Victir (2003). "Desarrollo iterativo e incremental: una breve historia". IEEE Computer . 36 (6) (edición de junio): 47–56. doi :10.1109/MC.2003.1204375. S2CID  9240477.
  25. ^ "Metodología: métodos de diseño".
  • Comprender los pros y contras del modelo en cascada del desarrollo de software
  • Modelos de ciclo de vida del proyecto: en qué se diferencian y cuándo utilizarlos
  • Cruzando la cascada con el RUP de Philippe Kruchten
  • CSC e IBM Rational se unen para ofrecer C-RUP y respaldar un cambio empresarial rápido
  • c2:Cascada
  • [1]
Obtenido de "https://es.wikipedia.org/w/index.php?title=Modelo_de_cascada&oldid=1249915152"