Erweitertes Wasserfallmodell

Dieser Beitrag ist eine Begriffserklärung zum erweiterten Wasserfallmodell, inklusive typischer Prüfungsfragen, Kernkomponenten und Tags. Lese jeden Tag einen “zufälligen Artikel” auf dieser Seite und erweitere Dein Wissen. Auch wenn viele Themen ggf. neu wirken.

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)

Sehr beliebt, gerade bei IHK Prüfungen bei Fachinformatiker für Anwendungsentwickler

Warum ? Das Wasserfallmodell eignet sich perfekt für kleine Projekte, die man in der Regel im Rahmen einer Ausbildung oder Praktikum durchführt. Das erweiterte Wasserfallmodell ist nicht so starr und bietet die Möglichkeit der Korrekturen durch Rücksprünge. Auch ich habe dieses gewählt und es war einfach zu erläutern und durchzuführen.

Wichtige Begriffe im Detail

Baselines

Definition: Eine Baseline ist ein festgeschriebener Zustand von Projektartefakten zu einem bestimmten Zeitpunkt. Sie dient als Referenzpunkt für zukünftige Änderungen.

Arten von Baselines:

• Requirements Baseline: Genehmigte Anforderungen (Lasten-/Pflichtenheft)
• Design Baseline: Freigegebene Entwurfsdokumente (Architektur, Modulentwurf)
• Code Baseline: Stabile, getestete Code-Version (Release Candidate)
• Test Baseline: Akzeptierte Testergebnisse und Testprotokolle

Beispiel: Nach der Anforderungsphase wird die Requirements Baseline erstellt. Alle späteren Änderungen müssen formal als Change Request beantragt werden.

Change Requests

Definition: Ein Change Request ist ein formaler Antrag zur Änderung bereits baselinierter Artefakte.

Change Request Prozess:

1. Antragstellung: Wer beantragt was und warum?
2. Impact-Analyse: Welche Auswirkungen hat die Änderung?
3. Bewertung: Kosten, Nutzen, Risiken abwägen
4. Entscheidung: Genehmigung oder Ablehnung durch Change Advisory Board (CAB)
5. Umsetzung: Änderung durchführen und dokumentieren

Beispiel: Der Kunde möchte während der Implementierung eine neue Funktion hinzufügen. Dies erfordert einen Change Request mit Impact-Analyse.

Impactanalyse

Definition: Die Impactanalyse untersucht die Auswirkungen einer geplanten Änderung auf das gesamte Projekt.

Analysebereiche:

• Technische Auswirkungen: Welche Komponenten müssen angepasst werden?
• Zeitliche Auswirkungen: Verlängert sich die Projektdauer?
• Kostenmäßige Auswirkungen: Zusätzliche Kosten für Entwicklung und Testing?
• Qualitative Auswirkungen: Beeinflusst die Änderung die Systemqualität?
• Risikoauswirkungen: Entstehen neue technische oder projektbezogene Risiken?

Beispiel: Bei einer Anforderungsänderung wird analysiert, welche Design-Elemente, Code-Module und Testfälle betroffen sind.

Traceability von Anforderungen zu Tests

Definition: Traceability stellt die Verfolgbarkeit von Anforderungen über alle Projektphasen bis zu den Tests sicher.

Traceability-Kette:

Anforderung (REQ-001) → Design (ARCH-015) → Code (CODE-042) → Test (TEST-087)

Zwecke der Traceability:

• Vollständigkeitsnachweis: Jede Anforderung wird implementiert und getestet
• Impact-Analyse: Bei Änderungen schnell betroffene Bereiche identifizieren
• Qualitätssicherung: Lücken in der Abdeckung erkennen
• Audit-Nachweis: Für regulatorische Anforderungen und Zertifizierungen

Traceability Matrix Beispiel:

Anforderungs-ID	Anforderung	Design-ID	Code-Komponente	Testfall-ID	Status
REQ-001	Benutzerregistrierung	ARCH-015	UserService.java	TEST-087	✅
REQ-002	Passwort-Reset	ARCH-016	PasswordService.java	TEST-088	✅
REQ-003	Produktkatalog	ARCH-017	ProductService.java	TEST-089	❌

Sehr beliebt bei IHK Prüfungen für Fachinformatiker für Anwendungsentwickler

Warum das erweiterte Wasserfallmodell bei IHK-Prüfungen so wichtig ist:

1. Strukturierte Vorgehensweise

Die IHK prüft ob Kandidaten systematisch und strukturiert arbeiten können. Das erweiterte Wasserfallmodell bietet genau diese Struktur mit klaren Phasen und Verantwortlichkeiten.

