Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

  • 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 Art des Releases

Eingang der
Anforderung bis

Veröffentlichung

Produktiv Release-Name
setzung

Interner Jira-Link
zu einem Beispiel-Release

CBS-Release MM.JJJJ
Anpassungen des Datenformates,
Anpassungen der Validation,
Anpassungen der Expansion und ,
Anpassungen der Indexierung
Die Bearbeitungszeit nach Eingang der Anforderung beträgt ca. 3 Wochen.
(1 Woche Bewertung durch IT1 und die Fachabteilungen,
 2 Wochen Realisierung durch IT4 und Tests)
Anzahl pro Jahr 11
Frequenz: monatlich
Ausnahme: August aufgrund Sommerurlauben
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 bis 10. jeden Monats
am 1. jeden Monats

CBS-Release 09.11  

Import-Release MM.JJJJ
Anpassungen der Importkonversionen
(MARC21, ONIX, XMetaDiss, Formulardaten)
Die Bearbeitungszeit nach Eingang der Anforderung beträgt : 1,5 Monate.
( 2 Wochen Bewertung durch IT1 und FA,
4 Wochen Realisierung durch IT4 und Tests)
Anzahl pro Jahr: 5
Frequenz: alle 2 Monate, gerade Monate,
Ausnahme: August aufgrund Sommerurlauben

bis 1505.12.2011 ->
bis 1517.02. ->
bis 1520.04. ->
bis 1517.08. ->
bis 1519.10. ->

am 01.02.
am 0102.04.
am 0111.06.
am 01.10.
am 01.12.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)
Die Bearbeitungszeit nach Eingang der Anforderung beträgt Bearbeitungszeit:  2 Monate.
( 2 Wochen Bewertung durch IT1 und FA,
6 Wochen Realisierung durch IT4 und Tests)
Anzahl pro Jahr: 4
Frequenz: pro Quartal, ungerade Monate
MAB-Anforderungen sind - wenn überhaupt -
nur in den Releases
März und September enthalten!

bis 0113.01. ->
bis 0116.03. ->
bis 0129.0706. ->
bis 0114.09. ->

am 0112.03.
am 0114.05.
am 0117.09.
am 01.11.05.11.


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


Export-Release 07.11

Seitenanfang

Jahreskalender der Produktivsetzungen der Releases2012

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:

...