CICLO DE

VIDA
SOFTWARE
 CICLO DE
Es el estado de lasVIDA
fases a través de las cuales se
mueve un proyecto de desarrollo de software.

El primer ciclo de vida del software, "Cascada", fue

definido por Winston Royce a fines del 70.

Desde 10 a 15 años atrás, el modelo cascada ha sido

críticado, debido a que es restrictivo y rígido, lo cual
dificulta el desarrollo de proyectos de software
moderno. En su lugar, muchos modelos nuevos de
ciclo de vida han sido propuestos, incluyendo
modelos que pretenden desarrollar software más
rápidamente, o más incrementalmente, o
precediendo el desarrollo a escala total con algún
 MODELOS
EVOLUTIVOS
El software evoluciona con el tiempo. Los requisitos
del usuario y del producto suelen cambiar conforme
se desarrolla el mismo.

Los desarrolladores necesitan modelos de progreso

que estén diseñados para acomodarse a una
evolución temporal o progresiva, donde los requisitos
centrales son conocidos de antemano, aunque no
estén bien definidos a niveles detallados.

En el modelo Cascada no se tiene en cuenta la

naturaleza evolutiva del software, se plantea como
Los evolutivos son modelos iterativos, permiten
desarrollar versiones más completas y complejas,
hasta llegar al objetivo final; incluso evolucionar más
allá, durante la fase de operación.
Los modelos “Iterativo Incremental” y “Espiral” son
dos de los más conocidos y utilizados del tipo

Diagrama genérico del Desarrollo Evolutivo

Incremental
 DEFINICIóN DE UN MODELO DE
CICLO
DE VIDA
Un modelo de ciclo de vida de software es una vista de
las actividades que ocurren durante el desarrollo de
software. El ciclo de vida básico de un software consta
de los siguientes procedimientos:

Definición de objetivos: definir el resultado del

proyecto y su papel en la estrategia global.
Análisis de los requisitos y su viabilidad:
recopilar, examinar y formular los requisitos del cliente
y examinar cualquier restricción que se pueda aplicar.
Diseño general: requisitos generales de la
arquitectura de la aplicación.
Diseño en detalle: definición precisa de cada
subconjunto de la aplicación.
Programación : es la implementación de un
lenguaje de programación para crear las funciones
definidas durante la etapa de diseño.

Prueba de unidad: prueba individual de cada

subconjunto de la aplicación para garantizar que
se implementaron de acuerdo con las
especificaciones.

Integración: para garantizar que los diferentes

módulos se integren con la aplicación. Éste es el
propósito de la prueba de integración que está
cuidadosamente documentada.

Prueba beta (validación): para garantizar que el

software cumple con las especificaciones
Documentación: sirve para documentar
información necesaria para los usuarios del
software y para desarrollos futuros.
Implementación
Mantenimiento: para todos los procedimientos
correctivos (mantenimiento correctivo) y las
actualizaciones secundarias del software
(mantenimiento continuo).

Ø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
definición de un detallado proceso de desarrollo
 MODELO
CASCADA
Este es el más básico de todos los modelos, y sirve
como bloque de construcción para los demás
modelos de ciclo de vida. La visión del modelo
cascada del desarrollo de software es muy simple;
dice que el desarrollo de software puede ser a través
de una secuencia simple de fases. Cada fase tiene un
conjunto de metas bien definidas, y las actividades
dentro de una fase contribuye a la satisfacción de
metas de esa fase o quizás a una subsecuencia de
metas de la fase. Las flechas muestran el flujo de
información entre las fases. La flecha de avance
El modelo de ciclo de vida cascada, captura algunos
principios básicos:

ØPlanear un proyecto antes de embarcarse en él.

ØDefinir el comportamiento externo deseado del
sistema antes de diseñar su arquitectura interna.
ØDocumentar los resultados de cada actividad.
ØDiseñar un sistema antes de codificarlo.
ØTestear un sistema después de construirlo.
 MODELO DE
DESARROLLO
INCREMENTAL
Los riesgos asociados con el desarrollo de sistemas
largos y complejos son enormes. Una forma de
reducir los riesgos es construir sólo una parte del
sistema. El desarrollo incremental es el proceso de
construcción siempre incrementando subconjuntos
de requerimientos del sistema.

El modelo de desarrollo incremental provee algunos

beneficios significativos para los proyectos:

ØConstruir un sistema pequeño es siempre menos

riesgoso que construir un sistema grande.
ØAl ir desarrollando parte de las funcionalidades, es más
fácil determinar si los requerimientos planeados para los
niveles subsiguientes son correctos.

ØSi un error
importante es
realizado, sólo la
última iteración
necesita ser
descartada.
Reduciendo el tiempo
de desarrollo de un
sistema decrecen las
probabilidades que
esos requerimientos
ØSi un error importante es realizado, el incremento previo
puede ser usado. Los errores de desarrollo realizados en
un incremento, pueden ser arreglados antes del comienzo
del próximo incremento
 MODELO
ESPIRAL
El modelo espiral de software es un modelo del
ciclo de meta−vida. En este modelo, el esfuerzo de
desarrollo es iterativo. Tan pronto como uno
completa un esfuerzo de desarrollo, otro comienza
en cada desarrollo ejecutado, puedes seguir estos
pasos:

ØDeterminar qué quieres lograr.

ØDeterminar las rutas alternativas que puedes

tomar para lograr estas metas. Por cada una,
analizar los riesgos y resultados finales.

ØEstablecer qué tienes terminado.

 REGIONES DEL MODELO
Ø
ESPIRAL
Región 1 - Tareas requeridas para establecer la
comunicación entre el cliente y el desarrollador.

Ø Región 2 - Tareas inherentes a la definición de los

recursos, tiempo y otra información relacionada con el
proyecto.

ØRegión 3 - Tareas necesarias para evaluar los riesgos

técnicos y de gestión del proyecto.

ØRegión 4 - Tareas para construir una o más

representaciones de la aplicación software.

Ø Región 5 - Tareas para construir la aplicación, instalarla,

probarla y proporcionar soporte al usuario o cliente.

Ø Región 6 - Tareas para obtener la reacción del cliente,

según la evaluación de lo creado e instalado en los ciclos