La Junta de tareas Informe de la Fuerza de Defensa de la Ciencia en Software

Militar 'emitido en 1987 puso de relieve la preocupacin de que los modelos

tradicionales de proceso de software fueron desalentadores enfoques ms
eficaces para el desarrollo de software, tales como la creacin de prototipos y
el software de su reutilizacin. The Computer Society ha patrocinado tutoriales
y talleres sobre modelos de procesos de software que han ayudado a aclarar
muchas de las cuestiones y estimulados avances en el campo (ver "Otras
lecturas").
El modelo en espiral se presenta en este artculo es uno de los candidatos para
mejorar la situacin modelo de proceso de software. La caracterstica distintiva
importante del modelo en espiral es que crea un enfoque orientado al riesgo al
proceso de software en lugar de un proceso fundamentalmente documentar
impulsada o cdigo de motor. Incorpora muchos de los puntos fuertes de otros
modelos y resuelve muchas de sus dificultades.
Este artculo comienza con una breve descripcin de los modelos de procesos
de software y los temas que tratan. Las secciones siguientes describen los
pasos del proceso que intervienen en el modelo en espiral; ilustrar la aplicacin
del modelo en espiral de un proyecto de software, mediante el Proyecto de
productividad TRW Software como un ejemplo; resumir las principales ventajas
e implicaciones involucradas en el uso del modelo en espiral y las dificultades
principales en usarlo en su nivel incompleto actual de elaboracin; y el
presente como resultado conclusiones.
Antecedentes sobre los modelos de procesos de software
Las funciones principales de un modelo de proceso de software son para
determinar el orden de las etapas implicadas en el desarrollo de software y la
evolucin y establecer los criterios de transicin para avanzar de una etapa a
la siguiente. Estos incluyen criterios de finalizacin para los criterios de la
etapa ms opcin actual y criterios de ingreso a la siguiente etapa. Por lo tanto,
un modelo de proceso aborda las siguientes preguntas de proyectos de
software:
(1) Qu vamos a hacer ahora? (2) Cunto tiempo vamos a seguir hacindolo?
En consecuencia, un modelo de proceso se diferencia de un mtodo de
software (a menudo llamado una metodologa) en que el objetivo principal de
un mtodo es sobre cmo navegar a travs de cada fase (la determinacin de
datos, control, o "utiliza" jerarquas; funciones de particin; requisitos
asignacin) y cmo que representa los productos de fase (diagramas de
estructura; hilos de estmulo-respuesta; diagramas de transicin de estado).
Por qu son importantes los modelos de procesos de software? Principalmente
debido a que proporcionan orientacin sobre el orden (fases, incrementos,
prototipos, tareas de validacin, etc.) en el que un proyecto debe llevar a cabo
sus tareas principales. Muchos proyectos de software, como en la siguiente
seccin, han llegado a la pena, ya que persiguen sus diferentes fases de
desarrollo y evolucin en el orden equivocado.

Evolucin de los modelos de procesos. Antes de concentrarse en profundidad

sobre el modelo espiral, debemos echar un vistazo a una serie de otros: el
modelo de cdigo-y-fix, el modelo por etapas y el modelo de cascada, el
modelo de desarrollo evolutivo, y el modelo de transformacin.
El modelo de cdigo-y-fix. El modelo bsico utilizado en los primeros das de
software
El modelo en espiral del proceso de software (ver Figura 2) ha ido
evolucionando desde hace varios aos, con base en la experiencia con varios
refinamientos del modelo de cascada que se aplican a grandes proyectos de
software de gobierno. Como se ver, el modelo espiral de casi todo tipo de
modelos anteriores como casos especiales y proporciona ms guidanceas a la
combinacin de los anteriores modelos mejor se adapte a una situacin de
software determinado. Desarrollo del Sistema de TRW Software Productividad
(TRW-SPS), que se describe en la siguiente seccin, es su aplicacin ms
completa hasta la fecha.
La dimensin radial en la Figura 2 representa el costo acumulado incurrido en
el cumplimiento de los pasos hasta la fecha; la cota angular representa el
progreso realizado en cada ciclo de la espiral. (El modelo refleja el concepto
subyacente de que cada ciclo consiste en una progresin que se dirige a la
misma secuencia de pasos, para cada porcin del producto y para cada uno de
sus niveles de elaboracin, a partir de un concepto general del documento
operacin hacia abajo para la codificacin de cada individuo programa.) Tenga
en cuenta que algunas licencias artsticas se ha tomado con la dimensin costo
acumulado cada vez mayor para mejorar la legibilidad de los pasos en la figura
2.
Un ciclo tpico de la espiral. Cada ciclo de la espiral comienza con la
identificacin de
los objetivos de la porcin del producto que se elaboran (rendimiento, la
funcionalidad, la capacidad de acomodar el cambio, etc.);
los medios alternativos de la aplicacin de esta parte del producto (diseo Un
diseo B, reutilizacin, comprar, etc.); y
las restricciones impuestas a la aplicacin de las alternativas (costo, horario,
interfaz, etc.). El siguiente paso es evaluar las alternativas en relacin con los
objetivos y limitaciones. Con frecuencia, este proceso identificar reas de
incertidumbre que son fuentes importantes de riesgo del proyecto. Si es as, el
siguiente paso debe involucrar a la formulacin de una estrategia rentable para
la resolucin de las fuentes de riesgo. Esto puede implicar la creacin de
prototipos, simulacin, la evaluacin comparativa, verificacin de referencias,
la administracin de cuestionarios de usuarios, el modelado analtico, o
combinaciones de estas y otras tcnicas de resolucin de riesgo.
Una vez que se evalan los riesgos, el siguiente paso se determina por los
riesgos restantes relativas. Si el rendimiento o la interfaz de usuario de los
riesgos de desarrollo del programa fuertemente dominan o los riesgos de

control de la interfaz interna, el siguiente paso puede ser un desarrollo

evolutivo una: un mnimo esfuerzo para especificar la naturaleza global del
producto, un plan para el siguiente nivel de creacin de prototipos, y el
desarrollo de un prototipo ms detallada contine para resolver los principales
problemas de riesgo. Si este prototipo es operativamente til y lo
suficientemente robusta como para servir como una base de bajo riesgo para
la futura evolucin del producto, las medidas impulsadas por riesgo posteriores
seran la serie evolutiva de prototipos evolutivos que van hacia la derecha en la
figura 2. En este caso, la opcin de escritura Especificaciones se abordaran,
pero no ejercidos. Por lo tanto, las consideraciones de riesgo pueden conducir a
un proyecto de implementacin de slo un subconjunto de todas las medidas
posibles en el modelo.
Por otro lado, si los esfuerzos de creacin de prototipos anteriores ya se han
resuelto todos los riesgos de rendimiento o de interfaz de usuario, y el
desarrollo de programas o de control de interfaz de riesgos dominar, el
siguiente paso sigue el enfoque bsico cascada (concepto de operacin,
requisitos de software, diseo preliminar, etc. en la figura 2), modificado segn
sea apropiado para incorporar desarrollo incremental. Cada nivel de
especificacin de software en la figura es seguido por una etapa de validacin
y la elaboracin de planes para el ciclo siguiente. En este caso, las opciones
para prototipo, simular, modelo, etc., estn dirigidas, pero no ejercido, lo que
lleva a la utilizacin de un subconjunto diferente de pasos. Este subconjunto
impulsado por riesgo de los pasos modelo espiral permite que el modelo para
dar cabida a cualquier mezcla apropiada de una especificacin orientada
prototipo orientado, en la simulacin orientado a la transformacin orientada
automtico, u otro enfoque para el desarrollo de software. En tales casos, la
estrategia mixta apropiada se elige teniendo en cuenta la magnitud relativa de
los riesgos del programa y la eficacia relativa de las diversas tcnicas en la
resolucin de los riesgos. De manera similar, las consideraciones de gestin de
riesgos pueden determinar la cantidad de tiempo y esfuerzo que debe
dedicarse a otras actividades del proyecto como la planificacin, gestin de la
configuracin, control de calidad, verificacin formal, y las pruebas. En
particular, las especificaciones impulsadas por riesgo (como se explica en la
siguiente seccin) pueden tener diversos grados de exhaustividad, la
formalidad, y granularidad, en funcin de los riesgos relativos de hacer muy
poco o demasiado especificacin. Una caracterstica importante del modelo de
espiral, como la mayora de los otros modelos, es que cada ciclo se completa
con un examen que involucra a la gente primarias u organizaciones
interesadas en el producto. Esta revisin se refiere a todos los productos
desarrollados durante el ciclo anterior, incluyendo los planes para el prximo
ciclo y los recursos necesarios para llevarlas a cabo. Principal objetivo de la
revisin es asegurar que todas las partes interesadas se comprometen
mutuamente con el enfoque para la siguiente fase.
Los planes para tener xito fases tambin pueden incluir una particin del
producto en incrementos para el desarrollo o componentes sucesivos a
desarrollar por las distintas organizaciones o personas. Para este ltimo caso,

visualizar una serie de ciclos en espiral en paralelo, uno para cada

componente, la adicin de una tercera dimensin al concepto presentado en la
Figura 2. Por ejemplo, espirales separadas se pueden evolucionando para los
componentes de software independientes o incrementos. Por lo tanto, el paso
de revisin y compromiso puede variar de un recorrido individual del diseo de
los componentes de un solo programador a una importante revisin exigencias
que implica desarrolladores, clientes, usuarios y organizaciones de
mantenimiento.
El inicio y terminacin de la espiral. Surgen cuatro preguntas fundamentales en
la consideracin de esta presentacin del modelo en espiral:
(1) De qu manera la espiral jams llegar
Comenzado? (2) Cmo se llega fuera de la espiral cuando es apropiado para
terminar un proyecto antes de tiempo? (3) Por qu el final de caracol tan
bruscamente? (4) Qu sucede con el software de mejorar
cin (o de mantenimiento)?
La respuesta a estas preguntas implica una observacin que el modelo en
espiral se aplica por igual a desarrollo o mejora de los esfuerzos. En cualquier
caso, la espiral se inicia por una hiptesis de que una misin operacional en
particular (o un conjunto de misiones) podra mejorarse mediante un esfuerzo
Software. El proceso en espiral implica entonces una prueba de esta hiptesis:
en cualquier momento, si la hiptesis no pasa la prueba (por ejemplo, si los
retrasos causan un producto de software que se pierda su ventana de mercado,
o si un producto comercial superiores est disponible), la espiral es terminado.
De lo contrario, se termina con la instalacin de software nuevo o modificado, y
la hiptesis se comprueba al observar el efecto sobre la misin operativa. Por
lo general, la experiencia con la misin operativa conduce a nuevas hiptesis
acerca de las mejoras de software y una nueva espiral de mantenimiento se
inicia para probar la hiptesis. Iniciacin, terminacin, y la iteracin de las
tareas y productos de ciclos anteriores As, se definen de manera implcita en
el modelo espiral (aunque no estn incluidas en la figura 2 para simplificar su
presentacin).
Usando el modelo en espiral
Las diversas rondas y actividades involucradas en el modelo espiral estn
mejor bajo de pie a travs del uso de un ejemplo. El modelo en espiral se utiliza
en la definicin y desarrollo del Sistema de TRW Software Productividad (TRWSPS), un entorno de ingeniera de software integrado. "La oportunidad inicial
misin coincidi con una iniciativa empresarial para mejorar la productividad
en todas las operaciones corporativas adecuadas y una hiptesis inicial que la
ingeniera de software era una zona atractiva para investigar. Esto llev a una
pequea "Ronda 0" extra circuito de la espiral para determinar la viabilidad de
aumentar la productividad del software a un costo empresarial razonable. (muy
grandes o complejos proyectos de software con frecuencia precedern al
"concepto de operacin" ronda de la espiral con una o ms pequeas rondas

para establecer la viabilidad y reducir la gama de alternativas de solucin

rpida y econmica.)
Tablas 1, 2 y 3 se resume la aplicacin del modelo en espiral a las tres primeras
rondas de la definicin de la MSF. Las principales caractersticas de cada ronda
son posteriormente
discutido y son seguidos por algunos ejemplos de las rondas posteriores, como
el diseo preliminar y detallado
Ronda de 0: Estudio de viabilidad. Este estudio involucr a cinco participantes a
tiempo parcial durante un perodo de dos a tres meses. Como se indica en la
Tabla 1, los objetivos y limitaciones se expresaron en un nivel muy alto y en
trminos cualitativos como "aumentar significativamente", "a un costo
razonable", etc.
Algunas de las alternativas consideradas, principalmente los de la zona
"tecnologa", podra conducir al desarrollo de un producto de software, pero el
posible atractivo de una serie de alternativas no-software en las reas de
gestin, el personal y las instalaciones podra haber dado lugar a una
conclusin no embarcarse en una actividad de desarrollo de software.
Las reas de riesgo primarios involucrados posibles situaciones en las que la
compaa invertira un buen negocio slo para encontrar que
resultantes aumentos de productividad no fueron significativas, o
potencialmente mejoras de gran influencia no eran compatibles con algunos
aspectos de la "cultura de TRW." Las actividades de resolucin de los riesgos
asumidos en la Ronda 0 fueron principalmente las encuestas y anlisis,
incluyendo entrevistas estructuradas de los desarrolladores de software y
administradores, un primer anlisis de los factores de apalancamiento de
productividad identificado por el modelo del costo constructivo (Cocomo) "; y
un anlisis de los proyectos anteriores en TRW exhibe altos niveles de
productividad.
Los resultados del anlisis de riesgo indicaron que significativos aumentos de la
productividad podran lograrse a un costo razonable mediante la aplicacin de
un conjunto integrado de iniciativas en las cuatro reas principales. Sin
embargo, algunas soluciones candidatas, como un entorno de soporte de
software basado en una sola, corporativo, sistema de tiempo compartido
basado en maxicomputer, se encontraron a estar en conflicto con las
limitaciones de TRW que requieren apoyo de los diferentes niveles de los
proyectos de seguridad-clasificado. Por lo tanto, incluso a un nivel muy alto de
generalidad de los objetivos y limitaciones, Ronda 0 fue capaz de responder a
las preguntas bsicas de viabilidad y eliminar clases significativas de
soluciones candidatas.
El plan para la Ronda 1 involucrada compromiso de 12 meses-hombre en
comparacin con los dos meses-hombre invertidas en Ronda 0 (durante estas
rondas, todos los participantes fueron a tiempo parcial). Ronda 1 aqu

corresponde bastante bien a la ronda inicial del modelo en espiral se muestra

en la Figura 2, en la que su intencin era producir un concepto de operacin y
un plan bsico del ciclo de vida de la aplicacin de lo que sea alternativa
preferida surgi.
Ronda 1: Concepto de operaciones. La Tabla 2 resume la Ronda 1 de la espiral
a lo largo de las lneas dadas en la Tabla 1 para la Ronda 0. Las caractersticas
de la Ronda 1 en comparacin con los de Ronda 0 de la siguiente manera:
Ronda 1: Concepto de operaciones. La Tabla 2 resume la Ronda 1 de la espiral
a lo largo de las lneas dadas en la Tabla 1 para la Ronda 0. Las caractersticas
de la Ronda 1 en comparacin con los de Ronda 0 de la siguiente manera:
El nivel de inversin fue mayor (12 frente a 2 meses-hombre).
Los objetivos y limitaciones eran ms especfico ("productividad doble de
software en cinco aos a un costo de $ 10.000 por persona" frente a "aumentar
significativamente la productividad a un costo razonable").
restricciones adicionales a la superficie, como la preferencia por los
productos de TRW (en particular, una red de rea local desarrollada TRW (LAN)
systern).
Las alternativas eran ms detallada ("SREM, PSL / PSA o TDAA, como
requisitos de herramientas, etc." frente a "herramientas"; "/ priwate
compartidos" terminales, terminales "inteligentes / mudos" versus "estaciones
de trabajo").
Las zonas de riesgo identificados fueron ms especficos ("TRW LAN preciorendimiento
Ronda 1: Concepto de operaciones. La Tabla 2 resume la Ronda 1 de la espiral
a lo largo de las lneas dadas en la Tabla 1 para la Ronda 0. Las caractersticas
de la Ronda 1 en comparacin con los de Ronda 0 de la siguiente manera:
El nivel de inversin fue mayor (12 frente a 2 meses-hombre).
Los objetivos y limitaciones eran ms especfico ("productividad doble de
software en cinco aos a un costo de $ 10.000 por persona" frente a "aumentar
significativamente la productividad a un costo razonable").
restricciones adicionales a la superficie, como la preferencia por los
productos de TRW (en particular, una red de rea local desarrollada TRW (LAN)
systern).
Las alternativas eran ms detallada ("SREM, PSL / PSA o TDAA, como
requisitos de herramientas, etc." frente a "herramientas"; terminales "privado /
compartido", terminales "inteligentes / mudos" versus "estaciones de trabajo").
Las zonas de riesgo identificados fueron ms especficos ("TRW LAN preciorendimiento dentro de una restriccin de inversin de $ 10.000 por persona
"frente a" las mejoras pueden

violar la restriccin razonable costo ").

La resolucin de riesgos actividades fueron ms extensas (incluyendo la
evaluacin comparativa y el anlisis de un prototipo TRW LAN est
desarrollando para otro proyecto).
El resultado fue un documento de concepto operacional bastante especfico,
que implica oficinas privadas adaptadas a los patrones de trabajo de software y
terminales personales conectados a superminis VAX travs de la LAN TRW.
Algunas elecciones se aplazaron especficamente a la siguiente ronda, como la
eleccin del sistema operativo y herramientas especficas.
El plan de ciclo de vida y el plan para la siguiente fase implicaron una
particin en actividades separadas para abordar mejoras en la gestin, el
desarrollo de las instalaciones, y el desarrollo del primer incremento de un
entorno de desarrollo de software.
El paso de compromiso que implica algo ms que un acuerdo con el plan. Se
ha comprometido a aplicar el ambiente para un prximo proyecto de software
banco de pruebas de 100 personas y desarrollar un entorno centrado en las
necesidades del proyecto banco de pruebas. Tambin especifica la formacin
de un grupo directivo representante para asegurar que las actividades
separadas eran bien coordinada y que el medio ambiente no sera
excesivamente optimizado en torno al proyecto banco de pruebas.
Aunque el plan recomienda el desarrollo de un entorno de prototipo, tambin
recomend que el proyecto emplean especificaciones de requisitos de diseo y
especificaciones de una manera impulsada por riesgo. As, el desarrollo del
medio ambiente sigui las rondas sucesivas del modelo en espiral.
Ronda 2: especificacin de requisitos de nivel superior. La Tabla 3 muestra los
pasos correspondientes que intervienen durante la Ronda 2 que definen el
sistema de productividad de software. Ronda 2 decisiones y su fundamento se
cubrieron en el trabajo anterior "; aqu, vamos a resumir las consideraciones
que se ocupan de la gestin de riesgos y el uso del modelo en espiral:
Las actividades iniciales de riesgos de identificacin durante la Ronda 2
mostraron que varios requisitos del sistema de bisagras en la decisin entre un
sistema host de destino o un conjunto de herramientas totalmente porttil y la
decisin entre VMS y Unix como sistema operativo anfitrin, Estos requisitos
incluyen las funciones necesarias para proporcionar un front-end fcil de usar,
el sistema operativo para ser utilizado por las estaciones de trabajo y las
funciones necesarias para apoyar una operacin de host de destino
Para mantener estos requisitos en sincronizacin con los dems, un minispiral
especial se inici para abordar y resolver estos problemas. La opinin
resultante condujo a un compromiso con una operacin de host de destino con
Unix en el sistema anfitrin, en un punto lo suficientemente temprano para
trabajar los requisitos del sistema operativo depende de manera oportuna.

 Abordar los riesgos de desajustes a las necesidades y prioridades del usuario

con el proyecto dio lugar a una importante participacin del personal del
usuario con el proyecto de la actividad de definicin de requisitos. Esto llev a
varias redirecciones significativos de los requisitos, en particular a apoyar las
primeras fases del ciclo de vida del software en el que el proyecto de usuario
se ha embarcado, como una adaptacin de la metodologa de los requisitos de
software de ingeniera (SREM) herramientas para la especificacin y anlisis de
requerimientos.
Tambin es interesante notar que la forma de los cuadros 1, 2 y 3 fue
desarrollado originalmente para fines de presentacin, pero posteriormente se
convirti en una "plantilla modelo en espiral" estndar utilizado en proyectos
posteriores. Estas plantillas son tiles no slo para la organizacin de las
actividades del proyecto, sino tambin como un registro de diseo-justificacin
residual. Diseo informacin justificacin es de suma importancia en la
evaluacin de la reutilizacin potencial de los componentes de software en
proyectos futuros. Otro punto importante a destacar es que el uso de la
plantilla era de hecho uniforme a travs de los tres ciclos, mostrando que los
pasos espirales pueden ser y fueron seguidos de manera uniforme en niveles
sucesivamente detalladas de definicin del producto,
Triunfar rondas. Ser til para ilustrar algunos ejemplos de cmo se usa el
modelo en espiral para manejar situaciones que surgen en el diseo preliminar
y el diseo detallado de los componentes de la MSF: la especificacin de diseo
preliminar para la herramienta requisitos de trazabilidad (RTT), y una
reanudacin diseo detallado o ir hacia atrs en la carpeta desarrollo unidad de
herramienta (UDF).
La especificacin de diseo preliminar RTT. El RTT establece la trazabilidad
entre especificaciones de requisitos de software detalladas, elementos de
diseo, elementos de cdigo, y los casos de prueba. Tambin es compatible
con diversas capacidades asociadas consulta, anlisis y generacin de
informes. La especificacin de diseo preliminar para la RTT (y la mayora de
las otras herramientas MSF) tiene un aspecto diferente de la especificacin de
diseo preliminar de costumbre, lo que tiende a mostrar un nivel uniforme de
elaboracin de todos los componentes del diseo. En su lugar, el nivel de
detalle de la especificacin RTT es impulsado por riesgo.
En las reas que implican un alto riesgo si el diseo result ser incorrecta, el
diseo se llev hasta el nivel de diseo detallado, por lo general con la ayuda
de prototipado rpido. Estas reas incluyen la elaboracin de las implicaciones
de las opciones de "deshacer" y hacer frente a los efectos de las teclas de
control se utilizan para escapar de los distintos niveles del programa.
En las reas que implican un riesgo moderado si el diseo era incorrecto, el
diseo se llev a un nivel preliminar de diseo. Estas reas incluyen las
opciones de comandos bsicos para la herramienta y los esquemas de la base
de datos los requisitos de trazabilidad. Una vez ms, la facilidad de creacin

rpida de prototipos con scripts de shell Unix soportado una buena parte de la
interfaz de usuario de prototipos
En las zonas con riesgo bajo si el diseo era malo, muy poca elaboracin
diseo fue hecho. Estas reas incluyen los detalles de todas las opciones de
mensaje de ayuda y todas las opciones de informe de generacin, una vez que
se estableci la naturaleza de estas opciones en algunos casos de ejemplo.
Un diseo detallado go-back. La herramienta UDF recoge en una "carpeta"
electrnica todos los artefactos involucrados en el desarrollo de una unidad de
software de un solo programador (tpicamente 500 a 1000 instrucciones):
requisitos de la unidad, diseo, cdigo, casos de prueba, resultados de las
pruebas, y documentacin. Tambin incluye una plantilla de gestin para el
seguimiento de finalizacin prevista y real del programador de cada artefacto.
Una alternativa en cuenta durante el diseo detallado de la herramienta UDF
fue reutilizacin de partes de la RTT para proporcionar punteros a los requisitos
y especificaciones de diseo preliminares de la unidad estn desarrollando.
Esto result ser una alternativa muy atractiva, no slo para evitar el desarrollo
de software duplicado, sino tambin para llevar a la superficie varios
problemas que involucran muchos-a-muchos asignaciones entre los requisitos,
diseo y cdigo que no haban sido considerados en el diseo de la
herramienta de UDF . Esto condujo a un replanteamiento de los requisitos de la
herramienta UDF y diseo preliminar, que evit una gran cantidad de cdigo de
retrabajo que habra sido necesario si el diseo detallado de la herramienta
UDF haba procedido en una, la moda de arriba abajo puramente deductivo de
la especificacin original requisitos UDF . El go-back resultante condujo a una
herramienta UDF significativamente diferente, menos costoso, y ms capaces,
incorporando el RTT en su "-jerarqua de usos."
Caractersticas modelo espiral. Estos dos ejemplos ilustran varias
caractersticas del enfoque espiral.
Fomenta el desarrollo de especificaciones que no son necesariamente
uniformes, exhaustiva, o formal, en cuanto a que aplazar la elaboracin
detallada de los elementos de software de bajo riesgo y evitar roturas
innecesarias en su diseo hasta que se estabilizan los elementos de alto riesgo
del diseo.
Incorpora prototipos como una opcin de reduccin de riesgos en cualquier
etapa de desarrollo. De hecho, los anlisis de prototipos y de riesgo
reutilizacin se utilizan a menudo en el proceso de pasar de diseo detallado
en cdigo.
Tiene capacidad para retrabajos o go-backs a etapas anteriores como
alternativas ms atractivas son identificados o como nuevos temas de riesgo
necesitan resolucin.
, Documentos impulsada por riesgo general, en particular las especificaciones y
planos, son caractersticas importantes del modelo de espiral. Grandes
cantidades de detalle no son necesarios a menos que la ausencia de tal detalle

pone en peligro el proyecto. En algunos casos, como con un producto cuya

funcionalidad puede ser determinado por una eleccin entre productos
comerciales, un conjunto de criterios de evaluacin ponderados para los
productos puede ser preferible a una pre-exposicin detallada de los requisitos
funcionales.
Documentos impulsada por riesgo general, en particular las especificaciones y
planos, son caractersticas importantes del modelo de espiral. Grandes
cantidades de detalle no son necesarias a menos que la ausencia de tal detalle
pone en peligro el proyecto. En algunos casos, como con un producto cuya
funcionalidad puede ser determinado por una eleccin entre productos
comerciales, un conjunto de criterios de evaluacin ponderados para los
productos puede ser preferible a una pre-exposicin detallada de los requisitos
funcionales.
Resultados. El Sistema de Productividad Software desarrollado y apoyado
mediante el modelo espiral evita los riesgos identificados y consigue la mayor
parte de los objetivos del sistema. El SPS ha crecido hasta incluir ms de 300
herramientas y ms de 1.300.000 instrucciones; 93 por ciento de las
instrucciones fueron reutilizados de paquetes desarrollado en proyectos, TRW
ha desarrollado, o software externo anteriores. Ms de 25 proyectos han
utilizado la totalidad o partes del sistema. Todos los proyectos que utilizan
plenamente el sistema han aumentado su productividad, al menos, el 50 por
ciento; de hecho, la mayora han duplicado su productividad (en comparacin
con el modelo de costo-estimacin de las predicciones de su productividad
utilizando mtodos tradicionales).
Sin embargo, un rea que el riesgo de los proyectos con sistemas de destino no
Unix no aceptara un host basado en Unix fue el sistema subestimada. Algunos
proyectos aceptaron el enfoque host de destino, pero por diversas razones
(tales como las limitaciones de los clientes y los equipos de destino de costo
cero) una buena parte no lo hicieron. Como resultado, el sistema fue menos
ampliamente utilizado en proyectos de TRW de lo esperado. Esto y otras
lecciones aprendidas se han incorporado en el enfoque de modelo en espiral al
desarrollo entorno de desarrollo de software de prxima generacin de TRW.
Evaluacin
Ventajas. La principal ventaja del modelo de espiral es que su gama de
opciones de capacidad para las buenas caractersticas de los modelos de
procesos de software existentes, mientras que su enfoque basado en el riesgoevita muchos de sus dificultades. En situaciones apropiadas, el modelo en
espiral se vuelve equivalente a uno de los modelos de proceso existentes. En
otras situaciones, se proporciona orientacin sobre la mejor combinacin de
enfoques para un determinado proyecto existente; por ejemplo, su aplicacin a
la TRW-MSF proporciona una mezcla impulsada por riesgo de especificar,
creacin de prototipos y desarrollo evolutivo.

Las condiciones primarias en las que el modelo en espiral se vuelve

equivalente a otros modelos principales del proceso se resumen de la siguiente
manera:
Si un proyecto tiene un bajo riesgo en reas tales como obtener la interfaz de
usuario incorrecto o que no cumplan con estrictos requisitos de rendimiento, y
si tiene un alto riesgo en el presupuesto y el calendario previsibilidad y control,
a continuacin, estas consideraciones de riesgo conducir el modelo en espiral
en una equivalencia para el modelo de cascada.
Si los requisitos de un producto de software son muy estables (lo que implica
un riesgo bajo de diseo y cdigo caro rotura debido a los requisitos de los
cambios durante el desarrollo), y si la presencia de errores en el producto de
software constituye un alto riesgo para la misin que sirve, entonces estos
consideraciones de riesgo en coche el modelo espiral para asemejarse al
modelo de dos partidos de la especificacin precisa y desarrollo formal del
programa deductivo.
Si un proyecto tiene un bajo riesgo en reas tales como la prdida de
presupuesto y el calendario previsibilidad y control, encontrndose con
problemas de integracin a gran sistema, o hacer frente a la esclerosis de la
informacin, y si tiene un alto riesgo en reas tales como conseguir la interfaz
de usuario incorrecto o requisitos de apoyo a las decisiones de los usuarios, a
continuacin, estas consideraciones de riesgo en coche el modelo espiral en
una equivalencia con el modelo de desarrollo evolutivo.
Si la capacidad de generacin de software automatizado estn disponibles,
entonces el modelo espiral de ellas tiene capacidad sea como opciones para la
creacin rpida de prototipos o para la aplicacin del modelo de
transformacin, en funcin de las consideraciones de riesgo implicados.
Si los elementos de alto riesgo de un proyecto involucran una combinacin
de los elementos de riesgo mencionados anteriormente, entonces el enfoque
espiral reflejar una combinacin adecuada de los modelos de procesos
anteriores (como se ejemplifica en la aplicacin TRW-SPS). Al hacerlo, sus
caractersticas de evitacin de riesgos por lo general evitar las dificultades de
los otros modelos.
El modelo en espiral tiene una serie de ventajas adicionales, que se resumen
de la siguiente manera: Se centra la atencin temprana de las opciones que
implican la reutilizacin de software existente. Los pasos que implican la
identificacin y evaluacin de alternativas alientan estas opciones.
Tiene capacidad de preparacin para la evolucin del ciclo de vida, el
crecimiento, y cambios en el producto de software.
Las principales fuentes de cambio de producto se incluyen en los objetivos del
producto, y de la informacin que oculta enfoques son atractivas alternativas
de diseo arquitectnico en que reducen el riesgo de no ser capaz de
adaptarse a los objetivos producto de carga.

Proporciona un mecanismo para la incorporacin de los objetivos de calidad de

software en el desarrollo de productos de software. Este mecanismo se deriva
del nfasis en la identificacin de todos los tipos de objetivos y limitaciones en
cada ronda de la espiral. Por ejemplo, la Tabla 3 muestra la facilidad de uso,
portabilidad y fiabilidad que los objetivos y limitaciones especficas que se
abordarn en el SPS. En la Tabla 1, las restricciones de seguridad fueron
identificados como un elemento de riesgo clave para el SPS.
Se centra en la eliminacin de errores y alternativas poco atractivas temprano.
El anlisis de riesgos, medidas de validacin y de compromiso cubren estas
consideraciones.
Para cada una de las fuentes de la actividad del proyecto y el gasto de
recursos, responde a la pregunta clave: "Cunto es suficiente?" Dicho de otra
manera, "Cunto de anlisis de requerimientos, planificacin, gestin de la
configuracin, control de calidad, pruebas, verificacin formal, etc. . debe hacer
un proyecto? "Uso del enfoque basado en el riesgo, se puede ver que la
respuesta no es la misma para todos los proyectos y que el nivel apropiado de
esfuerzo est determinado por el nivel de riesgo asumido por no hacer lo
suficiente.
No se trata de enfoques diferentes para el desarrollo de software y mejora de
software (o de mantenimiento). Este aspecto ayuda a evitar el "ciudadano de
segunda clase '' estado frecuentemente asociado con el mantenimiento del
software. Tambin ayuda a evitar muchos de los problemas que se derivan
actualmente cuando los esfuerzos de mejora de alto riesgo se abordan en la
misma forma que los esfuerzos de mantenimiento de rutina.
Proporciona un marco viable para el desarrollo integrado de sistema de
hardware-software. El enfoque en la gestin de riesgos y en la eliminacin de
las alternativas poco atractivas temprana y econmica es igualmente aplicable
a hardware y software.
Las dificultades. El modelo en espiral completa se puede aplicar con xito en
muchas situaciones, pero algunas dificultades debe abordarse antes de que
pueda ser llamado un modelo de madurez, de aplicacin universal. Los tres
principales desafos implican a juego para contratar software, basndose en la
experiencia de evaluacin de riesgos, y la necesidad de una mayor elaboracin
de medidas modelo en espiral.
Coincidencia de contratar software. El modelo en espiral actualmente funciona
bien en desarrollos de software internos como el TRW-SPS, pero es necesario
seguir trabajando para hacerlo coincidir con el mundo de la adquisicin de
software contrato.
Desarrollos de software internas tienen un alto grado de flexibilidad y libertad
para dar cabida a los compromisos etapa por etapa, aplazar compromisos de
opciones especficas, establecer minispirals resolver artculos de trayectoria
crtica, para ajustar los niveles de esfuerzo, o para dar cabida a prcticas tales
como la creacin de prototipos , desarrollo evolutivo, o de diseo a costos. El

mundo de la adquisicin de software contrato tiene ms dificultades para el

logro de estos grados de flexibilidad y libertad sin perder la rendicin de
cuentas y el control, y un tiempo ms difcil definir contratos cuyas
prestaciones no estn bien especificados de antemano.
Recientemente, una buena parte de los avances se han logrado en el
establecimiento de mecanismos de contratacin ms flexibles, tales como el
uso de contratos de front-end de la competencia para la definicin de concepto
o prototipo mosca-offs, el uso de contratos del grado de esfuerzo y premio
honorario para desarrollo evolutivo, y el uso de los contratos de diseo-a costo.
Aunque stas han sido en general exitosa, las modalidades de su utilizacin
an deben ser resueltos hasta el punto de que los gestores de adquisicin se
sienten totalmente cmodos con ellos.
Basndose en la experiencia de evaluacin de riesgos. El modelo en espiral
pone una gran cantidad de confianza en la capacidad de los desarrolladores de
software para identificar y gestionar las fuentes de riesgo del proyecto,
Un buen ejemplo de esto es la especificacin impulsada por riesgo del modelo
en espiral, que lleva elementos de alto riesgo a una gran cantidad de detalles y
deja elementos de bajo riesgo que se elaboran en las etapas posteriores; Por
este tiempo, hay menos riesgo de rotura.
Sin embargo, un equipo de desarrolladores sin experiencia o con poca Balling
tambin puede producir una especificacin con un patrn diferente de la
variacin en los niveles de detalle: una gran elaboracin de los detalles de los
elementos bien entendido, de bajo riesgo, y poca elaboracin del mal
entendido , elementos de alto riesgo, A menos que haya una revisin detallada
de una especificacin tal por el desarrollo o adquisicin de personal con
experiencia, este tipo de proyectos se dan una ilusin de progreso durante un
perodo en el que se diriga en realidad para el desastre.
Otra preocupacin es que una especificacin impulsado riesgo tambin ser
dependiente de las personas. Por ejemplo, un diseo elaborado por un experto
puede ser implementada por los no expertos. En este caso, el experto, que no
necesita una gran cantidad de documentacin detallada, debe producir
suficiente documentacin adicional para mantener a los no expertos de ir por
mal camino. Los revisores de la especificacin tambin deben ser sensibles a
estas preocupaciones.
Con un enfoque documento impulsado convencional, la obligacin de llevar a
todos los aspectos de la especificacin de un nivel uniforme de detalle elimina
algunos problemas potenciales y permite una adecuada revisin de algunos
aspectos de los colaboradores sin experiencia. Pero tambin crea una gran
carga para la poca de los expertos escasos, que deben excavar en busca de
los temas crticos dentro de una gran masa de detalles no crtica. Adems, si
los elementos de alto riesgo han sido pasados por altos por suenan
impresionante referencia a las capacidades de mal entendidos (tales como un
nuevo concepto de sincronizacin o un DBMS comercial), existe un riesgo an

mayor que el enfoque convencional dar la ilusin de progreso en situaciones

que son en realidad dirigen para el desastre
la necesidad de una mayor elaboracin de medidas modelo en espiral. en
general, las etapas del procedimiento modelo en espiral necesitan una mayor
elaboracin para garantizar que todos los participantes de desarrollo de
software estn operando en un contexto coherente.
Algunos ejemplos de esto son necesidad che para la definicin ms detallada
de la naturaleza de las especificaciones espiral modelo y los hitos, la
naturaleza y los objetivos de las revisiones modelo espiral, las tcnicas para la
estimacin y la sincronizacin de los horarios y procedimientos de costos
versus seguimiento de los progresos. Otra necesidad es de directrices y listas
de control para identificar la fuente ms probable de los riesgos del proyecto y
de las tcnicas ms eficaces de resolucin de riesgo para cada fuente de riesgo
Las personas altamente experimentadas pueden utilizar con xito el enfoque
espiral sin estas elaboraciones. Sin embargo, para su uso a gran escala en
situaciones en las que las personas traen bases de experiencia muy diferentes
al proyecto, aaden niveles de elaboracin, como se han acumulado a lo largo
de los aos para los enfoques basados en documentos son importantes para
garantizar una interpretacin coherente y el uso del enfoque en espiral a travs
del proyecto.
Implicaciones: El Plan de Gestin de Riesgos
Incluso si una organizacin no est preparada para adoptar todo el enfoque
espiral, una tcnica caracterstica que puede ser fcilmente adaptado a
cualquier modelo de ciclo de vida proporciona muchos de los beneficios del
enfoque espiral. Este es el Plan de Gestin de Riesgos se resume en la tabla 5.
Este plan bsicamente garantiza que cada proyecto hace una identificacin
temprana de sus principales elementos de riesgo (el nmero 10 no es un
requisito absoluto), se desarrolla una estrategia para resolver los riesgos
artculos, identifica y conjuntos por una agenda para resolver nuevos
elementos de riesgo, ya que la superficie, y pone de relieve el progreso frente
a los planes de las revisiones mensuales
El Plan de Gestin de Riesgos ha sido utilizado con xito en TRW y otras
organizaciones. Su uso se ha asegurado de enfoque apropiado en prototipado
temprano, la simulacin, el benchmarking, las medidas de personal clavepersona, y otras tcnicas de resolucin temprana de riesgos que han ayudado
a evitar muchos posibles proyectos "show-stoppers"
la reciente Departamento de Estndar de defensa en la gestin de software de
Estados Unidos, el Departamento de Defensa-Std-2167, requiere que los
desarrolladores producen y planes de gestin de uso de riesgo, al igual que su
homlogo de la regulacin de la Fuerza Area de Estados Unidos, AFR 800-14
En general, el plan de gestin de riesgos y el conjunto de maduracin de las
tcnicas de gestin del riesgo de software proporcionan una base para la

adaptacin de los conceptos de modelo de espiral en la adquisicin de software

ms establecida y los procedimientos de desarrollo
Podemos extraer cuatro conclusiones a partir de los datos presentados
la naturaleza impulsada por riesgo de la modelo en espiral es ms adaptable a
toda la gama de situaciones de proyecto de software que son los enfoques
principalmente basados en documentos tales como el modelo de cascada o los
enfoques principalmente basados en cdigos de como el desarrollo evolutivo.
es particularmente aplicable a complejo muy grande sistema de software,
ambicioso
el modelo espiral ha tenido bastante xito en su aplicacin ms grande hasta la
fecha la TRW-SPS. En general, se logra un alto nivel de capacidad de medio de
soporte de software en un tiempo muy corto y proporciona la flexibilidad
necesaria para adaptarse a un alto rango dinmico de alternativas tcnicas y
objetivos de usuario
el modelo espiral no es todava tan plenamente elaborado como los modelos
ms establecidos. Por lo tanto, el modelo de espiral puede ser aplicado por
personal experimentado, pero se necesita una mayor elaboracin en reas
como la contratacin, las especificaciones, los hitos. opinin, la programacin,
la monitorizacin del estado y la identificacin de la zona de riesgo a ser
plenamente utilizable en todas las situaciones.
Implementaciones parciales del modelo en espiral, como el plan de gestin de
riesgos, son compatibles con los modelos de procesos ms actuales y son muy
tiles en la superacin de las principales fuentes de riesgo del proyecto