Modelos evolutivos. incremental y espiral

Ingeniería en Sistemas de Información

Diseño de Sistemas(3K1)

Contenidos de la Unidad 1Introducción al Diseño

a. Significado Dentro del Ciclo de Vida de Desarrollo de Sistemas.

b. Modelos de Desarrollo de software

i. Modelos de Desarrollo Estructurado

Sommerville. Sección 8.5 y 4.5.1Pressman. Sección 2.10

1. Modelo en Cascada. Sommervillle. Sección 4.1.1.Pressman. Sección 2.4.

2. Modelos evolutivos: incremental y espiral.

Sommervillle. Sección 4.1.2. y 4.2Pressman. Sección 2.7

3. RUP Sommervillle. Sección 4.4.Jacobson, Booch y Rounbahg. Secciones 1.1 a a 1.5. Larman últ. Ed. Sección 37.1., 37.4 y 37.9

«Ingeniería del Software», 7ª Edición, por Ian Sommerville, 4.1.2.

Desarrollo Evolutivo: se basa en la idea de desarrollar una implementación inicial, exponiéndola a los comentarios del usuario y refinándola a través de las diferentes versiones hasta que se desarrolla un sistema adecuado.

Las actividades de especificación, desarrollo y validación se entrelazan, en vez de separarse, con una rápida retroalimentación entre éstas.

Unidad I: Modelos Evolutivos: Incremental

y Espiral

Unidad I: Modelos Evolutivos:

Figura Ilustrativa

Hay 2 tipos de desarrollo evolutivo: 1. Desarrollo exploratorio: Trabaja con el cliente para explorar sus

requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden

mejor. El sistema evoluciona agregando nuevos atributos propuestos por el

cliente. 2. Prototipos desechables: Busca comprender los requerimientos del

cliente y desarrollar una definición mejorada de los requerimientos. El prototipo se centra en experimentar con los requerimientos del

cliente que no se comprenden del todo.

Tipos de Modelos Evolutivos

Es más efectivo que el enfoque en cascada, pues satisface las necesidades inmediatas de los clientes.

La especificación se puede desarrollar de forma

creciente.

Tan pronto como el usuario entienda mejor su problema, éste se puede reflejar en el sistema software.

Ventajas del Modelo Evolutivo

1. El proceso no es visible. Los administradores deben hacer entregas regulares para medir el progreso.

Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema.

2. Genera sistemas con estructura deficiente. Los cambios continuos tienden a corromper la estructura del software.

Incorporar cambios se convierte cada vez más en una tarea difícil y costosa.

Desventajas del Modelo Evolutivo

Para sistemas pequeños y medios (de hasta 500.000 líneas de código), el enfoque evolutivo de desarrollo es el mejor.

Los problemas del desarrollo evolutivo se agravan en sistemas grandes y complejos, con un periodo de vida largo, donde diferentes equipos desarrollan distintas partes del sistema.

Es difícil establecer una arquitectura del sistema estable con este enfoque, por la dificultad en integrar las contribuciones de los equipos.

Recomendaciones para el Modelo Evolutivo

Para sistemas grandes, se recomienda un proceso mixto que incorpore las mejores características del modelo en cascada y del desarrollo evolutivo.

Se puede desarrollar un prototipo desechable (enfoque evolutivo) para resolver incertidumbres en la especificación del sistema.

Entonces, las partes del sistema bien comprendidas se pueden especificar y desarrollar utilizando un proceso basado en el modelo en cascada.

Las otras partes del sistema que son difíciles de especificar por adelantado (interfaz de usuario), se pueden desarrollar usando un enfoque de programación exploratoria.

Recomendaciones para el Modelo Evolutivo

Los cambios son inevitables en todos los proyectos de software grandes. Hay cambios cuando:

El negocio cambia por presiones externas. Las prioridades de gestión cambian. Cuando se dispone de nuevas tecnologías,

cambian los diseños y la implementación.

Iteración de procesosIan Sommerville, 4.2

El proceso del software no es un proceso único. Las actividades del proceso se repiten regularmente a

medida que el sistema se va rehaciendo, en respuesta a peticiones de cambios.

Hay dos modelos de procesos para apoyar esta iteración : Entrega incremental. La especificación, el diseño y la

implementación del software se dividen en una serie de incrementos, que se desarrollan por turnos.

Desarrollo en espiral. El desarrollo del sistema gira en espiral hacia fuera, empezando con un esbozo inicial y terminando con el desarrollo final.

Iteración de procesos

En los procesos iterativos, la especificación se desarrolla junto con el software.

Inconvenientes => conflictos en los contratos de desarrollo de software; donde se requiere una especificación completa del sistema previa, como etapa de evaluación del del contrato.

En el enfoque incremental, no existe una especificación completa del sistema hasta que llegamos al incremento final.

Iteración de procesos

El modelo de desarrollo en cascada requiere:1.Obtener los Requerimientos del Sistema antes de

empezar el Diseño.2.Que el Diseñador cumpla estrategias particulares de

Diseño antes de la Implementación. 3.Los cambios de Requerimientos implican rehacer el trabajo

de captura de Requerimientos, de Diseño e Implementación.

4.La separación de las etapas origina sistemas bien documentados, sólidos, que pueden evolucionar más fácilmente.

Entrega incrementalIan Sommerville, 4.2.1

En cambio, el Desarrollo Evolutivo tiene básicamente estas características:

1.Permite que los Requerimientos (Análisis) y las decisiones de Diseño se retrasen.

2.Origina un software débilmente estructurado y difícil de comprender y mantener.

Entrega incrementalDesarrollo Evolutivo

