Verknüpfung eines Carsharing-Kundenportals mit einem Web ... · Zusammenfassung Eine...

Gottfried Wilhelm Leibniz Universitat HannoverFakultat fur Elektrotechnik und Informatik

Institut fur Praktische InformatikFachgebiet Software Engineering

Verknupfung eines Carsharing-Kundenportals

mit einem Web-Kartendienst:

Anforderungen, Konzept und Umsetzung

Diplomarbeitim Studiengang Mathematik mit Studienrichtung Informatik

von

Mathis Dirksen-Thedens

22. Mai 2007

Erstprufer: Prof. Dr. Kurt Schneider

Zweitprufer: Prof. Dr. Marc C. Steinbach

Betreuer: M. Sc. Eric Knauss

Erklarung

Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbstandig und oh-ne fremde Hilfe verfasst und keine anderen als die in der Arbeit angegebenenQuellen und Hilfsmittel verwendet habe. Die Arbeit hat in dieser oder ahnlicherForm noch keiner anderen Prufungskommission vorgelegen.

Hannover, den 22.05.2007

Zusammenfassung

Eine Carsharing-Organisation muss ihren Kunden unter anderem die Informati-on zur Verfugung stellen, wann welches Fahrzeug buchbar ist. Diese temporalenDaten stehen in engem Zusammenhang mit den jedem Fahrzeug zugeordnetenStandortdaten. Fur diese geographischen Daten ist es sinnvoll, die Benutzer-schnittstelle durch eine Kartendarstellung zu erweitern, und da die Buchung vonFahrzeugen im hier betrachteten Fall vornehmlich uber das WWW stattfindet,kann ein webbasierter Kartendienst benutzt werden.

Es ist das Thema dieser Arbeit, diese Integration zu planen und durchzufuhren.Zuerst werden die Anforderungen gesammelt (hierzu wird u. a. eine Online-Umfrage eingesetzt), ein Konzept wird erstellt und dieses schließlich realisiert.Das Kundenportal wird in ein bestehendes Carsharing-Programm integriert undgetestet.

Inhaltsverzeichnis

1 Einleitung 6

1.1 Carsharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Anwendungsszenario . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Anforderungen 9

2.1 Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Projektziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Kontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Erhebung der Anforderungen . . . . . . . . . . . . . . . . . . . . 13

2.4.1 Expertenwissen . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.2 Bestandssystem . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.3 Umfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5.1 Funktionale Anforderungen und Use Cases . . . . . . . . . 20

2.5.2 Technische Anforderungen . . . . . . . . . . . . . . . . . . 24

2.5.3 Qualitatsanforderungen . . . . . . . . . . . . . . . . . . . . 24

2.6 Reflexion der Umfrage . . . . . . . . . . . . . . . . . . . . . . . . 26

2.7 Methodische Bewertung . . . . . . . . . . . . . . . . . . . . . . . 28

2.7.1 Grundsatzliche Uberlegungen . . . . . . . . . . . . . . . . 28

2.7.2 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.8 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.8.1 Testdatenbestand . . . . . . . . . . . . . . . . . . . . . . . 30

2.8.2 Testfalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3 Konzept 36

3.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Datenorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.1 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.2 Vorhaltung und Verteilung . . . . . . . . . . . . . . . . . . 42

3.3 Suche nach kurzesten Wegen . . . . . . . . . . . . . . . . . . . . . 43

3.3.1 Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.2 Abstandsberechnungen . . . . . . . . . . . . . . . . . . . . 45

3.4 Wahl eines Web-Kartendienstes . . . . . . . . . . . . . . . . . . . 46

3.5 Wahl eines geeigneten Frameworks . . . . . . . . . . . . . . . . . 46

3.6 Benutzeroberflache . . . . . . . . . . . . . . . . . . . . . . . . . . 47


4 Implementierung 50

4.1 Systemumgebung und Komponenten . . . . . . . . . . . . . . . . 51

4.1.1 Programmiersprachen . . . . . . . . . . . . . . . . . . . . . 51

4.1.2 EBuS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1.3 Echo2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.1.4 Google Maps Komponente fur Echo2 . . . . . . . . . . . . 53

4.2 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2.1 Anbindung an EBuS . . . . . . . . . . . . . . . . . . . . . 56

4.2.2 Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2.3 Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . 57

4.3 Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3.1 Echo2 und fremde Javascript-Dateien . . . . . . . . . . . . 59

4.3.2 Timeout Management . . . . . . . . . . . . . . . . . . . . 60

4.4 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4.1 Von Anforderungen abgeleitete Tests . . . . . . . . . . . . 61

4.4.2 Der Algorithmus zum Finden kurzester Wege . . . . . . . 63

4.4.3 Akzeptanztests mit Versuchspersonen . . . . . . . . . . . . 64

4.5 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5 Schlussbetrachtungen 73


5.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Quellenverzeichnis 77

Anhang 79

A.1 Die Umfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.2 Tabellarische Auflistung der Anforderungen . . . . . . . . . . . . 84

Kapitel 1

Einleitung

Diese Diplomarbeit befasst sich mit der Einbettung eines Web-Kartendienstes inein Buchungsportal fur Kunden von Carsharing-Unternehmen. Der Hauptteil derArbeit besteht aus den drei Teilen Anforderungen, Konzept und Implementie-rung, wobei ein besonderer Schwerpunkt auf der Anforderungserhebung liegt.

Aus Grunden der besseren Lesbarkeit wird bei geschlechtsspezifischen Begriffendurchgangig nur die mannliche Form verwendet; diese versteht sich ausdrucklichals geschlechtsneutral und schließt Frauen mit ein.

1.1 Carsharing

Das Ziel von Carsharing ist optimale Auslastung von Fahrzeugen, die gemeinsamgenutzt werden. Die Besonderheit gegenuber einer herkommlichen Autovermie-tung besteht in der flexiblen Nutzung der Fahrzeuge, z. B. kann ein Benutzerkurzfristig buchen und dann sofort zum Stellplatz des Fahrzeuges gehen. An die-sem Beispiel wird ein weiterer wichtiger Unterschied deutlich: Die Vorhaltung derFahrzeuge ist dezentral organisiert, das heißt, es gibt keinen Hof, auf dem alleAutos stehen, wenn sie nicht benutzt werden, sondern es sind viele Stellplatzeuber den gesamten Abdeckungsbereich des Unternehmens eingerichtet, und aufjedem dieser Stellplatze stehen wenige Fahrzeuge fur den Nutzer bereit, an ei-nigen Stellen auch nur eines. Diese Politik nach dem Motto

”nah am Nutzer“

erfordert es, dass jeder Nutzer an sein gebuchtes Fahrzeug kommt, ohne vorhereinen Schlussel in der Zentrale abholen zu mussen, denn das wurde den gan-zen Vorteil wieder zunichte machen. Dies wird zumeist durch ein elektronischesZugangssystem gelost.

1.2. Aufgabenstellung 7

Die Geschichte des Carsharing reicht zuruck bis ins Jahr 1948. Zu dieser Zeitwurde in der Schweiz die

”Selbstfahrergenossenschaft“ mit dem Ziel gegrundet,

gemeinsam ein Auto anzuschaffen, welches fur jeden einzeln unmoglich gewe-sen ware. Dieser Ansatz wurde jedoch im Zuge des wirtschaftlichen Aufschwungsschnell verdrangt, denn bald konnte sich jeder ein eigenes Auto leisten. Der zweiteAnlauf mit diesem Konzept kam etwa 40 Jahre spater. Wiederum in der Schweizwurde im Jahr 1987 das erste europaische Unternehmen mit dem Ziel gegrundet,Carsharing anzubieten. In Deutschland war Berlin in der Vorreiterrolle, dort ent-stand 1988 das erste deutsche Carsharing-Unternehmen. Fur weitergehende In-formationen zur historischen Entwicklung siehe z. B. [Ro01].

Die vorliegende Arbeit wird im Betrieb der cantamen GmbH erstellt. cantamenist ein IT-Dienstleister, der seine Software

”EBuS“ (Elektonisches Buchungs-

System) weltweit Carsharing-Unternehmen zur Verfugung stellt, unter anderemauch Stadtmobil Hannover – auch noch unter dem alteren Namen teilAuto be-kannt. Diese Firma bietet ihren Kunden 100 Fahrzeuge an 58 Stationen im RaumHannover an. Es gibt ca. 2600 Nutzungsberechtigte, die insgesamt durchschnitt-lich 2600 Buchungen pro Monat durchfuhren, davon ca. 75% uber die Webober-flache der Buchungssoftware, der Rest bucht uber Telefon bei der Buchungszen-trale.

1.2 Aufgabenstellung

Die zu bewaltigende Aufgabe ist, ein Portal fur Kunden eines Carsharing-Anbie-ters zu erstellen, welches die Daten zu vorliegenden Buchungen verwendet und ineinen Web-Kartendienst integriert. Daran angeknupft ist die geographische Suchenach kurzesten (Fußganger-)Wegen, um den Kunden die von seiner momentanenPosition aus schnellstmoglich erreichbaren Standorte anzeigen zu konnen.

Besonderes Augenmerk soll auf die Anforderungen gelegt werden. Es muss vorallem geklart werden, auf welche Weise die Benutzer das Portal nutzen werden;hierzu soll eine Online-Umfrage unter bestehenden Kunden durchgefuhrt werden.Eine allgemeine Bewertung der Methode

”Umfrage“ zur Anforderungserhebung

und aus den Anforderungen abgeleitete Abnahmetests schließen diesen Bereichab.

Ein Konzept bzw. ein Grobentwurf des Systems soll erstellt werden, hier istdie Anbindung des Web-Kartendienstes an die Unternehmensdaten ein wichti-ger Punkt.

Schließlich ist das entworfene System auch praktisch umzusetzen und zu doku-mentieren.

1.3. Anwendungsszenario 8

1.3 Anwendungsszenario

Das Geschaft eines Carsharing-Unternehmens ist die Bereitstellung von Fahrzeu-gen, die Kunden unkompliziert und flexibel buchen und nutzen konnen. Das zuerstellende Kunden-Portal will den Kunden großere Flexibilitat bieten, indem eseine Karte als Hilfsmittel benutzt, um mit dem Kunden zu interagieren. Denk-bare Szenarien sind z. B., dass der Kunde seine Position uber eine Karte eingibt,oder dass ein Uberblick uber verfugbare Fahrzeuge in einer Karte angezeigt wird.

Der Mehrwert entsteht dabei durch die Verknupfung der bereits vorhandenenInformationen uber die verfugbaren Fahrzeuge an den jeweiligen Standorten mitder Darstellungsform

”Karte“, denn so sind die Daten fur den Nutzer schneller

begreifbar – der bestehende Zusammenhang wird besser visualisiert.

1.4 Vorgehensweise

Der Rational Unified Process (RUP, siehe [ZGK04]) steht in abgewandelter FormModell fur das in diesem Projekt verwendete Vorgehen; eine erwahnenswerteAnderung ist die Phasenbezeichnung und -aufteilung: Das Projekt wurde in diePhasen

”Anforderungen“,

”Konzept“,

”Implementierung“ und

”Test“ eingeteilt,

wobei”Anforderungen“ die Konzeptionsphase des RUP mit umfasst, die Ent-

wurfsphase des RUP jedoch auf”Anforderungen“ und

”Konzept“ verteilt wurde.

Dies erscheint sinnvoll, da die Anforderungen ein Schwerpunkt dieser Arbeit sind.Die Integration in die Bestandssysteme ist bereits vom Beginn der Implementie-rung zwingend erforderlich und bildet deshalb keine separate Phase. Außerdemwurde die Auslieferungsphase ausgelassen, da im Rahmen dieser Arbeit keineendgultige Auslieferung stattfinden wird – diese wird spater von Entwicklern derFirma cantamen durchgefuhrt.

Kapitel 2

Anforderungen

Die Anforderungen und ihre Erhebung nehmen einen wichtigen Platz in jedemProjekt ein. Ohne eine korrekte und großtenteils vollstandige Liste von Anforde-rungen kann ein Projekt nicht sinnvoll geplant und realisisert werden. In diesemKapitel wird eine Liste der Stakeholder(-Gruppen) angefertigt (siehe Abschnitt2.1), die Ziele des Projekts werden festgelegt und das zu erstellende System wirdgegen seine Umgebung abgegrenzt. Es folgt die Dokumentation der Befragungder Stakeholder bzw. der Vertreter der Stakeholder-Gruppen.

Besonders wichtig ist die ubersichtliche Dokumentation der Anforderungen, hier-zu bieten sich unterschiedliche Techniken an, aus denen eine auszuwahlen ist.Eine Zusammenfassung der wichtigsten Anforderungen und der daraus abgelei-teten Tests bilden den Abschluss dieses Kapitels.

2.1 Stakeholder

Stakeholder sind alle Personen, Organisationen oder Datenverarbeitungssysteme,die irgendein Interesse an dem zu erstellenden System haben. Alle Stakeholdersollten idealerweise befragt (naturliche Personen, Organisationen) oder analysiertwerden (DV-Systeme), um die Anforderungen an das neue System zu finden.Insbesondere ist das Finden aller Stakeholder entscheidend fur den Erfolg einesProjekts.

Die menschlichen Stakeholder konnen fur dieses Projekt grob in folgende Bereicheeingeteilt werden (Ansprechpartner der einzelnen Untergruppen jeweils hervor-gehoben):

2.1. Stakeholder 10

1. Die Firma cantamen GmbH und ihre Mitarbeiter. cantamen stellt ein Sys-tem zur technischen Abwicklung von Buchungsvorgangen bei Carsharing-Unternehmen zur Verfugung und tritt dabei hauptsachlich als Dienstleisterauf. Die Kunden von cantamen sind verschiedene Carsharing-Anbieter inganz Europa, insbesondere auch Stadtmobil Hannover. Diese Untergruppenkonnen definiert werden:

� Die Geschaftsfuhrung (Dirk Hillbrecht, Harald Zielstorff). Sie hatein vitales Interesse an einfachen, gut funktionierenden und daheransprechenden Buchungsvorgangen. Durch zufriedene Kunden kannmehr Gewinn erzielt werden. Die Geschaftsfuhrung legt auch Wert aufZukunftssicherheit, denn es muss auch spater noch Support fur dasSystem geleistet werden.

� Die Kundenbetreuung (Mariana Pankova-Kumm, Claudia Kemp-ka). Diese Gruppe muss den Kunden helfen, das System passend einzu-richten und zu administrieren, oft auch am Telefon. Es ist diesen Sta-keholdern wichtig, dass das System einfach administrierbar ist, damitder Supportaufwand klein bleibt. Außerdem darf das System keine an-deren, parallel laufenden Anwendungen negativ beeinflussen, wodurcheine aufwendige Fehlersuche notig wurde.

2. Stadtmobil Hannover GmbH und ihre Mitarbeiter. Stadtmobil, auch unterdem Namen teilAuto bekannt, ist ein Carsharing-Anbieter mit etwa 2600Nutzungsberechtigten und ein Kunde von cantamen. Es gibt in dieser Firmafolgende Untergruppen:

� Die Geschaftsfuhrung (Harald Zielstorff). Hier ist das Interesse, dassdas Unternehmen Gewinn macht. Dazu soll das neue Kundenportalin Zukunft produktiv eingesetzt werden. Der Schwerpunkt liegt hiereinerseits auf der Sicherheit der Kundendaten, andererseits auf derZuverlassigkeit des neuen Systems. Es werden pro Monat etwa 1950Buchungen online getatigt – das bedeutet durchschnittlich alle 17 Mi-nuten eine Buchung, wenn man von einer Gleichverteilung von 6 bis24 Uhr ausgeht. Es wurde also beinahe sofort zu einem Umsatzverlustkommen, falls das System ausfallt.

� Die Kundenbetreuung (Judith Siano, Martin Russ, Henner Schmidt).Diese Stakeholder sind damit befasst, den Endkunden zu helfen, dieuber das neue Portal Fahrzeuge buchen wollen. Kunden rufen vor-nehmlich dann an, wenn sie Probleme haben und selbst nicht weiter-wissen, darum liegt fur diese Gruppe von Stakeholdern die Prioritat aufeinem intuitiv bedienbaren und leicht zu uberschauenden Buchungs-portal. Die Kunden haben so weniger Probleme, und die Mitarbeiter

2.2. Projektziele 11

von Stadtmobil konnen im Ernstfall leichter helfen, da sie die Bu-chungsoberflache selbst gut bedienen konnen.

3. Die Kunden von Stadtmobil Hannover. Diese Gruppe wurde uber die inAbschnitt 2.4.3 beschriebene Umfrage befragt. Man kann die Kunden inFirmen-/Großkunden und Privatkunden unterteilen; der Unterschied ist le-diglich, dass Firmenkunden Unternutzer haben, die alle uber eine Rech-nung abgerechnet werden, z. B. ist es so moglich, dass einzelne Angestell-te Stadtmobil dienstlich nutzen – eine solche Unterscheidung ist aber furdie Zielsetzung dieser Arbeit unerheblich, daher wird hier die allgemeine-re Terminologie

”Nutzungsberechtigte“ austauschbar mit der Bezeichnung

”Kunden“ oder

”Nutzer“ verwendet.

Die Vertreter der Stakeholder der ersten zwei Gruppen sind im Allgemeinen soforterreichbar, praktisch on-site. Die Stakeholder aus der dritten Gruppe wurdendurch die Umfrage erreicht.

Als weitere, nichtmenschliche Stakeholder sind die Systeme zu sehen, die mitdem zu erstellenden Portal interagieren sollen. Das sind vor allem EBuS zumBereitstellen der Geschaftsdaten und der Web-Kartendienst, der zum Visua-lisieren der geographischen Zusammenhange verwendet wird. Hier gibt es keineAnsprechpartner im eigentlichen Sinne, jedoch kann Dirk Hillbrecht als der In-itiator und Hauptentwickler von EBuS Fragen beantworten. Eine Dokumentationvon EBuS ist hingegen leider nur sehr luckenhaft vorhanden. Im Zusammenhangmit dem Web-Kartendienst kann die Online-Dokumentation als Referenz benutztwerden, außerdem gibt es vielfach Benutzerforen, in denen man gemeinsam mitanderen Benutzern des Dienstes Sachverhalte klaren kann.

2.2 Projektziele

Jeder der Stakeholder hat eigene Ziele – manche bewusst, manche implizit undunbewusst. Einige liegen auf der Hand, andere werden unter Umstanden ersterkannt, wenn das System schon fast fertig ist. Die Entwicklung eines Systemshat immer das Hauptziel, die Bedurfnisse der Stakeholder zu befriedigen, daherist es empfehlenswert, alle Stakeholder mit einzubeziehen, wenn die Ziele derEntwicklung festgelegt werden. Nach [Rup04] mussen Ziele

� vollstandig,

� korrekt,

� konsistent gegenuber anderen Zielen und in sich,

2.2. Projektziele 12

� testbar,

� verstandlich fur alle Stakeholder,

� umsetzbar bzw. realisierbar,

� notwendig,

� eindeutig,

� positiv formuliert,

� aktuell und

� losungsneutral sein und

� die einschrankenden Rahmenrichtlinien enthalten.

Die folgenden Ziele sind fur dies Projekt wichtig (die Reihenfolge bedeutet keineGewichtung): Das System soll. . .

Z1. einfach und intuitiv zu bedienen sein,

Z2. den Web-Kartendienst sinnvoll bei der Anzeige von geographischen Infor-mationen verwenden,

Z3. fehlertolerant auf Benutzereingaben reagieren,

Z4. kurze Antwortzeiten haben,

Z5. eine zukunftssichere Architektur besitzen, so dass spatere Anderungen oderErganzungen mit wenig Aufwand durchfuhrbar sind,

Z6. sich leicht in den EBuS-Server integrieren lassen, insbesondere soll der bis-herige EBuS-Befehlssatz benutzt werden (kleine Veranderungen daran sindmoglich),

Z7. einfach wartbar sein und ein zugangsgeschutztes Administrator-Backendhaben,

Z8. Datensicherheit gewahrleisten (niemand darf unberechtigt Daten abfangenoder ausspahen),

Z9. Datenkonsistenz gewahrleisten (zu keinem Zeitpunkt durfen Unklarheitenuber Buchungsdaten bestehen),

2.3. Kontext 13

Z10. den Server, auf dem es lauft, auch bei vielen parallelen Anfragen nicht zustark belasten,

Z11. an firmeninterne Gegebenheiten anpassbar sein (z. B. soll das Aussehen derOberflache veranderbar sein) und

Z12. zuverlassig arbeiten (auch bei hoher Last darf es nicht absturzen).

Finanzielle Ziele wurden in der obigen Liste bewusst nicht genannt, weil sie beider Durchfuhrung dieser Diplomarbeit nicht im Vordergrund stehen.

2.3 Kontext

Das zu entwickelnde System wird zusammen mit EBuS (”Elektronisches Bu-

chungs-System“, siehe auch Abschnitt 4.1.2) eingesetzt und muss mit diesem be-stehenden System Daten austauschen. Dabei wird eine Abstraktionsschicht uberInterfaces angestrebt, welche den Zugriff auf verschiedene Bereiche von EBuS ver-einheitlicht und zusatzlich die Moglichkeit schafft, in Zukunft auch mit anderenBackends zu arbeiten. Fur EBuS gibt es das javabasierte

”EBuS Management

Center“, welches auch zukunftig zum Pflegen der Daten benutzt werden soll. Imneuen Backend sollen lediglich die geographischen Daten fur den Administratorzu bearbeiten sein.

Das System wird einen Web-Kartendienst benutzen, um geographische Daten an-zuzeigen. Dabei bleibt zunachst offen, auf welche Weise und in welchem Teil desresultierenden Gesamtsystems die geographischen Daten gespeichert und notwen-dige Berechnungen damit durchgefuhrt werden. In jedem Fall wird nur das Ender-gebnis der Berechnungen, d. h. die Koordinatenpaare mit den notigen zusatzlichenInformationen wie Beschreibung oder gewunschtem Icon, an den Kartendienstzum Darstellen ubergeben, denn dieser bietet keinen Speicherplatz fur zusatzlicheDaten.

2.4 Erhebung der Anforderungen

Die Anforderungen werden in diesem Projekt hauptsachlich aus drei verschiede-nen Quellen gewonnen:

1. aus Befragungen der on-site verfugbaren Stakeholdergruppen-Ansprechpart-ner (siehe Abschnitt 2.1),

2.4. Erhebung der Anforderungen 14

2. aus der Analyse des Bestandssystems und

3. aus einer Umfrage unter den Nutzern des Bestandssystems.

2.4.1 Expertenwissen

Ein Teil der Anforderungen kann schon vor der Umfrage durch Interviews mit denVertretern der Stakeholder innerhalb der Unternehmen cantamen und Stadtmobileruiert werden. Diese Gruppe von Stakeholdern stellt eine qualifizierte, jedochzahlenmaßig sehr kleine Minderheit dar. Darum ist es sinnvoll, die erwartetenKundenanforderungen durch die Umfrage validieren zu lassen und die Gewichtungder Anforderungen herauszufinden.

Das Ergebnis der Gesprache ist eine Liste von naturlichsprachlichen Anforde-rungen und Wunschen, die im Abschnitt 2.5 zusammengefasst werden und inder vollstandigen Auflistung unter A.2 festgehalten sind. Die Angabe der Quel-len zu jeder Anforderung ermoglicht es, auch im Nachhinein festzustellen, welcheAnforderungen (und welche Prioritaten) im einzelnen aus diesen Gesprachen her-vorgegangen sind.

2.4.2 Bestandssystem

Ein anderer wichtiger Teil der Anforderungen kann aus der Analyse des bestehen-den, produktiven Systems EWI (

”EBuS Web Interface“) gewonnen werden. Hier

soll die generelle Architektur und die Benutzerfuhrung untersucht werden. EWIwurde vor einigen Jahren erstellt, um dem Kunden bei dem Prozess des Auslei-hens eines Fahrzeuges zu assistieren und bietet deshalb wertvolle Informationenuber diesen Prozess.


Abbildung 2.1: Das Hauptmenu des Bestandssystems EWI

Der Vorlaufer des zu erstellenden Systems hat folgende strukturelle Gliederung:

� Neue Buchung beim eigenen Anbieter erstellenHier wird ein Dialog mit dem Kunden gefuhrt, in dem schrittweise derZeitraum der Buchung, die gewunschten Ausstattungsmerkmale, evtl. einbestimmter Standort, ein Fahrzeugtyp und schließlich ein Fahrzeug aus-gewahlt werden. Optional kann zusatzlich ein Fahrtgrund angegeben wer-den, der auch nachher auf der Rechnung erscheint.

� Neue Buchung bei einem Fremdanbieter erstellen (Quernutzungim gleichen System)Hier wird der Tatsache Rechnung getragen, dass die Daten verschiede-ner Carsharing-Anbieter in ganz Deutschland zentral auf den Servern voncantamen mit derselben Software verarbeitet werden. Es gibt ein Abkom-men zwischen den Mitgliedern des Dachverbandes Europaischer Carsharing-Unternehmen (ECS), durch welches solche Quernutzungen generell gestat-tet sind. Besonders einfach ist es in diesem Fall, da alle Daten vorhanden


sind. Daher ist hier eine direkte Nutzung der Angebote anderer Carsharervorgesehen.

� Buchungen bearbeiten/stornieren/druckenHier konnen Buchungen, deren Nutzungszeitraum noch nicht begonnen hat,bearbeitet oder storniert werden, und Buchungen, deren Nutzungszeitraumgerade lauft, konnen vorzeitig beendet werden. Außerdem konnen fur diesezwei Typen von Buchungen Bestatigungen gedruckt werden (abgeschlosseneBuchungen sind nicht sichtbar). Beim Stornieren gibt es die Moglichkeit,sich dafur eine Bestatigung ausdrucken zu lassen, wenn die Stornierung aberfertig durchgefuhrt wurde, nicht mehr.

� Personliche Einstellungen anpassenHier kann der Kunde Passwort, Email-Adresse, seine funf bevorzugten Stand-orte und ahnliche Einstellungen tatigen.

� Abmelden

� Neue Buchung bei einem Fremdanbieter erstellen (Quernutzungin einem anderen System)Dies sind lediglich Links zu den Buchungsseiten von Fremdanbietern, mitdenen ein Abkommen besteht, die aber ein anderes System verwenden, d. h.es ist keine direkte Buchung moglich.

Diese Struktur soll generell beibehalten werden, allerdings wird das neue Systemin mehreren Punkten verandert und erweitert, im folgenden einige Beispiele (sieheauch Abschnitt 2.5):

� Es wird nicht nur beliebig viele”Bevorzugte Fahrzeug-Standorte“ geben,

sondern zusatzlich auch”Bevorzugte Positionen“ – ein Standort ist dabei

immer der Standort eines Fahrzeugs, eine Position immer eine geographischePosition, zu welcher der Benutzer nahe gelegene Fahrzeuge sucht, meist wirddies der Standort des Benutzers sein.

� Die verschiedenen Moglichkeiten, eine neue Buchung beginnen, werden zu-sammengelegt – so kann man unter einem einzigen Menupunkt normaleBuchungen und Quernutzungen im gleichen System erstellen.

� Der Dialogstil beim Erstellen neuer Buchungen wird aufgelost. Bisher muss-te der Benutzer eine Frage beantworten, z. B. diejenige nach dem Buchungs-zeitraum, und dann auf

”Weiter“ klicken und auf einer neuen Seite andere

Eingaben tatigen. Durch die Verwendung neuer Webtechnologien kann die-ser Vorgang auf einer Seite zusammengefasst werden, die sich dynamischaktualisiert, je nachdem, was der Benutzer eingibt oder auswahlt.


2.4.3 Umfrage

Die Umfrage wird im Prozess der Anforderungserhebung verwendet, um mog-lichst viele Stakeholder aus der Gruppe

”Kunden bzw. Nutzer von Stadtmobil

Hannover“ (siehe Abschnitt 2.1) zu erreichen und ihre Meinung einzubeziehen.Es wird unter anderem erhoben, wie zufrieden die Kunden mit dem aktuell beste-henden System sind; die Antworten auf diese Frage sollen die Gewichtung der ausdem Altsystem abgeleiteten Ziele und Anforderungen beeinflussen. Die Umfra-ge wird nach verschiedenen Prinzipien der Marktforschung gestaltet (Literatur:insbesondere [e-t], [Sch03] und [BWGB99], ferner [Fin95a] und [Fin95b]).

2.4.3.1 Fragebogen

Das Mittel der Umfrage, der Fragebogen, soll strukturiert entworfen und aufverschiedene Bereiche aufgeteilt werden, die nacheinander abzufragen sind, damitder Teilnehmer nicht die Orientierung verliert und die Umfrage evtl. vorzeitigabbricht. Es wird großer Wert darauf gelegt, dass Kommentare, die nicht in dasvorgegebene Schema passen, trotzdem einzugeben sind; um dies zu realisieren,wird ein zusatzliches Feld

”Kommentare“ oder

”Bemerkungen“ hinzugefugt, wo

dies notig erscheint.

Die Open-Source-Software flexSURVEY [Har] wird verwendet, um den Frage-bogen zu erstellen. flexSURVEY generiert auf Basis von PHP und MySQL dieUmfrageseiten dynamisch und speichert die Antworten.

Die technische Vorbereitung der Umfrage besteht unter anderem darin, eineMoglichkeit zu finden, um mehrfache Abgaben eines Benutzers zu erkennen, obabsichtlich oder unabsichtlich, denn dadurch kann das Ergebnis verzerrt wer-den. Die gewahlte Losung ist, einen MD5-Hash der Kundennummer als POST-Parameter an das flexSURVEY-System zu ubergeben. Dies ist zweckdienlich, danur Bestandskunden befragt werden sollen – nur diese konnen die Fragen beant-worten. Die einzelnen Elemente der Umfrage sind detailliert in A.1 aufgefuhrt.


Abbildung 2.2: Beispielseite aus der Umfrage

2.4.3.2 Auswertung

Die Umfrage wurde im Befragungszeitraum (30.11.2007 bis 02.01.2007) 249 malausgefullt; diese Zahl kann wie in Tabelle 2.1 gezeigt in verschiedene Gruppenaufgespalten werden. Am Ende dieses Auswahlvorgangs blieben noch 166 ver-wertbare Abgaben ubrig. Dies entspricht ca. 6,6% erfolgreich befragten Nutzern


von Stadtmobil Hannover und reicht aus, um die Reprasentativitat der Umfragezu rechtfertigen. Der Dropout bis zur zweiten Frage liegt bei knapp 30% (zur Be-rechnung wurden die Abgaben ohne Hashwert und die mehrfachen Abgaben außerAcht gelassen) – ein in Online-Befragungen durchaus noch akzeptabler Wert.

Abgaben insgesamt 249

komplett leere Abgaben1 29nur die erste Frage wurde beantwortet 41Abgaben ohne Hashwert 9mehrfache Abgaben – nur erste Abgabe gewertet 4

⇒ verwertbare Abgaben 166

Tabelle 2.1: Erste Aufteilung der Umfragedaten

Die verwertbaren Abgaben werden wie folgt ausgewertet:

� Die Zufriedenheit mit bestimmten Bereichen der Online-Buchung fließt indie Priorisierung ein (s. u.). Dabei gilt generell, dass Anforderungen ausden Bereichen mehr Gewicht bekommen, in denen die Zufriedenheit kleinerals die allgemeine Zufriedenheit ist.

� Alle Anregungen aus Feldern, in denen der Befragte Verbesserungen vor-schlagen oder bestehende Probleme beschreiben konnte, werden ggf. nacheiner Gewichtung (s. u.) in die Anforderungen ubernommen. Die Anzahlder Nennungen wird berucksichtigt und beeinflusst die Prioritat der Anfor-derung.

� Die Frage nach der Wichtigkeit der Anderungen (F4 in A.1) lasst erken-nen, was als absolute Notwendigkeit angesehen wird (

”Basisfaktoren“ nach

[Rup04]) und was eher eine Anregung fur die weitere Entwicklung ist. Eswerden die Verbesserungen, die eine Wichtigkeit von 6 oder 7 (auf der Ska-la von 1 bis 7) erhalten haben, direkt in die Anforderungen eingebracht,Anmerkungen mit Wichtigkeiten von 3 – 5 werden mit dem Faktor 0,5 ge-wichtet und unter einer Bewertung von 3 wird davon ausgegangen, dass dieAnderung nicht allzu wichtig ist, und sie wird in der weiteren Auswertungnicht weiter berucksichtigt.

� Die drei Vorschlage in Zusammenhang mit der Benutzung einer Karte inder neuen Oberflache (eigene Position uber einen Stadtplan eingeben und

1d. h. die erste Seite wurde angeschaut, aber nicht abgesendet

2.5. Ergebnisse 20

nachstgelegene Fahrzeuge angeboten bekommen, eigene Positionen als Fa-voriten, Ubersichtskarte der Stellplatze mit Kriterienwahl) werden als rich-tungsweisend dafur angesehen, welche Funktionalitat Prioritat haben sollte.

� Die Nutzungsdaten werden benutzt, um herauszufinden, fur welche Zugriffs-art bzw. fur welche Plattform die Oberflache zu optimieren ist. Wenn z. B.viele Benutzer angeben, dass sie mobile Gerate nutzen, muss die Online-Buchung fur einen solchen Zugriffsweg angepasst werden.

2.5 Ergebnisse

Im folgenden werden die wichtigen Anforderungen erlautert. Die vollstandige Lis-te ist in Abschnitt A.2 nachzulesen, dort sind auch die Quellen und Prioritatengenauer angegeben.

2.5.1 Funktionale Anforderungen und Use Cases

Ein essentieller Punkt in der Umfrage war die Karte. Vielfach gaben die Befragtenin den Kommentarfeldern positive Ruckmeldungen, und auch die Antworten beiden systematischen Bewertungsfragen zeigen, dass diese Entwicklung geschatztwird.

Ein Vorschlag stach besonders heraus; er wurde bei 78 von 134 Antworten mit derhochsten Wertung bedacht, und zwar

”die Karte zeigt, an welchen Stellplatzen

Fahrzeuge mit den vom Benutzer gewahlten Kriterien (Typ, Ausstattung...) zuder gewahlten Zeit verfugbar sind“. Die Gesamtwertung fur diesen Vorschlag lagbei 0,85 auf einer Skala von 0 bis 1.

Der andere Vorschlag (”der Benutzer kann seine eigene Position in die Karte ein-

geben, wobei das System automatisch die nachstgelegenen Fahrzeuge fur Buchun-gen anbietet“) kam auf eine Gesamtwertung von 0,78. Die Befragten empfandendiesen Vorschlag als ein wenig schlechter bzw. uninteressanter, daher wird er miteiner etwas niedrigeren Prioritat versehen als der oben genannte (siehe A.2).

Auch bei der Mehrheit als wichtig angesehen wurde die Moglichkeit, Favoriten zuhinterlegen. Als Erweiterung zum bisherigen System soll die Anzahl jedoch un-begrenzt sein (bisher waren funf moglich), und zusatzlich zu einzelnen Fahrzeug-standorten sollen auch beliebige geographische Positionen, von denen aus gesuchtwerden kann, ebenfalls als Favoriten zu speichern sein. Haufig wird eine solchePosition wohl aus der Eingabe der Adresse des Benutzers hervorgehen.

2.5. Ergebnisse 21

Viele Benutzer wunschen sich außerdem eine einfach zugangliche Detailseite zujedem Fahrzeug, auf der relevante Informationen einzusehen sind, und eine Ver-besserung der Belegtzeitanzeige.

Das folgende Use Case Diagramm zeigt, wie die Stakeholder das System denerhobenen Anforderungen entsprechend benutzen werden.

Abbildung 2.3: Use Case Diagramm (ubergeordnete Use Cases und Akteure)

Der Akteur”Stammdatenbestand“ umfasst die gesamten Fahrzeug-, Buchungs-

und Benutzerdaten. Das folgende Diagramm zeigt auf, wie die Use-Case-Hierarchieaufgebaut ist. Dabei werden aus Platzgrunden nur die Use Cases dargestellt. DieAkteur-Zuordnung ergibt sich aus der Zuordnung zu den Anwendungsfallen derUberblicksebene in der vorigen Darstellung.

2.5. Ergebnisse 22

Abbildung 2.4: Use Case Diagramm (Hierarchie)

Besondere Beachtung verdient der Use Case”Fahrzeug suchen/buchen“. Das

Template (nach [Coc00] und [Cri06]) sieht fur diesen Use Case wie folgt aus:

2.5. Ergebnisse 23

ID: 1.1 Fahrzeug suchen/buchen

Erlauterung Der Kunde mochte entweder anonym nach Fahrzeugen suchenoder eines buchen (dazu muss er allerdings angemeldet sein).

Status FinalEbene UberblickVorbedingung der Benutzer hat die Webadresse geoffnet, unter der das System

erreichbar istMindestgarantie der Benutzer bucht nicht unbeabsichtigt/aus Versehen ein FzErfolgsgarantie das System hinterlegt eine Buchung fur den entspr. Benutzer und

zeigt dem Benutzer eine BestatigungStakeholder

Benutzer: mochte ein Fahrzeug suchen bzw. buchen

Stammdatenhaltung: mochte die Integritat gewahrleisten

Web-Kartendienst: mochte Kartendaten anbieten

Hauptakteur BenutzerAusloser Benutzer wahlt Eintrag im MenuHauptszenario

1. Benutzer → 2.1: Fahrzeug selektieren

2. Benutzer → 3.1: Anmelden

3. Stammdatenhaltung legt Buchung ab

4. Stammdatenhaltung gibt dem Benutzer eine Ruckmeldung

Erweiterungen

� 3: wenn die Buchung unmoglich ist

1. Stammdatenhaltung gibt eine Fehlermeldung aus

TechnischeVariationen

� 2: Schritt 2 kann auch vor Schritt 1 ausgefuhrt werden

Prioritat unverzichtbarVerwendungs-haufigkeit

regelmaßig

2.5. Ergebnisse 24

2.5.2 Technische Anforderungen

In den vorigen Abschnitten wurden schon verschiedene technische Anforderungengenannt, jedoch werden einige bestimmte hier nochmals diskutiert.

Das zu erstellende Kundenportal soll auf einem System eingesetzt werden, das denkomplett in Java implementierten Webserver Jetty 5.1.4 verwendet. Jetty wird alsTeil des EBuS-Servers und nicht eigenstandig gestartet, das bringt auf der einenSeite einen hoheren Konfigurationsaufwand fur Jetty mit sich, auf der anderenSeite aber auch eine bessere Kommunikation zwischen der Webschnittstelle undder Carsharing-Datenhaltung, denn die Programmteile konnen die vorhandenenObjekte direkt benutzen.

Auch erstrebenswert ist, dass das System nicht vollstandig selbstprogrammiertwird, sondern dass ein Toolkit zum Einsatz kommt. Der Vorteil liegt darin, dassein solches Toolkit von vielen Leuten benutzt und weiterentwickelt wird, und so-mit kann bei Problemen oder Inkompatibilitaten vermutlich schnell eine Losunggefunden werden. Außerdem profitiert das System von veroffentlichten neuen Ver-sionen, die einfach eingesetzt werden konnen. Das Toolkit sollte serverseitig inJava ansprechbar sein, um gut mit EBuS kombiniert werden zu konnen, und einemoderne, dynamische Webseite erzeugen, welche aktuelle Techniken wie AJAX(Asynchronous Javascript and XML) benutzt, um die Seite fur den Benutzerbequem, ansprechend und intuitiv zu gestalten.

In der Umfrage wurde von mehr als 91% der Personen, die diese Frage uberhauptbeantwortet haben, angegeben, nie ein mobiles Endgerat zu benutzen, etwas mehrals weitere 5% setzen ein solches seltener als einmal pro Monat ein. Nur vierUmfrageteilnehmer haben angegeben, ein mobiles Gerat wie einen PDA ein- bisviermal im Monat einzusetzen, und eine Person funf- bis neunmal. Es ist also einesehr niedrig priorisierte Anforderung, dass das System auf mobilen Endgeraten alsClients lauffahig ist, deshalb wird in der weiteren Planung hierauf keine besondereRucksicht genommen. Eine spatere Erganzung in dieser Richtung kann dennochsinnvoll sein.

2.5.3 Qualitatsanforderungen

Besonders wichtig sind in diesem Projekt die Qualitatsanforderungen, da voneinem Benutzerkreis ausgegangen werden muss, der mehrheitlich wenig mit demComputer zu tun hat. Die Benutzer wollen lediglich ein Fahrzeug buchen, unddurfen nicht durch schlecht bedienbare Software o. a. gezwungen werden, sichlanger als notig damit zu beschaftigen.

2.5. Ergebnisse 25

Die Norm ISO/IEC 9126-1”Software Engineering – Product Quality“ ist maßge-

bend fur Qualitatsanforderungen an Software (s. [Jac], [usa]). Sie definiert Soft-warequalitat als die Eignung, die Aufgaben zu erfullen, fur die sie erstellt wurde.Die Kriterien sind:

� Funktionalitat – functionality: Die Anwendung muss technisch die Auf-gaben angemessen und richtig erledigen.

� Zuverlassigkeit – reliability: Es sollen keine technischen Fehler auftre-ten, Benutzungsfehler sollen toleriert werden und leicht korrigierbar sein.

� Verwendbarkeit – usability: Das System soll leicht verstandlich underlernbar sein.

� Effizienz – efficiency: Die Aufgaben sollen angemessen schnell und mitmoglichst wenig Verbrauch von Ressourcen wie z. B. Rechenzeit und Spei-cherplatz durchgefuhrt werden.

� Pflegbarkeit – maintainability: Die Anwendung muss gut dokumentiertund im Ablauf leicht nachvollziehbar sein und sich problemlos andern lassen.

� Portierbarkeit – portability: Es soll moglich sein, das System an andereGegebenheiten anzupassen und es gegebenenfalls auch zu ersetzen.

Die Hauptforderung der Umfrageteilnehmer war, dass das Portal eine einfacheSprache benutzen soll, auch Ubersichtlichkeit und eine gute Benutzerfuhrungwurden in diesem Zusammenhang gewunscht. Dies ist zwar einerseits eine An-forderung an die Benutzerschnittstelle, jedoch fallt diese Forderung auch in denBereich der Qualitat und kann unter

”Verwendbarkeit“ eingeordnet werden. Dies

war die meistgenannte Anforderung in der Umfrage, ohne dass direkt oder indi-rekt danach gefragt oder darauf angespielt worden ware. Daraus ist ersichtlich,dass dies den Benutzern sehr wichtig ist.

Ebenfalls im Bereich Verwendbarkeit angesiedelt ist die Forderung nach mehr Un-terstutzung des Benutzers bei der Eingabe des Datums. Der Hauptkritikpunktwar, dass nach Eingabe des Beginns der gewunschten Buchungszeit nicht automa-tisch die Endzeit auf einen Wert gesetzt wurde, der zeitlich hinter dem Beginn derBuchung liegt. So mussten Benutzer die im Bestandssystem etwas umstandlicheAuswahl des Datums doppelt durchfuhren.

2.6. Reflexion der Umfrage 26

2.6 Reflexion der Umfrage

Die Umfrage hat in etwa soviel Resonanz gebracht wie angenommen, obwohlkein finanzieller Anreiz wie ein Gewinnspiel o. a. geboten wurde. Die Motivati-on der Teilnehmer musste also sein, dass ihre Meinung bei der Erstellung derneuen Oberflache einbezogen wird. Infolgedessen ist anzunehmen, dass die mitdem Status Quo zufriedenen Kunden von Stadtmobil Hannover seltener an derUmfrage teilgenommen haben. Dies scheint auch tatsachlich so gewesen zu sein,denn die allgemeine Zufriedenheit mit der Weboberflache wird auch bei den re-gelmaßigen Meinungsumfragen der Firma abgefragt, und diese lag (in Anlehnungan das Schulnotensystem von 1: sehr gut bis 5: mangelhaft) in der Vergangenheitzwischen 1 und 2. Wenn man die generelle Zufriedenheit der Umfrageteilnehmerauf diese Skala umrechnet, liegt sie bei 2,3 – die Diskrepanz ist offensichtlich.

Der Drop-Out bis zur zweiten Frage (also die Anzahl der Teilnehmer, die entwedernur die Begrußungsseite angeschaut oder nur die erste Frage abgeschickt haben,aber keine weitere) lag, wie auch aus Tabelle 2.1 ersichtlich, bei knapp 30% –12,3% schauten sich nur die erste Seite an, und 17,4% kamen nur bis zur zweitenSeite und sandten dort die Antwort auf die erste Frage ab. Der Drop-Out uber diegesamte Umfrage (14 Fragen) lag mit 42,4% relativ betrachtet erstaunlich niedrig,wenn man sich die obigen Drop-Out-Raten bei den ersten zwei Fragen anschaut.Insbesondere zwei Grunde konnten fur diese Zahlen verantwortlich sein:

1. Es gab keinen außeren Anreiz fur eine komplette Teilnahme. Das Interesseder Kunden musste durch die ganze Umfrage dadurch gehalten werden,dass die Ergebnisse in die neue Weboberflache einfließen wurden; dies istoffenbar nur zum Teil gelungen.

2. Die Befragung hatte nur kurze erlauternde Texte und benutzte eine ehertechnische Sprache. Nach dem Gesamteindruck der Antworten scheinen die-jenigen, die tatsachlich die ganze Umfrage ausgefullt haben (oder zumindestmehr als eine Frage beantwortet haben), einigermaßen technisch versiert zusein. Es konnte also sein, dass manche Teilnehmer von der Nuchternheitder Darstellung und den technischen Fragestellungen abgeschreckt wurden.

In [RB01] (Seite 210) wird von einer im Rahmen einer Studie durchgefuhrtenUmfrage berichtet, bei der ohne finanziellen Anreiz 48% Drop-Out festzustellenwar, jedoch fiel dieser Wert auf 20,7%, wenn die Teilnehmer einen Scheck uber$ 20 bei Ruckgabe des Fragebogens erhielten. Allerdings ist auch zu erwagen,dass der finanzielle Anreiz den Wahrheitsgehalt der Antworten mindern kann,namlich dann, wenn nur um des Geldes willen teilgenommen wird, ohne dass diePerson eine qualifizierte Meinung zum Umfragethema hat.

2.6. Reflexion der Umfrage 27

Verschiedentlich haben Teilnehmer der hier durchgefuhrten Umfrage auch daseigentliche Thema aus den Augen verloren und generelle Anregungen in die Ant-wortfelder geschrieben. Z. B. wurden die Abschaffung der Stornokosten und dieBereitstellung eines bestimmten Fahrzeugtyps an einem bestimmten Stellplatzvorgeschlagen. Diese Anregungen haben zwar nicht zu den Anforderungen an dieneue Weboberflache beigetragen, sie wurden aber an Stadtmobil weitergegeben.

Die im Abschnitt 2.4.3.2 geplante Anpassung der Prioritaten nach der Kundenzu-friedenheit mit bestimmten Bereichen der Online-Buchung kann nur in geringemUmfang durchgefuhrt werden, da die Zufriedenheit in den einzelnen Bereichennur wenig vom Durchschnitt abweicht (maximal 11%, in vielen Bereichen aberdeutlich weniger). Auch kann die Prioritat nur angehoben werden, und zwar inBereichen, die schlecht bewertet wurden; die Bereiche, die momentan von denKunden als gut empfunden werden, durfen durch diese Anpassung keine niedrige-re Prioritat erhalten! Solch ein Vorgehen wurde die bestehenden Vorteile zunichtemachen.

Im Wesentlichen hat die Umfrage die vorher bereits fixierten Anforderungen vonStadtmobil und cantamen bestatigt, jedoch auch in einigen Bereichen neue Ideenangestoßen, z. B.

”das System zeigt Preise bei geschatzter km-Eingabe direkt im

richtigen Benutzertarif an“. Das Bestandssystem hat einen externen manuellenTarifrechner, der etwas schwerfallig zu bedienen ist. Dies wurde von vielen Um-frageteilnehmern moniert. Die tatsachlichen Kostendaten werden derzeit schonintern berechnet, sie mussen nur wahrend des Buchungsprozesses angezeigt wer-den, um diesen Kundenwunsch zu erfullen.

Der Drop-Out-Wert auf den ersten zwei Seiten der Umfrage konnte auch einer-seits auf die graphische Gestaltung der Umfrageseiten oder andererseits auf dasdoch zu geringe Interesse an der Verbesserung der Webbuchung zuruckgefuhrtwerden. Im ersten Fall sollte im Vorfeld mehr Gewicht auf die graphische Aufbe-reitung gelegt werden, damit die Umfrage die potenziellen Teilnehmer gleich abder ersten Seite anspricht. Im zweiten Fall konnte ein finanzieller oder anderwei-tiger Anreiz geboten werden, wobei im Einzelfall zu prufen ware, inwieweit diesdie Datenqualitat negativ beeinflusst.

Moglich ist auch, dass die Umfrage mit zehn separaten Seiten als zu lang emp-funden wurde und dass deswegen schon am Anfang die Teilnahme abgebrochenwurde. Eine mogliche Losung dieses Problems ware, die Umfrage zu straffen,wobei dann aber weniger auf Details eingegangen werden konnte (siehe auch Ab-schnitt 2.7.2).

2.7. Methodische Bewertung 28

2.7 Methodische Bewertung

Nachdem im Zuge dieser Arbeit eine Online-Umfrage durchgefuhrt wurde unddie Ergebnisse in den Prozess der Anforderungserhebung mit eingeflossen sind,sollen auch einige generelle Aussagen zur Sinnhaftigkeit und Nutzlichkeit dieserMethode gemacht werden. Dieser Abschnitt wird die gesammelten Erfahrungenverallgemeinern und so auch in anderen Bereichen anwendbar machen.

2.7.1 Grundsatzliche Uberlegungen

Die Erhebung von Anforderungen durch eine Online-Umfrage passt besondersgut, wenn geplante oder bereits in der Vorversion realisierte Eigenschaften desSystems von einer großen Zahl von Stakeholdern bewertet werden sollen. Dabeiunterscheidet man zwischen Multiple-Choice- und offenen Fragen. Erstere sollendem Teilnehmer die Moglichkeit geben, in einem vorgegebenen Raster Bewer-tungen abzugeben, letztere erwarten eine Eingabe von Freitext oder zumindestvon Stichworten. Besonders bei der Verwendung vieler offener Fragen muss derTeilnehmer ausreichend motiviert sein, an der Umfrage komplett teilzunehmen,sonst konnte er aus Zeitgrunden irgendwann die Befragung abbrechen, denn of-fene Fragen brauchen mehr Zeit zum Beantworten. [Rup04]

Es sollte bei der Konzeption einer Umfrage bedacht werden, dass die neutraleAuswertung der Antworten auf offene Fragen manchmal schwer fallt. Selten sinddie Kernaussagen von Freitextantworten auf den ersten Blick ersichtlich und inkeiner Weise mehrdeutig; teilweise wird auch viel Text in ein Feld eingegeben, unddie Analyse und Einordnung der tatsachlichen Aussage dauert lange. Daher sollteman vorgegebene Antworten verwenden, wo es moglich ist, und offene Fragensparsam einsetzen.

Bei manchen Umfragen gibt es einen eingegrenzten Teilnehmerkreis, bei anderenkann jeder teilnehmen. Wenn der Kreis begrenzt ist, ist es auch die maximaleTeilnehmerzahl. In diesem Fall kann ein Quorum festgelegt werden, das die Um-frage mindestens erreichen soll – dies ist sinnvoll in Verbindung mit Uberlegungenzur statistischen Reprasentativitat der Ergebnisse.

Eine Online-Umfrage macht zudem auch nur Sinn, wenn die zu befragenden Sta-keholder mit diesem Medium hinreichend vertraut sind, z. B. wenn das zu bewer-tende System eine Webseite ist oder falls man sich anderweitig versichern konnte,dass die Benutzer das Medium WWW akzeptiert haben. In der Vergangenheitspielte haufig das Alter eine Rolle im Zusammenhang mit dem Vertrautheitsgradmit neuen Medien, dies tritt jedoch zunehmend in den Hintergrund, da vielealtere Menschen den Umgang damit inzwischen erlernt haben.

2.8. Tests 29

2.7.2 Empfehlungen

Die hervorzuhebende Empfehlung ist, nicht allein und auch nicht primar auf ei-ne Online-Umfrage als Mittel zur Anforderungserhebung zu bauen. Es solltenzusatzlich – und idealerweise bevor die Umfrage konzipiert wird – andere Metho-den benutzt werden, um grundlegende Anforderungen festzulegen. Insbesonderebei Projekten, die als Endprodukt eine von vielen einzelnen Kunden benutzteSoftware haben, erscheint es sinnvoll, zunachst die Auftraggeber zu befragen unddanach evtl. die Anforderungen durch eine Umfrage bewerten oder verfeinern zulassen.

Nach [RB01] (Seite 214ff.) kann es zu kleineren Drop-Out-Zahlen fuhren, die de-mographischen Fragen am Anfang zu haben, daher sollte eine solche Umstellungfur zukunftige Untersuchungen dieser Art erwogen werden.

Es konnte außerdem sinnvoll sein, zwei verschiedene Versionen einer Umfragefur die Teilnehmer bereitzustellen. Dabei konnte die erste Umfrage sehr kurz sein(z. B. nur eine Frage) und in eine Webseite eingebunden werden. Diese eine Frageist an sich noch keine vollwertige Umfrage, sondern eher eine im WWW ublicheund haufig verwendete Kurzumfrage. Wenn ein Benutzer die Frage beantwortet,konnte er auf eine ausfuhrlichere Umfrage zu diesem Thema hingewiesen werden.Hat er genug Interesse, wird er vermutlich auch diese ausfullen, wenn jedochnicht, ist zumindest die Antwort auf die erste Frage bekannt.

Zusatzlich zu rein textbasierten Fragen konnten auch Vorschaubilder der geplan-ten Features mit in die Umfrage eingebaut werden, um durch die so hergestellteKonkretheit den Benutzer noch intensiver am Entstehungsprozess des neuen Sys-tems zu beteiligen.

2.8 Tests

Um die Einhaltung der formulierten Anforderungen zu uberprufen, mussen Test-falle definiert werden, anhand derer verifiziert werden kann, dass sich das Systemden Anforderungen entsprechend verhalt. Es gibt verschiedene Moglichkeiten,Testfalle zu definieren (s. [Rup04] Kap. 12). In dieser Arbeit soll die konkretenaturlichsprachliche Art zum Einsatz kommen, bei der die Ausgangssituation,das Ereignis (auch

”trigger“ genannt) und das erwartete Ergebnis auf der Ba-

sis von tatsachlichen, konkreten Daten in wenigen Satzen beschrieben werden.Das Ereignis ist hierbei typischerweise eine Benutzereingabe oder das Eintreffeneiner Nachricht von einem anderen System. Durch dieses Ereignis soll das anfor-derungskonforme Verhalten des Systems ausgelost werden, welches das erwartete

2.8. Tests 30

Ergebnis bringt.

In der Softwarebranche ist es ublich, Vorab-Versionen des Endproduktes zuersteiner kleinen Gruppe von Alpha-Testern und danach einer großeren Gruppe vonBeta-Testern zur Verfugung zu stellen. Das Feedback fließt wahrend des gesam-ten Testzeitraumes in die Weiterentwicklung ein. Aus Zeitgrunden ist es nichtmoglich, eine Beta-Testphase zu realisieren, jedoch ein Alpha-Test wird parallelzur Finalisierung von Mitgliedern der Stadtmobil-Gruppe durchgefuhrt. Die Fir-ma cantamen hat das noch unfertige erweiterte Kundenportal mit Integration desWeb-Kartendienstes in die regelmaßigen Veroffentlichungen aufgenommen, somitsind prinzipiell alle Kunden von cantamen imstande, die Software zu testen. Eswurden jedoch nur wenige Personen auf diese Moglichkeit hingewiesen, um Fehlerzu beseitigen und alle vorgesehenen Funktionen einzubauen, bevor eine großereGruppe (entsprechend eines Beta-Testes) Erfahrungen sammelt.

Es ware wunschenswert gewesen, diejenigen Personen erneut befragen zu konnen,die an der Online-Umfrage (siehe Abschnitt 2.4.3) teilgenommen haben. Jedochwurden aus Datenschutzgrunden alle Abgaben anonymisiert gespeichert, sodassdiese Moglichkeit ausschied. Stattdessen sollen uneingeweihte Versuchspersoneneinfache Aufgaben mit dem neuen Portal erledigen, ohne vorher eingewiesen wor-den zu sein (siehe Abschnitt 4.4.3).

2.8.1 Testdatenbestand

Um die Konkretheit zu gewahrleisten, mussen bestimmte Daten wie Benutzerkon-ten und Fahrzeugdaten im System vorhanden sein. Es soll bewusst ein einfacherDatenbestand definiert werden, um die Tests uberschaubar und leicht uberprufbarzu halten. Das folgende Diagramm veranschaulicht im Zusammenhang mit demKlassendiagramm (Abbildung 3.4) den initialen Zustand der verwendeten Test-daten. Obwohl die Konkretheit der hier angefuhrten Daten die strikten Grenzender verschiedenen Projektphasen verletzen, erscheint es sinnvoll, sie schon hierals im eigentlichen Sinne zu den Anforderungen gehorend darzustellen.

2.8. Tests 31

Abbildung 2.5: Testdaten

Die grau hinterlegten Elemente werden nicht als Attribute, sondern nur als Be-merkungen verwendet, d. h. der Benutzer kann nicht danach suchen, sortierenoder selektieren, sondern sie werden nur angezeigt. Außerdem wurden aus Platz-und Ubersichtlichkeitsgrunden erstens samtliche GeoData- und GeoCoordinates-Elemente und zweitens auch folgendes im Diagramm weggelassen:

2.8. Tests 32

Vehicle”rotes Auto“ — Product

”Produkt 1“ — Type

”Typ 1“

Vehicle”grunes Auto“ — Product

”Produkt 2“ — Type

”Typ 2“

Booking”gestern“ — Period

”gestern, 2 Stunden“

Booking”gestern“ — Costs

”10 e“

Booking”heute“ — Period

”heute, 2 Stunden, laufend“

Booking”heute“ — Costs

”15 $“

Booking”morgen“ — Period

”morgen, 2 Stunden“

Booking”morgen“ — Costs

”10 e“

Wie man schon an den Period-Objekten sehen kann, sind alle drei auftretendenArten von Buchungen in den Testdaten prasent: komplett in der Vergangenheit,gerade laufend und komplett in der Zukunft. Dadurch konnen alle Moglichkeitengetestet werden, Buchungen zu bearbeiten.

2.8.2 Testfalle

In diesem Abschnitt werden exemplarisch Testfalle fur zwei funktionale Anforde-rungen abgeleitet. Die Testfalle bestehen jeweils aus mehreren Black-Box-Tests,d. h. eine Funktionalitat wird dadurch getestet, dass Benutzereingaben getatigtwerden und das sichtbare Ergebnis beobachtet wird. Bei der Erstellung der Testsmussen nach [Rup04] die folgenden erwunschten Eigenschaften besonders beach-tet werden:

� Durchfuhrbarkeit: Der Test muss moglich und mit vertretbarem Aufwandausfuhrbar sein.

� Messbarkeit: Es muss (durch wie auch immer geartete Methoden) feststell-bar sein, ob ein Test erfolgreich war.

� Reproduzierbarkeit: Jeder Test muss bei jeder Durchfuhrung bei gleichenVoraussetzungen das gleiche Ergebnis bringen.

� Vollstandigkeit: Die Tests zu einer Anforderung mussen den ganzen Ein-flussbereich dieser Anforderung abdecken.

� Minimalitat: Es soll insgesamt keine Redundanz und keine fachlich irrele-vanten Tests geben.

Es ist klar, dass nicht fur jede Anforderung ihre Einhaltung durch einfache Black-Box-Tests verifiziert werden kann. Auch ist es nicht praktikabel (und in manchen

2.8. Tests 33

Fallen auch gar nicht moglich), alle Eventualitaten durch einen solchen Test ab-zudecken, so z. B. wenn gefordert wird, dass eine mogliche Anzahl von Objek-ten

”nur vom verfugbaren Speicherplatz begrenzt“ wird. Wenn dies durch einen

Black-Box-Test erschopfend getestet werden sollte, musste entweder dem Systemein sehr kleiner Speicherplatz zur Verfugung gestellt werden, sodass dieser schnellerschopft ware (ein solches Vorgehen wurde dem Test die Aussagekraft nehmen),oder der verfugbare Speicherbereich ware groß und die mogliche Anzahl folglichhoch und der Test wurde manuell viel Zeit erfordern oder er musste automati-siert werden, welches jedoch auch erhohten Aufwand mit sich brachte. Eine solcheForderung sollte, je nach Erfordernissen, mit einer

”vernunftigen“ (oder

”wahr-

scheinlich maximal benutzten“) Anzahl von Objekten getestet werden, oder esmuss ein Code Review durchgefuhrt werden, durch den anhand der Implemen-tierung gezeigt wird, dass die Anzahl lediglich durch den verfugbaren Speicherbegrenzt ist.

Im folgenden sollen nun die Black-Box-Tests zu zwei Anforderungen dargestelltwerden.

2.8.2.1 Favoriten

Anforderung: es gibt eine nur vom verfugbaren Speicherplatz begrenzte An-zahl vom Benutzer definierbarer Favoriten (Adressen fur Umkreissuche und/oderFahrzeug-Standorte), die bei Buchungen zur Auswahl angeboten werden

Test 1

Ausgangssituation: Der Benutzer”1000“ ist angemeldet, hat eine neue Bu-

chung begonnen und dazu nach der Adresse”An der Lutherkirche, Hanno-

ver“ gesucht.

Ereignis: Der Benutzer fugt die Position”An der Lutherkirche, Hannover“ mit

dem Titel”Lutherkirche“ zu seinen Favoriten hinzu.

Erwartetes Ergebnis: Der Favorit wird dauerhaft fur diesen Benutzer gespei-chert, und die Favoritenliste andert sich, sodass die neue Position als Aus-wahlmoglichkeit erscheint.

Test 2

Ausgangssituation: Der Benutzer”1000“ ist angemeldet, hat eine neue Bu-

chung begonnen und dazu nach der Adresse”An der Lutherkirche, Hanno-

ver“ gesucht.

2.8. Tests 34

Ereignis: Der Benutzer fugt den gefundenen Stellplatz”Vordere Schoneworth“

mit dem Titel”nahe Lutherkirche“ zu seinen Favoriten hinzu.

Erwartetes Ergebnis: Der Favorit wird dauerhaft fur diesen Benutzer gespei-chert, und die Favoritenliste andert sich, sodass der neue Stellplatz als Aus-wahlmoglichkeit erscheint.

Test 3

Ausgangssituation: Test 1 und 2 sind erfolgreich durchgefuhrt worden, und derBenutzer hat entweder eine neue Buchung gestartet oder eine vorhandene,komplett in der Zukunft liegende Buchung zum Bearbeiten geoffnet.

Ereignis: Der Benutzer wahlt den Favoriten”Lutherkirche“ aus.

Erwartetes Ergebnis: Die Liste der Buchungsvorschlage wird aufsteigend nachder Entfernung zur Adresse

”An der Lutherkirche“ sortiert.

Test 4

Ausgangssituation: Test 1 und 2 sind erfolgreich durchgefuhrt worden, und derBenutzer hat entweder eine neue Buchung gestartet oder eine vorhandene,komplett in der Zukunft liegende Buchung zum Bearbeiten geoffnet.

Ereignis: Der Benutzer wahlt den Favoriten”nahe Lutherkirche“ aus.

Erwartetes Ergebnis: Die Liste der Buchungsvorschlage wird aufsteigend nachder Entfernung zum Stellplatz

”Vordere Schoneworth“ sortiert. Dabei er-

scheinen die direkt an diesem Stellplatz positionierten Fahrzeuge ganz oben.

2.8.2.2 Filterung

Anforderung: der Benutzer kann uber die von EBuS unterstutzten Fahrzeugpa-rameter selektieren, und die benutzten Filter werden sichtbar markiert und sofortauf die Vorschlagsliste angewendet

Test 1

Ausgangssituation: Der Benutzer”1000“ ist angemeldet und hat entweder eine

neue Buchung begonnen oder eine vorhandene, komplett in der Zukunftliegende Buchung zum Bearbeiten geoffnet.

2.9. Zusammenfassung 35

Ereignis: Der Benutzer klickt auf das Selektionsfeld fur die Fahrzeugeigenschaft

”grune Lackierung“.

Erwartetes Ergebnis: Das Selektionsfeld wird optisch als aktiviert dargestelltund die Vorschlagsliste enthalt nur noch das Fahrzeug

”grunes Auto“.

Test 2

