Adventure Cloud Semesterarbeit - HSR Hochschule für Technik Rapperswil Abteilung für Informatik - Institutional Repository
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Semesterarbeit
Adventure Cloud
HSR Hochschule für Technik Rapperswil
Abteilung für Informatik
Herbstsemester 2019
Autor Sharon Moll
Betreuer Stefan Keller
Term Project
Adventure Cloud
University of Applied Science Rapperswil
Department of Computer Science
Fall Term 2019
Author Sharon Moll
Advisor Stefan Keller
Diese Arbeit wurde von Sharon Moll im Herbstsemester 2019
des Bachelorstudiums an der HSR erarbeitet.
Als Editor wurde der LaTeX-Editor «Overleaf» mit den Schrift-
arten «pifont», «mathpazo» und «csquotes» verwendet.
AC i
Abstract Unternehmen, die Freizeitaktivitäten anbieten, stellen ihren Kunden vermehrt GoPro-Kameras zu Verfü- gung, womit die Spass- und Abenteuererlebnisse digital mit Fotos und Videos festgehalten werden kön- nen. Auch Fotografen, welche sich im digitalen Zeitalter bewegen, möchten ihren Kunden ihre Medien digital zu Verfügung stellen. Im Markt gibt es bisher keine Lösung, welche diese Prozesse automatisiert. Die Adventure Cloud stellt eine Plattform zu Verfügung, welche diesen Anforderungen gerecht wird. Als demonstrativer Anwendungsfall wird die Skydive-Szene verwendet. Kunden können sich bei einer Skydive-Base für einen Tandemsprung anmelden. Der Sprung wird dabei mit GoPro-Kameras in Form eines Videos und Fotos festgehalten. Diese Medien können danach von den Kunden erworben werden. Dieser Prozess ist heute noch stark manuell geprägt. Die Tandemspringer übertragen die Medien nach dem Sprung zurück am Boden von den GoPro-Kameras auf einen Computer und von da werden sie auf einen USB-Stick kopiert, welcher dem Kunde verkauft wird. Um diesen Prozess zu automatisieren wurde zum einen eine Mobile App entwickelt, welche auf einem Tablet in der Skydive-Base läuft und zum anderen eine cloudbasierte Backend-Applikation. Die Tandem- springer fügen ihre GoPro-Kameras im Mobile App hinzu, wofür ein Pairing mit WLAN entwickelt wurde, das die GoPro-Kameras erkennt und im System hinterlegt. Der Tandemspringer fotografiert dann mit seiner GoPro-Kamera vor einem Tandemsprung das Anmel- deformular des Kunden, worauf sich ein QR-Code befindet, der eine eindeutige Kundenummer enthält. Nach dem Sprung und dessen Aufnahme startet er über einen einzelnen Klick in der Mobile App die Synchronisation der GoPro-Kamera, worauf sich das Tablet mit dieser über WLAN auf dessen Hotspot- Netzwerk verbindet und die Medien von dieser herunterlädt. Das Mobile App erkennt danach die abfotografierten QR-Codes über einen Fotoscan mit Hilfe der Zxing- Library und gruppiert die chronologisch nachfolgenden Medien in ein Album. Eine GoPro-Kamera kann vor der Synchronisation auch Medien von mehreren Kunden speichern, die jeweils chronologisch sortiert durch ein Foto mit QR-Code getrennt sind. Dies resultiert in mehreren Alben. Die erzeugten Alben werden danach von der Mobile App in die cloudbasierte Backend-Applikation hochgeladen. Nach rund 240 Arbeitsstunden konnte ein voll funktionsfähiges und stabiles Mobile App inklusive der Backend-Applikation entwickelt werden, welches auch grafisch durch die Verwendung des Google Mate- rial Designs glänzt. AC ii
Management Summary
Ausgangslage
In der Schweiz gibt es etwa zehn grosse Skydive Vereine, die Tandemsprünge anbieten. Der
Grösste von ihnen befindet sich in Interlaken. Etwa einen Viertel der Einnahmen bei Tandemsprün-
gen erzielen die Vereine durch den Verkauf der Photos und Videos, welche die Springer während
dem Flug aufnehmen und anschliessend den Kunden verkaufen.
Nach einem Tandemsprung – zurück am Boden in der Base – werden die Medien von der Ka-
mera, wobei es sich dabei häufig um GoPro-Modelle handelt, manuell auf einen Computer über-
tragen und von dort auf einen USB Stick. Danach können die USB Sticks mit den gespeicherten
Medien von den Kunden erworben werden.
Dieser, aus technischer Perspektive, eher konservative Ansatz bringt einige Nachteile mit sich,
welche mit adäquaten technischen Massnahmen reduziert werden können:
• Der Prozess der Medienübertragung nimmt relativ viel Zeit in Anspruch.
• Mindestens eine Person muss in der Base ständig für diesen Prozess bereitstehen.
• Medien können nicht mehr erworben werden, nach dem der Kunde den Standort verlässt.
Umsatzmöglichkeiten gehen verloren.
• Ein korruptes Dateisystem kann auf einem USB Stick relativ schnell entstehen, wenn dieser
beispielsweise unordnungsgemäss entfernt wird. Kundenunzufriedenheit ist die Konse-
quenz davon.
Nicht nur in der exemplarisch verwendeten Skydive Branche lässt sich der Use Case der Medi-
enaufnahme und deren Verkauf finden. Auch Fotografen, Kameras bei Konzerten oder in touris-
tischen Bergregionen sind von manuellen Verkaufprozessen geprägt.
Lediglich eine handvoll Unternehmen widmen sich der Automatisierung und Effizienzsteige-
rung dieser Prozesse. Bestehende Lösungen sind technologisch eingeschränkt und erfordern
dedizierte Hardware und können daher lediglich von spezifischen Kundengruppen eingesetzt
werden.
Ziele, Vorgehen und Technologien
Das finale Ziel dieses Projekts ist es, eine cloudbasierte Webplattform zu entwickeln, welche es
potenziellen Kunden ermöglicht, ihre Medien - beispielsweise von einem Skydive Tandemsprung
- als Preview anzuschauen und anschliessend automatisiert zu erwerben.
Im Kontext der Semesterarbeit Adventure Cloud wird ein App entwickelt, das auf einem Tablet
in der Base läuft, sich mit den GoPro-Kameras der Tandemspringer verbindet, wenn diese am
Boden ankommen, die Medien von diesen herunterlädt und in die Cloud überträgt.
Eine Evaluierung und empirische Analyse der Übertragungsgeschwindigkeit und Verlässlichkeit,
sowie die Frage, ob WLAN oder Bluetooth sich besser für die Übertragung von Medien zwischen
GoPro-Kameras und Tablet eignet, sind ebenso Teil dieser Semesterarbeit.
Während 11 Wochen und insgesamt 240 Arbeitsstunden wurde das Projekt mit einer Vorge-
hensweise, die dem Agile Unified Process angelehnt ist, in einem agilen und iterativen Ansatz
umgesetzt.
Zu Beginn wurde eine Analyse der GoPro-Schnittstellen vorgenommen. Die resultierenden Er-
kenntnisse wurden zur Ansteuerung der GoPro-Kamera genutzt, womit eine empirische Evalua-
tion der Übertragungsgeschwindigkeit und deren Verlässlichkeit erarbeitet werden konnte.
AC iiiAnschliessend wurde mit der Entwicklung des Mobile Apps fortgefahren. Bei diesem handelt es sich um ein hybrides Web App, das mit Hilfe von Cordova auf native Funktionalitäten der Ziel- plattform Android zugreift und für diese erstellt wird. Die eingesetzte Technologie ist Javascript mit VueJS (MVVM) und dem UI-Framework Quasar. Die Cordova-Plugins, die Zugriff auf native Funktionalitäten ermöglichen, wurden in Java entwickelt. Nachfolgend wurde die cloudbasierte Backend-Applikation, beziehungsweise deren REST API- Schnittstelle, in der Sprache C mit dem .NET Core MVC Framework umgesetzt. Da es im Verlauf des Projekts nicht zu starken und unüberwindbaren Hindernissen gekommen ist, konnte der gesamte geplante Funktionsumfang implementiert werden. Ergebnisse Mit der Semesterarbeit «Adventure Cloud» wurde ein Mobile App, sowie eine Backend-Applikation entwickelt, die es erlaubt, automatisiert die Medien von GoPro-Kameras abzugreifen, diese an- hand von einer QR-Scanning Logik zu gruppieren und anschliessend in die Backend-Applikation hochzuladen. Das Mobile App umfasst eine Authentifizierung bei der Backend-Applikation über die Verwen- dung von JSON Web Token, das Pairing von GoPro-Kameras und die Synchronisation mit diesen. Für das Verbinden der Mobile App mit einer GoPro-Kamera über WLAN, dem Herunterladen der Medien von GoPro-Kameras und dem QR-Code Scanning wurden eigene Cordova-Plugins in Java entwickelt oder erweitert. Das finale Mobile App glänzt durch die Anwendung des Material Design, fängt jegliche Fehler bei der Synchronisation mit einer GoPro-Kamera und dem Hochladen der Medien in die Cloud ab und läuft stabil auf dem Android Betriebssystem. Da das Mobile App als hybrides Web-App entwickelt wurde, kann es auch für andere Zielplattformen gebuildet werden. AC iv
Abbildung 1: Entwickeltes Mobile App Ausblick Die Entwicklungen in dieser Semesterarbeit sind in einem stabilen Gesamtsystem resultiert, was zeigt, dass das Projekt in Zukunft in einem praktischen Anwendungsfall eingesetzt werden kann. Mit weiteren Entwicklungen, zum Beispiel in Form einer Bachelorarbeit, kann das Projekt finalisiert- und ökonomisch interessant werden. Dazu muss eine Webplattform entwickelt werden, wo sich Kunden von Unternehmenspartnern ihre Medien als Preview anschauen und erwerben können. AC v
Danksagungen
Ich danke folgenden Personen für Ihre Unterstützung während meiner Semesterarbeit:
• Stefan Keller
• Christian Spielmann
• Jasmin Hürlimann
• Julian Klaiber
• Severin Dellsperger
Ich danke Professor Stefan Keller für die gute und konstruktive Unterstützung während meiner
Semesterarbeit ganz herzlich.
Ebenso möchte ich Christian Spielman für die Bereitstellung der benötigten Hardware danken.
Besten Dank geht auch an Jasmin Hürlimann, Julian Klaiber und Severin Dellsperger, die meine
Arbeit gegengelesen haben.
AC viInhaltsverzeichnis
I Technischer Bericht 1
1 Technischer Bericht 2
1.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.4 Rahmenbedingungen, Umfeld, Definitionen . . . . . . . . . . . . . . . . . . . 4
1.1.5 Ökonomischer Sachverhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.6 Vorgehen und Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Aktuelle Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Lösungsansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Datensicherheit und Datenschutz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Rechtliche Lage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Datenschutz in der Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Herausgabe von Daten in Zwischenfällen . . . . . . . . . . . . . . . . . . . . . 7
2 Resultate 8
2.1 Zielerreichung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Analyse der Übertragungsgeschwindigkeit und deren Verlässlichkeit . . . . 8
2.1.2 Mobile App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Backend-Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Schlussfolgerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Bewertung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
II Projektdokumentation 16
3 Anforderungsspezifikation 17
3.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 Akteure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.2 Use-Case-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.3 Use-Case-Beschreibungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
AC viiInhaltsverzeichnis
3.2.1 Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 Benutzbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.3 Zuverlässigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.4 Effizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.5 Änderbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.6 Übertragbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.7 Skalierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Domainanalyse 24
4.1 Domänenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Administrative Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 MediaSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3 MediaItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.4 PictureItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.5 VideoItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Architektur und Design Spezifikationen 26
5.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Y-Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Systemübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.1 Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.2 Database-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.3 Mobile-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.4 Web-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.5 GoPro-Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4 Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5 REST API-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.6 Sequenzdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.6.1 GoPro-Kamera(s) synchronisieren . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.6.2 Medienset unterteilen mit QR-Code Analyse . . . . . . . . . . . . . . . . . . . 31
5.6.3 Medienupload in die Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.6.4 Medienset erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.7 Logische Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.7.1 Client-Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.7.2 Server-Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.7.3 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.8 Packages und Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.8.1 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.8.2 Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.9 Design Android-App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6 Umsetzung und Implementation 45
6.1 Analyse der Übertragungsgeschwindigkeit und deren Verlässlichkeit . . . . . . . . 45
6.2 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.1 Authentifizierung und Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.2 REST API-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.3 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.3 Android-App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.3.1 Mediendownload von GoPro-Kamera . . . . . . . . . . . . . . . . . . . . . . . 47
6.3.2 Gruppierung der Medien mit QR-Code-Scanning . . . . . . . . . . . . . . . . 50
6.3.3 Medienupload in das Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
AC viiiInhaltsverzeichnis
6.3.4 Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.5 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7 Projektmanagement 52
7.1 Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.2 Projektmanagementsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.2.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.2.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.3 Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.3.1 Iterationsplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.3.2 Schätzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.3.3 Zeitauswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.4 Meilensteine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.5 Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.6 Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.6.1 Repository «Adventure Cloud Documentation» . . . . . . . . . . . . . . . . . 55
7.6.2 Repository «Adventure Cloud Android Client» . . . . . . . . . . . . . . . . . 56
7.6.3 Repository «Adventure Cloud Backend» . . . . . . . . . . . . . . . . . . . . . 56
7.7 Entwicklungskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.7.1 Qualitätsmassnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.7.2 Definition of Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.7.3 Code Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.8 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.9 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.9.1 Automatisiertes Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.9.2 Manuelles Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.10 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.11 Code-Metriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.12 Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.12.1 Umgang mit Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.12.2 Konsequenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Glossar und Abkürzungsverzeichnis 62
Abbildungsverzeichnis 65
Tabellenverzeichnis 67
Literaturverzeichnis 68
III Anhang 69
A Aufgabenstellung 70
B Testprotokolle 71
B.1 Systemtests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.2 Usability Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
C Metriken 73
C.1 Backend-Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.2 Mobile App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
AC ixInhaltsverzeichnis D Benutzerhandbuch 76 D.1 Installationsanleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 E Persönliche Reflektion 77 F Zeitauswertung 78 F.1 Zeitauswertung nach Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 F.2 Zeitauswertung nach Teammitgliedern . . . . . . . . . . . . . . . . . . . . . . . . . . 79 F.3 Zeitauswertung Soll-Ist-Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 AC x
Inhaltsverzeichnis
Teil I
Technischer Bericht
AC 1Kapitel 1
Technischer Bericht
1.1 Einführung
1.1.1 Problemstellung
Viele Anbieter von Freizeitaktivitäten nutzen etablierte Kamera-Hersteller für die Aufnahme von
Fotos und Videos ihrer Kunden. Besonders beliebt sind die hochauflösenden und preiswerten
GoPro-Kameras vom amerikanischen Hersteller aus Kalifornien.
Der Verkaufsprozess der Medien an Kunden ist manuell gestaltet. Die Mitarbeiter übertragen die
Medien von Hand von den Kameras auf USB-Sticks, welche die Kunden anschliessend erwerben
können.
Leider existieren für die GoPro-Kameras nahezu keine Softwarelösungen von Drittanbietern,
welche diesen Prozess automatisieren könnten. Dies ist darauf zurückzuführen, dass das GoPro-
Unternehmen ihr ökonomischen System vor wenigen Jahres vor externem Zugriff geschlossen
hat. Schnittstellen werden offiziell keine mehr angeboten und die offizielle GoPro-App für An-
droid und IOS verbleibt somit die einzige nutzbare kabellose Lösung für die Kommunikation
und den Medienaustausch zwischen GoPro-Kamera und Computer.
1.1.2 Vision
Die Adventure Cloud Lösung bietet Unternehmen die Möglichkeit, digitale Medien automati-
siert von GoPro-Kameras in die Cloud hochzuladen, wobei ihre Kunden diese anschliessend als
Vorschau auf einer webbasierten Plattform anschauen und automatisiert erwerben können. Das
Unternehmen tritt eine Provision pro Kauf an die Betreiber der Adventure Cloud ab, was den
primären wirtschaftlichen Business Case des Projekts darstellt.
Ferner in der Zukunft soll die Webplattform Adventure Cloud auch von anderen Quellen ge-
spiesen werden. Beispielsweise können stationäre Kameras in Skigebieten die Schnittstelle der
Adventure Cloud ansteuern, um ihre Medien auf diese hochzuladen und den Kunden zum Kauf
anzubieten. Es lassen sich eine Vielzahl plausibler weiterer Anwendungsmöglichkeiten erahnen.
1.1.3 Ziele
Nachfolgend sind die Ziele dieser Semesterarbeit definiert. Es wird aufgezeigt, was Teil der
Arbeit ist und wo Abgrenzungen gezogen werden.
Nachfolgend ist der Teilprozess des Customer Journey abgebildet, welcher durch die Semester-
arbeit abgedeckt und umgesetzt werden soll. Anschliessend folgen detaillierte Erläuterungen.
AC 21.1. EINFÜHRUNG
Abbildung 1.1: Ziel der Semesterarbeit
Android App und cloudbasierte Webplattform
Diese Semesterarbeit widmet sich der Entwicklung einer Mobile App, die auf einem Tablet läuft,
sich mit GoPro-Kameras verbindet und die Medien von diesen automatisiert herunter- und in
eine cloudbasierte Lösung hochlädt.
Die cloudbasierte Webplattform, auf welcher potentielle Kunden ihre Medien anschauen und
erwerben können, ist im Umfang dieser Arbeit sekundär und wird daher bei genügend Zeit
lediglich als rudimentärer Prototyp umgesetzt. Im Vordergrund steht das Mobile App, welches
die Medien von GoPro-Kameras abgreift und in die Cloud hochlädt. Dieses Mobile App wird
abgerundet mit komfortablen Funktionen, wie der Erkennung von QR-Codes in Fotos, welche
dazu dienen, eine Menge von Medien einem bestimmten Kunden zuzuordnen.
Dies impliziert ebenso, dass es keine Evaluation und Wahl eines Cloud-Providers, Deployment
zu einem Cloud-Provider und Aufsetzung der Cloud gibt. Die Projektdokumentation wird stel-
lenweise jedoch das visionierte Gesamtsystem enthalten und abbilden, da dies für die längerfris-
tige Planung notwendig ist und bei Weiterführung des Projekts - beispielsweise in Form einer
Bachelorarbeit - relevant ist.
Analyse der Übertragung und deren Verlässlichkeit
Eine Evaluierung und empirische Analyse der Übertragungsgeschwindigkeit und Verlässlichkeit
der Medienübertragung zwischen einer GoPro-Kamera und einem Android Gerät wird erarbei-
tet, um herauszufinden, wie und in welchem Ausmass die resultierende Lösung in der Praxis
verwendet werden kann.
Automatische Gruppierung von Mediensets und Zuordnung an Kunden
Die Medien einer GoPro-Kamera sollen automatisiert in Mediensets aufgeteilt werden, wobei
ein Medienset jeweils die Medien eines Kunden enthält und diesem zugeordnet wird. Dies wird
erreicht, indem vor der Aufnahme eines Mediensets ein QR-Code fotografiert wird, welcher die
Information zur Kundenzuordnung enthält (eindeutige Kundennummer). Nach dem Herunter-
laden aller Medien von einer GoPro-Kamera erkennt die Android App die Fotos, welche die
QR-Codes enthalten und nimmt so eine Aufteilung in kundenspezifische Mediensets vor. Durch
visuelle Erkennung der QR-Codes werden diese Mediensets dann bestimmten Kunden zugeord-
net.
AC 31.1. EINFÜHRUNG
1.1.4 Rahmenbedingungen, Umfeld, Definitionen
Für die Umsetzung werden verschiedene Technologien eingesetzt, die der Zeit gerecht werden
und sich für die Anwendungsfälle gut eignen. Das App wird für die Android Plattform konzi-
piert und in Java und mit Web-Technologien umgesetzt. Für das Backend wird .NET kombiniert
mit PostgreSQL und anderen Datenbanksystemen eingesetzt.
In Zukunft sollen Videos, welche in die Adventure Cloud hochgeladen werden, mit Hilfe vom
AWS MediaConvert-Service in leichtere Vorschauvideos umgewandelt werden, um die Benut-
zerfreundlichkeit auf der Webplattform zu erhöhen.
1.1.5 Ökonomischer Sachverhalt
Da die Motivation dieser Semesterarbeit darin besteht, die resultierende Lösung für den prakti-
schen Einsatz in der Privatwirtschaft zu konzipieren, ist eine ökonomische Darlegung der Um-
satzmöglichkeiten und Kosten von Interesse. Diese Arbeit beschränkt sich dabei auf folgende
Berechnungen:
Umsatz- und Kostenberechnung
Variablen Schätzwert Kostenpunkte Kosten/Jahr
Provision für Adventure Cloud 5% Cloud Hosting CHF 400
Anzahl Skydive Basen 4 Videokonvertierung CHF 1100
Anzahl Tandemsprünge/Base/Jahr 900 Domaingebühren CHF 30
Kundenkonversationsrate 60% Cloud Storage CHF 640
Ø Preis/Sprung CHF 100
Kosten/Videokonvertierung/Minute CHF 0.03
Ø Videolänge 10 Min
Ø Speicherzeit/Video 4 Monate
Ø Grösse/Video 2 GB
AWS Cloud Storage Kosten/GB/Monat CHF 0.025
Umsatz/Jahr CHF 10800
Gesamtkosten/Jahr CHF 2170
Gewinn/Jahr CHF 8630
Tabelle 1.2: Umsatz- und Kostenberechnung
Eine kommerzielle Anwendung hat, wie man aus vorgängiger Tabelle entnehmen kann, durchaus
positiven Ausblick. Die Schätzwerte wurden konservativ und eher pessimistisch gewählt, um
realistische Kennzahlen zu erhalten.
1.1.6 Vorgehen und Aufbau der Arbeit
Diese Semesterarbeit setzt sich aus zwei voneinander abhängigen Teilen zusammen. Der erste
Teil ist von experimenteller Natur und befasst sich mit der empirischen Analyse der Geschwin-
digkeit und Verlässlichkeit der Medienübertragung zwischen GoPro-Kamera und Android Tablet
über WLAN.
AC 41.2. STAND DER TECHNIK
Der zweite Teil nutzt die Erkenntnisse des ersten Teils, um die konkrete Umsetzung fertig zu
planen und zu realisieren.
1.2 Stand der Technik
1.2.1 Aktuelle Situation
Anschliessend folgt eine kurze Beschreibung, wie die heutigen relevanten Prozesse von potenti-
ellen zukünftigen Kunden gestaltet sind und wie diese optimiert werden sollen. Zusätzlich folgt
eine kurze Erläuterung zur aktuellen Marktsituation und existierenden Lösungen, welche dem
Projekt Adventure Cloud ähnlich sind.
Heutige Prozesse
Anbieter von Freizeitaktivitäten nutzen mehrheitlich GoPro-Kameras, um ihren Kunden perso-
nenbezogene Fotos und Videos zum Kauf anbieten zu können. Als konkretes Beispiel dient hier
wiederum ein Skydive Verein, der Tandemsprünge anbietet. Die Mitarbeiter nehmen während
dem Flug Fotos und Videos ihrer Kunden - dem Tandem - auf. Kommen sie am Boden an, laden
die Mitarbeiter diese Medien auf USB-Sticks, welche anschliessend von den Kunden erworben
werden können.
Es muss also ständig eine Person am Boden sein, die den erläuterten Prozess abwickelt. Noch
mühsamer ist jedoch die Wartezeit für die Kunden, da der Kopiervorgang auf die USB-Sticks
oftmals bis zu einer halben Stunde dauert. Grund dafür ist enorme Dateigrösse der Fotos und
Videos aufgrund der hohen Auflösung.
1.2.2 Lösungsansätze
Die manuellen Prozesse sollen digital automatisiert werden. Kunden sollen zukünftig die Mög-
lichkeit haben, ihre Medien online auf einer Web-Plattform anschauen und erwerben zu können.
Die Automation soll mit Hilfe eines Android-Geräts erfolgen, welches sich mit den GoPro-
Kameras verbindet und anschliessend die Medien von diesen herunter- und in die Cloud hoch-
lädt. Die Cloud ist dabei eine Applikation, welche die Medien entgegennimmt, verarbeitet und
über eine webbasierte Plattform den Kunden anbietet.
Der Automation-Prozess beinhaltet diverse Schritte, auf welche nachfolgend detailliert und in
zeitlich geordneter Reihenfolge eingegangen wird.
#1 Zuordnung der Medien an Kunden
Es soll möglich sein, mit einer GoPro-Kamera sequentiell Medien von verschiedenen Kunden
aufzunehmen, ohne, dass zwischendurch eine Synchronisation mit der Cloud vorgenommen
werden muss. Aktuell wird für die Zuordnung der Medien zu den unterschiedlichen Kunden
und das Erstellen von Sets folgende Strategie verwendet:
• Optische QR-Code Erkennung: Bevor Medien eines Kunden aufgenommen werden, wird
ein kundenspezifischer QR-Code fotografiert, der eine einzigartige Kundenidentifikation
enthält. Das Android-App wird in einem späteren Schritt alle Medien chronologisch nach
QR-Codes durchsuchen und die Medien jeweils der letzten erkannten Kundenidentifikation
zuordnen.
#2: Medien-Download von GoPro-Kameras
Sobald die Medien von einer GoPro-Kamera in die Cloud hochgeladen werden sollen (Syn-
chronisation), muss sich das Android-Gerät zuerst mit der GoPro-Kamera verbinden. Dies kann
AC 51.3. DATENSICHERHEIT UND DATENSCHUTZ entweder über WLAN oder Bluetooth geschehen. Sobald die Verbindung aufgebaut wurde, lädt das Android-Gerät die Medien von der GoPro-Kamera in den lokalen Speicher herunter. Dafür nutzt es die inoffiziellen HTTP REST API-Schnittstellen, die von der GoPro-Kamera angeboten werden. Der Mediendownload muss danach auf Korrektheit überprüft werden. Ist diese Prüfung erfolg- reich, werden die Medien auf der GoPro-Kamera gelöscht. Sollen mehrere GoPro-Kameras synchronisiert werden, werden diese in einer Warteschlange se- quentiell abgearbeitet, da lediglich eine WLAN-Verbindung simultan zu Verfügung steht. #3: Medien-Upload in die Cloud Bevor die Medien in die Cloud hochgeladen werden, wird mit der in Schritt #1 verwendeten Strategie eine Gruppierung der Medien in unterschiedliche Sets vorgenommen. Ein Set ist jeweils die Gesamtmenge aller Medien die einem Kunden zugeordnet werden sollen. Anschliessend werden die Medien inklusive der Gruppierungsinformation in die Cloud hochge- laden. Der Upload in die Cloud kann nicht simultan zum Medien-Download in Schritt #2 stattfinden, wenn der Download über WLAN abläuft. Grund dafür ist, dass Android per se nicht mehrere WLAN-Verbindungen unterstützt und normalerweise auch eine GSM-Verbindung nicht parallel mit einer WLAN-Verbindung aufrecht sein kann. #4: Umwandlung hochauflösender Videos GoPro- und auch andere Kameras sind heutzutage fähig, Videos in enorm hohen Auflösungen aufzunehmen. 4K und 8K Videos sind keine Seltenheit mehr. Diese Videos können unbearbeitet nicht oder nur mit Mühe auf einer Website eingebettet und von einem User abgespielt/gestreamt werden. In Zukunft, jedoch nicht im geplanten Rahmen dieser Semesterarbeit, werden hochauflösende und speicherintensive Videos über einen Drittanbieter, wie beispielsweise dem AWS MediaCon- vert-Service, in tiefauflösende Videos umgewandelt. #5: Präsentation und Verkauf der Medien Auf einer Web-Plattform kann der Kunde mit Hilfe seiner Kundenidentifikation auf seine Medien zugreifen, eine Vorschau davon anschauen und sie erwerben. Diese Web-Plattform wird, wie bereits zuvor erwähnt, nicht im Rahmen dieser Semesterarbeit umgesetzt. 1.3 Datensicherheit und Datenschutz Die Adventure Cloud Lösung speichert Medien - Fotos und Videos - von Personen auf einem Server in der Cloud. Diese personenbezogenen Daten sollen vor unerwünschtem Zugriff so gut wie möglich geschützt werden. 1.3.1 Rechtliche Lage In der Schweiz darf niemand ein Bild einer Person ohne deren Einverständnis veröffentlichen. In der Anwendung der Adventure Cloud stellt sich diese Frage jedoch nicht, da Bilder und Videos einer Person nur von dieser eingesehen werden können. Dies wird über einen eindeutigen Zugriffscode erreicht, der lediglich der entsprechende Kunde besitzt. Möchte eine Person nicht AC 6
1.3. DATENSICHERHEIT UND DATENSCHUTZ fotografiert oder per Video aufgenommen werden, kann sie dies vor der Aufnahme unterbinden oder danach die Löschung anordnen. Die Adventure Cloud speichert keine besonders schützenswerte Personendaten und muss daher nicht auf dieses Punkt im Bundesgesetz über den Datenschutz (DSG) eingehen. 1.3.2 Datenschutz in der Cloud Als Unternehmen möchte man die Daten der Kunden, hier Medien, vor jeglichem unerwünsch- ten Zugriff schützen. Dies gilt auch für den Zugriff durch andere Staaten. Es gilt also zu gegebener Zeit (nicht im Rahmen dieser Arbeit) einen passenden Cloud-Provider auszuwählen. Viele renomierte Cloud-Anbieter, wie die Google Cloud, halten Standards und Verträge ein, um Daten auf ihren Servern zu schützen. So zum Beispiel das ISO 27001 Zertifikat, um das Risiko zu minimieren, dass Mitarbeiter Kundendaten missbrauchen. Google verpflich- tet sich ebenso zur Einhaltung der EU-Datenschutz-Grundverordnung (DSGVO) für alle ihre Google-Cloud-Platform-Dienste. Grundsätzlich war es bis 2018 so, dass Serverstandorte in der EU unter die GDPR gefallen sind und amerikanische Standorte betroffen waren vom Patriot Act 2001. Es spielt also grundsätzlich schon eine Rolle, wo sich der Server physisch befindet. Regulationen, wie der Privacy Shield, regeln den Datenaustausch zwischen Europa und den USA. Seit die Trump-Regierung 2018 den Clarifying Lawful Overseas Use of Data Act (CLOUDAct) eingeführt hat, kann sie auch auf Daten ausserhalb der USA, z.B. in Europa, zugreifen, obwohl der Act die GDPR verletzt. Das bedeutet im Klartext, dass selbst wenn man sich für einen Server- standort innerhalb der EU oder der Schweiz entschieden hat, der Service- oder Cloud-Anbieter aber ein US-Unternehmen ist, dass der Anbieter trotzdem gezwungen werden kann, Kundenda- ten an die US-Behörden zu übergeben. Vorzuziehen ist im Optimalfall also ein Schweizer Unternehmen, welches Cloud-Dienste anbietet. 1.3.3 Herausgabe von Daten in Zwischenfällen Eine weitere wichtige Frage ist der Umgang mit digitalen Medien, welche Zwischenfälle zeigen, bei denen Personen zum Beispiel verletzt oder gar tödlich verunglückt sind. Wie mit diesen Medien umgegangen wird und ob diese Daten an Behörden ausgehändigt werden sollen und müssen wird zu einem späteren Zeitpunkt geklärt, sobald das Produkt kommerziell genutzt werden möchte. AC 7
Kapitel 2
Resultate
2.1 Zielerreichung
Alle definierten Ziele der Semesterarbeit konnten in vollem Umfang umgesetzt werden, da keine
unüberwindbaren Hindernisse im Verlauf des Projekts aufgetreten sind.
Die nachfolgenden Unterkapitel beschreiben die implementierten Ergebnisse der einzelnen Be-
standteile des entwickelten Systems.
2.1.1 Analyse der Übertragungsgeschwindigkeit und deren Verlässlichkeit
Die Übertragungsgeschwindigkeit des Mediendownloads zwischen dem Android-Tablet und ei-
ner GoPro-Kamera (Modell Hero 7 Black) konnte mit einer empirischen Herangehensweise er-
mittelt werden.
Auch die Verlässlichkeit, bezüglich Unterbrüchen oder Abbrüchen, konnte mit dem Download-
Manager von Android ermittelt werden.
Die Ergebnisse sind grundsätzlich positiv ausgefallen. Leider erreicht die durchschnittliche Über-
tragungsgeschwindigkeit nicht mehr als gute 5 Megabyte pro Sekunde, obwohl die GoPro-
Kamera den IEEE 802.11n WLAN-Standard unterstützt, der bis zu 600 MBit/s übertragen kann.
Werden also GoPro-Kameras synchronisiert, die hochauflösende Video enthalten, die sich im
Grössenbereich von Gigabytes bewegen, dauert die Synchronisation mehrere Minuten an.
Der Einsatz in grösseren Unternehmen könnte daher zu Problemen führen. Zum Beispiel könnte
ein Skydive-Unternehmen, das 10 Springer hat, die zusammen springen und die Synchronisation
zur selben Zeit einleiten, in Engpässe geraten. Die Springer müssten teilweise bis zu einer halben
Stunden warten, bis alle GoPro-Kameras synchronisiert sind.
Die Lösung dafür wäre, mehrere Tablets bereitzustellen, welche für die Synchronisation verwen-
det werden.
Entgegen wirkt die Gruppierungsfunktion, die es ermöglicht, mehrere Kunden zu bedienen, be-
vor eine Synchronisation eingeleitet wird.
2.1.2 Mobile App
Die Mobile App konnte mit allen geplanten Anforderungen umgesetzt werden. Es läuft stabil
und verlässlich und glänzt durch die Anwendung des Google Material Design.
Um die Endpunkte der GoPro-Kamera zu ermitteln, wurde das offizielle GoPro-App für Andro-
id reverse enginnered und die Kommunikation zwischen diesem und der GoPro-Kamera über
Wireshark analysiert.
AC 82.1. ZIELERREICHUNG
Abbildung 2.1: Entwickeltes Mobile App
Verbindung mit GoPro-Kamera
Das Verbinden mit einer GoPro-Kamera läuft reibungslos. Das Mobile App fügt dem System das
WLAN-Netzwerk der zu synchronisierenden GoPro-Kamera hinzu, worauf das Tablet in Kürze
mit diesem verbunden ist.
Nach dem Mediendownload von der GoPro-Kamera wird das hinzugefügte WLAN-Netzwerk
vom System gelöscht und das Tablet verbindet sich wieder mit dem zuvor verbundenen WLAN-
Netzwerk. Dieses ist das Netzwerk, welches Internetzugriff hat. So kann das Mobile App die
heruntergelandenen Medien anschliessend in die cloudbasierte Backend-Applikation hochladen.
Download der Medien von GoPro-Kamera
Der Download der Medien von der GoPro-Kamera wurde über den nativen DownloadManager
und dessen Schnittstelle umgesetzt. Dafür würde ein eigenes Cordova-Plugin in Java entwickelt.
AC 92.1. ZIELERREICHUNG Die GoPro-Kamera, rsp. der Webserver von dieser, unterstützt Partial Request, d.h. der Medi- endownload kann ab einem bestimmten Offset wiederaufgenommen werden. Dies ist besonders nützlich, wenn ein Download wiederaufgenommen wird, nachdem dieser zum Beispiel aufgrund von Verbindungsschwierigkeiten unterbrochen oder pausiert wurde. Die Verwendung des DownloadManager war eine gute Entscheidung, einerseits, da so die Ent- wicklung eines eigenen Downloadverfahrens eingespart werden konnte und dieser andererseits bereits seit Jahren von Android entwickelt wird und verlässlich und fehlerfrei funktioniert. QR-Code Analyse und Gruppierung der heruntergelandenen Medien Die Erkennung von QR-Codes in den heruntergeladenen Medien von der GoPro-Kamera wur- de mit der Open Source Zxing-Libary und derem HybridBinarizer umgesetzt. Dazu wurde ein Cordova-Plugin in Java entwickelt. Die Erkennung funktioniert auch mit Fotos, welche relativ starke Schatten enthalten, da der HybridBinarizer eine hohe Toleranz im Scanverfahren aufweist. Die Analyse, respektive das Scanning nach QR-Codes, läuft schnell und vorallem parallel zu den anderen Prozessen ab. Pro Bild dauert das Scanning nur wenige Hundert Millisekunden. Das Gruppieren der Medien anhand der erkannten QR-Codes konnte dank dem sauberen Scan- verfahren wie geplant umgesetzt werden. Upload der Medien in die Cloud Der Upload der (gruppierten) Medien in die Cloud erfolgt automatisch, sobald das Tablet Zu- gang zum Internet hat. Dies wird geprüft, indem Google in einem Intervall von wenigen Sekun- den gepingt wird. Der Upload ist in der aktuellen Implementation weniger fehlertolerant im Vergleich zum Down- load von der GoPro-Kamera. Wird ein Fileupload in die Backend-Applikation unterbrochen, so muss er von Vorne gestartet werden. Dies sollte vor einem kommerziellem Einsatz optimiert werden. 2.1.3 Backend-Applikation Die Backend-Applikation wurde gemäss funktionalen und nichtfunktionalen Anforderungen im- plementiert. Authentifizierung Die Authentifizierung nutzt JWT-Token. Bei erfolgreicher Authentifizierung mittels Zugangsda- ten erhält der Nutzer einen Access Token, der für die Authentifizierung aller folgenden Anfragen an den Server verwendet wird, sowie einen Refresh Token, mit welchem ein neuer Access Token gelöst werden kann, sobald dieser abläuft. Kryptografisch wurde mit den zeitgemässen Verfahren gearbeitet. Die Zugangsdaten werden gesalted (eigener Salt pro User) in der Datenbank gespeichert, um Angriffen über Rainbow Tables vorzubeugen. Das Hashing der Passwörter erfolgt mit SHA256. Die Signierung der JWT-Token erfolgt mit HMACSHA256 und wird somit dem aktuellen Stan- dard gerecht. AC 10
2.1. ZIELERREICHUNG
REST API-Schnittstelle
Die REST API-Schnittstellendokumentation wird mit dem Einsatz von Swagger direkt aus dem
Code generiert. Diese enthält eine Beschreibung für jeden Endpunkt, die erwarteten Parameter
(Schemas) und die möglichen Status Codes der Antwort.
Abbildung 2.2: Swagger API
Datenbank
Die Erstellung des Datenbankschemas erfolgt mit dem Code-First Ansatz. Als ORM-Mapper
wurde das Entity Framework von Microsoft für .NET Core verwendet.
2.1.4 Continuous Integration
Für die Continous Integration aller Komponenten der Adventure Cloud wurden zweckmässig
zugeschnittene Docker Images erstellt.
Die CI-Pipeline erstellt das Mobile App für die Android und die Backend-Applikation. Dabei
wird beim Mobile App ein Linter eingesetzt, der den Code auf Fehler und Verletzungen an
den Coding Guidelines prüft. Die Backend-Applikation enthält ein Projekt für Unittests und ein
weiteres für Integrationstests, die im CI-Durchlauf ausgeführt werden.
Der Code der Backend-Applikation wird im CI-Prozess zu SonarCloud, einem Dienst für Code-
Analyse, gesendet, wo anschliessend diverse Metriken einsehbar sind (https://sonarcloud.io/
dashboard?id=adventure_cloud).
AC 112.2. SCHLUSSFOLGERUNG
Ebenso wird zusätzlich eine Testabdeckung in Prozent mittels dem CLI Tool Coverlet ermittelt,
wonach die Testabdeckung auch in GitLab zu jedem Commit ersichtlich ist.
2.2 Schlussfolgerung
Nach 11 Wochen und insgesamt 240 Arbeitsstunden wurde das Projekt abgeschlossen. Die fol-
genden Kapitel bewerten die erreichte Arbeit und geben eine Schlussfolgerung zum Projekt.
2.2.1 Bewertung der Ergebnisse
Die gesamte geplante Funktionalität konnte umgesetzt werden.
Resultate
Analyse
Analyse der GoPro-API
Als Erstes wurde die Schnittstelle zur GoPro-Kamera (Modell Hero 7 Black) unter-
sucht.Daraus resultierten Endpunkte der REST API-Schnittstelle, die von einem Webserver
auf der GoPro-Kamera zur Verfügung gestellt- und für die Umsetzung der Mobile App
benötigt werden.
Analyse der Übertragungsgeschwindigkeit und deren Verlässlichkeit
Um eine quantitative Aussage über die tatsächliche Übertragungsrate des Mediendown-
loads von der GoPro-Kamera auf ein Android Tablet machen zu könnnen, wurde eine em-
pirische Analyse der Übertragungsrate und der Verlässlichkeit erarbeitet. Die Erkenntnisse
können genutzt werden, um den praktischen Einsatz bewerten zu können und mögliche
Probleme und Lösungen zu diskutieren.
Backend
Backend-API
Die REST API-Schnittstelle wurde entsprechend den Anforderungen umgesetzt. Eine
Swagger-Dokumentation wird aus dem Code generiert und eine Postman-Collection steht
für das Testing zu Verfügung.
Datenbank
Die Datenkbank, respektive das Schema, wurde mit dem Code-First Ansatz umgesetzt.
Als Datenbank können SQLite und PostgreSQL austauschbar verwendet werden.
Datensicherheit
Die Daten werden verschlüsselt in der Datenkbank abgespeichert. Für die Verschlüsselung
werden zeitgemässe kryptographische Verfahren verwendet. Die initiale Authentifizierung
erfolgt über Zugangsdaten. Danach werden JWT-Token verwendet.
AC 122.2. SCHLUSSFOLGERUNG
CI, Unit- & Integrationtests
In der CI werden die Unit- und Integrationstests automatisiert ausgeführt. Die CI-Pipeline
schlägt fehl, wenn die Tests fehlschlagen. Die Testabdeckung wird berechnet und in GitLab
ausgegeben.
Code-Metriken
In der CI wird der Code an den Dienst SonarCloud gesendet, der daraus Code-Metriken
erzeugt, welche anschliessend im Dashboard von SonarCloud eingesehen werden können.
AC 132.2. SCHLUSSFOLGERUNG
Mobile App
Mediendownload von GoPro-Kamera
Der Mediendownload von GoPro-Kamera(s) wurde wie geplant implementiert und läuft
ziemlich stabil. Downloads, die unterbrechen oder pausieren, werden wiederaufgenom-
men. Beispielsweise, wenn die Konnektivität zur GoPro-Kamera kurz unterbrochen wird,
da diese kurzzeitig aus der Reichweite des WLAN entfernt wurde.
Gruppierung der Medien mit QR-Code-Scanning
Das Scanning auf QR-Codes in den heruntergeladenen Medien wurde mit der Zxing-
Library implementiert und wird den Anforderungen gerecht. Anhand der erkannten QR-
Codes wird eine Gruppierung gemäss Planung vorgenommen.
Medienupload in das Backend
Sobald das Mobile App Zugang zum Internet hat, lädt es Medien, die noch nicht zur
cloudbasierten Backend-Applikation hochgeladen wurden, hoch.
User Stories
Alle User Stories wurden gemäss der Anforderungsspezifikation implementiert.
Responsive Design
Das Mobile App wurde komplett mit dem Google Material Design und dessen Kompo-
nenten umgesetzt. Es ist responsive, verständlich aufgebaut und einfach bedienbar.
Internationalisierung
Das Mobile App nutzt die i18n-Library für die Internationalisierung und ist in Deutsch
und in Englisch verfügbar. Die Sprache kann in den Einstellungen umgestellt werden.
CI
Das Mobile App wird in der CI automatisch mit einem Linter auf Code-Fehler und Ver-
letzungen an den Coding Guidelines geprüft, erstellt und das Kompilat wird als Artefakt
auf GitLab direkt zum Download angeboten.
2.2.2 Risikomanagement
Das Risikomanagement hat sich als realistisch geplant herausgestellt. Das grosse Risiko, dass
die einzige Person (Sharon Moll) im Projekt aufgrund einer hospitalen Operation ausfällt, ist
in Woche 12 eingetreten. Da diese Wahrscheinlichkeit, respektive die Auswirkung, bei der Risi-
koidentifizierung als relativ hoch bewertet wurde, wurde die SA als Massnahme bis zu dieser
Woche fertiggestellt.
Es gab kleinere technische Schwierigkeiten während der Entwicklung. Diese konnte aber alle
innerhalb von kurzer Zeit gelöst werden.
AC 142.2. SCHLUSSFOLGERUNG 2.2.3 Fazit Umfang Die Bewertung der Ergebnisse zeigt, dass alle geplanten Anforderungen umgesetzt werden konn- ten. Zu Beginn war nicht gänzlich klar, ob die funktionalen Anforderungen tatsächlich nach Plan implementiert werden können, da keine vorgängige Machbarkeitsstudie erarbeitet werden konn- te. Daher ist es umso erfreulicher, dass keine unüberwindbaren technischen Hürden während der Entwicklung aufgetaucht sind. Es konnte wahrscheinlich relativ viel Zeit bei der Kommunikation eingespart werden, indem das Projekt von einer Person allein umgesetzt wurde. Technologien Die getroffenen Entscheidungen bezüglich den verwendeten Technologien haben sich als sehr positiv herausgestellt. Zu Beginn war unklar, ob sich ein natives Android App besser eignet als ein hybrides Web App, da für letzteres Cordova-Plugins benötigt werden, um native Funktionalitäten zu verwenden. Es hat sich jedoch schnell gezeigt, dass die Umsetzung solcher Plugins simpel ist. Das Design und die UI-Elemente des Apps konnten dank dem verwendeten UI-Framework Quasar sehr schnell und sauber implementiert werden. Die Verwendung des .NET Framework in der Backend-Applikation hat zu einer architektonisch klar geschichteten Applikation geführt, die performant und skalierbar ist. 2.2.4 Ausblick Das Projekt wird allenfalls in einer Bachelorarbeit weitergeführt, um es für den kommerziellen Nutzen zu finalisieren. Dazu muss vorallem eine Webplattform entwickelt werden, die es den Kunden ermöglicht, ihre Medien, die in der Cloud gespeichert sind, online einsehen und erwerben zu können. AC 15
2.2. SCHLUSSFOLGERUNG
Teil II
Projektdokumentation
AC 16Kapitel 3
Anforderungsspezifikation
Dieses Kapitel enthält die Anforderungsspezifikation dieser Semesterarbeit. Die Use Cases (funk-
tionale Anforderungen) werden beschrieben und die nicht-funktionalen Anforderungen (Quali-
tätsattribute) aufgezeigt.
3.1 Use Cases
Diese Semesterarbeit fokussiert sich auf die Umsetzung des Android-Apps und das Hochladen
von Medien von diesem in die Backend-Applikation in der Cloud. Augenmerk wird daher auf
die Anwendungsfälle im entsprechenden System des Android-Apps gelegt.
3.1.1 Akteure
Akteur Beschreibung
Anonymous wird hier als Pseudonym für einen nicht authentisierten Benutzer
Anonymous verwendet. Dieser Benutzer muss sich einloggen, um weitere Use Cases anstos-
sen zu können, da er sonst die notwendigen Authorisierungen nicht besitzt.
Der User ist ein im System hinterlegter Benutzer, der einer Organisation
unterstellt- und authentisiert ist. Er ist Teil einer Organisation, die Medien von
User
ihren Kunden in die Adventure Cloud hochladen möchte und stösst die dafür
notwendigen Use Cases an.
Tabelle 3.1: Akteure
3.1.2 Use-Case-Diagramm
Das nachfolgende Use-Case-Diagramm zeigt die relevanten Anwendungsfälle in der Android-
App. Die Anwendungsfälle sind visuell nicht nach Nummerierung geordnet, um die Übersicht-
lichkeit zu verbessern.
AC 173.1. USE CASES
Abbildung 3.1: Use-Case-Diagramm
3.1.3 Use-Case-Beschreibungen
Die Use-Cases beginnen mit der einheitlichen Beschreibung in Form einer User-Story mit folgen-
der Vorlage:
User-Story 3.1.1: Vorlage
Als , möchte ich , damit ich
.
Falls nützlich folgt eine detaillierte tabellarische Beschreibung nach Larman [1].
UC01 Login
User-Story 3.1.2: UC01 Login
Als nicht authentifizierter User, möchte ich mich in die Applikation einloggen, damit ich
die Applikation mit ihrer Funktionalität überhaupt nutzen kann.
UC02 CRUD GoPro-Kameras
User-Story 3.1.3: UC02 CRUD GoPro-Kameras
Als eingeloggter User möchte ich meine GoPro-Kameras im System hinterlegen, damit ich
diese in die Cloud synchronisieren-, sprich die Medien von diesen in die Cloud hochladen,
kann.
AC 183.1. USE CASES UC03 GoPro-Kamera synchronisieren User-Story 3.1.4: UC03 GoPro-Kamera synchronisieren Als eingeloggter User möchte ich die Synchronisation einer meiner GoPro-Kameras an- stossen, damit die Medien von dieser in die Cloud übertragen werden. Dieser Anwendungsfall erweitert den Anwendungsfall UC04 CRUD Mediensets im nachfolgen- den Schritt 5, denn die Synchronisierung erfordert CRUD-Operationen auf die Mediensets, wel- che im Backend verwaltet werden. AC 19
3.1. USE CASES
Primärer Akteur User
Ein User kann die Synchronisierung einer seiner GoPro-Kameras auslö-
Übersicht sen, worauf das Android-Gerät die Medien von dieser herunter- und in
die Cloud hochlädt.
Interessenten User: Möchte eine seiner GoPro-Kameras synchronisieren.
• Das Android-Gerät ist mit dem Backend der Adventure Cloud ver-
bunden.
• Die gewünschte GoPro-Kamera ist im System eingetragen.
Vorbedingungen
• Die GoPro-Kamera ist örtlich im nahen Umkreis des Android-Geräts,
sodass dieses eine Verbindung mit der GoPro-Kamera aufbauen kann.
• Die Medien der GoPro-Kamera befinden sich auf dem Android-Gerät.
• Auf der GoPro-Kamera sind die heruntergeladenen Medien gelöscht.
• Die Verbindung zwischen Android-Gerät und GoPro-Kamera ist be-
endet.
Erfolgsgarantie
• Ein Medienset wird in der Cloud erstellt (siehe UC04 CRUD Medien-
sets).
• Die Medien werden vom Android-Gerät in die Cloud in das erstellte
Medienset hochgeladen.
1. Der User möchte eine GoPro-Kamera synchronisieren.
2. Der User wählt in der Android-App auf dem Android-Gerät die
Schaltfläche zur Synchronisation an.
3. Eine Liste von GoPro-Kameras, welche im System hinterlegt sind,
Haupterfolgsszen. wird angezeigt. Der User wählt die entsprechende GoPro-Kamera
aus.
4. Die GoPro-Kamera wird in die Warteschlange der zu synchronisie-
renden Geräten aufgenommen.
5. Die Synchronisation wird erfolgreich vollzogen.
*a Die GoPro-Kamera ist örtlich nicht genug nahe, damit das Android-
Gerät eine Verbidnung mit dieser aufbauen kann.
1. Die GoPro-Kamera wird in der Warteschlange der zu synchronisie-
renden GoPro-Kameras übersprungen.
2. Nachdem die restlichen GoPro-Kameras in der Warteschlange ab-
gearbeitet wurden, erfolgt ein weiterer Versuch zum Aufbau einer
Verbindung.
3. Je nach Einstellung wird dem Benutzer nach einer bestimmten An-
zahl an erfolglosen Versuchen eine Fehlermeldung angezeigt und
Alternative Flows die GoPro-Kamera wird aus der Warteschlange entfernt.
2a Keine GoPro-Kamera wurde im System hinterlegt.
1. Der User wird aufgefordert eine GoPro-Kamera im System hinzu-
zufügen (UC02 CRUD GoPro-Kameras).
5a Die Synchronisierung ist fehlerbehaftet oder wurde abgebrochen.
1. Ein erneuter Download-Versuch wird initiert.
2. Falls dieser wiederholt zu einem fehlerhaften Resultat führt, wird
eine Fehlermeldung angezeigt und die Synchronisation für diese
GoPro-Kamera abgebrochen.
Auftrittshäufigkeit Beliebig oft
Tabelle 3.2: UC03 GoPro-Kamera synchronisieren
AC 203.1. USE CASES
UC04 CRUD Mediensets
User-Story 3.1.5: UC04 CRUD Mediensets
Als eingeloggter User möchte ich die Mediensets bearbeiten können, damit ich Fehler in
der automatischen Gruppierung der Medien beheben- und die Sets filigraner verwalten
kann.
Primärer Akteur User
Ein User kann die Mediensets manuell bearbeiten, falls er/sie in das
Standardverhalten der Gruppierungsfunktion für Sets eingreifen möch-
Übersicht
te. Er kann Medien von einem Set entfernen, in ein anderes verschieben
oder ein ganzes bestehendes Set löschen.
Interessenten User: Möchte eins oder mehrere Mediensets mutieren.
• Das Android-Gerät ist mit dem Backend der Adventure Cloud ver-
Vorbedingungen bunden.
• Medien müssen auf dem Android-Gerät vorhanden sein.
• Die Deletion eines Sets führt zur tatsächlichen Entfernung lokal und
in der Cloud.
• Die Deletion von Medien in einem Set führt zur tatsächlichen Entfer-
nung lokal und in der Cloud.
Erfolgsgarantie • Das Verschieben von Medien von einem Set in ein anderes bewirkt
eine Entfernung im Ursprungsset und die Addition im Zielset lokal
und in der Cloud.
• Alle Operationen werden über die REST API-Schnittstelle zum Cloud-
Backend synchronisiert.
1. Der User möchte eine CRUD-Operation auf ein Medienset vorneh-
men.
2. Der User führt eine der möglichen Operationen durch.
Haupterfolgsszen.
3. Das Android-Gerät baut eine Verbindung zum Cloud-Backend auf
und die Operation wird mit diesem synchronisiert.
4. Die Änderung wird lokal und in der Cloud übernommen.
3a Das Android-Gerät kann keine Verbindung zum Cloud-Backend auf-
bauen.
1. Die Operation wird abgebrochen.
2. Der User wird auf die Fehlerursache hingewiesen.
Alternative Flows 3b Die Synchronisation mit dem Cloud-Backend schlägt fehl.
1. Die Operation wird abgebrochen.
2. Das System ist möglicherweise in einem inkonsistenen Zustand,
welcher manuell berichtigt werden muss.
3. Dem User wird eine adäquate Fehlermeldung präsentiert.
Auftrittshäufigkeit Beliebig oft
Tabelle 3.3: UC04 CRUD Mediensets
AC 213.2. NICHT-FUNKTIONALE ANFORDERUNGEN UC05 CRUD Einstellungen User-Story 3.1.6: UC05 CRUD Einstellungen Als eingeloggter User möchte ich Einstellungen vornehmen, damit ich den Vorgang der Synchronisierung, Gruppierung und allenfalls weiteren Funktionalitäten für meine An- wendung optimaler anpassen kann. 3.2 Nicht-funktionale Anforderungen Für die Einteilung und Organisation der QAs wird nachfolgend die FURPS-Taxonomie verwen- det. Um die Nicht-funktionalen Anforderungen möglichst zielführend zu definieren, wird der SMART- Ansatz so gut wie möglich verfolgt. 3.2.1 Funktionalität Angemessenheit Die Authentifizierung, sowie auch die Authorisierung werden simpel gehalten. Für die Authen- tifizierung wird lediglich ein Benutzername, sowie ein Passwort benötigt. Beide Mechanismen werden entweder über die vorhandenen Komponenten des .NET Core Frameworks oder mit einer simplen eigenen Implementierung bis zur Abgabe des Projekts umgesetzt. 3.2.2 Benutzbarkeit Verständlichkeit Die Benutzeroberfläche des Android-App ist in Deutsch und Englisch verfügbar. Dies beinhaltet lediglich Texte, nicht aber Bildmaterial, welches sprachspezifische Inhalte aufweist. Die beiden Sprachversionen sind spätenstens am Ende des Projekts verfügbar. Erlernbarkeit/Bedienbarkeit Die Benutzeroberfläche soll dem neusten Designstandard entsprechen und so intuitiv in kurzer Zeit bedient werden können. Dazu wird das Google Material Design für alle Ansichten und deren Widgets verwendet. 3.2.3 Zuverlässigkeit Reife 90% der Aktionen der Benutzer sollen wie geplant und ohne fehlerhafte Zustände durchgeführt werden können. Systemfehler werden dem Benutzer mit einer verständlichen und adäquaten Fehlermeldung mitgeteilt. Fehlertoleranz Fehlerhafte Eingaben sollen nicht zu inkonsistenten Zuständen und Abstürzen des Programs führen. Allfällige Inputfehler werden dem Benutzer mit einer entsprechenden Nachricht signa- lisiert und ein Hilfetext informiert, wo der Fehler liegt. Mindestens 90% aller Eingabemasken müssen fehlerhafte Eingaben abfangen können. AC 22
Sie können auch lesen
