Konzept für ein Live-Ergebnis System für eine Squash-WM

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Düsseldorf
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	Konzeption einer IT-Infrastruktur für eine Squash WM
Autor(en):	Marvin Suckow, Benjamin Snella, René Meurer
Studienzeitmodell:	Abendstudium
Semesterbezeichnung:	WS10
Studiensemester:	2
Bearbeitungsstatus:	begutachtet
Prüfungstermin:	10.01.2011
Abgabetermin:	09.01.2011

Name des Autors / der Autoren:	Benjamin Snella (bensnella@gmail.com), Marvin Suckow (marvin.suckow@arcor.de), René Meurer (rene.meurer@gmail.com)
Titel der Arbeit:	"Konzept für ein Live-Ergebnis System für eine Squash-WM"
Hochschule und Studienort:	FOM Düsseldorf

Inhaltsverzeichnis 1 Einleitung 1.1 Kontext der Fallstudie 1.2 Zielformulierung 1.3 Aufbau des Systems 2 Grundlagen 2.1 Squash Team-Weltmeisterschaft der Herren 2011 2.2 Grundlagen des Turnierverlaufes 2.3 Zielgruppen 2.4 Internettechnologien 2.4.1 Hypertext Markup Language (HTML) 2.4.2 Extensible Markup Language (XML) 2.4.3 Extensible Hypertext Markup Language (XHTML) 2.4.4 Rich Site Summary (RSS) 2.4.5 Cascading Style Sheets (CSS) 2.5 Skalierbarkeit 2.6 RAID-System 2.7 Cloud-Computing 2.8 Eingabe-Verarbeitung-Ausgabe Prinzip (EVA) 3 Konzeption Live-Ergebnis System 3.1 Vorhergehensweise 3.2 Betrachtung von bestehenden Systemen 3.3 Funktionsumfang 3.3.1 Zeitnahe Erfassung der Daten (Punkte, Zeiten, etc.) während des Spiels 3.3.2 Speicherung der Daten auf einem zentralen System 3.3.3 Augabe der Informationen 4 Ausarbeitung des Moduls: Erfassung (Input) 4.1 Authentifizierung und Autorisierung 4.2 Datenselektion 4.3 Datenerfassung 4.3.1 Datenerfassung in Echtzeit 4.3.2 Vorbereitende Datenerfassung 4.4 Qualitätsmanagement 4.5 Datenübermittlung 4.6 Konzept für einen Prototyp 4.6.1 Grundlegende Informationen zum Prototypen 4.6.2 Beschreibung des Prototyps 5 Ausarbeitung des Moduls: Verarbeitung und Speicherung (Processing) 5.1 Systemanforderungen 5.1.1 Bestandteile des Moduls "Processing" 5.1.2 Anforderungen an das System 5.2 Konzeptionierung des Moduls "Processing" 5.2.1 Hardware und Software (Aufbau und Funktionsweise) 5.2.2 Alternative "Cloud" 5.2.3 Ausgabe / Schnittstellen zu Modul "Ausgabe" 5.2.4 Datenbanksoftware (Analyse und Auswahl) 6 Ausarbeitung des Moduls: Darstellung (Output) 6.1 Konzeption: Live Ticker 6.1.1 Funktionsumfang 6.1.2 Datenverarbeitung 6.1.3 Navigationsstruktur 6.1.4 Informationsstruktur 6.2 Umsetzung 6.2.1 Darstellung 6.2.1.1 Auszeichungssprache 6.2.1.2 Stylesheet 6.2.2 Programmierung 6.2.3 Verbindung von Inhalt, Formatierung und Programmierung 6.2.4 Der Live Aspekt des Ergebnis Systems 6.2.4.1 Problemstellung 6.2.4.2 Lösungsansätze 6.2.4.3 Umsetzung des Live Aspektes 6.2.4.4 Visualisierung des Live Aspektes 6.2.5 Internationalisierung 6.3 Inhaltsverbreitung 6.3.1 Squashverbände 6.3.2 Soziale Netzwerke 6.3.3 Klassische Pressearbeit 6.3.4 RSS-Kanal 6.4 Beschreibung eines Prototypen 7 Schlußbetrachtung 7.1 Erfolgsfaktoren 7.2 Kritische Betrachtung des Konzeptes 7.3 Weitere Entwicklung 7.4 Projektkonzeption 8 Anhang 8.1 Fußnoten 8.2 Quellenverzeichnis 8.3 Tabellenverzeichnis 8.4 Abbildungsverzeichnis 8.5 Abkürzungsverzeichnis

1 Einleitung

1.1 Kontext der Fallstudie

Die Squash-Mannschaftsweltmeisterschaft der Herren findet im Jahr 2011 in Deutschland statt. Dies verwundert nicht, da bereits in den Jahren 1990 und 2005 internationale Meisterschaften im Ahorn-Sportpark in Paderborn stattgefunden haben und die Veranstaltungen seinerzeit bereits Maßstäbe gesetzt hatten. So werden Aktive aus 143 Ländern in denen Squash organisiert gespielt wird in 2011 nach Deutschland kommen. Bei weltweit mehr als 50.000 Courts in 185 Ländern und etwa 600.000 Menschen die das Hobby intensiv ausüben, so wie weiteren 1,9 Millionen Menschen die gelegentlich zum Racket greifen, ist mit einem hohen Informationsinteresse zu rechnen. ^[1]

Bereits andere Sportereignisse haben gezeigt, dass neben der Berichterstattung in den etablierten Medien (wie Fernsehen, Radio oder Zeitungen) vor allem das Internet genutzt wird um die Geschehnisse zu verfolgen. So nutzen nach einer Umfrage von „Initi@tive D21“ (Partnerschaft von Politik und Wirtschaft für die Informationsgesellschaft) Mitte 2010 bereits 72% aller Deutschen über 14 Jahren das Internet. ^[2]

Weltweit nutzen ca. 1,2 Milliarden Menschen das Internet:^[3]

Dies entspricht, ausgegangen von ca. 7 Milliarden Menschen ^[4], etwa 17 Prozent der Weltbevölkerung.

Laut der AGOF (Arbeitsgemeinschaft Onlineforschung) nutzen in demselben Zeitraum 37,9% der Internetnutzer die Möglichkeit sich über Sportereignisse im Netz zu erkundigen. ^[5] Auch in den Twittercharts 2010 ist das Thema Sport stark vertreten. So ist die Herrenfußballweltmeisterschaft 2010 dort auf Platz 2 der meistverfolgten Ereignisse zu finden.

Bereits 2008 veröffentlichte das Institut für Demoskopie Allensbach eine Studie zur Nutzung von Sportnachrichten im Internet. Demnach gaben im Zeitraum von Januar 2007 bis August 2007 49% der Befragten an das Internet zum Erhalt von Sportnachrichten zu nutzen. ^[6]

Die Möglichkeiten Inhalte wie Interviews, Portraits der Spieler, Hintergrundstories und Fotos mit den Live-Ergebnissen zu verknüpfen oder Sie zusätzlich anzubieten, sind online kaum begrenzt. So liegt es nahe das Mediums Internet für ein Live-Ergebnissystem in den Fokus zu rücken. Die Möglichkeiten hier Schnittstellen und Verweise von und zu anderen Medien herzustellen, wie auch die Möglichkeit der mobilen Nutzung, sind ein weiteres Argument das System in Form einer Website, Feeds und Mobile-Apps zu realisieren. Auch für andere Verbreitungsmedien solle eine webbasierte Lösung deutliche Vorteile bringen. So ist es möglich innerhalb des Veranstaltungsortes Anzeigen zu nutzen, welche ebenfalls auf webbasierte Daten zugreifen können.

1.2 Zielformulierung

Ziel ist die Erstellung eines ganzheitlichen Konzeptes für ein Live-Ergebnisystems für die Squash Weltmeisterschaft 2011 in Paderborn. Ganzheitlich bedeutet in diesem Zusammenhang, den Weg von der Erfassung der Spielereignisse, über die Speicherung und Verarbeitung eben jener, bis hin zur Darstellung der Daten. Das System wird so definiert, dass eine Darstellung aktueller Ergebnisse unmittelbar und ortsungebunden erfolgen kann. Da das Turnier als Weltermeisterschaft ausgelegt ist, ist zudem auf eine Internationalisierung der Informationen zu achten. Im Mittelpunkt steht die Betrachtung der wesentlichsten Punkte zur Planung und Umsetzung.

1.3 Aufbau des Systems

Um die Darstellung der Inhalte online präsentieren zu können ist es nötig die Ergebnisse schnellstmöglich zu erfassen und sie zentral zu speichern. Hier bieten sich mobile Erfassungstechniken an, welche die Spieldaten mit einem PDA, Handy oder per Funk an eine zentrale Stelle übermitteln können. Diese zentrale Stelle ist in Form einer Datenbank zu realisieren, so dass die Daten automatisiert weiterverarbeitet werden können und deren Nutzung universell möglich gemacht wird.

Hierfür ist entsprechende Infrastruktur und Personal nötig. Die sich hier ergebenden Möglichkeiten werden in späteren Teilen des Konzepts erarbeitet und analysiert. Fest steht, dass eine Website erstellt werden muss, die direkt auf die Datenbank zugreifen kann und die Spieldaten in verschiedenen, oben bereits beispielhaft erwähnten, Formen darstellt.

Die Kooperationsmöglichkeiten mit anderen Anbietern, Websites oder herkömmlichen Medien kann stark erweitert werden, wenn die Daten in Form von z.B. XML zur Verfügung gestellt werden. Hierdurch wird ein plattform- und implementationsunabhängiger Austausch ermöglicht.

Um diese Erfassungs-, Darstellungs- und Weitergabetechniken zu konzeptionieren ist vorher jedoch eine Betrachtung der zugrunde liegenden Thematik, der Squash-Mannschaftsweltmeisterschaft der Herren,sowie und der nötigen Grundlagen notwendig.

2 Grundlagen

2.1 Squash Team-Weltmeisterschaft der Herren 2011

• Die Webseite der Squash WM ^[7] bietet Informationen zu den Themen der Squash-WM.
• Das angewandte Regelwerk ^[8]ist auf der Webseite des Deutschen Squash Verband e.V (DSQV)^[9] zu finden.
• Das Regelwerk des DSQV erkennt die Regeln^[10] der World Squash Federation (WSF)^[11]an.

2.2 Grundlagen des Turnierverlaufes

• Bei der Team-WM im Squash spielen pro Team 3 Spieler.
• Es spielt je ein Teammitglied gegen ein Mitglied des Gegnerteams.
• Der Turnierverlauf besteht im Groben aus einer Gruppen- und einer K.O.-Phase.
• Aus der Gruppenphase ergeben sich die Achtelfinalisten, welche nach dem K.O.-Prinzip gegeneinander antreten.
• In der K.O.-Phase finden nochmals 15 Spiele statt.

2.3 Zielgruppen

Bei einer Squash-Mannschaftsweltmeisterschaft ergeben sich als Zielgruppe für ein Informationssystem zunächst die Fans. Diesen soll eine zentrale Anlaufstelle geboten werden, an der Sie alle interessanten Informationen zum Verlauf der einzelnen Spiele und der gesamten WM abrufen können. Sie sollte daher optisch ansprechend, übersichtlich und benutzerfreundlich gestaltet werden. Barrierefreiheit sollte daher im Rahmen der Darstellungskonzeption bedacht werden.

Eine weitere Zielgruppe können, in Abhängigkeit der Wünsche des Veranstalters und des Vorhandenseins von speziellen Alternativen, aber auch die Akteure selbst sein. Es sollten daher alle weiteren Nutzergruppen bekannt sein. Zu diesen können zählen:

• Mannschaften / Spieler
• Betreuer / Trainer
• Offizielle
• Presse
• Aussteller
• Sponsoren

Für die spätere Dimensionierung des Systems, im Hinblick auf die einzusetzende Hardware und Software, müssen auch die zu erwartenden Personenzahlen der einzelnen Nutzergruppe bekannt sein.

Diese sind zum Teil bereits bekannt, die öffentlich zugänglichen Zahlen hier lautet wie folgt^[12]:

• Mannschaften: 32
• Betreuer / Trainer: im Schnitt 3 Betreuer je Team
• Offizielle: ca. 50 Offizielle
• Presse: ca. 20 Pressevertreter
• Aussteller: noch unklar
• Publikum: es werden insgesamt 7.000 Besucher in der Woche erwartet (also nicht je Tag)

Es kann davon ausgegangen werden, dass pro Mannschaft (32) einer der Betreuer ständig Zugriff auf das System halten wird. Bei den Offiziellen ist dies nicht zu erwarten, jedoch sollte zwecks Ausfallsicherheit davon ausgegangen werden, dass jede der ca. 50 Personen durchgehend Zugriffe auf die Informationen des Systems generieren wird. Gleiches gilt für die Pressevertreter, so dass hier noch einmal ca. 20 Nutzer hinzukommen. Bis hierhin ergeben sich also, allein aus den Reihen der Beteiligten, etwa 102 Nutzer.

