Vorgehensmodelle der Softwareentwicklung

Musstest du schon mal ein größeres Softwareprojekt umsetzen und hast dich gefragt, wie du deine Schritte am besten vorausplanst?

Umfangreiche Projekte können schnell sehr unübersichtlich werden und erfordern viel Planungsaufwand. Es kann somit schwer werden, die zeitlichen Vorgaben und Kundenwünsche erfüllen zu können. Genau deshalb gibt es eine Reihe an Vorgehensmodelle, die dir helfen, deine Projekte ideal vorauszuplanen und erfolgreich umzusetzen.

simpleclub zeigt dir die gängigsten Vorgehensmodelle, wann du sie am besten einsetzt und welche Vor- und Nachteile sie jeweils haben.

Vorgehensmodelle einfach erklärt

Größere Softwareprojekte werden in der Praxis bei der Planung in einzelne überschaubare Phasen unterteilt. Bei der Beschreibung von Phasen müssen W-Fragen geklärt werden: Wer macht wann was und mit welchem Ergebnis?

Beispiel: „In der Testphase implementiert Kyra innerhalb einer Woche 10 White-Box-Tests und führt sie aus. Die Resultate der Tests (erfolgreich/fehlgeschlagen) hält sie in einem Dokument fest."

Aus diesen Phasen setzen sich unterschiedliche Vorgehensmodelle zusammen, welche dem Entwicklungsteam als Wegweiser für den Entwicklungsprozess dienen.

Die Vorgehensmodelle sind sich in ihrer groben Struktur meist ähnlich. Viele enthalten typische Phasen wie eine Testphase, in der die Software getestet wird. Sie unterscheiden sich vor allem in

• Der Anzahl der Phasen
• Den Detaillierungsgrad der Phasen, z. B. wie detailliert sind die Arbeitsschritte beschrieben oder wird nur eine grobe Richtung vorgegeben
• Art des Durchlaufs der Phasen: Werden sie einmal (auch linear) oder mehrfach (auch iterativ) durchlaufen?

Definition Vorgehensmodelle

Erklärung Vorgehensmodelle

Unterschiedliche Interessengruppen

Bei der Planung Softwareprojekten stehen sich meist verschiedene Personengruppen mit unterschiedlichen Sichtweisen und Zielsetzungen gegenüber.

• Manager vertreten Unternehmenssicht z. B. hinsichtlich finanzieller Interessen
• Fachexperten für Ablauforganisation sehen das Projekt vor allem aus der Planungsperspektive
• Fachexperten für die zu entwickelnde Software, z. B. Buchhaltungsexperte wenn ein System zur Finanzbuchhaltung implemeniert werden soll
• Software-Entwickler fungieren als IT-Experten und entwerfen die Architektur des gewünschten Gesamtsystems
• Programmierer setzen den Entwurf der Software-Entwickler um
• Anwender bedienen die entwickelte Software

Es ist somit äußerst wichtig, bei der Planung, die Interessen dieser unterschiedlichen Personengruppen zu vereinen. Dabei kann die Wahl des Vorgehensmodells eine entscheidende Rolle spielen. Beispielsweise existieren Modelle, bei denen vorgesehen wird, die Software in regelmäßigen Abständen dem Kunden vorzuführen, um sicherzustellen, dass sie genau seinen Erwartungen entspricht.

Unabhängig von der Wahl des Vorgehensmodell ist es jedoch wichtig, die Anforderungen des Kunden an die Software genau zu erfragen. Dies geschieht im Rahmen der Anforderungsanalyse.

Anforderungsanalyse

Die Sammlung der Anforderungen an die Software aus Kundensicht (z. B. welche Funktionalitäten implementiert werden sollen) ist die Basis für die weitere Entwicklung der Software. Oftmals ist die Anforderungsanalyse eine eigene Phase, die gleich zu Beginn eines Vorgehensmodell steht.

Es gibt verschiedene Arten, die Anforderungen zu erfassen.

Top-Down-Methode

