SDLC

In vielen Organisationen schwirrt der Begriff „Software Development Life Cycle“, kurz SDLC, irgendwo zwischen Prozesshandbuch, Wasserfall-Mythos und Compliance-Checkliste. Häufig wird damit ein Diagramm aus Kästchen und Pfeilen verbunden, während das dahinterliegende Verständnis diffus bleibt.

Ein tragfähiger SDLC ist mehr als ein Prozessbild. Er ist ein gemeinsamer Denkrahmen, der beschreibt, wie aus einer Idee Schritt für Schritt ein nutzbares, betreibbares Softwaresystem wird, von der ersten Idee bis zur Wartung im laufenden Betrieb. Dieser Rahmen hilft dir, technische Arbeit, fachliche Entscheidungen und organisatorische Verantwortung auf einer gemeinsamen Landkarte einzuordnen, statt sie nur als Strom einzelner Tickets zu erleben.

Genau deshalb ist der SDLC ein guter Startpunkt, um Softwareentwicklung als Ganzes zu verstehen und nicht nur als das Schreiben von Code. Er betrifft dich, egal ob du entwickelst, testest, ein Produkt verantwortest, ein Projekt leitest oder als Fachbereich die Anforderungen mitbringst.

SDLC als strukturierender Denkrahmen

Der SDLC unterteilt die Arbeit an Software in wiederkehrende Phasen mit klaren Zielen, Entscheidungen und Ergebnissen. Er beantwortet damit nicht primär die Frage, welches Vorgehensmodell eingesetzt wird, sondern wann welche Art von Arbeit und Entscheidung sinnvollerweise stattfindet.

Wie viele Phasen es dabei genau sind, wird in der Fachliteratur unterschiedlich beantwortet, mal mit fünf, mal mit neun benannten Schritten. Ein verbreitetes und praxiserprobtes Modell gliedert den Zyklus in sieben Phasen, die hier als roter Faden dienen:

Wie stark jede Phase ausgeprägt ist und in welcher Reihenfolge sie durchlaufen wird, hängt vom gewählten Vorgehensmodell ab. Nicht jedes Projekt braucht deshalb jede Phase in voller Ausprägung. Wichtiger als das lückenlose Abarbeiten aller sieben Schritte ist, dass die dahinterliegenden Fragen irgendwann bewusst beantwortet werden und nicht stillschweigend offen bleiben.

Wann sich ein vollständig durchlaufener SDLC lohnt und wann er eher überdimensioniert wirkt, vertieft der Artikel „Wann ist SDLC overkill?“.

Warum dieser Rahmen nötig ist

Softwareentwicklung ist ein bewegliches Ziel. Anforderungen verschieben sich, Prioritäten ändern sich, Technologien altern, Organisationsstrukturen wandeln sich. Ohne Rahmen wird der Prozess leicht zu einem endlosen Fluss aus Sprints, Tickets und spontanen Entscheidungen, sichtbar ist dann vor allem das operative Tagesgeschäft.

Ein SDLC bringt Struktur in diese Volatilität, ohne Veränderung zu verhindern. Er unterstützt dich dabei,

• Risiken früh zu erkennen, statt sie erst im Betrieb zu spüren,
• Entscheidungen bewusst zu treffen und nachvollziehbar zu dokumentieren,
• Verantwortung und Erwartungen zwischen Fachbereich, Management und IT zu klären,
• Qualität als Ergebnis wiederholbarer Schleifen (bauen, beobachten, lernen, anpassen) zu gestalten, statt als einmalige Endkontrolle kurz vor dem Go-Live.

Damit ist der SDLC kein Werkzeug allein für Entwickler, sondern ein gemeinsamer Orientierungsrahmen für alle, die an der Entstehung und am Betrieb von Software beteiligt sind.

Die sieben Phasen im Überblick

Jede Phase hat eine eigene Leitfrage, einen eigenen Schwerpunkt und eigene Fallstricke, dazu jeweils eigene Menschen, die in ihr den Ton angeben. Nachfolgend findest du zu jeder Phase eine kurze Einordnung sowie die passende Detailseite mit Aufgaben, typischen Risiken und Fragen für alle Beteiligten.

• Planung: Klärt, warum ein Vorhaben gestartet wird, mit Problem, Zielbild und groben Leitplanken als Ergebnis.
• Analyse: Übersetzt grobe Ziele in konkrete Anforderungen, Prozesse und Nutzergruppen.
• Design: Entwirft eine tragfähige Lösung, von der Architektur bis zur Nutzerführung.
• Entwicklung: Setzt den Entwurf robust in Code um, inklusive technischer Qualität und Automatisierung.
• Test: Prüft, ob die Lösung unter Realbedingungen funktional wie nicht-funktional trägt.
• Bereitstellung: Bringt die Lösung in den Einsatz, mit Rollout, Kommunikation und Sicherheit.
• Wartung: Begleitet den laufenden Betrieb, sorgt für Stabilität und liefert Erkenntnisse für die nächste Runde.

