Add protocol from 2023-11-03

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.