A web application for human resources administration

Transkript

1 Diplomarbeit aus Telematik, TU Graz Institut fuer Informationsverarbeitung und Computergestuetzte neue Medien A web application for human resources administration Daniel Gschliesser

2 i Gutachter: O.Univ.-Prof. Dr.phil. Dr.h.c Hermann Maurer Betreuer: Dipl.-Ing. Thomas Dietinger Graz, im Februar 2001 Ich versicherem, diese Arbeit selbständig verfaßt, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfsmittel bedient zu haben.

3 Danksagung Ich möchte mich an dieser Stelle bei allen Mitarbeitern des IICM, sowie der Firma SILVA System Services GmbH, die mich bei der Durchführung dieser Arbeit unterstützt haben und stets bemüht haben, meine Fragen zu beantworten, herzlich bedanken. Besonderer Dank gebührt auch meiner Freundin für ihr Vertändnis und ihre aufopfernde Hilfe. ii Abstract The starting point of this thesis was the need of an online tool for human resources administration of the company SILVA Services GmbH. The subject of this thesis is to describe the implementation and usage of this web based application for human resources administration. The Application gives customers the possibility to book trainers for courses online. There exists an online calender where trainers are able to enter the times they have time to train. The system tries to compute the best trainer for each customer query with that user inputs. It searches for possible dates for the course and takes care about the abilities of every trainer. Furthermore the customer is able to give some feedback to system how he liked the trainer and the course itself. These feedbacks are used for finding the proper trainer. The software design uses a three tier system model which makes the system scalable. Furthermore the implemented objects and the underlying objects can be used in other software projects later on.

4 Zusammenfassung Ausgehend von der Problematik der Trainerverwaltung der SILVA Personaldienstleistung Ges.m.b.H wurde eine Datenbank erstellt, die alle relevanten Daten für eine human resources Verwaltung enthält. Als Front End dient ein beliebiger Web Browser. Das GUI wurde für den Microsoft IIS 4.0 und Microsoft Windows NT 4.0 entwickelt. Die Web Applikation stellt eine Verbindung zwischen Kunden und Trainern dar. Kunden können über das Internet direkt von SILVA Kurse buchen und bekommen automatisch den passenden Trainer zugewiesen. Weiters soll dieses Dokument zeigen, inwieweit das erarbeitete Konzept auf andere Anwendungsgebiete übertragbar ist. Beim Design der Software wurde insbesondere auf die Erweiterbarkeit geachtet, sodass es leicht möglich ist, eine spezielle Lösung einfach zu entwickeln. Ein weiterer Punkt ist die Verwendung von Mobiltelephonen als Eingabemedium. Die Trainer sollen die Möglichkeit haben, ihre Verfügbarbarkeit direkt über ein Handy an die Datenbank zu übermitteln. Auch der umgekehrte Weg ist möglich. Das System informiert die Trainer via SMS über neue Termine und gibt ihnen Bescheid, ob ein Kunde sie gebucht hat.

5 Inhaltsverzeichnis 1 Einleitung Allgemein Klassische Bewertung eines freien Mitarbeiters nach den verursachten Kosten am Beispiel der Fa. NaviConsult Definition Allgemein Klassische Methoden (Telefon) Forderungen an ein human resources administration tool Verfügbarkeit Fähigkeiten Abilities Kundenfeedback Datenflussdiagramme und Use Cases Fixe Kurszeiten Diagramme Entgültige Trainerauswahl Algorithmus zur Trainerauswahl Allgemein Fähigkeiten Erste Auswahl Bewertungen des Trainers miteinbeziehen Gewichtung des Alters von Beurteilungen Definition der Einbindung der Referenzbewertung Setzen von Prioritäten bei Auswahl der Kombinationen Unterschiedliche Fähigkeiten Gleichmäßiges Aufteilen der Aufträge unter dem Personal i

6 INHALTSVERZEICHNIS ii 4 Verwendete Technologien und Produkte Web Interface CGI (Common Gateway Interface) ISAPI (Internet Server Application Programming Interface) ASP (Active Server Pages) Business Layer Allgemein Microsoft Transaktion Server COM Datenbank ADO Microsoft SQL Server Perfomance Vergleich Testumgebung Test Test Test Schlußfolgerungen Entwicklungstools Software Design Allgemein Business Logic Objekt Relationen OFFER.DLL - Details Die Datenbank von rent@trainer Erläuterungen Tabelle PLZ Tabelle COURSEBEGINTIME System Requirements Hardware Software Requirements Installation von rent@trainer 47

7 INHALTSVERZEICHNIS iii 9 Bedienung der Web Site Allgemein Public Area Trainer Area Ändern der persönlichen Daten Eintragen von Kurswünschen Online Kalender Customer Area Feedback Formular Kursinfos Die Buchung Ausblick Katastrophendienste Allgemein Bergrettung Interne Personalbeurteilung Notwendige Änderungen A Tabellen 63 B Views in der Datenbank 71 C Der Algorithmus zur Trainerauswahl 75 D Die Business Logik 78 D.1 Allgemein D.2 CAL.DLL (Interface: Calendar) D.3 CUST.DLL (Interface: Customer) D.4 MISC.DLL (Interface : Misc) D.5 SEC.DLL (Interface Security) D.6 TRAIN.DLL (Interface: Trainer) D.7 BOOKINGS.DLL (Interface: Booking) D.8 OFFERS.DLL (Interface Offer) D.8.1 Methoden D.9 ORDERS.DLL (Interface: ORDER) D.10 MSG.DLL (Interface: Messager) Abbildungsverzeichnis 91

8 INHALTSVERZEICHNIS 1 Tabellenverzeichnis 93

9 Kapitel 1 Einleitung 1.1 Allgemein Das Ein Lösungsansatz für das Problem von Betrieben und Institutionen geeignetes Personal effektiv zu verwalten ist der Inhalt dieses Dokuments. Der klassische Ansatz, wie es noch vielerorts gehandhabt wird, besteht in der Verwendung von Telefonisten, die die Aufgabe haben, Kundenanfragen entgegenzunehmen. Diese Person soll dann ad hoc die Trainer koordinieren und geeignetes Personal dem Kunden zur Verfügung zu stellen. Das ließ die Firma SILVA Personaldienstleistung GmbH ein Projekt initieren, dass sich mit dieser Problematik befassen sollte. Es sollte die Möglichkeit geschaffen werden, Kunden die Möglichkeit zu geben, Trainer direkt und unkompliziert buchen zu lassen. Der gewaltige Verwaltungsaufwand geeignete Trainer zu finden, soll vollautomatisiert ablaufen. Trainer können über das Internet einen Online Terminkalender zur Bekanntgabe Ihrer Verfügbarkeit benützen. Das System wertet diese Angaben aus und liefert innerhalb von Sekunden für jeden Kunden den richtigen Trainer. Dieser kann dann die so erhaltenen Angebote direkt online buchen. Umgekehrt garantiert das System durch seine Auswahlalgorithmen keinen Trainer, der gewisse Mindestanforderungen erfüllt, zu benachteiligen. Die Algorithmen wurden so entwickelt, dass im Mittel alle Trainer, deren Fähigkeiten vergleichbar sind, auch gleich oft gebucht werden. Resultat der Arbeit soll ein System sein, das eine konkrete Implementierung einer Personalverwaltung über das Internet erlaubt. Die entwickelten Komponenten sollen aber auch in anderen, vergleichbaren Szenarien einsetzbar sein. 2

10 KAPITEL 1. EINLEITUNG Klassische Bewertung eines freien Mitarbeiters nach den verursachten Kosten am Beispiel der Fa. NaviConsult (Info: Heike Pratter, Personalwesen, 1999) Um zu zeigen, dass das Problem der Personalbeurteilung nicht nur auf die Firma SILVA beschränkt ist, wird die Vorgehensweise in der Firma NaviConsult beschrieben. Es ist zu sehen, dass die automatisierte Beurteilung noch in den Kindeschuhen steckt, bzw. nicht vorhanden ist. Die Motivation für die Entwicklung einer automatisierten human resource Verwaltung ist nicht nur für den konkreten Anwendungsfall SILVA gegeben, sondern spiegelt sich auch in anderen Firmen wieder. Die Fa. NaviConsult entwickelt EDV Systemlösungen. Im konkreten wird eine große Buchhaltungssoftware, die auch das Personalwesen abdeckt, kundenspezifisch weiterentwickelt und vermarktet. Die Fa. NaviConsult rundet Ihr Angebot durch Hardwareinstallationen für die Software, sowie Schulungen und Workshops ab. NaviConsult beschäftigt ca. 100 Mitarbeiter österreichweit. Es wird intern keine qualitative Bewertung von den freien Mitarbeitern vorgenommen, im Sinne von rent@trainer. Es werden lediglich alle Kosten, die ein Mitarbeiter verursacht auf ein eigenes projektbezogenes Konto gebucht. Diese Kosten, die auch Spesen und sonstige Aufwendungen abdecken, werden den, dem Kunden verrechneten Kosten, entgegen gestellt. Weiters wird noch festgehalten, wie viele nicht verrechenbare Stunden der Mitarbeiter bei einem Kunden gearbeitet hat. Aus den Verhältnissen verrechenbare Stunden / Kosten und verrechenbare Stunden / nicht verrechenbare Stunden wird dann eine Beurteilung des Mitarbeiters gewonnen. Zufriedenheit des Kunden und Qualität der geleisteten Arbeit gehen in diese Beurteilung nicht ein. Ein Kunde gilt als zufrieden, wenn die gestellte Rechnung akzeptiert wird. Erst bei einer Beschwerde eines Kunden wird die Qualität des Mitarbeiters näher, auch in persönlichen Gesprächen, beleuchtet.

11 Kapitel 2 Definition 2.1 Allgemein Um über Human resources administration sprechen zu können, muss man das Problem zunächst klassifizieren. Prinzipiell geht es darum, Personal für eine bestimmte Aufgabe zu finden. Um diese Aufgabe erfüllen zu können, werden bestimmte Fähigkeiten gefordert. Neben der Kenntnis bestimmter Fähigkeiten wird noch die Verfügbarkeit der human resource gefordert. Ein dritter Punkt, der in dieser Arbeit diskutiert wird, ist das Feedback vom Kunden. Dieses Feedback muss in die Auswahl der human resource einfließen. Diese Beurteilung fällt aber nicht direkt unter den Aspekt Fähigkeiten. Aus diesem Grund wird es hier als eigener Punkt diskutiert. Diese Arbeit nimmt als Beispiel eine Schulungsfirma. Überlegungen, die direkt Bezug auf ein Schulungsunternehmen nehmen, können analog auch auf andere Bereiche übetragen werden. 2.2 Klassische Methoden (Telefon) In unserem Szenario werden Trainer, die als freie Mitarbeiter für das Schulungsunternehmen tätig sind, den Kunden vermittelt. Die Trainer stellen dann für geleistete Schulungen ein Honorar. Diese Form der Zusammenarbeit impliziert, dass die Trainer vor Ort nicht verfügbar sind. Die Trainer haben in der Regel einen weiteren Job und halten bei Bedarf Schulungen ab. D.h. die Trainer der Schulungsfirma sind auf ganz Österreich bzw. in Europa verteilt. Ein weiteres Problem neben dem Lokalitätsproblem ist die eigentliche Verfügbarkeit der Trainer. Da diese freie Mitarbeiter sind und in der Regel anderen Geschäften nachgehen, ist es 4

12 KAPITEL 2. DEFINITION 5 der Schulungsfirma oft nicht möglich, einen Kundenwunsch sofort positiv zu beantworten, weil sie einfach nicht weiß, ob der Trainer zu dem gegebenen Zeitpunkt auch wirklich verfügbar ist. Trainer müssen daher eine Art Verfügbarkeitsplan erstellen, an dem Sie bereit sind, Schulungen abzuhalten. Kann der Trainer an einem Tag nicht unterrichten, obwohl er sich dafür in dem Verfügbarkeitsplan eingetragen hat, so muss er dies umgehend der Zentrale melden. Dies geschieht im Allgemeinen per Telefon zwischen Tür und Angel. Damit ist für den Trainer der Fall erledigt. Er hat ja seine Verfügbarkeit oder seine Nichtverfügbarkeit gemeldet. Nun liegt der Ball bei dem Mitarbeiter der Schulungsfirma, der den Anruf erhalten hat. Er muss nun die Verfügbarkeit des Trainers auf dessen Plan abändern. Für diesen Plan gibt es kein EDV System, sodass hier auf dem Plan aus klassischem Papier mehr oder weniger oft herumgestrichen wird. Je länger im Voraus der Plan jetzt existiert, desto wahrscheinlicher werden auch auf diesem Termine geändert. Neben dem Problem der Verfügbarkeit muss natürlich noch die Befähigung des Trainers für die Schulung festgestellt werden. Hiezu gibt es wieder einen Plan, auf dem, vom Personalchef verifiziert, alle möglichen Schulungen für einen Trainer festgelegt sind. Eine weitere Unterteilung stellt die Sprache dar. Da die Anforderung von meist größeren Firmen besteht, die Schulungen in Englisch oder in einer anderen Sprache zu halten, ist es notwendig, festzuhalten, welcher Trainer welche Schulung in welcher Sprache halten kann. Der Mitarbeiter der Schulungsfirma muss nun anhand zweier unabhängiger Aufstellungen überprüfen, welcher Trainer für die Schulung in Frage kommt. Manuell fast unlösbar wird dieses Problem bei einer genügend hohen Anzahl an Trainern durch die Randbedingung des Terminwunsches: Schulungen gehen im Allgemeinen über mehrere Tage. Das bedeutet, dass Sonn- und Feiertage berücksichtigt werden müssen. Größte Probleme wird der Mitarbeiter der Schulungsfirma haben, wenn ein Kunde mehrere Trainer für einen Kurs buchen möchte, der über mehrere Tage dauert. In diesem Fall müssen die Trainer untereinander koordiniert werden. Die Komplexität dieser Aufgabe wird im folgenden Kapitel genauer erläutert. Ein wichtiger Aspekt in der Auswahl der Trainer ist aber noch nicht angesprochen worden. Neben der Ausbildung und rethorischen Fähigkeiten zählen auch Erfahrung und Kundenpreferenzen. War ein Kunde mit einem Trainer zufrieden, wird er den gleichen Trainer für kommende Schulungen wieder zugewiesen bekommen. Umgekehrt kann ein Kunde verlangen, dass bestimmte Trainer für ihn aufgrund schlechter Erfahrungen nicht mehr in Frage kommen. Zusammengenommen kann man festhalten, dass die oben beschriebenen Probleme ohne den Einsatz geeigneter Software nicht oder nur sehr schwer bzw. umständlich handzuhaben sind. Es wird nun versucht, obige Probleme formaler zu beschreiben und Algorithmen für

