Erweiterung einer bestehenden Webanwendung um einen Android-Client am Beispiel von verteilten Retrospektiven

Transkript

1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Erweiterung einer bestehenden Webanwendung um einen Android-Client am Beispiel von verteilten Retrospektiven Bachelorarbeit im Studiengang Informatik von Wadim Ortlieb Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Joel Greenyer Betreuerin: Dipl.-Math. Olga Liskin Hannover,

2 Zusammenfassung Bestehende Webanwendungen bieten immer häufiger eine an das System angebundene App-Version an. Diese ermöglichen, neben dem ortsunabhängigen Abrufen von Informationen des Systems, eine auf die mobilen Geräte abgestimmte Benutzerinteraktion. Nutzer der App können so zudem schneller an gewünschte Informationen des Systems kommen. Dabei bieten vor allem native Umsetzungen, wie z.b. Android-Apps im Vergleich zu mobilen Web-Apps zusätzliche Vorteile, da die Möglichkeiten der jeweiligen Mobil-Plattform voll ausgereizt werden können. Im Rahmen dieser Arbeit wurde eine solche bestehende Webanwendung um eine Android-App erweitert. Bei der Webanwendung handelt es sich dabei um eine Anwendung zum Abhandeln von aus der agilen Softwareentwicklung stammenden verteilten Retrospektiven. Aus der beispielhaften Erweiterung der Distance Retros Webanwendung wurde zudem ein allgemeines Vorgehen, in Form eines Software-Prozesses abgeleitet, das eine Erweiterung anderer Webanwendungen um einen Android-Client ermoeglichen soll. Innerhalb des Prozesses wurde dabei wurde vor allem auf Strukturen der bestehenden Webanwendung zurückgegriffen, um ein aufwandsreduziertes Erweitern zu ermöglichen. Der entwickelte Prozess wird innerhalb der Arbeit unter beispielhafter Anwendung auf die Distance Retros Webanwendung vorgestellt. Abstract Existing web applications more and more often offer an app version, which is connected and integrated into its system. This allows not only for a location-independent retrieval of system information, but also makes it possible to provide a user interaction that is fine-tuned for mobile devices and contexts. This enables the app user to reach the required information easier and faster. Especially native implementations like androidapps provide additional advantages when compared with common mobile web-apps, because they are able to use all the features provided by the specific mobile operating system, drastically improving the user experience. This thesis deals with such an existing web application that has been extended by an android app. The given web application Distance Retros which has been extended is used for conducting distributed retrospectives that are used in the context of agile software development. The extension of the Distance Retros web application by an android app was also used to derive a software development process in order to provide guidance for extending other web applications. In order to reduce the effort required for extending, structures of the existing web application have been used inside the process. The developed process is presented using the example of extending the distance retros web application. ii

3 Inhaltsverzeichnis 1. Einleitung Motivation Ziel der Arbeit Grundlagen Agile Softwareentwicklung Agile Retrospektiven Webanwendungen und Web-Technologien Typen von Webanwendungen API JSON Webservice REST Styleguides Android Design Styleguide Distance Retros Webanwendung Funktionen Retrospektiven Benutzerrollen Whiteboard Retrospektiven Moderation Umsetzung der Webanwendung Prozess Zur Entstehung des Prozesses Voraussetzungen der Prozessanwendung Prozessübersicht Schritt 1: Analyse der Webanwendung Analyse der Benutzeroberflächenstruktur Analyse und Dokumentation der vorliegenden API Eignung der vorliegenden API untersuchen Schritt 2: Entwicklung eines ressourcenorientierten Webservices Anlehnung an den REST-Architekturstil Webservice-Design Webservice-Implementierung Schritt 3: Anforderungsanalyse Bestimmung der Grundanforderungen Ableitung funktionaler Anforderungen aus dem Webservice iii

4 Inhaltsverzeichnis Aufdecken von Zusatzanforderungen Schritt 4: Benutzeroberflächen- und Interaktionsdesign View-Container zur Herleitung der Activity-Oberflächen-Struktur Activity-Design Schritt 5: Entwurf und Implementierung Entwurf des Android-Clients Aufstellen Code-Grundgerüsts Vollständige Implementierung der App Distance Retros App Entwicklung der App Herausforderungen und Designentscheidungen Fazit und Ausblick Fazit Ausblick A. Benutzeroberflächenstruktur der Distance Retros Webanwendung 56 B. Dokumentation: Distance Retros Webanwendung API 58 C. Dokumentation: Ressourcenorientierter Webservice 62 D. Funktionale Anforderungen 66 E. Screenshots: Distance Retros Prototyp 67 iv

5 1. Einleitung Dieses Kapitel erläutert die Motivation sowie die Zielsetzung der vorliegenden Arbeit Motivation Mobile Apps werden immer beliebter und sind längst nicht mehr auf kleine, der Unterhaltung dienenden Spielereien beschränkt. So werden die Geräte leistungsfähiger und ermöglichen immer mehr Möglichkeiten auch von unterwegs produktiven Tätigkeiten nachzugehen, die sonst auf den Einsatz eines vollwertigen Computers beschränkt sind. In Verbindung mit einer mobilen Internetverbindung ist mithilfe einer App der Zugriff auf relevante und vor allem aktuelle Informatioenn von überall aus möglich. Auf diese Informationen kann zudem aufgrund einer entsprechend zugeschnittenen Benutzerinteraktion schnell zugegriffen werden. Dies gilt vor allem für native Umsetzungen, wie z.b. Android-Apps. Diese bieten dem Nutzer im Vergleich zu mobilen Web-Apps ein besseres Benutzererlebnis, da die Möglichkeiten der jeweiligen Mobil- Plattform voll ausgereizt werden können. Viele Unternehmen haben diese Beliebtheit sowie die potenziellen Möglichkeiten der mobilen Apps erkannt und wollen mit auf den App-Zug aufspringen, indem sie für ihr vorhandenes System eine entsprechende App-Version anbieten. Dabei handelt es sich oft um bestehende Webanwendungen, die um eine App erweitert werden sollen. Die Apps sollen an das vorhandene System angebunden werden und einen Teil der Funktionen auf die mobilen Geräte abgestimmt bereitstellen. In dieser Situation befindet sich auch die in einem Softwareprojekt entstandene Anwendung Distance Retros. Für diese soll eine Android-App entwickelt werden, über die die Anwendung ebenfalls bedient werden kann. Bei der Anwendung Distance Retros handelt es sich um eine Webanwendung, die das Abhandeln von Retrospektiven zwischen verteilten Teams ermöglicht. Retrospektiven sind ein Bestandteil agiler Softwareprojekte und dienen der Verbesserung der internen Prozessabläufe. Dabei wird vor allem Feedback zu vergangenen Phasen eines Softwareprojekts gesammelt und gemeinsam diskutiert. Dieses Sammeln findet üblicherweise über das Anbringen von Karten oder Post-its an einer gemeinsamen Wand statt. Die Webanwendung Distance Retros ermöglicht diesen Vorgang auch verteilten Teams, indem sie den Anwendern ein virtuelles, ortsungebundenes Whiteboard bereitstellt. 1

6 1. Einleitung 1.2. Ziel der Arbeit Im Rahmen dieser Arbeit soll die bestehende Webanwendung Distance Retros um eine Android-App erweitert werden. Zuvor soll dazu die vorliegende Webanwendung untersucht und entsprechend erweitert werden, sodass eine Anbindung mobiler Clients an das bestehende System ermöglicht wird. Aus der beispielhaften Erweiterung der Distance Retros Anwendung soll des Weiteren ein allgemeines Vorgehen zur Erweiterung von bestehenden Webanwendungen um Android-Apps abgeleitet werden. Hierbei wurde zusätzlich das Ziel gesetzt dieses Vorgehen so zu gestalten, dass dabei der Aufwand einer Erweiterung möglichst gering gehalten wird, ohne dabei größere Kompromisse einzugehen. Diese Arbeit richtet sich somit vor allem an Projektmanager, die einen Überblick darüber bekommen wollen, was für eine solche Erweiterung vorgenommen werden muss und worauf zu achten ist, sodass eine Aufwandsabschätzung über eine eigene Erweiterung im Voraus vorgenommen werden kann. Des Weiteren sollen die Inhalte dieser Arbeit den Entwicklern einer solchen erweiterten Android-App konkrete Wege zur Umsetzung geben. 2

7 2. Grundlagen In diesem Kapitel sollen Grundlagen und Begriffe erläutert werden, die für den weiteren Verlauf der Arbeit vorausgesetzt werden Agile Softwareentwicklung Der Begriff agile Softwareentwicklung fasst eine Gruppe von Ansätzen im Softwareentwicklungsprozess zusammen, die sich im Gegensatz zu klassischen Vorgehensmodellen auf ein iteratives Vorgehen stützen. Projekte werden nicht im Voraus komplett durchgeplant und anschließend in einem Durchlauf ausgeführt, sondern Schritt für Schritt, mit inkrementellen Vorversionen des endgültigen Systems, umgesetzt. Dies soll zu einer erhöhten Transparenz und Flexibilität führen, um vor allem Risiken im Entwicklungsprozess zu minimieren. Definition angelehnt an [GabLex] Agile Retrospektiven Retrospektiven sind Treffen aller Beteiligten eines Softwareprojekts zum Zweck des Lernens. Dabei wird auf einen vergangenen Zeitabschnitt des Projektes zurückgeschaut, um gesammelte Erfahrungen und Eindrücke zu diskutieren. Es wird besprochen, was gut funktioniert hat und wo es im Prozess noch Verbesserungspotenzial gibt. Gemeinsam werden dann Ideen und konkrete Verbesserungsmaßnahmen erarbeitet. Retrospektiven finden vor allem in der agilen Softwareentwicklung statt und werden deshalb auch als agile Retrospektiven bezeichnet. [Wol11] Häufigkeit und Ablauf In der agilen Softwareentwicklung werden Retrospektiven üblicherweise zwischen den einzelnen Iterationen eines Softwareprojekts durchgeführt. Nach [Dav09] bilden die Retrospektiven eine Brücke zwischen den Iterationen. Inhaltlich besteht eine typische Retrospektive dabei aus zwei etwa gleich langen Abschnitten, dem Rückblick und dem Blick nach vorn. Begonnen wird stets mit dem Rückblick. Hier soll sich die Gruppe gemeinsam an Ereignisse und deren Ursachen erinnern. Dies geschieht üblicherweise über das Anbringen von Karten oder Post-its an einer gemeinsamen Wand. In der zweiten Hälfte wird dann ein Aktionsplan erstellt. 3

8 2. Grundlagen Dazu wird festgelegt, welche Probleme zuerst behoben werden sollen. Dies kann beispielsweise über eine Punktabstimmung geschehen. Bevor die festgelegten Aktionen zum Schluss der Retrospektive bestimmten Gruppenmitgliedern zugewiesen werden, wird ermittelt, warum alte Aktionen möglicherweise nicht abgeschlossen wurden (nach [Dav09]). Moderation und Aktivitäten Die Moderation stellt einen wichtigen Aspekt von Retrospektiven dar. Sie ist nach [Wol11] besonders wichtig, weil vor allem Entwickler während einer Gruppendiskussion gerne vom Thema der allgemeinen Prozessverbesserung abweichen und lieber über Technik, Design und Architektur diskutieren. Der Moderator muss die Gruppe in solchen Fällen darauf aufmerksam machen und die Diskussion zum eigentlichen Thema zurückführen. Der Moderator muss zudem dafür sorgen, dass die Retrospektive erfolgreich abgeschlossen wird. Dazu gehört das Ermitteln von Aktivitäten bzw. den sogenannten Action Items. Diese stellen die Ergebnisse einer Retrospektive dar. Ein Action Item beschreibt jeweils eine konkrete Maßnahme, die innerhalb der nächsten Iteration durchgeführt werden soll. Die Maßnahme wird dabei einem Teilnehmer zugewiesen. Verteilte Retrospektiven Bei der Durchführung von Retrospektiven müssen sich nicht zwangsläufig alle Teilnehmer vor Ort befinden. So werden nach [Eck10] vor allem Videokonferenzen und Telefonkonferenzen zur Durchführung von Retrospektiven in verteilten Teams durchgeführt. Da die vor allem die Kommunikation bei solchen Retrospektiven insgesamt schwieriger ist, wird beispielsweise vorgeschlagen, zum erleichterten Durchführen im Voraus eine Sprech-Reihenfolge der Teilnehmer festzulegen Webanwendungen und Web-Technologien Unter Webanwendungen versteht man eine Art von Anwendungsprogrammen, die einen Browser als Client verwenden und darüber mit einem Server kommunizieren. Dabei werden HTTP-Anfragen des Clients über das Internet oder ein Intranet an einen Webserver geschickt. Dieser leitet die Anfrage an ein auf dem Server liegendes Programm weiter, welches zudem Zugriff auf persistente Daten des Servers hat. Wurde die Anfrage vom Programm verarbeitet, wird eine Antwort über den Webserver zurück an den Browser geschickt

9 2. Grundlagen Typen von Webanwendungen Bei Webanwendungen ist zwischen zwei allgemeinen Typen zu unterscheiden. Die ersten, auch klassisch genannten Webanwendungen generieren mit jeder Anfrage des Clients dynamische eine Seite und schicken diese zurück an den Client. Man spricht dabei auch von synchronen Anfragen. Bei dem zweiten Typ handelt es sich um dynamische Webanwendungen. Diese sind nicht auf die Rückgabe von vollständig generierten Seiten des Servers beschränkt. Mithilfe von Client-seitiger Technologie ermöglichen diese ein dynamisches, asynchrones Nachladen von Serverdaten um somit Teilinhalte der Webanwendung zu aktualisieren, ohne auf eine komplette Neu-Generierung der dargestellten Seite zurückgreifen zu müssen. Dieses asynchrone Senden und Empfangen von Daten ermöglicht eine weniger starre Benutzerinteraktion, die normalen Desktopanwendungen ähnelt. Umgesetzt wird diese asynchrone Datenübertragung typischerweise mithilfe des Ajax (Asynchronous JavaScript and XML) Konzeptes, das bei der Durchführung der Anfragen auf JavaScript zurückgreift API Unter der Abkürzung API (application programming interface) versteht man allgemein eine von einem System bereitgestellte Programmierschnittstelle. Innerhalb dieser Arbeit wird die Bedeutung des Begriffs API allerdings auf eine über das HTTP-Protokoll laufende API beschränkt. Wir sprechen also bei von einer Webanwendung bereitgestellten API von einer Schnittstelle, die für die Datenübermittlung zwischen Client und Webserver bereitgestellt wird JSON JSON (JavaScript Object Notation) beschreibt ein spezielles, vor allem im Kontext des Webs verwendetes Datenformat. Es handelt sich dabei um ein Textformat, das auf zwei Strukturen aufbaut, nämlich Name-Wert Paare und geordnete Listen von Werten. Dieses Format ist einfach für Menschen zu lesen, aber auch effizient von Maschinen zu parsen und zu generieren. Aufgrund dieser Eigenschaften ist es vor allem bei Entwicklern im Web beliebt, da es aufgrund seiner kompakten Form eine angenehmere Arbeit ermöglicht, als es beispielsweise bei dem Datenformat XML der Fall ist Webservice Unter einem Webservice 3 versteht man eine Methode zur Maschine-zu-Maschine- Kommunkation, welche über das World Wide Web stattfindet. Webservices sollen da- 2 vgl. 3 Definition angelehnt an 5

