--- marp: true theme: default paginate: true lang: de header: 'Team 1 · Desktop-Fakturierungsanwendung' style: | @import url('https://fonts.googleapis.com/css2?family=Poppins:wght@400;600;700&family=Lora:wght@400;500;700&display=swap'); section { font-family: 'Lora', 'Georgia', serif; font-size: 26px; line-height: 1.6; padding: 64px 80px; color: #141413; background: #faf9f5; } h1, h2 { font-family: 'Poppins', 'Arial', sans-serif; letter-spacing: -0.02em; font-weight: 600; } h1 { color: #141413; } h2 { color: #141413; font-size: 36px; margin: 0 0 0.5em; padding: 0 0 0.35em; border: none; border-bottom: 2px solid #d97757; } h3 { font-family: 'Poppins', 'Arial', sans-serif; color: #d97757; font-size: 16px; font-weight: 600; text-transform: uppercase; letter-spacing: 0.08em; margin: 1.2em 0 0.3em; } strong { color: #141413; } a { color: #6a9bcc; text-decoration: none; } code { font-family: 'Consolas', 'Cascadia Code', monospace; background: #e8e6dc; color: #141413; padding: 2px 6px; border-radius: 3px; font-size: 0.9em; } table { font-size: 22px; border-collapse: collapse; width: 100%; } th { background: transparent; color: #b0aea5; font-family: 'Poppins', 'Arial', sans-serif; font-size: 14px; font-weight: 600; text-transform: uppercase; letter-spacing: 0.06em; padding: 8px 12px; text-align: left; border-bottom: 2px solid #d97757; } td { padding: 10px 12px; border-bottom: 1px solid #e8e6dc; } tr:nth-child(even) { background: transparent; } blockquote { background: transparent; color: #b0aea5; font-style: italic; border: none; border-left: 3px solid #d97757; padding: 8px 18px; margin: 1em 0; border-radius: 0; } section.lead { justify-content: center; text-align: center; background: #141413; color: #faf9f5; } section.lead h1 { color: #faf9f5; font-size: 52px; font-weight: 700; letter-spacing: -0.03em; margin-bottom: 0.2em; border: none; } section.lead h3 { color: #d97757; font-size: 14px; letter-spacing: 0.12em; } section.lead strong { color: #faf9f5; } section.divider { background: #faf9f5; color: #141413; justify-content: center; text-align: center; } section.divider h1 { color: #141413; font-size: 48px; font-weight: 700; border: none; margin-bottom: 0.2em; } section.divider h2 { color: #141413; border: none; } section.divider h3 { color: #d97757; } footer, header { color: #b0aea5; font-family: 'Poppins', 'Arial', sans-serif; font-size: 14px; } --- # Desktop-Fakturierungsanwendung ### Schlanke, lokal betriebene Fakturierung für Kleinstunternehmen --- ## Agenda 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? --- ## Team & Aufgabenverteilung 12 Personen, vier fachliche Komponenten: | Gruppe | Komponente | Leitung | Mitglieder | |---|---|---|---| | **A** | Prozess / Dokumentenzyklus | Lucas Strubel | Luca Kaiser | | **B** | Produktverwaltung | Meron Berhane | Jan-Micah SchulzeAmeling · Jessica Volz | | **C** | Kundenverwaltung | Mahsuna Ahadyar | Kübra Kilic · Mara Weidmann | | **D** | Programmoberfläche | Mirkan Güngör | Moritz König · Mohammed Bouhki | Querschnitt (`gemeinsam`): EreignisBus, JSON-Persistenz, CSV-Hilfe – von allen Gruppen genutzt. --- ## Kontext & Ziel **Problem:** SaaS-Fakturierung kostet laufend Lizenzgebühren; Open-Source-Alternativen (z. B. *Fakturama*) sind im Betrieb anspruchsvoll. **Unsere Lösung:** schlanke Desktop-Anwendung mit voller Datensouveränität – ohne Cloud. | Ziel | Inhalt | |---|---| | **PZ-01** | Digitale Verwaltung von Kunden- & Produktstammdaten (CRUD) | | **PZ-02** | Vollständiger Dokumentenzyklus: Angebot → AB → Lieferschein → Rechnung | | **PZ-03** | Bedienbar ohne Vorkenntnisse (Rechnung in < 10 Min) | | **PZ-04** | 100 % lokale, DSGVO-konforme Datenhaltung | *Nichtziele:* Mehrbenutzer/Netzwerk, vollständige Buchhaltung, E-Rechnung (ZUGFeRD/XRechnung). --- ## Architektur im Überblick **Vier Fachmodule + gemeinsame Infrastruktur**, manuelle Dependency Injection in `Main.java` (kein Framework). - **Repository-Interfaces** je Domäne mit JSON-Implementierungen; atomare Schreibvorgänge (`JsonPersistenz.schreibeAtomar`) - **EreignisBus** (Observer): Services melden Datenänderungen, GUI-Panels aktualisieren sich selbst - **Snapshot-Prinzip** in Belegen + **Löschsperren** (referenzielle Integrität) --- # Das Programm ### Vier Komponenten --- ## Gruppe C — Kundenverwaltung ### Ziel *(Lasten-/Pflichtenheft)* Kundenstammdaten anlegen, ändern, suchen, löschen *(BA-01–04)* · eindeutige Kundennummer · **keine Löschung bei verknüpften Dokumenten** *(GR-04)* ### 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 → automatische Nummer · suchen / sortieren · ändern · löschen --- ## Gruppe B — Produktverwaltung ### Ziel *(Lasten-/Pflichtenheft)* Produkte anlegen, ändern, suchen, löschen *(BA-05–08)* · Nettopreis + Steuersatz · **nur gültige Eingaben**, Löschsperre ### 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 --- ## Gruppe A — Prozess / Dokumentenzyklus ### 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 erstellen → Folgebeleg zu Rechnung → **PDF-Export** --- ## Gruppe D — Programmoberfläche ### 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 --- # Das Entwicklungsprojekt ### Modultests · KI-Einsatz · Lessons Learned --- ## Ergebnisse der Modultestpläne ### 71 / 71 Testfälle bestanden — 100 %, 0 Fehler | Bereich | Testfälle | Ergebnis | |---|---|---| | A — Dokumentenzyklus | 18 | ✅ bestanden | | B — Produktverwaltung | 14 | ✅ bestanden | | C — Kundenverwaltung | 14 | ✅ bestanden | | D — Programmoberfläche | 15 | ✅ bestanden | | Infrastruktur | 6 | ✅ bestanden | | Performance | 4 | ✅ Schranken eingehalten | | **Gesamt** | **71** | **100 % bestanden** | Deterministische JUnit-5-Tests, Nachbarkomponenten als Stubs/Mocks. Traceability **Anforderung → Code (`@DisplayName`) → Testfall**; spezifiziert in `Modultestplan.md`, nachgewiesen in `Anforderungsabgleich.md`. > Alle durch Code/Tests belegbaren Anforderungen ✅ — offen bleiben nur organisatorische Usability-Tests (Q-05 / AC-11). --- ## Wo wurde KI eingesetzt – und wie gut? **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, Verwendung von Design-Patterns, Optimierungen - **Diagramme & Tooling:** PlantUML-Quellen, Maven-Konfiguration, pandoc-/PDF-Workflow **Bewertung** - 👍 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? - **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** + einheitliche Anforderungen an Commits - **KI-Output gezielter prüfen** statt übernehmen – besonders bei Fachlogik - Aufgaben-/Lastverteilung über die Git-History früh sichtbar machen --- # Vielen Dank!