Instituto Tecnológico de Culiacán

Ingeniería en sistemas computacionales

Métodos Agiles

Maestro:
Martha Estela Valenzuela Tirado
Alumnos:
Cordero Diarte Simitrio

Culiacán, Sinaloa; Septiembre del 2019

De 11:00 a 12:00
Proceso Unificado
El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco
de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado
en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y
documentado del Proceso Unificado es el Proceso Unificado de Rational (RUP) o
simplemente UP.
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de
cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas
fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias
iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado
un incremento del producto desarrollado que añade o mejora las funcionalidades del
sistema en desarrollo.
Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a
las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño,
Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas
las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.
Dirigido por los casos de uso
En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales
y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un
conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas
disciplinas: diseño, implementación, prueba, etc. El proceso dirigido por casos de uso es el
rup. Nota: en UP se está Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de
ARLOW, Jim que menciona el tema.

Centrado en la arquitectura
El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos
del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la
arquitectura de software de un sistema. La analogía con la construcción es clara, cuando
construyes un edificio existen diversos planos que incluyen los distintos servicios de este:
electricidad, fontanería, etc.

Fases
Inicio
En la fase de inicio se define el negocio: facilidad de realizar el proyecto, se presenta un
modelo, visión, metas, deseos del usuario, plazos, costos y viabilidad.

Elaboración
En esta fase se obtiene la visión refinada del proyecto a realizar, la implementación iterativa
del núcleo de la aplicación, la resolución de riesgos altos, nuevos requisitos y se ajustan las
estimaciones.

Construcción
Esta abarca la evolución hasta convertirse en producto listo incluyendo requisitos mínimos.
Aquí se afinan los detalles menores como los diferentes tipos de casos o los riesgos
menores.

Transición
En esta fase final, el programa debe estar listo para ser probado, instalado y utilizado por el
cliente sin ningún problema. Una vez finalizada esta fase, se debe comenzar a pensar en
futuras novedades para la misma.
Desde el punto de vista Técnico: el proyecto está formado por los flujos de trabajo
fundamentales: captura de requerimientos, análisis, diseño, implementación y pruebas.
Tantos el punto de vista Gerencial como el Técnico concuerdan en: La iteración .
La gestión evolutiva de proyectos exige que cumpla sus requisitos en pequeños pasos (para
ejemplo 2% del presupuesto). Muchas personas inicialmente suponen que esto significa
entregar ciertos componentes o funciones. En el extremo, suponen falsamente que
estamos hablando de ofrecer unmcoche comenzando con una rueda. Esto no está cerca de
la realidad de Evo.
La descomposición puede seguir muchos caminos posibles. La idea esencial es esta:
• Entregar resultados reales a al menos una parte interesada, al menos una persona real;
• Entregue algunos de los resultados que se planificaron en la especificación de requisitos:
esto
pueden ser mejoras de funcionalidad o rendimiento;
• Asegúrese de que esos resultados sean un incremento útil, de alta prioridad y de alto valor
para la parte interesada: una adición a lo que tienen y algo que necesitan.
Como ejemplo, un proyecto de radar militar en el Reino Unido me dijo que no creían en su
proyecto podría hacerse evolutivamente. Solo necesitó 20 minutos de discusión y dos
conceptos para convencerlos de manera diferente. El primer concepto que sugerí fue que
en lugar de tomar puramente una visión técnica: que el sistema propuesto se refería
principalmente al uso de 2 antenas de radar, que el punto principal del sistema era
aumentar la precisión de la percepción, un rendimiento requisito. El segundo concepto era
que la Royal Navy era uno de los partes interesadas (no solo el nuevo barco para el que
estaba programado el sistema de radar). Con esto como base se hizo obvio que podríamos
evolucionar el sistema (incrementando los datos de la nave y el avión, y lógica de
procesamiento) hacia una mejor capacidad de percepción. En segundo lugar, podríamos
hacerlo utilizando barcos existentes en el mar (una porción de parte interesada).

