# Projektauftrag für "lehrcraft" von QSE_10@SEPM2020S

Dieser Auftrag baut auf diesem [Projektvorschlag](https://reset.inso.tuwien.ac.at/repo/2020ss-SEPM-group/ss20_sepm_qse_10/-/wikis/Project/Projektvorschlag) auf.

[[_TOC_]]

## Entwickler-Team
| Team-Mitglied | Gitlab-Username | E-Mail | Rolle | 2. Rolle |
| ------ | ------ | ------ | ------ | ------ |
| Christoph Bogner | @11808591 | [e-mail] | Backend-Architekt | |
| Jakob Hitzelhammer | @11734084 | [e-mail] | Qualitätsmanager | |
| Markus Hinkel | @11703479 | [e-mail] | Dokumentation/Git-Manager | Scrum-Master |
| Michael Kiran Huber | @11712763 | [e-mail] | Frontend-Architekt | Grafischer Designer |
| Tamas Schöberl | @11810348 | [e-mail] | Teamleiter| Scrum-Master |
| Thomas Stimakovits | @01551905 | [e-mail] | Test-Manager | |
| Alexander Firbas | @alexander.firbas | | Haupt-Tutor | |
| Hans-Jörg Schnedlitz | @hans-joerg.schnedlitz | | Tutor | |

## Ausgangssituation

Aus Gesprächen mit Lehrerinnen und Lehrern ging hervor, dass für sie eine Website zum Finden und Erstellen von Aufgaben und Übungsblättern sehr nützlich wäre. Nach kurzer Recherche stellte sich heraus, dass es momentan keine Applikation gibt, welche die Elemente des Findens und Erstellens von Aufgaben und die automatische Generierung von Übungsblättern vereint.

## Projektbeschreibung

lehrcraft.at soll eine kollaborative Web-Applikation werden, die den Austausch und die Erstellung von Übungsaufgaben und Arbeitsblättern für den Schulunterricht ermöglicht.

Ziel des Projekts ist es, eine schnelle und einfache Möglichkeit für das Kreieren ansprechender Arbeitsaufgaben zu bieten. Auf lehrcraft.at können dafür einerseits bestehende Aufgaben gefunden werden, andererseits können auch neue Aufgaben erstellt und für andere zugänglich gemacht werden. Diese Aufgaben können beliebig zu Aufgabenblättern zusammengestellt werden, welche ebenfalls von anderen gefunden werden können.

Das Finden und der Austausch von qualitativ hochwertigen Übungsmaterialien (Aufgaben & Aufgabenblättern) soll durch eine übersichtliche Sortierung, eine Upvote-/Downvotefunktion und eine Kommentarfunktion erleichtert werden.

Das Erstellen von Aufgaben soll in zwei Varianten durchführbar sein:
Erstens sollen User komplette, "statische" Aufgaben (z.B. offene Fragen) kreieren können.
Zweitens können User "dynamische" Aufgaben erstellen. Als "dynamische" Aufgaben oder Aufgabentemplates bezeichnen wir Aufgaben, bei denen konkrete Werte durch Variablen ersetzt werden. Diese Variablen werden später durch einen Generator mit konkreten Werten befüllt. Die Werte, die mittels des Generators eingefügt werden sollen, können mit Einschränkungen (z.B. Intervall, Zahlenmenge) versehen werden. Dynamische Aufgaben sollen also das Erstellen mehrerer Versionen einer Aufgabe einfach möglich machen.

Folgende Dynamische Aufgaben sollen erstellbar sein (Erweiterungen vorbehalten):
- Lückentext
- Mathematische Textaufgaben
- Mathematische Terme

Wie bereits erwähnt kann ein User aus mehreren Aufgaben(templates) Aufgabenblätter zusammenstellen ("craften"), welche über einen Generator in ein herunterladbares PDF-Dokument formatiert werden. Zusätzlich zum Aufgabenblatt werden hierbei auch die Lösungen bereitgestellt.

## Zielbenutzergruppen

In erster Linie richtet sich lehrcraft.at an **Lehrerinnen und Lehrer**. Insbesondere soll der Fokus, für das in der Lehrveranstaltung zu entwickelnde Projekt, auf Volksschullehrkräfte gelegt werden. Für diese Hauptnutzergruppe soll durch lehrcraft.at eine mühselige Arbeit vereinfacht werden und der Zugang zu interessanten Übungsideen anderer Berufskollegen geschaffen werden.

Für **Schülerinnen und Schüler** (bzw. deren Eltern) kann lehrcraft.at als Sammlung von Arbeitsaufgaben für eigenständiges Üben fungieren.


|Aktor|Rechte im System|Anmerkungen
|-----|-------------|----------|
|Admin|Uneingeschränkter Zugriff auf alle Inhalte.| Nur Administratoren können neue Templates für Beispiele erstellen, Beispiele aller Nutzer entfernen und neue Katogerien in der Suche einrichten oder entfernen.|
|Gast|Kann nur die hochgeladenen Beispiele/Übungsblätter einsehen. |Hat die Möglichkeit AufgabenTemplates zu sehen, kann aber keine Beispiele erstellen.|
|User| Zugriff auf alle angebotenen Services.| User können Beispiele/Übungsblätter erstellen, suchen, teilen, kommentieren, up-/downvoten, auswählen und downloaden. Können jedoch nur eigene Beispiel/-blätter löschen. |

## Funktionale Anforderung, Anwendungsfälle

### Featureliste

Die Kundenpriorität ist von 1-5 bewertet, wobei 5 die höchste Priorität darstellt.
Die Aufwandsabschätzung ist mit Fibonacci-Zahlen von 1-13 bewertet, wobei eine höhere Zahl einen höheren Aufwand darstellt.

Folgende Featurelist ist grob in 4 Kernbereiche unterteilt:
- 1.* betrifft Authentifizierung, Rollen
- 2.* betrifft Aufgabentemplates
- 3.* betrifft Aufgabenblätter
- 4.* betrifft Generator

|ID|Feature|Beschreibung|Priorität|Aufwand|
|------ |------ |------ |:------:|:------: |
|1.1|Lokale Registrierung der Nutzer|Nutzer haben die Möglichkeit, sich mit gültiger Email registrieren/anzumelden. Bestätigungs-Email ist Vorraussetzung. Benutzerdaten werden in lokaler Datenbank gespeichert. |3|5|
|1.2|Oauth Registrierung der Nutzer|Nutzer haben die Möglichkeit, sich über externe Dienste zu registrieren/anzumelden. (Vorerst geplant sind Google, Microsoft, Apple)|2|3|
|1.3|Nutzerrollen|Nutzer haben verschiedene Rollen. **Gäste** (nicht angemeldet) als readonly; **Nutzer** können Erstellen und eigene Sachen editieren; **Admin** können auch fremde Inhalte bearbeiten und löschen.|3|1|
|2.1|Nutzer kann Aufgabentemplates erstellen|Nutzer kann Aufgabentemplates erstellen, welche von einem Generator benutzt werden können. Der Ersteller kann Variablen in der Aufgabe definieren.|5|13|
|2.2|Variableneinschränkungen|Variablen im Aufgabentemplate können auf verschiedene Weisen eingeschränkt werden (Zahlenmengen, Intervalle, Nachkommastellen, Liste mit Werten)|5|8|
|2.3|Vorlagen/Kategorien für Aufgabentemplateerstellung|Vorlagen z.B: Lückentext, Textaufgaben, Formen, Umrechenaufgaben etc.|4|3|
|2.4|Sichtbarkeit von Aufgabentemplates einschränken|Aufgabentemplates sind standardmäßig öffentlich, aber die Sichtbarkeit soll beschränkbar sein|1|1|
|2.5|Up/Downvotes/Reports/Favoriten von Aufgabentemplates|Aufgabentemplates sollen bewertet und auch gemeldet werden können, falls diese gegen Richtlinien verstoßen oder unbrauchbar sind. Auch sollen Nutzer Aufgabentemplates als Favorit speichern können.|2|2|
|2.6|Auflisten von Aufgabentemplates|Die erstellten Aufgabentemplates werden in einer Liste angezeigt, der Nutzer kann suchen/filtern (Kategorie, Schwierigkeit, Fach, Schulstufe, Tags)|5|2|
|2.7|Aufgabentemplatekommentare|Nutzer können Aufgabentemplates kommentieren (z.B. für Verbesserungsvorschläge)|1|3|
|3.1|Zusammenstellen von Arbeitsblättern|Nutzer haben die Möglichkeit, diverse Aufgabentemplates zu einem Arbeitsblatt zusammenzufügen (ähnlich Einkaufswagen im e-Commerce).|4|3|
|3.2|Arbeitsblätter können gespeichert/gesucht werden|Nach ähnlichen Punkten wie in 2.6. |2|3|
|3.3|Sichtbarkeit von Arbeitsblättern einschränken|Arbeitsblätter sind standardmäßig öffentlich, aber die Sichtbarkeit soll beschränkbar sein.|1|1|
|3.4|Up/Downvotes/Reports/Favoriten von Arbeitsblättern| Wie 2.5. |1|2|
|4.1|Generator erstellt Aufgabenblätter|Der Generator nimmt ausgewählte Aufgabentemplates und füllt die angegebenen Variablen mit entsprechenden Zufallswerten und fügt diese zu einem Arbeitsblatt zusammen.|5|8|
|4.2|Generator formatiert Arbeitsblatt|Generator soll Kopfzeile (z.B. Nutzername, Arbeitsblattname, Datum...) oder Seitenzahlen hinzufügen und Aufgaben nummerieren können.|4|2|
|4.3|Arbeitsblattexport|Nutzer können ein fertiges Arbeitsblatt (als PDF) herunterladen.|3|2|
|4.4|Lösungsblätter|Generator soll ebenfalls Lösungsblätter zu den jeweiligen Arbeitsblättern erstellen können|3|5|

Aus Gründen der Lesbarkeit wurde in der Featureliste die männliche Form gewählt, nichtsdestoweniger beziehen sich die Angaben auf Angehörige aller Geschlechter.

### Anwendungsfall Übersicht
1. **User-Verwaltung** (3): nur Grundfunktionalität notwendig
2. **Aufgabentemplate-Verwaltung** (5): Unbedingt erforderlich, kritisch
3. **Arbeitsblätter-Verwaltung** (5): Unbedingt erforderlich, kritisch
4. **Social-Features** (1): Erweiternde Features, können auch nach dem Projekt implementiert werden
5. **Generator** (5): Unbedingt erforderlich, kritisch

### Iceberglist
Dies ist eine erste Version der Iceberglist. Die Spalte ID(FL) referenziert hierbei die IDs der Featureliste (FL). AT steht in der Liste für Aufgabentemplate, AB für Arbeitsblatt.

| Id(FL) | Feature, Aktor | Anwendungsfälle | Kundenpriorität | Aufwand | Version | Zuständiger |
|--------|-------------------------|------------------------------------------------------------------------------------------------------------|-----------------|---------|---------|-------------|
| 1.1 | User-Verwaltung, Anonym | Account anlegen | 3 | 5 | 1 | Markus |
| 1.1 | User-Verwaltung, User | Account-Daten ändern | 2 | 5 | 1 | |
| 1.1 | User-Verwaltung, User | An-/Abmelden | 3 | 3 | 1 | |
| 1.1 | User-Verwaltung, User | Account löschen | 2 | 1 | 1 | |
| | User-Verwaltung, User | User suchen | 1 | 5 | 3 | |
| | User-Verwaltung, User | User-Profil einsehen (AT/AB von User, Statistiken) | 1 | 13 | 3 | |
| | User-Verwaltung, Admin | User-Daten einsehen | 1 | 5 | 3 | |
| | User-Verwaltung, Admin | User-Daten bearbeiten | 1 | 5 | 3 | |
| | User-Verwaltung, Admin | User löschen | 1 | 1 | 3 | |
| 1.2 | User-Verwaltung, Anonym | Account über OAuth anlegen | 2 | 5 | 1 | |
| 1.2 | User-Verwaltung, User | An-/Abmelden über OAuth | 2 | 3 | 1 | |
| 2.6 | AT-Verwaltung, Anonym | AT suchen | 5 | 5 | 1 | |
| 2.6 | AT-Verwaltung, Anonym | AT ansehen | 5 | 13 | 1 | |
| 2.1 | AT-Verwaltung, User | Statische AT erstellen (Multiple Choice, Lückentext, Offene Fragen) | 5 | 13 | 1 | |
| 2.1 | AT-Verwaltung, User | Statische AT bearbeiten | 4 | 13 | 1 | |
| 2.1 | AT-Verwaltung, User | Statische AT löschen | 3 | 2 | 1 | |
| 2.1 | AT-Verwaltung, User | Dynamische AT erstellen (Mathematische Textaufgaben, Grundrechnungsarten/Umwandlungen, Einfache Grammatik) | 5 | 20 | 2 | |
| 2.1 | AT-Verwaltung, User | Dynamische AT bearbeiten | 4 | 20 | 2 | |
| 2.1 | AT-Verwaltung, User | Dynamische AT löschen | 3 | 2 | 2 | |
| 3.2 | AB-Verwaltung, Anonym | AB suchen | 5 | 5 | 2 | |
| 3.2 | AB-Verwaltung, Anonym | AB ansehen | 5 | 8 | 2 | |
| 3.1 | AB-Verwaltung, User | AB erstellen | 5 | 5 | 2 | |
| 3.1 | AB-Verwaltung, User | AT zu AB hinzufügen | 5 | 3 | 2 | |
| 3.1 | AB-Verwaltung, User | AT von AB entfernen | 5 | 3 | 2 | |
| 2.5 | Social-Features, User | AT upvoten/downvoten | 2 | 3 | 3 | |
| 2.5 | Social-Features, User | AT reporten | 2 | 3 | 3 | |
| 2.5 | Social-Features, User | AT favorisieren | 2 | 3 | 3 | |
| 2.7 | Social-Features, User | AT kommentieren | 2 | 5 | 3 | |
| 3.4 | Social-Features, User | AB upvoten/downvoten | 2 | 3 | 3 | |
| 3.4 | Social-Features, User | AB reporten | 2 | 3 | 3 | |
| 3.4 | Social-Features, User | AB favorisieren | 2 | 3 | 3 | |
| | Social-Features, User | AB kommentieren | 2 | 5 | 3 | |
| | Social-Features, Admin | Reports einsehen | 1 | 5 | 3 | |
| 4.2 | Generator, User | AB konfigurieren/formatieren | 5 | 13 | 2 | |
| 4.1 | Generator, User | AB generieren (AT mit Werten befüllen) | 5 | 13 | 2 | |
| 4.3 | Generator, User | AB generieren (PDF-Dokument erstellen) | 5 | 8 | 2 | |
| 4.4 | Generator, User | AB generieren (Lösungs-PDF erstellen) | 5 | 8 | 2 | |

## Domänenmodell

## Arbeitsstruktur und grober Projektplan

### Rollenverteilung
| Team-Mitglied | Gitlab-Username | E-Mail | Rolle | 2. Rolle |
| ------ | ------ | ------ | ------ | ------ |
| Christoph Bogner | @11808591 | [e-mail] | Backend-Architekt | |
| Jakob Hitzelhammer | @11734084 | [e-mail] | Qualitätsmanager | |
| Markus Hinkel | @11703479 | [e-mail] | Dokumentation/Git-Manager | Scrum-Master |
| Michael Kiran Huber | @11712763 | [e-mail] | Frontend-Architekt | Grafischer Designer |
| Tamas Schöberl | @11810348 | [e-mail] | Teamleiter| Scrum-Master |
| Thomas Stimakovits | @01551905 | [e-mail] | Test-Manager | |
| Alexander Firbas | @alexander.firbas | | Haupt-Tutor | |
| Hans-Jörg Schnedlitz | @hans-joerg.schnedlitz | | Tutor | |

### Horizontale Verantwortlichkeiten

#### Backend Architekt: Christoph Bogner
* Kontrolle der Schichtenarchitektur
* Design der Programmarchitektur
* Komponentendiagramm
* Dependency Management
* Externe Apis/Plugins
* Expertenwissen der verwendeten Technologien

#### Frontend Architekt: Michael Huber
* Design der Frontend-Architektur
* Design des UI
* Erstellen der Coroporate Identity
* Logo
* Colouring
* Expertenwissen/Kontrolle der Frontend Technologien
* Angular Material

#### Teamleiter : Tamas Schöberl
Der Teamleiter ist zuständig für die Koordination innerhalb das Teams und für das allgemeine Projektmanagement.

* Organisation & Planung
* Einhalten der Deadlines
* Risikoanalyse
* Erstellung und Überwachung des groben Projektplans
* Organisation und Führung von Meetings
* Controlling & Tracking
* Stundenlisten
* Arbeitsverteilung
* Ansprechpartner für Dritte
* Einhaltung des Scrum Prozesses (Scrum Master)

#### Dokumentationsbeauftragter: Markus Hinkel
* Versionskontrolle
* Kontrolle der Commits (messages, Regelmäßigkeit)
* Kontrolle des Branchings und Mergings

* Gitlab Dokumentation
* Templates für
* Wiki -Einträge
* Issues
* Überwachung/Führung der Meeting-Protokolle
* Kontrolle des Javadoc

* Swagger Kontrolle

#### Testmanager: Thomas Stimakovits
* Ausarbeiten einer Teststrategie
* Frontend Testing
* Backend Testing (jUnit, restAssured)
* Kontrolle der Testkonventionen
* Unabhägigkeit der Unittests
* verwendete Libraries
* Test-Driven Development
* Kontrolle der Testabdeckung
* Optional: Continous Integration

#### Qualitätsmanager: Jakob Hitzelhammer
* Reviews
* Einhaltung des Projektvauftrags
* Einhaltung der Codingkonventionen
* Überprüfung von Qualitätsmerkmalen
* Userfreundlichkeit
* Ausführungsgeschwindigkeit (Ladezeiten)

### Grober Projektplan

## Projektabgrenzungen

## Schichtendiagramm
## Lieferkomponenten
In den nachfolgenden beiden Abschnitten wird die dem Kunden übermittelte Software inklusive aller Artefakte und Dokumentationen beschrieben und festgelegt. Teile dieser Pakete sind bereits während der Entwicklungsarbeit verfügbar. Mit den kompletten Auslieferung der hier genannten Punkte kann aber erst bei finaler Projektauslieferung gerechnet werden.

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

- Angular (Node.js) Applikation mit Node-Package-Managment, um das Frontend zu bedienen.
- Springboot (Java) Applikation mit Maven Dependency-Managment, um das Backend zu bedienen.
- H2 Datenbank inklusiver initialer (Test-)Datensätze um das Programm in Betrieb zu nehmen und zu testen.
- Konfigurationsdaten für Datenbanken und Server, soweit für Wartung und Weiterentwicklung notwendig.

### Artefakte & Projektdokumentation
- Domänenmodell & Komponentendigramm
- Funktionale Anforderungen
- Anwendungsfallbeschreibung
- Anwendungsfalldiagramme, Pakete & Aktorenhierarchie
- Testplan, Funktionale Testfälle, Testberichte (soweit für die Wartung und Weiterentwicklung notwendig)
- Datenbankbeschreibung & ER Diagramm
- Präsentationen zu den Reviews (MRs)
- Stundenübersicht
- Swagger-UI als REST-Spezifikation
- Projektendbericht

### Meilensteine

### 1. Projektauftrag

* Einreichen des Projektvorschlags
* Verarbeiten des Feedbacks
* Nachjustieren der bereits eingereichten Auftragskomponenten
* Erstellen des Projektauftrags
* Featurliste vervollständigen
* Grober Projektplan erstellen

### 2. Arbeitsinfrastruktur aufsetzen

* Technischer Setup (Sprint 1)
* Code-Template
* Lauffähige pre-release Version der Applikation
* Alle Schichten funktionstüchtig
* Grundlegende CRUD-Operationen unterstützt
* Git/Release Workflow
* Coding Guidelines
* Agiles arbeiten
* SCRUM-Regeln
* User Stories dokumentiert
* Kanban-Board

### 3. Alpha-Version, 40% der US

* Rahmenfeatures umgesetzt
* Accountverwaltung (User-Side)
* Template-Speicher (Statische Templates)
* UI-Prototyp fertig
* Basic-Features umgesetzt (CRUD, Display, Search)
* Design
* Template-Aufbau finalisieren
* Technische Details des Generators

### 4. Beta-Version, 70% der US

* Produkt mit eingeschränkter Funktionalität
* Selling-Features funktionieren, bestimmte Beispiele
* Dynamische Templates
* Generator
* Erweitbarkeit vorhanden
* Service-Layer getestet
* Vorbereitung für die Hauptversion
* Bugs identifizieren
* Agile Anpassung basierend auf kontinuierliches Testen

### 5. Fertiges Produkt, 100% der US

* Alle Use Cases erfüllt
* Low-Prio Features umgesetzt
* Admin-Benutzerverwaltung
* Social-Features
* Bereit für Abnahme (Akzeptanztests)
* Fertige Dokumentation

### Abgrenzung des Lieferumfangs

## Nichtfunktionale Anforderungen
* Verfügbarkeit - Anwendung soll stabil laufen und mehrere Anfragen parallel bedienen können.
* Browser-Konformität - Sämtliche features sollen auf Firefox und Chrome fehlerfrei benutzbar sein.
* Userfreundlichkeit - Die Benutzeroberfläche sollte einfach zu bedienen und klar strukturiert sein.
* Wartbarkeit - System muss möglichst einfach wartbar und änderbar sein. Dafür benötigt es eine vollständige Codedokumentation.
* Skalierbarkeit - Die Anwendung sollte unter unterschiedlichen Speicherbedarfen und Nutzerzahlen funktionieren.
* Ästhetik - Die Nutzeroberfläche sollte visuell ansprechend sein.
* Feedback Nutzer - Die Anwendung sollte dem Nutzer beim Auftreten von Fehlern sinnvolles Feedback geben um das Problem einfach lösen zu können.
* Feedback Entwickler - Feedback der Nutzer oder innerhalb des Teams soll verwendet werden um Fehler und Qualitätsmängel schnell verbessern zu können.
* Datensicherheit - Private Daten der Nutzer sollen nur für Admins einsehbar sein.
* Wiederherstellung ??
TODO ???

## Risikoabschätzungen

## Informationswesen
Die Informationsstruktur für das Projekt wird folgendermaßen aussehen:

- Mindestens ein Wöchentliche Treffen intern (Jour-Fixe) über Discord, bei diesen werden auch Sprint-Retrospectives abgehalten
- Wöchentliche Treffen mit dem Tutor (Tutortreffen) mittels Zoom
- Insgesamt 5 Reviews (2 IRs, 3 MRs) mit 5 Statusberichten mittels Zoom
- Elektronische Kommunikation synchron mit Discord und hackmd.io, asynchron über Gitlab mittels Issues und Wiki-Einträgen
- Kommunikation mit den Auftraggebern und Tutor per Email
- Informationen zu Richtlinien im Tuwel-Forum

Die zur Verfügung gestellte Infrastruktur umfasst:

- Gitlab-Repository
- Gitlab-SCRUM
- Gitlab-Wiki
- Email-Adresse des Tutors
- Grundlegendes Code-Template
- Frontend: Angular.io
- Backend: Springboot
- Datenbank: H2

## Besonderheiten