lunes, 3 de agosto de 2009

MODELO INCREMENTAL EVOLUTIVO

Modelo De Desarrollo Incremental


La propuesta del modelo es diseñar sistemas que puedan entregarse por piezas.

  • A partir de la evaluación se planea el siguiente incremento y así sucesivamente
  • Es interactivo por naturaleza
  • Es útil cuando el personal no es suficiente para la implementación completa
  • En lugar de entrega del sistema en una sola entrega, el desarrollo y la entrega están fracturados bajo incrementos, con cada incremento que entrega parte de la funcionalidad requerida.
  • Los requerimientos del usuario se priorizan y los requerimientos de prioridad más altos son incluidos en los incrementos tempranos.
  • Hechos de incrementos tempranos como un prototipo, ayudan a obtener requisitos para los incrementos más tardíos.
  • Los usuarios no tiene que esperar.
  • Pueden aumentar el coste debido a las pruebas.
  • El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema.
  • El modelo incremental presupone que el conjunto completo de requerimientos es conocido al comenzar
  • Se evitan proyectos largos y se entrega “Algo de valor” a los usuarios con cierta frecuencia
  • El usuario se involucra más
  • Riesgos largos y complejos.
  • Difícil de aplicar a sistemas transaccionales que tienden a serintegrados y a operar como un todo
  • Requiere gestores experimentados
  • Los errores en los requisitos se detectan tarde.

Bajo este modelo se entrega software “por partes funcionales más pequeñas” , pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.

Beneficios:

  • Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
  • Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
  • Si un error importante es realizado, sólo la última iteración necesita ser descartada.
  • Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
  • Si un error importante es realizado, el incremento previo puede ser usado.
    Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento
  • El resultado puede ser muy positivo

Modelo De Desarrollo Evolutivo

  • Construcción de una implementación parcial que cubre los requisitos conocidos, para ir aprendiendo el resto y, paulatinamente, incorporarlos al sistema
  • El software evoluciona con el tiempo(Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo).
  • En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estén diseñados para acomodarse a una evolución temporal o progresiva, donde los requisitos
  • construye una serie de grandes versiones sucesivas de un producto.
  • El modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.
  • En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento.
  • Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.
  • El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores.
  • Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.
  • El desarrollo evolutivo es 100% compatible con el modelo cascada.
  • No se conocen niveles apropiados de calidad y documentación
  • Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se debe introducir una versión funcional limitada de alguna forma para aliviar las presiones competitivas.
  • Reduce el riesgo y aumenta la probabilidad de éxito
  • Problemas de gestión de configuración

El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.

Ejemplo:

Un procesador de texto que sea desarrollado bajo el paradigma Incremental podría aportar, en principio, funciones básicas de edición de archivos y producción de documentos (algo como un editor simple). En un segundo incremento se le podría agregar edición más sofisticada, y de generación y mezcla de documentos. En un tercer incremento podría considerarse el agregado de funciones de corrección ortográfica, esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones matemáticas. Así sucesivamente hasta llegar al procesador final requerido. Así, el producto va creciendo, acercándose a su meta final, pero desde la entrega del primer incremento ya es útil y funcional para el cliente, el cual observa una respuesta rápida en cuanto a entrega temprana; sin notar que la fecha límite del proyecto puede no estar acotada ni tan definida, lo que da margen de operación y alivia presiones al equipo de desarrollo.

Como se dijo, el Iterativo Incremental es un modelo del tipo evolutivo, es decir donde se permiten y esperan probables cambios en los requisitos en tiempo de desarrollo; se admite cierto margen para que el software pueda evolucionar. Aplicable cuando los requisitos son medianamente bien conocidos pero no son completamente estáticos y definidos.

Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software. Este modelo brinda cierta flexibilidad para que durante el desarrollo se incluyan cambios en los requisitos por parte del usuario, un cambio de requisitos propuesto y aprobado puede analizarse e implementarse como un nuevo incremento o, eventualmente, podrá constituir una mejora/adecuación de uno ya planeado.

2 comentarios: