Die untere Grafik präsentiert den Ablauf (Workflow) von der Meldung eines Problems bis zur Abschliessung.
In diesem Dokument werden kurz die Features von S.mon in der Version 1.1 beschrieben.
S.mon steht für Service Management Online. Es ist eine sog. Defect Tracking Software, eine Applikation, die zur Aufzeichnung von Problemen von der Enstehung bis zu deren Lösung dient.
S.mon ist eine Web-Applikation, die mittels Java-Technologien implementiert wurde. Die Applikation basiert auf Servlet-Technologie. Bei Erstellung von HTML-Seiten kommt auch stark die XML-Technik (Extensible Markup Language) zum Einsatz. Es wurde auf eine strikte Trennung zwischen Daten und Layout geachtet. Die Java-Klassen kümmern sich ausschließich um die Logik und liefern nur Daten aus. Die Daten werden am Ende durch eine Transformation (XSLT) ins HTML-Format konvertiert und zum Browser geschickt. Mit dieser Architektur ist man sehr flexibel, was das Layout betrifft. Ein Käufer kann sich das Layout leicht an eigene Bedürfnisse (Corporate Design) anpassen, ohne den Programm-Code ändern oder verstehen zu müssen.
Alle S.mon Daten werden in einer relationallen Datenbank gespeichert. Der Zugriff auf die Datenbank erfolgt über JDBC-API (Java Database Connectivity). Dadurch wird die Datenbankunabhängigkeit gewährleistet. Das Programm wurde mit zwei kommerziellen (Oracle, MS SQL Server) und zwei frei verfügbaren (MySQL, PostgreSQL) Datenbanken getestet. Man kann aber jede Datenbank einsetzen, welche einen JDBC-Treiber besitzt und welche Transaktionen und BLOB-Datentypen unterstützt.
Auf der Client-Seite wird keine extra Software installiert. Man braucht nur einen Web-Browser (Netscape, Mozilla, Explorer, Opera, ...), um arbeiten zu können. Auch die ganze Administration kann von einem Browser aus durchgeführt werden. Es gibt keine extra Anforderungen an den Web-Browser. Es wird eine Unterstützung von CSS (Cascading Stylesheet) und von Unicode (UTF8) vorausgesetzt, was heutzutage von jedem Browser erfüllt sein sollte. Die Benutzer Sessions werden mittels Cookies realisiert, deswegen muß ein Browser auch ein Cookie akzeptieren müssen. S.mon wurde so entwickelt, daß JavaScript am Browser nicht aktiviert werden muß. Gewisse Funkionalität kann man jedoch bequemer realisieren, wenn JavaScript aktiviert ist. Um den reibungslosen Ablauf zu gewährleisten sollte der Browser-Cache so konfiguriert werden, daß bei jedem Zugriff auf eine Seite geprüft wird, ob sich diese geändert hat.
Folgende Features können in einer Lizenzdatei gesetzt werden:
Die englischen Begriffe "Defect", "Ticket" oder "Case" können als Synonyme für das Wort Problem verwendet werden.
Jedem Problem wird eine eindeutige Nummer zur Identifikation automatisch
zugeordnet. Bei einer Problem-Meldung muß man einen Titel und die
detaillierte Beschreibung angeben. Jedes Problem hat auch eine Priorität,
welche fü die Problem-Behebung eine entscheidende Rolle spielt.
Es gibt viele andere Attribute, die mit einem Problem mitgespeichert werden.
Manche dieser Attribute werden von der meldenden Person, manche durch den
Sachbearbeiter ausgefüllt. Viele Werte werden auch automatisch vom System
bei dem gesamten Workflow gesetzt. Die Details zu den möglichen Werten
sollte man dem in dem Datenbank-Model nachlesen.
Die untere Grafik präsentiert den Ablauf (Workflow) von der Meldung
eines Problems bis zur Abschliessung.
| Zustand | Name | Beschreibung |
|---|---|---|
| N | New | Anfangszustand für neu gemeldete Probleme. Das neue Problem ist im System gespeichert. |
| P | Postponed | Der Assigner entscheidet, daß das Problem nicht so wichtig ist und aufgeschooben wird. An diesem Problem wird nicht gearbeitet. Zu einem späterem Zeitpunkt kann man das Problem einem Bearbeiter zuweisen. Dieser Zustand ist optional. |
| A | Assigned | Ein Problem befindet sich in diesem Zustand, wenn es von dem Assigner einem Bearbeiter zugewiesen wurde. Es heißt aber noch nicht, daß an der Lösung des Problems gearbeitet wird. Es heißt lediglich, daß das Problem von einer Person angesehen wurde, und es wurde entschieden, wer für die Behandlung des Problems verantwortlich ist. |
| O | Opened | Ein Problem ist in diesem Zustand, wenn der Bearbeiter es "wahrgenommen" hat. Die Person, der das Problem zugewiesen wurde, hat sich mit der Problembeschreibung vertraut gemacht und das Problem zur Bearbeitung akzeptiert. |
| F | Forwarded | Dieser Zustand wird erreicht, wenn ein Bearbeiter das Problem an einen anderen Bearbeiter weiterleitet. Wird die Weiterleitung von dem neuen Benutzer akzeptiert, dann übernimmt diese Person ab diesem Zeitpunkt die Verantwortung für die Problembehandlung. Ansonsten bleibt die Verantwortung bei dem letzten Bearbeiter. |
| W | Waiting | Es ist nicht üblich bei einer Defect Tracking Software, solchen Zustand zu haben. Es ändert sich nählich nichts in der Problembehandlung, das Problem muß nach wie vor bearbeitet werden. Dieser Zustand besagt lediglich, daß der Bearbeiter auf eine Information vom Problemmelder wartet. |
| L | Forwarded to Next Service Level | Das Ticket wurde zum nächsten Service Level weitergeleitet. Es wird eine Kopie des Originaltickets gemacht und diese wird als neues Ticket bei dem nächsten Service Level bearbeitet. Beide Tickets sind miteinander verlinkt. Sobald das neue Ticket abgeschlossen ist, wird der Bearbeiter benachrichtigt und kann die Arbeit mit dem Originalticket fortsetzen. |
| R | Resolved | Dieser Zustand besagt, daß der Bearbeiter mit der Problemlösung fertig ist. Das Problem konnte gelöst (behoben) werden. Eine Beschreibung der Lösung sollte angegeben werden. Es ist auch möglich zu sagen, daß es eine falsche Meldung (kein Problem) war oder daß es sich um ein Duplikat von einem anderen Problem gehandelt hat. |
| V | Verified | Dieser Zustand ist optional. Wenn die Problemlösung akzeptiert wurde, gelangt man zu diesem Zustand. |
| C | Closed | Endzustand eines Tickets. Die Lösung ist verfügbar und wurde akzeptiert (optional). Die Bearbeitung des Tickets ist damit abgeschlossen. |
Die untere Liste gibt kurzen Überblick über weitere Features:
Immer wenn Sie sich von einem Browser am Server anmelden, können Sie sich sicher sein, daß Ihr Paßwort nicht abgehört werden kann. Es wird auch nicht beim einem Web-Proxy-Server in einem Log-File mitgespeichert.
In der Datenbank werden auch keine Paßwörter im Klartext gespeichert. Die Paßwörter der S.mon Benutzer werden in der Datenbank verschlüsselt abgelegt. Dadurch kann auch kein Datenbank-Administrator Ihre Geheimnisse lesen.
Jeder Benutzer kann auch selbst das eigene Paßwort jede Zeit ändern.
Jedes Produkt, für welches Probleme gemeldet und dann weiter behandelt werden, ist durch ein sog. Access Control List (ACL) gesichert. Ein ACL definiert wer welche Zugriffsrechte für dieses Produkt besitzt. Hier wird zum Beispiel gespeichert, wer die Probleme lesen darf. Um die ACL-Verwaltung zu erleichtern, wurden auch drei Meta-Benutzer (oder Meta-Gruppen) definiert:
Die Hilfe steht derzeit nur in der englischen Sprache zur Verfügung.
Bevor die Suchergebnisse angezeigt werden, müssen die vom DB-Server gelieferten Daten einen Security-Filter passieren. Der Security-Filter entfernt alle Ergebnisse aus der Liste, welche für den jeweiligen Benutzer nicht freigegeben wurden.
Die Volltext-Suche wurde auf der Basis vom Apache-Projekt Lucene realisiert.
Derzeit werden folgende Dokument-Formate bei Fulltext-Search unterstützt:
Die Auswertung kann man für ein gesamtes Jahr, ein Monat oder für ein Quartal durchführen.
Die Statistiken sind sowohl für Kunden als auch Benutzer sowie den Administrator verfügbar. Dabei sind jedoch die Auswahlkriterien und die Ergebnisse unterschiedlich. Ein Administrator kann alle Statistiken sehen. Die Kunden können nur Statistiken über die Probleme des jeweiligen Kunden bilden und ein Bearbeiter sieht die Statistiken nur über die Probleme, für die er zuständig ist.
Für komplexe Statistiken kann eine spezielle Reporting-Software wie z.B. BusinessObjects oder Crystal Reports eingesetzt werden.
Die Kriterien für eine Benachrichtigung sind sehr flexibel. In erster Linie wählt man die gewünschten Zustände aus. Dann gibt man an, für welches Produkt man sich interessiert. Die Bearbeiter können auch die Benachrichtigung auf Probleme von einem bestimmten Kunden einschränken. Durch Eingabe von einer Problem-Nummer ist auch möglich die Änderungen über ein einzelnes Problem zu verfolgen. Zusätzlich kann man auch entscheiden, ob man eine Benachrichtigung für alle Probleme, oder nur für die selbst gemeldeten, haben will.
Derzeit gibt es keine Einschränkung bezüglich der Anzahl von Benachrichtigungen. Dies wird sich wahrscheinlich mit nächster Version ändern, so daß es ein Maximum (10-20 pro Benutzer) geben wird.
Um eine Benachrichtigung zu bekommen, muß für den jeweiligen Benutzer eine E-Mail-Adresse konfiguriert werden. Eine Benachrichtigung wird folgende Adresse verwendet:
Die Bearbeiter an die ein Problem zugewiesen wird, werden immer automatisch benachrichtigt, ohne daß sie dafür eine Benachrichtigung konfigurieren müssen. Auch wenn ihre Problemlösung abgeleht wird, werden sie darüber immer informiert.
Ein System-Administrator kann periodische Berichte für die Benutzer definieren. Diese Benutzer werden dann zu einem gegebenen Zeitpunkt über die Probleme informiert. Man kann z.B. jeden Mitarbeiter täglich über seine offenen (in Bearbeitung) Probleme informieren. Ein Manager könnte z.B. wöchentlich einen überblick über die abgelaufenen (Endtermin für das Fix ist schon vorbei) Probleme bekommen.
Die Berichte sind sehr flexibel zu gestalten.
Man gibt die Uhrzeit an, wann ein Bericht erstellt werden soll. Die Erstellung
kann täglich, wöchentlich (man wählt einen Wochentag aus) oder
monatlich (man wählt einen Tag aus) erfolgen.
Dabei kann man komplexe Kriterien für ein Bericht setzen:
Zu beachten ist, daß man über E-Mail keine Authentifizierung haben kann. Will man diese Funktionalität nutzen, so muß man in dem jeweiligen Produkt das Melden von Problemen auch für anonyme Benutzer erlauben.
Für die hier beschriebene Funktionalität wurde ein allgemeines E-Mail Gateway entwickelt, welches mit S.mon über die SOAP-Schnittstelle kommuniziert.
Jeder Benutzer kann ein einzelnes Problem oder die aktuelle Liste
von Problemen exportieren.
Bei der Export-Funktionalität werden folgende Formate unterstützt:
Das Logbuch hat mit Logging nicht zu tun. Trace-Ausgaben werden im S.mon in eine Log-Datei geschrieben. Diese Datei dient den Entwickler dazu, mögliche Programm-Fehler im System zu finden. Bei dem Logbuch werden alle Einträge in der Datenbank gespeichert. Wie schon oben erwähnt, ein Logbuch dient dazu, um nachzuvollziehen, welche kritische Aktionen (Anmeldung, Paßwort-Änderung, Erzeugen und Löschen von Daten) von wem durchgeführt wurden.
Im S.mon wurde ein asynchrones Event-Management implementiert. Meldet sich ein neuer Benutzer an oder ab, wird ein neues Problem gemeldet oder ein bestehendes modifiziert, so werden die entsprechenden Ereignisse einem zentralen Event-Manager mitgeteilt. Haben sich bei dem Event-Manager einige Klassen (sog. Listeners) registriert, so werden diese über die Ereignisse informiert.
S.mon bietet eine Plugin-Architektur an, so daß der Käufer auch eigene Erweiterungen im System durchführen kann. Es ist möglich bis zu fünf eigene Event-Listeners zu konfigurieren. Für die Details sollte man das Dokument über Events studieren.
Ählich wie bei den Event-Listeners besteht auch eine Möglichkeit eigene Cron-Jobs zu definieren. Es ist ein spezieller Mechanismus, um bestimmte Aktionen zu einer bestimmten Zeit zu erledigen. Intern wird dies System z.B. bei periodischen Berichten verwendet.
Der Käufer hat hier eine flexible Möglichket, das System an eigene Bedürfnisse anzupassen. Man könnte z.B. monatlich alte Probleme löschen, falls diese nicht mehr benötigt werden. Man kann auch eigene Eskalationsmechanismen einbauen, um z.B. schon nach einigen wenigen Minuten (oder Stunden) auf die neu gemeldeten Probleme zu reagieren, falls diese noch nicht in Bearbeitung sind. Der Kreativität sind es hier keine Grenzen gesetzt.
Die SOAP-Schnittstelle dient externen Programmen zur Kommunikation mit S.mon. Man kann z.B. eine eigene Seite im Intranet für Problemmeldung entwerfen, wobei beim Submit über die SOAP-Schnittstelle die Meldung im S.mon gespeichert wird.