Download - 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