Spiralmodell in der Softwareentwicklung: Phasen, Diagramm, Vor- und Nachteile

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Das Spiralmodell der Softwareentwicklung ist Barry Boehms Antwort aus den 1980er-Jahren auf ein Problem, an dem Projekte auch 2026 noch scheitern: Teams binden ihr gesamtes Budget an einen Plan, bevor sie wissen, welche Teile dieses Plans falsch sind. Statt starre Phasen abzuarbeiten, durchläuft ein Spiralprojekt immer wieder dieselben vier Aktivitäten – und in jedem Zyklus fließt der Aufwand dorthin, wo das Projekt am wahrscheinlichsten scheitern würde.

Damit passt das Spiralmodell gut zu Vorhaben, bei denen eine falsche frühe Annahme teuer wird: Ablösung von Kernbankensystemen, klinische Systeme, Logistikplattformen, Software für Luftfahrt und Verteidigung und andere Formen der individuellen Enterprise-Softwareentwicklung, bei denen Integrations-, Performance- oder Regulierungsrisiken ein ganzes Jahr Arbeit zunichtemachen können. Zugleich ist es das am häufigsten missverstandene Modell, weil das berühmte Diagramm wie ein abzuarbeitender Prozess aussieht und nicht wie eine Methode, um über den nächsten Schritt zu entscheiden.

Dieser Leitfaden erklärt das Spiralmodell verständlich: woher es stammt, wie Sie das Diagramm lesen, was in jedem Quadranten geschieht, welche Meilensteine eine Endlosschleife verhindern, ein durchgerechnetes Beispiel, echte Vor- und Nachteile und den Vergleich mit dem Wasserfallmodell, dem V-Modell und Agile. Der letzte Abschnitt zeigt, wie wir das Denken der Spirale in modernen Projekten anwenden – ohne den historischen Dokumentationsballast.

Was ist das Spiralmodell in der Softwareentwicklung?

Das Spiralmodell in der Softwareentwicklung ist ein risikogetriebenes, iteratives Lebenszyklusmodell, in dem ein Projekt wiederholt vier Aktivitäten durchläuft – Ziele festlegen, Risiken auflösen, entwickeln und testen, den nächsten Zyklus planen – und jeder Zyklus eine vollständigere Version des Systems liefert. Kerngedanke: Nicht eine vorgegebene Reihenfolge, sondern das Risiko entscheidet, wie viel von jeder Aktivität wann nötig ist.

Jede Windung der Spirale heißt Zyklus, Schleife oder Iteration. Frühe Zyklen sind klein und günstig: ein Betriebskonzept, eine Machbarkeitsstudie, ein Wegwerf-Prototyp. Spätere Zyklen sind größer und ähneln klassischer Entwicklung und Einführung. Der Abstand vom Zentrum der Spirale steht für die kumulierten Kosten – das Modell macht also sichtbar, dass jeder zusätzliche Zyklus Geld kostet und seinen Platz verdienen muss.

Woher das Spiralmodell stammt

Barry Boehm, damals bei TRW, beschrieb das Modell erstmals 1986 im Aufsatz A Spiral Model of Software Development and Enhancement und veröffentlichte die bekannteste Fassung im Mai 1988 in IEEE Computer. Sein Beispiel war das TRW Software Productivity System, ein internes Tooling-Programm, dessen Anforderungen für einen einzigen Wasserfalldurchlauf zu unsicher waren. Im Jahr 2000 formalisierte Boehm das Modell in einem Bericht für das Software Engineering Institute der Carnegie Mellon University, und 2014 war er Mitautor des Incremental Commitment Spiral Model, der modernen Weiterentwicklung der Idee.

Die Spirale prägte auch die öffentliche Beschaffung. Im Jahr 2000 machte das US-Verteidigungsministerium die evolutionäre Beschaffung mit Spiralentwicklung zu einem bevorzugten Ansatz für Großsysteme, und Boehm verfasste Leitlinien für diesen Einsatz. Dieses Erbe erklärt, warum das Modell in Luft- und Raumfahrt, Verteidigung, Verwaltung und anderen Programmen mit hohem Einsatz bis heute verbreitet ist.

Warum das Spiralmodell als Metamodell gilt

