iPlanningPoker

Zusammenfassung

Das Ziel dieser Semesterarbeit war die Erstellung einer App für das iPhone und das iPad. Die App wurde entwickelt, um das Planning Poker digital und drahtlos stattfinden zu lassen.

Mehrere iPhones können sich drahtlos mit einem iPad verknüpfen. Die Teilnehmer können auf dem iPhone eine Karte mit Storypoints auswählen und diese an das iPad übermitteln. Haben sich alle Teilnehmer für einen Wert entschieden, werden diese auf dem iPad angezeigt. Danach kann eine neue Runde begonnen werden und die Teilnehmer können sich wieder für eine Karte entscheiden.

Planning Poker wird in der agilen Projektmethode Scrum verwendet, um Anforderungen in deren Komplexität zu schätzen. Die App wurde entwickelt, um bekannte Probleme zu vereinfachen. Dieses Ziel wurden erreicht.

Ein aufwendiger, aber auch spannender, Teil war die Umsetzung der Kommunikation zwischen den iPhones und dem iPad. Da diese drahtlos stattfindet, können verschiedenste Fehlerquellen auftauchen. Es wurde auch ein eigenes Kommunikationsprotokoll entwickelt, welches bereits einige Fehlerquellen auschliessen sollte.

Einleitung

Ausgangslage

Das Planning Poker ist ein Bestandteil der agilen Projektmethode Scrum. Viele Teams kennen die Probleme des Planning Pokers:

• Zu wenige Kartendecks sind vorhanden oder erst gar nicht auffindbar
• Das Timing beim Aufdecken der Karten stimmt nicht
• In einem grossen Raum kann es schwierig sein, die verschiedenen Werte der Karten von den Kollegen zu sehen.

Diese Punkte sollen mit der App angegangen werden, um ein flüssigeres Ablaufen des Prozesses zu fördern.

Ziele der Arbeit

Es soll eine universelle App entwickelt werden. Dies erlaubt es, die App sowohl auf dem iPhone wie auch auf dem iPad einzusetzen. Zur Unterstützung der Kommunikation zwischen den iPhones und dem iPad wird das Apple eigene Framework GameKit eingesetzt. Das Framework GameKit wird verwendet, da es bereits eine grundlegende Funktion für die Verknüpfung von verschiedenen iOS Geräten bereitstellt.

Das vorrangige Ziel ist es, mit der App unkomplizierte eine Verbindung sowie die Kommunikation zwischen mehreren mobile Geräten erfolgreich herzustellen.

Das iPad wird dabei als "Server" agieren und die Verbindung mit den iPhones aufbauen. Der User hat dann die Möglichkeit, auf dem iPhone eine Karte auszuwählen. Die Karte wird dann verdeckt auf dem iPad angezeigt. Sobald alle User eine Karte gewählt haben, werden die Karten auf dem iPad aufgedeckt und eine neue Runde kann beginnen.

Aufgabenstellung

Folgende Aufgabenstellungen wurden definiert:

• Definition der Anforderungen der zu entwickelnden iOS App
• Analyse der GameKit API
• Definition des Netzwerkverkehrs
• Umsetzung einer universellen iOS App

Projektmanagement

Projektplanung

Der folgende Projektplan gibt einen Überblick über den Ablauf des Projekts und dessen wichtigsten Meilensteine.

Angepasste Planung

Die Semesterarbeit wurde um einen Monat verlängert, da ich geschäftlich sehr viel zu tun hatte. Die Projektplannung wurde entsprechend angepasst.

Die Abschlusspräsentation wird nach Abgabe der Semesterarbeit durchgeführt.

Aufwand

Laut Reglement sollte der Aufwand für die Fertigstellung der Semesterarbeit mindestens 120 Stunden betragen. Entsprechend wurde die Planung darauf ausgelegt.

Der Ist-Aufwand ist ein wenig höher als anfangs geplant. Die Aufwände für die Kommunikation zwischen den Clients und dem Server ist höher ausgefallen als geplant. Das Schreiben der Dokumentation hat ebenfalls mehr Zeit benötigt als vorgesehen.

Dokumentation

