Protokolle für den 28.10 und 29.10 eingefügt

Protokolle/Gruppentreffen.md

@@ -30,6 +30,7 @@ Hier eine Protokollvorlage für die Gruppentreffen:
 <summary>Designphase</summary>
 <br>
 
+* [29.10.2024](./Gruppentreffen/29.10.2024_Präsenz)
 
 </details>
 

Protokolle/Gruppentreffen/29.10.2024_Präsenz.md

@@ -0,0 +1,52 @@
+**Uhrzeit:** 12:20 - 12:47
+
+**Teilnehmer:** Gruppe, vollzählig
+
+**Es fehlt:**
+
+**Ort:** Gemeinschaftsraum Gebäude 20/100 EG
+
+<br>
+
+### **Themen:**
+
+**1. Nachbesprechung des Betreuertermins vom 14.10.2024**
+
+* Die Use-Cases und das Testhandbuch werden bis Mittwoch aufeinander abgestimmt, damit diese bis Donnerstag nachgereicht werden können
+* Die kleineren Fehler in den Diagrammen werden korrigiert, sodass diese ebenfalls in der E-Mail am Mitwoch/Donnerstag erwähnt werden können
+
+**2. Aufgabenverteilung für die Nachbereitung der Analysephase**
+
+* Korrektur angesprochenen Use-Cases (Müller, Szepielewicz)
+* Abgleich und Korrektur der IDs der Use-Cases mit der Use-Case-List und dem Testhandbuch (Müller, Szepielewicz)
+* "Vereinfachung" des Klassendiagramms für die Analysephase (Puderbach)
+* Korrektur der Zustandsdiagramme "PlayerState" und "GameState" (Schmelz)
+* Schreiben der Mail mit Verweis auf die korrigierten Use-Cases etc. (Wilkening)
+
+* Abschluss dieser Arbeiten bis spätestens Mittwochabend
+
+**3. Aufgabenverteilung für die Designphase**
+
+* Aktualisierung und Verfeinerung des Testhandbuches (Szepielewicz)
+* Erstellung BPMN-Diagramme (Müller, Schmelz)
+* Erstellung der Klassen- und Paketdiagramme (Puderbach, Schmelz)
+* Erstellung der Sequenzdiagramme (Malkmus, Schmelz)
+* Erstellung der Flussdiagramme (Schmidt)
+* Aktualisierung des Wikis und Erstellung der Ordnerstruktur der Designphase (Wilkening)
+* Aktualisierung der Gestaltungsrichtlinien (Malkmus)
+
+* Jeder achtet auf die korrekte Benennung und Versionierung seiner erstellten Dateien
+
+**Sonstiges**
+
+* Um Termine nicht jede Woche neu festlegen zu müssen, werden für die Gruppentreffen pro Woche mindestens folgende Termine festgelegt:
+  * Montag 1500 (Präsentation mit Fietkau)
+    * Präsentation der wöchentlichen Ergebnisse
+  * Montag nach der Präsentation, sofern zeitlich möglich (Gruppentreffen per Discord), sonst Dienstag beim Kundentermin
+    * Nachbesprechung der Präsentation ggf. mit Aufgabenverteilung
+  * Dienstag 1200 Gemeinschaftsraum Gebäude 20/100 EG (Kundentermin)
+    * Fragen mit dem Kunden/Tutor besprechen, ggf. Aufgabenverteilung und Nachbesprechung
+  * Donnerstag 2200 (Gruppentreffen per Discord)
+    * Gegenseitige Überprüfung und Koordinierung
+  * Sonntag 1600 (Gruppentreffen per Discord)
+    * Vorbereitung der Präsentation und der wöchentlichen Ergebnisse

Protokolle/Präsentationen.md

@@ -16,7 +16,7 @@ Hier eine Protokollvorlage für die Gruppentreffen:
 <br>
 
 * [21.10.2024](./Präsentationen/21.10.2024)
-
+* [28.10.2024](./Präsentationen/28.10.2024)
 </details>
 
 <details>

Protokolle/Präsentationen/28.10.2024.md

