Konzept für eine iPhone App für ein WM-Publikum

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):	Jan Kozik, Marcel Kümpfel, Lukas Kowalczyk
Studienzeitmodell:	Abendstudium
Semesterbezeichnung:	WS10
Studiensemester:	2
Bearbeitungsstatus:	begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis 1 Einleitung 1.1 Motivation 1.2 Zielsetzung 1.3 Aufbau 2 Grundlagen 2.1 Apple 2.1.1 iPhone 2.1.2 Apple iOS 2.1.3 Apps 2.1.3.1 Die Tab Bar 2.1.3.2 Single Main View 2.1.3.3 Die Table View 2.2 Squash-WM 2.2.1 Squash 2.2.1.1 Squash - Das Spiel 2.2.1.2 Zählweise 2.2.1.3 Aufschlag 2.2.1.4 Punktevergabe 3 Konzept 3.1 Anforderungen 3.1.1 App-Anforderungen 3.1.2 User-Anforderungen 3.1.3 Technische Anforderungen 3.1.4 Entwicklungs-Anforderungen 3.1.5 Projektplan 3.2 Frontend 3.2.1 Interface Design 3.2.1.1 User Experience 3.2.1.2 HIG 3.2.1.2.1 Utility App 3.2.1.2.2 Productivity App 3.2.1.2.3 Immersive Applications 3.2.1.3 Der Interface Builder 3.2.2 Web App vs. Native App 3.2.3 Menüpunkte 3.2.4 Interaktion 3.2.4.1 Walkthrough 3.2.4.2 Gesten 3.2.4.3 Bedienung 3.2.5 Prototyp 3.3 Backend 3.4 Datenbankstruktur 3.4.1 Core Data 3.4.2 SQLite 3.5 Administration 3.5.1 Datenpflege 3.5.2 Wirtschaftlichkeit 3.6 Wartung 3.6.1 Back-Up-System 3.6.2 User-Help-Desk 3.7 Distributionswege 3.7.1 App-Store 3.7.2 Sponsoring 3.7.3 Marketing 3.8 Kosten 3.8.1 Entwicklungskosten 3.8.1.1 Entwicklerkosten 3.8.1.2 Anschaffungskosten 3.8.2 Einmalige Kosten 3.8.3 Einnahmen 4 Fazit 4.1 Fazit 4.2 Ausblick 5 Anhang 5.1 Abkürzungsverzeichnis 5.2 Abbildungsverzeichnis 5.3 Fußnoten 5.4 Literatur- und Quellenverzeichnis

1 Einleitung

In der Zeit vom 21. - 27. August 2011 findet in Paderborn die 23te Herren Weltmeisterschaft im Squash statt. Hier werden voraussichtlich 32 Mannschaften inklusive Betreuer und Trainer gegeneinander antreten. Dabei wird mit insgesamt 7.000 Zuschauern in der Woche gerechnet.^[1]

1.1 Motivation

Da auch in diesem Jahr die Anzahl der verkauften Smartphones weiter angestiegen ist und die unzähligen Apps immer mehr Beliebtheit erfahren, sollte bei einem Event wie der Squash-WM auch eine App für mobile Endgeräte vom Veranstalter bereitgestellt werden. Dank des mobilen Internets und den inzwischen erschwinglichen Datenpreisen sprechen Smartphones und Apps ein breites Massenpublikum an, sodass die App für keine bestimmte Zielgruppe bestimmt wird.

Da der App-Store von Apple mit ungefähr 300.000 Apps^[2] der zur Zeit größte virtuelle Marktplatz ist wurde in dieser Fallstudie im Rahmen des Bachelor of Science Wirtschaftsinformatik-Studiums an der Fachhochschule für Ökonomie und Management (FOM) am Standort Düsseldorf im 2. Semester das Konzept für eine iPhone App entwickelt. Das Konzept beschreibt eine App für das WM-Publikum der Squash-WM das vor Ort anwesend sein wird, sowie für Fans aus aller Welt die nicht die Möglichkeit haben anreisen zu können.

1.2 Zielsetzung

Zielsetzung dieser Fallstudie ist es, dem Leser ein Software-Konzept vorzustellen. Anhand dieses Konzeptes soll ermöglicht werden, eine vollwertige App zu programmieren die alle gängigen Anforderungen, die im Verlauf des Konzepts erläutert werden, abdeckt.

Dem Entwickler soll ein Konzept vorgelegt werden anhand dieser die App ohne Fragen entwickeln kann. Dabei wird vor allem auf das User Interface, sowie das Backend eingegangen.

Ebenfalls richtet sich der Fokus auf die Bedienbarkeit der App.

1.3 Aufbau

Zunächst werden die einzelnen Anforderungen ermittelt. Diese richten sich sowohl an den User inklusive der technischen Anforderungen seines mobilen Endgerätes als auch an die Entwicklungsumgebung mit allen Voraussetzungen die der Entwickler der App benötigt. Es wird sowohl auf das User Interface als auch auf die Datenstruktur dahinter eingegangen. Ein weiterer Schwerpunkt des Konzeptes ist die Administration. Letztendlich wird der Weg einer fertigen App erläutert, wie zum Beispiel das Einstellen in den App-Store sowie die Promotion der App.

2 Grundlagen

In den folgenden Kapiteln soll der gesamte Zusammenhang zwischen der historischen Entwicklung des iPhones selbst, wie auch die Entwicklung von Apps im Allgemeinen erläutert werden. Hierzu dienen empirische Daten wie eine Anlayse des Unternhemens Apple selbst. Ferner sollen die potenziellen Möglichkeiten und Anforderungen einer App-Entwicklung aufgezeigt werden. Weiter soll ein Einblick in die Squash Welt und in die Squash WM und dessen Informationsbedürfnissen vermittelt werden.

2.1 Apple

Apple ist ein Unternehmen, welches Computer und Unterhaltungselektronik sowie Betriebssysteme und Anwendungssoftware herstellt. Es wurde am 1 April 1976 von Steve Jobs, Steve Wozniak und Ronald Wayne gegründet. Apple hat ca. 46.600^[3] Mitarbeiter und hat im Jahr 2009 einen Umsatz von 65.225 ^[4] Millionen Doller erwirtschaftet mit einem Gewinn von 14.013 Millionen^[4] Doller.

Tot gesagte leben länger! Dieses Sprichwort sollte sich auch bei Apple wieder einmal bewahrheiten. Obwohl Apple mitte der 1990er-Jahre kurz vor dem Ruin stand, da der Markt die Systeme als veraltet betrachte, konnte sich Apple unteranderem durch eine neue Unternehmensausrichtung und Umstrukturierung des Unternehmens retten. Als 1998 Jonathan Ive, der Gestalter des iMac, Chef der Gestaltungsabteilung bei Apple wurde, war dies der Anfang des "Hype's" auf Apple Produkte. Weiter wurde eine neue Produktstrategie ins Auge genommen, in der die Differenzierung zwischen Heimanwender und Profis als Hauptmerkmal und unter Gesichtspunkt der Mobilität, für die neuen Produkte genommen wurde. Hieraus entstanden das MacBook, der iMac und das MacBook Pro für Profis. Apple stellte zudem in den Jahren 2006 und 2007 nach und nach auf Prozessoren von Intel um, welches eine Vielzahl von Vorteilen bot.^[5]

Als 2001 das iPod von Apple veröffentlicht wurde, beschritt Apple einen neuen zusätzlichen Weg in Richtung Unterhaltungselektronik. Mit dem Erscheinen des iPhone 2007 und des iPads 2010 gelang es Apple zur dritt wertvollsten Marke der Welt aufzusteigen, mit einem geschätzen Wert von 83,15 ^[4] Milliarden US-Dollar. Da sich Apple immer mehr in Richtung Unterhaltungselektronik ausrichtet wurde zudem das Unternehmen, ehemals "Apple Computer Inc.", auf "Apple Inc." umfirmiert. Des weiteren besitzt Apple weltweit über 300 "Apple Retail Stores" in welchen Apple seine Produkte selbst vertreibt. Wichtig zur allgemeinen Geschichte des Personal Computers ist, dass Apple in den 70er Jahren zu den ersten Herstellern von Personal Computern gehörte. Ferner übernahm Apple in den 80er Jahren in Sachen Benutzeroberflächen und der Steuerung von Peripheriegeräten, wie z.B. der Maus eine Führungsposition ein. Viele Merkmale heutiger GUI's (Graphical User Interface), wie z.B. das Pull-down-Menü,das Drag and Drop-Verfahren, der Doppelklick und der Papierkorb beruhen auf Entwicklungen von Apple.

Apple setzte mit der Weiterentwicklung der GUI zum HI (Humand Interface) neue Standards für die Bedienung von PC's. Hierbei entwicklte Apple eine Human Interface Guideline, als Vorgabe für die Gestaltung von Benutzeroberflächen. Diese Richtlinen sollten ein gleiches Aussehen und eine gleichartige Bedienung der Anwendungen ermöglichen (Look & Feel). Diese Richtlinen stehen noch heute bei allen Apple Produkten als Standard und werden stätig weiterentwickelt. Sie finden sich auch bei der Gestaltung von Apps wieder, die über Apple angeboten werden können.

2.1.1 iPhone

Am 9. Januar 2007^[5] wurde das iPhone von Apple angekündigt und war erstmals in Amerika am 29 Juni 2007^[5] erhältlich. Am 9 November erhältlich erschien das iPhone erstmals in Deutschland. Interessant ist, dass die Domain ihpone.org schon 1999^[6] von Apple regestriert wurde. Das iPhone erfreut sich großer Beliebtheit, auf Grund der Touchscreen Technik die eine revolutionäre Bedienung mit mehreren Fingern gleichzeitig ermöglicht. Dieses war jedoch schon bei dem Apple-Produkt iPod möglich. Des weiteren beruht die große Beliebtheit darauf, dass potenzielle Käufer oft aus der emotionalen Sicht handeln und das iPhone auch als Life-Style Artikel sehen. Ferner wurde das iPhone 2007 von der amerikanischen Zeitung "Time" ^[7] zur Erfindung des Jahres gewählt.

Unter den technischen Details zählen unter anderem, dass das Iphone ein eigenes Betriebssystem besitzt auf dem alle Applikationen aufsetzten, das sog. iPhone OS. Dieses Betriebssystem besitzt hierbei für Entwickler mehrere Schichten, die bestimmte Schnittstellen bereitstellen (Frameworks). Unter anderem ermöglicht das iOS auch den Zugriff auf Funktionen wie die eingebaute Kamera und die mit gelieferten Standardapps. Das Konzept betrachtet hierbei die Funktionen eines iPhone's in der 4. Version und soll an dieser Stell den Funktionsumfang und das Gerät an sich beschreiben, da die zu entwickelnde App auf diesem Gerät aufsetzen soll, und sich dabei an den geletenden Standard orientiert. Im Juni 2010^[5] erhältlich wurde die vierte Generation, des mittlerweile sehr beliebten Smartphones, auf den Markt geworfen. Unter den technischen Details zählen unter anderem:

- Ein neues Gehäuse, das als Antenne dient ^[8]

