SDLC

Software Development Lifecycle ist der Sammelbegriff für die Phasen, die Software von Idee bis Außerbetriebnahme durchläuft. Verschiedene Methoden (Agile, Wasserfall, DevOps, Continuous Delivery) definieren andere Phasengrenzen und andere Übergangsmodi. Die Phasen selbst sind weitgehend invariant: Discovery, Design, Build, Test, Deploy, Operate, Retire.

Nützlich als Vokabular, nicht als Prozess. Teams, die ein strenges SDLC erzwingen, landen bei Dokumentations-Overhead, der den zweiten Sprint nicht überlebt. Teams, die das SDLC völlig ignorieren, entdecken jede Phase auf die schmerzhafte Art neu („wir haben ohne Deploy-Plan geshippt", „wir haben nie überlegt, wie wir das System abschalten").

Beispiel für die Phase, die alle überspringen: Ein Startup baut über zwei Jahre drei interne Services, shippt sie und macht weiter. Niemand verantwortet „Operate" und niemand plante „Retire". Achtzehn Monate später laufen zwei der drei Services noch, niemand erinnert sich warum, der eine Engineer, der sie verstand, ist gegangen, und das Abschalten könnte etwas brechen oder auch nicht. Das sind die unverrechneten Kosten, die hintere Hälfte des Lifecycles zu überspringen. Die Lösung ist billig, wenn vorab gemacht (einen Owner benennen, einen Deploy- und einen Teardown-Plan schreiben), und teuer, wenn später entdeckt.

Die Methode, die du wählst, entscheidet vor allem, wie starr die Grenzen zwischen Phasen sind. Ein Wasserfall-SDLC läuft sie strikt in Sequenz mit Sign-offs an jedem Gate; ein agiles SDLC verschränkt Design, Build und Test fortlaufend und kehrt zu früheren Phasen zurück, während es lernt. Die Phasen sind in beiden Fällen dasselbe Set, was die nützliche Einsicht ist: „Agile versus Wasserfall" zu streiten heißt eigentlich, darüber zu streiten, wie durchlässig die Grenzen sein sollen, und die richtige Antwort hängt davon ab, wie sehr sich deine Anforderungen noch ändern können.

Der ehrliche Trade-off und der häufige Fehler: Founder hören „SDLC" und überformalisieren es entweder zu einem gated, Sign-off-lastigen Prozess, der Tempo killt, oder tun es als Enterprise-Theater ab und überspringen die unglamourösen Phasen. Die richtige Haltung ist, es als Checkliste von Dingen zu behandeln, die irgendwo passieren müssen, nicht als Sequenz, die man durchmarschiert. Wavects bevorzugte Form: eine bezahlte Discovery-Phase vorne, Design und Build in kurzen Zyklen verschränkt, automatisiertes TDD und CI/CD von Tag eins, Operate mit klarer Ownership, Retire mit dokumentierten Migrationspfaden.