Evo
Evo, creado por Tom Gilb, es el método iterativo ágil más antiguo. Se lo llama también
Evolutionary Delivery, Evolutionary Management, Requirements Driven Project Management y
Competitive Engineering. Fue elaborado inicialmente en Europa. En 1976 Gilb trató temas de
desarrollo iterativo y gestión evolutiva en su clásico Software metrics [Gilb76], el texto que acuñó
el concepto e inauguró el campo de las métricas de software. Luego desarrolló en profundidad
esos temas en una serie de columnas en Computer Weekly UK. En 1981 publicó “Evolutionary
Development” en ACM Software Engineering Notes y “Evolutionary Devivery versus the ‘Waterfall
Model’” en ACM Sigsoft Software Requirements Engineering Notes. En la década de 1980 Gilb
cayó bajo la influencia de los valores de W. Edward Deming y del método Planear-Hacer-Estudiar-
Actuar (PDSA) de Walter Shewhart, que se constituyeron en modelos conceptuales subyacentes a
Evo. Deming y Schewhart son, incidentalmente, considerados los padres del control estadístico de
calidad; sus ideas, desarrolladas en las décadas de 1940 y 1950, se han aprovechado, por ejemplo,
en la elaboración de estrategias como Six Sigma, en Lean Development o en la industria japonesa.
En los 90s Gilb continuó el desarrollo de Evo, que tal vez fue más influyente por las ideas que éste
proporcionara a XP, Scrum e incluso UP que por su éxito como método particular. El texto de
Microsoft Press Rapid Development de Steve McConnell [McC96], que examina prácticas iterativas
e incrementales en desarrollo de software, menciona ideas de Gilb en 14 secciones [Lar04]; todas
esas referencias están ligadas a best practices.

A medida que se desenvuelve el proyecto, se obtiene feedback en tiempo real sobre las mejoras
que implica la Entrega Evolutiva sobre las Metas y Valores del Participante, así como sobre el
consumo de Recursos. Esta información se usa para establecer qué es lo que está bien y lo que no,
cuáles son los desafíos y qué es lo que no se sabía desde un principio; también se aprende sobre
las nuevas tecnologías y técnicas que no estaban disponibles cuando el proyecto empezó. Se
ajusta luego todo según se necesite, pero sin detallar las Soluciones o las Entregas Evolutivas hasta
que se esté próximo a la entrega. Por último vienen las Funciones y Sub-Funciones, de las que se
razona teniendo en cuenta que en rigor, en un nivel puro, son de hecho Soluciones a Metas.

Igual tratamiento se concede en Evo a las Funciones y Sub-Funciones, que se conciben más bien
como Soluciones para Metas de los Participantes. Aunque hay un proceso bien definido para
establecerlas y tratar con ellas, en Evo se recomienda mantener las funciones al mínimo, porque
se estima además que una especificación funcional es una concepción obsoleta. La diferencia
entre un procesador de texto como Word y la escritura con lápiz y papel, ilustra Gilb, no es
funcional; en ambos casos se puede hacer lo mismo, sólo que se lo hace de distinta manera. Lo
que el Participante requiere no debe ser interpretado como la adquisición de nueva funcionalidad;
por el contrario, el desastre de la industria de software, se razona aquí, se origina en que ha
dependido demasiado de la funcionalidad. En Evo, sin duda, se debe razonar de otro modo: todo
tiene que ver con las Metas y Valores de los Participantes, expresadas en términos tales que una
Solución (o como se la llama también Diseño, Estrategia, Táctica, Proceso, Funcionalidad,
Arquitectura y Método) pueda definirse como un medio para un fin, a través del cual se lleve de la
situación en la que se está a otra situación que se desea.

Open
¿Cómo se define el OpenUP?

OpenUP es un marco del proceso del desarrollo del software Open Source que en un cierto plazo,
se espera que cubra un amplio sistema de necesidades para los proyectos de desarrollo.

OpenUP es un proceso iterativo para el desarrollo de software que es:

- Mínimo: Solo incluye el contenido del proceso fundamental

- Completo: Puede ser manifestado como proceso entero para construir un sistema.
- Extensible: Puede ser utilizado como base para agregar o para adaptar más procesos.

¿Qué es el OpenUp/Basic?

OpenUP/Basic es un subconjunto de OpenUP que lleve un acercamiento ágil para el desarrollo del
software, con solo un contenido fundamental provee un conjunto simplificado de artefactos, roles,
tareas y guías de trabajo.

