1. Vorgehensmodelle

Vorgehensmodelle

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: Es legt fest, in welcher Reihenfolge gearbeitet wird, wer wann was entscheidet und woran man erkennt, dass ein Schritt fertig ist.

Dieses Kapitel behandelt die Modelle, die Sie kennen müssen, und vor allem die Frage dahinter: Wann taugt welches? Denn die ehrliche Antwort auf “Welches Vorgehensmodell ist das beste?” lautet: keines. Es gibt nur mehr oder weniger passende Antworten auf eine konkrete Projektsituation, und diese Auswahl begründen zu können ist die eigentliche Kompetenz.

Das Problem, das alle Modelle lösen wollen

Stellen Sie sich 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 die Datenübernahme aus dem Altsystem nie jemand angesehen hat.

Jedes Vorgehensmodell zieht gegen diese vier Probleme dieselben Register - Reihenfolge, Zuständigkeit, Zwischenergebnisse, Rückmeldung - und unterscheidet sich vor allem darin, wie früh und wie oft es sie zieht.

Wasserfall

Das älteste beschriebene Modell: Die Phasen laufen streng nacheinander, jede endet mit einem Dokument, das die nächste Phase als Eingabe nutzt.

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

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

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

Das entscheidende Argument gegen den reinen Wasserfall ist der Zeitpunkt der Erkenntnis: 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.

Trotzdem nicht ausgestorben

Wo Anforderungen tatsächlich feststehen und Änderungen unerwünscht sind, ist phasenorientiertes Vorgehen weiterhin richtig: sicherheitskritische Steuerungen, behördliche Abnahmen, Ausschreibungen mit fixem Leistungsverzeichnis. “Wasserfall ist überholt” ist eine Behauptung, keine Analyse.

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

Die gestrichelten Linien sind der ganze Trick: Jedes Dokument der linken Seite ist der Maßstab für einen Test der rechten Seite. Der Abnahmetest prüft gegen die Anforderungen, der Integrationstest gegen den Grobentwurf, der Modultest gegen den Feinentwurf. Daraus 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. Diese Lücke schließt das V-Modell nicht; es macht sie sichtbar, indem es für jede Ebene einen eigenen Prüfmaßstab verlangt.

Iterativ und inkrementell

Beide Begriffe stehen oft nebeneinander und meinen Verschiedenes:

• Inkrementell heißt: in Stücken liefern. Zuerst die Anmeldung, dann die Suche, dann der Export. Jedes Stück ist fertig, das Ganze wächst.
• Iterativ heißt: in Runden verbessern. Die Suche entsteht zuerst grob, wird in der nächsten Runde genauer, in der übernächsten schneller.

Praktisch werden beide kombiniert: Man liefert Stücke (inkrementell) und überarbeitet Geliefertes anhand von Rückmeldungen (iterativ). Der Gewinn gegenüber dem Wasserfall ist wieder der Zeitpunkt der Erkenntnis - nach jeder Runde gibt es etwas Lauffähiges, an dem sich Annahmen überprüfen lassen.

Ein verwandtes Werkzeug ist der Prototyp: eine bewusst unvollständige Version, die eine einzige Frage beantworten soll (“Lässt sich diese Schnittstelle überhaupt anbinden?”, “Verstehen die Nutzer diese Bedienung?”). Wichtig ist die Vereinbarung vorab, ob der Prototyp weggeworfen wird (throwaway) oder die Grundlage des Produkts bildet (evolutionär). Wird das nicht geklärt, landet regelmäßig ein Wegwerf-Prototyp im Produktivbetrieb - samt aller Abkürzungen, die man sich für den schnellen Bau erlaubt hat.

Agile Methoden

2001 formulierten siebzehn Softwareentwickler das Agile Manifest als Reaktion auf schwergewichtige, dokumentenlastige Prozesse. Sein Kern sind vier Wertepaare:

Wir schätzen …	… höher als
Individuen und Interaktionen	Prozesse und Werkzeuge
Funktionierende Software	umfassende Dokumentation
Zusammenarbeit mit dem Kunden	Vertragsverhandlung
Reagieren auf Veränderung	Befolgen eines Plans

Der meistzitierte und meistüberlesene Satz folgt direkt danach: “Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.” Agil heißt also nicht “keine Dokumentation” und nicht “kein Plan”, sondern eine Gewichtung bei Zielkonflikten.

Scrum

Scrum ist das verbreitetste agile Rahmenwerk und bewusst schlank gehalten: drei Verantwortlichkeiten, drei Artefakte, ein fester Zyklus.