Schwieriger ist es eine verlässliche Aussage darüber zu treffen, wieviele Fans gleichzeitigen Zugriff auf das System haben werden. So ergibt sich der Bedarf eine detailiertere Zielgruppenanalyse durchzuführen. Dies ist notwendig um Skalierung, Gestaltung und Funktionsumfang zu realisierender Systemmodule bedarfsgerecht anzupassen.

2.4 Internettechnologien

2.4.1 Hypertext Markup Language (HTML)

„HTML [...] ist eine typografische Auszeichnungssprache zur Beschreibung von Dokumenten im WWW [(World Wide Web)]. Sie bietet die Möglichkeit, Webseiten hierachisch [...] zu strukturieren, [und] Querverweise auf andere Textstellen im gleichen oder in anderen Dokumenten herzustellen“ (Neumann, Seite 475)

2.4.2 Extensible Markup Language (XML)

„XML [...] ist ein Standard zur Erstellung sogenannter Auszeichnungssprachen "Markup Languages" und zur Erstellung strukturierter Dokumente. Mit Hilfe solcher Sprachen werden in Dokumenten Metainformationen über die Struktur der Dokumente beziehungsweise semantische Informationen eingefügt. XML definiert also eine Metasprache, mit deren Hilfe eigene Auszeichnungssprachen definiert werden können.“^[13]

2.4.3 Extensible Hypertext Markup Language (XHTML)

XHTML ist eine Weiterentwicklung von HTML auf Basis von XML. Die Formatierungsfunktionen wurde wieder aus der Sprache schrittweise entfernt um eine Interoperabilität zwischen verschiedenen Systemen zu schaffen. ^[14]

2.4.4 Rich Site Summary (RSS)

„RSS [...] ist ein XML-basiertes Format für die Inhaltsverbreitung über das Web. Durch ein RSS-Dokument wird ein RSS-Kanal [...] definiert, in dem mehrere Artikel, die über das Web erreichbar sind, zusammengefasst werden.“^[15]

2.4.5 Cascading Style Sheets (CSS)

„Cascading Style Sheets (CSS), ist eine deklarative Stylesheet-Sprache für strukturierte Dokumente. Sie wird vor allem zusammen mit HTML und XML […] eingesetzt. CSS soll dabei festlegen, wie ein besonders ausgezeichneter Inhalt dargestellt werden soll. Dazu ist es wichtig, das HTML oder XML so zu gestalten, dass die Abschnitte, deren Aussehen gleich sein soll, auch als Gruppe erkannt werden können. Man zeichnet im Dokument also die Bedeutung einzelner Abschnitte aus, während das Aussehen dieser ausgezeichneten Abschnitte im CSS festgelegt wird.“ ^[16]

2.5 Skalierbarkeit

Skalierbarkeit beschreibt den Zusammenhang zwischen Ressourcen und Leistung. In der Informatik wird in diesem Zusammenhang auch von Komplexität und Perfomance gesprochen, wobei die Komplexität die Schwierigkeit (oder auch „Komplizierheit“) eines Problems oder einer Aufgabe beschreibt und die Performance die Leistung des Systems. Skalierbarkeit beschreibt nun den relativen Zusammenhang zwischen den Größen „Ressourcen“ und „Leistung“.

Hierzu ein kleines Beispiel: Steigen die Anforderungen an ein System in Form von Abfragen, Datenmenge etc. beispielsweise um 100% an, verdoppelt sich also die nötige Leistungsfähigkeit. Steigt nun der Ressourcenbedarf des Systems ebenfalls um 100% an, spricht man hier von einer guten Skalierbarkeit. Ein schlecht skalierbares Programm würde bei der Verdoppelung der Anforderungen vielleicht bereits die 5 oder gar 10-fache Leistungsfähigkeit benötigen um die gewünschten Ergebnisse in der gleichen Zeit liefern zu können. (siehe Abbildung 2)

So entsteht die Möglichkeit Ressourcen so zu bestimmen, dass die Anforderungen sich linear zu der benötigten Leistungsfähigkeit verhalten. Ist ein System mit 2000 Usern so bereits am Limit angelangt ist eine Verdoppelung der eingesetzten Hardwareleistung ausreichend die Anforderungen auch für 4000 User zu erfüllen. ^[17]

Die spätere Anpassung an wachsende Anforderungen ist über die Skalierbarkeit der Anwendungen so vereinfacht durchzuführen. So ergibt sich an dieser Stelle lediglich die Notwendigkeit die Anzahl der User und der Zugriffe, zu ermitteln um im Folgenden die nötigen Systemkomponenten bedarfsgerecht zu bestimmen. Die genauen Zahlen lassen sich im Vorfeld nur annäherungsweise bestimmen, die Zahlendaten aus dem oben aufgeführten Punkt 1.2 [Zielgruppenanalyse (Fans, Presse und Investoren / Sponsoren)] können genutzt werden um die potenzielle maximale Zugriffzahl zu bestimmen.

Die zu erfassenden Datenmengen, wie z.B. Spielstände, Spielergebnisse, Spielernamen, Schiedsrichter, Courts, Zuschauerzahl usw. lassen sich aus dem Punkt 5.1 [Grundlagen des Turnierverlaufes] ablesen oder zumindest ableiten.

2.6 RAID-System

RAID beschreibt einen Verbund von Festplatten, welcher nach Außen hin als eine einzige Festplatte agiert und anzusprechen ist. Der Vorteil von RAID ist, dass mehrere Festplatten gemeinsam die Daten halten und, je nach RAID-Level, dabei erhöhte Performance und/oder erhöhte Ausfallsicherheit im Falle von Datenträgerausfällen bieten können.

Das gebräuchlichste RAID-Level in der Unternehmenspraxis ist RAID 5, auf andere Level wird daher hier nicht weiter eingegangen:

RAID 5 beschreibt einen Verbund aus mindestens 3 Festplatten, welche einen logischen Datenträger abbilden. Hierbei werden die RAID-Level 0 und 1 kombiniert, denn die Daten werden gleichzeitig auf mehrere Festplatten geschrieben, was die Performance steigert, und außerdem noch mit Hilfe von Parity-Daten ausfallsicher abgelegt (siehe Abbildung 3).

2.7 Cloud-Computing

„Der Begriff des Cloud-Computing umfasst im Allgemeinen die Zurverfügungstellung von Softwarediensten, einer Plattform und einer Infrastruktur über das Internet.“^[18](siehe Abbildung 4)

Diese Zuverfügungstellung von Diensten und Plattformen erfolgt vornehmenlich in serviceorientierten Architekturen, in deren technischem Fokus „die Modellierung, der Test, die Simulation,Skalierbarkeit, Ausfallsicherheit,Konfigurierbarkeit, die zugrundeliegenden Architekturen und Austauschformate für Dienstleistungen“^[19] stehen.^[20]

Weitere Vorteile von Cloud-Computing (auch ASP: application service provision) sind:

• Die entfallende Notwendigkeit „teure und eventuell selten genutzte Anwendungen lokal zu installieren, sondern man überträgt die Verantwortung einem Dienstleister, der sich zusätzlich um die Pflege und Wartung des Systems kümmert.“^[21]
• Die Möglichkeit für kleine und mittlere Betriebe Anwendungen zu realisieren, die sich sich sonst nicht leisten können, oder die wegen Mangels an Know How nicht umgesetzt werden können.^[22]
• Die Skalierung des Systems erfolgt on demand, also wird live mehr Kapazität zur Verfügung gestellt, wenn diese benötigt wird. (Stichwort: Skalierbarkeit, Punkt 2.5)
• Die Bezahlung erfolgt ebenfalls on demand, das heißt die Abrechnung erfolgt auf Basis der Nutzung des Systems, „ein häufig benutztes Werbeargument der Outsourcing-Dienstleister.“^[23]

2.8 Eingabe-Verarbeitung-Ausgabe Prinzip (EVA)

„Das EVA-Prinzip ist eines der wichtigsten Prinzipien der Softwareentwicklung und sollte bei jedem Programmierer bekannt sein. Ausgeschrieben heißt EVA “Eingabe Verarbeitung Ausgabe” und beschreibt den Ablauf eines Programms. Laut dem EVA-Prinzip sollen zuerst Daten eingegeben, dann verarbeitet und am Ende ausgegeben werden.“ ^[24]

3 Konzeption Live-Ergebnis System

3.1 Vorhergehensweise

Zur Untersuchung der Thematik wurde sich innerhalb der Projektplanung für die Anlehnung des EVA-Prinzips geeinigt. Neben einer grundsätzliche Betrachtung und Zieldefinierung erfolgt die Konzeptionierung somit aufgeteilt in den Module Eingabe, Verarbeitung und Ausgabe.

3.2 Betrachtung von bestehenden Systemen

Ziel ist, die Funktionen, bestehender Systeme zu identifizieren. Die Grundfunktionen sind hier in vielen Sportarten identisch, so dass auch Live-Ergebnissysteme aus anderen Sportarten betrachtet werden können.

Aus einer Analyse Squash-fremder Systeme ^[25] haben sich die folgenden Funktionen ergeben:

• Spielplanübersicht

• Eine Übersicht über alle laufenden, anstehenden und bereits gespielten Partien mit Ergebnissen und Zwischenständen.

• Aktuelle Tabelle (Blitztabelle)

• Es wird die momentan gültige Tabelle angeboten und eine Blitztabelle generiert, die auch laufende Partien berücksichtigt.

• Live-Ticker

• Momentan laufende Partien können live betrachtet werden.
• Kommentare zum Spielverlauf in Textform.
• Informationen und Bilder zu den einzelnen Spielern oder Mannschaften werden eingeblendet.

• Übersicht über die Akteure und Mannschaften

• Es können Bilder, Texte und Statistiken zu den verschiedenen Spielern und/oder Mannschaften angezeigt werden.

• Zusatzfunktionen im Live-Ticker

• Bei gleichzeitig laufenden Partien können diese simultan im Ticker angezeigt werden. (Konferenzschaltung)
• Bei bestimmten Spielereignissen (Punktgewinne, Fouls etc.) kann ein Ton aktiviert werden.

Bei der Recherche wurde zudem ein lauffähiges Squash Turniersystem namens Squash-Draw^[26] gefunden. Das System besitzt einen hohen Umfang zur Darstellung der Ergebnisse (in Live-Form) sowie den Charakter einer Turnierdokumentation. Eine weitere Betrachtung findet in dieser Studie jedoch nicht statt. Grund sind der Schwerpunkt der Arbeit auf die konzeptionellen und technischen Aspekte und Anforderungen einer derartigen Anwendung.

3.3 Funktionsumfang

Das System muss zunächst über Grundfunktionen verfügen. Diese sind im Punkt 3.1 bereits aufgeführt.

Darüber hinaus wurden in einem Gespräch einige Zusatzfunktionen ausgewählt, so dass sich die Gesamtauswahl der Funktionen nun wie folgt darstellt:

3.3.1 Zeitnahe Erfassung der Daten (Punkte, Zeiten, etc.) während des Spiels

Zur zeitnahem Erfassung der Spieldaten, wie bspw. Punktgewinne, Aufschlagswechsel, Letballs etc. muss am Austragungsort, vielmehr direkt am entsprechenden Court eine Möglichkeit bestehen, die Daten in möglichst geringem zeitlichen Verzug in das System einzugeben.

3.3.2 Speicherung der Daten auf einem zentralen System

Wie im vorangestellten Punkt 4.2 [Zeitnahe Erfassung der Daten (Punkte, Zeiten, etc.) während des Spiels] beschrieben, kann die Datenerfassung auf verschiedene Arten realisiert werden. Die Weitergabe der entsprechenden Daten an den Erfasser könnte z.B. mittels herkömmlicher Funkgeräte realisiert werden, da die Übertragungsstrecke laut Grundriss ^[27] maximal einige hundert Meter betragen kann und dies bereits mit günstiger technischer Ausrüstung durchgeführt werden kann.

An der zentralen Stelle muss dann ein Erfasser (bei parallelen Spielen auch mehrere möglich) an einem Eingabearbeitsplatz die Durchsagen entgegenehmen und in das System einpflegen. Alternativ kann (wie oben erwähnt) auch an jedem Court ein solcher Eingabearbeitsplatz mit Personal eingesetzt werden, oder mobile Geräte werden zur Weitergabe der Informationen genutzt, so erleichtert sich die Eingabe von Kommentaren zum Spiel. Eine Ausarbeitung der weiteren Eingabe- und Weitergabemöglichkeiten findet sich im nachfolgenden Input-Modul.

3.3.3 Augabe der Informationen

• Spielplanübersicht
  • Eine Übersicht über alle laufenden, anstehenden und bereits gespielten Partien mit Ergebnissen und Zwischenständen.
• Aktuelle Tabelle (Blitztabelle)
  • Es wird die momentan gültige Tabelle angeboten und eine Blitztabelle generiert, die auch laufende Partien berücksichtigt.
• Live-Ticker
  • Momentan laufende Partien können live betrachtet werden.
  • Informationen und Bilder zu den einzelnen Spielern oder Mannschaften werden eingeblendet.

