add documentation into branch to merge into master

documentation/src/00_DocumentationToDos.adoc

@@ -0,0 +1,21 @@
+= To Dos der Documentation
+
+== Kontextabgrenzung in 03
+
+* Fachlicher Kontext mit Diagramm
+* Technischer Kontext mit Diagramm
+
+== Blocksicht des Aufbaus in 05
+
+* 1000 verschiedene sachen
+
+== Laufzeitsicht in 06
+
+* auch todes viel
+
+== Noch ne sicht in 07
+
+* auch ass viel
+
+== Mehr Konzepte hinzufügen in 08
+

documentation/src/01_introduction_and_goals.adoc

@@ -1,15 +1,46 @@
+
 [[section-introduction-and-goals]]
 ==	Einführung und Ziele
 
 === Aufgabenstellung
 
+
+==== Was ist das Modul "Gruppenbildung"?
+
+* Die Gruppenbildung dient dem Erstellen und Verwalten von Gruppen im Kontext zu Vorlesungen und sonstigen Veranstaltungen im Rahmen der Heinrich-Heine-Universität.
+* Die Gruppenbildung kann entweder zur Bildung von Gruppen in Verbindung mit einer Vorlesung, einem Kurs, oder einer Lerngruppe oder unabhängig von Vorlesungen zur Bildung einer anderen Zusammenkunft von Studenten außerhalb von Veranstaltungen der Universität verwendet werden.
+* Das Modul kann sowohl von Studenten zur Verwaltung der Teilnehmer einer Vorlesung o.ä., als auch von Studenten zum Bilden von Lerngruppen verwendet werden.
+
+
+==== Wesentliche Features
+
+* Funktionsfähige Software zur Gruppenbildung im Zusammenhang mit oder unabhängig von einer Vorlesung
+* Implementierung verschiedener Rollen mit verschiedenen Funktionen zur Separation von Studenten und Organisatoren
+* Eignung für den täglichen Gebrauch durch viele Benutzer
+* Gute Performance und intuitives Interface
+* Einfache und zuverlässige Verwaltung der Daten über einen langen Zeitraum
+
+
 === Qualitätsziele
 
+[cols="1,2" options="header"]
+|===
+|Qualitätsziel |Motivation und Erläuterung
+|Effizienz und Zuverlässigkeit |Die Softwware wird in Zukunft von vielen Usern gleichzeitig verwendet werden. Dementsprechend spielt Effizienz und Zuverlässigkeit eine große Rolle.
+|Attraktivität |Da die Software ein Teil des MOPS-Moduls ist, das von Studenten täglich verwendet werden soll, wird Wert auf ein attraktives und intuitives Interface gelegt.
+|Wartbarkeit und Analysierbarkeit |Da die Software nach dem Praktikum in fremde Hände gegeben wird, sollte sie für außenstehende gut wartbar sein, ohne viel Zeit aufwenden zu müssen, bis man den Code verstanden hat. Dementsprechend sollte der Code sinnvoll auskommentiert sein. Außerdem soll die Benennung der Variablen, Klassen und Methoden gut verständlich sein.
+|Änderbarkeit |Da die Software Teil eines Praktikums ist und ggf. am Endprodukt Änderungen vorgenommen werden müssen, sollte der Code zugänglich für Änderungen sein. Dies schließt direkt an die Verständlichkeit des Codes an (s.o.).
+|Einfache Anbindung an andere Komponenten des MOPS-Moduls |Da die Komponente Gruppenbildung in Zusammenarbeit mit anderen Komponenten des MOPS-Moduls funktionieren soll, wird eine Schnittstelle für die anderen Komponenten gestellt.
+|===
+
+
 === Stakeholder
 
 [cols="1,1,2" options="header"]
 |===
 |Rolle |Kontakt |Erwartungshaltung
-| _<Rolle-1>_ | _<Kontakt-1>_ | _<Erwartung-1>_
-| _<Rolle-2>_ | _<Kontakt-2>_ | _<Erwartung-2>_ 
+|Entwicklerteam IT-Bois |Entwickler der Software |Möchte Einsicht in Softwareentwicklung im Team und in der Praxis erhalten, Fähigkeiten im Bezug auf Entwicklung einer Software weiterentwickeln, ein gutes Endprodukt für eine gute Benotung im Praktikum abliefern.
+|Jens Bendisposto, Christian Meter, ... |Veranstalter des Praktikums, Bewerter der Software |Möchten ein gutes Gesamtprodukt aus allen Komponenten des MOPS-Moduls erhalten und erwarten demnach eine gute Software als Endprodukt.
+|Studenten |Verwender der Software nach der Fertigstellung |Möchten eine zuverlässige und schnelle Software im Universitätsalltag verwenden, ohne vor Schwierigkeiten in der Bedienung gestellt zu werden.
+|IT-Abteilung der HHU |Möchte nach Übernahme des MOPS-Moduls einen verständlichen, wartbaren Code erhalten, um diesen nach Ende des Praktikums verwalten zu können.
 |===

documentation/src/02_architecture_constraints.adoc

@@ -1,4 +1,28 @@
 [[section-architecture-constraints]]
 == Randbedingungen
 
+=== Technische Randbedingungen
 
+[cols="1,2" options="header"]
+|===
+|Randbedingung |Erläuterung und Hintergrund
+|Niedrige Hardwareanforderungen |Da nicht von jedem Studenten erwartet werden kann, sich einen PC mit starker Hardware zuzulegen, muss das System auch in Kombination mit Hardware von geringerer Leistung gut funktionieren.
+|Betrieb auf allen standartmäßigen browserfähigen Geräten |Da die geschriebene Software eine Webanwendung ist, deren Darstellung nur über Websites funktioniert, ist es auf jedem browserfähigen Gerät möglich, sie zu verwenden. Unter anderem sind demnach Apple, Windows, Linux unterstützte Betriebssysteme.
+|Implementierung in Java, Darstellung durch HTML |Die Funktionalität der Software ist vollständig mit Java 11 implementiert. In der Anwendung wird die Software durch HTML sichtbar gemacht.
+|Anbindung an andere MOPS-Komponenten durch Links |Da die Software ein Teil des MOPS-Moduls ist, ist die Kommunikation mit den anderen Komponenten gewährleistet. Die Weiterleitung erfolgt über Links.
+|Keine Verwendung von fremder Software außerhalb des MOPS-Moduls |Abgesehen von den anderen Komponenten des MOPS-Moduls wird keine Fremdsoftware verwendet.
+|===
+
+=== Organisatorische Randbedingungen
+
+[cols="1, 2" options="header"]
+|===
+|Randbedingung |Erläuterung und Hintergrund
+|Team |Team IT-Bois der Veranstaltung "Programmierpraktikum 2"
+|Zeitplan |Beginn der Entwicklung am 2. März 2020, Ende der Entwicklung am 27. März 2020. Abgabe der Software am letzten Tag.
+|Vorgehensmodell |Testorientierte Entwicklung, also Schreiben der Tests vor oder während der Implementierung der Funktionalität. Zur Dokumentation wird das arc42-Modell verwendet. Die vollständige Dokumentation ist eins der Ziele des Praktikums.
+|Entwicklungswerkzeuge |Erstellen der Grundidee durch Tafelbilder, die von Teammitgliedern entworfen werden. Implementierung der Quelltexte in IntelliJ, außerdem Einbindung vom Spring Framework.
+|Konfigurations- und Versionsverwaltung |Verwendung von Github während des gesamten Praktikums.
+|Testwerkzeuge und -prozesse |JUnit 5 für automatisiertes Testing, Checkstyle und Spotbugs für das Prüfen des Quellcodes. Alle Tests, Checkstyle und Spotbugs und die Continuous Integration (lässt Tests der Anwendung laufen) prüfen den Code vor dem Merge in den Master-Branch.
+|Veröffentlichung als Werkzeug der Universität |Die Quelltexte werden nach Abgabe der Lösung der Universität übergeben.
+|===

documentation/src/03_system_scope_and_context.adoc

@@ -6,17 +6,15 @@
 === Fachlicher Kontext
 
 
+image::fachlicher_kontext.png[]
 
-**<Diagramm und/oder Tabelle>**
-
-**<optional: Erläuterung der externen fachlichen Schnittstellen>**
+Das System wird vom User bedient. Externe Systeme, die Daten von unserem System anfordern, sind die angegebenen. Diese werden ebenfalls im Rahmen des Praktikums entwickelt.
 
 === Technischer Kontext
 
 
+image:technischer_kontext.png[]
 
-**<Diagramm oder Tabelle>**
+Das System erhält Authentifikationsinformationen von einem universitätsinternen Keycloak-Server. Damit können sich die User anmelden. Außerdem erhält es von den anderen Systemen die CSV-Dateien, die die Mitglieder, die einer Gruppe hinzugefügt werden sollen, angibt.
 
-**<optional: Erläuterung der externen technischen Schnittstellen>**
-
-**<Mapping fachliche auf technische Schnittstellen>**
+Die User erhält das System somit von Keycloak, den Input der externen Systeme in Form von CSV-Dateien.

documentation/src/05_building_block_view.adoc

@@ -7,81 +7,66 @@
 
 
 
-_**<Übersichtsdiagramm>**_
+image::bausteinsicht.png[]
 
-Begründung:: _<Erläuternder Text>_
 
-Enthaltene Bausteine:: _<Beschreibung der enthaltenen Bausteine (Blackboxen)>_
+Das System erhält vom User zunächst eine Eingabe in Form eines textuellen Inputs in ein Formular oder eines Knopfdrucks. Dieser Input wird, entsprechend seiner Art, an die Komponenten Gruppenerstellung, Gruppenverwaltung, Gruppensuche und Gruppenbeitritt gegeben.
 
