Entwicklung und Implementation einer Mobile Application und Dokumentation des Software-Engineering-Prozesses

Projektarbeit , 2021 , 69 Seiten , Note: 1,3

Informatik - Software

Das Ziel unser Android App mit dem Namen ActivFin ist es, Finanzen, offene Rechnungen, Einkäufe und Haushaltsaktivitäten unter Kontrolle zu behalten. Um die Finanzen jederzeit im Blick zu haben können die Einnahmen/ Ausgaben getracked, gespeichert, ausgewertet, kategorisiert werden. Rechnungen können mit Einnahmen/ Ausgaben verknüpft werden, damit man auch im Nachhinein noch Bezug dazu hat. Ebenfalls können Rechnungen auch mit anderen Personen geteilt werden, um nicht auf Kosten sitzen zu bleiben. Damit der Nutzer jederzeit über Änderungen (z.B. eingehende Zahlungen) informiert ist, wird der Nutzer über Push-Nachrichten auf dem aktuellen Stand gehalten. Diese Push-Nachrichten können gesetzte Grenzen, die vom Nutzer festgelegt worden sind, informieren.

Ebenso besitzt die App die Möglichkeit, Rechnungen mit Freunden und Gruppen teilen zu können. Dafür wird innerhalb der App die “Freunde”-Funktion verwendet. Diese bietet die Möglichkeit Personen hinzuzufügen, diese Gruppen zuzuordnen, damit der Nutzer innerhalb der App Rechnungen/ Zahlungsaufforderungen an diese weitergeben kann. Da die App keine reine Finanzapp sein soll, soll dem Nutzer auch die Möglichkeit gegeben werden, Pläne (Einkaufsliste, Haushaltsplan, etc.) zu erstellen. Dabei kann der Nutzer ebenfalls über Push-Nachrichten informiert werden, wenn festgelegte Termine bevorstehen. Die Planung der Haushaltsaktivitäten ist nicht in jedem Haushalt gut organisiert. Dadurch wird die App eine Kategorie enthalten, wo die Aktivitäten verwaltet werden können. Der Nutzer kann z. B. die Putz- oder Kochreihenfolge der Mitglieder eines Haushalts mithilfe eines Kalenders verwalten und organisieren.

Inhaltsverzeichnis

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Motivation zum Proj ekt
1.2 Themenfindung und Zielstellung
1.3 Bereits existierende Mobile Applications

2 Requirements Engineering
2.1 Zielgruppenfestlegung
2.2 Definition von Personas und deren Ausgangssituation
2.3 Ermittlung der Anforderungen
2.4 Spezifikation der Anforderungen
2.4.1 Funktionale Anforderungen
2.4.2 Nicht funktionale Anforderungen
2.4.3 Entwicklung von User Storys

3 Konzeption und Design
3.1 Interaktionsdesign
3.2 Arten des Prototypen
3.3 Prototyping
3.3.1 Low- Fidelity
3.3.2 High- Fidelity
3.4 Seitenspezifikation
3.5 UI / UX - Design
3.5.1 Namensfindung
3.5.2 Konzeption des Logos
3.5.3 F arbauswahl
3.5.4 Themen Design

4 Architektur
4.1 Projektmanagement
4.1.1 Wahl der Entwicklungsmethode
4.1.2 SCRUM
4.2 Hardware
4.2.1 Wahl der Zielplattform
4.2.2 Schwierigkeiten beim Bereitstellen der Entwicklungshardware
4.3 Software
4.3.1 Grobarchitektur, Wunsch gegen Realität
4.3.2 Wahl der Entwicklungsplattform
4.3.3 Wahl des Architektur Pattern
4.3.4 Entwicklungsmodule nach Use Case Analyse
4.3.5 Entwicklung der Datenbank Schemata
4.3.6 Weitere Technol ogien

5 Implementierung
5.1 Zuordnung der Business Logik
5.1.1 Activity oder Fragment
5.1.2 Services
5.2 XML- Designstruktur
5.2.1 Login-Activity
5.2.2 Finanzen-Activity
5.3 Login, Registration und sonstiges
5.3.1 Implementation von Login und Registrierung
5.3.2 Ergänzende Funktionen und Besonderheiten bei Implementierung
5.4 Finanzen
5.4.1 Analyse der Implementierungsaufgaben
5.4.2 Priorisierung der Implementierungsaufgaben
5.4.3 Schnittstellen
5.4.4 Datenbank Schema
5.4.5 Schwierigkeiten
5.5 Freunde und Gruppen
5.5.1 Analyse der Implementierungsaufgaben
5.5.2 Priorisierung der Implementierungsaufgaben
5.5.3 Schnittstellen
5.5.4 Datenbank Schema
5.5.5 Schwierigkeiten

