diff --git a/README.md b/README.md index 748ecda..3271eee 100644 --- a/README.md +++ b/README.md @@ -177,8 +177,9 @@ Runs on every push and PR: | `toolstack/toolstack.md` | Complete tool stack | | `gitea-aspice-setup.md` | Setting up Gitea for ASPICE | | `dev-process-schaubild.html` | V-model infographic | -| `templates/` | Markdown templates (source of truth) | +| `templates/` | Markdown templates, English (source of truth) | | `templates-word/` | Generated Word templates + master template `slohmaier-doc-template.docx` | +| `templates-de/` | The same templates in German, Markdown + Word. Moved here from ownCloud on 2026-07-31; see `templates-de/README.md`. Change a template and both language sets have to follow. | | `tools/build_word_template.py` | Builds the neutral Word master template with styles, cover page, document control | | `tools/generate_word_templates.sh` | Builds the `.docx` versions from the `.md` templates via pandoc | diff --git a/templates-de/README.md b/templates-de/README.md new file mode 100644 index 0000000..fcd64dc --- /dev/null +++ b/templates-de/README.md @@ -0,0 +1,104 @@ +# templates-de — Deutschsprachige slohmaier Dokument-Vorlagen + +Zentrale Sammlung wiederverwendbarer Dokument-Vorlagen. Sowohl Word (für formelle +Freigabe / ISO-9001-Audits / Kunden-Lieferung) als auch Markdown (für lebendige +Engineering-Artefakte mit Git-Diff und Traceability). + +> **Herkunft (2026-07-31):** Dieser Ordner lag bis dahin als `vorlagen/` im +> ownCloud-Share `~/ownCloud/Persönlich/slohmaier.com/` — ohne Versionskontrolle. +> Er ist hierher gezogen, weil dieses Repo laut eigener Beschreibung bereits +> „ASPICE 4.0 / ISO 26262 Methodik, **Vorlagen**, Tools" hält; ein zweiter +> Vorlagen-Ort wäre ein Duplikat gewesen. +> +> **Verhältnis zu `templates/` und `templates-word/`:** Das sind dieselben +> Vorlagen, seit Commit `247b831` ins Englische übersetzt und umbenannt +> (`*-vorlage` → `*-template`). `templates-de/` ist der deutschsprachige +> Stand. Beide sind gültig — wähle die Sprache, in der das Dokument geliefert +> wird. Wer eine Vorlage inhaltlich ändert, muss beide Sprachstände nachziehen. +> +> `slohmaier-doc-template.docx` ist **nicht** mit umgezogen: die ownCloud-Datei +> war byte-identisch (MD5 `31b2d074…`) mit dem bereits im Repo liegenden +> `templates-word/slohmaier-doc-template.docx`. + +## Struktur + +``` +templates-de/ +├── business/ Vertrieb + Kommunikation +│ ├── angebot-vorlage.{md,docx} +│ └── angebot-beispiel.html +│ +├── projekt/ Projektplanung (für jedes neue Projekt) +│ ├── PID-vorlage.{md,docx} Project Initiation Document +│ ├── PM-Plan-vorlage.{md,docx} Projektmanagement-Plan +│ ├── QA-Plan-vorlage.{md,docx} Qualitätssicherungs-Plan +│ ├── SWE-Plan-vorlage.{md,docx} Software Development Plan +│ └── Test-Plan-vorlage.{md,docx} Teststrategie +│ +├── qualitaet/ QM / Audit / Compliance +│ ├── Review-Protokoll-vorlage.{md,docx} +│ ├── Non-Conformity-vorlage.{md,docx} +│ ├── MISRA-Deviation-Permit-vorlage.{md,docx} +│ └── MISRA-Deviation-Record-vorlage.{md,docx} +│ +└── engineering/ Anforderungen + Architektur (nur Markdown) + ├── SA-vorlage.md System-Architektur-Element + ├── SWA-vorlage.md Software-Architektur-Element + └── Traceability-Matrix-vorlage.md +``` + +## Master-Word-Template + +`../templates-word/slohmaier-doc-template.docx` ist die Grundlage aller +Word-Vorlagen. Enthält: + +- Deckblatt (Projekt, Dokument-ID, Version, Klassifikation) +- Document Control (Freigaben, Änderungshistorie, Verteiler) — ISO-9001-konform +- Auto-Verzeichnisse (Inhalt, Abbildungen, Tabellen, Abkürzungen) +- Formatvorlagen: H1–H4, Body, Code, Note, Warning, Requirement +- Header/Footer mit Projekt, Dokument-ID, Klassifikation, Seitennummer + +Bei neuem formellem Dokument: **Master-Template kopieren → ausfüllen.** Oder die +fertigen `*-vorlage.docx` als Startpunkt nehmen, die schon den passenden Inhalt +strukturiert haben. + +## Word vs Markdown — welches Format wann? + +| Verwendung | Format | +|-------------------------------------------|-----------| +| Freigabe, Unterschrift, Audit-Lieferung | **Word** | +| Lebendige Anforderungen, Doorstop-Diff | **Markdown** | +| Architektur mit PlantUML, in Gitea geprüft| **Markdown** | +| Kunden-PDF aus Engineering-Markdown | Markdown + pandoc-Export | + +## Source-of-Truth & Neugenerierung + +Die Word-Vorlagen werden aus den Markdown-Vorlagen per pandoc generiert. Der +Source liegt in **diesem** Repo — seit dem Umzug gibt es keine ownCloud-Kopie +mehr, aus der man nachziehen müsste. + +- **Methodik-Repo:** https://gitea.slohmaier.com/slohmaier/dev-process +- **Lokal:** `~/git/dev-process/` +- **Generieren (englischer Stand):** `python3 tools/build_word_template.py && bash tools/generate_word_templates.sh` + +Wenn du die Vorlagen anpasst: +1. Markdown editieren — `templates/.md` (EN) bzw. `templates-de//.md` (DE) +2. Word-Versionen mit den Skripten oben neu erzeugen +3. Beide Versionen committen + pushen + +> Die Generator-Skripte in `tools/` erzeugen bislang nur den englischen Stand +> nach `templates-word/`. Die `.docx` unter `templates-de/` sind der zuletzt +> von Hand erzeugte deutsche Stand und werden noch nicht automatisch gebaut. + +## Einsatz im neuen Projekt + +```bash +# Beispiel-Workflow +git clone https://gitea.slohmaier.com/slohmaier/dev-process.git ~/git/dev-process +mkdir mein-neues-projekt && cd mein-neues-projekt && mkdir -p docs +cp ~/git/dev-process/templates-de/projekt/PID-vorlage.docx docs/PID.docx +cp ~/git/dev-process/templates-de/projekt/SWE-Plan-vorlage.docx docs/SWE-Plan.docx +# ... ausfüllen mit Projekt-Inhalt +``` + +Beispiel eines vollständig angewandten Templates: https://gitea.slohmaier.com/slohmaier/demo-epb diff --git a/templates-de/business/angebot-beispiel.html b/templates-de/business/angebot-beispiel.html new file mode 100644 index 0000000..653255b --- /dev/null +++ b/templates-de/business/angebot-beispiel.html @@ -0,0 +1,144 @@ + + + + + + Angebot: Accessibility Audit – slohmaier Engineering + + + + + + +
+ +

Angebot: Accessibility Audit

+ +

+ Datum: 03.04.2026    + Version: 1.0
+ Projekt: Accessibility Review – DemoApp v2.3
+ Auftraggeber: Acme GmbH, Berlin +

+ +
+ +

Zusammenfassung

+

Dieses Angebot beschreibt den Umfang und die Konditionen für einen Accessibility Audit der Windows-Desktop-Anwendung DemoApp v2.3, mit Fokus auf NVDA-Screenreader-Kompatibilität.

+ +

Inhalt

+ +

1. Ziel

+

Prüfung der Anwendung auf Bedienbarkeit mit NVDA (Windows) sowie Identifikation und Beschreibung konkreter Accessibility-Mängel mit Handlungsempfehlungen.

