Adaptierbare Webapplikationen

Transkript

1 Adaptierbare Webapplikationen Adaptierbarkeit der Hyperwave Information Server Applikation "Support Tracking System" Diplomarbeit an der Technischen Universität Graz vorgelegt von Christian Trummer Institut für Informationssysteme und Computer Medien IICM Technische Universität Graz A-8010 Graz Österreich März 2004 Copyright 2004, Christian Trummer Begutachter: Betreuer: o.univ.-prof. Dr. Dr.h.c.mult. Hermann Maurer Dipl.-Ing. Dr.techn. Christian Gütl Dipl.-Ing. Helmut Leitner

2 Meinen Eltern Theresia und Anton und meiner Lebensgefährtin Evelyn.

3 Kurzfassung Trouble Ticket Systeme dienen zur Dokumentation von Problemen und deren Lösungen. Das Support Tracking System, welches zu den Trouble Ticket Systemen gehört, ist spezialisiert auf den Kundendienstbereich. Kundenprobleme, deren Dokumentation und Lösungen, werden mittels Trouble Tickets erfasst. Um das Support Tracking System bei verschiedenen Kunden einsetzen zu können, war es notwendig geworden Möglichkeiten zur Adaptierung des Systems und der Benutzeroberfläche zu schaffen. Dies wurde im Rahmen von Wartungsarbeiten durchgeführt. Neben der Wartung des Support Tracking Systems war ein weiteres Ziel dieser Arbeit, eine Reduktion der anfallenden Wartungskosten. Arbeitstechniken aus dem Bereich der agilen Softwareentwicklungsprozesse wurden angewandt, um diese Kostenreduktion zu erreichen. Die Umwandlung in eine adaptierbare Webapplikation sollte den Umfang der Wartungsarbeiten reduzieren und so ebenfalls zu einer Kostenverringerung führen. Weil für die Anwendung der Arbeitstechniken (Refaktoring) die notwendigen Rahmenbedingungen (vollständige Testabdeckung) fehlten, hatte dieser Ansatz nur geringen Erfolg. Es gelang aber durch Einführung der Adaptierbarkeit, den Umfang der Wartungsarbeiten deutlich zu reduzieren. Man sollte daher bei zukünftigen Projekten von Anfang an für eine vollständige Testabdeckung sorgen. In diesem Fall sollte auch der Ansatz mit den Arbeitstechniken aus den agilen Softwareentwicklungsprozessen zu einer Reduktion der Wartungskosten führen. Abstract Trouble Ticket Systems are used for the documentation of occurring problems and their solutions. The Support Tracking System, a component of the Trouble Ticket Systems is specialized for customer support divisions. Problems reported by customers and the documentations of the solutions are stored in trouble tickets. To assure that the Support Tracking System useable for different customers, it was necessary to integrate possibilities for adaptation of the system and the user interface. This was realized during the maintenance phase. In addition to the maintenance of the Support Tracking System the reduction of the maintenance costs was one of the aims of this thesis. Several practices in the field of agile software development processes were used to reduce these costs. The transformation to an adaptable web application should reduce the amount of maintenance. Since not all conditions (test cases) necessary for practices (refactoring), this approach had only marginal success. The introduction of adaptability reduced the amount of maintenance significantly. For future projects test cases should be developed from the beginning. In this way the approach to use practices from agile software development processes would also lead to a reduction of maintenance costs.

4 Danksagung An dieser Stelle möchte ich mich bei all jenen bedanken, die mir beim Erstellen dieser Arbeit durch ihre Unterstützung zur Seite gestanden sind. Allen voran o.univ.-prof. Dr. Dr.h.c.mult. Hermann Maurer, Leiter des Institutes für Informationssysteme und Computer Medien (IICM) und Begutachter dieser Arbeit, sowie bei meinen Betreuern Dipl.-Ing. Dr.techn. Christian Gütl und Dipl.-Ing. Helmut Leitner, die mir durch ihre intensive Betreuung, zum einem im wissenschaftlichen Bereich zum anderen im kommerziellen und technischen Bereich, sehr geholfen haben. Weiters möchte ich mich an dieser Stelle bei allen Mitgliedern der Web Application Group und allen anderen Mitarbeitern des Institutes für die schöne Zeit am Institut bedanken. Bedanken möchte ich mich auch bei meinem Freund Dipl.-Ing. Simon Zwölfer, der mir half meine anfänglichen Schwierigkeiten mit dem Hyperwave Information Server zu überwinden. Die Firma Hyperwave München war ein angenehmer Kunde und mitverantwortlich dafür, dass diese Arbeit für mich auch zu einem finanziellen Erfolg wurde. Meiner Freundin Evelyn danke ich für Ausdauer und Geduld. Ganz besonders bedanken möchte ich mich bei meinen Eltern Theresia und Anton, die mein Studium erst ermöglicht haben, mich all die Jahre hinweg tatkräftig unterstützt haben und meinen Plänen und Wünschen gegenüber immer offen waren.

5 Ich versichere hiermit, diese Arbeit selbständig verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfsmittel bedient habe.

6 Inhaltsverzeichnis Kapitel 1 Einleitung Motivation Problemumfeld Struktur der Arbeit... 3 Kapitel 2 Trouble Ticket Systeme Anforderungen an Trouble Ticket Systeme Abgrenzungsversuch Support Tracking System Übersicht verfügbarer Systeme Nichtkommerzielle Produkte Bugzilla Debian Bug Tracking System (debbugs) GNATS Double Choco Latte Kommerzielle Produkte Rational ClearQuest Rational ClearDDTS Aegis Defect Tracking OmniTracker Zusammenfassung Kapitel 3 Wartungsprozess Softwarewartung Agile Software Prozesse Meta Prozesse Konkrete Prozesse extreme Programming (XP) Refaktoring Zusammenfassung Kapitel 4 Systembeschreibung Hyperwave Information Server HWLIB Support Tracking System im Überblick Hauptfunktionen aus Benutzersicht Architektur des Support Tracking Systems Funktionalität des Support Tracking Systems Zusammenfassung Kapitel 5 Adaptierbare Systemeigenschaften Allgemeines... 54

7 Inhaltsverzeichnis 5.2 Werte für die Ticketattribute Kundendatenbank Rollenabhängige Funktionalität Eskalationszeiten Implementierung Kundenbenachrichtigung Zusammenfassung Kapitel 6 Adaptierbare Benutzeroberfläche Ausgabe unter STS V Ausgabe unter STS V STS Tags insert_data insert_functionresult insert_actionlink und insert_href HTML Vorlagen sts_base sts_ticketobject_object sts_ticketobject_content sts_noteentry sts_phonenoteentry sts_schedulenoteentry sts_ entry Implementierung Zusammenfassung Kapitel 7 Erkenntnisse Trouble Ticket Systeme Wartung und agile Softwareprozesse Adaptierbare Webapplikation Kapitel 8 Zusammenfassung...95

8 Kapitel 1 Einleitung In diesem einleitenden Kapitel wird die Ausgangssituation dargestellt, d.h. es wird die Situation rund um das im Rahmen der Arbeit zu verbessernde Support Tracking System wiedergegeben. Es wird eine kurze Darstellung gegeben, welche Bedürfnisse welchen Änderungsmotiven zu Grunde lagen. Es folgt eine Beschreibung des Problemumfeldes, in dem das Support Tracking System eingesetzt wird. Abschließend findet sich eine Beschreibung der Struktur der Arbeit. 1.1 Motivation Heutzutage versuchen zahlreiche Unternehmen ihre Kunden immer enger an sich zu binden, deshalb begnügen sie sich nicht mit dem reinen Verkauf ihrer Produkte, sondern verbinden diese, zum Wohle der Kunden, mit zahlreichen zusätzlichen Dienstleistungen zu den Produkten selbst. Vielfach richten Unternehmen Supportabteilungen oder Callcenters ein, die den Kunden bei auftretenden Problemen unterstützen und beraten sollen. Diese Maßnahme verbessert die Beziehung zum Kunden und erhöht somit die Kundenbindung. Trouble Ticket Systeme sind Applikationen zur Verwaltung von Problemen. Der Supportbereich ist ein mögliches Einsatzgebiet für diese Systeme. Die Kommunikation zwischen Supportmitarbeitern und den Kunden kann mit Trouble Ticket Systemen dokumentiert werden. Diese Systeme helfen den Supportmitarbeitern den Überblick so zu waren, dass auf kein Problem irgendeines Kunden vergessen wird. Außerdem ermöglichen sie offene Kundenprobleme mit bereits gelösten Fällen zu vergleichen. Am Institut für Informationssysteme und Computer Medien (IICM) 1 der Technischen Universität Graz 2 wurde ein solches System mit dem Namen Support Tracking System (STS) für Hyperwave 3 entwickelt. Das Support Tracking System ist eine Hyperwave Information Server basierende Intranet Webapplikation. Hyperwave erkannte die

9 Kapitel 1 Einleitung 2 Notwendigkeit das Support Tracking System an die Bedürfnisse unterschiedlicher Kunden anpassen zu können. Hyperwave erteilte dem IICM den Auftrag das System anpassbar zu machen und mit einer anpassbaren Benutzeroberfläche auszustatten. Dies wurde im Rahmen dieser Arbeit neben sonstigen Wartungsarbeiten umgesetzt. Daneben wurde nach Wegen gesucht die Wartungskosten zu senken. Mit der Entwicklung einer adaptierbaren Benutzeroberfläche und durch die Umwandlung in einen adaptierbaren Systemkern war auch das Ziel eine Kostenreduktion bei der Wartung zu erreichen verbunden. Anforderungen an Software Anwendungen sind einer stetigen Veränderung unterworfen, dies gilt besonders für Systeme im Dienstleistungssektor, wo es gilt die eigene Serviceleistung schneller als die Konkurrenz zu verbessern. Softwareanwendungen müssen durch fortlaufende Wartung immer wieder an die geänderten Anforderungen angepasst werden. Die Wartung von Software verursacht große Kosten, deren Ursache vielfältig sein können. Zwei mögliche Ursachen können sein, dass zu aufwendige Softwareentwicklungsprozesse in der Wartungsphase eingesetzt werden und dass Programm, Design und Architektur nur schwer zu ändern sind. Softwareentwicklungsprozesse nehmen kaum Rücksicht auf die Phase nach der Auslieferung der Software, sondern konzentrieren sich hauptsächlich auf die Phasen Analyse, Design, Implementierung und Test. Schwergewichtige Entwicklungsprozesse stellen eine große Belastung für die kleinen Wartungsmannschaften dar, sodass agile Software Entwicklungsprozesse für die Wartungsphase als die geeignetere Wahl erscheinen. Gelingt es Architektur und Design von Software so zu gestalten, dass nicht jede Änderung in den Anforderungen den Eingriff eines Softwareentwicklers nach sich zieht, könnten Wartungskosten stark reduziert werden. Durch die Umwandlung vom Support Tracking System in eine adaptierbare Webapplikation ist es den Anwendern nun nicht nur möglich zahlreiche Änderungen an der Anwendung selbst vorzunehmen, sondern auch das komplette Erscheinungsbild zu gestalten. Heute, nach Abschluss dieser Arbeit, kann dieses System an die Anforderungen verschiedener Kunden (Support Abteilungen) ohne großen Aufwand angepasst werden. 1.2 Problemumfeld Die Anwendungsgebiete von Trouble Ticket Systemen sind vielfältig, das Grundprinzip solcher Systeme ist aber ähnlich. Unabhängig davon ob es sich um Problem Tracking Systeme, Bug Tracking Systeme, Feature Request Systeme oder um das Support Tracking System handelt, stets wird zu einem Problemfall ein Ticket angelegt. Diese Tickets enthalten eine Grundbeschreibung der aufgetretenen Situation. Rund um diese Grundbeschreibung werden, mit der Zeit, weitere Informationen hinzugefügt. Beim vorliegenden Support Tracking System handelt es sich um eine auf Internettechnologien basierende Anwendung, die im Intranetbereich von Supportabteilungen zum Einsatz kommt. Der serverseitige Teil basiert auf dem Hyperwave Information Server. Im clientseitigen Teil kommen gewöhnliche Webbrowser zur Anwendung.

