MODELOS EVOLUTIVOS

MODELO INCREMENTAL MODELO ITERATIVO DE PROCESOS MODELO ESPIRAL MODELO DE PROTOTIPOS

Unidad 3: Modelos Evolutivos: Incremental,

Iterativo, espiral, de prototipos

Ingeniera del Software, 7 Edicin, por Ian Sommerville, 4.1.2. Desarrollo Evolutivo: se basa en la idea de desarrollar una implementacin inicial, exponindola a los comentarios del usuario y refinndola a travs de las diferentes versiones hasta que se desarrolla un sistema adecuado. Las actividades de especificacin, desarrollo y validacin se entrelazan, en vez de separarse, con una rpida retroalimentacin entre stas.

Modelo de desarrollo evolutivo:

Tipos de Modelos Evolutivos

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 definicin mejorada de los requerimientos. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Ventajas del Modelo Evolutivo

Es ms efectivo que el enfoque en cascada, pues satisface las necesidades inmediatas de los clientes.
La especificacin se puede desarrollar de forma creciente. Tan pronto como el usuario entienda mejor su problema, ste se puede reflejar en el sistema software.

Desventajas del Modelo Evolutivo

1. El proceso no es visible. Los administradores deben hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rpidamente, no es rentable producir documentos que reflejen cada versin del sistema. 2. Genera sistemas con estructura deficiente. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios se convierte cada vez ms en una tarea difcil y costosa.

Recomendaciones para el Modelo Evolutivo

Para sistemas pequeos y medios (de hasta 500.000 lneas de cdigo), 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 difcil 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 caractersticas del modelo en cascada y del desarrollo evolutivo. Se puede desarrollar un prototipo desechable (enfoque evolutivo) para resolver incertidumbres en la especificacin 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 difciles de especificar por adelantado (interfaz de usuario), se pueden desarrollar usando un enfoque de programacin exploratoria.

Iteracin de procesos
Ian Sommerville, 4.2
Los cambios son inevitables en todos los proyectos de software grandes. Hay cambios cuando: El negocio cambia por presiones externas. Las prioridades de gestin cambian. Cuando se dispone de nuevas tecnologas, cambian los diseos y la implementacin.

Iteracin de procesos
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 iteracin : 1. Entrega incremental. La especificacin, el diseo y la implementacin del software se dividen en una serie de incrementos, que se desarrollan por turnos. 2. Desarrollo en espiral. El desarrollo del sistema gira en espiral hacia fuera, empezando con un esbozo inicial y terminando con el desarrollo final.

Iteracin de procesos
En los procesos iterativos, la especificacin se desarrolla junto con el software. Inconvenientes => conflictos en los contratos de desarrollo de software; donde se requiere una especificacin completa del sistema previa, como etapa de evaluacin del del contrato. En el enfoque incremental, no existe una especificacin completa del sistema hasta que llegamos al incremento final.

Entrega incremental Ian Sommerville, 4.2.1

El modelo de desarrollo en cascada requiere: 1. Obtener los Requerimientos del Sistema antes de empezar el Diseo. 2. Que el Diseador cumpla estrategias particulares de Diseo antes de la Implementacin. 3. Los cambios de Requerimientos implican rehacer el trabajo de captura de Requerimientos, de Diseo e Implementacin. 4. La separacin de las etapas origina sistemas bien documentados, slidos, que pueden evolucionar ms fcilmente.

Entrega incremental Desarrollo Evolutivo (caracteres)

En cambio, el Desarrollo Evolutivo tiene bsicamente estas caractersticas: 1. Permite que los Requerimientos (Anlisis) y las decisiones de Diseo se retrasen. 2. Origina un software dbilmente estructurado y difcil de comprender y mantener.

Entrega incremental Caractersticas

La Entrega Incremental es un enfoque intermedio que combina las ventajas de ambos modelos: 1. Los clientes identifican, a grandes rasgos, los servicios que proporcionar el sistema. 2. Identifican qu servicios son ms importantes y cules menos. 3. Entonces, se definen varios incrementos en donde cada uno proporciona una funcionalidad distinta del sistema.

Entrega incremental Caractersticas

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

Entrega incremental Caractersticas

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.

Entrega incremental Caractersticas

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

Entrega incremental Ventajas

1. Los clientes no tienen que esperar a que se entregue el sistema completo para poder sacarle provecho. El primer incremento satisface los requerimientos ms crticos 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 incremental Ventajas

4. Como los servicios ms prioritarios se entregan primero, y los incrementos posteriores se integran, despus, en ellos; a esos servicios ms importantes se les hacen ms pruebas. As, es menos probable que haya fallas en las partes ms importantes del sistema.

Entrega incremental Desventajas

Los incrementos deben ser relativamente pequeos (no ms de 20.000 lneas de cdigo) y cada uno debe entregar alguna funcionalidad del sistema. Puede ser difcil adaptar los requerimientos del cliente a incrementos de tamao 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 difcil identificar los recursos comunes que requieren todos los incrementos.

Desarrollo en espiral Ian Sommerville, 4.2.2

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 ms interno alude a la Viabilidad del Sistema, el siguiente ciclo a la Definicin de Requerimientos, el siguiente ciclo al Diseo del Sistema, y as sucesivamente.

Desarrollo en espiral 4 Sectores de cada Ciclo