OpenUP/Basic es un proceso iterativo del desarrollo del software que es mínimo, completo, y
extensible. Es un proceso para equipos de desarrollo pequeños y que le dan valor a la colaboración
y a las necesidades de los stakeholder.

OpenUP/Basic es extensible, porque puede ser utilizada como base para agregar o adaptar según
las necesidades. Es un proceso ejemplar y extensible para una gama de los procesos del desarrollo
y de la gerencia del software que apoya el desarrollo iterativo, ágil, e incremental y es aplicable a
un amplio sistema de plataformas y de usos del desarrollo.

Beneficios en el uso del OpenUP

- Ya que es apropiado para proyectos pequeños y de bajos recursos permite disminuir las
probabilidades de fracaso en los proyectos pequeños e incrementar las probabilidades de éxito.
- Permite detectar errores tempranos a través de un ciclo iterativo.
- Evita la elaboración de documentación, diagramas e iteraciones innecesarios requeridos en la
metodología RUP.
- Por ser una metodología ágil tiene un enfoque centrado al cliente y con iteraciones cortas.

Principios del OpenUP

- Colaborar para alinear intereses y para compartir conocimiento.

- Balancear las prioridades para maximizar las necesidades de los stakeholder.
- Centrado en la Arquitectura.
- Desarrollo Iterativo.

Fases del OpenUP

1. Concepción

Primera de las 4 fases en el proyecto del ciclo de vida, acerca del entendimiento del propósito y
objetivos y obteniendo suficiente información para confirmar que el proyecto debe hacer. El
objetivo de ésta fase es capturar las necesidades de los stakeholder en los objetivos del ciclo de
vida para el proyecto.

2. Elaboración

Es el segundo de las 4 fases del ciclo de vida del OpenUP donde se trata los riesgos significativos
para la arquitectura. El propósito de esta fase es establecer la base la elaboración de la
arquitectura del sistema.

3. Construcción
Esta fase esta enfocada al diseño, implementación y prueba de las funcionalidades para
desarrollar un sistema completo. El propósito de esta fase es completar el desarrollo del sistema
basado en la Arquitectura definida.

4. Transición

Es la última fase, suyo propósito es asegurar que el sistema es entregado a los usuarios, y evalúa la
funcionalidad y performance del último entregable de la fase de construcción.

Microsoft Solutions Framework

Microsoft Solution Framework es una metodología para el desarrollo de software para la
planificación, desarrollo y gestión de proyectos tecnológicos. Se centra en el modelo de
procesos y de equipo dejando los demás aspectos en segundo plano.
MSF se compone de varios modelos que se encargan de cada una de las fases del
desarrollo de un proyecto: modelo de arquitectura del proyecto, modelo de equipo,
modelo de procesos, modelo de gestión de riesgo, modelo de diseño de procesos y
modelo de aplicación.

Fase 1 Estrategia y alcance:

 Elaboración y aprobación del documento de alcances del proyecto.
 Formación del equipo de trabajo y distribución de competencias y responsabilidades.
 Elaboración del plan de trabajo.
 Elaboración de la matriz de riesgos y plan de contingencia.
Fase 2 Planificación y prueba de concepto:
 Documento de planificación y diseño de arquitectura.
 Documento de plan de laboratorio (son las pruebas de conceptos)
Fase 3 Estabilización
 Selección del entorno de pruebas piloto.
 Gestión de incidencias.
 Revisión de la documentación final de la arquitectura.
 Elaboración de plan de despliegue.
 Elaboración del plan de formación.
Fase 4 Despliegue
 Registro de mejoras y sugerencias.
 Revisión de las guías y manuales de usuario
 Entrega del proyecto y cierre del mismo
Otras características del MSF
Fases y definiciones del proyecto presentadas por el MSF:
 Prever: Identificar el objetivo del proyecto. Crear documento con ámbito del proyecto
y declaración de objetivos.
 Planear: Desarrollar especificaciones funcionales. Aquí se desarrolla el diseño del
proyecto que incluye diseños conceptuales, lógicos y físicos.
 Desarrollo: Crear un laboratorio de pruebas para examinar como funcionan las
soluciones en el mundo real.
 Implementación: Se alcanzan los objetivos indicados en la fase de desarrollo.