13 KAPITEL 2. DEFINITION 6 deren Lösung anzugeben. 2.3 Forderungen an ein human resources administration tool Verfügbarkeit Der klar scheinende Begriff Verfügbarkeit muss zunächst genau definiert werden. Ja nach Standpunkt, bekommt er eine unterschiedliche Bedeutung. Aus der Sichtweise des Trainers bedeutet er, die Zeit die der Trainer insgesamt zur Verfügung steht. In diesem Fall sind eventuelle Fahrzeiten mitberücksichtigt. Hat ein Trainer zum Beispiel an einem Tag von 08:00 Uhr bis 12:00 Uhr Zeit, so bedeutet das, dass die effektive Kursdauer 4h minus der Anfahrtszeit beträgt. Vom Standpunkt des Kunden aus bedeutet der Begriff Verfügbarkeit, die Zeit in der der Trainer bei ihm vor Ort ist. Wir definieren: Verfügbarkeit := reale Zeit, die die human resource zur Verfügung steht. Kundenzeit := die effektive Zeitdauer, in der die human resource dem Kunden zur Verfügung steht. Ein EDV System, dass Schulungen und Trainer verwalten soll, muss dieser Unterscheidung Rechnung tragen. In dieser Arbeit wurden die Wohnorte bzw. die momentanen Trainerschulungen gespeichert und die Entfernung daraus berechnet. Mittels einer empirisch gewählten Geschwindigkeit wurde dann die notwendige Dauer für die Anreise berechnet. Neuerdings ist es ist möglich, diese Zeitdauer auch von Routenplanern errechnen zu lassen. Hiezu benötigt man Routenplaner, die über ein geeignetes API automatisierte Abfragen zulassen. Als Geschwindigkeit wurde für diese Implementierung v := 70Km/h gewählt. Für die folgenden Betrachtungen gilt folgendes: n := Anzahl an Kalendereinträgen für alle Trainer, die in der Datenbank gespeichert sind. Ein Kalendereintrag entspricht in dieser Implementierung einer Zeitdauer, die beliebig lang sein kann. t := Anzahl der Trainer, die bei der Firma beschäftigt sind. m := Kursdauer in Tagen, diese müssen nicht aufeinanderfolgend sein.

14 KAPITEL 2. DEFINITION 7 k := Anzahl an Trainern, die für den Kurswunsch benötigt werden. p := Zeitperiode in Tagen, in der der Kurs stattfinden soll (z.b. innerhalb eines Monats ). Die Verfügbarkeit eines Trainers wird als Liste von Kalendereinträgen gespeichert. Diese Einträge enthalten eine Start- und Endzeit. Um einen Terminwunsch zu überprüfen, muss das System diese Liste durchsuchen. Die Liste wird in einer Datenbank gespeichert, wobei diese nach der Zeit indiziert ist. Das bedeutet, die Abfrage, ob ein Trainer zu einer bestimmten Zeit zur Verfügbar ist, ist von der Ordnung [Alg98, Seite 236]: T n = O (log (n)) (2.1) Dauert ein Kurs m Tage, so benötigt man O(m+log n) Zeit. m ist dabei gegen n sehr klein und kann in der Praxis als Konstante angesehen werden. T m,n = O (m + log (n)) (2.2) Hat man insgesamt t Trainer zur Verfügung und benötigt man für einen Kurs k Trainer, so ergibt sich für die Komplexität: T m,n,k,t = O (( ) ) t (m + log (n)) k (2.3) Fordert man vom System nun die Funktion selbständig nach freien Terminen zu suchen, wobei man als Randbedingung die Periode p vorgibt, innerhalb derer die Schulung stattfinden muss, ergibt sich für die Komplexität [Bar99, Seiten 78,79]: Beispiel: ( ( p ) T m,n,k,p,t = O m ( ) ) t (m + log (n)) k (2.4) Die Schulungsfirma habe 100 Trainer. Für jeden Trainer existieren 100 Kalendereinträge über seine Verfügbarkeit. Ein Kunde benötige für eine Schulung, die fünf Tage dauern soll, drei Trainer. Das System soll einen Termin innerhalb von drei Wochen finden. Sei: m = 5, n = 100, p = 21, t = 100, k = 3 Dann ergebe sich nach obiger Formel T =

15 KAPITEL 2. DEFINITION 8 Geht man davon aus, dass eine elementare Operation (Kalenderzugriff, Vergleich, etc) 10 6 s benötigt, dann käme man auf T = > , 0331s > 6, 3h Dieser Rechnungsaufwand ist nicht vertretbar. Das Ziel eines human administration tool ist es, sofort reagieren zu können. Eine Wartezeit von über sechs Stunden, wie in diesem Fall, ist nicht geeignet. Ein Ziel dieser Arbeit ist es, Methoden aufzuzeigen, wie man durch Ausnützen spezieller Eigenschaften den Rechnenaufwand reduzieren kann Fähigkeiten Abilities Wie eingangs erwähnt, benötigt man für die positive Erledigung einer Aufgabe bestimmte Fähigkeiten. Es gilt nun, diese benötigten Fähigkeiten zu klassifizieren, sodass diese als Eigenschaften der human resource herangezogen werden können, um entscheiden zu können, ob jemand die Aufgabe erledigen kann oder nicht. Die Fähigkeit eine bestimmte Aufgabe erfüllen zu können, ist im Allgemeinen hinreichend komplex und sehr spezifisch. Dieser Umstand macht diese Fähigkeit (fast) nicht auf andere Aufgaben übertragbar. Es wird vielmehr eine Liste von Basisfähigkeiten gespeichert. Um eine Aufgabe positiv abschließen zu können, benötigt man daher auch eine Anzahl von verschiedenen Basisfähigkeiten. Besitzt eine Person alle geforderten Fähigkeiten in ausreichendem Maße, dann kann sie zur Lösung der Aufgabe herangezogen werden. Spezifische Fähigkeiten setzen sich also aus einer oder mehreren dieser Basisfähigkeiten zusammen. Diese Basisfähigkeiten sind auch leicht verwaltbar, da sie zwischen den Aufgaben austauschbar sind. Das Anforderungsprofil aller möglichen Aufgaben (z.b.: aller angebotenen Dienstleistungen) stellt sich dann als Anforderungsmatrix A dar. Die Spalten der Matrix spezifizieren die Basisfähigkeiten, die Zeilen der Matrix stellen die einzelnen Aufgaben dar. Durch Setzen der einzelnen Felder in der Matrix wird festgelegt, welche Fähigkeiten für welche Aufgabe notwendig sind. a 11 a 12 a 1m A = a n1 a n2 a nm Beispiel: Die Schulungsfirma bietet drei verschiedene Kurse in deutsch und englisch an (Zeilen): HTML Grundkurs (Deutsch) HTML Grundkurs (Englisch)

16 KAPITEL 2. DEFINITION 9 Homepage Design (Gestalten ansprechender Sites) (Deutsch) Homepage Design (Gestalten ansprechender Sites) (Englisch) Einführung in Macromedia Dreamweaver (Deutsch) Einführung in Macromedia Dreamweaver (Englisch) Es werden folgende Basisfähigkeiten definiert (Spalten): Unterrichten HTML Homepage Design Macromedia Dreamweaver Englisch Deutsch Die Anforderungsmatrix A sieht wird dann wie folgt aus: A = Bemerkenswert ist die erste Spalte. Unterrichten wird als zusätzliche Basiseigenschaft festgelegt. Das bedeutet, dass es der Firma nicht genügt, wenn sich jemand gut in HTML auskennt. Um unterrichten zu dürfen, muss er zum Beispiel pädagogische Kurse oder bereits Erfahrungen im Unterrichten gesammelt haben. Um jetzt festzustellen, ob ein Trainer für einen Kurs geeignet ist, werden einfach die Werte der entsprechenden Zeile der Anforderungsmatrix mit den Eigenschaften des Trainers verglichen. Der Trainer muss alle Fähigkeiten besitzen, die in der Zeile gesetzt sind. Die Felder der Matrix werden nun nicht mehr nur als bool sche Werte betrachtet, sondern als Zahlenwerte. Diese Zahlenwerte geben einen Schwellwert an. Dieser Schwellwert definiert die Mindestanforderungen, die an das Personal für diese Fähigkeit für diese Aufgabe gestellt werden. Es werden die analogen Werte der Fähigkeiten immer auf 1 normiert. Die Werte der Matrix liegen also zwischen 0 (keine Kenntnis) und 1 (Top).

17 KAPITEL 2. DEFINITION 10 Im obigen Beispiel bedeutet das, dass ein Trainer für den HTML Grundkurs grundlegende Kenntnisse in Macromedias Dreamweaver haben muss. Für den Dreamweaverkurs wird aber gefordert, dass der Trainer perfekt mit der Software umgehen kann. Für die Kurse HTML Grundkurs und Macromedia Dreamweaver (beide in Deutsch) ergibt sich folgendes: 0, 8 0, 9 0, 2 0, 6 0 0, 8 A = 0, 8 0, 9 0, 2 0, , 8 Anmerkung: Die Werte in der Matrix stellen lediglich ein Beispiel dar und werden in der Praxis natürlich unterschiedlich sein. 2.4 Kundenfeedback Neben der eigentlichen Qualifikation spielen die individuelle Preferenzen von Kunden eine große Rolle. Kommt ein Trainer bei einem Kunden sehr gut an, dann kann es sein, dass sein Kontakt mit dem Kunden mehr wiegt als seine fachliche Qualifikation. Gerade im Trainingsbereich spielen derartige Sonderwünsche von Kunden eine große Rolle. Es wird nun versucht, diese Kundenpreferenzen mit einem Feedback-Formular zu erfassen. Der Kunde muss bestimmte Fragen zum Trainer und zum Kurs beantworten. Diese Benotung fließt nun direkt in die zukünftige Auswahl von Trainern ein. Diese Kundenfeedbacks stellen eine Art Akt über den Trainer dar. Da Einträge ein Leben lang gespeichert werden, muss eine Möglichkeit geschaffen werden, dass ein Trainer alte, negative Beurteilungen ausbessern kann. 2.5 Datenflussdiagramme und Use Cases Im Folgenden sollen nun die eben gemachten Überlegungen in Datenflussdiagrammen visualisiert werden. Diese Diagramme sind ein wichtiger Bestandteil beim Erstellen des Softwaredesigns. Im einfachsten Fall wird ein Trainer für einen Kurs benötigt. Für größere Projekte benötigt man jedoch meist mehr Personal. Hier genügt es nicht, obiges Schema wiederholt auszuführen, da eine erfolgreiche Antwort des Systems nur erfolgen darf, wenn die geforderte Anzahl an Personen auch zur Verfügung gestellt werden kann. Werden für einen Auftrag sieben Programmierer benötigt, es stehen aber für den angegebenen Zeitraum nur 3 zur Verfügung, so muss das System eine negative Antwort ausgeben. Außerdem müssen alle Personen zu den selben Zeitperioden Zeit haben. Diese müssen also intern koordiniert werden. Obiges Schema muss also um einen Input Parameter erweitert werden. Count legt fest, wie viel Personal das System für diese Anfrage suchen muss.

