Seitenhistorie
| Anker | ||||
|---|---|---|---|---|
|
| Inhalt | ||
|---|---|---|
|
Beginn des Verfahrens | 01. März 2011 |
|---|
1. Releaseplanungen
Import-/Export-Release
| Auszug einschließen | ||||
|---|---|---|---|---|
|
Schnittstellen-Release
| Auszug einschließen | ||||
|---|---|---|---|---|
|
CBS-Release
| Auszug einschließen | ||||
|---|---|---|---|---|
|
2. Releasebeschreibung
Name | Beschreibung | Workflow-Besonderheiten | Frequenz | IT-Zuständigkeit |
|---|---|---|---|---|
(CBS=Central Bibliographic System) | enthalten sind CBS-Anpassungen
| Eine Prüfung der Anforderungen (durch die Fachabteilungen oder IT) (siehe Workflow des CBS-Release) | ca. alle zwei Monate | Hr. Grund |
enthalten sind Anforderungen an die | Die Anforderungen und Vorgaben sollten zur Anforderungsfrist | alle vier Monate / | Hr. Althaus | |
| Schnittstellen-Release | enthält Anforderungen an die
| Die Anforderungen und Vorgaben sollten zur Anforderungsfrist sowohl mit den Fachabteilungen (i.d.R. 2D) als auch innerhalb der IT abgestimmt sein, damit nach der Anforderungsfrist sofort mit der Umsetzung begonnen werden kann. | alle vier Monate / i.d.R. der letzte Dienstag im Monat | Hr. Althaus |
3. Zielsetzungen des Change Management
- Aufwandsminimierung
der Aufwand für Change-Requests
Informationen zum ILTIS-Change-Management
Stand: Nach dem Review des Workflows am 11.08.2011 (Teilnehmer: Althaus, Becker, Czech, Diebel, Hernandez, Jochum, König, Molitor, Polak, Wiegand)
Ab 1. März 2011 wird ein neues Verfahren für die Planung, Bearbeitung und Durchführung von Anforderungen an das ILTIS-Katalogsystem eingeführt.
Zielsetzungen
...
- , die als Jira-Tickets gemeldet werden, soll durch Bündelung der Anforderungen reduziert werden
- Konzentration
die MitarbeiterInnen der IT sollen sich stärker auf zeitkritische (Projekt-)Aufgaben konzentrieren können - Information
die Information der Fachabteilungen über die Anforderungsplanung
...
- soll verbessert werden
- Abhängigkeiten
Änderungen sollen frühzeitig auf Wechselwirkungen und Abhängigkeiten geprüft werden - Bearbeitungszeit
die Bearbeitung von Anforderungen, die als Jira-Tickets gemeldet wurden, soll
...
- kontrolliert und
...
- zeitnah erfolgen
...
- Verläßlichkeit
über Jira-Tickets gemeldete Anforderungen sollen zuverlässig bearbeitet werden, indem sie mit Releaseplanung erfolgen - Workflow
durch Definition eines abgestimmten sollen die Zuständigkeiten eindeutig festgelegt werden
Besonderheiten (Fehler, Bugs, Projektaufgaben, spezielle Komponenten)
- akute Fehler bzw. Bugs
Abgrenzungen
Folgende Anforderungen, Meldungen werden nicht in diesem Verfahren behandelt:
- akute Fehler, die zu einer Störung in ILTIS führen, werden sofort bearbeitet umgehend außerhalb der Releaseplanung bearbeitet
(die Bewertung, ob es sich um einen akuten Fehler handelt erfolgt mittels Einzelfallprüfung durch die Leiter der Jira-Projekte, d.h. Althaus, Diebel) )
- Anforderungen, die sich aufgrund Einführung und Test im Rahmen eines Projektes zur Einführung eines neuen Verfahrens, Geschäftgangs, etc. ergeben, werden nach wie vor zeitnah bearbeitet
Hinweise zur Realisierung
...
werden einem bestehenden Release zugeordnet. Je nach Umfang der Anforderungen sind hier jedoch gesonderte Termine einzuhalten.
- Datenmanipulationen und Anpassungen von WinIBW-Scripten werden i.d.R. unabhängig von den CBS-Konfigurations-Releases geplant und bearbeitet.
- Das Jira-Projekt ZDB-ANFORDERUNGEN wird seit 1.1.2013 nur noch zur Dokumentation der vor 2013 erstellten Anforderungen verwendet.
Es können dort keine Tickets mehr erstellt werden.
...
Art des Releases
...
Eingang der
Anforderung
...
Produktiv-
setzung
...
Interner Jira-Link
zu einem Beispiel-Release
...
CBS-Konfigurations-Release MM.JJ
Anpassungen des Datenformates, der Validation, der Expansion und der Indexierung
Die Bearbeitungszeit nach Eingang der Anforderung beträgt ca. 3 Wochen.
Anzahl pro Jahr 11
Frequenz: monatlich
Ausnahme: August aufgrund Sommerurlauben
...
Importformate-Release MM.JJ
Anpassungen der Importkonversionen
(MARC21, ONIX, XMetaDiss, Formulardaten)
Die Bearbeitungszeit nach Eingang der Anforderung beträgt 1,5 Monate.
Anzahl pro Jahr: 5
Frequenz: alle 2 Monate, gerade Monate,
Ausnahme: August aufgrund Sommerurlauben
...
bis 15.12. ->
bis 15.02. ->
bis 15.04. ->
bis 15.08. ->
bis 15.10. ->
...
am 01.02.
am 01.04.
am 01.06.
am 01.10.
am 01.12.
...
Beispiele für das Zusammenspiel von Anforderungseingang und Produktivsetzung:
- Eine Anforderung an die Validation im Katalogsystem muss bis zum 10.03. in IT vorliegen, damit sie am 01.04. produktiv gesetzt werden kann.
- Eine Anforderung an den Import von MARC21 muss bis zum 01.03. in IT vorliegen, damit sie am 01.05. produktiv gesetzt werden kann.
Laufende Zeitplanung
- Beginn des Verfahrens
Das Verfahren beginnt ab 01.03.2011, d.h. dass alle Anforderungen, die ab diesem Stichtag eingehen, nach dem neuen Verfahren bearbeitet werden.Ggf. werden jedoch bereits bestehende Anforderungen in die Releaseplanungen integriert. - Review des Verfahrens
Im Juli 2011 wird ein Review dieses Verfahrens erfolgen, bei dem entschieden wird, ob es weitergeführt, angepasst oder wieder abgeschafft wird. - Ergebnis des Review am 11.08.2011 führt zur Weiterführung des Verfahrens. Anpassung ergaben sich hinsichtlich des Workflows und der Releaseplanung.
Jahreskalender der Produktivsetzungen der Releases
...
Monat/
Release
...
Jan
...
Feb
...
Mrz
...
Apr
...
Mai
...
Jun
...
Jul
...
Aug
...
Sep
...
Okt
...
Nov
...
Dez
...
CBS
...
x
...
x
...
x
...
x
...
x
...
x
...
x
...
...
x
...
x
...
x
...
x
...
Importformate
...
...
x
...
...
x
...
...
x
...
...
...
...
x
...
...
x
...
Exportformat MARC21
...
...
x
...
...
x
...
...
...
...
x
...
...
x
...
...
Exportformat MAB
...
...
...
x
...
...
...
...
...
...
x
...
...
Überblick
Inhalte