6 Testing

7 Fazit und technischer Ausblick
7.1 Fazit
7.2 Technischer Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1 - Zielgruppenfestlegung nach den 4 Hauptmerkmalen

Abbildung 2 - Spezifikation der Personas in ihren Eigenschaften

Abbildung 3 - Szenarienbeschreibung der Personas 1 und

Abbildung 4 - Darstellung der möglichen Anwendungsfälle in Diagrammform

Abbildung 5 - Aufgliederung der Anforderungen in zwei Bereiche

Abbildung 6 - Auflistung der funktionalen Anforderungen

Abbildung 7 - Auflistung der nicht funktionalen Anforderungen

Abbildung 8 - User Storys zum Beschreiben der Anforderungen

Abbildung 9 - Interaktionsdesign ActivFin

Abbildung 10 - Low-Fidelity Prototyp

Abbildung 11 - Low-Fidelity Prototyp

Abbildung 12 - High - Fidelity Prototyp

Abbildung 13 - Login Seitespezifikation

Abbildung 14 - Finaler Prototyp

Abbildung 15 - Namen der App

Abbildung 16 - Logos der App

Abbildung 17 - Farben der App

Abbildung 18 - Themen

Abbildung 19 - Android OS Popularity

Abbildung 20 -Wunsch Grobarchitektur

Abbildung 21 - Realität Grobarchitektur

Abbildung 22 - Ordner Struktur Android Studio

Abbildung 23 - Umzusetzende Module

Abbildung 24 - Umzusetzende Module

Abbildung 25 - XML Attributen

Abbildung 26 - Login Activity

Abbildung 27 - XML Login Activity

Abbildung 28 - Linear Layout

Abbildung 29 - XML Text View - Email

Abbildung 30 - XML Button - Anmelden

Abbildung 31 - Finanzen Activity

Abbildung 32 - Component Tree Finanzen Activity

Abbildung 33 - Darstellung der zu implementierenden Aufgaben

Abbildung 34 - Darstellung der Klasse User

Abbildung 35 - Darstellung des Datenbankschemata eines Nutzerkontos

Abbildung 36 - Implementierung der Datenbanktabelle mit allen Eigenschaften

Abbildung 37 - Anmelde- und Registierungsmaske

Abbildung 38 - Hinzufügen eines Nutzerkontos in der Datenbank

Abbildung 39 - Auslesen von Nutzerdaten aus der Datenbank

Abbildung 40 - Updateprüfung, Abbildung zeigt einen Fall mit Versionsunterschieden

Abbildung 41 - Passwort vergessen wurde angeklickt

Abbildung 42 - Reaktivierung des Nutzeraccounts

Abbildung 43 - Darstellung der zu prüfenden Pattern

Abbildung 44 - Regexprüfung von E- Mail und Passwort

Abbildung 45 - Generieren SHA 1 Hashwert

Abbildung 46 - Generierung des Salt Wertes

Abbildung 47 - Passwortprüfung

Abbildung 48 - Finanz Übersicht

Abbildung 49 - Anforderungen für Finanz Chart

Abbildung 50 - Datenbank Schema Single Transaction

Abbildung 51 - Anforderungen für Freunde Anlegen

Abbildung 52 - ER Diagramm Freunde/ Gruppen

Abbildung 53 - Datenbank Schema Freunde/ Gruppen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Wir leben heutzutage im Zeitalter der Technik, Computer, Handys, Smartphones, Tablets, welche sich zu einem festen Bestandteil unseres Lebens entwickelt haben. Gerade Smartphones sind oft unsere täglichen Begleiter und auch Helfer. Mobile Apps sind aus unserem privaten und beruflichen Alltag nicht mehr wegzudenken. Wir kommunizieren mit unseren Smartphones via WhatsApp, Facebook- oder E-Mail-App mit Freunden, Kommilitonen, Kunden und Geschäftspartnern, schreiben und lesen Skripte, Folien und andere studien- bzw. geschäftsrelevante Dokumente über unsere Tablets. Weiter führen wir Überweisungen via Banking-App durch und buchen einzelne Flüge oder ganze Urlaube über mobile Apps. Auch die Suche nach dem besten Facharzt oder der preiswertesten Tankstelle in der Umgebung lässt sich mithilfe einer App schnell und einfach erledigen. In der Vergangenheit hatte man ein Heft zum Planen von Einnahmen und Ausgaben, heute verwalten wir sie mit Hilfe von Apps am Handy. Die Motivation zu unserem Projekt haben wir genau da gefunden: der Bedarf alles digital dabei zu haben, planen und managen.

Zunächst wird in Abschnitt 1.1 die Motivation der vorliegenden Arbeit erläutert. Anschließend werden in Abschnitt 1.2 das Themenfindung und Zielstellung und in Abschnitt 1.3 drei Beispiele für bereits existierende Mobile Applikationen vorgestellt.

