Software Release Lifecycle (SRLC): Die 6 Phasen erklärt
Genauso wie Menschen verschiedene Lebensabschnitte durchlaufen, tun dies auch Softwareprodukte. Dies wird oft als Software-Release-Lebenszyklus bezeichnet.
Es gibt bestimmte Zeiträume, die mit den verschiedenen Phasen des Lebenszyklus oder „Entwicklungsstufen“ innerhalb von Apps verbunden sind, aber es ist oft schwierig vorherzusagen, wann eine Phase endet und eine andere beginnt. Jede Phase hat ihre eigenen, klar unterscheidbaren Aufgaben und bereichsübergreifenden Anforderungen, weshalb es für Produktmanager wichtig ist, jede Phase zu verstehen, um das Unternehmen erfolgreich durch den Software-Release-Lebenszyklus zu navigieren.
Während wir tiefer in diesen Artikel eintauchen, werde ich Kommentare zu meinen Erfahrungen beim Verkauf und der Integration von BankerBox, einem FinTech SaaS-Unternehmen für Investmentbanker, gemeinsam mit meinem Mitgründer bei SS&C Intralinks, in die verschiedenen Phasen des SRLC einfließen lassen.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Was ist ein Software-Release-Lebenszyklus (SRLC)?
Der Software-Release-Lebenszyklus (SRLC) ist eine Reihe von Meilensteinen, die die verschiedenen Etappen im Lebenszyklus einer Software oder deren aufeinanderfolgende Veröffentlichungsschritte beschreiben – vom ersten Konzept bis zur endgültigen, vollständig ausgereiften Veröffentlichung. Die Dauer dieses Lebenszyklus variiert je nach einer Vielzahl von Faktoren, wie dem Produkttyp, dem vorgesehenen Nutzen sowie branchenüblichen Sicherheits-, Compliance- und allgemeinen Standards.
Softwareanwendungen haben beispielsweise in der Regel einen kürzeren Lebenszyklus als die meisten anderen Produkte, weil neue Funktionen und Verbesserungen häufig agil eingeführt werden, um sich verändernden Marktanforderungen und neuen technologischen Trends gerecht zu werden.
Der SRLC ist dem Softwareentwicklungslebenszyklus (SDLC) ähnlich, bei dem es sich um eine Struktur für die Entwicklung von Softwareprodukten handelt. Der Unterschied zwischen diesen beiden Lebenszyklen besteht darin, dass der SDLC ausschließlich den Entwicklungsprozess und das Softwaredesign beschreibt, während der Release-Lebenszyklus nicht nur die Entwicklung, sondern auch die Nutzbarkeit, das Testen und die Verteilung beschreibt.
Software-Releases müssen sorgfältig geplant und getestet werden (idealerweise von einem Testteam), um sicherzustellen, dass sie nicht mehr Probleme verursachen als sie lösen. Ein Software-Release-Lebenszyklus stellt einen klaren Plan für einen erfolgreichen Release-Prozess durch ordnungsgemäße Planung, Testen und Fehlerbehebung auf.
Unternehmen sollten den Software-Release-Lebenszyklus nutzen, um vorauszuplanen, wann und wie sie ihre Webanwendungen oder Apps im Laufe der Zeit aktualisieren. Die Umsetzung von besten Praktiken im Release-Management ermöglicht es ihnen, ein stabiles Produkt zu erhalten, das kontinuierlich sowohl die Bedürfnisse ihrer Nutzer, die Kernfunktionalität als auch die Standards der Branche erfüllt (hier kann auch KI im Release-Management unterstützen). Dies ermöglicht es, ein robustes Produkt aufrechtzuerhalten, das kontinuierlich sowohl den Anforderungen der Nutzer, dem Kern der Funktionalität als auch dem Branchenstandard entspricht.
Die 6 Phasen des Software-Release-Lebenszyklus
Je nach Entwicklungsteam und System können unterschiedliche Phasen des Software-Release-Lebenszyklus genutzt werden, um den jeweiligen Anforderungen gerecht zu werden.
Die „Stufen“ markieren Meilensteine in der Produktentwicklung und ermöglichen es Entwicklungs- und Projektteams, Fortschritte nachzuverfolgen. Sie ermöglichen zudem das Erkennen von Trends in Apps und Webanwendungen und stellen sicher, dass durch die Iterationen Verbesserungen vorgenommen werden. Typischerweise besteht der Prozess aus folgenden sechs Phasen:
1. Pre-Alpha-Version
Die erste Stufe im Software-Release-Lebenszyklus ist die Pre-Alpha-Phase. In diesem Stadium konzentriert sich der gesamte Prozess auf die Entwicklung eines Produkts und nicht auf dessen Vermarktung oder öffentliche Veröffentlichung. Hier werden alle Maßnahmen beschrieben, die während der anfänglichen Entwicklung vor dem Testen ausgeführt werden. Zu den gängigsten Schritten der Pre-Alpha gehören Analyse, Design, Entwicklung und Komponententests (Unit-Tests).
Ein wesentlicher Teil der Pre-Alpha-Version besteht darin, zu definieren, wie sich die Softwareanwendung weiterentwickeln muss, um auf breitere Releases wie die Alpha- oder Beta-Version vorbereitet zu sein. Das Entwicklungsteam muss starke Test-, Usability- und Automatisierungsprozesse einführen, um stabile Übergänge zwischen den verschiedenen Phasen des Software-Release-Lebenszyklus sicherzustellen.
Bei der SaaS-Lösung, die mein Mitbegründer und ich bei SS&C Intralinks integriert haben, hatten wir die Pre-Alpha-Phase bereits intensiv geprüft und abgeschlossen. Wir hatten eine funktionierende Anwendung, die konzipiert, gestaltet und gebaut war. Es ist allerdings wichtig zu erwähnen, dass die Definition der Schritte Analyse, Design, Entwicklung und Komponententests in einem kleinen Softwareunternehmen deutlich von der Sichtweise und Strenge eines Großunternehmens abweichen kann.
4 Phasen für den Start der Pre-Alpha-Version
Analyse: Dies ist die Anfangsphase im Software-Release-Lebenszyklus oder SRLC, in der das Problem und die Systemanforderungen im Detail untersucht werden. Dazu gehören die Analyse der Benutzeranforderungen, kritischer Funktionen, die Identifikation des Problemfelds, die Erstellung von Machbarkeitsstudien und das Erstellen des SRS (Software Requirement Specification).
Design: In dieser Phase entwickeln die Entwicklungsteams eine Lösung für das im Analyseprozess identifizierte Problem. Hierbei wird ein High-Level-Design-Dokument sowie Mock-ups erstellt, welche erklären, wie das Softwareprodukt implementiert werden soll. Das Design-Dokument hebt grundlegende Schritte hervor, die beim Aufbau der Webanwendung zu befolgen sind.
Wenn Sie an Layouts oder an UI-Abläufen arbeiten, können diese Responsive-Design-Prototyping-Tools Ihnen helfen, Ideen schnell zu testen, bevor Sie in die Entwicklung übergehen. Das Design-Dokument hebt die grundlegenden Schritte hervor, die befolgt werden müssen, um die Webanwendung zu entwickeln.
Entwicklung: Dies ist die eigentliche Programmierphase, in der ein Entwicklungsteam die Anforderungsspezifikationen in ein tatsächliches Softwareprodukt umsetzt. Nach Abschluss der Codierung führen die Entwickler Tests durch und beheben Fehler so früh wie möglich.
Unit-Testing: Dies wird von den Entwicklern durchgeführt, bevor ihr Modul an das QA- (Qualitätssicherung) Entwicklungsteam für den weiteren Testprozess übergeben wird. In dieser Phase prüfen die Entwickler jede einzelne Zeile des Quellcodes, um sicherzustellen, dass der Code korrekt funktioniert, bevor er in die gesamte Anwendung integriert wird.
2. Alpha-Version
Die Alpha-Phase repräsentiert den ersten Buchstaben des griechischen Alphabets und ist ebenfalls ein Codename für die Entwicklungsphase, die stattfindet, bevor ein Produkt veröffentlicht wird. Softwareentwickler verwenden den Begriff „Alpha“ oder „Alpha-Version“, um Software zu beschreiben, die sich in der ersten Phase des Softwaretests befindet.
Der Alphatest wird von internen Mitarbeitern oder Entwicklern innerhalb der Organisation durchgeführt. Diese Art von Test findet beim Entwickler, aber nicht beim Kunden statt. Alphatests werden nach Abschluss der Systemtests und vor Beginn der Betaphase durchgeführt. Ziel dieser Tests ist es, Fehler oder Mängel in Bezug auf Benutzerfreundlichkeit, Funktionalität und Konsistenz zu finden.
Bei dieser Art von Test führen eine Gruppe von Personen, sogenannte „Tester“, Operationen ähnlich denen der Endbenutzer durch und berichten dann über aufgetretene Probleme. Das Hauptziel des Alphas ist sicherzustellen, dass alle Module korrekt integriert und wie erwartet funktionsfähig sind.
Als wir die Alpha-Phase für BankerBox durchliefen, haben wir Kolleginnen und Kollegen aus Produkt, Software sowie in unserem speziellen Fall (bei der Entwicklung einer Lösung für Banken) auch mehrere Investmentbanker und Kontakte im Bereich High Finance eingebunden.
Alpha-Software ist funktionsfertig, weist aber wahrscheinlich Fehler auf. Der Fokus von Alphatests liegt darauf, ein Produkt durch die Erkennung von Problemen vor der Betaphase zu verbessern und letzte Anpassungen basierend auf dem Alpha-Feedback vorzunehmen.
3. Beta-Version
Die Betaphase, benannt nach dem zweiten Buchstaben des griechischen Alphabets, ist der Codename, der verwendet wird, um zu signalisieren, dass ein Softwareprodukt in die zweite Testphase gelangt ist und bereit für den externen Einsatz durch Kunden oder Klienten ist – oft als „Beta-Tester“ bezeichnet. Einige Unternehmen bezeichnen diese Phase auch als „Early Adopter“-Phase.
Sobald eine Betaversion veröffentlicht wird, erfolgt meist eine umfangreichere Testung als in der Alphaphase. Dies ermöglicht es Unternehmen, abzuschätzen, wie gut ihre Software unter realen Bedingungen funktioniert.
Nachdem SS&C Intralinks BankerBox übernommen hatte, haben wir zügig einige wichtige Integrationspunkte zwischen unserer Software und den Systemen des übergeordneten Unternehmens (Authentifizierung, Cloud-Server, usw.) geschaffen. Anschließend konnten wir in Zusammenarbeit mit mehreren Unternehmenskunden das System als Live-Beta-Testlösung für ein M&A-Projekt vorstellen.
Dies war eine hervorragende Möglichkeit, Feedback zu erhalten, Kundenbeziehungen aufzubauen und Bereiche zu entwickeln, in denen sich die Software weiterentwickeln muss, um die Anforderungen und den „Maßstab“ für eine Release Candidate (RC) oder General Availability (GA) zu erfüllen.
Bei diesem Test liefern die Kunden wertvolles Feedback darüber, ob das Produkt oder die App ihren Erwartungen hinsichtlich Funktionalität, Bedienbarkeit, Leistung, Zuverlässigkeit, Skalierbarkeit usw. entspricht. Das von den Endanwendern bereitgestellte Feedback trägt dazu bei, die Benutzererfahrung zu verbessern und operative Probleme zu beheben, bevor das Produkt in die Produktionsumgebung übergeht. Es gibt zwei Arten der Betaphase:
- Offene Beta: Während dieser Phase kann jeder teilnehmen, der Interesse am Betatest hat. Dies hilft Entwicklern, Fehler schneller und einfacher zu beheben, da das Feedback vieler Anwender verschiedene Probleme aufdecken kann.
- Geschlossene Beta: In dieser Phase gibt es eine exakt definierte Zielgruppe, die die Tests durchführt. Die Zielgruppe hilft dabei, die Softwaretests auf spezielle Problembereiche zu fokussieren und sicherzustellen, dass alles für die Bedürfnisse der Zielkunden funktioniert.
4. Release Candidate
Ein Release Candidate (RC) ist eine Vorabversion der Software, die für die finale Freigabe (in der RC-Phase) an die Öffentlichkeit vorbereitet wird. Diese Phase wird manchmal auch als „Controlled Availability“ bezeichnet. Auch wenn bereits alle vorgesehenen Funktionen und Eigenschaften vorhanden sind und wie erwartet funktionieren, kann es dennoch aufgrund von erhaltenem Feedback zu Änderungen, mitunter sogar umfangreichen, kommen.
Entwickler veröffentlichen möglicherweise mehrere Release Candidates, bevor das endgültige Produkt herausgegeben wird, um sicherzustellen, dass das Programm unter hoher Belastung nicht abstürzt, keinen erheblichen Speicherverlust aufweist usw.
5. Allgemeine Verfügbarkeit
Allgemeine Verfügbarkeit (GA) bedeutet, dass ein Produkt oder eine Dienstleistung für die meisten Kunden (in der Regel weltweit) über kommerzielle Kanäle käuflich erhältlich ist. In der Softwareentwicklung bezieht sich dieser Begriff typischerweise auf eine Webanwendung oder App, die allen vorgesehenen Nutzern zur Verfügung steht. In dieser Phase zielen Updates oder weitere Entwicklungsarbeiten darauf ab, Funktionen und Leistung des Produkts zu verbessern, um es für Kunden attraktiver zu machen.
Einst BankerBox, nun „Deal Marketing“ unter dem neuen Markennamen, erreichte die allgemeine Verfügbarkeit. Wir konnten es auf Kunden in ganz Nordamerika skalieren und wertvolles Feedback, Nutzungszahlen, Skalierbarkeit usw. gewinnen, um die Passgenauigkeit des Produkts für den Markt zu validieren, bevor wir zur letzten Phase des Software-Release-Lebenszyklus, dem Produktions-Release, übergehen konnten.
6. Produktions-Release
Eine stabile Version ist eine Softwareausgabe, die getestet und verifiziert wurde. Sie stellt die neueste (und manchmal finale) Version eines Programms dar, die für die öffentliche Nutzung als sicher gilt. Diese Art von Veröffentlichung wird auch als „Stabile“ Version bezeichnet.
Wenn eine Software oder Webanwendung in diese Phase eintritt, signalisiert dies der gesamten Organisation und dem Markt den Grad der Einsatzbereitschaft des Produkts. Bei SS&C Intralinks habe ich als Führungskraft in der Produktorganisation wichtige bereichsübergreifende Initiativen an diese Phasen geknüpft.
In der Produktions-Release-Phase konnten wir eine Angebotsstrategie entwickeln, umfassendes Marketing und den Verkauf starten sowie die notwendige Unterstützung bereitstellen, etwa im Kundenservice, Site Reliability Engineering und anderen Abteilungen, um das Produkt zum Erfolg zu führen.
Dies gilt nach den meisten Maßstäben als vollständiges Produkt, obwohl es unter Umständen noch kleinere akzeptierte Probleme gibt. In einigen Fällen, wie etwa Linux, gibt es zwei Arten von stabilen Versionen: LTS (Langzeitunterstützung) und reguläre stabile Versionen.
- Reguläre stabile Versionen – sind die am häufigsten vorkommenden Veröffentlichungen. Sie sind einfach zu installieren (besonders wenn es sich um Betriebssysteme handelt) und, wie der Name schon sagt, stabil. Wenn man Software in einer Produktivumgebung testen möchte, nutzt man in der Regel diesen Typ der Veröffentlichung. Webanwendungen bezeichnen reguläre stabile Versionen oft als „Major“-Releases.
- LTS (Langzeitunterstützung) Versionen – sind speziell für den langfristigen Einsatz in Produktivumgebungen konzipiert. Diese Releases haben einen längeren Lebenszyklus als Standardversionen (der durchschnittliche Zeitraum zwischen LTS-Versionen beträgt drei Jahre). Dadurch wurden sie intensiv getestet und gelten als sicherer als stabile Versionen.
Abschließende Gedanken
Das Verständnis der verschiedenen Phasen des Software-Release-Lebenszyklus eines Produkts ist eine hervorragende Möglichkeit für Produktmanager, die Aktivitäten mit Bezug auf unterschiedliche Abteilungen und Kunden genau auf die jeweiligen Stufen im SRLC auszurichten. Dadurch kann das Produkt klar in den umfassenderen Kontext der Unternehmensziele, Strategien und Initiativen eingeordnet werden.
Diese Phasen als „Trigger“-Punkte zu nutzen, ermöglichte es mir, mein Produkt erfolgreich in ein großes Unternehmen zu integrieren und sämtliche Abläufe zu steuern sowie den Markterfolg sicherzustellen.
Sind die SRLC-Phasen abgeschlossen, hat das Produkt seine Verkaufs- und Wachstumszyklen durchlaufen und die Organisation erhält Signale, dass das Produkt ausläuft, beginnt der Wartungs-Lebenszyklus, der Folgendes umfasst:
- Behebung von Fehlern, die vom Kunden während der Einführungsphase gemeldet wurden,
- das Hinzufügen neuer Funktionen oder
- Anpassungen an bestehenden Funktionen auf Wunsch des Kunden, entsprechend sich ändernden Bedürfnissen und technologischem Fortschritt.
Schließlich erreichen irgendwann alle Softwareprodukte das Ende ihres Lebenszyklus, wenn sie vom Entwickler nicht mehr unterstützt werden.
Wenn Sie mehr über Best Practices im Produktmanagement und in der Produktentwicklung erfahren möchten, abonnieren Sie uns! Bis zum nächsten Mal.
Verwandte Beiträge:
- 6 Stufen des Software Development Life Cycle (SDLC)
- Wie man effektive Software-Release-Notes verfasst, die Nutzer begeistern
Verwandte Tool-Liste: Software Release Management Tools
Auch einen Blick wert:
