3023626
/
SE1_Team_1
3
3
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
SE1_Team_1/dokumentation/projekt/Praesentation.md

9.6 KiB
Raw Blame History

marp theme paginate lang header style
true default true de Team 1 · Desktop-Fakturierungsanwendung @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 → K-000017 · suchen / sortieren · ändern · Löschsperre bei verknüpftem Kunden (Hinweis mit Anzahl)

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-Patters, 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!