10 Kapitel 1 Einleitung 3 Supportabteilungen sind für Kunden die erste Anlaufstelle beim Auftreten von Problemen mit einem Produkt. Die Mitarbeiter im Supportbereich erfassen das Problem des Kunden mit einem Supportticket und fügen im Laufe der Zeit immer mehr Information zum Ticket hinzu. Dieses Hinzufügen erfolgt in Form sogenannter Ticketeinträge. Diese Einträge können Telefongespräche, s oder ganz einfache Notizen darstellen. In erster Linie soll das Support Tracking System verhindern, dass Supportmitarbeiter auf einzelne Kundenanfragen oder auf einzelne Probleme vergessen. Supporttickets erfahren eine ausführliche Beschreibung durch Metadaten. Mit Hilfe dieser Metadatenbeschreibung ist es möglich, nach ähnlichen Problemfällen im System zu suchen. 1.3 Struktur der Arbeit Die vorliegende Arbeit gliedert sich in einen Untersuchungsbereich und in einen daran anschließenden Gestaltungsbereich. Die der Einleitung folgenden drei Kapitel gehören zum Untersuchungsbereich. Kapitel 2 geht folgenden Fragen nach: Wozu werden Trouble Ticket Systeme verwendet? Wie funktionieren Trouble Ticket Systeme? Welche ähnlichen Softwaresysteme werden noch im Support eingesetzt? Welche kommerziellen Produkte sind verfügbar bzw. welche Produkte sind frei erhältlich? Wie für jedes andere Softwaresystem, ändern sich auch für Softwaresysteme im Dienstleistungsbereich immer wieder die Anforderungen oder Fehler im Programm werden offenkundig. Das Beheben von Softwarefehlern und das Anpassen von Software an neue Anforderungen erfolgt in der sogenannten Wartungsphase. Die Kosten dieser Phase werden vielfach unterschätzt. Ein Großteil der durchgeführten Arbeiten am Support Tracking System kann als Wartungsarbeiten betrachtet werden. Im Kapitel 3 werden die wesentlichen Kategorien der Softwarewartung definiert. Es wird die Möglichkeit untersucht, Wartungskosten zu senken, indem man Arbeitstechniken aus dem Bereich der agilen Softwareentwicklungsprozesse einsetzt. Softwaresysteme sind heutzutage zumeist keine vollständigen Neuentwicklungen, sondern greifen in verschiedensten Formen auf bereits bestehende Softwarekomponenten zurück. Diese Formen können vielfältig sein. Einige Stichworte dafür sind Komponentenmodelle, Middelware und Infrastruktursoftware, Wiederverwendung von Quellcode und Vererbung über Klassenhierarchien. Beim vorliegenden Support Tracking System verhält es sich nicht anders. Die wesentliche Basis vom Support Tracking System ist der Hyperwave Information Server der Firma Hyperwave und eine Bibliothek vom Institut für Informationssysteme und Computer Medien. Kapitel 4 gibt eine kurze Einführung zum Hyperwave Information Server. Es wird die Architektur und das Application Programming Interface (API) des Servers vorgestellt. In weiteren Unterkapiteln wird die Hyperwave Library HWLIB 4 und die Architektur 4 Hyperwave Library (HWLIB) erstellt von der Web Application Group (WAG) am IICM

11 Kapitel 1 Einleitung 4 des Support Tracking Systems beschrieben. Das Kapitel beinhaltet eine Beschreibung der Funktionalität des Support Tracking Systems aus Benutzersicht. Kapitel 5 und Kapitel 6 gehören zum Gestaltungsteil. Diese Kapitel beschreiben, wie die Adaptierbarkeit beim Support Tracking System realisiert wurde. Im Kapitel 5 wird beschrieben, wie aus dem Support Tracking System eine adaptierbare Webapplikation gemacht wurde. Durch die Möglichkeit das System adaptieren zu können, werden viel weniger Änderungswünsche an die Softwareentwickler herangetragen und die Kosten sinken. Kapitel 6 zeigt, wie der Kunde unter Verwendung von HTML Vorlagen in die Lage versetzt wird die Benutzeroberfläche zu verändern. Adaptierbare Systemeigenschaften und adaptierbare Benutzeroberfläche ergeben zusammen eine adaptierbare Webapplikation mit hohem Kundennutzen. Kapitel 7 umfasst die gewonnenen Erkenntnisse, sowohl aus dem Versuch auf Arbeitstechniken der agilen Softwareentwicklungsprozesse umzusteigen, als auch aus dem Versuch den Wartungsaufwand zu reduzieren, indem man das System in eine adaptierbare Anwendung umwandelt Kapitel 8 schließt diese Arbeit mit einer Zusammenfassung ab.