2. Qualitätsbewusstsein

Qualitätssicherung ist ein zentrales Thema bei der IHK. Das erweiterte Wasserfallmodell integriert QS-Maßnahmen in jeder Phase (Reviews, Tests, Prototypen).

3. Dokumentationspflicht

Die IHK verlangt lückenlose Dokumentation. Das Modell erzeugt nachweisbare Artefakte in jeder Phase (Lastenheft, Pflichtenheft, Testprotokolle).

4. Risikomanagement

Fachinformatiker müssen Risiken erkennen und bewerten können. Das erweiterte Wasserfallmodell bietet formalisierte Risikominimierung durch Prototypen und Reviews.

5. Änderungsmanagement

In der Praxis müssen Änderungen professionell verwaltet werden. Change Requests und Impact-Analysen sind IHK-relevante Kompetenzen.

6. Nachvollziehbarkeit

Prüfer müssen nachvollziehen können warum welche Entscheidungen getroffen wurden. Baselines und Traceability bieten genau diese Nachvollziehbarkeit.

7. Praxisrelevanz

Viele mittelständische Unternehmen arbeiten noch nach wasserfallartigen Modellen. Die IHK bereitet auf reale Arbeitsbedingungen vor.

Typische IHK-Prüfungsszenarien:

• Ein Projektphasenplan erstellen und begründen
• Eine Change-Analyse durchführen und bewerten
• Eine Traceability-Matrix erstellen
• Qualitätssicherungsmaßnahmen für eine Phase definieren
• Ein Rückkopplungsszenario beschreiben und steuern

Das erweiterte Wasserfallmodell im Detail

Phasenablauf mit Rückkopplungsschleifen

    ┌─────────────────────┐
    │  1. Anforderungs-    │
    │      phase           │
    └─────────┬───────────┘
              │ Abnahme
              ▼
    ┌─────────────────────┐
    │  2. Systementwurf    │◄────────────────┐
    └─────────┬───────────┘                 │
              │ Abnahme                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  3. Architektur-    │◄────────────────┤
    │      entwurf        │                 │
    └─────────┬───────────┘                 │
              │ Abnahme                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  4. Modulentwurf     │◄────────────────┤
    └─────────┬───────────┘                 │
              │ Abnahme                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  5. Implementierung │◄────────────────┤
    └─────────┬───────────┘                 │
              │ Abnahme                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  6. Testvorbereitung│◄────────────────┤
    └─────────┬───────────┘                 │
              │ Abnahme                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  7. Testdurchführung │◄────────────────┤
    └─────────┬───────────┘                 │
              │ Abnahme                      │
              ▼                              │
    ┌─────────────────────┐                 │
    │  8. Einführung       │                 │
    └─────────────────────┘                 │
                                           │
                                           │ Kontrollierte
                                           │ Rücksprünge
                                           │ bei Fehlern
                                           └─────────────────

Detaillierte Phasenbeschreibungen

Phase 1: Anforderungsphase

Ziele: Anforderungen vollständig erfassen, spezifizieren und abnehmen

Artefakte:

• Lastenheft (Kundensicht)
• Pflichtenheft (Anbietersicht)
• Anforderungskatalog mit IDs
• Akzeptanzkriterien
• Glossar

Aktivitäten:

• Stakeholder-Interviews
• Workshops mit Fachabteilung
• Anforderungsanalyse
• Priorisierung (MoSCoW)
• Fachliche Abnahme

Qualitätssicherung:

• Anforderungs-Reviews
• Konsistenzprüfungen
• Vollständigkeitschecks
• Traceability-Matrix starten

Typische Rückkopplungen: In der Regel keine, da Startpunkt

---

Phase 2: Systementwurf

Ziele: Systemgrenzen definieren, Schnittstellen spezifizieren

Artefakte:

• Kontextdiagramm
• Schnittstellenkatalog
• Datenflussdiagramme
• Systemarchitektur (grobschlächtig)
• Technische Konzepte

Aktivitäten:

• Systemgrenzen abstecken
• Externe Schnittstellen definieren
• Datenflüsse modellieren
• Nicht-funktionale Anforderungen spezifizieren
• Technologiewahl begründen

Qualitätssicherung:

• Architektur-Reviews
• Schnittstellen-Validierung
• Performance-Schätzungen
• Sicherheitskonzepte prüfen

Typische Rückkopplungen: Unklare Anforderungen → Anforderungsphase

---

