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


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


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


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


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


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


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


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)


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


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


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.


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


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)


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


• 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.


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.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


• 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


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


• 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


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.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


• 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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.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.


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


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


• 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.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


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


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)


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


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


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


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


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


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


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


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])


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


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


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


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


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.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.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;


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


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


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)


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


• 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


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.


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.


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.


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.



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.



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.


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.


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.


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.



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.


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.


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)


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.


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.



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.


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.


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.


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.


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.


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.



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.


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.



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.


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.


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.


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.


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.



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.



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.


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.


Tag-Ansicht.

When: Wenn der User dort einen bestimmten Tag anklickt,

Then: dann werden ihm alle dem Tag untergliederten Lesezeichen angezeigt.


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.



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.


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.


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)


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


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.


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


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


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

https://simple-note.appspot.com/api2

https://simple-note.appspot.com/api2


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


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)


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


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


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


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


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


• 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


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


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)


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.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.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


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


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


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


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


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


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


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


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


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


• 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


• 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.


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


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


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


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


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.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


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


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


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.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)


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.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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

http://cargo.codehaus.org/Maven2+plugin


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>


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.


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


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.


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


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.


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


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.


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


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.


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


Abbildung 7.21.: Screenshot über die Änderung einer Notiz (Quelle: Eigene Darstellung)

Abbildung 7.22.: Screenshot Bookmarks sortiert nach Tags (Quelle: Eigene Darstellung)

170


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)


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.


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


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

http://www.agilemodeling.com/essays/proof.htm

http://www.alexa.com/siteinfo/stackoverflow.com

http://www.alexa.com/siteinfo/stackoverflow.com

http://www.alexa.com/

http://www.alexa.com/

http://www.openisbn.com/price/9780321706287/

http://www.openisbn.com/price/9780321706287/

http://developer.apple.com/library/ios/#DOCUMENTATION/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html




http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html




https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtHowMessagingWorks.html



https://developer.apple.com/library/mac/#documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html



http://www.waveform.ie/_fileUpload/Image/Aztec_Code.JPG

http://www.waveform.ie/_fileUpload/Image/Aztec_Code.JPG

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

http://www.freepatentsonline.com/5591956.pdf

http://www.freepatentsonline.com/5591956.pdf

http://pb21.de/2010/11/kollaboratives-schreiben-i-uberblick/

http://pb21.de/2010/11/kollaboratives-schreiben-i-uberblick/

http://pb21.de/2010/11/kollaboratives-schreiben-ii-etherpad/

http://pb21.de/2010/11/kollaboratives-schreiben-ii-etherpad/

http://www.bitkom.org/de/presse/8477_72686.aspx

http://www.bitkom.org/de/themen/36444_72124.aspx

http://www.bitkom.org/de/themen/36444_72124.aspx

http://www.bundespruefstelle.de/bpjm/Jugendmedienschutz-Medienerziehung/computer-konsolenspiele,did=166746,render=renderPrint.html




http://books.google.de/books?id=tkVSCmAu2RIC

http://lernenheute.wordpress.com/2009/03/17/etherpad-das-klassen-notizbuch/

http://lernenheute.wordpress.com/2009/03/17/etherpad-das-klassen-notizbuch/




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

http://glassfish.java.net/

http://glassfish.java.net/

http://jersey.java.net/

http://jersey.java.net/

http://restkit.org

http://restkit.org

http://www.computerwoche.de/karriere/freiberufler/2499858/

http://www.computerwoche.de/karriere/freiberufler/2499858/

http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

http://books.google.de/books?id=fWy1PwAACAAJ

http://books.google.de/books?id=fWy1PwAACAAJ

http://www.eclipse.org/eclipselink/

http://www.eclipse.org/eclipselink/

http://www.economist.com/node/779429?Story_ID=779429

http://www.economist.com/node/779429?Story_ID=779429

http://www.makeuseof.com/tag/7-easy-screen-sharing-and-remote-access-tools-all-free/

