diff --git a/Protokolle/Gruppentreffen.md b/Protokolle/Gruppentreffen.md index 5329be6..ab1842e 100644 --- a/Protokolle/Gruppentreffen.md +++ b/Protokolle/Gruppentreffen.md @@ -30,6 +30,7 @@ Hier eine Protokollvorlage für die Gruppentreffen: Designphase
+* [29.10.2024](./Gruppentreffen/29.10.2024_Präsenz) diff --git a/Protokolle/Gruppentreffen/29.10.2024_Präsenz.md b/Protokolle/Gruppentreffen/29.10.2024_Präsenz.md new file mode 100644 index 0000000..6c94de2 --- /dev/null +++ b/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 + +
+ +### **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 diff --git a/Protokolle/Präsentationen.md b/Protokolle/Präsentationen.md index beb3465..fd69d85 100644 --- a/Protokolle/Präsentationen.md +++ b/Protokolle/Präsentationen.md @@ -16,7 +16,7 @@ Hier eine Protokollvorlage für die Gruppentreffen:
* [21.10.2024](./Präsentationen/21.10.2024) - +* [28.10.2024](./Präsentationen/28.10.2024)
diff --git a/Protokolle/Präsentationen/28.10.2024.md b/Protokolle/Präsentationen/28.10.2024.md new file mode 100644 index 0000000..0d93bbb --- /dev/null +++ b/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 + +
+ +### **Fragen der Gruppe:** + +
+ +### **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) + +
+ +### **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 + +
+ +### **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 + \ No newline at end of file