Das Spiralmodell gilt als Metamodell, weil es andere Vorgehensmodelle enthalten kann, statt sie zu ersetzen. Ist das Hauptrisiko eines Zyklus ein unklarer Nutzerbedarf, verhält sich dieser Zyklus wie evolutionäres Prototyping. Sind Anforderungen und Technologie gut verstanden, kann ein Zyklus als kurzer Wasserfall laufen. Ist das Risiko eine späte Integration, liefert der Zyklus ein Inkrement. Die Spirale ist der Entscheidungsrahmen; das Modell innerhalb jedes Zyklus wird je nach Risiko gewählt.

Wie liest man das Diagramm des Spiralmodells?

Das Diagramm des Spiralmodells wird von innen nach außen gelesen: Die Spirale beginnt im Ursprung, durchquert in jedem Zyklus vier Quadranten, und jeder abgeschlossene Zyklus endet mit einem Review und einer Zusage für den nächsten. Der Radius zeigt die kumulierten Kosten, der Winkel den Fortschritt im aktuellen Zyklus.

Die meisten Diagramme im Netz lassen die Elemente weg, die die Spirale nützlich machen. Deshalb hilft es zu wissen, was jedes visuelle Element bedeutet:

Welche vier Phasen hat das Spiralmodell?

Die vier Phasen des Spiralmodells sind: Ziele, Alternativen und Rahmenbedingungen festlegen; Risiken erkennen und auflösen; das Produkt der nächsten Stufe entwickeln und testen; den nächsten Zyklus planen. Jeder Zyklus durchläuft alle vier, doch die Zeit pro Phase hängt von den Risiken dieses Zyklus ab.

1. Ziele, Alternativen und Rahmenbedingungen festlegen

Der erste Quadrant definiert, was dieser Zyklus erreichen muss und welche Wege dorthin infrage kommen. Das Team hält die Ziele für den betrachteten Produktteil fest (Performance, Funktionalität, Anpassbarkeit), die alternativen Entwürfe oder Make-or-Buy-Optionen sowie Rahmenbedingungen wie Budget, Zeitplan, Regulierung und Schnittstellen zu bestehenden Systemen. Klare Ziele machen die Risikoanalyse im nächsten Quadranten konkret.

2. Risiken erkennen und auflösen

Der zweite Quadrant ist das Herz der Spirale: Das Team bewertet die Alternativen anhand der Ziele, identifiziert die größten Risikoquellen und investiert genau so viel Aufwand, wie nötig ist, um sie zu verringern. Typische Techniken sind Wegwerf-Prototypen, Benchmarks, Simulationen, Nutzerinterviews, Referenzprüfungen von Anbietern und analytische Modelle. Ergebnis ist eine Entscheidung: welche Alternative verfolgt wird und welche Risiken offen bleiben.

3. Das Produkt der nächsten Stufe entwickeln und testen

Der dritte Quadrant erstellt die nächste Version des Produkts mit dem Entwicklungsansatz, der zum verbleibenden Risiko passt. In frühen Zyklen kann das eine Spezifikation oder Architektur sein, in späteren Zyklen ist es lauffähiger, integrierter und getesteter Code. Weil die großen Unbekannten in Quadrant 2 geklärt wurden, beruht diese Arbeit auf geprüften Annahmen statt auf Vermutungen.

4. Prüfen und den nächsten Zyklus planen

Der vierte Quadrant schließt den Zyklus mit einem Review der Ergebnisse durch die Verantwortlichen für Budget und Anforderungen ab, gefolgt von einem Plan für den nächsten Zyklus. Das Review ist ein echter Zusagepunkt: Die Stakeholder können wie geplant weitermachen, die Ziele ändern oder das Projekt stoppen, solange die kumulierten Kosten noch niedrig sind. Ein früher Abbruch ist ein legitimes und oft wertvolles Ergebnis.

Warum steht die Risikoanalyse im Zentrum der Spirale?

Die Risikoanalyse steht im Zentrum der Spirale, weil das Modell anhand des Risikos entscheidet, wie viel von jeder Aktivität nötig ist: Senkt mehr Aufwand die Wahrscheinlichkeit des Scheiterns, investieren Sie ihn; senkt er sie nicht, hören Sie auf. Boehm formulierte das als Antwort auf die Frage „Wie viel ist genug?“ für Prototyping, Dokumentation, Tests und Planung.

