diff --git a/dokumentation/projekt/Praesentation.md b/dokumentation/projekt/Praesentation.md index 0999c2e..44a3d89 100644 --- a/dokumentation/projekt/Praesentation.md +++ b/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` - --- -# 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 + `KundenRepository` · `EinfacherKundennummernGenerator` · `KundenReferenzPruefung` + +### 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 + `ProduktRepository` · `EinfacherProduktnummernGenerator` · `ProduktReferenzPruefung` + +### 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)* + `DokumentRepository` · `BelegnummernGenerator` · `PdfBoxPdfExporter` + +### 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 + Swing + FlatLaf · `HauptFenster` · `RechnungsWizardController` + +### 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). +Deterministische JUnit-5-Tests, Nachbarkomponenten als Stubs/Mocks. Traceability **Anforderung → Code (`@DisplayName`) → Testfall**; spezifiziert in `Modultestplan.md`, nachgewiesen in `Anforderungsabgleich.md`. ---- - -## 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** diff --git a/dokumentation/projekt/Praesentation.pdf b/dokumentation/projekt/Praesentation.pdf index bc0260e..ccce210 100644 Binary files a/dokumentation/projekt/Praesentation.pdf and b/dokumentation/projekt/Praesentation.pdf differ