Master Thesis
-
Upload
christopher-ezell -
Category
Documents
-
view
553 -
download
15
Transcript of Master Thesis
Masterarbeit
Analyse, Konzeption und Implementierung
einer mobilen Kollaborationsplattform für
verteilte agile Software-Projekte
Zur Erlangung des akademischen Grades eines
Master of Science
- Media Processing and Interactive Services-
Fakultät Informatik
Referent: Prof. Dr. Kurt Englmeier
Koreferent: Prof. Dr. Regina Polster
eingereicht von:
Christopher Ezell
Matr.-Nr. 260352
Kreuzstraße 07
98590 Schwallungen
Rene Kassel
Matr.-Nr. 260208
Mühlweg 22
98597 Fambach
Schmalkalden, den 12.09.2012
Abstract
Globalisierung und der Trend zur Dezentralisierung tragen immer mehr zu Neuerungen bei der
Kommunikation und dem Austausch von Information zwischen Menschen bei. Diese Verände-
rungen machen auch bei der Arbeitswelt keinen Halt und bringen ständig neue Innovationen
hervor. Immer mehr Firmen nutzen diese neuen Techniken und verschaffen sich, zum Bei-
spiel mit Hilfe von Outsourcing und verteilten Arbeitsmöglichkeiten durch gut vernetzte
Standorte über das Internet, Vorteile. Dies bringt aber auch gravierende Veränderungen für die
Angestellten dieser Firmen mit sich. Teams werden zunehmend internationaler ausgestellt und
müssen immer größere und komplexere Aufgaben lösen. Dazu wird vermehrt Fachpersonal
benötigt, welches immer schwerer an einem zentralen Arbeitsplatz vereint werden kann. Die
Folgen daraus sind dezentralere Strukturen innerhalb der Teams. Diese verteilten Teams wer-
den auch virtuelle Teams genannt. Sie arbeiten also nur noch virtuell an einer gemeinsamen
Aufgabe und können sowohl räumlich als auch zeitlich voneinander getrennt sein.
Doch Menschen sind nicht für solch eine Art der Arbeit geschaffen. Immer wieder entstehen
Konflikte in verteilten Gruppen durch interkulturelle Unterschiede und soziale Missverständ-
nisse. Es gibt in den letzten Jahren einige Ansätze zum Lösen dieser Probleme. Doch viele
zielen nur auf das sehr formelle kommunizieren von Informationen ab und vernachlässigen die
soziale Komponente zu stark.
Besser wäre hier ein sozialer Ansatz, der allen Mitgliedern im Team ein Gefühl der Zusam-
mengehörigkeit verleiht. Dies muss unabhängig von Ort und Zeit des jeweiligen Mitglieds
gewährleistet sein. Ansätze, wie bei dem Projekt Flurfunk, zeigen auf, wo die Entwicklung
hinführen kann. Bei Flurfunk werden formelle Informationen aus dem Projektalltag1 und per-
sönliche2 Informationen von den Teammitgliedern3 kombiniert, wodurch ein zentraler Fluss an
Informationen bereit gestellt wird. Dieser kann den Mitgliedern helfen, die anderen Mitglieder
standortübergreifend kennenzulernen und so mehr Zusammenhalt im Team schaffen.
Die zweite Komponente, die in dieser Arbeit betrachtet werden soll, sind die Smartphones.
Smartphones sind aus dem Alltag nicht mehr wegzudenken und zu einem zentralen Kommu-
nikationsmittel geworden. Durch diesen großen Hype rund um das Thema Smartphones ist es
ersichtlich geworden, welches Potential in dieser Technik steckt.
1Das können Informationen über Neuigkeiten im Wiki und den Buildstatus sein.2soziale3Dies kann in Form von kurzen Nachrichten, die jeder absenden kann, erfolgen
II
Es stellt sich also die Frage, ob durch den geschickten Einsatz von Smartphones und einer
intelligenten Kommunikationsstrategie verteilte Menschen näher zusammen gebracht werden
können und sie dadurch auf einer sozialen Ebene wieder besser miteinander kommunizieren
können.
Diese Arbeit versucht einen Ansatz zu finden, wie heutige Kommunikationskanäle so verbun-
den werden können, dass diese Lücke in der sozialen Kommunikation überwunden werden
kann und so das Teamklima, das gegenseitige Vertrauen und andere wichtige soziale Aspek-
te wieder mehr in den Vordergrund der Kommunikation geraten. Hierzu werden Kommuni-
kationskanäle innerhalb der Arbeit ausgewertet und anhand von Kriterien kategorisiert. Das
Ergebnis ist ein Prototyp einer Kommunikations- und Kollaborationsplattform, der versucht,
diese Aspekte in einem virtuellen Team zu verbessern. Ein großer Fokus liegt dabei auf mobilen
Endgeräten, wie Smartphones. Sie sind immer parat und besitzen so das größte Potential, die
zentrale Schnittstelle zur digitalen Außenwelt zu werden. Auch durch die Sensoren in diesen
Geräten, wie GPS und Kompass, können völlig neue Dienste erschaffen und vorhandene Da-
ten viel effektiver genutzt werden. Es werden hierzu eine Menge aktueller Studien und Bücher
zurate gezogen, um dem Leser aktuelle Informationen über diese Thematik zu vermitteln.
III
Danksagungen
An dieser Stelle möchten wir uns herzlichst bei unseren Eltern sowie bei Franziska Sachs und
Sylvana Hofmeister bedanken. Sie haben uns während des Studiums und bei der Erstellung
dieser Masterarbeit stets unterstützt und auch in schlechten Momenten den Rücken gestärkt.
Ebenso einen großen Dank an euch für die Geduld und das Durchhaltevermögen in einigen
Phasen.
Ein herzlichster Dank gilt Herrn Prof. Dr. Kurt Englmeier und Frau Prof. Dr. Regina Polster,
die uns die Bearbeitung dieses Themas ermöglichten und uns stets bei Problemen oder Fragen
zur Stelle waren.
Ein großes Lob gebührt Beatrice Florat und Franziska Sachs. Diese haben mit ihrem Ehrgeiz
und Engagement die Arbeit durch Korrekturlesungen stark unterstützt.
Ebenso sind an dieser Stelle unsere Freunde zu nennen, die einem stets zur Seite standen, auch
wenn es mal schlechte Zeiten gab - danke dafür.
Zum Schluss geben wir unseren Dank auch an all diese, welche hier nicht namentlich genannt
wurden und sich damit angesprochen fühlen.
IV
Inhaltsverzeichnis
Inhaltsverzeichnis
Abkürzungsverzeichnis X
Abbildungsverzeichnis XII
Listings XV
1. Einleitung (Autoren: Christopher Ezell und Rene Kassel) 11.1. Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Thesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Voraussetzungen zum Verständnis der Arbeit . . . . . . . . . . . . . . . . . . 4
2. Kommunikation und Interaktion in (verteilten) Teams (Autoren: Christopher Ezell und Rene Kassel) 52.1. Begriffsdefinition virtuelle Teams(Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . 5
2.2. Kommunikation und Probleme in virtuellen Teams (Autor: Christopher Ezell) . . . . . . . 6
2.3. Lösungsansätze (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Das Potential von mobilen Endgeräten in verteilten Teams (Autor: Rene Kassel) . . . . . 11
2.5. Arten von Informationen in Teams (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . 11
2.6. Arten von potentiellen Kommunikationskanälen (Autor: Christopher Ezell) . . . . . . . . . 12
2.7. Gamification (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell) . . . . . . 15
2.8.1. Einordnung und Eigenschaften der Tools (Autor: Rene Kassel) . . . . . . . . . . 16
2.8.2. Collaboration Pad (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . 17
2.8.3. Mobile Instant Messaging (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . 21
2.8.4. Screen Sharing (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8.5. (Remote) Pair Programming (Autor: Rene Kassel) . . . . . . . . . . . . . . . . 26
2.8.6. Blog (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8.7. Microblogging (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8.8. Social Bookmarking (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . 33
2.8.9. Standortbezogene soziale Netzwerke (Autor: Christopher Ezell) . . . . . . . . . . 36
2.8.10. Shared Storage (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . 38
2.8.11. Shared Notes (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . 40
2.8.12. Wiki (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.8.13. Weitere Tools und eigene Ideen (Autor: Rene Kassel) . . . . . . . . . . . . . . . 45
V
Inhaltsverzeichnis
2.8.14. Überblick über die Projektplattform (Autor: Rene Kassel) . . . . . . . . . . . . 45
2.9. Zusammenfassung (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . 46
3. Grundlagen (Autoren: Christopher Ezell und Rene Kassel) 483.1. Agile Softwareentwicklung (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . 48
3.1.1. Agiles Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.1.2. User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1.3. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.4. Verteilte agile Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2. Technologien (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.1. Extensible Markup Language . . . . . . . . . . . . . . . . . . . . . . 53
3.2.2. Java Architecture for XML Binding . . . . . . . . . . . . . . . . . . . 54
3.2.3. Really Simple Syndication . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.4. JavaScript Object Notation . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.5. Representational State Transfer . . . . . . . . . . . . . . . . . . . . . 56
3.2.6. Extensible Messaging and Presence Protocol . . . . . . . . . . . . . . 59
3.2.7. Java Persistence API . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2.8. Webdav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.9. QR-Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3. iOS und Objective-C (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . 61
3.3.1. Die Methodensignatur in Objective-C . . . . . . . . . . . . . . . . . . 61
3.3.2. Besondere Schreibweise spezieller Datentypen . . . . . . . . . . . . . 64
3.3.3. Delegates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3.4. Key-Value-Observing . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.3.5. Struktur und Lebenszyklus einer iOS-Applikation . . . . . . . . . . . . 67
3.3.6. Notification Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.4. Testen von Software (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5. Build-Management (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6. Zusammenfassung (Autoren: Rene Kassel und Christopher Ezell) . . . . . . . . . . . . . . . . . . . 74
4. User Stories (Autoren: Christopher Ezell und Rene Kassel) 754.1. Beschreibung der Applikation (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . 75
4.2. User Story 1: Einloggen (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . 76
4.3. User Story 2: Ausloggen (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . 76
4.4. User Story 3: News einsehen (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . 77
4.5. User Story 4: News einstellen (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . 78
4.6. User Story 5: Build-Status einsehen (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . 79
4.7. User Story 6: Position der anderen User einsehen (Autor: Christopher Ezell) . . . . . . . . 79
4.8. User Story 7: Eigene Position erneuern (Autor: Christopher Ezell) . . . . . . . . . . . . . . 80
4.9. User Story 8: Tasks einsehen (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . 81
4.10. User Story 9: Task erzeugen (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . 81
VI
Inhaltsverzeichnis
4.11. User Story 10: Task konfigurieren (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . 82
4.12. User Story 11: Arbeitszeit einsehen (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . 83
4.13. User Story 12: Arbeitszeit erfassen (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . 84
4.14. User Story 13: Userliste abrufen (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . 84
4.15. User Story 14: Userinfo einsehen (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . 85
4.16. User Story 15: Chat-Kontaktliste abrufen (Autor: Christopher Ezell) . . . . . . . . . . . . 85
4.17. User Story 16: Chat-Gespräch mit einem bestimmten Nutzer(Autor: Christopher Ezell) . . 86
4.18. User Story 17: Task über QR-Code scannen (Autor: Rene Kassel) . . . . . . . . . . . . . 87
4.19. User Story 18: Benachrichtung per e-Mail (Autor: Christopher Ezell) . . . . . . . . . . . . 87
4.20. User Story 19: Offline Benachrichtung (Autor: Christopher Ezell) . . . . . . . . . . . . . . 88
4.21. User Story 20: Verteilte Notizen einsehen (Autor: Christopher Ezell) . . . . . . . . . . . . 89
4.22. User Story 21: Verteilte Notizen bearbeiten (Autor: Christopher Ezell) . . . . . . . . . . . 90
4.23. User Story 22: Shared Bookmarks einsehen (Autor: Rene Kassel) . . . . . . . . . . . . . 90
4.24. User Story 23: verteiltes Planningpoker durchführen (Autor: Christopher Ezell) . . . . . . 91
4.25. Zusammenfassung (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5. Konzeption (Autoren: Christopher Ezell und Rene Kassel) 935.1. Allgemeine Hinweise und Datenschutz (Autoren: Christopher Ezell und Rene Kassel) . . . . . . . . 95
5.2. Konzeption der internen Dienste (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . 96
5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel) . . . . . . . . . . . . . . 97
5.3.1. Social Bookmarking (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . 98
5.3.2. Shared Notes (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . 99
5.3.3. Shared Storage (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.4. Apple Push Service (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . 101
5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell) . . . . . . . . . . . . . 102
5.4.1. View (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4.2. Controller (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.4.3. Model (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell) . . . . . . . . . . . . . . . . . . . 110
5.5.1. Architektur der iPhone-App (Autor: Christopher Ezell) . . . . . . . . . . . . . . . 111
5.5.2. Datensynchronisation (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . 112
5.5.3. Die einzelnen Funktionalitäten im Überblick . . . . . . . . . . . . . . 112
5.5.3.1. Der Chat (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . 112
5.5.3.2. Tasks (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . 113
5.5.3.3. Die News (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . 114
5.5.3.4. Liste der Shared Links (Autor: Rene Kassel) . . . . . . . . . . . . . . 115
5.5.3.5. Maps (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . 116
5.5.3.6. Verteiltes Planningpoker (Autor: Christopher Ezell) . . . . . . . . . . . . 117
5.5.3.7. Liste der Notizen (Autor: Christopher Ezell) . . . . . . . . . . . . . . . 119
5.5.3.8. QR-Code-Scanner (Autor: Rene Kassel) . . . . . . . . . . . . . . . . 119
5.5.3.9. Buildstatus (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . 120
VII
Inhaltsverzeichnis
5.5.3.10. Das Punktesystem (Autor: Rene Kassel) . . . . . . . . . . . . . . . . 121
5.5.3.11. Liste aller registrierten User (Autor: Rene Kassel) . . . . . . . . . . . 122
5.6. Konzeption Build und Teststrategien (Autor: Christopher Ezell) . . . . . . . . . . . . . . . 123
5.7. Zusammenfassung (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6. Implementierung (Autoren: Christopher Ezell und Rene Kassel) 1256.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel) . . . . . . . 125
6.1.1. Datenbankanbindung (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . 125
6.1.2. Push-Konnektor (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . 127
6.1.3. QR-Code-Konnektor (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . 128
6.1.4. Mail-Konnektor (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . 129
6.1.5. XMPP-Konnektor (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . 130
6.1.6. Einbindung der Services in die Webapplikation (Autoren: Christopher Ezell) . . . . 130
6.1.7. XML-Binding (XMLService) (Autor: Rene Kassel) . . . . . . . . . . . . . . . . 132
6.1.8. REST-API (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . 134
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) . . . . . . . . . . . 135
6.2.1. REST-Anbindung (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . 136
6.2.2. XMPP-Integration (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . 138
6.2.3. XML/JSON-Parser (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . 139
6.2.4. Diigo-Integration (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . 141
6.2.5. Simplenote-Integration (Shared Notes) (Autor: Christopher Ezell) . . . . . . . . . 141
6.2.6. Konfigurations-Management (Autor: Rene Kassel) . . . . . . . . . . . . . . . . 142
6.2.7. Ortungsdienste (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . 144
6.2.8. ’Ziehen zum neu laden’ (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . 145
6.2.9. QR-Code-Parser (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . 147
6.2.10. Push-Notifications (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . 150
6.3. Implementierung Build und Continious Integration (Autor: Christopher Ezell) . . . . . . . 151
6.4. Zusammenfassung (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . . 155
7. Anwendungsbeispiel (Autoren: Christopher Ezell und Rene Kassel) 1567.1. Einloggen eines Users (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . 156
7.2. Die Verwaltung von Tasks (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . 157
7.3. Ein Chat mit der iPhone App (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . 158
7.4. Anzeigen des Build-Status (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . 160
7.5. Die Verwendung der Lokationsdienste (Autor: Christopher Ezell) . . . . . . . . . . . . . . 162
7.6. Die Verwendung der News (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . 164
7.7. Einsicht in Userdaten (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . 164
7.8. QR-Code Scan (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.9. Benachrichtigungssystem der App (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . 168
7.10. Notizenverwaltung (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . 168
7.11. Einsicht in Bookmarks (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . 169
VIII
Inhaltsverzeichnis
7.12. Ausloggen des Users (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . 172
7.13. Zusammenfassung (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . 172
8. Fazit (Autoren: Christopher Ezell und Rene Kassel) 1738.1. Abschlussbetrachtungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.2. Resumee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.3. Erweiterungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Quellenverzeichnis XVIII
A. Anhang Abbildungen XXVIII
B. Anhang Quellcode XLI
Eidesstattliche Erklärung XLIII
IX
Abkürzungsverzeichnis
Abkürzungsverzeichnis
AIM . . . . . . . . . . . . . . . . AOL Instant Messenger
Amazon S3 . . . . . . . . . . Amazon Simple Storage Service
API . . . . . . . . . . . . . . . . . Application Programming Interface
ARPN . . . . . . . . . . . . . . . Apple Remote Push Notification
BSD . . . . . . . . . . . . . . . . Berkeley Software Distribution
CD . . . . . . . . . . . . . . . . . Compact Disc
CI . . . . . . . . . . . . . . . . . . Continuous Integration
CMS . . . . . . . . . . . . . . . . Content Management System
COS . . . . . . . . . . . . . . . . Conditions of statisfaction
CRUD . . . . . . . . . . . . . . Create Update Delete
DNS . . . . . . . . . . . . . . . . Domain Name System
DOM . . . . . . . . . . . . . . . Document Object Model
ECMA . . . . . . . . . . . . . . European Computer Manufacturers Association
ESB . . . . . . . . . . . . . . . . Enterprise Service Bus
GPRS . . . . . . . . . . . . . . . General Packet Radio Service
GPS . . . . . . . . . . . . . . . . Global Positioning System
HTTP . . . . . . . . . . . . . . . Hypertext Transfer Protocol
IM . . . . . . . . . . . . . . . . . . Instant Messaging
IM . . . . . . . . . . . . . . . . . . Instant Messenger
INVEST . . . . . . . . . . . . . Independent, Negotiable, Valuable, Estimable, Small, Testable
IT . . . . . . . . . . . . . . . . . . Informationstechnik
JavaEE . . . . . . . . . . . . . . Java Platform Enterprise Edition
JAX-RS . . . . . . . . . . . . . Java API for RESTful Web Services
JAXB . . . . . . . . . . . . . . . Java Architecture for XML Binding
JCR . . . . . . . . . . . . . . . . . Java Content Repository
JPA . . . . . . . . . . . . . . . . . Java Persistence API
JSON . . . . . . . . . . . . . . . JavaScript Object Notation
KTI . . . . . . . . . . . . . . . . . Kommission für Technologie und Innovation
KVO . . . . . . . . . . . . . . . . Key Value Observing
X
Abkürzungsverzeichnis
LBS . . . . . . . . . . . . . . . . Location Based Services
MVC . . . . . . . . . . . . . . . Model-View-Controller
NIB . . . . . . . . . . . . . . . . . Binäre Interface Builder Datei
OSCAR . . . . . . . . . . . . . Open System for Communication in Realtime
PO . . . . . . . . . . . . . . . . . . Product Owner
POJO . . . . . . . . . . . . . . . Plain old Java Object
POM . . . . . . . . . . . . . . . . Project Object Model
POSIX . . . . . . . . . . . . . . Portable Operating System Interface
QR-Code . . . . . . . . . . . . Quick Response Code
REST . . . . . . . . . . . . . . . Representational State Transfer
RFC . . . . . . . . . . . . . . . . Request for Comments
RMI . . . . . . . . . . . . . . . . Remote Method Invocation
RSS . . . . . . . . . . . . . . . . . Really Simple Syndication
SAX . . . . . . . . . . . . . . . . Simple API for XML
SGML . . . . . . . . . . . . . . Standard Generalized Markup Language
Simple . . . . . . . . . . . . . . SIP for Instant Messaging and Presence Leveraging Extensions
SIP . . . . . . . . . . . . . . . . . Session Initiation Protocol
SLF4J . . . . . . . . . . . . . . . Simple Logging Facade for Java
SM . . . . . . . . . . . . . . . . . Scrum Master
SOAP . . . . . . . . . . . . . . . Simple Object Access Protocol
SSH . . . . . . . . . . . . . . . . Secure Shell
TDD . . . . . . . . . . . . . . . . Test Driven Developement
URI . . . . . . . . . . . . . . . . . Uniform Resource Identifier
URL . . . . . . . . . . . . . . . . Uniform Resource Locator
W3C . . . . . . . . . . . . . . . . World Wide Web Consortium
Webdav . . . . . . . . . . . . . Web-based Distributed Authoring and Versioning
XEP . . . . . . . . . . . . . . . . XMPP Extension Protocol
XIB . . . . . . . . . . . . . . . . . XML Interface Builder Datei
XML . . . . . . . . . . . . . . . . Extensible Markup Language
XMPP . . . . . . . . . . . . . . Extensible Messaging and Presence Protocol
XP . . . . . . . . . . . . . . . . . . Extreme Programming
XI
Abbildungsverzeichnis
Abbildungsverzeichnis
2.1. Konflikte in virtuellen Teams (Quelle: [Koe09], Seite 6.) . . . . . . . . . . . . 7
2.2. Arten von Informationen in Teams (Quelle: Eigene Darstellung) . . . . . . . . 12
2.3. Arten von Kommunikationsmittel in Teams (Quelle: Eigene Darstellung) . . . . 13
2.4. Die Säulen der Teamarbeit (Quelle: Eigene Darstellung) . . . . . . . . . . . . 15
2.5. Eigenschaftsmatrix des Collaboration Pads (Quelle: Eigene Darstellung) . . . . 20
2.6. Eigenschaftsmatrix des Mobile Instant Messagings (Quelle: Eigene Darstellung) 23
2.7. Eigenschaftsmatrix des Screen Sharings (Quelle: Eigene Darstellung) . . . . . 26
2.8. Eigenschaftmatrix des Remote Pair Programmings (Quelle: Eigene Darstellung) 29
2.9. Eigenschaftsmatrix des Blogs (Quelle: Eigene Darstellung) . . . . . . . . . . . 30
2.10. Eigenschaftsmatrix des Microbloggings (Quelle: Eigene Darstellung) . . . . . 33
2.11. Eigenschaftsmatrix des Social Bookmarkings (Quelle: Eigene Darstellung) . . 35
2.12. Eigenschaftsmatrix der standortbezogenen sozialen Netzwerke (Quelle: Eigene
Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.13. Eigenschaftsmatrix des Shared Storages (Quelle: Eigene Darstellung) . . . . . 40
2.14. Eigenschaftsmatrix der Shared Notes (Quelle: Eigene Darstellung) . . . . . . . 42
2.15. Eigenschaftsmatrix des Wikis (Quelle: Eigene Darstellung) . . . . . . . . . . . 44
3.1. Scrum auf einem Blick (Quelle: [HW11], Seite 7) . . . . . . . . . . . . . . . . 51
3.2. QR-Code Beispiel (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . . 60
3.3. QR-Code Vergleich (Quelle: [Win11]) . . . . . . . . . . . . . . . . . . . . . . 61
3.4. Schaubild Objective-C Delegation (Quelle: [App12d]) . . . . . . . . . . . . . 65
3.5. Überprüfung der Anforderungen mittels Tests (Quelle: [HW11], Seite 5.) . . . 69
3.6. Das V-Modell (Quelle: [Hab12], Seite 24) . . . . . . . . . . . . . . . . . . . . 70
5.1. Aufbau der Projektplattform (ideal) (Quelle: Eigene Darstellung) . . . . . . . . 94
5.2. Übersicht der verschiedenen Dienste in der Plattform (Quelle: Eigene Darstel-
lung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.3. Aufbau der Projektplattform (Quelle: Eigene Darstellung) . . . . . . . . . . . . 96
5.4. Genereller Ablauf einer Apple Push-Nachricht (Quelle: [App12b]) . . . . . . . 101
5.5. Aufbau der REST-Services (Quelle: Eigene Darstellung) . . . . . . . . . . . . 103
5.6. Die Verbindung von den Services zu der View (Quelle: Eigene Darstellung) . . 106
5.7. Verwendung des XML-Services im View (Quelle: Eigene Darstellung) . . . . . 107
5.8. Die Verbindung von Services zu den Konnektoren (Quelle: Eigene Darstellung) 109
5.9. Übersicht der iOS-Applikations Architektur (Quelle: Eigene Darstellung) . . . 111
XII
Abbildungsverzeichnis
5.10. Mind-Map der InstantScrum iPhone-Applikation (Quelle: Eigene Darstellung) . 113
5.11. Mockup der Chatliste (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . 114
5.12. Mockup eines Chats mit einem anderem User (Quelle: Eigene Darstellung) . . 115
5.13. Mockup der Taskliste (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . 116
5.14. Mockup der Detailansicht eines Tasks (Quelle: Eigene Darstellung) . . . . . . 117
5.15. Mockup der Newsliste (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . 118
5.16. Mockup der Mapfunktionalität (Quelle: Eigene Darstellung) . . . . . . . . . . 119
5.17. Mockup der PlanningpokerView (Quelle: Eigene Darstellung) . . . . . . . . . 120
5.18. Mockup des Buildstatus (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . 121
5.19. Mockup der Userliste (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . 122
6.1. Klassendiagramm EntityManager (Quelle: Eigene Darstellung) . . . . . . . . . 127
6.2. Tokengenerierung (Quelle: [App12b]) . . . . . . . . . . . . . . . . . . . . . . 128
6.3. Klassendiagramm RestServices (Quelle: Eigene Darstellung) . . . . . . . . . . 135
6.4. Der grafische Editor des Settings-Bundle (Quelle: Eigene Darstellung) . . . . . 143
6.5. Die iPhone Oberfläche der Einstellungen (Quelle: Eigene Darstellung) . . . . . 144
6.6. Funktion ’Ziehen zum neu laden’ (Quelle: Eigene Darstellung) . . . . . . . . . 146
6.7. Funktion ’Ziehen zum neu laden’ Teil 2 (Quelle: Eigene Darstellung) . . . . . 146
6.8. Klassendiagramm ZXing (Quelle: Eigene Darstellung) . . . . . . . . . . . . . 147
6.9. Klassendiagramm ZXing-Extention (Quelle: Eigene Darstellung) . . . . . . . . 148
7.1. Screenshot des Loginscreens (Quelle: Eigene Darstellung) . . . . . . . . . . . 156
7.2. Screenshot des Logos (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . 157
7.3. Screenshot von der Anzeige der Taskliste (Quelle: Eigene Darstellung) . . . . . 157
7.4. Screenshot der Detailansicht eines Tasks (Quelle: Eigene Darstellung) . . . . . 158
7.5. Screenshot der Ansicht zur Arbeitszeiterfassung (Quelle: Eigene Darstellung) . 159
7.6. Screenshot zum Anlegen eines Tasks (Quelle: Eigene Darstellung) . . . . . . . 159
7.7. Screenshot von Chatlistenansicht (Quelle: Eigene Darstellung) . . . . . . . . . 160
7.8. Screenshot von einem Chat mit einem User (Quelle: Eigene Darstellung) . . . . 161
7.9. Screenshot der Buildeinsicht (Quelle: Eigene Darstellung) . . . . . . . . . . . 161
7.10. Screenshot über die Detailansicht eines Builds (Quelle: Eigene Darstellung) . . 162
7.11. Screenshot der Mapfunktionalität (Quelle: Eigene Darstellung) . . . . . . . . . 163
7.12. Screenshot der Updatefunktion der Map (Quelle: Eigene Darstellung) . . . . . 163
7.13. Screenshot des Newsstreams (Quelle: Eigene Darstellung) . . . . . . . . . . . 164
7.14. Screenshot vom Erzeugen einer Neuigkeit (Quelle: Eigene Darstellung) . . . . 165
7.15. Screenshot des Newsstreams mit der neuen Nachricht (Quelle: Eigene Darstel-
lung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
7.16. Screenshot Userliste (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . 166
7.17. Screenshot Userdetail (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . 167
7.18. Screenshot des QR-Code Scans (Quelle: Eigene Darstellung) . . . . . . . . . . 167
7.19. Screenshot einer Push-Benachrichtigung von der instantScrum-App (Quelle:
Eigene Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
XIII
Abbildungsverzeichnis
7.20. Screenshot der Notizverwaltungsübersicht (Quelle: Eigene Darstellung) . . . . 169
7.21. Screenshot über die Änderung einer Notiz (Quelle: Eigene Darstellung) . . . . 170
7.22. Screenshot Bookmarks sortiert nach Tags (Quelle: Eigene Darstellung) . . . . . 170
7.23. Screenshot der Bookmarks innerhalb eines Tags (Quelle: Eigene Darstellung) . 171
7.24. Screenshot der der Webansicht innerhalb eines Bookmarks (Quelle: Eigene
Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
7.25. Screenshot der Useransicht mit Logoutbutton (Quelle: Eigene Darstellung) . . . 172
A.1. Aztec-Code (Quelle: [Azt97a]) . . . . . . . . . . . . . . . . . . . . . . . . . . XXVIII
A.2. Überprüfung der Anforderungen mittels Tests (Quelle: [HW11], Seite 5) . . . . XXVIII
A.3. Openfire Webadmin (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . XXIX
A.4. Architektur JAXB 2.0 (Quelle: [MS07], Seite 6.) . . . . . . . . . . . . . . . . XXX
A.5. JAXB 2.0 Schema-Compiler (Quelle: [MS07], Seite 8.) . . . . . . . . . . . . . XXX
A.6. Übersicht Server-Applikation (Quelle: Eigene Darstellung) . . . . . . . . . . . XXXI
A.7. Übersicht Startseite Etherpad (Quelle: Eigene Darstellung) . . . . . . . . . . . XXXI
A.8. JAXB 2.0 Schema-Generator (Quelle: [MS07], Seite 10.) . . . . . . . . . . . . XXXII
A.9. Etherpad Weboberfläche (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . XXXII
A.10.Lebenszyklus einer iOS Applikation (Quelle: [Kol10], Seite 41) . . . . . . . . XXXIII
A.11.Deployment Server (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . XXXIV
A.12.Deployment iPhone (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . XXXV
A.13.Use Cases (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . . . . . . XXXVI
A.14.Klassendiagramm Services (Quelle: Eigene Darstellung) . . . . . . . . . . . . XXXVII
A.15.Diigo Toolbar (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . . . . XXXVIII
A.16.Jenkins Weboberfläche (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . XXXIX
A.17.Wiki Weboberfläche (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . XL
XIV
Listings
Listings
3.1. Beispiel für XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2. Beispiel für JSON (Quelle: [Gro06]) . . . . . . . . . . . . . . . . . . . . . . . 56
3.3. Beispiel für URLs bei REST . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4. Beispiel für eine Nachricht in XMPP (Quelle: [SAST09]) . . . . . . . . . . . . 59
3.5. Objective-C Methodensignatur . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6. Beispiel einer Objective-C -Methode . . . . . . . . . . . . . . . . . . . . . . . 62
3.7. Aufruf einer Methode in Objective-C . . . . . . . . . . . . . . . . . . . . . . . 62
3.8. Beispiel für ein interface in Objective-C . . . . . . . . . . . . . . . . . . . 63
3.9. Die Implementierung der Klasse MyClass . . . . . . . . . . . . . . . . . . . 63
3.10. Beispiel für ein protocol in Objective-C . . . . . . . . . . . . . . . . . . . 64
3.11. Erzeugung eines Strings in Objective-C . . . . . . . . . . . . . . . . . . . . . 65
3.12. Erzeugung eines Strings in Objective-C mittels Kurzschreibweise . . . . . . . 65
3.13. Delegate-Methode der Klasse UIApplication . . . . . . . . . . . . . . . . 65
3.14. Registrierung eines Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.15. Aufruf der Methode bei Änderung eines Wertes . . . . . . . . . . . . . . . . . 66
3.16. Das protocol UIApplicationDelegate . . . . . . . . . . . . . . . . 67
3.17. Registrierung für eine local notification . . . . . . . . . . . . . . . . . . . . . 68
3.18. Die Signatur der Methode zum annehmen der Notification . . . . . . . . . . . 68
3.19. das Tag dependencies der pom.xml . . . . . . . . . . . . . . . . . . . . 72
5.1. Beispiel eines API-Aufrufes der Diigo-API (Lesen eines Bookmarks) . . . . . 98
5.2. Beispiel einer Diigo-Antwort in Form von JSON . . . . . . . . . . . . . . . . 98
5.3. Beispiel eines POST-Aufrufes zum Erstellen eines neuen Links . . . . . . . . . 99
5.4. Beispiel eines GET-Aufrufes zum Abrufen von Links von allen Notizen . . . . 99
5.5. Beispiel einer Diigo-Antwort einer Notiz in Form von JSON . . . . . . . . . . 100
5.6. JSON-Repräsentation einer ARPN (Quelle:[App12b]) . . . . . . . . . . . . . . 101
5.7. Die XML-Darstellung eines SrumUser-Objektes . . . . . . . . . . . . . . . . 104
5.8. Delegate-Methoden des Protokolls RKRequestDelegate . . . . . . . . . . 104
6.1. Auschnitt aus der Eclipse-Link Configuration . . . . . . . . . . . . . . . . . . 126
6.2. Beispiel eines Datenbankzugriffs mit JPA . . . . . . . . . . . . . . . . . . . . 126
6.3. Push to Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.4. QR-Code generieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.5. Senden einer E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
XV
Listings
6.6. Senden und Empfangen einer XMPP-Nachricht . . . . . . . . . . . . . . . . . 130
6.7. Beispiel einer Jersey-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.8. Einbindung des SetupListener in web.xml . . . . . . . . . . . . . . . . . 131
6.9. Initialisierung des Contextservice . . . . . . . . . . . . . . . . . . . . . 132
6.10. AbstractService in ServletContext . . . . . . . . . . . . . . . . . . 132
6.11. Service aufrufen mit dem ContextService . . . . . . . . . . . . . . . . . 132
6.12. Beispiel Klasse mit JAXB-Annotationen . . . . . . . . . . . . . . . . . . . . . 133
6.13. Beispiel XML aus einem Objekt . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.14. Unmarshalling von XML mit JAXB . . . . . . . . . . . . . . . . . . . . . . . 133
6.15. Beispiel einer Jersey web.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.16. Beispiel einer Jersey Service Klasse . . . . . . . . . . . . . . . . . . . . . . . 135
6.17. Initialisierung von einem RKClient . . . . . . . . . . . . . . . . . . . . . . 136
6.18. Delegate-Methoden des Protokolls RKRequestDelegate . . . . . . . . . . 136
6.19. Parsen einer Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.20. Auszug aus der RKClient.h . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.21. Delegate-Methoden des Protokolls RKRequestSerializable . . . . . . . 138
6.22. Senden von Inhalt mit XMPP auf iOS . . . . . . . . . . . . . . . . . . . . . . 138
6.23. Senden einer Nachricht mit XMPP auf iOS . . . . . . . . . . . . . . . . . . . 138
6.24. Die Methoden der XMPP-Fassade . . . . . . . . . . . . . . . . . . . . . . . . 139
6.25. Online und Offline gehen mit dem XMPP-Konnektor . . . . . . . . . . . . . . 139
6.26. Einfaches XML-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.27. Simples Parserbeispiel von XML mit XMLTreeNode . . . . . . . . . . . . . 140
6.28. JSON parsen unter iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.29. Posten einer Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.30. Registrierung des Oberservers und Implementierung der Methode . . . . . . . 142
6.31. Registrierung des Oberservers Beispiel . . . . . . . . . . . . . . . . . . . . . . 142
6.32. Implementierung der Observer-Methode . . . . . . . . . . . . . . . . . . . . . 142
6.33. Plist-XML-Datei mit den darin enthaltenen Einstellungen . . . . . . . . . . . . 143
6.34. Herausholen von Settings aus dem Settings-Bundle . . . . . . . . . . . . . . . 143
6.35. Auszug aus dem CLLocationManagerDelegate-Protokoll . . . . . . . . 144
6.36. Verwendung eines CLLocationManagers . . . . . . . . . . . . . . . . . . 145
6.37. Die Methoden von EGORefreshTableHeaderView . . . . . . . . . . . . . . . . 146
6.38. Die Methode parsedResultForString . . . . . . . . . . . . . . . . . . 148
6.39. Die Methode initWithString der Klasse TaskParsedResult . . . . . 149
6.40. Posten einer Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.41. Parsen eines Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.42. Anfrage auf ein Push Notification Token . . . . . . . . . . . . . . . . . . . . . 150
6.43. Erhalten eines Push Notification Tokens . . . . . . . . . . . . . . . . . . . . . 150
6.44. Empfangen eines Push Notification Errors auf der Clientseite . . . . . . . . . . 150
6.45. Empfangen einer Push Notification auf Clientseite . . . . . . . . . . . . . . . . 151
6.46. Module des Parent-Projekts in der pom.xml . . . . . . . . . . . . . . . . . . 151
XVI
Listings
6.47. Pom.xml des Projektes instantscrum-web . . . . . . . . . . . . . . . . . . . . 153
6.48. Pom.xml des Projektes instantscrum-web (resources) . . . . . . . . . . . . . 153
6.49. Pom.xml des Projektes instantscrum-web (Cargo Plugin) . . . . . . . . . . . 154
B.1. pom.xml des Projektes instantscrum-web (komplett) . . . . . . . . . . . . . . XLI
XVII
1. Einleitung (Autoren: Christopher Ezell und Rene Kassel)
1. Einleitung (Autoren: Christopher Ezell und Rene Kassel)
In den letzten Jahrzehnten ist der Bedarf an Computertechnik in Form von neuer Software
für zunehmend komplexer werdende Aufgaben und Anforderungen immer stärker geworden.
Softwaresysteme werden nahezu in allen Lebensbereichen eingesetzt. Sie unterstützen dort die
Arbeit ungemein und sind kaum noch weg zu denken. Jedoch müssen diese Systeme mit der
Zeit gehen und sind ständig steigenden Anforderungen ausgesetzt. Die komplexer werdenden
Anwendungen brauchen immer mehr und immer qualifiziertere Programmierer, Softwarear-
chitekten und technische Leiter, welche an einem einzigen Projekt arbeiten. Das aufkommende
Problem hierbei ist aber, dass das benötigte Know-how, welches zum Entwickeln und weiter-
führen für solche Softwaresysteme benötigt wird, nicht mehr nur an einem Standort konzen-
triert werden kann. Zum Teil müssen Teammitglieder von vielen verschiedenen Standorten,
Städten und sogar Ländern rekrutiert werden, um genug Wissen und Arbeitskraft verfügbar zu
machen.
Meistens ist es jedoch nicht so, dass das nötige Kapital eingesetzt wird, um die Teams an einem
Standort zu versammeln. Vielmehr wird davon ausgegangen, dass diese auch verteilt arbeiten
können.
Jedoch existiert in verteilten Teams ein wesentlich höherer Bedarf an Abstimmung und Kom-
munikation, um dieselben Aufgaben zu lösen, wie bei nicht verteilten Teams. Mit Teammitglie-
dern zu arbeiten, welche nicht am gleichen Standort tätig sind, ist unweit schwieriger als die
Arbeit mit einem Teammitglied am gleichen Standort. Wichtig sind aber auch Faktoren, wie
Probleme der einzelnen Mitarbeiter oder Informationen bezüglich der Erreichbarkeit. Auch an
dieser Stelle sollte eine bessere Transparenz vorliegen. Kurz gesagt ist es das Vertrauen, was
geschaffen werden muss. Nicht vorhandenes Vertrauen zwischen den Teammitgliedern kann
oft zu Konflikten innerhalb des Teams führen, wenn Probleme auftreten oder wichtige Ent-
scheidungen getroffen werden müssen. Bei solchen Konstellationen sollte also ein besonderer
Fokus darauf liegen, wie durch eine bessere Kommunikation solche Probleme behoben werden
können.
Ein Vorbild kann hier zum Beispiel die Veränderung der Kommunikation im Alltag sein. Die
zunehmende Akzeptanz des Internets, eine höhere Verfügbarkeit von breitbandigen, mobilen
Datenverbindungen und die immer günstigeren mobilen Endgeräte haben nachhaltig unsere
Kommunikation und Interaktion verändert. Es sind neue Dienste wie Microblogging und Lo-
cation Based Services entstanden. Immer mehr Leute teilen zunehmend mehr Informationen
durch solche Dienste mit anderen Menschen. Durch die hohe Verfügbarkeit von Internet ist es
1
1.1. Ziel der Arbeit
möglich geworden, immer und überall erreichbar zu sein und instantan auf Nachrichten reagie-
ren zu können. Diese Mentalität dringt durch jüngere Mitarbeiter immer mehr in den Projekten
ein und die Toleranz für solche Dienste am Arbeitsplatz steigt. Warum also nicht diese neuen
Möglichkeiten auch in Projekten nutzen, um den Fluss von Informationen zu verbessern. Auch
die teilweise sehr gut ausgeprägte Erfahrung mit solchen Kommunikationsmitteln erleichtert
den Einsatz im Firmenumfeld.
Neben dem Projektwandel, der Kommunikation und dem Aufkommen von sozialen Netzen
existiert noch der immer schneller wachsende Markt der Smartphones. Durch dieses Auf-
kommen ist es möglich, eine weitaus höhere Informationsflut zu verarbeiten. Auch die zwi-
schenmenschliche Kommunikation ist durch die bessere Erreichbarkeit und Aktualität stärker
ausgeprägt und einfacher möglich. Denn durch Smartphones ist es gegeben, instantan kom-
munizieren zu können. Damit ist auch ein Wandel von einer Push-Kommunikation zu einer
Pull-Kommunikation verbunden. Wo früher beide Gesprächspartner direkt miteinander ver-
bunden waren, können diese heute indirekt miteinander kommunizieren4. Das hat zur Folge,
dass Kommunikationspartner sich selbstbestimmter Informationen einholen können.
Aus den genannten Tatsachen heraus erschloss sich das Thema der Masterarbeit, eine mo-
bile Kollaborationsplattform für verteilte, agile Softwareprojekte zu erschaffen. Diese soll die
Trends berücksichtigen und mit einer guten Kombination moderner Kommunikationsmittel und
agiler Grundgedanken, die Zusammenarbeit und soziale Interaktion in Projekten erhöhen und
verbessern und zum Erfolg von verteilten, agilen Softwareprojekten beitragen.
1.1. Ziel der Arbeit
Ziel der Arbeit ist es zu analysieren, wie sich Entwickler in agilen Softwareprojekten durch die
Verwendung moderner Kommunikationsmittel besser verständigen können, um die Kommu-
nikation im Projekt zu fördern. Es soll gezeigt werden, wie durch eine sinnvolle Verknüpfung
von vorhandenen, modernen Kommunikationskanälen mit mobilen und nicht mobilen Endge-
räten eine ganzheitliche und leichtgewichtige Kommunikation innerhalb einer Projektgruppe
über Standortgrenzen hinweg ermöglicht werden kann. Dafür wird zunächst eine Analyse von
Kommunikationskanälen, welche sich in den letzten Jahren im Alltag etabliert haben, durchge-
führt. Das Ergebnis der Analyse soll eine Liste von Kommunikationsmitteln sein, welche eine
Empfehlung von den Autoren für eine ganzheitliche Kommunikation darstellt.
Nach der Analyse wird beispielhaft eine Kommunikationsplattform konzipiert, implementiert
und anhand eines Anwendungsbeispiels verifiziert. Die Plattform soll sämtliche Bereiche der
Kommunikation abdecken und vereinen, damit eine Verbesserung dieser gewährleistet wird.
Die Funktionalitäten (Features) der umgesetzten Projektplattform ergeben sich aus der entstan-
denen Liste der Analyse. Um die Analyse zu verbessern, wird ein Selbsttest der Kommunika-
tionsmittel durch die Autoren während der Umsetzung der Plattform getätigt.
4über neue Dienste, wie Twitter und Facebook
2
1.2. Thesen
1.2. Thesen
Neben dem genannten Ziel wird sich mit weiteren Fragestellungen befasst. Dazu werden fol-
gende Thesen aufgestellt und im Rahmen dieser Arbeit diskutiert.
• Es ergeben sich in verteilten Projekten eine Menge an Problemen bei der Nutzung von
klassischen Kommunikationsmitteln, da sie zu wenig Kontext-Informationen über die
andere Person vermitteln.
• Die Dienste von sozialen Netzwerken bieten neue Möglichkeiten, innerhalb eines Pro-
jektes zu interagieren.
• Die Nutzung solcher Dienste innerhalb eines Projektes kann die Zusammenarbeit ver-
bessern.
• Durch die Nutzung von Smartphones für die Kommunikation und Kollaboration mittels
des Einsatzes verschiedener Dienste, wie z.B. ortsbasierte Dienste, kann eine höhere
Transparenz in virtuellen Teams erreicht werden, was wiederum ein höheres Vertrauen
im Team zur Folge hat.
• Durch die Verwendung von sogenannter Social Software kann ein höheres Vertrauen und
ein höherer Zusammenhalt im Team geschaffen werden.
1.3. Aufbau der Arbeit
Das Kapitel 1 leitet das Thema und Ziel dieser Masterarbeit ein und beinhaltet allgemeine Fak-
ten zur Arbeit. Im weiteren Verlauf wird in Kapitel 2 über die Domäne agiler Projekte und
deren Fachwörter berichtet. Zudem analysiert dieses Kapitel grundlegende Veränderungen in
der Kommunikation innerhalb von Projekten. Es wird darauf eingegangen, was Entwickler be-
nötigen, um auch in verteilten Teams ein besseres Gruppenzugehörigkeitsgefühl zu bekommen
und was in einem verteilten Team kommunikationsrelevant ist. Kapitel 2.8 analysiert verschie-
dene Kommunikationsmittel auf ihren Nutzen für den Einsatz in einem verteilten, agilen Soft-
wareprojekt. Sie werden anhand von ausgewählten Eigenschaften auf ihre Verwendungsart und
ihrem Verwendungszweck hin geprüft. Auf Grundlage der erzielten Ergebnisse wird am Ende
des Kapitels ein Vorschlag für eine Kommunikationsplattform geschaffen. Dieser Vorschlag
dient als Grundlage für den weiteren Verlauf dieser Arbeit und als konzeptionelle Basis für die
Implementierung einer Beispielplattform. Kapitel 3 bietet einen grundlegenden Überblick über
technische Grundlagen und behandelt dabei Themen aus Technologien, Build-Managament
und der Code-Qualität. Diese Grundlagen bilden die Basis zum Verständnis der Arbeit.
Die Plattform wird im Kapitel 4 durch Userstories beschrieben. Kapitel 5 und Kapitel 6 do-
kumentieren die praktische Umsetzung der Plattform. Das Kapitel 7 skizziert am Beispiel der
3
1.4. Voraussetzungen zum Verständnis der Arbeit
Umsetzung der vorliegenden Masterarbeit den praktischen Alltag und die tägliche Kommuni-
kation innerhalb eines Projektes mit der in der Masterarbeit umgesetzten Plattform.
Diese Masterarbeit wurde von zwei Autoren bearbeitet und gemeinsam erarbeitet. Daher muss
innerhalb der Arbeit immer transparent sein, welcher Autor welches Gebiet bearbeitet hat. Es
wurden an den Kapiteln Markierungen in der Überschrift vorgenommen, von welchem Autor
der Inhalt stammt. Kapitel, die gemeinsam bearbeitet wurden, tragen beide Autorennamen.
1.4. Voraussetzungen zum Verständnis der Arbeit
Es wird vom Leser ein grundlegendes Verständnis der informationstechnischen Grundlagen
vorausgesetzt (begonnenes Studium der Informatik). Des Weiteren setzt die Arbeit Basiswissen
im Bereich der Softwareentwicklung bzw. der agilen Softwareentwicklung voraus. Alle für die
Arbeit relevanten Themen werden kurz angerissen und erläutert.
4
2. Kommunikation und Interaktion in (verteilten) Teams (Autoren: Christopher Ezell und Rene Kassel)
2. Kommunikation und Interaktion in(verteilten) Teams (Autoren: Christopher Ezell und Rene Kassel)
Wie in der Einleitung beschrieben, ist es eine anerkannte Tatsache, dass in der IT-Branche im-
mer mehr Projekte nicht mehr nur an einem Standort entwickelt werden, sondern auf mehrere
Standorte verteilt sind (vgl. [Eck09], S.1). Eine Studie, die sich mit dieser Thematik befasst
findet auch, dass der Trend zu einem verteiltem Team immer mehr zunimmt5. Dies kann so-
wohl Vorteile als auch Nachteile für das Projekt bedeuten. Welche hier überwiegen, hängt stark
von der Arbeitsweise und der Art der Kommunikation innerhalb des Teams ab.
In diesem Kapitel wird ermittelt, welche Arten von Informationen und Kommunikationswegen
in Projekten existieren und wie diese genutzt werden. Es wird darauf eingegangen, welche
Probleme sich ergeben, wenn ein Team über mehre Standorte oder sogar Firmen hinweg verteilt
ist und nicht die richtigen Kommunikationskanäle zur Verfügung stehen, um diese Lücke zu
überwinden.
Zunächst sollen die für diese Arbeit relevanten Informationen und die zur Verfügung stehenden
Arten von Kommunikationsmitteln innerhalb eines Projektes betrachtet werden. Diese werden
dann im Kapitel 2.8 genauer analysiert.
2.1. Begriffsdefinition virtuelle Teams(Autor: Christopher Ezell)
Zum besseren Verständnis wird dem Leser eine Begriffsdefinition von „verteilten Teams“ (vgl.
[Eck09]) gegeben. In dieser Arbeit werden die Begriffe „verteilte Teams“ und „virtuelle Teams“
(vgl. [Koe09]) synonym verwendet.
Definition Virtuelles Team
„A virtual team, like every team, is a group of people who interact through interdepen-
dent tasks guided by common purpose. Unlike conventional teams, a virtual team works
across space, time, and organizational boundaries with links strengthened by webs of
communication technologies“([HJK+00], Seite 21)
Entsprechend [HJK+00] ist ein virtuelles Team ein Team, welches über zeitliche und örtliche
Grenzen hinweg an einer Aufgabe arbeitet und mittels Kommunikationstechnologien mitein-
ander kommuniziert.
5Laut einer Studie der Computerwoche aus dem Jahr 2011 [Com12c]
5
2.2. Kommunikation und Probleme in virtuellen Teams (Autor: Christopher Ezell)
2.2. Kommunikation und Probleme in virtuellen Teams (Autor: Christopher Ezell)
Kommunikation ist ein weites Feld und kann aus den verschiedensten Blickwinkeln betrach-
tet werden. In diesem Kapitel soll nun die Kommunikation in virtuellen Teams analysiert und
strukturiert werden. Es wird ein Überblick über die Arten und Einflussfaktoren auf die Kommu-
nikation gegeben. Zudem wird auf Probleme hingewiesen, die sich aus der Kommunikation in
einem Team ergeben, welches auf verschiedene Standorte verteilt ist. Hierzu werden verschie-
dene Studien als Grundlage verwendet. Es soll anhand dieser Studien auch ermittelt werden,
welches die entscheidenden Faktoren für eine gute Kommunikation in einem Projekt sind.
Die erste Studie „Führung und Kommunikation in virtuellen Teams der IT-Branche“ der Kom-
mission für Technologie und Innovation (KTI) ist aus dem Jahr 2003. Sie behandelt das Arbei-
ten in virtuellen Teams und wie solche Teams effektiv geleitet werden können. Innerhalb dieser
Studie werden verschiedene Faktoren definiert, die in einem virtuellen Team die Kommunika-
tion beeinflussen (vgl. [Thi05]). Diese sind das Teamklima, das Vertrauen und Commitment(vgl. [Thi05]). Alle drei werden als sehr wichtig und essenziell für ein funktionierendes Team
erachtet, als Kerneigenschaften definiert. In [Eck09] wird ebenso das Vertrauen als ein wesent-
licher Punkt in solchen Teams herausgestellt. Die Studie stellt unter anderem fest, dass viele
Probleme in virtuellen Teams nicht aufgrund von technischen Problemen bei der Kommunika-
tion auftreten, sondern wegen zwischenmenschlichen (sozialen) Missverständnissen verursacht
werden. Es kann also festgehalten werden, dass sowohl die soziale Bindung (hier Commitment
genannt) als auch das Vertrauen als wichtige Faktoren angenommen werden können.
Die Small Group Research hat ebenfalls eine Studie6 zu virtuellen Teams durchgeführt (vgl.
[MZ09], Seite 586). 71 Studierende zwei kanadischer Universitäten nahmen daran teil. Zu
Beginn wurden die Teilnehmer in virtuelle Teams eingeteilt7. Die Aufgabe war im Team eine
wissenschaftliche Arbeit innerhalb eines Zeitraumes über drei Monate anzufertigen. Jedes Mit-
glied eines Teams soll die gleiche Note bekommen, die zudem zu 20-30 Prozent in die Endnote
einfließt. Zur Kommunikation untereinander standen ihnen E-Mail und Chaträume zur Verfü-
gung. Nach der Teameinteilung wurden die Studierenden mit einem ersten Fragebogen auf
ihr Vertrauen zu den Teammitgliedern befragt. Den Mitgliedern der eigenen Universität wur-
de mehr Vertrauen entgegen gebracht als der anderen Universität. Eine Hypothese der Small
Group Research war, dass das Vertrauen zu den entfernten Teammitgliedern im Laufe der Be-
arbeitung steigt. Das Gegenteil war der Fall: Das Vertrauen zu den Mitgliedern der eigenen
Universität stieg noch weiter an und das zu den anderen sank noch mehr (vgl. [MZ09]). Die-
se Studie zeigt, dass Methoden gefunden werden sollten, die diesem Trend entgegen wirken.
Das Vertrauen zu den entfernten Teammitgliedern sollte mit solchen Methoden gesteigert wer-
den.
In dem Artikel Virtuelle Teams: Die Rolle der Führung (vgl. [Koe09]) von Petra Köppel wer-
den Arten von Problemen und Konfliktgründen in virtuellen Teams erläutert (siehe hierzu Ab-
6Further Understanding of Trust and Performance in Virtual Teams7In einem virtuellen Team sind drei Studierende der einen Universität und drei der anderen Universität.
6
2.2. Kommunikation und Probleme in virtuellen Teams (Autor: Christopher Ezell)
bildung 2.1). Die Abbildung zeigt die Arten und Einflussfaktoren von virtuellen Konflikten.
Diese sind Mangel an Vertrauen, Kommunikationsmangel und Führungsprobleme. Eine
Abschwächung der genannten Problemfaktoren kann zu einer Verbesserung der Leistung und
Zufriedenheit im Projekt führen. Ein Kommunikationsmangel kann unter Umständen dazu
beitragen, dass ein Teammitglied nicht ausreichend informiert ist. Das wiederum kann zu einer
schlechteren Arbeitsleistung dieses Teammitgliedes führen. Köppel weist deutlich daraufhin,
dass die Zufriedenheit eines Mitglieds durch soziale Kontextinformationen beeinflusst werden
kann.
Abbildung 2.1.: Konflikte in virtuellen Teams (Quelle: [Koe09], Seite 6.)
Bei der Interaktion zwischen verschiedenen Menschen sind jedoch diese Kontextinformation
sehr wichtig für jeden Einzelnen. Diese sind subtile Informationen über verschiedene Sach-
verhalte, welche nur schwer über klassische, verteilte Kommunikationskanäle8 transportierbar
sind (vgl. [SK86], 1986). Hingegen werden solche Informationen in einem nicht virtuellen
Team mühelos und kontinuierlich miteinander ausgetauscht. Ein Fehlen dieser Informationen
über z.B. die Arbeitsweise der anderen Teammitglieder oder den Arbeitsumständen kann zu
fehlendem Vertrauen und Verständnis führen. Das bietet ein höheres Potential an Konflikten.
Die Studie von Sproull sagt, dass viele Informationen nur über sogenannte paraverbale9 und
nonverbale Kanäle kommuniziert werden (vgl. [Kö06], Seite 5). Er stellt in seiner Studie die
zwei größten Faktoren, die zu Konflikten in verteilten Teams beitragen, vor. Dies ist zum Einen
8Beispiele dafür stellen E-mail oder Telefon dar.9z.B. Tonfall
7
2.2. Kommunikation und Probleme in virtuellen Teams (Autor: Christopher Ezell)
die Reduzierung von Hintergrundinformationen im sozialen Kontext (vgl. [SK86]). Zum An-
deren ist es das fehlende Vertrauen (vgl. [MZ09]). Es gilt also in einem solchen Team diesen
Kontext in der Kommunikation so weit es geht zu vermitteln oder durch andere Medien trans-
parenter, erfahrbar zu gestalten.
Der Autor Erik Senst listet in einem Lernprogramm für Virtuelle Teamarbeit (vgl. [Sen01])
bei Mangel an sozialer Präsenz die folgenden sozialpsychologischen Effekte auf, die beobach-
tet werden konnten. Sie können in verschiedenen Situationen sowohl positiv als auch negativ
sein.
• Anonymität und depersonalisierte Wahrnehmung der Kommunikationsteilnehmer
• Gleichmäßige Beteiligung, da Statusunterschiede als geringer empfunden werden
• Hohe Aufgabenorientierung und geringe Beachtung sozialer Aspekte
• Negative und ungezwungene Sprache, aufgrund geringer Bindung an soziale Normen
• Schwierigkeiten einen Konsens in der Gruppe zu erreichen
Es muss also immer der richtige Mix an Kommunikationsmitteln genutzt werden, um den Grad
an sozialer Interaktion und standortübergreifender sozialer Präsenz zu regulieren.
Ein besonderes Problem stellen reisende Teammitglieder dar. Sie haben meistens eine über-
mäßig lange Arbeitswoche und sind in stressigen Zeiten „immer“ für die Arbeit unterwegs.
Dies muss gegenüber den anderen Teammitgliedern kommuniziert und transparent dargestellt
werden. Ansonsten kann dies bei den lokalen Mitgliedern eines Standortes zu Missverständnis-
sen und Unverständnis für die geringe Arbeitsleistung dieses Mitarbeiters führen. Sie können
zwar in Meetings erwähnen, wie oft sie unterwegs sind und was sie getan haben, jedoch ist
dies immer erst im Nachhinein möglich. Viele Meetings sind so gehalten, dass nur wenig Zeit
für soziale Interaktionen zur Verfügung steht. Es müsste hier eine Echtzeitlösung existieren,
die solche Arten von Aktionen transparent gegenüber anderen Mitgliedern aller Standorte ge-
staltet. Dies trifft auch für Mitglieder zu, die mit einem erschwerten Arbeitsumfeld oder einer
doppelten Projektlast arbeiten müssen. Auch hier kann es schnell zu einem Unverständnis im
Team kommen, warum dieser Mitarbeiter viel weniger Arbeit leistet als die Anderen.
Besonders im Umfeld der agilen Softwarentwicklung stellt der Trend der immer größeren Ver-
teilung der Teams ein großes Problem dar. Laut [Eck09] und vielen anderen Autoren funk-
tionieren agile Teams am besten, wenn alle Teammitglieder an einem Standort vereint sind.
Die Interaktions- und Kommunikationsmuster in solchen Teams sind darauf getrimmt, alle
Teammitglieder direkt und ohne technische Hilfsmittel zu erreichen. Hier besteht jedoch ein
Konflikt. Mit der zunehmenden Virtualität der Teams ergeben sich systemimmanente Konflikt-
herde (vgl. [Koe09]) in der Kommunikation innerhalb solcher Teams. Das spezielle Problem
von agilen Teams besteht in der Tatsache, dass die Intensität der Interaktion/Kommunikation
innerhalb des Teams weitaus höher ist als in nicht-agilen Projekten (vgl. [Bec99] und [Eck09]).
Für diese Anforderung muss in einem virtuellem Team eine Lösung gefunden werden. Hieraus
8
2.3. Lösungsansätze (Autor: Christopher Ezell)
bekommen auch Werte wie das Vertrauen und das Teamklima automatisch einen höheren
Stellenwert.
Wie noch in Kapitel 2.8 näher erläutert wird, wollen Menschen sehr viele Informationen mit ih-
ren Mitmenschen teilen, um sie so besser kennenzulernen. Einige dieser Informationen könnten
auch in Projekten von Relevanz sein. Gerade in verteilten Projekten, in denen sich die Projekt-
mitarbeiter oft nur selten sehen, ist es ein sehr wichtiger Faktor, die persönliche Bindung zu
den Projektmitarbeitern aufrecht zu erhalten. Viele der genannten Informationen aus Abbil-
dung 2.2 (Ort, Befinden und weitere) können auch für Projektteams wichtig sein und sollten
mit Kommunikationsmitteln vermittelbar sein.
Abschließend kann festgehalten werden, dass die sozialen Faktoren in einem virtuellen Team
nicht unterschätzt werden sollten. Im nächsten Unterkapitel werden dazu Lösungsansätze vor-
gestellt.
2.3. Lösungsansätze (Autor: Christopher Ezell)
Die in Kapitel 2.2 dargestellten Probleme in verteilten Teams werden schon seit Jahren mit
verschiedensten Ansätzen versucht zu lösen. Der Hauptangriffspunkt ist das Ermöglichen von
gemeinsamen Arbeiten an einer Information und das Bereitstellen von zentralen Informations-
systemen, zu denen alle Mitglieder Zugriff haben. Hier hat sich das Wort Groupware durch-
gesetzt.
Definition Groupware
„Ein computer-basiertes System, das eine Gruppe von Personen in ihrem Aufgabenge-
biet oder Ziel unterstützt und eine Schnittstelle für eine geteilte Arbeitsumgebung bietet.“
(vgl. [RK07], Seite 21)
Groupware bietet also einer Gruppe von Personen gemeinsamen Zugriff auf Arbeits- und Ter-
mininformationen. Beispiele für diese Informationen sind die folgenden (aus [RK07]):
• E-Mails
• gemeinsame Terminkalender
• gemeinsame Adressbücher und
• gemeinsame Todo-Listen (vgl. [RK07])
Daneben bieten heutige Groupware-Lösungen weitaus mehr Features. Ein Beispiel ist hier der
Anbieter Atlassian (zu finden unter [Gro12b]) mit den Produkten JIRA10, Confluence11 und
10ein Bugtracking-System11ein Wiki-System
9
2.3. Lösungsansätze (Autor: Christopher Ezell)
Bamboo12. Der hohe Wert an der Nutzung der ganzen Reihe an Software von Atlassian liegt
in der nahtlosen Integration von vielen Features innerhalb dieser Reihe.
Der Lösungsansatz der Groupware löst nur einen Teil der in Kapitel 2.2 beschriebenen Pro-
bleme. Die meiste Kommunikation bei Groupware ist sehr nüchtern und fokussiert auf den
Informationsgehalt für das Projekt und den Fortschritt der Aufgabe. Ein großer Teil der sozia-
len Probleme, wie dem fehlenden Kontext und der fehlenden Einschätzung der kommunizier-
ten Information, bleibt weiter über solche Systeme nur bedingt klärbar. Auch viele geforderte
Praktiken im Projektalltag, wie das kurz fassen und sachlich bleiben, fördern nicht die soziale
Interaktion. Ein Lösungsansatz wäre hier der kombinierte Einsatz von Groupware und SocialSoftware.
Definition Social Software
„Unter Social Software versteht man Anwendungen, die menschliche Interaktion unter-
stützen“ (nach [RK07], Seite 21).
Social Software bietet genau das, was Groupware (im Allgemeinen) nicht bietet, nämlich eine
Plattform zum Austausch von zwischenmenschlichen Informationen und die Kommunikation
über persönliche Dinge. Der geforderte Lösungsansatz kann also mit den geeigneten Kommu-
nikationsmitteln auf diese Anforderungen besser reagieren. Das Potential für Konflikte wird
innerhalb der Gruppe minimiert und das Projekt kann potentiell besser umgesetzt werden. Ein
Teil der Arbeit ist es, einen Prototypen zu entwickeln, der die einzelnen Faktoren einer Social
Software umsetzt.
Viele Anbieter kombinieren schon Groupware mit Social Software. dass bei vielen Anbie-
tern nicht mehr rein nach der Definition zwischen Groupware und Social Software getrennt
werden kann. Immer mehr Anbieter integrieren ’soziale’ Dienste in ihre Groupware (beispiels-
weise der Anbieter Atlassian ([Gro12b]). Atlassian ist einer der größeren und erfolgreichen
Anbieter solcher Software. Erst mit der letzten Version 4.X wurde in das bekannte Wiki Con-
fluence der Like-Button und ein RSS-Feed für Popular Content13 implementiert. Es ist es
möglich, einem User zu folgen (siehe Release Notes Confluence [Gro12c]). Da diese Version
von Confluence erst zum Ende der Masterarbeit herausgebracht wurde, findet sie sich nicht in
der Konzeption des Prototypen wieder. Solche Entwicklungen zeigen, das sich diese Art von
Features immer weiter verbreitet und immer mehr Beachtung bekommt.
In einer Studie der BITCOM mit dem Titel Social Media in deutschen Unternehmen wurde
festgestellt, dass fast die Hälfte der Unternehmen in Deutschland (47 Prozent) Social Media
nutzen (vgl. [bit12b]). Social Media wird aber nur für die externe Kommunikation und das
Marketing genutzt. Die Nutzung solcher Medien für interne Kommunikation in Firmen ist zur
Zeit noch nicht weit verbreitet, aber die Anzahl der Artikel und Bücher über dieses Thema
12ein Continous-Integration-System13Wiki-Seiten mit den meisten Likes
10
2.4. Das Potential von mobilen Endgeräten in verteilten Teams (Autor: Rene Kassel)
nimmt enorm zu. Alleine im August 2012 waren in fast jedem IT-Fachmagazin mindestens ein
Artikel über diese Themengebiete.
2.4. Das Potential von mobilen Endgeräten in verteilten Teams (Autor:Rene Kassel)
Neben der Entwicklung von Social Software ist ein weiterer Trend die Nutzung von Smart-phones und Tablets. Laut einer Studie14 der BITCOM nutzen 43 Prozent der Smartphone-
Nutzer jeden Tag das Internet. „Nur“ 42 Prozent nutzen täglich die Telefon-Funktion (vgl.
[bit12a]). Dies spiegelt einen allgemeinen Trend wieder, alles mit dem Smartphone zu erledi-
gen und weniger auf dem Desktop-PC oder mit dem Notebook. Wenn die Nutzer unterwegs
sind, bietet das Smartphone/Tablet die einzige Möglichkeit, online Dinge zu tätigen. Laut ei-
ner Umfrage von TNS Infratest (vgl. [Gro12d]) stieg allein vom Jahr 2011 zum Jahr 2012
die Zahl der Nutzer, die mittels Apps ihren mobilen Zugang zum Internet nutzen, von 19 auf
34 Prozent. Zudem wurde in der Umfrage die Nutzung von verschiedenen Onlinediensten auf
verschiedenen Endgeräten ermittelt. Dabei liegen Tablets und Smartphones ganz vorne.
Wird nun dieser Trend mit den oben genannten Kommunikationsaspekten verbunden, ergeben
sich vielfältige neue Möglichkeiten sich mit seinen Teammitgliedern in Verbindung zu setzen.
Auch auf Reisen können dadurch immmer Sachverhalte bezüglich der aktuellen Tätigkeit oder
Position kommuniziert werden. Hierdurch ist eine sehr viel höhere Transparenz und ein höheres
Commitment im Projekt potentiell möglich15.
2.5. Arten von Informationen in Teams (Autor: Christopher Ezell)
Generell existieren in einem Team unendlich viele Informationen verschiedenster Arten, wel-
che kommuniziert, gespeichert oder verarbeitet werden können. Die Abbildung 2.2 zeigt eine
Darstellung von ausgewählten Informationen, die innerhalb eines Projektteams anfallen.
Die gewählten Oberbegriffe in der Abbildung sind Informationen zur Erreichbarkeit, Status-
informationen, Arbeitsinformationen, Wissen und Echtzeitinformationen. Jedem Oberbegriff
sind verschiedene Teilinformationen zugeordnet. Diese decken sämtliche Bereiche der sozialen
Interaktionen in Projekten ab. Dargestellt sind hier die Informationen, die nach Autorenmei-
nung wichtig sind, um eine gute soziale Kommunikation zu erschaffen bzw. zu verbessern.
14„Smartphone-Funktionen: Internet wichtiger als Telefonieren“15Ob dies so ist, muss sich in weiterführenden Studien noch zeigen.
11
2.6. Arten von potentiellen Kommunikationskanälen (Autor: Christopher Ezell)
Abbildung 2.2.: Arten von Informationen in Teams (Quelle: Eigene Darstellung)
2.6. Arten von potentiellen Kommunikationskanälen (Autor: Christopher Ezell)
Im Whitepaper E-Collaboration Mehrwerte durch moderne Kommunikationsmittel schaffen
[Hor08] von Martin Hornstein et. al. findet sich die nachfolgende Aufteilung von Kommu-
nikationsmitteln. Er unterscheidet zwischen Kommunikationsmitteln der ersten, zweiten und
dritten Generation. Erstere werden Basis-Module genannt und bestehen aus:
• E-Mail,
• Kalender und
• Telefon.
Kommunikationsmittel der zweiten Generation werden in dem Paper Zusammenarbeit steht
im Mittelpunkt genannt und beinhalten:
• Instant Messaging,
• Presence Awareness (Ortsdienste),
• Dokumentenmanagement,
• Projektmanagement-Tools und
• Desktop Sharing.
Kommunikationsmittel der dritten Generation werden Social Software und Web 2.0 genannt
und bestehen aus:
• Tagging, Tag-Clouds,
12
2.6. Arten von potentiellen Kommunikationskanälen (Autor: Christopher Ezell)
• Wikis,
• Blogs,
• Social Networking,
• Social Bookmarking und
• RSS-Feeds.
Hinzu kommen einige zusätzliche Tools, die von den Autoren ausgewählt wurden. Dies sind:
• Codeverwaltung,
• Videochat,
• Audiochat,
• Collaboration Pad,
• Remote Pair Programming,
• Mircroblogging und
• Shared Storage.
Die eigens erstellte Abbildung 2.3 zeigt nochmals die Einteilung der Kommunikationsmittel
nach Arten. In Kapitel 2.8 wird näher auf ausgewählte Dienste eingegangen.
Abbildung 2.3.: Arten von Kommunikationsmittel in Teams (Quelle: Eigene Darstellung)
13
2.7. Gamification (Autor: Christopher Ezell)
2.7. Gamification (Autor: Christopher Ezell)
Die vorhergehenden Überlegungen führen zu einem zweiten Thema: der Motivation. Ein mo-
tiviertes Team, welches gerne an seinen Aufgaben arbeitet, ist in einem Projekt sehr wichtig.
Um die Motivation zu steigern gibt es einen möglichen Ansatz, welcher Gamification genannt
wird. Darunter wird im Allgemeinen der Prozess, aus einer täglichen Handlung eine spiele-
ähnliche Situation zu erzeugen, verstanden. Das bedeutet, dass Eigenschaften, die sonst nur
in Spielen vorhanden sind16, in das tägliche Leben übernommen werden. In einem Blogein-
trag von NBCNews.com vom 01. Juni 2010 beschreibt Helen Popkin (vgl. [Rad12]), wie die
Effekte der Social Games auf die reale Welt angewendet werden können. Laut dem Artikel
soll der spielerische Wettbewerb und das Punktesystem zu einem Bestandteil verschiedener
Aktivitäten werden. Dadurch soll die Durchführung dieser Aktivitäten verstärkt werden.
Definition Gamification
„It’s all part of the ’gamification’ of life, reports Advertising Age, ’where competition
and points are increasingly a part of offline activities.’ . . . Games ’keep people engaged
to keep doing things, as opposed to what goes viral quick: You click, you watch and then
never see it again.’“ [Rad10]
In der Ausgabe vom August des iX-Magazin [Ame12] wurde Gamification als ein vielverspre-
chender Ansatz zur Motivationssteigerung von Mitarbeitern dargestellt. Durch das Etablieren
von Spielemechanismen in der Software, die ein Mitarbeiter täglich bedient, soll eine Steige-
rung der Arbeitsfreude geschaffen werden. Die Studie The power of social connections der
Universität Stanford vom März 2012 zeigt die Macht von sozialen Interaktionen. Allein der
Wunsch nach Gemeinsamkeit und das Verlangen nach sozialen Interaktionen steigert unsere
Motivation (vgl. [Wal12] und vgl. [PRI11]).
Im Allgemeinen wird dieser Ansatz benutzt, um die Motivation, eine gewisse Handlung aus-
zuüben, zu erhöhen. Es gab in der letzten Zeit erste Versuche diesen Prozess auf Software-
projekte anzuwenden. Die Versuche zeigten positive Effekte: Die Softwareentwickler gehen
mit einer sehr viel höheren Motivation an Aufgaben heran und lösen diese potentiell besser.
Die Plattform Redcritter (vgl. [Red12]) bietet die Möglichkeit für erfolgreiche Erfüllung ei-
nes Tasks oder andere positive Prozesse in einem Projekt Punkte in verschiedenen Kategorien
zu sammeln. Zum Einen tragen diese Punkte dazu bei in verschiedenen Leveln zu steigen.
Zum Anderen können die Punkte am Ende eines Monats gegen Sonderprämien oder Urlaub
eingetauscht werden. Ein weiteres populäres Beispiel ist die Online-Hilfe Plattform stackover-
flow (siehe [sta12]). Hier können Softwareentwickler Probleme und Fragen einstellen, die von
anderen beantwortet werden können. Es gibt jeweils für das Einstellen und das Beantworten
16Das könnte ein Punktesystem sein oder bestimmte Level, die erhöht werden können.
14
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
der Fragen Punkte und Badges17. Stackoverflow ist eines der erfolgreichsten Frage-Antwort-
Portale18. Einer der Gründe dafür ist das umfangreiche Punkte- und Badgesystem.
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Nach der Erläuterung von Problemen bei der Kommunikation, gilt es nun zu erörtern, wie durch
den Einsatz neuartiger Kommunikationsmittel und einer höheren sozialen Interaktion diese ne-
gativen Effekte abgeschwächt werden können. Abbildung 2.4 zeigt die im Konzept der Platt-
form angedachten Kommunikationsmittel zur Lösung dieser Probleme. Die Abbildung stellt
die Abhängigkeiten zwischen den einzelnen Kanälen dar und zeigt auf, welche Eigenschaften
durch Einsatz dieser Mittel potentiell verbessert werden können. An der Spitze dieser Säule
stehen das Teamklima und das Vertrauen im Team19. Die beiden Faktoren werden durch
verschiedene Eigenschaften innerhalb eines Teams beeinflusst. Diese Eigenschaften bilden die
Stütze der Faktoren in der Abbildung. Sie werden mit Kommunikations- und Kollaborations-
mitteln verbunden. Die einzelnen Mittel werden nachfolgend analysiert.
Abbildung 2.4.: Die Säulen der Teamarbeit (Quelle: Eigene Darstellung)
17Abzeichen18Stackoverflow ist laut Alexa (Ein Trafficanalysedienst für das Internet) [ale12b] bei den weltweiten Top-Seiten
auf Platz 98 (August 2012) [ale12a]19Eine Erläuterung zu der Wichtigkeit dieser Begriffe gibt das Kapitel 2.2.
15
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
2.8.1. Einordnung und Eigenschaften der Tools (Autor: Rene Kassel)
Um die Einordnung der einzelnen Techniken besser bewerten zu können, wurden sie zunächst
in zwei Gruppen eingeteilt. Die Einteilung erfolgt in Kollaborationstools20 und Informations-
tools21. Für jede dieser Gruppen wurden eine Reihe von Eigenschaften zusammengestellt, wel-
che nachfolgend erläutert werden. Sie sind aus verschiedenen Disziplinen entnommen und stel-
len den Nutzen der Techniken in den Bereichen der Kommunikation und Interaktion dar. Die
verwendeten Eigenschaften für Kollaborationstools sind folgende:
• Kollaborationsfaktor: Dieser Wert gibt Auskunft darüber, inwiefern sich das Kommu-
nikationsmittel, unabhängig von anderen Faktoren, für die Zusammenarbeit zwischen
mehreren Projektbeteiligten eignet.
• Einfachheit: Hier soll beschrieben werden, wie groß die Lernkurve ist, um das Tool
zu bedienen. Genau genommen, sagt die Einfachheit etwas über den Schwierigkeitsgrad
der Bedienung, die Handhabung bzw. die Usability aus. Die Lernkurve ist besonders
hoch, wenn viel Aufwand durch den Nutzer investiert werden muss, bis eine akzeptable
Bedienung des Tools durchgeführt werden kann.
• Historie: Dieser Wert gibt an, wie gut Veränderungen, Kommunikationsverläufe bzw.
Verläufe der Kollaboration nachvollzogen werden können.
• Soziale Interaktion: Das ist ein Faktor, welcher eine Einschätzung über die Möglich-
keit der zwischenmenschlichen Kommunikation gibt. Dabei berücksichtigt der Faktor,
inwieweit diese möglich ist und wie gut die Interaktion unterstützt wird.
• Informationsaustausch: Wie der Name schon sagt, gibt diese Eigenschaft Auskunft
darüber, wie gut sich über das verwendete Tool Informationen austauschen lassen und
welche Arten von Informationen ausgetauscht werden können.
• Ortsunabhängige Erreichbarkeit: Hiermit wird die Unterstützung speziell im Tablet-
und Smartphone-Bereich beschrieben. Wird eine Unterstützung in diesen Bereichen ge-
währleistet, ist die Zusammenarbeit zwischen den Projektpartnern stets möglich. Damit
ist der Wert hoch. Ein geringer Wert kann entstehen, wenn der Projektpartner für die Ver-
wendung einer bestimmten Technik an seinem Arbeitsplatzrechner verfügbar sein muss.
Informationstools besitzen alle bisher genannten Eigenschaften, außer den Kollaborationsfak-
tor. Diese Eigenschaft wurde durch die Gemeinsame Informationsgenerierung ersetzt. Zu den
bisherigen kommen noch einige andere hinzu, die nachfolgend näher erläutert werden:
20Der Begriff beschreibt Tools, die ausschließlich das direkte gemeinschaftliche Arbeiten über ein Netzwerk hin-weg realisieren.
21Bei diesen Tools steht nicht die direkte Arbeit, sondern der Informationsaustausch sowie die Informationsgene-rierung und Handhabung im Vordergrund.
16
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
• Gemeinsame Informationsgenerierung: Dieser Wert gibt eine Aussage darüber, wie
gut über das spezifische Programm Informationen gemeinsam erzeugt und gesammelt
werden können.
• Gleichzeitige Dokumentbearbeitung durch mehrere Nutzer: Der Wert spiegelt die
Fähigkeit des Tools wieder, inwieweit ein Dokument durch mehrere Nutzer zur gleichen
Zeit bearbeitet werden kann. Der Wert ist besonders hoch, wenn es völlig egal ist, wann
ein Nutzer auf ein Dokument zugreift, wann er die Änderungen abspeichert und wenn
die Bearbeitung an einem gemeinsamen Dokument völlig synchron läuft.
• Übersichtlichkeit der vorhanden Informationen: Diese Eigenschaft soll beschreiben,
wie gut vorhandene Informationen dargestellt werden und welche Informationen bereits
vorhanden sind. Ebenfalls gibt sie Auskunft darüber, wie gut durch die vorhandenen In-
formationen navigiert werden kann, also die Nutzerfreundlichkeit bezüglich der Struk-
turierung der einzelnen Informationen.
• Langzeitspeicherung der Informationen: Ein wesentlich bedeutender Faktor ist, wie
gut das Tool die Speicherung von Daten über einen längeren Zeitraum gewährleistet.
• Durchsuchbarkeit der vorhandenen Informationen: Die Eigenschaft behandelt die
Suchfunktion des Tools durch die gesamten Informationen, die mit Hilfe des Tools ent-
stehen bzw. erzeugt werden. Der Wert ist besonders hoch, wenn eine Volltextsuche exis-
tiert und der Ort der gewünschten Informationen durch die Suche in kürzester Zeit aus-
findig gemacht werden kann.
Jede Technik bekommt in jeder Eigenschaft einen Punktwert zugewiesen. Dieser Punktwert
signalisiert, ob eine Technik gut geeignet ist (hoher Wert) oder nicht (niedriger Wert). Die
Skala ist in dem Bereich von null bis sechs pro Eigenschaft.
Nach der Auswertung der Eigenschaftsmatrix wird am Ende eines jeden Kapitels ein kurzes
Statement abgegeben, ob der Einsatz der Technik in einem verteilten Projekt sinnvoll ist und
für was es eingesetzt werden kann. Anschließend folgt ein Beispiel, wie die einzelne Technik
im Rahmen der Masterarbeit eingesetzt wird.
Da sich die Lösungen unterschiedlicher Anbieter wesentlich unterscheiden, ist es schwierig
Tools allgemein zu beschreiben und zu vergleichen. Daher wird im Zweifelsfall auf die in der
Masterarbeit genutzte Implementierung eingegangen, anstatt eine globale Einschätzung über
alle bestehenden Lösungen zu geben. In diesem Fall wird in einer Fußnote oder vorher im Text
darauf verwiesen.
2.8.2. Collaboration Pad (Autor: Rene Kassel)
Ein Collaboration Pad ist ein Online-Tool zum gemeinschaftlichen Erstellen eines Dokumen-
tes in Echtzeit. Es bietet die Möglichkeit, dass mehrere Personen gleichzeitig und nahezu oh-
ne Zeitverzögerung in ein und dasselbe Dokument schreiben können. Dabei kann fast jeder
17
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Tastendruck live mitverfolgt werden. Es existieren unterschiedliche Implementierungen eines
solchen Pads. Etherpad ist eine mögliche Umsetzung, welche auch im Rahmen der Masterar-
beit zum Einsatz kommt (siehe A.9). Davon existieren öffentlich zugängliche Instanzen, aber
auch die Möglichkeit diese auf einen eigenen Server zu installieren (vgl. [Col09]). Öffentliche
Beispiele sind Piratenpad, PrimaryPad, SketchPad und viele mehr (vgl. [Fou12b]).
Im Allgemeinen funktioniert ein Collaboration Pad so, dass zunächst eine Webseite aufgerufen
wird. Dort kann der Anwender ein neues Pad erstellen. Jedes Pad hat seine eigene URL. Diese
URL bleibt immer bestehen und wird nicht gelöscht. Sie ist von überall aus erreichbar. Wird
diese URL aufgerufen, dann wird ein integrierter Texteditor im Browser geöffnet, in welchem
gemeinschaftlich gearbeitet werden kann.
Ein Collaboration Pad birgt aber einige Gefahren. Gerät ein Dritter an die erwähnte URL, kann
er auf das Pad zugreifen, die gespeicherten Informationen einsehen und Veränderungen vor-
nehmen. Es ist daher ratsam, dass dort keine streng geheimen und vertraulichen Informationen
bearbeiten werden. Das trifft zumindest dann zu, wenn ein öffentlich zugänglicher Pad-Dienst
genutzt wird und keine Eigeninstallation. Ein weiteres Problem besteht darin, dass mehrere
Nutzer zur selben Zeit an der gleichen Zeile schreiben könnten. Dadurch kann es schnell zu
Unstimmigkeiten und Ärgernissen kommen. Deshalb sollte hier die Regel gelten, dass ein Nut-
zer den anderen Nutzer ausschreiben lässt, damit die Bearbeitung an dem gemeinsamen Doku-
ment nicht im Chaos endet. Zusätzlich kann zur Vorbereitung eine Art Gliederung angefertigt
werden. Ebenfalls bietet sich die Verwendung eines Audio-Chats an.
Hingegen der Probleme kann ein Collaboration Pad durch die gemeinschaftliche Arbeit an
einem Dokument motivierend wirken. Jeder Autor fühlt sich dadurch als Teil einer Gemein-
schaft. Das gemeinschaftliche Arbeiten kann die Partizipation und die Offenheit der Einzelnen
fördern (vgl. [BDMM10a]). Dadurch können Dokumente von besserer Qualität und höherer
Vielfalt entstehen. Dadurch kann wiederum die Dokumentation eines größeren Projektes ge-
nauer und intensiver werden. Durch das Schreiben an einem einzelnen Dokument sind die
Informationen zu einem Sachverhalt sofort gesammelt und nicht verteilt abgelegt. Dadurch ist
es zum Teil gewährleistet, dass weniger Informationen verloren gehen oder einfach vergessen
werden.
In der Praxis finden Collaboration Pads eine sehr rege Verwendung. So nutzt die Piratenpartei
dieses Tool für viele Abstimmungsaufgaben mit Hilfe des „Piratenpads“ (vgl. [pir12]). Dies ist
eine öffentlich zugängliche Instanz des freien Tools Etherpad, welches mit dem Piratenpartei-
Brand versehen wurde.
Etherpad, worauf die Entscheidung zur Verwendung gefallen ist, bringt eine Menge an Features
mit (vgl. [Fou12c] und [BDMM10b]). Dazu zählen:
• eine Online-Oberfläche zur Verarbeitung von Texten mit einem Textfeld,
• eine Übersicht über die Autoren, die an der Erstellung des Inhaltes mitwirken,
18
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
• die Mitverfolgung von jedem getippten Buchstaben durch den Nutzer in Echtzeit,
• die Hervorhebung von Änderungen durch unterschiedliche Farben jedes Nutzers,
• das Zurücksetzen und die Zurückverfolgung durch den Nutzer bis zum ersten getippten
Zeichen,
• die Historie in einer Art Videoaufzeichnung zur Nachverfolgung der Entstehungsge-
schichte,
• eine Chatfunktion zur Feinabstimmung zwischen den Autoren,
• die Möglichkeit zur Importierung von HTML, Word und RTF und
• die Möglichkeit zur Exportierung in die Formate HTML, Word und PDF.
Im Rahmen der Masterarbeit wurde eine Eigenschaftsmatrix erstellt, welche das Collaboration
Pad bezüglich bestimmter Eigenschaften genauer unter die Lupe nimmt. Dabei wird das Pad in
die Kategorie der Informationstools eingeteilt. Die Eigenschaftsmatrix ist in Abbildung 2.5 zu
sehen.
Das Tool eignet sich besonders gut für die Zusammenarbeit mehrerer Mitarbeiter. Dabei sticht
besonders die Echtzeitbearbeitung durch viele Nutzer an einem Dokument hervor. Die gemein-
same Informationsgenerierung ist, durch die Echtzeitbearbeitung an einem Dokument, sehr gut
möglich. Die Lernkurve ist sehr gering, wodurch wenig Zeit investiert werden muss, um die-
ses Tool zu bedienen. Bei der Eigenschaft Informationsaustausch kann das Collaboration Pad
ebenfalls stark punkten. Durch die Echtzeitbearbeitung und die einfache Bedienbarkeit lassen
sich Informationen spielend zwischen mehreren Mitarbeitern austauschen.
In der Eigenschaft der ortsunabhängigen Erreichbarkeit erhält das Tool keinen hohen Punkt-
wert. Es ist zum Einen sehr gut vom PC aus über das Internet mittels eines Webbrowsers er-
reichbar. Zum Anderen ist noch keine Unterstützung für Smartphones oder Tablets vorhan-
den.
Bei der Langzeitspeicherung und der Übersichtlichkeit der Informationen sammelt dieses Tool
kaum Punkte. Die einzelnen Pads, an denen gemeinschaftlich gearbeitet werden kann, sind über
eine eindeutige URL erreichbar. Der Nutzer hat weder eine Übersicht darüber, welche Pads
er bereits angelegt hat, noch kann er anhand der URL identifizieren, um welches Dokument
es sich handelt. Die einzige Chance, die sich in diesem Fall bietet, ist, dass der Nutzer in
einem extra angelegten Dokument eine Übersicht erstellt mit einem beschreibenden Namen
zum Pad und der dazugehörigen URL. Damit verbunden, kann das Collaboration Pad auch bei
der Durchsuchbarkeit der vorhandenen Informationen wenig punkten.
Bei der Historie verzeichnet das Tool wieder einen höheren Punkteausschlag. Der Nutzer kann
auf einer Timeline die Entwicklung des Dokumentes vollanimiert beobachten. Zudem kann er
bestimmte Stände abspeichern.
19
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Die soziale Interaktion erfährt nur leichte Abstriche. Nutzer können Dokumente gemeinsam
erstellen und sehen die Tätigkeiten voneinander in Echtzeit. Die direkte Kommunikation ist
außerhalb des Dokumentes über die integrierte Chatfunktion ebenfalls möglich. Leichte Ab-
striche gibt es, weil andere Möglichkeiten der sozialen Interaktion nicht unterstützt werden.
Abbildung 2.5.: Eigenschaftsmatrix des Collaboration Pads (Quelle: Eigene Darstellung)
Das Collaboration Pad kann in Summe der vergebenen Punkte je Eigenschaft sehr gut abräu-
men. Somit ist das Tool empfehlenswert für den Einsatz in einem verteilten Projekt und kann
dort zur Verwendung kommen. Besonders für die Echtzeitbearbeitung und die gemeinsame In-
formationsgenerierung gibt es kein Tool, was an die Qualitäten eines Collaboration Pads heran
kommt.
Als spezielle Umsetzung kommt, wie bereits erwähnt, Etherpad zum Einsatz. Es existieren
zwar einige andere Umsetzungen auf dem Markt, die ähnliche Funktionalitäten bewerkstelli-
gen, aber die Funktionalitäten so gut umsetzen wie Etherpad. Ein Beispiel dafür ist ein von
Google entwickeltes Konstrukt mit dem Namen Google Documents. Die Liveverfolgung in
Echtzeit ist dort nicht komplett gegeben und mit einer Verzögerung von 5-15 Sekunden be-
haftet. Etherpad hingegen ist ein ideales Beispiel für Liveverfolgung mit einer Verzögerung,
welche nahezu gegen null geht. Sie ist durch den Anwender kaum spürbar. Zudem ist Ether-
pad eine Open-Source-Variante und bietet die Möglichkeit den Dienst auf dem eigenen Server
zu integrieren. Im Rahmen der Arbeit wurde sich für die Eigeninstallation auf dem Server
entschieden. Somit können alle Features genutzt werden und die Autoren sind nicht von Ein-
schränkungen und Spezialisierungen abhängig.
20
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
2.8.3. Mobile Instant Messaging (Autor: Christopher Ezell)
Definition Instant Messaging
„Instant Messaging (engl. instant = sofort; engl. messaging = Datenaustausch) ermög-
licht es, mittels einer Software, dem Instant Messenger, in Echtzeit mit anderen Teilneh-
mern online zu kommunizieren.“ [OP]
Mobile Instant Messaging meint die Verwendung des Instant Messagings über das Mobilfun-
knetz auf mobilen Endgeräten, wie beispielsweise Smartphones.
Bei dem Kommunikationsablauf werden grundsätzlich zwei verschiedene Arten unterschie-
den. Die Basis des Instant Messagings ist die klassische Kommunikationsform. Diese ist da-
durch geprägt, dass ein Sender eine Botschaft an eine entfernte Person übersenden möch-
te. Technisch realisiert, wird das, indem die Botschaft an den Server des jeweiligen IM22-
Netzwerkes geschickt wird. Dieser leitet die Botschaft daraufhin an den Gegenüber weiter. Der
kann wiederum eine Antwort geben. Somit ist der Kommunkationsweg bidirektional.
Heutige IM-Systeme bieten noch weitaus mehr Funktionalitäten. Bezüglich der Kommunika-
tion sind Konferenzschaltungen bzw. Gruppenkonversationen möglich. In diesem Fall wird
von einem multidirektionalen Kommunikationsweg gesprochen. Die Übertragung funktioniert
ähnlich wie bei der bidirektionalen Kommunikation. Es gibt nur zusätzlich einen Gruppenlei-
ter, welcher spezielle Rechte besitzt, Personen einladen kann und die Unterhaltung überwachen
kann (vgl. [Mob06]).
Gerade bei den mobilen Versionen dieser Messenger hat sich in den letzten Jahren viel getan.
Durch den Erfolg der Smartphones gibt es viele tausende Nutzer mit einem hoch entwickelten
mobilen Endgerät und einer Internetverbindung. Hieraus gehen Messenger hervor, die berück-
sichtigen, dass der betreffende Nutzer immer online ist und ihm zu jeder Zeit Nachrichten
gesendet werden können. Der große Vorteil dabei: es ist nicht nötig auf ein anderes Kommuni-
kationsmittel umzusteigen, wenn der Nutzer gerade nicht im Chat erreichbar ist. Nachrichten
können einfach und transparent gegenüber Anderen geschrieben werden und der Kommuni-
kationspartner bekommt sie dann als Push-Benachrichtigung auf sein Smartphone geschickt.
Der Empfänger kann dann auf die Nachricht reagieren. Ein Beispiel für einen derartigen Dienst
ist Whatsapp. Hier können auch Standorte und Fotos miteinander geteilt werden.
Bei den beschriebenen Kommunikationsabläufen werden Nachrichten und Daten ausgetauscht.
Dies geschieht mit Hilfe von Protokollen. Es existieren eine ganze Reihe an verschiedenen
Übertragungsprotokollen, welche je nach Dienst oder bestimmten Clients verwendet werden.
Diese sind zum Teil proprietär und untereinander inkompatibel. Einige Beispiele sind (entnom-
men aus [Mob12]):
22Instant Messaging
21
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
• OSCAR: ist ein Protokoll für den AIM23 und den ICQ-Dienst sowie die dazugehörigen
Clients.
• Skype: ist der Name des Protokolls und des Clients.
• Simple: gibt dem SIP24-Standard IM-Funktionalitäten.
• XMPP25: ist ein erweiterbares Nachrichten-Anwesenheitsprotokoll.
• Yahoo Messenger: ist der Name des Protokolls und des Clients.
In der Praxis existiert eine große Auswahl an Instant Messenger Programmen. Jedes Pro-
gramm ist durch seine eigenen Funktionalitäten geprägt. ICQ ist einer der bekanntesten Cli-
ents. Er hat einen immensen Funktionsumfang und entwickelt sich immer mehr zu einem
Multimedia-Alleskönner. Es können Nachrichten und Dateien ausgetauscht werden. Ebenso
sind Video- und Audiochat möglich. Programme, wie Yahoo Messenger oder AIM, beschrän-
ken sich mehr auf Standardfunktionen. Zu den bekannten Clients gehören auch MSN von Mi-
crosoft und Skype.
Zu den allgemeinen Features von Instant Messenger Programmen zählen beispielsweise:
• der Austausch von Textnachrichten,
• der Austausch von Daten, wie Audio-, Video- und Bilddaten,
• die Anzeige des Online-Status der einzelnen Kommunikationspartner (online, offline,
abwesend, usw.),
• die Konferenzschaltung zur Kommunikation zwischen mehreren Partnern gleichzeitig
und
• ein Avatarbild.
Besondere Features werden durch die Möglichkeit zum Video- bzw. Audiochat und einem in-
tegrierten Whiteboard generiert. Letzteres ermöglicht den IM-Partnern auf einer weißen Fläche
Dinge in Echtzeit zu zeichnen (vgl. [Mob06]).
Die eigens erstellte Eigenschaftsmatrix des Mobile Instant Messaging ist in Abbildung 2.6 zu
sehen. Diese Technik ist im Bereich der Kollaborationstools angesiedelt, da es auschließlich
der direkten Kommunikation von Projektpartnern dient. Anhand der Abbildung zeigen sich die
Stärken dieses Tools. Durch die volle Unterstützung auf mobilen Endgeräten und die relativ gu-
te Netzabdeckung ist der Projektmitarbeiter nahezu dauerhaft erreichbar. Somit erhält das Tool
in der Katgeorie ortsunabhängige Erreichbarkeit volle Punktzahl. Der Informationsaustausch
ist ebenfalls dauerhaft und sehr gut möglich. Jedoch gibt es noch bessere Möglichkeiten zum
Informationsaustausch, weshalb keine volle Punktzahl vergeben werden kann. Durch den guten
23Hierbei handelt es sich um einen bestimmten Messenger von AOL.24SIP ist ein Netzprotokoll zur Erstellung, Veränderung und Beendigung einer Kommunikationssitzung zwischen
zwei oder mehr Teilnehmern (vgl. [Gro02]).25Extensible Messaging and Presence Protocol
22
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Informationsaustausch ist es gewährleistet, dass die Projektmitglieder immer auf dem neues-
ten Stand bleiben. Kommunikationswege werden durch den Einsatz eines solchen Tool stark
gekürzt. Damit kann das Tool ideal bei der sozialen Interaktion punkten. Eine weitere Stärke
dieses Tools liegt in der Eigenschaft Einfachheit. Das Tool ist einfach und ohne zusätzliche
Kenntnisse zu bedienen.
Die Historie muss leichte Abstriche erfahren. Chatverläufe je Nutzer werden mit einem Zeit-
stempel abgespeichert und sind komplett nachvollziehbar und rückverfolgbar. Jedoch ist es oft
schwierig, ein Gespräch zu einem bestimmten Thema zu finden. Oft ist die Durchsuchung der
Historie sehr aufwändig und mit viel Zeit verbunden. Dass Chatverläufe nur lokal gespeichert
werden, führt ebenfalls zum Punktabzug. Eine letzte zu untersuchende Eigenschaft ist die Kol-
laboration. Die Zusammenarbeit ist nicht vollständig gegeben. Das liegt daran, dass ein Mobile
Instant Messenger oft nur für kürzere Abstimmungssachverhalte sinnvoll ist und weniger zum
Generieren von neuen Informationen oder von Mehrwert für das Projekt.
Abbildung 2.6.: Eigenschaftsmatrix des Mobile Instant Messagings (Quelle: EigeneDarstellung)
In der Summe der vergebenen Punkte je Eigenschaft kann das Mobile Instant Messaging eine
hervorragend hohe Punktzahl sammeln. Der Nutzen dieses Kommunikationsmittels ist immens.
Der hohe Punktwert zeigt, dass das Mobile Instant Messaging unabdingbar für den Erfolg
eines Softwareprojektes ist. Die soziale Interaktion und der Informationsaustausch ist in einem
Projekt sehr wichtig, dabei zeigt dieses Kommunikaionsmittel einen Teil seiner Stärken auf.
Vor allem bei kleineren Abstimmungsaufgaben ist diese Technik oft sehr hilfreich und sollte
nicht fehlen. Dies ist besonders durch die hohe Erreichbarkeit gegeben. Probleme oder ähnliche
Anliegen, welche innerhalb eines Projektes abgestimmt oder gelöst werden müssen, müssen
nicht warten und können sofort bedient werden.
23
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Für die Unterstützung des Projektes wurde sich für die Kommunikation speziell für die Verwen-
dung des XMPP-Protokolls entschieden. Mit Hilfe dessen ist die Kommunikation innerhalb des
Projektes gewährleistet. Dieses Protokoll eignet sich besonders gut, da es einen großen Funk-
tionsumfang bietet und nahezu alle bekannten Möglichkeiten, die ein Chat bieten sollte, mit
diesem realisiert werden können.
2.8.4. Screen Sharing (Autor: Rene Kassel)
Screen Sharing, auch Desktop Sharing genannt, beschreibt die Übertragung von Bildschirmin-
halten eines Computers auf viele andere Computer über ein Netzwerk. Dadurch entsteht das
Gefühl, dass sich der Anwender direkt an dem entfernten Desktop befindet und dort arbeitet. In
der Praxis existiert eine ganze Reihe an Software, welche sich der Technik des Screen Sharing
bedienen. Dabei unterscheiden sich die einzelnen Produkte hinsichtlich ihres Anwendungsfel-
des (geschäftlich oder privat) und ihrer Funktionalität (vgl. [Mik]).
Desktop Sharing wird in verschiedenen Bereichen eingesetzt. Diese können sein (vgl. [Mik]):
• Fernwartung/Support: Dieses Gebiet gehört zu dem Hauptanwendungsfeld des Desktop
Sharings. Probleme an entfernten Computern können problemlos, schnell und ohne grö-
ßere Kommunikationsschwierigkeiten gelöst werden. Der Anwender des Remotegerätes
muss dazu lediglich eine Anwendung starten, welches den Zugang zu dem unterstützen-
den System gewährleistet.
• Teamarbeit/Projektbesprechungen: Ein weiteres Anwendungsgebiet ist die Kollabo-
ration an Dokumenten oder Produkten. Dies kann mit Hilfe eines solchen Tools über
verteilte Standorte hinweg realisiert werden.
• Fernzugriff/Remote Office: Dieser Bereich beschreibt die Fernsteuerung des eigenen
entfernten Computers über Desktop Sharing. Dies kann erfolgen, ohne dass der Anwen-
der selbst vor Ort sein muss. Es ist von unterwegs möglich, auf seine eigenen Computer
zuzugreifen und eigene Server fernzuwarten.
Ein solches Tools hat mehrere positive Eigenschaften: Die Projektpartnern können dadurch im
Team effizienter und schneller arbeiten. Dies ist besonders durch die eindeutige, schnelle und
zielführende Kommunikation möglich. Durch den Einsatz dieses Tools können Kosten und Zeit
gespart werden. Die Projektpartner müssen sich nicht an einem Ort zusammenfinden, sondern
können verteilt arbeiten. Die Bedienbarkeit von Screen Sharing Tools erweist sich als relativ
einfach. Ein weiterer Vorteil ist die Betriebssystemunabhängigkeit (vgl. [Mik]).
Es gibt eine ganze Reihe von Screen Sharing Tools auf dem Markt. Viele Lösungen werden
zur freien Verwendung angeboten. Zu den wohl bekanntesten Lösungen zählen Team Viewer
und Skype. Daneben extistieren noch CrossLoop, Yuuguu, sVNC oder SoonR. (vgl. [Ese07]).
Jedes einzelne Programm hat seine Features und Eigenschaften. Team Viewer ist eine nahezu
allumfassende Software. Es ist möglich seinen Desktop freizugeben, gemeinsam zu arbeiten,
24
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Dateien auszutauschen und miteinander zu chatten. Derjenige, der gerade seinen Desktop teilt,
kann Rechte vergeben, was der andere tun darf. Er entscheidet, wie lange ein Zugriff stattfin-
det.
Screen Sharing wird der Kategorie der Kollaborationtools zugeordnet. Die Abbildung 2.7 zeigt
die Eigenschaftsmatrix des Screen Sharings. Die Einschätzung der einzelnen Eigenschaften
über Screen Sharing ist im Allgemeinen sehr schwierig. Im Zweifelsfall wird der geschätzte
Wert von der Verwendung von Team Viewer genommen. Die einzelnen Implementierungen
unterscheiden sich ziemlich stark in ihrem Funktionsumfang.
Die Stärken dieses Tools stechen heraus: Sie liegen in den Bereichen der Einfachheit und des
Informationsaustausches. Die Bedienung ist selbsterklärend und es sind nur wenige Schrit-
te notwendig, um einen Bildschirm freizugeben. Die meisten Implementierungen des Screen
Sharings liefern eine Funktionalität zum Datenaustausch. Dadurch kann ein sehr guter Infor-
mationsaustausch stattfinden.
Die ortsunabhängige Erreichbarkeit erfährt Abstriche: Smartphoneintegration ist zwar vorhan-
den und wird unterstützt, aber das Arbeiten über ein Smartphone/Tablet ist unkomfortabel.
Die Kollaboration ist mittelmäßig. Es fördert zwar die Zusammenarbeit ungemein, aber es bie-
tet nicht die Möglichkeit zusammen und zur gleichen Zeit an einer Sache zu arbeiten. Stattdes-
sen kann nur einer auf dem Bildschirm gleichzeitig arbeiten. Der Andere kann Anmerkungen
tätigen und verfolgen.
Die Eigenschaft soziale Interaktion hat nicht die volle Punktzahl erreicht. Durch die genann-
ten Features können zwar einige Aspekte der Interaktion bedient werden, aber nicht alle. Die
meisten Screen Sharing Programme bieten keinen Audio-Chat.
Die Historie verzeichnet starke Einbußen. Den Autoren ist keine praktische Umsetzung einer
Screen Sharing-Technik bekannt, bei der Interaktionsdaten aufgezeichnet werden. Es werden
lediglich Zeitdaten erfasst, sodass nachvollzogen werden kann, wann Screen Sharing genutzt
wurde. Was jedoch innerhalb einer Sitzung geschah, ist nicht zurückführbar. Das ist ein großes
Defizit.
Das Screen Sharing als einzelne Technik kann zwar in den Eigenschaften der Einfachheit und
des Informationsaustausches stark punkten, aber nicht bei den meisten anderen Eigenschaften.
Dennoch steckt in dieser Technik jede Menge Potential für den Einsatz in verteilten Projek-
ten. Die Verknüpfung des Screen Sharings mit anderen Techniken ermöglicht fast die volle
Punktzahl über alle Eigenschaften26
Besonders die visuelle Kommunikation kann in verteilten Projekten erfolgsentscheidend sein.
Es gibt Aufgaben, die derartige Möglichkeiten zwingend benötigen. Das macht das Screen
Sharing zu einer nahezu unabdingbaren Technik für verteilte und auch für agile Projekte.
26Eine Verwendung dieser Technik mit anderen Techniken wird im nächsten Kapitel 2.8.5 vorgestellt.
25
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 2.7.: Eigenschaftsmatrix des Screen Sharings (Quelle: Eigene Darstellung)
Während der Umsetzung der Masterarbeit wird ein Tool aus diesem Bereich eingesetzt. Dabei
wird sich auf die Verwendung von Team Viewer beschränkt. Mit Hilfe dessen findet sowohl das
Pair Programming als auch das gemeinschaftliche Arbeiten an Dokumenten Unterstützung. Es
ist ideal, um seinen Projektpartner etwas zu erklären oder Neuerungen vorzustellen.
2.8.5. (Remote) Pair Programming (Autor: Rene Kassel)
Pair Programming ist eine Technik aus der agilen Softwareentwicklung27. Dabei arbeiten zwei
Programmierer zusammen an einem Arbeitsplatz. Einer der Programmierer schreibt den Quell-
code, während der andere zuschaut (vgl. [Wil01]). Nach einer gewissen Zeit tauschen die
beiden ihre Rollen. Der Beobachter achtet auf mögliche Fehler und betrachtet den geschrie-
benen Quellcode kritisch. Hat der Beobachter Anmerkungen, so teilt er diese sofort seinem
Partner mit. Dadurch kann umgehend darauf reagiert werden. Der Beobachter bringt Verbes-
serungsvorschläge mit ein. Zudem achtet er auf mögliche zukünftige Probleme, die durch den
geschriebenen Quellcode entstehen könnten. Dem Schreiber werden dadurch eine Menge an
Aufgaben abgenommen, sodass er der eigentlich Aufgabenerfüllung seine volle Konzentration
geben kann.
Das Remote Pair Programming ist ein Pair Programming, bei dem die beiden Programmierer
an unterschiedlichen Orten sind (vgl. [Flo06]). Um das verteilte gemeinschaftliche Program-
mieren zu realisieren, muss verschiedene Software eingesetzt werden. Dabei sollte mindestens
eine Software aus dem Bereich Screen-Sharing (Kapitel 2.8.4) oder einem Plug-in in einer
27Genauer gesagt, ist es eine Technik aus dem Extreme Programming (vgl. [Wel12]).
26
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Entwicklungsumgebung zum Einsatz kommen. Zusätzlich ist es notwendig, dass eine Softwa-
re aus dem Bereich Collaboration Pad (Kapitel 2.8.2) oder ein Audio-Chat eingesetzt wird. Mit
jeweils einer Anwendung aus diesen Bereichen werden die Grundzüge des Pair Programmings
auch bei verteilter Verwendung umgesetzt. In den einzelnen Bereichen gibt es verschiedenste
Softwareangebote, welche eingesetzt werden können.
Das Ziel dieser Technik ist die Steigerung der Softwarequalität. Dies bietet die Beobachter-
Funktion, mit der kritische Lösungen eingeschränkt werden können. Der Lerneffekt der Partner
kann erhöht werden. Sie können voneinander lernen und sich zum Teil neue Möglichkeiten
aneignen.
Einige Studien haben herausgefunden, dass Programmierer, die diese Methode verwenden,
zwar kleinere Programme produzieren, dafür aber ein besseres Design und weniger Fehler
erzeugen (vgl. [CW00]). Durch Studien wurde belegt, dass die Fehlerrate um 15-50 Prozent
bei Verwendung dieser Technik sinkt, je nach Programmiererfahrung und Aufgabenkomple-
xität (vgl. [CCG+07] und [Eco01]). Mehrere Programmierer erschaffen ein besseres Design,
was einfacher zu handhaben ist und weniger Fehler aufweist, als ein einzelner Programmierer
(vgl. [WK03]). Nahezu unmöglich lösbare Probleme sind in der Gemeinschaft einfacher und
schneller zu lösen (vgl. [CW00] und [WK03]). Ein weiterer Vorteil stellt sich dadurch heraus,
dass die Programmierer ihr Wissen untereinander teilen und voneinander lernen können (vgl.
[CW00] und [WK03]).
Wird im gesamten Team das Remote Pair Programming betrieben, vermindert sich das Risiko,
dass Wissen verloren geht, wenn ein Mitglied das Team verlässt (vgl. [CW00]). Die Stärkung
des Vertrauens untereinander ist ein entscheidender Faktor, der dieser Technik zugeschrieben
werden kann (vgl. [Krz08]).
Das Remote Pair Programming kann aber mit einigen Nachteilen behaftet sein. Es passiert sehr
leicht, dass einer der Partner, meist der Beobachter, nebenher anderen Aufgaben nachgeht. Ein
weiterer kritischer Punkt entsteht, wenn ein Programmierer viel erfahrener ist als der Partner.
So kann es zu Konflikten kommen, indem der Erfahrenere den anderen beschimpft oder be-
leidigt. Ein anderes Problem stellt die Arbeitszeit dar: Konzentrieren sich zwei Programmierer
auf die selbe Aufgabe, werden die Manntage verdoppelt.
Der Nutzen dieser Technik ist in der Eigenschaftsmatrix des Remote Pair Programmings in der
Abbildung 2.8 zu sehen. Das Pair Programming wird unter Berücksichtigung der Verwendung
aller wichtigen Tools betrachtet. Diese Technik wird als Kollaborationstool eingeteilt.
Die alleinige Verwendung des Tools ohne eine akustische Kommunikation erweist sich als
unpraktisch und ineffizient. Die Stärken des Remote Pair Programmings liegen in den Berei-
chen der Kollaboration, der sozialen Interaktion und in dem Informationsaustausch. Speziell
in Softwareprojekten ist es sehr hilfreich mehrere verschiedene Programme, die diese Technik
unterstützen, einzusetzen. Eine mögliche Unterstützung für das Remote Pair Programming ist
das Screen Sharing.
27
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Treten Schwierigkeiten auf, können sich die Teammitglieder mit Hilfe dieser Tools gegensei-
tig sehr gut unterstützen und vorantreiben. Somit ist einer Verzögerung bei der Bearbeitung
bestimmter Aufgaben schnell entgegengewirkt. Die Zusammenarbeit ist in vollem Umfang er-
füllt. Damit verbunden ist auch die soziale Interaktion stark ausgeprägt. Die beiden Nutzer
sehen den gleichen Bildschirm. Auf diesem Bildschirm können Veränderungen vorgenommen
werden und Inhalte generiert werden. Jedoch kann immer nur einer der Nutzer an dem Sachver-
halt arbeiten. Der Wechsel des bearbeitenden Nutzers kann sehr schnell und mit einer geringen
Wechseldauer erfolgen.
Es gibt Applikationen für Smartphones, welche das Remote Pair Programming ermöglichen.
Ein Smartphone als Endgerät für die Softwareentwicklung ist nicht gut geeignet, gegeben duch
die Eigenschaften eines Smartphones, wie Displaygröße, Handhabbarkeit, Nutzerfreundlich-
keit und ähnliche. Damit ist der Einsatz eines solchen Tools auf einen Smartphone nur wenig
sinnvoll. Die Autoren haben das Tool auf einem Smartphone getestet. Der Test ergab, dass es
sich nur für den Notfall eignet, aber nicht für die Routine. Es erwies sich als weniger nut-
zerfreundlich. Aufgrund dessen erhalten Remote Pair Programming Tools in der Kategorie
ortsunabhängige Erreichbarkeit lediglich drei Punkte.
Einen Tiefschlag erleiden solche Tools in der Kategorie Historie. Ändern und Bearbeiten durch
Nutzer werden nicht historisch abgelegt. Es kann nicht rückwirkend nachvollzogen werden,
welcher Nutzer zu welcher Zeit welchem Nutzer an was gearbeitet hat. Änderungen am Quell-
code können aber durch zusätzliche Tools, wie einer Versionskontrolle, nachvollzogen werden.
Aus diesem Grund ist die geringe Punktzahl in der Kategorie ertragbar und nicht von starker
Relevanz für den Einsatz eines solchen Tools.
Die Bedienbarkeit solcher Programme ist sehr nutzerfreundlich und unkompliziert. Somit wird
in der Kategorie Einfachheit eine hohe Punktzahl erreicht.
Insgesamt kann diese Technik viele Punkte sammeln. Die meisten Eigenschaften erreichen je-
weils hohe Punktzahlen. Besonders für die Kollaboration ist diese Technik eine der wenigen,
die volle Punktzahl nach Meinung der Autoren erreicht. Dieser Sachverhalt sowie die hohe
Gesamtpunktzahl rechtfertigen damit den Einsatz solcher Tools für verteiltes, gemeinschaftli-
ches Arbeiten in Projekten. Die Fehlerrate sinkt und die Fehlerbehebung erfolgt viel schneller
und effizienter. Somit ist Pair Programming sehr sinnvoll und bringt in Projekten sehr viele
Vorteile.
Zur Unterstützung des Masterarbeitsprojektes mittels des Pair Programmings wurden Tools in
vielen Bereichen eingesetzt. In der Kategorie Screen-Sharing fanden speziell die Tools Team
Viewer und die MacOS-Bildschirmfreigabe Einsatz. In manchen Fällen kam die Bildschrim-
freigabe von Skype zum Einsatz.
Als Whiteboard wird das Eclipse-Plugin Saros verwendet. Saros unterstützt zusätzlich das ge-
meinschaftliche Schreiben an einer Quellcode-Datei. Als Collaboration Pad wurde eine Eigen-
installation von Etherpad ausgewählt. Zur akustischen Abstimmung wird im Rahmen des Mas-
28
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 2.8.: Eigenschaftmatrix des Remote Pair Programmings (Quelle: EigeneDarstellung)
terarbeitsprojektes vorwiegend Skype oder der Chat auf dem eigenen Projektserver verwendet,
welcher ebenfalls den Audio-Chat unterstützt.
2.8.6. Blog (Autor: Rene Kassel)
Blogs sind ein sehr weit verbreites Kommunikationsmittel. Sie bestehen aus einer Liste von
Artikeln, die auf einer Webseite geführt und chronologisch angeordnet sind. Sie werden haupt-
sächlich für Tagebücher und Veröffentlichungen von Fachbeiträgen genutzt. In den letzten Jah-
ren etablierten sie sich für den Einsatz als Kommunikationsmittel innerhalb von Projekten. Sie
können für verschiedene Zwecke eingesetzt werden.
Für diesen Kommunikationskanal eignen sich Informationen, die von einer Person für viele
Personen bereit gestellt werden. So können tagesaktuelle Ereignisse und neue Informationen
schnell und effizient ins gesamte Projekt verteilt werden und jeder kann schnell auf diese In-
formation zugreifen. Durch die Verwendung eines RSS-Readers (Really Simple Syndication)
können die Inhalte sogar mobil konsumiert und für die Offlineverwendung archiviert werden
werden. Durch die Möglichkeit eines Kommentarsystems können Meinungen zu einem Sach-
verhalt ermittelt und diskutiert werden. Das macht einen Blog zu einem mächtigen Werkzeug
in der verteilten Kommunikation und sollte in keinem größeren Projekt fehlen. Innerhalb von
Projekten sollte sich im Vorfeld geeinigt werden, über was gebloggt wird. Ob nur technische
Themen und Neuerungen in der Architektur als Themen dienen oder ob auch die Frage nach
Lösungen eines Problems in einen Blogpost gefasst werden können (vgl. [Tri12]).
Der Blog zählt zu den Informationstools. In Abbildung 2.9 ist die Eigenschaftsmatrix zu se-
hen. Eindeutig liegen die Stärken in der Durchsuchbarkeit der vorhandenen Informationen,
29
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
der Langzeitspeicherung und der Historie. Die Erreichbarkeit ist durch die vollständige Be-
dienbarkeit über eine Weboberfläche (sowohl auf dem Desktop also auch auf einem mobilen
Browser) sehr hoch und kann stark punkten. Die Bedienbarkeit eines Blogs ist bei den meisten
Produkten sehr einfach und nutzerfreundlich, d.h. fünf Punkte in der Kategorie Einfachheit.
Mittelmäßige Punktausprägung erhält der Blog in der Übersichtlichtkeit, wegen der stark zeit-
orientierten Anordnung der Blogbeiträge. Diese können nur mit Hilfsmitteln besser strukturiert
werden, z.B. mit Hilfe von Tags. Die Eigenschaft gemeinsame Informationsgenerierung hat le-
diglich drei Punkte, da ein Blog meist nur zur Verbreitung von Neuigkeiten dient. Trotzdem
können einige Informationen aus einem Blog entnommen werden, wie beispielsweise Mei-
nungsbilder und Abstimmungen über konkrete Sachverhalte.
Mittelmäßig bis schwach ausgeprägt sind die Kategorien soziale Interaktion, Informations-
austausch und gleichzeitige Dokumentbearbeitung. Die gleichzeitige Dokumentenbearbeitung
existiert bei dieser Art der Kommunikation nicht. In den meisten Fällen schreibt lediglich ei-
ne Person28 ihren Blogeintrag und andere können diesen dann einsehen und kommentieren.
Deswegen erhält der Blog auch nur eine mäßige Punktanzahl in der Eigenschaft Informations-
austausch. Informationen können bei diesem Medium in Form von Texten, Bildern, Videos
und Weblinks ausgetauscht werden und beinhalten je nach Fokus Neuigkeiten, Anleitungen
und Empfehlungen zu einem bestimmten Themengebiet. Eine direkte Interaktion zwischen
den Projektmitgliedern ist mittels eines Blogs nicht möglich, daher die geringe Punktzahl in
dem Bereich soziale Interaktion.
Abbildung 2.9.: Eigenschaftsmatrix des Blogs (Quelle: Eigene Darstellung)
28Es ist bei manchen Blogsystemen durchaus möglich einen Beitrag von mehreren Autoren zu bearbeiten.
30
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Insgesamt kann ein Blog stark punkten. Besonders für langfristige und gut durchsuchbare In-
formationen in einem Projekt sollte ein Blog eingesetzt werden. Der Einsatz ist aber eher in
größeren und schwer überschaubaren Projekten sinnvoll. Da ist es oft zum Verständnis der Auf-
gabe und zum besseren Erfolg des Projektes sehr wichtig über neue Techniken und Technolo-
gien zu berichten. Durch die gute Erreichbarkeit eignet es sich auch für verteilte Projekte.
Im Rahmen der Masterarbeit wird Wordpress als Blogsystem verwendet. Die Hauptaufgaben
des eigenen Blogs liegen in dem Informieren der Projektpartner über neue Techniken, Tech-
nologien und Implementierung bezüglich des Projektes. Ebenso dient er auch als Möglichkeit,
Themen bezüglich des Projektes zu diskutieren.
2.8.7. Microblogging (Autor: Rene Kassel)
Microblogging ist ein Webservice, welcher es Nutzern erlaubt kurze Textnachrichten an andere
Nutzer zu senden. Diese kurzen Nachrichten werden Microposts genannt. Sie können öffentlich
publiziert werden oder nur einer privaten Gruppe von Nutzern. Der Nutzer kann die Nachrich-
ten online lesen oder Updatebenachrichtigungen über Veränderungen in Echtzeit erhalten, wie
beim Instant Messaging (vgl. [Rou09]).
Die Beiträge sind sehr kurz formuliert. Sie haben zwischen 140 und 200 Zeichen. Damit steht
das Microblogging im Gegensatz zum Blog, bei dem größere Inhalte publiziert werden. Kla-
re Stärke dieser Technik ist, dass sie über eine Vielzahl an Geräten genutzt werden kann, so
auch auf dem Smartphone. In der Regel sind Microposts in Textform, aber es extistieren auch
Dienste, die das Bloggen von Audio- oder Video-Streams erlauben (vgl. [Rou09]).
Die Thematik Microblogging ist durch den Nachrichtendienst Twitter sehr populär geworden.
Andere Beispiele sind Tumblr oder Plurk. Aber auch soziale Netzwerke wie Facebook, Linke-
dIn, Xing und Google+ besitzen eine Art Microblogging in ihren Funktionalitäten.
Im privaten Gebrauch erfahren solche Dienst sehr viel Zuspruch. Nach Meinung der Autoren
wird diese Möglichkeit der Kommunikation jedoch im Firmenbereich und Projektumfeld noch
zu wenig eingesetzt.
„Microblogging has the potential to become a new, communication medium, especially
for collaborative work within organizations“ [ZR09].
Das Zitat untermauert die Idee, dass dieses Tool die Kommunikation innerhalb eines Teams
stak verbessern kann.In den letzten Jahren hat sich die Kommunikation immer mehr zu ei-
ner Onlinekommunikation gewandelt, beispielsweise mittels E-Mail und Instant Messaging.
Die Kommunikation über E-Mails kann teilweise sehr zeitaufwändig und langsam sein (vgl.
[Val11]). So ist gerade bei kurzen Informationen oder sogar bei der Planung von Meetings und
anderen Dingen ein anderer Weg besser geeignet. Dafür kann das Microblogging sehr gute in
Firmen eingesetzt werden.
31
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
In einem aktuellen Blog vom Juli 2012 werden erste Beispiele für Microblogging-Dienste
für den Einsatz in Unternehmen vorgestellt.Beispiele sind Yammer, Co-op und ein deutscher
Dienst namens Communote. Dabei versprechen die Dienste laut dem Blog eine schnellere Pro-
jektkoordination und einen einfacheren Wissensaustausch zwischen Projektmitarbeitern. Com-
munote befindet sich zur Zeit im Beta-Stadium, verspricht aber eine Mischung verschiede-
ner Dienste, wie das Annlegen von Diensten, Mitarbeiter-Blogs und den Dateiupload (vgl.
[Hei12]). Der Artikel Will Microblogging at Work Make You More Productive [Mil08] aus der
New York Times berichtet davon, dass bereits Cisco Systems, Xerox und Hewlett-Packard sol-
che Dienste nutzen.
Durch die Eigenschaftsmatrix in Abbildung 2.10 wird der Nutzen eines solchen Tools für den
Einsatz in Projekten bestimmt. Das Microblogging siedelt sich im Bereich der Informations-
tools an.
Die Technik besticht durch die hervorragende Historie und die ortsunabhängge Erreichbarkeit.
Die Integration auf Smartphones und Tablets ist vollständig gegeben. Die Handhabung von Mi-
crobloggingtools sehr einfach und bedarf wenig bis gar keinen Lernaufwand durch den Nutzer
(fünf Punkte für die Einfachheit). Die Langzeitspeicherung der Informationen und die Über-
sichtlichkeit zählen auch zu den Stärken von Microblogging. Die Microposts sind in chronlo-
gischer Reihenfolge sortiert und bis zum ersten Post zurückverfolgbar.
Im Bereich Informationsaustausch kann das Kommunikationsmittel nur mäßig punkten. Kur-
ze Statusmeldungen können zwar abgesetzt werden, zum Teil in Text-, Video- und Audio-
form, aber nur für spezielle Themen. Für den allgemeinen Informationsaustausch zwischen
Projektmitarbeitern eignen sich andere Tools besser. Damit verbunden, punktet auch die sozia-
le Interaktion nur wenig. Der Blogger setzt seine Meldung ab und alle anderen können diese
einsehen, aber nicht direkt miteinander kommunizieren. Gerade durch das Veröffentlichen von
kurzen Statusmeldungen ist die gemeinsame Informationsgenerierung nicht komplett gegeben.
Meldungen können zwar generiert werden, jedoch nur wenig neue Informationen. Die Durch-
suchbarkeit von vorhandenen Informationen ist gut über die Browsersuche möglich, aber es
existiert keine eigene Suchfunktion, daher nur vier Punkte. Die gleichzeitige Dokumentbear-
beitung durch mehrere Nutzer ist an dieser Stelle nicht gegeben. Diese Eigenschaft ist bei dem
Microblogging wenig sinnvoll, da kaum neue Inhalte generiert werden, sondern lediglich Neu-
igkeiten und Statusmeldungen ausgetauscht werden.
Im Großen und Ganzen ist zu sagen, dass das Microblogging eine sehr angenehme Tech-
nik. Besonders bei der Schnelligkeit und der Einfachheit sowie bei der Aktualität der Inhalte
zeigt das Microblogging seine Stärken. Projektmitarbeiter können stets mit aktuellen Projekt-
Neuigkeiten versorgt werden und schnell auf bestimmte Dinge reagieren. Somit hat der Einsatz
dieser Technik in verteilten Projekten viel Sinn.
Im Rahmen der Masterarbeit haben sich die Autoren für eine Eigenimplementierung dieser
Funktionalität entschieden. Einer der wichtigsten Gründe dafür ist, dass die Funktionalität sehr
stark an die eigenen Bedürfnisse angepasst werden kann. Im umzusetzenden Projekt wird die
32
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 2.10.: Eigenschaftsmatrix des Microbloggings (Quelle: Eigene Darstellung)
Technik dazu eingesetzt, Neuigkeiten an das andere Projektmitglied zu posten. Zudem wer-
den bestimmte Statusnachrichten der Entwicklungsumgebung abgefangen und automatisiert in
den Microblog gesendet. Eine ebenso wichtige Funktion ist die Pushbenachrichtigung, die bei
jedem abgesetzten Micropost an das Smartphone des anderen gesendet wird. Dadurch werden
Projektpartner sofort über Neuigkeiten infomiert und sind demzufolge immer auf dem neuesten
Stand.
2.8.8. Social Bookmarking (Autor: Rene Kassel)
Die folgende Definition von Social Bookmarking bringt kurz und bündig eine Zusammenfas-
sung, wobei es sich bei diesem Dienst handelt.
Definition Social Bookmarking
„Social bookmarking is the practice of saving bookmarks to a public Web site and ’tag-
ging’ them with keywords. Bookmarking, on the other hand, is the practice of saving the
address of a Web site you wish to visit in the future on your computer.“ [Socb]
Um den Dienst zu nutzen, muss sich der User an einer Plattform anmelden. Möchte er einen
bestimmten Link einer Webseite abspeichern, kann er dies über die Plattform tun. Zusätzlich
ist es dem Nutzer möglich für die Sortierung und Organisation von Lesezeichen Tags zu ver-
wenden. Damit wird die Ressource kurz beschrieben. [Soca]
Ein Social-Bookmarking-System hat einige wichtige Features. Eines der nützlichsten Features
ist, dass der Nutzer von überall aus auf seine Lesezeichen zugreifen kann. Sie sind sowohl über
ein Smartphone als auch über jeden beliebigen anderen Rechner verfügbar. Es gibt ebenso die
33
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Möglichkeit Tags anderer Nutzer nach einem bestimmten Inhalt zu durchsuchen (vgl. [Soca]).
Einige Webseiten bieten zusätzlich eine Verifizierung, ob die Links noch funktionieren. Ein
weiteres Feature ist die Durchsuchbarkeit. Nutzer können Lesezeichen nach Schlüsselwörtern,
Tags und bestimmten Schemen, die sie anlegen, durchsuchen. (vgl. [Socb])
Der Einsatz und die Verwendung solcher Systeme ist besonders dann sinnvoll, wenn der
Nutzer eine Menge Lesezeichen sammeln und teilen möchte. Es ist einfach zu bedienen und
schafft eine gewisse Ordnung in den Bookmarks. Besonders gut geeignet ist es für Nutzer,
die viele verschiedene Endgeräte verwenden und von überall aus ihre Lesezeichen verwalten
wollen.
Für den unternehmerischen Einsatz sind solche Systeme ebenfalls gut geeignet. Es können Le-
sezeichen zu bestimmten zu erledigenden Aufgaben online gespeichert, durch Tag-Zuordnung
sortiert und mit Projektmitgliedern geteilt werden. Besonders durch das Annotieren mit Tags
und die Veröffentlichung tragen Social-Bookmarking-Systeme zur Verbesserung der Auffind-
barkeit der Bookmarks bei. Damit kann ein solches System eine Alternative zu algorithmenba-
sierten Suchmaschinen sein. Der spezielle Vorteil liegt darin, dass ein gemeinschaftlicher und
von Menschen geschaffener Index entsteht, durch den gesucht werden kann [ML08]. Besonders
in Projekten bzw. für Unternehmen kann dies von großer Bedeutung sein und die Suchzeiten
bezüglich bestimmter Themen stark verkürzen. Denn gerade dort ist es oft so, dass ähnliche
Themen von Relevanz sind und mehrfach durch unterschiedliche Mitarbeiter gesucht werden
müssen. Hier können Mitarbeiter durch die Erfahrungen anderer profitieren und gespeicherte
und getaggte Bookmarks durchsuchen.
Die Studie Social Bookmarking und Tagging der Praxis [ML08] von 2008 zeigt, dass Social-
Bookmarking-Systeme bisher wenig bekannt sind. In der Studie gaben 73,5 Prozent der Befrag-
ten an, dass sie solche Systeme weder kennen noch nutzen. Das Tagging ist noch unbekannter.
84,12 Prozent der Befragten kann dies nicht, noch nutzen sie es. In der Praxis existieren einige
Implementierungen dieses Dienstes. Der Dienst wird entweder über eine Webseite angeboten
oder als Erweiterung für den Browser. Bekannte Umsetzungen sind Delicious, Technorati, Di-
igo und Google Bookmarks.
Die Eigenschaftsmatrix des Social Bookmarking ist in Abbildung 2.11 dargestellt. Diese Tech-
nik gliedert sich in den Bereich der Informationstools ein. Zur einfacheren Bewertungsmög-
lichkeit wird die im Projekt eingesetzte Umsetzung Diigo betrachtet.
Die klaren Stärken von Diigo liegen hier in der Einfachheit und der Übersichtlichkeit der Infor-
mationen. Besonders durch die Tagging-Möglichkeit können die Informationen sehr gut struk-
turiert werden. Die gemeinsame Informationsgenerierung ist ebenfalls gut. Besonders durch
die Strukturierung von Bookmarks wird ein Mehrwert durch gezieltes Tagging dieser erzielt.
Die Integration für Smartphones ist ebenso vorhanden, daher die hohe Punktzahl in der Kate-
gorie ortsunabhängige Erreichbarkeit. Die Projektmitglieder konnten jederzeit und von überall
aus die Möglichkeit auf die geteilten Lesezeichen zugreifen.
34
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Defizite verzeichnet das Social Bookmarking jedoch in den restlichen Bereichen. Die Durch-
suchbarkeit der vorhandenen Informationen ist nur mäßig gegeben. Zwar können Bookmarks
nach Schlüsselwörtern durchsucht werden, aber der Inhalt der einzelnen Links ist global nicht
durchsuchbar. Informationen werden ebenso nur spezielle ausgetauscht, was einen allumfas-
senden Informationsaustausch nicht gewährleistet.
Die soziale Interaktion ist nicht vorhanden, da Projektmitglieder über dieses Kommunikations-
mittel nicht direkt miteinander kommunizieren können, lediglich themenbezogenen Lesezei-
chen werden ausgetauscht.
In dem Bereich der gleichzeitigen Dokumentbearbeitung kann die Technik auch nur mittelmä-
ßig punkten. Innerhalb von Diigo ist es zusätzlich möglich, bestimmte Inhalte der Weblinks zu
markieren. Diese Bearbeitung kann gleichzeitig erfolgen, was eine mittlere Punktzahl mit sich
bringt. Eine Historie bringt dieses Tool nicht mit. Informationen können nur mittelfristig lange
gespeichert werden. Beim Löschen oder Verändern eines Bookmarks kann dieses nicht wieder
rekonstruiert werden, was teilweise durch die fehlende Historie mitverschuldet ist.
Abbildung 2.11.: Eigenschaftsmatrix des Social Bookmarkings (Quelle: Eigene Darstellung)
Die Auswertung zeigt, dass die Übersichtlichkeit der Daten stark ausgeprägt ist. Social Book-
marking ist eine Möglichkeit bereits gefundenes Wissen des Internets zu strukturieren und
verfügbar zu machen. Das kann in Projekten von großer Bedeutung sein und speziell bei der
Suche nach bestimmten Informationen zeitbezogene Vorteile schaffen. Die Bekanntheit dieser
Technik ist gering ausgeprägt und das Potential wird demzufolge nur wenig genutzt.
Im Projekt ist es verzichtbar, da es ein sehr spezielles Kommunikationsmittel ist, aber es ist an-
genehm einzusetzen und bringt oft Vorteile. Im Rahmen der Masterarbeit wurde dieses Mittel
35
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
besonders für die Quellenarbeit und die Dokumentation eingesetzt. So war es beiden Projekt-
beteiligten möglich, ihre Bookmarks zu sammeln und wichtiges Inhalte vorab zu markieren.
Das hat des Öfteren die Arbeit immens erleichtert.
2.8.9. Standortbezogene soziale Netzwerke (Autor: Christopher Ezell)
Standortbezogene Dienste, engl. Location Based Services (LBS), sind Dienste eines Mobil-
funkanbieters, die auf den Aufenthaltsort des Nutzers abgestimmte Informationen bereitstellen.
Diese können Einkauf- und Freizeitmöglichkeiten sein, Informationen über Sehenswürdigkei-
ten, regionale Angebote und Verkehrsdaten, aber auch zur Standortbestimmung bestimmter
Personen (vgl. [ITW12]).
Standortbezogene Netze sind ausschließlich für den Markt der Smartphones konzipiert. Damit
die abgestimmten Informationen bereitgestellt werden können, muss die aktuelle Position des
Gerätes ermittelt werden. Das kann über das im Smartphone integrierte GPS-Signal (Global
Positioning System) ermittelt werden. Dabei gibt es verschiedene Möglichkeiten. Zum Einen
ist die Bestimmung über die Funkzelle möglich, in der sich jeder Mobilfunkteilnehmer anmel-
det. Jede Funkzelle verfügt über eine eindeutige Identifikationsnummer. Darüber ist eine grobe
Ortung möglich. Jedoch ist dies ziemlich ungenau. Durch den Einsatz von GPRS (General
Packet Radio Service) kann die Genauigkeit erhöht werden (vgl. [ITW12]).
Das bekannteste standortbezogene Netzwerk ist Foursquare. Es erweitert die Funktionalität ei-
nes sozialen Netzwerks. Es kommt bei diesem Dienst die Übertragungsmöglichkeit von Ortsin-
formationen der Nutzer hinzu. Dadurch können sich Nutzer gegenseitig Orte präsentieren und
sich leichter miteinander verabreden (vgl. [Mor]). Weitere Beispiele sind Facebook Places und
Qype.
Um die Akzeptanz solcher Dienste zu erhöhen, wurde in den meisten Umsetzungen eine Spiel-
komponente eingebaut. Bei Foursquare beispielsweise kann der Nutzer zum Mayor, also zum
Bürgermeister, eines bestimmten Ortes ernannt werden, wenn er dort öfter eingecheckt hat als
jeder andere (vgl. [Fou]). Somit wird der Spieltrieb im Menschen aktiviert, was ihn zu ver-
mehrten Übersenden von Ortsinformationen veranlasst.
Die Nutzung von standortbezogenen Netzen wird immer beliebter. Eine Umfrage hat ergeben,
dass 58 Prozent der deutschen Handynutzer, welche derartige Dienste noch nicht nutzen, den
Einsatz in Erwägung ziehen. Bereits 19 Prozent der sechs Milliarden Mobiltelefonnutzer nut-
zen standortbezogene Dienste (vgl. [Ver12]). Daraus schlussfolgernd, weisen derartige Dienste
eine hohe Akzeptanz auf.
Der Nutzen in Projekten wird durch die Eigenschaftsmatrix in der Abbildung 2.12 dargestellt.
Standortbezogene soziale Netz sind im Bereich der Informationstools eingeteilt. Ein klarer
Vorteil ist die ortsunabhängige Erreichbarkeit. Sehr gut sind die Bedienbarkeit und Nutzer-
freundlichkeit, also die Einfachheit.
36
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Das Zurückverfolgen von Aufenthaltsorten ist komplett möglich, weshalb es im Bereich His-
torie volle Punktzahl gibt. Die Informationen sind sehr übersichtlich und können über lange
Zeit gespeichert und nachverfolgt werden. Daraus resultieren auch die hohen Punktwerte in
den Kategorien Langzeitspeicherung und Übersichtlichkeit der vorhandenen Informationen. In
der Eigenschaft gemeinsame Informationsgenerierung kann diese Technik, bezogen auf Orts-
daten, ebenfalls einen hohen Punktwert sammeln. Die Ortsdaten können problemlos von vielen
unterschiedlichen Nutzern angegeben und eingesehen werden.
Die soziale Interaktion ist nur mittelmäßig gegeben, da nur ortsbezogene Daten ausgetauscht
werden. Weitere Interaktionsmöglichkeiten sind nicht möglich. Damit verbunden kann auch
der Informationsaustausch nicht komplett punkten. Die Durchsuchbarkeit der vorhandenen
Informationen ist nur über die integrierte Browsersuche möglich, weshalb an dieser Stelle nur
drei Punkte vergeben werden können. Eine gleichzeitige Dokumentbearbeitung ist nicht mög-
lich, was bei dieser Technik auch keinen Vorteil herbeiführen würde, da jeder der Nutzer seinen
eigenen Standort übermittelt. Dokumente werden hier nicht erzeugt.
Abbildung 2.12.: Eigenschaftsmatrix der standortbezogenen sozialen Netzwerke (Quelle: Ei-gene Darstellung)
Insgesamt kann dieser Dienst viele Punkte sammeln. Das macht ihn für ein Projekt unverzicht-
bar. Der große Vorteil liegt in dem steigenden Verständnis, an welchem Ort sich Projektmit-
arbeiter gerade befinden. Dies wird als Awareness29 bezeichnet. Awareness kann sehr hilfreich
in der sozialen Interaktion sein und ist bei unterschiedlichen Aufgabenverteilungen im Projekt
besonders wichtig. Es ist zum Beispiel wichtig, wenn ein Projektpartner nicht rechtzeitig zu
einem Meeting kommt oder er schwer zu erreichen ist. Die Ortsinformation über einen Loca-
tion Based Service kann dabei Abhilfe verschaffen. Es lässt sich in vielen Fällen rechtfertigen,
29Darunter wird die Bewusstheit verstanden, mit der die verteilten Teammitglieder die anderen wahrnehmen undderen Situation einschätzen.
37
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
warum der Projektpartner nicht erreicht werden kann. Es ist ebenso möglich abzuschätzen,
wann ein Projektpartner z.B. zu einem Meeting eintrifft. Besonders in solchen oder ähnlichen
Situationen ist ein solcher Dienst sehr hilfreich. Dieses Vorgehen sollte dann mit allen Pro-
jektmitarbeitern abgestimmt werden, um aufkommenden Konflikten diesbezüglich entgegen-
zuwirken. Ein Vorschlag dafür ist ein zeitgesteuertes Ortstracking. So kann reguliert werden,
dass eine Standortbestimmung nur zur Arbeitszeit erfolgt.
Im Rahmen der Masterarbeit wurde mit Hilfe dieser Technik das Verständnis, besonders in
Hinblick auf die schwere Erreichbarkeit, verbessert. Der Projektpartner war dadurch immer in
Kenntnis, was der Partner gerade tut oder wo er sich aufhält.
2.8.10. Shared Storage (Autor: Rene Kassel)
Der Begriff Shared Storage beschreibt eine Technik, mit der viele Personen auf ein Netzlauf-
werk zugreifen können. Es kann mittlerweile mit jedem Rechner über den integrierten Ether-
netport betrieben werden. Über den Port erfolgt ein Zugriff auf den Server, der jeden Betei-
ligten, entsprechend ihrer Rechte, den Zugriff auf die Daten des Netzlaufwerks erlaubt (vgl.
[Sma12]).
Diese Technik hat sich in den letzten Jahren weiterentwickelt. Besonders durch den großen Hy-
pe um Techniken, wie Amazon S330. Obwohl es Netzwerk-Festplatten schon seit vielen Jahren
gibt, hat sich das Paradigma eines komplett synchronen Ordners auf allen Rechnern der Pro-
jektmitglieder erst mit dem Aufkommen von schnelleren Netzen durchgesetzt. Wohingegen ein
Netzwerkordner nur ein passiver Speicher ist, bei dem jeder Aufruf über das Netzwerk statt-
findet, sind bei einer Lösung wie Dropbox zusätzlich alle Daten komplett als Ordner auf dem
lokalen Rechner gespeichert. Im Hintergrund läuft ein Dienst, der sich um die Datenhaltung
und Synchronisation mit dem Server kümmert. Somit ist gewährleistet, dass stets der gleiche
Datenbestand auf allen eingebundenen Rechnern und dem Server vorhanden ist.
Shared Storage gehören zu den Informationstools. Die Abbildung 2.13 zeigt die Eigenschafts-
matrix. Die Punktwerte richten sich ausschließlich nach der verwendeten Lösung Dropbox.
Die großen Stärken von verteiltem Festplattenspeicher zeigen sich relativ schnell: Es ist ideal
für den Informationsaustausch zwischen mehreren Projektbeteiligten geeignet. Es gibt keine
bessere Lösung als die des Shared Storage um eine Vielfalt an Informationen in Form von Da-
teien auszutauschen. Weiterhin können die ausgetauschten Dateien langfristig gespeichert und
archiviert werden, was der Langzeitspeicherung der Informationen einen hohen Wert einbringt.
Im Normalfall liegen alle Daten nochmal auf einem externen Server.
Die Eigenschaft der Übersichtlichkeit der vorhandenen Informationen ist stark ausgeprägt.
Dies wird dadurch gewährleistet, dass alle Beteiligten die Übersichtlichkeit ihrer Daten sel-
ber gestalten können. Damit verbunden, punktet auch die Eigenschaft Durchsuchbarkeit der
30Amazon Simple Storage Service
38
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
vorhandenen Informationen stark. Zum Einen existiert in den meisten Fällen eine Suche31.
Zum Anderen können die Daten in einer eigenen Struktur als Ordner im Dateisystem abgelegt
werden. Dies erleichtert die Suche nach bestimmten Daten massiv.
Eine weitere Stärke ist die Einfachheit. Die Lernkurve ist nur sehr gering. Die Nutzer müssen
nur wenig Zeit investieren, um die Bedienung und Nutzung zu verstehen, wenn sie schon mit
dem Dateimanager arbeiten können. Dies erhöht die Akzeptanz innerhalb eines Projektes.
Es existiert auch Software für Smartphones oder Tablets, damit Shared Storage im mobilen
Gebiet voll und ganz gewährleistet werden kann. Somit kann der Kommunikationskanal in der
Kategorie ortsunabhängige Erreichbarkeit fünf Punkte sammeln32.
Mittelmäßig ausgeprägt ist der Punktwert für die Historie. Es existiert in Dropbox zwar eine
Historie in vollem Umfang, aber nur mit Hilfe eines Extratools und Zusatzkosten (vgl. [Comb]).
Damit ist es dann möglich, Änderungen an Dateien bis zum Ursprung zurückzuverfolgen. Die
standardmäßig vorhandene Historie speichert Dateiabbilder lediglich für die letzten 30 Tage
(vgl. [Coma]). Damit können Dateien nicht komplett bis zu ihrem Ursprung rekonstruiert wer-
den.
Die Möglichkeit zur sozialen Interaktion ist nicht gegeben33. Die gemeinsame Informations-
generierung bekommt auch nur zwei Punkte. Informationen werden nicht wirklich generiert
und können auch nicht durch mehrere Mitarbeiter gleichzeitig geöffnet und bearbeitet werden.
Sie können nur nacheinander bearbeitet werden. Die gleichzeitige Dokumentbearbeitung durch
mehrere Nutzer ist also nicht möglich.
Shared Storage kann 41 von 60 Punkten bezogen auf alle Eigenschaften sammeln. Es ist ide-
al für die Langzeitspeicherung und den Austausch von Informationen nahezu aller Formate
geeignet und sollte in einem Projekt nicht fehlen. Die einfache Bedienung schafft eine hohe
Akzeptanz bei den Projektbeteiligten. Zudem können alle geteilten Informationen von überall
aus aufgerufen werden, wodurch die Projektmitarbeiter immer den aktuellen Informationsstand
haben.
Im Rahmen der Masterarbeit wird, wie schon erwähnt, die spezielle Lösung Dropbox einge-
setzt. Dadurch haben die Autoren einen gemeinsamen, synchronisierten Datenbestand. Es dient
ausschließlich dem Austausch und der Sammlung von Daten wie e-Books, Workspaces, Ab-
hängigkeiten in Bezug auf das Projekt und verschiedene Textdokumenten.
31Da zusätzlich Ordner auf der Fetsplatte liegt, kann hier mit allen Mitteln des Betriebssystems durchsucht undindiziert werden.
32Leichte Abstriche werden gemacht, da mobile Verträge meist auf ein bestimmtes monatliches Datenvolumenbegrenzt sind, was den Einsatz über das Mobilfunknetz erschwert.
33Die soziale Interaktion ist nicht der Fokus dieses Tools.
39
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 2.13.: Eigenschaftsmatrix des Shared Storages (Quelle: Eigene Darstellung)
2.8.11. Shared Notes (Autor: Christopher Ezell)
Shared Notes beschreibt eine Technik, welche es ermöglicht, private Notizen auf einen Ser-
ver abzuspeichern und von überall aus darauf zugreifen zu können. In der Praxis gibt es viele
Implementierungen dieser Technik. Ein sehr bekanntes Notizverwaltungstool ist SimpleNote.
Diese Spezialisierung wird im Anschluss näher betrachtet, da sie im Rahmen der Masterarbeit
eingesetzt wurde. Die einzelnen Implementierungen unterscheiden sich in ihrem Funktionsum-
fang sehr stark, was eine allgemeine Beschreibung dieser Technik nahezu unmöglich macht.
SimpleNote ein einfacher Weg Notizen, Listen, Ideen und vieles mehr abzuspeichern. Für den
Einsatz gibt es verschiedene Gründe: Notizen können von überall aus erreicht werden. Sie
werden mit dem Smartphone, Computer und jedem aktuellen Webbrowser synchronisiert. Die
Synchronisierung läuft komplett automatisch und sicher ab.
Notizen können veröffentlicht und geteilt werden. Das ist sehr sinnvoll, wenn Arbeitsgruppen
oder Gruppen bestehen, die das gleiche Ziel verfolgen, was in einer Firma oft der Fall ist. Die
Veröffentlichung von Meeting-Notizen innerhalb einer Firma sind ebenso vorstellbar.
Ein weiteres nützliches Feature ist die Historie. Es werden verschiedene Backups der Notizen
abgespeichert und der Nutzer kann einfach über einen Versionsslider in der Zeit zurück gehen.
Es steht genügend Speicherplatz für die Notizen auf dem Server bereit. Das Organisieren und
Sortieren der Notizen über Tags und Pins ist bei SimpleNote gut möglich. Durch das Setzen von
Tags können Notizen wie Ordner durchsucht werden. Das Setzen eines Pins für eine bestimmte
Notiz kann diese weit oben in der Notizliste anordnen. Daneben bietet SimpleNote eine Suche.
Nach Eingabe des Suchbegriffs wird die Liste von Notizen sofort aktualisiert, sodass nur noch
selten wichtige Gedanken oder Notizen verloren gehen.
40
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Eine nächste gute Eigenschaft ist die Erweiterbarkeit. SimpleNote ist eine offene Plattform, für
die eine Menge Programmierer Erweiterungen bereitstellen, um die Plattform an die eigenen
Bedürfnisse anzupassen.
Die Übertragung der Notizen bei der Synchronisation gilt als sicher, da die Notizen verschlüs-
selt übertragen werden. Die vorhandene API von SimpleNote ermöglicht eine einfache Inte-
gration dieses Dienstes in das eigene Projekt (vgl. [Sim12].
Zur besseren Übersicht der eben beschriebenen Features und Abschätzung des Nutzens wurde
eine Eigenschaftsmatrix erstellt (siehe Abbildung 2.14). Das Tool wird in die Kategorie der
Informationstools eingeteilt.
Als klare Stärke erweist sich die ortsunabhängige Erreichbarkeit, begründet durch die Plattfor-
munabhängigkeit und die optimierte Smartphoneintegration. Weitere Stärken sind die Historie,
die Einfachheit, die Übersichtlichkeit und die Durchsuchbarkeit der vorhandenen Informatio-
nen. Die Lernkurve ist sehr gerin, da ein Nutzer kaum Wissen benötigt, um ein Tool dieser
Technik zu bedienen. Die Übersichtlichkeit und Durchsuchbarkeit ist besonders durch das
Markieren der Notizen mit Pins und Tags sehr stark ausgeprägt. Das Tool besitzt eine Voll-
textsuche.
Die Langzeitspeicherung der Informationen ist ebenfalls eine Stärke. Die gemeinsame Infor-
mationsgenerierung ist nicht gegeben, da in der Regel ein Projektmitglied Notizen für sich
selbst abspeichert bzw. mit einer Gruppe teilt. Die Notizen werden dabei in der Regel alleine
erzeugt. Damit verbunden ist auch die gleichzeitige Dokumentbearbeitung kaum vorhanden.
Verschiedene Nutzer haben zwar die Möglichkeit Notizen untereinander zu verändern bzw. zu
ergänzen, aber arbeiten sie gleichzeitig an einem Notizdokument werden nur die Änderungen
eines Bearbeiters abgespeichert. Dabei handelt es sich um die Änderungen des letzten Spei-
chervorganges.
Die soziale Interaktion zwischen verschiedenen Projektmitarbeitern ist kaum möglich. Sie kön-
nen lediglich indirekt über die Notizen miteinander kommunizieren. Für diese Funktionalität
ist aber dieses Tool nicht vorgesehen. Die Eigenschaft des Informationsaustausches bekommt
auch nur wenige Punkte. Mittels dieses Tools werden lediglich Notizen in Textform ausge-
tauscht, die die Projektpartner informieren soll. An dieser Stelle eignen sich andere Tools
wesentlich besser, außerdem liegt der Fokus dieser Technik nicht in dem Bereich des Infor-
mationsaustausches.
Schlussfolgernd kann gesagt werden, dass sich diese Technik für bestimmte Zwecke in einem
Projekt sehr gut eignet. Besonders in verteilten Projekten ersetzt es den ortsgebundenen Notiz-
block und schafft eine gewisse Transparenz. Notizen haben in einem Projekt oft einen hohen
Stellenwert und sind nicht weg zu denken. Die Technik ist bereits sehr ausgefeilt und sicher zu
bedienen. Damit spricht nichts gegen den Einsatz in einem verteilten Projekt.
Im Rahmen der Masterarbeit wird SimpleNote genutzt. Da es eine API mitbringt, ist die Inte-
gration in das eigene Projekt sehr leicht möglich.
41
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 2.14.: Eigenschaftsmatrix der Shared Notes (Quelle: Eigene Darstellung)
2.8.12. Wiki (Autor: Rene Kassel)
Unter einem Wiki kann eine offene Sammlung von Webseiten bzw. Webinhalten verstanden
werden, welche von jeden Nutzer online problemlos und unkompliziert überarbeitet werden
können. Es bildet eine moderne Form eines Content-Management-Systems (CMS). Durch das
Aufkommen dieser Form ist es sogar für unerfahrene Nutzer leicht möglich Inhalte im World
Wide Web zu publizieren. Das Wiki besitzt eine einfache Syntax. Diese dient dazu, Texte les-
barer zu gestalten. Damit ist es einfacher zu schreiben als beispielsweise HTML (vgl. [Prz05]).
Es gibt unterschiedliche Implementierungen (Ausprägungen oder Varianten), die die Idee des
Wikis implementieren. Im Rahmen dieser Masterarbeit wurde sich für das MediaWiki entschie-
den.
Die neue Art des CMS hat sich in den letzten Jahren stark durchgesetzt und es hat sich ein
breites Feld an Einsatzmöglichkeiten etabliert. In den folgenden Gebieten wird es eingesetzt
(vgl. [Prz05]):
• in Installationsanleitungen, Handbüchern und FAQs,
• in technischen Dokumentationen,
• im Projektmanagement,
• in Projektbeschreibungen, Zeitplänen, Gesprächsprotokollen und Testergebnissen und
• in Link-Sammlungen, Notiz-Blöcken und ToDo-Listen.
42
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
Daneben gibt es noch weitere Einsatzmöglichkeiten. Diese Art von Informationssammlung hat
sich nicht nur im privaten Gebrauch durchgesetzt, sondern noch viel mehr im unternehmeri-
schen Anwendungsgebiet.
Ein Wiki als zentraler Wissensspeicher hat viele Vorteile für ein Projekt. Jeder Mitarbeiter34
kann Inhalte einsehen und verändern. Inhalte sind sofort nach dem Verfassen verfügbar und
lassen sich von anderen Nutzern abrufen. Gerade für den unternehmerischen Einsatz sollte die
Nutzergruppe eingeschränkt werden, die schreibenden Zugriff auf gewisse Inhalte hat. Dies ist
durch ein vorhandenes Rechtemanagement möglich. Ein weiterer Vorteil ist das gleichzeitige
Arbeiten an einem Wiki. Problematisch wird es erst dann, wenn mehrere Verfasser gleichzeitig
an einem Artikel arbeiten. Die vorhandene Versionsverwaltung ist ein weiteres positives Merk-
mal. Hier kann jede Änderung nachfolzogen werden, wann, was und von wem (vgl. [GLS10]
und [Hei08]).
Die Eigenschaftsmatrix ist in Abbildung 2.15 zu sehen. Die dargestellten Eigenschaften sind
jene aus den Informationstools, da das Wiki dort eingegliedert ist.
Die absoluten Stärken dieses Tools liegen in der Möglichkeit des Informationsaustausches,
der Übersichtlichkeit der vorhandenen Informationen, der Durchsuchbarkeit der Informatio-
nen sowie in der Nachvollziehbarkeit von Veränderungen (Historie). Jeder Nutzer kann sein
Wissen im Wiki verewigen und veröffentlichen, was ebenfalls eine sehr gute gemeinsame In-
formationsgenerierung ermöglicht. Es gibt die Möglichkeiten alle verfassten Artikel im Wiki
einzusehen. Über Inhaltsverzeichnisse können einzelne Artikel besser strukturiert und über-
schaubarer werden.
Defizite verzeichnet ein Wiki vor allem in den Eigenschaften der sozialen Interaktion sowie der
Langzeitspeicherung der Informationen. In einem Wiki sind gespeicherte Informationen stän-
digen Veränderungen ausgesetzt, was eine Langzeitspeicherung nicht gewährleistet. Direkte
Interaktionsmöglichkeiten in Echtzeit gibt es nicht.
Zudem ist es mittelmäßig gut für die gleichzeitige Bearbeitung geeignet. Zwar können vie-
le Nutzer gleichzeitig auf ein Wiki zugreifen, aber die gemeinschaftliche Arbeit an ein und
demselben Artikel wird nicht sonderlich gut unterstützt. Ändern mehrere Nutzer gleichzeitig
einen Artikel, dann werden nur die Änderungen eines Benutzers erfasst und gespeichert. Die
Modifizierungen anderer Nutzer gehen verloren. Es gibt kaum ein Wiki, das an die Echtzeitbe-
arbeitung eines Collaboration Pads heran kommt.
Die Lernkurve ist bei diesem Tool etwas höher als bei anderen. Dies hängt stark mit dem
Vorhandensein einer eigenen Syntax zusammen, welche durch den Nutzer vor der Verwendung
erlernt werden muss. Daraus resultieren lediglich die drei Punkte in der Einfachheit
Die ortsunabhängige Erreichbarkeit ist nur mittelmäßig erfüllt. Das Wiki kann von überall
aus durch das Internet mittels Webbrowser erreicht und verändert werden. Die Anpassungen
an Smartphones und Tablets sind eher suboptimal vorhanden. Die Einsicht in die Artikel ist
34mit Zugriff auf das Wiki
43
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
noch komfortabel möglich, jedoch ist die Bearbeitung eines Artikels über ein Smartphone nicht
nutzerfreundlich.
Abbildung 2.15.: Eigenschaftsmatrix des Wikis (Quelle: Eigene Darstellung)
Ein Wiki kann in vielen Bereichen stark punkten und ist ideal als Informationsspeicher und
Dokumentationsplattform geeignet. Dadurch ist es sinnvoll ein Wiki in verteilten Projekten
einzusetzen. Demzufolge ist es auch sehr gut für den Einsatz des Projektes der Masterarbeit
geeignet.
Der Dokumentationsaufwand war relativ hoch, bedingt durch die Komplexität der zu entwi-
ckelnden Anwendung und der vielen verwendeten Techniken. Dadurch bildete sich die Not-
wendigkeit eines zentralen Wissenspeichers. Dafür eignet sich ein Wiki sehr gut.
Die Vorteile sprechen für sich und die Nachteile tangieren das Projekt nur wenig, da das Tool
nur durch die beiden Autoren eingesetzt wird. Die Wahl fiel auf das MediaWiki, weil es den
vollen benötigten Funktionsumfang bietet und eine freie Softwarelösung ist. Der vielseitige
Einsatz des MediaWikis für alle durch die Wikimedia Foundation betriebenen Wikis ist eine
gute Referenz und hat zu dieser Wahl beigetragen [Wik07]. Dabei dient das Wiki im Rahmen
der Arbeit als Lager für Dokumentationen. Zum Teil ist es dafür vorgesehen, dass Projekt
zu planen und zu steuern. Das MediaWiki wurde zentral auf einem WebServer installiert. Im
Rahmen der Masterarbeit wurden zwei Benutzer angelegt, welche Inhalte generieren können.
Die Öffentlichkeit hat keinen Zugriff.
44
2.8. Die ausgewählten Kommunikationskanäle (Autoren: Rene Kassel und Christopher Ezell)
2.8.13. Weitere Tools und eigene Ideen (Autor: Rene Kassel)
Neben den bisher beschriebenen Kommunikationsmitteln existieren noch eine Menge ande-
rer Möglichkeiten zum Einsatz in einem Projekt. Die näher ausgewerteten Techniken zählen
zu den wichtigsten der neueren Techniken. Daneben werden noch die Techniken Audio-Chat,
Aufgabenverwaltung, Maildienst und Codeverwaltung eingesetzt. Diese Mittel werden durch
die Autoren als Standardtools in einem Projekt angesehen und werden nicht näher beschrieben.
Sie sind bereits existenzieller Bestandteil in einem Projekt und stellen keine neue Möglichkeit
dar. Der Verzicht auf diese Tools ist jedoch nicht zu denken, da sie wichtige Aufgaben in der
Projekterfüllung besitzen.
Eine eigene Idee erschließt sich aus dem Kapitel 2.7 über Gamification. Einige Komponen-
ten des Gamification-Ansatzes sollten in der Plattform enthalten sein. Die Integration solcher
Bestandteile kann die Mitarbeiter motivieren den sozialen Kontakt zueinander aufrecht zu er-
halten und die soziale Bindung zu stärken. In dem Artikel Virtuelle Welten als soziale Räumeerläutert die Bundesprüfstelle für jugendgefährdende Medien, dass die Interaktion mit anderen
Menschen in einer virtuellen Umgebung und der Austausch von Informationen zu einer hö-
heren sozialen Bindung führen kann (vgl. [Bun12]). Die Vermischung einiger Komponenten
dieses Ansatzes mit einer derartigen Plattform, die im Rahmen der Masterarbeit umgesetzt
werden soll, könnte einen großen Mehrwert bieten und vor allem die Nutzung der verschiede-
nen Möglichkeiten steigern.
2.8.14. Überblick über die Projektplattform (Autor: Rene Kassel)
Nachdem die vorherigen Kapitel einen Überblick über die vorhandenen Kommunikationsmittel
geben, wird nun ein grober Überblick über die resultierende Projektplattform gegeben. Dabei
handelt es sich um eine kurze Zusammenfassung der einzelnen Mittel. Zur besseren Übersicht
werden die einzelnen Techniken und Tools in der Tabelle 2.8.14 zusammengeführt. Es wird
kurz und prägnant darauf eingegangen, ob die Technik für die Plattform verwendet wird, ob
eine Eigenimplementierung vorgenommen wird und ob eine Integration für das Smartphone
stattfindet.
Legende:
V - Verwendung
E - Eigenimplementation
S - Smartphone-Integration
45
2.9. Zusammenfassung (Autor: Christopher Ezell)
Name V E S
Collaboration Pad Ja Nein Nein
Wiki Ja Nein Nein
Mobile Instant Messaging Ja Nein Ja
Remote Pair Programming Ja Nein Nein
Blog Ja Nein Nein
Microblogging Ja Ja Ja
Social Bookmarking Ja Nein Ja
Standortbezogene soziale Netzwerke Ja Ja Ja
Aufgabenverwaltung Ja Ja Ja
Shared Storage Ja Nein Nein
Shared Notes Ja Nein Ja
Mail Ja Nein Nein
Codeverwaltung Ja Nein Nein
Screen Sharing Ja Nein Nein
Audio-Chat Ja Nein Nein
Im Prototyp der Anwendung werden alle diese Techniken genutzt. Es ist nicht notwendig so
ein Spektrum an Tools und Techniken zu verwenden. Das hängt stark davon ab, wie viele In-
formationen ausgetauscht werden sollen und welche Informationen für ein bestimmtes Projekt
relevant sind. Oftmals werden bestimmte Funktionalitäten von mehreren Techniken abgedeckt,
dann liegt es im Ermessen des Nutzers, welche er nutzt. Das breite Spektrum an Techniken
wurde vorrgestellt, um den Lesern einen vielumfassenden Überblick zu geben und eine bessere
Einschätzung beim Selbsttest der Kommunikationsmittel vorzunehmen.
Resultierend aus den vorhergehenden Betrachtungen und der dabei entstandenen Liste von
Kommunikationstools werden im nächsten Kapitel die verschiedenen User Stories definiert.
Diese beschreiben die Funktionalitäten, die die zu implementierende Plattform enthalten soll.
2.9. Zusammenfassung (Autor: Christopher Ezell)
In diesem Kapitel wurde die Kommunikation innerhalb von verteilten Teams erläutert. Es wur-
den Informationsarten und die Einteilung von bestimmten Kommunikationstools gezeigt. Des
Weiteren wurde aufgezeigt, dass auch zwischenmenschliche Faktoren zu den Erfolgsfakto-
ren eines Teams zählen. Bezogen auf diese Faktoren wurden anhand von Studien Probleme
beschrieben, die innerhalb eines Projektes zwischen verschiedenen Mitarbeitern aufkommen
können mit besonderer Berücksichtigung auf verteilte Projektgruppen. Es wurde gezeigt, wie
wichtig die Kommunikation in Projekten ist. Zudem wurde ersichtlich, dass bestehende Soft-
warelösungen für verteiltes Arbeiten nicht ausreichend Funktionsumfang bieten, um den kom-
pletten Anforderungen an einem verteilten Projektteam gerecht zu werden. Weiterhin wurde
46
2.9. Zusammenfassung (Autor: Christopher Ezell)
auf die Thematik der Gamification eingegangen und gezeigt, dass auch mit spielerischen Ele-
menten positiv auf die Motivation von Teammitgliedern eingewirkt werden kann. Am Ende
dieses Kapitels erfolgte eine genaue Betrachtung und Analyse ausgewählter Kommunikations-
kanäle. Aus dieser Analyse heraus entstand eine Liste von Kommunikationsmitteln, welche in
einem verteilten, agilen Projekt als wichtig erachtet werden. Alle bisherigen Überlegungen, in-
klusive der entstandenen Liste, sind die Basis für diese Ausarbeitung und sind ausschlaggebend
für die darin realisierten Ideen.
Für das Verständnis der Umsetzung einer solchen Lösung sind jedoch einige grundlegende
Sachverhalte zu erläutern, besonders technische Grundlagen. Diese werden im nächsten Kapi-
tel (Kapitel 3) behandelt.
47
3. Grundlagen (Autoren: Christopher Ezell und Rene Kassel)
3. Grundlagen (Autoren: Christopher Ezell und Rene Kassel)
Nachdem die grundlegenden Ideen und Ziele der Arbeit in den vorherigen Kapiteln festgelegt
wurden, behandelt dieses Kapitel nun die Grundlagen. Sie sind nötig, um den weiteren Ver-
lauf dieser Arbeit zu verstehen. Zunächst werden im ersten Unterkapitel die Grundlagen der
agilen Softwareentwicklung kurz angerissen, um den Nutzen der Arbeit besser zu verstehen.
Die nachfolgenden Unterkapitel geben dem Leser das nötige Rüstzeug, die weitere Arbeit im
technischen Sinne verfolgen zu können. Kapitel 3.2 zeigt eine allgemeine Übersicht zu den
verwendeten Basistechnologien. Im darauffolgenden Kapitel 3.3 werden dem Leser Grundla-
gen zu iOS und Objective-C näher gebracht. Kapitel 3.4 behandelt die Grundlagen einzelner
Möglichkeiten zur Verbesserung der Qualität des geschriebenen Codes. Im letzten Unterkapitel
3.5 wird ein grundlegendes Verständnis für die Verwendung der Build-Plattform übermittelt.
3.1. Agile Softwareentwicklung (Autor: Christopher Ezell)
Die Umsetzung der vorliegenden Masterarbeit orientiert sich an Praktiken der agilen Softwa-
reentwicklung35. Aus diesem Grund werden kurz die Arbeitsweise, die Grundwerte und eini-
ge Basistechniken beschrieben. Zunächst ist es wichtig, ein Verständnis dafür zu entwickeln,
warum es gerade in agilen Teams sehr wichtig ist, immer mit den anderen Teammitgliedern
den Kontakt zu halten. Daher werden am Anfang die agilen Prinzipien und die Philosophie
hinter dem agilen Gedanken erklärt, um danach auf die Anforderungen von einem agilen Team
einzugehen. Zuletzt wird noch kurz auf die Arbeitsweise bei Scrum eingegangen.
3.1.1. Agiles Manifest
Der Grundpfeiler der agilen Softwareentwicklung ist das agile Manifest. Es ist im Jahre 2001
entstanden und definiert, was unter dem Begriff agil zu verstehen ist (vgl. [et.12]). Es stellt die
Grundideen hinter der Praxis der agilen Softwareentwicklung dar und definiert Grundwerte,
die immer eingehalten werden sollten.
Manifest für die agile Softwareentwicklung
• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
• Lauffähige Software ist wichtiger als umfangreiche Dokumentation.
35In [agi09] findet sich eine Beschreibung warum agile Praktiken gut sind.
48
3.1. Agile Softwareentwicklung (Autor: Christopher Ezell)
• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
• Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.
Diese Grundwerte des agilen Entwicklungsprozesses machen deutlich, wie wichtig die Men-
schen in einem agilen Team sind. Es wird sehr viel Wert auf direkte Kommunikation gelegt und
das Individuum über Prozesse und Werkzeuge gestellt. Ein Kommunikations- und Kollabora-
tionstool muss diesen Anforderungen genügen und muss sehr leicht und intuitiv zu bedienen
sein. Dies wurde bei der Konzeption der Plattform berücksichtigt.
3.1.2. User Stories
Eine User Story, auch als Anwendererzählung bezeichnet, ist eine in Alltagssprache definierte
Beschreibung von Funktionalitäten einer Software. Die Erfüllung der Software einer User Story
stellt dabei einen Mehrwert für den Benutzer oder Käufer einer Software dar. Der grundlegen-
de Aufbau einer User Story ist generell festgelegt und sieht folgendermaßen aus: Als <Rolle>
möchte ich <Ziel/Wunsch>, um <Nutzen>. Ein sehr wichtiger Bestandteil von User Stories
sind die Aktzeptanzkriterien36 (vgl. [CHH10]). Diese werden von anderen Autoren auch Er-
wartungen genannt (vgl. [Coh04]). Diese beschreiben im Allgemeinen zusätzliche Rahmenbe-
dingungen und Spezialfälle, die es dem Entwickler ermöglichen Tests zu schreiben.
William Wake erstellte 2003 in seinem Blog-Post INVEST in Good Stories, and SMART Tasks
[inv03] die INVEST-Kriterien37 für gute User Stories. Diese Kriterien müssen User Stories
erfüllen, um optimal umgesetzt werden zu können. Diese sind die folgenden:
• I – Independent (unabhängig): Es sollten möglichst keine Abhängigkeiten zwischen
den User Stories geben.
• N – Negotiable (verhandelbar): User Stories sollten schriftliche Verträge oder Anfor-
derungen sein, die die Software erfüllen muss.
• V – Valuable (werthaltig): Jede User Story sollte für den Kunden einen Mehrwert für
die Anwendung darstellen.
• E – Estimable (schätzbar): Die User Story sollte so erstellt worden sein, dass sie für
den Entwickler schätzbar ist.
• S – Small (klein): Die richtige Größe von User Stories erhöht die Planbarkeit ihrer Um-
setzung.
• T – Testable (testbar): User Stories müssen so geschrieben sein, dass durch einen Test
verifizierbar ist, ob die Story erfolgreich implementiert wurde (vgl. [CHH10]).
Die Autoren haben ihre User Stories aus Kapitel 4 daran orientiert.
36auch Conditions of Satisfaction (COS) genannt37Independent, Negotiable, Valuable, Estimable, Small, Testable
49
3.1. Agile Softwareentwicklung (Autor: Christopher Ezell)
3.1.3. Scrum
Hier wird auf das agile Management-Framework Scrum eingegangen. Scrum dient als Grund-
lage für die Entwicklung dieser Plattform und die definierten Prozesse haben die Autoren zum
Verwalten des Projektes genutzt.
Definition Scrum
„Das agile Management-Framework Scrum stellt heute den bekanntesten agilen Ver-
treter dar, weil es durch seine einfache Struktur und die klar definierten Rollen schnell
verständlich ist und sich produktiv einsetzen lässt.“ [HW11]
In Scrum wird innerhalb eines Teams täglich ein Meeting zu einem festen Zeitpunkt gehalten.
Dies ist das sogenannte Daily Scrum. Dieses Meeting dient zur Interaktion und Synchronisati-
on im Team. Es teilt sich generell in zwei Teile. Der erste Teil besteht aus einem festen Ablauf,
den jeder im Team durchläuft. Er besteht laut [HW11] aus der Beantwortung der folgenden
Fragen:
• Was habe ich seit dem letzten Daily Scrum getan?
• Was hat mich davon abgehalten?
• Was werde ich bis zum nächsten Daily Scrum tun?
Hier können sich Fragen und Diskussionen ergeben. Diese sind gewollt und wichtig und kom-
men im zweiten Teil des Meetings zum Tragen, dem sogenannten Offline-Teil. Hier können
nun alle ihre Probleme und Neuigkeiten erzählen und es kann diskutiert werden. Trotzdem
sollte ein Daily Scrum insgesamt nicht länger als 15 Minuten dauern.
Scrum definiert feste Rollen, die im Team besetzt werden müssen. Diese verschiedenen Rollen
haben verschiedene Aufgaben zu erfüllen. Eine Übersicht über Scrum findet sich in Abbildung
3.1. Die verschiedenen Rollen sind nach ([Pic07], S.13) folgende:
• Product Owner (PO): Der Product Owner in Scrum repräsentiert die Endkundenbedürf-
nisse, steuert die Softwareentwicklung und arbeitet mit dem Team über den gesamten
Projektverlauf eng zusammen.
• Scrum Master (SM): Der Scrum Master agiert als Coach und Change Agent. Er hilft
dem Team und dem Unternehmen Scrum richtig einzusetzen.
• Team: Das Team führt alle Arbeiten aus, die zur Umsetzung der Anforderungen in aus-
lieferbare Produktinkremente notwendig sind.
Die Arbeitseinheit, in denen Scrum-Teams arbeiten, nennen sich Sprints38. Die Abbildung 3.1
zeigt, dass ein Sprint innerhalb eines Teams und Projekts immer die gleiche Dauer von ein bis
38Manchmal werden Sprints auch Iterationen genannt (vgl. [Pic07], S.81).
50
3.1. Agile Softwareentwicklung (Autor: Christopher Ezell)
Abbildung 3.1.: Scrum auf einem Blick (Quelle: [HW11], Seite 7)
vier Wochen haben sollte. Generell sollten alle Aktivitäten, welche in einem Scrum-Team er-
ledigt werden, sich in einem definierten Sprint befinden. Um einen Scrum gut durchführen zu
können, muss ein Team selbstorganisiert sein. Selbstorganisierte Teams sind Teams, die keine
Hierachien enthalten, die den Fluss an Information behindern. Ein Team ist nicht selbstorgani-
siert, wenn z.B. alle Aktivitäten vorher mit einem Teammitglied abgestimmt werden müssen.
Ein Team muss sich in den Grenzen ihrer Programmierung frei bewegen können und selbst
entscheiden wie sie eine Aufgabe lösen.
Eine Möglichkeit in Scrum Aufwände zu schätzen stellt das Planning-Poker dar. Planning-
Poker wird von James Grenning in ([Gre], S.1) wie folgt beschrieben:
Definition Planning-Poker
„The mechanics of planning poker are simple. The customer reads a story. There is a
discussion clarifying the story as necessary. Each programmer writes their estimate on
a note card without discussing their estimate. Anticipation builds. Once all program-
mers have written their estimate, turn over all the cards. If there is agreement, great, no
discussion is necessary, record the estimate and move on to the next story.“
Planning-Poker definiert ein Schätzverfahren, in dem die Komplexität einer Aufgabe mit Punk-
ten bewertet wird. Es soll durch den Ablauf für eine Diskussion sorgen, die alle Beteiligten zu
einem besserem Verständnis der Aufgabe führen soll. Der Ablauf ist der folgende. Das Ent-
wicklerteam und der Kunde sitzen zusammen an einem Tisch. Nun liest der Kunde eine User
Story laut vor. Nachdem alle verstanden haben worum es geht, werden Karten verteilt. Jede
der Karten hat eine Nummer aufgedruckt. Diese haben aufsteigende Werte wie zum Beispiel
1, 2, 4, 8, 20, 100. Welche Komplexität zu welchem Wert gehört, kann das jeweilige Team
51
3.1. Agile Softwareentwicklung (Autor: Christopher Ezell)
entscheiden. Fest steht nur, dass die niedrigen Werte für niedrige Komplexität und die hohen
für hohe stehen. Wichtig ist, dass die höheren Zahlen in ihrer Wertigkeit weit auseinander lie-
gen39. Jedes Teammitglied hat dieselbe Anzahl und Wertigkeiten von Karten. Es kann nun von
jedem selbstständig die Komplexität der vorgelesenen Story eingeschätzt werden. Wenn dies
geschehen ist, legen alle die vorher verdeckten Karten gleichzeitig auf den Tisch. Nun werden
mit einer hohen Wahrscheinlichkeit einige Mitglieder andere Werte haben als andere. Es wird
nun der (oder die) ermittelt, der den niedrigsten und der, der den höchsten Wert hat. Diese müs-
sen jetzt diskutieren, warum ihre Meinung richtig ist. Hier entsteht nun ein Gespräch, bei dem
Kontextinformationen und Fallstricke zu tage kommen. Dies ist sehr wichtig für alle im Team
und hat so einen Mehrwert. Das befähigt wiederum die Mitglieder, eine bessere Schätzung als
vorher abzugeben. Nun wird die Runde wiederholt und es werden wieder Karten neu von je-
dem gelegt. Dies passiert, bis alle denselben Wert legen. Damit sich alle über die Komplexität
der Aufgabe einig sind (vgl. [Gre]).
3.1.4. Verteilte agile Teams
Scrum an sich definiert keine Verteilung der Leute. Es sagt nichts darüber aus, ob die Team-
Mitglieder alle an einem Standort sind oder verteilt. Aber durch die definierten Prozesse ist es
sehr schwer, dies ohne viel Mühe in eine verteilte Umgebung zu etablieren40. Trotzdem ist es
die Grundidee vieler agiler Ansätze, das sich alle an einem Standort zum arbeiten Treffen. Nur
dadurch ist es möglich das volle Potential der agilen Entwicklung auszuschöpfen. In größeren
und komplexeren Projekten ist dies nicht immer möglich, vor allem dann, wenn der Kunde
und das Team lokal weiträumig organisiert sind. Nur wenige Projekte werden noch an einem
Standort entwickelt (vgl. [Eck09], S.1).
In verteilten, agilen Teams ist es durch die Distanz sehr viel schwieriger einen einheitlichen
Rhythmus und einen Release-Termin zu kommunizieren und durchzuführen. Die Koordination
der Arbeit in einem verteilten, agilen Team ist eine große Aufgabe. Das steht im engen Zusam-
menhang damit, dass im Allgemeinen agile Softwareentwicklung sehr kommunikationsintensiv
ist. Vertrauen innerhalb des Teams ist ein entscheidender Erfolgsfaktor.
Es sollte definiert werden, was in einem verteiltem Team die grundlegenden Eigenschaften sein
sollen und diese versuchen durch meist technische Lösungen zu erhalten. Die Schaffung eines
vertrauensvollen Klimas in einer verteilten Umgebung ist eines der schwierigsten Teile. Es sol-
len alle Teammitglieder miteinander interagieren, besonders jene, die sich an unterschiedlichen
Standorten befinden. Oft ist es jedoch so, dass eine selektierte Kommunikation mit den Mit-
arbeitern desselben Standortes und nur selten eine größere Kommunikation mit den entfernen
Mitarbeitern stattfindet. Dieses Problem gibt es also zu lösen.
39dies Spiegelt die Tatsache wieder, dass kleine Aufwände mit den unteren Zahlen besser geschätzt werden könnenals große. Hier sollte es deswegen nur grobe Werte geben.
40siehe [Eck09]
52
3.2. Technologien (Autor: Rene Kassel)
3.2. Technologien (Autor: Rene Kassel)
Nachdem die Grundlagen der agilen Softwareentwicklung erläutert wurden, wird nun auf die
im Projekt verwendeten Techniken näher eingegangen. Dabei wird sich auf ausgewählte Tech-
niken beschränkt. Nicht betrachtet werden zum Beispiel Java-Grundlagen, da dies sehr umfang-
reich zu den Lehrinhalten vieler Fachhochschulen und Universitäten gehört. Genauer betrachtet
werden jedoch die Grundlagen von iOS- und Objective-C -bezogenen Themen. Dies ist darauf
begründet, dass an vielen Hochschulen Objective-C nicht Lehrgegenstand der Vorlesungen ist
und daher nicht von Lesern dieser Arbeit vorausgesetzt wird.
3.2.1. Extensible Markup Language
Die Extensible Markup Language (XML) ist eine erweiterbare Auszeichnungssprache zur Be-
schreibung von Dokumenten. XML wurde ursprünglich entwickelt, um der neuen Herausfor-
derung des vermehrten elektronischen Publizierens gerecht zu werden. Im Verlauf der Zeit
hat es eine immer bedeutendere Rolle beim Austausch einer Vielzahl von Daten im Web und
zwischen Computersystemen eingenommen. Genau gesagt, handelt es sich bei XML um ein
einfaches, sehr flexibles Textformat, welches aus SGML41 (ISO 8879) abgeleitet wurde und
Daten beschreibt (vgl. [W3C03]). Das W3C42 hat es im Jahr 1998 erstmals genauer spezifi-
ziert. Die neueste Auflage ist im Jahr 2008 entstanden und beschreibt XML sehr detailliert
(vgl. [W3C08]).
Bei XML werden die Daten mit Hilfe von Tags beschrieben. Diese Tags sind nicht vordefiniert,
es können eigene Tags definiert werden. Daher stammt der Name Extensible. Das wichtigste
bei XML sind die XML-Elemente. Ein solches Element besteht immer aus einem öffnenden
Tag, dem Inhalt und dem schließenden Tag.
Die Struktur einer XML-Datei kann durch ein Schema definiert werden. Ein XML-Schema ist
die Definition von Regeln (vgl. [MS07] Seite 17), die die erlaubten Daten und die Struktur
einer XML-Datei einschränken können. Es ist möglich eine XML-Datei mit einem Schema
zu validieren. Hierdurch kann ermittelt werden, ob eine XML-Datei einem Schema entspricht
(vgl. [MS07], Seite 17).
41Standard Generalized Markup Language42World Wide Web Consortium
53
3.2. Technologien (Autor: Rene Kassel)
Das Beispiel 3.1 zeigt die allgemeine Struktur eines XML-Dokumentes.
Listing 3.1: Beispiel für XML
1 <telefonbucheintraege>
2 <titel>Telefonbuch</titel>
3 <beitrag>
4 <name>Max Mustermann</name>
5 <nummer>12345698765</nummer>
6 </beitrag>
7 <beitrag>
8 <name>Frida Frau</name>
9 <nummer>05456798765</nummer>
10 </beitrag>
11 </telefonbucheintraege>
Die erste Zeile ist eine XML-Deklaration. Der Knoten
<telefonbucheintraege> beschreibt das Wurzelelement. Die nächsten Elemente
<titel> und <telefonbucheintraege> sind die Kind-Elemente und sind dem Wur-
zelelement untergeordnet. Das Element <telefonbucheintraege> hat mehrere Kindele-
mente vom Typ <beitrag> und eins vom Typ <titel> haben. Das Element <beitrag>
kann wiederum <name> und <nummer> enthalten. Hieran wird sehr gut deutlich, dass es sich
um eine Baumstruktur handelt. Die Daten werden flexibel mit Hilfe dieser Tags beschrieben.
Sie sind beliebig erweiterbar.
3.2.2. Java Architecture for XML Binding
Die Java Architecture for XML Binding (JAXB) ermöglicht es dem Java Entwickler optimal mit
XML interagieren zu lassen. Es definiert eine API43 zur Transformation von XML-Objekten
zu Java-Objekten und umgekehrt. JAXB hat den Anspruch eine API zu bieten, die weit ab-
strakter und komfortabler ist als sie bei SAX44 und DOM45 möglich ist (vgl. [MS07]). Die
Architektur von JAXB 2.0 ist im Anhang A.4 dargestellt. Sie zeigt die Hauptkomponenten von
JAXB. Diese sind das XML-Schema, welches die Struktur der Daten enthält und die PortableJava Beans, welche die mit JAXB-Annotationen versehenen Java-Klassen sind. Diese wurden
aus der XML-Schema-Datei generiert. Wie in der Abbildung zu sehen ist, passiert dies nicht
zur Laufzeit, sondern zur Zeit des Compilierens. Die Hauptkomponente, die zur Laufzeit eine
zentrale Rolle spielt, ist das Binding Framework. Dieses nutzt die Portable Java Beans und
eine dem Schema konforme XML, um daraus Instanzen dieser Java Beans zu erzeugen46. Das
43Application Programming Interface44Simple API for XML45Document Object Model46Die Abbildungen A.5 und A.8 stellen diesen Prozess der Schema-Kompilierung nochmal im Detail dar.
54
3.2. Technologien (Autor: Rene Kassel)
stellt die zugrunde liegende XML in Form von Java Klassen dar (vgl. [MS07], Seite 6). JAXB
2.0 stellt also eine gute Transformationsmöglichkeit zwichen XML und Java dar.
3.2.3. Really Simple Syndication
Really Simple Syndication (RSS) ist eine Verbreitungstechnik von Inhalten im Internet. Sie
basiert auf XML und eignet sich sehr gut zum Publizieren von Informationen aller Art. Die
Spezifikation kann auf http://www.rssboard.org/rss-specification gefunden
werden. Die Idee hinter RSS ist eine Art Kanal von Nachrichten. Dieser Kanal hat mehrere
Einträge. Der Kanal wird von Client in regelmäßigen Intervallen gelesen. Es ist also ein pull-
Verfahren, da der Client aktiv die Informationen holen muss.
3.2.4. JavaScript Object Notation
Die JavaScript Object Notation (JSON) ist ein schlankes, textbasierte Format für den Daten-
austausch zwischen IT-Systemen. Es wurde 2006 von Douglas Crockford im RFC47 4627
beschrieben (vgl. [Gro06]). Es ist relativ einfach zu lesen und durch die Maschine leicht zu
interpretieren. Es ist eine Teilmenge der JavaScript Programmiersprache48. Eine wichtige Ei-
genschaft von JSON ist, dass es komplett sprachunabhängig ist. Viele Sprachen bringen bereits
nötige Frameworks mit, um JSON-Objekte zu interpretieren und in die eigene Struktur umzu-
wandeln. Damit ist es ideal für den Austausch von Daten zwischen verschiedenen Sprachen
geeignet (vgl. [Jso]).
JSON kann vier primitive Datentypen und zwei strukturierte Datentypen repräsentieren. Erstere
können Zeichenketten (Strings), Zahlen (Numbers), boolesche Werte (Booleans) oder
Nullwerte (Null) sein. Zweitere sind Objekte und Arrays. Ein Objekt ist eine ungeordnete Zu-
sammenfassung von null oder mehreren Name/Wert-Paaren. Der Name ist eine Zeichenkette
und der Wert kann ein primitiver Datentyp oder ein Array sein. Ein Array ist eine geordnete
Aufeinanderfolge von null oder mehr Werten. Die Bezeichnungen Objekt und Array kom-
men von den Konventionen von JavaScript. Ein Array ist mit den Zeichen [] umschlossen.
Ein Objekt wird durch geschweifte Klammern abgegrenzt.
47Request for Comments48Es ist speziell definiert in dem Programmierstandard ECMA (European Computer Manufacturers Association)
der dritten Generation.
55
3.2. Technologien (Autor: Rene Kassel)
Das folgende Beispiel 3.2 zeigt ein Array mit zwei Objekten.
Listing 3.2: Beispiel für JSON (Quelle: [Gro06])
1 [
2 {
3 "Latitude": 37.7668, "Longitude": -122.3959,
4 "City": "SAN FRANCISCO", "Country": "US"
5 }, {
6 "Latitude": 37.371991, "Longitude": -122.026020,
7 "City": "SUNNYVALE", "Country": "US"
8 }
9 ]
Im Gegensatz zu XML ist JSON wesentlich überschaubarer und leichter lesbar durch den Men-
schen. Zudem weist es weniger Redundanzen als XML auf. Dadurch nimmt diese Struktur
weniger Speicherplatz ein. Ein weiterer Vorteil besteht im Parsen von JSON-Objekten. Dies
kann mit sehr wenig Programmieraufwand erfolgen. Bei XML im Gegensatz ist ein wesentlich
höherer Aufwand notwendig. Die Navigation in einen JSON-Objekt ist wesentlich schmaler
und einfacher als jene in einer XML-Struktur. JSON unterstützt jedoch nur einige grundlegen-
de Datentypen. XML hingegen weist mehr Flexibilität bezüglich der Typen auf. Für einfache
Fälle des Datenaustausches ist jedoch JSON durch seine Einfachheit und seinen geringeren
Aufwand vorzuziehen (vgl. [Kel06]).
3.2.5. Representational State Transfer
Representational State Transfer (REST) ist ein Programmierparadigma für Webanwendungen.
Es definiert eine Art und Weise wie auf Objekte über das Web zugegriffen werden kann. Erfun-
den wurde der Begriff REST von Roy T. Fielding49. Für diese Art von Zugriff auf Ressourcen
im Web erfand er diesen Begriff für seine Dissertation (vgl. [Fie00]). Der Zugriff geschieht
bei REST über URLs50, die mittels einer Anfrage über das Hypertext Transfer Protocol, kurz
HTTP51, aufgerufen und übertragen werden. Das Ziel ist die Struktur und Funktionsweise des
Web zu nutzen, um moderne Applikation von dieser Funktionsweise profitieren zu lassen. Ein
Vorteil von REST ist, dass auf etablierte Standards, wie z.B. die HTTP-Statuscodes, zurück-
gegriffen werden kann. Dies wird von vielen Anwendungen bereits unterstützt und muss nicht
selber programmiert werden.
Die Statuscodes können bei der Verwendung von REST zur Kommunikation zwischen Cli-
ent und Server genutzt werden. Um REST besser zu verstehen, werden im folgenden die fünf
49Er zählt zu den Kernentwicklern einer hohen Zahl von Webstandards. Er gehört zu den ehemaligen Vorsitzendender Apache Software Foundation.
50Uniform Resource Locator51Das HTTP-Protokoll wird definiert im RFC 2616 (vgl. [Fie99a]).
56
3.2. Technologien (Autor: Rene Kassel)
Kernprinzipien einer REST-Architektur aufgelistet und anschließend näher erläutert. Auf die
beiden Aspekte der Unterschiedlichen Repräsentationen und Statuslosen Kommunkation wird
nicht weiter eingegangen, da diese für die Arbeit nicht wichtig sind. Sie sollten nur der Voll-
ständigkeit halber genannt werden. Die fünf Kernprinzipien von REST sind nach [Til11]:
• Ressourcen mit eindeutiger Identifikation,
• Verknüpfungen/Hypermedia,
• Standardmethoden (für die Interaktion),
• Unterschiedliche Repräsentationen und
• Statuslose Kommunkation.
Der erste Punkt Ressourcen mit eindeutiger Identifikation ist die Basis einer REST-Anwendung.
Die Idee dahinter ist, dass jede Anwendung ein Set an Ressourcen besitzt, was die Basis für al-
le Anderen bildet52. Diese werden auch Kernkomponenten genannt. Kernkomponenten sind in
einer REST-Anwendung über eine eindeutige URL verfügbar. Daraus folgt, dass jedes Objekt
einer Kernkomponente eine ID hat, mit der sie referenziert werden kann. Dies ist bei REST die
URL. Das Listing 3.3 zeigt ein Beispiel hierfür. Dort gibt es eine Klasse von Kernkomponenten
mit dem Namen users und events. Alle Objekte einer Klasse von Kernkomponenten werden
unter einem Knoten zusammengefasst. Der Knoten events fasst alle event-Objekte zusammen.
Wird nun lesend die erste URL des Listings abgefragt, wird eine Liste aller User zurück ge-
geben. Dies ist so, da der Wurzelknoten aller User aufgerufen wird und dieser alle darunter
liegenden Knoten vom Typ User bekommt. Hingegen repräsentiert die zweite URL nur einen
einzelnen User. Wird also diese URL aufgerufen, wird nur dieser eine User (vgl. [Til11]) zu-
rückgegeben. Die dritte URL ruft alle Events zu dem übergebenen Datum auf.
Bei dem Punkt Verknüpfungen/Hypermedia geht es darum, dass durch die eindeutige Referen-
zierbarkeit der Objekte auf diese von anderen Knoten aus verwiesen werden kann. So ist es
möglich sehr elegant Daten innerhalb einer REST-Domäne zu verbinden. Wenn ein Event zum
Beispiel einem User zugeordnet ist, muss in dem Event nur die URL des Users angegeben wer-
den. Wenn ein Client, der das Event aufruft, mehr über den User erfahren will, kann er einfach
den Knoten des Users abfragen.
Listing 3.3: Beispiel für URLs bei REST
1 http://example.com/users/
2 http://example.com/users/1234
3 http://example.com/events/2012/12/24
Durch die Standardmethoden erhält das REST-Modell seine Dynamik. Sie definieren die Inter-
aktionsmöglichkeiten, die mit REST möglich sind. Diese werden bei REST Verben genannt.
Es gibt zur Zeit die Verben GET, PUT, POST, DELETE, OPTIONS, TRACE und CONNECT.
52In einem Warenlager sind das zum Beispiel die Lager und die Waren.
57
3.2. Technologien (Autor: Rene Kassel)
Bei GET handelt es sich um eine der grundlegenden und wichtigsten Verben. Es dient dazu, die
Informationen hinter der Ressource in einer Repräsentationsform abzufragen53. Laut den Prin-
zipien von REST, ist die GET-Operation als safe deklariert. Es werden also Serverseitig keine
Informationen der Ressource bei diesem Aufruf verändert. Im Gegensatz zu GET gilt PUT als
nicht safe, da dieses Verb die Aufgabe besitzt, den Server zu veranlassen, die referenzierte
Ressource zu aktualisieren. Ist die Ressource noch nicht vorhanden, dann wird sie über dieses
Verb erzeugt. Die Daten hierfür werden im Contentbereich, den sogenannten Entity Body, der
HTTP-Anfrage, gesendet. POST ist ein Verb mit zwei Bedeutungen. Auf der einen Seite wird
bei einem derartigen Aufruf eine neue Ressource unter einer vom Server bestimmten URI54
angelegt. Auf der anderen Seite wird es dann eingesetzt, wenn keine andere Methode passt.
Damit bietet POST eine zweite Möglichkeit, neue Ressourcen anzulegen. Jedoch handelt es
sich bei dieser zweiten Möglichkeit um ein Standardmuster zum Neuanlegen einer Ressource,
wofür auch ein HTTP-Statuscode existiert55. Das nächste wichtige Verb ist DELETE. Dies ist
für das Löschen einer Ressource zuständig. Es wird jene Ressource gelöscht, deren URI im
Request angegeben wird (vgl. [Til11]).
Auf die Verben Options, Trace und Connect wird hier nicht näher eingegangen.
Ein sehr mächtiges Kommunikationsmittel in der Welt von REST sind die im HTTP-Standard
definierten Statuscodes (vgl. [Fie99b]). Statuscodes sind Nummern zwischen 100 und 505, die
der Server als Antwort auf eine Anfrage des Clients zurücksenden kann. Hinter jedem dieser
Codes ist eine Aussage über den Zustand des Servers zu der Anfrage definiert. Diese Zustände
sind in fünf große Blöcke unterteilt.
Block eins (Codes zwischen 100 und 199) umfasst die Codes mit dem Marker Informational.
Das bedeutet, dies sind Codes um den Client zusätzliche Informationen zu geben. Ein Beispiel
dafür ist der Code 100 - Continue. Dieser signalisiert dem Client, dass sein Request noch nicht
vollständig ist und der Server eine Fortsetzung erwartet.
Der zweite Block beginnt bei 200 und endet bei 299. Dieser Block definiert Codes, die Aus-
kunft darüber geben, ob die Clientanfrage erfolgreich empfangen, verstanden oder akzeptiert
wurde. Dieser Block ist unter dem Begriff Successful zusammengefasst. Beispiele an dieser
Stelle sind 200 - OK oder 201 - Created. Der Code 200 besagt, dass die Anfrage erfolgreich
war und dass die Informationen, welche mit der Antwort zurückgesendet wird, abhängig von
der Methode ist, welche in der Anfrage verwendet wurde (GET, POST, TRACE). Statuscode
201 bedeutet, dass die Anfrage abgeschlossen ist und eine neue Ressource erstellt wurde.
Der nächste Block, Codes zwischen 300 und 399, hat den Überbegriff Redirection. Die Klasse
von Statuscodes zeigt an, dass weitere Aktionen durch den User-Agenten durchgeführt werden
müssen, damit die Anfrage vollständig bearbeitet werden kann.
Der darauffolgende Block, zwischen 400 und 499, ist mit dem Überbegriff Client Error be-
schrieben. Dieser beinhaltet Fehler, die vermutlich durch den Client verursacht wurden.
53Generell kann eine Ressource beliebig viele Repräsentationsformen besitzen (wie zum Beispiel XML, JSON,TEXT
54Uniform Resource Identifier55Dieser ist 201 Created.
58
3.2. Technologien (Autor: Rene Kassel)
Der letzte Block ist das Pendant zu dem vorhergehenden. Er besitzt den Marker Server Error.
Diese Statuscodes werden gesendet, wenn der Server sich bewusst ist, dass er einen Fehler
verursacht hat oder wenn der Server eine Anfrage nicht mehr beantworten kann.
3.2.6. Extensible Messaging and Presence Protocol
Extensible Messaging and Presence Protocol (XMPP) ist ein offenes und standardisiertes Pro-
tokoll zur Echtzeitkommunikation basierend auf XML (vgl. [Mag11], Seite 3). Es ermöglicht
die Interaktion in Form von Textnachrichten. Der Kern von XMPP ist ein Instant Messaging
Protokoll.
Definition XMPP
„The Extensible Messaging and Presence Protocol (XMPP) is an open technology for
realtime communication, using the Extensible Markup Language (XML) as the base for-
mat for exchanging information. In essence, XMPP provides a way to send small pieces
of XML from one entity to another in close to real time [. . . ]“ ([SAST09], Seite 3).
XMPP ist immer weiter gewachsen und bietet ein eigenes Protokoll zur Erweiterung der ei-
gentlichen Funktionalität wie zum Beispiel eine Kontaktliste oder die Möglichkeit Bilder zu
versenden, Screen-Sharing sowie eine Audio-Chat Funktionalität56. XMPP basiert komplett
auf XML und tauscht alle Informationen über diese Representationsform. In Listing 3.4 ist ein
Beispiel einer Nachricht in XMPP dargestellt.
Listing 3.4: Beispiel für eine Nachricht in XMPP (Quelle: [SAST09])
1 <message from="[email protected]"
2 to="[email protected]"> <body>hello world</body>
3 </message>
In der Arbeit wird dieses Protokoll für viele Interaktions- und Kommunikationsmöglichkeiten
verwendet.
3.2.7. Java Persistence API
Die Java Persistence API (JPA) ist innerhalb von Java ein sehr eleganter Weg Objekte in einer
relationalen Datenbank zu speichern. JPA ist ein Framework, welches den Zugriff auf die Da-
tenbank transparent kapselt und dem Entwickler ein einheitliches Interface bietet, um Objekte
in eine Datenbank zu schreiben und wieder aus der Datenbank zu laden.
„Das Ziel von JPA ist eine Standardisierung des Basis-API sowie der Metadaten eines
objektrelationalen Persistenzmechanismus für Java. Dabei handelt es sich nicht um ein
fertiges Framework, sondern lediglich um eine Spezifikation [. . . ]“ [MW08]
56siehe http://xmpp.org/extensions/
59
3.2. Technologien (Autor: Rene Kassel)
Es muss also noch eine passende Implementierung für das JPA-Framework gewählt werden.
Hier gibt es viele Anbieter wie Eclipse-Link [ecl12] und Hibernate [MW08]. In dieser Arbeit
wurde sich für Eclipse-Link entschieden.
3.2.8. Webdav
Das Web-based Distributed Authoring and Versioning (kurz Webdav) ist eine Technologie, die
den HTTP 1.1 Standard erweitert und dem Benutzer den Zugriff auf ein simuliertes Online-
Dateisystem ermöglicht. Es ist im aktuellen RFC 5689 von 2009 spezifiziert (vgl. [Gro09]).
Die erste Version ist im Jahr 1999 im RFC 2518 entstanden (vgl. [Gro99]). Es wird im Rahmen
dieser Arbeit dazu verwendet, dem Server das Ablegen von Dateien zu vereinfachen.
3.2.9. QR-Codes
QR-Codes57 sind zweidimensionale, grafische Codes (sogenannte 2D-Barcodes), die zur Spei-
cherung von Informationen dienen (vgl. [Win11]). Er kann sich in zwei Dimensionen ändern.
Dabei zeigt er Informationen in einem schwarz-weiß Muster an. Ein Beispiel dafür ist in Ab-
bildung 3.2 zu sehen. Dieser QR-Code enthält den task:1336505994864. Dies stellt eine Tas-
knummer dar, die von der implementierten Plattform generiert wurde. QR-Codes sind eine
Variante von 2D-Barcodes. Ein weiteres Beispiel für 2D-Barcodes ist der Aztec-Code im An-
hang A.1 (vgl. [Azt97b]). Der Unterschied zwischen einem 2D- und einem 1D-Barcode ist in
Abbildung 3.3 dargestellt.
Abbildung 3.2.: QR-Code Beispiel (Quelle: Eigene Darstellung)
57Quick Response Codes
60
3.3. iOS und Objective-C (Autor: Christopher Ezell)
Abbildung 3.3.: QR-Code Vergleich (Quelle: [Win11])
3.3. iOS und Objective-C (Autor: Christopher Ezell)
Da Objective-C , im Vergleich zu Java, eine ungewöhnliche Lese- und Schreibweise hat, wird
in diesem Kapitel dem Leser eine kleine Einführung in die Programmierung mit Objective-C
gegeben. Es wird zuerst auf die Struktur von Methoden und deren Aufruf eingegangen. An-
schließend wird in den Unterkapiteln kurz auf verschiedene Aspekte der Sprache eingegan-
gen.
3.3.1. Die Methodensignatur in Objective-C
Die Methodensignatur in Objective-C ist darauf ausgelegt den anschließenden Methoden-
aufruf wie einen Satz aussprechen zu können. Es soll möglich sein, den Quellcode auf eine
natürlichere Weise lesen zu können als bei anderen Programmiersprachen. Der Kerngedan-
ke dahinter ist die Position der Parameter in dem Methodenaufruf. Diese sind nicht, wie zum
Beispiel bei Java, zwischen zwei Klammern hinter dem Methodennamen alle zusammen ohne
weiteren Bezug auf die Verwendung der einzelnen Variablen, sondern mit sogenannten named
parameters (siehe [Sad12], Seite 53) direkt in dem Aufruf eingebettet (zu sehen in Listing 3.5).
Ein Parameter wird also anhand des Parameternamens der Methodensignatur erkannt.
Eine weitere Besonderheit ist die Sprechweise, die bei dieser Programmiersprache verwendet
wird. Es werden in Objective-C keine Methoden aufgerufen, sondern Nachrichten an Objek-
te gesendet. Diese Nachrichten werden Messages genannt, dynamisch verarbeitet und inner-
halb der Klasse auf eine Methode mit passender Signatur angewendet. Die Klasse wird dann
aufgerufen. Genauer nachzulesen ist dieser Mechanismuss im Apple Developer Portal unter
[App12c]. Die Syntax zum Senden einer Nachricht an ein Objekt sind in Objective-C die
eckigen Klammern. Dies ist in Listing 3.5 dargestellt. In diesem Listing wird einem Objekt
receiver die Nachricht message gesendet und daraufhin die Methode message aufgeru-
fen.
Listing 3.5: Objective-C Methodensignatur
1 [receiver message];
61
3.3. iOS und Objective-C (Autor: Christopher Ezell)
Ein Beispiel für die Definition und Deklaration einer Methode ist im Listing 3.6 dargestellt.
In diesem existiert eine Methode namens didFinishLaunchingWithOptions, die zwei
Parameter übergeben bekommt. Zum einen den Parameter application vom Typ
UIApplication *58 und zum anderen einen Parameter launchOptions vom Typ
NSDictionary *59. Außerdem hat sie einen Rückgabe-Parameter des Typs BOOL. Dies
ist der Variablentyp für ein Boolean in Objective-C . Das „-“ vor der Methode deutet an,
dass diese eine Instanzmethode ist. Sie kann also mittels eines Objektes der Klasse aufgerufen
werden60 und nicht mittels der Klasse. Diese Methode kann nun durch senden der Nachricht
message an das Objekt, wie im Listing 3.7 dargestellt, aufgerufen werden. Wie an dem „*“
hinter dem Variablentyp UIApplication zu erkennen ist, wird auch in Objective-C mit
Zeigern gearbeitet.
Listing 3.6: Beispiel einer Objective-C -Methode
1
2 - (BOOL)application:(UIApplication *)application
3 didFinishLaunchingWithOptions:(NSDictionary *)
launchOptions;
Listing 3.7: Aufruf einer Methode in Objective-C
1 NSObject *tempObject = [[NSObject alloc] init];
2 NSDictionary * dict =
3 [NSDictionary dictionaryWithKeysAndObjects:@"testKey",
4 @"testValue", nil];
5 BOOL boolean = [self testObject:tempObject
6 didBecomeActiveWithOption:dict];
Bei den Klassen hat sich in Objective-C eine an C angelehnte Syntax etabliert. Wie auch in C
gibt es Header-Dateien, in denen das Interface definiert ist und die eigentliche Implementie-
rung der Header-Datei. Eine Klasse, wie sie in Java üblich ist, besteht in Objective-C immer
mindestens aus dem Interface und der Implementierung. Das Interface ist eine Datei mit der
Endung .h und enthält die Deklarationen von Variablen, Properties und Methoden. Ein Inter-
face beginnt mit dem Schlüsselwort @interface61 und endet mit dem Schlüsselwort @end
(vgl. [AM11], Seite 101). Ein Beispiel für ein Interface ist in Listing 3.8 dargestellt.
58Dabei handelt es sich um einen Zeiger auf ein Objekt vom Typ UIApplication59Dabei handelt es sich um einen Zeiger auf ein Objekt vom Typ NSDictionary. Ein NSDictionary ist eine
Hashmap von Java in Objective-C .60Methoden die hingegen ein „+“ haben, können auch an das Klassenobjekt gesendet werden.61Das Schlüsselwort steht nach dem Importieren der benötigten Headers und Frameworks.
62
3.3. iOS und Objective-C (Autor: Christopher Ezell)
Listing 3.8: Beispiel für ein interface in Objective-C
1
2 #import <Foundation/Foundation.h>
3 #import "MyProtocol.h"
4 #import "MyClass.h"
5
6 @interface MyClass : NSObject <MyProtocol>{
7 }
8 @property (strong, nonatomic) UIWindow *window;
9 @property (readonly, strong, nonatomic) NSManagedObjectModel *
managedObjectModel;
10
11 - (void)method;
12 - (NSString *) getResultWithContentString:(NSString *)
contentString;
13
14 @end
Dieses Interface definiert ein Interface für eine Klasse mit dem Namen MyClass. Diese erbt
von der Klasse NSObject und besitzt zwei in Objective-C so geannte properties. Pro-
perties sind Variablen des Objektes, auf die von außen zugegriffen werden kann. Um dies zu
gewährleisten, werden die Getter- und Setter-Methoden von dem Compiler erzeugt. Die Imple-
mentierung der Klasse ist in Listing 3.9 dargestellt.
Listing 3.9: Die Implementierung der Klasse MyClass
1
2 #import "MyClass.h"
3
4 @implementation MyClass
5
6 @end
Wenn nun zu einem interface eine Implementierung geschrieben werden soll, geschieht
dies in der Datei mit der Endung .m. Dies zeigt an, dass es eine Objective-C -Datei ist. Sie
beginnt mit dem Schlüsselwort @implementation. Das bedeutet, dass eine .m-Datei immer
ein Interface implementiert und alle Methoden, Variablen und Properties von diesem Interface
besitzt. Die Datei endet auch wieder mit einem @end. Zwischen diesen Markierungen können
nun die im Interface deklarierten Methoden implementiert werden.
Neben Interfaces existieren noch die Protokolle. Der Unterschied zwischen ihnen liegt darin,
dass ein interface immer ein ganz spezielles Objekt mit all seinen Variablen und Me-
63
3.3. iOS und Objective-C (Autor: Christopher Ezell)
thoden beschreibt62. Ein protocol hingegen ist eine allgemeine Beschreibung einer Funk-
tionalität, also die Beschreibung einer Rolle. Diese kann von einem Objekt eingenommen
werden, wenn dieses Objekt dieses Protokoll implementiert. Auch ein Protokoll hat die En-
dung .h, startet mit dem Schlüsselwort @protocol und endet mit dem Schlüsselwort @end
(vgl. [AM11], Seite 167). Ein Beispiel für ein Protokoll findet sich im Listing 3.10. Hier ist
das Protokoll MyProtocol dargestellt. Es ist vom Basisobjekt NSObject abgeleitet und
hat eine Methode method1, die zwingend zu implementieren ist und eine optionale Me-
thode optionalMethod2. Ein Objekt, dass nun diesem protocol entsprechen möchte,
muss mindestens die erste Methode method1 implementieren, kann aber die zweite Methode
optionalMethod2 weglassen.
Listing 3.10: Beispiel für ein protocol in Objective-C
1 @protocol MyProtocol<NSObject>
2 - (void)method1:(NSString *)myString;
3 @optional
4 - (void)optionalMethod2:(NSString *)myString2;
5 @end
3.3.2. Besondere Schreibweise spezieller Datentypen
Bei den Datentypen gibt es spezielle Unterschiede und Einzelheiten bei der Programmierung
mit Objective-C zu beachten. Zum Beispiel gibt es für verschiedene Objekte Kurzschreibwei-
sen und Sonderregeln. Ein sehr populärer Vertreter von Objective-C ist das String-Objekt. In
Objective-C direkt, gibt es keine Klasse String, sondern nur eine Klasse NSString. Dies
ist ein Wrapper um die C-Klasse String. Listing 3.11 zeigt wie das Initialisieren durch das
Senden der alloc- und init-Nachrichten bei einem NSString funktioniert. Da das ständi-
ge Erzeugen eines Strings aber sehr umständlich wäre, gibt es speziell für die Verwendung
eines Strings die Schreibweise aus Listing 3.12. Durch den Indikator @ wird automatisch
aus dem nachfolgenden String ein Objekt der Klasse NSString erzeugt.
Ein weiterer Punkt kann bei der Programmierung von Objective-C zu Verwirrung führen: Da
Objective-C eine echte Obermenge der Sprache C ist63 (vgl. [Kol10], Seite 56), können alle
Variablentypen von C benutzt werden. So ist es möglich, in einem Objective-C -Programm den
Variablentyp boolean und die beiden Werte true und false zu benutzen. Das ist kein Typ
von Objective-C . Hier sollte der Variablentyp BOOL und die Werte YES und NO (zu schreiben
in Großbuchstaben) benutzt werden.
62so wie eine Header-Datei zu einer Implementierung bei C63Dadurch ist es möglich alle in C geschrieben Programme auch in Objective-C zu kompilieren.
64
3.3. iOS und Objective-C (Autor: Christopher Ezell)
Listing 3.11: Erzeugung eines Strings in Objective-C
1 const char *test= "Hallo Welt";
2 NSString *string = [[NSString alloc] initWithUTF8String:
test];
Listing 3.12: Erzeugung eines Strings in Objective-C mittels Kurzschreibweise
1 NSString *string = @"Hallo Welt";
3.3.3. Delegates
Delegates sind ein zentraler Bestandteil der iOS-Plattform und werden an diversen Stellen zur
Umsetzung von Funktionalität eingesetzt. Das Konzept der Delegation kann dafür eingesetzt
werden, den Funktionsumfang von bestehenden Objekten anzupassen und zu erweitern. Es
wird in Situation angewendet, wenn bei einer Klasse bestimmte Implementierungsdetails offen
gelassen werden sollen. In diesen Fällen wird die Umsetzung dieser Aufgaben an ein ande-
res Objekt delegiert. Dieses sogenannte Delegate kann nun selber bestimmen, wie die aufge-
tragene Aufgabe umgesetzt wird. Viele Klassen in Objective-C besitzen hierfür ein Attribut
delegate (vgl. [Kol10], Seite 102). Dieses kann zur Laufzeit mit einem anderem Delegate-
Objekt ausgetauscht werden und so die Funktionalität zur Laufzeit des Programms geändert
werden. Eine Illustration des Prinzips ist in Abbildung 3.4 dargestellt.
Abbildung 3.4.: Schaubild Objective-C Delegation (Quelle: [App12d])
Der Delegate-Mechanismus ist ereignisgesteuert. Wenn das delegierende Objekt ein Ereig-
nis durchläuft, wird die entsprechende Methode des Delegate-Objekt aufgerufen. Die meis-
ten Delegate-Methoden in Cocoa-Touch verwenden ein einheitliches Muster wie der Name
der Methode aufgebaut wird. Der Name der Methode beginnt immer mit dem Namen der de-
ligierenden Klasse und einem Parameter, in dem das Objekt der delegierenden Klasse über-
geben wird. Eine sehr oft verwendete Methode ist didFinishLaunchingWithOptions
der Klasse UIApplication. Dies ist in Listing 3.13 zu sehen.
Listing 3.13: Delegate-Methode der Klasse UIApplication
1 - (void)application:(UIApplication *)application
2 didFinishLaunchingWithOptions:(NSDictionary *)options;
65
3.3. iOS und Objective-C (Autor: Christopher Ezell)
3.3.4. Key-Value-Observing
Ein großes Thema in allen Applikationen, die über eine Benutzeroberfläche verfügen, ist wie
und wann die Oberfläche mit einem Update der zugrunde liegenden Daten versehen wird. Dies
sollte sehr schnell passieren, da veraltete Daten in der Oberfläche zu inkonsistenten Handlun-
gen des Benutzers führen können64. In Objective-C gibt es mit dem sogenannten Key-Value-
Observing (KVO) eine sehr elegante Technik dies mit sehr wenig Aufwand zu realisieren. KVO
ist also eine Technik, um das sogenannte Databinding auf der iOS-Plattform umzusetzen.
KVO ist eine Implementierung des Observer-Patterns. Dabei erfolgt zunächst eine Registrie-
rung des überwachten Objektes beim Observer. Hier wird als eine gewisse property eines
Objektes verwiesen. Nun wird bei einer Änderung dieser Property ein der Observer benach-
richtigt. Wie beschrieben, besteht diese Technik also aus zwei Teilen, dem Observer und der
überwachten property.
Listing 3.14 zeigt wie ein Oberserver auf das Objekt model registriert wird und die Property
text des Objektes model. Der Observer wird auf self65 gesetzt und kein Kontext über-
geben66. Listing 3.15 zeigt die Funktion, welche aufgerufen wird, wenn sich die beobachtete
Property ändert.
Listing 3.14: Registrierung eines Observer
1 [self addObserver:self
2 forKeyPath:@"model.text"
3 options:NSKeyValueObservingOptionNew
4 context:nil];
Listing 3.15: Aufruf der Methode bei Änderung eines Wertes
1
2 - (void)observeValueForKeyPath:(NSString *)keyPath
3 ofObject:(id)object
4 change:(NSDictionary *)change
5 context:(void *)context
6 {
7 NSLog(@"%s", __PRETTY_FUNCTION__);
8 NSLog(@"%@", keyPath);
9 }
64Dies kommt zum Beispiel vor, wenn ein Benutzer einen Datensatz bearbeiten will, der gar nicht mehr existiert.65also das aktuelle Objekt66also nil
66
3.3. iOS und Objective-C (Autor: Christopher Ezell)
3.3.5. Struktur und Lebenszyklus einer iOS-Applikation
Nachdem die grundlegenden Techniken der Sprache Objective-C und der iOS-PLattform erläu-
tert wurden, ist es vom Vorteil den generellen Lebenszyklus einer iOS-Applikation zu verste-
hen. Eine Applikation wird innerhalb der iOS-PLattform, wie auch viele andere Funktionen,
über ein Delegate realisiert. Das bedeutet also, dass eine Applikation existiert, die sich im Spei-
cher der Plattform befindet. Dabei hält der Programmierer eine Instanz eines Delegates in der
Hand, welches bei gewissen Ereignissen von der Instanz aufgerufen wird. Diese Ereignisse
und Methoden sind im protocol UIApplicationDelegate definiert. Das protocol
definiert nun eine Reihe von optionalen Methoden, die eine Klasse, die dieses protocol
implementiert, überschreiben und somit erweitern kann. Listing 3.16 zeigt nun ausgewählte
Methoden dieses Protokolls. Abbildung A.10 zeigt die Aufrufe in zeitlicher Beziehung zuein-
ander.
Im nachfolgenden wird der einfache Fall des Startvorganges erläutert. Nach dem Starten der
Applikation wird die Methode didFinishLaunchingWithOptions aufgerufen. An die-
ser Stelle kann der Entwickler wichtige Datenstrukturen aufbauen und Verbindungen zu den
Servern herstellen. Zu dieser Zeit wird noch das Startsymbol und nicht die View der Applikati-
on gezeigt. Als nächstes wird die Methode applicationDidBecomeActive aufgerufen.
Hier wird bereits die View angezeigt und es können noch letzte Updates durchgeführt wer-
den. Die Methode applicationWillResignActive bedeutet, dass der Nutzer gerade
den Home-Button gedrückt hat und die Applikation in den Hintergund gelegt wird. In die-
ser Methode können Hintergrundaktivitäten gestartet werden, um z.B. Ladevorgänge zu been-
den. Die Methode applicationDidEnterBackground bedeutet, dass die Applikation
pausiert wurde. Wenn die Applikation wieder im Vordergrund erscheint, wird die Methode
applicationWillEnterForeground aufgerufen. Hier können Verbindungen zum Ser-
ver wieder aufgebaut werden.
Listing 3.16: Das protocol UIApplicationDelegate
1 @protocol UIApplicationDelegate<NSObject>
2 @optional
3 - (void)applicationDidFinishLaunching:(UIApplication *)
application;
4 - (BOOL)application:(UIApplication *)application
5 didFinishLaunchingWithOptions:(NSDictionary *)
launchOptions;
6
7 - (void)applicationDidBecomeActive:(UIApplication *)
application;
8 - (void)applicationWillResignActive:(UIApplication *)
application;
9 - (void)applicationWillTerminate:(UIApplication *)application;
67
3.4. Testen von Software (Autor: Rene Kassel)
10
11 - (void)applicationDidEnterBackground:(UIApplication *)
application;
12 - (void)applicationWillEnterForeground:(UIApplication *)
application;
13 @property (nonatomic, retain) UIWindow *window;
14
15 @end
3.3.6. Notification Center
Das Notification Center ist eine zentrale Stelle innerhalb der iOS-Plattform, um asynchron
Nachrichten an andere Teile der Applikation senden und empfangen zu können. Eine Notifica-
tion kapselt die Informationen über ein Event67. Wenn nun Objekte innerhalb der Applikation
diese Information benötigen, können sie sich auf diese Notification registrieren. Die Objekte
werden beim Auftreten dieses Events aufgerufen (vgl. [ios12b]). Listing 3.17 zeigt, wie ein Ob-
jekt (hier self) sich für die Notification vom Typ
NSWindowDidBecomeMainNotification registriert. Wenn eine Notification von die-
sem Typ im System erstellt wurde, wird die Methode aWindowBecameMain: aufgerufen.
Diese Methode muss einen Parameter vom Typ NSNotification* besitzen. Der Sachver-
halt ist in Listing 3.18 dargestellt.
Listing 3.17: Registrierung für eine local notification
1 addObserver:self
2 selector:@selector(aWindowBecameMain:)
3 name:NSWindowDidBecomeMainNotification object:nil];
Listing 3.18: Die Signatur der Methode zum annehmen der Notification
1 - (void)aWindowBecameMain:(NSNotification *)notification;
3.4. Testen von Software (Autor: Rene Kassel)
Ein wichtiger Punkt beim Erstellen von guter Software ist das Einhalten etablierter Standards
und über die Jahre entwickelte sogenannte Best-Practices beim Programmieren. Hier kommen
Aspekte der Software-Qualität zum Tragen und Aspekte der Sicherstellung von Funktionalität.
Diese beiden Aspekte können durch gut strukturierte Software-Tests verbessert werden und
sollen kurz beschrieben werden. Der Begriff Test kann aus verschiedenen Perspektiven gesehen
werden. Auf der einen Seite ist er eine Art Beweis, dass die Software auch das leistet, was von67Ein Beispiel dafür ist ein Touch-Event, wenn der Benutzer einen Teil des Bildschirmes berührt.
68
3.4. Testen von Software (Autor: Rene Kassel)
ihr verlangt wird68. Auf der anderen Seite dienen sie zum strukturierten Finden von Fehlern
in der Software. Auch sind Tests eine sehr gute Methode, um die Anforderungen, die an die
Software gestellt werden, zu überprüfen. Dies soll Abbildung 3.5 nochmals veranschaulichen.
Es wurde sich im Rahmen dieser Arbeit für folgende Definition von einem Software-Tests
geeinigt.
Definition Test
„Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden“
([MS04], Seite 6)
Abbildung 3.5.: Überprüfung der Anforderungen mittels Tests (Quelle: [HW11], Seite 5.)
Es gibt in der klassischen Literatur die Unterteilung in verschiedene Kategorien von Tests.
Grob kann in Blackbox- und Whitebox-Tests unterschieden werden. Ein Blackbox-Test ist ein
datenorientierter Test. Er betrachtet das System als eine Blackbox, gibt dem System definierte
Daten als Eingabe und testet, ob die richtigen Daten als Ausgabe wieder zurück gegeben wer-
den (vgl. [Mye99], Seite 6). Beim Whitebox-Test hingegen kennt der Tester die interne Logik
des Programms und gestaltet seine Testfälle dementsprechend (vgl. [Mye99], Seite 8).
Eine andere Einordnung von Tests basiert auf dem Umfang des Testrahmens, also wieviel der
Applikation gleichzeitig getestet wird. Für diese Einteilung bietet das so genannte V-Modell
eine gute Übersicht über diese Art der Einteilung von Tests69. Der Name stammt von der Dar-
stellungsform dieses Modells. Dies ist in dem meisten Fällen V-förmig. Das V-Modell siedelt
die verschiedenen Arten von Tests in Schichten an (vgl. [Hab12]). Es definiert die folgenden
vier Testarten:
• Komponenten-Tests (Unit-Tests oder auch Modultests),
• Integrationstests,
• Systemtests und
• Abnahmetests.
Zu sehen sind diese in Abbildung 3.6 zum V-Model. Die Programmierung steht in dieser Ab-
bildung an zentraler Stelle im unteren, mittleren Bereich. Direkt darüber sind die Komponen-tentests (auch Unit-Tests) angesiedelt. Komponententests sind Tests, bei denen die einzel-
68Besser gesagt, das was die Tests testen.69nicht über das Vorgehen
69
3.4. Testen von Software (Autor: Rene Kassel)
nen Klassen (Units) unter Isolation von anderen Klassen getestet werden. Es sollen damit die
Funktionalität, Robustheit und die Effizenz getestet werden (vgl. [Hab12]). Ein Komponen-tentests kann sowohl als Blackbox- als auch als Whitebox-Test durchgeführt werden. Für die
Interaktion mit anderen Komponenten werden Mocks eingesetzt. Über den Unit-Tests stehen
die Integrationstests. Sie testen das Zusammenspiel der vorher getesteten Komponenten. An
oberster Stelle sind auf der linken Seite die Anforderungen an die Software gestellt. Der Sys-
temtests wird hier nicht beschrieben, da er nicht explizit getestet wird. Diese Anforderungen
stellen die abstrakteste Sichtweise auf die Software dar. Anforderungen sind für diese Arbeit als
User Stories definiert und im Kapitel 4 festgehalten. Die Abnahmetests, die die Anforderungen
testen, werden im Kapitel 7 beschrieben.
Abbildung 3.6.: Das V-Modell (Quelle: [Hab12], Seite 24)
Wie im Grundlagenkapitel beschrieben, ist es für einen agilen Entwicklungsprozess sehr wich-
tig ein schnelles Feedback für den neu geschriebenenen Quellcode zu bekommen. Hierzu ha-
ben sich automatisierte Tests und Codeanalysen durchgesetzt. Diese Tests sollten immer sehr
zeitnah ausgeführt werden. Ein sehr guter Zeitpunkt ist innerhalb des Build-Prozesses der An-
wendung. Auf diesen Prozess wird im nächsten Kapitel näher eingegangen.
70
3.5. Build-Management (Autor: Christopher Ezell)
3.5. Build-Management (Autor: Christopher Ezell)
Den Prozess, in dem aus dem Quellcode eine ausführbare Anwendung gebaut wird, nennt man
Build-Prozess70. Dies kann je nach Art der Software mehr oder weniger aufwändig sein. Im
Folgenden wird erläutert, wie der Build-Prozess bei den eingesetzten Technologien abläuft und
wie die Tests in diesen Prozess mit eingebunden sind.
Der Build für die Java-Komponenten wird mit Maven durchgeführt (vgl. [Fou12a]). Maven
ist eines der führenden Build-Tools für Java und zählt zu den deklarativen Build-Management-
Systemen. Das bedeutet, es wird lediglich der Inhalt des Projektes beschrieben, nicht die Struk-
tur oder die Abläufe, die zur Kompilierung und Veröffentlichung notwendig sind (vgl. [Spi11],
S.27). Durch die Verwendung von Maven ist es sehr einfach Prozess-Schritte zu automatisie-
ren. Es können zum Beispiel folgende Dinge automatisiert ablaufen:
• Compilieren des Quellcodes,
• Durchlaufen der Unit-Tests,
• Verarbeitung und Einbindung zusätzlicher Ressourcen,
• Ersetzung von Platzhaltern durch umgebungsspezifische Parameter,
• Starten eines Web- oder Applikationsservers und
• Durchlaufen der Integrations-Tests.
Diese und viele mehr können mit diesem Tool ermöglicht werden. Deswegen wurde sich für
Maven entschieden. So ist gewährleistet, dass in einem agilen Entwicklungsprozess schnelles
Feedback über den Zustand der Software möglich ist. Die Konfiguration von Maven wird über
das POM-File gesteuert. Dieses wird nachfolgend näher erläutert:
Das POM-File: Das Projektmodell (Project Object Model - POM) ist ein Mechanismus
innerhalb von Maven. Es wird dazu verwendet das zu kompilierende Projekt, die Umge-
bung und die Beziehungen zu anderen Projekten zu verwalten. Es ist in einer speziellen
Datei gespeichert, die den Namen pom.xml trägt.
Das Herzstück von Maven ist also die sogenannte POM-File. Sie beschreibt die Inhalte des
Projektes und welche Ressourcen für den Prozess verwendet werden sollen. Bei Maven wird
von einem sogenannten Build-Zyklus gesprochen, der durchlaufen wird. Maven durchläuft in-
nerhalb dieses Build-Zyklusses immer wieder dieselben Phasen. Diese sind streng aufeinander
folgend. Es ist möglich zu bestimmen, bis zu welche dieser Phasen der Zyklus durchlaufen
wird (vgl. [Gro12a]). Hier die einzelnen Phasen im Überblick:
• process-resources: verarbeitet alle Ressourcen und kopiert sie in das Zielver-
zeichnis.
70englisch „to build“ für „bauen“
71
3.5. Build-Management (Autor: Christopher Ezell)
• compile: kompiliert den Quellcode.
• process-classes: verarbeitet die kompilierten Klassen (Bytecodeoptimierung).
• generate-test-sources: verarbeitet alle Testressourcen und kopiert sie in das
Testzielverzeichnis.
• test-compile: kompiliert die Testklassen.
• test: durchläuft die Tests (meistens Unit-Tests).
• package: packt die kompletten Inhalte in ein jar-File.
• pre-integration-test: führt Aktionen aus, die zum Durchlaufen der Integrati-
onstests nötig sind.
• integration-test: liefert das Paket in der Umgebung aus (zum Beispiel Glassfish)
und durchläuft die Integrationstests.
• post-integration-test: führt abschließende Aktionen aus, die zum Herunter-
fahren der Umgebung nötig sind.
• install: installiert das Paket in das lokale Maven-Repository.
• deploy: deployed das Paket in das Remote-Repository.
Eine der großen Stärken und das Hauptargument für Maven ist das sehr gute Dependency
Management. Wenn für ein, mit Maven verwaltetes, Projekt eine neue Bibliothek eingebunden
werden soll, kann man dies einfach in eine spezielle Region der POM-File schreiben. Diese
Region befindet sich innerhalb des Tags dependencies. Der Sachverhalt ist beispielhaft
in Listing 3.19 zu sehen. Durch diesen Eintrag steht innerhalb des Projektes nun junit in der
Version 4.8.2 zur Verfügung.
Listing 3.19: das Tag dependencies der pom.xml
1 <dependencies>
2 <dependency>
3 <groupId>junit</groupId>
4 <artifactId>junit</artifactId>
5 <version>4.8.2</version>
6 </dependency>
7 </dependencies>
Wie in der Auflistung zu sehen ist, werden bei einem Maven-Build immer die Unit-Tests und
die Integrationstests durchlaufen. Dies bietet einen enormen Zeitvorteil, da durch das Ausfüh-
ren des Builds gleich geprüft wird, ob alle Tests durchlaufen werden. Dies erledigt der Ent-
wickler meistens gleich auf dem Entwicklungsrechner und kann so seinen geschriebenen Code
selber testen.
72
3.5. Build-Management (Autor: Christopher Ezell)
Der Quellcode soll auch auf einem anderen Rechner getestet werden. Dies verhindert, dass
eventuelle Rahmenbedingungen für das Funktionieren der Software an den Gegebenheiten des
Entwicklerrechners hängen. Hierzu wird ein externes unabhängiges System benötigt, welches
automatisiert diese Schritte und selbstständig die Tests durchläuft. Auf dieser Umgebung wer-
den sowohl Unit-Tests, als auch Integrations-Tests durchlaufen. Eine solche Umgebung wird
Continuous Integration Umgebung, kurz CI-Umgebung, genannt. CI wurde das erste Mal in
dem Buch Extreme Programming Explained von Kent Beck erwähnt. Es wird definiert als ein
kontinuierlicher Zyklus der gesamten Strecke von der Kompilierung des Quellcodes über auto-
matisierte Tests hin zur kompletten Integration der Anwendung auf einem Zielsystem (vgl.
[Bec99], Seite 138). Diese Umgebung soll zu einem bestimmten Zeitpunkt den gesamten
Build-Prozess durchlaufen. Dieser Zeitpunkt ist idealerweise nach jedem einzelnen Commit(vgl. [HF10], Seite 55) eines Entwicklers. Das ist aber nur möglich, wenn der Mechanismus
der Integration vollständig automatisiert werden kann. Wenn ein Team dies erreicht, kann es
die Zeit für die Auslieferung seiner Software signifikant verringern (vgl. [HF10]). In Anhang
A.2 ist ein beispielhafter Aufbau einer CI dargestellt.
Definition Continuous Integration
„Continuous Integration ist ein hervorragendes Werkzeug, um in Softwareentwicklungs-
projekten Risiken zu minimieren und Qualität zu steigern.“ [Wie10]
Ein Problem gibt es bei Maven: Es hat nur ein Kommandozeilen-Interface. Dies lässt sich
auf einem Entwicklerrechner noch umgehen, indem die Build-Zyklen von Hand gestartet wer-
den, aber für einen automatisierten Build ist das nicht geeignet. Dieses Problem lässt sich mit
Jenkins lösen. Im Rahmen der Masterarbeit wurde Jenkins als CI-Werkzeug eingesetzt und
wird daher näher erläutert. Im Anhang A.16 ist beispielhaft die Weboberfläche von Jenkins
dargestellt (vgl. [Wie10]). In der Weboberfläche können Jobs eingestellt werden, die danach
automatisiert einen Maven-Build anstoßen können. Diese Jobs können durch verschiedene
Trigger ausgelöst werden. Beispiele sind hier zum Einen feste Zeitpunkte und zum Anderen
Regeln. Eine Beispielregel ist, dass bei jedem Commit der Build gestartet werden soll. Die-
se löst den Build-Prozess nach jedem Commit aus. Durch eine Integrationsmöglichkeit eines
Maven-Buildprozesses ist es eine sehr gute Kombination, um eine CI umzusetzen. Ein weiterer
sehr wichtiger Punkt ist die sehr große Anzahl an Plug-ins für Jenkins. Durch Plug-ins können
somit mehr unterschiedliche Aktionen getriggert werden. Bei folgenden Ereignissen können
bestimmte Aktionen ausgelöst werden:
• ein Build-Prozess wurde gestartet,
• ein Build-Prozess ist erfolgreich durchgelaufen,
• ein Build-Prozess wurde abgebrochen,
• ein Build-Prozess ist fehlgeschlagen oder
• ein Build-Prozess wurde mit fehlgeschlagenen Tests beendet.
73
3.6. Zusammenfassung (Autoren: Rene Kassel und Christopher Ezell)
Bei diesen Ereignissen können nun beliebige Aktionen getriggert werden. Entweder werden
diese direkt von Jenkins unterstützt, oder es ist dafür ein Plug-in installiert worden. Zum Bei-
spiel wird das Senden einer e-Mail direkt von Jenkins unterstützt. Hingegen ist das Senden
einer XMPP-Nachricht nur mit einem Plug-in möglich. Auch RSS-Feeds werden ohne Plug-
in unterstützt. Damit können Entwickler alle Build-Status-Nachrichten abonnieren. Somit wird
der Entwickler in Echtzeit über vorhandene Fehler informiert und kann sofort darauf reagieren.
Die Erstellung eines Testberichtes ist ebenfalls möglich. JUnit-Testberichte können aufgelistet,
zusammengefasst und veranschaulicht werden.
3.6. Zusammenfassung (Autoren: Rene Kassel und Christopher Ezell)
In diesem Kapitel wurden grundlegende Techniken vorgestellt. Es wurde auf Begriffe einge-
gangen, die in der Arbeit verwendet werden und Techniken beschrieben, die für das Verständ-
nis der Umsetzung in dieser Arbeit beitragen. Es wurde auf Basistechniken der Software-Tests
eingegangen. Die vorgestellten Test-Techniken werden innerhalb der Implementierung genutzt,
um die Richtigkeit der Software zu verifizieren. Nach der Erläuterung von Grundlagen, kann
in dem nächsten Kapitel mit der Definition der User Stories begonnen werden.
74
4. User Stories (Autoren: Christopher Ezell und Rene Kassel)
4. User Stories (Autoren: Christopher Ezell und Rene Kassel)
Die Beschreibung der Funktionalität der umzusetzenden Plattform erfolgt über User Storiesund wird mit Conditions of Satifaction untermauert. Dies soll sicherstellen, dass am Ende
klar getestet werden kann, ob die Anforderungen aus den User Stories erfüllt wurden.
Die Autoren haben sich dazu entschieden, die Aufgaben der Software in User Stories zu defi-
nieren. Die Abbildung A.13 zeigt die User Stories als Überblick in Form eines UML-Usecase
Diagramms. Dies dient nur zur Übersicht und Orientierung. Die einzelnen User Stories werden
im nachfolgenden näher beschrieben. Diese leiten sich zum größten Teil aus einem vorheri-
gen Kapitel (Kapitel 2.8) und aus diversen Vorüberlegungen zur Plattform ab. Die User Stories
bilden den ersten Schritt in der Konzeptions- und Planungsphase.
Noch erwähnt werden sollte, dass die User Stories lediglich Features und Akzeptanzkriterien
beschreiben, die mittels einer Eigenimplementierung realisiert werden. Installationsroutinen
oder die Integration bestehender Lösungen in die Projektplattform werden nicht in User Stories
verpackt.
Sie werden nach den Anforderungen, die im Kapitel 3.1.2 gestellt werden, aufgestellt und
beschreiben das System auf einer Ebene, auf der der User mit diesem System interagiert.
4.1. Beschreibung der Applikation (Autor: Rene Kassel)
Bevor auf die einzelnen User Stories eingegangen wird, soll dem Leser ein Gesamteindruck
über die Funktionalität der zu entwickelnden Plattform gegeben werden. Der Prototyp versucht,
die in Kapitel 2.2 und 2.3 dargestellten Probleme durch das Aufgreifen der in Kapitel 2.3
angedeuteten Lösungsansätze zum größten Teil zu lösen und einen ersten Eindruck zu geben,
wie eine komplette Plattform, in diesem Stil, für ein verteiltes Team funktionieren kann.
Wie schon angedeutet, liegt das Hauptmerkmal dieses Prototypen auf dem mobilen Aspekt der
Kommunikation. Es wird also viel Wert darauf gelegt, dass der Benutzer des Prototypen alle
Aktionen auf seinem Smartphone erledigen kann. Er möchte mobil mit seinem Team interagie-
ren können und dem Team Informationen über seinen derzeitigen Standort und seine aktuelle
Situation bekannt geben. Er soll die Möglichkeit haben, aktuelle Informationen aus dem Team
einsehen zu können. Es gibt die Möglichkeit mit anderen Usern zu chatten und Aufgaben zu er-
stellen und diese zuweisen zu können. Der User kann den aktuellen Build-Status abfragen und
sich über gerade geteilte Links zu aktuellen Arbeitsthemen informieren. Die Anwendung soll
75
4.2. User Story 1: Einloggen (Autor: Rene Kassel)
den Problemen in verteilten Teams mit einer sinnvollen, logischen und überlegten Verknüp-
fung moderner Kommunikationsmöglichkeiten entgegenwirken und die negativen Auswirkun-
gen minimieren. Zudem soll das zwischenmenschliche Gefüge zwischen den Projektpartnern
verbessert werden, was sich wiederum positiv auf den Projekterfolg auswirken kann.
4.2. User Story 1: Einloggen (Autor: Rene Kassel)
User Story: Einloggen
Als ein User möchte ich mich mit meinen Accountdaten im System einloggen können.
Conditions of Satisfaction:
Given: Es existiert ein User mit einem validen Useraccount.
When: Wenn dieser User sich mit diesem Account versucht einzuloggen,
Then: dann bekommt der User positives Feedback vom System, dass er eingeloggt ist.
Given: Es existiert ein User mit einem nicht validen Useraccount.
When: Wenn dieser User sich mit diesem Account versucht einzuloggen,
Then: dann bekommt der User negatives Feedback vom System, da die Daten invalide sind.
Abnahmekriterien:
• Der LoginScreen soll im Hintergrund das InstantScrum-Logo haben.
• Der LoginScreen umfasst zwei Eingabefelder: Benutzername und Passwort.
• Der LoginScreen hat einen Button zum Absenden der Login-Daten, welcher mit „Login“
versehen ist.
4.3. User Story 2: Ausloggen (Autor: Rene Kassel)
User Story: Ausloggen
Als ein User möchte ich meinen Account ausloggen können.
Conditions of Satisfaction:
Given: Gegeben ist, dass ein User mit einem validen Useraccount am System angemeldet ist.
When: Wenn dieser User auf einen Button klickt,
Then: dann möchte er aus dem System ausgeloggt werden.
Abnahmekriterien:
76
4.4. User Story 3: News einsehen (Autor: Christopher Ezell)
• Der Logout-Button ist im Hauptmenü oben rechts platziert.
• Der Button entspricht den original Apple-Spezifikationen für einen Right-Bar-Button
des UINavigationsControllers.
4.4. User Story 3: News einsehen (Autor: Christopher Ezell)
User Story: News einsehen
Als ein User möchte ich Neuigkeiten aus dem Projekt auf einer Seite angezeigt bekom-
men.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung am System als User.
When: Wenn der User nun die Seite mit den Nachrichten aufruft,
Then: bekommt der User die Nachrichten in absteigender Reihenfolge angezeigt.
Given: Gegeben ist eine gültige Anmeldung am System als User. Zudem befindet sich der User
aktuell auf der Seite mit den Nachrichten.
When: Wenn der User nun den Inhalt der Seite mit dem Finger nach unten schiebt,
Then: dann wird ein „Pull down to refresh“ erzeugt, sodass die News neugeladen werden.
Abnahmekriterien:
• Eine einzelne News-Zelle soll enthalten:
– den Usernamen, welcher die Nachricht verursacht hat bzw. übersendet,
– die zu übermittelnde Nachricht selbst,
– ein Datum und eine Uhrzeit,
– optional: den Standort, von welchem aus die Nachricht übersendet wurde.
• Der „Pull down to refresh“ soll kurz sichtbar sein. D.h. es soll erkennbar sein, dass gerade
ein Update auf die Sicht durchgeführt wird.
77
4.5. User Story 4: News einstellen (Autor: Christopher Ezell)
4.5. User Story 4: News einstellen (Autor: Christopher Ezell)
User Story: News einstellen
Als ein User möchte ich die Möglichkeit besitzen, individuelle Neuigkeiten an meine
Projektmitglieder zu posten, um sie dadurch über den aktuellen Stand zu informieren.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung am System als User. Der User hat bereits die Seite
mit den Neuigkeiten aufgerufen.
When: Wenn der User auf einen Button klickt,
Then: dann öffnet sich eine neue Ansicht zum hinzufügen einer neuen Nachricht.
Given: Gegeben ist eine gültige Anmeldung am System als User. Der User hat bereits den But-
ton geklickt und befindet sich auf der neuen Ansicht zum hinzufügen.
When: Wenn der User dort die erforderten Daten eingibt und auf absenden klickt,
Then: dann wird die Neuigkeit an das System gepostet und ist für alle Projektbeteiligten sicht-
bar.
Abnahmekriterien:
• Der Button zum Hinzufügen soll sich an der oberen rechten Ecke befinden. Dabei soll er
den original Apple-Spezifikationen für einen Right-Bar-Button des UINavigationsCon-
trollers entsprechen.
• Die neue sich öffnende Ansicht sollte enthalten:
– Ein Feld zur Eingabe des Ortes (Angabe optional vermerken),
– Ein Feld zur Eingabe der Nachricht (Neuigkeit),
– Eine Zeichenbegrenzung für die Nachricht auf 160 Zeichen,
– Eine Ansicht über die noch verfügbaren Zeichen.
• Der Absenden-Button soll sich an der oberen rechten Ecke befinden und den original
Apple-Spezifikationen für einen Right-Bar-Button des UINavigationsControllers ent-
sprechen.
• Es soll sowohl eine Push-Benachrichtigung als auch eine Benachrichtigung per e-Mail
über die Neuigkeit an alle Projektbeteiligten gesendet werden71.
71Eigene User Stories dazu wurden in Kapitel 4.19 und 4.20 definiert
78
4.6. User Story 5: Build-Status einsehen (Autor: Rene Kassel)
4.6. User Story 5: Build-Status einsehen (Autor: Rene Kassel)
User Story: Build-Status einsehen
Als ein User möchte ich den aktuellen Build-Status einsehen können, um mich über den
aktuellen Projekt-Build-Prozess informieren zu können.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung am System als User.
When: Wenn der User nun das Tabbar-Icon für den Build drückt,
Then: dann öffnet sich eine Ansicht, welche den Build-Status der Projekte zeigt.
Abnahmekriterien:
• Die Ansicht soll alle Projekte, die integriert sind, anzeigen.
• Es soll die Möglichkeit geben, jedes einzelne Projekt anzuklicken um dadurch zu einer
Detailansicht zu gelangen.
• Diese Detailansicht soll anzeigen:
– Informationen zu Testergebnissen: Wie viele Tests sind von wie viel durchgeführ-
ten fehlgeschlagen?
– Informationen über den Build-Status: Wann schlug der letzte Build fehl?
– Wann war der letzte / erfolgreiche / stabile Build?
4.7. User Story 6: Position der anderen User einsehen (Autor: Christopher Ezell)
User Story: Position der anderen User einsehen
Als ein User möchte ich auf einer Karte durch Pinnadeln die Position meiner Projekt-
mitglieder sehen.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung am System als User.
When: Wenn der User auf die Seite navigiert,
Then: dann sieht er für jedes Projektmitglied mit einer gespeicherten Position eine Nadel auf
einer Karte.
79
4.8. User Story 7: Eigene Position erneuern (Autor: Christopher Ezell)
Given: Gegeben ist eine gültige Anmeldung am System als User. Der User ist auf der Seite mit
der Karte.
When: Wenn ein User nun auf eine Nadel klickt,
Then: dann wird ihm eine Sicht mit zusätzlichen Informationen über das spezielle Projektmit-
glied angezeigt.
Abnahmekriterien:
• Die anzeige der Maps soll mit der Hybrid-ansicht von Google Maps erfolgen.
• Für die Anzeige der Pins soll der Apple-StandardPin in Rot genutzt werden.
• Für jeden Nutzer gibt es eine eigene View mit Bild.
4.8. User Story 7: Eigene Position erneuern (Autor: Christopher Ezell)
User Story: Eigene Position erneuern
Als ein User möchte ich meine eigene Position updaten können.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung am System als User. Weiterhin befindet sich der
User auf der Seite mit der Karte.
When: Wenn der User nun auf „Update“ klickt,
Then: dann öffnet sich eine Eingabemaske zur Eingabe des Ortes.
Given: Gegeben ist eine gültige Anmeldung am System als User. Der User ist auf der Seite mit
der Karte. Die Eingabemaske ist bereits geöffnet.
When: Wenn ein User nun den Ort eingibt und auf den Button klickt,
Then: dann soll die Position des angemeldeten Users aktualisiert werden.
Abnahmekriterien:
• Der update-Button soll an der oberen rechten Ecke sein und den original Apple-Spezifikationen
für einen Right-Bar-Button des UINavigationsControllers entsprechen.
• Die Eingabemaske enthält ein Feld zur Eingabe eines Ortes, sowie einen Button zum
Bestätigen der Aktualisierung.
80
4.9. User Story 8: Tasks einsehen (Autor: Rene Kassel)
4.9. User Story 8: Tasks einsehen (Autor: Rene Kassel)
User Story: Tasks einsehen
Als ein User möchte ich alle Tasks sehen, die zu meinen Projekten gehören.
Conditions of Satisfaction:
Given: Der User ist mit einem gültigen Account am System angemeldet.
When: Klickt der User auf den Reiter „Taskliste“,
Then: dann öffnet sich eine Ansicht, welche alle Tasks anzeigt.
Given: Der User ist mit einem gültigen Account am System angemeldet. Er befindet sich zur
Zeit in der geöffneten Task-Ansicht.
When: Wenn der User nun den Inhalt der Seite mit dem Finger nach unten schiebt,
Then: dann wird ein „Pull down to refresh“ erzeugt, sodass die Taskliste aktualisiert wird.
Abnahmekriterien:
• Eine einzelne Zelle aus der Ansicht der Taskliste beinhaltet:
– den Tasknamen,
– den Wert „Worklog“: sagt etwas darüber aus, wie viel bereits an dem Task gearbei-
tet wurde,
– den Wert „Estimation“: gibt Auskunft darüber, welcher Aufwand für den Task ge-
schätzt wurde,
– eine Art Fortschrittsanzeige, welche sich aus Worklog und Estimation zusammen-
setzt.
• Der „Pull down to refresh“ soll kurz sichtbar sein. D.h. es soll erkennbar sein, dass gerade
ein Update auf die Sicht durchgeführt wird.
4.10. User Story 9: Task erzeugen (Autor: Rene Kassel)
User Story: Task erzeugen
Als ein User möchte ich die Möglichkeit besitzen, neue Tasks zu erzeugen.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung am System als User. Zudem befindet sich der User
in der Tasklisten-Ansicht.
81
4.11. User Story 10: Task konfigurieren (Autor: Rene Kassel)
When: Wenn der User auf einen Button klickt,
Then: dann wird eine neue Ansicht geöffnet, welche ein Formular zur Erstellung eines Tasks
enthält, gestartet.
Given: Gegeben ist eine gültige Anmeldung am System als User. Der User hat bereits den
Button geklickt und befindet sich auf der neuen Ansicht zum hinzufügen.
When: Wenn der User dort die erforderten Daten eingibt und auf erstellen klickt,
Then: dann wird ein neuer Task im System angelegt.
Abnahmekriterien:
• Der Button zum Hinzufügen soll sich an der oberen rechten Ecke in der Tasklisten-
Ansicht befinden. Dabei soll er den original Apple-Spezifikationen für einen Right-Bar-
Button des UINavigationsControllers entsprechen.
• Das Eingabeformular der neuen Ansicht soll enthalten:
– Ein Feld zur Eingabe des Namens,
– Eine Möglichkeit, diesen Task einem bestimmten Projekt zuzuweisen.
• Der Erstellen-Button soll sich an der oberen rechten Ecke befinden und den original
Apple-Spezifikationen für einen Right-Bar-Button des UINavigationsControllers ent-
sprechen.
• Nach dem Klick auf den Erstellen-Button soll die Anwendung wieder zurückkehren zur
Tasklisten-Ansicht.
4.11. User Story 10: Task konfigurieren (Autor: Rene Kassel)
User Story: Task erzeugen
Als ein User möchte ich die Möglichkeit haben, einen bereits bestehenden Task anzu-
passen. D.h. ich möchte ihm einen Verantwortlichen zuordnen und einen geschätzten
Aufwand eintragen.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung am System als User. Der User hat die Tasklisten-
Ansicht geöffnet und dort bereits den zu bearbeitenden Task angeklickt.
When: Wenn der User in dieser Ansicht auf assign User klickt,
Then: dann öffnet sich eine neue Ansicht, wo der Verantwortliche User ausgewählt werden
kann.
82
4.12. User Story 11: Arbeitszeit einsehen (Autor: Rene Kassel)
Given: Gegeben ist eine gültige Anmeldung am System als User. Der User hat die Tasklisten-
Ansicht geöffnet und dort bereits den zu bearbeitenden Task angeklickt. Zudem hat der User
auf den Button geklickt, welcher die Ansicht zur Wahl des Verantwortlichen öffnet.
When: Wenn der User dort den Verantwortlichen auswählt und auf assigned to klickt,
Then: dann wird diesem bestimmten Task der verantwortliche User zugeordnet.
Given: Gegeben ist eine gültige Anmeldung am System als User. Der User hat die Tasklisten-
Ansicht geöffnet und dort bereits den zu bearbeitenden Task angeklickt.
When: Klickt der User dort auf Estimate Value,
Then: dann kann er da einen Wert eingeben, um damit den Aufwand zu schätzen / setzen.
Abnahmekriterien:
• Die Buttons für Assign User und Estimate Value befinden sich am unteren Ende dieser
Ansicht im Footer.
• Die Ansicht, welche sich zur Wahl des Verantwortlichen öffnet hat eine Picker-View,
welche alle im Projekt beteiligten User beinhaltet, sodass der Verantwortliche nur noch
ausgewählt werden muss.
• Nach der Zuordnung der Verantwortlichkeit eines Tasks soll der betroffene User sowohl
eine Push-Benachrichtigung als auch eine Benachrichtigung per e-Mail bekommen72.
• Bei Klick auf den Estimate Value-Button öffnet sich ein Eingabefenster zum Wert einge-
ben.
• Der in der Taskliste angezeigte Estimate Value errechnet sich aus allen bereits abgege-
benen Schätzungen zu diesem Task. Bei dem angezeigten Wert handelt es sich um einen
Mittelwert.
4.12. User Story 11: Arbeitszeit einsehen (Autor: Rene Kassel)
User Story: Arbeitszeit einsehen
Als ein User möchte ich eine Übersicht darüber haben, wie viel bereits an einem Task
gearbeitet wurde.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung am System als User.
When: Wenn der User auf den Tabbar-Icon Taskliste klickt,
Then: dann sieht er alle Tasks, welche zu ihm gehören. Dort gibt es einen Wert namens
Worklog, wo ersichtlich wird, wie viel bereits an diesem Task gearbeitet wurde.
72Eigene User Stories dazu werden in Kapitel 4.19 und 4.20 definiert
83
4.13. User Story 12: Arbeitszeit erfassen (Autor: Rene Kassel)
4.13. User Story 12: Arbeitszeit erfassen (Autor: Rene Kassel)
User Story: Arbeitszeit erfassen
Als ein User möchte ich meine Arbeit an einem Task loggen.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung am System als User. Der User hat bereits die
Tasklisten-Ansicht aufgerufen und dort den Task ausgewählt, an welchem er gearbeitet hat.
Die Detailansicht des Tasks ist geöffnet.
When: Wenn der User den Worklog-Button klickt,
Then: dann öffnet sich eine neue Sicht.
Given: Gegeben ist eine gültige Anmeldung am System als User. Der User hat bereits die
Tasklisten-Ansicht aufgerufen und dort den Task ausgewählt, an welchem er gearbeitet hat.
Ebenso hat er die Detailansicht des Tasks geöffnet, und auf den Button geklickt, welcher die
neue Sicht, wo er die Arbeit loggen kann, öffnet.
When: Gibt der User dort den Wert über die getane Tätigkeit ein und klick auf absenden,
Then: dann wird die Arbeit geloggt.
Abnahmekriterien:
• Der Worklog-Button befindet sich in der Detail-Ansicht eines Tasks am unteren Ende im
Footer.
• Die Sicht zum Einstellen des Worklogs hat einen Schieberegler. Dabei ist der minimale
Wert null und der maximale Wert der geschätzte Wert (Estimated Value).
• Der Button log Work befindet sich an der oberen rechten Ecke und entspricht den original
Apple-Spezifikationen für einen Right-Bar-Button des UINavigationsControllers.
4.14. User Story 13: Userliste abrufen (Autor: Rene Kassel)
User Story: Userliste abrufen
Als ein User möchte ich eine Liste aller User abrufen, welche an dem aktuell geöffneten
Projekt beteiligt sind.
Conditions of Satisfaction:
Given: Der User muss mit einem validen Account am System angemeldet sein.
When: Klickt der User auf das Tabbar-Icon Userlist,
84
4.15. User Story 14: Userinfo einsehen (Autor: Rene Kassel)
Then: dann erscheint eine Liste von Usern, welche im Zusammenhang mit dem Projekt ste-
hen.
4.15. User Story 14: Userinfo einsehen (Autor: Rene Kassel)
User Story: Userinfo einsehen
Als ein User möchte ich aktuelle Informationen über meinen Account abrufen können.
Conditions of Satisfaction:
Given: Der User muss mit einem validen Account am System angemeldet sein.
When: Klickt der User auf das Tabbar-Icon Userinfo,
Then: dann öffnet sich eine neue Ansicht mit Nutzerdaten.
Abnahmekriterien:
• Die Details der Userinfo sollen zunächst aus Usernamen und Position bestehen.
4.16. User Story 15: Chat-Kontaktliste abrufen (Autor: Christopher Ezell)
User Story: Chat-Kontaktliste abrufen
Als ein User möchte ich einen Chatansicht aufrufen können, indem mir alle Kontakte
angezeigt werden.
Conditions of Satisfaction:
Given: Der User ist mit einem validen Account am System angemeldet.
When: Wenn der User auf das Chat-Symbol klickt,
Then: dann öffnet sich eine Ansicht, in der alle am Projekt beteiligten Personen mit ihrem
Online-Status angezeigt werden.
Given: Der User ist mit einem validen Account am System angemeldet. Zudem befindet sich
der User bereits in der Chat-Ansicht.
When: Wenn der User nun den Inhalt der Seite mit dem Finger nach unten schiebt,
Then: dann wird ein „Pull down to refresh“ erzeugt, sodass die Chat-Ansicht mit dem Online-
Status aktualisiert wird.
85
4.17. User Story 16: Chat-Gespräch mit einem bestimmten Nutzer(Autor: Christopher Ezell)
Abnahmekriterien:
• Der Online-Status unterteilt sich in Available und Offline.
• Der „Pull down to refresh“ soll kurz sichtbar sein. D.h. es soll erkennbar sein, dass gerade
ein Update auf die Sicht durchgeführt wird.
4.17. User Story 16: Chat-Gespräch mit einem bestimmtenNutzer(Autor: Christopher Ezell)
User Story: Chat-Gespräch mit einem bestimmten Nutzer
Als ein User möchte ich die Möglichkeit haben, mit einem bestimmten Projektbeteiligten
zu chatten.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung als User am System. Der User befindet sich in der
Chat-Ansicht.
When: Klickt der User nun auf einen bestimmten Kontakt,
Then: dann wird eine neue Ansicht zum chatten gestartet.
Given: Gegeben ist eine gültige Anmeldung als User am System. Der User hat bereits in der
Chat-Ansicht auf einen bestimmten Kontakt geklickt.
When: Wenn der User auf das Textfeld klickt,
Then: dann öffnet sich die Tastatur, sodass eine Nachricht eingegeben werden kann. Diese wird
dann mit dem Send-Button an den Gesprächspartner übersandt und im oberen Teil der Ansicht
angezeigt.
Abnahmekriterien:
• Die neue Ansicht, welche sich beim Klick auf einen bestimmten Nutzer öffnet, beinhal-
tet:
– Den Namen des Gesprächspartners oben in der Mitte der Ansicht,
– Ein Textfeld zur Eingabe der Chat-Nachricht,
– Einen Send-Button zum Absenden der Nachricht.
• Klickt der angemeldetet User auf das Textfeld, so fährt automatisch die Tastatur nach
oben.
• Es soll eine Möglichkeit geben, die Tastatur wieder einzufahren. Das ist dann hilfreich,
wenn der User die Absicht hat, den Chatverlauf nochmals nachzuvollziehen.
86
4.18. User Story 17: Task über QR-Code scannen (Autor: Rene Kassel)
• Es soll einen Button geben, der die Tastatur wieder ausblendet.
4.18. User Story 17: Task über QR-Code scannen (Autor: Rene Kassel)
User Story: Task über QR-Code scannen
Als ein User möchte ich einen bestimmten QR-Code einscannen, wodurch sich anschlie-
ßend der zugehörige Task öffnet.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung am System als User.
When: Wenn der User auf das Tabbar-Icon QR-Code klickt,
Then: dann öffnet sich eine neue Ansicht, welche einen Scan-Button besitzt.
Given: Gegeben ist eine gültige Anmeldung am System als User. Die Ansicht mit den Scan-
Button ist bereits geöffnet.
When: Klickt der User nun auf den Button,
Then: dann öffnet sich der Scanner, welchen der User an den QR-Code hält. Nach dem Scan-
vorgang öffnet sich sofort der Task, welcher mit dem QR-Code verschlüsselt wurde.
4.19. User Story 18: Benachrichtung per e-Mail (Autor: Christopher Ezell)
User Story: Benachrichtung per e-Mail
Als ein User möchte ich über Neuigkeiten, welche sich auf mein Projekt beziehen sowie
über mir neu zugewiesene Tasks per e-Mail benachrichtigt werden.
Conditions of Satisfaction:
Given: Es existiert ein User A und ein User B mit jeweils einem validen Account.
When: Wenn User A einen Task an User B vergibt,
Then: dann wird dem User B eine e-Mail über die Vergabe der Taskverantwortlichkeit zuge-
sandt.
Given: Es existiert ein User A und beliebig viele User B mit jeweils einem validen Account.
When: Wenn User A eine Neuigkeit postet,
Then: dann werden die beliebig vielen User B, vorausgesetzt sie stehen im Zusammenhang
mit der Neuigkeit, über diese mittels einer e-Mail Benachrichtigung informiert.
Given: Gegeben sind beliebig viele User mit jeweils einem validen Account.
When: Wenn das System eine Neuigkeit automatisch postet,
87
4.20. User Story 19: Offline Benachrichtung (Autor: Christopher Ezell)
Then: dann werden alle User, welche im Zusammenhang mit dieser Neuigkeit stehen, über
diese mittels einer e-Mail Benachrichtigung informiert.
Abnahmekriterien:
• Ein User steht im Zusammenhang mit einer Neuigkeit, sobald er dem gleichen Projekt
zugeordnet ist, wie jenes, woher die Neuigkeit stammt.
• Im Betreff der gesendeten e-Mail ist sofort zu erkennen, um welche Art es sich handelt.
Wurde dem Nutzer ein Task zugewiesen oder gibt es Neuigkeiten im Projekt.
• Der Inhalt der Mail ist entsprechend die Zuordnung der Taskverantwortlichkeit oder die
Neuigkeit selbst.
4.20. User Story 19: Offline Benachrichtung (Autor: Christopher Ezell)
User Story: Offline Benachrichtung
Als ein User möchte ich eine Offline (Push) Benachrichtigung auf meinem Smartphone
angezeigt bekommen wenn mir ein Task zugewiesen wird oder eine Neuigkeit bezüglich
meines Projektes gepostet wird.
Conditions of Satisfaction:
Given: Gegeben ist ein User A und ein User B mit jeweils einer installierten Smartphone-App.
Die User müssen einen validen Account besitzen und können online oder offline sein.
When: Wenn User B einen Task User A zuweist,
Then: dann bekommt User A eine Push-Benachichtigung über diese Zuweisung auf seinem
Smartphone.
Given: Gegeben sind ein User A und beliebig viele User B mit jeweils einer installierten
Smartphone-App. Die User müssen einen validen Account besitzen und können online oder
offline sein.
When: Wenn User A eine Neuigkeit postet,
Then: dann werden die beliebig vielen User B, vorausgesetzt sie stehen im Zusammenhang
mit der Neuigkeit, über diese mittels einer Push-Benachrichtigung auf ihren Smartphones in-
formiert.
Given: Gegeben sind beliebig viele User mit jeweils einer installierten Smartphone-App. Die
User müssen einen validen Account besitzen und können online oder offline sein.
When: Wenn das System eine Neuigkeit automatisch postet,
Then: dann werden alle User, welche im Zusammenhang mit dieser Neuigkeit stehen, über
diese mittels einer Push-Benachrichtigung auf ihren Smartphones informiert.
88
4.21. User Story 20: Verteilte Notizen einsehen (Autor: Christopher Ezell)
Abnahmekriterien:
• Ein User steht im Zusammenhang mit einer Neuigkeit, sobald er dem gleichen Projekt
zugeordnet ist, wie jenes, woher die Neuigkeit stammt.
• Die Push-Benachrichtigung öffnet ein Fenster bei allen beteiligten Projektpartnern mit
dem Inhalt der Nachricht.
• Der User kann die Anzeige der Push-Nachricht mit einem OK-Button beenden.
• Bei Ankunft der Nachricht ist ein Ton zu hören.
• Eine nicht beendete Push-Benachrichtigung wird in Form eines Badges73 angezeigt, so-
dass der Push nicht verloren geht.
4.21. User Story 20: Verteilte Notizen einsehen (Autor: Christopher Ezell)
User Story: Verteilte Notizen einsehen
Als ein User möchte ich mit anderen Projektmitgliedern gemeinschaftliche Notizen be-
sitzen und diese einsehen können.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung als User am System.
When: Klickt der User auf das Tabbar-Icon SimpleNote,
Then: dann öffnet sich eine Ansicht mit allen Notizen, welche dem Projekt angehörig sind.
Given: Gegeben ist eine gültige Anmeldung als User am System. Der User befindet sich in der
SimpleNote-Ansicht.
When: Wenn der Nutzer den Inhalt nach unten scrollt,
Then: dann wird ein „Pull down to refresh“ erzeugt, sodass die Notizen neu geladen werden.
Abnahmekriterien:
• Eine SimpleNote-Zelle beinhaltet eine Überschrift und die ersten zwei Zeilen des Inhal-
tes.
• Die Überschrift setzt sich aus den ersten 50 Zeichen des Inhaltes automatisch zusammen.
• Die Überschrift ist fett und etwas größer als die Vorschau für den Inhalt.
• Der „Pull down to refresh“ soll kurz sichtbar sein. D.h. es soll erkennbar sein, dass gerade
ein Update auf die Sicht durchgeführt wird.
73Badges sind kleine Zahlen, welche am App-Symbol hängen und über Neuigkeiten informieren
89
4.22. User Story 21: Verteilte Notizen bearbeiten (Autor: Christopher Ezell)
4.22. User Story 21: Verteilte Notizen bearbeiten (Autor: Christopher Ezell)
User Story: Verteilte Notizen bearbeiten
Als ein User möchte ich gemeinschaftliche Notizen mit anderen Projektmitgliedern be-
arbeiten können.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung als User am System. Der User befindet sich in der
SimpleNote-Ansicht.
When: Wenn der User auf eine bestimmte Nachricht klickt, SimpleNote,
Then: dann öffnet sich eine Ansicht zum Bearbeiten dieser Notiz.
Given: Gegeben ist eine gültige Anmeldung als User am System. Der User hat bereits auf eine
bestimmte Notiz in der SimpleNote-Ansicht geklickt.
When: Wenn der User nun in das Fenster klickt und seine Veränderungen eingibt und abschlie-
ßend auf den Safe-Button klickt,
Then: dann wird die Notiz in der veränderten Form abgespeichert. Sie ist dann für alle Pro-
jektmitglieder in dieser Form sichtbar.
Abnahmekriterien:
• Der Safe-Button befindet sich an der oberen rechten Ecke der Ansicht und entspricht den
original Apple-Spezifikationen für einen Right-Bar-Button des UINavigationsControl-
lers.
• Klickt der User in das Textfenster, dann beginnt der Bearbeiten-Modus.
• Sobald ein Zeichen eingetippt wird, wird der Safe-Button aktiv.
4.23. User Story 22: Shared Bookmarks einsehen (Autor: Rene Kassel)
User Story: Shared Bookmarks einsehen
Als ein User möchte ich mit meinen Projektmitgliedern eine Sammlung von Lesezeichen
besitzen und diese jederzeit einsehen können.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung als User am System.
When: Wenn der User auf das Tabbar-Icon DiigoTags klickt,
90
4.24. User Story 23: verteiltes Planningpoker durchführen (Autor: Christopher Ezell)
Then: dann wird zunächst eine Ansicht der Lesezeichen aufgeschlüsselt nach vergebenen Tags
aufgezeigt.
Given: Gegeben ist eine gültige Anmeldung als User am System. Der User befindet sich in der
Tag-Ansicht.
When: Wenn der User dort einen bestimmten Tag anklickt,
Then: dann werden ihm alle dem Tag untergliederten Lesezeichen angezeigt.
Given: Gegeben ist eine gültige Anmeldung als User am System. Der User befindet sich in der
Lesezeichen-Ansicht.
When: Klickt der User dort ein bestimmtes Lesezeichen an,
Then: dann öffnet sich ein in der App integrierter Webbrowser, welcher den Inhalt der Webseite
anzeigt.
Abnahmekriterien:
• In der Tag-Ansicht steht als Überschrift „Tags“.
• In der Lesezeichen-Ansicht steht als Überschrift „Diigo Links“.
• Der User kann jederzeit zwischen Web-Ansicht, Lesezeichen-Ansicht und Tag-Ansicht
umher schalten.
4.24. User Story 23: verteiltes Planningpoker durchführen (Autor:Christopher Ezell)
User Story: verteiltes Planningpoker durchführen
Als ein User möchte ich Planningpoker mit verteilten Teammitgliedern durchführen kön-
nen.
Conditions of Satisfaction:
Given: Gegeben ist eine gültige Anmeldung als User am System. Der User befindet sich in der
Planning-Poker-Ansicht.
When: Wenn der User auf einen Planningpoker starten-Button klickt,
Then: dann öffnet sich eine neue Ansicht zum Auswählen des Tasks und dem anschließenden
Durchführen des Planningpokers, welches in Kapitel 3.1.3 beschrieben ist.
Given: Gegeben ist eine gültige Anmeldung als User am System. Der User befindet sich in der
Planning-Poker-Ansicht. Der User hat bereits einen Task gewählt.
When: Wenn der User auf eine Karte klickt,
Then: dann wartet das System, bis alle Beteiligten ihre Karte gewählt haben und zeigt anschlie-
ßend dem User alle Werte der Beteiligten an.
91
4.25. Zusammenfassung (Autor: Rene Kassel)
Abnahmekriterien:
• Die auszuwählenden Tasks sind in einer Liste angeordnet.
• Das Planningpoker beinhaltet die Karten 0, 1, 3, 5, 8, 15, 25, 50, 100, unendlich und
einen Joker.
• Bei Gleichheit der Karten von allen Nutzern wird das Planningpoker beendet und der
Wert automatisch an den Server übertragen. Dies ist der geschätzte Aufwand zum Task.
• Sind die Werte nicht gleich, wird eine erneute Auswahlrunde gestartet.
4.25. Zusammenfassung (Autor: Rene Kassel)
Nachdem nun die User Stories definiert wurden, kann die spezielle Konzipierung der Anwen-
dung begonnen werden. Das nächste Kapitel gibt einen grundlegenden Überblick über das
System und erklärt deren Funktionsweise.
92
5. Konzeption (Autoren: Christopher Ezell und Rene Kassel)
5. Konzeption (Autoren: Christopher Ezell und Rene Kassel)
Im Kapitel 2.8 (Die ausgewählten Kommunikationskanäle) wurde ermittelt, welche Tools in
einem Projekt nicht fehlen sollten und wozu diese eingesetzt werden können, zusammenge-
fasst in einer Liste. In diesem Kapitel dient die Liste als Grundlage. Die verschiedenen Tools
werden in eine gewisse Form gebracht und es wird daraus prototypisch eine Projektplattform
entwickelt. Sie ermöglicht den Projektmitgliedern leichter und schneller den Kontakt mit ei-
nem anderem Projektmitglied aufzunehmen, sowie Nachrichten und Informationen auf einem
angemessenen Weg zu kommunizieren. Der Hauptfokus liegt auf der sozialen Interaktion der
einzelnen Teammitglieder untereinander.
Es wird in diesem Kapitel sowohl der Rahmen, als auch die Architektur der resultierenden An-
wendung, festgelegt. Die daraus resultierende Implementierung stellt nur einen Prototypen74
dar, um die Machbarkeit einer solchen Plattform zu demonstrieren. Aus diesem Grund sind
nicht alle Features im Rahmen der Arbeit implementiert, welche in der Konzeption angedacht
werden. Für manche Funktionen der Plattform werden externe Dienste gewählt, die die gefor-
derten Aufgaben vollständig erfüllen. In diesem Fall wird schon innerhalb der Konzeption auf
die entsprechenden externen Dienste eingegangen und deren Verwendung erläutert.
Die Abbildung 5.1 zeigt die Plattform, wie sie im Endstadium aussehen soll. Dabei existiert
keine Einteilung der Dienste, da sich im Endstadium der Plattform keiner externen Dienste be-
dient werden soll. Der Grund hierfür ist die bessere Kontrollierbarkeit der gespeicherten Daten
innerhalb dieser Dienste. Die Plattform ist eine zentrale Einheit zur Kommunikation zwischen
den einzelnen Clients. Sie verbindet die Clients mithilfe von Konnektoren an verschiedene
Kommunikations- und Kollaborationsdienste. Dafür verbinden sich die Clients mittels eines
Konnektors an die dafür von der Plattform definierte REST-Schnittstelle. Über diese können
alle Funktionen verwendet werden.
Da lediglich die Machbarkeit einer solchen Plattform behandelt wird, wird in der Konzepti-
on ein anderer Aufbau der Projektplattform vorgenommen. An dieser Stelle wird durch die
Autoren eine Einteilung der Dienste vorgenommen. Abbildung 5.2 zeigt eine Übersicht der
verschiedenen Arten von Diensten in der Plattform. Die Plattform ist in vier separate (logi-
sche) Teile getrennt. Dies bietet Vorteile bei der Konzeption, da selbst implementierte Dienste
und andere Dienste besser getrennt werden können. Im weiteren Verlauf der Arbeit werden
diese vier Teile getrennt voneinander betrachtet.
74Das heißt, es stellt nur eine der möglichen Umsetzungen dar.
93
5. Konzeption (Autoren: Christopher Ezell und Rene Kassel)
Abbildung 5.1.: Aufbau der Projektplattform (ideal) (Quelle: Eigene Darstellung)
Der erste Teil beinhaltet alle Dienste, die auf dem projekteigenen Server laufen75, aber nicht
selbst programmiert werden. Diese werden im Kapitel 5.2 betrachtet. Sie zählen daher zu den
internen Services/Diensten.
Im Kapitel 5.3 werden anschließend die externen Services/Dienste aufgegriffen. Diese sind
nicht auf dem projekteigenen Server installiert, sondern werden komplett von externen Anbie-
tern verwendet.
Die dritte Art von Diensten stellen die selbst implementierten Dienste76 dar. Sie werden nach-
folgend als Serverkomponente bezeichnet und sind im Kapitel 5.4 spezifiziert.
Der vierte und letzte Teil befasst sich mit der Clientanwendung. Sie wird in Form einer
iPhone-Anwendung realisiert und ist in Kapitel 5.5 definiert. Grundlage für die in diesem Ka-
pitel klassifizierten Typen von Diensten ist die Tabelle in Kapitel 2.8.14.
Für eine bessere Übersicht bezüglich der Diensteinteilung ist in Abbildung 5.3 eine schema-
tische Darstellung der gesamten Dienstarten dargestellt. Diese Abbildung umfasst nicht die
Clientanwendung. Sie enthält alle erwähnten Kommunikationsmittel und gliedert sie in die
oben erwähnten drei Arten von Diensten. Die Abbildung zeigt vier Ellipsen, die die drei ver-
schiedenen Arten von Diensten repräsentieren.
Die erste Ellipse zeigt die Dienste Audio-Chat, Screen Sharing und Instant Messaging. Sie
laufen auf dem projekteigenen Server. Die drei Dienste erhalten einen Konnektor in der Ser-verkomponente. Der Dienst Instant Messaging bekommt zusätzlich einen Konnektor in der
Clientanwendung.
75Alle Anwendungen wurden auf einem projekteigenen Server installiert. Dieser ist im Internet zu erreichen undermöglicht das Testen der Anwendung im Mobilfunknetz.
76In der Abbildung als Applikation Server bezeichnet.
94
5.1. Allgemeine Hinweise und Datenschutz (Autoren: Christopher Ezell und Rene Kassel)
Abbildung 5.2.: Übersicht der verschiedenen Dienste in der Plattform (Quelle: EigeneDarstellung)
Die zweite Ellipse zeigt die Dienste Notizen-Sync, Shared Storage und Social Bookmarking.
Sie sind, wie an der Markierung zu erkennen ist, weder Teil der Eigenimplementierung noch
Teil der Eigeninstallation, sondern werden komplett von externen Anbietern genutzt. Dabei
zählen sie zu den externen Diensten. Für alle diese Dienste wird ein Konnektor innerhalb der
Clientanwendung implementiert.
Die dritte Ellipse zeigt die Dienste Blog, Wiki, Collaboration Pad und Codeverwaltung. Diese
werden auf dem projekteigenen Server installiert. Sie erhalten weder einen Konnektor für die
Serverkomponente noch für die Clientanwendung.
Abschließend stellt die vierte Ellipse die Java-Webanwendung dar, welches das Herzstück der
Plattform ist. Sie repräsentiert innerhalb der Arbeit die Eigenimplementierung auf der Server-
seite. Die Webanwendung enthält die Dienste Aufgabenverwaltung, Mircoblogging und stand-
ortbezogene soziale Netze.
5.1. Allgemeine Hinweise und Datenschutz (Autoren: Christopher Ezell und Rene Kassel)
Bevor die Konzeption dieser Anwendung vorgenommen wird, soll noch ein Sachverhalt ge-
klärt werden. In dieser Konzeption werden für einige Dienste externe Dienstleister benutzt, um
den Aufwand für die Implementierung gering zu halten. In einer produktiv laufenden Kommu-
nikationsplattform können alle Dienste entweder auf eigenen Systemen laufen oder auf Syste-
men von Drittanbietern, mit denen ein Datenschutzabkommen definiert wird. Ansonsten kann
bei der Kommunikation von vertraulichen Daten nicht gewährleistet werden, dass diese auch
95
5.2. Konzeption der internen Dienste (Autor: Rene Kassel)
Abbildung 5.3.: Aufbau der Projektplattform (Quelle: Eigene Darstellung)
innerhalb des Teams bleiben. In der Praxis kommt es immer wieder vor, dass bei firmenüber-
greifenden Kommunikationswegen, bei der kein eigener Kommunikationsserver existiert, auf
teilweise kostenlose Anbieter zurückgegriffen wird. Ein Beispiel dafür ist Skype als Anbieter
für Instant Messaging, Audio- und Video-Chat. In einem solchem Szenario kann nur schwer
bis gar nicht nachvollzogen werden, wie die teilweise vertraulichen Informationen von dem ex-
ternen Anbieter weiterverarbeitet werden. Der Vorteil in der Nutzung einer eigenen Plattform
ist, dass in so einer Umgebung die kommunizierten Daten besser gegenüber anderen Parteien
geschützt sind.
5.2. Konzeption der internen Dienste (Autor: Rene Kassel)
Es wird hier zuerst auf die internen Dienste eingegangen. Folgende Dienste kommen zur Ver-
wendung:
• das XMPP,
• die Codeverwaltung (Subversion),
• der Blog,
• das Wiki und
• das Collaboration Pad.
Die drei Dienste der ersten Ellipse in Abbildung 5.3, Audio-Chat, Screen-Sharing und Instant
Messaging, sollen über einen XMPP-Server mit dem XMPP-Protokoll umgesetzt werden. Wie
in Kapitel 3.2.6 erläutert, eignet sich das Protokoll sehr gut für die genannten Interaktionsmög-
lichkeiten.
96
5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel)
Bei dem zu entwickelnden Prototypen wird sich für den XMPP-Server Openfire entschieden,
da er alle oben genannten Features unterstützt und sehr ressourcenschonend arbeitet. Außerdem
ist die Installation sehr leicht und kann schnell durchgeführt werden. Abbildung A.3 zeigt die
Web-Administrationsoberfläche von Openfire. Hier müssen nur noch die entsprechenden User
angelegt werden, damit der Server komplett eingerichtet ist. Da es für das XMPP-Protokoll
sowohl auf Client- als auch auf Serverseite fertige Bibliotheken zur Einbindung von XMPP
gibt, wird die API hier nicht weiter erläutert. Diese Dienste stellen einen großen Teil der Säu-
len aus Kapitel 2.8 dar. Sie werden zum Teil mittels einen Konnektors als Datenquelle in die
Serverkomponente und die Clientanwendung eingebunden.
Der SVN-Server wird für die gemeinsame Codeverwaltung installiert. Er ist auch sehr leicht
in der Handhabung. Der Zugang zu dem Server ist über das Secure Shell-Protokoll (SSH)
realisiert. Eine Einbindung in die beiden Anwendungen mittels Konnektoren braucht an dieser
Stelle nicht erfolgen.
Für das Wiki wurde sich für Media-Wiki entschieden. Hier ist ebenso der Fokus auf die Ein-
fachheit gelegt. Es ist schnell installiert und benötigt lediglich einen Webserver und eine Da-
tenbank für den Betrieb. Da weder eine Integration von SVN noch von MediaWiki geplant ist,
wird nicht weiter auf die Integration eingegangen.
Der Blog ist für größere Ankündigungen und Erklärungen für neu verwendete Techniken ge-
dacht. Hier können auch längere Artikel verfasst werden. Es erfolgt keine Einbindung in die
Server- bzw. Clientanwendung.
Ein größerer Punkt bei der Inbetriebnahme stellt das Collaboration-Pad dar. Hier ist die Ent-
scheidung auf Etherpad gefallen. Etherpad ist eine sehr schöne Weblösung für die kollaborative
Zusammenarbeit. Um einen Etherpad-Server zu installieren, ist eine Datenbank nötig. Das Pa-
ket muss selbst kompiliert und konfiguriert werden. Es bietet einige sehr gute und vor allem
performante Features, die die Entscheidung dafür rechtfertigen. Nach der Installation ist es
sofort nutzbar und sehr robust. In Etherpad gibt es nur zwei Ansichten. Die Startseite enthält
lediglich zwei Buttons. Der Eine ist ein Button für das Starten eines neuen Pads und der Andere
ist zum Einrichten einer Teamseite vorhanden. Ein Pad ist in Abbildung A.9 ersichtlich. Es ent-
hält eine große Bearbeitungsfläche in der Mitte. Diese kann von mehreren Nutzern gleichzeitig
bearbeitet werden. Auf der rechten Seite befindet sich der interne Chat für jedes einzelne Pad.
Genauere Informationen zu der dahinter stehenden Technik kann in Kapitel 2.8.2 nachgelesen
werden.
5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel)
In diesem Kapitel wird kurz auf die externen Dienste eingegangen. Sie werden für die Um-
setzung der Plattform vorgesehen, sind aber nicht Teil der Eigenimplementierung. Es wird nur
kurz auf die Nutzung der externen Dienste eingegangen. Eine gute Übersicht bieten die Ab-
bildungen A.11 und A.12. Sie zeigen unter anderem das Deployment der Services auf den
97
5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel)
unterschiedlichen Geräten. Die Dienste, die in diesem Kapitel behandelt werden, laufen auf
externen Servern. Explizit handelt es sich bei den Diensten um jene aus der zweiten Ellipse der
Abbildung 5.3. Da die Integration der betreffenden Diensten mit in die Eigenimplementierung
einfließt, wird hier jeweils kurz auf die API des Dienstes und deren Nutzung eingegangen. Es
handelt sich um die folgenden Dienste:
• das Social Bookmarking,
• das Shared Storage,
• die Shared Notes und
• der Apple Push Service.
5.3.1. Social Bookmarking (Autor: Rene Kassel)
Als Social Bookmarking-Dienst wird Diigo eingesetzt, da Diigo eine sehr einfache und REST-
konforme API hat. Diese ist auf [Tea12] dokumentiert. Generell werden die Informationen bei
Diigo über JSON ausgetauscht. Wie die Abbildung A.12 zeigt, kommuniziert ausschließlich
der Client mit der Diigo-API. Eine Integration in die Serverkomponente ist nicht vorgesehen.
Somit wird lediglich ein Konnektor für die Clientanwendung benötigt. Es können über die API
Links angelegt und verändert werden. Die komplette Interaktion erfolgt mittels Usernamen und
Passwort und mit Hilfe von HTTP Basic Authentifizierungen (vgl. [Inc12]).
Es werden von Diigo die zwei Verben GET und POST unterstützt. GET liest alle oder eine
bestimmte Anzahl an gespeicherten Bookmarks. Dies ist über einen Parameter einstellbar. Das
Listing 5.1 zeigt einen Beispielaufruf der API, mit dem ein Bookmark gelesen werden kann.
Die Antwort auf diesen Aufruf ist in Listing 5.2 zu sehen.
Listing 5.1: Beispiel eines API-Aufrufes der Diigo-API (Lesen eines Bookmarks)
1 GET https://secure.diigo.com/api/v2/bookmarks?user=XXX&count=1
Listing 5.2: Beispiel einer Diigo-Antwort in Form von JSON
1 [{ "updated_at":"2012/05/15 14:10:32+0000",
2 "url":"http://www.i.de/",
3 "annotations":[],
4 "user":"XXX",
5 "readlater":"yes",
6 "shared":"yes",
7 "tags":"no_tag",
8 "created_at":"2012/05/15 14:10:32 +0000",
9 "title":"Title1",
10 "comments":[],
11 "desc":"" }]
98
5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel)
Ein neuer Bookmark kann mit dem Aufruf in Listing 5.3 angelegt werden. Der große Vorteil
von Diigo ist die sehr gute Weboberfläche zum Verwalten der existierenden Links und Browser-
Plugins für alle gängigen Browser. Die Weboberfläche zeigt die Abbildung A.15.
Listing 5.3: Beispiel eines POST-Aufrufes zum Erstellen eines neuen Links
1 POST https://secure.diigo.com/api/v2/bookmarks
2 ?url=http%3A%2F%2Fwww.diigo.com&tags=diigo,bookmark,highlight&
shared=yes
Wie in der URL im Listing zu sehen ist, werden bei dem Aufruf bereits alle Parameter für
das Objekt mitgegeben. So steht nach diesem Aufruf sofort das fertige Objekt zur weiteren
Verarbeitung zur Verfügung.
5.3.2. Shared Notes (Autor: Christopher Ezell)
Shared Notes ermöglicht es über mehrere Entwickler einen Bestand an Notizen zu halten, die
jeder Entwickler einsehen und verändern kann. Es wird an dieser Stelle der Dienst Simple No-
tes eines Drittanbieters verwendet. Es ist ein sehr schlanker und performanter Dienst, der eine
REST-API anbietet. Der Wurzelknoten der API ist https://simple-note.appspot.
com/api2. Im Gegensatz zu Diigo hat Simple Notes einen anderen Ansatz: Über die API
muss ein Token angefordert werden. Dieses Token wird anschließend bei jedem Aufruf der
API angegeben. Es ist über den Aufruf einer Authentifizierungs-URL abrufbar und kann mit
Nutzernamen und Passwort eingeholt werden. Danach wird nur noch das Token und der Nut-
zername benötigt, nicht mehr das Passwort. Das Token verfällt nach 24 Stunden automatisch.
Bei dem Beispielaufruf in Listing 5.4 erhält der Client eine Liste von Notizen. Diese enthalten
aber nur Metadaten der jeweiligen Datensätze. Um an den Inhalt der Notizen zu kommen,
muss für jede Notiz die jeweilige URL aufgerufen werden. Listing 5.5 zeigt einen solchen
Beispielaufruf einer Notiz mit der ID 123. Der Rückgabeinhalt ist dabei der Gleiche. Hinzu
kommt lediglich zusätzliches Feld namens content.
Listing 5.4: Beispiel eines GET-Aufrufes zum Abrufen von Links von allen Notizen
1 GET https://simple-note.appspot.com/api2/index?length=100&mark
=&since=&auth=xxx&email=xxx
2 Antwort:
3 {
4 count: 25,
5 data: [
6 {
7 modifydate: "1324202852.963336",
8 tags: [ ],
9 deleted: 1,
99
5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel)
10 createdate: "1324202564.364233",
11 systemtags: [ ],
12 version: 0,
13 syncnum: 2,
14 key: "123",
15 minversion: 1
16 } ] ,
17 time: "1346362216.891024"
18 }
Mit der URL einer Notiz kann GET aufgerufen werden, um den Inhalt abzufragen. Die anderen
Methoden, wie PUT und DELETE, werden nicht unterstützt. Dies entspricht nicht den REST-
Prinzipien laut [Til11]. Um eine Notiz zu speichern, wird die URL mit einem PUT aufgerufen.
Das Löschen erfolgt über das Setzen des Wertes deleted. Dies ist bei der Beispielnotiz im
Listing bereits gesetzt. Das Flag77 mit dem Namen deleted im Listing 5.4 muss vom Client
explizit ausgewertet werden. Diese Auswertung erfolgt, da gelöschte Notizen auch von der API
zurückgesendet werden.
Listing 5.5: Beispiel einer Diigo-Antwort einer Notiz in Form von JSON
1 GET https://simple-note.appspot.com/api2/data/123?auth=xxx&
email=xxx
2 Antwort:
3 {
4 modifydate: "1324202852.963336",
5 tags: [ ],
6 deleted: 1,
7 createdate: "1324202564.364233",
8 systemtags: [ ],
9 content: "hello world",
10 version: 0,
11 syncnum: 2,
12 key: "123",
13 minversion: 1
14 }
5.3.3. Shared Storage (Autor: Rene Kassel)
Shared Storage ist ein perfektes Werkzeug um größere Mengen an Daten abzulegen. Es wer-
den innerhalb des Projektes zwei Arten von Shared Storage verwendet. Zum Einen der bereits
77Ein Flag ist eine Variable vom Typ Boolean.
100
5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel)
vorgestellte Dienst Dropbox, der in Kapitel 2.8.10 beschrieben wurde, und zum Anderen Apa-
che Jackrabbit. Dropbox wird zum Synchronisieren von Dateien zwischen den Entwicklern
genutzt. Apache Jackrabbit wird von dem implementierten Server genutzt, um Dateien abzu-
legen. Jackrabbit bietet eine Webdav-Schnittstelle um auf die Daten zuzugreifen. Wie in Ab-
bildung A.11 dargestellt, kommuniziert nur die Serveranwendung direkt mit dem Jackrabbit-
Server. Er wird dafür genutzt, die generierten QR-Codes zu speichern und abzurufen. Das
Jackrabbit-Projekt bringt eine Möglickeit mit, sich mit einem Client über eine Java Remote
Method Invocation (RMI)-Schnittstelle auf eine Jackrabbit-Instanz zu verbinden. Hierzu wird
lediglich die URL benötigt, auf die der Server konfiguriert ist. Daher wird nicht weiter darauf
eingegangen.
5.3.4. Apple Push Service (Autor: Christopher Ezell)
Der Apple Push Service ist ein zentraler Dienst zum Versenden einer Push-Benachrichtigung an
eine iOS-Device (vgl. [App12b]). Durch die Nutzung dieses Services kann jeder andere Service
eine Push-Benachrichtigung an ein bestimmtes Gerät eines Teammitglieds versenden.
Abbildung 5.4.: Genereller Ablauf einer Apple Push-Nachricht (Quelle: [App12b])
Abbildung 5.4 zeigt den generellen Ablauf einer Apple Remote Push Notification (ARPN).
Alle Push-Benachrichtigungen gehen zentral über den Apple-Push-Server. Diese müssen pro
Device angefragt werden. Die Abbildung zeigt einen Provider, der eine eine Notification an
bestimmtes Gerät senden möchte. Dabei geht die Notification den Weg über den Apple Push
Notification Service. Dieser ordnet die Benachrichtigung dem registrierten Gerät zu und schickt
sie dorthin. Anschließend wird innerhalb des iPhone-Betriebssystems die Notification einer
Client-App zugeordnet, sodass sie angezeigt werden kann.
Listing 5.6: JSON-Repräsentation einer ARPN (Quelle:[App12b])
1 {
2 "aps" : { "alert" : "Message received from Bob" },
3 "acme2" : [ "bang", "whiz" ]
4 }
Bei diesem Prozess wird von dem Push-Provider eine Push-Benachrichtigung in Form eines
JSON-Strings an den Server von Apple geschickt. Eine simple alert-Benachrichtigung wird in
Listing 5.6 gezeigt.
101
5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)
5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)
Dieses Kapitel befasst sich mit der Konzeption der Eigenimplementierung. Die Eigenimple-
mentierung besteht aus einer Web-Applikation, welche in einem JavaEE78-Server läuft.
Generell ist die Aufgabe dieses Servers, die iPhone-Applikation in der Erfüllung der in Kapitel
4 gestellten User Stories zu unterstützen. Für die Applikation werden die Daten zentral auf dem
Server abgelegt. Der Client79 hält also keine persistenten Daten, sondern fragt diese immer vom
Server ab. Der Server hält alle Daten von allen Clients persistent. Nach außen hin bietet der
Server eine REST-Schnittstelle an, über die sich der Client anmelden und die Daten abfragen
kann. Ebenso bietet er zusätzliche Funktionalität zum Verwalten und Bearbeiten der Daten. Es
werden die folgenden Funktionalitäten auf dem Server umgesetzt:
• die Aufgabenverwaltung,
• das Microblogging,
• ein Anmeldeservice,
• das Planningpoker,
• der Push-Service und
• der RSS-Service.
Bei der Architektur der Server-Anwendung wird sich für das MVC-Pattern (Model View Con-
troller) entschieden. Demzufolge teilt sich die Webapplikation in drei logische Teile. Den ers-
ten Teil bildet das View, das durch eine REST-API implementiert ist. Diese bietet dem Client
die Möglichkeit über HTTP mit allen Basis-Objekten „direkt“ zu interagieren80. Das View
leitet die erhaltenen Befehle an den Controller weiter. Der Controller ist der zweiten der We-
bapplikation. Dieser führt die zu tätigenden Anweisungen aus und leitet die Änderungen an
das Model weiter. Der Controller ist durch eine Menge von Services implementiert, die mit
Model und View kommunizieren. Im Model sind letztendlich verschiedene Konnektoren im-
plementiert. Diese verknüpfen die Services im Controller-Teil mit verschiedenen Datenquellen
und Diensten im Internet.
5.4.1. View (Autor: Christopher Ezell)
Wie oben erwähnt, ist die View eine auf den REST(HTTP)-Prinzipien aufgebaute API, die
mittels XML kommuniziert81. Das View delegiert alle Aufrufe an den Controller und kommu-
niziert die Rückgabewerte an den abfragenden Client zurück.
78Java Platform Enterprise Edition79die iPhone-Applikation80Genau genommen über die REST-Endpunkte und die Verben aus HTTP.81REST basiert auf den Prinzipien des HTTP-Protokolls und ist dadurch im Gegensatz zu SOAP(Simple Object
Access Protocol) eine sehr schlanke Form der Kommunikation und ist vielseitig einsetzbar.
102
5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)
Es werden nun die Interfaces für die verschiedenen Aufgaben definiert. Nur Teile der in den
User Stories definierten Funktionalitäten werden implementiert. Die anderen Funktionalitäten
laufen bei externen Anbietern und werden vom Client direkt aufgerufen. Die zu implementie-
renden Funktionalitäten sind die Aufgabenverwaltung und der NewsStream. Hierfür müssen
noch diverse andere Dienste eingebunden werden, dazu mehr in Kapitel 5.4.3.
Der Aufbau der Pfade in REST ähnelt einer Baumstruktur. Daher hat eine REST-basierte An-
wendung immer einen Wurzelknoten. Hieraus entstehen alle anderen Knoten. Der Wurzelkno-
ten ist in der Anwendung unter /rest erreichbar. Darunter befinden sich die Knoten /users,
/news, /push, /health und /auth. Diese werden nun nacheinander erläutert. Einen bes-
seren Überblick über die Struktur zeigt die Abbildung 5.5. Die dargestellten Knoten sind die
Hauptressourcen innerhalb der implementierten Plattform.
Abbildung 5.5.: Aufbau der REST-Services (Quelle: Eigene Darstellung)
Der Knoten /users ist der Einstiegspunkt für die Verwaltung von Userdaten. Es können auf
diesem Knoten die HTTP-Methoden GET und POST aufgerufen werden. Wie in Kapitel 3.2.5
beschrieben wurde, dient ein GET, um die Ressource abzufragen82. Es werden alle User zu-
rückgegeben, da das GET auf den ganzen Knoten der User ausgeführt wird. Ein POST liefert
eine ID des neues Objektes. Eine Befehlsübersicht ist in der unten stehenden Tabelle darge-
stellt.
Knoten Methode Inhalt Anfrage Inhalt Antwort/rest/users GET kein Inhalt alle existierenden User
/rest/users POST kein Inhalt 201, ID des neu angelegten Users
/rest/users/userID GET kein Inhalt den User mit der ID = userID/rest/users/userID PUT ScrumUser-Objekt (neu) 200 Den User mit neuen Werten
/rest/users/userID DELETE kein Inhalt 200
82Dies ist in Listing 5.7 zu sehen.
103
5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)
Listing 5.7: Die XML-Darstellung eines SrumUser-Objektes1 <scrumUser>2 <deviceId>7b...88</deviceId>3 <id>1346020087078</id>4 <latitude>52.5172503</latitude>5 <location>none</location>6 <longitude>13.3949287</longitude>7 <name>defaultUser</name>8 <status>busy</status>9 </scrumUser>
Der Knoten /auth/userName ist für die Authentifizierung der User und besitzt nur eine
Methode. Diese Methode kann mit dem Verb POST aufgerufen werden. Hinzu kommt der Pfad-
Parameter userName. Dieser stellt den Anmeldenamen des Users dar und muss vom Client
mit dem entsprechenden Wert gefüllt werden. Im Content-Bereich der Anfrage müssen die
Credentials83 des Users mitgegeben werden. Eine Beispielanfrage ist in Listing 5.8 dargestellt.
Die Rückgabe ist der komplette User. Die Antwort kann vom Client dazu verwendet werden,
die aktuellen Werte des Users zu speichern.
Listing 5.8: Delegate-Methoden des Protokolls RKRequestDelegate1 curl -X POST -d \2 ’<login-credentials><password>geheim</password></login-
credentials>’ \3 http://SERVER/rest/auth/iphone -v4
5 > POST /rest/auth/iphone HTTP/1.16 ...7 < HTTP/1.1 200 OK8 ...9
10 <scrumUser>11 <deviceId>...</deviceId><id>1346013911583</id>12 <jabbername>[email protected]</jabbername>13 <latitude>0.000000</latitude>14 <location></location><longitude>0.000000</longitude>15 <name>iphone</name><status>Bin heute in Muenchen.</status>16 </scrumUser>
In der Tabelle Label ist die Methode mit Parametern eingetragen(Klingt komisch). Wichtig ist
hier, dass im Fehlerfall Statuscodes vom Client verarbeitet werden müssen. Im Falle, dass der
Client ein ungültiges XML schickt, wird der Statuscode 422 (Unprocessable Entity) zurück
gesendet. Wenn die Userdaten nicht korrekt sind, wird ein 403 (Forbidden) geschickt.
Knoten Methode Inhalt Anfrage Statuscode, Inhalt der Antwort/rest/auth/username POST User Credentials 200 und den entsprechenden User
/rest/auth/username POST invalides XML 422 invalides XML
/rest/auth/username POST invalide Credentials 403 (User nicht valide)
83Das deutsche Wort dafür ist: Berechtigungsnachweis. Das sind im Allgemeinen Username und Passwort desjeweiligen Nutzers.
104
5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)
Die News haben den Knoten /news und können darüber erstellt und abgefragt werden. Die
Tabelle zeigt alle relevanten Methoden auf dem News-Knoten mit Parametern. Die Handha-
bung ist ähnlich zu dem User-Knoten. Die Schnittstelle wird in der unten stehenden Tabelle
beschrieben.
Knoten Methode Inhalt Anfrage Inhalt Antwort/rest/news GET kein Inhalt alle existierenden News
/rest/news POST kein Inhalt 201, ID der neu angelegten News
/rest/news/newsID GET kein Inhalt die News mit der ID = newsID/rest/news/newsID PUT News-Objekt (neu) 200 das News-Objekt mit neuen Werten
/rest/news/newsID DELETE kein Inhalt 200
Bei dem Knoten /push/ID kann an ein iPhone, das einem User zugeordnet ist, eine Push-
Benachrichtigung gesendet werden. Diese wird als Content in dem Aufruf mit gesendet. Die
Tabelle zeigt alle relevanten Methoden, die auf diesen Knoten aufgerufen werden können.
Knoten Methode Inhalt Anfrage Inhalt Antwort/rest/push/device-id POST Inhalt der Nachricht 200
/rest/push/user-id POST Inhalt der Nachricht t 200
Bei dem Knoten /health kann ein iPhone die Verfügbarkeit des Servers prüfen. Dieser Kno-
ten kann nur mit GET aufgerufen werden und liefert den Statuscode 200 zurück, wenn er ver-
fügbar ist.
Knoten Methode Inhalt Anfrage Inhalt Antwort/rest/health/ GET LEER 200
5.4.2. Controller (Autor: Christopher Ezell)
Der Controller beinhaltet die gesamte Geschäftslogik, die für die Plattform nötig ist. Diese
Logik ist in verschiedene Services unterteilt. Hier gibt es zwei Arten von Services. Die Services
der unteren Ebene (hier Basis-Services genannt) verbinden die Plattform über Konnektoren mit
den externen und internen Diensten. Beispiele dafür sind das Generieren eines QR-Codes oder
das Senden einer Push-Notification. Die Services der oberen Ebene verwenden die Services der
unteren Ebene und bündeln diese zu kompletten Funktionalitäten. Beispiele für solche Services
sind hier das Erstellen oder das Ändern eines Tasks.
Die Konnektoren stellen die Verbindung zum Model dar. Das Model bezeichnet in diesem
Fall alles, was eine Interaktion mit der Außenwelt darstellt. Die Verbindung von dem View
zu den Services ist in Abbildung 5.6 dargestellt. Jede Klasse in dem View hat eine Referenz
zu dem Context-Service. Der Context-Service ist ein übergeordneter Service, der
die anderen Services verwaltet. Er wird als einziger Service zu Beginn geladen und startet
alle anderen Services. Er wird über die Web-Applikation injiziert. Er hält alle Referenzen auf
die anderen Services. So kann ein View auf alle Services zugreifen und sehr effizient seine
105
5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)
Aufgaben erledigen, da nur der richtige Service geholt werden und eine Methode aufgerufen
werden muss. So ist die Trennung zwischen View und Controller sehr gut gelöst.
Abbildung 5.6.: Die Verbindung von den Services zu der View (Quelle: Eigene Darstellung)
Zusätzlich gibt es unterschiedliche Arten von Services. Es gibt zum Einen die Services, die nur
die Schnittstelle zu einem Konnektor kapseln, und zum Anderen die Services, die eine komplet-
te Funktionalität bieten. Beide können über den Context-Service aufgerufen werden. Bei den
Services, die nur die Funktionalität eines Konnektors kapseln, sind die folgenden definiert:
• Push-Service: Dabei handelt es sich um ein Service, der auf die Push-API von Apple zu-
greift und auf einzelne oder alle iPhones eine Push-Benachrichtigung erscheinen lassen
kann.
• Storage-Service: Der Storage-Service ist für die Speicherung von Dateien in die Webdav-
Schnittstelle verantwortlich.
• Mail-Service: Dieser Service befähigt die Anwendung E-Mails an registrierte Nutzer zu
senden, wenn eine Aktion notwendig ist oder eine Benachrichtigung gesendet werden
soll.
• QR-Code-Service: Der QR-Code-Service dient dazu innerhalb der Plattform das Gene-
rieren von QR-Codes aus einem Text zu ermöglichen.
• Notification-Service: Der Notification-Service ist in der Lage, an ein spezifisches De-
vice eine Remote-Notification zu senden. Einem bestimmten Nutzer eines Gerätes kann
eine direkte Nachricht geschickt werden. Dies kann für bestimmte Situationen sehr nütz-
lich sein.
• Entity-Service: Der Entity-Service ist die zentrale Anbindung an die Datenbank per
JPA. Er wird von höherliegenden Services benutzt, um Operation auf den Daten der
Datenbank durchzuführen.
• XMPP-Service: Der XMPP-Service ermöglicht der Applikation Nachrichten per XMPP
an registrierte Nutzer zu senden.
106
5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)
• XML-Service: Dies ist ein Dienst zum Generieren und Lesen von XML-Dateien auf
Basis von JAXB.
• Entity-Service: Der Service dient dem Zugriff auf die in der Datenbank gespeicherten
Objekte.
Eine Übersicht über die Integration der Services ist im Klassendiagramm der Abbildung A.14
dargestellt. Die Struktur und Hierarchie ist dort ersichtlich. Die abstrakte Oberklasse AbstractService
enthält alle Basisfunktionalitäten, die ein Service nutzen kann, um seine Aufgaben zu erle-
digen. Hierzu gehören unter anderem Helferfunktionen zum Verarbeiten der Daten und zur
Kapselung des Context-Services.
Der XML-Service wird vom View zum Lesen und Erzeugen von XML aus Java-Klassen ge-
nutzt. Der Mechanismus ist in Abbildung 5.7 dargestellt. Im ersten Schritt sendet der Cli-
ent dem Server eine Anfrage über HTTP84 mit XML-Daten. Diese XML-Daten repräsentie-
ren ein Objekt der Plattform. Das Objekt wird im zweiten Schritt durch den XML-Service
erzeugt. Danach wird es je nach aufgerufener URL an den jeweiligen Service weitergelei-
tet85. Das geschieht im dritten Schritt. Im vierten Schritt antwortet der Service mit einem
Response-Objekt, das im fünften Schritt wieder mit dem XML-Service in XML gewan-
delt und an den Client zurückgesendet wird (sechster Schritt).
Abbildung 5.7.: Verwendung des XML-Services im View (Quelle: Eigene Darstellung)
Die Services, welche eine komplette Funktionalität kapseln, sind Services, die andere Ser-
vices nutzen, um ihre Aufgabe zu erfüllen. Dabei können ganze Abläufe von Aktionen de-
finiert werden. Ein Beispiel ist der Task-Service. Er ist für die CRUD-Funktionalitäten86 ei-
nes Tasks zuständig. Hier soll nun ein Beispielablauf dargestellt werden. Das Beispiel ist die
Übergabe von einem Task an einen anderen User. Die Aufgabe des Task-Service ist es, die
84REST85Zum Beispiel wird es beim Aufruf von /news an den News-Service weitergeleitet.86CReate Update Delete
107
5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)
Daten dementsprechend zu bearbeiten und den neuen Inhaber des Tasks zu informieren. Dieser
Beispielablauf kann wie folgt umgesetzt werden. Zuerst holt sich der Task-Service über den
Context-Service den Entity-Service, um die Daten zu bearbeiten. Wenn dies passiert ist, holt er
sich den e-Mail-Service und schickt eine e-Mail an den User. Alternativ kann er auch über den
XMPP-Service eine Nachricht versenden. Ebenso ist es möglich, über den Push-Service eine
Push-Benachrichtigung an den User abzusetzen.
Neben dem Task-Service existieren noch zwei weitere Services dieser Ebene. Der News-Service
ist zum Erstellen, Löschen und Ändern von News zuständig. Für die Umsetzung seiner Aufga-
ben bedient sich auch dieser Service diversen Services der unteren Ebene. Der Login-Service
hat die Aufgabe, den Anmeldevorgang abzuwickeln.
5.4.3. Model (Autor: Christopher Ezell)
Das Model besteht aus einer Reihe von Datenschnittstellen nach außen. In dieser Arbeit werden
diese Schnittstellen als Konnektoren bezeichnet.
Konnektoren sind in der Anwendung eine Sammlung von Adaptern zu verschiedenen Diens-
ten, die von der Plattform zur Kommunikation genutzt werden. Es gibt sowohl Konnektoren
zur Datenbeschaffung als auch zum Senden von Daten. Durch diese Architektur kann sehr
flexibel auf verschiedene Situationen reagiert werden. Auch eine Verknüpfung verschiedener
Kommunikationskanäle ist denkbar. Diese Architektur wurde gegenüber einem generischen
ESB (Enterprise Service Bus) vorgezogen, da sie sehr viel schlanker in die Anwendung einge-
bunden werden kann. Die Konnektoren sind in den Abbildungen 5.8 und A.11 zu sehen. Sie
sind über den Context-Service mit den Services verbunden. Es gibt Konnektoren zu den
folgenden Diensten:
• der XMPP-Konnektor (XMPP-Protokoll),
• der E-Mail-Konnektor (SMTP-Protokoll),
• der RSS-Konnektor (XML),
• der QR-Code-Konnektor,
• der Apple-Push-Konnektor,
• der Webdav-Konnektor (JCR) und
• der Entity-Mananger (SQL über JPA).
Der Anwendung soll es möglich sein, mit den verschiedenen Diensten zu interagieren. Jeder
Dienst besitzt einen eigenen Konnektor. Es wird kurz auf die einzelnen Konnektoren eingegan-
gen. Bei dem XMPP-Konnektor handelt es sich um eine Verbindung zum XMPP-Server, der
108
5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)
Abbildung 5.8.: Die Verbindung von Services zu den Konnektoren (Quelle: EigeneDarstellung)
auf dem Projekt-Server läuft. Durch diesen Konnektor kann der Server Chat-Nachrichten ver-
senden und den Online-Status der User abfragen. Die Chat-Nachrichten können zum Beispiel
Benachrichtigungen über wichtige Ereignisse oder Status-Updates sein.
Der Mail-Konnektor ist ein Konnektor zu einem E-Mail-Server87. Hierdurch ist es dem Ser-
ver möglich, Berichte und Informationen über E-Mail zu versenden. Der RSS-Konnektor bzw.
das RSS-Modul soll es dem Server ermöglichen, Informationen als RSS-Feeds zu publizie-
ren. So können zum Beispiel die neuesten Projektupdates in Form eines RSS-Feeds publiziert
werden.
Ein weiterer Konnektor ist der QR-Code-Konnektor. Durch ihn kann innerhalb der Plattform
ein QR-Code erzeugt werden. Diese werden innerhalb der Client-Applikation zum schnel-
len Laden von zum Beispiel Tasks genutzt. Mit dem Apple-Push-Konnektor können Push-
Nachrichten auf einzelne Smartphones gesendet werden. Der Webdav-Konnektor verbindet die
Plattform mit einem Webdav-Server und kann auf diesem Dateien ablegen. Als letztes wird der
Entity-Manager (oder auch SQL-Konnektor) erwähnt. Dieser ermöglicht es, Daten mittels JPA
in einer Datenbank zu speichern.
87SMTP-Server
109
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
Die Konzeption des Clients ist in zwei Teile gegliedert. Der erste Teil besteht darin, die aus den
User Stories gewonnenen Informationen in strukturierte einzelne Funktionalitäten zu gliedern
und diese in ein Gesamtkonzept einzubinden. Im zweiten Teil wird die grundlegende Benut-
zeroberfläche für die jeweiligen Funktionalitäten mittels Mockups88 definiert. Die Mockups
wurden mit der Software Balsamiq Mockups erstellt. Besonders die Benutzeroberfläche ist ein
sehr wichtiges Thema. Wenn der Nutzer eine Funktionalität durch eine schlecht designte Ober-
fläche nicht findet, ist sie für ihn praktisch nicht existent. Es muss innerhalb der Applikation
also eine klare Art und Weise geben, wie der Nutzer diese verwendet.
Der Name der iPhone-Applikation ist InstantScrum und taucht an einigen Stellen im weiteren
Text auf. Es wurde auch ein Logo und ein Hintergrundbild mit diesem Namen gestaltet.
Grundsätzlich gibt es bei einer iPhone-App verschiedene Ansätze, die Informationen zu prä-
sentieren. Laut den Apple Human Interface Guidelines89 [ios12a] ist es eine der besten Mög-
lichkeiten, eine Applikation mit mehreren unterschiedlichen Funktionen mittels einer TabView
als Hauptview zu unterteilen. So wird diese App in oberster Ebene mittels einer Tabview in ver-
schiedene Bereiche getrennt. Diese kann man am unteren Bildschirmrand auswählen und so in
die verschiedenen Funktionalitäten wechseln. Es werden anhand des Kapitels 4 die folgenden
Bereiche als eigenständige Funktionen ermittelt:
• die Tasks (User Story 8, 9, 10, 11 und 12),
• die News (User Story 3 und 4),
• der Chat (User Story 15 und 16),
• die Liste aller registrierten User (User Story 13),
• die Liste der Links (User Story 22),
• die Maps (User Story 6 und 7),
• die Liste der Notizen (User Story 20 und 21),
• der QR-Code-Scanner (User Story 17),
• der Buildstatus (User Story 5) und
• die Informationen über angemeldete User (User Story 14).
Die einzelnen Funktionen werden im Verlauf dieses Kapitels noch näher erläutert und beschrie-
ben.
88Dies wird auch Wireframe genannt.89Diese sollten vor dem Entwickeln einer iPhone-App von jedem Entwickler gelesen werden.
110
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
5.5.1. Architektur der iPhone-App (Autor: Christopher Ezell)
Zunächst wird die Architektur der iPhone-App beschrieben. Die grundlegende Architektur ist
in Abbildung 5.9 dargestellt. Es handelt sich hierbei um eine Model-View-Controller-Architektur.
Im unteren Teil der Abbildung ist das Model dargestellt. Es beinhaltet alle Datenobjekte. Tasks,
Messages und Users werden in der Abbildung beispielhaft dargestellt. Es wurde jedoch kein
permanenter Speicher in die Applikation eingebaut. Da sich die Autoren dafür entschieden ha-
ben, die Daten bei jedem Start neu zu laden, wurde von diesem Feature abgesehen. Die Daten
werden vom Server über einen REST-Konnektor und einen XMPP-Konnektor geladen und
über verschiedene Parser90 in native Objective-C-Objekte überführt. Die Entscheidung, ob die
Daten über REST oder XMPP übertragen werden, hängt von dem jeweiligen Dienst ab.
Über dem Model befinden sich der Controller. Dieser bildet die Schnittstelle zwischen dem
Model und der View. Der Controller erhält dabei die Daten vom View und leitet diese an das
Model weiter91. Erhält er eine Antwort, leitet er diese an das View weiter. Das View greift über
den Controller auf die Daten zu und stellt diese dar.
Abbildung 5.9.: Übersicht der iOS-Applikations Architektur (Quelle: Eigene Darstellung)
In Abbildung A.12 ist die Verteilung der Dienste aus der Sicht des iPhones dargestellt. Es zeigt,
dass das iPhone auf Diigo, Simple Notes und den XMPP-Server zugreift. Da sowohl Diigo als
auch Simple Notes eine REST-API besitzen, müssen nur die in der Abbildung 5.9 gezeigten
REST- und XMPP-Konnektoren implementiert werden.
90Beispiele für verwendete Parser sind der XML- und der JSON-Parser.91Dies passiert bei Benutzereingaben.
111
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
5.5.2. Datensynchronisation (Autor: Rene Kassel)
Ein Punkt hat besonders großen Einfluss auf die Architektur einer Anwendung: die Art und
Weise wie das Management der Daten konzipiert wird. Die iPhone-Applikation muss verschie-
dene Kommunikationsarten unterstützen. Es gibt auf der einen Seite die asynchrone Kommu-
nikation mit dem Server. Hier werden Daten einmal vom Server geholt und erst wieder neu
geladen, wenn der Benutzer ein erneutes Laden initiiert. Auf der anderen Seite muss synchron
mit dem XMPP-Server Kontakt gehalten werden, um immer die neuesten Nachrichten anzeigen
zu können.
Es muss eine Entscheidung gefällt werden, wie diese Daten im iPhone vorgehalten und gespei-
chert werden. Die Entscheidung war keine persistenten lokalen Daten vorzuhalten, sondern
diese nur im Arbeitsspeicher zu halten. Das bedeutet, dass die Daten bei jedem Start der Ap-
plikation neu geladen werden. Wenn der Benutzer beim Start keinen Internetzugriff hat, hat er
keine Daten zur Verfügung. Die Daten werden nur neu geladen, wenn dies der Nutzer explizit
wünscht.
5.5.3. Die einzelnen Funktionalitäten im Überblick
Die Abbildung 5.10 zeigt eine Mind-Map zu der geplanten Funktionalität. Es enthält einen
Strang für jede Funktionalität der Applikation. Sie teilen sich in acht verschiedene Tabs und
einen Login-Screen auf. Nachfolgend werden die jeweiligen Tabs erläutert und deren Funktio-
nen erklärt.
5.5.3.1. Der Chat (Autor: Christopher Ezell)
Der Mockup der Chat-View ist in Abbildung 5.11 gezeigt. In diesem Tab hat der User die
Möglichkeit mit anderen Usern aus dem Projekt direkten Kontakt aufzunehmen und interaktiv
Informationen in Form von Messages auszutauschen. Der Mockup zeigt eine Liste der User,
die jeweils in die Kategorien Online und Offline getrennt sind. Mit Usern, die im Status On-
line sind, kann eine direkte Unterhaltung stattfinden, indem auf den jeweiligen Zelleneintrag
getappt wird. Es öffnet sich ein Fenster mit einer Texteingabeleiste am unteren Ende des Bild-
schirms. Wenn auf diese getappt wird, erscheint die Bildschirmtastatur. Es ist möglich durch
das Drücken des Senden-Buttons, die in der Texteingabeleiste geschriebene Nachricht zu ver-
senden. Zu sehen ist das in dem Mockup der Abbildung 5.12. Dort ist ersichtlich, von wem die
Nachricht stammt und welchen Inhalt die Nachricht trägt. Die Liste der Nachrichten ist scroll-
bar bis zum Beginn der aktuellen Session. Ältere Nachrichten sind nicht abrufbar.
Wenn der Nutzer mit Usern chatten will, die im Status Offline sind, kann er denen ebenfalls
Nachrichten senden. Diese Nachricht wird dann dem anderen User als Push-Benachrichtigung
zugestellt. Die Vorteile dieses Features sind im Kapitel 2.8.3 dargestellt.
112
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 5.10.: Mind-Map der InstantScrum iPhone-Applikation (Quelle: EigeneDarstellung)
Durch dieses Feature wird die direkte Erreichbarkeit von Projektmitgliedern immens erhöht.
Es kann ortsunabhängig und interaktiv miteinander kommuniziert werden. Die soziale Bindung
zwischen den Teammitgliedern wird durch dieses Feature ebenfalls verbessert.
5.5.3.2. Tasks (Autor: Rene Kassel)
Bei den Tasks handelt es sich um eine sehr simple Verwaltung von Aufgaben. Es soll dem Nut-
zer eine schnelle, aber effiziente, Möglichkeit bieten, sich selber Tasks als Erinnerung zu erstel-
len oder einem anderen User einen bestimmten Task zuzuweisen. Die Idee dabei ist, die Mög-
lichkeit des iPhone-Push-Services zu nutzen und einem Benutzer der App eine Push-Nachricht
zu schicken, wenn ihm ein Task zugewiesen wird.
Der Mockup des TaskView ist in Abbildung 5.13 zu sehen. Er ist durch ein TableView realisiert.
Jede Zelle enthält Informationen über den Namen und den aktuellen Workload des Tasks. Der
Name ist durch ein einfaches Textfeld dargestellt.
Wenn der Nutzer auf einen Eintrag in der Liste tappt, wird der gewählte Task in einer Detailan-
sicht dargestellt. Diese wird in Abbildung 5.14 gezeigt. Die Ansicht beinhaltet Informationen
113
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 5.11.: Mockup der Chatliste (Quelle: Eigene Darstellung)
zum Tasknamen, zur Arbeitszeit, zum Verantwortlichen Mitarbeiter und zum Status des Tasks.
Weiterhin können innerhalb der Detailansicht verschiedene Funktionen ausgelöst werden, wie
Planningpoker, Statusänderungen oder das Erfassen der Arbeitszeit.
Mit Hilfe dieses Features wird die Transparenz bezüglich der Arbeit innerhalb des Teams ver-
bessert.
5.5.3.3. Die News (Autor: Christopher Ezell)
Bei den News handelt es sich um die in Kapitel 2.8.7 analysierte Microblogging-Technik. Die-
se Technik dient dazu einem User der Applikation das Absenden einer kurzen Nachricht über
seinen aktuellen Status zu ermöglichen. Es ist eine Art globaler Newsstream innerhalb des Pro-
jektes, welcher nahezu alle Informationen enthält, die im Projekt anfallen. Wie schon in Kapitel
2.8.7 betrachtet, ist es in einem Projekt sehr wichtig, aktuelle Information schnell aufnehmen
zu können, um auf diese gegebenenfalls schnell reagieren zu können.
Der Mockup zu dieser Funktion ist in Abbildung 5.15 dargestellt. Er besteht aus einer Liste
von chronologisch sortierten Nachrichten. Jede Nachricht enthält dabei die Art der Nachricht
im Titel92 und den Inhalt der Nachricht im Hauptteil. Der Hauptteil ist im mittleren Bereich
der Zelle angesiedelt. In der unteren linken Ecke ist der Name des Users, der die Nachricht
verfasst hat. In der unteren rechten Ecke befindet sich ein Zeitstempel, wann die Nachricht
verfasst wurde.
92Die Art ist beispielsweise eine Veränderung im Wiki oder eine Nachricht, die ein anderer User geschrieben hat.
114
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 5.12.: Mockup eines Chats mit einem anderem User (Quelle: Eigene Darstellung)
Durch den kontinuierlichen Fluss an Neuigkeiten wird die Teilhabe einzelner Mitglieder am
Projekt stark erhöht. Dieses Feature ist von Vorteil, wenn einzelne Mitglieder an anderen Stand-
orten arbeiten und ohne diesen Newsstream nur sehr wenig Informationen bekommen würden.
Das Defizit des verteilten Teams wird dadurch abgeschwächt.
5.5.3.4. Liste der Shared Links (Autor: Rene Kassel)
In dem Tab der Shared Links sind alle im Projekt geteilten Links in einer Liste zu sehen. In der
ersten Ansicht sind zunächst die vergebenen Tags der Links dargestellt. Dies hat den Vorteil,
dass der Nutzer eine Übersicht über alle getagten Themen erhält und so entscheiden kann,
welche Links relevant sind. Der Nutzer kann nun auf eine Zelle mit einem Tag tappen und
sieht die einzelnen Links chronologisch sortiert. Damit sieht er immer die aktuellsten Links
zuerst. Wenn der Nutzer auf einen Link tappt, wodurch sich ein eingebetteter Browser öffnet,
der die Webseite hinter dem Link darstellt.
Dieses Feature kann von den einzelnen Teammitgliedern als Bibliothek verwendet werden.
Mit Hilfe von Tags ist eine sehr gute Strukturierung der Informationen möglich. Durch das
Feature kann sich ein Mitglied innerhalb kürzester Zeit und ortsunabhängig93 Wissen aneignen,
welches von anderen Teammitgliedern als wichtig erachtet wurde. Hierdurch kann sehr viel
Zeit bei der Einarbeitung gespart werden.
93Zum Beispiel während einer Bahnfahrt.
115
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 5.13.: Mockup der Taskliste (Quelle: Eigene Darstellung)
5.5.3.5. Maps (Autor: Christopher Ezell)
In dem Tab Maps sollen die User Stories 6 und 7 umgesetzt werden. Der Tab besteht, wie in
dem Mockup von Abbildung 5.17 dargestellt, aus der Standardansicht einer Karte. Diese zeigt
die aktuelle Position des Benutzers mit der blauen Markierung94. Mit der Markierung in Grün
werden ihm seine Kollegen angezeigt95. Der Benutzer kann nun mittels eines Buttons an der
oberen Seite seine eigene Position aktualisieren und optional eine Nachricht eingeben. Diese
wird automatisch im News-Stream erzeugt96.
Eine Erweiterung97 könnte eine Liste von im Projekt definierten Standorten sein. Zusätzlich zur
eigenen Position und der Positionen seiner Kollegen würden somit noch vordefinierte Standorte
zu sehen sein. Derartige Standorte können zum Beispiel das Büro oder das Lieblingscafe sein.
Ein Nutzer würde dann bei einem Tap auf den Button zuerst die Liste von Standorten sehen, in
die er einchecken kann. Diese Standorte kann er zusätzlich erstellen, wenn er seine Position an
einem noch unbekannten Ort aktualisiert.
Dieses Feature kann innerhalb eines Projektes die Transparenz für den Aufenthaltsort, an dem
sich die Teammitglieder befinden, erhöhen. Durch die Nutzung der Funktionalität kann eine
Erhöhung der sozialen Interaktionen im Projekt erreicht werden. Damit die Motivation zur
94Die Position wird vom GPS-Sensor des Smartphones ermittelt.95Besser gesagt: Es werden ihm die Positionen seiner Kollegen gezeigt, die sie zuletzt aktualisiert haben.96siehe Kapitel 5.5.3.397Diese Erweiterung ist kein Bestandteil des Prototypen.
116
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 5.14.: Mockup der Detailansicht eines Tasks (Quelle: Eigene Darstellung)
Nutzung dieser Technik gesteigert wird, kann ein Punktesystem integriert werden. Durch den
Spielcharakter kann die Häufigkeit der Informationsteilung ortsbezogener Daten stark erhöht
werden. Die Erhöhung der Transparenz und die Förderung der sozialen Interaktion stärken das
Vertrauen im Team und verbessern das Teamklima.
5.5.3.6. Verteiltes Planningpoker (Autor: Christopher Ezell)
Das verteilte Planningpoker ist nicht im Prototypen enthalten. Das Feature ist in User Story 23
erläutert. Es behandelt eine Funktionalität, die Teammitgliedern an verschiedenen Standorten
dennoch die Möglichkeit bietet, Planningpoker mit Echtzeit-Feedback durchzuführen98.
Der Prozess läuft wie folgt ab: Zuerst muss eine Audio-Verbindung hergestellt werden, um
mit den Projektpartnern direkt reden zu können. Danach wird die Applikation geöffnet und
die eigentliche Funktionalität kommt zum Einsatz. Im Tab Planningpoker gibt es oben rechts
einen Plus-Button. Wenn der Nutzer diesen Button betätigt, kann er aus der Liste aller noch
offenen Tasks einen bestimmten auswählen, für den er das Planningpoker durchführen möchte.
Zu diesem Zeitpunkt bekommen alle anderen Teammitglieder eine Push-Benachrichtigung mit
der Frage, ob sie am Planningpoker teilnhemen wollen. Jeder teilnehmende Nutzer bekommt
eine Ansicht mit Karten für verschiedene Komplexitätsgrade für den Task. Nun kann jeder
Nutzer eine Karte auswählen. Dabei wird solange gewartet, bis alle Teilnehmer eine Karte
ausgewählt haben. Nun ist die erste Runde vorbei und der Server wertet aus, welcher Nutzer
98Nähere Informationen gibt es im Kapitel 3.1.3.
117
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 5.15.: Mockup der Newsliste (Quelle: Eigene Darstellung)
welche Karte gewählt hat. Haben nicht alle Teilnehmer den gleichen Wert gewählt, wird den
Nutzern eine Liste der Teilnehmer mit den jeweils gewählten Werten dargestellt. Im Anschluss
darauf diskutieren die Teilnehmer über die Wahl. Danach kann über einen Button eine neue
Runde begonnen werden. Dieses Vorgehen läuft so lange bis alle die gleiche Karte gewählt
haben.
Der große Vorteil dieser Lösung ist die Ortsunabhängigkeit der Teilnehmer. Es kann praktisch
von jedem Ort aus an dieser Schätzrunde teilgenommen werden. Die Erfahrung der Autoren
hat gezeigt, dass es in einem verteilten Team sehr schwierig diese agilen Praktiken, wie das
Planningpoker, durchzuführen. Eine klassische Durchführung wäre bei einem Team, was zum
Zeitpunkt der Schätzung nicht an einem Standort ist, praktisch unmöglich. Durch das Plan-
ningpoker ist es jedoch mit Hilfe eines direkten Feedbacks möglich, solche Schätzungen auch
verteilt durchzuführen.
Dieses Feature ermöglicht die Technik des Planningpokers zur Aufwandschätzung auch zwi-
schen distanzierten Teammitgliedern. Dabei können die Mitglieder direkt und interaktiv die
Aufwände schätzen. Das verbessert die Qualität des Schätzverfahrens bei verteilten Teams
sowie der Planungsmeetings. Die Dauer der Planung kann dadurch stark reduziert werden.
Zusätzlich können Bilder der Projektmitglieder neben dem geschätzten Wert die emotionale
Verbindung herstellen und erhöhen.
118
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 5.16.: Mockup der Mapfunktionalität (Quelle: Eigene Darstellung)
5.5.3.7. Liste der Notizen (Autor: Christopher Ezell)
Die Liste der Notizen ist eine einfache Liste. In dieser werden die einzelnen Notizen angezeigt.
Die Konzeption wird anhand der User Stories 20 und 21 durchgeführt. Die Liste enthält für
jeden Eintrag die Überschrift der Notiz und die ersten Zeilen des Inhalts. Durch einen Tap auf
eine bestimmte Notiz in der Liste gelangt der Nutzer in die Komplettansicht der Notiz. Wenn
der Nutzer nun eine Änderung innerhalb der Notiz vornimmt, erscheint ein Speichern-Button
zum Abspeichern des neuen Inhalts.
Durch dieses Feature wird die Verteilung bestimmter Informationen, wie Mitschriften bei Mee-
tings, verbessert. Diese können mobil eingesehen und kommentiert werden.
5.5.3.8. QR-Code-Scanner (Autor: Rene Kassel)
Die Funktionalität des QR-Code-Scanners soll dem Benutzer den Umgang mit Tasks erleich-
tern. Tasks werden in einem QR-Code hinterlegt. Wenn diese nun an einem Taskboard aufge-
hängt werden, kann ein Task einfach per QR-Code gescannt werden. Dadurch wird er sofort
auf dem Smartphone geöffnet. In der sich öffnenden Ansicht kann nun der Status des Tasks ver-
ändert oder einem anderen Teammitglied zugewiesen werden. Die Grundlagen für QR-Codes
wurden im Kapitel 3.2.9 erläutert.
Die Idee hinter diesem Feature ist die starke Kopplung von Virtuellem und Realem. An dem
Taskboard sind eine Vielzahl von Tasks angebracht in Form von QR-Codes. Gibt es nun ein ver-
119
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 5.17.: Mockup der PlanningpokerView (Quelle: Eigene Darstellung)
teiltes Planungsmeeting mit Telefonkonferenz, kann ein Projektmitarbeiter an das Taskboard
gehen und einen bestimmten Task anscannen. Danach kann er ihn sofort einen bestimmten Mit-
arbeiter zuweisen, der eine Push-Benachrichtigung auf sein Smartphone erhält. Dadurch wird
die Information sehr schnell ausgetauscht. Damit ist der Effekt der direkten Interaktion sehr
viel höher, als wenn dies nur formell auf einer Webseite mit einem normalen Taskverwaltungs-
tool passiert.
5.5.3.9. Buildstatus (Autor: Rene Kassel)
In einem agilen Projekt ist es sehr wichtig, den aktuellen Build im Auge zu behalten und bei
Unregelmäßigkeiten schnell zu reagieren. Es soll mit dieser Funktionalität ermöglicht werden,
mit einem Klick einen Überblick über den Status aller Builds zu erhalten. Diese Ansicht ist
in Abbildung 5.18 dargestellt. Dabei werden die einzelnen Projekte gezeigt. Anhand eines
farbigen Indikators kann der Nutzer auf einem Blick sehen, welches Projekt kritisch ist.
Das Feature ermöglicht das schnelle Bemerken eines kritischen Fehlers im Quellcode, um dar-
auf reagieren zu können. Damit wird einer Entstehung schwerwiegenderer Fehler entgegenge-
wirkt.
120
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 5.18.: Mockup des Buildstatus (Quelle: Eigene Darstellung)
5.5.3.10. Das Punktesystem (Autor: Rene Kassel)
Dieses Feature wurde nur zu Teilen in der Plattform umgesetzt. Es greift das Thema der Gami-
fication aus Kapitel 2.7 auf. Hier wurde erwähnt, dass es sehr motivationsfördernd sein kann,
wenn der Nutzer durch Aktivitäten im Team Punkte bekommt und zusätzlich eine Ansicht hat,
wo diese Punkte eingesehen werden können. Aus Erfahrung ist es so, dass ein Teammitglied
an einem Standort A eher mit einem Mitglied des selben Standortes interagiert als mit denen,
welche an anderen Standorten sind. Dadurch kann sich die soziale Bindung zwischen den ent-
fernten Partnern mit der Zeit verlieren. Es soll also ein in das System integriertes Punktesystem
geben, was dem Nutzer ein positives Feedback gibt und Mitglieder dafür belohnt, wenn sie
Informationen mit anderen teilen und mit allen Mitgliedern interagieren. Das Punktesystem ist
ein übergreifendes Konzept in der gesamten Plattform und kann in alle Bereiche eingebracht
werden. Im folgenden sind einige Ideen aufgelistet:
• das Erstellen einer Wiki-Seite,
• das Beenden eines Tasks,
• das Posten einer News,
• das Einchecken eines Tests, der die Testabdeckung erhöht,
• das Reparieren eines Builds und
121
5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)
• das Einchecken eines Klassen- oder Methoden-Kommentars.
Das Team kann entscheiden, welche Aktion wie viele Punkte erhält. Zusätzlich kann entschie-
den werden, welche Belohnung bei welcher Punktzahl ansteht. So ist ein stetiger Anreiz ge-
schaffen, etwas Wertvolles für das Team zu tun.
5.5.3.11. Liste aller registrierten User (Autor: Rene Kassel)
Die Liste aller registrierten User soll einen Überblick gewähren, wer gerade im Team aktiv
ist. In dieser Ansicht können verschiedene Dinge zu jedem User im Projekt auf einen Blick
eingesehen werden. Zum Einen ist der Name und zum Anderen der Online-Status zu sehen. Der
Mockup ist in Abbildung 5.19 zu sehen. Dies ist in Form eines farbigen Kreises99 dargestellt.
In dem mittleren Teil ist die letzte Aktivität zu sehen, die der User getätigt hat. Darunter ist
eine Aufschlüsselung seiner aktuellen Punkte im Punktesystem sichtbar. Im unteren Teil der
Zelle ist noch die aktuelle Position ersichtlich.
Abbildung 5.19.: Mockup der Userliste (Quelle: Eigene Darstellung)
Mit Hilfe dieses Features kann sich der Nutzer einen schnellen Überblick über die wichtigsten
User-bezogenen Daten verschaffen. Durch die Informationen, die an dieser Stelle ausgetauscht
werden, wird im gewissen Maße ein Zusammengehörigkeitsgefühl zwischen den Teammit-
gliedern erzeugt. Zudem wird durch die Bekanntgabe der Punkte der Spieltrieb erhöht, was
wiederum die Motivation steigert.
99grün: online, gelb: nicht verfügbar und rot: offline
122
5.6. Konzeption Build und Teststrategien (Autor: Christopher Ezell)
5.6. Konzeption Build und Teststrategien (Autor: Christopher Ezell)
Als letzten Teil der Konzeption werden der Build und die Teststrategien spezifiziert. Hier
wird definiert, welche Tests innerhalb der Entwicklung erstellt werden und wie diese gene-
rell durchgeführt werden. Es werden in diesem Kapitel die Unit-Tests, Integrations-Test und
Explorativ-Tests betrachtet100.
Es ist in einem komplexen Projekt sehr wichtig ein Konzept zu besitzen, wie der Build der An-
wendung ablaufen soll und welche Komponenten darin wie durchlaufen werden sollen. Primär
geht es hier um den Build der Serveranwendung, da die Clientanwendung nur aus einem Teil
besteht. Im Build der Serveranwendung sind verschiedene Komponenten definiert. Die einzel-
nen Komponenten müssen bei der Implementierung dieses Builds mit Maven, falls nötig, noch
weiter aufgesplittet werden. Die Komponenten sind die folgenden:
• die Basisklassen: Hier sind alle Klassen, die sowohl in der Datenbank gespeichert, als
auch über REST übertragen werden.
• die Konnektoren: Das sind alle Konnektorklassen zu den externen Systemen inklusive
ihrer Datenbank.
• die Services: Diese beinhalten alle verfügbaren Services.
• das Web: Diese Komponente besitzt alle REST-Komponenten inklusive dem Web-Container
und den Basisklassen.
Nun müssen für jeden Schritt im Build-Prozess Teststrategien entworfen werden. Es werden
Unit-, Integrations- und Explorativ-Tests betrachtet.
Die Unit-Tests stellen die Basis für die Verifikation der Funktionalität einer Software dar und
werden daher sowohl auf dem Client als auch auf der Serverseite erstellt. Auf der Serverseite
werden für alle Module Unit-Tests definiert, die beim Build des jeweiligen Moduls durchlaufen
werden. Auf Clientseite werden nur Explorativ-Tests der Benutzoberfläche vorgenommen.
Die Integrations-Tests gehören zu einem gutem Test-Setup für agile Projekte dazu. Hier wer-
den alle Funktionalitäten Modul-übergreifend getestet. Dies sollte so produktionsnah wie mög-
lich getestet werden. Das bedeutet im besten Fall, dass über die API gestestet wird, welche
der Client benutzt. Dadurch ist gewährleistet, dass alle Komponenten im Zusammenspiel bis
hin zur Datenbank getestet werden. Diese sollten bei jedem Commit auf einer CI-Umgebung
automatisiert ablaufen. Somit sollte bei diesen Integrationstest die komplette Webapplikation
innerhalb einer Server-Umgebung laufen, die Zugriff auf eine echte Datenbank hat. Für diesen
Testaufbau wird also das Folgende benötigt:
• das Vorhandensein einer Datenbank, zu der eine Verbindung aufgebaut werden kann,
• das Vorhandensein eines Webservers, der als Container für die Applikation dienen kann,
100Grundlagen hierzu werden im Kapitel 3.4 beschrieben.
123
5.7. Zusammenfassung (Autor: Rene Kassel)
• die Webapplikation muss zur Testzeit auf dem Server deployed sein,
• es muss ein Test-Client existieren, der mit diesem Server eine Verbindung aufbauen kann
und
• das Vorhandensein von Testfällen, die den Anwendungsfällen entsprechen.
Dieses Setup soll in der Implementierung umgesetzt und über das Szenario getestet werden. Es
soll bei jedem Commit eines Entwicklers durchlaufen werden und Feedback über die Tester-
gebnisse per E-Mail verschicken.
5.7. Zusammenfassung (Autor: Rene Kassel)
In diesem Kapitel sind die Funktionalitäten der Plattform dargestellt worden und auf die ver-
schiedene Server verteilt worden. Es wurden die Schnittstellen der einzelnen Dienste beschrie-
ben bzw. spezifiziert. Weiterhin wurde definiert, welche Dienste extern bzw. intern genutzt
werden und welche Teile selber programmiert werden sollten. Aufgrund dieser Konzeption
werden im nachfolgenden Kapitel ausgewählte Teile der Implementierung betrachtet.
124
6. Implementierung (Autoren: Christopher Ezell und Rene Kassel)
6. Implementierung (Autoren: Christopher Ezell und Rene Kassel)
Dieses Kapitel behandelt die praktische Umsetzung der Projektplattform. Sie entspricht einer
Untermenge der im Kapitel 5 definierten Funktionen. Das Kapitel ist in drei Teile geteilt. Der
erste Teil handelt von der Implementierung der Server-Applikation in Kapitel 6.1. Der zweite
Teil, Kapitel 6.2, behandelt die Implementierung des Clients. In diesen beiden Kapiteln wird
speziell auf die Implementierung der einzelnen Techniken eingegangen und anhand von Bei-
spielcode die Verwendung im Projekt dargestellt. Auf die Implementierung jedes einzelnen
Features der Applikationen wird nicht explizit eingegangen. Im letzten Teil wird in Kapitel 6.3
die Umsetzung des Builds für den Server dargestellt sowie der Aufbau der CI-Umgebung für
das Projekt erläutert.
6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
Als erstes wird die Implementierung der jeweiligen Techniken auf Seiten des Servers vorge-
stellt. Zu Beginn wird auf die einzelnen Konnektoren zu den Diensten eingegangen, um danach
die Implementierung der Services zu beschreiben. Sie stellen den Controller dar. Am Ende wird
auf die View-Komponente eingegangen.
6.1.1. Datenbankanbindung (Autor: Rene Kassel)
Wie in Kapitel 3.2.7 beschrieben, ist JPA eine sehr elegante und einfache Methode eine Java-
Anwendung an eine Datenbank anzubinden. Nun soll es darum gehen, die praktische Umset-
zung zu erläutern. Die Autoren haben sich, wie oben erwähnt, für EclipseLink ([ecl12]) als Im-
plementierung von JPA entschieden. Die Konfiguration von JPA ist deklarativ über eine XML-
Datei. Hier werden alle wichtigen Verbindungsparameter gesetzt und alle Klassen eingetragen,
welche über diese Schnittstelle in eine Datenbank übertragbar sein müssen. Ein Ausschnitt aus
dieser Konfigurationsdatei ist in Listing 6.1 dargestellt. Hier ist eine JPA-Konfiguration mit
der ID de.crossbeanmedia.scrumapp.jpamodel zu sehen. Diese definiert die Per-
sistenz für die Klassen ScrumTask und ScrumUser. Die Klassen müssen die Annotation
@Entity aus javax.persistence.Entity tragen.
125
6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
Listing 6.1: Auschnitt aus der Eclipse-Link Configuration1 <persistence>2 <persistence-unit name="de.crossbeanmedia.scrumapp.jpamodel">3 <class>de.crossbeanmedia.scrumapp.basemodel.projectdata.
ScrumTask</class>4 <class>de.crossbeanmedia.scrumapp.basemodel.userdata.
ScrumUser</class>5 <properties>6 <property name="javax.persistence.jdbc.driver" value="" />7 <property name="javax.persistence.jdbc.url" value="" />8 <property name="javax.persistence.jdbc.user" value="" />9 <property name="javax.persistence.jdbc.password" value="" />
10 </properties>11 </persistence-unit>12 </persistence>
Aus dieser Konfiguration kann eine Instanz der Klasse EntityManager erzeugt werden.
Listing 6.2 zeigt, wie diese Konfiguration geladen wird. Zudem zeigt es, wie ein neues Ob-
jekt der Klasse ScrumUser in die Datenbank gespeichert wird und ein Objekt der Klasse
ScrumUserwieder aus der Datenbank geladen wird. Durch den Aufruf des EntityManager
wird beim ersten mal das dazugehörige Datenbankschema erzeugt.
Listing 6.2: Beispiel eines Datenbankzugriffs mit JPA1 EntityManagerFactory emf;2 EntityTransaction entityTransaction;3 EntityManager em = Persistence4 .createEntityManagerFactory(5 "de.crossbeanmedia.scrumapp.jpamodel");6 em = emf.createEntityManager();7 entityTransaction = em.getTransaction();8
9 ScrumUser user = new ScrumUser();10 em.persist(user);11 ScrumUser user2 = em.find(ScrumUser.class, id);
Die Integration dieser Funktionalität in den Kontext der Anwendung ist in Abbildung 6.1 dar-
gestellt. Hier wird deutlich, dass die Klasse ScrumEntityManager die Funktionalität von
EclipseLink kapselt. Der ScrumEntityManager hält dabei alle Referenzen auf die benötig-
ten Klassen. Dieser wird von der Klasse EntityService benutzt. Der EntityService
gehört zu den im Kapitel 5.4.2 definierten Services innerhalb der Web-Applikation. Der
EntityService kann wiederum von jedem anderen Service über den ContextService
aufgerufen werden. Dieser bietet Methoden, bei denen direkt eine Klasse der Plattform gela-
den werden kann. Ein Beispiel wäre getAllScrumUsers(). Dies macht den Zugriff auf
die Daten sehr viel einfacher.
126
6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
Abbildung 6.1.: Klassendiagramm EntityManager (Quelle: Eigene Darstellung)
6.1.2. Push-Konnektor (Autor: Christopher Ezell)
Nun soll auf die Umsetzung des Konnektors für den Apple Push Service eingegangen werden.
Die Definition des Interfaces wurde in Kapitel 5.3.4 vorgenommen. Auf der Serverseite wur-
de für die Umsetzung des Push-Konnektors die Bibliothek JavaPNS (siehe [P.12] verwendet.
Sie bietet eine sehr schöne API zum Erstellen von Push-Benachrichtigungen. Bevor eine Push-
Benachrichtigung auf einem iPhone angezeigt werden kann, müssen einige Vorbedingungen
auf dem Server erfüllt sein. Es wird ein generiertes Key-File mit verschiedenen Zertifikaten
benötigt. Dies wird für die Authentifizierung gegenüber dem Apple-Server verwendet. Die Ge-
nerierung ist hier nicht weiter beschrieben. Das Key-File muss für den weiteren Verlauf zur
Verfügung stehen. Als zweites wird das jeweilige Device-Token von jedem einzelnen iPho-
ne benötigt. Wie diese Device-Token in Erfahrung gebracht werden können, wird im Kapitel
6.2.10 dargestellt. Die Klasse PushConnector hat eine Methode pushWithSound. Diese
Methode kann von allen Services der Plattform über die Push-Konnektor-Klasse aufgerufen
werden und so einem spezifischen iPhone eine Push-Nachricht senden.
Listing 6.3 zeigt den Aufbau der Methode pushWithSound. Hier wird zuerst der Keysto-
re geladen und danach in eine Klasse der Bibliothek JavaPNS verpackt. Mit der Methode
Push.combined ist es nun möglich, einem Device mit dem übergebenen Device-Token
einen Push zu senden. Hierzu wird das Device-Token in eine Klasse BasicDevice ver-
packt.
127
6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
Abbildung 6.2.: Tokengenerierung (Quelle: [App12b])
Listing 6.3: Push to Device1 void pushWithSound(String message, String sound, String token,
int badge, Sting2 password) { try {3 InputStream keystore = this.getClass().getResourceAsStream("
/java.p12");4
5 //add Device to a List List<Device> list = new ArrayList<Device>();
6 BasicDevice device = new BasicDevice(token);7 list.add(device);8
9 Push.combined(message, badge, sound, keystore, password,false, list);
10
11 }12 catch (KeystoreException e) { log.info(e.getMessage()); }
catch (Exception e)13 {14 log.info(e.getMessage());15 }16 }
6.1.3. QR-Code-Konnektor (Autor: Rene Kassel)
Der QR-Code-Konnektor ist ein Wrapper, um die Bibliothek von kenglxn101 anzubinden. Er
wird wie in Listing 6.4 verwendet. Die Methode getQrCodeStream der Klasse
101siehe http://kenglxn.github.com/QRGen/
128
6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
QRConnektor erzeugt einen QR-Code mit der Größe 300 mal 300 Pixel und dem übergebe-
nen Text und gibt einen ByteArrayOutputStream zurück. Dieser kann von der Plattform
dann weiter verarbeitet werden.
Listing 6.4: QR-Code generieren1
2 public ByteArrayOutputStream getQrCodeStream(String message) {3 return QRCode4 .from(new String(message.getBytes(), Charset.forName("
UTF-8")))5 .to(ImageType.PNG).withSize(300, 300).stream();6
7 }
6.1.4. Mail-Konnektor (Autor: Rene Kassel)
Für die Implementierung des Mail-Konnektors wurde die Standard-API der javax.mail
Bibliothek verwendet. Das Listing 6.5 zeigt die Methode zum Senden der E-Mail. Dafür ist die
Methode sendMessage des Konnektors zuständig. Um die Mail zu verschicken wird eine
MimeMessage erzeugt und mit dem übergebenen Inhalt gefüllt. Zusätzlich werden Propertys
mit dem benötigten E-Mail-Einstellungen erzeugt. Abschließend verbindet sich der Konnektor
auf dem Mailserver und überträgt die E-Mail.
Listing 6.5: Senden einer E-Mail1 public void sendMessage(String to, String messageString,
String subject)2 throws AddressException, MessagingException {3 Properties props = new Properties();4 props.put("mail.transport.protocol", "smtp");5 props.put("mail.smtp.host", "smtp.strato.de");6 props.put("mail.smtp.auth", "true");7
8 Session mailSession = Session.getDefaultInstance(props);9 Transport transport = mailSession.getTransport("smtp");
10
11 MimeMessage message = new MimeMessage(mailSession);12 message.setSubject(subject);13 message.setContent(messageString, "text/plain");14 message.setFrom(new InternetAddress(""));15 message.addRecipient(Message.RecipientType.TO, new
InternetAddress(to));16
17 transport.connect("", "");18 transport.sendMessage(message,19 message.getRecipients(Message.RecipientType.TO));20 transport.close();21 }22
23 }
129
6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
6.1.5. XMPP-Konnektor (Autor: Christopher Ezell)
Die Java-Webapp nutzt den XMPP-Konnektor zum Senden und Empfangen von
XMPP-Nachrichten. Hierzu wird die API von Ignite Realtime verwendet102. Listing 6.6 zeigt
die Verwendung dieser API im XMPP-Konnektor.
Listing 6.6: Senden und Empfangen einer XMPP-Nachricht1 XMPPConnection("Servername");2
3 connection.connect();4 connection.login("user", "pass");5 PacketFilter filter = new AndFilter(new PacketTypeFilter(6 Message.class));7
8 PacketListener myListener = new PacketListener() {9 public void processPacket(Packet packet) {
10 if (packet instanceof Message) {11 Message msg = (Message) packet;12 if (msg.getBody() != null) {13 if (!msg.getBody().equalsIgnoreCase("null")) {14
15 Message message = new Message();16 message.setTo(msg.getFrom());17 message.setBody("OK");18 message.setType(Message.Type.normal);19 connection.sendPacket(message);20 }21 }22 }23 }24 };
Zuerst wird eine Verbindung zum Server aufgebaut. Danach wird auf diese Verbindung ein
sogenannter PacketFilter eingesetzt. Dieser ist ein Filter auf Nachrichten. Realisiert ist
dies im Listing mit einem Filter auf den Paket-Typ der Klasse Message. Dadurch kommen
nur Messages an. Nun wird dieser PacketListener registriert. Dieser wird aufgerufen,
wenn ein Paket eintrifft, das vom Typ Message ist. Wenn nun eine Nachricht eintrifft, wird
im Quellcode des Listeners eine Nachricht mit dem Inhalt OK erzeugt und an den Sender
zurück geschickt.
6.1.6. Einbindung der Services in die Webapplikation (Autoren: Christopher Ezell)
Jersey bietet ein sehr schönes Feature zum Einbinden von globalen Dependencies ohne di-
rekt das Singleton-Pattern einsetzen zu müssen103. Bei dieser Technik wird ein Objekt in den
Kontext der Webanwendung eingebaut, welches nun global zur Verfügung steht und von allen
102siehe http://www.igniterealtime.org/downloads/index.jsp103Das Singleton-Pattern zählt seit den letzten Jahren in Java zu den Pattern, die nicht benutzt werden sollten, um
einen globalen Status zu halten (vgl. [Tea09])
130
6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
anderen Objekten innerhalb von Jersey über den Kontext genutzt werden kann. Dieses Objekt
ist der ContextService. Über ihn kann auf alle Services zugegriffen werden. Diese Tech-
nik wurde verwendet, um die Services global innerhalb der Webapplikation zur Verfügung zu
stellen. Die Vorgehensweise ist wie folgt. Durch eine Annotation @Context in den Klammern
der Parameter einer Funktion ist es möglich, Variablen aus dem Kontext der Jersey-Applikation
in die jeweilige Methode zu injizieren104 und so an das globale Objekt zu gelangen. Listing 6.7
zeigt die Verwendung dieser Methode am Beispiel der Injizierung des ServletContext in
eine Methode von Jersey, um diesen Kontext in einer Methode zu verwenden. Über die Re-
ferenz zum Kontext kann auf diesen zugegriffen werden und der ContextService geholt
werden. Hierzu muss dieser beim Starten der Webanwendung geladen werden.
Listing 6.7: Beispiel einer Jersey-Methode1 @PUT2 public Response test(@Context ServletContext servletContext)
{3 //...4 }
Dies geschieht über einen Web-Setuplistener, der in der web.xml registriert wird. Dieser Setup-
Listener wird noch vor allen anderen Methoden aufgerufen. Hier ist der Ort zum initialisieren
des ContextService. Die web.xml ist in Listing 6.8 dargestellt. Die als Setup-Listener
registrierte Klasse InstantscrumWebSetupListener ist in Listing 6.9 dargestellt. Hier
wird der ContextService erzeugt und in den ServletContext eingebaut. Dieser kann
nun verwendet werden.
Listing 6.8: Einbindung des SetupListener in web.xml1 <web-app>2 ...3 <listener>4 <listener-class>de.crossbeanmedia.scrumapp.web.
instantscrumWebSetupListener</listener-class>5 </listener>6 ...7 </web-app>
104Dieses Wort stammt von dem Wort Dependency Injection und bedeutet, dass die benötigten Objekte, die inner-halb einer Methode gebraucht werden, nicht aktiv geholt werden müssen, sondern von außen eingespeist werdenkönnen.
131
6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
Listing 6.9: Initialisierung des Contextservice1 @Override2 public void contextInitialized(ServletContextEvent arg0) {3 log.info("contextservice called");4 final DefaultConfigurationBuilder builder = new
DefaultConfigurationBuilder();5 builder.setFileName("instantscrum-web-bootstrap.xml");6 Configuration config = null;7 try {8 config = builder.getConfiguration(true);9 ContextService service = new ContextService(config);
10 arg0.getServletContext().setAttribute("ContextService",service);
11 } catch (ConfigurationException e) {12 log.error("error in contextservice.startup ", e);13 }14 }
Wie in der Abbildung A.14 dargestellt, sind die Services alle von einer abstrakten Oberklas-
se AbstractService abgeleitet (Listing 6.10). Diese hält den ContextService und
bietet so eine einheitliche Zugriffsmöglichkeit auf den Basis-Service. Hierdurch ist auch ge-
währleistet, dass sich die Services untereinander finden und nutzen können ohne das Pattern
des Singletons zu benutzen. So kann eine Instanz der Klasse TaskService auf die Dienste
der anderen Services zugreifen, was im Quellcode in Listing 6.11 zu sehen ist.
Listing 6.10: AbstractService in ServletContext1 public abstract class AbstractService {2
3 private ContextService contextService;4
5 public AbstractService(ContextService contextService) {6 this.contextService = contextService;7 }8
9 protected synchronized ContextService getContextService() {10 return contextService;11 }12 }
Listing 6.11: Service aufrufen mit dem ContextService
1 getContextService().getMailService().sendEmail("", "", "")
6.1.7. XML-Binding (XMLService) (Autor: Rene Kassel)
Die Umsetzung der Generierung von XML aus den Klassen wurde mit JAXB realisiert. Die
Grundlagen hierfür wurden im Kapitel 3.2.2 beschrieben. Um eine Klasse mit JAXB in eine
XML umwandeln zu können, muss die betroffene Klasse die Annotation @XmlRootElement
aus javax.xml.bind.annotation tragen. Des Weiteren muss die Klasse für alle Felder
132
6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
getter und setter-Methoden und einen parameterlosen Defaultkonstruktor bieten. Wenn
dies alles erfüllt ist, kann die Klasse in XML umgewandelt werden.
Listing 6.12: Beispiel Klasse mit JAXB-Annotationen1
2 @XmlRootElement3 @Entity4 public class ScrumTask {5 public static final long DEFAULT_ID = 1234;6 private String taskName;7 private String status;8
9 public ScrumTask() {}10
11 public String getTaskName() {12 return taskName;13 }14 public void setTaskName(String taskname) {15 this.taskName = taskname;16 }17 public String getStatus() {18 return status;19 }20 public void setStatus(String status) {21 this.status = status;22 }23 }
Ein Beispiel ist die in Listing 6.12 dargestellte Klasse ScrumTask. Diese Klasse erfüllt al-
le Bedingungen, um in XML umgewandelt werden zu können. Bei dem folgenden Beispiel
werden zwecks einer besseren Übersichtlichkeit nur zwei Felder benutzt. Es soll gezeigt wer-
den, wie die XML aus Listing 6.13 in ein Java Objekt der Klasse ScrumTask gewandelt
werden kann. Dies ist in Listing 6.14 dargestellt. Zuerst wird ein JAXBContext erstellt. Da-
nach wird mittels der Methode Unmarshaller.unmarshal die XML in ein Java-Objekt
gewandelt.
Listing 6.13: Beispiel XML aus einem Objekt1 <scrumTask>2 <taskName>hallo</taskName>3 <status>done</status>4 </scrumTask>
Listing 6.14: Unmarshalling von XML mit JAXB1 JAXBContext context = JAXBContext.newInstance();2 Unmarshaller unmarshaller =context.createUnmarshaller();3 ScrumTask scrumTask= (ScrumTask) unmarshaller.unmarshal(new
StringReader( xml));
Die Funktionälität zum Generieren und Lesen von XML ist im XMLService umgesetzt und
wird von der REST-API zum marshallen und unmarshallen der Anfragen genutzt.
133
6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
6.1.8. REST-API (Autor: Christopher Ezell)
Für das Restinterface ist die Entscheidung auf das Jersey Framework [Com12a] der Glass-
fish Community [Comc] gefallen. Jersey ist eine für produktivzwecke einsetzbare Java API
for RESTful Web Services (JAX-RS). Es ist die Java-Referenzimplementierung für REST-
Webanwendungen. Jersey funktioniert komplett über sogenannte Annotations und POJOs. Es
verwendet dabei ein Servlet, welches die Anfragen an die entsprechenden Endpunkte weiter-
leitet.
Jersey stellt ein Servlet bereit, welches in die Web-Applikation eingebunden wird. In Listing
6.15 ist dies dargestellt. Wie hier zu sehen, wird das Jersey-Servlet auf alles gemappt, was mit
der URL rest/ beginnt. Hierzu werden alle Klassen aus dem package
de.crossbeanmedia.scrumapp.restinterface genommen, die eine entsprechen-
de Annotation besitzen. Ein Beispiel einer Service-Klasse ist in Listing 6.16 dargestellt. Dort ist
die Methode getString definiert. Die gezeigte Klasse NewsStream hat eine Annotation
@Path("/news") und eine Methode mit der Annotation @GET. Diese Methode wird aufge-
rufen, wenn die Ressource mit dem Pfad /news und der Methode GET aufgerufen wird. Hier
wird dann die HTTP-Antwort mit dem Kontent Hallo Welt und dem Status-Code 200105
gesendet.
Abbildung 6.3 zeigt, wie die Klassen der Plattform in die REST-API eingebunden sind.
Listing 6.15: Beispiel einer Jersey web.xml1 @Path("/news") public class NewsStream extends2 <web-app>3 <servlet>4 <servlet-name>Jersey REST Service</servlet-name>5 <servlet-class>ServletContainer</servlet-class>6 <init-param>7 <param-name>com.sun.jersey.config.property.packages</param
-name>8 <param-value>de.crossbeanmedia.scrumapp.restinterface</
param-value>9 </init-param>
10 <load-on-startup>1</load-on-startup>11 </servlet>12 <servlet-mapping>13 <servlet-name>Jersey REST Service</servlet-name>14 <url-pattern>/rest/*</url-pattern>15 </servlet-mapping>16 </web-app>
105OK
134
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Listing 6.16: Beispiel einer Jersey Service Klasse1 @Path("/news")2 public class NewsStream extends AbstractRestService {3
4 @GET5 @Produces({ "application/xml", "application/json" })6 public Response getString() {7 return Response.ok("Hallo Welt").build();8 }9 }
Abbildung 6.3.: Klassendiagramm RestServices (Quelle: Eigene Darstellung)
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Nachdem die Implementierung des Servers beschrieben wurde, wird nun die Implementierung
des Clients behandelt. Wie schon in den letzten Kapiteln erwähnt, handelt es sich um eine
iPhone-Applikation. Die Anforderungen und zu implementierenden Features sind in den Ka-
piteln 4 und 5.5 erläutert. Es soll in diesem Kapitel nicht jedes Detail und jede Funktionalität
der Applikation beschrieben werden. Es soll viel mehr in jedem Unterkapitel eine Technik be-
schrieben werden, die zur Implementierung dieser Applikation beigetragen hat und wo diese
in der Applikation genutzt wurde.
135
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
6.2.1. REST-Anbindung (Autor: Christopher Ezell)
Die REST-Anbindung ermöglicht der iPhone-Applikation die Kommunikation über das Rest-
protokoll mit einem Server. Für diese Anbindung wird das Framework RestKit verwendet
[Com12b]. Es stellt eine große Fülle an Funktionen bereit, die das Entwickeln einer Restful-App auf iOS sehr vereinfacht. Innerhalb der iPhone-Applikation wird diese Anbindung von
REST als REST-Konnektor bezeichnet.
Die Integration des RestKit-Frameworks im Quellcode geht über Delegates106. Dies stellt auch
eine sehr elegante Lösung dar, weil es sich nahtlos in eine existierende iOS-App integrieren
lässt.
Die Klasse zum Aufrufen einer REST-URL ist RKClient. Listing 6.17 zeigt die Initialisie-
rung der Klasse und den Aufruf einer REST-URL mit einer HTTP-Authentifizierung.
Listing 6.17: Initialisierung von einem RKClient
1
2 RKClient *client = [RKClient clientWithBaseURL:@"https://..."];
3 [RKClient clientWithBaseURL:@"https://..." username:@"test"password:@"test"];
Die Klasse, die innerhalb einer Applikation als die Funktion des RestKit-Delegate fun-
gieren möchte, muss das im RestKit-Framework definierte protocol RKRequestDelegate
implementieren. Dies ist im Listing 6.18 zu sehen. Die wichtigste Methode in diesem pro-
tocol ist die Methode didLoadResponse. Die Methode wird aufgerufen, wenn ein Re-
quest fertig übertragen wurde. In den Fehlerfällen werden je nach Fehlerfall die Methoden
requestDidCancelLoad, requestDidTimeout oder didFailLoadWithError
aufgerufen.
Listing 6.18: Delegate-Methoden des Protokolls RKRequestDelegate1
2 - (void)request:(RKRequest*)request didLoadResponse:(RKResponse*)response;
3
4 - (void)request:(RKRequest*)request didFailLoadWithError:(NSError*)error;
5
6 - (void)requestDidStartLoad:(RKRequest*)request;7
8 - (void)request:(RKRequest*)request didSendBodyData:(NSInteger)bytesWritten
9 totalBytesWritten:(NSInteger)totalBytesWritten10 totalBytesExpectedToWrite:(NSInteger)totalBytesExpectedToWrite
;11
12 - (void)requestDidCancelLoad:(RKRequest*)request;13
106siehe auch 3.3.3
136
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
14 - (void)requestDidTimeout:(RKRequest*)request;
Wenn nun die Methode didLoadResponse aufgerufen wird, ist die Übertragung beim Ser-
ver abgeschlossen. Zusätzlich muss innerhalb der Methode geprüft werden, was für eine Art
der Antwort zurückgekommen ist, welcher Statuscode zurückgegeben wurde und was der In-
halt der Nachricht ist. Dies ist in Listing 6.19 dargestellt.
Listing 6.19: Parsen einer Response1
2 - (void)request:(RKRequest*)request didLoadResponse:(RKResponse*)response {
3
4 if ([request isGET]) {5 if ([response isOK]){6 ...7 }8 }9 }
In der Klasse RKClient gibt es jeweils eine Methode für jedes Verb bei REST (z.B. GET,
POST, PUT und DELETE). Zu sehen sind die Definitionen in Listing 6.20. Dies macht die
Programmierung mit dieser Klasse sehr intuitiv.
Listing 6.20: Auszug aus der RKClient.h1
2 - (RKRequest*)get:(NSString*)resourcePath delegate:(NSObject<RKRequestDelegate>*)delegate;
3 - (RKRequest*)get:(NSString*)resourcePath queryParams:(NSDictionary*)queryParams delegate:(NSObject<RKRequestDelegate>*)delegate;
4 - (RKRequest*)post:(NSString*)resourcePath params:(NSObject<RKRequestSerializable>*)params delegate:(NSObject<RKRequestDelegate>*)delegate;
5 - (RKRequest*)put:(NSString*)resourcePath params:(NSObject<RKRequestSerializable>*)params delegate:(NSObject<RKRequestDelegate>*)delegate;
6 - (RKRequest*)delete:(NSString*)resourcePath delegate:(NSObject<RKRequestDelegate>*)delegate;
Alle Methoden benötigen Kontent, der zum Server übertragen werden muss. Eine Ausnah-
me stellt die Methode GET dar. Hierzu wird bei RESTKit ein Objekt einer Klasse, die das
protocol RKRequestSerializable implementiert, benötigt. Dieses protocol defi-
niert die Methoden aus Listing 6.21. Ein Objekt muss die Methode
HTTPHeaderValueForContentType und mindestens eine der optionalen Methoden
HTTPBody oder HTTPBodyStream implementieren. Die Rückgabe dieser Methode sollte
eine serialisierte Form des zu übertragenden Objektes sein und wird dann als NSData an den
HTTP-Request angehangen.
137
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Listing 6.21: Delegate-Methoden des Protokolls RKRequestSerializable1
2 @protocol RKRequestSerializable3
4 /**5 * The value of the Content-Type header for the HTTP Body
representation of the serialization6 */7 - (NSString*)HTTPHeaderValueForContentType;8
9 @optional10
11 - (NSData*)HTTPBody;12 - (NSInputStream*)HTTPBodyStream;13 - (NSUInteger)HTTPHeaderValueForContentLength;14
15 @end
6.2.2. XMPP-Integration (Autor: Christopher Ezell)
Die Integration mit einem XMPP-Server erfolgt über das XMPPFramework von Robbie Han-
son [Han12]. Es bietet eine sehr stabile und ausgereifte API für XMPP. Es gibt hier eine Fassa-
de, die alle Funktionalitäten kapselt. Mittels dieser Klasse können alle Dienste von XMPP
genutzt werden. Es wird im weiteren bei dieser Funktionalität der Name XMPP-Konnektor
verwendet. Die Daten, die der XMPP-Konnektor zur Anmeldung an den XMPP-Server benö-
tigt, bekommt er aus dem User-Objekt, welches bei der Anmeldung des Users auf dem iPhone
gespeichert wird. In Listing 6.22 ist beispielhaft das Senden einer XMPP-Nachricht dargestellt.
Listing 6.23 zeigt die Implementierung innerhalb der Klasse und die Integration der Daten des
gespeicherten Users. Sehr gut ist hier zu erkennen, das eine XML-Nachricht aufgebaut wird,
die dann über die Klasse xmppStream versendet wird.
Listing 6.22: Senden von Inhalt mit XMPP auf iOS1 [[XMPPDelegate getInstance] sendmessageWithContent: @"Hallo
Welt", [[XMPPDelegate getInstance] myJID], deviceToken]];
Listing 6.23: Senden einer Nachricht mit XMPP auf iOS1 -(void) sendmessageWithContent:(NSString*)string{2 NSXMLElement *body = [NSXMLElement elementWithName:@"body"
];3 [body setStringValue:string];4
5 NSXMLElement *message = [NSXMLElement elementWithName:@"message"];
6 [message addAttributeWithName:@"type" stringValue:@"chat"];
7 [message addAttributeWithName:@"to" stringValue:self.currentChatUserName];
8 [message addAttributeWithName:@"from" stringValue:myJID];
138
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
9 [message addChild:body];10
11 [self.xmppStream sendElement:message];12 }
Listing 6.24 stellt die wichtigsten Methoden der XMPP-Fassade dar. Dies sind Methoden zum
Senden und Empfangen von Nachrichten und zum Erhalten von Status-Updates.
Listing 6.24: Die Methoden der XMPP-Fassade1 - (void) sendmessageWithContent:(NSString*)string; - (void)
goOnline;2 - (void)goOffline;3 - (void)xmppStream:(XMPPStream *)sender didReceiveMessage:(
XMPPMessage *)message;4 - (void)xmppStream:(XMPPStream *)sender didReceivePresence:(
XMPPPresence *)presence;5 - (void)xmppStreamDidDisconnect:(XMPPStream *)sender withError
:(NSError *)error;
Damit der richtige Online/Offline-Status angezeigt wird, werden die Methoden des
ApplicationDelegate genutzt. Hier werden die Methoden goOnline und goOffline
aufgerufen. Dies ist in Listing 6.25 dargestellt. Wenn die Applikation pausiert
(applicationDidEnterBackground), wird die Verbindung zum XMPP-Server getrennt.
Wird die Applikation wieder aktiviert (applicationWillEnterForeground), wird die
Verbindung wieder aufgebaut.
Listing 6.25: Online und Offline gehen mit dem XMPP-Konnektor1 - (void)applicationDidEnterBackground:(UIApplication *)
application {2 [delegate goOffline];3 [delegate disconnect];4 }5 - (void)applicationWillEnterForeground:(UIApplication *)
application {6 [delegatew connect];7 [delegatew goOnline];8 }
6.2.3. XML/JSON-Parser (Autor: Rene Kassel)
Das Parsen von XML und JSON auf dem iPhone ist ein sehr häufiger Anwendungsfall. Daher
existieren einige sehr gute Standardlösungen, auf die zurückgegriffen werden kann. Für jeden
Anwendungsfall wurde jeweils ein Framework benutzt.
Für das Parsen von XML wurde das Framework namens XMLTreeParser benutzt (vgl. [osm12]).
Ein Beispiel dafür, wie das XML aus Listing 6.26 zu parsen ist, wird in Listing 6.27 gezeigt.
Zuerst wird ein neuer XMLTreeParser erzeugt. Zudem wird noch ein String erzeugt, wel-
cher die Beispielantwort des Servers in XML beinhaltet. Nachdem dies geschehen ist, kann
139
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
durch das Senden der Nachricht parse an das Objekt XMLTreeParser ein Objekt vom Typ
XMLTreeNode erstellt werden. Dieses Objekt stellt das Wurzelelement des XML-Baumes
dar. Nun können durch das Aufrufen der Methode findChildren rekursiv die jeweiligen
Kindelemente entnommen und verarbeitet werden.
Listing 6.26: Einfaches XML-Beispiel1 <person>2 <vorname>Harald</vorname>3 <name>Lesch</name>4 </person>
Listing 6.27: Simples Parserbeispiel von XML mit XMLTreeNode1 XMLTreeParser *parser = [[XMLTreeParser alloc] init];2 NSString *testString =3 @"<person><vorname>Harald</vorname><name>Lesch</name></
person>";4
5 XMLTreeNode* root =6 [parser parse:[testString dataUsingEncoding:
NSUTF8StringEncoding]];7 XMLTreeNode* person =8 [[root findChildren:@"person"]objectAtIndex:0];9 XMLTreeNode* vorname =
10 [[person findChildren:@"vorname"] objectAtIndex:0];11 XMLTreeNode* name =12 [[person findChildren:@"name"] objectAtIndex:0];13
14 NSLog(@"Vorname: %@, Nachname: %@", vorname.text, name.text);
Es ist also mit diesem Parser möglich, prozedural durch die Knoten zu iterieren und so die
benötigten Daten aus der XML herauszufiltern.
Für das Parsen von JSON steht in iOS ebenfalls ein sehr gutes Framework zur Verfügung,
das SBJSON-Framework. Es generiert aus einem JSON-String verschachtelte Schüssel-Wert-
Paare. Diese stellen die JSON-Struktur dar. Die Struktur kann dann geparst und in Objek-
te gewandelt werden. Ein Beispiel zeigt Listing 6.28. Hier wird ein Objekt von der Klasse
DiigoBookmark mit Daten aus einem JSON-String befüllt. Es werden dazu die Klassen
aus dem SBJSON-Framework genutzt. Die Klasse SBJsonParser kann mittels der Metho-
de objectWithString aus einem JSON-String diese verschachtelten Schüssel-Wert Paare
erstellen. Durch diese können nun innerhalb einer Schleife die benötigten Informationen aus
allen Objekten extrahiert werden.
140
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Listing 6.28: JSON parsen unter iOS1
2 SBJsonParser *jsonParser = [[SBJsonParser alloc] init];3 NSDictionary *jsonObjects = [jsonParser objectWithString:
jsonString error:&error];4
5 NSMutableArray *marks = [NSMutableArray array];6
7 for (NSDictionary *dict in jsonObjects)8 {9 DiigoBookmark *mark = [[DiigoBookmark alloc] init];
10 mark.updated_at = [dict objectForKey:@"updated_at"];11 mark.url = [dict objectForKey:@"url"];12
13 }
6.2.4. Diigo-Integration (Autor: Rene Kassel)
Die Diigo-Integration erfolgt über einen angepassten JSON-Parser mit REST-Anbindung. Die
Umsetzung basiert also auf einen REST-Konnektor, der durch die gespeicherten Anmeldedaten
des Users auf dem iPhone die Anmeldedaten für den Dienst Diigo besitzt und sich so zu dem
Dienst verbinden kann. Hierzu gibt es eine Klasse DiigoJSONParser, die das protocol
RKRequestDelegate implementiert und in der Methode didLoadResponse die Daten
der Bookmarks extrahiert. Diese Thematik ist schon im Listing 6.28 erläutert worden.
6.2.5. Simplenote-Integration (Shared Notes) (Autor: Christopher Ezell)
Die Simplenote-Integration erfolgt wie die Diigo-Integration über einen angepassten JSON-
Parser mit REST-Anbindung.Es werden wieder die Daten des Nutzers verwendet, um sich
bei dem Dienst anzumelden und den Dienst mittels REST aufzurufen. Hierzu gibt es eine
Klasse SimpleNoteListJSONParser, die das protocol RKRequestDelegate im-
plementiert und in der Methode didLoadResponse die Daten der Notizen extrahiert. Da
aber in der Liste von Notizen noch nicht die Daten der Notiz enthalten sind, muss noch jede
einzelne Notiz aufgerufen und geparst werden. Dies wurde mithilfe einer eigenen Notifica-
tion umgesetzt. In der Klasse SimpleNoteListJSONParser wird am Ende der Metho-
de didLoadResponse die Notification getSimpleNoteContent geworfen. Dies ist in
Listing 6.29 dargestellt.
Listing 6.29: Posten einer Notification1 [[NSNotificationCenter defaultCenter] postNotificationName:@"
getSimpleNoteContent" object:self];
Die Notification wird in der Model-Klasse abgefangen. Dort werden im Anschluss die Daten
für jede einzelne Notiz nachgeladen. Dies ist in Listing 6.30 gezeigt. Hier wird für jeden String
in dem Array simpleNoteKeys die Daten für eine Notiz geladen.
141
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Listing 6.30: Registrierung des Oberservers und Implementierung der Methode1 [[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(simpleUpdatedNotification:)2 name:@"reloadDataSimpleNote" object:nil
];3
4 - (void)simpleUpdatedNotification:(NSNotification *)notification{
5 for (NSString* keyTemp in simpleNoteKeys) {6 NSString* noteUrl = [[NSString alloc] initWithFormat:@
"/data/%@%@", keyTemp, @"?auth=XXX&email=XXX" ];7 NSLog(@"%@", noteUrl);8 [clientSimple get:noteUrl delegate:simpleParserFill];9 }
10 }
Um beim Laden der Liste möglichst zeitnah die neuen Daten anzuzeigen, wurde das Key-
Value-Observing Feature aus Kapitel 3.3.4 verwendet. Der Observer ist in der Klasse
NoteListController eingefügt. Dies ist in Listing 6.31 zu sehen. Dabei handelt es sich
um den Controller von der Listenansicht der Notizen. Hier wird definiert, dass der Wert
model.simpleNoteList überwacht werden soll. Immer, wenn sich hier etwas ändert,
triggert der Mechanismus. Dadurch wird die Methode aus Listing 6.32 aufgerufen. An die-
ser Stelle werden nun die Daten aus dem Model neu geladen und die neuen Inhalte werden
sofort dargestellt.
Listing 6.31: Registrierung des Oberservers Beispiel1 [self addObserver:self forKeyPath:@"model.simpleNoteList"
options:NSKeyValueObservingOptionNew context:nil];
Listing 6.32: Implementierung der Observer-Methode1 - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(
id)object change:(NSDictionary *)change context:(void *)context{
2 [self.tableView reloadData];3 }
6.2.6. Konfigurations-Management (Autor: Rene Kassel)
Das Iphone bringt einen eigenen internen Mechanismus mit, wie die Konfiguration gestaltet
werden soll. Hierzu gibt es in der App ein sogenanntes Settings-Bundle. Dies enthält in einer
eigenen Form die Einträge der Einstellungen. Ein solches Settings-Bundle ist eine XML107, die
mit Key-Value-Pairs die nötigen Einträge enthält (siehe Listing 6.33). Es gibt aber auch einen
grafischen Editor. Dieser kann in Abbildung 6.4 eingesehen werden.
107Dies ist in Form einer sogenannten plist, die bei Apple-Produkten häufig Verwendung findet.
142
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 6.4.: Der grafische Editor des Settings-Bundle (Quelle: Eigene Darstellung)
Listing 6.33: Plist-XML-Datei mit den darin enthaltenen Einstellungen1 <?xml version="1.0"2 encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST
1.0//EN"3 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">4 <plist version="1.0">5 <dict>6 <key>StringsTable</key>7 <string>Root</string>8 <key>PreferenceSpecifiers</key>9 <array>
10 <dict>11 <key>Type</key>12 <string>PSTextFieldSpecifier</string>13 <key>Title</key>14 <string>App-name</string>15 <key>Key</key>16 <string>app_name</string>17 <key>DefaultValue</key>18 <string>app</string>19 </dict>20 </array>21 </dict>22 </plist>
Wenn nun das Settings-Bundle in das iOS-Bundle eingebaut wird, erscheint es in der Einstel-
lungsseite des iPhones. Dieser Sachverhalt ist in Abbildung 6.5 zu sehen. Die Konfigurationen
sind im Quellcode, wie in Listing 6.34 dargestellt, auslesbar. Zu sehen ist, dass über die Klasse
NSUserDefaults auf die Einstellungen zugegriffen werden kann.
Listing 6.34: Herausholen von Settings aus dem Settings-Bundle1
2 NSUserDefaults *defaults = [NSUserDefaultsstandardUserDefaults];
3 NSString *app = [defaults stringForKey:@"app_name"];
143
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 6.5.: Die iPhone Oberfläche der Einstellungen (Quelle: Eigene Darstellung)
6.2.7. Ortungsdienste (Autor: Christopher Ezell)
Ein großer Vorteil des iPhones ist die nahtlose Integration vieler Sensortechniken, die über
die API benutzt werden können. Es handelt sich bei dem Ortungssensor im iPhone nicht um
reines GPS, sondern um einen Mix aus UMTS, WLAN und GPS108 Um den Ortungssensor auf
dem iPhone nutzen zu können, kann das für diesen Zweck von Apple zur Verfügung gestellte
Framework CoreLocation verwendet werden. Es ist durch diese nahtlose Integration der
Ortsdienste möglich, nativ in einer Applikation die Position des iPhones zu nutzen.
Um nun CoreLocation nutzen zu können, muss eine Klasse erstellt werden, die das protocol
CLLocationManagerDelegate implementiert. Listing 6.35 zeigt die wichtigsten Me-
thoden des Protokolls. Die Methode didUpdateToLocation wird automatisch aufgeru-
fen, sobald eine neue GPS-Position vom Gerät ermittelt wird. Übergeben werden hier dem
Location-Manager die neue Position sowie die alte Position.
Listing 6.35: Auszug aus dem CLLocationManagerDelegate-Protokoll1
2 - (void)locationManager:(CLLocationManager *)manager3 didUpdateToLocation:(CLLocation *)newLocation fromLocation:(
CLLocation4 *)oldLocation;5
6 - (void)locationManager:(CLLocationManager *)managerdidFailWithError:(NSError
108Zitat aus dem Apple Developer Portal: „The framework uses information obtained from the built-in cellular,Wi-Fi, or GPS hardware to triangulate a location fix for the device.“ [App12a]
144
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
7 *)error;
Listing 6.36 zeigt die Verwendung von einem Location-Manager im eigenen Programm. Der
Ausdruck locationManager.delegate = self; (Zeile 8 des Listings) sagt dem Ob-
jekt, dass das aufrufende (also self) Objekt das protocol CLLocationManagerDelegate
implementiert und bei den oben genannten Ereignissen aufgerufen werden sollte. Die komplet-
te Initialisierung des locationManagers passiert in der Methode viewDidLoad, also
noch bevor der Screen der aktuellen View gezeichnet wird. Wenn nun die View kurz vor dem
ersten Zeichnen steht, wird die Methode viewWillAppear aufgerufen. Hier wird durch das
Senden der Message startUpdatingLocation an das Objekt locationManager die
erste Position ermittelt und darauf die Methode didUpdateToLocation aufgerufen. Diese
Methode wird nun bei jeder neu ermittelten Position aufgerufen. Wenn die View nicht mehr neu
gezeichnet wird, wird die Methode viewWillDisappear aufgerufen. Innerhalb dieser wird
die Methode stopUpdatingLocation an das Objekt locationManager gesendet und
somit die Bestimmung der Position gestoppt.
Listing 6.36: Verwendung eines CLLocationManagers1
2 - (void)viewDidLoad {3 BOOL locationAvailable = [CLLocationManager
locationServicesEnabled];4 if(locationAvailable){5 CLLocationManager *locationManager = [[CLLocationManager
alloc] init];6 locationManager.desiredAccuracy = kCLLocationAccuracyBest;7 locationManager.distanceFilter = 3000;8 locationManager.delegate = self;9 }
10 }11
12 - (void)viewWillAppear:(BOOL)animated {13 [locationManager startUpdatingLocation];14 }15
16 -(void)viewWillDisappear:(BOOL)animated {17 [locationManager stopUpdatingLocation];18 }
6.2.8. ’Ziehen zum neu laden’ (Autor: Christopher Ezell)
Das Feature, was in dieser Ausarbeitung Pull to Reload genannt wird, bezeichnet die Möglich-
keit, ein für den Nutzer sehr angenehmes Starten von einem erneutem Abgleich der lokalen
Daten mit dem Server. Es wurde schon in vielen Applikationen auf dem iPhone integriert und
hat sich zu einem quasi Standard entwickelt. Hierdurch ist es ein Bruch in der Nutzerführung,
wenn dieses Feature in einer solchen Applikation nicht vorhanden ist.
145
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 6.6.: Funktion ’Ziehen zum neu laden’ (Quelle: Eigene Darstellung)
Es wird benutzt, indem eine Table-View weiter nach unten gescrollt wird, als normalerwei-
se möglich wäre. Hier greift das sogenannte weiche Scrollen. Dies ist ein Feature von iOS,
welches im Interface Builder aktiviert werden kann. Weiches Scrollen bezeichnet dabei den
Effekt, dass eine Table-View weiter gescrollt werden kann, als Inhalt auf dieser Seite vorhan-
den ist. Nun wird in einer der vom User angepassten Geschwindigkeit ein Bereich angezeigt,
der keinen Inhalt enthält. Dadurch wird eine View im oberen Bereich sichtbar. Diese View ist in
Abbildung 6.6 dargestellt. Auf der View ist ein Indikator, welcher misst, inwieweit noch nach
oben gescrollt werden muss, bis der Pull to Reload ausgeführt wird. Wenn die View weit genug
gezogen wurde, erscheint der Text in Abbildung 6.7. Wenn der Nutzer nun loslässt, werden die
Daten neu geladen und der Text verschwindet.
Abbildung 6.7.: Funktion ’Ziehen zum neu laden’ Teil 2 (Quelle: Eigene Darstellung)
Für diese Funktionalität wurde die Bibliothek EGORefresh genutzt109. Diese bietet eine Unter-
klasse der Klasse UIView, nämlich EGORefreshTableHeaderView. Die View, die die-
ses Feature unterstützen soll, muss nicht von UIView erben, sondern von
EGORefreshTableHeaderView. Die Klasse bietet ein delegate, welches von dem ak-
tuellen ViewController implementiert wird. Dadurch werden die Methoden aus Listing 6.37
automatisch aufgerufen und es können hierbei die Daten erneuert werden.
Listing 6.37: Die Methoden von EGORefreshTableHeaderView1
2 - (void)refreshLastUpdatedDate;3 - (void)egoRefreshScrollViewDidScroll:(UIScrollView *)
scrollView;4 - (void)egoRefreshScrollViewDidEndDragging:(UIScrollView *)
scrollView;5 - (void)egoRefreshScrollViewDataSourceDidFinishedLoading:(
UIScrollView *)scrollView;
109siehe https://github.com/enormego/EGOTableViewPullRefresh
146
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 6.8.: Klassendiagramm ZXing (Quelle: Eigene Darstellung)
6.2.9. QR-Code-Parser (Autor: Christopher Ezell)
Für die Umsetzung des QR-Code-Feature wurde das Framework ZXing110 verwendet. Es bietet
eine sehr generische Möglichkeit alle Arten von Standardinhalten von QR-Codes zu parsen.
ZXing kann standardmäßig folgende Inhalte parsen:
• Text,
• Email-Adressen,
• vCards und
• Links.
Es gibt auch die Möglichkeit eigene Parser einzubinden.
Wie Abbildung 6.8 zeigt, besteht ZXing aus einem UniversalResultParser, der mehre-
re ResultParser aufnehmen kann. Nachdem alle vorhandenen Parser (abgeleitet von
ResultParser) mit registerParser in der Klasse UniversalResultParser re-
gistriert wurden, kann mit der Methode parseResult ein QR-Code geparst werden.
Um nun eigene Datentypen mit dem ZXing-Framework zu parsen, müssen eigene Implementa-
tionen für die Klassen ResultParser, ParsedResult und Action geschrieben werden.
Danach muss noch der neue ResultParser bei dem UniversalResultParser in der
110ausgeprochen ’Zebra Crossing’ [sro12]
147
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Abbildung 6.9.: Klassendiagramm ZXing-Extention (Quelle: Eigene Darstellung)
Liste der Parser eingefügt werden. Für den Fall, dass ein Task encodiert werden soll, sieht die
Erweiterung wie in Abbildung 6.9 aus.
Es wurde von jeder Oberklasse des Frameworks eine Unterklasse für das Parsen eines Tasks
erstellt und diese Klassen wurden in das Framework eingebaut. Durch diese Integration wer-
den nun beim abfotografieren eines QR-Codes die entsprechenden Methoden der Unterklassen
aufgerufen. Hier wird zuerst der vom Framework ausgelesene Inhalt des QR-Codes in Form
eines Strings übergeben und ermittelt, ob es sich bei dem Inhalt um einen Task handelt. Hierfür
ist eine Methode in der Klasse TaskResultParser vorgesehen, die im Listing 6.38 darge-
stellt ist. Wenn diese Methode parsedResultForString etwas anderes als nil zurück
gibt, wird davon ausgegangen, dass ein Task geparst werden konnte. Dies ist der Fall, wenn die
Methode initWithString aus der Klasse TaskParsedResult ein Objekt zurück gibt.
Das ist in Listing listingXINGbasic2 dargestellt. Es prüft, ob der übergebene String mit
task: beginnt. Dies ist die Konvention der generierten QR-Codes für einen Task.
Listing 6.38: Die Methode parsedResultForString1 + (ParsedResult *)parsedResultForString:(NSString *)s2 format:(BarcodeFormat)format
{3 return [[[TaskParsedResult alloc] initWithString:s]
autorelease];4 }
148
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Listing 6.39: Die Methode initWithString der Klasse TaskParsedResult1
2 - (id)initWithString:(NSString *)s {3 if ((self = [super init]) != nil) {4 NSRange range = [s rangeOfString:@"task:"];5 if (range.length > 0){6 NSUInteger i = range.location + range.length;7 NSString* sub = [s substringFromIndex:i];8 self.text = sub;9 }else {
10 return nil;11 }12 }13 return self;14 }
Wenn nun ein QR-Code eingelesen und als Task erkannt wird, soll dieser gleich angezeigt
werden. Innerhalb des ZXing-Frameworks wird die Unterklasse OpenTaskAction111 ange-
sprochen und die Methode clickedButtonAtIndex aufgerufen. In dieser wird die Notifi-
cation showTask erstellt und der Name des extrahierten Tasknamen an die Notification ange-
hangen. Das ist in Listing 6.40 dargestellt. Die Notification wird in der Klasse QrCodeView
gefangen. Mit dem übergebenen Namen wird der entsprechende Task aus dem Model heraus-
gesucht und mit der Methode presentModalViewController angezeigt (siehe Listing
6.41).
Listing 6.40: Posten einer Notification1 - (void)alertView:(UIAlertView *)alertView
clickedButtonAtIndex:(NSInteger)buttonIndex {2 if (buttonIndex != [alertView cancelButtonIndex]) {3 NSNotification *notification = [NSNotification
notificationWithName:@"showTask" object:self.taskname];
4 [[NSNotificationCenter defaultCenter] postNotification:notification];
5 }6 }
Listing 6.41: Parsen eines Tasks1 - (void)showTask:(NSNotification *)notification{2 NSEnumerator *enumerator = [[[InstantScrumModelFacade
getInstance] taskList] objectEnumerator];3 id object;4 while ((object = [enumerator nextObject])) {5 NSString *comparestring = ((NSString *)notification.
object);6 if ([object isKindOfClass:[Task class]]){7 Task *task = ((Task *) object);8 if ([task.taskID isEqualToString:comparestring]) {9 modelfacade.currentTask = task;
111aus Abbildung 6.9
149
6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
10 NSString* username = modelfacade.currentTask.taskName;
11 TaskController* taskc = [[TaskController alloc] initWithNibName:@"TaskControllerView"bundle:nil];
12 [self presentModalViewController:taskcanimated:YES];
13 }14 }15 }16 }
6.2.10. Push-Notifications (Autor: Christopher Ezell)
Die Implementierung der Push-Notification ist auf der Clientseite sehr viel einfacher als auf
der Serverseite. Wenn alle Profile richtig konfiguriert sind, kann im Quellcode der iPhone-
Anwendung ein sogenanntes Device-Token von Apple beantragt werden. Wie dies gemacht
wird, ist in Listing 6.42 zu sehen. Hier wird die Methode
registerForRemoteNotificationTypes aufgerufen. Die Registrierung kann schei-
tern oder erfolgreich sein. Wenn sie gescheitert ist, wird die Methode aus Listing 6.44 aufgeru-
fen. Im positiven Fall wird dagegen die Methode
didRegisterForRemoteNotificationsWithDeviceToken aus dem Listing 6.43
aufgerufen und ein Token wird als Parameter zurückgegeben. Dies kann anschließend weiter
verarbeitet werden112. Nachdem dies erledigt ist, kann ein sogenannter Push-Provider mit dem
eben erhaltenen Token eine Push-Benachrictigung auf diese iPhone schicken.
Listing 6.42: Anfrage auf ein Push Notification Token1 [[UIApplication sharedApplication]2 registerForRemoteNotificationTypes: (
UIRemoteNotificationTypeBadge |3 UIRemoteNotificationTypeSound |4 UIRemoteNotificationTypeAlert)];
Listing 6.43: Erhalten eines Push Notification Tokens1 - (void)application:(UIApplication*)application2 didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)
deviceToken3 {4 NSLog(@"My token is: %@", deviceToken);5 }
Listing 6.44: Empfangen eines Push Notification Errors auf der Clientseite1 - (void)application:(UIApplication*)application2 didFailToRegisterForRemoteNotificationsWithError:(NSError*)
error
112Letztendlich muss das Token über einen Mechanismus an den Server übertragen werden, da er das Token für denPush benötigt.
150
6.3. Implementierung Build und Continious Integration (Autor: Christopher Ezell)
3 {4 NSLog(@"Failed to get token, error: %@", error);5 }
Wenn eine solche Push-Benachrichtigung eintrifft, wird die Methode
didReceiveRemoteNotification aufgerufen. Der Parameter userInfo enthält alle
Daten inklusive der Notification. Diese Daten müssen noch extrahiert werden. So kann immer
auf eine Remote-Push-Notification reagiert werden, auch wenn die Applikation nicht gestartet
ist.
Listing 6.45: Empfangen einer Push Notification auf Clientseite1 - (void)application:(UIApplication *)application2 didReceiveRemoteNotification:(NSDictionary *)
userInfo;
6.3. Implementierung Build und Continious Integration (Autor: ChristopherEzell)
Da in einem agilen Projekt ein schnelles Feedback von Neuerungen und Änderungen im einge-
checkten Quellcode sehr wichtig sind113, spielt die CI eine besonders wichtige Rolle und sollte
die zentrale Anlaufstelle für Fragen an den Projektstatus sein. In dem folgenden Kapitel wird
auf den Aufbau der Build-Struktur und der CI-Integration des Projektes eingegangen und die
grundlegende Funktionsweise erklärt.
Es wird hier nur auf den Build der Serverkomponente eingegangen. Sie ist durch den großen
Umfang und die Komplexität auch die aufwändigste Build-Komponente. Der Build des instant-
scrum-Produktes besteht aus einem verschachtelten Multi-Module-build. Das Listing 6.46 zeigt
einen Auszug aus der pom.xml. Dieses zeigt die einzelnen Module.
Listing 6.46: Module des Parent-Projekts in der pom.xml1 <modules>2 <module>parent</module>3 <module>common</module>4 <module>basemodel</module>5 <module>storageconnector</module>6 <module>streamconnectors</module>7 <module>services</module>8 <module>instantscrum-web</module>9 </modules>
113siehe Kapitel 3.5
151
6.3. Implementierung Build und Continious Integration (Autor: Christopher Ezell)
Die einzelnen Module sind die folgenden:
instantscrum
Dieses Modul enthält das gesamte Projekt und stößt die anderen untergeordneten Builds
in der berechneten Reihenfolge an114.
parent
Das "parentModul enthält alle wichtigen Basiseigenschaften für das Projekt und bil-
det so einen definierten Rahmen, um den gesamten Build laufen zu lassen. Des Wei-
teren werden hier alle globalen Properties gesetzt, die benötigten zusätzlichen Maven-
Repositories angegeben und Profile angelegt. Diese Profile können genutzt werden, um
spezielle Eigenschaften an eine spezielle Umgebung anzupassen115.
common
Nach den beiden Verwaltungsmodulen ist das common-Modul das erste, was Quellcode
enthält. Hier sind grundlegende Konstanten abgelegt, die über die gesamte Anwendung
hinweg genutzt werden sollen.
basemodel
Das Basemodel-Modul beinhaltet die Datenklassen, auf die das gesamte weitere Projekt
aufbaut. In diesem Modul werden auch die ersten Unittests auf die Funktionalität der
Datenklassen ausgeführt. Am Ende dieses Moduls steht ein Paket, welches von der Da-
tenbank zum Laden und Speichern der Daten verwendet wird und auch von der Web-API
zum Versenden der XML-Daten eingesetzt wird.
storageconnector
Das storageconnector-Modul ist die logische Zugriffsschicht auf die im Projekt ver-
wendeten Datendienste wie JPA und Jackrabbit. Es vereinfacht den Zugriff auf diese
Daten.
streamconnector
Das streamconnector-Modul ist im Gegensatz zu dem storageconnector-Modul eine
logische Zugriffsschicht auf externe Dienste und Funktionalitäten, die nicht direkt in den
oberen Services erledigt werden sollen. Zu den eingebundenen Funktionalitäten gehö-
ren unter anderem Mail, ein QR-Code-Generator, XMPP und der Apple Remote Push
Connector.
services
Das Modul der services liegt logisch gesehen direkt unter der Web-API. Es nutzt die
Module storageconnector und streamconnector, um ihre Aufgaben zu erfüllen und
114Dies wird in Maven der Reactor-Build genannt115Ein Beispiel wäre hier der lokale Build am Entwicklerrechner und der Build auf der CI-Umgebung.
152
6.3. Implementierung Build und Continious Integration (Autor: Christopher Ezell)
zu implementieren. Auf diesen beiden Modulen basiert die gesamte Geschäftslogik der
Web-Anwendung.
instantscrum-web
In diesem Modul werden alle vorher genannten Module verwendet und die Funktionali-
tät wird durch eine Web-API zur Verfügung gestellt.
Das Modul instantscrum-web ist das Modul für die Integrationstests der Anwendung. Hier
wird nun die Umsetzung der im Kapitel 5.6 vorgestellten Integrationstests vorgenommen. Be-
vor diese Tests durchlaufen werden können, muss eine komplett lauffähige Umgebung der
späteren Web-Applikation erstellt werden. Durch diese Anforderungen ist der Gesamtaufbau
der pom.xml etwas komplexer und wird im Detail im Folgenden erläutert. Die vollständige
pom.xml kann im Anhang B.1 gefunden werden. Listing 6.47 zeigt den grundlegenden Auf-
bau der pom.xml. Das packaging ist auf war gesetzt. Dadurch wird am ende eine .war Datei
erzeugt, die alle referenzierten Abhängigkeiten beinhaltet. Diese Datei kann dann auf einen
Applikationsserver deployed werden.
Listing 6.47: Pom.xml des Projektes instantscrum-web1 <project>2 <artifactId>instantscrum-web</artifactId>3 <packaging>war</packaging>4 <name>instantscrum-web Maven Webapp</name>5 <parent>6 <groupId>de.crossbeanmedia.instantscrum</groupId>7 <artifactId>parent</artifactId>8 <version>0.0.1-SNAPSHOT</version>9 <relativePath>../parent</relativePath>
10 </parent>11 ...12 </project>
Die benötigten Ressourcen werden in der Sektion <build>...</build> konfiguriert.
Zu sehen ist dies im Listing 6.48. Es ist so konfiguriert, dass alle Ressourcen im Ordner
src/main/java/META-INF, die mit .xml aufhören, mit in die war aufgenommen wer-
den. Hier befindet sich unter anderem die web.xml, in der Jersey konfiguriert ist. Außerdem
werden noch alle Dateien in src/main/resources/ mit aufgenommen. Hier finden sich
unter anderem die Konfiguration für das Logging und die Property-Dateien für die Umge-
bung.
Listing 6.48: Pom.xml des Projektes instantscrum-web (resources)1 <build>2 ...3 <resources>4 <resource>5 <directory>src/main/java/META-INF</directory>6 <includes>7 <include>**.xml</include>8 </includes>
153
6.3. Implementierung Build und Continious Integration (Autor: Christopher Ezell)
9 <filtering>true</filtering>10 </resource>11 <resource>12 <directory>src/main/resources/</directory>13 <filtering>true</filtering>14 </resource>15 </resources>16 ...17 </build>
Der Start des Servers und das deployment der Webapplikation wird von dem Maven-Plugin
Cargo116 erledigt. Dieses ist als Plugin mit in den Build eingebunden. Das Plugin des Builds
ist im Listing 6.49 dargestellt. Hier werden zum einen die Parameter des Plugins definiert.
Ein Beispiel wäre der Name des Servers, der auf glassfish3x gesetzt wird. Das wichtige ist
die Sektion deployer und deployables. Hier wird festgelegt, welche Webapplikationen
auf den Server deployed werden sollen. Hier wird die aus dem Build erzeugte war mit dem
Namen de.crossbeanmedia.instantscrum referenziert. Die weiteren Parameter im
Listing bewirken, dass der Applikations-Server vor der Phase integration-test gestar-
tet und die Web-Applikation deployed wird. Die verwendete Datenbank H2 wird beim Starten
der Anwendung automatisch mit gestartet und kann verwendet werden. Nun kann in der Phase
integration-test die fertige Anwendung mit allen Umgebungen getestet werden. An-
schließend wird nach dieser Phase der Server und die Datenbank wieder gestoppt.
Listing 6.49: Pom.xml des Projektes instantscrum-web (Cargo Plugin)1 <plugin>2 <groupId>org.codehaus.cargo</groupId>3 <artifactId>cargo-maven2-plugin</artifactId>4 <version>1.1.2</version>5 <configuration>6 <wait>false</wait>7 <container>8 <containerId>glassfish3x</containerId>9 </container>
10 <deployer>11 <deployables>12 <deployable>13 <groupId>de.crossbeanmedia.instantscrum</groupId>14 <artifactId>instantscrum-web</artifactId>15 <type>war</type>16 </deployable>17 </deployables>18 </deployer>19 </configuration>20 <executions>21 <execution>22 <id>start-container</id>23 <phase>pre-integration-test</phase>24 <goals>
116Das Cargo-Plugin für Maven (siehe auch http://cargo.codehaus.org/Maven2+plugin) von Code-haus ist ein sehr mächtiges Tool zum automatisieren von Schritten zum Starten und Deployen von Webcontai-nern.
154
6.4. Zusammenfassung (Autor: Rene Kassel)
25 <goal>start</goal>26 <goal>deploy</goal>27 </goals>28 </execution>29 <execution>30 <id>stop-container</id>31 <phase>post-integration-test</phase>32 <goals>33 <goal>stop</goal>34 </goals>35 </execution>36 </executions>37 </plugin>
6.4. Zusammenfassung (Autor: Rene Kassel)
In diesem Kapitel wurden ausgewählte Teile der Implementierung dargestellt. Dabei wurde
ein Einblick gegeben, wie die in der Konzeption spezifizierte Plattform umgesetzt wurde. Es
wurde auf die verwendeten Technologien eingegangen und es wurde jeweils an Beispielen die
Funktionsweise erläutert. Im nächsten Kapitel soll nun diese Umsetzung mit den im Kapitel 4
definierten User Stories verglichen werden.
155
7. Anwendungsbeispiel (Autoren: Christopher Ezell und Rene Kassel)
7. Anwendungsbeispiel (Autoren: Christopher Ezell und Rene Kassel)
Dieses Kapitel zeigt die Verwendung der Applikation mit einem simplem Beispiel und die
Interaktionsmöglichkeiten zwischen den Nutzern. Es wurde hierzu die Erstellung der vorlie-
genden Masterarbeit als Beispiel verwendet. Die Funktionalität wird anhand der im Kapitel
definierten User Stories geprüft und fungiert auch gleich als Akzeptanztest.
7.1. Einloggen eines Users (Autor: Rene Kassel)
Mit dem Einloggen eines Users über die iPhone Applikation beginnt diese kleine Geschichte
eines Anwendungsbeispiels. Die genauen Bedingungen zu dieser Funktionalität sind in User
Story 1 beschrieben. Der Login-Bildschirm ist in Abbildung 7.1 zu sehen. Er besteht lediglich
aus den Feldern Username und Passwort sowie einen Login-Button. Bei der Eingabe valider
Nutzerdaten wird der Nutzer weitergeleitet und hat Zugriff auf die weiteren Funktionalitäten
der App. Das Logo der App, was in Abbildung 7.2 zu sehen ist, befindet sich im Hintergrund
des Login-Bildschirms.
Abbildung 7.1.: Screenshot des Loginscreens (Quelle: Eigene Darstellung)
Damit sind alle Abnahmekriterien aus der User Story erfüllt.
156
7.2. Die Verwaltung von Tasks (Autor: Rene Kassel)
Abbildung 7.2.: Screenshot des Logos (Quelle: Eigene Darstellung)
7.2. Die Verwaltung von Tasks (Autor: Rene Kassel)
Das Kapitel behandelt den Abnahmetest von den User Stories 8, 9 und 10 sowie 11 und 12. Ers-
tere beschäftigen sich mit dem Taskbezogenen Funktionen, wie Task einsehen, Task erzeugen
und Task konfigurieren. Zweitere beschreiben die Funktionalitäten bezüglich der Arbeitszeit.
Zunächst ist in Abbildung 7.3 eine Übersicht über alle Projektbezogenen Tasks zu sehen. Da-
bei beinhaltet jede Zelle genau einen Task. Eine Zelle zeigt den Tasknamen, den geschätzten
Arbeitsaufwand sowie die bisherig investierte Arbeitszeit an. Zur besseren Übersichtlichkeit
gibt es eine Statusanzeige mit grün, gelb und rot sowie ein Fortschrittsbalken bezogen auf die
Arbeitszeit. Es ist möglich, jeden dieser Tasks anzuklicken.
Abbildung 7.3.: Screenshot von der Anzeige der Taskliste (Quelle: Eigene Darstellung)
Beim Klick auf einen Task gelangt der Nutzer in die Detailansicht des Tasks. Dies ist in Ab-
bildung 7.4 dargestellt. Hier gibt es Informationen zum Worklog, zur Verantwortlichkeit sowie
diverse Button, welche eine bestimmte Funktionalität ausführen. Assign User weist einen be-
stimmten Nutzer die Aufgabe zu. Über log work lässt sich, wie der Name schon sagt, die
getätigte Arbeitszeit eintragen. Über PlanningPoker soll es die Möglichkeit zum Schätzen des
Arbeitsaufwandes je Task geben.
157
7.3. Ein Chat mit der iPhone App (Autor: Christopher Ezell)
Abbildung 7.4.: Screenshot der Detailansicht eines Tasks (Quelle: Eigene Darstellung)
Beim Klick auf log work öffnet sich eine neue Ansicht, welche in Abbildung 7.5 zu sehen ist.
Dort kann der Nutzer nun über einen Slider seine getane Arbeit eintragen. Über den Commit-
Button in der oberen, rechten Ecke wird die Arbeitszeit endgültig erfasst.
Auch das Anlegen eines Tasks ist möglich. Dazu muss der Nutzer auf den Button in der oberen,
rechten Ecke klicken. Daraufhin öffnet sich eine Ansicht, welche in Abbildung 7.6 dargestellt
ist. Hier gibt es zunächst die Möglichkeit, einen Tasknamen und eine Taskbeschreibung abzu-
geben. Durch den Klick auf den Button Task anlegen wird der neue Task erzeugt und es öffnet
sich wieder die Übersicht über alle Tasks.
Die Abnahmekriterien aus den User Stories sind zum großen Teil erfüllt. Die Umsetzung der
kompletten User Story mit seinen Spezifikationen ist jedoch aus Zeitmangel und da es sich
lediglich um einen Prototypen handelt, nicht durchgeführt worden.
7.3. Ein Chat mit der iPhone App (Autor: Christopher Ezell)
Der Nutzer geht weiter entlang der Funktionalitäten der App und testet den Chat. Dies ist der
Abnahmetest für die User Stories 15 und 16. Sie definieren den Ablauf eines Chatgespräches
mittels der iPhone-Applikation. Abbildung 7.7 zeigt den Screenshot der Chatliste. Es gibt für
jeden Nutzer ein Foto und durch die Einordnung in die verschiedenen Sektionen Available und
Offline ist ersichtlich, welcher Kontakt verfügbar ist.
Wird nun auf eine Zelle eines Available-Kontakt geklickt, wird eine View mit einer Chatansicht
sichtbar. Hier kann der Nutzer mit dem angeklickten Nutzer in Kontakt treten. Zu sehen ist dies
in Abbildung 7.8. Oben in der Mitte ist der Name des Chatpartners zu sehen. Im Hauptfenster
158
7.3. Ein Chat mit der iPhone App (Autor: Christopher Ezell)
Abbildung 7.5.: Screenshot der Ansicht zur Arbeitszeiterfassung (Quelle: Eigene Darstellung)
Abbildung 7.6.: Screenshot zum Anlegen eines Tasks (Quelle: Eigene Darstellung)
159
7.4. Anzeigen des Build-Status (Autor: Rene Kassel)
Abbildung 7.7.: Screenshot von Chatlistenansicht (Quelle: Eigene Darstellung)
ist eine TableView mit Custom Cells, welche die Nachrichten beinhalten mit einem Zeitstem-
pel. Beim Klick auf das Eingabefeld im unteren Bereich der Abbildung fährt eine Tastatur
heraus, mit welcher der User die Nachricht eingeben kann. Durch den Klick auf hide Keyboard
kann die Tastatur wieder versteckt werden. Um den Chatverlauf besser lesen zu können, sind
die Zellen mit unterschiedlichen Farben versehen.
Entsprechend der Abnahmekriterien aus den User Stories sind alle Anforderungen erfüllt.
7.4. Anzeigen des Build-Status (Autor: Rene Kassel)
Eine nächste Funktion, welche durch den Nutzer getestet wird, ist die Anzeige des Buildstatu-
ses des zu implementierenden Projektes. Einzelheiten dazu sind in User Story 5 beschrieben.
Das Aussehen dieser Ansicht ist in Abbildung 7.9 zu sehen. Hier findet sich eine Unterteilung
in verschiedene Projekte.
Jedes einzelne Projekt ist anklickbar, wodurch eine neue Sicht geöffnet wird, welche Detailin-
formationen zu dem Projekt enthält. Diese Detailinformationen bestehen aus:
• Testquote: Wie viele Tests von wie vielen sind fehlgeschlagen?
• Build-Status: Wann schlug der letzte Build fehl?
• Wann war der letzte / erfolgreiche / stabile Build?
Diese Ansicht ist nochmals in Abbildung 7.10 veranschaulicht.
160
7.4. Anzeigen des Build-Status (Autor: Rene Kassel)
Abbildung 7.8.: Screenshot von einem Chat mit einem User (Quelle: Eigene Darstellung)
Abbildung 7.9.: Screenshot der Buildeinsicht (Quelle: Eigene Darstellung)
161
7.5. Die Verwendung der Lokationsdienste (Autor: Christopher Ezell)
Abbildung 7.10.: Screenshot über die Detailansicht eines Builds (Quelle: Eigene Darstellung)
Auch an dieser Stelle wurden zunächst alle Abnahmekritieren, definiert durch die User Story,
erfüllt.
7.5. Die Verwendung der Lokationsdienste (Autor: Christopher Ezell)
Eine nächste Funktion, welche durch den Nutzer getestet wird ist die Anzeige der Map und der
Standort der Projektmitglieder. Die genauen Anforderungen sind in den User Stories 6 und 7
beschrieben.
In Abbildung 7.11 ist das Feature zu sehen. Der blaue Punkt ist die aktuelle, eigene Position.
Der rote Punkt ist die Position des anderen Projektmitglieds. Der Benutzername ist an der
Stelle iphone und die Statusnotiz ist Bin heute in München. Der derzeitige Standort ist noch in
Berlin.
Der Nutzer hat nun die Möglichkeit seinen Standort zu aktualisieren, indem er auf den update-
Button klickt und eine Notiz zum Standort eingibt. Die Positionsdaten werden aus dem GPS-
Sensor des Gerätes entnommen. Die Abfrage sieht zur Zeit so aus, wie sie in Abbildung 7.12
dargestellt ist.
Die in den User Stories beschriebene Funktionalität sowie alle Abnahmekriterien sind damit
erfüllt.
162
7.5. Die Verwendung der Lokationsdienste (Autor: Christopher Ezell)
Abbildung 7.11.: Screenshot der Mapfunktionalität (Quelle: Eigene Darstellung)
Abbildung 7.12.: Screenshot der Updatefunktion der Map (Quelle: Eigene Darstellung)
163
7.6. Die Verwendung der News (Autor: Christopher Ezell)
7.6. Die Verwendung der News (Autor: Christopher Ezell)
Neuigkeiten können durch den Nutzer eingesehen werden und erstellt werden. Dieses Kapitel
behandelt den Akzeptanztest der User Stories 3 und 4. Die Abbildung 7.13 zeigt den Newss-
tream. Eine Neuigkeit besteht aus einem Namen, der Nachricht, einem Ort und einem Zeit-
stempel. Die Neuigkeiten sind chronologisch geordnet.
Abbildung 7.13.: Screenshot des Newsstreams (Quelle: Eigene Darstellung)
Klickt der User auf das Plus in der oberen rechten Ecke, dann öffnet sich eine weitere Ansicht
zum Erzeugen einer Neuigkeit. Dies ist in Abbildung 7.14 dargestellt. Dort hat der Nutzer die
Möglichkeit, einen Ort einzugeben, an welchem er die Nachricht absendet und die Nachricht
selbst. Durch den Klick auf den send-Button wird die Neuigkeit in den Newsstream gesendet
und ist durch alle weiteren Projektmitglieder sichtbar, wie dies in Abbildung 7.15 zu sehen
ist.
Die Akzeptanzkriterien für diese beiden User Stories sind mit den beiden Ansichten vollkom-
men erfüllt. Die Benachrichtigungen per Push und e-Mail sind jetzt hier nicht dargestellt. Diese
Funktionalitäten werden in einem späteren Kapitel noch mal separat behandelt (Kapitel 7.9).
7.7. Einsicht in Userdaten (Autor: Rene Kassel)
Die Einsicht in die Nutzerdaten sind die nächste Haltestelle dieses Anwendungsfallsbeispiels.
Der Nutzer kann zum einen eine Userliste abrufen, wo alle Projektzugehörigen gelistet sind
und zum anderen Informationen zu einzelnen Usern abrufen. Die genaueren Vorgaben dazu
sind in den User Stories 13 und 14 definiert. Abbildung 7.16 zeigt eine Liste von Nutzern.
164
7.7. Einsicht in Userdaten (Autor: Rene Kassel)
Abbildung 7.14.: Screenshot vom Erzeugen einer Neuigkeit (Quelle: Eigene Darstellung)
Abbildung 7.15.: Screenshot des Newsstreams mit der neuen Nachricht (Quelle: EigeneDarstellung)
165
7.8. QR-Code Scan (Autor: Christopher Ezell)
Dabei beinhaltet jede einzelne Zelle genau einen Nutzer. In der Zelle ist der Nutzername und
der aktuelle Standort des Nutzers eingetragen.
Abbildung 7.16.: Screenshot Userliste (Quelle: Eigene Darstellung)
In dieser Ansicht hat der Nutzer nun die Möglichkeit, auf einen bestimmten Nutzer zu klicken.
Er klickt auf den User namens Oliver. Dabei gelangt er zu einer Detailansicht dessen. Dies ist
in Abbildung 7.17 zu sehen. Der Screenshot zeigt den Nutzernamen, die aktuelle Position und
eine Karte mit der aktuellen Position des Nutzers. Der Nutzer hat die Möglichkeit über einen
Button wieder zur Userliste zurückzukehren.
Die Funktionalität entspricht vollständig der definierten aus den User Stories. Jedoch wurde
an dieser Stelle noch eine kleine Verbesserung vorgenommen. Die Userdetails sind von jedem
Nutzer durch den Klick auf diesen zu öffnen.
7.8. QR-Code Scan (Autor: Christopher Ezell)
In seiner Geschichte geht der Nutzer weiter zu dem QR-Code Scan. Dieses Feature ist gedacht,
um Zugriff auf einzelne Tasks über einen QR-Code zu bekommen. Dabei handelt es sich um ein
Versuch, diese neue Technik zu integrieren, um ein komfortables und schnelles Auffinden von
Tasks zu ermöglichen. In der User Story 17 ist dieses Feature genauer spezifiziert. Abbildung
7.18 zeigt den Screenshot vom iPhone. Der QR-Code wird dabei in das weiße Viereck gebracht,
woraufhin der Code eingelesen wird. Hinter dem Code verbirgt sich die Task-ID. Nach dem
Scan wird der Nutzer weiter geleitet zu dem entsprechenden Task.
Der volle beschriebene Funktionsumfang der User Story wurde an dieser Stelle umgesetzt.
166
7.8. QR-Code Scan (Autor: Christopher Ezell)
Abbildung 7.17.: Screenshot Userdetail (Quelle: Eigene Darstellung)
Abbildung 7.18.: Screenshot des QR-Code Scans (Quelle: Eigene Darstellung)
167
7.9. Benachrichtigungssystem der App (Autor: Christopher Ezell)
7.9. Benachrichtigungssystem der App (Autor: Christopher Ezell)
Weitere Funktionalität stellt die App durch ihre automatisierten Benachrichtigungen bereit. Da-
bei werden Benachrichtigungen per e-Mail und per Push-Nachricht unterschieden. Abbildung
7.19 zeigt eine Push-Benachrichtigung von dem Nutzer Rene mit dem Inhalt Einleitung korri-
giert. Die Nachricht wird automatisch gesendet, wenn der Nutzer etwas in den Newsstream ver-
öffentlicht. Zieht der Nutzer nun mit dem Finger über das instantScrum-Symbol, dann gelangt
er sofort in die App zu dem Newsstream. User Story 19 ist die dazugehörige Spezifizierung. In
User Story 18 ist die Benachrichtigung per e-Mail genauer beschrieben. Diese erfolgt ebenso
automatisiert und wird an die, dem Nutzer hinterlegte, e-Mailadresse gesendet. Automatisierte
Nachrichten werden ebenso gesendet, wenn einem bestimmten Nutzer eine Aufgabe zugeord-
net wird. Dabei erhält der betroffene Nutzer sowohl eine Push-Benachrichtigung als auch eine
Benachrichtigung per e-Mail. Damit ist das Risiko, dass er diese wichtige Information nicht
erhält bzw. nicht wahrnimmt, abgeschwächt.
Abbildung 7.19.: Screenshot einer Push-Benachrichtigung von der instantScrum-App (Quelle:Eigene Darstellung)
Der geforderte Funktionsumfang und die Abnahmekriterien sind im vollem Umfang im Rah-
men des Prototypen erfüllt worden.
7.10. Notizenverwaltung (Autor: Christopher Ezell)
Weiterhin wird die Notizverwaltung auf eine Abnahme hin geprüft. Die Bedingungen dafür
sind in den User Stories 20 und 21 festgelegt. Die Abbildung 7.20 zeigt eine Übersicht über
alle Notizen, welche auf dem Server abgelegt sind. Für jede Notiz existiert eine Zelle auf dem
168
7.11. Einsicht in Bookmarks (Autor: Rene Kassel)
iPhone. Die ersten Zeichen des Inhalts der Notiz bilden die Notizüberschrift. Zusätzlich ist in
der Zelle eine 2-zeilige Vorschau zum Inhalt zu sehen.
Abbildung 7.20.: Screenshot der Notizverwaltungsübersicht (Quelle: Eigene Darstellung)
Der Nutzer hat nun die Möglichkeit eine Notiz anzuklicken, um diese einzusehen. Das ist in
Abbildung 7.21 zu sehen. In dieser Ansicht hat er die Möglichkeit, den Inhalt zu verändern
und über den safe-Button auf dem Server abzuspeichern. Der Button wird erst aktiv, wenn eine
Änderung vorgenommen wurde. Die Tastatur ist nur sichtbar, wenn der Nutzer explizit in das
Feld klickt und etwas verändern möchte.
Entsprechend der in den User Stories definierten Vorgaben wurden alle Funktionen prototy-
pisch umgesetzt sowie alle Abnahmekriterien erfüllt.
7.11. Einsicht in Bookmarks (Autor: Rene Kassel)
Dieses Kapitel befasst sich mit dem Abnahmetest der in User Story 22 vorgegebenen Kriterien.
Zunächst sieht der User eine Liste von erstellten Tags, nach denen die Bookmarks klassifiziert
werden. Dort kann er bereits eine Vorauswahl treffen, zu welcher Thematik er geteilte Links
einsehen möchte. Abbildung 7.22 zeigt diese Sicht.
Beim Klick auf ein bestimmtes Tag gelangt der Nutzer in eine weitere Ansicht, welche die
einzelnen Links beinhaltet. In dem Beispiel wurde das ALL-Tag gedrückt. Die Linkliste ist in
Abbildung 7.23 zu sehen.
Klickt der Nutzer wiederum auf einen bestimmten Link, gelangt er in eine integrierte Weban-
sicht, welche die Webseite präsentiert, die hinter dem Link steht. Abbildung 7.25 zeigt die
Webansicht.
169
7.11. Einsicht in Bookmarks (Autor: Rene Kassel)
Abbildung 7.21.: Screenshot über die Änderung einer Notiz (Quelle: Eigene Darstellung)
Abbildung 7.22.: Screenshot Bookmarks sortiert nach Tags (Quelle: Eigene Darstellung)
170
7.11. Einsicht in Bookmarks (Autor: Rene Kassel)
Abbildung 7.23.: Screenshot der Bookmarks innerhalb eines Tags (Quelle: EigeneDarstellung)
Abbildung 7.24.: Screenshot der der Webansicht innerhalb eines Bookmarks (Quelle: EigeneDarstellung)
171
7.12. Ausloggen des Users (Autor: Rene Kassel)
Im großen und ganzen sind alle Anforderungen aus der User Story erfüllt. Die Funktion ist im
vollem Umfang gegeben.
7.12. Ausloggen des Users (Autor: Rene Kassel)
Die kleine Nutzergeschichte endet mit dem Ausloggen. Der User kann sich innerhalb der Use-
rinfo über einen Button ausloggen und wird dadurch am System abgemeldet. Es handelt sich
bei diesem Kapitel um den Abnahmetest für die User Story 2.
Abbildung 7.25.: Screenshot der Useransicht mit Logoutbutton (Quelle: Eigene Darstellung)
7.13. Zusammenfassung (Autor: Christopher Ezell)
Anhand dieser kleinen Anwendungsgeschichte wurde dem Leser beispielhaft die Funktionali-
tät des Prototyps präsentiert. Zudem diente das Beispiel als eine Art Abnahmetest für die in
Kapitel 4 definierten User Stories. Nach dieser Ergebnispräsentation folgen einige Worte zum
Abschluss dieser Ausarbeitung.
172
8. Fazit (Autoren: Christopher Ezell und Rene Kassel)
8. Fazit (Autoren: Christopher Ezell und Rene Kassel)
Es folgt eine abschließende Betrachtung und Bewertung des Projektes. Zudem wird kurz auf
zukünftige Aspekte eingegangen.
8.1. Abschlussbetrachtungen
Das Ziel der Arbeit war die Analyse, wie sich Entwickler in agilen Softwareprojekten durch die
Verwendung moderner Kommunikationsmittel besser verständigen können, um die Kommuni-
kation im Projekt zu fördern. Dafür wurde betrachtet, welche Möglichkeiten existieren, virtu-
elle Teams mittels einer mobilen Projektplattform zu unterstützen. Es wurde analysiert, welche
Kommunikationsmittel in einem verteiltem Umfeld dafür geeignet sind, die Teammitglieder
optimal zu unterstützen. Auf Grundlage dieser Erkenntnisse wurde ein Prototyp einer Projekt-
plattform zur Kommunikation und sozialen Interaktion umgesetzt. Dieser soll es ermöglichen,
mittels einer Smartphone-App den Benutzer mit seinen Teammitgliedern in Kontakt zu bringen
und durch eine verbesserte soziale Interaktion117 in einem verteilten Umfeld den Zusammen-
halt in der Gruppe zu stärken und das Vertrauen zu verbessern. Hierzu wurden verschiedene
Kommunikationsmittel auf ihre Tauglichkeit hin analysiert und nach eigenen Kriterien für die-
se Plattform ausgewählt. Die Untersuchung zur Wirksamkeit dieser Applikation war nicht Teil
dieser Arbeit.
8.2. Resumee
Abschließend wird gesagt, dass es eine sehr anspruchsvolle und nicht triviale Aufgabe war,
dieses Themenfeld zu bearbeiten und den Prototypen zu implementieren. Es wurde von den
Autoren extra für diese Arbeit die Programmiersprache Ojective-C und der Umgang mit der
Programmierumgebung Xcode erlernt. Dies stellte an einigen Punkten eine große Herausforde-
rung und einen großen Zeitaufwand dar. Es musste auch der Inhalt der Arbeit gekürzt werden,
um in dem gesteckten Zeitrahmen die Arbeit fertig zu stellen.Durch diese zeitlichen Proble-
me konnte keine Auswertung durchgeführt werden, inwieweit diese Plattform die untersuchten
Faktoren in einem virtuellen Team verbessert.
117Die soziale Interaktion ist durch das Anwenden der App verbessert.
173
8.3. Erweiterungsmöglichkeiten
Die Bearbeitung war sehr spannend, weil die Autoren dieses Thema selbständig gewählt haben
und somit ein großer persönlicher Anreiz existierte, das Thema so umfänglich wie möglich zu
verwirklichen. Es war für die Autoren trotz der am Ende auftretenden zeitlichen Probleme eine
sehr schöne Aufgabenstellung und hat viele weitere Ideen in diese Richtung hervorgebracht.
Die Verwendung der in der Arbeit analysierten Tools hat einen großen Vorteil in der Bearbei-
tung der Arbeit gebracht. Das stand im unmittelbaren Zusammenhang damit, dass die Autoren
verteilt diese Arbeit entwickelten und konzipierten. Parallel zur Umsetzung bekamen die bei-
den Autoren voneinander immer ein direktes Feedback, welche Tools funktionieren. Das lag
vor allem daran, dass die Tools sofort in einem verteilten Kontext genutzt werden konnten.
Die selbst implementierte App wurde im späteren Verlauf der Arbeit zur Verwaltung der Tasks
und zur Kommunikation untereinander genutzt. Die sozialen Features halfen den Autoren sehr
nicht den Bezug zueinander zu verlieren. Durch regelmäßige Statusupdates wurde immer das
Gefühl vermittelt, den anderen noch zu verstehen.
Durch die positiven Erfahrungen während der Entwicklung und der gleichzeitigen Nutzung
der Tools sind die Autoren der Meinung, dass diese Art von Software eine große Zukunft hat
und diese Art der Kommunikation immer populärer wird. Die Autoren sind der Meinung, dass
die entstandene Plattform enormes Potential besitzt, weiterentwickelt zu werden und die noch
fehlenden Services als Eigenimplementierung nachzureichen. Alleine die Ideen, die aus Zeit-
mangel nicht mehr umgesetzt werden konnten, würden den Nutzen der Applikation nochmals
immens steigern.
8.3. Erweiterungsmöglichkeiten
Die im Rahmen dieser Arbeit umgesetzte Plattform hat nur einen sehr kleinen Teil der potenti-
ellen Möglichkeiten umgesetzt. Ein erster Schritt ist die Umsetzung der nicht implementierten
Features aus dem Konzeptionskapitel 5.
Weitere Punkte sind eine noch höhere Integration in das Backendsystem und eine bessere Be-
nutzeroberflächensteuerung. Es könnten noch sehr viel mehr Dienste und Funktionalitäten in
die App eingebaut werden, die den User in seinem Projektalltag noch besser unterstützen.
Eine große Erweiterung der Plattform ist die Unterstützung von Tablets oder gleich der Umstieg
von einer nativen App hin zu einer universellen Web-App. Dies hätte den großen Charme der
Plattformunabhängigkeit.
Die implementierten Dienste und Konnektoren können noch weiter miteinander verwoben wer-
den. Viel mehr Abläufe innerhalb der Plattform können automatisiert ablaufen. Ein Beispiel
dafür ist das automatische Aktualisieren eines Jabber-Status, wenn der Nutzer in einen neuen
Ort eincheckt.
Ein weiteres Feature ist die Bereitstellung von Meetings in Form einer Smartphone-Funktionalität.
Hier könnten Audioaufzeichnungen und Notizen zu den einzelnen Meetings und Statusupdates
174
8.3. Erweiterungsmöglichkeiten
in einer chronologischen Liste erscheinen. Dadurch können sie von Projektmitgliedern noch-
mals angehört werden. Das kann besonders wichtig sein, wenn sie auf Reisen sind oder den
Termin aus anderen Gründen nicht wahrnehmen konnten. Somit sind sie nicht auf E-Mails
und direkte Nachfragen angewiesen und können die Original-Meetings verfolgen. Dies schafft
Zeitvorteile, die für andere Aktivitäten genutzt werden können.
175
Quellenverzeichnis
Quellenverzeichnis
[agi09] Answering the "Where is the Proof That Agile Methods Work"Question. Website,
2009. – http://www.agilemodeling.com/essays/proof.htm
[ale12a] Alexa Stackoverflow. Website, 2012. – http://www.alexa.com/
siteinfo/stackoverflow.com
[ale12b] Alexa Web Information Plattform. Website, 2012. – http://www.alexa.
com/
[AM11] AARON, Hillegass ; MARK, Fenoglio: Objective-C Programming: The Big
Nerd Ranch Guide. Addison-Wesley Professional, 2011 http://www.
openisbn.com/price/9780321706287/. – ISBN 9780321706287
[Ame12] AMELING, Dr. M.: Motivationsschub - Geschäftsanwendungen durch Spielele-
mente verbessern. In: iX - Magazin fuer Informationstechnik 09 (2012), August,
S. 104
[App12a] APPLE: Apple Core Location Guide. Website, 2012. – http:
//developer.apple.com/library/ios/#DOCUMENTATION/
UserExperience/Conceptual/LocationAwarenessPG/
CoreLocation/CoreLocation.html
[App12b] APPLE: Apple Push Notification Service. Website, 2012. – http:
//developer.apple.com/library/mac/#documentation/
NetworkingInternet/Conceptual/RemoteNotificationsPG/
ApplePushService/ApplePushService.html
[App12c] APPLE: Messaging. Website, 2012. – https://developer.apple.
com/library/mac/#documentation/Cocoa/Conceptual/
ObjCRuntimeGuide/Articles/ocrtHowMessagingWorks.html
[App12d] APPLE: Objective-C Delegation. Website, 2012. – https://developer.
apple.com/library/mac/#documentation/General/
Conceptual/DevPedia-CocoaCore/Delegation.html
[Azt97a] Aztec Code - Example. Website, 1997. – http://www.waveform.ie/
_fileUpload/Image/Aztec_Code.JPG
XVIII
Quellenverzeichnis
[Azt97b] Aztec Code - United States Patent US5591956. Website, 1997. – http://
www.freepatentsonline.com/5591956.pdf
[BDMM10a] BROMBACH, Guido ; DEMUTH, Ute ; MUUSS-MERHOLZ, Jöran: Kollaborati-
ves Schreiben I: Überblick. Website, November 2010. – http://pb21.de/
2010/11/kollaboratives-schreiben-i-uberblick/
[BDMM10b] BROMBACH, Guido ; DEMUTH, Ute ; MUUSS-MERHOLZ, Jöran: Kollaborati-
ves Schreiben II: Etherpad. Website, November 2010. – http://pb21.de/
2010/11/kollaboratives-schreiben-ii-etherpad/
[Bec99] BECK, Kent: Extreme Programming Explained – EMBRACE CHANGE.
Addison-Wesley, 1999
[bit12a] Smartphone-Funktionen: Internet wichtiger als Telefonieren. Website, 2012. –
http://www.bitkom.org/de/presse/8477_72686.aspx
[bit12b] Social Media in deutschen Unternehmen. Website, 2012. – http://www.
bitkom.org/de/themen/36444_72124.aspx
[Bun12] BUNDESPRÜFSTELLE: Faszination Onlinespiel: Virtuelle Welten als sozia-
le Räume. Website, 2012. – http://www.bundespruefstelle.
de/bpjm/Jugendmedienschutz-Medienerziehung/
computer-konsolenspiele,did=166746,render=
renderPrint.html
[CCG+07] CANFORA, Gerardo ; CIMITILE, Aniello ; GARCIA, Felix ; PIATTINI, Mario ;
VISAGGIO, Corrado A.: Evaluating performances of pair designing in industry.
In: Journal of Systems and Software (2007)
[CHH10] COHN, M. ; HESSE-HUJBER, M.: User Stories; PR:. mitp-Verlag, 2010
http://books.google.de/books?id=tkVSCmAu2RIC. – ISBN
9783826658983
[Coh04] COHN, Mike: User Stories Applied: For Agile Software Development. Redwood
City, CA, USA : Addison Wesley Longman Publishing Co., Inc., 2004. – ISBN
0321205685
[Col09] Etherpad – das Klasse(n)-Notizbuch. Website, 2009. –
http://lernenheute.wordpress.com/2009/03/17/
etherpad-das-klassen-notizbuch/
[Coma] COMMUNITY, Dropbox: How do I recover old versions of files? Website, . –
https://www.dropbox.com/help/11/en
[Comb] COMMUNITY, Dropbox: What is Packrat? Website, . – https://www.
dropbox.com/help/113/en
XIX
Quellenverzeichnis
[Comc] COMMUNITY, GlassFish: Glassfish. Website, . – http://glassfish.
java.net/
[Com12a] COMMUNITY, Jersey: Jesery Framework. Website, 2012. – http://
jersey.java.net/
[Com12b] COMMUNITY, Restkit: iOS REST-Binding Framework. Website, 2012. – http:
//restkit.org
[Com12c] COMPUTERWOCHE: Freiberufler-Studie 2011. Website, 2012. – http://
www.computerwoche.de/karriere/freiberufler/2499858/
[CW00] COCKBURN, Alistair ; WILLIAMS, Laurie: The Costs and Benefits of Pair Pro-
gramming. Website, 2000. – http://collaboration.csc.ncsu.edu/
laurie/Papers/XPSardinia.PDF
[Eck09] ECKSTEIN, J.: Agile Softwareentwicklung mit verteilten Teams.
Dpunkt.Verlag GmbH, 2009 http://books.google.de/books?
id=fWy1PwAACAAJ. – ISBN 9783898646307
[ecl12] Eclipse Link Home. Website, 2012. – http://www.eclipse.org/
eclipselink/
[Eco01] ECONOMIST, The: Agility counts. Website, 2001. – http://www.
economist.com/node/779429?Story_ID=779429
[Ese07] ESENGULOV, Aibek: 7 easy Screen-Sharing and Remote-Access
Tools. Website, 2007. – http://www.makeuseof.com/tag/
7-easy-screen-sharing-and-remote-access-tools-all-free/
[et.12] ET.AL., Kent B.: Agiles Manifest. Website, 2012. – http://
agilemanifesto.org/
[Fie99a] FIELDING, R.: Hypertext Transfer Protocol – HTTP/1.1. RFC, 1999. – http:
//www.w3.org/Protocols/rfc2616/rfc2616.html
[Fie99b] FIELDING, R.: Hypertext Transfer Protocol – HTTP/1.1 - Status Co-
des. RFC, 1999. – http://www.w3.org/Protocols/rfc2616/
rfc2616-sec10.html#sec10.2
[Fie00] FIELDING, Roy T.: Architectural styles and the design of network-based
software architectures, Diss., 2000. – http://www.ics.uci.edu/
~fielding/pubs/dissertation/top.htm
[Flo06] FLOR, Nick V.: Globally distributed software development and pair program-
ming. In: Communications of the ACM (2006)
[Fou] Foursquare. Website, . – http://www.social-media-wiki.com/
Foursquare.html
XX
Quellenverzeichnis
[Fou12a] FOUNDATION, Apache S.: Apache Maven. Website, 2012. – http://maven.
apache.org/
[Fou12b] FOUNDATION, Etherpad: Collaborate on documents in really real-time. Websi-
te, 2012. – http://etherpad.org/
[Fou12c] FOUNDATION, Etherpad: Features. Website, 2012. – http://etherpad.
org/features/
[GLS10] GROGG, Nadja ; LUBER, Sarah ; SCHREINER, Annina: Vor- und Nachteile eines
Wikis. Website, 2010. – http://www.learning-in-activity.com/
index.php?title=Vor-_und_Nachteile_eines_Wikis
[Gre] GRENNING, James: Planning Poker or How to avoid analysis paralysis while
release planning.
[Gro99] GROUP, Network W.: HTTP Extensions for Distributed Authoring – WEBDAV.
Website, 1999. – http://tools.ietf.org/html/rfc2518
[Gro02] GROUP, Network W.: SIP: Session Initiation Protocol. Website, Juni 2002. –
http://tools.ietf.org/html/rfc3261
[Gro06] GROUP, Network W.: The application/json Media Type for JavaScript Object
Notation (JSON). Website, 2006. – http://tools.ietf.org/html/
rfc4627
[Gro09] GROUP, Network W.: Extended MKCOL for Web Distributed Authoring and
Versioning (WebDAV). Website, 2009. – http://tools.ietf.org/
html/rfc5689
[Gro12a] GROUP, Apache: Maven-LifeCycle. Website, 2012. –
http://maven.apache.org/guides/introduction/
introduction-to-the-lifecycle.html
[Gro12b] GROUP, Atlassian: Homepage - Atlassian. Website, 2012. – http://www.
atlassian.com/de/
[Gro12c] GROUP, Atlassian: Release Notes Confluence 4.2 - Atlassian. Website, 2012.
– https://confluence.atlassian.com/display/DOC/Likes+
and+Popular+Content
[Gro12d] GROUP, Atlassian: Release Notes Confluence 4.2 - Atlassian. Website, 2012.
– https://confluence.atlassian.com/display/DOC/Likes+
and+Popular+Content
[Hab12] HABICHT, Sören: Softwaretest. ISTQB, 2012
[Han12] HANSON, Robbie: XMPPFramework. Website, 2012. – https://github.
com/robbiehanson/XMPPFramework
XXI
Quellenverzeichnis
[Hei08] HEILWAGEN, Andreas: Die wichtigsten Vor- und Nachteile von Wikis.
Website, 2008. – http://www.computerwoche.de/management/
it-strategie/1881240/
[Hei12] HEINRICH, Wolfgang: Microblogging für Unternehmen. Websi-
te, 2012. – http://www.medienkompakt.de/index.php/
microblogging-fur-unternehmen/
[HF10] HUMBLE, J. ; FARLEY, D.: Continuous Delivery: Reliable Software Releases
Through Build, Test, and Deployment Automation. Addison-Wesley, 2010 (The
Addison-Wesley Signature Series). http://books.google.de/books?
id=6ADDuzere-YC. – ISBN 9780321601919
[HJK+00] HERCZEG, M. ; JANFELD, B. ; KLEINEN, B. ; KRITZENBERGER, H. ; PAUL,
M. Wittstock H.: Virtuelle Teams – Erkenntnisse Über die Nutzung von Vi-
deo Conferencing und Application Sharing bei der Unterstützung virtueller
Teams / IATGE. Version: 2000. http://www.iatge.de/aktuell/
veroeff/ps/paul00a.pdf. 2000. – Forschungsbericht. – Web:
http://www.iatge.de/aktuell/veroeff/ps/paul00a.pdf
[Hor08] HORNSTEIN, Martin: E-Collaboration Mehrwerte durch moderne Kommu-
nikationsmittel schaffen. PDF, 2008. – http://www.namics.com/
fileadmin/user_upload/pdf/Wissen/2008/Fachartikel/
E-Collaboration.pdf
[HW11] HENNING WOLF, Arne R.: Agile Softwareentwicklung, Ein Überblick.
Dpunkt.Verlag GmbH, 2011 (IT-agile)
[Inc12] INC, Diigo: Diigo API. Website, 2012. – http://www.diigo.com/
tools/api
[inv03] INVEST in Good Stories, and SMART Tasks. Web-
site, 2003. – http://xp123.com/articles/
invest-in-good-stories-and-smart-tasks/
[ios12a] iOS Human Interface Guidelines. Website, 2012. – http://developer.
apple.com/library/ios/#DOCUMENTATION/UserExperience/
Conceptual/MobileHIG/Introduction/Introduction.html
[ios12b] iOS Notification Center. Website, 2012. – https://developer.apple.
com/library/mac/#documentation/Cocoa/Conceptual/
Notifications/Introduction/introNotifications.html
[ITW12] ITWISSEN: LBS (location based service). Website, 2012.
– http://www.itwissen.info/definition/lexikon/
location-based-service-LBS-Ortsbezogener-Dienst.html
XXII
Quellenverzeichnis
[Jso] Introducing JSON. Website, . – http://www.json.org/
[Kel06] KELLY, Sean: Speeding Up AJAX with JSON. Website, 2006.
– http://www.developer.com/lang/jscript/article.php/
3596836/Speeding-Up-AJAX-with-JSON.htm
[Koe09] KOEPPEL, Petra: Virtuelle Teams: Die Rolle der Fuehrung. In: Interkulturelle
Personal- und Organisationsentwicklung (2009,)
[Kol10] KOLLER, D.: IPhone-Apps entwickeln: Applikationen für iPhone, iPad und iPod
touch programmieren: Von der Idee zum App Store; So realisieren und vermark-
ten Sie Ihre Apps! Franzis, 2010 (Professional Series). http://books.
google.de/books?id=RX6jcQAACAAJ. – ISBN 9783645600811
[Krz08] KRZYWDA, Andrzej: Remote pair programming. Website, 2008.
– http://andrzejonsoftware.blogspot.de/2008/02/
remote-pair-programming.html
[Kö06] KÖPPEL, Petra: Konflikte und Synergien in multikulturellen Teams: Virtuelle und
face-to-face-Kooperation. Gabler, 2006. – ISBN 3835008730
[Mag11] MAGENHEIMER, Christian: Untersuchung von Kommunikationsprotokollen
fuer Dienstumgebungen in mobilen Anwendungen auf Basis von Android. Web-
site, 2011. – http://www.rn.inf.tu-dresden.de/uploads/
Studentische_Arbeiten/Diplomarbeit_Magenheimer_
Christian.pdf
[Mik] MIKOGO: Desktop Sharing. Website, . – http://www.mikogo.de/
[Mil08] MILLER, Claire C.: Will Microblogging at Work Make You
More Productive? In: The New York Times (2008), Oktober.
– http://bits.blogs.nytimes.com/2008/10/21/
will-microblogging-at-work-make-you-more-productive/
?partner=rssnyt&emc=rss&src=ig
[ML08] MAASS, Christian ; LEWANDOWSKI, Dirk: Social Bookmarking and
Tagging in der Praxis. Website, 2008. – http://www.google.
de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=
0CEwQFjAA&url=http%3A%2F%2Fwww.bui.haw-hamburg.
de%2Ffileadmin%2Fuser_upload%2Flewandowski%
2Fdoc%2FSocialBookmarkingundTagginginderPraxis.
pdf&ei=RJszUPfzNI7tsgaZ_IDoBA&usg=
AFQjCNHbbq3530K-cN8fS6mWs25tfXr9OQ
[Mob06] Instant Messenger. Website, April 2006. – http://wellman.
uni-trier.de/index.php?title=Instant_Messenger
XXIII
Quellenverzeichnis
[Mob12] Instant Messaging. Website, 2012. – http://de.wikipedia.org/
wiki/Instant_Messaging
[Mor] MORGENPOST, Hamburger: Foursquare und Co.: Schnitzeljagd
im Internet. Website, . – http://www.mopo.de/news/
standortbezogene-netzwerke-foursquare---co---schnitzeljagd-im-internet,
5066732,5151994.html
[MS04] MYERS, Glenford J. ; SANDLER, Corey: The Art of Software Testing. John
Wiley & Sons, 2004. – ISBN 0471469122
[MS07] MICHAELIS, Samuel ; SCHIESIG, Wolfgang: JAXB 2.0. Hanser Verlag, 2007. –
ISBN 9783446407534
[MW08] MÜLLER, Bernd ; WHER, Harald: Java-Persistence-API mit Hibernate.
Addison-Wesley, 2008. – ISBN 9783827325372
[Mye99] MYERS, Glenford J. ; PIEPER, Manfred (Hrsg.): Methodisches Tes-
ten von Programmen. 6. Aufl., unveränd. Nachdr. der 3. Aufl.
München [u.a.] : Oldenbourg, 1999 (Reihe Datenverarbeitung).
http://gso.gbv.de/DB=2.1/CMD?ACT=SRCHA&SRT=YOP&IKT=
1016&TRM=ppn+254611036&sourceid=fbw_bibsonomy. – ISBN
3486250566
[MZ09] MITCHELL, Alanah ; ZIGURS, Ilze: Trust in virtual teams: solved or still a mys-
tery? In: SIGMIS Database 40 (2009), Juli, Nr. 3, 61–83. http://dx.doi.
org/10.1145/1592401.1592407. – DOI 10.1145/1592401.1592407. –
ISSN 0095–0033
[OP] ONLINEMARKETING-PRAXIS: Definition Instant Messaging. Websi-
te, . – http://www.onlinemarketing-praxis.de/glossar/
instant-messaging
[osm12] OSMORPHIS: Enhancing the standard NSXMLParser class. Web-
site, 2012. – http://osmorphis.blogspot.de/2009/03/
enhancing-standard-nsxmlparser-class.html
[P.12] P., Maxime: Java Push Library. Website, 2012. – http://code.google.
com/p/javapns/
[Pic07] PICHLER, R.: Scrum- Agiles Projektmanagement erfolgreich einset-
zen. Dpunkt-Verlag, 2007 http://books.google.de/books?id=
KhoxPQAACAAJ. – ISBN 9783898644785
[pir12] Piraten-Pad. Website, 2012. – http://www.piratenpad.de/
XXIV
Quellenverzeichnis
[PRI11] PRIVATLEBEN, ALLTAGSFORSCHUNG.DE PSYCHOLOGIE
IN BERUF U.: gemeinsames-ziel-die-macht-sozialer-bindungen.
Website, 2011. – http://www.alltagsforschung.de/
gemeinsames-ziel-die-macht-sozialer-bindungen/
[Prz05] PRZEPIORKA, Sven: Weblogs und Wikis. Website, 2005. – http://tzwaen.
com/publikationen/vortrag-ueber-weblogs-wikis/
folien.html
[Rad10] RADOFF, Jon: FarmVille invades the real world Real world compa-
nies invest in the ‘gamification’ of life. Website, 2010. – http:
//www.msnbc.msn.com/id/37451547/ns/technology_and_
science-tech_and_gadgets/
[Rad12] RADOFF, Jon: History of Social Games. Website, 2012. – http://radoff.
com/blog/2010/05/24/history-social-games/
[Red12] It´s Game-on for Business. Website, 2012. – http://www.redcritter.
com/
[RK07] RICHTER, Michael ; KOCH, Alexander: Enterprise 2.0: Planung, Einführung
und erfolgreicher Einsatz von Social Software in Unternehmen. Olden-
bourg, 2007 http://www.amazon.de/Enterprise-2-0-Einf%
C3%BChrung-erfolgreicher-Unternehmen/dp/3486585789%
3FSubscriptionId%3D192BW6DQ43CK9FN0ZGG2%26tag%3Dws%
26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%
26creativeASIN%3D3486585789. – ISBN 3486585789
[Rou09] ROUSE, Margaret: Microblogging. Website, 2009. – http:
//searchmobilecomputing.techtarget.com/definition/
microblogging
[Sad12] SADUN, Erica: The IOS 5 Developer’s Cookbook: Core Concepts And Es-
sential Recipes For IOS. Addison-Wesley Professional, 2012 http://www.
openisbn.com/isbn/9780321832078/. – ISBN 9780321832078
[SAST09] SAINT-ANDRÉ, P. ; SMITH, K. ; TRONÇON, R.: XMPP: The Definitive Guide
: Building Real-time Applications with Jabber Technologies. O’Reilly Media,
2009 (Definitive Guide Series). http://books.google.de/books?id=
SG3jayrd41cC. – ISBN 9780596521264
[Sen01] SENST, Erik: Virtuelle Teamarbeit. (2001)
[Sim12] SIMPERIUM: Simplenote. Website, 2012. – http://simplenoteapp.
com/
XXV
Quellenverzeichnis
[SK86] SPROULL, L ; KIESLER, S: Reducing social context cues: electronic mail in
organizational communication. In: Manage. Sci. 32 (1986), November, Nr.
11, 1492–1512. http://dx.doi.org/10.1287/mnsc.32.11.1492.
– DOI 10.1287/mnsc.32.11.1492. – ISSN 0025–1909
[Sma12] SMALLTREE: Shared Storage. Website, 2012. – http://www.
small-tree.com/shared_storage_a/212.htm
[Soca] 5 Minute Guide ... Social Bookmarking. Website, . – http:
//www.thealbertalibrary.ab.ca/pdfs/5%20Minute%
20Guide-social%20bookmarking.pdf
[Socb] 7 Things You Should Know about... Social Bookmarking. In: Educause http:
//www.educause.edu/ir/library/pdf/ELI7001.pdf
[Spi11] SPILLER, M.: Maven 3: Konfigurationsmanagement mit Java. mitp/b-
hv, 2011 (mitp Professional). http://books.google.de/books?id=
FcwLPQ4eE1MC. – ISBN 9783826691188
[sro12] SROWEN: ZXing (Zebra Crossing). Website, 2012. – http://code.
google.com/p/zxing/
[sta12] Webseite Stackoverflow. Website, 2012. – http://stackoverflow.com/
[Tea09] TEAM, Technical J.: Singletons : Is Anti-Pattern? Website, 2009.
– http://thetechcandy.wordpress.com/2009/12/02/
singletons-is-anti-pattern/
[Tea12] TEAM, Diigo: Diigo API Referenz. Website, 2012. – http://www.diigo.
com/tools/api
[Thi05] THIMM, Caja: Virtuelle Teams - Kommunikation in virtuellen Führungs-
situationen. http://www.ikp.uni-bonn.de/ZfKM/dgpuk/DGPuK_
Vortrag_Thimm.pdf. Version: 2005
[Til11] TILKOV, S.: REST und HTTP: Einsatz der Architektur des Web für Integrati-
onsszenarien. Dpunkt.Verlag GmbH, 2011 http://books.google.de/
books?id=QIHUjwEACAAJ. – ISBN 9783898647328
[Tri12] TRIS, Hussley: Create your own Blog. SAMS, 2012
[Val11] VALDERRAMA, Jennifer: Twitters confusing inerface. Website, 2011.
– http://litteramedia.wordpress.com/2011/11/26/
twitters-confusing-interface/
[Ver12] VERIVOX: Standortbezogene Dienste werden immer beliebter. Web-
site, April 2012. – http://www.verivox.de/nachrichten/
XXVI
Quellenverzeichnis
standortbezogene-dienste-werden-immer-beliebter-86152.
aspx
[W3C03] W3C: Extensible Markup Language (XML). Website, 2003. – http://www.
w3.org/XML/
[W3C08] W3C: Extensible Markup Language (XML) 1.0 (Fifth Edition). Website, No-
vember 2008. – http://www.w3.org/TR/xml/
[Wal12] WALTON, Geoffrey L.; Cwir David; Spencer Steven J. Gregory M.; Cohen C.
Gregory M.; Cohen: Mere belonging: The power of social connections. In:
Journal of Personality and Social Psychology, (2012)
[Wel12] WELLS, Don: Extreme Programming: A gentle introduction. Website, 2012. –
http://www.extremeprogramming.org/rules/pair.html
[Wie10] WIEST, S.: Continuous Integration mit Hudson: Grundlagen und Praxiswissen
für Einsteiger und Umsteiger. Dpunkt.Verlag GmbH, 2010 http://books.
google.de/books?id=Kd1_RAAACAAJ. – ISBN 9783898646901
[Wik07] MediaWiki. Website, 2007. – http://www.mediawiki.org/wiki/
MediaWiki/de
[Wil01] WILLIAMS, Laurie: Integrationg Pair Programming into a Software Develop-
ment Process. Website, 2001. – http://collaboration.csc.ncsu.
edu/laurie/Papers/Integrating.pdf
[Win11] WINTER, M.: Scan Me - Everybody’s Guide to the Magical World of Qr
Codes. Westsong Publishing, 2011 http://books.google.de/books?
id=s5ZxqwwYKk8C. – ISBN 9780965900034
[WK03] WILLIAMS, L. ; KESSLER, R.R.: Pair Programming Illuminated.
Addison-Wesley, 2003 http://books.google.de/books?id=
LRQhdlrKNE8C. – ISBN 9780201745764
[ZR09] ZHAO, Dejin ; ROSSON, Mary B.: How and why people Twitter: the role
that micro-blogging plays in informal communication at work. New York,
NY, USA : ACM, 2009 (GROUP ’09). – 243–252 S. http://dx.
doi.org/10.1145/1531674.1531710. http://dx.doi.org/10.
1145/1531674.1531710. – ISBN 978–1–60558–500–0
XXVII
Quellenverzeichnis
A. Anhang Abbildungen
Abbildung A.1.: Aztec-Code (Quelle: [Azt97a])
Abbildung A.2.: Überprüfung der Anforderungen mittels Tests (Quelle: [HW11], Seite 5)
XXVIII
Quellenverzeichnis
Abbildung A.3.: Openfire Webadmin (Quelle: Eigene Darstellung)
XXIX
Quellenverzeichnis
Abbildung A.4.: Architektur JAXB 2.0 (Quelle: [MS07], Seite 6.)
Abbildung A.5.: JAXB 2.0 Schema-Compiler (Quelle: [MS07], Seite 8.)
XXX
Quellenverzeichnis
Abbildung A.6.: Übersicht Server-Applikation (Quelle: Eigene Darstellung)
Abbildung A.7.: Übersicht Startseite Etherpad (Quelle: Eigene Darstellung)
XXXI
Quellenverzeichnis
Abbildung A.8.: JAXB 2.0 Schema-Generator (Quelle: [MS07], Seite 10.)
Abbildung A.9.: Etherpad Weboberfläche (Quelle: Eigene Darstellung)
XXXII
Quellenverzeichnis
Abbildung A.10.: Lebenszyklus einer iOS Applikation (Quelle: [Kol10], Seite 41)
XXXIII
QuellenverzeichnisAbbildung A.11.: Deployment Server (Quelle: Eigene Darstellung)
XX
XIV
Quellenverzeichnis
Abbildung A.12.: Deployment iPhone (Quelle: Eigene Darstellung)
XX
XV
Quellenverzeichnis
Abbildung A.13.: Use Cases (Quelle: Eigene Darstellung)
XX
XV
I
Quellenverzeichnis
Abbildung A.14.: Klassendiagramm Services (Quelle: Eigene Darstellung)
XX
XV
II
Quellenverzeichnis
Abbildung A.15.: Diigo Toolbar (Quelle: Eigene Darstellung)
XX
XV
III
Quellenverzeichnis
Abbildung A.16.: Jenkins Weboberfläche (Quelle: Eigene Darstellung)
XX
XIX
Quellenverzeichnis
Abbildung A.17.: Wiki Weboberfläche (Quelle: Eigene Darstellung)
XL
Quellenverzeichnis
B. Anhang Quellcode
Listing B.1: pom.xml des Projektes instantscrum-web (komplett)1 <project>2 <artifactId>instantscrum-web</artifactId>3 <packaging>war</packaging>4 <name>instantscrum-web</name>5 <build>6 <resources>7 <resource>8 <directory>src/main/java/META-INF</directory>9 <includes>
10 <include>*.xml</include>11 <include>**.xml</include>12 </includes>13 <filtering>true</filtering>14 </resource>15 <resource>16 <directory>src/main/resources/</directory>17 <filtering>true</filtering>18 </resource>19 </resources>20 <plugins>21 <plugin>22 <groupId>org.apache.maven.plugins</groupId>23 <artifactId>maven-surefire-plugin</artifactId>24 <configuration>25 <skipTests>true</skipTests>26 <excludes>27 <exclude>**/*ITSuite.java</exclude>28 </excludes>29 </configuration>30 </plugin>31 <plugin>32 <groupId>org.codehaus.cargo</groupId>33 <artifactId>cargo-maven2-plugin</artifactId>34 <configuration>35 <deployer>36 <deployables>37 <deployable>38 <groupId>de.crossbeanmedia.instantscrum</
groupId>39 <artifactId>instantscrum-web</artifactId>40 <type>war</type>41 </deployable>42 </deployables>43 </deployer>44 </configuration>
XLI
Quellenverzeichnis
45 <executions>46 <execution>47 <id>start-container</id>48 <phase>pre-integration-test</phase>49 <goals>50 <goal>start</goal>51 <goal>deploy</goal>52 </goals>53 </execution>54 <execution>55 <id>stop-container</id>56 <phase>post-integration-test</phase>57 <goals>58 <goal>stop</goal>59 </goals>60 </execution>61 </executions>62 </plugin>63 <plugin>64 <groupId>org.apache.maven.plugins</groupId>65 <artifactId>maven-failsafe-plugin</artifactId>66 <configuration>67 <includes>68 <include>**/*ITSuite.java</include>69 </includes>70 </configuration>71 <executions>72 <execution>73 <id>integration-test</id>74 <phase>integration-test</phase>75 <goals>76 <goal>integration-test</goal>77 </goals>78 </execution>79 <execution>80 <id>verify</id>81 <goals>82 <goal>verify</goal>83 </goals>84 </execution>85 </executions>86 </plugin>87 </plugins>88 <finalName>instantscrum-web</finalName>89 </build>90 </project>
XLII
Eidesstattliche Erklärung
Ich versichere an Eides Statt durch meine eigenhändige Unterschrift, dass ich die vorliegende
Arbeit selbstständig und ohne fremde Hilfe angefertigt habe. Alle Stellen, die wörtlich oder
dem Sinn nach auf Publikationen oder Vorträgen anderer Autoren beruhen, sind als solche
kenntlich gemacht. Ich versichere außerdem, dass ich keine andere als die angegebene Lite-
ratur verwendet habe. Diese Versicherung bezieht sich auch auf alle in der Arbeit enthaltenen
Zeichnungen, Skizzen, bildlichen Darstellungen und dergleichen.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht veröf-
fentlicht.
Schwallungen,den 13. Oktober 2012
Ort, Datum Christopher Ezell
Fambach,den 13. Oktober 2012
Ort, Datum Rene Kassel
XLIII