Die Dokumentation wurde ausschliesslich in HTML und CSS geschrieben. Das Inhalts- und das Abbildungsverzeichnis wurden dynamisch mit JavaScript generiert. Um die Seite auch korrekt ausdrucken zu können, wurde die Software Prince verwendet, welche HTML-Seiten in PDFs umwandelt. Dadurch konnte diese Dokumentation, gleich wie der Source-Code der Applikation, mit der Versionsverwaltungssoftware Git verwaltet und über den Online-Service GitHub geteilt werden.

Sourcecode

Der Sourcecode der iOS App wurde ebenfalls mit der Versionsverwaltungssoftware Git verwaltet und kann über den Online-Service GitHub abgerufen werden.

Open Source

Ich habe mich, in Absprache mit Beat Seeliger, entschieden den Sourcecode wie auch die Dokumentation als Open Source zur Verfügung zu stellen. Als Lizenz wurde die MIT License gewählt.

Die GitHub Repositories sind unter diesen zwei Adressen zu finden:

• iOS App: https://github.com/gabac/iPlanningPoker
• Dokumentation: https://github.com/gabac/iPlanningPoker-doc

Planning Poker

Planning Poker ist ein Schätzverfahren, welches in der agilen Projektmethode Scrum zum Einsatz kommt.

Mit Hilfe von Planning Poker wird die Komplexität von User Stories (Requirements) geschätzt. Das Schätzen wird mit Hilfe von Spielkarten realisiert. Diese lehnen sich typischerweise an die Werte der Fibonacci-Folge an: 1, 2, 3, 5, 8, 13, 20, 40, 100. Optional gibt es noch Karten mit dem Wert 0, einem Fragezeichen (unsicher) und einer Kaffeetasse (Pause). Die Fibonacci-Folge wurde gewählt, um aufzuzeigen, dass komplexe User Stories schwieriger zu schätzen sind. Dies führt zu einer ungenaueren Schätzung.

Das Prinzip ist simpel. Jede User Story wird besprochen und offene Fragen werden untereinander geklärt. Sind keine weiteren Fragen mehr vorhanden, entscheidet sich jeder Entwickler, verdeckt, für eine Spielkarte. Haben sich alle Teilnehmer für eine Karte entschieden, werden die Karten gemeinsam aufgedeckt. Durch die verdeckte Karte wird der Einfluss von anderen Teilnehmer minimiert und es muss eine eigene Entscheidung gefällt werden.

Anforderungen an die iOS App

Features

Das UI der App soll minimalistisch gehalten werden. Die wichtigsten Funktionalitäten der App sind der einfache Verbindungsaufbau zwischen den iPhones und dem iPad, das einfache Auswählen eines Kartenwertes auf dem iPhone und die Darstellung der gewählten Werte auf dem iPad.

Es wurde ein Mockup erstellt, um die Vision klarer darzustellen.

Um dem User ein einheitliches Erlebnis zu bieten, wird eine universelle App erstellt. Dies bedeutet, die App kann sowohl auf dem iPhone wie auch auf dem iPad ausgeführt werden. Es wird dynamisch entschieden, welche Inhalte auf welchem Gerät angezeigt werden sollen.

User Interface

Die Auswahl der Karten wird mit Hilfe des Coverflows Paradigma dargestellt. Coverflow wird auf dem iPhone z.B. für die Albumauswahl innerhalb der Musik App verwendet. Der User wird die Möglichkeit haben, zwischen den verschiedenen Kartenwerten hin und her zu wischen. Hat er sich für einen Wert entschieden, kann er die Karte selektieren und der Wert wird zum iPad übertragen.

Auf dem iPad ähnelt die Darstellung einem Tisch. Die verschiedenen angemeldeten User werden mit ihrem Namen angezeigt.

Use Cases

Die App beinhaltet zwei wichtige Use Cases, welche im Diagramm abgebildet worden sind.

Anforderungsübersicht

Die Anforderungen wurden direkt aus den Use Cases bzw. von den Befragungs-, Kreativitäts- und Beobachtungstechnik abgeleitet. Die Beobachtungstechnik wurde während diverser Planning Pokers eingesetzt, um direkt vor Ort die wichtigsten Anforderungen heraus zu filtern. Mittels der Kreativitätstechnik wurden vor allem Anforderung für ein möglichst innovatives UI erstellt.

Vorlage

