Universität Ulm | 89069 Ulm | Germany Fakultät für
Ingenieurwissenschaften,
Informatik und
Psychologie
Institut für Datenbanken
und Informationssysteme
Konzeption und Realisierung einer
Web-Plattform zur Veröffentlichung und
Bereitstellung digitaler Fragebögen
Masterarbeit an der Universität Ulm
Vorgelegt von:
Lars Miltkau
Gutachter:
Prof. Dr. Manfred Reichert
Dr. Rüdiger Pryss
Betreuer:
Johannes Schobel
2018
Fassung 6. Juni 2018
c
2018 Lars Miltkau
This work is licensed under the Creative Commons. Attribution-NonCommercial-ShareAlike 3.0
License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/de/
or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California,
94105, USA.
Satz: PDF-L
A
TEX2ε
Kurzfassung
Digitale Fragebögen fangen durch die Entwicklung immer besserer Systeme langsam an
Papierfragebögen zu verdrängen. Dazu trägt auch die immer stärkere Verbreitung von
mobilen Geräten wie Smartphones bei, da dadurch die Zahl an potentiellen Teilnehmern
einer Studie steigt. Das Projekt QuestionSys nutzt diesen Zustand und weitere Vorteile
digitaler Fragebögen aus und setzt auf ein System um digitale Fragebögen für mobile
Geräte zu erstellen, verteilen, ausfüllen, analysieren und zu archivieren. QuestionSys
verfügt dabei über Möglichkeiten Fragebögen zur Bearbeitung an verschiedene Geräte
zu verteilen. Erstellte Fragebögen können aber nicht direkt veröffentlicht und so anderen
Nutzern für eigene Zwecke, wie zum Beispiel eigene Umfragen zugänglich gemacht
werden.
Das Ziel dieser Arbeit ist daher die Entwicklung einer Web-Plattform, mit der digitale
Fragebögen veröffentlicht und bereitgestellt werden können. Zu diesem Zweck wird ein
Shop entwickelt, in den Nutzer Fragebögen einstellen können. Andere Nutzer sollen die-
se Fragebögen dann käuflich erwerben können. Dazu soll ein Monetarisierungskonzept
erstellt und anschließend im Shop umgesetzt werden.
iii
Danksagung
An dieser Stelle möchte ich mich bei allen bedanken, die mich während der Anferti-
gung dieser Masterarbeit unterstützt haben. Zuerst möchte ich mich beim Institut für
Datenbanken und Informationssysteme der Universität Ulm bedanken, bei denen ich
diese Abschlussarbeit geschrieben habe. Ein besonderer Dank gebührt meinem Betreu-
er Johannes Schobel, der immer als Ansprechpartner zur Verfügung stand und mich
ausgiebig unterstützt hat. Des Weiteren gilt mein Dank meinen Kommilitonen, die mir mit
ihrer Motivation und Hilfsbereitschaft während des Studiums zur Seite standen. Abschlie-
ßend möchte ich meiner Familie danken, die mir mein Studium durch ihre Unterstützung
ermöglicht haben.
v
Inhaltsverzeichnis
1 Einleitung 1
1.1 Zielsetzung ................................... 2
1.2 StrukturderArbeit ............................... 2
2 Grundlagen 3
2.1 QuestionSys .................................. 3
2.1.1 Konfigurator............................... 4
2.1.2 Client .................................. 5
2.1.3 Server.................................. 5
3 Verwandte Arbeiten 7
3.1 LimeSurvey................................... 7
3.2 SurveySystem................................. 9
3.3 QuestionPro .................................. 10
3.4 GooglePlayStore ............................... 12
3.5 Vergleich .................................... 13
4 Anforderungen 19
4.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 20
5 Konzept 23
5.1 Ansätze zur Veröffentlichung digitaler Fragebögen . . . . . . . . . . . . . 23
5.2 Ansätze zur Monetarisierung digitaler Fragebögen . . . . . . . . . . . . . 24
5.3 Das entstandene Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3.1 Darstellung der Fragebögen . . . . . . . . . . . . . . . . . . . . . . 26
5.3.2 Nutzerrollen............................... 29
6 Implementierung 33
6.1 verwendete Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.1 Angular5................................ 33
vii
Inhaltsverzeichnis
6.1.2 INSPINIA Admin Theme . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Implementierung verschiedener Komponenten . . . . . . . . . . . . . . . 34
6.2.1 Service ................................. 34
6.2.2 Module ................................. 40
6.3 AufbaudesShops ............................... 41
6.3.1 Shop................................... 41
6.3.2 Home .................................. 46
6.3.3 Management.............................. 47
7 Zusammenfassung 49
7.1 Ausblick..................................... 50
viii
1
Einleitung
In der heutigen Zeit der Digitalisierung ist es immer noch üblich Papierfragebögen
zur Datenerhebung bei Umfragen oder Studien einzusetzen. Die Fragebögen müssen
dabei per Hand ausgeteilt und wieder eingesammelt werden. Dies stellt im Vergleich
zu digitalen Fragebögen einen deutlichen Mehraufwand dar. Zusätzlich müssen diese
Fragebögen zur Analyse nachträglich digitalisiert werden [1].
Die immer stärkere Verbreitung von mobilen Geräten wie Smartphones macht digitale
Fragebögen zunehmend interessanter, da dadurch die Zahl potentieller Teilnehmer
steigt. Zudem ist das Ausfüllen von Fragebögen auf dem Smartphone im Vergleich zu
Papierfragebögen deutlich bequemer und vom Ort unabhängig. Digitale Fragebögen
haben zudem den Vorteil, dass sie einfacher und in größeren Mengen verteilt und
ausgewertet werden können.
An der Universität Ulm wird mit QuestionSys ein System entwickelt, mit dem digitale
Fragebögen für mobile Geräte erstellt, verteilt, ausgefüllt, analysiert und anschließend
archiviert werden können. Dadurch werden alle Vorteile von digitalen Fragebögen
ausgenutzt [2].
Das Verteilen von digitalen Fragebögen dient meistens dazu, den Fragebogen an einen
entsprechenden Teilnehmer zu senden. Eine weitere Möglichkeit wäre jedoch den
Fragebogen vom Ersteller zu einem beliebigen Käufer zu senden. Da Käufer allerdings
schwierig zu finden sind, wäre es einfacher den Fragebogen auf einer Web-Plattform
bereitzustellen. Eine solche Plattform hat den Vorteil, dass Personen, die einen bereits
fertigen Fragebogen für eigene Umfragen oder Studien suchen, direkt einen Anhaltspunkt
haben. Zusätzlich ermöglicht dieser Ansatz die Wiederverwendbarkeit von Fragebögen.
Zum Beispiel wenn eine Person einen Fragebogen erstellt und anschließend eine Studie
1
1 Einleitung
durchführt, kann diese Person nach Abschluss dieser, den Fragebogen veröffentlichen
und Benutzern der Plattform die Möglichkeit geben den Fragebogen für eigene Zwecke
zu nutzen. Dies führt zu Zeitersparnissen, da das Erstellen des Fragebogens wegfällt.
1.1 Zielsetzung
Das Ziel dieser Masterarbeit ist die Entwicklung einer Web-Plattform zur Veröffentlichung
und Breitstellung von digitalen Fragebögen im Rahmen des Projektes QuestionSys. Dazu
soll eine Shop Anwendung geschrieben werden, in die Nutzer Fragebögen einstellen
sowie erwerben können. Die Fragebögen sollen dann in verschiedenen Kategorien
darstellbar sein. Zusätzlich soll für die Fragebögen ein Monetarisierungskonzept erstellt
und dieses in den Shop eingebaut werden. Der Shop soll zudem mit dem Server des
QuestionSys Projektes verbunden sein.
1.2 Struktur der Arbeit
Diese Arbeit ist in sechs weitere Kapitel eingeteilt. In Kapitel 2 werden die Grundlagen
der Arbeit beschrieben. In Kapitel 3 werden bereits existierende Fragebogensysteme
und die verwendeten Monetarisierungskonzepte angeschaut. Kapitel 4 beschreibt die
funktionalen und nicht-funktionalen Anforderungen des Shops. Das Konzept wird in
Kapitel 5 eingeführt. Dazu werden allgemeine Ansätze zur Veröffentlichung und Mone-
tarisierung digitaler Fragebögen aufgeführt, sowie das Monetarisierungskonzept des
Shops vorgestellt. In Kapitel 6 wird die Implementierung des Shops beschrieben. Mit
Kapitel 7 wird die Arbeit abgeschlossen. Dazu wird ein kurzes Fazit mit Blick auf die
Anforderungen gezogen, sowie ein Ausblick auf zukünftige Erweiterungen geworfen.
2
2
Grundlagen
In diesem Kapitel werden die Grundlagen der Arbeit vorgestellt. Dazu wird das System
QuestionSys beschrieben.
2.1 QuestionSys
QuestionSys ist ein System für digitale Fragebögen. Es wird dafür entwickelt, dass
Experten wie Psychologen oder Mediziner auch ohne Programmierkenntnisse digitale
Fragebögen erstellen, sowie auf mobilen Geräten Daten sammeln können [
3
]. Gestartet
wurde das Projekt 2013 an der Universität Ulm [4].
In Abbildung 2.1 ist der Lebenszyklus eines digitalen Fragebogens zur Sammlung
von mobilen Daten dargestellt. QuestionSys unterstützt den kompletten Zyklus mit ver-
schiedenen Anwendungen. Der Lebenszyklus besteht aus fünf Phasen. In der ersten
Phase, der Designphase wird der Fragebogen erstellt, bevor er in der nächste Phase
auf verschiedene mobile Geräte verteilt wird. Dort werden die Fragebögen dann in der
Enactment & Execution Phase bearbeitet und ausgeführt. In der vierten Phase werden
die erhaltenen Daten in Echtzeit analysiert. In der letzten Phase können die Fragebögen
archiviert und versioniert werden [5, 6].
QuestionSys benutzt einen modellbasierten Ansatz zum grafischen Erstellen der Frage-
bögen. Dieser wird dann durch ein spezielles Mapping in ein prozessorientiertes Modell
transformiert [
6
]. Umgesetzt werden die Phasen des Lebenszyklus bei QuestionSys
3
2 Grundlagen
Abbildung 2.1: Lebenszyklus zur Erhebung mobiler Daten [4, 5, 6]
durch drei Komponenten (Konfigurator, Client, Server). Diese Komponenten sind in
Abbildung 2.2 dargestellt und im Folgenden beschrieben.
Abbildung 2.2: Komponenten des Fragebogensystems QuestionSys
2.1.1 Konfigurator
Im Konfigurator können die Fragebögen erstellt werden. Dazu stehen verschiedene
Elemente zur Verfügung, die mit Drag & Drop kombiniert werden können. Zusätzlich
4
2.1 QuestionSys
ermöglicht der Konfigurator die Versionierung der Fragebögen. Am Ende kann der
Fragebogen als prozessorientiertes Modell zum Server geschickt werden [7].
2.1.2 Client
Der Client ist für die Erhebung der Daten zuständig. Dabei können viele verschiedene
Clients zum Einsatz kommen. Die Daten werden dann an den Server gesendet. In
dieser Arbeit wird zusätzlich ein clientseitiger Shop entwickelt, welcher es ermöglicht
Fragebögen zu Veröffentlichen und allgemein Bereitzustellen.
2.1.3 Server
Der Server ist für die Kommunikation zwischen den Clients sowie für den Konfigurator
verantwortlich. Er verteilt die Fragebögen an die Clients und verwaltet die erhaltenen
Daten zum Beispiel für Analysen. Der in dieser Arbeit entwickelte Shop kommuniziert
ebenfalls mit dem Server, so dass alle Schritte synchronisiert sind.
5
3
Verwandte Arbeiten
In diesem Kapitel wird auf bereits bestehende Web-Plattformen für Fragebögen und
Umfragen eingegangen. Dabei liegt der Fokus auf der Verteilung und Bereitstellung der
Fragebögen. Jedoch werden auch die Merkmale der jeweiligen Programme beschrieben.
Zudem wird auf die Monetarisierung der Plattformen eingegangen. In Abschnitt 3.5 folgt
dann ein Vergleich der Web-Plattformen mit dem Fokus auf der Verteilung und den
verwendeten Monetarisierungsmodellen.
3.1 LimeSurvey
LimeSurvey [
8
] ist eine Open-Source Software für online Umfragen der Firma Lime-
Survey GmbH, die unter der GPL v3.0 Lizenz läuft. Bei LimeSurvey kann sich jeder
kostenlos anmelden und anschließend anfangen Umfragen bzw. Fragebögen zu erstel-
len und zu verwalten. Da für die Entwicklung von LimeSurvey jedoch viele Ressourcen
notwendig sind, werden verschiedene Premium Pakete zur Monetarisierung angeboten.
LimeSurvey bietet neben dem Erstellen der Fragebögen auch Möglichkeiten zur automa-
tischen Analyse. Beim Erstellen von Umfragen stehen viele verschiedene Fragetypen zur
Verfügung. Zusätzlich können Fragen, Unterfragen oder Fragegruppen wiederverwendet
werden. LimeSurvey ist dabei für viele verschiedene Anforderungen, wie zum Beispiel
Marktforschung, Abstimmungen, Feedback oder Befragungen von Mitarbeitern oder Kun-
den, ausgelegt. Dabei hilft auch eine Verzweigungslogik, mit der die Umfragen genauer
angepasst werden können. Zur Bereitstellung der Fragebögen steht ein Management-
system zur Verfügung, indem die Teilnehmer per E-Mail eingeladen werden können.
Dabei stehen auch Funktionen bereit um anonyme Umfragen durchzuführen. Auf den
7
3 Verwandte Arbeiten
Fragebogen selbst kommt man über eine generierte URL. Dort kann der Fragebogen
dann ausgefüllt und bearbeitet werden. Die bearbeiteten Fragebögen können dann unter
anderem in verschiedene Formate und Datenbanken exportiert werden.
Für jeden von einer Person bearbeiteten und abgeschlossenen Fragebogen wird ei-
ne Antwort von einem Kontingent an Antworten abgezogen. Eine halbe Antwort wird
zudem für jeden angefangenen aber nicht abgeschlossenen Fragebogen berechnet.
Antworten stehen dabei nicht unbegrenzt zur Verfügung, sondern sind an verschiedene
Abonnements geknüpft. Neben den beschränkten Antworten gibt es sonst nur eine
Upload-Grenze, die zum Speichern der Umfragen verwendet wird. Die meisten anderen
Funktionen stehen in allen Abonnementstufen zur Verfügung. Folgende Versionen von
Abonnements [9] werden angeboten:
Free:
Beim kostenlosen Abonnement, mit dem jeder der sich einen Account erstellt
einsteigt, stehen 25 Antworten pro Monat zur Verfügung. Außerdem ist der Upload-
Speicher auf 10 MB beschränkt. Als Zusatz hat man bei dieser Version Werbung auf der
Endseite.
Basic:
Bei der billigsten Stufe der Abonnements erhält man 1000 Antworten pro Monat
für 29 Euro. Zusätzlich stehen 250 MB Upload-Speicher für die Fragebögen bereit. Die
Werbung entfällt ab dieser Stufe.
Expert:
Bei dieser Version stehen für 349 Euro im Jahr 10000 Antworten pro Jahr zur
Verfügung. Der Upload-Speicher beträgt 1 GB.
Enterprise:
Bei der teuersten Stufe der Abonnements, werden für 849 Euro im Jahr
100000 Antworten pro Jahr erhalten. Zusätzlich erhöht sich der Upload-Speicher auf 3
GB.
8
3.2 Survey System
3.2 Survey System
Survey System [
10
] ist eine umfangreiche Software von der Firma Creative Research
Systems. Sie unterstützt die Erstellung vieler Arten von Fragebögen. So ist die Software
darauf ausgelegt Papierfragebögen zu erstellen. Jedoch ist es genauso möglich die
Fragebögen als Webfragebogen mit oder ohne mobiler Version oder sogar als Telefo-
numfrage zu erstellen. Dabei stehen viele verschiedene Fragetypen zur Auswahl. Survey
System setzt dabei auf ein modulares Modell. Durch den Erwerb von Modulen können
je nach Bedürfnissen des Benutzers verschiedene Funktionen freigeschaltet werden.
Die Module stehen dann auf unbegrenzte Zeit zur Verfügung und können immer wieder
verwendet werden. Zusätzliche Kosten fallen nur an, wenn man die Version eines Moduls
upgraden möchte. Insgesamt stehen drei verschiedene Basiseditionen zur Verfügung.
Evaluation Edition:
Diese Edition ist zum Ausprobieren von Survey System gedacht.
Sie enthält eine volle Professional Edition mit allen verfügbaren Modulen. Ist aber
sowohl auf kleine Fragebögen, als auch auf kleine Datenmengen beschränkt. Die Kosten
belaufen sich auf einmalige 49 US Dollar.
Professional Edition:
Ist für Benutzer, die mit Papierfragebögen arbeiten ausgelegt.
Das Basismodul kostet 1499 US Dollar. Optionale Module erlauben dann auch das
Sammeln der Daten über Web, E-Mail, Telefon oder Smartphones. Die zusätzlichen
Kosten pro Modul betragen je nach Modul zwischen 500 und 4000 Dollar.
Enterprise Edition:
Ist vom Inhalt und Aufbau wie die Professional Edition, allerdings
ist diese auf mehrere Benutzer ausgelegt und dementsprechend teurer, allerdings ins-
gesamt billiger, als wenn jeder Benutzer einzeln eine Professional Edition erwirbt. Das
Basismodul kostet für zwei Benutzer 2499 Dollar. Für jeden zusätzlichen Nutzer werden
Kosten in Höhe von 750 Dollar fällig. Wurden optionale Module erworben, bekommen
diese die zusätzlichen Nutzer umsonst hinzu. Zudem ist es möglich, Dateien über ein
Netzwerk zu teilen und Zugriffsrechte festzulegen.
9
3 Verwandte Arbeiten
Die Verteilung der Fragebögen kommt auf die jeweiligen Module an. So ist es mög-
lich, Fragebögen in Webseiten einzubinden, per E-Mail zu verschicken oder als mobile
Version für Smartphones bereitzustellen. Für Telefonumfragen wird eine Liste von Te-
lefonnummern benötigt. Papierfragebögen können manuell per PDF verteilt werden.
Zusätzlich ist es möglich die Fragebögen in Papierform zu bestellen. Alle Editionen
enthalten Möglichkeiten zum Import und Export von Daten, sowie die Möglichkeit zur
Analyse der erhaltenen Daten.
3.3 QuestionPro
QuestionPro [
11
] ist eine webbasierte Umfragesoftware der Firma QuestionPro GmbH.
Genauso wie LimeSurvey in Abschnitt 3.1 unterstützt QuestionPro den kompletten Pro-
zess eines Fragebogens, von der Erstellung über die Durchführung bis zur Analyse.
Für das Erstellen und Gestalten von Online-Umfragen steht ein Fragebogen-Editor mit
mehr als 50 Fragetypen zur Verfügung. Zusätzlich gibt es die Möglichkeit verschiedene
professionelle Vorlagen zu verwenden. Das Design kann beliebig angepasst werden.
Dazu stehen ebenfalls Design-Vorlagen bereit. Es können jedoch auch eigene Grafiken
und Logos eingebunden werden, sowie Anpassungen mit CSS vorgenommen werden.
QuestionPro ist zudem für verschiedene Anzeigegeräte, wie zum Beispiel für Smartpho-
nes mittels angepasster App, optimiert. Für die Analyse und Auswertung der Umfragen
stehen viele verschiedene Angebote zur Auswahl. So werden in einem anpassbaren
Dashboard grafische Analysen und Reportings in Echtzeit dargestellt. Die Umfrage-
Daten können außerdem exportiert werden.
Die Verteilung der Fragebögen erfolgt über einen generierten Umfrage-Link, der ebenfalls
als QR-Code generiert werden kann. QuestionPro stellt zudem verschiedene zusätzliche
Möglichkeiten zur Bereitstellung der Umfragen zur Verfügung. So gibt es einen Social
Sharing Button, um die Umfrage in Soziale Netzwerke, wie zum Beispiel Facebook
oder Twitter, einzubinden. Des Weiteren unterstützt QuestionPro die Einbettung von
Fragebögen in eigenen Webseiten. Außerdem können Kontakte importiert werden, um
diesen dann Einladungen zur Umfrageteilnahme per E-Mail zu senden. Die Umfragen
können auch offline bearbeitet werden. In diesem Fall werden sie dann später mit dem
10
3.3 QuestionPro
Server synchronisiert.
QuestionPro finanziert sich über Abonnements, bei dem verschiedene Lizenzen mit
unterschiedlichen Funktionen erwerbbar sind. Grundsätzlich kann sich jeder einen kos-
tenlosen Account erstellen, allerdings ist dieser in der Funktionalität stark eingeschränkt.
Nachfolgend sind die verschiedenen angebotenen Lizenzmodelle aufgeführt. Der Über-
sicht wegen, werden nur die wichtigsten und für diese Arbeit relevanten Funktionen
erwähnt [12].
Free:
Die kostenlose Lizenz erhält jeder, der sich bei QuestionPro einen Account
erstellt hat. Diese ist zeitlich unbegrenzt und für den Einstieg gedacht. Es können
beliebig viele Umfragen erstellt werden, jedoch ist die Anzahl der Fragen auf 10 pro
Umfrage und die Feedbacks auf 100 pro Umfrage beschränkt.
Professional:
Mit der Professional Lizenz können bei jeder Umfrage beliebig viele
Fragen erstellt werden. Zudem erhöht sich die Anzahl der Feedbacks auf 1000 pro
Monat. Die Funktionalität wird ebenfalls erweitert. So steht nun zum Beispiel die Ver-
zweigungslogik und Randomisierung von Fragen zur Verfügung. Ebenfalls ist ab dieser
Version das Umfragedesign anpassbar. Die erhaltenen Rohdaten der Umfragen können
nun auch exportiert werden. Die Professional Lizenz kostet im Monat 15 Euro oder als
Jahreslizenz 149 Euro.
Corporate:
Die Corporate Lizenz ermöglicht das Erstellen von Umfragen mit einer un-
limitierten Anzahl an Fragen und Feedbacks. Es stehen alle Funktionen der Professional
Lizenz zur Verfügung. Zudem kommen durch die Corporate Lizenz weitere Funktionen,
wie das Zwischenspeichern von Umfragen oder das offline Erfassen von Daten hinzu.
In dieser Version stehen zudem zusätzliche Fragetypen bereit. Die Kosten betragen im
Monat 99 Euro oder als Jahreslizenz 899 Euro.
Team und Enterprise:
Die vorherigen Lizenzen sind alles Lizenzen für Einzelperso-
nen. Es stehen aber auch mit der Team Edition und der Enterprise Edition Lizenzen für
11
3 Verwandte Arbeiten
mehrere Personen zur Verfügung. Diese enthalten alle Funktionen der Corporate Lizenz,
sowie eine Vielzahl weiterer Funktionen. Die Enterprise Edition baut dabei auf der Team
Edition auf und erweitert die Funktionalität noch einmal. Der Preis für beide Editionen ist
nur auf Anfrage erhältlich.
3.4 Google Play Store
Google Play [
13
] ist der offizielle App Store für Android von der Firma Google LLC.
Im Gegensatz zu den zuvor beschriebenen Systemen hat Google Play nichts mit der
Erstellung oder Verteilung von Fragebögen zu tun. Google Play dient in dieser Arbeit als
Beispiel für Web-Plattformen, die eine andere Art der Bereitstellung und Veröffentlichung
von Produkten haben. Neben vielen verschiedenen Apps bietet der Google Play Store
auch Produkte wie Filme und Serien, Musik, Bücher und Zeitschriften an. Diese Produkte
sind wiederum in verschiedene Kategorien unterteilt. Alle Produkte sind ohne Account
sichtbar, so dass alle Produkte direkt und ohne Aufwand angeschaut werden können.
Die Produkte können mit einem kostenlos erstellten Account über das Payment System
von Google gekauft werden. Erworbene Produkte sind anschließend mit dem Account
des Käufers verknüpft und können sofort auf entsprechende Geräte heruntergeladen
werden.
Google Play erlaubt jedem Nutzer mit einem Google Play-Entwicklerkonto Apps in den
Store einzustellen. Um ein Entwicklerkonto anzulegen, ist eine einmalige Registrierungs-
gebühr von 25 Dollar nötig [
14
]. Beim Einstellen von Apps in den Store haben Entwickler
viele Einstellungsmöglichkeiten. So kann der Preis innerhalb einer Preisspanne belie-
big festgelegt werden. Apps können dabei auch kostenlos Angeboten werden. Google
verlangt zur Deckung von Kosten eine Transaktionsgebühr von 30 % des Preises. Die
anderen 70 % bekommt der Entwickler der App [
15
]. Dies ermöglicht den Nutzern selbst
erstellte Produkte einfach einer breiten Masse an möglichen Interessenten anzubieten
und dabei Geld einzunehmen.
12
3.5 Vergleich
3.5 Vergleich
Insgesamt gibt es auf dem Markt sehr viele Programme die auf Fragebögen oder
Umfragen ausgelegt sind. Neben den bereits in den vorherigen Abschnitten beschrie-
benen Programmen sind in Tabelle 3.1 weitere Produkte dargestellt. Dabei wurden die
wichtigsten Merkmale, sowie die verschiedenen Monetarisierungsmodelle der Software
aufgelistet.
Bei allen Programmen gibt es die Möglichkeit Fragebögen zu erstellen. Dazu stehen je
nach Programm verschiedene Funktionen zur Verfügung. Alle Programme sind darauf
ausgelegt, dass eine Person oder eine Gruppe von Personen die Fragebögen für die
eigene Nutzung selber erstellt. Die Fragebögen können dann an die Teilnehmer über ver-
schiedene Wege verteilt werden. So gibt es bei fast allen eine Verteilung der Fragebögen
über einen generierten Link der per E-Mail oder Soziale Netzwerke weitergeleitet werden
kann. Im Gegensatz zum Prinzip des Google Play Stores in Abschnitt 3.4 existiert bei
den bestehenden Fragebogenprogrammen keine einfache Möglichkeit Fragebögen für
andere unbekannte Nutzer zu erstellen oder an diese zu verkaufen beziehungsweise
bereitzustellen.
Unterschiede der Systeme gibt es vor allem bei der Monetarisierung und damit bei
den Kosten. Die Systeme nutzen dabei verschiedene Modelle. So stellen die meisten
verschiedene Abboversionen zur Verfügung, die dann monatlich oder jährlich bezahlt
werden müssen und je nach Version nur eine beschränkte Anzahl an Funktionen verfüg-
bar sind. Dazu gibt es Software wie zum Beispiel LimeSurvey in Abschnitt 3.1 die zwar
alle Funktionen bereitstellen, jedoch die Anzahl an Fragebögen pro Zeitraum, Fragen
oder Antworten der Fragebögen beschränken. Die meisten Systeme bieten dabei auch
stark eingeschränkte kostenlose Versionen zum Testen der Software an. Ein anderer
Ansatz ist der des modularen Modells, welchen Survey System in Abschnitt 3.2 benutzt.
Eine weitere Möglichkeit der Monetarisierung ist ein Modell, bei dem Punkte gekauft
werden können, die dann anhand von bestimmten Kriterien, wie zum Beispiel ausgefüllte
Fragebögen, verbraucht werden. Ein Beispiel für dieses Modell stellt movisensXS in
Tabelle 3.1 dar.
13
3 Verwandte Arbeiten
Tabelle 3.1:
Auflistung weiterer Umfrage Software mit Merkmalen und jeweiligem Preis-
modell
Name des Produkts Merkmale Preismodell
SurveyMonkey [16]
•Entwerfen von Umfragen
•
Umfrage Collectors zur Ver-
teilung über Web, E-Mail,
Soziale Medien
•
Analyse der Daten mit einer
App
•
Abbomodell mit monatlicher
oder jährlicher Abrechnung
•
Standard(
e
39 pro Monat),
Extra(
e
456 pro Jahr), Pre-
mium(e1188 pro Jahr)
•
Kostenlose Version auf 10
Fragen und 100 beantwor-
tungen pro Umfrage be-
schränkt
•
Anzahl der Umfragen in al-
len Versionen unbegrenzt
•
Beantwortungen in der
Standard Version auf 1000
pro Monat eingeschränkt
•
Teurere Abbos haben mehr
Funktionen
14
3.5 Vergleich
Name des Produkts Merkmale Preismodell
SurveyPlanet [17]
•Entwerfen von Umfragen
•
Vorgefertigte Fragen und
Templates, die zusätzlich
angepasst werden können
•
Unterstützt verschiedene
Themes
•
stellt das Branching von Fra-
gebogen zur Verfügung
•
Export des Fragebogens
und der Ergebnisse möglich
•
Verteilung der Umfragen
über generierte URL, E-
Mail, Soziale Netzwerke,
Einbinden in eigene Web-
seite
•
Zwei Verschiedene Versio-
nen: Free und Pro(20 Dollar
pro Monat)
•
Kostenlose Version enthält
keine Einschränkungen für
die Anzahl der Umfragen,
Fragen pro Umfrage und
Antworten pro Umfrage
•
Es sind in der kostenlosen
Version bereits viele Funk-
tionen vorhanden
15
3 Verwandte Arbeiten
Name des Produkts Merkmale Preismodell
movisensXS [18]
•
Gesamtsystem für das Ex-
perience Sampling
•
Mobile Erfassung von Fra-
gebögen durch Android-
App
•
Erstellen von Fragebögen
in Webplattform
•
Überwachung von Ergeb-
nissen in Echtzeit
•
movisens Sensoren können
eingebaut werden
•
Credit System: Erwerb von
Credits(Cr) durch verschie-
dene Pakete
•
Pakete: Free(1000 Cr/
e
0),
Basic(10000 Cr/
e
500),
Gold(100000 Cr/
e
3000),
Platinum(1000000 Cr/
e10000)
•
Credits können für verschie-
dene Studien benutzt wer-
den
•
Für jede beantwortete Fra-
ge wird 1 Cr verbraucht
•
Es existiert ein Rechner, mit
dem die Anzahl an benö-
tigten Credits anhand der
Teilnehmer, Fragen, Wieder-
holungen des Fragebogens
kalkuliert werden kann
16
3.5 Vergleich
Name des Produkts Merkmale Preismodell
Zoho [19]
•
Erstellen von Umfragen mit
verschiedenen Fragetypen
•
Auswahl aus verschiede-
nen anpassbaren Design-
Templates beim Erstellen
•
Verteilung der Fragebögen
über einen generierten Link
•
Der Link kann auch di-
rekt über E-Mail, Soziale
Netzwerke, private Grup-
pen, QR-Code verbreitet
werden
•
Antworten können auch off-
line erfasst werden
•
Es ist möglich Antworten
bzw. eine Zielgruppe für die
Umfrage direkt zu kaufen
•
Verschiedene Analysemög-
lichkeiten in Echtzeit
•
steht ebenfalls als App zur
Verfügung
•
Abbomodell mit monatlicher
oder jährlicher Abrechnung
•
Standard(
e
24 pro Monat),
Premium(
e
29 pro Jahr),
Enterprise(e49 pro Jahr)
•
Es gibt eine Kostenlose Ver-
sion: Beschränkung auf 15
Fragen und 150 Antworten
pro Umfrage. Die Anzahl
der Umfragen ist nicht be-
schränkt.
•
Die zur Verfügung stehen-
den Funktionen nehmen mit
teureren Abbos zu
•
Kostenlose Version ist in
den Funktionen stark einge-
schränkt.
17
4
Anforderungen
In diesem Abschnitt werden die an den Webshop gestellten Anforderungen beschrieben.
Diese werden in funktionale und nicht-funktionale Anforderungen unterteilt.
4.1 Funktionale Anforderungen
Funktionale Anforderungen sind Anforderungen an eine Anwendung, die die Funktio-
nalität beschreiben. Nachfolgend werden alle funktionalen Anforderungen des Shops
aufgezählt.
FA1 Fragebögen:
Jeder Besucher des Shops sollte in der Lage sein sich eine Auswahl
an verfügbaren digitalen Fragebögen anzuschauen.
FA2 Kategorien:
Die Fragebögen sollen in verschiedenen Kategorien unterteilt werden
können.
FA3 Login:
Ein Benutzer sollte sich auf der Webseite mit seinem QuestionSys Account
einloggen können, um damit digitale Fragebögen erwerben zu können.
FA4 Warenkorb:
Fragebögen können in einem Warenkorb vor dem Kauf vorgemerkt
werden. Dieser sollte zu jedem Zeitpunkt auf dem aktuellsten Stand sein und mit
dem Server synchronisiert sein.
FA5 Übersicht über erworbene Fragebögen:
Gekaufte Fragebögen sollten in einer
extra Übersicht dargestellt werden.
FA6 Rollen:
Es soll möglich sein Benutzern mit bestimmten Rollen weitere Funktionen
zur Verfügung zu stellen.
19
4 Anforderungen
FA7 Erstellen von Fragebögen:
Fragebögen sollen sich von berechtigten Benutzern
in den Shop einfügen lassen.
FA8 Ändern der Fragebögen:
Die von einem Benutzer erstellten Fragebögen sollen
sich von diesem bearbeiten lassen.
FA9 Preise der Fragebögen:
Die Preise der Fragebögen sollen sich nach den Wün-
schen des Benutzers frei festlegen lassen.
FA10 Fehlermeldungen:
Auf der ganzen Web-Plattform sollten sinnvolle Fehlermel-
dungen ausgegeben werden. Mit eingeschlossen ist dabei auch die Validierung
von Benutzereingaben.
4.2 Nicht-funktionale Anforderungen
Im Folgenden werden die nicht-funktionalen Anforderungen der Web-Plattform beschrie-
ben. Nicht-funktionale Anforderungen beschreiben die Qualität und Leistung der Anwen-
dung.
NFA1 Intuitive Bedienbarkeit:
Der Shop sollte einfach und selbsterklärend verwendet
werden können, damit potentiell jeder den Shop benutzen kann.
NFA2 Erweiterbarkeit von Funktionen:
Dem Shop sollten leicht neue Funktionen
hinzugefügt werden können. Zudem sollte er einfach anzupassen sein.
NFA3 Zuverlässigkeit:
Der Benutzer sollte jederzeit zuverlässig mit dem Shop arbeiten
können.
NFA4 Verfügbarkeit:
Der Shop sollte möglichst jederzeit zur Verfügung stehen. Da
im Hintergrund allerdings ein Server läuft, könnte es zu Verbindungsproblemen
kommen. Diese müssen entsprechend behandelt werden.
NFA5 Robustheit und Stabilität:
Der Shop sollte gegenüber Eingaben des Benutzers
robust und stabil funktionieren.
20
4.2 Nicht-funktionale Anforderungen
NFA6 Skalierbarkeit:
Große Datenmengen sollten dem Shop keine Probleme bereiten.
Dazu sollen Techniken wie Pagination zur Anwendung kommen. Zudem sollte es
keinen Unterschied machen, wie viele Fragebögen gekauft werden.
NFA7 Sicherheit:
Da es sich um einen Webshop handelt, der Anfragen an einen Server
sendet, liegt ein großer Teil der Sicherheit beim Server. Anfragen vom Shop sollten
daher vom Server überprüft werden.
21
5
Konzept
In diesem Kapitel wird das Konzept hergeleitet. Dazu wird zuerst allgemein auf mögliche
Ansätze zur Veröffentlichung und Bereitstellung digitaler Fragebögen eingegangen.
Anschließend werden in Abschnitt 5.2 Ansätze zur Monetarisierung digitaler Fragebögen
dargestellt. Im letzten Abschnitt wird das in dieser Arbeit verwendete Konzept vorgestellt.
5.1 Ansätze zur Veröffentlichung digitaler Fragebögen
Grundsätzlich gibt es durch die immer zunehmendere Wandlung von Papierfragebögen
zu digitalen Fragebögen, viele zusätzliche Möglichkeiten Fragebögen zu verteilen oder
bereitzustellen. In Kapitel 3 wird bereits dargestellt, wie andere Systeme die Fragebögen
verteilen. Dabei benutzen die meisten Systeme einen Mix aus verschiedenen Ansätzen.
Dadurch kann der Benutzer die für sich am Besten geeignete Möglichkeit auswählen.
Im Folgenden sind einige Ansätze zum Verteilen und Bereitstellen von digitalen Frage-
bögen aufgelistet:
•Link bzw. URL
•E-Mail
•QR-Code
•Soziale Netzwerke
•private oder öffentliche Gruppen, wie z.B. Chat Räume
Diese Ansätze eignen sich am Besten, um erstellte Fragebögen zum Ausfüllen und
Bearbeiten an bestimmte Gruppen zu senden. Dabei ist es einfach einen generierten
23
5 Konzept
Link über E-Mail oder QR-Code zu verteilen. Das Verteilen von Fragebögen über soziale
Netzwerke oder Gruppen hat den Vorteil, dass zum einen viele und zum anderen auch
unbekannte Personen erreicht werden können. Nachteile haben diese Methoden vor
allem dann, wenn es nicht mehr um die reine Verteilung von einem Fragebogen geht,
sondern weitere Anforderungen hinzukommen. Ein Beispiel dafür ist, ein Benutzer
will einen bereits erstellten Fragebogen an einen unbekannten Benutzer verkaufen
beziehungsweise zur weiteren Benutzung zur Verfügung stellen. Dann ist es mit diesen
Ansätzen schwierig, da die Zielgruppe unter Umständen sehr klein ist. Deshalb bietet
sich zur Veröffentlichung und Bereitstellung von Fragebögen ein weiterer Ansatz an:
•Shop Seite
Auf einem extra für Fragebögen angelegten Shop können Benutzer Fragebögen einstel-
len sowie erwerben. Dadurch konzentriert sich die Zielgruppe auf einen konzentrierteren
Bereich, wodurch schneller passende Fragebögen gefunden werden können.
5.2 Ansätze zur Monetarisierung digitaler Fragebögen
In diesem Abschnitt wird auf Möglichkeiten zur Monetarisierung digitaler Fragebögen
eingegangen. In Kapitel 3 sind mit den Monetarisierungsmodellen anderer Systeme
bereits einige Ansätze beschrieben. Allerdings muss dabei zwischen dem Einschränken
von Fragebögen und dem Einschränken von Funktionen unterschieden werden. Das
Beschränken von Funktionen spielt hier erst einmal keine Rolle. Das Einschränken
von Fragebögen dafür umso mehr, da dadurch viele Monetarisierungsmöglichkeiten
entstehen. Für einen Fragebogen sind potentiell einige Beschränkungen vorstellbar. Im
Folgenden sind diese möglichen Ansätze zur Beschränkung aufgelistet:
•Anzahl der Fragebögen in einem bestimmten Zeitraum
•Anzahl der Fragen in einem Fragebogen
•Anzahl der Antworten bzw. Teilnehmer von einem Fragebogen
•Anzahl der beantworteten Fragen in einem Fragebogen
24
5.3 Das entstandene Konzept
Diese Beschränkungen können dann genauer definiert werden, um dann abhängig von
einem Monetarisierungsmodell zum Beispiel eine genaue Anzahl in einem bestimmten
Zeitraum festzulegen.
Grundsätzlich gibt es verschiedene Ansätze an Monetarisierungsmodellen, die für ein
Konzept in Frage kommen. Im Folgenden sind diese Modelle aufgeführt:
•Abo-Modell
•Punkte-Modell
•Modul-Modell
•Shop-Modell
Diese Modelle können dann den Bedürfnissen und Vorgaben entsprechend angepasst
werden.
5.3 Das entstandene Konzept
In diesem Abschnitt wird das entstandene und in Kapitel 6 umgesetzte Konzept be-
schrieben. Als Grundmodell wurde dabei das Shop-Modell ausgewählt, da sich die
Fragebögen dadurch am Besten veröffentlichen und bereitstellen lassen. Das Modell hat
zudem den großen Vorteil, dass Benutzer für andere Benutzer Fragebögen anfertigen
können und diese unter Umständen öfters wiederverwendet werden können.
Um Fragebögen in den Shop einstellen zu können, braucht der Benutzer eine bestimmte
Rolle (siehe Abschnitt 5.3.2 Nutzerrollen). Die Fragebögen können dann direkt beim
Erstellen in den Shop gestellt werden. Der Ersteller des Fragebogens kann anschließend
selbständig die Preise für den Fragebogen festlegen. Dabei gibt es zwei verschiedene
Preise.
Der erste Preis, der
Model Preis
legt fest, wie viel ein Käufer beim Kauf für einen
Fragebogen bezahlen muss. Der Käufer kauft sich Lizenzen des Fragebogens. Lizen-
zen werden durch das Bearbeiten von Fragebögen durch die Teilnehmer verbraucht.
25
5 Konzept
Kauft der Käufer als Beispiel Lizenzen für 100 Fragebögen können 100 Teilnehmer den
Fragebogen ausfüllen. Sind die Lizenzen verbraucht, müssen neue Lizenzen erworben
werden. Der Ersteller gibt beim Einstellen des Fragebogens den Preis pro Lizenz an.
Gekaufte Fragebögen werden anschließend über den Server synchronisiert und sollten
dann in der mobilen App für weitere Schritte zur Verfügung stehen.
Der zweite Preis ist der
Instance Preis
. Dieser ist für die Ergebnisse des Fragebo-
gens da. Will der Käufer die beantworteten Fragebögen haben, müssen diese ebenfalls
gekauft werden. Der Ersteller kann diesen Preis, genauso wie beim Model Preis beliebig
einstellen. Beide Preise können auch unabhängig voneinander 0 betragen, so dass es
möglich ist Fragebögen komplett kostenlos anzubieten.
Zur Deckung der Kosten des Shops soll es einen Share bei den Einnahmen zwischen
dem Ersteller und der Plattform geben. Dadurch besteht für den Ersteller trotzdem noch
die Möglichkeit durch das Bereitstellen von Fragebögen Geld zu verdienen. Neben dem
Share sind keine weiteren Möglichkeiten für Einnahmen der Webplattform vorgesehen.
Dies schließt damit auch zusätzliche Abo-Modelle, in denen Fragebögen oder Funktionen
der verschiedenen Anwendungen beschränkt werden, aus. Fragebögen können somit
immer eine unlimitierte Anzahl an Fragen und Antworten haben. Zudem kann ein
Benutzer beliebig viele Fragebögen erstellen.
5.3.1 Darstellung der Fragebögen
Nachdem bereits in den vorangegangenen Abschnitten, das Shop-Modell und die Mo-
netarisierung der Fragebögen beschrieben wurde, wird nun auf die Darstellung der
Fragebögen im Shop eingegangen. Die Darstellung eines erstellten Fragebogens im
Shop gestaltet sich zunächst schwierig, da nicht der komplette Fragebogen angezeigt
werden kann. Zur einfachen Darstellung bietet es sich an, direkt bei der Erstellung des
Fragebogens ein zusätzliches
Shop Model
des Fragebogens zu erstellen. Dieses soll
dann durch eine Referenz mit dem eigentlichen Fragebogen verknüpft sein. In Abbil-
dung 5.1 ist dieses
Shop Model
des Fragebogens abgebildet. Damit die Fragebögen
26
5.3 Das entstandene Konzept
übersichtlich dargestellt werden können, hat das Fragebogen Model einen Titel und
Schlüsselwörter zur genaueren Einordnung des Fragebogens. Die Beschreibung sorgt
dafür, dass Inhalt und Merkmale des Fragebogens genau beschrieben werden können.
Des Weiteren sind die beiden Preise aus dem vorherigen Abschnitt ebenfalls enthalten.
Das Fragebogen Model reicht dann aus, um den Fragebogen im Shop darzustellen. Wei-
tere Informationen des richtigen Fragebogens werden nicht benötigt. Der Server erhält
dadurch die zusätzliche Aufgabe, das Fragebogen Model zu verwalten. Wird dieses
gekauft, muss der Käufer ebenfalls Zugang zum richtigen Fragebogen bekommen.
Abbildung 5.1: Fragebogen Model im Shop
Damit auch viele Fragebögen im Shop übersichtlich dargestellt werden können, sollen
die Fragebögen in verschiedene Kategorien eingeteilt werden. Eine Kategorie soll dabei
für ein bestimmtes Themengebiet stehen, welches der Fragebogen behandelt. Das
Fragebogen Model ist immer einer Kategorie zugeteilt. Durch die Schlüsselwörter lässt
sich das Gebiet zusätzlich näher spezifizieren. Dies ermöglicht Nutzern, die Fragebögen
für einen speziellen Bereich suchen, diese leicht zu finden und so schnellen Zugriff
zu erlangen. Zur genaueren Einteilung der Fragebögen in bestimmte Themengebiete,
27
5 Konzept
kann eine Kategorie beliebig viele Unterkategorien besitzen. Die Kategorien sind dabei
in Baumform angeordnet, so dass eine Schachtelung von Kategorien möglich ist. Zur
Darstellung mehrerer Oberkategorien für verschiedene Themengebiete, kann es mehre-
re Bäume von Kategorien geben. In Abbildung 5.2 ist ein Beispiel für den Aufbau von
Kategorien dargestellt. Im linken Teil der Grafik gibt es eine Oberkategorie Gesundheit,
welche in Fitness und Psychologie, sowie eine beliebige Anzahl weiterer Unterkatego-
rien, unterteilt wird. Diese Unterkategorien können ebenfalls weitere Unterkategorien
haben. Daneben kann es aber auch eine weitere Kategorie Logistik geben, welche
wiederum in verschiedene Unterkategorien unterteilt ist.
Abbildung 5.2: Aufbau der Kategorien als Beispiel
Damit ein Nutzer eine Übersicht über alle von Ihm erworbenen Fragebögen hat, soll
es neben dem Shop ein Dashboard geben. In diesem sollen die getätigten Trans-
aktionen und die gekauften Fragebögen dargestellt werden. Zusätzlich soll es einen
Management-Bereich geben, indem ein Nutzer seine eingestellten Fragebögen in Form
des Fragebogen Models sieht und diese bearbeiten kann.
28
5.3 Das entstandene Konzept
5.3.2 Nutzerrollen
In diesem Abschnitt des Konzeptes werden kurz die verschiedenen Nutzerrollen des
Shops vorgestellt. Die Rollen legen fest, welche Funktionalität des Shops dem Nutzer
zur Verfügung steht.
Gast
Ein Gast ist jeder Nutzer, der die Shop-Seite nutzt und nicht eingeloggt ist. Im Anwen-
dungsfalldiagramm in Abbildung 5.3 sind die Möglichkeiten eines Gastes anschaulich
dargestellt. Als Gast kann sich der Nutzer alle Fragebögen des Shops anschauen, diese
allerdings nicht erwerben. Er hat zudem die Option, die Fragebögen zur Ansicht in
vordefinierten Kategorien zu filtern. Außerdem kann er sich auf der Seite anmelden,
sowie über das zentrale Account-Management System von QuestionSys einen Account
erstellen.
Abbildung 5.3: Anwendungsfalldiagramm Nutzerrolle Gast
29
5 Konzept
Standardnutzer
Ein Benutzer erhält die Rolle Standardnutzer, sobald er sich erfolgreich eingeloggt hat.
Dadurch erhält er zusätzliche Berechtigungen, welche im Anwendungsfalldiagramm in
Abbildung 5.4 dargestellt sind. So kann er Fragebögen in den Warenkorb hinzufügen,
diesen bearbeiten, sowie den Kauf der Fragebögen über das Bezahlsystem abschließen.
Anschließend können die gekauften Fragebögen im Dashboard verwaltet werden.
Abbildung 5.4: Anwendungsfalldiagramm Nutzerrolle Standardnutzer
Merchant
Als Merchant steht dem Nutzer neben den Funktionen des Standardnutzers auch der
Management-Bereich zur Verfügung. In diesem hat der Nutzer eine Übersicht über alle
Fragebögen, die von ihm bearbeitet werden können. Die neu bekommenen Berech-
tigungen sind im Anwendungsfalldiagramm in Abbildung 5.5 abgebildet. Wie dort zu
sehen ist, kann der Nutzer die Fragebogen Models bearbeiten und somit auch die Preise
der ihm zugänglichen Fragebögen ändern. Die Rolle Merchant muss dem Nutzer extra
30
5.3 Das entstandene Konzept
zugewiesen werden.
Abbildung 5.5: Anwendungsfalldiagramm Nutzerrolle Merchant
31
6
Implementierung
In diesem Kapitel werden Aspekte der Implementierung des Shops beschrieben. Dazu
wird in Abschnitt 6.1 auf die verwendeten Frameworks der Anwendung eingegangen. Im
nächsten Abschnitt wird die Implementierung verschiedener Komponenten dargestellt
bevor in Abschnitt 6.3 der Aufbau des Shops vorgestellt wird.
6.1 Verwendete Frameworks
In diesem Abschnitt wird auf die verwendeten Frameworks des Shops eingegangen.
Dazu werden die Frameworks Angular 5 und INSPINIA beschrieben.
6.1.1 Angular 5
Angular 5 ist ein Framework von Google, mit dem clientseitige Web-Anwendungen
entwickelt werden können. Die Anwendungen werden mit
HTML
und
TypeScript
ge-
schrieben. Die Kernfunktionen von Angular werden in Form von TypeScript-Bibliotheken
direkt in die Anwendungen importiert [
20
]. TypeScript ist eine Sprache, die von Microsoft
Open-Source entwickelt wird und eine typisierte Obermenge von JavaScript darstellt.
Dabei kompiliert TypeScript zu normalem lesbaren JavaScript [21].
Eine Angular Anwendung besteht aus verschiedenen Modulen, dabei hat eine Anwen-
dung immer ein
root
-Modul und normalerweise mehrere
feature
-Module. Neben
dem
root-Modul
besitzt jede Anwendung eine
root-Komponente
, die die Kompo-
nenten Hierarchie mit dem Document Object Model (DOM) verbindet. Jede Komponente
definiert eine TypeScript-Klasse, die aus Anwendungsdaten und Logik besteht und
33
6 Implementierung
mit einem
HTML-Template
verknüpft ist. Das
HTML-Template
ermöglicht mit Hilfe
von Angular Markup das Modifizieren von HTML-Elementen bevor diese in der View
angezeigt werden. Ein Modul kann aus verschiedenen Teilen, wie Komponenten oder
Service bestehen. Ein Service enthält Logik oder Daten, die nicht mit einer bestimmten
View in Verbindung gebracht werden können oder mit anderen Komponenten geteilt
werden sollen [20].
6.1.2 INSPINIA Admin Theme
INSPINIA Admin Theme ist ein Bootstrap HTML Template, das für verschiedene Arten
von Web-Anwendungen benutzt werden kann. Es besteht aus HTML5, Bootstrap 3+
Framework und CSS [22].
Für den Shop, der im Rahmen dieser Arbeit entwickelt wurde, wird INSPINIA zur Unter-
stützung von Angular 5 verwendet. Dabei wurden die verwendeten HTML Dateien stark
angepasst, um die Vorteile von Angular nutzen zu können.
6.2 Implementierung verschiedener Komponenten
In diesem Abschnitt wird auf die Implementierung verschiedener Komponenten einge-
gangen. Zuerst werden die wichtigsten Service der Anwendung erläutert. Anschließend
werden zwei Module der Anwendung beschrieben.
6.2.1 Service
In diesem Abschnitt werden die wichtigsten
Service
Komponenten beschrieben. Zuerst
wird kurz erläutert, was ein Service ist. Anschließend wird genauer auf bestimmte
Service eingegangen. Ein
Service
ist eine Controller Komponente, die eine bestimmte
Funktion in der Applikation übernimmt. Durch das Registrieren als
Provider
bekommen
Service
-Klassen durch
Dependency-Injection
globalen Zugriff und können damit
in allen anderen Service-Klassen oder Komponenten verwendet werden [23, 24].
34
6.2 Implementierung verschiedener Komponenten
ApiService
Der
ApiService
stellt die Schnittstelle zur Kommunikation mit dem Server dar. Jeder
Zugriff auf die Api von Komponenten oder Services läuft über den
ApiService
. Dazu
steht für jeden
Request
an den Server eine eigene Funktion zur Verfügung. In Listing
6.1 ist ein Beispiel einer Funktion für einen
GET-REQUEST
dargestellt. In diesem Fall
ist die Funktion dafür zuständig alle verfügbaren Fragebögen vom Server zu laden.
Zuerst wird die passende URL vom
UriService
geholt. Es ist möglich diese durch den
optionalen Parameter
urlExtension
zusätzlich zu erweitern. Dies ist zum Beispiel
für Pagination nötig, da dadurch einfach bestimmte Datensätze geladen werden kön-
nen. Zum Beispiel mit der
urlExtension page=2
alle Daten die für Seite 2 benötigt
werden. Im nächsten Schritt folgt dann der Request. Dieser bekommt die generierte
URL, sowie Standard
httpOptions
wie
Header
übergeben. Die Daten werden im
JSON
-Format versendet. Deshalb wird die erhaltene
Response
vom Server mit Hilfe
des
MappingService
in die passenden Rückgabeobjekte gemapped. Zurückgegeben
wird ein Observable der RxJS-Bibliothek.
1public getAllQuestionnaires(urlExtension?: string): Observable
<[Questionnaire[], Pagination]> {
2let url = this.uriService.getUrl(’productsUrl’);
3if (urlExtension && urlExtension.length > 0) {
4url = url + ’?’ + urlExtension;
5}
6return this.http.get<[Questionnaire[], Pagination]>(url,
httpOptions)
7.pipe(
8map(data => [this.mappingService.
handleQuestionnairesMapping(data), this.
mappingService.handlePaginationMapping(data)]),
9catchError(this.handleError)
10 );
35
6 Implementierung
11 }
Listing 6.1: Beispiel GET-REQUEST in ApiService
Alle der im
ApiService
enthaltenen Funktionen sind nach diesem Schema aufgebaut.
Bei
POST-REQUESTS
wird der
MappingService
dazu verwendet, den
Body
im
JSON
-
Format darzustellen. Unterstützt wird der
ApiService
durch
Interceptoren
, die
bestimmte Fehlermeldungen behandeln oder Header hinzufügen. Auf diese Art wird
auch der
Authorization Header
mit entsprechendem
Authorization Token
hinzugefügt.
UriService
Der
UriService
besteht aus zwei Hauptkomponenten. Zum einen aus einer
Map
, die
alle benötigten
URLs
enthält. Und zum anderen aus einer Funktion, die die richtige
URL
zurückgibt. Für das Initialisieren der
Map
gibt es eine extra
Init
-Funktion. Die
URL
wird darin so aufgebaut, dass schrittweise Teile der
URL
in die Map eingetragen
werden (siehe Listing 6.2). Dazu werden bereits in der Map vorhandene
URLs
als Basis
für neue
URLs
verwendet. Änderungen an der Basis einer
URL
können damit einfach
durchgeführt werden.
1this.urls.set(’apiVersion’, API_URL + ’/v1’);
2this.urls.set(’shop’, this.urls.get(’apiVersion’) + ’/shop’);
Listing 6.2: Aufbau der Url
Für den Fall, dass eine URL eine Variable, wie zum Beispiel die
ID
eines Objektes
enthält, wird ein Placeholder nach folgendem Muster in Listing 6.3 hinzugefügt.
1this.urls.set(’questionnaireByID’, this.urls.get(’productsUrl’)
+ ’/{id}’);
Listing 6.3: Aufbau der Url mit einer Variablen
36
6.2 Implementierung verschiedener Komponenten
Der
Placeholder
wird anschließend in der Funktion zur Rückgabe der passenden
URL durch den richtigen Wert ersetzt (siehe Listing 6.4). Die Funktion bekommt neben
der optionalen ID den Schlüssel der Map übergeben. Mit diesem wird die richtige URL
zurückgegeben.
1getUrl(key: string, id?: string) {
2return this.urls.get(key).replace(’{id}’, id);
3}
Listing 6.4: Funktion zur Rückgabe passender URL
MappingService
Der
MappingService
hat die zentrale Aufgabe
Model
von oder in
JSON
umzuwandeln.
Dazu stehen für jeden Request passende Funktionen zur Verfügung. Diese verwenden
als Rückgabewert passende Models. In Listing 6.5 ist eine Beispielfunktion zum Mapping
von JSON in ein Pagination Model abgebildet.
1handlePaginationMapping(data: any): Pagination {
2const meta = data.meta;
3const p = meta.pagination;
4return new Pagination(p.total, p.count, p.per_page, p.
current_page, p.total_pages, data.links);
5}
Listing 6.5: Funktion zum Mapping von JSON in ein Pagination Model
Für komplexere Mappings, gibt es weitere interne Funktionen, die das Mapping vereinfa-
chen und in verschiedenen Fällen zur Anwendung kommen können.
37
6 Implementierung
AuthService
Der
AuthService
ist für die Authentifizierung des Benutzers verantwortlich. Neben dem
Login
und dem Aktualisieren des
Authentication Token
ist der
AuthService
auch für die
Session
des Benutzers zuständig. Dafür werden Funktionen zur Verfügung
gestellt, die von anderen Komponenten aufgerufen werden können. Beim
Login
enthält
die Antwort des Servers neben dem
Authentication Token
und einem
Refresh
Token
auch die Anzahl an Sekunden, wie lange der
Authentication Token
gültig
ist. Listing 6.6 stellt dar, wie diese Informationen in der Session gespeichert werden. Be-
vor die Werte in den
sessionStorage
geschrieben werden, wird der Ablaufzeitpunkt
des Tokens berechnet.
1public setSession(token: Token) {
2const expiresAt = moment().add(token.expires_in, ’second’);
3sessionStorage.setItem(’token’, token.token);
4sessionStorage.setItem(’refresh_token’, token.refresh_token
);
5sessionStorage.setItem(’expires_at’, JSON.stringify(
expiresAt.valueOf()));
6}
Listing 6.6: Speichern der Token in einer Session im AuthService
Funktionen des
AuthService
werden auch vom
AuthGuardService
benutzt, um
sicherzustellen, dass der Benutzer für bestimmte Seiten eingeloggt ist.
Kommunikation der Service
In diesem Abschnitt wird kurz anhand eines Beispiels die Kommunikation unter den be-
schriebenen Service näher erläutert. Allgemein gilt, dass jeder Service eine bestimmte
Aufgabe bzw. Funktion übernimmt und nur für diese zuständig ist. Wird eine Funktion
eines Service gebraucht, wird dieser entsprechend aufgerufen und die Funktion liefert
38
6.2 Implementierung verschiedener Komponenten
anschließend das Ergebnis zurück. Im Sequenzdiagramm in Abbildung 6.1 ist ein Vor-
gang zum Laden von Daten, wie Kategorien oder Fragebögen dargestellt. Gestartet wird
der Vorgang zum Beispiel durch eine Komponente, die Fragebögen aus einer Kategorie
darstellen soll. Die Komponente ruft die entsprechende Funktion des
ApiService
auf. Dieser ruft dann die
getUrl
Funktion des
UriService
auf und erhält dadurch
die passende URL. Im nächste Schritt sendet der
ApiService
einen
Request
an
den Server. Mit Erhalten der
Response
leitet der
ApiService
, die im JSON-Format
empfangenen Daten an den
MappingService
weiter. Dieser wandelt die Daten in das
passende Model, in diesem Beispiel das Fragebogen Model, um. Im letzten Schritt erhält
die Komponente das Model und kann die Daten anzeigen und somit im Beispiel die
Fragebögen der Kategorie darstellen.
Abbildung 6.1: Sequenzdiagramm zum Laden von Daten vom Server
39
6 Implementierung
6.2.2 Module
In diesem Abschnitt werden zwei Module beschrieben, die in vielen Komponenten zum
Einsatz kommen. Dies ist zum einen das
Pagination
-Modul und zum anderen das
Breadcrumb-Modul.
Pagination
Das
Pagination
-Modul besteht aus einer
Pagination
-Komponente, die in vielen
Komponenten benutzt wird. In Abbildung 6.2 ist diese mit drei Seiten dargestellt. Die
Pagination
-Komponente erhält als Input ein
Pagination
-Objekt. In diesem sind alle
Informationen zur aktuellen Seite, sowie zur Anzahl aller Seiten enthalten. Die Kompo-
nente selbst ist flexibel einstellbar. So sind die Anzahl der Seiten, die angezeigt werden
anpassbar. Zusätzlich können die Pfeilbuttons Vor/Zurück und Erste/Letzte individuell
ausgeblendet werden. Wird ein Button geklickt, liefert die
Pagination
-Komponente
über
EventEmitter
die Seitennummer. Mit dieser kann dann der
ApiService
aufge-
rufen werden und somit neue Inhalte geladen werden.
Abbildung 6.2: Pagination Komponente mit 3 Seiten
Breadcrumb
Das
Breadcrumb
-Model besteht genauso, wie das
Pagination
-Model aus nur einer
Komponente. Die
Breadcrumb
-Komponente wird jedoch auf jeder Seite verwendet.
Wie in Abbildung 6.3 zu sehen ist, besteht die
Breadcrumb
-Komponente aus einem
Titel und mehreren
Breadcrumb
-Models. Diese enthalten neben dem Namen einen
40
6.3 Aufbau des Shops
zugehörigen Link zur Navigation.
Abbildung 6.3: Breadcrumb Komponente
6.3 Aufbau des Shops
In diesem Abschnitt wird der Aufbau des Shops beschrieben. Der Shop ist in drei Be-
reiche aufgeteilt. Der Hauptbereich ist der
Shop
-Bereich in dem die Fragebögen in
verschiedenen Kategorien dargestellt werden. Der zweite Bereich ist der
Home
-Bereich
und der dritte Bereich der Management-Bereich.
Die Navigation zwischen den Bereichen erfolgt durch eine
Top-Navigation-Bar
Kom-
ponente, die in Abbildung 6.4 zu sehen ist.
Abbildung 6.4: Navigation über Top-Navigation-bar
6.3.1 Shop
In diesem Abschnitt wird der
Shop
-Bereich der Anwendung vorgestellt. Der Shop-
Bereich umfasst viele verschiedene Komponenten und Seiten. Die Fragebögen können
auf zwei unterschiedliche Arten angezeigt werden. Zum einen als
Grid View
und zum
anderen als
List View
. Zwischen den Views kann jederzeit über den Button auf der
41
6 Implementierung
rechten Seite der
Top-Navigation-Bar
(siehe Abbildung 6.4) gewechselt werden.
Mit Angular ist es möglich, die Komponenten so auszutauschen, dass die Daten nicht
erneut geladen werden müssen.
In der
Grid View
wird jeder Fragebogen in einer extra Komponente dargestellt. Die
Fragebogen-Komponenten werden dann im Grid-Format aneinander gereiht. In Abbil-
dung 6.5 ist diese Komponente mit Dummy-Daten dargestellt. Der Grün hinterlegte Preis
ist der
Model Preis
des Fragebogens. Über dem Titel stehen die Schlüsselwörter, die
den Bereich des Fragebogens näher beschreiben. Unter dem Titel stehen die ersten
Zeichen der Beschreibung. Mehr Informationen über den Fragebogen erhält der Nutzer
über die jeweilige Detail-Seite.
Abbildung 6.5: Fragebogen Komponente der Grid View
42
6.3 Aufbau des Shops
In der
List View
werden die Fragebögen in Tabellenform angezeigt. Wie in Abbildung
6.6 zu sehen ist, wird für jeden Fragebogen eine Zeile verwendet. Die
List View
ermöglicht eine kompaktere Darstellung der Fragebögen als die
Grid View
. Zusätzlich
stehen in dieser Ansicht weitere Informationen auf einen Blick bereit. Auch von der
List
View aus ist es möglich Fragebögen in der Detail-Seite anzuschauen.
Abbildung 6.6: Fragebogen Komponenten in der List View
Für beide Views wird die
Pagination
Komponente aus Abschnitt 6.2.2 verwendet,
um die erhaltenen Fragebögen übersichtlich darzustellen. Beim Seitenwechsel werden
die Fragebögen der gewünschten Seite als
questionnaire
-Model vom
ApiService
geladen. Welche Fragebögen genau geladen werden, hängt von der ausgewählten
Kategorie ab. In Abschnitt 5.3.1 wird bereits beschrieben, dass die Fragebögen einer
bestimmten Kategorie zugeordnet werden. Das Auswählen der Kategorie erfolgt in zwei
Schritten.
Im ersten Schritt lassen sich die Oberkategorien auswählen. Dazu befindet sich auf der
linken Seite der Anwendung ein Navigationsmenü, welches in Abbildung 6.7 dargestellt
ist. Die Kategorien werden über den
ApiService
vom Server geladen. Durch das Aus-
wählen einer Kategorie werden alle der Kategorie zugeordneten Fragebögen geladen
und in der ausgewählten View angezeigt. Neben den Kategorien besteht zudem die
Möglichkeit sich alle Fragebögen anzeigen zu lassen.
Im zweiten Schritt können die Unterkategorien einer Kategorie ausgewählt werden.
Dazu steht ein
Select
-Button zur Verfügung, der ein Menü mit den Unterkategorien
öffnet. Die direkten Unterkategorien der Oberkategorie sind mit grauem Hintergrund
43
6 Implementierung
Abbildung 6.7: Navigationsmenü innerhalb des Shops
hervorgehoben. Alle weiteren Unterkategorien folgen, wie in Abbildung 6.8 zu sehen ist,
als Liste ohne auf die jeweilige Stufe im Baum einzugehen. Das Menü ändert sich mit
dem Auswählen einer Unterkategorie nicht, sondern bleibt innerhalb einer Oberkategorie
immer gleich.
Weckt ein Fragebogen das Interesse des Benutzers, kann dieser den Fragebogen auf
der
Detail
-Seite genauer betrachten. Dort kann der Benutzer die ganze Beschrei-
bung lesen, sieht den
Model
und
Instance
Preis oder kann sich über den Autor des
Fragebogens informieren. Der Fragebogen kann in der Rolle als Standardnutzer zum
Warenkorb hinzugefügt werden. Dazu muss die Anzahl an gewünschten Lizenzen ange-
geben werden. In Abbildung 6.9 ist dieser Schritt abgebildet.
Im Warenkorb werden alle enthaltenen Fragebögen kurz mit dem Titel und dem Preis
aufgelistet. Zusätzlich ist es möglich die Anzahl der Lizenzen eines Fragebogens zu
ändern, sowie Fragebögen ganz aus dem Warenkorb zu entfernen. In Abbildung 6.10 ist
ein Ausschnitt der Warenkorb Seite zu sehen. Sie zeigt die Darstellung der Fragebögen
44
6.3 Aufbau des Shops
Abbildung 6.8: Unterkategorien innerhalb des Shops
Abbildung 6.9: Detail-Seite eines Fragebogens mit Option Warenkorb
45
6 Implementierung
im Warenkorb. Zudem gibt es auf der Seite noch weitere Komponenten zum Beispiel eine
Komponente, die den Gesamtpreis aller Produkte mit Steuern anzeigt. Der Warenkorb
ist mit dem Server synchronisiert, so dass dieser zu jedem Zeitpunkt auf dem aktuellsten
Stand ist. Werden Änderungen am Warenkorb vorgenommen, werden diese sofort dem
Server mitgeteilt.
Abbildung 6.10: Inhalt des Warenkorbs
Vom Warenkorb aus, der zu jeder Zeit über die
Top-Navigation-Bar
(siehe auch
Abbildung 6.4) erreichbar ist, kann der Kauf der Fragebögen gestartet werden. Der Kauf
wird über eine
Payment
-Seite abgewickelt. Auf dieser kann der Nutzer aus verschiede-
nen Zahlungsmitteln wählen (siehe in Abbildung 6.11). Aktuell steht zu Testzwecken nur
ein Internal Credit System zur Verfügung. Weitere Zahlungssysteme für den späteren
Einsatz können an dieser Stelle ergänzt werden.
6.3.2 Home
In diesem Abschnitt wird kurz der
Home
-Bereich der Anwendung beschrieben. Im
Home
-
Bereich existiert aktuell eine
Dashboard
-Seite, auf welcher der Standardnutzer eine
Übersicht über die von ihm getätigten Transaktionen erhält. Zusätzlich steht eine Über-
sicht über alle gekauften Fragebögen und den Stand der Lizenzen zur Verfügung.
46
6.3 Aufbau des Shops
Abbildung 6.11: Payment mit einem Internal Credits Account
6.3.3 Management
In diesem Abschnitt wird der
Management
-Bereich der Anwendung beschrieben. Im
Management-Bereich werden alle Fragebögen angezeigt, die der Benutzer bearbeiten
kann. Auf diesen haben, wie bereits in Abschnitt 5.3.2 beschrieben, nur Nutzer mit
der Rolle
Merchant
zugriff. Dies wird durch einen
Role Guard
sichergestellt. Der
Management-Bereich hat für die Fragebögen eine eigene
Detail
-Seite, in der im
Vergleich zur
Detail
-Seite des Shop-Bereichs weitere Informationen, wie vorherige
Versionen des Fragebogens zur Verfügung gestellt werden.
Des Weiteren können im Management-Bereich Fragebögen bearbeitet werden. Der
Bearbeitungsvorgang ist in mehrere Schritte, die in Abbildung 6.12 dargestellt sind,
aufgeteilt.
Abbildung 6.12: Management: Schritte bei der Bearbeitung eines Fragebogens
47
6 Implementierung
Die einzelnen Schitte bestehen jeweils aus einem Formular, welches die Eingaben über-
prüft. Im ersten Schritt des Bearbeitungsvorgangs können allgemeine Daten angegeben
werden. Dazu gehören Titel, Beschreibung und die Schlüsselwörter des Fragebogens.
Zusätzlich kann in diesem Schritt die zugehörige Kategorie geändert werden. In Abbil-
dung 6.13 ist dieser Schritt abgebildet. Instrument ist die ID, mit der auf dem Server das
questionnaire Model mit dem eigentlichen Fragebogen verknüpft ist.
Im zweiten Schritt können die Kontaktdaten des Ansprechpartners geändert werden.
Zu den Kontaktdaten zählen Name, E-Mail und Uri. Im dritten Schritt kann der Preis
des Fragebogens bearbeitet werden. Dies betrifft sowohl den
Model
-Preis, als auch
den
Instance
-Preis. Im vierten Schritt können die Bilder des Fragebogens verwaltet
werden. Im letzten Schritt sind alle Informationen der vorherigen Schritte noch einmal
zur Überprüfung aufgeführt.
Abbildung 6.13:
Management: Der Erste Schritt bei der Bearbeitung eines Fragebogens
48
7
Zusammenfassung
Im Rahmen dieser Arbeit wurde ein Shop entwickelt, mit dem sich Fragebögen des
Projektes QuestionSys veröffentlichen und bereitstellen lassen. Als Erstes wurden be-
reits vorhandene Fragenbogensysteme analysiert und verglichen. Dabei lag der Fokus
auf der Verteilung und der Monetarisierung der Fragebögen. Aus diesen Erkenntnissen
wurden in Kapitel 4 funktionale und nicht-funktionale Anforderungen aufgestellt. Als
nächstes wurde der Shop konzipiert. Dazu wurden zuerst Ansätze zur Veröffentlichung
und Monetarisierung digitaler Fragebögen angeschaut. Anschließend wurde für den
Shop ein Monetarisierungsmodell entworfen. Danach wurde das Konzept für zusätzliche
Bereiche des Shops erweitert. Darauf aufbauend wurde mit der Implementierung des
Shops begonnen.
Der Shop wurde in drei Bereichen implementiert. Der Hauptfokus lag dabei auf dem
Shop-Bereich. In diesem können die Fragebögen in verschiedenen Kategorien ange-
schaut und entsprechend dem Monetarisierungsmodell gekauft werden. Damit sind die
funktionalen Anforderungen FA1 und FA2 aus Abschnitt 4.1 erfüllt. Vor dem Kaufen der
Fragebögen, können diese in den Warenkorb gelegt werden. Änderungen am Warenkorb
werden direkt dem Server mitgeteilt, so dass dieser immer den aktuellen Stand des
Warenkorbes besitzt. Somit ist auch FA4 erfüllt. Im Management-Bereich, der nur mit
einer bestimmten Rolle zugänglich ist, lassen sich die eingestellten Fragebögen und
die Preise ändern. Dies erfüllt die funktionalen Anforderungen FA6, FA8 und FA9. Im
Home-Bereich gibt es eine Übersicht über alle erworbenen Fragebögen, womit auch
FA5 erfüllt ist.
49
7 Zusammenfassung
Der Shop gliedert sich in das Projekt QuestionSys ein. Die im Konfigurator erstellten
Fragebögen sollen sich in den Shop einfügen lassen. Der Server ist dabei das Bindeglied
und somit für die Kommunikation zuständig. Alle Daten des Shops werden dynamisch
vom Server geladen. Bei der Implementierung des Shops wurde zudem darauf geachtet,
dass die nicht-funktionalen Anforderungen aus Abschnitt 4.2 erfüllt sind.
7.1 Ausblick
Für die zukünftige Entwicklung des Shops, sind verschiedene Erweiterungen vorstellbar.
Zum einen könnte der Management-Bereich ausgebaut werden, so dass er Statistiken
und Grafiken zu den eingestellten Fragebögen erhält. Diese könnten zum Beispiel
anzeigen, wie oft und in welchem Zeitraum Fragebögen verkauft worden sind. Zudem
könnte aufgelistet werden, wie viel Geld mit den Fragebögen eingenommen wurde.
Zum anderen könnte der Home-Bereich erweitert werden. Auch hier könnten Statistiken
und Grafiken für den Käufer von Fragebögen hinzugefügt werden. Zum Beispiel könnte
es eine genaue Übersicht über die Anzahl an verbrauchten Lizenzen geben.
Im Shop-Bereich könnten beim Payment weitere Zahlungsmöglichkeiten hinzugefügt
werden. Dies wird vor allem nötig, wenn der Shop aktiv wird. Das Internal Credits System
muss dann durch richtige Zahlungssysteme ersetzt werden.
50
Literaturverzeichnis
[1]
Moser, H.: Strategisches Projektmanagement im Gesundheitswesen: Wie
Stakeholder
auf ein Sensitivitätsmodell einwirken - eine Analyse, disserta
Verlag
(2013) 151–152
[2]
Schobel, J., Pryss, R., Schickler, M., Reichert, M.: Towards Flexible Mobile Data
Collection in Healthcare. In: 29th IEEE International Symposium on Computer-
Based Medical Systems (CBMS 2016). (2016) 181–182
[3]
Schobel, J., Pryss, R., Schlee, W., Probst, T., Gebhardt, D., Schickler, M.,
Reichert
,
M.: Development of Mobile Data Collection Applications by Domain Experts:
Experimental
Results from a Usability Study. In: 29th International Conference
on Advanced Information Systems Engineering (CAiSE 2017). Number 10253 in
LNCS, Springer (2017) 60–75
[4]
Institut für Datenbanken und Informationssysteme (DBIS): QuestionSys - A
Generic and Flexible Questionnaire System Enabling Process-Driven
Mobile
Data
Collection
. (Website)
https://www.uni-ulm.de/in/iui-dbis/
forschung/laufende-projekte/questionsys/
; abgerufen am 02. Juni
2018.
[5]
Schobel, J., Pryss, R., Schickler, M., Ruf-Leuschner, M., Elbert, T., Reichert,
M.: End-User Programming of Mobile Services: Empowering Domain Experts
to
Implement
Mobile Data Collection Applications. In: 5th IEEE International
Conference
on Mobile Services (MS 2016), IEEE Computer Society Press (2016)
1–8
[6]
Schobel, J., Pryss, R., Schickler, M., Reichert, M.: A Lightweight Process Engine
for Enabling Advanced Mobile Applications. In: 24th International Conference on
Cooperative Information Systems (CoopIS 2016). Number 10033 in LNCS, Springer
(2016) 552–569
51
Literaturverzeichnis
[7]
Schobel, J., Pryss, R., Schickler, M., Reichert, M.: A Configurator Component for
End-User Defined Mobile Data Collection Processes. In: Demo Track of the 14th
International Conference on Service Oriented Computing (ICSOC 2016). (2016)
[8]
LimeSurvey GmbH: LimeSurvey: An open source survey tool. (Website)
https:
//www.limesurvey.org/; abgerufen am 15. Mai 2018.
[9]
LimeSurvey GmbH: LimeSurvey: Editionen & Preise: Pro. (Websi-
te)
https://www.limesurvey.org/de/editionen-und-preise/
limesurvey-pro/editionen-and-preise-professional
; abgerufen
am 15. Mai 2018.
[10]
Creative Research Systems: Survey Software - The Survey System. (Website)
https://www.surveysystem.com/index.htm; abgerufen am 15. Mai 2018.
[11]
QuestionPro GmbH: QuestionPro: Professionelle Online-Umfrage und Analyse-
Plattform. (Website)
https://www.questionpro.de/
; abgerufen am 16. Mai
2018.
[12]
QuestionPro GmbH: QuestionPro: Preise & Konditionen. (Website)
https://www.
questionpro.de/umfrage-software-preise-konditionen/
; abgerufen
am 16. Mai 2018.
[13]
Google LLC: Google Play Store. (Website)
https://play.google.com/store
;
abgerufen am 16. Mai 2018.
[14]
Google LLC: Play Console: Google Play-Entwicklerkonto. (Web-
site)
https://support.google.com/googleplay/android-developer/
answer/6112435; abgerufen am 16. Mai 2018.
[15]
Google LLC: Play Console: Transaktionsgebühren. (Website)
https://support.
google.com/googleplay/android-developer/answer/112622
; abgeru-
fen am 16. Mai 2018.
[16]
SurveyMonkey Europe UC : SurveyMonkey. (Website)
https://de.
surveymonkey.com/; abgerufen am 18. Mai 2018.
52
Literaturverzeichnis
[17]
Survey Planet LLC : SurveyPlanet: A simple & powerful online survey tool. (Website)
https://surveyplanet.com/; abgerufen am 18. Mai 2018.
[18]
movisens GmbH : MovisensXS: Experience Sampling Lösung für Android. (Web-
site)
https://www.movisens.com/de/produkte/movisensxs/
; abgerufen
am 27. Mai 2018.
[19]
Zoho Corporation Pvt. Ltd. : Zoho: Experience the craft of survey creation. (Website)
https://www.zoho.eu/survey/; abgerufen am 27. Mai 2018.
[20]
Google: Angular 5: Architecture overview. (Website)
https://angular.io/
guide/architecture; abgerufen am 01. Juni 2018.
[21]
Microsoft: TypeScript. (Website)
https://www.typescriptlang.org/
; abge-
rufen am 01. Juni 2018.
[22]
WebAppLayers: INSPINIA - Responsive Admin
Theme
. (Website)
https://wrapbootstrap.com/theme/
inspinia-responsive-admin-theme-WB0R5L90S
; abgerufen am 01.
Juni 2018.
[23]
Google: Angular: Introduction to services and dependency injection. (Website)
https://angular.io/guide/architecture-services
; abgerufen am 30.
Mai 2018.
[24]
Agarwal, U.: Hands-On Full Stack Development with Angular 5 and Firebase: Build
real-time, serverless, and progressive web applications with Angular and Firebase,
Packt Publishing Ltd. (2018) 20–22
53
Abbildungsverzeichnis
2.1 Lebenszyklus zur Erhebung mobiler Daten [4, 5, 6] . . . . . . . . . . . . . 4
2.2 Komponenten des Fragebogensystems QuestionSys . . . . . . . . . . . . 4
5.1 Fragebogen Model im Shop . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Aufbau der Kategorien als Beispiel . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Anwendungsfalldiagramm Nutzerrolle Gast . . . . . . . . . . . . . . . . . 29
5.4 Anwendungsfalldiagramm Nutzerrolle Standardnutzer . . . . . . . . . . . 30
5.5 Anwendungsfalldiagramm Nutzerrolle Merchant . . . . . . . . . . . . . . . 31
6.1 Sequenzdiagramm zum Laden von Daten vom Server . . . . . . . . . . . 39
6.2 Pagination Komponente mit 3 Seiten . . . . . . . . . . . . . . . . . . . . . 40
6.3 Breadcrumb Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4 Navigation über Top-Navigation-bar .................. 41
6.5 Fragebogen Komponente der Grid View .................. 42
6.6 Fragebogen Komponenten in der List View ................ 43
6.7 Navigationsmenü innerhalb des Shops . . . . . . . . . . . . . . . . . . . . 44
6.8 Unterkategorien innerhalb des Shops . . . . . . . . . . . . . . . . . . . . 45
6.9 Detail-Seite eines Fragebogens mit Option Warenkorb . . . . . . . . . . 45
6.10 Inhalt des Warenkorbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.11 Payment mit einem Internal Credits Account . . . . . . . . . . . . . . . . . 47
6.12 Management: Schritte bei der Bearbeitung eines Fragebogens . . . . . . 47
6.13 Management: Der Erste Schritt bei der Bearbeitung eines Fragebogens . 48
55
Name: Lars Miltkau Matrikelnummer: 789732
Erklärung
Ich erkläre, dass ich die Arbeit selbstständig verfasst und keine anderen als die angege-
benen Quellen und Hilfsmittel verwendet habe.
Ulm,den .............................................................................
Lars Miltkau
