Masterarbeit

Analyse, Konzeption und Implementierung einer mobilen Kollaborationsplattform fr verteilte agile Software-Projekte
Zur Erlangung des akademischen Grades eines Master of Science - Media Processing and Interactive Services-

Fakultt Informatik Referent: Prof. Dr. Kurt Englmeier Koreferent: Prof. Dr. Regina Polster eingereicht von: Christopher Ezell Matr.-Nr. 260352 Kreuzstrae 07 98590 Schwallungen Rene Kassel Matr.-Nr. 260208 Mhlweg 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 Vernderungen machen auch bei der Arbeitswelt keinen Halt und bringen stndig neue Innovationen hervor. Immer mehr Firmen nutzen diese neuen Techniken und verschaffen sich, zum Beispiel mit Hilfe von Outsourcing und verteilten Arbeitsmglichkeiten durch gut vernetzte Standorte ber das Internet, Vorteile. Dies bringt aber auch gravierende Vernderungen fr die Angestellten dieser Firmen mit sich. Teams werden zunehmend internationaler ausgestellt und mssen immer grere und komplexere Aufgaben lsen. Dazu wird vermehrt Fachpersonal bentigt, welches immer schwerer an einem zentralen Arbeitsplatz vereint werden kann. Die Folgen daraus sind dezentralere Strukturen innerhalb der Teams. Diese verteilten Teams werden auch virtuelle Teams genannt. Sie arbeiten also nur noch virtuell an einer gemeinsamen Aufgabe und knnen sowohl rumlich als auch zeitlich voneinander getrennt sein. Doch Menschen sind nicht fr solch eine Art der Arbeit geschaffen. Immer wieder entstehen Konikte in verteilten Gruppen durch interkulturelle Unterschiede und soziale Missverstndnisse. Es gibt in den letzten Jahren einige Anstze zum Lsen dieser Probleme. Doch viele zielen nur auf das sehr formelle kommunizieren von Informationen ab und vernachlssigen die soziale Komponente zu stark. Besser wre hier ein sozialer Ansatz, der allen Mitgliedern im Team ein Gefhl der Zusammengehrigkeit verleiht. Dies muss unabhngig von Ort und Zeit des jeweiligen Mitglieds gewhrleistet sein. Anstze, wie bei dem Projekt Flurfunk, zeigen auf, wo die Entwicklung hinfhren kann. Bei Flurfunk werden formelle Informationen aus dem Projektalltag1 und persnliche2 Informationen von den Teammitgliedern3 kombiniert, wodurch ein zentraler Fluss an Informationen bereit gestellt wird. Dieser kann den Mitgliedern helfen, die anderen Mitglieder standortbergreifend 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 Kommunikationsmittel geworden. Durch diesen groen Hype rund um das Thema Smartphones ist es ersichtlich geworden, welches Potential in dieser Technik steckt.

1 Das

knnen Informationen ber Neuigkeiten im Wiki und den Buildstatus sein. kann in Form von kurzen Nachrichten, die jeder absenden kann, erfolgen

2 soziale 3 Dies

II

Es stellt sich also die Frage, ob durch den geschickten Einsatz von Smartphones und einer intelligenten Kommunikationsstrategie verteilte Menschen nher zusammen gebracht werden knnen und sie dadurch auf einer sozialen Ebene wieder besser miteinander kommunizieren knnen. Diese Arbeit versucht einen Ansatz zu nden, wie heutige Kommunikationskanle so verbunden werden knnen, dass diese Lcke in der sozialen Kommunikation berwunden werden kann und so das Teamklima, das gegenseitige Vertrauen und andere wichtige soziale Aspekte wieder mehr in den Vordergrund der Kommunikation geraten. Hierzu werden Kommunikationskanle 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 groer Fokus liegt dabei auf mobilen Endgerten, wie Smartphones. Sie sind immer parat und besitzen so das grte Potential, die zentrale Schnittstelle zur digitalen Auenwelt zu werden. Auch durch die Sensoren in diesen Gerten, wie GPS und Kompass, knnen vllig neue Dienste erschaffen und vorhandene Daten viel effektiver genutzt werden. Es werden hierzu eine Menge aktueller Studien und Bcher zurate gezogen, um dem Leser aktuelle Informationen ber diese Thematik zu vermitteln.

III

Danksagungen
An dieser Stelle mchten wir uns herzlichst bei unseren Eltern sowie bei Franziska Sachs und Sylvana Hofmeister bedanken. Sie haben uns whrend des Studiums und bei der Erstellung dieser Masterarbeit stets untersttzt und auch in schlechten Momenten den Rcken gestrkt. Ebenso einen groen Dank an euch fr die Geduld und das Durchhaltevermgen in einigen Phasen. Ein herzlichster Dank gilt Herrn Prof. Dr. Kurt Englmeier und Frau Prof. Dr. Regina Polster, die uns die Bearbeitung dieses Themas ermglichten und uns stets bei Problemen oder Fragen zur Stelle waren. Ein groes Lob gebhrt Beatrice Florat und Franziska Sachs. Diese haben mit ihrem Ehrgeiz und Engagement die Arbeit durch Korrekturlesungen stark untersttzt. Ebenso sind an dieser Stelle unsere Freunde zu nennen, die einem stets zur Seite standen, auch wenn es mal schlechte Zeiten gab - danke dafr. Zum Schluss geben wir unseren Dank auch an all diese, welche hier nicht namentlich genannt wurden und sich damit angesprochen fhlen.

IV

Inhaltsverzeichnis

