11 KiB
| title | subtitle | author | date | lang | geometry | fontsize | mainfont | colorlinks | linkcolor | urlcolor | toc | toc-depth | numbersections |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Project Charter – Fakturierungssystem | SE1 Team 2 – Hochschule Mannheim | Christopher Lampert | 14.05.2026 | de-DE | left=2.2cm,right=2.2cm,top=2cm,bottom=2cm | 10pt | Latin Modern Roman | true | blue | blue | true | 2 | false |
Project Charter – Fakturierungssystem
Modul: Software Engineering 1 Team: SE1 Team 2 – Hochschule Mannheim Version: 1.1 Stand: 14.05.2026
1. Freigabeübersicht
| Ersteller | Prüfer | Freigebender |
|---|---|---|
| Oleg Akimenko | Prof. Dr. Gerd Marmitt | SE1 Team 2 (Gruppenleiter) |
2. Dokumentenhistorie
| Version | Datum | Autor | Änderung |
|---|---|---|---|
| 1.0 | 15.04.26 | O. Akimenko | Initiale Erstellung |
| 1.1 | 05.05.26 | C. Lampert | Überarbeitung nach Review: Kapitelnummerierung angepasst, Anforderungen ins Lastenheft verschoben, Zeitplan konkretisiert, Technologie-Stack ausgelagert, Gruppenleiter dokumentiert, Nicht-Ziele präzisiert, Erfolgskriterien Z1 ergänzt, V-Modell-Kapitel ausformuliert |
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
| Nr. | Ziel | Erfolgskriterium |
|---|---|---|
| Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet, gelöscht und gesucht werden |
| Z2 | Kundenverwaltung | Kundendaten sind vollständig anlegbar, änderbar, löschbar und auffindbar |
| Z3 | Dokumentenworkflow | Angebot → Auftragsbestätigung → Lieferschein → Rechnung wird durchgängig unterstützt |
| Z4 | GUI | Funktionale, einheitliche Oberfläche mit Navigation zwischen allen Modulen |
4.1 Nicht-Ziele
- Mobile Anwendung
- Cloud-System bzw. Multi-Tenant-Betrieb
- Mehrbenutzer-Online-System (gleichzeitiger Mehrbenutzerbetrieb über Netzwerk)
- Vollwertiges Buchhaltungssystem (z. B. Bilanz, Kontenrahmen, FiBu-Export)
- E-Rechnung (XRechnung, ZUGFeRD)
- Anbindung an externe Buchhaltungs- oder ERP-Systeme
- Mehrsprachigkeit (System ausschließlich in deutscher Sprache)
5. Business Case
- Zielgruppe: kleine Unternehmen sowie Lernprojekt
- Nutzen: Automatisierung von Fakturierungsprozessen
- Problem: manuelle Rechnungsprozesse sind fehleranfällig und ineffizient
6. Stakeholder und Teamstruktur
6.1 Stakeholder
| Rolle | Beschreibung |
|---|---|
| Auftraggeber | 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.
| Gruppe | Mitglieder | Gruppenleiter | Verantwortungsbereich |
|---|---|---|---|
| E | Hadil Jondi [3030438], Nicolas Seelinger [3027710] | Nicolas Seelinger | Programmoberfläche |
| F | Andreas Ivanovic [3028874], Armin Omanovic [3028711], Alexander Teller [3028801] | Andreas Ivanovic | Dokumentenprozess |
| G | Rahaf Alhosny [3026969], Fatemeh Mohammadi [3029148], Lulia Silk [3030489] | Lulia Silk | Produktverwaltung |
| H | Oleg Akimenko [3028868], Christopher Lampert [3027248], Kenan Pekarovic [3027541] | Oleg Akimenko | Kundenverwaltung |
7. Vorgehensmodell
Das Projekt orientiert sich am V-Modell. Auf der linken Seite des V werden die Anforderungs- und Entwurfsphasen durchlaufen (Anforderungsanalyse, Systemarchitektur, Detailentwurf, Implementierung), auf der rechten Seite die zugehörigen Testphasen (Komponenten-, Integrations-, Systemtest, Abnahmetest). Jede Entwicklungsphase wird so direkt mit der korrespondierenden Testphase verknüpft (Traceability gemäß Lastenheft, Kap. 8.4).
Die Phasen umfassen:
- Anforderungen (siehe Lastenheft v1.1)
- System- und Softwaredesign
- Implementierung
- Integration und Test
- Abnahme
8. Zeitplan und Meilensteine
Jeder Entwicklungsphase ist eine entsprechende Testphase zugeordnet. Das Project Charter ist ein lebendes Dokument; bei Anpassungen wird eine neue Version erstellt.
| Nr. | Phase | Inhalt | Datum |
|---|---|---|---|
| M1 | Anforderungen | Erhebung und Dokumentation der System- und Softwareanforderungen (Lastenheft) | 15.04.2026 – 15.05.2026 |
| M2 | Architektur | Systemarchitektur und Schnittstellendesign | 22.05.2026 |
| M3 | Detailentwurf | Moduldesign (Produkt-, Kundenverwaltung, UI, Prozess) | 29.05.2026 |
| M4 | Implementierung | Umsetzung aller Module im Code | 12.06.2026 |
| M5 | Integrationstest | Zusammenführung und Schnittstellentests | 19.06.2026 |
| M6 | Systemtest | Prüfung gegen Anforderungen | 26.06.2026 |
| M7 | Abnahme | Präsentation und finale Abgabe | 30.06.2026 |
Hinweis: Der Technologie-Stack ist in einem separaten Dokument (
Technologiestack.md) dokumentiert und wird perspektivisch im Architekturdokument (vgl. SE2) fortgeschrieben.
9. Risikomanagement
| Risiko | Wahrscheinlichkeit / Impact | Gegenmaßnahme |
|---|---|---|
| Ausfall von Teammitgliedern | Mittel / Hoch | Wissensaustausch, Pair-Programming |
| Merge-Konflikte | Mittel / Mittel | Code Reviews, kurze Feature-Branches |
| Integrationsprobleme | Mittel / Mittel | Frühe Integrationstests, klare Schnittstellen |
| Zeitverzug | Hoch / Mittel | MVP-Fokus, wöchentliche Statusprüfung |
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
- saubere Repository-Struktur
- teamübergreifende Integration
- dokumentierter Entwicklungsprozess
11. Kommunikationswege
| Kanal | Zweck | Frequenz |
|---|---|---|
| Discord / WhatsApp | Kommunikation | täglich |
| Gitty | Codeverwaltung | kontinuierlich |
| Meetings | Planung | wöchentlich |
| Betreuerkontakt | bei Bedarf |
12. Definition of Done
Ein Feature gilt als abgeschlossen, wenn es
- implementiert und funktionsfähig ist,
- getestet ist,
- ein Code-Review durchlaufen hat,
- dokumentiert ist,
- in das Gesamtsystem integriert ist.
13. Abnahmekriterien
- alle Pflichtmodule implementiert
- vollständiger Dokumentenprozess vorhanden
- GUI funktionsfähig
- Tests erfolgreich
- Präsentation bestanden
14. Genehmigung
Je Untergruppe unterzeichnet ausschließlich der jeweilige Gruppenleiter (siehe Kap. 6.2).
| Rolle | Name | Unterschrift | Datum |
|---|---|---|---|
| Betreuer | Prof. Dr. Gerd Marmitt | ______________________________ | _________ |
| Gruppenleiter Gruppe E | Nicolas Seelinger | ______________________________ | _________ |
| Gruppenleiter Gruppe F | Andreas Ivanovic | ______________________________ | _________ |
| Gruppenleiter Gruppe G | Lulia Silk | ______________________________ | _________ |
| Gruppenleiter Gruppe H | Oleg Akimenko | ______________________________ | _________ |