1. Vorgehensmodelle I – Phasenorientierte Modelle

Nach diesem Kapitel kannst du:

die vier typischen Probleme eines Projekts ohne Vorgehen nennen und die vier Mittel, mit denen jedes Vorgehensmodell gegensteuert.
Wasserfall und V-Modell mit ihren Phasen bzw. Stufen erklären und sagen, wann jedes der beiden Modelle Rückmeldung erzeugt.
Stärken und Schwächen von Wasserfall und V-Modell gegenüberstellen und begründen, warum das V-Modell nur den Testteil des Wasserfalls verbessert.
Verifikation von Validierung unterscheiden und im V-Modell jeder Entwurfsstufe ihre Teststufe zuordnen.

Softwareprojekte scheitern selten daran, dass niemand programmieren kann. Sie scheitern daran, dass am Ende etwas anderes dasteht als gebraucht wurde, dass niemand rechtzeitig gemerkt hat, wie weit man zurückliegt, oder dass drei Personen dieselbe Sache dreimal verschieden gebaut haben. Ein Vorgehensmodell ist der Versuch, genau das zu verhindern.

Stell dir eine lange Autofahrt in eine Stadt vor, in der du noch nie warst. Du kannst die Route am Vorabend vollständig auf der Karte festlegen und dich dann strikt daran halten. Oder du lässt ein Navi fahren, das alle paar Minuten deine Position prüft und bei Stau oder Sperre neu berechnet. Beide kommen an, aber sie erfahren zu sehr unterschiedlichen Zeitpunkten, dass etwas schiefläuft. Genau dieser Zeitpunkt der Rückmeldung zieht sich als roter Faden durch dieses und die beiden folgenden Kapitel.

Zwei Fahrten zum selben Ziel: Bei der am Vorabend festgelegten Route fällt eine Sperre erst auf, wenn man davorsteht. Das Navi prüft laufend, erkennt die Sperre früh und plant um.

Die ehrliche Antwort auf „Welches Vorgehensmodell ist das beste?” lautet: keines. Es gibt nur mehr oder weniger passende Antworten auf eine konkrete Projektsituation. Diese Auswahl begründen zu können ist die eigentliche Kompetenz, um die es hier geht.

Begriffe vorab

Vorgehensmodell (software process model): legt fest, in welcher Reihenfolge gearbeitet wird, wer wann was entscheidet und woran man erkennt, dass ein Schritt fertig ist.
Phase: ein abgegrenzter Arbeitsabschnitt mit eigenem Ziel und eigenem Ergebnis, z. B. Anforderungsanalyse oder Test.
Artefakt (artifact): ein greifbares Arbeitsergebnis, z. B. Pflichtenheft, Quellcode, Testprotokoll oder Backlog.
Auftraggeber: die Person oder Organisation, für die die Software gebaut wird und die sie am Ende abnimmt.
Stakeholder: alle, die vom Ergebnis betroffen sind oder darauf Einfluss haben - Auftraggeber, spätere Nutzer:innen, Fachabteilung, Betrieb.
Iteration und Inkrement: eine Arbeitsrunde bzw. ein fertig geliefertes Stück. Der genaue Unterschied folgt in Kapitel 02 im Abschnitt „Iterativ und inkrementell”.

Das Problem, das alle Modelle lösen wollen

Stell dir ein Projekt ohne jedes Vorgehen vor: Alle fangen an, irgendwo zu programmieren. Vorhersehbar passiert Folgendes.

Zwei Personen bauen dieselbe Funktion, eine dritte baut sie gegen eine andere Annahme.
Der Auftraggeber sieht das Ergebnis erstmals nach drei Monaten und stellt fest, dass er etwas anderes gemeint hat.
Niemand kann sagen, ob das Projekt zu 30 oder zu 80 Prozent fertig ist, weil „fertig” nirgends definiert ist.
Zwei Wochen vor dem Termin fällt auf, dass sich niemand die Datenübernahme aus dem Altsystem angesehen hat.

Jedes Vorgehensmodell setzt gegen diese vier Probleme dieselben vier Mittel ein: Reihenfolge, Zuständigkeit, Zwischenergebnisse und Rückmeldung. Die Modelle unterscheiden sich vor allem darin, wie früh und wie oft sie diese Mittel einsetzen.

flowchart LR
  P1["Zwei bauen dasselbe"] --> M1["Zuständigkeit"]
  P2["Auftraggeber sieht erst spät etwas"] --> M2["Rückmeldung"]
  P3["Fortschritt unklar"] --> M3["Zwischenergebnisse"]
  P4["Datenübernahme vergessen"] --> M4["Reihenfolge"]

Jedes der vier Probleme hat sein Gegenmittel: Klare Zuständigkeit verhindert doppelte Arbeit, frühe Rückmeldung verhindert die Überraschung am Ende. Definierte Zwischenergebnisse machen den Fortschritt messbar, eine geplante Reihenfolge sorgt dafür, dass keine Aufgabe übersehen wird.

