Dieses Dokument enthält wichtige Informationen zur Organisation und Durchführung des Projekts.

Rollen

Person	Zuständigkeit
Anisa	Datenbank
Elnaz	Frontend
Marc	Backend
Matej	API, Backend
Simon	Frontend

Weitere Rollen:

• Dokumentationsbeauftragter: Matej
• Zeitkoordinator: Anisa
• Scrum Master: Marc

Sprachen

	Sprache
Dokumentation	Deutsch
Statusreport	Deutsch
Code	Englisch
Issues	Deutsch

Statusreports

Wöchentliche Statusreports zu dem Projekt werden hier veröffentlicht.

Zeiterfassung

Die Zeiterfassung wird von jedem Teammitglied selbständig erfasst. Diese Zeiten werden in den wöchtenlichen Statusreports dokumentiert.

Aufwandsschätzung für Issues

Für die Aufwandsschätzung benutzen wir die (modifizierten) Fibonacci Zahlen für die Story Points.

0,5 - 1 - 2 - 3 - 5 - 8

Legende:

• 0,5 SP -> Leichte Aufgaben, hauptsächlich Dokumentation und ähnliches
• 1 SP -> Leichte Aufgaben, z.B. Performanceoptimierung oder Bugfix
• 2 SP -> Leichtere Aufgaben, Codeveränderungen, meist keine neuen Program-Funktionen
• 3 SP -> Mittelgroße Aufgaben, größere Codeänderungen
• 5 SP -> Umfangreiche Aufgaben, größere Codeänderungen, die Recherche benötigen
• 8 SP -> Sehr große Aufgaben, es soll überprüft werden, ob man die Aufgabe in kleinere zerbrechen könnte

Dabei entspricht 1 Storypoint ungefähr 45 Minuten.

Planung der Entwicklungsphase - Gantt Diagramm

Frontend Guide

• Seiten-Komponente sollen immer mit “page-“ beginnen, Komponente innerhalb der Page nicht Beispielkomponente: page-logIn, page-main, table, graph, page-signIn

• Alle Divs in der Anwendung sind per default mit “display: flex” definiert

• Die Anwendung wird standardweise mit “Prozent” skaliert

• Services sind im Ordner “services” zu erstellen

• Icons und Bilder werden im Ordner “assets” gespeichert

• es wird vorerst mit dem Material Design von Angular gearbeitet

• Styles sollen so viel wie möglich in den scss-Dateien definiert werden (und nicht direkt im html, es sei denn es ist wirklich nicht wichtig)

• komponentenübergreifende Änderungen sollen abgesprochen werden

• Routing:

• • Default-Page: DepotSeite,
• • Falls kein SessionToken vorhanden bzw. nicht eingeloggt ist wird man auf die LoginSeite weitergeleitet,
• • Auf der LoginSeite kann man sich entweder einloggen oder zur RegistrierenSeite wechseln,
• • Bei erfolgreichem Einloggen/Registrieren bekommt man Zugang zur DepotSeite und die SessionToken,
• • Mithilfe der SessionToken muss sich der User zukünftig nicht mehr einloggen,
• • Im Header kann man sich ausloggen, die Token wird entfernt und man wird auf die LoginSeite zurückgeleitet,
• • Der LogOut-Knopf wird nur angezeigt, wenn man eingeloggt ist

Backend Guide

Namenskonvention

Klassen des Servers werden immer kategorisiert in eine der folgenden Gruppen:

• Controller
• Services
• Models
• Repositories
• Config

Um den Zweck einer Klasse einfach erkenntlich zu machen, endet jede Klasse mit dem Namen seiner Gruppe.

Bspw.: "UserAuthService"

Struktur

Unterschiedliche Funktionalitäten werden strikt getrennt und nicht in einer Klasse gehandelt.

Das abgreifen von Anfragen und das Verarbeiten dieser ist Beispiel für diese Implementierung.

Um Webabfragen zu empfangen werden Controller verwendet. Sie sind die Schnittstelle nach außen und leiten die Anfrage an einen passenden Service weiter.

Bspw.: "StockPriceController" & "StockPriceService"

Anfrage- & Antwortmanagement

Anfragen werden entweder in sogenannten Requestklassen abgefangen oder über einzelne Emfangsparametern.

Bspw.: "UserRegisterRequest"

Antworten werden in einer Responseklasse modelliert, in ein JSON-Objekt umgewandelt und dann zurückgesendet.

Bspw.: "APIResponse" (generische Klasse, die verwendet werden kann um unterschiedliche Antwortformate zu modellieren)