237 lines
8.9 KiB
Markdown
237 lines
8.9 KiB
Markdown
---
|
||
title: Project Charter
|
||
author: Team A
|
||
version: 1.0
|
||
toc: yes
|
||
header-includes: |
|
||
\usepackage{fancyhdr}
|
||
\pagestyle{fancy}
|
||
\fancyhead[L]{Team A}
|
||
\fancyhead[C]{Project Charter}
|
||
\fancyhead[R]{Version 1.0}
|
||
\fancyfoot[C]{\thepage\ / \pageref{LastPage}}
|
||
\usepackage{lastpage}
|
||
---
|
||
|
||
+-------------------+-------------------+-------------------+
|
||
| Autor | Prüfer | Freigebenden |
|
||
+-------------------+-------------------+-------------------+
|
||
| Name, Vorname | Name, Vorname | Name, Vorname |
|
||
+-------------------+-------------------+-------------------+
|
||
| Abteilung/Funktion| Abteilung/Funktion| Abteilung/Funktion|
|
||
+-------------------+-------------------+-------------------+
|
||
| Datum, Unterschr. | Datum, Unterschr. | Datum, Unterschr. |
|
||
+-------------------+-------------------+-------------------+
|
||
|
||
<!-- TODO: Autor, Prüfer und Freigebenden mit konkreten Namen und Daten ausfüllen -->
|
||
|
||
# Dokumentenhistorie
|
||
|
||
| Version | Datum | Autor | Grund der Änderung |
|
||
|---------|------------|----------|---------------------|
|
||
| 1.0 | *[Datum]* | *[Name]* | Initiale Erstellung |
|
||
|
||
---
|
||
|
||
# Projektübersicht
|
||
|
||
## Projektzweck
|
||
|
||
*Kurze Beschreibung des Projekts (2–4 Sätze): Was wird entwickelt? Welches Problem löst die Software? Für wen?*
|
||
|
||
> **Beispiel:** Im Rahmen des Moduls Software Engineering 1 wird eine Webanwendung zur Verwaltung von Studierenden-Lerngruppen entwickelt. Die Anwendung soll es Studierenden ermöglichen, Gruppen zu erstellen, beizutreten und Lernmaterialien zu teilen.
|
||
|
||
## Projekthintergrund
|
||
|
||
*Warum wird dieses Projekt durchgeführt? Welcher Bedarf oder welche Anforderung liegt zugrunde?*
|
||
|
||
<!-- TODO: Inhalt gemäß Vorlesung ergänzen -->
|
||
|
||
---
|
||
|
||
# Projektziele
|
||
|
||
## Ziele
|
||
|
||
| Nr. | Ziel | Erfolgskriterien |
|
||
|------|-------------|------------------|
|
||
| Z-01 | *[Ziel 1]* | *[Kriterium]* |
|
||
| Z-02 | *[Ziel 2]* | *[Kriterium]* |
|
||
| Z-03 | *[Ziel 3]* | *[Kriterium]* |
|
||
|
||
## Nicht-Ziele
|
||
|
||
Die folgenden Punkte sind **explizit nicht** Teil dieses Projekts:
|
||
|
||
- *[Was wird bewusst ausgeschlossen?]*
|
||
- *[z. B. Mobile App, Admin-Backend, Mehrsprachigkeit]*
|
||
|
||
---
|
||
|
||
# Business Case
|
||
|
||
<!-- TODO: Inhalt gemäß Vorlesung ergänzen – Wirtschaftliche Begründung, Nutzen, Kosten-Nutzen-Abwägung -->
|
||
|
||
**Noch auszufüllen**
|
||
|
||
---
|
||
|
||
# Stakeholder
|
||
|
||
## Auftraggeber (extern/intern)
|
||
|
||
| Rolle | Name | Verantwortlichkeit |
|
||
|------------------------|---------------|-------------------------------------|
|
||
| Auftraggeber / Betreuer| *[Dozent/in]* | Anforderungen, Abnahme, Bewertung |
|
||
|
||
## Regulatorisch
|
||
|
||
<!-- TODO: Regulatorische Anforderungen und Rahmenbedingungen ergänzen (z. B. Datenschutz, DSGVO, Hochschulordnung) -->
|
||
|
||
**Noch auszufüllen**
|
||
|
||
## 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 |
|
||
|--------------------|-------------------------------------------------------------------------|
|
||
| **Projektleitung** | *[Name]* (Matrikel: *[Nr.]*) – Schwerpunkt: *[z. B. Backend]* |
|
||
| **Entwicklung 1** | *[Dino]* (Matrikel: *[Nr.]*) – Schwerpunkt: Implementierung, Testing |
|
||
| **Entwicklung 2** | *[Luca]* (Matrikel: *[Nr.]*) – Schwerpunkt: Implementierung, Dokumentation |
|
||
| **Entwicklung 3** | *[Lucas]* (Matrikel: *[Nr.]*) – Schwerpunkt: Implementierung, Architektur |
|
||
| **QA / Testing** | *[Name]* (Matrikel: *[Nr.]*) – Schwerpunkt: *[z. B. Testing, CI/CD]* |
|
||
|
||
---
|
||
|
||
# Zeitplan / Meilensteine
|
||
|
||
**Projektphasen:**
|
||
|
||
```
|
||
Phase 1 – Planung & Analyse
|
||
+-- Anforderungserhebung
|
||
+-- Technologiewahl
|
||
+-- Project Charter
|
||
|
||
Phase 2 – Design & Architektur
|
||
+-- Systemarchitektur
|
||
+-- UI/UX Mockups
|
||
+-- Datenbankdesign
|
||
|
||
Phase 3 – Implementierung
|
||
+-- Sprint 1: [Funktionen]
|
||
+-- Sprint 2: [Funktionen]
|
||
+-- Sprint 3: [Funktionen]
|
||
|
||
Phase 4 – Testing & QA
|
||
+-- Unit Tests
|
||
+-- Integrationstests
|
||
+-- User Acceptance Tests
|
||
|
||
Phase 5 – Abgabe & Präsentation
|
||
+-- Dokumentation finalisieren
|
||
+-- Abschlusspräsentation
|
||
```
|
||
|
||
**Meilensteinplan:**
|
||
|
||
| Meilenstein | Beschreibung | Datum | Status |
|
||
|-------------|------------------------------------|-----------|---------------|
|
||
| M-01 | Project Charter abgeschlossen | *[Datum]* | Abgeschlossen |
|
||
| M-02 | Anforderungsanalyse & Architektur | *[Datum]* | In Bearbeitung|
|
||
| M-03 | Prototyp / MVP fertig | *[Datum]* | Offen |
|
||
| M-04 | Feature-Complete | *[Datum]* | Offen |
|
||
| M-05 | Testing abgeschlossen | *[Datum]* | Offen |
|
||
| M-06 | Abgabe & Präsentation | *[Datum]* | Offen |
|
||
|
||
---
|
||
|
||
# Risikomanagement
|
||
|
||
| ID | Risiko | W/A | Gegenmaßnahme |
|
||
|------|-------------------------------------|-----|------------------------------------------|
|
||
| R-01 | Ausfall eines Teammitglieds | M/H | Wissensteilung, Pair Programming |
|
||
| 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 |
|
||
| R-05 | *[Projektspezifisches Risiko]* | *[W/A]* | *[Maßnahme]* |
|
||
|
||
**Legende:** W/A = Wahrscheinlichkeit/Auswirkung; H = Hoch, M = Mittel, N = Niedrig
|
||
|
||
---
|
||
|
||
# Budget und Ressourcen
|
||
|
||
- **Teamgröße:** *[Anzahl]* Personen
|
||
- **Verfügbare Zeit pro Person:** ca. *[x]* Stunden/Woche
|
||
- **Gesamtprojektlaufzeit:** *[Startdatum]* – *[Enddatum]*
|
||
- **Budget:** kein monetäres Budget (studentisches Projekt)
|
||
- **Infrastruktur:** *[z. B. GitHub Free, lokale Entwicklung, Uni-Server]*
|
||
|
||
**Rahmenbedingungen (Constraints):**
|
||
|
||
- Die Abgabe erfolgt bis **[Datum]**
|
||
- Der Technologie-Stack muss mit der Lehrveranstaltung kompatibel sein
|
||
- Alle Teammitglieder müssen gleichmäßig zum Projekt beitragen (erkennbar in Git-History)
|
||
- *[Weitere Vorgaben des Dozenten]*
|
||
|
||
**Technologie-Stack:**
|
||
|
||
| Bereich | Technologie / Tool |
|
||
|------------------------|----------------------------------------------------------|
|
||
| **Frontend** | *[z. B. React, Vue, HTML/CSS]* – Begründung: *[…]* |
|
||
| **Backend** | *[z. B. Spring Boot, Node.js, Django]* – Begründung: *[…]* |
|
||
| **Datenbank** | *[z. B. PostgreSQL, MySQL, MongoDB]* – Begründung: *[…]* |
|
||
| **Versionskontrolle** | Git / GitHub *(Standard, Kollaboration)* |
|
||
| **Projektmanagement** | *[z. B. GitHub Projects, Trello]* – Begründung: *[…]* |
|
||
| **CI/CD** | *[z. B. GitHub Actions]* – Begründung: *[…]* |
|
||
| **Kommunikation** | *[z. B. Discord, Teams]* – Begründung: *[…]* |
|
||
|
||
---
|
||
|
||
# Kommunikations- und Entscheidungswege
|
||
|
||
| Kanal | Zweck | Frequenz |
|
||
|--------------------------|--------------------------|---------------|
|
||
| *[z. B. Discord]* | Team-Kommunikation | täglich |
|
||
| *[z. B. GitHub Issues]* | Aufgabenverwaltung | kontinuierlich|
|
||
| *[z. B. Weekly Meeting]* | Fortschrittsbesprechung | wöchentlich |
|
||
| *[z. B. E-Mail]* | Kommunikation mit Betreuer| bei Bedarf |
|
||
|
||
<!-- TODO: Entscheidungswege und Eskalationspfade ergänzen -->
|
||
|
||
---
|
||
|
||
# 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: ____________
|
||
|
||
**Projektleiter:in:** ________________________________________ Datum: ____________
|
||
|
||
**Teammitglied:** ________________________________________ Datum: ____________
|
||
|
||
**Teammitglied:** ________________________________________ Datum: ____________
|
||
|
||
**Teammitglied:** ________________________________________ Datum: ____________ |