-Wichtige Schnittstellen:: _<Beschreibung wichtiger Schnittstellen>_
+Gruppenerstellung gibt die Information, dass eine Gruppe erstellt wurde, an die Gruppenverwaltung weiter, die Gruppen speichert und löscht.
+
+Eine Eingabe direkt an die Gruppenverwaltung kann z.B. das Löschen einer Gruppe oder das Entfernen eines Users sein. Dies wird von der Gruppenverwaltung selbst durchgeführt.
+
+Die Gruppensuche erhält als Input einen Suchbegriff, den der User eingibt.  Die Suche sucht dann mithilfe der Gruppenverwaltung die gespeicherten Gruppen, die den Suchbegriff beinhalten, heraus und zeigt sie dem User an.
+
+Von der Suche aus kommt man zum Gruppenbeitritt. Dieser wird ebenfalls an die Gruppenverwaltung weitergeleitet und von ihr durchgeführt.
+
+
+Wichtige Schnittstellen:: Die Kommunikation zwischen den Komponenten erfolgt mithilfe von Methodenaufrufen und den darin übergebenen Parametern.
 
 
 
-==== <Name Blackbox 1>
+==== Gruppenerstellung
+
+image::whitebox_erstellen.png[]
+
+Im obigen Diagramm sieht man eine detaillierte Ansicht des Vorgangs der Gruppenerstellung.
+
+Zunächst wird der Input des Users, der in das Formular zur Gruppenerstellung eingetragen wird, vom WebController.java gemapped, also aufgezeichnet, und an den ControllerService.java weitergeleitet. Dort wird die Methode createGroup aufgerufen, falls es sich um eine Gruppe handelt, oder createOrga, falls eine Veranstaltung erstellt wird.
+Beide Methoden erhalten einen Keycloak-Account, einen Gruppentitel, eine Beschreibung, die gewünschte Sichtbarkeit und die gewünschte maximale Teilnehmerzahl, bzw. die Information, dass die Teilnehmerzahl unbegrenz sein soll.
+
+Innerhalb der beiden Methoden werden die Methoden updateTitle, updateDescription, addUser und updateRole aufgerufen. Diese erstellen sogenannte Events mit verschiedenen Eigenschaften.
+Es wird ein CreateGroupEvent erstellt, das aussagt, dass eine Gruppe erstellt wird. Zu jeder Aktion, die beim Erstellen der Gruppe ausgeführt wird, wird ein Event erstellt, so z.B. auch ein AddUserEvent, wenn der Ersteller der Gruppe hinzugefügt wird, oder ein UpdateTitleEvent, wenn der Titel gesetzt wird. So wird zu jedem Attribut der Gruppe ein Event erstellt.
+
+Diese Events werden in den EventService.java hineingegeben. Dieser ist dafür zuständig, das Event zu speichern und erledigt dies mithilfe der Methoden saveEvent und getEventDTO.
+
+Das DTO wird weitergereicht an das EventRepository. Dies ist ein Interface, das von Java gestellte Methoden enthält, die die Kommunikation mit der Datenbank durch Queries erleichtern.
+Durch die Methode save wird das DTO nun in der Datenbank gespeichert.
+
+
+==== Gruppenverwaltung
+
+image::whitebox_verwalten.png[]
+
+Die Gruppenverwaltung funktioniert sehr ähnlich wie die Gruppenerstellung. Zunächst wird der Input vom WebController erfasst. Dieser wird aber zunächst an den ValidationService geleitet. Dieser prüft mithilfe der Methoden checkIfAdmin und checkTitleAndDescription, ob der User, der die Änderungen vornehmen möchte, berechtigt ist, dies zu tun, und ob er valide Eingaben abgesendet hat.
+
+Wenn diese Eingaben korrekt sind, dann werden sie an den ControllerService weitergegeben. Dieser erstellt analog zur Gruppenerstellung die Events, die die Änderungen an den Gruppen speichern.
+Diese Änderungen werden, ebenfalls analog, in die Datenbank gespeichert.
 
 
 
-_<Zweck/Verantwortung>_
+==== Gruppensuche
 
-_<Schnittstelle(n)>_
+image::whitebox_suche.png[]
 
-_<(Optional) Qualitäts-/Leistungsmerkmale>_
-
-_<(Optional) Ablageort/Datei(en)>_
-
-_<(Optional) Erfüllte Anforderungen>_
-
-_<(optional) Offene Punkte/Probleme/Risiken>_
-
-==== <Name Blackbox 2>
-
-_<Blackbox-Template>_
-
-==== <Name Blackbox n>
-
-_<Blackbox-Template>_
+Bei der Gruppensuche wird, vergleichbar mit der Gruppenverwaltung, zunächst der Input geprüft. Wenn der Suchbegriff valide ist, also nicht leer, dann wird im GroupService entweder die Methode findGroupWith aufgerufen, die die Gruppen zurückgibt, die den Suchbegriff im Titel oder in der Beschreibung enthalten, oder die Methode getAllGroupsVisibilityPublic, die alle Gruppen zurückgibt, deren Sichtbarkeit öffentlich ist. Private Gruppen werden in der Gruppensuche nicht angezeigt.
 
 
-==== <Name Schnittstelle 1>
+==== Gruppenbeitritt
 