- Ein neues 3,5" Display mit einer Auflösung von 960 x 640 Pixeln und IPS-Technik (In-Plane-Switching) auch Retina Display genannt^[8]

- Das iOS 4 Betriebssystem, welches erstmals Multitasking für Applikationen von Drittanbietern unterstützt^[8]

- Zwei neue Kameras, welche sogar HD-Aufnahmen ermöglichen ^[8]

- Neue Akkus in Kombination mit neuen Prozessoren (A4), die die Laufzeiten verlängern sollen. Ferner bekamm das iPhone 4 einen doppelt so großen Speicher^[8]

- Ein Gyroskop welches es ermöglicht Bewegungen um weitere Achsen zu erfassen und zu verarbeiten^[8]

- Für die Datenübertragung steht eine UMTS-Übertragung via HSUPA (High Speed Uplink Packet Access) mit bis zu 5,7 Mbps zur Verfügung^[8]

- Die Wifi-Verbindungen unterstützen die Standards IEEE 802.11b/g/n^[8]

2.1.2 Apple iOS

Um mit Anwendungen auf einzelne Teile des iPhones wie z.B. die Kamera zugreifen zu können, erfolgt der Zugriff nicht direkt auf die Hardware, sondern über die vom iPhone OS exportierten Programmierschnittstellen (API). Bei einem direkten Zugriff auf die Hardware würde die Entwicklung auch eher in eine Treiberprogrammierung ausarten und nicht in gängiger Anwendungsentwicklung. Auch für den Zugriff auf die mitglieferten Systemanwendungen wird eine entsprechende Schnittstelle mitgeliefert.

Für alle Anwendungen ist somit das iPhone OS die natürliche Grenze und die Abstraktion der Hardware. Als Betriebssystem wurde anfangs eine angepasste und abgespeckte Mac OS X Version verwendet. Dabei folgt das OS, der seit Max OS X 10.1^[10], der neu angelegten Namenskonvention. Allerdings besaß das iPhone am Anfang keine Java-Plattform.

iOS 3.0 ^[9]

In der neuen Version des Betriebssystems werden dem Anwender und Entwickler neue Möglichkeiten bereitgestellt, womit sich eine App um einige Funktionen ergänzen lässt. Darunter fallen unter anderem Möglichkeiten der Sprachsteuerung, die Möglichkeit seine UMTS Anbindung für umliegende Geräte per Funkverbindung zur Verfügung zu stellen. Ferner wurde ein Fernsteuerungsdienst namens "Find my iPhone" implementiert. Weiter hat es Apple geschafft eine weitere Möglichkeit des Geld verdienens mit einzubauen. Über das sog. Micropayment lassen sich über das "In-App-Purchase" Apps direkt erweitern. Zudem wurde das OS um Funktionen erweitert, die aber nicht für die im Konzept gedachte App-Entwicklung von Relevanz sind.

iOS 4.0 ^[9]

Die neuste Version des iOS bietet dem Anwender wie dem Entwickler neue Möglichkeiten im Breich Multitasking. Ferner wurden für Geschäftskunden neue Optionen für Werbemöglichkeiten mit eingebaut, welche für die Selbstfinanzierungen einer App eine enorme Rolle spielen. Mit dem neuen iOS ist es zudem möglich Applikationen im Hintergrund laufen zulassen und gleichzeitig andere Anwendungen zu nutzen. Hierbei wurde zudem ein Push-Dienst eingerichtet, der dem Anwender Veränderungen einer anderen Anwendungen, die zum Zeitpunkt der Nutzung im Hintergrund laufen Nachrichten mitteilt, und die Option einräumt auf die im Hintergrund laufende App zu wechseln (Local Notifications und Fast App Switching). Des weiteren wird das iPhone OS endgültig in iOS umbenannt. Hierbei sollte erwähnt werden, dass das iOS um über 100 Punkte erneuert wurde und dieses den Rahmen des Konzeptes sprengen würde. Weitere Informationen zum iOS finden sich aber im iPhone Dev Center.

2.1.3 Apps

Es gibt viele Formen von Apps für diverse Geräte, die in verschieden Programmiersprachen programmiert werden. Wir betrachten in unserem Konzept allerdings nur die Besonderheiten einer iPhone App, da dieses sich in den Anforderungen wiederspiegelt.

Bei dem iPhone erfolgt die gesamte Bedienung einer App über das Touchscreen. Bei Android basierten Apps werden beispielsweise Menüfunktionen über bestimmte Tasten am Rande des Gerätes aktiviert. Apps haben im Allgemeinen das Ziel für ein spezifisches Problem oder eine Anforderung einen so einfachst wie möglich gestalteten Lösungsweg zu bieten. Apps mit mehrfach Funktionen für mehere differenzierende Anwendungen gibt es kaum. Das Retina Display ermöglicht auf dem iPhone elegante Lösungsansätze, die es den Entwicklern erlauben ein leichtes und einfaches Design für Apps zu entwickeln.

Wesentliches Merkmal einer App ist, dass die Lernkurve eines Anwenders bei einer App enorm hoch ist und der Anwender sich intuitiv durch die App bewegt. Ferner werden keine großen Dokumentationen und Handbücher, wie bei traditionellen PC-Applikationen mehr gebraucht, welches sich auch in den Entwicklungkosten wiederspiegelt. Des weitern reduziert die einfache Handhabung einer App die Fehlerquote. Insgesamt bietet eine App einen sehr hohen Benutzerkomfort und eine hervorragende User Experience. Allerdings muss auch erwähnt werden, dass sich durch unsere von Geburt gegeben Fingergröße die Bedienung manchmal problematisch gestaltet und oft unpräzise ist. Dadurch sollte bei einer Entwicklung darauf geachtet werden, dass lange Phasen der Bedienung vermieden werden. Daraus resultiert auch der Zustand das der Appmarkt hart umkämpft ist, und eine einfach zu bedienende App eine der Grundvoraussetzungen für die Verbreitung des Apps ist. Über 80^[11] Prozent der Apps werden nur einmal gestartet, danach nie wieder. Das User Interface von Apple bietet die Möglichkeit, tief in hierarchische Strukturen einzutauchen, ohne diese als solche wahrzunehmen. Informationen lassen sich einfach hinzufügen, entfernen oder ändern, ohne die kontextuelle Orientierung zu verlieren. Als Tool für das Design eine Prototypen kann z.B. das Programm "OmniGraffle" vewendet werden.Der Interface Builder der bei der Entwicklungsumgebung dabei ist dient als Toll für das eigentliche Design.

Bei einer Entwicklung einer App stellen sich am Anfang oft einige Grundfragen, die bei der konzeptionierung berücksichtigt werden sollten. Darunter fallen unter anderem folgende Aspekte:

- Wie löse ich die gestellten Anforderungen und welchen Zusatznutzen kann man anbieten

- Welche Zielgruppe wird angesprochen und welche Erwartungen ergeben sich aus der Zeilgruppe

- Wo steht die Konkurrenz und welche Vorteile könnte man ihr gegenüber anbieten

Als Design Konzept bietet Apple als Grundlage drei Standardmodelle:

2.1.3.1 Die Tab Bar

Im dem "Tab Bar"-Modell wird am unteren Rand des Screens eine fixe Navigationsleiste eingeblendet, auf der dann bis zu fünf Symbole oder Texte plaziert werden können. Sie bietet den Vorteil, dass sie recht übersichtlich ist und der Anwender schnell mit der Navigation vertraut wird.

2.1.3.2 Single Main View

In diesem Ansatz werden die Informationen in einzelnen fixen Blöcken angeordnet, die durch ein horizontales Scrollen durch das App durchgesehen werden können. Der "Single Main View"-Ansatz bietet den Vorteil viele Informationen an den Anwender zu bringen.

2.1.3.3 Die Table View

Der "Table View"-Ansatz beschäftigt sich damit eine bildschirmfüllende und scrollbare Liste als Navigation zu verwenden. Als Vorteil hierzu zählt, dass Gruppierung und Sortierung im "Table View"-Ansatz dem Anwender leicht eine gewisse Ordnung vermittelt. Nachteil hierbei ist der Wechsel der einzelnen Funktionen, da man wieder auf die Ausgangseite zurückkehren muss.

Ferner gibt es noch einen weiteren Ansatz bei iPhone Apps, das sog. Metaphore-Design. Hier wird versucht bekannte Bedienkonzepte aus der realen Welt zu implementieren, welches wiederum Vor- und Nachteile mit sich bringt.

2.2 Squash-WM

Die 23te Herren Squash Team WM 2011 findet zwischem dem 21. - 27. August 2011 in Padaborn statt. Ein Tunier dieser größe findet nicht zum erstmal in Padaborn statt, schon 1990 und 2005 wurden im Ahorn-Sportpark größere Tuniere ausgetragen. Weltweit gibt es mehr als 50.000 Courts in 185 Ländern der Welt, in dennen ca. 2 Millionen Menschen den Sport ausüben.Dahingehend wird mit einer hohen Aufmerksamkeit zur WM in Padaborn gerechnet.Es wird mit voraussichtlich 32 Mannschaften gerechnet, die gegeneinander antreten werden.Ferner ist geplant einen Glas-Court mit bis zu 1.000 Sitzplätzen im Ahorn-Sportpark zu installieren, welches das Interesse von Sportfans nochmals untermauert.

2.2.1 Squash

In diesem Kapitel wird das Squashspiel kurz erläutert und die WM, für die die App entwickelt werden soll.

2.2.1.1 Squash - Das Spiel

Squash wird von zwei oder vier Spielern mit Squash-Schlägern und einem leichten kleinen Ball (von 39,0 bis 40,5 mm, zwischen 23,5 und 24,5 Gramm)^[12] auf einem Spielfeld, dem sog. Court, gespielt, der den Normen der World Squash Federation entspricht und in mehrere Bereiche (siehe Bild) aufgeteilt ist. Dabei versucht der jeweilige Gegner den Ball so an die Wand zuspielen, dass der Gegenspieler diesen Ball nicht wieder an die Wand zurückschmettern kann. Hierbei ist es den Regeln enstprechend nötig, dass der Ball bevor er zurückgeschlagen wird einmal den Boden berührt. Berührt der Ball den Boden zweimal ist der Punkt verloren. Hierbei muss zudem auf die Linienführung des Courts geachtet werden. Die Seitenwänder wie auch die Forderwand dürfen für die Schläge genutz werden. Ferner ist zu erwähnen, dass sich die Regeln mehrfach geändert haben und z.B. die damit verbunden die Satzanzahl verändert hat.^[12][13]

2.2.1.2 Zählweise

Im Vorfeld eines Turniers wird festgelegt über wieviel Sätze das Spiel geht, bei der WM werden meist drei bis fünf Sätze gepielt. Jeder Satz wird bis 11 Punkte gespielt und wird von dem Spieler gewonnen, der als erster 11 Punkte erreicht. Bei einem Stand von 10:10 muss der Rückschläger entscheiden, ob der Satz bis 11 normal weiter geht oder in die Verlängerung geht und der Satz erweitert wird. In letzteren Fall gewinnt der Spieler den Satz, der als erster zwei weitere Punkte erzielt. Fernen müssen diese Entscheidungen dem Schiedrichter vorher mitgeteilt werden. Bei jeglichen Fehlversuchen wird der Ballwechsel wiederholt, der sog. Let. ^[12]

