Systematische Softwareentwicklung

2.2Modelle

"Manche leben mit einer so erstaunlichen Routine, dass es schwerfällt zu glauben, sie lebten zum ersten mal."
(Stanislaw Jerzy Lec)

Betrachten wir doch zunächst mal einige Beispiele aus der evolutionären Entwicklung der Modelle, nach denen Software entwickelt wurde bzw. wird.

Beim "Wasserfall-Modell" werden alle Schritte, die bei einem Softwareentwicklungsprojekt erforderlich sind, nacheinander durchlaufen. Im ersten Augenblick scheint dies vernünftig und richtig zu sein, bei weiterem Nachdenken (oder Ausprobieren) stellt man jedoch fest, das es sich bei dem Wasserfall-Modell um eine Idealisierung handelt. Kein Projekt läuft wirklich so ab!

"Aber sobald mit der Umsetzung begonnen wird, zeigt sich irgendwo eine Unstimmigkeit, die sich mit der Spezifikation nicht klären lässt. Ein praktisch denkender Mensch würde jetzt vielleicht einfach den Kunden anrufen und ein paar Fragen stellen, was aber peinlich ist, wenn der Kunde bereits eine Rechnung über »1 Stck. Vollständige Leistungsbeschreibung« erhalten hat." [B4]

Erst am Ende der Entwicklung wird getestet, d.h. das wahre Ende des Projekts ist terminlich nicht vorhersehbar, weil kein Mensch ahnen kann, wie viele Fehler auftreten werden und wie lange deren Korrektur dauern wird. Dieses Modell hat Ähnlichkeiten mit einem echten Wasserfall, der das Wasser (in unserem Fall die Probleme) von Stufe zu Stufe weiter reicht und am Ende in einem See sammelt.

Das "V-Modell" ist eine Fortentwicklung des Wasserfall-Modells und berücksichtigt das Testen in allen Phasen, um die Überraschung am Ende zu vermeiden. Die Erfahrung hat jedoch gezeigt, dass die Überraschung nicht einfach durch intensivere Tests zu vermeiden ist, weil der Umgang mit Änderungsanforderungen (engl. "Change Requests") während der Entwicklung damit nicht abgedeckt wird.

Das "Spiral-Modell" von Barry Boehm ist quasi ein mehrfacher Wasserfall, bei dem Analyse, Entwurf, Codierung und Test mehrfach hintereinander durchlaufen werden. Dies ermöglicht eine schrittweise Verfeinerung der Software durch mehrstufige Implementierung der Funktionalität. Da die Analyse mehrfach erfolgt, können Änderungsanforderungen (engl. "Change Requests") bei diesem Modell besser berücksichtigt werden. Außerdem wird dabei mehrfach getestet, wodurch die Problematik des Wasserfall-Modells durchaus entschärft wird. Am Ende der Spirale steht das Idealprodukt.

Das "Prototypen-Modell" heißt auch Casey-Modell, womit ein junger Entwicklungsleiter geehrt wird. Dieser kam auf die Idee, einen Prototypen zu bauen, der bereits die gesamte Funktionalität enthält, aber nicht getestet ist, keine Hilfen und keine Plausibilitätskontrollen sowie keine Fehlerbehandlung enthält, weder kommentiert noch dokumentiert ist und auch unter optischen Aspekten völlig anspruchslos ist - also noch kein Produkt ist!

Es geht ganz einfach darum, möglichst schnell ein Stück Software zu haben, das dem Kunden als Basis für weitere Diskussionen dienen kann und den Entwickler spüren lässt, wo die größten technischen Probleme verborgen sind. Ein Prototyp zeigt sehr deutlich, ob der Anbieten seinen Kunden verstanden hat und der Kunde wirklich weiß, was er will.

Heute ist das Prototypen-Modell weiter entwickelt und erzeugt evtl. sogar ein Pilotsystem, das mit den Anwendern des Kunden getestet werden kann. Parallel dazu erfolgt heute auf jeden Fall die Entwicklung des Echtsystems nach einem anderen Modell, denn der Prototyp wird halt weggeworfen (schließlich ist es ein Prototyp und kein Echtsystem!). Mehr zur Prototypen-Entwicklung in meinem Kapitel Prototyp.

Die Modelle "USDP" ("Unified Software Development Process") bzw. "RUP" ("Rational Unified Prozess") gehen auf die drei Amigos Grady Booch, Jim Rumbaugh und Ivar Jacobson von der Firma Rational Software [L7] zurück. Grady Booch ist der Papst der Objektorientierung und Ivar Jacobson der Vater der Anwendungsfälle. In Deutschland ist die Firma oose [L4] ("OOSE" = Object Orientied Software Engineering) rund um Bernd Oesterreich sehr aktiv in der Verbreitung des objektorientierten Ansatzes.