Bei der Top-Down-Methode (übersetzt etwa „von oben nach unten") nennt der Kunde grobe Anforderungen, die nach und nach weiter verfeinert werden.

Im unteren Beispiel soll ein System für die Finanzbuchhaltung eines Unternehmens entwickelt werden. Der Kunde gibt die grobe Anforderung „Rechnungen verwalten" vor, welche weiter verfeinert wird.

Bottom-Up-Methode

Die Bottom-Up-Methode (übersetzt etwa „von unten nach oben") ist nahezu gegensätzlich zur Top-Down-Methode. Es stehen bereits funktionierende Software-Module zur Verfügung, die nach Wünschen des Kunden angepasst werden. So wird das Gesamtsystem „von unten" durch Zusammensetzen der Module und ihre Anpassung gebaut.

Auch hier ist wieder ein Beispiel für das System zur Finanzbuchhaltung gegeben. Der Kunde wählt aus einzelnen Modulen aus und erweitert diese gegebenenfalls, woraus sich die Anforderung „Rechnungen verwalten" zusammensetzt.

Evolutionärer Ansatz

Der evolutionäre Ansatz sieht vor, dass zu Beginn des Projekts nicht alle Anforderungen eingeholt werden. Stattdessen werden auch während der Entwicklung der Software weiter Kundengespräche gehalten und Anforderungen eingeholt. Bei diesem Ansatz ist das Risiko gering, dass das Endprodukt nicht den Wünschen des Kunden entspricht, da ständig Rücksprache mit diesem gehalten wird.

Arten von Vorgehensmodellen

Vorgehensmodelle können klassisch oder agil sein.

Ein klarer Nachteil solcher Modelle ist, dass auf spätere Änderungen von Anforderungen nur sehr schwer reagiert werden kann, da sich die Änderungen kaskadenartig durch den gesamten Plan ziehen.

Allerdings ist es mit diesem Ansatz oft schwieriger, konkrete Vorhersagen über den Fertigstellungszeitpunkt zu machen. Außerdem kann die Qualität der Software leiden, wenn mehrmals Softwarekomponenten hinzugefügt werden, die zu Beginn nicht eingeplant wurden.

Beispiele Vorgehensmodelle

Das Wasserfallmodell

Der Klassiker schlechthin ist das Wasserfallmodell. Der Name verrät dir bereits, dass hier die Phasen wie bei einem Wasserfall mit mehreren Kaskaden

• linear von oben nach unten abgearbeitet und
• Ergebnisse der vorherigen Phase für die nächste verwendet werden.

Dabei werden die Phasen strikt voneinander getrennt, d. h. erst nachdem eine Phase abgeschlossen wurde, darf die nächste begonnen werden. Zum Ende einer jeden Phase wird ein Dokument angefertigt, welches die Resultate der Phase festhält.

Das V-Modell

Das V-Modell ist ebenfalls ein klassisches Modell, welches Teile des Wasserfallmodells aufgreift und erweitert. Auch hier kannst du dir aus dem Namen den groben Aufbau des Modells herleiten, denn die Phasen sind V-förmig angeordnet:

• Auf der linken Seite des Vs befinden sich Phasen aus dem Wasserfallmodell.
• Auf der rechten Seite befinden sich verschieden Testphasen, welche die Resultate der Phasen links testen, z. B. Anhand von vorher festgelegten Testfällen.

Die linke Seite des Vs wird auch Top-Down-Phasen und die rechte als Bottom-Up-Phasen gennant. Sie werden jeweils linear durchlaufen.

Da sich das V-Modell und das Wasserfallmodell sehr ähneln, sind auch ihre Vor- und Nachteile sehr ähnlich.

Das Spiralmodell

Das Spiralmodell besteht aus vier Phasen, welche mehrmals in derselben Reihenfolge wiederholt werden. Während eines Durchlaufs (auch Iteration genannt) wird ein Prototyp der Software erstellt, welcher eine Erweiterung des Prototypen des vorherigen Durchlaufs ist.

Die vier Phasen des Modells sind:

1. Festlegung von Zielen und Rahmenbedingungen, sowie Erfassen von Alternativen
2. Risikoanalyse und Bewertung von Alternativen
3. Entwicklung und Test des Prototypen
4. Planung der nächsten Iteration

Auch hier gibt dir der Name des Modells wieder Aufschluss über seine übliche Darstellungsform.

Wie bei einer Spirale werden dieselben Phasen immer wieder durchlaufen und der Prototyp stückweise (auch inkrementell) erweitert, bis das Gesamtsystem fertig ist. Da die Planung eines Durchlaufs durch die Risikoanalyse sowie Finden und Bewerten von Alternativen sehr intensiv werden kann, gilt es als klassisches iteratives Modell.

Scrum

Nach den klassischen Vorgehensmodellen lernst du nun das agile Modell Scrum kennen. Es zeichnet sich vor allem dadurch aus, dass es keine typische Projektleitung gibt, sondern unterschiedliche Rollen innerhalb des Projekts:

• Der Product Owner ist der Kunde, welcher die Anforderungen stellt. Er hält sie im Product Backlog fest.
• Der Scrum-Master sorgt für die Einhaltung des Scrum-Ablaufs, in dem er zum Beispiel Meetings organisiert.
• Das Development Team ist das Entwicklerteam, welches das Projekt umsetzt. Da keine Projektleitung Aufgaben verteilt, sucht sich jedes Mitglied eigenständig geeignete Aufgaben.

Der Entwicklungsprozess bei Scrum findet in Form von Sprints statt. Jeder Sprint dauert zwei bis vier Wochen, in denen die Software stückweise weiter implementiert wird. Ein Sprint läuft folgendermaßen ab:

1. Zu Beginn des Sprints findet ein Sprint-Planning statt. Hier werden Punkte aus dem Product-Backlog ausgewählt, welche während des Sprints umgesetzt werden sollen.
2. Die ausgewählten Anforderungen werden in ein Dokument überführt, das Sprint Backlog genannt wird. Es ist Grundlage für den Sprint.
3. In den darauffolgenden Wochen arbeitet nun das Development Team an der Realisierung des Sprint-Backlogs. Währenddessen treffen sich die Teammitglieder täglich zum Daily Scrum, einem kurzen Meeting von ca. 15 Dauer. Dort werden tägliche Anliegen besprochen.
4. Zum Abschluss des Sprints werden eine Sprint-Review und eine Sprint Retrospective abgehalten. In der Review überprüft der Product Owner, ob das Produkt seinen Vorstellungen entsprechend weiterentwickelt wurde. In der Retrospective wirft das Development Team einen Blick auf den vergangenen Sprint und bespricht aufgetretene Probleme.

Nach Ende eines Sprints beginnt der Durchlauf von erneut.

Unterschied Spiralmodell und Scrum

Vermutlich ist dir bereits aufgefallen, dass sich Scrum und das Spiralmodell sehr ähneln: Beide sind iterative Modelle, bei denen die Software inkrementell entwickelt wird.

Sie unterscheiden sich jedoch in wesentlichen Punkten:

DevOps

Der Begriff DevOps ist eine Verschmelzung der Wörter Development und Operations. Hier ist der Name wieder Programm: Bei der DevOps-Methode werden das Entwicklerteam, welches die Software entwickelt, und das Operationsteam, welches sie für Anwender z. B. auf Servern bereitstellt, miteinander verschmolzen.

Üblicherweise sind diese beiden Teams getrennt: Das Entwicklerteam implementiert die Software in ihren eigenen Umgebungen und übergibt sie dann an das Operations-Team, welche sie in einer anderen Umgebung bereitstellt. Dies kann zu einigen Problemen führen:

• Die Trennung der Teams führt zu Verzögerungen bei der Bereitstellung von Code.
• Die unterschiedlichen Umgebungen können zu Fehlern bei der Ausführung der Software führen.
• Die Fehler können nur durch den Umweg über das Operations-Team an die Entwickler gemeldet werden.

Bei DevOps werden diese Teams zusammengeführt, um obige Probleme zu lösen. Es ist in DevOps-Team üblich, Software inkrementell, d. h. stückweise in Form von Updates (auch Inkremente), bereitzustellen. Es ergibt sich somit eine Endlosschleife von der Entwicklung der Software über ihre Bereitstellung zurück zur Entwicklung. Das Modell ist somit agil.

DevOps zeichnet sich also nicht durch die Einführung besonderer Phasen aus, sondern durch die neuartige Arbeitsweise eines Teams. Diese Arbeitsweise erfordert die Verwendung vieler Techniken der Automatisierung, zum Beispiel automatische Tests oder automatische Bereitstellung neuen Codes.

Zusammenfassung Vorgehensmodelle

Vorgehensmodelle in der Softwareentwicklung unterteilen den Entwicklungsprozess in einzelne überschaubare Phasen. Unterschiedliche Arten der Unterteilung ergeben unterschiedliche Vorgehensmodelle. Sie erfüllen mehrere Zwecke:

• Strukturierung und verbesserte Übersicht über die Risiken des Projekts
• Erhöhung der Erfolgswahrscheinlichkeit des Projekts durch Vorabplanung
• Vereinbarung unterschiedlicher Interessen beteiligter Personengruppen

Es gibt zwei Arten von Vorgehensmodellen:

• Klassische Modelle, welche alle Planungen zu Beginn anstellen und dadurch weniger flexibel auf Änderungen reagieren können.
• Agile Modelle, welche sich durch ein hohes Maß an Kundenkontakt und ihre erhöhte Bereitschaft für Änderungen der Anforderungen auszeichnen.

Du hast folgende Vorgehensmodelle kennengelernt:

Die Grundlage eines jeden Vorgehensmodells ist die Anforderungsanalyse, bei der die Anforderungen an die Software durch Kundengespräche erfasst werden. Es gibt drei Arten, wie diese eingeholt werden können:

• Top-Down-Methode
• Botom-Up-Methode
• Evolutionäre Methode