18 KAPITEL 2. DEFINITION 11 [ht] 2.6 Fixe Kurszeiten Abbildung 2.1: Datenfluss für einen benötigten Trainer Im Gegensatz zum bisher beschriebenen Szenario, wo nach Verfügbarkeit der Trainer gesucht wird, und der Termin entsprechend der Verfügbarkeit des Personen angepasst wird, werden Kurse auch mit fixen Zeiten angeboten. Kunden können sich in diesem Fall in einen Kurs einschreiben. Hier wird also nicht explizit eine Anzahl von Personal für eine bestimmte Aufgabe gesucht. Die Anzahl der geforderten Trainer ergibt sich implizit aus der Anzahl der Anmeldungen für einen Kurs. Die Aufgabe des Systems liegt nun darin, eine Anmeldung zu verbuchen, oder, falls kein Trainer zur Verfügung steht, die Anmeldung zurückzuweisen. Das System muss dafür sorgen, dass das Verhältnis Trainer/Kunde in einem einstellbaren Verhältnis bleibt. Ist der Kurs mit der gegebenen Anzahl an Trainern ausgebucht, so kann das System entweder einen weiteren Trainer anfordern oder falls die maximale Kursteilnehmerzahl erreicht ist, die Anmeldung zurückweisen. Die Lösung dieser Aufgabe ist im Allgemeinen weniger komplex als das Suchen von freien Terminen für mehrere Trainer, da die Termine ja bereits vom Benutzer vorgegeben werden. Diese Termine richten sich eher nach Kundenwünschen als nach Trainerwünschen. Für die Komplexität zum Suchen eines Trainers ergibt sich aus [2.2] multipliziert mit der Anzahl der Trainer t, da die Berechnung für jeden Trainer extra gemacht werden muss.

19 KAPITEL 2. DEFINITION 12 [ht] Abbildung 2.2: Datenfluss für mehr benötigte Trainer k := Anzahl an Trainern, die für den Kurswunsch benötigt werden. m := Kursdauer in Tagen, diese müssen nicht aufeinanderfolgend sein. n := Anzahl an Kalendereinträgen für alle Trainer, die in der Datenbank gespeichert sind. Ein Kalendereintrag entspricht in dieser Implementierung einer Zeitdauer, die beliebig lang sein kann. t := Anzahl der Trainer, die bei der Firma beschäftigt sind. T m,n,t = O (t (m + log (n))) (2.5) Für den gesamten Kurs (bei k benötigten Trainern) ergibt sich für die Komplexität: T m,n,k,t = O (k t (m + log (n))) (2.6) Erklärung: Bei diesem Szenario wird [2.5] für jeden Trainer hintereinander angewandt, da ja im Bedarfsfall jeweils immer nur ein Trainer benötigt wird und sich der Berechnungsaufwand für die einelnen Trainer nur addiert.

20 KAPITEL 2. DEFINITION Diagramme Die Randbedingungen werden vom Verantwortlichen eingangs gesetzt, bevor ein Kursangebot publik wird. [ht] Abbildung 2.3: Datenfluss für fixe Kurszeiten Der Verantwortliche legt den Kurstermin fest. Ein Kurs setzt sich dabei aus mehreren Tagen zusammen. Für jeden Tag wird die Startzeit und die Dauer festgelegt. Es ist dabei möglich, dass Tage nicht aufeinanderfolgend sein müssen. 2.7 Entgültige Trainerauswahl Die Trainerauswahl muss, wie oben beschrieben, alle drei Punkte, Verfügbarkeit, Qualifikation und Kundenfeedback in genügendem Maße berücksichtigen. Idealerweise werden beiden Parameter, Qualifikation und Kundenfeedback, derartig miteinander verknüpft, sodass ein Ranking der Trainer für diese Aufgabe entsteht. Der Algorithmus muss die beiden Parameter derartig ineinander abbilden, dass es möglich ist, eine Funktion ranking = f(f eedback, qualif iacation) (2.7) zu erhalten. Die Auswahl eines Trainers kann nun anhand dieses Rankings erfolgen. Dies bedeutet, dass jeder Kunde den für ihn optimalen Trainer erhält.

21 KAPITEL 2. DEFINITION 14 Bei dieser scheinbar optimalen Lösung muss nun aber bedacht werden, dass ein guter Trainer immer vor einem schlechteren Trainer (ein Trainer mit einem schlechteren Ranking) ausgewählt wird. Dies hat zur Folge, dass diese schlechter beurteilten oder schlechter qualifiziertern Trainer selten zu einer Schulung kommen und daher auch keine Möglichkeit erhalten, sich zu verbessern. Umgekehrt wird ein guter Trainer aufgrund guten Feedbacks immer hoher im Ranking sein. Es kann nun aber seitens der Schulungsfirma gefordert sein, dass alle verfügbaren Trainer in gewisser Regelmäßigkeit ausgewählt werden müssen, um diese bei Laune zu halten. Diese Forderung steht nun zunächst im Widerspruch mit der Forderung, Kundenanfragen optimal zu lösen. Später in diesem Dokument wird eine Methode vorgestellt, die dieses Problem zu umgehen versucht.

22 Kapitel 3 Algorithmus zur Trainerauswahl 3.1 Allgemein In diesem Kapitel soll nun die Implementierung für die gestellten Anforderungen detailiert erörtert werden. Dieser Abschnitt soll als Grundlage für alternative Implementierungen dienen. Es wird gezeigt, wie man der hohen Komplexität (Gleichung 2.4), mit geschickter Implementierung Herr werden kann. Ausserdem wird versucht, die Algorithmen derart allgemein zu halten, dass alle besprochenen Aspekte abgedeckt werden können. 3.2 Fähigkeiten Erste Auswahl Zunächst werden alle Trainer selektiert, die den angegebenen Kurs in der angegebenen Sprache mit einem minimalen Wissensstand MinKnowledgefaktor halten können. Diese Information wird aus der Tabelle ABILITY (Feld Knowledgefaktor) geholt. Über Knowledgefaktor kann der Administrator die Qualitäten eines Trainers festlegen. Dieser Wert soll als erste Information dienen, wie der Trainer intern eingestuft wird. Durch Setzen von Knowledgefaktor hat der Administrator zum Beispiel die Möglichkeit Trainer für einen Kurs zu sperren, indem er Knowledgefaktor auf einen Wert, der unter Minknowledgefaktor liegt, setzt. Zusätzlich werden alle Trainer herausgefiltert, die die Länge der Anfahrt nicht in Kauf nehmen wollen, und dies als eine Eigenschaft in der Web Site eingetragen haben. Für alle so ermittelten Trainer wird anhand der Kalendereinträge überprüft, welcher 15

23 KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 16 Trainer Zeit hat. Übrig bleibt ein Anzahl von Trainern, die grundsätzlich in der Lage wären, die gestellten Anforderungen zu erfüllen. Das Ziel eines solchen automatischen Systems ist,alle Beteiligten zufrieden zu stellen. Das bedeutet, dass Kunden nur Trainer erhalten, mit denen sie bereits positive Erfahrungen gemacht haben. Weiters soll dafür gesorgt werden, dass alle Trainer möglichst gleichmäßig ausgelastet werden Bewertungen des Trainers miteinbeziehen Um die gestellten Anforderungen zu erfüllen, wurde der Ansatz eines Protokolls gewählt. In dieses Protokoll werden alle Anmerkungen den Trainer und seine Arbeit betreffend, festgehalten. Im konkreten Fall von ist dies ein Feedbackformular, welches die Kunden nach abgeschlossenen Kurs ausfüllen sollen. Dieses Feedbackformular wird online zur Verfügung gestellt und speichert die Angaben des Kunden unmittelbar in die Datenbank (Tabellen FEEDBACK und TRAINERFEEDBACK ). Die Beurteilung von Trainern in einem Protokoll zu speichern, bietet gegenüber einem starren Wert den Vorteil, dass die Leistungen eines Trainers über einen Zeitraum hinweg genau verfolgt werden können. Es wurde ein Algorithmus entwickelt, der ältere Beurteilungen mitberücksichtigt. Erhält ein Trainer von einem Kunden zum Beispiel ein vernichtendes Urteil, so hat er zukünftig die Möglichkeit, diese Scharte aus seiner Geschichte auszumerzen. Es muss noch die Notenskala der Beurteilung definiert werden. Auf der Web Site wird mit dem Schulnotensystem wegen der intuitiven Bedienung gearbeitet. Die Beurteilung muss aber laut Definition immer zwischen 0 und 1 liegen, wobei 1 die höchste Bewertung ist. Das bedeutet, dass unabhängig von der Anzeige im UI (z.b.: Schulsystem 1 bis 5) Beurteilungen intern immer zwischen 0 und 1 angenommen wird. Es muss also vom UI eine Umsetzung auf das interne Bewertungssystem vorgenommen werden (Normierung). Aus allen Beurteilungen, die ein Trainer im Verlauf seiner Laufbahn bei rent@trainer erhalten hat, wird nun ein Mittelwert gebildet. Dabei können Beurteilungen von anderen Kursen und anderen Kunden unterschiedlich gewichtet werden. Außerdem bietet sich die Möglichkeit, ältere Beurteilungen weniger ins Gewicht fallen zu lassen. Dieser gewichtete Mittelwert wird im folgenden mit Ranking bezeichnet Gewichtung des Alters von Beurteilungen Durch den Parameter feedbackageweight kann man die Gewichtungskurve beeinflussen. Ein Wert von 0 würde alle Beurteilungen vom Alter her gleich gewichten. Die Trainer werden in der Reihenfolge ihres Rankings für die Auswahl herangezogen. Da auch Beurteilungen anderer Kunden berücksichtigt werden, tritt das Problem auf, dass ein Trainer, der einmal von irgendeinem Kunden eine positive Beurteilung erhalten hat, immer vor einem Trainer

24 KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 17 gereiht wird, der noch keine Beurteilung hat. Um dieses Problem zu lösen, wird einem neuen Trainer zunächst ein Standard Ranking zugeordnet. Dies soll so bemessen sein, dass ein neuer Trainer vor einem Trainer mit schlechter Bewertung, aber hinter einem Trainer mit guter Bewertung liegen wird. Dieser Standardwert wird mit der Eigenschaft booking.emptyranking festgelegt. Erhält nun ein Trainer von einem anderen Kunden eine positive Beurteilung und liegt diese auch weit zurück, falls sie die einzige ist bildet sie allein die Bewertung, da der Mittelwert eines Wertes immer der Wert selber ist, egal wie man die Gewichtung der Werte setzt. Das würde bedeuten, dass eine positive Beurteilung genügt, um vor einem Neuling gereiht zu werden. Dies wird zum Problem, da neue Trainer nur dann zum Zuge kommen würden, wenn alle anderen Trainer entweder keine Zeit oder schlechte Beurteilungen bekommen hätten. Da dieser Fall bei einem eingeschwungenen System bei ausreichender Traineranzahl im Allgemeinen nicht vorkommen wird, hieße dies effektiv, dass ein neuer Trainer überhaupt nie unterrichten könnte. Abhilfe schafft ein sogenannte Referenzbewertung, die zu den anderen Bewertungen addiert wird. Diese Referenzbewertung wird durch ihre Gewichtung, ihren Wert, sowie ihrem Datum festgelegt (Die Properties: booking.referenceweight, booking.referencevalue und booking.referencetime). Dieser Referenzwert wird nun unter dem Standard Ranking festgesetzt und wird nur wirksam, wenn ein Trainer bereits reale Beurteilungen erhalten hat. Das bedeutet, dass der Trainer zunächst einmal diese negative Referenzbeurteilung ausbessern muss, um vor einem Neuling zu gelangen. Durch geschicktes Setzen der einzelnen Parameter, kann man das System so einstellen, dass zwar eine positive Bewertung des aktuellen Kunden genügt, um vor einem Neuling zu stehen, aber mehrere Beurteilungen von anderen Kunden. er := EmptyRanking okw := OtherCustomerFeedbackWeight ocw := FeedbackOtherCoursesWeight w := FeetBackAgeWeight rw := ReferenceWeight ra := ReferenceAge rv :=ReferenceValue rd := Today d_n := Fedbackdate_n fan := FeedbackRanking für gleichen Kurs, gleichen Kunden fbn := FeedbackRanking für anderen Kurs, gleichen Kunden fcn := FeedbackRanking für gleichen Kurs, anderen Kunden fdn := FeedbackRanking für anderen Kurs, anderen Kunden

25 KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 18 N := Anzahl der Bewertungen. aw = raw = 1 (rd ra) w rv N 1 [ (rd d n ) w (fa n + fb n ocw + fc n okw + fd n ocw okw)] + raw rv rw n=1 Erklärung: ranking = N n=1 aw 1 (rd d n) + raw w (3.1) Obige Formel den im Text beschriebenen gewichteten Mittelwert dar. Die Gewichtung wird je nach Alter, Kurs und Kunde getroffen. rd ra stellt dabei das Alter des Feedbacks in 1 Tagen dar. Mit (rd ra) wird nun das Alter gewichtet, wobei der Parameter w die Alterung w bestimmt. Ist w = 0, so werden alle Beurteilungen unabhängig vom Alter bewertet. Im Gegensatz zu einem normalen Mittelwert wird hier nicht durch die Anzahl N der Gewichtungen dividiert, sondern durch die Summe der Altersgewichte selber. Der Effekt läßt sich am besten durch ein Beispiel erklären. rv=0 (Keine Referenz-Bewertung) w := 1 rd-ra := 5 (Alter der Bewertung in Tagen) N := 1 fa1 := 1 Bei einer Division durch die Anzahl N wäre Ranking = 0, 2. D.h. nur durch des Alters des Gewichtes würde der Trainer schlechter werden. Er würde mit jedem neuen Tag weiter abgewertet. Dividiert man aber durch die Summe der Altersgewichte, bleibt das Ranking konstant auf 1. Es wird also nicht allein durch das Altern verändert. Erst durch einen neues Feedback, mit einem neuen Datum, verändert die Bewertung des Trainers. Beispiel für eine solche Parameterschar: EmptyRanking := 0,7 OtherCustomerFeedbackWeight := 0,1 FeedbackOtherCoursesWeight := 0,5 FeetBackAgeWeight := 0,5 ReferenceWeight := 0,25 ReferenceAge := 200 Tage ReferenceValue := 0,5