Ein Beispiel: Die Ablösung eines Ticketsystems

Stell dir vor, ein internes Ticketsystem soll durch eine „modernere Lösung“ ersetzt werden, ein Szenario, an dem sich gut zeigen lässt, wie die sieben Phasen aus der Übersicht oben in der Praxis ineinandergreifen.

Alles beginnt mit der Frage, warum das alte System überhaupt weichen soll. In der Planung legt das Projektteam fest, wer von der Ablösung betroffen ist und welche Ziele damit verbunden sind, etwa kürzere Reaktionszeiten im Support oder mehr Transparenz für Führungskräfte. Erst in der Analyse zeigt sich, wie unterschiedlich Support, Vertrieb, IT und Management diese Ziele verstehen, denn was für die eine Abteilung „modern“ bedeutet, ist für die andere schlicht mehr vom Gleichen. Aus diesen teils widersprüchlichen Bedürfnissen entsteht im Design eine konkrete Architektur, mit klaren Schnittstellen zu bestehenden Systemen und einer Nutzerführung, die sich an echten Arbeitsabläufen orientiert statt an einem Wunschbild vom Reißbrett. Die Entwicklung übersetzt diesen Entwurf anschließend in lauffähigen Code und im Test zeigt sich, ob dieser Code unter realistischer Last, mit echten Nutzern und unter prüfendem Blick auf die Sicherheit hält, was er verspricht. Erst danach fällt in der Bereitstellung die Entscheidung, ob das neue System auf einen Schlag oder schrittweise eingeführt wird, flankiert von Kommunikation und Schulung für alle, die künftig damit arbeiten. Und in der Wartung schließlich zeigt sich über Monate und Jahre, ob sich diese Entscheidungen auszahlen, oder ob sich stattdessen technische Schulden und organisatorische Reibungen aufbauen.

Wird eine dieser Phasen unterschätzt oder nur formal abgehakt, verschiebt sich der Preis meist nach hinten: Budgetüberschreitungen, Zeitdruck, Vertrauensverlust oder Betriebsrisiken.

Querschnitt: Wer ist wann gefragt?

Über alle Phasen hinweg verändern sich weniger die beteiligten Personen als die Art ihrer Beteiligung. In Planung und Analyse dominieren Management, Produkt- und Fachverantwortliche. Im Design und in der Entwicklung rücken Architektur- und Entwicklerrollen in den Mittelpunkt, ohne dass der fachliche Dialog abreißen darf. Test, Bereitstellung und Wartung bringen zusätzlich Betrieb, Support und Change-Management ins Spiel.

Ein klarer SDLC macht diese Übergänge explizit. Er verhindert, dass einzelne Gruppen nur punktuell „zur Freigabe“ eingeladen werden, statt durchgängig eingebunden zu sein.

SDLC und Vorgehensmodelle sind zwei verschiedene Dinge

Ein häufiges Missverständnis: SDLC und Vorgehensmodelle wie Scrum, Kanban oder das Wasserfallmodell werden synonym verwendet. Das greift zu kurz. Der SDLC beschreibt, welche Aufgabenblöcke in einem Softwareprojekt anfallen. Ein Vorgehensmodell beschreibt, wie diese Aufgaben organisiert, terminiert und durchlaufen werden.

Das Wasserfallmodell durchläuft die sieben Phasen einmal, weitgehend linear, mit klaren Übergängen. Scrum und andere agile Ansätze durchlaufen verkürzte Versionen dieser Phasen in kurzen, wiederholten Zyklen, oft innerhalb eines einzigen Sprints. Das V-Modell stellt Entwicklungs- und Testphasen bewusst gegenüber, um Prüfschritte von Anfang an mitzudenken. Die Phasen bleiben in allen Fällen im Kern dieselben, nur die Art, wie ein Team durch sie hindurchgeht, unterscheidet sich.

Mehr dazu findest du auf den Seiten zu den einzelnen Vorgehensmodellen. Eine kritische Einordnung, wie gut sich der SDLC mit agilen Arbeitsweisen und DevOps verträgt, liest du im Artikel „SDLC trifft Realität: Agile, DevOps und moderne Alternativen“.

Ein Denkrahmen, kein Dogma

Der SDLC ist kein Regelwerk, das man buchstabengetreu abarbeitet, sondern ein Vokabular, mit dem sich Softwareprojekte beschreiben und reflektieren lassen. Genau das macht ihn wertvoll: Er hilft dir, bewusst zu entscheiden, in welcher Phase du gerade stehst, was diese Phase von dir verlangt und was passiert, wenn du sie überspringst. Nutze die Phasenseiten, um tiefer in das Thema einzusteigen, das dich gerade beschäftigt, oder um dir einen vollständigen Überblick über den Lebenszyklus einer Software zu verschaffen.