Trabajo de Modelo Espiral 6 Regiones - asig-ingenieria

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