-...
+image::whitebox_beitreten.png[]
 
-==== <Name Schnittstelle m>
+Hier wird der Input des Users in Form eines Knopfdrucks an den WebController geleitet. Dieser ruft dann den ValidationService auf, der den Vorgang mithilfe zweier Methoden prüft. Zunächst wird geprüft, ob der User bereits in der Gruppe ist. Wenn nicht, dann wird noch geprüft, ob die Gruppe bereits die maximale Teilnehmerzahl erreicht hat.
 
-=== Ebene 2
+Wenn beides nicht der Fall ist, dann wird der ControllerService aufgerufen, der mithilfe der Gruppenverwaltung und des Erstellens eines AddUserEvents den neuen User in die Gruppe einfügt und die Änderung an die Datenbank vermittelt.
 
 
-
-==== Whitebox _<Baustein 1>_
-
-
-
-_<Whitebox-Template>_
-
-==== Whitebox _<Baustein 2>_
-
-_<Whitebox-Template>_
-
-...
-
-==== Whitebox _<Baustein m>_
-
-_<Whitebox-Template>_
-
-=== Ebene 3
-
-
-
-==== Whitebox <_Baustein x.1_>
-
-
-
-_<Whitebox-Template>_
-
-==== Whitebox <_Baustein x.2_>
-
-_<Whitebox-Template>_
-
-==== Whitebox <_Baustein y.1_>
-
-_<Whitebox-Template>_

documentation/src/06_runtime_view.adoc

@@ -2,16 +2,4 @@
 == Laufzeitsicht
 
 
-
-=== _<Bezeichnung Laufzeitszenario 1>_
-
-*  <hier Laufzeitdiagramm oder Ablaufbeschreibung einfügen>
-*  <hier Besonderheiten bei dem Zusammenspiel der Bausteine in diesem Szenario erläutern>
-
-=== _<Bezeichnung Laufzeitszenario 2>_
-
-...
-
-=== _<Bezeichnung Laufzeitszenario n>_
-
-...
+Erläutert in Abschnitt 5.

documentation/src/07_deployment_view.adoc

@@ -3,32 +3,17 @@
 
 
 
-=== Infrastruktur Ebene 1
+=== Infrastruktur
 
+image::deployment.png[]
 
+[cols="1,2" options="header"]
+|===
+|Komponente |Definition
+|Java Application |Ausführbares Programm, mithilfe dessen sich die Anwendung starten lässt
+|Java Runtime Environment SE |Umgebung, auf der das Programm läuft
+|Docker Container |Beinhaltet die Anwendung und simuliert Betriebssystem, auf dem die Anwendung läuft. Enthält außerdem die Datenbank.
+|Browser |Anwendung, die Zugang zum Internet ermöglicht
+|Any type of host |Jedes Endsystem, das Zugriff auf einen Browser hat, kann die Gruppen2Application verwenden.
+|===
 
-_**<Übersichtsdiagramm>**_
-
-Begründung:: _<Erläuternder Text>_
-
-Qualitäts- und/oder Leistungsmerkmale:: _<Erläuternder Text>_
-
-Zuordnung von Bausteinen zu Infrastruktur:: _<Beschreibung der Zuordnung>_
-
-=== Infrastruktur Ebene 2
-
-
-
-==== _<Infrastrukturelement 1>_
-
-_<Diagramm + Erläuterungen>_
-
-==== _<Infrastrukturelement 2>_
-
-_<Diagramm + Erläuterungen>_
-
-...
-
-==== _<Infrastrukturelement n>_
-
-_<Diagramm + Erläuterungen>_

documentation/src/08_concepts.adoc

@@ -2,17 +2,47 @@
 == Querschnittliche Konzepte
 
 
+=== Benutzeroberfläche
 
-=== _<Konzept 1>_
+Für die Benutzeroberfläche wurd Wert auf Einheitlichkeit und stimmige Farbgebung geachtet. Dies sieht man beispielsweise an der Darstellung der Details einer Gruppe:
 
-_<Erklärung>_
+image::frontend_1.png[]
 
-=== _<Konzept 2>_
+Außerdem wird darauf geachtet, dass sich die Oberfläche selbst erklärt und dementsprechend intuitiv funktioniert, ohne, dass Erklärungen notwendig sind.
 
-_<Erklärung>_
+Ein Beispiel hierfür ist das Erstellen einer Gruppe:
 
-...
+image::frontend_2.png[]
 
