The 25 files under templates-de/ lived in ~/ownCloud/Persönlich/slohmaier.com/vorlagen/
with no version control. They are the German-language counterpart of the
templates renamed to English in 247b831 — this repo already describes itself as
holding the ASPICE 4.0 / ISO 26262 methodology, templates and tools, so a
second home for templates would have been a duplicate.
Structure preserved as found (business/, engineering/, projekt/, qualitaet/).
No file renamed, no template content changed.
Not moved: vorlagen/slohmaier-doc-template.docx was byte-identical (MD5
31b2d0748eadf0314babf469725ee0b1) to templates-word/slohmaier-doc-template.docx
already in this repo.
Path references fixed in templates-de/README.md, which pointed at locations
that no longer exist: the ownCloud cp examples now clone from Gitea, the
generator script name follows the vorlagen/ -> templates/ rename
(generate_word_vorlagen.sh -> generate_word_templates.sh), the edit workflow
names templates/ and templates-de/ instead of the removed ownCloud copy, and
the master template is referenced at ../templates-word/.
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.