INGENIERÍA DE SOFTWARE I

CICLO DE VIDA

ING. VÍCTOR ANCAJIMA MIÑÁN

Ciclo de vida: Definición
•Conjunto de fases por las que pasa el sistema que se está
desarrollando desde que nace la idea inicial hasta que el
software es retirado o reemplazado (“muere”).

• Se denomina a veces “paradigma”.

• Dos puntos de vista

• Transformación del producto.
• Proceso que transforma el producto.

2
Ciclo de vida: Definición
“Una aproximación lógica a la adquisición, el suministro, el
desarrollo, la explotación y el mantenimiento del software”
IEEE 1074

“Un marco de referencia que contiene los procesos, las

actividades y las tareas involucradas en el desarrollo, la
explotación y el mantenimiento de un producto de
software, abarcando la vida del sistema desde la definición
de los requisitos hasta la finalización de su uso”
ISO 12207-1

3
Ciclo de vida: Distribución del esfuerzo

Distribución del esfuerzo durante el ciclo de vida

40 36
35
30
25
16 16
Relativo(%)

20
12 12
Esfuerzo

15
8
10
5
0

4
Ciclo de vida: Funciones (i)
• Un ciclo de vida debe:

1. Determinar el orden de las fases del proceso

software.
2. Establecer los criterios de transición para
pasar de una fase a la siguiente.

3. Definir las entradas y salidas de cada fase.

5
Ciclo de vida: Funciones (ii)
1. Describir los estados por los que pasa el
producto.

2. Describir las actividades a realizar para

transformar el producto.

3. Definir un esquema que sirve como base para:

• Planificar.
• Organizar.
• Coordinar.
• Desarrollar.
6
Ciclo de vida: Situación Real

Análisis

Diseño Pruebas

Codificación

7
Modelos de ciclos de Vida
MODIFICADORES

MODELOS MODELOS CICLOS DE

CICLOS DESARROLLO VIDA DE SISTEMAS

SECUENCIAL
INCREMENTAL
CASCADA
EVOLUTIVO
CASCADA
ESPIRAL

PROTOTIPADO CONCURRENCIA

COMPONENTES COMERCIALES Y REUTILIZAZIÓN

8
Modelo de desarrollo: LINEAL

Requisitos

Diseño

Codificación

Pruebas

Integración

Operación y
mantenimiento

9
Modelo de desarrollo: LINEAL
• Este modelo refleja un desarrollo marcado por la sucesión escalonada de las
etapas que lo componen : requisitos, diseño, codificación, pruebas e integración.

• Es necesario terminar por completo cada etapa para pasar a la siguiente.

• Este modelo, identificado ya a principios de la década de los 50, resulta muy rígido
porque cada fase requiere como elemento de entrada el resultado completo de la
anterior.

Al aplicarlo en situaciones reales su rigidez genera problemas, porque muchas veces

resulta difícil poder disponer de requisitos completos o del diseño pormenorizado del
sistema en las fases iniciales, creando una barrera que impide avanzar.
Resulta apropiado para:

 Desarrollar nuevas versiones de sistemas ya veteranos en los que el

desconocimiento de las necesidades de los usuarios, o del entorno de
operación no plantea riesgos.
 Sistemas pequeños, sin previsión de evolución a corto plazo.
10
Modelo de ciclo de vida CASCADA (i)

Qué
Análisis

Diseño

Cómo
Codificación

Pruebas
e integración

Operación y
Mantenimiento 18
Modelo de ciclo de vida en cascada (ii)
Características:
• Es el más utilizado.
• Es una visión del proceso de desarrollo de software
como una sucesión de etapas que producen productos
intermedios.
• Para que el proyecto tenga éxito deben desarrollarse
todas las fases.
• Las fases continúan hasta que los objetivos se han
cumplido.

• Si se cambia el orden de las fases, el producto final

será de inferior calidad. 12
Modelo de ciclo de vida en cascada (iii)

Limitaciones:

• No se permiten las iteraciones.

• Los requisitos se congelan al principio

del proyecto.

• No existe un proyecto “enseñable” hasta

el final del proyecto.

13
Modelo de ciclo de vida en cascada (iv)

Divergencia de
expectativas

Análisis tiempo Entrega

14
Modelo de ciclo de vida en cascada: Variaciones

Análisis

Diseño

Codificación

Pruebas
e integración

•Se añade realimentación Operación y

entre fases. Mantenimiento 22
Modelo de mejora iteractiva

Análisis
• Los productos de las
Diseño diferentes etapas van
refinando y mejorando.
Codificación

Pruebas
e integración

Operación y
Mantenimiento 23
Iterativo

• Rational Unified Process (www.rational.com ).

Iteracción de A&D [más iteraciones]

Planificación Análisis Diseño

Incremento

Planificación Análisis Diseño Prototipo Pruebas Evalua

cliente
Cliente

[más iteraciones]

Otras “metodologías ágiles”:

• Extreme Programming (Xp):
www.extremeprogramming.org 24
Modelo de ciclo de vida en espiral (i)
Costos acumulados Progreso a través
Determinación de Evaluación de alternativas,
de pasos identificación y resolución
objetivos, riesgos,
alternativas, restricciones de riesgos
A. de
riesgo
A. de
riesgo
A. de
riesgo
Prototipo 1
Planificación de Simulaciones, modelos, programas de prueba
requisitos y del Concepto
ciclo de vida de operación
Planificación Validación
del diseño de requisitos
Planificación de Validación y
Planificación de
la codificación verificación del diseño Prueba Codificación
las próximas fases de
Integración unidad
aceptación
implantación

Prueba de
y Desarrollo, verificación
prueba del producto del próximo
nivel. 25
Modelo de ciclo de vida en espiral (ii)
•Se usa en proyectos en los que se prevén riesgos.