Inhaltsverzeichnis
Abkrzungsverzeichnis Abbildungsverzeichnis Listings 1. Einleitung (Autoren: Christopher Ezell und Rene Kassel) 1.1. Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Thesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Voraussetzungen zum Verstndnis der Arbeit . . . . . . . . . . . . . . . . . . 2. Kommunikation und Interaktion in (verteilten) Teams (Autoren: Christopher Ezell und Rene Kassel) 2.1. Begriffsdenition virtuelle Teams(Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . 2.2. Kommunikation und Probleme in virtuellen Teams (Autor: Christopher Ezell) . . . . . . . 2.3. Lsungsanstze (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . . . X XII XV 1 2 3 3 4 5 5 6 9

2.4. Das Potential von mobilen Endgerten in verteilten Teams (Autor: Rene Kassel) . . . . . 11 2.5. Arten von Informationen in Teams (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . 11 2.6. Arten von potentiellen Kommunikationskanlen (Autor: Christopher Ezell) . . . . . . . . . 12 2.7. Gamication (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.8. Die ausgewhlten Kommunikationskanle (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

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

3.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. Notication 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) 75

4.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 kongurieren (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-Gesprch 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: Ofine 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 durchfhren (Autor: Christopher Ezell) . . . . . . 91 4.25. Zusammenfassung (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5. Konzeption (Autoren: Christopher Ezell und Rene Kassel) 93

5.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 Funktionalitten im berblick . . . . . . . . . . . . . . 112 5.5.3.1. 5.5.3.2. 5.5.3.3. 5.5.3.4. 5.5.3.5. 5.5.3.6. 5.5.3.7. 5.5.3.8. 5.5.3.9. Der Chat (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . 112 Tasks (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . 113 Die News (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . 114 Liste der Shared Links (Autor: Rene Kassel) . . . . . . . . . . . . . . 115 Maps (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . . . 116 Verteiltes Planningpoker (Autor: Christopher Ezell) . . . . . . . . . . . . 117 Liste der Notizen (Autor: Christopher Ezell) . . . . . . . . . . . . . . . 119 QR-Code-Scanner (Autor: Rene Kassel) . . . . . . . . . . . . . . . . 119 Buildstatus (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . 120

VII

Inhaltsverzeichnis 5.5.3.10. Das Punktesystem (Autor: Rene Kassel) . . . . . . . . . . . . . . . . 121 5.5.3.11. Liste aller registrierten User (Autor: Rene Kassel) . . . . . . . . . . . 122 5.6. Konzeption Build und Teststrategien (Autor: Christopher Ezell) . . . . . . . . . . . . . . . 123 5.7. Zusammenfassung (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6. Implementierung (Autoren: Christopher Ezell und Rene Kassel) 125

6.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. Kongurations-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-Notications (Autor: Christopher Ezell) . . . . . . . . . . . . . . . . . . . . 150 6.3. Implementierung Build und Continious Integration (Autor: Christopher Ezell) . . . . . . . 151 6.4. Zusammenfassung (Autor: Rene Kassel) . . . . . . . . . . . . . . . . . . . . . . . . . . 155 7. Anwendungsbeispiel (Autoren: Christopher Ezell und Rene Kassel) 156

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

8.1. Abschlussbetrachtungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 8.2. Resumee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 8.3. Erweiterungsmglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Quellenverzeichnis A. Anhang Abbildungen B. Anhang Quellcode Eidesstattliche Erklrung XVIII XXVIII XLI XLIII

IX

Abkrzungsverzeichnis

Abkrzungsverzeichnis
AIM . . . . . . . . . . . . . . . . AOL Instant Messenger Amazon S3 . . . . . . . . . . Amazon Simple Storage Service API . . . . . . . . . . . . . . . . . Application Programming Interface ARPN . . . . . . . . . . . . . . . Apple Remote Push Notication 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 fr Technologie und Innovation KVO . . . . . . . . . . . . . . . . Key Value Observing

Abkrzungsverzeichnis LBS . . . . . . . . . . . . . . . . Location Based Services MVC . . . . . . . . . . . . . . . Model-View-Controller NIB . . . . . . . . . . . . . . . . . Binre 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 Identier URL . . . . . . . . . . . . . . . . Uniform Resource Locator W3C . . . . . . . . . . . . . . . . World Wide Web Consortium Webdav . . . . . . . . . . . . . Web-based Distributed Authoring and Versioning XEP . . . . . . . . . . . . . . . . XMPP Extension Protocol XIB . . . . . . . . . . . . . . . . . XML Interface Builder Datei XML . . . . . . . . . . . . . . . . Extensible Markup Language XMPP . . . . . . . . . . . . . . Extensible Messaging and Presence Protocol XP . . . . . . . . . . . . . . . . . . Extreme Programming

XI

Abbildungsverzeichnis

Abbildungsverzeichnis
2.1. Konikte 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 Sulen 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. berprfung 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 Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.3. Aufbau der Projektplattform (Quelle: Eigene Darstellung) . . . . . . . . . . . . 96 5.4. Genereller Ablauf einer Apple Push-Nachricht (Quelle: [App12b]) . . . . . . . 101 5.5. Aufbau der REST-Services (Quelle: Eigene Darstellung) . . . . . . . . . . . . 103 5.6. Die Verbindung von den Services zu der View (Quelle: Eigene Darstellung) . . 106 5.7. Verwendung des XML-Services im View (Quelle: Eigene Darstellung) . . . . . 107 5.8. Die Verbindung von Services zu den Konnektoren (Quelle: Eigene Darstellung) 109 5.9. bersicht der iOS-Applikations Architektur (Quelle: Eigene Darstellung) . . . 111

XII

Abbildungsverzeichnis 5.10. Mind-Map der InstantScrum iPhone-Applikation (Quelle: Eigene Darstellung) . 113 5.11. Mockup der Chatliste (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . 114 5.12. Mockup eines Chats mit einem anderem User (Quelle: Eigene Darstellung) . . 115 5.13. Mockup der Taskliste (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . 116 5.14. Mockup der Detailansicht eines Tasks (Quelle: Eigene Darstellung) . . . . . . 117 5.15. Mockup der Newsliste (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . 118 5.16. Mockup der Mapfunktionalitt (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 grasche Editor des Settings-Bundle (Quelle: Eigene Darstellung) . . . . . 143 6.5. Die iPhone Oberche 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 Mapfunktionalitt (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 Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 7.16. Screenshot Userliste (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . 166 7.17. Screenshot Userdetail (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . 167 7.18. Screenshot des QR-Code Scans (Quelle: Eigene Darstellung) . . . . . . . . . . 167 7.19. Screenshot einer Push-Benachrichtigung von der instantScrum-App (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

XIII

Abbildungsverzeichnis 7.20. Screenshot der Notizverwaltungsbersicht (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. berprfung der Anforderungen mittels Tests (Quelle: [HW11], Seite 5) . . . . XXVIII A.3. Openre 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 Weboberche (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 Weboberche (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . XXXIX A.17.Wiki Weboberche (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . XL

XIV

Listings

Listings
3.1. Beispiel fr XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2. Beispiel fr JSON (Quelle: [Gro06]) . . . . . . . . . . . . . . . . . . . . . . . 56 3.3. Beispiel fr URLs bei REST . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.4. Beispiel fr 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 fr ein interface in Objective-C . . . . . . . . . . . . . . . . . . . 63 3.9. Die Implementierung der Klasse MyClass . . . . . . . . . . . . . . . . . . . 63 3.10. Beispiel fr 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 fr eine local notication . . . . . . . . . . . . . . . . . . . . . 68 3.18. Die Signatur der Methode zum annehmen der Notication . . . . . . . . . . . 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-Reprsentation 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 Conguration . . . . . . . . . . . . . . . . . . 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 Ofine 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 Notication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Notication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 6.41. Parsen eines Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 6.42. Anfrage auf ein Push Notication Token . . . . . . . . . . . . . . . . . . . . . 150 6.43. Erhalten eines Push Notication Tokens . . . . . . . . . . . . . . . . . . . . . 150 6.44. Empfangen eines Push Notication Errors auf der Clientseite . . . . . . . . . . 150 6.45. Empfangen einer Push Notication 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 fr zunehmend komplexer werdende Aufgaben und Anforderungen immer strker geworden. Softwaresysteme werden nahezu in allen Lebensbereichen eingesetzt. Sie untersttzen dort die Arbeit ungemein und sind kaum noch weg zu denken. Jedoch mssen diese Systeme mit der Zeit gehen und sind stndig steigenden Anforderungen ausgesetzt. Die komplexer werdenden Anwendungen brauchen immer mehr und immer qualiziertere Programmierer, Softwarearchitekten und technische Leiter, welche an einem einzigen Projekt arbeiten. Das aufkommende Problem hierbei ist aber, dass das bentigte Know-how, welches zum Entwickeln und weiterfhren fr solche Softwaresysteme bentigt wird, nicht mehr nur an einem Standort konzentriert werden kann. Zum Teil mssen Teammitglieder von vielen verschiedenen Standorten, Stdten und sogar Lndern rekrutiert werden, um genug Wissen und Arbeitskraft verfgbar zu machen. Meistens ist es jedoch nicht so, dass das ntige Kapital eingesetzt wird, um die Teams an einem Standort zu versammeln. Vielmehr wird davon ausgegangen, dass diese auch verteilt arbeiten knnen. Jedoch existiert in verteilten Teams ein wesentlich hherer Bedarf an Abstimmung und Kommunikation, um dieselben Aufgaben zu lsen, wie bei nicht verteilten Teams. Mit Teammitgliedern zu arbeiten, welche nicht am gleichen Standort ttig 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 bezglich 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 Konikten innerhalb des Teams fhren, wenn Probleme auftreten oder wichtige Entscheidungen getroffen werden mssen. Bei solchen Konstellationen sollte also ein besonderer Fokus darauf liegen, wie durch eine bessere Kommunikation solche Probleme behoben werden knnen. Ein Vorbild kann hier zum Beispiel die Vernderung der Kommunikation im Alltag sein. Die zunehmende Akzeptanz des Internets, eine hhere Verfgbarkeit von breitbandigen, mobilen Datenverbindungen und die immer gnstigeren mobilen Endgerte haben nachhaltig unsere Kommunikation und Interaktion verndert. Es sind neue Dienste wie Microblogging und Location Based Services entstanden. Immer mehr Leute teilen zunehmend mehr Informationen durch solche Dienste mit anderen Menschen. Durch die hohe Verfgbarkeit von Internet ist es

1.1. Ziel der Arbeit mglich geworden, immer und berall erreichbar zu sein und instantan auf Nachrichten reagieren zu knnen. Diese Mentalitt dringt durch jngere Mitarbeiter immer mehr in den Projekten ein und die Toleranz fr solche Dienste am Arbeitsplatz steigt. Warum also nicht diese neuen Mglichkeiten auch in Projekten nutzen, um den Fluss von Informationen zu verbessern. Auch die teilweise sehr gut ausgeprgte 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 Aufkommen ist es mglich, eine weitaus hhere Informationsut zu verarbeiten. Auch die zwischenmenschliche Kommunikation ist durch die bessere Erreichbarkeit und Aktualitt strker ausgeprgt und einfacher mglich. Denn durch Smartphones ist es gegeben, instantan kommunizieren zu knnen. Damit ist auch ein Wandel von einer Push-Kommunikation zu einer Pull-Kommunikation verbunden. Wo frher beide Gesprchspartner direkt miteinander verbunden waren, knnen diese heute indirekt miteinander kommunizieren4 . Das hat zur Folge, dass Kommunikationspartner sich selbstbestimmter Informationen einholen knnen. Aus den genannten Tatsachen heraus erschloss sich das Thema der Masterarbeit, eine mobile Kollaborationsplattform fr verteilte, agile Softwareprojekte zu erschaffen. Diese soll die Trends bercksichtigen und mit einer guten Kombination moderner Kommunikationsmittel und agiler Grundgedanken, die Zusammenarbeit und soziale Interaktion in Projekten erhhen 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 verstndigen knnen, um die Kommunikation im Projekt zu frdern. Es soll gezeigt werden, wie durch eine sinnvolle Verknpfung von vorhandenen, modernen Kommunikationskanlen mit mobilen und nicht mobilen Endgerten eine ganzheitliche und leichtgewichtige Kommunikation innerhalb einer Projektgruppe ber Standortgrenzen hinweg ermglicht werden kann. Dafr wird zunchst eine Analyse von Kommunikationskanlen, welche sich in den letzten Jahren im Alltag etabliert haben, durchgefhrt. Das Ergebnis der Analyse soll eine Liste von Kommunikationsmitteln sein, welche eine Empfehlung von den Autoren fr eine ganzheitliche Kommunikation darstellt. Nach der Analyse wird beispielhaft eine Kommunikationsplattform konzipiert, implementiert und anhand eines Anwendungsbeispiels veriziert. Die Plattform soll smtliche Bereiche der Kommunikation abdecken und vereinen, damit eine Verbesserung dieser gewhrleistet wird. Die Funktionalitten (Features) der umgesetzten Projektplattform ergeben sich aus der entstandenen Liste der Analyse. Um die Analyse zu verbessern, wird ein Selbsttest der Kommunikationsmittel durch die Autoren whrend der Umsetzung der Plattform gettigt.
4 ber

neue Dienste, wie Twitter und Facebook

1.2. Thesen

1.2. Thesen
Neben dem genannten Ziel wird sich mit weiteren Fragestellungen befasst. Dazu werden folgende 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 Mglichkeiten, innerhalb eines Projektes zu interagieren. Die Nutzung solcher Dienste innerhalb eines Projektes kann die Zusammenarbeit verbessern. Durch die Nutzung von Smartphones fr die Kommunikation und Kollaboration mittels des Einsatzes verschiedener Dienste, wie z.B. ortsbasierte Dienste, kann eine hhere Transparenz in virtuellen Teams erreicht werden, was wiederum ein hheres Vertrauen im Team zur Folge hat. Durch die Verwendung von sogenannter Social Software kann ein hheres Vertrauen und ein hherer Zusammenhalt im Team geschaffen werden.

1.3. Aufbau der Arbeit

Das Kapitel 1 leitet das Thema und Ziel dieser Masterarbeit ein und beinhaltet allgemeine Fakten zur Arbeit. Im weiteren Verlauf wird in Kapitel 2 ber die Domne agiler Projekte und deren Fachwrter berichtet. Zudem analysiert dieses Kapitel grundlegende Vernderungen in der Kommunikation innerhalb von Projekten. Es wird darauf eingegangen, was Entwickler bentigen, um auch in verteilten Teams ein besseres Gruppenzugehrigkeitsgefhl zu bekommen und was in einem verteilten Team kommunikationsrelevant ist. Kapitel 2.8 analysiert verschiedene Kommunikationsmittel auf ihren Nutzen fr den Einsatz in einem verteilten, agilen Softwareprojekt. Sie werden anhand von ausgewhlten Eigenschaften auf ihre Verwendungsart und ihrem Verwendungszweck hin geprft. Auf Grundlage der erzielten Ergebnisse wird am Ende des Kapitels ein Vorschlag fr eine Kommunikationsplattform geschaffen. Dieser Vorschlag dient als Grundlage fr den weiteren Verlauf dieser Arbeit und als konzeptionelle Basis fr die Implementierung einer Beispielplattform. Kapitel 3 bietet einen grundlegenden berblick ber technische Grundlagen und behandelt dabei Themen aus Technologien, Build-Managament und der Code-Qualitt. Diese Grundlagen bilden die Basis zum Verstndnis der Arbeit. Die Plattform wird im Kapitel 4 durch Userstories beschrieben. Kapitel 5 und Kapitel 6 dokumentieren die praktische Umsetzung der Plattform. Das Kapitel 7 skizziert am Beispiel der

1.4. Voraussetzungen zum Verstndnis der Arbeit Umsetzung der vorliegenden Masterarbeit den praktischen Alltag und die tgliche Kommunikation 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 Verstndnis der Arbeit

Es wird vom Leser ein grundlegendes Verstndnis der informationstechnischen Grundlagen vorausgesetzt (begonnenes Studium der Informatik). Des Weiteren setzt die Arbeit Basiswissen im Bereich der Softwareentwicklung bzw. der agilen Softwareentwicklung voraus. Alle fr die Arbeit relevanten Themen werden kurz angerissen und erlutert.

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 immer 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 ndet auch, dass der Trend zu einem verteiltem Team immer mehr zunimmt5 . Dies kann sowohl Vorteile als auch Nachteile fr das Projekt bedeuten. Welche hier berwiegen, hngt 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 Kommunikationskanle zur Verfgung stehen, um diese Lcke zu berwinden. Zunchst sollen die fr diese Arbeit relevanten Informationen und die zur Verfgung stehenden Arten von Kommunikationsmitteln innerhalb eines Projektes betrachtet werden. Diese werden dann im Kapitel 2.8 genauer analysiert.

2.1. Begriffsdenition virtuelle Teams(Autor: Christopher Ezell)

Zum besseren Verstndnis wird dem Leser eine Begriffsdenition von verteilten Teams (vgl. [Eck09]) gegeben. In dieser Arbeit werden die Begriffe verteilte Teams und virtuelle Teams (vgl. [Koe09]) synonym verwendet. Denition Virtuelles Team A virtual team, like every team, is a group of people who interact through interdependent 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 miteinander kommuniziert.
5 Laut

einer Studie der Computerwoche aus dem Jahr 2011 [Com12c]

2.2. Kommunikation und Probleme in virtuellen Teams (Autor: Christopher Ezell)

2.2. Kommunikation und Probleme in virtuellen Teams (Autor: Christopher Ezell)

Kommunikation ist ein weites Feld und kann aus den verschiedensten Blickwinkeln betrachtet werden. In diesem Kapitel soll nun die Kommunikation in virtuellen Teams analysiert und strukturiert werden. Es wird ein berblick ber die Arten und Einussfaktoren auf die Kommunikation gegeben. Zudem wird auf Probleme hingewiesen, die sich aus der Kommunikation in einem Team ergeben, welches auf verschiedene Standorte verteilt ist. Hierzu werden verschiedene Studien als Grundlage verwendet. Es soll anhand dieser Studien auch ermittelt werden, welches die entscheidenden Faktoren fr eine gute Kommunikation in einem Projekt sind. Die erste Studie Fhrung und Kommunikation in virtuellen Teams der IT-Branche der Kommission fr Technologie und Innovation (KTI) ist aus dem Jahr 2003. Sie behandelt das Arbeiten in virtuellen Teams und wie solche Teams effektiv geleitet werden knnen. Innerhalb dieser Studie werden verschiedene Faktoren deniert, die in einem virtuellen Team die Kommunikation beeinussen (vgl. [Thi05]). Diese sind das Teamklima, das Vertrauen und Commitment (vgl. [Thi05]). Alle drei werden als sehr wichtig und essenziell fr ein funktionierendes Team erachtet, als Kerneigenschaften deniert. In [Eck09] wird ebenso das Vertrauen als ein wesentlicher Punkt in solchen Teams herausgestellt. Die Studie stellt unter anderem fest, dass viele Probleme in virtuellen Teams nicht aufgrund von technischen Problemen bei der Kommunikation auftreten, sondern wegen zwischenmenschlichen (sozialen) Missverstndnissen verursacht werden. Es kann also festgehalten werden, dass sowohl die soziale Bindung (hier Commitment genannt) als auch das Vertrauen als wichtige Faktoren angenommen werden knnen. Die Small Group Research hat ebenfalls eine Studie6 zu virtuellen Teams durchgefhrt (vgl. [MZ09], Seite 586). 71 Studierende zwei kanadischer Universitten 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 Mitglied eines Teams soll die gleiche Note bekommen, die zudem zu 20-30 Prozent in die Endnote einiet. Zur Kommunikation untereinander standen ihnen E-Mail und Chatrume zur Verfgung. Nach der Teameinteilung wurden die Studierenden mit einem ersten Fragebogen auf ihr Vertrauen zu den Teammitgliedern befragt. Den Mitgliedern der eigenen Universitt wurde mehr Vertrauen entgegen gebracht als der anderen Universitt. Eine Hypothese der Small Group Research war, dass das Vertrauen zu den entfernten Teammitgliedern im Laufe der Bearbeitung steigt. Das Gegenteil war der Fall: Das Vertrauen zu den Mitgliedern der eigenen Universitt stieg noch weiter an und das zu den anderen sank noch mehr (vgl. [MZ09]). Diese Studie zeigt, dass Methoden gefunden werden sollten, die diesem Trend entgegen wirken. Das Vertrauen zu den entfernten Teammitgliedern sollte mit solchen Methoden gesteigert werden. In dem Artikel Virtuelle Teams: Die Rolle der Fhrung (vgl. [Koe09]) von Petra Kppel werden Arten von Problemen und Koniktgrnden in virtuellen Teams erlutert (siehe hierzu Ab6 Further 7 In

Understanding of Trust and Performance in Virtual Teams einem virtuellen Team sind drei Studierende der einen Universitt und drei der anderen Universitt.

2.2. Kommunikation und Probleme in virtuellen Teams (Autor: Christopher Ezell) bildung 2.1). Die Abbildung zeigt die Arten und Einussfaktoren von virtuellen Konikten. Diese sind Mangel an Vertrauen, Kommunikationsmangel und Fhrungsprobleme. Eine Abschwchung der genannten Problemfaktoren kann zu einer Verbesserung der Leistung und Zufriedenheit im Projekt fhren. Ein Kommunikationsmangel kann unter Umstnden dazu beitragen, dass ein Teammitglied nicht ausreichend informiert ist. Das wiederum kann zu einer schlechteren Arbeitsleistung dieses Teammitgliedes fhren. Kppel weist deutlich daraufhin, dass die Zufriedenheit eines Mitglieds durch soziale Kontextinformationen beeinusst werden kann.

Abbildung 2.1.: Konikte in virtuellen Teams (Quelle: [Koe09], Seite 6.) Bei der Interaktion zwischen verschiedenen Menschen sind jedoch diese Kontextinformation sehr wichtig fr jeden Einzelnen. Diese sind subtile Informationen ber verschiedene Sachverhalte, welche nur schwer ber klassische, verteilte Kommunikationskanle8 transportierbar sind (vgl. [SK86], 1986). Hingegen werden solche Informationen in einem nicht virtuellen Team mhelos und kontinuierlich miteinander ausgetauscht. Ein Fehlen dieser Informationen ber z.B. die Arbeitsweise der anderen Teammitglieder oder den Arbeitsumstnden kann zu fehlendem Vertrauen und Verstndnis fhren. Das bietet ein hheres Potential an Konikten. Die Studie von Sproull sagt, dass viele Informationen nur ber sogenannte paraverbale9 und nonverbale Kanle kommuniziert werden (vgl. [K06], Seite 5). Er stellt in seiner Studie die zwei grten Faktoren, die zu Konikten in verteilten Teams beitragen, vor. Dies ist zum Einen
8 Beispiele 9 z.B.

dafr stellen E-mail oder Telefon dar. Tonfall

2.2. Kommunikation und Probleme in virtuellen Teams (Autor: Christopher Ezell) die Reduzierung von Hintergrundinformationen im sozialen Kontext (vgl. [SK86]). Zum Anderen 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 transparenter, erfahrbar zu gestalten. Der Autor Erik Senst listet in einem Lernprogramm fr Virtuelle Teamarbeit (vgl. [Sen01]) bei Mangel an sozialer Prsenz die folgenden sozialpsychologischen Effekte auf, die beobachtet werden konnten. Sie knnen in verschiedenen Situationen sowohl positiv als auch negativ sein. Anonymitt und depersonalisierte Wahrnehmung der Kommunikationsteilnehmer Gleichmige 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 standortbergreifender sozialer Prsenz zu regulieren. Ein besonderes Problem stellen reisende Teammitglieder dar. Sie haben meistens eine bermig lange Arbeitswoche und sind in stressigen Zeiten immer fr die Arbeit unterwegs. Dies muss gegenber den anderen Teammitgliedern kommuniziert und transparent dargestellt werden. Ansonsten kann dies bei den lokalen Mitgliedern eines Standortes zu Missverstndnissen und Unverstndnis fr die geringe Arbeitsleistung dieses Mitarbeiters fhren. Sie knnen zwar in Meetings erwhnen, wie oft sie unterwegs sind und was sie getan haben, jedoch ist dies immer erst im Nachhinein mglich. Viele Meetings sind so gehalten, dass nur wenig Zeit fr soziale Interaktionen zur Verfgung steht. Es msste hier eine Echtzeitlsung existieren, die solche Arten von Aktionen transparent gegenber anderen Mitgliedern aller Standorte gestaltet. Dies trifft auch fr Mitglieder zu, die mit einem erschwerten Arbeitsumfeld oder einer doppelten Projektlast arbeiten mssen. Auch hier kann es schnell zu einem Unverstndnis im Team kommen, warum dieser Mitarbeiter viel weniger Arbeit leistet als die Anderen. Besonders im Umfeld der agilen Softwarentwicklung stellt der Trend der immer greren Verteilung der Teams ein groes Problem dar. Laut [Eck09] und vielen anderen Autoren funktionieren 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 Konikt. Mit der zunehmenden Virtualitt der Teams ergeben sich systemimmanente Koniktherde (vgl. [Koe09]) in der Kommunikation innerhalb solcher Teams. Das spezielle Problem von agilen Teams besteht in der Tatsache, dass die Intensitt der Interaktion/Kommunikation innerhalb des Teams weitaus hher ist als in nicht-agilen Projekten (vgl. [Bec99] und [Eck09]). Fr diese Anforderung muss in einem virtuellem Team eine Lsung gefunden werden. Hieraus

2.3. Lsungsanstze (Autor: Christopher Ezell) bekommen auch Werte wie das Vertrauen und das Teamklima automatisch einen hheren Stellenwert. Wie noch in Kapitel 2.8 nher erlutert wird, wollen Menschen sehr viele Informationen mit ihren Mitmenschen teilen, um sie so besser kennenzulernen. Einige dieser Informationen knnten auch in Projekten von Relevanz sein. Gerade in verteilten Projekten, in denen sich die Projektmitarbeiter oft nur selten sehen, ist es ein sehr wichtiger Faktor, die persnliche Bindung zu den Projektmitarbeitern aufrecht zu erhalten. Viele der genannten Informationen aus Abbildung 2.2 (Ort, Benden und weitere) knnen auch fr Projektteams wichtig sein und sollten mit Kommunikationsmitteln vermittelbar sein. Abschlieend kann festgehalten werden, dass die sozialen Faktoren in einem virtuellen Team nicht unterschtzt werden sollten. Im nchsten Unterkapitel werden dazu Lsungsanstze vorgestellt.

2.3. Lsungsanstze (Autor: Christopher Ezell)

Die in Kapitel 2.2 dargestellten Probleme in verteilten Teams werden schon seit Jahren mit verschiedensten Anstzen versucht zu lsen. Der Hauptangriffspunkt ist das Ermglichen von gemeinsamen Arbeiten an einer Information und das Bereitstellen von zentralen Informationssystemen, zu denen alle Mitglieder Zugriff haben. Hier hat sich das Wort Groupware durchgesetzt. Denition Groupware Ein computer-basiertes System, das eine Gruppe von Personen in ihrem Aufgabengebiet oder Ziel untersttzt und eine Schnittstelle fr eine geteilte Arbeitsumgebung bietet. (vgl. [RK07], Seite 21) Groupware bietet also einer Gruppe von Personen gemeinsamen Zugriff auf Arbeits- und Termininformationen. Beispiele fr diese Informationen sind die folgenden (aus [RK07]): E-Mails gemeinsame Terminkalender gemeinsame Adressbcher und gemeinsame Todo-Listen (vgl. [RK07]) Daneben bieten heutige Groupware-Lsungen weitaus mehr Features. Ein Beispiel ist hier der Anbieter Atlassian (zu nden unter [Gro12b]) mit den Produkten JIRA10 , Conuence11 und

10 ein 11 ein

Bugtracking-System Wiki-System

2.3. Lsungsanstze (Autor: Christopher Ezell) Bamboo12 . Der hohe Wert an der Nutzung der ganzen Reihe an Software von Atlassian liegt in der nahtlosen Integration von vielen Features innerhalb dieser Reihe. Der Lsungsansatz der Groupware lst nur einen Teil der in Kapitel 2.2 beschriebenen Probleme. Die meiste Kommunikation bei Groupware ist sehr nchtern und fokussiert auf den Informationsgehalt fr das Projekt und den Fortschritt der Aufgabe. Ein groer Teil der sozialen Probleme, wie dem fehlenden Kontext und der fehlenden Einschtzung der kommunizierten Information, bleibt weiter ber solche Systeme nur bedingt klrbar. Auch viele geforderte Praktiken im Projektalltag, wie das kurz fassen und sachlich bleiben, frdern nicht die soziale Interaktion. Ein Lsungsansatz wre hier der kombinierte Einsatz von Groupware und Social Software. Denition Social Software Unter Social Software versteht man Anwendungen, die menschliche Interaktion untersttzen (nach [RK07], Seite 21). Social Software bietet genau das, was Groupware (im Allgemeinen) nicht bietet, nmlich eine Plattform zum Austausch von zwischenmenschlichen Informationen und die Kommunikation ber persnliche Dinge. Der geforderte Lsungsansatz kann also mit den geeigneten Kommunikationsmitteln auf diese Anforderungen besser reagieren. Das Potential fr Konikte 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 Anbietern nicht mehr rein nach der Denition zwischen Groupware und Social Software getrennt werden kann. Immer mehr Anbieter integrieren soziale Dienste in ihre Groupware (beispielsweise der Anbieter Atlassian ([Gro12b]). Atlassian ist einer der greren und erfolgreichen Anbieter solcher Software. Erst mit der letzten Version 4.X wurde in das bekannte Wiki Conuence der Like-Button und ein RSS-Feed fr Popular Content13 implementiert. Es ist es mglich, einem User zu folgen (siehe Release Notes Conuence [Gro12c]). Da diese Version von Conuence erst zum Ende der Masterarbeit herausgebracht wurde, ndet 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 Hlfte der Unternehmen in Deutschland (47 Prozent) Social Media nutzen (vgl. [bit12b]). Social Media wird aber nur fr die externe Kommunikation und das Marketing genutzt. Die Nutzung solcher Medien fr interne Kommunikation in Firmen ist zur Zeit noch nicht weit verbreitet, aber die Anzahl der Artikel und Bcher ber dieses Thema

12 ein

13 Wiki-Seiten

Continous-Integration-System mit den meisten Likes

10

2.4. Das Potential von mobilen Endgerten 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 Endgerten in verteilten Teams (Autor:

Rene Kassel)

Neben der Entwicklung von Social Software ist ein weiterer Trend die Nutzung von Smartphones und Tablets. Laut einer Studie14 der BITCOM nutzen 43 Prozent der SmartphoneNutzer jeden Tag das Internet. Nur 42 Prozent nutzen tglich die Telefon-Funktion (vgl. [bit12a]). Dies spiegelt einen allgemeinen Trend wieder, alles mit dem Smartphone zu erledigen und weniger auf dem Desktop-PC oder mit dem Notebook. Wenn die Nutzer unterwegs sind, bietet das Smartphone/Tablet die einzige Mglichkeit, online Dinge zu ttigen. Laut einer 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 Endgerten ermittelt. Dabei liegen Tablets und Smartphones ganz vorne. Wird nun dieser Trend mit den oben genannten Kommunikationsaspekten verbunden, ergeben sich vielfltige neue Mglichkeiten sich mit seinen Teammitgliedern in Verbindung zu setzen. Auch auf Reisen knnen dadurch immmer Sachverhalte bezglich der aktuellen Ttigkeit oder Position kommuniziert werden. Hierdurch ist eine sehr viel hhere Transparenz und ein hheres Commitment im Projekt potentiell mglich15 .

2.5. Arten von Informationen in Teams (Autor: Christopher Ezell)

Generell existieren in einem Team unendlich viele Informationen verschiedenster Arten, welche kommuniziert, gespeichert oder verarbeitet werden knnen. Die Abbildung 2.2 zeigt eine Darstellung von ausgewhlten Informationen, die innerhalb eines Projektteams anfallen. Die gewhlten Oberbegriffe in der Abbildung sind Informationen zur Erreichbarkeit, Statusinformationen, Arbeitsinformationen, Wissen und Echtzeitinformationen. Jedem Oberbegriff sind verschiedene Teilinformationen zugeordnet. Diese decken smtliche Bereiche der sozialen Interaktionen in Projekten ab. Dargestellt sind hier die Informationen, die nach Autorenmeinung wichtig sind, um eine gute soziale Kommunikation zu erschaffen bzw. zu verbessern.

14 Smartphone-Funktionen: 15 Ob

Internet wichtiger als Telefonieren dies so ist, muss sich in weiterfhrenden Studien noch zeigen.

11

2.6. Arten von potentiellen Kommunikationskanlen (Autor: Christopher Ezell)

Abbildung 2.2.: Arten von Informationen in Teams (Quelle: Eigene Darstellung)

2.6. Arten von potentiellen Kommunikationskanlen (Autor: Christopher Ezell)

Im Whitepaper E-Collaboration Mehrwerte durch moderne Kommunikationsmittel schaffen [Hor08] von Martin Hornstein et. al. ndet sich die nachfolgende Aufteilung von Kommunikationsmitteln. Er unterscheidet zwischen Kommunikationsmitteln der ersten, zweiten und dritten Generation. Erstere werden Basis-Module genannt und bestehen aus: E-Mail, Kalender und Telefon. Kommunikationsmittel der zweiten Generation werden in dem Paper Zusammenarbeit steht im Mittelpunkt genannt und beinhalten: Instant Messaging, Presence Awareness (Ortsdienste), Dokumentenmanagement, Projektmanagement-Tools und Desktop Sharing. Kommunikationsmittel der dritten Generation werden Social Software und Web 2.0 genannt und bestehen aus: Tagging, Tag-Clouds,

12

2.6. Arten von potentiellen Kommunikationskanlen (Autor: Christopher Ezell) Wikis, Blogs, Social Networking, Social Bookmarking und RSS-Feeds. Hinzu kommen einige zustzliche Tools, die von den Autoren ausgewhlt 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 nher auf ausgewhlte Dienste eingegangen.

Abbildung 2.3.: Arten von Kommunikationsmittel in Teams (Quelle: Eigene Darstellung)

13

2.7. Gamication (Autor: Christopher Ezell)

2.7. Gamication (Autor: Christopher Ezell)

Die vorhergehenden berlegungen fhren zu einem zweiten Thema: der Motivation. Ein motiviertes Team, welches gerne an seinen Aufgaben arbeitet, ist in einem Projekt sehr wichtig. Um die Motivation zu steigern gibt es einen mglichen Ansatz, welcher Gamication genannt wird. Darunter wird im Allgemeinen der Prozess, aus einer tglichen Handlung eine spielehnliche Situation zu erzeugen, verstanden. Das bedeutet, dass Eigenschaften, die sonst nur in Spielen vorhanden sind16 , in das tgliche Leben bernommen werden. In einem Blogeintrag von NBCNews.com vom 01. Juni 2010 beschreibt Helen Popkin (vgl. [Rad12]), wie die Effekte der Social Games auf die reale Welt angewendet werden knnen. Laut dem Artikel soll der spielerische Wettbewerb und das Punktesystem zu einem Bestandteil verschiedener Aktivitten werden. Dadurch soll die Durchfhrung dieser Aktivitten verstrkt werden. Denition Gamication Its all part of the gamication of life, reports Advertising Age, where competition and points are increasingly a part of ofine 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 Gamication als ein vielversprechender Ansatz zur Motivationssteigerung von Mitarbeitern dargestellt. Durch das Etablieren von Spielemechanismen in der Software, die ein Mitarbeiter tglich bedient, soll eine Steigerung der Arbeitsfreude geschaffen werden. Die Studie The power of social connections der Universitt Stanford vom Mrz 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 auszuben, zu erhhen. Es gab in der letzten Zeit erste Versuche diesen Prozess auf Softwareprojekte anzuwenden. Die Versuche zeigten positive Effekte: Die Softwareentwickler gehen mit einer sehr viel hheren Motivation an Aufgaben heran und lsen diese potentiell besser. Die Plattform Redcritter (vgl. [Red12]) bietet die Mglichkeit fr erfolgreiche Erfllung eines 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 knnen die Punkte am Ende eines Monats gegen Sonderprmien oder Urlaub eingetauscht werden. Ein weiteres populres Beispiel ist die Online-Hilfe Plattform stackoverow (siehe [sta12]). Hier knnen Softwareentwickler Probleme und Fragen einstellen, die von anderen beantwortet werden knnen. Es gibt jeweils fr das Einstellen und das Beantworten

16 Das

knnte ein Punktesystem sein oder bestimmte Level, die erhht werden knnen.

14

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) der Fragen Punkte und Badges17 . Stackoverow ist eines der erfolgreichsten Frage-AntwortPortale18 . Einer der Grnde dafr ist das umfangreiche Punkte- und Badgesystem.

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell)
Nach der Erluterung von Problemen bei der Kommunikation, gilt es nun zu errtern, wie durch den Einsatz neuartiger Kommunikationsmittel und einer hheren sozialen Interaktion diese negativen Effekte abgeschwcht werden knnen. Abbildung 2.4 zeigt die im Konzept der Plattform angedachten Kommunikationsmittel zur Lsung dieser Probleme. Die Abbildung stellt die Abhngigkeiten zwischen den einzelnen Kanlen dar und zeigt auf, welche Eigenschaften durch Einsatz dieser Mittel potentiell verbessert werden knnen. An der Spitze dieser Sule stehen das Teamklima und das Vertrauen im Team19 . Die beiden Faktoren werden durch verschiedene Eigenschaften innerhalb eines Teams beeinusst. Diese Eigenschaften bilden die Sttze der Faktoren in der Abbildung. Sie werden mit Kommunikations- und Kollaborationsmitteln verbunden. Die einzelnen Mittel werden nachfolgend analysiert.

Abbildung 2.4.: Die Sulen der Teamarbeit (Quelle: Eigene Darstellung)

17 Abzeichen 18 Stackoverow

ist laut Alexa (Ein Trafcanalysedienst fr das Internet) [ale12b] bei den weltweiten Top-Seiten auf Platz 98 (August 2012) [ale12a] 19 Eine Erluterung zu der Wichtigkeit dieser Begriffe gibt das Kapitel 2.2.

15

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell)

2.8.1. Einordnung und Eigenschaften der Tools (Autor: Rene Kassel)

Um die Einordnung der einzelnen Techniken besser bewerten zu knnen, wurden sie zunchst in zwei Gruppen eingeteilt. Die Einteilung erfolgt in Kollaborationstools20 und Informationstools21 . Fr jede dieser Gruppen wurden eine Reihe von Eigenschaften zusammengestellt, welche nachfolgend erlutert werden. Sie sind aus verschiedenen Disziplinen entnommen und stellen den Nutzen der Techniken in den Bereichen der Kommunikation und Interaktion dar. Die verwendeten Eigenschaften fr Kollaborationstools sind folgende: Kollaborationsfaktor: Dieser Wert gibt Auskunft darber, inwiefern sich das Kommunikationsmittel, unabhngig von anderen Faktoren, fr 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 durchgefhrt werden kann. Historie: Dieser Wert gibt an, wie gut Vernderungen, Kommunikationsverlufe bzw. Verlufe der Kollaboration nachvollzogen werden knnen. Soziale Interaktion: Das ist ein Faktor, welcher eine Einschtzung ber die Mglichkeit der zwischenmenschlichen Kommunikation gibt. Dabei bercksichtigt der Faktor, inwieweit diese mglich ist und wie gut die Interaktion untersttzt wird. Informationsaustausch: Wie der Name schon sagt, gibt diese Eigenschaft Auskunft darber, wie gut sich ber das verwendete Tool Informationen austauschen lassen und welche Arten von Informationen ausgetauscht werden knnen. Ortsunabhngige Erreichbarkeit: Hiermit wird die Untersttzung speziell im Tabletund Smartphone-Bereich beschrieben. Wird eine Untersttzung in diesen Bereichen gewhrleistet, ist die Zusammenarbeit zwischen den Projektpartnern stets mglich. Damit ist der Wert hoch. Ein geringer Wert kann entstehen, wenn der Projektpartner fr die Verwendung einer bestimmten Technik an seinem Arbeitsplatzrechner verfgbar sein muss. Informationstools besitzen alle bisher genannten Eigenschaften, auer den Kollaborationsfaktor. Diese Eigenschaft wurde durch die Gemeinsame Informationsgenerierung ersetzt. Zu den bisherigen kommen noch einige andere hinzu, die nachfolgend nher erlutert werden:

20 Der

Begriff beschreibt Tools, die ausschlielich das direkte gemeinschaftliche Arbeiten ber ein Netzwerk hinweg realisieren. 21 Bei diesen Tools steht nicht die direkte Arbeit, sondern der Informationsaustausch sowie die Informationsgenerierung und Handhabung im Vordergrund.

16

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Gemeinsame Informationsgenerierung: Dieser Wert gibt eine Aussage darber, wie gut ber das spezische Programm Informationen gemeinsam erzeugt und gesammelt werden knnen. Gleichzeitige Dokumentbearbeitung durch mehrere Nutzer: Der Wert spiegelt die Fhigkeit des Tools wieder, inwieweit ein Dokument durch mehrere Nutzer zur gleichen Zeit bearbeitet werden kann. Der Wert ist besonders hoch, wenn es vllig egal ist, wann ein Nutzer auf ein Dokument zugreift, wann er die nderungen abspeichert und wenn die Bearbeitung an einem gemeinsamen Dokument vllig synchron luft. bersichtlichkeit der vorhanden Informationen: Diese Eigenschaft soll beschreiben, wie gut vorhandene Informationen dargestellt werden und welche Informationen bereits vorhanden sind. Ebenfalls gibt sie Auskunft darber, wie gut durch die vorhandenen Informationen navigiert werden kann, also die Nutzerfreundlichkeit bezglich der Strukturierung der einzelnen Informationen. Langzeitspeicherung der Informationen: Ein wesentlich bedeutender Faktor ist, wie gut das Tool die Speicherung von Daten ber einen lngeren Zeitraum gewhrleistet. Durchsuchbarkeit der vorhandenen Informationen: Die Eigenschaft behandelt die Suchfunktion des Tools durch die gesamten Informationen, die mit Hilfe des Tools entstehen bzw. erzeugt werden. Der Wert ist besonders hoch, wenn eine Volltextsuche existiert und der Ort der gewnschten Informationen durch die Suche in krzester Zeit ausndig 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 fr was es eingesetzt werden kann. Anschlieend folgt ein Beispiel, wie die einzelne Technik im Rahmen der Masterarbeit eingesetzt wird. Da sich die Lsungen 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 Einschtzung ber alle bestehenden Lsungen zu geben. In diesem Fall wird in einer Funote 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 Dokumentes in Echtzeit. Es bietet die Mglichkeit, dass mehrere Personen gleichzeitig und nahezu ohne Zeitverzgerung in ein und dasselbe Dokument schreiben knnen. Dabei kann fast jeder

17

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Tastendruck live mitverfolgt werden. Es existieren unterschiedliche Implementierungen eines solchen Pads. Etherpad ist eine mgliche Umsetzung, welche auch im Rahmen der Masterarbeit zum Einsatz kommt (siehe A.9). Davon existieren ffentlich zugngliche Instanzen, aber auch die Mglichkeit 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 zunchst 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 gelscht. Sie ist von berall aus erreichbar. Wird diese URL aufgerufen, dann wird ein integrierter Texteditor im Browser geffnet, in welchem gemeinschaftlich gearbeitet werden kann. Ein Collaboration Pad birgt aber einige Gefahren. Gert ein Dritter an die erwhnte URL, kann er auf das Pad zugreifen, die gespeicherten Informationen einsehen und Vernderungen vornehmen. Es ist daher ratsam, dass dort keine streng geheimen und vertraulichen Informationen bearbeiten werden. Das trifft zumindest dann zu, wenn ein ffentlich zugnglicher Pad-Dienst genutzt wird und keine Eigeninstallation. Ein weiteres Problem besteht darin, dass mehrere Nutzer zur selben Zeit an der gleichen Zeile schreiben knnten. Dadurch kann es schnell zu Unstimmigkeiten und rgernissen kommen. Deshalb sollte hier die Regel gelten, dass ein Nutzer den anderen Nutzer ausschreiben lsst, damit die Bearbeitung an dem gemeinsamen Dokument nicht im Chaos endet. Zustzlich 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 fhlt sich dadurch als Teil einer Gemeinschaft. Das gemeinschaftliche Arbeiten kann die Partizipation und die Offenheit der Einzelnen frdern (vgl. [BDMM10a]). Dadurch knnen Dokumente von besserer Qualitt und hherer Vielfalt entstehen. Dadurch kann wiederum die Dokumentation eines greren Projektes genauer 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 gewhrleistet, dass weniger Informationen verloren gehen oder einfach vergessen werden. In der Praxis nden Collaboration Pads eine sehr rege Verwendung. So nutzt die Piratenpartei dieses Tool fr viele Abstimmungsaufgaben mit Hilfe des Piratenpads (vgl. [pir12]). Dies ist eine ffentlich zugngliche Instanz des freien Tools Etherpad, welches mit dem PiratenparteiBrand versehen wurde. Etherpad, worauf die Entscheidung zur Verwendung gefallen ist, bringt eine Menge an Features mit (vgl. [Fou12c] und [BDMM10b]). Dazu zhlen: eine Online-Oberche zur Verarbeitung von Texten mit einem Textfeld, eine bersicht ber die Autoren, die an der Erstellung des Inhaltes mitwirken,

18

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) die Mitverfolgung von jedem getippten Buchstaben durch den Nutzer in Echtzeit, die Hervorhebung von nderungen durch unterschiedliche Farben jedes Nutzers, das Zurcksetzen und die Zurckverfolgung durch den Nutzer bis zum ersten getippten Zeichen, die Historie in einer Art Videoaufzeichnung zur Nachverfolgung der Entstehungsgeschichte, eine Chatfunktion zur Feinabstimmung zwischen den Autoren, die Mglichkeit zur Importierung von HTML, Word und RTF und die Mglichkeit zur Exportierung in die Formate HTML, Word und PDF. Im Rahmen der Masterarbeit wurde eine Eigenschaftsmatrix erstellt, welche das Collaboration Pad bezglich 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 fr die Zusammenarbeit mehrerer Mitarbeiter. Dabei sticht besonders die Echtzeitbearbeitung durch viele Nutzer an einem Dokument hervor. Die gemeinsame Informationsgenerierung ist, durch die Echtzeitbearbeitung an einem Dokument, sehr gut mglich. Die Lernkurve ist sehr gering, wodurch wenig Zeit investiert werden muss, um dieses 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 ortsunabhngigen Erreichbarkeit erhlt das Tool keinen hohen Punktwert. Es ist zum Einen sehr gut vom PC aus ber das Internet mittels eines Webbrowsers erreichbar. Zum Anderen ist noch keine Untersttzung fr Smartphones oder Tablets vorhanden. 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 darber, welche Pads er bereits angelegt hat, noch kann er anhand der URL identizieren, 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 dazugehrigen URL. Damit verbunden, kann das Collaboration Pad auch bei der Durchsuchbarkeit der vorhandenen Informationen wenig punkten. Bei der Historie verzeichnet das Tool wieder einen hheren Punkteausschlag. Der Nutzer kann auf einer Timeline die Entwicklung des Dokumentes vollanimiert beobachten. Zudem kann er bestimmte Stnde abspeichern.

19

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Die soziale Interaktion erfhrt nur leichte Abstriche. Nutzer knnen Dokumente gemeinsam erstellen und sehen die Ttigkeiten voneinander in Echtzeit. Die direkte Kommunikation ist auerhalb des Dokumentes ber die integrierte Chatfunktion ebenfalls mglich. Leichte Abstriche gibt es, weil andere Mglichkeiten der sozialen Interaktion nicht untersttzt werden.

Abbildung 2.5.: Eigenschaftsmatrix des Collaboration Pads (Quelle: Eigene Darstellung) Das Collaboration Pad kann in Summe der vergebenen Punkte je Eigenschaft sehr gut abrumen. Somit ist das Tool empfehlenswert fr den Einsatz in einem verteilten Projekt und kann dort zur Verwendung kommen. Besonders fr die Echtzeitbearbeitung und die gemeinsame Informationsgenerierung gibt es kein Tool, was an die Qualitten eines Collaboration Pads heran kommt. Als spezielle Umsetzung kommt, wie bereits erwhnt, Etherpad zum Einsatz. Es existieren zwar einige andere Umsetzungen auf dem Markt, die hnliche Funktionalitten bewerkstelligen, aber die Funktionalitten so gut umsetzen wie Etherpad. Ein Beispiel dafr ist ein von Google entwickeltes Konstrukt mit dem Namen Google Documents. Die Liveverfolgung in Echtzeit ist dort nicht komplett gegeben und mit einer Verzgerung von 5-15 Sekunden behaftet. Etherpad hingegen ist ein ideales Beispiel fr Liveverfolgung mit einer Verzgerung, welche nahezu gegen null geht. Sie ist durch den Anwender kaum sprbar. Zudem ist Etherpad eine Open-Source-Variante und bietet die Mglichkeit den Dienst auf dem eigenen Server zu integrieren. Im Rahmen der Arbeit wurde sich fr die Eigeninstallation auf dem Server entschieden. Somit knnen alle Features genutzt werden und die Autoren sind nicht von Einschrnkungen und Spezialisierungen abhngig.

20

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell)

2.8.3. Mobile Instant Messaging (Autor: Christopher Ezell)

Denition Instant Messaging Instant Messaging (engl. instant = sofort; engl. messaging = Datenaustausch) ermglicht es, mittels einer Software, dem Instant Messenger, in Echtzeit mit anderen Teilnehmern online zu kommunizieren. [OP] Mobile Instant Messaging meint die Verwendung des Instant Messagings ber das Mobilfunknetz auf mobilen Endgerten, wie beispielsweise Smartphones. Bei dem Kommunikationsablauf werden grundstzlich zwei verschiedene Arten unterschieden. Die Basis des Instant Messagings ist die klassische Kommunikationsform. Diese ist dadurch geprgt, dass ein Sender eine Botschaft an eine entfernte Person bersenden mchte. Technisch realisiert, wird das, indem die Botschaft an den Server des jeweiligen IM22 Netzwerkes geschickt wird. Dieser leitet die Botschaft daraufhin an den Gegenber weiter. Der kann wiederum eine Antwort geben. Somit ist der Kommunkationsweg bidirektional. Heutige IM-Systeme bieten noch weitaus mehr Funktionalitten. Bezglich der Kommunikation sind Konferenzschaltungen bzw. Gruppenkonversationen mglich. In diesem Fall wird von einem multidirektionalen Kommunikationsweg gesprochen. Die bertragung funktioniert hnlich wie bei der bidirektionalen Kommunikation. Es gibt nur zustzlich einen Gruppenleiter, 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 Endgert und einer Internetverbindung. Hieraus gehen Messenger hervor, die bercksichtigen, dass der betreffende Nutzer immer online ist und ihm zu jeder Zeit Nachrichten gesendet werden knnen. Der groe Vorteil dabei: es ist nicht ntig auf ein anderes Kommunikationsmittel umzusteigen, wenn der Nutzer gerade nicht im Chat erreichbar ist. Nachrichten knnen einfach und transparent gegenber Anderen geschrieben werden und der Kommunikationspartner bekommt sie dann als Push-Benachrichtigung auf sein Smartphone geschickt. Der Empfnger kann dann auf die Nachricht reagieren. Ein Beispiel fr einen derartigen Dienst ist Whatsapp. Hier knnen auch Standorte und Fotos miteinander geteilt werden. Bei den beschriebenen Kommunikationsablufen 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 proprietr und untereinander inkompatibel. Einige Beispiele sind (entnommen aus [Mob12]):

22 Instant

Messaging

21

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) OSCAR: ist ein Protokoll fr den AIM23 und den ICQ-Dienst sowie die dazugehrigen Clients. Skype: ist der Name des Protokolls und des Clients. Simple: gibt dem SIP24 -Standard IM-Funktionalitten. XMPP25 : ist ein erweiterbares Nachrichten-Anwesenheitsprotokoll. Yahoo Messenger: ist der Name des Protokolls und des Clients. In der Praxis existiert eine groe Auswahl an Instant Messenger Programmen. Jedes Programm ist durch seine eigenen Funktionalitten geprgt. ICQ ist einer der bekanntesten Clients. Er hat einen immensen Funktionsumfang und entwickelt sich immer mehr zu einem Multimedia-Allesknner. Es knnen Nachrichten und Dateien ausgetauscht werden. Ebenso sind Video- und Audiochat mglich. Programme, wie Yahoo Messenger oder AIM, beschrnken sich mehr auf Standardfunktionen. Zu den bekannten Clients gehren auch MSN von Microsoft und Skype. Zu den allgemeinen Features von Instant Messenger Programmen zhlen beispielsweise: der Austausch von Textnachrichten, der Austausch von Daten, wie Audio-, Video- und Bilddaten, die Anzeige des Online-Status der einzelnen Kommunikationspartner (online, ofine, abwesend, usw.), die Konferenzschaltung zur Kommunikation zwischen mehreren Partnern gleichzeitig und ein Avatarbild. Besondere Features werden durch die Mglichkeit zum Video- bzw. Audiochat und einem integrierten Whiteboard generiert. Letzteres ermglicht den IM-Partnern auf einer weien Flche 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 auschlielich der direkten Kommunikation von Projektpartnern dient. Anhand der Abbildung zeigen sich die Strken dieses Tools. Durch die volle Untersttzung auf mobilen Endgerten und die relativ gute Netzabdeckung ist der Projektmitarbeiter nahezu dauerhaft erreichbar. Somit erhlt das Tool in der Katgeorie ortsunabhngige Erreichbarkeit volle Punktzahl. Der Informationsaustausch ist ebenfalls dauerhaft und sehr gut mglich. Jedoch gibt es noch bessere Mglichkeiten zum Informationsaustausch, weshalb keine volle Punktzahl vergeben werden kann. Durch den guten
23 Hierbei 24 SIP

handelt es sich um einen bestimmten Messenger von AOL. ist ein Netzprotokoll zur Erstellung, Vernderung und Beendigung einer Kommunikationssitzung zwischen zwei oder mehr Teilnehmern (vgl. [Gro02]). 25 Extensible Messaging and Presence Protocol

22

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Informationsaustausch ist es gewhrleistet, dass die Projektmitglieder immer auf dem neuesten Stand bleiben. Kommunikationswege werden durch den Einsatz eines solchen Tool stark gekrzt. Damit kann das Tool ideal bei der sozialen Interaktion punkten. Eine weitere Strke dieses Tools liegt in der Eigenschaft Einfachheit. Das Tool ist einfach und ohne zustzliche Kenntnisse zu bedienen. Die Historie muss leichte Abstriche erfahren. Chatverlufe je Nutzer werden mit einem Zeitstempel abgespeichert und sind komplett nachvollziehbar und rckverfolgbar. Jedoch ist es oft schwierig, ein Gesprch zu einem bestimmten Thema zu nden. Oft ist die Durchsuchung der Historie sehr aufwndig und mit viel Zeit verbunden. Dass Chatverlufe nur lokal gespeichert werden, fhrt ebenfalls zum Punktabzug. Eine letzte zu untersuchende Eigenschaft ist die Kollaboration. Die Zusammenarbeit ist nicht vollstndig gegeben. Das liegt daran, dass ein Mobile Instant Messenger oft nur fr krzere Abstimmungssachverhalte sinnvoll ist und weniger zum Generieren von neuen Informationen oder von Mehrwert fr das Projekt.

Abbildung 2.6.: Eigenschaftsmatrix des Mobile Instant Messagings (Quelle: Eigene Darstellung) 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 fr den Erfolg eines Softwareprojektes ist. Die soziale Interaktion und der Informationsaustausch ist in einem Projekt sehr wichtig, dabei zeigt dieses Kommunikaionsmittel einen Teil seiner Strken 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 gelst werden mssen, mssen nicht warten und knnen sofort bedient werden.

23

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Fr die Untersttzung des Projektes wurde sich fr die Kommunikation speziell fr die Verwendung des XMPP-Protokolls entschieden. Mit Hilfe dessen ist die Kommunikation innerhalb des Projektes gewhrleistet. Dieses Protokoll eignet sich besonders gut, da es einen groen Funktionsumfang bietet und nahezu alle bekannten Mglichkeiten, die ein Chat bieten sollte, mit diesem realisiert werden knnen.

2.8.4. Screen Sharing (Autor: Rene Kassel)

Screen Sharing, auch Desktop Sharing genannt, beschreibt die bertragung von Bildschirminhalten eines Computers auf viele andere Computer ber ein Netzwerk. Dadurch entsteht das Gefhl, dass sich der Anwender direkt an dem entfernten Desktop bendet 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 Anwendungsfeldes (geschftlich oder privat) und ihrer Funktionalitt (vgl. [Mik]). Desktop Sharing wird in verschiedenen Bereichen eingesetzt. Diese knnen sein (vgl. [Mik]): Fernwartung/Support: Dieses Gebiet gehrt zu dem Hauptanwendungsfeld des Desktop Sharings. Probleme an entfernten Computern knnen problemlos, schnell und ohne grere Kommunikationsschwierigkeiten gelst werden. Der Anwender des Remotegertes muss dazu lediglich eine Anwendung starten, welches den Zugang zu dem untersttzenden System gewhrleistet. Teamarbeit/Projektbesprechungen: Ein weiteres Anwendungsgebiet ist die Kollaboration an Dokumenten oder Produkten. Dies kann mit Hilfe eines solchen Tools ber verteilte Standorte hinweg realisiert werden. Fernzugriff/Remote Ofce: Dieser Bereich beschreibt die Fernsteuerung des eigenen entfernten Computers ber Desktop Sharing. Dies kann erfolgen, ohne dass der Anwender selbst vor Ort sein muss. Es ist von unterwegs mglich, auf seine eigenen Computer zuzugreifen und eigene Server fernzuwarten. Ein solches Tools hat mehrere positive Eigenschaften: Die Projektpartnern knnen dadurch im Team efzienter und schneller arbeiten. Dies ist besonders durch die eindeutige, schnelle und zielfhrende Kommunikation mglich. Durch den Einsatz dieses Tools knnen Kosten und Zeit gespart werden. Die Projektpartner mssen sich nicht an einem Ort zusammennden, sondern knnen verteilt arbeiten. Die Bedienbarkeit von Screen Sharing Tools erweist sich als relativ einfach. Ein weiterer Vorteil ist die Betriebssystemunabhngigkeit (vgl. [Mik]). Es gibt eine ganze Reihe von Screen Sharing Tools auf dem Markt. Viele Lsungen werden zur freien Verwendung angeboten. Zu den wohl bekanntesten Lsungen zhlen 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 mglich seinen Desktop freizugeben, gemeinsam zu arbeiten,

24

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Dateien auszutauschen und miteinander zu chatten. Derjenige, der gerade seinen Desktop teilt, kann Rechte vergeben, was der andere tun darf. Er entscheidet, wie lange ein Zugriff stattndet. Screen Sharing wird der Kategorie der Kollaborationtools zugeordnet. Die Abbildung 2.7 zeigt die Eigenschaftsmatrix des Screen Sharings. Die Einschtzung der einzelnen Eigenschaften ber Screen Sharing ist im Allgemeinen sehr schwierig. Im Zweifelsfall wird der geschtzte Wert von der Verwendung von Team Viewer genommen. Die einzelnen Implementierungen unterscheiden sich ziemlich stark in ihrem Funktionsumfang. Die Strken dieses Tools stechen heraus: Sie liegen in den Bereichen der Einfachheit und des Informationsaustausches. Die Bedienung ist selbsterklrend und es sind nur wenige Schritte notwendig, um einen Bildschirm freizugeben. Die meisten Implementierungen des Screen Sharings liefern eine Funktionalitt zum Datenaustausch. Dadurch kann ein sehr guter Informationsaustausch stattnden. Die ortsunabhngige Erreichbarkeit erfhrt Abstriche: Smartphoneintegration ist zwar vorhanden und wird untersttzt, aber das Arbeiten ber ein Smartphone/Tablet ist unkomfortabel. Die Kollaboration ist mittelmig. Es frdert zwar die Zusammenarbeit ungemein, aber es bietet nicht die Mglichkeit zusammen und zur gleichen Zeit an einer Sache zu arbeiten. Stattdessen kann nur einer auf dem Bildschirm gleichzeitig arbeiten. Der Andere kann Anmerkungen ttigen und verfolgen. Die Eigenschaft soziale Interaktion hat nicht die volle Punktzahl erreicht. Durch die genannten Features knnen zwar einige Aspekte der Interaktion bedient werden, aber nicht alle. Die meisten Screen Sharing Programme bieten keinen Audio-Chat. Die Historie verzeichnet starke Einbuen. 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 zurckfhrbar. Das ist ein groes Dezit. 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 fr den Einsatz in verteilten Projekten. Die Verknpfung des Screen Sharings mit anderen Techniken ermglicht fast die volle Punktzahl ber alle Eigenschaften26 Besonders die visuelle Kommunikation kann in verteilten Projekten erfolgsentscheidend sein. Es gibt Aufgaben, die derartige Mglichkeiten zwingend bentigen. Das macht das Screen Sharing zu einer nahezu unabdingbaren Technik fr verteilte und auch fr agile Projekte.

26 Eine

Verwendung dieser Technik mit anderen Techniken wird im nchsten Kapitel 2.8.5 vorgestellt.

25

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 2.7.: Eigenschaftsmatrix des Screen Sharings (Quelle: Eigene Darstellung) Whrend der Umsetzung der Masterarbeit wird ein Tool aus diesem Bereich eingesetzt. Dabei wird sich auf die Verwendung von Team Viewer beschrnkt. Mit Hilfe dessen ndet sowohl das Pair Programming als auch das gemeinschaftliche Arbeiten an Dokumenten Untersttzung. Es ist ideal, um seinen Projektpartner etwas zu erklren 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 Quellcode, whrend der andere zuschaut (vgl. [Wil01]). Nach einer gewissen Zeit tauschen die beiden ihre Rollen. Der Beobachter achtet auf mgliche Fehler und betrachtet den geschriebenen Quellcode kritisch. Hat der Beobachter Anmerkungen, so teilt er diese sofort seinem Partner mit. Dadurch kann umgehend darauf reagiert werden. Der Beobachter bringt Verbesserungsvorschlge mit ein. Zudem achtet er auf mgliche zuknftige Probleme, die durch den geschriebenen Quellcode entstehen knnten. Dem Schreiber werden dadurch eine Menge an Aufgaben abgenommen, sodass er der eigentlich Aufgabenerfllung 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 Programmieren 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

27 Genauer

gesagt, ist es eine Technik aus dem Extreme Programming (vgl. [Wel12]).

26

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Entwicklungsumgebung zum Einsatz kommen. Zustzlich ist es notwendig, dass eine Software aus dem Bereich Collaboration Pad (Kapitel 2.8.2) oder ein Audio-Chat eingesetzt wird. Mit jeweils einer Anwendung aus diesen Bereichen werden die Grundzge des Pair Programmings auch bei verteilter Verwendung umgesetzt. In den einzelnen Bereichen gibt es verschiedenste Softwareangebote, welche eingesetzt werden knnen. Das Ziel dieser Technik ist die Steigerung der Softwarequalitt. Dies bietet die BeobachterFunktion, mit der kritische Lsungen eingeschrnkt werden knnen. Der Lerneffekt der Partner kann erhht werden. Sie knnen voneinander lernen und sich zum Teil neue Mglichkeiten aneignen. Einige Studien haben herausgefunden, dass Programmierer, die diese Methode verwenden, zwar kleinere Programme produzieren, dafr 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 Aufgabenkomplexitt (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 unmglich lsbare Probleme sind in der Gemeinschaft einfacher und schneller zu lsen (vgl. [CW00] und [WK03]). Ein weiterer Vorteil stellt sich dadurch heraus, dass die Programmierer ihr Wissen untereinander teilen und voneinander lernen knnen (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 verlsst (vgl. [CW00]). Die Strkung 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 Konikten kommen, indem der Erfahrenere den anderen beschimpft oder beleidigt. 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 Bercksichtigung 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 inefzient. Die Strken des Remote Pair Programmings liegen in den Bereichen der Kollaboration, der sozialen Interaktion und in dem Informationsaustausch. Speziell in Softwareprojekten ist es sehr hilfreich mehrere verschiedene Programme, die diese Technik untersttzen, einzusetzen. Eine mgliche Untersttzung fr das Remote Pair Programming ist das Screen Sharing.

27

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Treten Schwierigkeiten auf, knnen sich die Teammitglieder mit Hilfe dieser Tools gegenseitig sehr gut untersttzen und vorantreiben. Somit ist einer Verzgerung bei der Bearbeitung bestimmter Aufgaben schnell entgegengewirkt. Die Zusammenarbeit ist in vollem Umfang erfllt. Damit verbunden ist auch die soziale Interaktion stark ausgeprgt. Die beiden Nutzer sehen den gleichen Bildschirm. Auf diesem Bildschirm knnen Vernderungen vorgenommen werden und Inhalte generiert werden. Jedoch kann immer nur einer der Nutzer an dem Sachverhalt arbeiten. Der Wechsel des bearbeitenden Nutzers kann sehr schnell und mit einer geringen Wechseldauer erfolgen. Es gibt Applikationen fr Smartphones, welche das Remote Pair Programming ermglichen. Ein Smartphone als Endgert fr die Softwareentwicklung ist nicht gut geeignet, gegeben duch die Eigenschaften eines Smartphones, wie Displaygre, Handhabbarkeit, Nutzerfreundlichkeit 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 fr den Notfall eignet, aber nicht fr die Routine. Es erwies sich als weniger nutzerfreundlich. Aufgrund dessen erhalten Remote Pair Programming Tools in der Kategorie ortsunabhngige 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 rckwirkend nachvollzogen werden, welcher Nutzer zu welcher Zeit welchem Nutzer an was gearbeitet hat. nderungen am Quellcode knnen aber durch zustzliche Tools, wie einer Versionskontrolle, nachvollzogen werden. Aus diesem Grund ist die geringe Punktzahl in der Kategorie ertragbar und nicht von starker Relevanz fr 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 jeweils hohe Punktzahlen. Besonders fr 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 fr verteiltes, gemeinschaftliches Arbeiten in Projekten. Die Fehlerrate sinkt und die Fehlerbehebung erfolgt viel schneller und efzienter. Somit ist Pair Programming sehr sinnvoll und bringt in Projekten sehr viele Vorteile. Zur Untersttzung 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 Fllen kam die Bildschrimfreigabe von Skype zum Einsatz. Als Whiteboard wird das Eclipse-Plugin Saros verwendet. Saros untersttzt zustzlich das gemeinschaftliche Schreiben an einer Quellcode-Datei. Als Collaboration Pad wurde eine Eigeninstallation von Etherpad ausgewhlt. Zur akustischen Abstimmung wird im Rahmen des Mas-

28

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 2.8.: Eigenschaftmatrix des Remote Pair Programmings (Quelle: Eigene Darstellung) terarbeitsprojektes vorwiegend Skype oder der Chat auf dem eigenen Projektserver verwendet, welcher ebenfalls den Audio-Chat untersttzt.

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 gefhrt und chronologisch angeordnet sind. Sie werden hauptschlich fr Tagebcher und Verffentlichungen von Fachbeitrgen genutzt. In den letzten Jahren etablierten sie sich fr den Einsatz als Kommunikationsmittel innerhalb von Projekten. Sie knnen fr verschiedene Zwecke eingesetzt werden. Fr diesen Kommunikationskanal eignen sich Informationen, die von einer Person fr viele Personen bereit gestellt werden. So knnen tagesaktuelle Ereignisse und neue Informationen schnell und efzient ins gesamte Projekt verteilt werden und jeder kann schnell auf diese Information zugreifen. Durch die Verwendung eines RSS-Readers (Really Simple Syndication) knnen die Inhalte sogar mobil konsumiert und fr die Ofineverwendung archiviert werden werden. Durch die Mglichkeit eines Kommentarsystems knnen Meinungen zu einem Sachverhalt ermittelt und diskutiert werden. Das macht einen Blog zu einem mchtigen Werkzeug in der verteilten Kommunikation und sollte in keinem greren 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 Lsungen eines Problems in einen Blogpost gefasst werden knnen (vgl. [Tri12]). Der Blog zhlt zu den Informationstools. In Abbildung 2.9 ist die Eigenschaftsmatrix zu sehen. Eindeutig liegen die Strken in der Durchsuchbarkeit der vorhandenen Informationen,

29

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) der Langzeitspeicherung und der Historie. Die Erreichbarkeit ist durch die vollstndige Bedienbarkeit ber eine Weboberche (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. fnf Punkte in der Kategorie Einfachheit. Mittelmige Punktausprgung erhlt der Blog in der bersichtlichtkeit, wegen der stark zeitorientierten Anordnung der Blogbeitrge. Diese knnen nur mit Hilfsmitteln besser strukturiert werden, z.B. mit Hilfe von Tags. Die Eigenschaft gemeinsame Informationsgenerierung hat lediglich drei Punkte, da ein Blog meist nur zur Verbreitung von Neuigkeiten dient. Trotzdem knnen einige Informationen aus einem Blog entnommen werden, wie beispielsweise Meinungsbilder und Abstimmungen ber konkrete Sachverhalte. Mittelmig bis schwach ausgeprgt sind die Kategorien soziale Interaktion, Informationsaustausch und gleichzeitige Dokumentbearbeitung. Die gleichzeitige Dokumentenbearbeitung existiert bei dieser Art der Kommunikation nicht. In den meisten Fllen schreibt lediglich eine Person28 ihren Blogeintrag und andere knnen diesen dann einsehen und kommentieren. Deswegen erhlt der Blog auch nur eine mige Punktanzahl in der Eigenschaft Informationsaustausch. Informationen knnen 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 mglich, daher die geringe Punktzahl in dem Bereich soziale Interaktion.

Abbildung 2.9.: Eigenschaftsmatrix des Blogs (Quelle: Eigene Darstellung)

28 Es

ist bei manchen Blogsystemen durchaus mglich einen Beitrag von mehreren Autoren zu bearbeiten.

30

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Insgesamt kann ein Blog stark punkten. Besonders fr langfristige und gut durchsuchbare Informationen in einem Projekt sollte ein Blog eingesetzt werden. Der Einsatz ist aber eher in greren und schwer berschaubaren Projekten sinnvoll. Da ist es oft zum Verstndnis der Aufgabe und zum besseren Erfolg des Projektes sehr wichtig ber neue Techniken und Technologien zu berichten. Durch die gute Erreichbarkeit eignet es sich auch fr 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, Technologien und Implementierung bezglich des Projektes. Ebenso dient er auch als Mglichkeit, Themen bezglich 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 knnen ffentlich publiziert werden oder nur einer privaten Gruppe von Nutzern. Der Nutzer kann die Nachrichten online lesen oder Updatebenachrichtigungen ber Vernderungen in Echtzeit erhalten, wie beim Instant Messaging (vgl. [Rou09]). Die Beitrge sind sehr kurz formuliert. Sie haben zwischen 140 und 200 Zeichen. Damit steht das Microblogging im Gegensatz zum Blog, bei dem grere Inhalte publiziert werden. Klare Strke dieser Technik ist, dass sie ber eine Vielzahl an Gerten 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 populr geworden. Andere Beispiele sind Tumblr oder Plurk. Aber auch soziale Netzwerke wie Facebook, LinkedIn, Xing und Google+ besitzen eine Art Microblogging in ihren Funktionalitten. Im privaten Gebrauch erfahren solche Dienst sehr viel Zuspruch. Nach Meinung der Autoren wird diese Mglichkeit 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 einer Onlinekommunikation gewandelt, beispielsweise mittels E-Mail und Instant Messaging. Die Kommunikation ber E-Mails kann teilweise sehr zeitaufwndig 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. Dafr kann das Microblogging sehr gute in Firmen eingesetzt werden.

31

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) In einem aktuellen Blog vom Juli 2012 werden erste Beispiele fr Microblogging-Dienste fr 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 Projektkoordination und einen einfacheren Wissensaustausch zwischen Projektmitarbeitern. Communote bendet sich zur Zeit im Beta-Stadium, verspricht aber eine Mischung verschiedener 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 solche Dienste nutzen. Durch die Eigenschaftsmatrix in Abbildung 2.10 wird der Nutzen eines solchen Tools fr den Einsatz in Projekten bestimmt. Das Microblogging siedelt sich im Bereich der Informationstools an. Die Technik besticht durch die hervorragende Historie und die ortsunabhngge Erreichbarkeit. Die Integration auf Smartphones und Tablets ist vollstndig gegeben. Die Handhabung von Microbloggingtools sehr einfach und bedarf wenig bis gar keinen Lernaufwand durch den Nutzer (fnf Punkte fr die Einfachheit). Die Langzeitspeicherung der Informationen und die bersichtlichkeit zhlen auch zu den Strken von Microblogging. Die Microposts sind in chronlogischer Reihenfolge sortiert und bis zum ersten Post zurckverfolgbar. Im Bereich Informationsaustausch kann das Kommunikationsmittel nur mig punkten. Kurze Statusmeldungen knnen zwar abgesetzt werden, zum Teil in Text-, Video- und Audioform, aber nur fr spezielle Themen. Fr den allgemeinen Informationsaustausch zwischen Projektmitarbeitern eignen sich andere Tools besser. Damit verbunden, punktet auch die soziale Interaktion nur wenig. Der Blogger setzt seine Meldung ab und alle anderen knnen diese einsehen, aber nicht direkt miteinander kommunizieren. Gerade durch das Verffentlichen von kurzen Statusmeldungen ist die gemeinsame Informationsgenerierung nicht komplett gegeben. Meldungen knnen zwar generiert werden, jedoch nur wenig neue Informationen. Die Durchsuchbarkeit von vorhandenen Informationen ist gut ber die Browsersuche mglich, aber es existiert keine eigene Suchfunktion, daher nur vier Punkte. Die gleichzeitige Dokumentbearbeitung 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 Neuigkeiten und Statusmeldungen ausgetauscht werden. Im Groen und Ganzen ist zu sagen, dass das Microblogging eine sehr angenehme Technik. Besonders bei der Schnelligkeit und der Einfachheit sowie bei der Aktualitt der Inhalte zeigt das Microblogging seine Strken. Projektmitarbeiter knnen stets mit aktuellen ProjektNeuigkeiten 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 fr eine Eigenimplementierung dieser Funktionalitt entschieden. Einer der wichtigsten Grnde dafr ist, dass die Funktionalitt sehr stark an die eigenen Bedrfnisse angepasst werden kann. Im umzusetzenden Projekt wird die

32

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 2.10.: Eigenschaftsmatrix des Microbloggings (Quelle: Eigene Darstellung) Technik dazu eingesetzt, Neuigkeiten an das andere Projektmitglied zu posten. Zudem werden 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 Denition von Social Bookmarking bringt kurz und bndig eine Zusammenfassung, wobei es sich bei diesem Dienst handelt. Denition Social Bookmarking Social bookmarking is the practice of saving bookmarks to a public Web site and tagging 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. Mchte er einen bestimmten Link einer Webseite abspeichern, kann er dies ber die Plattform tun. Zustzlich ist es dem Nutzer mglich fr die Sortierung und Organisation von Lesezeichen Tags zu verwenden. Damit wird die Ressource kurz beschrieben. [Soca] Ein Social-Bookmarking-System hat einige wichtige Features. Eines der ntzlichsten 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 verfgbar. Es gibt ebenso die

33

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Mglichkeit Tags anderer Nutzer nach einem bestimmten Inhalt zu durchsuchen (vgl. [Soca]). Einige Webseiten bieten zustzlich eine Verizierung, ob die Links noch funktionieren. Ein weiteres Feature ist die Durchsuchbarkeit. Nutzer knnen Lesezeichen nach Schlsselwrtern, 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 mchte. Es ist einfach zu bedienen und schafft eine gewisse Ordnung in den Bookmarks. Besonders gut geeignet ist es fr Nutzer, die viele verschiedene Endgerte verwenden und von berall aus ihre Lesezeichen verwalten wollen. Fr den unternehmerischen Einsatz sind solche Systeme ebenfalls gut geeignet. Es knnen Lesezeichen zu bestimmten zu erledigenden Aufgaben online gespeichert, durch Tag-Zuordnung sortiert und mit Projektmitgliedern geteilt werden. Besonders durch das Annotieren mit Tags und die Verffentlichung tragen Social-Bookmarking-Systeme zur Verbesserung der Aufndbarkeit der Bookmarks bei. Damit kann ein solches System eine Alternative zu algorithmenbasierten 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. fr Unternehmen kann dies von groer Bedeutung sein und die Suchzeiten bezglich bestimmter Themen stark verkrzen. Denn gerade dort ist es oft so, dass hnliche Themen von Relevanz sind und mehrfach durch unterschiedliche Mitarbeiter gesucht werden mssen. Hier knnen Mitarbeiter durch die Erfahrungen anderer protieren und gespeicherte und getaggte Bookmarks durchsuchen. Die Studie Social Bookmarking und Tagging der Praxis [ML08] von 2008 zeigt, dass SocialBookmarking-Systeme bisher wenig bekannt sind. In der Studie gaben 73,5 Prozent der Befragten 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 fr den Browser. Bekannte Umsetzungen sind Delicious, Technorati, Diigo und Google Bookmarks. Die Eigenschaftsmatrix des Social Bookmarking ist in Abbildung 2.11 dargestellt. Diese Technik gliedert sich in den Bereich der Informationstools ein. Zur einfacheren Bewertungsmglichkeit wird die im Projekt eingesetzte Umsetzung Diigo betrachtet. Die klaren Strken von Diigo liegen hier in der Einfachheit und der bersichtlichkeit der Informationen. Besonders durch die Tagging-Mglichkeit knnen die Informationen sehr gut strukturiert werden. Die gemeinsame Informationsgenerierung ist ebenfalls gut. Besonders durch die Strukturierung von Bookmarks wird ein Mehrwert durch gezieltes Tagging dieser erzielt. Die Integration fr Smartphones ist ebenso vorhanden, daher die hohe Punktzahl in der Kategorie ortsunabhngige Erreichbarkeit. Die Projektmitglieder konnten jederzeit und von berall aus die Mglichkeit auf die geteilten Lesezeichen zugreifen.

34

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Dezite verzeichnet das Social Bookmarking jedoch in den restlichen Bereichen. Die Durchsuchbarkeit der vorhandenen Informationen ist nur mig gegeben. Zwar knnen Bookmarks nach Schlsselwrtern durchsucht werden, aber der Inhalt der einzelnen Links ist global nicht durchsuchbar. Informationen werden ebenso nur spezielle ausgetauscht, was einen allumfassenden Informationsaustausch nicht gewhrleistet. Die soziale Interaktion ist nicht vorhanden, da Projektmitglieder ber dieses Kommunikationsmittel nicht direkt miteinander kommunizieren knnen, lediglich themenbezogenen Lesezeichen werden ausgetauscht. In dem Bereich der gleichzeitigen Dokumentbearbeitung kann die Technik auch nur mittelmig punkten. Innerhalb von Diigo ist es zustzlich mglich, 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 knnen nur mittelfristig lange gespeichert werden. Beim Lschen oder Verndern 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 ausgeprgt ist. Social Bookmarking ist eine Mglichkeit bereits gefundenes Wissen des Internets zu strukturieren und verfgbar zu machen. Das kann in Projekten von groer Bedeutung sein und speziell bei der Suche nach bestimmten Informationen zeitbezogene Vorteile schaffen. Die Bekanntheit dieser Technik ist gering ausgeprgt und das Potential wird demzufolge nur wenig genutzt. Im Projekt ist es verzichtbar, da es ein sehr spezielles Kommunikationsmittel ist, aber es ist angenehm einzusetzen und bringt oft Vorteile. Im Rahmen der Masterarbeit wurde dieses Mittel

35

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) besonders fr die Quellenarbeit und die Dokumentation eingesetzt. So war es beiden Projektbeteiligten mglich, 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 Mobilfunkanbieters, die auf den Aufenthaltsort des Nutzers abgestimmte Informationen bereitstellen. Diese knnen Einkauf- und Freizeitmglichkeiten sein, Informationen ber Sehenswrdigkeiten, regionale Angebote und Verkehrsdaten, aber auch zur Standortbestimmung bestimmter Personen (vgl. [ITW12]). Standortbezogene Netze sind ausschlielich fr den Markt der Smartphones konzipiert. Damit die abgestimmten Informationen bereitgestellt werden knnen, muss die aktuelle Position des Gertes ermittelt werden. Das kann ber das im Smartphone integrierte GPS-Signal (Global Positioning System) ermittelt werden. Dabei gibt es verschiedene Mglichkeiten. Zum Einen ist die Bestimmung ber die Funkzelle mglich, in der sich jeder Mobilfunkteilnehmer anmeldet. Jede Funkzelle verfgt ber eine eindeutige Identikationsnummer. Darber ist eine grobe Ortung mglich. Jedoch ist dies ziemlich ungenau. Durch den Einsatz von GPRS (General Packet Radio Service) kann die Genauigkeit erhht werden (vgl. [ITW12]). Das bekannteste standortbezogene Netzwerk ist Foursquare. Es erweitert die Funktionalitt eines sozialen Netzwerks. Es kommt bei diesem Dienst die bertragungsmglichkeit von Ortsinformationen der Nutzer hinzu. Dadurch knnen sich Nutzer gegenseitig Orte prsentieren und sich leichter miteinander verabreden (vgl. [Mor]). Weitere Beispiele sind Facebook Places und Qype. Um die Akzeptanz solcher Dienste zu erhhen, wurde in den meisten Umsetzungen eine Spielkomponente eingebaut. Bei Foursquare beispielsweise kann der Nutzer zum Mayor, also zum Brgermeister, 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 vermehrten 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 Erwgung ziehen. Bereits 19 Prozent der sechs Milliarden Mobiltelefonnutzer nutzen 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 ortsunabhngige Erreichbarkeit. Sehr gut sind die Bedienbarkeit und Nutzerfreundlichkeit, also die Einfachheit.

36

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Das Zurckverfolgen von Aufenthaltsorten ist komplett mglich, weshalb es im Bereich Historie volle Punktzahl gibt. Die Informationen sind sehr bersichtlich und knnen 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 Ortsdaten, ebenfalls einen hohen Punktwert sammeln. Die Ortsdaten knnen problemlos von vielen unterschiedlichen Nutzern angegeben und eingesehen werden. Die soziale Interaktion ist nur mittelmig gegeben, da nur ortsbezogene Daten ausgetauscht werden. Weitere Interaktionsmglichkeiten sind nicht mglich. Damit verbunden kann auch der Informationsaustausch nicht komplett punkten. Die Durchsuchbarkeit der vorhandenen Informationen ist nur ber die integrierte Browsersuche mglich, weshalb an dieser Stelle nur drei Punkte vergeben werden knnen. Eine gleichzeitige Dokumentbearbeitung ist nicht mglich, was bei dieser Technik auch keinen Vorteil herbeifhren wrde, da jeder der Nutzer seinen eigenen Standort bermittelt. Dokumente werden hier nicht erzeugt.

Abbildung 2.12.: Eigenschaftsmatrix der standortbezogenen sozialen Netzwerke (Quelle: Eigene Darstellung) Insgesamt kann dieser Dienst viele Punkte sammeln. Das macht ihn fr ein Projekt unverzichtbar. Der groe Vorteil liegt in dem steigenden Verstndnis, an welchem Ort sich Projektmitarbeiter gerade benden. 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 Location Based Service kann dabei Abhilfe verschaffen. Es lsst sich in vielen Fllen rechtfertigen,
29 Darunter

wird die Bewusstheit verstanden, mit der die verteilten Teammitglieder die anderen wahrnehmen und deren Situation einschtzen.

37

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) warum der Projektpartner nicht erreicht werden kann. Es ist ebenso mglich abzuschtzen, 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 Projektmitarbeitern abgestimmt werden, um aufkommenden Konikten diesbezglich entgegenzuwirken. Ein Vorschlag dafr 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 Verstndnis, besonders in Hinblick auf die schwere Erreichbarkeit, verbessert. Der Projektpartner war dadurch immer in Kenntnis, was der Partner gerade tut oder wo er sich aufhlt.

2.8.10. Shared Storage (Autor: Rene Kassel)

Der Begriff Shared Storage beschreibt eine Technik, mit der viele Personen auf ein Netzlaufwerk zugreifen knnen. Es kann mittlerweile mit jedem Rechner ber den integrierten Ethernetport betrieben werden. ber den Port erfolgt ein Zugriff auf den Server, der jeden Beteiligten, 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 groen Hype 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 Projektmitglieder erst mit dem Aufkommen von schnelleren Netzen durchgesetzt. Wohingegen ein Netzwerkordner nur ein passiver Speicher ist, bei dem jeder Aufruf ber das Netzwerk stattndet, sind bei einer Lsung wie Dropbox zustzlich alle Daten komplett als Ordner auf dem lokalen Rechner gespeichert. Im Hintergrund luft ein Dienst, der sich um die Datenhaltung und Synchronisation mit dem Server kmmert. Somit ist gewhrleistet, dass stets der gleiche Datenbestand auf allen eingebundenen Rechnern und dem Server vorhanden ist. Shared Storage gehren zu den Informationstools. Die Abbildung 2.13 zeigt die Eigenschaftsmatrix. Die Punktwerte richten sich ausschlielich nach der verwendeten Lsung Dropbox. Die groen Strken von verteiltem Festplattenspeicher zeigen sich relativ schnell: Es ist ideal fr den Informationsaustausch zwischen mehreren Projektbeteiligten geeignet. Es gibt keine bessere Lsung als die des Shared Storage um eine Vielfalt an Informationen in Form von Dateien auszutauschen. Weiterhin knnen 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 ausgeprgt. Dies wird dadurch gewhrleistet, dass alle Beteiligten die bersichtlichkeit ihrer Daten selber gestalten knnen. Damit verbunden, punktet auch die Eigenschaft Durchsuchbarkeit der
30 Amazon

Simple Storage Service

38

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) vorhandenen Informationen stark. Zum Einen existiert in den meisten Fllen eine Suche31 . Zum Anderen knnen die Daten in einer eigenen Struktur als Ordner im Dateisystem abgelegt werden. Dies erleichtert die Suche nach bestimmten Daten massiv. Eine weitere Strke ist die Einfachheit. Die Lernkurve ist nur sehr gering. Die Nutzer mssen nur wenig Zeit investieren, um die Bedienung und Nutzung zu verstehen, wenn sie schon mit dem Dateimanager arbeiten knnen. Dies erhht die Akzeptanz innerhalb eines Projektes. Es existiert auch Software fr Smartphones oder Tablets, damit Shared Storage im mobilen Gebiet voll und ganz gewhrleistet werden kann. Somit kann der Kommunikationskanal in der Kategorie ortsunabhngige Erreichbarkeit fnf Punkte sammeln32 . Mittelmig ausgeprgt ist der Punktwert fr 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 mglich, nderungen an Dateien bis zum Ursprung zurckzuverfolgen. Die standardmig vorhandene Historie speichert Dateiabbilder lediglich fr die letzten 30 Tage (vgl. [Coma]). Damit knnen Dateien nicht komplett bis zu ihrem Ursprung rekonstruiert werden. Die Mglichkeit zur sozialen Interaktion ist nicht gegeben33 . Die gemeinsame Informationsgenerierung bekommt auch nur zwei Punkte. Informationen werden nicht wirklich generiert und knnen auch nicht durch mehrere Mitarbeiter gleichzeitig geffnet und bearbeitet werden. Sie knnen nur nacheinander bearbeitet werden. Die gleichzeitige Dokumentbearbeitung durch mehrere Nutzer ist also nicht mglich. Shared Storage kann 41 von 60 Punkten bezogen auf alle Eigenschaften sammeln. Es ist ideal fr 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 knnen alle geteilten Informationen von berall aus aufgerufen werden, wodurch die Projektmitarbeiter immer den aktuellen Informationsstand haben. Im Rahmen der Masterarbeit wird, wie schon erwhnt, die spezielle Lsung Dropbox eingesetzt. Dadurch haben die Autoren einen gemeinsamen, synchronisierten Datenbestand. Es dient ausschlielich dem Austausch und der Sammlung von Daten wie e-Books, Workspaces, Abhngigkeiten in Bezug auf das Projekt und verschiedene Textdokumenten.

31 Da

zustzlich Ordner auf der Fetsplatte liegt, kann hier mit allen Mitteln des Betriebssystems durchsucht und indiziert werden. 32 Leichte Abstriche werden gemacht, da mobile Vertrge meist auf ein bestimmtes monatliches Datenvolumen begrenzt sind, was den Einsatz ber das Mobilfunknetz erschwert. 33 Die soziale Interaktion ist nicht der Fokus dieses Tools.

39

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 2.13.: Eigenschaftsmatrix des Shared Storages (Quelle: Eigene Darstellung)

2.8.11. Shared Notes (Autor: Christopher Ezell)

Shared Notes beschreibt eine Technik, welche es ermglicht, private Notizen auf einen Server abzuspeichern und von berall aus darauf zugreifen zu knnen. In der Praxis gibt es viele Implementierungen dieser Technik. Ein sehr bekanntes Notizverwaltungstool ist SimpleNote. Diese Spezialisierung wird im Anschluss nher betrachtet, da sie im Rahmen der Masterarbeit eingesetzt wurde. Die einzelnen Implementierungen unterscheiden sich in ihrem Funktionsumfang sehr stark, was eine allgemeine Beschreibung dieser Technik nahezu unmglich macht. SimpleNote ein einfacher Weg Notizen, Listen, Ideen und vieles mehr abzuspeichern. Fr den Einsatz gibt es verschiedene Grnde: Notizen knnen von berall aus erreicht werden. Sie werden mit dem Smartphone, Computer und jedem aktuellen Webbrowser synchronisiert. Die Synchronisierung luft komplett automatisch und sicher ab. Notizen knnen verffentlicht 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 Verffentlichung von Meeting-Notizen innerhalb einer Firma sind ebenso vorstellbar. Ein weiteres ntzliches Feature ist die Historie. Es werden verschiedene Backups der Notizen abgespeichert und der Nutzer kann einfach ber einen Versionsslider in der Zeit zurck gehen. Es steht gengend Speicherplatz fr die Notizen auf dem Server bereit. Das Organisieren und Sortieren der Notizen ber Tags und Pins ist bei SimpleNote gut mglich. Durch das Setzen von Tags knnen Notizen wie Ordner durchsucht werden. Das Setzen eines Pins fr eine bestimmte Notiz kann diese weit oben in der Notizliste anordnen. Daneben bietet SimpleNote eine Suche. Nach Eingabe des Suchbegriffs wird die Liste von Notizen sofort aktualisiert, sodass nur noch selten wichtige Gedanken oder Notizen verloren gehen.

40

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Eine nchste gute Eigenschaft ist die Erweiterbarkeit. SimpleNote ist eine offene Plattform, fr die eine Menge Programmierer Erweiterungen bereitstellen, um die Plattform an die eigenen Bedrfnisse anzupassen. Die bertragung der Notizen bei der Synchronisation gilt als sicher, da die Notizen verschlsselt bertragen werden. Die vorhandene API von SimpleNote ermglicht eine einfache Integration dieses Dienstes in das eigene Projekt (vgl. [Sim12]. Zur besseren bersicht der eben beschriebenen Features und Abschtzung des Nutzens wurde eine Eigenschaftsmatrix erstellt (siehe Abbildung 2.14). Das Tool wird in die Kategorie der Informationstools eingeteilt. Als klare Strke erweist sich die ortsunabhngige Erreichbarkeit, begrndet durch die Plattformunabhngigkeit und die optimierte Smartphoneintegration. Weitere Strken sind die Historie, die Einfachheit, die bersichtlichkeit und die Durchsuchbarkeit der vorhandenen Informationen. Die Lernkurve ist sehr gerin, da ein Nutzer kaum Wissen bentigt, um ein Tool dieser Technik zu bedienen. Die bersichtlichkeit und Durchsuchbarkeit ist besonders durch das Markieren der Notizen mit Pins und Tags sehr stark ausgeprgt. Das Tool besitzt eine Volltextsuche. Die Langzeitspeicherung der Informationen ist ebenfalls eine Strke. Die gemeinsame Informationsgenerierung ist nicht gegeben, da in der Regel ein Projektmitglied Notizen fr 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 Mglichkeit Notizen untereinander zu verndern bzw. zu ergnzen, aber arbeiten sie gleichzeitig an einem Notizdokument werden nur die nderungen eines Bearbeiters abgespeichert. Dabei handelt es sich um die nderungen des letzten Speichervorganges. Die soziale Interaktion zwischen verschiedenen Projektmitarbeitern ist kaum mglich. Sie knnen lediglich indirekt ber die Notizen miteinander kommunizieren. Fr diese Funktionalitt ist aber dieses Tool nicht vorgesehen. Die Eigenschaft des Informationsaustausches bekommt auch nur wenige Punkte. Mittels dieses Tools werden lediglich Notizen in Textform ausgetauscht, die die Projektpartner informieren soll. An dieser Stelle eignen sich andere Tools wesentlich besser, auerdem liegt der Fokus dieser Technik nicht in dem Bereich des Informationsaustausches. Schlussfolgernd kann gesagt werden, dass sich diese Technik fr bestimmte Zwecke in einem Projekt sehr gut eignet. Besonders in verteilten Projekten ersetzt es den ortsgebundenen Notizblock 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 Integration in das eigene Projekt sehr leicht mglich.

41

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 2.14.: Eigenschaftsmatrix der Shared Notes (Quelle: Eigene Darstellung)

2.8.12. Wiki (Autor: Rene Kassel)

Unter einem Wiki kann eine offene Sammlung von Webseiten bzw. Webinhalten verstanden werden, welche von jeden Nutzer online problemlos und unkompliziert berarbeitet werden knnen. Es bildet eine moderne Form eines Content-Management-Systems (CMS). Durch das Aufkommen dieser Form ist es sogar fr unerfahrene Nutzer leicht mglich Inhalte im World Wide Web zu publizieren. Das Wiki besitzt eine einfache Syntax. Diese dient dazu, Texte lesbarer zu gestalten. Damit ist es einfacher zu schreiben als beispielsweise HTML (vgl. [Prz05]). Es gibt unterschiedliche Implementierungen (Ausprgungen oder Varianten), die die Idee des Wikis implementieren. Im Rahmen dieser Masterarbeit wurde sich fr das MediaWiki entschieden. Die neue Art des CMS hat sich in den letzten Jahren stark durchgesetzt und es hat sich ein breites Feld an Einsatzmglichkeiten etabliert. In den folgenden Gebieten wird es eingesetzt (vgl. [Prz05]): in Installationsanleitungen, Handbchern und FAQs, in technischen Dokumentationen, im Projektmanagement, in Projektbeschreibungen, Zeitplnen, Gesprchsprotokollen und Testergebnissen und in Link-Sammlungen, Notiz-Blcken und ToDo-Listen.

42

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) Daneben gibt es noch weitere Einsatzmglichkeiten. Diese Art von Informationssammlung hat sich nicht nur im privaten Gebrauch durchgesetzt, sondern noch viel mehr im unternehmerischen Anwendungsgebiet. Ein Wiki als zentraler Wissensspeicher hat viele Vorteile fr ein Projekt. Jeder Mitarbeiter34 kann Inhalte einsehen und verndern. Inhalte sind sofort nach dem Verfassen verfgbar und lassen sich von anderen Nutzern abrufen. Gerade fr den unternehmerischen Einsatz sollte die Nutzergruppe eingeschrnkt werden, die schreibenden Zugriff auf gewisse Inhalte hat. Dies ist durch ein vorhandenes Rechtemanagement mglich. 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 Merkmal. 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 Strken dieses Tools liegen in der Mglichkeit des Informationsaustausches, der bersichtlichkeit der vorhandenen Informationen, der Durchsuchbarkeit der Informationen sowie in der Nachvollziehbarkeit von Vernderungen (Historie). Jeder Nutzer kann sein Wissen im Wiki verewigen und verffentlichen, was ebenfalls eine sehr gute gemeinsame Informationsgenerierung ermglicht. Es gibt die Mglichkeiten alle verfassten Artikel im Wiki einzusehen. ber Inhaltsverzeichnisse knnen einzelne Artikel besser strukturiert und berschaubarer werden. Dezite verzeichnet ein Wiki vor allem in den Eigenschaften der sozialen Interaktion sowie der Langzeitspeicherung der Informationen. In einem Wiki sind gespeicherte Informationen stndigen Vernderungen ausgesetzt, was eine Langzeitspeicherung nicht gewhrleistet. Direkte Interaktionsmglichkeiten in Echtzeit gibt es nicht. Zudem ist es mittelmig gut fr die gleichzeitige Bearbeitung geeignet. Zwar knnen viele Nutzer gleichzeitig auf ein Wiki zugreifen, aber die gemeinschaftliche Arbeit an ein und demselben Artikel wird nicht sonderlich gut untersttzt. ndern mehrere Nutzer gleichzeitig einen Artikel, dann werden nur die nderungen eines Benutzers erfasst und gespeichert. Die Modizierungen anderer Nutzer gehen verloren. Es gibt kaum ein Wiki, das an die Echtzeitbearbeitung eines Collaboration Pads heran kommt. Die Lernkurve ist bei diesem Tool etwas hher als bei anderen. Dies hngt 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 ortsunabhngige Erreichbarkeit ist nur mittelmig erfllt. Das Wiki kann von berall aus durch das Internet mittels Webbrowser erreicht und verndert werden. Die Anpassungen an Smartphones und Tablets sind eher suboptimal vorhanden. Die Einsicht in die Artikel ist
34 mit

Zugriff auf das Wiki

43

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell) noch komfortabel mglich, 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 fr den Einsatz des Projektes der Masterarbeit geeignet. Der Dokumentationsaufwand war relativ hoch, bedingt durch die Komplexitt der zu entwickelnden Anwendung und der vielen verwendeten Techniken. Dadurch bildete sich die Notwendigkeit eines zentralen Wissenspeichers. Dafr eignet sich ein Wiki sehr gut. Die Vorteile sprechen fr sich und die Nachteile tangieren das Projekt nur wenig, da das Tool nur durch die beiden Autoren eingesetzt wird. Die Wahl el auf das MediaWiki, weil es den vollen bentigten Funktionsumfang bietet und eine freie Softwarelsung ist. Der vielseitige Einsatz des MediaWikis fr 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 fr Dokumentationen. Zum Teil ist es dafr 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 knnen. Die ffentlichkeit hat keinen Zugriff.

44

2.8. Die ausgewhlten Kommunikationskanle (Autoren: Rene Kassel und Christopher Ezell)

2.8.13. Weitere Tools und eigene Ideen (Autor: Rene Kassel)

Neben den bisher beschriebenen Kommunikationsmitteln existieren noch eine Menge anderer Mglichkeiten zum Einsatz in einem Projekt. Die nher ausgewerteten Techniken zhlen 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 nher beschrieben. Sie sind bereits existenzieller Bestandteil in einem Projekt und stellen keine neue Mglichkeit dar. Der Verzicht auf diese Tools ist jedoch nicht zu denken, da sie wichtige Aufgaben in der Projekterfllung besitzen. Eine eigene Idee erschliet sich aus dem Kapitel 2.7 ber Gamication. Einige Komponenten des Gamication-Ansatzes sollten in der Plattform enthalten sein. Die Integration solcher Bestandteile kann die Mitarbeiter motivieren den sozialen Kontakt zueinander aufrecht zu erhalten und die soziale Bindung zu strken. In dem Artikel Virtuelle Welten als soziale Rume erlutert die Bundesprfstelle fr jugendgefhrdende Medien, dass die Interaktion mit anderen Menschen in einer virtuellen Umgebung und der Austausch von Informationen zu einer hheren sozialen Bindung fhren kann (vgl. [Bun12]). Die Vermischung einiger Komponenten dieses Ansatzes mit einer derartigen Plattform, die im Rahmen der Masterarbeit umgesetzt werden soll, knnte einen groen Mehrwert bieten und vor allem die Nutzung der verschiedenen Mglichkeiten 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 zusammengefhrt. Es wird kurz und prgnant darauf eingegangen, ob die Technik fr die Plattform verwendet wird, ob eine Eigenimplementierung vorgenommen wird und ob eine Integration fr das Smartphone stattndet. Legende: V - Verwendung E - Eigenimplementation S - Smartphone-Integration

45

2.9. Zusammenfassung (Autor: Christopher Ezell) Name Collaboration Pad Wiki Mobile Instant Messaging Remote Pair Programming Blog Microblogging Social Bookmarking Standortbezogene soziale Netzwerke Aufgabenverwaltung Shared Storage Shared Notes Mail Codeverwaltung Screen Sharing Audio-Chat V Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja E Nein Nein Nein Nein Nein Ja Nein Ja Ja Nein Nein Nein Nein Nein Nein S Nein Nein Ja Nein Nein Ja Ja Ja Ja Nein Ja Nein Nein 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 hngt stark davon ab, wie viele Informationen ausgetauscht werden sollen und welche Informationen fr ein bestimmtes Projekt relevant sind. Oftmals werden bestimmte Funktionalitten 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 Einschtzung beim Selbsttest der Kommunikationsmittel vorzunehmen. Resultierend aus den vorhergehenden Betrachtungen und der dabei entstandenen Liste von Kommunikationstools werden im nchsten Kapitel die verschiedenen User Stories deniert. Diese beschreiben die Funktionalitten, die die zu implementierende Plattform enthalten soll.

2.9. Zusammenfassung (Autor: Christopher Ezell)

In diesem Kapitel wurde die Kommunikation innerhalb von verteilten Teams erlutert. Es wurden Informationsarten und die Einteilung von bestimmten Kommunikationstools gezeigt. Des Weiteren wurde aufgezeigt, dass auch zwischenmenschliche Faktoren zu den Erfolgsfaktoren eines Teams zhlen. Bezogen auf diese Faktoren wurden anhand von Studien Probleme beschrieben, die innerhalb eines Projektes zwischen verschiedenen Mitarbeitern aufkommen knnen mit besonderer Bercksichtigung auf verteilte Projektgruppen. Es wurde gezeigt, wie wichtig die Kommunikation in Projekten ist. Zudem wurde ersichtlich, dass bestehende Softwarelsungen fr verteiltes Arbeiten nicht ausreichend Funktionsumfang bieten, um den kompletten Anforderungen an einem verteilten Projektteam gerecht zu werden. Weiterhin wurde

46

2.9. Zusammenfassung (Autor: Christopher Ezell) auf die Thematik der Gamication eingegangen und gezeigt, dass auch mit spielerischen Elementen positiv auf die Motivation von Teammitgliedern eingewirkt werden kann. Am Ende dieses Kapitels erfolgte eine genaue Betrachtung und Analyse ausgewhlter Kommunikationskanle. Aus dieser Analyse heraus entstand eine Liste von Kommunikationsmitteln, welche in einem verteilten, agilen Projekt als wichtig erachtet werden. Alle bisherigen berlegungen, inklusive der entstandenen Liste, sind die Basis fr diese Ausarbeitung und sind ausschlaggebend fr die darin realisierten Ideen. Fr das Verstndnis der Umsetzung einer solchen Lsung sind jedoch einige grundlegende Sachverhalte zu erlutern, besonders technische Grundlagen. Diese werden im nchsten Kapitel (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 ntig, um den weiteren Verlauf dieser Arbeit zu verstehen. Zunchst 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 ntige Rstzeug, die weitere Arbeit im technischen Sinne verfolgen zu knnen. Kapitel 3.2 zeigt eine allgemeine bersicht zu den verwendeten Basistechnologien. Im darauffolgenden Kapitel 3.3 werden dem Leser Grundlagen zu iOS und Objective-C nher gebracht. Kapitel 3.4 behandelt die Grundlagen einzelner Mglichkeiten zur Verbesserung der Qualitt des geschriebenen Codes. Im letzten Unterkapitel 3.5 wird ein grundlegendes Verstndnis fr die Verwendung der Build-Plattform bermittelt.

3.1. Agile Softwareentwicklung (Autor: Christopher Ezell)

Die Umsetzung der vorliegenden Masterarbeit orientiert sich an Praktiken der agilen Softwareentwicklung35 . Aus diesem Grund werden kurz die Arbeitsweise, die Grundwerte und einige Basistechniken beschrieben. Zunchst ist es wichtig, ein Verstndnis dafr 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 erklrt, 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 deniert, was unter dem Begriff agil zu verstehen ist (vgl. [et.12]). Es stellt die Grundideen hinter der Praxis der agilen Softwareentwicklung dar und deniert Grundwerte, die immer eingehalten werden sollten. Manifest fr die agile Softwareentwicklung Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Lauffhige Software ist wichtiger als umfangreiche Dokumentation.
35 In

[agi09] ndet sich eine Beschreibung warum agile Praktiken gut sind.

48

3.1. Agile Softwareentwicklung (Autor: Christopher Ezell) Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Eingehen auf Vernderungen ist wichtiger als Festhalten an einem Plan. Diese Grundwerte des agilen Entwicklungsprozesses machen deutlich, wie wichtig die Menschen 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 Kollaborationstool muss diesen Anforderungen gengen und muss sehr leicht und intuitiv zu bedienen sein. Dies wurde bei der Konzeption der Plattform bercksichtigt.

3.1.2. User Stories

Eine User Story, auch als Anwendererzhlung bezeichnet, ist eine in Alltagssprache denierte Beschreibung von Funktionalitten einer Software. Die Erfllung der Software einer User Story stellt dabei einen Mehrwert fr den Benutzer oder Kufer einer Software dar. Der grundlegende Aufbau einer User Story ist generell festgelegt und sieht folgendermaen aus: Als <Rolle> mchte ich <Ziel/Wunsch>, um <Nutzen>. Ein sehr wichtiger Bestandteil von User Stories sind die Aktzeptanzkriterien36 (vgl. [CHH10]). Diese werden von anderen Autoren auch Erwartungen genannt (vgl. [Coh04]). Diese beschreiben im Allgemeinen zustzliche Rahmenbedingungen und Spezialflle, die es dem Entwickler ermglichen Tests zu schreiben. William Wake erstellte 2003 in seinem Blog-Post INVEST in Good Stories, and SMART Tasks [inv03] die INVEST-Kriterien37 fr gute User Stories. Diese Kriterien mssen User Stories erfllen, um optimal umgesetzt werden zu knnen. Diese sind die folgenden: I Independent (unabhngig): Es sollten mglichst keine Abhngigkeiten zwischen den User Stories geben. N Negotiable (verhandelbar): User Stories sollten schriftliche Vertrge oder Anforderungen sein, die die Software erfllen muss. V Valuable (werthaltig): Jede User Story sollte fr den Kunden einen Mehrwert fr die Anwendung darstellen. E Estimable (schtzbar): Die User Story sollte so erstellt worden sein, dass sie fr den Entwickler schtzbar ist. S Small (klein): Die richtige Gre von User Stories erhht die Planbarkeit ihrer Umsetzung. T Testable (testbar): User Stories mssen so geschrieben sein, dass durch einen Test verizierbar ist, ob die Story erfolgreich implementiert wurde (vgl. [CHH10]). Die Autoren haben ihre User Stories aus Kapitel 4 daran orientiert.
36 auch

37 Independent,

Conditions of Satisfaction (COS) genannt Negotiable, Valuable, Estimable, Small, Testable

49

3.1. Agile Softwareentwicklung (Autor: Christopher Ezell)

3.1.3. Scrum
Hier wird auf das agile Management-Framework Scrum eingegangen. Scrum dient als Grundlage fr die Entwicklung dieser Plattform und die denierten Prozesse haben die Autoren zum Verwalten des Projektes genutzt. Denition Scrum Das agile Management-Framework Scrum stellt heute den bekanntesten agilen Vertreter dar, weil es durch seine einfache Struktur und die klar denierten Rollen schnell verstndlich ist und sich produktiv einsetzen lsst. [HW11] In Scrum wird innerhalb eines Teams tglich ein Meeting zu einem festen Zeitpunkt gehalten. Dies ist das sogenannte Daily Scrum. Dieses Meeting dient zur Interaktion und Synchronisation im Team. Es teilt sich generell in zwei Teile. Der erste Teil besteht aus einem festen Ablauf, den jeder im Team durchluft. 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 nchsten Daily Scrum tun? Hier knnen sich Fragen und Diskussionen ergeben. Diese sind gewollt und wichtig und kommen im zweiten Teil des Meetings zum Tragen, dem sogenannten Ofine-Teil. Hier knnen nun alle ihre Probleme und Neuigkeiten erzhlen und es kann diskutiert werden. Trotzdem sollte ein Daily Scrum insgesamt nicht lnger als 15 Minuten dauern. Scrum deniert feste Rollen, die im Team besetzt werden mssen. Diese verschiedenen Rollen haben verschiedene Aufgaben zu erfllen. Eine bersicht ber Scrum ndet sich in Abbildung 3.1. Die verschiedenen Rollen sind nach ([Pic07], S.13) folgende: Product Owner (PO): Der Product Owner in Scrum reprsentiert die Endkundenbedrfnisse, 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 fhrt alle Arbeiten aus, die zur Umsetzung der Anforderungen in auslieferbare 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

38 Manchmal

werden Sprints auch Iterationen genannt (vgl. [Pic07], S.81).

50

3.1. Agile Softwareentwicklung (Autor: Christopher Ezell)

Abbildung 3.1.: Scrum auf einem Blick (Quelle: [HW11], Seite 7) vier Wochen haben sollte. Generell sollten alle Aktivitten, welche in einem Scrum-Team erledigt werden, sich in einem denierten Sprint benden. Um einen Scrum gut durchfhren zu knnen, muss ein Team selbstorganisiert sein. Selbstorganisierte Teams sind Teams, die keine Hierachien enthalten, die den Fluss an Information behindern. Ein Team ist nicht selbstorganisiert, wenn z.B. alle Aktivitten vorher mit einem Teammitglied abgestimmt werden mssen. Ein Team muss sich in den Grenzen ihrer Programmierung frei bewegen knnen und selbst entscheiden wie sie eine Aufgabe lsen. Eine Mglichkeit in Scrum Aufwnde zu schtzen stellt das Planning-Poker dar. PlanningPoker wird von James Grenning in ([Gre], S.1) wie folgt beschrieben: Denition 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 programmers 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 deniert ein Schtzverfahren, in dem die Komplexitt einer Aufgabe mit Punkten bewertet wird. Es soll durch den Ablauf fr eine Diskussion sorgen, die alle Beteiligten zu einem besserem Verstndnis der Aufgabe fhren soll. Der Ablauf ist der folgende. Das Entwicklerteam 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 Komplexitt zu welchem Wert gehrt, kann das jeweilige Team

51

3.1. Agile Softwareentwicklung (Autor: Christopher Ezell) entscheiden. Fest steht nur, dass die niedrigen Werte fr niedrige Komplexitt und die hohen fr hohe stehen. Wichtig ist, dass die hheren Zahlen in ihrer Wertigkeit weit auseinander liegen39 . Jedes Teammitglied hat dieselbe Anzahl und Wertigkeiten von Karten. Es kann nun von jedem selbststndig die Komplexitt der vorgelesenen Story eingeschtzt 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 hchsten Wert hat. Diese mssen jetzt diskutieren, warum ihre Meinung richtig ist. Hier entsteht nun ein Gesprch, bei dem Kontextinformationen und Fallstricke zu tage kommen. Dies ist sehr wichtig fr alle im Team und hat so einen Mehrwert. Das befhigt wiederum die Mitglieder, eine bessere Schtzung als vorher abzugeben. Nun wird die Runde wiederholt und es werden wieder Karten neu von jedem gelegt. Dies passiert, bis alle denselben Wert legen. Damit sich alle ber die Komplexitt der Aufgabe einig sind (vgl. [Gre]).

3.1.4. Verteilte agile Teams

Scrum an sich deniert keine Verteilung der Leute. Es sagt nichts darber aus, ob die TeamMitglieder alle an einem Standort sind oder verteilt. Aber durch die denierten Prozesse ist es sehr schwer, dies ohne viel Mhe in eine verteilte Umgebung zu etablieren40 . Trotzdem ist es die Grundidee vieler agiler Anstze, das sich alle an einem Standort zum arbeiten Treffen. Nur dadurch ist es mglich das volle Potential der agilen Entwicklung auszuschpfen. In greren und komplexeren Projekten ist dies nicht immer mglich, vor allem dann, wenn der Kunde und das Team lokal weitrumig 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 durchzufhren. Die Koordination der Arbeit in einem verteilten, agilen Team ist eine groe Aufgabe. Das steht im engen Zusammenhang damit, dass im Allgemeinen agile Softwareentwicklung sehr kommunikationsintensiv ist. Vertrauen innerhalb des Teams ist ein entscheidender Erfolgsfaktor. Es sollte deniert werden, was in einem verteiltem Team die grundlegenden Eigenschaften sein sollen und diese versuchen durch meist technische Lsungen zu erhalten. Die Schaffung eines vertrauensvollen Klimas in einer verteilten Umgebung ist eines der schwierigsten Teile. Es sollen alle Teammitglieder miteinander interagieren, besonders jene, die sich an unterschiedlichen Standorten benden. Oft ist es jedoch so, dass eine selektierte Kommunikation mit den Mitarbeitern desselben Standortes und nur selten eine grere Kommunikation mit den entfernen Mitarbeitern stattndet. Dieses Problem gibt es also zu lsen.

39 dies Spiegelt die Tatsache wieder, dass kleine Aufwnde mit den unteren Zahlen besser geschtzt werden knnen 40 siehe

als groe. Hier sollte es deswegen nur grobe Werte geben. [Eck09]

52

3.2. Technologien (Autor: Rene Kassel)

3.2. Technologien (Autor: Rene Kassel)

Nachdem die Grundlagen der agilen Softwareentwicklung erlutert wurden, wird nun auf die im Projekt verwendeten Techniken nher eingegangen. Dabei wird sich auf ausgewhlte Techniken beschrnkt. Nicht betrachtet werden zum Beispiel Java-Grundlagen, da dies sehr umfangreich zu den Lehrinhalten vieler Fachhochschulen und Universitten gehrt. Genauer betrachtet werden jedoch die Grundlagen von iOS- und Objective-C -bezogenen Themen. Dies ist darauf begrndet, 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 Beschreibung von Dokumenten. XML wurde ursprnglich entwickelt, um der neuen Herausforderung 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 exibles Textformat, welches aus SGML41 (ISO 8879) abgeleitet wurde und Daten beschreibt (vgl. [W3C03]). Das W3C42 hat es im Jahr 1998 erstmals genauer speziziert. Die neueste Auage 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 vordeniert, es knnen eigene Tags deniert 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 schlieenden Tag. Die Struktur einer XML-Datei kann durch ein Schema deniert werden. Ein XML-Schema ist die Denition von Regeln (vgl. [MS07] Seite 17), die die erlaubten Daten und die Struktur einer XML-Datei einschrnken knnen. Es ist mglich eine XML-Datei mit einem Schema zu validieren. Hierdurch kann ermittelt werden, ob eine XML-Datei einem Schema entspricht (vgl. [MS07], Seite 17).

41 Standard 42 World

Generalized Markup Language Wide Web Consortium

53

3.2. Technologien (Autor: Rene Kassel) Das Beispiel 3.1 zeigt die allgemeine Struktur eines XML-Dokumentes. Listing 3.1: Beispiel fr XML
1 2 3 4 5 6 7 8 9 10 11

<telefonbucheintraege> <titel>Telefonbuch</titel> <beitrag> <name>Max Mustermann</name> <nummer>12345698765</nummer> </beitrag> <beitrag> <name>Frida Frau</name> <nummer>05456798765</nummer> </beitrag> </telefonbucheintraege> Die erste Zeile ist eine XML-Deklaration. Der Knoten

<telefonbucheintraege> beschreibt das Wurzelelement. Die nchsten Elemente <titel> und <telefonbucheintraege> sind die Kind-Elemente und sind dem Wurzelelement untergeordnet. Das Element <telefonbucheintraege> hat mehrere Kindelemente 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 exibel mit Hilfe dieser Tags beschrieben. Sie sind beliebig erweiterbar.

3.2.2. Java Architecture for XML Binding

Die Java Architecture for XML Binding (JAXB) ermglicht es dem Java Entwickler optimal mit XML interagieren zu lassen. Es deniert eine API43 zur Transformation von XML-Objekten zu Java-Objekten und umgekehrt. JAXB hat den Anspruch eine API zu bieten, die weit abstrakter und komfortabler ist als sie bei SAX44 und DOM45 mglich 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 enthlt und die Portable Java 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
43 Application 44 Simple

Programming Interface API for XML 45 Document Object Model 46 Die Abbildungen A.5 und A.8 stellen diesen Prozess der Schema-Kompilierung nochmal im Detail dar.

54

3.2. Technologien (Autor: Rene Kassel) stellt die zugrunde liegende XML in Form von Java Klassen dar (vgl. [MS07], Seite 6). JAXB 2.0 stellt also eine gute Transformationsmglichkeit 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 Spezikation kann auf http://www.rssboard.org/rss-specification gefunden werden. Die Idee hinter RSS ist eine Art Kanal von Nachrichten. Dieser Kanal hat mehrere Eintrge. Der Kanal wird von Client in regelmigen Intervallen gelesen. Es ist also ein pullVerfahren, da der Client aktiv die Informationen holen muss.

3.2.4. JavaScript Object Notation

Die JavaScript Object Notation (JSON) ist ein schlankes, textbasierte Format fr den Datenaustausch 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 Eigenschaft von JSON ist, dass es komplett sprachunabhngig ist. Viele Sprachen bringen bereits ntige Frameworks mit, um JSON-Objekte zu interpretieren und in die eigene Struktur umzuwandeln. Damit ist es ideal fr den Austausch von Daten zwischen verschiedenen Sprachen geeignet (vgl. [Jso]). JSON kann vier primitive Datentypen und zwei strukturierte Datentypen reprsentieren. Erstere knnen Zeichenketten (Strings), Zahlen (Numbers), boolesche Werte (Booleans) oder Nullwerte (Null) sein. Zweitere sind Objekte und Arrays. Ein Objekt ist eine ungeordnete Zusammenfassung 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 kommen von den Konventionen von JavaScript. Ein Array ist mit den Zeichen [] umschlossen. Ein Objekt wird durch geschweifte Klammern abgegrenzt.

47 Request 48 Es

for Comments ist speziell deniert in dem Programmierstandard ECMA (European Computer Manufacturers Association) der dritten Generation.

55

3.2. Technologien (Autor: Rene Kassel) Das folgende Beispiel 3.2 zeigt ein Array mit zwei Objekten. Listing 3.2: Beispiel fr JSON (Quelle: [Gro06])
1 2 3 4 5 6 7 8 9

[ { "Latitude": 37.7668, "Longitude": -122.3959, "City": "SAN FRANCISCO", "Country": "US" }, { "Latitude": 37.371991, "Longitude": -122.026020, "City": "SUNNYVALE", "Country": "US" } ] Im Gegensatz zu XML ist JSON wesentlich berschaubarer und leichter lesbar durch den Menschen. 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 hherer Aufwand notwendig. Die Navigation in einen JSON-Objekt ist wesentlich schmaler und einfacher als jene in einer XML-Struktur. JSON untersttzt jedoch nur einige grundlegende Datentypen. XML hingegen weist mehr Flexibilitt bezglich der Typen auf. Fr einfache Flle 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 fr Webanwendungen. Es deniert eine Art und Weise wie auf Objekte ber das Web zugegriffen werden kann. Erfunden wurde der Begriff REST von Roy T. Fielding49 . Fr diese Art von Zugriff auf Ressourcen im Web erfand er diesen Begriff fr 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 protieren zu lassen. Ein Vorteil von REST ist, dass auf etablierte Standards, wie z.B. die HTTP-Statuscodes, zurckgegriffen werden kann. Dies wird von vielen Anwendungen bereits untersttzt und muss nicht selber programmiert werden. Die Statuscodes knnen bei der Verwendung von REST zur Kommunikation zwischen Client und Server genutzt werden. Um REST besser zu verstehen, werden im folgenden die fnf
49 Er

zhlt zu den Kernentwicklern einer hohen Zahl von Webstandards. Er gehrt zu den ehemaligen Vorsitzenden der Apache Software Foundation. 50 Uniform Resource Locator 51 Das HTTP-Protokoll wird deniert im RFC 2616 (vgl. [Fie99a]).

56

3.2. Technologien (Autor: Rene Kassel) Kernprinzipien einer REST-Architektur aufgelistet und anschlieend nher erlutert. Auf die beiden Aspekte der Unterschiedlichen Reprsentationen und Statuslosen Kommunkation wird nicht weiter eingegangen, da diese fr die Arbeit nicht wichtig sind. Sie sollten nur der Vollstndigkeit halber genannt werden. Die fnf Kernprinzipien von REST sind nach [Til11]: Ressourcen mit eindeutiger Identikation, Verknpfungen/Hypermedia, Standardmethoden (fr die Interaktion), Unterschiedliche Reprsentationen und Statuslose Kommunkation. Der erste Punkt Ressourcen mit eindeutiger Identikation ist die Basis einer REST-Anwendung. Die Idee dahinter ist, dass jede Anwendung ein Set an Ressourcen besitzt, was die Basis fr alle Anderen bildet52 . Diese werden auch Kernkomponenten genannt. Kernkomponenten sind in einer REST-Anwendung ber eine eindeutige URL verfgbar. 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 hierfr. 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 zurck gegeben. Dies ist so, da der Wurzelknoten aller User aufgerufen wird und dieser alle darunter liegenden Knoten vom Typ User bekommt. Hingegen reprsentiert die zweite URL nur einen einzelnen User. Wird also diese URL aufgerufen, wird nur dieser eine User (vgl. [Til11]) zurckgegeben. Die dritte URL ruft alle Events zu dem bergebenen Datum auf. Bei dem Punkt Verknpfungen/Hypermedia geht es darum, dass durch die eindeutige Referenzierbarkeit der Objekte auf diese von anderen Knoten aus verwiesen werden kann. So ist es mglich sehr elegant Daten innerhalb einer REST-Domne zu verbinden. Wenn ein Event zum Beispiel einem User zugeordnet ist, muss in dem Event nur die URL des Users angegeben werden. 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 fr URLs bei REST
1 2 3

http://example.com/users/ http://example.com/users/1234 http://example.com/events/2012/12/24 Durch die Standardmethoden erhlt das REST-Modell seine Dynamik. Sie denieren die Interaktionsmglichkeiten, die mit REST mglich sind. Diese werden bei REST Verben genannt. Es gibt zur Zeit die Verben GET, PUT, POST, DELETE, OPTIONS, TRACE und CONNECT.
52 In

einem Warenlager sind das zum Beispiel die Lager und die Waren.

57

3.2. Technologien (Autor: Rene Kassel) Bei GET handelt es sich um eine der grundlegenden und wichtigsten Verben. Es dient dazu, die Informationen hinter der Ressource in einer Reprsentationsform abzufragen53 . Laut den Prinzipien von REST, ist die GET-Operation als safe deklariert. Es werden also Serverseitig keine Informationen der Ressource bei diesem Aufruf verndert. 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 hierfr 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 Mglichkeit, neue Ressourcen anzulegen. Jedoch handelt es sich bei dieser zweiten Mglichkeit um ein Standardmuster zum Neuanlegen einer Ressource, wofr auch ein HTTP-Statuscode existiert55 . Das nchste wichtige Verb ist DELETE. Dies ist fr das Lschen einer Ressource zustndig. Es wird jene Ressource gelscht, deren URI im Request angegeben wird (vgl. [Til11]). Auf die Verben Options, Trace und Connect wird hier nicht nher eingegangen. Ein sehr mchtiges Kommunikationsmittel in der Welt von REST sind die im HTTP-Standard denierten Statuscodes (vgl. [Fie99b]). Statuscodes sind Nummern zwischen 100 und 505, die der Server als Antwort auf eine Anfrage des Clients zurcksenden kann. Hinter jedem dieser Codes ist eine Aussage ber den Zustand des Servers zu der Anfrage deniert. Diese Zustnde sind in fnf groe Blcke unterteilt. Block eins (Codes zwischen 100 und 199) umfasst die Codes mit dem Marker Informational. Das bedeutet, dies sind Codes um den Client zustzliche Informationen zu geben. Ein Beispiel dafr ist der Code 100 - Continue. Dieser signalisiert dem Client, dass sein Request noch nicht vollstndig ist und der Server eine Fortsetzung erwartet. Der zweite Block beginnt bei 200 und endet bei 299. Dieser Block deniert Codes, die Auskunft darber 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 zurckgesendet wird, abhngig 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 nchste Block, Codes zwischen 300 und 399, hat den berbegriff Redirection. Die Klasse von Statuscodes zeigt an, dass weitere Aktionen durch den User-Agenten durchgefhrt werden mssen, damit die Anfrage vollstndig bearbeitet werden kann. Der darauffolgende Block, zwischen 400 und 499, ist mit dem berbegriff Client Error beschrieben. Dieser beinhaltet Fehler, die vermutlich durch den Client verursacht wurden.
53 Generell

kann eine Ressource beliebig viele Reprsentationsformen besitzen (wie zum Beispiel XML, JSON, TEXT 54 Uniform Resource Identier 55 Dieser ist 201 Created.

58

3.2. Technologien (Autor: Rene Kassel) Der letzte Block ist das Pendant zu dem vorhergehenden. Er besitzt den Marker Server Error. Diese Statuscodes werden gesendet, wenn der Server sich bewusst ist, dass er einen Fehler verursacht hat oder wenn der Server eine Anfrage nicht mehr beantworten kann.

3.2.6. Extensible Messaging and Presence Protocol

Extensible Messaging and Presence Protocol (XMPP) ist ein offenes und standardisiertes Protokoll zur Echtzeitkommunikation basierend auf XML (vgl. [Mag11], Seite 3). Es ermglicht die Interaktion in Form von Textnachrichten. Der Kern von XMPP ist ein Instant Messaging Protokoll. Denition XMPP The Extensible Messaging and Presence Protocol (XMPP) is an open technology for realtime communication, using the Extensible Markup Language (XML) as the base format 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 eigentlichen Funktionalitt wie zum Beispiel eine Kontaktliste oder die Mglichkeit Bilder zu versenden, Screen-Sharing sowie eine Audio-Chat Funktionalitt56 . 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 fr eine Nachricht in XMPP (Quelle: [SAST09])
1 2 3

<message from="tesuser1@test.lit" to="tesuser3@test.lit"> <body>hello world</body> </message> In der Arbeit wird dieses Protokoll fr viele Interaktions- und Kommunikationsmglichkeiten 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 Datenbank 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 fr Java. Dabei handelt es sich nicht um ein fertiges Framework, sondern lediglich um eine Spezikation [. . . ] [MW08]
56 siehe

http://xmpp.org/extensions/

59

3.2. Technologien (Autor: Rene Kassel) Es muss also noch eine passende Implementierung fr das JPA-Framework gewhlt werden. Hier gibt es viele Anbieter wie Eclipse-Link [ecl12] und Hibernate [MW08]. In dieser Arbeit wurde sich fr 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 OnlineDateisystem ermglicht. Es ist im aktuellen RFC 5689 von 2009 speziziert (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, grasche Codes (sogenannte 2D-Barcodes), die zur Speicherung von Informationen dienen (vgl. [Win11]). Er kann sich in zwei Dimensionen ndern. Dabei zeigt er Informationen in einem schwarz-wei Muster an. Ein Beispiel dafr ist in Abbildung 3.2 zu sehen. Dieser QR-Code enthlt den task:1336505994864. Dies stellt eine Tasknummer dar, die von der implementierten Plattform generiert wurde. QR-Codes sind eine Variante von 2D-Barcodes. Ein weiteres Beispiel fr 2D-Barcodes ist der Aztec-Code im Anhang 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)

57 Quick

Response Codes

60

3.3. iOS und Objective-C (Autor: Christopher Ezell)

Abbildung 3.3.: QR-Code Vergleich (Quelle: [Win11])

3.3. iOS und Objective-C (Autor: Christopher Ezell)

Da Objective-C , im Vergleich zu Java, eine ungewhnliche Lese- und Schreibweise hat, wird in diesem Kapitel dem Leser eine kleine Einfhrung in die Programmierung mit Objective-C gegeben. Es wird zuerst auf die Struktur von Methoden und deren Aufruf eingegangen. Anschlieend wird in den Unterkapiteln kurz auf verschiedene Aspekte der Sprache eingegangen.

3.3.1. Die Methodensignatur in Objective-C

Die Methodensignatur in Objective-C ist darauf ausgelegt den anschlieenden Methodenaufruf wie einen Satz aussprechen zu knnen. Es soll mglich sein, den Quellcode auf eine natrlichere Weise lesen zu knnen als bei anderen Programmiersprachen. Der Kerngedanke 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 Objekte gesendet. Diese Nachrichten werden Messages genannt, dynamisch verarbeitet und innerhalb 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 aufgerufen. Listing 3.5: Objective-C Methodensignatur
1

[receiver message];

61

3.3. iOS und Objective-C (Autor: Christopher Ezell) Ein Beispiel fr die Denition 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 . Auerdem hat sie einen Rckgabe-Parameter des Typs BOOL. Dies ist der Variablentyp fr 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 3

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *) launchOptions; Listing 3.7: Aufruf einer Methode in Objective-C

1 2 3 4 5 6

NSObject *tempObject = [[NSObject alloc] init]; NSDictionary * dict = [NSDictionary dictionaryWithKeysAndObjects:@"testKey", @"testValue", nil]; BOOL boolean = [self testObject:tempObject 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 deniert ist und die eigentliche Implementierung 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 enthlt die Deklarationen von Variablen, Properties und Methoden. Ein Interface beginnt mit dem Schlsselwort @interface61 und endet mit dem Schlsselwort @end (vgl. [AM11], Seite 101). Ein Beispiel fr ein Interface ist in Listing 3.8 dargestellt.

handelt es sich um einen Zeiger auf ein Objekt vom Typ UIApplication handelt es sich um einen Zeiger auf ein Objekt vom Typ NSDictionary. Ein NSDictionary ist eine Hashmap von Java in Objective-C . 60 Methoden die hingegen ein + haben, knnen auch an das Klassenobjekt gesendet werden. 61 Das Schlsselwort steht nach dem Importieren der bentigten Headers und Frameworks.
59 Dabei

58 Dabei

62

3.3. iOS und Objective-C (Autor: Christopher Ezell) Listing 3.8: Beispiel fr ein interface in Objective-C
1 2 3 4 5 6 7 8 9

#import <Foundation/Foundation.h> #import "MyProtocol.h" #import "MyClass.h" @interface MyClass : NSObject <MyProtocol>{ } @property (strong, nonatomic) UIWindow *window; @property (readonly, strong, nonatomic) NSManagedObjectModel * managedObjectModel; - (void)method; - (NSString *) getResultWithContentString:(NSString *) contentString; @end Dieses Interface deniert ein Interface fr eine Klasse mit dem Namen MyClass. Diese erbt von der Klasse NSObject und besitzt zwei in Objective-C so geannte properties. Properties sind Variablen des Objektes, auf die von auen zugegriffen werden kann. Um dies zu gewhrleisten, werden die Getter- und Setter-Methoden von dem Compiler erzeugt. Die Implementierung der Klasse ist in Listing 3.9 dargestellt. Listing 3.9: Die Implementierung der Klasse MyClass

10 11 12

13 14

1 2 3 4 5 6

#import "MyClass.h" @implementation MyClass @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 Schlsselwort @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 knnen nun die im Interface deklarierten Methoden implementiert werden. Neben Interfaces existieren noch die Protokolle. Der Unterschied zwischen ihnen liegt darin, dass ein interface immer ein ganz spezielles Objekt mit all seinen Variablen und Me-

63

3.3. iOS und Objective-C (Autor: Christopher Ezell) thoden beschreibt62 . Ein protocol hingegen ist eine allgemeine Beschreibung einer Funktionalitt, also die Beschreibung einer Rolle. Diese kann von einem Objekt eingenommen werden, wenn dieses Objekt dieses Protokoll implementiert. Auch ein Protokoll hat die Endung .h, startet mit dem Schlsselwort @protocol und endet mit dem Schlsselwort @end (vgl. [AM11], Seite 167). Ein Beispiel fr ein Protokoll ndet 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 Methode optionalMethod2. Ein Objekt, dass nun diesem protocol entsprechen mchte, muss mindestens die erste Methode method1 implementieren, kann aber die zweite Methode optionalMethod2 weglassen. Listing 3.10: Beispiel fr ein protocol in Objective-C
1 2 3 4 5

@protocol MyProtocol<NSObject> - (void)method1:(NSString *)myString; @optional - (void)optionalMethod2:(NSString *)myString2; @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 fr verschiedene Objekte Kurzschreibweisen und Sonderregeln. Ein sehr populrer 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 stndige Erzeugen eines Strings aber sehr umstndlich wre, gibt es speziell fr 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 fhren: Da Objective-C eine echte Obermenge der Sprache C ist63 (vgl. [Kol10], Seite 56), knnen alle Variablentypen von C benutzt werden. So ist es mglich, 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 Grobuchstaben) benutzt werden.

62 so

63 Dadurch

wie eine Header-Datei zu einer Implementierung bei C ist es mglich alle in C geschrieben Programme auch in Objective-C zu kompilieren.

64

3.3. iOS und Objective-C (Autor: Christopher Ezell) Listing 3.11: Erzeugung eines Strings in Objective-C
1 2

const char *test= "Hallo Welt"; NSString *string = [[NSString alloc] initWithUTF8String: test]; Listing 3.12: Erzeugung eines Strings in Objective-C mittels Kurzschreibweise

NSString *string = @"Hallo Welt";

3.3.3. Delegates
Delegates sind ein zentraler Bestandteil der iOS-Plattform und werden an diversen Stellen zur Umsetzung von Funktionalitt eingesetzt. Das Konzept der Delegation kann dafr 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 Fllen wird die Umsetzung dieser Aufgaben an ein anderes Objekt delegiert. Dieses sogenannte Delegate kann nun selber bestimmen, wie die aufgetragene Aufgabe umgesetzt wird. Viele Klassen in Objective-C besitzen hierfr ein Attribut delegate (vgl. [Kol10], Seite 102). Dieses kann zur Laufzeit mit einem anderem DelegateObjekt ausgetauscht werden und so die Funktionalitt zur Laufzeit des Programms gendert 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 Ereignis durchluft, wird die entsprechende Methode des Delegate-Objekt aufgerufen. Die meisten 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 deligierenden Klasse und einem Parameter, in dem das Objekt der delegierenden Klasse bergeben 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 2

- (void)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)options;

65

3.3. iOS und Objective-C (Autor: Christopher Ezell)

3.3.4. Key-Value-Observing
Ein groes Thema in allen Applikationen, die ber eine Benutzeroberche verfgen, ist wie und wann die Oberche mit einem Update der zugrunde liegenden Daten versehen wird. Dies sollte sehr schnell passieren, da veraltete Daten in der Oberche zu inkonsistenten Handlungen des Benutzers fhren knnen64 . In Objective-C gibt es mit dem sogenannten Key-ValueObserving (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 zunchst eine Registrierung des berwachten Objektes beim Observer. Hier wird als eine gewisse property eines Objektes verwiesen. Nun wird bei einer nderung dieser Property ein der Observer benachrichtigt. 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 bergeben66 . Listing 3.15 zeigt die Funktion, welche aufgerufen wird, wenn sich die beobachtete Property ndert. Listing 3.14: Registrierung eines Observer
1 2 3 4

[self addObserver:self forKeyPath:@"model.text" options:NSKeyValueObservingOptionNew context:nil]; Listing 3.15: Aufruf der Methode bei nderung eines Wertes

1 2 3 4 5 6 7 8 9

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context { NSLog(@"%s", __PRETTY_FUNCTION__); NSLog(@"%@", keyPath); }

64 Dies 65 also

kommt zum Beispiel vor, wenn ein Benutzer einen Datensatz bearbeiten will, der gar nicht mehr existiert. das aktuelle Objekt 66 also nil

66

3.3. iOS und Objective-C (Autor: Christopher Ezell)

3.3.5. Struktur und Lebenszyklus einer iOS-Applikation

Nachdem die grundlegenden Techniken der Sprache Objective-C und der iOS-PLattform erlutert wurden, ist es vom Vorteil den generellen Lebenszyklus einer iOS-Applikation zu verstehen. 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 Speicher der Plattform bendet. Dabei hlt 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 deniert. Das protocol deniert nun eine Reihe von optionalen Methoden, die eine Klasse, die dieses protocol implementiert, berschreiben und somit erweitern kann. Listing 3.16 zeigt nun ausgewhlte Methoden dieses Protokolls. Abbildung A.10 zeigt die Aufrufe in zeitlicher Beziehung zueinander. Im nachfolgenden wird der einfache Fall des Startvorganges erlutert. Nach dem Starten der Applikation wird die Methode didFinishLaunchingWithOptions aufgerufen. An dieser 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 Applikation gezeigt. Als nchstes wird die Methode applicationDidBecomeActive aufgerufen. Hier wird bereits die View angezeigt und es knnen noch letzte Updates durchgefhrt werden. Die Methode applicationWillResignActive bedeutet, dass der Nutzer gerade den Home-Button gedrckt hat und die Applikation in den Hintergund gelegt wird. In dieser Methode knnen Hintergrundaktivitten gestartet werden, um z.B. Ladevorgnge zu beenden. Die Methode applicationDidEnterBackground bedeutet, dass die Applikation pausiert wurde. Wenn die Applikation wieder im Vordergrund erscheint, wird die Methode applicationWillEnterForeground aufgerufen. Hier knnen Verbindungen zum Server wieder aufgebaut werden. Listing 3.16: Das protocol UIApplicationDelegate
1 2 3

@protocol UIApplicationDelegate<NSObject> @optional - (void)applicationDidFinishLaunching:(UIApplication *) application; - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *) launchOptions; - (void)applicationDidBecomeActive:(UIApplication *) application; - (void)applicationWillResignActive:(UIApplication *) application; - (void)applicationWillTerminate:(UIApplication *)application;

4 5

6 7

67

3.4. Testen von Software (Autor: Rene Kassel)

10 11

- (void)applicationDidEnterBackground:(UIApplication *) application; - (void)applicationWillEnterForeground:(UIApplication *) application; @property (nonatomic, retain) UIWindow *window; @end

12

13 14 15

3.3.6. Notication Center

Das Notication Center ist eine zentrale Stelle innerhalb der iOS-Plattform, um asynchron Nachrichten an andere Teile der Applikation senden und empfangen zu knnen. Eine Notication kapselt die Informationen ber ein Event67 . Wenn nun Objekte innerhalb der Applikation diese Information bentigen, knnen sie sich auf diese Notication registrieren. Die Objekte werden beim Auftreten dieses Events aufgerufen (vgl. [ios12b]). Listing 3.17 zeigt, wie ein Objekt (hier self) sich fr die Notication vom Typ NSWindowDidBecomeMainNotification registriert. Wenn eine Notication von diesem Typ im System erstellt wurde, wird die Methode aWindowBecameMain: aufgerufen. Diese Methode muss einen Parameter vom Typ NSNotification* besitzen. Der Sachverhalt ist in Listing 3.18 dargestellt. Listing 3.17: Registrierung fr eine local notication
1 2 3

addObserver:self selector:@selector(aWindowBecameMain:) name:NSWindowDidBecomeMainNotification object:nil]; Listing 3.18: Die Signatur der Methode zum annehmen der Notication

- (void)aWindowBecameMain:(NSNotification *)notification;

3.4. Testen von Software (Autor: Rene Kassel)

Ein wichtiger Punkt beim Erstellen von guter Software ist das Einhalten etablierter Standards und ber die Jahre entwickelte sogenannte Best-Practices beim Programmieren. Hier kommen Aspekte der Software-Qualitt zum Tragen und Aspekte der Sicherstellung von Funktionalitt. Diese beiden Aspekte knnen 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 von
67 Ein

Beispiel dafr ist ein Touch-Event, wenn der Benutzer einen Teil des Bildschirmes berhrt.

68

3.4. Testen von Software (Autor: Rene Kassel) ihr verlangt wird68 . Auf der anderen Seite dienen sie zum strukturierten Finden von Fehlern in der Software. Auch sind Tests eine sehr gute Methode, um die Anforderungen, die an die Software gestellt werden, zu berprfen. Dies soll Abbildung 3.5 nochmals veranschaulichen. Es wurde sich im Rahmen dieser Arbeit fr folgende Denition von einem Software-Tests geeinigt. Denition Test Testen ist der Prozess, ein Programm mit der Absicht auszufhren, Fehler zu nden ([MS04], Seite 6)

Abbildung 3.5.: berprfung 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 denierte Daten als Eingabe und testet, ob die richtigen Daten als Ausgabe wieder zurck gegeben werden (vgl. [Mye99], Seite 6). Beim Whitebox-Test hingegen kennt der Tester die interne Logik des Programms und gestaltet seine Testflle dementsprechend (vgl. [Mye99], Seite 8). Eine andere Einordnung von Tests basiert auf dem Umfang des Testrahmens, also wieviel der Applikation gleichzeitig getestet wird. Fr diese Einteilung bietet das so genannte V-Modell eine gute bersicht ber diese Art der Einteilung von Tests69 . Der Name stammt von der Darstellungsform dieses Modells. Dies ist in dem meisten Fllen V-frmig. Das V-Modell siedelt die verschiedenen Arten von Tests in Schichten an (vgl. [Hab12]). Es deniert 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 Abbildung an zentraler Stelle im unteren, mittleren Bereich. Direkt darber sind die Komponententests (auch Unit-Tests) angesiedelt. Komponententests sind Tests, bei denen die einzel68 Besser 69 nicht

gesagt, das was die Tests testen. ber das Vorgehen

69

3.4. Testen von Software (Autor: Rene Kassel) nen Klassen (Units) unter Isolation von anderen Klassen getestet werden. Es sollen damit die Funktionalitt, Robustheit und die Efzenz getestet werden (vgl. [Hab12]). Ein Komponententests kann sowohl als Blackbox- als auch als Whitebox-Test durchgefhrt werden. Fr 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 Systemtests wird hier nicht beschrieben, da er nicht explizit getestet wird. Diese Anforderungen stellen die abstrakteste Sichtweise auf die Software dar. Anforderungen sind fr diese Arbeit als User Stories deniert 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 fr einen agilen Entwicklungsprozess sehr wichtig ein schnelles Feedback fr den neu geschriebenenen Quellcode zu bekommen. Hierzu haben sich automatisierte Tests und Codeanalysen durchgesetzt. Diese Tests sollten immer sehr zeitnah ausgefhrt werden. Ein sehr guter Zeitpunkt ist innerhalb des Build-Prozesses der Anwendung. Auf diesen Prozess wird im nchsten Kapitel nher eingegangen.

70

3.5. Build-Management (Autor: Christopher Ezell)

3.5. Build-Management (Autor: Christopher Ezell)

Den Prozess, in dem aus dem Quellcode eine ausfhrbare Anwendung gebaut wird, nennt man Build-Prozess70 . Dies kann je nach Art der Software mehr oder weniger aufwndig sein. Im Folgenden wird erlutert, wie der Build-Prozess bei den eingesetzten Technologien abluft und wie die Tests in diesen Prozess mit eingebunden sind. Der Build fr die Java-Komponenten wird mit Maven durchgefhrt (vgl. [Fou12a]). Maven ist eines der fhrenden Build-Tools fr Java und zhlt zu den deklarativen Build-ManagementSystemen. Das bedeutet, es wird lediglich der Inhalt des Projektes beschrieben, nicht die Struktur oder die Ablufe, die zur Kompilierung und Verffentlichung notwendig sind (vgl. [Spi11], S.27). Durch die Verwendung von Maven ist es sehr einfach Prozess-Schritte zu automatisieren. Es knnen zum Beispiel folgende Dinge automatisiert ablaufen: Compilieren des Quellcodes, Durchlaufen der Unit-Tests, Verarbeitung und Einbindung zustzlicher Ressourcen, Ersetzung von Platzhaltern durch umgebungsspezische Parameter, Starten eines Web- oder Applikationsservers und Durchlaufen der Integrations-Tests. Diese und viele mehr knnen mit diesem Tool ermglicht werden. Deswegen wurde sich fr Maven entschieden. So ist gewhrleistet, dass in einem agilen Entwicklungsprozess schnelles Feedback ber den Zustand der Software mglich ist. Die Konguration von Maven wird ber das POM-File gesteuert. Dieses wird nachfolgend nher erlutert: Das POM-File: Das Projektmodell (Project Object Model - POM) ist ein Mechanismus innerhalb von Maven. Es wird dazu verwendet das zu kompilierende Projekt, die Umgebung und die Beziehungen zu anderen Projekten zu verwalten. Es ist in einer speziellen Datei gespeichert, die den Namen pom.xml trgt. Das Herzstck von Maven ist also die sogenannte POM-File. Sie beschreibt die Inhalte des Projektes und welche Ressourcen fr den Prozess verwendet werden sollen. Bei Maven wird von einem sogenannten Build-Zyklus gesprochen, der durchlaufen wird. Maven durchluft innerhalb dieses Build-Zyklusses immer wieder dieselben Phasen. Diese sind streng aufeinander folgend. Es ist mglich 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 Zielverzeichnis.
70 englisch

to build fr bauen

71

3.5. Build-Management (Autor: Christopher Ezell) compile: kompiliert den Quellcode. process-classes: verarbeitet die kompilierten Klassen (Bytecodeoptimierung). generate-test-sources: verarbeitet alle Testressourcen und kopiert sie in das Testzielverzeichnis. test-compile: kompiliert die Testklassen. test: durchluft die Tests (meistens Unit-Tests). package: packt die kompletten Inhalte in ein jar-File. pre-integration-test: fhrt Aktionen aus, die zum Durchlaufen der Integrationstests ntig sind. integration-test: liefert das Paket in der Umgebung aus (zum Beispiel Glasssh) und durchluft die Integrationstests. post-integration-test: fhrt abschlieende Aktionen aus, die zum Herunterfahren der Umgebung ntig sind. install: installiert das Paket in das lokale Maven-Repository. deploy: deployed das Paket in das Remote-Repository. Eine der groen Strken und das Hauptargument fr Maven ist das sehr gute Dependency Management. Wenn fr 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 bendet 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 Verfgung. Listing 3.19: das Tag dependencies der pom.xml
1 2 3 4 5 6 7

<dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.8.2</version> </dependency> </dependencies> Wie in der Auistung zu sehen ist, werden bei einem Maven-Build immer die Unit-Tests und die Integrationstests durchlaufen. Dies bietet einen enormen Zeitvorteil, da durch das Ausfhren des Builds gleich geprft wird, ob alle Tests durchlaufen werden. Dies erledigt der Entwickler meistens gleich auf dem Entwicklungsrechner und kann so seinen geschriebenen Code selber testen.

72

3.5. Build-Management (Autor: Christopher Ezell) Der Quellcode soll auch auf einem anderen Rechner getestet werden. Dies verhindert, dass eventuelle Rahmenbedingungen fr das Funktionieren der Software an den Gegebenheiten des Entwicklerrechners hngen. Hierzu wird ein externes unabhngiges System bentigt, welches automatisiert diese Schritte und selbststndig die Tests durchluft. Auf dieser Umgebung werden 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 erwhnt. Es wird deniert als ein kontinuierlicher Zyklus der gesamten Strecke von der Kompilierung des Quellcodes ber automatisierte 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 mglich, wenn der Mechanismus der Integration vollstndig automatisiert werden kann. Wenn ein Team dies erreicht, kann es die Zeit fr die Auslieferung seiner Software signikant verringern (vgl. [HF10]). In Anhang A.2 ist ein beispielhafter Aufbau einer CI dargestellt. Denition Continuous Integration Continuous Integration ist ein hervorragendes Werkzeug, um in Softwareentwicklungsprojekten Risiken zu minimieren und Qualitt zu steigern. [Wie10] Ein Problem gibt es bei Maven: Es hat nur ein Kommandozeilen-Interface. Dies lsst sich auf einem Entwicklerrechner noch umgehen, indem die Build-Zyklen von Hand gestartet werden, aber fr einen automatisierten Build ist das nicht geeignet. Dieses Problem lsst sich mit Jenkins lsen. Im Rahmen der Masterarbeit wurde Jenkins als CI-Werkzeug eingesetzt und wird daher nher erlutert. Im Anhang A.16 ist beispielhaft die Weboberche von Jenkins dargestellt (vgl. [Wie10]). In der Weboberche knnen Jobs eingestellt werden, die danach automatisiert einen Maven-Build anstoen knnen. Diese Jobs knnen durch verschiedene Trigger ausgelst werden. Beispiele sind hier zum Einen feste Zeitpunkte und zum Anderen Regeln. Eine Beispielregel ist, dass bei jedem Commit der Build gestartet werden soll. Diese lst den Build-Prozess nach jedem Commit aus. Durch eine Integrationsmglichkeit eines Maven-Buildprozesses ist es eine sehr gute Kombination, um eine CI umzusetzen. Ein weiterer sehr wichtiger Punkt ist die sehr groe Anzahl an Plug-ins fr Jenkins. Durch Plug-ins knnen somit mehr unterschiedliche Aktionen getriggert werden. Bei folgenden Ereignissen knnen bestimmte Aktionen ausgelst 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 knnen nun beliebige Aktionen getriggert werden. Entweder werden diese direkt von Jenkins untersttzt, oder es ist dafr ein Plug-in installiert worden. Zum Beispiel wird das Senden einer e-Mail direkt von Jenkins untersttzt. Hingegen ist das Senden einer XMPP-Nachricht nur mit einem Plug-in mglich. Auch RSS-Feeds werden ohne Plugin untersttzt. Damit knnen 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 mglich. JUnit-Testberichte knnen 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 eingegangen, die in der Arbeit verwendet werden und Techniken beschrieben, die fr das Verstndnis 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 verizieren. Nach der Erluterung von Grundlagen, kann in dem nchsten Kapitel mit der Denition 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 Funktionalitt der umzusetzenden Plattform erfolgt ber User Stories und wird mit Conditions of Satifaction untermauert. Dies soll sicherstellen, dass am Ende klar getestet werden kann, ob die Anforderungen aus den User Stories erfllt wurden. Die Autoren haben sich dazu entschieden, die Aufgaben der Software in User Stories zu denieren. 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 nher beschrieben. Diese leiten sich zum grten Teil aus einem vorherigen Kapitel (Kapitel 2.8) und aus diversen Vorberlegungen zur Plattform ab. Die User Stories bilden den ersten Schritt in der Konzeptions- und Planungsphase. Noch erwhnt werden sollte, dass die User Stories lediglich Features und Akzeptanzkriterien beschreiben, die mittels einer Eigenimplementierung realisiert werden. Installationsroutinen oder die Integration bestehender Lsungen 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 Funktionalitt 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 Lsungsanstze zum grten Teil zu lsen und einen ersten Eindruck zu geben, wie eine komplette Plattform, in diesem Stil, fr 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 mchte mobil mit seinem Team interagieren knnen und dem Team Informationen ber seinen derzeitigen Standort und seine aktuelle Situation bekannt geben. Er soll die Mglichkeit haben, aktuelle Informationen aus dem Team einsehen zu knnen. Es gibt die Mglichkeit mit anderen Usern zu chatten und Aufgaben zu erstellen und diese zuweisen zu knnen. 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 Verknpfung moderner Kommunikationsmglichkeiten entgegenwirken und die negativen Auswirkungen minimieren. Zudem soll das zwischenmenschliche Gefge 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 mchte ich mich mit meinen Accountdaten im System einloggen knnen. 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 mchte ich meinen Account ausloggen knnen. Conditions of Satisfaction:

Given: Gegeben ist, dass ein User mit einem validen Useraccount am System angemeldet ist. When: Wenn dieser User auf einen Button klickt, Then: dann mchte 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-Spezikationen fr einen Right-Bar-Button des UINavigationsControllers.

4.4. User Story 3: News einsehen (Autor: Christopher Ezell)

User Story: News einsehen Als ein User mchte ich Neuigkeiten aus dem Projekt auf einer Seite angezeigt bekommen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige 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 gltige Anmeldung am System als User. Zudem bendet 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 durchgefhrt 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 mchte ich die Mglichkeit besitzen, individuelle Neuigkeiten an meine Projektmitglieder zu posten, um sie dadurch ber den aktuellen Stand zu informieren. Conditions of Satisfaction:

Given: Gegeben ist eine gltige 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 hinzufgen einer neuen Nachricht. Given: Gegeben ist eine gltige Anmeldung am System als User. Der User hat bereits den Button geklickt und bendet sich auf der neuen Ansicht zum hinzufgen. When: Wenn der User dort die erforderten Daten eingibt und auf absenden klickt, Then: dann wird die Neuigkeit an das System gepostet und ist fr alle Projektbeteiligten sichtbar. Abnahmekriterien:

Der Button zum Hinzufgen soll sich an der oberen rechten Ecke benden. Dabei soll er den original Apple-Spezikationen fr einen Right-Bar-Button des UINavigationsControllers 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 fr die Nachricht auf 160 Zeichen, Eine Ansicht ber die noch verfgbaren Zeichen. Der Absenden-Button soll sich an der oberen rechten Ecke benden und den original Apple-Spezikationen fr einen Right-Bar-Button des UINavigationsControllers entsprechen. Es soll sowohl eine Push-Benachrichtigung als auch eine Benachrichtigung per e-Mail ber die Neuigkeit an alle Projektbeteiligten gesendet werden71 .

71 Eigene

User Stories dazu wurden in Kapitel 4.19 und 4.20 deniert

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 mchte ich den aktuellen Build-Status einsehen knnen, um mich ber den aktuellen Projekt-Build-Prozess informieren zu knnen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung am System als User. When: Wenn der User nun das Tabbar-Icon fr den Build drckt, 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 Mglichkeit 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 durchgefhrten 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 mchte ich auf einer Karte durch Pinnadeln die Position meiner Projektmitglieder sehen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung am System als User. When: Wenn der User auf die Seite navigiert, Then: dann sieht er fr 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 gltige 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 zustzlichen Informationen ber das spezielle Projektmitglied angezeigt. Abnahmekriterien:

Die anzeige der Maps soll mit der Hybrid-ansicht von Google Maps erfolgen. Fr die Anzeige der Pins soll der Apple-StandardPin in Rot genutzt werden. Fr 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 mchte ich meine eigene Position updaten knnen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung am System als User. Weiterhin bendet 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 gltige Anmeldung am System als User. Der User ist auf der Seite mit der Karte. Die Eingabemaske ist bereits geffnet. 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-Spezikationen fr einen Right-Bar-Button des UINavigationsControllers entsprechen. Die Eingabemaske enthlt ein Feld zur Eingabe eines Ortes, sowie einen Button zum Besttigen 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 mchte ich alle Tasks sehen, die zu meinen Projekten gehren. Conditions of Satisfaction:

Given: Der User ist mit einem gltigen 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 gltigen Account am System angemeldet. Er bendet sich zur Zeit in der geffneten Task-Ansicht. When: Wenn der User nun den Inhalt der Seite mit dem Finger nach unten schiebt, Then: dann wird ein Pull down to refresh erzeugt, sodass die Taskliste aktualisiert wird. Abnahmekriterien:

Eine einzelne Zelle aus der Ansicht der Taskliste beinhaltet: den Tasknamen, den Wert Worklog: sagt etwas darber aus, wie viel bereits an dem Task gearbeitet wurde, den Wert Estimation: gibt Auskunft darber, welcher Aufwand fr den Task geschtzt wurde, eine Art Fortschrittsanzeige, welche sich aus Worklog und Estimation zusammensetzt. Der Pull down to refresh soll kurz sichtbar sein. D.h. es soll erkennbar sein, dass gerade ein Update auf die Sicht durchgefhrt wird.

4.10. User Story 9: Task erzeugen (Autor: Rene Kassel)

User Story: Task erzeugen Als ein User mchte ich die Mglichkeit besitzen, neue Tasks zu erzeugen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung am System als User. Zudem bendet sich der User in der Tasklisten-Ansicht.

81

4.11. User Story 10: Task kongurieren (Autor: Rene Kassel) When: Wenn der User auf einen Button klickt, Then: dann wird eine neue Ansicht geffnet, welche ein Formular zur Erstellung eines Tasks enthlt, gestartet. Given: Gegeben ist eine gltige Anmeldung am System als User. Der User hat bereits den Button geklickt und bendet sich auf der neuen Ansicht zum hinzufgen. 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 Hinzufgen soll sich an der oberen rechten Ecke in der TasklistenAnsicht benden. Dabei soll er den original Apple-Spezikationen fr einen Right-BarButton des UINavigationsControllers entsprechen. Das Eingabeformular der neuen Ansicht soll enthalten: Ein Feld zur Eingabe des Namens, Eine Mglichkeit, diesen Task einem bestimmten Projekt zuzuweisen. Der Erstellen-Button soll sich an der oberen rechten Ecke benden und den original Apple-Spezikationen fr einen Right-Bar-Button des UINavigationsControllers entsprechen. Nach dem Klick auf den Erstellen-Button soll die Anwendung wieder zurckkehren zur Tasklisten-Ansicht.

4.11. User Story 10: Task kongurieren (Autor: Rene Kassel)

User Story: Task erzeugen Als ein User mchte ich die Mglichkeit haben, einen bereits bestehenden Task anzupassen. D.h. ich mchte ihm einen Verantwortlichen zuordnen und einen geschtzten Aufwand eintragen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung am System als User. Der User hat die TasklistenAnsicht geffnet 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 ausgewhlt werden kann.

82

4.12. User Story 11: Arbeitszeit einsehen (Autor: Rene Kassel) Given: Gegeben ist eine gltige Anmeldung am System als User. Der User hat die TasklistenAnsicht geffnet 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 auswhlt und auf assigned to klickt, Then: dann wird diesem bestimmten Task der verantwortliche User zugeordnet. Given: Gegeben ist eine gltige Anmeldung am System als User. Der User hat die TasklistenAnsicht geffnet 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 schtzen / setzen. Abnahmekriterien:

Die Buttons fr Assign User und Estimate Value benden 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 ausgewhlt 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 eingeben. Der in der Taskliste angezeigte Estimate Value errechnet sich aus allen bereits abgegebenen Schtzungen 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 mchte ich eine bersicht darber haben, wie viel bereits an einem Task gearbeitet wurde. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung am System als User. When: Wenn der User auf den Tabbar-Icon Taskliste klickt, Then: dann sieht er alle Tasks, welche zu ihm gehren. Dort gibt es einen Wert namens Worklog, wo ersichtlich wird, wie viel bereits an diesem Task gearbeitet wurde.
72 Eigene

User Stories dazu werden in Kapitel 4.19 und 4.20 deniert

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 mchte ich meine Arbeit an einem Task loggen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung am System als User. Der User hat bereits die Tasklisten-Ansicht aufgerufen und dort den Task ausgewhlt, an welchem er gearbeitet hat. Die Detailansicht des Tasks ist geffnet. When: Wenn der User den Worklog-Button klickt, Then: dann ffnet sich eine neue Sicht. Given: Gegeben ist eine gltige Anmeldung am System als User. Der User hat bereits die Tasklisten-Ansicht aufgerufen und dort den Task ausgewhlt, an welchem er gearbeitet hat. Ebenso hat er die Detailansicht des Tasks geffnet, 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 Ttigkeit ein und klick auf absenden, Then: dann wird die Arbeit geloggt. Abnahmekriterien:

Der Worklog-Button bendet 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 geschtzte Wert (Estimated Value). Der Button log Work bendet sich an der oberen rechten Ecke und entspricht den original Apple-Spezikationen fr einen Right-Bar-Button des UINavigationsControllers.

4.14. User Story 13: Userliste abrufen (Autor: Rene Kassel)

User Story: Userliste abrufen Als ein User mchte ich eine Liste aller User abrufen, welche an dem aktuell geffneten Projekt beteiligt sind. Conditions of Satisfaction:

Given: Der User muss mit einem validen Account am System angemeldet sein. When: Klickt der User auf das Tabbar-Icon Userlist,

84

4.15. User Story 14: Userinfo einsehen (Autor: Rene Kassel) Then: dann erscheint eine Liste von Usern, welche im Zusammenhang mit dem Projekt stehen.

4.15. User Story 14: Userinfo einsehen (Autor: Rene Kassel)

User Story: Userinfo einsehen Als ein User mchte ich aktuelle Informationen ber meinen Account abrufen knnen. Conditions of Satisfaction:

Given: Der User muss mit einem validen Account am System angemeldet sein. When: Klickt der User auf das Tabbar-Icon Userinfo, Then: dann ffnet sich eine neue Ansicht mit Nutzerdaten. Abnahmekriterien:

Die Details der Userinfo sollen zunchst aus Usernamen und Position bestehen.

4.16. User Story 15: Chat-Kontaktliste abrufen (Autor: Christopher Ezell)

User Story: Chat-Kontaktliste abrufen Als ein User mchte ich einen Chatansicht aufrufen knnen, indem mir alle Kontakte angezeigt werden. Conditions of Satisfaction:

Given: Der User ist mit einem validen Account am System angemeldet. When: Wenn der User auf das Chat-Symbol klickt, Then: dann ffnet sich eine Ansicht, in der alle am Projekt beteiligten Personen mit ihrem Online-Status angezeigt werden. Given: Der User ist mit einem validen Account am System angemeldet. Zudem bendet sich der User bereits in der Chat-Ansicht. When: Wenn der User nun den Inhalt der Seite mit dem Finger nach unten schiebt, Then: dann wird ein Pull down to refresh erzeugt, sodass die Chat-Ansicht mit dem OnlineStatus aktualisiert wird.

85

4.17. User Story 16: Chat-Gesprch mit einem bestimmten Nutzer(Autor: Christopher Ezell) Abnahmekriterien:

Der Online-Status unterteilt sich in Available und Ofine. Der Pull down to refresh soll kurz sichtbar sein. D.h. es soll erkennbar sein, dass gerade ein Update auf die Sicht durchgefhrt wird.

4.17. User Story 16: Chat-Gesprch mit einem bestimmten Nutzer(Autor: Christopher Ezell)
User Story: Chat-Gesprch mit einem bestimmten Nutzer Als ein User mchte ich die Mglichkeit haben, mit einem bestimmten Projektbeteiligten zu chatten. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung als User am System. Der User bendet 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 gltige 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 Gesprchspartner bersandt und im oberen Teil der Ansicht angezeigt. Abnahmekriterien:

Die neue Ansicht, welche sich beim Klick auf einen bestimmten Nutzer ffnet, beinhaltet: Den Namen des Gesprchspartners 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 fhrt automatisch die Tastatur nach oben. Es soll eine Mglichkeit 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 mchte ich einen bestimmten QR-Code einscannen, wodurch sich anschlieend der zugehrige Task ffnet. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung am System als User. When: Wenn der User auf das Tabbar-Icon QR-Code klickt, Then: dann ffnet sich eine neue Ansicht, welche einen Scan-Button besitzt. Given: Gegeben ist eine gltige Anmeldung am System als User. Die Ansicht mit den ScanButton ist bereits geffnet. When: Klickt der User nun auf den Button, Then: dann ffnet sich der Scanner, welchen der User an den QR-Code hlt. Nach dem Scanvorgang ffnet sich sofort der Task, welcher mit dem QR-Code verschlsselt wurde.

4.19. User Story 18: Benachrichtung per e-Mail (Autor: Christopher Ezell)
User Story: Benachrichtung per e-Mail Als ein User mchte ich ber Neuigkeiten, welche sich auf mein Projekt beziehen sowie ber mir neu zugewiesene Tasks per e-Mail benachrichtigt werden. Conditions of Satisfaction:

Given: Es existiert ein User A und ein User B mit jeweils einem validen Account. When: Wenn User A einen Task an User B vergibt, Then: dann wird dem User B eine e-Mail ber die Vergabe der Taskverantwortlichkeit zugesandt. 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: Ofine 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: Ofine Benachrichtung (Autor: Christopher Ezell)

User Story: Ofine Benachrichtung Als ein User mchte ich eine Ofine (Push) Benachrichtigung auf meinem Smartphone angezeigt bekommen wenn mir ein Task zugewiesen wird oder eine Neuigkeit bezglich meines Projektes gepostet wird. Conditions of Satisfaction:

Given: Gegeben ist ein User A und ein User B mit jeweils einer installierten Smartphone-App. Die User mssen einen validen Account besitzen und knnen online oder ofine 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 mssen einen validen Account besitzen und knnen online oder ofine 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 informiert. Given: Gegeben sind beliebig viele User mit jeweils einer installierten Smartphone-App. Die User mssen einen validen Account besitzen und knnen online oder ofine 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 hren. Eine nicht beendete Push-Benachrichtigung wird in Form eines Badges73 angezeigt, sodass der Push nicht verloren geht.

4.21. User Story 20: Verteilte Notizen einsehen (Autor: Christopher Ezell)
User Story: Verteilte Notizen einsehen Als ein User mchte ich mit anderen Projektmitgliedern gemeinschaftliche Notizen besitzen und diese einsehen knnen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige 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 angehrig sind. Given: Gegeben ist eine gltige Anmeldung als User am System. Der User bendet sich in der SimpleNote-Ansicht. When: Wenn der Nutzer den Inhalt nach unten scrollt, Then: dann wird ein Pull down to refresh erzeugt, sodass die Notizen neu geladen werden. Abnahmekriterien:

Eine SimpleNote-Zelle beinhaltet eine berschrift und die ersten zwei Zeilen des Inhaltes. Die berschrift setzt sich aus den ersten 50 Zeichen des Inhaltes automatisch zusammen. Die berschrift ist fett und etwas grer als die Vorschau fr den Inhalt. Der Pull down to refresh soll kurz sichtbar sein. D.h. es soll erkennbar sein, dass gerade ein Update auf die Sicht durchgefhrt wird.
73 Badges

sind kleine Zahlen, welche am App-Symbol hngen 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 mchte ich gemeinschaftliche Notizen mit anderen Projektmitgliedern bearbeiten knnen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung als User am System. Der User bendet sich in der SimpleNote-Ansicht. When: Wenn der User auf eine bestimmte Nachricht klickt, SimpleNote, Then: dann ffnet sich eine Ansicht zum Bearbeiten dieser Notiz. Given: Gegeben ist eine gltige 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 Vernderungen eingibt und abschlieend auf den Safe-Button klickt, Then: dann wird die Notiz in der vernderten Form abgespeichert. Sie ist dann fr alle Projektmitglieder in dieser Form sichtbar. Abnahmekriterien:

Der Safe-Button bendet sich an der oberen rechten Ecke der Ansicht und entspricht den original Apple-Spezikationen fr einen Right-Bar-Button des UINavigationsControllers. 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 mchte ich mit meinen Projektmitgliedern eine Sammlung von Lesezeichen besitzen und diese jederzeit einsehen knnen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung als User am System. When: Wenn der User auf das Tabbar-Icon DiigoTags klickt,

90

4.24. User Story 23: verteiltes Planningpoker durchfhren (Autor: Christopher Ezell) Then: dann wird zunchst eine Ansicht der Lesezeichen aufgeschlsselt nach vergebenen Tags aufgezeigt. Given: Gegeben ist eine gltige Anmeldung als User am System. Der User bendet sich in der Tag-Ansicht. When: Wenn der User dort einen bestimmten Tag anklickt, Then: dann werden ihm alle dem Tag untergliederten Lesezeichen angezeigt. Given: Gegeben ist eine gltige Anmeldung als User am System. Der User bendet sich in der Lesezeichen-Ansicht. When: Klickt der User dort ein bestimmtes Lesezeichen an, Then: dann ffnet sich ein in der App integrierter Webbrowser, welcher den Inhalt der Webseite anzeigt. Abnahmekriterien:

In der Tag-Ansicht steht als berschrift Tags. In der Lesezeichen-Ansicht steht als berschrift Diigo Links. Der User kann jederzeit zwischen Web-Ansicht, Lesezeichen-Ansicht und Tag-Ansicht umher schalten.

4.24. User Story 23: verteiltes Planningpoker durchfhren (Autor:

Christopher Ezell)

User Story: verteiltes Planningpoker durchfhren Als ein User mchte ich Planningpoker mit verteilten Teammitgliedern durchfhren knnen. Conditions of Satisfaction:

Given: Gegeben ist eine gltige Anmeldung als User am System. Der User bendet sich in der Planning-Poker-Ansicht. When: Wenn der User auf einen Planningpoker starten-Button klickt, Then: dann ffnet sich eine neue Ansicht zum Auswhlen des Tasks und dem anschlieenden Durchfhren des Planningpokers, welches in Kapitel 3.1.3 beschrieben ist. Given: Gegeben ist eine gltige Anmeldung als User am System. Der User bendet sich in der Planning-Poker-Ansicht. Der User hat bereits einen Task gewhlt. When: Wenn der User auf eine Karte klickt, Then: dann wartet das System, bis alle Beteiligten ihre Karte gewhlt haben und zeigt anschlieend dem User alle Werte der Beteiligten an.

91

4.25. Zusammenfassung (Autor: Rene Kassel) Abnahmekriterien:

Die auszuwhlenden 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 geschtzte Aufwand zum Task. Sind die Werte nicht gleich, wird eine erneute Auswahlrunde gestartet.

4.25. Zusammenfassung (Autor: Rene Kassel)

Nachdem nun die User Stories deniert wurden, kann die spezielle Konzipierung der Anwendung begonnen werden. Das nchste Kapitel gibt einen grundlegenden berblick ber das System und erklrt deren Funktionsweise.

92

5. Konzeption (Autoren: Christopher Ezell und Rene Kassel)

5. Konzeption

(Autoren: Christopher Ezell und Rene Kassel)

Im Kapitel 2.8 (Die ausgewhlten Kommunikationskanle) wurde ermittelt, welche Tools in einem Projekt nicht fehlen sollten und wozu diese eingesetzt werden knnen, zusammengefasst 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 ermglicht den Projektmitgliedern leichter und schneller den Kontakt mit einem 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 Anwendung, 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. Fr manche Funktionen der Plattform werden externe Dienste gewhlt, die die geforderten Aufgaben vollstndig erfllen. In diesem Fall wird schon innerhalb der Konzeption auf die entsprechenden externen Dienste eingegangen und deren Verwendung erlutert. 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 bedient werden soll. Der Grund hierfr 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. Dafr verbinden sich die Clients mittels eines Konnektors an die dafr von der Plattform denierte REST-Schnittstelle. ber diese knnen alle Funktionen verwendet werden. Da lediglich die Machbarkeit einer solchen Plattform behandelt wird, wird in der Konzeption 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 (logische) Teile getrennt. Dies bietet Vorteile bei der Konzeption, da selbst implementierte Dienste und andere Dienste besser getrennt werden knnen. Im weiteren Verlauf der Arbeit werden diese vier Teile getrennt voneinander betrachtet.

74 Das

heit, es stellt nur eine der mglichen Umsetzungen dar.

93

5. Konzeption (Autoren: Christopher Ezell und Rene Kassel)

Abbildung 5.1.: Aufbau der Projektplattform (ideal) (Quelle: Eigene Darstellung) Der erste Teil beinhaltet alle Dienste, die auf dem projekteigenen Server laufen75 , aber nicht selbst programmiert werden. Diese werden im Kapitel 5.2 betrachtet. Sie zhlen daher zu den internen Services/Diensten. Im Kapitel 5.3 werden anschlieend die externen Services/Dienste aufgegriffen. Diese sind nicht auf dem projekteigenen Server installiert, sondern werden komplett von externen Anbietern verwendet. Die dritte Art von Diensten stellen die selbst implementierten Dienste76 dar. Sie werden nachfolgend als Serverkomponente bezeichnet und sind im Kapitel 5.4 speziziert. Der vierte und letzte Teil befasst sich mit der Clientanwendung. Sie wird in Form einer iPhone-Anwendung realisiert und ist in Kapitel 5.5 deniert. Grundlage fr die in diesem Kapitel klassizierten Typen von Diensten ist die Tabelle in Kapitel 2.8.14. Fr eine bessere bersicht bezglich der Diensteinteilung ist in Abbildung 5.3 eine schematische Darstellung der gesamten Dienstarten dargestellt. Diese Abbildung umfasst nicht die Clientanwendung. Sie enthlt alle erwhnten Kommunikationsmittel und gliedert sie in die oben erwhnten drei Arten von Diensten. Die Abbildung zeigt vier Ellipsen, die die drei verschiedenen Arten von Diensten reprsentieren. 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 Serverkomponente. Der Dienst Instant Messaging bekommt zustzlich einen Konnektor in der Clientanwendung.
75 Alle

Anwendungen wurden auf einem projekteigenen Server installiert. Dieser ist im Internet zu erreichen und ermglicht das Testen der Anwendung im Mobilfunknetz. 76 In 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: Eigene Darstellung) 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 zhlen sie zu den externen Diensten. Fr 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 fr die Serverkomponente noch fr die Clientanwendung. Abschlieend stellt die vierte Ellipse die Java-Webanwendung dar, welches das Herzstck der Plattform ist. Sie reprsentiert innerhalb der Arbeit die Eigenimplementierung auf der Serverseite. Die Webanwendung enthlt die Dienste Aufgabenverwaltung, Mircoblogging und standortbezogene 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 geklrt werden. In dieser Konzeption werden fr einige Dienste externe Dienstleister benutzt, um den Aufwand fr die Implementierung gering zu halten. In einer produktiv laufenden Kommunikationsplattform knnen alle Dienste entweder auf eigenen Systemen laufen oder auf Systemen von Drittanbietern, mit denen ein Datenschutzabkommen deniert wird. Ansonsten kann bei der Kommunikation von vertraulichen Daten nicht gewhrleistet 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 rmenbergreifenden Kommunikationswegen, bei der kein eigener Kommunikationsserver existiert, auf teilweise kostenlose Anbieter zurckgegriffen wird. Ein Beispiel dafr ist Skype als Anbieter fr 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 externen Anbieter weiterverarbeitet werden. Der Vorteil in der Nutzung einer eigenen Plattform ist, dass in so einer Umgebung die kommunizierten Daten besser gegenber anderen Parteien geschtzt sind.

5.2. Konzeption der internen Dienste (Autor: Rene Kassel)

Es wird hier zuerst auf die internen Dienste eingegangen. Folgende Dienste kommen zur Verwendung: 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 erlutert, eignet sich das Protokoll sehr gut fr die genannten Interaktionsmglichkeiten.

96

5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel) Bei dem zu entwickelnden Prototypen wird sich fr den XMPP-Server Openre entschieden, da er alle oben genannten Features untersttzt und sehr ressourcenschonend arbeitet. Auerdem ist die Installation sehr leicht und kann schnell durchgefhrt werden. Abbildung A.3 zeigt die Web-Administrationsoberche von Openre. Hier mssen nur noch die entsprechenden User angelegt werden, damit der Server komplett eingerichtet ist. Da es fr das XMPP-Protokoll sowohl auf Client- als auch auf Serverseite fertige Bibliotheken zur Einbindung von XMPP gibt, wird die API hier nicht weiter erlutert. Diese Dienste stellen einen groen Teil der Sulen 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 fr 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. Fr das Wiki wurde sich fr Media-Wiki entschieden. Hier ist ebenso der Fokus auf die Einfachheit gelegt. Es ist schnell installiert und bentigt lediglich einen Webserver und eine Datenbank fr den Betrieb. Da weder eine Integration von SVN noch von MediaWiki geplant ist, wird nicht weiter auf die Integration eingegangen. Der Blog ist fr grere Ankndigungen und Erklrungen fr neu verwendete Techniken gedacht. Hier knnen auch lngere Artikel verfasst werden. Es erfolgt keine Einbindung in die Server- bzw. Clientanwendung. Ein grerer Punkt bei der Inbetriebnahme stellt das Collaboration-Pad dar. Hier ist die Entscheidung auf Etherpad gefallen. Etherpad ist eine sehr schne Weblsung fr die kollaborative Zusammenarbeit. Um einen Etherpad-Server zu installieren, ist eine Datenbank ntig. Das Paket muss selbst kompiliert und konguriert werden. Es bietet einige sehr gute und vor allem performante Features, die die Entscheidung dafr rechtfertigen. Nach der Installation ist es sofort nutzbar und sehr robust. In Etherpad gibt es nur zwei Ansichten. Die Startseite enthlt lediglich zwei Buttons. Der Eine ist ein Button fr das Starten eines neuen Pads und der Andere ist zum Einrichten einer Teamseite vorhanden. Ein Pad ist in Abbildung A.9 ersichtlich. Es enthlt eine groe Bearbeitungsche in der Mitte. Diese kann von mehreren Nutzern gleichzeitig bearbeitet werden. Auf der rechten Seite bendet sich der interne Chat fr jedes einzelne Pad. Genauere Informationen zu der dahinter stehenden Technik kann in Kapitel 2.8.2 nachgelesen werden.

5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel)
In diesem Kapitel wird kurz auf die externen Dienste eingegangen. Sie werden fr die Umsetzung 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 Abbildungen A.11 und A.12. Sie zeigen unter anderem das Deployment der Services auf den

97

5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel) unterschiedlichen Gerten. 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 einiet, 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 RESTkonforme API hat. Diese ist auf [Tea12] dokumentiert. Generell werden die Informationen bei Diigo ber JSON ausgetauscht. Wie die Abbildung A.12 zeigt, kommuniziert ausschlielich der Client mit der Diigo-API. Eine Integration in die Serverkomponente ist nicht vorgesehen. Somit wird lediglich ein Konnektor fr die Clientanwendung bentigt. Es knnen ber die API Links angelegt und verndert werden. Die komplette Interaktion erfolgt mittels Usernamen und Passwort und mit Hilfe von HTTP Basic Authentizierungen (vgl. [Inc12]). Es werden von Diigo die zwei Verben GET und POST untersttzt. 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 2 3 4 5 6 7 8 9 10 11

[{ "updated_at":"2012/05/15 14:10:32+0000", "url":"http://www.i.de/", "annotations":[], "user":"XXX", "readlater":"yes", "shared":"yes", "tags":"no_tag", "created_at":"2012/05/15 14:10:32 +0000", "title":"Title1", "comments":[], "desc":"" }]

98

5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel) Ein neuer Bookmark kann mit dem Aufruf in Listing 5.3 angelegt werden. Der groe Vorteil von Diigo ist die sehr gute Weboberche zum Verwalten der existierenden Links und BrowserPlugins fr alle gngigen Browser. Die Weboberche zeigt die Abbildung A.15. Listing 5.3: Beispiel eines POST-Aufrufes zum Erstellen eines neuen Links
1 2

POST https://secure.diigo.com/api/v2/bookmarks ?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 fr das Objekt mitgegeben. So steht nach diesem Aufruf sofort das fertige Objekt zur weiteren Verarbeitung zur Verfgung.

5.3.2. Shared Notes (Autor: Christopher Ezell)

Shared Notes ermglicht es ber mehrere Entwickler einen Bestand an Notizen zu halten, die jeder Entwickler einsehen und verndern kann. Es wird an dieser Stelle der Dienst Simple Notes 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 anschlieend bei jedem Aufruf der API angegeben. Es ist ber den Aufruf einer Authentizierungs-URL abrufbar und kann mit Nutzernamen und Passwort eingeholt werden. Danach wird nur noch das Token und der Nutzername bentigt, nicht mehr das Passwort. Das Token verfllt nach 24 Stunden automatisch. Bei dem Beispielaufruf in Listing 5.4 erhlt der Client eine Liste von Notizen. Diese enthalten aber nur Metadaten der jeweiligen Datenstze. Um an den Inhalt der Notizen zu kommen, muss fr jede Notiz die jeweilige URL aufgerufen werden. Listing 5.5 zeigt einen solchen Beispielaufruf einer Notiz mit der ID 123. Der Rckgabeinhalt ist dabei der Gleiche. Hinzu kommt lediglich zustzliches 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 Antwort: { count: 25, data: [ { modifydate: "1324202852.963336", tags: [ ], deleted: 1,

2 3 4 5 6 7 8 9

99

5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel)

10 11 12 13 14 15 16 17 18

createdate: "1324202564.364233", systemtags: [ ], version: 0, syncnum: 2, key: "123", minversion: 1 } ] , time: "1346362216.891024" } Mit der URL einer Notiz kann GET aufgerufen werden, um den Inhalt abzufragen. Die anderen Methoden, wie PUT und DELETE, werden nicht untersttzt. Dies entspricht nicht den RESTPrinzipien laut [Til11]. Um eine Notiz zu speichern, wird die URL mit einem PUT aufgerufen. Das Lschen 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 gelschte Notizen auch von der API zurckgesendet werden. Listing 5.5: Beispiel einer Diigo-Antwort einer Notiz in Form von JSON

GET https://simple-note.appspot.com/api2/data/123?auth=xxx& email=xxx Antwort: { modifydate: "1324202852.963336", tags: [ ], deleted: 1, createdate: "1324202564.364233", systemtags: [ ], content: "hello world", version: 0, syncnum: 2, key: "123", minversion: 1 }

2 3 4 5 6 7 8 9 10 11 12 13 14

5.3.3. Shared Storage (Autor: Rene Kassel)

Shared Storage ist ein perfektes Werkzeug um grere Mengen an Daten abzulegen. Es werden innerhalb des Projektes zwei Arten von Shared Storage verwendet. Zum Einen der bereits
77 Ein

Flag ist eine Variable vom Typ Boolean.

100

5.3. Konzeption externe Dienste (Autoren: Christopher Ezell und Rene Kassel) vorgestellte Dienst Dropbox, der in Kapitel 2.8.10 beschrieben wurde, und zum Anderen Apache Jackrabbit. Dropbox wird zum Synchronisieren von Dateien zwischen den Entwicklern genutzt. Apache Jackrabbit wird von dem implementierten Server genutzt, um Dateien abzulegen. Jackrabbit bietet eine Webdav-Schnittstelle um auf die Daten zuzugreifen. Wie in Abbildung A.11 dargestellt, kommuniziert nur die Serveranwendung direkt mit dem JackrabbitServer. Er wird dafr genutzt, die generierten QR-Codes zu speichern und abzurufen. Das Jackrabbit-Projekt bringt eine Mglickeit mit, sich mit einem Client ber eine Java Remote Method Invocation (RMI)-Schnittstelle auf eine Jackrabbit-Instanz zu verbinden. Hierzu wird lediglich die URL bentigt, auf die der Server konguriert 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 Gert 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 Notication (ARPN). Alle Push-Benachrichtigungen gehen zentral ber den Apple-Push-Server. Diese mssen pro Device angefragt werden. Die Abbildung zeigt einen Provider, der eine eine Notication an bestimmtes Gert senden mchte. Dabei geht die Notication den Weg ber den Apple Push Notication Service. Dieser ordnet die Benachrichtigung dem registrierten Gert zu und schickt sie dorthin. Anschlieend wird innerhalb des iPhone-Betriebssystems die Notication einer Client-App zugeordnet, sodass sie angezeigt werden kann. Listing 5.6: JSON-Reprsentation einer ARPN (Quelle:[App12b])
1 2 3 4

{ "aps" : { "alert" : "Message received from Bob" }, "acme2" : [ "bang", } 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. "whiz" ]

101

5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)

5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)

Dieses Kapitel befasst sich mit der Konzeption der Eigenimplementierung. Die Eigenimplementierung besteht aus einer Web-Applikation, welche in einem JavaEE78 -Server luft. Generell ist die Aufgabe dieses Servers, die iPhone-Applikation in der Erfllung der in Kapitel 4 gestellten User Stories zu untersttzen. Fr die Applikation werden die Daten zentral auf dem Server abgelegt. Der Client79 hlt also keine persistenten Daten, sondern fragt diese immer vom Server ab. Der Server hlt alle Daten von allen Clients persistent. Nach auen hin bietet der Server eine REST-Schnittstelle an, ber die sich der Client anmelden und die Daten abfragen kann. Ebenso bietet er zustzliche Funktionalitt zum Verwalten und Bearbeiten der Daten. Es werden die folgenden Funktionalitten 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 fr das MVC-Pattern (Model View Controller) entschieden. Demzufolge teilt sich die Webapplikation in drei logische Teile. Den ersten Teil bildet das View, das durch eine REST-API implementiert ist. Diese bietet dem Client die Mglichkeit 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 Webapplikation. Dieser fhrt die zu ttigenden 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 implementiert. Diese verknpfen die Services im Controller-Teil mit verschiedenen Datenquellen und Diensten im Internet.

5.4.1. View (Autor: Christopher Ezell)

Wie oben erwhnt, ist die View eine auf den REST(HTTP)-Prinzipien aufgebaute API, die mittels XML kommuniziert81 . Das View delegiert alle Aufrufe an den Controller und kommuniziert die Rckgabewerte an den abfragenden Client zurck.
78 Java 79 die

Platform Enterprise Edition iPhone-Applikation 80 Genau genommen ber die REST-Endpunkte und die Verben aus HTTP. 81 REST basiert auf den Prinzipien des HTTP-Protokolls und ist dadurch im Gegensatz zu SOAP(Simple Object Access Protocol) eine sehr schlanke Form der Kommunikation und ist vielseitig einsetzbar.

102

5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell) Es werden nun die Interfaces fr die verschiedenen Aufgaben deniert. Nur Teile der in den User Stories denierten Funktionalitten werden implementiert. Die anderen Funktionalitten laufen bei externen Anbietern und werden vom Client direkt aufgerufen. Die zu implementierenden Funktionalitten sind die Aufgabenverwaltung und der NewsStream. Hierfr mssen 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 Anwendung immer einen Wurzelknoten. Hieraus entstehen alle anderen Knoten. Der Wurzelknoten ist in der Anwendung unter /rest erreichbar. Darunter benden sich die Knoten /users, /news, /push, /health und /auth. Diese werden nun nacheinander erlutert. Einen besseren 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 fr die Verwaltung von Userdaten. Es knnen 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 zurckgegeben, da das GET auf den ganzen Knoten der User ausgefhrt wird. Ein POST liefert eine ID des neues Objektes. Eine Befehlsbersicht ist in der unten stehenden Tabelle dargestellt. Knoten /rest/users /rest/users /rest/users/userID /rest/users/userID /rest/users/userID Methode GET POST GET PUT DELETE Inhalt Anfrage kein Inhalt kein Inhalt kein Inhalt ScrumUser-Objekt (neu) kein Inhalt Inhalt Antwort alle existierenden User 201, ID des neu angelegten Users den User mit der ID = userID 200 Den User mit neuen Werten 200

82 Dies

ist in Listing 5.7 zu sehen.

103

5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell) Listing 5.7: Die XML-Darstellung eines SrumUser-Objektes <scrumUser> <deviceId>7b...88</deviceId> <id>1346020087078</id> <latitude>52.5172503</latitude> <location>none</location> <longitude>13.3949287</longitude> <name>defaultUser</name> <status>busy</status> </scrumUser> Der Knoten /auth/userName ist fr die Authentizierung der User und besitzt nur eine Methode. Diese Methode kann mit dem Verb POST aufgerufen werden. Hinzu kommt der PfadParameter userName. Dieser stellt den Anmeldenamen des Users dar und muss vom Client mit dem entsprechenden Wert gefllt werden. Im Content-Bereich der Anfrage mssen die Credentials83 des Users mitgegeben werden. Eine Beispielanfrage ist in Listing 5.8 dargestellt. Die Rckgabe 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 RKRequestDelegate curl -X POST -d \ <login-credentials><password>geheim</password></logincredentials> \ http://SERVER/rest/auth/iphone -v > POST /rest/auth/iphone HTTP/1.1 ... < HTTP/1.1 200 OK ... <scrumUser> <deviceId>...</deviceId><id>1346013911583</id> <jabbername>iphone@h1926567.stratoserver.net</jabbername> <latitude>0.000000</latitude> <location></location><longitude>0.000000</longitude> <name>iphone</name><status>Bin heute in Muenchen.</status> </scrumUser> In der Tabelle Label ist die Methode mit Parametern eingetragen(Klingt komisch). Wichtig ist hier, dass im Fehlerfall Statuscodes vom Client verarbeitet werden mssen. Im Falle, dass der Client ein ungltiges XML schickt, wird der Statuscode 422 (Unprocessable Entity) zurck gesendet. Wenn die Userdaten nicht korrekt sind, wird ein 403 (Forbidden) geschickt. Knoten /rest/auth/username /rest/auth/username /rest/auth/username
83 Das

1 2 3 4 5 6 7 8 9

1 2

3 4 5 6 7 8 9 10 11 12 13 14 15 16

Methode POST POST POST

Inhalt Anfrage User Credentials invalides XML invalide Credentials

Statuscode, Inhalt der Antwort 200 und den entsprechenden User 422 invalides XML 403 (User nicht valide)

deutsche Wort dafr ist: Berechtigungsnachweis. Das sind im Allgemeinen Username und Passwort des jeweiligen Nutzers.

104

5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell) Die News haben den Knoten /news und knnen darber erstellt und abgefragt werden. Die Tabelle zeigt alle relevanten Methoden auf dem News-Knoten mit Parametern. Die Handhabung ist hnlich zu dem User-Knoten. Die Schnittstelle wird in der unten stehenden Tabelle beschrieben. Knoten /rest/news /rest/news /rest/news/newsID /rest/news/newsID /rest/news/newsID Methode GET POST GET PUT DELETE Inhalt Anfrage kein Inhalt kein Inhalt kein Inhalt News-Objekt (neu) kein Inhalt Inhalt Antwort alle existierenden News 201, ID der neu angelegten News die News mit der ID = newsID 200 das News-Objekt mit neuen Werten 200

Bei dem Knoten /push/ID kann an ein iPhone, das einem User zugeordnet ist, eine PushBenachrichtigung gesendet werden. Diese wird als Content in dem Aufruf mit gesendet. Die Tabelle zeigt alle relevanten Methoden, die auf diesen Knoten aufgerufen werden knnen. Knoten /rest/push/device-id /rest/push/user-id Methode POST POST Inhalt Anfrage Inhalt der Nachricht Inhalt der Nachricht t Inhalt Antwort 200 200

Bei dem Knoten /health kann ein iPhone die Verfgbarkeit des Servers prfen. Dieser Knoten kann nur mit GET aufgerufen werden und liefert den Statuscode 200 zurck, wenn er verfgbar ist. Knoten /rest/health/ Methode GET Inhalt Anfrage LEER Inhalt Antwort 200

5.4.2. Controller (Autor: Christopher Ezell)

Der Controller beinhaltet die gesamte Geschftslogik, die fr die Plattform ntig 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 dafr sind das Generieren eines QR-Codes oder das Senden einer Push-Notication. Die Services der oberen Ebene verwenden die Services der unteren Ebene und bndeln diese zu kompletten Funktionalitten. Beispiele fr 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 Auenwelt 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 hlt alle Referenzen auf die anderen Services. So kann ein View auf alle Services zugreifen und sehr efzient seine

105

5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell) Aufgaben erledigen, da nur der richtige Service geholt werden und eine Methode aufgerufen werden muss. So ist die Trennung zwischen View und Controller sehr gut gelst.

Abbildung 5.6.: Die Verbindung von den Services zu der View (Quelle: Eigene Darstellung) Zustzlich 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 komplette Funktionalitt bieten. Beide knnen ber den Context-Service aufgerufen werden. Bei den Services, die nur die Funktionalitt eines Konnektors kapseln, sind die folgenden deniert: Push-Service: Dabei handelt es sich um ein Service, der auf die Push-API von Apple zugreift und auf einzelne oder alle iPhones eine Push-Benachrichtigung erscheinen lassen kann. Storage-Service: Der Storage-Service ist fr die Speicherung von Dateien in die WebdavSchnittstelle verantwortlich. Mail-Service: Dieser Service befhigt 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 Generieren von QR-Codes aus einem Text zu ermglichen. Notication-Service: Der Notication-Service ist in der Lage, an ein spezisches Device eine Remote-Notication zu senden. Einem bestimmten Nutzer eines Gertes kann eine direkte Nachricht geschickt werden. Dies kann fr bestimmte Situationen sehr ntzlich sein. Entity-Service: Der Entity-Service ist die zentrale Anbindung an die Datenbank per JPA. Er wird von hherliegenden Services benutzt, um Operation auf den Daten der Datenbank durchzufhren. XMPP-Service: Der XMPP-Service ermglicht der Applikation Nachrichten per XMPP an registrierte Nutzer zu senden.

106

5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell) XML-Service: Dies ist ein Dienst zum Generieren und Lesen von XML-Dateien auf Basis von JAXB. Entity-Service: Der Service dient dem Zugriff auf die in der Datenbank gespeicherten Objekte. Eine bersicht ber die Integration der Services ist im Klassendiagramm der Abbildung A.14 dargestellt. Die Struktur und Hierarchie ist dort ersichtlich. Die abstrakte Oberklasse AbstractService enthlt alle Basisfunktionalitten, die ein Service nutzen kann, um seine Aufgaben zu erledigen. Hierzu gehren 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 genutzt. Der Mechanismus ist in Abbildung 5.7 dargestellt. Im ersten Schritt sendet der Client dem Server eine Anfrage ber HTTP84 mit XML-Daten. Diese XML-Daten reprsentieren 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 weitergeleitet85 . Das geschieht im dritten Schritt. Im vierten Schritt antwortet der Service mit einem Response-Objekt, das im fnften Schritt wieder mit dem XML-Service in XML gewandelt und an den Client zurckgesendet wird (sechster Schritt).

Abbildung 5.7.: Verwendung des XML-Services im View (Quelle: Eigene Darstellung) Die Services, welche eine komplette Funktionalitt kapseln, sind Services, die andere Services nutzen, um ihre Aufgabe zu erfllen. Dabei knnen ganze Ablufe von Aktionen deniert werden. Ein Beispiel ist der Task-Service. Er ist fr die CRUD-Funktionalitten86 eines Tasks zustndig. 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
84 REST 85 Zum 86 CReate

Beispiel wird es beim Aufruf von /news an den News-Service weitergeleitet. Update Delete

107

5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell) Daten dementsprechend zu bearbeiten und den neuen Inhaber des Tasks zu informieren. Dieser Beispielablauf kann wie folgt umgesetzt werden. Zuerst holt sich der Task-Service ber den Context-Service den Entity-Service, um die Daten zu bearbeiten. Wenn dies passiert ist, holt er sich den e-Mail-Service und schickt eine e-Mail an den User. Alternativ kann er auch ber den XMPP-Service eine Nachricht versenden. Ebenso ist es mglich, 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, Lschen und ndern von News zustndig. Fr die Umsetzung seiner Aufgaben 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 auen. In dieser Arbeit werden diese Schnittstellen als Konnektoren bezeichnet. Konnektoren sind in der Anwendung eine Sammlung von Adaptern zu verschiedenen Diensten, 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 exibel auf verschiedene Situationen reagiert werden. Auch eine Verknpfung verschiedener Kommunikationskanle ist denkbar. Diese Architektur wurde gegenber einem generischen ESB (Enterprise Service Bus) vorgezogen, da sie sehr viel schlanker in die Anwendung eingebunden 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 mglich sein, mit den verschiedenen Diensten zu interagieren. Jeder Dienst besitzt einen eigenen Konnektor. Es wird kurz auf die einzelnen Konnektoren eingegangen. Bei dem XMPP-Konnektor handelt es sich um eine Verbindung zum XMPP-Server, der

108

5.4. Konzeption einer Server Webapplikation (Autor: Christopher Ezell)

Abbildung 5.8.: Die Verbindung von Services zu den Konnektoren (Quelle: Eigene Darstellung) auf dem Projekt-Server luft. Durch diesen Konnektor kann der Server Chat-Nachrichten versenden und den Online-Status der User abfragen. Die Chat-Nachrichten knnen 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 Server mglich, Berichte und Informationen ber E-Mail zu versenden. Der RSS-Konnektor bzw. das RSS-Modul soll es dem Server ermglichen, Informationen als RSS-Feeds zu publizieren. So knnen 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 schnellen Laden von zum Beispiel Tasks genutzt. Mit dem Apple-Push-Konnektor knnen PushNachrichten 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) erwhnt. Dieser ermglicht es, Daten mittels JPA in einer Datenbank zu speichern.