(caracteres)

La Entrega Incremental es un enfoque intermedio que combina las ventajas de ambos modelos:

Los clientes identifican, a grandes rasgos, los servicios que proporcionará el sistema.

Identifican qué servicios son más importantes y cuáles menos.

Entonces, se definen varios incrementos en donde cada uno proporciona una funcionalidad distinta del sistema.

Entrega incrementalCaracterísticas

Los incrementos que proporcionen servicios con mayor prioridad son desarrollados y entregados primero.

Una vez que se identifican los incrementos del sistema, se definen en detalle los requerimientos para los servicios que se van a entregar en el primer incremento, que es inmediatamente desarrollado.

Durante el desarrollo, se puede llevar a cabo un análisis adicional de requerimientos para los requerimientos posteriores, pero no se aceptan cambios en los requerimientos para el incremento actual.

Una vez que un incremento se completa y entrega, los clientes pueden ponerlo en servicio.


Hay una entrega temprana de partes de la funcionalidad del sistema.

El cliente puede experimentar con el sistema, lo que le ayuda a clarificar sus requerimientos para los incrementos posteriores y para las últimas versiones del incremento actual.

Tan pronto como se completan nuevos incrementos, se integran en los existentes.

La funcionalidad del sistema mejora con cada incremento entregado.


Los servicios comunes se pueden implementar al inicio del proceso o de forma incremental tan pronto como sean requeridos.


1. Los clientes no tienen que esperar a que se entregue el sistema completo para poder sacarle provecho. El primer incremento satisface los requerimientos más críticos y se puede utilizar el software inmediatamente.

2. Los clientes pueden utilizar los incrementos iniciales como prototipos y obtener experiencia sobre los requerimientos de los incrementos posteriores.

3. Existe un bajo riesgo de falla total del proyecto. Aunque se pueden encontrar problemas en algunos incrementos, lo normal es que el sistema se entregue de forma satisfactoria.

Entrega incrementalVentajas

4. Como los servicios más prioritarios se entregan primero, y los incrementos posteriores se integran, después, en ellos; a esos servicios más importantes se les hacen más pruebas.

Así, es menos probable que haya fallas en las partes más importantes del sistema.

Entrega incrementalVentajas

Los incrementos deben ser relativamente pequeños (no más de 20.000 líneas de código) y cada uno debe entregar alguna funcionalidad del sistema.

Puede ser difícil adaptar los requerimientos del cliente a incrementos de tamaño apropiado.

Muchos sistemas requieren un conjunto de recursos que se utilizan en diferentes partes del sistema.

Como los requerimientos no se definen en detalle hasta que un incremento se implementa, puede ser difícil identificar los recursos comunes que requieren todos los incrementos.

Entrega incrementalDesventajas

El modelo en espiral del proceso del software fue propuesto por Boehm (1988).

No representa al proceso del software como una secuencia de actividades, sino como una espiral.

Cada ciclo en la espiral representa una fase del proceso del software.

Así. el ciclo más interno alude a la Viabilidad del Sistema, el siguiente ciclo a la Definición de Requerimientos, el siguiente ciclo al Diseño del Sistema, y así sucesivamente.

Desarrollo en espiralIan Sommerville, 4.2.2

Cada ciclo de la espiral se divide en cuatro sectores:

1. Definición de objetivos. Para esta fase del proyecto se definen los objetivos específicos.

Se identifican las restricciones del proceso y el producto, y se traza un plan detallado de gestión.

Se identifican los riesgos del proyecto. Dependiendo de estos riesgos, se planean

estrategias alternativas.

Desarrollo en espiral4 Sectores de cada Ciclo

2. Evaluación y reducción de riesgos. Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto identificados.

Se definen los pasos para reducir dichos riesgo.

Por ejemplo, si existe el riesgo de tener requerimientos inapropiados, se puede desarrollar un prototipo del sistema.


3. Desarrollo y validación. Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema.

Por ejemplo, si hay riesgos en la interfaz de usuario => construir prototipos evolutivos.

Si hay riesgos de seguridad => un desarrollo basado

en transformaciones formales. Si el mayor riesgo es la integración de los

subsistemas => Modelo en Cascada.


4. Planificación. El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral.

Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto.


Desarrollo en espiralFigura Ilustrativa

La diferencia principal entre el modelo en espiral y los otros modelos es la consideración explícita del riesgo en el modelo en espiral.

El riesgo significa sencillamente que algo puede ir mal.

Por ejemplo, si se quiere utilizar un nuevo lenguaje de programación, un riesgo es que los compiladores disponibles sean poco fiables o que no produzcan código objeto suficientemente eficiente.

Desarrollo en espiralLa consideración del RIESGO

Los riesgos originan problemas en el proyecto; como ser: problemas de agendas y excesos en los costos.

Por eso la disminución de riesgos es una actividad muy importante en la gestión del proyecto.

Un ciclo de la espiral empieza con la elaboración de objetivos, como el rendimiento y la funcionalidad.

Entonces se enumeran alternativas de alcanzar estos objetivos y las restricciones de cada una.

Desarrollo en espiralLa consideración del

RIESGO

Cada alternativa se evalúa contra cada objetivo Se identifican las fuentes de riesgo del proyecto. El siguiente paso es resolver estos riesgos,

mediante: la recopilación de información, detallar más el análisis, la construcción de prototipos y la simulación.

Una vez que se han evaluado los riesgos, se desarrolla, seguido de una actividad de planificación para la siguiente fase del proceso.

Desarrollo en espiralConclusiones

Modelos evolutivos. incremental y espiral

Documents