1.1 Motivation zum Projekt

Wenn man im Haushalt voll ausgelastet ist, fällt es oft schwer den Überblick über alles zu behalten. Das kann besonders bei der Finanzplanung schnell zum Problem werden. Sowohl Kleinigkeiten wie die Rückzahlung des gestrigen Frühstücks an einen Freund, als auch die monatlichen Ausgaben sollten geplant werden. Mit dem Führen eines Haushaltsbuches werden nicht nur die monatlichen Ausgaben aufgezeigt, sondern es fällt auch leichter die eigenen Finanzmittel im Auge zu behalten und zu planen. Erweitert man dieses Haushaltsbuch noch um eine Aufgabenplanung für den Haushalt, sowie eine Einkaufsliste, entsteht eine zentrale Schnittstelle für die Planung des gesamten Haushaltes.

Daher wollen wir genau eine solche App entwickeln. Mit dieser App soll es möglich sein, sich mit seinen Mitbewohnern und Freunden zu verbinden, um damit Kosten, Einkäufe und Hausarbeiten gemeinsam koordinieren zu können. Hier können die eigenen Finanzen eingetragen, ausgelegte Rechnungen mit Freunden geteilt und diese auch an ausstehende Zahlungen erinnert werden. Für die Aufgabenplanung können, für alle Bewohner sichtbar, Aufgaben erstellt werden, damit jeder weiß, was erledigt werden muss. Außerdem wird mit der Erstellung einer gemeinsamen Einkaufsliste sichergestellt, dass sämtliche benötigten Lebensmittel, Drogerie- und sonstigen Artikel besorgt werden. Die

Beträge lassen sich auch gleich mit der vorher beschriebenen Funktion, Rechnungen zu teilen, einfach aufteilen. Um die Aufgaben und Finanzen nicht zu vergessen, dienen Push­Nachrichten als Erinnerung.

1.2 Themenfindung und Zielstellung

Das Ziel unser Android App mit dem Namen ActivFin, ist es, Finanzen, offene Rechnungen, Einkäufe und Haushaltsaktivitäten unter Kontrolle zu behalten.

Um die Finanzen jederzeit im Blick zu haben können die Einnahmen/ Ausgaben getracked, gespeichert, ausgewertet, kategorisiert werden. Rechnungen können mit Einnahmen/ Ausgaben verknüpft werden, damit man auch im Nachhinein noch Bezug dazu hat. Ebenfalls können Rechnungen auch mit anderen Personen geteilt werden, um nicht auf Kosten sitzen zu bleiben. Damit der Nutzer jederzeit über Änderungen (z.B. eingehende Zahlungen) informiert ist, wird der Nutzer über Push Nachrichten auf dem aktuellen Stand gehalten. Diese Push Nachrichten können gesetzte Grenzen, die vom Nutzer festgelegt worden sind, informieren.

Ebenso besitzt die App die Möglichkeit, Rechnungen mit Freunden und Gruppen teilen zu können. Dafür wird innerhalb der App die “Freunde” Funktion verwendet. Diese bietet die Möglichkeit Personen hinzuzufügen, diese Gruppen zuzuordnen, damit der Nutzer innerhalb der App Rechnungen/ Zahlungsaufforderungen an diese weitergeben kann. Da die App keine reine Finanz App sein soll, soll dem Nutzer auch die Möglichkeit gegeben werden Pläne (Einkaufsliste, Haushaltplan, etc.) zu erstellen. Dabei kann der Nutzer ebenfalls über Push Nachrichten informiert werden, wenn festgelegte Termine bevorstehen. Die Planung der Haushaltsaktivitäten ist nicht in jedem Haushalt gut organisiert. Dadurch wird die App eine Kategorie enthalten, wo die Aktivitäten verwaltet werden können. Der Nutzer kann z. B. die Putz- oder Kochreinfolge der Mitglieder eines Haushalts mithilfe eines Kalenders verwalten und organisieren.

Was macht eine gute Finanz- bzw. Haushaltbuch App aus?

- Erfassung aller getätigten Ausgaben und Einnahmen
- Grafische Auswertung der Daten für den visuellen Überblick
- Übersicht über monatliche Fixkosten
- Verwalten des persönlichen Monatsbudgets
- Hilfe beim Sparen durch Statistiken über einzelnen Ausgabenkategorien
- Erstellen eigener Kategorien für Einnahmen und Ausgaben
- Gemeinsame Haushaltsplanung für Paare
- Hilfe beim Teilen gemeinsamer Ausgaben

1.3 Bereits existierende Mobile Applications

Monefy

