# PA teilweise Überarbeitet

# Projektbezeichnung und Entwicklerteam
Dieser Abschnitt beinhaltet den Projektvorschlag für unser Projekt **StreetArtists**.

| ID | Name | Rolle | Stellvertretend
|--- | --- | --- | --- |
| 01500768 | Martin Bär | Teamkoordinator | - |
| 11905159 | Luca Huber | Git/DevOps Manager | Dokumentationsbeauftragter|
| 11815744 | Simeon Materna | Testleiter | - |
| 11918513 | Marco Reiser | Technical Architect | - |
| 00809236 | Helene Wenigner | Dokumentationsbeauftragter | - |
| 11911133 | Johannes Zottele | Visual Architect | Technical Architect |

# Ausgangssituation
Im Zuge der fortschreitenden Digitalisierung verbreitet sich auch die bargeldlose Zahlung immer stärker. Viele Menschen, besonders der jüngere Teil der Bevölkerung, nutzen sie mittlerweile in allen Lebensbereichen, was unter Anderem dazu führt, dass sie immer seltener Wechselgeld bei sich tragen. Dies stellt ein Problem für Menschen dar, welche auf kleine Spenden angewiesen sind, wie beispielsweise Straßenkünstler\*Innen. Digitale Bezahlsysteme, mit denen sich auch Mikro-Transaktionen durchführen lassen, würden zwar bereits zur Verfügung stehen, allerdings sind die Transaktionskosten bei sehr kleinen Zahlungen hierbei verhältnismäßig groß, weshalb sich noch kein einheitliches System durchgesetzt hat. Durch die Abnahme von Barzahlungen und mangels einer zugänglichen bargeldlosen Lösung für Künstler\*Innen sehen sich diese mit einer stetigen Abnahme ihrer Einnahmen konfrontiert und können oft nicht mehr mit ihrer Kunst ihren Lebensunterhalt bestreiten. Da diese Entwicklung voraussichtlich weiter voranschreiten wird sehen wir eine Lösung als notwendig.

# Projektbeschreibung
Die bargeldlose Unterstützung heimischer Künstler\*Innen soll vereinfacht werden, indem eine simple und schnelle Methode angeboten wird, ihnen digital kleine Beträge zukommen zu lassen, bei der die Transaktionskosten gering gehalten werden, indem wir uns als Zwischenhändler einschalten. Um außerdem eine Werbeplattform für die Künstler\*Innen zu schaffen, können diese ihr Profil personalisieren und aktuelle Auftritte ankündigen.

Um das System zu nutzen, muss es für Unterstützer\*Innen zunächst einmal die Möglichkeit geben, einen Account anzulegen. Dabei können auch gleich Kreditkarteninformationen verknüpft werden. Nach erfolgreichem Login im System bekommen Unterstützer\*Innen die Möglichkeit ein Guthaben von der Kreditkarte abzubuchen, um anschließende schnelle Spenden zu ermöglichen, des Weiteren bekommen sie Zugriff auf Informationen zu bevorstehenden Events, einen QR-Code-Scanner und eine Suchfunktion. Die beiden letzteren ermöglichen es, Künstler\*Innen zu finden. Dabei erreicht man zunächst eine Seite, auf der man eine Vorschau des Profils des Künstlers sieht, und sofort mit einem Klick eine kleine Spende hinterlassen kann (per default anonym, falls gewünscht mit Namen). Von dieser Seite kann man auch zum Profil navigieren, nach einer Spende wird man automatisch dorthin weitergeleitet.

Das wichtigste Feature für Künstler\*Innen ist das Anlegen einer Bankverbindung im Zuge der Registrierung, um Spenden erhalten zu können. Diese können sie – sobald eine Mindestsumme von 5€ erreicht ist – auf ihre angegebene Bankverbindung überweisen lassen. Nach Anlegen eines neuen Accounts erhalten Künstler\*Innen einen persönlichen QR-Code, der auf ihre persönliche Spendenseite weist. Diesen können sie jederzeit als formatiertes PDF herunterladen und ggf. ausdrucken. Anschließend bekommen sie die Möglichkeit ihr Profil zu personalisieren, zukünftige Auftrittsorte zu posten, und Youtube-Videos einzubetten, welche sie bei Ausübung ihrer Kunst zeigen.

Die Spenden werden im System protokolliert. Unterstützer\*Innen können auf Informationen zu jenen Spenden zuzugreifen, die sie selbst getätigt haben, Künstler\*Innen haben Zugriff auf alle Spenden, die sie erhalten haben, allerdings ohne Information zum Spender, es sei denn, dieser hat explizit gewählt nicht anonym zu spenden.
Im Rahmen dieses Projekts werden die Zahlungsfunktionalitäten gemockt.

# Zielgruppen
Künstler\*Innen sollen von der Anwendung sehr stark profitieren. Sie erhalten eine Möglichkeit, auf bargeldlosem Weg Spenden zu erhalten, was derzeit kaum praktische Umsetzung findet. Außerdem sollen sie ihre Kunst anwerben können, indem sie YouTube-Videos in ihr Profil einbetten und Auftritte erstellen.

Unterstützer\*Innen sollen davon profitieren, eine erweiterte Auswahl an Optionen zu bekommen, Kunst die ihnen gefällt zu unterstützen, wenn sie dies wollen, ohne dafür großen Aufwand betreiben zu müssen. Außerdem bleiben sie so über Auftritte von Straßenkünstler\*Innen informiert.