87 SMTP-Server

109

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

Die Konzeption des Clients ist in zwei Teile gegliedert. Der erste Teil besteht darin, die aus den User Stories gewonnenen Informationen in strukturierte einzelne Funktionalitten zu gliedern und diese in ein Gesamtkonzept einzubinden. Im zweiten Teil wird die grundlegende Benutzeroberche fr die jeweiligen Funktionalitten mittels Mockups88 deniert. Die Mockups wurden mit der Software Balsamiq Mockups erstellt. Besonders die Benutzeroberche ist ein sehr wichtiges Thema. Wenn der Nutzer eine Funktionalitt durch eine schlecht designte Oberche nicht ndet, ist sie fr 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. Grundstzlich gibt es bei einer iPhone-App verschiedene Anstze, die Informationen zu prsentieren. Laut den Apple Human Interface Guidelines89 [ios12a] ist es eine der besten Mglichkeiten, eine Applikation mit mehreren unterschiedlichen Funktionen mittels einer TabView als Hauptview zu unterteilen. So wird diese App in oberster Ebene mittels einer Tabview in verschiedene Bereiche getrennt. Diese kann man am unteren Bildschirmrand auswhlen und so in die verschiedenen Funktionalitten wechseln. Es werden anhand des Kapitels 4 die folgenden Bereiche als eigenstndige 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 nher erlutert und beschrieben.