Phase 3: Architekturentwurf

Ziele: Detaillierte Architektur festlegen, technische Risiken minimieren

Artefakte:

• Komponentendiagramm
• Deployment-Diagramm
• Datenmodell (ERD)
• Qualitätsziele-Katalog
• Architektur-Entscheidungsdokument (ADR)

Aktivitäten:

• Komponenten entwerfen
• Datenmodellierung
• Qualitätsattribute definieren
• Prototypen entwickeln (UI-Spikes, Technologie-Proofs)
• Sicherheitskonzepte detaillieren

Qualitätssicherung:

• Architektur-Reviews
• Prototyp-Tests
• Performance-Benchmarks
• Security-Reviews

Typische Rückkopplungen: Technische Unklarheiten → Systementwurf

---

Phase 4: Modulentwurf

Ziele: Detaildesign für alle Module, Schnittstellenverträge finalisieren

Artefakte:

• Klassendiagramme
• Sequenzdiagramme
• Schnittstellen-Spezifikationen
• Algorithmen-Beschreibungen
• Datenbank-Schema

Aktivitäten:

• Klassen und Objekte designen
• Algorithmen spezifizieren
• Datenbank-Design
• UI-Design (Screens, Wireframes)
• Integrationskonzepte

Qualitätssicherung:

• Design-Reviews
• Code-Generierung-Tests
• Datenbank-Normalisierung
• UI-Usability-Tests

Typische Rückkopplungen: Design-Probleme → Architekturentwurf

---

Phase 5: Implementierung

Ziele: Code gemäß Spezifikation erstellen, Qualitätssicherungsmaßnahmen umsetzen

Artefakte:

• Quellcode (versioniert)
• Unit-Tests
• Code-Dokumentation
• Build-Skripte
• Deployment-Pakete

Aktivitäten:

• Programmierung nach Standards
• Code-Reviews
• Statische Code-Analyse
• Unit-Test-Entwicklung
• Continuous Integration

Qualitätssicherung:

• Code-Reviews
• Statische Analyse (SonarQube)
• Unit-Test-Abdeckung
• Coding-Standard-Konformität

Typische Rückkopplungen: Implementierungsprobleme → Modulentwurf

---

Phase 6: Testvorbereitung

Ziele: Umfassende Teststrategie erstellen, Testumgebung aufbauen

Artefakte:

• Testkonzept
• Testfälle (detailliert)
• Testdaten
• Testautomatisierungsskripte
• Testumgebungen

Aktivitäten:

• Teststrategie definieren
• Testfälle ableiten (aus Anforderungen)
• Testdaten aufbereiten
• Testautomatisierung entwickeln
• Testumgebungen aufsetzen

Qualitätssicherung:

• Testkonzept-Review
• Testfall-Abdeckungsanalyse
• Testdaten-Validierung
• Testumgebungs-Checks

Typische Rückkopplungen: Testlücken → Implementierung/Modulentwurf

---

Phase 7: Testdurchführung

Ziele: Systemqualität nachweisen, Fehler finden und beheben

Artefakte:

• Testprotokolle
• Fehlerberichte
• Testabnahme-Berichte
• Leistungsmessungen
• Sicherheits-Test-Ergebnisse

Aktivitäten:

• Modultests
• Integrationstests
• Systemtests
• Abnahmetests
• Performance-Tests

Qualitätssicherung:

• Test-Reviews
• Fehler-Analyse
• Regressionstests
• Abnahme-Checks

Typische Rückkopplungen: Systemfehler → Implementierung/Architektur

---

Phase 8: Einführung

Ziele: Produktivbetrieb starten, Nutzer schulen, Dokumentation bereitstellen

Artefakte:

• Installationsanleitung
• Benutzerhandbuch
• Administrationshandbuch
• Schulungsunterlagen
• Wartungsvertrag

Aktivitäten:

• Installation/Deployment
• Datenmigration
• Nutzerschulung
• Betriebshandbuch erstellen
• Support-Struktur aufbauen

Qualitätssicherung:

• Installations-Tests
• Migration-Validierung
• Schulungs-Feedback
• Support-Readiness-Checks

Typische Rückkopplungen: Betriebsprobleme → Testdurchführung

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