• Übersicht über die Akteure und Mannschaften
  • Es können Bilder, Texte und Statistiken zu den verschiedenen Spielern und/oder Mannschaften angezeigt werden.
  • Kommentare zum Spielverlauf in Textform.

4 Ausarbeitung des Moduls: Erfassung (Input)

Die Datenerfassung oder Dateneingabe ist ein aufwendiger Prozess und ausschlaggebender Punkt für die Qualität und somit auch für den Erfolg eines Informationssystems. Aus diesem Grund widmet sich dieser Teil der Facharbeit der konzeptionellen Planung zur bedarfsgerechten Umsetzung eines Eingabemoduls für die Squash WM.

Das Eingabemodul gliedert sich in zwei Untermodule. Ein Modul, dass speziell für die Erfassung von Daten eines laufenden Spiel verwendet werden soll und ein weiteres Modul, welches für die Erfassung der grundlegenden Daten verwendet werden soll. Beide Module haben eigene Anforderungen und kritische Punkte, die im Laufe dieses Kapitels durchleuchtet werden.

Allgemein gibt es drei kritische Faktoren bei der Datenerfassung, die während der kompletten Konzeption, berücksichtigt werden müssen.^[28]

• Zeitaufwand
• Fehleranfälligkeit
• Kostenaufwand

Das grundlegende Ziel dieses Kapitels ist es die Daten zu Erfassen und an das verarbeitende System (Datenbankserver) zu übermitteln, in der sie weiter verarbeitet werden können. In diesem Kapitel wird häufig von Benutzern gesprochen mit denen die Personen gemeint sind welche die Datenerfassung durchführen.

4.1 Authentifizierung und Autorisierung

Es gibt eine Vielzahl von Authentifizierungsmethoden, beispielsweise die Authentifizierung über Zertifikate, Schlüsselverfahren bis hin zur biometrischen Authentifizierung. Diese Verfahren sind allerdings äußert aufwendig und dadurch sehr kostenintensiv.

Die Sensibilität der Daten für das Live System ist allerdings gering, da die Daten ohnehin veröffentlich werden sollen. Aus diesem Grund kann von einer solch aufwendigen Methode abgesehen werden. Es sollte allerdings sichergestellt werden, dass die Daten nicht durch Unbefugte manipuliert werden können. Um dies sicherzustellen ist ein gängiger Standard, wie eine Authentifizierung mittels eines Benutzernamens und eines Kennworts, ausreichend. Bei der Verwendung der sogenannten Passwort Methode sollten allerdings folgende Sicherheitsziele festgelegt werden.^[29]

• Das Kennwort sollte eine Mindestlänge haben und aus einer Kombination von Buchstaben, Zahlen und Sonderzeichen bestehen.
• Das Kennwort sollte aber auch nicht zu komplex sein, damit der Benutzer es sich merken kann
• Ein Zugang sollte nach mehrfacher falscher Eingabe des Kennworts, standardmäßig drei Mal, gesperrt werden
• Der Benutzername sollte kryptisch sein, also nicht dem Namen des Benutzers entsprechen

Desweiteren sollte in Benutzergruppen unterteilt werden. Über diese Benutzergruppen wird geregelt, welcher Funktionsumfang einem Benutzer zur Verfügung steht. Der Funktionsumfang sollte sich dabei nur auf die notwendigsten Funktionen beschränken.^[30]

Eine weitere Absicherung kann erzielt werden, indem der Zugriff nur durch registrierte Geräte erfolgen kann. Die Registrierung könnte anhand der einzigartigen Media-Access-Control-Adresse (MAC-Adresse) einer jeden Netzwerkkarte erfolgen.

Werden alle genannten Aspekte berücksichtigt sollte eine ausreichende Sicherung des Systems bestehen.

4.2 Datenselektion

Die Datenselektion befasst sich mit der Frage, welche Daten erfasst werden sollen. Allgemein formuliert bedeutet dies, dass von einer vorhandenen Menge an Informationen die Relevanten ausgewählt werden und identifiziert wird, welche Attribute zu einem Datensatz Mindestenz bekannt sein müssen um diesen in das System zu übernehmen. Ein Datensatz kann beispielweise ein Spieler sein und die entsprechenden Attribute wären Vor- und Nachname.

Bei der Datenselektion sollte sorgfältig vorgegangen werden, denn hier liegt ein enormes Potential den Zeitaufwand und damit einhergehend die Anzahl der fehlerhaften Eingaben zu reduzieren.

An erster Stelle bei der Datenselektion steht die Frage nach der Verfügbarkeit der Daten. Da der Betreiber des Live-Ergebnissystems auch der Veranstalter der Squash WM ist, sollten alle Basisdaten zum Turnierverlauf und teilnehmenden Mannschaften zur Verfügung stehen. Sollten allerdings weiter detaillierte Informationen, beispielsweise zu den Spielern, hinzugefügt werden, kann der vorhandene Datenbestand ggf. nicht ausreichen und es muss nach entsprechenden Informationsquellen recherchiert werden. Bei der Auswahl sollte ebenfalls die ausgewählte Zielgruppe berücksichtigt werden, indem geprüft wird, ob die Daten für diese relevant und interessant sind.^[31]

Ein weiterer wichtiger Punkt ist es eine Redundanz der Daten zu vermeiden. Hier spielt der Kostentreiber Zeit eine große Rolle und zusätzlich kann die Performance der Server unter einer zu großen Datenlast leiden. Des Weiteren ist bei der Datenselektion auf Vollständigkeit und Konsistenz der Daten zu achten, sodass das Wiederholen von Eingaben vermieden wird.^[32]

Innerhalb der Datenselektion sollte festgelegt werden, welche Ereignisse zu einem laufenden Spiele erfasst werden sollen. Hierbei sollten alle Ereignisse berücksichtigt werden, die dem Zuschauer einen realistischen Eindruck über den Spielverlauf vermitteln. Zu jedem Ereignis muss, soweit für das Spielerverständnis relevant, der betroffene Spieler und der Zeitpunkt des Ereignisses mit erfasst werden.

Im Rahmen dieser Fallstudie wurden folgende Spielereignisse festgelegt.

• Spielbeginn
• Aufschlagwechsel
• Punktgewinn
• Sets
• Stop
• Let
• Foul
• Strafschlag
• Satzstrafe
• Verwarnungen
• Disqualifikation
• Verletzungen

Ereignisse, wie Spielende und Satzende brauchen nicht erfasst werden, da sie sich automatisch aus den angegebenen Ereignissen berechnen lassen.

Zusätzlich sollen beliebig viele Kommentare zu einem Spiel hinzugefügt werden können. Die Kommentare sollen die Funktion eines Moderators einnehmen um einen intensiveren Spieleindruck zu erhalten. Ein solcher Kommentar könnte wie folgt aussehen.

"18:36:46: Der 28 Jahre alte Spieler der deutschen Nationalmannschaft, Max Mustermann, dominiert klar das Spiel und lässt keine Chance aus einen weiteren Punkt zu erzielen."

Im Umfang dieser Fallstudie wurde sich auf folgenden Datenumfang geeinigt (siehe Abbildung 5). Der Umfang ist eine exemplarische Auswahl speziell für diese Fallstudie, um ein besseres Verständnis für das folgende Konzept zu vermitteln.

4.3 Datenerfassung

Die Datenerfassung beschäftigt sich mit der Frage, wie und wo können die selektierten Daten bestmöglich Eingegeben werden. In diesem Vorgang liegt ein zusätzliches Potential um den Zeitaufwand weiter zu reduzieren und die Datenqualität zu verbessern. Insbesondere durch die Wahl des richtigen Mediums kann die Erfassungsgeschwindigkeit stark gesteigert werden.

Bei der Entwicklung der beiden Module sollte möglichst die gleiche Technologie zum Einsatz kommen um die Kompatibilität zu verbessern und den Aufwand der Entwicklung zu reduzieren.

4.3.1 Datenerfassung in Echtzeit

Squash kennzeichnet sich hauptsächlich dadurch aus, dass es eine sehr schnelle Sportart ist und hohe Konzentration der Spieler vorrausetzt. Es muss dem Benutzer also möglich sein den Spielverlauf während der Eingabe zu folgen und dies auch wenn ggf. Korrekturen bei der Eingabe vorgenommen werden müssen. Weiterhin sollte die Eingabe direkt vor Ort durchgeführt werden, damit der Benutzer das Spiel aufmerksam verfolgen kann.

Wichtig ist, dass der Benutzer beim Erfassen hauptsächlich an den Angaben der Offiziellen orientiert und nicht durch reines betrachten des Spielverlaufs eigene Eindrücke in das System eingibt. Beispielsweise sieht er, dass ein Punkt erzielt wird aber der Offizielle vergibt den Punkt nicht, weil er ihn im Aus gesehen hat. Die erfassten Informationen sollen also immer dem realen Spielergebnis entsprechen.

Als praktikables Medium kommen grundsätzlich zwei Arten in Frage. Erstens die Daten werden handschriftlich auf einem speziell konzipierten Ergebnisbogen notiert und in regelmäßigen Intervallen in das System eingegeben und Zweitens: die Daten werden direkt mit Hilfe einer Anwendung in das System eingeben. Die handschriftliche Erfassung weißt dabei einige signifikante Nachteile auf, zum einem entsteht durch die doppelte Erfassung ein erhöhter Personallaufwand, denn es werden mindestens zwei Personen benötigt. Eine Person welche die Daten handschriftlich erfasst und eine weitere welche die Daten im System erfasst. Zum Anderen leidet die Datenkonsistenz, denn die Daten können unleserlich oder falsch notiert werden und/oder falsch im System eingegeben werden. Des Weiteren entsteht eine nicht unwesentliche zeitliche Verzögerung zwischen der ersten Datenerfassung und der Digitalisierung.

Die zweite Möglichkeit ist die Eingabe über ein speziell für die Squash WM konzipierte Anwendung. Die ausschlaggebenden Vorteile hierbei sind, dass eine enorme Verbesserung der Datenkonsistenz erfolgt, da direkt bei der Eingabe eine logische Überprüfung anhand des offiziellen Regelwerks erfolgen kann und dass Daten, wie Zeitangaben (Zeitstempel) nicht notiert oder eingeben werden müssen sondern automatisch durch das System berechnet werden.

Ergebnisbogen	Anwendung
Vorteile:	Vorteile:
Geringer Schulungsbedarf Keine zusätzliche Hardware notwendig	Live, die Daten werden mit einer nicht merkbaren zeitliche Verzögerung eingegeben Verbesserung der Datenkonsistenz, durch logische Überprüfung direkt bei der Eingabe
Nachteile:	Nachteile:
Doppelte Erfassung der Daten, dadurch ein erhöhter Personallaufwand Schlechte Datenkonsistenz, durch unleserlich oder falsch notierte Daten und/ oder falscher Eingabe Keine Erfassung in Echtzeit	Hoher Schulungsbedarf Erhöhte Entwicklungskosten Zusätzliche Hardware wird benötigt

Entscheidet man sich für die Alternative einer Anwendung muss im nächsten Schritt entschieden werden, welche Plattform, also Hardware und Betriebssysteme, verwendet bzw. unterstützt werden sollen. Ziel ist es eine möglichst kostenneutrale Lösung zu finden, was mit einschließt, dass bereits vorhandene Ressourcen verwendet werden sollen. Deswegen kann davon ausgegangen werden, dass keine homogene Gruppe an Plattformen gegeben ist, wodurch eine möglichst Plattform unabhängige Umsetzung der Anwendung erfolgen sollte.

Mögliche Komponenten für die Client-Hardware könnten stationäre Personal Computer sein, die an jedem Court aufgebaut sind, oder mobile Endgeräte wie Notebook, Smartphone, Pocket-PC oder Tablet-PC. Durch die diversen Hardwarekomponenten kann auch von einer Vielzahl von verschiedenen Betriebssystemen ausgegangen werden.

Es besteht somit die Möglichkeit die Anwendung als Programm, Smartphone App oder Webanwendung zu entwickeln. Im Normalfall sind, beispielsweise Windows Programm nicht auf einem Macintosh-Computer lauffähig auf nicht auf einem Smartphone, dass selbe gilt auch in die andere Richtung. Das Konzept die Anwendung für jede Plattforum zu entwickeln kann verworfen werden, da es definitiv zu zeit- und kostenintensiv ist. Dadurch bleibt als gangbare Alternative, die plattformunabhängigste Methode, die Anwendung als Webanwendung zu entwickeln.

Der signifikanteste Vorteil einer Webanwendung ist, dass Sie auf dem Gerät lediglich einen Browser voraussetzen, welcher im Normalfall standardmäßig bereits vorhanden ist.^[33]

Um einen Höchstgrad an Plattformunabhängigkeit zu erreichen sollte bei der Umsetzung darauf geachtet werden, dass die Anwendung mit den gängigsten Browsern kompatibel ist.^[34] Die folgende Statistik vom Dezember 2010, zeigt die weltweiten Markanteile der gängigsten Browser.

