EL MODELO ESPIRAL

ITBA
REPORTES TECNICOS
CAPIS
EL MODELO ESPIRAL
Maestrando: Lic. Daniel Corcos
Introducción
El objetivo de este trabajo consiste en dar una visión más clara del modelo
espiral.
Esto viene motivado por su creciente importancia en el uso del mismo en
grandes proyectos, los cuales cada vez más son permeables al riesgo aspecto
que este modelo toma como su fundamento.
Los pasos a seguir serán: Breve descripción del mismo, desarrollos de sus
etapas, comentarios sobre sus fortalezas y debilidades, alternativas para su
mejora y finalmente un enfoque personal del mismo.
Nos consideraremos satisfechos si estas breves líneas ayudan a mejorar su
entendimiento y contribuyen a su mejor difusión.
Estado de la Tecnología
En la actualidad se pueden indicar una infinidad de modelos de ciclo de vida,
sin embargo, y a pesar de esta proliferación es dable indicar, a mi entender,
que buena parte de ellos se basan en una u otra medida en dos básicos los
llamados en cascada y los prototipados.
Dentro de los de cascada podrían incluirse: Mejora iterativa, emisión gradual,
estándares militares.
Dentro de los prototipados podrían incluirse: los alternativos evolutivos y los
de producción de software operativos.
El modelo espiral surge como un modelo no operativo de producción de
software que tiende a poner énfasis allí donde los demás tiene sus debilidades,
es decir, en el riesgo a asumir en cada etapa y el control del mismo.
Debemos decir no obstante que como modelo reciente en comparación con los
demás adolece de algunos inconvenientes que se indicarán pero tiene una
manera original de generar software que supera con creces los inconvenientes,
sobre todo allí donde los problemas financieros, de tecnologías innovativas o
cualidades particulares del software hacen que los otros modelos tiendan a no
conformar para su elección.
_____________________________________________________________________________________
1
ITBA
REPORTES TECNICOS
CAPIS
Identificación del Problema
Estas líneas no pretenden ser de modo alguno una avanzada sobre el modelo
a tratar, teniendo en cuenta que en su corta vida ya tiene varias decenas de
libros y cientos o miles de artículos sobre el mismo
Nuestro principal afán es el de dar una muy resumida síntesis del mismo y una
pequeña aportación personal que no incluyen ninguno de los artículos y libros
consultados.
Bases Iniciales
El modelo basa sus características en sucesivas iteraciones hasta cumplir
cierto hito o condiciones prefijadas para derivar a partir de allí en los modelos
clásicos (cascada o prototipado).
En el primer caso una vez realizadas determinado número de iteraciones se
pasará a un desarrollo acotado del modelo de cascada.
En el ultimo caso lo que se indica es que se usará el ciclo de vida espiral para
obtener un prototipo operativo y de allí en mas se utilizara el ciclo de vida
propio del prototipo. (Ver Anexo 1).
En ningún caso es necesario fijar este hito o las condiciones para pasar a los
modelos clásicos en la primera iteración.
A diferencia de la idea de estos modelos iterativos donde los espirales suelen
ser hacia el centro, es decir, que los primeros ciclos involucran las tareas más
importantes y los ciclos mas avanzados tareas de refinamiento hasta llegar al
objetivo; en el modelo espiral las primeras iteraciones realizan tareas muy
generales que se van ampliando a medida que se abarca los demás ciclos por
lo que el espiral se va abriendo a medida que avanzamos y su culminación
debe ser hecha por otros caminos y no por sí mismo.
Un caso clásico de espiral hacia el centro puede verse en el modelo de Deming
de circulo de calidad. (Ver Anexo 2)
En el caso del modelo espiral de Boehm las etapas son las mismas para cada
ciclo pero las tareas a realizar en cada una son mayoritariamente definidas por
el ciclo anterior.
El área del espiral así trazado vá abarcando cada vez mas requisitos, limites y
condiciones de contorno.
A los efectos de referirse diferenciadamente de los aspectos iterativos del inicio
a los aspectos de los modelos clásicos Boehm llama a los primeros ciclos
interiores y a los segundos ciclos exteriores, si bien estos últimos no tienen en
general un aspecto iterativo.
Dicho de otra manera los ciclos interiores tienen etapas diferenciadas de los
ciclos exteriores siendo para el primer caso: Planificación, Análisis de Riesgo,
Ingeniería, Evaluación, Toma de Decisiones, Refinamiento, y para el segundo
caso (si hablamos del ciclo de cascada): Factibilidad, Requisitos, Desarrollo
Preliminar, Desarrollo Detallado, Codificación, Integración y Prueba,
Implementación, Operación y Mantenimiento y Retiro.
_____________________________________________________________________________________
2
ITBA
REPORTES TECNICOS
CAPIS
Un aspecto interesante señalado por el propio autor es que de acuerdo a la
característica del modelo real este modelo en espiral, luego de los ciclos
internos, deriva en sus ciclos externos directamente en las etapas del
prototipado o el de cascada. (Las condiciones de pasaje de los ciclos internos a
los externos se indicarán posteriormente).
Etapas del Modelo
Las etapas del modelo pueden ser las siguientes:
TABLA 1. Etapas del Modelo
Etapas
Planificación
Aspectos a lograr
Determinación de objetivos,
limites
y
condiciones
de
contorno
(condiciones
que
limitan de alguna manera el
desarrollo, económicas, de
tiempo, etc.) y alternativas.
Actividades
Predecir la duración de las
actividades y tareas de
nivel individual, Recursos
requeridos, concurrencia y
solapamiento de tareas
para el desarrollo en
paralelo y camino crítico a
través de la red de
actividades.
Estimar recursos:
Predicción de personal
esfuerzo y costo que se
requerirán para terminar
las actividades y productos
conocidos asociados con
el proyecto.
Planificar
tareas
y
solapamiento
de
actividades y tareas.
Definir y desarrollar los
requerimientos
de
software.
Definir los requisitos de
interfaz.
Priorizar e integrar los
requisitos de software.
Etapas
Aspectos a lograr
Actividades
_____________________________________________________________________________________
3
ITBA
REPORTES TECNICOS
CAPIS
Análisis de Riesgo
Desarrollo de un plan para
descubrir los riesgos más
importantes
y resolver los
mismos.
Eliminación de aspectos no
compatibles
con
las
condiciones, o condiciones de
contorno o límites. (ver anexo 3)
Ingeniería
Desarrollo del producto o Realizar
el
diseño
prototipo según las condiciones arquitectónico.
de la etapa anterior.
Analizar
el
flujo
de
información.
Diseñar la base de datos.
Seleccionar o desarrollar
algoritmos.
Realizar
el
diseño
detallado de la etapa.
Crear el código fuente.
Evaluación
Evaluar los resultados del Crear los datos de prueba
prototipo obtenido, verificar y de código fuente.
validar.
Ejecutar las tareas de
Verificación y validación.
Identificar
ideas
o
necesidades.
Formular
soluciones
potenciales.
Conducir
estudios
de
viabilidad.
Planificar la transición del
sistema.
Refinar y finalizar la idea o
necesidad.
Analizar las funciones del
sistema.
Desarrollar la arquitectura
del sistema.
Descomponer
los
requisitos del sistema.
Planificación
de
contingencias.
Recoger y analizar los
datos de la métrica.
Planificar las pruebas.
Desarrollar
especificaciones
pruebas.
de
las
las
Ejecutar las pruebas.
Generación
de
los
Aspectos
de
mejora,
errores,
defectos,
ampliaciones.
_____________________________________________________________________________________
4
ITBA
REPORTES TECNICOS
Etapas
Toma de decisiones
Aspectos a lograr
Se determina si se pasa al ciclo
exterior o se realiza una nueva
iteración.
Refinamiento
Si se toma la decisión de
continuar en los ciclos internos
Se sofistican las condiciones a
tomar
en
cuenta
en
el
planeamiento del nuevo ciclo, en
los ciclos exteriores es una etapa
que no se utiliza.
CAPIS
Actividades
Evaluación
de
resultados.
Contraste con los hitos
fijados o condiciones
predeterminadas.
Fijación
de
las
Condiciones de pasaje
a los ciclos externos de
no haberlas fijado.
Repetición del ciclo o
pasaje a otro modelo.
Técnicas de toma de
decisiones (arboles de
decisión, decisiones en
condiciones
de
incertidumbre, etc.).
No hay actividades
específicas,
sino
aquellas que generan
las posibilidades de
sofisticar
indicadas
anteriormente.
Debe indicarse que el número de etapas pueden variarse o subdividirse
generando entre cuatro y siete de ellas según la importancia que se pretende
dar a cada una por lo que lo que aquí describimos es una interpretación posible
de las mismas.
La ultima indicada, por ejemplo, podría incorporase a la evaluación pero se la
indica explícitamente para dar una idea más clara del fundamento del modulo.
Alguna de las etapas tienen tareas o actividades que quizá no se contemplen
en forma específica en la norma IEEE 1074-1989, ya que si bien esta norma es
independiente del modelo, indica las tareas que se deben realizar pero no es
excluyente.
Algunas de las tareas no contempladas pueden ser:
Análisis de riesgo, identificación, proyección, evaluación, resolución y gestión,
toma de decisiones, técnicas de toma de decisiones.
De la tabla anterior se podría indicar como ya lo han hecho otros autores que
cuando el riesgo es todavía el dominante puede derivarse en un modelo
evolutivo (control de interfases en riesgo o problemas con las especificaciones),
o en una segunda fase del propio espiral. Si el riesgo es pequeño y se han
resuelto todos los problemas de interfases (de usuario, de control, etc.) y
como resultado de ello se obtuvo un prototipo operacional es posible derivar a
un modelo de cascada.
_____________________________________________________________________________________
5
ITBA
REPORTES TECNICOS
CAPIS
Fortalezas y Debilidades
Finalmente podemos indicar las fortalezas y debilidades de este modelo según
expresan deferentes autores.
Tabla 2. Fortalezas y Debilidades
Fortalezas
Debilidades
Evita las dificultades que corresponden a otros No provee un proceso específico de guía
modelos a través de un manejo del riesgo.
para determinar los objetivos, alternativas,
límites y condiciones de contorno.
Trata de eliminar errores en fase temprana.
Provee una flexibilidad mas que la
conveniente para muchos proyectos.
Es el mismo modelo para el desarrollo y el Se necesitan expertos para prever el
mantenimiento.
riesgo, no siendo una tarea fácil la
resolución de dicho riesgo.
Provee mecanismos para el aseguramiento de la Es un modelo en pleno desarrollo.
calidad del software.
Es aplicable a otras clases de proyectos, diferentes Es poco aplicable a proyectos bajo
a las de producción de software
contrato.
Puede ser aplicado a proyectos complejos, No es aplicable a proyectos sencillos
dinámicos y ambiciosos.
donde su dominio de aplicación es
conocido y previsible.
La debilidad citada en última instancia podría no considerarse una debilidad,
por ejemplo: Si se fabricó un monitor blanco y negro no se puede decir que una
de sus debilidades sea que no puede proyectar colores.
Sin embargo, un modelo de ciclo de vida debería poder adaptarse a todas las
circunstancias de un desarrollo de software y la única condición para adaptar
un modelo de ciclo de vida u otro debería estar dada por el tipo y
características intrínsecas del desarrollo y en este sentido algunos autores
indican esto como una debilidad.
Algunas alternativas para mejorar los aspectos de debilidad de esta teoría
están en pleno desarrollo y podrían indicarse como:
Tabla 3. Debilidades y Alternativas
Debilidades
No provee un proceso específico de guía para
determinar los objetivos, alternativas, límites y
condiciones de contorno.
Alternativas
Se puede utilizar la teoría W, donde se
trata de consensuar las restricciones de
los distintos participantes de manera de
obtener los objetivos ganadores (win
objetives) de cada parte interviniente y
consensuarlos. Del mismo modo se utiliza
la teoría para fijar los limites y condiciones
de contorno.
_____________________________________________________________________________________
6
ITBA
CAPIS
REPORTES TECNICOS
Debilidades
Alternativas
Provee una flexibilidad mas que la conveniente Quizá la propuesta de un espiral
para muchos proyectos.
cuantitativo dada mas adelante pueda
adaptarse mejor al problema de la
excesiva flexibilidad pues tiende a
contener el modelo en parámetros visibles.
Se necesitan expertos para prever el riesgo, no Es un aspecto todavía no resuelto, si bien
siendo una tarea fácil la resolución de dicho riesgo. se pueden utilizar técnicas de generación
de ideas (brain storming) para mejorar
este aspecto.
El uso de teorías de decisión puede
mejorar el aspecto de toma de decisiones.
Es un modelo en pleno desarrollo y no probado en Es un aspecto que el tiempo y lo indicado
muchos proyectos.
en esta tabla contribuirán a solucionar.
Es poco aplicable a proyectos bajo contrato.
Están surgiendo nuevas modalidades de
contratación
como
la
contratación
competitiva y contratos de diseño-costo.
No es aplicable a proyectos sencillos donde el Es posible atenuar en algunos casos las
dominio de aplicación es conocido y previsible.
etapas del espiral a fin que pueda
utilizarse en estos casos.
Espiral Cuantitativo (Contribución del Autor)
Como idea personal se ha desarrollado un espiral que llamaremos cuantitativo
que tiende a dar una imagen del espiral clásico pero adaptado a las situaciones
de presupuesto, tiempo, etapas de iteración y avance del proyecto lo que
permite a un solo golpe de vista verificar donde sé esta en el proyecto.
La idea básica tiende a superponer sobre el espiral clásico 2 ejes cartesianos
ortogonales que contiene respectivamente las siguientes características:
Eje X positivo:
Cronograma del proyecto en una escala adecuada
Eje X negativo:
Vueltas del espiral por número a distancias regulares
Eje Y positivo:
Presupuesto para cada etapa (en porcentual)
Eje Y negativo;
Avance del proyecto (en porcentual)
La construcción que sigue se basa en las siguientes condiciones hipotéticas.
Tabla 4. Datos para la Construcción del Gráfico del Espiral Cuantitativo
Fase
1
Presupuesto
(%)
20
Cronograma
(Meses)
8
Requisitos
Cumplidos (%)
40
2
40
12
50
Decisiones
Tomadas
Continuar el
espiral
Continuar el
espiral
_____________________________________________________________________________________
7
ITBA
CAPIS
REPORTES TECNICOS
Se puede agregar a cada eje una marca o hito (o más de una de ellas) que nos
permitiría apreciar cuan cerca o lejos estamos de determinada restricción, limite
o característica del proceso como puede ser el presupuesto para el ciclo
interno o externo, los requisitos (en porcentaje) fijados como base y el tiempo
límite para los ciclos internos o todo el desarrollo.
100
Presupuesto (%)
90
80
70
60
50
Determinación de objetivos,
limites y condiciones de
contorno
40
Análisis de riesgo y
resolución de los mismos
30
20
Etapas o
ciclos
5
Cronograma (en
meses o escala
adecuada)
10
4
3
2
4
1
8
12
16
20
10
20
Evaluación y toma de
decisiones
30
Ingeniería
40
50
60
70
80
90
Avance (Cumplimiento de
requisitos)
_____________________________________________________________________________________
8
ITBA
REPORTES TECNICOS
CAPIS
ANEXO 1
En este anexo se trata de indicar las similitudes
modelos de prototipado y el modelo espiral.
y diferencias entre los
Tabla 5. Similitudes y Diferencias entre el Modelo Espiral y el Prototipado
Modelo Espiral y Modelo de Prototipado
Similitudes
Modelo Espiral y Modelo Prototipado
Diferencias
Ambos modelos contienen componentes para El modelo espiral es mas abarcativo que el
establecer objetivos, desarrollo del modelo y modelo de prototipado.
evaluación del mismo.
Ambos modelos pueden ser usados con una El modelo espiral incorpora el análisis de
terminación en ciclo de vida en cascada.
riesgo el cual no esta representado en el
modelo prototipado.
La calidad del software es incluida como uno de El modelo prototipado es manejado
los objetivos del modelo espiral y un crecimiento de primariamente por el código y pone una
la calidad del software puede ser consecuencia del poca atención a la gestión del riesgo.
modelo prototipado.
El prototipado es la llave técnica de la evaluación El modelo espiral es mas apropiado para
del riesgo en el modelo espiral.
grandes proyectos mientras que el de
prototipado es apropiado para pequeños
sistemas o proyectos.
Los prototipos evolutivos pueden ser incluidos en el La naturaleza de modelo manejado por el
modelo espiral para el caso donde un prototipo riesgo del espiral hace que este pueda
detallado sea útil.
adaptarse a una mucho más amplia gama
de proyectos de software que el
prototipado.
_____________________________________________________________________________________
9
ITBA
CAPIS
REPORTES TECNICOS
Anexo 2
Figura 1. Espiral de la Calidad de Deming
Planificar
Comercializar y
Analizar
Hacer
Testear
El círculo de calidad de Deming suele también llamarse PDCA del ingles Plan,
Do, Check, Act y Analyze, que en castellano podríamos indicar como Planificar,
Hacer, Testear, Comercializar y Analizar.
Como se observa el ciclo en el paso final se debe rediseñar y mejorar lo que
provocará un nuevo ciclo.
Sin entrar a analizar las bondades o defectos de este método, el citarlo es
solamente para realizar unas consideraciones sobre el tipo de espiral que
provoca.
En el primer paso, cuando aún no se tiene el producto y debe hacerse el
estudio de mercado, diseñarlo, planificar su producción, fabricarlo, verificar lo
obtenido, imponerlo en el mercado y volver a realizar el estudio para posibilitar
medir la respuesta de los consumidores estaríamos en la fase mas amplia del
espiral.
Los trabajos de rediseño, mejora etc. son generalmente menores que el
primero dado que la base ya esta lanzada (salvo que nos hubiéramos
equivocado en el primer paso estrepitosamente), de allí que esta segunda y
demás vueltas del espiral son hacia adentro.
Si bien podría decirse que siempre se pude mejorar, rediseñar etc., en general
esto termina en algún momento para el producto lanzado y en vez de continuar
las mejoras se piensa en otro que abarque todas las funciones de este y las
mejore.
Téngase en cuenta que de no ser así, no habría un modelo de fabricación y
cada partida sería de alguna manera diferente a la anterior lo cual es
contraproducente desde el punto de vista comercial
_____________________________________________________________________________________
10
ITBA
REPORTES TECNICOS
CAPIS
Anexo 3
Diferentes Tipos de Riesgo y sus Formas de Tratarlos
Riegos
Identificación de Riesgos
Análisis de Riesgos
Costo y Calendario
Formas de Tratarlos
Lista de Chequeo
Taxonomía basada en riesgos
Análisis de manejo de decisiones
Arbol de Decisiones
Modelo de Nodos (PERT)
Trabajo de rotura de estructuras (WBS)
Modelo de Putman
Cocomo
Método del Factor de Riesgo
Presupuesto
Resolución del Riesgo
Reducción
Protección
Transferencia
Prototipado
Modelado
Simulación
Benchmarking
Desarrollo de la Ingeniería
Lista de Chequeo
Recursos Humanos
Monitoreo del Riesgo
Acciones de Proactividad
Monitoreo de los 10 riesgos principales
Revisión e Inspección
Indice de Madurez del Software
Métrica
Entrenamiento
Comunicación
Desarrollo, Control del Planeamiento
Aspectos Colaterales al Riesgo
Bibliografía:
Andrea Gabor
Granica
SPC-93098-CMC
Deming, "El Hombre que Descubrió la Calidad", Editorial:
"Evolucionary Spiral Process Model Guidebook"
Boehm Barry W. "A Spiral Model of Software Development and Enhancement"
Humphrey, Watts S. "A Discipline for SoftwareEngineering"
Herz M. "Relationship To The Spiral Model"
Hertz M. "Strengths and Weaknesses of The Spiral Model"
_____________________________________________________________________________________
11
ITBA
REPORTES TECNICOS
CAPIS
Boehm, Barry W. y otros "Developing Multimedia Applications with the Win
Win Spiral Model".
Krumholtz, Nira "The Spiral Model of Technology Evolution: A Base for
curriculum Development"
Sullivan, Kevin J.
"Real Option in Software Engineering".
Ghezzi Carlo y otros "Fundamentals of Software Engineering".
Pressman, Roger S. "Ingeniería del Software".
Un Enfoque Práctico
Kim, Jongseok: "Risk Management in the Spiral Model"
_____________________________________________________________________________________
12