Erweitertes Wasserfallmodell
Dieser Beitrag ist eine Begriffserklärung zum erweiterten Wasserfallmodell – inklusive Prüfungsfragen, Kernkomponenten und Tags.
In a Nutshell
Das erweiterte Wasserfallmodell behält die klaren Phasen des klassischen Wasserfalls bei, ergänzt sie aber um kontrollierte Rückkopplungsschleifen zwischen benachbarten Phasen und um frühe Prototypen. Dadurch werden Fehler früher entdeckt und Risiken gezielt reduziert.
Kompakte Fachbeschreibung
Im erweiterten Wasserfall verlaufen die Phasen weiterhin sequenziell (Anforderung → Entwurf → Implementierung → Test → Einführung/Wartung), aber:
- Es gibt definierte Rücksprünge in die vorherige Phase, wenn Abnahmekriterien nicht erfüllt sind.
- Testplanung und QS werden parallel vorbereitet (z.B. Testkonzept schon in Analyse/Entwurf).
- Prototypen (UI- oder Architektur-Spikes) werden früh eingesetzt, um unklare Anforderungen oder technische Risiken zu validieren.
Wichtige Begriffe:
- Verifikation: „Bauen wir das Produkt richtig?“ (gegen Spezifikation)
- Validierung: „Bauen wir das richtige Produkt?“ (gegen fachlichen Zweck)
Außerdem wichtig: Baselines, Change Requests, Impactanalyse und Traceability von Anforderungen zu Tests.
Prüfungsrelevante Stichpunkte
- Sequenzielle Phasen mit kontrollierten Rückkopplungen
- Testplanung früh integrieren (Akzeptanzkriterien schon in Analyse)
- Verifikation/Validierung je Phase (Reviews, Walkthroughs)
- Gate-Entscheidungen mit Abnahmekriterien (IHK)
- Prototyping zur Risikoreduktion
- Traceability (Anforderung → Design → Code → Test)
- Änderungsmanagement + Baselines
Kernkomponenten
- Anforderungsphase (Lasten-/Pflichtenheft, Akzeptanzkriterien)
- Systementwurf (Kontext, Schnittstellen, Datenmodell)
- Architekturentwurf (Qualitätsziele, Entscheidungen, Prototypen)
- Modulentwurf (Detaildesign, Schnittstellenverträge)
- Implementierung (Reviews, statische Analyse)
- Testvorbereitung (Testkonzept, Testfälle, Testdaten)
- Testdurchführung (Modul/Integration/System/Abnahme)
- Einführung (Migration, Betrieb, Handbuch)
- Rückkopplungsschleifen (genehmigte Rücksprünge)
- Konfigurations-/Änderungsmanagement (Versionierung)
Einfaches Praxisbeispiel
Kundenportal mit externer Zahlungsschnittstelle
Anforderung:
- User Stories + Akzeptanzkriterien
- Fachabnahme
System/Architekturentwurf:
- Kontextdiagramm + Schnittstellenvertrag
- Architektur-Spike (Tokenhandling)
- Gate: Architekturfreigabe nach Security Review
Implementierung + Test:
- Coding + Code Review
- Integrationstest gegen Zahlungs-Sandbox
- Fehler -> Rücksprung in Modulentwurf (Timeout/Retry)
- erneute Tests + Abnahme + Go Live
Vorteile und Nachteile
Vorteile
- Klare Planung und Verantwortlichkeiten
- Frühere Fehlerentdeckung (Reviews/Prototypen)
- Weniger teure Spätänderungen
- Gute Nachweisführung (Audit/IHK)
Nachteile
- Rücksprünge erzeugen Abstimmungsaufwand
- Höhere Vorlaufzeit (Spezifikation/Testplanung)
- Weniger flexibel als stark iterative Modelle
Typische Prüfungsfragen (mit Kurzantwort)
- Unterschied klassischer vs. erweiterter Wasserfall? Erweitert = definierte Rücksprünge + frühe QS/Prototypen.
- Rolle von Prototypen? Risiken früh validieren (Performance, Security, UX).
- Verifikation vs. Validierung? Verifikation gegen Spezifikation, Validierung gegen Zweck/Nutzen.
- Wie steuert man Rücksprünge? Gate-Entscheidung, Impactanalyse, Change Request, erneute Abnahme.
Lernstrategie
- Phasen mit Artefakten + Abnahmekriterien zeichnen.
- Rücksprung-Szenario (Integrationstest → Modulentwurf) dokumentieren.
- Vergleich Wasserfall vs. V-Modell vs. Spiral kurz üben.
- Traceability-Tabelle (Anforderung → Testfall) erstellen.