Es gibt aber auch Nachteile beim Einsatz einer Webanwendung, die bei der weiteren Konzeption berücksichtigt werden müssen. Eine Webanwendung benötigt eine ständige Verbindung zum Server. Desweitern müssen ausreichend geringe Latenzzeiten zur Verfügung stehen, damit die Anwendung ordentlich betrieben werden kann und nicht auf Grund eines Timeouts die Verbindung zum Server verloren wird.^[35]

Microsofts .NET und Sun Microsystems Java EE sind zwei Technologie Plattformen die eine solche webbasierte Anwendungsentwicklung unterstützen.^[36] Alternativ ist eine Umsetzung auch als PHP: Hypertext Preprocessor (PHP) Anwendung mit JavaScript und Asynchronous JavaScript and XML (Ajax) Elementen möglich.

4.3.2 Vorbereitende Datenerfassung

Die Erfassung der Basisdaten kann am besten über ein GUI mit intelligenten Formularen erfolgen, die den Benutzer bei der Eingabe unterstützten und gleichzeitig die Daten, soweit möglich auf Plausibilität prüft.

Wie bei der Konzeption der Echtzeitdatenerfassung festgestellt wurde ist eine naheliegende Lösung eine Webanwendung zu entwickeln. Aus diesem Grund werden die Lösungsansätze für dieses Modul ebenfalls auf eine Webanwendung bezogen.

Möglichkeiten solche intelligenten Eingabeformulare, welche häufig als interaktive Frageböge bezeichnet werden, im Web umzusetzen, bieten die Technologien HTML mit HTML -Formulare oder XML in Form von XForms. ^[37]

Beide Technologien bieten den nötigen Funktionsumfang um die Anforderungen umzusetzen. Bei HTML-Formularen muss allerdings eine Script-Sprache, wie JavaScript, verwendet werden um die nötige Dynamik zu erhalten. ^[38] Die folgende Tabelle verschafft einen Überblick über die für die Fallstudie relevanten Vor- und Nachteile der beiden Technologien.^[39]

HTML-Formulare	XForms
Vorteile:	Vorteile:
Weit verbreitet, dadurch entsprechendes Know-How vorhanden Hohe Kompatibilität mit PHP und JavaScript	XML als Datenformat, dadurch plattformunabhängig Hoher Funktionsumfang Strikte Trennung von Layout und Daten
Nachteile:	Nachteile:
Schwierig zu initialisieren ( Formular mit vorgebenden Daten zu füllen) Abhängig von Script-Sprachen (wie JavaScript)	Komplex in der Umsetzung Nicht kompatibel zu HTML Formularen

Obwohl XForms einige Vorteile gegenüber HTML-Formularen bietet ist HTML noch der gängige Standard.^[40] Dementsprechend ist mehr Know-how für diese Technologie vorhanden, wodurch sie eine Umsetzung schneller und vor allem kostengünstiger Umsetzen lässt.

Sind bereits viele der Daten in digitaler Form vorhanden ist eine weitere Alternative die Implementierung einer Schnittstelle für Dateiimporte. Die standard Formate für solche Dateiimporte sind CSV oder XML. Über eine solche Schnittstelle können CSV oder XML Dateien eingespielt werden, wodurch sich die zeitlich sehr aufwendige manuelle Erfassung enorm reduziert. Es entsteht lediglich ein Aufwand, wenn die Daten nicht in den geforderten Formaten vorliegen und erst eine Konvertierung notwendig ist. Bei der Implementierung solcher Schnittstellen entsteht natürlich ein erhöhter Entwicklungsaufwand, der sich aber ab einer gewissen Datenmengen in Relation zum Personalaufwand schnell amortisiert.

4.4 Qualitätsmanagement

Die Datenqualität kann verbessert werden indem eine zusätzliche Person die Daten möglichst beim oder kurz nach dem Erfassen überprüft und ggf. korrigiert. Um den Personalaufwand dabei möglichst gering zu halten, könnten ein der zwei Personen eingesetzt werden, die alle laufenden Spiele an einer zentralen Stelle, bspw. über einen Monitor verfolgen und dabei die Eingaben in das System überwachen.

4.5 Datenübermittlung

Die Datenübermittlung von der Anwendung zum Server ist abhängig von der gewählten Technologie zur Umsetzung der Software. Die Datenübertragung bei einer PHP-Anwendung kann über sogenannte Posts erfolgen, dabei werden die Daten an den Webserver geschickt und mittels SQL-Statements in die Datenbank geschrieben. Eine weitere Variante ist es, die erfassten Daten als XML-Dateien zu speichern und welche regelmäßig an den Datenbankserver übermittelt wird. Die gängigsten Datenbankserver haben standardmäßig eine Schnittstelle für XML-Dateien. Einen zusätzlichen Vorteil bei XML-Dateien ist der, dass die Daten ohne großen Aufwand an mehrere verschiedenartige Datenbankserver übermittelt werden kann, was auf die plattformunabhängigkeit von XML zurückzuführen ist.

4.6 Konzept für einen Prototyp

Im Rahmen dieser Fallstudie wurde ein Konzept für einen Prototyp einer Anwendung zum Erfassen der Daten eines laufenden Spiels erstellt. Der ausschlaggebende Grund, dieses Konzept innerhalb der Fallstudie zu Entwickeln war der, dass die Live Spielerergebnisse den zentralen Mittelpunkt des Systems darstellen und diese ohne die Möglichkeit einer sauberen und zeitnahen Erfassung nicht realisierbar sind.

4.6.1 Grundlegende Informationen zum Prototypen

Das Konzept für den Prototyp basiert auf einer ereignisbedingten Steuerung, da bis auf die Kommentare zu den Spielen nur Ereignisse erfasst werden müssen. Die Eingabe erfolgt dabei ausschließlich über Buttons, um ein zeitaufwendiges Eintippen zu vermeiden. Die Eingabe vom Kommentaren wird in diesem Konzept nicht mit berücksichtigt, da der Fokus auf den Spielereignissen liegen soll.

Desweiteren wird bei der Erfassung jedes Ereignisses der Zeitpunkt der Eingabe gespeichert, sodass der Aufwand den Zeitpunkt manuell zu Erfassen entfällt. Zusätzlich erhält man einen genaueren Zeitpunkt als bspw. über eine Analoge Uhr. Hierbei wird auf die Uhrzeit des Servers zugegriffen und nicht auf die Uhrzeit des Clientgeräts, denn diese kann durch den Benutzer verstellt werden.

Alle grundlegenden Informationen zu den Spielen, wie die Zuordnung der Teams und somit der Spielern sind bereits durch die vorbereitende Datenerfassung erledigt wurden.

4.6.2 Beschreibung des Prototyps

Es folgt eine konzeptionelle Beschreibung, die den Ablauf und die Funktionsweise des Prototyps beschreibt. Die folgenden Abbildungen 8 bis 11 dienen lediglich zum besseren Verständnis der Ablaufbeschreibung und sind keine Vorlage für die eigentliche Entwicklung.

Im ersten Schritt meldet sich der Benutzer, der das Spiel erfasst über die Webanwendung mit seinen Zugangsdaten am Server an (siehe Abbildung 8 - Links).Anschließend wählt er das entsprechende Spiel aus.

Beginnt das Spiel, erfasst der Benutzer es indem er auf den Button "LOG EVENT" in der Hauptansicht klickt (siehe Abbildung 8 - Rechts). Der Button "LOG EVENT" wird während des gesamten Spielverlaufs dazu verwendet neue Ereignisse einzugeben. Das erste Ereignis ist immer der Spielbeginn, deswegen öffnet sich automatisch eine Ansicht, indem der Benutzer angeben muss, welcher Spieler den ersten Aufschlag hat. Nach Auswahl der Spieler befindet sich der Benutzer wieder in der Hauptansicht.

Erzielt der Spieler nun einen Punkt, drückt der Benutzer erneut auf den Button "LOG EVENT" nun gelangt er in eine neue Ansicht indem ihm eine Liste angezeigt wird die alle möglichen Ereignisse anzeigt (siehe Abbildung 10). In dieser Liste wählt der Benutzer mit einem Klick auf das Ereignis „POINT“, den Punktegewinn aus. Der Spieler der momentan Aufschlag hat erhält dadurch automatisch einen Punkt.

Folgen mehrere Ereignisse zu schnell aufeinander, beispielsweise gibt es einen Aufschlagwechsel und der Spieler erzielt umgehend einen Punkt, kann es sein, dass die Erfassung des ersten Ereignisses noch nicht abgeschlossen ist. Für diesen Fall ist auf jeder Ansicht der Anwendung der Button "LOG EVENT" um ein weiteres Ereignis zu erfassen. Dieses neue Ereignis wird automatisch in die Liste aufgenommen und nach dem Fertigstellen der Eingabe des aktuellen Ereignisses, muss der Benutzer dieses Ereignis vervollständigen.

Abbildung: 8 - Prototyp: Login und Spiel vor dem Start

Abbildung: 9 - Prototyp: Laufendes Spiel - Übersicht

Abbildung: 10 - Prototyp: Ereignisauswahl

Abbildung: 11 - Prototyp: Ereignisprotokoll

Hat der Benutzer ein Ereignis falsch erfasst, kann er es über das Ergebnisprotokoll (siehe Abbildung 11) bearbeiten oder löschen. Durch das Löschen oder Ändern kann sich allerdings der komplette Spielverlauf ändern. Wenn beispielsweise ein Aufschlagwechsel fälschlicherweise als Punkt erfasst wurde und anschließend noch weitere Punkte erfasst wurden, dann würde dieser Punkte dem falschen Spieler zugeordnet. Korrigiert der Benutzer das Ereignis von einem Punkt in ein Aufschlagwechsel, werden die vergebenen Punkte automatisch dem Spieler der an dieser Stelle Aufschlag hat zugeordnet. Dieser Ablauf soll dafür sorgen, dass der Benutzer mit wenigen Klicks wieder auf dem korrekten Stand des Spiels ist und dem Verlauf weiter folgen kann.

Die Berechnung für einen gewonnen Satz oder ein gewonnenes Spiel erfolgt automatisch, nach dem offiziellen Regelwerk, durch das System. Ist ein Satz oder Spiel nach den Eingaben des Benutzers gewonnen, erhält der Benutzer eine Sicherheitsabfrage, ob das Spiel wirklich beendet ist. Diese Frage kann der Benutzer mit "Ja" oder "Nein" beantworten. Wählt der Benutzer "Nein" erhält er die Möglichkeit die Ereignisse zu korrigieren, wählt er "Ja" wird das Spiel abgeschlossen.

5 Ausarbeitung des Moduls: Verarbeitung und Speicherung (Processing)

5.1 Systemanforderungen

5.1.1 Bestandteile des Moduls "Processing"

In Anlehnung an die Funktionsweise des Systems ergeben sich folgende benötigte Komponenten zum Aufbau des Processing-Moduls:

Hardwareseitig:

Bezeichnung der Hardware	Erläuterung
Datenbankserver	Server zur Verwaltung und Administration der Datenbank als Datenbasis für das gesamte System
NAS[41]	Speicherlösung mit RAID-Funktionalität[41] zur Speicherung der Daten
Erfasser-PC	Clients zur Erfassung/Eingabe der Daten
Webserver	Server zwecks Hosting der Website auf welcher die Inhalte präsentiert bzw. veröffentlicht werden
Proxy-Server	Schnittstellenserver (Webserver <-> Internet)
Netzwerkinfrastruktur	Ausfallsicheres internes Netzwerk zwecks Anbindung der Module untereinander und an das Internet

Hierbei ist, zwecks Ausfallsicherheit, jedes der Systeme redundant aufgebaut. So sollten Datenbankserver, Anwendungsserver, Webserver und Proxyserver jeweils als Clusterlösung^[42] aufgesetzt werden, da ein Hardwareausfall hiermit kompensiert werden kann.

Auf Basis von Informationen des MS Technet^[43] kann die Serverzahl weiter reduziert werden, ohne die gewünschte Ausfallsicherheit dadurch zu mindern. Hier wird beschrieben, dass jeder Server verschiedene Aufgabenrollen innerhalb der Serverfarm übernimmt, bzw. übernehmen kann, wenn dies möglich ist. So kann die Funktionalität des Webservers bspw. durch den Proxyserver mitgetragen werden.

Hier reduzieren sich die minimale Anzahl der benötigten Server um 3, da jede der Maschinen die Aufgaben der jeweils anderen Geräte übernehmen kann, falls es hier zu einem Ausfall kommt. Schematisch dargestellt wird dies in Abbildung 12:

Die Anzahl der Server innerhalb der Clusterfarmen muss hierbei den Anforderungen angepasst werden. Sind mehr Benutzer im System und rufen Daten ab muss bzgl. der Performance die Anzahl der Maschinen erhöht werden. Siehe 2.5.

Softwareseitig:

Bezeichnung der Software	Erläuterung
Datenbanksystem	Bestehend aus Datenbankmanagementsystem und Datenbank
Webserver-Software	Software zwecks Hosting der Website auf welcher die Inhalte präsentiert bzw. veröffentlicht werden
Serverbetriebssysteme	Clusterfähiges Betriebssystem zum Betrieb der Server