88 Dies

89 Diese

wird auch Wireframe genannt. sollten vor dem Entwickeln einer iPhone-App von jedem Entwickler gelesen werden.

110

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

5.5.1. Architektur der iPhone-App (Autor: Christopher Ezell)

Zunchst 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 dafr entschieden haben, 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 berfhrt. Die Entscheidung, ob die Daten ber REST oder XMPP bertragen werden, hngt von dem jeweiligen Dienst ab. ber dem Model benden sich der Controller. Dieser bildet die Schnittstelle zwischen dem Model und der View. Der Controller erhlt dabei die Daten vom View und leitet diese an das Model weiter91 . Erhlt 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, mssen nur die in der Abbildung 5.9 gezeigten REST- und XMPP-Konnektoren implementiert werden.
90 Beispiele 91 Dies

fr verwendete Parser sind der XML- und der JSON-Parser. passiert bei Benutzereingaben.

111

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

5.5.2. Datensynchronisation (Autor: Rene Kassel)

Ein Punkt hat besonders groen Einuss auf die Architektur einer Anwendung: die Art und Weise wie das Management der Daten konzipiert wird. Die iPhone-Applikation muss verschiedene Kommunikationsarten untersttzen. Es gibt auf der einen Seite die asynchrone Kommunikation 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 knnen. Es muss eine Entscheidung gefllt werden, wie diese Daten im iPhone vorgehalten und gespeichert 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 Applikation neu geladen werden. Wenn der Benutzer beim Start keinen Internetzugriff hat, hat er keine Daten zur Verfgung. Die Daten werden nur neu geladen, wenn dies der Nutzer explizit wnscht.