12 I. Untersuchungsbereich

13 Kapitel 2 Trouble Ticket Systeme Dieses Kapitel beginnt mit einer Definition und Aufgabenbeschreibung für Trouble Ticket Systeme. Im folgenden Teil werden Gemeinsamkeiten und Unterschiede zu ähnlichen Systemen herausgearbeitet. Im dritten Teil wird eine kurze Einführung in das vom Institut für Informationssysteme und Computer Medien (IICM) der Technischen Universität Graz entwickelte Support Tracking System gegeben. Einer kurzen Übersicht verfügbarer Konkurrenzprodukte folgt die ausführliche Beschreibung von jeweils vier kommerziellen bzw. nicht kommerziellen Produkten. 2.1 Anforderungen an Trouble Ticket Systeme Entdecken, Eingrenzen und Beheben von Fehlern und Störungen gehören zu einem effizienten Fehlermanagement. Anwender von Programmen und Diensten sind nicht für die Fehlerbehebung zuständig, sondern haben andere Aufgaben professionell zu erledigen. Fehlermanagement ist Aufgabe des Benutzerservice (engl. User Help Desk) und hat Verfügbarkeit und Zuverlässigkeit von Systemen und Diensten hoch zu halten. Die vom Benutzerservice verwendeten Fehlerdokumentationssysteme oder Störverfolgungssysteme bezeichnet man als Trouble Ticket Systeme. Ein Trouble Ticket ist ein Datensatz für genau eine Störung, der zumindest Störungsmelder, betroffene Komponente, Störsymptome und Lösung enthält. [Kruse 2001] Eine Untergruppe der Systeme im Helpdesk Bereich sind die Trouble Ticket Systeme. Sie systematisieren den Supportvorgang. Diese Systeme ordnen Anfragen und Hilferufe ("Calls"), die über verschiedene Frontends einlangen, in Kategorien ein und versehen sie mit eindeutigen Identifikationen. Die Kategorie bestimmt den Bearbeiter des Problems. Bearbeiter und Störungsmelder werden von Zuweisungen, Änderungen, Arbeitsschritten und Lösungsvorschlägen mittels s informiert. Die meisten Systeme unterstützen eine automatische Wiedervorlage unbearbeiteter Anfragen. Die Koordination von mehreren Mitarbeitern verbessert sich und die Servicequalität steigt. [Schade 1999]

14 Kapitel 2 Trouble Ticket Systeme 7 Trouble Ticket Systeme helfen die Stehzeiten zu verringern und dadurch verbessert sich die Kundenzufriedenheit. Durch die enge Rückkopplung zwischen Kunden und Herstellern steigert sich deren Produktivität. Leicht zugängliche Trouble Ticket Systeme bewirken, das die Hersteller mit den Wiederverkäufern und den Kunden in Verbindung bleiben. Die Systeme helfen eine effektive Kommunikation über die Probleme zu führen. Diese Systeme führen allmählich zu einem Wissensaufbau in den Supportabteilungen und bewirken dadurch eine Kostenreduktion. [Mozilla Organisation 2003] Fehlermanagement teilt sich in die drei Phasen: Fehlererkennung, Fehlerdiagnose und Fehlerbehebung (siehe Abbildung 2-1). In der ersten Phase geht es darum, das erkannte Problem ausführlich zu erfassen und hinreichend genug zu klassifizieren, damit es schließlich dem richtigen Mitarbeiter zur Bearbeitung zugewiesen werden kann. In der zweiten Phase der Fehlerdiagnose wird das bestehende Problem analysiert. Kann es vom Mitarbeiter, der es zur Bearbeitung zugeteilt bekommen hat, nicht gelöst werden, so wird das Problem an einen anderen Mitarbeiter weitergeleitet. Muss das Problem an einen Mitarbeiter mit tiefergehendem Spezialwissen weitergegeben werden, dann spricht man von Eskalation. Die Fehlerbehebung ist die abschließende Phase im Fehlermanagement. In dieser Phase wird das Problem behoben und es kommt zum Schließen der Störmeldung. Dabei bekommt der Störmelder eine Rückmeldung, die ihm mitteilt, dass das Problem behoben ist. Wesentlich ist, dass über alle drei Phasen hinweg eine lückenlose Dokumentation geführt wird. Dies ist notwendig, damit verschiedene Personen in den unterschiedlichen Schritten und Phasen am Problem arbeiten können. Die Dokumentation hilft ähnliche Probleme rascher lösen zu können. [Kruse 2001] Fehlermanagement Fehlererkennung - Erfassung - Klassifizierung - Zuweisung Fehlerdiagnose - Diagnosemaßnahmen - Weiterleitung - Eskalation Dokumentation Fehlerbehebung - Behebungsmaßnahme - Schließen der Störmeldung - Rückmeldung Abbildung 2-1: Phasen des Fehlermanagements nach[kruse 2001] Die Aufgaben eines Trouble Ticket Systems gliedern sich grundsätzlich in die vier Bereiche: Trouble Ticket Management, Statistiken und Berichte, Zugriff auf Problemlösungswissen und schließlich Trouble Ticket Korrelation. Den Kern stellt allerdings das Trouble Ticket Management dar. Dieser Bereich hat die Aufgabe Störungsmeldungen, inklusive aller Aktivitäten rund um die Störbehebung in einer Datenbank zu speichern und zu verwalten. Der Datensatz rund um eine

