Modelos evolutivos. incremental y espiral

41,855 views

Published on

Unidad I. Diseño de Sistemas. Modelos Evolutivos: Incremental y Espiral. (3K1) UTN-FRT (2011). Sommerville, 4.1.2 y 4.2

3 Comments
8 Likes
Statistics
Notes
No Downloads
Views
Total views
41,855
On SlideShare
0
From Embeds
0
Number of Embeds
4,153
Actions
Shares
0
Downloads
675
Comments
3
Likes
8
Embeds 0
No embeds

No notes for slide

Modelos evolutivos. incremental y espiral

  1. 1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
  2. 2. Contenidos de la Unidad 1 Introducción al Diseño <ul><li>Significado Dentro del Ciclo de Vida de Desarrollo de Sistemas. </li></ul>  b. Modelos de Desarrollo de software   <ul><ul><ul><li>Modelos de Desarrollo Estructurado </li></ul></ul></ul>Sommerville. Sección 8.5 y 4.5.1 Pressman. Sección 2.10 <ul><ul><ul><ul><li>Modelo en Cascada. </li></ul></ul></ul></ul>Sommervillle. Sección 4.1.1. Pressman. Sección 2.4. <ul><ul><ul><ul><li>2. Modelos evolutivos: incremental y espiral. </li></ul></ul></ul></ul>Sommervillle. Sección 4.1.2. y 4.2 Pressman. Sección 2.7 <ul><ul><ul><ul><li>3. RUP </li></ul></ul></ul></ul>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
  3. 3. <ul><li>« Ingeniería del Software », 7ª Edición , por Ian Sommerville, 4.1.2 . </li></ul><ul><li>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. </li></ul><ul><li>Las actividades de especificación, desarrollo y validación se entrelazan, en vez de separarse, con una rápida retroalimentación entre éstas. </li></ul>Unidad I: Modelos Evolutivos: Incremental y Espiral
  4. 4. Unidad I: Modelos Evolutivos: Figura Ilustrativa
  5. 5. <ul><li>Hay 2 tipos de desarrollo evolutivo: </li></ul><ul><li>1. Desarrollo exploratorio : Trabaja con el cliente para explorar sus requerimientos y entregar un sistema final. </li></ul><ul><li>El desarrollo empieza con las partes del sistema que se comprenden mejor. </li></ul><ul><li>El sistema evoluciona agregando nuevos atributos propuestos por el cliente. </li></ul><ul><li>2. Prototipos desechables : Busca comprender los requerimientos del cliente y desarrollar una definición mejorada de los requerimientos. </li></ul><ul><li>El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo. </li></ul>Tipos de Modelos Evolutivos
  6. 6. <ul><li>Es más efectivo que el enfoque en cascada , pues satisface las necesidades inmediatas de los clientes . </li></ul><ul><li>La especificación se puede desarrollar de forma creciente . </li></ul><ul><li>Tan pronto como el usuario entienda mejor su problema, éste se puede reflejar en el sistema software. </li></ul>Ventajas del Modelo Evolutivo
  7. 7. <ul><li>1. El proceso no es visible . Los administradores deben hacer entregas regulares para medir el progreso. </li></ul><ul><li>Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema . </li></ul><ul><li>2. Genera sistemas con estructura deficiente . Los cambios continuos tienden a corromper la estructura del software. </li></ul><ul><li>Incorporar cambios se convierte cada vez más en una tarea difícil y costosa. </li></ul>Desventajas del Modelo Evolutivo
  8. 8. <ul><li>Para sistemas pequeños y medios (de hasta 500.000 líneas de código), el enfoque evolutivo de desarrollo es el mejor. </li></ul><ul><li>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. </li></ul><ul><li>Es difícil establecer una arquitectura del sistema estable con este enfoque, por la dificultad en integrar las contribuciones de los equipos. </li></ul>Recomendaciones para el Modelo Evolutivo
  9. 9. <ul><li>Para sistemas grandes, se recomienda un proceso mixto que incorpore las mejores características del modelo en cascada y del desarrollo evolutivo. </li></ul><ul><li>Se puede desarrollar un prototipo desechable (enfoque evolutivo) para resolver incertidumbres en la especificación del sistema. </li></ul><ul><li>Entonces, las partes del sistema bien comprendidas se pueden especificar y desarrollar utilizando un proceso basado en el modelo en cascada. </li></ul><ul><li>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. </li></ul>Recomendaciones para el Modelo Evolutivo
  10. 10. <ul><li>Los cambios son inevitables en todos los proyectos de software grandes. Hay cambios cuando: </li></ul><ul><li>El negocio cambia por presiones externas. </li></ul><ul><li>Las prioridades de gestión cambian. </li></ul><ul><li>Cuando se dispone de nuevas tecnologías, cambian </li></ul><ul><li>los diseños y la implementación. </li></ul>Iteración de procesos Ian Sommerville, 4.2
  11. 11. <ul><li>El proceso del software no es un proceso único. </li></ul><ul><li>Las actividades del proceso se repiten regularmente a medida que el sistema se va rehaciendo, en respuesta a peticiones de cambios. </li></ul><ul><li>Hay dos modelos de procesos para apoyar esta iteración : </li></ul><ul><li>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. </li></ul><ul><li>Desarrollo en espiral. El desarrollo del sistema gira en espiral hacia fuera, empezando con un esbozo inicial y terminando con el desarrollo final. </li></ul>Iteración de procesos
  12. 12. <ul><li>En los procesos iterativos, la especificación se desarrolla junto con el software . </li></ul><ul><li>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. </li></ul><ul><li>En el enfoque incremental, no existe una especificación completa del sistema hasta que llegamos al incremento final. </li></ul>Iteración de procesos
  13. 13. <ul><li>El modelo de desarrollo en cascada requiere : </li></ul><ul><li>Obtener los Requerimientos del Sistema antes de empezar el Diseño . </li></ul><ul><li>Que el Diseñador cumpla estrategias particulares de Diseño antes de la Implementación . </li></ul><ul><li>Los cambios de Requerimientos implican rehacer el trabajo de captura de Requerimientos , de Diseño e Implementación . </li></ul><ul><li>La separación de las etapas origina sistemas bien documentados, sólidos, que pueden evolucionar más fácilmente . </li></ul>Entrega incremental Ian Sommerville, 4.2.1
  14. 14. <ul><li>En cambio, el Desarrollo Evolutivo tiene básicamente estas características: </li></ul><ul><li>Permite que los Requerimientos ( Análisis ) y las decisiones de Diseño se retrasen. </li></ul><ul><li>Origina un software débilmente estructurado y difícil de comprender y mantener. </li></ul>Entrega incremental Desarrollo Evolutivo (caracteres)
  15. 15. <ul><li>La Entrega Incremental es un enfoque intermedio que combina las ventajas de ambos modelos: </li></ul><ul><li>Los clientes identifican, a grandes rasgos, los servicios que proporcionará el sistema. </li></ul><ul><li>Identifican qué servicios son más importantes y cuáles menos. </li></ul><ul><li>Entonces, se definen varios incrementos en donde cada uno proporciona una funcionalidad distinta del sistema. </li></ul>Entrega incremental Características
  16. 16. <ul><li>Los incrementos que proporcionen servicios con mayor prioridad son desarrollados y entregados primero. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>Una vez que un incremento se completa y entrega, los clientes pueden ponerlo en servicio. </li></ul>Entrega incremental Características
  17. 17. <ul><li>Hay una entrega temprana de partes de la funcionalidad del sistema. </li></ul><ul><li>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. </li></ul><ul><li>Tan pronto como se completan nuevos incrementos, se integran en los existentes. </li></ul><ul><li>La funcionalidad del sistema mejora con cada incremento entregado. </li></ul>Entrega incremental Características
  18. 18. <ul><li>Los servicios comunes se pueden implementar al inicio del proceso o de forma incremental tan pronto como sean requeridos . </li></ul>Entrega incremental Características
  19. 19. <ul><li>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. </li></ul><ul><li>2. Los clientes pueden utilizar los incrementos iniciales como prototipos y obtener experiencia sobre los requerimientos de los incrementos posteriores. </li></ul><ul><li>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 . </li></ul>Entrega incremental Ventajas
  20. 20. <ul><li>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. </li></ul><ul><li>Así, es menos probable que haya fallas en las partes más importantes del sistema. </li></ul>Entrega incremental Ventajas
  21. 21. <ul><li>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. </li></ul><ul><li>Puede ser difícil adaptar los requerimientos del cliente a incrementos de tamaño apropiado. </li></ul><ul><li>Muchos sistemas requieren un conjunto de recursos que se utilizan en diferentes partes del sistema. </li></ul><ul><li>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. </li></ul>Entrega incremental Desventajas
  22. 22. <ul><li>El modelo en espiral del proceso del software fue propuesto por Boehm (1988). </li></ul><ul><li>No representa al proceso del software como una secuencia de actividades, sino como una espiral. </li></ul><ul><li>Cada ciclo en la espiral representa una fase del proceso del software. </li></ul><ul><li>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. </li></ul>Desarrollo en espiral Ian Sommerville, 4.2.2
  23. 23. <ul><li>Cada ciclo de la espiral se divide en cuatro sectores: </li></ul><ul><li>1. Definición de objetivos. Para esta fase del proyecto se definen los objetivos específicos. </li></ul><ul><li>Se identifican las restricciones del proceso y el producto, y se traza un plan detallado de gestión. </li></ul><ul><li>Se identifican los riesgos del proyecto. </li></ul><ul><li>Dependiendo de estos riesgos, se planean estrategias alternativas. </li></ul>Desarrollo en espiral 4 Sectores de cada Ciclo
  24. 24. <ul><li>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. </li></ul><ul><li>Se definen los pasos para reducir dichos riesgo. </li></ul><ul><li>Por ejemplo, si existe el riesgo de tener requerimientos inapropiados, se puede desarrollar un prototipo del sistema. </li></ul>Desarrollo en espiral 4 Sectores de cada Ciclo
  25. 25. <ul><li>3. Desarrollo y validación. Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema. </li></ul><ul><li>Por ejemplo, si hay riesgos en la interfaz de usuario => construir prototipos evolutivos. </li></ul><ul><li>Si hay riesgos de seguridad => un desarrollo basado </li></ul><ul><li>en transformaciones formales. </li></ul><ul><li>Si el mayor riesgo es la integración de los subsistemas => Modelo en Cascada. </li></ul>Desarrollo en espiral 4 Sectores de cada Ciclo
  26. 26. <ul><li>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. </li></ul><ul><li>Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. </li></ul>Desarrollo en espiral 4 Sectores de cada Ciclo
  27. 27. Desarrollo en espiral Figura Ilustrativa
  28. 28. <ul><li>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 . </li></ul><ul><li>El riesgo significa sencillamente que algo puede ir mal. </li></ul><ul><li>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. </li></ul>Desarrollo en espiral La consideración del RIESGO
  29. 29. <ul><li>Los riesgos originan problemas en el proyecto; como ser: problemas de agendas y excesos en los costos. </li></ul><ul><li>Por eso la disminución de riesgos es una actividad muy importante en la gestión del proyecto. </li></ul><ul><li>Un ciclo de la espiral empieza con la elaboración de objetivos, como el rendimiento y la funcionalidad. </li></ul><ul><li>Entonces se enumeran alternativas de alcanzar estos objetivos y las restricciones de cada una. </li></ul>Desarrollo en espiral La consideración del RIESGO
  30. 30. <ul><li>Cada alternativa se evalúa contra cada objetivo </li></ul><ul><li>Se identifican las fuentes de riesgo del proyecto. </li></ul><ul><li>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. </li></ul><ul><li>Una vez que se han evaluado los riesgos, se desarrolla, seguido de una actividad de planificación para la siguiente fase del proceso. </li></ul>Desarrollo en espiral Conclusiones

×