Entwicklungsstadium (Software)
aus Wikipedia, der freien Enzyklopädie
Im Prozess der Softwareentwicklung durchläuft die zu erstellende Software verschiedene Entwicklungsstadien, die auch als Meilensteine betrachtet werden.
Die Stadien der Entwicklung sind: pre-Alpha → Alpha → Beta → Release Candidate → Release
Nach dem Erreichen des Endzustands wird der Zyklus, durch Wiederaufnahme der Arbeit an einer neuen Version der Software, wieder von vorne begonnen. Je nach Größe des Softwareprojektes und des Vorgehensmodells fallen einige Stadien weg oder werden zusammengelegt.
Inhaltsverzeichnis |
[Bearbeiten] Alpha-Version
Die erste zum Test bestimmte Version eines Computerprogrammes wird oft Alpha-Version genannt. Obwohl der Begriff nicht exakt definiert ist, enthält in der Regel eine Alpha-Version bereits die wichtigsten Bestandteile des Softwareprodukts – es ist aber fast unerlässlich, dass in späteren Versionen der Funktionsumfang noch erweitert wird.
Insbesondere enthalten Alpha-Versionen oftmals viele Programmfehler und sind daher in der Regel nicht für den Endkonsumenten oder für den produktiven Einsatz geeignet.
[Bearbeiten] Beta-Version
Eine Beta-Version ist eine unfertige Version eines Computerprogramms.
Häufig sind Beta-Versionen die ersten Versionen eines Programms, die vom Hersteller zu Testzwecken veröffentlicht werden.
Der Begriff ist nicht exakt definiert, als Faustregel zur Abgrenzung einer Beta-Version von anderen Versionen gilt in der Regel, dass zwar alle wesentlichen Funktionen des Programms implementiert, aber noch nicht vollständig getestet sind und das Programm daher vermutlich noch Fehler enthält.
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 (bzw. β) zu erkennen, z. B. v0.12 β.
[Bearbeiten] Betatester
Betatester sind Personen, die eine Software, welche sich im Beta-Stadium befindet, durch Benutzung derselben auf Programmfehler überprüfen. Sie stehen dabei im Kontakt mit den Entwicklern, so dass die gefundenen Fehler vor dem Release beseitigt werden können.
Der Nutzen eines Betatests besteht darin, dass Fehler, die typischerweise erst in der Praxis auftreten, wie zum Beispiel Konflikte mit anderen Programmen oder Probleme mit bestimmten Hardwarekomponenten, schon vor dem Release des Programms erkannt und behoben oder zumindest dokumentiert werden können.
Beta-Versionen werden normalerweise nicht auf dem gleichen Weg wie Release Candidates oder fertige Versionen vertrieben. Folgende Möglichkeiten finden Verwendung:
- In (un)regelmäßigen Abständen werden definierte Snapshots (aktuelle Entwicklungszustände) aus dem Quellcodeverwaltungssystem generiert und en bloc entweder im Quellcode oder als vorkompiliertes Paket angeboten. Dies kann täglich (Nightly Build), 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 Bugtracking-Modul enthalten (siehe Amarok), um den Betatestern die Fehlerberichte an die Entwickler zu erleichtern. Dies ist bei großen Projekten mit definierten Entwicklungszielen und einem festen Release-Zeitplan üblicherweise der Normalfall (GNOME).
- Die Betaversion wird im Quellcodeverwaltungssystem zu einer definierten Revision mit einem Tag (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 Releases arbeiten, bei denen aber trotzdem allgemeines Interesse an aktuellen Versionen besteht, zum Einsatz (Dirac, Xine).
- Es gibt keine feste Betaversion, 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 compilieren, 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). (KDE4)
Unter Umständen (insbesondere bei proprietären Produkten) wird diese noch unvollständige Software aber nur einem ausgewählten Personenkreis zur Verfügung gestellt. Für diese Auswahl gibt es verschiedene Möglichkeiten:
- Interessierte Anwender können sich in öffentlicher Ausschreibung (z.B. per Internet) für den Beta-Test anmelden, wobei aber nur eine bestimmte Zahl von Betatestern per Los bestimmt wird.
- Der Softwarehersteller stellt die Betaversion einem kleinen Kreis vorausgewählter Anwender, beispielsweise einzelnen Angestellten wichtiger Kunden oder gesetzlich vorgeschriebener Prüfinstitute, zur Verfügung.
- Die Betatester sind ausschließlich Mitarbeiter des Herstellers oder eines extra dafür beauftragten Dienstleisters.
In den letztgenannten beiden Varianten kann nicht mehr von einem öffentlichen Betatest gesprochen werden. Beta-Tests können für Softwarehersteller auch problematisch sein, da die Kontrolle über die meist unerwünschte Weitergabe von Betaversionen an weitere Personen (Leak) nur schwer möglich ist und so bei einem größeren Kreis potentieller Kunden ein falscher Eindruck von der Software entstehen kann. Proprietäre Produkte werden daher in der Regel keinem öffentlichen Betatest unterworfen.
[Bearbeiten] Community Technology Preview
Auf der Professional Developers Conference 2005, einem Treffen von Microsoft-Entwicklern, kündigte Bill Gates im Rahmen eines sogenannten Community Technology Preview (CTP) speziell für das damals in Entwicklung befindliche Windows Vista eine zusätzliche neue Art von Testversionen an. Dabei handelte es sich um eine in monatlichen Abständen veröffentlichte Programmversion, welche weniger als Testversion im engeren Sinne gedacht war, sondern vielmehr Softwareentwicklern den Zugang zur jeweils aktuellen Version von Windows Vista ermöglichen sollte, u.a. damit diese ihre Software bereits vor dem Release auf den neuesten Stand bringen konnten. Das erste Produkt, von dem Microsoft CTP-Versionen erzeugte, war Visual Studio 2005. Seitens Microsoft gibt es für CTP-Versionen keine Unterstützung.
[Bearbeiten] 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 Extreme-Programming-Konzept der "Continuous Integration" Rechnung trägt.
[Bearbeiten] Release Candidate
Ein Release Candidate (RC) (zu deutsch Freigabekandidat) ist eine abschließende Testversion einer Software. Darin sind alle Funktionen, die die endgültige Version der Software enthalten soll, schon verfügbar (sogenannter feature complete). Der Release Candidate wird vor der Veröffentlichung der endgültigen Version erstellt, um einen abschließenden Produkttest oder Systemtest durchzuführen. Dabei wird die Qualität der Software überprüft und nach verbleibenden Programmfehlern gesucht.
Wird auch nur eine Kleinigkeit geändert, muss ein weiterer Release Candidate erstellt werden und die Tests werden wiederholt. Die Release Candidates werden daher auch oft nummeriert (RC1, RC2, usw.). Erfolgen keine weiteren Änderungen und hält ein Release Candidate schließlich die geforderten Qualitätsstandards ein, so wird das Präfix RCx entfernt und damit die Version als Release erklärt und veröffentlicht.
Versionen, die deutlich stabiler sind als Beta-Versionen, aber noch nicht den Teststand eines Release Candidate besitzen, werden in manchen Entwicklungsprojekten als Gamma-Version bezeichnet.
[Bearbeiten] Release/Stable
Die fertige und veröffentlichte Version einer Software wird als Release oder Stable bezeichnet. Damit geht ein Hochzählen der Versionsnummer einher. Bei einer mediengebundenen Verteilung wird diese Version zur Produktion an die Presswerke ausgeliefert wo sie auf Datenträger wie CD-ROMs oder DVDs kopiert, also als tatsächlich greifbares Produkt hergestellt wird.
Für diesen Status haben sich verschiedene Bezeichnungen etabliert:
- Release oder Ready to Manufacturing/Web (RTM/RTW)
- Bereit für die Veröffentlichung
- Final
- für die endgültige Version
- Gold
- Die Herkunft der Bezeichnung ist umstritten. Sie geht auf die Zeit vor den CDs zurück, hat also nichts mit der Farbe der CDs oder des Trägermaterials zu tun. Die wahrscheinlichste Erklärung ist die Aufnahmetechnik für Schallplatten, bei der manche Master-Formen goldbeschichtet waren. Die Vergoldung geschah wegen besserer Beständigkeit des Materials gegen Korrosion. Besonders im Bereich der Computerspiel-Software wird dieser Begriff verwendet; wohl wegen der plakativen Wirkung des Edelmetalls.
[Bearbeiten] Fehlerbehebung nach Veröffentlichung
Um Fehler in bereits veröffentlichter Software zu beheben, geben Softwarehersteller sogenannte Hotfixes, Patches und Service Packs heraus. Bei vielen modernen Anwendungen und Betriebssystemen können diese dann direkt als Software über das Internet bezogen werden.
