SE1_Team_1/ProjectCharter.md

238 lines
12 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

---
title: "Project Charter"
subtitle: "Software Engineering 1"
author:
- Team 1
version: "1.0"
lang: de-DE
toc: true
toc-depth: 3
numbersections: true
papersize: a4
geometry: "margin=3cm"
fontsize: 12pt
linestretch: 1.5
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.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:**
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: 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: ____________
**Teammitglied:** ________________________________________ Datum: ____________
**Teammitglied:** ________________________________________ Datum: ____________
**Teammitglied:** ________________________________________ Datum: ____________
**Teammitglied:** ________________________________________ Datum: ____________
**Teammitglied:** ________________________________________ Datum: ____________
**Teammitglied:** ________________________________________ Datum: ____________
**Teammitglied:** ________________________________________ Datum: ____________
**Teammitglied:** ________________________________________ Datum: ____________
**Teammitglied:** ________________________________________ Datum: ____________
**Teammitglied:** ________________________________________ Datum: ____________
**Teammitglied:** ________________________________________ Datum: ____________