Alle Anforderungen wurden anhand folgender Vorlage erstellt

Anforderungen

Architektur

Systemumfeld (System- und Kontextabgrenzung)

Das System besteht aus einer iOS App, welche sowohl auf einem iPhone wie auch auf einem iPad installiert werden kann. Je nach Kontext erfüllt die App andere Aufgaben bzw. wird von einer anderen Zielperson verwendet. Die iPhones und das iPad kommunizieren drahtlos miteinander.

Prozess Systemkontext "Verbindungsaufbau"

1. Der Scrum Master startet die App auf dem iPad und versetzt das iPad in den "Verbindungsmodus".
2. Das iPad sucht nach iPhones, welche sich mit einem iPad verbinden möchten.
3. Der Teilnehmer startet die App auf dem iPhone und sucht nach einem iPad. Sobald ein iPad gefunden worden ist, verbindet sich das iPhone automatisch mit dem iPad.
4. Das iPad zeigt alle verbundenen iPhones an.
5. Der Scrum Master startet das Planning Poker.

Prozess Systemkontext "Karte wählen"

1. Die Teilnehmer wählen eine Karte auf dem iPhone aus.
2. Die iPhones senden den Kartenwert an das iPad.
3. Sobald alle Teilnehmer eine Karte gewählt haben, zeigt das iPad den gewählten Kartenwert der Teilnehmer einzeln an.

Aufbau

Die Applikation wird in verschiedene Teile gegliedert. Die Gruppe ViewControllers sorgt für die Darstellung der Daten innerhalb eines UIs auf dem iPad, wie auch auf dem iPhone. Die Gruppe Connection sorgt sich um die Verbindung zwischen einem iPad und verschiedenen iPhones. In der Gruppe DataModel werden die Daten beschrieben, welche zwischen dem iPad und den iPhones ausgetauscht werden.

Testing

Akzeptanz Testing

Die Akzeptanz Tests werden anhand der Requirements definiert und haben daher eine direkte Verbindung zu den Requirements.

Vorlage

Alle Akzeptanz Tests wurden anhand folgender Vorlage erstellt.

Akzeptanz Tests

Übersicht Abnahme Akzeptanz Tests

Unit Testing

Die App wird mittels dem Integrationsserver Jenkins bei jedem Change neu gebaut. Vor dem Erstellen der App werden alle Unit Tests ausgeführt. Dafür wird das Open-Source Tool xctool verwendet.

Unit Tests wurden pro Package durchgeführt. Nachfolgend eine Übersicht der Tests und deren Resultate.

Die Unit Tests stellen sicher, dass die verschiedenen Zustände zu bestimmten Zeitpunkten in der App gesetzt sind. Diese Zustände werdem im Kapitel 10, Umsetzung der iOS App, genauer erläutert.

Analyse GameKit API

Einführung

GameKit ist eine Sammlung von API's die für Spielentwickler entworfen worden ist. Diese API's bieten unter anderem die Möglichkeit, eine Peer-to-Peer bzw. Client Server Verbindung, auch GKSession gennant, aufzubauen. Dies wird nicht nur im Zusammenhang mit Spielen gebraucht und wird von verschiedensten App Typen eingesetzt.

Apple hat diesen Zustand bemerkt und bietet mit iOS7 diese API's unabhängig von GameKit an. Die neugeschaffenen API's werden unter dem "Multipeer Connectivity" Framework zusammengefasst. Die neuen API's bieten genau die gleiche Funktionalität, haben aber verschiedene Bereiche vereinfacht. Im Gegenzug wurden die GKSession Klassen auf "deprecated" gesetzt und werden in naher Zukunft entfernt.

iPlanningPoker basiert noch auf den GKSession Klassen, da die Entwicklung vor der Veröffentlichung von iOS7 begonnen hat. Eine Migration auf das neue Framework ist möglich und wird nach dem Abschluss der Arbeit vorangetrieben.

Der wichtigste Punkt weshalb dieses Framework gewählt wurde, ist der Vorteil, dass sich die App nicht für einen Kommunikationskanal entscheiden muss. Es wird automatisch vom Framework entschieden, ob sich nun die Geräte via Bluetooth oder WLAN miteinander verbinden. Das Auffinden, wie auch das Anpreisen der Geräte geschieht über einen Abstraktionslayer. Für diese Tasks wird innerhalb von GameKit der Apple Service Bonjour verwendet.