In der Praxis bedeutet das ein lebendes Risikoregister, das zu Beginn und am Ende jedes Zyklus geprüft wird. Das folgende Register zeigt, welche Risiken ein typisches Enterprise-Spiralprojekt verfolgt und mit welcher Technik jedes beseitigt wird:

Zwei Gewohnheiten machen risikogetriebenes Arbeiten wirksam. Erstens: Bewerten Sie jedes Risiko nach Wahrscheinlichkeit und Auswirkung, damit das Team dort Aufwand investiert, wo der erwartete Schaden am größten ist. Zweitens: Lassen Sie jeden Prototyp eine konkrete Risikofrage mit klarem Bestanden/Nicht-bestanden-Kriterium beantworten – ein Prototyp ohne Frage ist nur verfrühte Entwicklung. Unser Leitfaden zur Proof-of-Concept-Softwareentwicklung zeigt, wie Sie solche Experimente gestalten.

Was sind die Ankerpunkt-Meilensteine und Invarianten des Spiralmodells?

Die Ankerpunkt-Meilensteine sind drei Prüfpunkte – Life Cycle Objectives (LCO), Life Cycle Architecture (LCA) und Initial Operational Capability (IOC) –, die Boehm ergänzte, damit Spiralprojekte auf ein fertiges System zusteuern, statt endlos zu kreisen. Sie sind der Teil des Modells, den die meisten Zusammenfassungen weglassen, und der Teil, der es steuerbar macht.

• Life Cycle Objectives (LCO) – die Stakeholder einigen sich darauf, was das System leisten soll, und dass mindestens eine machbare Architektur existiert.
• Life Cycle Architecture (LCA) – die Architektur ist gewählt, ihre großen Risiken sind gelöst, und der Plan zur Umsetzung ist glaubwürdig.
• Initial Operational Capability (IOC) – das erste produktive Release ist bereit, die Nutzer sind geschult und der Einsatzort ist vorbereitet.

Im Bericht Spiral Development: Experience, Principles, and Refinements aus dem Jahr 2000, veröffentlicht vom Software Engineering Institute der Carnegie Mellon University, nannte Boehm außerdem sechs „Invarianten“, die jedes echte Spiralprojekt aufweist. Ein Prozess, der sie auslässt, ist keine Spirale – auch wenn er eine zeichnet:

1. Zentrale Artefakte – Betriebskonzept, Anforderungen, Pläne, Entwurf und Code – werden parallel definiert, nicht nacheinander.
2. Jeder Zyklus umfasst Ziele, Rahmenbedingungen, Alternativen, Risiken, Review und Zusage zum Weitermachen.
3. Der Aufwand für jede Aktivität richtet sich nach dem Risiko.
4. Der Detaillierungsgrad jedes Artefakts richtet sich nach dem Risiko.
5. Das Projekt nutzt die drei Ankerpunkt-Meilensteine (LCO, LCA, IOC).
6. Das Projekt betrachtet das gesamte System und seinen Lebenszyklus, nicht nur die erste Softwareentwicklung.

Beispiel für das Spiralmodell: Wie sieht ein Projekt mit vier Zyklen aus?

Ein Beispiel macht die abstrakten Quadranten greifbar. Nehmen wir einen regionalen Klinikverbund, der seine Software für die Medikamentenausgabe ersetzt: Sie muss sich in die bestehende elektronische Patientenakte integrieren, auf automatisierten Ausgabeschränken laufen und eine regulatorische Prüfung bestehen. Die Hauptrisiken sind klinische Usability, die Integration mit der Patientenakte und die Auditierbarkeit.

Die Zykluslängen sind beispielhaft, doch das Muster ist typisch: Die ersten beiden Zyklen sind kurz und günstig und verändern den Plan deutlich, bevor der Großteil des Budgets ausgegeben ist. Hätte das Team das Performanceproblem der Patientenakte im neunten Monat eines Wasserfallprojekts entdeckt, wäre eine Neukonzeption unter Termindruck nötig gewesen. Details zur Integration im Gesundheitswesen finden Sie in unserem Leitfaden zur EHR-Integration.

Welche Vor- und Nachteile hat das Spiralmodell?

Der wichtigste Vorteil des Spiralmodells ist, dass es die größten Risiken aufdeckt und verringert, bevor der Großteil des Budgets ausgegeben ist; der wichtigste Nachteil ist die Abhängigkeit von erfahrenen Menschen, die diese Risiken beurteilen, sowie zusätzlicher Managementaufwand. Ob sich das lohnt, hängt davon ab, wie teuer ein Scheitern wäre.