+ +

2. Umfang

+
    +
  • Vollständiger Durchgang aller Hauptdialoge und Workflows mit NVDA
    • +
  • Prüfung auf UIA-Baumstruktur und korrekte Rollen/Namen/Beschreibungen
    • +
  • Dokumentation aller Befunde mit Reproduktionsschritten und Schweregrad
    • +
  • Priorisierte Handlungsempfehlungen
    • +
+

Nicht enthalten: Implementierung von Korrekturen, Regressionstesting nach Fixes.

+ +

3. Anforderungen

+ + + + + + + + + + + +
Nr.AnforderungPriorität
1Vollständige NVDA-Bedienbarkeit aller WorkflowsMuss
2UIA-konforme Benennung aller SteuerelementeMuss
3Tastaturnavigation ohne MausMuss
4Logische FokusreihenfolgeSoll
5Kontraste mind. WCAG 2.1 AASoll
+ +

4. Vorgehen

+
    +
  1. Einrichtung der Testumgebung (Windows 11, NVDA 2024.4)
    2. +
  2. Manueller Test aller Hauptdialoge und Workflows
    3. +
  3. UIA-Dump-Analyse mit dumpUIA
    4. +
  4. Dokumentation der Befunde
    5. +
  5. Übergabe Auditbericht als PDF
    6. +
+

Geschätzte Dauer: 3 Werktage

+ +

5. Offene Punkte

+
    +
  • Übergabe Testversion der Anwendung
    • +
  • Zugang zu Testdaten für repräsentative Workflows
    • +
+ +

6. Lieferergebnis

+

Auditbericht (PDF) mit:

+
    +
  • Zusammenfassung und Gesamtbewertung
    • +
  • Vollständige Befundliste mit Schweregrad, Screenshot, Reproduktionsschritten
    • +
  • Priorisierte Handlungsempfehlungen
    • +
+ +
+ +

Konditionen

+

+ Tagessatz: auf Anfrage
+ Zahlungsziel: 14 Tage nach Rechnungsstellung
+ Gültig bis: 17.04.2026 +

+ +
+ +

Stefan Lohmaier
+ slohmaier.com · stefan@slohmaier.de