2.2.1.3 Aufschlag

Traditionell wird der erste Aufschlag über das Drehen eines Schlägers entschieden. Bei einem Satzende bekommt der Jenige den Aufschlag, der den letzten Satz gewonnen hat. Die Position des Aufschlages wird jeweils am Anfang eines Satzes und nach jedem Aufschlagwechsel vom Aufschläger entscheiden. Danach schlägt er abwechselnd von jeder Seite auf, solange er Aufschläger bleibt.^[13]

2.2.1.4 Punktevergabe

Nur der Spieler der Aufschlag hat, hat die Möglichkeit einen Punkt zu erzielen. Sobald der Gegenspieler den Ball gewinnt bekommt er den Aufschlag. Falls ein Spieler beim beim Aufschlag stark behindert wird kann ein Let oder ein sog. Stroke (Punkt an den behinderten Spieler) vom Schiedsrichter entschieden werden.^[13]

3 Konzept

Im Konzept soll der theoretische Ansatz zur Entwicklung einer spezifischen App für die Squash-WM vorgestellt werden. Hierbei werden die Anforderungen an die allgmeine Entwicklung, genauso wie die User und App Anforderungen beleuchtet. Da dieses Konzept auch als Zielgruppe potenzielle Entwickler beinhaltet, werden die Technischen Anforderungen sowie die Entwicklungsanforderungen ebenfalls ausführlich erläutert.

3.1 Anforderungen

Zu den allgemeinen Anforderungen zählen die Betrachtung der benötigten Ressourcen und Informationen. Die Feststellung des Aufwandes beruhrt auf der Einschätzung der eigenen Entwicklungserfahrungen von Applikationen und Apps im Team selbst, da unser Team aus reinen Entwicklern besteht und genug Erfahrung mitbringt um den Aufwand für die reine Entwicklung abzuschätzen. Der Aufwand berücksichtig wie in allen Software-Konzepten einen gewissen Puffer, für beispielsweise das Testen der App. Der Aufwand berücksichtig allerdings nicht die Ausarbeitung des Konzeptes oder andere Aufwände, wie beispielsweise das Anmelden im Apple Portal oder die Verbereitung der App. Für die Entwicklung werden die Aufwände in Mann Tagen zusammengefasst, so dass der Entwicklungszeitraum flexibel gehalten werden kann. Bei der Einstellung von zusätzlichen Entwicklern reduziert sich der Aufwand. Als Infrastruktur für die Entwicklung wird in diesem Konzept ein neuer Mac Rechner nach den unten aufgeführten Technischen-Standards veranschlagt, des weiteren werden zwei Versionen des iPhones in diesem Konzept benötigt, da eine gewisse Abwärstkompabilität gewährleistet werden soll, insbesondere für das iOS 3.0. Unter anderem müssen für die Entwicklung eine ausreichende Dokumentation im kleinen Maß und Test-System erstellt werden. Als Grundvorraussetzung wird ein eingerichtetes Wlan vorrausgesetzt, um alternativ die Informationen auch über eine Wlan-Verbindung zu übermitteln. Im Konzept wird auf die Datenübertragung nicht näher eingegangen, da es dem Auftraggeber freigstellt wird ob er sich dazu entscheidet das App über UMTS oder Wlan mit Informationen zu füttern. Für die zu entwickelnde App würden beide Alternativen einprogrammiert, was nicht soviel Aufwand bedeutet wie es vieleicht klingt da die eingebauten Schnittstellen von der programmierung her ähnlich aufgebaut sind.

3.1.1 App-Anforderungen

Unter den App-Anforderungen fallen alle relevanten Funktionen, die das App ausmachen. Im einzelnen bedeutet dies:

Ein Spielplan der den Spieltag im Detail beleuchtet und es ermöglicht über einen "Liveticker" aktuelle Situationen und Spiele informativ zu übertragen. Ein Gruppenplan der die Gruppen Details, wie z.B. die Teilnehmer der Gruppe und derren einzelnen Spielinformationen beinhaltet. Genauso wie die Ergebnisse der einzelnen Gruppen in einer tabellarischen Sicht auführt. Ferner ist eine News Rubrik angedacht in der wesentliche Neuigkeiten direkt übertragen werden. Des weiteren werden für die Handhabung Funktionen wie eine Einstellungseite benötigt, in der beispielsweise die Verbindungsart ausgewählt werden kann. Weiter soll eine "Topscore"-Funktion implementiert werden, die es ermöglicht die Top-Spieler des Tuniers näher zu betrachten und sich, mit dem Verweis auf die Spieltage , die einzel Ergebniss auführen zu lassen.

3.1.2 User-Anforderungen

Als Benutzeranforderung steht vorallem die leichte Bedingbarkeit der App im Fordergrund. Dem Benutzer soll es ermöglicht werden zwischen den einzelne Funktionen schnell zu wechseln. Des weiteren wird vom potenziellen Benuter erwartet, dass er die Verfügbarkeit der Informationen in Echtzeit mit zu den wichtigsten Anforderungen zählt. Die Informationen müssen aktuell gehalten werden, damit garantiert werden kann das man auch außerhalb der Tunierveranstaltung nichts verpasst. Des weiteren sollte das App auch für Benutzer mit unterschiedlichen Versionen des iPhone Betiebssystems verfügbar sein. Um den Benutzer nicht abzuschrecken sollte das App kostenfrei bereitgestellt werden. Als Finanzierungsmöglichkeit besteht die Idee eine kleine Oberfläche des Apps als Werbefläche zu nutzen, etwa um gegebenen Werbepartnern eine Möglichkeit zu geben, ihre Produkte zu publizieren. Hierrauf wird aber im späteren Verlauf näher eingegangen.

Unser Team nimmt an, dass eine vorher eingehende Befragung einiger Squash Fans dazu beitragen könnte, die User-Anforderungen näher zu spezifizieren. Bei der Beauftragung der App würde das Team Kontakt zu Squash-Fans über diverse Squash-Portale aufnehmen und über kleinere Umfragen die benötigten tiefgreifenden Informationen sammeln. Da das Konzept bis heute aber theoretisch bleibt verzichten wir im Vorfeld auf diese Befragung, behalten sie aber Hinterkopf.

3.1.3 Technische Anforderungen

Die technischen Anforderungen an die App spielen eine wesentliche Rolle, um das App performant und lauffähig zu halten. Die einzelnen Situationen und Ergebnisse müssen von einer Verwaltungsperson über eine Oberfläche, hinter der eine Datenbank liegt, für die App bereitgestellt werden. Es gibt mehrer Möglichkeiten für das App an diese Informationen zu gelangen, die einfachste Realisierung wäre ein Informationsaustausch über das normale Handynetz der Provider. Weiter könnte in Erwägung gezogen werden, dass ein Wlan-Pool im Bereich der WM zu integireren ist um dort eine direkte Informationsübertragung zu ermöglichen. Die technischen Anforderungen sind hierbei mit in die Gesamtkostenrechnung mit aufzunehmen. Falls ein Wlan-Pool aufgebaut werden sollte, müsste hierfür die benötigte Hardware eingekauft werden und Personal disponiert werden, welches die Infrastruktur aufbaut falls dieses nicht vom Veranstalter schon gegeben ist.

Des weiteren ist nicht zuvergessen, dass eine Person abgestellt werden müsste die aktuelle Informationen über die Oberfläche in die im App verbaute Datenbank einpflegt. Für diese Person müsste ein Arbeitplatz eingerichtet werden und "FAQ" beigelegt werden. Diese Person/Personen werden im späteren Verlauf des Konzeptes als Administratoren beschrieben und mit in den Kosten veranschlagt.

Ferner muss ein Webserver mit einer dahinter liegenden Datenbank in Betrieb genommen werden, welche die Daten zwischen Client (App) und der Eingabeoberfläche, für die aktuellen Daten, verwaltet.

3.1.4 Entwicklungs-Anforderungen

Für die Entwicklung des Apps muss eine bestimmte Entwicklungumgebung implementiert werden. iPhone Apps werden normalerweise, ausgenommen Emulatoren die ein Betriebssystem simulieren, ausschlieslich auf Mac OS Systemen auf einem Apple Mac entwickelt. Als Entwicklungswerkzeug wird das sog. iPhone SDK (Software Development Kit^[15]) benötigt. Dieses kann unter dem eigens von Apple entwickeltem Protal "Apple Developer Connection"^[15] unter dem Bereich iPhone Dev Center heruntergeladen werden. Hierbei ist die Mitgliedschaft in der Connection obligatorisch und kostenlos. In diesem SDK ist die Entwicklungsumgebung "Xcode" enhalten, in der die App in der Programmierungsprache "Objectiv C"^[15] entwickelt werden kann. Ebenfalls im SDK enthalten ist ein Simulator eines iPhones, welches für die Entwicklung und zum rapidtesten der eigenen App gedacht ist. Ferner besitzt das SDK einen Interface Builder der für die Oberflächengestaltung zuständig ist. Des weiteren beinhaltet das SDK Tools^[15] zum debuggen, für Performance Test und zum testen der App auf Endgeräte.

Für das Testen einer App auf einem Endgerät muss eine Mitgliedschaft im "iPhone Developer Programm"^[15] bestehen, welche nicht kostenlos ist und mit in die Berechnung der Gesamtkosten einbezogen werden muss.

Der Distributionsweg ist bei einem iPhone App, im Gegensatz zu einem Android App, vorgegeben. Es wird das Programm iTunes zum veröffentlichen benötigt, welches im SDK mit enthalten ist.

Als Grundlage der Programmierung werden objektorientierte Module entwickelt, die sich jeweils nach den gängigen Standards der Softwarentwicklung richten. Hierbei wird darauf geachtet, dass die einzelnen Module so programmiert werden, dass sich deren Dateninhalte austauschen lassen. Der Grund für diese Ausrichtung wird im Fazit und Ausblick näher erläutert.

Ferner muss eine App für die Distribution zertifiziert und von Apple über Funktionen im Portal bestätigt werden, hierauf wird im weiteren Verlauf des Konzeptes im Kapitel Distribution näher eingegangen.

3.1.5 Projektplan

Das unten aufgeführte Diagramm soll den groben Projektplan darstellen.

3.2 Frontend

Das Frontend hat eine ganz besondere Bedeutung der Software. Hier wird der erste Eindruck der App vermittelt. Ein Benutzer wird sofort feststellen ob ihm die App gefällt oder nicht. Von daher ist es besonders wichtig auf das Oberflächendesign der App zu achten.

Die Besonderheit am Frontend der iOS Geräte ist die Tatsache, dass es auch gleichzeitig das Bedienelement der App ist. Dadurch entstehen viele bemerkenswerte Vorteile, aber natürlich auch einige Nachteile^[17].

Jeder User wird es als einen logischen Prozess betrachten, auf ein Objekt zu drücken um ein Event auszulösen. Durch diese Eigenschaft lernt jeder Anwender, auch ohne technisches Hintergrundwissen, enorm schnell die Bedienung der App. Die Bedienung der App geschieht auf intuitive Art und Weise und minimiert die Fehleranfälligkeit. Dadurch stellt Apple eine hervorragende User Experience sicher, die die Grundvoraussetzung für jede von Apple zugelassen App ist.

