5.2.3 Vorgehensmodelle

Ein Vorgehensmodell (auch Phasenmodell genannt) ist eine aus mehreren Teilprozessen bestehende und idealisierte Anleitung, um Software zu entwickeln. Die in jedem Modell vorkommenden Teilprozesse sind Analyse, Entwurf, Implementation und Test. Dazu kommen je nach Modell noch verschiedene weitere Phasen, die oft eine Verfeinerung der o.g. Prozesse sind, z.B. gibt es im V-Modell die Phasen Modultest und Integrationstest.

Als Hilfs- oder Unterstützungsprozesse werden häufig das Projektmanagement, Qualitätsmanagement und das Konfigurationsmanagement (z.B. Versionsverwaltung) angesehen. Grundsätzlich kann man sagen, dass je einfacher und statischer ein Vorgehensmodell konzipiert ist, desto weniger kann man es in der Praxis umsetzen. Eine ausführliche Liste von Vorgehensmodellen findet man in Wikipedia1, hier stelle ich exemplarisch einige wichtige Vorgehensmodelle dar und bewerte diese.

Wasserfallmodell

Das in Lehrbüchern oft als erstes genannte Modell ist das Wasserfallmodell, das zu den linearen Phasenmodellen gehört. Es besteht aus den Phasen Initialisierung, DV-Konzept, DV-Entwurf, Implementierung, Test, Installation und Wartung.

Wasserfallmodell
Wasserfallmodell

Jede der Phasen ist sehr strikt getrennt und in die nächste Phase kommt man erst nach Abschluss der vorherigen Phase. Rückschritte zur vorherigen Phase sind zwar möglich, jedoch unerwünscht. In der Praxis eingesetzt würde das Produkt dem Kunden nach der Testphase präsentiert werden, also wenn es fertig ist. Das ist auch der Hauptnachteil an diesem Modell, denn wenn dann Änderungen von Seiten den Kunden kommen, müssen alle Phasen erneut durchlaufen werden. Damit ist dieses Modell idealisiert und unbrauchbar für die Praxis, zumindest wenn man Kunden bedienen und Geld verdienen muss. Als theoretischer Einstieg in die Phasenmodelle ist es jedoch gut geeignet und deshalb auch sehr oft genannt. Außerdem zeigt es deutlich die Trennung zwischen den verschiedenen Phasen, so dass an diesem einfachen linearen Modell die Idee der Phasenmodelle schön deutlich wird.

Spiralmodell

Das Spiralmodell (1988 beschrieben von BOEHM) ist nicht mehr linear aufgebaut, sondern wie der Name schon sagt, wie eine Spirale. Es wird auch als iterativ und inkrementelles Phasenmodell bezeichnet, weil die Phasen des Wasserfall-Modells mehrfach durchlaufen werden. Am Ende eines Durchlaufs entsteht ein Prototyp und im letzten Durchlauf schließlich dann das fertige Produkt. Da das Modell in einer Zeit beschrieben wurde, als mit Software-Projekten häufig schlechte Erfahrungen gemacht worden sind, wird bei jedem Durchlauf eine erneute Risikoanalyse durchgeführt. Daher ist das Modell auch risikogetrieben.

Spiralmodell
Spiralmodell

Dieses Modell ist in der Praxis einsetzbar, doch besteht ein deutlicher Mehraufwand durch die erneuten Risikoanalysen und Verifikation der Zwischenschritte. Die Vorteile sind jedoch wirtschaftlich betrachtet sehr wichtig, denn man kann nach den Risikoanalysen das Projekt abbrechen, statt noch mehr Geld in das gescheiterte oder fehlentwickelte Projekt zu stecken.

Außerdem konnte schon durch das frühe Erstellen der Prototypen erkannt werden, ob sich das Projekt in die richtige Richtung entwickelt und so mögliche Fehlentscheidungen noch relativ kostengünstig korrigiert werden.

Rational Unified Process (RUP)

Die 2003 von IBM gekaufte Softwarefirma Rational2 entwickelte ein auf UML basierendes Vorgehensmodell. RUP3 ist eine Vorgehensweise, um in Organisationen Aufgaben und Verantwortungen zu vergeben und damit Kommunikationsprobleme zu verhindern. Es soll den Budget- und Zeitplan prognostizieren und die Entwicklung einer qualitativ hochwertigen Software garantieren.

