239 lines
6.9 KiB
Markdown
239 lines
6.9 KiB
Markdown
---
|
||
title: Project Charter – Fakturierungssystem
|
||
author: Oleg Akimenko
|
||
version: 1.0
|
||
lang: de-DE
|
||
toc: true
|
||
---
|
||
|
||
# Freigabeübersicht
|
||
|
||
| Ersteller | Prüfer | Freigebender |
|
||
|---|---|---|
|
||
| Oleg Akimenko | Prof. Dr. Gerd Marmitt | [Wird im Team abgestimmt] |
|
||
| SE1 Team 2 | Hochschule Mannheim | SE1 Team 2 |
|
||
| 15.04.2026 | 15.04.2026 | 30.06.2026 |
|
||
|
||
---
|
||
|
||
# Dokumentenhistorie
|
||
|
||
| Version | Datum | Autor | Änderung |
|
||
|---|---|---|---|
|
||
| 1.0 | 15.04.2026 | Oleg Akimenko | Initiale Erstellung |
|
||
|
||
---
|
||
|
||
# Projektübersicht
|
||
|
||
## 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.
|
||
|
||
---
|
||
|
||
## 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.
|
||
|
||
---
|
||
|
||
# Projektziele
|
||
|
||
| Nr. | Ziel | Erfolgskriterium |
|
||
|---|---|---|
|
||
| Z1 | Produktverwaltung | Produkte können erstellt, bearbeitet und gelöscht werden |
|
||
| Z2 | Kundenverwaltung | Kundendaten sind vollständig verwaltbar |
|
||
| Z3 | Dokumentenworkflow | Angebot → Auftragsbestätigung → Lieferschein → Rechnung |
|
||
| Z4 | GUI | Benutzerfreundliche und funktionale Oberfläche |
|
||
|
||
## Nicht-Ziele
|
||
|
||
- Mobile Anwendung
|
||
- Cloud-System
|
||
- Mehrbenutzer-Online-System
|
||
- Buchhaltungssystem
|
||
- E-Rechnung
|
||
|
||
---
|
||
|
||
# Business Case
|
||
|
||
- Zielgruppe: kleine Unternehmen und Lernprojekt
|
||
- Nutzen: Automatisierung von Fakturierungsprozessen
|
||
- Problem: manuelle Rechnungsprozesse sind fehleranfällig und ineffizient
|
||
|
||
---
|
||
|
||
# Stakeholder
|
||
|
||
| Rolle | Beschreibung |
|
||
|---|---|
|
||
| Auftraggeber | Prof. Dr. Gerd Marmitt |
|
||
| Entwicklungsteam | SE1 Team 2 |
|
||
| Endnutzer | spätere Anwender des Systems |
|
||
|
||
---
|
||
|
||
# Teamstruktur und Repositories
|
||
|
||
| Gruppe | Repository | Mitglieder | Verantwortungsbereich |
|
||
|---|---|---|---|
|
||
| Gruppe E | SE1_Gruppe_E | Hadil Jondi [3030438], Nicolas Seelinger [3027710]| Programmoberfläche |
|
||
| Gruppe F | SE1_Gruppe_F | Andreas Ivanovic [3028874], Armin Omanovic [3028711], Alexander Teller [3028801]| Dokumentenprozess |
|
||
| Gruppe G | SE1_Gruppe_G | Rahaf Alhosny [3026969], Fatemeh Mohammadi [3029148], Lulia Silk [3030489]| Produktverwaltung |
|
||
| Gruppe H | SE1_Gruppe_H | Oleg Akimenko [3028868], Christopher Lampert [3027248], Kenan Pekarovic [3027541]| Kundenverwaltung |
|
||
|
||
---
|
||
|
||
# Funktionale Anforderungen
|
||
|
||
- Verwaltung von Produkten
|
||
- Verwaltung von Kunden
|
||
- Benutzeroberfläche
|
||
- Angebotserstellung
|
||
- Auftragsbestätigung
|
||
- Lieferschein
|
||
- Rechnungserstellung
|
||
|
||
## Nicht-funktionale Anforderungen
|
||
|
||
- Gute Usability
|
||
- Wartbarer Code
|
||
- Versionierung über Git
|
||
- Saubere Architektur
|
||
- Testbarkeit der Module
|
||
|
||
---
|
||
|
||
# Vorgehensmodell
|
||
|
||
Das Projekt orientiert sich am V-Modell.
|
||
|
||
- Anforderungen
|
||
- System- und Softwaredesign
|
||
- Implementierung
|
||
- Integration und Test
|
||
- Abnahme
|
||
|
||
---
|
||
|
||
# Zeitplan / Meilensteine (V-Modell-orientiert)
|
||
|
||
Das Projekt orientiert sich am V-Modell mit Fokus auf Verifikation und Validierung.
|
||
Jeder Entwicklungsphase ist eine entsprechende Testphase zugeordnet.
|
||
|
||
| Nr. | Phase | Inhalt | Datum |
|
||
|---|---|---|---|
|
||
| M1 | Anforderungen | Erhebung und Dokumentation der System- und Softwareanforderungen | 15.04.2026 |
|
||
| M2 | Architektur | Systemarchitektur und Schnittstellendesign | [Datum] |
|
||
| M3 | Detailentwurf | Moduldesign (Produkt-, Kundenverwaltung, UI, Prozess) | [Datum] |
|
||
| M4 | Implementierung | Umsetzung aller Module im Code | [Datum] |
|
||
| M5 | Integrationstest | Zusammenführung und Schnittstellentests | [Datum] |
|
||
| M6 | Systemtest | Prüfung gegen Anforderungen | [Datum] |
|
||
| M7 | Abnahme | Präsentation und finale Abgabe | 30.06.2026 |
|
||
|
||
---
|
||
|
||
# Technologie-Stack
|
||
|
||
| Bereich | Technologie |
|
||
|---|---|
|
||
| Frontend | JavaFX |
|
||
| Backend | Java |
|
||
| Datenbank | SQLite |
|
||
| Version Control | Gitty |
|
||
| Tools | IntelliJ, VS Code, Discord |
|
||
|
||
---
|
||
|
||
# Risikomanagement
|
||
|
||
| Risiko | Wahrscheinlichkeit / Impact | Gegenmaßnahme |
|
||
|---|---|---|
|
||
| Ausfall von Teammitgliedern | Mittel / Hoch | Wissensaustausch |
|
||
| Merge-Konflikte | Mittel / Mittel | Code Reviews |
|
||
| Integrationsprobleme | Mittel / Mittel | frühe Tests |
|
||
| Zeitverzug | Hoch / Mittel | MVP-Fokus |
|
||
|
||
---
|
||
|
||
# Ressourcen und Rahmenbedingungen
|
||
|
||
- Teamgröße: 11 Personen
|
||
- Zeit pro Person: 2–3 Stunden pro Woche
|
||
- Projektlaufzeit: 15.04.2026 – 30.06.2026
|
||
- Budget: kein Budget
|
||
- Infrastruktur: Gitty, Discord, lokale Entwicklung
|
||
|
||
Rahmenbedingungen:
|
||
- Umsetzung aller Pflichtmodule
|
||
- saubere Repository-Struktur
|
||
- Teamübergreifende Integration
|
||
- dokumentierter Entwicklungsprozess
|
||
|
||
---
|
||
|
||
# Kommunikationswege
|
||
|
||
| Kanal | Zweck | Frequenz |
|
||
|---|---|---|
|
||
| Discord/Whatsapp
|
||
|
||
|
||
| Kommunikation | täglich |
|
||
| Gitty | Codeverwaltung | kontinuierlich |
|
||
| Meetings | Planung | wöchentlich |
|
||
| E-Mail | Betreuerkontakt | bei Bedarf |
|
||
|
||
---
|
||
|
||
# Definition of Done
|
||
|
||
Ein Feature gilt als abgeschlossen, wenn:
|
||
|
||
- Implementiert und funktionsfähig
|
||
- getestet
|
||
- Code Review durchgeführt
|
||
- dokumentiert
|
||
- integriert
|
||
|
||
---
|
||
|
||
# Abnahmekriterien
|
||
|
||
- alle Pflichtmodule implementiert
|
||
- vollständiger Dokumentenprozess vorhanden
|
||
- GUI funktionsfähig
|
||
- Tests erfolgreich
|
||
- Präsentation bestanden
|
||
|
||
---
|
||
|
||
# Genehmigung
|
||
|
||
| Rolle | Unterschrift | Datum |
|
||
|---|---|---|
|
||
| Betreuer | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|
||
| Teammitglied: | ______________________________ | __________ |
|