beneficios del modelo en cascada

1. República Bolivariana De Venezuela
Instituto Universitario Politécnico
“Santiago Mariño”
Extensión Porlamar (Sede Genovés)
Escuela: Ingeniería en Sistemas
ENSAYO.
“Beneficios Del Modelo En Cascada”
Profesora. Realizado por:
Yasmin Marcano. Francisco Gómez.
C.I.26.243.271.
Sección “4G”
Porlamar, Marzo de 2017.

2. BENEFICIOS DEL MODELO EN CASCADA
En primer lugar, el desarrollo en cascada en la ingeniería del software, es una
perspectiva metodológica que propone una serie de etapas, sucesivas, que representan el
proceso para el desarrollo de software, en este modelo para iniciar con la siguiente etapa es
necesario haber culminado la etapa anterior a esta. Por ejemplo, no podríamos empezar a
programar, hasta haber completado totalmente el diseño técnico. Cabe destacar que fue este
modelo fue el primero en crearse y además es la base de todos los demás modelos de ciclo
de vida.
Todos los proyectos de software siempre han tenido la posibilidad de fallar; en los
años 90 hubo un auge en la necesidad de crear software, con la finalidad de reducir los riesgos
de que en su desarrollo hubiera fallos, se originó esta metodología. El modelo de cascada
original, publicada por Winston W. Royce en 1970, no fue presentado con el nombre que hoy
día conocemos, Royce presentó el modelo como un modelo defectuoso, con fallas, sin
embargo debido a las diversas ventajas que este enfoque hacia el diseño de software para le
época y la aplicación presentada, pronto se hizo muy popular en el mundo de desarrollo de
software. En los años 90 sobre todo, la forma de trabajo de las consultoras y fábricas de
software, originaron que la especialización, y el hecho de contar con personal poco
experimentado por otro, esta técnica fuera necesaria y efectiva. Esta técnica fue muy efectiva
para las condiciones que se dieron lugar en ese momento.
Principalmente este método asume que en cada etapa ya deberíamos estar preparados
para la siguiente, y esto porque: El cliente necesita una documentación estable; otros
proveedores también necesitan una documentación estable; ya se tienen establecidos equipos
diferenciados para el desarrollo del software; además, este modelo supone que los cambios
generan costos adicionales.
Las etapas que conforman este modelo son las siguientes: Análisis de los
requerimientos. Diseño del sistema. Diseño del programa. Codificación. Pruebas.
Implementación del programa. Mantenimiento.
Dadas las necesidades actuales en el desarrollo de sistemas, donde los requerimientos
son cambiantes, y los diseños complicados de conceptualizar de forma total, este tipo de

3. metodología de ciclo de vida es algo obsoleto, ya que es muy rígido para aceptar constantes
cambios, los proyectos raramente siguen el proceso lineal tal como se definía originalmente
el ciclo de vida, es difícil que el cliente exponga explícitamente todos los requisitos al
principio; sin embargo, es perfectamente aplicable a casos determinados, y aunque
imperfecto, tiene sus usos en nuestros días, y sigue siendo utilizado. Este modelo puede ser
apropiado, en general, para proyectos cuyos requisitos no sean variantes, y donde es posible
y probable que los diseñadores predigan totalmente áreas de problema del sistema y
produzcan un diseño correcto antes de que empiece la implementación, asegurando que no
habría cambios futuros.
El modelo de cascada es un modelo lineal y, cabe destacar, que los modelos lineales
son las más sencillos de entender y simples para ser implementados. Funciona bien para
proyectos pequeños donde los requisitos están bien entendidos.
Su rigidez trae algún que otro beneficio, como que debido a la rigidez del modelo es
fácil de gestionar ya que cada fase tiene entregables, sin embargo son mayores las desventajas
que trae, como la intolerancia a cambios.
La cantidad de recursos necesarios para poder implementar este modelo es mínimo.
Una gran ventaja del modelo de cascada es que la documentación se produce en cada etapa
del desarrollo del modelo de cascada. Esto hace que la comprensión del producto diseñar
procedimiento más sencillo.
Aunque hoy en día este modelo siga siendo utilizado, ha pasado a convertirse en un
modelo obsoleto, sus características no cubren las necesidades de desarrollo de hoy en día,
siendo más eficaces las metodologías agiles. Sin embargo, este modelo fue la base para la
existencia de los modelos actuales, y aunque obsoleto, dada su estabilidad y simplicidad aun
es aplicable a situaciones muy particulares.