Mit einem Entwicklungsmodell werden verschiedene Stadien (Phasen) eines Softwareprodukts von seiner Entstehung bis zum Ende seiner Verwendung vorgegeben, vergleiche [INFODUDEN S. 656]. Mit einem Entwicklungsmodell versucht man den Prozess der Systementwicklung im Vorhinein so festzulegen, dass man im Nachhinein auf eine optimale Systementwicklung zurückblicken kann. Ein Entwicklungsmodell hilft dem Entwickler, den gesamten Prozess der Systementwicklung so aufzuteilen, dass diese überschaubar und somit beherrschbar wird.

Bei der Aufteilung in einzelne Stadien/Phasen, die wiederum aufteilbar sind, stehen je nach Entwicklungsmodell verschiedene Aspekte im Vordergrund wie zum Beispiel:

• Nebenläufigkeit
  Bei einem Mehrpersonenprojekt ist es wichtig, dass viele Personen an ein und demselben Projekt gleichzeitig arbeiten können. Dabei ist es wünschenswert, dass sich die Entwickler dabei nicht in die Quere kommen. Dies kann erreicht werden, indem das Projekt in voneinander unabhängige Teile aufgeteilt wird. Beispielsweise kann das Produkthandbuch unabhängig von der Testphase erstellt werden.
• Qualitätssicherung
  Es ist selbstverständlich, dass durch die Aufteilung in einzelne Stadien/Phasen nach dem Prinzip „divide−and−conquer” die Qualität des Systems/Produkts zunimmt. Aber auch die Art und Weise, wie nun der Aufwand der Qualitätssicherung im Entwicklungsprozess verankert ist, wirkt sich auf die Qualität des Endprodukts aus.
• Spontaneität
  Oft kommen während der fortgeschrittenen Systementwicklung weitere, unvereinbarte Anforderungen sowie Änderungswünsche hinsichtlich bestehender Anforderungen (Change−Requests) hinzu. Erweiterungen und vor allem Abänderungen während der Softwareentwicklung können das Projekt gefährden (Inkonsistenz). Deshalb ist es wünschenswert, eine Vorgehensweise zu kennen, die mit spontanen Änderungen (agil) umgehen kann.
• Fristen
  Typisch für die IT−Branche ist, dass Termine eigentlich nie eingehalten werden. Hat man es aber mit unverschiebbaren Auslieferungsterminen zu tun, benötigt man in erster Linie ein geeignetes Modell zur Softwareentwicklung — mit dem guten Willen allein, hat man noch keinen Termin eingehalten. :−)

Während der Systementwicklung fallen viele unterschiedliche Aufgaben an. Jede Aufgabe erfordert eine bestimmte Herangehensweise. Man spricht hierbei von Tätikeiten und Aktivitäten, für die je nach Entwicklungsmodell Rollen festgelegt werden. Typische Rollen in der Softwareentwicklung sind:

• Systementwickler
  Ohne dem Systementwickler gäbe es praktisch keine Realisierung. Der Systementwickler entwirft und implementiert das geplante System gemäß der Anforderungen, sodass am Ende ein Softwaresystem herauskommt.
• Projektleiter
  Der Projektleiter übernimmt die Aufgaben des Projektmanagements, d. h. er kommuniziert mit dem Auftraggeber, stellt die Entwicklerteams zusammen, verwaltet den Projektplan, koordiniert die Ressourcen und kontrolliert, ob die Projektziele erreicht werden.

Selbstverständlich lassen sich oben genannte Rollen wiederum in weitere spezialisiertere Rollen aufteilen. Und weitere Rollen wie zum Beispiel Rollen für die Qualitätssicherung sind hier noch gar nicht erwähnt.

Im Vergleich zum Begriff Entwicklungsmodell hat sich in der IT−Branche der Begriff Vorgehensmodell (nicht zu verwechseln mit dem Begriff V-Modell) besser durchgesetzt. Die einzige Rechtfertigung für meine Begriffsungenauigkeit ist, dass sich meines Erachtens die Nicht−IT−ler unter dem Begriff Entwicklungsmodell etwas mehr vorstellen können.