-=== _<Konzept n>_
+Hier ist das Ausfüllen der Felder des Formulars selbsterklärend und eindeutig.
 
-_<Erklärung>_
+
+=== Event
+
+image::concept_event.png[]
+
+Hier sieht man ein Beispiel für ein Event. Jedes Event ist eine Unterart der Oberklasse Event. Diese Events werden in der Datenbank gespeichert (s. 9. Entscheidungen, "Event Sourcing")
+
+Jede Eventklasse überschreibt die Methode "applyEvent", sodass, je nach Eventtyp die richtige Aktion ausgeführt wird.
+
+Hier sieht man das AddUserEvent, das einen User anhand seiner ID und Informationen einer Gruppe, die mithilfe einer ID identifiziert wird, hinzufügt.
+
+Bevor dies geschieht, werden jedoch Validierungen ausgeführt, die prüfen, ob der User bereits Mitglied in der Gruppe ist und ob die maximale Mitgliederzahl bereits erreicht ist.
+Wenn die Validierungen ohne Fehler verlaufen, dann wird dem User die Rolle "Mitglied" gegeben.
+
+
+=== Validierung im Backend
+
+image::concept_validation.png[]
+
+Hier sieht man ein Beispiel für eine Validierung im Quellcode. Diese prüft, ob ein User Admin ist. Der User und die Gruppe werden in die Methode als Parameter übergeben.
+
+Zunächst wird eine weitere Validierung innerhalb dieser durchgeführt, um zu prüfen, ob der angegebene User Mitglied der angegeben Gruppe ist. Dann wird die Rolle der Users innerhalb der Gruppe geprüft. Falls dieser kein Admin ist, dann wird die angegebene Exception ausgegeben.
+
+
+=== Gruppe
+
+image::concept_group.png[]
+
+Hier sieht man die Klassendefinition der Gruppe.
+Die Attribute werden mithilfe von Lombok, einem Plugin, automatisch eingefügt.

documentation/src/09_design_decisions.adoc

@@ -1,4 +1,37 @@
 [[section-design-decisions]]
 == Entwurfsentscheidungen
 
+=== Festlegen auf einen Datenbanktypen
 
+Während der Entwicklung wird eine H2-Datenbank verwendet, da sie In-Memory funktioniert und automatisch und schnell startet. Die Daten werden hier nur temporär gespeichert, weshalb sie sich nur für die Entwicklung und nicht für die Produktion eignet. In der Produktion wird dann eine MySQL-Datenbank als persistenter Speicher verwendet.
+
+=== Verwendung einer Swagger-API
+
+Da eine Schnittstelle benötigt wird, damit andere MOPS-Komponenten mit unserer Software kommunizieren können, haben wir uns für eine Swagger-API entschieden. Diese nimmt Statusinformationen von den Komponenten entgegen und reagiert mit aktuellen Informationen. Wir haben uns dafür entschieden, weil diese API gut mit Spring funktioniert.
+
+=== Verwendung von Event Sourcing
+
+Dieses Vorgehen wurde uns von unserem Dozenten vorgestellt. Es bewirkt, dass nicht die Gruppen gespeichert werden, sondern die Aktionen, die auf die Gruppen ausgeführt werden. Dies ist an einem Beispiel eines Bankaccouts darstellen, in dem auch nicht der aktuelle Kontostand gespeichert wird, sondern vielmehr die Transaktionen, aus denen dann der Kontostand ausgehend von einem Startwert berechnet wird. So kann man den Stand des Kontos sowohl zum aktuellen, als auch zu jedem vergangenen Zeitpunkt bestimmen.
+
+=== Ausgabe von JSON-Files als Schnittstelle nach außen
+
+Wir haben uns für JSON-Files als Schnittstelle gewählt, weil man sie sehr gut in Java-Objekte umwandeln kann. Somit lassen sie sich von anderen MOPS-Komponenten sehr gut weiterverwenden.
+
+=== Verwenden von aussagekräftigen Exceptions
+
+Durch das Verwenden von Exceptions kann man bessere Aufzeichnung der Fehler der Software erzielen. So sieht man in den Logs genau, welcher Fehler wo aufgetreten ist. Außerdem kann man in den automatisierten Tests die Fehler schneller und genauer identifizieren.
+
+=== Differenzieren der Rechte von Studenten und Organisatoren
+
+Wir haben uns darauf geeinigt, dass Organisatoren nicht nur wie Studenten Gruppen erstellen können, sondern auch die übergeordneten Lehrveranstaltungen, mit denen eine Gruppe verknüpft werden kann.
+So ist die Kontrolle über Lehrveranstaltungen in verantwortungsvollen Händen.
+Studenten können Gruppen jeder Art erstellen.
+
+=== Beitreten in Gruppen in beide Richtungen
+
+Wir haben uns entschieden, dass man als Student Gruppen von sich aus beitreten kann, aber auch, dass man als Ersteller von Gruppen Studenten in eine Gruppe hinzufügen kann. Dies geschieht über den Upload einer CSV-Datei.
+
+=== Beitreten in private Gruppen
+
+Das Beitreten in private Gruppen funktioniert über einen Link, der nur dem Admin der privaten Gruppe sichtbar ist. Diesen Link kann er mit entsprechenden Studenten teilen, sodass nur diese die Möglichkeit erhalten, der Gruppe beizutreten.
+Private Gruppen können in der Suche auch nicht gefunden werden und sind demnach nur über den Link zu erreichen.

