Update presentation content and formatting for clarity and consistency

dokumentation/projekt/Praesentation.md

@@ -70,21 +70,22 @@ style: |
 
 ## Agenda
 
-1. **Team & Aufgabenverteilung**
-2. **Kontext & Ziel** des Projekts
-3. **Architektur** im Überblick
-4. **Live-Demo** des Programms  *(≈ 10 Min)*
-5. **Entwicklungsprojekt** *(≈ 5 Min)*
+1. **Einleitung** — Team, Kontext & Ziel, Architektur
+2. **Das Programm**
+   - Gruppe C — Kundenverwaltung
+   - Gruppe B — Produktverwaltung
+   - Gruppe A — Dokumentenzyklus
+   - Gruppe D — Programmoberfläche
+3. **Das Entwicklungsprojekt**
    - Ergebnisse der Modultestpläne
    - Wo wurde KI eingesetzt – und wie gut?
    - Was würden wir nächstes Mal anders machen?
-6. **Fragen** *(5 Min)*
 
 ---
 
 ## Team & Aufgabenverteilung
 
-12 Personen, vier fachliche Komponenten (V-Modell, Einzelplatzanwendung):
+12 Personen, vier fachliche Komponenten:
 
 | Gruppe | Komponente | Leitung | Mitglieder |
 |---|---|---|---|
@@ -122,61 +123,73 @@ Querschnitt (`gemeinsam`): EreignisBus, JSON-Persistenz, CSV-Hilfe – von allen
 - **EreignisBus** (Observer): Services melden Datenänderungen, GUI-Panels aktualisieren sich selbst
 - **Snapshot-Prinzip** in Belegen + **Löschsperren** (referenzielle Integrität)
 
-**Technologie-Stack**
-
-`Java 21` · `Swing + FlatLaf 3.6` · `Maven` (Fat-JAR via shade) · `Jackson 2.17` (JSON) · `Apache PDFBox 3.0` (PDF) · `JUnit 5.10`
-
 ---
 
 <!-- _class: divider -->
 <!-- _paginate: false -->
 
-# Live-Demo
-### Das entwickelte Programm
+# Das Programm
+### Vier Komponenten
 
 ---
 
-## Demo 1 — Stammdaten
+## Gruppe C — Kundenverwaltung
 
-**Kundenverwaltung (Gruppe C)**
-- Anlegen mit eindeutiger Kundennummer (`K-000017`), Pflichtfeld-Validierung *(BA-01)*
-- Suchen & sortierte Liste, Ändern *(BA-02, BA-04)*
-- **Löschsperre**: Kunde mit verknüpften Dokumenten wird nicht gelöscht *(BA-03, GR-04)*
+### Ziel *(Lasten-/Pflichtenheft)*
+Kundenstammdaten anlegen, ändern, suchen, löschen *(BA-01–04)* · eindeutige Kundennummer · **keine Löschung bei verknüpften Dokumenten** *(GR-04)*
 
-**Produktverwaltung (Gruppe B)**
-- Anlegen mit Nettopreis & zulässigem Steuersatz, Nummernvergabe `P-000042` *(BA-05)*
-- Ändern, Suche, **Löschsperre** bei referenzierten Produkten *(BA-06–BA-08)*
+### Technische Umsetzung
+- **Referenzielle Integrität** ohne Datenbank: Löschsperre über eine Referenzprüfung
+- Automatische Nummernvergabe & Pflichtfeld-/E-Mail-Validierung
+  <small>`KundenRepository` · `EinfacherKundennummernGenerator` · `KundenReferenzPruefung`</small>
+
+### Live-Demo
+Kunde anlegen → `K-000017` · suchen / sortieren · ändern · **Löschsperre** bei verknüpftem Kunden (Hinweis mit Anzahl)
 
 ---
 
-## Demo 2 — Dokumentenzyklus (Gruppe A)
+## Gruppe B — Produktverwaltung
 
-**Angebot → Auftragsbestätigung → Lieferschein → Rechnung**
+### Ziel *(Lasten-/Pflichtenheft)*
+Produkte anlegen, ändern, suchen, löschen *(BA-05–08)* · Nettopreis + Steuersatz · **nur gültige Eingaben**, Löschsperre
 