5.5.3. Die einzelnen Funktionalitten im berblick

Die Abbildung 5.10 zeigt eine Mind-Map zu der geplanten Funktionalitt. Es enthlt einen Strang fr jede Funktionalitt der Applikation. Sie teilen sich in acht verschiedene Tabs und einen Login-Screen auf. Nachfolgend werden die jeweiligen Tabs erlutert und deren Funktionen erklrt. 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 Mglichkeit 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 Ofine getrennt sind. Mit Usern, die im Status Online sind, kann eine direkte Unterhaltung stattnden, indem auf den jeweiligen Zelleneintrag getappt wird. Es ffnet sich ein Fenster mit einer Texteingabeleiste am unteren Ende des Bildschirms. Wenn auf diese getappt wird, erscheint die Bildschirmtastatur. Es ist mglich durch das Drcken des Senden-Buttons, die in der Texteingabeleiste geschriebene Nachricht zu versenden. Zu sehen ist das in dem Mockup der Abbildung 5.12. Dort ist ersichtlich, von wem die Nachricht stammt und welchen Inhalt die Nachricht trgt. Die Liste der Nachrichten ist scrollbar bis zum Beginn der aktuellen Session. ltere Nachrichten sind nicht abrufbar. Wenn der Nutzer mit Usern chatten will, die im Status Ofine sind, kann er denen ebenfalls Nachrichten senden. Diese Nachricht wird dann dem anderen User als Push-Benachrichtigung zugestellt. Die Vorteile dieses Features sind im Kapitel 2.8.3 dargestellt.