Da nun bekannt ist, welche Komponenten benötigt werden erfolgt nun eine kurze Auflistung der benötigten Funktionen, welche die unterschiedlichen Komponenten bieten müssen.

5.1.2 Anforderungen an das System

Wie bereits erwähnt, sollten die Anforderungen an die Datenbank und das tragende Hardwaremodell definiert werden, bevor eine Auswahl erfolgen kann.

Die Hardware muss hier folgende Bedingungen erfüllen:

Bezeichnung der Hardware	Benötigte Funktionen
Serverhardware	Leistungsfähige Serverhardware mit redundantem Netzwerkanschluss (3 Ports zwecks Clustering und redundatem LAN)
Clients	Möglichst günstig, da lediglich eine Anwendung aufgerufen werden soll (Eventuell ThinClients)
Netzwerkswitche	redundante Netzwerkswitche mit STP[44]
Router mit Internetanbindung	redundante Router
Storage-Einheit	Ausfallsichere Speichereinheit mit RAID-Funktion, redundanter Netzwerkanbindung und Zugriffkontrolle

Für die Software ergeben sich folgenden Anforderungen:

Bezeichnung der Software	Benötigte Funktionen
Clientbetriebssysteme	Simples BS mit Unterstützung der Dateneingabesoftware (DB-Software)
Datenbanksystem	Günstige und leistungsgerechte Datenbanklösung.
Webserver-Software	Ergibt sich aus dem Modul "Output"
Serverbetriebssysteme	Muss clusterfähig sein.

5.2 Konzeptionierung des Moduls "Processing"

5.2.1 Hardware und Software (Aufbau und Funktionsweise)

Das Storage und Processing Modul muss die oben bereits genannten Funktionen bieten. Dies sind somit eine Datenbank mit Eingabemöglichkeiten, ein redundant angebundenes NAS, redundante Servertechnik (mit Webserver, Proxyserver und Datenbankserver) und eine redundante Netzwerkinfrastruktur.

Der Aufbau erfolg an einer zentralen Stelle im Gebäude,jedoch sollten die Erfasser-PCs räumlich von der Serverhardware getrennt werden. So ergibt sich kein Zugriff der Erfasser auf die Backbone^[45]-Technik

Der Aufbau und die Vernetzung können sich (schematisch) wie folgt darstellen:

Hier kann betrachtet werden, dass die Anbindung der Server und des NAS an die Router jeweils redundant umgesetzt wird. Der Ausfall eines Routers, eines Netzwerkanschlusses, eines Servers^[46] oder einer Netzwerksstrecke, können vom System kompensiert werden.

5.2.2 Alternative "Cloud"

Durch die Tatsache, dass sich eine Abschätzung der Nutzerzahlen und deren Spitzenwerte als recht komplex herausstellen können und die dynamischen Anfragenvolumina die Skalierung des Backbones unglücklich verkomplizieren, ergibt sich eine alternative Lösung. Die Möglichkeit das gesamte System online, in der Cloud, abzusetzen ist betrachungswürdig, nicht zuletzt auch wegen des gegen Null laufenden Bedarfs das System vor Ort durch Fachpersonal betrieben zu lassen.

Die automatisierte Skalierung, welche in der Cloud durch den Hoster realisiert wird und die Kosten der Dienstleistung bestimmt, macht die Abschätzung des aufkommenden Traffics für die Organisation der WM-Gastgeber interessant. Haben sich aus der Zielgruppenanalyse (siehe Punkt 2.3) Werte ergeben, die Rückschlüsse auf das Nutzungsverhalten zulassen, kann eine Gegenüberstellung beider Lösungen bzgl. der Kosten interessant sein. Hier wären die Kosten eigener Hardware und deren Betrieb den anfallenden Kosten einer Cloud-Lösung gegenüberzustellen, die sich aus benötigter Bandbreite und Rechenkapazitäten ergeben. Da genau Werte über Nutzung und Ressourcenbedarf nicht vorliegen ist eine eindeutige Empfehlung an dieser Stelle nicht möglich, jedoch sollten die Argumente des entfallenden Fachpersonals und der ebenfalls entfallenden Anschaffungskosten für kurzfristig zu nutzende Hardware, so wie die automatisierte Skalierung ohne die Gefahr Kapazitäten nicht anbieten zu können, die Cloud-Lösung sehr interessant erscheinen. Somit wird zumindest empfohlen hier eigene Gegenüberstellung der Kosten vorzunehmen und anschließend die Ansiedelung des Systems zu bestimmen.

5.2.3 Ausgabe / Schnittstellen zu Modul "Ausgabe"

Zur Verknüpfung bzw. Wiederverwendung der Daten innerhalb einer Website bietet sich das Format XML^[41] an. Dies ergibt sich aus verschiedenen Argumenten, so kann z.B. die frei verfügbare Scriptsprache PHP hervorragend mit XML arbeiten. Wird eine webbasierte Eingabelösung für die zu erhebenden Daten gewählt, ist eine XML basierte Datenbank ebenfalls weitgehend kompatibel.

XML bietet darüber hinaus eine Funktion, welche das Ergebnissystem ebenfalls bieten soll. Es ist vielseitig einsetzbar, die Daten können erfasst, bearbeitet,dargestellt und plattformübergreifend weitergegeben werden.^[47] Aufgrund der hohen Verbreitung und Unterstützung des Standards kann somit jeder die Daten automatisiert wiederverwenden.

Darüber hinaus kann, um die Performace des gesamten Systems zu steigern, eine XML-Datenbank verwendet werden. So heißt es bereits im Datenschutz-Lexikon der WEKA Media GmbH&Co KG:

„Infolgedessen ergeben sich u.a. folgende (Performance-)Vorteile beim Einsatz von reinen XML-Datenbanken:

• weniger Ressourcenaufwand (Zeit, Speicher) beim Einfügen und Auslesen der XML-Daten,
• Einsatz von XML-basierten Abfragesprachen (z.B. XQuery), die ohne Formatumwandlung direkt auf der hierarchischen Speicherstruktur arbeiten können,
• Einsatz von XML-Indizes, die auf die Eigenschaften der hierarchischen Speicherung zugreifen können.“^[48]

Es ist demzufolge möglich die Daten, welche auf der Website angezeigt oder eingegeben werden, direkt aus der Datenbank abzurufen,oder Sie abzulegen, ohne hier Formatumwandlungen vornehmen zu müssen, welche Zeit und Rechenressourcen verbrauchen. Dies ist, zusätzlich zur vereinfachten Weitergabe der erhobenen Daten, ein deutliches Argument für das geplante System nicht nur zur Weitergabe das XML-Format zu empfehlen. Es sollte darüber hinaus bedacht werden, die gesamte Datenbank bereits darauf zu basieren.

5.2.4 Datenbanksoftware (Analyse und Auswahl)

Da die benötigten Komponenten und deren Funktionen und Funktionsweise nun bestimmt wurde, erfolgt der Vergleich verschiedener Lösungen und die Auswahl bestimmter Vorschläge inklusive einer anschließende Empfehlung.

Bezüglich der Software steht vor Allem die Auswahl einer Datenbank im Vordergrund. Hier wurde im Punkt 5.2.3 bereits die Verwendung einer XML-Datenbank nahegelegt. Hier gibt es eine Vielzahl von Softwarelösungen, die Bekanntesten sind folgende:

Aufgrund ihrer kostenlosen Verfügbarkeit treten hier 3 Datenbanken in den Fokus:

• eXtc (Entwickler: M / Gateway Developments Ltd)
• M / DB: X (Entwickler: M / Gateway Developments Ltd)
• Sedna XML-DBMS (Entwickler: Management Of Data & Information Systems, Institute for System Programming of the Russian Academy of Sciences)

Alle unterstützen hier den W3C-Standard, jedoch fällt beim Sedna XML-DBMS auf, dass Sie zum Einen ein komplettes Datenbankmanagement-System mitbringt, Ihre Abfragen auf XQuery basieren(empfohlen durch das W3C ^[49]) und Sie ein Wiki bietet, auf dem die Funktionsweise bereits in einer Onlinedemo getestet werden kann^[50]. Nicht zuletzt aufgrund der breiten Unterstützung von Standards des W3C fällt die Empfehlung demnach auf diese Lösung!

6 Ausarbeitung des Moduls: Darstellung (Output)

Ziel dieses Abschnittes ist die Beleuchtung von Aspekten, die für die Ausgabe eines Live-Ergebnis System eine elementare Rolle spielen. Hierbei liegt der Schwerpunkt auf den Fragestellungen, die aus dem Titel der Arbeit resultieren:

• Welche Daten sind für das Nachvollziehen des Spielverlaufes wichtig und in welcher Form können diese dargestellt werden?
• Wie können Daten möglichst „live“, also zeitnah, übermittelt und dargestellt werden?
• Welche Anforderungen ergeben sich aus der Eigenheit des Turniers als Weltmeisterschaft?

Die Verfahrensweise beginnt mit Definition des Funktionsumfang, deren Umsetzung im Laufe dieses Moduls betrachtet wird.

6.1 Konzeption: Live Ticker

6.1.1 Funktionsumfang

Der Live-Ticker soll durch folgende Funktionen Auskunft über den Turnierverlauf geben:

• Anzeige des laufenden Spiels mit Informationen über den aktuellen Spielstand, die Kontrahenten, die Art des Spiels (z. B. Vorrundenspiel) und letzte Spielgeschehnisse (z.B. Punkt- oder Satzgewinne sowie Kommentierungen)
• Anzeige der kommenden Spiele mit Zeitangabe sowie den Kontrahenten
• Detailansicht des laufenden Spiels mit den o. g. Informationen, jedoch der Erweiterung, dass alle Spielgeschehnisse angezeigt werden und weiterführende Informationen zu den Kontrahenten geboten werden
• Übersicht der absolvierten Spiele und den daraus resultierenden Platzierungen

Zudem folgende Funktionen, die die einfache Verbreitung der Informationen erlauben:

• Empfehlung der Spieldaten in sozialen Netzwerken (Twitter, Facebook)
• Push-Dienst als Abonnementfunktion über neue Ereignisse
• Plattformunabhängige Anzeige

6.1.2 Datenverarbeitung

Neben den, im Abschnitt 4 beschriebenen, in Echtzeit erfassten und vorbereiteten Daten müssen weitere Informationen aus diesen abgeleitet werden, um grundlegende Aussagen über das Turnier treffen zu können:

• Spielentscheidungen: Partien die gemäß den Turnierregeln abgeschlossen wurden.
• Qualifizierungen: Gewinne führen zur Qualifizierung eines weiteren Spieles, sofern es sich nicht um Finalspiele handelt.

Diese Liste ist natürlich noch erweiterbar: denkbar sind Spieler- oder Teamstatistiken (erzielte Punkte im Turnier, Fouls).

6.1.3 Navigationsstruktur

Die Navigationsstruktur stellt einen der grundlegendsten und wichtigsten Punkte einer Webanwendung dar. Hierüber entscheidet sich, wie schnell der Nutzer zu den gewünschten Informationen gelangt. Ein oft zitiertes Paradigma ist hier KISS – Keep it simple and stupid – also eine Erarbeitung mit der Einfachheit im Fokus^[51] In diesem Konzept werden 4 Navigationspunkte unterschieden, welche folgend (An-)sicht, Seite oder Sektion genannt werden: „Laufendes Spiel“, „Kommende Spiele“, „Turnierverlauf“ und „Spielverlauf“. Den Aufbau der Navigationstruktur wird schematisch in Abbildung 15 dargestellt.

Hier wird als erstes das „Laufende Spiel“ angezeigt, zudem die „Kommenden Spiele“. Von der Anzeige des „Laufenden Spiels“, besteht die Möglichkeit, eine detaillierte Ansicht des „Spielverlaufes“ zu erhalten. Dies geschieht durch einen Klick, etwa auf einen Button. Von den „Kommenden Spielen“ gelangt man über die gleiche Methode zum gesamten „Turnierverlauf“ (siehe Variante 1). Die Gesamtübersicht der Begegnungen bietet zudem die Möglichkeit, bereits absolvierte Spiele im Detail mit einer Verlinkung zur Sektion „Spielverlauf“ zu betrachten. Ein direkter Aufruf der Sicht „Spielverlauf“ ist nicht erlaubt, da hier Informationen zu einem bestimmten Spiel dargestellt werden. Der Aufruf des Navigationspunkt ohne die Angabe des Spiels, zu dem Details ausgegeben werden sollen, würde zu einer Anzeige der Seite, ohne Spieldaten führen. Daher ist diese Sektion im Schema ausgegraut.

Natürlich findet nicht immer ein Spiel statt, wodurch eine ständige Anzeige des „Laufenden Spiels“ nicht sinnvoll ist. Für diesen Fall kann dann alternativ das nächste Spiel verkündet werden. Sobald das Turnier abgeschlossen ist, ist die Anzeige des Siegerteams sinnvoll. Anstelle der kommenden Spiele, sind ab Turnierende die Anzeige des Turniersiegers, sowie die Möglichkeit, den Turnierverlauf aufzurufen, vorgesehen (siehe Variante 2 und 3).