documentation/src/10_quality_scenarios.adoc

@@ -2,11 +2,24 @@
 == Qualitätsanforderungen
 
 
-
 === Qualitätsbaum
 
-
+image::quality_tree.png[]
 
 === Qualitätsszenarien
 
-
+[cols="1,2" options="header"]
+|===
+|Qualitätsziele |Szenario
+|1|Ein Student möchte einer Lerngruppe des Fachs Lineare Algebra 1 beitreten. Obwohl es insgesamt über 1000 Gruppen gibt, wird die Suche in angemessener Zeit durchgeführt und die passenden Ergebnisse angezeigt.
+|1|Die Leitung der Fachrichtung Informatik möchte eine Gruppe mit allen Studenten des Fachs erstellen, um regelmäßig wichtige Informationen verteilen zu können. Der Leiter der Fachrichtung kann mithilfe einer CSV-Datei, in der die über 5000 Studenten gelistet sind, die Studenten schnell und zuverlässig hinzufügen.
+|2, 3 |Die Universität verwaltet mithilfe des Moduls Gruppenbildung sehr viele verschiedene Gruppen, was zu einer hohen Belastung des Speichers der Universitätsserver führen kann, wenn die Gruppen nicht richtig verwaltet werden. Da aber die Gruppen ohne Mitglieder automatisch gelöscht werden und auch von Usern manuell gelöscht werden können, findet kein unnötiger Speicherverbrauch statt.
+|3, 4 |Ein Student, der neu an der Universität ist, gibt aus Versehen im Formular zur Gruppenerstellung fehlerhafte Daten ein und setzt weder einen Haken, der die unbegrenzte Anzahl der Mitglieder gewährleistet, noch eine maximale Mitgliederanzahl. Da aber sowohl im User Interface als auch in der Geschäftslogik Validierungen durchgeführt werden, gelangen keine fehlerhaften Objekte in die Datenbank und Fehler werden verhindert.
+|5 |Die Universität legt seit Jahren Wert auf ein modernes Auftreten und hat kürzlich sowohl das eigene Logo, als auch die Studentenausweise modernisiert. Demnach ist eine entsprechende Anforderung an moderner Optik an die Software gestellt, die die Studenten verwenden sollen. Aufgrund des einheitlichen und modernen Aussehens passt die Oberfläche des Moduls "Gruppenbildung" in das Image der Universität.
+|5, 6 |Ein neuer Mathematik-Student, der nicht viel Erfahrung mit PCs und digitalen Formularen hat, sucht eine Lerngruppe im Fach Analysis, um die gelernten Inhalte zu wiederholen. Dank der intuitiven Benutzeroberfläche findet er sich im Modul gut zurecht und kann eine Gruppe nach seinen Vorstellungen erstellen.
+|6, 7 |Ein neuer Mitarbeiter der IT-Abteilung soll in das Modul eingeführt werden und sich in Zukunft um die Wartung kümmern. Weil der Code gut auskommentiert und die Variablen sinnvoll benannt sind, findet er sich in der Software zurecht und braucht nicht lange, bis er mit der Arbeit beginnen kann.
+|7 |Der Dozent des Fachs "Programmierpraktikum" möchte anhand eines Beispiels die Arbeit Teams im 2. Praktikum und das Ergebnis, was erzielt werden kann, darstellen. Dafür zeigt er Teile des Codes und erläutert kurz die Logik, die den Studenten leicht verständlich ist.
+|7, 8 |Ein Student hat einen Bug in der Software gefunden und diesen der IT-Abteilung gemeldet. Da sich der neue Mitarbeiter der Abteilung schnell in den Code eingefunden hat, kann er den Fehler beheben, ohne viel Zeit zu investieren.
+|7, 8 |Die Leitung der Universität möchte ein neues Feature in das Modul "Gruppenbildung" einfügen, und zwar sollen die Mitglieder nicht mehr über eine CSV-Datei, sondern über ein anderes tabellarisches Datenformat eingefügt werden. Weil es nur wenige Abhängigkeiten im Code gibt, kann das  Feature problemlos eingefügt werden.
+|9 |Eine neue Komponente soll ins MOPS-Modul eingefügt werden. Es soll Gruppen annehmen und die Abgabe von Übungsblättern in diesen Gruppen verwalten. Die Schnittstelle der "Gruppenbildung" ist einfach gehalten, weshalb die Anbindung eines neuen Moduls problemlos funktioniert.
+|===

documentation/src/11_technical_risks.adoc

@@ -2,4 +2,71 @@
 == Risiken und technische Schulden
 
 
+=== Unklare Spezifikation und Umfang der Software, fehlerhafte Umsetzung
+
+Zu Beginn des Praktikums bestehen kleine Unstimmigkeiten zwischen der Information, die aus den Spezifikationen, die online zur Verfügung gestellt wurden, und denen, die uns zu Beginn von den Tutoren gegeben wurden. Zu diesem Zeitpunkt lässt sich keine klare Aussage über den Umfang der Software machen.
+In Erwartung, dass im Laufe des Praktikums nähere Informationen über Anforderungen und gewünschte Features gegeben werden, besteht das Risiko, dass wir zu Beginn einen falschen Ansatz wählen und mitten im Praktikum neu beginnen müssen oder länger brauchen als vorgegeben ist (s.u.).
+
+*Eventualfallplanung:*
+
+Falls wir einen falschen Ansatz wählen, dann bleibt uns nichts übrig, als neu zu beginnen oder so viel zu ändern, bis die Software den Anforderungen entspricht.
+
+*Risikominderung:*
+
+Um das Risiko zu mindern, sprechen wir uns mit den Tutoren ab und bitten regelmäßig um Auskunft über Anforderungen oder Wünsche. Außerdem versuchen wir, die Abhängigkeit der verschiedenen Komponenten der Software voneinander möglichst gering zu halten, um Teile bei Bedarf austauschen oder verändern zu können.
+
+
+=== Zeitliche Begrenzung des Praktikums in Relation zum Umfang der Software
+
+Da die Software bis zum 27. März fertiggestellt sein muss und Unklarheiten über den Umfang und die Anforderungen bestehen, sind wir uns nicht sicher, wie viel Zeit die Implementierung in Anspruch nehmen wird.
+
+*Eventualfallplanung:*
+
+Falls die Software nicht fertiggestellt werden kann, haben wir keine anderen Optionen als auf ein Bestehen zu hoffen oder mit den Dozenten eine Verlängerung auszuhandeln.
+
+*Risikominderung:*
+
+Um das Risiko der Zeitknappheit möglichst gering zu halten, beginnen wir mit der Implementierung der wesentlichsten Features, die sicher benötigt werden. Wir werden abwarten, bis die Tutoren oder Dozenten mit Anweisungen zu uns kommen, sondern auf sie zugehen und uns mit ihnen absprechen, um, auch solange Unklarheiten über das Endprodukt bestehen, schnell mit der Implementierung beginnen und voranschreiten zu können.
+Um während der Entwicklung schnell voranzukommen, werden wir uns immer gut absprechen, um ein effizientes Vorgehen umzusetzen.
+
+
+=== Mangelnde Vorkenntnisse
+
+Alle Mitglieder des Teams IT-Bois haben Vorkenntnisse aus den Vorlesungen zur Programmierung. Allerdings ist es möglich, dass die Software, die im Praktikum entwickelt wird, andere und höher gesteckte Anforderungen hat, als wir mit dem aktuellen Wissensstand bedienen können.
+
+*Eventualfallplanung:*
+
+Falls wir auf ein Problem stoßen, dass wir mit unseren Kenntnissen nicht lösen können, dann werden wir die Tutoren befragen können. Wenn dies auch nicht funktioniert, dann müssen wir uns auf einen anderen Lösungsweg einigen.
+
+*Risikominderung:*
+
+Da die Tutoren während des Praktikums stets zur Stelle sein werden, werden wir sie um Rat fragen können, wenn wir Probleme haben. Manche Probleme werden sich vermutlich auch mit einfachen Suchen im Internet lösen lassen. Außerdem sind wir ein Team mit vielen Mitgliedern, in dem sich hoffentlich zu den meisten Problemen eine Lösung finden lässt.
+
+
+=== Kommunikation mit anderen Gruppen, Einigung auf eine Schnittstelle
+
+Da unsere Komponente des MOPS-Moduls mit vielen verschiedenen anderen Komponenten interagieren muss, müssen wir uns mit den anderen Entwicklerteams auf eine Schnittstelle einigen. Da viele verschiedene Teams ggf. verschiedene Anforderungen haben, könnte diese Einigung ein Problem werden.
+
+*Eventualfallplanung:*
+
+Falls sich eine Unstimmigkeit bei der Wahl der Schnittstelle ergibt, dann bleibt keine Option, als so lange mit den anderen Teams zu kommunizieren, bis eine Einigung erzielt wird.
+
+*Risikominderung:*
+
+Um das Risiko von Unstimmigkeiten zu mindern, haben wir die Situation so gedreht, dass die anderen Gruppen unsere Ideen annehmen, statt dass wir ihre umsetzen, da so die Quelle der Idee nur eine ist, und nicht viele verschiedene. Die Schnittstelle, die wir entwerfen, muss dennoch für alle anderen Komponenten brauchbar und zu verwenden sein. Auch bleiben wir offen für Feedback, wenn wir etwas an der Grundidee unserer Schnittstelle ändern müssen.
+
+
+=== Aufteilung der Aufgaben auf 8 Leute
+
+Da keiner von uns bisher eine Software im Team mit über 5 Mitgliedern entwickelt hat, könnte sich die Aufteilung der Aufgaben auf 8 Personen als schwierig erweisen. Außerdem möchten wir vermeiden, dass Teammitglieder nur an einer Komponente der Software arbeiten und ihnen dann Kenntnis über andere Komponenten fehlt.
+
+*Eventualfallplanung:*
+
+Im schlimmsten Fall fehlen einzelnen Teammitgliedern Kenntnisse über einzelne Softwarekomponenten. In dem Fall muss nach dem Praktikum und vor der Klausur ein Teammeeting stattfinden, in dem wir uns über die Einzelteile der Software austauschen und so jeder ein Grundwissen über alle Komponenten entwickelt.
+
+*Risikominderung:*
+
+Damit jeder an jedem Teil der Software arbeiten kann und jeder eine Aufgabe hat, sprechen wir uns jeden Morgen ab, wer was an dem entsprechenden Tag in Angriff nehmen möchte. Außerdem wird Wert auf Programmieren in Paaren oder Kleingruppen gelegt, damit man Probleme gemeinsam lösen kann. Wenn jemand keine konkrete Aufgabe hat, dann setzt er sich zu bestehenden Teams dazu und arbeitet mit ihnen.
+
+
 

