Con la
variante trata de ajustarse más a la realidad de lo que es un proyecto de
desarrollo de software, en el cual el resultado final no es exactamente la
implementación del catálogo de requisitos, sino que una vez definido se
renegocia el alcance del mismo, incluso en diversas partes del proyecto, entre
cliente y proveedor con el objetivo de intentar que ambas partes queden
satisfechas (aunque en la mayoría de los casos, cada parte solo se mire su
ombligo).
La variante
se basa en la inclusión de tres etapas o regiones al principio:
1.- Identificar las partes interesadas (stakeholders) para esta nueva iteración del producto: Es
necesario definir los interlocutores que serán de áreas que se verán afectadas
por el resultado final de la nueva versión. Estos interlocutores serán del área
del cliente (puede haber más de uno) y del proveedor.
2.-
Identificar las condiciones de victoria de las partes interesadas en el
proyecto: Se concreta cuáles son las condiciones que requiere cada parte para
que se sienta satisfecha una vez realizada esta versión.
3a.- Reunir
las condiciones de victoria: Con las etapas anteriores se han definido unos
objetivos generales para la versión y se obtiene conocimiento de los objetivos
particulares de cada parte. Ahora toca negociar hasta dónde realmente se va a
llegar y cómo, intentando llegar a una solución en la que todos ganen (cliente
y proveedor).
Las
siguientes etapas tienen una correspondencia con algunas variantes, con la
versión inicial del ciclo de vida en espiral:
3b.- Establecer
los objetivos, restricciones y alternativas del siguiente nivel: Teniendo en
cuenta los objetivos y acuerdos de las fases anteriores, se definirían los
requisitos de esta versión, además de especificarse diversas alternativas en el
caso de que existan.
4.- Evaluar
las alternativas del producto y del proceso y resolución de riesgos: Se
realizaría el análisis del riesgo típico de los modelos en espiral.
5.- Definir
el siguiente nivel del producto y del proceso, incluyendo particiones: Esta
etapa completaría el proceso de análisis y realizaría el diseño y la
construcción.
6.- Validar
las definiciones del producto y del proceso: Comprendería la implantación y
aceptación de la versión, verificándose si el resultado de la iteración
satisface el alcance indicado.
7.- Revisión
y comentarios: Tocaría hacer inventario, medir el nivel de satisfacción de las
partes, el nivel de cumplimiento de objetivos con el objetivo sobre todo de
intentar aprender de los errores para mejorar en versiones sucesivas y de
detectar correcciones y mejoras a realizar en el producto.
Lo más
interesante del modelo es que se especifique de forma explícita la necesidad de
que las partes negocien para llegar a un acuerdo satisfactorio para todos, por
eso esta variante recibe el nombre de Win Win. Aunque es complicado alcanzar un
equilibrio en el que ambas partes ganen a un 50%, sí que es fundamental que
independientemente de si uno es un poco más ganador que el otro, todas las
partes estén convencidas en que el acuerdo es bueno.
En cualquier
caso sigue sin ser absolutamente realista con respecto al transcurso normal de
un proyecto de desarrollo de software, donde la negociación se extiende en
muchos proyectos hasta el mismo proceso de construcción del sistema de
información, no obstante, si los incrementos no son muy grandes no tendría por qué
extenderse tanto la negociación, no obstante, como en este tipo de modelos de
ciclo de vida, en cada iteración (incluida la primera) se intenta tener un
producto funcionando, salvo que éste sea trivial, las primera etapa por lo
menos tendrá tamaño suficiente para que en muchos casos nos encontremos con
casos donde se estén negociando aspectos del proyecto hasta el final.
No hay comentarios:
Publicar un comentario