-- Folgebeleg übernimmt Kunde, Positionen & Mengen und speichert eine **Rückreferenz** *(GR-05)*
-- **Lückenlose** Belegnummern `R-2026-000124` (GoBD) *(GR-01)*
-- Automatische **Steuerberechnung** netto / Steuer / brutto, Scale 2 *(GR-03)*
-- Standard-**Zahlungsziel** +14 Tage, falls nicht angegeben *(GR-06)*
-- Rechnung mit allen Pflichtangaben gem. **§ 14 UStG** *(BA-12)*
+### Technische Umsetzung
+- **Validierung** lehnt negative Preise & unzulässige Steuersätze ab; Produktnummer unveränderlich
+- Gleiches Repository-/Generator-Muster wie Gruppe C
+  <small>`ProduktRepository` · `EinfacherProduktnummernGenerator` · `ProduktReferenzPruefung`</small>
+
+### Live-Demo
+Produkt anlegen → `P-000042` · neg. Preis & Steuersatz `0.15` **abgelehnt** · ändern · suchen · Löschsperre
 
 ---
 
-## Demo 3 — Wizard, Export & Storno
+## Gruppe A — Prozess / Dokumentenzyklus
 
-- **Geführte Rechnungserstellung** (Wizard): Kunde → Positionen → Bestätigen → Zusammenfassung → Speichern *(BA-13)*
-- **PDF-Export** der Belege (PDFBox) ins lokale Dateisystem *(IF-01)*
-- **CSV-Vollexport** von Stamm- **und** Bewegungsdaten – offenes Format *(Q-08)*
-- **Stornierung** einer offenen Rechnung mit Datum & Benutzer; versendete Belege sind **unveränderlich** *(BA-14, GR-02)*
+### Ziel *(Lasten-/Pflichtenheft)*
+Angebot → Auftragsbestätigung → Lieferschein → Rechnung *(BA-09–12)* · lückenlose Belegnummern *(GR-01)* · Steuer & Zahlungsziel · § 14 UStG · Storno *(BA-14)*
+
+### Technische Umsetzung
+- **Snapshot-Prinzip**: alte Rechnungen bleiben preisstabil, auch wenn sich Produktpreise ändern *(GR-03)*
+- **Lückenlose** Belegnummern (GoBD) · Folgebeleg übernimmt Daten + Rückreferenz *(GR-05)*
+  <small>`DokumentRepository` · `BelegnummernGenerator` · `PdfBoxPdfExporter`</small>
+
+### Live-Demo
+Angebot → Folgebeleg-Kette → Rechnung (`R-2026-000124`, netto/Steuer/brutto, Zahlungsziel +14) · **PDF-Export** · **Storno**
 
 ---
 
-## Oberfläche: Beitrag Gruppe D
+## Gruppe D — Programmoberfläche
 
-- Die Demo läuft über die von Gruppe D umgesetzte **Swing-Oberfläche**
-- Verantwortet: Navigation, Dialogführung, Pflichtfeldhinweise und Status-/Aktionsanzeige
-- Fachlogik bleibt in den Komponenten A–C und wird über Services aufgerufen
-- Beispiel Traceability: `BA-13` → `F-09…F-13` → `TC-01…TC-08` → `RechnungsWizardController`
-- Nachweis: `OberflaechenControllerTest` mit **15 grünen JUnit-Tests**
+### Ziel *(Lasten-/Pflichtenheft)*
+Geführte Rechnungserstellung *(BA-13)* · Navigation, Pflichtfeldhinweise *(Q-09)*, Statusanzeige · bedienbar **ohne Vorkenntnisse** *(PZ-03)*
+
+### Technische Umsetzung
+- **EreignisBus (Observer)**: Panels aktualisieren sich automatisch nach Datenänderung
+- Fachlogik strikt getrennt — GUI ruft nur die Services der Komponenten A–C
+  <small>Swing + FlatLaf · `HauptFenster` · `RechnungsWizardController`</small>
+
+### Live-Demo
+**Wizard**: Kunde → Positionen → Bestätigen → Zusammenfassung → Speichern · Statusfilter „offen" · Pflichtfeldhinweis · PDF-/CSV-Export
 
 ---
 
@@ -190,57 +203,40 @@ Querschnitt (`gemeinsam`): EreignisBus, JSON-Persistenz, CSV-Hilfe – von allen
 
 ## Ergebnisse der Modultestpläne
 
-**71 deterministische JUnit-5-Testfälle – alle grün.** Nachbarkomponenten durch Stubs/Mocks ersetzt.
+### 71 / 71 Testfälle bestanden — 100 %, 0 Fehler
 
