Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Inhalt:

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
  • der Aufwand für ChangeRequests, die als Jira-Tickets gemeldet werden, soll durch Bündelung der Anforderungen reduziert werden
  • die MitarbeiterInnen der IT sollen sich stärker auf zeitkritische (Projekt-)Aufgaben konzentrieren können
  • die Information der Fachabteilungen über die Anforderungsplanung soll transparenter und zuverlässiger werden
  • die Bearbeitung von Anforderungen, die als Jira-Tickets gemeldet wurden, soll kontrollierter und zeitnaher erfolgen
  • auch innerhalb der IT soll eine klare Regelung helfen Transparenz und Zuverlässigkeit zu erzeugen
Abgrenzungen

Folgende Anforderungen, Meldungen werden nicht in diesem Verfahren behandelt:

  • akute Fehler, die zu einer Störung in ILTIS führen, werden sofort 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 eines neuen Verfahrens, Geschäftgangs, etc. ergeben, werden nach wie vor zeitnah bearbeitet

Seitenanfang

Hinweise zur Realisierung
  • Je nach Art der Anforderung (siehe Tabelle) werden bestimmte Stichtage festgelegt,
    - zu denen die Anforderung in IT eingegangen sein muss
    - zu denen die Realisierung der Anforderung nach erfolgreichem Test produktiv gesetzt wird.

  • Anforderungen, die für einen bestimmten Termin produktiv gesetzt werden sollen, müssen zum Stichtag des Anforderungseingangs in IT als Jira-Ticket vorliegen. Das bedeutet jedoch nicht, dass ab sofort alle Anforderungen erst zum Stichtag an die IT schicken werden sollen. Diese sollten weiterhin auch vor dem Stichtag in der IT vorliegen.

  • Es gilt weiterhin die generelle Regel, dass die Anforderungen nach Eingang bearbeitet werden. Die Anforderungen werden von IT in Jira der entsprechenden Release-Version zugeordnet.

  • Anforderungen werden in IT analysiert, bevor sie zur weiteren Bearbeitung freigegeben werden. Aufgrund dieser Analyse kann es zu einer Verschiebung bei der Realisierung kommen. Je exakter und vollständiger eine Anforderung gestellt wird (Detailangaben, Beispiele, Kommandos) desto schneller kann die Bearbeitung durch die IT erfolgen!

  • Sollte eine Realisierung aller von den Fachabteilungen übermittelten Anforderungen aufgrund der Anzahl der Anforderungen nicht möglich sein, so behält sich die IT vor, die Bearbeitung einzelner Anforderungen zu verschieben.

  • Eine Verschiebung aufgrund von Ressourcenengpässen in der IT, die sich geplant (hoch priorisierte Projekte, Dienstreisen, Urlaub, etc.) und ungeplant (Krankheit) ergeben können, ist - wie bisher - möglich.

Seitenanfang

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.
(1 Woche Bewertung durch IT1 und 2 Wochen Realisierung durch IT4 und Tests)
Anzahl pro Jahr 11
Frequenz: monatlich
Ausnahme: August aufgrund Sommerurlauben

bis 10. jeden Monats

am 1. jeden Monats

CBS-Konfigurations-Release 09.11  

Importformate-Release MM.JJ
Anpassungen der Importkonversionen
(MARC21, ONIX, XMetaDiss, Formulardaten)
Die Bearbeitungszeit nach Eingang der Anforderung beträgt 1,5 Monate.
(2 Wochen Bewertung durch IT1 und 4 Wochen Realisierung durch IT4 und Tests)
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.

Importformate-Release 09.11

Exportformate-Release MM.JJ
Anpassungen der Exportkonversionen (MARC21, MAB)
Die Bearbeitungszeit nach Eingang der Anforderung beträgt 2 Monate.
(2 Wochen Bewertung durch IT1 und 6 Wochen Realisierung durch IT4 und Tests)
Anzahl pro Jahr: 4
Frequenz: pro Quartal, ungerade Monate
MAB-Anforderungen sind nur in den Releases
März und September enthalten!

