Stefan Lohmaier
8ea3f3d8f4
The 25 files under templates-de/ lived in ~/ownCloud/Persönlich/slohmaier.com/vorlagen/
with no version control. They are the German-language counterpart of the
templates renamed to English in 247b831 — this repo already describes itself as
holding the ASPICE 4.0 / ISO 26262 methodology, templates and tools, so a
second home for templates would have been a duplicate.
Structure preserved as found (business/, engineering/, projekt/, qualitaet/).
No file renamed, no template content changed.
Not moved: vorlagen/slohmaier-doc-template.docx was byte-identical (MD5
31b2d0748eadf0314babf469725ee0b1) to templates-word/slohmaier-doc-template.docx
already in this repo.
Path references fixed in templates-de/README.md, which pointed at locations
that no longer exist: the ownCloud cp examples now clone from Gitea, the
generator script name follows the vorlagen/ -> templates/ rename
(generate_word_vorlagen.sh -> generate_word_templates.sh), the edit workflow
names templates/ and templates-de/ instead of the removed ownCloud copy, and
the master template is referenced at ../templates-word/.
86 lines
4.3 KiB
Markdown
86 lines
4.3 KiB
Markdown
# 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.*
|