El documento describe el modelo de ciclo de vida en cascada para el desarrollo de software. Este modelo implica que el desarrollo siga una secuencia de fases, incluyendo la ingeniería y análisis del sistema, el análisis de requisitos del software, el diseño, la codificación, las pruebas y el mantenimiento. Cada fase tiene objetivos definidos y contribuye a la siguiente. Sin embargo, este enfoque puede llevar a retrasos significativos si una fase falla o si los requisitos no están claros desde el inicio.

1. INSTITUTO UNIVERSITARIO
POLITECNICO “SANTIAGO MARIÑO”
EXTENSION-PORLAMA
ESCUELA DE SISTEMAS
CODIGO: 47
BACHILLER:
Luis Caraballo C.I: 24.695.744
Porlamar, marzo de 2017

2. Modelo de Ciclo de Vida en Cascada
El modelo de cascada es el más sencillo de los modelos y se utiliza como principal
bloque de construcción para los demás módulos de ciclo de vida. Este ciclo convencional
de una ingeniería y su visión es muy simple: el desarrollo de software se debe realizar
siguiendo una secuencia de fases. Cada etapa tiene un conjunto de metas bien definidas
y las actividades dentro de cada una contribuyen a la satisfacción de metas de esa fase
o quizás a una su secuencia de metas de la misma.
Él método de la cascada es considerado como el enfoque clásico para el ciclo de
vida del desarrollo de sistemas, se puede decir que es un método puro que implica un
desarrollo rígido.
El arquetipo del ciclo de vida abarca las siguientes actividades:
1. Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un
sistema mayor, el trabajo comienza estableciendo los requisitos de todos los
elementos del sistema y luego asignando algún subconjunto de estos requisitos al
software.
2. Análisis de los requisitos del software: el proceso de recopilación de los requisitos
se centra e intensifica especialmente en el software. El ingeniero de software debe
comprender el ámbito de la información del software, así como la función, el
rendimiento y las interfaces requeridas.
3. Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa;
la estructura de los datos, la arquitectura del software, el detalle procedimental y
la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una
representación del software con la calidad requerida antes de que comience la
codificación.
4. Codificación: el diseño debe traducirse en una forma legible para la máquina. Si el
diseño se realiza de una manera detallada, la codificación puede realizarse
mecánicamente.
5. Prueba: una vez que se ha generado el código comienza la prueba del programa.
La prueba se centra en la lógica interna del software y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requieren.
6. Mantenimiento: el software sufrirá cambios después de que se entrega al cliente.
Los cambios ocurrirán debidos a que se haya encontrado errores, a que el software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos
periféricos) o a que el cliente requiera ampliaciones funcionales o del rendimiento.

3. La metodología en cascada es esencialmente:
 El inicio y el alcance del proyecto
 La planificación del proyecto (calendario, recursos necesarios, costo)
 Definición de las necesidades del negocio y el análisis en detalle dela solución
 La creación de la solución
 Prueba que la solución funciona. La entrega de la solución a su público objetivo
 Cierre del proyecto.
Lamentablemente el uso de este modelo del desarrollo del software pone en jaque
la integridad mientras se construye el sistema, ya que si se falla en una etapa, se ve
obligado a reiniciar prácticamente el proceso de construcción, otra de las situaciones
que pueden llevar al fracaso es precisamente una de sus características esenciales,
avanzar hasta que se concluya la etapa anterior, viéndolo de este modo, puede atrasar
de manera significativa el proceso de desarrollo de software, quizá tome mucho más
tiempo del que realmente necesite, otra desventaja es el mantenimiento del software,
ya que se involucra la repetición de sus pasos que se llevaron a cabo para la constitución
del software volviendo este método muy tedioso, es recomendable utilizar este modelo
siempre y cuando se conozca los requerimientos.