10 2. Grundlagen bei vor allem als Abstraktionsschicht fungieren. Daten werden über einen Webservice in maschinenlesbaren Formaten wie JSON oder XML übertragen. Meinst findet die Kommunikation über das HTTP-Protokoll statt. Ein Webservice ist zudem über eine sogenannte URI (Uniform Resource Identifier) eindeutig identifizierbar bzw. adressierbar REST Bei dem Begriff REST (Representational State Transfer) handelt es sich um einen Architekturstil für netzwerkbasierte Anwendungen, der von Roy Fieldings in seiner Dissertation (2000) vorgestellt wurde. Die Kerneigenschaft des Architekturstils ist dabei das Bereitstellen von Daten in Form von Ressourcen bzw. deren Repräsentationen. Konkret beschreibt REST fünf grundlegende Prinzipien die ein REST-konformer Dienst besitzen muss. 4 Adressierbarkeit Eindeutiger Zugriff auf den REST-Dienst (über eine URL) sowie auf dessen Ressourcen (über URIs). Unterschiedliche Repräsentationen Bereitstellung unterschiedlicher Darstellungsformen der selben Ressource (beispielsweise in Form von HTML- oder JSON-Daten). Zustandslosigkeit Eine Zustandslose Kommunikation zwischen Server und Client, bei der sämtliche Nachrichten alle für den Server zur Verarbeitung nötigen Informationen enthalten. Operationen Bereitstellung vorgegebener, auf Ressourcen anwendbare Operationen. Im Falle von HTTP gehören dazu unter anderem GET, POST, PUT und DELETE. Verwendung von Hypermedia Repräsentationen von Ressourcen enthalten Links zu anderen Ressourcen, um eine Navigation zwischen vorhandenen Ressourcen zu ermöglichen Styleguides Bei einem Styleguide handelt es sich um ein Dokument, dass die Ergebnisse der Analyse-, Design- und Entwicklungsphase eines Softwareprojekts vereint. Das Dokument beinhaltet konkrete Vorgaben für das Layout und die visuelle Gestaltung von Benutzeroberflächen. Die Vorgaben beziehen sich dabei immer auf ein bestimtes Produkt oder eine Gruppierung von Produkten 5. Es hanedelt sich also nicht um allge- 4 Definition angelehnt an 5 Beispielsweise eine bestimmte Plattform, oder eine Produktgruppe eines bestimmten Unternehmens 6

11 2. Grundlagen meingültigen Regeln, die überall anwendbar sind. Bei der Entwicklung eines neuen Softwarerodukts können Designer die im Styleguide enthaltenen Vorgaben als Nachschlagwerk verwenden oder diese checklistenartig abarbeiten. Insgesamt soll dies zu einer erhöhten Konsistenz und Qualität während des Designprozesses führen (nach [May99]) Android Design Styleguide Android Design 6 ist ein von Google bereitgestellter Styleguide für das Android Betriebssystem. Der Styleguide wurde im Januar 2012, kurz nach dem Erscheinen der Android-Version 4.0 veröffentlicht 7. Er richtet sich an Designer und Entwickler von Android-Apps und soll dabei helfen im Grunddesign konsistente und benutzerfreundliche Android Apps zu entwickeln. Inhaltlich besteht der Android Design Styleguide aus 3 Hauptteilen: Style: Hier werden allgemeine Prinzipien und Guidelines vorgestellt. Dabei handelt es sich um allgemeine Faustregeln der visuellen Gestaltung. Es werden beispielsweise Metriken zum Einsatz von Schriftarten, Farben und Icons genannt. Patterns: Hier werden Pattern vorgestellt, die beispielsweise die Umsetzung einer effizienten Navigation und Benutzerinteraktion mit der App ermöglichen sollen. So werden beispielsweise für bestimmte Anwendungszwecke als sinnvoll befundene Gesten vorgestellt sowie bewährte Muster zur Darstellung und Bearbeitung von Daten. Building Blocks: Hier werden konkrete Blöcke bzw. Elemente der Android-GUI 8 vorgestellt. Es wird erläutert, wie diese korrekt zu verwenden sind, sodass ein möglichst gutes Benutzererlebnis erzielt werden kann. Dazu gehören konkrete Angaben zur Verwendung von Tabs (Reitern), Listen, scrollbaren Inhalten und weitere Elemente Graphical User Interface bzw. Benutzeroberfläche 7

12 3. Distance Retros Webanwendung In diesem Kapitel wird die bestehende Webanwendung, welche im Rahmen dieser Arbeit um einen Android-Client erweitert werden soll, vorgestellt. Dazu werden die Funktionen, sowie die technische Umsetzung der Anwendung kurz erläutert. Entstanden ist die Anwendung im Wintersemester 2012, innerhalb der Lehrveranstaltung Softwareprojekt (SWP) Funktionen Bei der Webanwendung Distance Retros handelt es sich um ein Werkzeug zum Abhandeln von verteilten Retrospektiven. Die Anwendung bietet verteilten Entwickler- Teams die Möglichkeit, trotz großer räumlicher Distanz auf eine gemeinsame Arbeitsfläche zuzugreifen. Diese Arbeitsfläche soll den von normalen Retrospektiven gewohnten Einsatz eines Whiteboards bzw. einer Wand, an der Karten angebracht werden können, simulieren. Zusätzlich ermöglicht die Webanwendung Funktionen wie beispielsweise das Erstellen und Auswerten von Umfragen Retrospektiven Benutzer können sich mit ihrem zuvor zugeteilten Benutzeraccount bei der Webanwendung einloggen. Dadurch bekommen sie Zugriff auf eine Übersicht der aktuell vorhandenen Retrospektiven. Von hier aus können neue Retrospektiven erstellt werden, oder bereits vorhandene betreten werden Benutzerrollen Innerhalb einer Retrospektive gibt es zwei Typen von Benutzern, den Teilnehmer und den Moderator. Erstellt ein Benutzer eine Retrospektive, so ist er automatisch der (einzige) Moderator dieser Retrospektive. Alle folgenden Benutzer, die dieser Retrospektive beitreten, sind automatisch normale Teilnehmer. Neben dem gesamten Funktionsumfang des Teilnehmers werden dem Moderator zusätzliche Funktionen zum Leiten der Retrospektive geboten. 1 Fachgebiet Software Engineering, Leibniz Universität Hannover 8

13 3. Distance Retros Webanwendung Whiteboard Jede Retrospektive besitzt ein Whiteboard, auf dem sogenannte Widgets erstellt, verschoben und bearbeitet werden können. Die Ansicht des Whiteboards aktualisiert sich dabei selbstständig bei jedem teilnehmenden Benutzer. Folgende Widget-Typen können auf dem Whiteboard platziert werden. Karte Besitzt einen Text und eine Hintergrundfarbe, die über die Auswahl eines Templates 2 ausgewählt werden kann. Eine Karte kann von Nutzern positiv bewertet und vom Moderator hervorgehoben werden. Karten können von Teilnehmern und vom Moderator erstellt werden. Label Besitzt eine markante Überschrift und dient zur Strukturierung des Whiteboards. Labels können nur vom Moderator erstellt werden. Umfrage Bietet anonyme Abstimmmöglichkeiten sowie eine Auswertung der Ergebnisse. Umfragen können nur vom Moderator erstellt werden. Action Item Besitzt einen Aufgabentext und kann vom Moderator einem bestimmten Teilnehmer zugewiesen werden. Zudem besitzen Action Items einen Status, der angibt, ob die jeweilige Aktivität bereits erledigt wurden. Action Items können nur vom Moderator erstellt werden. Jeder Nutzer besitzt zudem einen persönlichen Arbeitsbereich. Dort können eigene Widgets vorbereitet werden, bevor sie auf dem Whiteboard veröffentlich werden. Dargestellt wird der persönliche Arbeitsbereich über eine halbtransparente Ebene über dem Whiteboard. Beim Veröffentlichen der vorbereiteten Widgets übernehmen diese die Position, die sie auf dem persönlichen Arbeitsbereich hatten, sodass dem Benutzer klar ist, wo die Widgets auf dem globalen Whiteboard erscheinen werden. Das Whiteboard der Distance Retros Anwendung ist auf Abbildung 3.1 zu sehen Retrospektiven Moderation Neben dem Erstellen der genannten Widgets, hat der Moderator zudem weitere Möglichkeiten zur Moderation der Retrospektive. So kann er Action Items aus anderen, zuvor getätigten Retrospektiven importieren. Die dazu vorgesehene Funktion importiert dabei eine Auswahl offener, also nicht erledigter Action Items in die aktuelle Retrospektive. 2 Vom System bzw. Administrator festgelegte Farben 9

14 3. Distance Retros Webanwendung Abbildung 3.1.: Distance Retros Whiteboard-Ansicht Außerdem besteht die Möglichkeit, vorhandene Action Items einer Retrospektive zu exportieren. Dazu können Action Items inklusive Status und einem ggf. zugewiesenem Teilnehmer in einem PDF-Dokument aufgelistet werden Umsetzung der Webanwendung Entwickelt wurde die Webanwendung mithilfe des Play!-Frameworks 3 in der Version Das Framework basiert auf dem MVC 4 -Pattern und verwendet die Programmiersprachen Java und Scala. Für die Entwicklung der Distance Retros Webanwendung wurde auf Serverseite primär Java verwendet. Für die Umsetzung des Whiteboards und der sich selbst aktualisierenden Widgets wurde auf Ajax zurückgegriffen. Der Client holt sich dabei alle paar Sekunden die aktuellsten Daten vom Server und aktualisiert anschließend die Sicht, ohne ein Neuladen der kompletten Seite zu erzwingen. Die restlichen Unterseiten der Webanwendung, dazu gehören Verwaltungs- und Übersichtsseiten wurden im klassischen, synchronen Anfrage-Stil umgesetzt Model-View-Controller 10

15 In diesem Kapitel wird der zur Erweiterung von Webanwendungen um einen Android- Client 1 entwickelte Prozess vorgestellt. Bei der Vorstellung des Prozesses wird innerhalb jedes Schrittes eine beispielhafte Anwendung in Bezug auf die Distance Retros Webanwendung durchgeführt. Bevor die einzelnen Schritte des Prozesses erläutert werden, soll zuvor jedoch ein Blick auf die Entstehung des Prozesses sowie die Voraussetzungen der Prozessanwendung geworfen werden Zur Entstehung des Prozesses Ein großer Aufgabenteil dieser Arbeit bestand darin, ein allgemeines Vorgehen für die Erweiterung von Webanwendungen um Android-Apps abzuleiten. Im Sinne des Software Engineerings erscheint es dabei als sinnvoll, dieses Vorgehen in einem Software- Entwicklungsprozess festzuhalten. Doch stellt man sich womöglich die Frage, warum man für diese Erweiterung nicht einfach auf einen vorhandenen Prozess zurückgreift. Ein Ansatz hierfür wäre beispielsweise das Verwenden des klassischen Wasserfallmodells 2. Bei der Untersuchung der möglichen Motivationen und Hintergründe einer solchen Erweiterung stellte sich allerdings heraus, dass diese vor allem für Unternehmen interessant sein könnte, die ihren Kunden zwar gerne eine zusätzliche App zu ihrem bestehenden System anbieten würden, dafür allerdings nicht die Kosten eines vollwertigen Softwareprojekts bereit sind zu zahlen. Bei der Anwendung eines klassischen Vorgehensmodells würde vermutlich aber genau dieser, mit hohem Aufwand und damit Kosten verbundene, nicht wünschenswerte Fall eintreten, da sich die Entwicklung der App als komplett neues, bei Punkt Null startendes Softwareprojekt herausstellen würde. Aus diesem Grund wurde das konkretere Ziel der Prozessentwicklung herausgearbeitet, ein Erweiterungsvorgehen zu beschreiben, dass versucht die Kosten der Entwicklung gering zu halten. Es stellte sich heraus, dass dieses Vorgehen durch das Verwenden von vorhandenen Strukturen der bestehenden Webanwendung unterstützt werden kann. Dabei soll allerdings nicht auf eine einfache Konvertierung der Webanwendung zurückgegriffen werden. Diese kommt deshalb nicht infrage, da eine App andere Anforderungen und Randbedingungen als das bestehende System hat. 1 Im weiteren Verlauf der Arbeit werden die Begriffe Android-Client, Android-App und App synoynm verwendet. 2 /Vorgehensmodell/Wasserfallmodell 11

16 Auch das Zurückgreifen auf vorhanden Software-Migrationsprozesse, wie vielleicht zunächst vermutet, ist für diesen Anwendungszweck nicht geeignet. Nach [Sne10] zielen Migrationsmaßnahmen nämlich auf die Erhaltung eines Softwaresystems in einer neuen Umgebung ab. Es geht dabei um das vollständige Ersetzen eines vorhandenen Systems (sogenannte Legacy-Systeme) mit dem Zweck das Leben des migrierten Systems zu verlängern. Für die Erweiterung und Anpassung der Funktionalität des Zielsystems, aufgrund von geänderten Anforderungen sind deshalb andere, nicht in der Software-Migration enthaltene Prozessmodelle anzuwenden (nach [Sne10]). Konkret hat die Prozessentwicklung mithilfe einer exemplarischen Erweiterung der zuvor vorgestellten Distance Retros Webanwendung stattgefunden. Die im Prozess beschriebenen Schritte der Erweiterung sind dabei die erlangten Erkenntnisse und als sinnvoll befundenen Vorgehenspraktiken zur strukturierten und aufwandsreduzierten Erweiterung Voraussetzungen der Prozessanwendung Hier soll beschrieben werden wie die Voraussetzungen für eine Anwendung des Prozesses aussehen. Dazu gehören vor allem die technischen Voraussetzungen an die Webanwendung. Für die Anwendung des Prozesses wird zunächst davon ausgegangen, dass es vom Kunden eine einzige, initiale Anforderung gibt: Die bestehende Webanwendung soll um eine Android-App erweitert werden. Diese stößt den Erweiterungsprozess an. Eine konkrete Anforderungsanalyse findet zu Beginn des Prozesses nicht statt, diese wird im späteren Verlauf des Prozesses vorgenommen, nachdem einige Grundlagen geschafft wurden. Es wird des weiteren keine Spezifikation vorausgesetzt, sondern nur das Vorhandensein der Webanwendung selbst, inklusive dem vollständigen Code. Dies ermöglicht uns auch Webanwendungen erweitern zu können, die zum Einen gar keine Spezifikation besitzen (z.b. bei iterativ entwickelten und angepassten Projekten) oder nur eine veraltete ursprüngliche Version dieser, die nicht den aktuellen Zustand der Systemfunktionalität beschreibt. 3 Technisch setzen wir an die Webanwendung folgende Voraussetzungen: Der gesamte Code der Webanwendung liegt vor Die Webanwendung kann live ausgeführt werden Die Webanwendung basiert auf dem MVC-Pattern 4 3 In der späteren Anforderungsanalyse werden Hinweise gegeben, wie man eine ggf. vorhandene Spezifikation dennoch zur Aufwandsreduzierung integrieren kann. Der Prozess selbst geht grundsätzlich aber davon aus, dass keine Spezifikation vorliegt. 4 Bei der Prozessanwendung wird in diesem Fall konkret das Play!-Framework verwendet. 12

17 Sämtliche auf Clientseite darzustellende Daten befinden sich auf der Serverseite und werden über die API übermittelt (über die Rückgabe generierter HTML- Seiten oder maschinell lesbare Datenformate eines Webservices) Ein Positivbeispiel für eine mögliche Anwendung wäre somit ein CMS (Content- Management-System), ein Wiki-System oder ein Webbasiertes soziales Netzwerk. Ein Negativbeispiel wäre eine Client-seitige Simulationsumgebung, die lediglich Konfigurationsdaten bzw. Zustandsdaten vom Server lädt, um anschließend daraus darzustellende Daten zu berechnen Prozessübersicht Dieser Abschnitt soll einen Gesamtüberblick über den entwickelten Erweiterungsprozess vermitteln. Es wird erläutert wie die Schritte miteinander zusammenhängen und welche Produkte bzw. Dokumente während der einzelnen Aktivitäten entstehen. Abbildung 4.1 bietet dazu zudem eine Übersicht in der SPEM-Notation. Im anschließenden Abschnitt folgt eine genaue Erläuterung der Prozesschritte. Hier noch eine Anmerkung zur verwendeten Begrifflichkeit: Der Begriff API beschränkt sich in dieser Arbeit wie in den Grundlagen beschrieben auf HTTP-Schnittstellen. Zur Vereinfachung definieren wir des Weiteren den Begriff Webservice als Teilmenge einer solchen API. Diese Webservices beschränken sich dabei auf Maschine-zu- Maschine Kommunikation unter der Verwendung von entsprechenden Datenformaten (JSON, XML). Dies soll uns dabei helfen den HTML-Daten-Teil der API und den Nicht- HTML-Teil der API besser unterscheiden zu können. Schritt 1: Analyse der Webanwendung Im ersten Schritt des Prozesses wird die bestehende Webanwendung, welche die Grundlage unserer Erweiterung darstellt, analysiert. Hier werden erste Produkte des Prozesses erstellt, die aus der Webanwendung extrahiert werden und im weiteren Verlauf des Prozesses als Hilfsmittel dienen sollen. Dazu gehört die Dokumentation der Benutzeroberflächenstruktur sowie die Dokumentation der von der Webanwendung verwendeten API. Anhand der API-Dokumentation wird die API dann auf eine Eignung für unseren Erweiterungsprozess hin untersucht. Wird die API als ungeeignet eingestuft, so muss mithilfe des nächsten Schrittes eine geeignete API entwickelt werden, da diese eine technische Voraussetzung unserer App-Entwicklung darstellt. Wird sie hingegen als geeignet eingestuft, so kann direkt zu Schritt 3 (Anforderungsanalyse) des Prozesses gesprungen werden. Produkte dieses Schrittes: Dokumentation der Benutzeroberflächenstruktur der bestehenden Webanwen- 13

