3 Clase Ciclo De Vida Del Software -

1

EL CICLO DE VIDA DEL SOFTWARE

Lic. Espinoza Robles Armando David

2

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.

3

• 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.”

4

• 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.

5

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

6

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.

7

– 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.

8

• 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.

9

– 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.

10

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.

11

– 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.

12

– 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.

13

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.

14

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.

15

P.Adquisición P.Suministro

P.Gestión

P. Explotación

P.Mantenimiento P.Desarrollo

Compra.prove

direccion

Operad.Usua

Desarrolla. Mant.

Per.usa proc.apoyo

PROCESO DE 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

Mejora

soporte

V.contrato

V.dirección

V.operativo

V.Ingeni.

16

• 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

17

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

18

Análisis de requisitos Sistema

Análisis Requisitos Software

Diseño Preliminar

Diseño Detallado

Codificaciónpruebas

Explotaciónmantenimiento

19

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.

20

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.

21

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.

22

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.

23

AnálisisRequisitoSistemas

AnálisisRequisito

Softw.

DiseñoPreliminar

DiseñoDetallado

CodificaciónPrueba

ExplotaciónMantenimiento

DiseñoDetallado

CodificaciónPrueba

ExplotaciónMantenimiento

Incremento 1

Incre. 2

24

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

25

• 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.

26

Evalúa alternativas

identificar y resolver

los riesgos

Determina objetivos

alternativas restricciones

Planificación de fase

siguiente

Desarrollar verificar el

producto del siguiente nivel.

P.3

Anal .riesgo

Ver.requisito

Plan desarrollo

P.2

Plan requisito

27

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

28

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

29

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.

30

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

31

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.

32

ESPEC DISREA VALGEN

ESPEC DISREA VALGEN

ESPEC DISREA VALGEN

TIEMPO

TIEMPO

Agrupamiento 1

Agrupamiento 2

Agrupamiento n

MODELO DE AGRUPAMIENTO (CLUSTER)

33

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.

34

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)

35

Análisis

Diseño conceptual

componentes

codificación

Pruebassistemas

evoluciónmantenimiento

Piscina Sw

Estudio de

viabilidad y requisitos

Pruebasunitarias

utilización

Modelo ciclo de vida fuente

36

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:

37

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

38

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.

39

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.

40

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.

41

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.

42

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.

43

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

44

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.