Entwicklungsstadium (Software)

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Release Candidate)
Wechseln zu: Navigation, Suche
Software-Entwicklungsstadien

Im Prozess der Softwareentwicklung durchläuft die zu erstellende Software verschiedene Entwicklungsstadien, die auch als Meilensteine betrachtet werden.

Die Stadien der Entwicklung sind: pre-AlphaAlphaBetaRelease CandidateRelease

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.

Benennungen[Bearbeiten | Quelltext bearbeiten]

Die Benennung einer Veröffentlichung ist grundsätzlich nicht genormt und lautet meist von Projekt zu Projekt unterschiedlich. Manche Hersteller legen in einer Art Roadmap auch die beabsichtigten Bezeichnungen für (geplante) veröffentlichte Entwicklungsstände fest.

Problematisch ist auch der Begriff Beta-Version, da er nicht eindeutig definiert ist und damit grundsätzlich für jeden unfertigen Entwicklungsstand stehen kann. So gibt es dieselben Benennung nach den Stadien der Entwicklung oft einerseits bezogen auf das gesamte Projekt, andererseits kann die Benennung auch lediglich auf erst kürzlich hinzugefügte Teilkomponenten bezogen sein (und der Rest der Projektes ist eigentlich stabil und daher keine Beta-Version).

Auch die Veröffentlichung selbst hat meist unterschiedliche Namen. Neben der sogenannten “Release” (englisch für „Veröffentlichung“) gibt es auch die “Final” oder final version (zu Deutsch: fertige Version oder auch finale Version). Es gibt jedoch auch den Begriff “Stable”, also stabil, oft als stable version, stabile Version. Auch hier zeigt sich deutlich, dass verschiedene Benennungen durchaus üblich sind: statt einer Version kann auch eine Veröffentlichung namensgebend sein: eine final release eines Entwicklungsprojektes ist lediglich die veröffentlichte final version.

Bei unfertigen Versionen verhält es sich nicht anders. Ob nun Pre-Alpha-, Alpha- oder Beta-Version: gebräuchlicht ist “experimental” (experimentell), “unstable” (instabil), “testing” genauso wie “Preview”, jeweils optional wieder als “version” oder als “release”, aber auch als “build”. Ein Build ist dabei am unspezifischsten, wird aber auch oft bei Veröffentlichungen verwendet, um den Status einer unfertigen Software zu verdeutlichen. Dennoch haben auch stabile und fertige Versionen oft eine Build-Nummer.

Eine Besonderheit ist die Benennung als Nightly Build, übersetzt: nächtlicher Build. Ein Programm mit dieser Benennung kann zwischen vollkommen stabil bis gänzlich laufunfähig alles sein, weil der Prozess fast immer automatisiert in der Nacht abläuft (daher auch der Name) und dabei auf dem jeweiligen Stand des Quelltextes basiert, an dem die Entwickler tagsüber ihre Änderungen vornehmen. Der Quelltext könnte durch die letzten Änderungen defekt geworden sein (englisch broken), jedoch dennoch übersetzbar für den Compiler bleiben, sodass zwar der Build-Prozess erfolgreich verläuft, das Programm jedoch dennoch nicht lauffähig ist. Daher sagt die Benennung als Nightly Build nichts über das Entwicklungsstadium des Softwareprojektes aus.

Üblich sind aber auch Benennungen, die unabhängig vom Entwicklungsstand eines Softwareprojekts an ein bestimmtes Publikum gerichtet sind. Diese verfolgen meist das für den Entwickler vorteilhafte Ziel, einen externen „Beta-Test“ unter bestimmten Bedingungen durchzuführen. Auch die Benennungen für weiterreichende „Beta-Programme“ sind nicht genormt und lauten von Projekt zu Projekt unterschiedlich, es gibt jedoch gemeinsame Schlagwörter:

Internal Build oder Private Build
bezeichnet eine lauffähige Version eines Projekts, das nur intern getestet wird.
Developer Build
ist eine Testversion, die speziell für externe Entwickler (englisch developer) gedacht ist. Das kommt meist dann zur Anwendung, wenn viele Drittanbieter für die Funktion des Projektes unerlässlich sind, z. B. bei einem Betriebssystem, auf dem viele Programme von anderen Herstellern laufen können (bzw. kompatibel bleiben oder werden) sollen.
Beispiel: Rhapsody Developer Release oder Mac OS X Developer Preview
Closed Beta
bezeichnet eine Beta-Version, die einem exklusiven Kreis verfügbar gemacht wird.
Beispiel: Windows 10 als Insider Build oder Insider Preview, das für Teilnehmer eines offenen (da nur anmeldepflichtigen) Programms von Microsoft, das den Namen Insider Program trug, veröffentlicht wurde. Dabei war die Aufnahme von Testern zeitlich begrenzt.
Public Beta
bezeichnet, wie der Name schon sagt, eine Beta-Version, die offen und uneingeschränkt für Early-Adopter gedacht ist.
Beispiel: Mac OS X Public Beta, eine Beta-Version von Mac OS X 10.0.
Early Access
bezeichnet ein Kundenprogramm, das einen meist kostenpflichtigen Zugang (englisch access) zu frühen Test- und/oder Entwicklerversionen bietet. Dies ist vor allem bei Computerspielen sehr beliebt, da es einerseits den Spielern bereits lange vor der Veröffentlichung eines Titels erlaubt, bestimmte Elemente der Spielewelt zu erforschen und bei Stabilitätstests auf verschiedener Hardware zu helfen, andererseits den Entwicklern ermöglicht, frühzeitig Änderungen vorzunehmen, die auf Feedback der Spieler basieren. Early-Access-Programme sind zudem meist eine gute Finanzierungsquelle, da das Entwicklungsstudio bereits über Early-Access-Verkäufe Geld für die Entwicklung des Spiels vorab einnimmt.

Eine weitere Art der Benennung stellt die Bezeichnung des Zwecks oder Grundes dar, für den eine bestimmte Version oder Veröffentlichung herausgegeben wird. Gebräuchlich sind hier vor allem die “Maintenance Release” und “Service Release”, also eine Veröffentlichung zum Zweck der Wartung. Übersetzt wird dies oft auch als Wartungsversion.

Pre-Alpha-Version[Bearbeiten | Quelltext bearbeiten]

Allgemein kann jeder beliebige Entwicklungszustand vor der ersten Alpha-Version als eine pre-Alpha-Version (von lateinisch prae- ‚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 englisch developer preview, abgekürzt auch oft DP).

Alpha-Version[Bearbeiten | Quelltext bearbeiten]

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, englisch Developer Previews oder Developer Releases, verfügbar gemacht werden. Dies geschieht meist in einem exklusiven Kreis für Entwickler von Drittanbietern.

Beta-Version[Bearbeiten | Quelltext bearbeiten]

