El documento describe dos modelos de ciclo de vida de software: el modelo de cascada y el modelo en espiral. El modelo de cascada consiste en 7 etapas secuenciales: especificación de requisitos, diseño, implementación, integración, pruebas, despliegue y mantenimiento. El modelo en espiral enfatiza el análisis de riesgos a través de iteraciones que incluyen la planificación, análisis de riesgos e implementación.

1. Actividad 20: realizar un ensayo que contenga portada, índice,
introducción, definición del problema, planteamiento de solución,
justificación de modelo, de ciclo de vida, así como su diagrama,
conclusión y referencias.

2. INDICE
Portada…………………………………………………………… 1
Índice……………………….……………………………………….2
Introducción………………………………………………………3
Modelo de cascada……………………………………………..4
Modelo de espiral………………………………………………..5
Bibliografías…………………………………………………………7
INTRODUCCION:
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren
durante el desarrollo de software, intenta determinar el orden de las etapas
involucradas y los criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida del software:
Describe las fases principales de desarrollo de software.
Define las fases primarias esperadas de ser ejecutadas durante esas fases.
Ayuda a administrar el progreso del desarrollo, y
Provee un espacio de trabajo para la

3. MODELO DE CASCADA
El modelo de cascada define las siguientes etapas que deben cumplirse
de forma sucesiva:
1.
2.
3.
4.
5.
6.
7.
Especificación de requisitos
Diseño del software
Construcción o Implementación del software
Integración
Pruebas (o validación)
Despliegue (o instalación)
Mantenimiento
Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza
una fase, comienza la otra. En ocasiones se realiza una revisión antes de
iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que
puede incluir un proceso de control formal de cambio). Las revisiones
también se utilizan para asegurar que la fase anterior ha sido totalmente
finalizada; los criterios para completar una fase se conocen
frecuentemente con el término inglés "gate" (puerta). Este modelo
desaconseja revisitar y revisar fases que ya se han completado. Esta falta
de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de
los defensores de modelos más flexibles.
MODELO ESPIRAL
La principal características del modelo en espiral es la gestión de riesgos de
forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988
por Barry Boehm, combinando algunos aspectos clave de las
metodologías del modelo de cascada y del desarrollo rápido de
aplicaciones, pero dando énfasis en un área que para muchos no jugó el
papel que requiere en otros modelos: un análisis iterativo y concienzudo de
los riesgos, especialmente en el caso de sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a través de algunas
iteraciones con el diagrama de los cuatro cuadrantes representativos de
las siguientes actividades:
1. crear planes con el propósito de identificar los objetivos del
software,seleccionados para implementar el programa y clarificar las
restricciones en el desarrollo del software;
2. Análisis de riesgos: una evaluación analítica de programas
seleccionados, para evaluar como identificar y eliminar el riesgo;

4. 3. la implementación del proyecto: implementación del desarrollo del
software y su pertinente verificación;
Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las
condiciones de las opciones y limitaciones para facilitar la reutilización de
software, la calidad del software puede ayudar como una meta propia en
la integración en el desarrollo del producto. Sin embargo, el modelo en
espiral tiene algunas limitaciones, entre las que destacan:
1. El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de
clientes que acepten este análisis y actúen en consecuencia. Para
ello es necesaria confianza en los desarrolladores así como la
predisposición a gastar más para solventar los temas, por lo cual este
modelo se utiliza frecuentemente en desarrollo interno de software a
gran escala.
2. Si la implementación del riesgo de análisis afectará de forma
esencial los beneficios del proyecto, no debería utilizarse este
modelo.
3. Los desarrolladores de software han de buscar de forma explícita
riesgos y analizarlos de forma exhaustiva para que este modelo
funcione.
http://html.rincondelvago.com/el-ciclo-de-vida-del-software.html
http://es.wikipedia.org/wiki/Ciclo_de_vida_del_software