1. Anforderungsphase (Lasten-/Pflichtenheft, Akzeptanzkriterien)
2. Systementwurf (Kontext, Schnittstellen, Datenmodell)
3. Architekturentwurf (Qualitätsziele, Entscheidungen, Prototypen)
4. Modulentwurf (Detaildesign, Schnittstellenverträge)
5. Implementierung (Reviews, statische Analyse)
6. Testvorbereitung (Testkonzept, Testfälle, Testdaten)
7. Testdurchführung (Modul/Integration/System/Abnahme)
8. Einführung (Migration, Betrieb, Handbuch)
9. Rückkopplungsschleifen (genehmigte Rücksprünge)
10. Konfigurations-/Änderungsmanagement (Versionierung)

Verifikation und Validierung im Detail

Verifikation: “Bauen wir das Produkt richtig?”

Verifikation überprüft, ob das entwickelte Produkt den Spezifikationen entspricht.

Verifikationsmethoden:

• Code-Reviews: Entspricht der Code den Coding-Standards?
• Unit-Tests: Erfüllen die Funktionen die spezifizierten Anforderungen?
• Statische Analyse: Enthält der Code bekannte Fehler oder Muster?
• Integrations-Tests: Funktionieren die Schnittstellen wie spezifiziert?
• Dokumentations-Reviews: Ist die Dokumentation vollständig und korrekt?

Verifikationsbeispiel:

Spezifikation: "Die Passwortfunktion muss 8-20 Zeichen akzeptieren"
Verifikation: Unit-Test prüft Grenzwerte 7, 8, 20, 21 Zeichen
Ergebnis: ✅ Spezifikation korrekt implementiert

Validierung: “Bauen wir das richtige Produkt?”

Validierung überprüft, ob das entwickelte Produkt den tatsächlichen Bedürfnissen der Nutzer entspricht.

Validierungsmethoden:

• Akzeptanztests: Erfüllt das System die Geschäftsanforderungen?
• Usability-Tests: Können Nutzer das System intuitiv bedienen?
• Beta-Tests: Reagieren echte Nutzer wie erwartet?
• Performance-Tests: Erreicht das System die geforderte Leistung?
• Security-Tests: Ist das System sicher genug für den Einsatz?

Validierungsbeispiel:

Anforderung: "Nutzer müssen sich schnell und einfach einloggen können"
Validierung: 50 Testnutzer führen Login-Task durch (Messung: <3 Sekunden)
Ergebnis: ✅ Nutzerakzeptanz erreicht, Bedürfnis erfüllt

V-Modell: Verbindung von Verifikation und Validierung

Anforderungserhebung ←───────────────── Abnahmetest (Validierung)
        ↓                                    ↑
Systementwurf ←───────────────────── Systemtest (Validierung)
        ↓                                    ↑
Architekturentwurf ←─────────── Integrationstest (Verifikation)
        ↓                                    ↑
Modulentwurf ←───────────────────── Modultest (Verifikation)
        ↓                                    ↑
Implementierung ────────────────────────

Umfassendes Praxisbeispiel: E-Commerce Plattform

Projektübersicht

Ziel: Entwicklung einer E-Commerce-Plattform mit externen Zahlungssystemen Team: 8 Personen (2 PM, 2 Architekten, 4 Entwickler) Dauer: 6 Monate Budget: 450.000€

Phase 1: Anforderungsphase (4 Wochen)

Artefakte erstellt:

Lastenheft (Kunde):
- 150 User Stories mit Akzeptanzkriterien
- 23 Nicht-funktionale Anforderungen
- 12 Integrationsschnittstellen

Pflichtenheft (Anbieter):
- Detaillierte Spezifikationen
- Technische Rahmenbedingungen
- Zeit- und Kostenplanung

Traceability-Matrix:
REQ-001 → ARCH-015 → TEST-087
REQ-045 → INTF-003 → TEST-156
...

Gate-Kriterien:

• ✅ Alle Anforderungen priorisiert (MoSCoW)
• ✅ Fachabnahme durch 3 Stakeholder
• ✅ Traceability-Matrix vollständig
• ✅ Risikoanalyse erstellt

Ergebnis: Phase abgenommen, 2 Change Requests dokumentiert

---

Phase 2: Systementwurf (3 Wochen)

Artefakte erstellt:

Kontextdiagramm:
- 8 externe Systeme (Payment, CRM, ERP, etc.)
- 3 User-Rollen (Customer, Admin, Partner)

Schnittstellenkatalog:
- REST API: 47 Endpunkte
- SOAP: 3 Legacy-Schnittstellen
- Message Queue: 12 Event-Typen

Datenflussdiagramme:
- Bestellprozess (7 Schritte)
- Zahlungsabwicklung (4 Schritte)
- Inventur-Sync (täglich)

Prototyp-Entscheidung: UI-Prototyp für Bestellprozess entwickelt → Nutzerfeedback positiv

