EL CICLO DE VIDA DEL

SOFTWARE
Lic. Espinoza Robles Armando David

1
 Concepto de Ciclo de Vida
• En los Dpto. de Sistemas se debe definir un marco de
referencia común que:
– Pueda ser empleado por todos los que participan en un
desarrollo informático, que defina los procesos las actividades
tareas a desarrollar
• Se han propuestos diferentes paradigmas o ciclos de
vida para el Software, desde:
– Ciclo en Cascada
– Modelo en Espiral de Boehm
– Ciclo de vida OO.
• Las Organizaciones (IEEE, ISO ) han publicado sendos
informes titulados
– estándar IEEE para el desarrollo del Ciclo de vida del Sftw.
– ISO :Proceso del ciclo de vida del Sftw.

2
• La norma IEEE 1040: Entiende por ciclo de
vida del Softw: “Una aproximación lógica a
la adquisición, el suministro, el desarrollo,
la explotación y mantenimiento del Softw.”
• La Norma ISO 12207-1: Entiende por ciclo
de vida: “ 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 Softw., abarcando la vida del
sistema desde la definición de los requisitos
hasta la finalización de su uso.”

3
• Ambas consideran:
– una actividad como un conjunto de tareas
– una tarea como una acción que transforma
entrada en salida.
• El ciclo de vida abarca:
– toda la vida del sistema : desde su concepción
hasta su fin.
– El ciclo de desarrollo : es un sub conjunto del
ciclo de vida
• empieza en el análisis
• finaliza en la entrega del sistema al usuario.

4
 PROCESO DE CICLO DE VIDA SOFTWARE
• Para ISO 12207-1
• Procesos Principales Procesos de Soporte
– Adquisición Documentación
– Suministro Gestión de Configur.
– Desarrollo Asegura.Calidad
– Explotación Verificación
– mantenimiento Validación
– Revisión Conjunta
– Auditoria
– Resoluc. Problemas
– PROCESOS DELA ORGANIZACIÓN
• Gestión Infraestructura
• Mejora Formación
5
 Procesos Principales
• Son los que resultan útiles a personas que
realizan el desarrollo explotación y
mantenimiento del Sftw. (compradores,
suministradores, el personal de desarrollo,
operadores, personal de mantenimiento)
– Proceso de Adquisición: actividades y tareas que el
comprador el cliente o usuario realiza para adquirir
un sistema.
– Proceso de Suministro: actividades y tareas que el
suministrador realiza. Inicia con decisión de preparar
una respuesta a una petición de un comprador.

6
– Proceso de Desarrollo: actividades de análisis
de requisitos, diseño, codificación, pruebas e
instalación y aceptación.

• Análisis de Requisitos:
• Diseño de Arquitectura del Sistema
• Análisis de Requisitos del Softw.
– Especificaciones funcionales y de capacidad
– Interfaces externas, requisitos de aceptación, seguridad,
– Especificaciones de interacción hombre maquina
– Requisitos de base de datos.
– Requisitos de instalación y aceptación del softw.
• Diseño de la Arquitectura Softw.
• Diseño detallado del Softw.
• Codificación y prueba del Softw.
7
• Integración del Softw.
• Prueba del software
• Integración del Sistema
• Prueba del Sistema
• Instalación del Softw.
• Soporte de Proceso de aceptación del Softw.

8
– Proceso de Explotación.: incluye la explotación
del Softw., y el soporte a los usuarios.
– Proceso de Mantenimiento: aparece cuando el
Softw., necesita de modificaciones en el código
o documentación. Incluye actividades de
migración a un nuevo entorno.

9
 Proceso de Soporte
• Sirve de apoyo al resto, y se aplica en
cualquier punto del ciclo de vida del Softw. Y
son:
– Proceso de Documentación: se registra la
información producida por un proceso o actividad
del ciclo de vida.
– Proceso de Gestión de la Configuración: aplica
procedimientos adminis. Y técnicos durante el
ciclo de vida del sist.:
– Identificar definir establecer la línea de los elementos de
configuración.
– Controlar modificaciones y versiones.

10
 – Registrar información sobre peticiones de modificación.
