Feld - Asysnet
Werbung
Festlegungen zur Bearbeitung von Störungs- oder Mangelmeldungen, Change- oder Dienstleistungsvorschlägen und Supportanfragen an die ZKS-Abfall im Meldungssystem JIRA erstellt von der InformationsKoordinierenden Stelle Abfall DV-Systeme - IKA Stand: 27.10.2016 / Dokumentenname: Dokumentation_ZKS-JIRA_V06.doc ZKS-JIRA Inhaltverzeichnis 1. Allgemeines.................................................................................................................... 4 2. JIRA-Meldungssystem ................................................................................................... 5 3. 2.1. Aufgabe................................................................................................................... 5 2.2. Zugang .................................................................................................................... 5 2.3. Rechte..................................................................................................................... 5 2.4. Benachrichtigungen................................................................................................. 6 2.5. Auswertungen ......................................................................................................... 6 2.6. Betrieb, Konfiguration und Benutzereinstellungen ................................................... 7 Bearbeitung von Meldungen........................................................................................... 8 3.1. Vorgangstypen ........................................................................................................ 8 3.2. Erstellen von Meldungen ......................................................................................... 9 3.3. Bearbeitung von Meldungen durch die IKA ............................................................10 3.3.1. Entgegennahme der Meldung ("Sichtung") ......................................................10 3.3.2. Dringlichkeit und Priorität einer Meldung .........................................................10 3.3.3. Bearbeitung von Störungsmeldungen .............................................................11 3.3.4. Bearbeitung von Meldungen zu Betriebsänderung ..........................................11 3.3.5. Bearbeitung von Meldungen zu Programmfehlern...........................................12 3.3.6. Bearbeitung von Optimierungen ......................................................................12 3.3.7. Bearbeitung von Supportanfragen ...................................................................13 3.3.8. Kategorie einer Meldung .................................................................................13 3.3.9. Schließen von Meldungen ...............................................................................14 3.3.10. 3.4. Information bei Meldungen von besonderem allgemeinem Interesse ...........15 Bearbeitung von Meldungen durch KDO ................................................................15 3.4.1. Vertragliche Grundlagen .................................................................................15 3.4.2. Behebung von Betriebsstörungen ...................................................................15 3.4.3. Umsetzung von Betriebsänderungen ..............................................................16 3.5. Bearbeitung von Meldungen durch IBM..................................................................17 3.5.1. Vertragliche Grundlagen .................................................................................17 3.5.2. Behebung von Programmfehlern .....................................................................17 3.5.3. Umsetzung von Optimierungen .......................................................................18 3.6. Abbildung des Bearbeitungsablaufes im JIRA-Meldungssystem ............................18 3.6.1. Arbeitsablauf Betriebsstörungen und Betriebsänderungen ..............................19 3.6.2. Arbeitsablauf Programmfehler und Optimierung ..............................................19 3.6.3. Arbeitsablauf Support ......................................................................................20 3.6.4. Angabe Status.................................................................................................20 3.6.5. Angabe Bearbeitungsstatus ............................................................................21 -2- ZKS-JIRA 3.7. Erläuterung zu weiteren Angaben im JIRA-Meldungssystem .................................22 3.7.1. Zusammenfassung, Nummer ..........................................................................22 3.7.2. Beschreibung des Problems und seiner Lösung..............................................22 3.8. Aktualisierung der Angaben im ZKS-JIRA-Meldungssystem ..................................22 -3- ZKS-JIRA 1. Allgemeines Im Rahmen der laufenden Betreuung des DV-Systems ZKS-Abfall nimmt die IKA Störungsund Fehlermeldungen, Änderungsvorschläge und Supportanfragen von den Nutzern der ZKS-Abfall entgegen und bearbeitet diese. An der Behebung von Störungen und Programmfehlern sowie der Umsetzung von Betriebsänderungen und Optimierungen sind dabei regelmäßig - der Zweckverband Kommunale Datenverarbeitung Oldenburg (KDO) im Rahmen des Betriebs der ZKS-Abfall in ihrem Rechenzentrum - und die IBM im Rahmen der Pflege und Weiterentwicklung der Software der ZKSAbfall beteiligt. Sowohl der Service-Vertrag zum Betrieb der ZKS-Abfall1 mit dem Vertragspartner KDO und die zugehörige Leistungsbeschreibung2 als auch der Pflege- und Wartungsvertrag3 für die Software der ZKS-Abfall mit dem Vertragspartner IBM sehen vor, dass zur Kommunikation im Rahmen der Meldungen ein durch die IKA bereitzustellendes zentrales Meldungssystem genutzt wird. Das vorliegende Dokument beschreibt das Vorgehen bei der Bearbeitung von Meldungen mit Hilfe des JIRA-Meldungssystems und konkretisiert die entsprechenden Festlegungen der beiden Verträge im Sinne von Ausführungsbestimmungen. Im Folgenden kurz KDO-Service-Vertrag; vollständige Bezeichnung Service-Vertrag Version 4, vom 28.11.2013, "Rechenzentrumsdienstleistungen zum Betrieb der Software des DV-Anwendungssystems Zentrale Koordinierungsstelle Abfall ZKS-Abfall", TED-Publikation: 3037893-2012-DE. 2 Im Folgenden kurz KDO-Leistungsbeschreibung; vollständige Bezeichnung Leistungsbeschreibung Version 3 - BAFO, vom 29.07.2013, "Rechenzentrumsdienstleistungen zum Betrieb der Software des Projektes Zentrale Koordinierungsstelle Abfall ZKS-Abfall", TED-Publikation: 3037893-2012-DE. 3 Im Folgenden kurz: „IBM-Pflegevertrag; vollständige Bezeichnung: Vertrag über die Pflege und Wartung der AnwendungsSoftware Zentrale Koordinierungsstelle Abfall (ZKS-Abfall), Fassung vom 28.11.2013 und die dazu gehörenden Dokumente. 1 -4- ZKS-JIRA 2. JIRA-Meldungssystem 2.1. Aufgabe Zur Unterstützung der Bearbeitung der Meldungen und zur Dokumentation des Bearbeitungsablaufs dient bei allen Meldungen das JIRA-Meldungssystem. 2.2. Zugang Das JIRA-Meldungssystem besitzt eine browser-basierte Benutzeroberfläche und kann somit ohne Installation besonderer Software benutzt werden. Zur Nutzung wird der Einsatz des Browsers "Firefox" der Firma Mozilla empfohlen. Das JIRA-Meldungssystem ist unter www.gadsys-softwarepflege.de erreichbar. Die Anzeige der Seiten erfolgt SSL verschlüsselt über das Protokoll https. Zur Nutzung ist eine vorherige Authentifizierung erforderlich. Schreibenden Zugang zum JIRA-Meldungssystem haben - die Knotenstellen der Länder in Person der ASYS-Fachbetreuer und -Administratoren - die IKA in Person der mit der Bearbeitung der Meldungen betrauten Mitarbeiter (insbesondere der Mitarbeiter des SHD der IKA) - die KDO in Person der von KDO benannten, mit der Pflege des ZKS-Systems betrauten Personen - die IBM in Person der von IBM benannten, mit der Pflege des Software ZKS-Abfall betrauten Personen Für jede Person mit schreibendem Zugang zum JIRA-Meldungssystem ist in JIRA ein individuelles Benutzerkonto eingerichtet (vgl. Abschnitt 2.6). 2.3. Rechte Jeder Benutzer des JIRA-Meldungssystem besitzt folgende Rechte: - Alle im JIRA-Meldungssystem erfassten Meldungen sind für alle Benutzer einsehbar (inkl. der diesen Meldungen angefügten Dateianhänge). - Jeder Benutzer kann sich zum sogenannten Beobachter einer Meldung erklären und die Beobachtung einer Meldung beenden. Die Knotenstellen der Länder besitzen zudem die folgenden zusätzlichen Rechte - Meldungen zu erstellen - eigenen und fremden Meldungen Kommentare oder Dateianhänge hinzuzufügen Die Knotenstellen können die Angaben -auch zu den von ihnen selbst erstellten Meldungennach der Erstellung nicht mehr bearbeiten. Möchten sie ihrer Meldung nach deren Erstellung weitere Informationen hinzufügen, ist dies durch das Hinzufügen von Kommentaren und Dateianhängen möglich. IKA, KDO und IBM besitzen über die Rechte der Knotenstellen hinaus die folgenden zusätzlichen Rechte: - die Angaben zu allen Meldungen zu bearbeiten - Meldungen entsprechend inhaltlicher, fachlicher oder ihre Bearbeitung betreffende Zusammenhänge untereinander zu verknüpfen -5- ZKS-JIRA - den Status der Meldung entsprechend vorkonfigurierten Arbeitsablaufes entsprechend der jeweiligen individuellen Rechte zu verändern (genaueres s. Abschnitt 3.5) - beliebigen Meldungen beliebige JIRA-Benutzer als Beobachter hinzufügen und die Beobachtung einer Meldung durch einen Benutzer zu beenden - Meldungen bestimmten JIRA-Benutzern als sogenanntem Bearbeiter zur Bearbeitung zuzuweisen - Meldungen als Bearbeiter zugewiesen zu bekommen Nur die IKA besitzt darüber hinaus die Rechte: - den Vorgangstyp (vgl. Abschnitt 3.1) einer Meldung zu verändern - Meldungen, Kommentare und Dateianhänge zu löschen - Meldungen in anderen DV-Systemen Meldungssystems zu verschieben 2.4. zugeordnete Bereiche des JIRA- Benachrichtigungen Mit Hilfe des JIRA-Meldungssystems kann der Zugang zu aktuellen und umfassenden Informationen zum Stand der Bearbeitung der Meldungen für alle Beteiligten sichergestellt werden. Das JIRA-Meldungssystem besitzt zudem spezielle Funktionalitäten, um die Beteiligten automatisiert über Änderungen bezüglich einzelner Meldungen zu informieren. Im Rahmen der Bearbeitung der Meldungen soll daher auf eine Information und Kommunikation der Beteiligten auf anderen Wegen (insbesondere auf eine Kommunikation per E-Mail) verzichtet werden. Die automatisierte Benachrichtigung der Beteiligten über Änderungen bezüglich der Meldungen durch das JIRA-Meldungssystem erfolgt über eine Mail, die u.a. einen Link zum Öffnen der jeweiligen Meldung und eine Übersicht über die erfolgten Änderungen enthält. Über Änderungen werden jeweils der Melder und alle Beobachter der Meldung informiert. Als Änderungen sind zu verstehen: - Erstellen der Meldung - Änderung der Angaben zu einer Meldung - Hinzufügen oder Ändern eines Dateianhangs bzw. eines Kommentars - Verknüpfen mit einer anderen Meldung - Schließen einer Meldung Der Bearbeiter einer Meldung erhält eine E-Mail-Benachrichtigung, - 2.5. wenn ihm die Meldung als sogenanntem Bearbeiter zu Bearbeitung zugewiesen wird Auswertungen Das JIRA-Meldungssystem bietet umfangreiche Funktionalitäten, um die Meldungen nach bestimmten Kriterien auszuwerten. Wiederkehrende Auswertungen können in Form von sogenannten "Filtern" gespeichert werden. Entsprechende Filter können zur Nutzung durch andere Benutzer freigegeben werden. Die IKA erstellt Filter zu Auswertungen von allgemeinem Interesse und gibt diese für alle Benutzer frei. Die Erstellung der Filter erfolgt dabei als unpersönlicher Benutzer "ZKS- -6- ZKS-JIRA Bearbeiter IKA". Die aktuell zur Verfügung stehenden Filter können durch alle Benutzer über eine Suche nach Filtern ermittelt werden. Die auf der individuellen Startseite des jeweiligen JIRA-Benutzers (dem sogenannten "Dashboard") dargestellten Inhalte (wie z.B. Listen von Meldungen, die bestimmten Filter genügen, und andere Auswertungen) können durch den JIRA-Benutzer individuell konfiguriert werden. 2.6. Betrieb, Konfiguration und Benutzereinstellungen Der technische Betrieb und die Konfiguration des JIRA-Meldungssystems sowie die Einrichtung von Benutzern erfolgt durch die IKA. Die Benutzer können nach Anmeldung am System bestimmte Benutzereinstellungen vornehmen. Insbesondere können sie die bei Versand von Benachrichtigungen an sie genutzte E-Mail-Adresse und ihr Passwort verändern. -7- ZKS-JIRA 3. Bearbeitung von Meldungen 3.1. Vorgangstypen Jede Meldung zum DV-System ZKS-Abfall kann einem der folgenden fünf Vorgangstypen zugeordnet werden: - Betriebsstörung4 Eine Störung liegt vor, wenn die ZKS-Abfall nicht oder nur mit Einschränkungen genutzt werden kann. Ausgenommen davon sind Einschränkungen aufgrund von vorher abgestimmten Wartungsarbeiten. Beispiele von Störungen sind: - o Aus dem LeANV ist kein Versand von Dokumenten möglich. o Bei der Kommunikation zwischen einem eANV-System und der VPS treten Probleme auf. o Bei der Verarbeitung von Nachrichten durch das Servicemodul treten Verzögerungen auf. Betriebsänderung5 Änderungen des Betriebs sind alle Änderungen der IT-Umgebung der ZKS-Abfall, unabhängig davon, ob diese die Soft- oder die Hardware betreffen. Für alle Änderungen an der Software ZKS-Abfall werden immer Meldungen erstellt. Für Änderungen an anderer für den Betrieb notwendigen Software sowie bezüglich der Hardware werden nur dann Meldungen erstellt, wenn die Änderung die Software ZKS-Abfall beeinflussen könnte.6 Beispiele von Betriebsänderungen sind: - o Eine neue Version der Software ZKS-Abfall wird bereitgestellt und installiert. o Eine Konfigurationsänderung innerhalb der Software ZKS-Abfall wird vorgenommen. o Ein bestimmter Knoten der ZKS-Abfall wird heruntergefahren oder gestartet. o Eine neue Version einer anderen für den Betrieb notwendigen Software wird installiert. o Hardware wird ersetzt. Programmfehler7 Programmfehler sind alle Abweichungen vom vereinbarten Softwareverhalten der Software ZKS-Abfall. Auch ein offensichtlich nicht korrektes oder nicht sinnvolles Softwareverhalten stellt in diesem Sinne keinen Programmfehler dar, wenn es ausdrücklich vereinbart worden ist. Beispiele für Programmfehler sind: vgl. KDO-Leistungsbeschreibung Abschnitt 3.7.1 Tabelle 12 (Dort wird der Begriff „Störung“ genutzt.) vgl. KDO-Leistungsbeschreibung, Abschnitt 3.8. 6 vgl. KDO-Leistungsbeschreibung Abschnitt 3.8 und 3.9. Die Anforderung an die KDO zur Dokumentation ist durch die KDO zusätzlich unabhängig vom JIRA-Meldungssystem zu erfüllen. 7 vgl. - soweit der Programmfehler innerhalb der Software ZKS-Abfall auftritt – IBM-Pflegevertrag Abschnitt 6. 4 5 -8- ZKS-JIRA - o Der Inhalt eines BMU-Dokumentes wird im LeANV nicht korrekt angezeigt. o Eine im Service-Modul-Postfach eingegangene, für eine Behörde bestimmte Nachricht wird nicht in das gemäß der Weiterleitungsregel korrekte Knotenstellenpostfach weitgeleitet. Optimierung8 Hierzu gehören alle Anpassungen der Software ZKS-Abfall oder anderer zum Betrieb der ZKS-Abfall notwendigen Software an geänderte oder neue Anforderungen (z.B. aufgrund rechtlicher Änderungen, dem Wunsch nach Berücksichtigung neuer Inhalte oder der Umsetzung eines geänderten oder erweiterten Funktionsumfangs), die Anpassung an geänderte oder neue Einsatzumgebungen sowie die Anpassung an geänderte technische Normen und Schnittstellen sowie geänderte rechtliche Festlegungen. Beispiele von Optimierungen sind: - o Das LeANV wird um eine bestimmte Funktionalität erweitert. o Das Gesamtsystem wird an eine neue Version der BMU-Schnittstelle angepasst. Support Unter Support ist die Analyse und Beseitigung auftretender Probleme bei Nutzung und Betrieb der ZKS-Abfall zu verstehen, die nicht durch Störungen oder Programmfehler verursacht werden. Als Support sind auch die Unterstützung bei sowie die Beantwortung von Verständnisfragen zur Bedienung des Programms und zu anderen Fragen im Zusammenhang mit der Nutzung und Betrieb der ZKS-Abfall zu verstehen. Beispiele von Supports sind: 3.2. o Ein Anwender des LeANVs lässt sich in die Bedienung der Anwendung einweisen. o Ein ASYS-Fachadministrator oder -Fachbetreuer bittet um Unterstützung bei der Recherche nach einer Nachricht, die den Adressaten nicht erreicht hat. Erstellen von Meldungen Meldungen können von der IKA, der KDO, der IBM und den Knotenstellen der Länder erstellt werden. Zu bei der IKA von anderen (also z.B. von Nutzern des LeANVs, anderen am eANVBeteiligten, Softwareherstellern) eingehenden Hinweisen auf eine Störung, einen Programmfehler oder eine gewünschte Optimierung werden durch die IKA Meldungen erstellt. Zu von anderen eingehenden (Support-)anfragen erstellt die IKA nur dann Meldungen, wenn der Support durch die IKA nicht unmittelbar geleistet werden kann. Dementsprechend werden von der IKA zu telefonisch von Nutzern des LeANVs eingehenden Supportanfragen in der Regel keine Meldungen erstellt. Entsprechend ihrer Aufgaben und gemäß der vertraglichen Regelungen erstellt 8 - die IKA im wesentlichen Meldungen zu Betriebsstörungen, Programmfehlern, Optimierungen und Supports. - die IBM im wesentlichen Meldungen zu Betriebsänderungen und Programmfehlern. - die KDO im wesentlichen Meldungen zu Betriebsstörungen und Betriebsänderungen. vgl. IBM-Pflegevertrag Abschnitt 7. -9- ZKS-JIRA - die Länder im wesentlichen Meldungen zu Betriebsstörungen und Supports. Wesentlicher Bestandteil der Meldung ist in jedem Fall eine möglichst detaillierte Beschreibung (in der Angabe Beschreibung durch Melder). Bei Störungen, Programmfehlern und Supportanfragen sollte aus der Beschreibung auch hervorgehen, in welcher genauen Konstellation und mit welcher Häufigkeit das Problem auftritt und ob es reproduziert werden kann. Das Hinzufügen von geeigneten Anhängen bereits bei der Erstellung der Meldung macht deren nachträgliche Anforderung überflüssig und kann die Bearbeitung der Meldung deutlich beschleunigen: Angehängt werden sollten alle relevanten Dokumenten und Dateien, d.h. BMU-Dokumente, Screenshots, Log-files aller relevanten Systeme oder Konfigurationsdateien etc.9 Sind die Beschreibung des Problems sowie die angefügten Dokumente und Dateien für eine Bearbeitung der Meldung nicht ausreichend, wird die IKA, KDO oder IBM ggf. über eine entsprechend Kommentierung im JIRA-Meldungssystem um die weitere Ergänzung der Beschreibung sowie um das Hinzufügen weiterer Dokumente und Dateien bitten. 3.3. Bearbeitung von Meldungen durch die IKA 3.3.1. Entgegennahme der Meldung ("Sichtung") Erster Schritt der Bearbeitung einer Meldung durch die IKA ist die sogenannte Sichtung der Meldung. Bei der Sichtung werden die Angaben der Meldung kontrolliert und ggf. vervollständigt, die Priorität der Meldung wird festgelegt und die Meldung wird einem Bearbeiter innerhalb der IKA zugewiesen. Ebenfalls während der Sichtung erfolgt eine Prüfung, ob sich eine inhaltsgleiche Meldung bereits in Bearbeitung befindet. Ist dies der Fall, wird die Meldung unmittelbar geschlossen. 3.3.2. Dringlichkeit und Priorität einer Meldung Bei der Erstellung der Meldung gibt der Melder die Dringlichkeit der Bearbeitung der Meldung aus seiner Sicht an. Diese Angabe wird während der Bearbeitung nicht mehr verändert. Folgende Dringlichkeiten sind im JIRA-Meldungssystem vorgesehen: - gering - normal - eilt Während der Sichtung der Meldungen legt die IKA für jede Meldung die Priorität der Bearbeitung fest. Als Prioritätsstufen sind vorgesehen: - nachrangig bearbeiten - baldmöglichst bearbeiten - sofort bearbeiten Die Prioritätensetzung bezüglich der Bearbeitung der Meldungen durch die IKA erfolgt bei Berücksichtigung aller aktuell zu bearbeitenden Meldungen nach folgenden Grundsätzen: 9 Störungen werden vorrangig bearbeitet. vgl. auch Pflege- und Wartungsvertrag, Abschnitt 6.3. - 10 - ZKS-JIRA - Hinweise zu Programmfehlern werden in der Regel vorrangig vor Supportmeldungen und Anfragen bearbeitet. - Supportmeldungen und Anfragen werden in der Regel nachrangig bearbeitet. - Probleme, die nur in Einzelfällen oder nur in speziellen Konstellationen auftreten oder Bereiche und Funktionalitäten betreffen, die nur einer geringeren Nutzungsintensität unterliegen, werden in der Regel nachrangig bearbeitet. - Die vom Melder genannte Dringlichkeit findet Berücksichtigung. Die IKA berücksichtigt zudem die in Abschnitt 3.3.8 genannten, bei der Festlegung der Kategorien zu beachtenden Grundsätze auch bei der Festlegung der Priorität der Bearbeitung der Meldungen. 3.3.3. Bearbeitung von Störungsmeldungen Die IKA ist bei der Bearbeitung von Störungsmeldungen verpflichtet, die Meldungen vor deren Weiterleitung an KDO zunächst auf Berechtigung zu prüfen10. Zur Prüfung gehören die folgenden Teilprüfungen - Prüfung, ob das beschriebene Verhalten durch einen Bestandteil des DV-Systems ZKS-Abfall bei bestimmungsmäßigem Nutzung hervorgerufen wurde. - Prüfung, ob das beschriebene Programmverhalten tatsächlich auftritt. Diese Prüfung erfolgt durch den Versuch der Reproduktion des Fehlers und/oder durch Überprüfung der maßgeblichen Betriebsparameter sowie unter Berücksichtigung ggf. bereits vorliegender anderen Meldungen. Die Prüfung kann entfallen, wenn die Störung durch die KDO gemeldet wurde. Bei Störungsmeldungen prüft die IKA nicht, ob die Störung durch einen Programmfehler innerhalb der Software ZKS-Abfall oder anderer Software verursacht wurde. Nur wenn für die IKA offensichtlich ist, dass die Störung durch einen Programmfehler verursacht wurde und nicht durch ein Problem im Betrieb der ZKS-Abfall, wird die Meldung nicht als zu behebende Betriebsstörung an KDO zugewiesen, sondern durch die IKA als Programmfehler weiterbearbeitet und ggf. der IBM als zu behebender Programmfehler zugewiesen. Ist eine der genannten Bedingungen nicht erfüllt, wird die Meldung nach Information des Melders über das Prüfergebnis entweder mit der Lösung "gegenstandslos" geschlossen oder durch die IKA als Optimierung oder Supportmeldung weiterbearbeitet. Teil der Prüfung einer Störungsmeldung ist die Feststellung des Beginns der Störung. Dieser Zeitpunkt wird in der Angabe Zeitpunkt Störungsbeginn eingetragen. Tritt eine Störung nach ihrer scheinbaren Behebung erneut auf, wird durch die IKA der Beginn der erstmaligen Störung als Zeitpunkt Störungsbeginn eingetragen. Liegt eine Betriebsstörung vor, weist die IKA die Meldung der KDO als zu behebende Betriebsstörung zu. Der Zeitpunkt, bis zu dem die Störung entsprechend der vertraglichen Regelungen zu beheben ist, wird von IKA in der Angabe Zeitpunkt Umsetzung Soll eingetragen. 3.3.4. Bearbeitung von Meldungen zu Betriebsänderung Während der Bearbeitung einer Meldung zu einer Betriebsänderung prüft die IKA, ob der Änderung zugestimmt werden kann. Bei der Prüfung beteiligt die IKA ggf. die IBM11. Ist dies der Fall weist die IKA die Meldung der KDO zur Umsetzung zu. Mit der Zuweisung einer Betriebsänderung an die KDO erteilt die IKA die Freigabe zu ihrer Umsetzung. 10 11 vgl. KDO-Leistungsbeschreibung Abschnitt 3.10 Vgl. IBM-Pflegevertrag Abschnitt 7 Liste der Dienstleistungen im Kontingentteil - 11 - ZKS-JIRA Die Umsetzung von Emergencychanges sollte stets baldmöglichst erfolgen. Der entsprechend der vertraglichen Festlegungen spätestens zulässige Umsetzungszeitpunkt wird durch die IKA bei der Zuweisung der Meldung an KDO in der Angabe Zeitpunkt Umsetzung Soll eingetragen. Der Termin für die Umsetzung von Regelchanges wird vor der Anforderung der Umsetzung zwischen der IKA und KDO einvernehmlich festgelegt und wird durch die IKA bei der Zuweisung der Meldung an KDO in der Angabe Zeitpunkt Umsetzung Soll eingetragen. 3.3.5. Bearbeitung von Meldungen zu Programmfehlern Die IKA ist bei der Bearbeitung von Meldungen zu Programmfehlern verpflichtet, die Meldungen vor deren Weiterleitung als zu behebenden Fehler an IBM zunächst auf Berechtigung zu prüfen.12 Zur Prüfung gehören die folgenden Teilprüfungen - Prüfung, ob das beschriebene Verhalten durch einen Bestandteil des DV-Systems ZKS-Abfall bei bestimmungsmäßigem Betrieb hervorgerufen wurde - Prüfung, ob das aufgetreten ist beschriebene Programmverhalten tatsächlich auftritt bzw. Diese Prüfung erfolgt entweder durch den Versuch der Reproduktion des Fehlers oder durch eine Analyse der Meldung gemeinsam mit dem Melder bzw. anhand dessen Angaben. - Prüfung, ob das Programmverhalten eine Abweichung Programmverhalten darstellt (vgl. auch Abschnitt 3.1) vom vereinbarten Ist eine der genannten Bedingungen nicht erfüllt, wird die Meldung nach Information des Melders über das Prüfergebnis entweder mit der Lösung "gegenstandslos" oder "kein Fehler" geschlossen oder durch die IKA als Optimierung oder Supportmeldung weiterbearbeitet. Sind alle drei Kriterien erfüllt, weist die IKA die Meldung der IBM als zu behebenden Programmfehler zu. Der Zeitpunkt, bis zu dem die IBM entsprechend der vertraglichen Regelungen die Bearbeitung des Programmfehlers begonnen haben muss, wird von der IKA in die Angabe Zeitpunkt Rückmeldung Soll eingetragen. 3.3.6. Bearbeitung von Optimierungen Nach der Sichtung eines Optimierungsvorschlages prüft die IKA zunächst, ob und wie der Optimierungswunsch umgesetzt werden könnte und ob die Umsetzung mit dem übrigen Programmverhalten verträglich wäre. Ggf. werden die Anforderungen an die Umsetzung in einem separaten Dokument beschrieben, das der Meldung angefügt wird. Bei der Erarbeitung des Umsetzungskonzeptes beteiligt die IKA ggf. die IBM13. Ist die Vorprüfung mit positivem Ergebnis abgeschlossen, legt die IKA den Optimierungsvorschlag dem zuständigen Gremium zur Entscheidung über die Umsetzung vor. Welches Gremium mit welchen Ergebnis über die Umsetzung eines Optimierungsvorschlages entschieden hat, ist der Angabe Umsetzungsentscheidung zu entnehmen. Wird die Umsetzung befürwortet, fordert die IKA außerhalb des JIRA-Meldungssystems die Umsetzung der Optimierung bei der IBM an und weist die Meldung entsprechend zu. 12 13 vgl. IBM-Pflegevertrag Abschnitt 6.3. Vgl. IBM-Pflegevertrag Abschnitt 7 Liste der Dienstleistungen im Kontingentteil - 12 - ZKS-JIRA Der Termin für die Umsetzung von Optimierungen wird vor der Anforderung der Umsetzung zwischen der IKA und der IBM einvernehmlich festgelegt und wird durch die IKA bei der Zuweisung der Meldung an KDO in der Angabe Zeitpunkt Umsetzung Soll eingetragen. Wird die Umsetzung abgelehnt, wird der Optimierungsvorschlag mit der Lösung "Optimierungsvorschlag abgelehnt" geschlossen. 3.3.7. Bearbeitung von Supportanfragen Die Bearbeitung von Supportanfragen erfolgt in aller Regel durch die IKA. Bei der Klärung von fachlichen Fragen beteiligt die IKA ggf. die IBM und die KDO. 3.3.8. Kategorie einer Meldung Nur für die Meldungen, die durch die IKA der KDO oder der IBM als im Rahmen der entsprechenden Verträge zu behebende Betriebsstörungen, umzusetzende Betriebsänderung oder zu behebende Programmfehler zugewiesen werden, legt die IKA die Kategorie der Meldung fest. 3.3.8.1. Einstufung Für die Einstufung der Meldungen in die Kategorien können aufgrund der Vielfalt der denkbaren Fallgestaltungen keine festen Regeln beschrieben werden. Die Einstufung erfolgt daher immer individuell unter Berücksichtigung der speziellen Konstellation. Maßgeblich sind dabei die Gegebenheiten des tatsächlichen produktiven Betriebs. 3.3.8.2. - Kategorien Betriebsstörung14 Kategorie A (betriebsverhindernd) Eine betriebsverhindernde Störung liegt vor, wenn die Nutzung des Systems unmöglich oder erheblich eingeschränkt ist. Eine betriebsverhindernde Störung liegt auch vor, wenn mehrere leichte Störungen insgesamt zu einer erhebliche Einschränkung der Nutzung des Systems führen. Hierzu zählen z.B. - o Kommunikationsstörungen wie "kein Dokumentenversand möglich" oder "Bearbeitungsstau durch langsame Verarbeitung von Dokumenten" o Einloggen für Nutzer nicht möglich o Registrierung oder Adressabfragen nicht möglich Kategorie B (leichte Störung) Eine leichte Störung liegt vor, wenn die Nutzung des Systems mit leichten Einschränkungen möglich ist. Hierzu zählen z.B. 3.3.8.3. 14 15 o Einloggen für die IKA an den speziellen ZKS-Tools (z.B. Admintool, CMS) ist nicht möglich o zeitverzögerter Mailversand zu durchgeführten Registrierungen Kategorien Betriebsänderungen15 Regelchange vgl. KDO-Leistungsbeschreibung Abschnitt 3.7.2. vgl. KDO-Leistungsbeschreibung Abschnitt 3.7.1. - 13 - ZKS-JIRA Zuvor geplante und vereinbarte Änderung. - Emergencychange Dringende vorab nicht geplante und planbare Änderung zur Behebung von Betriebsstörungen und Programmfehlern 3.3.8.4. - Kategorien Programmfehler16 Kategorie 1 Der Fehler bewirkt einen Systemstillstand, d.h. wesentliche Teile der Software lassen sich nicht nutzen. - Kategorie 2 Schwerwiegender Mangel, jedoch gibt es die Möglichkeit, den Fehler zu umgehen - Kategorie 3 Leichter Mangel, der keinen oder nur einen geringen Einfluss auf die Funktionsweise der Software hat, wie z.B. Tippfehler in den Hilfetexten, Mängel in der Dokumentation. 3.3.9. Schließen von Meldungen Meldungen werden ausschließlich durch die IKA geschlossen. Vor dem Schließen von Meldungen zu einer Betriebsstörung prüft die IKA ihre tatsächliche Behebung. Meldungen zu einer bereits behobenen Störung werden durch die IKA erst dann geschlossen, wenn durch sie keine negativen Folgewirkungen auf den aktuellen Betrieb mehr auftreten. Meldungen zu Betriebsänderungen werden durch die IKA in der Regel unmittelbar nach ihrer Umsetzung geschlossen. Meldungen zu Programmfehlern und zu Optimierungen werden am Tag der Installation der entsprechend aktualisierten Programmversion geschlossen. Support-Meldungen werden durch die IKA unmittelbar nach Abschluss des Supports geschlossen. Das Schließen einer Meldung zu einer Optimierung ist nicht mit der Abnahme der Leistung entsprechend des jeweiligen Vertrages verbunden. Diese erfolgt separat außerhalb des JIRA-Meldungssystems. Ist die Abnahme erfolgt, wird das Datum der Abnahme durch die IKA in der Angabe Datum Abnahme vermerkt. Wird die Bearbeitung einer Meldung zu einer Betriebsstörung bzw. zu einem Programmfehler oder zu einem Support nicht mit der Behebung der Betriebsstörung bzw. des Programmfehlers (z.B. weil es bei dem beschriebenen Verhalten nicht um eine Betriebsstörung bzw. einen Programmfehler handelte) bzw. mit dem erfolgreichen Abschluss des erbetenen Supports beendet, gibt die IKA dem Melder die Möglichkeit sich zur beabsichtigen Beendigung der Bearbeitung der Meldung zu äußern. Reagiert der Melder auf Nachfragen zu gemeldeten Betriebsstörungen nicht innerhalb von 24 Stunden, schließt die IKA die Meldung ohne weitere Rücksprache. Erhält die IKA innerhalb eines Zeitraums von 10 Arbeitstagen und trotz erfolgter Erinnerung keine Rückmeldung auf Nachfragen zu gemeldeten Programmfehlern und Supportanfragen (z.B. in Form von Bitten um Bereitstellung von Dateien und Dokumenten hierzu) sowie auf 16 vgl. IBM-Pflegevertrag Abschnitt 6.4. - 14 - ZKS-JIRA die Ankündigung der Beendigung der Bearbeitung einer Meldung, schließt die IKA die Meldung ohne weitere Rücksprache. 3.3.10. Interesse Information bei Meldungen von besonderem allgemeinem Die IKA informiert die Nutzer der ZKS-Abfall zum Vorliegen von Meldungen von besonderem allgemeinem Interesse (insbesondere zu Störungsmeldungen und zu Betriebsänderungen), die sich auf die Produktivumgebung beziehen, durch das Einstellen einer Störungsmeldung bzw. Wartungsankündigung auf der Internetseite www.zks-abfall.de. Zusätzlich erfolgt eine Information der ASYS-Fachadministratoren und -Fachbetreuer sowie von Herstellern und Providern von eANV-Systemen und anderer Interessierter per E-Mail. Bei Störungen und Betriebsänderungen, die sich auf die modifizierte Testumgebung der ZKS-Abfall beziehen, informiert die IKA die Nutzer der modifizierte Testumgebung per EMail. Der Zeitpunkt, an dem die Information zum Vorliegen des Problems erstmalig erfolgte, wird von der IKA in der Angabe Zeitpunkt Hinweis extern eingetragen. 3.4. Bearbeitung von Meldungen durch KDO 3.4.1. Vertragliche Grundlagen Die KDO ist zur Behebung von Störungen und zur Umsetzung von Betriebsänderungen im Rahmen des KDO-Service-Vertrags i.V.m. der KDO-Leistungsbeschreibung verpflichtet. 3.4.2. Behebung von Betriebsstörungen Die duch die IKA festgelegte Kategorie der Störung bestimmt die durch die KDO während der Bearbeitung der Meldung nach der Zuweisung einzuhaltenden Fristen. Folgende maximale Störungsdauern wurden vereinbart.17 Beschreibung PU ITU MTU Maximale Störungsdauer pro Ereignis in Minuten 05:00 - 21:00 215 (Mo -Fr) min 315 min 415 min Maximale Störungsdauer pro Ereignis in Minuten 21:00 - 05:00 430 (Mo - Fr) min n.v. n.v. Maximale Störungsdauer pro Ereignis in Minuten ganztags Sa, 430 So und deutschlandweite Feiertage min n.v. n.v. Maximale Störungsdauer pro Ereignis in Minuten 05:00 - 21:00 495 (Mo -Fr) min 495 min 495 min Maximale Störungsdauer pro Ereignis in Minuten 21:00 - 05:00 n.v. (Mo - Fr) n.v. n.v. Betriebsverhindernder Ausfall Kategorie "A" Leichte Störung Kategorie "B" 17 vgl. KDO-Leistungsbeschreibung Abschnitt 3.7.2, Tabelle 13. - 15 - ZKS-JIRA Beschreibung PU ITU MTU Maximale Störungsdauer pro Ereignis in Minuten ganztags Sa, n.v. So und deutschlandweite Feiertage n.v. n.v. KDO kann auf die Zuweisung einer Meldung des Vorgangstyps „Betriebsstörung“ in unterschiedlicher Weise reagieren: - Die Meldung wird als zu behebende Störung akzeptiert. Hierzu erfolgt eine Änderung des Bearbeitungsstatus im JIRA-Meldungssystem auf "In Arbeit KDO / Störung in Behebung" Ggf. wird eine Umgehungsmöglichkeit für den angegeben (in der Angabe Problemlösung). - Die Meldung kann noch nicht abschließend beurteilt werden, da zur Analyse des Fehler bzw. des Problems weitere Informationen notwendig sind: Zur Anforderung der Informationen erfolgt eine unmittelbare Änderung des Bearbeitungsstatus auf "In Arbeit KDO / Rückfrage bei Melder o.a." und eine Beschreibung, welche Angaben, Informationen und Dokumente benötigt werden, in der Kommentierung. - Die Meldung wird nicht als im Rahmen des genannten Auftrages zu behebende Störung akzeptiert, da es sich entweder um keine Störung handelt oder eine Störung durch KDO nicht feststellbar ist. Der Grund für die Ablehnung wird in einer Kommentierung angegeben. Die Angabe Bearbeitungsstatus wird auf "In Arbeit IKA / keine Störung" oder auf "In Arbeit IKA / Störung nicht nachvollziehbar" aktualisiert. Die KDO beschreibt während der Bearbeitung der Betriebsstörung die genaue Art, den Umfang und die vermutete Ursache der Störung in der Angabe Problembeschreibung. Zur Behebung einer Betriebsstörung durch KDO gehören alle Maßnahmen, die erforderlich sind, um das System in einen Zustand zu bringen, in dem es wieder uneingeschränkt genutzt werden kann. Die KDO beschreibt die von ihr ergriffenen Maßnahmen in der Angabe Problemlösung. Nach Behebung der Störung trägt die KDO den Zeitpunkt der Behebung der Störung in der Angabe Zeitpunkt Umsetzung ein und weist die Meldung mit dem Bearbeitungsstatus "In Arbeit IKA / Störung behoben" an die IKA zurück. Die Angaben Zeitpunkt Störungsbeginn und Zeitpunkt Umsetzung sind für die Überprüfung der Einhaltung der vertraglichen Fristen maßgeblich. 3.4.3. Umsetzung von Betriebsänderungen Die duch die IKA festgelegte Kategorie der Betriebsänderung bestimmt die durch die KDO während der Bearbeitung der Meldung nach der Zuweisung einzuhaltenden Fristen. Folgende maximale Umsetzungszeiten wurden vereinbart.18 18 vgl. Leistungsbeschreibung, Abschnitt 3.7.2, Tabelle 13. - 16 - ZKS-JIRA Betriebsänderungen ITU MTU Mit einer Vorlaufzeit von 2 Arbeitstagen (Mo - Fr bzw. im Regelwartungsfenster) Mit einer Vorlaufzeit von 2 Arbeitstagen (Mo - Fr bzw. im Regelwartungsfenster) Umsetzung von 2 Stunden Emergencychanges 05:00 - 21:00 (Mo -Fr) 2 Stunden 2 Stunden Umsetzung von 6 Stunden Emergencychanges jedoch spätestens 21:00 - 5:00 (Mo -Fr) 7 Uhr des folgenden Werktages 6 Stunden 6 Stunden Umsetzung von 6 Stunden Emergencychanges ausgenommen ganztags Sa, So und Wartungsfenster deutschlandweite Feiertage 6 Stunden 6 Stunden ausgenommen Wartungsfenster ausgenommen Wartungsfenster Umsetzung Regelchanges PU von Mit einer Vorlaufzeit von 10 Arbeitstagen im Regelwartungsfenster jedoch spätestens 7 jedoch spätestens 7 Uhr des folgenden Uhr des folgenden Werktages Werktages Wurde die Umsetzung einer Betriebsänderung durch KDO abgeschlossen, ist der Zeitpunkt der Umsetzung in der Angabe Zeitpunkt Umsetzung einzutragen und die Meldung mit dem Bearbeitungsstatus "In Arbeit IKA / Betriebsänderung umgesetzt" an die IKA zurückzuzuweisen. Die Angaben Zeitpunkt Meldung an AN und Zeitpunkt Umsetzung sind für die Überprüfung der Einhaltung der vertraglichen Fristen maßgeblich. 3.5. Bearbeitung von Meldungen durch IBM 3.5.1. Vertragliche Grundlagen Die Bearbeitung von Meldungen durch die IBM erfolgt auf Basis des IBM-Pflegevertrages. 3.5.2. Behebung von Programmfehlern Die duch die IKA festgelegte Kategorie des Programmfehlers bestimmt die durch IBM während der Bearbeitung der Meldung nach der Zuweisung einzuhaltenden Fristen. Folgende Fristen für den Beginn der Arbeiten zur Behebung des Fehlers wurden vereinbart.19 Kategorie Beginn 1 4 Stunden 2 am nächsten Arbeitstag Vgl. Pflege- und Wartungsvertrag, Abschnitt 6.4. (Bei der Berechnung der Fristen sind nur die Geschäftszeiten der IBM zu berücksichtigen.) 19 - 17 - ZKS-JIRA Kategorie Beginn 3 am nächsten Arbeitstag IBM kann auf die Zuweisung eines Programmfehlers in unterschiedlicher Weise reagieren: - Die Meldung wird als zu behebender Programmfehler akzeptiert. Hierzu erfolgt eine Änderung des Bearbeitungsstatus im JIRA-Meldungssystem auf "In Arbeit IBM / Fehler in Behebung" Eine Umgehungsmöglichkeit für den Programmfehler ist dabei anzugeben (in der Angabe Problemlösung). - Die Meldung kann noch nicht abschließend beurteilt werden, da zur Analyse des Fehler bzw. des Problems weitere Informationen notwendig sind: Zur Anforderung der Informationen erfolgt eine unmittelbare Änderung des Bearbeitungsstatus auf "In Arbeit IBM / Rückfrage bei Melder o.a." und eine Beschreibung, welche Angaben, Informationen und Dokumente benötigt werden, in der Kommentierung. - Die Meldung wird nicht als im Rahmen des genannten Auftrages zu behebender Programmfehler akzeptiert. Der Grund für die Ablehnung wird in einer Kommentierung angegeben. Die Angabe Bearbeitungsstatus wird auf "In Arbeit IKA / Verhalten spezifikationsgemäß" oder auf "In Arbeit IKA / Fehler nicht nachvollziehbar" aktualisiert. In jedem Fall wird der Zeitpunkt, an dem die erste Rückmeldung von IBM nach der Zuweisung durch die IKA erfolgte, durch IBM in der Angabe Zeitpunkt Rückmeldung AN eingetragen. Zur Bearbeitung eines Programmfehlers durch IBM gehören ggf. die Beschreibung der Ursachen des Problems und soweit möglich auch eine Beschreibung der Möglichkeiten zur Behebung. Wurde die Bearbeitung eines Programmfehlers durch die IBM abgeschlossen, ist das aktuelle Datum als Datum Umsetzung sowie die Version der Software ZKS-Abfall, in der die Behebung des Programmfehlers erfolgte, in der Angabe Auslieferung mit einzutragen. Die Meldung wird durch die IBM anschließend mit dem Bearbeitungsstatus "In Arbeit IKA / Fehler behoben" an die IKA zurückzugewiesen. Die Angaben Zeitpunkt Meldung an AN und Zeitpunkt Rückmeldung AN sind für die Überprüfung der Einhaltung der vertraglichen Fristen maßgeblich. 3.5.3. Umsetzung von Optimierungen Wurde die Umsetzung einer Optimierung durch die IBM abgeschlossen, ist das aktuelle Datum als Datum Umsetzung sowie die Version der Software ZKS-Abfall, in der die Umsetzung der Optimierung erfolgte, in der Angabe Auslieferung mit einzutragen. Die Meldung wird durch die IBM anschließend mit dem Bearbeitungsstatus "In Arbeit IKA / Optimierung umgesetzt" an die IKA zurückzugewiesen. 3.6. Abbildung des Bearbeitungsablaufes im JIRA-Meldungssystem Für die Bearbeitung der Meldungen sind entsprechend des in den Abschnitten 3.2., 3.3, 3.4 und 3.5 beschriebenen Bearbeitungsablaufs jeweils verschiedene sogenannte JIRAArbeitsabläufe konfiguriert. - 18 - ZKS-JIRA 3.6.1. Arbeitsablauf Betriebsstörungen und Betriebsänderungen 3.6.2. Arbeitsablauf Programmfehler und Optimierung - 19 - ZKS-JIRA 3.6.3. Arbeitsablauf Support 3.6.4. Angabe Status Den Stand der Bearbeitung einer Meldung entsprechend des Arbeitsablaufes kann der Angabe Status entnommen werden. Folgende Zustände des Status sind möglich. - offen - In Arbeit IKA - In Arbeit KDO - In Arbeit IBM - geschlossen Über die Angabe Status ist ersichtlich, wer für die weitere, fristgerechte Bearbeitung der Meldungen verantwortlich ist. Diese Verantwortung liegt bei Meldungen in den Status "offen" und "In Arbeit IKA" bei der IKA, bei Meldungen im Status "In Arbeit KDO" bei der KDO und bei Meldungen im Status "In Arbeit IBM" bei der IBM. Meldungen im Status "geschlossen" werden nicht weiter bearbeitet. Der Status einer Meldung kann im JIRA-Meldungssystem nur über besondere Funktionalitäten ("Sichten", "KDO zuweisen", "IBM zuweisen", "IKA zuweisen“ und "Schließen") verändert werden, die nur der IKA, KDO und bzw. oder IBM zur Verfügung stehen. - Die Sichtung einer Meldung ist ausschließlich der IKA möglich. - Die Zuweisung einer Meldung zur weiteren Bearbeitung an KDO erfolgt durch die IKA. - KDO kann die Bearbeitung einer neuen Meldung initiativ an sich ziehen. Dieser Fall tritt immer ein, wenn es sich um eine durch die KDO selbst festgestellte Betriebsstörung handelt. - Die Zuweisung einer Meldung zur weiteren Bearbeitung an IBM erfolgt durch die IKA. - Die Zurückzuweisung einer Meldung zur weiteren Bearbeitung an die IKA erfolgt durch die KDO bzw. die IBM. - Das Schließen einer Meldung erfolgt ausschließlich durch die IKA. - 20 - ZKS-JIRA Neben der automatisierten Benachrichtigung bei Änderung einer Meldung bzw. bei Zuweisung werden bei der Erstellung sowie bei der Zuweisung von Meldungen (vgl. Abschnitt 2.4) durch das JIRA-Meldungssystem folgende besondere Benachrichtigungen automatisiert versandt: - Bei Erstellung einer Meldung wird eine Benachrichtigung an die IKA gesandt (derzeit an die E-Mail-Adresse des unpersönlichen Benutzers "ZKS-Bearbeiter IKA"). - Bei Zuweisung einer Meldung an KDO wird eine Benachrichtigung an die KDO gesandt (derzeit an die E-Mail-Adresse des unpersönlichen Benutzers "ZKSBearbeiter KDO" [email protected]). - Bei Zuweisung einer Meldung an IBM wird eine Benachrichtigung an die IBM gesandt (derzeit an die E-Mail-Adresse des unpersönlichen Benutzers "ZKS-Bearbeiter IBM" [email protected]). - Bei Zurückzuweisung einer Meldung an die ZKS durch KDO oder IBM wird eine Benachrichtigung an IKA gesandt (derzeit an die E-Mail-Adresse des unpersönlichen Benutzers "ZKS-Bearbeiter IKA"). 3.6.5. Angabe Bearbeitungsstatus Befindet sich die Meldung in Bearbeitung wird zusätzlich zum Status der detaillierte Stand der Bearbeitung in der Angabe Bearbeitungsstatus angegeben. Der 1. Teil des zweistufig angegebenen Bearbeitungsstatus entspricht dabei immer dem Status der Meldung. Der Bearbeitungsstatus wird während der Bearbeitung entsprechend des aktuellen Standes durch die IKA, KDO bzw. IBM aktualisiert (vgl. Abschnitt 3.8). Bei geschlossenen Meldungen ist der Grund, aus dem die Meldung geschlossen wurde, der Angabe "Lösung" zu entnehmen. - 21 - ZKS-JIRA 3.7. Erläuterung zu weiteren Angaben im JIRA-Meldungssystem 3.7.1. Zusammenfassung, Nummer Das Feld Zusammenfassung enthält einen Titel bzw. einen Betreff für die Meldung. Die Zusammenfassung wird im JIRA-Meldungssystem in der Regel gemeinsam mit einer vom System vergebenen Nummer, dem sogenannten Schlüssel, angezeigt. Die Zusammenfassung der Meldung wird ggf. im Laufe der Bearbeitung der Meldung entsprechend dem aktuellen Kenntnisstand aktualisiert. 3.7.2. Beschreibung des Problems und seiner Lösung Bei der Erstellung der Meldung beschreibt der Melder das fehlerhafte Programmverhalten, den Optimierungswunsch oder das Problem, bei dem Support gewünscht wird, im Feld Beschreibung durch Melder. Diese Angabe bleibt während der gesamten Bearbeitung der Meldung unverändert erhalten. Soweit während der Bearbeitung der Meldung ersichtlich wird, dass die ursprüngliche Beschreibung durch den Melder das Problem nicht aussagekräftig, nicht exakt genug oder nicht korrekt beschreibt, erstellt die IKA eine aktualisierte Beschreibung der Meldung (im Feld Problembeschreibung). Diese wird ggf. während der weiteren Bearbeitung entsprechend dem aktuellen Kenntnisstand durch die IKA bzw. die KDO oder die IBM weiter fortgeschrieben. Die Angabe Modul/Programmbestandteil gibt wieder, auf welches Modul bzw. welchen Programmbestandteil sich die Meldung bezieht. Die Eingabe muss durch Auswahl aus den Vorgaben erfolgen. Die Eingabe erfolgt zudem mehrstufig: Nach Eingabe des Hauptprogrammbestandteils kann aus den entsprechenden Unterbereichen ausgewählt werden. Sowohl die Zusammenfassung als auch die Problembeschreibung sind immer im Kontext mit dem Modul bzw. Programmbestandteil, auf den sich die Meldung bezieht, zu sehen. Die Angabe Version gibt die Modul- oder die Programmversion bzw. den Stand wieder, auf den sich die Meldung bezieht. Die Eingabe muss durch Auswahl aus den Vorgaben erfolgen. Nach Eingabe des betroffenen Hauptprogrammbestandteils werden in der zweiten Auswahlliste die jeweiligen Versionen bzw. Stände zur Auswahl angeboten. Der unter Version angegebene Hauptprogrammbestandteil muss mit dem unter Modul/Programmbestandteil angegebenen Hauptprogrammbestandteil übereinstimmen. Die Angabe Problemlösung beschreibt die zur Lösung des Problems notwendigen bzw. durchgeführten Änderungen, wenn diese nicht bereits aus der Beschreibung durch den Melder oder der Problembeschreibung hinreichend hervorgehen. Besteht bei Programmfehlern die Möglichkeit einer Umgehung des Problems ist dieser als sogenannter "Workaround" ebenfalls der Angabe Problemlösung zu entnehmen. Ggf. enthält die Problemlösung die Antwort auf die gestellte Frage. 3.8. Aktualisierung der Angaben im ZKS-JIRA-Meldungssystem Welche Angaben während der Erstellung und der Bearbeitung der Meldungen durch den Melder, die IKA und ggf. KDO oder IBM einzutragen (E), zu aktualisieren (A) bzw. zu prüfen (P) sind und in diesem Rahmen geändert werden dürfen, ist der nachfolgenden Tabelle zu entnehmen. - 22 - Schlüssel E Vorgangstyp E P A Zusammenfassung E A A Status E A Bearbeitungsstatus E A A A A A A A A E P A A Prog.Bestandteil E P A A Programmversion E P A A Autor E P/A Meldergruppe E P Melder E Melder Telefonnr. E E/A E/A Melder E-Mail E E/A E/A Externe Nr. E Zeitpunkt Erstellung E Beschreibung durch Melder E Dringlichkeit E Priorität Nacharbeit (IKA) Eintrag erfolgt i.d.R. automatisiert. Eintrag erfolgt automatisiert. E A Einzutragen, wenn nicht mit Erstellungsdatum identisch (z.B. Erfassung durch IKA aus Mail eines eANV-Nutzers) E Auftrag E Bearbeiter E Problembeschreibung E Zeitpunkt Hinweis extern Eintrag erfolgt automatisiert. E Umgebung Problemlösung Hinweise Eintrag erfolgt automatisiert. Lösung Zeitpunkt Meldung an IKA Schließen (IKA) Zuweisung an IKA (durch KDO,/IBM) Bearbeitung durch KDO/IBM Zuweisung an KDO/IBM (durch IKA) Sichten (IKA) Erstellen Angabe (Pflichtangaben fett) Bearbeitung durch IKA ZKS-JIRA A P A A20 A E/A P E/A E/A P E/A Auftrag, auf dessen Grundlage die Bearbeitung erfolgt. Bei der Erstellung erfolgt automatisiert der Eintrag „IKA-Vertrag“. A21 Aktualisierung erfolgt im Rahmen der Zuweisungen automatisiert. Einzutragen, wenn die Beschreibung durch den Melder nicht aussagekräftig oder zutreffend ist P P Einzutragen, wenn die Problemlösung nicht offensichtlich;(ggf. auch Umgehungen) E Als Bearbeiter wird bei der Zuweisung einer Meldung an KDO bzw. IBM der unpersönliche Benutzer "ZKS-Bearbeiter KDO" bzw. "ZKS-Bearbeiter IBM" eingetragen. 21 Als Bearbeiter wird bei der Zuweisung einer Meldung an die IKA der unpersönliche Benutzer "ZKS-Bearbeiter IKA" eingetragen. 20 - 23 - Aufwand geschätzt Nacharbeit (IKA) Schließen (IKA) Zuweisung an IKA (durch KDO,/IBM) Bearbeitung durch KDO/IBM Zuweisung an KDO/IBM (durch IKA) Sichten (IKA) Erstellen Angabe (Pflichtangaben fett) Bearbeitung durch IKA ZKS-JIRA Nur bei Optimierungen: Einzutragen durch IKA in Absprache mit IBM E Kategorie Hinweise Einzutragen bei Betriebsstörungen, Betriebsänderungen, Programmfehlern E Zeitpunkt Störungsbeginn E E/A/ P Nur bei Betriebsstörungen Zeitpunkt Störungsfeststellung E E/A/ P Nur bei Betriebsstörungen Zeitpunkt Meldung an AN Datum/Uhrzeit entsprechen in der Regel dem Zeitpunkt der Zuweisung. E Zeitpunkt Rückmeldung AN E Zeitpunkt Rückmeldung AN Soll nur bei Betriebsstörung und Programmfehlern E Zeitpunkt Umsetzung E Zeitpunkt Umsetzung Soll P E geflickt mit E Auslieferung mit E Einzutragen bei Fehlerbehebung Datum Abnahme E Einzutragen bei Optimierung Datum Rechnung E Einzutragen bei Optierung Zeitpunkt Meldung geschlossen Eintrag erfolgt automatisiert E - 24 -