26 KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 19 In diesem Fall genügt eine einzelne Bewertung des aktuellen Kunden für den aktuell geforderten Kurs von 0,75, um mit einem Neuling gleichzuziehen, falls die Bewertung ebenfalls 200 Tage zurückliegt. Sollte die Bewertung jünger sein, dann ist der Trainer schon vor einem neuen Trainer gereiht. Aber einer Bewertung von 1 eines anderen Kunden für einen anderen Kurs, die lediglich einen Monat zurückliegt, reicht nicht aus, um vor einen Neuling zu gelangen. Um die idealen Werte für rent@trainer zu finden, existiert ein Microsoft Excel Macro, mit dem man die verschiedenen Auswirkungen der Parameter leicht ausprobieren und überprüfen kann Definition der Einbindung der Referenzbewertung Der eingesetzte Referenzwert löst das Problem, dass neue Trainer nicht zum Zuge kommen würden. Betrachtet man ein eingeschwungenes System, wo alle Trainer bereits Kurse gehalten haben und bereits eine Reihe von Bewertungen protokolliert wurden, verschwindet die Wirkung des Referenzwertes, da sein Wert bei steigender Anzahl von Beurteilungen naturgemäß immer weniger ins Gewicht fällt. Mit dem Knowledgefaktor und dem Ranking bestehen also zwei Möglichkeiten einen Trainer qualitativ zu beurteilen. In der aktuellen Implementierung wird Knowledgefaktor nur als Schwellwert verwendet, unter welchem ein Trainer auf keinen Fall mehr unterrichten darf. Es ist aber auch denkbar, diesen Wert mit in das Ranking einzubeziehen. Beispielsweise könnte man den Knowledgefaktor analog der Referenzbeurteilung in die Berechnung einbeziehen. Ein anderer Ansatz wäre, Knowledgefaktor direkt als Referenzbeurteilung zu verwenden. Diese Erweiterungen ändern aber nicht das Prinzip der Beurteilungen, da man sowohl die Referenzbeurteilung als auch den Knowledgefaktor als eigene Beurteilungen speichern könnte. Man würde sich dadurch die explizite Ausführung dieser Parameter zwar ersparen, aber die Übersichtlichkeit des Algorithmus würde darunter leiden. Für die Komplexität der Berechnung des Rankings gilt: T b,b,n = O ((b + log (B)) n) (3.2) b = Anzahl an Bewertungen des Trainers B = Anzahl aller Bewertungen aller Trainer n = Anzahl benötigter Trainer Anmerkung: log(b) ergibt sich aus dem Datenbankzugriff, welcher indiziert in O(log B) erfolgen kann. [Alg98, Seite 236]

27 KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL Setzen von Prioritäten bei Auswahl der Kombinationen Hat man mehrere Personen zur Auswahl bleibt noch das Problem, der Möglichkeiten, Personen zu kombinieren. Es bestehen zwei Möglichkeiten durch Setzen von Prioritäten die Auswahl der Trainer zu beeinflussen. Entweder es versucht, die möglichst besten Trainer für die Auswahl zu erreichen, oder die Aufgabenstellung verlangt den ehest möglichen Termin. Je nach Aufgabenstellung muss man also zuert die Termine oder die Trainer permutieren Unterschiedliche Fähigkeiten Es sind aber auch Aufgabenstellungen denkbar, die Personal mit verschiedenen Fähigkeiten benötigen. In diesem Fall ist obiger Algorithmus für alle gewünschten Fähigkeiten wiederholt anzuwenden. Das System muss die gesammelten Ergebnisse auswerten und eine negative Antwort retournieren, falls nicht Personal mit allen geforderten Fähigkeiten gefunden werden kann Gleichmäßiges Aufteilen der Aufträge unter dem Personal Mit dem Errechnen des Rankings und der Einbeziehung eines Wissensfaktors hat man probate Werkzeuge immer den besten Trainer für einen Kurs zu finden. Die Konsequenz der Auswahl von besten Trainern ist aber der Umstand, dass Trainer mit geringeren Rankings nicht mehr für einen Kurs ausgewählt werden. Wird ein Trainer mit schlechtem Ranking nicht mehr für einen Kurs ausgewählt, so hat er aber auch nicht mehr die Möglichkeit, sein Ranking zu verbessern. Das bedeutet, dass eine einzige negative Beurteilung einen Trainer für immer aus dem Verkehr ziehen kann. Betrachtet man wieder ein eingeschwungenes System, so ergibt sich folgender Zustand: Einige wenige Trainer teilen sich alle einkommenden Aufträge unter sich auf, während andere Trainer nie gebucht werden. Trainer, die von nie gebucht werden, werden aber über kurz oder lang die Firma verlassen und die Konkurrenz aufsuchen, was natürlich nicht im Sinne eines Personaldienstleistungsbetriebes sein kann. Eine einfache Lösung gleichmäßiger Aufteilung wäre, alle Trainer, deren Ranking über dem Minranking liegt, nicht nach dem Ranking, sondern nach dem Datum des letzten gehaltenen Kurses zu reihen. Mit dieser Methode wäre gewährleistet, dass alle qualifizierten Trainer im Mittel gleich oft gebucht wird. Schulungsunternehmen sind in der Regel darauf bedacht, dass Kunden immer denselben Trainer zugewiesen bekommen, da sich dieser bereits mit den Gepflogenheiten des Kunden auskennt und im Allgemeinen seine Arbeit zielgerechter und dadurch effektiver durchführen kann. In der Diskussion mit Verantwortlichen von Silva stellte sich heraus,

28 KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 21 dass diese Forderung sehr wichtig, ja erfolgskritisch für ein Schulungsunternehmen sein kann. Diese Forderung würde durch den oben beschriebenen Ranking Algorithmus erfüllt, jedoch steht sie im Widerspruch zu der Forderung alle Trainer gleichmäßig auszulasten. Die Lösung besteht in einer Kombination beider Algorithmen. In einem ersten Durchlauf wird nach Stammtrainern gesucht. Ein Stammtrainer ist per Definition ein Trainer, der bei einem Kunden bereits unterrichtet hat und dabei sehr hohe Bewertungen erhalten hat. Zu Qualifizierung eines Stammtrainers wird ein Stammtrainerranking herangezogen. Dieses Stammtrainerranking errechnet sich gleich dem oben beschriebenen Ranking Algorithmus mit dem Unterschied, dass othercustomerfeedbackweight auf 0 und othercoursefeedbackweight auf 1 gesetzt wird. Es werden also alle Bewertungen anderer Kunden ignoriert. Weiters wird ein neuer Schwellwert eingeführt (MinDefaultTrainerRanking). Dieser Schwellwert gibt das minimale Stammtrainerranking an, ab wann ein Trainer als Stammtrainer gewertet wird. Zu beachten ist auch, dass bei der Berechnung des Stammtrainerranking die Referenzbeurteilung nicht benötigt wird. Sollte ein Trainer einmal bei einem Kunden gewesen sein und dort gute Kritiken erhalten haben, so genügt das, um ihn wieder diesem Kunden zuzuweisen. Hier wäre es sogar ein Nachteil, das Ranking gegen einen tieferen Wert hinzugewichten, da dann unter Umständen (je nach Parametervorgabe) mehrere gute Beurteilungen notwendig sind, um einen Trainer zu einem Stammtrainer zu machen. Da die Trainerauswahl bei nicht Vorhandensein eines Trainers nicht mehr ausschließlich vom Ranking abhängt, sondern von den Buchungszeiten, würden dann mehrere Trainer abwechselnd diesem Kunden zugewiesen werden, solange bis eben einer den Status eines Stammtrainers erreicht. Erhält ein Kunde bei seinen ersten drei Buchungen aber drei verschiedene Trainer, so wird dies für seine Einstellung gegenüber dem Schulungsunternehmen nicht unbedingt positiv sein. Wird ein Trainer gefunden, dessen Stammtrainerranking höher als MinDefaultTrainer- Ranking ist, so wird dieser Trainer gebucht. Dieser Trainer wird unabhängig vom Datum seines letzten Einsatzes gebucht. Wird kein derartiger Trainer gefunden, so werden aus allen verbleibenden Trainern, die ja laut Ranking ebenfalls für diese Aufgabe geeignet sind, derjenige gewählt, dessen letzte Buchung am weitesten zurück liegt. Aus Performancegründen wird die Berechnung von Stammtrainer im selben Durchlauf wie das normale Ranking durchgeführt. (Die Daten brauchen in diesem Fall nur einmal aus der Datenbank gelesen werden) Für den Algorithmus siehe Anhang C.

29 Kapitel 4 Verwendete Technologien und Produkte 4.1 Web Interface Aus der Vorgabe der Firma Silva eine Internet Applikation für den MS IIS zu schreiben, stellte sich zunächst die Frage nach den zu verwendeten Technologien. Grundsätzlich gibt es für den MS IIS 4.0 drei grundsätzliche Möglichkeiten, dynamische Webseiten zu generieren CGI (Common Gateway Interface) Das Common Gateway Interface (Allgemeine Vermittlungsrechner-Schnittstelle) ist eine Möglichkeit, Programme im WWW bereitzustellen, die von HTML-Dateien aus aufgerufen werden können und die selbst HTML-Code erzeugen und an einen WWW-Browser senden können. Wenn Sie im WWW eine Suchdatenbank benutzen, Pizza oder Büstenhalter bestellen, sich in ein Gästebuch eintragen, oder einen Zähler mit Zugriffszahlen sehen, dann steckt CGI oder eine CGI vergleichbare Schnittstelle dahinter. CGI - das sind Programme, die auf einem Server-Rechner im Internet liegen und bei Aufruf bestimmte Daten verarbeiten. Die Datenverarbeitung geschieht auf dem Server- Rechner. CGI-Programme können auf dem Server-Rechner Daten speichern, zum Beispiel, wie oft auf eine WWW-Seite zugegriffen wurde, oder, was ein Anwender in ein Gästebuch geschrieben hat. Bei entsprechendem Aufruf kann ein CGI-Programm gespeicherte Daten auslesen und daraus HTML-Code generieren. Dieser dynamisch erzeugte HTML-Code wird an den aufrufenden WWW-Browser eines Anwenders übertragen und kann dort in- 22

30 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 23 dividuelle Daten in HTML-Form anzeigen, zum Beispiel den aktuellen Zugriffszählerstand einer WWW-Seite oder die bisherigen Einträge in einem Gästebuch. Die sogenannte CGI-Schnittstelle muss von der WWW-Server-Software unterstützt werden. Aus Sicht des Mieters von Speicherplatz auf einem WWW-Server steht die CGI- Schnittstelle in Form eines bestimmten Verzeichnisses zur Verfügung. Meistens hat dieses Verzeichnis den Namen cgi-bin. In diesem Verzeichnis können Programme abgelegt werden, die CGI-Aufgaben übernehmen. Falls Sie unsicher sind, fragen Sie Ihren Provider, ob er Ihnen eine CGI-Schnittstelle zur Verfügung stellt. Bei preiswerten oder gar kostenlosen Homepage-Vermittlern wie CompuServe, AOL usw. steht Ihnen normalerweise keine CGI- Schnittstelle zur Verfügung. Es gibt keine Vorschriften dafür, in welcher Programmiersprache ein CGI-Programm geschrieben ist. Damit das Programm auf dem Server-Rechner ausführbar ist, muss es entweder für die Betriebssystem-Umgebung des Servers als ausführbares Programm kompiliert worden sein, oder es muss auf dem Server ein Laufzeit-Interpreter vorhanden sein, der das Programm ausführt. Wenn der Server zum Beispiel ein Unix-Rechner ist, führt er C-Programme aus, die mit einem Unix-C-Compiler zu einer ausführbaren Datei kompiliert wurden. Wenn der Server ein Windows-NT-Rechner ist, können CGI-Scripts auch EXE-Dateien sein, die mit 32-Bit-Compilern für C, Pascal, Visual Basic usw. erzeugt wurden. Die meisten heutigen CGI-Programme sind in der Unix-Shell-Sprache oder in Perl geschrieben. Die Unix-Shell-Sprache wird von allen Unix-Rechnern interpretiert. Für Perl muss ein entsprechender Interpreter installiert sein. Fragen Sie hierzu Ihren Provider. Das folgende Beispiel zeigt eine typische CGI-Situation, wie sie zum Beispiel für Suchdienste im WWW erforderlich ist. Abbildung 4.1: CGI Struktur In dem Beispiel kann der Anwender in einer angezeigten HTML-Datei in einem Formular Daten eingeben, zum Beispiel eine Suche in einer Datenbank formulieren. Nach dem Abschicken des Formulars an den Server-Rechner wird ein CGI-Programm aufge-

