8.0 KiB
8.0 KiB
| title | subtitle | geometry | linestretch | papersize | |||
|---|---|---|---|---|---|---|---|
| Project Charter | Software Engineering 1 |
|
1.2 | a4 |
Project Charter
Software Engineering 1
| Feld | Wert |
|---|---|
| Projektname | |
| 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 | 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
| Bezeichnung | Details |
|---|---|
| Projektleitung | [Name] (Matrikel: [Nr.]) Schwerpunkt: [z. B. Backend] |
| Entwicklung 1 | [Name] (Matrikel: [Nr.]) Schwerpunkt: [z. B. Frontend] |
| Entwicklung 2 | [Name] (Matrikel: [Nr.]) Schwerpunkt: [z. B. Datenbank] |
| QA / Testing | [Name] (Matrikel: [Nr.]) Schwerpunkt: [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 |
|---|---|
| Frontend | [z. B. React, Vue, HTML/CSS] Begründung: [Begründung] |
| Backend | [z. B. Spring Boot, Node.js, Django] Begründung: [Begründung] |
| Datenbank | [z. B. PostgreSQL, MySQL, MongoDB] Begründung: [Begründung] |
| Versionskontrolle | Git / GitHub (Standard, Kollaboration) |
| Projektmanagement | [z. B. GitHub Projects, Trello] Begründung: [Begründung] |
| CI/CD | [z. B. GitHub Actions] Begründung: [Begründung] |
| Kommunikation | [z. B. Discord, Teams] Begründung: [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 | 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 | 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
9. Ressourcen und Constraints
9.1 Ressourcen
- Teamgröße: [Anzahl] Personen
- Verfügbare Zeit pro Person: ca. 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:
- Alle Muss-Anforderungen (Priorität: Hoch) vollständig implementiert sind
- Alle Unit- und Integrationstests bestehen
- Die Anwendung lauffähig demonstriert werden kann
- Die technische Dokumentation vollständig vorliegt
- 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.
Betreuer/in: ________________________________________ Datum: ____________
Projektleiter:in: ________________________________________ Datum: ____________
Teammitglied: ________________________________________ Datum: ____________
Teammitglied: ________________________________________ Datum: ____________
Teammitglied: ________________________________________ Datum: ____________
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.