Una forma de llevar paso por paso está metodología es a través de las herramientas de
Microsoft como es el caso de Visual Studio. MSF es flexible ya que permite agregar y
extender nuevas características.
MSF no es rígido ya que sabe que no existe una sola estructura que se pueda acoplar a
todo los tipos de proyectos.
Es una metodología integrada, ya que combina muchos elementos y características y
además, es una metodología productiva, ya que incrementa la productividad de todo el
equipo de trabajo.
MSF es una metodología de mejores prácticas para el desarrollo del software. Los
modelos de procesos que maneja son ágiles y formales.
Los modelos de procesos ágiles fueron desarrollado por un conjunto de profesionales
conocidos como la Agile Alliance, quienes rechazaron la noción de que los procesos son
más importantes que la gente.
Se enfoca más en las habilidades y cualidades de las personas que en la eficacia de los
modelos de procesos.
MSF está basado en mejores prácticas del mundo real, basado en las experiencias de
Microsoft.
Algunas capacidades de extensión del MSF son: guía de procesos, estructura de iteración,
vistas de criterio de entrada y salidas, definición de tipos y reglas de elementos de trabajo,
políticas de revisión de código, seguridad de grupos, plantillas de documentos, reportes y
portales.
Introducción al riesgo
 En el desarrollo de software existe una gran cantidad de cosas desconocidas.
 Principios de fundación de riesgos:
 Mantenerse ágil, esperando cambios.
 Comunicaciones abiertas
 Aprender de todas las experiencias
 Responsabilidad compartida, contabilidad clara
 El riesgo está inherentemente en cualquier proyecto de procesos.
 La administración de riesgo proactivo es más eficiente:
 Anticipar problemas antes de que puedan ocurrir
 Tener un plan de resolución de problemas antes de que éstos ocurran
 Usar procesos repetibles, estructurados y conocidos para la resolución de
problemas
 Usar medidas preventivas cuando sea posible.
Pasos para el proceso de manejo de riesgo del MSF
La administración de riesgos es una de las actividades principales del MSF. Tiene las
siguientes características:
 Es comprensivo, direccionando todo los elementos del proyecto: personas, procesos y
elementos tecnológicos
 Incorpora procesos reproducibles, sistemático, y paso a paso de la administración de
riesgos
Prácticas recomendadas para el modelo de procesos del MSF
 Concentrarse en la creatividad por medio de características envolventes y restricción
de recursos.
 Establecer calendarios fijados.
 Calendarización para futuro incierto.
 Uso de equipos de trabajo pequeños, trabajando en paralelo, con puntos de
sincronización frecuentes.
 Uso de prototipos
 Uso de implementaciones frecuentes y pruebas rápidas
El establecimiento de equipos de trabajos es una de las partes que mayor importancia
tiene cuando se desarrolla un proyecto, ya que si se realiza en forma equivocada los
integrantes del proyecto no podrán colaborar de buena manera y hacerlo bien.
Miembros de equipos sinergizados:
 Estar preparado para hacer comisiones de otros.
 Determinar claramente las comisiones que los miembros del equipo entienden.
 Hacer razonable cada esfuerzo para entregar las comisiones.
 Comunicar honestamente cuando las comisiones puedan tener riesgo.
Algunas sugerencias para el manejo de riesgo:
 Sinergizar el equipo para conocer las comisiones que le han sido asignadas.
 Centrarse en el valor del negocio
 Mantener una visión compartida del proyecto
El modelo de equipo del MSF:
 Los equipos motivados son más eficientes.
 Clarificar la visión del equipo.
 Construir una identidad de equipo, usando nombres códigos a los proyectos.
 Gastar tiempo en eventos sociales en el equipo.
 Calendarizar actividades para discutir temas en equipo
 Asegurarse que las metas personales no interfieran en el desarrollo del proyecto.
 Celebrar el éxito
 Equipos multidisciplinarios y pequeños.
 Trabajo en conjunto
Principios de un equipo exitoso
 Pueden trabajar independientemente.
 Demostrar las habilidades del equipo.
 Poseer habilidades específicas para resolver el problema.
 Pueden compartir conocimiento con la organización
 Pueden desarrollar efectivamente métodos de trabajo.
Equipos de proyecto de Microsoft
 Vista del modelo de equipo
 Administración del producto
 Administración del programa
 Desarrollo
 Pruebas
 Experiencias del usuario
 Administrador de versiones
