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 obiger 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 - Scrum

Im folgenden soll auf das Agile Softwareentwicklungsmodell Scrum eingegangen werden. Scrum besteht aus nur wenigen Regeln. Diese Regeln beschreiben vier Ereignisse, drei Artefakte und drei 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
Die Software wird Schritt für Schritt um Features ergänzt.

iterativ - in Schleifen durchlaufend, sich wiederholend
Der Komplette Prozess von Planung, Entwicklung und Abnahme wiederholt sich in kurzen Zyklen.

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 kein aufwändiges Lasten- und Pflichtenheft definiert, sondern Anforderungen aus der Anwendersicht formuliert (siehe User Stories). 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, dem Product Increment. Dieses Produktinkrement sollte immer in einem herzeigbaren Zustand sein, sodass es dem Kunden ausgeliefert werden kann. Weiters 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 weiteren Begrifflichkeiten von Scrum erläutert.

Scrum

Sprint

Ein Sprint ist ein zeitlich begrenzter Arbeitsabschnitt (1 - 4 Wochen) an dessen Ende ein Produktinkrement steht. Der Sprint beginnt mit dem Sprint Planning und endet mit dem Sprint Review und der Sprint Retrospektive. Während eines Sprints sollten keine Tasks im Sprint Backlog hinzugefügt, gelöscht oder geändert werden.

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.

Product Owner

Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich. Er erstellt und priorisiert die zu entwickelnden Produkteigenschaften. Also was, wann, entwickelt werden soll. Die Produkteigenschaften hält er in Zusammenarbeit mit den Entwicklern und den Stakeholdern im Product Backlog fest.

Scrum Master

Der Scrum Master ist Verantwortlich für die Umsetzung des Scrum Regelwerks. Er organisiert und moderiert meist die Ereignisse und arbeitet stark mit den Entwicklern zusammen, gibt diesen aber keine Anweisungen. Weiters gehören in seinen Aufgabenbereich die Beseitigung von Hindernissen und Störquellen für das Team. Dazu gehören auch administrative Tätigkeiten (wie z.B. das Organisieren von Equipment und ähnliches) und zwischenmenschliche Tätigkeiten (z.B. Streitschlichtung).

EntwicklerIn

Die Entwickler sind für die Lieferung der Produktfunktionalität und die Einhaltung von vereinbarten Qualitätsstandards verantwortlich. Die Entwickler sind selbst organisiert und lassen sich von niemandem bei der Umsetzung von Sprint Backlog Einträgen beeinflussen. Weiters sollten sie in der Lage sein, die Ziele des Sprints selbstständig erreichen, d.h. ohne Abhängigkeiten von Außen, zu können. Deswegen sind Entwicklerteams am besten interdisziplinär aufzustellen (Softwarearchitekt, Designer, Entwickler, Tester, Dokumentationsexperte,...). Schlagen Ziele eines Sprints fehl, so ist dies nie die Schuld eines einzelnen Individuums, sondern des gesamten Scrum Teams.

Stakeholder

Die Stakeholder sind kein Teil des Scrum Teams, sind jedoch Stark in den Entwicklungsprozess eingebunden. Kunden als auch Anwender sollten nach Möglichkeit beim Sprint Review als auch beim Backlog Refinement teilnehmen um ihr Feedback abzugeben.

Kunden

Für die Kunden wird das Projekt entwickelt. Der Product Owner hat die Aufgabe die Kunden durch die Lieferung des Wunschproduktes zufrieden zu stellen. Um dies zu gewährleisten sollten Product Owner und Kunden im engen Austausch stehen. Der Product Owner sollte bereits vor Beginn des Auftrages ein möglichst gutes Verständnis von den Wunschvorstellungen des Kunden haben.

Anwender

Die Anwender sind diejenigen Personen, welche das Produkt auch benutzen werden. Ein Anwender kann, muss aber kein Kunde sein. Für das Scrum Team sind die Anwender besonders wichtig, da nur Sie das Produkt aus der Perspektive des Benutzers beurteilen können.

Management

Das Management ist Verantwortlich für die Schaffung geeigneter Rahmenbedingungen. Dies umfasst die Bereitstellung von Räumen, Arbeitsmitteln, die Abschottung von externen Arbeitsanforderungen und weiteren Störfaktoren. Weiters sollte das Management den Scrum Master dabei unterstützen, Hindernisse aus dem Weg zu räumen.

Ereignisse

Im folgenden werden die Ereignisse von Scrum erläutert.

Daily Scrum

Findet während eines aktiven Sprints statt und bildet einen täglichen Fixpunkt, der zu Beginn des Arbeitstages stattfindet. Jeder Entwickler gibt über seinen aktuellen Stand der Arbeit Auskunft, und was bis zum nächsten Daily Scrum erreicht werden soll. Zusätzlich werden Hindernisse kommuniziert. Der Daily Scrum sollte zeitlich stark beschränkt werden und maximal 15 Minuten dauern. Reicht diese Zeit nicht aus, so kann Weiterführendes auf Folgemeetings verschoben werden.

Hindernisse werden im Kontext von Scrum Impediments genannt.

Sprint Planning

Im Sprint Planning wird festgelegt, was und wie es im kommenden Sprint erledigt werden soll und die Ziele werden festgelegt. Für das Sprint Planning sollte das Product Backlog bereits so detailliert und vorbereitet sein, dass der Sprint mit Einträgen gefüllt werden kann.

Die Einträge im Product Backlog müssen bereits in passende Tasks unterteilt worden sein. Das wird hier unter detailliert verstanden (siehe Backlog Grooming).

Sprint Review

