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
68 lines
3.2 KiB
Markdown
68 lines
3.2 KiB
Markdown
# 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:
|
|
|
|
1. Python-Skript liest ueber GitLab API alle Issues mit `req::*`-Labels
|
|
2. Folgt Issue-Links zu Architektur-Issues, MRs und Test-Issues
|
|
3. Liest CI-Pipeline-Ergebnisse (JUnit-XML) fuer Testergebnisse
|
|
4. 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.*
|