modelo espiral

Presentacion

Modelo en Espiral

Algo de Historia

El creador del modelo en espiral fue Barry Boehm quien recibió su grado de B.A. de Harvard en 1957, y sus grados de M.S. y de Ph.D. de UCLA en 1961 y 1964, todo en matemáticas.

Entre los años de 1989 y 1992, sirvió dentro del departamento de ESTADOS UNIDOS de la defensa (DoD) como director de la oficina de las ciencias y de la tecnología de la información de DARPA, y como director del software de DDR&E y de la oficina de la informática, trabajó en TRW a partir de 1973 a 1989, culminando como principal científico del grupo de los sistemas de la defensa, y en el Rand Corporation a partir de 1959 a 1973, culminando como jefe del departamento de las ciencias de la información.

Barry 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.

DEFINICION

El Modelo en Espiral es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Ideal para realizar versiones incrementales de manera rápida, que no se basa en fases claramente definidas y separadas para crear un sistema. Se divide en un número de actividades de marco de trabajo, también llamadas regiones de tareas , Cada una de las regiones Están compuestas por un conjunto de tareas del trabajo llamado conjunto de tareas.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las ultimas iteraciones se producen versiones cada vez mas completas del sistema diseñado.

Cada vuelta en la espiral se divide en sectores:

Comunicación con el Cliente: Las tareas requeridas para establecer, comunicación entre el desarrollador y el cliente

Planificación o Planeación: Las tareas requeridas para definir recursos, el tiempo, determinación de los objetivos, alternativas y restricciones y otra información relacionadas con el proyecto.

Análisis de Riesgos: Las tareas requeridas para evaluar riesgos tecnicos y de gestion, análisis de alternativas e identificación/resolución de riesgos

Ingeniería:Las tareas requridas para construir una o mas representaciones de la aplicación, desarrollo del producto hasta "el siguiente nivel".

Construcción y Acción: Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo, documentación y práctica).

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 implementada durante la etapa de instalación. Valoración por parte del cliente de los resultados obtenidos.

VARIANTES

Modelo Original de Bohem

• No hay un número definido de iteraciones. Las iteracones debe decidirlas el equipo de gestión de proyecto.
• Cada vuelta se divide en 4 sectores:
  Planeación : determinación de los objetivos, alternativas y restricciones
  Análisis de riesgo : análisis de alternativas e identificación/resolución de riesgos
  Ingeniería : desarrollo del producto hasta "el siguiente nivel".
  Evaluación : valoración por parte del cliente de los resultados obtenidos.
• El movimiento de la espiral, ampliando con cada iteración su amplitud radial, indica que cada vez se van construyendo versiones sucesivas del software, cada vez más completas.
  Uno de los puntos más interesantes del modelo, es la introducción al proceso de desarrollo a las actividades de análisis de los riesgos asociados al desarrollo y a la evaluación por parte del cliente de los resultados del software.

Modelo Espiral Típico de Seis Regiones

• Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral puede producir el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software. Cada paso por la región de planificación produce ajuste en el plan del proyecto.
• A diferencia del modelo de proceso clásico que termina cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Una visión alternativa del modelo en espiral puede ser considerada examindo el eje de punto de entrada en el proyecto.
• Cada uno de los cubos situados a lo largo del eje puede usarse para representar el punto de arranque para los diferentes tipos de proyectos. Un proyecto de desarrollo de concepto comienza en el centro del espiral continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el producto continúa a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.
  

Modelo Espiral WINWIN

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 del espiral y proporcionan hitos de decisión antes de continuar el proyecto de software.

MODELO ESPIRAL

Idea General

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 priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

Introduccion

La Ingeniería de software, se vale y establece de una serie de modelos que establecen y muestran las distintas etapas y estados por lo que pasa un producto software, desde su concepción inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les denomina «modelos de ciclo de vida del software».

El primer modelo concebido fue el de Royce, más comunmente conocido como desarrollo en cascada o desarrollo lineal secuencial. Este modelo establece que las diversas actividades que se van realizando al desarrollar un producto software se suceden de forma lineal.

Boehm, autor de diversos artículos de ingeniería del software; modelos de estimación de esfuerzo y tiempo que se consume en hacer productos software; y Modelos de Ciclo de Vida; ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. 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.

Este modelo fue propuesto por Boehm en 1988. Básicamente consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un Modelo Cascada, pero no necesariamente debe ser así. El Espiral puede verse como un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada, con el agregado de gestión de riegos.

En cada vuelta o iteración hay que tener en cuenta

Los Objetivos: Que necesidad debe cubrir el producto.
Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:

• Características: experiencia del personal, requisitos a cumplir, etc.
• Formas de gestión del sistema.
• 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:

• Angular: Indica el avance del proyecto software dentro de un ciclo.
• 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.

Tareas

Para cada ciclo habrá cuatro actividades:

Determinar o fijar objetivos
• Fijar también los productos definidos a obtener: requerimientos, 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 o previa.

Análisis del riesgo
• Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.

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.

Planificar

• Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.

Mecanismos de control
• La dimensión radial mide el coste.

• La dimensión angular mide el grado de avance del proyecto.

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

Planificar un proyecto con esta metodología es a menudo imposible, debido a la incertidumbre en el número de iteraciones que serán necesarias. En este contexto la evaluación de riesgos es de la mayor importancia y, para grandes proyectos, dicha evaluación requiere la intervención de profesionales de gran experiencia.