Modelo espiral[editar]

El modelo espiral fue propuesto inicialmente por Barry Boehm. 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.1318
El modelo se divide en un número de Actividades de marco de trabajo, llamadas «regiones de
tareas». En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En
la figura 6 se muestra el esquema de un modelo espiral con seis regiones. En este caso se
explica una variante del modelo original de Boehm, expuesto en su tratado de 1988; en 1998
expuso un tratado más reciente.

Figura 6: 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 6) 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;19 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.
Desventajas importantes:

 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.
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.
Modelo espiral Win & Win[editar]
Una variante interesante del Modelo Espiral previamente visto (Figura 6) es el «Modelo espiral
Win-Win»14 (Barry Boehm). El Modelo Espiral previo (clásico) sugiere la comunicación con el
cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él
proporciona la información para continuar; pero esto es en un contexto ideal que rara vez
ocurre. Normalmente cliente y desarrollador entran en una negociación, se negocia coste
frente a funcionalidad, rendimiento, calidad, etc.
«Es así que la obtención de requisitos requiere una negociación, que tiene éxito cuando
ambas partes ganan».
Las mejores negociaciones se fuerzan en obtener «Victoria & Victoria» (Win & Win), es decir
que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane
consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere
fuertes habilidades de negociación.
El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso
alrededor de la espiral; se definen las siguientes actividades:

1. Identificación del sistema o subsistemas clave de los directivos * (saber qué quieren).
2. Determinación de «condiciones de victoria» de los directivos (saber qué necesitan y
los satisface)
3. Negociación de las condiciones «victoria» de los directivos para obtener condiciones
«Victoria & Victoria» (negociar para que ambos ganen).
* Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por la
organización si tiene éxito o criticado si no.
El modelo Win & Win hace énfasis en la negociación inicial, también introduce 3 hitos en el
proceso llamados «puntos de fijación», que ayudan a establecer la completitud de un ciclo de
la espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo
del software.

Etapas en el desarrollo del software[editar]

