Aaron Fischer Ingenieur, Vater, Heimwerker, Problemlöser

07 März, 2008

Von Wasserfällen und scharfer Munition

TL;DR:

Im Laufe meines Studiums habe ich einige Vorgehensmodelle zur Softwareentwicklung kennengelernt. Besonders ausführlich wurde das Wasserfallmodell behandelt. Wer es (noch) nicht kennt: Der Softwareentwicklungsprozess ist in 5 Phasen eingeteilt, welche linear durchlaufen werden. Zuerst wird die Software geplant, sprich ein Lasten und Pflichtenheft erstellt welches beschreibt was die Software können muss. Daraus wird der Entwurf der Software (meist mit UML) erstellt. Dieser Entwurf wird in Software umgesetzt und anschließend getestet. Am Ende wird die Software ausgeliefert, Installiert und gewartet. Die einzelnen Phasen sind wie bei einem Wasserfall angeordnet und strikt getrennt. Wenn bei der Implementierung Designfehler entdeckt werden wird wieder bis zur Entwurfsphase gesprungen, der Fehler behoben und dann wieder die Kette nach unten geklettert.

Wasserfall (Bild von @t.)

Irgendwie konnte ich mich mit diesem Modell nie richtig anfreunden und habe auch nie wirklich geglaubt das ein solches Konzept erfolgreich angewandt werden kann. In dem Buch Ship it! von Richardson und Gwaltney bin ich hier auf meine lang ersehnte Bestätigung gestoßen:

Ein Vorgehensmodell, das Sie vermeiden sollten, ist das berüchtigte Wasserfallmodell. Es wurde in fortschrittlicheren Entwicklerkreisen allgemein verworfen, trotzdem ist es erstaunlich, in wie vielen Unternehmen es immer noch angewendet wird. [...] Ahnungslose Manager, die in Zeitpläne vernarrt sind, sind schon seit vielen Jahren Anhänger dieses Vorgehensmodells.

Als pragmatische Alternative zu den eingerosteten Vorgehensweisen stellt das Buch das von Thomas und Hunt entwickelte Tracer Bullet Development (TBD) vor. Ziel ist es hier, die Anwendung so schnell wie nur möglich lauffähig/ausführbar zu machen. Anfangs wird die Anwendung in Bereiche eingeteilt und Schnittstellen spezifiziert. Die einzelnen Klassen mit Methoden werden als stubs angelegt und geben bestenfalls statische dummy-Werte zurück. Wenn dieses Grundgerüst steht, werden die einzelnen Methoden ausprogrammiert und mit der Zeit verfollständigt.

Ein interessantes Konzept wird auch bei den Schnittstellen angewendet: Alle Schnittstellen kommunizieren über das Netzwerk, auch wenn beide Teile auf einem Prozessor laufen. Das hat den Vorteil, das eine Lose Kopplung erzwungen wird und die Software am Ende viel besser skaliert werden kann.

Doch eines hat dieses Konzept mit dem Wasserfallmodell gemeinsam. Es geht davon aus, das das Konzept der Software endgültig ist und das von Anfang an feststeht wie die Software am Ende auszusehen hat. Es ist zwar viel leichtgewichtiger als die großen, aber nicht so Agil wie XP und Co. Martin Fowler unterscheidet hier zwischen geplantem und wachsendem Design.

Ich denke es kommt immer darauf an, was für Software man entwickelt. Wenn es eine Neuimplementierung einer alten Steuersoftware ist, spricht eigentlich nichts gegen TBD, doch wenn beim umzusetzenden Programm ganz neue Technologien verwendet werden, Features implementiert werden sollen die es zuvor noch nicht gegeben hat und anfangs noch gar nicht klar ist, wie das Endergebnis aussehen soll (oder der Kunde nicht weiß was er will), sind agilere Vorgehensweisen angebrachter.