Vorteile des Spiralmodells

• Frühe Risikominderung. Technische, Usability- und Integrationsrisiken werden in den günstigsten Zyklen getestet.
• Flexible Anforderungen. Neue oder geänderte Anforderungen können zu Beginn jedes Zyklus einfließen.
• Eingebaute Haltepunkte. Jeder Zyklus endet mit einer Go/No-Go-Entscheidung, sodass scheiternde Projekte früh gestoppt werden können.
• Bessere Schätzungen im Zeitverlauf. Jeder Zyklus ersetzt Annahmen durch Daten und verbessert Kosten- und Terminprognosen.
• Starke Einbindung der Stakeholder. Nutzer und Auftraggeber prüfen in jedem Zyklus reale Artefakte.
• Geeignet für ganze Systeme. Hardware, Software, Betrieb und Schulung lassen sich in denselben Zyklen planen.

Nachteile des Spiralmodells

• Erfordert Risikokompetenz. Ohne fundierte Risikoanalyse werden Zyklen zu offenem Prototyping.
• Managementaufwand. Reviews, Risikoregister und Pläne für jeden Zyklus kosten Zeit.
• Festpreis schwierig. Gesamtkosten und Dauer sind zu Beginn unbekannt, was Festpreisverträge erschwert.
• Gefahr der Endlosschleife. Ohne Ankerpunkt-Meilensteine verfeinern Teams weiter, statt auszuliefern.
• Überdimensioniert für kleine Projekte. Bei risikoarmer, gut verstandener Arbeit kostet der Formalismus mehr, als er spart.

Auch die kaufmännische Seite zählt. Weil Spiralprojekte ihren tatsächlichen Umfang erst im Verlauf kennenlernen, passen sie besser zu Time-and-Materials- oder Phasenverträgen als zu einem einzigen Festpreis; unser Vergleich Time and Materials vs. Festpreis vs. dediziertes Team erklärt die Optionen.

Wann sollten Sie das Spiralmodell einsetzen?

Setzen Sie das Spiralmodell ein, wenn ein Projekt groß ist, Fehler teuer wären und es viele Unbekannte gibt, die sich vor dem vollen Ausbau untersuchen lassen. Wenn Sie drei oder mehr der folgenden Fragen mit Ja beantworten, zahlen sich Risikozyklen im Stil der Spirale wahrscheinlich aus:

• Ist das Budget so groß, dass ein gescheitertes Projekt dem Unternehmen ernsthaft schaden würde?
• Sind die Anforderungen unklar, umstritten oder werden sie sich voraussichtlich deutlich ändern?
• Hängt das Projekt von neuer oder unerprobter Technologie oder von einer fragilen Legacy-Integration ab?
• Hat ein Fehlverhalten des Systems Folgen für Sicherheit, Finanzen oder Regulierung?
• Läuft das System viele Jahre, sodass Betrieb und Wartung von Anfang an geplant werden müssen?
• Brauchen die Auftraggeber explizite Entscheidungspunkte, bevor sie die nächste Budgettranche freigeben?

Typische Einsatzfelder sind Programme in Luft- und Raumfahrt und Verteidigung, Kernbanken- und Zahlungsplattformen, klinische Software und Medizinprodukte-Software, große Ablösungen von Logistik- und ERP-Systemen sowie neue Produkte auf Basis unerprobter Hardware- oder KI-Komponenten.

Wann das Spiralmodell nicht passt

Das Spiralmodell passt nicht zu kleinen, risikoarmen oder gut verstandenen Projekten, nicht zu Teams ohne erfahrene Leute für die Risikoanalyse und nicht zu Arbeit, die in wenigen Wochen live gehen muss. Eine Marketing-Website, eine Standard-App mit bekannten Anforderungen oder ein MVP für schnelles Marktfeedback ist mit Scrum, Kanban oder einem einfachen iterativen Modell besser bedient.

Wie unterscheidet sich das Spiralmodell von Wasserfall, V-Modell und Agile?

Das Spiralmodell unterscheidet sich von Wasserfall und V-Modell dadurch, dass es seine Phasen in risikogetriebenen Zyklen wiederholt, und von Agile dadurch, dass diese Zyklen um explizite Risikoanalyse und formale Zusagepunkte statt um Sprints fester Länge organisiert sind. Die Tabelle fasst die praktischen Unterschiede zusammen.

