El documento describe el modelo de ciclo de vida en cascada para el desarrollo de software. Este modelo implica que cada etapa del desarrollo debe completarse antes de pasar a la siguiente, lo que simplifica la gestión del proyecto. Sin embargo, también puede llevar al fracaso si no se especifican correctamente los requisitos iniciales o si surgen nuevos requisitos. El documento también discute algunos problemas comunes con este enfoque y las ventajas de los modelos iterativos.

1. REPÚBLICA BOLIVARIANA DE VENEZUELA
INSTITUTO UNIVERSITARIO POLITÉCNICO
“SANTIAGO MARIÑO”
EXTENSIÓN PORLAMAR
Sistemas I
Bachiller:
Mariannys Bermúdez
Porlamar, 12 de marzo 2017

2. Modelo de Ciclo de Vida en Cascada
Desde el inicio el ciclo de vida de un plan software incluye todos los
trabajos que se realizan sobre él desde que se especifican las particulares
que debe tener, hasta que se conserva en operación. A veces (aunque no
será éste nuestro caso) se contienen en el ciclo de vida las transformaciones
que pueden ejecutar al sistema para acomodar a nuevas especificaciones.
Podría pensarse que el ciclo de vida de un programa no tiene por qué seguir
un desarrollo "lineal", entendiendo como tal una sucesión de etapas.
Uno de estos modelos del ciclo de vida, quizás el más ampliamente
utilizado, es el del desarrollo en cascada. En él, cada etapa deja el camino
preparado para la siguiente, de forma que esta última no debe comenzar
hasta que no ha acabado aquélla. De esta forma, se reduce mucho la
complejidad de la gestión, ya que basta con no dar por terminada una etapa
hasta que haya cumplido totalmente con sus objetivos.
En cuantos los beneficios que se debe tener en cuenta que un proyecto
sigue una secuencia lineal, esto crea una mala implementación del modelo,
lo cual hace que lo lleve al fracaso. Para eso tenemos que ver el que no se
siga una secuencia lineal, no es error del modelo, sino del garante de
proteger. no suele establecer al principio todos los requisitos necesarios.
Esto provoca que el modelo no se ajuste al gran número de nuevos
requisitos y cambios en otros requisitos existentes, que se van a producir. Sí,
vale, pero hay que matizar que la culpa no es del cliente. Un buen analista
debe llegar a conocer el negocio del cliente, y debe extraer sus necesidades.
Si nos tenemos que basar en lo que nos cuenta el cliente de forma exclusiva,
estamos listos (y además, estamos pagando innecesariamente un analista).
El modelo de ciclo de vida en cascada no nos indica nada acerca de la
relación contractual existente entre el cliente y la organización encargada del
desarrollo de software. Desde el punto de vista de una empresa de desarrollo
de software, formalizar la firma de un contrato al final de la etapa de análisis,
por ejemplo, puede ayudar a reducir el riesgo que supone elaborar un
presupuesto cuando aún no se dispone de toda la información necesaria
para que la estimación del esfuerzo requerido por el proyecto sea lo
suficientemente precisa. Este tipo de contrato obliga a que el cliente se haga
cargo de los costes adicionales ocasionados por cambios en los
requerimientos, mientras que la empresa de desarrollo de software deberá
asumir los gastos ocasionados si el producto finalmente entregado no
cumple todas las condiciones pactadas a la firma del contrato.
Un modelo contractual como el descrito en el párrafo anterior no
siempre resulta aceptable para el cliente, que puede verse obligado a invertir
dinero a cambio de nada. Esto podría pasar si, tras la etapa de análisis, el
proyecto se desestima por no ser técnica o económicamente viable. Es más,
si el cliente acepta a regañadientes la firma de un contrato al final de la etapa

3. de análisis, la imagen de la empresa desarrolladora de software puede verse
seriamente deteriorada en cuanto surja cualquier tipo de problema.
Para limar las asperezas que pueden surgir en la relación cliente-
proveedor y mejorar el rendimiento del equipo del proyecto, hoy en día se
suele recurrir a modelos iterativos como los que se describirán a
continuación.
El diseño de este tipo de ciclo es un proceso multipaso que se centra en
cuatro atributos diferentes de los programas: estructura de datos,
arquitectura del software, detalle del proceso y caracterización de las
interfases. El proceso de diseño representa los requerimientos en una forma
que permita la codificación del producto (además de una evaluación de la
calidad previa a la etapa de codificación). Al igual que los requerimientos, el
diseño es documentado y se convierte en parte del producto de software.
El ciclo de vida clásico es el paradigma más viejo y el más ampliamente
usado en la ingeniería del software. Sin embargo, su aplicabilidad en muchos
campos ha sido cuestionada. Entre los problemas que aparecen cuando se
aplica el modelo cascada están:
Los proyectos raramente siguen el flujo secuencial que el modelo
propone. La iteración siempre es necesaria y está presente, creando
problemas en la aplicación del modelo.
A menudo es difícil para el cliente poder especificar todos los
requerimientos explícitamente. El modelo de vida del software clásico
requiere esto y presenta problemas acomodando la incertidumbre natural
que existe al principio de cualquier proyecto.
El cliente debe ser paciente. Una versión funcional del sistema no
estará disponible hasta tarde en la duración del desarrollo. Cualquier error o
malentendido, si no es detectado hasta que el programa funcionando es
revisado, puede ser desastroso.
Cada uno de estos problemas es real. Sin embargo, el modelo clásico
del ciclo de vida del software tiene un lugar bien definido e importante en los
trabajos de ingeniería del software. Provee un patrón dentro del cual encajan
métodos para el análisis, diseño, codificación y mantenimiento.
La metodología de cascada ordena rigurosamente las etapas del ciclo
del software, es decir en este modelo se tienen que terminar las fases en un
orden, para poder pasar a la siguiente etapa. Este modelo es el mas usado
en la actualidad; El modelo de cascada es exitoso cuando se tienen bien
específicos los requerimientos del software y se conozcan las herramientas a
utilizar. El modelo de cascada tarda mucho tiempo en resolver un software,
ya que hasta que no se tenga bien el software, no se opera el software
Lo que puedo mencionar es que el modelo cascada es una de las
metodologías que al llevarse a cabo se debe de llevar a cabo fase por la fase
el modelo de cascada nos permite realizar una organización más fácil de
comprender tratando