272 lines
22 KiB
Markdown
272 lines
22 KiB
Markdown
---
|
||
title: "Project Charter – Fakturierungssystem"
|
||
subtitle: "SE1 Team 2 – Hochschule Mannheim"
|
||
author: "Christopher Lampert"
|
||
date: "15.05.2026"
|
||
lang: de-DE
|
||
geometry: "left=2.2cm,right=2.2cm,top=2cm,bottom=2cm"
|
||
fontsize: 10pt
|
||
mainfont: "Latin Modern Roman"
|
||
colorlinks: true
|
||
linkcolor: "blue"
|
||
urlcolor: "blue"
|
||
toc: true
|
||
toc-depth: 2
|
||
numbersections: false
|
||
---
|
||
|
||
# Project Charter – Fakturierungssystem
|
||
|
||
**Modul:** Software Engineering 1
|
||
**Team:** SE1 Team 2 – Hochschule Mannheim
|
||
**Version:** 1.1
|
||
**Stand:** 15.05.2026
|
||
|
||
---
|
||
|
||
## 1. Freigabeübersicht
|
||
|
||
| Version | Ersteller | Prüfer | Freigebender |
|
||
|---------|---------------------|-------------------------|----------------------------|
|
||
| 1.0 | Oleg Akimenko | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter) |
|
||
| 1.1 | Christopher Lampert | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter) |
|
||
|
||
## 2. Dokumentenhistorie und Änderungswesen
|
||
|
||
### 2.1 Dokumentenhistorie
|
||
|
||
| Version | Datum | Autor | Änderung |
|
||
|----------|-------------|---------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||
| 1.0 | 15.04.2026 | O. Akimenko | Initiale Erstellung |
|
||
| 1.1 | 15.05.2026 | C. Lampert | Überarbeitung nach Review und Schwachstellenanalyse: Kapitelnummerierung angepasst; Anforderungen ins Lastenheft v1.0 verschoben; Technologie-Stack ausgelagert; Gruppenleiter dokumentiert; Nicht-Ziele präzisiert (PDF in-scope/E-Rechnung out-of-scope, Authentifizierung out-of-scope mit Begründung); Erfolgskriterien Z1–Z4 SMART und an NF-Anforderungen verknüpft; Pflichtenheft als Phase im V-Modell und Zeitplan ergänzt; Aufwandsschätzung je Phase; Pufferwoche vor M7; Risikoregister auf 9 Risiken mit messbaren Schwellwerten und Verantwortlichen erweitert; neues Kapitel „Annahmen und Abhängigkeiten" (Kap. 6.3); Begriff „Auftraggeber" durchgängig verwendet (auch Kap. 14); DoD um Akzeptanztest-Pflicht ergänzt; Abnahmekriterien erweitert; Änderungswesen-Prozess (Kap. 2.2) dokumentiert. |
|
||
|
||
### 2.2 Änderungswesen
|
||
|
||
Das Project Charter ist ein **lebendes Dokument**. Änderungen folgen folgendem Prozess:
|
||
|
||
1. **Änderungsantrag:** Jedes Teammitglied kann einen begründeten Antrag an den eigenen Gruppenleiter stellen.
|
||
2. **Bewertung:** Die Gruppenleiter prüfen den Antrag im wöchentlichen Gruppenleiter-Meeting auf Auswirkungen auf Scope, Zeitplan, Risiken und Lastenheft.
|
||
3. **Freigabe:** Der Auftraggeber bestätigt die Änderung.
|
||
4. **Versionierung:** Versionsnummer wird angehoben (Minor: klärende Änderung; Major: Scope-Änderung). Datum, Autor und Änderungsumfang werden in Kap. 2.1 eingetragen.
|
||
5. **Synchronisation:** Alle bezugnehmenden Dokumente (Lastenheft, Pflichtenheft, Architekturdokument) werden im selben Schritt versions-synchronisiert. Eine Charter-Version referenziert immer die zum Zeitpunkt ihrer Freigabe gültige Lastenheft-Version und umgekehrt.
|
||
|
||
---
|
||
|
||
## 3. Projektübersicht
|
||
|
||
### 3.1 Projektzweck
|
||
|
||
Das Ziel des Projekts ist die konzeptionelle und praktische Entwicklung eines modularen Fakturierungssystems im Rahmen des Moduls Software Engineering 1.
|
||
|
||
Das System bildet einen vollständigen Geschäftsprozess von der Angebotserstellung über die Auftragsbestätigung und den Lieferschein bis hin zur Rechnungserstellung ab. Dabei steht nicht nur die Implementierung im Vordergrund, sondern insbesondere die Anwendung strukturierter Softwareentwicklungsprozesse und die Umsetzung eines klassischen Vorgehensmodells.
|
||
|
||
### 3.2 Projekthintergrund
|
||
|
||
Die Entwicklung moderner Softwaresysteme erfordert strukturierte Vorgehensmodelle, klare Anforderungen und eine saubere Trennung von Entwicklungs- und Testphasen.
|
||
|
||
Im Rahmen des Moduls Software Engineering 1 wird ein praxisnahes Projekt durchgeführt, das die Anwendung klassischer Entwicklungsprozesse im Team ermöglicht. Das Fakturierungssystem dient als realistisches Szenario, um zentrale Konzepte der Softwareentwicklung wie Anforderungsanalyse, Architekturdesign, Implementierung, Integration und Test praktisch umzusetzen.
|
||
|
||
Das Projekt orientiert sich am V-Modell als strukturiertem Vorgehensmodell.
|
||
|
||
---
|
||
|
||
## 4. Projektziele
|
||
|
||
Die folgenden Ziele sind SMART formuliert und gegen die nicht-funktionalen Anforderungen sowie Akzeptanztests des Lastenhefts v1.0 (Kap. 5 bzw. Anhang 8.4) messbar.
|
||
|
||
| Nr. | Ziel | Erfolgskriterium |
|
||
|------|---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||
| Z1 | Produktverwaltung | Alle CRUD-Operationen (Anlegen, Bearbeiten, Suchen, Löschen) bei einem Datenbestand von bis zu 1.000 Produkten innerhalb der NF-PERF-01-Antwortzeit von 1 s. Akzeptanztests AT-PV-01 bis AT-PV-08 bestanden. Geschäftsregel GR-05 (Stammdatenschutz bei referenzierten Produkten) eingehalten. |
|
||
| Z2 | Kundenverwaltung | CRUD bei bis zu 1.000 Kunden analog Z1. Akzeptanztests AT-KV-01 bis AT-KV-08 bestanden. DSGVO-konformes Löschen (NF-SEC-02) unter Beachtung der Aufbewahrungspflicht (GR-05) demonstrierbar. |
|
||
| Z3 | Dokumentenworkflow | Vollständiger Prozess Angebot → Auftragsbestätigung → Lieferschein → Rechnung an mindestens einem Beispielkunden und -produkt durchgängig demonstrierbar; Rechnung enthält alle Pflichtangaben nach § 14 UStG; Akzeptanztests AT-DP-01 bis AT-DP-07 sowie GR-01 bis GR-06 bestanden. |
|
||
| Z4 | GUI | Funktionale, einheitliche Oberfläche mit Navigation zwischen allen Modulen; alle Belege per GUI erstell- und als PDF exportierbar; Usability gemäß NF-USE-01/02 (Anlegen Kunde < 2 min, > 80 % Erfolgsquote „Angebot → Rechnung") nachgewiesen; Akzeptanztests AT-GUI-01 bis AT-GUI-08 bestanden. |
|
||
|
||
### 4.1 Nicht-Ziele
|
||
|
||
Folgendes ist **nicht** Bestandteil des Projekts:
|
||
|
||
- Mobile Anwendung
|
||
- Cloud-System bzw. Multi-Tenant-Betrieb
|
||
- Mehrbenutzer-Online-System (gleichzeitiger Mehrbenutzerbetrieb über Netzwerk)
|
||
- Vollwertiges Buchhaltungssystem (z. B. Bilanz, Kontenrahmen, FiBu-Export)
|
||
- Strukturierte E-Rechnung (XRechnung, ZUGFeRD) — eine einfache PDF-Ausgabe der Belege ist hingegen **in-scope** (siehe BA-DP-07 im Lastenheft)
|
||
- Anbindung an externe Buchhaltungs- oder ERP-Systeme
|
||
- Mehrsprachigkeit (System ausschließlich in deutscher Sprache)
|
||
- Authentifizierung bzw. Benutzeranmeldung — Begründung: lokale Einbenutzer-Anwendung; Zugriffsschutz erfolgt durch das Betriebssystem-Login des PC-Arbeitsplatzes (siehe Lastenheft Kap. 2.1 und NF-SEC-01)
|
||
|
||
---
|
||
|
||
## 5. Business Case
|
||
|
||
- **Zielgruppe:** kleine Unternehmen sowie Lernprojekt
|
||
- **Nutzen:** Automatisierung von Fakturierungsprozessen
|
||
- **Problem:** manuelle Rechnungsprozesse sind fehleranfällig und ineffizient
|
||
|
||
---
|
||
|
||
## 6. Stakeholder, Teamstruktur, Annahmen
|
||
|
||
### 6.1 Stakeholder
|
||
|
||
| Rolle | Beschreibung |
|
||
|--------------------------------------------|----------------------------------------|
|
||
| Auftraggeber (Lehrveranstaltungs-Betreuer) | Prof. Dr. Gerd Marmitt |
|
||
| Entwicklungsteam | SE1 Team 2 (Gruppen E, F, G, H) |
|
||
| Endnutzer | spätere Anwender (kleines Unternehmen) |
|
||
|
||
### 6.2 Teamstruktur, Repositories und Gruppenleiter
|
||
|
||
Pro Untergruppe ist ein **Gruppenleiter** benannt, der die Untergruppe gegenüber dem Gesamtteam und dem Auftraggeber vertritt und das Project Charter unterzeichnet. Pro Gruppe ist zusätzlich ein **Stellvertreter** benannt (Bus-Faktor > 2, siehe Kap. 9, R1/R9).
|
||
|
||
| Gruppe | Mitglieder | Gruppenleiter | Stellvertreter | Verantwortungsbereich |
|
||
|---------|-----------------------------------------------------------------------------------------|----------------------|---------------------|--------------------------|
|
||
| E | Hadil Jondi [3030438], Nicolas Seelinger [3027710] | Nicolas Seelinger | Hadil Jondi | Programmoberfläche (GUI) |
|
||
| F | Andreas Ivanovic [3028874], Armin Omanovic [3028711], Alexander Teller [3028801] | Andreas Ivanovic | Armin Omanovic | Dokumentenprozess |
|
||
| G | Rahaf Alhosny [3026969], Fatemeh Mohammadi [3029148], Lulia Silk [3030489] | Lulia Silk | Rahaf Alhosny | Produktverwaltung |
|
||
| H | Oleg Akimenko [3028868], Christopher Lampert [3027248], Kenan Pekarovic [3027541] | Oleg Akimenko | Christopher Lampert | Kundenverwaltung |
|
||
|
||
### 6.3 Annahmen und Abhängigkeiten
|
||
|
||
**Annahmen** (gelten als gegeben; sind sie nicht erfüllt, ist eine Re-Planung erforderlich):
|
||
|
||
| ID | Annahme |
|
||
|----|---------------------------------------------------------------------------------------------------------------|
|
||
| A1 | Alle Teammitglieder bringen mindestens 2 h/Woche über die gesamte Projektlaufzeit ein. |
|
||
| A2 | Gitty, Discord und die lokale Entwicklungsumgebung sind während der gesamten Laufzeit verfügbar. |
|
||
| A3 | Der Auftraggeber steht für Rückfragen wöchentlich per E-Mail erreichbar (siehe Kap. 11). |
|
||
| A4 | Die Endgeräte der Anwender erfüllen die in NF-PERF-03 genannten Referenzhardware-Anforderungen. |
|
||
|
||
**Abhängigkeiten zwischen den Gruppen** (Integrationsreihenfolge):
|
||
|
||
| Modul (Gruppe) | Hängt ab von | Wann benötigt? |
|
||
|--------------------------|-----------------------------------------------------------|----------------|
|
||
| Produktverwaltung (G) | — | M4 Start |
|
||
| Kundenverwaltung (H) | — | M4 Start |
|
||
| Dokumentenprozess (F) | Produktverwaltung (G), Kundenverwaltung (H) – Datenmodell | M4 Mitte |
|
||
| GUI (E) | alle drei Backend-Module – Schnittstellen | M4 Mitte → M5 |
|
||
|
||
Schnittstellen zwischen den Modulen werden bis Ende M2 (22.05.2026) als Schnittstellenkontrakte festgelegt.
|
||
|
||
---
|
||
|
||
## 7. Vorgehensmodell
|
||
|
||
Das Projekt orientiert sich am **V-Modell**. Auf der linken Seite des V werden die Anforderungs- und Entwurfsphasen durchlaufen, auf der rechten Seite die zugehörigen Testphasen. Jede Entwicklungsphase wird direkt mit der korrespondierenden Testphase verknüpft (Traceability gemäß Lastenheft v1.0, Kap. 8.4).
|
||
|
||
Die Phasen umfassen:
|
||
|
||
- **Anforderungen** – Lastenheft v1.0 (Auftraggebersicht: was soll das System leisten)
|
||
- **Pflichtenheft / System-Spezifikation** – Antwortdokument des Auftragnehmers (wie wird es umgesetzt; siehe Lastenheft Kap. 1.4)
|
||
- **System- und Softwarearchitektur**
|
||
- **Detailentwurf (Moduldesign)**
|
||
- **Implementierung**
|
||
- **Komponenten- und Integrationstest**
|
||
- **Systemtest** (gegen Anforderungen, inkl. Lasttests NF-PERF)
|
||
- **Abnahme** (Akzeptanztests gegen Lastenheft)
|
||
|
||
---
|
||
|
||
## 8. Zeitplan, Meilensteine und Aufwand
|
||
|
||
Jeder Entwicklungsphase ist eine korrespondierende Testphase zugeordnet. Die letzte Woche (M7) ist als Puffer für Fehlerbeseitigung und Abnahmevorbereitung eingeplant.
|
||
|
||
| Nr. | Phase | Inhalt | Zeitraum | Aufwand (= Pers.-h) |
|
||
|-----|-----------------------------|--------------------------------------------------------------------------------|---------------------------|---------------------|
|
||
| M1 | Anforderungen | Lastenheft v1.0 (System- und Softwareanforderungen aus Auftraggebersicht) | 15.04.2026 – 15.05.2026 | 70 |
|
||
| M2 | Pflichtenheft & Architektur | Pflichtenheft, Systemarchitektur, Schnittstellenkontrakte zwischen den Gruppen | 16.05.2026 – 22.05.2026 | 35 |
|
||
| M3 | Detailentwurf | Moduldesign (Produkt-, Kundenverwaltung, Dokumentenprozess, GUI) | 23.05.2026 – 29.05.2026 | 30 |
|
||
| M4 | Implementierung | Umsetzung aller Module im Code, parallel Komponententests | 30.05.2026 – 12.06.2026 | 90 |
|
||
| M5 | Integrationstest | Zusammenführung und Schnittstellentests | 13.06.2026 – 19.06.2026 | 30 |
|
||
| M6 | Systemtest | Prüfung gegen Anforderungen, Lasttests gemäß NF-PERF-01/02 | 20.06.2026 – 26.06.2026 | 30 |
|
||
| M7 | Puffer & Abnahme | Fehlerbehebung, Akzeptanztests, Präsentation, finale Abgabe | 27.06.2026 – 30.06.2026 | 25 |
|
||
| | | **Summe** | | **= 310** |
|
||
|
||
Das Kapazitätsbudget bei 11 Personen × ca. 11 Wochen × 2,5 h beträgt ca. 300 h und entspricht damit knapp dem geschätzten Aufwand. Risiko Zeitverzug ist entsprechend als „Hoch / Mittel" eingestuft (siehe Kap. 9, R4).
|
||
|
||
|
||
---
|
||
|
||
## 9. Risikomanagement
|
||
|
||
| ID | Risiko | Wahrsch. / Impact | Auslöser-Schwellwert / Indikator | Gegenmaßnahme | Verantwortlich |
|
||
|----|-----------------------------------------|-------------------|----------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|----------------------|
|
||
| R1 | Ausfall von Teammitgliedern | Mittel / Hoch | > 1 Person der Gruppe > 1 Woche ausgefallen | Pair-Programming, Wissensaustausch, Stellvertreter benannt (Kap. 6.2) | Gruppenleiter |
|
||
| R2 | Merge-Konflikte | Mittel / Mittel | Mehr als 2 ungelöste Konflikte/Woche pro Repo | Feature-Branches < 3 Tage, tägliche Pulls aus `main`, Code Reviews | Gruppenleiter |
|
||
| R3 | Integrationsprobleme | Mittel / Mittel | Schnittstellenkontrakt nicht bis Ende M2 vorhanden | Schnittstellenkontrakte vor Implementierung, frühe Mock-Integration ab M3 | Gruppe F + E |
|
||
| R4 | Zeitverzug | Hoch / Mittel | Meilenstein überschritten oder Backlog Soll/Ist > 20 % | MVP-Fokus, wöchentliche Statusprüfung, Pufferwoche M7 | Gesamtteam |
|
||
| R5 | Anforderungsänderung / Scope-Creep | Mittel / Hoch | > 2 nachträglich aufgenommene Muss-Anforderungen nach M2 | Anforderungs-Freeze für Muss-Anforderungen nach M2; Änderungswesen Kap. 2.2 | Auftraggeber + Team |
|
||
| R6 | Lernkurve Technologie-Stack | Hoch / Mittel | Spike in M2 nicht lauffähig | Spike-Sample je Gruppe in M2; gemeinsame Coding-Standards; gegenseitige Code Reviews | Gruppenleiter |
|
||
| R7 | DSGVO- / § 14 UStG-Compliance-Verstoß | Niedrig / Hoch | Akzeptanztest GR-01 oder AT-DP-05 fehlgeschlagen | Pflichtangaben in BA-DP-05 fest verdrahtet; NF-SEC-02-Funktion implementiert; Review-Checkliste GR-01 bis GR-06 | Gruppe F |
|
||
| R8 | Datenverlust auf lokalem System | Mittel / Hoch | Datenbestand seit > 48 h nicht gesichert | Tägliche Sicherung der lokalen Datendatei in Gitty-Branch `data-snapshots`; Testdatensätze ebenfalls in Gitty | Gruppe G + H |
|
||
| R9 | Ausfall Gruppenleiter | Niedrig / Hoch | Gruppenleiter > 1 Woche nicht erreichbar | Stellvertreter benannt (Kap. 6.2); wöchentliche Gruppenleiter-Synchronisation; Repository-Rechte für Stellvertreter | Gesamtteam |
|
||
|
||
---
|
||
|
||
## 10. Ressourcen und Rahmenbedingungen
|
||
|
||
- **Teamgröße:** 11 Personen
|
||
- **Zeit pro Person:** 2–3 Stunden pro Woche
|
||
- **Projektlaufzeit:** 15.04.2026 – 30.06.2026
|
||
- **Budget:** kein finanzielles Budget
|
||
- **Infrastruktur:** Gitty, Discord, lokale Entwicklung
|
||
|
||
**Rahmenbedingungen:**
|
||
|
||
- Umsetzung aller Pflichtmodule (Produktverwaltung, Kundenverwaltung, Dokumentenprozess, GUI)
|
||
- saubere Repository-Struktur (pro Gruppe ein Repo, einheitliche Namenskonvention)
|
||
- teamübergreifende Integration über vereinbarte Schnittstellenkontrakte
|
||
- dokumentierter Entwicklungsprozess (Lastenheft, Pflichtenheft, Architekturdokument)
|
||
|
||
---
|
||
|
||
## 11. Kommunikationswege
|
||
|
||
| Kanal | Zweck | Frequenz |
|
||
|--------------------|-------------------------|----------------|
|
||
| Discord / WhatsApp | Tägliche Kommunikation | täglich |
|
||
| Gitty | Codeverwaltung, Reviews | kontinuierlich |
|
||
| Team-Meetings | Planung, Status | wöchentlich |
|
||
| Gruppenleiter-Sync | Koordination Gruppen | wöchentlich |
|
||
| E-Mail | Auftraggeber-Kontakt | bei Bedarf |
|
||
|
||
---
|
||
|
||
## 12. Definition of Done
|
||
|
||
Ein Feature gilt als abgeschlossen, wenn es
|
||
|
||
- implementiert und funktionsfähig ist,
|
||
- getestet ist und **für jede zugeordnete Muss-Anforderung mindestens ein Akzeptanztest erfolgreich durchlaufen wurde** (siehe Lastenheft Kap. 8.4),
|
||
- ein Code-Review durch ein anderes Teammitglied durchlaufen hat,
|
||
- dokumentiert ist (Code-Kommentare nach NF-MAINT-02; ggf. Eintrag im Pflichtenheft),
|
||
- in das Gesamtsystem integriert ist.
|
||
|
||
---
|
||
|
||
## 13. Abnahmekriterien
|
||
|
||
Das System gilt als abgenommen, wenn alle folgenden Kriterien erfüllt sind:
|
||
|
||
1. Alle Pflichtmodule (Produkt-, Kundenverwaltung, Dokumentenprozess, GUI) sind implementiert und in das Gesamtsystem integriert.
|
||
2. Der vollständige Dokumentenprozess Angebot → Auftragsbestätigung → Lieferschein → Rechnung ist durchgängig demonstrierbar.
|
||
3. Die GUI ist funktionsfähig und ermöglicht den vollständigen PDF-Export aller Belege.
|
||
4. Alle Muss-Anforderungen sind durch zugeordnete Akzeptanztests aus Lastenheft Kap. 8.4 nachgewiesen.
|
||
5. Die Lasttests gemäß NF-PERF-01 und NF-PERF-02 sind mit dem geforderten Datenbestand erfolgreich durchgeführt.
|
||
6. Lastenheft v1.0 sowie Pflichtenheft / Architekturdokument liegen in finaler freigegebener Version vor.
|
||
7. Die Traceability-Matrix (Lastenheft Kap. 8.4) ordnet jeder Muss-Anforderung mindestens einen Akzeptanztest zu.
|
||
8. Die Abnahmepräsentation gegenüber dem Auftraggeber ist erfolgreich durchgeführt.
|
||
|
||
---
|
||
|
||
## 14. Genehmigung
|
||
|
||
Je Untergruppe unterzeichnet ausschließlich der jeweilige **Gruppenleiter** (siehe Kap. 6.2).
|
||
|
||
| Rolle | Name | Unterschrift | Datum |
|
||
|------------------------|------------------------|---------------------------------|-----------|
|
||
| Auftraggeber | Prof. Dr. Gerd Marmitt | ______________________________ | _________ |
|
||
| Gruppenleiter Gruppe E | Nicolas Seelinger | ______________________________ | _________ |
|
||
| Gruppenleiter Gruppe F | Andreas Ivanovic | ______________________________ | _________ |
|
||
| Gruppenleiter Gruppe G | Lulia Silk | ______________________________ | _________ |
|
||
| Gruppenleiter Gruppe H | Oleg Akimenko | ______________________________ | _________ |
|