18 Abbildung 4.1.: Prozess in SPEM-Notation dung Dokumentation der vorliegenden API Schritt 2: Entwicklung eines ressourcenorientierten Webservices Im zweiten Schritt wird ein für unsere Erweiterung geeigneter, ressourcenorientierter Webservice entwickelt, der sich an den REST-Architekturstil anlehnt. Dieser Webservice wird für die Kommunikation zwischen Android-Client und Server zuständig sein. Dabei wird die zuvor in Schritt 1 erstellte Dokumentation der vorliegenden API als Grundlage genommen, um daraus werden nötige Informationen über von der Webanwendung verwendete Daten bzw. Ressourcen zu extrahieren, welche den Webservice- Design-Prozess unterstützen sollen. Produkte dieses Schrittes: Dokumentation des ressourcenorientierten Webservices 14

19 Code des ressourcenorientierten Webservices Schritt 3: Anforderungsanalyse Im dritten Schritt werden die für die zu entwickelnde App relevanten Anforderungen bestimmt. Dies geschieht in drei Teilen. Zunächst werden grundlegende Anforderungen an die App in einem Kundengespräch ermittelt. Anschließend werden erste funktionale Anforderungen aus dem geeigneten Webservice hergeleitet. Diese bilden die Grundfunktionalität der Webanwendung und werden damit auch einen Teil der Funktionalitäten unseres Android-Clients abdecken. Anschließend werden mithilfe von Personas und einem Anwendungsszenario weitere kontextspezifische 5 Anforderungen der App bestimmt. Die hier erstellten Personas werden zudem den folgenden Schritt (Benutzeroberflächen- und Interaktionsdesign) unterstützen, wenn es darum geht Designentscheidungen zu treffen. Produkte dieses Schrittes: Personas Anwendungsszenario Funktionale und nicht-funktionale Anforderungen Schritt 4: Benutzeroberflächen- und Interaktionsdesign Im vierten Schritt wird die Benutzeroberfläche und Benutzerinteraktion der App designt. Es wird zunächst eine Übersicht über nötige Views der App hergeleitet. Dafür wird die in Schritt 1 erstellte Dokumentation der Benutzeroberflächenstruktur zur Hilfe genommen. Diesen hergeleiteten Views werden dann aus Schritt 3 stammende Anforderungen zugewiesen. Es entsteht eine Übersicht über alle für die App zu erstellenden Views inklusive der jeweils darin umzusetzenden funktionalen Anforderungen. Mit dieser Übersicht werden dann die Oberflächen der einzelnen Android-Views bzw. Activities designt. Dafür werden GUI-Mockups sowie ein interaktiver Prototyp zum Testen der App-Interaktion erstellt. Unterstützt wird der gesamte Designprozess dabei durch den Android Design Guide, welcher Richtlinien sowie konkrete Vorgaben zur Erstellung der Views und Interaktion liefert. Produkte dieses Schrittes: Zuordnung von Anforderungen zu Views GUI-Mockups Interaktiver GUI-Prototyp Activity-Design 5 Primär nicht-funktionale Anforderungen, die sich auf den konkreten Anwendungseinsatz der App beziehen. 15

20 Schritt 5: Entwurf und Implementierung Im letzten Schritt wird ein Grobentwurf der zu implementierenden App erstellt. Anschließend werden die in Schritt 4 designten Activities in Code umgesetzt. Für die Kommunikation mit dem Server wird dabei der in Schritt 2 entwickelte oder sofern als geeignet eingestuft, der initial vorliegende Webservice verwendet. Um den Aufwand der App-Implementierung zusätzlich zu reduzieren, wird an bestimmten Stellen auf vorhandenen, teilweise anzupassenden Code der Webanwendung zurückgegriffen. Produkte dieses Schrittes: Grobentwurf Code der Android-App 16

21 4.4. Schritt 1: Analyse der Webanwendung Im ersten Schritt des Prozesses wollen wir die Grundlage unserer Erweiterung, nämlich die bestehende Webanwendung analysieren. Aus dieser werden wir Erste, für die Entwicklung unserer neuen App relevante Informationen extrahieren. Neben dem Erstellen konkreter Dokumentation, auf die wir im weiteren Verlauf des Prozesses als Hilfsmittel zurückgreifen werden, ermöglicht uns diese initiale Analyse der bestehenden Webanwendung zudem bereits Wissen über die Domäne des Kunden zu erlangen. Dies soll dabei helfen, das in Software-Projekten auftretende Unverständnis 6 zwischen Informatikern und Kunden zumindest auf Seite des Informatikers zu reduzieren um in Schritt 3 (Anforderungsanalyse) ggf. auftretende Kundenwünsche fachlich besser verstehen zu können. In Schritt 4 (Benutzeroberflächen- und Interaktionsdesign) des Prozesses werden wir die für unsere App nötige allgemeine View-Übersicht herleiten sowie die darin enthaltenen einzelnen App-Views designen. Damit wir eine Basis für diese App-View- Herleitung haben, untersuchen und dokumentieren wir in diesem Schritt die Benutzeroberflächenstruktur der Webanwendung. Danach wollen wir die vorliegende API untersuchen. Um eine saubere und einfache Entwicklung des Android-Clients gewährleisten zu können, sollte die zur App- Entwicklung vorliegende API einige Kriterien erfüllen und von uns als geeignet eingestuft werden. Wird die vorliegende API als nicht geeignet eingestuft, so müssen wir im nächsten Schritt eine neue, geeignete API entwickeln. Unabhängig von der Beschaffenheit der vorliegenden API wollen wir sie in diesem Prozessschritt vollständig dokumentieren, da wir in folgenden Prozessschritten auf diese Dokumentation zurückgreifen werden Analyse der Benutzeroberflächenstruktur Als Erstes erstellen wir eine Übersicht der Benutzeroberflächenstruktur der Webanwendung. Dabei machen wir uns bereits mit dem vorliegenden System und dessen Begrifflichkeiten vertraut. Wir starten die Webanwendung im Browser und untersuchen jede Seite bzw. View 7 der Anwendung einzeln. Um sicherzugehen, dass dabei auch alle Views entdeckt werden, können wir die sich im View-Paket der Webanwendung befindenden Views bzw. View- Templates checklistenartig abarbeiten. Bei der Untersuchung der Views müssen wir außerdem beachten, dass vor allem bei Webanwendungen die ihren Inhalt dynamisch laden und nicht nur aus statischen HTML-Seiten bestehen, auch dynamische Elemente oder so genannte Sub-Views innerhalb der View vorhanden sein können. Diese Sub-Views wollen wir ebenfalls in unsere Übersicht der Benutzeroberflächenstruktur aufnehmen. Dies ist wichtig, da der Inhalt dieser Sub-Views später ggf. in gesonderte 6 vgl. Symmetry of Ignorance [Sch11] 7 Die gerenderte Sicht. 17

22 App-Views dargestellt werden soll, um so eine Informations-Überladung der einzelnen Views zu vermeiden. Nachdem ein Grundverständnis der jeweiligen Views und dessen Funktion vorliegt, werden alle vorliegenden Views in die Dokumentation aufgenommen. Dazu wird zu jeder View der Name der View (Dateiname bzw. Templatename), der Typ (View oder Sub-View) sowie ein Titel, der die Hauptfunktion der View beschreibt notiert. Ebenfalls in die Dokumentation aufzunehmen ist die Navigationsstruktur der Webanwendung. Also welche Navigationsmöglichkeiten die einzelnen Views zu anderen Views bieten. Auf diese so erstellte Übersicht werden wir in Schritt 4 (Benutzeroberflächen- und Interaktionsdesign) zurückgreifen. Benutzeroberflächenstruktur der Distance Retros Webanwendung Abbildung 4.2 zeigt die ermittelte Benutzeroberflächenstruktur der Distance Retros Webanwendung. Das dynamische Dialogfenster Action Items importieren stellt dabei ein Beispiel für eine Sub-View dar. Dieses Fenster lässt sich in der Webanwendung öffnen, ohne die komplette Seite neu laden zu müssen. Da dieses Fenster aber auch eigene Funktionen besitzt, die wir später ggf. in unserer Android-App umsetzen wollen, übernehmen wir es in unsere Benutzeroberflächenstruktur Analyse und Dokumentation der vorliegenden API Damit unser zu entwickelnder Android-Client mit unserem Server kommunizieren kann, benötigen wir Zugriff auf eine entsprechende Schnittstelle bzw. API. Die Webanwendung besitzt bereits eine API, ob diese allerdings für unseren Android-Client geeignet ist, wissen wir noch nicht. Deshalb wollen wir als nächstes die vorliegende API der Webanwendung analysieren, um anhand der dabei erstellten Dokumentation anschließend eine Eignungsuntersuchung der API vorzunehmen. Um die Analyse strukturiert durchführen zu können, nehmen wir uns die Konfiguration des HTTP-Routers unserer Webanwendung zur Hilfe. Diese bietet eine Übersicht über sämtliche Anfragen der Webanwendung. Der HTTP-Router selbst ist für das Übersetzen der HTTP Anfragen eines Clients in Methodenaufrufe der Controller Klassen zuständig. Die jeweiligen Übersetzungseinträge stehen in der Konfiguration des HTTP- Routers. Ein Eintrag des HTTP-Routers innerhalb einer Play!-Anwendung hat dabei folgende Syntax 8 : [Request-Methode] [URI-Muster] [Controller-Methodenaufruf] Mithilfe der HTTP-Routing-Übersicht können wir nun die einzelnen Anfragen analysieren. Dazu wollen wir zum einen Eigenschaften der jeweiligen Anfragen direkt aus der Routing-Konfiguration ablesen und zum Anderen in den Code der jeweiligen Controller- Methoden schauen

23 Abbildung 4.2.: Benutzeroberflächenstruktur der Distance Retros App Insgesamt sollen dabei folgende Eigenschaften der Anfragen bestimmt und dokumentiert werden: Beschreibung Welche Funktion wird ausgeführt? Auf welche Daten oder Ressourcen wird zugegriffen? Hierzu schauen wir uns die Request-Methode und deren URI-Muster an, um eine erste Vermutung der Anfragenfunktion zu bekommen. Als Nächstes überprüfen wir diese Vermutung, in dem wir in den jeweiligen Controller-Methodenaufruf schauen und dessen Code untersuchen. Request-Methode Welche Request-Methode wird verwendet? 19

24 URI Ist direkt aus der Routing-Konfiguration zu übernehmen: GET, POST, PUT, oder DELETE. Wie lautet die vollständige URI der Anfrage, inklusive Parameter-Platzhalter? Ist direkt aus der Routing-Konfiguration zu übernehmen. Zusätzlich übermittelte Daten Welches Format (JSON, XML, URL, HTML-Formular) wird verwendet und wie sieht der Inhalt aus? Über die URL übermittelte Parameter werden innerhalb der Routing-Konfiguration an die Controller-Methode übergeben und können dort abgelesen werden. Handelt es sich um POST oder PUT Anfragen, so müssen wir zusätzlich in die Controller-Klasse schauen, um herauszufinden, ob weitere Daten übermittelt werden. Das übertragene Format wird über eine Java-Annotation direkt über der Methodendefinition angegeben und ist somit direkt abzulesen. Für den Inhalt wird in der Methode überprüft, welche Daten aus dem Body geparst werden. Rückgabeformat Wird eine HTML-Seite, ein XML-Dokument, ein JSON-Dokument oder ein anderes Format zurückgeliefert? Hierzu schauen wir uns den Rückgabewert der jeweiligen Controller-Methode an. Wird ein Template gerendert 9, so handelt es sich um eine HTML-Seite. Ansonsten notieren wir den Typ des zurückgelieferten Objektes. Inhalt der Rückgabe Welche Attribute liegen vor (sofern die Antwort im JSON- oder XML-Format vorliegt)? Hierzu schauen wir uns innerhalb der Controller-Methode die Attribute bzw. Variablen des zurückgelieferten Objekts an. HTTP-Statuscode Werden neben dem üblichen HTTP 200 (OK) andere HTTP-Statuscodes verwendet? Hierzu schauen wir uns innerhalb der Controller-Methode die jeweilgen Rückgabe- Anweisungen an. Authentifizierung Ist für die Ausführung der Anfrage eine Authentifizierung notwendig und ist die Anfrage auf bestimmte Benutzergruppen innerhalb des Systems beschränkt? Hierzu überprüfen wir, ob innerhalb der Controller-Methode eine Authentifizierungsüberprüfung stattfindet. Sofern vorhanden, befindet sich diese üblicherweise am Anfang der Methode. 9 über einen render() Aufruf 20

25 Zusätzlich notieren wir zu jeder Anfrage deren Aufruf-View, also wo im View-Code bzw. von welcher View der Webanwendung diese Anfrage aufgerufen bzw. ausgeführt wird. 10 Konkret tragen wir dazu den entsprechenden Namen der View (Dateiname bzw. Templatename) den wir auch bei der Erstellung der Benutzeroberflächenstruktur verwendet haben in unsere Dokumentation ein. Es bietet sich an, die Dokumentation der vorliegenden API in tabellarischer Form durchzuführen. Neben den eben aufgeführten Eigenschaften wird dabei jeder Anfrage zusätzlich eine eindeutige ID zugewiesen. Damit haben wir die Möglichkeit uns im weiteren Verlauf des Prozesses auf bestimmte Anfragen zu beziehen. Dokumentation der Distance Retros API Die Dokumentation der API der Distance Retros Webanwendung ist in Anhang B zu finden Eignung der vorliegenden API untersuchen Nachdem wir die vorliegende API dokumentiert haben, wollen wir nun bestimmen, ob diese für die Entwicklung des Android-Clients geeignet ist. Dabei geht es in erster Linie darum, ob die API überhaupt für uns nötige Webservice-Funktionalitäten bietet. Also ob neben der für Webanwendungen üblichen Rückgabe von HTML-Seiten auch ein Datenaustausch zwischen Server und Client mit anderen Formaten (in diesem Fall JSON) bietet. Basiert die API vollständig auf dem Einsatz von HTML-Seiten, und damit kein Webservice vorhanden ist, können wir sofort zum nächsten Schritt des Prozesses springen, um einen für die Erweiterung nötigen Webservice zu entwickeln. Ist ein Webservice hingegen vorhanden, so müssen wir sichergehen, dass dieser die gesamte Funktionalität der Webanwendung abdeckt. Es muss für jede dargestellte HTML-Seite und deren angebotenen Daten darstellenden und Daten verarbeitenden Funktionen eine entsprechende Webservice-Anfrage vorhanden sein. Erfüllt der Webservice auch diese Bedingung, so wollen wir nun die konkreten Anfragen des Webservices auf deren Eignung untersuchen. Für eine geeignete Erweiterung unseres Android-Clients sollten die vorhanden Anfragen einige Kriterien erfüllen. Für die Untersuchung der Eignung des vorliegenden Webservices, untersuchen wir sämtliche nicht HTML Anfragen auf folgende Eigenschaften: Sind Anfragen (Request-Methode und URI) möglichst selbstbeschreibend? 10 Diese spezielle Information werden wir in Schritt 4 (Benutzeroberflächen- und Interaktionsdesign) des Prozesses noch benötigen, um Funktionen bestimmten Views zuordnen zu können. Für unsere Eignungs-Untersuchung hat sie keine Relevanz. 21

