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 25 Next »

Fortlaufende Zeitplanung
  • Beginn des Verfahrens ab 01.03.2011
  • Review des Verfahrens am 11.08.2011 (Teilnehmer: Althaus, Becker, Czech, Diebel, Hernandez, Jochum, König, Molitor, Polak, Wiegand)
  • Review des Verfahrens am 27.10.2011 mit den Fachabteilungen
  • Aktualisierung und Kommentierung anhand des Reviews vom 27.10.2011
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 von IT einem Release zugeordnet. Die Anforderungen im Rahmen eines CBS-Releases werden den FA mittels einer Releaseankündigung mitgeteilt. Die FA haben eine Woche Zeit auf die geplanten Anpassungen zu reagieren. Kommentare in den einzelnen Jira-Vorgängen sollten möglichst nur dann erfasst werden, wenn es Rückfragen gibt. Die Zustimmung zu Änderungen sollte formlos an den Mailverteiler der VL-ILTIS-Kerngruppe gehen.

  • 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.
  • Jira-Vorgänge, deren Umsetzung nicht im Rahmen eines CBS-Releases erfolgen, werden von IT als "geschlossen" gekennzeichnet, wenn die Realisierung erfolgt ist. Nur wenn ein Feedback der FA erwartet wird, so wird ein Jira-Vorgang nur auf "erledigt" gesetzt.
  • Für das Projekt ILTIS wird die Komponente Datenmanipulation verwendet, um geplante Manipulationen von Daten im CBS zuzuordnen (Entfernen, Korrigieren, Verschieben von Feldern). Diese Datenmanipulationen sind in der Releaseankündigung für CBS-Releases enthalten. Analog zu den Releases haben auch hier die Fachabteilungen eine Woche Zeit, um eine geplante Datenmanipulation zu stoppen. Die Datenmanipulationen werden dann nach der Veröffentlichung des Releases eingeplant und umgesetzt.

Seitenanfang

Releaseplanung 2012

Eingang der
Anforderung bis

Veröffentlichung

Release-Name

Interner Jira-Link
zu einem Beispiel-Release

CBS-Release
Anpassungen des Datenformates,
Anpassungen der Validation,
Anpassungen der Expansion,
Anpassungen der Indexierung
Datenmanipulationen
Hinweise: keine Releases im ... aufgrund ...
... Januar ... Jahreswechsel und Weihnachtsferien
... April ... GND-Einführung, Bibliothekartag und Osterferien
... August/September ... aufgrund Sommerferien
... November ... Herbstferien


bis 10.01. ->
bis 10.02. ->
bis 13.04. ->
bis 11.05. ->
bis 08.08. ->
bis 31.08. ->
bis 31.10. ->

am 01.02.
am 01.03.
am 07.05.
am 01.06.
am 02.07.
am 01.10.
am 03.12.

CBS-Release 02.2012
CBS-Release 03.2012
CBS-Release 05.2012
CBS-Release 06.2012
CBS-Release 07.2012
CBS-Release 10.2012
CBS-Release 12.2012

CBS-Release 09.11  

Import-Release
Anpassungen der Importkonversionen
(MARC21, ONIX, XMetaDiss, Formulardaten)
Bearbeitungszeit: 1,5 Monate.
2 Wochen Bewertung durch IT1 und FA,
4 Wochen Realisierung durch IT4 und Tests)

bis 05.12.2011 ->
bis 17.02. ->
bis 20.04. ->
bis 17.08. ->
bis 19.10. ->

am 01.02.
am 02.04.
am 11.06.
am 01.10.
am 03.12.

Import-Release 02.2012
Import-Release 04.2012
Import-Release 06.2012
Import-Release 10.2012
Import-Release 12.2012

Import-Release 09.11

Export-Release MM.JJ
Anpassungen der Exportkonversionen (MARC21, MAB)
Bearbeitungszeit:  2 Monate.
2 Wochen Bewertung durch IT1 und FA,
6 Wochen Realisierung durch IT4 und Tests)
MAB-Anforderungen sind - wenn überhaupt -
nur in den Releases März und September enthalten!

bis 13.01. ->
bis 16.03. ->
bis 29.06. ->
bis 14.09. ->

am 12.03.
am 14.05.
am 17.09.
am 05.11.


Export-Release 03.2012
Export-Release 05.2012
Export-Release 09.2012
Export-Release 11.2012


Export-Release 07.11

Seitenanfang

Jahreskalender 2012

Monat/
Release

Jan

Feb

Mrz

Apr

Mai

Jun

Jul

Aug

Sep

Okt

Nov

Dez

CBS


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

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 schicken - wenn es sich um Anforderungen im Rahmen von CBS-Releases handelt - eine Releaseankündigung an die ILTIS-Kontaktpersonen. Die FA haben danach eine Woche Zeit, die für ein CBS-Release vorgesehenen Jira-Vorgänge zu prüfen. Die Diskussion zu den Jira-Vorgängen wird mit Hilfe der Verteilerliste VL-Iltis-Kerngruppe geführt. In den einzelnen Jira-Vorgängen wird nur dann ein Kommentar erfasst, wenn eine Anforderung zurückgezogen wird.
  • Nach der erfolgten Abstimmung der FA wird das CBS-Release in der IT verbindlich eingeplant. Dazu treffen sich die Beteiligten IT-KollegInnen zu Beginn der Bearbeitung und kurz vor Veröffentlichung des CBS-Releases. Bei der Planung sind Tests der Umsetzung durch die FA und IT, sowie Urlaubszeiten 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".

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

  • IT 1 stellt - spätestens am Tag der Veröffentlichung des Releases - aktualisierte Dokumentationen zur Verfügung (z.B. Feldverzeichnisse). Der Umfang eines CBS-Releases ist in Jira auch nach der Veröffentlichung zu ersehen. Es wird kein ILTIS-Info zu den einzelnen Releases erstellt.

  • 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