31 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 24 rufen. Das CGI-Programm setzt die vom Anwender eingegebenen Daten in eine Datenbankabfrage um. Wie das genau funktioniert, hängt von der Datenbank ab. Es gibt eine international standardisierte Datenbankabfragesprache, SQL, die hierbei sehr häufig zum Einsatz kommt. Die Datenbankanwendung liefert die Suchergebnisse an das aufrufende CGI-Programm zurück (oder schreibt sie in eine Datei, die das CGI-Programm dann auslesen kann). Das CGI-Programm erzeugt nun HTML-Code, wobei es die Suchergebnisse als Daten in den HTML-Code einbaut. Den HTML-Code sendet das CGI-Programm an den WWW-Browser, der die Suchabfrage gestartet hat. Am Bildschirm des Anwenders verschwindet die WWW-Seite mit dem Suchformular. Stattdessen erscheint eine neue Seite mit den Suchergebnissen, dynamisch generiert von dem CGI-Programm. Dies stellt die klassische Methode dar, einem Web Server Funktionalität hinzuzufügen. Vorteil dieser Methode ist die weite Verbreitung. Ein CGI ist generell auf allen Web Servern einer Plattform, die den Standard erfüllen, lauffähig. Da unter Windows NT aber fast ausschließlich der MS IIS zum Einsatz kommt, ist eine derartige Flexibilität nicht notwendig. Nachteil von CGI s ist, dass für jeden HTTP Request ein eigener Server Prozess gestartet werden muss. Das Erzeugen eines Prozesses ist für einen Web Server eine zeitaufwendige Prozedur. Aus diesem Grund schneiden CGI s in Performancevergleichen im Allgemeinen schlechter ab als ISAPI oder ASP Anwendungen [CT991]. Der größte Nachteil ergibt sich aber in mangelnden Möglichkeiten zum Debuggen der Anwendung während der Entwicklung. Man ist hier auf das Ausgeben von Text in Files angewiesen. Was die Entwicklungszeit drastisch erhöhen kann ISAPI (Internet Server Application Programming Interface) ISAPI ist eine Entwicklung von Microsoft, die den Nachteil von CGI s, immer neue Prozesse starten zu müssen, kompensieren will. ISAPI Anwendungen sind DLL s, mit standardisierten Interfaces zur Kommunikation mit dem MS IIS. Mit ISAPI startet der IIS jeweils nur einen neuen Thread für jeden Request. Das Erzeugen und Zerstören von Threads geht wesentlich schneller als das Starten von eigenen Prozessen. In der Praxis ergab sich ein Performancegewinn bei rechenintensiven Routinen bei mittlerer Serverlast von 600 %. Ein weiterer Vorteil von ISAPI ist die Möglichkeit des Debuggens. Man hat die Möglichkeit, gängige Compiler (Microsoft Visual C bzw. Borland Delphi 4.03) als Host Applikationen für die ISAPI Extentions zu definieren. Durch diese Einstellung wird bei einem http Request automatisch der Debugger der verwendeten Entwicklungsumgebung gestartet und man hat die Möglichkeit, den Source Code zu debuggen.

32 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 25 Kommunikation zwischen ISAPI Extentions und dem IIS Der Server erzeugt eine ECB Datenstruktur. In dieser Datenstruktur werden alle relevanten Daten, die zum Handling eines Requests notwendig sind, gespeichert. Das Erzeugen dieser Datenstruktur ist natürlich viel schneller als das Erzeugen eines eigenen Prozesses, dem man die Servervariablen, etc. über den Standardinput mitgibt. Für jeden HTTP Request wird nun, wie gesagt, kein eigener Prozess gestartet, sondern nur ein neuer Thread erzeugt, was viel schneller geht. Das Konzept birgt jedoch auch Gefahren. So kann eine abstürzende DLL den ganzen Server mit in die Tiefe reißen, da ja beide im selben Prozessraum laufen. Aus diesem Grund bietet der IIS die Möglichkeit, sogenannte Applications zu definieren. Applications sind in diesem Zusammenhang Gruppen von ISAPI DLL s oder SKRIPTS (werden weiter unten behandelt). Eine Gruppe von Dateien ist ein Verzeichnis. Also kann man jedes virtuelle Verzeichnis des IIS als Application definieren. Alle ISAPI DLL S, die unter diesem Verzeichnis liegen, gehören dann zu dieser Applikation. Die wichtigste Eigenschaft so eines Applikationsverzeichnisses ist Run in seperate memory Space. Dabei ist garantiert, dass eine unhandled Exception in einer ISAPI DLL nicht den gesamten Server zum Absturz bringt. So kann man durch Definieren mehrerer Application Directories die richtige Mischung aus Performance und Sicherheit (Serverstabilität) finden. Je mehr eigene Prozessräume man definiert, desto weniger beeinflussen sich die ISAPI DLL S. Umgekehrt müssen dann aber wiederum Prozesse erzeugt und terminiert werden, was Zeit kostet. Man hat nur dann die Möglichkeit über die Management Console alle Dll s einer Application zu terminieren, indem der Server die ISAPI DLL S unloaded (ISAPI Exit Function TerminateExtention ), wenn diese in einem eigenen Prozessraum laufen. Auch dieses wichtige Feature ist nicht über das Web Interface erreichbar, sondern nur über die Management Console. Das Problem beim Entwickeln einer ISAPI Extension ist nun aber das Debuggen. Während man beim Debuggen von simplen CGI Programmen noch über die Kommandozeile Tests durchführen kann, ist dies bei DLL s natürlich nicht möglich. Ein weiterer Vorteil beim Debuggen von CGI Programmen ist, dass wenn ein CGI Programm abstürzt, es zwar im Speicher hängen bleibt, der Server aber trotzdem ungehindert weiterläuft. Ungehindert ist deshalb nicht 100% richtig, da das hängengebliebene CGI Programm Speicher, und schlimmer noch, Rechenleistung in Anspruch nimmt. Man hat da aber immer noch die Möglichkeit, einige weitere Testläufe zu fahren, bis der Server komplett zu ist, um dann erst den Server neu zu starten bzw. mit dem MS Ressource Kit den Prozess zu killen. Bei einer ISAPI Extension muss man nach jedem fehlgeschlagenen Testlauf (die DLL hängt noch im Server Prozessraum) versuchen, den Server zu überreden, die DLL zu entladen. Nur wenn dies gelingt, kann man einen neuen

33 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 26 Compilerlauf starten und die alte DLL überschreiben, da sie sonst vom System als geöffnet erkannt wird und keine Schreibzugriffe auf diese Datei gestattet werden. Das Unloaden einer abgestürzten DLL funktioniert aber nicht immer, was bedeutet, dass man früher oder später um einen Reboot nicht umhinkommt. Das Laufzeitverhalten von ISAPI Anwendungen ist momentan das beste aller möglichen Techniken der Internetprogrammierung [Pro98]. Der Nachteil von ISAPI ist aber, analog zu CGI, dass keine klare Trennlinie zwischen User Interface (HTML Code) und der Funktionalität der Anwendungen möglich ist. Sollen größere Projekte zum Beispiel mehrsprachig entwickelt werden, so leidet die Wartbarkeit des entstandenen Codes erheblich ASP (Active Server Pages) ASP [MSO] schließlich ist eine Scriptsprache des IIS, die intern als ISAPI realisiert ist. Die direkte Programmierung einer ISAPI Extentions wird daher in der Regel immer schneller sein. Das UI wurde mit ASP programmiert. Die Programmierung mit Scripts bringt den Vorteil, dass das Layout der Anwendung später leichter geändert werden kann. Jedoch ist es mit ASP ab einer gewissen Komplexität nicht möglich, lesbaren Code zu schreiben. Versucht man z.b. zusätzlich zur Eingabeüberprüfung von HTML Formularen noch ein wenig Logik in die Scripts zu programmieren, so endet dieser Ansatz unweigerlich in Spaghetti Code [DevJ1]. Aus diesem Grund wurde jegliche Business Logik in COM+ Objekten realisiert. ASP bietet die Möglichkeit, sehr einfach und unkompliziert auf jegliche im System registrierten Objekte zuzugreifen. Aber auch der umgekehrte Ansatz etwas vom UI in die COM+ Objekte zu packen, birgt die Gefahr, dass Layoutänderungen später nur schwer und aufwendig zu realisieren sind [MSO2] [Bün00] [Buc00]. Aus diesem Grund war unbedingt darauf zu achten, hier eine exakte Trennlinie einzuhalten [Qui99] [Gam95]. 4.2 Business Layer Allgemein Scriptsprachen, wie JScript, sind aber nur bedingt dafür geeignet, komplexere Software zu erstellen. Hier hakt Microsoft ein und bietet weitere Software an, die den Entwickler hier unterstützen. Ein Ansatz, diesen Nachteil von Scriptsprachen zu umgehen, sind Three- Tier Applications. Gemeint ist, dass man ausgehend vom Zweischicht Modell (klassisches Client / Server), eine dritte Schicht zwischen Client und Server einzieht, die die sogenannte Business Logik beinhaltet.

34 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE Microsoft Transaktion Server Microsoft bietet für die Business Logic mit DCOM (Distributed Components Object Modell) auch gleich eine passende Technologie an. Man kann sogenannte DCOM Server entwickeln, die auf verschiedenen Rechnern liegen können. Diese DCOM Server übernehmen dann die Business Logik. DCOM Server sind quasi nicht sichtbare ActiveX Controls, die Methoden und Properties besitzen [Cha96]. Mit dem Option Pack wird auch der MS Transaktion Server (MTS) mit ausgeliefert. Dieser bildet eine Art Schutzhülle über DCOM Komponenten, die man entwickelt hat. Diese Schutzhülle beinhaltet eine Transaktionskontrolle auf Datenbankzugriffe, eine kompfortable Schnittstelle zur Userverwaltung von MS Windows NT, sowie eine Multi threading Umgebung. Der MTS sorgt dafür, dass man eine Komponente single threaded entwickeln kann, diese erscheint aber nach außen hin wie eine Multi Threaded Anwendung. Dies erlaubt kleine überschaubare Komponenten zu entwickeln, und diese dann z.b. mit JScript zu einer größeren Applikation zu verbinden. Der Einsatz von solchen kleinen überschaubaren Komponenten kann einem das Entwicklerleben sehr erleichtern COM+ Mit Windows 2000 wurde die MTS Technologie von COM Objekten neuerlich überarbeitet. COM+ wurde dafür ausgelegt, bestehende Investitionen in COM, MTS und andere COM-basierte Applikationen zu nutzen und möglichst leicht erweitern zu können. Es wird erstmalig in Windows 2000 enthalten sein. Auch in COM+ werden Dienste in Form von Komponenten verwaltet. Der Zugriff und die Kontrolle dieser werden hier komplett vom Server übernommen. Dazu wurde ein Interception -Mechanismus eingeführt. Im Unterschied zum einfachen COM, wo Server und Client auf demselben Rechner angesiedelt waren (Abbildung 4.2), ist es mit COM+ ohne weiteres möglich, Dienste auf anderen Rechnern zu nutzen. Früher wurde dies mittels Remote Procedure Call (RPC) gelöst. (Abbildung 4.3) Der MTS erweiterte dieses RPC- Prinzip um eigene Kontext-Wrapper auf der Serverseite, welche Sicherheitsüberprüfung übernahmen. (Abbildung 4.4) [DNJ100, Seite 55-56]. COM+ führt zur Sicherheitsüberprüfung sogenannte Policy-Objekte ein, wodurch die Kontext-Wrapper des MTS entfallen. Diese Policy-Objekte werden sowohl auf Client- als auch auf Serverseite plaziert, wo sie die bereits oben erwähnten Interceptions durchführen können. Wie das ganze dann schematisch aussieht, zeigt die Abbildung 4.5. Alle angebotenen Dienste müssen in COM+ als Applikation angemeldet werden. Es werden dabei 2 Arten von Applikationen unterschieden. Zum ersten wäre da die Serverapplikation, was bedeutet, dass die Komponente zur Laufzeit in einen vom Client getrenn-

35 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 28 Abbildung 4.2: Eine direkte Verbindung zu einem Objekt auf dem gleichen Computer, im gleichen Adressraum und Apartment wie der Client Abbildung 4.3: Eine indirekte Proxy/Stub-Verbindung zu einem Objekt, das an einem anderen Ort existiert ten Adressraum auf dem Server oder einem anderen beliebigen Rechner ausgeführt wird. (Abbildung 4.6) Die zweite Form ist die Bibliotheksapplikation, bei der die Komponente im Adressraum des Client ausgeführt wird.(abbildung 4.7) Wird von COM+ nun ein bestimmter Dienst angefordert, muss zunächst das entsprechende Objekt erstellt werden. Dazu wird zuerst geprüft, ob der geforderte Dienst überhaupt registriert ist. Hierzu wird der interne COM+ Katalog nach der gewünschten Komponente durchsucht. Wurde die Komponente gefunden, wird sie gemäß ihren Eigenschaften (Bibliotheks- oder Serverapplikation) gestartet. Danach kann der Interceptor eingerichtet werden. Anschließend wird auf der Clientseite ein Proxy inklusive eines RPC- Kanals eingerichtet. Zuletzt wird dem Client ein Zeiger auf den Proxy zurückgegeben. Für das Beenden einer Applikation ist der Server verantwortlich; das Verhalten kann vom Administrator eingestellt werden (z.b.: App. niemals beenden, App. nach xx Minuten beenden, usw.). Hier noch ein paar Bemerkungen zum oben erwähnten COM+ Katalog. Der Katalog stellt eine Systemdatenbank dar, in welcher alle registrierten Applikationen mit ihren Komponenten gespeichert werden können. Arbeiten kann man mit diesem Katalog über sogenannte Dienstobjekte, welche unter anderem auch Skriptverarbeitung anbieten. Zugriff auf die oberste Ebene des Kataloges bekommt man durch die Verwendung der Komponente COMAdmin (ist in COM+ enthalten).

