Methoden der Softwareentwicklung

Verschiedene Methodiken der Softwareentwicklung haben sich bewÀhrt und beweisen (weiterhin) ihre Daseinsberechtigung.


Produkttypen

Es bedarf einer klaren Abgrenzung der Produkttypen in der Softwareentwicklung.

Vorproduktiv

☐ Der proof of concept [POC], ist eine Machbarkeitsstudie, die sich nicht um weitere Rahmenbedingungen kĂŒmmern (sollte) sondern sich auf die KlĂ€rung des technisch machbaren des Produktes / der Innovation fokussiert.

☐ Der proof of value [POV] ist als Folgeschritt zum POC zu sehen ist, der auch den wirtschaftlichen Aspekt einbezieht.

☐ Der Prototyp ist ein funktionsfÀhiges Produkt, welches auf der Zielarchitektur laufen sollte. Ein Prototyp verwendet hÀufig noch Mock-FunktionalitÀten um Teile der FunktionalitÀten vorzutÀuschen.

☐ Die alpha-Version eines Produkts ist eine Version, die bewusst noch nicht fehlerbereinigt ist  bzw. zur ersten Fehlerbereinigung ausgeliefert wird. Ich empfehle ausdrĂŒcklich die semantische Versionierung fĂŒr Software und auch fĂŒr Daten und Dateien.

☐ Die beta-Version eines Produkts ist eine Version, von der angenommen wird sie enthalte keine Fehler mehr und zur PrĂŒfung dieser Annahme die Software bereitgestellt wird. Bereits mit der Bezeichnung beta wird jedoch ausdrĂŒcklich vor Fehlern gewarnt.


Produktiv

☐ Das Produkt, hĂ€ufig mit einer Version 1.0.0 beginnend, ist fĂŒr den Echteinsatz gedacht. Alternativ sind Begriffe wie Produktions- / Produktivbetrieb oder auch Wirkbetrieb in Verwendung.

☐ Das minimum viable product [MVP] ist ein produktives Produkt, welches einen minimalen fachlichen / geschĂ€ftlichen Mehrwert hat und insbesondere bei der agilen Softwareentwicklung zum Einsatz kommt. Es ist kein Prototyp, sondern ein fertiges Produkt fĂŒr den Echteinsatz / Produktionseinsatz / Wirkbetrieb.


Nachproduktiv

☐ AbgekĂŒndigte Versionen oder auch Vintage Produkte sind weiterhin im produktiven Einsatz möglich bergen jedoch Risiken bei einem weiteren Einsatz z.B. hinsichtlich Sicherheit oder technischer AbhĂ€ngigkeiten.

☐ Ungepflegte Produkte sind sowohl im Bereich der OSS als auch bei kommerzieller Software zu finden, dort u.a. auch als auslaufende Produktlinien benannt. Risiken bestehen insbesondere wenn technische AbhÀngigkeiten bestehen und nicht die Möglichkeit (kommerzielle Produkte) oder das Know-How (OSS) besteht dies aufzufangen. Die Einordnung zu nachproduktiv erfolgt aufgrund der damit verbundenen technischen Schulden und Risiken.


Agile Softwareentwicklung

Methoden der agilen Softwareentwicklung zielen darauf ab, ein möglichst schnelle Produktivsetzung durch eine evolutionÀre Fortentwicklung zu erreichen. HÀufig wird dabei mit einem Produkt gestartet, welches aufs unbedingt notwendige beschrÀnkt ist (minimum viable product - MVP).

Agile Methoden favorisieren die Anforderungen an die Software in kleinen Umsetzungsschritten. Dies beginnt beim MVP wird vor allem jedoch bereits bei der Anforderungsaufnahme umgesetzt und bedingt, dass wĂ€hrend der kompletten Umsetzungszeit kein abschließendes, mit allen abgestimmten Bild des spĂ€teren fertigen Produktes vorhanden ist. Die hĂ€ufig beschworene Nutzerzentrierung und hĂ€ufigen Feedbackschleifen können auch das Look-and-Feel der Anwendung jederzeit Ă€ndern. Agile Methoden ergĂ€nzen sich im Backend daher gut mit dem Konzept der Microservices, da auch hier kleine Softwarekomponenten bei geĂ€nderten Anforderungen „leicht“ austauschbar sind.

Der Unterschied zu einer inkrementellen Softwareentwicklung ist, wenn auch fließend, dass die AgilitĂ€t und Umsetzung in kleinen Schritten bereits bei den Anforderungen bzw. Lasten umgesetzt wird. Die Umsetzung der Software in inkrementell hingegen fokussiert sich auf ein Lastenheft mit zugehörigem Pflichtenheft, welches im Anschluss an die Erstellung in die inkrementell umzusetzenden Versionen zerlegt wird. 


KANBAN zielt u.a. darauf ab die Ziele der agilen Softwareentwicklung ohne neue Rollen, Prozesse etc. in der Organisation einzufĂŒhren. Mit dem KANBAN-Board wird der Bearbeitungsstand visualisiert. Begrenzte Ressourcen werden durch KANBAN abgebildet, indem die einzelnen Bearbeitungsschritte bewusst mit einem Limit der gleichzeitigen Aufgaben belegt werden. ErgĂ€nzt durch ein Pull-System, wo nachfolgende Bearbeitungsschritte sich ihre Aufgaben abholen wird der Arbeitsfluss gesteuert. In KANBAN werden Aufgaben nur entlang des Arbeitsfluss bearbeitet, so dass eine neue Aufgabe erst nach Abschluss der vorhergehenden begonnen wird. Hierdurch fokussiert sich KANBAN auf die Erledigung der Aufgabe. Mit Hilfe des kontinuierlichen Verbesserungsprozess (KVP / Kaizen) wird der Arbeitsfluss hierbei nachgesteuert. RegelmĂ€ĂŸiges Feedback wird zu festgesetzten Terminen eingefordert.


Scrum fĂŒhrt ein sich selbstorganisierendes Team ohne direkte Hierarchien jedoch mit Rollen des Product Owner, des Entwicklers und des Scrum Master, mit einer ĂŒblichen TeamgrĂ¶ĂŸe möglichst nicht mehr als 12 Personen. Entwicklungsschritte werden in Sprints realisiert. 

Der Product Owner ist der fachliche Produktverantwortliche der im „Product Backlog“ die Anforderungen eintrĂ€gt, welche ihn von Stakeholder und Entwicklungsteam benannt wird. Nach Scrum hat ein Product Owner Entscheidungskompetenz. Der Scrum Master steht neben dem Entwicklungsteam als Berater, Mediator, Coach und KĂŒmmerer der die Befolgung und Scrum Regeln sicher stellen soll. Scrum als Framework ist hierbei spezifisch fĂŒr das Projekt und die Organisation auszugestalten und kann beispielsweise dem Product Owner auch die Entscheidungskompetenz versagen. Das Team selbst wird interdisziplinĂ€r aufgestellt und trĂ€gt gemeinsam die Verantwortung fĂŒr die Erreichung des Ziels sowohl im Ganzen als auch fĂŒr den jeweiligen Sprint.

Ein Sprint ist eine Menge von Aufgaben die aus dem Backlog genommen werden und in dem definierten Zeitraum (= Sprint) umgesetzt werden. Nicht erledigte Aufgaben zum Ende des Sprint werden in das Backlog zurĂŒck gelegt. Hierdurch fokussiert sich Scrum auf die Einhaltung der Zeitvorgaben. Mit dem Daily Scrum des Teams wird die Selbstorganisation des Teams, ohne Product Owner und Scrum Master, zur Termintreue unterstĂŒtzt.



Obwohl Nutzerzentrierung bei jedem Vorgehensmodell Anwendung finden kann ist die Verwendung bei linearer Softwareentwicklung ungleich schwerer.

Nutzerzentrierung bedeutet hierbei insbesondere, dass neben dem Auftraggeber auch die spÀteren Anwender bereits bei der Softwareentwicklung einbezogen werden und primÀr die Nutzer die Umsetzung der FunktionalitÀten vorgeben.


Lineare Softwareentwicklung

Lineares Vorgehensmodelle gehen erst nach Abschluss eines Schrittes zum NĂ€chsten ĂŒber. Dabei profitieren diese Systeme von der Vorherbestimmtheit der Ergebnisse z.B. bei WerkvertrĂ€gen. 

‍ 

Das Wasserfallmodell setzt anders als KANBAN beim Übergang zum nĂ€chsten Schritt im Arbeitsfluss die vollumfĂ€ngliche Abarbeitung voraus, so dass die Anforderungen als Ganzes in einem Lastenheft formuliert sind, die dazugehörige Umsetzung anschließend im Pflichtenheft formuliert wird, dem nach Fertigstellung die Implementation folgt. Die Gesamtsicht auf die jeweiligen Schritte ermöglichen bei Auftragsvergabe (als Werkvertrag) jeder Seite einen verlĂ€sslichen Auftrags- / Vertragsgegenstand als Basis zu haben. Der komplette Produktumfang ist nach dem Lastenheft definiert und qualitativ und quantitativ verifizierbar.

SpĂ€tere Änderungen der Anforderungen mĂŒssen explizit neu beauftragt werden. Soweit Lasten- und Pflichtenheft auch im Rahmen der Wartung der fertigen Produkte gepflegt werden, liegt jederzeit ein dokumentiertes und pflegearmes Gesamtsystem vor.

Software kann auch mit dem Wasserfallmodell inkrementell entwickelt werden, indem mehrere Projekte nacheinander aufgesetzt werden.