I 29 - Anhang_19.4_Release_und_Deployment_Management_Reportingplattform_V.0.9.pdf

[Seite 1]

Anhang 19.4

Release und Deployment Management

zu Anlage 19 Servicemanagement

zum Rahmenvertrag vom TT.MM.JJJJ

zwischen

Landesbank Hessen-Thüringen Girozentrale

Neue Mainzer Straße 52 -58

60311 Frankfurt

- nachfolgend Helaba oder Auftraggeber genannt –

und

[Adresszeile 1: Vollständige Firmierung des Auftragnehmers]

[Adresszeile 2: Straße des Auftragnehmers]

[Adresszeile 3: PLZ und Stadt des Auftragnehmers]

- nachfolgend [Kürzel des Auftragnehmers] oder Auftragnehmer ge-

nannt –

– zusammen auch „Vertragspartner“, „Vertragsparteien“ oder „Parteien“

genannt –

Version 0.9

[Seite 2]

Anhang 19.4 – Release und Deployment Management

INHALTSVERZEICHNIS

1 Gegenstand .................................................................................................. 3

1.1 Abgrenzung des Dokuments .......................................................................... 3

1.2 Begriffsklärung ............................................................................................... 3

2 Leistungsbeschreibung .............................................................................. 3

2.1 Release Management .................................................................................... 3

2.2 Deployment Management .............................................................................. 6

2.3 Leistungen und Verantwortlichkeiten ............................................................. 6

3 Prozesseinbindung und -schnittstellen ..................................................... 9

4 Reporting ...................................................................................................... 9

Seite 2 von 9

[Seite 3]

Anhang 19.4 – Release und Deployment Management

1 Gegenstand

Gegenstand dieses Anhangs zu Anlage 19 Servicemanagement des Rahmenvertrages ist die Beschreibung von Leistungen und wesentlichen Aufgaben des Auftragnehmers bei der Zusammenarbeit im Release und Deployment Management sowie die Definition erforderlicher Mitwirkungen durch den Auftraggeber. Deployments werden im Rahmen von IT-Changes durchgeführt; es gelten die Regelungen des Change Management-Prozesses (siehe Anhang 19.3 Change Management).

1.1 Abgrenzung des Dokuments

Dieses Dokument beschreibt weder die internen Prozesse des Auftraggebers noch die des Auftragnehmers. Die Ausgestaltung der Prozesse des Auftraggebers verbleibt in der Hoheit des Auftraggebers, ebenso wie die Ausgestaltung der Prozesse des Auftragnehmers in der Hoheit des Auftragnehmers verbleibt. Wechselseitige Ansprüche beschränken sich auf die Einhaltung bzw. Erfüllung der hier vereinbarten Abläufe, Schnittstellen und Rollen.

Die Regelungen dieses Anhangs stellen den grundlegenden fachlichen und prozessualen Rahmen für das Release und Deployment Management dar. Sie enthalten keine abschlie- ßende operative Ausgestaltung der im Einzelfall anzuwendenden Prozesse, technischen An- forderungen oder betrieblichen Abläufe.

Die für den jeweiligen Leistungsgegenstand maßgeblichen Detailregelungen – insbesondere operative Prozessschritte, Rollen, Schnittstellen, technische Spezifikationen und Dokumenta- tionspflichten – werden von den Vertragsparteien im Rahmen der Leistungsübernahme ge- meinsam konkretisiert und außerhalb dieses Anhangs in einem Prozesshandbuch (vgl. An- lage 19 Servicemanagement) festgelegt. Dieses Dokument präzisiert die vorliegenden Rah- menvorgaben und ist für beide Vertragsparteien verbindlich einzuhalten.

Für den vereinbarten Leistungsgegenstand nicht relevante Anforderungen dieses Anhangs finden keine Anwendung.

1.2 Begriffsklärung

Das Release Management bündelt geplante und inhaltlich oder zeitlich zusammengehörende Systemänderungen und deren korrespondierende IT-Changes, verwaltet die Release-Kapazi- tät und koordiniert die Überführung in alle Umgebungen, die vom Auftragnehmer dem Auftrag- geber oder umgekehrt bereitgestellt werden.

Das Deployment Management verantwortet den störungsfreien und termingerechten Rollout von qualitätsgeprüften und genehmigten Softwareänderungen in die Zielumgebungen (Test/Abnahme, Produktion).

2 Leistungsbeschreibung

2.1 Release Management

Das Release-Management verfolgt folgende Ziele:

• Schutz der Systemintegrität der bestehenden IT-Infrastruktur aller Umgebungen (ins- besondere der Produktionsumgebung)

Seite 3 von 9

[Seite 4]

Anhang 19.4 – Release und Deployment Management

• Sicherstellung durch Quality-Gates, dass nur erfolgreich getestete Komponenten be- reitgestellt werden

