slohmaier/dev-process
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(i18n): dev-process repo in English

Browse Source 
- README.md: full English rewrite
- All 13 vorlagen MD templates hand-translated:
  PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan,
  SA, SWA, Review-Protokoll, Non-Conformity,
  MISRA-Deviation-Permit, MISRA-Deviation-Record,
  Traceability-Matrix, angebot (quotation)
- Master Word template (slohmaier-doc-template.docx) regenerated
  in English: cover page, document control, TOC headers,
  classification banner all English
- All derived Word vorlagen regenerated from English MD sources

Still to translate: toolstack.md, gitea-aspice-setup.md
This commit is contained in:
Stefan Lohmaier
2026-05-12 03:42:35 -07:00
parent 6e458ae76f
commit d5cfec9e42
25 changed files with 774 additions and 875 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+88 -88
View File
@@ -1,41 +1,41 @@
# slohmaier Dev Process # 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. A practical development process aligned with ASPICE 4.0 / ISO 26262, implemented with Gitea, Doorstop, MS Word, and VS Code. Designed for freelance projects and small teams.
**Demo-Projekt:** [slohmaier/demo-epb](https://gitea.slohmaier.com/slohmaier/demo-epb) — Elektrische Parkbremse, wendet diesen Prozess vollständig an. **Demo project:** [slohmaier/demo-epb](https://gitea.slohmaier.com/slohmaier/demo-epb) — Electric Parking Brake, applies this process end-to-end.
## Grundprinzip ## Core principle
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. Everything lives in a **monorepo**. Requirements, documents, code, and tests sit together in one Git repository. All changes go through pull requests with approval — that's the formal review record.
## Format-Strategie: Hybrid ## Format strategy: hybrid
Die zwei Welten — ISO-9001-Audit und tägliches Engineering — haben unterschiedliche Anforderungen. Wir trennen sauber: The two worlds — ISO-9001 audits vs day-to-day engineering — have different needs. We split cleanly:
| Artefakt | Format | Begründung | | Artifact | Format | Rationale |
|----------|--------|------------| |----------|--------|-----------|
| PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan | **Word** (signiert) | Formell freigegeben, an Kunden geliefert | | PID, PM Plan, QA Plan, SWE Plan, Test Plan | **Word** (signed) | Formally released, delivered to customers |
| Reviews, Non-Conformities, Audit-Protokolle | **Word** | Audit-Artefakte | | Reviews, non-conformities, audit minutes | **Word** | Audit artifacts |
| MISRA Permits / Records | **Word** | Audit-Artefakte | | MISRA permits / records | **Word** | Audit artifacts |
| Angebote, Verträge | **Word** | klar | | Quotations, contracts | **Word** | obvious |
| Requirements (SYS, SWE) | **Markdown** (Doorstop) | Diff, Traceability, lebt täglich | | Requirements (SYS, SWE) | **Markdown** (Doorstop) | Diff, traceability, lives daily |
| Architektur (SA, SWA, SWD) | **Markdown** (Doorstop) | Mapping per `links:` | | Architecture (SA, SWA, SWD) | **Markdown** (Doorstop) | Mapping via `links:` |
| Code, Tests, CI | Code | klar | | Code, tests, CI | source | obvious |
| Liefer-PDFs an Kunden | **PDF via pandoc** aus MD | formelle Übergabe der Engineering-Artefakte | | Customer-facing PDFs | **PDF via pandoc** from MD | formal handover of engineering artifacts |
**Markdown-Vorlagen sind Source of Truth**, Word wird daraus per pandoc gebaut (`tools/generate_word_vorlagen.sh`). **Markdown templates are the source of truth**; Word is built from them via pandoc (`tools/generate_word_vorlagen.sh`).
## Monorepo-Struktur ## Monorepo structure
``` ```
projekt-name/ project-name/
reqs/ reqs/
sys/ SYS-001.md, SYS-002.md sys/ SYS-001.md, SYS-002.md
swe/ SWE-001.md, SWE-002.md swe/ SWE-001.md, SWE-002.md
arch/ arch/
sys/ SA-001.md, SA-002.md (ASPICE SYS.3) sys/ SA-001.md, SA-002.md (ASPICE SYS.3)
swe/ SWA-001.md, SWA-002.md (ASPICE SWE.2) swe/ SWA-001.md, SWA-002.md (ASPICE SWE.2)
swd/ SWD-001.md (ASPICE SWE.3, ab ASIL-C) swd/ SWD-001.md (ASPICE SWE.3, ASIL-C+)
docs/ docs/
PID.md PID.md
PM-Plan.md PM-Plan.md
@@ -44,7 +44,7 @@ projekt-name/
Test-Plan.md Test-Plan.md
reviews/ reviews/
non-conformities/ non-conformities/
traceability/ (generiert von Doorstop) traceability/ (generated by Doorstop)
src/ src/
tests/ tests/
unit/ unit/
@@ -59,9 +59,9 @@ projekt-name/
.doorstop.yml .doorstop.yml
``` ```
## Anforderungen mit Doorstop (Markdown-Modus) ## Requirements with Doorstop (markdown mode)
Requirements sind `.md`-Dateien mit YAML-Frontmatter. PlantUML-Diagramme direkt einbettbar. Requirements are `.md` files with YAML frontmatter. PlantUML diagrams embed directly.
```markdown ```markdown
--- ---
@@ -71,9 +71,9 @@ links:
- SYS-001: abc123 - SYS-001: abc123
--- ---
# SWE-001: CAN Bus Initialisierung # SWE-001: CAN Bus Initialization
Der CAN-Treiber muss den Bus mit konfigurierbarer Baudrate initialisieren. The CAN driver must initialize the bus with configurable baud rate.
```plantuml ```plantuml
@startuml @startuml
@@ -84,22 +84,22 @@ Hardware --> CANDriver: ok
``` ```
``` ```
Gitea rendert das direkt. VS Code mit PlantUML-Extension zeigt die Preview beim Editieren. Gitea renders this natively. VS Code with the PlantUML extension shows a live preview.
Doorstop prüft: Doorstop verifies:
- Alle Links valide - All links resolve
- Alle Requirements haben Tests - All requirements have tests
- Keine Lücken in der Traceability - No gaps in traceability
## Architektur-Design (ASPICE SYS.3 / SWE.2) ## Architecture 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. Architecture elements live in `arch/` and are also Doorstop documents. Same mechanism as requirements: Markdown + YAML frontmatter + embedded PlantUML.
- `arch/sys/SA-XXX.md` — System-Architektur, Mapping auf SYS-Anforderungen - `arch/sys/SA-XXX.md` — system architecture, mapping to SYS requirements
- `arch/swe/SWA-XXX.md` — Software-Architektur, Mapping auf SWE-Anforderungen - `arch/swe/SWA-XXX.md` — software architecture, mapping to SWE requirements
- `arch/swd/SWD-XXX.md` — Software Detailed Design (nur ab ASIL-C) - `arch/swd/SWD-XXX.md` — software detailed design (ASIL-C+ only)
**Mapping** geschieht über `links:` im Frontmatter: **Mapping** via `links:` in frontmatter:
```markdown ```markdown
--- ---
@@ -113,12 +113,12 @@ links:
# SWA-003: CAN Driver Component # SWA-003: CAN Driver Component
``` ```
`doorstop check` verifiziert in beide Richtungen: `doorstop check` verifies bidirectionally:
- Jede SWE-Anforderung wird von mindestens einem SWA-Element abgedeckt - Every SWE requirement is covered by at least one SWA element
- Jedes SWA-Element verweist auf mindestens eine SWE-Anforderung - Every SWA element points to at least one SWE requirement
- `doorstop publish all docs/traceability/` erzeugt die Traceability-Matrix - `doorstop publish all docs/traceability/` produces the traceability matrix
**Code → Architektur** per Header-Kommentar im Modul: **Code → architecture** via header comment:
```c ```c
/** /**
@@ -128,82 +128,82 @@ links:
*/ */
``` ```
Vorlagen: `vorlagen/SA-vorlage.md`, `vorlagen/SWA-vorlage.md`. Templates: `vorlagen/SA-vorlage.md`, `vorlagen/SWA-vorlage.md`.
## Reviews ## Reviews
Jede Änderung — an Code, Requirements, Dokumenten oder Plänen — geht über einen Pull Request. Every change — to code, requirements, documents, or plans — goes through a pull request.
| Was | Approver | | Item | Approver |
|-----|----------| |------|----------|
| Requirement neu/ändern | mind. 1 Reviewer | | New / changed requirement | ≥ 1 reviewer |
| Architektur-Element (SA/SWA/SWD) | mind. 2 Technical Reviewer | | Architecture element (SA/SWA/SWD) | ≥ 2 technical reviewers |
| Dokument (Plan, Protokoll) | mind. 1 Reviewer | | Document (plan, minutes) | ≥ 1 reviewer |
| Code-Änderung | mind. 1 Reviewer | | Code change | ≥ 1 reviewer |
| MISRA Permit | Technical Lead | | MISRA permit | technical lead |
Merge = formale Freigabe. Git-History ist der Audit-Trail. Merge = formal release. Git history is the audit trail.
## Traceability ## Traceability
Vier Ebenen werden verknüpft: Four levels are linked:
1. **Doorstop-Links** in `.md`-Dateien: `links: [SYS-001: abc123]` 1. **Doorstop links** in `.md` files: `links: [SYS-001: abc123]`
2. **Architektur-Mapping** (Arch-Element → Anforderung) ebenfalls per Doorstop 2. **Architecture mapping** (arch element → requirement) also via Doorstop
3. **Commit-Messages**: `feat(SWE-001): implement CAN init` oder `feat(SWA-003): ...` 3. **Commit messages**: `feat(SWE-001): implement CAN init` or `feat(SWA-003): ...`
4. **Issue-Referenzen** in PRs: `Refs #42` 4. **Issue references** in PRs: `Refs #42`
Chain: `SYS-XXX → SA-XXX → SWE-XXX → SWA-XXX → Code → Test` Chain: `SYS-XXX → SA-XXX → SWE-XXX → SWA-XXX → code → test`
Doorstop erzeugt automatisch einen Traceability-Report: Doorstop generates the matrix automatically:
```bash ```bash
doorstop publish all docs/traceability/ doorstop publish all docs/traceability/
``` ```
## CI-Pipeline ## CI pipeline
Läuft bei jedem Push und PR automatisch: Runs on every push and PR:
1. `doorstop check` — Requirements-Links valide 1. `doorstop check` — requirement links valid
2. `cppcheck --addon=misra` — MISRA-Compliance 2. `cppcheck --addon=misra` — MISRA compliance
3. `make test` — Unit Tests 3. `make test` — unit tests
4. `make coverage` — Coverage-Report 4. `make coverage` — coverage report
5. `doorstop publish` — Traceability-Report aktualisieren 5. `doorstop publish` — refresh traceability report
## Dateien in diesem Repo ## Files in this repo
| Pfad | Inhalt | | Path | Content |
|------|--------| |------|---------|
| `toolstack/toolstack.md` | Vollständiger Tool-Stack | | `toolstack/toolstack.md` | Complete tool stack |
| `gitea-aspice-setup.md` | Gitea einrichten für ASPICE | | `gitea-aspice-setup.md` | Setting up Gitea for ASPICE |
| `dev-process-schaubild.html` | V-Modell Infografik | | `dev-process-schaubild.html` | V-model infographic |
| `vorlagen/` | Markdown-Vorlagen (Source of Truth) | | `vorlagen/` | Markdown templates (source of truth) |
| `vorlagen-word/` | Generierte Word-Vorlagen + Master-Template `slohmaier-doc-template.docx` | | `vorlagen-word/` | Generated Word templates + master template `slohmaier-doc-template.docx` |
| `tools/build_word_template.py` | Erzeugt das neutrale Master-Word-Template mit Formatvorlagen, Deckblatt, Document Control | | `tools/build_word_template.py` | Builds the neutral Word master template with styles, cover page, document control |
| `tools/generate_word_vorlagen.sh` | Erzeugt aus den `.md`-Vorlagen die `.docx`-Versionen via pandoc | | `tools/generate_word_vorlagen.sh` | Builds the `.docx` versions from the `.md` templates via pandoc |
## Word-Vorlagen neu generieren ## Regenerate Word templates
```bash ```bash
# Master-Template + alle abgeleiteten Word-Vorlagen neu bauen # Rebuild master template + all derived Word templates
python3 tools/build_word_template.py python3 tools/build_word_template.py
bash tools/generate_word_vorlagen.sh bash tools/generate_word_vorlagen.sh
``` ```
Das Master-Template enthält ISO-9001-konform: The master template is ISO-9001-compliant and includes:
- Deckblatt mit Projekt, Dokument-ID, Version, Klassifikation - Cover page with project, document ID, version, classification
- Document Control (Freigaben, Änderungshistorie, Verteiler) - Document control (approvals, revision history, distribution)
- Auto-Verzeichnisse (Inhalt, Abbildungen, Tabellen) - Auto-tables of contents, figures, and tables
- Formatvorlagen für H1–H4, Body, Code, Note, Warning, Requirement - Styles for H1–H4, Body, Code, Note, Warning, Requirement
- Header/Footer mit Projekt, Dokument-ID, Klassifikation, Seitennummer - Header/footer with project, document ID, classification, page number
## Einsatz in eigenen Projekten ## Using this process in your own projects
Drei Wege, diesen Prozess zu nutzen: Three options:
1. **Git-Submodule** in dein Projekt: 1. **Git submodule** in your project:
```bash ```bash
git submodule add https://gitea.slohmaier.com/slohmaier/dev-process .dev-process git submodule add https://gitea.slohmaier.com/slohmaier/dev-process .dev-process
``` ```
2. **Vorlagen kopieren** und im Projekt einchecken (statischer Snapshot). 2. **Copy templates** into the project and commit (static snapshot).
3. **Fork / Clone** und als Basis für eigene Anpassungen verwenden. 3. **Fork / clone** and use as the base for your own customisations.
tools/build_word_template.py
+66 -66
View File
@@ -223,7 +223,7 @@ def setup_page(doc):
section.footer_distance = Cm(1.25) section.footer_distance = Cm(1.25)
def build_header_footer(doc, doc_id_placeholder="<DOC-ID>", classification="VERTRAULICH"): def build_header_footer(doc, doc_id_placeholder="<DOC-ID>", classification="CONFIDENTIAL"):
section = doc.sections[0] section = doc.sections[0]
section.different_first_page_header_footer = True section.different_first_page_header_footer = True
@@ -234,11 +234,11 @@ def build_header_footer(doc, doc_id_placeholder="<DOC-ID>", classification="VERT
tabs = header_para.paragraph_format.tab_stops tabs = header_para.paragraph_format.tab_stops
tabs.add_tab_stop(Cm(8), WD_ALIGN_PARAGRAPH.CENTER) tabs.add_tab_stop(Cm(8), WD_ALIGN_PARAGRAPH.CENTER)
tabs.add_tab_stop(Cm(16), WD_ALIGN_PARAGRAPH.RIGHT) tabs.add_tab_stop(Cm(16), WD_ALIGN_PARAGRAPH.RIGHT)
r1 = header_para.add_run("<PROJEKT>") r1 = header_para.add_run("<PROJECT>")
r1.font.size = Pt(9) r1.font.size = Pt(9)
r1.font.color.rgb = RGBColor(0x59, 0x59, 0x59) r1.font.color.rgb = RGBColor(0x59, 0x59, 0x59)
header_para.add_run("\t") header_para.add_run("\t")
r2 = header_para.add_run("<DOKUMENT-TITEL>") r2 = header_para.add_run("<DOCUMENT-TITLE>")
r2.font.size = Pt(9) r2.font.size = Pt(9)
r2.font.color.rgb = RGBColor(0x59, 0x59, 0x59) r2.font.color.rgb = RGBColor(0x59, 0x59, 0x59)
r2.bold = True r2.bold = True
@@ -263,7 +263,7 @@ def build_header_footer(doc, doc_id_placeholder="<DOC-ID>", classification="VERT
fr2.font.color.rgb = RGBColor(0x59, 0x59, 0x59) fr2.font.color.rgb = RGBColor(0x59, 0x59, 0x59)
fr2.bold = True fr2.bold = True
footer_para.add_run("\t") footer_para.add_run("\t")
fr3 = footer_para.add_run("Seite ") fr3 = footer_para.add_run("Page ")
fr3.font.size = Pt(9) fr3.font.size = Pt(9)
fr3.font.color.rgb = RGBColor(0x59, 0x59, 0x59) fr3.font.color.rgb = RGBColor(0x59, 0x59, 0x59)
add_field(footer_para, "PAGE", "1") add_field(footer_para, "PAGE", "1")
@@ -298,7 +298,7 @@ def add_cover_page(doc):
# Classification banner # Classification banner
cls_p = doc.add_paragraph() cls_p = doc.add_paragraph()
cls_p.alignment = WD_ALIGN_PARAGRAPH.CENTER cls_p.alignment = WD_ALIGN_PARAGRAPH.CENTER
cls_r = cls_p.add_run("VERTRAULICH") cls_r = cls_p.add_run("CONFIDENTIAL")
cls_r.font.size = Pt(11) cls_r.font.size = Pt(11)
cls_r.font.bold = True cls_r.font.bold = True
cls_r.font.color.rgb = RGBColor(0xC5, 0x5A, 0x11) cls_r.font.color.rgb = RGBColor(0xC5, 0x5A, 0x11)
@@ -306,12 +306,12 @@ def add_cover_page(doc):
# Title # Title
title_p = doc.add_paragraph(style="Title") title_p = doc.add_paragraph(style="Title")
title_p.alignment = WD_ALIGN_PARAGRAPH.CENTER title_p.alignment = WD_ALIGN_PARAGRAPH.CENTER
title_p.add_run("<Dokument-Titel>") title_p.add_run("<Document title>")
# Subtitle # Subtitle
sub_p = doc.add_paragraph(style="Subtitle") sub_p = doc.add_paragraph(style="Subtitle")
sub_p.alignment = WD_ALIGN_PARAGRAPH.CENTER sub_p.alignment = WD_ALIGN_PARAGRAPH.CENTER
sub_p.add_run("<Untertitel oder Kurzbeschreibung>") sub_p.add_run("<Subtitle or short description>")
for _ in range(4): for _ in range(4):
doc.add_paragraph() doc.add_paragraph()
@@ -323,12 +323,12 @@ def add_cover_page(doc):
meta_tbl.columns[0].width = Cm(4.5) meta_tbl.columns[0].width = Cm(4.5)
meta_tbl.columns[1].width = Cm(8.5) meta_tbl.columns[1].width = Cm(8.5)
meta_data = [ meta_data = [
("Projekt", "<Projektname>"), ("Project", "<Project name>"),
("Dokument-ID", "<DOC-ID>"), ("Document ID", "<DOC-ID>"),
("Version", "1.0"), ("Version", "1.0"),
("Datum", "YYYY-MM-DD"), ("Date", "YYYY-MM-DD"),
("Status", "Entwurf"), ("Status", "Draft"),
("Klassifikation", "Vertraulich"), ("Classification", "Confidential"),
] ]
for i, (k, v) in enumerate(meta_data): for i, (k, v) in enumerate(meta_data):
c1 = meta_tbl.cell(i, 0) c1 = meta_tbl.cell(i, 0)
@@ -354,49 +354,49 @@ def add_cover_page(doc):
def add_document_control(doc): def add_document_control(doc):
doc.add_heading("Dokumentenlenkung", level=1) doc.add_heading("Document Control", level=1)
doc.add_paragraph( doc.add_paragraph(
"Diese Seite dokumentiert die formale Lenkung dieses Dokuments gemaess " "This page documents the formal control of this document per ISO 9001. "
"ISO 9001. Aenderungen werden nur ueber den Freigabeprozess wirksam." "Changes only take effect after the release process."
) )
doc.add_heading("Freigaben", level=2) doc.add_heading("Approvals", level=2)
appr_tbl = doc.add_table(rows=4, cols=4) appr_tbl = doc.add_table(rows=4, cols=4)
appr_tbl.style = "Light Grid Accent 1" appr_tbl.style = "Light Grid Accent 1"
hdr = appr_tbl.rows[0].cells hdr = appr_tbl.rows[0].cells
for i, h in enumerate(["Rolle", "Name", "Unterschrift / Datum", "Bemerkung"]): for i, h in enumerate(["Role", "Name", "Signature / Date", "Notes"]):
hdr[i].text = "" hdr[i].text = ""
r = hdr[i].paragraphs[0].add_run(h) r = hdr[i].paragraphs[0].add_run(h)
r.bold = True r.bold = True
set_cell_shading(hdr[i], LIGHT_GREY) set_cell_shading(hdr[i], LIGHT_GREY)
roles = ["Erstellt von", "Geprueft von", "Freigegeben von"] roles = ["Author", "Reviewer", "Approver"]
for i, role in enumerate(roles, start=1): for i, role in enumerate(roles, start=1):
appr_tbl.rows[i].cells[0].text = role appr_tbl.rows[i].cells[0].text = role
for j in (1, 2, 3): for j in (1, 2, 3):
appr_tbl.rows[i].cells[j].text = "" appr_tbl.rows[i].cells[j].text = ""
doc.add_heading("Aenderungshistorie", level=2) doc.add_heading("Revision History", level=2)
rev_tbl = doc.add_table(rows=3, cols=4) rev_tbl = doc.add_table(rows=3, cols=4)
rev_tbl.style = "Light Grid Accent 1" rev_tbl.style = "Light Grid Accent 1"
rev_hdr = rev_tbl.rows[0].cells rev_hdr = rev_tbl.rows[0].cells
for i, h in enumerate(["Version", "Datum", "Aenderung", "Autor"]): for i, h in enumerate(["Version", "Date", "Change", "Author"]):
rev_hdr[i].text = "" rev_hdr[i].text = ""
r = rev_hdr[i].paragraphs[0].add_run(h) r = rev_hdr[i].paragraphs[0].add_run(h)
r.bold = True r.bold = True
set_cell_shading(rev_hdr[i], LIGHT_GREY) set_cell_shading(rev_hdr[i], LIGHT_GREY)
rev_data = [ rev_data = [
("0.1", "YYYY-MM-DD", "Initialer Entwurf", "<Autor>"), ("0.1", "YYYY-MM-DD", "Initial draft", "<Author>"),
("1.0", "YYYY-MM-DD", "Erstfreigabe", "<Autor>"), ("1.0", "YYYY-MM-DD", "First release", "<Author>"),
] ]
for i, row in enumerate(rev_data, start=1): for i, row in enumerate(rev_data, start=1):
for j, v in enumerate(row): for j, v in enumerate(row):
rev_tbl.rows[i].cells[j].text = v rev_tbl.rows[i].cells[j].text = v
doc.add_heading("Verteilerkreis", level=2) doc.add_heading("Distribution List", level=2)
dist_tbl = doc.add_table(rows=3, cols=3) dist_tbl = doc.add_table(rows=3, cols=3)
dist_tbl.style = "Light Grid Accent 1" dist_tbl.style = "Light Grid Accent 1"
dist_hdr = dist_tbl.rows[0].cells dist_hdr = dist_tbl.rows[0].cells
for i, h in enumerate(["Empfaenger", "Rolle", "Organisation"]): for i, h in enumerate(["Recipient", "Role", "Organisation"]):
dist_hdr[i].text = "" dist_hdr[i].text = ""
r = dist_hdr[i].paragraphs[0].add_run(h) r = dist_hdr[i].paragraphs[0].add_run(h)
r.bold = True r.bold = True
@@ -409,40 +409,40 @@ def add_document_control(doc):
def add_toc_pages(doc): def add_toc_pages(doc):
doc.add_heading("Inhaltsverzeichnis", level=1) doc.add_heading("Table of Contents", level=1)
p = doc.add_paragraph() p = doc.add_paragraph()
add_field( add_field(
p, p,
'TOC \\o "1-3" \\h \\z \\u', 'TOC \\o "1-3" \\h \\z \\u',
"Inhaltsverzeichnis aktualisieren: F9 (rechte Maustaste auf TOC > Felder aktualisieren)", "Update TOC: F9 (right-click on TOC > Update Field)",
) )
doc.add_page_break() doc.add_page_break()
doc.add_heading("Abbildungsverzeichnis", level=1) doc.add_heading("List of Figures", level=1)
p = doc.add_paragraph() p = doc.add_paragraph()
add_field( add_field(
p, p,
'TOC \\h \\z \\c "Abbildung"', 'TOC \\h \\z \\c "Figure"',
"Abbildungsverzeichnis aktualisieren: F9", "Update list of figures: F9",
) )
doc.add_page_break() doc.add_page_break()
doc.add_heading("Tabellenverzeichnis", level=1) doc.add_heading("List of Tables", level=1)
p = doc.add_paragraph() p = doc.add_paragraph()
add_field( add_field(
p, p,
'TOC \\h \\z \\c "Tabelle"', 'TOC \\h \\z \\c "Table"',
"Tabellenverzeichnis aktualisieren: F9", "Update list of tables: F9",
) )
doc.add_page_break() doc.add_page_break()
def add_abbreviations(doc): def add_abbreviations(doc):
doc.add_heading("Abkuerzungsverzeichnis", level=1) doc.add_heading("Abbreviations", level=1)
tbl = doc.add_table(rows=4, cols=2) tbl = doc.add_table(rows=4, cols=2)
tbl.style = "Light Grid Accent 1" tbl.style = "Light Grid Accent 1"
hdr = tbl.rows[0].cells hdr = tbl.rows[0].cells
for i, h in enumerate(["Abkuerzung", "Bedeutung"]): for i, h in enumerate(["Abbreviation", "Meaning"]):
hdr[i].text = "" hdr[i].text = ""
r = hdr[i].paragraphs[0].add_run(h) r = hdr[i].paragraphs[0].add_run(h)
r.bold = True r.bold = True
@@ -460,23 +460,23 @@ def add_abbreviations(doc):
def add_main_content(doc): def add_main_content(doc):
# Section 1 # Section 1
doc.add_heading("1. Einleitung", level=1) doc.add_heading("1. Introduction", level=1)
doc.add_heading("1.1 Zweck", level=2) doc.add_heading("1.1 Purpose", level=2)
doc.add_paragraph( doc.add_paragraph(
"<Kurzer Absatz: Wozu existiert dieses Dokument? Welche Frage beantwortet es?>" "<Short paragraph: why does this document exist? What question does it answer?>"
) )
doc.add_heading("1.2 Geltungsbereich", level=2) doc.add_heading("1.2 Scope", level=2)
doc.add_paragraph("<Welches Produkt, welches Projekt, welche Phase?>") doc.add_paragraph("<Which product, project, phase?>")
doc.add_heading("1.3 Definitionen", level=2) doc.add_heading("1.3 Definitions", level=2)
doc.add_paragraph( doc.add_paragraph(
"<Spezielle Begriffe, die im Dokument verwendet werden. Allgemeine Abkuerzungen " "<Domain-specific terms used in this document. Generic abbreviations are listed "
"siehe Abkuerzungsverzeichnis.>" "in the Abbreviations section.>"
) )
doc.add_heading("1.4 Referenzen", level=2) doc.add_heading("1.4 References", level=2)
ref_tbl = doc.add_table(rows=3, cols=3) ref_tbl = doc.add_table(rows=3, cols=3)
ref_tbl.style = "Light Grid Accent 1" ref_tbl.style = "Light Grid Accent 1"
ref_hdr = ref_tbl.rows[0].cells ref_hdr = ref_tbl.rows[0].cells
for i, h in enumerate(["ID", "Titel", "Version / Ort"]): for i, h in enumerate(["ID", "Title", "Version / Location"]):
ref_hdr[i].text = "" ref_hdr[i].text = ""
r = ref_hdr[i].paragraphs[0].add_run(h) r = ref_hdr[i].paragraphs[0].add_run(h)
r.bold = True r.bold = True
@@ -486,60 +486,60 @@ def add_main_content(doc):
ref_tbl.rows[i].cells[j].text = "" ref_tbl.rows[i].cells[j].text = ""
# Section 2 # Section 2
doc.add_heading("2. Hauptinhalt", level=1) doc.add_heading("2. Main Content", level=1)
doc.add_paragraph( doc.add_paragraph(
"<Hier beginnt der dokumenttyp-spezifische Inhalt. Die Vorlage liefert Struktur " "<This is where the document-type-specific content begins. This template "
"und Formatvorlagen; konkrete Sektionen kommen aus der jeweiligen Dokumentart " "provides structure and styles; concrete sections come from each document "
"(PID, QA-Plan, SWE-Plan, ...).>" "type (PID, QA Plan, SWE Plan, ...).>"
) )
# Demonstrate styles # Demonstrate styles
doc.add_heading("2.1 Beispiel: Formatvorlagen", level=2) doc.add_heading("2.1 Example: Styles", level=2)
doc.add_paragraph( doc.add_paragraph(
"Body-Text in der Vorlage. Schriftart Calibri 11 mit 1,15-fachem Zeilenabstand." "Body text in the template. Calibri 11 with 1.15 line spacing."
) )
code_p = doc.add_paragraph(style="Code") code_p = doc.add_paragraph(style="Code")
code_p.add_run( code_p.add_run(
"// Beispiel-Code im Code-Stil (Consolas 10)\n" "// Example code in code style (Consolas 10)\n"
"Status epb_apply(uint8_t force_percent);" "Status epb_apply(uint8_t force_percent);"
) )
set_paragraph_shading(code_p, LIGHT_GREY) set_paragraph_shading(code_p, LIGHT_GREY)
note_p = doc.add_paragraph(style="Note") note_p = doc.add_paragraph(style="Note")
note_p.add_run("HINWEIS: ").bold = True note_p.add_run("NOTE: ").bold = True
note_p.add_run("Hinweis-Stil fuer ergaenzende Informationen.") note_p.add_run("Note style for supplementary information.")
set_paragraph_border(note_p, NOTE_BORDER, size=18, side="left") set_paragraph_border(note_p, NOTE_BORDER, size=18, side="left")
set_paragraph_shading(note_p, NOTE_BG) set_paragraph_shading(note_p, NOTE_BG)
warn_p = doc.add_paragraph(style="Warning") warn_p = doc.add_paragraph(style="Warning")
warn_p.add_run("ACHTUNG: ").bold = True warn_p.add_run("WARNING: ").bold = True
warn_p.add_run("Warn-Stil fuer sicherheitsrelevante Hinweise.") warn_p.add_run("Warning style for safety-relevant information.")
set_paragraph_border(warn_p, WARN_BORDER, size=18, side="left") set_paragraph_border(warn_p, WARN_BORDER, size=18, side="left")
set_paragraph_shading(warn_p, WARN_BG) set_paragraph_shading(warn_p, WARN_BG)
req_p = doc.add_paragraph(style="Requirement") req_p = doc.add_paragraph(style="Requirement")
req_p.add_run("REQ-001: ").bold = True req_p.add_run("REQ-001: ").bold = True
req_p.add_run( req_p.add_run(
"Requirement-Stil fuer in-line Anforderungen " "Requirement style for inline requirements "
"(meist in Markdown via Doorstop, in Word fuer formelle Berichte)." "(usually in Markdown via Doorstop, but in Word for formal reports)."
) )
set_paragraph_border(req_p, REQ_BORDER, size=18, side="left") set_paragraph_border(req_p, REQ_BORDER, size=18, side="left")
set_paragraph_shading(req_p, REQ_BG) set_paragraph_shading(req_p, REQ_BG)
doc.add_heading("2.2 Beispiel-Tabelle", level=2) doc.add_heading("2.2 Example Table", level=2)
tbl = doc.add_table(rows=4, cols=3) tbl = doc.add_table(rows=4, cols=3)
tbl.style = "Light Grid Accent 1" tbl.style = "Light Grid Accent 1"
hdr = tbl.rows[0].cells hdr = tbl.rows[0].cells
for i, h in enumerate(["ID", "Beschreibung", "ASIL"]): for i, h in enumerate(["ID", "Description", "ASIL"]):
hdr[i].text = "" hdr[i].text = ""
r = hdr[i].paragraphs[0].add_run(h) r = hdr[i].paragraphs[0].add_run(h)
r.bold = True r.bold = True
set_cell_shading(hdr[i], LIGHT_GREY) set_cell_shading(hdr[i], LIGHT_GREY)
rows = [ rows = [
("F-01", "Apply bei Fahrer-Anforderung", "D"), ("F-01", "Apply on driver request", "D"),
("F-05", "Release bei Fahrer-Anforderung", "B"), ("F-05", "Release on driver request", "B"),
("F-10", "HMI: LED-Steuerung", "QM"), ("F-10", "HMI: LED control", "QM"),
] ]
for i, row in enumerate(rows, start=1): for i, row in enumerate(rows, start=1):
for j, v in enumerate(row): for j, v in enumerate(row):
@@ -547,12 +547,12 @@ def add_main_content(doc):
# Caption demo # Caption demo
cap_p = doc.add_paragraph(style="Caption") cap_p = doc.add_paragraph(style="Caption")
cap_p.add_run("Tabelle 1: Beispiel-Anforderungen mit ASIL-Klassifikation") cap_p.add_run("Table 1: Example requirements with ASIL classification")
# Section 3 — Anhang # Section 3 — Appendix
doc.add_heading("3. Anhang", level=1) doc.add_heading("3. Appendix", level=1)
doc.add_paragraph( doc.add_paragraph(
"<Anhaenge: Detail-Berechnungen, Skripte, Zusatz-Tabellen, Glossar.>" "<Appendices: detail calculations, scripts, extra tables, glossary.>"
) )
vorlagen-word/MISRA-Deviation-Permit-vorlage.docx
BIN
View File
Binary file not shown.
vorlagen-word/MISRA-Deviation-Record-vorlage.docx
BIN
View File
Binary file not shown.
vorlagen-word/Non-Conformity-vorlage.docx
BIN
View File
Binary file not shown.
vorlagen-word/PID-vorlage.docx
BIN
View File
Binary file not shown.
vorlagen-word/PM-Plan-vorlage.docx
BIN
View File
Binary file not shown.
vorlagen-word/QA-Plan-vorlage.docx
BIN
View File
Binary file not shown.
vorlagen-word/Review-Protokoll-vorlage.docx
BIN
View File
Binary file not shown.
vorlagen-word/SWE-Plan-vorlage.docx
BIN
View File
Binary file not shown.
vorlagen-word/Test-Plan-vorlage.docx
BIN
View File
Binary file not shown.
vorlagen-word/angebot-vorlage.docx
BIN
View File
Binary file not shown.
vorlagen-word/slohmaier-doc-template.docx
BIN
View File
Binary file not shown.
vorlagen/MISRA-Deviation-Permit-vorlage.md
+42 -42
View File
@@ -1,76 +1,76 @@
# MISRA Deviation Permit # MISRA Deviation Permit
| Feld | Wert | | Field | Value |
|-----------------|-------------------------------| |------------------|--------------------------------|
| Permit-ID | PER-[XXX] | | Permit ID | PER-[XXX] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Erstellt von | [Name] | | Author | [Name] |
--- ---
## 1. Regelbereich ## 1. Rule
| Feld | Wert | | Field | Value |
|-------------------|----------------------------------------------------| |-------------------|----------------------------------------------------|
| Regel-Nummer | [z.B. Rule 11.3] | | Rule number | [e.g. Rule 11.3] |
| Kategorie | [Required / Advisory] | | Category | [Required / Advisory] |
| Regeltext | [Exakter Text der MISRA-Regel] | | Rule text | [Exact text of the MISRA rule] |
| Standard | [MISRA C:2012 / MISRA C:2023] | | Standard | [MISRA C:2012 / MISRA C:2023] |
## 2. Scope ## 2. Scope
Dieses Permit gilt fuer: This permit applies to:
| Aspekt | Geltungsbereich | | Aspect | Scope |
|-------------------|----------------------------------------------------| |-------------------|----------------------------------------------------|
| Code-Bereich | [z.B. src/hal/*.c — alle Hardware-Abstraction-Layer Dateien] | | Code area | [e.g. src/hal/*.c — all hardware-abstraction-layer files] |
| Modul / Komponente| [z.B. HAL, CAN-Treiber] | | Module / component| [e.g. HAL, CAN driver] |
| Kontext | [z.B. Register-Zugriffe auf Memory-Mapped I/O] | | Context | [e.g. register access to 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. **Limitation:** This permit applies exclusively to the scope defined above. Deviations outside this scope require a separate deviation record or a separate permit.
## 3. Begruendung ## 3. Rationale
[Warum ist die Abweichung von dieser Regel im definierten Kontext vertretbar?] [Why is deviation from this rule acceptable in the defined context?]
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." Example: "Rule 11.3 forbids casts between pointer types. In the HAL, casts from `uint32_t*` to register structs are necessary because the hardware is accessed via memory-mapped I/O. The register addresses and layouts are defined in the datasheet and are static. A rule-compliant alternative does not exist."
**Begruendung:** [Hier ausfuellen] **Rationale:** [Fill in here]
## 4. Risikobewertung und Alternativen ## 4. Risk assessment and alternatives
### Risikobewertung ### Risk assessment
| Aspekt | Bewertung | | Aspect | Assessment |
|---------------------------|-----------------------------------------------| |---------------------------|-----------------------------------------------|
| Sicherheitsrelevanz | [Keine / Gering / Mittel / Hoch] | | Safety relevance | [None / Low / Medium / High] |
| Fehlerpotenzial | [Beschreibung] | | Fault potential | [Description] |
| Absicherung | [z.B. Unit Tests pruefen korrekte Register-Zugriffe, Code Review Pflicht fuer HAL-Code] | | Mitigation | [e.g. unit tests verify correct register access, code review required for HAL code] |
| Restrisiko | [Bewertung] | | Residual risk | [Assessment] |
### Geprufte Alternativen ### Alternatives considered
| Alternative | Bewertung | | Alternative | Assessment |
|--------------------------|------------------------------------------------| |--------------------------|------------------------------------------------|
| [z.B. Generische Zugriffsfunktionen] | [z.B. Nicht praktikabel, da hunderte Register] | | [e.g. generic accessor functions] | [e.g. not practical due to hundreds of registers] |
| [z.B. Compiler-Erweiterung] | [z.B. Nicht portabel] | | [e.g. compiler extension] | [e.g. not portable] |
## 5. Freigabe ## 5. Approval
| Feld | Wert | | Field | Value |
|-----------------------|-----------------------------------------------| |-----------------------|-----------------------------------------------|
| Freigegeben von | [Name, Rolle] | | Approved by | [Name, role] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Nachweis | [GitLab-Issue / Wiki-Verweis / Unterschrift] | | Evidence | [Gitea issue / wiki link / signature] |
## 6. Gueltigkeit ## 6. Validity
| Feld | Wert | | Field | Value |
|-------------------|----------------------------------------------------| |-------------------|----------------------------------------------------|
| Gueltig ab | [YYYY-MM-DD] | | Valid from | [YYYY-MM-DD] |
| Gueltig bis | [YYYY-MM-DD oder "bis auf Widerruf"] | | Valid until | [YYYY-MM-DD or "until revoked"] |
| Widerrufsbedingung | [z.B. Bei Aenderung der Zielplattform neu bewerten] | | Revocation trigger | [e.g. re-evaluate if the target platform changes] |
--- ---
*Dieses Permit wird im GitLab-Wiki unter MISRA-Deviation-Permits abgelegt und aus Deviation Records referenziert.* *This permit is stored in the Gitea wiki under MISRA-Deviation-Permits and referenced from deviation records.*
vorlagen/MISRA-Deviation-Record-vorlage.md
+42 -42
View File
@@ -1,70 +1,70 @@
# MISRA Deviation Record # MISRA Deviation Record
| Feld | Wert | | Field | Value |
|-----------------|-------------------------------| |------------------|--------------------------------|
| Deviation-ID | DEV-[XXX] | | Deviation ID | DEV-[XXX] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Erstellt von | [Name] | | Author | [Name] |
--- ---
## 1. Regel ## 1. Rule
| Feld | Wert | | Field | Value |
|-------------------|----------------------------------------------------| |-------------------|----------------------------------------------------|
| Regel-Nummer | [z.B. Rule 11.3] | | Rule number | [e.g. Rule 11.3] |
| Kategorie | [Required / Advisory / Mandatory] | | Category | [Required / Advisory / Mandatory] |
| Regeltext | [Exakter Text der MISRA-Regel] | | Rule text | [Exact text of the MISRA rule] |
| Standard | [MISRA C:2012 / MISRA C:2023] | | Standard | [MISRA C:2012 / MISRA C:2023] |
## 2. Fundstelle ## 2. Location
| Feld | Wert | | Field | Value |
|-------------------|----------------------------------------------------| |-------------------|----------------------------------------------------|
| Datei | [z.B. src/drivers/watchdog.c] | | File | [e.g. src/drivers/watchdog.c] |
| Zeile(n) | [z.B. 142-145] | | Line(s) | [e.g. 142-145] |
| Funktion | [z.B. wdg_set_timeout()] | | Function | [e.g. wdg_set_timeout()] |
| Git-Commit | [Commit-Hash] | | Git commit | [commit hash] |
| GitLab-Referenz | [MR-Link oder Issue-Link] | | Gitea reference | [PR link or issue link] |
## 3. Begruendung ## 3. Rationale
[Warum ist die Abweichung in diesem konkreten Fall technisch vertretbar?] [Why is the deviation technically acceptable in this specific case?]
Moegliche Begruendungen: Possible rationales:
- Hardware-Zugriff erfordert Typkonvertierung - Hardware access requires type conversion
- Compiler-spezifisches Verhalten ist definiert und getestet - Compiler-specific behaviour is defined and tested
- Alternative Implementierung waere unverhältnismaessig komplex - Alternative implementation would be disproportionately complex
- Regel ist im Kontext nicht sicherheitsrelevant - Rule is not safety-relevant in this context
**Konkrete Begruendung:** [Hier ausfuellen] **Specific rationale:** [Fill in here]
## 4. Risikobewertung ## 4. Risk assessment
| Aspekt | Bewertung | | Aspect | Assessment |
|---------------------------|-----------------------------------------------| |---------------------------|-----------------------------------------------|
| Sicherheitsrelevanz | [Keine / Gering / Mittel / Hoch] | | Safety relevance | [None / Low / Medium / High] |
| Fehlerpotenzial | [Beschreibung moeglicher Fehler] | | Fault potential | [Description of potential faults] |
| Absicherung | [Welche Tests / Massnahmen sichern den Code ab] | | Mitigation | [Which tests / measures cover the code] |
| Restrisiko | [Bewertung des verbleibenden Risikos] | | Residual risk | [Assessment of the residual risk] |
## 5. Verweis auf Deviation Permit ## 5. Reference to deviation permit
| Feld | Wert | | Field | Value |
|-----------------------|-----------------------------------------------| |-----------------------|-----------------------------------------------|
| Permit vorhanden | [Ja / Nein] | | Permit exists | [Yes / No] |
| Permit-ID | [PER-XXX oder "entfaellt"] | | Permit ID | [PER-XXX or "n/a"] |
Falls kein Permit vorhanden: diese Abweichung ist eine Einzelfallgenehmigung. If no permit exists: this deviation is a single-case approval.
## 6. Freigabe ## 6. Approval
| Feld | Wert | | Field | Value |
|-------------------|----------------------------------------------------| |-------------------|----------------------------------------------------|
| Freigegeben von | [Name, Rolle] | | Approved by | [Name, role] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Nachweis | [GitLab-MR-Approval / Unterschrift] | | Evidence | [Gitea PR approval / signature] |
--- ---
*Dieser Record wird im Repository unter `docs/misra/` oder als GitLab Issue gefuehrt.* *This record is kept in the repository under `docs/misra/` or as a Gitea issue.*
vorlagen/Non-Conformity-vorlage.md
+50 -50
View File
@@ -1,79 +1,79 @@
# Non-Conformity Report # Non-Conformity Report
| Feld | Wert | | Field | Value |
|-----------------|-------------------------------| |------------------|--------------------------------|
| NC-ID | NC-[XXX] | | NC ID | NC-[XXX] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Erstellt von | [Name] | | Author | [Name] |
| Status | [Offen / In Bearbeitung / Geschlossen] | | Status | [Open / In progress / Closed] |
--- ---
## 1. Bezug ## 1. Reference
| Feld | Wert | | Field | Value |
|-----------------------|-----------------------------------------------| |-----------------------|-----------------------------------------------|
| Art | [Prozessabweichung / Produktabweichung] | | Kind | [Process deviation / Product deviation] |
| Betroffener Prozess | [z.B. SWE.4 Implementierung, SUP.1 QA] | | Affected process | [e.g. SWE.4 Implementation, SUP.1 QA] |
| Betroffenes Work Product | [z.B. Modul XY, Anforderung SWR-042, Testplan] | | Affected work product | [e.g. module XY, requirement SWR-042, test plan] |
| GitLab-Referenz | [Issue-Link / MR-Link / Wiki-Seite] | | Gitea reference | [Issue link / PR link / wiki page] |
| Gefunden bei | [Review / Audit / Test / CI-Pipeline] | | Discovered in | [Review / audit / test / CI pipeline] |
## 2. Beschreibung der Abweichung ## 2. Description of deviation
[Was genau weicht ab? Konkret beschreiben. Bezug auf Norm oder Prozessvorgabe angeben.] [What exactly deviates? Describe concretely. Reference the standard or process specification.]
## 3. Schweregrad ## 3. Severity
| Schweregrad | Definition | | Severity | Definition |
|-------------|------------------------------------------------------------------| |--------------|------------------------------------------------------------------|
| [ ] Critical | Sicherheitsrelevant oder vollstaendiges Fehlen eines geforderten Work Products | | [ ] Critical | Safety-relevant or complete absence of a required work product |
| [ ] Major | Signifikante Abweichung, die die Qualitaet oder Konformitaet beeintraechtigt | | [ ] Major | Significant deviation that affects quality or compliance |
| [ ] Minor | Geringfuegige Abweichung, keine direkte Auswirkung auf Sicherheit oder Funktion | | [ ] Minor | Minor deviation, no direct effect on safety or function |
**Zugewiesener Schweregrad:** [Critical / Major / Minor] **Assigned severity:** [Critical / Major / Minor]
## 4. Ursachenanalyse ## 4. Root-cause analysis
[Warum ist die Abweichung aufgetreten? Moegliche Kategorien:] [Why did the deviation occur? Possible categories:]
- Prozess nicht bekannt / nicht geschult - Process not known / not trained
- Prozess nicht anwendbar / unrealistisch - Process not applicable / unrealistic
- Versehen / menschlicher Fehler - Oversight / human error
- Tool-Fehler - Tool error
- Zeitdruck / Ressourcenmangel - Time pressure / lack of resources
- Anforderung unklar - Requirement unclear
**Beschreibung:** [Konkrete Ursache] **Description:** [Specific cause]
## 5. Korrekturmassnahme ## 5. Corrective action
| Feld | Wert | | Field | Value |
|-----------------------|-----------------------------------------------| |-----------------------|-----------------------------------------------|
| Massnahme | [Was wird getan um die Abweichung zu beheben] | | Action | [What is done to fix the deviation] |
| Verantwortlich | [Name] | | Responsible | [Name] |
| Faelligkeit | [YYYY-MM-DD] | | Due | [YYYY-MM-DD] |
### Vorbeugende Massnahme (optional) ### Preventive action (optional)
[Was wird getan damit diese Art von Abweichung nicht erneut auftritt?] [What is done so that this type of deviation does not occur again?]
## 6. Wirksamkeitspruefung ## 6. Effectiveness check
| Feld | Wert | | Field | Value |
|-----------------------|-----------------------------------------------| |-----------------------|-----------------------------------------------|
| Geprueft von | [Name] | | Verified by | [Name] |
| Pruefungsdatum | [YYYY-MM-DD] | | Verification date | [YYYY-MM-DD] |
| Massnahme wirksam | [Ja / Nein] | | Action effective | [Yes / No] |
| Nachweis | [GitLab-Issue-Link / Commit / Review] | | Evidence | [Gitea issue link / commit / review] |
## 7. Abschluss ## 7. Closure
| Feld | Wert | | Field | Value |
|-----------------------|-----------------------------------------------| |-----------------------|-----------------------------------------------|
| Status | [Geschlossen / Erneut geoeffnet] | | Status | [Closed / Reopened] |
| Geschlossen von | [Name] | | Closed by | [Name] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
--- ---
*Dieser Report wird als GitLab Issue (Label: `non-conformity`) gefuehrt.* *This report is kept as a Gitea issue (label: `non-conformity`).*
vorlagen/PM-Plan-vorlage.md
+51 -61
View File
@@ -1,85 +1,75 @@
# Projektplan (PM-Plan) # Project Management Plan (PM Plan)
| Feld | Wert | | Field | Value |
|-----------------|-------------------------------| |-----------------|--------------------------------|
| Projekt | [Projektname] | | Project | [Project name] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Version | [1.0] | | Version | [1.0] |
| Status | [Entwurf / Freigegeben] | | Status | [Draft / Released] |
| Bezug | PID Version [X.Y] |
--- ---
## 1. Projektphasen und Meilensteine ## 1. Project organisation
| Phase | Start | Ende | Meilenstein | [Describe organisation, roles, escalation path. Distinct from the role section in the PID — here you go into more detail on day-to-day collaboration.]
|------------------------|-------------|-------------|--------------------------------------|
| 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. Work packages
## 2. Ressourcen und Rollen | WP-ID | Work package | Owner | Effort (PD) | Due | Status |
|-------|------------------------|----------------|-------------|-----------|--------|
| WP-01 | [name] | [Name] | [n] | [Date] | [open] |
| WP-02 | [name] | [Name] | [n] | [Date] | [open] |
| Rolle | Person | Verfuegbarkeit | Aufgaben | ## 3. Schedule
|--------------------------|---------------------|-------------------|---------------------------------|
| 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 | Phase | Start | End | Result |
|--------------------------|-------------|-------------|-------------------------------|
| Concept | [Date] | [Date] | PID released |
| Requirements | [Date] | [Date] | SRS released |
| Architecture | [Date] | [Date] | Architecture document |
| Implementation | [Date] | [Date] | Code complete |
| Verification | [Date] | [Date] | Test report |
| Release | [Date] | [Date] | Release package |
| Aktivitaet | Haeufigkeit | Teilnehmer | Medium | ## 4. Change management
|--------------------------|--------------|---------------------------|---------------------|
| 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 - Changes go through change requests (CR)
- CR ID: `CR-XXX`, tracked in Gitea Issues
- For ASIL-relevant changes: re-run impacted reviews (architecture, code, tests)
- Re-baselining via git tag (see CM Plan)
| Stufe | Situation | Eskalation an | Frist | ## 5. Communication
|-------|----------------------------------------------|----------------------------|-------------|
| 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 | Channel | Use | Frequency |
|-----------------|--------------------------------------|-------------|
| Gitea Issues | Tickets, bugs, change requests | as needed |
| Gitea PRs | Reviews, approval, audit trail | per change |
| Status report | Project status update | weekly |
| Standup | Quick alignment | daily |
| Review meeting | Architecture / design / code reviews | per CR |
Aenderungen an Anforderungen, Scope oder Zeitplan werden als Change Request behandelt: ## 6. Risk management
1. Change Request als GitLab Issue erfassen (Label: `change-request`) See `RM Plan` (separate document). Top-level summary here:
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. | ID | Risk | Status |
|------|----------------------------------|-------------|
| R-01 | [Top risk] | [Mitigated] |
| R-02 | [Top risk] | [Open] |
## 6. Risikomanagement ## 7. Reporting
### Vorgehen - **Weekly status:** email to client with progress + open items
- **Audit report:** at project closure, PDF from Doorstop + Word plans
- **CI artefacts:** updated on every push (coverage, MISRA, traceability)
- Initiale Risiken im PID erfasst ## 8. Closure
- 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 The project is considered closed when:
- All success criteria from the PID are met
| Wahrscheinlichkeit / Auswirkung | Niedrig | Mittel | Hoch | - A `v1.0.0` git tag is set
|----------------------------------|---------|---------|---------| - The release package has been delivered to the client and accepted
| 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.* *Changes to this plan are versioned in the Gitea wiki.*
vorlagen/QA-Plan-vorlage.md
+47 -85
View File
@@ -1,106 +1,68 @@
# Quality Assurance Plan (QA-Plan) # Quality Assurance Plan (QA Plan)
| Feld | Wert | | Field | Value |
|-----------------|-------------------------------| |-----------------|--------------------------------|
| Projekt | [Projektname] | | Project | [Project name] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Version | [1.0] | | Version | [1.0] |
| Status | [Entwurf / Freigegeben] | | Status | [Draft / Released] |
| ASIL | [QM / A / B / C / D] |
--- ---
## 1. QA-Aktivitaeten pro Phase ## 1. Quality goals
| Phase | QA-Aktivitaet | Verantwortlich | - [Goal 1, e.g. "100% MISRA Required compliance"]
|------------------------|--------------------------------------------------------|----------------| - [Goal 2, e.g. "Statement coverage ≥ 90% for ASIL-D"]
| Anforderungsanalyse | Review der Anforderungen (Vollstaendigkeit, Konsistenz, Testbarkeit) | QA / Reviewer | - [Goal 3, e.g. "Zero critical static-analysis findings on release"]
| 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 ## 2. Quality measures
| Work Product | Review-Art | Pruefkriterien | | Measure | Tool / Method | Frequency | Owner |
|----------------------------------|------------------|---------------------------------------------| |--------------------------|------------------------------|------------------|----------|
| PID | Peer Review | Vollstaendig, konsistent mit Vertrag | | Traceability check | `doorstop check` | every push | dev |
| PM-Plan | Peer Review | Realistisch, Risiken adressiert | | MISRA check | Cppcheck + MISRA addon | every push | dev |
| Software Requirements | Technical Review | Eindeutig, testbar, ASIL zugeordnet | | Static analysis | Cppcheck, clang-tidy | every push | dev |
| Architektur-Dokumentation | Technical Review | Modular, Schnittstellen definiert, Safety-Konzept | | Unit tests | CppUTest | every push | dev |
| Quellcode | Peer Review (MR) | MISRA-konform, getestet, lesbar | | Coverage | gcov / lcov | every push | dev |
| Unit Tests | Peer Review | Abdeckung, Randfaelle, Traceability | | Peer review | Gitea PRs | every change | reviewer |
| Testberichte | Peer Review | Pass/Fail dokumentiert, Coverage erreicht | | Architecture review | Technical review | on changes | TL |
| MISRA Compliance Report | Peer Review | Abweichungen dokumentiert und genehmigt |
| Traceability-Matrix | QA-Pruefung | Keine Luecken, bidirektional |
## 3. Review-Arten ## 3. Review obligations
| Review-Art | Teilnehmer | Formalitaet | Wann | | Artefact | Review type | Min. approvers |
|---------------------|-------------------------------|-------------|----------------------------------| |--------------------------------|---------------------|-----------------|
| Peer Review | 1 Reviewer | Niedrig | Jeder MR, Dokument-Aenderungen | | Requirements | Technical review | 1 |
| Technical Review | 2+ Reviewer, inkl. Tech Lead | Mittel | Architektur, Safety-Code, Plaene | | Architecture element | Technical review | 2 |
| Inspektion | Moderator + 2+ Reviewer | Hoch | Safety-kritische Artefakte (ASIL C/D) | | Code (QM / ASIL-A/B) | Peer review | 1 |
| Code (ASIL-C/D) | Technical review | 2 |
| Plans and reports | Peer review | 1 |
| MISRA deviation permit | Technical lead | 1 |
Peer Reviews laufen ueber GitLab MR-Approvals. Technical Reviews und Inspektionen werden zusaetzlich mit Review-Protokoll dokumentiert. ## 4. Non-conformity management
## 4. Entry/Exit-Kriterien Deviations from plans or requirements are documented as a non-conformity (NC):
### Entry-Kriterien (Beginn einer Phase) - Path: `docs/non-conformities/NC-XXX.docx`
- Severity: Critical / Major / Minor
- Corrective action and verification tracked
- Closure criterion: corrective action verified
| Phase | Entry-Kriterien | ## 5. Audit preparation
|----------------------|--------------------------------------------------------|
| 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) Audit readiness is maintained continuously:
| Phase | Exit-Kriterien | - Git history is the audit trail (no direct push to `main`)
|----------------------|--------------------------------------------------------| - Documents are versioned in the repo
| Anforderungen | Alle Requirements reviewed, ASIL zugeordnet, testbar | - Traceability matrices are generated on every CI run
| Architektur | Architektur reviewed, Schnittstellen definiert | - MISRA records and deviation permits are stored under `misra/`
| Implementierung | MISRA-konform, Unit Tests gruen, Coverage-Ziel erreicht | - Test and coverage reports are stored as CI artefacts
| 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 ## 6. Improvement measures
1. Abweichung wird erkannt (Review, Audit, Test) - Lessons-learned note at each sprint closure under `docs/lessons-learned/`
2. Non-Conformity Report erstellen (GitLab Issue, Label: `non-conformity`) - Quarterly retrospective with the team
3. Schweregrad zuweisen: Critical / Major / Minor - Updates to this plan are versioned and reviewed
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.* *Changes to this plan are versioned in the Gitea wiki.*
vorlagen/Review-Protokoll-vorlage.md
+45 -45
View File
@@ -1,74 +1,74 @@
# Review-Protokoll # Review Minutes
| Feld | Wert | | Field | Value |
|-------------------------|-----------------------------------------| |-------------------------|------------------------------------------|
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Review-Art | [Peer Review / Technical Review / Inspektion] | | Review type | [Peer review / Technical review / Inspection] |
| Moderator | [Name] | | Moderator | [Name] |
| Protokollfuehrer | [Name] | | Minute keeper | [Name] |
--- ---
## 1. Teilnehmer ## 1. Participants
| Name | Rolle | Anwesend | | Name | Role | Present |
|---------------------|--------------------------|----------| |---------------------|--------------------------|----------|
| [Name] | Moderator | Ja / Nein | | [Name] | Moderator | Yes / No |
| [Name] | Autor | Ja / Nein | | [Name] | Author | Yes / No |
| [Name] | Reviewer | Ja / Nein | | [Name] | Reviewer | Yes / No |
| [Name] | Reviewer | Ja / Nein | | [Name] | Reviewer | Yes / No |
## 2. Reviewtes Work Product ## 2. Reviewed work product
| Feld | Wert | | Field | Value |
|-------------------|-------------------------------------------| |-------------------|--------------------------------------------|
| Work Product | [z.B. Architektur-Dokumentation, Modul XY, Anforderungen SWR-040 bis SWR-060] | | Work product | [e.g. architecture documentation, module XY, requirements SWR-040 to SWR-060] |
| Version / Commit | [Version oder Git-Commit-Hash] | | Version / commit | [Version or git commit hash] |
| GitLab-Referenz | [MR-Link / Wiki-Seite / Issue-Nummern] | | Gitea reference | [PR link / wiki page / issue numbers] |
## 3. Review-Vorbereitung ## 3. Review preparation
| Reviewer | Vorbereitungszeit (h) | Vorbereitung abgeschlossen | | Reviewer | Preparation time (h) | Preparation complete |
|-------------------|-----------------------|----------------------------| |-------------------|-----------------------|----------------------------|
| [Name] | [X] | Ja / Nein | | [Name] | [X] | Yes / No |
| [Name] | [X] | Ja / Nein | | [Name] | [X] | Yes / No |
## 4. Findings ## 4. Findings
| ID | Beschreibung | Schwere | Verantwortlich | Fälligkeit | Status | | ID | Description | Severity | Responsible | Due | Status |
|------|---------------------------------|-------------------|----------------|-------------|-------------| |------|---------------------------------|-------------------|----------------|-------------|-------------|
| F-01 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen | | F-01 | [Finding description] | Critical / Major / Minor | [Name] | [Date] | Open |
| F-02 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen | | F-02 | [Finding description] | Critical / Major / Minor | [Name] | [Date] | Open |
| F-03 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen | | F-03 | [Finding description] | Critical / Major / Minor | [Name] | [Date] | Open |
### Schweregrade ### Severities
- **Critical:** Sicherheitsrelevant oder funktional falsch. Muss vor Freigabe behoben werden. - **Critical:** Safety-relevant or functionally wrong. Must be fixed before release.
- **Major:** Signifikanter Fehler oder Luecke. Muss behoben werden, kann aber terminiert werden. - **Major:** Significant defect or gap. Must be fixed but may be scheduled.
- **Minor:** Verbesserungsvorschlag, Stil, Lesbarkeit. Behebung empfohlen. - **Minor:** Improvement suggestion, style, readability. Fix recommended.
## 5. Entscheidung ## 5. Decision
| Entscheidung | | Decision |
|-----------------------------------------------------------| |-----------------------------------------------------------|
| [ ] Freigegeben | | [ ] Approved |
| [ ] Bedingt freigegeben (nach Behebung der Critical/Major Findings) | | [ ] Conditionally approved (after fixing Critical/Major findings) |
| [ ] Nicht freigegeben (erneutes Review erforderlich) | | [ ] Not approved (re-review required) |
**Bedingungen fuer bedingte Freigabe:** **Conditions for conditional approval:**
[Falls zutreffend: welche Findings muessen behoben werden, wer prueft die Behebung] [If applicable: which findings must be fixed, who verifies the fix]
## 6. Unterschriften / Nachweis ## 6. Signatures / evidence
| Rolle | Name | Datum | Nachweis | | Role | Name | Date | Evidence |
|----------------------|---------------------|-------------|------------------------------| |----------------------|---------------------|-------------|------------------------------|
| Moderator | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] | | Moderator | [Name] | [Date] | [Signature / Gitea PR approval] |
| Reviewer 1 | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] | | Reviewer 1 | [Name] | [Date] | [Signature / Gitea PR approval] |
| Reviewer 2 | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] | | Reviewer 2 | [Name] | [Date] | [Signature / Gitea PR approval] |
| Autor | [Name] | [Datum] | | | Author | [Name] | [Date] | |
**GitLab-MR-Link:** [URL zum Merge Request, falls zutreffend] **Gitea PR link:** [URL to the pull request, if applicable]
--- ---
*Dieses Protokoll wird im GitLab-Wiki unter Review-Protokolle/ abgelegt.* *These minutes are kept in the Gitea wiki under review-minutes/.*
vorlagen/SA-vorlage.md
+53 -53
View File
@@ -5,100 +5,100 @@ links:
- SYS-XXX: [hash] - SYS-XXX: [hash]
--- ---
# SA-XXX: [Element-Name] # SA-XXX: [Element name]
> **System Architectural Design Element (ASPICE SYS.3).** > **System Architectural Design Element (ASPICE SYS.3).**
> Beschreibt ein Element der System-Architektur und sein Mapping auf System-Anforderungen. > Describes a system architecture element and its mapping to system requirements.
| Feld | Wert | | Field | Value |
|----------|-------------------------------| |----------|--------------------------------|
| Projekt | [Projektname] | | Project | [Project name] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Version | [1.0] | | Version | [1.0] |
| Status | [Entwurf / Freigegeben] | | Status | [Draft / Released] |
| ASIL | [QM / A / B / C / D] | | ASIL | [QM / A / B / C / D] |
| Autor | [Name] | | Author | [Name] |
--- ---
## 1. Verantwortung ## 1. Responsibility
[Was tut dieses Element? Ein bis zwei Saetze. Welcher Zweck im Gesamtsystem.] [What does this element do? One or two sentences. Its purpose in the overall system.]
## 2. System-Kontext ## 2. System context
[PlantUML-Diagramm: dieses Element im Verhaeltnis zu Nachbarsystemen / Umgebung.] [PlantUML diagram: this element in relation to neighbouring systems / environment.]
```plantuml ```plantuml
@startuml @startuml
!define COMPONENT(x) component "x" as x !define COMPONENT(x) component "x" as x
COMPONENT([Element]) COMPONENT([Element])
[Element] --> [Nachbarsystem A] : Schnittstelle X [Element] --> [Neighbour A] : interface X
[Nachbarsystem B] --> [Element] : Schnittstelle Y [Neighbour B] --> [Element] : interface Y
@enduml @enduml
``` ```
## 3. Allokation ## 3. Allocation
| Anforderung | Allokation auf | Bemerkung | | Requirement | Allocated to | Notes |
|---------------|----------------|---------------------------| |---------------|------------------|------------------------------|
| SYS-XXX | dieses Element | [vollstaendig / teilweise] | | SYS-XXX | this element | [full / partial] |
| SYS-YYY | dieses Element | [Begruendung] | | SYS-YYY | this element | [Rationale] |
Allokations-Regel: jede verlinkte System-Anforderung muss eindeutig auf HW, SW oder Mechanik abgebildet werden. Allocation rule: every linked system requirement must be unambiguously mapped to HW, SW, or mechanics.
## 4. Schnittstellen zur Umgebung ## 4. External interfaces
| Schnittstelle | Richtung | Typ | Bemerkung | | Interface | Direction | Type | Notes |
|---------------|---------------|----------------------|--------------------------| |---------------|---------------|-----------------------|-------------------------|
| [Name] | in / out / io | [CAN / SPI / GPIO / ...] | [Protokoll-Verweis] | | [Name] | in / out / io | [CAN / SPI / GPIO / ...] | [Protocol reference] |
## 5. Subkomponenten / Aufteilung ## 5. Subcomponents / breakdown
[Falls dieses System-Element aus mehreren Subkomponenten besteht: kurze Auflistung mit Verweis auf weitere SA- oder SWA-Elemente.] [If this system element consists of subcomponents: short list with references to other SA or SWA elements.]
| Subkomponente | Realisierung | Verweis | | Subcomponent | Realisation | Reference |
|---------------|--------------------|-------------------| |---------------|--------------------|-------------------|
| [Name] | [HW / SW / Mechanik] | SWA-XXX / SA-YYY | | [Name] | [HW / SW / mechanics] | SWA-XXX / SA-YYY |
## 6. Dynamisches Verhalten ## 6. Dynamic behaviour
[PlantUML-Sequenz oder State-Diagramm fuer kritische Ablaeufe.] [PlantUML sequence or state diagram for critical flows.]
```plantuml ```plantuml
@startuml @startuml
actor Nutzer actor User
Nutzer -> [Element]: Anforderung User -> [Element]: request
[Element] -> [Nachbar]: weiterleiten [Element] -> [Neighbour]: forward
[Nachbar] --> [Element]: Antwort [Neighbour] --> [Element]: response
[Element] --> Nutzer: Ergebnis [Element] --> User: result
@enduml @enduml
``` ```
## 7. Nichtfunktionale Eigenschaften ## 7. Non-functional properties
| Aspekt | Anforderung / Zielwert | | Aspect | Requirement / target value |
|---------------------|-----------------------------| |---------------------|------------------------------|
| Worst-Case Timing | [z.B. < 10 ms Reaktionszeit]| | Worst-case timing | [e.g. < 10 ms reaction time] |
| Speicherbedarf | [z.B. < 64 KB Flash] | | Memory footprint | [e.g. < 64 KB flash] |
| Stromaufnahme | [z.B. < 200 mA bei 12 V] | | Power draw | [e.g. < 200 mA at 12 V] |
| Umgebungsbedingungen | [Temperatur, EMV] | | Environment | [Temperature, EMC] |
| Sicherheitsziel | [Verweis auf SG-XXX, falls vorhanden] | | Safety goal | [Reference to SG-XXX, if any] |
## 8. Designentscheidungen ## 8. Design decisions
| Entscheidung | Alternativen | Begruendung | | Decision | Alternatives | Rationale |
|--------------|--------------|-------------| |--------------|--------------|-----------|
| [Was] | [Was sonst noch erwogen wurde] | [Warum diese Wahl] | | [What] | [What else was considered] | [Why this choice] |
## 9. Verifikation ## 9. Verification
| Anforderung | Verifikations-Methode | Test-ID | | Requirement | Verification method | Test ID |
|-------------|------------------------|-------------------| |-------------|---------------------------|-------------------|
| SYS-XXX | [Review / Test / Analyse] | TST-SYS-XXX | | SYS-XXX | [Review / test / analysis] | TST-SYS-XXX |
Jede in den `links` referenzierte System-Anforderung muss mindestens eine Verifikations-Methode haben. Every system requirement listed in `links` must have at least one verification method.
--- ---
*Aenderungen an diesem Architektur-Element gehen per PR mit mind. 2 Technical-Review-Approvals (siehe SWE-Plan).* *Changes to this architecture element go through a PR with at least 2 technical-review approvals (see SWE Plan).*
vorlagen/SWA-vorlage.md
+69 -70
View File
@@ -5,83 +5,83 @@ links:
- SWE-XXX: [hash] - SWE-XXX: [hash]
--- ---
# SWA-XXX: [Komponenten-Name] # SWA-XXX: [Component name]
> **Software Architectural Design Element (ASPICE SWE.2).** > **Software Architectural Design Element (ASPICE SWE.2).**
> Beschreibt eine Software-Komponente und ihr Mapping auf Software-Anforderungen. > Describes a software component and its mapping to software requirements.
| Feld | Wert | | Field | Value |
|----------|-------------------------------| |----------|--------------------------------|
| Projekt | [Projektname] | | Project | [Project name] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Version | [1.0] | | Version | [1.0] |
| Status | [Entwurf / Freigegeben] | | Status | [Draft / Released] |
| ASIL | [QM / A / B / C / D] | | ASIL | [QM / A / B / C / D] |
| Autor | [Name] | | Author | [Name] |
| Parent | [SA-XXX, falls vorhanden] | | Parent | [SA-XXX, if applicable] |
--- ---
## 1. Verantwortung ## 1. Responsibility
[Ein bis zwei Saetze: Was tut diese Komponente? Wo ist die Abgrenzung zu Nachbar-Komponenten?] [One or two sentences: what does this component do? Where is the boundary to neighbouring components?]
## 2. Statische Sicht ## 2. Static view
### 2.1 Komponentendiagramm ### 2.1 Component diagram
```plantuml ```plantuml
@startuml @startuml
package "[Komponenten-Name]" { package "[Component name]" {
[Submodul A] [Submodule A]
[Submodul B] [Submodule B]
} }
[Submodul A] --> [Submodul B] [Submodule A] --> [Submodule B]
[Komponenten-Name] ..> [Nachbar-Komponente] : nutzt [Component name] ..> [Neighbour component] : uses
@enduml @enduml
``` ```
### 2.2 Eingebettete / verwendete Komponenten ### 2.2 Embedded / used components
| Komponente | Verweis | Verwendung | | Component | Reference | Use |
|---------------|----------|--------------------------| |---------------|-----------|---------------------------|
| [Name] | SWA-YYY | [wofuer] | | [Name] | SWA-YYY | [for what] |
## 3. Schnittstellen ## 3. Interfaces
### 3.1 Bereitgestellte Schnittstelle (Provided) ### 3.1 Provided interface
```c ```c
/** /**
* @brief [Kurzbeschreibung] * @brief [Short description]
* @param [name] [Bedeutung, Wertebereich] * @param [name] [Meaning, value range]
* @return [Status / Wert] * @return [Status / value]
* @pre [Vorbedingung] * @pre [Precondition]
* @post [Nachbedingung] * @post [Postcondition]
*/ */
Status component_init(const Config* cfg); Status component_init(const Config* cfg);
``` ```
| Funktion | Zweck | Pre-Condition | Post-Condition | | Function | Purpose | Pre-condition | Post-condition |
|------------------|----------------------|-----------------------|------------------------| |------------------|--------------------|-----------------------|------------------------|
| component_init | Initialisierung | cfg != NULL | Komponente betriebsbereit | | component_init | Initialisation | cfg != NULL | Component ready |
| component_send | Daten senden | initialisiert | Daten in TX-Buffer | | component_send | Send data | initialised | Data in TX buffer |
### 3.2 Benoetigte Schnittstelle (Required) ### 3.2 Required interface
| Schnittstelle | Bereitgestellt von | Zweck | | Interface | Provided by | Purpose |
|-------------------|--------------------|-----------------------| |-------------------|--------------------|---------------------|
| ILogger::log() | LoggerComponent | Diagnose / Tracing | | ILogger::log() | LoggerComponent | Diagnostics / tracing |
| IClock::now() | ClockComponent | Zeitstempel | | IClock::now() | ClockComponent | Timestamps |
## 4. Dynamisches Verhalten ## 4. Dynamic behaviour
### 4.1 Sequenzdiagramm (kritischer Ablauf) ### 4.1 Sequence diagram (critical flow)
```plantuml ```plantuml
@startuml @startuml
participant App participant App
participant "[Komponente]" as C participant "[Component]" as C
participant HW participant HW
App -> C: init(cfg) App -> C: init(cfg)
C -> HW: configure C -> HW: configure
@@ -90,7 +90,7 @@ C --> App: STATUS_OK
@enduml @enduml
``` ```
### 4.2 Zustandsdiagramm (falls zutreffend) ### 4.2 State diagram (if applicable)
```plantuml ```plantuml
@startuml @startuml
@@ -103,46 +103,45 @@ Error --> Ready : reset()
@enduml @enduml
``` ```
## 5. Ressourcen-Bedarf ## 5. Resource demand
| Ressource | Worst-Case | Methode der Bestimmung | | Resource | Worst case | Method of determination |
|-------------------|--------------|-----------------------------| |-------------------|--------------|------------------------------|
| Stack | [z.B. 256 B] | [Messung / statische Analyse] | | Stack | [e.g. 256 B] | [Measurement / static analysis] |
| Heap | [z.B. 0 B] | [keine Heap-Nutzung] | | Heap | [e.g. 0 B] | [No heap use] |
| Flash | [z.B. 4 KB] | [Map-File des Linkers] | | Flash | [e.g. 4 KB] | [Linker map file] |
| RAM (statisch) | [z.B. 128 B] | [Map-File des Linkers] | | RAM (static) | [e.g. 128 B] | [Linker map file] |
| CPU-Last | [z.B. < 1 %] | [Messung auf Zielsystem] | | CPU load | [e.g. < 1%] | [Measurement on target] |
| Worst-Case Timing | [z.B. 200 us / Aufruf init()] | [Messung HiL] | | Worst-case timing | [e.g. 200 us / call init()] | [HiL measurement] |
## 6. Fehlerverhalten ## 6. Failure behaviour
| Fehlerfall | Erkennung | Reaktion | | Failure case | Detection | Reaction |
|-----------------------|-------------------|---------------------------| |-----------------------|-------------------|---------------------------|
| Ungueltige Konfig | Parameter-Check | Status STATUS_EINVAL | | Invalid config | Parameter check | Status STATUS_EINVAL |
| HW-Timeout | Timer | Retry, dann STATUS_TIMEOUT | | HW timeout | Timer | Retry, then STATUS_TIMEOUT |
| Buffer voll | Check vor Schreiben | STATUS_NOSPACE | | Buffer full | Pre-write check | STATUS_NOSPACE |
## 7. Designentscheidungen ## 7. Design decisions
| Entscheidung | Alternative(n) | Begruendung | | Decision | Alternative(s) | Rationale |
|------------------------|------------------|--------------------------| |------------------------|------------------|----------------------------|
| [z.B. statische Allokation] | [Heap] | [deterministisch, MISRA] | | [e.g. static allocation] | [Heap] | [Deterministic, MISRA] |
| [Lock-Strategie] | [Mutex / lock-free] | [Begruendung] | | [Locking strategy] | [Mutex / lock-free] | [Rationale] |
## 8. Mapping auf Anforderungen ## 8. Mapping to requirements
| Anforderung | Wie abgedeckt | Verifikations-Test | | Requirement | How covered | Verification test |
|---------------|----------------------------------------------|----------------------------| |---------------|-----------------------------------------------|----------------------------|
| SWE-XXX | [welcher Teil dieser Komponente erfuellt es] | TST-UNIT-XXX, TST-INT-YYY | | SWE-XXX | [which part of this component fulfils it] | TST-UNIT-XXX, TST-INT-YYY |
| SWE-YYY | [...] | TST-UNIT-YYY | | SWE-YYY | [...] | TST-UNIT-YYY |
Jede in den `links` referenzierte SWE-Anforderung muss in dieser Tabelle einen Eintrag haben. Every SWE requirement listed in `links` must have an entry in this table.
## 9. Detail-Design ## 9. Detailed design
Detail-Design (ASPICE SWE.3) wird ab ASIL-C separat in `arch/swd/SWD-XXX.md` gefuehrt. Detailed design (ASPICE SWE.3) is maintained separately under `arch/swd/SWD-XXX.md` from ASIL-C upwards. For ASIL-A/B and QM, code plus header comments are sufficient.
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).* *Changes to this architecture element go through a PR with at least 2 technical-review approvals (see SWE Plan).*
vorlagen/SWE-Plan-vorlage.md
+87 -87
View File
@@ -1,132 +1,132 @@
# Software Development Plan (SWE-Plan) # Software Development Plan (SWE Plan)
| Feld | Wert | | Field | Value |
|-----------------|-------------------------------| |------------------|--------------------------------|
| Projekt | [Projektname] | | Project | [Project name] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Version | [1.0] | | Version | [1.0] |
| Status | [Entwurf / Freigegeben] | | Status | [Draft / Released] |
| ASIL | [QM / A / B / C / D] | | ASIL | [QM / A / B / C / D] |
--- ---
## 1. Entwicklungsmethode ## 1. Development method
[Beschreibung der Vorgehensweise: iterativ, V-Modell-angelehnt, oder hybrid.] [Describe the approach: iterative, V-model aligned, or hybrid.]
Grundstruktur folgt dem V-Modell (ISO 26262 Part 6): The base structure follows the V-model (ISO 26262 Part 6):
- Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung - Left side: requirements → architecture → detailed design → implementation
- Rechte Seite: Unit Test → Integrations-Test → System-Test - Right side: unit test → integration test → system test
- Iterationen innerhalb der Phasen moeglich - Iterations within phases are possible
Aenderungen werden ueber Change Requests gesteuert (siehe PM-Plan). Changes are managed via change requests (see PM Plan).
## 2. Programmiersprache und Standards ## 2. Programming language and standards
| Aspekt | Festlegung | | Aspect | Decision |
|---------------------|-----------------------------------------------------| |---------------------|-----------------------------------------------------|
| Sprache | [C (C99/C11) / C++ (C++14/17) / Rust] | | Language | [C (C99/C11) / C++ (C++14/17) / Rust] |
| Coding Standard | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023] | | Coding standard | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023] |
| Projekt-Guidelines | [Verweis auf Coding-Guidelines im Wiki] | | Project guidelines | [Reference to coding guidelines in the wiki] |
| Namenskonvention | [z.B. snake_case fuer Funktionen, UPPER_CASE fuer Makros] | | Naming convention | [e.g. snake_case for functions, UPPER_CASE for macros] |
### MISRA-Handhabung ### MISRA handling
- Alle Required- und Mandatory-Regeln werden eingehalten - All Required and Mandatory rules are observed
- Advisory-Regeln: Liste der angewendeten Regeln im Wiki dokumentiert - Advisory rules: list of applied rules documented in the wiki
- Abweichungen werden per MISRA Deviation Record dokumentiert - Deviations are documented per MISRA deviation record
- Projektweite Abweichungen per MISRA Deviation Permit genehmigt - Project-wide deviations are approved via MISRA deviation permit
- MISRA-Pruefung laeuft automatisch in der CI-Pipeline - MISRA check runs automatically in the CI pipeline
## 3. Build-Umgebung ## 3. Build environment
| Komponente | Tool / Version | | Component | Tool / Version |
|--------------------|-----------------------------------------------------| |--------------------|-----------------------------------------------------|
| Build-System | [CMake X.Y / SCons X.Y / Make] | | Build system | [CMake X.Y / SCons X.Y / Make] |
| Compiler | [GCC ARM X.Y / Clang X.Y] | | Compiler | [GCC ARM X.Y / Clang X.Y] |
| Zielplattform | [z.B. ARM Cortex-R5, Cortex-M4] | | Target platform | [e.g. ARM Cortex-R5, Cortex-M4] |
| Host-Plattform | [Linux x86_64 / macOS ARM64] | | Host platform | [Linux x86_64 / macOS ARM64] |
| CI-Runner | [GitLab Runner, Docker Image: ...] | | CI runner | [Gitea Runner, Docker image: ...] |
Build-Umgebung ist reproduzierbar: entweder per Docker-Image oder per dokumentierter Toolchain-Installation. The build environment is reproducible: either via a Docker image or via a documented toolchain installation.
## 4. Branching-Strategie ## 4. Branching strategy
``` ```
main — Stabiler, freigegebener Stand main — stable, released state
develop — Aktueller Entwicklungsstand develop — current development state
feature/SWR-XXX — Feature-Branch pro Anforderung feature/SWE-XXX — feature branch per requirement
bugfix/BUG-XXX — Bugfix-Branch bugfix/BUG-XXX — bug-fix branch
release/vX.Y — Release-Vorbereitung release/vX.Y — release preparation
hotfix/vX.Y.Z — Kritische Fixes nach Release hotfix/vX.Y.Z — critical fixes after release
``` ```
- Feature-Branches von `develop` abzweigen - Feature branches are taken off `develop`
- Merge nach `develop` nur per MR mit Approval - Merge to `develop` only via PR with approval
- `main` und `release/*` sind geschuetzt (kein direkter Push) - `main` and `release/*` are protected (no direct push)
- Branch-Name enthaelt Issue-Nummer - Branch name includes the issue number
Details: siehe `gitlab-aspice-setup.md`. Details: see `gitea-aspice-setup.md`.
## 5. Review-Verpflichtungen ## 5. Review obligations
| Artefakt | Review-Art | Mindest-Approvals | | Artefact | Review type | Min. approvals |
|-----------------------------|-------------------|--------------------| |-----------------------------|--------------------|-----------------|
| Quellcode (MR) | Peer Review | 1 | | Source code (PR) | Peer review | 1 |
| Safety-relevanter Code | Technical Review | 2 | | Safety-relevant code | Technical review | 2 |
| Architektur-Dokument | Technical Review | 2 | | Architecture document | Technical review | 2 |
| Anforderungen | Technical Review | 1 | | Requirements | Technical review | 1 |
| Testfaelle | Peer Review | 1 | | Test cases | 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). Every PR must be reviewed and approved before merge. Self-merges are not permitted (exception: 1-person project with documented self-review).
## 6. Definition of Done ## 6. Definition of Done
Ein Feature / eine Anforderung gilt als "Done" wenn: A feature / requirement is "Done" when:
- [ ] Code ist implementiert und kompiliert fehlerfrei - [ ] Code is implemented and compiles without errors
- [ ] MISRA-Check in CI ist gruen (keine neuen Violations) - [ ] MISRA check in CI is green (no new violations)
- [ ] Static Analysis (Cppcheck, clang-tidy) hat keine neuen Findings - [ ] Static analysis (Cppcheck, clang-tidy) has no new findings
- [ ] Unit Tests sind geschrieben und gruen - [ ] Unit tests are written and green
- [ ] Coverage-Ziel ist erreicht (siehe Abschnitt 8) - [ ] Coverage target is reached (see section 8)
- [ ] MR ist reviewed und approved - [ ] PR is reviewed and approved
- [ ] Anforderung ist mit Test verlinkt (Traceability) - [ ] Requirement is linked to a test (traceability)
- [ ] Dokumentation ist aktualisiert (falls betroffen) - [ ] Documentation is updated (if affected)
## 7. Integration und Test-Strategie ## 7. Integration and test strategy
| Teststufe | Verantwortlich | Umgebung | Automatisierung | | Test level | Owner | Environment | Automation |
|---------------------|----------------|----------------|-----------------| |--------------------|----------------|---------------|------------------|
| Unit Test | Entwickler | Host (x86) | CI-Pipeline | | Unit test | Developer | host (x86) | CI pipeline |
| Integrations-Test | Entwickler | Host / SiL | CI / manuell | | Integration test | Developer | host / SiL | CI / manual |
| System-Test | Test / QA | SiL / HiL | teilweise | | System test | Test / QA | SiL / HiL | partial |
| Abnahme-Test | Auftraggeber | HiL / Fahrzeug | manuell | | Acceptance test | Client | HiL / vehicle | manual |
- Unit Tests laufen auf Host-Plattform (Cross-Compilation fuer Tests auf x86) - Unit tests run on the host platform (cross-compilation for x86 testing)
- Integrationstests pruefen Zusammenspiel der Module - Integration tests verify module interaction
- System-Tests pruefen gegen System-Anforderungen - System tests verify against system requirements
- HiL-Tests werden vom Auftraggeber bereitgestellt oder gemeinsam definiert - HiL tests are provided by the client or jointly defined
## 8. Coverage-Ziele ## 8. Coverage targets
| ASIL | Statement Coverage | Branch Coverage | MC/DC | | ASIL | Statement coverage | Branch coverage | MC/DC |
|------|--------------------|-----------------|----------| |------|--------------------|-----------------|----------|
| QM | >= 80% empfohlen | — | — | | QM | ≥ 80% recommended | — | — |
| A | >= 80% | empfohlen | — | | A | ≥ 80% | recommended | — |
| B | >= 80% | >= 80% | — | | B | ≥ 80% | ≥ 80% | — |
| C | >= 90% | >= 80% | empfohlen| | C | ≥ 90% | ≥ 80% | recommended |
| D | >= 90% | >= 90% | >= 80% | | D | ≥ 90% | ≥ 90% | ≥ 80% |
Konkrete Zielwerte fuer dieses Projekt: Concrete target values for this project:
| Metrik | Zielwert | | Metric | Target |
|---------------------|------------| |---------------------|------------|
| Statement Coverage | >= [X]% | | Statement coverage | ≥ [X]% |
| Branch Coverage | >= [X]% | | Branch coverage | ≥ [X]% |
| MC/DC | >= [X]% (falls anwendbar) | | MC/DC | ≥ [X]% (where applicable) |
Coverage wird in der CI gemessen und als Artefakt archiviert. Abweichungen vom Ziel werden begruendet und im QA-Report dokumentiert. Coverage is measured in CI and archived as an artefact. Deviations from the target are justified and documented in the QA report.
--- ---
*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.* *Changes to this plan are versioned in the Gitea wiki.*
vorlagen/Test-Plan-vorlage.md
+46 -98
View File
@@ -1,121 +1,69 @@
# Testplan # Test Plan
| Feld | Wert | | Field | Value |
|-----------------|-------------------------------| |-----------------|--------------------------------|
| Projekt | [Projektname] | | Project | [Project name] |
| Datum | [YYYY-MM-DD] | | Date | [YYYY-MM-DD] |
| Version | [1.0] | | Version | [1.0] |
| Status | [Entwurf / Freigegeben] | | Status | [Draft / Released] |
| ASIL | [QM / A / B / C / D] |
| Bezug | SWE-Plan Version [X.Y] |
--- ---
## 1. Testziele ## 1. Test strategy
- Nachweis, dass die Software die spezifizierten Anforderungen erfuellt [Describe the approach: e.g. test-first, requirement-based, risk-based.]
- Nachweis der strukturellen Code-Abdeckung gemaess ASIL-Vorgaben
- Nachweis der Robustheit gegenueber Fehlbedienung und Grenzwerten
- Identifikation von Defekten vor der Integration / Auslieferung
## 2. Teststrategie Each requirement has at least one test (`@reqs` tag in the test). Coverage targets as in the SWE Plan section 8.
| Teststufe | Testziel | Methode | Automatisierung | ## 2. Test levels
|---------------------|---------------------------------------------|------------------|-----------------|
| 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 | Level | Scope | Tool | Environment | Status |
|---------------|----------------------|------------|-------------|---------------|
| Unit | Functions / modules | [CppUTest] | host x86 | [planned] |
| Integration | Module interaction | [CppUTest] | host / SiL | [planned] |
| System | End-to-end | [manual] | SiL / HiL | [planned] |
| Acceptance | Client acceptance | [manual] | HiL / vehicle | [planned] |
- Framework: [CppUTest / Google Test / Unity+CMock] ## 3. Test management
- Laufen auf Host-Plattform (x86)
- Jede Anforderung hat mindestens einen zugehoerigen Testfall
- Negative Tests und Grenzwerte sind Pflicht
### Integrationstests - Tests live in `tests/unit/`, `tests/integration/`, ...
- Each test file carries `@reqs` tags pointing to the covered requirements
- Tests run automatically in CI on every push
- Coverage report is published as a CI artefact
- Pruefen Schnittstellen zwischen Modulen ## 4. Test selection per component
- Laufen auf Host oder SiL-Umgebung
- Kommunikationsschnittstellen (CAN, SPI, UART) werden per Mock oder Simulator getestet
### System-Tests | Component | ASIL | Test file | Method |
|--------------------|------|----------------------------------|---------------------------------|
| [Component A] | [D] | tests/unit/test_componentA.c | Equivalence classes + boundary + MC/DC |
| [Component B] | [B] | tests/unit/test_componentB.c | Equivalence classes + boundary |
| [Component C] | [QM] | tests/unit/test_componentC.c | Equivalence classes |
- Pruefen gegen System-Anforderungen ## 5. Entry and exit criteria
- Laufen auf SiL oder HiL
- Testfaelle werden aus System-Requirements abgeleitet
## 3. Coverage-Ziele **Entry to test execution:**
- Code compiles
- Doorstop check is green
- Static analysis has no critical findings
| Metrik | Zielwert | Messung | **Exit:**
|---------------------|----------------|------------------| - All tests green
| Statement Coverage | >= [X]% | gcov/lcov | - Coverage target reached
| Branch Coverage | >= [X]% | gcov/lcov | - Test report archived
| MC/DC | >= [X]% (falls anwendbar) | MCDC-Star / kommerziell |
Referenz: ISO 26262 Part 6, Table 9. ## 6. Defect handling
| ASIL | Statement | Branch | MC/DC | - Test failure = blocking issue
|------|-----------|---------|--------------| - Issue raised via Gitea Issues, referenced in the PR
| QM | empfohlen | — | — | - Severity classification per QA Plan section 4
| A | Pflicht | empfohlen | — |
| B | Pflicht | Pflicht | — |
| C | Pflicht | Pflicht | empfohlen |
| D | Pflicht | Pflicht | Pflicht |
## 4. Testumgebung ## 7. Reporting
| Komponente | Beschreibung | Test reports are generated automatically:
|---------------------|----------------------------------------------------| - Console output of the test framework (TAP / JUnit XML)
| Host-Plattform | [Linux x86_64 / macOS ARM64] | - Coverage HTML from lcov
| Cross-Compiler | [GCC ARM X.Y] | - Both as CI artefacts under `tests/results/`
| 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.* *Changes to this plan are versioned in the Gitea wiki.*
vorlagen/Traceability-Matrix-vorlage.md
+44 -44
View File
@@ -1,67 +1,67 @@
# Traceability-Matrix # Traceability Matrix
## Prinzip ## Principle
Die Traceability-Matrix stellt die Rueckverfolgbarkeit von der Anforderung bis zum Test sicher: The traceability matrix ensures end-to-end traceability from requirement to test:
``` ```
System-Anforderung → Software-Anforderung → Architektur-Element → Implementierung (MR/Datei) → Testfall → Testergebnis System requirement → Software requirement → Architecture element → Implementation (PR/file) → Test case → Test result
``` ```
Jede Ebene muss bidirektional verfolgbar sein: Each level must be traceable in both directions:
- **Vorwaerts:** Anforderung → wurde sie implementiert und getestet? - **Forward:** requirement → has it been implemented and tested?
- **Rueckwaerts:** Testfall → welche Anforderung verifiziert er? - **Backward:** test case → which requirement does it verify?
## Tabellenstruktur ## Table structure
| Sys-Req | SW-Req | ASIL | Arch-Element | Implementierung | Testfall | Test-Ergebnis | Status | | Sys-Req | SW-Req | ASIL | Arch element | Implementation | Test case | Test result | Status |
|---------|---------|------|--------------|----------------------|----------|---------------|--------------| |---------|---------|------|--------------|----------------------|-----------|---------------|--------------|
| SYR-001 | SWR-010 | B | MOD-Timer | MR !23, timer.c | TC-010 | Pass (v1.2) | Vollstaendig | | SYR-001 | SWR-010 | B | MOD-Timer | PR !23, timer.c | TC-010 | Pass (v1.2) | Complete |
| SYR-001 | SWR-011 | B | MOD-Timer | MR !23, timer.c | TC-011 | Pass (v1.2) | Vollstaendig | | SYR-001 | SWR-011 | B | MOD-Timer | PR !23, timer.c | TC-011 | Pass (v1.2) | Complete |
| SYR-002 | SWR-020 | A | MOD-CAN | MR !31, can_driver.c | TC-020 | Pass (v1.2) | Vollstaendig | | SYR-002 | SWR-020 | A | MOD-CAN | PR !31, can_driver.c | TC-020 | Pass (v1.2) | Complete |
| SYR-003 | SWR-030 | B | MOD-Watchdog | — | — | — | Offen | | SYR-003 | SWR-030 | B | MOD-Watchdog | — | — | — | Open |
| — | SWR-040 | QM | MOD-Diag | MR !35, diag.c | TC-040 | Fail (v1.1) | Finding offen| | — | SWR-040 | QM | MOD-Diag | PR !35, diag.c | TC-040 | Fail (v1.1) | Finding open |
## Spalten-Erklaerung ## Column explanation
| Spalte | Beschreibung | | Column | Description |
|------------------|----------------------------------------------------------------| |------------------|----------------------------------------------------------------|
| Sys-Req | System-Anforderungs-ID (GitLab Issue mit Label `req::system`) | | Sys-Req | System requirement ID (Gitea issue with label `req::system`) |
| SW-Req | Software-Anforderungs-ID (GitLab Issue mit Label `req::software`) | | SW-Req | Software requirement ID (Gitea issue with label `req::software`) |
| ASIL | Zugewiesener ASIL-Level | | ASIL | Assigned ASIL level |
| Arch-Element | Architektur-Modul oder -Komponente | | Arch element | Architecture module or component |
| Implementierung | Merge Request und/oder Datei | | Implementation | Pull request and/or file |
| Testfall | Testfall-ID (GitLab Issue mit Label `test::*`) | | Test case | Test case ID (Gitea issue with label `test::*`) |
| Test-Ergebnis | Pass/Fail mit Version/Datum | | Test result | Pass/Fail with version/date |
| Status | Vollstaendig / Offen / Finding offen | | Status | Complete / Open / Finding open |
## Lueckenanalyse ## Gap analysis
Die Matrix macht Luecken sichtbar: The matrix makes gaps visible:
- **Anforderung ohne Test:** Zeile ohne Testfall-Eintrag → Test fehlt - **Requirement without test:** row without test-case entry → test missing
- **Anforderung ohne Implementierung:** Zeile ohne MR → nicht implementiert - **Requirement without implementation:** row without PR → not implemented
- **Test ohne Anforderung:** Testfall der keiner Anforderung zugeordnet ist → ueberpruefen - **Test without requirement:** test case not assigned to any requirement → verify
- **Fail ohne Finding:** Fehlgeschlagener Test ohne dokumentiertes Finding → nacharbeiten - **Fail without finding:** failed test without a documented finding → rework
## Automatische Generierung aus GitLab ## Automatic generation from Gitea
Diese Matrix kann aus GitLab-Issues automatisch generiert werden: The matrix can be generated automatically from Gitea issues:
1. Python-Skript liest ueber GitLab API alle Issues mit `req::*`-Labels 1. A Python script reads all issues with `req::*` labels via the Gitea API
2. Folgt Issue-Links zu Architektur-Issues, MRs und Test-Issues 2. It follows issue links to architecture issues, PRs, and test issues
3. Liest CI-Pipeline-Ergebnisse (JUnit-XML) fuer Testergebnisse 3. It reads CI-pipeline results (JUnit XML) for test outcomes
4. Erzeugt die Matrix als Markdown-Tabelle oder CSV 4. It produces the matrix as a Markdown table or CSV
**Voraussetzung:** Issues sind korrekt verlinkt und gelabelt (siehe `gitlab-aspice-setup.md`). **Precondition:** issues are correctly linked and labelled (see `gitea-aspice-setup.md`).
**Ausgabe-Formate:** **Output formats:**
- Markdown (fuer Wiki / Dokumentation) - Markdown (for wiki / documentation)
- CSV (fuer Import in Kundensysteme) - CSV (for import into customer systems)
- HTML (fuer Reporting) - HTML (for reporting)
Ein Beispiel-Skript liegt unter `tools/traceability-report.py` im Projekt-Repository. An example script lives at `tools/traceability-report.py` in the project repository.
--- ---
*Die aktuelle Traceability-Matrix wird bei jedem Release aktualisiert und im Wiki abgelegt.* *The current traceability matrix is updated on every release and stored in the wiki.*
vorlagen/angebot-vorlage.md
+34 -34
View File
@@ -1,7 +1,7 @@
<!-- slohmaier Engineering – Angebotsvorlage --> <!-- slohmaier Engineering – Quotation template -->
<!-- Verwendung: Platzhalter {{ ... }} ersetzen, dann mit pandoc exportieren --> <!-- Use: replace {{ ... }} placeholders, then export with pandoc -->
<!-- Export: pandoc angebot.md -o angebot.html --standalone --> <!-- Export: pandoc angebot.md -o angebot.html --standalone -->
<!-- Beispiel: angebot-beispiel.html --> <!-- Example: angebot-beispiel.html -->
<div class="logo"> <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-light.svg" alt="slohmaier" class="logo-light" />
@@ -10,65 +10,65 @@
--- ---
# Angebot: {{ Titel }} # Quotation: {{ title }}
**Datum:** {{ datum }} **Date:** {{ date }}
**Version:** 1.0 **Version:** 1.0
**Projekt:** {{ projektname }} **Project:** {{ project name }}
**Auftraggeber:** {{ auftraggeber }} **Client:** {{ client }}
--- ---
## Zusammenfassung ## Summary
{{ Kurze Beschreibung was angeboten wird }} {{ Short description of what is being offered }}
--- ---
## Inhalt ## Content
### 1. Ziel ### 1. Goal
{{ Was soll erreicht werden? }} {{ What is to be achieved? }}
### 2. Umfang ### 2. Scope
{{ Was ist enthalten? Aufzaehlung der Leistungen }} {{ What is included? List of services }}
**Nicht enthalten:** {{ Was ist explizit ausgeschlossen? }} **Not included:** {{ What is explicitly excluded? }}
### 3. Anforderungen ### 3. Requirements
| Nr. | Anforderung | Prioritaet | | # | Requirement | Priority |
|-----|-------------|------------| |-----|-------------|------------|
| 1 | ... | Muss | | 1 | ... | Must |
| 2 | ... | Soll | | 2 | ... | Should |
| 3 | ... | Kann | | 3 | ... | Could |
### 4. Vorgehen ### 4. Approach
1. {{ Schritt 1 }} 1. {{ Step 1 }}
2. {{ Schritt 2 }} 2. {{ Step 2 }}
3. {{ Schritt 3 }} 3. {{ Step 3 }}
Geschaetzte Dauer: **{{ Dauer }}** Estimated duration: **{{ duration }}**
### 5. Offene Punkte ### 5. Open items
- [ ] {{ Voraussetzung 1 }} - [ ] {{ Precondition 1 }}
- [ ] {{ Voraussetzung 2 }} - [ ] {{ Precondition 2 }}
### 6. Lieferergebnis ### 6. Deliverable
{{ Was wird am Ende geliefert? Format, Umfang }} {{ What is delivered at the end? Format, scope }}
--- ---
**Konditionen** **Terms**
Tagessatz: auf Anfrage Day rate: on request
Zahlungsziel: 14 Tage nach Rechnungsstellung Payment terms: 14 days from invoice date
Gueltig bis: {{ datum + 14 Tage }} Valid until: {{ date + 14 days }}
--- ---