Modelos del ciclo de vida del software

Modelos del Ciclo de Vida del Software

Porque se les llama prescriptivos:

Porque prescriben un conjunto de elementos de proceso: actividades del marco de trabajo, acciones de ingeniería del software, tareas, productos del trabajo, aseguramiento de calidad y mecanismos de control de cambio para cada proyecto.

También prescribe un flujo de trabajo

Cualquier organización de Ingeniería del software debe describir un conjunto único de actividades dentro del marco de trabajo.

MODELO

EN

CASCADA

CUANDO SE UTILIZA:

Existen ocasiones en que los requisitos de un problema se entienden de manera razonable: cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal. Ejemplo: adaptaciones o mejoras a un sistema de contabilidad existente debido a los cambios en las regulaciones del Gobierno.

En un número limitado de proyectos de nuevos desarrollos, cuando los requerimientos están bien definidos y son estables de forma razonable.

MODELO EN CASCADA

Algunas veces llamado “Ciclo de vida clásico” sugiere:

Un enfoque sistemático secuencial hacia el desarrollo del software.

Es el paradigma mas antiguo para la ingeniería del software.

MODELO EN CASCADA

Comunicación

Inicio del proyecto

Recopilación de requisitos

Planeación

Estimación

Itinerario

Seguimiento

Modelado

Análisis

Diseño

Despliegue

Entrada

Soporte

retroalimentación

Construcción

Código

Prueba

MODELO EN CASCADAProblemas al aplicar el modelo:

Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo.

Es difícil para el cliente establecer los requisitos de manera explicita. El modelo en cascada lo requiere.

El cliente debe tener paciencia. Debe esperar que el proyecto esté bien avanzado para poder probar una versión que funcione del programa.

MODELO EN CASCADA

Resultados de aplicar el modelo

Los cambios confunden mientras el equipo del proyecto actúa.

Incorporan la incertidumbre natural.

Un error grave será desastroso si no se detecta antes de la revisión del programa.

MODELO EN CASCADA

Conclusión de análisis a un proyecto real.

Conduce a estados de bloqueo

El estado de bloqueo tiende a ser mas común al principio y al final del proceso

Puede servir como modelo en situaciones donde los requerimientos están fijos, y donde el trabajo se realiza hasta su conclusión de una manera lineal.

MODELOS INCREMENTALES

En muchas situaciones los requisitos iniciales del Software están bien definidos en forma razonable, pero el enfoque global excluye un proceso puramente lineal.

Quizá haya necesidad de proporcionar un conjunto limitado de funcionalidad para el usuario y después refinarla y expandirla en las entregas posteriores del Software.

MODELO INCREMENTALSe da cuando:

Los requisitos iniciales del software están bien definidos en forma razonable.

Hay una necesidad imperiosa de proporcionar un conjunto de funcionalidad al usuario y después refinarla y expandirla.

A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial

MODELO INCREMENTAL

Características:

Este modelo combina elementos del modelo en cascada aplicada en forma iterativa.

Aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario.

Cada secuencia lineal produce incrementos de software

MODELO INCREMENTAL

Ejemplo de un software procesador de texto:

Primer incremento: Realiza funciones básicas de administración de archivos, edición y producción

de documentos

Segundo incremento: Ediciones mas sofisticadas y tendría funciones mas complejas de producción

de documentos.

Tercer incremento: Funciones de corrección ortográfica y gramatical

Cuarto incremento: Capacidades avanzadas de configuración de pagina.

MODELO INCREMENTAL

En este modelo el primer incremento es un productos esencial.

Es iterativo por naturaleza.

Se enfoca en la entrega de un productos funcional con cada incremento.

Es útil cuando el personal necesario para una implementación completa no esta disponible.

Los primeros incrementos se pueden implementar con menos gente.

Los incrementos se pueden planear para manejar los riesgos técnicos.

MODELO INCREMENTALAnálisi

sDiseñ

oCódig

oPrueb

a

Análisis

Diseño

Código

Prueba

Análisis

Diseño

Código

Prueba

Entrega de primer incremento

Entrega de segundo incremento

Entrega de tercer incremento

Tiempo calendario

Desarrollo Rápido de Aplicaciones (DRA)

Desarrollo Rápido de Aplicaciones (DRA)

Objetivo: Desarrollo de sistemas en poco tiempo

Adaptación a “alta velocidad” del modelo en cascada.Equipos trabajando en paraleloAplicando tecnología de componentes

Del inglés Rapid Application Development (RAD)

Fases del Módelo DRA

Comunicación

Planificación Modelado• Gestión• Datos• Proceso

Construcción• Reutilización de