6.1.4 Informationsstruktur

Die Informationsstruktur beantwortet die Frage, welche Informationen in den einzelnen Navigationsebenen ersichtlich sein sollen. Hierbei ist die Betrachtung auf den Benutzer gerichtet und den Erwartungswert, den dieser hat, sobald er z.B. den Navigationspunkt Turnierverlauf liest, zu erfüllen.

Laufendes Spiel

• Begegnung: Welche Teams/Spieler treffen im laufenden Spiel aufeinander? Name der Teams/Spieler und Nationalflagge zur einfachen Zuordnung
• Uhrzeit: Die Anzeige der aktuellen Uhrzeit
• Spielart: Vorrundenspiel, Achtelfinale, Viertelfinale, etc.
• Spieldatum: Startzeit des Spiels
• Punkte: Erzielte Punkt- und Satzgewinne

Kommende Spiele

• Begegnung: Welche Teams/Spieler treffen im laufenden Spiel aufeinander? Name der Teams/Spieler und Nationalflagge zur einfachen Zuordnung
• Datum: Die Anzeige der Uhrzeit und Datum der Spiele
• Spielart: Vorrundenspiel, Achtelfinale, Viertelfinale, etc.
• Spieldatum: Startzeit und Datum des Spiels

Spielverlauf

• Begegnung: Welche Teams/Spieler treffen im laufenden Spiel aufeinander? Name der Teams/Spieler und Nationalflagge zur einfachen Zuordnung
• Spielart: Vorrundenspiel, Achtelfinale, Viertelfinale, etc.
• Spieldatum: Startzeit und Datum des Spiels
• Ereignis: Uhrzeit und Ereignisart, z.B. Punkt inkl. Zuordnung zum Verursacher

Turnierverlauf

• Spielübersicht: Welche Begegnungen haben stattgefunden, welche Begegnungen folgen noch?
• Spielart: Vorrundenspiel, Achtelfinale, Viertelfinale, etc.
• Spieldatum: Startzeit und Datum des Spiels
• Ereignis: Uhrzeit und Ereignisart, z.B. Punkt inkl. Zuordnung zum Verursacher
• Ergebnisse: Welche Begegnungen wurden wie entschieden und wie nimmt dies Einfluss auf den Turnierverlauf?

6.2 Umsetzung

In der Softwareentwicklung werden verschiedene Organisationsschemen unter dem Begriff Architekturmuster geführt. Für den konkreten Fall wäre eine Anwendung dieser Muster möglich. Speziell das Model-View-Controller (MVC) Prinzip sei hier zu nennen. Ein wirklicher Vorteil durch diese starke Abstraktion von Daten ist aber aufgrund des gering geschätzten Programmieraufwands nicht wahrscheinlich.

Zur weiteren Beschreibung der Funktionsweise des Systems soll hier aber eine Unterscheidung zwischen den formalen und logischen Elementen erfolgen: Darstellung – wie wird die Anwendung angezeigt? - und Programmierung – welche Funktion erfüllt die Anwendung?

6.2.1 Darstellung

6.2.1.1 Auszeichungssprache

In Hinblick auf eine möglichst weite Kompatibilität des Ergebnis Systems mit verschiedensten Endgeräten sei hier eine XML-basierende Auszeichnungssprache zu empfehlen.^[52]

6.2.1.2 Stylesheet

Neben der grundsätzlichen Formatierung der Applikation spielt das CSS-Attribut media eine wichtige Rolle für diese Arbeit. Durch dieses lassen sich verschiedene Medien mit verschiedenen Formatierungen versorgen^[53] Hervorgehoben werden sollen folgende Werte:

• handheld: Ausgabe auf mobilen Endgeräten, z.B. Mobilfunkgeräte

• screen: Ausgabe auf (Computer-)bildschirmen

• tv: Ausgabe auf Fernsehgeräten

6.2.2 Programmierung

Die Möglichkeit logische Operationen, wie z.B. mathematische Berechnungen, durchzuführen, erforder den Einsatz einer Programmiersprache.

Eine Auswahl der passenden Sprache kann hier nach verschiedensten Aspekten erfolgen: erforderliche Rechenleistung, Schnelligkeit, Präferenz der umsetzendem Agentur (Kostenaspekt). Eine genaue Untersuchung und Empfehlung wird jedoch nicht ausgesprochen. Im Rahmen der Facharbeit haben sich jedoch zwei Sprachen als Möglichkeit ergeben:

• PHP, welche bereits als Framework für das Content Management System (CMS) der WM-Webseite dient,

• sowie das auf JavaScript aufbauende Framework JQuery, welches, durch die in Abschnitt 6.2.4 folgende Problematisierung des Live-Aspektes, als Möglichkeit identifiziert wurde.

Auf die Möglichkeit Datenbankabfragen sowie mathematische Operationen durchzuführen, darf jedoch nicht verzichtet werden.

6.2.3 Verbindung von Inhalt, Formatierung und Programmierung

Am Beispiel eines ersten Entwurfes der Sicht „Laufendes Spiel“ erfolgt eine Zuordnung der o. g. Punkte zum leichteren Verständnis in Abbildung 16:

6.2.4 Der Live Aspekt des Ergebnis Systems

6.2.4.1 Problemstellung

Das hauptsächliche Interesse an live übertragenen Sportereignissen resultiert sicherlich auch aus dem starken Bedürfnis, unmittelbar über die neuesten Entwicklungen der favorisierten Spielbegegnung zu erfahren^[54] Wie beim live Fußballspiel im Fernsehen wird eine passive Position eingenommen; die Spielgeschehnisse werden automatisch zum Zuschauer gesendet, ohne dessen Zutun. Genau an dieser tritt die Schwierigkeit auf, eine entsprechende Lösung in einer Internetanwendung zu realisieren.

Eine Webseite nutzt das Hypertext Transfer Protocol (HTTP) für die Übertragung zwischen Anwender und Server, dem Computer auf dem die Webseite bereitgestellt wird. „HTTP basiert auf einem asymmetrischen Anfrage/Antwort-Paradigma. Dadurch ergibt sich für jede Verbindung die Rollenverteilung von Client und Server. […] Der Client schickt einen Request, und der Server antwortet mit einem Response.“^[55]

Da zunächst ein Request, also eine Anfrage gesendet werden muss, um eine Antwort (Response) zu erhalten, kann eine live Übermittlung, nicht ohne Weiteres geschehen.

6.2.4.2 Lösungsansätze

Die Anforderung an das System lautet also, das beschriebene Anfrage/Antwort-Paradigma zu überwinden. Eine aktuelle und populäre Technik ist Ajax. Vereinfacht gesprochen sorgt Ajax „dafür, dass Daten auf einer Webseite verändert werden können, ohne dass die gesamte Webseite nachgeladen werden muss“^[56]

Zur Verwendung von Ajax empfiehlt sich die Nutzung eines Frameworks, also einer Sammlung von bereits vorgefertigten Methoden zur Programmierung. Am weitesten verbreitet ist hier das kostenlose JavaScript Framework JQuery^[57] mit einer aktuellen Nutzung von 41,36% weltweit (siehe Abbildung 17).

Alternativ sei hier noch das Softwareprodukt Adobe Flash der Firma Adobe Systems Inc.^[58] zu erwähnen. Nachteilig ist hier jedoch die mangelnde Unterstützung diverser Endgeräte, so z.B. Mobilfunkgeräte oder das sehr populäre und beliebte iPad der Firma Apple^[59] weswegen eine weitere Betrachtung nicht stattfindet.

6.2.4.3 Umsetzung des Live Aspektes

Eine Implementierung des JQuery Frameworks auf einem HTTP-Server, geschieht durch Einbindung des folgenden Programmiercodes in die <head>-Sektion des HTML Dokumentes:

<script src="http://code.jquery.com/jquery-latest.js"></script>

Die Bibliothek jquery-latest.js befindet sich in diesem Beispiel nicht lokal auf dem Server der Webanwendung sondern wird direkt von der Projektwebseite JQuery geladen. Vorteil hierbei ist, dass immer die aktuellste Version, hier „latest“, des Frameworks geladen wird. Alternativ, z.B. bei einer lokalen Installation ohne Internetzugang, kann die Bibliothek auch lokal auf dem HTTP-Server gespeichert werden.

Das folgende Code Fragment hat die Funktion, einen Teil der Webseite in einem bestimmten Intervall asynchron, also wie gefordert ohne Browser-Aktualisierung, immer wieder neu zu laden. Zum leichteren Verständnis befinden sich hinter den einzelnen Codezeilen Kommentare, die die Funktion beschreiben:

<script>
 $(document).ready(function() { /* Aufruf der Funktion, sobald alle Elemente der Datei vom Server heruntergeladen wurden */
	 $("#laufendes-spiel").load("laufendes-spiel.xml"); /* In den Container (FUSSNOTE!) mit der Kennzeichnung „#laufendes-spiel“ wird die datei „laufendes-spiel“ geladen */
  var refreshId = setInterval(function() { /* Erzeugung eines neuen Objekts mit der Methode setInterval */
     $("#laufendes-spiel").load("laufendes-spiel.xml");
  }, 5000);  /* Laden von #laufendes-spiel.xml alle 5000 Millisekunden */
 });
</script>[60]

Somit lässt sich mit der Methode „setInterval“ technisch schon von einem Live Ergebnissystem sprechen. Je kleiner der Wert (im Beispiel 5000 Millisekunden) ist, desto häufiger findet eine Aktualisierung statt.

Zu beachten ist jedoch, das häufige Aktualisierungen auch zu einer Steigerung der erforderlichen Rechenleistung auf dem Server führen. Hier sei nochmal auf die im Abschnitt 2.4 erwähnte Skalierbarkeit des Serversystems hinzuweisen.

6.2.4.4 Visualisierung des Live Aspektes

Während im vorherigen Punkt die Software Einschränkungen aufgehoben wurden, widmet sich dieser Punkt den Erfordernissen, die den Live Aspekt auch visuell wahrzunehmen. Eine Aktualisierung findet zwar nun in einem gegebenen Intervall statt, führt aber nicht zwangsläufig zu einer Veränderung der Anzeige, da etwa keine neuen Daten vorliegen.

Die folgende Aufstellung soll eine erste Vorstellung möglicher Lösungswege geben. Die Punkte bestehen auf eigenen Ideen und der Veröffentlichung „JavaScript and AJAX Accessibility“^[61].

• Anzeige des Wortes „live“
• Anzeige einer Grafik, ähnlich der „aktualisieren“ Schaltfläche eines Internetbrowsers, evtl. animiert
• Anzeige der fortlaufenden und aktuellen Uhrzeit am Austragungsort – besonders interessant wenn Gäste außerhalb dieser Zeitzone dem Spielverlauf folgen
• Veränderung der Hintergrundfarbe der geänderten Daten für einige Sekunden in eine Signalfarbe

6.2.5 Internationalisierung

Die Internationalisierung der Anwendung ermöglicht eine Adaption für andere Einsatzszenarien, z.B. die Nutzung des Live-Tickers auf anderen Webseiten. Inwiefern der Mehraufwand im Verhältnis zur kurzen Einsatzdauer steht, muss entschieden werden. Eine nähere Betrachtung muss jedoch stattfinden, da eine internationale Benutzerschaft, ansonsten ausgeschlossen wird.

6.3 Inhaltsverbreitung

Neben der Veröffentlichung von Informationen ist es natürlich auch von grundlegender Bedeutung, dass diese leicht zu finden sind. Hierbei muss es Ziel sein, möglichst viele Interessenten zu erreichen und eine Verfügbarkeit über verschiedene Medien zu gewährleisten.

6.3.1 Squashverbände

Sinnvoll erscheint eine Information zum Bestehen eines Live-Ergebnis Systems an die World Squash Federation sowie mindestens an die Nationalverbände der teilnehmenden Teams. Möglich ist auch die Einbindung eines Verweises oder direkt des Live-Tickers auf die entsprechenden Webseiten.

6.3.2 Soziale Netzwerke

„Das Internet bewirkt in der klassischen Print-, Rundfunk- und Fernsehlandschaft einen tiefgreifenden Wandel. Inhalte verlagern sich zunehmend ins Netz, neue Nutzungsgewohnheiten und neue Medien entstehen. Die bisherige Deutungshoheit journalistisch erstellter Medien wird zunehmend ergänzt von sozialen Medien. Durch ihren Vernetzungs- und Austauschcharakter oftmals unter Gleichgesinnten haben diese eine hohe Glaubwürdigkeit. Zudem entsteht eine Wechselwirkung zwischen sozialen Medien und der klassischen Presse, die vermehrt Inhalte daraus aufgreift.“^[62]

Sofern nicht schon Konten für soziale Netzwerke bestehen, sollten hier die wichtigsten identifiziert werden und mit der Berichterstattung wichtiger Ereignisse rund um die Squash-WM (in diesem Kontext: Vorrundenabschluss, Spielgewinne, Finale) eingerichtet und versorgt werden. Am Beispiel von Facebook sei hier schon gesagt, dass eine Einbindung in Internetanwendungen durch bereitgestellte Dokumentationen^[63] zu keinem großen Aufwand führt.

