# 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 (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.

### 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.*