Am Ende jedes Sprints wird das Sprint Review durchgeführt. Hierbei wird das Produktinkrement überprüft um zu sehen ob die Anfangs gesteckten Ziele erfüllt wurden. Das Scrum Team und die Stakeholder besprechen das Ergebnis, weitere Schritte bzw. Anpassungen fließen dann ins Product Backlog ein.

Sprint Retrospektive

Die Sprint Retrospektive steht ebenfalls am Ende des Sprints. Hierbei wird das generelle Vorgehen während des Sprints besprochen und optimiert. Die Arbeitsweise soll ehrlich und offen überprüft und diskutiert werden. Wichtig ist hierbei herauszufinden, in welchen Punkten sich das Scrum Team verbessern kann.

Artefakte

Im Folgenden werden die Artefakte von Scrum besprochen.

Product Backlog

Das Product Backlog ist eine geordnete Auflistung der Anforderungen an das Produkt. Weiters ist es dynamisch und wird ständig erweitert. Jegliche Arbeit die durch das Entwicklungsteam geleistet wurde, muss ihren Ursprung im Product Backlog haben. Der Product Owner ist für die Pflege des Product Backlog verantworlich und nimmt die Reihung und Priorisierung vor. Die Anforderungen sollten fachlich und anwenderorientiert sein, hierfür können User Stories verwendet werden.

Backlog Refinement

Im Backlog Refinement wird das Backlog modifiziert. Anforderungen werden:

• detailliert
  • User Stories werden in bewältigbare Tasks unterteilt
  • Zu große Tasks werden in kleinere Tasks unterteilt
• zusammengefasst
• geschätzt
• geordnet
• gelöscht

Weiters findet hier die Release Planung statt.

Beim Schätzen von Tasks werden normalerweise sogenannte Story Points verwendet. Hierbei wird kein Wert im Sinne von Stunden verwendet, sondern die Komplexität. Vielfach wird als 1 Story Point eine triviale Aufgabe angenommen. 2 Story Points wäre dann einfach, 3 Story Points mittel. Die konkrete Einteilung kann je Nach Scrum Team variieren.

Weiters werden für die Story Points auch oft die Fibonacci-Zahlen verwendet, um die zunehmende Unsicherheit, je schwerer eine Aufgabe ist, zu verdeutlichen.

Je nach Scrum Team werden, sobald Tasks die eine gewisse Anzahl an Story Points überschreiten in kleinere Tasks unterteilt.

Sprint Backlog

Das Sprint Backlog ist der Plan für den aktuellen Sprint. Dieser enthält die ausgewählten Einträge (z.B. User Stories) aus dem Product Backlog und die dazugehörigen Tasks die in dieser Zeitspanne erledigt werden sollen.

Product Increment

Das Produktinkrement besteht aus allen Product Backlog Einträgen, die in einem Sprint und allen vorhergehenden Sprints erledigt wurden. Es ist einfach das fortschreitende Produkt.

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).

Taskboard

Das Taskboard wird in einem Sprint verwendet um den aktuellen Status zu repräsentieren. Im laufe des Sprints werden Tasks auf dem Taskboard verschoben.

Taskboard

In der Grafik sind in der ersten Spalte die User Stories ersichtlich. Diese sind unterteilt in mehrere Tasks welche sich, je nach Fortschritt, in den Zeilen rechts daneben befinden.

Burndown Chart

Der Burndown Chart ist das Mittel zur Wahl um den Fortschritt während eines Sprints zu überprüfen. Es gibt ihn weiters in der Variante als Release Burndown Chart, hierbei wird der Chart über mehrere Sprints geführt. Der Burndown Chart bietet die Möglichkeit zu visualisieren in wieweit sich das Scrum Team von der Planung entfernt, oder ob es im Zeitplan liegt. Ebenso kann die Velocity des Entwicklungsteams leicht abgelesen werden.

Velocity - Wieviele Story Points schafft eine Entwicklungsteam pro Sprint

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. Die dabei für jede User Story erwünschten Eigenschaften wurden von Bill Wake zum Akronym INVEST zusammengefasst. Es steht für:

• Independent – unabhängig. Sie sollte nach Möglichkeit nicht von anderen User Stories abhängen.
• Negotiable – verhandelbar. Sie sollte keine Umsetzungsdetails festlegen.
• Valuable – nützlich. Ihre Umsetzung erhöht den Gebrauchswert des Produkts für den Endkunden.
• Estimable – schätzbar. Der Aufwand für die Umsetzung muss abschätzbar sein.
• Small – klein. Der Aufwand für die Umsetzung sollte überschaubar sein. Erstrebenswert sind einige Arbeitstage, maximal einige Wochen.
• Testable – überprüfbar. Ihre erfolgreiche Umsetzung sollte sich mit objektiven Kriterien überprüfen lassen.

Beispiele

• Als BenutzerIn möchte ich mich auf der Webseite anmelden können.
• Als BenutzerIn möchte ich mein Benutzerprofil einsehen können.
• Als BenutzerIn möchte ich mein Passwort ändern 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 BenutzerIn 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.
• Als AdministratorIn möchte ich Benutzer löschen können.

Weiterführende Anforderungen

• Transparenz des Fortschritts - Dies kann Beispielsweise mit dem Zusatzinstrument Burndown Chart realisiert werden.
• Definition of Done - Wann ist eine Aufgabe wirklich abgeschlossen? Das Scrum Team muss sich darüber einig sein. (Z.b. Implementiert und getestet)
• Definition of Ready - Kann mit der Implementierung einer Aufgabe wirklich begonnen werden? Sind alle Vorbedingungen erfüllt um eine reibungslose Implementierung zu ermöglichen?