Zusätzlich gib es eine UML Aktorenhierarchie, auf die sich die [Iceberglist](#Iceberglist) bezieht.

| Akteur | Rechte im System | Anmerkungen |
| -------- | -------- | -------- |
| Künstler | Künstler können die eigenen Events verwalten und ihr Guthaben abbuchen. | Zur Verwaltung der Events gehören das Erstellen, Bearbeiten und Löschen dieser. |
| Unterstützer | Unterstützer können ihr Guthaben verwalten. | Zur Verwaltung gehören das Einsehen und aufladen des Guthabens. |

# Funktionale Anforderungen, Anwendungsfälle

## Featurelist

| ID | Feature | Beschreibung | Priorität | Aufwand |
| ------ | ------ | ------ | ------ | ------ |
| 1 | Registrieren von Nutzer\*Innen | Auswahl zwischen Künstler\*In oder Unterstützer\*In. Bei Registrierung als Künstler\*In Angabe einer Bankverbindung (IBAN) verpflichtend. Unterstützer\*Innen können direkt bei der Anmeldung Kreditkarteninformationen hinterlegen, dies ist jedoch optional. Passwort wird als Hash gespeichert | H | 8 |
| 2.1 | Kreditkartendaten hinzufügen (Unterstützer\*Innen) | Angabe direkt bei Anmeldung möglich, aber optional. Zusätzliche Möglichkeit, diese nachträglich anzugeben (Umleitung von Guthaben Hochladen). | H | 6 |
| 2.2 | Guthaben hochladen | Selbst gewähltes Guthaben (mind. 5€) von Kreditkarte abbuchen. Ist noch keine Kreditkarte hinterlegt, wird man dazu aufgefordert Kreditkartendaten hinzuzufügen. (Diese Funktion wird gemockt) | H | 5 |
| 2.3 | Spende hinterlassen | Auswahl zwischen 3 Beträgen (50 cent, 1€, 2€), oder selbst gewählter Betrag. Eine Checkbox kann ausgewählt werden, wenn man seine Spende mit Namen hinterlassen will (per default ist sie anonym). Versucht man eine Spende zu hinterlassen, die das eigene Guthaben übersteigt, wird man dazu aufgefordert, neues Guthaben aufzuladen. | H | 4 |
| 2.4 | Künstler\*In: Spenden “abheben” | Künstler\*Innen haben Zugriff auf die aktuell angesammelte Summe, die diese über Spenden erhalten haben und können sie nach Wunsch auf ihre angegebene Bankverbindung (IBAN) überweisen lassen. Aufgrund von Transaktionskosten ist dies erst ab einem Betrag von 5€ möglich. (Diese Funktion wird gemockt) | H | 5 |
| 3.1 | Künstler\*In: QR-Code und Artist-Code Generieren | Diese werden automatisch bei Registrierung generiert und können nicht geändert werden. Sie verweisen auf die Spendenseite des\*der Künstler\*In | H | 1 |
| 3.2 | Künstler\*In: QR-Code herunterladen | Ein Künstler\*In kann den generierten QR-Code als formatiertes PDF herunterladen. | H | 6 |
| 3.4 | QR-Code Scanner | Von der Startseite der Unterstützer\*Innen Zugriff auf einen eingebetteten QR-Code-Scanner. | M | 9 |
| 3.5 | QR-Code Scanner | Alternativ zum QR-Code-Scan kann der 4-stellige Artist-Code eingegeben werden, um ebenfalls zur Spendenseite zu kommen. | M | 3 |
| 4.1 | Künstler\*In: Profil personalisieren | Künstler\*Innen können eine Biographie schreiben, URLs zu Social Media Links hinzufügen (Instagram, Facebook, YouTube). | N | 5 |
| 4.2 | Medien einbetten | Künstler\*Innen können auf ihrem Profil Youtube-Videos einbetten. Dabei ersetzen neue Videos alte. Die 10 neuesten Videos werden in der Datenbank gespeichert und im Profil angezeigt. | N | 1 |
| 5.1 | Künstler\*In: Event erstellen | Ein\*e Künstler\*In kann ein Event erstellen (Datum (in der Zukunft), Uhrzeit, Adresse, kurze Beschreibung), diese sieht man dann auf dem Profil der Künstler\*Innen und in den “Upcoming Events”. Events können bis zu 14 Tage im Vorhinein angekündigt werden. | M | 6 |
| 5.2 | Homepage “Upcoming Events” | Auf der Startseite der Unterstützer\*Innen wird eine Liste mit den 20 relevantesten Events angezeigt (relevant wird definiert durch zeitliche und örtliche Nähe) | M | 4 |
| 6.1 | Spendenliste Künstler\*Innen | Künstler\*Innen können eine Liste von Spenden einsehen, die darstellt, zu welchem Zeitpunkt sie wie viel Geld erhalten haben. Sind Spenden nicht anonym, sehen sie auch den Namen des\*der Spender\*in zur Spende zugeordnet. | H | 3 |
| 6.2 | Spendenliste Unterstützer\*Innen | Unterstützer\*Innen sehen eine Liste aller Spenden, sie sie getätigt haben mit folgenden Informationen: Datum, Betrag, Künstler\*In. Von einem Eintrag der Spendenliste kann direkt zum\*zur Künstler\*In navigiert werden. | H | 2 |
| 6.3 | Spendenliste Künstler\*Innen und Unterstützer\*Innen als Grafiken | Künstler\*Innen und Unterstützer\*Innen können Statistiken und Grafiken zu den erhaltenen Spenden einsehen | M | 8 |
| 7.1 | Suche nach Künstler\*In, Genre, Events | Zeigt eine Liste aller Künstler\*Innen oder Events, auf die alle Parameter zutreffen. | N | 5 |
| 7.2 | Eventlisten - Filter | Die Eventlisten können gefiltert werden, je nachdem welche Sortierung Unterstützer\*innen und Künstler\*innen bevorzugen | M | 2 |
| 8.1 | Überblick als Kartenansicht der Events für Unterstützer\*Innen | Es werden die relevantesten Events (siehe 7.2) angezeigt, damit Unterstützer\*Innen einen besseren Überblick haben. | M | 8 |
| 8.2 | Kartenansicht für einzelne Events | In der Event-Detailansicht wird die Location des jeweiligen Events auf einer Karte angezeigt | N | 2 |
| 9.1 | E-Mail-Bestätigung bei Registrierung | User\*Innen bekommen bei Registrierung eine E-Mail und müssen diese für eine erfolgreiche Registrierung bestätigen | N | 8 |
| 9.2 | Passwort vergessen | User\*Innen können das Passwort zurücksetzten (bekommen dazu eine E-Mail) | N | 6 |
| 9.3 | Newsletter per Mail | Wenn Unterstützer*\Innen dies wollen, bekommen sie News über Künstler\*Innen oder besondere Events per E-Mail | N | 5 |
| 10.1 | Admin-Funktion | Administrator\*In kann User\*Innen und Events löschen oder sperren | M | 8 |
| 10.2 | Melden von unangemessenen Inhalten | User\*Innen können unangemessene Profile oder Events melden. Admin hat eine Übersicht über diese Meldungen und kann dann entscheiden, was er\*sie damit | M | 5 |
| 11 | Review-System | User\*Innen können Bewertungen für Künstler\*Innen schreiben | N | 8 |
| 12.1 | Künstler\*In Profilbild | Künstler\*Innen können ein Profilbild hochladen | N | 6 |
| 12.2| Künstler\*In Bildergalerie | Künstler\*Innen können bis zu 9 weitere Bilder hochladen. Diese werden in einer Galerie angezeigt | N | 8 |

## Anwendungsfall Übersicht

Obrige Features wurden zu folgende Anwendungsfall-Paketen zusammengefasst, wobei diese Priorisiert wurden (**H**och, **M**ittel, **N**iedrig).

1. Registrierung (**H**): Unbedingt erforderlich, kritisch
2. Geldspende (spenden, Guthaben aufladen, abheben) (**H**): Unbedingt erforderlich, kritisch
3. QR-Code (**H**): Unbedingt erforderlich, kritisch
4. Profilpersonalisierung (**N**): Erweiternde Features, können auch nach dem Projekt implementiert werden
5. Events (**M**): nur Grundfunktionalität notwendig (erstellen/bearbeiten/löschen)
6. Spendenübersicht (**N**): Erweiternde Features, können auch nach Projekt implementiert werden
7. Suche (**N**): Erweiternde Features, können auch nach dem Projekt implementiert werden
8. Kartenansicht (**M**): Übersichtskarte bietet eine beeindruckende und benutzerfreundliche Funktion, ist allerdings für die Funktionsweise der App nicht notwendig.
9. E-Mail-System (**M**): Passwort-vergessen-Funktion und E-Mail-Bestätigung bieten praktische Funktionen, die Sicherheit und Benutzerfreundlichkeit der App erhöhen. Newsletter ist nicht zwingend notwendig.
10. Admin-Funktion (**M**): Fügt eine zusätzliche Kontrollschicht ein und macht die App sicherer. Allerdings funktioniert die App auch ohne dieses Feature.
11. Reviewsystem (**N**): Erweiterndes Feature, kann auch nach Projekt implementiert werden.
12. Bildfunktion (**N**): Erweiterned Feature, kann auch nach Projekt implementiert werden.

## Iceberglist

Verfeinerung der [Featurelist](#Featurelist).

| Id | Feature, Aktor | Anwendungsfälle | Kunden-Priorität | Aufwand | Version | Zuständige\*r |
| -------- | -------- | -------- | -------- | -------- | -------- | -------- |
| 1.1.1 | Registrierung, Künstler\*in | Künstleraccount anlegen | H | 4 | 1 | Helene |
| 1.1.2 | Registrierung, Unterstützer\*in | Unterstützeraccount anlegen | H | 3 | 1 | Helene |
| 1.1.3 | Registrierung, Künstler\*in | Bankverbindung angeben | H | 1 | 1 | Helene |
| 1.2.1 | Registrierung, Unterstützer\*in | Künstleraccount Login | H | 3 | 1 | Helene |
| 1.2.2 | Registrierung, Unterstützer\*in | Unterstützeraccount Login | H | 3 | 1 | Helene |
| 1.2.3 | Registrierung, Unterstützer\*in | Künstleraccount Logout | H | 3 | 1 | Helene |
| 1.2.4 | Registrierung, Unterstützer\*in | Unterstützeraccount Logout | H | 3 | 1 | Helene |
| 1.3.1 | Registrierung, Künstler\*in | Künstleraccount löschen | H | 4 | 1 | Helene |
| 1.3.2 | Registrierung, Unterstützer\*in | Unterstützeraccount löschen | H | 3 | 1 | Helene |
| 2.1 | Geldspende, Unterstützer\*in | Kreditkarteninfo. angeben | H | 6 | 1 | Johannes |
| 2.2 | Geldspende, Unterstützer\*in | Guthaben aufladen | H | 5 | 1 | Johannes |
| 2.3.1 | Geldspende, Unterstützer\*in | Spende hinterlassen | H | 4 | 1 | Johannes |
| 2.3.2 | Geldspende, Unterstützer\*in | Spende anonym hinterlassen | H | 4 | 1 | Johannes |
| 2.3.3 | Spendenverw., Künstler\*in | Spende abheben | H | 4 | 1 | Johannes |
| 2.3.4 | Spendenverw., Künstler\*in | Abhebung auf 5 Euro beschränken| H | 1 | 1 | Johannes |
| 3.1 | QR-Code, Künstler\*in | QR-Code generieren | H | 1 | 1 | Marco |
| 3.2 | QR-Code, Künstler\*in | Artist-Code generieren | H | 1 | 1 | Marco |
| 3.3 | QR-Code, Künstler\*in | QR/Artist-Code-Pdf herunterladen | H | 6 | 1 | Marco |
| 3.4 | QR-Code, Unterstützer\*in| QR-Code scannen auf Startseite | M | 9 | 1 | Marco |
| 3.5 | QR-Code, Unterstützer\*in| Artist-Code eingeben | M | 1 | 3 | Marco |
| 4.1.1 | Profilpers., Künstler\*in | Biographie hinzufügen | N | 1 | 3 | Simeon |
| 4.1.2 | Profilpers., Künstler\*in | Biographie bearbeiten | N | 1 | 3 | Simeon |
| 4.1.3 | Profilpers., Künstler\*in | Biographie löschen | N | 1 | 3 | Simeon |
| 4.2.1 | Profilpers., Künstler\*in | Socialmedia links hinzufügen | N | 1 | 3 | Simeon |
| 4.2.2 | Profilpers., Künstler\*in | Socialmedia links löschen | N | 1 | 3 | Simeon |
| 4.2.3 | Profilpers., Künstler\*in | Socialmedia links bearbeiten | N | 1 | 3 | Simeon |
| 4.3.1 |Profilpers., Künstler\*in | Youtube-Video einbetten | N | 1 | 4 | Simeon |
| 4.4.2 |Profilpers., Künstler\*in | Youtube-Video löschen | N | 1 | 4 | Simeon |
| 5.1 | Events, Künstler\*in | Event erstellen | M | 4 | 3 | Martin |
| 5.2 | Events, Künstler\*in | Event bearbeiten | M | 2 | 3 | Martin |
| 5.3 | Events, Künstler\*in | Event löschen. | M | 1 | 3 | Martin |
| 5.4 | Events, Künstler\*in | Eventauflistung. | M | 3 | 3 | Martin |
| 5.5 | Events, Unterstüzer\*in | Eventauflistung. | M | 1 | 3 | Martin |
| 5.6 | Events, Künstler\*in | Andere Künstler\*innen einladen | N | 5 | 3 | Martin |
| 5.7 | Events, Künstler\*in | Kollaboration anfragen. | N | 3 | 3 | Martin |
| 6.2.1 | Spendenverw., Künstler\*in | Spendenliste abrufen | H | 3 | 2 | Luca |
| 6.2.2 | Spendenverw., Künstler\*in | Spenden Grafiken einsehen | N | 5 | 2 | Luca |
| 6.3.1 |Spendenverw., Unterstützer\*in|Spendenliste: Künstler anzeigen | M | 1 | 2 | Luca |
| 6.3.2 | Spendenverw., Unterstützer\*in|Spendenliste: Betrag anzeigen | M | 1 | 2 | Luca |
| 6.3.3 | Spendenverw., Unterstützer\*in|Spendenliste: Datum anzeigen | M | 1 | 2 | Luca |
| 6.3.4 | Spendenverw., Unterstützer\*in|Spende zu Künstler Navigation | M | 1 | 2 | Luca |
| 6.3.5 | Spendenverw., Unterstützer\*in|Grafiken einsehen. | N | 3 | 2 | Luca |
| 7.1 | Suche, Unterstützer\*in| Suche nach Künstlername | N | 2 | 4 | Luca |
| 7.2 | Suche, Unterstützer\*in| Suche nach Genre | N | 2 | 4 | Luca |
| 7.2 | Suche, Unterstützer\*in| Suche nach Events | N | 2 | 4 | Luca |
| 7.2 | Suche, Unterstützer\*in| Filtern der Suchergebnisse | N | 2 | 4 | Luca |

# Domänenmodell


# Arbeitsstruktur & Grober Projektplan
Das Projektteam besteht aus 6 Entwickler\*Innen, die die weiter oben definierten Expert\*Innenrollen übernehmen. Für das Projektmanagement wurde eine Kombination aus dem Ticketsystem in GitLab und Scrum gewählt. Anfangs (Ausarbeitung des Projekts, Anwendungsfälle, Expertenwissen) war der Einfluss von Scrum noch sehr gering. Allerdings soll in der weiteren Phase des Entwicklungsprozesses eine stärkere Orientierung an Scrum erfolgen.

## Rollenverteilung
Siehe Abschnitt [Projektbezeichnung und Entwicklerteam](#Projektbezeichnung-und-Entwicklerteam) weiter oben.

Spezielle Aufgaben wie das UI-Design, das Build- und Releasemanagement oder das Verfassen von Dokumentation sind den dafür vorgesehenen Expert\*Innen zugeteilt. Code beitragen und reviewen wird jedoch jedes Teammitglied.

## Horizontale Verantwortlichkeiten

### Technischer Architekt: Marco Reiser (Zweitbesetzung: Johannes Zottele)
Der technische Architekt sorgt für eine strukturierte Architektur und kümmert sich um die Aspekte, welche die Applikation spannen.

- Auswahl und Testen zu verwendender Technologien
- Bewertung welche Libraries, plugins, etc. am besten für den jeweiligen Use-Case geeignet sind
- Verwendungszwecke aufzeigen und abgrenzen
- Definition der generellen Architektur
- Informationsfluss inklusive Authorization festlegen
- Trennung der Schichten, einzelnen Services etc. garantieren
- Integration verschiedener Bereiche überwachen (bspw. mit Testleiter koordinieren)
- Definition von projektspezifischen Konventionen
- bspw. Exceptionhandling
- Einhaltung der technischen Anforderungen
- Schichtentrennung sicherstellen
- Reibungslose Kommunikation zwischen Backend und Frontend sicherstellen
- Einhaltung für Projektspezifische Konventionen
- Einhaltung von Best Practices für lesbaren sowie maintainable Code
- Klärung bei Unsicherheiten der Implementation

### Team Koordinator: Martin Bär
Der Team Koordinator ist zuständig für die Projektplanung bzw. -organisation und sollte immer einen Überblick über den Fortschritt des Projekts haben.

- Organisation und Planung
- laufende Aktualisierung und Weiterentwicklung des Projektplans
- Aktualisierung der (von Johannes erstellten) Iceberglist
- Controlling & Tracking
- Issue-Erstellung zu Sprints auf GitLab
- Statuserhebung für Review-Meetings
- Kontrolle der Aufgabeverteilung
- Kommunikation mit Tutor
- Organisation von Meetings
- intern: Gruppentreffen
- extern: Tutortreffen, IRs, MRs
- siehe [Informationswesen](#Informationswesen)

### Dokumentationsbeauftragte: Helene Weninger (Zweitbesetzung: Luca Huber)

- Verfügbarkeit der Dokumentation
- Vollständigkeit der Java API Dokumentation
- Jede Java-Package muss dokumentiert werden. Eine package-info.java Datei muss für jedes Java-Package erstellt werden.
- Sicherstellen, dass alle Klassen, Variablen und Methoden in English dokumentiert werden
- Erstellung von Dokumentationsrichtlinien (Format- und Formatierungsrichtlinien, Spezifikation der Code Conventions)
- Überprüfung der Einhaltung von Dokumentationsrichtlinien
- Überprüfung der Vollständigkeit von Dokumenten
- Dokumentation in GitLab
- Protokollierung aller Meetings
- Organisation der Dokumente im Wiki

### Testleiter: Simeon Materna
Der Testleiter ist für eine stets gut durchtestete und (möglichst) fehlerfrei Laufende Applikation verantwortlich.
- Testinfrastruktur
- Testbibliotheken und tools
- Testdaten
- Erstellung von Testrichtlinien
- Für sowohl manuelle als auch automatisierte Tests
- Testvorgehensweise
- Regelmäßige verifizierung der Testqualität und Abdeckung
- Überprüfung der Testrichtlinieneinhaltung

### Git/DevOps Manager: Luca Huber
Der Git- bzw. DevOps Manager ist für einen sauberen Git-Workflow verantwortlich. Außerdem hat er die Verantwortung, die reibungslose *Continous Integration* (CI) mittels Gitlab sicherzustellen.

- Git
- Festlegung einheitlicher Commit-Messages
- Dokumentation für Branch Strategy bzw. Workflow erstellen
- Teammitglieder für sauberen Workflow sensibilisieren (DO's and DONT's)
- Sicherstellung, dass für Reviews die notwendigen Files im richtigen Branch sind
- Unterstützung und Support für Teammitglieder bei Fragen
- Gitlab CI
- Gitlab Continous Integration aufsetzen
- Runner konfigurieren
- Mit Testleiter die Testkonfiguration für CI festlegen

### Visual Architect: Johannes Zottele
Der Visual-Architect ist verantwortlich für ein ansehnliches und nutzerfreundliches Design und Layout, das sowohl auf den gängisten Desktop- als auch Mobile-Browser läuft.

- Ausarbeitung der Design Richtlinien
- Aufbereitet für alle Entwickler\*innen (PDF)
- Überprüfung ob die Richtlinien von den Entwickler\*innen eingehalten werden
- Gestaltung der Wireframes (Figma)
- Überprüfung der Einhaltung der Responsiveness (Mobile/Desktop)
- Planung der Frontend-Komponenten (Angular-Components)

## Grober Projektplan
Der Projektplan enthält neben die in die Work Breakdown Structure eingearbeitete Erstellung der eigenstädnigen Artefakte auch die zeitliche Verortung der Meilensteine. Die Verteilung der Zuständigkeiten basiert auf den Horizontalen Verantwortlichkeiten. Dort, wo noch keine zuständige Person angeführt ist, wird diese während des Arbeitsprozesses noch zugewiesen.

### Work Breakdown Structure (WBS)
Bei der Erstellung der WBS wurde die Meilensteinbeschreibung als Grundlage genommen und die ersten Arbeitspakete (hauptsächlich Erstellung der Artefakte und der App-Grundstruktur) aufgrund der Horizontalen Verantwortlichkeiten herausgearbeitet. Die technischen Arbeitspakete basieren jeweils auf den in der [Iceberglist](#Iceberglist) festgelegten Anwendungsfällen und sind dort genauer beschrieben. Die WBS dient hauptsächlich zur Eintragung von Arbeitspaketen zur Dokumentation, Konfiguration, Anforderungsanalyse etc.

| Nr. | Arbeitspakete | Anfang | Ende | Stunden | Verantwortlich |
| -------- | -------- | -------- | -------- | -------- | -------- |
| *MS.0* | *Kick-Off* | 14.04.2021 | 14.04.2021 | 1 | |
| 0.1 | PV erstellen | 14.04.2021 | 21.04.2021 | 17 | |
| *MS.0.1* | *PV vorstellen* | 21.04.2021 | 21.04.2021 | 1 | Helene, Johannes |
| 1.1 | Anforderungsanalyse | 22.04.2021 | 29.04.2021 | 46,5 | |
| 1.1.1 | Feature-Liste verfeinern: Iceberglist | 23.04.2021 | 29.04.2021 |2,5 | Johannes |
| 1.1.2 | Restliche, im PV bereits vorhandene Teile verfeinern (inkl. Domänenmodell) | 23.04.2021 | 29.04.2021 | 1 | Helene |
| 1.1.3 | Projektplan erstellen | 23.04.2021 | 29.04.2021 | 6,5 | Martin |
| 1.1.4 | Schichtendiagramm und Nichtfunktionale Anforderungen beschreiben | 23.04.2021 | 29.04.2021 | 6,5 | |
| 1.1.5 | Benutzerbefragung | 23.04.2021 | 29.04.2021 | 13,5 | Simeon |
| 1.1.6 | Restliche Teile des PA schreiben | 23.04.2021 | 29.04.2021 | 2,5 | Johannes, Martin |
| 1.1.7 | GUI: Design Guidelines erstellen | 16.04.2021 | 29.04.2021 | 4 | Johannes |
| 1.1.8 | GUI: Wireframe erstellen | 19.04.2021 | 29.04.2021 | 9,5 | Johannes, Simeon |
| *MS.1* | *Projektdefinition, Projektauftrag* | 29.04.2021 | 29.04.2021 | | |
| *MR-1* | *Management Review 1* | 29.04.2021 | 29.04.2021 | | |
| 1.2 | Anfoderungsanalyse überarbeiten | 29.04.2021 | 02.05.2021 | | |
| 1.2.2 | Use-cases überarbeiten | 29.04.2021 | 02.05.2021 | | |
| 1.3 | Projektplan laufend überarbeiten, dazu Issues in GitLab erstellen | 29.04.2021 | | | Martin |
| 2.1 | Entwurf und Design | 29.04.2021 | 02.05.2021 | | |
| 2.1.1 | Schichtendiagramm verfeinern | 29.04.2021 | 07.05.2021 | | |
| 2.1.2 | Leitfaden zum Git-Workflow | 30.04.2021 | 05.05.2021 | | Luca |
| 2.1.3 | Leitfaden zur technischen Architektur | 30.04.2021 | 07.05.2021 | | Marco |
| 2.1.4 | Testleitfaden | 30.04.2021 | 07.05.2021 | | Simeon |
| 2.1.5 | Gitlab CI konfigurieren | 01.05.2021 | 07.05.2021 | | Luca |
| 3.0 | Implementierung Sprint 1 | 01.05.2021 | 10.05.2021 | | |
| 3.0.1 | DB Schema & Testdaten | 01.05.2021 | 10.05.2021 | | |
| 3.0.2 | Persistenz-Schicht, DAOs | 01.05.2021 | 10.05.2021 | | |
| 3.0.3 | Service Schicht, erste Entities | 01.05.2021 | 10.05.2021 | | |
| 3.0.4 | Frontend: erstes GUI-Panel und UML Diagramm der Angular-Components | 01.05.2021 | 10.05.2021 | | Johannes |
| 3.0.5 | Produkt Dokumentation | 01.05.2021 | 10.05.2021 | | Helene |
| 3.0.6 | Maven Konfiguration (pom.xml) | 01.05.2021 | 10.05.2021 | | |
| 3.0.7 | Tests der CRUD-Methoden und der ersten GUI-Version | 01.05.2021 | 10.05.2021 | | Simeon |
| *MS.2* | *Erster Systemtest* | 10.05.2021 | 10.05.2021 | | |
| *IR-1* | *Internes Review 1 inkl. Pre-Release Demo* | 10.05.2021 | 13.05.2021 | | |
| 2.2 | Entwurf und Design überarbeiten | 11.05.2021 | 18.05.2021 | | |
| 3.1 | Implementierung Sprint 2 bis Version 1 (siehe [Iceberglist](#Iceberglist)) | 11.05.2021 | 26.05.2021 | | |
| *MS.3* | *Alphaversion der Software, grundlegende Funktionalitäten bereits vorhanden, DAO-Tests vorhanden* | 26.05.2021 | 27.05.2021 | | |
| *MR2* | *Management Review 2, Alpha Release Demo* | 27.05.2021 | | | |
| 3.2 | Implementierung Sprint 3 bis Version 3 (siehe [Iceberglist](#Iceberglist)) | 28.05.2021 | 09.06.2021 | | |
| *MS.4* | *80% der US implementiert, Service-Schicht-Tests vorhanden* | 09.06.2021 | 10.06.2021 | | |
| *IR-2* | *Internes Review 2, Beta Version Demo* | 10.06.2021 | 10.06.2021 | | |
| 3.3 | Implementierung Sprint 4 bis Version 4 (siehe [Iceberglist](#Iceberglist)) | 11.06.2021 | 23.06.2021 | | |
| *MS.5* | *100% der US implementiert, fertiges Produkt* | 23.06.2021 | 24.06.2021 | | |
| *MR-3* | *Management Review 3, Projektabnahme, Version Demo* | 24.06.2021 | 24.06.2021 | | |

### Meilensteinbeschreibung
1. Projektauftrag (MR1) 29.04.2021
2. Erster Systemtest (IR1) 10.05.2021
Die allererste Version der Software (pre-release). Die Schichten sind bereits verknüpft und können mit den benachbarten Schichten (beschränkt) kommunizieren. Es sind noch keine bis sehr wenige Features implementiert und hauptsächlich CRUD Methoden vorhanden. Außerdem wurde die Software bereits mit der GUI und einer Datenbankverbindung getestet.

3. 50% der US implementiert (MR2) 24.05.2021
Alpha-Version der Software: Software ist bereits benutzbar und enthält bereits erste Features, wie z. B. die Anlegung eines Accounts (Use Cases in der [Iceberglist](#Iceberglist), die der Version 1 zugeordnet ist). Außerdem sind bereits Tests für die DAOs implementiert und die Persistenz-Schicht ist bereits zu 60%-70% implementiert.

4. 80% der US implementiert, Service-Schicht Tests (IR2) 07.06.2021
Beta-Version der Software: die Software ist benutzbar und enthält bereits die allerwichtigsten Features, jedoch sind noch nicht alle Features implementiert (Use Cases in der [Iceberglist](#Iceberglist), die der Version 3 Zugeordnet sind). Außerdem ist die Service-Schicht bereits getestet.

5. 100% der US implementiert (MR3) 21.06.2021
Es sollen alle Use Cases, die in der Iceberglist zu finden sind, abgearbeitet sein. Das Produkt ist lauffähig und die Tests funktionieren. Das Produkt wird der Kundschaft gezeigt und vorgeführt.

# Projektabgrenzung
Generell sollen alle Features des Projektvorschlags bzw der [Iceberglist](#Iceberglist) umgesetzt werden. Dennoch sind manche Punkte genauer zu begrenzen um möglichen Missverständnissen vorzubeugen.

- **QR-Code Funktionalität:** Der QR-Code-Scan soll nicht auf allen Browser auf jedem Smartphone verfügbar sein. Diese Funktionalität ist auf folgende OS (Browser) beschränkt: Android (Chrome, Firefox), iOS (Safari). Insbesondere auf der Desktopversion werden QR-Code-Scan Features nicht verfügbar sein.
- **Profilvideos:** Es sollen keine Videos hochgeladen werden können sondern jediglich die Möglichkeit geben, bestehende Youtube-Videos als solche einzubetten.
- **Künstler als Unterstützer:** Nutzer die als Künstler registriert sind, werden nicht die Möglichkeit haben die Funktionen für Unterstützer zu verwenden.
- **QR-Scanner:** Für die Implementierung des QR-Code-Scanners verwenden wir einen bestehenden QR-Scanner und binden diese in unsere Applikation ein. Das heißt der QR-Code-Scanner wird nicht von uns selbst entwickelt.
- **Transaktionen:** Es werden Transaktionen über eine Payment Service API (z.B. Stripe) gemockt, jedoch nicht real verwendbar sein.
- **Events** Die Standorte der Events werden nicht über externe Dienste(Google Maps, OSM) gemanaged und auch nicht auf einer Karte angezeigt. Die Eventstandorte werden lediglich als Addressen im System vorhanden sein. Es wird also auch keine überprüfung auf echtheit von Addressen stattfinden.
- **Admin Funktionen:** Es wird keinen eigenen Admin bzw. Moderator Account geben der Zugriffe auf alle Funktionen mittels GUI bekommt. Daher umfasst dieses Projekt auch keine Moderation/Support-Tools für das Management der Applikation.

# Schichtendiagramm


## Used technology

The architecture is based on the Java Spring Framework. For persistence, JPA is used in conjunction with hibernate. Spring Security with JWT is used for authentication and authorization. Backend and Frontend are separated and communicate via HTTP. The backend exposes REST API endpoints for this purpose. The frontend application will be made with Angular. For payments, Stripe will be used for both sending and receiving payments. Transactions between users will be implemented without third-party services. PDF generation will be done using iText in the backend. The frontend will include a QR-Scanner based on the html5-qrcode library.

# Lieferkomponenten
Dieser Abschnitt beschreibt die während der Projektlaufzeit entstehende Software, inklusive der dazugehörigen Dokumentation und wichtiger Artefakte. Die Übergabe aller Artefakte und der Software erfolgt ausschließlich über GitLab.

## Software

Nach Projektabschluss werden dem Kunden folgende Kernkomponenten der Software in Produktionsfähigen Zustand übergeben:

- Angular Application für Benutzung durch Nutzer
- H2 SQL Datenbank mit Datenbankskripts zur Inbetriebnahme der Applikation (Initialisierung)
- Konfigurationsdaten für Datenbanken und Server, soweit für Wartung und Weiterentwicklung notwendig
- Anlegen und Verwalten von 2 Arten von Nutzenprofilen (Unterstützer, Künstler)
- Aufladen des Guthaben durch Unterstützer, Transaktionen zwischen Nutzern und Abheben durch Künstler, unterstützt durch Stripe
- Erstellen und Verwalten von Events durch Künstler
- Erstellen und scannen von QR-Codes zur schnellen Navigation

## Artefakte & Projektdokumentation
- Domänenmodell
- Schichtendiagramm
- Funktionale Anforderungen:
- Iceberglist
- Aktorenhierarchie
- Funktionierende Testfälle
- Präsentationen zu den MRs

## Meilensteine
### Meilenstein 2: Erster Systemtest
- Artefakte des laufenden Projektmanagements (Besprechungsprotokolle)
- IR1 Statusbericht
- Pre-Release-Version mit GUI Prototyp: erster Systemtest ist möglich
- Schichtendiagramm abgeschlossen
- erste Persistenz-Tests
- Datenbankschema

### Meilenstein 3: 50% der US implementiert
- Artefakte des laufenden Projektmanagements
- MR2 Statusbericht inkl. Präsentation
- Datenbankbeschreibung
- Alpha-Version: Prototyp mit einigen ersten Features 50% der US sind implementiert
- UI Design abgeschlossen
- Persistenz-Tests

### Meilenstein 4: 80% der US implementiert, Service-Schicht Tests
- Artefakte des laufenden Projektmanagements
- IR2 Statusbericht
- Beta-Version der Software inkl. den allerwichtigsten Features (ca. 80% der US)
- Tests auf Service-Schicht erweitert

### Meilenstein 5: 100% der US implementiert
- Artefakte des laufenden Projektmanagements
- MR3 Statusbericht inkl. Präsentation
- funktionierendes Produkt
- Tests abgeschlossen

## Abgrenzung des Lieferumfangs
Nicht im Lieferumfang des End-Produkts enthalten sind:
- Testleitfaden
- Git-Leitfaden
- Leitfaden zur technischen Architektur
- Burn-Down-Charts, Projektstrukturplan

# Nichtfunktionale Anforderungen

- **Browser-Konformität:** Bis auf den QR-Code-Scanner sollen alle Features auf den neuesten Versionen der gängisten Browser (Google Chrome ab 88.0, Microsoft Edge ab 88.0, Mozilla Firefox ab 85.0, Apple Safari for IOS ab 14.1, Chrome for Android ab 90.0, Firefox for Android ab 87.0) fehlerfrei funktionieren und getested sein. Es gibt für QR-Code-Scanner einige Einschrängungen siehe [Projektabgrenzung](#Projektabgrenzung)
- **Wiederherstellung:** Alle Daten (insbesondere Transaktionsdaten) müssen auch nach dem Ausfall des Systems konsistent wiederhergestellt werden können.
- **Benutzerfreundlichkeit:** Die Benutzeroberfläche soll für Smartphones optimiert sein. Alle Features müssen bis zu einer Bildschirmbreite von 375 pt korrekt dargestellt werden und verwendbar sein. Wir planen eine Umsetzung mit nur einer Hauptseite am Smartphone.
- **Serviceworker:** Nutzer sollen die Applikation auch ohne Internetverbindung starten können, um eine bessere Nutzbarkeit vor allem am Smartphone zu gewährleisten. Hierzu sollen Serviceworker verwendet werden, um Teile des Frontends im Cache zu speichern.
- **Add To Homscreen:** Wenn die Website im Standard-Mobilebrowser geöffnet wird, soll es die Möglichkeit geben, diese zum Homescreen hinzuzufügen und dabei ein Icon angezeigt zu bekommen.
- **Skalierbarkeit:** Grundsätzlich sollen bei der Implementierung mögliche Erweiterungen berücksichtigt werden. Es wird aber nicht davon ausgegangen die Applikation extrem zu skalieren, daher findet diese Berücksichtigung nur in einem beschränkten Ausmaß statt.
- **Feedback:** Es ist darauf zu achten, dass sowohl Endnutzer als auch Entwickler immer eine sinnvolle Fehler- bzw. Erfolgsmessage erhalten.
- **Wartbarkeit:** Um eine spätere Wartbarkeit der Applikation so gut wie möglich zu gewährleisten, müssen alle Coding- und Dokumentationsguidelines eingehalten werden.
- **Datensicherheit:** Nutzer dürfen nur Überweisungen angezeigt bekommen, die sie selbst getätigt bzw. erhalten haben. Bei anonymen Spenden darf kein Name in der Liste der Künstler angezeigt werden. Kreditkartendaten dürfen nicht von Nutzern auslesbar sein.

# Risikoabschätzung

Im folgenden sind Risiken gelistet, die während der Projektlaufzeit eintreten können. Zusätzlich sind mögliche Gegenmaßnahmen zu den einzelnen Risiken beschrieben. Die Gegenmaßnahmen, die bei eintreten eines Risikos gewählt werden, hängen jedoch immer von der konkreten Situation ab.

| N1. | Typ | Priori-tät | Wahrschein-lichkeit | Folge-risiken | Verant-wortliche | Name & Beschreibung | Gegenenmaßnahmen |
| --- | --- | --------- | ---------- | -------- | ------------ | ------------- | -------- |
| 1 | immer | hoch | mittel | 2, 3 | Martin | **Ausfall eines Projektmitglieds:** Ein Projektmitglied kann, zB bedingt duch eine Krankheit, längere Zeit nicht am Projekt mitarbeiten bzw scheidet komplett aus dem Projektteam aus. | Sammeln der bereits geleisteten und noch ausständigen Arbeit; Besprechung und Aufteilung der Aufgaben innerhalb der Gruppe (zusätzlich zum Jour-Fixe, kann auch elektronisch stattfinden). Zuteilung der Rolle zu einem anderen Gruppenmitglied. |
| 2 | entwicklung | hoch | niedrig | - | Marco, Johannes | **Rechtzeitige Fertigstellung gefährdet:** Die rechtzeitige Fertigstellung des Projekts ist gefährdet. Mögliche Ursachen könnten zu hohe Anforderungen, zu geringe zeitliche Ressourcen, Ausfall von Team-Mitgliedern, etc sein. | Reduktion von Features anhand ihrer Priorisierung (abhängig von aktuellem Fortschritt) |
| 3 | management | hoch | niedrig | 2 | Martin | **Verlust von Projekt-internen Wissen:** Verlust an Projekt-internem Wissen durch verschiedene Ursachen (zB Ausscheiden eines Projektmitglieds, Server-Ausfall, etc) | Dokumentation aller relevanten Informationen im SCM und Tracker; Eigenständige Backups vom Tracker; Zusammentragen aller lokal gespeicherten Informationen der einzelnen Teammitglieder. |
| 4 | planung, entwicklung | hoch | mittel | 2 | Marco, Johannes | **Notwendige Libraries nicht verfügbar:** Während des Projektverlaufs stellt sich heraus, dass für ein bestimmtes Feature notwendige Libraries nicht (frei) verfügbar sind. | Sofern der Aufwand vertretbar ist, können die Funktionalitäten selbst entwickelt, bzw andere Libraries adaptiert werden; Ist dies nicht möglich, muss das Feature so weit wie notwendig reduziert werden. |
| 5 | planung, entwicklung | mittel | mittel | 2 | Simeon | **Unzureichende Design-Entscheidungen:** Während der Implementierung stellt sich eine Design-Entscheidung als unzureichend heraus. | Design-Entscheidungen werden so früh wie möglich mit allen Projektmitgliedern besprochen, die die Entscheidung bezüglich Ihrer Rolle beurteilen; Modulares Design, damit die Auswirkungen falscher Design-Entscheidungen möglichst klein gehalten werden. |
| 6 | planung, entwicklung | hoch | mittel | 4 | Marco, Johannes | **Funktionalität des QR-Scanners:** Während der Implementierung stellt sich heraus dass der gewählte QR-Scanner nicht wie erwartet funktioniert. | Es muss ein neue Library gefunden werden. Falls es keine passende Alternative gibt muss auf das Feature verzichtet werden und es wird ausschließlich der Artist-Code verwendet. |
| 7 | entwicklung | niedrig | mittel | 4 | Marco, Johannes | **Serviceworker:** Die Implementierung der Serviceworker erweist sich als schwieriger als gedacht. | Die Nutzung von Serviceworker wird auf ein minimum beschränkt. |
| 8 | entwicklung, testing | mittel | mittel | 5 | Simeon | **Bug in Software werden erst spät erkannt:** Während der Implementierung stellt sich heraus dass es einen Bugs im Code gibt, der von den Tests nicht erkannt wurde.| Tests müssen schon im vorhinein genau sein. Falls doch vorhanden -> Bug finden und beheben. Falls nicht behebbar wegen Architektur -> Refactoring |
| 9 | entwicklung, testing | mittel | mittel | 8 | Luca | **Gitlab CI funktioniert nicht / überprüft nicht die Tests:** Durch fehlerhafte Konfiguration der Gitlab CI kann es passieren, dass auf den nötigen Branches die Testsuite nicht durchgeführt wird. |

# Informationswesen
Während des Projekts wird die Kommunikation wiefolgt ablaufen:
- Wöchentliche interne Treffen (freitags)
- Wöchentliche Treffen mit dem Tutor (montags)
- 5 Reviews (2 IRs, 3 MRs), zu denen jeweils ein Meilenstein abgeschlossen ist und bei denen jeweils ein Statusbericht gegeben wird
- Elektronische Kommunikation synchron mittels Discord, [Google Docs](https://docs.google.com) und [HackMD](https://hackmd.io). Asynchron mit dem Issue-Tracker auf GitLab. Bei Informationen mit niedriger Dringlichkeit ist die Signal-Gruppe oder der Discord-Server zu verwenden.
- Kommunikation mit Tutor und Auftraggebern per E-Mail und asynchron über GitLab (Artefakte des laufenden Projektmanagements werden dort hochgeladen)

Die zur Verfügung gestellte Infrastruktur umfasst:
- Discord Server
- Git Repository inkl. Wiki- und Issue-/Ticket-Funktion