Ausgangssituation: Test 1 ist erfolgreich durchgefuhrt worden.

Ereignis: Der Benutzer klickt nun zusatzlich auf das Selektionsfeld fur die Fahr-zeugeigenschaft

”rote Lackierung“.

Erwartetes Ergebnis: Das Selektionsfeld wird ebenfalls optisch als aktiviertdargestellt und die Vorschlagsliste enthalt Eintrage fur

”rotes Auto“ und

”grunes Auto“.

Test 3

Ausgangssituation: Der Benutzer”1000“ ist angemeldet und hat entweder eine

neue Buchung begonnen oder eine vorhandene, komplett in der Zukunftliegende Buchung zum Bearbeiten geoffnet.

Ereignis: Der Benutzer klickt auf das Selektionsfeld fur den Fahrzeugtyp”Typ

1“.

Erwartetes Ergebnis: Das Selektionsfeld wird optisch als aktiviert dargestelltund die Vorschlagsliste enthalt nur noch das Fahrzeug

”rotes Auto“.

2.9 Zusammenfassung

In diesem Kapitel wurden die Stakeholder benannt und die Projektziele wurdenerlautert. Zentral war die Erhebung der Anforderungen an das zu entwickelndeSystem, dabei stand im Vordergrund, wie die Online-Umfrage mitgewirkt hat,die Anforderungen zu verfeinern und zu priorisieren. Es wurde beispielhaft einUse Case entwickelt, welcher eine bestimmte funktionale Anforderung noch bes-ser veranschaulichte, und die Ergebnisse der Umfrage wurden bewertet, um diezukunftige Verwendung dieses Mittels zu erleichtern. Schließlich wurden exem-plarisch einige Tests aus Anforderungen abgeleitet, um die Umsetzung spaterkontrollieren zu konnen.

Kapitel 3

Konzept

Fast jede großere Aufgabe kann, um sie einfacher losen zu konnen, in mehrereUnteraufgaben aufgeteilt werden. Ebenso wird bei Software ublicherweise eineAufteilung in Komponenten vorgenommen, die miteinander kommunizieren unddie zusammen das Gesamtsystem darstellen. In diesem Kapitel soll eine solcheAufteilung vorgenommen werden, insbesondere ist dabei wichtig, dass jede Kom-ponente ein klar umrissenes Aufgaben- bzw. Anwendungsgebiet hat. Außerdemmuss geregelt werden, welche Daten wo gespeichert werden, und uber welcheSchnittstellen sie weitergegeben werden.

Das Konzept umfasst außerdem die verwendeten Mechanismen, um Daten zu fil-tern oder anderweitig zu verandern, um sie im konkreten Fall nutzbar zu machen.Als wichtiges Element ist hierbei besonders die Suche nach kurzesten Wegen unterBeachtung großerer geographischer Hindernisse zu sehen (vgl. Abschnitt 3.3).

3.1 Architektur

Gerade bei der Strukturierung von Software konnen durch Anwendung von Stan-dard-Prinzipien einige Fehler von vorneherein unmoglich gemacht werden. DavidLorge Parnas hat schon vor Jahrzehnten das heutzutage nicht mehr aus der Soft-wareentwicklung wegzudenkende Prinzip des

”Information Hiding“ etabliert; dies

besagt, dass Einheiten von Software als Black Boxes fungieren, d. h. dass sie nachaußen nur Schnittstellen zur Verfugung stellen, um sie nutzen zu konnen, die kon-krete Implementierung jedoch versteckt ist.

Jeder Softwarearchitekt kann dieses Prinzip im großen wie im kleinen umsetzen;in einer objektorientierten Programmiersprache sollte es sowohl in jeder Klasse

3.1. Architektur 37

angewendet werden als auch in den großeren Komponenten einer Software, diemiteinander uber APIs kommunizieren.

Abbildung 3.1: Alte 3-tier-Architektur

In der vorliegenden Arbeit wurde das Frontend einer vorhandenen 3-tier-Architek-tur ausgetauscht, bei der Frontend und Logikschicht bisher nicht sauber voneinan-der getrennt waren: Das in PHP realisierte EWI (EBuS Web Interface) kommuni-zierte uber eine Klartext-Befehlsschnittstelle auf Request-Response-Basis (siehe[Hil99] fur Einzelheiten zum Protokoll) mit der Logikschicht. Diese Schnittstellewar EBuS-spezifisch, da die einzelnen Befehle auf die Geschaftslogik von EBuSabzubilden waren. Im Zuge dieser Arbeit wurde EWI durch ECWI (EBuS Cars-haring Web Interface) ersetzt, wobei allerdings ECWI auch vollstandig getrenntvon EBuS einsetzbar ist. Es setzt lediglich voraus, dass eine definierte Schnitt-stelle vom Kommunikationspartner zur Verfugung gestellt wird. Die in diesemInterface definierten Methoden sind grobschrittiger und uberlassen es der kon-kreten Implementierung, eventuell notige Geschaftslogik zusatzlich einzubauen.

Zwei der wichtigen technischen Anforderungen sind, dass das System in einemeinbettbaren Java Servlet Container lauft, der die Servlet-Spezifikation in derVersion 2.3 unterstutzt, und dass das System ein Toolkit verwendet, um eineAJAX-Oberflache anzubieten. Dies impliziert, dass das Toolkit ebenfalls auf demo. g. Servlet Container lauffahig sein muss. Im Zusammenhang damit wird esdurch das Thema der Arbeit (Integration eines Web-Kartendienstes) notig, dassder Web-Kartendienst mit dem Toolkit harmoniert (mehr Informationen uber dieAuswahl des Frameworks in Abschnitt 3.5).

Aus der Abbildung 3.2 ist ersichtlich, welche verschiedenen Komponenten zusam-menwirken sollen, um die Prasentationsschicht zu ergeben, und es wird deutlich,dass samtliche Kommunikation uber eine kleine Menge von Klassen und Interfacesgeregelt wird, das Carsharing Web Interface Framework, kurz

”CWI-Framework“.

Der allgemeine Name bereits macht deutlich, dass es hierdurch moglich seinsoll, dass beliebige Carsharing-Anwendungen als Logikschicht verwendet werdenkonnen.

3.2. Datenorganisation 38

Abbildung 3.2: Neue Frontend-Ebene

Die Komponente ECWI ist die Hauptkomponente in der Frontend-Schicht. ECWIbedient sich der Hilfe des AJAX-Frameworks zur Darstellung der Oberflache undzusatzlich zum Standardumfang noch der Webkartendienst-Erweiterung des Fra-meworks (die ihrerseits auch wieder auf dem AJAX-Framework basiert).

Die Anwendungslogik sitzt weiterhin vollstandig in der EBuS-Schicht, das In-terface kontrolliert lediglich Benutzereingaben auf Plausibilitat. Wenn jedochdie Moglichkeit einer Buchung gepruft werden soll, wird immer uber das obenerwahnte Interface eine entsprechende Anfrage geschickt.

3.2 Datenorganisation

Fur die Realisierung einer Buchungsoberflache fur Carsharing-Kunden sind Datenaus unterschiedlichen Quellen erforderlich. Erstens mussen die Kundendaten (Be-rechtigungen, personliche Einstellungen) verwertet werden, zweitens benotigt dasSystem samtliche Buchungsdaten inklusive reservierter, aber noch nicht bestatig-ter Buchungen, um neue Buchungen passend zu gestalten (gebuchte Zeitraume


fur angeforderte Fahrzeuge mussen ausgeschlossen werden), und drittens werdendurch die Integration des Web-Kartendienstes jetzt auch geographische Datenbenutzt.

In diesem Abschnitt werden die verwendeten Datenmodelle und die Datenvorhal-tungsstrategie erlautert. Insbesondere ist fur die Kommunikation mit beliebigenAnwendungsservern eine Schnittstelle entworfen worden, uber die samtliche er-forderlichen Informationen ausgetauscht werden konnen. So kann die Oberflachenicht nur mit EBuS zusammenarbeiten, sondern auch mit anderen Carsharing-Anwendungen, die diese Schnittstelle implementieren.

3.2.1 Modellierung

Das zentrale Element beim Carsharing ist die Buchung. Es gibt viele weitere wich-tige Datentypen wie Fahrzeug oder Stellplatz, aber die Buchung verbindet alleElemente und ist außerdem der geschaftskritische Teil eines Carsharing-Portals.

Das Buchungsobjekt hat verschiedene Eigenschaften: einen Status, ein zugeord-netes Fahrzeug, einen Zeitraum, den buchenden Kunden und die Kosten, dieentweder bei der Buchung entstanden sind oder die bei einer Buchung entstehenwurden. Um ein moglichst allgemeines Modell zu erstellen, sind selbst Vorschlagefur Buchungen schon als Buchungen modelliert. Vorschlage haben stets den Sta-tus Proposition. In der Abbildung 3.3 wird der

”Lebenslauf“ einer Buchung

anhand ihrer Statusanderungen veranschaulicht.


Abbildung 3.3: Zustandsdiagramm einer Buchung

Die Zustande Reserving und Reserved werden sowohl fur das Erstellen einerneuen Buchung (von Proposition kommend) als auch zum Andern vorhan-dener Buchungen (von Booked kommend) verwendet. Das erwunschte Resul-tat ist jeweils dasselbe, es soll eine Buchung mit den entsprechenden Daten imSystem abgelegt werden. Es ist der Implementierung des Backends uberlassen,ggf. bereits vorhandene Buchungen zuzuordnen. Ein anderes Ziel hat hingegendie Stornierung (hierbei soll eine Buchung zuruckgezogen werden), daher mussder Stornierungsvorgang inklusive seiner endgultigen Bestatigung uber andereZustande (Reserving Cancel und Reserved Cancel) abgewickelt werden.Der eventuell auftretende Timeout bei Reserved und Reserved Cancel sollverhindern, dass Unklarheit entsteht. Wenn beispielsweise ein Kunde eine Bu-


chung reserviert, wird dieser Zeitraum fur andere Kunden als belegt angezeigtbzw. der Zeitraum wird fur dies Fahrzeug gar nicht mehr vorgeschlagen. Solangeder Buchende jedoch seine Reservierung nicht bestatigt, hat er noch nicht gebucht(und dieser Vorgang kann ihm auch nicht in Rechnung gestellt werden). Solch einunklarer Sachverhalt soll dadurch ausgeschlossen werden, dass nach 20 Minu-ten eine Reservierung kommentarlos aufgehoben wird, sollte sie nicht bestatigtworden sein. So konnen andere Kunden das Fahrzeug wieder buchen. Bei derStornierung ist es genau andersherum, hier wird das Fahrzeug nicht freigegeben,solange die Buchung nicht bestatigterweise zuruckgezogen wurde.

Abbildung 3.4: Klassendiagramm des Datenmodells (ohne Methoden)

In Abbildung 3.4 ist das Gesamt-Datenmodell zu sehen. Die hierbei verwendeteSemantik geht etwas uber die ubliche UML-Notation eines Klassendiagrammeshinaus und bedarf somit evtl. einer kurzen Erlauterung, um vollstandig verstan-den zu werden: Eine gerichtete Assoziation zwischen zwei Klassen beginnt stets


explizit bei einem Attribut, dessen Name die Verwendung innerhalb der Klasseverdeutlicht (z. B. gibt es in der Klasse Vehicle zwei Listen von Attribute-Objekten, deren unterschiedlicher Sinn sich erst durch eine solche Notation er-schließt).

Hervorzuheben ist hierbei die Vollstandigkeit des Modells. Samtliche Daten undOperationen sind hiermit darstellbar, so dass das CWI-Framework als Bruckezwischen der Darstellungsschicht und der Logikschicht fungieren kann. Die Dar-stellungsschicht ist somit universell einsetzbar und nicht an EBuS gebunden.

3.2.2 Vorhaltung und Verteilung

Die Moglichkeiten der Datenhaltung sind:

� Buchungsdaten in EBuS, geographische Daten extern (z. B. in einer KML-Datei)

� Buchungsdaten und geographische Daten in EBuS

Fur dieses Projekt wurde die Strategie gewahlt, samtliche Daten innerhalb vonEBuS vorzuhalten und zu verwalten. So konnen sie einfach uber die in Abschnitt3.2.1 vorgestellten Datenstrukturen abgefragt und eingetragen werden, und esgibt nur einen

”Ansprechpartner“ fur das Frontend. Außerdem ist der Aufwand,

die zusatzlichen Spalten in die EBuS zu Grunde liegenden MySQL-Tabellen ein-zutragen, nicht allzu groß. Allerdings mussen die vorhandenen EBuS-Befehle soerweitert werden, dass die Geodaten ebenfalls ausgegeben werden.

Der Overhead bei KML oder anderen XML-basierten Formaten zur Speicherungvon geographischen Informationen ware uberdies sehr groß. Die eigentlichen Da-ten sind lediglich Koordinaten, also zwei Gleitkommazahlen. Bei XML-Formatenmusste außerdem zusatzlich zum eigentlichen Zugriff jedesmal ein Parser arbei-ten. Dies ist hier uberflussig und ware eine Verschwendung von Ressourcen.

Es gibt bei der zentralen Datenhaltung einen entscheidenden Nachteil: Wenn einFehler auftritt, der mit Datenverlust einhergeht, sind meist alle Daten betroffen(auch bekannt als das

”Alle Eier in einem Korb“-Problem). Dies kann jedoch in

einen Vorteil verwandelt werden: Wenn samtliche Daten an einer Stelle liegen,konnen sie auch leicht komplett gesichert oder, wie in diesem Fall gut anwend-bar, in eine Replikation der MySQL-Datenbank ubertragen werden. Eine guteDatensicherungsstrategie ist also bei diesem Konzept unerlasslich.

3.3. Suche nach kurzesten Wegen 43

3.3 Suche nach kurzesten Wegen

Fur die Suche nach den nachsten Standorten ist die Hauptanforderung, großerenHindernissen wie Seen, Flussen oder Autobahnstucken ohne Unterfuhrung aus-zuweichen. Es soll kein Routing an Straßen entlang durchgefuhrt werden, wiees bei vielen Kartendiensten im Web angeboten wird. Die Anwendung soll aufFußganger abzielen, und fur solche gibt es viel mehr Moglichkeiten, als an Straßenentlang zu gehen, z. B. gibt es haufig kleine Wege durch Reihenhaussiedlungen,und eine Fußgangerzone stellt auch kein Hindernis fur Fußganger dar, wohingegenRoutingdienste diese naturlich fur ihre Zielgruppe, die Autofahrer, als Hindernissehen. Es soll jedoch die Strecke vom Kunden zum Auto minimiert werden, undselten wird jemand mit einem Auto zu dem Auto fahren, welches er sich gemietethat.

Infolge dieser Uberlegungen wurde festgelegt, dass die Luftlinie als Naherungder Verbindungsstrecke angenommen wird, solange kein großeres Hindernis imWege ist. Die Hindernisse sind Streckenzuge, die von den Administratoren derCarsharing-Unternehmen einzugeben sind – dabei sollen Hauser etc. nicht detail-liert modelliert werden, sondern lediglich großere Barrieren wie z. B. Seen oderFlusse. Bewusst wurde nicht die Herangehensweise gewahlt, Polygone (also ge-schlossene Streckenzuge) vorauszusetzen, damit auch linienformige Hindernissewie Autobahnen oder Flusse einfach zu realisieren sind.

3.3.1 Algorithmus

Bevor der eigentliche Algorithmus durchgefuhrt werden kann, mussen einige geo-metrische Operationen auf die Menge der Barrieren angewendet werden, und zwarim einzelnen:

1. Eine Dilatation. Diese aus der Bildverarbeitung stammende Operation er-weitert eine geometrische Form an allen Randern gleichmaßig. So wer-den aus den flachenlosen Streckenzugen geschlossene Polygone mit einerkleinen Flache verschieden von 0, welche die Streckenzuge komplett ein-schließen und deren Begrenzung an jeder Stelle gleichweit vom Ursprungs-Streckenzug entfernt ist.

2. Eine Vereinigung. Alle im vorigen Schritt erzeugten Polygone, die sichschneiden, werden zu einem einzigen Polygon vereinigt.

3. Entfernung von Lochern. Samtliche Locher, die in den aus dem vorigenSchritt hervorgegangenen Polygonen auftreten, werden entfernt.


Der Sinn dieser Operationen erschließt sich beim naheren Hinsehen. Es kann ein-fach berechnet werden, ob eine Strecke eine Flache durchquert oder beruhrt, beieinem Streckenzug ist dies mit mehr Aufwand verbunden. Die Vereinigung bringtPolygone hervor, die sich nicht mehr uberschneiden – dies ist unverzichtbar, wennDeadlocks im Algorithmus aus dem Weg gegangen werden soll. Schließlich wer-den die Locher aus allen Polygonen entfernt, die eventuell im vorigen Schrittentstanden sind. Dadurch werden Fehler bei der Eingabe von Standortkoordina-ten und/oder Barrieren ausgeglichen, die sonst den Algorithmus zum Scheiterngebracht hatten. Es wird namlich ein Unterschied gemacht zwischen dem

”kreu-

zen“ eines Polygons und dem bloßen”schneiden, ohne zu kreuzen“.

Abbildung 3.5: Lagemoglichkeiten fur Strecken

In der Abbildung 3.5 stellt Fall A ein Kreuzen des Polygons und Fall B ein Schnei-den ohne Kreuzen dar. Im Algorithmus also ist die Bedingung, dass die Streckeein Polygon kreuzt (Zeile 2), fur Fall B nicht erfullt. Es ist dabei unerheblich,ob ein Sachverhalt ahnlich Fall B erst durch Operationen 2 oder 3 (siehe oben)entsteht oder ob der Ausgangspunkt unwahrscheinlicherweise so nah an einerBarriere liegt, dass er schon in Operation 1 umschlossen wird.

Nach diesen Vorarbeiten kann die Suche nach dem kurzesten Weg effizient mitder unten in Pseudocode skizzierten Routine durchgefuhrt werden. Der initialeAufruf der Routine hat die beiden Endpunkte, die Liste aller Barrieren und eineleere Punktliste als Parameter. Die Menge

”Punkte“ enthalt jeweils fur den ak-

tuellen Aufruf die Menge der bereits besuchten Zwischenstationen, so dass diesebei weiterer Rekursion nicht nochmals besucht werden, sollte sich die Moglichkeitfur den Algorithmus ergeben. Die Lange des leeren Ergebnisses ist im formalenAlgorithmus als ∞ definiert, in der Praxis kommt hierfur jedoch der maximalmogliche Wert fur den Typ der enthaltenden Variablen zum Einsatz.


1 FindeWeg(A, B, Barrieren , Punkte) {2 wenn (Strecke AB kreuzt keine Barriere aus Barrieren) {3 gib Strecke AB zurueck4 }5 wenn (A oder B ist in Punkte enthalten) {6 gib leeres Ergebnis zurueck7 }8 Barriere1 = erste auf dem Weg von A nach B gekreuzte Barriere9 C = von A aus am weitesten links liegender Punkt von Barriere1

10 D = von A aus am weitesten rechts liegender Punkt von Barriere111 Moeglichkeit1 = FindeWeg(A, C, Barrieren , Punkte + C)12 + FindeWeg(C, B, Barrieren , Punkte + C)13 Moeglichkeit2 = FindeWeg(A, D, Barrieren , Punkte + D)14 + FindeWeg(D, B, Barrieren , Punkte + D)15 wenn (Moeglichkeit1 ist kuerzer als Moeglichkeit2) {16 gib Moeglichkeit1 zurueck17 } sonst {18 gib Moeglichkeit2 zurueck19 }20 }

3.3.2 Abstandsberechnungen

Die grundlegenden Abstandsberechnungen zwischen Punkten auf der Erdober-flache werden mit der u. a. in [McG] beschriebenen Formel durchgefuhrt. Siebasiert auf dem Referenzellipsoid des World Geodetic System von 1984, auchals WGS84 bekannt, welches international anerkannt ist und z. B. auch bei denBerechnungen im Global Positioning System (GPS) Anwendung findet.

Eine Alternative ware, von einer flachen Erde auszugehen und so die Abstands-berechnung primitiv durchzufuhren. Dies Vorgehen wurde Rechenzeit einsparen,jedoch bei großeren Entfernungen auch zunehmend die Genauigkeit mindern. Die-se Moglichkeit sollte in Betracht gezogen werden, falls die Berechnungen zu vielRechenzeit erfordern, denn viele Abstande sind klein, etwa innerhalb einer Stadt.Zum Vergleich: Die Strecke zwischen Empelde Ortsausgang und der Nordosteckedes Maschsee ist nach der genaueren Formel 6310 m lang und nach der ungenaue-ren 6296 m. Zwischen Empelde Ortsausgang und Altwarmbuchen Ortsausgangliegen nach der genaueren Formel 17.667 m, nach der ungenaueren 17.628 m. Mansieht, dass der Unterschied innerhalb eines so begrenzten Gebietes fast nicht insGewicht fallt. Jedoch ist die auf dem WGS84-Ellipsoid basierende Formel allge-meingultig, und deshalb sollte sie verwendet werden, solange keine Performance-Probleme auftreten.

3.4. Wahl eines Web-Kartendienstes 46

3.4 Wahl eines Web-Kartendienstes

Als bekannteste Alternativen sind die Dienste Google Maps, Yahoo! Maps, Map-solute Map24 und Microsoft MapPoint Web Service zu nennen. Obwohl alle eineprogrammierbare Schnittstelle bieten, um Karten in eigene Seiten einzubinden,gibt es doch große Unterschiede in den Rahmenbedingungen. Etwa ist der Map-Point Web Service gar nicht kostenlos zu nutzen, sondern man muss eine Lizenzerwerben, und die kostenlosen Versionen von Map24 und Yahoo! Maps durfennicht gewerblich genutzt werden. Die technisch gesehen ahnlich gestalteten Diens-te von Google, Yahoo! und Mapsolute (alle bieten die Moglichkeit, eine Karte perJavascript einzubinden und anzupassen) sind somit rechtlich nicht mehr gleich-wertig, sondern Google allein bietet die Erlaubnis zur gewerblichen Nutzung deskostenlosen Angebots.

