3. Vorgehensmodelle III – Das passende Modell wählen

Nach diesem Kapitel kannst du:

• eine Projektsituation anhand der sechs Kriterien der Auswahltabelle analysieren und grob einordnen.
• ein passendes Vorgehen oder eine Mischform begründet auswählen und die Wahl gegen Alternativen verteidigen.
• die drei häufigsten Fehlschlüsse über Vorgehensmodelle erkennen und widerlegen.
• die Sicht der Softwareentwicklung (SEW) auf Vorgehensmodelle von der Projektmanagement-Sicht (ITP) abgrenzen.

In den beiden vorigen Kapiteln hast du die phasenorientierten Modelle (die am Vorabend festgelegte Route) und die iterativen und agilen Modelle (das Navi, das laufend neu plant) kennengelernt. Jetzt geht es um die eigentliche Kompetenz: für eine konkrete Projektsituation begründet zu entscheiden, welches Vorgehen passt.

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

Zwei dieser Kriterien als Achsen genügen schon, um Projekte grob einzuordnen. Die Ampelsteuerung aus der Denkaufgabe unten und die Diplomarbeit aus dem nächsten Absatz landen in gegenüberliegenden Ecken:

quadrantChart
  title Zwei der sechs Kriterien
  x-axis Anforderungen stabil --> Anforderungen im Fluss
  y-axis Fehler korrigierbar --> sicherheitskritisch
  quadrant-1 Mischform
  quadrant-2 V-Modell
  quadrant-3 beides möglich
  quadrant-4 agil
  Ampelsteuerung: [0.15, 0.85]
  Diplomarbeit Lager-App: [0.8, 0.2]

Die Ecke allein entscheidet nicht. Sie zeigt nur, wohin die Abwägung tendiert, bevor die übrigen vier Kriterien dazukommen.

Durchgespielt: eine Diplomarbeit

Eine Diplomarbeit mit externem Auftraggeber: Die Anforderungen sind anfangs grob („eine App für die Lagerverwaltung”), der Auftraggeber ist über das Schuljahr hinweg erreichbar, das Team ist klein und stabil. Ein Teil der Technologie ist neu, und Fehler sind wirtschaftlich korrigierbar.

Fünf Kriterien sprechen damit für agiles Vorgehen, nur der eingereichte Projektantrag wirkt wie ein fixer Leistungsumfang. Die begründete Antwort ist deshalb keine Reinform: in kurzen Zyklen iterativ-inkrementell arbeiten, den vereinbarten Rahmen als Grenze behandeln und jede Abweichung davon schriftlich mit dem Auftraggeber abstimmen.

Mischformen sind der Normalfall

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. Wie eine begründete Mischform für Schulprojekte aussieht, zeigt Kapitel 06 im Abschnitt „Scrum light + Kanban“.

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.

Kurz nachgedacht

Eine Gemeinde beauftragt eine Firma, die Steuerung der Ampelanlage an einer Kreuzung neu zu programmieren. Die Schaltzeiten sind in einer Verordnung festgelegt, die Anlage muss vor Inbetriebnahme behördlich abgenommen werden. Welches Vorgehen schlägst du vor? Nenne zwei Kriterien aus der Tabelle, die deine Wahl tragen.

Auflösung

Ein phasenorientiertes Vorgehen, sinnvollerweise das V-Modell. Die Anforderungen stehen durch die Verordnung früh und stabil fest, und die Fehlerfolgen sind sicherheitskritisch mit verpflichtender Abnahme. Das V-Modell liefert zusätzlich zu jeder Entwurfsstufe den passenden Prüfmaßstab. Ein agiles Vorgehen wäre hier keine Stärke, weil es kaum etwas gibt, das sich durch frühe Rückmeldung noch ändern sollte.

Abgrenzung zum Projektmanagement

Vorgehensmodelle kommen auch im 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).

flowchart LR
  ITP["ITP: Ziele, Termine, Kosten, Risiken"] --> P["Jahresprojekt und Diplomarbeit"]
  SEW["SEW: Anforderungen, Entwurf, Code, Test"] --> P

Beide Sichten treffen sich im selben Projekt, und beide brauchst du in der Diplomarbeit. Widersprechen sich die Darstellungen, frag 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.

Zusatzmaterialien

Die Quellen zu den einzelnen Modellen stehen in den Zusatzmaterialien von Kapitel 01 (Wasserfall, V-Modell) und Kapitel 02 (Agiles Manifest, Scrum, Kanban).

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

• Analysieren: eine Projektsituation anhand der sechs Kriterien der Auswahltabelle analysieren und grob einordnen.
• Beurteilen: ein passendes Vorgehen oder eine Mischform begründet auswählen und die Wahl gegen Alternativen verteidigen.
• Erklären: die drei häufigsten Fehlschlüsse über Vorgehensmodelle erkennen und widerlegen.
• Erklären: die Sicht der Softwareentwicklung (SEW) auf Vorgehensmodelle von der Projektmanagement-Sicht (ITP) abgrenzen.

Passende Übungen

• Aufgabe 01 - Modell-Matrix

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules