MODELO EN ESPIRAL WIN WIN Teoria win win La teoría win win (en castellano teoría ganar ganar) nació del libro llamado "La meta" (the goal), escrita por el físico Eli Goldratt. La acción se desarrolla en una fábrica con problemas de liquidez, su director resuelve situaciones mediante negociaciones utilizando el método win win. Este método ha revolucionado el mundo de los negocios, incluso se imparte en numerosas universidades de Estados Unidos y Eli Goldratt ofrece seminarios sobre ello. La teoría win win es una negociación donde de forma comunicativa todas las partes aportan sus objetivos, creando una empatía mútua hasta llegar a un acuerdo común y todos salen beneficiados. En este caso el objetivo no es conseguir lo más barato, si no conseguir un acuerdo justo que asegure una buena relación entre las partes ya que éstas se verán comprometidas a cumplir su parte del trato. En las negociaciones existen temores, sentimientos encontrados, competitividad, envidia, etc. El método win win constituye una técnica de negociación más. Hay ocasiones en las que no se puede ser tan dúctil porque los oponentes se aprovecharían. El mejor negociador es el que más técnicas domina y es capaz ser competitivo, agresivo o caborativo cuando la situación lo requiera en cada momento. Funcionamiento del método win win La técnica de negociación win win se basa fundamentalmente en negociar teniendo como objetivo que todas las partes salgan beneficiadas, separa a las personas de sus intereses individuales para enfocarse en los de las demás partes que interactúan. La frase que resume esta teoría es "todos salimos ganando". Alcanzar una solución win win es muy complejo pero se puede resumir en tres actitudes: 1. Dejar las emociones negativas fuera del proceso: al comienzo de toda negociación las partes que intervienen tienen intereses opuestos, emociones negativas, miedo a perder, etc. Estas emociones negativas hay que identificarlas porque en caso contrario serán un obstáculo para conseguir los objetivos win win. 2. Focalizarse en la solución: lo principal es dirigir nuestro enfoque al debate y la negociación, para conocer las necesidades de la otra parte, es una forma de crear empatía. 3. Explorar el contexto y las opciones: encontrar soluciones donde todas las partes estén satisfechas y de acuerdo para poder trabajar juntos y que todos consigan sus objetivos. La negociación win win consiste en un 30% de diálogo, otro 45% de escuchar y el 25% restante se emplea en la aceptación, cierre y papeleo de dicho negocio. Modelo Espiral Clásico o de cuatro regiones El modelo espiral en el desarrollo del software es un modelo meta del ciclo de vida del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ahí mismo comienza otro; además en cada ejecución del desarrollo se sigue cuatro pasos principales: 1. Determinar o fijar los objetivos. En este paso se definen los objetivos específicos para posteriormente identifica las limitaciones del proceso y del sistema de software, además se diseña una planificación detallada de gestión y se identifican los riesgos. 2. Análisis del riesgo. En este paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y luego del análisis de estos riesgos se planean estrategias alternativas. 3. Desarrollar, verificar y validar. En este tercer paso, después del análisis de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla. 4. Planificar. En este último paso es donde el proyecto se revisa y se toma la decisión si se debe continuar con un ciclo
posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. Con cada iteración alrededor de la espiral, se crean sucesivas versiones del software, cada vez más completas y, al final, el sistema de software ya queda totalmente funcional. La diferencia principal entre el modelo espiral y los modelos anteriores (ej.: cascada, evolutivo, incremental, etc.) es la evaluación del riesgo. Características del modelo en espiral para el desarrollo de software Es considerado como un modelo evolutivo ya que combina el modelo clásico con el diseño de prototipos. • Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente. • Este modelo es el indicado para desarrollar software con diferentes versiones actualizadas como se hace con los programas modernos de PC s. • La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos. • Este es el enfoque más realista actualmente. El modelo en espiral esta compartida en varias actividades estructurales, también llamadas regiones de tareas. Existen seis regiones de tareas que son: • Comunicación con el cliente: esta es una tarea requerida para establecer comunicación entre el desarrollador y el cliente. • Planificación: esta tarea es necesaria aplicarla para poder definir los recursos, el tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos. • Análisis de riesgos: esta es una de las tareas principales por lo que se aplica el modelo en espiral, es requerida para evaluar los riesgos técnicos y otras informaciones relacionadas con el proyecto. • Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más representaciones de la aplicación. • Construcción y adaptación: esta tarea es requerida en el modelo espiral porque se necesita construir, probar, instalar y proporcionar soporte al usuario. • Evaluación el cliente: esta también es una tarea principal, necesaria para adquirir la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería y la de implementación creada durante la etapa de instalación.
Ventajas El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos. •
Reduce riesgos del proyecto
•
Incorpora objetivos de calidad
•
Integra el desarrollo con el mantenimiento, etc.
Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático. Desventajas •
Genera mucho tiempo en el desarrollo del sistema
•
Modelo costoso
•
Requiere experiencia en la identificación de riesgos
Del modelo en espiral de desprenden tres variantes: •
Modelo de cuatro regiones o modelo original de BOEHM.
•
Modelo en espiral de seis regiones
•
Modelo en espiral Win Win. Este modelo es el que estudiaremos más a detalle.
Modelo en espiral de seis regiones Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.
Las 6 regiones que componen este modelo son las siguientes: •
Comunicación con el cliente - Tareas necesarias para plantear la comunicación entre el desarrollador y el cliente.
•
Planificación - Tareas inherentes a la definición de recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
•
Análisis de riesgos – Tareas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
•
Ingeniería - Tareas para construir una o más representaciones de la aplicación.
•
Construcción y adaptación - Tareas requeridas para construir, probar, instalar y proporcionar soporte a los usuarios.
•
Evaluación del cliente - Tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
Ventajas •
El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
•
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 nivele evolutivos.
•
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.
•
Reduce riesgos del proyecto
•
Incorpora objetivos de calidad
Desventajas •
Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
•
Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
•
Genera mucho tiempo en el desarrollo del sistema
•
Modelo costoso
•
Requiere experiencia en la identificación de riesgos
Ejemplos •
navegadores y controladores aeronáuticos.
•
la creación de un Sistema Operativo.
Modelo en espiral Win Win El MODELO en espiral, propuesto originalmente por BOEHM , define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades: •
Identificación del sistema o subsistemas clave de los directivos. ¿Saber que quieren?
•
Determinación de las condiciones de victoria de los directivos. ¿Saber que necesitan y los satisface?
•
Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software). VictoriaVictoria.
Diferencia entre el modelo en espiral clásico y el modelo en espiral win win El Modelo Espiral (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". El modelo Win & Win hace énfasis en la negociación inicial, también introduce 3 hitos en el proceso llamados "puntos de fijación", que ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo del software. •
El primer punto de fijación, llamado objetivos del ciclo de vida (OCV), define un conjunto de objetivos para cada actividad principal de ingeniería del software. Como ejemplo, de una parte de OCV, un conjunto de objetivos asociados a la definición de los requisitos del producto/sistema del nivel más alto.
•
El segundo punto de fijación, llamado arquitectura del ciclo de vida (ACV), establece los objetivos que se deben conocer mientras que se define la arquitectura del software y el sistema. Como ejemplo, de una parte de la ACV, el equipo del proyecto de software debe demostrar que ha evaluado la funcionalidad de los componentes del software reutilizables y que ha considerado su impacto en las decisiones de arquitectura.
•
La capacidad operativa inicial (COI) es el tercer punto de fijación y representa un conjunto de objetivos asociados a la preparación del software para la instalación/distribución, preparación del lugar previamente a la instalación, y la asistencia precisada de todas las partes que utilizará o mantendrá el software.
Ciclo de vida en espiral Win & Win Barry Boehm, años después realizó una variante o actualización del //ciclo de vida en espiral que definió en 1988. 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 el siguiente nivel para los directivos: 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 los directivos: 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 segundo 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. Ventajas del modelo en espiral win win •
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 nivele evolutivos.
•
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.
•
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 del modelo en espiral win win •
Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
•
Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
Conclusiones El modelo en espiral no se ha utilizado tanto como el modelo lineal o secuencial y dio construcción de prototipos. EL modelo en espiral es de gran complejidad y solo es utilizado en sistemas grandes, que si son desarrollados con éxito logran doblar la productividad.
