diff --git a/src/main/asciidoc/protocols/2023-11-03.adoc b/src/main/asciidoc/protocols/2023-11-03.adoc new file mode 100644 index 0000000..96fd485 --- /dev/null +++ b/src/main/asciidoc/protocols/2023-11-03.adoc @@ -0,0 +1,145 @@ +// vim: set spell spelllang=de: += Protokoll Gruppe 23 + +Treffen am 2023-11-03 + +Ort: APB/E010 + +Beginn: 14:50 Uhr + +Ende: 16:36 Uhr + +__Schriftführer:__ Simon Bruder + +*Nächstes Treffen:* + +2023-11-10, 14:50 Uhr, APB (Treffpunkt: Foyer) + +__Teilnehmer:__ + +[%header] +|=== +|Name|Rolle|Bemerkung +|Denis Natusch|| +|Eren Asker||BBB +|Erik Hohlfeld|| +|Jacob Benjamin Fasshauer|Kunde, Tutor| +|Mathis Kral|Scrum Master| +|Paul Heimer|| +|Simon Bruder|Schriftführer| +|Theo Reichert|| +|=== + +== Bemerkungen + +Die im letzten Treffen angekündigte Erklärung des Codes vom Videoshop entfällt, +da dies aus Zeitgründen nicht sinnvoll wäre, +sowie Vertrauen aufseiten des Tutors besteht. + +Auf eine Frage hin wird erläutert, +dass unter Pair Programming sowohl die Aufteilung der Aufgabe (z.B. in Implementation und Test) +als auch die Gleichzeitige (driver/observer) Arbeit an der gleichen Aufgabe verstanden werden kann. +Wichtig sei in jedem Fall, +dass vor allem bei der ersten Interpretation, +jede Person jeden Aufgabentyp in der Bilanz in gleichen Teilen übernimmt. + +Es werden Fragen zum geplanten Ablaufes dieses Sprints gestellt. +Zunächst sollte der Grobentwurf bzw. die Entwicklungsdokumentation stattfinden, +der die Basis für die Gestaltung des Prototyps bildet. +Die Entwicklungsdokumentation muss vollständig sein, +da sie die Grundlage von Aufgaben für diesen und die nächsten Sprints ist. +Jedoch ist dies nur die erste Version. +Die Dokumentation wird im Laufe des Projektes dauernd überarbeitet werden. +Eine Überschneidung der benutzen Frontend-Ressourcen in verschiedenen Controllern (insbesondere Packages) ist normal und zu erwarten. +Die Arbeitseinteilung muss jedoch nicht exakt an den Grenzen der Packages verlaufen, +jedoch sollte am Ende des Sprints dem Tutor mitgeteilt werden, +wer an welchem Teil gearbeitet hat. +Der Prototyp ist vor allem für die Zwischenpräsentation relevant. +Es sollen Fake-Daten angezeigt werden, +eine Interaktivität (Hinzufügen, Löschen, Bearbeiten) soll, +sofern geplant, +innerhalb einer Komponente möglich sein. +Die Interfaces für die Anbindung der anderen Komponenten, +sowie Controller für die eigene Komponente +müssen vorhanden sein. + +Weiter wird das Problem geschildert, +dass die Architektur von SalesPoint es nicht leicht macht, +mehrere individuell konfigurierte Aufträge in den Warenkorb zu legen, +da für jedes Produkt im Warenkorb ein Eintrag im Catalog/Inventory existieren muss. +Daher wird sich darauf geeinigt, +dass auch nur ein Auftrag pro Warenkorb akzeptabel ist. +Damit ist die zuvor gegebene Antwort auf diese Frage (als das Problem noch nicht bekannt war) hinfällig. + +Mit „Persistenz“, +was auf den Folien zum Ablauf des Projektes zur Beschreibung der Aufgabe dieses Sprints verwendet wird, +ist nur gemeint, dass die Daten während der Laufzeit gespeichert werden. +Eine Speicherung über die Laufzeit hinaus ist nicht notwendig. + +Es wird weiterhin darauf hingewiesen, +dass die Entwicklungsdokumentation und die in ihr verwendeten Diagramme in der gleichen Sprache verfasst sein müssen. +Die Gruppe einigt sich hierbei auf Englisch. + +Darüber hinaus werden in den Diagrammen nur Konstrukte erwartet, +die in SWT1 behandelt wurden. + +=== Erklärungen zur Zwischenpräsentation + +Die Zwischenpräsentation stellt eine Simulation von bzw. eine Vorbereitung für die Abschlusspräsentation dar. +Nach dieser erhält die Gruppe vom Tutor Feedback. +Die Präsentation besteht aus zwei Teilen, +die beide je 10 Minuten umfassen sollen. + +Im ersten sollen die Ergebnisse und das Vorgehen der Analyse- und Entwurfsphase vorgetragen werden. +Hierbei ist besonders darauf zu achten, +dass die gezeigten Diagramme keine „UML-Tapeten“ sind, +sondern nur die wichtigsten Teile darstellen. +Es genügt also, +Teile der Diagramme aus dem Pfichtenheft und der Entwicklungsdokumentation zu verwenden. + +Der zweite Teil besteht aus der interaktiven Präsentation des Prototyps, +wobei die Anwendungsszenarien vorgestellt werden. +Hierbei wird empfohlen, +die verwendeten Daten (bspw. für Formulare) bereits vorher zurechtzulegen, +sodass man diese nicht während der Präsentation (möglicherweise fehleranfällig) manuell eingeben muss. +Die Komponenten für Login, Logout und Registrierung müssen nicht vorgestellt werden. + +Es wird die Frage gestellt, +ob sich die Gruppe wünscht, +dass zur Präsentation ein weiterer Tutor eingeladen wird. +Die Gruppe einigt sich darauf, +dass dies für sie nicht unbedingt sein muss. + +Der Termin für die Präsentation wird voraussichtlich mit der anderen Gruppe des Tutors geteilt werden. +Die genaue Festlegung findet nach einer Umfrage statt, +die von den Teilnehmern auszufüllen ist und noch zur Verfügung gestellt werden wird. +Vorab ist jedoch bekannt, +dass der Termin in der KW 46 oder 47 liegen wird. + +=== Bewertung + +Weiter werden einige allgemeine Informationen zur Bewertung des Projektes vom Tutor gegeben. + +Aufgrund einer Bewertungsmatrix erstellt der Tutor einen Vorschlag, +welcher von anderen Personen bestätigt werden muss. +Hierbei bekommt jeder Meilenstein eine einzelne Note. +Ob eine individuelle Benotung erfolgt, +konnte noch nicht gesagt werden. + +== Retrospektive des letzten Sprints + +Es wurde bereits am Montag durch den Tutor im Chat angemerkt, +dass in den Anwendungsfällen des Pflichtenheftes noch das Bearbeiten und Löschen von Aufträgen durch den Administrator fehlt. +Während des Treffens wird sich darauf geeinigt, +dass eine Stornierungsfunktion einer Löschfunktion vorzuziehen ist. + +Diese Anmerkungen wurden teilweise schon auf dem feature branch umgesetzt. + +Diese sollen noch bis Sonntag auf den `main`-Branch gemerged werden. + +== Aktueller Stand + +Ein Prototyp wird kurz vorgestellt. + +Der aktuelle Stand des Grobentwurfes wird vorgestellt. + +== Planung des nächsten Sprints + +Zu diesem Abschnitt werden keine besonderen Anmerkungen gemacht.