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