Dein Webbrowser blockiert JavaScript! Bitte aktiviere JavaScript, um sicher zu stellen, dass die Website richtig funktioniert!

Software Entwicklungsstadien

Begriffsklärung

Entwicklungsstadium: Dieses kann am ehesten mit einer Produktentwicklung aus der Betriebswirtschaftslehre verglichen werden. In der Softwareentwicklung ist es die Beschreibung des aktuellen Fertigstellungszustandes. Das ist wie mit der Entwicklung und Herstellung z.B. einer Grafikkarte. Zu einem bestimmten Zeitpunkt im gesamten Prozess bis zum fertigen Produkt hat das Produkt (Grafikkarte, Software, …) bestimmte Meilensteine und Teilprozesse bereits durchlaufen.

Software: Der Begriff ist weit gefächert. Dieser beschreibt nicht nur den Programmcode oder Quellcode eines Programmes, sondern kann eher als ein Sammelbegriff für alle möglichen unterschiedlichen Programme und die zugehörigen Daten gesehen werden. Diese Daten können unter anderem auch Softwaredokumentation, Bilder oder Cheat-Sheets umfassen.

Wozu Software Entwicklungsstadien?

Kleine Programme mit überschaubarem Funktionsumfang benötigen meist keine Entwicklungsstadien. Prototypen, die z.B. nur grobe Funktionalität besitzen sollen, werden größtenteils nicht einmal als eine Alpha-Version bezeichnet, sondern nur als Prototyp oder als erster “Proof-of-Concept“.

Die Softwarestadien sollen helfen und Überblick schaffen über den aktuellen Entwicklungsstand und die zukünftigen Entwicklungen. Jedes Stadium der Entwicklung soll bestimmte Aufgabenbereiche abdecken. Diese Aufgabenbereiche werden in einer nützlichen Reihenfolge durchgeführt und sollen vor allem bei größeren Teams und komplexen Softwares dafür sorgen, Struktur in die Bearbeitung der Entwicklung zu bringen.

Welche Entwicklungsstadien gibt es?

Je nach Hersteller oder Community können die Bezeichnungen für die einzelnen Stadien variieren. Es haben sich in den vergangenen Jahrzehnten die Bezeichnungen wie Alpha, Beta, … oder auch „aktueller Build“, „aktueller Release“, … durchgesetzt. Bei der Anwendung der Unterteilungen sollte nicht zu sehr vom allgemeinen Standard abgewichen werden. Dies kann später hinzukommende Personen zu einem Projekt verwirren. Ebenfalls bürgern sich dann Eigenarten ein, welche im späteren Verlauf (z.B. nach 1 bis 2 Jahren) zu Problemen in der Aufarbeitung von Kinderkrankheiten der Software führen können. Die folgenden sind ein Auszug.

Pre-Alpha:

Jeder mögliche frühe Entwicklungsstand ist im Grunde eine Pre-Alpha. Somit ist jeder Proof-Of-Concept oder Prototyp bereits eine Pre-Alpha. Teilweise werden diese auch als Nightly-Build oder kurz als Nightly bezeichnet. Oft fehlen in Pre-Alphas größere Unittests oder auch stabile Integrationen in eine bestehende Software, wenn die Pre-Alpha z.B. ein Modul für eine Softwareerweiterung ist.

Alpha/ Entwicklervorschau

Dies ist bereits eine Version, die auch zum Testen an externe Personen gegeben werden kann. Hier geht es vor allem darum, die ersten Schwächen und Bugs unter Real-Bedingungen im Programmablauf zu finden. Entwickler*innen z.B. der Spiele-Branche nutzen eine Alpha gerne auch, um diese einer ausgewählten Anzahl an Spieler kostenlos spielen zu lassen. Das gewonnene Feedback und auch mitunter Leistungsdaten auf z.B. unterschiedlichen PCs geben den Entwickler*innen viele Vorteile für die weiteren Entwicklungsentscheidungen. Gerne wird eine Alpha auch für die Präsentation für einen oder mehrere Kunden und/ oder andere Entwickler benutzt, um weitere Tests zu planen.

Die meisten gröberen Funktionen sind zwar bereits enthalten, jedoch ist die Erweiterung, Präzisierung und Einbau weiterer neuer Funktionen meist unerlässlich. Weiter werden diese Versionen auch als Developer-Preview oder Developer-Releases bezeichnet.

Beta:

Software erreicht einen stabilen und zuverlässigen Entwicklungsstand, diese werden dann als Beta-Versionen bezeichnet. Diese Veröffentlichungen sind die häufigsten Erstveröffentlichungen des Produktes. Es sind alle Funktionen enthalten, die teilweise noch schwere Bugs hervorrufen können. Diese Bugs sind unbekannt und deswegen lohnt es sich viele Beta-Tester zu haben. Gleichzeitig ist die Ermittlung von eventuellen Konflikten mit anderen Programmen oder auch Hardware von Endgeräten möglich. Diese werden dann von den Entwicklern erfasst und für die nächsten Veröffentlichungen der Beta behoben.

Die öffentlichen Tests werden entweder als Closed-Beta (geschlossene Beta) oder Open-Beta (offene Beta) bezeichnet. Ein Closed-Beta-Release ist nur für eine bestimmte Anzahl oder auch Gruppe von vorab Bewerbern zugänglich. Eine Open-Beta hingehen ist für alle, die sich auch während des Tests der Open-Beta anmelden nutzbar. Meist sind Beta-Tests zeitlich begrenzt und sind je nach Branche und Ziele der Entwickler*innen unterschiedlichen Gruppen von möglichen Nutzer*innen zugänglich.

Perpetual Beta:

Diese Sonderform wird auch gerne als „Software nach dem Bananenprinzip“ beschrieben. Die kontinuierliche Weiterentwicklung des Software-Produktes steht dabei im Vordergrund. Die Kunden erhalten somit kein fertiges Endprodukt, sondern eher eine Bananenkiste mit unreifen grünen Bananen. Diese sollen dann beim Kunden reifen und erst später eine schöne verzehrbare Gestalt annehmen. Das umschreibt bildlich eine Software, die wissentlich in den Einsatz beim Kunden eingebracht wird, aber in bestimmten Bereichen noch gar nicht Releasefähig und für den Kunden entsprechend den Anforderungen einsatzbereit ist.

Gamma / Delta (Release Candidates):

Diese Versionen sind für den aktiven Release (Veröffentlichung) potenzielle Kandidaten (Candidates). Teilweise findet sich auf die Bezeichnung Prerelease (Vorabveröffentlichung), welcher eine Softwareversion beschreibt, die bereits dicht an einem ersten Release liegen soll. Die Bezeichnungen Gamma und Delta für diese Entwicklungsstände der Software haben sich nicht unbedingt durchgesetzt. Obwohl mitunter Versionen, die einem Release-Candiate sehr nahe kommen, aber dieser noch nicht sind, als Gamma-Version bezeichnet werden können.

In diesen Versionen sind alle bisher bekannten Fehler behoben oder so gefixt worden, dass diese keine schweren Bugs mehr hervorrufen können. Also diese Fehler auch in naher Zukunft komplett gefixt sein werden. Aus diesen Kandidaten kann dann ein Produkttest entworfen werden, welcher die Qualität überprüft und ggf. noch verbliebene Programmfehler aufspürt. Wird etwas geändert, müssen alle Tests wiederholt werden, um die Qualitätssicherheit zu gewährleisten.

Release:

Die Veröffentlichung des fertigen oder ersten fertigen Softwareproduktes (Hauptversion). Die Versionsnummer wird um+1 erhöht. Auf den Release folgen Unstable- und Stable-Versionen, welche ein Abbild eines Entwicklungsstandes sind. Oft wird bei Softwareprojektes auch eine Unstable-Version angeboten. Diese funktioniert im Allgemeinen auch mit neuen hinzugefügten Features, aber konnte bisher nicht alle Tests bestehen.

Final:

Das Softwareprodukt ist vollständig entwickelt und wird jetzt nur noch vervielfältigt. Tests und Bugfixes sind im Allgemeinen nicht mehr vorgesehen, auch wenn neue Bugs gefunden werden. Vor allem für Frameworks, Softwareprogramme wie Gimp, Blender, Photoshop, Krita, Virenscanner, … wird es eine Final-Version wahrscheinlich nie geben, da an diesen Produkten kontinuierlich weiterentwickelt wird.

Versionsnummern und Versionsnamen

Softwareentwicklerinnen oder auch aus Marketinggründen geben Release-Versionen z.B. gerne auch Namen. Die Entwicklerinnen von Kirby CMS gaben einigen Versionen Namen, z.B. „Kirby 3.5 Calumma“ oder „Kirby 3.6 Jungle Calumma“. Oft stehen auch nur Release-Nummerierungen, bestehend aus drei Digit für eine stabile und im Realeinsatz nutzbare Version. Die einzelnen Digit stehen dabei für Hauptversion, Nebenversion und Revisionsnummer. Ein viertes Digit ist oft für Außenstehende nicht einsehbar. Dieses steht für Buildnummer, welche im internen Entwicklerteam für Unterscheidung einzelner Softwarestände genutzt wird.

Beispiel: 1.16.4 steht für

Dieses Vorgehen aus dem Beispiel wird für die Software Blender genutzt. Es können alle älteren Version eingesehen und auch heruntergeladen werden. Dafür stellt blender.org eine Release-Seite zur Verfügung, welche auch einer schicken einfachen Liste einsehbar ist. In der Liste sind alle Softwareversionen für Linus und Windows-Plattformen zu finden. Da sich die Software in einer beständigen Weiterentwicklung befindet und viele Entwickler*innen an diesem Tool arbeiten sind mehre Releases im Jahr vorhanden, welche eine Namensbenennung eher auch verwirrend machen könnten. Zumal die aufwendige Präsentation für sich spricht.

Versionierung von Software mit Versionsnummern und für Releases mit Namen.

Prozessablauf der Software Entwicklungsstadien

Die Prozesse zwischen den einzelnen Versionen und Stadien sind agil. Jedes Stadium hat seine bestimmten Kernziele. Erst, wenn diese erfüllt sind, wird zum nächsten Stadium übergegangen. Versionierungstools wie Git helfen Entwickler-Teams, die Struktur und Reihenfolgen beizubehalten.

Beispiel: Angenommen, ein Entwickler-Team besteht aus zwei Senior-Developer und vier Software-Entwickler*innen und zwei Junior-Entwicklern*innen. Alle Entwickler*innen arbeiten mithilfe von Git. Mit großer Wahrscheinlichkeit haben nur die zwei Senior-Entwickler die Befugnis, vom Dev-Branch auf den Master-Branch zu committen und zu pushen. Die anderen Entwickler*innen arbeiten auf dem Dev-Branch und Feature-Branches. Somit liegt die Entscheidungsgewalt über die Versionsnummern, die ein Softwarestand erhält, bei den Senior-Developern. Der vierte Digit hingegen kann von allen genutzt werden.

Es gibt unterschiedliche Beispiele. Ein Entwickler*in allein wird wahrscheinlich nur einen Master- und einen Dev-Branch mit ein oder zwei Feature-Branches haben. Ebenfalls gibt es unterschiedliche Workdlows für Git und so weiter… Es hängt vom Projekt und Team ab, wie die Versionierung im Real-Projekt umgesetzt wird. Meist wird von diesem Vorgehen wie oben beschrieben aber nur wenig abgewichen. Denn es hat sich in den Jahrzehnten der Softwareentwicklung als produktiv und zielführend herausgestellt.

Weitere Informationen