Stefan Lohmaier
6e458ae76f
ASPICE 4.0 / ISO 26262 Entwicklungsprozess fuer kleine Teams. Inhalte: - README mit hybrider Format-Strategie (Word + Markdown) - Toolstack (Gitea, Doorstop, Cppcheck, gcov, CppUTest, pandoc) - Markdown-Vorlagen fuer Requirements + Architektur (SA, SWA) - Markdown-Vorlagen fuer formelle Dokumente (PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan, Reviews, Non-Conformity, MISRA Permits/Records) - Word-Master-Template (slohmaier-doc-template.docx) mit ISO-9001- konformer Document Control, Formatvorlagen, Auto-Verzeichnissen - Build-Scripts (build_word_template.py, generate_word_vorlagen.sh) - gitea-aspice-setup.md, V-Modell-Infografik
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.*
|