TL;DR — die sechs Phasen auf einen Blick
Jedes erfolgreiche individuelle Softwareprojekt durchläuft dieselben sechs Phasen, unabhängig davon, ob das Team agil oder hybrid arbeitet. Das Überspringen oder Verkürzen einer Phase erzeugt nachgelagerte Kosten, die den eingesparten Zeitaufwand regelmäßig übersteigen. Hier die Kurzfassung:
- Discovery: Definieren, was gebaut wird und warum — Anforderungen, Scope, Datenmodell, Architekturentscheidungen. 4–6 Wochen.
- Design & Architektur: UX-Wireframes, UI-Designs, System-Blueprint. 3–5 Wochen.
- Entwicklungs-Sprints: Iterativer agiler Build, lauffähige Software alle 2 Wochen. 12–24 Wochen für mittlere Projekte.
- Testing & QA: Automatisierte Tests, manuelle QA, Sicherheitsprüfung, Performance-Profiling. 3–5 Wochen (überlappend mit Sprints).
- Deployment & Launch: Staging-Verifikation, Produktionsfreigabe, Go-Live-Monitoring. 1–2 Wochen.
- Support & Iteration: Fehlerbehebungen, Sicherheits-Patches, Feature-Releases. 15–20 % der Build-Kosten pro Jahr.
Überblick: der vollständige SDLC in einer Tabelle
Die folgende Tabelle fasst zusammen, was jede Phase liefert, wie lange sie typischerweise dauert und welchen Anteil sie an den Gesamtkosten eines mittelkomplexen Projekts (90.000 €–230.000 € Build) hat.
| Phase | Kernergebnisse | Typische Dauer | % der Build-Kosten |
|---|---|---|---|
| 1. Discovery | Anforderungsdokument, Datenmodell, Architecture Decision Record, Projektauftrag | 4–6 Wochen | 10–15 % |
| 2. Design & Architektur | Wireframes, UI-System, API-Verträge, Infrastrukturdiagramm | 3–5 Wochen | 8–12 % |
| 3. Entwicklungs-Sprints | Lauffähige Software-Inkremente, Sprint-Demos, Release-fähige Builds | 12–24 Wochen | 55–65 % |
| 4. Testing & QA | Automatisierte Test-Suite, QA-Bericht, Sicherheitsbefunde, Performance-Baseline | 3–5 Wochen | 8–12 % |
| 5. Deployment & Launch | Produktionsumgebung, CI/CD-Pipeline, Runbook, Go-Live-Checkliste | 1–2 Wochen | 3–5 % |
| 6. Support & Iteration | Patch-Releases, Feature-Inkremente, Monitoring-Dashboards | Laufend | 15–20 % /Jahr |
Phase 1: Discovery
Die Discovery-Phase ist die folgenschwerste Phase im gesamten Software-Entwicklungslebenszyklus. Sie übersetzt ein Geschäftsproblem in eine baubare technische Spezifikation. Ohne sie bauen Entwicklungsteams das Falsche in voller Geschwindigkeit.
Eine gut durchgeführte Discovery-Phase produziert vier Kernartefakte:
- Anforderungsdokument: User Stories, Akzeptanzkriterien, Out-of-Scope-Entscheidungen und Edge-Case-Behandlung.
- Datenmodell: die Entitäten, Beziehungen und Constraints, die das System repräsentieren muss. Dies ist die Grundlage jeder nachfolgenden Architekturentscheidung.
- Architecture Decision Record (ADR): Technologie-Stack, Integrationspunkte, Hosting-Strategie, Compliance-Anforderungen (DSGVO/BDSG, AV-Vertrag) und dokumentierte Trade-offs mit Begründung.
- Projektauftrag: Scope, Meilensteine, Teamzusammensetzung, Kommunikationsrhythmus und Eskalationswege.
Die Discovery-Phase dauert für ein mittelkomplexes Projekt typischerweise 4–6 Wochen und kostet 15.000–25.000 € mit einem erfahrenen Nearshore-Team. Sie wird fast immer separat vom Hauptbuild bepreist — und das zu Recht. Der Output der Discovery ist das, was einen Festpreis oder gedeckelten Zeit-und-Material-Vertrag erst aussagekräftig macht. Ohne Discovery ist jeder Festpreis eine Schätzung ins Blaue.
Teams, die Discovery überspringen, berichten regelmäßig dieselben Symptome: Anforderungen ändern sich, nachdem die Architektur festgelegt ist; Integrationen werden erst während des Sprints entdeckt; Compliance-Anforderungen wie DSGVO-Datenspeicherung oder BDSG-Auftragsverarbeitung werden nach dem Launch nachgerüstet. Jede dieser Situationen ist teurer zu beheben als eine vollständige Discovery-Phase gekostet hätte.
Phase 2: Design & Architektur
Design und Architektur übersetzt die Discovery-Artefakte in den visuellen und strukturellen Blueprint, gegen den das Entwicklungsteam bauen wird. Es läuft in zwei parallelen Workstreams.
UX- und UI-Design produziert User Flows, Wireframes und hochauflösende Mockups. Für produktseitige Software ist das richtige UX vor dem Entwicklungsstart nicht kosmetisch — es verhindert die teuerste Art von Nacharbeit: den Wiederaufbau von UI, das echte Nutzer ablehnen. Eine gut designte Komponentenbibliothek beschleunigt auch die Entwicklung, da Entwickler gegen ein konsistentes System bauen statt pro Screen UI neu zu erfinden.
Systemarchitektur produziert das Infrastrukturdiagramm, API-Verträge, den Datenmigrations-Plan (falls zutreffend) und das technische Runbook. Hier werden Schnittstellen-Entscheidungen getroffen: Monolith vs. Microservices, synchrone vs. event-getriebene Kommunikation, Authentifizierungs- und Autorisierungsstrategie, Datenspeicherungsanforderungen gemäß DSGVO Art. 5 und 32, Verschlüsselungsanforderungen sowie CI/CD-Pipeline-Design.
In dieser Phase getroffene Architekturentscheidungen sind kostspielig rückgängig zu machen. Die falsche Datenpartitionierungsstrategie zu wählen kann beispielsweise sechs Monate später eine vollständige Datenmigration erfordern. Erfahrene Architekten rechtfertigen ihre Kosten in dieser Phase durch fundierte Trade-off-Entscheidungen statt durch Standardisierung auf das Bekannte.
Phase 3: Entwicklungs-Sprints
Die Entwicklung ist die Phase, in der der größte Teil des Budgets verbraucht wird — typischerweise 55–65 % der Gesamtprojektkosten. Für mittelkomplexe Projekte läuft sie über 12–24 Wochen in mehreren agilen Sprints.
Jeder Sprint folgt demselben Rhythmus: Planung (Sprint-Ziele aus dem Backlog definieren), Build (Entwickler implementieren vereinbarte Stories), Review (lauffähige Software wird Stakeholdern demonstriert), Retrospektive (Team-Verbesserungsmaßnahmen). Der Zwei-Wochen-Sprint-Takt erfüllt eine kritische Funktion: Er deckt Fehlausrichtungen früh auf, wenn sie günstig zu korrigieren sind, statt bei der Lieferung, wenn das nicht mehr der Fall ist.
Engineering-Praktiken, die professionelle von amateurhafter Lieferung unterscheiden:
- Code Review: Jeder Pull Request wird von mindestens einem Senior-Entwickler vor dem Merge geprüft. Verhindert Anhäufung technischer Schulden.
- Automatisiertes Testen: Unit-, Integrations- und End-to-End-Tests werden parallel zu Features geschrieben, nicht als Nachgedanke. Mindestens 70 % Code-Coverage auf kritischen Pfaden.
- Feature-Flags: Neue Funktionalität hinter Flags deployt, was inkrementelles Rollout und sicheres Rollback ohne Deployment-Overhead ermöglicht.
- Security-by-Construction: Input-Validierung, Secrets-Management, OWASP-Top-10-Maßnahmen und Abhängigkeits-Vulnerability-Scanning eingebaut in den Entwicklungs-Workflow, nicht nachgerüstet im QA.
Für Teams mit Compliance-Anforderungen (DSGVO-Datenspeicherung, BDSG-AV-Vertrag, SOC 2-Prüfpfad, HIPAA) müssen die Compliance-Controls ab dem ersten Sprint in Stories eingebaut werden, nicht nach der Lieferung hinzugefügt. Weitere Informationen finden Sie auf unserer Seite individuelle Softwareentwicklung.
Phase 4: Testing & QA
Qualitätssicherung läuft parallel zu Entwicklungs-Sprints und nicht als diskrete Post-Build-Phase. Ein dedizierter QA-Zyklus am Ende der Entwicklung bleibt jedoch vor jedem Produktionsrelease unerlässlich.
Die Testing-Pyramide für produktionsreife Software umfasst vier Ebenen:
- Unit-Tests: Schnelle, isolierte Tests einzelner Funktionen und Komponenten. Laufen bei jedem Commit. Sollen 70 %+ der Geschäftslogik abdecken.
- Integrationstests: Stellen sicher, dass Komponenten und Services korrekt interagieren. Decken kritische API-Verträge und Datenbankoperationen ab.
- End-to-End-Tests: Simulieren echte Nutzerreisen durch eine deployte Umgebung. Decken alle primären User Flows und in der Discovery dokumentierten Edge Cases ab.
- Nichtfunktionales Testing: Performance-Profiling unter realistischer Last, Sicherheits-Penetrationstest (für regulierte Umgebungen), Barrierefreiheits-Audit (WCAG 2.1 AA Minimum für öffentlich zugängliche Software in der EU).
Ein Sicherheits-Penetrationstest ist für jede Software, die personenbezogene Daten verarbeitet (DSGVO-Compliance), Finanztransaktionen abwickelt (PCI-DSS) oder Gesundheitsdaten handhabt (HIPAA), unverhandelbar. Für EU-seitige Software ist die Datenschutz-Folgenabschätzung (DSFA) gemäß DSGVO Art. 35 für Hochrisikoverarbeitungen gesetzlich vorgeschrieben und sollte vor dem Launch abgeschlossen sein.
Phase 5: Deployment & Launch
Das Deployment ist die kürzeste Phase, aber die mit der höchsten öffentlichen Sichtbarkeit. Ein missglückter Launch erzeugt ein Vertrauensproblem, dessen Behebung Wochen an operativer Kommunikation erfordert, unabhängig von der technischen Qualität der Software.
Produktionsreifes Deployment für ein mittelkomplexes Projekt umfasst:
- Infrastrukturbereitstellung: Cloud-Umgebung konfiguriert für Produktionslast, Security Groups, Backup-Richtlinien und Alerting eingerichtet.
- CI/CD-Pipeline: Automatisierter Build-, Test- und Deployment-Pipeline, damit künftige Releases Minuten statt Tage dauern.
- Stufenweises Rollout: Produktions-Traffic schrittweise von alt auf neu umgeleitet (5 % → 25 % → 100 %) mit automatischen Rollback-Triggern bei erhöhten Fehlerraten.
- Go-Live-Monitoring: Echtzeit-Dashboards für Fehlerrate, Latenz, Durchsatz und Infrastruktur-Metriken in den ersten 72 Stunden nach dem Launch. On-Call-Engineering-Abdeckung in diesem Zeitfenster wird erwartet.
- Operations-Runbook: Dokumentierte Verfahren für gängige Betriebsaufgaben, Incident-Response und Eskalationswege.
Phase 6: Support & Iteration
Software, die nicht aktiv gewartet wird, degradiert. Nicht dramatisch oder sofort — aber stetig. Abhängigkeiten veralten. Sicherheitslücken häufen sich an. Performance nimmt mit wachsendem Datenvolumen ab. Features, die bei 100 Nutzern funktioniert haben, brechen bei 10.000 zusammen.
Branchenrichtwerte setzen laufenden Support und Wartung konstant bei 15–20 % der ursprünglichen Build-Kosten pro Jahr an. Was dieses Budget für eine typische mittelkomplexe Plattform abdeckt:
- Sicherheits-Patches und Abhängigkeits-Updates: Kritische und hohe CVEs innerhalb vereinbarter SLAs gepatcht (typischerweise 24–72 Stunden für kritische). Nicht verhandelbar.
- Fehlerbehebungen aus realem Nutzerfeedback: Die ersten 90 Tage nach dem Launch bringen typischerweise den Großteil der Edge-Case-Bugs an die Oberfläche, die das Testing übersehen hat.
- Infrastruktur-Skalierung: Kapazitätsanpassungen bei wachsender Nutzerbasis, Kostenoptimierung bei stabilisierenden Nutzungsmustern.
- Feature-Iterationen: nutzdatengetriebene Feature-Ergänzungen, UX-Verbesserungen und Integrationen aus der Produkt-Roadmap.
- Monitoring und On-Call: 24/7-Alerting mit definierten Response-SLAs. Für umsatzkritische Software müssen P1-Incidents innerhalb von 15 Minuten bestätigt werden.
Für einen Build von 150.000 € sind jährlich 22.500–30.000 € für Support einzuplanen. Für einen Build von 300.000 € 45.000–60.000 € pro Jahr. Teams, die das Supportbudget auf null kürzen, sehen sich typischerweise innerhalb von 3–5 Jahren einer erzwungenen vollständigen Neuentwicklung bei 150–200 % der ursprünglichen Kosten gegenüber. Das vollständige Wartungskostenmodell finden Sie in unserem Leitfaden zu Kosten individueller Softwareentwicklung 2026.
Iteration in dieser Phase ist keine Wartung — es ist Produktentwicklung. Nutzeranalysen, Support-Tickets und Vertriebsfeedback speisen ein priorisiertes Backlog. Feature-Releases in dieser Phase sind schneller und günstiger als während des initialen Builds, weil die Architektur steht, das Team die Codebasis kennt und die CI/CD-Pipeline betriebsbereit ist. Lesen Sie unseren Leitfaden so wählen Sie ein Softwareentwicklungsunternehmen, um Partner auf beide Dimensionen zu evaluieren.
FAQ
Welche Phasen hat die Softwareentwicklung?
Die sechs Kernphasen sind: Discovery (Anforderungen und Architektur), Design und Architektur (UX- und System-Blueprints), Entwicklungs-Sprints (iterativer agiler Build), Testing und QA (automatisierte und manuelle Verifikation), Deployment und Launch (Produktionsrelease) sowie Support und Iteration (Wartung und Feature-Evolution). Jede Phase produziert spezifische Artefakte und bildet das Gate für die nächste Phase. Das Überspringen von Phasen erzeugt nachgelagerte Kosten, die den eingesparten Zeitaufwand regelmäßig übersteigen.
Warum ist die Discovery-Phase wichtig?
Discovery übersetzt ein Geschäftsproblem in eine konkrete, baubare technische Spezifikation, bevor Entwicklungsbudget eingesetzt wird. Sie identifiziert Integrations-Komplexität, Compliance-Anforderungen (DSGVO/BDSG, AV-Vertrag) und architektonische Constraints, die sich sonst als teure Mid-Build-Überraschungen manifestieren würden. Projekte, die in eine ordentliche 4–6-wöchige Discovery-Phase investieren, sparen regelmäßig 30–50 % an Nacharbeit während des Builds.
Wie lange dauert jede Phase?
Für ein mittelkomplexes Projekt: Discovery 4–6 Wochen; Design und Architektur 3–5 Wochen; Entwicklungs-Sprints 12–24 Wochen; Testing und QA 3–5 Wochen (überlappend mit Sprints); Deployment und Launch 1–2 Wochen. Die Gesamtdauer von Kick-off bis Produktionslaunch beträgt typischerweise 5–9 Monate. Komplexe Enterprise-Projekte dauern 12–24 Monate.
Verwenden Sie agile oder Wasserfall?
Wir verwenden einen Hybrid: strukturierte Discovery- und Architekturphasen (leichte Wasserfall-Gates), gefolgt von agilen Zwei-Wochen-Sprints für die Lieferung. Dies kombiniert architektonische Rigidität mit Liefer-Flexibilität. Reines Wasserfall ist für die meisten individuellen Softwareprojekte ungeeignet, weil Anforderungen sich weiterentwickeln. Reines Agile ohne Vorab-Architektur produziert technische Schulden, die sich mit der Zeit kumulieren. Der Hybrid ist der aktuelle Industriestandard für individuelle Mittelstands- und Enterprise-Software.
Was passiert nach dem Launch?
Die Software tritt in die Support- und Iterationsphase ein: Sicherheits-Patches, Fehlerbehebungen, Infrastruktur-Skalierung und Feature-Releases. Planen Sie 15–20 % der Build-Kosten pro Jahr für diese Phase ein. Post-Launch-Iteration ist schneller und günstiger als der initiale Build, weil die Architektur und die CI/CD-Pipeline bereits stehen. Kürzen Sie dieses Budget nicht — aufgeschobene Wartung schafft kumulierten technischen Schulden, der innerhalb von 3–5 Jahren eine vollständige Neuentwicklung erzwingt.
Veröffentlicht am 21. Mai 2026. Prozesszeitrahmen und Kostenanteilswerte spiegeln Senior-Nearshore-Lieferung für mittelkomplexe individuelle Softwareprojekte wider. Individuelle Projektzeitrahmen variieren je nach Scope, Integrationskomplexität und Compliance-Anforderungen.