112

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 5.10.: Mind-Map Darstellung)

der

InstantScrum

iPhone-Applikation

(Quelle:

Eigene

Durch dieses Feature wird die direkte Erreichbarkeit von Projektmitgliedern immens erhht. Es kann ortsunabhngig 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 Nutzer eine schnelle, aber efziente, Mglichkeit bieten, sich selber Tasks als Erinnerung zu erstellen oder einem anderen User einen bestimmten Task zuzuweisen. Die Idee dabei ist, die Mglichkeit 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 enthlt 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 gewhlte Task in einer Detailansicht dargestellt. Diese wird in Abbildung 5.14 gezeigt. Die Ansicht beinhaltet Informationen

113

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 5.11.: Mockup der Chatliste (Quelle: Eigene Darstellung) zum Tasknamen, zur Arbeitszeit, zum Verantwortlichen Mitarbeiter und zum Status des Tasks. Weiterhin knnen innerhalb der Detailansicht verschiedene Funktionen ausgelst werden, wie Planningpoker, Statusnderungen oder das Erfassen der Arbeitszeit. Mit Hilfe dieses Features wird die Transparenz bezglich der Arbeit innerhalb des Teams verbessert. 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. Diese Technik dient dazu einem User der Applikation das Absenden einer kurzen Nachricht ber seinen aktuellen Status zu ermglichen. Es ist eine Art globaler Newsstream innerhalb des Projektes, welcher nahezu alle Informationen enthlt, die im Projekt anfallen. Wie schon in Kapitel 2.8.7 betrachtet, ist es in einem Projekt sehr wichtig, aktuelle Information schnell aufnehmen zu knnen, um auf diese gegebenenfalls schnell reagieren zu knnen. Der Mockup zu dieser Funktion ist in Abbildung 5.15 dargestellt. Er besteht aus einer Liste von chronologisch sortierten Nachrichten. Jede Nachricht enthlt 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 bendet sich ein Zeitstempel, wann die Nachricht verfasst wurde.
92 Die

Art ist beispielsweise eine Vernderung im Wiki oder eine Nachricht, die ein anderer User geschrieben hat.

114

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 5.12.: Mockup eines Chats mit einem anderem User (Quelle: Eigene Darstellung) Durch den kontinuierlichen Fluss an Neuigkeiten wird die Teilhabe einzelner Mitglieder am Projekt stark erhht. Dieses Feature ist von Vorteil, wenn einzelne Mitglieder an anderen Standorten arbeiten und ohne diesen Newsstream nur sehr wenig Informationen bekommen wrden. Das Dezit des verteilten Teams wird dadurch abgeschwcht. 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 zunchst die vergebenen Tags der Links dargestellt. Dies hat den Vorteil, dass der Nutzer eine bersicht ber alle getagten Themen erhlt 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 mglich. Durch das Feature kann sich ein Mitglied innerhalb krzester Zeit und ortsunabhngig93 Wissen aneignen, welches von anderen Teammitgliedern als wichtig erachtet wurde. Hierdurch kann sehr viel Zeit bei der Einarbeitung gespart werden.

93 Zum

Beispiel whrend einer Bahnfahrt.

115

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 5.13.: Mockup der Taskliste (Quelle: Eigene Darstellung) 5.5.3.5. Maps (Autor: Christopher Ezell) In dem Tab Maps sollen die User Stories 6 und 7 umgesetzt werden. Der Tab besteht, wie in dem Mockup von Abbildung 5.17 dargestellt, aus der Standardansicht einer Karte. Diese zeigt die aktuelle Position des Benutzers mit der blauen Markierung94 . Mit der Markierung in Grn 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 knnte eine Liste von im Projekt denierten Standorten sein. Zustzlich zur eigenen Position und der Positionen seiner Kollegen wrden somit noch vordenierte Standorte zu sehen sein. Derartige Standorte knnen zum Beispiel das Bro oder das Lieblingscafe sein. Ein Nutzer wrde dann bei einem Tap auf den Button zuerst die Liste von Standorten sehen, in die er einchecken kann. Diese Standorte kann er zustzlich erstellen, wenn er seine Position an einem noch unbekannten Ort aktualisiert. Dieses Feature kann innerhalb eines Projektes die Transparenz fr den Aufenthaltsort, an dem sich die Teammitglieder benden, erhhen. Durch die Nutzung der Funktionalitt kann eine Erhhung der sozialen Interaktionen im Projekt erreicht werden. Damit die Motivation zur
94 Die

Position wird vom GPS-Sensor des Smartphones ermittelt. gesagt: Es werden ihm die Positionen seiner Kollegen gezeigt, die sie zuletzt aktualisiert haben. 96 siehe Kapitel 5.5.3.3 97 Diese Erweiterung ist kein Bestandteil des Prototypen.
95 Besser

116

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 5.14.: Mockup der Detailansicht eines Tasks (Quelle: Eigene Darstellung) Nutzung dieser Technik gesteigert wird, kann ein Punktesystem integriert werden. Durch den Spielcharakter kann die Hugkeit der Informationsteilung ortsbezogener Daten stark erhht werden. Die Erhhung der Transparenz und die Frderung der sozialen Interaktion strken 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 erlutert. Es behandelt eine Funktionalitt, die Teammitgliedern an verschiedenen Standorten dennoch die Mglichkeit bietet, Planningpoker mit Echtzeit-Feedback durchzufhren98 . Der Prozess luft wie folgt ab: Zuerst muss eine Audio-Verbindung hergestellt werden, um mit den Projektpartnern direkt reden zu knnen. Danach wird die Applikation geffnet und die eigentliche Funktionalitt kommt zum Einsatz. Im Tab Planningpoker gibt es oben rechts einen Plus-Button. Wenn der Nutzer diesen Button bettigt, kann er aus der Liste aller noch offenen Tasks einen bestimmten auswhlen, fr den er das Planningpoker durchfhren mchte. 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 fr verschiedene Komplexittsgrade fr den Task. Nun kann jeder Nutzer eine Karte auswhlen. Dabei wird solange gewartet, bis alle Teilnehmer eine Karte ausgewhlt haben. Nun ist die erste Runde vorbei und der Server wertet aus, welcher Nutzer
98 Nhere

Informationen gibt es im Kapitel 3.1.3.

117

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 5.15.: Mockup der Newsliste (Quelle: Eigene Darstellung) welche Karte gewhlt hat. Haben nicht alle Teilnehmer den gleichen Wert gewhlt, wird den Nutzern eine Liste der Teilnehmer mit den jeweils gewhlten Werten dargestellt. Im Anschluss darauf diskutieren die Teilnehmer ber die Wahl. Danach kann ber einen Button eine neue Runde begonnen werden. Dieses Vorgehen luft so lange bis alle die gleiche Karte gewhlt haben. Der groe Vorteil dieser Lsung ist die Ortsunabhngigkeit der Teilnehmer. Es kann praktisch von jedem Ort aus an dieser Schtzrunde teilgenommen werden. Die Erfahrung der Autoren hat gezeigt, dass es in einem verteilten Team sehr schwierig diese agilen Praktiken, wie das Planningpoker, durchzufhren. Eine klassische Durchfhrung wre bei einem Team, was zum Zeitpunkt der Schtzung nicht an einem Standort ist, praktisch unmglich. Durch das Planningpoker ist es jedoch mit Hilfe eines direkten Feedbacks mglich, solche Schtzungen auch verteilt durchzufhren. Dieses Feature ermglicht die Technik des Planningpokers zur Aufwandschtzung auch zwischen distanzierten Teammitgliedern. Dabei knnen die Mitglieder direkt und interaktiv die Aufwnde schtzen. Das verbessert die Qualitt des Schtzverfahrens bei verteilten Teams sowie der Planungsmeetings. Die Dauer der Planung kann dadurch stark reduziert werden. Zustzlich knnen Bilder der Projektmitglieder neben dem geschtzten Wert die emotionale Verbindung herstellen und erhhen.

118

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 5.16.: Mockup der Mapfunktionalitt (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 durchgefhrt. Die Liste enthlt fr 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 Meetings, verbessert. Diese knnen mobil eingesehen und kommentiert werden. 5.5.3.8. QR-Code-Scanner (Autor: Rene Kassel) Die Funktionalitt des QR-Code-Scanners soll dem Benutzer den Umgang mit Tasks erleichtern. Tasks werden in einem QR-Code hinterlegt. Wenn diese nun an einem Taskboard aufgehngt werden, kann ein Task einfach per QR-Code gescannt werden. Dadurch wird er sofort auf dem Smartphone geffnet. In der sich ffnenden Ansicht kann nun der Status des Tasks verndert oder einem anderen Teammitglied zugewiesen werden. Die Grundlagen fr QR-Codes wurden im Kapitel 3.2.9 erlutert. Die Idee hinter diesem Feature ist die starke Kopplung von Virtuellem und Realem. An dem Taskboard sind eine Vielzahl von Tasks angebracht in Form von QR-Codes. Gibt es nun ein ver-

119

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 5.17.: Mockup der PlanningpokerView (Quelle: Eigene Darstellung) teiltes Planungsmeeting mit Telefonkonferenz, kann ein Projektmitarbeiter an das Taskboard gehen und einen bestimmten Task anscannen. Danach kann er ihn sofort einen bestimmten Mitarbeiter zuweisen, der eine Push-Benachrichtigung auf sein Smartphone erhlt. Dadurch wird die Information sehr schnell ausgetauscht. Damit ist der Effekt der direkten Interaktion sehr viel hher, als wenn dies nur formell auf einer Webseite mit einem normalen Taskverwaltungstool 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 Unregelmigkeiten schnell zu reagieren. Es soll mit dieser Funktionalitt ermglicht 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 ermglicht das schnelle Bemerken eines kritischen Fehlers im Quellcode, um darauf reagieren zu knnen. Damit wird einer Entstehung schwerwiegenderer Fehler entgegengewirkt.

120

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 5.18.: Mockup des Buildstatus (Quelle: Eigene Darstellung) 5.5.3.10. Das Punktesystem (Autor: Rene Kassel) Dieses Feature wurde nur zu Teilen in der Plattform umgesetzt. Es greift das Thema der Gamication aus Kapitel 2.7 auf. Hier wurde erwhnt, dass es sehr motivationsfrdernd sein kann, wenn der Nutzer durch Aktivitten im Team Punkte bekommt und zustzlich eine Ansicht hat, wo diese Punkte eingesehen werden knnen. 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 entfernten Partnern mit der Zeit verlieren. Es soll also ein in das System integriertes Punktesystem geben, was dem Nutzer ein positives Feedback gibt und Mitglieder dafr 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 erhht, das Reparieren eines Builds und

121

5.5. Konzeption Client (Autoren: Rene Kassel und Christopher Ezell) das Einchecken eines Klassen- oder Methoden-Kommentars. Das Team kann entscheiden, welche Aktion wie viele Punkte erhlt. Zustzlich kann entschieden werden, welche Belohnung bei welcher Punktzahl ansteht. So ist ein stetiger Anreiz geschaffen, etwas Wertvolles fr das Team zu tun. 5.5.3.11. Liste aller registrierten User (Autor: Rene Kassel) Die Liste aller registrierten User soll einen berblick gewhren, wer gerade im Team aktiv ist. In dieser Ansicht knnen 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 Aktivitt zu sehen, die der User gettigt hat. Darunter ist eine Aufschlsselung 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 Mae ein Zusammengehrigkeitsgefhl zwischen den Teammitgliedern erzeugt. Zudem wird durch die Bekanntgabe der Punkte der Spieltrieb erhht, was wiederum die Motivation steigert.
99 grn:

online, gelb: nicht verfgbar und rot: ofine

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 speziziert. Hier wird deniert, welche Tests innerhalb der Entwicklung erstellt werden und wie diese generell durchgefhrt 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 Anwendung ablaufen soll und welche Komponenten darin wie durchlaufen werden sollen. Primr geht es hier um den Build der Serveranwendung, da die Clientanwendung nur aus einem Teil besteht. Im Build der Serveranwendung sind verschiedene Komponenten deniert. Die einzelnen Komponenten mssen bei der Implementierung dieses Builds mit Maven, falls ntig, 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 verfgbaren Services. das Web: Diese Komponente besitzt alle REST-Komponenten inklusive dem Web-Container und den Basisklassen. Nun mssen fr jeden Schritt im Build-Prozess Teststrategien entworfen werden. Es werden Unit-, Integrations- und Explorativ-Tests betrachtet. Die Unit-Tests stellen die Basis fr die Verikation der Funktionalitt einer Software dar und werden daher sowohl auf dem Client als auch auf der Serverseite erstellt. Auf der Serverseite werden fr alle Module Unit-Tests deniert, die beim Build des jeweiligen Moduls durchlaufen werden. Auf Clientseite werden nur Explorativ-Tests der Benutzoberche vorgenommen. Die Integrations-Tests gehren zu einem gutem Test-Setup fr agile Projekte dazu. Hier werden alle Funktionalitten Modul-bergreifend getestet. Dies sollte so produktionsnah wie mglich getestet werden. Das bedeutet im besten Fall, dass ber die API gestestet wird, welche der Client benutzt. Dadurch ist gewhrleistet, 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. Fr diesen Testaufbau wird also das Folgende bentigt: das Vorhandensein einer Datenbank, zu der eine Verbindung aufgebaut werden kann, das Vorhandensein eines Webservers, der als Container fr die Applikation dienen kann,
100 Grundlagen

hierzu werden im Kapitel 3.4 beschrieben.

123

5.7. Zusammenfassung (Autor: Rene Kassel) die Webapplikation muss zur Testzeit auf dem Server deployed sein, es muss ein Test-Client existieren, der mit diesem Server eine Verbindung aufbauen kann und das Vorhandensein von Testfllen, die den Anwendungsfllen 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 Testergebnisse per E-Mail verschicken.

5.7. Zusammenfassung (Autor: Rene Kassel)

In diesem Kapitel sind die Funktionalitten der Plattform dargestellt worden und auf die verschiedene Server verteilt worden. Es wurden die Schnittstellen der einzelnen Dienste beschrieben bzw. speziziert. Weiterhin wurde deniert, welche Dienste extern bzw. intern genutzt werden und welche Teile selber programmiert werden sollten. Aufgrund dieser Konzeption werden im nachfolgenden Kapitel ausgewhlte 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 denierten 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 Beispielcode 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 fr den Server dargestellt sowie der Aufbau der CI-Umgebung fr das Projekt erlutert.

6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)
Als erstes wird die Implementierung der jeweiligen Techniken auf Seiten des Servers vorgestellt. 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 JavaAnwendung an eine Datenbank anzubinden. Nun soll es darum gehen, die praktische Umsetzung zu erlutern. Die Autoren haben sich, wie oben erwhnt, fr EclipseLink ([ecl12]) als Implementierung von JPA entschieden. Die Konguration von JPA ist deklarativ ber eine XMLDatei. Hier werden alle wichtigen Verbindungsparameter gesetzt und alle Klassen eingetragen, welche ber diese Schnittstelle in eine Datenbank bertragbar sein mssen. Ein Ausschnitt aus dieser Kongurationsdatei ist in Listing 6.1 dargestellt. Hier ist eine JPA-Konguration mit der ID de.crossbeanmedia.scrumapp.jpamodel zu sehen. Diese deniert die Persistenz fr die Klassen ScrumTask und ScrumUser. Die Klassen mssen die Annotation @Entity aus javax.persistence.Entity tragen.

125

6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel) Listing 6.1: Auschnitt aus der Eclipse-Link Conguration <persistence> <persistence-unit name="de.crossbeanmedia.scrumapp.jpamodel"> <class>de.crossbeanmedia.scrumapp.basemodel.projectdata. ScrumTask</class> <class>de.crossbeanmedia.scrumapp.basemodel.userdata. ScrumUser</class> <properties> <property name="javax.persistence.jdbc.driver" value="" /> <property name="javax.persistence.jdbc.url" value="" /> <property name="javax.persistence.jdbc.user" value="" /> <property name="javax.persistence.jdbc.password" value="" /> </properties> </persistence-unit> </persistence> Aus dieser Konguration kann eine Instanz der Klasse EntityManager erzeugt werden. Listing 6.2 zeigt, wie diese Konguration geladen wird. Zudem zeigt es, wie ein neues Objekt der Klasse ScrumUser in die Datenbank gespeichert wird und ein Objekt der Klasse ScrumUser wieder aus der Datenbank geladen wird. Durch den Aufruf des EntityManager wird beim ersten mal das dazugehrige Datenbankschema erzeugt. Listing 6.2: Beispiel eines Datenbankzugriffs mit JPA EntityManagerFactory emf; EntityTransaction entityTransaction; EntityManager em = Persistence .createEntityManagerFactory( "de.crossbeanmedia.scrumapp.jpamodel"); em = emf.createEntityManager(); entityTransaction = em.getTransaction(); ScrumUser user = new ScrumUser(); em.persist(user); ScrumUser user2 = em.find(ScrumUser.class, id); Die Integration dieser Funktionalitt in den Kontext der Anwendung ist in Abbildung 6.1 dargestellt. Hier wird deutlich, dass die Klasse ScrumEntityManager die Funktionalitt von EclipseLink kapselt. Der ScrumEntityManager hlt dabei alle Referenzen auf die bentigten Klassen. Dieser wird von der Klasse EntityService benutzt. Der EntityService gehrt zu den im Kapitel 5.4.2 denierten 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 geladen werden kann. Ein Beispiel wre getAllScrumUsers(). Dies macht den Zugriff auf die Daten sehr viel einfacher.

1 2 3

5 6 7 8 9 10 11 12

1 2 3 4 5 6 7 8 9 10 11

126

6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)

Abbildung 6.1.: Klassendiagramm EntityManager (Quelle: Eigene Darstellung)

6.1.2. Push-Konnektor (Autor: Christopher Ezell)

Nun soll auf die Umsetzung des Konnektors fr den Apple Push Service eingegangen werden. Die Denition des Interfaces wurde in Kapitel 5.3.4 vorgenommen. Auf der Serverseite wurde fr die Umsetzung des Push-Konnektors die Bibliothek JavaPNS (siehe [P.12] verwendet. Sie bietet eine sehr schne API zum Erstellen von Push-Benachrichtigungen. Bevor eine PushBenachrichtigung auf einem iPhone angezeigt werden kann, mssen einige Vorbedingungen auf dem Server erfllt sein. Es wird ein generiertes Key-File mit verschiedenen Zertikaten bentigt. Dies wird fr die Authentizierung gegenber dem Apple-Server verwendet. Die Generierung ist hier nicht weiter beschrieben. Das Key-File muss fr den weiteren Verlauf zur Verfgung stehen. Als zweites wird das jeweilige Device-Token von jedem einzelnen iPhone bentigt. Wie diese Device-Token in Erfahrung gebracht werden knnen, 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 spezischen iPhone eine Push-Nachricht senden. Listing 6.3 zeigt den Aufbau der Methode pushWithSound. Hier wird zuerst der Keystore geladen und danach in eine Klasse der Bibliothek JavaPNS verpackt. Mit der Methode Push.combined ist es nun mglich, einem Device mit dem bergebenen Device-Token einen Push zu senden. Hierzu wird das Device-Token in eine Klasse BasicDevice verpackt.

127

6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)

Abbildung 6.2.: Tokengenerierung (Quelle: [App12b]) Listing 6.3: Push to Device void pushWithSound(String message, String sound, String token, int badge, Sting password) { try { InputStream keystore = this.getClass().getResourceAsStream(" /java.p12"); //add Device to a List List<Device> list = new ArrayList< Device>(); BasicDevice device = new BasicDevice(token); list.add(device); Push.combined(message, badge, sound, keystore, password, false, list); } catch (KeystoreException e) { log.info(e.getMessage()); } catch (Exception e) { log.info(e.getMessage()); } }

2 3

4 5

6 7 8 9

10 11 12

13 14 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

101 siehe

http://kenglxn.github.com/QRGen/

128

6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel) QRConnektor erzeugt einen QR-Code mit der Gre 300 mal 300 Pixel und dem bergebenen Text und gibt einen ByteArrayOutputStream zurck. Dieser kann von der Plattform dann weiter verarbeitet werden. Listing 6.4: QR-Code generieren
1 2 3 4

5 6 7

public ByteArrayOutputStream getQrCodeStream(String message) { return QRCode .from(new String(message.getBytes(), Charset.forName(" UTF-8"))) .to(ImageType.PNG).withSize(300, 300).stream(); }

6.1.4. Mail-Konnektor (Autor: Rene Kassel)

Fr 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. Dafr ist die Methode sendMessage des Konnektors zustndig. Um die Mail zu verschicken wird eine MimeMessage erzeugt und mit dem bergebenen Inhalt gefllt. Zustzlich werden Propertys mit dem bentigten E-Mail-Einstellungen erzeugt. Abschlieend verbindet sich der Konnektor auf dem Mailserver und bertrgt die E-Mail. Listing 6.5: Senden einer E-Mail public void sendMessage(String to, String messageString, String subject) throws AddressException, MessagingException { Properties props = new Properties(); props.put("mail.transport.protocol", "smtp"); props.put("mail.smtp.host", "smtp.strato.de"); props.put("mail.smtp.auth", "true"); Session mailSession = Session.getDefaultInstance(props); Transport transport = mailSession.getTransport("smtp"); MimeMessage message = new MimeMessage(mailSession); message.setSubject(subject); message.setContent(messageString, "text/plain"); message.setFrom(new InternetAddress("")); message.addRecipient(Message.RecipientType.TO, new InternetAddress(to)); transport.connect("", ""); transport.sendMessage(message, message.getRecipients(Message.RecipientType.TO)); transport.close(); } }

2 3 4 5 6 7 8 9 10 11 12 13 14 15

16 17 18 19 20 21 22 23

129

6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)

6.1.5. XMPP-Konnektor (Autor: Christopher Ezell)

Die Java-Webapp nutzt den XMPP-Konnektor zum Senden und Empfangen von XMPP-Nachrichten. Hierzu wird die API von Ignite Realtime verwendet102 . Listing 6.6 zeigt die Verwendung dieser API im XMPP-Konnektor. Listing 6.6: Senden und Empfangen einer XMPP-Nachricht XMPPConnection("Servername"); connection.connect(); connection.login("user", "pass"); PacketFilter filter = new AndFilter(new PacketTypeFilter( Message.class)); PacketListener myListener = new PacketListener() { public void processPacket(Packet packet) { if (packet instanceof Message) { Message msg = (Message) packet; if (msg.getBody() != null) { if (!msg.getBody().equalsIgnoreCase("null")) { Message message = new Message(); message.setTo(msg.getFrom()); message.setBody("OK"); message.setType(Message.Type.normal); connection.sendPacket(message); } } } } }; 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 zurck geschickt.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

6.1.6. Einbindung der Services in die Webapplikation (Autoren: Christopher Ezell)

Jersey bietet ein sehr schnes Feature zum Einbinden von globalen Dependencies ohne direkt das Singleton-Pattern einsetzen zu mssen103 . Bei dieser Technik wird ein Objekt in den Kontext der Webanwendung eingebaut, welches nun global zur Verfgung steht und von allen
102 siehe 103 Das

http://www.igniterealtime.org/downloads/index.jsp Singleton-Pattern zhlt seit den letzten Jahren in Java zu den Pattern, die nicht benutzt werden sollten, um einen globalen Status zu halten (vgl. [Tea09])

130

6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel) anderen Objekten innerhalb von Jersey ber den Kontext genutzt werden kann. Dieses Objekt ist der ContextService. ber ihn kann auf alle Services zugegriffen werden. Diese Technik wurde verwendet, um die Services global innerhalb der Webapplikation zur Verfgung zu stellen. Die Vorgehensweise ist wie folgt. Durch eine Annotation @Context in den Klammern der Parameter einer Funktion ist es mglich, 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 Referenz 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-Methode
1 2

3 4

@PUT public Response test(@Context ServletContext servletContext) { //... } Dies geschieht ber einen Web-Setuplistener, der in der web.xml registriert wird. Dieser SetupListener 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.xml

1 2 3 4

5 6 7

<web-app> ... <listener> <listener-class>de.crossbeanmedia.scrumapp.web. instantscrumWebSetupListener</listener-class> </listener> ... </web-app>

104 Dieses

Wort stammt von dem Wort Dependency Injection und bedeutet, dass die bentigten Objekte, die innerhalb einer Methode gebraucht werden, nicht aktiv geholt werden mssen, sondern von auen eingespeist werden knnen.

131

6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel) Listing 6.9: Initialisierung des Contextservice
1 2 3 4

