Kapitel 6 Adaptierbare Benutzeroberfläche
Werbung
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: o.Univ.-Prof. Dr. Dr.h.c.mult. Hermann Maurer Betreuer: Dipl.-Ing. Dr.techn. Christian Gütl Dipl.-Ing. Helmut Leitner Meinen Eltern Theresia und Anton und meiner Lebensgefährtin Evelyn. 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. 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. 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. Inhaltsverzeichnis Kapitel 1 Einleitung ............................................................................................................. 1 1.1 1.2 1.3 Motivation .......................................................................................................................... 1 Problemumfeld ................................................................................................................... 2 Struktur der Arbeit .............................................................................................................. 3 Kapitel 2 Trouble Ticket Systeme ...................................................................................... 6 2.1 2.2 2.3 2.4 2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.6 2.6.1 2.6.2 2.6.3 2.6.4 2.7 Anforderungen an Trouble Ticket Systeme ........................................................................ 6 Abgrenzungsversuch .......................................................................................................... 9 Support Tracking System ................................................................................................. 10 Übersicht verfügbarer Systeme......................................................................................... 12 Nichtkommerzielle Produkte ............................................................................................ 12 Bugzilla............................................................................................................................ 12 Debian Bug Tracking System (debbugs) ......................................................................... 13 GNATS ............................................................................................................................ 14 Double Choco Latte ......................................................................................................... 14 Kommerzielle Produkte .................................................................................................... 15 Rational ClearQuest ......................................................................................................... 15 Rational ClearDDTS........................................................................................................ 15 Aegis Defect Tracking ..................................................................................................... 16 OmniTracker .................................................................................................................... 17 Zusammenfassung ............................................................................................................ 18 Kapitel 3 Wartungsprozess ............................................................................................... 20 3.1 3.2 3.2.1 3.2.2 3.3 3.4 3.5 Softwarewartung ............................................................................................................... 20 Agile Software Prozesse ................................................................................................... 24 Meta Prozesse .................................................................................................................. 26 Konkrete Prozesse ........................................................................................................... 28 eXtreme Programming (XP) ............................................................................................. 30 Refaktoring ....................................................................................................................... 32 Zusammenfassung ............................................................................................................ 34 Kapitel 4 Systembeschreibung .......................................................................................... 36 4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.4 Hyperwave Information Server ........................................................................................ 36 HWLIB ............................................................................................................................. 38 Support Tracking System im Überblick ........................................................................... 41 Hauptfunktionen aus Benutzersicht ................................................................................. 41 Architektur des Support Tracking Systems ..................................................................... 47 Funktionalität des Support Tracking Systems ................................................................. 49 Zusammenfassung ............................................................................................................ 52 Kapitel 5 Adaptierbare Systemeigenschaften ................................................................. 54 5.1 Allgemeines ...................................................................................................................... 54 Inhaltsverzeichnis 5.2 5.3 5.4 5.5 5.6 5.7 5.8 Werte für die Ticketattribute ............................................................................................ 55 Kundendatenbank ............................................................................................................. 58 Rollenabhängige Funktionalität ........................................................................................ 59 Eskalationszeiten .............................................................................................................. 64 Implementierung ............................................................................................................... 64 Kundenbenachrichtigung .................................................................................................. 66 Zusammenfassung ............................................................................................................ 67 Kapitel 6 Adaptierbare Benutzeroberfläche ................................................................... 68 6.1 6.2 6.3 6.3.1 6.3.2 6.3.3 6.4 6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.4.6 6.4.7 6.5 6.6 Ausgabe unter STS V1.2 .................................................................................................. 68 Ausgabe unter STS V1.3 .................................................................................................. 70 STS Tags........................................................................................................................... 71 insert_data ........................................................................................................................ 71 insert_functionresult ........................................................................................................ 72 insert_actionlink und insert_href ..................................................................................... 75 HTML Vorlagen ............................................................................................................... 75 sts_base ............................................................................................................................ 76 sts_ticketobject_object ..................................................................................................... 79 sts_ticketobject_content ................................................................................................... 81 sts_noteentry .................................................................................................................... 82 sts_phonenoteentry .......................................................................................................... 84 sts_schedulenoteentry ...................................................................................................... 85 sts_emailentry .................................................................................................................. 85 Implementierung ............................................................................................................... 87 Zusammenfassung ............................................................................................................ 90 Kapitel 7 Erkenntnisse ...................................................................................................... 91 7.1 7.2 7.3 Trouble Ticket Systeme .................................................................................................... 91 Wartung und agile Softwareprozesse ............................................................................... 91 Adaptierbare Webapplikation ........................................................................................... 93 Kapitel 8 Zusammenfassung ............................................................................................. 95 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 Graz2 wurde ein solches System mit dem Namen Support Tracking System (STS) für Hyperwave3 entwickelt. Das Support Tracking System ist eine Hyperwave Information Server basierende Intranet Webapplikation. Hyperwave erkannte die 1 http://www.iicm.edu http://www.tugraz.at 3 http://www.hyperwave.com 2 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. 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, E-Mails 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 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. I. Untersuchungsbereich 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 E-Mails 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] 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 Fehlerdiagnose Fehlerbehebung - Erfassung - Diagnosemaßnahmen - Behebungsmaßnahme - Klassifizierung - Weiterleitung - Schließen der Störmeldung - Zuweisung - Eskalation - Rückmeldung Dokumentation 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 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 E-Mail 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 1st Level Supports die Störung zu beheben. Gelingt dies nicht, dann leiten die Generalisten des 1st Level Supports das Trouble Ticket an die Spezialisten im 2nd 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 1st 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] 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. 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 E-Mails für Benachrichtigungen verwendet und Schedule Notes alarmieren die Mitarbeiter rechtzeitig, bevor Fristen ablaufen. Trouble Ticket Systeme können zumindest für den 1st 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 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 4.3.3. 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 E-Mailbenachrichtigungen 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 E-Mails, 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 E-Mailverkehr 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 E-Mails vom Kunden den entsprechenden Tickets zuzuordnen. Dabei wird lediglich vorausgesetzt, dass der Kunde bestimmte Teile der E-Mailü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. Kapitel 2 Trouble Ticket Systeme 12 2.4 Ü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. 2.5.1 Bugzilla Bugzilla5 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 dargestellt werden. Das System verfügt über fortgeschrittene Möglichkeiten zur 5 http://www.bugzilla.org Kapitel 2 Trouble Ticket Systeme 13 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 E-Mail Formate und XML Formate zur Fehlerberichterstattung. Weiter Zugriffsmöglichkeiten sind über Konsole oder Webbrowser gegeben. Für die Anbindung zu Konfigurationswerkszeugen wie Perforce6, Bonsai7 oder CVS8 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. E-Mails 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] 2.5.2 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 E-Mailsysteme sind verwendbar. Anlegen eines Reports als auch alle anderen Manipulationen an Reports erfolgen mittels E-Mails. 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 E-Mails gespiegelt werden. Jeder Report bekommt als Identität eine eigene E-Mailadresse. Mit Hilfe von E-Mails 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 16000 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 E-Mailmechanismen. Verwendung fand debbugs bisher bei den Projekten Debian GNU/Linux, GNOME, KDE und bei der Firma nCipher. [Benham 1999][Jackson 1994] 6 http://www.perforce.com/ http://www.mozilla.org/projects/bonsai/ 8 http://www.cvshome.org/ 9 http://www.mysql.com/ 10 http://www.benham.net/debbugs 11 http://www.gnu.org/ 7 Kapitel 2 Trouble Ticket Systeme 2.5.3 14 GNATS GNU GNATS12 ist ein weiteres Bug Tracking System unter GPL. GNATS ist eine Sammlung von Werkzeugen zur zentralen Verwaltung von Problemberichten. Problemberichte werden über Kategorien zu Gruppen zusammengefasst. Kernaufgaben sind die Verwaltung der Problemberichte und die Kommunikation über diese auf vielfältige weise. Der E-Mailverkehr wird archiviert und für die Suche indiziert. Alle Berichte werden in einer Datenbank gespeichert und Abfrage-, Editier- und Wartungswerkzeuge greifen auf diese Datenbank zu. GNATS bietet Zugriffsmöglichkeiten über Befehle für die Kommandozeile, E-Mail, Emacs, Tcl/Tk und einem Webinterface (CGI, Perl, Python) an. Sowohl die Datenbankeinträge als auch die Konfigurationen des Systems werden in Textdateien abgelegt. Dies führt zu einer einfachen Benutzbarkeit und einer hohen Flexibilität. Die Möglichkeiten Felder anpassen können, verschiedene Datenbanken zu verwenden und umfassende Web- und Tcl-Benutzerschnittstellen kamen mit GNATS V4.0 im August 2003 dazu. Die Entwicklung an der Webbenutzerschnittstelle Gnatsweb ist abgeschlossen. GNATS zählt zu den robustesten Systemen. Es wird unter anderem auch für das GNU Projekt selbst verwendet. [Free Software Foundation 2003][Free Software Foundation 2000][Free Software Foundation 2000b] 2.5.4 Double Choco Latte Ein weiteres unter GPL verfügbares System ist Double Choco Latte13. Kernkonzept sind sogenannte "Work Orders", die für die zeitliche Verfolgung von Fehlern, Anfragen, Wartungsaufgaben und Projektaufgaben verwendet werden. Projekte werden in einer hierarchischen Struktur verwaltet und Projektstatistiken schließen die Unterprojekte mit ein. Sogenannte "Call Tickets" repräsentieren den Kontakt mit Kunden. Aktionen, Prioritäten und Status sind als Attribute vorhanden, aber jedes Projekt kann einen eigenen Satz an Attributen für "Work Orders" und "Call Tickets" verwenden. "Severities" legen fest wie schwerwiegend ein Ticket ist, "Priorities" mit welcher Priorität ein Ticket bearbeitet wird und "Statuses" gibt den aktuellen Status eines Tickets bekannt. Projektmitarbeiter können über "Departments" hierarchisch verwaltet werden. Zusammengehörende Aufgaben bekommen ansteigende Aufgabennummern. Die dadurch entstehende Reihenfolge kann für Projekte verwendet werden. Bei Double Choco Latte besonders ausgeprägt ist die Möglichkeit mit E-Mail Benachrichtigungen zu arbeiten. Benachrichtigungen erfolgen bei Statuswechsel (Open, Close, Changed) und werden für die Überwachung von Aktivitäten, Produkten und Projekten verwendet. Weiters werden sie für die Beobachtung von Arbeitsreihenfolgen, Tickets und Abweichungen in Projekten angewandt. Ein Reportgenerator kann auch statische Berichte erstellen. Double Choco Latte kann sowohl als alleinstehendes System betrieben werden oder als Bestandteil von phpGroupWare14. [Free Software Foundation 2004] 12 http://www.gnu.org/software/gnats http://dcl.sourceforge.net/index.php 14 http://phpgroupware.org 13 Kapitel 2 Trouble Ticket Systeme 15 2.6 Kommerzielle Produkte Im Vergleich zu den frei verfügbaren Trouble Ticket Systemen ist die Anzahl der kommerziell verfügbaren Systeme sehr groß. Eine Liste, ohne Anspruch auf Vollständigkeit, findet sich im Anhang B unter Kommerzielle Produkte. Ein wesentlicher Unterschied zu den frei verfügbaren Systemen besteht im viel größeren Funktionsumfang. Vorgestellt werden ClearQuest und ClearDTTS. Beide sind Trouble Ticket Systeme vom Hersteller Rational. Danach folgen Aegis Defect Tracking und OmniTracker, die beide umfangreiche Systeme zur Kundenbetreuung darstellen. 2.6.1 Rational ClearQuest Ein Vertreter aus der großen Anzahl von kommerziellen Trouble Ticket Systemen kommt von der IBM15 Tochter Rational16. ClearQuest17 ist ein flexibles System zur Verfolgung von Defekten und Änderungswünschen. Primär soll es Herstellern von Software beim Entwicklungsprozess unterstützen. Die Benutzeroberflächen für Windows, UNIX und Webbrowser sind vollständig vom Kunden an die jeweiligen Bedürfnisse anpassbar. Weiters sind Eintragsfelder und der Workflow an jeden Entwicklungsprozess anpassbar. Es handelt sich um ein "out-of-the-box" System. EMails werden sowohl zur Benachrichtigung als auch für die Eingabe von neuen Fällen verwendet. Abfragen, Berichte und Charts werden unterstützt. Rational ClearQuest baut auf Industriestandarddatenbanken auf und skaliert für alle Projektgrößen sehr gut. Für geographisch verteilte Entwicklungsteams gibt es einen Replizierungs- und Synchronisationsmechanismus. Für Entwickler von Software ist es sehr angenehm, dass Rational ClearQuest sich in die integrierten Entwicklungsumgebungen WebSphere Studio18, Eclipse19 und Visual Studio .NET20 einfügt. Rational ClearQuest arbeitet natürlich mit der Rational Suite zusammen und unterstützt Rational's Unified Change Management Ansatz. Zusammen mit Rational ClearCase bildet ClearQuest ein vollständiges Software Configuration Management Werkzeug. [IBM 2004] 2.6.2 Rational ClearDDTS Neben ClearQuest vertreibt Rational auch noch das Produkt ClearDDTS 21. Auch dieses Produkt dient zur Verfolgung und Verwaltung von Fehlerberichten und 15 http://www.ibm.com/ http://www.ibm.com/software/rational/ 17 http://www.ibm.com/software/awdtools/clearquest/ 18 http://www.ibm.com/software/webservers/studio/ 19 http://www.eclipse.org/ 20 http://msdn.microsoft.com/vstudio/using/default.aspx 21 http://www-306.ibm.com/software/awdtools/clearddts/ 16 Kapitel 2 Trouble Ticket Systeme 16 Verbesserungsanfragen. ClearDDTS beschränkt sich aber auf die Kommunikation zwischen Testern und Entwicklern und ist auf die Entwicklung im UNIX Umfeld spezialisiert. Die Möglichkeit zur Anbindung an Rational ClearCase erlaubt effektives Management von Veränderungen innerhalb des Software Entwicklung Prozesses. Durch die Verwendung eines Webzuganges ist es für verschiedene Plattformen verwendbar und erlaubt auch geografisch verteilten Entwicklern den Zugang zum System. Auch bei ClearDDTS ist es möglich mittels E-Mails neue Einträge zu machen und umgekehrt verwendet das System E-Mails zur Benachrichtigung bei Veränderungen. Oracle wird als Datenbanksystem unterstützt, aber es wird auch eine eigene SQL-fähige Datenbank mitgeliefert. Über 40 verschiedene Managementberichte sind die große Stärke dieses Systems. Es ist zu erwaten, dass Rational ClearDDTS hinter ClearQuest zurückstellen wird. [IBM 2004b] 2.6.3 Aegis Defect Tracking Abacus Systems22 bietet mit Aegis Help Desk, Aegis Defect Tracking23, Aegis Client Management und Web Front End eine ganze Programmfamilie rund um die Kundenbetreuung an. Da dies über das Feld Trouble Ticket Systeme weit hinaus geht, soll hier nur Aegis Defekt Tracking näher betrachtet werden. Die Aegis Programme von Abacus Systems sind nicht zu verwechseln mit dem Sourceforge Projekt Aegis24, welches sich mit Konfigurationsmanagement in der Softwareentwicklung beschäftigt. Die automatische Benachrichtigung durch E-Mails erfolgt sowohl, wenn ein Ereignis den gesamten Datensatz betrifft als auch, wenn sich nur ein einzelne Feldeintrage ändern. Die Benachrichtigungen sind vollständig anpassbar und personalisierbar. Die Möglichkeit alle Kunden oder Kundengruppen zu verständigen ist eine weitere bemerkenswerte Eigenschaft des Benachrichtigungssystems. Sind genügend Einträge mit Lösungen vorhanden, dann kann Aegis Defect Tracking automatisch eine durchsuchbare Wissensbasis aufbauen. Dabei wird für jeden Fall automatisch ein beschreibender Artikel erstellt. Die Kundenverwaltung wird sehr ernst genommen. Zu jedem Kunden können beliebig viele Kontakte verwaltet werden. Telefonnummerlisten, E-Mailadresslisten und Kontaktadressenlisten sind herstellbar. Außerdem werden alle von einem Kunden gekauften Produkte gespeichert. Der Berichtgenerator kann zusammenfassende Berichte oder graphische Darstellungen erstellen. Dabei werden Größen betrachtet wie "Wie lange dauerte die Lösung?", "Wie alt ist ein Fall?" oder "Wie groß war der geschätzte Aufwand und wie groß ist der tatsächliche Aufwand?". Die Sortierreihenfolge ist benutzerdefiniert und es gibt verschiedene Ansichten. Sehr mächtig sind die eingebauten Möglichkeiten zur Filterung. So kann man zum Beispiel Filter verwenden um herauszufinden, mit welchen Problemen welche Entwickler beschäftigt sind oder um bestimmten Kunden als Gruppe E-Mails zu schicken. Aegis Defect Tracking ist vollständig adaptierbar. Zum Beispiel gibt es Werkzeuge um Formulare oder Eintragsfelder zu bearbeiten. Für verschiedene Benutzer sind verschiedene Formulare herstellbar. [Abacus 1998] 22 http://www.abacus-systems.com/ http://www.abacus-systems.com/AegisDT.htm 24 http://aegis.sourceforge.net/ 23 Kapitel 2 Trouble Ticket Systeme 2.6.4 17 OmniTracker OmniTracker25 ist ein kommerzielles Produkt aus Deutschland. Auffallend bei diesem System ist der sehr große Funktionsumfang. Helpdesk, Callcenter, Customer Relationship Management (CRM), Qualitätsmanagement, Aktivitätsmanagement, Problemmanagement, Änderungsmanagement, Kundenservice, Vertriebsunterstützung und Kontaktmanagement sind die Bereiche, die vom Hersteller als Einsatzbereiche genannt werden. Dies zeigt zum einen die Mächtigkeit der Trouble Ticket Systeme, aber zum anderen auch wie der Begriff Trouble Ticket System etwas zu kurz greift. Das System baut auf Microsoft Windows Systemen auf und verwendet für das Webinterface den Internet Explorer. Neue Tickets können über Telefon, E-Mail, Telefax oder Webzugang ins System eingebracht werden. Das System ist einfach zu konfigurieren, zu administrieren und handhabbar. Eine Anpassung an einen Kunden ist in 5-8 Tagen machbar. Zu den wichtigen Kernfunktionen zählen Konfigurierbarkeit, Volltextsuche, regelgesteuerte Filter, Statistiken und eine Schnittstelle für eigene Programmerweiterungen. Konfiguration erfolgt nicht mittels Skripts, sondern über Dialoge. Konfiguration erfolgt auf Ordnerebene und wird an Unterordner vererbt. Workflow, Datenmodell, Benachrichtigung, Eskalationsmodell, Benutzerrechte und Statistiken sind weitere konfigurierbare Elemente. Der Workflow regelt Übergänge zwischen Zuständen auf Ordnerebene. Durch den Workflow wird der Prozess zwischen Kunden, Qualitätssicherung, Vertrieb und Marketing einerseits und Produktherstellern andererseits gesteuert. Bei der benutzerdefinierten Datenmodellierung stehen gängige Datentypen, Nummerierungsschemata und Dropdownlisten zur Verfügung. Weitere Möglichkeiten bei der Datenmodellierung sind Referenzen, Referenzlisten und Relationen (1:1, 1:n, m:n). Für die Bereiche ITIL konformes Servicemanagement, Inventarisierung (SW, HW), Vertragsdaten (Service Level Agreement), Kundenverwaltung (CRM) und Versions- und Konfigurationsmanagement gibt es vordefinierte Datenmodelle. Benachrichtigungen erfolgen regelbasierend, wobei zwischen Benutzer und Benutzergruppen unterschieden werden kann. Auslösende Ereignisse können ein neuer Eintrag oder das Verändern eines Feldes eines Eintrages sein. Benachrichtigung erfolgt entweder über SMTP, MAPI, Telefax oder in Briefform. Die Eskalationssteuerung kann sowohl durch zeitliche Abläufe als auch durch logische Zusammenhänge gesteuert werden. Die Regeln werden mit dem Regeleditor erstellt und können dazu führen, dass Inhalte modifiziert werden, E-Mails versand werden, Betriebssystemkommandos oder Skripte ausgeführt werden. Benutzerrechte werden, mit Hilfe eines Editors für Zugriffsrechte, für den einzelnen Benutzer oder für Gruppen auf Ordnerebene vergeben. Diese Rechte schließen verschiedene Sichten mit ein und können auch auf Feldebene ausgedehnt werden. Benutzerverwaltung umfasst die Vergabe von Rechten, E-Mailadressen und Passwörtern. Ein eigener Formulareditor erlaubt das Erstellen von Dialogen, wobei über sogenannte Controls Zeichensätze, Farben, Schriftgrößen, Positionen bestimmt werden. Der Formulareditor beherrscht auch die Zuordnung von Attributen zum Datenmodell und ermöglicht auch das Einbinden von Skripten zur clientseitigen Formularprüfung. Für jeden Ordner können beliebig viele Formularansichten erstellt werden. Eine integrierte Volltextsuchmaschine erlaubt auch das Durchsuchen von Dateianhängen (MS Word, MS Excel) und unterstützt logische Verknüpfungen. Im Gegensatz zu den nichtkommerziellen 25 http://www.omninet.de/ Kapitel 2 Trouble Ticket Systeme 18 Produkten gibt es hier auch eine fehlertolerante Suche. Filterregeln operieren auf Ordnerebene und sind Benutzer bzw. Benutzergruppen abhängig. Filterregeln können gespeichert werden und können mit Objektreferenzen (1:1, 1:n, m:n) umgehen. Statistiken sind wiederum auf Ordner, Benutzer oder Benutzergruppen zugeschnitten. Es gibt drei Arten von Statistiken. Schnappschussstatistiken zeigen den aktuellen Stand des Datenbestandes, Verlaufsstatistiken zeigen die Veränderungen über die Zeit und schließlich die Durchsatzstatistiken. Zur Darstellung der Statistiken können Tabellen, 2D/3D Balkendiagramme, 2D/3D Tortendiagramme und 2D/3D "gestapelte" Balkendiagramme verwendet werden. Durch Benutzung von ActiveX- bzw. OLE Objekten ist es Visual Basics, C++, VBScript und JavaScript Programmieren möglich das Produkt zu erweitern und weiter anzupassen. Eine spezielle DLL wird vom Hersteller zur Verfügung gestellt. [OmniNet 2001] 2.7 Zusammenfassung Trouble Ticket Systeme werden zur Verfolgung von Fehlern, Störungen oder Problemen verwendet. Das zentrale Element dieser Systeme sind die Trouble Tickets, wovon jedes genau einen Störfall beschreibt. Aufgabe eines Trouble Tickets ist es den Lebenszyklus einer Störung von der Entdeckung über die Eingrenzung bis hin zur Lösung zu dokumentieren. Für den Supportbereich bedeutet dies, das der gesamte Kommunikationsverlauf zwischen Störungsmelder und Bearbeiter dokumentiert wird. Kernaufgabe der Trouble Ticket Systeme ist das Fehlermanagement bestehend aus Fehlererhebung, Fehlerdiagnose und Fehlerbehebung. Weitere Aufgaben sind die Erstellung von Statistiken und Berichten und das Auffinden von korrelierenden Trouble Tickets. Das Support Tracking System ist ein auf den Kundensupport spezialisiertes Trouble Ticket System. Trouble Ticket Systeme werden gewöhnlich den Helpdesk Anwendungen zugeordnet, weißen aber auch Merkmale von Groupware Systemen, Cased Based Reasoning Systemen, Knowledge Management Systemen oder von Customer Relationship Management Systemen auf. Trouble Ticket Systeme treten unter den verschiedensten Bezeichnungen auf und haben verschiedenste Einsatzgebiete. Adaptierbare Systeme können mehrere Gebiete abdecken. Alle untersuchten Systeme entstammen dem Fehlermanagement für Softwareprojekte. Die nicht kommerziellen Systeme decken nach wie vor nur den Fehlermanagementbereich für Softwareentwicklung ab. Den kommerziellen Systemen ist es gelungen, durch starke Erweiterung der Funktionalität weitere Anwendungsfelder zu erschließen. Es gibt mehr kommerzielle als nichtkommerzielle Systeme und der Funktionsumfang ist bei den kommerziellen Systemen deutlich höher. Alle untersuchten Systeme betrachten Kommunikation als das zentrale Element. Unter den untersuchten Systemen ist keines, dass die Kommunikation über E-Mails nicht unterstützen würde. Fast alle Systeme haben eins webbasierendes Benutzerschnittstelle. Die meisten Systeme bieten Möglichkeiten zur Adaptierung der Ticketfelder, des Workflows und der Benutzerschnittstelle an. Ein Zeichen dafür, das auch das Support Tracking System diese Möglichkeiten besitzen sollte. Auch das Support Tracking System ist Veränderungen und Anpassungen unterworfen. Kapitel 3 beschreibt die verschiedenen Wartungsarten und untersucht ob agile Softwareentwicklungsprozesse für die Wartungsphase einen Vorteil darstellen. Die Kapitel 2 Trouble Ticket Systeme 19 Kapitel 5 und Kapitel 6 zeigen, dass die Adaptierbarkeit eines Programms die Änderungs- und Anpassungsarbeiten reduzieren kann. Kapitel 3 Wartungsprozess Dieses Kapitel beschäftigt sich mit jener Phase im Software Lebenszyklus, die mit der Auslieferung der Software beginnt. Ist die Software installiert und beim Anwender in Produktion, werden nun früher oder später die Schwächen der Anwendung sichtbar. Diese Schwächen können Fehler in der Software, geänderte Anforderungen oder Erweiterungswünsche sein. Das Support Tracking System befand sich bereits in dieser Phase und im Rahmen dieser Arbeit wurden auch Fehlerbehebungen und Funktionserweiterungen durchgeführt. Probleme die mit dem Support Tracking System erfasst werden, lösen oft eine Wartungsaktivität aus. Gründe genug sich mit dem Thema Wartung ausführlicher zu beschäftigen. Um die Quellcodebasis vom Support Tracking System zu verbessern und um neue Funktionalität implementieren zu können, war es notwendig den Entwurf des Systems zu ändern. Die dazu verwendete Technik bezeichnet man als Refaktoring und stammt aus dem Bereich eXtreme Programming. Aus diesem Grund beschäftigt sich dieses Kapitel neben der Softwarewartung mit den agilen Software Entwicklungsprozessen und mit Refaktoring. 3.1 Softwarewartung Schwergewichtige Software Entwicklungsprozesse, wie das Wasserfall-Modell, das V-Modell oder das Spiralmodell, konzentrieren sich sehr stark auf den einmaligen Durchlauf der Phasen Analyse, Design, Implementierung, Test und Auslieferung. Dies deutet darauf hin, dass die softwareerstellende Industrie in ihrem Denken mehr den Projektgedanken als den Produktgedanken behaftet ist. Erst die agilen Softwareentwicklungsprozesse, auch als evolutionäre, iterative, inkrementelle oder leichte Prozesse bezeichnet, berücksichtigen die sich ändernden Anforderungen an die erstellte Software. Selbst so umfangreiche Werke, wie das Lehrbuch der Software Technik von Helmut Balzert, beinhaltet nur einen verhältnismäßig kleinen Teil für das Thema Softwarewartung. [Balzert 1996][Balzert 1998] Befindet sich eine Softwareapplikation in Produktion, dann treten die folgenden drei Ereignisgruppen auf, die meist zu einer Änderung der Software führen. In die erste Gruppe fallen Programmierfehler, die während der Erstellung der Software gemacht wurden. Sie können mehr oder weniger stark die Benutzung der Software behindern. In Kapitel 3 Wartungsprozess 21 die zweite Gruppe fallen sich ändernde Rahmen- und Umweltbedingungen. Dazu zählen Änderungen im Hardwaresetup, Veränderungen im Systemsoftwarebereich oder die sich ändernde organisatorische Einbettung. Je vertrauter die Benutzer eines Systems mit den Funktionen und Möglichkeiten sind, desto mehr Änderungswünsche stellen sie. Diese Änderungswünsche der Benutzer bilden die dritte Ereignisgruppe in der Wartungsphase. [Balzert 1998] Stabilisierungen, Optimierungen, Anpassungen und Erweiterungen sind die Antworten auf diese drei Problemgruppen. Ein Nichtreagieren hätte zur Folge, dass die Software veraltet und an Wert und Benutzbarkeit verliert. Die oben genannten Punkte fasst [Balzert 1998] wie folgt zusammen: Stabilisierung und Korrektur: Verborgene Fehler werden durch Tests während der Entwicklung nicht entdeckt und treten erst im Betrieb zu Tage. Die Korrektur versucht die Fehler zu beseitigen. Sogenannte "second level defects" sind neue Fehler, die bei der Fehlerbeseitigung gemacht werden. Leider nehmen diese durch Wartung verursachten Fehler im Laufe der Zeit zu. Auf zehn während der Tests entdeckten Fehler, kommt nur ein Fehler, der im Betrieb entdeckt wird. Allerdings sind die Kosten der Beseitigung eines Fehlers, bei in Produktion stehender Software, viermal so hoch als bei Entdeckung und Beseitigung während der Entwicklung. Optimierung und Leistungsverbesserung: Neue Software ist beim Verbrauch der Ressourcen Rechenzeit, Hauptspeicher und Platz in der Datenbank oft noch nicht optimal. Oft wird Software nach dem Erreichen der Funktionalität ohne durchgeführte Ressourcenoptimierung sofort freigeben. Dadurch ist Software bei der ersten Freigabe selten optimal. Die Optimierung verschiebt sich in die Wartungsphase, obwohl diese eigentlich Teil der Entwicklung sein sollte. Anpassung und Änderung: Ändern sich Gesetze und betriebliche Regeln, werden neue Formulare benötigt oder kommt es zum Einsatz neuer Betriebsysteme, wird eine Anpassung der Funktionen, der Benutzeroberfläche oder der technischen Einbindung notwendig. Erweiterung: Funktionen konnten im ersten Produktionszyklus nicht realisiert werden oder Benutzer erkennen den Bedarf neuer Funktionen. Wenn diese Funktionen während der Wartungsphase realisiert werden, dann spricht man von Erweiterung. Stabilisierung und Optimierung fasst man auch unter korrektive Tätigkeiten oder Wartung zusammen. Hingegen zählen Anpassung und Erweiterung zu den progressiven Tätigkeiten oder Pflege. 60%-80% der Tätigkeiten fallen in den progressiven Bereich. Tabelle 3-1 stellt die unterschiedlichen Eigenschaften von Wartung und Pflege gegenüber. Im alltäglichen Sprachgebrauch wird der Begriff Wartung für beides verwendet. [Balzert 1998] Wartung Pflege Ziel Lokalisierung und Behebung von Fehlern Lokalisierung und Durchführung von Änderungen Ausgangsbasis fehlerhaftes, inkonsistentes Produkt konsistentes Produkt Kapitel 3 Wartungsprozess 22 Wartung Pflege Größe - Bandbreite geringe Auswirkung auf Gesamtsystem kleine bis große Änderungen betroffene Teile Implementierung Analyse, Design, Implementierung, Test, Dokumentation Planung ereignisgesteuert, nicht vorhersehbar, nicht planbar planbar Tabelle 3-1: Gegenüberstellung von Wartung und Pflege nach [Balzert 1998] Rund 80% der Softwareentwickler sind mit der Pflege von Software beschäftigt. Nur der geringe Anteil von 20% entwickelt neue Software. Eine Trennung von Wartung und Pflege erweist sich als Vorteil, weil Pflegeaufgaben den Softwareentwicklungsprozess komplett durchlaufen. Wird Software zyklisch weiterentwickelt, so spricht man auch von evolutionärer oder inkrementeller Entwicklung (siehe auch Unterkapitel 3.2). Der Wartungs- und Pflegeaufwand nimmt mit dem Alter der Software zu, da der Umfang der Software langsam anwächst und immer häufiger Fehler der Kategorie "second level defects" gemacht werden. Je älter die Software, umso schwieriger und teurer wird die Wartung. Werden die Probleme zu groß, geht man von der Wartung zur Sanierung und schließlich zur Neuimplementierung über. Die zu erwartende Resteinsatzdauer bestimmt die Wirtschaftlichkeit dieser drei Stufen. [Balzert 1998] Die Größen Änderbarkeit und Übertragbarkeit wirken auf Wartung und Pflege ein. Änderbarkeit ist der Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist. Dabei setzt sich Änderbarkeit aus den Größen Analysierbarkeit, Modifizierbarkeit, Stabilität und Prüfbarkeit zusammen. Analysierbarkeit ist der Aufwand, um Mängel oder Ursachen des Versagens zu diagnostizieren und änderungsbedürftige Teile zu bestimmen. Modifizierbarkeit ist der notwendige Aufwand zur Ausführung von Verbesserungen, zur Fehlerbeseitigung oder zur Anpassung an Umgebungsänderungen. Stabilität ist die Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Änderungen. Prüfbarkeit schließlich ist der Aufwand, der zur Prüfung der geänderten Software notwendig ist. Übertragbarkeit ist die Eignung der Software von einer organisatorischen, Software- oder Hardware Umgebung in eine andere Umgebung übertragen werden zu können. Übertragbarkeit setzt sich aus Anpassbarkeit, Installierbarkeit, Konformität und Anwendbarkeit zusammen. Anpassbarkeit ist die Möglichkeit, die Software an verschiedene, festgelegte Umgebungen anpassen zu können. Installierbarkeit ist der Aufwand, der zur Installierung der Software in einer festgelegten Umgebung notwendig ist. Konformität ist der Grad, in dem die Software Normen oder Vereinbarungen zur Übertragbarkeit erfüllt ist. Anwendbarkeit ist die Möglichkeit, diese Software anstelle einer spezifizierten anderen in der Umgebung jener Software zu verwenden, sowie den dafür notwendigen Aufwand. [Balzert 1998] Wartung und Pflege beeinflussen ihrerseits die Zuverlässigkeit und die Effizienz eines Programms. Zuverlässigkeit ist die Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren. Zuverlässigkeit setzt sich aus Reife, Fehlertoleranz und Wiederherstellbarkeit zusammen. Reife ist die Versagenshäufigkeit durch Fallumstände. Fehlertoleranz ist die Kapitel 3 Wartungsprozess 23 Fähigkeit, ein spezifiziertes Leistungsniveau bei Softwarefehlern oder Nichteinhaltung ihrer spezifizierten Schnittstelle zu bewahren. Wiederherstellbarkeit ist die Fähigkeit, bei Versagen das Leistungsniveau wieder herzustellen und direkt betroffene Daten wiederzugewinnen. Zu berücksichtigen sind die dafür benötigte Zeit und der benötigte Aufwand. Die zweite beeinflusste Größe ist die Effizienz, sie ist das Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen. Zur Effizienz gehören Zeitverhalten und Verbrauchsverhalten. Zeitverhalten betrifft Antwort- und Verarbeitungszeiten, sowie den Durchsatz bei der Ausführung von Funktionen. Das Verbrauchsverhalten betrifft Anzahl und Dauer der benötigten Betriebsmittel für die Erfüllung der Funktion. [Balzert 1998] Die Organisationsform hat großen Einfluss auf die Effektivität der Wartung. Konfigurationsmanagementsysteme und Systeme zur Erfassung, Verwaltung und Verfolgung von Fehlern, Problemen und Änderungswünschen können bei der Wartung unterstützend wirken. Im Kapitel 2 werden Trouble Ticket Systeme, zu denen auch das Support Tracking System gehört, genauer erläutert. Der letzte Punkt der Betrachtung zur Softwarewartung beschäftigt sich damit, ob Wartung und Pflege von eigenständigen Wartungsabteilungen oder durch Entwicklungsabteilungen ausgeführt werden sollen. Tabelle 3-2 stellt die Vor- und Nachteile einer Trennung gegenüber. [Balzert 1998] Vorteile klare Zuordnung der Kosten zu Wartung oder Entwicklung Nachteile Entlastung der Entwickler von parallelen Tätigkeiten schlechtes Image von Wartungsarbeiten senkt die Motivation der Wartungsmitarbeiter einstellen spezialisierter Mitarbeiter und gezieltere Ausbildung Informationsverlust beim Übergang vom Entwicklungs- zum Wartungsteam effizientere Kommunikation im Wartungsteam Koordinationsproblem zwischen Wartung und Entwicklung höhere Produktivität durch Spezialisierung aufwendiges Einarbeiten der Wartungsmitarbeiter ungleichmäßige Auslastung der Wartungsmannschaft Tabelle 3-2: Eigenständiger Wartungsabteilungen nach [Balzert 1998] Bei der Fehlerkorrektur ist es von großem Vorteil, wenn Anwender und Programmierer eng zusammenarbeiten. Dabei soll der Anwender dem Programmierer ein schnelles Feedback liefern, ob der Fehler tatsächlich behoben wurde. Ein durch Fehlerbehebung hervorgerufenes Problem ist, dass Implementierung und Dokumentation auseinanderdriften und das Fachkonzept langsam zerfällt. Ein Problem welches bei STS V1.2 schon recht stark auftrat und mit Hilfe von Refaktoring gemindert werden sollte (siehe Unterkapitel 3.4). Kapitel 3 Wartungsprozess 24 3.2 Agile Software Prozesse In den letzen Jahren ist eine Entwicklung in Gang gekommen, die die phasenorientierten Entwicklungsprozesse, wie Wasserfallmodell, Spiralmodell und V-Modell mit ihren zahlreichen, zumeist inkonsistenten Dokumenten langsam etwas unter Druck geraten lässt. Dabei handelt es sich um inkrementelle, iterative Prozesse, die sich gut in die Objektorientierte Programmierung einfügen. Ihr wohl bekanntester Vertreter ist eXtreme Programming (XP). Anfangs fasste man diese Prozesse unter den Sammelbegriff "leichte Softwareentwicklungsprozesse" zusammen. In letzter Zeit kristallisiert sich immer mehr die Bezeichnung Agile Software Prozesse heraus. Kernhypothese dieser Prozesse ist, dass Software änderbar ist und nicht alles von Anfang an festlegt werden muss. Daraus leitet sich dann das inkrementelle, iterative Vorgehen ab. Mit jeder Iteration kommen neue Funktionen dazu. Einen Überblick über Agile Software Prozesse gibt Jens Coldewey in [Coldewey 2002]. Agile Software Entwicklungsverfahren teilt Coldewey in Meta Prozesse und in Konkrete Prozesse auf. Meta Prozesse treffen keine konkrete Festlegung einzelner Prozessschritte. Hier wird auf die Erfahrung und Professionalität des Teams vertraut. Meta Prozesse geben nur Rahmenbedingungen vor. Adaptive Software Development (ASD) von Jim Highsmith, Crystal Prozesse von Alistair Cockburn sowie Scrum von Ken Schaber und Jeff Sutherland sind die Vertreter der Meta Prozesse und sind im Unterkapitel 3.2.1 näher beschrieben. Konkrete Prozesse machen dagegen auch Vorschläge für einzelne Prozessschritte. Gestehen aber erfahrenen Teams zu diese Vorschläge abzuändern. Vertreter sind Feature Driven Development (FDD) von Jeff De Luca, Dynamic Systems Development Method (DSDM) und eXtreme Programming (XP) von Kent Beck, Ward Cunningham und Ron Jeffries. Die beiden erstgenannten Vertreter der Konkreten Prozesse sind im Unterkapitel 3.2.2 beschrieben. eXtreme Programming wird, auf Grund der Bedeutung für diese Arbeit, das Unterkapitel 3.3 gewidmet. [Coldewey 2002] Das Wort "agil" bedeutet soviel wie beweglich, flink oder gewandt. Um auf schnell ändernde Märkte reagieren zu können, setzen agile Prozesse beim Team, bei der Software und beim Prozess selbst an. Ziel ist es sich nicht gegen Änderungen bei den Anforderungen zu wehren. Am Projektanfang definierte Anforderungen stimmen zum Projektende nicht mehr. Dadurch entsteht ein "Moving Target", das es gilt so gut wie möglich zu treffen. [Beck 2001] Das Manifest26 der agilen Softwareentwicklung gibt folgende Leitmotive für die Bereiche Team, Software und Prozesse: Einzelpersonen und Interaktionen sind wichtiger als Prozesse und Werkzeuge Die Stärken des Teams müssen Kompetenz und Zusammenarbeit sein, denn Software kann ohne einen Prozess und ohne Werkzeuge erstellt werden, aber nie ohne ein qualifiziertes Team. Der beste Prozess wiegt einen chaotischen Haufen von Anfängern, die kein professionelles Team bilden, nicht auf. Da professionelle Teams einen hohen Grad an Selbstorganisation haben ist eine kleine Zahl an Methoden ausreichend. Zwölf 26 http://agilemanifesto.org/ Kapitel 3 Wartungsprozess 25 auf einer Seite definierte Methoden bringen mehr als tausend Seiten Richtlinien der Prozessdinosaurier der beiden vorangegangen Jahrzehnten. Die nur von wenigen Experten überblickt und verstanden wurden. Man verabschiedet sich immer mehr von der Vorstellung, dass einheitliche wiederholbare Prozesse und detailliert planbare Projekte möglich sind. Auch die Vorstellung durch klare Anweisungen und Kontrolle ein Projekt steuern zu können schwindet, da die Erfahrung zeigt, dass kreative Prozesse sich nur schlecht befehlen und kontrollieren lassen. Wichtig ist es ein Team mit kompetenten Mitgliedern zu haben! Wo dies nicht der Fall ist, stellt sich die Frage, ob professionelle Softwareentwicklung überhaupt möglich ist. [Beck 2001] Laufende Systeme sind wichtiger als umfangreiche Dokumentation Agile Prozesse versuchen umfangreiche Dokumentation, welche nur zu oft inkonsistent ist, durch Kollaboration und Kommunikation im Team zu ersetzen. Dokumentation stellt meist nur einen statischen Schnappschuss in einer dynamischen Welt dar und fehlinformiert oft statt zu informieren. Dokumentation für den sicheren Betrieb ist zu erstellen, allerdings nachträglich für bereits stabile Systemteile. Dokumentation darf nicht zum Selbstzweck verkommen, sondern sollte dann verwendet werden, wenn es keine bessere Möglichkeit zur Kommunikation gibt. [Beck 2001] Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen Kunden und Auftragnehmer verwenden sehr viel Zeit und Energie für die Vertragsgestaltung, statt gemeinsam an der Lösung der Probleme zu arbeiten. Ein Vertrag setzt eindeutige Spezifikationen voraus, die zu Projektbeginn noch nicht feststehen und sich erst im Projektverlauf herauskristallisieren. Eine vollständige Spezifikation ist schwierig und nur teuer (unrentabel) zu erstellen. Aufwände wie sie in der Raumfahrt betrieben werden, sind für die meisten anderen Projekte nicht finanzierbar. Ariane 5 und Marssondenausfälle zeigen, dass auch dann Fehler nicht auszuschließen sind. Agile Prozesse versuchen deshalb Kunden so ins Projekt einzubeziehen, dass ein fachlicher Entscheidungsträger kurzfristig immer zur Verfügung steht. [Beck 2001] Reagieren können auf Veränderung ist wichtiger als Pläne zu verfolgen Es ist zu beobachten, dass kein Projekt nach Plan verläuft, was im übrigen nicht die Schuld der Ausführenden, sondern ein Problem des Planerstellers ist. Je feiner ein Projektplan strukturiert ist, umso schneller treten Abweichungen auf. Die Erfüllung von Plänen bewirkt außerdem, dass die Notwendigkeiten zu Projektbeginn erfüllt werden und nicht die vorliegenden Notwendigkeiten am Ende des Projektes. Böse Zungen behaupten Pläne ersetzen Zufall durch Irrtum. Agile Verfahren erstellen nur so viele Pläne, wie Team und Auftraggeber brauchen. Es wird immer nur die nächste Iteration geplant, dabei verzichtet man auf Vorhersagbarkeit zu Gunsten der schnelleren Reaktionsfähigkeit. [Beck 2001] Die vier Schwerpunkte agiler Softwareprozesse sind, Konzentration auf Individuen und Zusammenarbeit, frühzeitig lauffähige Software, Einbindung des Kunden und Kapitel 3 Wartungsprozess 26 Änderungsfreudigkeit statt Planungsverfolgung. Diese Schwerpunkte sind sowohl den Meta Prozessen als auch den Konkreten Prozessen gemein. Konkrete Prozesse beschreiben den Prozess zur Softwareentwicklung allerdings tiefergehender (siehe die Unterkapitel 3.2.1, 3.2.2 und 3.3). [Coldewey 2002] 3.2.1 Meta Prozesse Meta Prozesse lassen dem Team völlig freie Hand bei der Gestaltung der Softwareentwicklung, dabei könnte ein Team sich theoretisch auch einen rigiden Prozess auferlegen. Die Freiheit in Metaprozessen setzt allerdings ein professionelles und erfahrenes Team sowie rigide Praktiken voraus, um die Prozesse unter Kontrolle zu halten. Nachfolgend werden drei Vertreter dieser Klasse umrissen. Die beschriebenen Metaprozesse haben einige Gemeinsamkeiten. Am Anfang steht eine Art Workshop um den Umfang des Projektes, die Arbeitsweise und einen Plan festzulegen. Der zweite gemeinsame Punkt ist die Verwendung kurzer Arbeitsphasen. Dabei wird Kommunikation und Kollaboration im Team großgeschrieben. Die dritte Gemeinsamkeit von Metaprozessen sind Feedbackworkshops. Dabei wird das Vorgehen der letzten Iteration besprochen und über Verbesserungen für die nächste Iteration nachgedacht. Ein minimaler Satz an Regeln führt zum gewünschten Verhalten (Emergent Behaviour), dabei wird auf die Kompetenz der Entwickler vertraut. Wichtig ist aber auch das bewusste und disziplinierte Reflektieren über den Prozess. Im folgenden werden die drei untersuchten Metaprozesse im Detail dargestellt. Adaptive Software Development (ASD) Jim Highsmith hat sich für seinen Prozess Anregungen aus dem Bereich der Biologie bei komplexen adaptiven Systemen geholt. Unter komplexen Systemen versteht man ein Zusammenspiel von Agenten, die mittels Regeln kommunizieren. Das dabei entstehende Verhalten (Emergent Behaviour) zeigt folgende Eigenschaft. Einfache Regeln gepaart mit reichen Beziehungen führen zu erfolgreichem Verhalten und komplexe Regeln gepaart mit wenigen Beziehungen führen zu erfolglosem Verhalten. Bei der Entwicklung von Software betrachtet man nun Teammitglieder, Auftraggeber und Organisationen als Agenten. Die Regeln für die Zusammenarbeit bilden dabei das Entwicklungsverfahren. Somit entspricht ein Projekt einem komplexen System. Jim Highsmith hat folgendes Regelwerk erstellt [Coldewey 2002]: Entwicklungsteam und Kunde starten gemeinsam mit dem Entwurf einer Vision Team versucht innerhalb von vier Wochen so viele Features, von einer Prioritätenliste des Kunden, wie nur möglich zu erfüllen. Am Ende der vierwöchigen Iteration erhält das Team Feedback vom Kunden. während der Iteration wird dem Team vertraut und wenn der Plan nicht erfüllt werden konnte, geht man von einer Fehlplanung aus am Iterationsende überprüft das Team seine Leistung und verbessert seinen Prozess Team plant nächste Iterationsrunde auf Grund vorangegangener Erfahrungen Management unterstützt das Team auf allen Ebenen man überlässt dem Team einzelne Arbeitstechniken anzupassen Kapitel 3 Wartungsprozess 27 Diese kleine Anzahl von Regeln führt zu flexiblen Projekten. Der ASD Lebenszyklus ist eine kurze Abfolge aus Spekulieren, Kollaborieren und Lernen. [Coldewey 2002] Crystal Methoden Familie Alistair Cockburn war als Berater in zahlreichen Projekten in verschiedenen Kulturkreisen tätig. Diese Erfahrungen flossen in die Entwicklungsprozesse der Crystal Familie ein. Schlussfolgerung seiner Erfahrungen ist, dass nicht jede Methode für jedes Projekt geeignet ist und Anpassung an die Projekte notwendig ist. Dabei sind Organisationskultur, Projektgröße und Kritikalität (Menschenleben, Konkurs, etc.) von Bedeutung. Ziel bei diesen Verfahren ist nicht einzelne Zwischenprodukte zu erstellen, sondern die Festlegung wie zusammengearbeitet werden soll. Die Crystal Methoden Familie kennt vier Abstufungen (Clear, Yellow, Orange, Red), dabei werden Teamgröße und Kritikalität als Einteilungsmerkmale verwendet. Crystal Clear ist geeignet für kleine Teams mit bis zu sechs Mitgliedern und Projekten mit geringer Kritikalität. Folgende Richtlinien gelten für alle Crystal Prozessvarianten [Coldewey 2002]: direkte, interaktive Kommunikation zwischen zwei anwesenden Personen ist die preisgünstigste und schnellste Art Information auszutauschen mit steigender Anzahl Teammitglieder Kommunikationsregeln steigen überflüssige Regeln kosten überproportional viel Geld je höher die Kritikalität umso höher muss der Anteil von außen nachvollziehbarer Interaktionen sein Formalismus bedeutet nicht Disziplin, Prozess alleine bedeutet nicht Fähigkeit und Dokumentation bedeutet nicht Verständnis Feedback und Kommunikation vermindert Notwendigkeit an Zwischenprodukten Abseits vom kritischen Pfad sind möglichst stabile Ergebnisse wichtiger als möglichst schnelle Ergebnisse muss auch die Anzahl der Die drei wichtigsten Punkte für Alistair Cockburn sind Kommunikation, zweimaliges Feedback pro Iteration und maximale Iterationszyklen von vier Monaten. Alistair Cockburn stellt außerdem noch eine interessante These auf, dass nämlich die Informationsdichte mit der Distanz mit der dritten Potenz abnimmt und leitet daraus ab, dass E-Mailverkehr und Videokonferenzen nur ein schlechter Ersatz für den direkten Kontakt sind. Alistair Cockburn beschränkt sich nicht nur auf den Metaprozess, sondern gibt auch eine Reihe von Arbeitsergebnissen inklusive einer Sinnangabe an. [Coldewey 2002] Scrum Ken Schwaber und Jeff Sutherland holten sich für ihren Prozess Anregungen aus dem Bereich Verfahrenstechnik (Process Engineering). Bei den Verfahren zur Stoffumwandlung unterscheidet man zwischen chemischer Reaktionstechnik, mechanischen und thermischen Verfahren. Der wesentliche Punkt ist aber, dass man Kapitel 3 Wartungsprozess 28 zwischen wiederholbaren und empirischen Prozessen unterscheidet. Wiederholbare Prozesse sind solche, die vollständig verstanden sind und deren Anwendung immer zu akzeptablen Ergebnissen führen. Wohingegen empirische Prozesse chaotisch und sehr komplex sind. Daraus folgt aber auch, dass sie nicht oder nur schwer steuerbar (Sensoren und Regelkreise) sind. Schwaber und Sutherland behaupten, Softwareentwicklung ist kein streng wiederholbarer Prozess, da die Endprodukte immer verschieden sind. Empirische Prozesse müssen fortlaufend überwacht und angepasst werden, um ein erwünschtes Verhalten (Emergent Behaviour) zu erzielen. Zur Steuerung ihres Prozesses verwenden sie den Produktrückstand, damit sind die offenen Punkte der Prioritätenliste gemeint. Alle 30 Tage setzen sich Auftraggeber und Team zusammen und beschließen, was in den nächsten 30 Tagen von der Prioritätenliste gemacht werden soll. Das Team versucht in diesen 30 Tagen, die als Sprint bezeichnet werden, die Aufgaben zu erfüllen. Aufgaben die nicht erfüllt werden können bilden den Sprint Rückstand. Während des Sprints kann das Team ohne Einflüsse von außen arbeiten. Am Ende kommt es zu einem Sprint Review und die nicht erfüllten Aufgaben wandern wieder auf den Produktrückstand. Nach einem Feedback und Erfahrungsaustausch beginnt wieder alles von vorne. Das Team hält täglich, immer zur gleichen Zeit, ein sogenanntes Scrum Meeting ab. Richtlinien für Scrum Meeting sind [Coldewey 2002]: kurze Dauer von 15-30 Minuten was hat jeder seit dem letzten Meeting getan was wird man bis zum nächsten Meeting tun was hat bei der Arbeit behindert Lösungen werden nicht während eines Scrum Meeting gesucht oder diskutiert zu offenen Fragen werden kleine Teams gebildet, diese arbeiten nach Abschluss des Scrum Meetings weiter Scrum Meetings sind der Pulsschlag des Projektes 30 Tage hat der Auftraggeber die Möglichkeit sich neue Anforderungen zu überlegen, die dann Teil des neuen Produktrückstandes werden. Der Vorteil dieses Prozesses ist, dass das Team 30 Tage ungestört arbeiten kann. Die Durchführung der Aufgaben ist Teamsache, somit ist Scrum ein reiner Metaprozess. Scrum enthält keine Richtlinien zur Programmierung. [Coldewey 2002] 3.2.2 Konkrete Prozesse Konkrete Prozesse regeln den Softwareentwicklungsprozess tiefgehender als die Metaprozesse. Die Prozesse Dynamic System Development Method (DSDM) und Feature Driven Development werden nur kurz besprochen. Der Klassiker unter den agilen Prozessen, eXtreme Programming (XP) kommt etwas ausführlicher zur Diskussion. Grund ist, dass im Laufe dieser Arbeit versucht wurde einige eXtreme Programming Techniken anzuwenden. Vor allem wurde versucht die Qualität des Quellcodes vom Support Tracking System durch Refaktoring zu erhöhen. Kapitel 3 Wartungsprozess 29 Dynamic System Development Method (DSDM) Dieser aus Großbritannien stammte Prozess wird von einem Industriekonsortium unterstützt und ist eine Weiterentwicklung des Rapid Application Development Ansatzes. Das Verfahren baut auf die vier Grundprinzipien aktive Beteiligung der Anwender, Team muss Entscheidungen treffen können und dürfen, häufige Auslieferung des Produktes und Abnahme und Eignung für den Geschäftsprozess als Hauptkriterium auf. Weitere Prinzipien bilden das Manifest der agilen Softwareentwicklung ab. Dazu zählen iterative und inkrementelle Entwicklungsschritte zur Lösung des Geschäftsproblems. Man ist sich bewusst, dass Änderungen umkehrbar sind. Die Anforderungen werden nur grob definiert und Details werden später abgeklärt. Tests werden im kompletten Lebenszyklus verwendet und Tests stellen keine gesonderten Aktivitäten dar. Kollaborative und kommunikative Zusammenarbeit wird gefördert. Das Verfahren gliedert sich in fünf aufeinander folgende Phasen. Die erste Phase prüft die technische Machbarkeit und dauert maximal einen Monat. Ein weiterer Monat wird für die fachliche Machbarkeitsstudie verwendet. Danach folgen die Phasen Analyse (Functional Model Iteration), Design (Design and Build Iteration) und Implementierung. Das Vorgehen ist auch hier wieder iterativ und die einzelnen Iterationszyklen sollten 4-6 Wochen dauern und die Anforderungen, nach Prioritäten geordnet, abarbeiten. Dokumentation soll auch in diesem Prozess durch Kommunikation zurückgedrängt werden. DSDM kennt 15 Artefakte, gibt aber weder Gliederung noch den genauen Inhalt vor. Jedes Artefakt hat aber vier beschreibende Faktoren. Dazu zählen in welcher Phase wird es abgeschlossen, wer es abnehmen soll, welchem Zweck es dient und welche Qualitätskriterien es erfüllen muss. [Coldewey 2002] Feature Driven Development (FDD) Feature Driven Development stammt von Jeff De Luca. Der Prozess gliedert sich in fünf Phasen, wobei die Beschreibung jeder Phase auf einer Seite Platz findet und jeweils folgende Punkte klärt [Coldewey 2002]: Eintrittskriterien Aktivitäten Maßnahmen zur Verifikation Abschlusskriterien In der Startphase wird ein übergreifendes Modell entwickelt, diese Phase benötigt in etwa 10% der gesamten Zeit. In der Startphase wird das gesamte System einmal grob durchlaufen. Anforderungen werden in zwei Klassen, in "unbedingt notwendig" und in "nice to have", eingeteilt. Für die einzelnen Teile werden Modelle erstellt und am Ende dieser Phase zu einem Gesamtmodell zusammengeführt. In der zweiten Phase wird aus dem Gesamtmodell eine Featureliste erstellt, wobei jedes Feature einzeln implementiert werden kann und wirtschaftlichen Nutzen bringt. Ein einzelnes Feature sollte in weniger als zwei Wochen implementierbar und testbar sein. In der dritten Phase wird ein Featureplan erstellt, dabei wird gemeinsam der Aufwand geschätzt und Jeff De Luca rät dringend von zu feinstrukturierten Plänen ab. Die einzelnen Features werden Teams zugeordnet. Die vierte und fünfte Phase verlaufen ähnlich wie bei Scrum. In der vierten Phase, wird für jedes Feature ein Design entworfen, dabei werden Features, die gleiche Kapitel 3 Wartungsprozess 30 Klassen betreffen, gebündelt. In dieser Phase ist die Einbindung des Anwendungsexperten sehr stark. In der fünften und letzen Phase wird das Design der vierten Phase implementiert und getestet. Vor einer Codefreigabe erfolgt eine Codeinspektion. [Coldewey 2002] 3.3 eXtreme Programming (XP) Der Softwareentwicklungsprozess eXtreme Programming (XP) von Kent Beck, Ward Cunningham und Ron Jeffries gehört zur Gruppe der konkreten Prozesse. Der Prozess eXtreme Programming ist der Klassiker unter den agilen Prozessen. XP ist auch deshalb von besonderem Interesse, weil während der Arbeit am Support Tracking System versucht wurde einige Techniken von XP anzuwenden. Deshalb wird XP hier getrennt von den anderen konkreten Prozessen vorgestellt. Der Arbeitstechnik Refaktoring wird im Anschluss ein eigenes Unterkapitel gewidmet. Kent Beck führt in seinem Buch die fünf nachfolgenden Grundprinzipien an. Aus diesen leitet er dann zwölf Praktiken ab. Beck betont, dass die Prinzipien wichtiger sind als die Praktiken. [Beck 2000] Die fünf Grundprinzipien nach [Beck 2000] sind: unmittelbares Feedback bedeutet möglichst rasch nach einer Tätigkeit irgendeine Rückmeldung über Richtigkeit zu erlangen streben nach Einfachheit soll verhindern, dass Dinge zu einem Zeitpunkt verkompliziert werden, wo man mit einfachen Lösungen noch das Auslangen findet inkrementelle Weiterentwicklung heißt, dass in Zyklen am Werk weitergearbeitet wird und beachtet wird in kurzen Abständen lauffähige Versionen zu haben Änderungen willkommen heißen ist eine Einstellung, die ermuntert einmal getroffene Entscheidungen zu revidieren Qualitätsarbeit leisten bedeutet Qualität als zentrales Element neben der Funktionalität zu betrachten Diese fünf Prinzipien folgen aus den Werten Kommunikation, Einfachheit, Feedback und Mut. Nebenprinzipien sind Lernen lehren, kleine Anfangsinvestition, Spielen um zu gewinnen, gezielte Experimente, offene ehrliche Kommunikation, Mitarbeiterinstinkte nutzen, Verantwortung übernehmen, an örtliche Gegebenheiten anpassen, mit leichtem Gebäck reisen und ehrliches Messen. Aus den obigen Grundprinzipien wurden die dreizehn Praktiken von eXtreme Programming entwickelt: [Beck 2000] 1. Kunde vor Ort, bedeutet das ein Vertreter des Auftraggebers Mitglied des Entwicklungsteams ist und dem Team jederzeit auftretende Fragen beantwortet und Feedback gibt. 2. Kurze Inkremente heißt, dass von Release zu Release maximal 1-2 Monate vergehen sollen. Dabei ist zu beachten dass jede Release dem Kunden ausgeliefert wird und wirtschaftlichen Mehrwert bringt, aber nicht in Produktion gehen muss. 3. Planungsspiel wird am Anfang jedes Inkrementes durchgeführt. Dabei werden zusammen mit den Anwendern User Stories erstellt, Prioritäten nach wirtschaftlichen Kriterien gesetzt, Aufwände geschätzt und Liefertermine festgelegt. Kapitel 3 Wartungsprozess 31 4. Abnahmetests werden vom Anwender definiert und erstellt. 5. Einfaches Design wählen heißt, dass nur soviel Komplexität verwendet wird, wie unbedingt erforderlich ist um die Funktionalität der laufenden Iteration zu implementieren. Das Design trifft keine Vorbereitung für Funktionalität, die vielleicht irgendwann einmal eingebaut werden könnte. 6. Das Programmieren in Paaren soll Reviews und Inspektionen ersetzen und sorgt für die Wissensverteilung im Team. 7. Entwicklertest heißt, dass nach dem Test-Frist-Ansatz implementiert wird und zuerst die Testfälle geschrieben werden und erst anschließend die Funktionen selbst implementiert werden. 8. Refaktoring ist die Möglichkeit bei bestehendem Quellcode, dass Design zu verbessern und notwendige Umstrukturierungen machen zu können, falls das implementierte Design für neue Funktionalität nicht ausreicht (siehe Unterkapitel 3.4) 9. Gemeinsame Verantwortung heißt, dass der Quellcode in der Verantwortung des gesamten Teams liegt. Einzelpersonen haben nicht die alleinige Änderungsbefugnis über Codeteile. 10. Programmierstandards helfen mit, dass sich das gesamte Team in allen Codeteilen zurecht findet. 11. Fortlaufende Integration ist notwendig, damit in jeder Nacht auf das Neue alle Testfälle neu ausgeführt werden können. 12. Metapher gibt dem Team eine Vision und ein Richtung vor. 13. Nachhaltiges Tempo und 40 Stunden Woche bedeutet, dass kontinuierlich am Projekt gearbeitet wird ohne an der Substanz der Teammitglieder zu nagen. Die Punkte 1. – 4. zählen zum Produktzyklus, Punkte 5. – 8. zum Entwicklerzyklus und die Punkte 9.- 13. stellen unterstützende Praktiken dar. [Beck 2000] eXtreme Programming versucht auch einen Paradigmenwechsel herbeizuführen. Je später ein Fehler im Phasenverlauf Analyse, Design, Implementierung, Test und Wartung entdeckt wird und je früher der Fehler im Phasenverlauf gemacht wurde, umso höher sind die Fehlerbeseitigungskosten. Das ist die Annahme der Vertreter der Phasenmodelle. Vertreter der Phasenmodelle Wasserfall, V-Modell oder Spiralmodell versuchten deshalb, Entscheidungen möglichst früh zu treffen und Analyse und Design möglichst ausführlich und detailliert zu machen. Das Festhalten der Entscheidungen führte zu umfangreicher Dokumentation der einzelnen Phasen, die selten mit dem tatsächlichen Quellcode konsistent war. XP Vertreter versuchen die Kosten der Fehlerbeseitigung durch ein Bündel an Maßnahmen in den Griff zu bekommen. Dazu zählen die Praktiken einfaches Design, automatisierte Testfälle und Refaktoring. Diese drei Praktiken zusammen nutzen den Umstand, dass Software im Vergleich zu Hardware leicht zu ändern ist und sorgen dafür, dass Änderungen auch kostengünstig erfolgen können. XP Vertreter wehren sich nicht gegen Veränderung, sondern nehmen diese offen an. XP Vertreter sehen den Quellcode als zentrales Produkt und halten die Dokumentation aus den verschiedenen Phasen gering. Dies reduziert auch das Problem mit inkonsistenter Dokumentation. XP Vertreter behaupten, dass durch das Kapitel 3 Wartungsprozess 32 Maßnahmenbündel die Kosten für Änderungen und Fehlerbeseitigung beschränkt ist und Entscheidungen aufgeschoben werden können. [Beck 2000] Konkrete Prozesse, wie Dynamic System Development, Feature Driven Development und eXtreme Programming geben nicht nur allgemeine Verhaltensrichtlinien wieder, wie die Metaprozesse Adaptive Software Development, Crystal Methode oder SCRUM, sondern stellen den Entwicklern konkrete Praktiken und Schritte zur Seite. Die Designstrategie beinhaltet einfaches Design, umgehend die Qualität von Ergebnissen zu prüfen, Erfahrungen ins Design einfliesen zu lassen, sowie die Minimierung der Zeitdauer für diese Prozesse. Einfaches Design ist gegeben, wenn das System (Quellcode und Testfälle) alles vermittelt, was man aussagen will, kein redundanter Code vorhanden ist und Klassenzahl und Methodenzahl minimal sind. Allerdings soll das Design nicht nur am Anfang einfach sein, sondern soll es auch später bleiben. Refaktoring ist die Praktik um dies zu erreichen. Diese Praktik wird im Unterkapitel 3.4 ausführlich beschrieben. 3.4 Refaktoring Einfaches Design, der Test-First Ansatz mit automatisierter Testumgebung und Refaktoring bilden eine zusammengehörende Gruppe von Praktiken des agilen Prozesses eXtreme Programming. Da diese Praktiken so wichtig sind, werden sie nicht nur von Kent Beck in [Beck 2000] beschrieben, sondern haben Martin Fowler veranlasst ein eigenes Buch über Refaktoring zu schreiben [Fowler 2000]. Während der Wartung und Pflege des Support Tracking Systems wurde das Ziel verfolgt, mit Hilfe von Refaktoring Designschwächen zu entfernen und das Design wieder zu vereinfachen. Bei der Umwandlung vom Support Tracking System in eine adaptive Webapplikation, wurde um die notwendigen Designänderungen vorzunehmen einige Techniken des Refaktoring verwendet. Martin Fowler gibt folgende Definitionen an: Refaktorisierung (Substantiv): "Eine Änderung an der internen Struktur einer Software, um sie leichter verständlich zu machen und einfacher zu verändern, ohne ihr beobachtbares Verhalten zu ändern." [Fowler 2000] Refaktorisieren (Verb): "Eine Software umstrukturieren, ohne ihr beobachtbares Verhalten zu ändern, indem man eine Reihe von Refaktoringschritten anwendet." [Fowler 2000] Refaktoring wird verwendet um das Design einer Software zu verbessern, um Fehler leichter zu lokalisieren und weil es hilft schneller zu Programmieren. Die Praktik Refaktoring soll verwendet werden bei Code Reviews, beim Beheben von Fehlern, beim Hinzufügen von Funktionen und beim Auftreten der 3'er Regel. Die 3'er Regel besagt, dass man, wenn man zweimal auf eine Situation stößt diese noch ausprogrammiert, stößt man allerdings dreimal auf die gleiche Situation, dann ist es Zeit Refaktoring anzuwenden. Refaktoring soll nicht verwendet werden bei Datenbankschemas, wenn Neuimplementierung günstiger ist und bei schwer durchführbaren Designänderungen. Auch das Verändern von bereits veröffentlichten Schnittstellen ist nicht angebracht. Beide aus dem eXtreme Programming Ansatz stammenden Praktiken Refaktoring und einfaches Design gehören zusammen. Refaktoring sorgt dafür, dass, obwohl immer mehr Funktionalität zu einem Programm dazukommt, das Design einfach bleibt. Kapitel 3 Wartungsprozess 33 Refaktoring dient zwar in erster Linie dazu das Design einfach zu halten, aber es kann auch für die Performanceverbesserung verwendet werden. [Fowler 2000] Martin Fowler nennt 22 Situationen, die im Quellcode vorkommen können, wo es sich lohnt genauer hinzusehen und eventuell zu refaktorisieren. Er bezeichnet solche Stellen als "übel riechenden Codestücke". Folgende 22 Arten werden in [Fowler 2000] identifiziert: 1. Duplizierter Code ist an Quellcodefragmente erkennbar, die gleiche oder ähnliche Aufgaben erfüllen und oft durch einfaches Copy&Paste entstanden sind. 2. Lange Methoden sind Methoden, die auf einer Bildschirmseite nicht mehr Platz finden. Bei gutem objektorientierten Entwurf sind Methoden nur wenige Codezeilen lang. 3. Große Klassen erkennt man an einer unübersichtlichen Anzahl von Methoden. 4. Lange Parameterlisten bei Methoden erschweren das Codieren, sind fehleranfällig und können vermieden werden. 5. Divergierende Änderungen entstehen, wenn eine Klasse häufig auf verschiedene Weise aus verschiedenen Gründen geändert wird 6. Schrottkugeln herausoperieren wird notwendig, wenn für eine Änderung in einer einzelnen Programmfunktionen es notwendig ist, Änderungen in vielen Klassen vorzunehmen. 7. Neid tritt bei Methoden auf, die mehr an anderen Klassen interessiert sind als an der eigenen Klasse. 8. Datenklumpen sind daran zu erkennen, dass immer wieder die gleichen Datenelemente gemeinsam an verschiedenen Codestellen auftreten. 9. Neigung zu elementaren Datentypen tritt zum Beispiel auf, wenn man ein einfaches Datenelement statt einer Klasse verwendet um Währungen oder ähnliches auszudrücken. 10. Switch Befehle treten oft dupliziert auf, können aber elegant durch Polymorphismus umgangen werden. 11. Parallele Vererbungshierarchien erkennt man, wenn man einer Hierarchie eine Unterklasse hinzufügt, dass auch an der anderen Hierarchie eine Unterklasse notwendig wird. 12. Faule Klasse ist eine Klasse, die wenig tut außer Kosten verursachen. 13. Spekulative Allgemeinheit tritt oft auf, wenn für die Zukunft mal irgendeine Funktionalität erwartet wird. 14. Temporäre Felder sind Objekte die nur kurzfristig erzeugt werden und gleich wieder zerstört werden. 15. Nachrichtenketten, treten dort auf, wo scheinbar unendlich oft delegiert wird. 16. Vermittler, tritt dann auf, wenn eine Klasse hauptsächlich mit delegieren beschäftigt ist. 17. Unangebrachte Intimität, dies ist der Fall, wenn sich Klassen mit privaten Angelegenheiten anderer Klassen befassen. Kapitel 3 Wartungsprozess 34 18. Alternative Klassen haben verschiedene Schnittstellen. 19. Unvollständige Bibliotheksklasse, hierbei handelt es sich um oft fremde Bibliotheksklassen, die nicht genug Methoden anbieten. 20. Datenklassen bestehen oft nur aus set- und get- Methoden und tun sonst wenig. 21. Ausgeschlagenes Erbe, dabei erben Unterklassen mehr als sie selber brauchen. 22. Kommentare sollen, dort wo Kommentare nötig sind um etwas zu Beschreiben, verwendet werden. Wenn etwas aus dem Code nicht hervorgeht, ist aber auch oft ein Punkt um mit Refaktoring anzusetzen. Um an diesen "übelriechenden Stellen" aktiv werden zu können, ist eine Voraussetzung unbedingt notwendig. Es müssen ausreichend Testfälle vorhanden sein und das Ausführen der Tests muss schnell und effizient gehen. Automatisch ablaufende Tests, die ihre Zwischen- und Endergebnisse selbst vergleichen können sind von größtem Nutzen. Diese Tests sollten laufend verwendet werden, während man Refaktoring anwendet, aber zumindest einmal täglich. [Fowler 2000] Martin Fowler hat in seinem Buch über siebzig Methoden zum Refaktoring zusammengetragen, die eingesetzt werden können, wenn man auf übelriechende Codestücke stößt. Alle Methoden sind ausführlich beschrieben, beginnend mit einem Namen, einer Zusammenfassung, einer Motivation, einer Beschreibung der Vorgehensweise und schließlich mit einem Beispiel. Hier sollen diese Methoden nicht aufgeführt werden, es wird nur eine Liste angeführt, die die Gruppen darstellt in welche die siebzig Methoden zusammengefasst werden. [Fowler 2000] Methoden zusammenstellen Eigenschaften zwischen Objekten verschieben Daten organisieren Bedingte Ausdrücke vereinfachen Methodenaufrufe vereinfachen Umgang mit der Generalisierung Große Refaktoringschritte Im Anhang C findet sich noch eine Liste von Zitaten aus dem Buch von Martin Fowler, die ihm besonders wichtig erscheinen. [Fowler 2000] 3.5 Zusammenfassung Fehler, Änderungen bei den Rahmenbedingungen und Änderungen bei den Anforderungen sind die Ereignisse, auf die in der Wartungsphase reagiert werden muss. Reaktionen sind Stabilisierung, Optimierung, Anpassung und Erweiterung. Die ersten beiden Reaktionen fast man als korrektive Tätigkeiten oder Wartung zusammen und die letzten beiden Reaktionen fast man als progressive Tätigkeiten oder Pflege zusammen. Ungefähr 80% der Tätigkeiten in der Wartungsphase sind unter Pflege einzuordnen. Für die Wartungsphase von großer Bedeutung ist, dass zuerst die Wartung durchgeführt wird und Pflege immer erst auf einem konsolidierten Produkt durchgeführt wird. Kapitel 3 Wartungsprozess 35 Änderbarkeit und Übertragbarkeit sind die Eigenschaften die auf den Aufwand bei Wartung und Pflege einen Einfluss haben. Wartung und Pflege ihrerseits beeinflussen die Zuverlässigkeit und Effizienz eines Produktes. Beim Support Tracking System war das Verhältnis von Pflege- zu Wartungsarbeiten in einem ähnlichen Verhältnis (80:20) und die Erstellung neuer Versionen begann immer mit der Konsolidierung der Vorgängerversion. Agile Software Prozesse verlangen ein inkrementelles iteratives Vorgehen. Diese Prozesse stützen sich auf die Annahme, dass unter Einhaltung bestimmter Ansätze, Software leicht änderbar ist und damit auf Änderungen in den Anforderungen reagiert werden kann. Es wird zwischen Konkreten und Meta Prozessen unterschieden. Meta Prozesse beschränken sich auf die Aufstellung von Regeln, wie auf Prozessebene vor zu gehen ist. Konkrete Prozesse sind detaillierter und geben auch an welche Artefakte zu erstellen sind oder welche Praktiken die Softwareentwickler anwenden sollen. Das Manifest der agilen Softwareentwicklung streicht heraus, dass Personen und Interaktionen, laufende Systeme, Zusammenarbeit mit den Kunden und auf Veränderungen reagieren zu können wichtiger ist, als Prozesse und Werkzeuge, umfangreiche Dokumentation, Verträge und Pläne. Der Prozess eXtreme Programming leitet aus den Eigenschaften Kommunikation, Einfachheit, Feedback und Mut die Grundprinzipien schnelles Feedback, Einfachheit anstreben und erhalten, inkrementelle Schritte, Änderungen begrüßen und Qualitätsarbeit anstreben ab. Zusammen mit weiteren Nebenprinzipien führt dies schließlich zu zwölf Praktiken für die Softwareentwickler. Unter diesen zwölf Praktiken gibt es die Gruppe bestehend aus einfachem Design, Refaktoring und Testen. Im Rahmen dieser Arbeit wurde versucht, diese Praktiken anzuwenden. Refaktoring ist ein Satz von Umstrukturierungstechniken, die es einem Softwareentwickler erlauben den Entwurf eines Systems zu verändern ohne die Funktionalität des Systems zu zerstören. In Summe gibt es über 70 Ansätze auf über 20 verschiedene Schwächen im Entwurf zu reagieren. Bei der Wartung und Pflege vom Support Tracking System, wurde Refaktoring aber nicht nur eingesetzt um den Entwurf des Systems zu verbessern, sondern auch für Wartungs- und Pflegeaufgaben und um das System in ein adaptierbares System umzuwandeln. Im Kapitel 7 werden die Erfahrungen mit diesen Arbeitsweisen geschildert. Im nachfolgenden Kapitel 4 wird der interne Aufbau des Support Tracking Systems dargestellt. Kapitel 4 Systembeschreibung In diesem Kapitel wird der Aufbau vom Support Tracking Systems beschrieben. Diese Beschreibung beginnt mit dem Hyperwave Information Server, welcher als Plattform für Support Tracking System dient. Die am Institut für Informationssysteme und Computer Medien entwickelte Hyperwave Library (HWLIB) führt eine Abstraktionsebene über dem API des Hyperwave Information Server ein. Die Architektur vom Support Tracking System basiert auf dieser Bibliothek. Ein abschließender Abschnitt beschreibt die Funktionalität des Support Tracking Systems aus der Sicht der Benutzer. 4.1 Hyperwave Information Server Der Hyperwave Information Server bildet serverseitig die Grundlage für das Support Tracking System. Die in dieser Arbeit beschriebene Version STS V1.3 des Support Tracking Systems verwendet die Version HWIS V5.1.1. Da für den Hyperwave Information Server umfangreiche Dokumentation vorhanden ist, wird in diesem Abschnitt nur ein kurzer Einblick in die Architektur und das für die Entwicklung benötigte Application Interface (API) des Hyperwave Information Servers gegeben. [Hyperwave 1999] [Hyperwave 1999a] [Hyperwave 1999b] Der Hyperwave Information Server ist modular aufgebaut. Die einzelnen Module sind in drei Ebenen angeordnet. "database layer" bildet die unterste Ebene. Sie besteht aus "object server", "full text server" und "document cache server". Die mittlere Ebene wird als "session layer" bezeichnet und enthält das Modul "hgserver". Die oberste Ebene wird als "protocol conversion layer" bezeichnet und besteht aus dem Modul "wavemaster". [Hyperwave 1999] Das Modul "object server" wird entweder von "wavestore" oder von "waveoracle" realisiert. "wavestore" sorgt für die Anbindung an die native Datenbank. Das Modul "waveoracle" übernimmt die Datenhaltung, falls eine Oracle Datenbank zur dauerhaften Objektspeicherung verwendet wird. Das "object server" Modul realisiert eine SchreibLese-Datenbank für mehrere Benutzer und verwaltet alle Objekte und alle Objektbeziehungen. Dazu zählen Dokumente, Collections, bidirektionale Hyperlinks, Kapitel 4 Systembeschreibung 37 Benutzerbeschreibungen und Serverbeschreibungen. Objektbeziehungen beschreiben Mitgliedschaft in einer Collection und Links. [Hyperwave 1999] Das Modul "full text server" bildet einen Volltextserver. Es verwaltet Indizes und Wortlisten und übernimmt Suchanfragen. Als Ergebnis einer Suchanfrage liefert es eine geordnete Liste von Objektidentitäten. Wie schon beim "object server" gibt es auch hier die Möglichkeit, das Hyperwave Modul durch ein Modul eines Fremdherstellers zu ersetzen. [Hyperwave 1999] Das Modul "document cache server" hält die aktuellen Dokumente und bedient die Clients mit lokalen Dokumenten. Er erhält Dokumente von den Clients und von fernen Servern und gibt diese auch an die Clients weiter. Dieses Modul ist auch für die Ausführung von CGI Skripts zuständig. Alle drei hier beschriebenen Module der untersten Schicht verwenden HG-CSP27 als Protokoll zur nächsten Schicht. [Hyperwave 1999] Die mittlere Schicht hat die Bezeichnung "session layer" und wird vom Modul "hgserver" realisiert. Der "hgserver" teilt größere Operationen auf und leitet diese elementare Operationen seriell an die Datenhaltungsebene weiter. Dadurch wird verhindert, dass größere Requests sich gegenseitig blockieren. Dieses Modul führt ein Caching der häufig verwendeten Objekte durch und überprüft die Zugangsberechtigung der Benutzer. "hgserver" stellt außerdem die Verbindung zu entfernten Hyperwave Information Servern her. Für jeden zu bedienenden Client wird ein "hgserver" gestartet. Das Modul "wavemaster" stellt einen möglichen Client dar. Die Lebensdauer des "hgserver" ist auf die Lebensdauer einer Verbindung zu einem Client beschränkt bzw. endet nach Ablauf eines Timeouts. Für alle Verbindungen wird HG-CSP verwendet HG-CSP ist ein verbindungsorientiertes und zustandbehaftetes Protokoll. [Hyperwave 1999] Das Modul "wavemaster" übernimmt im "protocol conversion layer" die Aufgabe den Hyperwave Information Server an das World Wide Web (WWW) anzubinden. Es gehört zur Hauptaufgabe dieses Moduls, die Verbindung zwischen dem verbindungslosen und zustandslosen Protokoll HTTP28 und dem verbindungsorientierten und zustandbehafteten Protokoll HG-CSP herzustellen. Es führt eine Transformation der separaten Hyperwave Information Server Links zu den engebettenden Links von HTML29 durch. Erst durch den "wavemaster" wird der Hyperwave Information Server durch Webclients wie Netscape Navigator oder Microsoft Internet Explorer bedienbar. Das Modul "wavemaster" sorgt auch für die Darstellung der Serverinhalte (Collections, Suchformulare, Dokumente usw.) in einem sogenannten Standardinterface. Das Standardinterface ermöglicht Dokumentensuche und Authoring von Dokumenten. Das Erscheinungsbild kann mit Hilfe von PLACE verändert werden. In diesem Modul ist außerdem die JavaScript Engine untergebracht und in dieser Engine läuft der serverseitige Teil vom Support Tracking System ab. [Hyperwave 1999] Das Hyperwave Application Programming Interface (HW-API) definiert eine sprachunabhängige, abstrakte Schnittstelle. Sie erlaubt es Programmierern die 27 HyperG - Client Server Protocol (HG-CSP) HyperText Transfer Protocol (HTTP) 29 HyperText Markup Language (HTML) 28 Kapitel 4 Systembeschreibung 38 Funktionalität des Servers zu erweitern. Das HW-API erlaubt den Zugriff auf Serverobjekte mit Funktionen auf einer hohen Abstraktionsebene. Im HW-API spiegeln sich die Serverobjekte als Datentypen wieder. Diese sind im Sinne einer Objektorientierung mit Zugriffsmethoden ausgestattet. Die grundlegenden Strukturen umfassen ein Zugriffsmodul, Datentypen und Operatoren. Das Zugriffsmodul verfügt über Methoden zum Öffnen von Sitzungen, zum Identifizieren, zum Beziehen von Objekten mittels einer eindeutigen Identifikation, zum Beziehen des Inhaltes einer Collection oder zum Einfügen eines Dokumentes. Die Datentypen umfassen sowohl einfache Typen, wie "string" oder "name-value-pairs", aber auch abstraktere Konzepte zur Dokumentrepräsentation. Mit Hilfe der Operatoren lassen sich Sortierparameter oder Selektoren für Attribute festlegen. Eine konkrete Realisierung dieser abstrakten Schnittstelle ist die Implementierung für die Skriptsprache JavaScript im "wavemaster". HW_API_Attribute, HW_API_Object, HW_API_ObjectArray, HW_API_Reason, HW_API_Error, HW_API_Content, HW_API_Server, KeyValue, KeyValueField, OptionParser, HTMLJavaScriptParser, SendMail, File und Directory sind die Klassen die dem Programmierer zur Verfügung stehen. JavaScript Prototypen ermöglichen eine Spezialisierung dieser Objekte durch Vererbungsmechanismen. Die Instanzen server, request, response, wavemaster, client und einige globale Funktionen stehen in der Wavemasterumgebung immer zur Verfügung. [Hyperwave 1999a] 4.2 HWLIB Es wurden zahlreiche Anwendungen entwickelt, die auf dem Hyperwave Information Server basieren. Diese Anwendungen wurden entweder von Hyperwave oder von Partnerunternehmen implementiert. Die Web Application Group am Institut für Informationssysteme und Computer Medien ist solch ein Entwicklungspartner für Hyperwave. Die Web Application Group entwickelte die Hyperwave Library (HWLIB) mit den Zielen die Softwareentwicklung zu verbessern und zu beschleunigen. Vorteile der Bibliothek HWLIB sind Wiederverwendbarkeit, Modularität, Stabilität, Erweiterbarkeit, Einfachheit, verbesserte Qualitätssicherung und Unterstützung von OOP30 unter JavaScript31. [Wurzenberger 1999] Die Kernelemente der Bibliothek HWLIB sind die Generatoren für HTML-Formulare und für JavaScript Objekte für am Hyperwave Information Server abgelegt Objekte. Für die Dateneingabe oder Datenänderung werden bei Webapplikationen HTML-Formulare verwendet. Der Formulargenerator sorgt für ein gleichmäßiges Erscheinungsbild aller HTML-Formulare einer Webapplikation. Die vom Formulargenerator zur Verfügung gestellten Methoden entbinden die Programmierer davon eine Menge HTML Code selber erstellen zu müssen. So ist auch sichergestellt, dass alle Formulare einer Applikation ein einheitliches Erscheinungsbild haben. Alle Formulare haben einen einheitlichen Aufbau. Zuoberst wird eine Überschrift mit Subüberschrift platziert und danach folgt die obere Umrahmung. Zumindest ein Formular muss explizit angelegt werden, aber es ist auch möglich mehrere Formulare innerhalb einer Seite zu 30 31 Objekt Orientierte Programmierung (OOP) http://devedge.netscape.com/library/manuals/2000/javascript/1.5/guide/ Kapitel 4 Systembeschreibung 39 verwenden. Innerhalb eines Formulars können dann beliebige viele Formularfelder positioniert werden. Abbildung 4-1: Formulargenerator Die untere Umrahmung schließt das Formular optisch ab. Die OK/Reset/Chancel Buttons werden gewöhnlich außerhalb der Umrahmung platziert. Wie schon der Anfang des Formulars, so wird auch das Ende des Formulars explizit deklariert. hw_FormEntry_Header, hw_FormEntry_TopBorder, hw_FormEntry_BottomBorder, hw_FormEntry_StartForm, hw_FormEntry_EndForm, hw_FormEntry_InputText, Kapitel 4 Systembeschreibung 40 hw_FormEntry_TextArea, hw_FormEntry_DropDownList, hw_FormEntry_RadioButtons, hw_FormEntry_CheckBoxes, hw_FormEntry_Button, hw_FormEntry_FileSelect, hw_FormEntry_OkResetChancel, hw_FormEntry_HorizontalElement und hw_FormEntry_startBrowserButton sind die Methoden, die den Entwicklern zur Verfügung stehen. Abbildung 4-1 zeigt das Support Tracking System Formular zum Anlegen einer neuen zeitablaufgesteuerten Notiz, dass mit Hilfe des Formulargenerators der HWLIB erstellt wird. [Wurzenberger 1999] hw_Object hw_DocumentObject hw_TextObject hw_TextObjectHTML hw_ImageObject hw_GenericObject hw_CollectionObject hw_ClusterObject hw_SequenceObject hw_MultiClusterObject hw_AlternativeClusterObject hw_QueryObject hw_UserManagementObject hw_GroupObject hw_UserObject Abbildung 4-2: Prototypeobjekthierarchie (HWLIB) nach [Wurzenberger 1999] Die Bibliothek HWLIB ist eine Schnittstelle zwischen dem Hyperwave API und der JavaScript Ebene. Die HWLIB bildet die Hyperwave Information Server Objekte, wie zum Beispiel "Collection" oder "Sequence", auf JavaScript Objekte ab. Der Objektgenerator erzeugt zu Hyperwave Information Server Objekten, die entsprechenden JavaScript Objekte. Der Prototype hw_Object stellt die Basismethoden zur Verfügung. Diese Methoden werden allen anderen Prototypeobjekten der HWLIB vererbt. Abbildung 4-2 zeigt die Vererbungshierarchie in der HWLIB. Bereits der Basisprototype hw_Object stellt 14 Attribute und 82 Methoden zur Verfügung. Die Kapitel 4 Systembeschreibung 41 Methoden lassen sich thematisch in die Gruppen generelle Methoden, Methoden zur Objektmanipulation, Methoden für den Zugriff auf die Attribute, Methoden für die Anzeige des Objektes, Methoden um auf die Objekteltern zu zugreifen, Methoden für den Zugriff auf Dateien, Suchmethoden, Methoden um das Objekt am Server einzufügen, Methoden für Formulare und eine Gruppe mit verschiedensten Methoden teilen. Für eine genaue Beschreibung der Attribute und Methoden aller HWLIB Prototypen sei auf [Wurzenberger 1999] verwiesen. 4.3 Support Tracking System im Überblick Das Support Tracking System ist eine Webapplikation, die auf dem Hyperwave Information Server und der HWLIB aufbaut. Die Funktionalität, die vom Support Tracking System zur Verfügung gestellt wird, ist rollenabhängig. Die Benutzer des Systems teilen sich in die drei Rollen Administrator, Dispatcher und Support ein. Dieses Unterkapitel gibt eine kurze Übersicht der wesentlichen Funktionen für die verschiedenen Rollen, beschreibt die Architektur vom Support Tracking System und gibt schließlich eine vollständige Übersicht der gesamten Funktionalität. 4.3.1 Hauptfunktionen aus Benutzersicht Dieses Unterkapitel stellt die Funktionalität des Support Tracking Systems aus der Sicht der verschiedenen Benutzergruppen dar. Mitarbeiter, die mit dem Support Tracking System arbeiten, können in drei verschiedene Rollen eingeteilt werden. Es kann nicht ausgeschlossen werden, dass ein und derselbe Mitarbeiter mehr als eine Rolle ausfüllt. Folgende Rollen werden vom Support Tracking System verwendet: Administrator: Für die Verwaltung vom Support Tracking System sind Administratoren zuständig. Zur Verwaltung zählt zum Beispiel das Anlegen, Ändern oder Löschen von Supportmitarbeitern. Dispatcher: Mitarbeiter in dieser Rolle verteilen die verschiedenen Supportfälle auf die verschiedenen Supportmitarbeiter. Sie berücksichtigen die fachliche Qualifikation und streben eine gleichmäßige Auslastung an. Support: Mitarbeiter dieser Gruppe bearbeiten die einzelnen Supportfälle, welche ihnen vom Dispatcher zur weiteren Bearbeitung zugeteilt wurden. Die Rollen im Support Tracking System sind hierarchisch angeordnet. In der Standardkonfiguration von STS V1.3 sind die Einstellungen so getroffen, dass Funktionalität, die den Mitarbeitern der Gruppe Support zur Verfügung steht, auch den Mitarbeitern der Gruppe Dispatcher zur Verfügung steht. Genauso verhält es sich für die Rollen Dispatcher und Administrator. Somit sind die Support Tracking System Benutzer in der Rolle Administrator jene, denen die volle Funktionalität zu Teil wird. Aufgabe der Administratoren ist es nicht die Supportfälle abzuwickeln, sondern das System zu verwalten. Administratoren sind für die Adaptierung installierter Support Tracking Systeme verantwortlich. Wie Einstellungen und Benutzeroberfläche verändert werden können, findet sich in Kapitel 5 und Kapitel 6. In der Standardkonfiguration von STS V1.3 dürfen nur Administratoren Objekte permanent löschen. Alle anderen Kapitel 4 Systembeschreibung 42 Benutzer können Objekte nur in einen Papierkorb verschieben. Die Verwaltung von Benutzern des Support Tracking Systems liegt in den Händen der Administratoren. Dazu zählen das Anlegen, Verändern und Entfernen von Benutzern. Abbildung 4-3 zeigt zum Beispiel das Formular, welches verwendet wird um Daten eines Supportmitarbeiters zu verändern. Diese Formulare werden vom Formulargenerator der HWLIB erstellt (siehe Unterkapitel 4.2). Ähnliche Formulare werden für das Anlegen und Löschen eines Supportmitarbeiters verwendet. Abbildung 4-3: Verändern von Mitarbeiterdaten Für Mitarbeiter der Rolle Dispatcher sind einige Funktion, die zur Verwaltung des Systems dienen, nicht zugänglich. Ihre Hauptaufgabe ist es für eine gleichmäßige Auslastung der Mitarbeiter zu sorgen. Bei Bedarf können sie Supporttickets von einem Mitarbeiter zu einem anderen Mitarbeiter umschichten (siehe Abbildung 4-4). Dieses Verschieben von Supporttickets ist nicht nur notwendig, wenn eine ungleiche Auslastung der Mitarbeiter vorliegt, sondern auch um einen Spezialisten ein Supportticket zur Bearbeitung zu übertragen. Krankheit oder Urlaub eines Mitarbeiters sind weitere Gründe, warum ein Dispatcher Supporttickets einem anderen Mitarbeiter zuteilen will. Kapitel 4 Systembeschreibung Abbildung 4-4: Supportticket einen neuen Mitarbeiter zuweisen Abbildung 4-5: Formular für das Erzeugen eines Notizeintrages 43 Kapitel 4 Systembeschreibung 44 Die dritte Gruppe der Benutzer vom Support Tracking System fallen in die Rolle Support. In der Standardkonfiguration von STS V1.3 stehen Benutzern, die zu dieser Rolle gehören, am wenigsten Funktionen zur Verfügung. Meldet ein Kunde ein Problem, so ist die erste Aufgabe des Supportmitarbeiters ein Supportticket anzulegen. Dazu verwendet er das vom Formulargenerator der HWLIB erzeugte Formular aus Abbildung 4-6. Am Anfang des Formulars werden Daten zum Kunden und zur Kontaktperson, die das Problem gemeldet hat, erhoben. Danach folgen Angaben zum Supportticket und wie mit dem Supportticket zu verfahren ist. Ein Block aus domänenspezifischen Attributen beschreibt das Setup in welchem das Problem aufgetreten ist. Das Supportticket erhält einen Titel und eine Prosabeschreibung des Problems. Mit dem Supportticket kann bereits eine erste Notiz gemacht werden. Die Notiz wird nicht für die Kundenbenachrichtigung verwendet. Die Prosabeschreibung wird dem Kunden mittels E-Mail mitgeteilt, falls die Benachrichtigung im letzten Abschnitt des Formulars eingeschaltet wird. Ein ähnliches Formular wird verwendet um die Einträge eines Supporttickets zu ändern. Ist ein Supportticket angelegt, dann ist es in der Ticketsammlung des Supportmitarbeiters sichtbar. Abbildung 6-9 zeigt wie eine Ticketsammlung aussehen kann. Wird ein Supportfall bearbeitet, dann machen die Supportmitarbeiter Notizen, protokollieren Telefongespräche mit den Kunden oder versenden E-Mails an Kunden oder Experten, die sie um Rat bitten. Abbildung 4-5 zeigt das Formular zum Erstellen einer Notiz. In Abbildung 4-1 ist das Formular zum Erstellen einer ablaufgesteuerten Notiz zu sehen. Supportmitarbeiter versuchen Supportfälle mit den Daten aus bereits gelösten Supportfällen zu lösen. Mit der Suche des Support Tracking Systems versuchen sie ähnliche Fälle zu finden. Das Suchformular (Abbildung 4-7) ermöglicht eine zeitliche Einschränkung der Suche im Bezug auf Erstellung, Änderung und Abschluss der Supporttickets. Für die Suche im Domänenbereich, im welchem das Support Tracking System eingesetzt wird, dienen die Supportticket Attribute. Bei den Supportticket Attributen kann man aus den Listen auswählen oder Eingaben in den Freitextfeldern machen. Die Suche beim Support Tracking System erlaubt auch eine Volltextsuche. Die Attributsuche und die Volltextsuche sind kombinierbar. Der Suchbereich kann auf den gesamten Server, auf das Support Tracking System oder auf die dem Mitarbeiter zugewiesene Supporttickets beschränkt werden. Abbildung 4-8 zeigt ein mögliches Suchergebnis. Wenn die Fundstelle nicht ein Supportticket ist, wird die gesamte Hierarchie aufwärts bis zum Supportticket, welches die Fundstelle enthält, dargestellt. Sieht sich der Supportmitarbeiter ein Supportticket näher an, dann erhält er eine Darstellung ähnlich wie in Abbildung 6-10. Kapitel 4 Systembeschreibung Abbildung 4-6: Anlegen eines neuen Supporttickets 45 Kapitel 4 Systembeschreibung Abbildung 4-7: Neue Suchabfrage erstellen 46 Kapitel 4 Systembeschreibung 47 Abbildung 4-8: Suchergebnis 4.3.2 Architektur des Support Tracking Systems Die Software Architektur vom Support Tracking System baut auf der Architektur der Bibliothek HWLIB auf. Die Support Tracking System Prototypeobjekte leiten sich von den HWLIB Prototypeobjekten hw_Object, hw_CollectionObject, hw_QueryObject und hw_ClusterObject ab. Diese vier Prototypeobjekte finden sich in der linken Hälfte der Abbildung 4-9. Auf der rechten Seite finden sich die Prototypeobjekte des Support Tracking Systems. [Gössler 1999] Nachfolgend werden die Objekte des Support Tracking Systems, die am Hyperwave Server abgelegt werden und im laufenden Programm in JavaScript Objekte umgewandelt werden, kurz beschrieben. Die meisten dieser Prototypeobjekte waren schon Bestandteil früherer Versionen des Support Tracking Systems. Eine Beschreibung für STS V1.0 findet sich in [Gössler 1999]. sts_Object stellt globale Funktionen und Definitionen zur Verfügung. Es wird bei jedem Request erzeugt. sts_TicketContainerObject ist eine Hyperwave Collection, die beliebig viele Supporttickets beinhalten kann. Diese Ticketsammlung ist nötig, da nicht alle Kapitel 4 Systembeschreibung 48 Supporttickets Mitarbeitern zugeteilt sein müssen und stellt außerdem Abstraktion der Ticketsammlungen, die zu Supportmitarbeitern gehören, dar sts_StaffMemberObject ist eine Erweiterung von sts_TicketContainerObject. Objektinstanzen von diesem Prototypeobjekt beinhalten Werte, die einen spezifischen Supportmitarbeiter beschreiben. Supporttickets die sich in solch einer Collection befinden, sind dem zugehörigen Supportmitarbeiter zur Erledigung zugeteilt. hw_Object sts_CustomerObject hw_CollectionObject sts_Object sts_TicketContainerObject sts_StaffMemberObject sts_TicketObject hw_QueryObject sts_QueryObject hw_ClusterObject sts_TicketEntryObject sts_TicketEntryEmailObject sts_TicketEntryPhoneNoteObject sts_TicketEntryScheduleObject sts_TicketEntryNoteObject Abbildung 4-9: Prototypeobjekthierarchie (STS) nach [Gössler 1999] sts_TicketObject ist die Repräsentation von Supportfällen. Ein Supportticket besteht aus einer Reihe den Supportfall beschreibender Attribute, einen beschreibenden Textblock und einer Sammlung von Ticketeinträgen. Kapitel 4 Systembeschreibung 49 sts_CustomerObject ist die Repräsentation eines Kunden. Supportfälle werden von Kunden berichtet. Wird für einen Supportfall ein Supportticket angelegt, werden auch die Kundendaten hinzugefügt. sts_QueryObject leitet sich vom hw_QueryObject ab. Dieser Queryobjekte sind eine Besonderheit des Hyperwave Information Servers. Queryobjekte werden beim Support Tracking System für das Erstellen von Berichten verwendet. sts_TicketEntryObject ist eine Abstraktion für alle Arten von Ticketeinträgen. Dieses Prototypeobjekt stellt alle gemeinsam benötigten Methoden zur Verfügung. sts_TicketEntryNoteObject, sts_TicketEntryEmailObject, sts_TicketEntryPhoneNoteObject und sts_TicketEntryScheduleObject sind Spezialisierungen von sts_TicketEntryObject und stellen die spezifischen Methoden der Subtypen zur Verfügung. 4.3.3 Funktionalität des Support Tracking Systems Mit der Version STS V1.3 ist die Zuordnung der Funktionalität zu den Rollen nicht mehr starr. Die Zuordnung kann vom Betreiber der Software verändert werden. Eine Beschreibung der Zuordnung von Rollen und Funktionen findet sich in 5.4. Die nachfolgende Liste der Funktionen berücksichtigt die Rollenzugehörigkeit nicht. Kernelement vom Support Tracking System ist das Supportticket. Funktionen die sich auf Tickets operieren sind: new_ticket: Diese Funktion ermöglicht es über ein umfangreiches Formular ein neues Supportticket anzulegen. Es werden zahlreiche beschreibende Daten und eine Beschreibung des Problems in Textform erfasst. Kundendaten gehören genauso zu den erfassten Daten, wie eine Beschreibung der Softwarekonstellation, die das Problem hervorrief. create_ticket_email, create_ticket_note, create_ticket_phonenote: Supporttickets erhalten mit der Zeit immer mehr Einträge in Form von E-Mails, Notizen und Telefonprotokollen. Diese Einträge können in eigenständige Tickets umgewandelt werden. Erfolgt dies werden die gleichen Daten erhoben, wie beim Erstellen eines neuen Tickets. Mit dem Unterschied, dass für die Beschreibung des Problems der bestehende Eintrag herangezogen wird. assign_ticket_to_staff: Mit dieser Funktion wird ein Supportticket in die Ticketsammlung eines Supportmitarbeiters gestellt und diesem somit zur Bearbeitung zugeteilt. modify_ticket: Fallweise kann es vorkommen, dass sich die Daten eines Tickets ändern bzw. falsch eingeben wurden. Mit dieser Funktion sind Änderungen und Korrekturen möglich. change_status: Supporttickets kennen verschiedene Stati von neu bis erledigt. Diese Funktionalität erlaubt es den Status eines Tickets zu ändern. close_ticket: Ist ein Supportfall abgeschlossen, so kann das Supportticket mit all seinen Einträgen archiviert werden, um für zukünftige, ähnliche Probleme wichtige Informationen zu liefern. Kapitel 4 Systembeschreibung 50 remove_ticket: Sollte man einmal wirklich der Meinung sein, dass ein Ticket nicht mehr benötigt wird, dann kann man es auch in den Papierkorb verschieben. Tickets sind im Support Tracking System das zentrale Element, aber nicht minder wichtig sind die Einträge in Form von Notizen und E-Mails bei den Tickets. add_note, add_phonenote, add_schedulenote und add_email: Mit Hilfe dieser Funktionen werden Ticketeinträge gemacht. Die vier Grundtypen für Ticketeinträge sind Notizen, Telefongesprächsprotokolle, ablaufgesteuerte Notizen und E-Mails. Bei Notizen gibt es einfache Notiz, Frage/Antwort, Arbeitsliste und Zusammenfassung als Untertypen. remove_note, remove_phonenote, remove_schedulenote und remove_email: Wie schon für Tickets angeführt, gibt es auch für die Ticketeinträge die Möglichkeit, diese in den Papierkorb zu verschieben. modify_schedulenote: Die ablaufgesteuerten Notizen sind die einzigen Einträge für die eine Funktion zum Ändern des Inhaltes vorhanden ist. Geändert werden kann hier aber nur der Ablaufzeitpunkt, nicht aber der Inhalt der Notiz. Verwendung findet diese Art von Notizen von Supportmitarbeitern um sich damit an vereinbarte Fristen zu erinnern. reply_email, forward_email: Die oben beschriebene Funktion add_email macht natürlich nicht nur einen Ticketeintrag, sondern verschickt auch eine E-Mail an den Adressaten. Achtet der Kunde beim Beantworten von E-Mails darauf, dass er die Ticketidentifikation nicht aus der E-Mailtitelzeile löscht, so kann das Support Tracking System selbstständig E-Mails vom E-Mailserver hohlen und sie als Ticketeinträge beim richtigen Ticket ablegen. Der Supportmitarbeiter erkennt an einer speziellen Kennzeichnung der Tickets, dass ein E-Mail zum Supportticket eingegangen ist. Der Mitarbeiter kann auf E-Mails antworten oder diese an gewünschte Stellen, vom Support Tracking System aus, weiterleiten. Diese E-Mails werden natürlich wiederum zu Ticketeintragen gemacht. assign_email: E-Maileinträge können von einem Ticket zu einem anderen Ticket verschoben werden. Eine weitere wichtige Komponente vom Support Tracking System ist die Abbildung der Supportmitarbeiter im System. Jeder Supportmitarbeiter hat eine eigene Sammlung von Tickets, die er zu bearbeiten hat. new_staffmember: Im Regelfall sollte das Support Tracking System so konfiguriert sein, dass zumindest Mitarbeiter mit der Rolle Administrator neue Mitarbeiter ins System einfügen können. Dabei werden Daten wie Name, Telefonnummer und E-Mailadresse erfasst und eine eigene Collection angelegt. In der Collection werden Tickets abgelegt, die dem Mitarbeiter zugeteilt sind. modify_staffmember: Daten eines Supportmitarbeiters müssen aktualisierbar sein, falls sich zum Beispiel E-Mailadresse oder Telefonnummer ändern. remove_staffmember: Von Fall zu Fall scheiden Mitarbeiter aus einem Unternehmen aus. Diese Funktion sollte aber erst dann Verwendung finden, wenn alle Tickets neuen Mitarbeitern zugeordnet wurden. Beim Löschen des Mitarbeiters wird der Inhalt der Collection, das sind die offenen Supportfälle ebenfalls in den Papierkorb verschoben. Kapitel 4 Systembeschreibung 51 Das Support Tracking System bietet für die Suche mächtige Werkzeuge an. new_search: Stellt ein umfangreiches Formular zur Verfügung um eine Suchabfrage zu erstellen. Es kann nach Tickets mit bestimmten Attributen (Metadaten) gesucht werden. Auch eine Volltextsuche kann initiiert werden. Beide Suchtypen sind kombinierbar. Suchabfragen müssen nicht immer neu eingeben werden, sondern es besteht auch die Möglichkeit die vorangegangene Suche zu modifizieren. new_query, modify_query, remove_query: Für sehr erfahrene Hyperwave Information Server Anwender gibt es auch noch die Möglichkeit, sogenannte Queryobjekte zu erzeugen, zu verändern und in den Papierkorb zu verschieben. Diese Queryobjekte haben allerdings eine schwierige Syntax und werden deshalb leider nur wenig verwendet. Im Prinzip stellen sie permanente Suchabfragen dar, die ihr Ergebnis ständig in einer Kollektion bereithalten. Queryobjekte können für die laufende Berichterstattung verwendet werden. Weniger wichtig sind die beiden folgenden Funktionen. attribute: Listet alle Attribute eines Tickets in einer speziellen Ansicht auf, die sich am Erscheinungsbild der Standardoberfläche des Hyperwave Information Server der Version 5.1.1 orientiert. history: Zu jedem Ticket wird eine Art Logbuch geführt, welches bei Bedarf eingesehen werden kann. Alle Aktivitäten rund um ein Ticket, werden mit Zeitstempel und Kurzbeschreibung im Logbuch erfasst. Funktionen fürs tägliche Leben der Supportmitarbeiter sollen auch noch kurz Erwähnung finden: identify: Mit Namen und Passwort meldet man sich beim System an. Ohne Identifikation hat man keinen Zugriff auf Daten und Funktionen des Support Tracking Systems. changepasswd: Von Zeit zu Zeit sollte man das Passwort ändern home: Dient als Navigationshilfe und bringt den Benutzer immer in seine Ticketsammlung zurück. Folgende Funktionen haben große Auswirkung auf das Support Tracking System und sollten mit entsprechender Umsicht Rollen zugeordnet bzw. verwendet werden. Beide Funktionen sind der ausgelieferten Benutzeroberfläche nicht erreichbar, könnten aber durch Adaptierung, wieder zugänglich gemacht werden. remove_container: STS ist in seiner Datenhaltung hierarchisch organisiert, dazu werden sogenannte Collections verwendet. Diese können in einem Stück in den Papierkorb verschoben werden. Durch die hierarchische Anordnung werden auch Subcollections mitgelöscht. remove_sts: Diese Funktion entfernt alle Daten unwiederbringlich vom Hyperwave Information Server. einer STS Installation Da alle Löschfunktionen nur in den Papierkorb verschieben, gibt es noch eine letzte Funktion. empty_trashcan: Mit dieser Funktion kann der komplette Papierkorb entleert werden, dieses Entleeren ist allerdings unwiederbringlich. Kapitel 4 Systembeschreibung 52 4.4 Zusammenfassung Der Hyperwave Information Server bildet die Basis für das Support Tracking System. Für die Implementierung wurde aber nicht nur das Hyperwave Application Programming Interface verwendet. Das Support Tracking System nutzt auch die Möglichkeiten der Hyperwave Library (HWLIB). Die Bibliothek HWLIB führt eine weitere Abstraktionsebene ein und erlaubt die Generierung von JavaScript Objekten zu den im Support Tracking System vorhandenen Objekten. Für die Generierung der notwendigen HTML Formulare stellt die HWLIB einen eigenen Formulargenerator zur Verfügung. Das Support Tracking System kennt drei Gruppen von Benutzern. Die Rollen Administrator, Dispatcher und Support haben unterschiedliche Aufgaben und Funktionen. Administratoren sollen die Mitarbeiter im Support Tracking System verwalten. Dispatcher sorgen für die gleichmäßige Verteilung der Supportfälle. Die Mitarbeiter in der Rolle Support betreuen die Kunden bei ihren Problemen. Wie Funktionen des Support Tracking Systems einzelnen Rollen zugeordnet werden ist Teil vom Kapitel 5. Kapitel 5 beschreibt die Möglichkeit zur Adaptierbarkeit auf Systemebene. Kapitel 6 zeigt, wie diese Möglichkeit sich in die Benutzeroberfläche eingliedern. Diese Möglichkeiten zur Adaptierung des Support Tracking Systems stehen den Administratoren zur Verfügung. II. Gestaltungsteil Kapitel 5 Adaptierbare Systemeigenschaften Im Verlauf dieser Arbeit entstanden vom Support Tracking System die Version STS V1.1, STS V1.2 und STS V1.3. Bei allen Versionen wurden Wartungsarbeiten in Form von Fehlerbehebung und Pflegearbeiten in Form von neuer Funktionalität durchgeführt. Mit der Version STS V1.3 wurde das Softwaredesign durch Refaktoring deutlich verbessert. Die Zugänglichkeit zu den Systemeigenschaften für den Benutzer und die durch den Benutzer veränderbare Benutzeroberfläche sind die großen Änderungen der Version STS V1.3. Die adaptierbaren Systemeigenschaften werden in diesem Kapitel beschrieben. Die adaptierbare Benutzeroberfläche wird in Kapitel 6 beschrieben. 5.1 Allgemeines Ein System, welches dem Benutzer erlaubt bestimmte Parameter und Verhalten des Systems zu verändern, wird als adaptierbares System bezeichnet. Systeme die sich selbständig auf Grund von Annahmen über den Benutzer verändern werden adaptive Systeme genannt. [Fink et. al. 1997] Im Rahmen dieser Arbeit wurden Wartungs- und Pflegearbeiten am Support Tracking System durchgeführt. Eine Unterscheidung der Begriffe Wartung und Pflege gibt Kapitel 3. Bei diesen Arbeiten zeigte sich, dass einige Arbeiten immer wieder Daten betrafen die leider Teil des Quellcodes waren. Um die Wartungskosten zu senken wurden diese Daten aus dem Quellcode durch Refaktoring (siehe Unterkapitel 3.4) extrahiert. Diese Daten beschreiben und steuern das Systemverhalten des Support Tracking Systems. Dieses Kapitel beschäftigt sich eingehend mit den adaptierbaren Systemeigenschaften. Wartungskosten zu senken war nur ein Grund für diese Maßnahme. Ein weiterer Grund war das Support Tracking System verschiedenen Kunden zur Verfügung stellen zu können. Hyperwave stellte auch die Forderung nach einer neuen Benutzeroberfläche für das Support Tracking System auf. Sowohl die adaptierbaren Systemeigenschaften als auch die Anforderung die Benutzeroberfläche für Kunden adaptieren zu können, führten zu einer adaptierbaren Benutzeroberfläche (siehe Kapitel 6). Mit STS V1.3 kam es zu einer Trennung von Eigenschaftsdaten und Quellcode. Erst diese Trennung ermöglicht adaptierbare Systemeigenschaften. Kapitel 5 Adaptierbare Systemeigenschaften 55 Unterkapitel 5.2 beschreibt, wie Werte für die Attribute der Supporttickets über Dateien zur Verfügung gestellt werden können. In früheren Versionen waren diese Werte Bestandteil des Quellcodes. Die Kundendatenbank wurde aus dem Quellcode entfernt und in eigene Dateien ausgelagert. Unterkapitel 5.3 beschäftigt sich eingehender mit der Kundendatenbank. Administrator, Dispatcher und Support sind die möglichen Rollen der Support Tracking System Benutzer. Unterkapitel 5.4 zeigt, wie man die verschiedenen Funktionen des Support Tracking Systems für die verschiednen Rollen ein- und ausschaltet. Das Support Tracking System unterstützt ein Eskalationsmodell. Wie Zeitspannen für dieses Eskalationsmodell gesetzt werden können, findet sich im Unterkapitel 5.5. Die Implementierung erfolgte im wesentlichen durch die Klasse "sts_AttributeInterfaceObject" und wird im Unterkapitel 5.6 beschrieben. Diese Klasse kapselt die Konfigurationsdateien und besitzt eine festgelegte Schnittselle. Sollten in den nächsten Entwicklungsschritten die Dateien mit den Kundendaten durch eine vollwertige Kundendatenbank ersetzt werden, so muss nur noch diese Klasse angepasst werden. Der Rest des Systems wäre durch eine solche Änderung nicht betroffen. Unterkapitel 5.7 zeigt die Möglichkeit auf verschiedensprachige Texte für die automatischen Kundenbenachrichtigungen zu verwenden. Unterkapitel 5.8 fasst das gesamte Kapitel zusammen. In der Datei "..\wavemaster-sts-5.1\sts\config.js" wird eine Variable "CUSTOMIZEPATH" wie folgt gesetzt: var CUSTOMIZEPATH = "wavemaster-sts-5.1/sts/customize"; Dieses Verzeichnis enthält alle Dateien, die zur Konfiguration von STS V1.3 notwendig sind. Durch die Verwendung einer Variablen für den Verzeichnispfad, ist es leicht mit verschiedenen Konfigurationsvarianten von STS V1.3 zu arbeiten. Allerdings werden Änderungen an der JavaScript Datei "config.js" erst nach einem Neustart des sogenannten Waveslaves aktiv. Änderungen an den Konfigurationsdateien werden hingegen unmittelbar wirksam. Sobald ein Benutzer des Support Tracking Systems eine Funktion aufruft oder weitere Information, wie zum Beispiel ein anderes Supportticket, abruft, sind die geänderten Konfigurationsdaten wirksam. 5.2 Werte für die Ticketattribute Supporttickets sind nicht nur eine Sammlung von Einträgen wie Notizen oder E-Mails, sondern enthalten auch Attribute, die den Supportfall näher beschreiben. Diese Ticketattribute werden beim Erzeugen eines Tickets gesetzt und fallweise geändert. Für viele Ticketattribute sind Wertetabellen vorgegeben und für die folgenden Ticketattribute wurden die Werte in Dateien abgelegt. Der vollständige Name der Dateien besteht aus dem Namen des Ticketattributes und der angefügten Extension ".dat". sts_ticketStatuscs ist eine Tabelle, die die möglichen Ticketstatuswerte für die Ticketoperationen "ticket close" und "ticket suspend" enthält. Im neuen Userinterface wurden diese beiden Operationen durch "finish request" ersetzt. Kapitel 5 Adaptierbare Systemeigenschaften 56 sts_ticketStatus beinhaltet alle möglichen Ticketstatuswerte für verschiedene Ticketoperationen mit Ausnahme für die Operationen "ticket close" und "ticket suspend". sts_source Werte geben die mögliche Quelle eines Supportfalles bekannt, diese können zum Beispiel E-Mails oder Telefonate sein. sts_product ist eine Tabelle der von der Supportabteilung betreuten Produkte. sts_release beinhaltet die Versions- und Releasenummern der betreuten Produkte. Diese Tabelle besteht aus mehreren Untertabellen, wobei die Reihenfolge den Einträgen in sts_product entspricht. Dadurch kann eine Abhängigkeit zum gewählten sts_product Wert realisiert werden. sts_platform ist eine Tabelle die Einträge zu verschiedenen Plattformen und Betriebssystemen enthält. sts_hwModule ist eine Tabelle verschiedener Komponenten des Hyperwave Information Server. Die Grundkonfiguration des Support Tracking Systems ist für die Hyperwave Support Abteilung zugeschnitten. Diese Abteilung betreut Kunden, die den Hyperwave Information Server einsetzen. sts_client beinhaltet Werte, die den verschiedenen Clientprogrammen des Hyperwave Information Server entsprechen, wie zum Beispiel verschiedene Webbrowser oder Virtual Folders. sts_category beinhaltet Werte, die eine grobe Klassifizierung des Problems vornehmen, d.h. handelt es sich um ein Problem mit der Suche, mit der Dokumentation, mit der Performance und vieles mehr. sts_escalation beinhaltet Werte, die beschreiben unter welches Supportmodell der betroffene Kunde fällt und wird zur Berechnung von Reaktionszeiten verwendet. Eine Besonderheit des Ticketattributes "sts_ticketStatus" ist, dass gleich zwei Dateien existieren. Zum einem die Datei sts_ticketStatuscs.dat und zum anderem die Datei sts_ticketStatus.dat. Der Status eines Tickets kann beim Anlegen bzw. beim Modifizieren des Tickets bestimmt werden. Dabei stehen alle Stati aus der Datei sts_ticketStatus.dat zur Verfügung. Außerdem besteht die Möglichkeit, auf ein Ticket die Operation "Finish Request" anzuwenden, wobei das Ticket erneut sein Attribut "sts_ticketStatus" verändert. Diesmal sind aber nur die Werte aus sts_ticketStatuscs.dat möglich. Alle Datenfiles die Ticketattributdaten enthalten sind nach dem gleichen Schema aufgebaut. Im Prinzip handelt es sich dabei um einfache Listen. Jede Zeile entspricht einem Attributwert und wird mit einem Strichpunkt abgeschlossen. Die nachfolgende Zeile ist ein Beispiel für eine Datenzeile und ist der Konfigurationsdatei sts_escalation.dat entnommen. InputValue:"Standard", DisplayStoreValue:"Standard"; Dabei kann man erkennen, dass diese Dateien zwei Spalten enthalten. In der ersten Spalte stehen die InputValue Einträge und in der zweiten die DisplayStoreValue Kapitel 5 Adaptierbare Systemeigenschaften 57 Einträge. Die Ursache, warum jedes Listenelement aus zwei Werten besteht, ist in STS V1.2 zu suchen. Die InputValue Werte sind jene Werte, die bei den entsprechenden Ticketattributen in den Formularen "Ticket anlegen", "Ticket modifizieren" und "Suchformular" zur Auswahl stehen. Der Wert unter DisplayStoreValue ist der korrespondierende Wert, der dann als Wert beim entsprechenden Ticketattribut gespeichert wird und beim Anzeigen eines Tickets dann auch ausgegeben wird. Wie an den Hochkommata zu erkennen ist, können diese Werte auch Leerzeichen enthalten. Beim Ändern oder Erweitern der Konfigurationsdateien, sollte darauf geachtet werden Werte ohne Leerzeichen zu verwenden. Das Entfernen eines Eintrages hat zur Folge, dass dieser in den Formularen für Ticketanlegen, Ticketmodifizieren, sowie im Suchformular fehlt Damit die Daten für die Ticketattribute ins System gelangen, müssen bestimmte Einträge in der Konfigurationsdatei sts_ticketAttributes.dat vorhanden sein. Diese Datei ist analog zu jenen Dateien aufgebaut, in denen die Werte der einzelnen Ticketattribute gespeichert werden. Jede Zeile enthält einen Datensatz und wird von einem Strichpunkt abgeschlossen. Die einzelnen Spaltenelemente werden durch Beistriche getrennt. Jedes Spaltenelement besitzt eine Bezeichnung und mit einem Doppelpunkt davon getrennt den eigentlichen Wert. In der ersten Spalte stehen die Werte mit der Bezeichnung "Name", welche die Namen der einzelnen Ticketattribute beinhaltet. Man sollte die Datei sts_ticketAttributes.dat nicht als reine Konfigurationsdatei verstehen, sondern auch ein wenig als Informationseinheit. In dieser Datei werden alle Ticketattribute, die in STS V1.3 Tickets Verwendung finden, aufgelistet und nicht nur jene die vom Benutzter gesetzt werden. In der zweiten Spalte finden sich die Werte mit der Bezeichnung "Generation". Diese Werte geben zum entsprechenden Attributnamen an, wie die Ticketattribute erstellt werden. Drei Arten sind hier zu unterscheiden: HWIS_automatic Ticketattribute werden vom Hyperwave Information Server für jedes Ticket gesetzt und verwaltet. STS_automatic Ticketattribute werden vom Support Tracking System für jedes Ticket gesetzt und verwaltet. Input Ticketattribute sind jene Ticketattribute, die zur Anpassung an die Produktionsbedingungen dienen. Durch diese Anpassung wird das Support Tracking System für verschiedene Support Abteilungen nutzbar. Bezeichnungen für Ticketattribute, die in die Gruppen "HWIS_automatic" und "STS_automatic" angegeben werden, stehen für die Konfiguration durch den Benutzer nicht zur Verfügung. Zeilen, die in der Spalte mit der Bezeichnung "Generation" den Wert "Input" eingetragen haben, enthalten eine weiter Spalte mit der Bezeichnung "Formular". Für die Spalte mit der Bezeichnung "Formular" werden folgende Werte vom System unterstützt. Textline zeigt an, dass der Wert für das Ticketattribut nicht aus einer Werteliste ausgewählt wird. Der Benutzer gibt den Wert über eine Textzeile ein. Textarea zeigt an, dass der Wert für das Ticketattribut nicht aus einer Werteliste ausgewählt wird, sondern durch Eingabe eines größeren Textblockes erfolgt. Kapitel 5 Adaptierbare Systemeigenschaften 58 List zeigt an, dass für dieses Ticketattribut eine Liste von Werten zur Auswahl steht. Die Werte für dieses Ticketattribut werden der entsprechenden Konfigurationsdatei entnommen. -List zeigt an, dass für dieses Ticketattribut noch die Funktionen von STS V1.2 verwendet werden. Spätere Versionen sollten eventuell auf den Typ "List" umstellen. Davon betroffen sind die Ticketattribute "sts_customerNotified" und "sts_priority". OverList wird zusammen mit dem Typ "SubList" verwendet. Dabei handelt es sich um eine spezielle Liste, die eine Unterliste verwendet, die in einer eigenen Konfigurationsdatei gespeichert ist. SubList stellt die Unterliste zu Verfügung. "OverList" und "SubList" werden im Bereich der Kundendatenbank verwendet. Es ist geplant diese auf Dateien basierende Kundendatenbank durch eine "echte" Datenbank zu ersetzen. CombineList ist der Kombination "OverList" und "SubList" ähnlich. In diesem Fall wird die Unterliste allerdings nicht in einer getrennten Konfigurationsdatei abgelegt. SystemList ist eine Liste, die nicht konfigurierbar ist. Diese Listen sind von den Laufzeitdaten des Systems abhängig. In der Beispielkonfiguration betrifft dies die Liste der Supportmitarbeiter für das Ticketattribut "sts_staff". Bei STS V1.3 werden alle Listentypen aus Konfigurationsdateien eingelesen. Zukünftige Versionen des Support Tracking Systems könnten diese Information mit der Bezeichnung "Formular" auch dafür nützen, adaptierbare Formulare für das Anlegen und Verändern von Tickets zu verwenden. Eine weitere Spalte mit der Bezeichnung "Searchable" könnte dazu verwendet werden, festzulegen welches Ticketattribut im Suchformular vorhanden sein soll und welches nicht. Die Ticketattribute sts_customer und sts_CustomerContactPerson werden der Kundendatenbank entnommen. Da die Listen der Kundendatenbank ein wenig von anderen Listen abweichen, findet sich unter 5.3 eine ausführliche Beschreibung dieser Kundendatenbank. 5.3 Kundendatenbank Unter STS V1.2 waren die Kundendaten im Quellcode integriert. Mit STS V1.3 wurden diese Daten in eigene Dateien ausgegliedert. Die Dateien custom_db.dat und customer.csv bilden zusammen die Kundendatenbank. Die Datei custom_db.dat enthält eine Beschreibung, wie die Datei customer.csv aufgebaut ist, welche die eigentlichen Kundendaten enthält. Der Aufbau der Datei custom_db.dat folgt dem gleichen Schema, welches auch bei den Ticketattributen verwendet wurde. Das Schema ist spaltenorientiert und jeder Spalteneintrag enthält eine Bezeichnung und einen mittels Doppelpunkt getrennten Wert. Spaltenelemente werden durch Beistriche getrennt und Zeilen werden mit einem Strichpunkt abgeschlossen. In der Datei custom_db.dat finden sich neben der Bezeichnung "entry" folgende Werte: identityNumber ist eine eindeutige Nummer. Jedem Kunden ist eine solche eindeutige Nummer zugeordnet. customer enthält eine Bezeichnung für den Kunden, dies ist meist der Firmenname. Kapitel 5 Adaptierbare Systemeigenschaften 59 cpFirstName enthält den Vornamen einer Kontaktperson beim Kunden. Zu einem Kunden können mehr als eine Kontaktperson gehören. cpSurname enthält den Nachnamen der Kontaktperson beim Kunden. cpEmail enthält die E-Mailadresse der Kontaktperson beim Kunden. cpPhone enthält die Telefonnummer der Kontaktperson beim Kunden. cpLanguage enthält eine Angabe über die Muttersprache der Kontaktperson beim Kunden. cpEscalationModel enthält eine Angabe in welches Supportmodell die betreffende Kontaktperson fällt. Die zweite Spalte enthält Einträge mit der Bezeichnung "column". Diese beziehen sich auf die Position in der Datei customer.csv, an welcher die Werte für "identityNumber", "customer", "cpFirstName", "cpSurname", "cpEmail", "cpLanguage" und "cpEscalationModel" zu finden sind. Die Datei customer.csv ist vom Typ "comma separated values". Eine Zeile dieser Datei entspricht genau einer Kontaktperson. Darauf ist zu achten, sollte diese Datei aus einer Excel Tabelle erstellt werden. Kopfzeilen, die Spaltennamen enthalten, sind gegebenenfalls zu entfernen. In jeder Zeile müssen mindestens so viele durch Beistriche getrennte Felder vorkommen, dass Vorname und Nachname der Kontaktperson vorhanden sein können. Leerzeilen und Zeilen mit zu wenig Feldern werden nicht berücksichtigt. Dies bedeutet aber nicht, das Vorname und Nachname angegeben werden müssen, sondern nur, dass die Felder vorhanden sein müssen. Gibt es zu einem Kunden mehr als eine einzige Kontaktperson, so müssen diese in aufeinanderfolgenden Zeilen eingetragen werden. Dabei ist wesentlich, dass alle die gleiche Kundennummer haben. Einträge mit unterschiedlichen Kundennummern werden vom Support Tracking System als unterschiedliche Kunden interpretiert. Ab der zweiten Kontaktperson eines Kunden, kann die Kundennummer auch entfallen. Als Eskalationsmodell wird für alle Kontaktpersonen der Wert der ersten Kontaktperson des Kunden verwendet. Wird bei der ersten Kontaktperson kein Wert angegeben, so ist der Wert für das Eskalationsmodell für alle Kontaktpersonen "Standard". Unterschiedliche Einträge in den nachfolgenden Kontaktpersonen werden ignoriert. 5.4 Rollenabhängige Funktionalität STS V1.3 kennt drei Benutzergruppen. Diese Gruppen werden auch als Rollen bezeichnet. Die Zugehörigkeit eines Benutzers zu einer Rolle, wird durch die Zugehörigkeit zu Benutzergruppen im Hyperwave Information Server System bestimmt. Folgende Rollen sind vorhanden: administrator ist eine Rolle, welcher die Verwaltung des Support Tracking Systems obliegt. Aufgaben sind zum Beispiel das Neuanlegen oder Verwalten der Supportmitarbeiter. dispatcher ist eine Rolle, die primär die Aufgabe hat vorhandene Supportfälle bzw. Supporttickets auf die verschiedenen Supportmitarbeiter zu verteilen. Kapitel 5 Adaptierbare Systemeigenschaften 60 support ist jene Gruppe von Mitarbeitern, die ihnen zugeteilte Supportfälle bearbeiten. Zum Beispiel können Angehörige dieser Gruppe Ticketeinträge machen und Ticketbeschreibungen verändern. Hat ein Benutzer des Support Tracking Systems mehr als eine Rolle, so wird der Benutzer immer der in der Hierarchie höheren Rolle zugeteilt. Damit keine Probleme auftreten sollte Funktionalität, die der Rolle Support zugerordnet wird, auch immer den Rollen Dispatcher und Administrator zugeordnet werden. Analog sollten Möglichkeiten der Dispatcher immer auch Administratoren eingeräumt werden. Die Konfigurierung der rollenabhängigen Funktionen erfolgt mit den Konfigurationsdateien action_role.dat und move_to.dat. Die Konfigurationsdatei action_role.dat legt in STS V1.3 fest, welche Funktionen für welche Rollen verfügbar sind. Auf der neuen Benutzeroberfläche von STS V1.3 werden nur jene Funktionen dem Benutzer zu Verfügung gestellt, welche für seine Rolle vorgesehen sind. Wie Funktionen in die Benutzeroberfläche eingebunden werden, wird detaillierter in Kapitel 6 beschrieben. Die Konfigurationsdateien action_role.dat und move_to.dat haben den üblichen Aufbau. Jede Zeile enthält einen Datensatz und wird mit einem Strichpunkt abgeschlossen. Die Elemente innerhalb der Zeile werden durch Beistriche getrennt und besitzen eine Bezeichnung vor dem eigentlichen Wert, der durch einen Doppelpunkt von der Bezeichnung getrennt ist. In der ersten Spalte werden die Funktionen angeführt. Diese Spalte hat die Bezeichnung "action". Es folgen vier weitere Spalten mit den Bezeichnungen "no_role", "support", "dispatcher" und "administrator". Die Werte unter dem Label "no_role" werden für nicht identifizierte Benutzer und für Benutzer, die keiner STS V1.3 Rolle zugeordnet werden können, verwendet. Die restlichen drei Spalten sind für die entsprechenden Rollen Support, Dispatcher und Administrator. Folgende Funktionen des Support Tracking Systems werden in diesen beiden Dateien aufgezählt: identify ist eine Funktion um sich beim Support Tracking System anzumelden. Diese Funktion sollte für alle Rollen verfügbar sein, damit sich bereits angemeldete Benutzer mit einer anderen Identität neu anmelden können. change_passwd ist eine Funktion mit der man das Passwort neu setzen kann. Dies sollte jeder Benutzer regelmäßig tun. new_search ist eine Funktion, die über ein umfangreiches Formular eine Detailsuche über alle Supporttickets ermöglicht. home ist eine Funktion, die zum Hauptverzeichnis des aktuell angemeldeten Benutzers führt. Jeder Benutzer des Support Tracking Systems besitzt ein eigenes Hauptverzeichnis, welches alle ihm zugeordneten Supportfälle enthält. new_staffmember ist eine Funktion zum Anlegen eines neuen Benutzers. Dabei wird die Rolle des neuen Benutzers bestimmt und ein Hauptverzeichnis eingerichtet. new_query ist eine Funktion, die mit Hilfe eines Formulars spezielle Hyperwave Information Server Queryobjekte erzeugt. Diese Queryobjekte stellen ihre Abfrageergebnisse in eigenen Verzeichnissen dar. Kapitel 5 Adaptierbare Systemeigenschaften 61 new_ticket mit dieser Funktion kann der Supportmitarbeiter ein Supportticket zu einem Supportfall erstellen. Dabei werden verschiedene Daten zum Kunden und zum Problem erfasst. assign_ticket_to_staff mit dieser Funktion werden Supportfälle verschiedenen Supportmitarbeitern zugeteilt. Dabei wird das Supportticket in das Verzeichnis des entsprechenden Mitarbeiters verschoben. add_email mit dieser Funktion kann ein E-Mail zum konkreten Supportfall erstellt und verschickt werden. Anschließend wird das E-Mail als Ticketeintrag zum Ticket hinzugefügt. add_phonenote mit dieser Funktion kann ein Telefongespräch, welches den konkreten Supportfall betrifft, protokolliert werden. Die Phonenote wird als Ticketeintrag zum Ticket hinzugefügt. add_note mit dieser Funktion können zu einem Supportfall Anmerkungen gemacht werden. Wiederum werden die Eingaben als Ticketeintrag dem Ticket hinzugefügt. add_schedulenote mit dieser Funktion können Supporttickets mit Erinnerungen versehen werden. Diese Erinnerungen machen sich nach Ablauf einer Zeitmarke bei jenem Supportmitarbeiter bemerkbar, dem dieser Supportfall zugeordnet ist. change_status diese Funktion wird im graphischen User Interface von STS V1.3 mit "Finish Request" bezeichnet. Dabei wird der Status des Supporttickets entweder auf "suspended" oder "closed" gesetzt und in ein entsprechendes Verzeichnis verschoben. close_ticket ist ein Eintrag, der unter STS V1.3 noch nicht aktiv ist. Dieser Eintrag sollte den Eintrag "change_status" ablösen, da dieser für seine Funktion eine irreführende Bezeichnung darstellt. modify_ticket mit dieser Funktion kann der Supportmitarbeiter die Daten zum Kunden und zum Supportfall eines Supporttickets verändern. modify_staffmember mit dieser Supportmitarbeiters verändert werden. modify_query ist ein Eintrag, der unter STS V1.3 noch nicht aktiv ist. Mit dieser Funktion kann der Supportmitarbeiter ein vorhandenes Hyperwave Information Server Queryobjekt verändern. Diese Funktion wird im graphischen User Interface an der gleichen Stelle wie "modify_staffmember" angeboten. Diese Funktion wird unter STS V1.3 durch "modify_staffmember" gesteuert und erscheint nur, wenn das aktuell angezeigte Objekt ein Queryobjekt ist. remove_ticket ist eine Funktion, die unter STS V1.2 ein Supportticket vollständig aus dem System gelöscht hat. Mit dieser Funktion kann ein Supportmitarbeiter unter STS V1.3 ein Supportticket in den Papierkorb verschieben. remove_staffmember war unter STS V1.2 eine Funktion, die alle Einträge eines Supportmitarbeiters aus dem Support Tracking System gelöscht hat. Weil bei dieser Funktion alle zugeordneten Supporttickets mitgelöscht wurden, wird diese Funktion unter STS V1.3 nicht mehr unterstützt. Dieser Eintrag ist unter STS V1.3 inaktiv. Funktion können die Daten eines Kapitel 5 Adaptierbare Systemeigenschaften 62 remove_query ist eine Funktion, die es ermöglichte unter STS V1.2 ein Hyperwave Information Server Queryobjekt zu löschen. Diese Funktion ist unter STS V1.3 inaktiv. remove_container ist eine Funktion, die ein Verzeichnis vollständig vom System entfernt. Mit dieser Funktion konnte man unter STS V1.2 alle Einträge aller Supportmitarbeiter vom System entfernen. Diese Funktion ist unter STS V1.3 inaktiv. remove_sts ist eine Funktion, die alle Daten einer Support Tracking System Installation vom Hyperwave Information Server in einem Schritt entfernt. Diese Funktion ist unter STS V1.3 inaktiv. header_body_footer ist eine Funktion, die unter STS V1.2 Teile der Hyperwave Information Server Standardoberfläche ein- und ausblendet. Weil mit der neuen Benutzeroberfläche von STS V1.3 diese Teile der Standardoberfläche nicht mehr verwendet werden, ist diese Funktion unter STS V1.3 inaktiv. modify_schedulenote ist eine Funktion Erinnerungszeitpunkt zu verändern. remove_email ist eine Funktion, die vom Supportmitarbeiter dazu benutzt wird EMails in den Papierkorb zu verschieben. remove_phonenote ist eine Funktion, die vom Supportmitarbeiter dazu benutzt wird Telefonprotokolle in den Papierkorb zu verschieben. remove_note ist eine Funktion, die vom Supportmitarbeiter dazu benutzt wird, Ticketnotizen in den Papierkorb zu verschieben. remove_schedulenote ist eine Funktion, die vom Supportmitarbeiter dazu benutzt wird, Erinnerungen in den Papierkorb zu verschieben. trash_email, trash_phonenote, trash_note, trash_schedulenote, trash_ticket sind unter STS V1.3 noch nicht aktiv. In Zukunft sollten diese Einträge die entsprechenden "remove" Einträge ersetzen, weil die Namensgebung intuitiver ist. empty_trash ist eine Funktion, die unter STS V1.3 noch nicht implementiert ist. Der Papierkorb kann unter STS V1.3 zum Beispiel mit Hilfe der Virtual Folders oder der Java Virtual Folders geleert werden. Dieser Eintrag ist unter STS V1.3 inaktiv. create_ticket_email ist eine Funktion, die es ermöglicht ein im Support Tracking System erfasstes E-Mail in ein eigenes Supportticket umzuwandeln. create_ticket_phonenote ist eine Funktion, die es ermöglicht aus einem Telefonprotokoll ein eigenständiges Supportticket zu machen. create_ticket_note ist eine Funktion, die es dem Supportmitarbeiter erlaubt aus einer Notiz eines Supporttickets ein neues Supportticket zu generieren. reply_email ist eine Funktion um ein im Support Tracking System bestehendes EMail zu beantworten. Die Antwort wird als E-Maileintrag beim Supportticket abgelegt. forward_email ist eine Funktion um ein im Support Tracking bestehendes E-Mail an einen beliebigen Empfänger weiterzuleiten. Da dabei der Inhalt der E-Mail um den Erinnerungstext oder Kapitel 5 Adaptierbare Systemeigenschaften 63 verändert werden kann, wird auch das weitergeleitete E-Mail als E-Maileintrag beim Supportticket abgelegt. assign_email ist eine Funktion, die es ermöglicht E-Mails innerhalb des Support Tracking Systems zu verschieben. Primär wird diese Funktion verwendet um vom System nicht eingeordnete E-Mails an das richtige Supportticket anzuhängen. Mit dieser Funktion kann man auch E-Mails von einem Supportticket zu einem anderen Supportticket verschieben. move_email ist eine Funktion, die unter STS V1.3 nicht aktiv ist. Alle inaktiven Einträge könnten aus der Datei entfernt werden. Diese Einträge geben Hinweise in welche Richtung die Konfigurierbarkeit des Systems weiterentwickelt werden könnte. In der Konfigurationsdatei action_role.dat finden sich in den vier Spalten mit den Bezeichnungen "no_role", "support", "dispatcher" und "administrator" die Werte "yes" und "no". Der Wert "yes" bedeutet, dass die Funktion dieser Zeile der entsprechenden Rolle zur Verfügung steht. Funktionen für die der Wert "no" eingetragen ist, werden Benutzern der entsprechenden Rolle vom System nicht angeboten. Die Datei move_to.dat ist unter STS V1.3 nicht aktiv. Diese Möglichkeit zur Konfiguration des Systems konnte aus Zeitgründen nicht realisiert werden. Sie deutet an, wie man das Problem der sogenannten Ticketverfolgung lösen könnte. Benutzer möchten abhängig von ihrer Rolle vom System unterschiedlich geführt werden. Benutzer in verschiedenen Rollen möchten nach Abschluss einer Funktion unterschiedliche Informationen vom System präsentiert bekommen. An den Stellen, wo in der Konfigurationsdatei action_role.dat die Werte "yes" und "no" stehen, stehen in der Konfigurationsdatei move_to.dat folgende Werte: sts_root ist das Basisverzeichnis einer Support Tracking System Installation. Nach Abschluss einer Funktion, zeigt das Support Tracking System dem Benutzer das Basisverzeichnis. root nach Beendigung der entsprechenden Funktion zeigt das Support Tracking System das Basisverzeichnis des Hyperwave Information Server. home nach Beendigung der Funktion wird dem identifizierten Benutzer sein eigenes Basisverzeichnis gezeigt. this nach Beendigung der Funktion wird das gleiche Element dem Benutzer gezeigt. Verschiebt ein Benutzer zum Beispiel ein Supportticket, so wird nach Abschluss der Funktion wiederum dieses Supportticket dargestellt. In diesem Fall hat sich allerdings der Kontext geändert, d.h. ein Verzeichniswechsel hat stattgefunden. ticket nach Beendigung der Funktion wird wieder das gleiche Supportticket angezeigt. Dies ist zum Beispiel nützlich beim Verschieben einer E-Mail. new findet dort Verwendung wo ein neues Element erstellt wird. Wird zum Beispiel ein Supportticket, eine E-Mail oder eine Notiz erstellt, so wird nach der Fertigstellung genau dieses Element dem Benutzer angezeigt. parent bedeutet, dass man sich nach Abschluss einer Funktion genau eine Hierarchieebene höher befindet. Supporttickets und Verzeichnisse bilden im Support Tracking System ein hierarchisches Gebilde. Kapitel 5 Adaptierbare Systemeigenschaften 64 Die Konfigurationsdatei move_to.dat gibt für jede Funktion in Abhängigkeit von der Rolle an, welches gespeicherte Objekt aus dem Support Tracking System angezeigt werden soll. Im Unterkapitel 5.6 wird die Implementierung der bisher beschriebenen Konfigurationsmöglichkeiten dargestellt. 5.5 Eskalationszeiten Eine weitere Datei, die zur Konfiguration vom Support Tracking System eingelesen wird, ist escalationTime.dat. Da diese Datei keine Werteliste für ein Ticketattribut ist, muss diese Datei auch nicht in der Datei sts_ticketAttributes.dat eingetragen werden. Diese Datei enthält die vorgeschriebenen Antwortzeiten in Abhängigkeit von Priorität und Supportmodell. Jede Zeile enthält die Werte für ein Modell und jede Zeile endet wieder mit einem Strichpunkt. Die Spalteneinträge sind wiederum mit Bezeichnungen versehen. In der ersten Spalte ist die Bezeichnung "escalation" zu finden, gefolgt von einem Modell-Namen nach dem Doppelpunkt. Bei den Modellnamen handelt es sich um: Standard entspricht dem Normalfall. Dies ist jenes Supportmodell, das die meisten Kunden erwerben. Premium entspricht jenem Supportmodell, das von jenen Kunden gekauft wird, die eine bevorzugte Behandlung wünschen oder benötigen. Eval entspricht jenem Supportmodell, das für jene Kunden gedacht ist, die ein Produkt nur zur Evaluierung einsetzen und nicht zu Produktionszwecken. In jeder Zeile finden sich dann noch durch Beistriche getrennt die Bezeichnungen, die zugleich die Prioritäten von STS V1.3 sind: High der Supportfall hat höchste Priorität. Das aufgetretene Problem hindert den Kunden daran seinem Geschäft nachzugehen. Medium der Supportfall hat mittlere Priorität. Das aufgetretene Problem beschränkt die Tätigkeit des Kunden. Low, L1-Low, L2-Low sind für Supportfälle mit niedriger Priorität. Das aufgetretene Problem beschränkt die Tätigkeit des Kunden nicht oder nur in sehr geringem Umfang. Die Werte, die hinter den Prioritätsbezeichnungen angeben werden, sind die Anzahl der Stunden, innerhalb derer die Supportmannschaft zu reagieren hat. 5.6 Implementierung Die Klasse sts_AttributeInterfaceObject wird einmal im globalen Variablenscope als Objekt stsCustomize instanziert. Dieses Objekt bildet dann die Schnittstelle zu den Konfigurationsdaten. Eine Ausnahme bilden die Daten für die adaptierbare Benutzeroberfläche. Diese werden durch eine eigene Schnittstelle eingelesen (siehe Kapitel 6). Tabelle 5-1 enthält eine Übersicht und kurze Beschreibung Kapitel 5 Adaptierbare Systemeigenschaften 65 Methoden der Klasse sts_AttributeInterfaceObject. Die Klasse sts_AttributeInterfaceObject sorgt für die notwendige Schnittstelle zwischen aller dem Support Tracking System und den Daten zur Konfiguration. Werte für Ticketattribute, Kundendatenbank, rollenabhängige Funktionalität und verschiedene Eskalationszeiten werden dadurch möglich. E-Mails zur Kundenbenachrichtigung sind auch konfigurierbar, verwenden aber nicht diese Schnittstelle. Eine genauere Beschreibung findet sich im nachfolgenden Unterkapitel 5.7. Name der Methode Beschreibung readData Das Schnittstellenobjekt stsCustomize liest mit dieser Methode alle Konfigurationsdaten ein. Diese Methode wird aufgerufen, wenn das Support Tracking System vom Schnittstellenobjekt zum erstenmal Daten benötigt. readTicketAttributList Die readData delegiert an readTicketAttributList das Einlesen der Konfigurationsdatei mit allen Ticketattributen. readAttributeValues Sind dem Schnittstellenobjekt stsCustomize die Ticketattribute bekannt, dann werden die möglichen Ticketattributwerte mit Hilfe von readAttributeValues eingelesen. Dies wird für alle Ticketattribute durchgeführt, die unter der Bezeichnung "Formular" den Wert "List" eingetragen haben. makeListElement Diese Methode wandelt die einzelnen Datenzeilen der Ticketattributwertedateien in ein internes Format um. getOptions Diese Methode des Schnittstellenobjektes stsCustomize liefert dem Support Tracking System Werte für ein bestimmtes Ticketattribut. Die Werte sind so aufbereitet, dass sie direkt für die Pulldownauswahlen der Formulare verwendbar sind. readActionsAndRoles Diese Methode liest jene Datei ein, die als Information enthält, welche Funktionen für welche Rolle zugänglich sind. testActionAllowed Mit dieser Methode überprüft das Support Tracking System, ob es eine bestimmte Funktion für die Rolle des aktuellen Benutzers verwenden darf. readCutomerDataBase Das Schnittstellenobjekt stsCustomize delegiert an diese Methode das Einlesen der Kundendatenbank. getCustomerDataBase Diese Methode liefert die Kundendatenbank in einer Form an das Support Tracking System, sodass sie in den clientseitigen Skripts der entsprechenden Formulare verwendbar ist. Kapitel 5 Adaptierbare Systemeigenschaften Name der Methode 66 Beschreibung testInEscalationModels Überprüft beim Einlesen der Kundendatenbank, ob der angegebene Wert für das Eskalationsmodell einer Kontaktperson gültig ist. getEscalationTime Liefert die Eskalationszeit in Abhängigkeit von der Priorität an das Support Tracking System. readEscalationTimes Diese Methode liest die Reaktionszeiten verschiedenen Eskalationsmodelle ein. für die Tabelle 5-1: Methoden der Klasse sts_AttributeInterfaceObject 5.7 Kundenbenachrichtigung Auf Wunsch wird beim Anlegen eines neuen Supporttickets vom Support Tracking System automatisch E-Mails an den Kundenkontakt versendet. Auf diese Weise wird dem Kunden mitgeteilt, dass sein Anliegen erfasst wurde. Im File sts_notifyemail.js ist es möglich, einige Einstellungen dafür zu treffen. Mit der Variable DEFAULT_NOTIFY_LANGUAGE ist es möglich eine Sprache einzustellen, die für die Verständigung mittels E-Mail verwendet werden soll, wenn für den Kundenkontakt die Muttersprache nicht bekannt ist. Weiters kann man für beliebig viele Sprachen einen Text für die E-Mailüberschrift und für den E-Mailtext einfügen. Dafür gibt es zwei JavaScript Arrays, eines mit dem Namen NOTIFY_SUBJECT und eines mit dem Namen NOTIFY_TEXT. Die Sprache gibt man, wie unten im Beispiel zu sehen ist, an (hier für Englisch): NOTIFY_SUBJECT["en"] = "…"; NOTIFY_TEXT["en"] = "…"; NOTIFY_SUBJECT wird für den Titel des E-Mails verwendet. Dabei gibt es den Unterschied, ob ein Ticket aus einem E-Mail erstellt wird oder nicht. Wird ein Ticket aus einer E-Mail erstellt, so wird nicht der hier gespeicherte Text verwendet, sondern der Titel der E-Mail aus der das neue Ticket erstellt wird. Vorangestellt wird "Re:" und am Ende wird die Ticketnummer in runden Klammern angefügt. Dadurch kann das Support Tracking System E-Mails, die der Kunde als Antwort schickt, diesem Ticket zuordnen und automatisch einfügen. Bei nicht aus E-Mails erstellten Tickets, wird der Titel aus dem Text von NOTIFY_SUBJECT in Abhängigkeit von der Sprache gebildet, gefolgt vom Titel des neuen Tickets und wiederum in runde Klammern die Ticketnummer angehängt. NOTIFY_TEXT wird für den Textkörper der E-Mails verwendet. Dabei werden zunächst entweder die ersten zehn Zeilen jener E-Mail verwendet aus der das neue Ticket erstellt wurde oder die ersten zehn Zeilen der Beschreibung des neuen Tickets. Daran anschließend wird der Text von NOTIFY_TEXT, in Abhängigkeit von der Sprache des Kunden, angehängt. Kapitel 5 Adaptierbare Systemeigenschaften 67 5.8 Zusammenfassung Die Einführung von Möglichkeiten zur Adaptierung beim Übergang von STS V1.2 zu STS V1.3 stellen einen gelungenen Schritt zum Refaktoring der Implementierung vom Support Tracking System dar. Unter STS V1.2 konnten Änderungen nur direkt im Quellcode vorgenommen werden. Das System konnte von der einsetzenden Abteilung nicht konfiguriert werden. Mit STS V1.3 ist es nun möglich das Support Tracking System mit Hilfe einfacher Textdateien zu konfigurieren. Unter STS V1.3 kann der Administrator, der Zugriff auf die Systemdateien hat, das System adaptieren. Er kann festlegen, welche Attribute zu einem Support Ticket gehören. Für jedes dieser Attribute können Werte vorgegeben werden. Die Funktionen des Support Tracking Systems können für Rollen freigegeben werden. Für die verschiedenen Eskalationsmodelle können Fristen festgelegt werden. Die Kundendaten wurden extrahiert und in eigenen Dateien abgelegt. Der Zugriff auf die Adaptierungsdaten erfolgt über eine abstrakte Schnittstelle. Wird die dateibasierende Kundendatenbank durch eine echte Datenbankanbindung ersetzt, muss nur noch die Implementierung dieser Schnittstelle geändert werden. Die hier beschriebenen Änderungen sind nur ein erster Schritt das Support Tracking System adaptierbar zu machen. Die adaptierbare Benutzerführung wurde nur angedacht, aber noch nicht vollständig umgesetzt. Der Teil für die Kundenbenachrichtigung ist noch aus dem Quellcode zu entfernen. Es gäbe auch noch die Verbesserungsmöglichkeit XML für die Strukturierung der Textfiles zu verwenden. Im nachfolgenden Kapitel 6 wird gezeigt, wie diese Konfigurationsmöglichkeiten im graphischen Benutzer Interface eingearbeitet werden können und wie das Erscheinungsbild von STS V1.3 verändert werden kann. Kapitel 6 Adaptierbare Benutzeroberfläche Dieses Kapitel widmet sich ausschließlich der neuen Benutzeroberfläche von STS V1.3. Bei der Version STS V1.0 lag der Fokus auf der Implementierung der Funktionalität. Die Versionen STS V1.1 und STS V1.2 dienten zur Fehlerbehebung und zur Erweiterung der Funktionalität. Mit der Version STS V1.3 wurde mit der Implementierung der Benutzeroberfläche, der zweite große Entwicklungsschritt des Support Tracking Systems gesetzt. Die adaptierbare Ausführung der Benutzeroberfläche ermöglicht zwei wesentliche Eigenschaften. Zum einem kann die Benutzeroberfläche an geänderte Systemeigenschaften, wie zum Beispiel neue Ticketattribute angepasst werden. Zum anderen ist es mit dieser Ausführung möglich verschiedene Oberflächen zu entwickeln. Möglichkeiten die Systemeigenschaften von STS V1.3 zu adaptieren werden im Kapitel 5getrennt behandelt. Dieses Kapitel beschreibt zunächst die Ausgangssituation, d.h. die Erzeugung der Benutzeroberfläche unter STS V1.2. Anschließend folgt eine kurze Beschreibung der Änderungen unter STS V1.3. Die Details zu STS Tags, HTML Vorlagen und Implementierung finden sich in den Unterkapiteln. 6.1 Ausgabe unter STS V1.2 Alle JavaScript Objekte, die vom HWLIB Objektgenerator zu Hyperwave Server Objekten generiert werden, haben zwei Methoden zur Darstellung. Dabei handelt es sich um die Methoden displayContent und displayObject der HWLIB Basisklasse hw_Object. Eine Beschreibung des Objektgenerators findet sich im Unterkapitel 4.2. Tabelle 6-1 zeigt, welche Klassen diese Methoden überschreiben und welche Klasse diese Methoden erben. Klasse displayContent displayObject sts_Object überschreiben erben sts_QueryObject überschreiben überschreiben sts_StaffmemberObject überschreiben erben sts_TicketObject überschreiben überschreiben Kapitel 6 Adaptierbare Benutzeroberfläche sts_CustomerObject 69 erben erben überschreiben überschreiben erben erben sts_TicketEntryEmailObject überschreiben überschreiben sts_TicketEntryNoteObject überschreiben überschreiben sts_TicketEntryPhoneNoteObject überschreiben überschreiben sts_TicketEntryScheduleNoteObject überschreiben überschreiben sts_TicketContainerObject sts_TicketEntryObject Tabelle 6-1: Ausgabemethoden Abbildung 6-1: Sicht auf die Ticketdarstellung unter STS V1.2 Vererbung erfolgt über die Prototypenhierarchie von HWLIB und STS (siehe Abschnitt 4.3.2). Zusammen mit den Methoden displayActionInterface, displayActualUser und STSdisplayNavigation der STS V1.2 Klasse Kapitel 6 Adaptierbare Benutzeroberfläche 70 sts_Object generierte STS V1.2 eine Benutzeroberfläche, wie unter Abbildung 6-1 zu sehen ist. Im ersten Abschnitt vor der ersten horizontalen Linie, wird der Hyperwave Header aus dem Standardtemplatesatz des HWIS 5.1.1 dargestellt. Im zweiten Abschnitt, zwischen der ersten und zweiten horizontalen Linie, findet man den Namen des aktuellen Benutzers. Danach folgt eine Navigationshilfe von STS V1.2, die es erlaubt, in der Verzeichnishierarchie rasch nach oben zu navigieren. Darunter befindet sich ein großer Block, der in Gruppen unterteilt, alle möglichen Funktionen von STS V1.2 enthält. Im dritten Abschnitt werden entweder die Tickets mit ihren Ticketeinträgen, oder eine Auflistung aller Tickets eines Supportmitarbeiters, wie in Abbildung 6-1 ersichtlich, dargestellt. Im vierten und letzten Abschnitt folgt der Verzeichnisbaum gefolgt von einer Fußzeile. Beides wird vom Standardtemplatesatz des HWIS 5.1.1 erstellt. Die Abschnitte am Anfang und am Ende, die vom Standardtemplatesatz des HWIS 5.1.1 erstellt werden, können ein- und ausgeblendet werden. Da all diese Methoden HTML Code direkt durch "write" Befehle schrieben, waren Änderungen nur möglich, wenn man HTML Kenntnisse hatte und JavaScript Programmiererfahrung besaß, sodass man wusste, in welcher Methode welche Anweisung zu ändern war. Ziel war es somit ab STS V1.3 die Entwicklung der Funktionalität von der Entwicklung der Benutzeroberfläche zu trennen. 6.2 Ausgabe unter STS V1.3 Mit STS V1.3 ist es nun erstmals möglich, dass Erscheinungsbild des Support Tracking Systems zu ändern, ohne in den Quellcode eingreifen zu müssen. Dazu wurden sogenannte HTML Vorlagen für die einzelnen Objekte des Support Tracking Systems angelegt. Diese HTML Vorlagen sind mit speziellen Platzhaltern, den sogenannten STS Tags, versehen. Diese STS Tags sind in HTML Kommentaren eingebettet, sodass die HTML Vorlagen mit jedem beliebigen HTML Editor bearbeitet werden können. Anstelle der STS Tags werden zur Laufzeit Objektattribute, Berechnungsergebnisse und Bearbeitungsfunktionen eingefügt. Die unter 6.1 beschriebenen Methoden erzeugen den HTML Code nicht mehr selbst, sondern delegieren diese Aufgabe an die Methode interfaceBuilder des GUI Objektes. Das GUI Objekt gehört zum STS V1.3 Prototypen sts_GUIObject und wird einmal im globalen Variablenscope instanziert. Die Generierung der Benutzeroberfläche wird vollständig von displayObject und displayContent übernommen. Beim Aufruf der Methode interfaceBuilder wird der Name der HTML Vorlage übergeben. Weitere Übergabeparameter sind eine Referenz auf das aufrufende Objekt und eine Liste von sogenannten Actionlinks. Die Referenz auf das aufrufende Objekt wird benötigt um Berechnungsergebnisse von Methoden dieses Objektes im Layout einfügen zu können. Die Liste von Actionlinks wird benötigt um Bearbeitungsfunktionen in die Oberfläche einbauen zu können. Im Unterkapitel 6.3 werden die in den HTML Vorlagen möglichen Platzhalter beschrieben. Unterkapitel 6.4 beschreibt die HTML Vorlagen und die jeweils verfügbaren Actionlinks. Unterkapitel 6.5 stellt die Implementierungsdetails des GUI Objektes dar. Kapitel 6 Adaptierbare Benutzeroberfläche 71 6.3 STS Tags STS Tags sind in HTML Kommentaren untergebracht, um die HTML Vorlagen mit jedem beliebigen HTML Editor bearbeiten zu können. Ein STS Tag sieht zum Beispiel wie folgt aus: <!--<STS>insert_actionlink:identify</STS>--> Die äußere Umklammerung der STS Tags wird von <!-- und --> gebildet, was einem HTML Kommentar entspricht. Die innere Klammerung wird von <STS> und </STS> gebildet. Beide Umklammerungen zusammen bilden ein STS Tag. Zwischen dem öffnenden Teil <!--<STS> und dem schließenden Teil </STS>--> finden sich durch einen Doppelpunkt getrennt der Typ des STS Tags und die dazugehörigen Parameter. Es ist darauf zu achten, dass das gesamte Konstrukt leerzeichenfrei ist. Es gibt vier verschiedene Arten von STS Tags, die sich durch die Angabe des Typs unterscheiden. Diese sind: insert_data fügt an der betreffenden Stelle den Attributwert eines Objektes ein. insert_functionresult fügt das Ergebnis einer Methode eines Objektes ein. insert_actionlink fügt eine Bearbeitungsfunktion an der betreffenden Stelle ein. insert_href fügt ebenfalls eine Bearbeitungsfunktion an der betreffenden Stelle ein. Die Angabe des STS Tag Typs erfolgt in Kleinbuchstaben. In den nachfolgenden Abschnitten werden alle vier STS Tag Typen ausführlich beschrieben. 6.3.1 insert_data Mit dem STS Tag insert_data werden Attributwerte des aufrufenden Objektes an der betreffenden Stelle platziert. Der erste Parameter ist der Name des Objektattributes. <!--<STS>insert_data:sts_staff:1:,</STS> Das oben angeführte Beispiel zeigt, wie das Objektattribut sts_staff platziert werden kann. Beim STS Tag insert_data können optional noch weitere Parameter angegeben werden. Diese beiden Parameter kommen bei zusammengesetzten Objektattributen zum Einsatz. Der zweite Parameter gibt an, welcher Teil des zusammengesetzten Objektattributes verwendet werden soll. Der dritte Parameter gibt an, welches Zeichen die zusammengesetzten Teile trennt. Wird der dritte Parameter weggelassen, so wird der Doppelpunkt als Trennzeichen verwendet. Beim oben angeführten Beispiel wird der erste Teil des Objektattributes sts_staff eingefügt. Das zusammengesetzte Objektattribut sts_staff verwendet Beistriche zur Trennung der einzelnen Teile. Kapitel 6 Adaptierbare Benutzeroberfläche 6.3.2 72 insert_functionresult Leider ist die Möglichkeit, an bestimmten Stellen der Benutzeroberfläche Attributwerte einzufügen, nicht ausreichend. Aus diesem Grund wurden weitere STS Tags implementiert. Das STS Tag insert_functionresult ruft Methoden der Objekte auf. Diese liefern HTML formatierte Ergebnisse. Diese Ergebnisse werden an Stelle der STS Tags eingefügt. Ein Nachteil dieses Konzeptes ist es, dass die Trennung Geschäftslogik und Benutzeroberfläche teilweise aufgehoben wird. Die verfügbaren Methoden werden in der Tabelle 6-2 aufgezählt. Die Tabelle 6-2 zeigt auch für welche HTML Vorlage eine Methode verfügbar ist. Im Anschluss werden die Methoden kurz beschrieben. Methode HTMLVorlage actualUserToHTML sts_base.html assignedLinksToHTML sts_base.html bodyToHTML sts_noteentry.hmtl, sts_phonenoteentry.html, sts_schedulenoteentry.html, sts_emailentry.html displayRefClosedTicket sts_emailentry.html getAttachments sts_emailentry.html getLastTimeModified sts_ticketobject_object.html identifyDisplayContent sts_base.html modifyObjectToHTML sts_base.html noteIcon_to_HTML sts_noteentry.hmtl priority_to_HTML sts_ticketobject_object.html, sts_ticketobject_content.html sortOrderSelectToHTML sts_base.html sts_customerContactPerson_to_HTML sts_ticketobject_content.html sts_escalationModel_to_HTML sts_ticketobject_content.html sts_remainder_to_HTML sts_ticketobject_object.html, sts_ticketobject_content.html STSdisplayNavigation sts_base.html subject sts_noteentry.hmtl, sts_phonenoteentry.html, sts_schedulenoteentry.html, sts_emailentry.html Kapitel 6 Adaptierbare Benutzeroberfläche Methode timeCreated_to_HTML 73 HTMLVorlage sts_ticketobject_content.html, sts_noteentry.hmtl, sts_phonenoteentry.html, sts_schedulenoteentry.html, sts_emailentry.html timeExpire_to_HTML sts_schedulenoteentry.html updated_to_HTML sts_ticketobject_object.html, sts_ticketobject_content.html Tabelle 6-2: Methoden für insert_functionresult und deren Vorkommen actualUserToHTML ermöglicht es, dass der Name des aktuellen Benutzers angezeigt wird. Ist kein Benutzer identifiziert, so wird “anonymous“ ausgegeben. assignedLinksToHTML fügt einen Block von Hyperlinks auf die Verzeichnisse der "Assigned Ticket Collection" ein. Dies sind die Verzeichnisse der Supportmitarbeiter mit nicht abgeschlossenen Supporttickets. bodyToHTML ersetzt die Zeichen "Newline" und "Carriage Return" durch "<BR>". Diese Zeichen können im Textkörper der Ticketeinträge enthalten sein. In HTML werden beide Zeichen ignoriert und müssen durch "<BR>" ersetzt werden. displayRefClosedTicket zeigt an, dass eine E-Mail bei einem abgeschlossenen Supportticket abgelegt wurde. Das Support Tracking System versucht neuangekommene E-Mails automatisch beim entsprechenden Supportticket abzulegen. Ist das Supportticket geschlossen, wird beim E-Maileintrag ein spezieller Vermerk gemacht, der von dieser Methode dargestellt wird. getAttachments fügt Hyperlinks auf Dateien ein, die bei E-Mails als Anhänge vorhanden sind. Fallweise enthalten E-Mails von Kunden Dateianhänge. getLastTimeModified wird verwendet, um beim Auflisten der Tickets eines Verzeichnisses anzuzeigen, wie lange die Tickets nicht mehr bearbeitet wurden. Diese Methode ist auch in der Ticketansicht verwendbar. identifyDisplayContent wird in der HTML Vorlage sts_base.html verwendet um das aktuelle Objekt im Layout zu platzieren. Die HTML Vorlage sts_base.html bildet den Rahmen mit den möglichen Funktionen.. Der Inhalt sollte ursprünglich nur identifizierten Benutzern gezeigt werden. Daher rührt der Name dieser Methode. modifyObjectToHTML fügt einen Link zum Modifizieren bestimmter Objekte ein. Im Kopfteil der Benutzeroberfläche von STS V1.3 sind allgemeine Funktionen, wie Identifizieren, Passwort ändern und Suche, verfügbar. Darunter können neue Objekte, wie Ticket, Query und Staffmember, erzeugt werden. Daneben fügt diese Methode einen Link zum Verändern von Ticketverzeichnissen, Staffmember und Query ein, da diese Objekte in ihrer eigenen Darstellung keine Möglichkeit zum Verändern anbieten. Das aktuelle Objekt muss vom Typ Ticketverzeichnis, Staffmember oder Query sein. Kapitel 6 Adaptierbare Benutzeroberfläche 74 noteIcon_to_HTML platziert für die verschiedenen Untertypen eines Ticketeintrages vom Typ Notiz ein entsprechendes Icon. Untertypen sind Notiz, Zusammenfassung, Frage-Antwort und Arbeitsliste. priority_to_HTML wechselt in Abhängigkeit von der Priorität des Supporttickets die Schriftfarbe. Diese Methode findet sowohl bei der Anzeige eines Supporttickets, als auch bei der Auflistung aller Tickets eines Verzeichnisses Verwendung. sortOrderSelectToHTML platziert eine Pull-Down Auswahl für die Sortierung der Supporttickets. Die Auswahl eines Wertes bewirkt eine Neusortierung der Anzeige einer Supportticketliste. Title, Status, Priority, Time Modified, Created, Customer und Default sind mögliche Sortierreihenfolgen. Bei Default wird nach Priorität und Status gereiht. Diese Auswahl steht nur bei Ticketverzeichnissen zur Verfügung. sts_customerContactPerson_to_HTML fügt das Ticketattribut "Customer Contact Person" ins Layout ein. Bevor das Attribut eingefügt wird, wird vor jedem Beistrich ein Leerzeichen eingefügt. Bei der Darstellung ist es Webbrowsern nun möglich den Text umzubrechen. Ohne diese Maßnahme wird das Layout der Benutzeroberfläche von STS V1.3 zerstört. Man kann den Aufruf dieser Methode vermeiden, indem man die Trennfunktionalität des STS Tags insert_data verwendet. sts_escalationModel_to_HTML fügt das Eskalationsmodell und die für den Supportmitarbeiter verfügbare Reaktionszeit ein. Die Reaktionszeit leitet sich aus dem Eskalationsmodell des jeweiligen Kunden und aus der Priorität des Tickets ab. sts_remainder_to_HTML fügt eine auffällige Zeile mit dem Erinnerungszeitpunkt und mit der Anzahl der verbleibenden Tage ein. Supporttickets können Ticketeinträge enthalten die Erinnerungsnotizen sind. Diese Erinnerungsnotizen enthalten einen Erinnerungszeitpunkt. Falls mehr als eine Erinnerungsnotiz im Supportticket vorhanden ist, zeigt diese Methode den zeitlich nächsten Erinnerungszeitpunkt. Diese Methode wird für Supporttickets und für Auflistungen von Supporttickets verwendet. STSdisplayNavigation fügt eine Navigationsleiste ein, die es erlaubt, alle dem aktuell angezeigten Element übergeordneten Hierarchieebenen rasch zu erreichen. subject wird in den HTML Vorlagen von STS V1.3 verwendet, um den Titel der Ticketeinträge anzuzeigen. Dies kann auch mit Hilfe des STS Tags insert_data erledigt werden. timeCreated_to_HTML zeigt den Wert des Attributes TimeCreated an, wobei allerdings eine Umrechnung hin zur lokalen Ortszeit durchgeführt und ein spezielles Anzeigenformat gebildet wird. timeExpire_to_HTML fügt, wie sts_remainder_to_HTML für Supporttickets, eine auffällige Zeile mit dem Erinnerungszeitpunkt und mit der Anzahl der verbleibenden Tage ein. Da die Klasse sts_TicketEntryScheduleNoteObject diese Methode enthält, erfolgt dies für die Erinnerungsnotizen. updated_to_HTML kennzeichnet Tickets mit dem Schriftzug "Update", wenn eine neue E-Mail eines Kunden beim Supportticket eingefügt wurde. Enthalten die EMails der Kunden im Titel die Supportnummer, so werden sie vom Support Tracking System automatisch dem entsprechenden Supportticket zugeordnet. Kapitel 6 Adaptierbare Benutzeroberfläche 75 Wenn möglich sollte insert_data statt insert_functionresult verwendet werden. Dadurch ist die Entkoppelung von Business Logik und Benutzeroberfläche besser. 6.3.3 insert_actionlink und insert_href Alle Bearbeitungsfunktionen des Support Tracking Systems werden als Hyperlinks in die Benutzeroberfläche eingebunden. Diese Hyperlinks verbergen sich hinter kurzen Texten oder kleinen Bildern. Die Auswahl eines Hyperlinks durch einen Supportmitarbeiter stößt die entsprechende Bearbeitungsfunktion an. Alle möglichen Bearbeitungsfunktionen des aktuellen Objektes werden dem Interfacebuilder als Actionlinks übergeben. Die STS Tags insert_actionlink und insert_href platzieren diese in der Benutzeroberfläche. insert_actionlink fügt dabei den vollständigen Hyperlink ein, wie er als Actionlink dem Interfacebuilder vom aufrufenden Objekt übergeben wurde. Wie im nachfolgenden Beispiel ersichtlich, muss nur noch ein schließende HTML Tag </a> gesetzt werden. <td> <!--<STS>insert_actionlink:home</STS>--> HOME </a> </td> insert_href funktioniert ähnlich wie insert_actionlink. Dieses STS Tag fügt nicht den gesamten übergebenen Actionlink ein, sondern nur den HREF Teil. Der Anfangsteil <a und der Schlussteil > werden nicht mehr durch das STS Tag eingefügt. Dadurch können aber innerhalb vom HTML Tag <a> weitere Angaben gemacht werden. Wie beim STS Tag insert_actionlink, muss man auch hier ein schließendes HTML Tag </a> setzen. Zum Beispiel ist diese Art Actionlinks einzufügen notwendig, um mit Cascading Style Sheets das gewünschte Ergebnis zu erhalten. <a class="tl1" <!--<STS>insert_href:ticketopen</STS>-->> <!--<STS>insert_data:Name</STS>--> </a> Das nachfolgende Unterkapitel 6.4 zeigt wie HTML Vorlagen diese STS Tags verwenden. 6.4 HTML Vorlagen Die für STS V1.3 erstellten Standard HTML Vorlagen sind im Verzeichnis ../wavemaster-sts-5.1/sts/gui2 zu finden. HTML Vorlagen können in einem Kapitel 6 Adaptierbare Benutzeroberfläche 76 anderen Verzeichnis abgelegt werden. In der Konfigurationsdatei config.js wird das Verzeichnis mit den HTML Vorlagen, wie folgt angegeben: var GUIPATH = "wavemaster-sts-5.1/sts/gui2"; Einer neuer Wert in der Variable GUIPATH, wird erst nach einem Neustart des Waveslaves wirksam. STS V1.3 benötigt für das angegebene Verzeichnis Leserechte. Dazu ist in der Konfigurationsdatei .db.contr.rc folgender Eintrag nötig: WAVEMASTER-STS-51:: JAVASCRIPT_FILE_READ_ACCESS = d:/sts/wavemaster-sts-5.1 Wird in den HTML Vorlagen auf Dateien, die im Verzeichnisbaum der Anwendung vorkommen, verwiesen, so ist die Endung ";internal&inline=true" zu verwenden. Im folgenden Beispiel wird die Bilddatei "identify.gif" aus dem Verzeichnis "../wavemaster-sts-5.1/sts/gui2/icons" verwendet: <img src="/sts/gui2/icons/identify.gif;internal&inline=true" width="102" height="27" border="0"> HTML Vorlagen sind eine Art von Layout Templates. Die verschiedenen STS Tags werden zur Laufzeit durch aktuellen Inhalt ersetzt. Somit sind STS Tags, so etwas wie Platzhalter für alternativen Inhalt. Zu den verschiedenen Objekten des Support Tracking Systems existieren HTML Vorlagen. Die Beschreibung der HTML Vorlagen beginnt mit der HTML Vorlage sts_base.html, welche einen Art Rahmen für die restlichen HTML Vorlagen in der Benutzeroberfläche bildet. 6.4.1 sts_base Die wichtigste HTML Vorlage ist sts_base.html. Sie erzeugt jenen Rahmen, der die grundlegenden Bearbeitungsfunktionen des Support Tracking Systems zur Verfügung stellt. Das gerade aktuelle Objekt wird innerhalb dieses Rahmens dargestellt. Der erste Aufruf des Interfacebuilders im Rahmen eines Requests erfolgt immer von der Methode displaySTS aus. Dabei wird dem Interfacebuilder als Vorlage sts_base.hmtl übergeben. Weiters bekommt der Interfacebuilder eine umfangreiche Liste an Actionlinks mitübergeben, die in der Vorlage verwendet werden und den Bearbeitungsfunktionen entsprechen. Nachfolgend eine kurze Beschreibung der Bearbeitungsfunktionen bzw. Actionlinks: identify ermöglicht Benutzern sich am Support Tracking System anzumelden. Nur nach erfolgter Anmeldung steht die Funktionalität von STS V1.3 zur Verfügung. passwd ermöglicht den Benutzern vom Support Tracking System ihr Passwort zu ändern. Kapitel 6 Adaptierbare Benutzeroberfläche 77 newsearch öffnet ein Formular, mit welchem eine neue Suchanfrage an das System gestellt werden kann. createticket öffnet ein Formular, mit welchem ein neuer Supportfall im System angelegt werden kann. newquery führt zu einem Formular, welches das Anlegen eines Queryobjektes erlaubt. Mit neuen Queryobjekten ist es möglich neue Reports mit dem Support Tracking System zu erstellen. Queryobjekte sind eine Besonderheit des Hyperwave Information Servers. newstaffmember führt zu einem Formular, das alle Daten für einen neuen Supportmitarbeiter erfasst. Nach Abschluss des Formulars wird ein entsprechender Benutzer angelegt. modifystaffmember eröffnet die Möglichkeit die Dateneinträge eines Benutzers des Support Tracking Systems zu ändern. home ruft jenes Verzeichnis auf, welches die noch offenen Supporttickets des gerade angemeldeten Benutzers enthält. unassigned führt zu einer Liste von E-Mails, die vom System keinem bestimmten Supportfall zugeordnet werden konnten. new führt zu einer Liste von Supporttickets, welche neu angelegt und noch keinem Supportmitarbeiter zur Bearbeitung zugeteilt wurden. assigned führt zu einem Verzeichnis, das alle Mitarbeiterverzeichnisse enthält. suspended listet alle Supporttickets mit dem Status "suspended" auf. closed listet alle Supporttickets auf, die bereits abgeschlossen sind. system führt zu einem Verzeichnis, das Systeminformation enthält. Dieses Verzeichnis wird in der Version STS V1.3 nicht verwendet und ist somit leer. Actionlinks werden vom Interfacebuilder in Form von Hyperlinks in die Benutzerschnittstelle eingebaut. Mit der HTML Vorlage bekommt der Interfacebuilder auch eine Reihe von Referenzen auf Funktionen übergeben. Der Interfacebuilder ist so in der Lage Berechnungsergebnisse in die Benutzerschnittstelle einzubauen. Diese Berechnungsfunktionen müssen jedoch Methoden des aufrufenden Objektes sein. Folgende Methoden stehen der Vorlage sts_base zur Verfügung: modifyObjectToHTML diese Methode entscheidet ob das aktuelle Objekt modifiziert werden kann. Falls dies der Fall ist wird ein weiterer Button für diese Funktion in die Benutzeroberfläche eingebaut. Diese Methode wurde der hw_Object Klasse der HWLIB hinzugefügt. Somit steht sie jedem Objekt zur Verfügung. assignedLinksToHTML mit dieser Methode ist es möglich Arbeitsverzeichnisse der Supportmitarbeiter als Hyperlinks in Benutzeroberfläche darzustellen. STSdisplayNavigation blendet eine Reihe von Hyperlinks in der Benutzeroberfläche ein, die ein navigieren in der Hierarchie erlauben. Beim Support Tracking System sind Supporttickets, Arbeitsverzeichnisse und so weiter hierarchisch angeordnet. alle der Kapitel 6 Adaptierbare Benutzeroberfläche 78 actualUserToHTML ermöglicht die Anzeige des Benutzernamens des aktuell identifizierten Mitarbeiters in der Benutzeroberfläche. sortOrderSelectToHTML wird ein Verzeichnis mit Supporttickets dargestellt. So wird mit dieser Methode eine Möglichkeit in die Benutzeroberfläche eingebaut um verschiedene Sortierreihenfolgen der Supporttickets auswählen zu können. identifyDisplayContent mit dieser Methode wird das aktuelle Objekt in der Benutzeroberfläche platziert. Das aktuelle Objekt wird aber nur dargestellt, wenn sich zuvor der Benutzer am System identifiziert hat. Die HTML Vorlage sts_base.html verwendet keine STS Tags vom Typ insert_data. Abbildung 6-2 zeigt was STS V1.3 mit Hilfe dieser Vorlage generiert. Will man Cascading Style Sheets für die Gestaltung der Benutzeroberfläche verwenden, so sollten diese am Anfang dieser HTML Vorlage eingefügt werden. Sie stehen dann allen anderen verwendeten HTML Vorlagen zur Verfügung. Abbildung 6-2: Mit der HTML Vorlage sts_base generiert Im obersten Bildabschnitt findet man die Möglichkeiten, sich zu identifizieren, das Passwort zu ändern oder ein Suchformular anzufordern. Darunter finden sich jene STS V1.3 Funktionen, die sich nicht auf ein Ticket oder einen Ticketeintrag beziehen. Dazu zählen die Möglichkeiten ein neues Ticket anzulegen, eine neue Query anzulegen oder einen neuen Staffmember ins System einzufügen. Wenn die Ticketcollection eines Supportmitarbeiters angezeigt wird, wird zusätzlich die Möglichkeit angeboten, die Daten dieses Mitarbeiters zu bearbeiten. Unter diesen STS V1.3 Funktionen finden sich, durch STSdisplayNavigation eingefügt, die Navigationshilfe, die es erlaubt in der Kapitel 6 Adaptierbare Benutzeroberfläche 79 Hierarchie der Collection rasch nach oben zu steigen. Unter der Navigationszeile wird der Loginname des aktuellen Benutzers eingefügt. Auf der linken Seite befinden sich vertikal angeordnet zahlreiche Navigationenhilfen, die es ermöglichen in eine spezielle Ticketcollection zu wechseln. Home wechselt in die Collection des aktuellen Benutzers, Unassigned E-Mails in die Sammlung der nicht eingeordneten E-Mails, New Tickets zu den neuen Tickets, die keinem Supportmitarbeiter zugewiesen wurden und Assigned Tickets führt in jene Collection, wo sich die Collections, Queryobjekte und der sogenannte Trashcan der Supportmitarbeiter befinden. Die einzeln Collections sind durch die function_result Methode assignedLinksToHTML unterhalb eingefügt. In der vertikalen Anordnung finden sich noch Suspended und Closed Tickets sowie STS System Staff. Unter dem bereits erwähnten Usernamen wird jetzt mittels function_result und der Methode identifyDisplayContent das eigentlich Objekt dargestellt. Ursprünglich überprüfte diese Methode, ob es sich beim aktuellen Benutzer um einen identifizierten Benutzer oder um einen anonymen Benutzer handelte und zeigte nur identifizierten Benutzern die Objekte an. Da dies jetzt nicht mehr der Fall ist, könnte man hier auch displayObject mittels function_result in die HTML Vorlage einfügen, denn nichts anderes macht die Methode identifyDisplayContent. Die displayObject Methode des aktuellen Objekts, ist eine überschriebene Methode, die je nachdem zu welcher Klasse das aktuelle Objekt gehört, nun erneut den Interfacebuilder mit sinnvollen Parametern aufruft. Dadurch werden nun nachfolgend beschriebene HTML Vorlagen fallweise ausgeführt. 6.4.2 sts_ticketobject_object Folgende Elemente werden beim Aufruf der HTML Vorlage sts_ticketobject_object, dem Interfacebuilder als Actionlinks übergeben und stehen somit innerhalb dieser HTML Vorlage für insert_actionlink und insert_href zu Verfügung: attributes setzt einen Button mit zugehörigen Hyperlink in der Benutzeroberfläche. Damit sind die Attribute des Objektes in der Standarddarstellung des Hyperwave Information Server erreichbar. ticketopen erzeugt einen Hyperlink auf die Volldarstellung des Supporttickets. Eine Kombination der Attribute Name und Titel wird für die Anzeige des Hyperlinks verwendet. resetupdate erzeugt einen Hyperlink zum Löschen der Veränderungsanzeige. Dieser Hyperlink wird zusammen mit der Methode updated_to_HTML verwendet. Von den Methoden der Klasse sts_ticketObject werden folgende mittels STS Tag insert_functionresult verwendet: updated_to_HTML prüft ob das System am vorliegenden Supportticket Veränderungen durchgeführt hat. Ist dies der Fall, wird dies dem Benutzer angezeigt. sts_remainder_to_HTML prüft ob für dieses Supportticket ein Erinnerungsdatum gesetzt ist. Falls dies der Fall ist werden Tage und Stunden bis zum Eintritt des Datums angezeigt. Kapitel 6 Adaptierbare Benutzeroberfläche 80 priority_to_HTML wandelt die interne Darstellung der Priorität in Texte um. Dies wurde notwendig als sich Hyperwave mehr und aussagekräftigere Prioritäten wünschte. getLastTimeModified zeigt die Anzahl der Tage an, die seit der letzten Bearbeitung durch einen Supportmitarbeiter vergangen sind. Um Cascading Style Sheets verwenden zu können ist es notwendig insert_href statt insert_actionlink zu verwenden. Das nachfolgende Codestück zeigt außerdem, wie man nur einen Teil des zusammengesetzten Attributes "Title" verwendet. <a class="tl1" <!--<STS>insert_href:ticketopen</STS>-->>&nbsp; <!--<STS>insert_data:Name</STS>--> <!--<STS>insert_data:Title:3</STS>--> </a> Ein weiteres kleines Codebeispiel illustriert, wie man einen Actionlink mit dem Ergebnis der Methode updated_to_HTML verbinden kann. Durch diese Anordnung und dadurch, dass die Methode updated_to_HTML einen Leerstring zurückliefert, falls das entsprechende Flag beim Ticket nicht gesetzt ist, wird bewirkt, dass nur bei einem Ticket mit einem vom System eingefügten E-Mail ein roter Schriftzug mit dem Wort Update erscheint und klickbar ist. <a <!--<STS>insert_href:resetupdate</STS>-->> <!--<STS>insert_functionresult:updated_to_HTML</STS>--> </a> Abbildung 6-3 zeigt die befüllte HTML Vorlage sts_ticketobject_object. Alle drei Actionlinks werden für die erste Zeile verwendet. Ganz links kann man die Attribute des Tickets aufrufen, in der Mitte kann man das Ticket öffnen und ganz rechts kann man das Update Flag zurücksetzen. Für den Actionlink zum Öffnen des Tickets werden Name und Teile des Titels verwendet. In der zweiten Zeile sieht man das Ergebnis der Methode sts_remainder_to_HTML, welches natürlich nur vorhanden ist, wenn das Ticket zumindest eine Schedulenote enthält. Darunter werden Ticketattribute und Teile von Ticketattributen in mehreren Zeilen dargestellt. Nach dem Ticketstatus befinden sich die Ergebnisse der Methoden priority_to_HTML und getLastTimeModified der Klasse sts_ticketObject. Abbildung 6-3: Mit der HTML Vorlage sts_ticketobject_object generiert Kapitel 6 Adaptierbare Benutzeroberfläche 6.4.3 81 sts_ticketobject_content Die HTML Vorlage sts_ticketobject_content stellt eine andere Sicht auf das Ticket zur Verfügung als sts_ticketobject_object. Die HTML Vorlage sts_ticketobject_object zeigt eine Zusammenfassung des Tickets, die für Ticketlisten benötigt wird. Mit sts_ticketobject_content erhält man eine Volldarstellung des Inhaltes eines Tickets. Dem Interfacebuilder werden für die HTML Vorlage sts_ticketobject_content folgende Elemente als verfügbare Actionlinks übergeben: resetupdate erzeugt einen Hyperlink zum Löschen der Veränderungsanzeige. Dieser Hyperlink wird zusammen mit der Methode updated_to_HTML verwendet. history führt bei Betätigung zu einer Auflistung, der am Ticket durchgeführten Änderungen mit Zeitangaben. addnote öffnet ein Formularfenster, mit welchem eine neue Notiz zum Ticket hinzugefügt werden kann. addschedulenote öffnet ein Formularfenster, mit welchem eine neue Ablaufnotiz zum Ticket hinzugefügt werden kann. addphonenote öffnet ein Formularfenster, mit welchem eine Telefongesprächsnotiz verfasst werden kann. addemail öffnet ein Formularfenster, mit welchem dem zum Ticket gehörigen Kunden eine E-Mail geschickt werden kann. Diese E-Mail wird als Ticketeintrag zum Ticket hinzugefügt. assignticket führt zu einem Formularfenster, mit welchem das Ticket einem anderen Mitarbeiter übertragen werden kann. modifyticket führt zu einem Formularfenster mit allen Ticketdaten. Mit Hilfe dieses Formulars ist es möglich die Ticketdaten zu verändern. removeticket führt über eine Sicherheitsabfrage zum Löschen des Tickets mit all seinen Einträgen. changestatus ermöglicht den Status des Tickets auf "closed" oder "suspended" zu stellen. In beiden Fällen wird das Ticket in entsprechende Verzeichnisse verschoben. Instanzen der STS V1.3 Klasse sts_ticketObject stellen folgende Methoden für das STS Tag insert_functionresult zur Verfügung: updated_to_HTML prüft ob das System am vorliegenden Supportticket Veränderungen durchgeführt hat. Ist dies der Fall, wird dies dem Benutzer angezeigt. sts_remainder_to_HTML prüft ob für dieses Supportticket ein Erinnerungsdatum gesetzt ist. Falls dies der Fall ist werden Tage und Stunden bis zum Eintritt des Datums angezeigt. sts_customerContactPerson_to_HTML bereitet die Supporttickets für die Anzeige in der Benutzeroberfläche vor. Kundendaten des Kapitel 6 Adaptierbare Benutzeroberfläche 82 timeCreated_to_HTML wandelt das interne Datumsformat in ein externes Format für die Anzeige um. priority_to_HTML wandelt die interne Darstellung der Priorität in Texte um. sts_escalationModel_to_HTML berechnet aus dem Supportmodell des Kunden, die Anzahl an Stunden die der Supportgruppe zur Verfügung stehen um zu reagieren. Abbildung 6-4 zeigt das Ergebnis, das Interfacebuilder mit der HMTL Vorlage sts_ticketobject_content erzeugt. In der ersten Zeile kommen gleich zwei Actionlinks zum Zug. Der Actionlink history wird am Zeilenanfang über ein Icon gelegt und ermöglicht es dem Benutzer, ein Fenster zu öffnen und die Logfileeinträge zu betrachten. In der Mitte der Zeile wird mit insert_data der Titel des Tickets dargestellt. Am Zeilenende kommt es wieder zum Zusammenspiel vom Actionlink update und dem Methodenaufruf updated_to_HTML. In der zweiten Zeile kommen weitere vier Actionlinks zur Anwendung. In dieser Zeile kann man der Reihe nach die Formulare zum Erzeugen einer Note, Schedulenote, Phonenote und E-Mail öffnen – alle zusammen sind sogenannte Ticketeinträge. Hierfür werden die Actionlinks addnote, addschedulenote, addphonenote und addemail verwendet. Darunter in der dritten Zeile befindet sich die Anzeige, dass eine Schedulenote abläuft. Diese Ausgabe wird von der Methode sts_remainder_to_HTML generiert. Danach kommt ein großer Block an Ticketattributdaten, die entweder über das STS Tag insert_data oder über das STS Tag insert_functionresult eingefügt werden. Mit dem STS Tag insert_data werden folgende Daten eingefügt sts_staff:1, sts_ticket_Status, sts_customer, sts_category, sts_platform, sts_release, sts_customerNotified, sts_product, sts_workTimeTotal, sts_client, sts_prTicketURL, sts_prTicketNumber und Description. Dazwischen sorgen noch die Methoden sts_customerContactPerson_to_HTML, timeCreated_to_HTML, priority_to_HTML und sts_escalationModel_to_HTML für notwendige Ergänzungen über das STS Tag insert_functionresult. Abschließend folgt noch eine Zeile mit Kommandos, die sich auf das Ticket selbst beziehen. Dazu werden der Reihe nach die Actionlinks assignticket, modifyticket, removeticket und changestatus angewendet. Mit Assign bekommt man ein Formular, um das Ticket einem anderen Supportmitarbeiter zuzuweisen. Mit Modify gelangt man zu einem Formular mit dem man Ticketattribute verändern kann. Mit Remove verschiebt man das gesamte Ticket inklusive der Ticketeinträge in einen sogenannten Trashcan. Schließlich kann man mit Finish Request den Ticketstatus auf Suspended oder Closed setzen, was dazu führt, dass das Ticket in entsprechende Collections verschoben wird. 6.4.4 sts_noteentry Wird ein Supportticket mit der HTML Vorlage sts_ticketobject_content umfassend angezeigt, dann sollte es auch eine Möglichkeit geben die Einträge, die laufend zu einem Supportticket gemacht werden, darzustellen. Dies wird von den HTML Vorlagen sts_noteentry, sts_phonenoteentry, sts_schedulenoteentry und sts_emailentry ausgeführt. Für die HTML Vorlage sts_noteentry erhält der Interfacebuilder folgende Actionlinks: Kapitel 6 Adaptierbare Benutzeroberfläche 83 nextentry ermöglicht das Weiterblättern zum nächsten Ticketeintrag. previuousentry ermöglicht es zurück zum vorigen Ticketeintrag zu blättern. topentry ermöglicht das Zurückspringen zum ersten Ticketeintrag. lastentry ermöglicht es zum letzten Ticketeintrag zu springen. remove führt zum Löschen eines Ticketeintrages. create führt zu einem Formularfenster, welches den Notizeintrag in ein neues Supportticket umwandelt. Abbildung 6-4: Mit der HTML Vorlage sts_ticketobject_content generiert Instanzen der Klasse sts_TicketEntryNoteObject stellen Interfacebuilder über das STS Tag insert_functionresult folgenden Methoden bereit: timecreated_to_HTML wandelt das interne Datumsformat in ein externes Format (Wochentag, Monat Tag, Jahr, hh:mm:ss) um. noteIcon_to_HTML wählt ein Icon aus, welches den Typ der Notiz (einfache Notiz, Zusammenfassung, Arbeitsliste, Frage-Antwort) symbolisiert. Kapitel 6 Adaptierbare Benutzeroberfläche 84 subject liefert vom Attribut sts_subject einen bestimmten Teil für die Anzeige zurück. bodyToHTML nimmt am Text der Notiz Formatierung vor, damit das Layout der HTML Seite nicht zerstört wird. Abbildung 6-5 zeigt die HTML Vorlage sts_noteentry, nachdem Befüllen durch den Interfacebuilder. In der ersten Zeile ganz rechts befinden sich die Actionlinks, die dafür sorgen, dass man zwischen den Ticketeinträgen blättern kann (zum ersten Eintrag, zum vorhergehenden Eintrag, zum nachfolgenden Eintrag und zum letzten Eintrag). Darunter werden mit dem STS Tag insert_functionresult, die Ergebnisse von timeCreated_to_HTML, noteIcon_To_HTML, subject und bodyToHTML eingefügt. Dazwischen befinden sich noch die Daten der Noteentryattribute sts_worktime und sts_to. In der abschließenden Zeile finden dann die beiden letzten Actionlinks Platz. Remove verschiebt die Noteentry in den Trashcan und create öffnet das Formular, mit dem man aus der Noteentry ein Ticket machen kann. Abbildung 6-5: Mit der HTML Vorlage sts_noteentry generiert 6.4.5 sts_phonenoteentry sts_phonenoteentry ist im wesentlichen gleich Handzuhaben, wie die in 6.4.4 sts_noteentry beschriebene HTML Vorlage für die Noteentries. Zusätzlich wird das Phonenoteattribut sts_to mit dem STS Tag insert_data platziert. Außerdem findet die Methode noteIcon_to_HTML hier keine Anwendung, zumal es weder Untertypen bei Phonenotes gibt, noch eine entsprechende Methode in der STS V1.3 Klasse sts_TicketEntryPhoneNoteObject existiert. Kapitel 6 Adaptierbare Benutzeroberfläche 85 Abbildung 6-6: Mit der HTML Vorlage sts_phonenoteentry generiert 6.4.6 sts_schedulenoteentry Auch hier sind die Änderungen gegenüber einer Ticketnoteentry minimal. Erneut gibt es hier keine Untertypen, sodass wiederum keine Methode noteIcon_to_HTML mittels insert_functionresult verwendet werden kann. In der zweiten Zeile wird das Ablaufdatum der Schedulenote mit Hilfe des STS Tags insert_functionresult und der Methode timeExpire_to_HTML der Klasse sts_TicketEntryScheduleNoteObject angezeigt (siehe Abbildung 6-7). Abbildung 6-7: Mit der HTML Vorlage sts_schedulenoteentry generiert 6.4.7 sts_emailentry E-Mails sind Ticketeinträge, die sich von den zuvor beschriebenen Ticketeinträgen etwas unterscheiden und deshalb etwas ausführlicher beschrieben werden. Mit der HTML Vorlage sts_emailentry bekommt der Interfacebuilder folgende Actionlinks übergeben: nextentry ermöglicht das Weiterblättern zum nächsten Ticketeintrag. Kapitel 6 Adaptierbare Benutzeroberfläche 86 previousentry ermöglicht es zum vorigen Ticketeintrag zurück zu blättern. topentry ermöglicht das Zurückspringen zum ersten Ticketeintrag. lastentry ermöglicht es zum letzten Ticketeintrag zu springen. assign ermöglicht das Verschieben der E-Mail zu einem Supportticket. reply liefert die Möglichkeit das E-Mail zu beantworten. forward liefert die Möglichkeit das E-Mail weiterzuleiten. remove führt zum Löschen eines Eintrags. create führt zu einem Formularfenster, welches den Notizeintrag in ein neues Supportticket umwandelt. Folgende Methoden der Klasse sts_ticketEntryEmailObject werden durch das STS Tag insert_functionresult verwendet: displayRefClosedTicket zeigt an, dass das E-Mail zu einem Supportticket gehört, welches bereits geschlossen ist. STS konnte dieses E-Mail nicht automatisch zuordnen, weil es dann von keinem Mitarbeiter bearbeitet werden würde. timeCreated_to_HTML wandelt das interne Datumsformat in ein externes Format (Wochentag, Monat Tag, Jahr, hh:mm:ss) um. subject liefert vom Attribut sts_subject einen bestimmten Teil für die Anzeige zurück. bodyToHTML nimmt am Text der E-Mail Formatierung vor, damit das Layout der HTML Seite nicht zerstört wird. getAttachments fügt einen Hyperlink ein, der E-Mailanhänge zur Anzeige bringt. Die Ausgabe ist wiederum sehr ähnlich der erzeugten Ausgabe bei sts_noteentry. Wiederum findet die Methode noteIcon_to_HTML keine Anwendung, da auch E-Mails keine Subtypen besitzen. Dafür können mit den beiden zusätzlichen Methoden, im Zusammenspiel mit dem STS Tag insert_functionresult, wichtige Informationen platziert werden. Die Methode displayRefClosedTicket stellt in der Mitte der ersten Zeile einen Hyperlink auf ein bereits geschlossenes Ticket dar. Dies ist dann der Fall, wenn das System eine E-Mail zu einem Ticket empfängt, welches bereits im Zustand closed oder suspended ist. Dadurch erkennt man beim Betrachten der Collection der Unassigned E-Mails, dass eine E-Mail zu einem solchen Ticket eingelangt ist. Mit der Methode getAttachments können Beilagen von E-Mails angezeigt werden. Beide Methoden sind in der Abbildung 6-8 nicht eingesetzt worden und daher dort nicht sichtbar. Zusätzlich zu den Attributwerten bei Notetypen werden die E-Mailattribute sts_from und sts_cc mittels insert_data eingefügt. Die drei zusätzlichen Actionlinks machen sich in der letzten Zeile bemerkbar, wo für E-Mails die Funktionen Reply, Forward und Assign dazukommen. Mit Reply bekommt man ein Formular um eine E-Mail zu beantworten, mit Forward ein Formular um eine E-Mail weiterzuleiten und Assign öffnet schließlich ein Formular, mit dem es möglich ist, aus einer E-Mail ein Ticket zu generieren. Kapitel 6 Adaptierbare Benutzeroberfläche 87 6.5 Implementierung Der wesentliche Teil der Implementierung der neuen adaptiven Benutzeroberfläche von STS V1.3 erfolgt durch die Klasse sts_GUIObject. Diese Klasse wird einmal als globales Objekt mit dem Namen GUI instanziert. Folgende Methoden bilden den Kern dieser Klasse: interfaceBuilder bildet die Schnittstelle der Klasse nach außen. An diese Methode delegieren die Methoden displayObject und displayContent die Erstellung der Benutzeroberfläche. Beim Aufruf der Methode werden drei Parameter übergeben. Diese drei Parameter setzen sich aus einem Namen für die HTML Vorlage, aus einer Referenz auf das aufrufende Objekt und aus einer Liste der sogenannten Actionlinks zusammen. Die Methode interfaceBuilder liefert als Ergebnis ein HTML Format. HTMLFileReader ist jene Methode, die der Methode interfaceBuilder die HTML Vorlage zur Verfügung stellt. Ist die HTML Vorlage noch nicht vorhanden, wird sie vom Dateisystem eingelesen. Das Einlesen der HTML Vorlagen vom Dateisystem ist leider langsam. Das GUI Objekt hält die HTML Vorlagen im Speicher. Werden HTML Vorlagen mehrmals benötigt, kann dadurch Rechenzeit gespart werden. replaceSTSTags wird von der Methode interfaceBuilder aufgerufen, sobald die HTML Vorlage verfügbar ist. Diese Methode sucht in der HTML Vorlage nach den STS Tags. Die Suche nach den STS Tags ist sehr rechenintensiv. transformSTSTag liefert an replaceSTSTags jene Zeichenketten, mit denen die STS Tags ersetzt werden. Diese Methode wird von replaceSTSTags für jedes gefundene STS Tag aufgerufen. Wenn die Methoden displayObject oder displyContent eines beliebigen Objektes interfaceBuilder aufrufen, ist das Ergebnis eine Darstellung genau dieses Objektes. Um eine benutzbare Oberfläche zu erhalten ist dies allerdings zu wenig. Es fehlen allgemeine Bearbeitungsfunktionen und Navigationsmöglichkeiten. Die HWLIB Basisklasse hw_Object wurde um die Methode displaySTS erweitert. Auf Grund der Vererbung besitzen alle HWLIB und STS Klassen in der Vererbungshierarchie diese Methode. Diese Methode wandelt die allgemeinen Bearbeitungsfunktionen in eine Actionlinkliste um und ruft die Methode interfaceBuilder mit der HTML Vorlage sts_base.html auf. Irgendwo in dieser HTML Vorlage wird mit dem STS Tag insert_functionresult die Methode identifyDisplayContent aufgerufen. Über den Umweg displayObject oder displayContent wird interfaceBuilder mit der HTML Vorlage für das aktuelle Objekt aufgerufen. Die Darstellung des aktuellen Objektes wird so in den Basisrahmen der Benutzeroberfläche von STS V1.3 eingefügt. Kapitel 6 Adaptierbare Benutzeroberfläche Abbildung 6-8: Mit der HTML Vorlage sts_emailentry generiert Abbildung 6-9: Sicht auf ein Supportticketverzeichnis 88 Kapitel 6 Adaptierbare Benutzeroberfläche Abbildung 6-10: Ansicht eines Supporttickets mit einer Telefonnotiz als Eintrag 89 Kapitel 6 Adaptierbare Benutzeroberfläche 90 6.6 Zusammenfassung Mit STS V1.3 wurde erstmals beim Support Tracking System eine Trennung der Benutzeroberfläche und der Geschäftslogik erreicht. Dieses Ziel wurde mit der Hilfe von sogenannten HTML Vorlagen erreicht. HTML Vorlagen bestehen für alle wesentlichen Objekte des Support Tracking Systems. Eine HTML Vorlage bildet den Rahmen für die Darstellung aller Objekte und beinhaltet generelle Funktionalität. Für das Supportticket gibt es zwei HTML Vorlagen. Eine HTML Vorlage ermöglicht eine Kurzdarstellung für Supportticketlisten, während eine weiterer HTML Vorlage die Volldarstellung eines Supporttickets liefert. Auch für Notizen, Telfonprotokolle, E-Mails und zeitgesteuerte Notizen gibt es HTML Vorlagen. In diesen HTML Vorlagen bilden sogenannte STS Tags Platzhalter für Objektdaten, Berechnungsergebnisse und Funktionen. Letztere werden auf Hyperlinks gelegt. Bei jedem Request müssen die HTML Vorlagen eingelesen werden und mit den Attributen des aktuellen Objektes bzw. mit den Berechnungsergebnissen der Methoden des aktuellen Objektes befüllt werden. Der Vorgang die STS Tags mit Inhalt zu ersetzen ist leider sehr rechenintensiv. Eine Vorverarbeitung könnte Rechenzeit einsparen. Leider konnte keine vollständige Trennung von Benutzeroberfläche und Geschäftslogik erreicht werden. Abbildung 6-10 und Abbildung 6-9 zeigen die neue Benutzeroberfläche von STS V1.3. Sie zeigen beispielhaft das Ergebnis der HTML Vorlagen, die im Rahmen dieser Arbeit entwickelt wurden. Abbildung 6-10 zeigt ein Supportticket, welches eine Telefongesprächsnotiz als einzigen Eintrag enthält. Abbildung 6-9 zeigt ein Verzeichnis mit Supporttickets. Kapitel 7 Erkenntnisse Dieses Kapitel versucht die bei dieser Arbeit gemachten Erfahrungen aufzuzählen. Diese Erfahrungen fallen im wesentlichen in drei unterschiedliche Bereiche. Der erste Bereich umfasst die Einordnung des Support Tracking Systems und den Vergleich mit anderen Systemen. Erfahrungen aus dem Bereich Wartung, agile Softwareentwicklungsprozesse und Refaktoring bilden den zweiten Bereich. Der dritte Bereich fasst die Erfahrungen bei der Einführung der Adaptierbarkeit zusammen. 7.1 Trouble Ticket Systeme Sieht man das Support Tracking System als ein Trouble Ticket System, welches für die Beziehung zwischen Kunden und Supportabteilung spezialisiert ist, dann ist die Zuordnung des Support Tracking Systems zu den Trouble Ticket System ein leichter Schritt. Aus der Sicht des Support Tracking Systems ist auch noch einsichtig, warum Trouble Ticket Systeme zu den Helpdesksystemen gehören. Bedenkt man aber, dass es zahlreiche Systeme gibt, die zu einem Ereignis ein Ticket anlegen und im Verlauf der Zeit das Ticket mit Einträgen ergänzen, beginnt es schwierig zu werden. Problem Tracking Systeme, Bug Tracking Systeme, Support Tracking Systeme, Feature Request Tracking oder Knowledge Base Systeme können Ticket basierend sein. Diese Systeme gehören somit zur Klasse der Trouble Ticket Systeme, aber nicht notwendigerweise zu den Helpdesksystemen. Kommerzielle Systeme haben eine stark erweiterte Funktionalität und können fallweise auch Aufgaben aus den Bereichen Groupware, Case Based Reasoning, Knowledge Management Systeme oder Customer Relationship Management abdecken. Die wenigen nicht kommerziellen Systeme haben kleinere Funktionsumfänge und konzentrieren sich alle auf den Bereich Bug Tracking. 7.2 Wartung und agile Softwareprozesse Es hat sich auch bei der Wartung vom Support Tracking System gezeigt, dass ungefähr 80% des Aufwandes in der Wartungsphase für progressive Pflegetätigkeiten verwendet werden und nur 20% des Aufwandes auf korrektive Wartungsarbeiten entfallen. Das Support Tracking wurde in drei Schritten erweitert (STS V1.1, STS V1.2 und STS Kapitel 7 Erkenntnisse 92 V1.3). Es hat sich gezeigt, dass eine Trennung der Wartungsarbeiten und der Pflegearbeiten von Vorteil ist. Progressive Pflegearbeiten sollten immer nur auf konsolidierten Quellcode durchgeführt werden. Leider bestätigte sich auch die Behauptung der Vertreter der agilen Softwareprozesse, dass Dokumentation und Quellcode sich auseinander entwickeln. Zu Begin dieser Arbeit lag schon ein laufendes System vor, dies ist ein Kriterium das in der agilen Softwareentwicklung raschest erfüllt werden soll. Folgende Erfahrungen wurden mit den 12 Praktiken von eXtreme Programming gemacht Kunde vor Ort Dies war leider nicht der Fall, aber die Auswirkungen waren gering, wenn es darum ging offene Fragen bezüglich neuer Funktionalität abzuklären. Groß hingegen waren die Auswirkungen, wenn es darum ging Feedback zu erhalten, dies blieb entweder aus oder kam nur mit einiger Verspätung. Kurze Inkrementzyklen Das Vorgehen war inkrementell und iterativ, aber die Zyklen waren länger als die geforderten 4-8 Wochen. Dies blieb ohne Folgen, da die drei Erweiterungsstufen gut ausdiskutiert waren und so nicht der Fall eintrat völlig an den Kundenwünschen vorbei zu arbeiten. Planungsspiel Ein Planungsspiel wurde explizit nicht unter diesem Namen durchgeführt, allerdings kam es zu einigen Meetings mit Vertretern der Kundenseite und natürlich zu laufenden Besprechungen mit den Betreuern dieser Arbeit. Bei diesen Besprechungen wurden kurzfristige Ziele erörtert und Prioritäten gesetzt. Größere Meetings fanden vor allem zu Anfang der drei großen Erweiterungsschritte statt. Abnahmetest Wie weit die Kundenseite Abnahmetests im Sinne von XP zur Funktionalitätsprüfung durchführte, ist leider nicht bekannt. Feedback langte aber ein, woraus man schließen kann, dass irgendetwas in diese Richtung gemacht wurde. Einfaches Design Da am Support Tracking System verschiedene Personen gearbeitet hatten, hat sich mit der Zeit das Design verkompliziert. Einige augenscheinlich gewordene Designschwächen wurden mit Hilfe von Refaktoring beseitigt. Programmieren in Paaren Konnte nicht praktiziert werden, da das Projektteam meistens nur aus einem Entwickler bestand. Die Phase mit zwei Entwicklern war leider zu kurz, um dieses Konzept umfangreich auszuprobieren. Zu bemerken war allerdings, dass unerfahrenere Partner, dies nicht als Chance begreifen von einander zu lernen. Entwicklertest Eine vollständige Testabdeckung lag nicht vor und außerdem fehlte eine automatisierte Testumgebung. Der sogenannte Test-First-Ansatz kam nicht zur Anwendung. Dieser Umstand erschwerte vor allem das Refaktoring. Kapitel 7 Erkenntnisse 93 Refaktoring Trotz Empfehlung Refaktoring laufend anzuwenden, wurde versucht durch Refaktoring das Design in einem großen Schritt zu vereinfachen. Dies gelang nur teilweise und war auf Grund der fehlenden Testfälle bzw. nicht vorhandener Testumgebung äußerst mühsam und frustrierend. Vorhandene Testfälle verschieben die Neuimplementierung auf einen späteren Zeitpunkt, während nicht vorhandene Testfälle eine Neuimplementierung früher notwendig machen. Gemeinsame Verantwortung Hier gilt das Gleiche, wie unter Programmieren in Paaren. Programmierstandards Da ungefähr fünf bis sieben Programmierer ohne entsprechende Codierstandards an dieser Software gearbeitet haben, sind entsprechende Stiele im Code auszumachen. Ein wenig davon wurde während des Versuches Refaktoring zu betreiben vereinheitlicht. Niedergeschriebene Standards existieren weiterhin nicht für dieses Produkt. Fortlaufende Integration Support Tracking System wurde sukzessive mit neuer Funktionalität ausgestattet. Dies wäre allerdings wesentlich einfacher gewesen, hätte es eine automatisch ablaufende Testabdeckung gegeben. Metapher Metapher wurde keine gefunden, da aber mit STS V1.0 schon ein Produkt vorhanden war, welches in Produktion stand, war der Verwendungszweck klar. Nachhaltiges Tempo Sieht man von etwas mehr Zeitaufwand vor Terminen ab, so wurde diese XP Praktik eingehalten. Von einem vollständigen XP Prozess war man also ein gutes Stück entfernt. Die Annahme, dass agile Prozesse für die Wartungsphase besser geeignet sind, konnte nicht bestätigt werden. Ausreichende Testfälle, eine automatisierte Testumgebung und fortlaufendes Refaktoring sollten aber die Wartungskosten senken. Es stellt sich die Frage, ob eine komplette Neuimplementierung nicht günstiger gewesen wäre. 7.3 Adaptierbare Webapplikation Die Einführung adaptierbarer Systemeigenschaften funktionierte sehr gut. Mit STS V1.3 können Ticketattribute in Wertetabellen angegeben werden. Dadurch ist eine Domänenabbildung des Einsatzbereiches möglich. Die Standardkonfiguration deckt die Bedürfnisse von Hyperwave ab. Kundendatenbank ist aus dem Quellcode entfernt worden. Die Schnittstelle zu den Kundendaten ist soweit vorbereitet, dass die Anbindung an eine richtige Datenbank jederzeit möglich wäre. Funktionalität ist für die verschiedenen Rollen aktivierbar. Das Eskalationsmodell und E-Mail Benachrichtigungen sind adaptierbar. Die Einführung der Adaptierbarkeit im Bereich der Systemeigenschaften ist abgeschlossen. Eine mögliche Verbesserung wäre, dass die Anpassungen nicht durch Editieren von Dateien erfolgt, sondern mittels Formularen. Kapitel 7 Erkenntnisse 94 Die adaptierbare Benutzeroberfläche funktioniert sehr gut. Die HTML Vorlagen auch Templates genannt, funktionieren nach anfänglichen Schwierigkeiten mit dem Netscape Communicator mittlerweile sehr gut. Die entworfenen STS Tags, die sich in HTML Kommentaren verstecken, sind für die Designer der Benutzeroberfläche nicht ganz optimal. Leider war es nicht möglich auf das Ergebnis von Berechnungen gänzlich zu verzichten, dadurch ist es die Trennung der Benutzeroberfläche von der Business Logik nicht vollständig gelungen. Ein letzter noch nicht durchgeführter Schritt, wäre die Ausweitung des Konzeptes auf die zur Dateneingabe verwendeten Webformulare. Kapitel 8 Zusammenfassung Trouble Ticket Systeme sind für die Verwaltung von Problemen, Fehlern und Störungen zuständig. Das Support Tracking System ist ein Trouble Ticket System, das an der Schnittstelle zwischen Kunden und Support zum Einsatz kommt. Zu jeder Störmeldung von Kunden wird ein Supportticket angelegt. Die gesamte Kommunikation zwischen Kunden und Supportmitarbeitern wird in Ticketeinträgen festgehalten. Trouble Ticket Systeme systematisieren das Fehlermanagement bestehend aus Fehlererkennung, Fehlerdiagnose und Fehlerlösung. Für das Support Tracking System bestand die Anforderung weitere Funktionalität, Adaptierbarkeit des Systemkerns und eine neue adaptierbare Benutzeroberfläche zu implementieren. Diese Erweiterungen wurden notwendig, damit das Support Tracking System bei verschiedenen Kunden mit unterschiedlichen Anforderungen eingesetzt werden kann. Diese progressive Pflegetätigkeiten wurden parallel zu korrektiven Wartungsarbeiten durchgeführt. Obwohl davon auszugehen war, dass durch die Adaptierbarkeit der Wartungsaufwand sinken würde, wurde nach weiteren Möglichkeiten gesucht die Wartungskosten zu senken. Die Auseinandersetzung mit dem Thema Wartung ergab, dass man zwischen korrektiven Wartungsarbeiten und progressiven Pflegearbeiten unterscheiden sollte. Sowohl für die Fehlerbehebung als auch für die Erweiterung eines Programms erwies sich Refaktoring als eine nützliche Arbeitstechnik. Diese aus dem Bereich der agilen Softwareentwicklungsprozesse stammende Arbeitstechnik, erlaubt es das Design von Software zu verändern unter Sicherstellung, dass die Funktionalität erhalten bleibt. Weil für das Support Tracking System keine automatisierte Testumgebung vorlag, erwiesen sich die Refaktoringschritte als sehr mühsam und zeitintensiv. Sie wurden aber trotzdem gesetzt, um das Design der Software zu verbessern und um Erweiterungen wie die Adaptierbarkeit realisieren zu können. Die Arbeitstechniken der agilen Softwareentwicklungsprozesse können die Wartungskosten nur senken, wenn sie in Kombination eingesetzt werden, d.h. das Refaktoring nur dann Kosten senkt, wenn es schnell und effizient eingesetzt werden kann, weil ausreichend Testfälle in einer automatisierten Testumgebung vorhanden sind. Das Support Tracking System konnte erfolgreich in eine adaptierbare Webapplikation umgewandelt werden. Das Support Tracking System kann in kurzer Zeit an verschiedene Kundenbedürfnisse angepasst werden, ohne dass hohe Wartungskosten entstehen würden. Zum einem wurden adaptierbare Systemeigenschaften eingeführt. Dazu zählen Ticketattribute, Werte für Ticketattribute, Kundendatenbank, Kapitel 8 Zusammenfassung 96 rollenabhängige Funktionen, konfigurierbarer Workflow und personalisierbare Benachrichtigungen. Zu den adaptierbaren Systemeigenschaften gehört auch eine adaptierbare Benutzeroberfläche. Eine nicht veränderbare Benutzeroberfläche würde verhindern, dass die Adaptierungen der Systemeigenschaften sichtbar werden. Die adaptierbare Benutzeroberfläche erlaubt es außerdem das Support Tracking System an das "Look and Feel" anderer beim Kunden im Einsatz befindlicher Software anzupassen. Die beiden Ebenen der Adaptierbarkeit haben zu einem starken Rückgang der Wartungsarbeiten am Support Tracking System geführt. Literaturverzeichnis [Abacus 1998] Abacus; Aegis Defect Tracking; Stand: Februar 2004 URL: http://www.abacus-systems.com/AegisDT.htm [Balzert 1996] Balzert, H.; Lehrbuch der Software-Technik: Software-Entwicklung; Heidelberg, Berlin, Oxford; Spektrum, Akad. Verl, 1996 [Balzert 1998] Balzert, H.; Lehrbuch der Software-Technik: Software-Management, SoftwareQualitätssicherung, Unternehmensmodellierung; Heidelberg, Berlin; Spektrum, Akad. Verl., 1998 [Beck 2000] Beck, K.: Extreme Programming: Die revolutionäre Methode für Softwareentwicklung in kleinen Teams; München; Addison-Wesley Verlag, 2000 [Beck 2001] Beck, K.: Manifesto for Agile Software Development; Stand: Februar 2004 URL: http://www.agilemanifesto.org/ [Benham 1999] Benham, D.: Debian Bug Tracking System; Stand: Februar 2004 URL: http://www.benham.net/debbugs [Coldewey 2002] Coldewey, J.: Multi-Kulti: Ein Überblick über die Agile Entwicklung; OBJEKTspektrum: Die Zeitschrift für Web- und Objekttechnologie; Troisdorf; SIGSDATACOM GmbH; S.: 69-77; 01/2002 [Eaten 2002] Eaten, D.: Configuration Management Frequently Asked Questions; Stand: Mai 2002 URL: http://www.daveeaton.com/scm/ [Fink et. al. 1997] Fink, J.; Kobsa, A.; Schreck, J.: Personilzed Hypermedia Information Provision Through adaptive and adaptable system features: User modeling, privacy and security issues; Proceedings of the Fourth International Conferences on Intelligence in Services and Networks; Springer; S.: 459-467; 1997 [Fowler 2000] Fowler, M.: Refactoring: Wie Sie das Design vorhandener Software verbessern; München; Addison-Wesley Verlag, 2000 [Free Software Foundation 2004] Free Software Foundation; Double Choco Latte; Stand: Februar 2004 URL: http://dcl.sourceforge.net/features.php [Free Software Foundation 2000] Free Software Foundation; Gnats – Bug Tracking System; Stand: Februar 2004 URL: http://www.gnu.org/directory/GNU/gnats.html [Free Software Foundation 2000b] Free Software Foundation; gnats – Summary; Stand : Februar 2004 URL: http://savannah.gnu.org/projects/gnats [Free Software Foundation 2003] Free Software Foundation; GNATS; Stand: Februar 2004 URL: http://www.gnu.org/software/gnats/ [Gamma et. al. 1996] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J.: Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software; Bonn; Addison-Wesley-Longman, 1996 [Gössler 1999] Gössler, C.; Support Tracking System: Object Reference; IICM Technische Universität Graz, 1999 [Hyperwave 1999] Hyperwave: Hyperwave Administrator's Guide; München, 1999 [Hyperwave 1999a] Hyperwave: Hyperwave Programmer's Guide; München, 1999 [Hyperwave 1999b] Hyperwave: Hyperwave User's Guide; München, 1999 [IBM 2004] IBM; Rational ClearQuest; Stand: Februar 2004 URL: http://www-306.ibm.com/software/awdtools/clearquest/ [IBM 2004b] IBM; Rational ClearDDTS; Stand: Februar 2004 URL: http://www-306.ibm.com/software/awdtools/clearddts/ [Jackson 1994] Jackson, I.: Debian bug tracking software; Stand: Februar 2004 URL: http://www.chiark.greenend.org.uk/~ian/debbugs [Kruse 2001] Kruse, R.: Entwicklung eines Werkzeuges für die Administration eines Trouble Ticket Systems; Fernuniversität Hagen; 2001; URL:http://www.ice-bachelor.fernuni-hagen.de/Forschung/Forschungsbericht2_2001.pdf [Link 2002] Link, J.; Unit Test mit Java: Der Test-First-Ansatz; Heidelberg; dpunkt-Verlag, 2002 [Mozilla Organisation 2003] Mozilla Organisation; Bugzilla: Bug Tracking System; Stand: Feb.2004 URL: http://www.bugzilla.org/about.html [OmniNet 2001] OmniNet GmbH.; Service-Management mit OmniTracker; Stand: Februar 2004 URL: http://www.omninet.de/german/id_otpos.html [Schade 1999] Schade, O.; Problemsortierer: Freie Trouble-Ticket-Systeme; iX 9/1999; Heise Verlag; S70-75, 1999 [Wurzenberger 1999] Wurzenberger, G.; hwlib: Reference Guide; IICM Technische Universität Graz, 1999 Abbildungsverzeichnis Abbildung 2-1: Phasen des Fehlermanagements nach[Kruse 2001] ..................................... 7 Abbildung 4-1: Formulargenerator ...................................................................................... 39 Abbildung 4-2: Prototypeobjekthierarchie (HWLIB) nach [Wurzenberger 1999].............. 40 Abbildung 4-3: Verändern von Mitarbeiterdaten ................................................................ 42 Abbildung 4-4: Supportticket einen neuen Mitarbeiter zuweisen ....................................... 43 Abbildung 4-5: Formular für das Erzeugen eines Notizeintrages ....................................... 43 Abbildung 4-6: Anlegen eines neuen Supporttickets .......................................................... 45 Abbildung 4-7: Neue Suchabfrage erstellen ........................................................................ 46 Abbildung 4-8: Suchergebnis .............................................................................................. 47 Abbildung 4-9: Prototypeobjekthierarchie (STS) nach [Gössler 1999] .............................. 48 Abbildung 6-1: Sicht auf die Ticketdarstellung unter STS V1.2 ......................................... 69 Abbildung 6-2: Mit der HTML Vorlage sts_base generiert ................................................ 78 Abbildung 6-3: Mit der HTML Vorlage sts_ticketobject_object generiert ......................... 80 Abbildung 6-4: Mit der HTML Vorlage sts_ticketobject_content generiert ....................... 83 Abbildung 6-5: Mit der HTML Vorlage sts_noteentry generiert ........................................ 84 Abbildung 6-6: Mit der HTML Vorlage sts_phonenoteentry generiert .............................. 85 Abbildung 6-7: Mit der HTML Vorlage sts_schedulenoteentry generiert .......................... 85 Abbildung 6-8: Mit der HTML Vorlage sts_emailentry generiert ...................................... 88 Abbildung 6-9: Sicht auf ein Supportticketverzeichnis ....................................................... 88 Abbildung 6-10: Ansicht eines Supporttickets mit einer Telefonnotiz als Eintrag ............. 89 Tabellenverzeichnis Tabelle 3-1: Gegenüberstellung von Wartung und Pflege nach [Balzert 1998] .................. 22 Tabelle 3-2: Eigenständiger Wartungsabteilungen nach [Balzert 1998] ............................. 23 Tabelle 5-1: Methoden der Klasse sts_AttributeInterfaceObject ........................................ 66 Tabelle 6-1: Ausgabemethoden ........................................................................................... 69 Tabelle 6-2: Methoden für insert_functionresult und deren Vorkommen ................ 73 Anhang A Nichtkommerzielle Produkte Produktname URL Bugzilla http://www.bugzilla.org/ Debian Bug Tracking System (debbugs) http://www.chiark.greenend.org.uk/~ian/debbugs http://www.benham.net/debbugs GNU GNATS (GNU Problem http://www.cuug.ab.ca:8001/~macdonal/tkgnats.html Report Management System) Jitterbug http://samba.anu.edu.au/cgi-bin/jitterbug Opentrack (OT) http://www.accurev.com/ot PTS, XPTS und Web/PTS http://www.halcyon.com/dean/pts/pts.html PTS, Keystone http://www.stonekeep.com wrek http://www.math.duke.edu/~yu/wreq Anhang B Kommerzielle Produkte Produktname URL +1CR http://www.plus-one.com AccuRev/Dispatch http://www.accurev.com/dispatch Aegis http://www.abacus-systems.com AllChange http://www.intasoft.co.uk/intasoft Apriori http://www.platinum.com/products BugBase http://www.bugbase.com CCC/Harvest http://www.ca.com/products/ccm ClearDDTS http://www.rational.com/products/clear_ddts ClearQualtity http://www.clarify.com ClearQuest http://www.rational.com/products/clearquest ClearTrack http://www.clrstream.com/ClearTrack.htm Census http://www.metaquest.com Change Synergy http://www.telelogic.com Control First und TRUEtrack http://www.truesoft.com/truetrack.php Defect WorkFlow (DWF) http://www.softquest.co.il DTS http://www.open.com.au/dts ExtraView http://www.extraview.com GLOBETrack http://www.globetrotter.com IssueView http://www.issueview.com Lotus Notes http://www.lotus.com/ NeumaCM+ http://www.neuma.com OmniTracker http://www.omninet.de PR-Tracker http://www.prtracker.com Problem Tracker http://www.n2r6.com Produktname URL PVCS Dimensions http://www.merant.com/pvcs/products PVCS Tracker http://www.merant.com Siebel http://www.siebel.com Razor http://www.razor.visible.com Remedy ARS http://www.remedy.com SWBTracker http://www.softwarewithbrains.com TeamTrack http://www.teamshare.com Track for Windows http://www.soffront.com TrackRecord http://www.compuware.com TrackWise http://www.sparta-sys.com Vantive Quality http://www.peoplesoft.com Visual Intercept http://www.elsitech.com Anhang C Refaktoring Ratschläge von Martin Fowler Wenn Sie zu einem Programm etwas hinzufügen müssen und die Struktur des Programms erlaubt dies nicht auf einfache Art und Weise, so refaktorisieren Sie zunächst das Programm so, dass Sie die Erweiterung leicht hinzufügen können und fügen sie anschließend hinzu. Bevor Sie zu refaktorisieren beginnen, prüfen Sie, ob Sie eine solide Menge von Testfällen haben. Diese Tests müssen selbstprüfend sein. Beim Refaktorisieren ändern Sie das Programm in kleinen Schritten. Machen Sie einen Fehler, so ist er leicht zu finden. Jeder Dummkopf kann Code schreiben, den ein Computer versteht. Gute Programmierer schreiben Code, den Menschen verstehen. Drei Mal und Sie refaktorisieren. Veröffentlichen Sie keine unausgereiften Schnittstellen. Ändern Besitzverhältnisse am Code, um das Refaktorisieren zu vereinfachen. Sie die Wenn Sie glauben, einen Kommentar zu benötigen, refaktorisieren Sie den Code, so dass jeder Kommentar überflüssig wird. Stellen Sie sicher, dass alle Tests vollständig automatisiert werden und dass Sie ihre Ergebnisse selbst überprüfen. Eine Testsuite ist ein leistungsfähiger Fehlerdetektor, der die Zeit für die Fehlersuche dramatisch reduziert. Führen Sie Ihre Tests oft aus. Verwenden Sie Ihre Tests bei jeder Umwandlung – jeden Test mindestens einmal täglich. Bekommen Sie einen Fehlerbericht, so schreiben Sie einen Komponententest der den Fehler erkennt. Es ist besser, unvollständige Tests zu schreiben und durchzuführen, als vollständige Tests nicht auszuführen. Denken Sie an die Randbedingungen, unter denen Dinge schief gehen können, und konzentrieren Sie Ihre Tests auf diese. Vergessen Sie nicht Ausnahmen zu testen, die ausgelöst werden, wenn etwas schief gegangen ist. Lassen Sie sich durch die Furcht, nicht alle Fehler zu finden, nicht davon abhalten, die Tests zu schreiben, die die meisten Fehler finden.