Es ist allgemein bekannt, dass zuverlässige, robuste, portable, wartbare, benutzerfreundliche und erweiterbare Software nur schwer zu entwicklen ist. Der Entwickler wünscht sich deshalb ein plan- und kontrollierbares Modell zur Entwicklung von Software, mit dem es möglich ist, sich dem Endziel (exzellente Software) schrittweise aber sicher anzunähern.
Zunächst liegt das Hauptaugenmerk auf etwas, das kaum planbar und kontrollierbar ist, was aber jeder kennt: dem Code−and−Fix−Zyklus.

Unter einem Code−and−Fix−Verfahren versteht Boehm die unsystematische Vorgehensweise in der Frühzeit des Programmierens: Man beginnt ohne weitere Planungen und Vorüberlegungen mit dem Schreiben von Code (oft in einer niederen, wenig übersichtlichen Programmiersprache) und endet mit dem langwierigen und mühseligen Austesten und Zusammenfügen der Programmbausteine (fix). [INFO2004]
Dieses Verfahren ist aus diesem Grunde nicht sehr empfehlenswert für Projekte, vielleicht nicht einmal für Einmannprojekte.

1. Code schreiben 2. Code testen 3. Code verbessern 4. Goto 1 :-)

Jeder, der schon einmal nach diesem Verfahren programmiert hat, sagt sich spätestens bei der zehntausendsten Code−Zeile: Das programmier' ich später nochmal, aber dann viel besser! :−)
Diese Art zu programmieren, führte 1968 zur Software−Krise, denn:

1. Zuverlässigkeit nimmt kontinuierlich ab!
2. Wartbarkeit nimmt kontinuierlich ab!
3. Wenn der Programmierer kündigt, ist alles vorbei!

Code−and−Fix ist also kein guter Ansatz für zuverlässige, wartbare Software. Außerdem umfassen heutige Projekte mehrere Personenjahre oder gar Personenjahrhunderte — das schafft ein einzelner Programmierer ja gar nicht!
Wer nun glaubt, dass das Code−and−Fix−Verfahren, also das „Drauflosprogrammieren”, der Vergangenheit angehört, irrt sich. Viele Programmierer (vermutlich sogar alle) programmieren — entgegen besserem Wissen — erst einmal drauflos, ohne überhaupt genau zu wissen, was sie wollen. Was dabei herauskommt, genügt den Qualitätsanforderungen eines Endprodukts in den seltensten Fällen. Sinnvoll ist dieses Vorgehen eventuell beim Erstellen eines vorläufigen Prototypen (Evolutionäres Modell).

Das Wasserfallmodell gliedert sich in mehrere Phasen, wobei jede einzelne Phase metaphorisch für eine Fallstufe eines echten Wasserfalls steht. Erst wenn eine Phase vollständig abgeschlossen ist, kann mit der Folgephase fortgefahren werden. Ein Rücksprung in eine Vorgängerphase ist nicht vorgesehen, ähnlich wie bei einem echten Wasserfall: Ein Wassermolekül kann keine Fallstufe mehr erreichen, die es bereits passiert hat (ohne Rücksprung).
Jedoch bietet dieses Modell nur wenige Möglichkeiten zur Kosten− und Ressourcenabschätzung, und die Vorwegnahme von nachträglichen Änderungsmöglichkeiten (Antizipation des Wandels) wird überhaupt nicht unterstützt.

Zu den wohl berühmtesten Vorgehensmodellen zählt das V−Modell. Es zeichnet sich dadurch aus, dass der Entwicklungsprozess auf die projektspezifischen Bedürfnisse angepasst werden kann, um nicht mehr Aufwand zu haben als unbedingt notwendig ist. Der Name des V−Modells gründet auf der V−artigen Anordnung der einzelnen Phasen in einem Detailierung−Zeit−Diagramm.

