# Projektplan (PM-Plan) | Feld | Wert | |-----------------|-------------------------------| | Projekt | [Projektname] | | Datum | [YYYY-MM-DD] | | Version | [1.0] | | Status | [Entwurf / Freigegeben] | | Bezug | PID Version [X.Y] | --- ## 1. Projektphasen und Meilensteine | Phase | Start | Ende | Meilenstein | |------------------------|-------------|-------------|--------------------------------------| | Anforderungsanalyse | [Datum] | [Datum] | Requirements Complete | | Architektur | [Datum] | [Datum] | Architecture Complete | | Implementierung | [Datum] | [Datum] | Code Complete | | Integration & Test | [Datum] | [Datum] | Integration Complete | | Verifikation | [Datum] | [Datum] | Verification Complete | | Release | [Datum] | [Datum] | Release | Phasen koennen ueberlappen (iterativ). Meilenstein-Kriterien sind im QA-Plan definiert. ## 2. Ressourcen und Rollen | Rolle | Person | Verfuegbarkeit | Aufgaben | |--------------------------|---------------------|-------------------|---------------------------------| | Projektleiter / Entwickler | Stefan Lohmaier | [X Tage/Woche] | Planung, Implementierung, Tests | | Reviewer | [Name / extern] | [nach Bedarf] | Code- und Dokument-Reviews | | QA | [Name / extern] | [nach Bedarf] | QA-Audits, Prozessueberwachung | | Auftraggeber | [Name] | [nach Bedarf] | Anforderungsklaerung, Abnahme | ## 3. Kommunikationsplan | Aktivitaet | Haeufigkeit | Teilnehmer | Medium | |--------------------------|--------------|---------------------------|---------------------| | Status-Update | [Woechentlich] | Auftraggeber, PL | E-Mail / Call | | Technische Abstimmung | [Nach Bedarf] | Entwickler, Auftraggeber | Call / GitLab Issue | | Meilenstein-Review | [Pro Phase] | Alle Beteiligten | Meeting | | QA-Report | [Pro Phase] | QA, PL, Auftraggeber | Dokument (Wiki) | ## 4. Eskalationspfad | Stufe | Situation | Eskalation an | Frist | |-------|----------------------------------------------|----------------------------|-------------| | 1 | Technische Blockade | Auftraggeber (technisch) | 2 Arbeitstage | | 2 | Terminverschiebung > 1 Woche | Projektverantwortlicher | 1 Arbeitstag | | 3 | Scope-Aenderung oder Safety-Concern | Management Auftraggeber | sofort | ## 5. Aenderungsmanagement Aenderungen an Anforderungen, Scope oder Zeitplan werden als Change Request behandelt: 1. Change Request als GitLab Issue erfassen (Label: `change-request`) 2. Auswirkungsanalyse: betroffene Anforderungen, Code, Tests, Zeitplan 3. Bewertung und Freigabe durch Auftraggeber 4. Bei Freigabe: betroffene Work Products aktualisieren, Traceability nachfuehren 5. Dokumentation der Aenderung im Issue (Begruendung, Auswirkung, Entscheidung) Keine Aenderung ohne dokumentierte Freigabe. ## 6. Risikomanagement ### Vorgehen - Initiale Risiken im PID erfasst - Risikoliste wird pro Meilenstein-Review aktualisiert - Neue Risiken werden als GitLab Issues erfasst (Label: `risk`) - Jedes Risiko hat: Beschreibung, Wahrscheinlichkeit, Auswirkung, Massnahme, Verantwortlicher ### Risiko-Bewertung | Wahrscheinlichkeit / Auswirkung | Niedrig | Mittel | Hoch | |----------------------------------|---------|---------|---------| | Hoch | Mittel | Hoch | Kritisch| | Mittel | Niedrig | Mittel | Hoch | | Niedrig | Niedrig | Niedrig | Mittel | Kritische Risiken werden sofort eskaliert (siehe Eskalationspfad Stufe 3). --- *Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*