Initial commit: slohmaier Dev Process v1.0

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

vorlagen/Traceability-Matrix-vorlage.md

@@ -0,0 +1,67 @@
+# 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.*