documentation/src/12_glossary.adoc

@@ -5,13 +5,20 @@
 
 [cols="1,2" options="header"]
 |===
-|Begriff
-|Definition
-
-|_<Begriff-1>_
-|_<Definition-1>_
-
-
-|_<Begriff-2_
-|_<Definition-2>_
+|Begriff |Definition
+|MOPS-Modul |MOPS steht für die "Modulare OrganisationsPlattform für Studenten", die ein neues Werkzeug für Studenten darstellt, mit dem ihnen verschiedenste Dienste zur Verfügung gestellt werden. MOPS ist die übergeordnete Anwendung, von der die "Gruppenbildung" ein Teil ist.
+|arc42 |arc42 ist ein Muster zum Erstellen einer guten Entwicklungsdokumentation während eines -prozesses.
+|Java 11 |Java 11 ist die 11. Version der Programmiersprache Java.
+|Framework |Ein Framework ist eine Ansammlung von Diensten, die zur Unterstützung der Entwickler dient. Durch das Verwenden eines Framworks können verschiedene Prozesse automatisiert werden, die sonst manuell durchgeführt oder implementiert werden müssten.
+|JUnit |JUnit ist ein auf Java basiertes Framework zum Schreiben von automatisierten Softwaretests.
+|Spring Framework |Spring ist ein Framework, das viele Dienste zum Aufbauen einer Software zur Verfügung stellt, wie z.B. die Automatisierung verschiedener Funktionen, die sonst per Hand implementiert werden müssten.
+|GitHub |Werkzeug zur Arbeit an Software von verschiedenen PCs aus und zur Versionskontrolle.
+|Branches und Master-Branch |Auf GitHub werden die Änderungen im Code online gespeichert. Wenn man Änderungen machen möchte, die aber nicht direkt in der endgültigen Software landen sollen, dann kann man sog. Branches erstellen, die den bestehenden Code kopieren, aber unabhängig davon bearbeitet werden. Der Haupt-Branch heißt der Master. Auf diesem liegt die endgültige Software.
+|Checkstyle und Spotbugs |Werkzeuge zum automatisierten Finden von Fehlern in Quellcode. Spotbugs findet Fehler in der Funktionalität und Checkstyle prüft die Schreibweise des Codes.
+|Continuous Integration/CI |Lässt Tests laufen, bevor Änderungen an der Software endgültig gespeichert werden können. So kann eine funktionierende Software zu jedem Zeitpunkt garantiert werden.
+|Log |Aufzeichnung der Meldungen während der Laufzeit einer Software. Darin kann man mögliche Fehler- oder Erfolgsmeldungen auslesen und so bessere Auskunft über die unsichtbaren Vorgänge innerhalb der Software erlangen.
+|Keycload |Externes Plugin, das die Authentifizierung und damit den Zugang zur Anwendung ermöglicht.
+|DTO |Data Transfer Object. Dies ist eine Vereinfachung einer Java-Instanz, die leichter innerhalb der Datenbank verwaltet werden kann.
+|Interface |Sammlung von Java-Methoden, die von Klassen implementiert werden können.
+|Queries |Zeichenketten, die in der Sprache einer Datenbank geschrieben sind und so die Kommunikation mit ihr ermöglichen.
 |===