Cada ciclo de la espiral se divide en cuatro sectores: 1. Definicin de objetivos. Para esta fase del proyecto se definen los objetivos especficos. Se identifican las restricciones del proceso y el producto, y se traza un plan detallado de gestin. Se identifican los riesgos del proyecto. Dependiendo de estos riesgos, se planean estrategias alternativas.

Desarrollo en espiral 4 Sectores de cada Ciclo

2. Evaluacin y reduccin de riesgos. Se lleva a cabo un anlisis 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.

Desarrollo en espiral 4 Sectores de cada Ciclo

3. Desarrollo y validacin. Despus de la evaluacin 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 integracin de los subsistemas => Modelo en Cascada.

Desarrollo en espiral 4 Sectores de cada Ciclo

4. Planificacin. El proyecto se revisa y se toma la decisin 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 espiral
Figura Ilustrativa

Desarrollo en espiral
La consideracin del RIESGO
La diferencia principal entre el modelo en espiral y los otros modelos es la consideracin explcita 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 programacin, un riesgo es que los compiladores disponibles sean poco fiables o que no produzcan cdigo objeto suficientemente eficiente.

Desarrollo en espiral La consideracin del RIESGO

Los riesgos originan problemas en el proyecto; como ser: problemas de agendas y excesos en los costos. Por eso la disminucin de riesgos es una actividad muy importante en la gestin del proyecto. Un ciclo de la espiral empieza con la elaboracin de objetivos, como el rendimiento y la funcionalidad. Entonces se enumeran alternativas de alcanzar estos objetivos y las restricciones de cada una.

Desarrollo en espiral Conclusiones

Cada alternativa se evala contra cada objetivo Se identifican las fuentes de riesgo del proyecto. El siguiente paso es resolver estos riesgos, mediante: la recopilacin de informacin, detallar ms el anlisis, la construccin de prototipos y la simulacin. Una vez que se han evaluado los riesgos, se desarrolla, seguido de una actividad de planificacin para la siguiente fase del proceso.

EL MODELO PROTOTIPADO
El Prototipado consiste en construir un modelo del software a fabricar para que lo evale el cliente en conjunto con el programador. La construccin de un prototipo suele ser muy adecuado al comienzo de la etapa de "anlisis", ya que el modelo es el nico medio a travs del cual se pueden obtener de una manera ms eficaz los requisitos. El modelo evoluciona despus hacia la produccin del software. En la figura anterior se muestra las diferentes etapas por la que atraviesa la metodologa por Prototipos

Modelo en prototipos

Comunicacin

Desarrollo, Entrega y retroalimentacin

Plan rpido

Metodologa mas conocida de desarrollo de software basada en prototipos o tambin llamada El Prototipado

Construccin del prototipo

Modelado de diseo rpido

Comunicacin: Se inicia cuando el ingeniero de software y el cliente se encuentran y definen los objetivos globales para el software, se identifican los requisitos ya conocidos y las reas del esquema en donde se necesitara mas definicin. Plan rpido: Se plantea con rapidez una iteracin de construccin de prototipos y se presenta el modelo (en forma de un diseo rpido). El diseo rpido se centra en una representacin de aquellos aspectos del software que sean visibles para el cliente o el usuario final(ejemplo: la configuracin de la interfaz con el usuario, el formato de despliegue de salida). Diseo rpido: Conduce a la construccin del prototipo

Existen dos enfoques para utilizar prototipos, el denominado enfoque cerrado tambin denominado prototipo desechable tiene como nico objetivo el poder demostrar y recolectar requisitos, luego este se desecha y se encara el desarrollo con un punto de vista diferente. Por su parte el enfoque abierto o Prototipado evolutivo. Este mtodo utiliza el mismo enfoque en las primeras etapa de anlisis y luego se contina con el diseo y la construccin. Muchos usuarios finales suelen mostrar gran entusiasmo cuando se le presenta un prototipo del futuro software por lo que la situacin suele ser adecuada para evaluar como seria la futura interaccin entre el usuario y el software a construirse.

El ciclo comienza con la: Recoleccin de requisitos. El cliente y el desarrollador definen los objetivos globales para el software, identifican los requisitos conocidos y que reas del problema requiere una atencin. Luego se procede a realizar un Diseo rpido. Este diseo rpido busca una representacin sobre aspectos del software que sern importantes para el cliente/usuario como ser el diseo de pantallas y operatividad. A seguir se construye el prototipo. Este prototipo lo evala el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar.

 Cuando el prototipo satisface las necesidades del usuario/cliente y el programador tiene una clara comprensin de lo que se necesita hacer se procede a una nueva iteracin. VENTAJAS Y DESVENTAJAS DEL MODELO DE PROTOTIPADO VENTAJAS : Reduccin de la incertidumbre y del riesgo, reduccin de tiempo y de costos ,incrementos en la aceptacin del nuevo sistema, mejoras en la administracin de proyectos , mejoras en la comunicacin entre desarrolladores y clientes .

DESVENTAJAS: La dependencia de las herramientas del software para el xito ya que la necesidad de disminucin de incertidumbre depende de las iteraciones del prototipo, entre ms iteraciones existan mejor y esto ltimo se logra mediante el uso de mejores herramientas lo que hace a este proceso dependiente de las mismas. No es posible aplicar la metodologa a todos los proyectos de software y finalmente, la mala interpretacin que pueden hacer los usuarios del prototipo, al cual pueden confundir con el sistema terminado