SE1_Team_1/ProjectCharter.md

12 KiB
Raw Blame History

title subtitle author version lang toc toc-depth numbersections papersize geometry fontsize linestretch mainfont sansfont monofont header-includes
Project Charter Software Engineering 1
Team 1
1.2 de-DE true 3 true a4 margin=3cm 12pt 1.5 Times New Roman Arial DejaVu Sans Mono \usepackage{fancyhdr} \usepackage{lastpage} \pagestyle{fancy} \fancyhf{} \fancyhead[L]{Team 1} \fancyhead[C]{Project Charter} \fancyhead[R]{Version 1.2} \fancyfoot[C]{\thepage\ /\ \pageref{LastPage}} \renewcommand{\headrulewidth}{0.4pt} \renewcommand{\footrulewidth}{0pt}

\newpage

+-------------------------+-------------------------+-------------------------+ | Autor | Prüfer | Freigebender | +=========================+=========================+=========================+ | Name, Vorname | Prof. Dr. Marmitt, Gerd | Prof. Dr. Marmitt, Gerd | +-------------------------+-------------------------+-------------------------+ | Entwickler | Modulverantwortlicher | Modulverantwortlicher | +-------------------------+-------------------------+-------------------------+ | 11.05.2026 | Datum, Unterschr. | Datum, Unterschr. | +-------------------------+-------------------------+-------------------------+

Dokumentenhistorie

Version Datum Autor Grund der Änderung
1.0 10.04.2026 Lucas Strubel Initiale Erstellung
1.1 14.04.2026 Lucas Strubel Ergänzung fehlender Matrikelnummern
1.2 11.05.2026 Mirkan Güngör Umsetzung Feedback zur Project Charter

Projektübersicht

Projektzweck

Im Rahmen des Moduls Software Engineering wird eine Desktop-Fakturierungsanwendung für Kleinstunternehmen, Freiberufler und Selbstständige entwickelt. Die Anwendung bildet den vollständigen kaufmännischen Dokumentenzyklus ab von der Angebotserstellung über Auftragsbestätigung und Lieferschein bis zur finalen Rechnung. Ziel ist eine schlanke, lokal betriebene Alternative zu kostenpflichtigen SaaS-Lösungen, die dem Nutzer vollständige Datensouveränität bietet. Als Referenzsystem dient die Open-Source-Software Fakturama.

Projekthintergrund

Die fortschreitende Digitalisierung des Rechnungswesens sowie die gesetzliche E-Rechnungspflicht im B2B-Bereich (ab 01.01.2025) stellen insbesondere Kleinstunternehmen vor erhebliche Herausforderungen. Dieses Projekt entwickelt eine vereinfachte lehrveranstaltungsbegleitende Fakturierungslösung, die die Kernprozesse eines Fakturierungsprogramms abdeckt und gleichzeitig als praxisnahes Lehrprojekt im Bereich Software Engineering dient.

Projektziele

Ziele

Nr. Ziel Erfolgskriterien
Z-01 Digitale Verwaltung von Produkten und Kunden CRUD-Operationen für beide Module vollständig implementiert und funktionsfähig
Z-02 Abbildung des vollständigen Dokumentenzyklus Alle 4 Dokumenttypen (Angebot, Auftragsbestätigung, Lieferschein, Rechnung) erstellbar und untereinander verknüpfbar
Z-03 Funktionsfähige und bedienbare Programmoberfläche Anwendung kann ohne technische Vorkenntnisse zur Erstellung eines Dokuments genutzt werden

Nicht-Ziele

Die folgenden Punkte sind explizit nicht Teil dieses Projekts:

  • Mehrbenutzer- oder Netzwerkfähigkeit (gleichzeitiger Zugriff mehrerer Nutzer)
  • Vollständiges Buchhaltungsmodul (keine Bilanzierung)
  • Webshop-Anbindung (z. B. WooCommerce, Gambio Connectoren)
  • Mobile Clients oder Web-Applikation
  • Unterstützung von E-Rechnungsformaten (ZUGFeRD / XRechnung)
  • Mahnwesen und automatisiertes Forderungsmanagement
  • Garantierter kommerzieller Support oder Service Level Agreements (SLAs)

Business Case

Kommerzielle Fakturierungssoftware ist für Kleinstunternehmen und Freiberufler häufig mit monatlichen Lizenzkosten verbunden. Bestehende Open-Source-Alternativen (z. B. Fakturama) sind funktional umfangreich, jedoch technisch anspruchsvoll in Installation und Wartung. Das vorliegende Projekt schafft eine schlanke, wartungsarme Lösung.

Nutzen: Kosteneinsparung gegenüber SaaS-Abonnements, vollständige lokale Datenhaltung ohne Cloud-Zwang, geringer Einrichtungsaufwand.

Stakeholder

Auftraggeber

Rolle Name Verantwortlichkeit
Auftraggeber Prof. Dr. Gerd Marmitt Anforderungen, Abnahme, Bewertung

Regulatorisch