Anhand der eingetragenen Daten erstellt die App automatisch eine personalisierte Finanzübersicht. In Tages-, Wochen-, Monats- oder Jahresübersichten sind die einzelnen Kostenstellen wie Auto, Lebensmittel oder Freizeit übersichtlich aufgeführt, was die finanzielle Einschätzung der persönlichen Lebensführung enorm erleichtert. Auch mögliches Potential zum Kosteneinsparen wird so aufgedeckt.

Money Manager Expense & Budget

Mit dieser App können unkompliziert mehrere Bankkonten verwalten werden. Sowohl Einkünfte als auch Ausgaben können bequem einem jeweiligen Konto zugewiesen werden, worüber sich die Ausgaben der Konten tracken lassen. Gleichzeitig lassen sich Ausgabengrenzen setzen, die bei der Budget Verwaltung helfen.

Tricount

Die Finanz App Tricount bietet einfache Lösungen zum Aufteilen von Rechnungen und Gruppenkosten aller Art, ohne vorher komplizierte Excel-Tabellen erstellen zu müssen. Die App eignet sich daher zum Beispiel auch ideal für das Teilen der Kosten während gemeinsamer Urlaube oder zur gerechten Aufteilung der Haushaltkosten für WGs.

2 Requirements Engineering

Im Requirements Engineering geht es primär um die Analyse und Spezifikation der einzelnen Anforderungen an ein Produkt und in diesem Falle an die App ActivFin.

Speziell ist dieser Abschnitt in mehrere Unterkapitel eingeteilt, um schrittweise die erforderlichen Anforderungen an die Mobile Applikation zu spezifizieren.

Um einen kurzen Einblick in das Kapitel zu erhalten, wird für das Vorgehen erstmals die Zielgruppe festgelegt, um gezielte Personengruppen ansprechen zu können.

Der nächste Abschnitt bezieht sich auf die Definition von zwei fiktiven Personas, welche innerhalb dieser Zielgruppe liegen. Diese Personas zeichnen sich durch verschiedene Charakteristiken aus. Aus diesen Charaktereigenschaften wird zu der jeweiligen Persona ein Szenario entwickelt, um die Lebenswelt dieser Zielgruppe für alle Projektbeteiligten besser darstellen zu können.

Ein weiterer Vorteil ist, dass ergänzende Rückschlüsse auf Anforderungen gezogen werden können, die unter Kapitel 1.3 mit verschiedenen Methoden für das Softwareprodukt ermittelt werden.

Aus der Sammlung aller ermittelten Anforderungen, müssen einige von ihnen tiefgreifender für die konkrete Umsetzung spezifiziert werden. Somit bildet das Requirements Engineering den Grundbaustein für die Herangehensweise der Entwicklung einer mobilen Applikation.

2.1 Zielgruppenfestlegung

Im Requirements Engineering geht es primär um die Analyse und Spezifikation der einzelnen Anforderungen an ein Produkt und in diesem Falle an die App. Um jedoch Anforderungen festlegen zu können, welche Gruppen von Personen angesprochen werden sollen.

Gemeint ist, die Beschreibung und Festlegung der Zielgruppe. Auch in der Softwareplanung ist dieses Vorgehen ein wesentlicher Bestandteil für die Entwicklung von konkreten Anforderungen an das Softwareprodukt.

Zur Bestimmung der Zielgruppe kann, wie aus dem Marketing bekannt, vorgegangen werden. Die Zielgruppe wird im ersten Schritt in 4 Hauptkategorien eingeteilt. Die Hauptkategorien sind die demografischen (z. B. Alter, Geschlecht, Wohnort), sozioökologischen (quantitativ z. B. Bildung, Einkommen, Beruf), psychografischen (z. B. Bedürfnisse, Werte, Hobbys) Merkmale und das Kaufverhalten (z. B. Neigungen, Gewohnheiten, Beeinflussbarkeit) [3, pp. 45-51] .

Um eine definierte Zielgruppe festzulegen, müssen Abstimmungen bezüglich der beschriebenen Hauptkategorien getroffen werden. Im Anwendungsfall der App ActivFin wurde das Brainstorming als Kreativitätstechnik zur Bestimmung der Zielgruppe, wie in Abbildung 1 ersichtlich, angewendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 - Zielgruppenfestlegung nach den 4 Hauptmerkmalen

Im Abschnitt 1.2 werden zwei konkrete Beispiele zu fiktiven Personen (Personas) die innerhalb der Zielgruppe liegen verdeutlicht.

2.2 Definition von Personas und deren Ausgangssituation