• einheitliche und transparente Release-Planung anhand klar definierter Termine für Re- leases (Release-Kalender) und deren Bereitstellung

• eine in ihrer Systematik nachvollziehbare und revisionssichere Planung, Durchführung und Dokumentation der erbrachten Änderungen sowie die Verwaltung der erbrachten Release-Stände.

2.1.1 Arten von Releases

Um eine einheitliche und transparente Release-Planung zu gewährleisten, vereinbaren Auf- tragnehmer und Auftraggeber, in ihren eigenen internen Release-Prozessen einen Standard- fall (Regel-Release) und ein priorisiertes Release (Zwischen-Release).

• Regel-Release (Standard)

Diese Release-Art entspricht dem Standardfall für Releases des Auftragnehmers und des Auf- traggebers. Solche Releases sind in den vereinbarten Gremien langfristig gemäß einer ver- einbarten Planungsperiode sowie mit den Vorlaufzeiten gemäß Kapitel 2.1.2 Termine und Fris- ten zu planen, zu steuern, durchzuführen und abzuschließen.

Beispiele: planbare Veränderungen wie inhaltlich spezifizierte Wartungsfenster für Hard- und Software, Patches, Updates von Anwendungssystemen und Upgrades des Betriebssystems (Versionswechsel)

• Zwischen-Release (priorisiert)

Ein nicht im Rahmen der Planungsperiode planbares Release zur zielgerichteten Deckung eines begründeten Bedarfs mit entsprechend kürzeren Planungszeiten (z.B. Abwendung von Schäden, die nicht unmittelbar in einem Notfall behoben werden müssen).

2.1.2 Termine und Fristen

Als Planungsperiode wird ein Planungshorizont von einem Jahr vereinbart, der mindestens quartalsweise rollierend erweitert wird. Dieser Planungshorizont gilt als Standardfall (Regel- Release).

Den Turnus von Regel-Releases sowie verbindliche Vorlaufzeiten für die Umsetzung von Re- gel-Releases und priorisierten Releases werden die Vertragsparteien im Rahmen der Leis- tungsübernahme vereinbaren und dokumentieren.

2.1.3 Bewertung von Releases

Die Bewertung von Releases findet durch die Auswirkungsanalyse auf einem risikobasierten Ansatz innerhalb der definierten Vorlaufzeiten statt. Die finale Freigabe von Releases erfolgt im Rahmen der Autorisierung der korrespondierenden IT-Changes. Es gelten die Regelungen des Change Management-Prozesses (siehe Anhang 19.3 Change Management).

Sollte sich ein Release-Gegenstand im Rahmen einer bereits gestarteten Auswirkungsanalyse ändern, muss eine Re-Evaluierung der Risikostufe erfolgen und eine erneute Auswirkungs- analyse gemäß der Risikostufe und unter Berücksichtigung der vollständigen Vorlaufzeit statt- finden.

Seite 4 von 9

[Seite 5]

Anhang 19.4 – Release und Deployment Management

2.1.4 Test von Releases

Die durch den Auftragnehmer durchzuführenden Änderungen an Systemen werden durch den Auftragnehmer innerhalb der Vorlaufzeiten angemessen sowie erfolgreich getestet. Der erfolg- reiche Abschluss und die Dokumentation der Tests müssen spätestens zum Zeitpunkt der Genehmigung im Change-Prozess vorliegen. In die Tests ist der Auftraggeber bei Bedarf mit einzubinden.

Die vom Auftragnehmer durchgeführten Tests werden in einer revisionssicheren Systematik geplant, durchgeführt und entsprechend in Test-Nachweisen dokumentiert. Der Auftragneh- mer übergibt die Test-Nachweise dem Auftraggeber anlassbezogen auf Anforderung des Auf- traggebers in einem geeigneten Format. Darüber hinaus hat der Auftragnehmer dem Auftrag- geber periodisch Test-Nachweise zu einer vom Auftraggeber definierten Stichprobe zur Ver- fügung zu stellen.

Anforderungen für das Testen unterscheiden sich innerhalb der verschiedenen Umgebungen wie Entwicklungs-, Test- und anderen Nicht-Produktionsumgebungen. Der Auftragnehmer ge- währleistet bei seinen Tests die Trennung der jeweiligen Umgebung von der Produktionsum- gebung. Dies betrifft insbesondere Konten, Daten oder Verbindungen.

Tests sind in einer Testumgebung durchzuführen, um die Systeme und Anwendungen des Auftraggebers im laufenden Geschäftsbetrieb nicht zu gefährden. Mit Tests sind auch quali- tätssichernde Maßnahmen in der Produktion wie Penetrationstests gemeint. Ausnahmen sind schriftlich zu genehmigen.