3.2.1 Interface Design

Das Interfacedesign (dt.: Schnittstellendesign) ist eine Teilbereich des Designs, der sich mit der grafischen Gestaltung von Benutzeroberflächen. Anforderungen und Ziele werden an Mensch und Maschine ermittelt und so verarbeitet. Ziel des Interfacedesign ist es, dem Anwender eine Schnittstelle zur Verfügung zu stellen.

3.2.1.1 User Experience

Die Zeit die der User mit der App verbringt, soll so angenehm wie möglich sein. Alles was ihn verärgern könnte soll im Vorhinein ausgeschlossen werden. Alles was ihm Spaß macht und was seinem Auge gefällt soll integriert werden. Dieser Ansatz lässt sich allgemein als User Experience bezeichnen.^[19] Die User Experience setzt sich aus drei Komponenten zusammen. Der Usability der App, dem „Look“ und dem „Feel“. ^[19] Unter der Usability versteht man die Benutzbarkeit der Webseite oder einer Software. Alles was den Inhalt negativ beeinflusst sollte vermieden werden. Dazu gehören schlechte Farbkontraste, eine zu kleine Schriftgröße oder eine unkonventionelle Bedienung. ^[19] Der Look beschreibt das Aussehen der App. Dieser kann je nach Vorliebe stark variieren, „trotzdem sollten auch hier Grundgesetze der Proportion, Farbharmonie und Gestaltung gelten“^[19]. Der Look sollte der Zielgruppe angepasst sein um eine „gute Experience beim User zu bewirken“^[19]. Um dem User eine angenehme Seitenerfahrung zu ermöglichen, spielen letztendlich auch einige Gefühlsfaktoren eine Rolle. Diese Gefühle können beim Anwender hervorgerufen werden, indem die App oder Webseite deutlich zeigt, „dass sie auf die Benutzerhandlung reagiert“^[19].

Die Präzision der Eingabe kann sich durch die Größe der Hand des Anwenders negativ auf die User Experience auswirken^[17]. Ebenfalls kann es vorkommen, dass der Anwender der App sich selbst die Sicht auf wichtige Teile durch seine Hand nimmt. Auch muss beachtet werden, dass zu lange Eingaben sich negativ auf das Empfinden des Users auswirken kann^[17]. Diese negativen Eigenschaften des User Interface sollten im Entwicklungsprozess berücksichtigt werden.

Um die gröbsten Usability-Fehler(Fehler die der Anwender beim Benutzen der App machen kann) zu vermeiden, sollten einige Punkte berücksichtigt werden. Dazu gehört eine Mindestgröße der Objekte, mit denen der User interagiert^[17]. Weiter sollten keine zu weitreichenden Eingaben vom User verlangt werden.

3.2.1.2 HIG

Bei den iPhone Human Interface Guidelines (HIG) handelt es sich um einen Dokumentationsteil innerhalb des iOS Dev Centers von Apple^[20]. Innerhalb dieses Centers werden dem Programmierer wertvolle Information zur Entwicklung von iOS Programmen gegeben.

Die HIG geben wertvolle Hilfestellungen bezüglich der User Experience, was zu deutsch soviel wie Nutzungserlebnis bedeutet und dem Anwendungsverhalten der einzelnen Software Komponenten. Auch werden hier die Rahmenbedingungen die das Design erfüllen muss und somit eine besondere User Experience für den Nutzer sicherstellt, ziemlich klar abgedeckt. Werden diese Vorgaben nicht berücksichtig, könnte es passieren, dass die App im App Store Review abgelehnt wird^[17].

Die User Experience unter Mac OS X und iOS Programmen beinhalten die visuelle Erscheinung, das interaktive Verhalten und technischen Einsatzmöglichkeiten der Software.^[21] Aqua ist die grafische Benutzeroberfläche die allen OS X und iOS Programmen zugrunde liegt. Aqua beschreibt die Verwendung von Elementen wie Buttons, Fenstern und Menüs. Wie der Name Aqua es vermuten lässt, orientiert sich das Design stark ans Wasser. Dabei werden Elemente als Wassertröpfchen, oder transparent dargestellt.^[22]

Die iPhone Human Inteface Guidelines (HIG) definieren drei verschieden App Stile - Utility, Productivity und Immersive.

3.2.1.2.1 Utility App

Utility Apps ermöglichen dem Benutzer einen schnellen Zugriff auf spezielle Informationen. Häufig findest man diese Art der App bei Börsenkursen, Wetter Informationen oder Sport Ergebnissen.

Typische Eigenschaften einer Utility-App sind folgenden:

• minimales Setup
• simple Bedienung und Layout
• standard User Interface Elemente^[23]

Die meisten Utility Apps sind typischerweise direkt verwendbar wenn sie das erste Mal gestartet werden. Der Setup-Prozess, sprich die Einstellungen die der User machen muss sind nicht nötig oder minimal. Als Faustregel sollte man sich merken, wenn das Setup der App länger dauert als das primäre Nutzen, so verliert die App an Wert und Benutzer werden sie meiden. Die ideale Wetter-App würde beispielsweise den aktuellen Standort ermitteln(mit der Erlaubnis) und das Wetter dieses Ortes anzeigen.

Viele User könnten beispielweise nur wenige Sekunden mit der App verbringen, daher ist es enorm wichtig, dass er schnell an die benötigte Information rankommt. Aus diesem Grund wird bei einer Utility App ein sehr einfaches Layout verwendet und darauf geachtet, dass die Bedienung simpel bleibt.

Üblicherweise verwendet diese Art der App nur standard User Interace Bedienelemente. Zu diesen gehört unter Anderem die aktuelle Seite, ein Info-Button und die Anzahl der folgenden Seiten die durch Punkte gargestellt werden. Selbst erstellte UI-Elemente können durchaus ästethischer wirken. Jedoch sind diese Elemente dem Benutzer nicht so bekannt, so dass er sich unter Umständen nicht direkt mit der App zurecht finden kann.

Die Squash-Wm App sollte aus dem Bereich der Utility-App auch einiges abdecken. Als wichtigstes Kriterium gilt hier, dass die App einfach zu konfigurieren sein muss und der User sie demnach direkt nach dem Start verwenden kann.

3.2.1.2.2 Productivity App

Productivity Apps haben in der Regel mehr Features als Utility Apps. Dazu können Social Networks oder mobile Banking beispielsweise gehören. Die Zeit, die mit dieser Art von App verbracht wird, kann sich enorm unterscheiden. Von ein paar Sekunden beim eMail-check bis hin zu ein paar Stunden in einem sozialen Netzwerk.

Productivity Apps sind meisten grundverschieden, aber viele können an folgenden Eigenschaften ausgemacht werden:

• hierarchische Struktur
• Shortcuts

Beinahe allen Productivity Apps liegt eine hierarchische Struktur zugrunde. Dazu gehören Listen und Detailansichten. Eine Liste beinhaltet in der Regel einen scrollbaren Kontext. Durch Tabs kann direkt zu anderen Sektionen der App gesprungen werden. Dadurch können logisch getrennte Bereiche besser navigiert werden. Bei den Detailansicht handelt es sich um mehr Informationen zu dem gewünschten Thema.
Productivity Apps benötigen oft Eingaben vom Nutzer. Da sich dieser Prozess durch die kleine Tastatur oft als schwierig gestaltet, sollte der User nur so wenig wie möglich Eingaben vornehmen müssen. Auch hier kann der User unterstützt werden indem man zum Beispiel schon den aktuellen Standort ermitteln kann, oder mit dem in iOS integrierten SpellCheck Rechtschreibfehler vermeiden.

Wie schon bei Utility Apps, soll auch hier unsere App die wichtigsten Vorteile nutzen. Besonders wichtig ist eine tab bar über die der Nutzer direkt zu anderen Bereichen navigieren kann. Siehe auch Menüpunkte.

3.2.1.2.3 Immersive Applications

Diese Art App wird verwenden um Spiele zu spielen, Media-Content anzusehen und spezialisierte Prozesse(wie Tonaufnahme) auszuführen. Üblicherweise verwenden User Immersive Apps wenn sie etwas Freizeit haben. Diese kann variieren zwischen ein paar Minuten und ein paar Stunden.

Auch Immersive Apps sind grundsätzlich sehr verschieden, haben jedoch auch Punkte in denen sie sich gleich sind:

• fokussieren sich auf den Content
• customized user experience

Dadurch dass sich die Apps auf den Inhalt fokussieren, wird häufig der ganze Bildschrim, inklusive der Statusleiste die Netz Informationen und Batteriestand anzeigt, verwendet. Durch diesen Effekt lässt sich der Benutzer nicht weiter ablenken und kann sich ganz auf den Inhalt konzentrieren.

3.2.1.3 Der Interface Builder

Wir wollen nun die User Interface Elemente vorstellen die von unserer App verwendet werden sollen.

Apple stellt eine breite Masse an User Interface Elementen bereits zur Verfügung. Auf diese Elemente sollte der Entwickler zurückgreifen, denn dadurch kommt es nicht zu unvorhersehbaren Ereignissen, da man weiß wie sich das Objekt verhält wenn ein User damit interagiert.

Die iPhone Title Bar ist die Headline aller Seiten. Innerhalb dieser Title Bar wird die Überschrift der jeweiligen Seite angezeigt. Ebenfalls werden hier der Reload-Button, sowie die Zurück-Button eingefügt.

Die zuvor angesprochenen Zurück-Schaltflächen werden mittels den iPhone Title Bar Buttons realisiert. Diese werden jeweils links von der Überschrift in der iPhone Title Bar angezeigt.

Bei der Icon Bar handelt es sich um das Hauptnavigationselement. Die Icon Bar ist auf jeder Seite ganz unten erreichbar. Von dort aus sind die vier Hauptmenüpunkte Spieltag, Gruppen, News und Mehr jederzeit erreichbar und können angesteuert werden.

Die iPhone Item List wird bei einer größeren Auswahlliste verwendet. Diese Auswahlliste werden wir beim Liveticker verwenden. Innerhalb dieser Item List werden dann die verschiedenen Spiele die zur Auswahl stehen angezeigt. Ebenfalls wird dieses Element seine Verwendung im Menüpunkt Gruppen finden. Hier werden die einzelnen Gruppen inklusive ihrer Spieler angezeigt.

Die iPhone Check Mark, Add, Arrow Icons sind standard Elemente mit denen der User durch die App navigieren kann. Für unsere App ist das Arrow Icon, sprich der Pfeil von besonderer Bedeutung. Bei allen Seiten und Elementen bei denen es weitere Informationen bezüglich eines Punktes gibt, kann mittels des Arrow Icon zu dieser detaillierten Ansicht navigiert werden.