@@ -0,0 +1,104 @@
+**Uhrzeit:** 15:00 - 16:31
+
+**Teilnehmer:** Gruppe, vollzählig; Hambrügge, Fietkau
+
+**Ort:** Online über BigBlueButton
+
+<br>
+
+### **Fragen der Gruppe:**
+
+<br>
+
+### **Präsentation:**
+
+**1. Was haben wir letzte Woche gemacht?**
+
+* Bearbeitung der Artefakte nach vorher besprochener Aufgabenverteilung
+
+**2. Was hat uns an der Arbeit gehindet?**
+
+* Koordinierung mit den Use-Cases und weiteren Dokumenten
+* Z.T. wurden unterschiedliche Versionen der gleichen Dokumente gleichzeitig verwendet
+
+**3. Was werden wir nächste Woche machen?**
+
+* Use-Cases überarbeiten (siehe Feedback Use-Cases)
+* Korrektur des Klassendiagramm für die Analysephase (siehe Feedback Klassendiagramm)
+* Korrektur des Zustandsdiagramm (siehe Feedback Zustandsdiagramm)
+* Beginn der Bearbeitung der Designphase
+  * Aufgaben verteilen und bearbeiten (Gruppentreffen 29.10.2024)
+
+<br>
+
+### **Fragen, Empfehlungen und Anmerkungen durch den Betreuer für die einzelnen Artefakte**
+
+**1. Rückmeldung Use-Cases (Müller)**
+
+Konkretes:
+
+* Serverbeitritt wurde als einen Use Case abgebildet. Nun sind diese in zwei einzelne Fälle
+  gesplittet.
+  * Feedback: nicht Zielführend, die Anmeldung in 2 Cases zu splitten.
+* Unterschied zwischen 6 und 7? 
+  * Hier sollte der genaue Ablauf von Serverstart, Einloggen der Spieler und Einstellungen des
+    Spiels eingeügt werden
+* Game-11: Empfehlung den Timer wegzulassen, da dieser sehr aufwendig ist
+
+Grundsätzliches:
+
+* Sinn von Use-Case: Wir listen auf, was man alles so machen will. Dienen dazu „fachliche Aktionen“ dazustellen. NICHT, mehrmals UIs
+  dazustellen.
+* Testhandbuch, Use-Cases und Use-Case-Beschreibung müssen einheitlich sein.
+  * Wir reichen die Use-Cases bis Donnerstag nach
+    * Mag den Abstraktionsgrad der Gameplay Use Cases
+    * Handelsmenü und Karten vernünftig abgebildet
+    * Sound im im Wesentlichen gut
+    * Feedback: Unglücklich, dass Use Case Liste und Beschreibungen nicht
+    übereinstimmen. Testhandbuch, Use Cases und Use Case Beschreibung
+    müssen einheitlich sein.
+
+**2. Rückmeldung Testhandbuch (Schmidt)**
+
+* Testhandbuch muss mit den Use-Cases übereinstimmen
+* Bei den Tests sollten zusätzlich beachtet werden ...
+  * manuelle (händische) Tests, die keine Implementierung erfordern, aber nicht automatisiert getestet werden können
+  * "Normalen J-Unit-Tests", die Implementiert werden müssen, aber dafür automatisiert ausgeführt werden können
+
+**3. Klassendiagramme (Puderbach)**
+
+* Diagramm ist zu detailliert und zu nah an der tatsächlichen Implementierung für die Analysephase
+  * Klassendiagramme sollten bisher nur die notwendigsten Attribute enthalten
+  * Es der Fokus hätte auf den existierenden Objekten als solche liegen müssen und wie diese miteinander Interagieren, weniger auf die Attribute der einzelnen Objekte
+
+**4. Zustandsdiagramm (Schmelz)**
+
+* Feedback Spielerstate
+  * Pfeil aus Gefängnis raus fehlt
+  * Start soll schwarzer Kreis sein. Schwarz/weiß ist ENDzustand
+  * Ansonsten keine inhaltlichen Probleme.
+
+*Feedback PlayerState
+  * Man kann sehr gut Grenzen eines Zustandsdiagramm sehen, da dieses unübersichtlich wirkt
+    * In solchen Fällen ist ein hierarchisches Zustandsdiagramm empfehlenswert
+  * Settings Screen immer aufrufbar. 
+    * Wenn man von irgendwo auf Setting geht und wieder rausgeht, ist nicht offensichtlich, welches Menü gerade aktiv ist
+
+Korrektur der Zustandadiagramme
+Korrektur der Klassendiagramme
+
+**5. Benutzerhandbuch (Wilkening)**
+
+* Zustandsdiagramme als Platzhalter möglich
+* Handbuch sollte am Ende der Implementierungsphase Screenshots aus dem tatsächlichen Spiel enthalten
+
+<br>
+
+### **Allgemeines Feedback durch den Betreuer**
+
+* Die Designphase darf begonnen werden
+* Die Use-Cases und das Testhandbuch müssen in eine kohärente Form gebracht werden (Abgabe am Donnerstag)
+  * keine Abweichungen in den IDs
+* Die Diagramme werden ebenfalls korrigiert
+  * Das Klassendiagramm wurde für die Analysephase etwas vereinfacht, kann aber in der Designphase weiterverwendet werden
+