Gate-Kriterien:

• ✅ Alle externen Schnittstellen spezifiziert
• ✅ Performance-Anforderungen definiert (<2s Ladezeit)
• ✅ Security-Konzept erstellt
• ✅ Technologie-Stack festgelegt (React, Node.js, PostgreSQL)

Rückkopplung: 1 unklare Anforderung → zurück zu Phase 1

---

Phase 3: Architekturentwurf (3 Wochen)

Artefakte erstellt:

Komponentendiagramm:
- Frontend: React SPA
- Backend: 6 Microservices
- Database: PostgreSQL + Redis Cache
- Message Queue: RabbitMQ

Qualitätsziele:
- Performance: <2s Antwortzeit
- Verfügbarkeit: 99.9%
- Skalierbarkeit: 10.000 gleichzeitige Nutzer
- Security: OWASP Top 10 abgedeckt

ADR (Architecture Decision Records):
ADR-001: Microservice-Architektur gewählt
ADR-003: Event-Driven für Asynchronität
ADR-007: CQRS für komplexe Abfragen

Technische Prototypen:

• Payment-Integration (Spike: 3 Tage)
• Performance-Test (Load: 5.000 Nutzer)
• Security-Test (Penetrationstest)

Gate-Kriterien:

• ✅ Architektur-Review bestanden
• ✅ Performance-Benchmarks erreicht
• ✅ Security-Review bestanden
• ✅ Prototypen erfolgreich

---

Phase 4: Modulentwurf (2 Wochen)

Artefakte erstellt:

Klassendiagramme:
- User Service: 12 Klassen
- Order Service: 18 Klassen
- Payment Service: 8 Klassen

Schnittstellen-Spezifikationen:
- Internal API: 67 Methoden
- External API: 47 Endpunkte
- Database Schema: 23 Tabellen

UI-Design:
- 47 Wireframes
- 23 High-Fidelity Mockups
- Responsive Design (Mobile/Desktop)

Qualitätssicherung:

• Design-Reviews mit Senior-Entwicklern
• Database-Normalisierung (3NF)
• UI-Usability-Tests mit 5 Nutzern

---

Phase 5: Implementierung (8 Wochen)

Artefakte erstellt:

Quellcode:
- 45.000 Zeilen Code
- 237 Unit-Tests (92% Abdeckung)
- 47 Integration-Tests

CI/CD Pipeline:
- Automated Builds
- Code Quality Checks (SonarQube)
- Automated Testing
- Deployment to Staging

Qualitätsmetriken:

• Code Coverage: 92%
• SonarQube Quality Gate: ✅ Passed
• Build Time: 4 Minuten
• Test Execution: 8 Minuten

Rückkopplung: 2 Performance-Probleme → zurück zu Phase 4

---

Phase 6: Testvorbereitung (2 Wochen)

Artefakte erstellt:

Testkonzept:
- 4 Teststufen (Unit/Integration/System/Acceptance)
- 3 Testumgebungen (Dev/Staging/Prod)
- Testautomatisierung: Selenium + Cypress

Testfälle:
- 345 Funktionale Tests
- 67 Performance-Tests
- 23 Security-Tests
- 12 Usability-Tests

Testdaten:
- 1.200 synthetische Kunden
- 5.000 Testprodukte
- 800 Testbestellungen

---

Phase 7: Testdurchführung (4 Wochen)

Testergebnisse:

Modultests: 237/237 ✅ (100%)
Integrationstests: 45/47 ✅ (96%)
Systemtests: 89/95 ✅ (94%)
Performance-Tests: 22/23 ✅ (96%)
Security-Tests: 20/23 ❌ (87%)

Gefundene Fehler:
- Critical: 2 (Security-Lücken)
- Major: 8 (Funktionsfehler)
- Minor: 15 (UI-Probleme)

Rückkopplungen:

• Security-Lücken → zurück zu Phase 3 (Architektur)
• Performance-Problem → zurück zu Phase 4 (Design)

---

Phase 8: Einführung (2 Wochen)

Artefakte erstellt:

Deployment:
- Docker Container
- Kubernetes Konfiguration
- Monitoring (Prometheus + Grafana)
- Logging (ELK Stack)

Dokumentation:
- Installationsanleitung (45 Seiten)
- Benutzerhandbuch (120 Seiten)
- Admin-Handbuch (80 Seiten)
- API-Dokumentation (OpenAPI 3.0)

Schulung:
- 12 Administrator-Schulungen
- 45 Benutzer-Trainings
- 8 Support-Handbücher

