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.
Herunterladen
Explore flashcards