Stefan Lohmaier
294b9956f9
Validate / build-test (macos-latest) (push) Failing after 2s
Validate / build-test (windows-latest) (push) Failing after 15s
Validate / build-test (ubuntu-latest) (push) Failing after 15s
Validate / reports (push) Has been skipped
Release / release (push) Successful in 57s
3 neue Plaene: - Project Manual: Master-Wegweiser fuer neue Projektmitglieder, Lese-Reihenfolge, Rollen, Lebenszyklus, Dokumenten-Landschaft - Configuration Management Plan: CIs, Baselines, Change Control, Release-Prozess, Aufbewahrungsfristen (ASPICE SUP.8) - Risk Management Plan: Projekt-Risiken (abgegrenzt von HARA), Klassifikations-Skala, Risiko-Register, Eskalations-Pfad Landing-Page (Startseite): - tools/generate_landing_page.py erzeugt build/index.html - Standalone-HTML, oeffnet im Browser ohne Server - KPI-Cards: SG/SYS/SWE/Arch/Komponenten/Tests-Counts - Sektionen mit Links: Plaene, Safety, Manuals, Audit, Reports, Diagramme, Source-Code, externe Links - Existenz-Check: nicht-generierte Reports werden grau markiert - Im Release-Bundle als index.html ganz oben CI-Integration: - validate.yml: neuer Step "Landing-Page" + Upload als Artefakt - release.yml: Landing-Page generieren + ins Bundle einbauen, zusaetzlich Source-Code im Bundle (war vorher nur als tar.gz) Makefile: neues Target `make landing-page`
149 lines
6.5 KiB
Markdown
149 lines
6.5 KiB
Markdown
---
|
|
doc-id: SLM-EPB-CM-001
|
|
version: 1.0
|
|
status: Freigegeben
|
|
datum: 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 |
|