Softwareentwicklungsmodelle: Unterschied zwischen den Versionen
Drlue (Diskussion | Beiträge) |
Drlue (Diskussion | Beiträge) |
||
| Zeile 20: | Zeile 20: | ||
# Anforderungsanalyse und -spezifikation. Resultiert im {{Link|Lastenheft}}. | # Anforderungsanalyse und -spezifikation. Resultiert im {{Link|Lastenheft}}. | ||
# Systemdesign und -spezifikation. Resultiert in der Softwarearchitektur. | # Systemdesign und -spezifikation. Resultiert in der Softwarearchitektur. | ||
# Programmierung und Modultests resultiert in der eigentlichen Software. | # Programmierung und {{Softwarequalitätsmanagement|Unit_Test|Modultests}} resultiert in der eigentlichen Software. | ||
# Integrations- und Systemtest. | # {{Softwarequalitätsmanagement|Integrationstest|Integrations}}- und {{Softwarequalitätsmanagement|Systemtest|Systemtest}}. | ||
# Auslieferung, Einsatz und Wartung. | # Auslieferung, Einsatz und Wartung. | ||
Version vom 6. Februar 2021, 18:35 Uhr
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.[1]
Pflichtenheft
Das Pflichtenheft ist die Antwort auf das Lastenheft. Im Pflichtenheft beschreibt der Auftragnehmer wie er das Projekt des Auftraggebers umsetzen kann und wird.[2]
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:

Phasen
Im folgenden werden die Phasen kurz erläutert.
- Anforderungsanalyse und -spezifikation. Resultiert im Lastenheft.
- Systemdesign und -spezifikation. Resultiert in der Softwarearchitektur.
- Programmierung und Vorlage:Softwarequalitätsmanagement resultiert in der eigentlichen Software.
- Vorlage:Softwarequalitätsmanagement- und Vorlage:Softwarequalitätsmanagement.
- 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

Quellen
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.[6]
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.
Scrum
Rollen
Product Owner
Scrum Master
Entwicklerin
Aktivitäten
Daily Scrum
Sprint Planning
Sprint Review
Sprint Retrospektive
- ↑ https://at.gruender.de/buchhaltung/pflichtenheft-lastenheft/#lastenheft-und-pflichtenheft-die-definitionen
- ↑ https://at.gruender.de/buchhaltung/pflichtenheft-lastenheft/#definition-pflichtenheft-die-antwort-auf-das-lastenheft
- ↑ 3,0 3,1 https://de.wikipedia.org/wiki/Wasserfallmodell
- ↑ 4,0 4,1 https://de.wikipedia.org/wiki/V-Modell
- ↑ https://deacademic.com/dic.nsf/dewiki/407012
- ↑ https://de.wikipedia.org/wiki/User_Story