GKSession und GKSessionDelegate

Um die Klasse GKSession zu instanzieren ist es notwendig, sich für einen Modus zu entscheiden. Dieser bestimmt wie sich die Klasse verhalten soll. Zur Verfügung stehen drei verschiedene Modi.

    typedef enum {
       GKSessionModeServer,
       GKSessionModeClient,
       GKSessionModePeer,
    } GKSessionMode;

Die Werte GKSessionModeClient und GKSessionModeServer stehen für eine Client Server Verbindung. Eine Client Server Verbindung unterhält nur Verbidungen zwischen den Clients und dem Server.

Im Gegensatz dazu steht die Peer-to-Peer Verbindung GKSessionModePeer, bei welcher alle beteiligten Endgeräte miteinander kommunizieren.

Da iPlanningPoker in einem Client-Server Modus funktioniert, wurde entschieden, die Klasse GKSession in den Modi "GKSessionModeServer" und "GKSessionModeClient" zu instanzieren. Intern in der GKSession, welche für einen Entwickler nicht sichtbar ist, wird immer noch ein Peer-to-Peer Netzwerk verwendet.
Die iOS API's arbeiten stark nach dem Delegation Pattern. Das Protokoll GKSessionDelegate wird implementiert, um auf Events reagieren zu können. Typische Events sind:

• Veränderungen an den verbundenen Clients z.B. wenn ein iPhone die Verbindung unterbricht
• Verbindungsaufbau mit einem Server
• Allfällige Kommunikationsfehler

Typische Methoden

Der Abschnitt behandelt die wichtigsten Methoden der GameKit API, welche in diesem Projekt verwendet worden sind. Um eine vollständige Übersicht zu erhalten, empfiehlt sich die Dokumentation von Apple.

Client

Diese Instanzmethode wird verwendet um den Client zu instanzieren. Die sessionID wird als Konstante verwendet, damit alle Clients mit dem gleichen Server kommunizieren können. Der displayName ist der Gerätename und der sessionMode erhält den Wert des Enums "GKSessionModeClient".

- (id)initWithSessionID:(NSString *)sessionID displayName:(NSString *)name
sessionMode:(GKSessionMode)mode

Mit dieser Methode wird eine Verbindung zum Server aufgebaut. Dabei ist die peerId eine eindeutige UUID, welche den Server identifiziert. Das Timeout wird mittels einer Konstante gesteuert.

- (void)connectToPeer:(NSString *)peerID withTimeout:(NSTimeInterval)timeout

Um Daten an den Server senden zu können, in diesem Fall den Kartenwert, werden diese in einer speziellen Klasse aufbereitet. Das Kapitel Netzwerkverkehr behandelt dieses Thema im Detail.
Das peers Array enthalten nur einen Eintrag, die UUID des Servers. Weiter kann entschieden werden, in welchem Modus die Daten geschickt werden sollen. Wir verwenden den Wert GKSendDataReliable des Enums. Diese Einstellung gewährleistet, dass mehrmals versucht wird die Daten zu schicken und nicht sofort nach dem ersten Fehlversuch die Übertragung abbricht.

- (BOOL)sendData:(NSData *)data toPeers:(NSArray *)peers
withDataMode:(GKSendDataMode)mode error:(NSError **)error

Server

Um einen Server zu instanzieren muss der Enumwert von sessionMode auf "GKSessionModeServer" gesetzt werden. Dies ist der wichtigste Unterschied zum Client.

- (id)initWithSessionID:(NSString *)sessionID displayName:(NSString *)name
sessionMode:(GKSessionMode)mode

Um Daten an alle Clients zu senden, wird eine unterschiedliche Methode verwendet. Diese Methode erlaubt es, Daten an alle verbundenen Clients zu senden.

- (BOOL)sendDataToAllPeers:(NSData *)data withDataMode:(GKSendDataMode)mode
error:(NSError **)error

Netzwerkverkehr

Die Übertragung der Daten findet mit bereitgestellten APIs von GameKit statt. Die Struktur der zu übertragenden Daten kann frei gewählt werden, auf welche nun eingegangen wird.