-| Komponente | Testfälle |
-|---|---|
-| A — Dokumentenzyklus (Zyklus, Persistenz, PDF, CSV) | 18 |
-| B — Produktverwaltung | 14 |
-| C — Kundenverwaltung | 14 |
-| D — Programmoberfläche (Controller) | 15 |
-| Gemeinsame Infrastruktur (EreignisBus, JSON) | 6 |
-| Performance/Last (Q-02/03/04/08) | 4 |
-| **Summe** | **71** |
+| Komponente | Tests | | Performance | gemessen | Schranke |
+|---|---|---|---|---|---|
+| A — Dokumentenzyklus | 18 | | Start | 0,039 s | ≤ 5 s |
+| B — Produktverwaltung | 14 | | Suche | 0,025 s | ≤ 1 s |
+| C — Kundenverwaltung | 14 | | PDF | 0,011 s | ≤ 2 s |
+| D — Programmoberfläche | 15 | | Export | 0,181 s | ≤ 30 s |
+| Infrastruktur · Performance | 6 · 4 | | *(5.000 Kunden/Produkte)* | | |
 
-Performance-Schranken eingehalten: Start ≤ 5 s, Suche ≤ 1 s, PDF ≤ 2 s, Export ≤ 30 s (5.000 Kunden/Produkte).
+<small>Deterministische JUnit-5-Tests, Nachbarkomponenten als Stubs/Mocks. Traceability **Anforderung → Code (`@DisplayName`) → Testfall**; spezifiziert in `Modultestplan.md`, nachgewiesen in `Anforderungsabgleich.md`.</small>
 
----
-
-## Traceability
-
-**Lückenlose Kette: Anforderung → Codebeleg → Testfall.**
-
-- Spezifikation der Testfälle: **`Modultestplan.md`** (Vorbedingung / Eingabe / erwartetes Ergebnis)
-- Nachweismatrix: **`Anforderungsabgleich.md`** — BA-01…14, GR-01…06, Q-01…09, AC-01…11
-- Jede Testfall-ID ist auch im Code per `@DisplayName` auffindbar
-  (`TC-…`, `INF-…`, `Q-…`) → direkt grep-bar
-
-> Alle durch Code/Tests belegbaren Anforderungen sind ✅; offen bleiben nur organisatorische Usability-Tests (Q-05/AC-11).
+> Alle durch Code/Tests belegbaren Anforderungen ✅ — offen bleiben nur organisatorische Usability-Tests (Q-05 / AC-11).
 
 ---
 
 ## Wo wurde KI eingesetzt – und wie gut?
 
-> *Entwurf — vom Team mit eigenen Erfahrungswerten zu ergänzen.*
-
 **Eingesetzt für**
 - **Dokumentation:** Entwürfe für Lasten-/Pflichtenhefte, Modultestplan, Traceability-Matrix
-- **Code:** Boilerplate der Repository-/Service-Schicht, JSON-Persistenz, CSV-Export, JUnit-Testgerüste
+- **Code:** Boilerplate der Repository-/Service-Schicht, JSON-Persistenz, CSV-Export, JUnit-Testgerüste, Verwendung von Design-Patters, Optimierungen
 - **Diagramme & Tooling:** PlantUML-Quellen, Maven-Konfiguration, pandoc-/PDF-Workflow
 
 **Bewertung**
-- 👍 Hohes Tempo bei wiederkehrendem Code, Tests & Doku; konsistente deutsche Fachsprache; schnelle Iteration nach Feedback
-- 👎 Fachlogik (§ 14 UStG, GoBD, Steuer-/Snapshot-Regeln) und Gruppen-Schnittstellen mussten **manuell geprüft & nachgeschärft** werden; Vorschläge teils zu generisch
+- 👍 Hohes Tempo bei Produktion, Tests & Doku; konsistente deutsche Fachsprache; schnelle Iteration nach Feedback
+- 👎 Vorschläge teils zu generisch
 
 ---
 
 ## Was würden wir nächstes Mal anders machen?
 
-> *Entwurf — vom Team zu ergänzen.*
-
 - **Früher integrieren:** modulübergreifende Tests nicht erst spät im V-Modell
 - **Schnittstellen-Verträge** zwischen Gruppen A–D verbindlich zu Projektbeginn festlegen
-- **Kleinere, häufigere Commits** + konsequentere Pull-Request-Reviews
+- **Kleinere, häufigere Commits** + einheitliche Anforderungen an commits
 - **KI-Output gezielter prüfen** statt übernehmen – besonders bei Fachlogik
 - Aufgaben-/Lastverteilung über die Git-History früh sichtbar machen
 
@@ -260,6 +256,4 @@ Performance-Schranken eingehalten: Start ≤ 5 s, Suche ≤ 1 s, PDF ≤ 2 s, Ex
 
 # Vielen Dank!
 
-### Fragen?
-
 **Team 1 · Desktop-Fakturierungsanwendung · SE1 SoSe 2026**