5 6 7 8 9 10

11 12 13 14

@Override public void contextInitialized(ServletContextEvent arg0) { log.info("contextservice called"); final DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder(); builder.setFileName("instantscrum-web-bootstrap.xml"); Configuration config = null; try { config = builder.getConfiguration(true); ContextService service = new ContextService(config); arg0.getServletContext().setAttribute("ContextService", service); } catch (ConfigurationException e) { log.error("error in contextservice.startup ", e); } } Wie in der Abbildung A.14 dargestellt, sind die Services alle von einer abstrakten Oberklasse AbstractService abgeleitet (Listing 6.10). Diese hlt den ContextService und bietet so eine einheitliche Zugriffsmglichkeit auf den Basis-Service. Hierdurch ist auch gewhrleistet, dass sich die Services untereinander nden und nutzen knnen 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 ServletContext public abstract class AbstractService { private ContextService contextService; public AbstractService(ContextService contextService) { this.contextService = contextService; } protected synchronized ContextService getContextService() { return contextService; } } Listing 6.11: Service aufrufen mit dem ContextService getContextService().getMailService().sendEmail("", "", "")

1 2 3 4 5 6 7 8 9 10 11 12

6.1.7. XML-Binding (XMLService) (Autor: Rene Kassel)

Die Umsetzung der Generierung von XML aus den Klassen wurde mit JAXB realisiert. Die Grundlagen hierfr wurden im Kapitel 3.2.2 beschrieben. Um eine Klasse mit JAXB in eine XML umwandeln zu knnen, muss die betroffene Klasse die Annotation @XmlRootElement aus javax.xml.bind.annotation tragen. Des Weiteren muss die Klasse fr alle Felder

132

6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel) getter und setter-Methoden und einen parameterlosen Defaultkonstruktor bieten. Wenn dies alles erfllt ist, kann die Klasse in XML umgewandelt werden. Listing 6.12: Beispiel Klasse mit JAXB-Annotationen
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

@XmlRootElement @Entity public class ScrumTask { public static final long DEFAULT_ID = 1234; private String taskName; private String status; public ScrumTask() {} public String getTaskName() { return taskName; } public void setTaskName(String taskname) { this.taskName = taskname; } public String getStatus() { return status; } public void setStatus(String status) { this.status = status; } } Ein Beispiel ist die in Listing 6.12 dargestellte Klasse ScrumTask. Diese Klasse erfllt alle Bedingungen, um in XML umgewandelt werden zu knnen. Bei dem folgenden Beispiel werden zwecks einer besseren bersichtlichkeit nur zwei Felder benutzt. Es soll gezeigt werden, 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. Danach wird mittels der Methode Unmarshaller.unmarshal die XML in ein Java-Objekt gewandelt. Listing 6.13: Beispiel XML aus einem Objekt

1 2 3 4

<scrumTask> <taskName>hallo</taskName> <status>done</status> </scrumTask> Listing 6.14: Unmarshalling von XML mit JAXB JAXBContext context = JAXBContext.newInstance(); Unmarshaller unmarshaller =context.createUnmarshaller(); ScrumTask scrumTask= (ScrumTask) unmarshaller.unmarshal(new StringReader( xml)); Die Funktionlitt zum Generieren und Lesen von XML ist im XMLService umgesetzt und wird von der REST-API zum marshallen und unmarshallen der Anfragen genutzt.

1 2 3

133

6.1. Implementierung der Serveranwendung (Autoren: Christopher Ezell und Rene Kassel)

6.1.8. REST-API (Autor: Christopher Ezell)

