swt23w23/src/main/asciidoc/protocols/2023-10-20.adoc
Simon Bruder bac025fd0a
Make project REUSE compliant
This finally makes the licensing under AGPL-3.0-or-later explicit after
I got the okay from the kickstart source owners.

This also checks the REUSE compliance in a pre commit hook, and
therefore also in CI.
2023-12-11 17:59:14 +01:00

167 lines
6 KiB
Plaintext

// 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-10-20
Ort: APB Gang 2. Stock +
Beginn: 15:00 Uhr +
Ende: 16:20 Uhr
__Schriftführer:__ Simon Bruder
*Nächstes Treffen:* +
2023-10-27, 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||
|===
__Fehlt:__
- Yucheng Yang
== Bemerkungen
Es wird darauf hingewiesen,
dass die späteste Frist zur Abgabe des Pflichtenheftes und der Videoshop-Erweiterung
am Ende des Sonntags (2023-10-29) ist.
Unter Abgabe wird das Bestehen eines Branches im Git-Repository mit den zu berücksichtigenden Commits verstanden.
=== Fragen und Anmerkungen zum Pflichtenheft
Zum Pflichtenheft merkt der Tutor auf eine Frage an,
dass die Modelle, Diagramme und Beschreibungen noch nicht exakt das abbilden müssen,
was implementiert wird,
auch da zur Implementierung ohnehin in Details von diesen abgewichen wird.
Es reicht also bei einigen Bereichen,
nur ein grobes, vereinfachtes Diagramm im Pflichtenheft zu hinterlegen.
Das zugrunde liegende Modell der Diagramme,
in unserem Fall der PlantUML-Quelltext,
soll mit im Repository abgegeben werden.
Aller Teile des Pflichtenheftes sollen in deutscher Sprache verfasst sein.
=== Fragen und Anmerkungen zur Aufgabenstellung
Weiter werden einige Fragen zur Aufgabenstellung gestellt,
welche vom Kunden beantwortet und teilweise von Ergänzungen begleitet werden.
Es wird explizit darauf hingewiesen,
dass die primäre Zielgruppe der Software künftige Kunden des Cateringservices sind.
Diese können
sich registrieren,
Buchungen in einen Warenkorb legen,
die Buchungen im Warenkorb absenden
und bei Bedarf ihr Konto löschen.
Mitarbeitende hingegen benötigen keinen gesonderten Zugriff.
Der Administrator (in der Regel Hannes Wurst) bildet hiervon eine Ausnahme.
Er hat die höchsten Rechte in der Software,
was ihm zum Beispiel erlaubt,
Benutzerkonten zu löschen.
Hierfür stehen ihm spezielle Übersichtsseiten zur Verfügung,
welche nur für ihn sichtbar sind.
Die Passwörter der Konten sollen nach aktuellem Standard gesichert abgespeichert werden.
Als Zahlungsart steht ausschließlich die Zahlung mittels Bargeld zur Verfügung.
Die Software soll nach Eingang einer Bestellung vollautomatisch
die notwendigen Ressourcen (Material, Personen etc.) zuteilen.
Vom Kunden wird besonders die Funktion hervorgehoben,
dass es im Geschäftsfeld Partyservice Sonderaktionen geben muss,
welche einen niedrigeren Preis als den regulären besitzen
und visuell für Interessierte besonders gekennzeichnet sind.
Für Mobile Breakfast soll die Bestellung monatsweise zu festen Zeitslots erfolgen,
wobei bei der Buchung mehrere Menüs zur Auswahl stehen sollen.
Das Angebot wird für einen festen Zeitraum gebucht und verlängert sich nicht.
Als Rechnung versteht der Kunde
eine informelle Auflistung
der Positionen der Bestellung (mit Anzahl, Einzelpreis und Gesamtpreis),
sowie einer Gesamtsumme
als Internetseite und PDF.
Die Rechnungen werden in allen Geschäftsfeldern an die Entität gestellt,
die den Auftrag erteilt.
Mit der Erleichterung der Abrechnung wünscht sich der Kunde
eine dem Administrator zur Verfügung stehende, informelle Aufstellung darüber,
wie viel eine bestimmte Person gearbeitet hat.
Hierbei soll ausschließlich die Zeit berücksichtigt werden,
die die Mitarbeitenden tatsächlich gearbeitet haben,
also einem Auftrag zugeteilt waren.
Auf Sicherheitsfunktionen legt der Kunde keinen besonderen Wert,
jedoch soll SQL-Injection im Allgemeinen nicht möglich sein,
bspw. durch Prepared Statements oder Verwendung eines ORM.
== Retrospektive des letzten Sprints
Die Teilnehmer haben sich nach dem letzten Treffen auf eine Aufteilung der Bereiche des Pflichtenheftes geeinigt:
[%header]
|===
|Bereich|Verantwortlicher
|Akzeptanztestfaelle|Eren
|Anwendungsfälle|Denis
|Aufgabenstellung, Zusammenfassung|Yucheng
|Datenmodell, Interessensgruppen|Simon
|Funktionale Anforderungen|Theo
|GUI-Prototyp|Erik
|Nicht-funktionale Anforderungen|Mathis
|Produktnutzung|Paul
|===
Durch Verhinderung Seitens Yuchengs hat Mathis dessen Aufgaben übernommen.
Die Teilnehmer haben sich des Weiteren seit dem letzten Treffen
auf ein UML-Tool (PlantUML) geeinigt,
ihre ersten Ergebnisse untereinander besprochen
und diese zu einem Entwurf zusammengefügt.
== Aktueller Stand
Die Teilnehmer berichten über ihren aktuellen Stand bei der Erweiterung des Videoshops.
Alle haben sich bereits mit den verwendeten Frameworks genauer beschäftigt
und die Mehrheit auch schon mit der Implementation begonnen.
Zwei Teilnehmer haben die Erweiterung bereits abgeschlossen.
Ein Entwurf des Pflichtenheftes ist im Branch `scope-statement` im Repository der Gruppe zu finden.
Der Tutor stellt fest, dass dieser in die richtige Richtung geht.
Eventuell könnten die vier Geschäftsfelder des Cateringservices explizit in der Zusammenfassung erwähnt werden.
== Planung des nächsten Sprints
Die Teilnehmer planen,
zunächst gemeinsam ein Glossar zu erarbeiten,
um bis zum Ende der Woche jeweils den eigenen Bereich des Pflichtenheftes in Bezug darauf zu überarbeiten.
Um dabei technische Konflikte zu vermeiden wurde festgelegt,
dass Änderungen, welche den eigenen Bereich betreffen,
selbstständig auf den `scope-statement`-Branch hinzugefügt werden können,
wobei auf ein rasches `pull`, `commit` und `push` geachtet werden soll.
Sollten Änderungen auch einen anderen Bereich betreffen,
muss hierfür mit dem dafür Verantwortlichen und/oder mit dem Scrum Master Kontakt aufgenommen werden.
Soweit das Videoshop-Projekt noch nicht abgeschlossen ist,
planen die betroffenen Teilnehmer,
dies zeitnah fertigzustellen.