Roles y responsabilidades
La característica principal de cualquier modelo de equipo consiste en asignar a cada uno
de los intregrantes del equipo de algunas actividades
Rol del administrador de producto
 Marketing:
 Manejar marketing y relaciones públicas.
 Diferenciar el proyecto del resto de los competidores.
 Poner la distribución en formas fácilmente accessible para los clientes.
 Proveer soporte a los clientes.
 Valor del negocio:
 Definir y mantener la justificación para el proyecto.
 Definir y medir el valor del negocio del usuario.
 Avocado al cliente:
 Manejar una vision y solución del proyecto compartida.
 Manejar las espectativas del cliente y las comunicaciones
 Planeación del producto:
  Analizar y priorizar los requerimientos de los clientes
 Mejorar el análisis e inteligencia de la investigación de mercado y la demanda del
Mercado.
 Determinar las métricas del negocio y los criterios de éxito
 Identificar múltiples versiones del plan de entrega.
 Agrupación de roles en la administración de proyectos
Administración del proyecto:
 Seguimiento y manejo del presupuesto.
 Gestionar la calendarización del proyecto maestro.
 Manejar el proceso de gestión de riesgos
 Facilitar la comunicación y negociación dentro del equipo.
 Seguimiento del progreso y gestión del estado del reporte del estado del proyecto.
 Manejar la relocalización de recursos
Arquitectura de solución
 Manejar todas los posibles diseños de solución.
 Manejar las especificaciones funcionales.
 Manejar el alcance de la solución y acuerdos de decisión críticos.
 Mejora de procesos:
 Definir la calidad de los procesos
 Definir y recomendar mejoras
Servicios administrativos
 Implementar los procesos de administración de proyecto y el soporte de liderazgo al
equipo de trabajo.
 Proveer un rango de servicios de administración para soportar eficientemente equipos
de trabajo.
 Actividades de la arquitectura de solución incluyen:
 Crear el concepto de solución y revisar el plan de requerimientos.
 Captura de requerimientos, manejo de procesos de diseño lógico.
 Manejo de cambios de la especificación funcional.
 Proveer actualizaciones al equipo de arquitectura empresarial.
Desarrollo de agrupación de roles
Área funcional de consulta de tecnología:
 Servir al equipo como consultor de tecnología.
 Evaluar y validar tecnologías
 Participar activamente en la creación y validación de las especificaciones funcionales.
 Contribuir para definir estándares de desarrollo para la organización.
Arquitectura de implementación y diseño funcional de áreas
 Hacer un mapa de la arquitectura de la empresa para la implementación de la
arquitectura de solución proveyendo detalles específicos de la solución para las vistas
de la arquitectura de datos, tecnología y aplicación.
 Implementar el diseño lógico y físico de la solución.
Área de desarrollo funcional de aplicaciones
 Características de código para conocer especificaciones de diseño.
 Revisión de conductas de código durante el desarrollo y compartición de
conocimiento y experiencia.
 Llevar acabo pruebas de unidad así como un plan de pruebas.
Área de desarrollo funcional de infraestructura
 Desarrollo de características que conozcan el diseño de especificaciones.
 Revisión de conductas de código durante el desarrollo y compartición de
conocimientos y experiencias.
 Llevar acabo pruebas de unidad así como un plan de pruebas.
 Desarrollo de scripts para automatizar despliegue.
 Desarrollo de documentación de despliegue
Agrupación de roles de pruebas
 Planeación de pruebas
 Desarrollo de pruebas a través del plan.
 Participar en la configuración de la barra de calidad.
 Desarrollo de especificación de pruebas.
Ingeniería de pruebas
 Desarrollo y mantenimiento automatizado de casos de pruebas, herramientas y
scripts.
 Conducción de pruebas adecuadamente para determinar el estado del producto
desarrollado.
 Administración del proceso de construcción
 Reporte de pruebas
 Proveer al equipo con datos relacionados para la calidad del producto
 Seguimiento de todos los errores y comunicarlos para su solución antes de sacar el
producto al mercado
Agrupación de roles de experiencia del usuario
 Internalización
 Comunicaciones tecnológicas: diseño y desarrollo de documentación para sistemas de
soporte manuales de ayuda, artículos KB (base de conocimiento), Documentación de
ayuda y asistencias.
 Entrenamiento
 Usabilidad: analizar y priorizar los requerimientos de usuarios, proveer