Sollte es notwendig sein, Testtätigkeiten innerhalb der Produktionsumgebung des Auftragge- bers durchzuführen, wird der Auftragnehmer seinen Bedarf bei dem Auftraggeber schriftlich ankündigen und genehmigen lassen. Hierbei muss der Test eindeutig identifizierbar sein, be- gründet werden und zeitlich begrenzt sein. Nach erfolgter Genehmigung wird der Auftragneh- mer den Test nur in Abstimmung mit dem Auftraggeber durchführen. Die Anforderungen des Auftraggebers für das Testen in Produktionsumgebungen sind für den Auftragnehmer bindend. Während des Tests achten Auftraggeber und Auftragnehmer darauf, dass die Verfügbarkeit, Vertraulichkeit, Integrität und Authentizität von IKT-Systemen und -Produktionsdaten in der Produktionsumgebung sichergestellt sind.

Dem Auftraggeber ist es gestattet den Testumfang gemäß der Kritikalität betroffener Ge- schäftsprozesse und Komponenten festzulegen.

Sollte der Auftragnehmer zur Erfüllung seiner Leistungspflicht Software zum Einsatz bringen, so ist diese Software beim ersten Einsatz vor der Integration in die Systeme des Auftraggebers sowie bei Veränderungen einer Sicherheits- und Qualitätsprüfung (insb. Code Review, stati- sche Code-Analysen, Unit Tests, etc.) zu unterziehen.

Die dem Auftraggeber durch den Auftragnehmer zur Verfügung gestellten Test-Nachweise müssen mindestens Testfallspezifikationen, Testprotokolle und Fehlerberichte sowie mindes- tens folgende Kennzahlen enthalten:

• Anzahl geplanter und durchgeführter Testfälle,

• Anzahl durchgeführter Testfälle im Verhältnis zu der Anzahl geplanter/erstellter Test- fälle,

Seite 5 von 9

[Seite 6]

Anhang 19.4 – Release und Deployment Management

• Anzahl offener Fehler nach Schweregrad sowie eine nachvollziehbare Begründung, warum im Einzelfall mit diesen offenen Fehlern ein Deployment trotzdem durchgeführt werden kann, so anwendbar.

Weitergehende Anforderungen an die Durchführung von Softwaretests, einschließlich detail- lierter Testmethoden, Prüfkriterien und Dokumentationsvorgaben, sind in Anlage 15 Soft- wareentwicklung des Rahmenvertrages verbindlich festgelegt.

2.2 Deployment Management

Im Vorfeld des Deployments ist die Gesamtlösung aus Betriebssicht angemessen zu doku- mentieren und die Dokumentation dem Auftraggeber in Verbindung mit einem angemessenen Know-how-Transfer (z.B. Handbücher, Schulungsunterlagen) zu übergeben.

Nach durch den Auftraggeber erteilter Change-Genehmigung wird der IT-Change an den Auf- tragnehmer zur Umsetzung übergeben. Der Auftragnehmer hat das Deployment des IT-Chan- ges zu koordinieren. Der Auftragnehmer prüft, ob das Deployment gemäß der Planung im Deployment-Drehbuch durchgeführt wurde. Diese Aktivität wird unmittelbar nach oder wäh- rend des Deployments durchgeführt.

Bei einem (teilweise) nicht erfolgreichen Deployment müssen angemessene Korrekturmaß- nahmen gemäß Einzelfallbetrachtung und Fallback-Plan angestoßen werden (z.B. Hotfix, Roll- backs einleiten). Daran ist ein Lessons-Learned (PIR)-Prozess anzuschließen, dessen Ergeb- nisse dem Auftraggeber vom Auftragnehmer in geeigneter Form, schriftlich zur Verfügung ge- stellt werden.

2.3 Leistungen und Verantwortlichkeiten

2.3.1 Leistungen des Auftragnehmers

Im Prozess Release und Deployment Management erbringt der Auftragnehmer insbesondere folgende Leistungen:

• Bereitstellung und Betrieb von Deployment-Tools sowie eines Software-Repositories zur Übergabe von Release-Paketen zwischen Auftraggeber und Auftragnehmer,

• Empfehlung der Implementierung bestimmter Einstellungen sowie Patches und Aktua- lisierungen für Komponenten des Auftraggebers, soweit der Auftragnehmer Einsicht erhalten hat oder erhält,

• Planung von Releases und deren Bereitstellung an den vom Auftragnehmer bereitge- stellten Komponenten hinsichtlich Zeit und Inhalt mit Darstellung der Auswirkungen auf die betroffenen Systeme/Komponenten/IT-Services des Auftraggebers und Berück- sichtigung der vereinbarten Planungsperiode und Vorlaufzeiten,

