Softwareentwicklungsmodelle

Softwareentwicklungsmodell bieten eine Vorgehensweise wie ein Softwareprojekt durchgeführt werden soll.

Klassische Softwareentwicklungsmodelle

Im folgenden wird auf zwei klassische Softwareentwicklungsmodelle eingegangen. Das Wasserfallmodell und dessen Erweiterung, das V-Modell. Beide beschriebenen Softwareentwicklungsmodelle zeichnen sich vorallem durch ihr lineares Vorgehen aus. D.h. die Phasen werden immer nur in einer Richtung durchlaufen.

Lasten vs. Pflichtenheft

Beide spielen in klassischen Softwareentwicklungsmodellen eine wichtige Rolle. Doch was ist eigentlich der unterschied?

Lastenheft

Das Lastenheft sind die Erwartungen an das Projekt aus der sicht des Kuden. Es könnte auch Kundenspezifikation oder Anforderungskatalog bezeichnet werden. Das Lastenheft führt beim Kunden zu einem intensiven Auseinandersetzen mit dem Auftrag. Er muss sich genau darüber Gedanken machen was er sich eigentlich vom Auftrag erwartet und was er genau haben will. Ein gut ausgearbeitetes Lastenheft ist eine sehr gute Arbeitsgrundlage für den Auftragnehmer.

Pflichtenheft

Das Pflichtenheft ist die Antwort auf das Lastenheft. Im Pflichtenheft beschreibt der Auftragnehmer wie er das Projekt des Auftraggebers umsetzen kann und wird.

Wasserfallmodell

Das Wasserfallmodell ist wie schon beschrieben ein lineares Modell, die Phasen werden der Reihe nach durchlaufen. Die Ergebnisse einer Phase fließen als Input in die nächste Phase, deswegen Wasserfall. Das Wasserfallmodell wird je nach Definition mit mehr oder weniger Phasen beschrieben, im folgenden soll die Variante mit 5 Phasen beschrieben werden:

Wasserfallmodell

Phasen

Im folgenden werden die Phasen kurz erläutert.

1. Anforderungsanalyse und -spezifikation. Resultiert im Lastenheft.
2. Systemdesign und -spezifikation. Resultiert in der Softwarearchitektur.
3. Programmierung und Modultests resultiert in der eigentlichen Software.
4. Integrations- und Systemtest.
5. Auslieferung, Einsatz und Wartung.

Vorteile

• Phasen sind klar Abgegrenzt
• Planung und Kontrolle einfach möglich
• Kosten und Umfang können bei stabilen und klaren Anforderungen gut abgeschätzt werden

Nachteile

• Klar abgegrenzte Phasen sind oft unrealistisch. Teile eines Systems können sich noch in der Planung befinden, während andere schon implementiert oder betriebsbereit sind.
• Die Phasen laufen klar sequenziell ab, in der Praxis sind jedoch Rückschritte (z.B.: zurück zur Planung) oft unvermeidlich.
• Das frühe festschreiben der Anforderungen kann sehr problematisch sein. Sind Änderungen nötig, so muss der Prozess wieder komplett durchlaufen werden.
• Einführung des vollständigen Systems zu einem späten Zeitpunkt, Fehler werden unter Umständen erst spät erkannt und müssen mit hohem Aufwand entfernt werden.

Es kann angemerkt werden, dass das Wasserfallmodell für Projekte, welche wirklich klar und sehr gut durch den Kunden spezifiziert werden können, geeignet ist. Eine Beteiligung des Kunden wird nur in der Planungsphase benötigt. Dannach wird bis zur Auslieferung kein Kundenkontakt vorgeschrieben. Hierbei kann es dann zu großen Unterschieden zwischen dem was sicher der Kunde erwartet und des was er bekommt, kommen. Weitere Änderungswünsche durch den Kunden stellen nach der Anfangsphase des Projekts Neuanträge dar.

V-Modell

Ähnlich dem Wasserfallmodell organisiert es den Softwareentwicklungsprozess in Phasen. Zusätzlich zu diesen Entwicklungsphasen definiert das V-Modell auch das Vorgehen zur Qualitätssicherung (Testen), indem den einzelnen Entwicklungsphasen Testphasen gegenüber gestellt werden. Auf der linken Seite wird mit einer funktionalen/fachlichen Spezifikation begonnen, die immer tiefer detailliert zu einer technischen Spezifikation und Implementierungsgrundlage ausgebaut wird. In der Spitze erfolgt die Implementierung, die anschließend auf der rechten Seite gegen die entsprechenden Spezifikationen der linken Seite getestet wird. So entsteht bildlich das namensgebende „V“, welches die einzelnen Entwicklungsebenen ihren jeweiligen Testebenen gegenüberstellt.

V-Modell

Fehlerbeseitigungskosten

Fehlerbeseitigungskosten je nach Phase

In obgiger Grafik ist sehr gut ersichtlich, dass die Anzahl der eingebrachten Fehler bei der Entwicklung eines Softwaresystems in den Anfangsphasen am höchsten ist.

Unter Fehler wird hier auch ein Abweichen von den Anforderungen oder auch eine Inkonsistenz in den selbigen verstanden