Die Software soll visuell in UML modelliert werden, wobei alle Diagrammarten des UML benutzt werden. Dazu wird eine iterative Vorgehensweise vorgeschlagen, in der Projekte in mehrere kleine Projekte aufgeteilt werden, so dass jede Iteration ähnlich dem Wasserfallmodell bearbeitet werden kann. Es gibt 4 Haupt-Milestones, die weiter unten bei RUP 4 genannt sind.

RUP unterscheidet zwischen Kern- und Support-Workflows. Im so genannten RUP 9 bestehen die Kern-Workflows aus:

Die drei Support-Workflows sind: In der Zeitachse (also orthogonal dazu) ist jeder Workflow in vier Phasen aufgeteilt (daher RUP 4), in denen jeder Workflow unterschiedlich stark eingesetzt wird. Dies sind die vier Haupt-Milestones:

In der Konzeptionsphase wird die Vision des Endprodukts erarbeitet, Geschäftsprozesse spezifiziert und der Umfang des Projekts definiert. Außerdem werden in dieser Phase Risikoanalysen und Kosten vorhergesagt. Die Entwurfsphase spezifiziert die Produkt­eigenschaften und die Architektur. Weiterhin werden hier die Aktivitäten und Ressourcen eingeplant. Die Konstruktionsphase beinhaltet die Programmierung und Integration der Komponenten in das fertige Produkt. In der letzen Phase wird das Produkt vom Benutzer abgenommen und die Qualitätsüberprüfung durchgeführt. Ein weiterer Bestandteil ist die Auslieferung und Installation des Produkts, sowie Training der Benutzer und die Wartung.

Um dieses Vorgehensmodell einzusetzen, benötigt man die Software Rational Rose von der Firma Rational, die pro Arbeitsplatz im 4-stelligen Euro-Bereich liegt.

V-Modell

Das V-Modell ist in Deutschland ein besonders wichtiges Modell, da der öffentliche Dienst nach diesem Modell vorgeht und Aufträge nur nach diesem Modell vergibt. Seinen Ursprung hat es im militärischen Bereich, in dem es im Februar 1991 per Erlass als Standard für Softwareentwicklung fest geschrieben wurde. 1992 wurde eine zivile Version entwickelt und 1997 eine Optimierung für Objektorientierte Softwareentwicklung. 2005 wurde die Version 1.0 des V-Modell XT (Extreme Tailoring) herausgegeben. Dabei wird der Auftraggeber mehr in das Projekt eingebunden, indem es nun auch Vorgehensbausteine für diesen gibt. Die Bausteine lassen sich flexibler und modulartiger zusammensetzen, außerdem ist die Ausrichtung in Richtung agiler und inkrementeller Ansätze geändert worden. Abbildung "V-Modell" zeigt das Vorgehen lt. Grundlagen-PDF4 (S. 35).

V-Modell
V-Modell

Man sieht in Abbildung 6 deutlich, dass es zu jeder Phase auf dem Weg zum Feinentwurf auch eine entsprechende Phase auf dem Weg zur Abnahme gibt. Im V-Modell wird geregelt welche Rollen es gibt und wer was zu welchem Zeitpunkt regeln muss. Damit bei kleinen Projekten der sehr detailiert geregelte Ablauf die Kosten nicht durch Verkomplizierung in die Höhe treibt, ist es möglich Teile wegzulassen, was jedoch auch geregelt ist, dies nennt man Tailoring. Der Nachteil dieses Vorgehensmodell ist aber der sehr detailierte Weg, den man als Softwareentwickler gehen muss, was zu einer Gegenbewegung geführt hat, denn es wünschten sich viele Entwickler eine agilere Softwareentwicklung.

Agile Softwareentwicklung

"Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität in der Softwareentwicklung"[Wikipedia]. Das bedeutet, dass schnell, flexibel und ohne große Reglementierung programmiert werden kann, quasi als Gegenbewegung zu den detailiert geregelten Softwaremodellen wie dem V-Modell oder dem Rational Unified Process. Das Leitbild sagt, dass man weniger planen soll, da man dadurch das bekommt, das man geplant hat und nicht unbedingt das was man benötigt. Außerdem ist es das Ziel, die Aufwandkurve möglichst flach zu halten, denn viele Kunden wissen zu Beginn des Projekts nicht genau, was sie wirklich benötigen. So kann man unmöglich vorher genau planen und spezifizieren, was der Kunde möchte.

