8.9 KiB

Raw Blame History

title	author	version	toc	header-includes
Project Charter	Team A	1.0	yes	\usepackage{fancyhdr} \pagestyle{fancy} \fancyhead[L]{Team A} \fancyhead[C]{Project Charter} \fancyhead[R]{Version 1.0} \fancyfoot[C]{\thepage\ / \pageref{LastPage}} \usepackage{lastpage}

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?

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

Noch auszufüllen

Stakeholder

Auftraggeber (extern/intern)

Rolle	Name	Verantwortlichkeit
Auftraggeber / Betreuer	[Dozent/in]	Anforderungen, Abnahme, Bewertung

Regulatorisch

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:

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

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

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: ____________

8.9 KiB Raw Blame History Unescape Escape