– Asegurar la complecion, la consistencia y comunicación de
los elementos.
– Controlar el almacenamiento, la manipulación y entrega de
elementos.
– Proceso de Aseguramiento de la Calidad: aporta
la seguridad que los procesos y producto,
cumplen con los requisitos especificados.
– Proceso de Verificación: determina si los
requisitos de un sistema están completos y son
correctos
– Proceso de Validación: sirve para determinar si el
sistema final cumple con los requisitos previstos.

11
– Proceso de Revisión Conjunta: sirve para
evaluar el estado del Softw., y sus productos en
una actividad del ciclo de vida
– Proceso de Auditoria.: determina los hitos
predeterminados, han cumplido los requisitos,
planes y contrato.
– Proceso de Resolución de Problemas.: analiza y
elimina los problemas descubiertos durante el
desarrollo , explotación, mantenimiento u otro
proceso.

12
 Procesos Generales o de Organización
• Ayuda a establecer implementar y mejorar la
organización, haciendola mas eficaz
– Proceso de Gestión: contiene tareas genéricas
para gestionar procesos.
– Procesos de Infraestructura: establece la
infraestructura necesaria para cualquier proceso
(softw y hardw.)
– Proceso de Mejora: valorar, medir controlar y
mejorar los procesos del ciclo de vida Softw.
– Proceso de Formación: sirve para mantener al
personal formado. Material y plan de formación.
13
 Proceso de Adaptación
• Sirve para la adaptación a la norma ISO
12207-1 con respecto a los proyectos de
softw.
• Dado que los procesos se aplican durante el
ciclo de vida del sftw., de diferentes formas
es necesario comprender los procesos, las
organizaciones y sus relaciones tal como se
ve en la sig. Figura.

14
 V.contrato Compra.prove
P.Adquisición P.Suministro

P.Gestión
V.dirección direccion

P. Explotación
V.operativo Operad.Usua

V.Ingeni.
P.Mantenimiento P.Desarrollo Desarrolla. Mant.

PROCESO DE APOYO soporte

Per.usa proc.apoyo
Documentación validación
Gestión Configuración Revisión Conjunta
Aseg.de calidad Auditoria
Verificación Resu.Problemas
PROCESO DE LA ORGANIZACIÓN
Infraestructura Formación
15

Mejora
• Visión de Contrato: el comprador y proveedor
negocian y firman, empleando los procesos de
adquisición y suministro.
• Visión de Dirección: el comprador, proveedor,
desarrollador gestionan sus procesos, para
proyecto de softw.
• Visión de Explotación: el operador explota el
sftw.,
• Visión de Ingeniería: el desarrollador o
personal de mant., lleva ha cabo sus tareas
• Visión de Soporte: unen grupos, proporciona
servicios de apoyo a otros grupos
16
 MODELO EN CASCADA
• La versión original del modelo Cascada fue
propuesto por Royce: 1970.
• El numero de faces varian. En general son:
– Análisis de requisitos de sistema
– Análisis de requisitos del softw.
– Diseño preliminar
– Diseño detallado
– Codificación
– Pruebas
– Explotación
– Mantenimiento
17
Análisis de requisitos
Sistema

Análisis Requisitos
Software
Diseño
Preliminar

Diseño
Detallado

Codificación
pruebas

Explotación
mantenimiento

18
 Modelo en Cascada
• Algunas características:
– cada fase empieza cuando ha terminado la
anterior
– para pasar de una fase a otra es necesario
conseguir todos los objetivos de la fase anterior
– ayuda a prevenir que se sobrepasen la fecha de
entrega y los costos esperados
– al final de cada fase técnicos y usuarios tienen
la oportunidad de revisar el proceso del
proyecto.

19
 Modelo en cascada
• Es el mod. De ciclo de vida mas antiguo y
mas ampliamente usado.
• Las criticas son:
– no refleja el proceso real de desarrollo de
softw., estos raramente siguen procesos lineales
– se tarda mucho tiempo en pasar por todo el
ciclo.
– Acentúa el fracaso de la industria del softw.,
con el usuario final.

20
 Modelo Incremental