15 Kapitel 2 Trouble Ticket Systeme 8 Störungsmeldung wird als Trouble Ticket bezeichnet. Trouble Ticket Management unterstützt alle Phasen des Fehlermanagements. Die erste Aufgabe ist das Erfassen einer Störmeldung. Diese Meldung kann telefonisch, per oder über ein Webformular erfolgen. Nimmt das Benutzerservice die Daten auf, so ist dies meist zuverlässiger und exakter, als bei Direkteingaben vom Störungsmelder. Die Effizienz eines Trouble Ticket Systems hängt primär von der Exaktheit und Vollständigkeit der Daten ab. Identität, Status, Benutzerdaten, Komponenten- und Dienstdaten, Zeitstempel, Fehlerdaten und Organisationsdaten gehören meist zu den vorgegebenen Feldern eines Trouble Tickets. Die Identifikationsnummer ist wesentlich für Nachfragen des Störungsmelders. Typische Werte für den Status sind "offen", "weitergeleitet", "in Bearbeitung", "wartend" oder "abgeschlossen". Komponenten- und Dienstdaten beschreiben von der Störung betroffenen Einheiten. Fehlerdaten beschreiben die aufgetretene Störung. Alle Einträge eines Trouble Tickets werden mit Zeitstempel versehen, dies ermöglicht es zeitliche Abläufe später nachvollziehen zu können. Benutzerdaten halten fest, wer die Störung gemeldet hat. Organisationsdaten enthalten zum Beispiel Angaben über Dringlichkeit oder Priorität und legen somit fest, in welchen Zeiträumen auf eine Störung zu reagieren ist. Je nachdem, in welchem Bereich ein Trouble Ticket System eingesetzt wird, gibt ein bestimmtes Domänenvokabular, welches sich in den Auswahllisten für die einzelnen Einträge wiederfindet. Allerdings sollte es immer die Möglichkeit für Freitexteingaben geben. Personendatenbanken im Hintergrund und Verfahren wie CTI (Computer Telefon Integration) erhöhen die Benutzbarkeit des Systems. Die eingetragenen Daten dienen zunächst zum Klassifizieren, zum Prioritäten setzen und zum Zuweisen. [Kruse 2001] Zunächst versuchen Mitarbeiter des 1 st Level Supports die Störung zu beheben. Gelingt dies nicht, dann leiten die Generalisten des 1 st Level Supports das Trouble Ticket an die Spezialisten im 2 nd Level Support weiter. Je länger eine Störung besteht und umso mehr Personen mit der Behebung einer Störung betraut sind, umso höher sind die Kosten. Daher wird angestrebt, dass die auftretenden Probleme vom 1 st Level Support gelöst werden. Wird ein Trouble Ticket weitergeleitet, dann kommt es zu einer Benachrichtigung (Notifikation). Oft besteht zwischen Benutzern eines Systems und Supportabteilung eine Dienstleistungsvereinbarung (DLV) oder ein Service Level Agreement (SLA). Werden beim Versuch Lösungen zu finden bestimmte Zeiten überschritten, dann wird die nächst höherer Supportebene informiert. Diesen Vorgang bezeichnet man auch als Eskalation. Um Eskalationen automatisiert ablaufen lassen zu können, bedarf es der bereits erwähnten Zeitstempel. [Kruse 2001] Ein weiterer wichtiger Bereich ist die Erstellung von Statistiken und Berichten. Diese zeigen ein Abbild des vom Benutzerservice betreuten Systems. Grundsätzlich gibt es zwei Betrachtungen. Zum einem gibt es eine Betrachtung des aktuellen Zustandes und zum anderen gibt es eine Betrachtung von langfristigen Trends. Statistiken und Berichte unterstützen den Betrieb eines Trouble Ticket Systems. Diese Statistiken liefern Hinweise zur Verbesserung des Fehlermanagements und versorgen das Management mit Daten. Bei der Betrachtung des aktuellen Zustandes sind vor allem die Zustände von Interesse, d.h. wie viele Tickets sind offen, gelöst oder in einem anderen Zustand. Man kann auch Aussagen über den Zustand des betreuten Systems machen. Wie lange läuft ein System fehlerfrei? Wie lange dauert die Behebung einer Störung im Durchschnitt? Man kann auch feststellen, wo in einem System latente Probleme liegen. [Kruse 2001]

