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/.
4.3 KiB
4.3 KiB
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:
- Change Request als GitLab Issue erfassen (Label:
change-request) - Auswirkungsanalyse: betroffene Anforderungen, Code, Tests, Zeitplan
- Bewertung und Freigabe durch Auftraggeber
- Bei Freigabe: betroffene Work Products aktualisieren, Traceability nachfuehren
- 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.