Beim iPhone Notification Element handelt es sich sozusagen um ein Pop-Up das dem User eine Nachricht anzeigt. Dies kann auch geschehen wenn die App nicht geöffnet ist. Dabei muss der User jedoch explizit erlauben, dass er Benachrichtigungen von der App auf seinen Home Screen erhalten möchte. Davon abgesehen soll dieses Element verwendet werden um Ergebnisse von beendeten Spielen anzuzeigen. Auch bei allen Warnungen soll eine Meldung in dieser Form angezeigt werden.

Der Interface Builder ist ein eigenständiges Programm und kann auch unabhängig von Xcode gestartet werden. Hier kann das Oberflächendesign mit Hilfe von den oben vorgestellten Schablonen erstellt werden. Ebenfalls würde die Möglichkeit bestehen, das User Interface in Xcode manuell per Hand zu programmieren. Der Vorteil beim Interface Builder ist, dass nicht unbedingt ein Programmierer das Design entwickeln kann. Ebenfalls wird der Entwickler schnell erste Ergebnisse sehen können. Ein weiterer großer Vorteil des Interface Builder ist, dass unheimlich flexibel Anpassungen am Design vorgenommen werden können. Wird mittels dem Interface Builder eine Oberflächendefinitionsdatei erstellt, so kann diese von Xcode verwendet werden. Diese Oberflächendefinitionsdatei hat den Dateityp .nib. Seit Version 3 des Interface Builders gibt es ein neues Dateiformat: .xib. Dabei handelt es sich um eine XML-Datei.^[27]

3.2.2 Web App vs. Native App

Ein wichtiges Kriterium der App ist, in welcher Form sie angeboten werden soll. Sie kann auf zwei verschiedene Arten erstellt werden. Dabei unterscheidet man zwischen einer Native App und einer Web App.

Unter einer Native App versteht man eine speziell entwickelte App, die über den App Store auf das mobile Endgeräte heruntergalden wird. Diese App läuft dann nur auf diesem Gerät unter dessen Betriebssystem. Wenn eine neue Version der App herausgebracht werden soll, so muss eine Anpassung vorgenommen werden und die App danach erneut runtergeladen werden.^[28] Ein absoluter Vorteil der Native Apps ist, dass keine dauerhafte Internetverbindung benötigt wird. Ist die App einmal auf das Gerät heruntergeladen worden, kann diese jederzeit geöffnet werden. Auch haben Native Apps derzeit noch einen Performance Vorteil. Leider haben diese Apps auch einen großen Nachteil. Apple unterbindet sämtliche Flashinhalte auf iPhone, iPad und co.

Doch es gibt eine Möglichkeit dem User animierte Inhalte anzubieten. Dabei wird auf HTML 5 zurückgegriffen. Diese Alternative zur Native App ist die sogenannte Web App. Dabei werden die Inhalte der App ganz oder Teilweise aus dem Web geladen. Die Anwendung kann auf jedem mobilen Endgeräte aufgerufen werden. Gerade mit HTML 5 ist es möglich, deutliche Verbesserungen im Bereich der Web Apps zu erzielen.

Auf den ersten Blick sieht eine Web App aus wie eine Native App und funktioniert auch so. Doch das Prinzip das dahinter steckt, ist ein vollkommen anderes. Die Web App ist im Prinzip eine Webseite, die speziell für Smartphones angepasst wurde. Die Web App wird damit nicht auf dem Gerät installiert, sondern über einen Browser aufgerufen und über die URL angesteuert.^[28] Die Vorteile einer Web App sind folgende:

• Look & Feel einer Native App
• Unabhängig vom Endgerät
• Keine Kontrolle durch den App-Store
• Aktualisierungen sind schnell machbar
• Bewegte Bilder

Doch auch die Web App hat Nachteile:

• Dauerhafte Internetverbindung ist nötig
• Kein Zugriff auf Hardware-Funktionen
• Abrechnungen laufen nicht über Apple und den App-Store
• Verschiedene Browser können auf Inhalte anders als erwartet reagieren^[28]

Unsere App sollte jedoch aus Kompatibilitäsgründen noch als Native App entwickelt werden.

3.2.3 Menüpunkte

Folgende Menüpunkte wurden in den Anforderungen spezifiziert:

• Spielplan
  • Spieltags Details
    • Liveticker
• Gruppen
  • Gruppen Details Tabelle
  • Ergebnis Details (Newsticker)
• News
  • News Details
• Mehr
  • Einstellungen
  • Topscorer
  • About

Weitere Informationen zu den einzelnen Menüpunkten sind im Abschnitt 3.2.5 (Prototyp) zu finden.

3.2.4 Interaktion

In diesem Kapitel soll nun erläutert werden, wie der User mit der Anwendung arbeiten kann. Zunächst wird die hierarchische Struktur der App erläutert und welche Gesten auf dem iPhone zur Verfügung stehen. Im Abschließenden Teil wird erklärt wie der User die App bedienen und steuern kann.

3.2.4.1 Walkthrough

Im Folgenden wird die Menüführung der App erläutert. Dabei wird gezeigt wie der User an einzelne Menüpunkte gelang. Nach dem Start der App gelangt der User auf der Startseite. Diese wird in der Grafik mit "Top" bezeichnet. Die erste Ebene bezeichnet die vier Hauptmenüpunkte, die in der iPhone Icon Bar ganz unten aufgeführt werden sollen. Die zweite Ebene stellt die darunter liegenden, verfügbaren Seiten dar. Unsere App ist auf bis zu drei Ebenen verschachtelt. Tiefer sollte nicht verschachtelt werden, da der User sonst die Orientierung verlieren kann.

3.2.4.2 Gesten

Die Gesten (gestures) die das iPhone kennt, sind eine zentrale Eigenschaft, die jede App nutzt. Nachfolgend werden acht Gesten beschrieben, die der Nutzer der App anwenden kann. Ebenfalls wird erläutert welche Geste, wann zum Einsatz kommen wird^[29].

• Tap

Bei einem Tap handelt es sich sozusagen um einen einfachen Klick. Mit einem Tap wird ein einfacher Klick auf der gewünschten Stelle (zum Beispiel einen Link im Safari-Browser) ausgeführt. Beim Tab handelt es sich um die meist verwendete Geste innerhalb unserer App. Mittels der Geste können einzelne Menüpunkte ausgewählt werden.

• Touch and hold

Die Touch and hold Geste ist vergleichbar mit einem Klick mit der Maus auf ein Element. Diese Geste wird eher selten verwendet und kommt in unserer App nicht zur Verwendung.

• Double tap

Auch der double tab ist eine sehr intuitive Geste und wird wie ein Doppelklick mit der Maus angewendet.

• Swipe

Der Swipe ist ein sanftes Blättern wie es der iPhone User vom Bildschirm Entsperren her kennt. Die Swipe Geste ist die standard Wahl um eine weitere Seite anzeigen zu lassen, falls diese verfügbar ist. Wenn mehrere Seiten verfügbar sind, wird dies über die Punkte am unteren Bildschirmrand angezeigt. Ist dies der Fall, kann mit einer sanften Streichbewegung nach links oder rechts zu diesen Seiten gesprungen werden.

• Flick

Diese Geste kann man auch als sanftes Blättern bezeichnen. Sie wird ähnlich wie die Swipe-Geste angewendet. Doch beim Flick wird die Geste vertikal anstatt horizontal beim Swipe ausgeführt. Beim scrollen durch den Liveticker wird der Flick angewendet.

• Drag

Der Drag ist eine Geste um zum Beispiel Elemente zu ziehen. Diese Geste wird in unserer App keine Verwendung finden.

• Pinch

Eine weitere sehr wichtige Geste für die App ist der Pinch. Dabei handelt es sich um ein Auseinanderziehen bzw. Zusammenziehen. Dabei können Flächen vergrößert und wieder verkleinert werden. Dazu muss mit zwei Fingern die Geste ausgeführt werden. Bei dieser Geste handelt es sich um eine Multi-Touch-Geste.

• Shake

Der Shake ist ein Schütteln. Mit dieser Geste können Eingaben rückgängig gemacht werden. Da innerhalb unserer App keine Eingaben gemacht werden müssen, wird diese Geste keine Verwendung finden.

Um sicherzustellen, dass die beschriebenen Gesten auch die korrekte Wirkung auf dem iPhone erzielen, müssen die einzelnen Gesten auf dem iPhone Simulator getestet werden. Auf dem iPhone werden diese Gesten sehr intuitiv angewendet. Dies ist beim iPhone Simulator nicht der Fall. Daher sollte eine ausführliche Testphase stattfinden, bevor die App veröffentlicht wird.

Dem Entwickler steht das Konzept der Gestures Recognizers zur Verfügung. Dabei werden in beliebigen Views die Gesten erkannt. Das UIKit definiert hierfür die abstrakte Klasse UIGestureRecognizer^[30]. Von dieser Klasse kann nun abgeleitet werden. Für die standard Gesten stehen jedoch schon eigene Klassen zur Verfügung. Dazu zählt auch die Klasse UITabGestureRecognizer^[30]. Diese Klasse erkennt den Tap.

3.2.4.3 Bedienung

Das zentrale Bedienelement ist das einfache drücken (der tap). Mit dem tap können alle vier Menüpunkte in der Icon Bar angesteuert werden. Ebenfalls kann das Arrow Icon über den tap angesprochen werden. Dieses Icon dient auch als Weiterleitung zur weiterführenden Seite.

Der Home-Button wird als Ausstiegspunkt der App verwendet. Wenn der User die App beenden will, so drückt er den Home-Button und gelangt zurück zu seinem Home-Screen. Auf seinem Home-Screen kann der User das Icon der App beliebig verschieben. Dafür muss er das App-Icon gedrückt halten (touch and hold) bis die Symbole anfangen zu wackenln. Danach ist ein verschieben der App-Icons möglich. Um die Eingabe abzuschließen, ist wieder das Drücken des Home-Buttons nötig.

Wenn die App beendet wird, soll sie standardmäßig alle Verbindungen trennen. Wenn der User jedoch den Notifizierungsnachrichten zugestammt hat, soll die App weiter im Hintergrund Daten sammeln und bei einem Beendeten Spiel dem User eine Nachricht auf den Home-Screen schicken.

Beim Drehen des iPhones, soll sich der Content der App dynamisch der Lage anpassen. Für das Rotieren des Textes wird die folgende Methode verwendet:

 (BOOL)shouldAutorotateToInterfaceOrientation:
    (UIInterfaceOrientation)interfaceOrientation {
    return YES;
 }     

3.2.5 Prototyp

Zum Abschluss soll noch ein erster Prototyp der App vorgestellt werden. Dieser Prototyp wird anhand von Skizzen erläutert. Diese Skizzen sollen als Grundlage für weiter Mock-ups und für das fertige Produkte verwendet werden.

Der Spielplan ist der erste Menüpunkt. Wenn dieser ausgewählt wird, gelangt der Nutzer zur Übersicht der Spieltage. Der aktuelle Spieltag wird rot markiert. Vergangene oder zukünftige Spieltage werden mit grün gekennzeichnet. Über das Pfeil-Icon gelangt der Anwender zur nächsten Ebene, die sich mit den Details eines Spieltages beschäftigt.