+ + + diff --git a/templates-de/business/angebot-vorlage.docx b/templates-de/business/angebot-vorlage.docx new file mode 100644 index 0000000..5f1d1fa Binary files /dev/null and b/templates-de/business/angebot-vorlage.docx differ diff --git a/templates-de/business/angebot-vorlage.md b/templates-de/business/angebot-vorlage.md new file mode 100644 index 0000000..8e6ff18 --- /dev/null +++ b/templates-de/business/angebot-vorlage.md @@ -0,0 +1,76 @@ + + + + + + + +--- + +# Angebot: {{ Titel }} + +**Datum:** {{ datum }} +**Version:** 1.0 +**Projekt:** {{ projektname }} +**Auftraggeber:** {{ auftraggeber }} + +--- + +## Zusammenfassung + +{{ Kurze Beschreibung was angeboten wird }} + +--- + +## Inhalt + +### 1. Ziel + +{{ Was soll erreicht werden? }} + +### 2. Umfang + +{{ Was ist enthalten? Aufzaehlung der Leistungen }} + +**Nicht enthalten:** {{ Was ist explizit ausgeschlossen? }} + +### 3. Anforderungen + +| Nr. | Anforderung | Prioritaet | +|-----|-------------|------------| +| 1 | ... | Muss | +| 2 | ... | Soll | +| 3 | ... | Kann | + +### 4. Vorgehen + +1. {{ Schritt 1 }} +2. {{ Schritt 2 }} +3. {{ Schritt 3 }} + +Geschaetzte Dauer: **{{ Dauer }}** + +### 5. Offene Punkte + +- [ ] {{ Voraussetzung 1 }} +- [ ] {{ Voraussetzung 2 }} + +### 6. Lieferergebnis + +{{ Was wird am Ende geliefert? Format, Umfang }} + +--- + +**Konditionen** + +Tagessatz: auf Anfrage +Zahlungsziel: 14 Tage nach Rechnungsstellung +Gueltig bis: {{ datum + 14 Tage }} + +--- + +**Stefan Lohmaier** +slohmaier.com · stefan@slohmaier.de diff --git a/templates-de/engineering/SA-vorlage.md b/templates-de/engineering/SA-vorlage.md new file mode 100644 index 0000000..92f30e3 --- /dev/null +++ b/templates-de/engineering/SA-vorlage.md @@ -0,0 +1,104 @@ +--- +active: true +level: 1.0 +links: + - SYS-XXX: [hash] +--- + +# SA-XXX: [Element-Name] + +> **System Architectural Design Element (ASPICE SYS.3).** +> Beschreibt ein Element der System-Architektur und sein Mapping auf System-Anforderungen. + +| Feld | Wert | +|----------|-------------------------------| +| Projekt | [Projektname] | +| Datum | [YYYY-MM-DD] | +| Version | [1.0] | +| Status | [Entwurf / Freigegeben] | +| ASIL | [QM / A / B / C / D] | +| Autor | [Name] | + +--- + +## 1. Verantwortung + +[Was tut dieses Element? Ein bis zwei Saetze. Welcher Zweck im Gesamtsystem.] + +## 2. System-Kontext + +[PlantUML-Diagramm: dieses Element im Verhaeltnis zu Nachbarsystemen / Umgebung.] + +```plantuml +@startuml +!define COMPONENT(x) component "x" as x +COMPONENT([Element]) +[Element] --> [Nachbarsystem A] : Schnittstelle X +[Nachbarsystem B] --> [Element] : Schnittstelle Y +@enduml +``` + +## 3. Allokation + +| Anforderung | Allokation auf | Bemerkung | +|---------------|----------------|---------------------------| +| SYS-XXX | dieses Element | [vollstaendig / teilweise] | +| SYS-YYY | dieses Element | [Begruendung] | + +Allokations-Regel: jede verlinkte System-Anforderung muss eindeutig auf HW, SW oder Mechanik abgebildet werden. + +## 4. Schnittstellen zur Umgebung + +| Schnittstelle | Richtung | Typ | Bemerkung | +|---------------|---------------|----------------------|--------------------------| +| [Name] | in / out / io | [CAN / SPI / GPIO / ...] | [Protokoll-Verweis] | + +## 5. Subkomponenten / Aufteilung + +[Falls dieses System-Element aus mehreren Subkomponenten besteht: kurze Auflistung mit Verweis auf weitere SA- oder SWA-Elemente.] + +| Subkomponente | Realisierung | Verweis | +|---------------|--------------------|-------------------| +| [Name] | [HW / SW / Mechanik] | SWA-XXX / SA-YYY | + +## 6. Dynamisches Verhalten + +[PlantUML-Sequenz oder State-Diagramm fuer kritische Ablaeufe.] + +```plantuml +@startuml +actor Nutzer +Nutzer -> [Element]: Anforderung +[Element] -> [Nachbar]: weiterleiten +[Nachbar] --> [Element]: Antwort +[Element] --> Nutzer: Ergebnis +@enduml +``` + +## 7. Nichtfunktionale Eigenschaften + +| Aspekt | Anforderung / Zielwert | +|---------------------|-----------------------------| +| Worst-Case Timing | [z.B. < 10 ms Reaktionszeit]| +| Speicherbedarf | [z.B. < 64 KB Flash] | +| Stromaufnahme | [z.B. < 200 mA bei 12 V] | +| Umgebungsbedingungen | [Temperatur, EMV] | +| Sicherheitsziel | [Verweis auf SG-XXX, falls vorhanden] | + +## 8. Designentscheidungen + +| Entscheidung | Alternativen | Begruendung | +|--------------|--------------|-------------| +| [Was] | [Was sonst noch erwogen wurde] | [Warum diese Wahl] | + +## 9. Verifikation + +| Anforderung | Verifikations-Methode | Test-ID | +|-------------|------------------------|-------------------| +| SYS-XXX | [Review / Test / Analyse] | TST-SYS-XXX | + +Jede in den `links` referenzierte System-Anforderung muss mindestens eine Verifikations-Methode haben. + +--- + +*Aenderungen an diesem Architektur-Element gehen per PR mit mind. 2 Technical-Review-Approvals (siehe SWE-Plan).* diff --git a/templates-de/engineering/SWA-vorlage.md b/templates-de/engineering/SWA-vorlage.md new file mode 100644 index 0000000..6c03e7d --- /dev/null +++ b/templates-de/engineering/SWA-vorlage.md @@ -0,0 +1,148 @@ +--- +active: true +level: 1.0 +links: + - SWE-XXX: [hash] +--- + +# SWA-XXX: [Komponenten-Name] + +> **Software Architectural Design Element (ASPICE SWE.2).** +> Beschreibt eine Software-Komponente und ihr Mapping auf Software-Anforderungen. + +| Feld | Wert | +|----------|-------------------------------| +| Projekt | [Projektname] | +| Datum | [YYYY-MM-DD] | +| Version | [1.0] | +| Status | [Entwurf / Freigegeben] | +| ASIL | [QM / A / B / C / D] | +| Autor | [Name] | +| Parent | [SA-XXX, falls vorhanden] | + +--- + +## 1. Verantwortung + +[Ein bis zwei Saetze: Was tut diese Komponente? Wo ist die Abgrenzung zu Nachbar-Komponenten?] + +## 2. Statische Sicht + +### 2.1 Komponentendiagramm + +```plantuml +@startuml +package "[Komponenten-Name]" { + [Submodul A] + [Submodul B] +} +[Submodul A] --> [Submodul B] +[Komponenten-Name] ..> [Nachbar-Komponente] : nutzt +@enduml +``` + +### 2.2 Eingebettete / verwendete Komponenten + +| Komponente | Verweis | Verwendung | +|---------------|----------|--------------------------| +| [Name] | SWA-YYY | [wofuer] | + +## 3. Schnittstellen + +### 3.1 Bereitgestellte Schnittstelle (Provided) + +```c +/** + * @brief [Kurzbeschreibung] + * @param [name] [Bedeutung, Wertebereich] + * @return [Status / Wert] + * @pre [Vorbedingung] + * @post [Nachbedingung] + */ +Status component_init(const Config* cfg); +``` + +| Funktion | Zweck | Pre-Condition | Post-Condition | +|------------------|----------------------|-----------------------|------------------------| +| component_init | Initialisierung | cfg != NULL | Komponente betriebsbereit | +| component_send | Daten senden | initialisiert | Daten in TX-Buffer | + +### 3.2 Benoetigte Schnittstelle (Required) + +| Schnittstelle | Bereitgestellt von | Zweck | +|-------------------|--------------------|-----------------------| +| ILogger::log() | LoggerComponent | Diagnose / Tracing | +| IClock::now() | ClockComponent | Zeitstempel | + +## 4. Dynamisches Verhalten + +### 4.1 Sequenzdiagramm (kritischer Ablauf) + +```plantuml +@startuml +participant App +participant "[Komponente]" as C +participant HW +App -> C: init(cfg) +C -> HW: configure +HW --> C: ok +C --> App: STATUS_OK +@enduml +``` + +### 4.2 Zustandsdiagramm (falls zutreffend) + +```plantuml +@startuml +[*] --> Uninitialized +Uninitialized --> Ready : init() +Ready --> Busy : send() +Busy --> Ready : tx_done +Ready --> Error : fault +Error --> Ready : reset() +@enduml +``` + +## 5. Ressourcen-Bedarf + +| Ressource | Worst-Case | Methode der Bestimmung | +|-------------------|--------------|-----------------------------| +| Stack | [z.B. 256 B] | [Messung / statische Analyse] | +| Heap | [z.B. 0 B] | [keine Heap-Nutzung] | +| Flash | [z.B. 4 KB] | [Map-File des Linkers] | +| RAM (statisch) | [z.B. 128 B] | [Map-File des Linkers] | +| CPU-Last | [z.B. < 1 %] | [Messung auf Zielsystem] | +| Worst-Case Timing | [z.B. 200 us / Aufruf init()] | [Messung HiL] | + +## 6. Fehlerverhalten + +| Fehlerfall | Erkennung | Reaktion | +|-----------------------|-------------------|---------------------------| +| Ungueltige Konfig | Parameter-Check | Status STATUS_EINVAL | +| HW-Timeout | Timer | Retry, dann STATUS_TIMEOUT | +| Buffer voll | Check vor Schreiben | STATUS_NOSPACE | + +## 7. Designentscheidungen + +| Entscheidung | Alternative(n) | Begruendung | +|------------------------|------------------|--------------------------| +| [z.B. statische Allokation] | [Heap] | [deterministisch, MISRA] | +| [Lock-Strategie] | [Mutex / lock-free] | [Begruendung] | + +## 8. Mapping auf Anforderungen + +| Anforderung | Wie abgedeckt | Verifikations-Test | +|---------------|----------------------------------------------|----------------------------| +| SWE-XXX | [welcher Teil dieser Komponente erfuellt es] | TST-UNIT-XXX, TST-INT-YYY | +| SWE-YYY | [...] | TST-UNIT-YYY | + +Jede in den `links` referenzierte SWE-Anforderung muss in dieser Tabelle einen Eintrag haben. + +## 9. Detail-Design + +Detail-Design (ASPICE SWE.3) wird ab ASIL-C separat in `arch/swd/SWD-XXX.md` gefuehrt. +Fuer ASIL-A/B und QM ist Code + Header-Kommentare ausreichend. + +--- + +*Aenderungen an diesem Architektur-Element gehen per PR mit mind. 2 Technical-Review-Approvals (siehe SWE-Plan).* diff --git a/templates-de/engineering/Traceability-Matrix-vorlage.md b/templates-de/engineering/Traceability-Matrix-vorlage.md new file mode 100644 index 0000000..be6a99a --- /dev/null +++ b/templates-de/engineering/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.* diff --git a/templates-de/projekt/PID-vorlage.docx b/templates-de/projekt/PID-vorlage.docx new file mode 100644 index 0000000..007356b Binary files /dev/null and b/templates-de/projekt/PID-vorlage.docx differ diff --git a/templates-de/projekt/PID-vorlage.md b/templates-de/projekt/PID-vorlage.md new file mode 100644 index 0000000..bb2a6ce --- /dev/null +++ b/templates-de/projekt/PID-vorlage.md @@ -0,0 +1,92 @@ +# Project Initiation Document (PID) + +| Feld | Wert | +|-----------------|-------------------------------| +| Projektname | [Name] | +| Auftraggeber | [Firma / Ansprechpartner] | +| Auftragnehmer | Stefan Lohmaier | +| Datum | [YYYY-MM-DD] | +| Version | [1.0] | +| Status | [Entwurf / Freigegeben] | + +--- + +## 1. Projektziel + +[Was soll erreicht werden? Ein bis drei Saetze.] + +## 2. Scope + +### In Scope + +- [Lieferumfang Punkt 1] +- [Lieferumfang Punkt 2] + +### Out of Scope + +- [Was explizit nicht enthalten ist] +- [Abgrenzung zu anderen Teilprojekten] + +## 3. Randbedingungen + +| Randbedingung | Beschreibung | +|-------------------------|-------------------------------------------| +| Zielplattform | [z.B. ARM Cortex-R5, Renesas RH850] | +| ASIL | [QM / A / B / C / D] | +| Normen | [ASPICE 4.0, ISO 26262:2018] | +| Programmiersprache | [C / C++ / Rust] | +| Coding Standard | [MISRA C:2012 / MISRA C:2023] | +| Laufzeitumgebung | [Bare-Metal / AUTOSAR Classic / Linux] | +| Kundenvorgaben | [Spezifische Anforderungen des Kunden] | + +## 4. Lieferergebnisse + +| Nr. | Lieferergebnis | Format | Termin | +|-----|-----------------------------------|---------------|-------------| +| 1 | Software Requirements Specification | GitLab Issues | [Datum] | +| 2 | Architektur-Dokumentation | GitLab Wiki | [Datum] | +| 3 | Quellcode | Git Repository| [Datum] | +| 4 | Unit Tests + Coverage Report | CI-Artefakt | [Datum] | +| 5 | MISRA Compliance Report | CI-Artefakt | [Datum] | +| 6 | Testbericht | Markdown/PDF | [Datum] | +| 7 | Release-Paket | Git Tag + Artefakte | [Datum] | + +## 5. Meilensteine + +| Meilenstein | Datum | Kriterium | +|--------------------------|-------------|------------------------------------------| +| Projektstart | [Datum] | PID freigegeben | +| Requirements Complete | [Datum] | Alle Anforderungen reviewed | +| Architecture Complete | [Datum] | Architektur reviewed und freigegeben | +| Code Complete | [Datum] | Implementierung abgeschlossen, Tests gruen | +| Verification Complete | [Datum] | Coverage-Ziele erreicht, MISRA compliant | +| Release | [Datum] | Alle Exit-Kriterien erfuellt | + +## 6. Risiken (initial) + +| ID | Risiko | Wahrscheinlichkeit | Auswirkung | Massnahme | +|------|----------------------------------|---------------------|------------|----------------------------------| +| R-01 | [Risikobeschreibung] | [H/M/L] | [H/M/L] | [Gegenmassnahme] | +| R-02 | [Risikobeschreibung] | [H/M/L] | [H/M/L] | [Gegenmassnahme] | + +## 7. Beteiligte Rollen + +| Rolle | Person / Organisation | Verantwortung | +|--------------------------|------------------------|-----------------------------------| +| Projektleiter | Stefan Lohmaier | Gesamtverantwortung | +| Software-Entwickler | Stefan Lohmaier | Implementierung, Unit Tests | +| QA-Verantwortlicher | [Name / extern] | QA-Aktivitaeten, Audits | +| Safety-Verantwortlicher | [Name / extern] | ISO 26262 Compliance | +| Reviewer | [Name / extern] | Code- und Dokument-Reviews | +| Auftraggeber | [Name] | Anforderungen, Abnahme | + +## 8. Freigabe + +| Rolle | Name | Datum | Unterschrift / GitLab-Verweis | +|----------------------|---------------------|-------------|-------------------------------| +| Auftragnehmer | Stefan Lohmaier | [Datum] | | +| Auftraggeber | [Name] | [Datum] | | + +--- + +*Aenderungen an diesem Dokument werden im GitLab-Wiki versioniert.* diff --git a/templates-de/projekt/PM-Plan-vorlage.docx b/templates-de/projekt/PM-Plan-vorlage.docx new file mode 100644 index 0000000..4de91ee Binary files /dev/null and b/templates-de/projekt/PM-Plan-vorlage.docx differ diff --git a/templates-de/projekt/PM-Plan-vorlage.md b/templates-de/projekt/PM-Plan-vorlage.md new file mode 100644 index 0000000..801f83f --- /dev/null +++ b/templates-de/projekt/PM-Plan-vorlage.md @@ -0,0 +1,85 @@ +# Projektplan (PM-Plan) + +| Feld | Wert | +|-----------------|-------------------------------| +| Projekt | [Projektname] | +| Datum | [YYYY-MM-DD] | +| Version | [1.0] | +| Status | [Entwurf / Freigegeben] | +| Bezug | PID Version [X.Y] | + +--- + +## 1. Projektphasen und Meilensteine + +| Phase | Start | Ende | Meilenstein | +|------------------------|-------------|-------------|--------------------------------------| +| Anforderungsanalyse | [Datum] | [Datum] | Requirements Complete | +| Architektur | [Datum] | [Datum] | Architecture Complete | +| Implementierung | [Datum] | [Datum] | Code Complete | +| Integration & Test | [Datum] | [Datum] | Integration Complete | +| Verifikation | [Datum] | [Datum] | Verification Complete | +| Release | [Datum] | [Datum] | Release | + +Phasen koennen ueberlappen (iterativ). Meilenstein-Kriterien sind im QA-Plan definiert. + +## 2. Ressourcen und Rollen + +| Rolle | Person | Verfuegbarkeit | Aufgaben | +|--------------------------|---------------------|-------------------|---------------------------------| +| Projektleiter / Entwickler | Stefan Lohmaier | [X Tage/Woche] | Planung, Implementierung, Tests | +| Reviewer | [Name / extern] | [nach Bedarf] | Code- und Dokument-Reviews | +| QA | [Name / extern] | [nach Bedarf] | QA-Audits, Prozessueberwachung | +| Auftraggeber | [Name] | [nach Bedarf] | Anforderungsklaerung, Abnahme | + +## 3. Kommunikationsplan + +| Aktivitaet | Haeufigkeit | Teilnehmer | Medium | +|--------------------------|--------------|---------------------------|---------------------| +| Status-Update | [Woechentlich] | Auftraggeber, PL | E-Mail / Call | +| Technische Abstimmung | [Nach Bedarf] | Entwickler, Auftraggeber | Call / GitLab Issue | +| Meilenstein-Review | [Pro Phase] | Alle Beteiligten | Meeting | +| QA-Report | [Pro Phase] | QA, PL, Auftraggeber | Dokument (Wiki) | + +## 4. Eskalationspfad + +| Stufe | Situation | Eskalation an | Frist | +|-------|----------------------------------------------|----------------------------|-------------| +| 1 | Technische Blockade | Auftraggeber (technisch) | 2 Arbeitstage | +| 2 | Terminverschiebung > 1 Woche | Projektverantwortlicher | 1 Arbeitstag | +| 3 | Scope-Aenderung oder Safety-Concern | Management Auftraggeber | sofort | + +## 5. Aenderungsmanagement + +Aenderungen an Anforderungen, Scope oder Zeitplan werden als Change Request behandelt: + +1. Change Request als GitLab Issue erfassen (Label: `change-request`) +2. Auswirkungsanalyse: betroffene Anforderungen, Code, Tests, Zeitplan +3. Bewertung und Freigabe durch Auftraggeber +4. Bei Freigabe: betroffene Work Products aktualisieren, Traceability nachfuehren +5. Dokumentation der Aenderung im Issue (Begruendung, Auswirkung, Entscheidung) + +Keine Aenderung ohne dokumentierte Freigabe. + +## 6. Risikomanagement + +### Vorgehen + +- Initiale Risiken im PID erfasst +- Risikoliste wird pro Meilenstein-Review aktualisiert +- Neue Risiken werden als GitLab Issues erfasst (Label: `risk`) +- Jedes Risiko hat: Beschreibung, Wahrscheinlichkeit, Auswirkung, Massnahme, Verantwortlicher + +### Risiko-Bewertung + +| Wahrscheinlichkeit / Auswirkung | Niedrig | Mittel | Hoch | +|----------------------------------|---------|---------|---------| +| Hoch | Mittel | Hoch | Kritisch| +| Mittel | Niedrig | Mittel | Hoch | +| Niedrig | Niedrig | Niedrig | Mittel | + +Kritische Risiken werden sofort eskaliert (siehe Eskalationspfad Stufe 3). + +--- + +*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.* diff --git a/templates-de/projekt/QA-Plan-vorlage.docx b/templates-de/projekt/QA-Plan-vorlage.docx new file mode 100644 index 0000000..ecb07e8 Binary files /dev/null and b/templates-de/projekt/QA-Plan-vorlage.docx differ diff --git a/templates-de/projekt/QA-Plan-vorlage.md b/templates-de/projekt/QA-Plan-vorlage.md new file mode 100644 index 0000000..df883e4 --- /dev/null +++ b/templates-de/projekt/QA-Plan-vorlage.md @@ -0,0 +1,106 @@ +# Quality Assurance Plan (QA-Plan) + +| Feld | Wert | +|-----------------|-------------------------------| +| Projekt | [Projektname] | +| Datum | [YYYY-MM-DD] | +| Version | [1.0] | +| Status | [Entwurf / Freigegeben] | +| ASIL | [QM / A / B / C / D] | + +--- + +## 1. QA-Aktivitaeten pro Phase + +| Phase | QA-Aktivitaet | Verantwortlich | +|------------------------|--------------------------------------------------------|----------------| +| Anforderungsanalyse | Review der Anforderungen (Vollstaendigkeit, Konsistenz, Testbarkeit) | QA / Reviewer | +| Architektur | Architektur-Review (Modularitaet, Safety-Konzept) | QA / Reviewer | +| Implementierung | Code-Review (MR-Approval), MISRA-Pruefung (CI) | Reviewer / CI | +| Integration & Test | Test-Review, Coverage-Pruefung, Traceability-Check | QA / CI | +| Verifikation | Gesamtpruefung: alle Kriterien erfuellt? | QA | +| Release | Release-Audit: alle Work Products vollstaendig? | QA | + +## 2. Zu pruefende Work Products + +| Work Product | Review-Art | Pruefkriterien | +|----------------------------------|------------------|---------------------------------------------| +| PID | Peer Review | Vollstaendig, konsistent mit Vertrag | +| PM-Plan | Peer Review | Realistisch, Risiken adressiert | +| Software Requirements | Technical Review | Eindeutig, testbar, ASIL zugeordnet | +| Architektur-Dokumentation | Technical Review | Modular, Schnittstellen definiert, Safety-Konzept | +| Quellcode | Peer Review (MR) | MISRA-konform, getestet, lesbar | +| Unit Tests | Peer Review | Abdeckung, Randfaelle, Traceability | +| Testberichte | Peer Review | Pass/Fail dokumentiert, Coverage erreicht | +| MISRA Compliance Report | Peer Review | Abweichungen dokumentiert und genehmigt | +| Traceability-Matrix | QA-Pruefung | Keine Luecken, bidirektional | + +## 3. Review-Arten + +| Review-Art | Teilnehmer | Formalitaet | Wann | +|---------------------|-------------------------------|-------------|----------------------------------| +| Peer Review | 1 Reviewer | Niedrig | Jeder MR, Dokument-Aenderungen | +| Technical Review | 2+ Reviewer, inkl. Tech Lead | Mittel | Architektur, Safety-Code, Plaene | +| Inspektion | Moderator + 2+ Reviewer | Hoch | Safety-kritische Artefakte (ASIL C/D) | + +Peer Reviews laufen ueber GitLab MR-Approvals. Technical Reviews und Inspektionen werden zusaetzlich mit Review-Protokoll dokumentiert. + +## 4. Entry/Exit-Kriterien + +### Entry-Kriterien (Beginn einer Phase) + +| Phase | Entry-Kriterien | +|----------------------|--------------------------------------------------------| +| Architektur | Requirements reviewed und freigegeben | +| Implementierung | Architektur reviewed und freigegeben | +| Integration & Test | Code-Reviews abgeschlossen, Unit Tests gruen | +| Verifikation | Alle Tests durchgefuehrt, Coverage gemessen | +| Release | Alle Exit-Kriterien der Verifikation erfuellt | + +### Exit-Kriterien (Abschluss einer Phase) + +| Phase | Exit-Kriterien | +|----------------------|--------------------------------------------------------| +| Anforderungen | Alle Requirements reviewed, ASIL zugeordnet, testbar | +| Architektur | Architektur reviewed, Schnittstellen definiert | +| Implementierung | MISRA-konform, Unit Tests gruen, Coverage-Ziel erreicht | +| Integration & Test | Integrationstests gruen, keine offenen Critical Findings | +| Verifikation | Traceability vollstaendig, alle Findings geschlossen oder bewertet | +| Release | Alle Work Products vollstaendig, QA-Freigabe erteilt | + +## 5. Non-Conformity-Prozess + +1. Abweichung wird erkannt (Review, Audit, Test) +2. Non-Conformity Report erstellen (GitLab Issue, Label: `non-conformity`) +3. Schweregrad zuweisen: Critical / Major / Minor +4. Ursachenanalyse durchfuehren +5. Korrekturmassnahme definieren und umsetzen +6. Wirksamkeitspruefung nach Umsetzung +7. Issue schliessen mit Verweis auf Korrekturnachweis + +**Eskalation:** Critical Non-Conformities werden sofort an den Auftraggeber gemeldet. + +## 6. Reporting an Management + +| Report | Haeufigkeit | Inhalt | +|---------------------------|------------------|-------------------------------------------| +| QA-Status-Report | Pro Meilenstein | Offene Findings, NC-Status, Coverage-Stand | +| Meilenstein-Bewertung | Pro Phase-Ende | Entry/Exit-Kriterien geprueft | +| Release-Bewertung | Vor Release | Gesamtbewertung aller QA-Kriterien | + +## 7. QA-Metriken + +| Metrik | Ziel | Messung | +|---------------------------------|-------------------------|----------------------------------| +| Requirement Coverage | 100% | Anforderungen mit verlinktem Test | +| Code Coverage (Statement) | >= [X]% | gcov/lcov in CI | +| Code Coverage (Branch) | >= [X]% | gcov/lcov in CI | +| MC/DC Coverage (falls ASIL C/D) | >= [X]% | MCDC-Star / kommerziell | +| MISRA Violations | 0 (oder alle genehmigt)| Cppcheck MISRA-Addon in CI | +| Offene Findings (Critical) | 0 vor Release | GitLab Issues | +| Offene Non-Conformities | 0 Critical/Major | GitLab Issues | +| Review-Abdeckung | 100% MRs reviewed | GitLab MR-Approvals | + +--- + +*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.* diff --git a/templates-de/projekt/SWE-Plan-vorlage.docx b/templates-de/projekt/SWE-Plan-vorlage.docx new file mode 100644 index 0000000..2b3e378 Binary files /dev/null and b/templates-de/projekt/SWE-Plan-vorlage.docx differ diff --git a/templates-de/projekt/SWE-Plan-vorlage.md b/templates-de/projekt/SWE-Plan-vorlage.md new file mode 100644 index 0000000..78c9036 --- /dev/null +++ b/templates-de/projekt/SWE-Plan-vorlage.md @@ -0,0 +1,132 @@ +# Software Development Plan (SWE-Plan) + +| Feld | Wert | +|-----------------|-------------------------------| +| Projekt | [Projektname] | +| Datum | [YYYY-MM-DD] | +| Version | [1.0] | +| Status | [Entwurf / Freigegeben] | +| ASIL | [QM / A / B / C / D] | + +--- + +## 1. Entwicklungsmethode + +[Beschreibung der Vorgehensweise: iterativ, V-Modell-angelehnt, oder hybrid.] + +Grundstruktur folgt dem V-Modell (ISO 26262 Part 6): +- Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung +- Rechte Seite: Unit Test → Integrations-Test → System-Test +- Iterationen innerhalb der Phasen moeglich + +Aenderungen werden ueber Change Requests gesteuert (siehe PM-Plan). + +## 2. Programmiersprache und Standards + +| Aspekt | Festlegung | +|---------------------|-----------------------------------------------------| +| Sprache | [C (C99/C11) / C++ (C++14/17) / Rust] | +| Coding Standard | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023] | +| Projekt-Guidelines | [Verweis auf Coding-Guidelines im Wiki] | +| Namenskonvention | [z.B. snake_case fuer Funktionen, UPPER_CASE fuer Makros] | + +### MISRA-Handhabung + +- Alle Required- und Mandatory-Regeln werden eingehalten +- Advisory-Regeln: Liste der angewendeten Regeln im Wiki dokumentiert +- Abweichungen werden per MISRA Deviation Record dokumentiert +- Projektweite Abweichungen per MISRA Deviation Permit genehmigt +- MISRA-Pruefung laeuft automatisch in der CI-Pipeline + +## 3. Build-Umgebung + +| Komponente | Tool / Version | +|--------------------|-----------------------------------------------------| +| Build-System | [CMake X.Y / SCons X.Y / Make] | +| Compiler | [GCC ARM X.Y / Clang X.Y] | +| Zielplattform | [z.B. ARM Cortex-R5, Cortex-M4] | +| Host-Plattform | [Linux x86_64 / macOS ARM64] | +| CI-Runner | [GitLab Runner, Docker Image: ...] | + +Build-Umgebung ist reproduzierbar: entweder per Docker-Image oder per dokumentierter Toolchain-Installation. + +## 4. Branching-Strategie + +``` +main — Stabiler, freigegebener Stand +develop — Aktueller Entwicklungsstand +feature/SWR-XXX — Feature-Branch pro Anforderung +bugfix/BUG-XXX — Bugfix-Branch +release/vX.Y — Release-Vorbereitung +hotfix/vX.Y.Z — Kritische Fixes nach Release +``` + +- Feature-Branches von `develop` abzweigen +- Merge nach `develop` nur per MR mit Approval +- `main` und `release/*` sind geschuetzt (kein direkter Push) +- Branch-Name enthaelt Issue-Nummer + +Details: siehe `gitlab-aspice-setup.md`. + +## 5. Review-Verpflichtungen + +| Artefakt | Review-Art | Mindest-Approvals | +|-----------------------------|-------------------|--------------------| +| Quellcode (MR) | Peer Review | 1 | +| Safety-relevanter Code | Technical Review | 2 | +| Architektur-Dokument | Technical Review | 2 | +| Anforderungen | Technical Review | 1 | +| Testfaelle | Peer Review | 1 | + +Jeder MR muss vor dem Merge reviewed und approved sein. Self-Merges sind nicht erlaubt (Ausnahme: 1-Person-Projekt mit dokumentiertem Self-Review). + +## 6. Definition of Done + +Ein Feature / eine Anforderung gilt als "Done" wenn: + +- [ ] Code ist implementiert und kompiliert fehlerfrei +- [ ] MISRA-Check in CI ist gruen (keine neuen Violations) +- [ ] Static Analysis (Cppcheck, clang-tidy) hat keine neuen Findings +- [ ] Unit Tests sind geschrieben und gruen +- [ ] Coverage-Ziel ist erreicht (siehe Abschnitt 8) +- [ ] MR ist reviewed und approved +- [ ] Anforderung ist mit Test verlinkt (Traceability) +- [ ] Dokumentation ist aktualisiert (falls betroffen) + +## 7. Integration und Test-Strategie + +| Teststufe | Verantwortlich | Umgebung | Automatisierung | +|---------------------|----------------|----------------|-----------------| +| Unit Test | Entwickler | Host (x86) | CI-Pipeline | +| Integrations-Test | Entwickler | Host / SiL | CI / manuell | +| System-Test | Test / QA | SiL / HiL | teilweise | +| Abnahme-Test | Auftraggeber | HiL / Fahrzeug | manuell | + +- Unit Tests laufen auf Host-Plattform (Cross-Compilation fuer Tests auf x86) +- Integrationstests pruefen Zusammenspiel der Module +- System-Tests pruefen gegen System-Anforderungen +- HiL-Tests werden vom Auftraggeber bereitgestellt oder gemeinsam definiert + +## 8. Coverage-Ziele + +| ASIL | Statement Coverage | Branch Coverage | MC/DC | +|------|--------------------|-----------------|----------| +| QM | >= 80% empfohlen | — | — | +| A | >= 80% | empfohlen | — | +| B | >= 80% | >= 80% | — | +| C | >= 90% | >= 80% | empfohlen| +| D | >= 90% | >= 90% | >= 80% | + +Konkrete Zielwerte fuer dieses Projekt: + +| Metrik | Zielwert | +|---------------------|------------| +| Statement Coverage | >= [X]% | +| Branch Coverage | >= [X]% | +| MC/DC | >= [X]% (falls anwendbar) | + +Coverage wird in der CI gemessen und als Artefakt archiviert. Abweichungen vom Ziel werden begruendet und im QA-Report dokumentiert. + +--- + +*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.* diff --git a/templates-de/projekt/Test-Plan-vorlage.docx b/templates-de/projekt/Test-Plan-vorlage.docx new file mode 100644 index 0000000..bb91896 Binary files /dev/null and b/templates-de/projekt/Test-Plan-vorlage.docx differ diff --git a/templates-de/projekt/Test-Plan-vorlage.md b/templates-de/projekt/Test-Plan-vorlage.md new file mode 100644 index 0000000..5f745df --- /dev/null +++ b/templates-de/projekt/Test-Plan-vorlage.md @@ -0,0 +1,121 @@ +# Testplan + +| Feld | Wert | +|-----------------|-------------------------------| +| Projekt | [Projektname] | +| Datum | [YYYY-MM-DD] | +| Version | [1.0] | +| Status | [Entwurf / Freigegeben] | +| ASIL | [QM / A / B / C / D] | +| Bezug | SWE-Plan Version [X.Y] | + +--- + +## 1. Testziele + +- Nachweis, dass die Software die spezifizierten Anforderungen erfuellt +- Nachweis der strukturellen Code-Abdeckung gemaess ASIL-Vorgaben +- Nachweis der Robustheit gegenueber Fehlbedienung und Grenzwerten +- Identifikation von Defekten vor der Integration / Auslieferung + +## 2. Teststrategie + +| Teststufe | Testziel | Methode | Automatisierung | +|---------------------|---------------------------------------------|------------------|-----------------| +| Unit Test | Einzelne Funktionen / Module korrekt | White-Box | CI (automatisch)| +| Integrations-Test | Zusammenspiel der Module | Grey-Box | CI / SiL | +| System-Test | Erfuellung der System-Anforderungen | Black-Box | SiL / HiL | +| Regressionstest | Keine Seiteneffekte durch Aenderungen | Automatisiert | CI | + +### Unit Tests + +- Framework: [CppUTest / Google Test / Unity+CMock] +- Laufen auf Host-Plattform (x86) +- Jede Anforderung hat mindestens einen zugehoerigen Testfall +- Negative Tests und Grenzwerte sind Pflicht + +### Integrationstests + +- Pruefen Schnittstellen zwischen Modulen +- Laufen auf Host oder SiL-Umgebung +- Kommunikationsschnittstellen (CAN, SPI, UART) werden per Mock oder Simulator getestet + +### System-Tests + +- Pruefen gegen System-Anforderungen +- Laufen auf SiL oder HiL +- Testfaelle werden aus System-Requirements abgeleitet + +## 3. Coverage-Ziele + +| Metrik | Zielwert | Messung | +|---------------------|----------------|------------------| +| Statement Coverage | >= [X]% | gcov/lcov | +| Branch Coverage | >= [X]% | gcov/lcov | +| MC/DC | >= [X]% (falls anwendbar) | MCDC-Star / kommerziell | + +Referenz: ISO 26262 Part 6, Table 9. + +| ASIL | Statement | Branch | MC/DC | +|------|-----------|---------|--------------| +| QM | empfohlen | — | — | +| A | Pflicht | empfohlen | — | +| B | Pflicht | Pflicht | — | +| C | Pflicht | Pflicht | empfohlen | +| D | Pflicht | Pflicht | Pflicht | + +## 4. Testumgebung + +| Komponente | Beschreibung | +|---------------------|----------------------------------------------------| +| Host-Plattform | [Linux x86_64 / macOS ARM64] | +| Cross-Compiler | [GCC ARM X.Y] | +| Test-Framework | [CppUTest / Google Test / Unity] | +| SiL-Framework | [Python + pytest, Kommunikation: UART/CAN/TCP] | +| HiL-System | [dSPACE Scalexio / vom Kunden gestellt / entfaellt] | +| CI-Runner | [GitLab Runner, Docker Image: ...] | + +## 5. Testdaten + +- Testdaten werden im Repository unter `tests/data/` versioniert +- Grenzwerte aus Anforderungen ableiten +- Ungueltige Eingaben explizit testen +- Testdaten fuer Regressionen aus Bug-Reports ableiten + +## 6. Pass/Fail-Kriterien + +### Einzelner Testfall + +- **Pass:** Erwartetes Ergebnis stimmt mit tatsaechlichem ueberein +- **Fail:** Abweichung vom erwarteten Ergebnis + +### Teststufe gesamt + +| Kriterium | Bedingung fuer Pass | +|----------------------------------------|----------------------------------------| +| Alle Testfaelle ausgefuehrt | Ja | +| Alle Testfaelle bestanden | Ja (oder Fails bewertet und genehmigt) | +| Coverage-Ziel erreicht | Ja | +| Keine offenen Critical Findings | Ja | +| Traceability vollstaendig | Jede Anforderung hat mindestens einen Test | + +Fehlgeschlagene Tests, die nicht behoben werden, muessen per Non-Conformity oder Change Request dokumentiert und bewertet werden. + +## 7. Traceability + +Jeder Testfall muss auf mindestens eine Anforderung rueckfuehrbar sein. + +``` +Anforderung (GitLab Issue, Label: req::software) + → Testfall (GitLab Issue, Label: test::unit / test::integration / test::system) + → Testergebnis (CI-Artefakt / JUnit-XML) +``` + +Umsetzung: +- Testfall-Issue verlinkt auf Anforderungs-Issue ("relates to" oder "verified by") +- Im Testcode: Kommentar mit Anforderungs-ID (`// Verifies: SWR-042`) +- Traceability-Report wird per Skript aus GitLab API generiert + +--- + +*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.* diff --git a/templates-de/qualitaet/MISRA-Deviation-Permit-vorlage.docx b/templates-de/qualitaet/MISRA-Deviation-Permit-vorlage.docx new file mode 100644 index 0000000..33071ee Binary files /dev/null and b/templates-de/qualitaet/MISRA-Deviation-Permit-vorlage.docx differ diff --git a/templates-de/qualitaet/MISRA-Deviation-Permit-vorlage.md b/templates-de/qualitaet/MISRA-Deviation-Permit-vorlage.md new file mode 100644 index 0000000..235f36a --- /dev/null +++ b/templates-de/qualitaet/MISRA-Deviation-Permit-vorlage.md @@ -0,0 +1,76 @@ +# MISRA Deviation Permit + +| Feld | Wert | +|-----------------|-------------------------------| +| Permit-ID | PER-[XXX] | +| Datum | [YYYY-MM-DD] | +| Erstellt von | [Name] | + +--- + +## 1. Regelbereich + +| Feld | Wert | +|-------------------|----------------------------------------------------| +| Regel-Nummer | [z.B. Rule 11.3] | +| Kategorie | [Required / Advisory] | +| Regeltext | [Exakter Text der MISRA-Regel] | +| Standard | [MISRA C:2012 / MISRA C:2023] | + +## 2. Scope + +Dieses Permit gilt fuer: + +| Aspekt | Geltungsbereich | +|-------------------|----------------------------------------------------| +| Code-Bereich | [z.B. src/hal/*.c — alle Hardware-Abstraction-Layer Dateien] | +| Modul / Komponente| [z.B. HAL, CAN-Treiber] | +| Kontext | [z.B. Register-Zugriffe auf Memory-Mapped I/O] | + +**Einschraenkung:** Dieses Permit gilt ausschliesslich fuer den oben definierten Scope. Abweichungen ausserhalb dieses Bereichs erfordern einen eigenen Deviation Record oder ein separates Permit. + +## 3. Begruendung + +[Warum ist die Abweichung von dieser Regel im definierten Kontext vertretbar?] + +Beispiel: "Rule 11.3 verbietet Casts zwischen Pointer-Typen. Im HAL sind Casts von `uint32_t*` auf Register-Structs notwendig, da die Hardware ueber Memory-Mapped I/O angesprochen wird. Die Register-Adressen und Layouts sind durch das Datenblatt definiert und statisch. Eine regelkonforme Alternative existiert nicht." + +**Begruendung:** [Hier ausfuellen] + +## 4. Risikobewertung und Alternativen + +### Risikobewertung + +| Aspekt | Bewertung | +|---------------------------|-----------------------------------------------| +| Sicherheitsrelevanz | [Keine / Gering / Mittel / Hoch] | +| Fehlerpotenzial | [Beschreibung] | +| Absicherung | [z.B. Unit Tests pruefen korrekte Register-Zugriffe, Code Review Pflicht fuer HAL-Code] | +| Restrisiko | [Bewertung] | + +### Geprufte Alternativen + +| Alternative | Bewertung | +|--------------------------|------------------------------------------------| +| [z.B. Generische Zugriffsfunktionen] | [z.B. Nicht praktikabel, da hunderte Register] | +| [z.B. Compiler-Erweiterung] | [z.B. Nicht portabel] | + +## 5. Freigabe + +| Feld | Wert | +|-----------------------|-----------------------------------------------| +| Freigegeben von | [Name, Rolle] | +| Datum | [YYYY-MM-DD] | +| Nachweis | [GitLab-Issue / Wiki-Verweis / Unterschrift] | + +## 6. Gueltigkeit + +| Feld | Wert | +|-------------------|----------------------------------------------------| +| Gueltig ab | [YYYY-MM-DD] | +| Gueltig bis | [YYYY-MM-DD oder "bis auf Widerruf"] | +| Widerrufsbedingung | [z.B. Bei Aenderung der Zielplattform neu bewerten] | + +--- + +*Dieses Permit wird im GitLab-Wiki unter MISRA-Deviation-Permits abgelegt und aus Deviation Records referenziert.* diff --git a/templates-de/qualitaet/MISRA-Deviation-Record-vorlage.docx b/templates-de/qualitaet/MISRA-Deviation-Record-vorlage.docx new file mode 100644 index 0000000..639a252 Binary files /dev/null and b/templates-de/qualitaet/MISRA-Deviation-Record-vorlage.docx differ diff --git a/templates-de/qualitaet/MISRA-Deviation-Record-vorlage.md b/templates-de/qualitaet/MISRA-Deviation-Record-vorlage.md new file mode 100644 index 0000000..372a6e5 --- /dev/null +++ b/templates-de/qualitaet/MISRA-Deviation-Record-vorlage.md @@ -0,0 +1,70 @@ +# MISRA Deviation Record + +| Feld | Wert | +|-----------------|-------------------------------| +| Deviation-ID | DEV-[XXX] | +| Datum | [YYYY-MM-DD] | +| Erstellt von | [Name] | + +--- + +## 1. Regel + +| Feld | Wert | +|-------------------|----------------------------------------------------| +| Regel-Nummer | [z.B. Rule 11.3] | +| Kategorie | [Required / Advisory / Mandatory] | +| Regeltext | [Exakter Text der MISRA-Regel] | +| Standard | [MISRA C:2012 / MISRA C:2023] | + +## 2. Fundstelle + +| Feld | Wert | +|-------------------|----------------------------------------------------| +| Datei | [z.B. src/drivers/watchdog.c] | +| Zeile(n) | [z.B. 142-145] | +| Funktion | [z.B. wdg_set_timeout()] | +| Git-Commit | [Commit-Hash] | +| GitLab-Referenz | [MR-Link oder Issue-Link] | + +## 3. Begruendung + +[Warum ist die Abweichung in diesem konkreten Fall technisch vertretbar?] + +Moegliche Begruendungen: +- Hardware-Zugriff erfordert Typkonvertierung +- Compiler-spezifisches Verhalten ist definiert und getestet +- Alternative Implementierung waere unverhältnismaessig komplex +- Regel ist im Kontext nicht sicherheitsrelevant + +**Konkrete Begruendung:** [Hier ausfuellen] + +## 4. Risikobewertung + +| Aspekt | Bewertung | +|---------------------------|-----------------------------------------------| +| Sicherheitsrelevanz | [Keine / Gering / Mittel / Hoch] | +| Fehlerpotenzial | [Beschreibung moeglicher Fehler] | +| Absicherung | [Welche Tests / Massnahmen sichern den Code ab] | +| Restrisiko | [Bewertung des verbleibenden Risikos] | + +## 5. Verweis auf Deviation Permit + +| Feld | Wert | +|-----------------------|-----------------------------------------------| +| Permit vorhanden | [Ja / Nein] | +| Permit-ID | [PER-XXX oder "entfaellt"] | + +Falls kein Permit vorhanden: diese Abweichung ist eine Einzelfallgenehmigung. + +## 6. Freigabe + +| Feld | Wert | +|-------------------|----------------------------------------------------| +| Freigegeben von | [Name, Rolle] | +| Datum | [YYYY-MM-DD] | +| Nachweis | [GitLab-MR-Approval / Unterschrift] | + +--- + +*Dieser Record wird im Repository unter `docs/misra/` oder als GitLab Issue gefuehrt.* diff --git a/templates-de/qualitaet/Non-Conformity-vorlage.docx b/templates-de/qualitaet/Non-Conformity-vorlage.docx new file mode 100644 index 0000000..231f599 Binary files /dev/null and b/templates-de/qualitaet/Non-Conformity-vorlage.docx differ diff --git a/templates-de/qualitaet/Non-Conformity-vorlage.md b/templates-de/qualitaet/Non-Conformity-vorlage.md new file mode 100644 index 0000000..62aa2ae --- /dev/null +++ b/templates-de/qualitaet/Non-Conformity-vorlage.md @@ -0,0 +1,79 @@ +# Non-Conformity Report + +| Feld | Wert | +|-----------------|-------------------------------| +| NC-ID | NC-[XXX] | +| Datum | [YYYY-MM-DD] | +| Erstellt von | [Name] | +| Status | [Offen / In Bearbeitung / Geschlossen] | + +--- + +## 1. Bezug + +| Feld | Wert | +|-----------------------|-----------------------------------------------| +| Art | [Prozessabweichung / Produktabweichung] | +| Betroffener Prozess | [z.B. SWE.4 Implementierung, SUP.1 QA] | +| Betroffenes Work Product | [z.B. Modul XY, Anforderung SWR-042, Testplan] | +| GitLab-Referenz | [Issue-Link / MR-Link / Wiki-Seite] | +| Gefunden bei | [Review / Audit / Test / CI-Pipeline] | + +## 2. Beschreibung der Abweichung + +[Was genau weicht ab? Konkret beschreiben. Bezug auf Norm oder Prozessvorgabe angeben.] + +## 3. Schweregrad + +| Schweregrad | Definition | +|-------------|------------------------------------------------------------------| +| [ ] Critical | Sicherheitsrelevant oder vollstaendiges Fehlen eines geforderten Work Products | +| [ ] Major | Signifikante Abweichung, die die Qualitaet oder Konformitaet beeintraechtigt | +| [ ] Minor | Geringfuegige Abweichung, keine direkte Auswirkung auf Sicherheit oder Funktion | + +**Zugewiesener Schweregrad:** [Critical / Major / Minor] + +## 4. Ursachenanalyse + +[Warum ist die Abweichung aufgetreten? Moegliche Kategorien:] +- Prozess nicht bekannt / nicht geschult +- Prozess nicht anwendbar / unrealistisch +- Versehen / menschlicher Fehler +- Tool-Fehler +- Zeitdruck / Ressourcenmangel +- Anforderung unklar + +**Beschreibung:** [Konkrete Ursache] + +## 5. Korrekturmassnahme + +| Feld | Wert | +|-----------------------|-----------------------------------------------| +| Massnahme | [Was wird getan um die Abweichung zu beheben] | +| Verantwortlich | [Name] | +| Faelligkeit | [YYYY-MM-DD] | + +### Vorbeugende Massnahme (optional) + +[Was wird getan damit diese Art von Abweichung nicht erneut auftritt?] + +## 6. Wirksamkeitspruefung + +| Feld | Wert | +|-----------------------|-----------------------------------------------| +| Geprueft von | [Name] | +| Pruefungsdatum | [YYYY-MM-DD] | +| Massnahme wirksam | [Ja / Nein] | +| Nachweis | [GitLab-Issue-Link / Commit / Review] | + +## 7. Abschluss + +| Feld | Wert | +|-----------------------|-----------------------------------------------| +| Status | [Geschlossen / Erneut geoeffnet] | +| Geschlossen von | [Name] | +| Datum | [YYYY-MM-DD] | + +--- + +*Dieser Report wird als GitLab Issue (Label: `non-conformity`) gefuehrt.* diff --git a/templates-de/qualitaet/Review-Protokoll-vorlage.docx b/templates-de/qualitaet/Review-Protokoll-vorlage.docx new file mode 100644 index 0000000..07e3230 Binary files /dev/null and b/templates-de/qualitaet/Review-Protokoll-vorlage.docx differ diff --git a/templates-de/qualitaet/Review-Protokoll-vorlage.md b/templates-de/qualitaet/Review-Protokoll-vorlage.md new file mode 100644 index 0000000..dcc7625 --- /dev/null +++ b/templates-de/qualitaet/Review-Protokoll-vorlage.md @@ -0,0 +1,74 @@ +# Review-Protokoll + +| Feld | Wert | +|-------------------------|-----------------------------------------| +| Datum | [YYYY-MM-DD] | +| Review-Art | [Peer Review / Technical Review / Inspektion] | +| Moderator | [Name] | +| Protokollfuehrer | [Name] | + +--- + +## 1. Teilnehmer + +| Name | Rolle | Anwesend | +|---------------------|--------------------------|----------| +| [Name] | Moderator | Ja / Nein | +| [Name] | Autor | Ja / Nein | +| [Name] | Reviewer | Ja / Nein | +| [Name] | Reviewer | Ja / Nein | + +## 2. Reviewtes Work Product + +| Feld | Wert | +|-------------------|-------------------------------------------| +| Work Product | [z.B. Architektur-Dokumentation, Modul XY, Anforderungen SWR-040 bis SWR-060] | +| Version / Commit | [Version oder Git-Commit-Hash] | +| GitLab-Referenz | [MR-Link / Wiki-Seite / Issue-Nummern] | + +## 3. Review-Vorbereitung + +| Reviewer | Vorbereitungszeit (h) | Vorbereitung abgeschlossen | +|-------------------|-----------------------|----------------------------| +| [Name] | [X] | Ja / Nein | +| [Name] | [X] | Ja / Nein | + +## 4. Findings + +| ID | Beschreibung | Schwere | Verantwortlich | Fälligkeit | Status | +|------|---------------------------------|-------------------|----------------|-------------|-------------| +| F-01 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen | +| F-02 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen | +| F-03 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen | + +### Schweregrade + +- **Critical:** Sicherheitsrelevant oder funktional falsch. Muss vor Freigabe behoben werden. +- **Major:** Signifikanter Fehler oder Luecke. Muss behoben werden, kann aber terminiert werden. +- **Minor:** Verbesserungsvorschlag, Stil, Lesbarkeit. Behebung empfohlen. + +## 5. Entscheidung + +| Entscheidung | +|-----------------------------------------------------------| +| [ ] Freigegeben | +| [ ] Bedingt freigegeben (nach Behebung der Critical/Major Findings) | +| [ ] Nicht freigegeben (erneutes Review erforderlich) | + +**Bedingungen fuer bedingte Freigabe:** +[Falls zutreffend: welche Findings muessen behoben werden, wer prueft die Behebung] + +## 6. Unterschriften / Nachweis + +| Rolle | Name | Datum | Nachweis | +|----------------------|---------------------|-------------|------------------------------| +| Moderator | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] | +| Reviewer 1 | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] | +| Reviewer 2 | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] | +| Autor | [Name] | [Datum] | | + +**GitLab-MR-Link:** [URL zum Merge Request, falls zutreffend] + +--- + +*Dieses Protokoll wird im GitLab-Wiki unter Review-Protokolle/ abgelegt.*