http://www.makeuseof.com/tag/7-easy-screen-sharing-and-remote-access-tools-all-free/

http://agilemanifesto.org/

http://agilemanifesto.org/

http://www.w3.org/Protocols/rfc2616/rfc2616.html

http://www.w3.org/Protocols/rfc2616/rfc2616.html

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

http://www.social-media-wiki.com/Foursquare.html

http://www.social-media-wiki.com/Foursquare.html

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

http://maven.apache.org/

http://maven.apache.org/

http://etherpad.org/

http://etherpad.org/features/

http://etherpad.org/features/

http://www.learning-in-activity.com/index.php?title=Vor-_und_Nachteile_eines_Wikis

http://www.learning-in-activity.com/index.php?title=Vor-_und_Nachteile_eines_Wikis







http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

http://www.atlassian.com/de/

http://www.atlassian.com/de/

https://confluence.atlassian.com/display/DOC/Likes+and+Popular+Content




https://github.com/robbiehanson/XMPPFramework

https://github.com/robbiehanson/XMPPFramework

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

http://www.computerwoche.de/management/it-strategie/1881240/

http://www.computerwoche.de/management/it-strategie/1881240/

http://www.medienkompakt.de/index.php/microblogging-fur-unternehmen/

http://www.medienkompakt.de/index.php/microblogging-fur-unternehmen/

http://books.google.de/books?id=6ADDuzere-YC

http://books.google.de/books?id=6ADDuzere-YC



http://www.namics.com/fileadmin/user_upload/pdf/Wissen/2008/Fachartikel/E-Collaboration.pdf



http://www.diigo.com/tools/api


http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

http://developer.apple.com/library/ios/#DOCUMENTATION/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html



https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Notifications/Introduction/introNotifications.html



http://www.itwissen.info/definition/lexikon/location-based-service-LBS-Ortsbezogener-Dienst.html

http://www.itwissen.info/definition/lexikon/location-based-service-LBS-Ortsbezogener-Dienst.html

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

http://www.json.org/

http://www.developer.com/lang/jscript/article.php/3596836/Speeding-Up-AJAX-with-JSON.htm

http://www.developer.com/lang/jscript/article.php/3596836/Speeding-Up-AJAX-with-JSON.htm

http://books.google.de/books?id=RX6jcQAACAAJ

http://books.google.de/books?id=RX6jcQAACAAJ

http://andrzejonsoftware.blogspot.de/2008/02/remote-pair-programming.html

http://andrzejonsoftware.blogspot.de/2008/02/remote-pair-programming.html

http://www.rn.inf.tu-dresden.de/uploads/Studentische_Arbeiten/Diplomarbeit_Magenheimer_Christian.pdf



http://www.mikogo.de/

http://bits.blogs.nytimes.com/2008/10/21/will-microblogging-at-work-make-you-more-productive/?partner=rssnyt&emc=rss&src=ig



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







http://wellman.uni-trier.de/index.php?title=Instant_Messenger

http://wellman.uni-trier.de/index.php?title=Instant_Messenger

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

http://de.wikipedia.org/wiki/Instant_Messaging

http://de.wikipedia.org/wiki/Instant_Messaging

http://www.mopo.de/news/standortbezogene-netzwerke-foursquare---co---schnitzeljagd-im-internet,5066732,5151994.html



http://gso.gbv.de/DB=2.1/CMD?ACT=SRCHA&SRT=YOP&IKT=1016&TRM=ppn+254611036&sourceid=fbw_bibsonomy

http://gso.gbv.de/DB=2.1/CMD?ACT=SRCHA&SRT=YOP&IKT=1016&TRM=ppn+254611036&sourceid=fbw_bibsonomy

http://dx.doi.org/10.1145/1592401.1592407

http://dx.doi.org/10.1145/1592401.1592407

http://www.onlinemarketing-praxis.de/glossar/instant-messaging

http://www.onlinemarketing-praxis.de/glossar/instant-messaging

http://osmorphis.blogspot.de/2009/03/enhancing-standard-nsxmlparser-class.html