Erkannt werden diese Fehler erst zu einem späten Zeitpunkt. Dies kann auf die wenig vorhandene Einbeziehung des Kunden und schlechte Spezifikation der Anforderung durch den Kunden zurückgeführt werden. Weiters ist dem Kunden oft auch nicht klar, was er eigentlich will, so kann das erwartete vom gelieferten des Softwareprodukts stark auseindandergehen. Je früher die Fehler auftreten, desto höher sind deren Beseitigungskosten, da bereits mehrere Phasen durchlaufen wurden. Die Beseitigung erforder ein erneutes durchlaufen dieser Phasen. Agile Softwareentwicklungsmodelle versuchen diesem Umstand, durch starke Kundeneinbindung und kurze Releasezyklen entgegenzuwirken. Somit sieht der Kunde nicht erst nach vielen Wochen oder Monaten den Fortschritt des Projekts.

Agile Softwareentwicklungsmodelle

Im folgenden soll auf das Agile Softwareentwicklungsmodell Scrum eingegangen werden.

Scrum

Scrum besteht aus nur wenigen Regeln. Diese Regeln beschreiben vier Ereignisse, drei Artefakte und drei {{Link|Rollen}, die den Kern ausmachen. Bei der konkreten Umsetzung dieser Regeln gibt es jedoch viel Freiraum und Gestaltungsmöglichkeit.
Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Das Modell beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind um diese komplett durchzuplanen.

empirisch - auf Erkenntnis beruhend

inkrementell - Schritt für Schritt

iterativ - in Schleifen durchlaufend, sich wiederholend

Es wird davon ausgegangen dass ein Großteil der Anforderungen zu Beginn unklar ist. Diese Unklarheit kann durch Zwischenergebnisse beseitigt werden. Anhand von Zwischenergebnissen können fehlende Anforderungen und Lösungstechniken effizienter gefunden werden als durch eine abstrakte Klärungsphase, wie dies Beispielsweise beim Wasserfallmodell in der ersten Phase der Fall ist. Nicht nur das Produkt sondern auch die Planung ist iterativ und inkrementell. Das Product Backlog, der langfristige Plan, wird kontinuierlich verfeinert, siehe Backlog Refinement. Das Sprint Backlog stellt den Detailplan dar und wird immer nur für den nächsten Sprint erstellt.

Die empirische Verbesserung fußt auf drei Säulen:

• Transparenz: Fortschritt und Hindernisse eines Projektes werden regelmäßig und für alle sichtbar festgehalten.
• Überprüfung: Projektergebnisse und Funktionalitäten werden regelmäßig abgeliefert und bewertet.
• Anpassung: Anforderungen an das Produkt, Pläne und Vorgehen werden nicht ein für alle Mal festgelegt, sondern kontinuierlich und detailliert angepasst. Scrum reduziert die Komplexität der Aufgabe nicht, strukturiert sie aber in kleinere und weniger komplexe Bestandteile.
  
  

Das Ziel von Scrum ist die schnelle und kostengünstige Entwicklung hochwertiger Produkte. Es werden keine Aufwändigen Lasten und Pflichtenheft definiert, sondern Anforderungen aus der Anwendersicht formuliert. Die Liste dieser Anforderungen stellt das Product Backlog dar. In jedem Sprint werden Teile des Product Backlogs umgesetzt, und am Ende jedes Sprints steht die Auslieferung eines fertigen Teilprodukts, Product Increment. Dieses Produktinkrement sollte immer in einem herzeigbaren Zustand sein, sodass es dem Kunden ausgeliefert werden kann. Am Ende eines Sprints wird das Produkt (siehe Sprint Review, die Anforderungen (siehe Backlog Refinement) und das Vorgehen (siehe Sprint Retrospektive überprüft und verbessert.
Folgende Grafik, soll das Vorgehen von Scrum in seiner Gesamtheit beschreiben, im nachfolgenden Teil werden alle Rollen, Artefakte und Ereignisse, sowie einige

Scrum

Rollen

Ein Scrum Team besteht aus drei Rollen, Product Owner, Scrum Master und EntwicklerIn. Das Scrum Team tritt mit den Beteiligen, den Stakeholdern in Kontakt.

Scrum Master

Der Scrum Master organisiert eigentlich alle Aktivitäten

Ergänzende Techniken

Im folgenden werden einige wichtige Techniken, die in Zusammenhang mit Scrum verwendet werden, erläutert. Diese gehören jedoch nicht zum Scrum Core (Kern).

User Story

Eine User Story („Anwendererzählung“) ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze.

Beispiele

• Als Benutzer möchte ich mich auf der Webseite anmelden können, um mein Benutzerprofil einsehen zu können.
• Als Benutzerin möchte ich mich von der Webseite abmelden können und nach erneutem besuchen der Webseite nicht mehr angemeldet sein.
• Als Benutzer möchte ich, wenn ich mein Passwort vergessen habe, über einen Passwort zurücksetzen Link, mein Passwort zurücksetzen können.
• Als Benutzerin möchte ich Artikel in meinen Favoriten speichern können.