• Abstimmung und Synchronisation der Release-Planung mit dem Auftraggeber und wei- teren wesentlichen Stakeholdern, z.B. eingebundene Dritt-Dienstleister, IT-Fachberei- che etc., mindestens in regelmäßigen Terminen und zusätzlich bei Bedarf, d.h. bei kurzfristig anzusetzenden Zwischen-Releases bzw. deren Bereitstellung,

Seite 6 von 9

[Seite 7]

Anhang 19.4 – Release und Deployment Management

• Erstellung und Pflege eines Release-Kalenders unter Berücksichtigung der vereinbar- ten Planungsperiode, der regelmäßig mit dem Auftraggeber und den wesentlichen Sta- keholdern abgestimmt wird und auf den der Auftraggeber Zugriff hat. Der Zugriff des Auftraggebers auf diesen Release-Kalender des Auftragnehmers entbindet den Auf- tragnehmer nicht von der Pflicht zur proaktiven Information und Abstimmung mit dem Auftraggeber, insbesondere bei Änderungen an bereits vereinbarten Release-Termi- nen,

• Zusammenstellung der Release-Pakete für vom Auftragnehmer verantwortete Kompo- nenten und Bereitstellung der erforderlichen Dokumentation unter Einhaltung der ver- einbarten Vorlaufzeiten,

• Durchführung von Tests von Releases und Freigaben von korrespondierenden IT- Changes aus Betriebssicht, um sicherzustellen, dass die auf den vom Auftragnehmer verantworteten Komponenten aufsetzenden Services des Auftraggebers soweit funkti- onsfähig sind, dass der Auftraggeber diese Services testen und die dem Release kor- respondierenden IT-Changes autorisieren kann,

• Durchführung von Deployments im Rahmen von IT-Changes und entsprechende Nachweise,

• Abschließende Informationen über die Ergebnisse des Releases.

2.3.2 Mitwirkungspflichten des Auftraggebers

Folgende Mitwirkungspflichten bestehen seitens des Auftraggebers:

• Bereitstellung von Informationen zu geplanten Releases bzw. Release-Anfragen für vom Auftraggeber verantwortete Komponenten (Anwendungs-Releases),

• Zusammenstellung der Release-Pakete für vom Auftraggeber verantwortete Kompo- nenten und Übergabe an den Auftragnehmer zum Deployment inklusive entsprechen- der Dokumentation (z.B. Installationsanleitungen / Deployment Drehbuch, Fallback- Plan und Testabnahmeprotokoll),

• Durchführung von Tests und Freigaben an vom Auftraggeber verantworteten Kompo- nenten, wenn diese für die Erbringung der Leistungen des Auftragnehmers relevant sind.

2.3.3 RACI-Matrix

Im Folgenden sind die für das Release und Deployment Management notwendigen Leistun- gen, die durch die Auftragnehmer (AN) und den Auftraggeber (AG) zu erbringen sind, definiert. Dabei ist jeder Leistung eine Verantwortlichkeit gemäß RACI-Matrix aus Anlage 19 Service- management zugeordnet.

Seite 7 von 9

[Seite 8]

Anhang 19.4 – Release und Deployment Management

Seite 8 von 9

[Seite 9]

Anhang 19.4 – Release und Deployment Management

• Die Zuweisung C oder I ist abhängig von der Art der Komponente, wobei folgende Einstufung gilt: • C: exklusiv für den Auftraggeber betriebene Komponenten • I: mit Vetorecht für den Auftraggeber für shared systems (querschnittlich vom Auftragnehmer betriebene Komponenten) Tabelle 1: Release und Deployment Management RACI

3 Prozesseinbindung und -schnittstellen

Im Rahmen der Serviceerbringung arbeitet der Auftragnehmer eng mit dem Auftraggeber zu- sammen.

Die Einzelheiten der Zusammenarbeit werden im Zuge der Leistungsübernahme gemeinsam von beiden Parteien festgelegt, in konkrete Prozessschritte überführt und entsprechend doku- mentiert.

Die zur technischen Unterstützung des Release und Deployment Management eingesetzten Tools und Systeme werden ebenfalls im Rahmen der Leistungsübernahme gemeinsam defi- niert und dokumentiert.

Der Release- und Deployment-Prozess hat bezüglich Beauftragung, Genehmigung, Abwick- lung, Dokumentation und Abnahme Schnittstellen insbesondere zu folgenden Prozessen

• dem Change Management-Prozess, siehe Anhang 19.3 Change Management • dem kaufmännischen bzw. vertraglichen Änderungsverfahren, siehe Ziffer 11 Ände- rungsmanagement des Rahmenvertrags.

Es gelten daher die Regelungen und Rollen auch in Bezug auf und im Zusammenspiel mit diesen Prozessen.

4 Reporting

Der Auftragnehmer stellt dem Auftraggeber die in der Anlage 2 Berichtswesen definierten Service Level-Reports zum Release und Deployment Management in der vereinbarten Form bereit.

Seite 9 von 9