commit 6e458ae76f021f1a51e3a0a5ef457bceffea9790 Author: Stefan Lohmaier Date: Mon May 11 13:40:51 2026 -0700 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 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e6b79b7 --- /dev/null +++ b/.gitignore @@ -0,0 +1,20 @@ +# macOS +.DS_Store + +# Editor +.vscode/ +.idea/ +*.swp +*~ + +# Python +__pycache__/ +*.pyc +.venv/ +venv/ + +# Pandoc temp +*.tmp.docx + +# Generated PDFs (kann lokal gebaut werden) +*.pdf diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..4686cfe --- /dev/null +++ b/LICENSE @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2026 Stefan Lohmaier + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/README.md b/README.md new file mode 100644 index 0000000..51108c2 --- /dev/null +++ b/README.md @@ -0,0 +1,209 @@ +# slohmaier Dev Process + +Ein praxisnaher Entwicklungsprozess angelehnt an ASPICE 4.0 / ISO 26262, umgesetzt mit Gitea, Doorstop, MS Word und VS Code. Ausgelegt für Freelance-Projekte und kleine Teams. + +**Demo-Projekt:** [slohmaier/demo-epb](https://gitea.slohmaier.com/slohmaier/demo-epb) — Elektrische Parkbremse, wendet diesen Prozess vollständig an. + +## Grundprinzip + +Alles lebt in einem **Monorepo**. Anforderungen, Dokumente, Code und Tests sind zusammen in einem Git-Repository. Alle Änderungen gehen über Pull Requests mit Approval — das ist der formale Review-Nachweis. + +## Format-Strategie: Hybrid + +Die zwei Welten — ISO-9001-Audit und tägliches Engineering — haben unterschiedliche Anforderungen. Wir trennen sauber: + +| Artefakt | Format | Begründung | +|----------|--------|------------| +| PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan | **Word** (signiert) | Formell freigegeben, an Kunden geliefert | +| Reviews, Non-Conformities, Audit-Protokolle | **Word** | Audit-Artefakte | +| MISRA Permits / Records | **Word** | Audit-Artefakte | +| Angebote, Verträge | **Word** | klar | +| Requirements (SYS, SWE) | **Markdown** (Doorstop) | Diff, Traceability, lebt täglich | +| Architektur (SA, SWA, SWD) | **Markdown** (Doorstop) | Mapping per `links:` | +| Code, Tests, CI | Code | klar | +| Liefer-PDFs an Kunden | **PDF via pandoc** aus MD | formelle Übergabe der Engineering-Artefakte | + +**Markdown-Vorlagen sind Source of Truth**, Word wird daraus per pandoc gebaut (`tools/generate_word_vorlagen.sh`). + +## Monorepo-Struktur + +``` +projekt-name/ + reqs/ + sys/ SYS-001.md, SYS-002.md + swe/ SWE-001.md, SWE-002.md + arch/ + sys/ SA-001.md, SA-002.md (ASPICE SYS.3) + swe/ SWA-001.md, SWA-002.md (ASPICE SWE.2) + swd/ SWD-001.md (ASPICE SWE.3, ab ASIL-C) + docs/ + PID.md + PM-Plan.md + QA-Plan.md + SWE-Plan.md + Test-Plan.md + reviews/ + non-conformities/ + traceability/ (generiert von Doorstop) + src/ + tests/ + unit/ + integration/ + results/ + misra/ + permits/ + records/ + reports/ + .gitea/ + workflows/validate.yml + .doorstop.yml +``` + +## Anforderungen mit Doorstop (Markdown-Modus) + +Requirements sind `.md`-Dateien mit YAML-Frontmatter. PlantUML-Diagramme direkt einbettbar. + +```markdown +--- +active: true +level: 1.0 +links: + - SYS-001: abc123 +--- + +# SWE-001: CAN Bus Initialisierung + +Der CAN-Treiber muss den Bus mit konfigurierbarer Baudrate initialisieren. + +```plantuml +@startuml +ECU -> CANDriver: init(baudrate) +CANDriver -> Hardware: configure(baudrate) +Hardware --> CANDriver: ok +@enduml +``` +``` + +Gitea rendert das direkt. VS Code mit PlantUML-Extension zeigt die Preview beim Editieren. + +Doorstop prüft: +- Alle Links valide +- Alle Requirements haben Tests +- Keine Lücken in der Traceability + +## Architektur-Design (ASPICE SYS.3 / SWE.2) + +Architektur-Elemente liegen in `arch/` und sind ebenfalls Doorstop-Dokumente. Gleiche Mechanik wie Anforderungen: Markdown + YAML-Frontmatter + eingebettetes PlantUML. + +- `arch/sys/SA-XXX.md` — System-Architektur, Mapping auf SYS-Anforderungen +- `arch/swe/SWA-XXX.md` — Software-Architektur, Mapping auf SWE-Anforderungen +- `arch/swd/SWD-XXX.md` — Software Detailed Design (nur ab ASIL-C) + +**Mapping** geschieht über `links:` im Frontmatter: + +```markdown +--- +active: true +level: 1.0 +links: + - SWE-001: abc123 + - SWE-014: def456 +--- + +# SWA-003: CAN Driver Component +``` + +`doorstop check` verifiziert in beide Richtungen: +- Jede SWE-Anforderung wird von mindestens einem SWA-Element abgedeckt +- Jedes SWA-Element verweist auf mindestens eine SWE-Anforderung +- `doorstop publish all docs/traceability/` erzeugt die Traceability-Matrix + +**Code → Architektur** per Header-Kommentar im Modul: + +```c +/** + * @file can_driver.c + * @arch SWA-003 + * @reqs SWE-001, SWE-014 + */ +``` + +Vorlagen: `vorlagen/SA-vorlage.md`, `vorlagen/SWA-vorlage.md`. + +## Reviews + +Jede Änderung — an Code, Requirements, Dokumenten oder Plänen — geht über einen Pull Request. + +| Was | Approver | +|-----|----------| +| Requirement neu/ändern | mind. 1 Reviewer | +| Architektur-Element (SA/SWA/SWD) | mind. 2 Technical Reviewer | +| Dokument (Plan, Protokoll) | mind. 1 Reviewer | +| Code-Änderung | mind. 1 Reviewer | +| MISRA Permit | Technical Lead | + +Merge = formale Freigabe. Git-History ist der Audit-Trail. + +## Traceability + +Vier Ebenen werden verknüpft: + +1. **Doorstop-Links** in `.md`-Dateien: `links: [SYS-001: abc123]` +2. **Architektur-Mapping** (Arch-Element → Anforderung) ebenfalls per Doorstop +3. **Commit-Messages**: `feat(SWE-001): implement CAN init` oder `feat(SWA-003): ...` +4. **Issue-Referenzen** in PRs: `Refs #42` + +Chain: `SYS-XXX → SA-XXX → SWE-XXX → SWA-XXX → Code → Test` + +Doorstop erzeugt automatisch einen Traceability-Report: +```bash +doorstop publish all docs/traceability/ +``` + +## CI-Pipeline + +Läuft bei jedem Push und PR automatisch: + +1. `doorstop check` — Requirements-Links valide +2. `cppcheck --addon=misra` — MISRA-Compliance +3. `make test` — Unit Tests +4. `make coverage` — Coverage-Report +5. `doorstop publish` — Traceability-Report aktualisieren + +## Dateien in diesem Repo + +| Pfad | Inhalt | +|------|--------| +| `toolstack/toolstack.md` | Vollständiger Tool-Stack | +| `gitea-aspice-setup.md` | Gitea einrichten für ASPICE | +| `dev-process-schaubild.html` | V-Modell Infografik | +| `vorlagen/` | Markdown-Vorlagen (Source of Truth) | +| `vorlagen-word/` | Generierte Word-Vorlagen + Master-Template `slohmaier-doc-template.docx` | +| `tools/build_word_template.py` | Erzeugt das neutrale Master-Word-Template mit Formatvorlagen, Deckblatt, Document Control | +| `tools/generate_word_vorlagen.sh` | Erzeugt aus den `.md`-Vorlagen die `.docx`-Versionen via pandoc | + +## Word-Vorlagen neu generieren + +```bash +# Master-Template + alle abgeleiteten Word-Vorlagen neu bauen +python3 tools/build_word_template.py +bash tools/generate_word_vorlagen.sh +``` + +Das Master-Template enthält ISO-9001-konform: +- Deckblatt mit Projekt, Dokument-ID, Version, Klassifikation +- Document Control (Freigaben, Änderungshistorie, Verteiler) +- Auto-Verzeichnisse (Inhalt, Abbildungen, Tabellen) +- Formatvorlagen für H1–H4, Body, Code, Note, Warning, Requirement +- Header/Footer mit Projekt, Dokument-ID, Klassifikation, Seitennummer + +## Einsatz in eigenen Projekten + +Drei Wege, diesen Prozess zu nutzen: + +1. **Git-Submodule** in dein Projekt: + ```bash + git submodule add https://gitea.slohmaier.com/slohmaier/dev-process .dev-process + ``` +2. **Vorlagen kopieren** und im Projekt einchecken (statischer Snapshot). +3. **Fork / Clone** und als Basis für eigene Anpassungen verwenden. diff --git a/dev-process-schaubild.html b/dev-process-schaubild.html new file mode 100644 index 0000000..e42a348 --- /dev/null +++ b/dev-process-schaubild.html @@ -0,0 +1,211 @@ + + + + + +slohmaier Dev Process – V-Model (ASPICE 4.0 / ISO 26262) + + + + + + + + + + + + + + + + + + + + + + Software Development Process + ASPICE 4.0 / ISO 26262 — V-Model with GitLab Toolchain + + + + + SUP.1 — Quality Assurance + + + SUP.8 — Configuration Management (Git / GitLab) + + + SUP.9 — Problem Resolution (GitLab Issues) + + + SUP.10 — Change Request Management (GitLab Merge Requests) + + + + + + + + + + SPECIFICATION + VERIFICATION + + + + + + SYS.2 + System Requirements + + + + + + + SWE.1 + Software Requirements + + + + + + + SWE.6 + Qualification Test + + + + + + + SWE.2 + Software Architecture + + + + + + + SWE.5 + Integration Test + + + + + + + SWE.3 + Detail Design + + + + + + + SWE.4 + Unit Verification + + + + + + SWE.3 + Implementation + + + + + + + + + + + + + + + + + + + Traceability + + + + + Traceability + + + + + + + TOOLCHAIN + + + + + GitLab + Source · Wiki · Reviews · CI/CD + + + + Cppcheck + MISRA Compliance + + + + gcov / lcov + MCDC-Star Coverage + + + + CppUTest + Google Test + + + + ScanCode + FOSSology + + + + pandoc + Document Export + + + + slohmaier.com + ASPICE 4.0 / ISO 26262 compliant process overview + + + + diff --git a/gitea-aspice-setup.md b/gitea-aspice-setup.md new file mode 100644 index 0000000..d759910 --- /dev/null +++ b/gitea-aspice-setup.md @@ -0,0 +1,242 @@ +# Gitea für ASPICE 4.0 einrichten + +Konkrete Anleitung für den slohmaier Dev Process auf Basis von Gitea, Doorstop und Gitea Actions. + +## Gitea installieren + +### Docker (empfohlen) + +```yaml +# docker-compose.yml +version: "3" +services: + gitea: + image: gitea/gitea:latest + ports: + - "3000:3000" + - "222:22" + volumes: + - ./data:/data + environment: + - USER_UID=1000 + - USER_GID=1000 +``` + +```bash +docker compose up -d +``` + +### PlantUML-Rendering aktivieren + +In `data/gitea/conf/app.ini`: + +```ini +[markup.plantuml] +ENABLED = true +NEED_POSTPROCESS= true +FILE_EXTENSIONS = .puml +RENDER_COMMAND = plantuml -tsvg -pipe +IS_INPUT_FILE = false +``` + +Oder über den öffentlichen Renderer (kein lokales PlantUML nötig): + +```ini +[server] +OFFLINE_MODE = false + +[markup.plantuml] +ENABLED = true +NEED_POSTPROCESS = true +RENDER_COMMAND = curl -s https://www.plantuml.com/plantuml/svg/~h +``` + +## Organisations- und Repo-Struktur + +``` +Organisation: slohmaier (eigene Projekte) +Organisation: kunde-projektname (Kundenprojekte) + Repo: projektname (Monorepo: reqs + docs + src + tests) +``` + +Ein Repo pro Projekt. Kein Aufteilen in viele Repos. + +## Label-Schema + +Alle Labels in der Organisation anlegen, dann in jedem Repo verfügbar. + +| Label | Farbe | Verwendung | +|-------|-------|------------| +| `type:requirement` | blau | Anforderungs-Issue | +| `type:architecture` | dunkelblau | Architektur-Entscheidung | +| `type:implementation` | grün | Implementierungsaufgabe | +| `type:test` | hellgrün | Testfall | +| `type:document` | grau | Dokument-Änderung | +| `aspice:NC` | rot | Non-Conformity | +| `aspice:change-request` | orange | Change Request | +| `aspice:finding` | gelb | QA-Finding | +| `status:review-required` | lila | Wartet auf Review | +| `status:approved` | grün | Freigegeben | +| `severity:critical` | dunkelrot | Kritisch | +| `severity:major` | orange | Schwerwiegend | +| `severity:minor` | gelb | Geringfügig | + +## Branch-Schutz + +Für `main`: +- Kein direktes Pushen +- Mind. 1 Approval erforderlich +- CI muss grün sein + +Einstellbar unter: Repo → Settings → Branches → Branch Protection + +## Branching-Strategie + +``` +main protected, stabil, nur via PR +develop Integrationsbranch +feature/SWE-001-can-init Feature mit Req-Referenz +docs/qa-plan-v1 Dokument-Änderung +fix/NC-003-misra-violation Bugfix mit NC-Referenz +release/v1.0 Release-Branch +``` + +## PR/Review-Workflow + +### Neue Anforderung anlegen +``` +1. Branch: reqs/SWE-001-can-init +2. Datei anlegen: reqs/swe/SWE-001.md +3. PR erstellen mit Titel: "[REQ] SWE-001: CAN Bus Initialisierung" +4. Reviewer zuweisen +5. Nach Approval → Merge +``` + +### Dokument ändern +``` +1. Branch: docs/qa-plan-update +2. Änderung in docs/QA-Plan.md +3. PR mit Beschreibung der Änderung +4. Reviewer zuweisen → Approval → Merge +``` + +### Code-Änderung +``` +1. Branch: feature/SWE-001-can-init +2. Commit-Message: "feat(SWE-001): implement CAN bus init at configurable baudrate" +3. PR: "Refs #" +4. CI muss grün sein +5. Reviewer → Approval → Merge +``` + +## Commit-Message-Konvention + +``` +feat(SWE-001): implement CAN bus initialization +fix(NC-003): resolve MISRA Rule 14.4 violation +docs(QA-Plan): add review schedule for SWE phase +test(SWE-001): add unit test for CAN init error handling +``` + +Format: `(): ` + +## Gitea Actions — Basis-Pipeline + +```yaml +# .gitea/workflows/validate.yml +name: Validate +on: [push, pull_request] + +jobs: + validate: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + + - name: Install tools + run: | + pip install doorstop + apt-get install -y cppcheck + + - name: Doorstop check + run: doorstop check + + - name: MISRA check + run: | + cppcheck --addon=misra --error-exitcode=1 \ + --suppress=misra-c2012-15.5 \ + src/ + + - name: Unit tests + run: make test + + - name: Coverage + run: make coverage + + - name: Publish traceability + run: | + doorstop publish all docs/traceability/ + git config user.email "ci@slohmaier.com" + git config user.name "CI" + git add docs/traceability/ + git diff --cached --quiet || git commit -m "ci: update traceability report" + git push +``` + +## Doorstop konfigurieren + +`.doorstop.yml` im Repo-Root: + +```yaml +settings: + digits: 3 + prefix: REQ +``` + +`.doorstop` in jedem Requirements-Unterordner: + +```yaml +# reqs/sys/.doorstop +settings: + digits: 3 + prefix: SYS + parent: null +``` + +```yaml +# reqs/swe/.doorstop +settings: + digits: 3 + prefix: SWE + parent: SYS +``` + +```yaml +# tests/unit/.doorstop +settings: + digits: 3 + prefix: TST + parent: SWE +``` + +## VS Code Extensions für diesen Stack + +| Extension | ID | Zweck | +|-----------|-----|-------| +| PlantUML | jnbt.plantuml | Diagramm-Preview in Markdown | +| Markdown All in One | yzhang.markdown-all-in-one | Markdown-Bearbeitung | +| YAML | redhat.vscode-yaml | YAML-Frontmatter in .md | +| GitLens | eamodio.gitlens | Git-History und Blame | +| Continue | Continue.continue | KI-Assistent lokal via Ollama | + +## Traceability-Übersicht + +``` +SYS-001 (System-Anforderung) + └── SWE-001 (Software-Anforderung) [links: SYS-001] + └── TST-001 (Testfall) [links: SWE-001] + └── Commit abc1234 [feat(SWE-001): ...] + └── PR #12 [Refs #5 (Issue: SWE-001)] +``` + +Doorstop prüft die komplette Kette automatisch bei jedem CI-Lauf. diff --git a/tools/build_word_template.py b/tools/build_word_template.py new file mode 100644 index 0000000..726c620 --- /dev/null +++ b/tools/build_word_template.py @@ -0,0 +1,583 @@ +#!/usr/bin/env python3 +""" +Build the neutral slohmaier Word document template. + +Output: vorlagen-word/slohmaier-doc-template.docx + +The template is ISO 9001 / ASPICE-friendly: +- Cover page with project, doc-ID, version, classification +- Document Control (Approvals, Revision History, Distribution) +- Inhaltsverzeichnis / Abbildungsverzeichnis / Tabellenverzeichnis (auto-fields) +- Custom styles: Heading 1-4, Body, Caption, Code, Note, Warning, Requirement +- Header/Footer with project + doc-ID + classification + page + +Run: python3 tools/build_word_template.py +""" +from __future__ import annotations + +import sys +from pathlib import Path + +from docx import Document +from docx.enum.style import WD_STYLE_TYPE +from docx.enum.table import WD_ALIGN_VERTICAL, WD_TABLE_ALIGNMENT +from docx.enum.text import WD_ALIGN_PARAGRAPH, WD_BREAK +from docx.oxml import OxmlElement +from docx.oxml.ns import qn +from docx.shared import Cm, Pt, RGBColor + + +# --------------------------------------------------------------------------- +# OXML helpers +# --------------------------------------------------------------------------- + +def _qn_set(elem, attr, value): + elem.set(qn(attr), value) + + +def add_field(paragraph, instr_text, default_text=""): + """Insert a Word field (e.g. TOC, PAGE) into a paragraph.""" + run = paragraph.add_run() + r_elem = run._r + + fld_begin = OxmlElement("w:fldChar") + _qn_set(fld_begin, "w:fldCharType", "begin") + r_elem.append(fld_begin) + + instr = OxmlElement("w:instrText") + _qn_set(instr, "xml:space", "preserve") + instr.text = instr_text + r_elem.append(instr) + + fld_sep = OxmlElement("w:fldChar") + _qn_set(fld_sep, "w:fldCharType", "separate") + r_elem.append(fld_sep) + + default_t = OxmlElement("w:t") + default_t.text = default_text + r_elem.append(default_t) + + fld_end = OxmlElement("w:fldChar") + _qn_set(fld_end, "w:fldCharType", "end") + r_elem.append(fld_end) + + +def set_cell_shading(cell, fill_hex): + tc_pr = cell._tc.get_or_add_tcPr() + shd = OxmlElement("w:shd") + _qn_set(shd, "w:val", "clear") + _qn_set(shd, "w:color", "auto") + _qn_set(shd, "w:fill", fill_hex) + tc_pr.append(shd) + + +def set_cell_borders(cell, color="808080", size=4): + tc_pr = cell._tc.get_or_add_tcPr() + tc_borders = OxmlElement("w:tcBorders") + for edge in ("top", "left", "bottom", "right"): + b = OxmlElement(f"w:{edge}") + _qn_set(b, "w:val", "single") + _qn_set(b, "w:sz", str(size)) + _qn_set(b, "w:space", "0") + _qn_set(b, "w:color", color) + tc_borders.append(b) + tc_pr.append(tc_borders) + + +def set_paragraph_border(paragraph, color="808080", size=12, side="left"): + p_pr = paragraph._p.get_or_add_pPr() + p_bdr = OxmlElement("w:pBdr") + b = OxmlElement(f"w:{side}") + _qn_set(b, "w:val", "single") + _qn_set(b, "w:sz", str(size)) + _qn_set(b, "w:space", "8") + _qn_set(b, "w:color", color) + p_bdr.append(b) + p_pr.append(p_bdr) + + +def set_paragraph_shading(paragraph, fill_hex): + p_pr = paragraph._p.get_or_add_pPr() + shd = OxmlElement("w:shd") + _qn_set(shd, "w:val", "clear") + _qn_set(shd, "w:color", "auto") + _qn_set(shd, "w:fill", fill_hex) + p_pr.append(shd) + + +# --------------------------------------------------------------------------- +# Styles +# --------------------------------------------------------------------------- + +NEUTRAL_GREY = "595959" +SOFT_GREY = "808080" +LIGHT_GREY = "F2F2F2" +ACCENT_DARK = "1F3864" +NOTE_BG = "E7F0FA" +NOTE_BORDER = "2E74B5" +WARN_BG = "FFF4E5" +WARN_BORDER = "C55A11" +REQ_BG = "EAEAEA" +REQ_BORDER = "404040" + + +def configure_styles(doc): + styles = doc.styles + + # --- Normal / Body Text --- + normal = styles["Normal"] + normal.font.name = "Calibri" + normal.font.size = Pt(11) + normal.font.color.rgb = RGBColor(0x20, 0x20, 0x20) + normal.paragraph_format.space_after = Pt(6) + normal.paragraph_format.line_spacing = 1.15 + + # --- Headings --- + heading_specs = [ + ("Heading 1", 18, True, RGBColor(0x1F, 0x38, 0x64), 18, 6), + ("Heading 2", 14, True, RGBColor(0x1F, 0x38, 0x64), 12, 6), + ("Heading 3", 12, True, RGBColor(0x40, 0x40, 0x40), 8, 4), + ("Heading 4", 11, True, RGBColor(0x40, 0x40, 0x40), 6, 4), + ] + for name, size, bold, color, before, after in heading_specs: + s = styles[name] + s.font.name = "Calibri" + s.font.size = Pt(size) + s.font.bold = bold + s.font.color.rgb = color + s.paragraph_format.space_before = Pt(before) + s.paragraph_format.space_after = Pt(after) + s.paragraph_format.keep_with_next = True + + # --- Title --- + title = styles["Title"] + title.font.name = "Calibri" + title.font.size = Pt(36) + title.font.bold = True + title.font.color.rgb = RGBColor(0x1F, 0x38, 0x64) + + # --- Subtitle --- + subtitle = styles["Subtitle"] + subtitle.font.name = "Calibri" + subtitle.font.size = Pt(16) + subtitle.font.color.rgb = RGBColor(0x59, 0x59, 0x59) + + # --- Caption (figure/table caption) --- + caption = styles["Caption"] + caption.font.name = "Calibri" + caption.font.size = Pt(10) + caption.font.italic = True + caption.font.color.rgb = RGBColor(0x59, 0x59, 0x59) + + # --- Code (custom paragraph style) --- + if "Code" not in [s.name for s in styles]: + code = styles.add_style("Code", WD_STYLE_TYPE.PARAGRAPH) + code.base_style = styles["Normal"] + code.font.name = "Consolas" + code.font.size = Pt(10) + code.paragraph_format.left_indent = Cm(0.5) + code.paragraph_format.space_before = Pt(4) + code.paragraph_format.space_after = Pt(4) + + # --- Note (custom paragraph style) --- + if "Note" not in [s.name for s in styles]: + note = styles.add_style("Note", WD_STYLE_TYPE.PARAGRAPH) + note.base_style = styles["Normal"] + note.font.name = "Calibri" + note.font.size = Pt(10) + note.paragraph_format.left_indent = Cm(0.4) + note.paragraph_format.space_before = Pt(6) + note.paragraph_format.space_after = Pt(6) + + # --- Warning --- + if "Warning" not in [s.name for s in styles]: + warn = styles.add_style("Warning", WD_STYLE_TYPE.PARAGRAPH) + warn.base_style = styles["Normal"] + warn.font.name = "Calibri" + warn.font.size = Pt(10) + warn.font.bold = True + warn.paragraph_format.left_indent = Cm(0.4) + + # --- Requirement Box --- + if "Requirement" not in [s.name for s in styles]: + req = styles.add_style("Requirement", WD_STYLE_TYPE.PARAGRAPH) + req.base_style = styles["Normal"] + req.font.name = "Calibri" + req.font.size = Pt(11) + req.paragraph_format.left_indent = Cm(0.4) + req.paragraph_format.space_before = Pt(6) + req.paragraph_format.space_after = Pt(6) + + +# --------------------------------------------------------------------------- +# Page setup, header/footer +# --------------------------------------------------------------------------- + +def setup_page(doc): + for section in doc.sections: + section.top_margin = Cm(2.5) + section.bottom_margin = Cm(2.5) + section.left_margin = Cm(2.5) + section.right_margin = Cm(2.5) + section.header_distance = Cm(1.25) + section.footer_distance = Cm(1.25) + + +def build_header_footer(doc, doc_id_placeholder="", classification="VERTRAULICH"): + section = doc.sections[0] + section.different_first_page_header_footer = True + + # --- Default header (skipped on cover page) --- + header = section.header + header_para = header.paragraphs[0] + header_para.alignment = WD_ALIGN_PARAGRAPH.LEFT + tabs = header_para.paragraph_format.tab_stops + tabs.add_tab_stop(Cm(8), WD_ALIGN_PARAGRAPH.CENTER) + tabs.add_tab_stop(Cm(16), WD_ALIGN_PARAGRAPH.RIGHT) + r1 = header_para.add_run("") + r1.font.size = Pt(9) + r1.font.color.rgb = RGBColor(0x59, 0x59, 0x59) + header_para.add_run("\t") + r2 = header_para.add_run("") + r2.font.size = Pt(9) + r2.font.color.rgb = RGBColor(0x59, 0x59, 0x59) + r2.bold = True + header_para.add_run("\t") + r3 = header_para.add_run(doc_id_placeholder) + r3.font.size = Pt(9) + r3.font.color.rgb = RGBColor(0x59, 0x59, 0x59) + + # --- Default footer (skipped on cover page) --- + footer = section.footer + footer_para = footer.paragraphs[0] + footer_para.alignment = WD_ALIGN_PARAGRAPH.LEFT + f_tabs = footer_para.paragraph_format.tab_stops + f_tabs.add_tab_stop(Cm(8), WD_ALIGN_PARAGRAPH.CENTER) + f_tabs.add_tab_stop(Cm(16), WD_ALIGN_PARAGRAPH.RIGHT) + fr1 = footer_para.add_run("© slohmaier.com") + fr1.font.size = Pt(9) + fr1.font.color.rgb = RGBColor(0x59, 0x59, 0x59) + footer_para.add_run("\t") + fr2 = footer_para.add_run(classification) + fr2.font.size = Pt(9) + fr2.font.color.rgb = RGBColor(0x59, 0x59, 0x59) + fr2.bold = True + footer_para.add_run("\t") + fr3 = footer_para.add_run("Seite ") + fr3.font.size = Pt(9) + fr3.font.color.rgb = RGBColor(0x59, 0x59, 0x59) + add_field(footer_para, "PAGE", "1") + fr4 = footer_para.add_run(" / ") + fr4.font.size = Pt(9) + fr4.font.color.rgb = RGBColor(0x59, 0x59, 0x59) + add_field(footer_para, "NUMPAGES", "1") + + # --- First-page header/footer (cover): empty --- + fp_header = section.first_page_header + fp_header.paragraphs[0].text = "" + fp_footer = section.first_page_footer + fp_footer.paragraphs[0].text = "" + + +# --------------------------------------------------------------------------- +# Content +# --------------------------------------------------------------------------- + +def add_cover_page(doc): + # Top logo placeholder + p = doc.add_paragraph() + p.alignment = WD_ALIGN_PARAGRAPH.RIGHT + r = p.add_run("[LOGO]") + r.font.size = Pt(10) + r.font.color.rgb = RGBColor(0x80, 0x80, 0x80) + + # Vertical space + for _ in range(8): + doc.add_paragraph() + + # Classification banner + cls_p = doc.add_paragraph() + cls_p.alignment = WD_ALIGN_PARAGRAPH.CENTER + cls_r = cls_p.add_run("VERTRAULICH") + cls_r.font.size = Pt(11) + cls_r.font.bold = True + cls_r.font.color.rgb = RGBColor(0xC5, 0x5A, 0x11) + + # Title + title_p = doc.add_paragraph(style="Title") + title_p.alignment = WD_ALIGN_PARAGRAPH.CENTER + title_p.add_run("") + + # Subtitle + sub_p = doc.add_paragraph(style="Subtitle") + sub_p.alignment = WD_ALIGN_PARAGRAPH.CENTER + sub_p.add_run("") + + for _ in range(4): + doc.add_paragraph() + + # Metadata block + meta_tbl = doc.add_table(rows=6, cols=2) + meta_tbl.alignment = WD_TABLE_ALIGNMENT.CENTER + meta_tbl.autofit = False + meta_tbl.columns[0].width = Cm(4.5) + meta_tbl.columns[1].width = Cm(8.5) + meta_data = [ + ("Projekt", ""), + ("Dokument-ID", ""), + ("Version", "1.0"), + ("Datum", "YYYY-MM-DD"), + ("Status", "Entwurf"), + ("Klassifikation", "Vertraulich"), + ] + for i, (k, v) in enumerate(meta_data): + c1 = meta_tbl.cell(i, 0) + c1.width = Cm(4.5) + c1.text = "" + c1_p = c1.paragraphs[0] + c1_r = c1_p.add_run(k) + c1_r.bold = True + c1_r.font.size = Pt(11) + set_cell_shading(c1, LIGHT_GREY) + set_cell_borders(c1, SOFT_GREY) + + c2 = meta_tbl.cell(i, 1) + c2.width = Cm(8.5) + c2.text = "" + c2_p = c2.paragraphs[0] + c2_r = c2_p.add_run(v) + c2_r.font.size = Pt(11) + set_cell_borders(c2, SOFT_GREY) + + # Page break + doc.add_page_break() + + +def add_document_control(doc): + doc.add_heading("Dokumentenlenkung", level=1) + doc.add_paragraph( + "Diese Seite dokumentiert die formale Lenkung dieses Dokuments gemaess " + "ISO 9001. Aenderungen werden nur ueber den Freigabeprozess wirksam." + ) + + doc.add_heading("Freigaben", level=2) + appr_tbl = doc.add_table(rows=4, cols=4) + appr_tbl.style = "Light Grid Accent 1" + hdr = appr_tbl.rows[0].cells + for i, h in enumerate(["Rolle", "Name", "Unterschrift / Datum", "Bemerkung"]): + hdr[i].text = "" + r = hdr[i].paragraphs[0].add_run(h) + r.bold = True + set_cell_shading(hdr[i], LIGHT_GREY) + roles = ["Erstellt von", "Geprueft von", "Freigegeben von"] + for i, role in enumerate(roles, start=1): + appr_tbl.rows[i].cells[0].text = role + for j in (1, 2, 3): + appr_tbl.rows[i].cells[j].text = "" + + doc.add_heading("Aenderungshistorie", level=2) + rev_tbl = doc.add_table(rows=3, cols=4) + rev_tbl.style = "Light Grid Accent 1" + rev_hdr = rev_tbl.rows[0].cells + for i, h in enumerate(["Version", "Datum", "Aenderung", "Autor"]): + rev_hdr[i].text = "" + r = rev_hdr[i].paragraphs[0].add_run(h) + r.bold = True + set_cell_shading(rev_hdr[i], LIGHT_GREY) + rev_data = [ + ("0.1", "YYYY-MM-DD", "Initialer Entwurf", ""), + ("1.0", "YYYY-MM-DD", "Erstfreigabe", ""), + ] + for i, row in enumerate(rev_data, start=1): + for j, v in enumerate(row): + rev_tbl.rows[i].cells[j].text = v + + doc.add_heading("Verteilerkreis", level=2) + dist_tbl = doc.add_table(rows=3, cols=3) + dist_tbl.style = "Light Grid Accent 1" + dist_hdr = dist_tbl.rows[0].cells + for i, h in enumerate(["Empfaenger", "Rolle", "Organisation"]): + dist_hdr[i].text = "" + r = dist_hdr[i].paragraphs[0].add_run(h) + r.bold = True + set_cell_shading(dist_hdr[i], LIGHT_GREY) + for i in range(1, 3): + for j in range(3): + dist_tbl.rows[i].cells[j].text = "" + + doc.add_page_break() + + +def add_toc_pages(doc): + doc.add_heading("Inhaltsverzeichnis", level=1) + p = doc.add_paragraph() + add_field( + p, + 'TOC \\o "1-3" \\h \\z \\u', + "Inhaltsverzeichnis aktualisieren: F9 (rechte Maustaste auf TOC > Felder aktualisieren)", + ) + doc.add_page_break() + + doc.add_heading("Abbildungsverzeichnis", level=1) + p = doc.add_paragraph() + add_field( + p, + 'TOC \\h \\z \\c "Abbildung"', + "Abbildungsverzeichnis aktualisieren: F9", + ) + doc.add_page_break() + + doc.add_heading("Tabellenverzeichnis", level=1) + p = doc.add_paragraph() + add_field( + p, + 'TOC \\h \\z \\c "Tabelle"', + "Tabellenverzeichnis aktualisieren: F9", + ) + doc.add_page_break() + + +def add_abbreviations(doc): + doc.add_heading("Abkuerzungsverzeichnis", level=1) + tbl = doc.add_table(rows=4, cols=2) + tbl.style = "Light Grid Accent 1" + hdr = tbl.rows[0].cells + for i, h in enumerate(["Abkuerzung", "Bedeutung"]): + hdr[i].text = "" + r = hdr[i].paragraphs[0].add_run(h) + r.bold = True + set_cell_shading(hdr[i], LIGHT_GREY) + examples = [ + ("ASIL", "Automotive Safety Integrity Level"), + ("ECU", "Electronic Control Unit"), + ("MISRA", "Motor Industry Software Reliability Association"), + ] + for i, (k, v) in enumerate(examples, start=1): + tbl.rows[i].cells[0].text = k + tbl.rows[i].cells[1].text = v + doc.add_page_break() + + +def add_main_content(doc): + # Section 1 + doc.add_heading("1. Einleitung", level=1) + doc.add_heading("1.1 Zweck", level=2) + doc.add_paragraph( + "" + ) + doc.add_heading("1.2 Geltungsbereich", level=2) + doc.add_paragraph("") + doc.add_heading("1.3 Definitionen", level=2) + doc.add_paragraph( + "" + ) + doc.add_heading("1.4 Referenzen", level=2) + ref_tbl = doc.add_table(rows=3, cols=3) + ref_tbl.style = "Light Grid Accent 1" + ref_hdr = ref_tbl.rows[0].cells + for i, h in enumerate(["ID", "Titel", "Version / Ort"]): + ref_hdr[i].text = "" + r = ref_hdr[i].paragraphs[0].add_run(h) + r.bold = True + set_cell_shading(ref_hdr[i], LIGHT_GREY) + for i in range(1, 3): + for j in range(3): + ref_tbl.rows[i].cells[j].text = "" + + # Section 2 + doc.add_heading("2. Hauptinhalt", level=1) + doc.add_paragraph( + "" + ) + + # Demonstrate styles + doc.add_heading("2.1 Beispiel: Formatvorlagen", level=2) + doc.add_paragraph( + "Body-Text in der Vorlage. Schriftart Calibri 11 mit 1,15-fachem Zeilenabstand." + ) + + code_p = doc.add_paragraph(style="Code") + code_p.add_run( + "// Beispiel-Code im Code-Stil (Consolas 10)\n" + "Status epb_apply(uint8_t force_percent);" + ) + set_paragraph_shading(code_p, LIGHT_GREY) + + note_p = doc.add_paragraph(style="Note") + note_p.add_run("HINWEIS: ").bold = True + note_p.add_run("Hinweis-Stil fuer ergaenzende Informationen.") + set_paragraph_border(note_p, NOTE_BORDER, size=18, side="left") + set_paragraph_shading(note_p, NOTE_BG) + + warn_p = doc.add_paragraph(style="Warning") + warn_p.add_run("ACHTUNG: ").bold = True + warn_p.add_run("Warn-Stil fuer sicherheitsrelevante Hinweise.") + set_paragraph_border(warn_p, WARN_BORDER, size=18, side="left") + set_paragraph_shading(warn_p, WARN_BG) + + req_p = doc.add_paragraph(style="Requirement") + req_p.add_run("REQ-001: ").bold = True + req_p.add_run( + "Requirement-Stil fuer in-line Anforderungen " + "(meist in Markdown via Doorstop, in Word fuer formelle Berichte)." + ) + set_paragraph_border(req_p, REQ_BORDER, size=18, side="left") + set_paragraph_shading(req_p, REQ_BG) + + doc.add_heading("2.2 Beispiel-Tabelle", level=2) + tbl = doc.add_table(rows=4, cols=3) + tbl.style = "Light Grid Accent 1" + hdr = tbl.rows[0].cells + for i, h in enumerate(["ID", "Beschreibung", "ASIL"]): + hdr[i].text = "" + r = hdr[i].paragraphs[0].add_run(h) + r.bold = True + set_cell_shading(hdr[i], LIGHT_GREY) + rows = [ + ("F-01", "Apply bei Fahrer-Anforderung", "D"), + ("F-05", "Release bei Fahrer-Anforderung", "B"), + ("F-10", "HMI: LED-Steuerung", "QM"), + ] + for i, row in enumerate(rows, start=1): + for j, v in enumerate(row): + tbl.rows[i].cells[j].text = v + + # Caption demo + cap_p = doc.add_paragraph(style="Caption") + cap_p.add_run("Tabelle 1: Beispiel-Anforderungen mit ASIL-Klassifikation") + + # Section 3 — Anhang + doc.add_heading("3. Anhang", level=1) + doc.add_paragraph( + "" + ) + + +# --------------------------------------------------------------------------- +# Main +# --------------------------------------------------------------------------- + +def build_template(out_path: Path): + doc = Document() + setup_page(doc) + configure_styles(doc) + build_header_footer(doc) + + add_cover_page(doc) + add_document_control(doc) + add_toc_pages(doc) + add_abbreviations(doc) + add_main_content(doc) + + out_path.parent.mkdir(parents=True, exist_ok=True) + doc.save(out_path) + print(f"Wrote: {out_path}") + + +if __name__ == "__main__": + out = Path(sys.argv[1] if len(sys.argv) > 1 else + Path(__file__).resolve().parent.parent / "vorlagen-word" / "slohmaier-doc-template.docx") + build_template(out) diff --git a/tools/generate_word_vorlagen.sh b/tools/generate_word_vorlagen.sh new file mode 100755 index 0000000..c59511a --- /dev/null +++ b/tools/generate_word_vorlagen.sh @@ -0,0 +1,52 @@ +#!/usr/bin/env bash +# Convert the formal-document Markdown vorlagen to Word .docx +# using slohmaier-doc-template.docx as style reference. +# +# Word ist Industriestandard fuer formelle Freigabe / ISO-9001-Audits. +# Markdown bleibt die Source of Truth, Word wird daraus generiert. +# +# Diese Vorlagen werden zu Word konvertiert: +set -euo pipefail + +REPO_ROOT="$(cd "$(dirname "$0")/.." && pwd)" +SRC="$REPO_ROOT/vorlagen" +DST="$REPO_ROOT/vorlagen-word" +TEMPLATE="$DST/slohmaier-doc-template.docx" + +if [[ ! -f "$TEMPLATE" ]]; then + echo "Building base Word template first..." + python3 "$REPO_ROOT/tools/build_word_template.py" +fi + +# Formelle Dokumente (zu Word): +FORMAL_DOCS=( + PID-vorlage + PM-Plan-vorlage + QA-Plan-vorlage + SWE-Plan-vorlage + Test-Plan-vorlage + Review-Protokoll-vorlage + Non-Conformity-vorlage + MISRA-Deviation-Permit-vorlage + MISRA-Deviation-Record-vorlage + angebot-vorlage +) + +mkdir -p "$DST" + +for doc in "${FORMAL_DOCS[@]}"; do + if [[ -f "$SRC/$doc.md" ]]; then + echo "Converting: $doc.md -> $doc.docx" + pandoc "$SRC/$doc.md" \ + --reference-doc="$TEMPLATE" \ + --toc \ + --toc-depth=3 \ + -o "$DST/$doc.docx" + else + echo "WARN: $SRC/$doc.md not found, skipping" + fi +done + +echo "" +echo "Done. Word-Vorlagen unter: $DST/" +ls -la "$DST/" diff --git a/toolstack/toolstack.md b/toolstack/toolstack.md new file mode 100644 index 0000000..8d15a1a --- /dev/null +++ b/toolstack/toolstack.md @@ -0,0 +1,222 @@ +# Toolstack – slohmaier Dev Process + +Kompletter Open-Source-Toolstack fuer ASPICE 4.0 und ISO 26262 konforme Embedded-Entwicklung. + +--- + +## Uebersicht + +| Kategorie | Tool | Bemerkung | +|-----------|------|-----------| +| Source Control | Gitea (self-hosted) | `tea` CLI fuer Kommandozeile, VS Code Integration | +| Requirements | Doorstop (Markdown-Modus) | Requirements als `.md` mit PlantUML eingebettet | +| Architektur-Design | Doorstop + PlantUML | SA / SWA / SWD als `.md` mit Mapping per `links:` (ASPICE SYS.3 / SWE.2 / SWE.3) | +| Diagramme | PlantUML | Eingebettet in Markdown, gerendert von Gitea und VS Code | +| MISRA | Cppcheck + MISRA-Addon | Kostenlos, Deviation Permits/Records via Doorstop | +| Coverage | gcov/lcov | Bis ASIL-B; MCDC-Star fuer ASIL-C/D | +| Unit Tests | CppUTest oder Google Test | Je nach Projekt | +| Static Analysis | Cppcheck, clang-tidy | Cppcheck auch fuer MISRA | +| Build | SCons, CMake | Je nach Projekt | +| Compiler | GCC ARM | Eigene Qualifizierung; Ferrocene fuer Rust | +| CI | Gitea Actions | Pipeline im Monorepo unter `.gitea/workflows/` | +| Open Source Analyse | ScanCode, FOSSology | Lizenz-Compliance | +| KI-Unterstuetzung | Continue.dev + Ollama | VS Code Extension, lokal, kein Cloud-Datenschutzproblem | +| Dokumentenexport | pandoc | Markdown nach PDF | +| Editor | VS Code | Primaerer Editor fuer alles | + +--- + +## Source Control: Gitea + +Gitea ist eine self-hosted Git-Plattform. Leichtgewichtig, laeuft auf jeder Hardware. + +- Web-UI fuer PRs, Reviews, Issues +- Gitea Actions fuer CI/CD (kompatibel mit GitHub Actions Syntax) +- PlantUML-Rendering in Markdown (per PlantUML-Server) +- `tea` CLI fuer Kommandozeilen-Workflows +- Branch Protection und Approval-Workflows + +Setup-Anleitung: `gitea-aspice-setup.md` + +--- + +## Requirements: Doorstop (Markdown-Modus) + +Doorstop verwaltet Requirements als `.md`-Dateien mit YAML-Frontmatter. Kein proprietaeres Format, alles lesbar in jedem Editor. + +**Vorteile:** +- Requirements sind Markdown, versioniert in Git +- PlantUML-Diagramme direkt im Requirement eingebettet +- Traceability-Pruefung per CLI: `doorstop check` +- Report-Generierung: `doorstop publish all docs/traceability/` +- Gitea rendert alles direkt (Markdown + PlantUML) + +**Requirement-Format:** + +```markdown +--- +active: true +level: 1.0 +links: + - SYS-001: abc123 +--- + +# SWE-001: Titel + +Beschreibung mit eingebettetem PlantUML. +``` + +--- + +## Architektur-Design: Doorstop + PlantUML + +Architektur-Elemente sind ebenfalls Doorstop-Dokumente, nur mit eigenen Prefixen: + +| Prefix | Ebene | ASPICE | Verzeichnis | +|--------|--------------------------------|--------|--------------| +| SA | System Architectural Design | SYS.3 | `arch/sys/` | +| SWA | Software Architectural Design | SWE.2 | `arch/swe/` | +| SWD | Software Detailed Design | SWE.3 | `arch/swd/` | + +**Mapping auf Anforderungen** per `links:` im YAML-Frontmatter — identisch zur Requirements-Verlinkung. Doorstop verifiziert in beide Richtungen: keine verwaisten Anforderungen, keine verwaisten Architektur-Elemente. + +**Verifikation in der CI:** + +```bash +doorstop check # bidirektional, schlaegt fehl bei Luecken +doorstop publish all docs/traceability/ # Traceability-Matrix erzeugen +``` + +Vorlagen unter `dev-process/vorlagen/`: +- `SA-vorlage.md` — System Architecture Element +- `SWA-vorlage.md` — Software Architecture Element + +SWD wird nur fuer ASIL-C/D zwingend gefuehrt; fuer QM/A/B reichen Code + Header-Kommentare. + +--- + +## Diagramme: PlantUML + +PlantUML-Diagramme werden direkt in Markdown eingebettet. Kein separates Tool, kein Export. + +**Rendering:** +- Gitea: Automatisch via PlantUML-Server (Konfiguration in `app.ini`) +- VS Code: PlantUML-Extension (jebbs.plantuml) fuer Live-Preview +- Export: pandoc mit PlantUML-Filter fuer PDF + +--- + +## MISRA: Cppcheck + MISRA-Addon + +Cppcheck mit MISRA-Addon prueft C-Code auf MISRA-Konformitaet. Kostenlos, laeuft in der CI-Pipeline. + +```bash +cppcheck --addon=misra --error-exitcode=1 src/ +``` + +Deviation Permits und Records werden als Markdown-Dateien im `misra/`-Verzeichnis verwaltet. Vorlagen unter `dev-process/vorlagen/`. + +--- + +## Coverage + +| ASIL | Tool | Methode | +|------|------|---------| +| A–B | gcov/lcov | Statement + Branch Coverage | +| C–D | MCDC-Star | MC/DC Coverage | + +Coverage-Reports werden in der CI generiert und unter `tests/results/` abgelegt. + +--- + +## Unit Tests + +CppUTest oder Google Test, je nach Projektanforderung. + +- Tests unter `tests/unit/` +- Ergebnisse unter `tests/results/` +- CI fuehrt Tests bei jedem Push aus + +--- + +## Static Analysis + +| Tool | Zweck | +|------|-------| +| Cppcheck | Allgemeine statische Analyse + MISRA | +| clang-tidy | Modernisierung, Stil, Bugs | + +Beide laufen in der CI-Pipeline. + +--- + +## Build: SCons / CMake + +Je nach Projekt SCons oder CMake. Cross-Compilation fuer ARM-Targets. + +--- + +## Compiler + +| Compiler | Sprache | Qualifizierung | +|----------|---------|----------------| +| GCC ARM | C/C++ | Eigene Qualifizierung nach ISO 26262 | +| Ferrocene | Rust | Zertifizierter Rust-Compiler fuer Safety | + +--- + +## CI: Gitea Actions + +Pipeline-Datei: `.gitea/workflows/validate.yml` + +Schritte bei jedem Push/PR: +1. Doorstop-Konsistenz pruefen +2. MISRA-Check +3. Unit Tests +4. Coverage +5. Traceability-Report generieren + +Syntax kompatibel mit GitHub Actions. + +--- + +## Open Source Analyse + +| Tool | Zweck | +|------|-------| +| ScanCode | Lizenz-Erkennung in Quellcode | +| FOSSology | Lizenz-Compliance-Analyse | + +Wichtig fuer Automotive: Lizenz-Compliance muss dokumentiert sein. + +--- + +## KI-Unterstuetzung: Continue.dev + Ollama + +Continue.dev als VS Code Extension mit Ollama als lokalem Backend. + +- Kein Cloud-Service, alle Daten bleiben lokal +- Kein Datenschutzproblem mit Kundendaten +- Unterstuetzung beim Code-Schreiben, Reviews, Dokumentation + +--- + +## Dokumentenexport: pandoc + +```bash +pandoc dokument.md -o dokument.pdf --pdf-engine=xelatex +``` + +Alle Dokumente in Markdown, Export nach PDF fuer Kunden und Audits. + +--- + +## VS Code Extensions + +| Extension | Zweck | +|-----------|-------| +| PlantUML (jebbs.plantuml) | PlantUML-Preview | +| Markdown All in One | Markdown-Editing | +| GitLens | Git-History, Blame | +| YAML (redhat.vscode-yaml) | YAML-Validierung | +| Continue.dev | KI mit Ollama | diff --git a/vorlagen-word/MISRA-Deviation-Permit-vorlage.docx b/vorlagen-word/MISRA-Deviation-Permit-vorlage.docx new file mode 100644 index 0000000..f6612ff Binary files /dev/null and b/vorlagen-word/MISRA-Deviation-Permit-vorlage.docx differ diff --git a/vorlagen-word/MISRA-Deviation-Record-vorlage.docx b/vorlagen-word/MISRA-Deviation-Record-vorlage.docx new file mode 100644 index 0000000..38198bf Binary files /dev/null and b/vorlagen-word/MISRA-Deviation-Record-vorlage.docx differ diff --git a/vorlagen-word/Non-Conformity-vorlage.docx b/vorlagen-word/Non-Conformity-vorlage.docx new file mode 100644 index 0000000..6c1de28 Binary files /dev/null and b/vorlagen-word/Non-Conformity-vorlage.docx differ diff --git a/vorlagen-word/PID-vorlage.docx b/vorlagen-word/PID-vorlage.docx new file mode 100644 index 0000000..c4126d4 Binary files /dev/null and b/vorlagen-word/PID-vorlage.docx differ diff --git a/vorlagen-word/PM-Plan-vorlage.docx b/vorlagen-word/PM-Plan-vorlage.docx new file mode 100644 index 0000000..5732b85 Binary files /dev/null and b/vorlagen-word/PM-Plan-vorlage.docx differ diff --git a/vorlagen-word/QA-Plan-vorlage.docx b/vorlagen-word/QA-Plan-vorlage.docx new file mode 100644 index 0000000..1326ccd Binary files /dev/null and b/vorlagen-word/QA-Plan-vorlage.docx differ diff --git a/vorlagen-word/Review-Protokoll-vorlage.docx b/vorlagen-word/Review-Protokoll-vorlage.docx new file mode 100644 index 0000000..1fa8e59 Binary files /dev/null and b/vorlagen-word/Review-Protokoll-vorlage.docx differ diff --git a/vorlagen-word/SWE-Plan-vorlage.docx b/vorlagen-word/SWE-Plan-vorlage.docx new file mode 100644 index 0000000..ca5351c Binary files /dev/null and b/vorlagen-word/SWE-Plan-vorlage.docx differ diff --git a/vorlagen-word/Test-Plan-vorlage.docx b/vorlagen-word/Test-Plan-vorlage.docx new file mode 100644 index 0000000..4923081 Binary files /dev/null and b/vorlagen-word/Test-Plan-vorlage.docx differ diff --git a/vorlagen-word/angebot-vorlage.docx b/vorlagen-word/angebot-vorlage.docx new file mode 100644 index 0000000..523d0d5 Binary files /dev/null and b/vorlagen-word/angebot-vorlage.docx differ diff --git a/vorlagen-word/slohmaier-doc-template.docx b/vorlagen-word/slohmaier-doc-template.docx new file mode 100644 index 0000000..4e737a3 Binary files /dev/null and b/vorlagen-word/slohmaier-doc-template.docx differ diff --git a/vorlagen/MISRA-Deviation-Permit-vorlage.md b/vorlagen/MISRA-Deviation-Permit-vorlage.md new file mode 100644 index 0000000..235f36a --- /dev/null +++ b/vorlagen/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/vorlagen/MISRA-Deviation-Record-vorlage.md b/vorlagen/MISRA-Deviation-Record-vorlage.md new file mode 100644 index 0000000..372a6e5 --- /dev/null +++ b/vorlagen/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/vorlagen/Non-Conformity-vorlage.md b/vorlagen/Non-Conformity-vorlage.md new file mode 100644 index 0000000..62aa2ae --- /dev/null +++ b/vorlagen/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/vorlagen/PID-vorlage.md b/vorlagen/PID-vorlage.md new file mode 100644 index 0000000..bb2a6ce --- /dev/null +++ b/vorlagen/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/vorlagen/PM-Plan-vorlage.md b/vorlagen/PM-Plan-vorlage.md new file mode 100644 index 0000000..801f83f --- /dev/null +++ b/vorlagen/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/vorlagen/QA-Plan-vorlage.md b/vorlagen/QA-Plan-vorlage.md new file mode 100644 index 0000000..df883e4 --- /dev/null +++ b/vorlagen/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/vorlagen/Review-Protokoll-vorlage.md b/vorlagen/Review-Protokoll-vorlage.md new file mode 100644 index 0000000..dcc7625 --- /dev/null +++ b/vorlagen/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.* diff --git a/vorlagen/SA-vorlage.md b/vorlagen/SA-vorlage.md new file mode 100644 index 0000000..92f30e3 --- /dev/null +++ b/vorlagen/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/vorlagen/SWA-vorlage.md b/vorlagen/SWA-vorlage.md new file mode 100644 index 0000000..6c03e7d --- /dev/null +++ b/vorlagen/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/vorlagen/SWE-Plan-vorlage.md b/vorlagen/SWE-Plan-vorlage.md new file mode 100644 index 0000000..78c9036 --- /dev/null +++ b/vorlagen/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/vorlagen/Test-Plan-vorlage.md b/vorlagen/Test-Plan-vorlage.md new file mode 100644 index 0000000..5f745df --- /dev/null +++ b/vorlagen/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/vorlagen/Traceability-Matrix-vorlage.md b/vorlagen/Traceability-Matrix-vorlage.md new file mode 100644 index 0000000..be6a99a --- /dev/null +++ b/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.* diff --git a/vorlagen/angebot-beispiel.html b/vorlagen/angebot-beispiel.html new file mode 100644 index 0000000..653255b --- /dev/null +++ b/vorlagen/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/vorlagen/angebot-vorlage.md b/vorlagen/angebot-vorlage.md new file mode 100644 index 0000000..8e6ff18 --- /dev/null +++ b/vorlagen/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