demo-epb/docs/plans-md/CM-Plan.md

doc-id, version, status, datum

doc-id	version	status	datum
SLM-EPB-CM-001	1.0	Freigegeben	2026-05-12

Configuration Management Plan (CM-Plan)

Feld	Wert
Projekt	demo-epb
Dokument-ID	SLM-EPB-CM-001
Version	1.0
Status	Freigegeben
Datum	2026-05-12
Norm	ASPICE SUP.8 + ISO 26262-8 §7

---

1. Zweck

Beschreibt, wie Konfigurations-Items identifiziert, versioniert, freigegeben und kontrolliert geaendert werden.

2. Configuration Items (CIs)

Folgende Artefakte stehen unter Konfigurationskontrolle:

Typ	Pfad	Versionierung
Source-Code	src/**/*.{c,h}	Git
Tests	tests/**	Git
Anforderungen	reqs/{sys,swe}/*.md	Git + Doorstop-Item-Hash
Architektur	arch/{sys,swe}/*.md	Git + Doorstop-Item-Hash
Safety Goals	safety/sg/*.md	Git
Plaene (Word)	docs/plaene/*.docx	Git + Dokument-Versionsblock
Safety-Doku (Word)	docs/safety/*.docx	Git
Manuals (Word)	docs/manuals/*.docx	Git
Reviews + NCs	docs/reviews/, docs/non-conformities/	Git
MISRA-Records	misra/records/*.docx	Git
CI-Konfiguration	.gitea/workflows/*.yml	Git
Build-Definition	Makefile, Doxyfile	Git
Tools	tools/*.py	Git

3. Repository-Struktur

• Remote: https://gitea.slohmaier.com/slohmaier/demo-epb
• Branch main: stabil, immer freigegebener Stand
• Branch develop: aktueller Entwicklungsstand
• Feature-Branches: feature/SWE-XXX-...
• Bugfix-Branches: bugfix/<issue>-...
• Release-Branches: release/vX.Y (nur bei Real-Projekt; Demo: direkt von main)

4. Baselines

Eine Baseline ist ein eingefrorener, freigegebener Stand. Baselines werden durch Git-Tags gesetzt.

Baseline-Typ	Tag-Schema	Wann
Requirements Baseline	req-vX.Y	Nach Anforderungs-Freigabe
Architecture Baseline	arch-vX.Y	Nach Architektur-Review
Release Baseline	vX.Y.Z	Bei produktiver Freigabe
Internal Snapshot	snap-YYYY-MM-DD	Bei wichtigen Zwischenstaenden

Jeder Tag triggert (bei vX.Y.Z) den Release-Workflow, der ein Bundle erzeugt.

5. Versions-Schema

Artefakt	Schema
Software-Release	Semantic Versioning MAJOR.MINOR.PATCH
Anforderungen	Doorstop-Level X.Y + Datum
Architektur	Doorstop-Level X.Y + Datum
Word-Dokumente	MAJOR.MINOR im Dokument-Header

6. Change Control

Aenderungen an Configuration Items erfolgen ueber:

1. Trivial-Aenderung (Tippfehler, Kommentare): direkt im Branch, PR mit 1 Approval
2. Normal-Aenderung (Feature, Bugfix): Feature-Branch, PR mit Reviews je nach ASIL
3. Major-Aenderung (Architektur, Sicherheits-Konzept): Change Request + Reviewer-Quorum

Asil	Reviewer-Mindestanzahl
QM	1
ASIL-A/B	1
ASIL-C	2 (mind. 1 Technical Reviewer)
ASIL-D	2 Technical Reviewer + Safety Manager

Reviews werden in docs/reviews/REV-XXX.docx dokumentiert.

7. Release-Prozess

1. Alle PRs in main gemerged
2. Branch protected, alle CI-Checks gruen
3. Release-Notes-Entwurf im PR vorbereitet
4. Tag setzen: git tag -a vX.Y.Z -m "..."
5. Push: git push origin vX.Y.Z
6. Release-Workflow laeuft (.gitea/workflows/release.yml):
   - Build + Tests + Coverage
   - Traceability + Diagrams + API-Doc
   - Word-Dokumente bundlen
   - Source + Artefakt-Archive packen
   - Gitea-Release anlegen
7. Release manuell pruefen (Bundle herunterladen, sichten)
8. Release als "stable" markieren

8. Aufbewahrung

Artefakt	Aufbewahrungsdauer
Git-Repository	Unbegrenzt (Gitea + Backup)
Release-Bundles	10 Jahre nach Produkt-EOL
Reviews + NCs	10 Jahre nach Produkt-EOL
MISRA-Records	10 Jahre nach Produkt-EOL
CI-Artefakte (kurzlebig)	90 Tage (in Gitea-Artifacts)

ISO 26262 fordert 10 Jahre nach End-of-Production-Life (Annahme).

9. Verifikation

Alle Pull Requests laufen durch:

• doorstop-aequivalenter Traceability-Check (tools/traceability.py check)
• Build + Unit-Tests
• Static Analysis + MISRA-Check
• Coverage-Messung

Erst nach Approval und CI-Gruen kann der Merge nach main erfolgen.

10. Verantwortlichkeiten

Rolle	Aufgabe
Configuration Mgr	Pflege dieses CM-Plans, Repo-Hygiene, Baselines
Entwickler	Korrekte Branch-Strategie, sinnvolle Commit-Msg
Reviewer	Pruefung vor Merge, Audit-Trail
Project Owner	Release-Freigabe

11. Aenderungshistorie

Version	Datum	Aenderung	Autor
1.0	2026-05-12	Erstfreigabe	S. Lohmaier