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
This commit is contained in:
Stefan Lohmaier
+20
@@ -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
|
||||
@@ -0,0 +1,21 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2026 Stefan Lohmaier <stefan@slohmaier.com>
|
||||
|
||||
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.
|
||||
@@ -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.
|
||||
@@ -0,0 +1,211 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>slohmaier Dev Process – V-Model (ASPICE 4.0 / ISO 26262)</title>
|
||||
<style>
|
||||
@import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&display=swap');
|
||||
* { margin: 0; padding: 0; box-sizing: border-box; }
|
||||
html, body { width: 100%; height: 100%; background: #fff; }
|
||||
@page { size: A4 landscape; margin: 10mm; }
|
||||
@media print {
|
||||
body { -webkit-print-color-adjust: exact; print-color-adjust: exact; }
|
||||
svg { width: 100% !important; height: auto !important; }
|
||||
}
|
||||
body {
|
||||
display: flex; justify-content: center; align-items: flex-start;
|
||||
padding: 20px; font-family: 'Inter', 'Helvetica Neue', Arial, sans-serif;
|
||||
}
|
||||
svg { max-width: 1200px; width: 100%; height: auto; }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1200 800" width="1200" height="800">
|
||||
<defs>
|
||||
<marker id="arr" markerWidth="8" markerHeight="6" refX="7" refY="3" orient="auto">
|
||||
<path d="M0,0 L8,3 L0,6 Z" fill="#5BA5D6"/>
|
||||
</marker>
|
||||
<marker id="arr-t" markerWidth="7" markerHeight="5" refX="6" refY="2.5" orient="auto">
|
||||
<path d="M0,0 L7,2.5 L0,5 Z" fill="#92BDD8"/>
|
||||
</marker>
|
||||
<filter id="sh" x="-3%" y="-5%" width="106%" height="115%">
|
||||
<feDropShadow dx="0" dy="1.5" stdDeviation="2.5" flood-color="#282728" flood-opacity="0.07"/>
|
||||
</filter>
|
||||
</defs>
|
||||
|
||||
<!-- Background -->
|
||||
<rect width="1200" height="800" fill="#ffffff"/>
|
||||
|
||||
<!-- ======================== HEADER ======================== -->
|
||||
<image href="https://slohmaier.com/branding/logo-doc-light.svg" x="30" y="16" width="150" height="38" preserveAspectRatio="xMinYMid meet"/>
|
||||
<text x="600" y="36" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="20" font-weight="700" fill="#282728">Software Development Process</text>
|
||||
<text x="600" y="56" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="11.5" font-weight="400" fill="#888">ASPICE 4.0 / ISO 26262 — V-Model with GitLab Toolchain</text>
|
||||
|
||||
<!-- ======================== SUPPORTING PROCESSES ======================== -->
|
||||
<!-- Horizontal bands spanning the full width -->
|
||||
<rect x="40" y="72" width="1120" height="26" rx="4" fill="#D4A574" opacity="0.13"/>
|
||||
<text x="600" y="89" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="600" fill="#D4A574">SUP.1 — Quality Assurance</text>
|
||||
|
||||
<rect x="40" y="100" width="1120" height="22" rx="4" fill="#D4A574" opacity="0.09"/>
|
||||
<text x="600" y="115" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="9" font-weight="500" fill="#C49564">SUP.8 — Configuration Management (Git / GitLab)</text>
|
||||
|
||||
<rect x="40" y="124" width="1120" height="22" rx="4" fill="#D4A574" opacity="0.06"/>
|
||||
<text x="600" y="139" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="9" font-weight="500" fill="#C49564">SUP.9 — Problem Resolution (GitLab Issues)</text>
|
||||
|
||||
<rect x="40" y="148" width="1120" height="22" rx="4" fill="#D4A574" opacity="0.04"/>
|
||||
<text x="600" y="163" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="9" font-weight="500" fill="#C49564">SUP.10 — Change Request Management (GitLab Merge Requests)</text>
|
||||
|
||||
<!-- ======================== V-MODEL ======================== -->
|
||||
<!--
|
||||
Layout (Y positions):
|
||||
SYS.2 y=195 (top, left only — no right counterpart shown)
|
||||
SWE.1 / SWE.6 y=275 (same height pair)
|
||||
SWE.2 / SWE.5 y=355 (same height pair)
|
||||
SWE.3 / SWE.4 y=435 (same height pair, SWE.3 bottom-center)
|
||||
Implementation y=495 (bottom center)
|
||||
|
||||
Left boxes: x = 55..305 → 65..315 → 115..365 → center
|
||||
Right boxes: x = 835..1095 → 785..1045 → 735..995 → center
|
||||
-->
|
||||
|
||||
<!-- V-shape guide lines (subtle background V) -->
|
||||
<polyline points="190,225 490,525" stroke="#5BA5D6" stroke-opacity="0.12" stroke-width="2.5" fill="none"/>
|
||||
<polyline points="1010,225 710,525" stroke="#5BA5D6" stroke-opacity="0.12" stroke-width="2.5" fill="none"/>
|
||||
|
||||
<!-- Side labels -->
|
||||
<text x="125" y="188" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="700" fill="#5BA5D6" letter-spacing="1.5">SPECIFICATION</text>
|
||||
<text x="1080" y="188" text-anchor="end" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="700" fill="#5BA5D6" letter-spacing="1.5">VERIFICATION</text>
|
||||
|
||||
<!-- ===== SYS.2 — System Requirements (top left, no mirror) ===== -->
|
||||
<g filter="url(#sh)">
|
||||
<rect x="55" y="198" width="270" height="56" rx="6" fill="#f0f2f4" stroke="#5BA5D6" stroke-width="1.5"/>
|
||||
<rect x="55" y="198" width="5" height="56" rx="2.5 0 0 2.5" fill="#5BA5D6"/>
|
||||
<text x="74" y="220" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="700" fill="#5BA5D6">SYS.2</text>
|
||||
<text x="74" y="240" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="13" font-weight="600" fill="#282728">System Requirements</text>
|
||||
</g>
|
||||
|
||||
<!-- ===== SWE.1 — Software Requirements ===== -->
|
||||
<g filter="url(#sh)">
|
||||
<rect x="145" y="278" width="270" height="56" rx="6" fill="#f0f2f4" stroke="#5BA5D6" stroke-width="1.5"/>
|
||||
<rect x="145" y="278" width="5" height="56" rx="2.5 0 0 2.5" fill="#5BA5D6"/>
|
||||
<text x="164" y="300" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="700" fill="#5BA5D6">SWE.1</text>
|
||||
<text x="164" y="320" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="13" font-weight="600" fill="#282728">Software Requirements</text>
|
||||
</g>
|
||||
|
||||
<!-- ===== SWE.6 — Qualification Test (mirrors SWE.1) ===== -->
|
||||
<g filter="url(#sh)">
|
||||
<rect x="785" y="278" width="270" height="56" rx="6" fill="#f0f2f4" stroke="#5BA5D6" stroke-width="1.5"/>
|
||||
<rect x="1050" y="278" width="5" height="56" rx="0 2.5 2.5 0" fill="#5BA5D6"/>
|
||||
<text x="1040" y="300" text-anchor="end" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="700" fill="#5BA5D6">SWE.6</text>
|
||||
<text x="1040" y="320" text-anchor="end" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="13" font-weight="600" fill="#282728">Qualification Test</text>
|
||||
</g>
|
||||
|
||||
<!-- ===== SWE.2 — Software Architecture ===== -->
|
||||
<g filter="url(#sh)">
|
||||
<rect x="235" y="358" width="270" height="56" rx="6" fill="#f0f2f4" stroke="#5BA5D6" stroke-width="1.5"/>
|
||||
<rect x="235" y="358" width="5" height="56" rx="2.5 0 0 2.5" fill="#5BA5D6"/>
|
||||
<text x="254" y="380" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="700" fill="#5BA5D6">SWE.2</text>
|
||||
<text x="254" y="400" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="13" font-weight="600" fill="#282728">Software Architecture</text>
|
||||
</g>
|
||||
|
||||
<!-- ===== SWE.5 — Integration Test (mirrors SWE.2) ===== -->
|
||||
<g filter="url(#sh)">
|
||||
<rect x="695" y="358" width="270" height="56" rx="6" fill="#f0f2f4" stroke="#5BA5D6" stroke-width="1.5"/>
|
||||
<rect x="960" y="358" width="5" height="56" rx="0 2.5 2.5 0" fill="#5BA5D6"/>
|
||||
<text x="950" y="380" text-anchor="end" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="700" fill="#5BA5D6">SWE.5</text>
|
||||
<text x="950" y="400" text-anchor="end" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="13" font-weight="600" fill="#282728">Integration Test</text>
|
||||
</g>
|
||||
|
||||
<!-- ===== SWE.3 — Detail Design (left of bottom) ===== -->
|
||||
<g filter="url(#sh)">
|
||||
<rect x="325" y="438" width="230" height="56" rx="6" fill="#f0f2f4" stroke="#5BA5D6" stroke-width="1.5"/>
|
||||
<rect x="325" y="438" width="5" height="56" rx="2.5 0 0 2.5" fill="#5BA5D6"/>
|
||||
<text x="344" y="460" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="700" fill="#5BA5D6">SWE.3</text>
|
||||
<text x="344" y="480" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="13" font-weight="600" fill="#282728">Detail Design</text>
|
||||
</g>
|
||||
|
||||
<!-- ===== SWE.4 — Unit Verification (mirrors SWE.3) ===== -->
|
||||
<g filter="url(#sh)">
|
||||
<rect x="645" y="438" width="230" height="56" rx="6" fill="#f0f2f4" stroke="#5BA5D6" stroke-width="1.5"/>
|
||||
<rect x="870" y="438" width="5" height="56" rx="0 2.5 2.5 0" fill="#5BA5D6"/>
|
||||
<text x="860" y="460" text-anchor="end" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="700" fill="#5BA5D6">SWE.4</text>
|
||||
<text x="860" y="480" text-anchor="end" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="13" font-weight="600" fill="#282728">Unit Verification</text>
|
||||
</g>
|
||||
|
||||
<!-- ===== IMPLEMENTATION (bottom center, accent filled) ===== -->
|
||||
<g filter="url(#sh)">
|
||||
<rect x="420" y="518" width="360" height="58" rx="6" fill="#5BA5D6"/>
|
||||
<text x="600" y="543" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="600" fill="#fff" opacity="0.8">SWE.3</text>
|
||||
<text x="600" y="562" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="14" font-weight="700" fill="#fff">Implementation</text>
|
||||
</g>
|
||||
|
||||
<!-- ======================== FLOW ARROWS (V path) ======================== -->
|
||||
<!-- Left side: SYS.2 → SWE.1 → SWE.2 → SWE.3 → Implementation -->
|
||||
<line x1="210" y1="254" x2="260" y2="276" stroke="#5BA5D6" stroke-width="2" marker-end="url(#arr)"/>
|
||||
<line x1="300" y1="334" x2="350" y2="356" stroke="#5BA5D6" stroke-width="2" marker-end="url(#arr)"/>
|
||||
<line x1="390" y1="414" x2="420" y2="436" stroke="#5BA5D6" stroke-width="2" marker-end="url(#arr)"/>
|
||||
<line x1="480" y1="494" x2="520" y2="516" stroke="#5BA5D6" stroke-width="2" marker-end="url(#arr)"/>
|
||||
|
||||
<!-- Right side: Implementation → SWE.4 → SWE.5 → SWE.6 -->
|
||||
<line x1="680" y1="516" x2="720" y2="496" stroke="#5BA5D6" stroke-width="2" marker-end="url(#arr)"/>
|
||||
<line x1="790" y1="438" x2="810" y2="416" stroke="#5BA5D6" stroke-width="2" marker-end="url(#arr)"/>
|
||||
<line x1="880" y1="358" x2="900" y2="336" stroke="#5BA5D6" stroke-width="2" marker-end="url(#arr)"/>
|
||||
|
||||
<!-- ======================== TRACEABILITY ARROWS (horizontal dashed) ======================== -->
|
||||
<!-- SWE.1 ↔ SWE.6 (y=306, same height) -->
|
||||
<line x1="415" y1="306" x2="783" y2="306" stroke="#92BDD8" stroke-width="1.2" stroke-dasharray="6,4" marker-end="url(#arr-t)"/>
|
||||
<rect x="548" y="293" width="102" height="16" rx="3" fill="#fff" fill-opacity="0.85"/>
|
||||
<text x="600" y="304" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="8.5" font-weight="600" fill="#92BDD8">Traceability</text>
|
||||
|
||||
<!-- SWE.2 ↔ SWE.5 (y=386, same height) -->
|
||||
<line x1="505" y1="386" x2="693" y2="386" stroke="#92BDD8" stroke-width="1.2" stroke-dasharray="6,4" marker-end="url(#arr-t)"/>
|
||||
<rect x="548" y="373" width="102" height="16" rx="3" fill="#fff" fill-opacity="0.85"/>
|
||||
<text x="600" y="384" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="8.5" font-weight="600" fill="#92BDD8">Traceability</text>
|
||||
|
||||
<!-- SWE.3 ↔ SWE.4 (y=466, same height) -->
|
||||
<line x1="555" y1="466" x2="643" y2="466" stroke="#92BDD8" stroke-width="1.2" stroke-dasharray="6,4" marker-end="url(#arr-t)"/>
|
||||
|
||||
<!-- ======================== TOOLCHAIN BAR ======================== -->
|
||||
<line x1="50" y1="600" x2="1150" y2="600" stroke="#e0e0e0" stroke-width="1"/>
|
||||
<text x="600" y="622" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="10" font-weight="700" fill="#282728" letter-spacing="2">TOOLCHAIN</text>
|
||||
|
||||
<!-- Tool boxes (6 items, evenly spaced) -->
|
||||
<!-- GitLab -->
|
||||
<rect x="52" y="636" width="175" height="48" rx="5" fill="#f0f2f4" stroke="#d0d0d0" stroke-width="1"/>
|
||||
<text x="139" y="656" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="11" font-weight="600" fill="#282728">GitLab</text>
|
||||
<text x="139" y="672" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="8.5" font-weight="400" fill="#666">Source · Wiki · Reviews · CI/CD</text>
|
||||
|
||||
<!-- Cppcheck + MISRA -->
|
||||
<rect x="239" y="636" width="145" height="48" rx="5" fill="#f0f2f4" stroke="#d0d0d0" stroke-width="1"/>
|
||||
<text x="311" y="656" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="11" font-weight="600" fill="#282728">Cppcheck</text>
|
||||
<text x="311" y="672" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="8.5" font-weight="400" fill="#666">MISRA Compliance</text>
|
||||
|
||||
<!-- gcov/lcov -->
|
||||
<rect x="396" y="636" width="155" height="48" rx="5" fill="#f0f2f4" stroke="#d0d0d0" stroke-width="1"/>
|
||||
<text x="473" y="656" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="11" font-weight="600" fill="#282728">gcov / lcov</text>
|
||||
<text x="473" y="672" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="8.5" font-weight="400" fill="#666">MCDC-Star Coverage</text>
|
||||
|
||||
<!-- CppUTest / Google Test -->
|
||||
<rect x="563" y="636" width="155" height="48" rx="5" fill="#f0f2f4" stroke="#d0d0d0" stroke-width="1"/>
|
||||
<text x="640" y="656" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="11" font-weight="600" fill="#282728">CppUTest</text>
|
||||
<text x="640" y="672" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="8.5" font-weight="400" fill="#666">Google Test</text>
|
||||
|
||||
<!-- ScanCode / FOSSology -->
|
||||
<rect x="730" y="636" width="155" height="48" rx="5" fill="#f0f2f4" stroke="#d0d0d0" stroke-width="1"/>
|
||||
<text x="807" y="656" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="11" font-weight="600" fill="#282728">ScanCode</text>
|
||||
<text x="807" y="672" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="8.5" font-weight="400" fill="#666">FOSSology</text>
|
||||
|
||||
<!-- pandoc -->
|
||||
<rect x="897" y="636" width="155" height="48" rx="5" fill="#f0f2f4" stroke="#d0d0d0" stroke-width="1"/>
|
||||
<text x="974" y="656" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="11" font-weight="600" fill="#282728">pandoc</text>
|
||||
<text x="974" y="672" text-anchor="middle" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="8.5" font-weight="400" fill="#666">Document Export</text>
|
||||
|
||||
<!-- ======================== FOOTER ======================== -->
|
||||
<line x1="40" y1="710" x2="1160" y2="710" stroke="#eaeaea" stroke-width="0.5"/>
|
||||
<text x="40" y="728" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="9" font-weight="400" fill="#aaa">slohmaier.com</text>
|
||||
<text x="1160" y="728" text-anchor="end" font-family="Inter, Helvetica Neue, Arial, sans-serif" font-size="9" font-weight="400" fill="#aaa">ASPICE 4.0 / ISO 26262 compliant process overview</text>
|
||||
|
||||
</svg>
|
||||
</body>
|
||||
</html>
|
||||
@@ -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 #<issue-nummer>"
|
||||
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: `<type>(<id>): <beschreibung>`
|
||||
|
||||
## 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.
|
||||
@@ -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="<Feld aktualisieren mit F9>"):
|
||||
"""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="<DOC-ID>", 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("<PROJEKT>")
|
||||
r1.font.size = Pt(9)
|
||||
r1.font.color.rgb = RGBColor(0x59, 0x59, 0x59)
|
||||
header_para.add_run("\t")
|
||||
r2 = header_para.add_run("<DOKUMENT-TITEL>")
|
||||
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("<Dokument-Titel>")
|
||||
|
||||
# Subtitle
|
||||
sub_p = doc.add_paragraph(style="Subtitle")
|
||||
sub_p.alignment = WD_ALIGN_PARAGRAPH.CENTER
|
||||
sub_p.add_run("<Untertitel oder Kurzbeschreibung>")
|
||||
|
||||
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", "<Projektname>"),
|
||||
("Dokument-ID", "<DOC-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", "<Autor>"),
|
||||
("1.0", "YYYY-MM-DD", "Erstfreigabe", "<Autor>"),
|
||||
]
|
||||
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(
|
||||
"<Kurzer Absatz: Wozu existiert dieses Dokument? Welche Frage beantwortet es?>"
|
||||
)
|
||||
doc.add_heading("1.2 Geltungsbereich", level=2)
|
||||
doc.add_paragraph("<Welches Produkt, welches Projekt, welche Phase?>")
|
||||
doc.add_heading("1.3 Definitionen", level=2)
|
||||
doc.add_paragraph(
|
||||
"<Spezielle Begriffe, die im Dokument verwendet werden. Allgemeine Abkuerzungen "
|
||||
"siehe Abkuerzungsverzeichnis.>"
|
||||
)
|
||||
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(
|
||||
"<Hier beginnt der dokumenttyp-spezifische Inhalt. Die Vorlage liefert Struktur "
|
||||
"und Formatvorlagen; konkrete Sektionen kommen aus der jeweiligen Dokumentart "
|
||||
"(PID, QA-Plan, SWE-Plan, ...).>"
|
||||
)
|
||||
|
||||
# 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(
|
||||
"<Anhaenge: Detail-Berechnungen, Skripte, Zusatz-Tabellen, Glossar.>"
|
||||
)
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 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)
|
||||
Executable
+52
@@ -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/"
|
||||
@@ -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 |
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -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.*
|
||||
@@ -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.*
|
||||
@@ -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.*
|
||||
@@ -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.*
|
||||
@@ -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.*
|
||||
@@ -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.*
|
||||
@@ -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.*
|
||||
@@ -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).*
|
||||
@@ -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).*
|
||||
@@ -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.*
|
||||
@@ -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.*
|
||||
@@ -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.*
|
||||
@@ -0,0 +1,144 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>Angebot: Accessibility Audit – slohmaier Engineering</title>
|
||||
<style>
|
||||
:root {
|
||||
--text: #111417;
|
||||
--text-light: #525c69;
|
||||
--border: #d0d5dd;
|
||||
--bg: #ffffff;
|
||||
color-scheme: light dark;
|
||||
}
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--text: #f0f2f4;
|
||||
--text-light: #9ca3af;
|
||||
--border: #2a2e33;
|
||||
--bg: #111417;
|
||||
}
|
||||
.logo-light { display: none !important; }
|
||||
.logo-dark { display: block !important; }
|
||||
}
|
||||
@media (prefers-color-scheme: light) {
|
||||
.logo-dark { display: none !important; }
|
||||
.logo-light { display: block !important; }
|
||||
}
|
||||
body {
|
||||
font-family: Aptos, Inter, -apple-system, Helvetica Neue, Arial, sans-serif;
|
||||
font-size: 16px;
|
||||
line-height: 1.65;
|
||||
color: var(--text);
|
||||
background: var(--bg);
|
||||
max-width: 820px;
|
||||
margin: 0 auto;
|
||||
padding: 48px 40px;
|
||||
}
|
||||
.logo img { width: 280px; height: auto; margin-bottom: 32px; display: block; }
|
||||
h1 { font-size: 2rem; font-weight: 700; margin-top: 0; }
|
||||
h2 { font-size: 1.2rem; font-weight: 600; border-bottom: 1px solid var(--border); padding-bottom: 6px; margin-top: 40px; }
|
||||
h3 { font-size: 1rem; font-weight: 600; margin-top: 24px; }
|
||||
hr { border: none; border-top: 1px solid var(--border); margin: 32px 0; }
|
||||
table { width: 100%; border-collapse: collapse; font-size: 0.95rem; }
|
||||
th { text-align: left; border-bottom: 2px solid var(--border); padding: 8px 12px; font-weight: 600; }
|
||||
td { border-bottom: 1px solid var(--border); padding: 8px 12px; color: var(--text-light); }
|
||||
p { color: var(--text); }
|
||||
ul { color: var(--text-light); }
|
||||
strong { color: var(--text); }
|
||||
ol li { margin-bottom: 4px; }
|
||||
.meta { color: var(--text-light); font-size: 0.95rem; }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<div class="logo">
|
||||
<img src="https://slohmaier.com/branding/logo-doc-light.svg" alt="slohmaier" class="logo-light" />
|
||||
<img src="https://slohmaier.com/branding/logo-doc-dark.svg" alt="slohmaier" class="logo-dark" />
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
|
||||
<h1>Angebot: Accessibility Audit</h1>
|
||||
|
||||
<p class="meta">
|
||||
<strong>Datum:</strong> 03.04.2026
|
||||
<strong>Version:</strong> 1.0<br>
|
||||
<strong>Projekt:</strong> Accessibility Review – DemoApp v2.3<br>
|
||||
<strong>Auftraggeber:</strong> Acme GmbH, Berlin
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<h2>Zusammenfassung</h2>
|
||||
<p>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.</p>
|
||||
|
||||
<h2>Inhalt</h2>
|
||||
|
||||
<h3>1. Ziel</h3>
|
||||
<p>Prüfung der Anwendung auf Bedienbarkeit mit NVDA (Windows) sowie Identifikation und Beschreibung konkreter Accessibility-Mängel mit Handlungsempfehlungen.</p>
|
||||
|
||||
<h3>2. Umfang</h3>
|
||||
<ul>
|
||||
<li>Vollständiger Durchgang aller Hauptdialoge und Workflows mit NVDA</li>
|
||||
<li>Prüfung auf UIA-Baumstruktur und korrekte Rollen/Namen/Beschreibungen</li>
|
||||
<li>Dokumentation aller Befunde mit Reproduktionsschritten und Schweregrad</li>
|
||||
<li>Priorisierte Handlungsempfehlungen</li>
|
||||
</ul>
|
||||
<p><strong>Nicht enthalten:</strong> Implementierung von Korrekturen, Regressionstesting nach Fixes.</p>
|
||||
|
||||
<h3>3. Anforderungen</h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>Nr.</th><th>Anforderung</th><th>Priorität</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>1</td><td>Vollständige NVDA-Bedienbarkeit aller Workflows</td><td>Muss</td></tr>
|
||||
<tr><td>2</td><td>UIA-konforme Benennung aller Steuerelemente</td><td>Muss</td></tr>
|
||||
<tr><td>3</td><td>Tastaturnavigation ohne Maus</td><td>Muss</td></tr>
|
||||
<tr><td>4</td><td>Logische Fokusreihenfolge</td><td>Soll</td></tr>
|
||||
<tr><td>5</td><td>Kontraste mind. WCAG 2.1 AA</td><td>Soll</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3>4. Vorgehen</h3>
|
||||
<ol>
|
||||
<li>Einrichtung der Testumgebung (Windows 11, NVDA 2024.4)</li>
|
||||
<li>Manueller Test aller Hauptdialoge und Workflows</li>
|
||||
<li>UIA-Dump-Analyse mit dumpUIA</li>
|
||||
<li>Dokumentation der Befunde</li>
|
||||
<li>Übergabe Auditbericht als PDF</li>
|
||||
</ol>
|
||||
<p>Geschätzte Dauer: <strong>3 Werktage</strong></p>
|
||||
|
||||
<h3>5. Offene Punkte</h3>
|
||||
<ul>
|
||||
<li>Übergabe Testversion der Anwendung</li>
|
||||
<li>Zugang zu Testdaten für repräsentative Workflows</li>
|
||||
</ul>
|
||||
|
||||
<h3>6. Lieferergebnis</h3>
|
||||
<p>Auditbericht (PDF) mit:</p>
|
||||
<ul>
|
||||
<li>Zusammenfassung und Gesamtbewertung</li>
|
||||
<li>Vollständige Befundliste mit Schweregrad, Screenshot, Reproduktionsschritten</li>
|
||||
<li>Priorisierte Handlungsempfehlungen</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<h2>Konditionen</h2>
|
||||
<p>
|
||||
Tagessatz: auf Anfrage<br>
|
||||
Zahlungsziel: 14 Tage nach Rechnungsstellung<br>
|
||||
Gültig bis: 17.04.2026
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<p><strong>Stefan Lohmaier</strong><br>
|
||||
slohmaier.com · stefan@slohmaier.de</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,76 @@
|
||||
<!-- slohmaier Engineering – Angebotsvorlage -->
|
||||
<!-- Verwendung: Platzhalter {{ ... }} ersetzen, dann mit pandoc exportieren -->
|
||||
<!-- Export: pandoc angebot.md -o angebot.html --standalone -->
|
||||
<!-- Beispiel: angebot-beispiel.html -->
|
||||
|
||||
<div class="logo">
|
||||
<img src="https://slohmaier.com/branding/logo-doc-light.svg" alt="slohmaier" class="logo-light" />
|
||||
<img src="https://slohmaier.com/branding/logo-doc-dark.svg" alt="slohmaier" class="logo-dark" />
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# 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
|
||||
Reference in New Issue
Block a user