• Corrige la necesidad de una secuencia no
lineal de pasos de desarrollo. En este mod.,
se va creando el sistema añadiendo
componentes funcionales al sistema.
• En cada paso se actualiza el sistema con
nuevas funcionalidades o requisitos.
• El sistema no se ve como una única unidad
monolítica con fecha fija.
21
 Modelo Incremental
• Se ajusta a entornos de alta incertidumbre, ya
que en cada refinamiento amplia los
requisitos y especificaciones de fases
anteriores.
• Es un avance respecto al modelo en Cascada.
• Presenta el problema de saber si los
requisitos propuestos son validos
• los errores en requisitos se detectan tarde y
corrección es costosa.

22
Análisis
Requisito
Sistemas
Análisis
Incremento 1
Requisito
Softw.
Diseño
Preliminar
Diseño
Detallado
Incre. 2
Codificación
Diseño Prueba
Detallado

Codificación Explotación
Prueba Mantenimiento

Explotación
Mantenimiento

23
 MODELO ESPIRAL
• Boehn 1988 propuso el modelo espiral que
consta de una serie de ciclos. Cada uno
empieza identificando sus objetivos,
alternativas y restricciones.
• Se evalúa las alternativa respecto a los
objetivos tomando en cuenta las
restricciones, se lleva a cabo el ciclo
• una vez finalizado se plantea el próximo
ciclo
24
• Cada ciclo dela espiral comienza con la
identificación de:
– Los objetivos: de la parte del producto que esta
siendo elaborada. Ej. Se desea aumentar la
productividad del softw.
– Las Alternativas, principales de la implantación
de esta porción del producto. Existen diferentes
alternativas
– las restricciones impuestas para cada
alternativa.

25
Determina objetivos Evalúa alternativas
alternativas restricciones identificar y resolver
los riesgos

Anal .riesgo

P.3
P.2
Plan requisito

Plan desarrollo
Ver.requisito

Planificación de fase Desarrollar verificar el

siguiente producto del siguiente nivel.
26
 Modelo espiral
• El siguiente paso es evaluar las diferentes
alternativas, teniendo en cuenta los
objetivos y restricciones. Se identifica las
áreas de incertidumbre del producto.
• El siguiente paso en formular una estrategia
efectiva para resolver los riesgos.
• El siguiente paso revisar los resultados del
análisis de riesgo
• siguiente paso planificar la fase posterior

27
 Modelo Espiral
• Una vez realizado el primer ciclo se vuelve ha
empezar. Cada ciclo se completa con una
revisión.
• Las características del método Espiral es:
– Existe conocimiento explícito de las diferentes
alternativas a alcanzar
– la identificación de riesgos asociado a cada
alternativa y como resolverlos.
– División de proyecto en ciclos, y cada uno con un
acuerdo final de ciclo
– el modelo se adapta a cualquier tipo de actividad
28
 Modelo Espiral
• Dificultades:
– trabajo con softw., contratado. Trabaja bien en
los desarrollos internos, pero necesita ajustes
para sub contrata de software.
– Necesidad de expertos en evaluación de
riesgos.

29
 MODELO DE DESARROLLO
DE SISTEMAS O.O
• EL MODELO Cascada no permite aprovechar
la tecnología de objetos, que pretende acelerar
el desarrollo de Softw., iterativo e incremental.
• La tecnología OO generaliza los componentes
para reutilizar, esto aumenta los costos de
desarrollo en un 10 a 50%.
• Se han propuesto modelos para abordar esta
problemática
30
 Modelo de Agrupamiento (Cluster)
• Los modelos usuales de ciclo de vida esta
basado en proyectos; mientras en el
desarrollo OO esta basado en en el producto.
• Para la cultura del proyecto se propone el
modelo de agrupamiento. En la que la fase
de generalización aparece combinada con la
fase de validación.
• El concepto clave es el Agrupamiento:
que es un conjunto de clases relacionadas
con un objetivo común.
31
TIEMPO MODELO DE AGRUPAMIENTO (CLUSTER)

Agrupamiento n
ESPEC DISREA VALGEN

ESPEC DISREA VALGEN Agrupamiento 2