26 Dies bewirkt, dass beim Entwickler weniger Bedarf besteht, in die Dokumentation der API zu blicken. Wird ein direktes Abrufen und Ändern bestimmter Datenobjekte über eindeutige URIs ermöglicht? Dadurch können wir die Zugriffserlaubnis auf bestimmte URIs und damit auch Objekte steuern. Des Weiteren führt das gezielte Abrufen bestimmter Daten zu einer geringeren Bandbreitennutzung und erspart ein ggf. erforderliches Filtern der Daten auf der Client-Seite. Werden passende Request-Methoden (GET, POST, PUT und DELETE), die die Art des Datenzugriffes beschreiben korrekt verwendet? Dies erleichtert aufgrund der einheitlichen Schnittstelle (alle Objekte besitzen einheitliche Verarbeitungsmethoden) zusätzlich die Entwicklungsarbeit. Akzeptiert der Webservice Daten im JSON-Format und liegen zurückgelieferte Daten ebenfalls im JSON-Format vor? Dies erleichtert die Arbeit mit den übermittelten Daten innerhalb der Android- Umgebung, da ein Parsen und Erstellen von JSON-Daten um einiges einfacher und übersichtlicher als es beispielsweise bei XML der Fall ist. Werden passende HTTP-Status Codes zurückgeliefert, die Informationen über die Ausführung der Anfrage auf dem Server liefern? Dies ist nötig, damit der Client bei der Ausführung der Anfrage entstehende Fehler erkennen und behandeln kann. Beispielsweise wenn es zu Parametervalidationsfehler kommt oder ein angefragtes Objekt nicht existiert. Erfüllt der vorliegende Webservice diese Minimalkriterien, so stufen wir ihn insgesamt als geeignet für unsere Erweiterung ein. Schritt 2 des Prozesses kann somit übersprungen werden. Wird lediglich die Unterstützung des JSON-Formats nicht erfüllt, so kann man den vorliegenden Webservice um diese erweitern. Bei allen anderen Kriterien würde ein Anpassen des vorliegenden Webservices dazu führen, dass die Webanwendung nicht mehr korrekt funktioniert, weshalb ein neuer Webservice notwendig ist. Analyse der Distance Retros API Die Analyse der Distance Retros API führte zu dem Ergebnis, dass die API insgesamt als ungeeignet eingestuft wurde. Folgender Abschnitt erläutert die Ungeeignetheit. Zunächst wurde schnell ersichtlich, dass der angebotene Webservice nur einen Teil der Webanwendungs-Funktionalität abdeckt. Theoretisch könnte die Untersuchung also hier bereits abbrechen, da die Ungeeignetheit damit festgestellt wurde. Abgesehen davon erfüllen die vorhandenen Webservice-Anfragen nicht die konkret 22

27 geforderten Kriterien unserer Eignungsuntersuchung. Dazu gehört, dass ein gezieltes Arbeiten mit vorhandenen Datenobjekten des Systems, wenn überhaupt nur eingeschränkt ermöglicht wird. So wird beispielsweise nicht für jedes Objekt ein GET- Request angeboten. Des Weiteren sind Funktionen teilweise in einem Aufruf zusammengefasst und werden über die Parameterwahl gesteuert. Ferner werden bei den Anfragen kaum passende Request-Methoden eingesetzt. Konkret beschränkt sich die gesamte API auf GET- und POST-Anfragen. So werden beispielsweise auch Lösch-Anfragen über eine POST-Anfrage durchgeführt. Des Weiteren existieren Daten verändernde Anfragen, die über ein GET-Request aufgerufen werden. All diese Eigenschaften würden die Entwicklung unseres Android-Clients nur unnötig erschweren. 11 Zum einen, weil wir aufgrund der Inkonsistenz der App sehr häufig auf die Dokumentation angewiesen wären. So variiert die Art der Daten- und Parameterübermittlung von Anfrage zu Anfrage sehr stark. Teilweise werden Parameter über die URL übermittelt, in anderen Fällen über JSON-Dokumente. Zum anderen müssten wir eingehende Daten in vielen Fällen filtern, um an die gewünschten Datenobjekte zu gelangen. Es ist klar zu erkennen, dass die API direkt auf die Funktionen der Webanwendung zugeschnitten ist und aufgrund der resultierenden hohen Kopplung zwischen Server und Web-Client nicht für die Kommunikation mit unserem Android-Client geeignet ist. 11 Unter der Annahme, dass der Webservice doch alle Funktionen abdecken würde. 23

28 4.5. Schritt 2: Entwicklung eines ressourcenorientierten Webservices In diesem Schritt wollen wir sofern nicht bereits vorhanden einen für die Erweiterung geeigneten Webservice entwickeln, um damit die technischen Voraussetzungen für die Implementierung des Android-Clients zu setzen. Dazu werden wir den Webservice zunächst designen und dokumentieren, um diesen anschließend implementieren zu können Anlehnung an den REST-Architekturstil Unseren neuen Webservice wollen wir an den REST-Architekturstil anlehnen. Dieser bietet uns einen bewährten Standard, welcher all unsere in Schritt 1 geforderten Anforderungen an einen für uns geeigenten Webservice erfüllt. Zudem bietet er uns weitere Vorteile, die darüber hinaus für seinen Einsatz sprechen. Hier sei noch mal angemerkt, dass wir unseren Webservice an den REST-Architekturstil anlehnen. Wir werden keinen vollwertigen REST-Webservice entwickeln, sondern auf die Einhaltung der Hypermedia-Restriktionen verzichten. Diese sind für unseren Anwendungszweck nicht zwingend erforderlich und würden den Entwicklungsaufwand unseres Webservices stark erhöhen. Nach dem REST-Reifegrad Modell RMM 12 soll unser Webservice somit Stufe 2 erreichen. Die Einhaltung der von uns gewählten REST-Restriktionen bietet unserem Anwendungszweck folgende Vorteile: 13 Ressourcen mit eindeutiger Identifikation Ressourcen erleichtern uns vor allem die objektorientierte Programmierung und damit Entwicklung der App, da wir gezielt Objekte anfragen und bearbeiten können. Repräsentationen Die Möglichkeit unterschiedliche Repräsentationsformate für dieselbe Ressource zu verwenden, erweitert die Verarbeitungsmöglichkeit dieser Daten innerhalb unterschiedlicher Anwendungszwecke und Systeme. Dies führt dazu, dass unser Webservice neben der Eignung für unseren Android-Client zudem auch noch 12 Bei RMM handelt es sich um eine von Leonard Richardson entwickelte und in [Ric08] vorgestellte Heuristik zur Einstufung des REST-Reifegrads eines Webservices. Richardson sieht dabei eine Beziehung zwischen der Einhaltung bestimmter REST-Restriktionen und der allgemeinen Qualität eines Webservices. Dabei werden vier aufeinander aufbauende Reife-Stufen (Level 0 bis 3) angegeben. Bei der ersten Stufe (Level 0) handelt es sich um Webservices, die für ihre Anfragen eine einzige URI und lediglich die Request-Methode POST verwenden. Level 1 beschreibt Webservices, die Ressourcen und verschiedene URIs verwenden, sich aber weiterhin auf die Request-Methode POST beschränken. Level 2 beinhaltet die Verwendung weiterer HTTP-Verben bzw. Request-Methoden (GET, PUT und DELETE). Level 3 führt schließlich Hypermedia (HATEOAS) ein. 13 REST-Eigenschaften nach [Til11] 24

29 zukunftssicherer in Bezug auf den Einsatz in anderen Systemen ist. Lose Kopplung Die insgesamt aus dem REST-Architekturstil resultierende Architektur trägt zusätzlich dazu bei unsere API zukunftstauglicher für weitere Client-Erweiterungen zu machen. Standardmethoden Der konsistente Einsatz der vier Standard-Request-Methoden bei allen Ressourcen führt zu einer einheitlichen Schnittstelle. Es ist stets klar, welche Methoden auf eine Ressource angewandt können und wie die URI einer Ressource zu verwenden ist. So kann man sich beispielweise bei einem GET immer darauf verlassen eine Repräsentation der jeweiligen Ressource zu bekommen. Idempotenz Die Request-Methoden GET, PUT und DELETE garantieren Idempotenz. D.h., diese Typen von Requests können mehrmals hintereinander auf die gleiche Ressource ausgeführt werden, ohne dabei durch das erneute Ausführen eine Auswirkung auf die Ressource zu bewirken. Unter Betrachtung des mobilen Kontexts und ggf. eingeschränkter Konnektivität stellt dies eine sehr wertvolle Eigenschaft dar, da z.b. bei einer ausbleibenden Antwort die gleiche Anfrage ohne Bedenken erneut abgeschickt werden kann. Statuslose Kommunikation Dies ist vor allem unter Betrachtung unseres mobilen Kontexts sehr wichtig, da keine durchgehende Verbindung mit dem Server nötig ist und beispielsweise bei temporären Netzwerkeinschränkungen die gleiche Anfrage einfach erneut gestellt werden kann, ohne vorher einen bestimmten Status wiederherstellen zu müssen. Da wir uns nicht an alle REST-Restriktionen halten, bezeichnen wir den entstehenden geeigneten Webservice im weiteren Verlauf der Arbeit als ressourcenorientierten Webservice Webservice-Design Nachdem wir nun wissen, wie die Eigenschaften eines für uns geeigneten Webservices aussehen, wollen wir als Nächstes einen solchen Webservice designen. Dazu nehmen wir die in Schritt 1 dokumentierte API zur Hilfe. Diese wird uns dabei unterstützen, vorliegende Ressourcen zu identifizieren. Neben den Eigenschaften, die wir aus dem REST-Architekturstil übernehmen, wollen wir dabei zusätzliche Eigenschaften festlegen die sich an die Eignungsuntersuchung aus Schritt 1 anlehnen. Dazu gehört die Beschränkung auf das JSON-Format bei der Datenübermittlung sowie die Notwendigkeit dem Entwickler eine übersichtliche, hier- 25

30 archische URI-Struktur bereitzustellen. Die folgende Liste trägt noch einmal zusammen, welche konkreten Eigenschaften unser ressourcenorientierter Webservice besitzen soll. Ressourcen mit Repräsentationen und eindeutige URIs Passende Request-Methoden Datenübermittlung über das JSON-Format Informative HTTP-Statuscodes Eine insgesamt übersichtliche URI-Struktur Identifikation der Ressourcen Als Erstes wollen wir sämtliche in unserem System verfügbaren Ressourcen unseres Systems bzw. unserer Webanwendung identifizieren. Zur Vereinfachung wollen wir uns dabei auf die Ressourcentypen Primärressourcen, Subressourcen, Listen und Filter beschränken, wobei sich Listen aus Primärressourcen zusammensetzen und Filter wiederum Teilmengen von Listen enthalten. Diese Typisierung von Ressourcen richtet sich nach [Til11]). Zur Identifikation von Ressourcenkandidaten aus bestehenden Anwendungen schreibt dieser ferner: In aller Regel sind die fachlichen Kernkonzepte die unmittelbar sinnvollen Kanditen. Beispiele dafür wären: jeder einzelne Kunde und seine Adresse in einem CRM-System, jedes Konto, jede Mahnung und jeder Zahlungseingang in einer Anwendung zur Unterstützung des Mahnwesens oder Benutzer und Konversation in einem Chat-Server. Damit wir bei unserer Ressourcenidentifikation nicht bei Null anfangen müssen nehmen wir die in Schritt 1 erstellte Dokumentation der vorliegenden API zur Hilfe. Anhand der darin dokumentierten Anfragen (dazu gehören auch die HTML-Anfragen), können wir ermitteln, welche Objekttypen innerhalb des Systems vorhanden sind. Wurde bei der API-Untersuchung in Schritt 1 ein Webservice festgestellt, welcher sämtliche Funktionen der Webanwendung abdeckt, so reicht es hier lediglich die Auflistung der Anfragen innerhalb der API-Dokumentation auf potenzielle Ressourcen, zu untersuchen. Dazu schaut man sich vor allem die Anfragenebschreibungen, sowie die übermittelten Daten bzw. deren Attribute an. Wurde die API hingegen als ungeeigneter eingestuft, sodass sie beispielsweise nur HTML-Anfragen bereitstellt, so müssen wir zusätzlich in den Code der Webanwendung schauen, um auch alle möglichen Ressourcen identifizieren zu können. Hier handelt es sich primär um Modelklassen und deren Attribute, die wir betrachten sollten. Beim Identifizieren der Ressourcen ist es außerdem wichtig, bereits auf ggf. vorhandene Ressourcen-Hierarchie zu achten und diese ebenfalls zu notieren. Also ob bestimmte Ressourcen Eltern- bzw. Kinderressourcen von anderen Ressourcen sind. Diese Hierarchie wollen wir nutzen, um übersichtlich strukturierte URIs erstellen zu können. 26

31 Bestimmung der URIs Nachdem wir alle Ressourcen identifiziert haben, wollen wir als Nächstes die jeweiligen URIs der Ressourcen bestimmen. Dabei ist es sinnvoll, vorhandene bzw. zu erkennende Ressourcen-Hierarchie über trennende Schrägstriche darzustellen (vgl. [Ric07]). Für unsere Dokumentation ist es außerdem wichtig Variablen bzw. Platzhalter für ggf. nötige Ressourcen-Identifikationsnummern (IDs) in unsere URI-Muster aufzunehmen. Über diese IDs werden wir später einen gezielten Zugriff auf Ressourcen ermöglichen. Das URI-Muster /parent/{parent_id}/child/{child_id} stellt hierzu ein Beispiel dar. Request-Methoden und übermittelte Daten der Anfragen Als Nächstes wollen wir jeder Ressource die benötigten Request-Methoden zuweisen. Außerdem wollen wir die konkret zu übermittelnden Daten der jeweiligen Anfrage bestimmen. Wir möchten dabei jede Datenzugriffs- bzw. Änderungsoperation der vorliegenden API abdecken, nur dass diese jetzt auf unsere Ressourcen abgebildet werden. Auch hier gilt, dass die Dokumentation der vorliegenden API uns die nötigen Informationen liefert. Zusätzlich wollen wir dafür sorgen, dass jede Ressource ein GET-Request unterstützt, selbst wenn dabei nur eine Fehlermeldung bzw. ein entsprechender HTTP-Statuscode zurückgeliefert wird (vgl. [Til11]). Bei der Festlegung der übermittelten Daten und deren Attribute sollte man darauf achten ein einheitliches Vokabular zu benutzen, sodass beispielsweise gleiche Attributtypen verschiedener Ressourcen nicht unterschiedliche Bezeichnungen besitzen. So sollten bei allen Ressourcen vorkommende IDs auch durchgehend als id bezeichnet werden 14. Dem Entwickler werden so nach einiger Arbeit mit dem Webservice unnötige Blicke in die Dokumentation erspart. Das Resultat dieses Abschnittes ist eine Dokumentation, die jede mögliche Anfrage unseres neuen Webservices beschreibt. D.h., jede Ressource besitzt für jede ihrer Request-Methoden eine Anfrage, und damit auch einen Eintrag in unserer Dokumentation. Hierbei ist es noch wichtig anzumerken, dass wir beim Abbilden einer alten Anfrage der vorliegenden API auf eine Ressourcen-Anfrage in unserem neuen Webservice jeweils notieren, aus welcher alten Anfrage diese Neue entstanden ist. Zusätzlich übernehmen wir die notierte Aufruf-View der Ursprungsanfrage. 15 Des Weiteren müssen wir daran denken, ggf. notwendige Authentifizierungsrechte einer Anfrage der Webanwendungs-API in die Dokumentation des neuen Webservices abzubilden. 14 Dies ist nur ein Beispiel, das ID-Attribut kann natürlich auch anders benannt werden, hauptsache es bleibt konsistent. 15 Auch auf diese Informationen werden wir in Schritt 4 zurückgreifen. 27

32 Distance Retros Webservice-Design Die Dokumentation des Distance Retros Webservices ist in Anhang C zu finden. Ein Beispiel für eine Konvertierung eines vorhanden nicht idempotenten PUT-Request der vorhandenen API in ein ressourcenorientiertes und idempotentes PUT-Request des neuen Webservices stellt die Funktion des Hervorhebens von sich auf dem Whiteboard befindenen Karten dar. Alte Anfrage: POST /ajax/featurecard/ Neue Anfrage: PUT /card/{card_id}/feature Die bestehende Anfrage führt eine Toggle-Funktion der Hervorherbung hervor. Diese ist nicht idempotent. Die neue Anfrage stellt die Hervorhebung ( feature ) als Ressource dar. Diese kann über ein PUT erstellt bzw. aktiviert und über ein DELETE gelöscht bzw. deaktiviert werden Webservice-Implementierung Nachdem wir den ressourcenorientierten Webservice designt haben, können wir diesen nun anhand unserer erstellten Dokumentation implementieren. Damit die Webanwendung unter allen Umständen weiterhin voll funktionsfähig bleibt, werden wir den Webservice parallel zur vorhandenen API der Webanwendung laufen lassen. Für die nötigen Controller-Klassen unseres Webservices, legen wir im Controller-Paket unserer Webanwendung ein neues Unterpaket an. Diesem geben wir einen beschreibenden Namen wie webservice oder rest. Für jede Ressource wird innerhalb dieses Paketes eine Controller-Klasse angelegt. Bei der Implementierung der Controller-Klassen können wir auf den Code der vorhandenen API zurückgreifen. Der Aufwand der Umsetzung des Webservices hängt stark von der Beschaffenheit der vorhandenen API ab. Im Optimalfall kann der gesamte Code der vorliegenden API bzw. der entsprechenden Controller als Basis übernommen um anschließend an den nötigen Stellen angepasst zu werden 16. Im schlimmsten Fall, nämlich dann wenn die vorhandene API vollständig auf HTML-Daten-Requests basiert, müssen wir für jede Ressource die entsprechenden Controller vollständig neu implementieren. Um die Arbeit mit zurückzugebenden und zu empfangenden Ressourcen innerhalb der Controller-Klassen zu erleichtern, hat es sich als bewährt erwiesen, die Modelklassen um Methoden zu ergänzen, die entsprechende Repräsentation zurückliefern bzw. Model-Instanzen anhand übermittelter Ressourcen-Daten aktualisieren. Ein Beispiel für eine solche Umsetzung sind die folgenden zwei Methoden. 16 also beispielsweise das Aufteilen von gebündelten Daten in einzelne zurückzugebende Ressourcen, das Anpassen von HTTP-Statuscode-Rückgaben, Vereinheitlichung des Attributvokabulars usw. 28

33 public ObjectNode getjsonrepresentation() Liefert eine Repräsentation der Ressource im JSON-Format zurück. public void updatefromjson(jsonnode json) Parst die übermittelten JSON-Daten und aktualisiert anhand dieser die entsprechende Model-Instanz. Es sei anzumerken, dass unsere Ressourcen nicht zwangsläufig nur auf Models unseres Systems basieren. So ist es typisch, dass bestimmte Ressourcen zusätzlich aus anderen Objekten bzw. Methoden des Systems innerhalb unserer Controller-Klassen abstrahiert werden müssen. Nachdem die Controller-Klassen angelegt und die nötigen Model-Klassen um ihre Repräsentationen erweitert wurden, können wir nun die einzelnen Anfragen implementieren. Dazu erstellen wir pro dokumentierter Webservice-Anfrage eine Methode in der entsprechenden Ressourcen-Controller-Klasse. Dabei lässt sich für die Benennung der entsprechenden Controller-Methoden einfacher Anfragen, also die Anfragen die sich auf das Abrufen, Erstellen, Aktualisieren und Löschen kompletter Ressourcen beziehen, folgende Abbildung anwenden. 17 Request-Methode GET POST PUT DELETE Controller-Methode showressource() createressource() updateressource() deleteressource() Hierbei sei nochmal angemerkt, dass wir bei der Implementierung der einzelnen Methoden auf die Garantierung der Idempotenz bei den entsprechenden Anfragen achten müssen. Des Weiteren soll bei den Anfragen zudem Folgendes gewährleistet werden: createressource() Methoden liefern eine Repräsentation der erstellten Ressource, inklusive der neu zugewiesenen ID der Ressource zurück. updateressource() Methoden liefern eine Repräsentation der aktualisierten Ressource zurück. Wurde eine Methode vollständig implementiert, so ergänzen wir unsere HTTP-Router- Konfiguration um den entsprechenden Eintrag, der sich aus Request-Methode, URI- Muster und zugewiesener Controller-Methode zusammensetzt. Damit die Funktionalität der Webanwendung gewährleistet bleibt und es nicht zu URI- Konflikten mit dem alten Webservice kommt, versionieren wir den neuen Webservice innerhalb der HTTP-Router-Konfiguration. Dies bietet uns zudem den Vorteil, dass sofern in der Zukunft größere Webservice-Umstrukturierungen durchgeführt werden, wir diese auch als neue Webservice-Version parallel zur Alten laufen lassen können, damit mit der ersten Webservice-Version entwickelte Clients ihre Implementierung nicht 17 Das Wort Ressource dient dabei als entsprechender Platzhalter. 29

34 zwingend anpassen müssen. Wir stellen der Basis-URI also eine entsprechende Versionsnummer an (z.b. /v1/...). Um unseren Android-Client in Schritt 5 (Entwurf und Implementierung) implementieren zu können, ist es unabdingbar, dass wir den soeben implementierten Webservice ausführlich testen. Distance Retros Webservice-Implementierung Die API der Distance Retros Webanwendung wurde um einen geeigneten Webservice erweitert, sodass eine Anbindung der zu entwickelnden Android-App an das System ermöglicht wird. Innerhalb des neuen controllers.rest Pakets der Webanwendung wurde zu jeder Ressource eine Controller-Klasse angelegt. Dabei musste der Objekttyp Action Item zusätzlich abstrahiert werden, um als eine Ressource dargestellt werden zu können. Dies lag daran, dass das System intern mit zwei verschiedenen Action Item Model-Klassen arbeitet, nämlich normalen Action Items und importierte Action Items. Diese Information ist für den Anwender des Webservices allerdings nicht nötig. Zum Testen der Anfragen wurde die Anwendung POSTMAN 18 verwendet. Diese bietet eine komfortable Umgebung zum Testen, da Anfragen in einem Katalog angelegt, angepasst und nachträglich erneut ausgeführt werden können

35 4.6. Schritt 3: Anforderungsanalyse Nachdem mit dem Vorhandensein eines geeigneten Webservices die technischen Voraussetzungen für unsere Erweiterung gesetzt sind, wollen wir in diesem Schritt die Anforderungsanalyse durchführen. Diese werden wir in drei Schritten realisieren. Im ersten Schritt werden wir in einem Gespräch mit dem Kunden einige Grundanforderungen der zu entwickelnden App bestimmen. Im zweiten Schritt werden wir einen Teil der funktionalen Anforderungen unserer App aus den Anfragen unseres geeigneten Webservices ableiten. Dieser Anforderungsteil besteht aus Funktionen, welche die App mit der bestehenden Webanwendung teilen wird. Im dritten Schritt werden wir dann mithilfe von Personas und einem Szenario Zusatzanforderungen aufdecken, die sich speziell an den mobilen Kontext unserer App richten. Die so entstehenden funktionalen und nicht-funktionalen Anforderungen vervollständigen damit unseren Anforderungskatalog. Die so ermittelten Anforderungen werden wir im nächsten Prozessschritt (Benutzeroberflächenund Interaktionsdesign) verwenden um unsere Android-GUI zu designen Bestimmung der Grundanforderungen Für die Entwicklung unserer Android-App müssen wir einige bestimmte Grundanforderungen an diese ermitteln. Diese Anforderungen hängen dabei von der Präferenz des Kunden ab. Dazu stellen wir dem Kunden folgende Fragen: Welche Funktionen sollen in der App nicht vorhanden sein? Hier kann es sich vor allem um spezielle Funktionen wie Administrations-Funktionalitäten, die beispielsweise für die initiale Konfiguration des Systems notwendig sind, handeln. Bei diesen kann davon ausgegangen werden, dass diese weiterhin über die Webanwendung vorgenommen werden und dass solche Funktionen in so gut wie allen Anwendungsfällen deshalb nicht in die App übernommen werden sollen. 19 Um eine solche Auswahl der nicht zu übernehmenden Funktionen dem Kunden zu erleichtern, bedienen wir uns der in Schritt 1 erstellten Übersicht der Benutzeroberflächen-Struktur. Damit hat der Kunde die Möglichkeit uns auf eine einfache Art mitzuteilen, welche Funktionalitäten bestimmter Seiten bzw. Views nicht in die App integriert werden sollen. Später werden wir mithilfe dieser Auswahl sämtliche in diesen Views vorkommenden Funktionen aus unserem Anforderungskatalog entfernen. 19 Davon abgesehen ist dies natürlich auch eine Frage der Kosten bzw. des Aufwands und hängt damit klar vom Kunden ab. 31

36 Welche zusätzlichen Anforderungen sollen in der App umgesetzt werden? Hier kann sich der Kunde zu speziellen Wünschen äußern, die er in Bezug auf die Umsetzung der App bzw. dessen erweiterten Funktionsumfang hat. Aufgrund der zuvor in Schritt 1 durchgeführten Analyse der Webanwendung besitzen wir inzwischen ein gewisses Verständnis über die Domäne des Kunden. Dies soll uns die Interpretation der Kundenwünsche erleichtern. Gemeinsam sollen so optimalere Umsetzungs-Lösungen gefunden werden. Grundanforderungen der Distance Retros Android-App Das fiktive Kundengespräch 20 zur Entiwcklung der Distance Retros Android-App hat ergeben, dass auf sämtliche Administrationsfunktionen, die Action Items exportieren Funktionalität sowie die Bearbeitung des Benutzerprofils verzichtet werden. Konkret sollen folgende Views ignoriert werden Template-Verwaltung, Benutzerverwaltung, Benutzerprofil, Action Items exportieren Ableitung funktionaler Anforderungen aus dem Webservice Für die Bestimmung des zweiten Teils der Anforderungen wollen wir uns auf unseren geeigneten Webservice stützen. Dabei werden wir aus dem Webservice funktionale Anforderungen ableiten, die das Grundgerüst der Webanwendungs-Funktionalität darstellen. Hierbei bedienen wir uns den Ansätzen der klassischen Software-Entwicklungs- Methode der Structured Analysis von Tom DeMarco (vgl. [Sch11]). Da unser Webservice die Voraussetzung hat, sämtliche Funktionen der Webanwendung bereitzustellen 21, können wir ihn als zentrale Schnittstelle zu unserem bestehenden System sehen. Die Dokumentation unseres Webservices stellt uns dabei eine Übersicht dieser Datenflüsse, also welche Daten aus dem System und in das System fließen, zur Verfügung. Zudem finden wir in der Dokumentationen Informationen über den genauen Inhalt dieser Daten. Wurde unser Webservice in Schritt 2 entwickelt, so besitzt dieser aufgrund unserer Webservice-Kriterien eine übersichtliche Struktur, die uns zusätzlich ein einfacheres Ableiten ermöglichen soll. Konkret gehen wir bei dieser Anforderungs-Ableitung nun wie folgt vor. Für jede dokumentierte Anfrage des geeigneten Webservices betrachten wir jeweils die Anfragenbeschreibung, das entsprechende Objekt bzw. die entsprechenden Ressource sowie die übermittelten Daten. Aus diesen Informationen leiten wir dann eine funktionale 20 Dies soll beispielhaft die Anwendung des Prozessschrittes verdeutlichen. 21 Dies können wir voraussetzen, da in Schritt 1 die vorliegende API darauf untersucht wurde, ob diese Webservice-Funktionalität bietet, die den gesamten Funktionsumfang der Webanwendung abdeckt. War dies nicht der Fall, so wurde in Schritt 2 ein Webservice entwickelt, der die gesamte Funktionalität der Webanwendung abdeckt. Unser Webservice bietet also in beiden Fällen die gesamte Funktionalitätsabdeckung. 32

37 Anforderung ab, welche wir anschließend dokumentieren. Dabei müssen wir ggf. vorhandene Authentifizierungsrechte der Anfragen beachten und in unsere Anforderung übernehmen. Das folgende Beispiel soll diesen Ableitungsvorgang verdeutlichen: Aus der Anfrage POST /v1/users leiten wir die Anforderung Administratoren können Benutzer anlegen ab (unter Beachtung der über das JSON-Format übermittelten Daten sowie der Anmerkung, dass für die Anfrage die Authentifizierung eines Administrators notwendig ist). Des Weiteren können wir wir die Anforderung um die Beschreibung Benutzer enthält Name und ergänzen, da diese Daten aus dem Inhalt der zu übermittelnden Daten hervorgehen. Zu der jeweiligen Anforderung notieren wir uns zudem eine eindeutige Anforderungsnummer sowie die Nummer der Anfrage, aus der wir diese Anfoderung abgeleitet haben. Mit dieser können wir dann Zurückverfolgen, in welcher View die Anfrage und damit auch Funktion bzw. funktionale Anforderung in der Webanwendung aufgerufen wurde. Dies wird uns in Schritt 4 dabei helfen eine View-Grundstruktur für unsere zu designende App zu erstellen, bei der wir die einzelnen Anforderungen den entsprechenden Views zuweisen werden. Anschließend werden wir diese View-Grundstruktur an unsere Zusatzanforderungen der App anpassen. Es ist zu beachten, dass wir beim Ableiten der Anforderungen alle Anfragen ignorieren, die aus einer vom Kunden deselektierten View stammen. 22 Die Information, aus welcher View die Anfrage stammt, haben wir bei der Dokumentation des Webservices notiert. Zu diesem Schritt des Aufstellens der funktionalen Anforderungen sei angemerkt, dass dieser Teil theoretisch auch aus einer vorhandenen Spezifikation der Webanwendung übernommen werden könnte. In diesem Fall wäre es aber nötig, dass man die Anforderungen der Spezifikation auch den in der Webanwendung vorhandenen Views zuordnen kann und diese Information bei der Anforderung notiert. Abgeleitete funktionale Anforderungen der Distance Retros App Die so ermittelten und dokumentierten funktionalen Anforderungen der Distance Retros App sind dem Anhang D zu entnehmen Aufdecken von Zusatzanforderungen Für die Bestimmung des dritten und damit letzten Teils unseres Anfragenkatalogs erstellen wir Personas und setzen diese anschießend in ein Anwendungsszenario. Dieses soll einen fiktiven Einsatz unserer Android-App beschreiben. Aus diesem Szenario werden wir dann zusätzliche funktionale und vor allem nicht-funktionale Anforderungen 22 Wir gehen hier davon aus, dass diese Anfragen auch wirklich nur in diesen Views vorkommen. Um wirklich sicher gehen zu können, muss man hier noch einmal überprüfen, ob diese Anfragen nicht in einer der restlichen Views vorkommen. 33

38 extrahieren. Die angewandte Methodik der Personas und Szenarios richtet sich dabei nach [Coo07]. Erstellen von Personas Hier soll noch einmal kurz erläutert werden, was wir unter einer Persona verstehen und welchen Zweck sie für uns hat. Eine Persona ist ein Modell eines fiktiven Nutzers einer zu entwickelnden Anwendung. Dieses Modell soll während des Designprozesses dabei helfen, Designentscheidungen zu treffen und das Auftreten des elastischen Nutzers 23 zu vermeiden. Die Persona beschreibt typische Eigenschaften des Nutzers sowie das Verhalten und die persönlichen Motivationen beim Verwenden der Anwendung. Üblicherweise wird für die Ermittlung dieser Nutzer-Informationen dessen Verhalten innerhalb eines bestimmten, für den Einsatz der Anwendung relevanten Kontext studiert. Dies könnte z.b. das Verwenden eines Vorgängersystems der Anwendung oder das Durchführen einer mit der Anwendung in Verbindung stehenden Tätigkeit sein. Im Fall unserer Erweiterung bietet es sich an, den Nutzer während der Verwendung der bestehenden Webanwendung zu studieren. Der Einsatz einer Persona hat den Vorteil, dass man anstelle dieser großen Menge an gesammelten Rohdaten ein kompaktes, greifbares Modell des Nutzers hat. Distance Retros Personas Für die Entwicklung der Distance Retros App wurden zwei Personas erstellt, die repräsentativ für die Benutzergruppe Moderator und Teilnehmer einer Retrospektive stehen sollen. Eine konkrete Verwendungsuntersuchung der Webanwendung konnte in diesem Fall nicht vorgenommen werden. Diese Personas basieren hingegen auf Eigenschaften von Mitgliedern eines agilen Softwareentwicklungsteams. Für die Ermittlung der relevanten Eigenschaften und Motivationen wurden Informationen aus Literatur zur agilen Softwareentwicklung([Wol11], [Jan13]) und Literatur zu verteilten Teams sowie Retrospektiven ([Eck10], [Dav09]) extrahiert. Die Personas werden nun vorgestellt. Retrospektiven-Teilnehmer Tim 29 Jahre alt Softwareentwickler arbeitet seit 2 Jahren im agilen Team sehr gute Computerkenntnisse 23 Bei Produktionsentscheidungen werden die Anforderungen und Bedürfnisse des Benutzers verbogen, um den Weg der technisch einfachsten Umsetzung zu rechtfertigen. 34

