SE1_Gruppe_A/project-charter.md

259 lines
8.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# Project Charter
## Software Engineering 1
---
| | |
|---|---|
| **Projektname** | *[Projektname eintragen]* |
| **Version** | 1.0 |
| **Status** | Entwurf |
| **Datum** | *[Datum]* |
| **Hochschule / Kurs** | *[Hochschule] Software Engineering 1* |
---
## 1. Projektübersicht
### 1.1 Projektzweck
*Kurze Beschreibung des Projekts (24 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.
### 1.2 Projekthintergrund
*Warum wird dieses Projekt durchgeführt? Welcher Bedarf oder welche Anforderung liegt zugrunde?*
---
## 2. Ziele und Nicht-Ziele
### 2.1 Projektziele
| Nr. | Ziel | Messbare Erfolgskriterien |
|-----|------|--------------------------|
| Z-01 | *[Ziel 1]* | *[Kriterium]* |
| Z-02 | *[Ziel 2]* | *[Kriterium]* |
| Z-03 | *[Ziel 3]* | *[Kriterium]* |
### 2.2 Nicht-Ziele (Out of Scope)
Die folgenden Punkte sind **explizit nicht** Teil dieses Projekts:
- *[Was wird bewusst ausgeschlossen?]*
- *[z. B. Mobile App, Admin-Backend, Mehrsprachigkeit]*
---
## 3. Stakeholder
| Rolle | Name | Verantwortlichkeit |
|-------|------|--------------------|
| Auftraggeber / Betreuer | *[Dozent/in]* | Anforderungen, Abnahme, Bewertung |
| Projektleiter:in | *[Name]* | Koordination, Planung, Kommunikation |
| Entwickler:in | *[Name]* | Implementierung, Testing |
| Entwickler:in | *[Name]* | Implementierung, Dokumentation |
| Entwickler:in | *[Name]* | Implementierung, Architektur |
| *(weitere)* | *[Name]* | *[Rolle]* |
---
## 4. Projektteam und Rollen
### 4.1 Teamstruktur
| Teammitglied | Matrikelnummer | Primäre Rolle | Technischer Schwerpunkt |
|---|---|---|---|
| *[Name]* | *[Nr.]* | Projektleitung | *[z. B. Backend]* |
| *[Name]* | *[Nr.]* | Entwicklung | *[z. B. Frontend]* |
| *[Name]* | *[Nr.]* | Entwicklung | *[z. B. Datenbank]* |
| *[Name]* | *[Nr.]* | QA / Testing | *[z. B. Testing, CI/CD]* |
### 4.2 Kommunikation
| 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 |
---
## 5. Anforderungen (Überblick)
### 5.1 Funktionale Anforderungen
| ID | Anforderung | Priorität |
|----|-------------|-----------|
| FA-01 | *[Funktionale Anforderung 1]* | Hoch |
| FA-02 | *[Funktionale Anforderung 2]* | Hoch |
| FA-03 | *[Funktionale Anforderung 3]* | Mittel |
| FA-04 | *[Funktionale Anforderung 4]* | Niedrig |
### 5.2 Nicht-funktionale Anforderungen
| ID | Anforderung | Kategorie |
|----|-------------|-----------|
| NFA-01 | *[z. B. Antwortzeit < 2 Sekunden]* | Performance |
| NFA-02 | *[z. B. Responsives Design]* | Usability |
| NFA-03 | *[z. B. HTTPS, Passwort-Hashing]* | Sicherheit |
| NFA-04 | *[z. B. Deployment via Docker]* | Betrieb |
---
## 6. Technologie-Stack
| Bereich | Technologie / Tool | Begründung |
|---------|--------------------|------------|
| 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]* |
---
## 7. Zeitplan und Meilensteine
### 7.1 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
```
### 7.2 Meilensteinplan
| Meilenstein | Beschreibung | Geplantes 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 |
---
## 8. Risikomanagement
| ID | Risiko | Wahrscheinlichkeit | Auswirkung | Gegenmaßnahme |
|----|--------|--------------------|------------|----------------|
| R-01 | Ausfall eines Teammitglieds | Mittel | Hoch | Wissensteilung, Pair Programming |
| R-02 | Technische Komplexität unterschätzt | Mittel | Hoch | Frühzeitige Spikes, Scope-Reduktion |
| R-03 | Anforderungsänderungen | Niedrig | Mittel | Klare Change-Request-Prozesse |
| R-04 | Integrationsprobleme | Mittel | Mittel | Frühzeitige Integrationstests |
| R-05 | *[Projektspezifisches Risiko]* | *[W]* | *[A]* | *[Maßnahme]* |
**Legende:** Wahrscheinlichkeit / Auswirkung: Hoch / Mittel / Niedrig
---
## 9. Ressourcen und Constraints
### 9.1 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]*
### 9.2 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]*
---
## 10. Definition of Done (DoD)
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
---
## 11. 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
---
## 12. Unterschriften und Genehmigung
Mit ihrer Unterschrift bestätigen alle Beteiligten, dass sie den Inhalt dieses Project Charters gelesen haben und damit einverstanden sind.
| Rolle | Name | Unterschrift | Datum |
|-------|------|--------------|-------|
| Betreuer/in | | | |
| Projektleiter:in | | | |
| Teammitglied | | | |
| Teammitglied | | | |
| Teammitglied | | | |
---
## Anhang
### A. Glossar
| Begriff | Definition |
|---------|------------|
| MVP | Minimum Viable Product minimale, lauffähige Version des Produkts |
| Spike | Zeitlich begrenzter Forschungs- / Lernaufwand zur Risikoreduktion |
| DoD | Definition of Done Kriterien, wann ein Feature als abgeschlossen gilt |
| *[Begriff]* | *[Definition]* |
### B. Referenzen
- Vorlesungsunterlagen Software Engineering 1, *[Hochschule]*, *[Jahr]*
- *[weitere Quellen, Literatur, Standards]*
### C. Änderungshistorie
| Version | Datum | Autor | Änderung |
|---------|-------|-------|----------|
| 1.0 | *[Datum]* | *[Name]* | Initiale Erstellung |
---
*Dieses Dokument wurde im Rahmen des Moduls Software Engineering 1 erstellt.*