36 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 29 Abbildung 4.4: Ein Kontext-Wrapper als eine separate Schicht im Microsoft Transaction Server Abbildung 4.5: Interception durch Policy-Objekte Zuletzt noch ein paar Worte zur Sicherheit in COM+. Früher war die Erstellung von guten Sicherheitscode schwierig und teuer. Heute kann man diese Aufgabe voll und ganz COM+ überlassen, es kann die Sicherheitsinfrastruktur ererbt werden. Zu den angebotenen Diensten zählen die Authentifizierung und die Autorisierung. Die Authentifizierung wird vom Security Support Provider (SSP) im Betriebssystem bereitgestellt. Er stellt dazu verschiedene Authentifizierungsebenen bereit, die angeben, wie umfangreich das Sicherheitssystem arbeiten soll. Auf die einzelnen Ebenen soll an dieser Stelle nicht weiter eingegangen werden. Die Autorisierung ist natürlich abhängig von der Authentifizierungsebene. Ist sie beispielsweise auf NONE eingestellt, entfällt die Autorisierung komplett. Die Autorisierung selbst wird über sogenannte Rollen abgewickelt, wobei Rollen anwendungsbezogene Benutzergruppen sind. Die neue Bezeichnung derartiger Objekte lautet nun COM+. Die herausragende Neuerung von COM+ ist, die Tatsache COM Objekte kontektbezogen zu entwickeln. Das bedeutet, dass sich ein COM Objekt bei entsprechender Implementierung je nach aufrufender Applikation anders verhalten. Das Objekt verändert also sein Verhalten, wenn es z.b. über

37 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 30 Abbildung 4.6: Eine Serverapplikation, die in einem separaten Adressraum ausgeführt wird Abbildung 4.7: Eine Bibliotheksapplikation, die im Adressraum der Clientanwendung ausgeführt wird den IIS aus dem Internet aufgerufen wird. Wird es von VBA aus Microsoft Excel aufgerufen, dann können andere Eigenschaften des Objektes zum Vorschein kommen. 4.3 Datenbank ADO Ob Veranstaltungskalender, Produktkatalog, Mitgliederdatenbank, Gästebuch, personalisierte Dienste oder allgemein veränderliche Daten - all dies läßt sich mit Hilfe der Kombination ASP Skripts auf der Webserver Seite und einer Datenbank auf der anderen Seite verwirklichen. Betrachten wir einmal das Bindeglied zwischen diesen beiden Technologien näher. Von ASP aus greift man am einfachsten über ADO (ActiveX Data Objects) und das zugehörige ADODB Objekt auf Datenquellen zu. Die Verbindung zwischen ADO (und der darunterliegenden OLE DB, Object Linking and Embedding Database) und der Datenbank wird meist über ODBC (Open DataBase Connectivity) hergestellt, das Applikationen einen weitgehend einheitlichen Zugriff auf verschiedenste Datenquellen erlaubt [Kol00] [MSO2]. ADO stellt die Objekte zur Verfügung, mit deren Hilfe ein ASP Skript eine Verbindung zur Datenbank aufbauen und Daten auf vielfältigste Weise manipulieren kann.

38 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 31 Die wichtigsten ADO Objekte sind: Connection (Datenbankverbindung) - Repräsentiert die Verbindung zur Datenquelle. Recordset (Sammlung von Datensätzen) - Besteht aus den Datensätzen die aus einer Datenbankabfrage stammen und dem zugehörigen Cursor, der auf den aktuellen Datensatz zeigt. Field (Datenfeld) - Enthält Daten einer Datenbankspalte und Informationen über diese Daten wie Datentyp, Datenlänge und Ähnliches. Das Recordset Objekt stellt dabei die Fields Collection zur Verfügung, die alle Field Objekte eines Datensatzes beinhaltet. Property (Eigenschaft) - Erlaubt den Zugriff auf dynamische Informationen eines ADO Objektes, die von der Datenquelle oder der Datenanbindung (wie ODBC) zur Verfügung gestellt werden. Error (Fehler) - Enthält ausführliche Fehlerinformationen bei Datenbankzugriffen. Auf alle Fehler eines Datenbankzugriffes kann durch die Errors Collection zugegriffen werden. Command (Befehl) - Erlaubt es, einzelne Datenbankabfragen zu definieren, sodass ein mehrmaliger Einsatz mit verschiedenen Parametern rascher durchgeführt werden kann. Parameter (Parameter) - Stellt einen einzelnen Parameter (Argument) eines Command Objektes für eine parametrisierte Abfrage oder einen Zugriff auf eine Gespeicherte Datenbankprozedur dar. Wie sieht nun eine einfache Datenbankabfrage aus? Das folgende ASP Skript öffnet eine Verbindung zur Nordwind Datenbank, die mit Microsoft Access 97/2000 und SQL Server 7.0 (deutsche Versionen) ausgeliefert wird. Weiters liest es die Datensätze der Tabelle Artikel aus, die in die Kategorie Meeresfrüchte fallen, um die Werte der Spalten Artikel- Nr und Artikelname schließlich im Browser anzuzeigen. <% Response.Expires=0 Response.AddHeader Pragma, no-cache Response.AddHeader cache-control, no-store Response.Write Abfrageergebnis:<br> & vbcrlf Set conn = Server.CreateObject( ADODB.Connection )

39 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 32 conn.open DSN=NW;USR=sa;PWD= strsql = SELECT Artikel.[Artikel-Nr], Artikel.Artikelname strsql = strsql & FROM Artikel INNER JOIN Kategorien strsql = strsql & ON Artikel.[Kategorie-Nr]=Kategorien.[Kategorie-Nr] strsql = strsql & WHERE Kategorien.Kategoriename = Meeresfrüchte Set rs = conn.execute(strsql) Do While Not(rs.EOF) Response.Write & rs( Artikel-Nr ) & : Response.Write & rs( Artikelname ) & <BR> & vbcrlf rs.movenext Loop rs.close conn.close %> Microsoft SQL Server 7.0 Für die Entwicklung des Datenbank Back end s wurde MSDE gewählt. MSDE ist im MS Office 2000 Paket enthalten und bietet SQL Kompatibilität zum MS SQL Server 7.0. Außerdem benötigt die MSDE weniger Hardwaressourcen, was ebenfalls ein Kostenfaktor ist. Aufgrund der 100% Kompatibilität zum MS SQL Server 7.0 lässt sich das System leicht durch einen einfachen Upgrade der Datenbankengine skalieren. Bei der Entwicklung wurde darauf geachtet, möglichst wenig herstellerspezifische SQL Statements zu verwenden. Dies sollte es leicht möglich machen, gegebenenfalls gegen einen anderen SQL Server zu fahren. Durch die Verwendung von ADO 2.1 ist es aber auch leicht möglich, die Software dahingehend zu ändern, dass gegen jede relationale Datenbank (SQL) gefahren werden kann. Bei der Verwendung von Windows 2000 als Betriebssystem kommt ADO 2.5 zur Anwendung. 4.4 Perfomance Vergleich ISAPI wurde eingeführt, um CGI Programme zu beschleunigen. Die Frage ist nun, wie es mit der Performance im Vergleich mit ASP steht. Als erstes, weil dies ein Kernbereich der Untersuchungen darstellt, wurde der Zugriff auf eine Tabelle einer Relationalen Datenbank getestet.

40 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 33 Task ASP ISAPI Default Einstellungen 9sec 20sec Isolated Process* 22sec 21sec Buffer ASP Pages** 6sec - Tabelle 4.1: Ergebnisse Test Testumgebung AMD K MB Ram NT Server+Optionpack installiert (IIS 4.0) MS SQL Server Server installiert MS Office 97 installiert 10BaseT Netzwerk (PCI Netzwerkkarten) Test 1 Zugriff auf eine Tabelle in einer Accessdatenbank. Access wurde gewählt, da die JET Engine Ressourcen schonender als der MS SQL Server ist. Die Testkandidaten sollten einfach die Felder aus der Access Tabelle in eine HTML Tabelle schreiben. Folgendes Script musste gegen eine entsprechende ISAPI Extension antreten. Die ISAPI Extention wurde mit Borland Delphi 4.0 entwickelt. Ergebnisse von Test 1 Tabelle enthält ca Datensätze. Es wurde mit einer Stoppuhr die Zeit, in der sich die Fortschrittsanzeige (Balken in der Statusleiste) der Browser bewegt, gemessen. Außerdem wurde die Abfrage zuvor einmal ohne Messung gestartet, um dem Server internes Caching (welcher Art auch immer) zu ermöglichen. * Option Run in Seperated Space wurde aktiviert. ** Option Buffering ASP Pages wurde aktiviert. Bedeutet, dass das Senden einer ASP solange vom Server verzögert wird, bis sie fertig aufgebaut ist. Andernfalls würde sie Zeile für Zeile abgearbeitet und Zeile für Zeile verschickt werden.

41 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 34 Task ASP ISAPI Buffer ASP Pages 10sec Absturz Tabelle 4.2: Ergebnisse Test Test 2 Identisch mit Test1, nur dass zusätzlich noch eine kleine Berechnung aus den Daten der selben Tabelle gefordert war. Berechnung : ((ors(2)/3.3) (ors(2)/3.7))/(12/2.3) Anmerkung: Bei einem Testlauf dieser ISAPI Extention war der Server abgestürzt. Laut Taskmanager: Prozessorauslastung 0 Dabei konnte der IIS nur durch ein Reboot der gesamten NT Maschine wieder zum Leben erweckt werden. Der Server lieferte bei allen folgenden Requests nichts mehr zurück (TimeOut) Test 3 Neben dem Datenbankzugriff sollte nun auch die reine Ausführungsgeschwindigkeit gemessen werden. Zu diesem Zweck wurde folgendes Script getestet: Hierzu benötigte der IIS 5 Sekunden. Als Gegner musste wieder eine ISAPI DLL ins Rennen. Diese brachte das Ergebnis ohne merkliche Verzögerung in den Browser. Da die Ergebnisse handgestoppt wurden, kann bei einer derartigen kurzen Messdauer keine präzise Zeit genannt werden, da der Seitenaufbau immer weniger als eine Sekunde benötigte. 4.5 Schlußfolgerungen rent@trainer verwendet nun die Kombination ASP, COM+ und Microsofts SQL Server. Die Entwicklung von Web Anwendungen mittels CGI oder ISAPI hat den großen Nachteil, das die Trennung von Präsentation und Funktionalität nicht gegeben ist. Es bestünde zwar die Möglichkeit, mittels Dokumentvorlagen eine Trennlinie einzufügen, diese kann in der Praxis, wie die Erfahrung zeigt, aber nicht eingehalten werden. Beispielsweise muss man in der Anwendung eine HTML-Auswahlbox mit Elementen aus der Datenbank füllen. Der Code für die Auswahlbox kann dabei nur in im CGI bzw. ISAPI Code liegen, womit man die Seperation von Präsentation und Funktionalität schon aufgegeben hat. Die Verwendung von Scriptsprachen löst obiges Problem. Jedoch bekommt man bei der Verwendung von ASP bei größeren Projekten das Problem, dass der Code schnell unüber-

42 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 35 sichtlich wird. Dies liegt darin begündet, dass ASP Objektorientiertheit nur ansatzweise bietet. Sehr schnell entwickelt sich das Script zu Spagetti Code. Aus diesem Grund wurde folgende Vorgangsweise gewählt: Für die Präsentation der Daten wird ASP verwendet. ASP greift nun nicht direkt auf die Datenbank zu, sondern auf COM+ Objekte. Diese enthalten die gesamte Business Logic der Anwendung und stellen auch die Verbindung zur Datenbank her. Die COM+ Objekte sind in Borlands Delphi implementiert. 4.6 Entwicklungstools Die MTS Objekte wurden mit Borland Delphi 4.03 entwickelt [Kos991] [Kos992]. Bereits im späten Entwicklungsprozess, wo versucht wurde die Anwendung nach Windows 2000 zu portieren, musste festgestellt werden, dass mit Borland Delphi 4.03 unter Windows NT 4.0 entwickelte Objekt unter Windows 2000 nicht mehr funktionieren. Die kompilierten Object Interfaces wurden von den verschiedenen Betriebssystemen nicht mehr verstanden. Aus diesem Grund war eine Neukompilation des gesamten Source Codes auf der neuen Plattform notwendig. Da dieses Verhalten von Microsoft nicht dokumentiert ist, wird angenommen, dass sich Borland Delphi 4.03 hier nicht 100% korrekten Compilate liefert [...]. Die ASP und HTML Seiten wurden mit Macromedia Dreamweaver 2.0 erstellt. Die erstellten Images kamen von einer Drittfirma. Die ASP Tags selber wurden mit einem gewöhnlichem Texteditor, der HTML Syntaxhighlithing beherrscht, erstellt. Die Wahl fiel hier auf das Shareware Programm UltraEdit32 v6.20b.