Extreme Programming (XP) ist die bekannteste Methode der agilen Prozesse und zeichnet sich dadurch aus, dass zu Beginn der Entwicklung auf einen detailiert spezifizierten Anforderungskatalog verzichtet wird, sondern in kurzen Abständen ein Prototyp erstellt wird und dann wieder erneut die Anforderungen analysiert werden. Es werden alle Phasen der Softwareentwicklung ständig kurz durchlaufen und somit können die Anforderungen des Kunden noch bis zum Ende aufgenommen und frei nach dem Motto "Der Appetit kommt beim Essen" merkt der Kunde erst mit der Anwendung des Prototypen, welche Features er wirklich braucht.

Die wichtigsten Punkte des Extreme Programmings sind die vielen und frühen Tests, die Programmierfehler und Fehlentwicklungen schnell aufdecken. Es wird nur implementiert, was der Kunde wirklich benötigt, die klassische "Featuritis" wird durch XP verhindert. Ein ebenso wichtiger Punkt beim XP ist die Art des Programmierens, denn oft sitzen zwei Entwickler vor einem Bildschirm und programmieren zusammen. Was zunächst sehr "teuer" aussieht, ist wegen des "Vier-Augen-Prinzip" sehr sinnvoll, denn ein Softwareentwickler denkt die ganze Zeit mit, sieht Fehler und hat vor allem auch Zeit zu denken, während der andere Programmierer den Quellcode eintippt. So kann man komplexe Sachverhalte in kürzester Zeit lösen und dadurch erheblich schneller ist als allein. Außerdem lernt man durch wechselnde Programmiererpaare (und Rollen: Coder/Observer) eine Menge voneinander und so entwickeln sich die Mitarbeiter stärker weiter als normal.

Zeitpläne sind ebenfalls nicht in Gefahr, weil nur das implementiert wird, was der Kunde aktuell wünscht. Weiterhin bietet sich für den Kunden der Vorteil, durch die kurzen Iterationszyklen jederzeit steuernd in das Projekt eingreifen zu können. Oft ändern sich während großer Projekte oder durch die Arbeit mit den ersten Prototypen die Anforderungen und so können diese dann problemlos mit aufgenommen werden.

Schwierigkeiten mit XP sind die Auftragsverfahren der Auftraggeber. Üblicherweise wollen Kunden ein Angebot mit Festbetrag für einen Anforderungskatalog erhalten. Dies ist mit XP nicht so einfach, da man ja keine Spezifikation macht und Projekte nicht von Beginn an genau umrissen werden. Außerdem birgt XP die Gefahr, dass Projekte aus dem Ruder laufen. Hier muss das Projektmanagement den Projektverlauf sehr sorgfältig überwachen.

Objektorientiertes Vorgehensmodell

Oft wird eine abgewandelte Form des Wasserfallmodells benutzt und dann objektorientiertes Vorgehensmodell genannt, auch wenn es das gleiche Vorgehen mit anderen Bezeichnungen ist. So ist die Phase DV-Konzept die Objektorientierte Analyse, der Entwurf (Objektorientiertes Design) wird geteilt, wie auch im (klassischen7) V-Modell, in System- und Komponentenentwurf. Die Implementierung wurde nicht umbenannt (Objektorientierte Programierung).

Jedoch ist es nicht zwingend notwendig, das Wasserfallmodell zu verwenden, denn aus (beim Wasserfallmodell) genannten Gründen ist es für die Praxis nur suboptimal. Das Spiralmodell hat durchaus das Potenzial, für eine objektorientierte Methode genutzt zu werden, da es die Phasen mehrfach durchläuft.

Somit ist die objektorientierte Vorgehensweise kein Modell sondern eine Methode, die mit vielen Modellen angewandt werden kann. Sogar in der Agilen Software-entwicklung kann man objektorientiert vorgehen (vgl. ANDRESEN 2004, S.12).