39 Tim ist ein offener und kommunikativer Mensch. Mit seinem sechs Kollegen fühlt er sich verbunden. Zusammen bilden wir ein echt gutes Team. Jeder von uns fühlt sich für den gesamten Quellcode mitverantwortlich. An den verteilten Retrospektiven, die nach jeder Projekt-Iteration stattfinden, nimmt er gerne teil. Er hat seinen Kollegen immer viele Verbesserungsvorschläge mitzuteilen. Diese formuliert er meist sehr schnell auf den dazu vorgesehenen Karten, während die anderen noch am überlegen sind. Dabei spricht er auch mal unangenehme Themen an. Davon profitieren wir schließlich alle. Zur Eigen- und damit auch Teamverbesserung ist Tim allerdings gleichermaßen um das Feedback seiner Kollegen bemüht. Er lernt gerne neue Techniken und Werkzeuge kennen. Ziele: Ideen und Vorschläge einfach und schnell präsentieren Feedback zur Eigen- und Teamverbesserung bekommen Retrospektiven-Moderatorin Mona 35 Jahre alt Softwareentwicklerin, Kommunikationsbeauftragte arbeitet seit 7 Jahren im agilen Team sehr gute Computerkenntnisse Mona ist schon lange im Team dabei. Neben ihrer Arbeit als Softwareentwicklerin, übernimmt sie seit einiger Zeit auch die Rolle der Kommunikationsbeauftragten. Wenn es während einer Iteration größere Probleme mit dem anderen Team gibt, dann wenden sich meine Kollegen meist an mich. An größeren Meilensteinen des Projekts besucht Mona das externe Team auch vor Ort. Während der verteilten Retrospektiven übernimmt Mona oft die Rolle der Moderatorin. Dabei ist es ihr besonders wichtig, die limitierte Zeit der Retrospektive effizient zu nutzen und sinnvolle Resultate hervorzubringen. Dazu gehört das Herausarbeiten konkreter Maßnahmen, die sie in den Action Items festhält. Mona bevorzugt einfache Lösungen, die vom gesamten Team iterativ erarbeitet werden. Ich möchte immer alle Meinungen hören, das ist sehr wichtig. Manchmal frage ich auch gezielt bei Kollegen nach, die noch nichts beigetragen haben. Oft kommen dabei sehr gute Ideen raus. Wenn die Gruppe zu sehr vom aktuellen Thema abschweift, kümmert sich Mona darum sie wieder auf den richtigen Kurs zu bringen. Ziele: Zeit effizient nutzen und konkrete Maßnahmen festlegen 35

40 Überblick über die Retrospektive behalten Erstellen eines Szenarios Mithilfe eines Szenarios wollen wir nun einen fiktiven Einsatz unserer zukünftigen App beschreiben. Der Hauptzweck hierfür ist das Extrahieren zusätzlicher Anforderungen der App. Im Fall unserer Webanwendungs-Erweiterung handelt es sich dabei vor allem um nicht-funktionale Anforderungen, welche die Art und Weise der App-Bedienbarkeit betreffen. Unsere zuvor erstellten Personas kriegen in dem Szenario eine Rolle, in der sie ein bestimmtes Ziel, mithilfe der App erfüllen. Wir gehen des Weiteren davon aus, dass die Interaktion mit dem Interface der App möglichst simpel 24 ist. D.h., wir geben nicht konkret an, wie genau das Interface bzw. die Interaktion nun aussieht. Wir wollen zudem ggf. auftretende zusätzliche Anforderungen des Kunden (aus dem ersten Gespräch) in dieses Szenario einbauen. So haben wir die Möglichkeit, seine zuvor gestellten Wünsche noch mal aus unserer Sicht zu präsentieren und somit zu überprüfen, ob die Wünsche des Kunden korrekt umgesetzt wurden. In Schritt 4 werden wir dann noch einmal auf den Kunden zurückkommen, und mit Hilfe eines GUI-Prototyps eine zweite Überprüfung vornehmen. Distance Retros App-Szenario Hier soll ein fiktiver Einsatz der Distance Retros Android-App während einer verteilten Retrospektive vorgestellt werden. Die zuvor erstellten Personas Mona und Tim nehmen an dieser Retrospektive teil. 1. Mona sitzt mit ihrem Tablet im Zug, sie ist auf dem Weg zur Firma. Um 10 Uhr findet dort die verteilte Retrospektive mit einem externen Team statt. Mona wird die Retrospektive moderieren, unterwegs bereitet sie diese bereits vor. Sie öffnet die letzte Retrospektive in der Distance Retros App und schaut sich an, welche Action Items in ihr festgelegt wurden. Danach erstellt sie die heutige Retrospektive und legt in dieser bereits zwei Überschriften positiv und negativ an. 2. In der Firma angekommen sammeln sich Monas Kollegen bereits im Besprechungsraum. Einige sitzen vor ihrem Laptop, andere haben ein Tablet dabei. Tim sitzt entspannt auf dem Stuhl, in seiner Hand hält er ein Tablet. Schnell schaut er sich nochmal die Action Items an, die ihm nach der letzten Iteration zugewiesen wurden. Währenddessen startet Mona das Videkonferenz-Tool. Das externe Team ist auf dem Beamer zu sehen. Sie begrüßt alle Teilnehmer und startet 24 Pretending it s magic nach [Coo07] 36

41 offiziel die Retrospektive. Es folgt ein Rückblick auf die Ergebnisse der letzten Retrospektive. Wer hat welche Action Items erledigt? Welche Action Items sind noch offen? Mona lässt die Teilnehmer der Reihe nach sprechen, das externe Team beginnt. Den Status des jeweils besprochenen Action Items aktualisiert sie mithilfe der App. 3. Anschließend gibt es eine Feedbackrunde zu den Geschehnissen der letzten Iteration. Dazu gibt Mona ihre zuvor erstellten Überschriften frei und bittet die Teilnehmer sich Gedanken darüber zu machen, was in der letzten Iteration gut und was schlecht lief. Jeder bekommt 5 Minuten Zeit dazu passende Karten zu schreiben und diese an das globale Whiteboard zu schicken. Tim schreibt schnell einige Karten auf seinem Tablet und schickt diese ab. Dabei ordnet er die meisten Karten der Überschrift negativ zu. Ein anderer Kollege, ebenfalls im Einsatz eines Tablets bereitet einige Karten zunächst vor und editiert sie noch einmal vor dem Abschicken. 4. Nach Ablauf der Zeit werden die Karten - moderiert von Mona - einzeln durchgegangen. Karten werden sortiert und inhaltlich gleiche entfernt. Die Teilnehmer hatten relativ viel zu berichten, weshalb Mona eine Abstimmung ankündigt. Welche Themen erscheinen der Gruppe am wichtigsten? Was soll als Nächstes angegangen werden? Dazu sollen die Teilnehmer für jeweils zwei Karten favorisieren. Tim gibt für die beiden seiner Meinung nach wichtigsten Karten seine Stimme ab. Nachdem alle abgestimmt haben, sucht Mona die zwei Karten mit den meisten Stimmen raus und hebt diese auf dem Whiteboard hervor. 5. Nachdem alle wichtigen Karten besprochen wurden, werden gemeinsam Action Items definiert und anschließend zugewiesen. Tim hat sich für die Bearbeitung eines bestimmten Action Items gemeldet. Nachdem es ihm zugewiesen wurde macht er sich in der App gleich ein paar Notizen dazu. 6. Zum Abschluss bedankt sich Mona bei allen Teilnehmern und beendet offiziell die Retrospektive. Gemeinsam geht die lokale Gruppe in die Kantine. Nach dem Mittagessen, auf dem Weg zum Büro, schaut sich Tim in der App noch mal an, welche Action Items ihm in der Retrospektive zugewiesen wurden, sodass er sich gleich an die Arbeit machen kann. Extrahieren zusätzlicher Anforderungen aus dem Szenario Nachdem das Fundament der grundlegenden Anforderungen der App aufgestellt wurde, widmen wir uns unserem zuvor erstellten Szenario und extrahieren hieraus zusätzliche funktionale sowie nicht-funktionale Anforderungen. Dabei achten wir vor allem auf Hinweise, aus denen nicht-funktionale Anforderungen bestimmt werden können, die die gewünschte Art und Weise der App-Bedienung beschreiben. 37

42 Zusätzliche Anforderungen der Distance Retros App Aus dem Szenario der Distance Retros App wurden so zusätzlichen Anforderungen bestimmt. Die Nummern geben dabei den jeweiligen Abschnitt des Szenarios an, aus dem die Anforderung extrahiert wurde. Funktionale Anforderungen R26: Moderatoren haben eine gesonderte Übersicht über die Action Items einer Retrospektive [1] [2] R27: Nutzer haben eine Übersicht über die ihnen zugewiesene Action Items [2] [5] [6] R28: Nutzer können Notizen zu zugewiesenen Action Items anlegen [5] Nicht-funktionale Anforderungen R29: Action Items sollen übersichtlich und schnell verwaltet werden können [1] [5] R30: Eine schnelle Navigation innerhalb der App ist möglich [2] R31: Karten bzw. Texte sollen schnell und komfortabel eingeben werden können [2] [3] Insgesamt hat sich herausgestellt, dass innerhalb des mobilen Kontexts vor allem die Arbeit mit den vorliegenden Action Items wichtig ist. Eine gesonderte Action Items Übersicht soll dem Nutzer eine flexiblere und gezieltere Interaktion mit dem Distance Retros System ermöglichen, da Action Items sonst auf dem Whiteboard gesucht werden müssen. Diese liegen dort nämlich lediglich als verschiebbare Widgets vor. 38

43 4.7. Schritt 4: Benutzeroberflächen- und Interaktionsdesign In diesem Schritt wollen wir die Benutzeroberfläche der App designen, damit wir diese im nächsten und letzten Schritt (Entwurf und Implementierung) in Code umsetzen können. Dabei wollen wir nicht die Benutzeroberfläche der Webanwendung übernehmen, sondern eine neue, für den mobilen Kontext unserer App erstellte Benutzeroberfläche erstellen. Konkret wollen wir eine Android-Activity-Struktur unserer App herleiten. Für diese Herleitung werden wir das in diesem Schritt eingeführte Konzept der View-Container verwenden. Nachdem die Activity-Struktur festgelegt wurde, werden wir GUI-Mockups und anschließend einen interaktiven GUI-Prototypen erstellen, sodass wir uns während der Implementierung im nächsten Schritt nach diesen richten können View-Container zur Herleitung der Activity-Oberflächen-Struktur Nach [Hoo11] ist es besonders wichtig beim Designen mobiler Apps, ein neues Produkt, mit einer neuen Benutzeroberfläche zu erstellen und nicht einfach nur das Design der bestehenden Desktopanwendung in eine mobile Umgebung zu konvertieren. Dies liegt zu einem an den Einschränkungen der mobilen Geräte, wie z.b. eine kleinere Displaygröße aber auch an zusätzlichen Möglichkeiten, wie erweiterte Eingabemethoden (z.b. Gesten). Des Weiteren besitzen mobile Apps andere Anforderungen als Desktopanwendungen. Die Frage ist nun, wie wir ein solches Neu-Erstellen der Benutzeroberfläche und dessen Interaktion dennoch möglichst strukturiert und somit aufwandsreduzierend realisieren können. Dazu wird das Konzept der View-Container vorgestellt. Dieses soll uns beim strukturierten Erstellen einer an den mobilen Kontext angepassten Benutzeroberfläche helfen. Es orientiert sich dabei an der Benutzeroberfläche der Webanwendung, um uns so einen Startpunkt zu geben, ermöglicht es aber, diese Grundlage den kontextspezifischen Anforderungen der mobilen App anzupassen. Hiermit wird versucht einen guten Kompromiss zwischen dem kompletten Neuerstellen einer Benutzeroberflächenstruktur und dem kompletten übernehmen bzw. konvertieren bereits vorhandener Benutzeroberflächen zu finden. Die Grundidee hierbei ist, dass wir zur Herleitung unserer Benutzeroberflächenstruktur die funktionalen Anforderungen bzw. Funktionen potenzieller Views als verschiebbare Elemente sehen, die wir zwischen den einzelnen View-Kandidaten umordnen können. Die Views selbst sind dabei auch nicht fix, sondern können zusammengefasst, erweitert oder entfernt werden. Diese dynamischen Views bezeichen wir dabei als unsere View-Container, welche unsere verschiebbaren funktionalen Anforderungen enthalten. Der Ausgangszustand der View-Container-Struktur wird dabei die Benutzeroberflächenstruktur der Webanwendung sein. Diese wird dann iterativ an die in Schritt 3 ermittelten Zusatzanforderungen der Android-App angepasst. Dabei werden die Motivationen und Ziele der Personas berücksichtigt. Sobald der Zustand der View-Container-Struktur als final eingestuft wird, können wir 39

44 aus dieser unsere Activites herleiten. Wir erhalten also eine Übersicht der nötigen Activites sowie der jeweils zugewiesenen Anforderungen, die diese Activity erfüllen muss. Die folgenden Abschnitte beschreiben dieses Vorgehen nun genauer. Ableitung der View-Container Zunächst wollen wir unsere View-Container erstellen. Dazu nehmen wir die in Schritt 1 dokumentierte Benutzeroberflächen-Struktur der Webanwendung. Diese beinhaltet eine Auflistung aller Views und den sogenannten Sub-Views (dynamische Elemente). Für jede View und Sub-View wollen wir nun einen View-Container erstellen. Jeder View-Container bekommt eine ID und den Titel der View, den wir ebenfalls in Schritt 1 definiert haben. Hierbei ist zu beachten, dass wir die in Schritt 3 vom Kunden als nicht zu übernehmenden Views ignorieren. Zuordnung webservicebasierter funktionaler Anforderungen Als Nächstes wollen wir den einzelnen View-Containern die aus dem Webservice stammenden funktionalen Anforderungen zuordnen und so den Ausgangszustand unserer View-Container-Struktur herstellen. Wir bilden also die angebotenen Funktionen der jeweiligen Webanwendungs-Views auf unsere View-Container ab. Hierbei soll daran erinnert werden, dass wir in Schritt 3 unsere funktionalen Anforderungen aus den Webservice-Anfragen abgeleitet haben. Bei der Dokumentation der Webservice- Anfragen wiederum haben wir notiert, welcher View diese entstammen. Diese Information verwenden wir nun, um die funktionalen Anforderungen den View-Containern zuzuordnen. Die GET-Requests, denen innerhalb der Dokumentation keine View zugewiesen ist ignorieren wir dabei. Wir übernehmen außerdem die Navigationsstruktur der ursprünglichen Benutzeroberflächenstruktur. Zuordnung ergänzender Zusatzanforderungen Wir haben nun den Ausgangszustand der View-Container-Struktur hergestellt, welche der Zuordnung von Views der Webanwendung und deren entsprechenden Funktionen entspricht. Es folgt die Ergänzung um funktionale Anforderungen, die aus dem Szenario extrahiert wurden sowie die allgemeine Anpassung der View-Container-Struktur an unsere nicht-funktionale Anforderungen. Dabei wollen wir des Weiteren die Motivationen und Ziele unserer in Schritt 3 erstellten Personas berücksichtigen. Als Erstes werden wir nun einen zusätzlichen View-Container mit dem Titel Android System hinzufügen. Diesem werden wir ggf. auftretende Anforderungen bzw. Funktionen, die vom Android-System übernommen werden können zuweisen. Dazu gehört beispielsweise das Verwenden des Benachrichtigungssystems, der Kamera oder das Bereitstellen von Android-Widgets. Generell bietet die Android-Plattform eine Vielzahl 40

45 an Schnittstellen, die aufgrund von Auslagerung der Funktionalität unseren Implementierungsaufwand reduzieren. Als Nächstes ordnen wir die aus dem Szenario extrahierten funktionalen Anforderungen unseren Containern zu. Dabei kann es vorkommen, dass es keinen passenden oder sinnvollen View-Container für eine solche Anforderung gibt. In so einem Fall fügen wir einen neuen Container hinzu. Iterative Umstrukturierung der View-Container Es folgt ein iterativer Prozess, bei dem wir folgende Aktionen durchführen können: funktionale Anforderungen in andere View-Container verschieben View-Container hinzufügen, zusammenfassen, entfernen Navigationsflüsse zwischen View-Containern ändern Der daraus resultierende Zustand der View-Container stellt nun die Grundlage unserer Activity-Struktur dar. Aus jedem Container wird also eine Activity erstellt, mit Ausnahme des Android-System-Containers. Umstrukturierung der Distance Retros App View-Container Aufgrund der funktionalen Anforderung R26: Moderatoren haben eine gesonderte Übersicht über die Action Items einer Retrospektive wurde der neue View-Container Action Items hinzugefügt. Diesem wurden die funktionalen Anforderungen des Action Item Imports (R24: Moderatoren können sich importierbare Action Items anzeigen lassen, R25: Moderatoren können Action Items importieren ) zugewiesen, da aufgrund der neuen Action Items Übersicht diese primär für die Verwaltung von Action Items zuständig sein soll. Die Funktionalität des Action Item Imports wurde gleichzeitig aus der Whiteboard-View entfernt. Es hat also ein Verschieben der Funktionalität von der Whiteboard-View zur Action Items View stattgefunden. Aufgrund der funktionalen Anforderung R27: Nutzer haben eine Übersicht über die ihnen zugewiesene Action Items wurde der neue View-Container Meine Action Items hinzugefügt. Die ursprünglichen View-Container Whiteboard und Persönlicher Arbeitsbereich wurden zusammengefasst, da diese innerhalb der Android-App in einer View dargestellt werden sollen Activity-Design Nachdem wir mit Hilfe der View-Container unsere Activitys und deren zugehörigen Funktionen hergeleitet haben, ist die Frage was in den Activities umgesetzt werden 41

46 soll geklärt. Es folgt die Frage wie es umgesetzt werden soll. Dabei geht es vor allem darum, wie wir unsere vorhandenen Daten darstellen. Dazu wollen wir nun unter Zuhilfenahme des Android Design Guides die einzelnen Activities entsprechend designen, da uns dieser die dazu nötigen Prinzipien, Richtlinien und Vorgaben gibt. Dies nimmt uns zum einen eine Menge Arbeit ab, da wir weniger probieren müssen und auf Bewährtes zurückgreifen können. Zum anderen gewährleistet uns dies zudem bei korrekter Anwendung eine gute Usability der App. Des Weiteren sei hier anzumerken, dass wir in dieser Activity-Design-Phase noch darauf achten müssen, ggf. einzelne Activities bzw. Views in Datenauswahl-Sichten und Daten-Detail-Sichten zu trennen. Diese Aufteilung hängt insbesondere davon ab, ob wir unser App für Smartphone- oder Tablet-Geräte entwickeln wollen. Vor allem bei Smartphone-Geräten, die aufgrund ihrer geringeren Displaygröße weniger Informationen auf einmal darstellen können, ist dies oft der Fall. Erstellen von GUI-Mockups Während des Designens der Activities wollen wir GUI-Mockups erstellen. Diese dienen uns nicht nur als Endprodukt der entworfenen Activities, sondern vor allem auch für das Ausprobieren verschiedener Umsetzungsvarianten. Der Prozess der Mockup- Erstellung selbst dient zudem als Kommunikationsmittel zur Diskussion von Ideen (vgl. [Bux07]). Dies ist also vor allem ein iterativer Prozess. Erstellen eines interaktiven Prototypen Nachdem die Activities designt wurden wollen wir als Nächstes einen interaktiven GUI-Prototypen unserer App erstellen. Dieser Prototyp ist vor allem deshalb wichtig, weil wir mithilfe unserer Mockups nicht die Möglichkeit haben Interaktion darzustellen. Des Weiteren haben wir so die Möglichkeit verschiedene Interaktionsmöglichkeiten live auszuprobieren. Der GUI-Prototyp bietet uns zudem die Möglichkeit noch einmal Feedback vom Kunden zu bekommen, bevor es dann im nächsten Schritt zur Fertigstellung der App kommt. Prototyp der Distance Retros App Für die Entwicklung der Distance Retros App wurde ein interaktiver Prototyp erstellt. Dieser wurde vor allem dazu genutzt, verschiedene Interaktionsmöglichkeiten, die vom Android Design Guide empfohlen werden auszuprobieren und eine zu dem Kontext passende Variante auszuwählen. Dabei wurde vor allem Wert auf die Umsetzung einer effektiven Navigation gesetzt, die es dem Nutzer ermöglicht sich schnell innerhalb der App zu bewegen. Neben der Navigation zwischen den einzelnen Activities, wurden zudem einzelne Dummy-Funktionen eingebaut, die vor allem dazu dienen sollen die Interaktion mit dem Whiteboard zu testen, speziell ob die Größe einzelner Widgets 42

47 touchgerecht umsetzbar ist. Dabei wurde vor allem erkannt, dass eine Auslagerung der Widget-Aktionen nötig ist. 25 Der entwickelte Prototyp wurde mithilfe von Adobe Flash und der Programmiersprache Action Script entwickelt. Mit Hilfe der Adobe AIR Laufzeitumgebung, kann so eine installierbare APK-Datei erstellt werden, wodurch der Prototyp auf einem Android-Gerät für Testzwecke installiert und ausgeführt werden kann. Diese Umsetzung wurde deshalb präferiert, da so relativ schnell eine interaktive Benutzeroberfläche umgesetzt werden kann, die nach eigenen Bedürfnissen gestaltet wird. So konnten bereits innerhalb des Prototypen Android-GUI-Elemente nachgebildet werden, um ein Benutzererlebnis nachzubilden, das dem der richtig implementierten App nahe kommt. Screenshots des Prototypen sind in Anhang E zu finden. 25 Näheres zu den konkreteren Designentscheidungen ist in Kapitel 5 zu finden. 43

48 4.8. Schritt 5: Entwurf und Implementierung In diesem Schritt wollen wir die zuvor designten Activities in Code umsetzen. Bevor wir allerdings mit der Implementierung beginnen, wollen wir uns vorher noch Gedanken zum Entwurf unseres Android-Clients machen. Für unsere Webservice basierte Kommunikation mit dem Server bietet es sich hier an, eine gewisse Architektur zu verwenden. Darauf basierend werden wir anschließend ein Paket- und anschließend Code- Grundgerüst erstellen, bei dem wir zusätzlich Teile aus der Webanwendung übernehmen, um uns so Implementierungsarbeit zu ersparen Entwurf des Android-Clients Innerhalb unserer Activities werden wir vor allem mit vom Server geladenen Daten arbeiten. Dafür wollen wir unseren geeigneten Webservice verwenden. Damit das Laden und Verwenden dieser Daten dabei strukturiert vorgeht und wir innerhalb unserer Activities nicht unnötig Komplexität schaffen, wollen wir uns an folgende grundlegende Architektur (Abbildung 4.3) halten. Abbildung 4.3.: Grundlegende Architektur Dabei führen wir zusätzlich zu unseren Activities zunächst eine Webservice-Hilfsklasse ein. Über diese stoßen wir unsere Webservice-Anfragen an, die wir dann innerhalb der Hilfsklasse von Android-AsyncTasks 26 ausführen lassen werden. Zusätzlich soll sich die Webservice-Hilfsklasse um die Verwaltung der serverspezifischen URIs kümmern

49 Wurde eine Anfrage ausgeführt, so werden ggf. zurückgegebene Daten in einer auf dem Android-Client lokalen SQLite-Datenbank gespeichert. 27 Damit wir nicht über pure SQL-Anfragen mit unseren gespeicherten Daten arbeiten müssen, führen wir als zusätzliche Abstraktionsschicht sogenannte DataSource-Klassen 28 für jede unserer verwendeten Webservice-Ressourcen ein. Diese kümmern sich um die SQLite-Anfragen und sollen uns so ein komfortables Arbeiten mit den entsprechenden Model-Klassen ermöglichen Aufstellen Code-Grundgerüsts Bevor die einzelnen Activities umgesetzt werden, wollen wir als Nächstes das Code- Grundgerüst der App aufstellen. Erstellen der Paket-Grundstruktur Zunächst erstellen wir die Paket-Grundstruktur. Folgende Pakete bieten sich dabei als Basis für unsere webservicebasierte Android-App an: models net db ui util Beinhaltet die Model-Klassen des Systems. Beinhaltet netzwerkspezifische Klassen. Dazu gehört die beschriebene WebService- Hilfsklasse sowie die entsprechenden AsyncTask-Klassen für unsere Webservice-Anfragen. Beinhaltet datenbankspezifische Klassen zum lokalen Speichern und Cachen vom Server geladener Daten. Primär unsere DataSource- Klassen sowie die entsprechende SQLite-Tabellen-Klassen. Beinhaltet primär die Activity-Klassen. Beinhaltet weitere Hilfsklassen (Utility-Klassen), Enumerationen sowie statische Konstanten-Klassen. Übernehmen und Anpassen von Webanwendungs-Code Nachdem die Paketstruktur angelegt wurde, wollen wir nun einige dieser Pakete mit Klassen, die wir aus der Webanwendung übernehmen können füllen. Diese übernommenen Klassen müssen teilweise noch angepasst werden. Als Erstes können wir 27 Nach einem Ausführen der Anfrage kümmert sich die AsyncTask des Weiteren um das Anstoßen nötiger GUI-Aktualisierungen. 28 Angelehnt an 45

50 als Grundlage die Model-Klassen der Webanwendung übernehmen. Innerhalb dieser müssen wir anschließend ggf. enthaltene Play!-spezifische Methoden, Annotationen und Attribute entfernen. Hierbei handelt es sich vor allem um die datenbankspezifischen Methoden der Webanwendung, die wir in unserem Android-Client nicht benötigen. Außerdem müssen wir dafür sorgen, dass sämtliche in den jeweiligen JSON- Repräsentationen des Models (bzw. der entsprechenden Ressource) vorkommenden Attribute ebenfalls in der Android-Model-Klasse als Attribute vorhanden sind. Dazu gehört vor allem die Webservice-ID der Webservice-Ressource, sodass wir eine Referenz zu der entsprechenden Server-Ressource haben. Es findet also eine Art Angleichen von Attributen der Model-Klasse der Webanwendung und der entsprechenden JSON-Repräsentation statt. Im weiteren Verlauf der Implementierung können wir sofern notwendig ebenfalls auf die nicht Play!-spezifischen Hilfsklassen 29 sowie sämtliche Enums der Webanwendung in den Code unseres Android-Clients übernehmen. Anlegen des Activity-Grundgerüsts Als Nächstes wollen wir innerhalb des ui-paketes das Grundgerüst der Activities anlegen. Hierfür nehmen wir die in Schritt 4 erstellte Activity-Übersicht zur Hand. Durch das Aufstellen dieses Grundgerüsts können wir während der folgenden Implementierung der einzlnen Activities bereits eine Navigation zu anderen Platzhalter-Activities ermöglichen. Umsetzen der SQLite-Abstraktionsschicht Für die Umsetzung der Datenbank-Abstraktionsschicht erstellen wir als Basis für jede unserer verwendeten Ressource eine RessourceDataSource-Klasse, wobei der Teil Ressource durch den Namen der jeweiligen Ressource ersetzt wird. Innerhalb einer solchen Klasse definieren wir Methoden zum Erstellen, Aktualisieren und Löschen dieser Ressource. Dabei arbeiten die Methoden nach außen hin nur mit Model-Klassen, intern kümmern sie sich um die jeweilge SQL-Ausführung. Innerhalb unserer Activities können wir dann eine solche RessourceDataSource-Klasse instanziieren und über diese mit den in der SQLite Datenbank gespeicherten Ressourcen bzw. Models arbeiten. 29 Wobei diese nicht zwingenderweise Verwendung innerhalb unseres Android-Clients finden müssen. Ist die Implementierung fertiggestellt, sollte man also nicht vergessen noch ein Mal ein Bereinigen nicht notwendiger Methoden bzw. Hilfsklassen durchzuführen. 46

51 Umsetzen von Webservice-Anfragen Für die Umsetzung einer Webservice-Anfrage müssen wir entsprechende AsyncTask- Klassen 30 erstellen. Dabei werden dieser AsyncTask-Klasse die zu übermittelnde Daten sowie die entsprechende URI der Anfrage übergeben. Die AsnycTask-Klasse selbst führt diese Anfrage dann in einem gesonderten Thread aus, wodurch eine Blockierung unseres GUI-Threads verhindert wird. Dies ermöglicht die Umsetzung einer insgesamt flüssig laufenden netzwerkbasierten App. Sobald die Anfrage erfolgreich ausgeführt und vom Server beantwortet wurde, können in der Methode void onpostexecute(string result) einer AsyncTask entsprechende Verarbeitungen dieser Antwort vorgenommen werden. Dabei können wir uns innerhalb dieser Methode auch auf die GUI beziehen, da sie nicht mehr innerhalb eines gesonderten Threads ausgeführt wird. In unserem Fall wollen wir hier vor allem ein Aktualisieren unserer SQLite Datenbank vornehmen sowie ggf. notwendige Aktualisierungen der GUI anstoßen Vollständige Implementierung der App Es folgt die vollständige Implementierung der App anhand des erstellten Entwurfs sowie der Designprodukte aus Schritt 4. Zur Implementierung gehört also vor allem das konkrete Umsetzen der Benutzeroberfläche über die entsprechenden Android XML- Layouts, das Umsetzen der Funktionen der einzelnen Activities sowie das Umsetzen der nötigen AsyncTask- und Datenbank-Klassen. Dieser Schritt ist so gut wie vollständig vom jeweiligen Projekt bzw. der jeweiligen Webanwendung abhängig. Dennoch sollen hier nun einige Praktiken vorgestellt werden, die sich bei der Entwicklung der Distance Retros App als bewährt erwiesen haben. Feedback zu Webservice-Anfragen Beim Ausführen von Webservice-Anfragen ist besonders darauf zu achten, von uns ggf. geänderte Datensätze erst dann im Interface zu aktualisieren, wenn die entsprechende Anfrage vom Server bestätigt wurde. So verhindern wir, dass beispielsweise das Löschen eines Objekts aufgrund einer eingeschränkten Konnektivität vom Android- Client, nicht aber vom Server gelöscht wird. Um den Nutzern der App dennoch ein schnelles visuelles Feedback und damit eine erhöhte Usability zu bieten (da das System nicht träge erscheint) kann man eine entsprechende UI-Aktualisierung bereits nach Abschicken der Anfrage durchführen, um sie dann bei ggf. auftretenden Fehler inklusive einer entsprechenden Fehlermeldung wieder rückgängig zu machen. Dies ist zu bevorzugen, da wir davon ausgehen können, dass unser Client insgesamt mehr korrekt ausgeführte Anfragen abschicken wird als fehlerhafte. Letztendlich hängt dies aber vom Anwendungsfall ab

52 Dialogfenster über Fragments Arbeitet unser Android-Client mit besonders vielen Daten bzw. Ressourcen, so bietet es sich an die dazu ggf. auftretenden Dialogfenster zur Bearbeitung der Daten in gesonderte Fragment-Klassen 31 auszulagern. So wird ein Wiederverwenden dieser Dialogfenster ermöglicht. Es bietet sich zudem an, diese Dialog-Fragments aufgrund ihrer Menge in ein gesondertes ui.dialog Unterpaket auszulagern. Login und Authentifizierung Damit ein Login in unser System und auch das Abschicken authentifizierter Anfragen innerhalb unseres Android-Clients möglich ist, benötigen wir ein vom Server bereitgestelltes Sicherheitstoken, dass wir mit jeder Anfrage an den Server übermitteln. Eine Anfrage zum Erlangen eines solchen Sicherheitstokens muss dabei von unserem Webservice bereitgestellt werden. Eine solche Anfrage enthält dabei üblicherweise ein Benutzername und Passwort, mit dem anschließend auf dem Server über ein Verschlüsselungsverfahren das Token generiert und zurückgeschickt wird. Die HTTP- Header der Anfragen unseres Android-Clients werden dann von uns mit diesem Token versehen, wodurch eine Authentifizierung auf dem Server und damit Zuordnung zum entsprechend eingeloggten Benutzer ermöglicht wird. Innerhalb einer Android-App lässt sich dieses Token in den SharedPreferences 32 speichern. Diese bieten einen lokalen Schlüssel-Wert-Paar Speicherort, auf den wir nur innerhalb unserer App zugreifen können. Schicken wir nun eine Anfrage an unseren Webservice, entnehmen wir das zuvor gespeicherte Token aus unseren SharedPreferences und hängen es an den HTTP-Header (innerhalb der AsyncTask) unserer Anfrage