componentes• Creación de nuevos

componentes• Pruebas

Modelado• Gestión• Datos• Proceso

Construcción• Reutilización de

componentes• Creación de nuevos

componentes• Pruebas

Equipo 1

Equipo n

Despliegue• Pruebas• Entrega• Retroalimentaci

ón

60 – 90 días

Ventajas y Desventajas del DRA

VentajasRapidez(Enfatiza ciclos de desarrollo extremadamente

cortos)Válido para aplicaciones modularizablesReutilización

DesventajasExige conocer bien los requisitos y delimitar el ámbito del

proyectoNúmero de personasClientes y desarrolladores comprometidosGestión riesgos técnicos altos

○ Uso de nueva tecnología○ Alto grado de interoperabilidad con sistemas existentes○ Cuando los riesgo son altos DRA no es apropiado

Modelos Evolutivos

- Los modelos evolutivos son iterativos, los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más completas del Software.

- Las estrictas fechas tope del mercado imposibilitan la conclusión de un producto completo, por lo que se debe presentar una versión limitada para liberar la presión competitiva y de negocios.

1. CONSTRUCCIÓN DE PROTOTIPOS

A menudo un cliente define un conjunto de objetivos generales para el software pero no identifica los requisitos detallados de entrada, procesamiento o salida.

Desventajas El cliente ve lo que parece una versión en

funcionamiento del software, sin saber que el prototipo está unido con chicle,

que por la prisa de hacerlo funcionar no se ha considerado la calidad del

software.

Cuando se informa que el producto debe construirse otra vez para mantener los altos niveles de calidad, el cliente no lo

entiende, es frecuente que la gestión sea muy lenta.

A menudo, el desarrollador establece compromisos de implementación para lograr que el prototipo funcione con rapidez. Tal vez se utilice un sistema

operativo o lenguaje de programación inadecuado solo porque está disponible y

es conocido.

Plan rápido

Modelado, diseño rápido

Construcción del prototipo

Desarrollo, entrega y

retroalimentación

Comunicación

Modelo de Construcción de Prototipos

2. MODELO EN ESPIRAL

Historia

El creador del modelo en espiral fue Barry Boehm

Sirvió dentro del departamento de ESTADOS UNIDOS de la defensa (DoD) como director de la oficina de las ciencias y de la tecnología de la información de DARPA

Sus contribuciones al campo incluyen el modelo constructivo del coste (COCOMO), el modelo espiral del proceso del software propuesto originalmente por BOEHM en 1976

Cuando se aplica el modelo en espiral, el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documento del modelo o un prototipo. Durante las últimas iteraciones se producen versiones cada vez más complejas del sistema desarrollado.

A diferencia de otros modelos de proceso que terminan cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del Software de computadora.

El modelo en espiral es un enfoque realista para el desarrollo de software y de sistemas a gran escala.

Es difícil convencer a los clientes de que el enfoque evolutivo es controlable.

A medida que el software evoluciona, el desarrollador y el cliente comprenden y reaccionan mejor ante los riesgos en cada uno de los niveles evolutivos.

Mantiene el enfoque sistemático de los pasos del ciclo de vida clásico, pero lo incorpora al marco de trabajo iterativo.

Principios Básicos

Decidir qué problema se quiere resolver antes de viajar a resolverlo.

Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.

No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita.

Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

Como Elegir el ModeloPuntos a tomar en cuenta para elegir el modelo.

Hay Cambio significativo a medida que avance el proyecto. (Evolutivo)

Se Comprende bien toda la arquitectura del sistema al comenzar el proyecto. (Lineales)

Fiabilidad. (Formales)

Que tiempo extra se necesita para planificar y diseñar durante el proyecto para posibles versiones futuras. (DRA)

Existe una Planificación predefinida. (Espiral)

Se tendrá que Realizar modificaciones a medio camino. (Evolutivo, Incremental)

Debe proporcionarse a los clientes signos visibles de progreso durante el proyecto . (Incremental)

Analizar el siguiente problema, luego dar su respuesta de cual modelo utilizaría para este caso y explicar la razón por la cual eligió dicho modelo:

Se supone que se va desarrollar una aplicación relativa a la gestión de pedidos de una empresa. En este caso el cliente ya tiene claro qué es lo que quiere. El personal informático va a utilizar una tecnología que le resulta completamente nueva. Indique qué tipo de ciclo de vida es más apropiado y qué procesos se deberían utilizar para desarrollar esta aplicación. Explique su respuesta

Lecturas complementarias

Leer el capítulo 3 del libro de texto de Roger Pressman, para ampliar tus conocimientos.

Muchas Gracias