Verantwortlichkeiten

Rolle	Aufgabe	Häufiges Missverständnis
Product Owner	verantwortet das Was: Backlog, Priorisierung, fachliche Entscheidungen	ist kein Vorgesetzter des Teams
Entwicklungsteam	verantwortet das Wie: Umsetzung, Schätzung, technische Entscheidungen	schätzt selbst; Schätzungen werden nicht vorgegeben
Scrum Master	verantwortet den Prozess: Hindernisse beseitigen, Regeln schützen	ist kein Projektleiter und kein Protokollführer

Artefakte

• Product Backlog: die geordnete Liste aller Wünsche an das Produkt; lebt und ändert sich ständig.
• Sprint Backlog: die Auswahl, die das Team für den laufenden Sprint übernommen hat.
• Increment: das lauffähige Ergebnis am Sprintende, das die Definition of Done erfüllt.

Der Zyklus

flowchart LR
  A[Sprint Planning] --> B[Sprint: 1 bis 4 Wochen]
  B --> C[Daily Scrum: taeglich 15 min]
  C --> B
  B --> D[Sprint Review: Ergebnis zeigen]
  D --> E[Retrospektive: Zusammenarbeit verbessern]
  E --> A

Der Unterschied zwischen Review und Retrospektive wird regelmäßig verwechselt und ist prüfungsrelevant: Das Review betrachtet das Produkt (gemeinsam mit den Stakeholdern), die Retrospektive die Zusammenarbeit (im Team). Wer beides zusammenlegt, verliert in der Praxis die Retrospektive - und damit die einzige Stelle, an der das Vorgehen selbst verbessert wird.

Das Daily ist kein Statusbericht

Die drei Fragen (“Was habe ich gemacht, was mache ich, was hindert mich?”) richten sich an das Team, nicht an eine vorgesetzte Person. Sobald das Daily zur Berichterstattung nach oben wird, verliert es seinen Zweck: die tägliche Selbstabstimmung und das frühe Sichtbarmachen von Hindernissen. Erkennungsmerkmal: Alle sprechen zur Lehrkraft statt zueinander.

Kanban

Kanban setzt an einer anderen Stelle an: nicht am Zeittakt, sondern am Fluss der Arbeit. Es gibt keine Sprints und keine vorgeschriebenen Rollen, sondern ein Board mit Spalten und - das ist der Kern - WIP-Limits (work in progress), also Obergrenzen für die Zahl gleichzeitig bearbeiteter Aufgaben:

Backlog | Analyse (3) | Umsetzung (2) | Review (2) | Fertig

Ist eine Spalte voll, darf nichts Neues hinein. Wer nichts anfangen darf, hilft dort, wo es klemmt. Das wirkt zunächst wie eine Behinderung und ist das Gegenteil: Zu viele parallele Aufgaben verlängern die Durchlaufzeit aller Aufgaben, weil ständig umgeschaltet wird und halbfertige Arbeit liegen bleibt.

	Scrum	Kanban
Rhythmus	feste Sprints	kontinuierlicher Fluss
Rollen	drei definierte	keine vorgeschrieben
Planung	pro Sprint	fortlaufend
Kernmechanik	Zeitbox und Commitment	WIP-Limit und Durchlaufzeit
Passt gut bei	planbarer Produktentwicklung	Support, Wartung, wechselnden Prioritäten

Die Auswahl begründen

Damit zur eigentlichen Kompetenz. Kein Modell ist immer richtig; die Wahl folgt der Projektsituation:

Kriterium	Spricht für phasenorientiert	Spricht für agil
Anforderungen	früh vollständig bekannt und stabil	unklar, im Fluss, entstehen erst im Gebrauch
Auftraggeber	nur zu Beginn und zur Abnahme verfügbar	laufend verfügbar und entscheidungsfähig
Technologie	bekannt und erprobt	neu; Risiken müssen früh erprobt werden
Team	groß, verteilt, wechselnd	klein, stabil, selbstorganisiert
Rahmen	Vertrag mit fixem Leistungsumfang	Budget- oder Zeitrahmen mit flexiblem Umfang
Fehlerfolgen	sicherheitskritisch, Zulassung nötig	wirtschaftlich, korrigierbar

In der Praxis sind die meisten Projekte Mischformen: agile Umsetzung innerhalb eines vertraglich fixierten Rahmens, oder ein phasenorientierter Gesamtplan mit iterativen Abschnitten. Wichtiger als die reine Lehre ist die Frage, ob die gewählten Elemente zusammenpassen - zweiwöchige Sprints ohne verfügbaren Product Owner ergeben Sprint Reviews ohne Publikum, und dann ist der Sprint nur ein Kalendereintrag.