Beta-Versionen sind vor allem bei Web-2.0-Diensten oft durch einfache Logos gekennzeichnet.

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. Als Betatester bezeichnet man im Allgemeinen den oder die ersten unabhängigen beziehungsweise anonymen Fremdtester und Anwender.

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 viele, auch schwerwiegende Fehler enthält, die einen produktiven Einsatz nicht empfehlenswert machen.

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.

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 der finalen Veröffentlichung (englisch 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 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 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 (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[Bearbeiten | Quelltext bearbeiten]

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.

Siehe auch: Bananenprinzip

Release Candidate/Prerelease[Bearbeiten | Quelltext bearbeiten]

Ein Release Candidate (kurz RC, aus dem Englischen für Freigabekandidat), gelegentlich auch als Prerelease (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 feature complete), alle bis dahin bekannten Fehler sind behoben. Aus dem Release Candidate 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 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 Suffix RCx entfernt und damit die Version als Release (auch englisch final release, finale Veröffentlichung oder final version, finale Version) 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.

Bei Gerätetreibern für Windows gibt es manchmal den Status WHQL Candidate (übersetzt WHQL-Kandidat). Hierbei handelt es sich um eine dem RC entsprechende Treiberversion, die der Hersteller zur WHQL-Prüfung eingereicht hat, die entsprechende Zertifizierung ist allerdings noch nicht erfolgt.

Release[Bearbeiten | Quelltext bearbeiten]

Die fertige und veröffentlichte Version einer Software wird als Release bezeichnet. Damit geht eine Veränderung der Versionsbezeichnung, meist 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 außerdem verschiedene Bezeichnungen etabliert:

Release to Manufacturing/Web (RTM/RTW), auch First Customer Shipment (FCS)
Bereit für die Vervielfältigung und Veröffentlichung im Netz (Web)
Stable
für eine stabile Version, die nicht mehr verändert wird
Final
für die endgültige (finale) Version
General Availability (GA)
steht für eine allgemeine Verfügbarkeit. Der Begriff verdeutlicht, dass die Version für den Praxiseinsatz freigegeben ist und über verschiedene Medien verteilt wurde bzw. erhältlich ist.[1][2][3]
Gold, auch Golden Master (GM)
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 mit Gold beschichtet wurden. Besonders im Bereich der Computerspiele wird dieser Begriff verwendet, wohl wegen der plakativen Wirkung des Edelmetalls, außerdem bedeutet er meist, dass alle oder zumindest populäre Erweiterungen des Spieles enthalten sind. Der Begriff soll – ähnlich wie die Final und General Availability – symbolisieren, dass das Produkt ausgereift und (möglichst) frei von Fehlern ist.

Fehlerbehebung nach Veröffentlichung[Bearbeiten | Quelltext bearbeiten]

Um Fehler in bereits veröffentlichter Software zu beheben, geben Softwarehersteller sogenannte Aktualisierungen, Hotfixes, Patches und Service Packs heraus. Bei vielen modernen Anwendungen und Betriebssystemen können diese dann manuell oder automatisch über das Internet bezogen werden.

Firefox als Beispiel[Bearbeiten | Quelltext bearbeiten]

Der Webbrowser Mozilla Firefox erscheint in sechswöchigen Abständen in drei verschiedenen Versionen: der experimentellen Version Firefox Aurora, der größtenteils stabilen Version Firefox Beta und der stabilen Version Firefox[4][5], die sich jeweils in ihrer Versionsnummer unterscheiden, z. B. Firefox Aurora 11, Firefox Beta 10, Firefox 9. Außerdem kann man das „nächtliche“ Nightly Build (aktueller Entwicklungsstand, nur zum Testen geeignet) herunterladen. Auf diese Weise kann einerseits der Entwicklungsprozess beschleunigt werden, andererseits können Benutzer durch die Verwendung der Versionen Beta oder Aurora dazu beitragen, künftige Funktionen der stabilen Version zu testen, zu beurteilen und Programmfehler sowie Sicherheitslücken frühzeitig zu erkennen, da die Aurora-Version zwölf und die Beta-Version sechs Wochen vor dem endgültigen Erscheinen der stabilen Version der Öffentlichkeit zur Verfügung gestellt wird.

Siehe auch[Bearbeiten | Quelltext bearbeiten]

Literatur[Bearbeiten | Quelltext bearbeiten]

  • Manfred Precht, Nikolaus Meier, Dieter Tremel: EDV-Grundwissen. Pearson Education, München 2004, ISBN 3-8273-2129-8.
  • Mike Gunderloy: Coder to Developer. Wiley_Default, 2004, ISBN 0-7821-4327-X.

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. Microsoft Announces General Availability of Windows Small Business Server 2008 and Windows Essential Business Server 2008 (Memento vom 25. Dezember 2008 im Internet Archive)
  2. VMware Announces General Availability of VMware View 3, with Ground-Breaking Advances in Managing, Scaling and Personalizing Virtual Desktop Environments (Memento vom 5. Dezember 2008 im Internet Archive)
  3. Release Phases & Criteria. In: cs.pomona.edu. Abgerufen am 24. Juli 2016 (englisch).
  4. Johnathan Nightingale: Every Six Weeks. In: blog.mozilla.org. 18. Juli 2011, abgerufen am 24. Juli 2016 (englisch).
  5. Jens Ihlenfeld: Firefox weiter alle 6 Wochen, aber mit Versionsnummer. golem.de, 26. August 2011, abgerufen am 24. Juli 2016.