http://osmorphis.blogspot.de/2009/03/enhancing-standard-nsxmlparser-class.html

http://code.google.com/p/javapns/

http://code.google.com/p/javapns/

http://books.google.de/books?id=KhoxPQAACAAJ

http://books.google.de/books?id=KhoxPQAACAAJ

http://www.piratenpad.de/

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

http://www.alltagsforschung.de/gemeinsames-ziel-die-macht-sozialer-bindungen/

http://www.alltagsforschung.de/gemeinsames-ziel-die-macht-sozialer-bindungen/

http://tzwaen.com/publikationen/vortrag-ueber-weblogs-wikis/folien.html



http://www.msnbc.msn.com/id/37451547/ns/technology_and_science-tech_and_gadgets/



http://radoff.com/blog/2010/05/24/history-social-games/

http://radoff.com/blog/2010/05/24/history-social-games/

http://www.redcritter.com/

http://www.redcritter.com/

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





http://searchmobilecomputing.techtarget.com/definition/microblogging



http://www.openisbn.com/isbn/9780321832078/

http://www.openisbn.com/isbn/9780321832078/

http://books.google.de/books?id=SG3jayrd41cC

http://books.google.de/books?id=SG3jayrd41cC

http://simplenoteapp.com/

http://simplenoteapp.com/

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

http://dx.doi.org/10.1287/mnsc.32.11.1492

http://www.small-tree.com/shared_storage_a/212.htm

http://www.small-tree.com/shared_storage_a/212.htm

http://www.thealbertalibrary.ab.ca/pdfs/5%20Minute%20Guide-social%20bookmarking.pdf



http://www.educause.edu/ir/library/pdf/ELI7001.pdf

http://www.educause.edu/ir/library/pdf/ELI7001.pdf

http://books.google.de/books?id=FcwLPQ4eE1MC

http://books.google.de/books?id=FcwLPQ4eE1MC

http://code.google.com/p/zxing/

http://code.google.com/p/zxing/

http://stackoverflow.com/

http://thetechcandy.wordpress.com/2009/12/02/singletons-is-anti-pattern/

http://thetechcandy.wordpress.com/2009/12/02/singletons-is-anti-pattern/



http://www.ikp.uni-bonn.de/ZfKM/dgpuk/DGPuK_Vortrag_Thimm.pdf

http://www.ikp.uni-bonn.de/ZfKM/dgpuk/DGPuK_Vortrag_Thimm.pdf

http://books.google.de/books?id=QIHUjwEACAAJ

http://books.google.de/books?id=QIHUjwEACAAJ

http://litteramedia.wordpress.com/2011/11/26/twitters-confusing-interface/

http://litteramedia.wordpress.com/2011/11/26/twitters-confusing-interface/

http://www.verivox.de/nachrichten/standortbezogene-dienste-werden-immer-beliebter-86152.aspx


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




http://www.w3.org/XML/

http://www.w3.org/XML/

http://www.w3.org/TR/xml/

http://www.extremeprogramming.org/rules/pair.html

http://books.google.de/books?id=Kd1_RAAACAAJ

http://books.google.de/books?id=Kd1_RAAACAAJ

http://www.mediawiki.org/wiki/MediaWiki/de

http://www.mediawiki.org/wiki/MediaWiki/de

http://collaboration.csc.ncsu.edu/laurie/Papers/Integrating.pdf

http://collaboration.csc.ncsu.edu/laurie/Papers/Integrating.pdf

http://books.google.de/books?id=s5ZxqwwYKk8C

http://books.google.de/books?id=s5ZxqwwYKk8C

http://books.google.de/books?id=LRQhdlrKNE8C

http://books.google.de/books?id=LRQhdlrKNE8C

http://dx.doi.org/10.1145/1531674.1531710

http://dx.doi.org/10.1145/1531674.1531710

http://dx.doi.org/10.1145/1531674.1531710

http://dx.doi.org/10.1145/1531674.1531710

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