53 5. Distance Retros App In diesem Kapitel wird die entwickelte Distance Retros Android-App vorgestellt, aus dessen Entwicklung der zuvor vorgestellte Prozess entstanden ist. Dabei sollen unter anderem getroffene Designentscheindungen erläutert werden Entwicklung der App Die entstandene Distance Retros App wurde an das bestehende System angebunden. Eine Durchführung von plattformübergreifenden Retrospektiven ist so bereits möglich, mit der Ausnahme, dass die Erstellung von Umfragen innerhalb der App noch nicht umgesetzt wurde. 1 Entwickelt wurde die App für die Android-Version (API 15). Die Wahl dieser Version hing zum einen damit zusammen, dass so auf eine größere Auswahl an GUI- Elementen des Android Design Guides zurückgegriffen werden konnte und zum anderen um eine Umsetzung von Widget-Animationen auf dem Whiteboard zu ermöglichen, die dazu dienen sollen dem Nutzer verschobene Widgets besser verfolgen zu können. Zum Testen und Debuggen wurde die App sowohl in dem von der Android SDK bereitgestellten Emulator ausgeführt, als auch auf einem Android-Tablet-Gerät (Samsung Galaxy Tab 2). Auf den Emulator wurde dabei vor allem zu Beginn der Entwicklung zurückgegriffen, um so schnell netzwerkspezifische Tests mit dem Webservice durchführen zu können. Für das Testen der Benutzerinteraktion wurde später primär auf das Tablet-Gerät zurückgegriffen Herausforderungen und Designentscheidungen Whiteboard Eine große Herausforderung während der Entwicklung der App, stellte die Umsetzung des Whiteboards dar. Hier musste zunächst eine Möglichkeit gefunden werden die dort platzierten Widgets darzustellen, korrekt zu positionieren (übereinstimmende Positionierungen mit der Webanwendung) und automatisch zu aktualisieren. Dazu wurden zunächst mehrere Tests und verschiedene Varianten ausprobiert. Dabei hat sich herausgestellt, dass eine Variante, die ein dynamisches hinzufügen, aktualisieren und 1 Die dafür nötigen Vorkehrungen, wie beispielsweise das Plotten der Ergebnisse wurden bereits implementiert, es fehlt noch die Umsetzung des Erstellungsdialogs 49

54 5. Distance Retros App entfernen von Widget-Elementen auf dem Whiteboard ermöglicht umsetzbar ist, ohne das Android-Gerät zu überlasten. Abbildung 5.1.: Whiteboard-Ansicht Für die Umsetzung des Whiteboards musste zudem eine angepasste Benutzerinteraktion der Widgets umgesetzt werden. Innerhalb der Webanwendung ist ein Editieren, und Ändern von Eigenschaften der Widgets über die Widgets selbst möglich. D.h. auf den Widgets befinden sich entsprechende Text-Eingabefelder und Buttons. Da wir allerdings auf unserem mobilen Gerät eine geringere Bildschirmgröße haben, geht so sehr viel Platz verloren. Deshalb wurden sämtliche kontextuellen Aktionen der Widgets in die Action Bar ausgelagert (Funktionsleiste am oberen Bildschirmrand). Wählt man ein Widget über ein Klick bzw. Touch aus, so füllt sich die Action Bar automatisch mit den entsprechenden Widget-Aktionen (aus Sicht des Moderators bei einer Karte beispielse Editieren, Hervorheben und Löschen - siehe dazu Abbildung 5.2). Des Weiteren musste für jedes Widget eine Drag and Drop Funktionalität gewährleistet werden. Damit es dabei nicht zu Konflikten mit der Auswahl eines Widgets kommt (zum Aktivieren der kontextuellen Aktionen), wurde für die Aktivierung der Drag and Drop ein längerer Touch verwendet. Die so entstandene Interaktion mit den Widgets hat sich als äußerst angenehm herausgestellt und macht das Arbeiten mit dem Whiteboard dadurch noch natürlicher (im Vergleich zum Einsatz der Maus innerhalb der Webanwendung). 50

55 5. Distance Retros App Abbildung 5.2.: Angebotene Aktionen einer Karte aus Sicht des Moderators Navigation Die nicht-funktionalen Anforderungen der App forderten eine schnelle Navigation innerhalb der App. Um eine solche schnelle Navigation zwischen den einzelnen Activities zu ermöglichen, wurde ein vom Android Design Guide für einen solchen Anwendungszweck vorgeschlagene Navigation Drawer 2 implementiert (siehe Abbildung 5.3). Dabei handelt es sich um eine Navigationsleiste, die vom linken Bildschirmrand ausgefahren werden kann. Dies kann entweder über einen Wisch über den Bildschirmrand geschehen, oder über ein Touch auf den Navigationsbutton am oberen linken Bildschirmrand. Die so umgesetzte Navigation ermöglicht es jederzeit von der aktuellen Activitiy zu einer anderen gewünschten Activity zu springen. Unter Verwendung des Android-Zurück-Buttons kann man so ebenfalls zur vorherigen Activity zurückspringen, d.h. ein schnelles Überprüfen der eigenen Action Items und anschließendes Zurückkehren zur vorherigen Retrospektive ist damit auch möglich. Neue View: Action Items Auf Abbildung 5.4 ist die neu hinzugekommene Sicht Action Items zu sehen. Hier hat der Moderator die Möglichkeit die vorhanden Action Items zu verwalten. Befindet sich ein Moderator innerhalb einer Retrospektive, so kann er zwischen dieser Action Items Sicht und dem Whiteboard der entsprechenden Retrospektive wechseln. Das Wechseln der Sichten geschieht dabei über einen Spinner 3. Dabei handelt es sich um ein Dropdown-Menü. Der Android Style Guide empfiehlt diese Art von Sichten-Navigation dann einzusetzen, wenn man für ein gleichbleibendes Datenset verschiedene Sichten anbieten möchte (beispielsweise ein Kalender mit den Sichten Tages-, Wochen- und Monatsansicht). In diesem Fall ist das Datenset die Retrospektive mit den zwei Sichten Action Items und Whiteboard

56 5. Distance Retros App Abbildung 5.3.: Retrospektiven-Übersicht mit ausgefahrener Navigationsleiste Abbildung 5.4.: Moderatoren-Sicht zum Verwalten von Action Items 52

57 6. Fazit und Ausblick In diesem Kapitel wird ein allgemeiner Rückblick auf die in der Arbeit behandelten Inhalte geworfen. Des Weiteren werden die Ergebnisse der Arbeit kritisch reflektiert. Anschließend folgt ein Ausblick auf Verbesserungs- und Erweiterungsmöglichkeiten, sowohl auf den Prozess, als auch die Distance Retros App bezogen Fazit Im Rahmen dieser Arbeit wurde die bestehende Webanwendung Distance Retros um eine Android-App erweitert. Die dabei entstandene App wurde an das bestehende System angebunden. Zuvor musste dazu die Webanwendung dafür angepasst werden. Bei der Entwicklung der App wurde darauf geachtet, die Benutzerinteraktion und vor allem die Benutzeroberflächen dem Kontext der mobilen Anwendung gerecht anzupassen. Aus den gesammelten Erkenntnissen dieses Erweiterungsvorgehens sowie zusätzlicher Überlegungen, wie ein Übertrag auf andere Webanwendungen aussehen könnte, wurde ein allgemeiner Prozess abgeleitet, der eine Erweiterung von Webanwendungen um Android-Apps ermöglichen soll. Dabei wurde auf vorhandene Strukturen der Webanwendung zurückgegriffen, um den Erweiterungsprozess möglichst strukturiert und aufwandsreduzierend zu gestalten. Es konnte ermittelt werden, dass die API der vorliegenden Webanwendung dabei eine zentrale Rolle spielen kann und eine wichtige Informationsquelle für die Erweiterung bzw. Entwicklung der App darstellt. Obwohl während der Ableitung und Optimierung des Prozesses bereits darauf geachtet wurde, mögliche Eigenschaften anderer Webanwendungen zu berücksichtigen, kann der gesamte Prozess dennoch keineswegs als reif bezeichnet werden. Dazu fehlt vor allem eine nötige Evaluation. Es müsste also eine Reihe von weiteren Erweiterungen mithilfe des vorgestellten Prozesses durchgeführt werden, sodass ggf. vorliegende Probleme oder Lücken aufgedeckt und angepasst bzw. optimiert werden können. Ein außerdem wichtiger, innerhalb des Prozesses nicht behandelter Aspekt ist das Testen und Validieren der entwickelten App selbst. Dazu müssten notwendige Prozessschritte eingeführt werden, welche die Entwicklung einer qualitativ messbaren App gewährleisten können. 53

58 6. Fazit und Ausblick 6.2. Ausblick Zur Evaluation des Prozesses wäre es sinnvoll, diesen auf andere bestehende Webanwendungen anzuwenden, um, wie im Fazit bereits erwähnt wurde, mögliche Problemquellen des Prozesses aufzudecken. Als erste Anlaufquelle für weitere Prozess- Durchführungen könnte man dabei auf Webanwendungen aus Open Source Projekten zurückgreifen, da so ein Blick in den Code dieser Anwendungen möglich ist. Bei der Ergänzung des Prozesses um einen Validierungsschritt, wäre es interessant zu untersuchen, inwiefern man eine Validierung durchführen könnte, die sich die bestehende Webanwendung zu Hilfe nimmt. Zumindest für den Teil der aus der Webanwendung übernommenen Funktionen der App ließe sich hier vielleicht sogar eine systematische Validierung herleiten, da man davon ausgehen kann, dass die aus der Webanwendung übernommenen Funktionen mit einem Teil der gewünschten Funktionen der Android App identisch sind und mit den Vorstellungen des Kunden übereinstimmen. Des Weiteren wäre es interessant zu überprüfen, inwiefern der Ansatz des Prozesses auf andere mobile Betriebssysteme wie beispielsweise ios oder Windows Phone übertragen ließe, und welche Anpassungen nötig wären, um das Erweiterungsvorgehen auch für diese Betriebssysteme anwenden zu können. Hierzu müssten vor allem die Schritte 4 (Benutzeroberflächen- und Interaktionsdesign) und 5 (Entwurf und Implementierung) angepasst werden. Der folgende Abschnitt bezieht sich auf Verbesserungs- bzw. Erweiterungsmöglichkeiten der Distance Retros App. Ein grundlegendes Problem von verteilten Retrospektiven ist die eingeschränkte verbale Kommunikation bzw. das Einhalten einer geordneten Sprechreihenfolge. Wie von [Eck10] genannt, wird bei Telefon-Retrospektiven beispielsweise im Voraus eine solche Sprechreihenfolge festgelegt. Dies kann zu einer zähen Diskussion führen. Des Weiteren wird genannt, dass es üblich bei solchen Retrospektiven ist, dass Teilnehmer bevor sie etwas sagen ihren Namen nennen, sodass alle Zuhörer wissen, wer jetzt spricht. Eine grundlegende Ergänzung der App, die dabei helfen könnte dieses Problem zu reduzieren wäre das Einführen einer Art Sprech-Warteschlange, die vom Moderator verwaltet wird. So könnten Teilnehmer beispielsweise über einen Button ihren Sprechwunsch abgeben, worauf beim Moderator ein entsprechender Hinweis erscheint. Der Moderator hat dabei eine Übersicht über alle abgegebenen Sprechwünsche und könnte so die Sprechreihenfolge im Voraus dynamisch festlegen. Wird der Sprechwunsch einer Person genehmigt, so erscheint bei allen Teilnehmern eine Meldung darüber wer jetzt spricht. Über die Verwendung einer solchen Warteschlange könnten sich zudem Teilnehmer die als Nächstes dran sind bereits darauf vorbereiten. Dies könnte insgesamt zu einer flüssigeren Kommunikation und damit erfolgreicheren verteilten Retrospektive führen. Eine Umsetzung innerhalb der Distance Retros App könnte dabei beispielsweise über eine am rechten Bildschirmrand platzierte Seitenleiste erfolgen. Der Moderator könnte darüber eine solche Warteschlange verwalten. 54

59 6. Fazit und Ausblick Um das Abhandeln von Retrospektiven noch flexibler gestalten zu können, wäre es zudem denkbar die App um eine Funktion zum Verfassen handschriftlicher Karten auf dem Whiteboard zu ergänzen. Dadurch würde das Abhandeln von diesen virtuellen, verteilten Retrospektiven dem realen Durchführen einer Retrospektive näher kommen. Teilnehmer der Retrospektive hätte so die Möglichkeit, trotz der Distanz sich und ihre Gedanken besser auszudrücken. Dazu müsste die Funktionalität der Webanwendung allerdings ebenfalls angepasst werden, so dass in der App handschriftlich verfasste Karten auch innerhalb der Webanwendung dargestellt werden können. Das Überprüfen der eigenen, zugewiesenen Action Items stellt innerhalb der Android- App einen wichtigen Use-Case dar. Um eine noch schnellere Überprüfung der Action Items zu ermöglichen, wäre es sinnvoll die App um ein sogenanntes Android Widget zu ergänzen. Dieses Widget ließe sich auf dem Homescreen des jeweilgen Android- Geräts platzieren und würde so eine sehr schnelle Möglichkeit bieten vorhandene Action Items zu überprüfen, da die App selbst dadurch nicht geöffnet werden muss. 55

60 56

61 A. Benutzeroberflächenstruktur der Distance Retros Webanwendung A. Benutzeroberflächenstruktur der Distance Retros Webanwendung 57

62 58

63 B. Dokumentation: Distance Retros Webanwendung API B. Dokumentation: Distance Retros Webanwendung API 59

64 B. Dokumentation: Distance Retros Webanwendung API 60

65 B. Dokumentation: Distance Retros Webanwendung API 61

66 62

67 C. Dokumentation: Ressourcenorientierter Webservice C. Dokumentation: Ressourcenorientierter Webservice 63

68 C. Dokumentation: Ressourcenorientierter Webservice 64

69 C. Dokumentation: Ressourcenorientierter Webservice 65

70 D. Funktionale Anforderungen Nr. Aus Anfrage Anforderungsbeschreibung R1 N1 Retrospektiven-Inhalte (Widgets) können aktualisiert werden R2 N2 Es gibt eine Übersicht über alle Retrospektiven R3 N3 Retrospektiven können betreten werden R4 N4 Retrospektiven können angelegt werden R5 N12 Moderatoren können Umfragen anlegen R6 N13 Umfragen bieten Abstimmmöglichkeit R7 N13A Moderatoren können Umfragen verschieben R8 N16 Modetoren können Umfragen löschen R9 N18 Karten können angelegt werden R10 N19 Moderatoren können Karten editieren R11 N20 Moderatoren können Karten löschen R12 N22 Moderatoren können Karten hervorheben R13 N24 Karten können verschoben werden R14 N25 Karten können veröffentlicht werden R15 N26 Karten können positiv geliket werden R16 N28 Moderatoren können Label anlegen R17 N29 Moderatoren können Label editieren R18 N29 Moderatoren können Label verschieben R19 N30 Moderatoren können Label löschen R20 N32 Moderatoren können Action Items anlegen R21 N33 Moderatoren können Action Items editieren R22 N33A Moderatoren können Action Items verschieben R23 N34 Moderatoren können Action Items löschen R24 N35 Moderatoren können sich importierbare Action Items anzeigen lassen R25 N37 Moderatoren können Action Items importieren 66

71 E. Screenshots: Distance Retros Prototyp Abbildung E.1.: Retrospektiven-Übersicht Abbildung E.2.: Whiteboard-Ansicht 67