Reine Modelle sind in der Praxis selten. Der PMI-Bericht Pulse of the Profession 2024 zeigt, dass der Anteil hybrid geführter Projekte von 20 % im Jahr 2020 auf 31 % im Jahr 2023 gestiegen ist, und eine Kombination aus Spirale und Agile ist eines der häufigsten Muster, die wir in Enterprise-Programmen sehen. Einen breiteren Überblick bieten unsere Leitfäden zu Vorgehensmodellen der Softwareentwicklung und zur agilen Softwareentwicklung.

Das Incremental Commitment Spiral Model (ICSM)

Das Incremental Commitment Spiral Model ist Boehms moderne Weiterentwicklung der Spirale, 2014 gemeinsam mit Jo Ann Lane, Supannika Koolmanojwong und Richard Turner veröffentlicht. Es behält die risikogetriebenen Zyklen bei, stellt jeden Zyklus aber unter vier Prinzipien: wertorientierte Steuerung durch die Stakeholder, schrittweise Zusage und Verantwortlichkeit, parallele interdisziplinäre Entwicklung sowie evidenz- und risikobasierte Entscheidungen. Im ICSM geht ein Projekt erst weiter, wenn die Belege für seine Machbarkeit stark genug sind, damit die Stakeholder weitere Mittel zusagen.

Wie wenden Sie das Spiralmodell 2026 an?

Am wirksamsten wenden Sie das Spiralmodell 2026 an, indem Sie seine Risikodisziplin und Entscheidungspunkte beibehalten und die Umsetzung innerhalb jedes Zyklus mit moderner agiler und DevOps-Praxis durchführen. Diese sieben Schritte beschreiben, wie wir bei risikoreichen Projekten vorgehen:

1. Mit einem risikoorientierten Discovery-Zyklus beginnen. Ziele, Rahmenbedingungen und die zehn größten Risiken erfassen, bevor Produktionscode entsteht; unser Leitfaden zur Discovery-Phase zeigt, was dabei entstehen sollte.
2. Risiken in Experimente übersetzen. Für jedes Top-Risiko einen Spike, Prototyp oder Benchmark mit klarem Bestanden/Nicht-bestanden-Kriterium und Timebox definieren.
3. Jeden Zyklus zeitlich begrenzen. Frühe Zyklen auf 2–6 Wochen, spätere auf ein Quartal beschränken, damit die Spirale nicht ausufert.
4. Ankerpunkte als Budget-Gates nutzen. Das Budget für die volle Umsetzung erst nach der LCA freigeben, wenn die Architekturrisiken gelöst sind.
5. Sprints innerhalb der Zyklen laufen lassen. Scrum oder Kanban für den Engineering-Quadranten nutzen, mit CI/CD, automatisierten Tests und Feature Flags.
6. Das Risikoregister lebendig halten. Es bei jedem Zyklus-Review prüfen, Risiken mit Belegen schließen und neue aufnehmen, sobald sie auftauchen.
7. Nach Risiko dokumentieren, nicht nach Vorlage. Detaillierte Spezifikationen dort schreiben, wo Fehler teuer sind – etwa bei Schnittstellen, Sicherheit und regulierten Funktionen – und den Rest schlank halten.

Die Spirale fügt sich zudem natürlich in den übergeordneten Softwareentwicklungslebenszyklus ein: Sie ersetzt Anforderungen, Entwurf, Umsetzung, Test und Einführung nicht, sondern entscheidet, wie oft und wie detailliert Sie sie durchlaufen.

FAQ

Veröffentlicht am 24. Oktober 2026. Quellen: B. Boehm, „A Spiral Model of Software Development and Enhancement“, IEEE Computer, Mai 1988; B. Boehm, Spiral Development: Experience, Principles, and Refinements, CMU/SEI-2000-SR-008; B. Boehm und W. Hansen, The Spiral Model as a Tool for Evolutionary Acquisition; B. Boehm, J. A. Lane, S. Koolmanojwong und R. Turner, The Incremental Commitment Spiral Model, Addison-Wesley, 2014; PMI, Pulse of the Profession 2024. Das Klinikbeispiel und die Zykluslängen sind beispielhaft.