Lade Inhalt...

Release Management als Teil des Softwarelebenszyklus

Projektarbeit 2018 20 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

I. Inhaltsverzeichni

Vorwort

I. Inhaltsverzeichnis

II. Abbildungsverzeichnis

III. Abkürzungs- und Symbolverzeichnis A-Z

1. Einleitung

2. Softwarelebenszyklus
2.1 Spezifikation
2.2 Entwurf
2.4 Installation
2.5 Betrieb

3. Release Management
3.1 Aufgaben und Inhalt
3.2 Release planen
3.3 Release Inhalte zusammenstellen
3.5 Rollout planen
3.6 Rollout durchführen
3.7 Herkunft

4. Fazit

IV. Literaturverzeichni
A. Bücher A-Z
B. Digitale Medien A-Z

Vorwort

Während seiner beruflichen Laufbahn hatte der Autor dieser Projektarbeit verschiedene Rollen und Verantwortlichkeiten innerhalb des Softwarelebenszyklus inne. Hierunter findet sich die Analyse und Konzeption, sowie die Entwicklung von Software, die Leitung von Softwareentwicklungsprojekten gleichsam wie die laterale Führung von Scrum-Teams. Während seiner Zeit als Release Manager reifte die Überlegung zu dieser Arbeit.

Großer Dank geht an Simon Kühn, Annika Samuelsson und Prof. Dr. Erich Ehses.

II. Abbildungsverzeichni

Abbildung 1 - Seite 7:

“Softwarelebenszyklus inkl. nicht funktionaler Anforderungen” (Quelle: Siehe ³ - Seite 1 )

Abbildung 2 - Seite 11:

“ITIL Aufbau und Inhalt dargestellt als Lebenszyklus IT gestützter Prozesse und Services” (Quelle: http://www.bmc.com/content/dam/bmc/guides/itil-processes.png - Stand: 01.11.2017)

III. Abkürzungs- und Symbolverzeichnis A-Z

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Die Projektarbeit “Release Management als Teil des Softwarelebenszyklus” beschäftigt sich mit der Frage ob und in welchen Aspekten des Softwarelebenszyklus sich die Disziplin Release Management widerspiegelt. Zu Beginn der Arbeit stellt der Autor die These auf, dass das Release Management verortet werden kann und durch seinen Verantwortungs- und Aufgabenbereich die Aspekte Implementierung, Installation und Außerbetriebnahme behandelt.

Diese Fragestellung wird der Autor versuchen durch eine ausgiebige Literaturanalyse zu beantworten. Hierzu wird er zunächst den Softwarelebenszyklus, seine Aufgaben und Besonderheiten beschreiben. Anschließen wird er auf die Herkunft, Eigenschaften und Aufgaben des Release Managements eingehen und versuchen darzustellen, ob und an welchen Stellen dieses im Softwarelebenszyklus verortet werden kann.

2. Softwarelebenszyklu

Während der Produktlebenszyklus, ein Modell aus der Betriebswirtschaft, 1959 erstmals beschrieben, den Zeitraum zwischen Markteinführung und Marktaustritt eines Produkts beschreibt (Vgl. 5 - Seite 1-5), so beschreibt der Softwarelebenszyklus, wenngleich auch Software ein Produkt ist, den Zeitraum von der ersten Idee zur Software, über die Erstellung, Einführung und deren Außerbetriebnahme. Jedes Softwaresystem durchläuft dieses Phasenmodell und auch bei der Erstellung von Software sollten die nachfolgenden Phasen und Ihre Anforderungen berücksichtigt werden - insbesondere gilt dies für architekturelle Entscheidungen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Softwarelebenszyklus inkl. nicht funktionaler Anforderungen

In der Regel beginnt der Softwarelebenszyklus mit einer Spezifikationsphase (siehe hierzu Abbildung 1), in der die grundlegenden fachlichen und nicht funktionalen Anforderungen des IT-Systems beschrieben werden und endet in der Regel mit der Abschaltung bzw. mit der Ablösung durch eine neue Version de IT-Systems.

Je nachdem, welches Vorgehensmodell bei der Entwicklung von Software genutzt wird, können die einzelnen Phasen teilweise parallel oder in wiederkehrenden Schleifen öfter durchlaufen werden. Neben dem iterativen Vorgehensmodellen, beispielsweise Scrum, dem Spiralmodell und dem klassischen V-Modell geht der Autor in der folgenden Beschreibung der einzelnen Phasen, sofern nicht explizit genannt, vom Wasserfall-Modell aus (Vgl. 3 - Seite 1-2 ). Prozesse, Methoden oder Disziplinen, die in allen Bereichen des Softwarelebenszykluses relevant sind, werden auch al Full-Circle-Disziplin bezeichnet.

2.1 Spezifikation

In der Spezifikationsphase gilt es zunächst herauszufinden, welche Anforderungen das Softwaresystem erfüllen muss. Diese beschreibt nicht nur die Aufgaben und den Zweck des Systems sowie die mögliche Erstellung und Verarbeitung von Daten, sondern beispielsweise auch, in welchem IT Umfeld die Software betrieben werden soll. Hier sind Anforderungen bezüglich der Hardware Voraussetzungen ebenso zu erfüllen, wie die Anzahl von zeitgleichen Nutzern. Weitere Fragen wären beispielsweise, welche Partnersysteme anzubinden oder zu integrieren sind, ob mit lizensierten oder Open Source Bibliotheken zu arbeiten ist, ob die Software lokal oder zentral verwaltet wird und dergleichen. All diese Informationen zusammenzutragen und in einem sogenannten Pflichtenheft, in agilen Projekten wäre dies ein Backlog mit entsprechenden Stories, zu dokumentieren obliegt dem Requirements Engineering. Das Pflichtenheft stellt im Detail dar, wie ein Auftragnehmer die Anforderungen des Auftraggebers, meist beschrieben in einem sogenannten Lastenheft, verstanden hat und umzusetzen gedenkt. Die dokumentierten Anforderungen sollten zwischen allen Stakeholdern und Beteiligten im Prozess abgestimmt und gleichwohl verstanden sein (Vgl. 4 - Seite 403).

2.2 Entwurf

In der Entwurfsphase kommt es darauf an, die spezifizierten Anforderung in ein technisches Modell für die fertige Software zu übertragen. Dies kann in grober oder detaillierter Fassung geschehen. Hier wird über die Architektur, Funktion und Benutzbarkeit entschieden und bewertet, inwiefern der Entwurf die Anforderungen erfüllen oder gegebenenfalls auch nicht erfüllen kann. Es kann durchaus sein, dass funktionale Anforderungen aufgrund der technischen Gegebenheiten, aus Kosten- oder Zeitgründen nicht umgesetzt werden können. Am Ende dieser Phase sollte ein Beschluss der Stakeholder stehen (Vgl. 3 - Seite 1,6).

2.3 Implementierung

In der Implementierungsphase wird der Entwurf in Programmcode umgesetzt und die eigentliche Software erstellt (Vgl. 3 - Seite 1). Um die architekturelle Umsetzung und die Funktion zu gewährleisten, wird die Software teilweise oder vollständig lokal oder auf speziellen Testsystemen installiert und ausgeführt. Hier können dann alle erforderlichen Qualitätssicherungsmaßnahmen durchgeführt werden um die Anforderungen zu erfüllen und auch die nachfolgenden Phasen zu verproben (Vgl. 3 - Seite 1, 492 ff.; Vgl. 4 - Seite 403-404).

2.4 Installation

Im Anschluss an die Entwicklung der Software wird das Produkt auf den Zielrechnern verteilt und installiert. Hier kann das Produkt auch abgenommen und eingeführt werden. Diese Phase wird oft auch Rollout oder Deployment genannt. Dieser Phase sollte eine entsprechende Planung vorausgehen, um zu klären, wie das Softwareprodukt verteilt wird. Dies kann im sogenannten “Big Bang” oder phasenweise geschehen. Zudem müssen technische und fachliche Abhängigkeiten bei der Installation berücksichtigt werden (Vgl. 3 - Seite 522).

2.5 Betrieb

In der Betriebsphase wird die Software technisch betrieben und bereitgestellt. Während der Betriebsphase können weitere Ereignisse eintreten. Diese können hardware- und softwareseitige Fehler sein, die im Rahmen des Servicing, also im Rahmen aller Maßnahmen die den störungsfreien Betrieb gewährleisten, behoben werden. Dies kann durch Komponententausch bzw. durch das Einspielen (Installieren) sogenannter Patches oder Bugfixes getan werden. Bei kleineren Phänomen, die Software betreffend, handelt es sich hierbei meist um eine Datenmanipulation oder die Erweiterung des bestehenden Programmcodes im laufenden Betrieb, um den Fehler zu beseitigen. Bei größeren Phänomenen oder beim Auftreten neuer oder geänderter Anforderungen bedarf es in der Regel einer neuen Version der Software. Dies wird auch als Evolution bezeichnet, da sich die Funktionen der Software stückweise mit den Anforderungen verändert und weiterentwickelt. Weitere Phasen des Betrieb können die “Phase Out” und die “Closing Down” Phase sein. Ersteres beschreibt die weitgehende Sicherstellung des Betriebes ohne weitere oder zusätzliche Anstrengungen zur Fehlerbeseitigung oder Erweiterung des Programms. Zweiteres beschreibt die Abschaltung des Systems. Beide Phasen sind jedoch relativ selten anzutreffen, der Normalfall ist die Ablösung des Systems durch eine neuere Version. Dies wird von Softwareherstellern im Allgemeinen auch als Release bezeichnet (Vgl. 3 - Seite 2).

3. Release Management

Release Management, im Rahmen der Softwareentwicklung und -bereitstellung, beschreibt alle Tätigkeiten und Maßnahmen um ein fertiges Softwareprodukt zusammenzustellen, bereitzustellen und in den Betrieb zu überführen. Es ist eine Disziplin beschrieben und definiert in der ITIL (IT Infrastructure Library), welche ITSM (IT Service Management) Best Practices, Empfehlungen und Beispiele nach ISO/IEC 20000 sammelt und veröffentlicht (Vgl. 14).

3.1 Aufgaben und Inhalt

Die Hauptaufgabe des Release Managements (im Kontext von ITIL auch Release & Deployment Management genannt) ist es, neue oder geänderte IT-Systeme, in der Regel Software, gegebenenfalls auch Hardwarekomponenten, einzuführen (Erst- oder Ersatzinstallation) und dabei die Qualität sicherzustellen, Ausfallzeiten und Risiken für die Produktionsumgebung zu minimieren und die Softwareversion so zusammenzustellen und zu dokumentieren, dass das Ergebnis reproduzierbar ist.

[...]

Details

Seiten
20
Jahr
2018
ISBN (eBook)
9783668900103
ISBN (Buch)
9783668900110
Sprache
Deutsch
Katalognummer
v458672
Institution / Hochschule
Technische Hochschule Köln, ehem. Fachhochschule Köln
Note
1,3
Schlagworte
Release Management Software Softwarelebenszyklus ITIL

Autor

Zurück

Titel: Release Management als Teil des Softwarelebenszyklus