Wo begegnet dir das? Im Gruppenprojekt aus dem 4. Jahrgang, bei dem am Vorabend der Abgabe die Teile zum ersten Mal zusammengesteckt wurden und nicht zusammenpassten. Das war kein Pech, sondern ein Projekt ohne vereinbarte Zwischenergebnisse.

Wasserfall

Das älteste beschriebene Modell: Die Phasen laufen streng nacheinander, jede endet mit einem Dokument, das die nächste Phase als Eingabe nutzt. In der Analogie ist das die Route, die am Vorabend vollständig auf der Karte festgelegt wird.

flowchart TD
  A[Anforderungsanalyse] --> B[Entwurf]
  B --> C[Implementierung]
  C --> D[Test]
  D --> E[Betrieb und Wartung]

Die Phasen und ihre Ergebnisse

Phase	Was darin passiert	Ergebnis für die nächste Phase
Anforderungsanalyse	mit dem Auftraggeber klären, was die Software leisten muss	Lasten- und Pflichtenheft
Entwurf	festlegen, wie gebaut wird: Architektur, Module, Schnittstellen, Datenmodell	Entwurfsdokument
Implementierung	die entworfenen Module programmieren	Quellcode
Test	prüfen, ob das Gebaute der Spezifikation entspricht	Testprotokoll, Abnahme
Betrieb und Wartung	Einsatz beim Kunden, Fehlerbehebung, kleine Änderungen	laufendes System

Die Idee dahinter ist nicht dumm. Sie stammt aus einer Zeit, in der Rechenzeit teuer und Änderungen am fertigen Programm extrem aufwendig waren: erst denken, dann tippen.

Stärken und Schwächen

Stärken	Schwächen
Planbar: Termine, Kosten und Umfang stehen früh fest	Setzt voraus, dass die Anforderungen von Anfang an bekannt und stabil sind
Gut für Verträge und Ausschreibungen geeignet	Fehler in der Analyse fallen erst im Test auf - dann ist die Korrektur am teuersten
Klare Zuständigkeiten und Dokumentenlage	Der Auftraggeber sieht sehr lange nichts Lauffähiges
Nachvollziehbar für Außenstehende und Prüfer	Keine Möglichkeit, aus Zwischenergebnissen zu lernen

Der Zeitpunkt der Erkenntnis

Das entscheidende Argument gegen den reinen Wasserfall ist der Zeitpunkt, an dem ein Fehler auffällt. Ein Missverständnis in der Analyse kostet in der Analyse Minuten, im Entwurf Stunden, in der Implementierung Tage und nach der Auslieferung möglicherweise das Projekt. Ein Vorgehen, das erst am Ende Rückmeldung erzeugt, sammelt genau diese Missverständnisse an. In der Analogie: Die gesperrte Brücke auf der Papierroute bemerkst du erst, wenn du davorstehst.

Diese Beobachtung ist mehr als eine Anekdote. Barry Boehm maß bereits in den 1970er-Jahren an großen Softwareprojekten, wie stark die Kosten für dieselbe Korrektur von Phase zu Phase steigen - grob im zweistelligen Faktor zwischen Anforderungsphase und Betrieb. Die genauen Zahlen schwanken je nach Studie und Projektart, das Prinzip gilt aber bis heute als Konsens der Softwaretechnik.

Wo begegnet dir das? Bei Software, die vor dem Einsatz eine formale Zulassung braucht, etwa in Medizingeräten oder Bahnsteuerungen. Dort muss vor dem Bau nachweisbar feststehen, was das System tun soll, und jede spätere Änderung durchläuft die Prüfung erneut.

V-Modell

Das V-Modell ist ein aufgeklappter Wasserfall: Es stellt jeder Entwurfsstufe die passende Teststufe gegenüber.

flowchart LR
  A[Anforderungen] --> B[Grobentwurf]
  B --> C[Feinentwurf]
  C --> D[Implementierung]
  D --> E[Modultest]
  E --> F[Integrationstest]
  F --> G[Abnahmetest]
  A -.->|prueft| G
  B -.->|prueft| F
  C -.->|prueft| E

Welche Ebene prüft was?

Die gestrichelten Linien sind der ganze Trick: Jedes Dokument der linken Seite ist der Maßstab für einen Test der rechten Seite. Wer die Ebenen nicht kennt, kann die Zuordnung auch nicht begründen.

Entwurfsstufe (links)	legt fest	Teststufe (rechts)	prüft
Anforderungen	was das System aus Sicht des Auftraggebers können muss	Abnahmetest	ob das fertige System genau das tut - beurteilt vom Auftraggeber
Grobentwurf	welche Bausteine es gibt (Module, Dienste, Datenbank) und wie sie zusammenspielen	Integrationstest	ob die Bausteine im Zusammenspiel funktionieren, besonders an den Schnittstellen
Feinentwurf	wie ein einzelner Baustein innen aufgebaut ist: Klassen, Methoden, Algorithmen	Modultest	ob der einzelne Baustein für sich korrekt arbeitet

Technisch werden diese Teststufen in Kapitel 19 behandelt, hier zählt die Zuordnung.

Was sich gegenüber dem Wasserfall ändert und was gleich bleibt

Im Wasserfall ist Test eine einzige Phase am Ende. Im V-Modell entsteht jeder Test bereits gemeinsam mit dem Dokument, gegen das er später prüft: Der Abnahmetest wird formuliert, während die Anforderungen entstehen, nicht erst nach der Implementierung.

Das klingt nach Buchhaltung und ist in Wahrheit ein Prüfwerkzeug für die Spezifikation selbst. Die Frage „Wie würden wir das testen?” entlarvt unbrauchbare Anforderungen sofort: „Die Software soll benutzerfreundlich sein” lässt sich nicht testen, „ein neuer Benutzer legt ohne Schulung in unter drei Minuten einen Auftrag an” schon.

	Wasserfall	V-Modell
Ablauf	sequenziell, phasenorientiert	sequenziell, phasenorientiert
Test	eine Phase am Ende	eine Teststufe pro Entwurfsstufe
Testfälle entstehen	nach der Implementierung	gemeinsam mit dem jeweiligen Entwurfsdokument
Anforderungen	müssen früh stabil sein	müssen früh stabil sein
Lauffähige Software	erst spät	erst spät

Die Tabelle zeigt, was für die Beurteilung genauso wichtig ist: Die Schwächenspalte des Wasserfalls gilt fast unverändert weiter. Das V-Modell repariert also nicht den Wasserfall, sondern nur dessen Testteil.

Verifikation und Validierung

Aus der Zuordnung folgen zwei Begriffe, die gern verwechselt werden:

Verifikation: Bauen wir das Produkt richtig? (Erfüllt der Code die Spezifikation?)
Validierung: Bauen wir das richtige Produkt? (Löst die Spezifikation das Problem des Auftraggebers?)

Ein Programm kann vollständig verifiziert und trotzdem wertlos sein, dann war die Spezifikation falsch. Konkret heißt das: Eine Kassensoftware berechnet exakt nach der übergebenen Spezifikation 25 % statt 20 % Mehrwertsteuer, weil sich jemand bei der Anforderungsaufnahme vertippt hat. Jeder Test gegen diese falsche Spezifikation ist grün - das Programm ist perfekt verifiziert.

Trotzdem ist es nicht validiert, weil es das eigentliche Problem, die korrekte Steuerberechnung, nicht löst. Diese Lücke schließt das V-Modell nicht. Es macht sie aber sichtbar, indem es für jede Ebene einen eigenen Prüfmaßstab verlangt.

Wo begegnet dir das? In der deutschen Bundesverwaltung war mit dem V-Modell XT lange eine Weiterentwicklung des V-Modells als Standard für IT-Projekte empfohlen. Im Kleinen begegnet dir dieselbe Frage in jeder Diplomarbeit: Der Abnahmetest mit dem Auftraggeber prüft die Validierung, deine Unit-Tests prüfen die Verifikation.

Auflösung

Zum Beispiel: „Nach dem Antippen einer Lektion ist deren erste Seite auf einem Mittelklasse-Handy im Schul-WLAN in höchstens zwei Sekunden vollständig sichtbar.” Entscheidend sind eine messbare Größe, eine Grenze und definierte Bedingungen. Weil es eine Anforderung aus Sicht des Auftraggebers ist, prüft sie der Abnahmetest.

Zusatzmaterialien

Winston W. Royce, Managing the Development of Large Software Systems (1970) - lohnt sich, weil der angebliche Ursprung des Wasserfallmodells selbst schon vor dessen rückkopplungsfreier Form warnt.
Wikipedia: V-Modell - vertieft die Teststufen und Begriffe, auf die Kapitel 19 aufbaut.

Zum Anhören

Diesen Text kannst du dir kostenlos mit der Vorlesefunktion deines Browsers oder Betriebssystems vorlesen lassen, z. B. in Microsoft Edge über „Laut vorlesen”.

Lernergebnisse: Was du nach diesem Kapitel können solltest

Nennen: die vier typischen Probleme eines Projekts ohne Vorgehen nennen und die vier Mittel, mit denen jedes Vorgehensmodell gegensteuert.
Erklären: Wasserfall und V-Modell mit ihren Phasen bzw. Stufen erklären und sagen, wann jedes der beiden Modelle Rückmeldung erzeugt.
Analysieren: Stärken und Schwächen von Wasserfall und V-Modell gegenüberstellen und begründen, warum das V-Modell nur den Testteil des Wasserfalls verbessert.
Erklären: Verifikation von Validierung unterscheiden und im V-Modell jeder Entwurfsstufe ihre Teststufe zuordnen.

Passende Übungen

Dieses Kapitel hat keine eigene Übung. Die passende Übung folgt in Kapitel 03:

Aufgabe 01 - Modell-Matrix

In den 70 Praxisminuten liest du dich in Aufgabe 01 ein und beginnst die Vergleichsmatrix mit den beiden Modellen aus diesem Kapitel, Wasserfall und V-Modell.

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules