Ein Entwicklungsstadium ist in der Softwaretechnik der Fertigstellungszustand, den ein zu erstellendes Softwareprodukt zu einem bestimmten Zeitpunkt erreicht hat oder erreichen soll. Die relevanten Stadien werden im Rahmen des Projektmanagements zeitpunktbezogen und inhaltlich festgelegt. Sie basieren auf dem für das Projekt gewählten Vorgehensmodell, seinen Aktivitäten und Meilensteinen oder auf Festlegungen in herstellerspezifischen Methodenkonzepten und Entwicklungsumgebungen.
Im engeren Sinn bezieht sich der Begriff Entwicklungsstadium auf ausführbare Software, d. h. auf lauffähige Programme, die im Rahmen von Releasemanagement-Prozessen eines Projekts zum Testen oder an ihre Benutzer bereitgestellt werden. Je nach Projektsituation, oft in kleineren Wartungsprojekten, entfallen manche Stadien, sie werden zusammengelegt oder die Software wird nur als eine einzige finale Version bereitgestellt.
In erweitertem Sinn ergeben sich unterschiedliche Entwicklungsstadien für Software im gesamten Projektverlauf, in dem auch in konzeptionellen Projektphasen Ergebnisse entstehen, die bestimmten Meilensteinen (‚Entwicklungsstadien‘) zugeordnet sind. Beispiel siehe.Ralf Ötinger Benutzergerechte Softwareentwicklung Stadien: Problemanalyse, Anforderungsdefinition Am Ende jedes Stadiums werden die definierten Projektergebnisse in nachfolgende Bearbeitungsstufen übergeleitet.
Nach dem Erreichen des Software-Endzustands beginnt der Entwicklungszyklus i. d. R. mit Maßnahmen/Projekten zur Anwendungserweiterung wieder neu – mit dem Ziel einer neuen Software-Version.
Zweck/Unterschiede Die Zielsetzung für die Festlegung mehrerer Entwicklungsstadien ist im Allgemeinen, im Projektverlauf Fixpunkte mit definierten Reifegraden zu erreichen, um die anschließenden Aktivitäten sicher(er) bearbeiten zu können. Häufig werden unterschiedliche Entwicklungsstadien z. B. beim Softwaretest praktiziert, um in nachgelagerten Teststufen/Testarten Funktionsdetails überprüfen zu können, die auf bereits im vorhergehenden Stadium getesteten Funktionalitäten aufsetzen.
Unterschiede zwischen den einzelnen Software-Entwicklungsstadien für Computerprogramme können zum Beispiel folgende sein – um für den jeweils als Beispiel angegebenen Freigabezweck verwendet zu werden: Manche Funktionen sind noch nicht realisiert; um einzelne Funktionen vorweg zu testen … oder sind nur in einfacher Form (ohne Spezialfälle) realisiert; ebenfalls für erste/frühe Tests. Die Software wurde im bisherigen Stadium nur durch bestimmte Testarten (wie Alphatests) überprüft; zur Durchführung von Betatests. Die Software enthält noch Hilfsroutinen (z. B. Stubs oder Driver); zum Testen von Unterprogrammen. Die Anwendung wird zur Übernahme in eine spezielle System- oder Testumgebung bereitgestellt und ist ggf. zielsystemspezifisch adaptiert; zur Durchführung von Produktionstests oder Lasttests. In der Anwendung sind Hilfsroutinen enthalten, die das Testen und die Dokumentation von Fehlerfällen unterstützen; für öffentliche Tester. Stadiumbezogene Übergaben enthalten entweder die ganze Anwendung oder nur einzelne Komponenten zur (nachträglichen) Installation. Die Anwendung ist vollständig einsatzbereit (letztes Stadium); zur finalen Übergabe in die Produktionsumgebung.
Beispiele für Entwicklungsstadien Die Anzahl an Entwicklungsstadien mit ihren Soll-Reifegraden und auch ihre Bezeichnungen variieren erheblich. Insbesondere bei Standardsoftware (inkl. Systemsoftware) legen die Hersteller häufig fest, wie sie ihre Software stufenweise entwickeln, für wen und zu welchen Zwecken sie die jeweiligen Softwareversionen bereitstellen und wie sie diese Stufen benennen. Bei der Entwicklung von Individualsoftware werden Entwicklungsstadien/Softwarereleases meist unternehmensindividuell praktiziert, sie sind oft nicht allgemeingültig festgelegt, sondern folgen projektspezifischen Gegebenheiten.
Entwicklungsstadien und Bezeichnungen für Softwarereleases können zum Beispiel sein: pre-Alpha → Alpha → Beta → Release Candidate → Release. In anderen Fällen praktiziert ein Hersteller Releasebezeichnungen wie die folgenden: CLOSED → FINAL STABLE → FINAL → CURRENT BUILD → SCHEDULED.es2000 Software für Sie gemacht Support Lifecycle
Dabei ergeben sich zwischen solchen Haupt-Stadien in der Softwareentwicklung intern beliebig viele Software-Zwischenversionen, zum Beispiel aus mehreren Behebungsversuchen (und Teststufen) bei gemeldeten Programmfehlern.
Für die Softwareentwicklung allgemein, d. h. nicht nur für ausführbare Programme geltend, sind beispielsweise folgende Stadien i. S. von Meilensteinen bekannt: Projektdefinition, Anforderungsanalyse, Lastenheft, Pflichtenheft, Codeanalyse, Modultest, Systemtest, Projektabnahme
Softwarestadien für ausführbare Software mini|Software-Entwicklungsstadien Pre-Alpha-Version Allgemein kann jeder beliebige Entwicklungszustand vor der ersten Alpha-Version als eine pre-Alpha-Version (von ‚vorzeitig‘ und vom ersten Buchstaben des griechischen Alphabets Alpha, auch als Schriftzeichen für 1) bezeichnet werden. Oft wird eine solche Version verwendet, wenn ein halbwegs fertiges Modul der Software vorgestellt werden soll. Eine weitere Bezeichnung ist die Entwicklervorschau (von , abgekürzt auch oft DP).
Alpha-Version Die erste zum Test durch Fremde (also nicht die eigentlichen Entwickler) bestimmte Version eines Computerprogramms wird oft Alpha-Version genannt. Obwohl der Begriff nicht exakt definiert ist, enthält in der Regel eine Alpha-Version bereits die grundlegenden Bestandteile des Softwareprodukts – es ist aber fast unerlässlich, dass in späteren Versionen der Funktionsumfang noch erweitert wird.
Insbesondere enthalten Alpha-Versionen zumeist Programmfehler in Ausmaß oder Menge, die sie für den produktiven Einsatz ungeeignet machen.
Auch Alpha-Versionen können als Entwicklervorschauen, oder , verfügbar gemacht werden. Dies geschieht meist in einem exklusiven Kreis für Entwickler von Drittanbietern.
Beta-Version Eine Beta-Version ist die erste Version eines Computerprogramms, die vom Hersteller zu Testzwecken veröffentlicht wird. Der Begriff ist nicht exakt definiert, als Faustregel zur Abgrenzung einer Beta-Version von anderen Versionen gilt in der Regel, dass in ihr zwar alle wesentlichen Funktionen des Programms implementiert, aber noch nicht vollständig getestet sind. Das Programm kann oder wird daher unter Umständen noch viele, evtl. auch schwerwiegende Fehler enthalten, die einen produktiven Einsatz nicht empfehlenswert machen.
Der Nutzen eines Betatests besteht insbesondere darin, dass Fehler, die typischerweise erst in der Praxis auftreten (wie zum Beispiel Konflikte mit anderen Programmen, Probleme mit bestimmten Hardwarekomponenten, missverständlich umgesetzte Anforderungen oder Unklarheiten in der Benutzeroberfläche), schon vor der finalen Veröffentlichung () des Programms erkannt und behoben oder zumindest dokumentiert werden können. Als Betatester bezeichnet man im Allgemeinen den oder die ersten unabhängigen beziehungsweise anonymen Fremdtester und Anwender. Bei Betatestungen wird zwischen Open Beta (offene Beta) und Closed Beta (geschlossene Beta) unterschieden. Geschlossene Betaversionen werden einem begrenzten Personenkreis auf Einladung zum Benutzertest zur Verfügung gestellt, während bei einer Open Beta die zu testende Software für einen begrenzten Zeitraum einer breitere Masse an Internetnutzern zugänglich ist. Offene Betatestungen dienen mehreren Zwecken; einem Produkt oder einem Produktsystem einem umfangreicheren Stresstest bzw. Lasttest, als dies bei einer Closed Beta möglich ist, zu unterziehen und damit einhergehend mögliche Kompatibilitätsprobleme zu identifizieren sowie das Produkt den potenziellen Kunden zu demonstrieren (Marketing).
Beta-Versionen von Programmen sind in der Regel an der 0 als Hauptversionsnummer – diese Variante gilt natürlich nur für die Beta-Versionen vor der ersten fertigen Version (1.0) – oder dem Namenszusatz Beta zu erkennen.
Beta-Versionen werden normalerweise nicht auf dem gleichen Weg wie oder fertige Versionen vertrieben. Folgende Möglichkeiten finden Verwendung: In (un)regelmäßigen Abständen werden definierte (aktuelle Entwicklungszustände) aus dem Quellcodeverwaltungssystem generiert und en bloc entweder im Quellcode oder als vorkompiliertes Paket angeboten. Dies kann täglich (), wöchentlich oder zu beliebigen anderen Terminen, die die Entwickler für angemessen halten (z. B. nach Fertigstellung eines Subsystems), erfolgen. Eine solche Version kann auch ein automatisches -Modul enthalten (siehe z. B. Amarok), um den Betatestern die Fehlerberichte an die Entwickler zu erleichtern. Dies ist bei großen Projekten mit definierten Entwicklungszielen und einem festen Veröffentlichungszeitplan üblicherweise der Normalfall (z. B. bei GNOME). Die Betaversion wird im Quellcodeverwaltungssystem zu einer definierten Revision mit einem (einer Markierung) versehen, aber sonst nicht gesondert behandelt. Unabhängige Anbieter können dann diesen Entwicklungsstand als Basis für ihre vorkompilierten Pakete verwenden. Dies kommt bei sich sehr schnell ändernden Projekten, die unter Umständen ganz ohne oder nur mit seltenen festen arbeiten, bei denen aber trotzdem allgemeines Interesse an aktuellen Versionen besteht, zum Einsatz (z. B. Dirac, Xine). Es gibt keine feste Beta-Version, Beta ist das aktuelle HEAD, also der sich ständig ändernde, tatsächliche Entwicklungsstand. Betatester müssen den derzeitigen Stand selbst aus dem Quellcodeverwaltungssystem herunterladen, konfigurieren und kompilieren, diese Tätigkeit wird normalerweise durch vom Projekt bereitgestellte Skripte automatisiert erledigt. Dies ist der häufigste Fall, kann aber auch mit einer der beiden vorherigen Methoden kombiniert werden (das ist die Regel).
Perpetual Beta Ein Begriff, der beschreibt, dass sich in Bezug auf die ständige Entwicklung des Internets auch Websites und Software kontinuierlich weiterentwickeln und somit nie wirklich fertig sind. Somit ist ein immerwährender Entwicklungszustand eingetreten, die „Perpetual Beta“. Entstanden als Schlagwort innerhalb des Web-2.0-Konzeptes, das dem -Konzept der „“ Rechnung trägt.
Technical Preview Wenn ein Produkt oder eine Komponente qualitätsgesichert freigegeben wird, die aber noch unvollständig ist, spricht man von einem Technical Preview. Kunden können die Software testen, auch wenn sie noch dokumentierte Einschränkungen hat, z. B. noch nicht in allen finalen Sprachen lokalisiert ist.
Release Candidate/Prerelease mini|hochkant|Microsoft Windows 2000 Server RC 2 Installations-CD mini|rechts|Ein Screenshot eines Vorab-Releases mit Warnhinweisen zur Verwendung Ein (kurz RC, aus dem Englischen für Freigabekandidat), gelegentlich auch als (aus dem Englischen etwa für „Vorabveröffentlichung“ oder „Vorabversion“) bezeichnet, ist eine abschließende Testversion einer Software. Darin sind alle Funktionen, die die endgültige Version der Software enthalten soll, schon verfügbar (sogenannter ,) alle bis dahin bekannten Fehler sind behoben. Aus dem wird vor der Veröffentlichung die endgültige Version erstellt, um einen abschließenden Produkttest oder Systemtest durchzuführen. Dabei wird die Qualität der Software überprüft und nach verbliebenen Programmfehlern gesucht.
Wird auch nur eine Kleinigkeit geändert, muss ein weiterer erstellt werden, und die Tests werden wiederholt. Die werden daher auch oft nummeriert (RC1, RC2 usw.). Erfolgen keine weiteren Änderungen und hält ein schließlich die geforderten Qualitätsstandards ein, so wird das Suffix RCx entfernt und damit die Version als (auch , finale Veröffentlichung oder , finale Version) erklärt und veröffentlicht.
Versionen, die deutlich stabiler sind als Beta-Versionen, aber noch nicht den Teststand eines besitzen, werden in manchen Entwicklungsprojekten als Gamma-Version bezeichnet.