Go-Live-Ergebnis:

• ✅ Deployment erfolgreich
• ✅ Datenmigration abgeschlossen
• ✅ Nutzer geschult
• ✅ Monitoring aktiv

---

Projekt-Zusammenfassung

Erfolge:

• ✅ Zeitplan eingehalten (+2 Wochen Puffer)
• ✅ Budget eingehalten (+5%)
• ✅ Qualitätsziele erreicht
• ✅ Nutzerakzeptanz: 87%

Herausforderungen:

• 3 größere Rückkopplungen (Phasen 3, 4, 7)
• 2 Change Requests während Entwicklung
• 1 Security-Problem in letzter Minute

Gelernte Lektionen:

• Frühzeitige Prototypen reduzieren Risiken
• Regelmäßige Reviews sind entscheidend
• Traceability spart viel Zeit bei Fehlersuche

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

Traceability und Requirements Management

Traceability Matrix erstellen

Zweck: Sicherstellen, dass jede Anforderung implementiert und getestet wird.

Beispiel Traceability Matrix:

Anforderungs-ID	Anforderungstext	Design-Element	Code-Komponente	Testfall	Status
REQ-001	Benutzerregistrierung mit E-Mail-Validierung	UserRegistrationController	UserRegistrationService	TEST-001, TEST-002	✅
REQ-015	Passwort-Reset-Funktion	PasswordResetController	PasswordResetService	TEST-045, TEST-046	✅
REQ-023	Produktkatalog mit Filterung	ProductCatalogController	ProductService	TEST-089, TEST-090	❌
REQ-034	Warenkorb-Funktion	ShoppingCartController	CartService	TEST-123, TEST-124	✅

Traceability-Tools:

• Requirements Management Tools: JIRA, Polarion, DOORS
• Test Management Tools: TestRail, Zephyr, Xray
• Excel/Google Sheets: Für kleine Projekte
• Custom Solutions: Traceability-Scripts

Traceability-Prozess

1. Anforderung erfassen → REQ-XXX
2. Design zuordnen → ARCH-XXX
3. Implementierung verlinken → CODE-XXX
4. Testfälle ableiten → TEST-XXX
5. Abnahme dokumentieren → STATUS: ✅/❌
6. Abweichungen analysieren → Change Request

Change Management und Baselines

Baselines definieren

Baseline: Festgeschriebener Zustand von Artefakten zu einem bestimmten Zeitpunkt.

Arten von Baselines:

• Requirements Baseline: Genehmigte Anforderungen
• Design Baseline: Freigegebene Entwurfsdokumente
• Code Baseline: Stabile Code-Version
• Test Baseline: Akzeptierte Testergebnisse

Change Request Prozess

Change Request eingeben
        ↓
Impact-Analyse durchführen
        ↓
Change Advisory Board (CAB) bewertet
        ↓
Entscheidung: Genehmigt/Ablehnung
        ↓
Bei Genehmigung:
  - Baseline aktualisieren
  - Traceability anpassen
  - betroffene Phasen informieren
  - Tests durchführen

Change Request Template:

CR-2024-001
Titel: Änderung der Passwort-Richtlinie
Begründung: Neue Sicherheitsanforderungen
Auswirkungen:
- REQ-015: Passwort-Komplexität erhöhen
- ARCH-007: Password Validator anpassen
- TEST-045: Neue Testfälle hinzufügen
Kostenschätzung: 8 Stunden
Priorität: Hoch
Genehmigt: ✅

Vergleich mit anderen Vorgehensmodellen

Klassisches Wasserfall vs. Erweitertes Wasserfall

Kriterium	Klassisches Wasserfall	Erweitertes Wasserfall
Rückkopplungen	Keine	Kontrollierte Rücksprünge
Fehlerentdeckung	Spät (Testphase)	Früh (Prototypen/Reviews)
Flexibilität	Sehr gering	Moderat
Planungsaufwand	Gering	Hoch
Risikomanagement	Begrenzt	Umfassend
Dokumentation	Umfassend	Sehr umfassend

Wasserfall vs. V-Modell

Wasserfallmodell:
Anforderung → Entwurf → Implementierung → Test → Einführung
    ↓
    ↑
   (Keine direkte Verbindung)

V-Modell:
Anforderungserhebung ←─────── Abnahmetest
        ↓                      ↑
Systementwurf ←─────── Systemtest
        ↓                      ↑
Architekturentwurf ←─── Integrationstest
        ↓                      ↑
Modulentwurf ←─────── Modultest
        ↓                      ↑