Obwohl es eine Alternative ist, fur das benutzte Kartenmaterial und die in An-spruch genommenen Dienste zu bezahlen, ist es doch im jetzigen Entwicklungssta-dium des Kundenportals (noch) nicht sinnvoll, eine so hohe Investition zu tatigen– viele Anbieter verlangen mehrere Zehntausend Euro jahrlich fur die Stadtplan-daten von Deutschland. Folglich wird zumindest vorerst der Web-KartendienstGoogle Maps Anwendung finden. Ebenfalls dafur sprechen eine gute Dokumen-tation und eine breite Nutzerbasis, in mehreren Foren und Newsgroups konnenProbleme so in Zusammenarbeit mit anderen Nutzern geklart werden.

3.5 Wahl eines geeigneten Frameworks

Durch die zum Einsatz kommende Serversoftware wird schon grob die Richtungvorgegeben, in der nach einem passenden Framework gesucht werden muss. Es istnicht sinnvoll, das Kundenportal von Grund auf neu zu programmieren, sondernes soll auf eine Sammlung von Klassen aufgesetzt werden, welche die grundlegen-den Darstellungsfunktionen ubernimmt.

Besonderes Augenmerk wurde bei der Auswahl des Frameworks darauf gelegt,dass die clientseitigen Javascript-Funktionen gut gekapselt werden und so dieDarstellung im Browser keiner weiteren Beachtung bedarf. Es liegt nahe, eineahnliche Funktionalitat wie bei Java Swing zu erwarten, idealerweise (wie beiSwing) auch ereignisgesteuert.

Mit dieser Herangehensweise wird die Auswahl schon stark eingeschrankt. Tat-sachlich sind nur noch zwei Frameworks in die engere Auswahl gekommen, undzwar Echo2 von NextApp und ThinWire von Custom Credit Systems.

3.6. Benutzeroberflache 47

Da die Frameworks einen beinahe identischen Leistungsumfang aufweisen, wurdedie Entscheidung durch den Bekanntheits- und Beliebtheitsgrad (soweit feststell-bar) sowie durch die Große der Entwickler- und Anwendergemeinschaft leichtzugunsten von Echo2 beeinflusst.

Es wurden einige Evaluationen durchgefuhrt, um festzustellen, auf welche Wei-se Google Maps in das jeweilige Framework integriert werden kann. Bei Echo2kam eine in den Benutzerforen auch mehrfach erwahnte Schwachstelle zu Tage,namlich die Unfahigkeit von Echo2-generierten Seiten, fremde Javascript-Dateienin den <head> der HTML-Datei einzubinden. Wahrend des Testens wurde jedocheine Losung hierfur erarbeitet (siehe auch Abschnitt 4.3.1).

3.6 Benutzeroberflache

Der Benutzerschnittstelle kommt eine herausragende Rolle in der Prasentationder Anwendung zu. Sie sollte den internen Ablauf der Applikation fur den Be-nutzer transparent erscheinen lassen und dabei in der Bedienung fuhren, ohnejedoch einzuschranken. Niemand sollte ein Handbuch lesen mussen, um mit demProgramm zu arbeiten, und dennoch wird Genauigkeit im Detail gefordert.

Das alte Kundenportal ist sequentiell aufgebaut und fuhrt den Benutzer durchmehrere Auswahlstufen (Zeitraum, Ausstattungsmerkmale, Typ, Standort) zu ei-ner Buchung. Diese Art der Benutzerhinfuhrung wird beibehalten, jedoch auf eineeinzige Seite zusammengefasst, die sich in den entscheidenden Teilen jeweils ak-tualisiert. Hinzu kommen als neue Konzepte die Einstellmoglichkeiten zur Flexi-bilitat des gewahlten Zeitraumes. Durch diese neuen Elemente kann der Benutzerbei Vorgabe eine Zeitspanne auch angeben, ob es moglich ware, den Zeitraum zuverschieben oder etwas zu verkurzen, um die anderen Wunsche an das Fahrzeugzu erfullen.

Ebenfalls neu ist naturlich die auf der Seite zentral platzierte Karte. Durch siewird dem Benutzer angezeigt, an welchen Stellplatzen Fahrzeuge zur Verfugungstehen, die seinen sonstigen eingestellten Kriterien wie Typ oder Eigenschaftenentsprechen. Abbildung 3.6 stellt dar, wie die geplante Oberflache in etwa ausse-hen soll. Die denkbare Erweiterung, eine speziell fur kleine Displays angepassteVariante der Benutzeroberflache zu erstellen, soll in dieser Arbeit nicht behandeltwerden.

Das erwunschte Vorgehen des Benutzers ist nach der Integration des Kartenele-ments nun, dass er ggf. zuerst den gewunschten Zeitraum anpasst, dann seinePosition auswahlt und moglicherweise zusatzlich erforderliche Einschrankungenmacht und so zu einer nach Anforderungs-Erfullungsgrad sortierten Liste von Vor-


schlagen gelangt. Das AJAX-Framework, welches fur die Darstellung verwendetwird, baut eine Webseite auf, deren Teile sich aktualisieren und so Anderungen desBenutzers berucksichtigen; ein Reload der gesamten Webseite tritt hingegen nieauf. Zusatzlich kann durch die Sitzungsverwaltung des Frameworks der Zustandder Benutzerschnittstelle per Session-Cookie gesichert werden, so kann der Benut-zer, nachdem er andere Webseiten besucht oder versehentlich den Zuruck-Buttondes Browsers angeklickt hat, wieder zuruckkehren und findet seine Oberflache un-verandert vor – vorausgesetzt, es ist inzwischen nicht durch eine Zeitbegrenzungdie Sitzung geloscht worden.

3.7 Zusammenfassung

In diesem Kapitel wurde der Aufbau des geplanten Systems veranschaulicht, ins-besondere in Zusammenhang mit dem Bestandssystems, es wurden die verwen-deten Datenmodelle beschrieben und in Bezug zueinander gesetzt, und getroffeneEntscheidungen bzgl. beteiligter Software wurden dargelegt. Insbesondere wurdeder Algorithmus zum Finden kurzester Wege erlautert – Beispiele der Arbeits-weise finden sich in Abschnitt 4.4.2. Schließlich wurde ein Entwurf der Benutzer-oberflache erstellt und auf die neue Bedienungsweise hingewiesen.


Abbildung 3.6: Skizze der Benutzerschnittstelle

Kapitel 4

Implementierung

Die tatsachliche Umsetzung des in den vorigen Kapiteln geplanten Systems isteine Aufgabe, die bei sorgfaltiger und vorausschauender Arbeitsweise wahrendder Anforderungserhebungs- und Entwurfsphase (der Entwurf wurde hier abge-schwacht als Konzeption durchgefuhrt) nicht mehr allzu viele Probleme bereitensollte. Jedoch erfordert gerade diese Phase der Entwicklung oft viel Zeit, da un-vorhergesehene Inkompatibilitaten oder andere außere Umstande (z. B. die zuverwendenden Nachbar- oder Legacy-Systeme) das Voranschreiten verzogern.

Es ist schon bei der Analyse der Anforderungen, insbesondere bei der Erstel-lung von Use Cases, wichtig, dass die spatere Umgebung des zu entwickelndenSystems mit in die Planungen einbezogen wird. Auch mussen die einzelnen Teiledes Systems ausreichend eigenstandig geplant werden, damit sie moglichst auchfur andere Projekte wiederverwendbar sind – insbesondere aber sollten sie jeweilseindeutig einem Zweck zuzuordnen sein. In diesem Kapitel werden die Systemum-gebung und die Komponenten des Systems beschrieben, dabei wird vorrangig aufdie technische Umsetzung eingegangen. Außerdem werden die in Abschnitt 2.8.2beschriebenen Tests durchgefuhrt und die Ergebnisse protokolliert. Den Abschlussdes Kapitels bildet eine Zusammenfassung der Funktionsweise des fertigen Sys-tems.

Der Name des als Nachfolger von EWI entwickelten Systems ist ECWI (”EBuS

Carsharing Web Interface“). Obwohl der Name eine Gebundenheit an EBuS an-klingen lasst, ist das Frontend doch unabhangig davon. Wenn es zusammen miteiner anderen Anwendungsschicht als EBuS eingesetzt wird, konnte daher eineUmdeutung des Akronyms ECWI zu

”Extended Carsharing Web Interface“ sinn-

voll sein.

4.1. Systemumgebung und Komponenten 51

4.1 Systemumgebung und Komponenten

ECWI ersetzt, wie bereits erwahnt, die Darstellungsschicht in einer 3-tier-Archi-tektur. Es benutzt Daten, die von EBuS geliefert werden, und leitet Eingabenund Festlegungen des Benutzers an EBuS weiter. Um dies zu realisieren, werdenverschiedene Programmiersprachen und mehrere angepasste bzw. selbstentwickel-te Komponenten benutzt. Da ECWI eine Webanwendung ist, wird zum Betriebaußerdem ein Applikationsserver benotigt. Hierfur kam die Jetty-Engine in derVersion 5.1.4 zum Einsatz, die in den EBuS-Server eingebunden ist.

4.1.1 Programmiersprachen

Das Projekt besitzt große Teile, die in Java 1.4 geschrieben sind, denn EBuSist in dieser Sprache geschrieben, und Echo2 erfordert ebenfalls Java. Besondershervorzuheben ist, dass der in Abbildung 3.2 mit

”ECWI“ bereichnete Bereich

komplett in Java 1.4 realisiert wurde. Wahrend des Bearbeitungszeitraumes wur-de zwar eine Umstellung des kompletten Systems auf Java 1.5 begonnen, jedochnoch nicht abgeschlossen, da dieser Schritt gut getestet sein muss und daher auchviel Zeit benotigt.

Zusatzlich sind die folgenden Sprachen und Standards zum Einsatz gekommen:

� HTML 4.01 Transitional

� CSS 2.0

� Javascript 1.5

� DOM 1.0

Sie werden in den Projektteilen benutzt, welche die Darstellung im Browserubernehmen, also in Echo2 und in der Google Maps Komponente dafur. In Java-script wurde das

”prototype“-Konstrukt eingesetzt, um eigene Objekte und das

Prinzip der Vererbung zu simulieren, obwohl diese Sprache nicht objektorientiertim eigentlichen Sinne ist.

4.1.2 EBuS

Das Elektronische Buchungs-System begann 1997 mit einem zuerst in Pythonimplementierten Serverteil und einem in Java geschriebenen Client. Die Kom-munikation lief uber Klartext-Zeichenketten, ahnlich denen, die auch heute noch


im Protokoll enthalten sind. Spater wurde der Server neu implementiert, ver-wendete jedoch aufgrund damals noch unvollstandiger Dokumentation nicht dieRMI-Technik, sondern setzte weiterhin auf ein eigenes Protokoll, welches inzwi-schen verschiedene alternative Verbindungsmethoden anbietet:

� String-basiert in ISO-8859-15

� String-basiert in UTF-8

� Java-Objekt-basiert

Jede der drei Moglichkeiten gibt es mit oder ohne SSL-Verschlusselung, und soexistieren serverseitig sechs offene Ports, uber die mit dem EBuS-Kern kommu-niziert werden kann. In jedem Fall muss man sich aber zuerst uber den Port 2990verbinden (ISO-8859-15 ohne SSL), um die restlichen Portnummern zu erfragen,denn diese sind konfigurierbar. Uber einen der auf Strings fußenden Verbindungs-wege kann man sich, in Abhangigkeit von der lokal verwendeten Zeichenkodie-rung, auch mittels telnet zum EBuS-Server verbinden. Die Kommunikation lauftnach dem typischen Request-Reply-Schema ab. Der Anfang einer typischen Kom-munikation mit EBuS sieht etwa so aus (telnet-Mitschnitt):