43 Kapitel 5 Software Design 5.1 Allgemein Da die Software eine Web-Applikation ist, geht das Design von einer Client / Server Architektur aus. Den Client stellt ein HTML Browser. Die bekanntesten und am weitesten verbreiteten Vertreter sind Microsoft s Internet Explorer und Netscape s Communicator. Bei der Entwicklung von einer Web-Applikation ist, wie bei der Entwicklung aller Anwendungen, darauf zu achten, die Presentation Layer streng von der Data Source Layer zu trennen. Diese Forderung wird im Allgemeinen von Scriptsprachen, wie ASP eine ist, nicht erfüllt. Eine zukünftige Alternative, die bereits Einzug in die neuesten Implementationen gehalten hat ist XML. XML verspricht die Möglichkeit, Daten und Präsentation derselben trennen zu können. Ein anderer Ansatz, der auch in dieser Arbeit angewandt wurde, ist das Einziehen einer dritten Schicht auf dem Server. Diese Schicht wird Application Layer oder Business Layer genannt. Die Aufgabe dieser Schicht ist das Bereitstellen von Funktionen, die nicht direkt von der Datenbank geliefert werden, aber von der Präsentationsschicht benötigt werden. In diese Schicht werden alle Algorithmen, die von der Applikation verwendet werden, gepackt. Ein Beispiel dafür ist der Algorithmus zum Auswahl eines Trainers. Die klassische Client/Server Architektur wird zur Multi Tier-, oder Three Tier Architektur. Um die Entwicklung der Application Layer möglichst effektiv zu gestallten, bieten verschiedene Hersteller Produkte her, die Transaktionen, Sicherheitsaspekte und Performanceaspekte, wie Load Balancing unterstützen. Eines dieser Produkte ist der in Windows NT und Windows 2000 integrierte Transaction Server. Soll die Applikation nicht auf einem Windows basierendem Server, sondern auf einem 36

44 KAPITEL 5. SOFTWARE DESIGN 37 Unix Derivat laufen, so sind die Produkte von Borland (Borland Application Server) oder Sun (Sun Java Application Server) in Betracht zu ziehen. Einen weiteren interessanten, vielversprechenden Ansatz bietet Hyperwave. Hyperwave bietet mit seiner objektorientierten Datenbank und der damit verbundenen objektorientierten Scriptsprache, die an JavaScript angelehnt ist, die Möglichkeit auch große Projekte durchgehend in Scriptsprachen zu entwickeln, ohne die Probleme der Unübersichtlichkeit von ASP Code zu haben. 5.2 Business Logic Objekt Relationen Es folgen Diagramme über die Beziehungen der ASP Scripts mit den COM+ Objekten (Abb 5.1 und Abb 5.2). Man sieht, dass versucht wurde, eine strenge Trennung der einzelnen Layers zu erhalten. Die COM+ Objekte stellen konsequent die mittlere Schicht zwischen User Interface und Datenbank dar. Eine genaue Beschreibung der Methoden der einzelnen Objekte findet sich im Anhang D OFFER.DLL - Details Motivation Das zentrale Objekt dieser Arbeit stellt TOffer im File OFFER.DLL dar. Sie enthält die Implementierung für die Auswahl der Trainer. Unter Kapitel 3 war die Komplexität untersucht worden. Es wird nun gezeigt, wie man durch Ausnutzen maschinenspezifischer Eigenschaften, die Performance erhöhen kann. Schnelle Berechnung der Verfügbarkeit Es wird ein Matrix erstellt, wobei die Spalten die Tage und die Zeilen die Personen darstellen. Es wird von dem angegebenen Startdatum stadat ausgegangen. Der Spaltenindex i gibt den Tag relativ zum Startdatum an. Alle Einträge werden zu diesem Startdatum genormt. Das bedeutet, dass eine Spalte bei allen Personen dem selben Tag entspricht. Für die Abstraktion eines Tages wählt man einen Ganzzahlwert, dessen Bits Teile eines Tages darstellen. Mit einer 24 Bitzahl kann man einen Tag Stundengenau auflösen. Die Implementierung von rent@trainer verwendet einen 64 Bit Integer Typ. Das erlaubt eine Auflösung von 30 Minuten, da von den 64 Bit momentan nur 48 genutzt werden. Eine Auf-

45 KAPITEL 5. SOFTWARE DESIGN 38 lösung von 30 Minuten erscheint noch recht grob, da aber bei Kurse nur ganze Vielfache von Stunden dauern und nur zur jeweils halben oder vollen Stunde anfangen, genügt eine Auflösung von 30 Minuten. Das Verwenden von 64 Bit Ganzzahlen hat zudem den Vorteil gegenüber komplexen Datenstrukturen, dass Operationen auf diesen Zahlen direkt von einem modernen Prozessor ausgeführt werden können. Damit beschränken sich Vergleiche zwischen zwei Personen auf binäre UND Operationen, welche vom Prozessor sehr schnell ausgeführt werden können. Von allen potentiellen Personen werden alle Kalendereinträge, die die Verfügbarkeit repräsentieren, aus der Datenbank gelesen. Jeder Tag wird in einem 64Bit Ganzzahlwert gespeichert. Jedes Bit entspricht einer halben Stunde. Somit werden von den 64Bit 48Bit effektiv genutzt. Für jede Person ergibt sich dadurch ein Array von 64 Bit Ganzzahlen. Die Länge des Arrays m ergibt sich aus der Anzahl der Tage, für die Verfügbarkeit gesucht wird. In der konkreten Implementation von rent@trainer wäre m=60. Man erhält also eine Matrix M der Größe p*m. Wo die Zeilen den Tagen und Spalten den Personen entsprechen. Es wird eine Schablone für einen Tag erstellt. Diese Schablone ist eine 64 Bit Zahl wo für jede benötigte halbe Stunde eine binäre 1 steht. Würde man Trainer von 8:00 Uhr bis 12:00 Uhr benötigen, ergäbe sich eine Zahl von Binär = FF0000 = Ob zwei Trainer j1, j2 am Tag i von 8:00 Uhr bis 12:00 Uhr Zeit haben, ergibt sich wie folgt: if (M[i,j1] AND M[i,j2] AND FF0000 = FF0000) then begin j1 and j2 have time end; Resultat Als Resultat dieser Berechnungen erhält man eine Liste aller potentiellen Trainer, die alle geforderten Ansprüche erfüllen. Trainer, die diese Mindestanforderungen nicht erfüllen, sind ausgeschieden. Zusätzlich sind die ausgewählten Trainer nach ihrem Ranking sortiert. Der beste Trainer steht am Beginn der Liste. Nachdem die Fähigkeiten aller Trainer untersucht wurde, muss nun ein möglicher Termin für einen Kurs gefunden werden. Die Komplexität für die Berechnung der Fähigkeiten (Gl. 3.2) liegt unter der, die für die Berechnung der Verfügbarkeit (Gl. 2.4). Aus diesem Grund werden zuerst die Fähigkeiten errechnet, um so die Komplexität für die Berechnung der Termine zu minimieren.

