7.9 KiB

Raw Blame History

Project Charter

Software Engineering 1


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

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.

7.9 KiB Raw Blame History Unescape Escape