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.0

de-DE

true

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.1} \fancyfoot[C]{\thepage\ /\ \pageref{LastPage}} \renewcommand{\headrulewidth}{0.4pt} \renewcommand{\footrulewidth}{0pt}

\newpage

+-------------------------+-------------------------+-------------------------+ | Autor | Prüfer | Freigebenden | +=========================+=========================+=========================+ | Name, Vorname | Guengoer, Mirkan | Prof. Dr. Marmitt, Gerd | +-------------------------+-------------------------+-------------------------+ | Entwickler | Entwickler | Modulverantwortlicher | +-------------------------+-------------------------+-------------------------+ | 14.04.2026 | 14.04.2026 | 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

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:

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

Projekt-Team und Rollen

Bezeichnung	Details
Entwicklung 1	Lucas Strubel (Matrikelnummer: 3023626) – Schwerpunkt: Prozess
Entwicklung 2	Luca Kaiser (Matrikelnummer: 3027448) – Schwerpunkt: Prozess
Entwicklung 3	Mirkan Güngör (Matrikelnummer: 3029276) – Schwerpunkt: Programmoberfläche
Entwicklung 4	Moritz König (Matrikelnummer: 3027456) – Schwerpunkt: Programmoberfläche
Entwicklung 5	Mohammed Bouhki (Matrikelnummer: 3028421) – Schwerpunkt: Programmoberfläche
Entwicklung 6	Dino Cickusic (Matrikelnummer: 3026435) – Schwerpunkt: Prozess
Entwicklung 7	Mahsuna Ahadyar (Matrikelnummer: 3029329) – Schwerpunkt: Verwaltung von Kunden
Entwicklung 8	Meron Berhane (Matrikelnummer: 3031895) – Schwerpunkt: Verwaltung von Produkten
Entwicklung 9	Kübra Kilic (Matrikelnummer: 3029356) – Schwerpunkt: Verwaltung von Kunden
Entwicklung 10	Jan-Micah SchulzeAmeling (Matrikelnummer: 3030949) – Schwerpunkt: Verwaltung von Produkten
Entwicklung 11	Jessica Volz (Matrikelnummer: 3027339) – Schwerpunkt: Verwaltung von Produkten
Entwicklung 12	Mara Weidmann (Matrikelnummer: 3031272) – Schwerpunkt: Verwaltung von Kunden

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	[…]	In Bearbeitung
M-03	Systementwurf & Architektur abgeschlossen	[…]	Offen
M-04	Pflichtenheft & Komponentenentwurf	[…]	Offen
M-05	Implementierung abgeschlossen (Feature-Complete)	[…]	Offen
M-06	Integrations- & Systemtests abgeschlossen	[…]	Offen
M-07	Abnahmetest & Präsentation	[…]	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 (Constraints):

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: ____________

12 KiB Raw Blame History Unescape Escape