MODELO EVOLUTIVO
El desarrollo evolutivo
consta del desarrollo de una versión inicial que luego de exponerse se va
refinando de acuerdo de los comentarios o nuevos requerimientos por parte del
cliente o del usuario final. Las fases de especificación, desarrollo y
validación se entrelazan en vez de separarse.
Existen dos tipos de desarrollo evolutivo
1.
Desarrollo exploratorio: donde el objetivo del
proceso es trabajar 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: Donde
el objetivo del proceso de desarrollo evolutivo es comprender los
requerimientos del cliente y entonces desarrollar una definición mejorada de
los requerimientos para el sistema. Desde el punto de
vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en
comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades
del cliente, a la vez que él mismo entiende mejor sus propios requerimientos.
Desventajas:
Ø El proceso no es visible. Los administradores tienen
que 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.
Ø A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden
a corromper la estructura del software. Incorporar cambios en él se convierte
cada vez más en una tarea difícil y costosa.
Aunque supone grandes
ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeños y
medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo
dificultan la estabilidad y la integración de los avances de los distintos
grupos de trabajo que puedan existir. La mayoría de las empresas que
desarrollan grandes sistemas usan un modelo mixto que usa las mayores
fortalezas de los enfoques evolutivos y de cascada.
MODELO INCREMENTAL.
El modelo incremental
es una evolución del modelo de cascada; viene a suplir el problema de no poder
retroceder en las fases de desarrollo del software. Es, por tanto, un modelo no
secuencial.
El funcionamiento
es sencillo. Comienza con el análisis de los requisitos, tras el cual se
prepara un primer diseño. La novedad de este modelo respecto del anterior, es
la introducción de iteraciones para “bifurcar” diseños. Es decir, este modelo
ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc. del
software, que de no convencer al cliente (o al propio programador) es rechazado
y se comienza con una segunda iteración (o un segundo diseño), sin necesidad de
realizar un nuevo análisis de requisitos. Pueden realizarse tantas iteraciones
(también llamadas incrementos) como sean necesarias.
El modelo
incremental por otra parte es una unión de las mejores funcionalidades del
modelo de cascada y del modelo de prototipos. A medida que se presenta un
prototipo se produce un “incremento”, que es una interacción del proceso
anterior pero aplicando las experiencias aprendidas del proceso anterior. A
diferencia del modelo de prototipos, los prototipos de este modelo están
orientados a ser operacionales en cada incremento y no ser solo una “previa” de
cómo sería el sistema en su versión final.
MODELO ESPIRAL
Es un
modelo de desarrollo evolutivo propuesto por Barry Boehm, que utiliza
prototipos como apoyo. La forma de espiral representa una interacción
(repetición) de procesos que, a medida que se van entregando prototipos y éstos
son revisados por los clientes o usuarios finales, el tiempo empleado para
desarrollar la próxima versión es cada vez mayor. Cada división recibe el
nombre de región de tareas.
Aunque el
modelo espiral representa ventajas por sobre el desarrollo lineal, el cálculo
de los riesgos puede ser muy complicado y no es tan usado en la realidad.
Modelo Espiral WINWIN
Una variante interesante del Modelo Espiral
es el Modelo espiral Win-Win. El Modelo Espiral previo (clásico) sugiere la
comunicación con el cliente para fijar los requisitos, en que simplemente se
pregunta al cliente qué necesita y él proporciona la información para
continuar, sin embargo, esta es una situación que rara vez ocurre. Normalmente
el cliente y desarrollador entran en una negociación, se negocia coste frente a
funcionalidad, rendimiento, calidad, etc.
Las
mejores negociaciones se fuerzan en obtener <<Victoria & Victoria»
(Win & Win), es decir que el cliente gane obteniendo el producto que lo
satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de
entrega realista. Evidentemente, este modelo requiere fuertes habilidades de
negociación.
No hay comentarios:
Publicar un comentario