Wie bereits im Abschnitt 2.1 beschrieben, geht es in diesem Kapitel um die Definition bzw. die Vorstellung von zwei entwickelten Personas, siehe Abbildung 2 . Eine Persona ist ein frei erfundener Benutzer der App, welcher innerhalb der definierten Zielgruppe liegt. Personas haben wie reale Nutzer Bedürfnisse, Gewohnheiten und Ziele, welche durch das Softwareprodukt unterschiedlich stark angesprochen werden.

Um nun detailliert auf eine entwickelte Persona eingehen zu können, wird zu jeder Persona ein Szenario entwickelt, welches dazu dient, Anforderungen an die App ausfindig zu machen. Ein typisches Szenario enthält den Ausgangszustand der Persona, die Beschreibung des Normalfalls, die Beschreibung des Fehlerfalls, parallel ablaufende Aufgaben und den Zustand der App, wenn das Szenario endet [1, pp. 67-72] .

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 - Spezifikation der Personas in ihren Eigenschaften

Wie bereits erwähnt, wird die Erstellung von Szenarien zu den jeweiligen Personas oftmals auch ergänzend für die Ermittlung der Anforderungen an das Softwareprodukt herangezogen.

Auch im Fall der App ActivFin dienen die Szenarien, welche in Abbildung 3 ersichtlich ist, unterstützend für die Entwicklung eines Anwendungsfall- Diagramms (Use Case Diagramm), um die notwendigen Anforderungen zu verdeutlichen.

Szenario Persona 1: Anja

1. Ausgangszustand der Persona

Anja ist 18 Jahre und hat gerade ihre Ausbildung als KFZ- Mechatronikerin angefangen, direkt zum Anfang ihrer Ausbildung ist sie in eine WG gezogen. Mit Ihrer WG versteht sie sich gut, dennoch gibt es oft Streit, da sie immer den Putzplan vergisst und noch ihre alten Gewohnheiten besitzt. Auch das Einkaufen fällt ihr schwer, sie kauft ungeplant ein und dadurch meist Fertigprodukte. Diese sind nicht immer günstig und somit ist sie am Monatsende knapp bei Kasse und muss sich Geld bei ihren Mitbewohnern leihen. Mit der Zeit ist die WG genervt und möchte die Kosten für das Mitkochen und leihen des Geldes auf Anja zurückübertragen. Gleichzeitig soll Anja auch mehr Struktur in ihren Alltag und ihre Finanzen bringen. Somit hat die WG bei einer Intervention beschlossen, dass Anja eine App für die Alltagsplanung herunterladen muss. Anja willigt ein und lädt sich die App herunter.

2. Beschreibung des Normalfalls

Nachdem Anja die App heruntergeladen hat, erstellt sie sich einen Account und meldet sich an. Um sich bei der WG zu entschuldigen, plant Anja am Monatsende ein Abendessen und packt viele Zutaten auf die neu angelegte Einkaufsliste innerhalb der App. Um ihre Finanzen noch einmal zu kontrollieren, schaut sie sich ihre Monatshistorie an und bekommt ihren Saldo angezeigt. Ihr fällt auf, dass sie alle Zutaten problemlos kaufen kann. Sie fährt in den Supermarkt und kauf alle Dinge ein.

3. Beschreibung des Fehlerfalls

Anja geht Einkaufen, sieht in der App, dass sie noch 30 € für den Monat übrig hat und beschließt am Monatsende etwas für die WG zu kochen. An der Kasse möchte sie zahlen aber ihr Konto sperrt die Transaktion. Geärgert schaut sie in die App, da sie dort angezeigt bekommt sie hätte noch genug Geld. Anja schaut verärgert alle ihre Ausgaben durch und ihr fällt auf, dass sie diesen Monat ein Möbelstück gekauft hat und statt den bezahlten 100 € nur 10 € in der App erfasst hat. Sie geht in ihre Historie, bearbeitet ihre Rechnung und setzt den Preis auf die bezahlten 100€. Die App aktualisiert sich automatisch und zeigt den neuen Saldo an.

4. Parallel ablaufende Aufgaben

Sobald ein Finanzbeitrag autorisiert wird, muss der Betrag in den Speicher geschrieben werden und den richtigen Kategorien zugeordnet werden. Parallel muss geprüft werden, ob überhaupt noch Geld für die entsprechende Kategorie zur Verfügung steht, sollte das nicht der Fall sein, wird Anja über eine Push-Benachrichtigung auf Ihrem Handy benachrichtigt.

5. Zustand der App, wenn das Szenario endet

Nach Beendigung der App muss diese weiterhin im Hintergrund weiterlaufen, d.h. es muss überprüft werden, ob für den Tag Erinnerungen anstehen oder Haushaltsaktivitäten eingetragen sind. Ebenso muss im Kalender überprüft werden, ob ein neuer Monat begonnen hat, sodass die App automatisch das monatliche Budget in der App ausweisen kann.