•Representa un enfoque dirigido por el riesgo para el análisis y

estructuración del proceso software.

• Ventajas:
• Utiliza las fases de modelos tradicionales.
• Se centra en la eliminación de errores y alternativas poco
atractivas.
• Su orientación a detectar y prevenir el riesgo evita muchas
dificultades.

• Desventajas:
• Complicado: Consume muchos recursos.
• Las etapas y sus E/S no están claramente definidas
19
Modelo de ciclo de vida PROTOTIPADO

20
Modelo de PROTOTIPADO
1. No modifica el flujo del ciclo de vida

2. Reduce el riesgo de construir productos que no satisfagan las

necesidades de los usuarios
3. Reduce costos y aumenta la probabilidad de éxito
4. Exige disponer de las herramientas adecuadas

5. No presenta calidad ni robustez

6. Una vez identificados todos los requisitos mediante el prototipo, se construye el
producto de ingeniería

21
Modelo de PROTOTIPADO
PARA QUE SEA EFECTIVO:

Debe ser un sistema con el que se pueda experimentar

Debe ser comparativamente barato (< 10%)
Debe desarrollarse rápidamente
Enfasis en la interfaz de usuario
Equipo de desarrollo reducido
Herramientas y lenguajes adecuados

“El prototipado es un medio excelente para recoger el

‘feedback’ (realimentación) del usuario final”

22
Modelo de PROTOTIPADO: PELIGROS

1. El cliente ve funcionando lo que para el es la primera

versión del prototipo que ha sido construido con
“plastilina y alambres”, y puede desilusionarse al decirle
que el sistema aun no ha sido construido.

2. El desarrollador puede caer en la tentación de ampliar

el prototipo para construir el sistema final sin tener en
cuenta los compromisos de calidad y de mantenimiento
que tiene con el cliente

23
Modelos de desarrollo de productos software (i)
•Elcliente no suele tener una idea clara de lo que quiere, o no sabe
explicarlo bien.

•El
responsable de desarrollo puede no estar seguro de la eficacia de
un algoritmo, del enfoque a tomar en la interacción hombre-
máquina, etc.

• Ayudan a comprender y validar los requisitos de usuario.

• Desarrollo de prototipos y maquetas.

24
Desarrollo de productos software

Divergencia de
expectativas

Revisión del Revisión del

Prototipo Prototipo

tiempo
25
Productos software

Construir/revisar
maqueta

Escuchar al cliente El cliente prueba

33
la maqueta
Modelo de procesos software IEEE (i)
Procesos Orientados al desarrollo de SW.
Procesos de Pre-Desarrollo
Proceso de selección
de un MCVS Proceso de exploración de Conceptos
Procesos Integrales
Proceso de asignación del sistema del Proyecto

Procesos de Desarrollo Proceso

Proceso de gestión Proceso
del Proyecto Proceso de Requisitos de Gestión
de
Proceso Verificación de
y Configura-
de Proceso de Diseño
Proceso Validación ción del
Segui- SW
de
Iniciación miento Proceso de Implementación
y
control Proceso
Proceso
Procesos de post-desarrollo de
de
Documen-
Proceso de Instalación Formación
Proceso tación.
de Gestión de
Calidad del SW. Proceso de
Proceso de Proceso de
Operación y
Mantenimiento Retiro
Soporte
35
Modelo de procesos software IEEE:

Modelo de ciclo + Actividades = Ciclo de vida

de vida

IEEE 1074-1995
• Gestión.
Ejemplos: Iniciación, Seguimiento y Control, Gestión
de calidad.
• Cascada • Pre-desarrollo.
Exploración de conceptos, Asignación del
• Incremental sistema.
• Espiral • Desarrollo.
• Evolutivo Requisitos, diseño, implementación.
• ... • Post-desarrollo.
Instalación, Operación, Soporte, Mantenimiento,
Retiro.
• Integrales.
Verificación y Validación, Gestión de Config.,
63
Documentación,Formación.
Modelo de procesos software IEEE:
Ej.: Ciclo de Vida en Cascada

Actividades EV AR DI CO PR IN MA RE
Procesos de Gestión de Proyecto
Procesos de Iniciación
• Asignar actividades al MCV X
• Reservar recursos para el proyecto X X X X X X X X
• Establecer entorno (estándares,...) X X X
• Plan de gestión proyecto X X

Procesos de Seguimiento y Control X X X X X X

• Analizar riesgos.
• Realizar planes de contingencia.
• Gestionar el proyecto. X X X X X X X X
X X X X X
• Registrar información. X X X X X X X X
•Implementar sistema de reporte de Problemas. X X X X X X X

… …
29
Creación de un Modelo de ciclo de vida
Al iniciar el proyecto, el responsable de la arquitectura de procesos debe realizar los
siguientes pasos:
 Análisis de las circunstancias ambientales del proyecto.
 Diseño del modelo específico de ciclo de vida para el proyecto (sobre las bases
de los diseños más apropiados, para el desarrollo y la evolución del sistema de
software.
 Mapeo de las actividades sobre el modelo.
 Desarrollo del plan para la gestión del ciclo de vida del proyecto.
Debe considerar aspectos como:
 Posibilidad de descomposición del sistema en subsistemas de software, con
agendas y entregas diferenciadas.
 Estabilidad esperada de los requisitos.
 Novedad del proceso o procesos gestionados por el sistema en el entorno del
cliente.
 Criticidad de las agendas y presupuestos.
 Grado de complejidad del interfaz de operación, criticidad de la usuabilidad.
 Grado de conocimiento y familiaridad con el entorno de desarrollo, componentes
externos empleados, etc.
30