Implementierung ────────────────

Wasserfall vs. Agile Methoden

Aspekt	Wasserfall	Agile (Scrum/Kanban)
Planung	Upfront, detailliert	Iterativ, adaptiv
Änderungen	Teuer, formell	Einfach, willkommen
Risiko	Hoch (am Ende)	Niedrig (früh)
Transparenz	Phasenbasiert	Kontinuierlich
Kundenfeedback	Am Ende	Jede Iteration
Teamstruktur	Silos	Cross-funktional

Wann das erweiterte Wasserfallmodell geeignet ist

✅ Geeignet für:

• Regulierte Branchen (Medizintechnik, Automotive, Luftfahrt)
• Sicherheitskritische Systeme
• Projekte mit stabilen Anforderungen
• Government- und Behördenprojekte
• Systeme mit hohen Compliance-Anforderungen

❌ Weniger geeignet für:

• Stark volatile Märkte
• Startups mit häufigen Pivotierungen
• Projekte mit unklaren Anforderungen
• Kleine, experimentelle Projekte
• User-zentrierte Produkte mit häufigen UX-Änderungen

Typische Prüfungsfragen (mit Kurzantwort)

1. Unterschied klassischer vs. erweiterter Wasserfall? Erweitert = definierte Rücksprünge + frühe QS/Prototypen.

2. Rolle von Prototypen? Risiken früh validieren (Performance, Security, UX).

3. Verifikation vs. Validierung? Verifikation gegen Spezifikation, Validierung gegen Zweck/Nutzen.

4. Wie steuert man Rücksprünge? Gate-Entscheidung, Impactanalyse, Change Request, erneute Abnahme.

5. Was ist eine Baseline? Festgeschriebener Zustand von Artefakten zu einem bestimmten Zeitpunkt.

6. Traceability-Zweck? Sicherstellen, dass jede Anforderung implementiert und getestet wird.

7. Change Request Prozess? Impact-Analyse → CAB-Bewertung → Genehmigung → Umsetzung.

8. Vorteile gegenüber klassischem Wasserfall? Frühere Fehlerentdeckung, bessere Risikokontrolle, höhere Qualität.

9. Nachteile gegenüber agilen Methoden? Weniger flexibel, höherer Planungsaufwand, spätes Kundenfeedback.

10. Wann Prototypen einsetzen? Bei technischen Risiken, unklaren Anforderungen, komplexen UIs.

Lernstrategie

1. Phasen mit Artefakten und Abnahmekriterien visualisieren

Methode: Erstelle eine detaillierte Phasenübersicht mit allen relevanten Artefakten und Gate-Kriterien.

Praktische Übung:

Phase 1: Anforderungsphase
├── Artefakte: Lastenheft, Pflichtenheft, Anforderungskatalog
├── Aktivitäten: Stakeholder-Interviews, Workshops, Priorisierung
├── QS-Maßnahmen: Anforderungs-Reviews, Konsistenzprüfungen
└── Gate-Kriterien: ✅ Alle Anforderungen priorisiert, ✅ Fachabnahme

Lernziel: Du verstehst welche Artefakte in welcher Phase entstehen und wie die Qualitätssicherung funktioniert.

2. Rücksprung-Szenario detailliert durchspielen

Methode: Dokumentiere ein komplettes Rückkopplungsszenario von der Fehlerentdeckung bis zur erneuten Abnahme.

Praktisches Beispiel:

Szenario: Integrationstest fehlschlägt
├── Fehlerentdeckung: Integrationstest Phase 7
├── Fehleranalyse: Performance-Problem im Datenbankzugriff
├── Impact-Analyse: Betroffene Komponenten identifizieren
├── Change Request: CR-2024-001 erstellen und genehmigen
├── Rückkopplung: Zurück zu Phase 4 (Modulentwurf)
├── Korrektur: Datenbank-Design optimieren
├── Neue Tests: Performance-Tests ergänzen
└── Erneute Abnahme: Phase 7 erfolgreich bestanden

Lernziel: Du verstehst wie Rückkopplungen kontrolliert ablaufen und welche Schritte notwendig sind.

3. Vorgehensmodell-Vergleich systematisch durchführen

Methode: Erstelle eine Vergleichsmatrix der wichtigsten Vorgehensmodelle mit konkreten Kriterien.

Vergleichsmatrix ausfüllen:

Kriterium	Klassisches Wasserfall	Erweitertes Wasserfall	V-Modell	Scrum
Phasenablauf	Linear	Linear mit Rücksprüngen	V-förmig	Iterativ
Flexibilität	Sehr gering	Moderat	Gering	Sehr hoch
Risikomanagement	Spät	Früh (Prototypen)	Früh	Kontinuierlich
Dokumentation	Umfassend	Sehr umfassend	Umfassend	Minimal
Kundenfeedback	Am Ende	Zwischenphasen	Zwischenphasen	Jede Iteration

Lernziel: Du kannst die Vor- und Nachteile jedes Modells begründen und das passende Modell auswählen.

4. Praktische Traceability-Tabelle erstellen

Methode: Erstelle eine vollständige Traceability-Matrix für ein kleines Projektbeispiel.

Projektbeispiel: Benutzerregistrierungssystem

Anforderungen erfassen:
REQ-001: Benutzer soll sich mit E-Mail und Passwort registrieren
REQ-002: Passwort muss 8-20 Zeichen lang sein
REQ-003: E-Mail muss validiert werden
REQ-004: Doppelte E-Mail-Adressen müssen verhindert werden

Design zuordnen:
ARCH-001: UserRegistrationController
ARCH-002: PasswordValidator
ARCH-003: EmailService
ARCH-004: UserRepository

Implementierung verlinken:
CODE-001: UserRegistrationService.java
CODE-002: PasswordValidator.java
CODE-003: EmailValidator.java
CODE-004: UserRepository.java

Testfälle ableiten:
TEST-001: Registrierung mit gültigen Daten
TEST-002: Registrierung mit zu kurzem Passwort
TEST-003: Registrierung mit ungültiger E-Mail
TEST-004: Registrierung mit existierender E-Mail

Lernziel: Du verstehst wie die durchgehende Verfolgbarkeit sichergestellt wird und warum sie wichtig ist.

5. Change Management praktizieren

Methode: Simuliere einen Change Request für ein laufendes Projekt.

Übungsszenario:

Ausgangslage: Projekt ist in Phase 5 (Implementierung)
Änderungswunsch: Zusätzliche Funktion "Social Login" hinzufügen

Durchführung:
1. Change Request Formular ausfüllen
2. Impact-Analyse durchführen:
   - Technische Auswirkungen: OAuth2-Integration nötig
   - Zeitliche Auswirkungen: +2 Wochen Entwicklungszeit
   - Kostenmäßige Auswirkungen: +8.000€
3. Risiken bewerten: Sicherheit der OAuth2-Integration
4. Entscheidung treffen: Genehmigt mit zusätzlichen Security-Tests
5. Baselines aktualisieren und Traceability anpassen

Lernziel: Du kannst Änderungsprozesse professionell durchführen und dokumentieren.

6. Prüfungs-spezifische Vorbereitung

Methode: Bereite dich auf typische IHK-Fragen mit strukturierten Antworten vor.

Typische Prüfungsfragen üben:

• “Beschreiben Sie die Phasen des erweiterten Wasserfallmodells mit den wichtigsten Artefakten.”
• “Erklären Sie den Unterschied zwischen Verifikation und Validierung an einem praktischen Beispiel.”
• “Wie führen Sie eine Impact-Analyse für eine Anforderungsänderung durch?”
• “Welche Rolle spielen Prototypen im erweiterten Wasserfallmodell?”

Antwortstruktur trainieren:

1. Definition/Konzept erklären
2. Praktisches Beispiel geben
3. Vorteile/Nachteile aufzeigen
4. IHK-relevante Aspekte betonen

7. Zeitplan für die Prüfungsvorbereitung

Empfohlene Lernphasen:

Woche 1: Grundlagen verstehen

• Phasen und Artefakte lernen
• Verifikation vs. Validierung meistern
• Basis-Begriffe wiederholen

Woche 2: Vertiefung

• Rückkopplungsszenarien durchspielen
• Change Management üben
• Traceability praktizieren

Woche 3: Anwendung

• Praxisbeispiele analysieren
• Vergleich mit anderen Modellen
• Prüfungsfragen beantworten

Woche 4: Wiederholung

• Alle Konzepte revisitieren
• Schwachstellen identifizieren
• Prüfungssimulation durchführen

Lern-Tipp: Konzentriere dich auf die IHK-relevanten Aspekte: Struktur, Dokumentation, Qualitätssicherung und Nachvollziehbarkeit.

Wichtigste Quellen

1. https://de.wikipedia.org/wiki/Wasserfallmodell
2. https://dl.acm.org/doi/10.1145/360248.360251

Typische Prüfungsfragen, die Dir ein Prüfer stellen könnte