Versionen im Vergleich

Alte Version 2

changes.mady.by.user Althaus, Bernd

Gespeichert am

verglichen mit

Neue Version 129

changes.mady.by.user Althaus, Bernd

Gespeichert am

Schlüssel

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

Anker
begin
begin

Inhalt
typeflat

Beginn des Verfahrens

01. März 2011

1. Releaseplanungen
Import-/Export-Release

Auszug einschließen
Import/Export-Release
Import/Export-Release

Schnittstellen-Release

Auszug einschließen
Schnittstellen-Release
Schnittstellen-Release

CBS-Release

Auszug einschließen
CBS-Release
CBS-Release

2. Releasebeschreibung

Name

Beschreibung

Workflow-Besonderheiten

Frequenz

IT-Zuständigkeit 

CBS-Release

(CBS=Central Bibliographic System)

enthalten sind CBS-Anpassungen
für

  • die Validation,
  • die Indexierung,
  • die Expansion,
  • die Präsentation und
  • die Syntax.

Eine Prüfung der Anforderungen (durch die Fachabteilungen oder IT)
ist i.d.R. vor Ablauf der Anforderungsfrist nicht vorgesehen.
Nach Ablauf der Anforderungsfrist haben die Fachabteilungen
eine Woche Zeit die Anforderungen zu prüfen.
Erst im Anschluß beginnt die Umsetzung der Anforderung in der IT.

(siehe Workflow des CBS-Release)

ca. alle zwei Monate

Hr. Grund 

Import/Export-Release

enthalten sind Anforderungen an die
Exportformate MARC 21 und Linked Data,
sowie an die
Importformate ONIX, xMetaDissPlus, MARC 21

Die Anforderungen und Vorgaben sollten zur Anforderungsfrist
sowohl mit den Fachabteilungen als auch innerhalb der IT abgestimmt sein,
damit nach der Anforderungsfrist sofort mit der Umsetzung begonnen werden kann.
Workflow-Diagramm der Import/Export-Releases 

alle vier Monate /
Mitte des Monats

Hr. Althaus 
Schnittstellen-Release

enthält Anforderungen an die
Schnittstellen:

  • OAI
  • SRU/Retrieval
  • Z39.50
  • ONS/Z39.50
  • ONS/SRU
  • IN2N / SCUSI-Schnittstelle
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

 Seitenanfang

3. Zielsetzungen des Change Management

 

  • Aufwandsminimierung
    der Aufwand für Change-Requests, 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, die zu einer Störung in ILTIS führen, werden 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)
     
  • Anforderungen, die sich im Rahmen eines Projektes zur Einführung eines neuen Verfahrens, Geschäftgangs, etc. ergeben,
    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.

Seitenanfang 

Informationen zum ILTIS-Change-Management

Ab 1. März 2011 wird im ILTIS-Katalogsystem ein neues Verfahren für die Planung, Bearbeitung und Durchführung von Anforderungen an das ILTIS-Katalogsystem eingeführt.

Zielsetzungen
  • der Aufwandes 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 Fehlermeldungen, die zu einer Störung in ILTIS führen, werden sofort bearbeitet
  • Anforderungen, die sich aufgrund Einführung und Test eines neuen Verfahrens, Geschäftgangs, etc. ergeben, werden nach wie vor zeitnah bearbeitet
Hinweise zur Realisierung

...

Arbeitsbereich

Anforderungseingang
Frequenz, Stichtag, Beginn

Produktivsetzung
Frequenz, Stichtag, Beginn

Name der Releaseversion in Jira

Anpassungen des Datenformates, der Validation, der Expansion und der Indexierung

monatlich zum 15.
(also ca. 2 Wochen vor der Produktivsetzung)
1. Stichtag: 15.03.2011

monatlich am 1.
(also ca. 2 Wochen nach dem Anforderungseingang)
1. Stichtag: 01.04.2011

CBS-Konfigurations-Release MM/JJ
z.B. CBS-Konfigurations-Release 04/11 
(ACHTUNG: DNB-interner Link!)

Anpassungen der Importkonversionen (MARC21, ONIX, XMetaDiss, Formulardaten)

jeden 2. Monat zum 15.
(also ca. 2 Wochen vor der Produktivsetzung)
1. Stichtag: 15.04.2011

jeden 2. Monat am 1.
(also ca. 2 Wochen nach dem Anforderungseingang)
1. Stichtag: 01.05.2011

Importformate-Release MM/JJ,
z.B.
Importformate-Release 05/11
(ACHTUNG: DNB-interner Link!)

Anpassungen der Exportkonversionen (MARC21, MAB)

MAB: halbjährlich (1.12./1.6.)
MARC21: vierteljährlich (1.12/1.3./1.6./1.10.)
(also jeweils ca. 4 Wochen vor der Produktivsetzung)

MAB: halbjährlich (1.1./1.7.)
MARC21: vierteljährlich (1.1/1.4./1.7./1.11.)
(also jeweils ca. 4 Wochen nach dem Anforderungseingang)

Exportformate-Release MM/JJ

Beispiele für das Zusammenspiel von Anforderungseingang und Produktivsetzung:

  1. Eine Anforderung an die Validation im Katalogsystem muss bis zum 15.03.2011 in IT vorliegen, damit sie am 01.04.2011 produktiv gesetzt werden kann.
  2. Eine Anforderung an den Import von MARC21 muss bis zum 15.04.2011 in IT vorliegen, damit sie am 01.05.2011 produktiv gesetzt werden kann.
Zeitplanung

...