Kurzfassung — der SDLC in einem Absatz
Der Softwareentwicklungslebenszyklus (SDLC) ist der strukturierte Prozess zum Bau von Software, unterteilt in sieben Phasen: Planung, Anforderungen, Design, Umsetzung, Testen, Auslieferung und Wartung. Er macht die Auslieferung planbar und die Qualität sichtbar. Modelle wie Wasserfall, Agile und DevOps sind unterschiedliche Wege durch dieselben Phasen — wählen Sie das, das zu Ihrer Anforderungsstabilität und Release-Häufigkeit passt.
Was ist der Softwareentwicklungslebenszyklus?
Der Softwareentwicklungslebenszyklus ist der strukturierte Prozess, mit dem ein Team Software plant, baut, testet, veröffentlicht und wartet, unterteilt in geordnete Phasen mit definierten Aktivitäten und Ergebnissen. Er existiert, um die Software-Auslieferung planbar zu machen: Jederzeit weiß jeder, in welcher Phase die Arbeit ist, was wahr sein muss, um zur nächsten überzugehen, und wer für jeden Schritt verantwortlich ist. Ohne ihn driften Projekte — das Programmieren beginnt, bevor jemand vereinbart hat, was gebaut wird, das Testen wird am Ende zusammengedrückt, und niemand ist für die Software verantwortlich, sobald sie live ist.
Betrachten Sie den SDLC als gemeinsame Landkarte, nicht als starres Skript. Die Phasen benennen die Arbeit, die immer geschehen muss; das gewählte Modell entscheidet, ob Sie diese Karte einmal von Anfang bis Ende ablaufen oder sie in kurzen Zyklen durchlaufen. Diese Unterscheidung ist wichtig, denn die meiste Verwirrung — „Ist Agile ein SDLC?", „Wie viele Phasen gibt es?" — entsteht durch das Vermischen von Rahmenwerk und Umsetzung. Dieser Leitfaden hält beides getrennt: zuerst die Phasen, dann die Modelle, dann die Wahl. Wenn Sie sehen möchten, wie der Lebenszyklus in einem echten Auftrag aussieht, durchläuft unsere durchgängige individuelle Softwareentwicklung jedes Projekt danach, und unser Prozess der individuellen Softwareentwicklung geht dieselbe Schleife Schritt für Schritt durch.
Die 7 Phasen des Softwareentwicklungslebenszyklus
Der Softwareentwicklungslebenszyklus hat sieben Phasen: Planung, Anforderungsanalyse, Design, Umsetzung, Testen, Auslieferung und Wartung. Jede Phase erzeugt ein konkretes Ergebnis, auf das die nächste angewiesen ist — genau das verhindert, dass die Arbeit sich selbst überholt. Manche Teams fassen dies zu fünf oder sechs Stufen zusammen, aber der Ablauf von Planen über Bauen bis Betreiben ändert sich nie.
- Planung. Definieren Sie Ziel, Umfang, Budget, Zeitplan und Machbarkeit und entscheiden Sie, ob das Projekt lohnt. Ergebnis: ein Projektplan und eine klare Problemstellung, der alle zustimmen.
- Anforderungsanalyse. Erfassen Sie genau, was die Software leisten muss und welche Randbedingungen gelten — funktional und nicht funktional. Ergebnis: eine Anforderungsspezifikation und ein priorisiertes Backlog.
- Design. Übersetzen Sie Anforderungen in einen technischen Bauplan: Architektur, Datenmodell, Integrationen, Sicherheit und Oberflächen. Ergebnis: Architektur- und UX/UI-Designs, aus denen das Team bauen kann.
- Umsetzung. Schreiben, prüfen und integrieren Sie den Code gegen das Design. Ergebnis: funktionierende, versionierte Software in kleinen, getesteten Inkrementen.
- Testen. Prüfen Sie, ob die Software das tut, was die Anforderungen verlangten, und sicher ist — funktionale, Integrations-, Leistungs- und Sicherheitstests. Ergebnis: ein getesteter Build und eine bekannte, priorisierte Fehlerliste.
- Auslieferung. Veröffentlichen Sie die Software in Produktion, idealerweise über eine automatisierte, wiederholbare Pipeline. Ergebnis: ein Live-Release und ein Rollback-Plan, falls etwas schiefgeht.
- Wartung. Beheben Sie Fehler, patchen Sie Sicherheitslücken und verbessern Sie die Software anhand echter Nutzung — die Phase, die am längsten dauert und über die Lebensdauer eines Produkts am meisten kostet. Ergebnis: ein unterstütztes, sich weiterentwickelndes System.
SDLC-Modelle im Vergleich: Wasserfall, Agile, DevOps und mehr
SDLC-Modelle sind unterschiedliche Wege durch dieselben sieben Phasen, und die wichtigsten sind Wasserfall, Agile, iterativ, Spiral, V-Modell und DevOps. Sie unterscheiden sich vor allem in einem: wie oft Sie die Phasen durchlaufen und funktionierende Software liefern. Wasserfall durchläuft sie einmal in Reihenfolge; Agile und DevOps durchlaufen fortlaufend einen Ausschnitt. Die Tabelle stellt die gängigen Modelle nebeneinander.
| Modell | Wie es die Phasen durchläuft | Beste Eignung |
|---|---|---|
| Wasserfall | Alle Phasen einmal, streng nacheinander; Lieferung am Ende | Fester, vollständig bekannter Umfang; regulierte oder vertragsgebundene Arbeit |
| Agile | Ein Ausschnitt jeder Phase in kurzen Iterationen; Lieferung pro Zyklus | Produkt- und SaaS-Arbeit mit unsicheren, wechselnden Anforderungen |
| Iterativ | Bau in wiederholten Zyklen, ein wachsendes System verfeinernd | Große Systeme mit bekanntem Kern, aber sich entwickelnden Details |
| Spiral | Iterationen, gesteuert durch Risikobewertung in jeder Schleife | Große, risikoreiche Projekte mit frühem Risikoabbau |
| V-Modell | Wasserfall mit einer passenden Teststufe für jede Bauphase | Sicherheitskritische Systeme mit hohem Verifikationsbedarf |
| DevOps | Agile plus Automatisierung über Bau, Test, Release und Betrieb | Teams, die häufige, zuverlässige, risikoarme Releases brauchen |
2026 liegt der Schwerpunkt klar auf Agile und DevOps: Die Umfrage Digital.ai State of Agile beziffert die Agile-Verbreitung als nahezu universell unter Softwareteams, und die DORA-Forschung von Google Cloud zeigt immer wieder, dass die Automatisierung der Auslieferungs- und Testphasen — der DevOps-Schritt — Spitzenteams vom Rest trennt. Wasserfall ist jedoch nicht verschwunden; es bleibt die ehrliche Wahl, wenn der Umfang wirklich nicht beweglich ist. Einen tieferen Blick auf das gängigste Modell bietet unser vollständiger Leitfaden zur agilen Softwareentwicklung.
Welches SDLC-Modell sollten Sie wählen?
Wählen Sie Ihr SDLC-Modell, indem Sie zwei Fragen beantworten: Wie stabil sind Ihre Anforderungen, und wie oft können Sie veröffentlichen? Sind die Anforderungen fest und vollständig bekannt und veröffentlichen Sie einmal, passen Wasserfall oder das V-Modell. Sind die Anforderungen unsicher und können Sie inkrementell ausliefern — was auf die meiste Produkt- und SaaS-Arbeit zutrifft — ist Agile der Standard, und DevOps ist Agile mit automatisierter Release-Pipeline. Das Modell ist ein Mittel zum Zweck, keine Identität, die man verteidigt.
Einige praktische Regeln schneiden durch die Debatte. Regulierte, festpreisgebundene oder hardwaregebundene Arbeit, deren Spezifikation unterzeichnet und unbeweglich ist, belohnt ein planbasiertes Modell — es gibt wenig durch Iterieren zu entdecken. Alles, wo echte Nutzer die Anforderungen umformen werden, belohnt Agile, weil das Aufdecken von Problemen alle zwei Wochen günstiger ist als deren Entdeckung bei einem Launch. Und wenn Sie bereits agil liefern, aber Releases langsam, manuell und angstbesetzt sind, ist das Upgrade kein neues Modell — es ist DevOps-Automatisierung auf dem bestehenden. Wenn Sie auch abwägen, wie Sie die Arbeit vertraglich gestalten, behandelt unser Leitfaden zu Time & Materials vs. Festpreis vs. dediziertes Team, welche Modelle zu iterativer Lieferung passen.
Was ist ein SDLC-Diagramm, und brauchen Sie eines?
Ein SDLC-Diagramm ist schlicht eine Visualisierung der Phasen und wie die Arbeit zwischen ihnen fließt — eine Linie für Wasserfall, eine Schleife für Agile, eine Spirale für das Spiral-Modell. Es ist ein Kommunikationswerkzeug, kein Ergebnis an sich: Sein Wert liegt darin, alle darüber zu einigen, welche Phasen es gibt, was die Ein- und Austrittskriterien jeder Phase sind und wo die Rückkopplungsschleifen sitzen. Ein einseitiges Diagramm an der Wand richtet ein Team stärker aus als ein fünfzigseitiges Prozessdokument, das niemand liest.
Sie brauchen kein aufwendiges Diagramm, und Sie müssen keine Methodik kaufen, um eines zu bekommen. Was Sie brauchen, ist ein gemeinsames Bild, das Ihrem Team drei Fragen beantwortet: Was muss wahr sein, um eine Phase zu betreten, was muss diese Phase produzieren, um sie zu verlassen, und wer entscheidet. Kann Ihr Diagramm das nicht beantworten, ist es Dekoration. Kann es das, wird es zur Referenz, auf die Sie zeigen, sobald jemand das Testen überspringen oder mit dem Bauen beginnen will, bevor das Design fertig ist.
Werkzeuge des Softwareentwicklungslebenszyklus nach Phase
SDLC-Werkzeuge unterstützen bestimmte Phasen, und das Ziel ist eine verbundene Toolchain, nicht die längste Liste an Logos. Die folgenden Kategorien decken ab, was die meisten Teams 2026 tatsächlich nutzen; die genauen Produkte zählen weniger, als dass jede Phase Werkzeuge hat und diese sauber ineinandergreifen.
| Phase | Werkzeugkategorie | Wozu es dient |
|---|---|---|
| Planung & Anforderungen | Arbeitsmanagement & Dokumente | Backlog, Roadmap und gemeinsame Spezifikationen |
| Design | Design & Diagramme | Oberflächen-Mockups und Architekturdiagramme |
| Umsetzung | Versionsverwaltung & IDEs | Schreiben, Prüfen und Speichern von Quellcode |
| Testen | Testautomatisierung & Scanning | Automatisierte Tests plus Sicherheits- und Qualitätsprüfungen |
| Auslieferung | CI/CD-Pipelines | Automatisches Bauen, Veröffentlichen und Zurückrollen |
| Wartung | Monitoring & Observability | Alarmierung, Logging und Nachverfolgen von Problemen in Produktion |
Wo Sicherheit hingehört: der sichere SDLC
Sicherheit gehört in jede Phase, nicht am Ende angeschraubt — das ist die ganze Idee eines sicheren Softwareentwicklungslebenszyklus (SSDLC). Sicherheit als abschließendes Testtor zu behandeln ist der Weg, auf dem teure Sicherheitsvorfälle entstehen: Wenn ein Penetrationstest einen Designfehler findet, steckt er bereits in der Architektur und ist kostspielig zu entfernen. Das „Nach-links-Verlagern" — Sicherheitsarbeit früher anzusiedeln — ist durchweg günstiger als das Beheben nach dem Release und 2026 zunehmend eine Compliance-Anforderung statt einer Reifegrad-Kür.
- Planung: Bedrohungsmodellierung und explizite Sicherheitsanforderungen neben den funktionalen.
- Design: sichere Architektur, minimale Rechtevergabe und Datenschutzentscheidungen von Anfang an.
- Umsetzung: sichere Programmierstandards, Code-Review und automatisiertes Abhängigkeits-Scanning.
- Testen: automatisierte Sicherheitstests, statische und dynamische Analyse, nicht nur funktionale Prüfungen.
- Auslieferung & Wartung: gehärtete Konfiguration, Secrets-Management und zügiges Patchen neuer Schwachstellen.
Nichts davon erfordert eine separate „Sicherheitsphase" — es erfordert eine Sicherheitsaktivität in jeder bestehenden Phase, verantwortet vom Team statt an eine Prüfung am Ziel ausgelagert.
Häufige SDLC-Fehler, die Sie vermeiden sollten
Die meisten SDLC-Fehlschläge sind nicht exotisch — es sind dieselben wenigen Phasen, die unter Termindruck übersprungen werden. Die häufigen Fallen zu kennen ist die halbe Miete:
- Planung und Anforderungen überspringen. Mit dem Programmieren zu beginnen, bevor jemand vereinbart hat, was gebaut wird, ist die teuerste Abkürzung in Software; jede falsche Annahme wird später zum Zehnfachen bezahlt.
- Testen als komprimierbare Phase behandeln. Wenn ein Projekt in Verzug gerät, wird das Testen zuerst zusammengedrückt — genau so erreichen Fehler die Nutzer. Automatisierte Tests schützen diese Phase vor dem Terminplan.
- Wartung vergessen. Der Bau ist nur ein Bruchteil der Lebenskosten eines Produkts; ein Projekt ohne Wartungsplan liefert ein System, für das am Tag nach dem Start niemand verantwortlich ist.
- Modell mit Ergebnis verwechseln. Agile-Zeremonien einzuführen und dabei einen festen, rückkopplungsfreien Plan zu behalten, bringt den Aufwand ohne den Nutzen — „agil nur dem Namen nach".
- Die Arbeit unterschätzen. Phasen brechen zusammen, wenn der Zeitplan nie realistisch war. Solide Schätzung hält den Lebenszyklus ehrlich — siehe unseren Leitfaden zur Softwareprojekt-Schätzung.
FAQ
Was ist der Softwareentwicklungslebenszyklus?
Der Softwareentwicklungslebenszyklus (SDLC) ist der strukturierte Prozess, mit dem ein Team Software baut — von der ersten Idee bis zum laufenden System und der laufenden Pflege. Er unterteilt die Arbeit in geordnete Phasen — üblicherweise Planung, Anforderungen, Design, Umsetzung, Testen, Auslieferung und Wartung — jede mit definierten Aktivitäten und Ergebnissen. Das Ziel ist, die Auslieferung planbar und die Qualität sichtbar zu machen. Der SDLC ist das Rahmenwerk; Modelle wie Wasserfall, Agile und DevOps sind unterschiedliche Wege, ihn zu durchlaufen.
Welche Phasen hat der Softwareentwicklungslebenszyklus?
Das gängigste Modell hat sieben Phasen: Planung, Anforderungsanalyse, Design, Umsetzung, Testen, Auslieferung und Wartung. Jede erzeugt ein Ergebnis, auf das die nächste aufbaut — einen Projektplan, eine Anforderungsspezifikation, eine Architektur, funktionierenden Code, einen getesteten Build, ein Live-Release und ein gewartetes System. Manche Teams fassen dies zu fünf oder sechs Stufen zusammen, aber der Ablauf bleibt gleich.
Wie viele Phasen hat der SDLC?
Es gibt keine einzige offizielle Zahl — die meisten Quellen beschreiben fünf bis sieben Phasen. Die Version mit sieben Phasen ist die detaillierteste und am weitesten verbreitete; kürzere Versionen fassen Planung mit Anforderungen und Auslieferung mit Wartung zusammen. Wichtig ist nicht die Anzahl, sondern dass jede Aktivität ihren Platz hat: Fehlt Planung, Testen oder Wartung eine eigene Phase, wird sie meist übersprungen.
Was ist der Unterschied zwischen SDLC und Agile?
Der SDLC ist das übergreifende Rahmenwerk der Arbeit, die zum Bau von Software nötig ist; Agile ist eine Art, diese Arbeit zu ordnen. Jedes Projekt plant, entwirft, baut, testet und veröffentlicht weiterhin — das ist der Lebenszyklus. Wasserfall durchläuft diese Phasen einmal in Reihenfolge; Agile durchläuft einen Ausschnitt derselben Phasen in jeder kurzen Iteration. Agile ist also keine Alternative zum SDLC — es ist ein SDLC-Modell.
Was ist ein sicherer Softwareentwicklungslebenszyklus (SSDLC)?
Ein sicherer Softwareentwicklungslebenszyklus baut Sicherheit in jede Phase ein statt sie erst am Ende zu prüfen: Bedrohungsmodellierung in der Planung, sichere Architektur im Design, sicheres Programmieren und Abhängigkeits-Scans in der Umsetzung, Sicherheitstests vor dem Release sowie gehärtete Konfiguration und zügiges Patchen im Betrieb. Sicherheit so nach links zu verlagern ist weit günstiger als das Beheben nach dem Start und zunehmend eine Compliance-Anforderung.
Welches SDLC-Modell ist das beste?
Es gibt kein universell bestes Modell — das richtige hängt davon ab, wie stabil Ihre Anforderungen sind und wie oft Sie veröffentlichen können. Wasserfall passt zu festem, vollständig bekanntem Umfang; Agile zu unsicherer, inkrementell auslieferbarer Produktarbeit; DevOps erweitert Agile um Release-Automatisierung; das V-Modell eignet sich für sicherheitskritische Systeme. Die meisten Produktteams arbeiten 2026 agil oder mit DevOps.
Zuletzt aktualisiert am 2. Juli 2026. Verbreitungs- und Leistungszahlen beziehen sich auf die Umfrage Digital.ai State of Agile und die DORA-Forschung State of DevOps von Google Cloud und dienen als allgemeine Orientierung. Die richtigen Phasen und das richtige Modell hängen von Ihrem Umfang, Ihren Randbedingungen und Ihrem Team ab — behandeln Sie dies als Ausgangspunkt, nicht als Vorschrift.
