Lernziele
- Sie beschreiben die Phasen eines Softwareprojekts und ihre Ergebnisse.
- Sie erläutern das Wasserfallmodell und vergleichen es mit einem agilen Vorgehen.
- Sie schreiben User Stories, leiten Tasks ab und führen ein Project Board.
- Sie vereinbaren Schnittstellen als Voraussetzung für Arbeitsteilung.
- Sie nutzen Klassen aus einer Programmbibliothek anhand ihrer Dokumentation.
- Sie entwerfen Testfälle, die Randfälle abdecken, und unterscheiden Testen von Debuggen.
- Sie führen ein Softwareprojekt im Team eigenverantwortlich durch.
Schritt 1
Motivation
Warum ein Programm im Team etwas anderes ist.
Alle bisherigen Programme dieses Schuljahres hatten eines gemeinsam: Eine Person hat sie geschrieben, und sie waren in einer Doppelstunde fertig. Für so etwas braucht niemand ein Vorgehensmodell.
Sobald vier Personen ein halbes Jahr an einem Produkt arbeiten, ändert sich das. Nicht, weil Programmieren schwieriger würde – sondern weil Absprachen nötig werden: Wer baut welchen Teil? Wie rufen sich die Teile gegenseitig auf? Woran merken wir, dass wir fertig sind?
Schritt 2
Erklärung
Die Phasen eines Softwareprojekts.
Die Phasen
Jedes Softwareprojekt durchläuft dieselben Phasen. Die Vorgehensmodelle unterscheiden sich nur darin, wie oft und wie streng nacheinander sie durchlaufen werden.
Lastenheft und Pflichtenheft
Bei der Abnahme wird gegen das Pflichtenheft geprüft – es ist die Zusage des Auftragnehmers.
Warum späte Änderungen teuer sind
Derselbe Änderungswunsch kostet zu verschiedenen Zeitpunkten sehr Unterschiedliches:
- in der Analyse – einen Satz neu schreiben
- nach dem Entwurf – Klassendiagramm und Schnittstellen anpassen
- in der Implementierung – an der Schnittstelle hängt bereits fertiger Code anderer
- nach der Auslieferung – echte Daten, neuer Test, neue Übergabe
Aus dieser Beobachtung ziehen die beiden Vorgehensmodelle entgegengesetzte Schlüsse.
Schritt 2
Erklärung
Zwei Vorgehensmodelle.
Das Wasserfallmodell
Das Modell überträgt die Bau- und Produktionsplanung auf Software: Der Ablauf fließt von oben nach unten, Wasser fließt nicht zurück.
Zwei Regeln machen es aus:
- Eine Phase beginnt erst, wenn die vorige abgeschlossen ist.
- Jede Phase endet mit einem Dokument.
In der Praxis wird meist die Fassung mit Rückkopplung verwendet: Ein gezielter Rücksprung in die vorherige Phase ist erlaubt, damit möglichst viel geleistete Arbeit erhalten bleibt. Das Modell wird dadurch brauchbar, verliert aber sein stärkstes Versprechen – die verlässliche Planbarkeit.
Eingesetzt wird es dort, wo Anforderungen vorab feststehen und nachträgliche Änderungen ohnehin ausgeschlossen sind: Luftfahrt, Medizintechnik, öffentliche Ausschreibungen.
Agile Softwareentwicklung
Agile Methoden entstanden als Antwort auf ein Problem der frühen 1990er-Jahre: Zwischen Auftrag und Auslieferung vergingen Jahre, und bei der Übergabe hatten sich die Anforderungen längst geändert. Der Begriff wurde 2001 mit dem agilen Manifest bekannt; die verbreitetsten Verfahren sind Scrum und Kanban.
Die Grundidee: Änderungen nicht verhindern, sondern billig machen. Dazu wird in Iterationen (Sprints) gearbeitet – festen Zeitfenstern, an deren Ende jeweils etwas Lauffähiges steht.
Der Ablauf einer Iteration
- Iterationsplanung – welche User Stories nehmen wir uns vor?
- Arbeitsphase – umsetzen, testen, kurze Absprachen (Stand-up)
- Review – Zwischenstand zeigen
- Retrospektive – wie war die Zusammenarbeit?
Das Zeitfenster ist fest, der Umfang ist verhandelbar. Eine unfertige Story wandert in die nächste Iteration.
User Stories und Tasks
Eine User Story beschreibt einen Wunsch aus Nutzersicht, im Muster Als … möchte ich … damit …. Sie enthält keine Klassennamen – sonst legt sie die Lösung fest, bevor jemand über sie nachgedacht hat.
Ein Task ist ein technischer Arbeitsschritt zur Umsetzung einer Story. Tasks entstehen erst in der Iterationsplanung.
Priorität und Aufwand sind zwei verschiedene Dinge. Die Priorität sagt, was zuerst gebraucht wird (kleine Zahl = wichtig); der Aufwand wird grob geschätzt, oft in den Größen S, M und L. Eine kleine Story kann höchste Priorität haben.
Das Project Board
Jede Story ist eine Karte mit den Namen der Verantwortlichen und wandert von links nach rechts – aber erst, wenn sie wirklich läuft und getestet ist.
Schritt 2
Erklärung
Wie ein Team zusammenarbeitet.
Arbeitsformen
Pair Programming. Zwei Personen an einem Gerät: Die Fahrerin tippt, der Navigator liest mit, prüft und behält das Ziel im Blick. Der Gewinn liegt nicht im Tippen, sondern im Prüfen zur Entstehungszeit – und darin, dass danach beide den Code kennen. Entscheidend ist der regelmäßige Rollenwechsel, etwa alle 15 Minuten.
Stand-up-Meeting. Kurze Standortbestimmung mit drei Fragen, höchstens zehn Minuten:
- Was habe ich seit dem letzten Mal geschafft?
- Was nehme ich mir bis zum nächsten Mal vor?
- Was hindert mich gerade?
Die dritte Frage ist die wichtigste. Fachliche Diskussionen werden auf ein eigenes Treffen der Beteiligten vertagt.
Retrospektive. Rückblick am Ende jeder Iteration – nicht auf den Code, sondern auf die Zusammenarbeit. Was lief gut? Wo hakte es? Und eine konkrete Änderung für die nächste Iteration, samt der Angabe, woran man ihre Wirkung erkennen würde. Es geht um den Ablauf, nicht um Personen.
Schnittstellen
Arbeitsteilung setzt voraus, dass vorher feststeht, wie die Teile zusammenarbeiten. Vereinbart werden muss:
- wie die Methoden heißen
- welche Parameter sie erwarten
- was sie zurückgeben – auch im Sonderfall („
null, falls nicht gefunden")
Was nicht vereinbart werden muss, ist die Implementierung. Genau das ist der Sinn einer Schnittstelle: Das Innere darf sich ändern, solange das Versprechen nach außen gilt. Das ist die Datenkapselung aus Lernbereich 12.1 – hier als Organisationsprinzip.
Schritt 2
Erklärung
Fremden Code benutzen, eigenen prüfen.
Bibliotheksklassen
Zeichenfläche, Taktgeber, Dateizugriff – das sind gelöste Probleme. Um eine Bibliotheksklasse zu benutzen, genügt ihre Schnittstelle; wie sie intern arbeitet, ist gleichgültig.
Rechteck feld = new Rechteck();
feld.PositionSetzen(50, 80);
feld.GroesseSetzen(200, 120);
feld.FarbeSetzen("blau");
Die Online-IDE bringt dafür die Bibliothek Graphics and Games mit:
Rechteck, Kreis, Dreieck, GText und GTurtle mit deutschen
Methodennamen.
Testen
Testen heißt: das Programm mit ausgewählten Eingaben ausführen und prüfen, ob das Erwartete herauskommt. Debuggen heißt: einem bekannten Fehler nachgehen und ihn beheben.
Ein bestandener Test zeigt korrektes Verhalten für diese Eingabe – nie die Abwesenheit aller Fehler. Und nach jeder Korrektur laufen alle Tests erneut: Eine Reparatur an einer Stelle beschädigt gern eine andere.
Schritt 8
Zusammenfassung
Das Wichtigste auf einen Blick.
- Jedes Projekt durchläuft Analyse, Entwurf, Implementierung, Integration, Betrieb – die Modelle unterscheiden sich in Reihenfolge und Häufigkeit.
- Das Lastenheft kommt vom Auftraggeber, das Pflichtenheft vom Auftragnehmer; abgenommen wird gegen das Pflichtenheft.
- Das Wasserfallmodell ist streng sequenziell, gut planbar und unflexibel; in der Praxis wird es mit Rückkopplung verwendet.
- Agile Methoden arbeiten in kurzen Iterationen; nach jeder läuft etwas. Kernbegriffe: User Story, Task, Project Board, Review, Retrospektive.
- Schnittstellen werden vor der Arbeitsteilung vereinbart – Methodennamen, Parameter, Rückgaben, auch für den Sonderfall.
- Pair Programming lohnt sich durch das Prüfen zur Entstehungszeit; die Rollen müssen regelmäßig wechseln.
- Getestet wird an den Rändern, und nach jeder Korrektur läuft alles erneut.
- Für das eigene Projekt gilt: lieber klein und fertig als groß und halb.