Szenario Persona 2: Jürgen

1. Ausgangszustand der Persona

Jürgen ist 68 Jahre alt und frischer Rentner. Er genießt seine neu gewonnene Freizeit sehr, fast schon zu sehr. Er lässt sich ziemlich gehen, schweift gerne beim Einkaufen ab und benötigt Stunden dafür. Dort vergisst er dann die Hälfte der Dinge, die seine Frau ihm aufträgt und widmet sich direkt wieder dem Sport, nachdem alles erledigt ist. Er blendet dabei völlig aus, dass seine Frau arbeitet und der ganze Haushalt nur an ihr hängen bleibt. Da Jürgen technisch nicht der Begabteste ist, hat seine Frau ihm vor längerer Zeit ein Smartphone gekauft, wobei er sich weigert es zu benutzen. Irgendwann reicht es seiner berufstätigen Frau und es endet in einem Streit. Jürgen entschuldigt sich, doch seine Frau ist nicht begeistert und legt ihm auf, sein Smartphone zu benutzen und sich eine App für Haushaltsaufgaben und Aktivitätsplanungen herunterzuladen.

Jürgen willigt ein, beide richten sein Smartphone ein und laden die App ActivFin herunter. Nachdem herunterladen, richteten beide Jürgens Account ein und Jürgen loggt sich ein. Direkt nach dem Login richten sie die Haushaltsaktivitäten ein.

2. Beschreibung des Normalfalls

Jürgen hat nun die App auf dem Handy. Er fällt dennoch wieder in alte Verhaltensmuster und möchte zum Sport fahren. Um schnell die Uhrzeit zu kontrollieren, schaut er auf sein Smartphone und sieht eine Benachrichtigung auf seinem Display. Die Benachrichtigung ist eine Erinnerung für den heutigen Tag, dass er noch Staubsaugen muss. Durch die Erinnerung ruft Jürgen wieder in sein Gedächtnis, er lässt seinen Sport ausfallen und staubsaugt das Haus. Nachdem die Aufgabe erledigt ist, markiert er direkt die Aufgabe als erledigt und überprüft direkt wann die nächste Aufgabe für ihn ansteht. Da er gesehen hat, dass keine anderen Aufgaben anstehen, geht er entspannt und beruhigt in den Sport und seine Frau ist auch noch glücklich.

3. Beschreibung des Fehlerfalls

Jürgen besitzt die App und hat gemeinsam mit seiner Frau eine Planungsliste angelegt. Jürgen schaut auf sein Smartphone und sieht keine Erinnerungen, wobei er heute dachte es würde eine Aufgabe für ihn anstehen. Es gab tatsächlich eine Erinnerung, jedoch hatte er sie unbeabsichtigt weggewischt.

4. Parallel ablaufende Aufgaben

Sobald eine Haushaltsaktivität abgehakt wird, muss analysiert werden, was für den Tag noch offen ist und wann Jürgen die nächste Mitteilung bekommt. Gleichzeitig muss die Erledigung der Aufgabe für diese Woche gespeichert werden und Jürgen bekommt eine Nachricht im UI angezeigt.

5. Zustand der App wenn das Szenario endet

Nach dem Schließen der App muss kontinuierlich eine Hintergrundaktualisierung stattfinden. Sollten neue Aufgaben oder Erinnerungen anstehen, so sollte eine entsprechende Push Benachrichtigung verschickt werden. Die App kann ansonsten einfach geschlossen werden und ohne weitere Probleme jederzeit wieder geöffnet werden.

Abbildung 3 - Szenarienbeschreibung der Personas 1 und 2

Im Kapitel 2.3 wird genauer auf die Ermittlung der Anforderungen eingegangen und anhand des praktischen Vorgehens der App ActivFin untermauert.

2.3 Ermittlung der Anforderungen

In diesem Kapitel geht es um die Ermittlung der Anforderungen, die an unsere App gestellt werden. Die Ermittlung dieser Anforderungen ist sehr vielschichtig, da es viele unterschiedliche Herangehensweisen für die konkrete Ermittlung gibt.

Im Fall unserer App sind die Anforderungen mithilfe von Kreativitätstechniken ermittelt worden. Diese ermittelten Anforderungen aus den Kreativitätstechniken wurden in der zweiten Instanz nochmals durchgesprochen und in das Use Case Diagramm eingezeichnet.

Unter Kreativitätstechniken werden Methoden zur Förderung neuer Ideen verstanden, im Fall unserer App lag der Fokus der angewendeten Methoden auf dem Brainstorming und dem Perspektivenwechsel.

