From 6d6f50cadd79af1d0edb4eab989fb83963ac1200 Mon Sep 17 00:00:00 2001 From: Oleg Akimenko <3028868@stud.th-mannheim.de> Date: Mon, 13 Apr 2026 17:00:27 +0200 Subject: [PATCH] Dateien nach "/" hochladen --- project-charter.md | 307 +++++++++++++++++++++++---------------------- 1 file changed, 159 insertions(+), 148 deletions(-) diff --git a/project-charter.md b/project-charter.md index ade8eb2..9724779 100644 --- a/project-charter.md +++ b/project-charter.md @@ -1,217 +1,228 @@ --- -Title: Projekt Charter -Autor: [Name, Vorname] -Version: 1.0 -Toc: yes +title: Project Charter – Fakturierungssystem +author: Oleg Akimenko +version: 1.0 +lang: de-DE +toc: true --- -| Autor | Prüfer | Freigebende | -|------|------------|---------------------| -| [Name, Vorname] | [Name, Vorname] | [Name, Vorname] | -| [Abteilung/Funktion]| [Abteilung/Funktion] | [Abteilung/Funktion] | -| [Datum, Unterschr.] | [Datum, Unterschr.] | [Datum, Unterschr.] | +# 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 +# Dokumentenhistorie -| Version | Datum | Autor | Grund der Änderung | -|---------|------------|---------------------|---------------------| -| 1.0 | [Datum] | [Name, Vorname] | Initiale Erstellung | - -*(Auf jeder Dokumentseite: Kopf- oder Fußzeile mit Autor, Dokumenttitel, Version, Seitenzahl usw.)* +| Version | Datum | Autor | Änderung | +|---|---|---|---| +| 1.0 | 15.04.2026 | Oleg Akimenko | Initiale Erstellung | --- # Projektübersicht -## Projektzweck -Kurze Beschreibung des Projekts (2–4 Sätze): *[Hier das Projekt beschreiben – welches Problem gelöst wird und für wen.]* +## Projektzweck -## Projekthintergrund -*Hintergrund und Motivation:* [Warum wird dieses Projekt durchgeführt? Welcher Bedarf/Anforderung liegt zugrunde?] +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 -## Ziele -| Nr. | Ziel | Erfolgskriterien | -|-----|----------|------------------| -| 1 | [Ziel 1] | [Kriterium] | -| 2 | [Ziel 2] | [Kriterium] | -| 3 | [Ziel 3] | [Kriterium] | +| 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 -Die folgenden Punkte sind **explizit nicht** Teil dieses Projekts: -- [Nicht-Ziel 1] -- [Nicht-Ziel 2] -- [Nicht-Ziel 3] +## Nicht-Ziele + +- Mobile Anwendung +- Cloud-System +- Mehrbenutzer-Online-System +- Buchhaltungssystem +- E-Rechnung --- -# Business Case -- **Zielgruppe:** [Wer nutzt das System?] -- **Nutzen:** [Welchen Mehrwert bietet die Lösung?] -- **Problem:** [Welches Problem wird gelöst?] +# Business Case + +- Zielgruppe: kleine Unternehmen und Lernprojekt +- Nutzen: Automatisierung von Fakturierungsprozessen +- Problem: manuelle Rechnungsprozesse sind fehleranfällig und ineffizient --- # Stakeholder -## Auftraggeber (extern/intern) | Rolle | Beschreibung | -|------|-------------| -| [z. B. Betreuer] | Anforderungen, Feedback, Abnahme | - -## Regulatorisch -| Vorgabe | Beschreibung | -|--------|-------------| -| [z. B. Datenschutz] | Einhaltung von Richtlinien | - -## Qualitätsmanagement -| Maßnahme | Beschreibung | -|----------|-------------| -| Code Reviews | Qualitätssicherung im Team | -| Tests | Unit- und Integrationstests | +|---|---| +| Auftraggeber | Prof. Dr. Gerd Marmitt | +| Entwicklungsteam | SE1 Team 2 | +| Endnutzer | spätere Anwender des Systems | --- -# Projekt-Team und Rollen -| Bezeichnung | Details | -|----------------|------------------------------------------------------| -| Projektleitung | [Name] (Matrikel: [Nr.]) – Schwerpunkt: [z.B. Koordination] | -| Entwicklung | [Name] (Matrikel: [Nr.]) – Schwerpunkt: [z.B. Frontend] | -| Entwicklung | [Name] (Matrikel: [Nr.]) – Schwerpunkt: [z.B. Backend] | -| QA / Testing | [Name] (Matrikel: [Nr.]) – Schwerpunkt: [z.B. Testing, CI/CD] | +# Teamstruktur und Repositories + +| Gruppe | Repository | Mitglieder | Verantwortungsbereich | +|---|---|---|---| +| Gruppe E | SE1_Gruppe_E | Hadil Jondi [3030438], Nicolas Seelinger [3027710]| Produktverwaltung | +| Gruppe F | SE1_Gruppe_F | Andreas Ivanovic [3028874], Armin Omanovic [3028711], Alexander Teller [3028801]| Programmoberfläche | +| Gruppe G | SE1_Gruppe_G | Rahaf Alhosny [3026969], Fatemeh Mohammadi [3029148], Lulia Silk [3030489]| Dokumentenprozess | +| Gruppe H | SE1_Gruppe_H | Oleg Akimenko [3028868], Christopher Lampert [3027248], Kenan Pekarovic [3027541]| Kundenverwaltung | --- -# Zeitplan / Meilensteine +# Funktionale Anforderungen -## Projektphasen -Phase 1 – Planung & Analyse -- Anforderungserhebung -- Technologiewahl - -Phase 2 – Design -- Architektur -- UI/UX - -Phase 3 – Implementierung -- Entwicklung der Funktionen - -Phase 4 – Testing -- Tests und Fehlerbehebung - -Phase 5 – Abschluss -- Dokumentation -- Präsentation - -## Meilensteine -| Nr. | Meilenstein | Datum | -|-----|--------------------------------|---------| -| 1 | Project Charter abgeschlossen | [Datum] | -| 2 | Anforderungen & Design final | [Datum] | -| 3 | Prototyp (MVP) fertig | [Datum] | -| 4 | Feature-Complete | [Datum] | -| 5 | Testphase abgeschlossen | [Datum] | -| 6 | Abgabe / Präsentation | [Datum] | - ---- - -# Anforderungen (Überblick) - -## Funktionale Anforderungen -- [Funktion 1] -- [Funktion 2] -- [Funktion 3] +- Verwaltung von Produkten +- Verwaltung von Kunden +- Benutzeroberfläche +- Angebotserstellung +- Auftragsbestätigung +- Lieferschein +- Rechnungserstellung ## Nicht-funktionale Anforderungen -- Performance -- Sicherheit -- Usability + +- 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 | [z. B. React / HTML/CSS] | -| Backend | [z. B. Django / Node.js] | -| Datenbank | [z. B. PostgreSQL] | +|---|---| +| Frontend | JavaFX | +| Backend | Java | +| Datenbank | SQLite | | Version Control | Gitty | -| Tools | [z. B. VS Code] | +| Tools | IntelliJ, VS Code, Discord | --- -# Risikomanagement -| Nr. | Risiko | W/A | Gegenmaßnahme | -|-----|------------|-----|---------------| -| 1 | [Risiko 1] | M/H | [Maßnahme] | -| 2 | [Risiko 2] | H/M | [Maßnahme] | -| 3 | [Risiko 3] | M/M | [Maßnahme] | -| 4 | [Risiko 4] | H/M | [Maßnahme] | +# 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 Budget -- **Teamgröße:** X Personen -- **Verfügbare Zeit pro Person:** [Stunden/Woche] -- **Projektlaufzeit:** [Startdatum] – [Enddatum] -- **Budget:** [Betrag] -- **Infrastruktur:** [z. B. GitHub, Uni-Server] +# Ressourcen und Rahmenbedingungen -**Rahmenbedingungen:** -- Abgabe bis [Datum] -- Technologiestack gemäß Vorgaben -- Gleichmäßige Arbeitsverteilung +- 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 --- -# Kommunikations- und Entscheidungswege -| Kanal | Zweck | Frequenz | -|------------------|----------------------------|-------------| -| [z.B. Discord] | Team-Kommunikation | täglich | -| [z.B. GitHub] | Aufgabenverwaltung | kontinuierlich | -| [z.B. Meeting] | Fortschrittskontrolle | wöchentlich | -| [z.B. E-Mail] | Kommunikation mit Betreuer | bei Bedarf | +# Kommunikationswege + +| Kanal | Zweck | Frequenz | +|---|---|---| +| Discord | Kommunikation | täglich | +| Gitty | Codeverwaltung | kontinuierlich | +| Meetings | Planung | wöchentlich | +| E-Mail | Betreuerkontakt | bei Bedarf | --- -# Definition of Done (DoD) +# Definition of Done -Ein Feature gilt als fertig, wenn: +Ein Feature gilt als abgeschlossen, wenn: -- Code implementiert und funktionsfähig ist -- Tests erfolgreich bestanden sind -- Code Review durchgeführt wurde -- Dokumentation aktualisiert wurde -- Feature getestet wurde +- Implementiert und funktionsfähig +- getestet +- Code Review durchgeführt +- dokumentiert +- integriert --- # Abnahmekriterien -Das Projekt gilt als erfolgreich abgeschlossen, wenn: - -- Alle Muss-Anforderungen erfüllt sind -- Anwendung demonstrierbar ist -- Tests erfolgreich sind -- Dokumentation vollständig ist -- Präsentation durchgeführt wurde +- alle Pflichtmodule implementiert +- vollständiger Dokumentenprozess vorhanden +- GUI funktionsfähig +- Tests erfolgreich +- Präsentation bestanden --- -## Unterschriften und Genehmigung - -Mit ihrer Unterschrift bestätigen alle Beteiligten, dass sie den Inhalt dieses Project Charters gelesen haben und damit einverstanden sind. +# Genehmigung | Rolle | Unterschrift | Datum | -|-|-|-| -| Betreuer/in | __________________________ | __________ | -| Projektleiter/in | __________________________ | __________ | -| Teammitglied | __________________________ | __________ | -| Teammitglied | __________________________ | __________ | -| Teammitglied | __________________________ | __________ | \ No newline at end of file +|---|---|---| +| Betreuer | ______________________________ | __________ | +| Gruppe E | ______________________________ | __________ | +| Gruppe F | ______________________________ | __________ | +| Gruppe G | ______________________________ | __________ | +| Gruppe H | ______________________________ | __________ | \ No newline at end of file