dbconnectiveOKmemberlogin 2 "35" "123"ACCEPTED "Christiane Janker"getallbookings -1 trueOK v(h(REMARKCOUNT =1 ASSTATE =0 SEQINORG =14 USESREALBOOKEE=false

END=d(20070504010000) _IBOOKEENR =31 BOOKEEORGOUTERNR =10001_IPLACENR =2 INSERTED=d(20070503233228) BOOKINGSTATE =3200NRINORG =19 BOOKERPRENAME =" Christine" BOOKEEGROUP =2 BOOKEETYPE="A: Kleinwagen" BOOKEENRINORG =1 MEMBERORGNAME =" OekomobilMuckelhausen" CHANGED=d(20070510230934) _IBORG =2MEMBERSUBNRINORG =-1 BOOKERNAME =" Christiane Janker" START=d(20070504000000) MEMBERORGINORG =10001 REMARKONLY=true CITY="Muckelhausen" BOOKING=b(20070504000000 20070504010000 3200NULL NULL NULL) BILLSTATE =1200 ISFINISHED=falseISCISORGANISATION=false BOOKEEORGNAME =" Oekomobil Muckelhausen"MEMBERALPHINORG ="" DISTRICT =" Zentrum/Uni" BOOKEENAME ="MUC -

OM101" PLACE =" Bahnhof" MEMBERNAME =" Christiane Janker"BOOKERSURNAME =" Janker" MEMBERORGOUTERNR =10001 HISTORYLEAD=trueMEMBERNRINORG =35 NRONBOOKEE =1 CLIENTHOST =" localhost

(127.0.0.1)" CITYABBREV ="MUC" LOGINMODE =1 BOOKINGINDEX =0ACCESSSYSTEM =1 SEQONBOOKEE =1 MEMBERGROUP =0 PROVIDER ="CWIBackend 0.1" BOOKEEGROUPNAME =" OekoMobil" BOOKEEPRODUCT ="Uher Kaanu"))

Der erste Wert in der Antwort ist jeweils eine Statusangabe, danach folgen even-tuell angefragte Daten, die auch in Strukturen wie Listen (v(...), historisch von


”Vector“) oder Maps (h(...) fur

”HashMap“) enthalten sein konnen. Andere

eigene Datentypen sind z. B. EDate (d(...)) und Booking (b(...)), wobei dieseine andere Booking-Klasse darstellt als die im CWI-Framework enthaltene undin Abbildung 3.4 verwendete. Einzelheiten des Protokolls sind in [Hil99] genauerbeschrieben, und weitere technische Details zu EBuS sind in [Hil03] nachzulesen.

Im Zuge dieses Projektes muss eine Implementation des in Abschnitt 3.1 erwahn-ten Interfaces geschrieben werden, die Methodenaufrufe intern in Folgen vonEBuS-Befehlen umsetzt, diese sendet, die Antworten verarbeitet und in der er-warteten Form (namlich als Hierarchie von Klassen aus dem CWI-Framework)als Ruckgabewert liefert.

4.1.3 Echo2

Das Echo2 Framework ist eine Sammlung von Java-Klassen, die es ahnlich wieSwing ermoglichen, eine graphische Benutzerschnittstelle zu programmieren, al-lerdings fur eine Webanwendung, das heißt, die Oberflache wird im Browser dar-gestellt. Intern ist eine Aufteilung vorgenommen wurden, welche die logischenElemente von der tatsachlichen Darstellung im Browser des Benutzers trennt, sodass es moglich ware, ohne Anderung an der Anwendung die Darstellungsebe-ne auszutauschen und statt einer Webanwendung ein normales Fenster auf demComputer des Benutzers anzuzeigen.

Besonders hervorzuheben ist, dass Echo2 ereignisgesteuert arbeitet. So werdenAnderungen an Java-Objekten uber ein Event-System an die Browser-Darstellungweitergereicht, wo sie von Javascript interpretiert werden und u. U. notwendigeAnderungen an der Oberflache durchgefuhrt werden. Der Entwickler hat somitbei der Arbeit mit Standardelementen nichts mit Javascript oder HTML zu tun;diese Ebenen sind komplett versteckt. Weitere Einzelheiten zur Funktionsweisevon Echo2 sind in [Nex] beschrieben.

Im Bearbeitungszeitraum wurde die aktuelle Beta-Version”2.1.0 beta 5“ von

Echo2 erst durch den Release Candidate 1 und wenige Tage spater durch denRelease Candidate 2 ersetzt. Die in der Implementierung zum Einsatz kommendeSoftware basiert auf dem Code von Echo2 2.1.0 RC2, der allerdings modifiziertwerden musste (siehe Abschnitt 4.3.1).

4.1.4 Google Maps Komponente fur Echo2

Um alle vorherigen Designentscheidungen umsetzen zu konnen, muss nun eineKomponente fur Echo2 hergestellt werden, die auf die oben beschriebene Art die


eigentliche Implementierung in HTML und Javascript versteckt und als Schnitt-stelle eine Java-Klasse zur Verfugung stellt. Dabei soll die Komponente nicht spe-ziell an die Bedurfnisse dieses Projektes angepasst werden, sondern auch spatereine allgemeine Anwendung in anderen Projekten ermoglichen, die das Echo2-Framework einsetzen.

Die eigentlichen Funktionen sollen bei dieser Komponente jedoch nicht selbstentwickelt werden, sondern die Funktionen in der von Google bereitgestelltenJavascript-Datei sollen benutzt werden. In herkommlichen Webseiten muss die-se Datei stets direkt zur Seiten-Ladezeit vom Google-Server hinzugeladen wer-den. Dies geschieht ublicherweise mit dem folgenden Tag, der in den <head> derHTML-Datei eingebunden wird:

<scriptsrc="http :// maps.google.com/maps?file=api&v=2&key=

abcdefg"type="text/javascript">

</script >

Wenn diese Datei mitgeladen wurde, kann uber Javascript-Funktionen eine Kar-tendarstellung initialisiert und auch spater beliebig beeinflusst werden. DieseJavascript-Aufrufe mussen uber die Wege des Echo2-Konzeptes realisiert wer-den, also ist eine Klasse GoogleMap zu erstellen, die den RenderingPeer Google-MapPeer zugeordnet bekommt. Dieser

”Partner“ ist dafur zustandig, eventuelle

Anderungen am Java-Objekt zum Client weiterzugeben und Ereignisse von derClient-Seite auch umgekehrt weiterzupropagieren.

Außerdem wird eine Javascript-Datei erstellt, die auf der Clientseite als sogenann-ter Service stets ausgefuhrt wird, wenn in der anzuzeigenden Seite ein Karten-element angezeigt werden soll. Diese Javascript-Datei gibt ihrerseits dann wiederBefehle an den Javascript-Code von Google weiter und empfangt Ereignisse vonihm. Die Kommunikation uber das Netzwerk lauft also nur zwischen dem Ren-deringPeer auf der Serverseite und der dazugehorigen Javascript-Datei auf derClientseite.

Abbildung 4.1 zeigt die Kommunikation zwischen einer Instanz der Java-KlasseGoogleMap und dem Google-Scriptcode, wobei dazwischen der RenderingPeerund der eigene Javascript-Code liegen und uber diese samtliche Nachrichten aus-getauscht werden. Es soll in diesem Beispiel der angezeigte Kartenausschnitt ver-schoben werden; dieser Befehl ergeht serverseitig uber die Methode setPosition().Diese setzt intern den Positionswert, und der im Hintergrund laufende Upda-teManager ruft infolgedessen renderUpdate() im GoogleMapPeer auf, um dieClient-Darstellung den veranderten Gegebenheiten des Server-Objekts anzupas-sen. Dieser wiederum erstellt eine Nachricht, die bei der nachsten Moglichkeit (dernachsten Anfrage des Clients, was auch immer der Grund dafur ist) an den Client-


Teil des Google Maps Komponenten gesendet wird. Dieser Teil lauft als Javascriptim Browser des Benutzers. Hier wird die Nachricht verarbeitet und schließlich diegewunschte Aktion durchgefuhrt, namlich das Verschieben des sichtbaren Aus-schnitts in der Karte. Zu diesem Zweck wird die Methode panTo() von GMap2aufgerufen. GMap2 muss aus der von Google stammenden Javascript-Datei er-stellt werden, wenn die Karte angezeigt werden soll, und verhalt sich wie einObjekt. Unter anderem wird eine Moglichkeit angeboten, Event-Handler zu regis-trieren. Diese benutzt der clientseitige Teil der Echo2-Komponente, und so wirdein Ereignis

”Kartenausschnitt wurde verschoben“ uber den Aufruf der Metho-

de moveMapEvent() signalisiert. Daraufhin wird eine diesbezugliche Nachrichtan den Server gesendet, wo entschieden werden muss, ob die Methode client-EventTriggered() aufgerufen wird (wenn die Anderung tatsachlich vom Benutzerausgeht) – die samtliche registrierten Listener dieses GoogleMap-Objektes be-nachrichtigen wurde – oder nicht (wenn dies nur eine Ruckmeldung auf eine vomServer angestoßene Aktion ist).

Abbildung 4.1: Sequenzdiagramm: Setzen eines Kartenausschnittes

Diese Implementierung halt sich an den Echo2-Standard, den darstellenden Codevon der Klasse zu trennen, welche die Logik und die Daten beinhaltet. Beide Ob-jekte sind zur Laufzeit nur uber den UpdateManager verbunden, der Nachrichtenzwischen beiden vermittelt. Insbesondere wird die Methode renderUpdate() auch

4.2. Umsetzung 56

nicht direkt von einer GoogleMap-Instanz, sondern vom UpdateManager aufgeru-fen. Dieser bekommt keinen expliziten Aufruf als Trigger, sondern er bemerkt dieVeranderung im GoogleMap-Objekt und versucht daraufhin, den Datentransferan den Client zu starten, indem er renderUpdate() aufruft.

4.2 Umsetzung

Zusammen mit der Google Maps Komponente fur Echo2 sind nun alle Voraus-setzungen fur die Implementation des eigentlichen Systems gegeben. Es musseinerseits die Anbindung an den Anwendungsserver EBuS und andererseits diegraphische Benutzeroberflache realisiert werden.

4.2.1 Anbindung an EBuS

Die Schnittstelle zu EBuS wird uber eine dort neu eingebaute Klasse namensCWIBackend zur Verfugung gestellt, die das im CWI-Framework definierte Inter-face Backend implementiert. Hier sind Methoden definiert, die in verschiedeneBereiche eingeteilt werden konnen:

� An- und Abmelden von Benutzern und Administratoren

� Abfragen globaler Daten wie Organisationen oder Website-Designs

� Abfragen von benutzergebundenen Daten wie Buchungen oder personlichenEinstellungen

� Abfragen von buchungsrelevanten Daten, z. B. mogliche Fahrzeugtypenoder Buchungsvorschlage

� Einstellen, Andern und Stornieren von Buchungen

� Andern von personlichen Einstellungen

� Administrative Funktionen wie das Andern der Geodaten eines Stellplatzes

Fur die Instanzierung der Backends wurde ein Interface BackendFactory in CWI-Framework definiert, eine Implementierung davon findet sich unter dem NamenCWIBackendFactory in EBuS. Diese Klasse wird vom EBuS-Server einmalig in-stanziert und dann bei der ersten Anfrage neuer Web-Sessions verwendet, umihnen ein Backend zuzuweisen. Konkret sind dies bei der CWIBackendFactory

Instanzen von CWIBackend.

4.2. Umsetzung 57

Um die Allgemeinheit des Ansatzes von ECWI zu bewahren, wird bei der Ini-tialisierung des EBuS-Servers, wenn der interne Jetty-Server gestartet wird, dieInstanz von CWIBackendFactory in einem Attribut des Servlet-Kontextes abge-legt. Das Servlet, welches die Anfragen der Clients entgegen nimmt (EcwiServletfur das Kunden- und EcwiAdminServlet fur das Administrationsportal), erwar-tet nun lediglich, irgendeine Implementierung von BackendFactory in seinemServlet-Kontext vorzufinden. So kann die in diesem Projekt entwickelte Benut-zerschnittstelle sehr einfach auch auf andere Systeme als EBuS zugreifen, ohnedass dafur Code in ECWI geandert werden musste – es mussen nur die beidenInterfaces BackendFactory und Backend in der neuen Anwendungsschicht imple-mentiert werden, und der Servlet-Kontext muss entsprechend prapariert werden.

Die eigentliche Kommunikation mit dem EBuS-Server findet also nur innerhalbder Klasse CWIBackend statt. Dort werden auch bestimmte Daten zwischenge-speichert, wie z. B. die existierenden Carsharing-Organisationen fur diesen Serveroder die Buchungen des aktuell angemeldeten Benutzers. Bei den Organisations-daten wird vorausgesetzt, dass sich diese Informationen nicht andern, wahrendein Benutzer angemeldet ist, die Buchungen hingegen werden nach jeder rele-vanten Anderung, die der Benutzer verlangt, neu eingelesen, um das erwarteteErgebnis der Operation zu verifizieren.

4.2.2 Algorithmus

Zum neuen Element”Karte“ gehort der ebenso mit geographischen Koordina-

ten arbeitende Algorithmus zum Finden kurzester Wege. Er wurde mit Hilfe derJTS Topology Suite von Vivid Solutions umgesetzt (siehe auch [Viv]), denn mitden dort vorhandenen Datenstrukturen lassen sich geometrische Operationen wiedie Dilatation einfach durchfuhren. Die JTS Topology Suite ist unter der LGPLveroffentlicht worden; dies ist mit den rechtlichen Anforderungen an dieses Pro-jekt kompatibel.

4.2.3 Benutzerschnittstelle

Die Oberflache wurde, wie in Zusammenhang mit dem Echo2-Framework ublich,als Erweiterung der abstrakten Klasse ApplicationInstance umgesetzt. Die ein-zige zwingend zu implementierende Methode ist init(), sie liefert ein Window-Objekt zuruck, welches den gesamten Inhalt des Client-Browsers darstellt. Esist jetzt die Entscheidung des Entwicklers, ob der Benutzer nur den Inhalt desTop-Level-Containers sieht oder ob eine imitierte Mehrfenster-Oberflache gezeigtwird. Hier fiel die Entscheidung tendenziell eher fur die erste Moglichkeit aus,

4.2. Umsetzung 58

jedoch wird dies durchbrochen fur

� Buchungs-/Stornierungsbestatigungen,

� wichtige Hinweise und

� Fehlermeldungen.

Diese Arten von Dialogen werden modal angezeigt, d. h. mit der restlichen Ober-flache (innerhalb des Browserfensters, wohlgemerkt) kann nicht interagiert wer-den, bis der Dialog geschlossen wurde. So kann in diesen Situationen die sofortigeAufmerksamkeit des Benutzers eingefordert werden. Alle anderen Daten werdennormal angezeigt, um dem Benutzer die Entscheidung zu uberlassen, welche Ele-mente er wann benutzen mochte.

Um die Oberflache bezuglich des Aussehens flexibel zu halten, wurde ein wei-teres Feature von Echo2 benutzt, und zwar die Moglichkeit, anstelle der di-rekten Zuweisung von Farben, Schriftarten etc. sogenannte Styles zu definieren– dies sind Instanzen der Klasse Style, deren Eigenschaften entsprechend desgewunschten spateren Aussehens gesetzt wurden. Den Elementen der Oberflachewerden lediglich die zentral definierten Styles zugewiesen. Es waren jedoch nichtnur die Style-Definitionen zu verwalten, sondern es mussten auch einige Bildermoglichst einfach austauschbar sein, deswegen wurde ein Interface Design ge-schaffen, dessen implementierende Klassen beliebige Objekte speichern konnensollen. Dort konnen einerseits alle Styles hinterlegt werden, aber andererseitsauch Bilder als Byte-Arrays oder Texte als Strings. Es ist vorgesehen, das Designvom Backend laden zu lassen und dann an die EcwiApp-Instanz weiterzugeben,diese Moglichkeit wurde aber aus Zeitgrunden bisher nicht durchimplementiert.Zur Zeit wird stets die Klasse DefaultEcwiDesign verwendet, die das momentaneStandard-Aussehen enthalt.

Im Laufe der Oberflachenentwicklung wurden neue Komponenten fur Echo2 durchdie Erweiterung bestehender Klassen erstellt: BookingEditor, PossibleBooking-List und PeriodEditor stammen von Column ab, BookingList von Table undPeriodDisplay von Label. Insbesondere die erstgenannte Klasse nimmt eine zen-trale Rolle ein, sowohl bei der Erstellung von neuen Buchungen als auch, wennbestehende Buchungen bearbeitet oder storniert werden sollen. Stets wird demKonstruktor die zu bearbeitende Buchung und das zustandige Backend als Ar-gument mitgeteilt. Mit den so zuganglichen Informationen kann die Oberflachedes Buchungseditors aufgebaut werden. Abhangig vom Status der Buchung sindbestimmte Elemente nicht zu bearbeiten oder ganz versteckt. Wird vom Benutzerdann eine Anderung an der Buchung gewunscht, wird diese dem Backend mitge-teilt – und bei auftretenden Problemen wird der Benutzer umgehend in Kenntnisgesetzt.

4.3. Probleme 59

Buchungen sollen aber nicht nur erstellt und editiert werden konnen, sondernKunden mussen auch Bestatigungen fur Buchungen und Stornierungen ausdru-cken konnen. Hierfur wurde eine Druckansicht implementiert, bei der jegliche Na-vigation ausgeblendet wird (bis auf einen Button

”Druckansicht schließen“. Diese

Ansicht offnet sich bewusst nicht in einem neuen Fenster, sondern verandert dasbisherige, damit keine Probleme mit den heutzutage ublichen Popup-Blockernentstehen.

Eine weitere essentielle Anforderung, die Internationalisierung der Benutzerober-flache, wurde uber einen erweiterten ResourceBundle-Ansatz verwirklicht, der inder Quarterback Java Classes Collection (QJCC)1 zur Verfugung steht. Uber einestatische Klasse kann dort der Fall abgefangen werden, dass ein ResourceBundlenicht existiert, und in diesem Fall wird keine MissingResourceException ausgege-ben, sondern der Schlussel wird als Wert zuruckgeliefert. Dieser Ansatz verhin-dert eine komplett unbenutzbare Oberflache um den Preis, dass eventuell mancheTexte merkwurdig aussehen, wenn namlich ein ResourceBundle nicht gefundenwurde. Aus Zeitgrunden wurde bisher die direkte Sprachwechselmoglichkeit nochnicht implementiert, sodass die Benutzerschnittstelle zwar bereits verschiedeneSprachen anzeigen kann, der Benutzer aber nicht zu beeinflussen vermag, welcheSprache verwendet wird.

Das Aussehen der Oberflache und die Benutzerfuhrung werden in Abschnitt 4.5aufgezeigt, unter anderem anhand von Screenshots.

4.3 Probleme

Bei der Realisierung traten immer wieder verschiedene Probleme auf. Da nichtalle genannt werden konnen, werden hier exemplarisch zwei kurz beschrieben,und die gewahlte Losung wird aufgezeigt.

4.3.1 Echo2 und fremde Javascript-Dateien

Wie in Abschnitt 3.5 beschrieben musste das Echo2-Framework leicht erweitertwerden, um uberhaupt die Moglichkeit zu bieten,

”fremde“ Javascript-Dateien zur

Ladezeit der Seite einzubinden. Es stellte sich jedoch heraus, dass die anfangsgewahlte Losung nicht ausreichend flexibel war. Der Mechanismus des Ladensaller Javascript-Dateien, deren URLs in einer Property-Datei fest vorgegebensind, bot keine Moglichkeit fur eine Portierung des Veroffentlichungspaketes auf

1eine uber SourceForge.net verfugbare Open-Source-Bibliothek

4.4. Tests 60

andere Server, ohne das Codearchiv selbst verandern zu mussen. Dies liegt darinbegrundet, dass der Web-Kartendienst Google Maps es zwingend voraussetzt,dass ein zu genau einer URL gehorender Schlussel erzeugt wird, bevor der Dienstgenutzt werden kann. Der Mechanismus musste also nochmals verandert werdenund benutzt jetzt das Backend, in dem im Vorfeld ein gultiger Schlussel fur GoogleMaps zu hinterlegen ist.

4.3.2 Timeout Management

Der EBuS-Server hat eine in das Protokoll integrierte Timeout-Behandlung, umdie Verbindung zu nicht langer aktiven Clients zu kappen. Die meist sehr knappeingestellten Werte haben verschiedentlich dazu gefuhrt, dass ein Backend dieVerbindung zum Server verlor, wahrend das Web-Interface noch benutzt wurde,nur wurden uber eine gewisse Zeitspanne keine Daten von EBuS geladen. ECWIbesitzt deshalb ein separates Timeout-Management. Das Backend sendet in be-stimmten Abstanden den Befehl NOP (no operation), wenn nichts zu tun ist, umdie Verbindung zu EBuS aufrechtzuerhalten. Damit dadurch nicht alle erzeugtenBackend-Instanzen bis zum nachsten Server-Neustart aktiv bleiben, wurde einservletbasiertes Inaktivitats-Timeout eingefuhrt, dessen Zeit in der Konfigurati-on gesetzt werden kann. Uber eine Implementation von HttpSessionListener

wird sichergestellt, dass zu jeder Session, deren Timeout ablauft, das Backendebenfalls fur die Garbage Collection freigegeben wird.

4.4 Tests

Die entwickelte Software wurde durch den ganzen Entstehungsprozess hindurchgetestet, am Anfang jede kleinere Funktion mit Ausgabe des Ergebnisses auf derKonsole, dann großere Routinen, meist ebenfalls mit Textausgabe, spater auchganze Komponenten – speziell fur die Google Maps Komponente wurde zuerst se-parat eine etwas umfanglichere Testumgebung erstellt, in der dynamisch uber an-dere Standard-Echo2-Komponenten wie Dropdown- oder Textfelder verschiedeneFunktionen aufgerufen werden konnten. So wurde diese Komponente zunachstvollig getrennt vom eigentlichen System erstellt und erst spater integriert, als siehinreichend getestet war.

Im folgenden werden einige der durchgefuhrten Tests ausfuhrlicher dokumentiert.

4.4. Tests 61

4.4.1 Von Anforderungen abgeleitete Tests

Es werden beispielhaft die Ergebnisse des ersten in Abschnitt 2.8.2.1 dargestelltenBlack-Box-Versuches beschrieben. Alle Bildschirmfotos in diesem Abschnitt sindmit den sehr simplen Testdaten hergestellt worden, die ExampleBackend enthalt.

Die Ausgangssituation Der Benutzer”1000“ ist angemeldet, hat eine neue Bu-

chung begonnen und dazu nach der Adresse”An der Lutherkirche, Hannover“ ge-

sucht. ist in Abbildung 4.2 zu sehen. Bei der Suche nach einer Adresse wird stetsder Marker der aktuellen Benutzerposition (im Bild blau mit Punkt dargestellt)auf diese Adresse gesetzt. Er ist aber weiterhin durch den Benutzer bewegbar,so kann er z. B. minimale Abweichungen bei der mit Hausnummernangabe kor-rigieren, sollte die gefundene Position im Verlauf der Straße nicht richtig sein.Auf diese Moglichkeit wird momentan nicht explizit hingewiesen, diese Funktionwerden also nur Benutzer verwenden, die mit Google Maps vertraut sind oder diediese Moglichkeit des Verschiebens durch Experimentieren herausfinden.

Abbildung 4.2: Nach dem Suchen der Adresse

Die eingegebene Adresse wird nach der Suche automatisch in das Feld fur denFavoritennamen ubernommen, so dass der Benutzer diesen Schritt nicht selbst

4.4. Tests 62

durchfuhren muss. Er kann vor dem Hinzufugen den Namen editieren, muss diesaber nicht. Das Ereignis Der Benutzer fugt die Position

”An der Lutherkirche,

Hannover“ mit dem Titel”Lutherkirche“ zu seinen Favoriten hinzu. wird da-

durch ausgelost, dass der Benutzer den Namen auf”Lutherkirche“ andert und

auf”Hinzufugen“ klickt. Abbildung 4.3 zeigt die Oberflache, nachdem dies ge-

schehen ist. Man sieht, dass der Favorit wie gewunscht als neue Wahlmoglichkeitunten in der Liste erschienen ist. Das erwartete Ergebnis Der Favorit wird dau-erhaft fur diesen Benutzer gespeichert, und die Favoritenliste andert sich, sodassdie neue Position als Auswahlmoglichkeit erscheint. ist somit eingetreten.

Abbildung 4.3: Nach dem Hinzufugen des Favoriten

Auch die Durchfuhrung der anderen in Abschnitt 2.8.2 aufgezahlten Testfallehat das erwartete Ergebnis gebracht. Es ist anzumerken, dass mit den doch sehrprimitiven Testdaten aus ExampleBackend das Testen der Oberflache nicht sogut funktioniert. Um intensive Tests durchfuhren zu konnen, sind reale Datenunerlasslich. Mit freundlicher Genehmigung von Stadtmobil Hannover werdendeshalb die aktuellen Standort- und Fahrzeugdaten fur wissenschaftliche Testszur Verfugung gestellt. Die Daten auf der beiliegenden CD-ROM ermoglichen es,einen voll funktionsfahigen EBuS-Server zu installieren und weitere Tests damitdurchzufuhren. Eine Installationsanleitung und die zu den Projekten gehorende

4.4. Tests 63

Java-API-Dokumentation ist dort ebenfalls enthalten.

4.4.2 Der Algorithmus zum Finden kurzester Wege

Zum Testen des in 3.3.1 beschriebenen Algorithmus wurde der Maschsee in Han-nover als Barriere verwendet und zusatzlich zwei weitere (fiktive) Hindernis-Streckenzuge, je einer sudwestlich und nordostlich vom Maschsee. Die Startposi-tion lag in der Sudstadt und das Ziel in Linden. Es wurden mehrere verschiedeneLagen der Start- und Zielpunkte probiert, im Folgenden sind Ausgaben des Pro-gramms gnuplot von zwei verschiedenen Startpunkten aus zu sehen. Die Darstel-lung ist leicht verzerrt, da fur diese Visualisierung von Koordinaten in der Ebeneausgegangen wurde. Außerdem wurden die Hindernisse durch die vorgenommeneDilatation starker verbreitert als im Regelbetrieb, um den Effekt besser sichtbarzu machen.

Abbildung 4.4: Ergebnis von Beispiel 1 (Startpunkt: 52.346, 9.764)

4.4. Tests 64

Abbildung 4.5: Ergebnis von Beispiel 2 (Startpunkt: 52.355474, 9.7541)

Fur das Beispiel 1 hat der Algorithmus etwa 480ms benotigt, fur Beispiel 2lag der gemessene Wert bei ca. 650ms – wenn jedoch keine Barriere zwischenStart- und Zielpunkt lag, war der Zeitbedarf weniger als 1ms, unabhangig da-von, wie viele Barrieren definiert waren. Als Testumgebung ist hierbei ein IntelPentium 4 PC mit 2,4 GHz Taktfrequenz, 1 GB Hauptspeicher, einer Prozessor-Grundauslastung von ca. 5% und das Sun Java Runtime Environment in der Ver-sion 1.5.0 11-b03 unter dem Linux-Kernel 2.6.21.1-SMP-PREEMPT zum Einsatzgekommen.

Die Entfernungsbestimmungen wurden mit der auf einem Ellipsoidmodell basie-renden Formel durchgefuhrt. Bei einer testweisen Umstellung auf das Modell ei-ner flachen Erde (Entfernungsberechnungen mit dem Satz von Pythagoras) wurdekein Unterschied im Zeitbedarf festgestellt.

4.4.3 Akzeptanztests mit Versuchspersonen

Die Kundenoberflache wurde zusatzlich so getestet, dass funf Personen aus un-terschiedlichem Umfeld, auch mit sehr wenig Erfahrung im Bereich Carsharing,je drei einfache Aufgaben mit dem neuen System erfullen sollten. Fur diese Testswurden die realen Fahrzeug- und Standortdaten von Stadtmobil Hannover ver-wendet. Die Aufgabenstellungen waren im einzelnen:

4.5. Ergebnis 65

1. Sie wohnen in der Sonderburger Str. 1 in Hannover und wollen am Samstag,dem 2. Juni 2007 nachmittags einige Mobelstucke von einem Bekannten ausBurgdorf abholen. Buchen Sie ein Fahrzeug von Stadtmobil Hannover, dasIhnen hierfur gunstig erscheint.

2. Sie wollen mit einem Fahrzeug von Stadtmobil Hannover am Nachmittagdes 11. Juni 2007 von der Mozartstraße in Hannover aus einkaufen fahren.Buchen Sie zu diesem Zweck ein Fahrzeug des Typs C (Kombi oder Kombimit Fruhling-Spezial)!

3. Ein Freund aus Hannover hat Sie gebeten, einen Anhanger bei Ihnen unter-stellen zu durfen, hat aber kein Fahrzeug, um ihn zu ziehen. Stellen Sie fest,wo von Ihrem Wohnort aus (Sonderburger Str. 1) das nachste Fahrzeug vonStadtmobil Hannover steht, mit dem dies am 19. Mai 2007 moglich ware!

Die Testpersonen haben alle Aufgaben ohne großere Probleme in kurzer Zeit losenkonnen. Einzelne Schwierigkeiten tauchten z. B. in der Bedienung der Adress-Suche auf: Es sorgte fur Irritationen, dass eine Suche lediglich nach

”Sonderburger

Str. 1“ einen Treffer in Koln-Mulheim lieferte. Daraufhin wurde die Oberflachemit weiteren erklarenden Texten und Tooltips ausgestattet. Generell wurden dieneuen Einstellungsmoglichkeiten zur Verschiebbarkeit des Buchungszeitraumesgut angenommen, vier der funf Versuchspersonen haben sie auf Anhieb verstan-den und sofort benutzt. Wenn die Testperson nicht mit der Bedienung von Web-Kartendiensten vertraut war, kamen teilweise Ruckfragen, wie man den Karten-ausschnitt verschieben konne. Insgesamt verlief dieser Test jedoch gut und zeigte,dass auch die Anordnung der Elemente in Karteikarten gut verstanden wurde.

4.5 Ergebnis

Im folgenden wird das Ergebnis beschrieben – einerseits die Buchungsoberflache,andererseits aber auch die Administrationsseite. Die Schilderung der Moglichkei-ten wird durch Screenshots erweitert und veranschaulicht, wo dies sinnvoll er-scheint.

Das neue System setzt es nicht langer voraus, dass sich Benutzer zuerst anmel-den. Dies mag unlogisch erscheinen, da nur Personen buchen konnen, die auchtatsachlich Kunden sind, aber es macht das Arbeiten mit der Oberflache flexibler,wenn direkt nach dem Laden der Seite beispielsweise eine Adress-Suche gestartetwerden kann oder wenn es sofort moglich ist, durch Zoomen in die Karte einenbestimmten Stellplatz zu lokalisieren. Es ist trotzdem moglich, sich zuerst anzu-melden, jedoch ist der Zwang aufgehoben. Der einzige Nachteil des Arbeitens als

4.5. Ergebnis 66

nicht-angemeldeter (also anonymer) Benutzer ist, dass man seine Favoriten nichtbenutzen kann.

Abbildung 4.6: Anonyme Adress-Suche und Tooltip eines Stellplatzes

Abbildung 4.6 zeigt, wie ohne vorherige Anmeldung nach einer Adresse in Han-nover gesucht worden ist. Bei der Suche wird stets die gesuchte Position in derKarte zentriert und mit einem blauen Marker versehen, welcher auch ohne erneu-te Adresseingabe einfach per Drag and Drop verschoben werden kann. Wenn eseine eigene Position in der Karte gibt, wird die Ergebnisliste unten aufsteigendnach der Entfernung zu diesem Ort sortiert. Bei der Sortierung werden die vomAdministrator eingetragenen Hindernisse (s. u.) mit berucksichtigt.

Der Benutzer kann entweder seine eigene Ausgangsposition als Sortierkriteriumverwenden lassen, wie oben beschrieben – dies ist das erwartete Verhalten fur diemeisten Benutzer – oder einen Stellplatz direkt wahlen. Im Bestandssystem istes so, dass bei einer Stellplatzwahl nur die Fahrzeuge an diesem einen Stellplatzangezeigt werden. In der neuen Oberflache werden die Ergebnisse in diesem Falljedoch nur aufsteigend nach der Entfernung zu diesem Stellplatz sortiert, alsowerden zuerst alle Vorschlage fur Fahrzeuge an diesem Stellplatz angezeigt unddanach die umliegend stationierten Fahrzeuge. So kann auch ein rot markierterStellplatz ausgewahlt werden (an dem keine Fahrzeuge den gewahlten Kriterien

4.5. Ergebnis 67

entsprechen). Es werden dann die buchbaren Fahrzeuge in der Umgebung alsBuchungsvorschlage angezeigt.

Im Zuge der Umgestaltung wurde nicht nur die Oberflache neu entworfen, son-dern auch der Algorithmus, der die Buchungsvorschlage macht. Bisher mussteder Kunde, nachdem er einen Stellplatz ausgewahlt hatte, selbst uberprufen, obdie dort stationierten Fahrzeuge frei oder (teilweise) belegt sind. Dieses Konzeptwurde durch die Moglichkeit ersetzt, den Kunden seine maximalen Zeitgrenzenselbst wahlen zu lassen, und so automatisch die besten Vorschlage machen zukonnen. In der neuen Oberflache gibt es nun die Felder

”max. . . . h fruher“ und

”max. . . . h spater“, die Einfluss auf die Vorschlagsliste haben. Wenn namlich

nahe des gewahlten Bezugspunktes (einer eigenen Position oder eines Stellplat-zes) ein Fahrzeug im gewahlten Zeitraum belegt ist, kann es eventuell eine halbeStunde spater fur die gewunschte Buchungslange frei sein. Dieser Tatsache wur-de so Rechnung getragen, und der Benutzer kann nun angeben, wie flexibel derZeitraum nach vorn oder hinten verschiebbar ist.

Intern werden den einzelnen Vorschlagen Qualitatswerte zwischen 0 und 1 zu-gewiesen, und zwar einerseits nach der geographischen Lage und andererseitsnach der Ubereinstimmung des Zeitraums. Die Vorschlage fur Fahrzeuge nahebeim gewahlten Bezugspunkt, deren Buchungszeitraum mit den Benutzervorga-ben ubereinstimmt, haben die hochste Qualitat und werden als erstes auf der Er-gebnisliste platziert. Es wird vom Algorithmus versucht, den gewunschten Zeit-raum moglichst genau zu treffen – der mogliche Zeitraum mit der geringstenprozentualen Abweichung vom gewunschten Zeitraum wird fur den Vorschlagverwendet.

In Abbildung 4.7 ist zu sehen, dass die Suche auf Fahrzeuge des Typs”D: Kom-

fort: Cabriolet“ eingegrenzt wurde. Durch die Benutzung des AJAX-Frameworkswird die Vorschlagsliste aktualisiert, sobald eine Einstellung geandert wird, unddie neuen Ergebnisse werden direkt in Zusammenhang mit der gerade durch-gefuhrten Anderung gebracht. Außerdem ist in diesem Screenshot zu Demonstra-tionszwecken das Kalenderelement aufgeklappt, mit dem der Kunde das Start-datum wahlen kann. Die Zeitraumeinstellung ist das Einzige, was nicht sofortnach einer Anderung auf die Ergebnisliste angewendet wird – dies wurde vielenutzlose Serveranfragen nach sich ziehen. Denn wenn eine der sechs Einstellun-gen (Startdatum, Startzeit, Enddatum, Endzeit und Flexibilitatseinstellungen)geandert wurde, ist es sehr wahrscheinlich, dass auch noch etwas anderes in die-ser Zeile geandert werden soll. Aus diesem Grund muss bei einer nachtraglichenAnderung des Zeitraumes auf den Button

”ubernehmen“ geklickt werden – wenn

spater noch z. B. nach einer Adresse gesucht wird, werden die Zeiteinstellungenautomatisch ubernommen.

Wenn ein Vorschlag aus der Ergebnisliste tatsachlich gebucht werden soll, muss

4.5. Ergebnis 68

Abbildung 4.7: Eingegrenzte Suche und Auswahl des Datums

der Button”Buchen!“ verwendet werden. Auf diese Absichtserklarung des Be-

nutzers hin erscheint ein Bestatigungsfenster, wie in Abbildung 4.8 gezeigt. ImHintergrund ist bereits die Liste der vorhandenen Buchungen sichtbar. Die mo-mentan zu bestatigende Buchung erscheint dort bereits, wurde aber bei einemAbbruch des Vorganges sofort wieder entfernt werden.

Der Bereich”Neuigkeiten“ bietet dem Carsharing-Anbieter die Moglichkeit, dem

Benutzer wichtige Anderungen mitzuteilen, die sich insbesondere auf den Fuhr-park beziehen. Auch Stellplatzverlegungen o. a. konnen hier veroffentlicht werden.

Fur den eigentlichen Vorgang des Buchens nicht essentiell sind die personlichenEinstellungen des Benutzers. Dennoch sollte dieser Bereich nicht vernachlassigtwerden, denn auch die hier hinterlegten Daten haben Einfluss auf die Inter-aktion des Systems mit dem Benutzer. So kann z. B. eine Benachrichtigungs-Email-Adresse hinterlegt werden und, wenn dies gewunscht wird, auch die Email-Adresse eines SMS-Gateways. An diese Adressen konnen bei neuen Buchungenoder Anderungen Nachrichten gesendet werden. Abbildung 4.9 zeigt das Aus-sehen der Seite, auf welcher der Benutzer diese Einstellungen vornehmen kann.Außerdem konnen hier die im Buchungseditor erstellten Favoriten wieder geloschtwerden.

4.5. Ergebnis 69

Abbildung 4.8: Bestatigen einer Buchung

Besonders hervorzuheben ist die Moglichkeit, eine Standard-Streckenlange zuhinterlegen. Es sind die strukturellen Voraussetzungen dafur geschaffen worden,dass jeder Vorschlag schon vor der tatsachlichen Buchung Kosten zugeordnetbekommt. Da viele Carsharing-Abrechnungsmodelle einen zeit- und einen stre-ckenabhangigen Anteil haben, muss außer der Zeit auch eine Vorgabe fur diewahrscheinlich zuruckgelegte Strecke gemacht werden. Jeder Benutzer kann in-dividuell festlegen, wie diese Vorgabe sein soll. Momentan bietet allerdings derEBuS-Kern diese Moglichkeiten noch nicht, daher wird der hinterlegte Wert nochnicht benutzt.

Die Kartendarstellung ist ein sehr wichtiger Teil der Buchungsseite fur die Kun-den, aber auch die Administration kann mit Hilfe einer Karte erheblich erleichtertwerden. Fur die Benutzung des neuen Kundenfrontends muss jede Organisationzuallererst jeden Stellplatz mit Geokoordinaten versehen. Diese Arbeit kann ma-nuell unter Benutzung von Google Maps erfolgen, jedoch wurde im Zuge derImplementierung auch eine integrierte Administrationsseite erstellt. Hier konnenganze Organisationen, Stadte, Stadtteile und Stellplatze mit einem Bereich ver-sehen werden, den Benutzer mindestens auf der Kartendarstellung sehen sollen,wenn die zugehorige Einheit ausgewahlt wird. Zusatzlich ist es naturlich erforder-

4.5. Ergebnis 70

Abbildung 4.9: Personliche Einstellungen

lich, bei Stellplatzen den genauen Punkt auf der Karte bezeichnen zu konnen. AufAbbildung 4.10 wird deutlich, auf welche Weise diese Angaben gemacht werdenkonnen: Der Standort-Marker in der Mitte kann positioniert werden, so dass erden tatsachlichen Ort prazise bezeichnet, und auch die außeren Marker konnendurch Drag and Drop angepasst werden, um den gewunschten minimalen Karten-ausschnitt zu definieren. Wenn die Bearbeitung abgeschlossen wurde, muss derButton

”Speichern“ verwendet werden, um die Eingaben in den Datenbestand zu

ubernehmen.

Die Namen der Organisationen, Stadte, Stadtteile und Stellplatze in den Listenhaben als Hervorhebung ein Sternchen vor ihrem Namen, wenn noch keine zu-gehorigen Geodaten hinterlegt wurden. So wird der Administrator bei der Durch-sicht der Daten darauf aufmerksam und kann diesem Mangel leicht abhelfen.

Schließlich muss die Eingabe von Hindernissen noch moglich sein, dies geschiehtuber die in Abbildung 4.11 gezeigte Seite des Administrationsbereiches. Hierkonnen Barrieren durch mehrfaches Klicken an die einzelnen Stationen des Stre-ckenzuges hinzugefugt werden, dabei kann der Administrator jeweils das bisherigeErgebnis sehen und die Eingabe durch den

”Speichern“-Button beenden. Ebenso

kann jede Barriere im Nachhinein bearbeitet oder auch geloscht werden.

4.5. Ergebnis 71

Abbildung 4.10: Bearbeiten eines Stellplatzes

Die Hindernisse haben zwar im Datenbestand einen Namen (zusatzlich zur immerautomatisch vergebenen ID), jedoch ist dieser nicht entscheidend und wird daherim Moment automatisch als zehnstellige Hexadezimalzahl zufallig generiert. Ineinem weiteren Schritt konnte man den Namen auch frei wahlbar gestalten.

Zusammenfassend kann man sagen, dass die Implementierung dieses Projekteszwar mehr Zeit benotigt hat als vorher veranschlagt, dass aber das Ergebnis denAufwand rechtfertigt. Es wurde ein System geschaffen, welches den Buchungspro-zess fur Carsharing-Kunden vereinfacht und so Zeit spart. Hinzu kommt, dass dieOberflache mit moderner Technologie realisiert wurde und auch unabhangig vomEBuS-Server einsetzbar ist. Es wurde bis auf EBuS und die Javascript-Datei vonGoogle Maps nur Open-Source-Software verwendet. Dies macht das entwickelteSystem auch rechtlich gesehen flexibel nutzbar.

4.5. Ergebnis 72

Abbildung 4.11: Bearbeiten eines Hindernisses

Kapitel 5

Schlussbetrachtungen

5.1 Zusammenfassung

In dieser Arbeit wurde ein Carsharing-Kundenportal so geplant und realisiert,dass es nicht nur mit dem Elektronischen Buchungs-System

”EBuS“ der Firma

cantamen zusammenarbeiten kann, sondern auch daruber hinaus allgemein ein-setzbar ist. Es wurden die Stakeholder festgestellt und die Ziele des Projekts undder Kontext definiert. Zur Erhebung der Anforderungen konnte auf Expertenwis-sen von Mitarbeitern von cantamen zuruckgegriffen werden, außerdem wurde dasBestandssystem analysiert und eine Online-Umfrage durchgefuhrt. Die Umfragehat auf der einen Seite neue Anforderungen geliefert und auf der anderen Seitegeholfen, die Prioritat bereits bekannter Anforderungen richtig einzuschatzen.

Ein wichtiger Aspekt war auch eine allgemeine Einschatzung der sinnvollen An-wendbarkeit des Mittels

”Online-Umfrage“ zur Anforderungserhebung. Hierbei

wurde festgestellt, dass nicht nur die Ergebnisse einer Umfrage herangezogenwerden sollten, sondern moglichst vor der Umfrage herkommliche Methoden aus-zuschopfen sind. Einerseits wird meist nur ein Teil der Stakeholder uber eineOnline-Umfrage erreicht, andererseits kann die Auswertung insbesondere bei offe-nen Fragen problematisch sein. Hingegen eignet sich dieses Mittel gut, um bereitsrealisierte oder geplante Eigenschaften der Software bewerten zu lassen.

Aus den gesammelten Anforderungen wurden auf systematische Weise Tests ab-geleitet. Diese konnten nach der Implementierung des Systems unter Verwendungeiner eigens hierfur geschaffenen Testdatenbasis durchgefuhrt werden und fuhrtenzu den erwarteten Ergebnissen.

Wahrend der Erstellung des Konzeptes wurden die verwendeten Daten model-liert und die Architektur des geplanten Systems festgelegt. Das fur die Kunden-,


Fahrzeug- und Buchungsdaten verwendete Modell wurde bewusst allgemein ge-halten und nicht an EBuS-spezifische Strukturen angepasst, damit das entwi-ckelte Kundenportal auch fur andere Carsharing-Software verwendbar ist. EineHauptaufgabe in dieser Projektphase bestand darin, einen Algorithmus zur Um-gehung von großeren geographischen Hindernissen auszuarbeiten, der bei der Ent-fernungsbestimmung benotigt wurde. Entscheidungen zur verwendeten Softwarewie im Speziellen dem Web-Kartendienst wurden getroffen. Außerdem wurde einegrobe Skizze der Benutzerschnittstelle angefertigt, die jedoch in mehreren Punk-ten spater nicht exakt auf diese Weise umgesetzt wurde. Die Anderungen amOberflachenentwurf waren hauptsachlich

� eine Strukturierung der einzelnen Elemente in Tabs und

� das Weglassen der Minimalzeiteinstellung.

Sie resultierten aus Grunden sowohl der besseren Ubersichtlichkeit als auch dertechnischen Praktikabilitat. Die Favoriten wurden in die Kategorien

”Stellplatze“

und”Positionen“ aufgeteilt und so jeweils logisch besser zugeordnet.

Die Implementierungsphase war grob in zwei Teile zu trennen: Die Integrationder definierten Kommunikationsschnittstelle in EBuS und die Erstellung der Be-nutzeroberflache auf Basis dieser Schnittstelle. Zusatzlich zum reinen Einbettender Schnittstelle war es jedoch im ersten Teil erforderlich, einen neuen Algo-rithmus zur Erstellung und Bewertung von Buchungsvorschlagen zu entwickeln,weil EBuS das Konzept von alternativen buchbaren Vorschlagen noch nicht un-terstutzte. Bisher musste der Benutzer aufgrund der angezeigten Fahrzeugda-ten (frei/teilweise belegt/belegt) entscheiden, welches Fahrzeug er buchen wollteund ob er ggf. den definierten Zeitraum manuell anpassen konnte, um doch seingewunschtes Fahrzeug zu erhalten.

Das verwendete AJAX-Framework Echo2 ermoglichte, unter Verwendung be-kannter Konzepte aus der Swing-Oberflachengestaltung das Portal aus vorhande-nen und neu fur dieses Projekt entwickelten Komponenten zusammenzustellen.Eine großere Aufgabe hierbei war die Erstellung einer von Grund auf neu ent-worfenen Komponente, um den Dienst von Google Maps in Echo2 einzubinden.Hierbei mussten zusatzlich Schwierigkeiten im Design von Echo2 beseitigt wer-den, was sich darin niederschlug, dass keine Standard-Echo2-Version verwendetwerden konnte, sondern mit einer angepassten Codebasis gearbeitet werden muss-te. Fur die Anpassung der aktuellen Version 2.1.0 RC2 liegen Patches vor, dievermutlich auch auf zukunftige Versionen angewendet werden konnen, so dassstets die neueste Fassung von Echo2 verwendet werden kann.

5.2. Ausblick 75

5.2 Ausblick

Die Benutzerschnittstelle besitzt die grundlegenden Fahigkeiten, die fur eine Ver-wendung notig sind; es ist jedoch erforderlich, weitergehende, ausgiebige Tests miteinem großeren Teilnehmerkreis durchzufuhren, bevor die Software tatsachlichproduktiv eingesetzt werden kann. Es ist außerdem unumganglich, weitere Datenim taglichen Betrieb zu sammeln, insbesondere was die Beeinflussung des Ge-samtsystems betrifft. Es muss moglichst ausgeschlossen werden, dass EBuS oderandere auf derselben Hardware parallel laufende Programme verlangsamt oderanderweitig negativ beeinflusst werden. Wenn Seiteneffekte festgestellt werden,muss z. B. durch Optimierung der verwendeten Mechanismen Abhilfe geschaffenwerden.

Im Verlauf dieses Projektes wurde, quasi als”Nebenprodukt“, eine Google Maps

Komponente fur Echo2 entwickelt; diese ist naturlich auch in anderen Projekteneinsetzbar und steht im SourceForge-Projekt

”googlemaps-echo“ interessierten

Entwicklern unter den Bestimmungen der GNU GPL zur Verfugung.

Zusatzlich wurden verschiedentlich Punkte gefunden, die fur ein weiteres Voran-schreiten der Kundenschnittstelle im Allgemeinen interessant waren, zum Beispieldie Eingabe einer minimalen Zeitspanne fur eine Buchung. Auf diese Weise konnteder Kunde sogar die Lange des Zeitraums flexibel anpassen lassen, wenn der ur-sprunglich gewahlte Zeitraum fur einige Fahrzeuge nicht buchbar ist. Hierzu waredas Bewertungsschema fur Buchungsvorschlage zu uberdenken und ggf. zu ver-allgemeinern. Eine weitere Erweiterungsmoglichkeit ist die Integration andererAlgorithmen bzw. Dienste zur Suche von kurzesten Wegen.

Danksagungen

Ich will dich preisen, Herr, mein Gott, mit meinem ganzen Herzen unddeinen Namen ewig verherrlichen. Psalm 86, Vers 12

Ich danke Jesus Christus fur seine Liebe, meiner Frau Sophie fur ihre Unterstut-zung, außerdem Herrn Eric Knauss fur die interessierte und vorbildliche Betreu-ung dieser Arbeit sowie allen Personen, die mir bei Planung und Durchfuhrungzur Seite gestanden haben, insbesondere Herrn Dirk Hillbrecht und Herrn HaraldZielstorff.

Quellenverzeichnis

[BWGB99] Berad Batinic, Andreas Werner, Lorenz Graf und Wolfgang Bandilla(Herausgeber): Online Research: Methoden, Anwendungen und Er-gebnisse. Hogrefe Verlag, Gottingen, 1999.

[Coc00] Alistair Cockburn: Writing Effective Use Cases. Addison-Wesley,Boston, 2000.

[Cri06] Christian Crisp: Konzept und Werkzeug zur erfahrungsbasierten Er-stellung von Use Cases. Masterarbeit, Leibniz Universitat Hannover,2006.

[e-t] e-teaching.org: Online-Umfrage. http://www.e-teaching.org/

didaktik/qualitaet/online umfrage/.

[Fin95a] Arlene Fink: How to ask Survey Questions. Sage Publications, Thou-sand Oaks, California, 1995.

[Fin95b] Arlene Fink: The Survey Handbook. Sage Publications, ThousandOaks, California, 1995.

[Har] Sven Hartenstein: flexSURVEY. http://www.flexsurvey.de/.

[Hil99] Dirk Hillbrecht: MouthTracker — Ein System zur Lippensegmentie-rung in einer Java-Umgebung. Diplomarbeit, Universitat Hannover,1999.

[Hil03] Dirk Hillbrecht: Elektronisches Buchungssystem fur Carsharing –Technische Dokumentation. Interne Dokumentation der Firma can-tamen, Hannover, 2003. Auf Anfrage beim Autor erhaltlich.

[Jac] Jens Jacobsen: Usability-Normen. http://www.contentmanager.

de/magazin/artikel 582-200 usability normen din iso.html.

[McG] Andy McGovern: Geographic Distance and Azimuth Calculati-ons. http://www.codeguru.com/Cpp/Cpp/algorithms/general/

article.php/c5115/.

http://www.e-teaching.org/didaktik/qualitaet/online_umfrage/

http://www.e-teaching.org/didaktik/qualitaet/online_umfrage/

http://www.flexsurvey.de/

http://www.contentmanager.de/magazin/artikel_582-200_usability_normen_din_iso.html

http://www.contentmanager.de/magazin/artikel_582-200_usability_normen_din_iso.html

http://www.codeguru.com/Cpp/Cpp/algorithms/general/article.php/c5115/

http://www.codeguru.com/Cpp/Cpp/algorithms/general/article.php/c5115/

Quellenverzeichnis 78

[Nex] NextApp: Echo2 Documentation. http://nextapp.com/platform/

echo2/echo/doc/.

[RB01] Ulf-Dietrich Reips und Michael Bosnjak (Herausgeber): Dimensionsof Internet Science. Pabst Science Publishers, Lengerich, 2001.

[Rup04] Chris Rupp: Requirements-Engineering und -Management. 3. Aufla-ge, Carl Hanser Verlag, Munchen, 2004.

[Ro01] Katja Rosch: Car-Sharing. Dissertation, Friedrich-Alexander-Universitat Erlangen-Nurnberg, 2001.

[Sch03] Armin Scholl: Die Befragung. UVK Verlagsgesellschaft, Konstanz,2003.

[usa] usabilitynet.org: International Standards. http://www.

usabilitynet.org/tools/r international.htm#9126-1.

[Viv] Vivid Solutions: JTS Topology Suite. http://www.vividsolutions.com/jts/jtshome.htm.

[ZGK04] Wolfgang Zuser, Thomas Grechenig und Monika Kohle: Software En-gineering mit UML und dem Unified Process. Pearson, Munchen,2004.

Alle o. g. Webseiten wurden am 20.05.2007 mit positivem Ergebnis auf Erreich-barkeit gepruft.

http://nextapp.com/platform/echo2/echo/doc/

http://nextapp.com/platform/echo2/echo/doc/

http://www.usabilitynet.org/tools/r_international.htm#9126-1

http://www.usabilitynet.org/tools/r_international.htm#9126-1

http://www.vividsolutions.com/jts/jtshome.htm

http://www.vividsolutions.com/jts/jtshome.htm

Anhang

A.1 Die Umfrage

Im folgenden sind die einzelnen Elemente der Umfrage aufgefuhrt, jeweils miteiner kurzen Angabe, warum diese Elemente eingebaut wurden.

Einleitungsseite

Sie konnen mitwirken an der Neugestaltung der Online-Buchung! In dieser Um-frage haben Sie die Moglichkeit, uns Ihre Wunsche fur die zukunftige Oberflachemitzuteilen. Wir haben ein paar Fragen vorbereitet, die Sie schnell und einfachbeantworten konnen.

Diese Umfrage wird ca. 3 – 5 Minuten dauern. Wir freuen uns, dass Sie Interessehaben! Denn nur, wenn wir Ihre Meinung kennen, konnen wir uns verbessern undIhre Wunsche erfullen.

Zweck: den Kunden willkommen heißen und ihn ermutigen, die Umfrage kom-plett auszufullen

Fragen

F1. Wie zufrieden sind Sie mit der momentanen Online-Buchung?

Antwortmoglichkeit: Multiple Choice (”sehr zufrieden“,

”eher zufrieden“,

”weder ausgesprochen zufrieden noch unzufrieden“,

”eher unzufrieden“,

”sehr

unzufrieden“)

Zweck: generelle Zufriedenheit herausfinden

F2. Bitte bewerten Sie die Qualitat einzelner Bereiche der Online-Buchung!

A.1. Die Umfrage 80

Kategorien:

– Erstellen neuer Buchungen ohne Einschrankungen bzgl. Fahrzeug, Stand-ort oder Ausstattung

– Erstellen neuer Buchungen mit bestimmtem Fahrzeugwunsch

– Erstellen neuer Buchungen mit bestimmtem Standortwunsch

– Erstellen neuer Buchungen mit bestimmten Ausstattungswunschen

– Bearbeiten vorhandener Buchungen

– Stornieren von Buchungen

– Ausdrucken von Belegen

– Anpassen von personlichen Einstellungen

– etwas anderes (bitte im Textfeld unten angeben)

Antwortmoglichkeit: jeweils Multiple Choice (von”Funktion ist schlecht,

muss extrem verbessert werden“ in 7 Abstufungen bis”Funktion ist sehr

gut, bedarf keiner Verbesserung“, zusatzlich”Kann ich nicht beurteilen /

keine Antwort“), fur die letzte Kategorie ein Textfeld

Zweck: Zufriedenheit in einzelnen Bereichen herausfinden – diese Wertekann man (nach einer Normierung) mit der generellen Zufriedenheit ver-gleichen und sieht so, wie jeder Bereich relativ zum Durchschnitt liegt.

F3. Was sollte geandert werden bei dem . . . (Stichworte reichen aus)?

Anmerkung: Diese und die nachste Frage wurden fur mindestens die dreiam schlechtesten bewerteten Gebiete aus der vorigen Frage gestellt. Dabeiwurden, bevor der Benutzer diese Frage zu sehen bekam, die Antworten aufdie vorige Frage von der schlechtesten zur besten Bewertung durchgegangenund jeweils die Gebiete vorgemerkt, die diese Bewertung bekommen haben– und sobald insgesamt mindestens drei zusammengekommen waren, wurdeabgebrochen. Es konnte daher vorkommen, dass Benutzer F3 und F4 furmehr als 3 Gebiete gezeigt bekamen, namlich dann, wenn sie mehr als 3Gebiete

”gleichschlecht“ bewertet hatten.

Antwortmoglichkeit: Textfeld

Zweck: Hinter dieser Frage steht die Absicht, Anregungen zu den vom Be-nutzer am schlechtesten empfundenen Bereichen zu bekommen, denn genaufur diese Bereiche hat der Benutzer vermutlich viele Anregungen und wirdgern zu einer Verbesserung beitragen.

F4. Und wie wichtig ist Ihnen die Anderung bei dem . . . ?

A.1. Die Umfrage 81

Antwortmoglichkeit: Multiple Choice (von”unwichtig“ in 7 Abstufungen

bis”sehr wichtig“, zusatzlich

”Kann ich nicht beurteilen / keine Antwort“)

Zweck: Der Benutzer soll bewusst nochmals eine differenzierte Einstufungseiner Praferenzen geben – die erste Einstufung durch die Qualitatsbewer-tung einzelner Bereiche reicht nicht aus, um nachher Prioritaten fur dieAnforderungen zu vergeben!

F5. Bitte nennen Sie Vorschlage fur neue Funktionen (Stichworte reichen aus)!


Zweck: Bewusst vor der Vorstellung der schon geplanten neuen Funktionengelegt wurde diese Frage, um unvoreingenommene Vorschlage zu bekom-men.

F6. Momentan konnen Sie bevorzugte Fahrzeug-Standorte einstellen. Stellen Siesich vor, sie konnten mit beliebigen Positionen unabhangig von den Stell-platzen der Fahrzeuge arbeiten. Bitte bewerten Sie, wie Ihnen die folgendenFunktionen gefallen wurden:

Kategorien:

– Sie konnen Ihre eigene Position uber einen Stadtplan eingeben, wobeidas System automatisch die nachstgelegenen Fahrzeuge fur Buchungenanbietet.

– Sie konnen eine Liste von Positionen unabhangig von den Stellplatzenverwalten und bei einer neuen Buchung wahlen, von welcher dieserPositionen aus Sie Fahrzeuge suchen wollen.

– Sie konnen eine Ubersichtskarte anschauen, die darstellt, an welchenStellplatzen Fahrzeuge mit den von Ihnen gewahlten Kriterien (Typ,Ausstattung) verfugbar sind.

Antwortmoglichkeit: jeweils Multiple Choice (von”ware vollkommen

uberflussig“ in 7 Abstufungen bis”ware eine sehr gute Erganzung“, zusatz-

lich”Kann ich nicht beurteilen / keine Antwort“)

Zweck: Zwischen den drei vorgegebenen Vorschlagen wird eine Art Konkur-renz aufgebaut, der Benutzer muss sich zwar nicht fur eine der Moglichkeitenentscheiden, wird aber dahin gefuhrt, sich mit den Unterschieden zu befas-sen und die fur ihn personlich besonders gut passenden Vorschlage durcheine bessere Bewertung hervorzuheben.

A.1. Die Umfrage 82

F7. Haben Sie Anmerkungen zu der Idee, eine Karte in die Online-Buchung zuintegrieren?


Zweck: Falls jemandem ein weitere Weise wichtig ist, eine Karte in derWebbuchung zu benutzen, so kann er diese hier beschreiben. Außerdemwird durch die offene Fragestellung die Moglichkeit gegeben, separat voneiner fixen Skala eine Bewertung dieser Idee abzugeben.

F8. Uber den Zeitraum der letzten 3 Monate gesehen, wie oft haben Sie durch-schnittlich pro Monat die Online-Buchung benutzt?

Antwortmoglichkeit: Multiple Choice (”nie“,

”weniger als 1 mal pro Mo-

nat“,”1 – 4 mal pro Monat“,

”5 – 9 mal pro Monat“,

”10 – 15 mal pro

Monat“,”mehr als 15 mal pro Monat“)

Zweck: Die Meinung von Benutzern, die haufiger online buchen, sollte mehrGewicht haben.

F9. Uber den Zeitraum der letzten 3 Monate gesehen, wie oft haben Sie durch-schnittlich pro Monat mobile Endgerate wie internetfahige Handys oderPDAs benutzt, um Fahrzeuge zu buchen? Anrufe bei der Buchungszentralezahlen dabei nicht!

Antwortmoglichkeit: Multiple Choice (”nie“,

”weniger als 1 mal pro Mo-

nat“,”1 – 4 mal pro Monat“,

”5 – 9 mal pro Monat“,

”10 – 15 mal pro

Monat“,”mehr als 15 mal pro Monat“)

Zweck: Von Seiten cantamen/Stadtmobil kam die Aussage”Bisher wird

sehr wenig uber mobile Endgerate gebucht.“ Hier sollte erfragt werden, wiehoch der Anteil tatsachlich ist.

F10. Hersteller und Modellbezeichnung des mobilen Endgerates: (diese Angabeist freiwillig)


Zweck: Wenn jemand uber ein mobiles Endgerat bucht, ist es sinnvoll, denTyp zu erfragen, um evtl. spater Anpassungen an besonders haufig genutzteGerate zu implementieren.

F11. Aus welchem Anlass haben Sie in den letzten 3 Monaten die Online-Buchungbenutzt?

Antwortmoglichkeit: Multiple Choice (”privat“,

”geschaftlich“,

”beides“,

”keine Angabe“)

A.1. Die Umfrage 83

Zweck: Der Anlass gibt unter Umstanden Aufschluss daruber, wie re-gelmaßig weiterhin mit einer Benutzung zu rechnen ist; um hierzu Schatzun-gen abzugeben, muss jedoch der Zusammenhang mit anderen Daten diesesBenutzers hergestellt werden.

F12. Bitte geben Sie Ihr Alter an!

Antwortmoglichkeit: Multiple Choice (”unter 30 Jahre“,

”30 – 45 Jah-

re“,”46 – 60 Jahre“,

”uber 60 Jahre“,

”keine Angabe“)

Zweck: Die Antworten auf diese und die nachste Frage ergeben ein diffe-renzierteres Bild der Benutzergruppe.

F13. Bitte geben Sie Ihr Geschlecht an!

Antwortmoglichkeit: Multiple Choice (”mannlich“,

”weiblich“,

”keine

Angabe“)

F14. Zum Schluss haben Sie hier noch die Moglichkeit, allgemeine Kommentarezur Befragung abzugeben oder auf bestimmte Punkte besonders hinzuwei-sen. Ihre Bemerkungen:


Zweck: Der Benutzer sollte die Moglichkeit haben, zur Umfrage und zuPunkten Stellung zu nehmen, die nicht abgefragt wurden.

Endseite

Sie haben vollstandig an der Umfrage teilgenommen. Vielen Dank fur Ihr Inter-esse!

Hier konnen Sie zuruck in Ihr Kundenmenu wechseln!

Zweck: Hier kann uber einen Link wieder zum Hauptmenu gesprungen werden,nachdem die Umfrage beendet wurde, ohne dass ein erneuter Loginvorgang notigist.

A.2. Tabellarische Auflistung der Anforderungen 84

A.2 Tabellarische Auflistung der Anforderun-

gen

Sektionen

F FrontendF1 Fahrzeug suchen/buchenF2 Buchung bearbeiten/(teil-)stornierenF3 Belege druckenF4 Pers. Einstellungen andernB Backend (Administration)T Technische Anforderung

Arten

fun funktionale Anforderungtec technische Anforderunginf Anforderung an die zu verarbeitenden Informationensch Anforderung an die Benutzerschnittstellequa Qualitatsanforderungent Anforderung an die Durchfuhrung der Entwicklungver rechtlich-vertragliche Anforderung

Prioritaten bzw. Gewichte

Bei der Quelle”Umfrageteilnehmer“ wird zusatzlich in Klammern die nach 2.4.3.2

gewichtete Anzahl der Nennungen oder bei Anforderungen, welche auf Frage 6aus A.1 basieren, die prozentuale Akzeptanz des Vorschlages genannt.

1 sehr niedrig (0,5 - 2)2 niedrig (2,5 - 5)3 mittel (5,5 - 9)4 hoch (9,5 - 14)5 sehr hoch (14,5 und mehr)

Quellen

A Analyse des AltsystemsM Mathis Dirksen-ThedensF Mitarbeiter der Firma cantamen oder Stadtmobil/teilAutoU Umfrageteilnehmer


Sektion Art Prio QPrio Anforderung QAnf

F1,2 fun 5 (85%) U eine Karte zeigt, an welchen Stell-platzen Fahrzeuge mit den vomBenutzer gewahlten Kriterien (Typ,Ausstattung...) zu der gewahltenZeit verfugbar sind (Standard-Zeitvorgabe: nachste halbe Stunde,Standard-Buchungslange: eineStunde)

UM

F sch 5 (42) U das Portal benutzt eine einfacheSprache, es ist ubersichtlich undhat eine gute Benutzerfuhrung, evtl.auch erlauternde Hilfetexte, und alleFunktionen sind leicht zuganglich

U

F1,2,4 fun 5 (18,5) U es gibt eine nur vom verfugbarenSpeicherplatz begrenzte Anzahl vomBenutzer definierbarer Favoriten(Adressen fur Umkreissuche und/o-der Fahrzeug-Standorte), die beiBuchungen zur Auswahl angebotenwerden

UFM

F1,2 fun 5 (17) U es gibt eine Umkreissuche zu Adres-sen und eine geographische Hilfestel-lung per Karte bei der Fahrzeug-Auswahl: es wird ein zoom- undverschiebbarer Kartenausschnitt undggf. ein Adress-Suchfeld angezeigt,durch welches man schnell zu ei-ner Adresse springen kann, und aufder Karte werden mogliche Fahrzeu-ge bzw. Stellplatze kenntlich gemacht

UM

F1,2 sch 5 (6,5) UM die Eingabe des Buchungszeitraumesist einfach, und der Benutzer kannden Buchungszeitraum in den vonEBuS festgesetzten Grenzen angeben

UA

F1,2 fun 5 (2,5) UM der Benutzer kann uber die vonEBuS unterstutzten Fahrzeugpara-meter selektieren, und die benutztenFilter werden sichtbar markiert undsofort auf die Vorschlagsliste ange-wendet

UA


Fortsetzung


F1 sch 5 M der Benutzer kann, wenn EBuS diesunterstutzt, auch ohne vorherige An-meldung nach Fahrzeugen suchen (ei-ne Buchung vorbereiten), bei einerAnmeldung dabei wird weiterhin dieSeite

”Neue Buchung“ mit allen bis-

her eingegebenen Daten angezeigt(Standard: nach dem Login wer-den die

”Anbieter-Neuigkeiten“ an-

gezeigt), zum tatsachlichen Buchenist eine Anmeldung naturlich obliga-torisch

AFM

F2 fun 5 M der eingeloggte Benutzer kann Bu-chungen bearbeiten, soweit zeitlichnoch moglich, und auch stornieren(auch teilweise, d. h. das Ende vor-ziehen)

A

F fun 5 M der Benutzer kann sich an- und ab-melden

A

B fun 5 M der Administrator kann sich an- undabmelden

M

T inf 5 M EBuS erlaubt den Zugriff auf dienotigen Daten, damit der Benutzertatsachlich Fahzeuge suchen kann,ohne sich vorher anmelden zu mussen(andernfalls steht diese Funktionnicht zur Verfugung)

M

T tec 5 M das System benutzt ein AJAX-Toolkit fur Java (z. B. Echo2 oderThinWire)

FM

T tec 5 M das System ist mit EBuS kombinier-bar, d. h. es lauft auf einem einbett-baren Java Servlet Container, der dieServlet-Spezifikation in der Version2.4 unterstutzt, konkret z. B. Jetty5.1.4

F

T ver 5 M das entwickelte System wird unterder GPL bzw. die in EBuS zu inte-grierenden Codeteile unter der LGPLveroffentlicht

M


Fortsetzung


F1,2 fun 4 (78%) U der Benutzer kann seine eigene Po-sition uber eine Karte eingeben,wobei das System automatisch dienachstgelegenen Fahrzeuge fur Bu-chungen anbietet

UM

F1,2 fun 4 (13) U Fahrzeugdetails wie Maße sindleicht nachschlagbar, z. B. aufeiner Infoseite zum Fahrzeug; man-ches muss jedoch weiterhin amTelefon besprochen werden (z. B.Dachtrager, Winterreifen, Maße beiNicht-Transportern)

UFA

F2,3 fun 4 (1) UM es gibt eine Ubersicht aller Buchun-gen, die uber EBuS zuganglich sind

UM

F1,2 fun 4 M der Algorithmus, der die fur den Be-nutzer schnellstmoglich zu erreichen-den Stellplatze sucht, berucksichtigtdie eingegebenen Hindernisse (Poly-gonzuge)

M

F1,2 fun 4 M der Benutzer kann einen Fahrtgrundhinterlegen, der spater auch auf derRechnung erscheint

A

B fun 4 M der eingeloggte Administrator kannHindernisse (Polygonzuge) neu ein-geben und bearbeiten (mit Karten-ansicht)

M

B fun 4 M der eingeloggte Administrator kannzu vorhandenen Stellplatzen Geoda-ten hinzufugen bzw. diese bearbeiten(mit Kartenansicht)

M

F4 fun 4 M der eingeloggte Benutzer kann seineEinstellungen anpassen

A

F sch 4 M der Benutzer bekommt aktuelle In-formationen des Anbieters angezeigt

AF

F sch 4 (1) UF es gibt ein durchgehend sichtbaresMenu

FU


Fortsetzung


F1,2 sch 3 (9) U der Benutzer kann leicht sehen (auchin der Liste schon), wann Fahrzeugevon anderen gebucht sind, und evtl.sind Verschiebemoglichkeiten schongekennzeichnet

U

F1,2 fun 3 (8) U das System zeigt Preise beigeschatzter km-Eingabe direktim richtigen Benutzertarif an,Sonderabgebote sind hervorgehoben

U

F1,2 sch 3 (8) U die Belegtzeitanzeige zeigt auch vorund nach der angestrebten Buchungliegende Zeiten an

U

F ent 3 M die Struktur ermoglicht, dass eineRechnungsansicht bzw. die adminis-trative Anderung von Kundendatenspater hinzugefugt werden kann

F

B ent 3 M die Struktur ermoglicht, dass dieAnsicht von beliebigen Buchungenund Tasks spater hinzugefugt werdenkann

F

T sch 3 M das System bietet eine mehrsprachi-ge Benutzerschnittstelle an, und derBenutzer kann zu jedem Zeitpunktdie Sprache wechseln, bleibt aber aufderselben Seite wie vorher

A

F tec 3 M das Aussehen des Frontends ist an-passbar

A

F qua 3 (0,5) UM das Portal reagiert bei Benutzerein-gaben fehlertolerant

U

F sch 3 F es gibt einen Web-Link zur Webseitedes Anbieters und einen Email-Linkzur Anbieter-Kontaktadresse

A

F3 fun 3 (2,5) UM der Benutzer kann Bestatigungen furStornierungen und Buchungen gutausdrucken, evtl. sogar als PDF her-unterladen

UA

F1,2 fun 3 (1,5) UM der Benutzer kann nach Standortenselektieren, dabei konnen mehrereStandorte gleichzeitig gewahlt wer-den

UM


Fortsetzung


F3 fun 2 M es gibt eine Karte auf derBestatigungsseite, welche die Um-gebung des gebuchten Fahrzeugsdarstellt

MF

F1,2 fun 2 (4) U die Vorschlagsliste lasst sich sortierenoder filtern, auch z. B. nach Stadttei-len

U

T tec 2 (3,5) U bei einer langsamen Internet-Verbindung arbeitet das Portaltrotzdem zugig, evtl. ist die Kartein den Personlichen Einstellungendeaktivierbar oder sie wird als letztesgeladen

U

F1,2 fun 2 (3) U das System macht Vorschlage furandere Fahrzeuge bei unmoglicherWahl

U

F1,2 fun 2 (2,5) U der Buchungszeitraum kann (auchautomatisch) verschoben werden, da-mit ein spezielles Fahrzeug gebuchtwerden kann, und es gibt eineUbersicht, wann das Auto gebucht istan dem Tag, um personl. Alternati-ven zu finden

U

F1,2 sch 2 (2,5) U die Buchungsdaten werden komplettauf einer Seite abgefragt

U

F1,2 ent 2 M das Kartenmaterial von Google Mapswird verwendet (Yahoo bietet einenahnlichen Service an)

M

F4 fun 1 (2) U die Emailadresse fur den Newsletter-empfang und die Rechnungsadresseund das eigene Bankkonto konnenonline geandert werden

U

F1 fun 1 (2) U die Belegtzeit-Ubersicht eines Fahr-zeugs beinhaltet auch dieselbe Zeiteinen Tag davor oder danach

U

F1 fun 1 (2) U alte Buchungen konnen als Vorlageverwendet werden, nur Zeit wird ak-tualisiert

U


Fortsetzung


F sch 1 (2) U als Erganzung ist bei Gasautos einPlan der Gastankstellen und eineTankanleitung verlinkt

U

F ent 1 (1) U das System verwendet nur Standard-Techniken (z. B. nicht ActiveX-Controls oder Java-Applets)

U

F1,2 fun 1 (1) U der Benutzer kann nach Fahrzeug-Zugangssystem filtern

U

F tec 1 (1) U das Portal ist auch auf kleinen Bild-schirmen gut bedienbar

U

F fun 1 (0,5) U Storno-Kosten werden vor derendgultigen Stornierung angezeigt

U

F1 sch 1 (0,5) U die Wagenart ist gut gekennzeichnet,evtl. auch schon in der Karte

U

F sch 1 M der eingeloggte Benutzer siehtstandig die Anzahl seiner aktuellenBuchungen oder sogar eine kleineUbersicht

F

Verknüpfung eines Carsharing-Kundenportals mit einem Web ... · Zusammenfassung Eine...

Documents

Transcript of Verknüpfung eines Carsharing-Kundenportals mit einem Web ... · Zusammenfassung Eine...