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

\newpage

+-------------------+-------------------+-------------------+
| Autor             | Prüfer            | Freigebenden      |
+-------------------+-------------------+-------------------+
| Name, Vorname     | Name, Vorname     | Name, Vorname     |
+-------------------+-------------------+-------------------+
| Abteilung/Funktion| Abteilung/Funktion| Abteilung/Funktion|
+-------------------+-------------------+-------------------+
| Datum, Unterschr. | Datum, Unterschr. | Datum, Unterschr. |
+-------------------+-------------------+-------------------+

# Dokumentenhistorie

| Version | Datum      | Autor    | Grund der Änderung  |
|---------|------------|----------|---------------------|
| 1.0     | *10.04.2026*  | *Lucas Strubel* | Initiale Erstellung |

---

# 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 | *Abbildugn 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 (extern/intern)

| 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

| Bezeichnung        | Details                                                                 |
|--------------------|-------------------------------------------------------------------------|
| **Entwicklung 1**  | *Lucas Strubel* (Matrikelnummer: *3023626*) – Schwerpunkt:    |
| **Entwicklung 2**  | *Luca Kaiser* (Matrikel: *[Nr.]*) – Schwerpunkt:  |
| **Entwicklung 3**  | *[]* (Matrikel: *[Nr.]*) – Schwerpunkt:   |
| **Entwicklung 4**  | *[]* (Matrikel: *[]*) – Schwerpunkt:    |
| **Entwicklung 5**  | *[]* (Matrikel: *[Nr.]*) – Schwerpunkt:  |
| **Entwicklung 6**  | *[]* (Matrikel: *[Nr.]*) – Schwerpunkt:   |
| **Entwicklung 7**  | *[]* (Matrikel: *[]*) – Schwerpunkt:    |
| **Entwicklung 8**  | *[]* (Matrikel: *[Nr.]*) – Schwerpunkt:  |
| **Entwicklung 9**  | *[]* (Matrikel: *[Nr.]*) – Schwerpunkt:   |
| **Entwicklung 10**  | *[]* (Matrikel: *[]*) – Schwerpunkt:    |
| **Entwicklung 11**  | *[]* (Matrikel: *[Nr.]*) – Schwerpunkt:  |
| **Entwicklung 12**  | *[]* (Matrikel: *[Nr.]*) – Schwerpunkt:   |

---

# Zeitplan / Meilensteine

**Projektphasen (V-Modell):**

​```
Phase 1 – Anforderungsanalyse
  +-- Project Charter
  +-- Stakeholder-Analyse
  +-- Lastenheft

Phase 2 – Systementwurf
  +-- Systemarchitektur
  +-- Technologiewahl

Phase 3 – Komponentenentwurf
  +-- UI/UX Mockups
  +-- Datenbankdesign
  +-- Pflichtenheft

Phase 4 – Implementierung
  +-- Produktverwaltung
  +-- Kundenverwaltung
  +-- Dokumentenzyklus
  +-- Programmoberfläche

Phase 5 – Integrationstest
  +-- Schnittstellentests
  +-- Modulübergreifende Tests

Phase 6 – Systemtest
  +-- Integrationstests
  +-- Systemvalidierung

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

---

# Risikomanagement

| ID   | Risiko                              | W/A | Gegenmaßnahme                            |
|------|-------------------------------------|-----|------------------------------------------|
| R-01 | Ausfall eines Teammitglieds         | M/H | Wissensteilung, Pair Programming         |
| 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:** *[Startdatum]* – *[Enddatum]*
- **Budget:** kein monetäres Budget (studentisches Projekt)
- **Infrastruktur:** *Gitty, Lokale Entwicklung*

**Rahmenbedingungen (Constraints):**

- Die Abgabe erfolgt bis **[]**
- 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**           | *[z. B. React, Vue, HTML/CSS]* – Begründung: *[…]*      |
| **Backend**            | *[z. B. Spring Boot, Node.js, Django]* – Begründung: *[…]* |
| **Datenbank**          | *[z. B. PostgreSQL, MySQL, MongoDB]* – Begründung: *[…]* |
| **Versionskontrolle**  | Gitea *(Standard, Kollaboration)*                 |
| **Projektmanagement**  | *[z. B. GitHub Projects, Trello]* – Begründung: *[…]*   |
| **CI/CD**              | *[z. B. GitHub Actions]* – 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: ____________