swt23w23/src/main/asciidoc/protocols/2023-11-03.adoc

// vim: set spell spelllang=de:
// SPDX-License-Identifier: Apache-2.0 AND AGPL-3.0-or-later
// SPDX-FileCopyrightText: 2015 Sven Seemann
// SPDX-FileCopyrightText: 2015 Oliver Drotbohm
// SPDX-FileCopyrightText: 2017 Jan Falkenberg
// SPDX-FileCopyrightText: 2017 Marc Kandler
// SPDX-FileCopyrightText: 2023 swt23w23
= 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.