Releasemanagement

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Zusammenhänge verschiedener Prozesse im Release Management

Das Releasemanagement (auch Release-Management, englisch release management) ist ein Prozess, der sich ursprünglich aus den Erfahrungen des Produktmanagements der Software-Industrie ableitete, welcher die Bündelung von Konfigurations-Änderungen zu einem Release oder Versionspaket und deren ordnungsgemäße Eingliederung in der Infrastruktur sicherstellte. Releasemanagement bedeutet die Planung und Durchführung der Veröffentlichung, von der Idee bzw. den ersten Anforderungen bis zum Erreichen des Endbenutzers. Es interagiert somit zwischen Change- und Konfigurationsmanagement. Es ist Teil des ITSM bzw. des ITIL-Service Managements.

Das Releasemanagement hat zur Aufgabe, sicherzustellen, dass eine erwartete Anforderung an eine Veränderung in einem Prozess mit einem vertretbaren Risiko in der geforderten Zeit erfolgreich umgesetzt werden kann. Anpassungen im Geschäftsbereich auf sich ständig verändernde äußere Anforderungen erfordern eine permanente Neukonfiguration der Systeme, die die zugrunde liegenden Prozesse steuern. Gleichzeitig erhöht in einer komplexen Umgebung dieser evolutive Prozess der dauerhaften Neukonfiguration von Systemen das Risiko, lebenswichtige Geschäftsprozesse durch Fehlkonfiguration zu stören, unvorhergesehen zu beeinflussen oder ganz zum Stillstand zu bringen. Ein Unternehmen rechtfertigt den Einsatz eines Releasemanagement mit der Reduktion der teilweise erheblichen Kosten durch etwaige Prozess-Störungen, die durch notwendige konfigurative Veränderungen hervorgerufen werden können. Das Releasemanagement hat die Aufgabe, die Risiken der Unterbrechung von Geschäftsprozessen bei Konfigurationsänderungen bestehender Systeme, die durch schlecht geplante oder nicht ausreichend getestete Systemkonfigurationen hervorgerufen werden, zu mindern.

Aufgaben des Releasemanagements[Bearbeiten]

Das Releasemanagement hat folgende Aufgaben:

  • Festlegung des funktionellen Umfangs
  • Festlegung des genauen Zeitplans einer Releasefreigabe in Abstimmung mit dem Change- bzw. Produktmanagement
  • Qualitätskontrolle zur Überwachung der Einhaltung der Kriterien, die im Rahmen des Change- bzw. Produktmanagements für eine Releaseerstellung festgelegt wurden
  • Dokumentation des Umfangs und der Änderungen, dabei insbesondere Beschreibung der für die Rückwärtskompatibilität relevanten Eigenschaften
  • Verwaltung der Versionshistorie (Versionierung), damit Sicherstellung der Reproduzierbarkeit

Releaseanforderung[Bearbeiten]

Releaseanforderungen werden zunächst vom Change-Management erfasst. Das Change-Management formuliert in der Regel auch den 'Use Case' und kümmert sich auch um den (je nach Risiko-Relevanz teilweise recht komplexen) Genehmigungsprozess. Anschließend wird die eigentliche Aufgabe der Durchführung eines Changes, also die 'Executive', an das Releasemanagement übergeben. Daraus resultiert oft die Meinung, das Releasemanagement sei ein Teilbereich des Change-Managements. Das Releasemanagement ist jedoch nach Praxis-Erfahrung aus dem ITIL-Bereich bewusst kein Teilbereich des Change-Managements. Unternehmen, die dies nicht berücksichtigen und Releasemanagement im Change-Management integrieren, werden recht schnell in interne Konfliktsituationen der Verantwortlichkeiten kommen, in denen die wichtigen Elemente der Risikoeinschätzung, der Planung und Qualitätskontrolle meistens aus dem notwendigen Gleichgewicht kommen. Somit stellt das Releasemanagement auch sicher, dass ein Release die erwartete Anforderung mit einem vertretbaren Risiko in der geforderten Zeit umsetzen kann. Die aktuelle ITIL Version 3 berücksichtigt diesen Umstand und hat deshalb das Releasemanagement explizit als eigenständige Prozesseinheit definiert.

Releaseplanung[Bearbeiten]

Die Planung erstellt das Kerngerüst, die eigentliche Blaupause eines gesamten Releaseprojektes.

Releaseentscheidung[Bearbeiten]

Der Releasemanager entscheidet, wann ein System als Release zur Weitergabe freigegeben werden kann. Er muss dabei darauf achten, dass das System frei von schwerwiegenden Fehlern, also produktionssicher ist. In der traditionellen Softwareentwicklung ist dies der Fall, wenn der Entwicklungsprozess das Stadium Release Candidate erreicht.

Risikoanalyse[Bearbeiten]

Risiken sind immer mit Geschäftsperspektiven abzugleichen. Dabei wird ein Restrisiko teilweise bewusst in Kauf genommen um z. B. aufgrund von zu späten Releases mit höherer Qualität keinen geschäftlichen Vorteil, den man durch ein früheres Releasedatum erreicht, zu verlieren.

Qualitätskontrolle[Bearbeiten]

Die Qualitätskontrolle eines Releases ist eines der wichtigsten Elemente der Sicherstellung der Change Objectives, also der Frage

  • was will man ursprünglich mit der Änderung einer Konfigurationsänderung aus der Geschäftsperspektive erreichen und
  • stimmt das Ergebnis auch mit den Anforderungen überein?

Realisiert wird dies durch entsprechende Testpläne, durch Simulationen und Entwicklung und Test der Strategien zu Notfallsituationen.

Releaseerstellung[Bearbeiten]

Wenn die reine Entwicklung abgeschlossen ist, bedeutet das aber nicht gleichzeitig eine Veröffentlichung. Dazu müssen oft noch weitere Schritte erfolgen:

  • Erstellung der Konfigurationsstände, welche alle Komponenten beinhaltet
  • Zusammenstellung und Bezeichnung sowohl des Quellcodes als auch sämtlicher Datendateien
  • Bereitstellung von Konfigurationsdateien, Benutzerhandbüchern, technischer Dokumentation, ...
  • Bereitstellung/Vertrieb (Datenträger, E-Mail, Download, ...)
  • Ausbildung und Vorbereitung der Mitarbeiter, die das System nutzen
  • Ausbildung und Vorbereitung der Mitarbeiter, die das System pflegen

Releasedokumentation[Bearbeiten]

Die Dokumentation von Releases ist z. B. zur späteren Nachproduktion oder Rückverfolgung von speziellen Releases für einzelne Kunden oder Plattformen sehr wichtig.

Die Dokumentation sollte eine komplette Beschreibung der gesamten Entwicklungsumgebung und des zugrunde liegenden Systems (Programme, Versionen, Dokumente, Beschreibungen, Anleitungen, ...) enthalten, um eine spätere Wiederherstellung zu vereinfachen.

DHL - Definitive Hardware Library[Bearbeiten]

Die Archivierung zur Logistischen Verwaltung der technischen Komponenten eines Unternehmens.

DSL - Definitive Software Library[Bearbeiten]

Die Archivierung zur Logistischen Verwaltung der Softwarekomponenten eines Unternehmens. DSL wurde nach der Veröffentlichung von ITIL V3 (30. Mai 2007) zu DML (Definitive Media Library).

Zertifizierung[Bearbeiten]

ISO/IEC 20000 Release-Management als Teilbereich des ISO/IEC 20000 Standards.