Im Detail wurden im Brainstorming erstmals alle spontanen Einfälle verschriftlicht, die zur Kernfunktionalität und zur einfachen Befriedigung weiterer Bedürfnisse bei Nutzung einer Haushaltsbuch-, Planungs-, Organisations- Apps beitragen. Nach dem Brainstorming sind alle Gedanken noch mal aus Entwicklersicht betrachtet worden, um die Anforderungen auf Umsetzbarkeit zu prüfen [2] .Nach dieser Prüfung ist der Perspektivenwechsel als zweite Methodik als Kreativitätstechnik angewandt worden. Der Perspektivenwechsel betrachtet Funktionen und Bedürfnisse aus der Anwenderperspektive und gibt Aufschluss auf die wirklich relevanten Anforderungen an das Softwareprodukt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 - Darstellung der möglichen Anwendungsfälle in Diagrammform

Beide angewendeten Methodiken in Kombination miteinander, wirken als Filter für die tatsächlich umsetzbaren oder zukünftig umsetzbaren Anforderungen. Mithilfe dieser Erkenntnisse ist ein Use Case Diagramm, siehe Abbildung 4 , mit den jeweiligen Anwendungsfällen entwickelt worden, um eine Grundlage für eine spätere tiefgreifendere Spezifikation der wesentlichen Anforderungen zu ermöglichen.

Folgend wird in Kapitel 2.4 genauer auf die Spezifikation und die Einteilung der Anforderungen eingegangen.

2.4 Spezifikation der Anforderungen

Oftmals setzen sich die Anforderungen eines Softwaresystems aus funktionalen und nicht funktionalen Anforderungen zusammen, wie in Abbildung 5 ersichtlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 - Aufgliederung der Anforderungen in zwei Bereiche

Somit werden die bereits ermittelten Anforderungen in beiden Unterkapiteln in beide Anforderungstypen getrennt. Auf den Unterschied der beiden Einteilungen wird in der jeweiligen Untergliederung genauer eingegangen.

Ebenso werden einige ausgewählte Anforderungen unserer App tabellarisch dargestellt.

Im letzten Unterpunkt wird auf eine der möglichen Formen der konkreten Spezifikation von Anforderungen eingegangen, damit diese sowohl von Anwendern als auch Entwicklern gedeutet werden können und damit ein klarer Nutzen durch eine Funktionalität aufgezeigt werden kann.

2.4.1 Funktionale Anforderungen

Funktionale Anforderungen sind Anforderungen, die von einem Softwareprodukt erwartet werden, also die Leistung der Software. Des Weiteren beschreiben funktionale Anforderungen das Verhalten des Systems, die Verarbeitung der Daten und die Ausführung von Funktionen bei Interaktion durch den Benutzer [1, p. 85] .

Eine funktionale Anforderung kann ebenso eine ausdrückliche Beschreibung sein, was das System nicht tun soll.

Alle ausführbaren Aktionen müssen ausdrücklich festgelegt werden, sodass keine Missverständnisse bei der Entwicklung entstehen können. Meist werden die funktionalen Anforderungen noch mit einer User Story dargestellt, die dem Entwickler die genaue Funktion nahebringen soll.

In Abbildung 6 sind zehn ausgewählte funktionale Anforderungen der App ActivFin dargestellt, um einen detaillierteren Einblick in die Entwicklung und Planung der Software zu erhalten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 - Auflistung der funktionalen Anforderungen

2.4.2 Nicht funktionale Anforderungen

Eine nicht funktionale Anforderung ist keine speziell zu leistende Funktion der Anwendung, sondern betrifft die wichtigsten Softwareeigenschaften wie z. B. Zuverlässigkeit, Reaktionszeit, Sicherheit, Speicherbedarf und viele weitere [1, p. 86] .

Ebenso wie bei funktionalen Anforderungen können auch bei nicht funktionalen Anforderungen bestimmte Restriktionen beschrieben werden, also Beschränkungen des Systems.

Im Unterschied zu den funktionalen Anforderungen beziehen sich nicht funktionalen Anforderungen auf das gesamte System und nicht nur auf eine Systemfunktion. Somit hat auch das nicht beachten einer nicht funktionalen Anforderungen drastischere Folgen als bei funktionalen Anforderung.

Auch hier sind in Abbildung 7 zehn ausgewählte nicht funktionale Anforderungen dargestellt, um auch einen Unterschied der Anforderungskategorien im direkten Vergleich zu betrachten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 - Auflistung der nicht funktionalen Anforderungen

2.4.3 Entwicklung von User Storys

Um die Kommunikation zwischen Entwickler- und Anwenderperspektive zu vereinfachen, werden User Storys als Werkzeug zur Beschreibung der Funktionalität aus Anwenderperspektive geschrieben.

