"Pay-as-you-park"-Produkte für Kfz-Versicherungen. Implementierung des Android App Showcases "ParkSafe"

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Problemstellung und Zielsetzung
1.3 Vorgehensmodell
1.4 Aufbau der Arbeit

2 Grundlagen
2.1 Versicherungsfachliche Begriffsabgrenzungen
2.2 Android
2.2.1 Android-Plattform und -Version
2.2.2 Spezifika Java Android
2.3 „Cloud Firestore“-Datenbank von Google
2.4 Geofence/Geofencing

3 Anforderungsdefinition und -analyse
3.1 Überblick zum Kapitel
3.2 Vorgehensmodell
3.3 Anforderungsdefinition
3.3.1 Identifikation der Stakeholder
3.3.2 Brainstorming als Kreativitätstechnik
3.3.3 Brainstorming zur Erhebung der Grundfunktionalitäten
3.3.4 Brainstorming zur Definition benötigter Use Cases
3.4 Anforderungsanalyse
3.4.1 Spezifikation funktionaler Systemanforderungen in einem Lastenheft
3.4.2 Spezifikation nicht-funktionaler Systemanforderungen in einem Lastenheft
3.4.3 Priorisierung von Systemanforderungen

4 Prototyp-Entwicklung
4.1 Überblick zum Kapitel
4.2 Zweck des Prototypen
4.3 Prototyp GUI
4.4 Prototyp-Architektur/Klassendiagramm.
4.5 Implementierte Use Cases
4.5.1 UC016: Wetter-Daten prüfen
4.5.2 UC017: Geofence-Daten prüfen
4.6 Schnittstellen
4.6.1 Cloud Firestore Geofence-Datenbank
4.6.2 Wetterdaten von openweathermap.org
4.7 Bewertung des Prototypen

5 Implementierung
5.1 Überblick zum Kapitel
5.2 Architektur
5.2.1 MainActivity und Layout
5.2.2 Entwurfsmuster
5.2.3 Worker Threads
5.2.4 Strukturierung der Anwendung in Packages
5.3 Objektorientierter Entwurf
5.3.1 Klassenmodell
5.3.2 Konventionen zur Namensgebung
5.3.3 Hilfsklassen
5.3.4 Refactoring des Klassenmodells
5.4 Highlights der Implementierung/Kritischste Klassen
5.4.1 MainActivity
5.4.2 AsyncTasks
5.4.3 JSON Parser
5.4.4 Komplexe Use Cases im Detail
5.5 Schnittstellen
5.5.1 Bonusprogramm-Datenbank
5.5.2 Geofence-Datenbank
5.5.3 openweathermap.org-API
5.5.4 Google-Places-API

6 Qualitätssicherung
6.1 Überblick zum Kapitel
6.2 Standards und Konventionen
6.2.1 Dokumentations-Standards
6.2.2 Design-Standards
6.2.3 Coding-Standards
6.3 Software Reviews/Code-Inspektionen
6.4 Test-Plan
6.4.1 Vorgehen
6.4.2 Zu testende Features
6.4.3 Test-Verfahren
6.5 Testfälle
6.5.1 Testfall-Spezifikation
6.5.2 Testfall zu UC009: Userdaten persistieren
6.5.3 Testfall zu UC015: Multi-Gefahrencheck ausführen
6.5.4 Testdurchführung

7 Schlussbetrachtung
7.1 Zusammenfassung
7.2 Kritische Würdigung der Ergebnisse
7.3 Ausblick

Literaturverzeichnis

Anhang
Anhang A: Arbeitsdokumente
Anhang B: Lastenheft

Kurzfassung

Von Versicherungen werden heute verschiedene Produkte angeboten, die App-gestützt das Kundenverhalten evaluieren und dadurch eine verhaltensabhängige Ermittlung von Versicherungsprämien ermöglichen. Dazu zählen häufig mit dem Zusatz „Pay-as-you-x“ bezeichnete Produkte wie z. B. Kfz-Versicherungen, die eine risikoarme Fahrweise des Versicherten mit einer niedrigeren Prämie belohnen (hier also „Pay-as-you-drive“).

Die im Rahmen dieser Arbeit entwickelte „ParkSafe“-App soll diesen Themenkomplex um einen neuen Anwendungsfall erweitern und die Realisierung von „Pay-as-you-park“-Produkten ermöglichen. Es handelt sich dabei um Kfz-Versicherungen, bei denen der Anwender durch Nutzung der App vor bestimmten Risiken beim Parken gewarnt wird, um auf diese Weise das Versicherungsrisiko zu reduzieren. Der Versicherungsnehmer wird im Gegenzug bei entsprechender Reaktion dafür belohnt.

Dazu wurden funktionale und nicht-funktionale Anforderungen an eine solche App erhoben und in einem Lastenheft dokumentiert. Basierend auf diesen Anforderungen, wurde zunächst ein Prototyp auf der Android-Plattform entwickelt, um eine prinzipielle Machbarkeit der Ziellösung zu verifizieren. Da die Erstversion der App als Showcase zur Demonstration einer definierten User Journey dienen soll, wurden im Anschluss benötigte Features ausgewählt, detailliert spezifiziert und implementiert. Im Rahmen einer Qualitätssicherung wurden schließlich verschiedene Tests durchgeführt, um die Funktionsfähigkeit dieser User-Journey zu gewährleisten.

Abstract

Today insurance companies offer different products which evaluate the behaviour of customers in order to calculate insurance premiums based on this behaviour. Products in this category are often labeled as “Pay-as-you-x”-products like car insurances which reward a less risky driving style with a lower premium (in this case „Pay-as-you-drive“ accordingly).

The “ParkSafe”-app, which has been developed within this thesis, is supposed to add a new use case to this product category by realizing “Pay-as-you-park”-products. Those products are supposed to reduce the insurance risk by warning the customer of certain dangers through the usage of the app. The customer gets rewarded in case he reacts properly.

For this purpose functional and non-functional requirements have been created and documented in a software requirements specification. Based on these requirements a prototype has been developed in order to verify a general feasibility for the implementation of the target solution. Since the initial version of the app is supposed to be used as a show case in order to demonstrate a defined user journey, required features have been selected, designed in detail and implemented. Finally multiple tests have been conducted during a quality assurance phase in order to guarantee the functionality of the defined user journey.

Abbildungsverzeichnis

Abbildung 1: Vorgehensmodell in der Anforderungsanalyse

Abbildung 2: Mindmap Brainstorming zur Feature-Erhebung

Abbildung 3: Mindmap Brainstorming zur UC-Identifikation

Abbildung 4: Prototyp-GUI nach Durchführung Wetter-Check

Abbildung 5: Prototyp-GUI im Initialzustand

Abbildung 6: Klassendiagramm ParkSafe-Prototyp

Abbildung 7: Sequenzdiagramm der Implementierung „UC016:Wetterdaten prüfen“ im Prototyp

Abbildung 8: Sequenzdiagramm der Implementierung „UC017: Geofence-Daten prüfen“ im Prototyp

Abbildung 9: Datenmodell ParkSafePrototypDB

Abbildung 10: Geofence als Viereck mit Koordinaten (49, 5) im Zentrum

Abbildung 11: App-Architektur inklusive Activity und Fragments

Abbildung 12: Klassendiagramm MVC-Entwurfsmuster am Beispiel RiskOverviewFragment

Abbildung 13: Klassendiagramm MVC-Komponenten zu Bonusübersicht und persönliche Daten

Abbildung 14: Klassendiagramm MVC-Komponenten zu Gefahrenübersicht und Parkhaussuche

Abbildung 15: Klassendiagramm MainActivity

Abbildung 16: Klassendiagramm Hilfsklassen Teil I

Abbildung 17: Klassendiagramm Hilfsklassen Teil II und JSON-Parser

Abbildung 18: Klassendiagramm AsyncTask-Klassen

Abbildung 19: Sequenzdiagramm zu „UC015: Multi-Gefahrencheck ausführen“

Abbildung 20: Sequenzdiagramm zu „UC009: User persistieren“

Abbildung 21: Datenmodell Bonusprogramm-DB

Abbildung 22: Datenmodell Geofence-Datenbank

Tabellenverzeichnis

Tabelle 1: Bewertung und Priorisierung definierter Use Cases

Tabelle 2: Regeln zur Ableitung von UC-Prioritäten anhand vorgenommener Bewertung

Tabelle 3: GUI Design des Prototypen

Tabelle 4: Überblick Hilfsklassen und ihre Verantwortlichkeiten

Tabelle 5: Fachliche Kontexte für die Abfrage von JSON-Files und zugehörige Parser-Klassen

Tabelle 6: Übersicht Endgeräte für Testdurchführungen

Tabelle 7: Testfall TC001 zu UC

Tabelle 8: Testfall TC002 zu UC012, UC015, UC016, UC

Tabelle 9: Vergleich existierender Apps im Versicherungsbereich

Tabelle 10: Aufwandsschätzung basierend auf Prototyp-Implementierung (alle Aufwände in Personentagen (PT))

1 Einleitung

1.1 Motivation

Versicherungen setzen Apps auf mobilen Endgeräten heute für verschiedene Zwecke ein. Bei einem Vergleich verschiedener existierender Lösungen¹ zeigt sich, dass diese im Wesentlichen die folgenden Funktionalitäten bieten:

1) Abschluss/Bearbeitung von Verträgen (z.B. temporäre Änderung eines Fahrers in einer Kfz-Versicherung)
2) Meldung/Bearbeitung von Schäden (z.B. Einreichen einer Zahnarztrechnung)
3) Änderung von Partnerdaten (z.B. Änderung der Adresse des Versicherungsnehmers)
4) Vergleich/Suche von geeigneten Versicherungsprodukten (z.B. Vergleich verschiedener Krankenhaustagegeld-Versicherungen)
5) Erhebung/Meldung von Daten zum Versicherungsnehmer (z.B. Telematikdaten zur Evaluierung des Fahrverhaltens)

Insbesondere die Erhebung von Daten zum Versicherungsnehmer wird für Versicherer im Kontext von „Big Data“ sowie der zunehmenden Verbreitung des „Internet of Things“ (IoT)² immer interessanter. Der Nutzen besteht u.a. in der Erschließung von neuen Wegen der Kundeninteraktion sowie der Gestaltung neuer Versicherungsprodukte. So nutzen z.B. „Pay as you drive“-Produkte Telematik-Daten von Fahrzeugen, um von dem Fahrverhalten von Versicherungskunden Schadenrisiken abzuleiten und in Abhängigkeit der ermittelten Risiken unterschiedliche Versicherungsprämien³ zu berechnen. Ein anderes Beispiel aus dem Bereich der Kfz-Versicherung ist eine Warnung des Versicherungsnehmers vor Fahrstrecken, die durch Unwetter gefährdet sind, und die anschließende Bereitstellung alternativer Routen. Beide Beispiele nutzen das IoT oder Big Data und erhöhen gleichzeitig die Interaktion mit dem Versicherungskunden, die sich bei Versicherungsprodukten ansonsten häufig auf den Vertragsabschluss und die Bearbeitung eines Schadenfalls beschränkt.⁴

An diesen Beispielen lässt sich erkennen, dass es für Versicherungsunternehmen sinnvoll sein kann, weitere Anwendungsfälle in diesem Kontext zu identifizieren und entsprechende Apps zur Unterstützung zu entwickeln. Es stellt sich daher die Frage, wie ein neuer Anwendungsfall aussehen kann und was eine zugehörige App leisten muss.

1.2 Problemstellung und Zielsetzung

Wie in Kapitel 1.1 aufgezeigt, gibt es bereits erste Ansätze und Apps, die Daten des Versicherungsnehmers verwenden, um Versicherungsrisiken aktiv zu steuern bzw. Anreize für den Versicherungsnehmer zu setzen, um das Versicherungsrisiko zu minimieren.

Bisher im Kontext von Kfz-Versicherungen noch nicht berücksichtigt wurde das Parken eines Fahrzeugs und das damit verbundene Versicherungsrisiko. Ähnlich wie das Versicherungsrisiko durch den Fahrstil des Versicherungsnehmers beeinflusst werden kann, kann es auch dadurch beeinflusst werden, an welchem Ort ein Fahrzeug geparkt wird bzw. welchen Risiken es beim Parken an einem bestimmten Ort ausgesetzt wird. Dies wird z. B. durch sogenannte „Garagenrabatte“ deutlich, die Versicherer gewähren, wenn ein Fahrzeug in einer Garage geparkt wird.⁵

Das übergeordnete Ziel dieser Arbeit soll daher die Entwicklung eines Showcases, d. h. einer prototypischen App⁶ „ParkSafe” zur Realisierung dieses neuen Anwendungsfalls sein. Aus diesem übergeordneten Ziel lassen sich die folgenden Unter-Ziele für die App ableiten:

1) Die App soll die Modellierung von „Pay-as-you-park”-Versicherungsprodukten ermöglichen, die den Versicherungsnehmer bei einem risikominimierenden Parken seines Fahrzeugs mit niedrigeren Versicherungsbeiträgen belohnen.
2) Die App soll Gefahren für das Parken an dem aktuellen Ort des Anwenders ermitteln und ihn gegebenenfalls davor warnen.
3) Der Anwender soll Vorschläge zur Risikovermeidung erhalten und beim Befolgen dieser Vorschläge über ein Bonussystem belohnt werden.

Neben diesen funktionalen Zielsetzungen werden weitere Ziele im Hinblick auf den Softwarentwicklungsprozess definiert:

1) Die App soll in einem Wasserfallmodell⁷ entwickelt werden.
2) Die Anforderungen an die App sollen so spezifiziert sein, dass sie jederzeit für Dritte einsehbar und verständlich sind.
3) Der Code soll durch Dritte wartbar und erweiterbar sein, da die App potenziell auch in einer produktiven Umgebung in einem Versicherungsunternehmen eingesetzt werden soll.

1.3 Vorgehensmodell

Da der Autor als allein verantwortliche Person der einzige Stakeholder für die Entwicklung der „ParkSafe“-App ist, kann davon ausgegangen werden kann, dass es möglich ist, eine Menge vollständiger Anforderungen zu Beginn des Projektes zu definieren, die im weiteren Verlauf weitestgehend stabil bleibt. Auf die Vorteile eines agilen Vorgehensmodells, welches auf zunächst wenig definierte und häufig ändernde Anforderungen ausgelegt ist, kann aus diesem Grunde verzichtet werden. Stattdessen soll das Vorgehensmodell sich am Wasserfallmodell orientieren, welches sich in dem beschriebenen Szenario gut eignet.⁸

In der ersten Phase werden daher Anforderungen an die App definiert, um die in Kapitel 1.2 festgelegten Ziele erreichen zu können. Diese werden detailliert in einem Lastenheft dokumentiert (siehe Kapitel 3).

In der zweiten Phase wird ein Prototyp der App mit minimalem Funktionsumfang entwickelt, um eine prinzipielle Machbarkeit zu bestätigen. Es handelt sich dabei um einen vertikalen Prototypen, da in erster Linie Ausschnitte aus der Anwendungslogik und Netzwerkzugriffe verprobt werden sollen.⁹ Die GUI spielt zunächst eine eher nachrangige Rolle.

Die dritte Phase beinhaltet den Entwurf sowie die Implementierung der technischen Lösung. Die gewonnenen Erkenntnisse aus der Entwicklung des Prototypen fließen hier mit ein.

In der vierten und letzten Phase werden Tests für kritische Teilbereiche der App durchgeführt, um eine prinzipielle Funktionsfähigkeit zu gewährleisten.

1.4 Aufbau der Arbeit

Nach der Einführung werden in Kapitel 2 versicherungsfachliche Grundlagen bereitgestellt und Grundlagen sowie Spezifika der eingesetzten Android-Plattform vermittelt.

Kapitel 3 beschreibt das Vorgehen während der Anforderungsanalyse und die Erstellung des Lastenheftes im Detail.

In Kapitel 4 werden die Entwicklung des Prototypen sowie die umgesetzten Features und relevanten Schnittstellen erläutert.

Die Beschreibung des technischen Designs sowie aller Details zur Implementierung der App erfolgt in Kapitel 5.

Kapitel 6 beinhaltet das Testkonzept sowie eine Beschreibung aller durchgeführten Maßnahmen zur Qualitätssicherung.

Abschließend werden die Ergebnisse und Erfahrungen aus der Entwicklung der App in Kapitel 7 zusammengefasst und kritisch reflektiert.

2 Grundlagen

2.1 Versicherungsfachliche Begriffsabgrenzungen

Da die „ParkSafe“-App im Kontext von Kfz-Versicherungen entwickelt wird, sollen nachfolgend einige versicherungsfachliche Grundbegriffe erläutert werden.

Ein wesentlicher Nutzen der App aus Sicht eines Versicherungsunternehmens (wie z.B. Allianz o. ä.) ist die Senkung des Versicherungsrisikos durch eine Beeinflussung des Kundenverhaltens beim Parken eines Fahrzeugs. Das Versicherungsrisiko stellt in diesem Kontext das Risiko bzw. die Wahrscheinlichkeit dar, dass ein Schadenfall für die Kfz-Kasko- bzw. -Haftpflichtversicherung des Kunden eintritt.¹⁰

Eine Kfz-Kaskoversicherung bietet Schutz vor der Beschädigung, dem Verlust oder der Zerstörung eines Kraftfahrzeugs.¹¹ Eine Kfz-Haftpflichtversicherung deckt Personen- und Sachschäden ab, die durch den Gebrauch eines Kraftfahrzeugs entstanden sind.¹²

Ein Kunde profitiert von einem risikoärmeren Verhalten, indem er seine Versicherungsprämie senken kann. Als Versicherungsprämie wird der monetäre Beitrag eines Kunden für seine Kfz-Versicherung bezeichnet.¹³

Alle Daten, die ein Versicherungsunternehmen im Kontext seiner Kunden speichert, gehören zu den Daten, die als Partnerdaten bezeichnet werden. Partnerdaten sind alle Daten, die im Zusammenhang mit einem „Partner“ des Versicherers stehen. „Partner“ können in diesem Kontext alle juristischen/natürlichen Personen sein, die mit dem Versicherer interagieren wie z.B. Makler, Vertriebsmitarbeiter, andere Versicherer und insbesondere auch Endkunden des Versicherers. Partnerdaten werden entsprechend in sog. Partnersystemen verwaltet.¹⁴

2.2 Android

2.2.1 Android-Plattform und -Version

Die zu entwickelnde „ParkSafe“-App soll vom User während des Parkvorganges in seinem Fahrzeug genutzt werden. Es handelt sich daher um eine App, die für mobile Endgeräte ausgerichtet ist. Als Ziel-Plattform für die erste Version der App wurde „Android“ gewählt, da es sich hier um das in Deutschland und auch weltweit meist verbreitete Betriebssystem für mobile Endgeräte handelt. In Deutschland liegt der Marktanteil bei etwa 80 %.¹⁵

Um möglichst viele der existierenden Versionen von Android zu unterstützen, wurde geprüft, ab welcher Version keine Einschränkungen für die zu entwickelnden Funktionalitäten bestehen. Im Rahmen dieser Analyse wurde festgestellt, dass eine Integration der Google Firestore-Datenbank (in 2.3 noch näher erläutert) mindestens die Android-Version 4.1 erfordert.¹⁶ Ansonsten gab es keine Gründe, die eine höhere Version zwingend erforderlich machten. Da der weltweite Anteil von Endgeräten mit einer Version niedriger als 4.1 lediglich bei 0,6 % liegt, stellt diese Version eine nahezu vollständige Abdeckung aller verwendeten Geräte dar.¹⁷ Version 4.1 wurde daher als minimal unterstützte Android-Version für die „ParkSafe“-App definiert.

2.2.2 Spezifika Java Android

Anwendungen für die Android-Plattform können in Java oder der neueren Entwicklungssprache Kotlin entwickelt werden. Da für die „ParkSafe“-App Java als Entwicklungssprache gewählt wurde, sollen im Folgenden Gemeinsamkeiten und Unterschiede zwischen Java SE¹⁸ und Java für Android kurz skizziert werden.

Die Kernbibliotheken in Android enthalten die meisten Pakete, die aus Java SE bekannt sind wie z.B. java.util oder java.io. Darüber hinaus gibt es Android-spezifische Bibliotheken wie z.B. die „Material Components“ aus dem Package com.google.android.material, die verschiedene Komponenten für ein ansprechendes GUI-Design bereitstellen. Für die Entwicklung von Benutzeroberflächen sind Java SE-Bibliotheken wie java.swing oder java.awt für Android nicht verfügbar.¹⁹ Es gibt jedoch eigene Libraries für Android, die ähnliche Funktionalitäten bereitstellen. Anstatt GUI-Elemente mit Java-Code zu erzeugen, gibt es in Android-Studio allerdings auch die Möglichkeit, diese mit Hilfe einer XML-basierten Sprache zu deklarieren, die von der Entwicklungsumgebung in Code übersetzt wird.²⁰

Im Gegensatz zu Java SE wird in Android keine main-Methode definiert, die beim Start der App ausgeführt wird und die Initialisierung der grafischen Anzeige anstößt. Die Komponenten, die in Android GUI-Elemente enthalten und somit die Schnittstelle zum Benutzer darstellen, heißen „Activities“, d. h. von der Klasse Activity abgeleitete Klassen. Jede Applikation besteht aus mindestens einer Activity, die in einer sogenannten „Manifest“-Datei als „Main Activity“ definiert ist. Innerhalb dieser Activity muss eine onCreate()-Methode definiert sein, sodass diese beim Start der App als Erstes ausgeführt werden kann (analog der main-Methode in Java SE).²¹

2.3 „Cloud Firestore“-Datenbank von Google

Für verschiedene Funktionalitäten der „ParkSafe“-App ist es notwendig, bestimmte Daten außerhalb der App in einer Datenbank zu persistieren. Da die Erstversion einen Showcase darstellt, können diese Datenbanken in einer produktiven Version prinzipiell ausgetauscht werden. Dennoch sollte auch für die Erstversion bereits eine Datenbank-Lösung eingesetzt werden, die sich für einen Produktivbetrieb eignet und die entsprechenden Anforderungen an Performance, Verfügbarkeit, Skalierbarkeit etc. erfüllt (vgl. auch Kapitel 3.4 des Lastenheftes). Forrester hat in diesem Kontext die „Cloud Firestore“-Datenbank von Google als „Leader“ im Bereich „Database-as-a-Service“ eingestuft.²² Die Wahl ist daher auf diese Lösung gefallen. Es handelt sich dabei um eine NoSQL-Cloud-Datenbank, die Daten nicht in Tabellen, sondern in sog. „Documents“ und „Collections“ speichert. Es ist die Nachfolgerversion der „Firebase Realtime Database“.²³

2.4 Geofence/Geofencing

Im Zusammenhang mit dem Gefahrencheck, der in der App durchgeführt werden kann, wird im Laufe der Arbeit auch ein Check zur Ermittlung von „Geo-Gefahren“ erwähnt. Dazu ist es notwendig, das Konzept eines „Geofences“ zu verstehen. Ein Geofence stellt ein virtuell abgegrenztes Areal dar, welches durch die Angabe von GPS-Koordinaten definiert wird. Kann der Standort eines Nutzers z. B. über sein Smartphone abgefragt werden, kann auch ermittelt werden, ob der Nutzer sich innerhalb eines definierten Geofences befindet. Häufig lösen Apps/Anwendungen beim Betreten eines solchen Geofences bestimmte Aktionen aus, was auch als „Geofencing“ bezeichnet wird.²⁴

3 Anforderungsdefinition und -analyse

3.1 Überblick zum Kapitel

In diesem Kapitel soll näher erläutert werden wie die Anforderungen an die App entstanden sind und wie diese dokumentiert wurden. Zu diesem Zweck wird zunächst das Vorgehensmodell und anschließend der Ablauf selbst beschrieben. Abschließend wird der Prozess zur Priorisierung der spezifizierten Anforderungen skizziert.

3.2 Vorgehensmodell

Um die in Kapitel 1.2 definierten Ziele zu erreichen, mussten zunächst Anforderungen an die „ParkSafe“-App spezifiziert werden. Bei der Vorgehensweise wurde sich am Standard „ISO/IEC/IEEE 29148:2011“²⁵ orientiert, der eine Unterteilung in die beiden Prozesse der Anforderungsdefinition und Anforderungsanalyse empfiehlt. Die Anforderungsdefinition beinhaltet im Wesentlichen die Erhebung und Definition von Anforderungen der Stakeholder. In der Anforderungsanalyse werden diese Stakeholderanforderungen erweitert bzw. transformiert, um Systemanforderungen zu erhalten, die beschreiben, was das zu entwickelnde System leisten muss, um die Stakeholderanforderungen erfüllen zu können.²⁶

Innerhalb dieser Prozesse gibt es eine Vielzahl vorgeschlagener Aktivitäten und Aufgaben, die zum großen Teil auch durchgeführt wurden. Auf einen detaillierten Vergleich der durchgeführten Aktivitäten und eine Referenzierung auf die entsprechenden Abschnitte des Standards soll jedoch verzichtet werden. Stattdessen sollen die beiden Prozesse als Projektphasen verstanden werden, für die in den Folgekapiteln jeweils das konkrete Vorgehen im Detail beschrieben wird.

Im Rahmen der Anforderungsdefinition wurden zunächst Stakeholder identifiziert und verschiedene Brainstormings durchgeführt, um gewünschte Grundfunktionalitäten und benötigte Use Cases (UCs) zu definieren. In der Anforderungsanalyse wurde, basierend auf diesen Stakeholderanforderungen, ein Lastenheft erstellt, in dem funktionale und nicht-funktionale Systemanforderungen an die App spezifiziert wurden. Die funktionalen Anforderungen wurden im Wesentlichen in Form von detaillierten Use Case-Beschreibungen dokumentiert. Um zunächst alle Stakeholderanforderungen zu berücksichtigen, wurden für alle Anforderungen entsprechende Systemanforderungen im Lastenheft aufgenommen. Aufgrund der eingeschränkten Entwicklungszeit für die Erstversion der App wurde jedoch anschließend eine Priorisierung der Systemanforderungen durchgeführt, um den tatsächlich zu implementierenden Scope zu definieren.

Abbildung 1 stellt das beschriebene Vorgehensmodell noch einmal in einer Übersicht dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Vorgehensmodell in der Anforderungsanalyse

3.3 Anforderungsdefinition

3.3.1 Identifikation der Stakeholder

Da die „ParkSafe“-App nicht innerhalb eines Unternehmens oder auf Wunsch eines externen Auftraggebers entwickelt wird, ist der Autor prinzipiell der einzige Stakeholder der App und hat damit freien Handlungsspielraum. Da die App jedoch perspektivisch auch produktiv in Versicherungsunternehmen einsetzbar sein soll, wurden potenzielle Stakeholder durch ausgewählte Personengruppen „simuliert“, um möglichst realitätsnahe Bedingungen bei der Anforderungsdefinition zu erzeugen. Es wurden dabei drei verschiedene Personengruppen involviert: Umsetzungsexperten aus IT-Beratungshäusern, Fachexperten aus Versicherungen und potenzielle Endanwender, die weder einen versicherungsfachlichen noch einen IT-technischen Hintergrund aufweisen. Der Autor selbst verfügt als Mitarbeiter der „Business Technology Insurance“-Einheit bei Capgemini²⁷ über mehrjährige Erfahrung in der Entwicklung technologischer Lösungen für die Versicherungswirtschaft.

3.3.2 Brainstorming als Kreativitätstechnik

Die zu entwickelnde App soll keine bestehenden Prozesse abbilden oder ein bestehendes System ablösen. Zur Erhebung von Anforderungen können daher keine Techniken wie die Analyse von existierenden Dokumenten oder Modellen genutzt werden. Es ist ebenfalls nicht möglich, anhand von Interviews oder in Anforderungsworkshops einen Input von Stakeholdern zu bestehenden Prozessen und Funktionalitäten zu erhalten. Es müssen vielmehr neue Ideen erarbeitet werden, um daraus Funktionalitäten und Anforderungen an die „ParkSafe“-App abzuleiten. Da sich Brainstorming genau für diese Zielsetzung gut eignet, wurde diese Technik ausgewählt, um Ideen zu generieren, die in Form von Mindmaps dokumentiert wurden.²⁸

3.3.3 Brainstorming zur Erhebung der Grundfunktionalitäten

Ziel der ersten Brainstorming-Phase war eine high-level-Erhebung der Features, die die App unterstützen soll. Dazu wurde der grob geplante Lösungsumfang zu Beginn kurz skizziert und den Teilnehmern die folgenden Leitfragen als Orientierung gestellt:

„Welche spezifischen Funktionalitäten sind im Kontext der „ParkSafe“-App denkbar?“

„Welche nicht App-spezifischen Funktionalitäten werden benötigt?“

In mehreren Sessions mit jeweils unterschiedlichen Stakeholdergruppen wurden die gesammelten Ideen sukzessive erweitert. Im Ergebnis ist die Mindmap entstanden, die in Abbildung 2 dargestellt ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Mindmap Brainstorming zur Feature-Erhebung

3.3.4 Brainstorming zur Definition benötigter Use Cases

Der Fokus der zweiten Brainstorming-Phase lag auf der Identifikation verschiedener Use Cases, die durch die App unterstützt werden sollen. Da die Definition von UCs Vorwissen in diesem Bereich erfordert, wurden lediglich Umsetzungsexperten für dieses Brainstorming herangezogen. Ein Mindmap-Gerüst mit den verschiedenen Features diente als Ausgangspunkt. Im Ergebnis ist die Mindmap in Abbildung 3 entstanden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Mindmap Brainstorming zur UC-Identifikation

3.4 Anforderungsanalyse

3.4.1 Spezifikation funktionaler Systemanforderungen in einem Lastenheft

Wie zuvor erwähnt, wurden aus den identifizierten Stakeholder-Anforderungen im nächsten Schritt Systemanforderungen abgeleitet und in einem Lastenheft dokumentiert (siehe Anhang B). Für die Erstellung und den Aufbau dieses Dokumentes diente der Standard „IEEE Std 830-1998“²⁹ als Richtlinie.

Basierend auf der ersten Mindmap, wurde ein Grobentwurf für die App erstellt und die verschiedenen Funktionalitäten inklusive Mockup-Entwürfen wurden in Kapitel 2.1.1 des Lastenheftes beschrieben. Die Mindmap aus Abbildung 3 diente als Basis für die Detailspezifikation funktionaler Anforderungen in Form von Use Case-Beschreibungen in Kapitel 3.3 des Lastenheftes.

3.4.2 Spezifikation nicht-funktionaler Systemanforderungen in einem Lastenheft

Zur Definition nicht-funktionaler Systemanforderungen in Kapitel 3.4 des Lastenheftes wurde zusätzlich der Standard „ISO/IEC FDIS 9126-1“ als Orientierung herangezogen. Das hier enthaltene Qualitätsmodell beschreibt die folgenden sechs Hauptcharakteristika für die Softwarequalität:

1) Funktionalität
2) Zuverlässigkeit
3) Usability
4) Effizienz
5) Wartbarkeit
6) Portabilität

Diese Hauptcharakteristika sowie zugehörige Neben-Charakteristika haben die Leitlinie für die Spezifikation eigener nicht-funktionaler Anforderungen gebildet.³⁰

3.4.3 Priorisierung von Systemanforderungen

Da die App einen Showcase zur Verprobung der kritischsten und interessantesten Features darstellen soll, wurde eine User Journey³¹ definiert, die ebendiese beinhaltet. Der Anwender soll in dieser Journey in der Lage sein, die folgenden Schritte in der App zu durchlaufen:

1) Persönliche Daten eingeben und speichern
2) Gefahrencheck durchführen (Wetter-Risiken oder Geo-Risiken werden ermittelt)
3) Parken im Parkhaus wird empfohlen
4) Durchführung der Parkhaussuche
5) Navigation zu einem Parkhaus
6) Bestätigung der Parkhauseinfahrt
7) Aktualisierung der Bonuspunkte

Im Hinblick auf eine Machbarkeit in dem gegebenen Zeitrahmen wurden daher nicht alle im Lastenheft spezifizierten Use Cases umgesetzt. Vielmehr wurde im Sinne eines ersten lauffähigen Releases zunächst eine Bewertung der UCs anhand verschiedener Kriterien vorgenommen (siehe Tabelle 1).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Bewertung und Priorisierung definierter Use Cases

Für die Priorisierung wurden zunächst drei Kriterien definiert, anhand derer eine Bewertung der einzelnen UCs vorgenommen wurde. Die möglichen Ausprägungen sind „niedrig“ (Minus-Zeichen), „mittel“ (Null) und „hoch“ (Plus-Zeichen).

Das Kriterium „Attraktivität für User“ bewertet, wie hoch das fachliche Interesse an einem UC ist und ob dieser Funktionalitäten beinhaltet, die in gleicher oder ähnlicher Weise auch in vielen anderen Apps enthalten sein können, oder ob sie spezifisch für die „ParkSafe“- App sind. Die Bewertung ist anhand einer Befragung mehrerer Experten aus dem Versicherungsbereich erfolgt, inklusive der eigenen Einschätzung des Autors.

Das Kriterium „Komplexität der Umsetzung“ stellt eine grobe Kategorisierung des Aufwands für die Implementierung dar.

„Kritikalität für User Journey“ bewertet schließlich, wie wichtig ein Use Case für das erfolgreiche Durchlaufen der zuvor definierten User Journey ist.

Nach Bewertung aller Kriterien wurde eine vier-stufige Priorisierung nach der MoSCow³² -Methode vorgenommen. Die möglichen Prioritäten in absteigender Reihenfolge lauten dabei „Must“, „Should, „Could“ und „Won‘t“. Die Regeln, anhand derer die Priorisierung aus der Bewertung abgeleitet wurde, finden sich in Tabelle 2.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Regeln zur Ableitung von UC-Prioritäten anhand vorgenommener Bewertung

Am Ende dieses Bewertungsverfahrens sind 8 UCs mit der Priorität „Must“ bewertet worden, sodass der Fokus der Implementierung zunächst auf diese UCs gelegt wurde. 7 weitere UCs mit der Priorität „Should“ wurden im direkten Anschluss bearbeitet und konnten ebenfalls alle umgesetzt werden. 15 UCs mit der Priorität „Could“ und „Won‘t“ wurden von der Implementierung ausgeschlossen und stellen potenzielle Anforderungen für zukünftige Releases dar.

In den nachfolgenden Kapiteln wird die Implementierung der umgesetzten UCs im Detail beschrieben.

4 Prototyp-Entwicklung

4.1 Überblick zum Kapitel

Wie in Kapitel 1.3 bereits erwähnt, wurde vor der eigentlichen Implementierung ein Prototyp entwickelt. Auf diese Weise wurde verprobt, ob für die im Lastenheft spezifizierten Anforderungen eine grundsätzliche technische Machbarkeit für den gegebenen Zeitrahmen von sechs Monaten erfüllt ist. Im Folgenden wird daher näher beschrieben, wie die Implementierung des Prototyps aufgebaut war und welcher Umfang an Funktionalitäten verprobt wurde.

4.2 Zweck des Prototypen

Für die Umsetzung des Prototypen wurden zwei UCs gewählt, die sowohl technisch komplex als auch für die definierte User Journey von hoher Bedeutung sind (vgl. 3.4.3). Für den Wetter-Gefahrencheck (UC016) ist die Abfrage von Daten über das Netzwerk sowie das Parsen von JSON-Files erforderlich. Für den Geo-Gefahrencheck (UC017) wird eine Kommunikation mit der Google Firestore-Datenbank benötigt. Damit decken diese UCs wesentliche komplexe Funktionalitäten der App ab, die auch an verschiedenen anderen Stellen benötigt werden.

4.3 Prototyp GUI

Aus bereits genannten Gründen ist die GUI des Prototypen sehr einfach gehalten und besteht lediglich aus einer Activity mit zwei Buttons und zwei TextViews, die die folgenden Funktionen erfüllen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: GUI Design des Prototypen

In Abbildung 5 findet sich ein Screenshot von dem Prototypen vor der Durchführung eines Gefahrenchecks. Die beiden TextViews zeigen initial die Platzhalter-Labels für Warnungen an. Die Anzeige in der linken Textview stellt einen Text aus der Abfrage des Wetter-Forecasts dar, sofern diese Daten ermittelt werden können. Die rechte Textview zeigt eine Meldung, ob Geo-Warnungen für den aktuellen Standort ermittelt wurden. Abbildung 4 zeigt den Zustand, nachdem Wetter-Daten abgefragt wurden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Prototyp-GUI nach Durchführung Wetter-Check

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Prototyp-GUI im Initialzustand

4.4 Prototyp-Architektur/Klassendiagramm

Da der Fokus bei dem Prototypen auf einer möglichst schnell erreichbaren und wenig aufwändigen „Wegwerf“-Lösung lag, wurde die Strukturierung des Codes vernachlässigt. Der Code ist daher hauptsächlich in einer Klasse MainActivity implementiert, die die Activity darstellt, die beim Start der App aufgerufen wird. Alle benötigten Methoden sind in dieser Klasse implementiert. Daneben wird noch eine Hilfsklasse WeatherInformation zur Datenhaltung von Wetter-Daten verwendet. Die Auslagerung von Hintergrundaktivitäten wurde durch die Definition der beiden inneren AsyncTask-Klassen AsyncTaskLocation und AsyncTaskParsing auch im Prototypen bereits berücksichtigt. Das zugehörige Klassendiagramm ist in Abbildung 6 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Klassendiagramm ParkSafe-Prototyp

4.5 Implementierte Use Cases

4.5.1 UC016: Wetter-Daten prüfen

Wie in 4.1 bereits erwähnt, stellt UC016 einen der beiden komplexen UCs dar, die verprobt werden sollen. Im Kontext von diesem UC sollen primär der technische Abruf der Wetterdaten über eine API von openweathermap.org sowie das Parsen der im JSON-Format erhaltenen Daten verprobt werden. Es wird daher lediglich der Wetter-Forecast für die nächsten sechs Stunden abgefragt und in einer TextView angezeigt. Dabei erfolgt keine weitere Auswertung der Ergebnisse, um z.B. ausschließlich kritische Wettermeldungen zu identifizieren, wie es im Zielszenario benötigt wird. Der Ablauf ist dabei wie folgt:

1. Nach einem Klick auf den Button „Start Wetter-Check“ wird in der Methode startWeatherCheck() ein Objekt der Klasse AsyncTaskLocation erzeugt. Diese Klasse wird verwendet, um die Logik für die Bestimmung der Standort-Koordinaten in der doInBackground()-Methode zu implementieren und diese somit in einen separaten Worker-Thread auszulagern (da die Ermittlung der Standort-Koordinaten unter Verwendung von GPS potenziell länger andauern kann).
2. Nach Rückkehr des Worker-Threads wird anschließend in der onPostExcecute()-Methode ein Request an openweathermap.org gestartet, um ein JSONObject mit Wetterdaten zu erhalten. Für den Request wird die http-Library „Volley“³³ genutzt.
3. Sobald das JSONObject über eine onResponse()-Callback Methode erhalten wurde, wird wiederum ein Worker-Thread über ein Objekt der Klasse AsyncTaskParsing gestartet. In dieser Klasse ist die ebenfalls potenziell länger andauernde Logik für das Parsen des JSONObjects ausgelagert.
4. Die onPostExcecute()-Methode dieser Klasse erhält lediglich ein Objekt der Hilfsklasse WeatherInformation, aus der eine Wetter-Warnung als String entnommen werden kann, um sie schließlich in der GUI anzuzeigen.

Abbildung 7 visualisiert den Ablauf noch einmal in einem Sequenzdiagramm.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Sequenzdiagramm der Implementierung „UC016:Wetterdaten prüfen“ im Prototyp

4.5.2 UC017: Geofence-Daten prüfen

Für den Geo-Gefahrencheck sollen primär die Konfiguration sowie die Anbindung an eine Google Firestore-Datenbank verprobt werden. Daher werden hier „hardcodierte“ Standortdaten verwendet, um bei der Suche nach einem Geofence in der Firestore-Datenbank mit Sicherheit den konfigurierten Werten zu entsprechen und eine Warnung anzuzeigen. Im Zielszenario werden die jeweils aktuellen Standorte zur Laufzeit ermittelt und basierend darauf ein Geofence in der Datenbank gesucht. Für die Anfragen an die Geofence-Datenbank wird die Cloud Firestore API³⁴ verwendet. Auch hier soll der Ablauf der einzelnen Schritte kurz beschrieben werden:

1. Nach einem Klick auf den Button „Start Geo-Check“ wird in der Methode startGeoCheck(), unter Nutzung der Cloud-Firestore API, ein Request auf das Dokument „geofence01“ in der Collection „Germany“ gestartet.
2. In einem OnCompleteListener wird beim Empfang der Antwort die Methode validateGeoPosition() aufgerufen, in der die Logik zum Vergleich der statischen Standortdaten mit den Standortdaten im Test-Geofence implementiert ist.
3. Da aufgrund der Dummy-Standortdaten immer ermittelt wird, dass der Standort innerhalb eines Geofences liegt, wird in einer TextView eine Meldung über identifizierte Geo-Warnungen angezeigt.

Der beschriebene Ablauf ist auch noch einmal in Abbildung 8 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Sequenzdiagramm der Implementierung „UC017: Geofence-Daten prüfen“ im Prototyp

4.6 Schnittstellen

4.6.1 Cloud Firestore Geofence-Datenbank

Wie im Lastenheft beschrieben (vgl. Kapitel 2.1.3.4 des Lastenhefts), soll zur Ermittlung von Risiken an einem aktuellen Standort eine Datenbank aufgesetzt werden, die verschiedene Geofences innerhalb Deutschlands enthält. Durch einen Abgleich der Geofence-Daten mit dem aktuellen Standort kann ermittelt werden, ob Letzterer innerhalb eines Geofences liegt.

Für den Prototyp wurde eine separate Cloud Firestore-Datenbank „ParkSafePrototypDB“ aufgesetzt. Dabei handelt es sich um eine NoSQL Cloud-Datenbank, in der die Daten als „Collections“ und „Documents“ hierarchisch strukturiert werden können. Documents müssen dabei stets in einer Collection enthalten sein und können nicht die Wurzel der Hierarchie bilden.³⁵ Zur Verprobung wurde daher eine einzelne Collection „Germany“ mit einem einzelnen Document „geofence01“ angelegt. Das Document soll einen existierenden Geofence repräsentieren und erhält daher die in Abbildung 9 dargestellten Informationen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Datenmodell ParkSafePrototypDB

Ein Geofence ist somit als Viereck modelliert, dessen Kanten sich durch ein definiertes Zentrum (die Koordinaten latitude/longitude) und den Wert des radius ergeben (siehe Abbildung 10).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Geofence als Viereck mit Koordinaten (49, 5) im Zentrum

4.6.2 Wetterdaten von openweathermap.org

Für Wetter-Warnungen benötigte Wetterdaten sollen über eine Schnittstelle von openweathermap.org abgefragt werden. In der kostenfreien Version stehen Daten für einen Forecast zu den nächsten 18 Stunden, unterteilt in 3-Stunden-Blöcke, zur Verfügung. Diese können über http-Requests abgefragt werden und werden im JSON-Format geliefert. Die JSON-Datei enthält eine Liste mit 6 Objekten, die jeweils die Wetterdaten für einen 3-Stunden-Block enthalten. Nachfolgend ist ein Auszug dieser Datei mit einem Objekt dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Die Daten, die für die Warnmeldungen genutzt werden sollen, finden sich in dem weather-Array. Es handelt sich um die id, die einen Code für den Wetterstatus bereitstellt, sowie die description, eine Kurzbeschreibung als Text. In der Implementierung wird die id geprüft und die Beschreibung als Teil der Warnmeldung verwendet.

4.7 Bewertung des Prototypen

Beim Start der Implementierung des Prototypen wurde zunächst noch offen-gelassen, in welcher Form die Ergebnisse weiterverwendet werden. Da es sich um einen vertikalen Prototypen handelte, bei dem der Fokus auf der möglichst umfänglichen Verprobung technisch komplexer Komponenten liegt, hat die GUI des Gesamtsystems eine nachrangige Rolle gespielt und war daher nur sehr rudimentär vorhanden. Auch die Architektur der App wurde zunächst sehr nachrangig betrachtet, um möglichst schnell die definierten Funktionalitäten verproben zu können. Es wurde daher entschieden, keinen evolutionären Ansatz für den Prototyp zu verfolgen, bei dem dieser das Grundgerüst für die spätere App im Sinne einer ersten Version des zu entwickelnden Systems darstellt.³⁶ Vielmehr sollten die erarbeiteten Lösungsansätze und Techniken für die spätere Umsetzung wiederverwendet werden.

Eine erfolgreiche erste Implementierung des Prototypen konnte auf diese Weise in einem Zeitraum von ca. vier Wochen erreicht werden. Die gewonnenen Erfahrungen aus der Entwicklung von komplexen Funktionalitäten, wie z.B. der Kommunikation mit Cloud Firestore-Datenbanken, haben die Grundlage für eine Abschätzung potenzieller Aufwände für weitere Entwicklungen in ähnlichen Kontexten gebildet. Unter Betrachtung der umzusetzenden UCs und der dazu benötigten Funktionalitäten konnte für den Gesamtzeitraum von zwei Monaten eine prinzipielle Machbarkeit bestätigt werden.³⁷

5 Implementierung

5.1 Überblick zum Kapitel

In diesem Kapitel soll die eigentliche Implementierung der App beschrieben werden, die im Anschluss an die Entwicklung des Prototypen durchgeführt wurde. Wie bereits erwähnt, konnten einzelne Codeteile aus dem Prototypen wiederverwendet werden. Die eigentliche App wurde jedoch als neues Android-Studio-Projekt aufgesetzt, für das eine Architektur und ein Entwurfsmuster definiert sowie ein Klassenmodell entwickelt wurden. Diese Aspekte sowie die von ihrer Bedeutung und Komplexität her kritischsten Klassen der App sollen im Folgenden näher erläutert werden. Daneben werden die involvierten Schnittstellen jeweils kurz charakterisiert.

5.2 Architektur

5.2.1 MainActivity und Layout

Beim Start der App wird eine MainActivity gestartet, die von AppCompatActivity abgeleitet und mit einem DrawerLayout gestaltet ist. Innerhalb dieses Layouts werden weitere Komponenten aus der android.material³⁸ -Bibliothek eingesetzt. Es beinhaltet eine NavigationView, die ein ein- und ausklappbares Menü auf der linken Seite darstellt. Ein AppBarLayout bildet eine Kopfzeile bzw. einen Headerbereich, der immer sichtbar ist und eine Überschrift zu dem aktuell angezeigten Content beinhaltet. Der Bereich unter dem Header stellt den Contentbereich zur Darstellung der App-Inhalte dar und wird durch ein FrameLayout repräsentiert. Bei der Initialisierung der MainActivity wird ein Fragment zur Anzeige der „Gefahrenübersicht“ in dem FrameLayout platziert. Beim Wechsel auf einen anderen Menüpunkt über das Seitenmenü kann das Fragment durch ein anderes Fragment der jeweils zugehörigen Funktionalität ersetzt werden. Insgesamt wird die App daher durch eine Activity und vier Fragments repräsentiert (für die Menüpunkte „Gefahrenübersicht“, „Parkhaussuche“, „Persönliche Daten“ und „Bonusübersicht“). Abbildung 11 stellt die Architektur und das Zusammenspiel der verschiedenen Komponenten noch einmal in einer Übersicht dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: App-Architektur inklusive Activity und Fragments

5.2.2 Entwurfsmuster

Wie in 5.2.1 bereits erwähnt, besteht die App insgesamt aus vier Fragments, die verschiedene Oberflächen/Funktionen repräsentieren, die über das Seitenmenü aufrufbar sind. Um für jedes Fragment die Verantwortlichkeiten zwischen der grafischen Anzeige, der Reaktion auf Benutzereingaben und der fachlichen Logik/Datenhaltung in verschiedene Klassen aufzuteilen, wurde für jedes Fragment das Entwurfsmuster MVC³⁹ (Model-View-Controller) eingesetzt. Eine von Fragment abgeleitete Klasse stellt dabei jeweils die View dar und zwei separat definierte Klassen das Model und den Controller.

Die View hält eine Referenz auf das Model und wird bei Änderungen des Models über eine fireXxModelChanged-Methode benachrichtigt. Als Reaktion kann sie über weitere Methoden GUI-Elemente mit Hilfe der Daten aus dem Model aktualisieren.

Der Controller besitzt eine Referenz auf das Model und stellt lediglich Methoden zur Änderung des Models bereit. Der Controller ist als Listener an den Views/Fragments registriert und hat jeweils die Schnittstellen-Methode onClick() implementiert, in der in Abhängigkeit des auslösenden GUI-Elementes entschieden wird, welche weiteren Controller-Methoden bzw. Methoden im Model aufgerufen werden.

Das Model enthält die Daten, die zur Anzeige benötigt werden bzw. Referenzen auf weitere Objekte, die die eigentlichen Daten enthalten. Weiterhin enthält es Methoden zur Aktualisierung/Änderung der Daten, insbesondere auch für Netzwerkzugriffe. In diesem Kontext wurden weitere Hilfs-Klassen entsprechend der verschiedenen beteiligten Entitäten und benötigten Funktionalitäten definiert. Darüber hinaus wird der Ansatz eines „aktiven“ Models verfolgt, d. h. die Daten des Models sind nicht ausschließlich über den Controller änderbar, sondern auch über andere Klassen (z.B. kann die Hilfs-Klasse WeatherJsonParserAsyncTask nach dem erfolgreichen Parsen von Wetter-Daten die Daten im RiskOverviewModel aktualisieren).

Um potenziell mehrere Views gleichzeitig über Änderungen in einem Model zu benachrichtigen, wurde daneben jeweils eine ModelListener-Schnittstelle definiert, die von dem Model implementiert wird. Zusammengefasst kann der Ablauf bei einer Benutzeraktion daher wie folgt beschrieben werden:

1) Nutzer führt Aktion über GUI-Element in einem Fragment aus.
2) onClick()-Methode wird im Controller aufgerufen, der als Listener registriert ist.
3) Aus onClick() heraus werden weitere Controller-Methoden oder Model-Methoden zur Änderung von Daten im Model aufgerufen.
4) Model benachrichtigt View (d. h. Fragment) über die Änderung in fireXxModelChanged()-Methode.
5) View aktualisiert GUI-Elemente.

Eine High-Level Darstellung des zugehörigen Klassendiagramms findet sich am Beispiel des RiskOverviewFragments in Abbildung 12.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Klassendiagramm MVC-Entwurfsmuster am Beispiel RiskOverviewFragment

5.2.3 Worker Threads

Um die GUI durch länger andauernde Tätigkeiten nicht zu blockieren, werden diese in Worker-Threads ausgelagert. Dies betrifft insbesondere Standort-Abfragen, Anfragen an die Firestore-Datenbank sowie weitere Netzwerkanfragen und die Verarbeitung der Ergebnisse.

Da an verschiedenen Stellen JSON-Objekte von unterschiedlichen Quellen über das Netzwerk abgefragt werden müssen, wird die speziell dafür ausgelegte Android-Volley-Bibliothek⁴⁰ eingesetzt, die diese Requests automatisch in separate Threads auslagert. Zur Vorbereitung von Netzwerkanfragen sowie zur Verarbeitung der Ergebnisse wurden verschiedene von AsyncTask abgeleitete Klassen eingesetzt, die die jeweils benötigten Logiken beinhalten. Letztere werden in 5.4.2 noch im Detail erläutert.

5.2.4 Strukturierung der Anwendung in Packages

Um die Anwendung übersichtlich zu strukturieren, wurden die Klassen in Abhängigkeit der zugehörigen Verantwortlichkeiten in verschiedene Packages aufgeteilt. Es wurden daher insgesamt acht Packages definiert, die im Folgenden näher erläutert werden sollen:

1) de.parksafe.mainActivity
2) de.parksafe.models
3) de.parksafe.fragments
4) de.parksafe.controllers
5) de.parksafe.modelListeners
6) de.parksafe.helperClasses
7) de.parksafe.jsonParser
8) de.parksafe.asyncTasks

Das erste Package de.parksafe.mainActivity beinhaltet die MainActivity-Klasse, in der u. a. die verschiedenen MVC-Komponenten initialisiert werden. Daneben ist noch eine weitere Klasse MyMultiDexApplication enthalten, die lediglich dazu dient, Multidex⁴¹ für die App zu aktivieren.

In den Packages de.parksafe.models, de.parksafe.fragments, de.parksafe.controllers und de.parksafe.modelListeners sind die jeweils den MVC-Komponenten zugehörigen Klassen enthalten (siehe 5.2.2).

Hilfsklassen, die zur Abbildung komplexer Datentypen dienen (z.B. BonusUser) oder Methoden zu einem bestimmten Themengebiet bündeln (z.B. FirestoreDBOperations), finden sich in dem Package de.parksafe.helperClasses.

Da das Parsen von JSON-Files eine komplexere Logik umfasst und für verschiedene File-Typen unterschiedliche Parser definiert wurden, sind diese in einem eigenen Package de.parksafe.jsonParser zusammengefasst.

Das Package de.parksafe.asyncTasks beinhaltet schließlich alle von AsyncTask abgeleitete Klassen, die für verschiedene Hintergrundtätigkeiten eingesetzt werden (vgl. 5.2.3).

5.3 Objektorientierter Entwurf

5.3.1 Klassenmodell

In dem vorangegangenen Kapitel wurde die Strukturierung der verschiedenen Klassen anhand der Definition der Packages bereits grob beschrieben. Im Folgenden findet sich nun eine Visualisierung des vollständigen Klassenmodells. Zur Verbesserung der Übersichtlichkeit und Lesbarkeit wurden verschiedene Vereinfachungen angewendet. Zunächst wurde das Modell in mehrere Klassendiagramme aufgeteilt. Hinsichtlich der Assoziationen zwischen den Klassen wurden diese nur abgebildet, wenn es sich um Assoziationen zwischen selbst definierten Klassen handelt. Assoziationen zu Klassen aus Android-/Java-Bibliotheken wurden hingegen nicht modelliert. Lediglich Vererbungs- und Implementierungsbeziehungen zu solchen Klassen wurden teilweise dargestellt. Darüber hinaus wurden alle Konstruktoren, Getter- und Setter-Methoden in den Klassen weggelassen.

Das Klassendiagramm in Abbildung 13 enthält zunächst die MVC-Klassen zur Bonusübersicht und den persönlichen Daten im Detail. Beziehungen wurden nur zwischen den dargestellten Klassen modelliert. Weitere Beziehungen - z. B. zu Hilfs- oder Oberklassen - wurden zur Vereinfachung nicht abgebildet. In Abbildung 14 sind die MVC-Klassen zur Gefahrenübersicht und der Parkhaussuche dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Klassendiagramm MVC-Komponenten zu Bonusübersicht und persönliche Daten

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Klassendiagramm MVC-Komponenten zu Gefahrenübersicht und Parkhaussuche

[...]

---

¹ Es wurden insgesamt 10 Apps aus dem deutschen Versicherungsmarkt verglichen. Eine detaillierte Beschreibung der Funktionalitäten befindet sich im Anhang.

² Das IoT beschreibt Netzwerke, innerhalb derer physische Objekte mit ihrer Umgebung kommunizieren und interagieren. [Vgl. (Gartner, 2019)].

³ Siehe Erläuterung der Begrifflichkeit in Kapitel 2.1.

⁴ Vgl. (Cummings, 2017)

⁵ Vgl. (Rhode, 2019)

⁶ Obwohl es sich um keine App mit dem Ziel der Produktionsreife handelt, wird im Rahmen dieser Arbeit zur Vereinfachung häufig der Begriff „App” anstatt „Showcase” oder „Prototyp” verwendet.

⁷ Das Wasserfallmodell ist ein sequenzielles Vorgehensmodell in mehreren definierten Phasen. [Vgl. (Royce, 1970)]

⁸ Vgl. (Boehm, 2002, S. 68)

⁹ Ein vertikaler Prototyp bzw. ein „technischer Durchstich“ verprobt einen Teil eines Systems über alle Schichten der Architektur hinweg. Im Gegensatz dazu bildet ein horizontaler Prototyp lediglich einen Teil der Architektur jedoch möglichst vollständig ab, z.B. die GUI eines Systems. [Vgl. (Balzert, 2009, S. 79 ff.)]

¹⁰ Vgl. (Wagner, Definition, 2018)

¹¹ Vgl. (Wagner, Kfz-Kaskoversicherung, 2018)

¹² Vgl. (Wagner, Kfz-Haftpflichtversicherung, 2018)

¹³ Vgl. (Wagner, Definition Prämie, 2018)

¹⁴ Vgl. (Aschenbrenner, Dicke, Karnarski, & Schweiggert, 2010, S. 236)

¹⁵ Vgl. (Statista, Marktanteile von Android und iOS, 2019)

¹⁶ Vgl. (Google, Add Firebase to your Android, 2019)

¹⁷ Vgl. (Statista, Android, 2019)

¹⁸ Java SE steht für die Java Standard Edition, die mittlerweile in Version 13 von Oracle herausgeben wird. [Vgl. (Oracle, 2019)]

¹⁹ Vgl. (Google, Package Index | Android Developers, 2019)

²⁰ Android Studio basiert auf IntelliJ IDEA und ist die offizielle Entwicklungsumgebung für Android. [Vgl. (Google, Meet Android Studio | Android, 2019)]

²¹ Vgl. (Google, Introduction to Activities, 2019)

²² Vgl. (Forrester, 2019)

²³ Vgl. (Google, Cloud Firestore, 2019)

²⁴ Vgl. (White, 2017)

²⁵ Der Standard wurde gemeinsam von den drei Organisation ISO, IEC und IEEE entwickelt und enthält empfohlene Vorgehensweisen und Techniken für das Requirements Engineering. [Vgl. (ISO/IEC/IEEE 29148 2011, 2011)]

²⁶ Vgl. (ISO/IEC/IEEE 29148 2011, 2011, S. 9)

²⁷ Die Capgemini Deutschland GmbH gehört zu den Top 5 IT-Beratungs- und Systemintegrations-Unternehmen in Deutschland. [Vgl. (Lünendonk-Liste 2019, 2019)]

²⁸ Vgl. (Clark, 1972, S. 49 ff.)

²⁹ Der Standard beschreibt eine vom IEEE (Institute of Electrical and Electronics Engineers) empfohlene Struktur für die Erstellung von Lastenheften. [Vgl. (IEEE, 830-1998 - Recommended Practice for Software Requirements Specification, 1998)]

³⁰ Der Standard beschreibt eine gemeinsam von der ISO (International Organization for Standardization) und der IEC (International Electrotechnical Commission) herausgegebene Empfehlung zur Beschreibung von Software-Qualität. [Vgl. (ISO/IEC, 2000)]

³¹ Unter einer User Journey soll in diesem Kontext ein möglicher Pfad durch verschiedene Dialoge der App verstanden werden, den ein User bei der Nutzung der App durchlaufen kann.

³² Die MoSCoW Methode ist eine Technik zur Priorisierung von Anforderungen in Abhängigkeit von ihrer Wichtigkeit. [Vgl. ( (Wiegers & Beatty, 2013, S. 320-321)]

³³ Vgl. (Google, Volley overview | Android Developers, 2019)

³⁴ Vgl. (Google, com.google.firebase.firestore | Firebase, 2019)

³⁵ Vgl. (Google, Google – Cloud Firestore Data model | , 2019)

³⁶ Vgl. (Balzert, 2009, S. 79 ff.)

³⁷ Basierend auf den IST-Aufwänden, die für die Entwicklung des Prototypen angefallen sind, wurde eine Aufwandsschätzung für die Umsetzung der in 3.4.3 priorisierten UCs erstellt. Diese Schätzung hat eine Machbarkeit für den reinen Implementierungszeitraum von zwei Monaten bzw. eine verfügbare Kapazität von 25 Personentagen (PT) ergeben. Detaillierte Informationen dazu finden sich im Anhang.

³⁸ Vgl. (Google, Material Design, 2019)

³⁹ Das Entwurfsmuster MVC beschreibt eine Aufteilung der Klassen in Abhängigkeit ihrer Verantwortlichkeiten in die Komponenten „Model“, „View“ und „Controller“. [Vgl. (Vlissides, Johnson, Helm, & Gamma, 1994, S. 14 ff.)]

⁴⁰ Vgl. (Google, Volley overview | Android Developers, 2019)

⁴¹ Multidex wird benötigt, wenn eine App und Ihre referenzierten Libraries mehr als 65.536 Methoden beinhalten. [Vgl. (Google, Enable multidex for apps, 2019)]