Zunächst haben wir in der Title Bar einen Button mit dem wir zurück springen können. Neben der Überschrift befindet sich hier auch noch der Button für den reload der Seite. Im Hauptfenster wird eine Liste angezeigt, die die Spiele pro Datum und Uhrzeit gruppiert anzeigt. Diese Liste wird mittels einer Item List erstellt und kann ebenfalls über das Pfeil-Icon weiter eingegrenzt werden. Hat man sich für ein Spiel entschieden und hat dieses ausgewählt, so landet man bei den Spieldetails.

Diese Details sind im weitesten Sinne der Liveticker. Schaut man sich die Details eines schon beendeten Spiels an, so sieht man eine Historie des Livetickers. Läuft das Spiel hingegen noch, so wird der Liveticker stetig neu geladen. Dieser reload kann ebenfalls manuell erzeugt werden. Wieder über den entsprechenden Button oben rechts im Titel. Ebenfalls werden hier die Details zum Spiel, wie Spielstand, Ort, Beginn, Teilnehmer so wie die eingeteilte Gruppe angezeigt.

Der zweite Hauptmenüpunkt ist "Gruppen". Auf der ersten Ebene erfährt der User alles über die einzelnen Gruppen. Dabei werden die Teilnehmer sowie ihre Nationalflagge aufgelistet. Möchte der User mehr über eine bestimmte Gruppe erfahren, so geht er den Weg über das entsprechende Pfeil-Icon.

Auf der zweiten Ebene erhält er dann die Details zur ausgewählten Gruppe. Über zwei weitere Pfeile in der Title Bar kann der User direkt zur Gruppe drüber oder drunter wechseln ohne erst einen Schritt zurück zu machen.

Im Hauptfenster findet man eine aktuelle Tabelle der Gruppe. Diese wird just-in-time berechnet. Das heißt, wenn ein Spiel läuft wird der aktuelle Spielstand direkt in dieser Tabellensicht berechnet. Direkt im Anschluss an die Tabelle findet man eine Historisierte Spielübersicht. Hier werden alle beendeten Spiele aufgelistet. Zu diesen Spielen können sich wieder die Details angezeigt werden. Durch diesen Teil des Fenster kann mittels der Flick-Geste durchgescrollt werden. Über diese Verbindung gelangt man wieder zum historisierten Liveticker.

Im dritten Hauptmenüpunkt findet der User die Rubrik News. Hier erfolgt zunächst eine Newsvorschau. Ein Vorschaubild wird angezeigt, sowie die Headline mit Datum und Uhrzeit wann die News gepostet wurden.

Interessiert sich der User für eine Headline, so kann er die News wieder über das Pfeil-Icon ansteuern. Dazu öffnet sich nun eine neue Seite in der die vollständigen News dargestellt werden. Der User hat nun die Möglichkeit die kompletten Nachrichten zu lesen. Ein vergrößern und verkleinern des Textes ist mittels der Pinch-Geste jederzeit möglich.

Bis zu 25 News werden historisiert direkt dargestellt. Über die beiden Pfeile in der Title Bar, sind die Nachrichten direkt auswählbar.

Der letzte und vierte Hauptmenüpunkt ist mit "Mehr" betitelt. Ebenfalls über eine Item Liste werden die einzelnen Unterpunkte realisiert. In dieser Liste befinden sich die Punkte: Einstellungen, Topscorer und About. Unter dem Begriff "Topscorer" erwartet den Anwender eine Liste der besten Spieler des Turniers, aufsteigend sortiert. Die Sortierung erfolgt zunächst nach der Punkteanzahl, sprich der gewonnen Spiele. Das zweite Kriterium ist die Anzahl gewonnener Sätze. Das dritte die Anzahl der verlorenen Sätze. Die Auswertung erfolgt über alle Gruppen, so dass man eine Übersicht über die zur Zeit erfolgreichsten Spieler des Turniers erhält. Der letzte Punkt "About" beinhaltet nur Informationen zu den Entwicklern und Auftraggebern.

3.3 Backend

Die Aufgabe des Backend ist die Datenhaltung der Anwendung. In diesem Teil wird die Speicherung der Daten beschrieben und erläutert.

Apple bietet schon lokal die Vorausetzungen einer Datenbank auf dem iPhone. Diese sind in den Core Services des iPhones unter Core Data enthalten. Diese werden aber nur zu der Laufzeit generiert. Core Data stellt eine Relationale Datenbank da, daher wird empfohlen eine Relationale Datenbank zu verwenden.

Das Backend für die App sollte so aussehen, dass die Daten auf einem SQL-Webserver gespeichert werden, damit sie lose gekoppelt sind und von verschiedenen Medien aus abgefragt werden können. Für die App wird die gleiche Struktur wie auf dem Webserver gespeichert, damit nur ein Update durchgeführt werden muss, um die aktuellsten Daten zu erhalten. Hinzu kommt noch, dass die Daten angezeigt werden können auch wenn der SQL-Webserver nicht erreichbar ist.

Die App sollte die Möglichkeit bieten die Verbindung zum Webserver über UMTS und WLan herstellen zu können.

In den unteren Themen wird die Struktur sowie Wartung und Administration beschrieben.

3.4 Datenbankstruktur

Um eine gute anfängliche Darstellung der Datenbankstruktur darzustellen und zu entwerfen verwenden wir das ERM (Entity-Relationship-Modell) nach Chen-Notation. Aus den Anforderungen aus dem Frontend geht hervor, dass die Datenbankstruktur im Schaubild (Abb. 14) dargestellt wird. Unten dargestellt sind die Entitäten aus dem Modell mit deren Attributen.

• News
  • Newsart
  • Datum
  • Uhrzeit
  • Titel
  • Text
  • Bild

(Die News beziehen sich auf alle relevanten Tabellen)

• Spiel
  • Heim
  • Gast
  • Heim Punkte
  • Gast Punkte
  • Sieger
  • Start Uhrzeit
  • End Uhrzeit
  • Datum

• Spielmeldung
  • Uhrzeit
  • Datum
  • Meldung
  • Meldungsart
  • Bild

• Betreuer
  • Name
  • Aufgabe
  • Bild

• Team
  • Bezeichnung
  • Siege
  • Niederlagen
  • Punkte
  • Bild

• Gruppe
  • Sieger
  • Bezeichnung

• Spieler
  • Name
  • Alter
  • Punkte
  • Infotext
  • Bild

• Spielfeld
  • Bezeichnung
  • Platzanzahl

Die Datenbank selbst wird nach dem gängigen Format der Relationalen-Datenbank realisiert werden. Diese Darstellung wird durch das EER (Abb. 15) dargestellt.

Diese Datenbankstruktur wird sowohl auf dem iPhone als auf dem SQL-Webserver vorhanden sein. Auf dem iPhone werden Daten in einer SQLite-Datenbank gespeichert. Die SQLite-Datenbank kann mit Hilfe des Core Data Framworks des SDK für die App nutzbar gemacht werden. Näheres wird in den unteren Themen Core Data und SQLite ermittelt.

3.4.1 Core Data

Core Data ist die Datenbankschnittstelle des iPhones OS. Es ermöglicht unteranderem die Speicherung der Daten auf einer SQLite Datenbank des iPhone OS. Core Data stellt folgende Funktionen zu verfügung.

• Speicherung der Daten in der internen Datenbank.
• Unterstützung einer Undo/Redo-Funktion.
• Unterstützung von Validierung.
• Sicherstellung das die Objektbezeichnungen untereinander aktuell bleiben.
• Gruppiert und filtert die gespeicherte Daten.

^[31]

3.4.2 SQLite

SQLite ist eine Programmbibliothek, die eine relationale Datenbank beinhaltet enthält. Sie beinhaltet Transaktionen, Sichten, Unter-/abfragen, Trigger und SQLite ist weitestgehend eingenständig. Desweitern muss SQLite nicht installiert und konfiguriert werden. Der Ausschluss einer Server-Client-Architektur macht SQLite sehr kompakt. Aufgrund der zuvor erwähnten Kompaktheit hat sich SQLite schnell im Mobiltelefonbereich durchgesetzt. SQLite ist gemeinfrei und wird unteranderem von Android und Apple für deren Betriebsysteme verwendet. ^[32]

3.5 Administration

Die Administration kann von bis zu 2 Personen zentral gelöst werden, da der Wartungsaufwand nur auf die zentrale Datenbank und der App lastet. Diese Personen pflegen auch die Daten der App.

3.5.1 Datenpflege

Die Datenpflege muss einmal für den SQL-Webserver gewährleistet werden und einmal für die Datenbank auf dem iPhone.

Die Datenpflege des iPhones wird automatisch gewährleistet, d.h. die Daten werden mit der Datenbank des Webservers der App synchronisiert. Dies geschieht beim starten der App. Danach werden mit einer Push-Freigabe die Spiele und ähnliche Entitäten, die sich innerhalb von bis zu 5 min ändern können, auf dem iPhone mit der auf dem Webserver synchronisiert werden. Ausgeschlossen von dem Push sind die Entitäten Spielfeld, Betreuer und Gruppe.

Wie die Spielstände erfassst werden kann auf der WinfWiki-Seite "Web-Prototyp für die Erfassung von Spielständen im Squash auf mobilen Endgeräten" nachgelesen werden. Die Restlichen Daten wie die Daten der Teams müssen händisch von den Administratoren auf dem SQL-Webserver eingepflegt werden.

3.5.2 Wirtschaftlichkeit

Die Wirtschaftlichkeit sagt aus wie effizent ein Projekt ist. Diese ergibt sich aus der Division der Einnahmen gewinne durch die Kosten. Die Kosten sind im Artikel Kosten beschrieben, genauso wie der Einnahmen.

Die Kosten für die Wartung betragen 9.800€. Der genau Aufbau der Wartungkosten kann man unter dem Titel 3.6 Wartung nachgelesen.

Die Kosten für die Hardware sind mit wahrscheinlich 1.400€ zu beantragen. Genau nachzulesen unter 3.8.2 Einmalige Kosten.

Hinzu kommen die Entwicklerkosten, diese betragen 9.724,70€. Die Auflösung kann man unter den Artikel 3.8.1 Entwicklungskosten nachlesen.

Die Gesammtkosten der App belaufen sich auf 20.924,70€.

Der Erlös der App wird nur mit der Werbung und Sponsoring erwirtschaftet. Man sollte versuchen die Kennzahl der Wirtschaftlichkeit auf größer oder gleich eins zu erwirtschaften. Dies würde bedeuten, dass der Erlös am Ende der Squash WM 2011 mindest 20.924,70€ betragen sollte um eine positive Effizent zu erhalten.

3.6 Wartung

Die Wartung des laufenden Systems wird durch die Administratoren überwacht. Die Wartung beinhaltet auch das aktualisieren der Daten in der Datenbank und die Funktionfähigkeit das die App diese erhält.

Die Kosten für die Wartung errechnet sich wie folgt. Einmal die Personalkosten der Administratoren. Das sind die die Arbeitsstunden mal den Kostensatz. Wir rechnen damit einen Service anzubieten, der sich an den Öffnungszeiten hält. Diese sind von 9.30 Uhr bis 23.00 Uhr. Das sind 14 Stunden pro Tag. Die WM dauert 7 Tage. Die gesamte Stundenzahl der Administratoren beträgt daher 98 Stunden. Wir gehen von einen Kostensatz für die Administratoren von 50€ pro Stunde aus, darin sind unteranderem die Kosten für den Webserver und der benötigten Materialien zum warten dieses Servers enthalten.

