El modelo en espiral en el desarrollo de software es la respuesta que Barry Boehm dio en la década de 1980 a un problema que todavía hunde proyectos en 2026: los equipos comprometen todo su presupuesto con un plan antes de saber qué partes de ese plan son erróneas. En lugar de avanzar por fases fijas, un proyecto en espiral recorre una y otra vez las mismas cuatro actividades y, en cada ciclo, dedica el esfuerzo a lo que tiene más probabilidades de hacer fracasar el proyecto.
Por eso el modelo en espiral encaja de forma natural en el tipo de trabajo en el que una suposición inicial errónea sale cara: sustitución de sistemas de core banking, sistemas clínicos, plataformas logísticas, software aeroespacial y de defensa, y otras formas de desarrollo de software empresarial a medida en las que un riesgo de integración, rendimiento o regulación puede echar por tierra un año de trabajo. También es el modelo que más a menudo se malinterpreta, porque su famoso diagrama parece un proceso que seguir y no una forma de decidir qué hacer a continuación.
Esta guía explica el modelo en espiral con claridad: de dónde viene, cómo leer el diagrama, qué ocurre en cada cuadrante, los hitos que impiden que la espiral gire sin fin, un ejemplo completo, sus ventajas y desventajas reales y cómo se compara con el modelo en cascada, el modelo en V y el desarrollo ágil. La última sección muestra cómo aplicamos la lógica de la espiral en proyectos actuales sin su histórica carga documental.
¿Qué es el modelo en espiral en el desarrollo de software?
El modelo en espiral en el desarrollo de software es un modelo de ciclo de vida iterativo y guiado por el riesgo en el que un proyecto recorre repetidamente cuatro actividades — fijar objetivos, resolver riesgos, construir y probar, planificar el ciclo siguiente — y cada ciclo produce una versión más completa del sistema. La idea clave es que el riesgo, y no una secuencia predefinida, decide cuánto hacer de cada actividad y cuándo.
Cada vuelta de la espiral se denomina ciclo, bucle o iteración. Los primeros ciclos son pequeños y baratos: un concepto de operaciones, un estudio de viabilidad, un prototipo desechable. Los ciclos posteriores son mayores y se parecen más al desarrollo y la implantación convencionales. La distancia al centro de la espiral representa el coste acumulado, de modo que el modelo deja claro que cada ciclo adicional consume dinero y debe justificar su lugar.
De dónde viene el modelo en espiral
Barry Boehm, entonces en TRW, describió el modelo por primera vez en el artículo de 1986 A Spiral Model of Software Development and Enhancement y publicó la versión más conocida en IEEE Computer en mayo de 1988. Su ejemplo fue el TRW Software Productivity System, un programa interno de herramientas cuyos requisitos eran demasiado inciertos para una única pasada en cascada. Más tarde, Boehm formalizó el modelo en un informe de 2000 para el Software Engineering Institute de Carnegie Mellon y, en 2014, fue coautor del Incremental Commitment Spiral Model, la evolución moderna de la idea.
La espiral también influyó en la contratación pública. En 2000, el Departamento de Defensa de EE. UU. adoptó la adquisición evolutiva con desarrollo en espiral como enfoque preferente para los grandes sistemas, y Boehm redactó orientaciones para ese uso. Esa herencia explica por qué el modelo sigue siendo habitual en el sector aeroespacial, la defensa, la Administración pública y otros programas de alto riesgo.
Por qué el modelo en espiral se considera un metamodelo
El modelo en espiral se considera un metamodelo porque puede contener los demás modelos de proceso en lugar de sustituirlos. Si el riesgo principal de un ciclo son unas necesidades de usuario poco claras, ese ciclo se comporta como un prototipado evolutivo. Si los requisitos y la tecnología se conocen bien, un ciclo puede ejecutarse como una cascada corta. Si el riesgo es una integración tardía, el ciclo puede entregar un incremento. La espiral es el marco de decisión; el modelo que se usa dentro de cada ciclo se elige según el riesgo.
¿Cómo se lee el diagrama del modelo en espiral?
El diagrama del modelo en espiral se lee del centro hacia fuera: la espiral parte del origen, atraviesa cuatro cuadrantes en cada ciclo y cada ciclo completado termina con una revisión y un compromiso con el siguiente. El radio muestra el coste acumulado; el ángulo, el avance dentro del ciclo en curso.
La mayoría de los diagramas en internet omiten los elementos que hacen útil la espiral, así que conviene saber qué significa cada elemento visual:
| Elemento del diagrama | Qué significa | Implicación práctica |
|---|---|---|
| Distancia radial desde el centro | Coste acumulado hasta el momento | Los ciclos exteriores son caros; el aprendizaje arriesgado debe hacerse en los ciclos interiores |
| Posición angular | Avance dentro del ciclo en curso | Cada ciclo debe pasar por los cuatro cuadrantes, aunque sea brevemente |
| Cruce del eje horizontal | Punto de revisión y compromiso | Las partes interesadas deciden continuar, cambiar de rumbo o detenerse |
| Prototipos en el cuadrante 2 | Artefactos de reducción de riesgos | Se construyen para responder a una pregunta, no para entregarse |
| Ciclo más exterior | Diseño detallado, codificación, pruebas, implantación | Se parece a la entrega convencional una vez eliminados los riesgos |
¿Cuáles son las cuatro fases del modelo en espiral?
Las cuatro fases del modelo en espiral son: determinar objetivos, alternativas y restricciones; identificar y resolver riesgos; desarrollar y probar el producto del nivel siguiente; y planificar la siguiente iteración. Cada ciclo pasa por las cuatro, pero el tiempo dedicado a cada una depende de los riesgos de ese ciclo.
1. Determinar objetivos, alternativas y restricciones
El primer cuadrante define qué debe lograr el ciclo y qué vías para lograrlo están sobre la mesa. El equipo registra los objetivos de la parte del producto en alcance (rendimiento, funcionalidad, adaptabilidad), los diseños alternativos u opciones de desarrollar o comprar, y las restricciones como presupuesto, calendario, regulación e interfaces con los sistemas existentes. Unos objetivos claros son lo que hace concreto el análisis de riesgos del cuadrante siguiente.
2. Identificar y resolver riesgos
El segundo cuadrante es el corazón de la espiral: el equipo evalúa las alternativas frente a los objetivos, identifica las mayores fuentes de riesgo y dedica el esfuerzo justo para reducirlas. Las técnicas habituales son prototipos desechables, benchmarks, simulaciones, entrevistas con usuarios, comprobación de referencias de proveedores y modelos analíticos. El resultado es una decisión: qué alternativa seguir y qué riesgos quedan abiertos.
3. Desarrollar y probar el producto del nivel siguiente
El tercer cuadrante construye la siguiente versión del producto con el enfoque de desarrollo que mejor se ajuste al riesgo restante. En los primeros ciclos puede ser una especificación o una arquitectura; en los posteriores, código funcional, integrado y probado. Como las grandes incógnitas se trataron en el cuadrante 2, este trabajo se apoya en supuestos validados y no en conjeturas.
4. Revisar y planificar la siguiente iteración
El cuarto cuadrante cierra el ciclo con una revisión de los resultados por parte de quienes controlan el presupuesto y los requisitos, seguida de un plan para el ciclo siguiente. La revisión es un verdadero punto de compromiso: las partes interesadas pueden continuar según lo previsto, cambiar los objetivos o detener el proyecto mientras el coste acumulado sigue siendo bajo. Detenerse pronto es un resultado legítimo y, a menudo, valioso.
| Cuadrante | Pregunta clave | Entradas habituales | Resultados habituales |
|---|---|---|---|
| 1. Objetivos | ¿Qué debe lograr este ciclo? | Objetivos de negocio, necesidades de las partes interesadas, revisión del ciclo anterior | Objetivos, alternativas, restricciones |
| 2. Análisis de riesgos | ¿Qué podría hacernos fracasar? | Alternativas, restricciones, registro de riesgos | Prototipos, benchmarks, enfoque elegido |
| 3. Ingeniería | ¿Podemos construirlo? | Enfoque elegido, supuestos validados | Especificación, diseño, código, resultados de las pruebas |
| 4. Evaluación | ¿Debemos continuar? | Resultados, estimaciones actualizadas, opiniones de las partes interesadas | Decisión de seguir o no seguir (go/no-go), plan del ciclo siguiente |
¿Por qué el análisis de riesgos está en el centro de la espiral?
El análisis de riesgos está en el centro de la espiral porque el modelo usa el riesgo para decidir cuánto hacer de cada actividad: si hacer más de algo reduce la probabilidad de fracaso, hágalo; si no, deténgase. Boehm lo planteaba como la respuesta a la pregunta «¿cuánto es suficiente?» para el prototipado, la documentación, las pruebas y la planificación.
En la práctica, eso supone mantener un registro de riesgos vivo y revisarlo al principio y al final de cada ciclo. El registro siguiente muestra el tipo de riesgos que sigue un proyecto empresarial en espiral típico y la técnica con la que se elimina cada uno:
| Riesgo | Probabilidad | Impacto | Técnica de resolución | Eliminado en el ciclo |
|---|---|---|---|---|
| Los usuarios rechazan el nuevo flujo de trabajo | Medium | Alto | Prototipo navegable probado con 8–10 usuarios | 1 |
| La API del ERP heredado no soporta el volumen en picos | Alto | Alto | Prueba de carga contra una copia de staging | 2 |
| Un proveedor externo incumple las fechas de entrega | Medium | Medium | Comprobación de referencias, hitos contractuales, opción alternativa | 2 |
| Una auditoría regulatoria detecta lagunas de trazabilidad | Bajo | Alto | Matriz de trazabilidad revisada por el área de cumplimiento | 3 |
| Un ingeniero clave abandona el proyecto a mitad | Medium | Medium | Trabajo en pareja, documentación, intercambio de conocimiento | Continuo |
Dos hábitos hacen eficaz el trabajo guiado por el riesgo. Primero, valore cada riesgo por probabilidad e impacto para que el equipo dedique esfuerzo donde la pérdida esperada es mayor. Segundo, haga que cada prototipo responda a una pregunta de riesgo concreta con un criterio de aprobado o suspenso; un prototipo sin pregunta no es más que desarrollo prematuro. Nuestra guía sobre la prueba de concepto en el desarrollo de software explica cómo diseñar esos experimentos.
¿Cuáles son los hitos de anclaje y las invariantes del modelo en espiral?
Los hitos de anclaje son tres puntos de control — Life Cycle Objectives (LCO), Life Cycle Architecture (LCA) e Initial Operational Capability (IOC) — que Boehm añadió para que los proyectos en espiral avancen hacia un sistema terminado en lugar de girar indefinidamente. Son la parte del modelo que omiten la mayoría de los resúmenes y la que lo hace gobernable.
- Life Cycle Objectives (LCO) — las partes interesadas acuerdan qué debe lograr el sistema y que existe al menos una arquitectura viable.
- Life Cycle Architecture (LCA) — la arquitectura está elegida, sus riesgos principales están resueltos y el plan para construirla es creíble.
- Initial Operational Capability (IOC) — la primera versión operativa está lista, con los usuarios formados y el entorno preparado.
En el informe de 2000 Spiral Development: Experience, Principles, and Refinements, publicado por el Software Engineering Institute de Carnegie Mellon, Boehm enumeró además seis «invariantes» que presenta todo proyecto en espiral real. Un proceso que las omite no es una espiral, aunque dibuje una:
- Los artefactos clave — concepto operativo, requisitos, planes, diseño y código — se definen de forma concurrente, no uno tras otro.
- Cada ciclo abarca objetivos, restricciones, alternativas, riesgos, revisión y compromiso para continuar.
- El nivel de esfuerzo de cada actividad lo determina el riesgo.
- El grado de detalle de cada artefacto lo determina el riesgo.
- El proyecto utiliza los tres hitos de anclaje (LCO, LCA, IOC).
- El proyecto pone el foco en el sistema completo y en su ciclo de vida, no solo en el desarrollo inicial del software.
Ejemplo del modelo en espiral: ¿cómo es un proyecto de cuatro ciclos?
Un ejemplo del modelo en espiral hace concretos los cuadrantes abstractos. Imagine una red hospitalaria regional que sustituye su software de dispensación de medicamentos, que debe integrarse con la historia clínica electrónica existente, funcionar en armarios de dispensación automatizados y superar una revisión regulatoria. Los riesgos principales son la usabilidad clínica, la integración con la historia clínica electrónica (EHR) y la auditabilidad.
| Ciclo | Objetivo | Riesgo principal abordado | Trabajo de reducción del riesgo | Resultado |
|---|---|---|---|---|
| 1 (4 semanas) | Confirmar el concepto con enfermeros y farmacéuticos | El personal clínico rechaza el flujo de trabajo | Prototipos en papel y navegables, observación en planta | LCO alcanzado; alcance reducido un 20% |
| 2 (6 semanas) | Demostrar la arquitectura de integración | La interfaz de la EHR no cumple los tiempos de respuesta | Spike de HL7/FHIR, prueba de carga en una EHR de staging | LCA alcanzado; se añade un message broker |
| 3 (12 semanas) | Construir los módulos principales de dispensación y auditoría | Lagunas de trazabilidad ante el regulador | Matriz de trazabilidad, revisión independiente de las pruebas | Versión lista para el piloto en una planta |
| 4 (10 semanas) | Piloto y despliegue en el primer hospital | Interrupción operativa en la puesta en marcha | Funcionamiento en paralelo, formación del personal, plan de reversión | IOC alcanzado; despliegue en la red planificado |
Las duraciones de los ciclos son ilustrativas, pero el patrón es típico: los dos primeros ciclos son cortos y baratos, y cambian el plan de forma notable antes de gastar la mayor parte del presupuesto. Si el equipo hubiera descubierto el problema de rendimiento de la EHR en el noveno mes de un proyecto en cascada, la solución habría exigido rediseñar bajo la presión de los plazos. Para conocer los detalles de la integración sanitaria, consulte nuestra guía de integración de EHR.
¿Cuáles son las ventajas y desventajas del modelo en espiral?
La principal ventaja del modelo en espiral es que expone y reduce los mayores riesgos antes de gastar la mayor parte del presupuesto; su principal desventaja es que depende de personas con experiencia para valorar esos riesgos y añade carga de gestión. Que el intercambio compense depende de lo caro que resultaría un fracaso.
Ventajas del modelo en espiral
- Reducción temprana del riesgo. Los riesgos técnicos, de usabilidad y de integración se prueban en los ciclos más baratos.
- Requisitos flexibles. Los requisitos nuevos o modificados pueden entrar al inicio de cualquier ciclo.
- Puntos de parada integrados. Cada ciclo termina con una decisión de seguir o no, de modo que los proyectos fallidos pueden detenerse pronto.
- Mejores estimaciones con el tiempo. Cada ciclo sustituye supuestos por datos y mejora las previsiones de coste y plazo.
- Fuerte implicación de las partes interesadas. Usuarios y patrocinadores revisan artefactos reales en cada ciclo.
- Sirve para sistemas completos. Hardware, software, operaciones y formación pueden planificarse en los mismos ciclos.
Desventajas del modelo en espiral
- Requiere experiencia en riesgos. Sin un análisis de riesgos competente, los ciclos se convierten en un prototipado sin fin.
- Carga de gestión. Las revisiones, los registros de riesgos y los planes de cada ciclo llevan tiempo.
- Difícil fijar un precio. El coste total y la duración no se conocen al principio, lo que complica los contratos de precio cerrado.
- Puede girar indefinidamente. Sin hitos de anclaje, los equipos siguen refinando en lugar de entregar.
- Excesivo para proyectos pequeños. En trabajos de bajo riesgo y bien conocidos, el formalismo cuesta más de lo que ahorra.
| Factor | Valoración del modelo en espiral |
|---|---|
| Tamaño y coste del proyecto | Ideal para programas grandes y caros |
| Claridad de los requisitos | Sólido cuando los requisitos son poco claros o cambiantes |
| Nivel de riesgo | Sólido cuando un fracaso es caro o peligroso |
| Previsibilidad del presupuesto | Débil al principio, mejora ciclo a ciclo |
| Madurez del equipo necesaria | Alta: arquitectos sénior y responsables conscientes del riesgo |
| Rapidez en aplicaciones pequeñas | Débil: el desarrollo ágil o un modelo iterativo sencillo es más rápido |
El aspecto comercial también importa. Como los proyectos en espiral descubren su alcance real sobre la marcha, encajan mejor en contratos de tiempo y materiales o por fases que en un único precio cerrado; nuestra comparativa de tiempo y materiales vs precio cerrado vs equipo dedicado explica las opciones.
¿Cuándo conviene usar el modelo en espiral?
Use el modelo en espiral cuando un proyecto sea grande, caro si sale mal y lleno de incógnitas que puedan investigarse antes de construir a gran escala. Si puede responder afirmativamente a tres o más de las preguntas siguientes, los ciclos de riesgo al estilo de la espiral probablemente se amortizarán:
- ¿Es el presupuesto lo bastante grande como para que un proyecto fallido perjudique seriamente al negocio?
- ¿Son los requisitos poco claros, discutidos o susceptibles de cambiar de forma significativa?
- ¿Depende el proyecto de una tecnología nueva o no probada, o de una integración frágil con sistemas heredados?
- ¿Tendría consecuencias de seguridad, financieras o regulatorias que el sistema se comportara de forma incorrecta?
- ¿Funcionará el sistema durante muchos años, de modo que la operación y el mantenimiento deban planificarse desde el principio?
- ¿Necesitan los patrocinadores puntos de decisión explícitos antes de liberar cada tramo del presupuesto?
Los casos típicos incluyen programas aeroespaciales y de defensa, plataformas de core banking y de pagos, software clínico y de productos sanitarios, grandes sustituciones de sistemas logísticos y ERP, y nuevos productos basados en hardware o componentes de IA no probados.
Cuándo el modelo en espiral no es la opción adecuada
El modelo en espiral no es la opción adecuada para proyectos pequeños, de bajo riesgo o bien conocidos, para equipos sin perfiles sénior capaces de dirigir el análisis de riesgos ni para trabajos que deban entregarse en pocas semanas. Un sitio de marketing, una app móvil estándar con requisitos conocidos o un MVP pensado para obtener respuesta rápida del mercado se resuelven mejor con Scrum, Kanban o un modelo iterativo sencillo.
¿En qué se diferencia el modelo en espiral del modelo en cascada, el modelo en V y el desarrollo ágil?
El modelo en espiral se diferencia de la cascada y del modelo en V en que repite sus fases en ciclos guiados por el riesgo, y del desarrollo ágil en que organiza esos ciclos en torno a un análisis explícito de riesgos y a puntos de compromiso formales en lugar de sprints de duración fija. La tabla resume las diferencias prácticas.
| Aspecto | Espiral | Cascada | Modelo en V | Ágil (Scrum) |
|---|---|---|---|---|
| Motor | Riesgo | Documentos y fases | Verificación y validación | Valor para el cliente y retroalimentación |
| Iteraciones | Ciclos de duración variable | Ninguna (una sola pasada) | Ninguna (una sola pasada) | Sprints fijos de 1–4 semanas |
| Cambios en los requisitos | Al inicio de cada ciclo | Costosos tras la aprobación | Costosos tras la aprobación | En cada sprint |
| Gestión del riesgo | Explícita, en cada ciclo | Implícita, tardía | Mediante la planificación de las pruebas | Implícita, mediante retroalimentación corta |
| Documentación | Tanta como exija el riesgo | Extensa | Extensa | Ligera |
| Ideal para | Sistemas grandes y de alto riesgo | Alcance estable y bien definido | Sistemas críticos y regulados | Productos con necesidades cambiantes |
Los modelos puros son poco frecuentes en la práctica. El informe del PMI Pulse of the Profession 2024 constató que la proporción de proyectos gestionados con enfoques híbridos pasó del 20% en 2020 al 31% en 2023, y el híbrido de espiral y desarrollo ágil es uno de los patrones más habituales que vemos en programas empresariales. Para una visión más amplia, lea nuestras guías sobre metodologías de desarrollo de software y sobre ágil vs cascada.
El Incremental Commitment Spiral Model (ICSM)
El Incremental Commitment Spiral Model es la evolución moderna de la espiral propuesta por Boehm, publicada en 2014 junto con Jo Ann Lane, Supannika Koolmanojwong y Richard Turner. Mantiene los ciclos guiados por el riesgo, pero organiza cada uno en torno a cuatro principios: orientación basada en el valor para las partes interesadas, compromiso y responsabilidad incrementales, ingeniería multidisciplinar concurrente y decisiones basadas en evidencias y en el riesgo. En el ICSM, un proyecto solo avanza cuando las evidencias de su viabilidad son lo bastante sólidas para que las partes interesadas comprometan más recursos.
¿Cómo se aplica el modelo en espiral en 2026?
La forma más eficaz de aplicar el modelo en espiral en 2026 es conservar su disciplina de riesgos y sus puntos de decisión, y ejecutar el trabajo de construcción de cada ciclo con prácticas ágiles y DevOps modernas. Estos siete pasos describen cómo lo hacemos en proyectos de alto riesgo:
- Empiece con un ciclo de descubrimiento centrado en el riesgo. Identifique objetivos, restricciones y los diez riesgos principales antes de escribir código de producción; nuestra guía de la fase de descubrimiento muestra qué producir.
- Convierta los riesgos en experimentos. Para cada riesgo principal, defina un spike, un prototipo o un benchmark con un criterio claro de aprobado o suspenso y un límite de tiempo.
- Limite la duración de cada ciclo. Mantenga los primeros ciclos en 2–6 semanas y los posteriores en un trimestre, para que la espiral no se desvíe.
- Use los hitos de anclaje como puertas de financiación. Libere el presupuesto de la entrega completa solo después del LCA, cuando los riesgos de arquitectura estén resueltos.
- Ejecute sprints dentro de los ciclos. Use Scrum o Kanban para el cuadrante de ingeniería, con CI/CD, pruebas automatizadas y feature flags.
- Mantenga vivo el registro de riesgos. Revíselo en cada revisión de ciclo, cierre los riesgos con evidencias y añada los nuevos en cuanto aparezcan.
- Documente según el riesgo, no según la plantilla. Redacte especificaciones detalladas donde los errores salen caros, como interfaces, seguridad y funciones reguladas, y mantenga ligero el resto.
La espiral también encaja de forma natural en el ciclo de vida del desarrollo de software en su conjunto: no sustituye los requisitos, el diseño, la construcción, las pruebas ni la implantación, sino que decide cuántas veces y con qué nivel de detalle los recorre.
Preguntas frecuentes
¿Qué es el modelo en espiral en el desarrollo de software?
El modelo en espiral en el desarrollo de software es un modelo de ciclo de vida iterativo y guiado por el riesgo que Barry Boehm presentó en 1986. Un proyecto avanza por ciclos repetidos y en cada uno fija objetivos, analiza y reduce los mayores riesgos, construye y prueba una versión del producto y planifica el ciclo siguiente. El riesgo, y no una secuencia fija de fases, decide qué hace el equipo a continuación.
¿Cuáles son las cuatro fases del modelo en espiral?
Cada ciclo del modelo en espiral tiene cuatro cuadrantes: determinar objetivos, alternativas y restricciones; identificar y resolver riesgos, a menudo con prototipos o simulaciones; desarrollar y probar el producto del nivel siguiente; y revisar los resultados y planificar la siguiente iteración. Las partes interesadas se comprometen con el ciclo siguiente solo después de la revisión.
¿Por qué el modelo en espiral se denomina metamodelo?
El modelo en espiral se denomina metamodelo porque puede contener otros modelos de proceso. Según los riesgos de un ciclo concreto, un equipo puede ejecutarlo como una etapa en cascada, un prototipo evolutivo o una entrega incremental. La espiral decide qué enfoque encaja; no impone uno solo.
¿Cuál es la principal desventaja del modelo en espiral?
La principal desventaja del modelo en espiral es su dependencia de un análisis de riesgos competente. Cada ciclo necesita personas capaces de detectar y dimensionar riesgos técnicos, de calendario y de negocio; sin ellas, el modelo se convierte en una costosa serie de prototipos sin fin. Además, añade carga de gestión y documentación, lo que lo hace poco adecuado para proyectos pequeños o de bajo riesgo.
¿Es ágil el modelo en espiral?
No exactamente. El modelo en espiral es iterativo y acepta requisitos cambiantes, como el desarrollo ágil, pero lo guían un análisis explícito de riesgos, revisiones formales y puntos de compromiso de las partes interesadas, y no sprints cortos de duración fija. En 2026 muchos equipos combinan ambos: ciclos de riesgo e hitos al estilo de la espiral a nivel de programa, con sprints de Scrum o Kanban dentro de cada ciclo.
¿Quién creó el modelo en espiral del desarrollo de software?
Barry Boehm creó el modelo en espiral del desarrollo de software. Lo describió por primera vez en el artículo de 1986 A Spiral Model of Software Development and Enhancement y publicó la versión más citada en IEEE Computer en mayo de 1988, con el TRW Software Productivity System como ejemplo. Más tarde lo perfeccionó hasta convertirlo en el Incremental Commitment Spiral Model.
Publicado el 24 de octubre de 2026. Fuentes: B. Boehm, «A Spiral Model of Software Development and Enhancement», IEEE Computer, mayo de 1988; B. Boehm, Spiral Development: Experience, Principles, and Refinements, CMU/SEI-2000-SR-008 (en inglés); B. Boehm y W. Hansen, The Spiral Model as a Tool for Evolutionary Acquisition (en inglés); B. Boehm, J. A. Lane, S. Koolmanojwong y R. Turner, The Incremental Commitment Spiral Model, Addison-Wesley, 2014; PMI, Pulse of the Profession 2024 (en inglés). El ejemplo hospitalario y las duraciones de los ciclos son ilustrativos.
