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
3.2 KiB
3.2 KiB
Traceability-Matrix
Prinzip
Die Traceability-Matrix stellt die Rueckverfolgbarkeit von der Anforderung bis zum Test sicher:
System-Anforderung → Software-Anforderung → Architektur-Element → Implementierung (MR/Datei) → Testfall → Testergebnis
Jede Ebene muss bidirektional verfolgbar sein:
- Vorwaerts: Anforderung → wurde sie implementiert und getestet?
- Rueckwaerts: Testfall → welche Anforderung verifiziert er?
Tabellenstruktur
| Sys-Req | SW-Req | ASIL | Arch-Element | Implementierung | Testfall | Test-Ergebnis | Status |
|---|---|---|---|---|---|---|---|
| SYR-001 | SWR-010 | B | MOD-Timer | MR !23, timer.c | TC-010 | Pass (v1.2) | Vollstaendig |
| SYR-001 | SWR-011 | B | MOD-Timer | MR !23, timer.c | TC-011 | Pass (v1.2) | Vollstaendig |
| SYR-002 | SWR-020 | A | MOD-CAN | MR !31, can_driver.c | TC-020 | Pass (v1.2) | Vollstaendig |
| SYR-003 | SWR-030 | B | MOD-Watchdog | — | — | — | Offen |
| — | SWR-040 | QM | MOD-Diag | MR !35, diag.c | TC-040 | Fail (v1.1) | Finding offen |
Spalten-Erklaerung
| Spalte | Beschreibung |
|---|---|
| Sys-Req | System-Anforderungs-ID (GitLab Issue mit Label req::system) |
| SW-Req | Software-Anforderungs-ID (GitLab Issue mit Label req::software) |
| ASIL | Zugewiesener ASIL-Level |
| Arch-Element | Architektur-Modul oder -Komponente |
| Implementierung | Merge Request und/oder Datei |
| Testfall | Testfall-ID (GitLab Issue mit Label test::*) |
| Test-Ergebnis | Pass/Fail mit Version/Datum |
| Status | Vollstaendig / Offen / Finding offen |
Lueckenanalyse
Die Matrix macht Luecken sichtbar:
- Anforderung ohne Test: Zeile ohne Testfall-Eintrag → Test fehlt
- Anforderung ohne Implementierung: Zeile ohne MR → nicht implementiert
- Test ohne Anforderung: Testfall der keiner Anforderung zugeordnet ist → ueberpruefen
- Fail ohne Finding: Fehlgeschlagener Test ohne dokumentiertes Finding → nacharbeiten
Automatische Generierung aus GitLab
Diese Matrix kann aus GitLab-Issues automatisch generiert werden:
- Python-Skript liest ueber GitLab API alle Issues mit
req::*-Labels - Folgt Issue-Links zu Architektur-Issues, MRs und Test-Issues
- Liest CI-Pipeline-Ergebnisse (JUnit-XML) fuer Testergebnisse
- Erzeugt die Matrix als Markdown-Tabelle oder CSV
Voraussetzung: Issues sind korrekt verlinkt und gelabelt (siehe gitlab-aspice-setup.md).
Ausgabe-Formate:
- Markdown (fuer Wiki / Dokumentation)
- CSV (fuer Import in Kundensysteme)
- HTML (fuer Reporting)
Ein Beispiel-Skript liegt unter tools/traceability-report.py im Projekt-Repository.
Die aktuelle Traceability-Matrix wird bei jedem Release aktualisiert und im Wiki abgelegt.