6.3.3 Klassische Pressearbeit

Soziale Netzwerke erfahren einen immer größeren Zuspruch und Verbreitung, jedoch können diese die klassischen Medien zum heutigen Zeitpunkt noch nicht ablösen. Angeführt sei hier die Diskussion um die digitale Spaltung. Nach einer aktuellen Studie der Initiative D21 e.V. seien 28 Prozent der Bevölkerung in Deutschland im Jahre 2010 noch nicht mit dem Internet verbunden.^[64].

Betrachtungen über die effiziente Verbreitung der WM-Neuigkeiten müssen somit auch die klassischen Mittel wie z.B. Pressemitteilungen berücksichtigen.

6.3.4 RSS-Kanal

Für die Erstellung eines RSS-Dokumentes ist eine Aufbereitung der Daten in kürzerer Form erforderlich. So ist eine Meldung bei Spielentscheidungen als prägnante Information und die Verlinkung zum Live-Ticker bereits eine gute Basis um sich über den Turnierverlauf auf dem Laufenden zu halten. Erwähnenswert ist hier das Attribut <ttl> mit dem beschrieben werden kann, wie lange eine Kanal zwischengespeichert werden soll, bevor ein neue Abruf stattfindet. Vorausgesetzt, dass der Benutzer eine ständige Internetverbindung hält und der RSS-Browser das Attribut auch nutzt.

6.4 Beschreibung eines Prototypen

Um das Verständnis für die beschriebenen Sachverhalte zu vereinfachen, wurde eine erster Prototyp erstellt. Die Abbildung 18, die den Live-Ticker sowie die folgenden Spiele zeigt, macht verständlich wie eine Darstellung auf der offiziellen Seite des Squash-WM 2011 erfolgen könnte.

7 Schlußbetrachtung

7.1 Erfolgsfaktoren

Die Untersuchungen innerhalb dieser Fallstudie haben gezeigt, dass die zeitnahe Erfassung eine unabdingbare Voraussetzung für ein Live-Ergebnis System ist. Der personal- und organisatorische Aufwand ist an dieser Stelle am stärksten konzentriert. Dadurch entsteht bei diesem Punkt aber auch ein enormes Potential den Zeitaufwand und somit die Kosten zu reduzieren. Diese Einsparung sollten allerdings nicht zu Lasten der Datenqualität ausgebaut werden, da diese neben der zeitnahen Erfassung an erster Stelle stehen sollte. Ein optimaler Lösungsansatz ist hier mit Eingabeoptimierung zu arbeiten, z.B. durch intelligente Formulare mit integrierter Plausibilitätsprüfung der Daten.

Zwingende Voraussetzung für die Verarbeitung ist, dass die Skalierbarkeit des System berücksichtigt wird. Dies ist essentiell, um auf variable Nutzerzahlen reagieren zu können.

Darüber hinaus ist es erforderlich, dass die Anbindung des Austragungsstandortes (und damit der Ort der Datenerhebung) an das Internet hochverfügbar gestaltet wird. Sollte es hier zu einem Ausfall kommen ist das gesamte System nicht lauffähig, denn die erhobenen Daten können entweder gar nicht in das System eingegeben werden (Cloud-Konzept) oder nicht veröffentlicht werden(bei lokaler Verarbeitung am Standort selbst).

Für die Ausgabe ließ sich die Verbreitung und Akzeptanz des System als wichtiger Punkt identifizieren. Hierzu bieten sich diverse Möglichkeiten, die gerade im Kontext der sozialen Netzwerke eine einfache aber effektive Möglichkeit ergeben, Interessierte zu erreichen. Somit kann das System als wichtiges PR-Mittel dienen und weiteres Interesse für den Squash-Sport wecken.

7.2 Kritische Betrachtung des Konzeptes

• Der Lösungsansatz für das Eingabemodul schließt zur Umsetzung als Webanwendung. Es gibt neben Webanwendungen aber auch weitere Technologien die eine plattformunabhängige Umsetzung ermöglichen. Beispielsweise könnte die Anwendung mit entsprechenden Funktionen ebenfalls in Java umgesetzt werden.
• Auf eine konkrete Kostenschätzung wurde hier verzichtet, da diese stark von den Spezifikationen abhängt, die schließlich umgesetzt werden sollen. Hierzu sei auf den üblichen Weg der Angebotseinholung verwiesen um einen passenden Anbieter zu finden, der eine Entwicklung kosteneffizient umsetzen kann.
• Aufgrund des Umfangs und der Informationsgrundlage war es im Rahmen des Konzepts nicht möglich die vorhandene Infrastruktur des Veranstalters genauer zu analysieren und Sie für die Umsetzung des Systems zu nutzen.
• Betrachtungen zu den Themen Benutzerführung (Usability) und Barrierefreiheit wurden nicht ausgearbeitet, da keine themenspezifischen Aspekte identifiziert werden konnten. Diesen Punkten ist jedoch aufgrund der kurzen Nutzdauer für eine einfache Benutzung wichtig.

7.3 Weitere Entwicklung

• Wiederverwendung des Systems

Es ist möglich das System auch für kommende Turniere erneut zu nutzen. Hier treten zunächst die kommenden Großveranstaltungen im Bereich Squash ins Auge, aber auch für andere Sportarten wäre das System geeignet und könnte entsprechend angepasst werden. Auch der Ansatz ein Geschäftsmodell zu diesem System zu entwickeln, es anderen Interessenten zu präsentieren und anzubieten, ist denkbar.

• Erweiterbarkeit

Das System wäre erweiterbar und könnte demnach mehr Inhalte aus einer Hand zur Verfügung stellen. Es wäre bspw. möglich Turnierdokumentationen, Spielerinformationen und Statistiken, so wie weitere Informationen über die Austragungsorte und Beteiligten in das Ausgabemodul zu implemetieren.

• Verbreitung über weitere Medien

Die Verbreitung des Systems ist, aufgrund der möglichst plattformunabhängigen Umsetzung, auch auf anderen Medien denkbar. So könnte jedes Medium, dass eine Berichterstattung zu der Veranstaltung anbietet auf die Daten zugreifen und sie wiederverwenden. Beispiele sind hier:

-Radio und Fernsehen

-Mobile Apps

7.4 Projektkonzeption

Bei der Ausarbeitung dieser Fallstudie wurde nach dem EVA-Prinzip vorgegangen, um sich ganzheitlich einem Informationssystem zu nähern. Diese Vorhergehensweise erwies sich im Ganzen als angemessen um die Thematik zu durchdringen. Auffällig hierbei war, dass bei der Konzeption das Modell umgekehrt durchlaufen wurde. Einer der ersten Schritte war die Recherche nach bestehenden Systemen.

Die Abstimmung der Schnittstellen zwischen den drei Modulen ließ sich als unbedingter Erfolgsfaktor identifizieren. Ohne eine derartige Koordination hätte es keine gemeinsame Datenbasis gegeben. Hervorzuheben sei hier die Definition der Datenbasis, welche über alle drei Teile identisch ist.

8 Anhang

8.1 Fußnoten