Folgende regulatorische Rahmenbedingungen sind für Fakturierungssoftware in Deutschland relevant und werden im Projekt als bekannte Anforderungen geführt, auch wenn ihre vollständige Umsetzung explizit kein Projektziel ist (siehe Nicht-Ziele):

  • GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern): Erstellte Rechnungen dürfen nach Versand nicht mehr verändert werden; alle Geschäftsvorfälle müssen lückenlos erfasst werden.
  • E-Rechnungspflicht ab 01.01.2025: Im B2B-Bereich sind strukturierte elektronische Rechnungsformate (ZUGFeRD, XRechnung) gesetzlich vorgeschrieben. Die Unterstützung dieser Formate ist für dieses Projekt kein Ziel, wird aber als bekannte Anforderung dokumentiert.
  • DSGVO: Kundendaten werden ausschließlich lokal gespeichert; es erfolgt keine Übertragung an Dritte.

Qualitätsmanagement

Ein Feature gilt als fertiggestellt, wenn:

  • Der Code ist implementiert und funktioniert lokal
  • Unit Tests sind geschrieben und bestehen
  • Der Code wurde von mindestens einem anderen Teammitglied reviewed (Pull Request)
  • Die Änderungen sind in den main-Branch gemergt
  • Die relevante Dokumentation wurde aktualisiert
  • Das Feature wurde manuell getestet

Abnahmekriterien Das Projekt gilt als erfolgreich abgeschlossen, wenn:

  1. Alle Muss-Anforderungen (Priorität: Hoch) vollständig implementiert sind
  2. Alle Unit- und Integrationstests bestehen
  3. Die Anwendung lauffähig demonstriert werden kann
  4. Die technische Dokumentation vollständig vorliegt
  5. Das Projekt erfolgreich präsentiert wurde

Projekt-Team und Rollen

Untergruppe Komponente Gruppenleiter Mitglieder
Gruppe A Prozess / Dokumentenzyklus Lucas Strubel (3023626) Luca Kaiser (3027448), Dino Cickusic (3026435)
Gruppe B Verwaltung von Kunden Mahsuna Ahadyar (3029329) Kübra Kilic (3029356), Mara Weidmann (3031272)
Gruppe C Verwaltung von Produkten Meron Berhane (3031895) Jan-Micah SchulzeAmeling (3030949), Jessica Volz (3027339)
Gruppe D Programmoberfläche Mirkan Güngör (3029276) Moritz König (3027456), Mohammed Bouhki (3028421)

Zeitplan / Meilensteine

Projektphasen (V-Modell):

Phase Bezeichnung Kernaufgaben
1 Anforderungsanalyse Project Charter, Stakeholder-Analyse, Lastenheft
2 Systementwurf Systemarchitektur, Technologiewahl
3 Komponentenentwurf UI/UX Mockups, Datenbankdesign, Pflichtenheft
4 Implementierung Produkt-, Kundenverwaltung, Dokumentenzyklus, UI
5 Integrationstest Schnittstellentests, Modulübergreifende Tests
6 Systemtest Integrationstests, Systemvalidierung
7 Abnahmetest Abnahme durch Betreuer, Abschlusspräsentation
Jede Entwicklungsphase korrespondiert mit ihrer jeweiligen Testphase im Rahmen des V-Modells.

Meilensteinplan:

Meilenstein Beschreibung Datum Status
M-01 Project Charter abgeschlossen 15.04.2026 Abgeschlossen
M-02 Lastenheft & Anforderungsanalyse 15.05.2026 In Bearbeitung
M-03 Systementwurf & Architektur abgeschlossen 29.05.2026 Offen
M-04 Pflichtenheft & Komponentenentwurf 12.06.2026 Offen
M-05 Implementierung abgeschlossen (Feature-Complete) 26.06.2026 Offen
M-06 Integrations- & Systemtests abgeschlossen 03.07.2026 Offen
M-07 Abnahmetest & Präsentation 10.07.2026 Offen

Risikomanagement

ID Risiko W/A Gegenmaßnahme
R-01 Ausfall eines Teammitglieds M/H Wissensteilung
R-02 Technische Komplexität unterschätzt M/H Frühzeitige Spikes, Scope-Reduktion
R-03 Anforderungsänderungen N/M Klare Change-Request-Prozesse
R-04 Integrationsprobleme M/M Frühzeitige Integrationstests

Budget und Ressourcen

  • Teamgröße: 12 Personen
  • Verfügbare Zeit pro Person: ca. 2 Stunden/Woche
  • Gesamtprojektlaufzeit: Sommersemester 2026
  • Budget: kein monetäres Budget (studentisches Projekt)
  • Infrastruktur: Gitea, Lokale Entwicklung

Rahmenbedingungen

  • Der Technologie-Stack muss mit der Lehrveranstaltung kompatibel sein
  • Alle Teammitglieder müssen gleichmäßig zum Projekt beitragen (erkennbar in Git-History)

Technologie-Stack

Bereich Technologie / Tool
Frontend […] Begründung: […]
Backend […] Begründung: […]
Datenbank […] Begründung: […]
Versionskontrolle Gitea (Standard, Kollaboration)
Projektmanagement […] Begründung: […]
CI/CD […] Begründung: […]

Kommunikations- und Entscheidungswege

Kanal Zweck Frequenz
Discord Team-Kommunikation täglich
Wöchentliches Meeting Fortschrittsbesprechung wöchentlich
E-Mail Kommunikation mit Professor bei Bedarf

Genehmigung / Unterschriften

Mit ihrer Unterschrift bestätigen alle Beteiligten, dass sie den Inhalt dieser Project Charta gelesen haben und damit einverstanden sind.

Betreuer/in: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________

Teammitglied: ________________________________________ Datum: ____________