MODELO ESPIRAL DE 6 REGIONES CRISTIAN CAMILO RIASCOS JHENNIFER SANCHEZ ORTIZ ALEJANDRO PINEDA SANCHEZ FERNANDO JAVIER REBELLÓN HURTADO INFORMATICA EMPRESARIAL III (NOCHE) CARTAGO VALLE COTECNOVA 2011-09-03 MODELO ESPIRAL DE 6 REGIONES CRISTIAN CAMILO RIASCOS JHENNIFER SANCHEZ ORTIZ ALEJANDRO PINEDA SANCHEZ FERNANDO JAVIER REBELLÓN HURTADO Trabajo de técnicas de ingeniería de software presentado a la profesora Sonia Godoy CARTAGO VALLE COTECNOVA 2011-09-03 OBJETIVOS Conocer que es un modelo en espiral. Analizar sus regiones de tareas. Identificar cuales son las labores que realiza cada una de sus regiones. Entender cuales son las diferencias del modelo en espiral de 4 regiones y de 6 regiones. Comprender cuales son las ventajas y desventajas de este modelo. Entender porque llegaron a modificar el modelo anterior. Conocer como funciona el ciclo de vida. Identificar en donde se esta utilizando este modelo. Conocer las pautas que se deben tener en cada iteración o vuelta. CONTENIDO INTRODUCCIÓN .................................................................................................. 5 BIOGRAFIA DEL CREADOR M.E.6.R ............................................................... 6 DEFINICION .......................................................................................................... 7 CICLO DE VIDA ................................................................................................... 8 REGIONES ............................................................................................................. 9 EXPLICACION REGIONES……………………………………………………..9 VENTAJAS……………………………………………………………………....13 DESVENTAJAS…………………………………………………………………15 INCONVENIENTES…………………………………………………………….16 EJEMPLOS DE UTILIZACION………………………………………………...16 CONCLUSIONES……………………………………………………………….17 BIBLIOGRAFIA .................................................................................................. 18 INTRODUCCIÓN 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 últimas iteraciones se producen versiones cada vez mas completas del sistema diseñado. BIOGRAFIA DEL CREADOR M.E.6.R 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 quantum de la productividad del software de TRW saltan el ambiente. MODELO ESPIRAL DE 6 REGIONES 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 últimas iteraciones se producen versiones cada vez mas completas del sistema diseñado. Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada. Proporciona potencial para desarrollo rápido de versiones incrementales. En el modelo Espiral el software se construye en una serie de versiones incrementales. En las primeras iteraciones la versión incremental podría ser un modelo en papel o bien un prototipo. En las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado. 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 examinando el eje de punto de entrada en el proyecto. El modelo está dividido en actividades en marco de trabajo, conocidas como Regiones de Tareas, en común existen entre tres y seis regiones de tareas. Las actividades para el marco de trabajo son generales y son aplicables en cualquier proyecto, ya sea grande, mediano, pequeño y no importa si es complejo o no. Las regiones que definen esas actividades se comprenden un conjunto de tareas de trabajo. El modelo espiral da un enfoque realista, que evoluciona igual que el software, de manera que se adapta bien al desarrollo de software, por considerar los riesgos técnicos en todas las etapas del proyecto, para reducirlos antes que sea un verdadero. CICLO DE VIDA MODELO ESPIRAL PARA EL CICLO DE VIDA DEL SOFTWARE Las regiones definidas en el modelo de la figura son: Región 1 - Tareas requeridas para establecer la comunicación entre el cliente y el desarrollador. Región 2 - Tareas inherentes a la definición de los recursos, tiempo y otra información relacionada con el proyecto. Región 3 - Tareas necesarias para evaluar los riesgos técnicos y de gestión del proyecto. Región 4 - Tareas para construir una o más representaciones de la aplicación software. Región 5 - Tareas para construir la aplicación, instalarla, probarla y proporcionar soporte al usuario o cliente (Ej. documentación y práctica). Región 6 - Tareas para obtener la reacción del cliente, según la evaluación de lo creado e instalado en los ciclos anteriores. Las actividades enunciadas para el marco de trabajo son generales y se aplican a cualquier proyecto, grande, mediano o pequeño, complejo o no. Las regiones que definen esas actividades comprenden un «conjunto de tareas» del trabajo: ese conjunto sí se debe adaptar a las características del proyecto en particular a emprender. Nótese que lo listado en los ítems de 1 a 6 son conjuntos de tareas, algunas de las ellas normalmente dependen del proyecto o desarrollo en si. Proyectos pequeños requieren baja cantidad de tareas y también de formalidad. En proyectos mayores o críticos cada región de tareas contiene labores de más alto nivel de formalidad. En cualquier caso se aplican actividades de protección (por ejemplo, gestión de configuración del software, garantía de calidad, etc.). Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniería gira alrededor del espiral (metafóricamente hablando) comenzando por el centro (marcado con ๑ en la figura) y en el sentido indicado; el primer circuito de la espiral puede producir el desarrollo de una especificación del producto; los pasos siguientes podrían generar un prototipo y progresivamente versiones más sofisticadas del software. Cada paso por la región de planificación provoca ajustes en el plan del proyecto; el coste y planificación se realimentan en función de la evaluación del cliente. El gestor de proyectos debe ajustar el número de iteraciones requeridas para completar el desarrollo. El modelo espiral puede ir adaptándose y aplicarse a lo largo de todo el Ciclo de vida del software (en el modelo clásico, o cascada, el proceso termina a la entrega del software). Una visión alternativa del modelo puede observarse examinando el «eje de punto de entrada de proyectos». Cada uno de los circulitos (๏) fijados a lo largo del eje representan puntos de arranque de los distintos proyectos (relacionados); a saber: Un proyecto de «desarrollo de conceptos» comienza al inicio de la espiral, hace múltiples iteraciones hasta que se completa, es la zona marcada con verde. Si lo anterior se va a desarrollar como producto real, se inicia otro proyecto: «Desarrollo de nuevo Producto». Que evolucionará con iteraciones hasta culminar; es la zona marcada en color azul. Eventual y análogamente se generarán proyectos de «mejoras de productos» y de «mantenimiento de productos», con las iteraciones necesarias en cada área (zonas roja y gris, respectivamente). Cuando la espiral se caracteriza de esta forma, está operativa hasta que el software se retira, eventualmente puede estar inactiva (el proceso), pero cuando se produce un cambio el proceso arranca nuevamente en el punto de entrada apropiado (por ejemplo, en «mejora del producto»). El modelo espiral da un enfoque realista, que evoluciona igual que el software; se adapta muy bien para desarrollos a gran escala. El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la evolución. Mantiene el enfoque clásico (cascada) pero incorpora un marco de trabajo iterativo que refleja mejor la realidad. Este modelo requiere considerar riesgos técnicos en todas las etapas del proyecto; aplicado adecuadamente debe reducirlos antes de que sean un verdadero problema. El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de Sistemas Operativos (complejos); también en sistemas de altos riesgos o críticos (Ej. navegadores y controladores aeronáuticos) y en todos aquellos en que sea necesaria una fuerte gestión del proyecto y sus riesgos, técnicos o de gestión. Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por lo que no se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difícil de implementar y controlar. 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 examinando el eje de punto de entrada en el proyecto. Las regiones de tareas que componen este modelo son: Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos. Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto. Ingeniería: las tareas requeridas representaciones de la aplicación. para construir una o más Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Evaluación del cliente: las 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. 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 [editar] 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. ANALISIS 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. ANALISIS DE ALTERNATIVAS E IDENTIFICACION Y RESOLUCION 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. VARIACIONES DEL MODELO EN ESPIRAL Modelo en Espiral Típico de seis regiones. Modelo en espiral WIN WIN. 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. 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. En la utilización de grandes sistemas a doblado la productividad. 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. El análisis de riesgo se lo hace de forma explícita y clara. Integra el desarrollo con el mantenimiento de software.etc. Mejoras y nuevos requerimientos sin romper la metodología, ya que este ciclo de vida no es rígido ni estático. Prevenir los errores que se nos pueden presentar en un futuro, lo cual es muy positivo para poder mejorar la calidad del software. Utiliza los prototipos para disminuir los riegos desde el punto de vista técnico. Si nos tardamos mucho tiempo en pasar a otro nivel superior el proyecto se lo puede abandonar para no gastar ni tiempo ni dinero en vano. El desarrollador y el cliente comprenden y reacción mejor ante riesgos en cada uno de los niveles evolutivos. Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. Mantiene el enfoque del ciclo de vida clásico pero lo incorpora al marco de trabajo interactivo que refleja un mundo más realista de la naturaleza del proyecto. Hace una consideración directa de los riesgos técnicos en todas las etapas del proyecto de tal manera que si se aplica adecuadamente reduce los riesgos antes de convertirse en problemáticos. El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software. 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. Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en problemáticos. Es nuevo y no se ha utilizado tanto como otros modelos de ciclo de vida. Requiere una considerable habilidad para la evaluación del riesgo, y cuenta con esta habilidad para el éxito. 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. Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto. Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo. Como se va planificando ciclo por ciclo (vuelta por vuelta) no sabemos cuanto tiempo nos demandará en realizar el software, por lo tanto este modelo no es recomendable para realizar un proyecto de software bajo contrato. Al elaborarlo por partes no tenemos una visión global del problema. Aquí nos dice que los prototipos se van validando, lo cual es muy negativo porque como ya se ha dicho ningún software debe empezar como un prototipo. Como es un modelo relativamente nuevo no es muy utilizado como los paradigmas lineales secuenciales o de construcción de prototipos. Debido a su elevada complejidad no se aconseja utilizarlo en sistemas pequeños (sobre-costo de gestión). INCONVENIENTES 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. El IEEE clasifica al desarrollo en espiral como modelo no operativo en sus clasificaciones de MCV. El modelo espiral de 6 regiones se utiliza en los siguientes ejemplos: Navegadores y controladores aeronáuticos CONCLUSIONES Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por lo que no se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difícil de implementar y controlar. Que el Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de Sistemas Operativos complejos. Realizar el presente trabajo nos ha permitido conocer una de las dos clases de modelo espiral que se manejan en la actualidad. Que requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto. Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo. Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada. BIBLIOGRAFIA http://es.geocities.com/modeloespiral/definicion.htm http://es.wikipedia.org/wiki/Desarrollo_en_espiral http://148.202.148.5/cursos/cc321/fundamentos/unidad1/espiral.htm Desarrollo en espiral. (2009, 28) De septiembre. Wiki pedía, La enciclopedia libre. Fecha de consulta: 21:12, diciembre 14, 2009 http://es.wikipedia.org/w/index.php?title=Desarrollo_en_espiral&oldid=301 35499