Die Kommunikation zwischen den verschiedenen iPhones und dem iPad ist wohl definiert. Die Daten werden in sogenannten Paketen zwischen dem Server und den Clients ausgetauscht. Diese Pakete haben einen klar strukturierten Header, auf welchen nun näher eingegangen wird.

Paket Struktur

Ein typischer Header in der App besteht aus 10 Bytes, gefolgt von dem Payload, den eigentlichen Daten.

• Die ersten 4 Bytes identifizieren ein Paket eindeutig für die App. Nur Pakete mit diesem Header werden von der App verarbeiten. Dazu wird die Abkürzung iPPr verwendet. Dies steht für den Hexadezimalenwert von

          
  0x69505072
          

• Die nächsten 4 Bytes werden für die Nummerierung der Pakete verwendet. Nummeriert werden die Pakete, um sicherzustellen, dass sie in der richtigen Reihenfolge verarbeitet werden.
• Die letzten 2 Bytes stehen für den Pakettyp. Je nach Typ reagiert die App unterschiedlich auf die gesendeten Daten. Die Typen werden in einem Enum gehalten.

          
  typedef enum {
      DataPacketTypeSignInRequest = 0x01,
      DataPacketTypeSignInResponse = 0x02,
      DataPacketTypeServerReady = 0x03,
      DataPacketTypeServerQuit = 0x04,
      DataPacketTypeUserQuit = 0x05
  } DataPacketType;
          

• Der Payloadbereich beinhaltet die eigentlichen Daten. Meldet sich z.B. ein neues iPhone bei einem iPad an, wäre im Payload der Name des iPhones zu finden.

Beispiel Paket

Nehmen wir das Beispiel einer SignIn-Response. Da es das erste Packet ist, wird die Nummer 1 vergeben. Dies entspricht dem Wert 0x0001. Es handelt sich um einen SignIn-Response, daher wird der Packettyp auf 0x02 gesetzt. Folgendes Bild zeigt das komplette Packet, welches versendet wird.

Umsetzung der iOS App

Entwicklungsumgebung

Xcode

Xcode ist die von Apple angebotene IDE zur Entwicklung von iOS und Mac Applikationen. Xcode bietet Möglichkeiten, die entwickelte App auf einem Simulator wie auch auf einem realen iOS Gerät zu testen. Als VCS unterstützt Xcode Git und SVN. In diesem Projekt wird Git verwendet
(Schritt 1).

GitHub

Der Source-Code wird auf GitHub in einem öffentlichen Repository gehalten. Jenkins wird informiert, sobald ein neuer Change gepusht worden ist (Schritt 2).

Jenkins CI

Jenkins wird verwendet, um die App kontinuierlich zu bauen. Wurde ein Change auf Github veröffentlicht, wird ein Jenkins Job durchloffen. Der Job besteht aus zwei Teilen. Zuerst werden die Unittests angestossen. Sind alle Unittests erfolgreich ausgeführt worden, wird das Artefakt gebildet. Das Artefakt ist ein IPA File, welches sich auf iOS Geräten installieren lässt
(Schritt 3).

Sequenzdiagramm / Zustandsmaschine

Nachfolgend wird ein typischer Ablauf innerhalb der App durch ein Sequenzdiagramm dargestellt. Die App wurde mit Hilfe einer Zustandsmaschine entwickelt. Entsprechend wurden im Sequenzdiagramm die verschiedenen Zustände erwähnt.

Die App enthält zwei verschiedene Typen von Zustandsmaschinen. Für den ersten Teil der App, den eigentlichen Verbindungsaufbau, wird eine Ereignisgetriebene-Zustandsmaschine verwendet. Im zweiten Teil, der Kommunikation zwischen den Clients und dem Server, wird eine klassische Zustandsmaschine verwendet.

Die einzelnen Schritte der App werden nachfolgend erläutert und die verschiedenen Zustände detailliert erklärt.

Verbindungsaufbau

Öffnet man die App auf dem iPhone, wird dem User folgender Screen präsentiert. Die App befindet sich zu diesem Zeitpunkt im Zustand ClientStateIdle.

Die iPad App verhält sich sehr ähnlich. Dem User wird ebenfalls ein Startscreen präsentiert. Die App auf dem iPad befindet sich im Zustand ServerStateIdle.