Anzahl Administratoren * (Personenstunde * Kostensatz) = Administrationskosten
2 * (98 * 50€) = 9.800€

3.6.1 Back-Up-System

Eine Art Back-Up ist schon in der Datenbankstruktur erhalten. Dies bezieht sich darauf, dass die App auf die lokale Datenbank zur Darstellung zugreift und nicht die Datenbank des Webservers verwendet. Im Falle, dass der Webserver nicht erreichbar ist wird trotzdem nur auf die Daten auf dem iPhone zugegriffen. Das Back-Up-System des Webservers sollte einfach gehalten werden um weitere Kosten zu verhindern. Es würde eine Back-Up-Datenbank reichen, die im Notfall die Daten vom Vormittag wiederherstellt, das obliegt der Dienstleistungen des SQL-Webserver-Anbieters. Die Aufgabe dieses System zu warten obliegt dem Unternehmen bei dem der SQL-Webserver gemietet wird. Die Kosten sind in den Wartungskosten enthalten.

3.6.2 User-Help-Desk

Wenn ein Fehler während der Benutzung der App auftritt, wird die eine Meldung ausgegeben. Die Medlung beinhaltet den Wunsch, dass sich der User mit einer Fehlerbeschreibung via Email an die Administratoren wenden kann. Diese werten die Emails und versuchen die Fehler zu beheben.

3.7 Distributionswege

Beim iPhone App gibt es genau zwei Wege das App zu verteilen:

Die erste Möglichkeit besteht in der Ad Hoc Distributation auf die wir nicht näher im Detail eingehen, da das App über den App-Store vertrieben werden soll. Die zweite Möglichkeit besteht in der Distribution über den App-Store von Apple selbst.

Für beide genannten Arten der Verteilung der Anwendung muss ein eigenes Distributions-Zertifikat und Provisioning Profil erstellt werden. Dieses erstellt man innerhalb von Certificats im Apple iPhone Protal und mit Hilfe der Entwicklungsumgebung Xcode. Dabei werden drei Entitäten herangezogen:

- Personen

Die Personen die an der Entiwcklung beteiligt sind. Hierfür bietet Apple die Möglichkeit komplete hirarische Teams im Protal anzulegen^[33]

- Devices

Die Device ID ist notwendig, um das Provisioning Profil zu erstellen und kann im Organizer in Xcode ausglesen werden^[33]

- Apps

Die App ID und der Appname

Daraus wird ein Zertifikat und ein Provisioning Profil generiert. Das Provisioning Profil für die Distribution findet man im Bereich Certification innerhalb von Provisioning wieder. Die Art der Distribution (App-Stor oder Ad Hoc) legt man in der Eingabemaske für das Provisioning Profil fest. Der Ablauf besteht hierbei aus folgenden Schritten:

1. Der Entwickler beginnt mit dem sog. Certificate Signing Requst (CSR) welches er über die Entwicklungsumgebung und dessen Schlüsselbundverwaltung lokal speichert und anschließend über das Portal in der Rubrik Provisoning hochlädt.^[34]

2. Nach dem das Zertifitkat von einem Administrator bestätigt wurde, bekommt der Entwickler das signierte Zertifikat zurück in dem er es im Provisoning Bereich auswählt und herunterlädt. Das Zertifikat hat hierbei eine standard Schlüsselänge von 2048 Bit mit einem RSA Algorithmus.^[34]

3. Der Entwickler lädt zudem das Intermediate Zertifikat herunter (WWDR), welches bei jeder App von nöten ist. ^[34]

4. Der Entwickler lädt die Device ID's und die Device Namen hoch (iPhone, IPad etc.).^[34]

5. Der Entwickler lädt die App ID und den App Namen im Provisioning Portal hoch. Hierbei ist wichtig zu erwähnen, dass alle App ID's einzigartig sind. Dei App Id's sind normalerweise als Resvere Domain Name-Notation gekennzeichnet (beispielsweise "de.teamiphone.fom"). Der App Name sollte kurz sein, da man sonst nicht den vollen Namen des App als Text auf einem Gerät lesen kann.^[34]

6. Der Entwickler bekommt das Provisoning Profile und kann es herunterladen.^[34]

Nach der Freigabe muss man das heruntergladene Zertifikat und das Provisoning Profile auf der Entwicklungsumgbung installieren und das Zertifikat in die Schlüsselbundverwaltung einbinden. Wenn alle Schritte erledigt sind kann der Weg über iTunes genutz werden um das App im Store anzubieten.

3.7.1 App-Store

Um eine App am Ende in den App-Store zur Prüfung einzureichen, muss man noch an Apples iPhone Developer Programm teilnehmen, was einmalig 99 US Dollar kostet. Nachdem man sich regestiert hat kann man über das Programm iTunes das zertifizierte App über den App-Store anbieten.^[34]

In folgendem erscheint der Weg einer Verbreitung einer App aufwendig und teuer, doch man darf nicht vergessen welche Masse an potentziellen Käufern/ Nutzern über den App-Store angesprochen werden. Dahingehend muss der lange Weg einer Veröffentlichung als Schritt zu einem Weltweiten Markt betrachtet werden.

3.7.2 Sponsoring

Im Hintergrund der Projektfinanzierung ist eine sich selbst tragende Wirtschafseinheit zu schaffen. Dahingehnd liegt es nahe sich für das App Sponsoren zu suchen. Dieses kann durch Absprache mit dem WM Veranstalter geschehen. Beispielsweise könnten die Sponsoren der eigentlichen WM auf die App aufmerksam gemacht werden und Ihnen so die Möglichkeit angeboten werden dort in kleinen Rahmen eine kleine Fläche des Apps selbst als Werbebanner auszuprägen.

Zudem könnte eine Refinanzierung des Projektes dadruch realisiert werden, dass die App im Vorfeld modulweise programmiert wird und von den Inhalten her leicht austauschbar ist. Somit könnte die App auch für andere Sportveranstaltungen genutzt werden. Damit wäre die Möglichkeit geschaffen auf lange Sicht die Entwicklungskosten wieder einzuspielen.

3.7.3 Marketing

Um den Aspekt des Marketings nicht zu verachten, wurden in der Konzeptionierung des Projektes die Idee aufgenommen, das App in Vorfeld und während der WM über verschiedene Wege bekannt zu machen. Darunter zählt beispielsweise die Möglichkeit das App auf der Homepage des Veranstalters kenntlich zu machen. Ferner wurde angedacht ein Banner zu erstellen, welches die Besucher der WM direkt auf das App hinweist. Dieses müsste zusätzlich in Auftrag gegeben werden. Der Werbespurch des Banner könnte lauten: "Verfolgen Sie die WM immer stets Live mit dem neuen Squash-WM iPhone App".

3.8 Kosten

Im Bereich Kosten differenzieren wir zwischen den Entwicklungskosten sowie den voraussichtlichen Einnnahmen. Jedoch dürfen weiter Kosten nicht außer Acht gelassen werden.

So können durch die Datenpflege des Livetickers weitere Personalkosten anfallen. Auch die Gebühr, die Apple verlangt für die Software Developer Lizenz sollte nicht vergessen werden. Desweiteren können laufende Kosten für die App anfallen. Da die Nachrichten und Ergebnisse im Web auf einem Server abgelegt werden müssen um mit der App darauf zugreifen zu können. Die laufenden Kosten richten sich also nach einem normalen Webserver der angemietet werden kann.

3.8.1 Entwicklungskosten

Die Entwicklungskosten beinhalten zu einem die Kosten der Entwickler mit 7.500€ und die Anschaffungskosten mit 2.224,70€ daraus resultieren Entwicklungskosten von 9.724,70€. Die genaue Zusammensätzung der Kosten ist unten Beschrieben.

3.8.1.1 Entwicklerkosten

Die Entwicklerkosten für die App ergeben sich aus dem Aufwand multipliziert mit dem Kostensatz pro Stunde für den Entwickler. Dabei rechnen wir mit einem geschätzten Aufwand von 100 Personenstunden. Innerhalb dieser 100 Personenstunden fallen das Erstellen des Frontends und des Backends sowie eine angemessen Dokumentation der Software und das bereitstellen der App. Die geschätzten Kosten für einen Entwickler betragen 75€. Daraus ergeben sich die geschätzten externen Entwicklerkosten:

Personenstunde * Kostensatz = Entwicklerkosten
100 * 75 = 7.500€

3.8.1.2 Anschaffungskosten

Hinzu kommen noch Anschaffungskosten, die in die Entwicklerkosten mit einfliesen. Einmal muss ein Entwickler Arbeitsplatz eingerichtet werden, das währen einmal ein Mac-Rechner und Testgeräte (iPhone 4, iPhone 3Gs)

1x Mac-Arbeitsplatz        = 1.000,00€
1x iPhone 4                =   629,00€
1x iPhone 3Gs              =   519,00€
1x Applezertifizierung     =    76,70€ (99$)
-------------------------------------------
Gesamte Anschaffungskosten = 2.224,70€

Auf jeden Fall sollten vorher Angebote eingeholt werden und diese verglichen werden.

3.8.2 Einmalige Kosten

Unter Einmalige Kosten sind die Kosten für Ressourcen einzuordnen, die einmalig erworben werden müssen. In unserem Fall sind es die Rechner, die die Administratoren verwenden um die Ergebnisse einzutragen und die Emails zu bearbeiten.

 
2x Arbeitsfähiger Rechner = 1.400€

3.8.3 Einnahmen

Die App wird grundsätzlich kostenlos über den App-Store verfügbar sein. Die App soll ein Goodie sein. Jedoch sollte die Möglichkeit berücksichtigt werden, innerhalb der App dezent Werbung einzublenden. Potenzielle Kunden, die dafür in Frage kommen sind in erster Linie die Sponsoren die bei der Squash-WM mitwirken. Im erweiterten Kreis der Kunden müssen auch Sportartikelherstelller in Betracht gezogen werden. Durch den Effekt Werbung innerhalb der App zu platzieren kann die App trotz kostenlosen Angebot als sich selbst finanzierende Geschäftseinheit betrachtet werden.

4 Fazit

In diesem Fazit wird die Durchführung der Fallstudie zusammengefasst, dies beinhaltet den zeitlichen und ergebnisorentierten Ablauf. Am Ende wird ein kurzer Ausblick der Fallstudie beschrieben.

4.1 Fazit

Nach dem gesichtet wurde welche Apps zum Thema Sporttuniere bereits auf dem Markt sind, haben wir das Aussehen und die Funkionen dieser Apps analysiert. Folgende Informationen zum Aufbau dieses Typs der App haben wir erhalten:

• Live Ticker
• Informationen über das Spiel, Teams, Spieler und Austragungsort
  • Textural
  • Bildlich
  • Aktuallisierung über Push und/oder Button
• Gruppentabelle
• Rankings (Bester Spieler/ Bestes Team)
• Aktuallisierung der Spielinformationen über Push und den User möglich.