Captura, análisis y especificación de requisitos[editar]
Al inicio de un desarrollo (no de un proyecto), esta es la primera fase que se realiza, y, según
el modelo de proceso adoptado, puede casi terminar para pasar a la próxima etapa (caso de
Modelo Cascada Realimentado) o puede hacerse parcialmente para luego retomarla (caso
Modelo Iterativo Incremental u otros de carácter evolutivo).
En simple palabras y básicamente, durante esta fase, se adquieren, reúnen y especifican las
características funcionales y no funcionales que deberá cumplir el futuro programa o sistema a
desarrollar.
Las bondades de las características, tanto del sistema o programa a desarrollar, como de su
entorno, parámetros no funcionales y arquitectura dependen enormemente de lo bien lograda
que esté esta etapa. Esta es, probablemente, la de mayor importancia y una de las fases más
difíciles de lograr certeramente, pues no es automatizable, no es muy técnica y depende en
gran medida de la habilidad y experiencia del analista que la realice.
Involucra fuertemente al usuario o cliente del sistema, por tanto tiene matices muy subjetivos y
es difícil de modelar con certeza o aplicar una técnica que sea «la más cercana a la
adecuada» (de hecho no existe «la estrictamente adecuada»). Si bien se han ideado varias
metodologías, incluso software de apoyo, para captura, elicitación y registro de requisitos, no
existe una forma infalible o absolutamente confiable, y deben aplicarse conjuntamente buenos
criterios y mucho sentido común por parte del o los analistas encargados de la tarea; es
fundamental también lograr una fluida y adecuada comunicación y comprensión con el usuario
final o cliente del sistema.
El artefacto más importante resultado de la culminación de esta etapa es lo que se conoce
como especificación de requisitos software o simplemente documento ERS.
Como se dijo, la habilidad del analista para interactuar con el cliente es fundamental; lo común
es que el cliente tenga un objetivo general o problema que resolver, no conoce en absoluto el
área (informática), ni su jerga, ni siquiera sabe con precisión qué debería hacer el
producto software (qué y cuantas funciones) ni, mucho menos, cómo debe operar. En otros
casos menos frecuentes, el cliente «piensa» que sabe precisamente lo que el software tiene
que hacer, y generalmente acierta muy parcialmente, pero su empecinamiento entorpece la
tarea de elicitación. El analista debe tener la capacidad para lidiar con este tipo de problemas,
que incluyen relaciones humanas; tiene que saber ponerse al nivel del usuario para permitir
una adecuada comunicación y comprensión.20
Escasas son las situaciones en que el cliente sabe con certeza e incluso con completitud lo
que requiere de su futuro sistema, este es el caso más sencillo para el analista.
Las tareas relativas a captura, elicitación, modelado y registro de requisitos, además de ser
sumamente importante, puede llegar a ser dificultosa de lograr acertadamente y llevar
bastante tiempo relativo al proceso total del desarrollo; al proceso y metodologías para llevar a
cabo este conjunto de actividades normalmente se las asume parte propia de la ingeniería
de software, pero dada la antedicha complejidad, actualmente se habla de una ingeniería de
requisitos,21 aunque ella aún no existe formalmente.
Hay grupos de estudio e investigación, en todo el mundo, que están exclusivamente abocados
a idear modelos, técnicas y procesos para intentar lograr la correcta captura, análisis y registro
de requisitos. Estos grupos son los que normalmente hablan de la ingeniería de requisitos; es
decir se plantea esta como un área o disciplina pero no como una carrera universitaria en sí
misma.
Algunos requisitos no necesitan la presencia del cliente, para ser capturados o analizados; en
ciertos casos los puede proponer el mismo analista o, incluso, adoptar unilateralmente
decisiones que considera adecuadas (tanto en requisitos funcionales como no funcionales).
Por citar ejemplos probables: Algunos requisitos sobre la arquitectura del sistema, requisitos
no funcionales tales como los relativos al rendimiento, nivel de soporte a errores operativos,
plataformas de desarrollo, relaciones internas o ligas entre la información (entre registros o
tablas de datos) a almacenar en caso de bases o bancos de datos, etc. Algunos funcionales
tales como opciones secundarias o de soporte necesarias para una mejor o más sencilla
operatividad; etc.
La obtención de especificaciones a partir del cliente (u otros actores intervinientes) es un
proceso humano muy interactivo e iterativo; normalmente a medida que se captura la
información, se la analiza y realimenta con el cliente, refinándola, puliéndola y corrigiendo si
es necesario; cualquiera sea el método de ERS utilizado. EL analista siempre debe llegar a
conocer la temática y el problema que resolver, dominarlo, hasta cierto punto, hasta el ámbito
que el futuro sistema a desarrollar lo abarque. Por ello el analista debe tener alta capacidad
para comprender problemas de muy diversas áreas o disciplinas de trabajo (que no son
específicamente suyas); así por ejemplo, si el sistema a desarrollar será para gestionar
información de una aseguradora y sus sucursales remotas, el analista se debe compenetrar
en cómo ella trabaja y maneja su información, desde niveles muy bajos e incluso llegando
hasta los gerenciales. Dada a gran diversidad de campos a cubrir, los analistas suelen ser
asistidos por especialistas, es decir gente que conoce profundamente el área para la cual se
desarrollará el software; evidentemente una única persona (el analista) no puede abarcar tan
vasta cantidad de áreas del conocimiento. En empresas grandes de desarrollo de
productos software, es común tener analistas especializados en ciertas áreas de trabajo.
Contrariamente, no es problema del cliente, es decir él no tiene por qué saber nada
de software, ni de diseños, ni otras cosas relacionadas; solo se debe limitar a aportar
objetivos, datos e información (de mano propia o de sus registros, equipos, empleados, etc) al
analista, y guiado por él, para que, en primera instancia, defina el «Universo de Discurso», y
con posterior trabajo logre confeccionar el adecuado documento ERS.
Es bien conocida la presión que sufren los desarrolladores de sistemas informáticos para
comprender y rescatar las necesidades de los clientes/usuarios. Cuanto más complejo es el
contexto del problema más difícil es lograrlo, a veces se fuerza a los desarrolladores a tener
que convertirse en casi expertos de los dominios que analizan.
Cuando esto no sucede es muy probable que se genere un conjunto de requisitos 22 erróneos o
incompletos y por lo tanto un producto de software con alto grado de desaprobación por parte
de los clientes/usuarios y un altísimo costo de reingeniería y mantenimiento. Todo aquello que
no se detecte, o resulte mal entendido en la etapa inicial provocará un fuerte impacto negativo
en los requisitos, propagando esta corriente degradante a lo largo de todo el proceso de
desarrollo e incrementando su perjuicio cuanto más tardía sea su detección (Bell y
Thayer 1976)(Davis 1993).