Im nächsten Schritt möchte sich der User zu einem neuen Planning Poker hinzufügen. Dabei hat er die Möglichkeit, den Namen seines iPhones zu bestimmen. Standardmässig wird der Gerätename verwendet.

Ist der User mit dem Namen zufrieden, versucht sich die App mit einem iPad zu verbinden. Zu diesem Zeitpunkt befindet sich die App im Zustand ClientStateLookingForServers.

Der Scrum Master startet ein neues Planning Poker auf dem iPad. Dabei wird ihm eine (leere) Tabelle präsentiert. Das iPad befindet sich nun im Verbindungsmodus und ist für die iPhones sichtbar. Alle iPhones, welche sich erfolgreich mit dem iPad verbunden haben, werden in dieser Tabelle dargestellt. Die App befindet sich im Status ServerStateAcceptingConnections.

Das iPhone erhält ein Ereignis, welches ihm mitteilt, dass ein iPad gefunden worden ist. Das iPhone stellt nun eine Verbindung her. Die App befindet sich im Zustand ClientStateConnecting.
Wurde eine erfolgreiche Verbindung mit dem iPad hergestellt, erhält das iPhone wiederum ein Ereignis, welches die Verbindung zum iPad bestätigt. Dies führt zum Zustand ClientStateConnected. Nun wird auf ein SignIn-Request gewartet. Die App befindet sich im Zustand PlanningPokerCardsWaitingForSignIn.

Planning Poker starten

Haben sich alle Teilnehmer mit dem iPad verbunden, initiiert der Scrum Master das eigentliche Planning Poker. Das iPad ist ab diesem Zeitpunkt nicht mehr auffindbar und der Zustand wird auf ServerStateStopAcceptingNewConnections gesetzt.
Jedem verbundenen iPhone wird ein SignIn-Request geschickt. Zu diesem Zeitpunkt befindet sich die App im Zustand PlanningPokerDeckWaitingForSignIn. Haben alle iPhones mit einer SignIn-Response geantwortet, wird ein Ready-Kommando geschickt und folgendes UI angezeigt. Die App befindet sich nun im Zustand PlanningPokerDeckWaitingForCardValues. Das iPad ist nun bereit für ein Planning Poker.

Wie bereits erwähnt, erhält das iPhone ein SignIn-Request vom iPad. Das iPhone antwortet mit einer SignIn-Response und geht in den Zustand PlanningPokerCardsWaitingForReady über. Danach wird vom iPad das erwähnte Ready-Kommando gesendet. Dies führt zum Zustand PlanningPokerCardsChooseCardValue und folgendes UI erscheint auf dem iPhone.

Karte auswählen

Nun können die Teilnehmer eine Karte auf dem iPhone wählen. Der Wert der Karte wird auf das iPad übertragen. Sollte sich ein Teilnehmer doch noch für eine andere Karte entscheiden, kann er dies tun, solange noch nicht alle anderen Teilnehmer eine Karte ausgewählt haben. Dies ist der Grund, wieso die App in diesem Schritt im Status PlanningPokerCardsChooseCardValue verbleibt.

Haben sich alle Teilnehmer für eine Karte entschieden, geht die App in den Zustand PlanningPokerDeckShowCardValues über und die Karten der einzelnen Teilnehmer werden auf dem iPad angezeigt. Den iPhones wird ebenfalls mitgeteilt, dass nun die Karten dargestellt werden.

Sobald die Karten auf dem iPad dargestellt werden, wird dies dem iPhone mitgeteilt. Das UI wird deaktiviert und eine Kartenauswahl ist für den Moment nicht mehr möglich. Die App befindet sich im Zustand PlanningPokerCardsWaitingForNextRound.

Neue Runde starten

Soll eine neue Runde gestartet werden, schickt das iPad den iPhones ein entsprechendes Kommando. Die Kartenwerte auf dem iPad verschwinden und das UI auf dem iPhone wird wieder aktiviert. Das iPhone befindet sich wieder im Zustand PlanningPokerDeckWaitingForCardValues und die iPhones im Zustand PlanningPokerCardsChooseCardValue. Es kann eine neue Runde gespielt werden.

Fazit