ESPEC DISREA VALGEN Agrupamiento 1

32
TIEMPO
 Modelo Fuente
• Definido por Henderson Sellers y Edwards
1990: es el mas conocido en el desarrollo
OO.
• Presenta alto grado de iteración y
solapamiento que hace la tecnología de
Objetos.
• En la base esta el análisis de Requisitos, a
partir del cual va creciendo el ciclo de vida,
cayendo solo para el mantenimiento.
• La piscina seria el repositorio de clase.
33
 Modelo fuente
• Se propone además, un modelo de ciclo de
vida para cada clase o modulo, ya que cada
una puede estar en una fase diferente del
ciclo de vida durante el desarrollo de un
sistema.
• Este ciclo d vida se puede aplicar también a
los agrupamientos de clase. ( reutilizacion
parcial o una total al desarrollo una clase)

34
mantenimiento utilización evolución
Pruebas
sistemas
Pruebas
unitarias
codificación
componentes
Diseño
conceptual
Análisis
Estudio de
viabilidad y requisitos

Piscina Sw Modelo ciclo

de vida fuente
35
 MODELO REMOLINO
• Rumbaugh: 1992: señala que las
metodológias de desarrollo, no ofrecen una
visión real del mismo, que es mucho mas
desordenada e implica múltiples iteraciones.
• El modelo en cascada asume solo una
dimensión de iteración consistente en la
fase de proceso, pero pueden identificarse
otras dimensiones, como las:

36
 MODELO REMOLINO
– Amplitud: o tamaño del desarrollo
– profundidad: nivel de abstracción o detalle
– madurez : grado de compleción, corrección y
elegancia
– alternativas: diferentes soluciones a un
problema
– alcance: en cuanto a adjetivos del sistema, ya
que los requisitos cambian a lo largo del tiempo

37
 MODELO REMOLINO
• Las diferentes dimensiones se pueden
anidar de muchas maneras: ej. Fase -
madures - amplitud.
• Este proceso fractal (mas que lineal),
consiste en un desarrollo multiciclico, tiene
la forma de un remolino en lugar de una
cascada.

38
 Modelo Pinball
• Propuesto por Ampler: 1994. Señala que el
pinball refleja realmente la forma en la que
se desarrolla softw.
• En este modelo la pelota representa un
proyecto completo sub proyecto, y el
jugador es el equipo de desarrollo.

39
 Modelo Pinball
• Se procede de forma iterativa a encontrar
clases, atributos, métodos e interrelaciones
y definir colaboraciones, herencias,
agregación y subsistemas.
• Por ultimo se pasa a la programación
prueba e implementacion
• como en el pinball los pasos se pueden
tomar en cualquier orden y de forma
simultanea.

40
 Modelo Pinball
• Se destaca dos estilos a la hora de jugar:
– a lo seguro: con tecnologías y métodos
probados.
– Al limite: con mayor riesgo, pero con mas
ventajas.
• El autor destaca que al igual que en el juego
del pinball, la habilidad es el factor mas
importante.

41
 Consideraciones generales
• Todos los modelos de desarrollo OO se
caracterizan por:
– eliminación de fronteras entre fases
– una nueva forma de concebir los lenguajes de
programación y su uso
– un alto grado de iteración y solapamiento
• los expertos en tecnologías de objetos
proponen seguir un desarrollo Iterativo e
incremental.
42
 Consideraciones generales
• Las tareas de cada fase se llevan a cabo de
forma iterativa, a la vez existe un ciclo de
desarrollo análisis - instrumentación -
análisis que permite hacer evolucionar al
sistema.
• Lo incremental se refiere al hecho que el
sistema se divide en un conjunto de
particiones, las cuales se desarrollan de
manera completa

43
 Consideraciones generales
• Las actividades de validación, verificación y
seguimiento de la calidad se realizan para cada
iteración de cada fase
• la ventaja principal de estos modelos es que
permite fijar hitos mas frecuentes, realizando
entregas de sistemas operativos cada dos o tres
meses, para recibir retroalimentacion del
cliente.
• El inconveniente es la dificultad de gestionar
de manera formal los proyectos.
44