16 Kapitel 2 Trouble Ticket Systeme 9 Während der Bearbeitung eines Trouble Tickets werden diesem laufend Informationen über die Problembehebung hinzugefügt. Im Laufe der Zeit baut sich so ein enormes Problemlösungswissen auf, auf welches die Mitarbeiter zurückgreifen können. Durch ein Trouble Ticket System kommt es zum erwünschten Transfer von Know-how von erfahrenen Mitarbeitern zu weniger erfahrenen Mitarbeitern. Das in den Trouble Tickets angehäufte Wissen hilft bei der Fehlerdiagnose und Fehlerbehebung ähnlicher Störungen. [Kruse 2001] Ein letzter wichtiger Punkt für Trouble Ticket Systeme ist es, die Korrelationen zwischen Trouble Tickets herauszufinden. Möglicherweise beschreiben verschiedene Trouble Tickets die gleiche Störung oder verschiedene Benutzer verschiedener Installationen haben die gleiche Störung gemeldet. Wird ein Trouble Ticket geschlossen, weil eine Lösung für die Störung gefunden wurde, ist es wesentlich zu wissen, welche Trouble Tickets mit geschlossen werden können. [Kruse 2001] 2.2 Abgrenzungsversuch Das Support Tracking System gehört zur Klasse der Trouble Ticket Systeme. Bei diesen Systemen wird zu jedem Fall ein Ticket angelegt, welches im Laufe der Zeit immer mehr Daten sammelt oder zumindest seinen Status ändert. Support Tracking Systeme sammeln Informationen, die zwischen den Kunden und den Supportmitarbeitern ausgetauscht werden. Ähnliche Systeme sind Problem Tracking Systeme (PTS), Bugtracking Systeme (BTS), Feature Request Systeme (FRS) und Knowledge Data Base Systeme (KDB), welche alle sehr häufig in der Softwarebranche Verwendung finden. Es findet sich fast jede Kombination der Marketingschlagworte Trouble, Problem, Bug, Request, Feature, Ticket, Tracking und System. Kann ein Kundenproblem vom Support nicht gelöst werden, so geht das Problem in ein Problem Tracking System ein. Probleme mit Softwareprodukten können viele Ursachen haben, wie etwa schlechte oder fehlerhafte Beschreibung in Handbüchern, oder falsche Bedienung durch den Benutzer. Nicht selten handelt es sich aber auch um Fehler im Programm selbst. Diese Fehler, meist als Bugs bezeichnet, werden dann in Bug Tracking Systeme gesammelt und in der Wartung behoben. Um die zahlreichen Ideen zur Verbesserung einer Software verwalten zu können, kommen sogenannte Feature Request Systeme zum Einsatz. Hier werden Ideen gesammelt, abgelehnt oder Releasezyklen zugeordnet. Für viele Probleme werden Lösungen oder Workarounds gefunden, die zusammen mit anderen Tipps und Tricks in einer Knowledge Data Base gesammelt werden können. Die verschiedenen hier beschrieben Systeme arbeiten oft Hand in Hand. Dabei kann es sein, das ein System mehrere Aufgaben übernimmt oder das für jede Aufgabe ein spezialisiertes System Verwendung findet. Gemeinsam haben diese Systeme, dass sie mit Tickets (Datensätzen) arbeiten und die im Laufe der Zeit gemachten Veränderungen speichern (Tracking). Kommen mehrere Systeme zum Einsatz, dann halten die Tickets eines Systems oft Referenzen auf Tickets eines anderen Systems. Dafür ist die Angabe von System und Ticketidentität ausreichend. Support, Problem, Bugtracking und Feature Request Systeme werden gerne, sowohl thematisch als auch in der Praxis, zusammengefasst.

17 Kapitel 2 Trouble Ticket Systeme 10 Eine weitere Betrachtung von Trouble Ticket Systemen besteht im Versuch sie mit anderen Anwendungen in Relation zu setzen. Helpdesk Anwendungen stellen den Mitarbeitern des Benutzerservices jene Information zur Verfügung, die sie zur Betreuung der Benutzer der IT Systeme eines Unternehmens brauchen. Trouble Ticket Systeme sind ein Teil einer Helpdesk Anwendung, aber Helpdesk Systeme haben noch darüber hinausgehende Funktionen. Nach ähnlichen Problemfällen suche zu können, ist für Mitarbeiter des Benutzerservices sehr hilfreich. Eine der größten Stärken vom Support Tracking System ist die Vielfalt an mächtigen Suchmöglichkeiten. Groupware Anwendung verteilen und organisieren die Arbeit innerhalb einer Gruppe. Beim Support Tracking System wird jedem Supportticket ein Mitarbeiter zugeordnet, werden s für Benachrichtigungen verwendet und Schedule Notes alarmieren die Mitarbeiter rechtzeitig, bevor Fristen ablaufen. Trouble Ticket Systeme können zumindest für den 1 st Level Support Groupware Funktionen teilweise abdecken. Cased Based Reasoning Systeme (CBR) versuchen mit Hilfe einer Fallbasis auf die Lösung für neue Probleme zu schließen. Zum einen könnte man ein Trouble Ticket System zu einem CBR System ausbauen und zum anderen müssen für ein CBR System eine ausreichende Zahl an Fällen gesammelt werden, wofür ein Trouble Ticket System wiederum gut geeignet ist. Knowledge Management Systeme sammeln und verteilen Wissen. Das Support Tracking System sammelt mit seinen Tickets eine Menge an Probleminformationen. In den gelösten Fällen sind auch die Lösungen erfasst. Die Suche des Support Tracking Systems erweißt sich als mächtiges Werkzeug. Die Suchstärke stammt vom zu Grunde liegenden Hyperwave Information Server. Customer Relationship Management (CRM) ist ein Feld, in welches viele Hersteller von Trouble Ticket Systemen mit ihren Produkten versuchen einzudringen. Zahlreiche Trouble Ticket Systeme sind an der Schnittstelle zwischen Unternehmen und Kunden im Einsatz. Der Versuch eine Abgrenzung für Trouble Ticket Systeme zu finden ist in zweierlei Hinsicht mit Schwierigkeiten verbunden. Zum einem verwenden die verschiedenen Hersteller unterschiedliche Bezeichnungen für ihre Systeme. Dies erschwert die Einordnung der verfügbaren Systeme. Zum anderem werden Trouble Ticket Systeme nicht nur im Helpdesk Bereich verwendet. Über den Kernbereich von Trouble Ticket Systemen hinausgehende Funktionalität eröffnet den Einsatz in anderen Bereichen. Diese Bereiche können Groupware, Cased Based Reasoning, Knowledge Management oder Customer Relationship Management sein. 2.3 Support Tracking System Am Institut für Informationssysteme und Computer Medien (IICM), ein Institut der Technischen Universität Graz, wurde ein Trouble Ticket System mit dem Namen Support Tracking System (STS) entwickelt. Das Support Tracking System ist bei der Firma Hyperwave in München im Bereich Kundensupport in Verwendung. Mit dieser Arbeit wurde die Version STS V1.3 erreicht, dabei handelt es sich um eine Version, die vom Administrator einer STS V1.3 Installation in mehreren Breichen selbstständig

18 Kapitel 2 Trouble Ticket Systeme 11 veränderbar ist. Wartungsarbeiten konnten damit vom Entwickler der Software zum Anwender verlagert werden. Diese neuen Möglichkeiten zur Adaptierung werden im Kapitel 5 und Kapitel 6 im beschrieben. Dieser Abschnitt beschreibt überblicksartig die Eigenschaften und Funktionsbereiche von STS V1.3 und seinen Vorgängern. Eine detaillierte Beschreibung der Funktionen vom Support Tracking System findet sich im Abschnitt Die Verwaltung von Benutzern, Kunden, Tickets und Einträgen in Tickets bilden die großen funktionalen Einheiten des Systems. Die große Stärke vom Support Tracking System ist die Suche. Automatische benachrichtigungen und Verwendung von Webtechnologien als Basistechnologie sind weitere Stärken. Unter dem Begriff Benutzerverwaltung summieren sich all die Aufgaben, die anfallen, wenn es gilt Personen und deren Zugriffsrechte zu bearbeiten. Mitarbeiter können angelegt und deren Daten geändert werden. Jedem Mitarbeiter der Zugriff auf das Support Tracking System erhält, wird eine bestimmte Rolle (Administrator, Dispatcher oder Support) zugeteilt. Die Ticketverwaltung ist die Hauptaufgabe eines jeden Trouble Ticket Systems und somit auch vom Support Tracking System. Es können Supporttickets angelegt, verändert und gelöscht werden. Jedes Ticket sammelt eine Reihe von Daten über den betroffenen Kunden, seine eingesetzte Software und sein Problem. Ein Ticket entspricht immer genau einem Support Fall und es bildet den Rahmen für die Ticketeinträge. Ticketeinträge bilden den Kommunikationsprozess des Supportmitarbeiters mit dem Kunden im System ab. Die Ticketeinträge können s, Telefongesprächsnotizen oder Notizen sein. Letztere unterteilen sich auch noch in gewöhnliche Notizen, Aufgabenlisten, Frage-Antwort und Zusammenfassungen. Ein vierter Typ von Ticketeinträgen erlaubt es auch zeitliche Abläufe ins System einzubringen. Dieser vierte Typ erinnert den Supportmitarbeiter an Termine. Ticketeinträge können angelegt, geändert und gelöscht werden und gehören explizit zu einem Trouble Ticket. Eine sehr starke Eigenschaft vom Support Tracking System ist, dass der gesamte verkehr zwischen Kunden und Supportmitarbeiter innerhalb des Systems erfolgt. Der gesamte Kommunikationsverlauf mit dem Kunden wird protokolliert. Das Support Tracking System ist in der Lage selbstständig s vom Kunden den entsprechenden Tickets zuzuordnen. Dabei wird lediglich vorausgesetzt, dass der Kunde bestimmte Teile der überschrift nicht verändert. Die zweite nicht unwesentliche Eigenschaft vom Support Tracking System ist, dass das System vollständig mit Webclients (Microsoft Internet Explorer oder Netscape Navigator) bedienbar ist. Deshalb ist clientseitig keine Softwareinstallation notwendig. Da die meisten Benutzer mit dem Umgang von Webbrowsers vertraut sind, ist der Aufwand für die Einarbeitung gering. Die größte Stärke von Support Tracking System ist sicherlich die umfangreiche Suche. Das Support Tracking System profitiert von der Stärke des zugrundeliegenden Hyperwave Information Servers (HWIS) auf diesem Gebiet. Es stehen sowohl Queryobjekte, eine Besonderheit des Hyperwave Information Servers, als auch ein umfangreiches Suchformular zu Verfügung. Mit Hilfe der Queryobjekte lassen sich zum Beispiel alle Fälle eines Kunden finden. Mit der Suchfunktion ist es möglich ähnliche Problemfälle aufzufinden.

19 Kapitel 2 Trouble Ticket Systeme Übersicht verfügbarer Systeme Eine sehr gute Möglichkeit sich über Trouble Ticket Systeme zu informieren ist die Newsgroup comp.software.config-mgm. Diese Gruppe hat Configuration Management in der Softwareentwicklung zum Ziel. Dies mag im ersten Augenblick verwundern, bedenkt man aber, dass aus Supportfällen Problemfälle werden und diese möglicherweise Bugs sind, dann wird sehr rasch klar, dass oft Software verändert werden muss um ein Problem zu lösen. Insofern scheint Software Configuration Management den richtigen Kontext darzustellen. Tatsache ist das zum Thema Trouble Ticket Systeme in dieser Newsgroup geschrieben wird. Weiters gibt es zu dieser Newsgroups sehr gute FAQ Seiten, die monatlich ein Update erfahren. [Eaten 2002] In den Anhängen A und B dieser Arbeit findet man je eine Liste über freie und kommerzielle Systeme. Keine der beiden Listen erhebt den Anspruch der Vollständigkeit. Dies ist schon aus dem Grund nicht möglich, da der Begriff Trouble Ticket System sich nicht hinreichend genau beschreibbar ist. In den beiden nachfolgenden Kapiteln werden jeweils vier Vertreter kurz beschrieben. 2.5 Nichtkommerzielle Produkte Es gibt einige wenige freiverfügbare Trouble Ticket Systeme. Im Gegensatz zu den kommerziell vertriebenen Systemen ist sowohl die Anzahl der Systeme, als auch der Funktionsumfang der einzelnen Systeme kleiner. Die hier vorgestellten Systeme sind Bugzilla, Debian Bug Tracking System (debbugs), GNATS und Double Choco Latte. Die ersten drei Systeme sind auf den Einsatz im Bereich Bugtracking bei Opensource Projekten zugeschnitten. Double Choco Latte geht über das reine Bugtracking hinaus und enthält Ansätze einer Groupware Software. Freie Trouble Ticket Systeme, die auf die Aufgaben im Supportbereich spezialisiert sind, konnten nicht gefunden werden. Beim Support Tracking System bestand die Überlegung, das System soweit anzupassen, dass es für das Institut für Informationssysteme und Computer Medien als Bug Tracking System einsetzbar ist. Bei Opensource Projekten gibt es meist keine Supportabteilungen, die Störmeldungen entgegennehmen. Dies ist ein Grund, warum in diesem Bereich die Bug Tracking Systeme öffentlich zugänglich sind und so auch Funktionen eines Trouble Tracking Systems übernehmen Bugzilla Bugzilla 5 ist eines der bekanntesten Bug Tracking Systeme und ist unter der Mozilla Public License verfügbar. Es hilft Entwicklern noch offene Fehler eines Systems zu verwalten. Bugzilla wurde ursprünglich mit TCL entwickelt und später erfolgte ein Wechsel von TCL zu Perl. Bugzilla ist ein Open Source Projekt und gilt als Standard unter den Bug Tracking Systemen. Bugzilla erlaubt eine Produkt- oder Projektorientierung. Abhängigkeiten von Bugs untereinander können graphisch 5

20 Kapitel 2 Trouble Ticket Systeme 13 dargestellt werden. Das System verfügt über fortgeschrittene Möglichkeiten zur Reporterstellung. Umfangreiche Möglichkeiten zur Konfiguration des Programms sind vorhanden. Ein gut durchdachtes und leicht verständliches "bug resolution protocol" wurde umgesetzt. Bugzilla unterstützt Formate und XML Formate zur Fehlerberichterstattung. Weiter Zugriffsmöglichkeiten sind über Konsole oder Webbrowser gegeben. Für die Anbindung zu Konfigurationswerkszeugen wie Perforce 6, Bonsai 7 oder CVS 8 ist gesorgt. Robustheit und Popularität sind die großen Vorteile von Bugzilla. Bugzilla ist allerdings auf eine bestimmte Datenbank (mysql 9 ) angewiesen. Für die Benutzeroberfläche und für die Programmlogik gibt es keine Abstraktionsebene. s werden für Benachrichtigungen verwendet. Die Abfragemechanismen sind mächtig aber gewöhnungsbedürftig. Die Reporterstellung lässt sich nur geringfügig konfigurieren. Mechanismen zur Internationalisierung sind nur geringfügig vorhanden. Die Abhängigkeit von nicht standardisierten Bibliotheken ist eine weiter Schwäche von Bugzilla. Dennoch ist Bugzilla sowohl in der Hardwareals auch in der Software-Entwicklung beliebt. Bugzilla wird in zahlreichen Open Software Projekten (Mozilla, Linux Kernel, Gnome, KDE, Apache, Open Office), bei Linuxdistributoren (Red Hat, Mandrake, Gentoo, Turbo Linux) und bei vielen Firmen (Ximian, NASA, Id Software, IBM) eingesetzt. [Mozilla Organisation 2003] Debian Bug Tracking System (debbugs) Debian Bug Tracking System (debbugs) 10 wurde für das Debian Projekt 1994 entwickelt. Es ist unter GNU General Public License (GPL) Bedingungen verfügbar. GPL wurde von der Free Software Foundation (FSF) 11 veröffentlicht. Das System debbugs besteht aus Perl Skripts, die Problemreporte in einer Datenbank verwalten. Anstatt der Begriffe Bug, Problem oder Ticket spricht man bei debbugs von einem Report. Das System benötigt ein UNIX Betriebssystem und einen eigenen Maildomain. Verschiedene systeme sind verwendbar. Anlegen eines Reports als auch alle anderen Manipulationen an Reports erfolgen mittels s. Somit sind für die Benutzer weder Zugang zum Hostsystem noch Webzugang notwendig. Listen bestehend aus Reports, die den gleichen Status haben, können sowohl über Webbrowser als auch über s gespiegelt werden. Jeder Report bekommt als Identität eine eigene adresse. Mit Hilfe von s können einfach zusätzliche Informationen zu einem Report abgelegt werden. Beim Debian Projekt stellte das System seine Leistungsfähigkeit unter Beweis. Im Laufe von sechs Jahren wurden über Reporte verwaltet. Im Jahr 1999 waren gleichzeitig 5000 Reporte im System und benötigen rund 300 MB Speicherplatz in der Datenbank. Seit 1997 ist debbugs durch Parametrisierung anpassungsfähig. Zu debbugs Kernfunktionalität zählen Anpassung an Projektbedürfnisse und die mechanismen. Verwendung fand debbugs bisher bei