Es war spannend eine so komplexe iOS App zu entwickeln. Was mich erfreut, ist die Tatsache, dass alle definierten Ziele erreichten wurden:

• Definition der Anforderungen der zu entwickelnden iOS App
• Analyse der GameKit API
• Definition des Netzwerkverkehrs
• Umsetzung einer universellen iOS App

Das Requirements Engineering konnte optimal und zielführend durchgeführt werden. Es war hilfreich, dass ich bereits die Vorlesung von Herrn Bachmann besucht habe, welche sich exakt dieser Theamtik widmete.

Es gab im Internet leider nicht viele hilfreiche Quellen, dafür war aber die Dokumentation von Apple ausgezeichnet. Spannend war auch, dass Apple mit iOS7 genau die von mir verwendetet API aus GameKit herausgelöst hat. Dies ist eine logische Evolution dieser API. Ich kann mir vorstellen, dass solche Apps in Zukunft immer beliebter werden und noch in einer grösseren Anzahl erscheinen werden.

Das Schreiben eines eigenen Netzwerkprotokolls war eine Herausforderung. Wir haben bisher im Studium wenig auf diesem Level gemacht, aber ich denke, die erarbeitete Lösung hat die Anforderungen erfüllt. Ausserden ist das Protokoll erweiterbar, was ein persönliches Ziel bei der Definition des Protokolls war. Es war äusserst spannend wieder mal mit Bits, Bytes und Hex zu arbeiten.

Dass eine voll funktionsumfassende App entstanden ist, erfüllt mich mit Stolz. Mit iOS7 wurd ein flaches UI eingeführt, was mir mit meinen bescheidenen Designfähigkeiten in die Hände spielte. Das simple UI passt ausserordentlich gut zu iOS7 und vereinfacht das Arbeiten mit der App.< br/> Der nächste Schritt nach der Abgabe der Semsterarbeit, wird die Veröffentlichung der App im AppStore sein. Ich erhoffe mir, dass auch weitere Teams von dieser App profitieren können. In unserem Team wird die App bereits eingesetzt und hat uns das Leben vereinfacht.

Insgesamt kann ich sagen, dass die Semesterarbeit viel Spass und Schweiss bereitet hat. Der Aufwand der Dokumentation darf nie unterschätzt werden, was ich bei meiner nächsten Arbeit besser berücksichtigen werde. Ein gutes Projektmanagment fördert den reibungslosen Ablauf der Arbeit, dies werde ich weiterhin so machen werden.

Viel Spass beim nächsten Planning Poker!

Anhang

Glossar

API: Application Programming Interface, bezeichnet die Schnittstelle, über welche der Client Daten vom Server abruft.

Client: Ein Anwendungsprogramm, welches auf dem Gerät des Benutzers läuft und meist mit einem Server kommuniziert.

Server: Eine Komponente, welche verschiedene Requests von Clients erhält und auf diese reagieren kann.

UI: Kurzschreibweise für User Interface. Das Aussehen einer Applikation.

Enum: Ein Aufzählungstyp mit einer endlichen Menge an konstanten Typen.

UUID: Steht für Universally Unique Identifier. In diesem Projekt eine eindeutige Nummer für einen Client.

Byte: Ein Byte besteht aus 8 Bit. Es ist eine Masseinheit in der Informatik

Hexadezimalsystem: Dieses Stellwertsystem wird zur Basis 16 dargestellt. Im Unteschied zum Dezimalsystem, welches zur Basis 10 dargestellt wird.

SVN: Ist eine Software zur Versionsverwaltung von Dateien von Apache.

Git: Ebenfalls eine Software zur Versionsverwaltung. Wurde ursprünglich für Linux entwickelt. Der grösste Unteschied zu SVN ist die dezentrale Verwaltung des Sourcecodes.

Artefakt: Ist das Ergebnis eines Buildprozesses. Es ist die fertige Software, welche auf Endgärten installiert werden kann.

Literaturverzeichnis

Stephen G. Kochan: Programming in Objective-C 2.0(5. Auflage), 2013, 978-0321887283, Amsterdam: Addison-Wesley Longman

Ken Schwaber, Mike Beedle: Agile Software Development with Scrum, 2001, 978-0130676344

Quellenverzeichnis

Abbildungsverzeichnis