retroalimentación y entradas para el diseño de solución, desarrollo de escenario de
uso y casos de uso.
 Diseño de gráficos: diseño de la interfaz de usuario.
 Accesibilidad: la incorporación de secciones de accesibilidad dentro de cada
característica de especificación, integrando información de accesibilidad en cada
sección de ayuda, asegurarse que la documentación es accesible y completa,
asegurarse que la documentación está en formatos accesibles.
 Globalización
 Localización
Agrupación de roles de la administración de versiones
 Actuar como mediador entre el desarrollo de proyectos y los grupos de operación.
 Manejar la selección de herramientas para actividades de entrega y manejo de
automatización optimizada.
 Configurar un criterio operacional para la entrega de versiones.
 Participación en diseño, concentrándose en la manejabilidad, soportabilidad y
despliegue.
Infraestructura
 Planeación de infraestructura empresarial.
 Ambiente físico de configuración usado y planeación a través de la geografía (centro
de datos, laboratorios, oficinas).
 Proveer al equipo con políticas y procedimientos para concientizar estándares y
manejos de infraestructura.
 Proveer infraestructura de servicios al equipo de MSF (construcción de servicios,
imágenes estándar, instalación de software).
 Gestionar la procuración de hardware/software para el equipo.
 Construcción de pruebas que sirvan de espejo en los ambientes de producción.
Soporte
 Proveer soporte al cliente de TI.
 Soporte para los negocios por medio de comités.
 Proveer resolución a problemas e incidentes; respuestas rápidas a las peticiones de los
usuarios.
 Dar retroalimentación del desarrollo y diseño al equipo.
 Desarrollar procedimientos de recuperación ante las fallas.
Operaciones
 Control de configuración de sistemas y cuentas, administración de cuentas de usuarios
y permisos.
 Mensajes, base de datos, operaciones de telecomunicaciones y redes.
 Administración del sistema, procesamiento de lotes
 Administración del firewall, administración de seguridad
 Servicios de aplicaciones
 Servicios de integración de hosts
 Servicio de operaciones de directorio
Administración de entregas comerciales
 Código de registro de productos, proceso de verificación de registros.
 Administración de licencias
 Empaquetado
 Administración del canal de distribución
 Publicaciones electrónicas e impresas
Modelo de espiral WinWin o MBASE
El desarrollo en espiral es un modelo de ciclo de vida del software definido por
primera vez por Barry Boehm en 1986,1 utilizado generalmente en la ingeniería de
software.
Las actividades de este modelo se conforman en una espiral, en la que cada bucle
o iteración representa un conjunto de actividades. Las actividades no están fijadas
a ninguna prioridad, sino que las siguientes se eligen en función del análisis de
riesgo, comenzando por el bucle interior.

El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de

negociación al principio de casa 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.

 Determinación de las condiciones de victoria de los directivos.
 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).

El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos

de fijación que ayudan a establecer la completitud de un ciclo alrededor de la
espiral y proporcionan hitos de decisión antes de continuar el proyecto de
software.

Para cada ciclo habrá cuatro actividades:

1. Determinar objetivos
2. Análisis del riesgo
3. Desarrollar y probar
4. Planificación
Determinar o fijar objetivos

 Fijar también los productos definidos a obtener: requisitos, especificación,

manual de usuario.
 Fijar las restricciones.
 Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
 Hay una cosa que solo se hace una vez: planificación inicial.
Desarrollar, verificar y validar (probar)

 Tareas de la actividad propia y de prueba.

 Análisis de alternativas e identificación resolución de riesgos.
 Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo
para el desarrollo, el que puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz
de usuario son dominantes, un modelo de desarrollo apropiado podría ser la
construcción de prototipos evolutivos. Si lo riesgos de protección son la
principal consideración, un desarrollo basado en transformaciones formales
podría ser el más apropiado.
Análisis del riesgo

 Se lleva a cabo el estudio de las causas de las posibles amenazas y probables

eventos no deseados y los daños y consecuencias que éstas puedan producir.
Se evalúan alternativas. Se debe tener un prototipo antes de comenzar a
desarrollar y probar.
En resumen, es para tener en cuenta los riesgos de cada uno de los ámbitos.