EL CICLO DE VIDA DEL

SOFTWARE

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 Softwareare, 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.
2
– ISO :Proceso del ciclo de vida del Sftw.
• La norma IEEE 1040: Entiende por ciclo de
vida del Softwareare: “Una aproximación
lógica a la adquisición, el suministro, el
desarrollo, la explotación y mantenimiento del
Softwareare.”
• 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
Softwareare, 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 SoftwareARE
• Para ISO 12207-1
Procesos Principales Procesos de Soporte
– Adquisición *Documentación
– Suministro *Gestión de Configuración.
– Desarrollo *Aseguramiento de la Calidad
– Explotación *Verificación
– mantenimiento *Validación
*Revisión Conjunta
*Auditoria
*Resolución de 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 Software.
– 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 Software.
• Diseño de la Arquitectura Software.
• Diseño detallado del Software.
• Codificación y prueba del Software.
7
• Integración del Software.
• Prueba del Softwareare
• Integración del Sistema
• Prueba del Sistema
• Instalación del Software.
• Soporte de Proceso de aceptación del Software.

8
– Proceso de Explotación.: incluye la explotación
del Software., y el soporte a los usuarios.

– Proceso de Mantenimiento: aparece cuando el

Software., 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
Software 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 administración. Y técnicos
durante el ciclo de vida del sistema.:
– 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 Software., 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, haciéndola mas eficaz
– Proceso de Gestión: contiene tareas genéricas
para gestionar procesos.
– Procesos de Infraestructura: establece la
infraestructura necesaria para cualquier proceso
(Software y hardware.)
– Proceso de Mejora: valorar, medir controlar y
mejorar los procesos del ciclo de vida Software.
– 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
Software.

• Dado que los procesos se aplican durante el

ciclo de vida del Software, de diferentes
formas es necesario comprender los
procesos, las organizaciones y sus
relaciones tal como se ve en la siguiente
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

Documentación validación Per.usa proc.apoyo

Gestión Configuración Revisión Conjunta Aseg.de

calidad Auditoria
Verificación Resu.Problemas
PROCESO DE LA ORGANIZACIÓN

Infraestructura Formación Mejora

15
• 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 Software.
• 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 Software.
– Diseño preliminar
– Diseño detallado
– Codificación
– Pruebas
– Explotación
– Mantenimiento 17
Análisis de requisitos
Sistema

Análisis Requisitos
Softwareare
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 modelo De ciclo de vida mas antiguo
y mas ampliamente usado.
• Las criticas son:
– no refleja el proceso real de desarrollo de
Software., estos raramente siguen procesos
lineales
– se tarda mucho tiempo en pasar por todo el
ciclo.
– Acentúa el fracaso de la industria del Software.,
con el usuario final.

20
 Modelo Incremental
• Corrige la necesidad de una secuencia no
lineal de pasos de desarrollo. En este
modelo, 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
Software.
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 Software.

– 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 Software., contratado. Trabaja bien
en los desarrollos internos, pero necesita ajustes
para sub contrata de Softwareare.
– Necesidad de expertos en evaluación de
riesgos.

29
 MODELO DE DESARROLLO
DE SISTEMAS ORIENTACIÓN
OBJETOS
• EL MODELO Cascada no permite aprovechar
la tecnología de objetos, que pretende acelerar
el desarrollo de Software, 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 VALGEN Agrupamiento 1

DISREA

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ógicas 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 Software.
• 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