diff --git a/Protokolle/Präsentationen/11.11.2024.md b/Protokolle/Präsentationen/11.11.2024.md new file mode 100644 index 0000000..a5643c6 --- /dev/null +++ b/Protokolle/Präsentationen/11.11.2024.md @@ -0,0 +1,74 @@ +**Uhrzeit:** 15:00 - 16:00 + +**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 +* Behebung verschiedener Fehler in den Diagrammen + +**2. Was hat uns an der Arbeit gehindet?** + +* Versionierungsfehler bei den Flussdiagrammen +* Import von Server/Client Struktur von Battleship bereitete Probleme + +**3. Was werden wir nächste Woche machen?** + +* Beginn der Bearbeitung der Implementierungsphase + * Aufgaben verteilen und bearbeiten (Gruppentreffen 12.11.2024) + +
+ +### **Fragen, Empfehlungen und Anmerkungen durch den Betreuer für die einzelnen Artefakte** + +**1. Klassendiagramme (Schmelz)** + +* Sehr viel Leerraum zwischen den einzelnen Klassen im Diagramm, welche ggf. noch gefüllt werden können +* Für Präsentation übersichtlicher und kompakter gestalten + +**2. Flussdiagramme (Wilkening, Schmidt)** + +* keine besonderen Anmerkungen zu "Spielzug_V2.1" und "Spielende_V2.1" + +* 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 + +**3. Sequenzdiagramme (Malkmus)** + +* Deutliche Verbesserung der Syntax und der Qualität der Sequenzdiagramme + +**Aber** + +* Es muss auf den Abstraktionsgrad geachtet werden, diese sollten nicht durcheinandergebracht werden +* Man sollte Interaktionen von GUI Objekten/Client/Server auf der einen Seite und Klassenobjekten auf der anderen Seite zur besseren Übersichtlichkeit trennen. + * Beispiel Grundstück kaufen: Start bei Figur auf Feld (Startaktion), kaufen Button (Nutzerinteraktion). Es muss klar sein, dass Aktion 2 und 4/5 auf verschiedenen Ebenen sind. Weitere Iteration jetzt in Designphase nicht notwendig. + +**4. Testhandbuch (Szepielewicz)** + +* Derzeit verhältnismäßig viele händische Tests + * Beachtung der Notwendigkeit, diese Nach jedem Commit auch händisch zu testen, was sehr zeitaufwendig sein kann + * Händische Tests sollten daher soweit wie es geht reduziert werden +* Soundlogik sollte vom tatsächlichen Abspielen der Sound entkoppelt werden. Dadurch kann man Soundtests vom händischen Tests lösen + +
+ +### **Allgemeines Feedback durch den Betreuer** + +* Die Implementierungsphase darf begonnen werden +* Es gibt in Implementierungsphase die Möglichkeit, von Ideen der Designphase abzuweichen. Dies kann man in Texten erläutern +* Empfehlung Zielsetzung: + * Es ist riskant zu planen, dass man nach 3 Wochen erst ein spielbares Spiel hat Woche 1: Minimum viable Product: Spiel, wo man Ablauf im großen und Ganzen durchlaufen kann. Natürlich gibt es noch nicht alle Aktionen; aber die gröbsten Aktionen + * Woche 2: ALLE Use Cases der höchsten Priorität. + * Woche 3: Bug Fixes und Polishing + * Was im Main Branch liegt, sollte kompilierbar sein. Probleme und Spielabstürze intern kommunizieren. \ No newline at end of file diff --git a/Protokolle/Präsentationen/28.10.2024.md b/Protokolle/Präsentationen/28.10.2024.md index cbc3dfb..a5a1cfa 100644 --- a/Protokolle/Präsentationen/28.10.2024.md +++ b/Protokolle/Präsentationen/28.10.2024.md @@ -8,8 +8,6 @@ ### **Fragen der Gruppe:** -
- ### **Präsentation:** **1. Was haben wir letzte Woche gemacht?** @@ -29,35 +27,28 @@ * 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. +* 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 +* Unterschied zwischen 6 und 7? + * Hier sollte der genaue Ablauf von Serverstart, Einloggen der Spieler und Einstellungen des Spiels eingeügt werden * UC-game-11: Empfehlung auf dynamische, redundante Server zu verzichten, da dieser sehr aufwendig in der Implementierung ist * Das Spiel wird bei jeglicher Störung für alle Spieler beendet Grundsätzliches: -* Sinn von Use-Case: Wir listen auf, was man alles so machen will. Dienen dazu „fachliche Aktionen“ dazustellen. NICHT, mehrmals UIs - dazustellen. +* 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. + * 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)** @@ -79,27 +70,23 @@ Grundsätzliches: * 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 +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 -Korrektur der Zustandadiagramme -Korrektur der Klassendiagramme - -**5. Benutzerhandbuch (Wilkening)** +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 +* Das Klassendiagramm wurde für die Analysephase etwas vereinfacht, kann aber in der Designphase weiterverwendet werden \ No newline at end of file