bis 01.01. ->
bis 01.03. ->
bis 01.07. ->
bis 01.09. ->

am 01.03.
am 01.05.
am 01.09.
am 01.11.



Exportformate-Release 07.11

Seitenanfang

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

 

 

 

Seitenanfang

Beispiele für das Zusammenspiel von Anforderungseingang und Produktivsetzung:

  1. Eine Anforderung an die Validation im Katalogsystem muss bis zum 10.03. in IT vorliegen, damit sie am 01.04. produktiv gesetzt werden kann.
  2. Eine Anforderung an den Import von MARC21 muss bis zum 01.03. in IT vorliegen, damit sie am 01.05. produktiv gesetzt werden kann.

Seitenanfang

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
    Ab Juli 2011 wird ein Review dieses Verfahrens erfolgen, bei dem entschieden wird, ob es weitergeführt, angepasst oder wieder abgeschafft wird.

Seitenanfang

Workflow des ILTIS-Change-Managements
  • Eine neue Anforderung der FA wird als Jira-Task erfasst. Dies kann durch einen autorisierten Mitarbeiter der FA, den IT-Service oder einen IT-Mitarbeiter erfolgen. FA sind alle Abteilungen in DNB (z.B. Formalerschließung, Erwerbung, Inhaltserschließung, Integrierte Zeitschriftenbearbeitung, DMA, DBSM, ...) und die autorisierten KollegInnen der ZDB (z.B. Jacobi, Rolschewski, Czwinkalik, Heise, ...). Die DNB-Anforderungen werden im Jira-Projekt ILTIS erfasst. Die Anforderungen der ZDB im Jira-Projekt ZDB-ANFORDERUNGEN. In beiden Jira-Projekten werden die gleichen Releaseversionen eingerichtet.

  • Die Leiter der Jira-Projekte ILTIS (Althaus) und ZDB-ANFORDERUNGEN (Diebel) prüfen die eingegangenen Anforderungen, legen - abhängig vom Eingangsdatum der Anforderung - eine vorläufige Releaseversion in Jira fest und leiten die Anforderungen zur Bearbeitung innerhalb IT weiter.

  • Die Bearbeitung der Anforderungen innerhalb IT beginnt mit dem Stichtag für den Anforderungseingang. Zu diesem Zeitpunkt sollte die Prüfung durch IT 1 erfolgt sein. Es müssen zeitnah durchzuführende Tests der Umsetzung durch die FA und IT 1 eingeplant werden. Urlaubszeiten sind zu berücksichtigen! Anpassungen, die die CBS-Validation oder die Exportformate betreffen, sollten durch die IT mit Hilfe von Standardtests geprüft werden.

  • Sobald die Umsetzung durch die FA oder IT 1 erfolgreich abgenommen wurde, setzt IT 1 den Jira-Vorgang auf "erledigt".

  • Nachdem der Stichtag für den Eingang der Anforderungen abgelaufen ist, wird der tatsächliche Termin der Veröffentlichung im Rahmen einer gemeinsamen Besprechung aller Beteiligten in der IT festgelegt.

  • IT 4 stellt sicher, dass die relevanten Steuerungen zum Stichtag der Produktivsetzung vorliegen und dokumentiert dies im Jira-Vorgang.

  • IT 1 informiert per ILTIS-Info über den bevorstehenden Release und stellt aktualisierte Dokumentationen zur Verfügung (z.B. Feldverzeichnisse).
    Die ILTIS-Kontaktpersonen werden per Mail über den bevorstehenden Release informiert. Dies ist die letzte Möglichkeit der FA ggf. eine Anforderungen zurückzuziehen!

  • IT 2 übernimmt die relevanten Steuerungen am Stichtag (inkl. Versionsverwaltung) und startet die entsprechenden Server neu.

  • IT 1 schliesst alle Jira-Vorgänge, die dem veröffentlichten Release zugeordnet sind

    Seitenanfang
  • No labels