Fr das Restinterface ist die Entscheidung auf das Jersey Framework [Com12a] der Glasssh Community [Comc] gefallen. Jersey ist eine fr produktivzwecke einsetzbare Java API for RESTful Web Services (JAX-RS). Es ist die Java-Referenzimplementierung fr RESTWebanwendungen. Jersey funktioniert komplett ber sogenannte Annotations und POJOs. Es verwendet dabei ein Servlet, welches die Anfragen an die entsprechenden Endpunkte weiterleitet. 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 entsprechende Annotation besitzen. Ein Beispiel einer Service-Klasse ist in Listing 6.16 dargestellt. Dort ist die Methode getString deniert. Die gezeigte Klasse NewsStream hat eine Annotation @Path("/news") und eine Methode mit der Annotation @GET. Diese Methode wird aufgerufen, 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.xml @Path("/news") public class NewsStream extends <web-app> <servlet> <servlet-name>Jersey REST Service</servlet-name> <servlet-class>ServletContainer</servlet-class> <init-param> <param-name>com.sun.jersey.config.property.packages</param -name> <param-value>de.crossbeanmedia.scrumapp.restinterface</ param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>Jersey REST Service</servlet-name> <url-pattern>/rest/*</url-pattern> </servlet-mapping> </web-app>

1 2 3 4 5 6 7

9 10 11 12 13 14 15 16

105 OK

134

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) Listing 6.16: Beispiel einer Jersey Service Klasse
1 2 3 4 5 6 7 8 9

@Path("/news") public class NewsStream extends AbstractRestService { @GET @Produces({ "application/xml", "application/json" }) public Response getString() { return Response.ok("Hallo Welt").build(); } }

Abbildung 6.3.: Klassendiagramm RestServices (Quelle: Eigene Darstellung)

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)
Nachdem die Implementierung des Servers beschrieben wurde, wird nun die Implementierung des Clients behandelt. Wie schon in den letzten Kapiteln erwhnt, handelt es sich um eine iPhone-Applikation. Die Anforderungen und zu implementierenden Features sind in den Kapiteln 4 und 5.5 erlutert. Es soll in diesem Kapitel nicht jedes Detail und jede Funktionalitt der Applikation beschrieben werden. Es soll viel mehr in jedem Unterkapitel eine Technik beschrieben werden, die zur Implementierung dieser Applikation beigetragen hat und wo diese in der Applikation genutzt wurde.

135

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)

6.2.1. REST-Anbindung (Autor: Christopher Ezell)

Die REST-Anbindung ermglicht der iPhone-Applikation die Kommunikation ber das Restprotokoll mit einem Server. Fr diese Anbindung wird das Framework RestKit verwendet [Com12b]. Es stellt eine groe Flle an Funktionen bereit, die das Entwickeln einer RestfulApp 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 Lsung dar, weil es sich nahtlos in eine existierende iOS-App integrieren lsst. Die Klasse zum Aufrufen einer REST-URL ist RKClient. Listing 6.17 zeigt die Initialisierung der Klasse und den Aufruf einer REST-URL mit einer HTTP-Authentizierung. Listing 6.17: Initialisierung von einem RKClient
1 2

RKClient *client = [RKClient clientWithBaseURL:@"https://... "]; [RKClient clientWithBaseURL:@"https://..." username:@"test" password:@"test"]; Die Klasse, die innerhalb einer Applikation als die Funktion des RestKit-Delegate fungieren mchte, muss das im RestKit-Framework denierte protocol RKRequestDelegate implementieren. Dies ist im Listing 6.18 zu sehen. Die wichtigste Methode in diesem protocol ist die Methode didLoadResponse. Die Methode wird aufgerufen, wenn ein Request fertig bertragen wurde. In den Fehlerfllen werden je nach Fehlerfall die Methoden requestDidCancelLoad, requestDidTimeout oder didFailLoadWithError aufgerufen. Listing 6.18: Delegate-Methoden des Protokolls RKRequestDelegate

1 2

- (void)request:(RKRequest*)request didLoadResponse:( RKResponse*)response; - (void)request:(RKRequest*)request didFailLoadWithError:( NSError*)error; - (void)requestDidStartLoad:(RKRequest*)request; - (void)request:(RKRequest*)request didSendBodyData:(NSInteger )bytesWritten totalBytesWritten:(NSInteger)totalBytesWritten totalBytesExpectedToWrite:(NSInteger)totalBytesExpectedToWrite ; - (void)requestDidCancelLoad:(RKRequest*)request;
106 siehe

3 4

5 6 7 8

9 10

11 12 13

auch 3.3.3

136

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) - (void)requestDidTimeout:(RKRequest*)request; Wenn nun die Methode didLoadResponse aufgerufen wird, ist die bertragung beim Server abgeschlossen. Zustzlich muss innerhalb der Methode geprft werden, was fr eine Art der Antwort zurckgekommen ist, welcher Statuscode zurckgegeben wurde und was der Inhalt der Nachricht ist. Dies ist in Listing 6.19 dargestellt. Listing 6.19: Parsen einer Response
1 2

14

- (void)request:(RKRequest*)request didLoadResponse:( RKResponse*)response { if ([request isGET]) { if ([response isOK]){ ... } } } In der Klasse RKClient gibt es jeweils eine Methode fr jedes Verb bei REST (z.B. GET, POST, PUT und DELETE). Zu sehen sind die Denitionen in Listing 6.20. Dies macht die Programmierung mit dieser Klasse sehr intuitiv. Listing 6.20: Auszug aus der RKClient.h

3 4 5 6 7 8 9

1 2

- (RKRequest*)get:(NSString*)resourcePath delegate:(NSObject< RKRequestDelegate>*)delegate; - (RKRequest*)get:(NSString*)resourcePath queryParams:( NSDictionary*)queryParams delegate:(NSObject< RKRequestDelegate>*)delegate; - (RKRequest*)post:(NSString*)resourcePath params:(NSObject< RKRequestSerializable>*)params delegate:(NSObject< RKRequestDelegate>*)delegate; - (RKRequest*)put:(NSString*)resourcePath params:(NSObject< RKRequestSerializable>*)params delegate:(NSObject< RKRequestDelegate>*)delegate; - (RKRequest*)delete:(NSString*)resourcePath delegate:( NSObject<RKRequestDelegate>*)delegate; Alle Methoden bentigen Kontent, der zum Server bertragen werden muss. Eine Ausnahme stellt die Methode GET dar. Hierzu wird bei RESTKit ein Objekt einer Klasse, die das protocol RKRequestSerializable implementiert, bentigt. Dieses protocol deniert die Methoden aus Listing 6.21. Ein Objekt muss die Methode HTTPHeaderValueForContentType und mindestens eine der optionalen Methoden HTTPBody oder HTTPBodyStream implementieren. Die Rckgabe dieser Methode sollte eine serialisierte Form des zu bertragenden Objektes sein und wird dann als NSData an den HTTP-Request angehangen.

137

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) Listing 6.21: Delegate-Methoden des Protokolls RKRequestSerializable
1 2 3 4 5

@protocol RKRequestSerializable /** * The value of the Content-Type header for the HTTP Body representation of the serialization / * - (NSString*)HTTPHeaderValueForContentType; @optional - (NSData*)HTTPBody; - (NSInputStream*)HTTPBodyStream; - (NSUInteger)HTTPHeaderValueForContentLength; @end

6 7 8 9 10 11 12 13 14 15

6.2.2. XMPP-Integration (Autor: Christopher Ezell)

Die Integration mit einem XMPP-Server erfolgt ber das XMPPFramework von Robbie Hanson [Han12]. Es bietet eine sehr stabile und ausgereifte API fr XMPP. Es gibt hier eine Fassade, die alle Funktionalitten kapselt. Mittels dieser Klasse knnen alle Dienste von XMPP genutzt werden. Es wird im weiteren bei dieser Funktionalitt der Name XMPP-Konnektor verwendet. Die Daten, die der XMPP-Konnektor zur Anmeldung an den XMPP-Server bentigt, 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 iOS [[XMPPDelegate getInstance] sendmessageWithContent: @"Hallo Welt", [[XMPPDelegate getInstance] myJID], deviceToken ]]; Listing 6.23: Senden einer Nachricht mit XMPP auf iOS -(void) sendmessageWithContent:(NSString*)string{ NSXMLElement *body = [NSXMLElement elementWithName:@"body" ]; [body setStringValue:string]; NSXMLElement *message = [NSXMLElement elementWithName:@" message"]; [message addAttributeWithName:@"type" stringValue:@"chat" ]; [message addAttributeWithName:@"to" stringValue:self. currentChatUserName]; [message addAttributeWithName:@"from" stringValue:myJID];

1 2

3 4 5

138

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) [message addChild:body]; [self.xmppStream sendElement:message]; } 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-Fassade - (void) sendmessageWithContent:(NSString*)string; - (void) goOnline; - (void)goOffline; - (void)xmppStream:(XMPPStream *)sender didReceiveMessage:( XMPPMessage *)message; - (void)xmppStream:(XMPPStream *)sender didReceivePresence:( XMPPPresence *)presence; - (void)xmppStreamDidDisconnect:(XMPPStream *)sender withError :(NSError *)error; Damit der richtige Online/Ofine-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 Ofine gehen mit dem XMPP-Konnektor - (void)applicationDidEnterBackground:(UIApplication *) application { [delegate goOffline]; [delegate disconnect]; } - (void)applicationWillEnterForeground:(UIApplication *) application { [delegatew connect]; [delegatew goOnline]; }

9 10 11 12

2 3

2 3 4 5

6 7 8

6.2.3. XML/JSON-Parser (Autor: Rene Kassel)

Das Parsen von XML und JSON auf dem iPhone ist ein sehr huger Anwendungsfall. Daher existieren einige sehr gute Standardlsungen, auf die zurckgegriffen werden kann. Fr jeden Anwendungsfall wurde jeweils ein Framework benutzt. Fr das Parsen von XML wurde das Framework namens XMLTreeParser benutzt (vgl. [osm12]). Ein Beispiel dafr, 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, welcher die Beispielantwort des Servers in XML beinhaltet. Nachdem dies geschehen ist, kann

139

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) durch das Senden der Nachricht parse an das Objekt XMLTreeParser ein Objekt vom Typ XMLTreeNode erstellt werden. Dieses Objekt stellt das Wurzelelement des XML-Baumes dar. Nun knnen durch das Aufrufen der Methode findChildren rekursiv die jeweiligen Kindelemente entnommen und verarbeitet werden. Listing 6.26: Einfaches XML-Beispiel
1 2 3 4

<person> <vorname>Harald</vorname> <name>Lesch</name> </person> Listing 6.27: Simples Parserbeispiel von XML mit XMLTreeNode XMLTreeParser *parser = [[XMLTreeParser alloc] init]; NSString *testString = @"<person><vorname>Harald</vorname><name>Lesch</name></ person>"; XMLTreeNode* root = [parser parse:[testString dataUsingEncoding: NSUTF8StringEncoding]]; XMLTreeNode* person = [[root findChildren:@"person"]objectAtIndex:0]; XMLTreeNode* vorname = [[person findChildren:@"vorname"] objectAtIndex:0]; XMLTreeNode* name = [[person findChildren:@"name"] objectAtIndex:0]; NSLog(@"Vorname: %@, Nachname: %@", text); vorname.text, name.

1 2 3

4 5 6

7 8 9 10 11 12 13 14

Es ist also mit diesem Parser mglich, prozedural durch die Knoten zu iterieren und so die bentigten Daten aus der XML herauszultern. Fr das Parsen von JSON steht in iOS ebenfalls ein sehr gutes Framework zur Verfgung, das SBJSON-Framework. Es generiert aus einem JSON-String verschachtelte Schssel-WertPaare. Diese stellen die JSON-Struktur dar. Die Struktur kann dann geparst und in Objekte gewandelt werden. Ein Beispiel zeigt Listing 6.28. Hier wird ein Objekt von der Klasse DiigoBookmark mit Daten aus einem JSON-String befllt. Es werden dazu die Klassen aus dem SBJSON-Framework genutzt. Die Klasse SBJsonParser kann mittels der Methode objectWithString aus einem JSON-String diese verschachtelten Schssel-Wert Paare erstellen. Durch diese knnen nun innerhalb einer Schleife die bentigten Informationen aus allen Objekten extrahiert werden.

140

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) Listing 6.28: JSON parsen unter iOS
1 2 3

SBJsonParser *jsonParser = [[SBJsonParser alloc] init]; NSDictionary *jsonObjects = [jsonParser objectWithString: jsonString error:&error]; NSMutableArray *marks = [NSMutableArray array]; for (NSDictionary *dict in jsonObjects) { DiigoBookmark *mark = [[DiigoBookmark alloc] init]; mark.updated_at = [dict objectForKey:@"updated_at"]; mark.url = [dict objectForKey:@"url"]; }

4 5 6 7 8 9 10 11 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 fr 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 erlutert worden.

6.2.5. Simplenote-Integration (Shared Notes) (Autor: Christopher Ezell)

Die Simplenote-Integration erfolgt wie die Diigo-Integration ber einen angepassten JSONParser 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 implementiert 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 Notication umgesetzt. In der Klasse SimpleNoteListJSONParser wird am Ende der Methode didLoadResponse die Notication getSimpleNoteContent geworfen. Dies ist in Listing 6.29 dargestellt. Listing 6.29: Posten einer Notication [[NSNotificationCenter defaultCenter] postNotificationName:@" getSimpleNoteContent" object:self]; Die Notication wird in der Model-Klasse abgefangen. Dort werden im Anschluss die Daten fr jede einzelne Notiz nachgeladen. Dies ist in Listing 6.30 gezeigt. Hier wird fr jeden String in dem Array simpleNoteKeys die Daten fr eine Notiz geladen.

141

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) Listing 6.30: Registrierung des Oberservers und Implementierung der Methode [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(simpleUpdatedNotification:) name:@"reloadDataSimpleNote" object:nil ]; - (void)simpleUpdatedNotification:(NSNotification *) notification{ for (NSString* keyTemp in simpleNoteKeys) { NSString* noteUrl = [[NSString alloc] initWithFormat:@ "/data/%@%@", keyTemp, @"?auth=XXX&email=XXX" ]; NSLog(@"%@", noteUrl); [clientSimple get:noteUrl delegate:simpleParserFill]; } } Um beim Laden der Liste mglichst zeitnah die neuen Daten anzuzeigen, wurde das KeyValue-Observing Feature aus Kapitel 3.3.4 verwendet. Der Observer ist in der Klasse NoteListController eingefgt. Dies ist in Listing 6.31 zu sehen. Dabei handelt es sich um den Controller von der Listenansicht der Notizen. Hier wird deniert, 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 dieser Stelle werden nun die Daten aus dem Model neu geladen und die neuen Inhalte werden sofort dargestellt. Listing 6.31: Registrierung des Oberservers Beispiel [self addObserver:self forKeyPath:@"model.simpleNoteList" options:NSKeyValueObservingOptionNew context:nil]; Listing 6.32: Implementierung der Observer-Methode - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:( id)object change:(NSDictionary *)change context:(void *) context{ [self.tableView reloadData]; }

3 4

5 6

7 8 9 10

2 3

6.2.6. Kongurations-Management (Autor: Rene Kassel)

Das Iphone bringt einen eigenen internen Mechanismus mit, wie die Konguration gestaltet werden soll. Hierzu gibt es in der App ein sogenanntes Settings-Bundle. Dies enthlt in einer eigenen Form die Eintrge der Einstellungen. Ein solches Settings-Bundle ist eine XML107 , die mit Key-Value-Pairs die ntigen Eintrge enthlt (siehe Listing 6.33). Es gibt aber auch einen graschen Editor. Dieser kann in Abbildung 6.4 eingesehen werden.

107 Dies

ist in Form einer sogenannten plist, die bei Apple-Produkten hug Verwendung ndet.

142

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 6.4.: Der grasche Editor des Settings-Bundle (Quelle: Eigene Darstellung) Listing 6.33: Plist-XML-Datei mit den darin enthaltenen Einstellungen <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>StringsTable</key> <string>Root</string> <key>PreferenceSpecifiers</key> <array> <dict> <key>Type</key> <string>PSTextFieldSpecifier</string> <key>Title</key> <string>App-name</string> <key>Key</key> <string>app_name</string> <key>DefaultValue</key> <string>app</string> </dict> </array> </dict> </plist> Wenn nun das Settings-Bundle in das iOS-Bundle eingebaut wird, erscheint es in der Einstellungsseite des iPhones. Dieser Sachverhalt ist in Abbildung 6.5 zu sehen. Die Kongurationen 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-Bundle
1 2

1 2

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; NSString *app = [defaults stringForKey:@"app_name"];

143

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 6.5.: Die iPhone Oberche der Einstellungen (Quelle: Eigene Darstellung)

6.2.7. Ortungsdienste (Autor: Christopher Ezell)

Ein groer Vorteil des iPhones ist die nahtlose Integration vieler Sensortechniken, die ber die API benutzt werden knnen. 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 knnen, kann das fr diesen Zweck von Apple zur Verfgung gestellte Framework CoreLocation verwendet werden. Es ist durch diese nahtlose Integration der Ortsdienste mglich, nativ in einer Applikation die Position des iPhones zu nutzen. Um nun CoreLocation nutzen zu knnen, muss eine Klasse erstellt werden, die das protocol CLLocationManagerDelegate implementiert. Listing 6.35 zeigt die wichtigsten Methoden des Protokolls. Die Methode didUpdateToLocation wird automatisch aufgerufen, sobald eine neue GPS-Position vom Gert ermittelt wird. bergeben werden hier dem Location-Manager die neue Position sowie die alte Position. Listing 6.35: Auszug aus dem CLLocationManagerDelegate-Protokoll
1 2 3

4 5 6

- (void)locationManager:(CLLocationManager *)manager didUpdateToLocation:(CLLocation *)newLocation fromLocation:( CLLocation )oldLocation; * - (void)locationManager:(CLLocationManager *)manager didFailWithError:(NSError
108 Zitat

aus dem Apple Developer Portal: The framework uses information obtained from the built-in cellular, Wi-Fi, or GPS hardware to triangulate a location x for the device. [App12a]

144

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) *)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 Objekt, dass das aufrufende (also self) Objekt das protocol CLLocationManagerDelegate implementiert und bei den oben genannten Ereignissen aufgerufen werden sollte. Die komplette 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 CLLocationManagers
1 2 3

4 5

6 7 8 9 10 11 12 13 14 15 16 17 18

- (void)viewDidLoad { BOOL locationAvailable = [CLLocationManager locationServicesEnabled]; if(locationAvailable){ CLLocationManager *locationManager = [[CLLocationManager alloc] init]; locationManager.desiredAccuracy = kCLLocationAccuracyBest; locationManager.distanceFilter = 3000; locationManager.delegate = self; } } - (void)viewWillAppear:(BOOL)animated { [locationManager startUpdatingLocation]; } -(void)viewWillDisappear:(BOOL)animated { [locationManager stopUpdatingLocation]; }

6.2.8. Ziehen zum neu laden (Autor: Christopher Ezell)

Das Feature, was in dieser Ausarbeitung Pull to Reload genannt wird, bezeichnet die Mglichkeit, ein fr 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 Nutzerfhrung, wenn dieses Feature in einer solchen Applikation nicht vorhanden ist.

145

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 6.6.: Funktion Ziehen zum neu laden (Quelle: Eigene Darstellung) Es wird benutzt, indem eine Table-View weiter nach unten gescrollt wird, als normalerweise mglich wre. 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 vorhanden ist. Nun wird in einer der vom User angepassten Geschwindigkeit ein Bereich angezeigt, der keinen Inhalt enthlt. 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 ausgefhrt wird. Wenn die View weit genug gezogen wurde, erscheint der Text in Abbildung 6.7. Wenn der Nutzer nun loslsst, werden die Daten neu geladen und der Text verschwindet.

Abbildung 6.7.: Funktion Ziehen zum neu laden Teil 2 (Quelle: Eigene Darstellung) Fr diese Funktionalitt wurde die Bibliothek EGORefresh genutzt109 . Diese bietet eine Unterklasse der Klasse UIView, nmlich EGORefreshTableHeaderView. Die View, die dieses Feature untersttzen soll, muss nicht von UIView erben, sondern von EGORefreshTableHeaderView. Die Klasse bietet ein delegate, welches von dem aktuellen ViewController implementiert wird. Dadurch werden die Methoden aus Listing 6.37 automatisch aufgerufen und es knnen hierbei die Daten erneuert werden. Listing 6.37: Die Methoden von EGORefreshTableHeaderView
1 2 3

- (void)refreshLastUpdatedDate; - (void)egoRefreshScrollViewDidScroll:(UIScrollView *) scrollView; - (void)egoRefreshScrollViewDidEndDragging:(UIScrollView *) scrollView; - (void)egoRefreshScrollViewDataSourceDidFinishedLoading:( UIScrollView *)scrollView;

109 siehe

https://github.com/enormego/EGOTableViewPullRefresh

146

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 6.8.: Klassendiagramm ZXing (Quelle: Eigene Darstellung)

6.2.9. QR-Code-Parser (Autor: Christopher Ezell)

Fr die Umsetzung des QR-Code-Feature wurde das Framework ZXing110 verwendet. Es bietet eine sehr generische Mglichkeit alle Arten von Standardinhalten von QR-Codes zu parsen. ZXing kann standardmig folgende Inhalte parsen: Text, Email-Adressen, vCards und Links. Es gibt auch die Mglichkeit eigene Parser einzubinden. Wie Abbildung 6.8 zeigt, besteht ZXing aus einem UniversalResultParser, der mehrere ResultParser aufnehmen kann. Nachdem alle vorhandenen Parser (abgeleitet von ResultParser) mit registerParser in der Klasse UniversalResultParser registriert wurden, kann mit der Methode parseResult ein QR-Code geparst werden. Um nun eigene Datentypen mit dem ZXing-Framework zu parsen, mssen eigene Implementationen fr die Klassen ResultParser, ParsedResult und Action geschrieben werden. Danach muss noch der neue ResultParser bei dem UniversalResultParser in der
110 ausgeprochen

Zebra Crossing [sro12]

147

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell)

Abbildung 6.9.: Klassendiagramm ZXing-Extention (Quelle: Eigene Darstellung) Liste der Parser eingefgt werden. Fr 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 fr das Parsen eines Tasks erstellt und diese Klassen wurden in das Framework eingebaut. Durch diese Integration werden nun beim abfotograeren 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. Hierfr ist eine Methode in der Klasse TaskResultParser vorgesehen, die im Listing 6.38 dargestellt ist. Wenn diese Methode parsedResultForString etwas anderes als nil zurck gibt, wird davon ausgegangen, dass ein Task geparst werden konnte. Dies ist der Fall, wenn die Methode initWithString aus der Klasse TaskParsedResult ein Objekt zurck gibt. Das ist in Listing listingXINGbasic2 dargestellt. Es prft, ob der bergebene String mit task: beginnt. Dies ist die Konvention der generierten QR-Codes fr einen Task.

1 2

Listing 6.38: Die Methode parsedResultForString + (ParsedResult *)parsedResultForString:(NSString *)s format:(BarcodeFormat)format { return [[[TaskParsedResult alloc] initWithString:s] autorelease]; }

148

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) Listing 6.39: Die Methode initWithString der Klasse TaskParsedResult
1 2 3 4 5 6 7 8 9 10 11 12 13 14

- (id)initWithString:(NSString *)s { if ((self = [super init]) != nil) { NSRange range = [s rangeOfString:@"task:"]; if (range.length > 0){ NSUInteger i = range.location + range.length; NSString* sub = [s substringFromIndex:i]; self.text = sub; }else { return nil; } } return self; } Wenn nun ein QR-Code eingelesen und als Task erkannt wird, soll dieser gleich angezeigt werden. Innerhalb des ZXing-Frameworks wird die Unterklasse OpenTaskAction111 angesprochen und die Methode clickedButtonAtIndex aufgerufen. In dieser wird die Notication showTask erstellt und der Name des extrahierten Tasknamen an die Notication angehangen. Das ist in Listing 6.40 dargestellt. Die Notication wird in der Klasse QrCodeView gefangen. Mit dem bergebenen Namen wird der entsprechende Task aus dem Model herausgesucht und mit der Methode presentModalViewController angezeigt (siehe Listing 6.41). Listing 6.40: Posten einer Notication - (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex { if (buttonIndex != [alertView cancelButtonIndex]) { NSNotification *notification = [NSNotification notificationWithName:@"showTask" object:self. taskname]; [[NSNotificationCenter defaultCenter] postNotification :notification]; } } Listing 6.41: Parsen eines Tasks - (void)showTask:(NSNotification *)notification{ NSEnumerator *enumerator = [[[InstantScrumModelFacade getInstance] taskList] objectEnumerator]; id object; while ((object = [enumerator nextObject])) { NSString *comparestring = ((NSString *)notification. object); if ([object isKindOfClass:[Task class]]){ Task *task = ((Task *) object); if ([task.taskID isEqualToString:comparestring]) { modelfacade.currentTask = task;
111 aus

2 3

5 6

1 2

3 4 5

6 7 8 9

Abbildung 6.9

149

6.2. Implementierung der iPhone-App (Autoren: Rene Kassel und Christopher Ezell) NSString* username = modelfacade.currentTask. taskName; TaskController* taskc = [[TaskController alloc ] initWithNibName:@"TaskControllerView" bundle:nil]; [self presentModalViewController:taskc animated:YES]; } } } }

10

11

12

13 14 15 16

6.2.10. Push-Notications (Autor: Christopher Ezell)

Die Implementierung der Push-Notication ist auf der Clientseite sehr viel einfacher als auf der Serverseite. Wenn alle Prole richtig konguriert sind, kann im Quellcode der iPhoneAnwendung 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 scheitern oder erfolgreich sein. Wenn sie gescheitert ist, wird die Methode aus Listing 6.44 aufgerufen. Im positiven Fall wird dagegen die Methode didRegisterForRemoteNotificationsWithDeviceToken aus dem Listing 6.43 aufgerufen und ein Token wird als Parameter zurckgegeben. Dies kann anschlieend 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 Notication Token [[UIApplication sharedApplication] registerForRemoteNotificationTypes: ( UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)]; Listing 6.43: Erhalten eines Push Notication Tokens - (void)application:(UIApplication*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData*) deviceToken { NSLog(@"My token is: %@", deviceToken); } Listing 6.44: Empfangen eines Push Notication Errors auf der Clientseite - (void)application:(UIApplication*)application didFailToRegisterForRemoteNotificationsWithError:(NSError*) error
112 Letztendlich muss das Token ber einen Mechanismus an den Server bertragen werden, da er das Token fr den

1 2

3 4

1 2

3 4 5

1 2

Push bentigt.

150

6.3. Implementierung Build und Continious Integration (Autor: Christopher Ezell) { NSLog(@"Failed to get token, error: %@", error); } Wenn eine solche Push-Benachrichtigung eintrifft, wird die Methode

3 4 5

didReceiveRemoteNotification aufgerufen. Der Parameter userInfo enthlt alle Daten inklusive der Notication. Diese Daten mssen noch extrahiert werden. So kann immer auf eine Remote-Push-Notication reagiert werden, auch wenn die Applikation nicht gestartet ist. Listing 6.45: Empfangen einer Push Notication auf Clientseite - (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *) userInfo;

1 2

6.3. Implementierung Build und Continious Integration (Autor: Christopher

Ezell)

Da in einem agilen Projekt ein schnelles Feedback von Neuerungen und nderungen im eingecheckten Quellcode sehr wichtig sind113 , spielt die CI eine besonders wichtige Rolle und sollte die zentrale Anlaufstelle fr 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 erklrt. Es wird hier nur auf den Build der Serverkomponente eingegangen. Sie ist durch den groen Umfang und die Komplexitt auch die aufwndigste Build-Komponente. Der Build des instantscrum-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.xml
1 2 3 4 5 6 7 8 9

<modules> <module>parent</module> <module>common</module> <module>basemodel</module> <module>storageconnector</module> <module>streamconnectors</module> <module>services</module> <module>instantscrum-web</module> </modules>

113 siehe

Kapitel 3.5

151

6.3. Implementierung Build und Continious Integration (Autor: Christopher Ezell) Die einzelnen Module sind die folgenden: instantscrum Dieses Modul enthlt das gesamte Projekt und stt die anderen untergeordneten Builds in der berechneten Reihenfolge an114 . parent Das "parentModul enthlt alle wichtigen Basiseigenschaften fr das Projekt und bildet so einen denierten Rahmen, um den gesamten Build laufen zu lassen. Des Weiteren werden hier alle globalen Properties gesetzt, die bentigten zustzlichen MavenRepositories angegeben und Prole angelegt. Diese Prole knnen genutzt werden, um spezielle Eigenschaften an eine spezielle Umgebung anzupassen115 . common Nach den beiden Verwaltungsmodulen ist das common-Modul das erste, was Quellcode enthlt. 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 Funktionalitt der Datenklassen ausgefhrt. Am Ende dieses Moduls steht ein Paket, welches von der Datenbank 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 verwendeten 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 Funktionalitten, die nicht direkt in den oberen Services erledigt werden sollen. Zu den eingebundenen Funktionalitten gehren 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 erfllen und
114 Dies 115 Ein

wird in Maven der Reactor-Build genannt Beispiel wre hier der lokale Build am Entwicklerrechner und der Build auf der CI-Umgebung.

152

6.3. Implementierung Build und Continious Integration (Autor: Christopher Ezell) zu implementieren. Auf diesen beiden Modulen basiert die gesamte Geschftslogik der Web-Anwendung. instantscrum-web In diesem Modul werden alle vorher genannten Module verwendet und die Funktionalitt wird durch eine Web-API zur Verfgung gestellt. Das Modul instantscrum-web ist das Modul fr die Integrationstests der Anwendung. Hier wird nun die Umsetzung der im Kapitel 5.6 vorgestellten Integrationstests vorgenommen. Bevor diese Tests durchlaufen werden knnen, muss eine komplett lauffhige Umgebung der spteren Web-Applikation erstellt werden. Durch diese Anforderungen ist der Gesamtaufbau der pom.xml etwas komplexer und wird im Detail im Folgenden erlutert. Die vollstndige pom.xml kann im Anhang B.1 gefunden werden. Listing 6.47 zeigt den grundlegenden Aufbau der pom.xml. Das packaging ist auf war gesetzt. Dadurch wird am ende eine .war Datei erzeugt, die alle referenzierten Abhngigkeiten beinhaltet. Diese Datei kann dann auf einen Applikationsserver deployed werden. Listing 6.47: Pom.xml des Projektes instantscrum-web
1 2 3 4 5 6 7 8 9 10 11 12

<project> <artifactId>instantscrum-web</artifactId> <packaging>war</packaging> <name>instantscrum-web Maven Webapp</name> <parent> <groupId>de.crossbeanmedia.instantscrum</groupId> <artifactId>parent</artifactId> <version>0.0.1-SNAPSHOT</version> <relativePath>../parent</relativePath> </parent> ... </project> Die bentigten Ressourcen werden in der Sektion <build>...</build> konguriert. Zu sehen ist dies im Listing 6.48. Es ist so konguriert, dass alle Ressourcen im Ordner src/main/java/META-INF, die mit .xml aufhren, mit in die war aufgenommen werden. Hier bendet sich unter anderem die web.xml, in der Jersey konguriert ist. Auerdem werden noch alle Dateien in src/main/resources/ mit aufgenommen. Hier nden sich unter anderem die Konguration fr das Logging und die Property-Dateien fr die Umgebung. Listing 6.48: Pom.xml des Projektes instantscrum-web (resources)

1 2 3 4 5 6 7 8

<build> ... <resources> <resource> <directory>src/main/java/META-INF</directory> <includes> <include>**.xml</include> </includes>

153

6.3. Implementierung Build und Continious Integration (Autor: Christopher Ezell) <filtering>true</filtering> </resource> <resource> <directory>src/main/resources/</directory> <filtering>true</filtering> </resource> </resources> ... </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 deniert. Ein Beispiel wre der Name des Servers, der auf glasssh3x 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 gestartet 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. Anschlieend wird nach dieser Phase der Server und die Datenbank wieder gestoppt. Listing 6.49: Pom.xml des Projektes instantscrum-web (Cargo Plugin) <plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <version>1.1.2</version> <configuration> <wait>false</wait> <container> <containerId>glassfish3x</containerId> </container> <deployer> <deployables> <deployable> <groupId>de.crossbeanmedia.instantscrum</groupId> <artifactId>instantscrum-web</artifactId> <type>war</type> </deployable> </deployables> </deployer> </configuration> <executions> <execution> <id>start-container</id> <phase>pre-integration-test</phase> <goals>
116 Das

9 10 11 12 13 14 15 16 17

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Cargo-Plugin fr Maven (siehe auch http://cargo.codehaus.org/Maven2+plugin) von Codehaus ist ein sehr mchtiges Tool zum automatisieren von Schritten zum Starten und Deployen von Webcontainern.

154

6.4. Zusammenfassung (Autor: Rene Kassel) <goal>start</goal> <goal>deploy</goal> </goals> </execution> <execution> <id>stop-container</id> <phase>post-integration-test</phase> <goals> <goal>stop</goal> </goals> </execution> </executions> </plugin>

25 26 27 28 29 30 31 32 33 34 35 36 37

6.4. Zusammenfassung (Autor: Rene Kassel)

In diesem Kapitel wurden ausgewhlte Teile der Implementierung dargestellt. Dabei wurde ein Einblick gegeben, wie die in der Konzeption spezizierte Plattform umgesetzt wurde. Es wurde auf die verwendeten Technologien eingegangen und es wurde jeweils an Beispielen die Funktionsweise erlutert. Im nchsten Kapitel soll nun diese Umsetzung mit den im Kapitel 4 denierten 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 Interaktionsmglichkeiten zwischen den Nutzern. Es wurde hierzu die Erstellung der vorliegenden Masterarbeit als Beispiel verwendet. Die Funktionalitt wird anhand der im Kapitel denierten User Stories geprft 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 Funktionalitt 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 Funktionalitten der App. Das Logo der App, was in Abbildung 7.2 zu sehen ist, bendet sich im Hintergrund des Login-Bildschirms.

Abbildung 7.1.: Screenshot des Loginscreens (Quelle: Eigene Darstellung) Damit sind alle Abnahmekriterien aus der User Story erfllt.

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. Erstere beschftigen sich mit dem Taskbezogenen Funktionen, wie Task einsehen, Task erzeugen und Task kongurieren. Zweitere beschreiben die Funktionalitten bezglich der Arbeitszeit. Zunchst ist in Abbildung 7.3 eine bersicht ber alle Projektbezogenen Tasks zu sehen. Dabei beinhaltet jede Zelle genau einen Task. Eine Zelle zeigt den Tasknamen, den geschtzten Arbeitsaufwand sowie die bisherig investierte Arbeitszeit an. Zur besseren bersichtlichkeit gibt es eine Statusanzeige mit grn, gelb und rot sowie ein Fortschrittsbalken bezogen auf die Arbeitszeit. Es ist mglich, 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 Abbildung 7.4 dargestellt. Hier gibt es Informationen zum Worklog, zur Verantwortlichkeit sowie diverse Button, welche eine bestimmte Funktionalitt ausfhren. Assign User weist einen bestimmten Nutzer die Aufgabe zu. ber log work lsst sich, wie der Name schon sagt, die gettigte Arbeitszeit eintragen. ber PlanningPoker soll es die Mglichkeit zum Schtzen 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 CommitButton in der oberen, rechten Ecke wird die Arbeitszeit endgltig erfasst. Auch das Anlegen eines Tasks ist mglich. 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 zunchst die Mglichkeit, einen Tasknamen und eine Taskbeschreibung abzugeben. 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 groen Teil erfllt. Die Umsetzung der kompletten User Story mit seinen Spezikationen ist jedoch aus Zeitmangel und da es sich lediglich um einen Prototypen handelt, nicht durchgefhrt worden.

7.3. Ein Chat mit der iPhone App (Autor: Christopher Ezell)
Der Nutzer geht weiter entlang der Funktionalitten der App und testet den Chat. Dies ist der Abnahmetest fr die User Stories 15 und 16. Sie denieren den Ablauf eines Chatgesprches mittels der iPhone-Applikation. Abbildung 7.7 zeigt den Screenshot der Chatliste. Es gibt fr jeden Nutzer ein Foto und durch die Einordnung in die verschiedenen Sektionen Available und Ofine ist ersichtlich, welcher Kontakt verfgbar ist. Wird nun auf eine Zelle eines Available-Kontakt geklickt, wird eine View mit einer Chatansicht sichtbar. Hier kann der Nutzer mit dem angeklickten Nutzer in Kontakt treten. Zu sehen ist dies in Abbildung 7.8. Oben in der Mitte ist der Name des Chatpartners zu sehen. Im Hauptfenster

158

7.3. Ein Chat mit der iPhone App (Autor: Christopher Ezell)

Abbildung 7.5.: Screenshot der Ansicht zur Arbeitszeiterfassung (Quelle: Eigene Darstellung)

Abbildung 7.6.: Screenshot zum Anlegen eines Tasks (Quelle: Eigene Darstellung)

159

7.4. Anzeigen des Build-Status (Autor: Rene Kassel)

Abbildung 7.7.: Screenshot von Chatlistenansicht (Quelle: Eigene Darstellung) ist eine TableView mit Custom Cells, welche die Nachrichten beinhalten mit einem Zeitstempel. Beim Klick auf das Eingabefeld im unteren Bereich der Abbildung fhrt 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 knnen, sind die Zellen mit unterschiedlichen Farben versehen. Entsprechend der Abnahmekriterien aus den User Stories sind alle Anforderungen erfllt.

7.4. Anzeigen des Build-Status (Autor: Rene Kassel)

Eine nchste Funktion, welche durch den Nutzer getestet wird, ist die Anzeige des Buildstatuses des zu implementierenden Projektes. Einzelheiten dazu sind in User Story 5 beschrieben. Das Aussehen dieser Ansicht ist in Abbildung 7.9 zu sehen. Hier ndet sich eine Unterteilung in verschiedene Projekte. Jedes einzelne Projekt ist anklickbar, wodurch eine neue Sicht geffnet wird, welche Detailinformationen zu dem Projekt enthlt. Diese Detailinformationen bestehen aus: Testquote: Wie viele Tests von wie vielen sind fehlgeschlagen? Build-Status: Wann schlug der letzte Build fehl? Wann war der letzte / erfolgreiche / stabile Build? Diese Ansicht ist nochmals in Abbildung 7.10 veranschaulicht.

160

7.4. Anzeigen des Build-Status (Autor: Rene Kassel)

Abbildung 7.8.: Screenshot von einem Chat mit einem User (Quelle: Eigene Darstellung)

Abbildung 7.9.: Screenshot der Buildeinsicht (Quelle: Eigene Darstellung)

161

7.5. Die Verwendung der Lokationsdienste (Autor: Christopher Ezell)

Abbildung 7.10.: Screenshot ber die Detailansicht eines Builds (Quelle: Eigene Darstellung) Auch an dieser Stelle wurden zunchst alle Abnahmekritieren, deniert durch die User Story, erfllt.

7.5. Die Verwendung der Lokationsdienste (Autor: Christopher Ezell)

Eine nchste 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 Mnchen. Der derzeitige Standort ist noch in Berlin. Der Nutzer hat nun die Mglichkeit seinen Standort zu aktualisieren, indem er auf den updateButton klickt und eine Notiz zum Standort eingibt. Die Positionsdaten werden aus dem GPSSensor des Gertes entnommen. Die Abfrage sieht zur Zeit so aus, wie sie in Abbildung 7.12 dargestellt ist. Die in den User Stories beschriebene Funktionalitt sowie alle Abnahmekriterien sind damit erfllt.

162

7.5. Die Verwendung der Lokationsdienste (Autor: Christopher Ezell)

Abbildung 7.11.: Screenshot der Mapfunktionalitt (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 knnen 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 Newsstream. Eine Neuigkeit besteht aus einem Namen, der Nachricht, einem Ort und einem Zeitstempel. 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 Mglichkeit, 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 fr diese beiden User Stories sind mit den beiden Ansichten vollkommen erfllt. Die Benachrichtigungen per Push und e-Mail sind jetzt hier nicht dargestellt. Diese Funktionalitten werden in einem spteren Kapitel noch mal separat behandelt (Kapitel 7.9).

7.7. Einsicht in Userdaten (Autor: Rene Kassel)

Die Einsicht in die Nutzerdaten sind die nchste Haltestelle dieses Anwendungsfallsbeispiels. Der Nutzer kann zum einen eine Userliste abrufen, wo alle Projektzugehrigen gelistet sind und zum anderen Informationen zu einzelnen Usern abrufen. Die genaueren Vorgaben dazu sind in den User Stories 13 und 14 deniert. 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: Eigene Darstellung)

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 Mglichkeit, 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 Mglichkeit ber einen Button wieder zur Userliste zurckzukehren. Die Funktionalitt entspricht vollstndig der denierten aus den User Stories. Jedoch wurde an dieser Stelle noch eine kleine Verbesserung vorgenommen. Die Userdetails sind von jedem Nutzer durch den Klick auf diesen zu ffnen.

7.8. QR-Code Scan (Autor: Christopher Ezell)

In seiner Geschichte geht der Nutzer weiter zu dem QR-Code Scan. Dieses Feature ist gedacht, um Zugriff auf einzelne Tasks ber einen QR-Code zu bekommen. Dabei handelt es sich um ein Versuch, diese neue Technik zu integrieren, um ein komfortables und schnelles Aufnden von Tasks zu ermglichen. In der User Story 17 ist dieses Feature genauer speziziert. Abbildung 7.18 zeigt den Screenshot vom iPhone. Der QR-Code wird dabei in das weie Viereck gebracht, woraufhin der Code eingelesen wird. Hinter dem Code verbirgt sich die Task-ID. Nach dem Scan wird der Nutzer weiter geleitet zu dem entsprechenden Task. Der volle beschriebene Funktionsumfang der User Story wurde an dieser Stelle umgesetzt.

166

7.8. QR-Code Scan (Autor: Christopher Ezell)

Abbildung 7.17.: Screenshot Userdetail (Quelle: Eigene Darstellung)

Abbildung 7.18.: Screenshot des QR-Code Scans (Quelle: Eigene Darstellung)

167

7.9. Benachrichtigungssystem der App (Autor: Christopher Ezell)

7.9. Benachrichtigungssystem der App (Autor: Christopher Ezell)

Weitere Funktionalitt stellt die App durch ihre automatisierten Benachrichtigungen bereit. Dabei 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 korrigiert. Die Nachricht wird automatisch gesendet, wenn der Nutzer etwas in den Newsstream verffentlicht. 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 dazugehrige Spezizierung. 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 zugeordnet wird. Dabei erhlt der betroffene Nutzer sowohl eine Push-Benachrichtigung als auch eine Benachrichtigung per e-Mail. Damit ist das Risiko, dass er diese wichtige Information nicht erhlt bzw. nicht wahrnimmt, abgeschwcht.

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 Rahmen des Prototypen erfllt worden.

7.10. Notizenverwaltung (Autor: Christopher Ezell)

Weiterhin wird die Notizverwaltung auf eine Abnahme hin geprft. Die Bedingungen dafr 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. Fr 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 Notizberschrift. Zustzlich ist in der Zelle eine 2-zeilige Vorschau zum Inhalt zu sehen.

Abbildung 7.20.: Screenshot der Notizverwaltungsbersicht (Quelle: Eigene Darstellung) Der Nutzer hat nun die Mglichkeit eine Notiz anzuklicken, um diese einzusehen. Das ist in Abbildung 7.21 zu sehen. In dieser Ansicht hat er die Mglichkeit, den Inhalt zu verndern 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 verndern mchte. Entsprechend der in den User Stories denierten Vorgaben wurden alle Funktionen prototypisch umgesetzt sowie alle Abnahmekriterien erfllt.

7.11. Einsicht in Bookmarks (Autor: Rene Kassel)

Dieses Kapitel befasst sich mit dem Abnahmetest der in User Story 22 vorgegebenen Kriterien. Zunchst sieht der User eine Liste von erstellten Tags, nach denen die Bookmarks klassiziert werden. Dort kann er bereits eine Vorauswahl treffen, zu welcher Thematik er geteilte Links einsehen mchte. 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 gedrckt. Die Linkliste ist in Abbildung 7.23 zu sehen. Klickt der Nutzer wiederum auf einen bestimmten Link, gelangt er in eine integrierte Webansicht, welche die Webseite prsentiert, die hinter dem Link steht. Abbildung 7.25 zeigt die Webansicht.

169

7.11. Einsicht in Bookmarks (Autor: Rene Kassel)

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

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

170

7.11. Einsicht in Bookmarks (Autor: Rene Kassel)

Abbildung 7.23.: Screenshot der Bookmarks innerhalb eines Tags (Quelle: Eigene Darstellung)

Abbildung 7.24.: Screenshot der der Webansicht innerhalb eines Bookmarks (Quelle: Eigene Darstellung)

171

7.12. Ausloggen des Users (Autor: Rene Kassel) Im groen und ganzen sind alle Anforderungen aus der User Story erfllt. 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 Userinfo ber einen Button ausloggen und wird dadurch am System abgemeldet. Es handelt sich bei diesem Kapitel um den Abnahmetest fr die User Story 2.

Abbildung 7.25.: Screenshot der Useransicht mit Logoutbutton (Quelle: Eigene Darstellung)

7.13. Zusammenfassung (Autor: Christopher Ezell)

Anhand dieser kleinen Anwendungsgeschichte wurde dem Leser beispielhaft die Funktionalitt des Prototyps prsentiert. Zudem diente das Beispiel als eine Art Abnahmetest fr die in Kapitel 4 denierten User Stories. Nach dieser Ergebnisprsentation 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 abschlieende Betrachtung und Bewertung des Projektes. Zudem wird kurz auf zuknftige Aspekte eingegangen.

8.1. Abschlussbetrachtungen
Das Ziel der Arbeit war die Analyse, wie sich Entwickler in agilen Softwareprojekten durch die Verwendung moderner Kommunikationsmittel besser verstndigen knnen, um die Kommunikation im Projekt zu frdern. Dafr wurde betrachtet, welche Mglichkeiten existieren, virtuelle Teams mittels einer mobilen Projektplattform zu untersttzen. Es wurde analysiert, welche Kommunikationsmittel in einem verteiltem Umfeld dafr geeignet sind, die Teammitglieder optimal zu untersttzen. Auf Grundlage dieser Erkenntnisse wurde ein Prototyp einer Projektplattform zur Kommunikation und sozialen Interaktion umgesetzt. Dieser soll es ermglichen, mittels einer Smartphone-App den Benutzer mit seinen Teammitgliedern in Kontakt zu bringen und durch eine verbesserte soziale Interaktion117 in einem verteilten Umfeld den Zusammenhalt in der Gruppe zu strken und das Vertrauen zu verbessern. Hierzu wurden verschiedene Kommunikationsmittel auf ihre Tauglichkeit hin analysiert und nach eigenen Kriterien fr diese Plattform ausgewhlt. Die Untersuchung zur Wirksamkeit dieser Applikation war nicht Teil dieser Arbeit.

8.2. Resumee
Abschlieend 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 fr diese Arbeit die Programmiersprache Ojective-C und der Umgang mit der Programmierumgebung Xcode erlernt. Dies stellte an einigen Punkten eine groe Herausforderung und einen groen Zeitaufwand dar. Es musste auch der Inhalt der Arbeit gekrzt werden, um in dem gesteckten Zeitrahmen die Arbeit fertig zu stellen.Durch diese zeitlichen Probleme konnte keine Auswertung durchgefhrt werden, inwieweit diese Plattform die untersuchten Faktoren in einem virtuellen Team verbessert.

117 Die

soziale Interaktion ist durch das Anwenden der App verbessert.

173

8.3. Erweiterungsmglichkeiten Die Bearbeitung war sehr spannend, weil die Autoren dieses Thema selbstndig gewhlt haben und somit ein groer persnlicher Anreiz existierte, das Thema so umfnglich wie mglich zu verwirklichen. Es war fr die Autoren trotz der am Ende auftretenden zeitlichen Probleme eine sehr schne Aufgabenstellung und hat viele weitere Ideen in diese Richtung hervorgebracht. Die Verwendung der in der Arbeit analysierten Tools hat einen groen Vorteil in der Bearbeitung der Arbeit gebracht. Das stand im unmittelbaren Zusammenhang damit, dass die Autoren verteilt diese Arbeit entwickelten und konzipierten. Parallel zur Umsetzung bekamen die beiden 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 spteren 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 regelmige Statusupdates wurde immer das Gefhl vermittelt, den anderen noch zu verstehen. Durch die positiven Erfahrungen whrend der Entwicklung und der gleichzeitigen Nutzung der Tools sind die Autoren der Meinung, dass diese Art von Software eine groe Zukunft hat und diese Art der Kommunikation immer populrer 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 Zeitmangel nicht mehr umgesetzt werden konnten, wrden den Nutzen der Applikation nochmals immens steigern.

8.3. Erweiterungsmglichkeiten
Die im Rahmen dieser Arbeit umgesetzte Plattform hat nur einen sehr kleinen Teil der potentiellen Mglichkeiten umgesetzt. Ein erster Schritt ist die Umsetzung der nicht implementierten Features aus dem Konzeptionskapitel 5. Weitere Punkte sind eine noch hhere Integration in das Backendsystem und eine bessere Benutzeroberchensteuerung. Es knnten noch sehr viel mehr Dienste und Funktionalitten in die App eingebaut werden, die den User in seinem Projektalltag noch besser untersttzen. Eine groe Erweiterung der Plattform ist die Untersttzung von Tablets oder gleich der Umstieg von einer nativen App hin zu einer universellen Web-App. Dies htte den groen Charme der Plattformunabhngigkeit. Die implementierten Dienste und Konnektoren knnen noch weiter miteinander verwoben werden. Viel mehr Ablufe innerhalb der Plattform knnen automatisiert ablaufen. Ein Beispiel dafr 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-Funktionalitt. Hier knnten Audioaufzeichnungen und Notizen zu den einzelnen Meetings und Statusupdates

174

8.3. Erweiterungsmglichkeiten in einer chronologischen Liste erscheinen. Dadurch knnen sie von Projektmitgliedern nochmals angehrt werden. Das kann besonders wichtig sein, wenn sie auf Reisen sind oder den Termin aus anderen Grnden nicht wahrnehmen konnten. Somit sind sie nicht auf E-Mails und direkte Nachfragen angewiesen und knnen die Original-Meetings verfolgen. Dies schafft Zeitvorteile, die fr andere Aktivitten genutzt werden knnen.

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 Stackoverow. Website, 2012. http://www.alexa.com/

siteinfo/stackoverflow.com [ale12b] Alexa Web Information Plattform. Website, 2012. http://www.alexa. com/ [AM11] A ARON, Hillegass ; M ARK, Fenoglio: Objective-C Programming: The Big Nerd Ranch Guide. Addison-Wesley Professional, 2011 http://www. openisbn.com/price/9780321706287/. ISBN 9780321706287 [Ame12] A MELING, Dr. M.: Motivationsschub - Geschftsanwendungen durch Spielelemente verbessern. In: iX - Magazin fuer Informationstechnik 09 (2012), August, S. 104 [App12a] A PPLE: Apple Core Location Guide. Website, 2012. http:

//developer.apple.com/library/ios/#DOCUMENTATION/ UserExperience/Conceptual/LocationAwarenessPG/ CoreLocation/CoreLocation.html [App12b] A PPLE: Apple Push Notication Service. Website, 2012. http:

//developer.apple.com/library/mac/#documentation/ NetworkingInternet/Conceptual/RemoteNotificationsPG/ ApplePushService/ApplePushService.html [App12c] A PPLE: Messaging. Website, 2012. https://developer.apple. com/library/mac/#documentation/Cocoa/Conceptual/ ObjCRuntimeGuide/Articles/ocrtHowMessagingWorks.html [App12d] A PPLE: Objective-C Delegation. Website, 2012. https://developer. apple.com/library/mac/#documentation/General/ Conceptual/DevPedia-CocoaCore/Delegation.html [Azt97a] Aztec Code - Example. Website, 1997. http://www.waveform.ie/ _fileUpload/Image/Aztec_Code.JPG

XVIII

Quellenverzeichnis [Azt97b] Aztec Code - United States Patent US5591956. Website, 1997. http:// www.freepatentsonline.com/5591956.pdf [BDMM10a] B ROMBACH, Guido ; D EMUTH, Ute ; M UUSS -M ERHOLZ, Jran: Kollaboratives Schreiben I: berblick. Website, November 2010. http://pb21.de/ 2010/11/kollaboratives-schreiben-i-uberblick/ [BDMM10b] B ROMBACH, Guido ; D EMUTH, Ute ; M UUSS -M ERHOLZ, Jran: Kollaboratives Schreiben II: Etherpad. Website, November 2010. http://pb21.de/ 2010/11/kollaboratives-schreiben-ii-etherpad/ [Bec99] B ECK, 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] B UNDESPRFSTELLE: le Rume. Faszination Onlinespiel: Virtuelle Welten als soziahttp://www.bundespruefstelle.

Website, 2012.

de/bpjm/Jugendmedienschutz-Medienerziehung/ computer-konsolenspiele,did=166746,render= renderPrint.html [CCG+ 07] C ANFORA, Gerardo ; C IMITILE, Aniello ; G ARCIA, Felix ; P IATTINI, Mario ; V ISAGGIO, Corrado A.: Evaluating performances of pair designing in industry. In: Journal of Systems and Software (2007) [CHH10] C OHN, M. ; H ESSE -H UJBER, M.: 9783826658983 [Coh04] C OHN, 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. User Stories; PR:. mitp-Verlag, 2010 ISBN

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

http://lernenheute.wordpress.com/2009/03/17/ etherpad-das-klassen-notizbuch/ [Coma] C OMMUNITY, Dropbox: How do I recover old versions of les? Website, . https://www.dropbox.com/help/11/en [Comb] C OMMUNITY, Dropbox: What is Packrat? Website, . https://www. dropbox.com/help/113/en

XIX

Quellenverzeichnis [Comc] C OMMUNITY, GlassFish: Glasssh. Website, . http://glassfish. java.net/ [Com12a] C OMMUNITY, Jersey: jersey.java.net/ [Com12b] C OMMUNITY, Restkit: iOS REST-Binding Framework. Website, 2012. http: //restkit.org [Com12c] C OMPUTERWOCHE: Freiberuer-Studie 2011. Website, 2012. http:// www.computerwoche.de/karriere/freiberufler/2499858/ [CW00] C OCKBURN, Alistair ; W ILLIAMS, Laurie: The Costs and Benets of Pair Programming. Website, 2000. http://collaboration.csc.ncsu.edu/ laurie/Papers/XPSardinia.PDF [Eck09] E CKSTEIN, J.: Agile GmbH, Softwareentwicklung mit verteilten Teams. Jesery Framework. Website, 2012. http://

Dpunkt.Verlag

2009

http://books.google.de/books?

id=fWy1PwAACAAJ. ISBN 9783898646307 [ecl12] Eclipse Link Home. eclipselink/ [Eco01] E CONOMIST, The: Agility counts. Website, 2001. http://www. Website, 2012. http://www.eclipse.org/

economist.com/node/779429?Story_ID=779429 [Ese07] E SENGULOV, Aibek: Tools. 7 easy Screen-Sharing and Remote-Access http://www.makeuseof.com/tag/

Website, 2007.

7-easy-screen-sharing-and-remote-access-tools-all-free/ [et.12] ET. AL ., Kent B.: Agiles Manifest. Website, 2012. http://

agilemanifesto.org/ [Fie99a] F IELDING, R.: Hypertext Transfer Protocol HTTP/1.1. RFC, 1999. http: //www.w3.org/Protocols/rfc2616/rfc2616.html [Fie99b] F IELDING, R.: des. Hypertext Transfer Protocol HTTP/1.1 - Status Cohttp://www.w3.org/Protocols/rfc2616/

RFC, 1999.

rfc2616-sec10.html#sec10.2 [Fie00] F IELDING, Roy T.: Architectural styles and the design of network-based http://www.ics.uci.edu/

software architectures, Diss., 2000.

~fielding/pubs/dissertation/top.htm [Flo06] F LOR, Nick V.: Globally distributed software development and pair programming. In: Communications of the ACM (2006) [Fou] Foursquare. Website, . http://www.social-media-wiki.com/

Foursquare.html

XX

Quellenverzeichnis [Fou12a] F OUNDATION, Apache S.: Apache Maven. Website, 2012. http://maven. apache.org/ [Fou12b] F OUNDATION, Etherpad: Collaborate on documents in really real-time. Website, 2012. http://etherpad.org/ [Fou12c] F OUNDATION, Etherpad: Features. Website, 2012. http://etherpad. org/features/ [GLS10] G ROGG, Nadja ; L UBER, Sarah ; S CHREINER, Annina: Vor- und Nachteile eines Wikis. Website, 2010. http://www.learning-in-activity.com/ index.php?title=Vor-_und_Nachteile_eines_Wikis [Gre] G RENNING, James: Planning Poker or How to avoid analysis paralysis while release planning. [Gro99] G ROUP, Network W.: HTTP Extensions for Distributed Authoring WEBDAV. Website, 1999. http://tools.ietf.org/html/rfc2518 [Gro02] G ROUP, Network W.: SIP: Session Initiation Protocol. Website, Juni 2002. http://tools.ietf.org/html/rfc3261 [Gro06] G ROUP, Network W.: The application/json Media Type for JavaScript Object Notation (JSON). Website, 2006. http://tools.ietf.org/html/ rfc4627 [Gro09] G ROUP, Network W.: Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV). html/rfc5689 [Gro12a] G ROUP, Apache: Maven-LifeCycle. Website, 2012. Website, 2009. http://tools.ietf.org/

http://maven.apache.org/guides/introduction/ introduction-to-the-lifecycle.html [Gro12b] G ROUP, Atlassian: Homepage - Atlassian. Website, 2012. http://www. atlassian.com/de/ [Gro12c] G ROUP, Atlassian: Release Notes Conuence 4.2 - Atlassian. Website, 2012. https://confluence.atlassian.com/display/DOC/Likes+ and+Popular+Content [Gro12d] G ROUP, Atlassian: Release Notes Conuence 4.2 - Atlassian. Website, 2012. https://confluence.atlassian.com/display/DOC/Likes+ and+Popular+Content [Hab12] H ABICHT, Sren: Softwaretest. ISTQB, 2012 [Han12] H ANSON, Robbie: XMPPFramework. Website, 2012. https://github. com/robbiehanson/XMPPFramework

XXI

Quellenverzeichnis [Hei08] H EILWAGEN, Andreas: Website, 2008. Die wichtigsten Vor- und Nachteile von Wikis.

http://www.computerwoche.de/management/

it-strategie/1881240/ [Hei12] H EINRICH, Wolfgang: te, 2012. Microblogging fr Unternehmen. Websi-

http://www.medienkompakt.de/index.php/

microblogging-fur-unternehmen/ [HF10] H UMBLE, 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] H ERCZEG, M. ; JANFELD, B. ; K LEINEN, B. ; K RITZENBERGER, H. ; PAUL, M. Wittstock H.: Virtuelle Teams Erkenntnisse ber die Nutzung von Video Conferencing und Application Sharing bei der Untersttzung virtueller Teams / IATGE. Version: 2000. http://www.iatge.de/aktuell/ 2000. Forschungsbericht. Web: veroeff/ps/paul00a.pdf.

http://www.iatge.de/aktuell/veroeff/ps/paul00a.pdf [Hor08] H ORNSTEIN, Martin: E-Collaboration Mehrwerte durch moderne KommuPDF, 2008. http://www.namics.com/

nikationsmittel schaffen.

fileadmin/user_upload/pdf/Wissen/2008/Fachartikel/ E-Collaboration.pdf [HW11] H ENNING W OLF, Arne R.: Agile Softwareentwicklung, Ein berblick.

Dpunkt.Verlag GmbH, 2011 (IT-agile) [Inc12] I NC, Diigo: Diigo API. Website, 2012. http://www.diigo.com/ tools/api [inv03] INVEST site, in 2003. Good Stories, and SMART Tasks. Web-

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 Notication Center. Website, 2012. https://developer.apple. com/library/mac/#documentation/Cocoa/Conceptual/ Notifications/Introduction/introNotifications.html [ITW12] ITW ISSEN: LBS (location based service). Website, 2012.

http://www.itwissen.info/definition/lexikon/

location-based-service-LBS-Ortsbezogener-Dienst.html

XXII

Quellenverzeichnis [Jso] Introducing JSON. Website, . http://www.json.org/ [Kel06] K ELLY, 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 fr iPhone, iPad und iPod touch programmieren: Von der Idee zum App Store; So realisieren und vermarkten Sie Ihre Apps! Franzis, 2010 (Professional Series). http://books. google.de/books?id=RX6jcQAACAAJ. ISBN 9783645600811 [Krz08] K RZYWDA, Andrzej: Remote pair programming. Website, 2008.

http://andrzejonsoftware.blogspot.de/2008/02/

remote-pair-programming.html [K06] KPPEL, Petra: Konikte und Synergien in multikulturellen Teams: Virtuelle und face-to-face-Kooperation. Gabler, 2006. ISBN 3835008730 [Mag11] M AGENHEIMER, Christian: site, 2011. Untersuchung von Kommunikationsprotokollen

fuer Dienstumgebungen in mobilen Anwendungen auf Basis von Android. Webhttp://www.rn.inf.tu-dresden.de/uploads/ Studentische_Arbeiten/Diplomarbeit_Magenheimer_ Christian.pdf [Mik] M IKOGO: Desktop Sharing. Website, . http://www.mikogo.de/ [Mil08] M ILLER, More Claire C.: In: Will The Microblogging New York at Times Work Make You

Productive?

(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] M AASS, Christian ; L EWANDOWSKI, Dirk: Tagging in der Praxis. Website, 2008. Social Bookmarking and http://www.google.

de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved= 0CEwQFjAA&url=http%3A%2F%2Fwww.bui.haw-hamburg. de%2Ffileadmin%2Fuser_upload%2Flewandowski% 2Fdoc%2FSocialBookmarkingundTagginginderPraxis. pdf&ei=RJszUPfzNI7tsgaZ_IDoBA&usg= AFQjCNHbbq3530K-cN8fS6mWs25tfXr9OQ [Mob06] Instant Messenger. Website, April 2006. http://wellman.

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

XXIII

Quellenverzeichnis [Mob12] Instant Messaging. Website, 2012. http://de.wikipedia.org/

wiki/Instant_Messaging [Mor] M ORGENPOST, im Internet. Hamburger: Website, . Foursquare und Co.: Schnitzeljagd

http://www.mopo.de/news/

standortbezogene-netzwerke-foursquare---co---schnitzeljagd-im-in 5066732,5151994.html [MS04] M YERS, Glenford J. ; S ANDLER, Corey: The Art of Software Testing. John Wiley & Sons, 2004. ISBN 0471469122 [MS07] M ICHAELIS, Samuel ; S CHIESIG, Wolfgang: JAXB 2.0. Hanser Verlag, 2007. ISBN 9783446407534 [MW08] M LLER, Bernd ; W HER, Harald: Java-Persistence-API mit Hibernate.

Addison-Wesley, 2008. ISBN 9783827325372 [Mye99] M YERS, Glenford J. ; P IEPER, Manfred (Hrsg.): ten von Programmen. Mnchen [u.a.] : Oldenbourg, 1999 (Reihe Methodisches TesDatenverarbeitung). ISBN

6. Au., unvernd. Nachdr. der 3. Au.

http://gso.gbv.de/DB=2.1/CMD?ACT=SRCHA&SRT=YOP&IKT= 1016&TRM=ppn+254611036&sourceid=fbw_bibsonomy. 3486250566 [MZ09] M ITCHELL, Alanah ; Z IGURS, Ilze: Trust in virtual teams: solved or still a mystery? In: SIGMIS Database 40 (2009), Juli, Nr. 3, 6183. http://dx.doi. org/10.1145/1592401.1592407. DOI 10.1145/1592401.1592407. ISSN 00950033 [OP] O NLINEMARKETING -P RAXIS: te, . instant-messaging [osm12] OSMORPHIS: site, 2012. Enhancing the standard NSXMLParser class. WebDenition Instant Messaging. Websi-

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

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] P ICHLER, R.: zen. Scrum- Agiles Projektmanagement erfolgreich einset-

Dpunkt-Verlag, 2007 http://books.google.de/books?id=

KhoxPQAACAAJ. ISBN 9783898644785 [pir12] Piraten-Pad. Website, 2012. http://www.piratenpad.de/

XXIV

Quellenverzeichnis [PRI11] PRIVATLEBEN, IN BERUF U.: Website, 2011. ALLTAGSFORSCHUNG.DE PSYCHOLOGIE

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

gemeinsames-ziel-die-macht-sozialer-bindungen/ [Prz05] P RZEPIORKA, Sven: Weblogs und Wikis. Website, 2005. http://tzwaen. com/publikationen/vortrag-ueber-weblogs-wikis/ folien.html [Rad10] R ADOFF, Jon: FarmVille invades the real world Real world compaWebsite, 2010. http:

nies invest in the gamication of life. science-tech_and_gadgets/

//www.msnbc.msn.com/id/37451547/ns/technology_and_

[Rad12] R ADOFF, Jon: History of Social Games. Website, 2012. http://radoff. com/blog/2010/05/24/history-social-games/ [Red12] Its Game-on for Business. Website, 2012. http://www.redcritter. com/ [RK07] R ICHTER, Michael ; KOCH, Alexander: Enterprise 2.0: Planung, Einfhrung und erfolgreicher Einsatz von Social Software in Unternehmen. bourg, 2007 Oldenhttp://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 [Sad12] S ADUN, Erica: The IOS 5 Developers Cookbook: Core Concepts And Essential Recipes For IOS. Addison-Wesley Professional, 2012 http://www. openisbn.com/isbn/9780321832078/. ISBN 9780321832078 [SAST09] S AINT-A NDR, P. ; S MITH, K. ; T RONON, R.: XMPP: The Denitive Guide : Building Real-time Applications with Jabber Technologies. OReilly Media, 2009 (Denitive Guide Series). http://books.google.de/books?id= SG3jayrd41cC. ISBN 9780596521264 [Sen01] S ENST, Erik: Virtuelle Teamarbeit. (2001) [Sim12] S IMPERIUM: Simplenote. Website, 2012. http://simplenoteapp. com/ Microblogging. Website, 2009. http:

//searchmobilecomputing.techtarget.com/definition/

XXV

Quellenverzeichnis [SK86] S PROULL, L ; K IESLER, S: Reducing social context cues: electronic mail in organizational communication. In: Manage. Sci. 32 (1986), November, Nr. 11, 14921512. http://dx.doi.org/10.1287/mnsc.32.11.1492. DOI 10.1287/mnsc.32.11.1492. ISSN 00251909 [Sma12] S MALLT REE: Shared Storage. Website, 2012. http://www.

small-tree.com/shared_storage_a/212.htm [Soca] 5 Minute Guide ... Social Bookmarking. 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] S PILLER, M.: Maven 3: Kongurationsmanagement mit Java. mitp/bWebsite, . http:

//www.thealbertalibrary.ab.ca/pdfs/5%20Minute%

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 Stackoverow. Website, 2012. http://stackoverflow.com/ [Tea09] T EAM, Technical J.: Singletons : Is Anti-Pattern? Website, 2009.

http://thetechcandy.wordpress.com/2009/12/02/

singletons-is-anti-pattern/ [Tea12] T EAM, Diigo: Diigo API Referenz. Website, 2012. http://www.diigo. com/tools/api [Thi05] T HIMM, Caja: Virtuelle Teams - Kommunikation in virtuellen Fhrungs-

situationen. http://www.ikp.uni-bonn.de/ZfKM/dgpuk/DGPuK_ Vortrag_Thimm.pdf. Version: 2005 [Til11] T ILKOV, S.: REST und HTTP: Einsatz der Architektur des Web fr Integrationsszenarien. Dpunkt.Verlag GmbH, 2011 http://books.google.de/ books?id=QIHUjwEACAAJ. ISBN 9783898647328 [Tri12] T RIS, 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] V ERIVOX: Standortbezogene Dienste werden immer beliebter. Web-

site, April 2012.

http://www.verivox.de/nachrichten/

XXVI

Quellenverzeichnis standortbezogene-dienste-werden-immer-beliebter-86152. aspx [W3C03] W3C: Extensible Markup Language (XML). Website, 2003. http://www. w3.org/XML/ [W3C08] W3C: Extensible Markup Language (XML) 1.0 (Fifth Edition). Website, November 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] W ELLS, Don: Extreme Programming: A gentle introduction. Website, 2012. http://www.extremeprogramming.org/rules/pair.html [Wie10] W IEST, S.: Continuous Integration mit Hudson: Grundlagen und Praxiswissen fr 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] W ILLIAMS, Laurie: Integrationg Pair Programming into a Software Development Process. Website, 2001. http://collaboration.csc.ncsu. edu/laurie/Papers/Integrating.pdf [Win11] W INTER, M.: Scan Me - Everybodys Guide to the Magical World of Qr

Codes. Westsong Publishing, 2011 http://books.google.de/books? id=s5ZxqwwYKk8C. ISBN 9780965900034 [WK03] W ILLIAMS, L. ; K ESSLER, R.R.: Addison-Wesley, 2003 LRQhdlrKNE8C. ISBN 9780201745764 [ZR09] Z HAO, 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). 243252 S. http://dx. doi.org/10.1145/1531674.1531710. http://dx.doi.org/10. 1145/1531674.1531710. ISBN 9781605585000 Pair Programming Illuminated.

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

XXVII

Quellenverzeichnis

A. Anhang Abbildungen

Abbildung A.1.: Aztec-Code (Quelle: [Azt97a])

Abbildung A.2.: berprfung der Anforderungen mittels Tests (Quelle: [HW11], Seite 5)

XXVIII

Quellenverzeichnis

Abbildung A.3.: Openre 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 Weboberche (Quelle: Eigene Darstellung)

XXXII

Quellenverzeichnis

Abbildung A.10.: Lebenszyklus einer iOS Applikation (Quelle: [Kol10], Seite 41)

XXXIII

XXXIV Quellenverzeichnis Abbildung A.11.: Deployment Server (Quelle: Eigene Darstellung)

XXXV Quellenverzeichnis Abbildung A.12.: Deployment iPhone (Quelle: Eigene Darstellung)

XXXVI Quellenverzeichnis Abbildung A.13.: Use Cases (Quelle: Eigene Darstellung)

XXXVII Quellenverzeichnis Abbildung A.14.: Klassendiagramm Services (Quelle: Eigene Darstellung)

XXXVIII Quellenverzeichnis Abbildung A.15.: Diigo Toolbar (Quelle: Eigene Darstellung)

XXXIX Abbildung A.16.: Jenkins Weboberche (Quelle: Eigene Darstellung) Quellenverzeichnis

XL Quellenverzeichnis Abbildung A.17.: Wiki Weboberche (Quelle: Eigene Darstellung)

Quellenverzeichnis

B. Anhang Quellcode
Listing B.1: pom.xml des Projektes instantscrum-web (komplett) <project> <artifactId>instantscrum-web</artifactId> <packaging>war</packaging> <name>instantscrum-web</name> <build> <resources> <resource> <directory>src/main/java/META-INF</directory> <includes> <include>*.xml</include> <include>**.xml</include> </includes> <filtering>true</filtering> </resource> <resource> <directory>src/main/resources/</directory> <filtering>true</filtering> </resource> </resources> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <skipTests>true</skipTests> <excludes> <exclude>**/*ITSuite.java</exclude> </excludes> </configuration> </plugin> <plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <configuration> <deployer> <deployables> <deployable> <groupId>de.crossbeanmedia.instantscrum</ groupId> <artifactId>instantscrum-web</artifactId> <type>war</type> </deployable> </deployables> </deployer> </configuration>

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

39 40 41 42 43 44

XLI

Quellenverzeichnis <executions> <execution> <id>start-container</id> <phase>pre-integration-test</phase> <goals> <goal>start</goal> <goal>deploy</goal> </goals> </execution> <execution> <id>stop-container</id> <phase>post-integration-test</phase> <goals> <goal>stop</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <configuration> <includes> <include>**/*ITSuite.java</include> </includes> </configuration> <executions> <execution> <id>integration-test</id> <phase>integration-test</phase> <goals> <goal>integration-test</goal> </goals> </execution> <execution> <id>verify</id> <goals> <goal>verify</goal> </goals> </execution> </executions> </plugin> </plugins> <finalName>instantscrum-web</finalName> </build> </project>

45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90

XLII

Eidesstattliche Erklrung
Ich versichere an Eides Statt durch meine eigenhndige Unterschrift, dass ich die vorliegende Arbeit selbststndig und ohne fremde Hilfe angefertigt habe. Alle Stellen, die wrtlich oder dem Sinn nach auf Publikationen oder Vortrgen anderer Autoren beruhen, sind als solche kenntlich gemacht. Ich versichere auerdem, dass ich keine andere als die angegebene Literatur 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 Prfungsbehrde vorgelegt und auch noch nicht verffentlicht.

Schwallungen, den 13. Oktober 2012

Ort, Datum Christopher Ezell

Fambach, den 13. Oktober 2012

Ort, Datum Rene Kassel

XLIII