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.

V-Modell

Das V-Modell ist ein Vorgehensmodell, welches ursprünglich für die Softwareentwicklung konzipiert wurde. Ä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

Agile Softwareentwicklungsmodelle

User Stories

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.