Der Hauptanwendungsgrund von User Storys ist, dass diese leicht zu verstehen sind und die direkten Wünsche der Anwender an die Mobile Applikation verdeutlicht werden. So kann das Fehlinterpretationspotenzial verringert werden und die gewünschte Funktionalität wird entsprechend überprüft.

Eine User Story ist meist wie folgt aufgebaut, zuerst wird beschrieben aus welcher Anwenderrolle (z. B. Admin, Nutzer, Gast) die Anforderung betrachtet wird, daraufhin wird auf die Funktionalität eingegangen, die einen klar definierten Nutzen erreichen soll. Meist wird dem Entwickler Spielraum gelassen, sprich man verwendet Akzeptanzkriterien, um den gewünschten Nutzen zu erreichen [1, pp. 82-84] .

Im Fall von ActivFin werden zwei User Storys exemplarisch in Abbildung 8 dargestellt, um die praktische Anwendung dieser Spezifikationsmethodik von Anforderungen aufzuzeigen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8 - User Storys zum Beschreiben der Anforderungen

3 Konzeption und Design

In diesem Abschnitt wird die Entwicklung des Konzepts genauestens beschrieben. Dafür werden sämtliche Ergebnisse aus der vorherigen Requirements Phase benötigt und genutzt. Ziel ist es, möglichst schnell erste Prototypen der grafischen Benutzeroberfläche zu entwickeln, testen, evaluieren und zu verbessern. Das zentrale Ergebnis der obigen Verbesserungen und Tests ist die sogenannte Seitenspezifikation und die UI-Design Definition.

Beispielhafte Eigenschaften für ActivFin

- Intuitiv zu bedienende Haushaltbuch App
- Finanzen, eintragen von Rechnungen, Haushaltsaktivitäten zu managen
- Einnahmen/Ausgaben zu tracken, speichern, kategorisieren
- Zahlungsaufforderungen an die Personen zu stellen
- Personen hinzuzufügen, dann Gruppen zuzuordnen, sodass innerhalb der App, Rechnungen/ Zahlungsaufforderungen geteilt werden können
- Pläne (Einkaufsliste, Haushaltplan) erstellen
- Haushaltaktivitäten zu verwalten

3.1 Interaktionsdesign

Das Interaktionsdesign einer mobilen App verfügt über mehrere Interaktionsmöglichkeiten. Ein Benutzer kann damit durch das Funktions- und Informationsangebot navigieren bzw. Interaktionen mit der mobilen App durchführen. Dabei veranlasst der Benutzer durch seine jeweiligen Interaktionen einen Übergang von einer Bildschirmseite (Screen oder View) zu einer anderen. Grundsätzlich sollte die Informationsarchitektur so flach wie möglich gehalten werden, d.h. jede Unterseite sollte mit so wenig Klicks wie möglich von der Startseite aus erreichbar sein. Eine tiefe Informationsstruktur ist hingegen sehr viel unübersichtlicher für User und birgt zudem die Gefahr, dass die tiefen liegenden Unterseiten nicht leicht erreichbar sind. [1, p. 109]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9 - Interaktionsdesign ActivFin

Das Interaktionsdesign unserer App verfügt über eine flache Architektur. Der Benutzer soll sich durch die Login Activity einloggen bzw. registrieren. Der Homescreen ist die Finanzübersicht. Der Benutzer kann durch die Finanzübersicht alle anderen Screens erreichen. (Abbildung 9 )

3.2 Arten des Prototypen

Beim Prototyping wird zwischen horizontalem und vertikalem Prototyping unterschieden:

- Beim horizontalen Prototyping wird nur eine Ebene bzw. Schicht des späteren IT- Systems möglichst vollständig entwickelt.
- Beim vertikalen Prototyping wird mit einem sogenannten Durchstich-Prototyp eine bestimmte Untermenge der Gesamtfunktionalität durch alle Ebenen hindurch realisiert.

Je nach Zielsetzung und Einsatzzweck werden drei verschiedene Arten des Prototyping eingesetzt

- Exploratives Prototyping dient als Kommunikationsgrundlage für die Softwareentwickler und späteren Benutzer.
- Experimentelles Prototyping wird während des Konzeptionsprozesses eingesetzt, um Lösungsalternativen zu diskutieren und zu evaluieren.

[...]

• Hochschule: Hochschule für Technik, Wirtschaft und Kultur Leipzig (Digitale Transformation)
• Veranstaltung: Mobile Computing
• Note: 1,3
• Autor: Dennis Kraus (Autor:in)
• Erscheinungsjahr: 2021
• Seiten: 69
• Katalognummer: V1314748
• ISBN (PDF): 9783346791702
• ISBN (Buch): 9783346791719
• Sprache: Deutsch
• Schlagworte: Android, App-Entwicklung, Apps, Programmierung, Mobile Applikation, Appentwicklung, Entwicklung