Die gestalltung eines benutzerfreundlichen Frontend wird schon weitesgehend von Apple vorgeben. Daher gab es keine Auswahlmöglichkeit in diesem Bereich. Nachdem die App-Sichtung abgeschlossen war, sind wir zum Design des Backends übergegangen. Für das Backend mussten wir uns mit der Problematik auseinandersetzen, schnell und einfach die Informationen für alle Kunden der App erreichbar zu machen. Daraufhin haben wir uns geeinigt, dass eine Datenhaltung auf einem SQL-Webserver realisiert werden soll, da dieser über das Internet einfach gewartet und die Daten plattformunabhängig abgefragt werden können. Dies verringert die Kosten für das Personal und Hardware. Dieses Verfahren der Datenhaltung hat sich auch bei den anderen Sport-Apps bewährt.

Die Funktionen die zur Darstellung der Daten im Frontend verwendet werden, sind einfache Abfragen der lokalen Datenbank des iPhones. Die direkte Abfrage der lokalen Datenbank ist schneller als die Abfrage auf dem SQL-Webserver. Der Aufwand der Entwicklung wird daher geringer und es existiert ein Back-Up-System. Dies begründet sich darin, dass die Datenbank des Webservers zyklisch mit der lokalen Datenbank auf dem iPhone synchronisiert wird und so bei einem Ausfall des Webservers die App mit Daten angezeigt werden kann. Die Synchronisierung der lokalen Datenbank wird entweder durch ein Push gewährleistet oder durch das betätigen des Aktuallisieren-Buttons auf den dafür vorgesehen Oberflächen. Die Kosten der Entwicklung und Laufzeit sind wahrscheinliche Kosten, auf Basis unserer Erfahrung. Diese können unter anderem beim überziehen der Zeit der Entwicklung daraufhin abweichen. Der Bereich der Amortisierung der App ist nicht ganz geklärt, da nicht abzusehen ist welche Sponsoren wieviel Mittel in das Projekt einfließen lassen. Daher ist unsere Empfehlung, dass das Ziel ist die Kosten auf unbestimmte zu amortisieren. Da die Kosten und Aufwände für diese App nebensächlich sind und die App als Goodie zur Squash WM 2011 gilt, sollte kein kommerzieller Erfolg gewährleistet werden.

Es gibt noch offene Punkte im Bereich der Erweiterung der App auf andere Berreiche, dies wird im Teil 4.2 Ausblick näher erläutert.

4.2 Ausblick

Da diese Fallstudie ein Konzept ist gehen wir davon aus das unser erstelltes Konzept realisiert wird. Aber auch die Möglichkeit die Datenbankstruktur für andere Sporttuniere wäre möglich, zum Beispiel bei einem Tennisturnier. Die Anpassungen wären nur oberflächlich und die Datenbankstruktur würde so erhalten bleiben. Mit unserem Vorschlag der Speicherung und Aktualisierung der Daten auf einem SQL-Webserver, ist die Anwendung dadurch autark. Dadurch wäre es auch möglich unsere Datenbankstruktur über eine Android-App zu verwenden oder aber auch über eine Website.

Dies sind Möglichkeiten auf Basis unseres Konzeptes, um eine breitere Masse anzusprechen.

5 Anhang

5.1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
iOS	Betriebssystem von Apple für iPhone, iPod und iPad
UE	User Experience
App	Applikation
HIG	Human Interface Guidelines
OS X	Betriebssystem von Apple für MacBook und iMac
UI	User Interface
Xcode	Entwicklungsumgebung des SDK
SDK	Software Development Kit
HTML	Hypertext Markup Language
URL	Uniform Resource Locator
ERM	Entity-Relationship-Modell
EER	Enhanced-Entity-Relationship-Modell

5.2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	iOS Zugriff auf Hardware
2	Squash Court
3	Projektplan
4	User Experience
5	Utility Schema
6	Productivity Schema
7	iPhone Title Bar
8	iPhone Title Bar Buttons
9	iPhone Icon Bar
10	iPhone Item List
11	iPhone iPhone Check Mark, Add, Arrow Icons
12	iPhone Notification
13	Hierarchische Struktur der App
14	Screenshot Spielplanmenü
15	Screenshot Gruppenmenü
16	Screenshot Newsnmenü
17	ERM Squash WM 2011
18	EER Squash WM 2011
19	Ablauf einer Distribution

5.3 Fußnoten

1. ↑ Vgl. Squash Wm 2011 (2010)
2. ↑ Vgl. iPhone App Store (2010)
3. ↑ Vgl. http://de.wikipedia.org/wiki/Apple#Mitarbeiter
4. ↑ ^{4,0 4,1 4,2} Vgl. http://de.wikipedia.org/wiki/Apple#Marktanteile_und_Umsatzentwicklung
5. ↑ ^{5,0 5,1 5,2 5,3} Vgl. http://www.apple-history.com/
6. ↑ Vgl. Markus Stäuble Seite 1
7. ↑ Vgl. http://time.com/
8. ↑ ^{8,0 8,1 8,2 8,3 8,4 8,5 8,6 8,7} Vgl. http://www.iphone-könig.de/
9. ↑ ^{9,0 9,1 9,2} http://www.apple.com/ios/
10. ↑ Vgl. Markus Stäuble Kapitel 3
11. ↑ Vgl. http://www.drweb.de/magazin/iphone-apps-gestalten-erfahrungsbericht-mit-tipps-und-tricks/
12. ↑ ^{12,0 12,1 12,2} Vgl. http://de.wikipedia.org/wiki/Squash
13. ↑ ^{13,0 13,1 13,2} Vgl. http://www.nett-im-let.de/regeln.htm
14. ↑ entnommen von http://www.marena-tennis.de
15. ↑ ^{15,0 15,1 15,2 15,3 15,4} Vgl. Markus Stäuble Kapitel 2
16. ↑ Eigene Entwicklung
17. ↑ ^{17,0 17,1 17,2 17,3 17,4} Vgl. iPhone-Apps gestalten (2010)
18. ↑ entnommen von http://de.wikipedia.org/wiki/User_Experience
19. ↑ ^{19,0 19,1 19,2 19,3 19,4 19,5} Vgl. User Experience (2009)
20. ↑ Vgl. http://developer.apple.com/devcenter/ios/index.action
21. ↑ Apple User Experience (2010)
22. ↑ Vgl. The Aqua Interface (2010)
23. ↑ Vgl. Ginsburg (2010), Seite 4
24. ↑ Entnommen aus Ginsburg (2010), Seite 5
25. ↑ Entnommen aus Ginsburg (2010), Seite 8
26. ↑ ^{26,0 26,1 26,2 26,3 26,4 26,5} Entnommen von iPhone GUI Elements (2010)
27. ↑ Vgl. Stäuble (2011), Seite 121
28. ↑ ^{28,0 28,1 28,2} Vgl. Web App vs. Native App? (2010)
29. ↑ Vgl. Stäuble (2011), Seite 139
30. ↑ ^{30,0 30,1} Vgl. Stäuble (2011), Seite 76
31. ↑ Vgl. iPhone-Apps gestalten (2010)
32. ↑ Vgl. http://de.wikipedia.org/wiki/SQLite
33. ↑ ^{33,0 33,1} Vgl. Technische Universität Gratz
34. ↑ ^{34,0 34,1 34,2 34,3 34,4 34,5 34,6} Vgl. Markus Stäuble Kapitel 6
35. ↑ Tu Graz

5.4 Literatur- und Quellenverzeichnis

Ginsburg (2010)	Ginsburg, Suzanne: Designing the iPhone User Expercience, 1. Auflage, Pearson Education Inc., Boston 2010
Stäuble (2011)	Stäuble, Markus: Programmieren für iPhone und iPad, 3. Auflage, dpunkt.Verlag, Heidelberg 2011
DudneyAdamson (2010)	Dudney, Bill & Adamson, Chris: Entwickeln mit dem iPhone SDK, 1. Auflage, O'Reilly Verlag, Köln 2010
Web App vs. Native App? (2010)	Kennzeichen b http://www.openpr.de/news/445107/Web-App-vs-Native-App.html (30.12.2010, 07:26)
Squash Wm 2011 (2010)	Kern, Uwe: Squash Wm 2011, 02.12.2010, http://winfwiki.wi-fom.de/index.php/Squash_WM_2011 (19.12.2010, 13:18)
iPhone-Apps gestalten (2010)	Read, Sven: iPhone-Apps gestalten - Erfahrungsbericht mit Tipps & Tricks, 20.08.2010, http://www.drweb.de/magazin/iphone-apps-gestalten-erfahrungsbericht-mit-tipps-und-tricks/ (19.12.2010, 13:48)
User Experience (2009)	Katzenberg Design: User Experience - Der Erfolgsfaktor, 07.04.2009 http://www.katzenbergdesign.net/Agentur-Ravensburg/blog/?p=76 (19.12.2010, 17:07)
Apple User Experience (2010)	Apple, User Experience: http://developer.apple.com/ue/ (19.12.2010, 14:02)
The Aqua Interface (2010)	Apple: The Aqua Interface, 20.08.2009 http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGPartIII/XHIGPartIII.html%23//apple_ref/doc/uid/TP40002723-TPXREF101 (19.12.2010, 14:15)
iPhone GUI Elements (2010)	iPhone GUI Elements http://www.designerstoolbox.com/designresources/iphone/ (30.12.2010, 11:51)
iPhone App Store (2010)	iPhone App Store http://www.apple.com/de/iphone/apps-for-iphone/ (08.01.2011, 14:31)
Apple Geschichte (1)	Apple History (2011) http://www.apple-history.com/ -- 20:35, 8. Jan. 2011 (CET)
Apple Geschichte (2)	Computer Modell Katalog (2011) http://computer-modell-katalog.de/apple2.htm -- 20:35, 8. Jan. 2011 (CET)
Apple Umsätz/Gewinne/Mitarbeiter (2011)	Wikipedia http://de.wikipedia.org/wiki/Apple -- 20:35, 8. Jan. 2011 (CET)
iPhone 4 Daten (2011)	iPhone König http://www.iphone-könig.de/ -- 20:35, 8. Jan. 2011 (CET)
Time (2011)	Time http://www.time.com/time/ -- 20:35, 8. Jan. 2011 (CET)
Apple iOS(2011)	iOS http://www.apple.com/ios/ -- 20:35, 8. Jan. 2011 (CET)
Squash WM(2011)	Squash WM www.squashwm2011.de -- 20:35, 8. Jan. 2011 (CET)
Squash WM(2011)	Squash in Deutschland http://www.squash-in-deutschland.de -- 20:35, 8. Jan. 2011 (CET)
Squash das Spiel(2011)	Nett im Let http://www.nett-im-let.de/regeln.htm -- 20:35, 8. Jan. 2011 (CET)
Squash das Spiel(2011)	Wikipedia http://de.wikipedia.org/wiki/Squash#Aktuell_Z.C3.A4hlweise_bis_11 -- 20:35, 8. Jan. 2011 (CET)
Ablauf einer Distribution für iPhone Apps(2011)	Tu Graz http://www.tugraz.at/ -- 20:35, 8. Jan. 2011 (CET)