Prozessmodelle
Prozessmodelle sind in der Softwareentwicklung weit verbreitete Vorgehensmodelle. Sie legen fest, in welcher Reihenfolge und in welcher Art und Weise Aktivitäten in der Softwareentwicklung durchgeführt werden. Sie beschreiben also eine planvolle und systematische Vorgehensweise zur Entwicklung eines Anwendungssystems, welche den Prozess in überschaubare, zeitlich und inhaltlich begrenzte Phasen unterteilt. Diese Vorgehensweise "Phase-für-Phase" führt in aller Regel zur Verbesserung der Qualität des gesamten Systems und erlaubt eine Rekonstruktion des Entwicklungsprozesses und der zu Grunde liegenden Entscheidungen.
Am weitesten verbreitet sind die folgenden drei Modelle, die wir ausführlicher vorstellen möchten:
Das Wasserfallmodell
Das Wasserfallmodell legt fest, dass Software in sukzessiven Stufen entwickelt wird. Es wird Wasserfallmodell genannt, weil die Ergebnisse einer Stufe wie bei einem Wasserfall in die nächste Stufe einfließen. Ergebnis einer Stufe ist ein fertig gestelltes Dokument (d.h. das Wasserfallmodell ist ein dokumentengetriebenes Modell). Als Dokument ist hier allerdings nicht zwingend eine schriftliche Abhandlung gemeint, ein Dokument kann in diesem Zusammenhang auch Quellcode oder Diagramme u.ä. bedeuten.
Neben der strikten Abfolge der Stufen (in obiger Abbildung als Rechtecke dargestellt) sind auch kontrollierte Iterationen zwischen den Stufen möglich. Dies sind Rücksprünge von späteren Stufen zu vorangegangenen, z.B. wenn Fehler in einem früheren Stufenergebnis entdeckt worden sind und nun korrigiert werden müssen.
Das Wasserfallmodell besitzt folgende Eigenschaften:
- Jede Stufe ist in der richtigen Reihenfolge vollständig durchzuführen.
- Am Ende jeder Stufe steht ein fertiges Dokument.
- Der Entwicklungsablauf ist sequentiell, d.h. jede Stufe muss beendet sein, bevor die nächste anfängt.
- Es orientiert sich am top-down-Vorgehen.
- Es ist einfach, verständlich und benötigt nur wenig Management-Aufwand.
Das V-Modell
Das V-Modell ist ein Vorgehensmodell zum Planen und Durchführen von Projekten. Es definiert die in einem Projekt zu erstellenden Ergebnisse und beschreibt die konkreten Vorgehensweisen, mit denen diese Ergebnisse erarbeitet werden. Des Weiteren legt das V-Modell die Verantwortlichkeiten jedes Projektbeteiligten fest. Es regelt also, "Wer" "Wann" "Was" in einem Projekt zu tun hat.
Die Grundelemente des Modells sind also Aktivitäten (Vorgehensweisen — in obiger Abbildung als Rechtecke dargestellt) und Produkte (Ergebnisse — in obiger Abbildung als Ovale dargestellt), die während der Produktentwicklung durchgeführt bzw. erarbeitet werden. Ziel einer Aktivität kann es sein,
- das Produkt zu erstellen,
- den Zustand des Produktes zu ändern,
- den Inhalt des Produktes zu ändern.
Die Projektbeteiligten werden verschiedenen Rollen zugeordnet. Zu diesen gehören:
- ein Manager, der die Rahmenbedingungen für die Aktivitäten festlegt,
- ein Verantwortlicher, der die Aufgaben plant, steuert und kontrolliert,
- ein oder mehrere Durchführende, die die geplanten Aufgaben ausführen.
Das V-Modell ist eine Erweiterung des Wasserfallmodells. Wie in obiger Abbildung zu sehen ist, integriert es die Qualitätssicherung in das Wasserfallmodell, d.h. die Verifikation und die Validation sind Bestandteil des Modells.
Extreme Programming
Extreme Programming (XP) ist eine moderne Vorgehensweise in der Softwaretechnik, die im wesentlichen auf den Werten Kommunikation, Einfachheit, Feedback und Mut basiert. Diese Vorgehensweise ermöglicht es, langlebige Software zu erstellen und während der Entwicklung auf vage und sich rasch ändernde Anforderungen zu reagieren. XP funktioniert, indem eine Reihe von einfachen Regeln und Praktiken eingehalten werden. Hierzu gehören:
- kurze Releasezyklen
- offene Arbeitsumgebungen
- kurze Iterationen
- tägliche Standup-Meetings
- Benutzergeschichten
- Pair Programming
- Continuous Integration
- Coding Standards
- Test-Driven Development
Entstanden ist die Vorgehensweise aus der Erfahrung, dass der Kunde die wirklichen Anforderungen zum Projektbeginn meist noch nicht vollständig kennt. Er fordert Features, die er nicht braucht, und vergisst solche, die benötigt werden. Durch die erwähnten Regeln und Praktiken wird die Qualität und Flexibilität der Software soweit gesteigert, dass der Zusammenhang zwischen dem Zeitpunkt, zu dem eine Anforderung gestellt wird, und den damit entstehenden Kosten weitgehend linear ist.
Das Produkt wird iterativ und evolutionär in kleinen Schritten entwickelt und fortlaufend getestet. Anforderungen werden für jedes Release neu aufgenommen, das Design wird von Release zu Release über Refactoring verbessert. Jedes Release ist ein jeweils lauffähiges, nutzbares (Teil-) Produkt, das vom Kunden abgenommen wird.