Descripción somera de la metodología
Originalmente el modelo espiral surge para sustituir la solución en fases del “modelo en cascada” con ciclos de experimentación y aprendizaje. El modelo incorpora un nuevo elemento en el desarrollo al cual denomina “análisis de riesgos”. El modelo es la unión del modelo de prototipos y la secuencialidad del clásico, esta mezcla permite construir un ciclo que inicia desde el centro, si el cliente prefiere hacer alguna modificación o mejoría al producto, se evalúan las diferentes alternativas y se crea un nuevo análisis de riesgos, con lo cual se forma una nueva vuelta de espiral. De esta manera se incrementa el número de vueltas hasta que el producto queda terminado. Con el tiempo este modelo fue evolucionando en distintas propuestas como el modelo espiral Victoria-Victoria (WinWin). Este nuevo modelo incorpora unas actividades para la comunicación con el cliente para lograr mejores negociaciones que beneficien tanto al desarrollador como al cliente.
.
Creadores
El creador del modelo en espiral fue Barry W. Boehm. Era un Programador-Analista en General Dynamics entre 1955 y 1959, sus intereses actuales de la investigación incluyen modelar de proceso del software, ingeniería de requisitos del software, las arquitecturas del software, métrica del software y los modelos del coste, los ambientes de la tecnología de dotación lógica, y tecnología de dotación lógica basada en el conocimiento. Sus contribuciones al campo incluyen el modelo constructivo del coste (COCOMO), el modelo espiral del proceso del software, el acercamiento de la teoría W (ganar-gane) a la determinación de la gerencia y de los requisitos del software y a dos ambientes avanzados de la tecnología de dotación lógica: el sistema y el quántum de la productividad del software de TRW saltan el ambiente.
Etapa de la Ingeniería Software el Desarrollo
PROCESO DE DESARROLLO DE SOFTWARE
Teoría-W
Teoría-W Boehm et al. 1994 está diseñado para una aplicación general y no es confinado al desarrollo de software. Las partes interesadas se definen como: Usuarios, clientes, desarrolladores, mantenedores, interfaces, probadores, reutilizadores, general público. Esencialmente, la teoría argumenta que un proyecto solo tendrá éxito si el crítico Los usuarios interesados, los clientes, los desarrolladores y los mantenedores son todos "ganadores", por lo tanto". El término WinWin. Si los requisitos de cualquiera de estos interesados son omitido, entonces se aplica una situación de ganar-perder}, por ejemplo, donde el cliente se cumplen los requisitos pero no los de los usuarios.
Tal escenario de ganar-perder es, en realidad, una situación de perder-perder porque un proyecto solo puede tener éxito si todas las partes importantes logran sus objetivos esenciales. Un típico ejemplo podría ser una situación en la que una pieza de software cubre el costo del cliente requisitos, pero en realidad no funciona de acuerdo con los requisitos del usuario. El ‘‘ ganador ’’ también pierde, ya que tendrá que soportar menos de rendimiento óptimo o enfrentarse a más gastos de desarrollo del software.
El modelo en espiral original [1] utiliza un enfoque cíclico para desarrollar elaboraciones cada vez más detallados de la definición de un sistema de software, culminando en versiones incrementales
de la capacidad operativa del sistema. Cada ciclo consta de cuatro actividades principales:
• Elaborar el sistema o subsistema de objetivos de productos y procesos, limitaciones y
alternativas
4 Barry Boehm, Hasan KITAPCI
• Evaluar las alternativas con respecto a los objetivos y limitaciones. Identificar y resolver las
principales fuentes de productos y procesos de riesgo
• Elaborar la definición del producto y del proceso
• Planificar el siguiente ciclo, y actualizar el plan de ciclo de vida, incluyendo la partición del sistema en subsistemas que deben abordarse en ciclos paralelos.
Esto puede incluir un plan para terminar el proyecto si es demasiado arriesgada o inviable. Asegurar el compromiso de la administración para proceder según lo previsto, desde su creación, el modelo en espiral se ha elaborado y ampliamente aplicado con éxito en numerosos proyectos. Sin embargo, algunas dificultades comunes llevaron USC-CSE y sus organizaciones afiliadas para extender el modelo al modelo espiral WinWin se describe en el siguiente texto.
Previamente visto es el «Modelo espiral Win-Win (Barry Boehm). 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; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.
«Es así que la obtención de requisitos requiere una negociación, que tiene éxito cuando ambas partes ganan».
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.
El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral;
Se definen las siguientes actividades:
1. Identificación del sistema o subsistemas clave de los directivos (*) (saber qué quieren).
2. Determinación de «condiciones de victoria» de los directivos (saber qué necesitan y los satisface)
3. Negociación de las condiciones «victoria» de los directivos para obtener condiciones «Victoria & Victoria» (negociar para que ambos ganen).
(*) Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por la organización si tiene éxito o criticado si no.
El nuevo modelo agrega actividades de front-end que muestran dónde los objetivos, limitaciones y alternativas provienen de. Esto permite a las partes interesadas más claramente Identificar las razones involucradas en la negociación de las condiciones ganadoras para el producto. Un aspecto clave del modelo es que introduce consideraciones económicas, de calidad del producto y de riesgo en los pasos de toma de decisiones e introduce exploración de compensación en el proceso para abordar riesgos y conflictos.
Metodología: iterativa
En cada vuelta o iteración hay que tener en cuenta:
· Los Objetivos: qué necesidad debe cubrir el producto.
· Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:
1. Características: experiencia del personal, requisitos a cumplir, etc.
2. Formas de gestión del sistema.
3. Riesgo asumido con cada alternativa.
· Desarrollar y Verificar: Programar y probar el software.
Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:
· Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:
1. Angular: Indica el avance del proyecto del software dentro de un ciclo.
2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.
Además del énfasis inicial puesto en la condición de ganar-ganar, el modelo también presenta tres etapas del proceso (puntos de anclaje), que ayudan a establecer la realización de un ciclo alrededor de la espiral y proporcionar los hitos de decisión antes de que el proyecto de producto de software.
Estos son:
Objetivos del Ciclo de Vida (Life Cycle Objectives - LCO) - Define una serie de objetivos para cada actividad de software más importantes (un conjunto de objetivos relacionados con la definición de los principales requisitos de nivel de producto).
Arquitectura del Ciclo de Vida (Life Cycle Architecture - LCA) - Establece los objetivos que deben cumplirse como la arquitectura de software se define.
Initial Operational Capability (Initial Operational Capability - IOC) - Representa un conjunto de objetivos asociados a la preparación del software para la instalación y distribución, la preparación previa a las instalaciones del sitio, asistencia requerida por todas las partes que utilizará o soporte técnico del software.
Con esta breve descripción se puede declarar que el Software de producción más rápido puede facilitarse a través de la participación colaborativa de las partes interesadas pertinentes además de ser barato a través de reproceso y mantenimiento reducciones.
Objetivo
El modelo Win-Win deriva su nombre del objetivo de estas negociaciones, es decir, "ganar-ganar". El cliente recibe el producto que satisface la mayoría de sus necesidades, y el desarrollador trabaja para alcanzar presupuestos y fechas de entrega. Para lograr este objetivo, se realizan varias actividades de negociación al principio de cada paso alrededor de la espiral.
Además, si encuentran consistentemente ellos equilibrar sus necesidades con las necesidades de otras partes interesadas, que tendrán expectativas más realistas acerca de cómo obtener todo lo que quieren. A medida que trabajan juntos para negociar sus requisitos, le dan la forma de proyectos, y sus visiones fusionadas se convierten en un sistema que todos los interesados puedan aceptar. Si, por el contrario, las partes interesadas no se negocian juntos, hay poca probabilidad de que el sistema resultante se adaptará a sus necesidades, y el proyecto fracasará.
Etapas, fases y/o procesos que propone la misma.
El modelo Espiral Win-Win 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.
Roles y/o intervinientes
Habrá cuatro roles de los stakeholders:
• Desarrollador: los miembros del equipo representarán las preocupaciones del desarrollador, como el uso de paquetes familiares, la estabilidad de los requisitos, la disponibilidad de herramientas de soporte y los enfoques técnicamente desafiantes.
• Cliente: los miembros del equipo representarán las inquietudes de los clientes, como la necesidad de desarrollar el sistema en una fecha determinada, presupuestos limitados para herramientas de soporte y enfoques técnicos de bajo riesgo.
• Usuario: trabajarán con su representante designado de la comunidad de usuarios para representar las inquietudes de los usuarios, tales como características de acceso multimedia particulares, tiempo de respuesta rápido, interfaz de usuario amigable, alta confiabilidad y flexibilidad de requisitos.
• Administrador del proyecto: le pregunta al cliente que necesita y el proporciona la información para continuar, además ajusta el número de iteraciones planeado que se requiere para completar el software.
Ventajas y Desventajas
VENTAJAS
1. El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
2. Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
3. El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
4. El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas
DESVENTAJAS
1. Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
2. Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
3. Genera mucho tiempo en el desarrollo de sistemas.
4. Requiere experiencia en la identificación de riesgos
Herramientas (software)
WinWin Tools – Paga – Uso Local
WinWin es un programa informático basado en estación de trabajo Unix que ayuda a la captura, negociación y coordinación de requisitos para un sistema grande. Se supone que un grupo de personas llamadas partes interesadas han firmado con el propósito expreso de discutiendo y refinando los requisitos de su sistema propuesto (Horowitz 1999).
WinWin-0, la versión inicial del sistema de soporte, se implementó además de Percepción CAGErPMW. Se realizó un "experimento de arranque" en la Universidad del Centro de Ingeniería de Software del Sur de California USC-CSE con WinWin-0. Usándolo para modelar la próxima versión de la Universidad del Sur de California USC® propio producto WinWin.
Easy WinWin - PAGA - USO LOCAL Y NUBE
EasyWinWin es una metodología de negociación de requisitos que combina el Modelo en espiral WinWin de ingeniería de software del Centro de USC para Ingeniería de software con técnicas de conocimiento colaborativo y automatización de un sistema de soporte grupal de GroupSystems.com
Soporte de herramientas para la negociación de requisitos de WinWin
EasyWinWin es una metodología de negociación de requisitos que combina el Modelo en espiral WinWin de ingeniería de software del Centro de USC para Ingeniería de software con técnicas de conocimiento colaborativo de última generación y automatización de un sistema de soporte grupal de GroupSystems.com. Un sistema de soporte grupal (GSS) es un conjunto de herramientas de software que se puede usar para crear, mantener y cambiar patrones de interacción grupal en repetible, formas predecibles [14].
EasyWinWin ayuda a un equipo de partes interesadas a obtener una mejor y más completa comprensión del problema y apoya el aprendizaje cooperativo sobre los puntos de vista de otros. Además, ayuda a aumentar la participación e interacción de los interesados. EasyWinWin define un conjunto de actividades que guían partes interesadas a través de un proceso de recopilación, elaboración, priorización y requisitos de negociación El propósito nominal de la metodología EasyWinWin es crear un conjunto aceptable de requisitos del sistema. Los equipos pueden use EasyWinWin durante todo el ciclo de desarrollo para crear un visión del proyecto, para desarrollar una definición de requisitos de alto nivel, para producir requisitos detallados para características, funciones y propiedades, adquisición e integración de COTS, mejora del producto COTS y planes de requisitos para la transición del sistema al cliente y al usuario.
El modelo de negociación proporciona la captura, representación y uso de razón fundamental. El razonamiento se captura durante la comunicación y las partes interesadas negociación de una manera estructurada en la cual las relaciones entre los artefactos son claros para las partes interesadas. La herramienta proporciona la distribución de la justificación. característica para usuarios concurrentes. Es fácil de capturar, modificar y revisar justificación durante la negociación. Aumenta la colaboración y coordinación con conciencia grupal, modos de comunicación síncronos y asíncronos, y soporte para análisis de compensación. Justificación utilizada durante y después negociación para acordar los artefactos de desarrollo. Sin embargo, la herramienta no proporciona soporte para la preservación de la lógica y las interfaces para el legado componentes actualmente debido a la razón por la que se está utilizando para la negociación de requisitos.
El proceso de negociación
La entrada a un taller EasyWinWin es típicamente una declaración de misión delineando los objetivos de alto nivel de un proyecto y otra declaración que especifica el propósito de la negociación, es decir, los objetivos de una negociación dentro de un proyecto. En cada actividad en este proceso, el equipo agrega detalles y aumenta la precisión. El proceso EasyWinWin se compone de las siguientes actividades:
Revisar y ampliar los temas de negociación. Las partes interesadas refinan conjuntamente y personalizar un esquema de temas de negociación basado en una taxonomía de Requisitos de Software. El esquema compartido ayuda a estimular el pensamiento, a organiza los resultados de la negociación y sirve como una lista de verificación de integridad para negociaciones.
Lluvia de ideas sobre los intereses de los interesados. Las partes interesadas comparten sus objetivos, perspectivas, puntos de vista, antecedentes y expectativas mediante la recopilación de declaraciones sobre sus intereses creados.
Converge en las condiciones de victoria. Las partes interesadas elaboran conjuntamente una lista de condiciones de victoria claramente establecida e inequívoca al considerar y discutir todo ideas aportadas en la sesión de lluvia de ideas.
Capture un glosario de términos. Las partes interesadas definen y comparten el significado de términos importantes del proyecto en un glosario.
Priorizar las condiciones de victoria. Las partes interesadas priorizan las condiciones de victoria para definir el alcance del trabajo y para enfocarse.
Revelar problemas y restricciones. Las partes interesadas emergen y entienden cuestiones.
Identificar problemas y opciones. Las partes interesadas resuelven los problemas que surgen debido a restricciones, riesgos, incertidumbres y condiciones de victoria conflictivas. Proponen opciones para resolver estos problemas.
Negociar acuerdos. Las partes interesadas negocian compromisos mutuos por considerando las condiciones de victoria que no plantearon problemas y todas las opciones propuestas.
Los resultados del proceso de negociación
Figura 8.3: Actividades de trabajo EasyWinWin y productos con relaciones a los productos de trabajo Importantes en el ciclo de vida del software
Las actividades del proceso EasyWinWin se resumen arriba y se muestran en la Figura 8.3 con productos de trabajo relacionados (para obtener una descripción más detallada, consulte [8] [12]). Los resultados de cada actividad en el proceso son una entrega bien definida: (1) temas de negociación organizados en una taxonomía de dominio, (2) un glosario que define los términos clave del proyecto, (3) acuerdos que proporcionan la base para planes adicionales, (4) Cuestiones abiertas que abordan restricciones, conflictos y problemas conocidos, así como (5) mayor justificación que muestra el historial de negociación (comentarios, condiciones de victoria, problemas, opciones, etc.).
Los principales resultados del proceso de negociación son una lista de acuerdos y una lista de problemas no resueltos (por ejemplo, causados por la disidencia de las partes interesadas), que deben gestionarse como posibles riesgos de los proyectos. Los acuerdos de las partes interesadas críticas para el éxito son aportes al contrato del proyecto y al refinamiento durante las actividades de ingeniería de requisitos. El árbol WinWin muestra cómo los acuerdos y los problemas abiertos se remontan a las condiciones de ganancia de los interesados.
Un ejemplo: uso de WinWin en desarrollo de software
EasyWinWin se ha utilizado en más de 100 proyectos del mundo real en varios dominios (por ejemplo, bibliotecas digitales, mercado electrónico y tecnología de colaboración). Al utilizar el enfoque MBASE durante todo el desarrollo del software, descubrimos que el uso de un enfoque de negociación de requisitos de WinWin ayuda a las partes interesadas a priorizar sus requisitos y capturar los fundamentos de sus decisiones.
Uno de los proyectos de los proyectos del mundo real que usaremos como ejemplo es el siguiente:
“La División de Servicios de Información (ISD) quisiera reemplazar su actual tarjeta de tiempo y sistema de hoja de tiempo (papel) con un sistema electrónico basado en la web para simplificar recopilación de datos, para registrar con mayor precisión las horas trabajadas para todos sus empleados, y para proporcionar herramientas de gestión de personal para supervisores y directores ".
El taller EasyWinWin comenzó con el equipo revisando y expandiendo los temas de negociación basados en la taxonomía de dominio que ayudó a organizar los artefactos que surgieron más adelante en el proceso. La figura 8.4 muestra parte de la taxonomía de nuestro proyecto. Luego, las partes interesadas hicieron una lluvia de ideas sobre el proyecto y contribuyeron con sus intereses. Algunos ejemplos son:
• El sistema debe proporcionar algún beneficio a los empleados que lo usan, como proporcionarles el saldo actual de sus vacaciones.
• El sistema debe tener la capacidad de corregir errores en tarjetas de tiempo anteriores.
• Las estructuras jerárquicas pueden proporcionar varios niveles de acceso para diferentes grupos de gestión.
• Algunos componentes de ISD preferirían un deslizamiento de tarjeta o un sistema biométrico de entrada / salida de reloj conectado a la red. Los supervisores consideran que esto reducirá la entrada / salida de otros usuarios.
La recopilación resultante de las declaraciones e ideas de los interesados proporcionó un punto de partida y una justificación para elaborar condiciones ganadoras y definir términos importantes del dominio del proyecto. Las declaraciones de lluvia de ideas se adjuntaron a las condiciones ganadoras resultantes para preservar la lógica de la lluvia de ideas.
Figura 8.5: Algunos resultados de votación de las condiciones de victoria: gris como consenso, negro como falta de consenso.
Después de eso, las partes interesadas votaron sobre cada condición ganadora de acuerdo con dos criterios: importancia comercial y facilidad de implementación. Durante esta actividad, los desarrolladores generalmente se enfocaban en problemas técnicos, mientras que los clientes y usuarios se concentraban en la relevancia comercial (ver Figura 8.5).
En el siguiente paso, las partes interesadas examinaron los resultados de la priorización e identificaron problemas y opciones en varias iteraciones. Durante los problemas y limitaciones reveladores, los interesados modificaron las prioridades de acuerdo con la información actualizada que obtuvieron. El estado de equilibrio de WinWin se mantiene cuando todas las condiciones de ganancia están cubiertas por acuerdos, y no hay problemas pendientes. Tan pronto como algunos interesados ingresan en un problema y una condición de conflicto conflictiva asociada, la negociación abandona el estado de equilibrio de WinWin, y los interesados intentan formular opciones para resolver el problema. Por ejemplo, si las condiciones de conflicto en conflicto van a hacer que el sistema se ejecute en una plataforma Windows y una plataforma UNIX, una opción aceptable podría ser construir el sistema para que se ejecute en una máquina virtual Java.
El árbol WinWin tiene toda la información recopilada durante la negociación de requisitos: números únicos para los artefactos que ayudan a rastrear los artefactos a través del ciclo de vida del software, las prioridades para las condiciones de ganancia, las partes interesadas que identificaron problemas y opciones, y los elementos de taxonomía a los que pertenecen los artefactos. El árbol WinWin también captura la justificación de las condiciones ganadoras y la forma en que las partes interesadas llegan a un acuerdo al incluir todas las opciones propuestas, ya sean adoptadas o no, todos los problemas que finalmente se abordaron y todas las condiciones ganadoras (ver Figura 8.6).
Figura 8.6: Una pequeña parte de WinWin Tree: capacidad inicial y secciones de interfaz
Los resultados de la negociación, principalmente los acuerdos, se convierten en la base de los requisitos, mientras que los otros artefactos son el fundamento de las decisiones adicionales tomadas durante el ciclo de vida del desarrollo, tales como riesgos importantes, planes de iteración, etc. Los acuerdos que cubren las condiciones ganadoras de menor prioridad se convierten en requisitos de evolución. , proporcionando la base para la arquitectura del sistema para eliminarlos fácilmente (si es necesario para cumplir con el cronograma) o incorporarlos en incrementos posteriores. Por ejemplo, “El sistema W12 [FGT] debe admitir interfaces de deslizamiento de tarjeta o basadas en la web. [Taxonomía 3.1] ”pertenecía a los Requisitos de la interfaz de usuario durante la negociación. Sin embargo, después de la priorización se clasifica como no importante y muy difícil de implementar. Un problema identificado por el administrador como "I12 El soporte de las interfaces de deslizamiento de la tarjeta requiere la compra e integración de hardware adicional [Administrador] [Taxonomía 3.1]". Este problema ocurrió debido a un límite de presupuesto para el proyecto. Por lo tanto, las partes interesadas proporcionaron una opción para tener una interfaz de usuario basada en la web primero, y dejaron la interfaz de deslizar la tarjeta como requisitos de evolución tecnológica. Al final había dos requisitos: (1) Interfaz basada en web como requisitos de interfaz, (2) Agregar nuevos dispositivos de entrada como lectores de tarjetas magnéticas como requisito de evolución.
El equipo que usa EasyWinWin puede desarrollar un conjunto de resultados más amplio y profundo en un tiempo más corto. Una negociación de EasyWinWin da como resultado un número significativamente mayor de artefactos en comparación con los enfoques tradicionales basados en papel o pizarra: nuestra experiencia hasta la fecha muestra que las negociaciones típicas sobre los requisitos del sistema con más de 10 partes interesadas dan como resultado más de 300 ideas de lluvia de ideas, más de 100 condiciones ganadoras, más de 50 problemas, más de 50 opciones y más de 100 acuerdos en menos tiempo que otras técnicas tradicionales. A pesar de que los equipos tenían una formación educativa similar y básicamente las mismas condiciones de victoria, se les ocurrieron enfoques y soluciones de negociación muy diferentes.
El enfoque en el consenso lleva a una mayor aceptación de las decisiones y a un mayor entendimiento mutuo entre las partes involucradas. La evaluación del modelo WinWin muestra que el uso de un modelo de problema para el apoyo a la negociación mejora la confianza y la comprensión compartida entre los accionistas, incluso en presencia de incertidumbres y requisitos cambiantes.
CONCLUSION
El modelo espiral WinWin
proporciona disciplina, flexibilidad y ayuda a mantener el proyecto a tiempo.
Si las variaciones se aplican por separado a un proyecto, el resultado
generalmente no tendrá éxito, produciendo sistemas separados con muchos
componentes innecesarios y conflictivos. A menudo, los diseñadores miran más
allá de los parámetros de los objetivos del sistema.
Es muy difícil lograr que un
grupo variado de partes interesadas esté de acuerdo en un proyecto grande,
debido a la combinación de equipos; Es por eso que la adquisición incremental y
evolutiva es importante y se hace referencia en los hitos.
Entonces, podemos decir que el
enfoque Win Win implica que las partes interesadas críticas para el éxito de un
sistema participen en un proceso de negociación para que puedan converger en un
conjunto de requisitos mutuamente satisfactorios (ganar-ganar).
Link fuente o matriz de la misma
https://dspace.itcolima.edu.mx/bitstream/handle/123456789/1483/52136%20A
LONSO%20ANGEL%20S%C3%81NCHEZ%20MALDONADO.pdf
Libros:
Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Magnament, and Research
Ingeniería del Software Un Enfoque Práctico 6ta Edicion Roger S. Pressman
a spiral model of software development and enhancement barry boehm pdf
Ingeniería del software, 5ta Edición - Roger S. Pressman