1. ↑ vgl. Offizielle Seite der Squash-WM
2. ↑ vgl. NONLINER-Atlas der Initi@tive D21
3. ↑ vgl. BITKOM - Onlinestatistik weltweit (Abbildung)
4. ↑ vgl. deutsche Stiftung Weltbevölkerung (Weltbevölkerungsuhr)
5. ↑ vgl. AGOF (ArbeitsGemeinschaft Online Forschung (Nutzungsstatistik Internet)
6. ↑ vgl. IfD Allensbach (Allensbacher Computer- und Technik-Analyse 2007)
7. ↑ Offizielle Seite der Squash-WM
8. ↑ Webseite des Deutschen Squash Verband e.V. (Regelwerk)
9. ↑ Webseite des Deutscher Squash Verband e.V.
10. ↑ World Squash Federation (Regelwerk)
11. ↑ World Squash Federation (Website)
12. ↑ vgl. WinfWiki - Squash Informationsseite
13. ↑ Wikibooks.org (Beschreibung Websiteentwicklung XML
14. ↑ Vgl.Wikibooks.org (Beschreibung Websiteentwicklung XHTML)
15. ↑ Hansen/Neumann "Wirtschaftsinformatik 1" Seite 550
16. ↑ Wikibooks.org (Beschreibung Websiteentwicklung CSS)
17. ↑ vgl. MSDN: Microsoft Developer Network Deutschland (Definition Skalierbarkeit)
18. ↑ Hansen/Neumann "Wirtschaftsinformatik 1" Seite 268
19. ↑ Hansen/Neumann "Wirtschaftsinformatik 1" Seite 269
20. ↑ vgl.Hansen/Neumann "Wirtschaftsinformatik 1" Seite 268f
21. ↑ Hansen/Neumann "Wirtschaftsinformatik 1" Seite 164
22. ↑ vgl.Hansen/Neumann "Wirtschaftsinformatik 1" Seite 164
23. ↑ Hansen/Neumann "Wirtschaftsinformatik 1" Seite 164
24. ↑ Net-Developers.de (EVA-Prinzip)
25. ↑ vgl.Sport-Ergebnissystem "XXLSCORE" und Sport-Ergebnissystem "XXLSCORE" und Sport-Ergebnissystem "SPORT1"
26. ↑ System “Squashdraw” - Website)
27. ↑ vgl. WinfWiki - Squash Informationsseite
28. ↑ vgl. Einführung in die elektronische Datenverarbeitung: Datenerfassung,Seite S. 1
29. ↑ vgl. BSI, M 2.11 Regelung des Passwortgebrauchs
30. ↑ vgl. BSI. M 2.8 Vergabe von Zugriffsrechten
31. ↑ vgl. Intelligente Datenanaylse in MATLAB: Datenselektion und Datenaufbereitung, S. 5
32. ↑ vgl. Intelligente Datenanaylse in MATLAB: Datenselektion und Datenaufbereitung, S. 6
33. ↑ vgl. AKtiv software GmbH - Webapplikationen, S.1
34. ↑ vgl. AKtiv software GmbH - Webapplikationen, S.1
35. ↑ vgl. AKtiv software GmbH - Webapplikationen, S.1
36. ↑ vgl. AKtiv software GmbH - Webapplikationen, S.2
37. ↑ vgl. XForms - Formulare im Zeitalter von XML, S. 1 ff.
38. ↑ vgl. XForms - Formulare im Zeitalter von XML, S. 3 f.
39. ↑ vgl. XForms - Formulare im Zeitalter von XML, S. 3 f.
40. ↑ vgl. XForms - Formulare im Zeitalter von XML, S. 18
41. ↑ ^{41,0 41,1 41,2} siehe Abkürzungsverzeichnis
42. ↑ Servercluster: Ein Rechnerverbund oder engl. Computercluster bzw. meist einfach Cluster (engl. für „Schwarm“, „Gruppe“, „Haufen“), bezeichnet eine Anzahl von vernetzten Computern, die von außen in vielen Fällen als ein Computer gesehen werden können. (...) Ziel des „Clustering“ besteht meistens in der Erhöhung der Rechenkapazität oder der Verfügbarkeit gegenüber einem einzelnen Computer. ( vgl. Wikipedia - Definition "Computercluster" )
43. ↑ vgl.Microsoft Technet (Artikel: Planen von Redundanz (Office SharePoint Server))
44. ↑ siehe Abkürzungsverzeichnis
45. ↑ Backbone (engl. für Rückgrat, Hauptstrang, Basisnetz) bezeichnet einen verbindenden Kernbereich eines Telekommunikationsnetzes mit sehr hohen Datenübertragungsraten(...) [vgl. Wikipedia - Definition "Backbone"]
46. ↑ hier ist ein Ausfall unerheblich, siehe Punkt 6.1.2 [Bestandteile des Moduls "Processing"]
47. ↑ vgl. "PHP und XML" S.19-20
48. ↑ vgl. Datenschutz-Lexikon WEKA Media GmbH und Co KG
49. ↑ The declarative update language is based on the extensions to XQuery proposed by the W3C and Patrick Lehti [vgl. Herstellerwebsite Sedna XML-DB]
50. ↑ Sedna Wiki
51. ↑ vgl.Scandio.de (Paradigmen in der Softwareentwicklung)
52. ↑ Vgl.W3C.de (XML in 10 Points)
53. ↑ vgl.W3C.de (XML in 10 Points)
54. ↑ vgl.Diplomarbeit “Das Erlebnis Sport im WWW-dargestellt am Beispiel www.Laola1.at“ (S. 45ff)
55. ↑ Analyse, Design und Realisierung eines webbasierten SCADA Systems mit OPC XML-DA Schnittstelle zu mehreren Soft-SPS Systemen (Seite 9)
56. ↑ Internet-Begriffe einfach erklärt, Philip Kiefer (Seite 5)
57. ↑ Javascript Framework jquery
58. ↑ Adobe Website
59. ↑ (vgl.welt.de(Microsoft kapituliert beim-Kampf um die Tablets)
60. ↑ vgl.brightcherry.com(Autorefresh)||
61. ↑ vgl.w3.org(JavaScript and AJAX Accessibility
62. ↑ bitkom.org (Leitfaden Social Media) (Seite 7)
63. ↑ vgl.Facebook (Dokumentation)
64. ↑ vgl.Initi@tive D21(Studie Internetnutzung)

8.2 Quellenverzeichnis

Quellenbezeichnung	Details	Zuletzt verfügbar (Onlinequellen
XML-KurzInfo von Hubert Partl	http://www.boku.ac.at/htmleinf/xmlkurz.html	09.01.2011 (22 Uhr)
Offizielle Seite der Squash-WM	http://www.squashwm2011.de	09.01.2011 (22 Uhr)
Webseite des Deutschen Squash Verband e.V.	http://dsqv.de	09.01.2011 (22 Uhr)
Webseite des Deutschen Squash Verband e.V. (Regelwerk)	http://dsqv.de/files/turniero.pdf	09.01.2011 (22 Uhr)
World Squash Federation	http://www.worldsquash.org/	09.01.2011 (22 Uhr)
World Squash Federation (Regelwerk)	http://www.worldsquash.org/ws/wp-content/uploads/2010/12/110101_Championship-Regulations-V3-1.pdf	09.01.2011 (22 Uhr)
Wikibooks.org (Beschreibung Websiteentwicklung XML)	http://de.wikibooks.org/wiki/Websiteentwicklung:_XML:_Beschreibung	09.01.2011 (22 Uhr)
Wikibooks.org (Beschreibung Websiteentwicklung XHTML)	http://de.wikibooks.org/wiki/Websiteentwicklung:_XHTML:_Beschreibung	09.01.2011 (22 Uhr)
Wikibooks.org (Beschreibung Websiteentwicklung CSS)	http://de.wikibooks.org/wiki/Websiteentwicklung:_CSS:_Beschreibung	09.01.2011 (22 Uhr)
Net-Developers.de (EVA-Prinzip)	http://www.net-developers.de/blog/2009/05/22/das-eva-prinzip-eingabeverarbeitungausgabe	09.01.2011 (22 Uhr)
System “Squashdraw” - Website	http://www.squashdraw.de/	09.01.2011 (22 Uhr)
Scandio.de (Paradigmen in der Softwareentwicklung)	http://www.scandio.de/2010/09/paradigmen-in-der-softwareentwicklung	09.01.2011 (22 Uhr)
W3C.de (XML in 10 Points)	http://www.w3c.de/Misc/XML-in-10-points.html	09.01.2011 (22 Uhr)
w3C.de (Media Types)	http://www.w3.org/TR/CSS21/media.html	09.01.2011 (22 Uhr)
Diplomarbeit “Das Erlebnis Sport im WWW-dargestellt am Beispiel Laola.tv“	http://othes.univie.ac.at/6507/1/2009-07-03_0204133.pdf	09.01.2011 (22 Uhr)
Sedna Wiki	http://wikixmldb.org/	09.01.2011 (22 Uhr)
Analyse, Design und Realisierung eines webbasierten SCADA Systems mit OPC XML-DA Schnittstelle zu mehreren Soft-SPS Systemen	http://astro.uni-wuppertal.de/html/Theses/Barkhausen-diplom.pdf	09.01.2011 (22 Uhr)
Hansen/Neumann "Wirtschaftsinformatik 1"	Hans Robert Hansen und Gustaf Neumann, F.X. Bea (Hrsg.), M Schweitzer (Hrsg.), Wirtschaftsinformatik 1 - Grundlagen und Anwendungen, 10. Auflage, ISBN 978-3-8252-2669-5
Internet-Begriffe einfach erklärt, Philip Kiefer	http://www.databecker.de/media/prod/docs/sample/441737_sample.pdf	09.01.2011 (22 Uhr)
Javascript Framework jquery	http://www.jquery.com	09.01.2011 (22 Uhr)
NONLINER-Atlas der Initi@tive D21	http://www.nonliner-atlas.de/	09.01.2011 (22 Uhr)
Adobe Website	http://www.adobe.com/de/	09.01.2011 (22 Uhr)
welt.de(Microsoft kapituliert beim-Kampf um die Tablets)	http://www.welt.de/print/welt_kompakt/webwelt/article12020351/Microsoft-kapituliert-beim-Kampf-um-die-Tablets.html	09.01.2011 (22 Uhr)
brightcherry.com(Autorefresh)	http://www.brightcherry.co.uk/scribbles/2009/02/26/jquery-auto-refresh-div-every-x-seconds/	09.01.2011 (22 Uhr)
w3.org(JavaScript and AJAX Accessibility)	http://www.w3.org/2006/Talks/0524-www-AjaxWAI.pdf	09.01.2011 (22 Uhr)
bitkom.org (Leitfaden Social Media)	http://www.bitkom.org/files/documents/Leitfaden_Social_Media.pdf	09.01.2011 (22 Uhr)
Facebook (Dokumentation)	http://developers.facebook.com/docs/	09.01.2011 (22 Uhr)
Initi@tive D21(Studie Internetnutzung)	http://www.initiatived21.de/presseinformationen/studie-digitale-gesellschaft-laesst-weiter-auf-sich-warten	09.01.2011 (22 Uhr)
deutsche Stiftung Weltbevölkerung (Weltbevölkerungsuhr)	http://www.weltbevoelkerung.de/info-service/weltbevoelkerungsuhr.php?navanchor=1010037	09.01.2011 (22 Uhr)
BITKOM - Onlinestatistik weltweit (Abbildung)	http://www.mittelstandsblog.de/2007/05/weltweit-nutzen-12-milliarden-menschen-das-internet/zahl-der-internetnutzer-weltweit-nach-landern-quelle-bitkom/	09.01.2011 (22 Uhr)
XML-KurzInfo von Hubert Partl	http://www.boku.ac.at/htmleinf/xmlkurz.html	09.01.2011 (22 Uhr)
AGOF (ArbeitsGemeinschaft Online Forschung (Nutzungsstatistik Internet)	http://www.handelsblatt.com/marktplatz/statista/statistik-der-woche-die-beliebtesten-webseiten-der-welt;2643959;2#bgStart	09.01.2011 (22 Uhr)
IfD Allensbach (Allensbacher Computer- und Technik-Analyse 2007) [Registrierung erforderlich]	http://de.statista.com/statistik/diagramm/studie/22616/umfrage/abrufen-von-sportnachrichten-im-internet/	09.01.2011 (22 Uhr)
WinfWiki - Squash Informationsseite	http://winfwiki.wi-fom.de/index.php/Squash_WM_2011	09.01.2011 (22 Uhr)
Sport-Ergebnissystem "XXLSCORE"	http://www.xxlscore.de/	09.01.2011 (22 Uhr)
Sport-Ergebnissystem "SPORTAL"	http://www.sportal.de/sportal	09.01.2011 (22 Uhr)
Sport-Ergebnissystem "SPORT1"	http://www.sport1.de/	09.01.2011 (22 Uhr)
MSDN: Microsoft Developer Network Deutschland (Definition Skalierbarkeit)	http://msdn.microsoft.com/de-de/library/aa292172(v=vs.71).aspx	09.01.2011 (22 Uhr)
Wikipedia - Definition "Computercluster"	http://de.wikipedia.org/wiki/Computercluster	09.01.2011 (22 Uhr)
Wikipedia - Definition "Backbone"	http://de.wikipedia.org/wiki/Backbone_(Telekommunikation)#Einzelnachweise	09.01.2011 (22 Uhr)
Datenschutz-Lexikon WEKA Media GmbH und Co KG	http://www.datenschutz-praxis.de/lexikon/xyz/xml-datenbank.html	09.01.2011 (22 Uhr)
Herstellerwebsite Sedna XML-DB	http://modis.ispras.ru/sedna/index.html	09.01.2011 (22 Uhr)
PHP und XML	Marco Skulschus: PHP und XML,2. Auflage, Comelio Medien, ISBN 978-3939701002
N. Meier, Einführung in die elektronische Datenverarbeitung: Datenerfassung, November 1998	http://www.wzw.tum.de/dvs/scripten/edv1/datenerfass6.pdf	09.01.2011 (22 Uhr)
Bundesamt für Sicherheit in der Informationstechnik (BSI), M 2.11 Regelung des Passwortgebrauchs, 2008	https://www.bsi.bund.de/cln_183/ContentBSI/grundschutz/kataloge/m/m02/m02011.html	09.01.2011 (22 Uhr)
Bundesamt für Sicherheit in der Informationstechnik (BSI), M 2.8 Vergabe von Zugriffsrechten, 2009	https://www.bsi.bund.de/cln_156/ContentBSI/grundschutz/kataloge/m/m02/m02008.html	09.01.2011 (22 Uhr)
Michael Brückner, Tobias Scheffer, Intelligente Datenanaylse in MATLAB: Datenselektion und Datenaufbereitung, 22.05.2009	http://www.cs.uni-potsdam.de/ml/teaching/ss09/ida/Datenvorverarbeitung.pdf	09.01.2011 (22 Uhr)
AKtiv software GmbH, Webapplikationen	http://www.aktivsoftware.at/Software_Entwickl/Webanwendung.pdf	09.01.2011 (22 Uhr)
Samuel Greef, XForms - Formulare im Zeitalter von XML, 2007	http://www.samuel-greef.de/uni/xforms.pdf	09.01.2011 (22 Uhr)

8.3 Tabellenverzeichnis

Tabellen-Nr.	Tabellentitel	Kapitel-Nr.
1	Vorteile/Nachteile Ergebnisbogen vs. Anwendung	4.3.1
Vorteile/Nachteile HTML-Formulare vs XForms	4.3.2
1	Aufstellung: benötigte Hardware	5.1.1
2	Aufstellung:benötigte Software	5.1.1
3	Aufstellung: Voraussetzungen Hardware	5.1.2
4	Aufstellung: Voraussetzungen Software	5.1.2

8.4 Abbildungsverzeichnis

Abb.-Nr.	Abbildung	Quelle	Datum	Kapitel-Nr.
1	Statistik "Internetnutzer weltweit"	http://www.mittelstandsblog.de/2007/05/weltweit-nutzen-12-milliarden-menschen-das-internet/zahl-der-internetnutzer-weltweit-nach-landern-quelle-bitkom/	28.12.2010 - 17:52	1.1
2	Skalierbarkeit	Abbildung für diese Fallstudie		2.5
3	RAID-Level 5	http://www.raid.com/04_01_05.html	08.01.2010 - 15:04	2.6
4	Cloud-Computing	http://blog.gpm.de/upload/files/images/pic_cloud_computing.png	09.01.2010 - 16:30	2.7
5	Relationales Datenmodell	Abbildung für diese Fallstudie		4.2
6	Medien zur Datenerfassung	Abbildung für diese Fallstudie		4.3.1
7	Marktanteile der Browser	http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0#	08.01.2010 - 21:58	4.3.1
8	Prototyp: Login und Spiel vor dem Start	Abbildung für diese Fallstudie		4.6.2
9	Prototyp: Laufendes Spiel - Übersicht	Abbildung für diese Fallstudie		4.6.2
10	Prototyp: Ereignisauswahl	Abbildung für diese Fallstudie		4.6.2
11	Prototyp: Ereignisprotokoll	Abbildung für diese Fallstudie		4.6.2
12	Schematische Darstellung - Redundanz	http://technet.microsoft.com/de-de/library/cc263044(office.12).aspx	30.21.2010 - 15:24	5.1.1
13	Schematische Darstellung - Backbonenetz	Abbildung für diese Fallstudie		5.2.1
14	Native XML-Datenbanken	http://www.rpbourret.com/xml/XMLDatabaseProds.htm	31.12.2010 - 13:35	5.2.4
15	Navigationsstruktur	Abbildung für diese Fallstudie		6.1.3
16	Inhalt-Formatierung-Programmierung	Abbildung für diese Fallstudie		6.2.3
17	Statistik weltweite Nutzung JavaScript Frameworks	http://trends.builtwith.com/javascript	08.01.2010 - 05:13	6.2.4.2
18	Prototyp: Live-Ticker	Abbildung für diese Fallstudie		6.4

8.5 Abkürzungsverzeichnis

Abkürzung	Bedeutung
AGOF	Arbeitsgemeinschaft Onlineforschung
Ajax	Asynchronous JavaScript and XML
ASP	Application Service Provision
CMS	Content Management System
CSS	Cascading Style Sheets
DSQV	Deutscher Squash Verband e.V.
EVA	Eingabe-Verarbeitung-Ausgabe
HTML	Hypertext Markup Language
HTTP	Hypertext Transfer Protocol
KISS	Keep it simple and stupid
MAC	Media Access Control
MVC	Model-View-Controller
NAS	Network Attached Storage
PDA	Personal Digital Assistant
PHP	PHP: Hypertext Preprocessor
RAID	Redundant Array of Independent Disks
RSS	Rich Site Summary, auch Really Simple Syndication
STP	Spanning Tree Protocoll
W3C	World Wide Web Consortium
WM	Weltmeisterschaft
WSF	World Squash Federation
XHTML	Extensible Hypertext Markup Language
XML	Extensible Markup Language