Das evolutionäre Modell ist ein flexibles Modell zur strukturierten Software−Entwicklung. Es eignet sich besonders dann, wenn der Kunde überhaupt nicht weiß, was er will! Zudem kann es auch vorkommen, dass der Entwickler nicht weiß, wie bestimmte Anforderungen realisiert werden können. Zur schrittweisen Annäherung an eine vage Anforderung oder eine vage Realisierung bietet das evolutionäre Modell den nötigen Spielraum für beide Seiten — den Auftraggeber und den Auftragnehmer.
Ein System/Produkt wird als Folge von Approximationen realisiert. Mit diesem Modell lernt das Entwickler−Team, die Bedürfnisse und Wünsche des Kunden zu verstehen und demgemäß umzusetzen.

Das Spiralmodell ist ein Metamodell, das evolutionäre Aspekte und Risikobewertung umfasst. Das Softwareprodukt wächst wie eine Spirale, wobei diese in vier Quadranten (je ein 90°−Sektor) unterteilt ist. Ein Umlauf durch alle vier Quadranten ergibt den nächsten Prototyp, der wiederum im nächsten Umlauf erweitert wird.

1. Anforderungsdefinition 2. Bewertung von Alternativen und deren Risiken 3. Entwurf, Implementation und Test 4. Auswertung und Planung des nächsten Umlaufs 5. Goto 1

Unter Extreme Programming versteht man einen Prozess zum schnellen Programmerstellen in unsicherem Umfeld. Es ist sozusagen eine Erweiterung von Code-and-Fix für eine kleine Gruppe qualifizierter Programmierer, die sich ihre Regeln selbst macht; zum Beispiel sorgt Pair Programming (Programmieren in Paaren) für ständiges Gegenlesen durch den Partner.
Jeder darf die Software umstrukturieren, solange dies begründet und kommentiert ist.
Der Grundsatz des Extreme Programming lautet:

1. Ohne Testen läuft gar nichts!

Nach der Implementierung wird oftmals die Verifikation vernachlässigt. Aus diesem Grund schreibt man die Testfälle vor der Implementierung der Methoden, die jederzeit automatisch ausgeführt werden können; JUnit ist zum Beispiel ein gutes Werkzeug dafür.


Extreme Programming ist die Antwort auf die übermäßige Prozessmodellierung der 90er Jahre. Das Wasserfallmodell hat beispielsweise bei größeren Projekten eine lästige, projektinterne Bürokratie zur Folge, in der sich nur wenige zurechtfinden.
Es ist jedoch unklar, ob das Modell „Extreme Programming” auf große bzw. kritische Systeme anwendbar ist.

„Scrum ist ein Entwicklungsstil, bei dem ein Projekt sich einem Featureset widmet, das innerhalb eines 30 Tage Sprints implementiert werden kann”, heißt es in [SWSCHäTZUNG S. 113].
Unter Featureset verstehe ich eine kleine zusammengehörige Funktionsmenge, die in relativ kurzer Zeit (Sprint) implementiert werden kann, sobald die Anforderungsdefinition dafür abgeschlossen ist.
Nach dem Sprint folgt die nächste Iteration, d. h. die Featureset−Definition, welche wiederum in einem Sprint implementiert wird. Des Weiteren heißt es in [SWSCHäTZUNG], dass der Kunde während eines Sprints nicht mehr die Möglichkeit habe, die entsprechende Featureset−Definition zu ändern.

Für manch kleine Anwendungen eignet sich das Transformationsmodell. Das fertige Programm wird (beinahe voll-) automatisch mit einer formalen Spezifikation erstellt. Dies erfordert allerdings eine teure Anwendung mit korrektheitserhaltenden Transformationen, also eine solide Software- und Maschinenunterstützung.
Zum Beispiel können Scanner und Parser unter Angabe einer formalen Spezifikation (reguläre Ausdrücke, Token etc.) beinahe automatisch erzeugt werden.
Jedoch sind viele Anforderungen heutzutage viel zu komplex, als dass sie automatisch von Maschinen produziert werden könnten.