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
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 |
|----------|--------|------------|
| PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan | **Word** (signiert) | Formell freigegeben, an Kunden geliefert |
| Reviews, Non-Conformities, Audit-Protokolle | **Word** | Audit-Artefakte |
| MISRA Permits / Records | **Word** | Audit-Artefakte |
| Angebote, Verträge | **Word** | klar |
| Requirements (SYS, SWE) | **Markdown** (Doorstop) | Diff, Traceability, lebt täglich |
| Architektur (SA, SWA, SWD) | **Markdown** (Doorstop) | Mapping per `links:` |
| Code, Tests, CI | Code | klar |
| Liefer-PDFs an Kunden | **PDF via pandoc** aus MD | formelle Übergabe der Engineering-Artefakte |
| Artifact | Format | Rationale |
|----------|--------|-----------|
| PID, PM Plan, QA Plan, SWE Plan, Test Plan | **Word** (signed) | Formally released, delivered to customers |
| Reviews, non-conformities, audit minutes | **Word** | Audit artifacts |
| MISRA permits / records | **Word** | Audit artifacts |
| Quotations, contracts | **Word** | obvious |
| Requirements (SYS, SWE) | **Markdown** (Doorstop) | Diff, traceability, lives daily |
| Architecture (SA, SWA, SWD) | **Markdown** (Doorstop) | Mapping via `links:` |
| Code, tests, CI | source | obvious |
| 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/
sys/ SYS-001.md, SYS-002.md
swe/ SWE-001.md, SWE-002.md
arch/
sys/ SA-001.md, SA-002.md (ASPICE SYS.3)
swe/ SWA-001.md, SWA-002.md (ASPICE SWE.2)
swd/ SWD-001.md (ASPICE SWE.3, ab ASIL-C)
swd/ SWD-001.md (ASPICE SWE.3, ASIL-C+)
docs/
PID.md
PM-Plan.md
@@ -44,7 +44,7 @@ projekt-name/
Test-Plan.md
reviews/
non-conformities/
traceability/ (generiert von Doorstop)
traceability/ (generated by Doorstop)
src/
tests/
unit/
@@ -59,9 +59,9 @@ projekt-name/
.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
---
@@ -71,9 +71,9 @@ links:
- 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
@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:
- Alle Links valide
- Alle Requirements haben Tests
- Keine Lücken in der Traceability
Doorstop verifies:
- All links resolve
- All requirements have tests
- 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/swe/SWA-XXX.md` — Software-Architektur, Mapping auf SWE-Anforderungen
- `arch/swd/SWD-XXX.md` — Software Detailed Design (nur ab ASIL-C)
- `arch/sys/SA-XXX.md` — system architecture, mapping to SYS requirements
- `arch/swe/SWA-XXX.md` — software architecture, mapping to SWE requirements
- `arch/swd/SWD-XXX.md` — software detailed design (ASIL-C+ only)
**Mapping** geschieht über `links:` im Frontmatter:
**Mapping** via `links:` in frontmatter:
```markdown
---
@@ -113,12 +113,12 @@ links:
# SWA-003: CAN Driver Component
```
`doorstop check` verifiziert in beide Richtungen:
- Jede SWE-Anforderung wird von mindestens einem SWA-Element abgedeckt
- Jedes SWA-Element verweist auf mindestens eine SWE-Anforderung
- `doorstop publish all docs/traceability/` erzeugt die Traceability-Matrix
`doorstop check` verifies bidirectionally:
- Every SWE requirement is covered by at least one SWA element
- Every SWA element points to at least one SWE requirement
- `doorstop publish all docs/traceability/` produces the traceability matrix
**Code → Architektur** per Header-Kommentar im Modul:
**Code → architecture** via header comment:
```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
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 |
|-----|----------|
| Requirement neu/ändern | mind. 1 Reviewer |
| Architektur-Element (SA/SWA/SWD) | mind. 2 Technical Reviewer |
| Dokument (Plan, Protokoll) | mind. 1 Reviewer |
| Code-Änderung | mind. 1 Reviewer |
| MISRA Permit | Technical Lead |
| Item | Approver |
|------|----------|
| New / changed requirement | ≥ 1 reviewer |
| Architecture element (SA/SWA/SWD) | ≥ 2 technical reviewers |
| Document (plan, minutes) | ≥ 1 reviewer |
| Code change | ≥ 1 reviewer |
| MISRA permit | technical lead |
Merge = formale Freigabe. Git-History ist der Audit-Trail.
Merge = formal release. Git history is the audit trail.
## Traceability
Vier Ebenen werden verknüpft:
Four levels are linked:
1. **Doorstop-Links** in `.md`-Dateien: `links: [SYS-001: abc123]`
2. **Architektur-Mapping** (Arch-Element → Anforderung) ebenfalls per Doorstop
3. **Commit-Messages**: `feat(SWE-001): implement CAN init` oder `feat(SWA-003): ...`
4. **Issue-Referenzen** in PRs: `Refs #42`
1. **Doorstop links** in `.md` files: `links: [SYS-001: abc123]`
2. **Architecture mapping** (arch element → requirement) also via Doorstop
3. **Commit messages**: `feat(SWE-001): implement CAN init` or `feat(SWA-003): ...`
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
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
2. `cppcheck --addon=misra` — MISRA-Compliance
3. `make test` — Unit Tests
4. `make coverage` — Coverage-Report
5. `doorstop publish` — Traceability-Report aktualisieren
1. `doorstop check` — requirement links valid
2. `cppcheck --addon=misra` — MISRA compliance
3. `make test` — unit tests
4. `make coverage` — coverage report
5. `doorstop publish` — refresh traceability report
## Dateien in diesem Repo
## Files in this repo
| Pfad | Inhalt |
|------|--------|
| `toolstack/toolstack.md` | Vollständiger Tool-Stack |
| `gitea-aspice-setup.md` | Gitea einrichten für ASPICE |
| `dev-process-schaubild.html` | V-Modell Infografik |
| `vorlagen/` | Markdown-Vorlagen (Source of Truth) |
| `vorlagen-word/` | Generierte Word-Vorlagen + Master-Template `slohmaier-doc-template.docx` |
| `tools/build_word_template.py` | Erzeugt das neutrale Master-Word-Template mit Formatvorlagen, Deckblatt, Document Control |
| `tools/generate_word_vorlagen.sh` | Erzeugt aus den `.md`-Vorlagen die `.docx`-Versionen via pandoc |
| Path | Content |
|------|---------|
| `toolstack/toolstack.md` | Complete tool stack |
| `gitea-aspice-setup.md` | Setting up Gitea for ASPICE |
| `dev-process-schaubild.html` | V-model infographic |
| `vorlagen/` | Markdown templates (source of truth) |
| `vorlagen-word/` | Generated Word templates + master template `slohmaier-doc-template.docx` |
| `tools/build_word_template.py` | Builds the neutral Word master template with styles, cover page, document control |
| `tools/generate_word_vorlagen.sh` | Builds the `.docx` versions from the `.md` templates via pandoc |
## Word-Vorlagen neu generieren
## Regenerate Word templates
```bash
# Master-Template + alle abgeleiteten Word-Vorlagen neu bauen
# Rebuild master template + all derived Word templates
python3 tools/build_word_template.py
bash tools/generate_word_vorlagen.sh
```
Das Master-Template enthält ISO-9001-konform:
- Deckblatt mit Projekt, Dokument-ID, Version, Klassifikation
- Document Control (Freigaben, Änderungshistorie, Verteiler)
- Auto-Verzeichnisse (Inhalt, Abbildungen, Tabellen)
- Formatvorlagen für H1–H4, Body, Code, Note, Warning, Requirement
- Header/Footer mit Projekt, Dokument-ID, Klassifikation, Seitennummer
The master template is ISO-9001-compliant and includes:
- Cover page with project, document ID, version, classification
- Document control (approvals, revision history, distribution)
- Auto-tables of contents, figures, and tables
- Styles for H1–H4, Body, Code, Note, Warning, Requirement
- 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
git submodule add https://gitea.slohmaier.com/slohmaier/dev-process .dev-process
```
2. **Vorlagen kopieren** und im Projekt einchecken (statischer Snapshot).
3. **Fork / Clone** und als Basis für eigene Anpassungen verwenden.
2. **Copy templates** into the project and commit (static snapshot).
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)
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.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.add_tab_stop(Cm(8), WD_ALIGN_PARAGRAPH.CENTER)
tabs.add_tab_stop(Cm(16), WD_ALIGN_PARAGRAPH.RIGHT)
r1 = header_para.add_run("<PROJEKT>")
r1 = header_para.add_run("<PROJECT>")
r1.font.size = Pt(9)
r1.font.color.rgb = RGBColor(0x59, 0x59, 0x59)
header_para.add_run("\t")
r2 = header_para.add_run("<DOKUMENT-TITEL>")
r2 = header_para.add_run("<DOCUMENT-TITLE>")
r2.font.size = Pt(9)
r2.font.color.rgb = RGBColor(0x59, 0x59, 0x59)
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.bold = True
footer_para.add_run("\t")
fr3 = footer_para.add_run("Seite ")
fr3 = footer_para.add_run("Page ")
fr3.font.size = Pt(9)
fr3.font.color.rgb = RGBColor(0x59, 0x59, 0x59)
add_field(footer_para, "PAGE", "1")
@@ -298,7 +298,7 @@ def add_cover_page(doc):
# Classification banner
cls_p = doc.add_paragraph()
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.bold = True
cls_r.font.color.rgb = RGBColor(0xC5, 0x5A, 0x11)
@@ -306,12 +306,12 @@ def add_cover_page(doc):
# Title
title_p = doc.add_paragraph(style="Title")
title_p.alignment = WD_ALIGN_PARAGRAPH.CENTER
title_p.add_run("<Dokument-Titel>")
title_p.add_run("<Document title>")
# Subtitle
sub_p = doc.add_paragraph(style="Subtitle")
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):
doc.add_paragraph()
@@ -323,12 +323,12 @@ def add_cover_page(doc):
meta_tbl.columns[0].width = Cm(4.5)
meta_tbl.columns[1].width = Cm(8.5)
meta_data = [
("Projekt", "<Projektname>"),
("Dokument-ID", "<DOC-ID>"),
("Project", "<Project name>"),
("Document ID", "<DOC-ID>"),
("Version", "1.0"),
("Datum", "YYYY-MM-DD"),
("Status", "Entwurf"),
("Klassifikation", "Vertraulich"),
("Date", "YYYY-MM-DD"),
("Status", "Draft"),
("Classification", "Confidential"),
]
for i, (k, v) in enumerate(meta_data):
c1 = meta_tbl.cell(i, 0)
@@ -354,49 +354,49 @@ def add_cover_page(doc):
def add_document_control(doc):
doc.add_heading("Dokumentenlenkung", level=1)
doc.add_heading("Document Control", level=1)
doc.add_paragraph(
"Diese Seite dokumentiert die formale Lenkung dieses Dokuments gemaess "
"ISO 9001. Aenderungen werden nur ueber den Freigabeprozess wirksam."
"This page documents the formal control of this document per ISO 9001. "
"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.style = "Light Grid Accent 1"
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 = ""
r = hdr[i].paragraphs[0].add_run(h)
r.bold = True
set_cell_shading(hdr[i], LIGHT_GREY)
roles = ["Erstellt von", "Geprueft von", "Freigegeben von"]
roles = ["Author", "Reviewer", "Approver"]
for i, role in enumerate(roles, start=1):
appr_tbl.rows[i].cells[0].text = role
for j in (1, 2, 3):
appr_tbl.rows[i].cells[j].text = ""
doc.add_heading("Aenderungshistorie", level=2)
doc.add_heading("Revision History", level=2)
rev_tbl = doc.add_table(rows=3, cols=4)
rev_tbl.style = "Light Grid Accent 1"
rev_hdr = rev_tbl.rows[0].cells
for i, h in enumerate(["Version", "Datum", "Aenderung", "Autor"]):
for i, h in enumerate(["Version", "Date", "Change", "Author"]):
rev_hdr[i].text = ""
r = rev_hdr[i].paragraphs[0].add_run(h)
r.bold = True
set_cell_shading(rev_hdr[i], LIGHT_GREY)
rev_data = [
("0.1", "YYYY-MM-DD", "Initialer Entwurf", "<Autor>"),
("1.0", "YYYY-MM-DD", "Erstfreigabe", "<Autor>"),
("0.1", "YYYY-MM-DD", "Initial draft", "<Author>"),
("1.0", "YYYY-MM-DD", "First release", "<Author>"),
]
for i, row in enumerate(rev_data, start=1):
for j, v in enumerate(row):
rev_tbl.rows[i].cells[j].text = v
doc.add_heading("Verteilerkreis", level=2)
doc.add_heading("Distribution List", level=2)
dist_tbl = doc.add_table(rows=3, cols=3)
dist_tbl.style = "Light Grid Accent 1"
dist_hdr = dist_tbl.rows[0].cells
for i, h in enumerate(["Empfaenger", "Rolle", "Organisation"]):
for i, h in enumerate(["Recipient", "Role", "Organisation"]):
dist_hdr[i].text = ""
r = dist_hdr[i].paragraphs[0].add_run(h)
r.bold = True
@@ -409,40 +409,40 @@ def add_document_control(doc):
def add_toc_pages(doc):
doc.add_heading("Inhaltsverzeichnis", level=1)
doc.add_heading("Table of Contents", level=1)
p = doc.add_paragraph()
add_field(
p,
'TOC \\o "1-3" \\h \\z \\u',
"Inhaltsverzeichnis aktualisieren: F9 (rechte Maustaste auf TOC > Felder aktualisieren)",
"Update TOC: F9 (right-click on TOC > Update Field)",
)
doc.add_page_break()
doc.add_heading("Abbildungsverzeichnis", level=1)
doc.add_heading("List of Figures", level=1)
p = doc.add_paragraph()
add_field(
p,
'TOC \\h \\z \\c "Abbildung"',
"Abbildungsverzeichnis aktualisieren: F9",
'TOC \\h \\z \\c "Figure"',
"Update list of figures: F9",
)
doc.add_page_break()
doc.add_heading("Tabellenverzeichnis", level=1)
doc.add_heading("List of Tables", level=1)
p = doc.add_paragraph()
add_field(
p,
'TOC \\h \\z \\c "Tabelle"',
"Tabellenverzeichnis aktualisieren: F9",
'TOC \\h \\z \\c "Table"',
"Update list of tables: F9",
)
doc.add_page_break()
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.style = "Light Grid Accent 1"
hdr = tbl.rows[0].cells
for i, h in enumerate(["Abkuerzung", "Bedeutung"]):
for i, h in enumerate(["Abbreviation", "Meaning"]):
hdr[i].text = ""
r = hdr[i].paragraphs[0].add_run(h)
r.bold = True
@@ -460,23 +460,23 @@ def add_abbreviations(doc):
def add_main_content(doc):
# Section 1
doc.add_heading("1. Einleitung", level=1)
doc.add_heading("1.1 Zweck", level=2)
doc.add_heading("1. Introduction", level=1)
doc.add_heading("1.1 Purpose", level=2)
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_paragraph("<Welches Produkt, welches Projekt, welche Phase?>")
doc.add_heading("1.3 Definitionen", level=2)
doc.add_heading("1.2 Scope", level=2)
doc.add_paragraph("<Which product, project, phase?>")
doc.add_heading("1.3 Definitions", level=2)
doc.add_paragraph(
"<Spezielle Begriffe, die im Dokument verwendet werden. Allgemeine Abkuerzungen "
"siehe Abkuerzungsverzeichnis.>"
"<Domain-specific terms used in this document. Generic abbreviations are listed "
"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.style = "Light Grid Accent 1"
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 = ""
r = ref_hdr[i].paragraphs[0].add_run(h)
r.bold = True
@@ -486,60 +486,60 @@ def add_main_content(doc):
ref_tbl.rows[i].cells[j].text = ""
# Section 2
doc.add_heading("2. Hauptinhalt", level=1)
doc.add_heading("2. Main Content", level=1)
doc.add_paragraph(
"<Hier beginnt der dokumenttyp-spezifische Inhalt. Die Vorlage liefert Struktur "
"und Formatvorlagen; konkrete Sektionen kommen aus der jeweiligen Dokumentart "
"(PID, QA-Plan, SWE-Plan, ...).>"
"<This is where the document-type-specific content begins. This template "
"provides structure and styles; concrete sections come from each document "
"type (PID, QA Plan, SWE Plan, ...).>"
)
# Demonstrate styles
doc.add_heading("2.1 Beispiel: Formatvorlagen", level=2)
doc.add_heading("2.1 Example: Styles", level=2)
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.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);"
)
set_paragraph_shading(code_p, LIGHT_GREY)
note_p = doc.add_paragraph(style="Note")
note_p.add_run("HINWEIS: ").bold = True
note_p.add_run("Hinweis-Stil fuer ergaenzende Informationen.")
note_p.add_run("NOTE: ").bold = True
note_p.add_run("Note style for supplementary information.")
set_paragraph_border(note_p, NOTE_BORDER, size=18, side="left")
set_paragraph_shading(note_p, NOTE_BG)
warn_p = doc.add_paragraph(style="Warning")
warn_p.add_run("ACHTUNG: ").bold = True
warn_p.add_run("Warn-Stil fuer sicherheitsrelevante Hinweise.")
warn_p.add_run("WARNING: ").bold = True
warn_p.add_run("Warning style for safety-relevant information.")
set_paragraph_border(warn_p, WARN_BORDER, size=18, side="left")
set_paragraph_shading(warn_p, WARN_BG)
req_p = doc.add_paragraph(style="Requirement")
req_p.add_run("REQ-001: ").bold = True
req_p.add_run(
"Requirement-Stil fuer in-line Anforderungen "
"(meist in Markdown via Doorstop, in Word fuer formelle Berichte)."
"Requirement style for inline requirements "
"(usually in Markdown via Doorstop, but in Word for formal reports)."
)
set_paragraph_border(req_p, REQ_BORDER, size=18, side="left")
set_paragraph_shading(req_p, REQ_BG)
doc.add_heading("2.2 Beispiel-Tabelle", level=2)
doc.add_heading("2.2 Example Table", level=2)
tbl = doc.add_table(rows=4, cols=3)
tbl.style = "Light Grid Accent 1"
hdr = tbl.rows[0].cells
for i, h in enumerate(["ID", "Beschreibung", "ASIL"]):
for i, h in enumerate(["ID", "Description", "ASIL"]):
hdr[i].text = ""
r = hdr[i].paragraphs[0].add_run(h)
r.bold = True
set_cell_shading(hdr[i], LIGHT_GREY)
rows = [
("F-01", "Apply bei Fahrer-Anforderung", "D"),
("F-05", "Release bei Fahrer-Anforderung", "B"),
("F-10", "HMI: LED-Steuerung", "QM"),
("F-01", "Apply on driver request", "D"),
("F-05", "Release on driver request", "B"),
("F-10", "HMI: LED control", "QM"),
]
for i, row in enumerate(rows, start=1):
for j, v in enumerate(row):
@@ -547,12 +547,12 @@ def add_main_content(doc):
# Caption demo
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
doc.add_heading("3. Anhang", level=1)
# Section 3 — Appendix
doc.add_heading("3. Appendix", level=1)
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
| Feld | Wert |
|-----------------|-------------------------------|
| Permit-ID | PER-[XXX] |
| Datum | [YYYY-MM-DD] |
| Erstellt von | [Name] |
| Field | Value |
|------------------|--------------------------------|
| Permit ID | PER-[XXX] |
| Date | [YYYY-MM-DD] |
| Author | [Name] |
---
## 1. Regelbereich
## 1. Rule
| Feld | Wert |
| Field | Value |
|-------------------|----------------------------------------------------|
| Regel-Nummer | [z.B. Rule 11.3] |
| Kategorie | [Required / Advisory] |
| Regeltext | [Exakter Text der MISRA-Regel] |
| Rule number | [e.g. Rule 11.3] |
| Category | [Required / Advisory] |
| Rule text | [Exact text of the MISRA rule] |
| Standard | [MISRA C:2012 / MISRA C:2023] |
## 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] |
| Modul / Komponente| [z.B. HAL, CAN-Treiber] |
| Kontext | [z.B. Register-Zugriffe auf Memory-Mapped I/O] |
| Code area | [e.g. src/hal/*.c — all hardware-abstraction-layer files] |
| Module / component| [e.g. HAL, CAN driver] |
| 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] |
| Fehlerpotenzial | [Beschreibung] |
| Absicherung | [z.B. Unit Tests pruefen korrekte Register-Zugriffe, Code Review Pflicht fuer HAL-Code] |
| Restrisiko | [Bewertung] |
| Safety relevance | [None / Low / Medium / High] |
| Fault potential | [Description] |
| Mitigation | [e.g. unit tests verify correct register access, code review required for HAL code] |
| Residual risk | [Assessment] |
### Geprufte Alternativen
### Alternatives considered
| Alternative | Bewertung |
| Alternative | Assessment |
|--------------------------|------------------------------------------------|
| [z.B. Generische Zugriffsfunktionen] | [z.B. Nicht praktikabel, da hunderte Register] |
| [z.B. Compiler-Erweiterung] | [z.B. Nicht portabel] |
| [e.g. generic accessor functions] | [e.g. not practical due to hundreds of registers] |
| [e.g. compiler extension] | [e.g. not portable] |
## 5. Freigabe
## 5. Approval
| Feld | Wert |
| Field | Value |
|-----------------------|-----------------------------------------------|
| Freigegeben von | [Name, Rolle] |
| Datum | [YYYY-MM-DD] |
| Nachweis | [GitLab-Issue / Wiki-Verweis / Unterschrift] |
| Approved by | [Name, role] |
| Date | [YYYY-MM-DD] |
| Evidence | [Gitea issue / wiki link / signature] |
## 6. Gueltigkeit
## 6. Validity
| Feld | Wert |
| Field | Value |
|-------------------|----------------------------------------------------|
| Gueltig ab | [YYYY-MM-DD] |
| Gueltig bis | [YYYY-MM-DD oder "bis auf Widerruf"] |
| Widerrufsbedingung | [z.B. Bei Aenderung der Zielplattform neu bewerten] |
| Valid from | [YYYY-MM-DD] |
| Valid until | [YYYY-MM-DD or "until revoked"] |
| 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
| Feld | Wert |
|-----------------|-------------------------------|
| Deviation-ID | DEV-[XXX] |
| Datum | [YYYY-MM-DD] |
| Erstellt von | [Name] |
| Field | Value |
|------------------|--------------------------------|
| Deviation ID | DEV-[XXX] |
| Date | [YYYY-MM-DD] |
| Author | [Name] |
---
## 1. Regel
## 1. Rule
| Feld | Wert |
| Field | Value |
|-------------------|----------------------------------------------------|
| Regel-Nummer | [z.B. Rule 11.3] |
| Kategorie | [Required / Advisory / Mandatory] |
| Regeltext | [Exakter Text der MISRA-Regel] |
| Rule number | [e.g. Rule 11.3] |
| Category | [Required / Advisory / Mandatory] |
| Rule text | [Exact text of the MISRA rule] |
| Standard | [MISRA C:2012 / MISRA C:2023] |
## 2. Fundstelle
## 2. Location
| Feld | Wert |
| Field | Value |
|-------------------|----------------------------------------------------|
| Datei | [z.B. src/drivers/watchdog.c] |
| Zeile(n) | [z.B. 142-145] |
| Funktion | [z.B. wdg_set_timeout()] |
| Git-Commit | [Commit-Hash] |
| GitLab-Referenz | [MR-Link oder Issue-Link] |
| File | [e.g. src/drivers/watchdog.c] |
| Line(s) | [e.g. 142-145] |
| Function | [e.g. wdg_set_timeout()] |
| Git commit | [commit hash] |
| 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:
- Hardware-Zugriff erfordert Typkonvertierung
- Compiler-spezifisches Verhalten ist definiert und getestet
- Alternative Implementierung waere unverhältnismaessig komplex
- Regel ist im Kontext nicht sicherheitsrelevant
Possible rationales:
- Hardware access requires type conversion
- Compiler-specific behaviour is defined and tested
- Alternative implementation would be disproportionately complex
- 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] |
| Fehlerpotenzial | [Beschreibung moeglicher Fehler] |
| Absicherung | [Welche Tests / Massnahmen sichern den Code ab] |
| Restrisiko | [Bewertung des verbleibenden Risikos] |
| Safety relevance | [None / Low / Medium / High] |
| Fault potential | [Description of potential faults] |
| Mitigation | [Which tests / measures cover the code] |
| 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-ID | [PER-XXX oder "entfaellt"] |
| Permit exists | [Yes / No] |
| 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] |
| Datum | [YYYY-MM-DD] |
| Nachweis | [GitLab-MR-Approval / Unterschrift] |
| Approved by | [Name, role] |
| Date | [YYYY-MM-DD] |
| 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
| Feld | Wert |
|-----------------|-------------------------------|
| NC-ID | NC-[XXX] |
| Datum | [YYYY-MM-DD] |
| Erstellt von | [Name] |
| Status | [Offen / In Bearbeitung / Geschlossen] |
| Field | Value |
|------------------|--------------------------------|
| NC ID | NC-[XXX] |
| Date | [YYYY-MM-DD] |
| Author | [Name] |
| Status | [Open / In progress / Closed] |
---
## 1. Bezug
## 1. Reference
| Feld | Wert |
| Field | Value |
|-----------------------|-----------------------------------------------|
| Art | [Prozessabweichung / Produktabweichung] |
| Betroffener Prozess | [z.B. SWE.4 Implementierung, SUP.1 QA] |
| Betroffenes Work Product | [z.B. Modul XY, Anforderung SWR-042, Testplan] |
| GitLab-Referenz | [Issue-Link / MR-Link / Wiki-Seite] |
| Gefunden bei | [Review / Audit / Test / CI-Pipeline] |
| Kind | [Process deviation / Product deviation] |
| Affected process | [e.g. SWE.4 Implementation, SUP.1 QA] |
| Affected work product | [e.g. module XY, requirement SWR-042, test plan] |
| Gitea reference | [Issue link / PR link / wiki page] |
| 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 |
|-------------|------------------------------------------------------------------|
| [ ] Critical | Sicherheitsrelevant oder vollstaendiges Fehlen eines geforderten Work Products |
| [ ] Major | Signifikante Abweichung, die die Qualitaet oder Konformitaet beeintraechtigt |
| [ ] Minor | Geringfuegige Abweichung, keine direkte Auswirkung auf Sicherheit oder Funktion |
| Severity | Definition |
|--------------|------------------------------------------------------------------|
| [ ] Critical | Safety-relevant or complete absence of a required work product |
| [ ] Major | Significant deviation that affects quality or compliance |
| [ ] 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:]
- Prozess nicht bekannt / nicht geschult
- Prozess nicht anwendbar / unrealistisch
- Versehen / menschlicher Fehler
- Tool-Fehler
- Zeitdruck / Ressourcenmangel
- Anforderung unklar
[Why did the deviation occur? Possible categories:]
- Process not known / not trained
- Process not applicable / unrealistic
- Oversight / human error
- Tool error
- Time pressure / lack of resources
- 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] |
| Verantwortlich | [Name] |
| Faelligkeit | [YYYY-MM-DD] |
| Action | [What is done to fix the deviation] |
| Responsible | [Name] |
| 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] |
| Pruefungsdatum | [YYYY-MM-DD] |
| Massnahme wirksam | [Ja / Nein] |
| Nachweis | [GitLab-Issue-Link / Commit / Review] |
| Verified by | [Name] |
| Verification date | [YYYY-MM-DD] |
| Action effective | [Yes / No] |
| Evidence | [Gitea issue link / commit / review] |
## 7. Abschluss
## 7. Closure
| Feld | Wert |
| Field | Value |
|-----------------------|-----------------------------------------------|
| Status | [Geschlossen / Erneut geoeffnet] |
| Geschlossen von | [Name] |
| Datum | [YYYY-MM-DD] |
| Status | [Closed / Reopened] |
| Closed by | [Name] |
| 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 |
|-----------------|-------------------------------|
| Projekt | [Projektname] |
| Datum | [YYYY-MM-DD] |
| Field | Value |
|-----------------|--------------------------------|
| Project | [Project name] |
| Date | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Entwurf / Freigegeben] |
| Bezug | PID Version [X.Y] |
| Status | [Draft / Released] |
---
## 1. Projektphasen und Meilensteine
## 1. Project organisation
| Phase | Start | Ende | Meilenstein |
|------------------------|-------------|-------------|--------------------------------------|
| Anforderungsanalyse | [Datum] | [Datum] | Requirements Complete |
| Architektur | [Datum] | [Datum] | Architecture Complete |
| Implementierung | [Datum] | [Datum] | Code Complete |
| Integration & Test | [Datum] | [Datum] | Integration Complete |
| Verifikation | [Datum] | [Datum] | Verification Complete |
| Release | [Datum] | [Datum] | Release |
[Describe organisation, roles, escalation path. Distinct from the role section in the PID — here you go into more detail on day-to-day collaboration.]
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 |
|--------------------------|---------------------|-------------------|---------------------------------|
| 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. Schedule
## 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 |
|--------------------------|--------------|---------------------------|---------------------|
| 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. Change management
## 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 |
|-------|----------------------------------------------|----------------------------|-------------|
| 1 | Technische Blockade | Auftraggeber (technisch) | 2 Arbeitstage |
| 2 | Terminverschiebung > 1 Woche | Projektverantwortlicher | 1 Arbeitstag |
| 3 | Scope-Aenderung oder Safety-Concern | Management Auftraggeber | sofort |
## 5. Communication
## 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`)
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)
See `RM Plan` (separate document). Top-level summary here:
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
- Risikoliste wird pro Meilenstein-Review aktualisiert
- Neue Risiken werden als GitLab Issues erfasst (Label: `risk`)
- Jedes Risiko hat: Beschreibung, Wahrscheinlichkeit, Auswirkung, Massnahme, Verantwortlicher
## 8. Closure
### Risiko-Bewertung
| Wahrscheinlichkeit / Auswirkung | Niedrig | Mittel | Hoch |
|----------------------------------|---------|---------|---------|
| Hoch | Mittel | Hoch | Kritisch|
| Mittel | Niedrig | Mittel | Hoch |
| Niedrig | Niedrig | Niedrig | Mittel |
Kritische Risiken werden sofort eskaliert (siehe Eskalationspfad Stufe 3).
The project is considered closed when:
- All success criteria from the PID are met
- A `v1.0.0` git tag is set
- The release package has been delivered to the client and accepted
---
*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 |
|-----------------|-------------------------------|
| Projekt | [Projektname] |
| Datum | [YYYY-MM-DD] |
| Field | Value |
|-----------------|--------------------------------|
| Project | [Project name] |
| Date | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Entwurf / Freigegeben] |
| ASIL | [QM / A / B / C / D] |
| Status | [Draft / Released] |
---
## 1. QA-Aktivitaeten pro Phase
## 1. Quality goals
| Phase | QA-Aktivitaet | Verantwortlich |
|------------------------|--------------------------------------------------------|----------------|
| Anforderungsanalyse | Review der Anforderungen (Vollstaendigkeit, Konsistenz, Testbarkeit) | QA / Reviewer |
| Architektur | Architektur-Review (Modularitaet, Safety-Konzept) | QA / Reviewer |
| Implementierung | Code-Review (MR-Approval), MISRA-Pruefung (CI) | Reviewer / CI |
| Integration & Test | Test-Review, Coverage-Pruefung, Traceability-Check | QA / CI |
| Verifikation | Gesamtpruefung: alle Kriterien erfuellt? | QA |
| Release | Release-Audit: alle Work Products vollstaendig? | QA |
- [Goal 1, e.g. "100% MISRA Required compliance"]
- [Goal 2, e.g. "Statement coverage ≥ 90% for ASIL-D"]
- [Goal 3, e.g. "Zero critical static-analysis findings on release"]
## 2. Zu pruefende Work Products
## 2. Quality measures
| Work Product | Review-Art | Pruefkriterien |
|----------------------------------|------------------|---------------------------------------------|
| PID | Peer Review | Vollstaendig, konsistent mit Vertrag |
| PM-Plan | Peer Review | Realistisch, Risiken adressiert |
| Software Requirements | Technical Review | Eindeutig, testbar, ASIL zugeordnet |
| Architektur-Dokumentation | Technical Review | Modular, Schnittstellen definiert, Safety-Konzept |
| Quellcode | Peer Review (MR) | MISRA-konform, getestet, lesbar |
| Unit Tests | Peer Review | Abdeckung, Randfaelle, Traceability |
| Testberichte | Peer Review | Pass/Fail dokumentiert, Coverage erreicht |
| MISRA Compliance Report | Peer Review | Abweichungen dokumentiert und genehmigt |
| Traceability-Matrix | QA-Pruefung | Keine Luecken, bidirektional |
| Measure | Tool / Method | Frequency | Owner |
|--------------------------|------------------------------|------------------|----------|
| Traceability check | `doorstop check` | every push | dev |
| MISRA check | Cppcheck + MISRA addon | every push | dev |
| Static analysis | Cppcheck, clang-tidy | every push | dev |
| Unit tests | CppUTest | every push | dev |
| Coverage | gcov / lcov | every push | dev |
| Peer review | Gitea PRs | every change | reviewer |
| Architecture review | Technical review | on changes | TL |
## 3. Review-Arten
## 3. Review obligations
| Review-Art | Teilnehmer | Formalitaet | Wann |
|---------------------|-------------------------------|-------------|----------------------------------|
| Peer Review | 1 Reviewer | Niedrig | Jeder MR, Dokument-Aenderungen |
| Technical Review | 2+ Reviewer, inkl. Tech Lead | Mittel | Architektur, Safety-Code, Plaene |
| Inspektion | Moderator + 2+ Reviewer | Hoch | Safety-kritische Artefakte (ASIL C/D) |
| Artefact | Review type | Min. approvers |
|--------------------------------|---------------------|-----------------|
| Requirements | Technical review | 1 |
| Architecture element | Technical review | 2 |
| 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 |
|----------------------|--------------------------------------------------------|
| 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 |
## 5. Audit preparation
### Exit-Kriterien (Abschluss einer Phase)
Audit readiness is maintained continuously:
| Phase | Exit-Kriterien |
|----------------------|--------------------------------------------------------|
| Anforderungen | Alle Requirements reviewed, ASIL zugeordnet, testbar |
| Architektur | Architektur reviewed, Schnittstellen definiert |
| Implementierung | MISRA-konform, Unit Tests gruen, Coverage-Ziel erreicht |
| Integration & Test | Integrationstests gruen, keine offenen Critical Findings |
| Verifikation | Traceability vollstaendig, alle Findings geschlossen oder bewertet |
| Release | Alle Work Products vollstaendig, QA-Freigabe erteilt |
- Git history is the audit trail (no direct push to `main`)
- Documents are versioned in the repo
- Traceability matrices are generated on every CI run
- MISRA records and deviation permits are stored under `misra/`
- Test and coverage reports are stored as CI artefacts
## 5. Non-Conformity-Prozess
## 6. Improvement measures
1. Abweichung wird erkannt (Review, Audit, Test)
2. Non-Conformity Report erstellen (GitLab Issue, Label: `non-conformity`)
3. Schweregrad zuweisen: Critical / Major / Minor
4. Ursachenanalyse durchfuehren
5. Korrekturmassnahme definieren und umsetzen
6. Wirksamkeitspruefung nach Umsetzung
7. Issue schliessen mit Verweis auf Korrekturnachweis
**Eskalation:** Critical Non-Conformities werden sofort an den Auftraggeber gemeldet.
## 6. Reporting an Management
| Report | Haeufigkeit | Inhalt |
|---------------------------|------------------|-------------------------------------------|
| QA-Status-Report | Pro Meilenstein | Offene Findings, NC-Status, Coverage-Stand |
| Meilenstein-Bewertung | Pro Phase-Ende | Entry/Exit-Kriterien geprueft |
| Release-Bewertung | Vor Release | Gesamtbewertung aller QA-Kriterien |
## 7. QA-Metriken
| Metrik | Ziel | Messung |
|---------------------------------|-------------------------|----------------------------------|
| Requirement Coverage | 100% | Anforderungen mit verlinktem Test |
| Code Coverage (Statement) | >= [X]% | gcov/lcov in CI |
| Code Coverage (Branch) | >= [X]% | gcov/lcov in CI |
| MC/DC Coverage (falls ASIL C/D) | >= [X]% | MCDC-Star / kommerziell |
| MISRA Violations | 0 (oder alle genehmigt)| Cppcheck MISRA-Addon in CI |
| Offene Findings (Critical) | 0 vor Release | GitLab Issues |
| Offene Non-Conformities | 0 Critical/Major | GitLab Issues |
| Review-Abdeckung | 100% MRs reviewed | GitLab MR-Approvals |
- Lessons-learned note at each sprint closure under `docs/lessons-learned/`
- Quarterly retrospective with the team
- Updates to this plan are versioned and reviewed
---
*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 |
|-------------------------|-----------------------------------------|
| Datum | [YYYY-MM-DD] |
| Review-Art | [Peer Review / Technical Review / Inspektion] |
| Field | Value |
|-------------------------|------------------------------------------|
| Date | [YYYY-MM-DD] |
| Review type | [Peer review / Technical review / Inspection] |
| Moderator | [Name] |
| Protokollfuehrer | [Name] |
| Minute keeper | [Name] |
---
## 1. Teilnehmer
## 1. Participants
| Name | Rolle | Anwesend |
| Name | Role | Present |
|---------------------|--------------------------|----------|
| [Name] | Moderator | Ja / Nein |
| [Name] | Autor | Ja / Nein |
| [Name] | Reviewer | Ja / Nein |
| [Name] | Reviewer | Ja / Nein |
| [Name] | Moderator | Yes / No |
| [Name] | Author | Yes / No |
| [Name] | Reviewer | Yes / No |
| [Name] | Reviewer | Yes / No |
## 2. Reviewtes Work Product
## 2. Reviewed work product
| Feld | Wert |
|-------------------|-------------------------------------------|
| Work Product | [z.B. Architektur-Dokumentation, Modul XY, Anforderungen SWR-040 bis SWR-060] |
| Version / Commit | [Version oder Git-Commit-Hash] |
| GitLab-Referenz | [MR-Link / Wiki-Seite / Issue-Nummern] |
| Field | Value |
|-------------------|--------------------------------------------|
| Work product | [e.g. architecture documentation, module XY, requirements SWR-040 to SWR-060] |
| Version / commit | [Version or git commit hash] |
| 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] | Ja / Nein |
| [Name] | [X] | Yes / No |
| [Name] | [X] | Yes / No |
## 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-02 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen |
| F-03 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen |
| F-01 | [Finding description] | Critical / Major / Minor | [Name] | [Date] | Open |
| F-02 | [Finding description] | Critical / Major / Minor | [Name] | [Date] | Open |
| F-03 | [Finding description] | Critical / Major / Minor | [Name] | [Date] | Open |
### Schweregrade
### Severities
- **Critical:** Sicherheitsrelevant oder funktional falsch. Muss vor Freigabe behoben werden.
- **Major:** Signifikanter Fehler oder Luecke. Muss behoben werden, kann aber terminiert werden.
- **Minor:** Verbesserungsvorschlag, Stil, Lesbarkeit. Behebung empfohlen.
- **Critical:** Safety-relevant or functionally wrong. Must be fixed before release.
- **Major:** Significant defect or gap. Must be fixed but may be scheduled.
- **Minor:** Improvement suggestion, style, readability. Fix recommended.
## 5. Entscheidung
## 5. Decision
| Entscheidung |
| Decision |
|-----------------------------------------------------------|
| [ ] Freigegeben |
| [ ] Bedingt freigegeben (nach Behebung der Critical/Major Findings) |
| [ ] Nicht freigegeben (erneutes Review erforderlich) |
| [ ] Approved |
| [ ] Conditionally approved (after fixing Critical/Major findings) |
| [ ] Not approved (re-review required) |
**Bedingungen fuer bedingte Freigabe:**
[Falls zutreffend: welche Findings muessen behoben werden, wer prueft die Behebung]
**Conditions for conditional approval:**
[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] |
| Reviewer 1 | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] |
| Reviewer 2 | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] |
| Autor | [Name] | [Datum] | |
| Moderator | [Name] | [Date] | [Signature / Gitea PR approval] |
| Reviewer 1 | [Name] | [Date] | [Signature / Gitea PR approval] |
| Reviewer 2 | [Name] | [Date] | [Signature / Gitea PR approval] |
| 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]
---
# SA-XXX: [Element-Name]
# SA-XXX: [Element name]
> **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 |
|----------|-------------------------------|
| Projekt | [Projektname] |
| Datum | [YYYY-MM-DD] |
| Field | Value |
|----------|--------------------------------|
| Project | [Project name] |
| Date | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Entwurf / Freigegeben] |
| Status | [Draft / Released] |
| 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
@startuml
!define COMPONENT(x) component "x" as x
COMPONENT([Element])
[Element] --> [Nachbarsystem A] : Schnittstelle X
[Nachbarsystem B] --> [Element] : Schnittstelle Y
[Element] --> [Neighbour A] : interface X
[Neighbour B] --> [Element] : interface Y
@enduml
```
## 3. Allokation
## 3. Allocation
| Anforderung | Allokation auf | Bemerkung |
|---------------|----------------|---------------------------|
| SYS-XXX | dieses Element | [vollstaendig / teilweise] |
| SYS-YYY | dieses Element | [Begruendung] |
| Requirement | Allocated to | Notes |
|---------------|------------------|------------------------------|
| SYS-XXX | this element | [full / partial] |
| 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 |
|---------------|---------------|----------------------|--------------------------|
| [Name] | in / out / io | [CAN / SPI / GPIO / ...] | [Protokoll-Verweis] |
| Interface | Direction | Type | Notes |
|---------------|---------------|-----------------------|-------------------------|
| [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
@startuml
actor Nutzer
Nutzer -> [Element]: Anforderung
[Element] -> [Nachbar]: weiterleiten
[Nachbar] --> [Element]: Antwort
[Element] --> Nutzer: Ergebnis
actor User
User -> [Element]: request
[Element] -> [Neighbour]: forward
[Neighbour] --> [Element]: response
[Element] --> User: result
@enduml
```
## 7. Nichtfunktionale Eigenschaften
## 7. Non-functional properties
| Aspekt | Anforderung / Zielwert |
|---------------------|-----------------------------|
| Worst-Case Timing | [z.B. < 10 ms Reaktionszeit]|
| Speicherbedarf | [z.B. < 64 KB Flash] |
| Stromaufnahme | [z.B. < 200 mA bei 12 V] |
| Umgebungsbedingungen | [Temperatur, EMV] |
| Sicherheitsziel | [Verweis auf SG-XXX, falls vorhanden] |
| Aspect | Requirement / target value |
|---------------------|------------------------------|
| Worst-case timing | [e.g. < 10 ms reaction time] |
| Memory footprint | [e.g. < 64 KB flash] |
| Power draw | [e.g. < 200 mA at 12 V] |
| Environment | [Temperature, EMC] |
| Safety goal | [Reference to SG-XXX, if any] |
## 8. Designentscheidungen
## 8. Design decisions
| Entscheidung | Alternativen | Begruendung |
|--------------|--------------|-------------|
| [Was] | [Was sonst noch erwogen wurde] | [Warum diese Wahl] |
| Decision | Alternatives | Rationale |
|--------------|--------------|-----------|
| [What] | [What else was considered] | [Why this choice] |
## 9. Verifikation
## 9. Verification
| Anforderung | Verifikations-Methode | Test-ID |
|-------------|------------------------|-------------------|
| SYS-XXX | [Review / Test / Analyse] | TST-SYS-XXX |
| Requirement | Verification method | Test ID |
|-------------|---------------------------|-------------------|
| 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]
---
# SWA-XXX: [Komponenten-Name]
# SWA-XXX: [Component name]
> **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 |
|----------|-------------------------------|
| Projekt | [Projektname] |
| Datum | [YYYY-MM-DD] |
| Field | Value |
|----------|--------------------------------|
| Project | [Project name] |
| Date | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Entwurf / Freigegeben] |
| Status | [Draft / Released] |
| ASIL | [QM / A / B / C / D] |
| Autor | [Name] |
| Parent | [SA-XXX, falls vorhanden] |
| Author | [Name] |
| 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
@startuml
package "[Komponenten-Name]" {
[Submodul A]
[Submodul B]
package "[Component name]" {
[Submodule A]
[Submodule B]
}
[Submodul A] --> [Submodul B]
[Komponenten-Name] ..> [Nachbar-Komponente] : nutzt
[Submodule A] --> [Submodule B]
[Component name] ..> [Neighbour component] : uses
@enduml
```
### 2.2 Eingebettete / verwendete Komponenten
### 2.2 Embedded / used components
| Komponente | Verweis | Verwendung |
|---------------|----------|--------------------------|
| [Name] | SWA-YYY | [wofuer] |
| Component | Reference | Use |
|---------------|-----------|---------------------------|
| [Name] | SWA-YYY | [for what] |
## 3. Schnittstellen
## 3. Interfaces
### 3.1 Bereitgestellte Schnittstelle (Provided)
### 3.1 Provided interface
```c
/**
* @brief [Kurzbeschreibung]
* @param [name] [Bedeutung, Wertebereich]
* @return [Status / Wert]
* @pre [Vorbedingung]
* @post [Nachbedingung]
* @brief [Short description]
* @param [name] [Meaning, value range]
* @return [Status / value]
* @pre [Precondition]
* @post [Postcondition]
*/
Status component_init(const Config* cfg);
```
| Funktion | Zweck | Pre-Condition | Post-Condition |
|------------------|----------------------|-----------------------|------------------------|
| component_init | Initialisierung | cfg != NULL | Komponente betriebsbereit |
| component_send | Daten senden | initialisiert | Daten in TX-Buffer |
| Function | Purpose | Pre-condition | Post-condition |
|------------------|--------------------|-----------------------|------------------------|
| component_init | Initialisation | cfg != NULL | Component ready |
| component_send | Send data | initialised | Data in TX buffer |
### 3.2 Benoetigte Schnittstelle (Required)
### 3.2 Required interface
| Schnittstelle | Bereitgestellt von | Zweck |
|-------------------|--------------------|-----------------------|
| ILogger::log() | LoggerComponent | Diagnose / Tracing |
| IClock::now() | ClockComponent | Zeitstempel |
| Interface | Provided by | Purpose |
|-------------------|--------------------|---------------------|
| ILogger::log() | LoggerComponent | Diagnostics / tracing |
| IClock::now() | ClockComponent | Timestamps |
## 4. Dynamisches Verhalten
## 4. Dynamic behaviour
### 4.1 Sequenzdiagramm (kritischer Ablauf)
### 4.1 Sequence diagram (critical flow)
```plantuml
@startuml
participant App
participant "[Komponente]" as C
participant "[Component]" as C
participant HW
App -> C: init(cfg)
C -> HW: configure
@@ -90,7 +90,7 @@ C --> App: STATUS_OK
@enduml
```
### 4.2 Zustandsdiagramm (falls zutreffend)
### 4.2 State diagram (if applicable)
```plantuml
@startuml
@@ -103,46 +103,45 @@ Error --> Ready : reset()
@enduml
```
## 5. Ressourcen-Bedarf
## 5. Resource demand
| Ressource | Worst-Case | Methode der Bestimmung |
|-------------------|--------------|-----------------------------|
| Stack | [z.B. 256 B] | [Messung / statische Analyse] |
| Heap | [z.B. 0 B] | [keine Heap-Nutzung] |
| Flash | [z.B. 4 KB] | [Map-File des Linkers] |
| RAM (statisch) | [z.B. 128 B] | [Map-File des Linkers] |
| CPU-Last | [z.B. < 1 %] | [Messung auf Zielsystem] |
| Worst-Case Timing | [z.B. 200 us / Aufruf init()] | [Messung HiL] |
| Resource | Worst case | Method of determination |
|-------------------|--------------|------------------------------|
| Stack | [e.g. 256 B] | [Measurement / static analysis] |
| Heap | [e.g. 0 B] | [No heap use] |
| Flash | [e.g. 4 KB] | [Linker map file] |
| RAM (static) | [e.g. 128 B] | [Linker map file] |
| CPU load | [e.g. < 1%] | [Measurement on target] |
| 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 |
| HW-Timeout | Timer | Retry, dann STATUS_TIMEOUT |
| Buffer voll | Check vor Schreiben | STATUS_NOSPACE |
| Invalid config | Parameter check | Status STATUS_EINVAL |
| HW timeout | Timer | Retry, then STATUS_TIMEOUT |
| Buffer full | Pre-write check | STATUS_NOSPACE |
## 7. Designentscheidungen
## 7. Design decisions
| Entscheidung | Alternative(n) | Begruendung |
|------------------------|------------------|--------------------------|
| [z.B. statische Allokation] | [Heap] | [deterministisch, MISRA] |
| [Lock-Strategie] | [Mutex / lock-free] | [Begruendung] |
| Decision | Alternative(s) | Rationale |
|------------------------|------------------|----------------------------|
| [e.g. static allocation] | [Heap] | [Deterministic, MISRA] |
| [Locking strategy] | [Mutex / lock-free] | [Rationale] |
## 8. Mapping auf Anforderungen
## 8. Mapping to requirements
| Anforderung | Wie abgedeckt | Verifikations-Test |
|---------------|----------------------------------------------|----------------------------|
| SWE-XXX | [welcher Teil dieser Komponente erfuellt es] | TST-UNIT-XXX, TST-INT-YYY |
| Requirement | How covered | Verification test |
|---------------|-----------------------------------------------|----------------------------|
| SWE-XXX | [which part of this component fulfils it] | TST-UNIT-XXX, TST-INT-YYY |
| SWE-YYY | [...] | TST-UNIT-YYY |
Jede in den `links` referenzierte SWE-Anforderung muss in dieser Tabelle einen Eintrag haben.
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.
Fuer ASIL-A/B und QM ist Code + Header-Kommentare ausreichend.
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.
---
*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 |
|-----------------|-------------------------------|
| Projekt | [Projektname] |
| Datum | [YYYY-MM-DD] |
| Field | Value |
|------------------|--------------------------------|
| Project | [Project name] |
| Date | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Entwurf / Freigegeben] |
| Status | [Draft / Released] |
| 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):
- Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung
- Rechte Seite: Unit Test → Integrations-Test → System-Test
- Iterationen innerhalb der Phasen moeglich
The base structure follows the V-model (ISO 26262 Part 6):
- Left side: requirements → architecture → detailed design → implementation
- Right side: unit test → integration test → system test
- 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] |
| Coding Standard | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023] |
| Projekt-Guidelines | [Verweis auf Coding-Guidelines im Wiki] |
| Namenskonvention | [z.B. snake_case fuer Funktionen, UPPER_CASE fuer Makros] |
| Language | [C (C99/C11) / C++ (C++14/17) / Rust] |
| Coding standard | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023] |
| Project guidelines | [Reference to coding guidelines in the wiki] |
| Naming convention | [e.g. snake_case for functions, UPPER_CASE for macros] |
### MISRA-Handhabung
### MISRA handling
- Alle Required- und Mandatory-Regeln werden eingehalten
- Advisory-Regeln: Liste der angewendeten Regeln im Wiki dokumentiert
- Abweichungen werden per MISRA Deviation Record dokumentiert
- Projektweite Abweichungen per MISRA Deviation Permit genehmigt
- MISRA-Pruefung laeuft automatisch in der CI-Pipeline
- All Required and Mandatory rules are observed
- Advisory rules: list of applied rules documented in the wiki
- Deviations are documented per MISRA deviation record
- Project-wide deviations are approved via MISRA deviation permit
- 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] |
| Zielplattform | [z.B. ARM Cortex-R5, Cortex-M4] |
| Host-Plattform | [Linux x86_64 / macOS ARM64] |
| CI-Runner | [GitLab Runner, Docker Image: ...] |
| Target platform | [e.g. ARM Cortex-R5, Cortex-M4] |
| Host platform | [Linux x86_64 / macOS ARM64] |
| 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
develop — Aktueller Entwicklungsstand
feature/SWR-XXX — Feature-Branch pro Anforderung
bugfix/BUG-XXX — Bugfix-Branch
release/vX.Y — Release-Vorbereitung
hotfix/vX.Y.Z — Kritische Fixes nach Release
main — stable, released state
develop — current development state
feature/SWE-XXX — feature branch per requirement
bugfix/BUG-XXX — bug-fix branch
release/vX.Y — release preparation
hotfix/vX.Y.Z — critical fixes after release
```
- Feature-Branches von `develop` abzweigen
- Merge nach `develop` nur per MR mit Approval
- `main` und `release/*` sind geschuetzt (kein direkter Push)
- Branch-Name enthaelt Issue-Nummer
- Feature branches are taken off `develop`
- Merge to `develop` only via PR with approval
- `main` and `release/*` are protected (no direct push)
- 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 |
|-----------------------------|-------------------|--------------------|
| Quellcode (MR) | Peer Review | 1 |
| Safety-relevanter Code | Technical Review | 2 |
| Architektur-Dokument | Technical Review | 2 |
| Anforderungen | Technical Review | 1 |
| Testfaelle | Peer Review | 1 |
| Artefact | Review type | Min. approvals |
|-----------------------------|--------------------|-----------------|
| Source code (PR) | Peer review | 1 |
| Safety-relevant code | Technical review | 2 |
| Architecture document | Technical review | 2 |
| Requirements | Technical 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
Ein Feature / eine Anforderung gilt als "Done" wenn:
A feature / requirement is "Done" when:
- [ ] Code ist implementiert und kompiliert fehlerfrei
- [ ] MISRA-Check in CI ist gruen (keine neuen Violations)
- [ ] Static Analysis (Cppcheck, clang-tidy) hat keine neuen Findings
- [ ] Unit Tests sind geschrieben und gruen
- [ ] Coverage-Ziel ist erreicht (siehe Abschnitt 8)
- [ ] MR ist reviewed und approved
- [ ] Anforderung ist mit Test verlinkt (Traceability)
- [ ] Dokumentation ist aktualisiert (falls betroffen)
- [ ] Code is implemented and compiles without errors
- [ ] MISRA check in CI is green (no new violations)
- [ ] Static analysis (Cppcheck, clang-tidy) has no new findings
- [ ] Unit tests are written and green
- [ ] Coverage target is reached (see section 8)
- [ ] PR is reviewed and approved
- [ ] Requirement is linked to a test (traceability)
- [ ] Documentation is updated (if affected)
## 7. Integration und Test-Strategie
## 7. Integration and test strategy
| Teststufe | Verantwortlich | Umgebung | Automatisierung |
|---------------------|----------------|----------------|-----------------|
| Unit Test | Entwickler | Host (x86) | CI-Pipeline |
| Integrations-Test | Entwickler | Host / SiL | CI / manuell |
| System-Test | Test / QA | SiL / HiL | teilweise |
| Abnahme-Test | Auftraggeber | HiL / Fahrzeug | manuell |
| Test level | Owner | Environment | Automation |
|--------------------|----------------|---------------|------------------|
| Unit test | Developer | host (x86) | CI pipeline |
| Integration test | Developer | host / SiL | CI / manual |
| System test | Test / QA | SiL / HiL | partial |
| Acceptance test | Client | HiL / vehicle | manual |
- Unit Tests laufen auf Host-Plattform (Cross-Compilation fuer Tests auf x86)
- Integrationstests pruefen Zusammenspiel der Module
- System-Tests pruefen gegen System-Anforderungen
- HiL-Tests werden vom Auftraggeber bereitgestellt oder gemeinsam definiert
- Unit tests run on the host platform (cross-compilation for x86 testing)
- Integration tests verify module interaction
- System tests verify against system requirements
- 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 | — | — |
| A | >= 80% | empfohlen | — |
| B | >= 80% | >= 80% | — |
| C | >= 90% | >= 80% | empfohlen|
| D | >= 90% | >= 90% | >= 80% |
| QM | ≥ 80% recommended | — | — |
| A | ≥ 80% | recommended | — |
| B | ≥ 80% | ≥ 80% | — |
| C | ≥ 90% | ≥ 80% | recommended |
| D | ≥ 90% | ≥ 90% | ≥ 80% |
Konkrete Zielwerte fuer dieses Projekt:
Concrete target values for this project:
| Metrik | Zielwert |
| Metric | Target |
|---------------------|------------|
| Statement Coverage | >= [X]% |
| Branch Coverage | >= [X]% |
| MC/DC | >= [X]% (falls anwendbar) |
| Statement coverage | ≥ [X]% |
| Branch coverage | ≥ [X]% |
| 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 |
|-----------------|-------------------------------|
| Projekt | [Projektname] |
| Datum | [YYYY-MM-DD] |
| Field | Value |
|-----------------|--------------------------------|
| Project | [Project name] |
| Date | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Entwurf / Freigegeben] |
| ASIL | [QM / A / B / C / D] |
| Bezug | SWE-Plan Version [X.Y] |
| Status | [Draft / Released] |
---
## 1. Testziele
## 1. Test strategy
- Nachweis, dass die Software die spezifizierten Anforderungen erfuellt
- Nachweis der strukturellen Code-Abdeckung gemaess ASIL-Vorgaben
- Nachweis der Robustheit gegenueber Fehlbedienung und Grenzwerten
- Identifikation von Defekten vor der Integration / Auslieferung
[Describe the approach: e.g. test-first, requirement-based, risk-based.]
## 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 |
|---------------------|---------------------------------------------|------------------|-----------------|
| 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 |
## 2. Test levels
### 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]
- Laufen auf Host-Plattform (x86)
- Jede Anforderung hat mindestens einen zugehoerigen Testfall
- Negative Tests und Grenzwerte sind Pflicht
## 3. Test management
### 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
- Laufen auf Host oder SiL-Umgebung
- Kommunikationsschnittstellen (CAN, SPI, UART) werden per Mock oder Simulator getestet
## 4. Test selection per component
### 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
- Laufen auf SiL oder HiL
- Testfaelle werden aus System-Requirements abgeleitet
## 5. Entry and exit criteria
## 3. Coverage-Ziele
**Entry to test execution:**
- Code compiles
- Doorstop check is green
- Static analysis has no critical findings
| Metrik | Zielwert | Messung |
|---------------------|----------------|------------------|
| Statement Coverage | >= [X]% | gcov/lcov |
| Branch Coverage | >= [X]% | gcov/lcov |
| MC/DC | >= [X]% (falls anwendbar) | MCDC-Star / kommerziell |
**Exit:**
- All tests green
- Coverage target reached
- Test report archived
Referenz: ISO 26262 Part 6, Table 9.
## 6. Defect handling
| ASIL | Statement | Branch | MC/DC |
|------|-----------|---------|--------------|
| QM | empfohlen | — | — |
| A | Pflicht | empfohlen | — |
| B | Pflicht | Pflicht | — |
| C | Pflicht | Pflicht | empfohlen |
| D | Pflicht | Pflicht | Pflicht |
- Test failure = blocking issue
- Issue raised via Gitea Issues, referenced in the PR
- Severity classification per QA Plan section 4
## 4. Testumgebung
## 7. Reporting
| Komponente | Beschreibung |
|---------------------|----------------------------------------------------|
| Host-Plattform | [Linux x86_64 / macOS ARM64] |
| Cross-Compiler | [GCC ARM X.Y] |
| Test-Framework | [CppUTest / Google Test / Unity] |
| SiL-Framework | [Python + pytest, Kommunikation: UART/CAN/TCP] |
| HiL-System | [dSPACE Scalexio / vom Kunden gestellt / entfaellt] |
| CI-Runner | [GitLab Runner, Docker Image: ...] |
## 5. Testdaten
- Testdaten werden im Repository unter `tests/data/` versioniert
- Grenzwerte aus Anforderungen ableiten
- Ungueltige Eingaben explizit testen
- Testdaten fuer Regressionen aus Bug-Reports ableiten
## 6. Pass/Fail-Kriterien
### Einzelner Testfall
- **Pass:** Erwartetes Ergebnis stimmt mit tatsaechlichem ueberein
- **Fail:** Abweichung vom erwarteten Ergebnis
### Teststufe gesamt
| Kriterium | Bedingung fuer Pass |
|----------------------------------------|----------------------------------------|
| Alle Testfaelle ausgefuehrt | Ja |
| Alle Testfaelle bestanden | Ja (oder Fails bewertet und genehmigt) |
| Coverage-Ziel erreicht | Ja |
| Keine offenen Critical Findings | Ja |
| Traceability vollstaendig | Jede Anforderung hat mindestens einen Test |
Fehlgeschlagene Tests, die nicht behoben werden, muessen per Non-Conformity oder Change Request dokumentiert und bewertet werden.
## 7. Traceability
Jeder Testfall muss auf mindestens eine Anforderung rueckfuehrbar sein.
```
Anforderung (GitLab Issue, Label: req::software)
→ Testfall (GitLab Issue, Label: test::unit / test::integration / test::system)
→ Testergebnis (CI-Artefakt / JUnit-XML)
```
Umsetzung:
- Testfall-Issue verlinkt auf Anforderungs-Issue ("relates to" oder "verified by")
- Im Testcode: Kommentar mit Anforderungs-ID (`// Verifies: SWR-042`)
- Traceability-Report wird per Skript aus GitLab API generiert
Test reports are generated automatically:
- Console output of the test framework (TAP / JUnit XML)
- Coverage HTML from lcov
- Both as CI artefacts under `tests/results/`
---
*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:
- **Vorwaerts:** Anforderung → wurde sie implementiert und getestet?
- **Rueckwaerts:** Testfall → welche Anforderung verifiziert er?
Each level must be traceable in both directions:
- **Forward:** requirement → has it been implemented and tested?
- **Backward:** test case → which requirement does it verify?
## Tabellenstruktur
## Table structure
| Sys-Req | SW-Req | ASIL | Arch-Element | Implementierung | Testfall | Test-Ergebnis | Status |
|---------|---------|------|--------------|----------------------|----------|---------------|--------------|
| SYR-001 | SWR-010 | B | MOD-Timer | MR !23, timer.c | TC-010 | Pass (v1.2) | Vollstaendig |
| SYR-001 | SWR-011 | B | MOD-Timer | MR !23, timer.c | TC-011 | Pass (v1.2) | Vollstaendig |
| SYR-002 | SWR-020 | A | MOD-CAN | MR !31, can_driver.c | TC-020 | Pass (v1.2) | Vollstaendig |
| SYR-003 | SWR-030 | B | MOD-Watchdog | — | — | — | Offen |
| — | SWR-040 | QM | MOD-Diag | MR !35, diag.c | TC-040 | Fail (v1.1) | Finding offen|
| Sys-Req | SW-Req | ASIL | Arch element | Implementation | Test case | Test result | Status |
|---------|---------|------|--------------|----------------------|-----------|---------------|--------------|
| SYR-001 | SWR-010 | B | MOD-Timer | PR !23, timer.c | TC-010 | Pass (v1.2) | Complete |
| SYR-001 | SWR-011 | B | MOD-Timer | PR !23, timer.c | TC-011 | Pass (v1.2) | Complete |
| 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 | — | — | — | Open |
| — | 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`) |
| SW-Req | Software-Anforderungs-ID (GitLab Issue mit Label `req::software`) |
| ASIL | Zugewiesener ASIL-Level |
| Arch-Element | Architektur-Modul oder -Komponente |
| Implementierung | Merge Request und/oder Datei |
| Testfall | Testfall-ID (GitLab Issue mit Label `test::*`) |
| Test-Ergebnis | Pass/Fail mit Version/Datum |
| Status | Vollstaendig / Offen / Finding offen |
| Sys-Req | System requirement ID (Gitea issue with label `req::system`) |
| SW-Req | Software requirement ID (Gitea issue with label `req::software`) |
| ASIL | Assigned ASIL level |
| Arch element | Architecture module or component |
| Implementation | Pull request and/or file |
| Test case | Test case ID (Gitea issue with label `test::*`) |
| Test result | Pass/Fail with version/date |
| 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
- **Anforderung ohne Implementierung:** Zeile ohne MR → nicht implementiert
- **Test ohne Anforderung:** Testfall der keiner Anforderung zugeordnet ist → ueberpruefen
- **Fail ohne Finding:** Fehlgeschlagener Test ohne dokumentiertes Finding → nacharbeiten
- **Requirement without test:** row without test-case entry → test missing
- **Requirement without implementation:** row without PR → not implemented
- **Test without requirement:** test case not assigned to any requirement → verify
- **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
2. Folgt Issue-Links zu Architektur-Issues, MRs und Test-Issues
3. Liest CI-Pipeline-Ergebnisse (JUnit-XML) fuer Testergebnisse
4. Erzeugt die Matrix als Markdown-Tabelle oder CSV
1. A Python script reads all issues with `req::*` labels via the Gitea API
2. It follows issue links to architecture issues, PRs, and test issues
3. It reads CI-pipeline results (JUnit XML) for test outcomes
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:**
- Markdown (fuer Wiki / Dokumentation)
- CSV (fuer Import in Kundensysteme)
- HTML (fuer Reporting)
**Output formats:**
- Markdown (for wiki / documentation)
- CSV (for import into customer systems)
- 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 -->
<!-- Verwendung: Platzhalter {{ ... }} ersetzen, dann mit pandoc exportieren -->
<!-- slohmaier Engineering – Quotation template -->
<!-- Use: replace {{ ... }} placeholders, then export with pandoc -->
<!-- Export: pandoc angebot.md -o angebot.html --standalone -->
<!-- Beispiel: angebot-beispiel.html -->
<!-- Example: angebot-beispiel.html -->
<div class="logo">
<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
**Projekt:** {{ projektname }}
**Auftraggeber:** {{ auftraggeber }}
**Project:** {{ project name }}
**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 |
| 2 | ... | Soll |
| 3 | ... | Kann |
| 1 | ... | Must |
| 2 | ... | Should |
| 3 | ... | Could |
### 4. Vorgehen
### 4. Approach
1. {{ Schritt 1 }}
2. {{ Schritt 2 }}
3. {{ Schritt 3 }}
1. {{ Step 1 }}
2. {{ Step 2 }}
3. {{ Step 3 }}
Geschaetzte Dauer: **{{ Dauer }}**
Estimated duration: **{{ duration }}**
### 5. Offene Punkte
### 5. Open items
- [ ] {{ Voraussetzung 1 }}
- [ ] {{ Voraussetzung 2 }}
- [ ] {{ Precondition 1 }}
- [ ] {{ 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
Zahlungsziel: 14 Tage nach Rechnungsstellung
Gueltig bis: {{ datum + 14 Tage }}
Day rate: on request
Payment terms: 14 days from invoice date
Valid until: {{ date + 14 days }}
---