Especificacin Inicial

Desarrollo del Producto

Implementacin, Uso y Evaluacin

Versiones del Software

Re- espicificacin

Ingeniera en Sistemas de Informacin

Diseo de Sistemas (3K1)

Contenidos de la Unidad 1 Introduccin al Diseo

a. Significado Dentro del Ciclo de Vida de Desarrollo de Sistemas. b. Modelos de Desarrollo de software i. Modelos de Desarrollo Estructurado 1. Modelo en Cascada. 2. Modelos evolutivos: incremental y espiral. 3. RUP

Sommerville. Seccin 8.5 y 4.5.1 Pressman. Seccin 2.10

Sommervillle. Seccin 4.1.1. Pressman. Seccin 2.4. Sommervillle. Seccin 4.1.2. y 4.2 Pressman. Seccin 2.7 Sommervillle. Seccin 4.4. Jacobson, Booch y Rounbahg. Secciones 1.1 a a 1.5. Larman lt. Ed. Seccin 37.1., 37.4 y 37.9

Unidad I: Modelos Evolutivos:

Incremental y Espiral
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.

Unidad I: Modelos Evolutivos:

Figura Ilustrativa

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.