Die drei häufigsten Fehlschlüsse

“Agil heißt ohne Plan.” Agile Verfahren planen häufiger, nicht weniger: jeden Sprint neu, mit dem aktuellen Wissensstand.

“Wir machen Scrum” - ohne Product Owner, ohne Retrospektive, mit vorgegebenen Schätzungen. Das ist kein Scrum, sondern der übliche Ablauf mit neuen Wörtern; die Fachliteratur nennt das Cargo-Kult.

“Das Modell garantiert Erfolg.” Kein Vorgehensmodell ersetzt fachliche Klärung, brauchbare Anforderungen und Können. Es macht Probleme nur früher sichtbar - und das ist schon viel.

Abgrenzung zum Projektmanagement

Vorgehensmodelle kommen auch im Gegenstand Projektmanagement vor, dort mit anderem Blickwinkel. Grob gilt: Das Projektmanagement betrachtet Projekte (Ziele, Termine, Ressourcen, Risiken, Stakeholder, Wirtschaftlichkeit), die Softwareentwicklung betrachtet den Entwicklungsprozess (von den Anforderungen bis zur lauffähigen Software, Qualitätssicherung, technische Entscheidungen). Beide Sichten treffen sich im selben Projekt, und beide werden in der Diplomarbeit gebraucht. Widersprechen sich die Darstellungen, fragen Sie nach: Unterschiedliche Fachtraditionen verwenden dieselben Wörter verschieden, und das zu bemerken gehört zur Kompetenz.

Abgrenzung zum Fach ITP - Informationstechnische Projekte

Der konkrete Ort dieser Projektmanagement-Sicht an unserer Schule ist das Fach ITP - Informationstechnische Projekte. Der Lehrplan ordnet ITP über mehrere Jahrgänge den Bereichen Grundlagen des Betriebes, Projektmanagement, Durchführung informationstechnischer Projekte und (im V. Jahrgang) Qualitätsmanagement zu. Vertieft werden dort die organisatorischen und betriebswirtschaftlichen Seiten eines Projekts: SMART-Ziele und Kontextabgrenzung, Rollen im Team, Termin-, Ressourcen- und Kostenplanung, Risiko-, Konflikt- und Changemanagement, das Projektmanagementhandbuch, Projektcontrolling sowie Qualitätsnormen und QM-Systeme.

Dieses SEW-Kapitel schaut auf denselben Gegenstand von der technischen Seite: nicht wie ein Projekt geführt und wirtschaftlich beurteilt wird, sondern in welcher Reihenfolge Software entsteht und wie man ihre Richtigkeit nachweist - Anforderungen, Entwurf, Implementierung, Test, Verifikation und Validierung. Der sichtbarste Berührungspunkt ist agiles Arbeiten: In ITP erscheint Scrum als Projektorganisationsform (Planung, Rollen, Controlling), in SEW als die Art, wie der Code selbst iterativ-inkrementell entsteht und Sprint für Sprint lauffähig bleibt. Im Jahresprojekt und in der Diplomarbeit greifen beide Fächer ineinander; dieselben Wörter meinen je nach Fach die Management- oder die Entwicklungsseite.

Lernergebnisse: Was Sie nach diesem Kapitel können sollten

Nach Abschluss dieses Kapitels sollten Schülerinnen und Schüler in der Lage sein:

• Erklären: Wasserfall, V-Modell, iterativ-inkrementelles Vorgehen und agile Methoden mit ihren Phasen beziehungsweise Bestandteilen erklären.
• Erklären: Verifikation und Validierung unterscheiden und die Zuordnung von Entwurfs- zu Teststufen im V-Modell beschreiben.
• Nennen: die Verantwortlichkeiten, Artefakte und Ereignisse von Scrum nennen und Review von Retrospektive unterscheiden.
• Erklären: die Kernmechanik von Kanban (Fluss, WIP-Limit) erklären und Kanban von Scrum abgrenzen.
• Analysieren: eine Projektsituation anhand von Anforderungslage, Verfügbarkeit des Auftraggebers, Team und Risiko analysieren.
• Beurteilen: für ein gegebenes Projekt ein Vorgehen begründet auswählen und die Wahl gegen Alternativen verteidigen.

Passende Übungen

• Aufgabe 01 - Modell-Matrix