diff --git a/README.md b/README.md index 51108c2..bac9222 100644 --- a/README.md +++ b/README.md @@ -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. diff --git a/tools/build_word_template.py b/tools/build_word_template.py index 726c620..8771a06 100644 --- a/tools/build_word_template.py +++ b/tools/build_word_template.py @@ -223,7 +223,7 @@ def setup_page(doc): section.footer_distance = Cm(1.25) -def build_header_footer(doc, doc_id_placeholder="", classification="VERTRAULICH"): +def build_header_footer(doc, doc_id_placeholder="", 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="", 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("") + r1 = header_para.add_run("") r1.font.size = Pt(9) r1.font.color.rgb = RGBColor(0x59, 0x59, 0x59) header_para.add_run("\t") - r2 = header_para.add_run("") + r2 = header_para.add_run("") 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="", 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("") + title_p.add_run("") # Subtitle sub_p = doc.add_paragraph(style="Subtitle") sub_p.alignment = WD_ALIGN_PARAGRAPH.CENTER - sub_p.add_run("") + sub_p.add_run("") 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", ""), - ("Dokument-ID", ""), + ("Project", ""), + ("Document 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", ""), - ("1.0", "YYYY-MM-DD", "Erstfreigabe", ""), + ("0.1", "YYYY-MM-DD", "Initial draft", ""), + ("1.0", "YYYY-MM-DD", "First release", ""), ] 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( - "" + "" ) - doc.add_heading("1.2 Geltungsbereich", level=2) - doc.add_paragraph("") - doc.add_heading("1.3 Definitionen", level=2) + doc.add_heading("1.2 Scope", level=2) + doc.add_paragraph("") + doc.add_heading("1.3 Definitions", level=2) doc.add_paragraph( - "" + "" ) - 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( - "" + "" ) # 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( - "" + "" ) diff --git a/vorlagen-word/MISRA-Deviation-Permit-vorlage.docx b/vorlagen-word/MISRA-Deviation-Permit-vorlage.docx index f6612ff..ad4262c 100644 Binary files a/vorlagen-word/MISRA-Deviation-Permit-vorlage.docx and b/vorlagen-word/MISRA-Deviation-Permit-vorlage.docx differ diff --git a/vorlagen-word/MISRA-Deviation-Record-vorlage.docx b/vorlagen-word/MISRA-Deviation-Record-vorlage.docx index 38198bf..5eca5b0 100644 Binary files a/vorlagen-word/MISRA-Deviation-Record-vorlage.docx and b/vorlagen-word/MISRA-Deviation-Record-vorlage.docx differ diff --git a/vorlagen-word/Non-Conformity-vorlage.docx b/vorlagen-word/Non-Conformity-vorlage.docx index 6c1de28..65fb1fe 100644 Binary files a/vorlagen-word/Non-Conformity-vorlage.docx and b/vorlagen-word/Non-Conformity-vorlage.docx differ diff --git a/vorlagen-word/PID-vorlage.docx b/vorlagen-word/PID-vorlage.docx index c4126d4..a643603 100644 Binary files a/vorlagen-word/PID-vorlage.docx and b/vorlagen-word/PID-vorlage.docx differ diff --git a/vorlagen-word/PM-Plan-vorlage.docx b/vorlagen-word/PM-Plan-vorlage.docx index 5732b85..b8cfe6e 100644 Binary files a/vorlagen-word/PM-Plan-vorlage.docx and b/vorlagen-word/PM-Plan-vorlage.docx differ diff --git a/vorlagen-word/QA-Plan-vorlage.docx b/vorlagen-word/QA-Plan-vorlage.docx index 1326ccd..890efd5 100644 Binary files a/vorlagen-word/QA-Plan-vorlage.docx and b/vorlagen-word/QA-Plan-vorlage.docx differ diff --git a/vorlagen-word/Review-Protokoll-vorlage.docx b/vorlagen-word/Review-Protokoll-vorlage.docx index 1fa8e59..5ddbe6c 100644 Binary files a/vorlagen-word/Review-Protokoll-vorlage.docx and b/vorlagen-word/Review-Protokoll-vorlage.docx differ diff --git a/vorlagen-word/SWE-Plan-vorlage.docx b/vorlagen-word/SWE-Plan-vorlage.docx index ca5351c..942ca86 100644 Binary files a/vorlagen-word/SWE-Plan-vorlage.docx and b/vorlagen-word/SWE-Plan-vorlage.docx differ diff --git a/vorlagen-word/Test-Plan-vorlage.docx b/vorlagen-word/Test-Plan-vorlage.docx index 4923081..641b5a6 100644 Binary files a/vorlagen-word/Test-Plan-vorlage.docx and b/vorlagen-word/Test-Plan-vorlage.docx differ diff --git a/vorlagen-word/angebot-vorlage.docx b/vorlagen-word/angebot-vorlage.docx index 523d0d5..5642ed9 100644 Binary files a/vorlagen-word/angebot-vorlage.docx and b/vorlagen-word/angebot-vorlage.docx differ diff --git a/vorlagen-word/slohmaier-doc-template.docx b/vorlagen-word/slohmaier-doc-template.docx index 4e737a3..de45bff 100644 Binary files a/vorlagen-word/slohmaier-doc-template.docx and b/vorlagen-word/slohmaier-doc-template.docx differ diff --git a/vorlagen/MISRA-Deviation-Permit-vorlage.md b/vorlagen/MISRA-Deviation-Permit-vorlage.md index 235f36a..fec0d60 100644 --- a/vorlagen/MISRA-Deviation-Permit-vorlage.md +++ b/vorlagen/MISRA-Deviation-Permit-vorlage.md @@ -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.* diff --git a/vorlagen/MISRA-Deviation-Record-vorlage.md b/vorlagen/MISRA-Deviation-Record-vorlage.md index 372a6e5..b289e3e 100644 --- a/vorlagen/MISRA-Deviation-Record-vorlage.md +++ b/vorlagen/MISRA-Deviation-Record-vorlage.md @@ -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.* diff --git a/vorlagen/Non-Conformity-vorlage.md b/vorlagen/Non-Conformity-vorlage.md index 62aa2ae..a5a5157 100644 --- a/vorlagen/Non-Conformity-vorlage.md +++ b/vorlagen/Non-Conformity-vorlage.md @@ -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`).* diff --git a/vorlagen/PM-Plan-vorlage.md b/vorlagen/PM-Plan-vorlage.md index 801f83f..1b5ebd9 100644 --- a/vorlagen/PM-Plan-vorlage.md +++ b/vorlagen/PM-Plan-vorlage.md @@ -1,85 +1,75 @@ -# Projektplan (PM-Plan) +# Project Management Plan (PM Plan) -| Feld | Wert | -|-----------------|-------------------------------| -| Projekt | [Projektname] | -| Datum | [YYYY-MM-DD] | -| Version | [1.0] | -| Status | [Entwurf / Freigegeben] | -| Bezug | PID Version [X.Y] | +| Field | Value | +|-----------------|--------------------------------| +| Project | [Project name] | +| Date | [YYYY-MM-DD] | +| Version | [1.0] | +| 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.* diff --git a/vorlagen/QA-Plan-vorlage.md b/vorlagen/QA-Plan-vorlage.md index df883e4..6d1daaa 100644 --- a/vorlagen/QA-Plan-vorlage.md +++ b/vorlagen/QA-Plan-vorlage.md @@ -1,106 +1,68 @@ -# Quality Assurance Plan (QA-Plan) +# Quality Assurance Plan (QA Plan) -| Feld | Wert | -|-----------------|-------------------------------| -| Projekt | [Projektname] | -| Datum | [YYYY-MM-DD] | -| Version | [1.0] | -| Status | [Entwurf / Freigegeben] | -| ASIL | [QM / A / B / C / D] | +| Field | Value | +|-----------------|--------------------------------| +| Project | [Project name] | +| Date | [YYYY-MM-DD] | +| Version | [1.0] | +| 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.* diff --git a/vorlagen/Review-Protokoll-vorlage.md b/vorlagen/Review-Protokoll-vorlage.md index dcc7625..89bea7a 100644 --- a/vorlagen/Review-Protokoll-vorlage.md +++ b/vorlagen/Review-Protokoll-vorlage.md @@ -1,74 +1,74 @@ -# Review-Protokoll +# Review Minutes -| Feld | Wert | -|-------------------------|-----------------------------------------| -| Datum | [YYYY-MM-DD] | -| Review-Art | [Peer Review / Technical Review / Inspektion] | -| Moderator | [Name] | -| Protokollfuehrer | [Name] | +| Field | Value | +|-------------------------|------------------------------------------| +| Date | [YYYY-MM-DD] | +| Review type | [Peer review / Technical review / Inspection] | +| Moderator | [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/.* diff --git a/vorlagen/SA-vorlage.md b/vorlagen/SA-vorlage.md index 92f30e3..e0f7a6d 100644 --- a/vorlagen/SA-vorlage.md +++ b/vorlagen/SA-vorlage.md @@ -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] | -| Version | [1.0] | -| Status | [Entwurf / Freigegeben] | -| ASIL | [QM / A / B / C / D] | -| Autor | [Name] | +| Field | Value | +|----------|--------------------------------| +| Project | [Project name] | +| Date | [YYYY-MM-DD] | +| Version | [1.0] | +| Status | [Draft / Released] | +| ASIL | [QM / A / B / C / D] | +| 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).* diff --git a/vorlagen/SWA-vorlage.md b/vorlagen/SWA-vorlage.md index 6c03e7d..7f2789b 100644 --- a/vorlagen/SWA-vorlage.md +++ b/vorlagen/SWA-vorlage.md @@ -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] | -| Version | [1.0] | -| Status | [Entwurf / Freigegeben] | -| ASIL | [QM / A / B / C / D] | -| Autor | [Name] | -| Parent | [SA-XXX, falls vorhanden] | +| Field | Value | +|----------|--------------------------------| +| Project | [Project name] | +| Date | [YYYY-MM-DD] | +| Version | [1.0] | +| Status | [Draft / Released] | +| ASIL | [QM / A / B / C / D] | +| 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).* diff --git a/vorlagen/SWE-Plan-vorlage.md b/vorlagen/SWE-Plan-vorlage.md index 78c9036..02aafb1 100644 --- a/vorlagen/SWE-Plan-vorlage.md +++ b/vorlagen/SWE-Plan-vorlage.md @@ -1,132 +1,132 @@ -# Software Development Plan (SWE-Plan) +# Software Development Plan (SWE Plan) -| Feld | Wert | -|-----------------|-------------------------------| -| Projekt | [Projektname] | -| Datum | [YYYY-MM-DD] | -| Version | [1.0] | -| Status | [Entwurf / Freigegeben] | -| ASIL | [QM / A / B / C / D] | +| Field | Value | +|------------------|--------------------------------| +| Project | [Project name] | +| Date | [YYYY-MM-DD] | +| Version | [1.0] | +| 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.* diff --git a/vorlagen/Test-Plan-vorlage.md b/vorlagen/Test-Plan-vorlage.md index 5f745df..adbfb2b 100644 --- a/vorlagen/Test-Plan-vorlage.md +++ b/vorlagen/Test-Plan-vorlage.md @@ -1,121 +1,69 @@ -# Testplan +# Test Plan -| Feld | Wert | -|-----------------|-------------------------------| -| Projekt | [Projektname] | -| Datum | [YYYY-MM-DD] | -| Version | [1.0] | -| Status | [Entwurf / Freigegeben] | -| ASIL | [QM / A / B / C / D] | -| Bezug | SWE-Plan Version [X.Y] | +| Field | Value | +|-----------------|--------------------------------| +| Project | [Project name] | +| Date | [YYYY-MM-DD] | +| Version | [1.0] | +| 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.* diff --git a/vorlagen/Traceability-Matrix-vorlage.md b/vorlagen/Traceability-Matrix-vorlage.md index be6a99a..c11f0be 100644 --- a/vorlagen/Traceability-Matrix-vorlage.md +++ b/vorlagen/Traceability-Matrix-vorlage.md @@ -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.* diff --git a/vorlagen/angebot-vorlage.md b/vorlagen/angebot-vorlage.md index 8e6ff18..39677a5 100644 --- a/vorlagen/angebot-vorlage.md +++ b/vorlagen/angebot-vorlage.md @@ -1,7 +1,7 @@ - - + + - +