Beim USDP-Modell stelle ich gerne die Unterscheidung zwischen der Managementsicht und der technischen Sicht gemäß nebenstehendem Diagramm heraus: Die Managementsicht besteht aus Projektphasen mit Meilensteinen für Konzept, Entwurf, Konstruktion und Übergabe. Die technische Sicht besteht aus Prototypen und Produktversionen. Bei jeder Versionsstufe werden die Prozesse Anforderung, Analyse, Design, Implementierung und Test durchlaufen (iterative Vorgehensweise). Das Produkt wächst dadurch inkrementell in seinem Leistungsumfang.

Es wird dabei gerne auch vom "Lebenszyklus" des Software-Entwicklungsprojektes gesprochen (engl. "Software Development Life Cycle"). Die vier Phasen werden von Rational als "Etablierung" (engl. "Inception"), "Ausarbeitung" (engl. "Elaboration"), "Konstruktion" (engl. "Construction") und "Übergang" (engl. "Transition") bezeichnet.

Ich meine, dass dieses Modell sehr gut um weitere Sichten (Rollen) des Projekts ergänzt werden kann, denn neben der technischen Versionssicht und der Management-Phasensicht gibt es mindestens noch eine Produktsicht, die für Marketing, QS, Training und Support relevant ist, sowie eine kaufmännische Sicht (Verträge, Zahlungen und Strafen), die für den Vertrieb sehr wichtig ist.

Sie können an der Breite der Dreiecke sehen, welche Prozesse wie intensiv iteriert werden. So reicht die Konzeptphase der Projektleitersicht beispielsweise vom Anforderungsprozess bis zum Designprozess, wobei ein Schwerpunkt auf dem Anforderungsprozess liegt. Die Version 1.0 der Marketingsicht h
ingegen hat ihren Schwerpunkt bei der Übergabe.

Fazit

Im Prinzip war das Wasserfallmodell gar nicht so verkehrt, denn es ist sicherlich immer gut, einen Schritt nach dem anderen zu tun (auch wenn es heute modern zu sein scheint, alles auf einmal zu versuchen (wobei bekanntermaßen ohnehin nur Frauen mehrere Dinge gleichzeitig tun können)). Ein ganzes Software-Projekt strikt stufig durchzuführen geht aber auf jeden Fall schief. Wie ist es denn bei einem echten Wasserfall? Am Ende wird man doch nass, oder? Im Ernst: Das Problem beim Wasserfallmodell ist, dass man am Anfang noch gar nicht alle Eventualitäten abschätzen kann, während der Entwicklungszeit viele neue Änderungsanforderungen (Change Requests) eintreten und am Ende weder zeitlich ("in time") noch preislich ("in budget") noch qualitativ ("in quality") das herauskommt, was sich der Auftraggeber vorgestellt hat. Damit ist der Ärger vorprogrammiert.

Zerteilt man das Software-Projekt in viele Phasen, durchläuft jede Phase stufig und bezieht den Kunden (auch dessen Anwender!) in jeder Phase mit ein, so sieht es schon viel besser aus, weil jede einzelne Phase abschätzbar wird und Änderungen sowie bekannt gewordene Details nach jeder einzelnen Phase in die Planungen integriert und getestet werden können. Diese Vorgehensweise wird heute als "iterativ inkrementell" bezeichnet, weil das Produkt in vielen schleifenähnlichen Durchläufen von Version zu Version vollständiger wird.

Übrigens können die Prozesse selbst auch noch in Teilprozesse unterteilt werden, die dann wiederum für eine gewisse Zeit iterativ inkrementell innerhalb des Prozesses durchlaufen werden. Die Analyse kann beispielsweise sehr wohl durch verschiedene Sichten und Detaillierungsgrade in mehreren interativen Schritten inkrementell erstellt werden. Wenn Sie die Entstehung dieser Abhandlung betrachten, so stellen Sie fest, dass ich eine gewisse Zeit lang Stichworte sammel und verteile, Sprüche hinzufüge, Graphiken und Diagramme ergänze, Mengen in Einzelseiten aufteile, eine Seite dann erst als durchgehenden Prosatext formuliere und irgendwann nochmal eine Überarbeitung fahre. So sind einige Seiten offensichtlich schon fertig, während in manchen Kapiteln erst eine einzelne Seite mit Stichworten existiert. Da ich hier eine iterativ inkrementelle Softwareentwicklung beschreibe, füllt sich das Dokument zwar im Groben "von vorne nach hinten", aber die ersten Stichworte waren tatsächlich zum Kapitel "Test" entstanden.

Bedenken Sie aber auch bei aller Systematik immer, dass das eigentliche Ziel der Softwareentwicklung natürlich nicht die Entwicklung selbst, sondern die Auslieferung einer fertigen Software mit den drei oben genannten Teilzielen ist.