46 KAPITEL 5. SOFTWARE DESIGN 39 Würde durch obiges Verfahren 2/3 der Trainer eliminiert werden, so ergibt sich für die Gesamtkomplexität folgender Wert. m = 5 (Kursdauer), n = 100 (Anzahl der Kalendereinträge), p = 21 (Periode innerhalb der Kurs stattfinden muss, t = 100 (Anzahl der Trainer), k = 3 (Benötigte Trainer), b = 25 (Anzahl Bewertungen für einen Trainer), B = 2500 (Anzahl aller Bewertungen im System) Geht man davon aus, dass eine elementare Operation (Kalenderzugriff, Vergleich, etc) 10 6 s benötigt, dann käme man nach Gl. 2.4 und Gl. 3.2 auf T = 13Minuten Dies entspricht einer Zeitersparnis von 2700 %. Wählt man die Parameter so, dass nur mehr 10 Trainer übrigbleiben, dann kommt man auf nach der genannen Formel auf: T = 12sec Die Berechnungsvorschrift findet sich in Anhang C.

47 KAPITEL 5. SOFTWARE DESIGN 40 [h][ht] editanswer.asp courselist.asp TMisc Datenbank registration.asp courseinfo.asp TMisc bookingform.asp TCustomer Datenbank default.asp TCustomer editcustomer.asp Datenbank TTrainer feedbackanswer.asp TCustomer Datenbank TOrder feedback.asp Datenbank TOrder order.asp TMessenger Mail / SMS Datenbank TCustomer registrationanswer.asp TSecurity TMessenger Mail / SMS Datenbank Abbildung 5.1: Objekt Relationen Teil 1

48 KAPITEL 5. SOFTWARE DESIGN 41 [h][ht] TCustomer Datenbank editanswer.asp TMessanger Mail / SMS TOffer offer.asp TBooking Datenbank TOffer orderverification.asp Datenbank newterminasnwer.asp calendar.asp TCalendar Datenbank newavailable.aspnewtermin.asp editanswer.asp edittrainer.asp TTrainer Datenbank wantercourseanswer.asp education.asp Abbildung 5.2: Objekt Relationen Teil 2

49 Kapitel 6 Die Datenbank von rent@trainer 6.1 Erläuterungen Die Datenbank basiert im Prinzip auf drei Säulen: Den Trainern (Tabelle HUMANRE- SOURCE), den angebotenen Kursen (Tabelle COURSE) und den Kunden (Tabelle CU- STOMER). Diese Tabellen sind mit verschiedenen Untertabellen verknüpft. Die Untertabellen ergaben sich durch die Erstellung der 3. Normalform der Datenstruktur [Dat98] Besonderheiten: Normalerweise werden als Identity Felder Autoincrement Integer Felder verwendet. Bei einigen Fällen wird jedoch darauf verzichtet und stattdessen das Primärschlüsselfeld mit speziellen Funktionen versehen Tabelle PLZ Hier ist das Primärschlüsselfeld die Postleitzahl. Die Verknüpfungen mit PLZ sind in der derzeitigen Version nicht mit referentieller Integrität realisiert. Es kann nämlich sein, dass ein User eine Postleitzahl und einen Ort eingibt, der noch nicht in der Datenbank gespeichert ist. Sollte dies der Fall sein, so darf dieser User nicht abgewiesen werden, sondern die angegebenen Daten müssen in die Datenbank übernommen werden. In der Tabelle PLZ werden noch Längengrad und Breitengrad der Orte gespeichert. Mit diesen Informationen wird mittels Pythagoras die Entfernung zwischen zwei Orten ermittelt, aus der dann die Fahrtkosten errechnet werden. Da diese Entfernung nur die Luftlinie darstellt, kann sie natürlich nicht ganz übereinstimmen. Aus diesem Grund wird die ermittelte Luftlinie mit dem Faktor 1.2 multipliziert, um auf eine reale Straßenentfernung zu kommen. 42

50 KAPITEL 6. DIE DATENBANK VON 43 Abbildung 6.1: Datenbankstruktur

51 KAPITEL 6. DIE DATENBANK VON 44 Leider war es zur Entwicklungszeit nicht möglich, einen Routenplaner zu organisieren, der über ein API, die wirkliche Entfernung zwischen zwei Orten einer anderen Applikation zur Verfügung stellt. Alle erhältlichen Routenplaner verlangen eine händische Eingabe der Orte Tabelle COURSEBEGINTIME Das Primärschlüsselfeld gibt hier die Zeit in Minuten an. Dieses Format wurde deshalb verwendet, um im Integer Bereich bleiben zu können. Ein Datumsfeld wird ja intern von der Datenbank als FLOAT Typ gespeichert. Diese Tabelle wird benötigt um die Kursbeginnzeiten für den Kunden einzuschränken. Würde man hier dem Kunden freie Hand lassen, so wäre im Allgemeinen nicht möglich, für einen Trainer zwei Halbtageskurse an einem Tag zu halten. Bucht der Kunde zum Beispiel um 11:00 Uhr einen 4-Stunden Kurs, so geht sich weder davor noch danach ein Kurs für dentrainer aus. Aus diesem Grund bietet man dem Kunden nur bestimmte Beginnzeiten an. Aus ähnlichem Grund wie bei den Beginnzeiten von Kursen möchte man nur definierte Dauern von Kursen anbieten (4h, 1 Tag oder 2 Tage, etc.). Alle möglichen Dauern von Kursen werden in der Tabelle COUR- SEDURATION gespeichert. Auch die Tabelle COURSEDURATION besitzt ein spezielles Primärschlüsselfeld. Dieses ist wie folgt definiert. Coursedurationid := Anzahl Tage * Anzahl Stunden/Tag. Anzahl Tage := coursedurationid div 100 Anzahl Stunden := coursedurationid mod 100 Es liegt in der Verantwortung des Administrators hier sinnvolle Werte einzutragen. Es wird hier seitens der Datenbank keine Plausibiltätskontrolle durchgeführt. Dies ist insofern zu beachten, als dass ein fehlerhaftes Schlüsselfeld nicht visualisiert wird. Das bedeutet, dass das Programm hier einfach falsch rechnet. Als eigenständigen Teil muss man auch die Login Tabellen betrachten. Diese haben mit der eigentlichen Verwaltung der Trainer und Kunden nichts zu tun. Sie dienen lediglich dem Web Interface als Informationen über die Zugriffsberechtigungen der User. Die Login Tabellen lauten wie folg: LOGIN LOGINGROUP LOGINHRMAPPING LOGINCUSTOMERMAPPING LOG

52 KAPITEL 6. DIE DATENBANK VON 45 Die Tabelle LOGIN enthält die eigentlichen Zugangsdaten. Die Tabelle LOGINGROUP speichert lediglich die verschiedenen Benutzergruppen, die auf das System Zugriff haben. In der derzeitigen Implementierung sind dies nur Trainer und Kunde. Zu beachten ist, dass die ID Werte der Zeilen Trainer und Kunde in der Tabelle LOGINGROUP vom System reserviert sind. Trainer wird eine 1 zugeordnet; Kunde eine 2. Diese ID Werte werden vom Web Server dazu verwendet, um schnell unterscheiden zu können, ob ein gerade eingeloggter User ein Kunde oder ein Trainer ist. Die Tabelle LOG zeichnet alle Logins auf. Mit dieser Tabelle ist es später möglich, eine statistische Auswertung des Userverhaltens vorzunehmen.

53 Kapitel 7 System Requirements 7.1 Hardware Intel Pentium PC oder kompatibel. 64 MB Ram (Generell gilt je mehr Speicher, desto besser. Empfohlen werden min. 128 MB) 1 GB Festplatte Die Datenbank, die COM Objekte, und die HTML Templates nehmen zusammen ca. 10 MB Festplattenspeicher in Anspruch. Sollte die Datenbank schnell wachsen, so ist hier generell mehr Speicherplatz gefordert. 7.2 Software Requirements Microsoft Windows NT Service Pack3 mit Microsoft Option Pack 4.0 (IIS 4.0) Alternativ dazu kann auch Microsoft Windows 2000 verwendet werden. Microsoft SQL Server 7.0 oder die dazu kompatible MSDE. 46

54 Kapitel 8 Installation von rent@trainer Bevor mit der eigentlichen Installation begonnen werden kann, muss gewährleistet sein, dass obige Systemvoraussetzungen erfüllt sind. 1. Das selbstentpackende Archiv hrsetup.exe ausführen. Als Zielordner wird der Ordner angegeben, der später auch als Web Verzeichnis fungieren soll. 2. Die entpackte Datei humanresource.adp mit MS Access 2000 starten. Dann die MSDE Datenbank wiederherstellen [MSACC1]. Die Datei der Sicherungskopie heißt humanresource.dat. 3. In der Microsoft Management Console (MMC) ist ein neues Packages zu erstellen. Die MMC ermöglicht dabei den Import bereits bestehender Packages. Beim Importieren muss das Exportfile hr.pak angegeben werden, welches ebenfalls entpackt wurde. 4. Schließlich sind noch alle entsprechenden Zugriffsrechte für die Verzeichnisse zu setzen, damit die Anwendung ihren Dienst aufnehmen kann. 5. Der Web folder, in den man alle ASP Files kopiert hat, muss als Applikation definiert werden. Dies geschieht ebenfalls in der MMC. 6. Zum Schluss müssen noch alle Parameter für die Anwendung gesetzt werden. Dazu wird auf die Kapitel Datenbankstruktur und Businesslogik verwiesen. 47

55 Kapitel 9 Bedienung der Web Site 9.1 Allgemein Die Web Site gliedert sich in drei Abschnitte Public Area (Abbildung 9.1), Trainer Area (Abbildung 9.2) und Customer Area (Abbildung 9.3). Die Public Area verschafft einen groben Überblick über die Möglichkeiten und Angebote von rentatrainer. Die Trainer Area bietet spezifische Funktionen für die Trainer an. Die Customer Area bietet dem Kunden die Möglichkeit, die Angebote von rentatrainer auch interaktiv zu nutzen. Die Navigation innerhalb der Site findet durchgehend am linken Bildschirmrand statt. Diese Bedienung wird konsistent in allen Areas eingehalten. Die verschiedenen Areas unterscheiden sich erkennbar in der Farbe der Navigationsleiste. Die Public Area ist durchgehend in Blautönen gehalten, die Trainer Area in Rot- und die Customer Area in Gelbtönen. Dies soll dem User eine intuitive Navigation ermöglichen. 9.2 Public Area Die Public Area dient als zentrale Informationsstelle für rentatrainer. Hier findet man allgemeine Informationen zu rentatrainer. Außerdem wird man über Bedingungen und etwaige Einschränkungen dieses Dienstes informiert. Außerdem war von der Firma SILVA geplant ständig akutelle News auf der Startseite zu präsentieren. Um das Angebot von rentatrainer nutzen zu können, ist eine einmalige Registrierung in die Datenbank notwendig. Dies gilt sowohl für Trainer als auch für Kunden. Die Registrierung soll in beiden Fällen kostenlos sein. Für Trainer ist eine Registrierung sowieso selbstverständlich. Von Kunden wird eine Registrierung gefordert, damit eine Überprüfung der Identität vorgenommen werden kann. Da ein Kunde direkt Trainer buchen kann und diese Trainer damit für den gewählten Termin für andere Kunden nicht verfügbar sind, 48

56 KAPITEL 9. BEDIENUNG DER WEB SITE 49 Abbildung 9.1: Public Area

57 KAPITEL 9. BEDIENUNG DER WEB SITE 50 Abbildung 9.2: Trainer Area

58 KAPITEL 9. BEDIENUNG DER WEB SITE 51 Abbildung 9.3: Trainer Area

59 KAPITEL 9. BEDIENUNG DER WEB SITE 52 Abbildung 9.4: Startseite muss ein Missbrauch des Dienstes weitgehend verhindert werden. Da der Einsatzzweck von rentatrainer kurzfristig gebuchte Schulungen sind, soll davon abgesehen werden, im Buchungsvorgang selbst eine Identitätsüberprüfung einzubauen. Eine derartige Überprüfung würde den Buchungsvorgang ausbremsen, was der prompten Erledigung von Buchungen widersprechen würde. Zur Registrierung stehen zwei Buttons zur Verfügung. Einer für Trainer, sowie einer für Kunden. Das Registrieren erschöpft sich im Ausfüllen eines Formulars. Bei erfolgter Registrierung erhält der User seine Zugangsdaten direkt per zugesandt. Die Korrektheit der Adresse genügt also in der derzeitigen Implementierung für die Überprüfung der Identität. Sollen weitere Überprüfungen stattfinden, so sind diese manuell von rentatrainer durchzuführen. Registriert sich ein Trainer, so erhält dieser zwar Zugang zu der Trainer Area, kann jedoch a priori noch nicht gebucht werden. Seine Kurswünsche müssen erst vom Personalchef verifiziert werden. Dieser erhält bei jeder Änderung von Kurswünschen eine , sodass er die Änderungen verfolgen kann. Trägt ein Trainer einen Kurswunsch ein, so wird das Feld Knowledgefaktor in der Tabelle ABILITY standardmäßig auf 0 gesetzt. Der Personalchef muss, damit der Trainer auch gebucht werden kann, diesen Wert auf einen Wert größer als MinKnowledgefactor einstellen (Minknowledgefactor wird im Script Offer.asp eingestellt).

60 KAPITEL 9. BEDIENUNG DER WEB SITE 53 Abbildung 9.5: Kunden Registrierung Abbildung 9.6: Trainer Registrierung

61 KAPITEL 9. BEDIENUNG DER WEB SITE 54 Nach erfolgter Registrierung kann sich der User nach Erhalt der Zugangsdaten per e- mail einloggen. Zu diesem Zweck stehen zwei Buttons zur Verfügung: Ein Login - Button für die Trainer Area, der zweiter für die Customer Area. Diese Aufteilung hat lediglich optischen Charakter. Man kommt von jedem Login- Dialog mit den entsprechenden Zugangsdaten zu beiden Areas. Abbildung 9.7: Buchungsformular Um zu verhindern, dass sich ein User zweimal registriert, kann sich ein User pro Sitzung nur einmal registrieren. Eine erneute Registrierung ist nur dann möglich, wenn der Internet Browser beendet und wieder gestartet wird. Durch diese Maßnahme wird auch verhindert, dass durch ein Reload einer Seite eine erneute Registrierung vorgenommen wird. Es wurde vereinbart, dass aus Sicherheitsgründen bereits existente Namen nicht abgewiesen werden. Dies würde Dritten die Möglichkeit bieten, zu erfahren, wer bei rentatrainer bereits registriert ist. 9.3 Trainer Area Gibt man gültige Login Daten eines Trainers ein, so gelangt man zur Startseite für Trainer. Auf dieser Seite sieht der Trainer alle Buchungen, für die er eingeteilt ist. Von dieser Seite aus kommt der Trainer auf verschiedene weitere Seiten, auf denen er verschiedene

62 KAPITEL 9. BEDIENUNG DER WEB SITE 55 Einstellungen treffen kann Ändern der persönlichen Daten Ändert sich zum Beispiel die Anschrift des Trainers, so kann er über diese Seite seine Daten ändern. Die Daten werden nach erfolgter Bestätigung sofort in die Datenbank übernommen. D.h. der Trainer trägt die volle Verantwortung über seine Eingaben. Diese sollten daher stehts überprüft werden Eintragen von Kurswünschen Auf dieser Seite kann der Trainer alle Kurse und Sprachen eintragen, die er unterrichten will. Wie eingangs erwähnt, sollen sich komplexere Fähigkeiten aus mehreren Fähigkeiten zusammensetzen. Bei sind dies Fachkenntnisse über den zu unterrichtenden Stoff und die Kenntnis der Sprachen. Aber genau stellt eine Ausnahme dar. Da alle Trainer aus dem deutschsprachigen Raum kommen, werden vollkommen perfekte Sprachkenntnisse nicht angenommen. Vielmehr verlangen Kurse im IT Bereich spezielles Fachvokabular, dass für jeden Kurs variieren kann. Aus diesem Grund genügt es nicht, einfach Englisch anzukreuzen, damit man alle Kurse in Englisch halten kann. Es muss differentiert für alle Kurse angegeben werden, in welcher Sprache man diesen halten kann. Diese Vorgehensweise erhöht zwar den Tippaufwand für den Trainer, aber die Auswahl des Trainers kann viel spezifischer erfolgen Online Kalender Um die Verfügbarkeit verwalten zu können, müssen die Trainer ihre Verfügbarkeit erst eintragen. Dies geschieht mit einem Online Kalender. Die Verfügbarkeit stellt sich durch einen dunkelblauen Bereich in der Wochenansicht dar. Gebuchte Bereiche werden hellblau dargestellt. Andere Termine werden grün dargestellt. Der Kalender ist jedoch nur prototypenhaft implementiert. Bis zum Zeitpunkt der Fertigstellung konnte er leider noch nicht von der Firma SILVA evaluiert werden. Es wurde daraufhin verzichtet, die Entwicklung in diesem Bereich fortzusetzen.

63 KAPITEL 9. BEDIENUNG DER WEB SITE 56 Abbildung 9.8: Trainer Kalender Das Software Design des Kalenders ist aber so allgemein gehalten, dass eine Erweiterung des Kalenders leicht vorgenommen werden kann. Eine Monatsansicht wäre zum Beispiel sehr wünschenswert. Modifikationen, die das Layout des Kalenders betreffen, können durch Änderung der ASP Scripts vorgenommen werden. 9.4 Customer Area Der Kunde kann seine persönlichen Daten ändern, Kursinformationen abfragen und natürlich Kurse buchen. Nachdem ein Kunde gültige Zugangsdaten eingegeben hat, gelangt er zu seiner Startseite. Hier sieht er alle abgeschlossenen gebuchten Kurse. Der Kunde kann dann diese Kurse mittels einem Online Feedback Formular evaluieren. Dieses Feedback fliesst dann direkt in zukünftige Auswahlen von Trainern ein Feedback Formular Das Feedback, das der Kunde einzugeben hat, beinhaltet folgende Felder:

64 KAPITEL 9. BEDIENUNG DER WEB SITE 57 Erwartungen Nutzen Inhalt Dauer Tempo Vorkenntnisse Unterlagen Gesamtnote Diese Felder wurden von der Fa. SILVA G.m.b.H vorgegeben. Die Eintragungen sind im Schulnotensystem einzugeben ( Sehr Gut bis Nicht Genügend ). Intern werden die Noten umgerechnet in Werte zwischen 0 (Nicht Genügend) und 1 (Sehr Gut) Kursinfos Der Kunde kann in einer eigenen Seite die Details aller angebotenen Kurse abfragen. Die Details sind in dieser Implementierung als Hyperlink ausgeführt. D.h. Es obligt dem Systadministrator vor Ort die Links auf eine externe Site zu setzen, um hier die Informationen anzeigen zu lassen. Momentan wurde das Kursportfolio der Fa. SILVA G.m.b.h, welches in Microsoft Powerpoint vorlag, in JPEG Bilder convertiert und die Links auf die Bilder gesetzt. Diese Vorgangsweise ist sicher nicht optimal, sie soll hier aber nur die Möglichkeiten aufzeigen und als Prototyp dienen Die Buchung Die Buchung erfolgt in mehreren Schritten. Zuerst muss das Buchungsformular (Abbildung 9.10) ausgefüllt werden. Es ist möglich, hier einen eigenen Ansprechpartner anzugeben, der auf Kundenseite für die Abwicklung dieses Kurses verantwortlich ist. Standardmäßig wird der eingeloggte User als Kontaktperson angenommen. Falls die Kontaktperson geändert wird, ist auf eine korrekte Adresse zu achten, damit der geänderte User auch die notwendigen Nachrichten vom System erhält. Nach der Eingabe der Daten versucht der Server mit den zuvor beschriebenen Algorithmen, Vorschläge für Kurstermine zu finden. Diese Vorschläge werden dem User als Antwort auf die Eingabe des Buchungsformulars präsentiert. Aus diesen Vorschlägen kann

65 KAPITEL 9. BEDIENUNG DER WEB SITE 58 Abbildung 9.9: Kursportfolio: Beispiel MS Visual Basic Abbildung 9.10: Buchungsformular