Initial commit: slohmaier Dev Process v1.0
ASPICE 4.0 / ISO 26262 Entwicklungsprozess fuer kleine Teams. Inhalte: - README mit hybrider Format-Strategie (Word + Markdown) - Toolstack (Gitea, Doorstop, Cppcheck, gcov, CppUTest, pandoc) - Markdown-Vorlagen fuer Requirements + Architektur (SA, SWA) - Markdown-Vorlagen fuer formelle Dokumente (PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan, Reviews, Non-Conformity, MISRA Permits/Records) - Word-Master-Template (slohmaier-doc-template.docx) mit ISO-9001- konformer Document Control, Formatvorlagen, Auto-Verzeichnissen - Build-Scripts (build_word_template.py, generate_word_vorlagen.sh) - gitea-aspice-setup.md, V-Modell-Infografik
This commit is contained in:
Stefan Lohmaier
@@ -0,0 +1,76 @@
|
||||
# MISRA Deviation Permit
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------|-------------------------------|
|
||||
| Permit-ID | PER-[XXX] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Erstellt von | [Name] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Regelbereich
|
||||
|
||||
| Feld | Wert |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Regel-Nummer | [z.B. Rule 11.3] |
|
||||
| Kategorie | [Required / Advisory] |
|
||||
| Regeltext | [Exakter Text der MISRA-Regel] |
|
||||
| Standard | [MISRA C:2012 / MISRA C:2023] |
|
||||
|
||||
## 2. Scope
|
||||
|
||||
Dieses Permit gilt fuer:
|
||||
|
||||
| Aspekt | Geltungsbereich |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Code-Bereich | [z.B. src/hal/*.c — alle Hardware-Abstraction-Layer Dateien] |
|
||||
| Modul / Komponente| [z.B. HAL, CAN-Treiber] |
|
||||
| Kontext | [z.B. Register-Zugriffe auf Memory-Mapped I/O] |
|
||||
|
||||
**Einschraenkung:** Dieses Permit gilt ausschliesslich fuer den oben definierten Scope. Abweichungen ausserhalb dieses Bereichs erfordern einen eigenen Deviation Record oder ein separates Permit.
|
||||
|
||||
## 3. Begruendung
|
||||
|
||||
[Warum ist die Abweichung von dieser Regel im definierten Kontext vertretbar?]
|
||||
|
||||
Beispiel: "Rule 11.3 verbietet Casts zwischen Pointer-Typen. Im HAL sind Casts von `uint32_t*` auf Register-Structs notwendig, da die Hardware ueber Memory-Mapped I/O angesprochen wird. Die Register-Adressen und Layouts sind durch das Datenblatt definiert und statisch. Eine regelkonforme Alternative existiert nicht."
|
||||
|
||||
**Begruendung:** [Hier ausfuellen]
|
||||
|
||||
## 4. Risikobewertung und Alternativen
|
||||
|
||||
### Risikobewertung
|
||||
|
||||
| Aspekt | Bewertung |
|
||||
|---------------------------|-----------------------------------------------|
|
||||
| Sicherheitsrelevanz | [Keine / Gering / Mittel / Hoch] |
|
||||
| Fehlerpotenzial | [Beschreibung] |
|
||||
| Absicherung | [z.B. Unit Tests pruefen korrekte Register-Zugriffe, Code Review Pflicht fuer HAL-Code] |
|
||||
| Restrisiko | [Bewertung] |
|
||||
|
||||
### Geprufte Alternativen
|
||||
|
||||
| Alternative | Bewertung |
|
||||
|--------------------------|------------------------------------------------|
|
||||
| [z.B. Generische Zugriffsfunktionen] | [z.B. Nicht praktikabel, da hunderte Register] |
|
||||
| [z.B. Compiler-Erweiterung] | [z.B. Nicht portabel] |
|
||||
|
||||
## 5. Freigabe
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Freigegeben von | [Name, Rolle] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Nachweis | [GitLab-Issue / Wiki-Verweis / Unterschrift] |
|
||||
|
||||
## 6. Gueltigkeit
|
||||
|
||||
| Feld | Wert |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Gueltig ab | [YYYY-MM-DD] |
|
||||
| Gueltig bis | [YYYY-MM-DD oder "bis auf Widerruf"] |
|
||||
| Widerrufsbedingung | [z.B. Bei Aenderung der Zielplattform neu bewerten] |
|
||||
|
||||
---
|
||||
|
||||
*Dieses Permit wird im GitLab-Wiki unter MISRA-Deviation-Permits abgelegt und aus Deviation Records referenziert.*
|
||||
@@ -0,0 +1,70 @@
|
||||
# MISRA Deviation Record
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------|-------------------------------|
|
||||
| Deviation-ID | DEV-[XXX] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Erstellt von | [Name] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Regel
|
||||
|
||||
| Feld | Wert |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Regel-Nummer | [z.B. Rule 11.3] |
|
||||
| Kategorie | [Required / Advisory / Mandatory] |
|
||||
| Regeltext | [Exakter Text der MISRA-Regel] |
|
||||
| Standard | [MISRA C:2012 / MISRA C:2023] |
|
||||
|
||||
## 2. Fundstelle
|
||||
|
||||
| Feld | Wert |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Datei | [z.B. src/drivers/watchdog.c] |
|
||||
| Zeile(n) | [z.B. 142-145] |
|
||||
| Funktion | [z.B. wdg_set_timeout()] |
|
||||
| Git-Commit | [Commit-Hash] |
|
||||
| GitLab-Referenz | [MR-Link oder Issue-Link] |
|
||||
|
||||
## 3. Begruendung
|
||||
|
||||
[Warum ist die Abweichung in diesem konkreten Fall technisch vertretbar?]
|
||||
|
||||
Moegliche Begruendungen:
|
||||
- Hardware-Zugriff erfordert Typkonvertierung
|
||||
- Compiler-spezifisches Verhalten ist definiert und getestet
|
||||
- Alternative Implementierung waere unverhältnismaessig komplex
|
||||
- Regel ist im Kontext nicht sicherheitsrelevant
|
||||
|
||||
**Konkrete Begruendung:** [Hier ausfuellen]
|
||||
|
||||
## 4. Risikobewertung
|
||||
|
||||
| Aspekt | Bewertung |
|
||||
|---------------------------|-----------------------------------------------|
|
||||
| Sicherheitsrelevanz | [Keine / Gering / Mittel / Hoch] |
|
||||
| Fehlerpotenzial | [Beschreibung moeglicher Fehler] |
|
||||
| Absicherung | [Welche Tests / Massnahmen sichern den Code ab] |
|
||||
| Restrisiko | [Bewertung des verbleibenden Risikos] |
|
||||
|
||||
## 5. Verweis auf Deviation Permit
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Permit vorhanden | [Ja / Nein] |
|
||||
| Permit-ID | [PER-XXX oder "entfaellt"] |
|
||||
|
||||
Falls kein Permit vorhanden: diese Abweichung ist eine Einzelfallgenehmigung.
|
||||
|
||||
## 6. Freigabe
|
||||
|
||||
| Feld | Wert |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Freigegeben von | [Name, Rolle] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Nachweis | [GitLab-MR-Approval / Unterschrift] |
|
||||
|
||||
---
|
||||
|
||||
*Dieser Record wird im Repository unter `docs/misra/` oder als GitLab Issue gefuehrt.*
|
||||
@@ -0,0 +1,79 @@
|
||||
# Non-Conformity Report
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------|-------------------------------|
|
||||
| NC-ID | NC-[XXX] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Erstellt von | [Name] |
|
||||
| Status | [Offen / In Bearbeitung / Geschlossen] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Bezug
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Art | [Prozessabweichung / Produktabweichung] |
|
||||
| Betroffener Prozess | [z.B. SWE.4 Implementierung, SUP.1 QA] |
|
||||
| Betroffenes Work Product | [z.B. Modul XY, Anforderung SWR-042, Testplan] |
|
||||
| GitLab-Referenz | [Issue-Link / MR-Link / Wiki-Seite] |
|
||||
| Gefunden bei | [Review / Audit / Test / CI-Pipeline] |
|
||||
|
||||
## 2. Beschreibung der Abweichung
|
||||
|
||||
[Was genau weicht ab? Konkret beschreiben. Bezug auf Norm oder Prozessvorgabe angeben.]
|
||||
|
||||
## 3. Schweregrad
|
||||
|
||||
| Schweregrad | Definition |
|
||||
|-------------|------------------------------------------------------------------|
|
||||
| [ ] Critical | Sicherheitsrelevant oder vollstaendiges Fehlen eines geforderten Work Products |
|
||||
| [ ] Major | Signifikante Abweichung, die die Qualitaet oder Konformitaet beeintraechtigt |
|
||||
| [ ] Minor | Geringfuegige Abweichung, keine direkte Auswirkung auf Sicherheit oder Funktion |
|
||||
|
||||
**Zugewiesener Schweregrad:** [Critical / Major / Minor]
|
||||
|
||||
## 4. Ursachenanalyse
|
||||
|
||||
[Warum ist die Abweichung aufgetreten? Moegliche Kategorien:]
|
||||
- Prozess nicht bekannt / nicht geschult
|
||||
- Prozess nicht anwendbar / unrealistisch
|
||||
- Versehen / menschlicher Fehler
|
||||
- Tool-Fehler
|
||||
- Zeitdruck / Ressourcenmangel
|
||||
- Anforderung unklar
|
||||
|
||||
**Beschreibung:** [Konkrete Ursache]
|
||||
|
||||
## 5. Korrekturmassnahme
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Massnahme | [Was wird getan um die Abweichung zu beheben] |
|
||||
| Verantwortlich | [Name] |
|
||||
| Faelligkeit | [YYYY-MM-DD] |
|
||||
|
||||
### Vorbeugende Massnahme (optional)
|
||||
|
||||
[Was wird getan damit diese Art von Abweichung nicht erneut auftritt?]
|
||||
|
||||
## 6. Wirksamkeitspruefung
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Geprueft von | [Name] |
|
||||
| Pruefungsdatum | [YYYY-MM-DD] |
|
||||
| Massnahme wirksam | [Ja / Nein] |
|
||||
| Nachweis | [GitLab-Issue-Link / Commit / Review] |
|
||||
|
||||
## 7. Abschluss
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Status | [Geschlossen / Erneut geoeffnet] |
|
||||
| Geschlossen von | [Name] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
|
||||
---
|
||||
|
||||
*Dieser Report wird als GitLab Issue (Label: `non-conformity`) gefuehrt.*
|
||||
@@ -0,0 +1,92 @@
|
||||
# Project Initiation Document (PID)
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------|-------------------------------|
|
||||
| Projektname | [Name] |
|
||||
| Auftraggeber | [Firma / Ansprechpartner] |
|
||||
| Auftragnehmer | Stefan Lohmaier |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Entwurf / Freigegeben] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Projektziel
|
||||
|
||||
[Was soll erreicht werden? Ein bis drei Saetze.]
|
||||
|
||||
## 2. Scope
|
||||
|
||||
### In Scope
|
||||
|
||||
- [Lieferumfang Punkt 1]
|
||||
- [Lieferumfang Punkt 2]
|
||||
|
||||
### Out of Scope
|
||||
|
||||
- [Was explizit nicht enthalten ist]
|
||||
- [Abgrenzung zu anderen Teilprojekten]
|
||||
|
||||
## 3. Randbedingungen
|
||||
|
||||
| Randbedingung | Beschreibung |
|
||||
|-------------------------|-------------------------------------------|
|
||||
| Zielplattform | [z.B. ARM Cortex-R5, Renesas RH850] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
| Normen | [ASPICE 4.0, ISO 26262:2018] |
|
||||
| Programmiersprache | [C / C++ / Rust] |
|
||||
| Coding Standard | [MISRA C:2012 / MISRA C:2023] |
|
||||
| Laufzeitumgebung | [Bare-Metal / AUTOSAR Classic / Linux] |
|
||||
| Kundenvorgaben | [Spezifische Anforderungen des Kunden] |
|
||||
|
||||
## 4. Lieferergebnisse
|
||||
|
||||
| Nr. | Lieferergebnis | Format | Termin |
|
||||
|-----|-----------------------------------|---------------|-------------|
|
||||
| 1 | Software Requirements Specification | GitLab Issues | [Datum] |
|
||||
| 2 | Architektur-Dokumentation | GitLab Wiki | [Datum] |
|
||||
| 3 | Quellcode | Git Repository| [Datum] |
|
||||
| 4 | Unit Tests + Coverage Report | CI-Artefakt | [Datum] |
|
||||
| 5 | MISRA Compliance Report | CI-Artefakt | [Datum] |
|
||||
| 6 | Testbericht | Markdown/PDF | [Datum] |
|
||||
| 7 | Release-Paket | Git Tag + Artefakte | [Datum] |
|
||||
|
||||
## 5. Meilensteine
|
||||
|
||||
| Meilenstein | Datum | Kriterium |
|
||||
|--------------------------|-------------|------------------------------------------|
|
||||
| Projektstart | [Datum] | PID freigegeben |
|
||||
| Requirements Complete | [Datum] | Alle Anforderungen reviewed |
|
||||
| Architecture Complete | [Datum] | Architektur reviewed und freigegeben |
|
||||
| Code Complete | [Datum] | Implementierung abgeschlossen, Tests gruen |
|
||||
| Verification Complete | [Datum] | Coverage-Ziele erreicht, MISRA compliant |
|
||||
| Release | [Datum] | Alle Exit-Kriterien erfuellt |
|
||||
|
||||
## 6. Risiken (initial)
|
||||
|
||||
| ID | Risiko | Wahrscheinlichkeit | Auswirkung | Massnahme |
|
||||
|------|----------------------------------|---------------------|------------|----------------------------------|
|
||||
| R-01 | [Risikobeschreibung] | [H/M/L] | [H/M/L] | [Gegenmassnahme] |
|
||||
| R-02 | [Risikobeschreibung] | [H/M/L] | [H/M/L] | [Gegenmassnahme] |
|
||||
|
||||
## 7. Beteiligte Rollen
|
||||
|
||||
| Rolle | Person / Organisation | Verantwortung |
|
||||
|--------------------------|------------------------|-----------------------------------|
|
||||
| Projektleiter | Stefan Lohmaier | Gesamtverantwortung |
|
||||
| Software-Entwickler | Stefan Lohmaier | Implementierung, Unit Tests |
|
||||
| QA-Verantwortlicher | [Name / extern] | QA-Aktivitaeten, Audits |
|
||||
| Safety-Verantwortlicher | [Name / extern] | ISO 26262 Compliance |
|
||||
| Reviewer | [Name / extern] | Code- und Dokument-Reviews |
|
||||
| Auftraggeber | [Name] | Anforderungen, Abnahme |
|
||||
|
||||
## 8. Freigabe
|
||||
|
||||
| Rolle | Name | Datum | Unterschrift / GitLab-Verweis |
|
||||
|----------------------|---------------------|-------------|-------------------------------|
|
||||
| Auftragnehmer | Stefan Lohmaier | [Datum] | |
|
||||
| Auftraggeber | [Name] | [Datum] | |
|
||||
|
||||
---
|
||||
|
||||
*Aenderungen an diesem Dokument werden im GitLab-Wiki versioniert.*
|
||||
@@ -0,0 +1,85 @@
|
||||
# Projektplan (PM-Plan)
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------|-------------------------------|
|
||||
| Projekt | [Projektname] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Entwurf / Freigegeben] |
|
||||
| Bezug | PID Version [X.Y] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Projektphasen und Meilensteine
|
||||
|
||||
| Phase | Start | Ende | Meilenstein |
|
||||
|------------------------|-------------|-------------|--------------------------------------|
|
||||
| Anforderungsanalyse | [Datum] | [Datum] | Requirements Complete |
|
||||
| Architektur | [Datum] | [Datum] | Architecture Complete |
|
||||
| Implementierung | [Datum] | [Datum] | Code Complete |
|
||||
| Integration & Test | [Datum] | [Datum] | Integration Complete |
|
||||
| Verifikation | [Datum] | [Datum] | Verification Complete |
|
||||
| Release | [Datum] | [Datum] | Release |
|
||||
|
||||
Phasen koennen ueberlappen (iterativ). Meilenstein-Kriterien sind im QA-Plan definiert.
|
||||
|
||||
## 2. Ressourcen und Rollen
|
||||
|
||||
| Rolle | Person | Verfuegbarkeit | Aufgaben |
|
||||
|--------------------------|---------------------|-------------------|---------------------------------|
|
||||
| Projektleiter / Entwickler | Stefan Lohmaier | [X Tage/Woche] | Planung, Implementierung, Tests |
|
||||
| Reviewer | [Name / extern] | [nach Bedarf] | Code- und Dokument-Reviews |
|
||||
| QA | [Name / extern] | [nach Bedarf] | QA-Audits, Prozessueberwachung |
|
||||
| Auftraggeber | [Name] | [nach Bedarf] | Anforderungsklaerung, Abnahme |
|
||||
|
||||
## 3. Kommunikationsplan
|
||||
|
||||
| Aktivitaet | Haeufigkeit | Teilnehmer | Medium |
|
||||
|--------------------------|--------------|---------------------------|---------------------|
|
||||
| Status-Update | [Woechentlich] | Auftraggeber, PL | E-Mail / Call |
|
||||
| Technische Abstimmung | [Nach Bedarf] | Entwickler, Auftraggeber | Call / GitLab Issue |
|
||||
| Meilenstein-Review | [Pro Phase] | Alle Beteiligten | Meeting |
|
||||
| QA-Report | [Pro Phase] | QA, PL, Auftraggeber | Dokument (Wiki) |
|
||||
|
||||
## 4. Eskalationspfad
|
||||
|
||||
| Stufe | Situation | Eskalation an | Frist |
|
||||
|-------|----------------------------------------------|----------------------------|-------------|
|
||||
| 1 | Technische Blockade | Auftraggeber (technisch) | 2 Arbeitstage |
|
||||
| 2 | Terminverschiebung > 1 Woche | Projektverantwortlicher | 1 Arbeitstag |
|
||||
| 3 | Scope-Aenderung oder Safety-Concern | Management Auftraggeber | sofort |
|
||||
|
||||
## 5. Aenderungsmanagement
|
||||
|
||||
Aenderungen an Anforderungen, Scope oder Zeitplan werden als Change Request behandelt:
|
||||
|
||||
1. Change Request als GitLab Issue erfassen (Label: `change-request`)
|
||||
2. Auswirkungsanalyse: betroffene Anforderungen, Code, Tests, Zeitplan
|
||||
3. Bewertung und Freigabe durch Auftraggeber
|
||||
4. Bei Freigabe: betroffene Work Products aktualisieren, Traceability nachfuehren
|
||||
5. Dokumentation der Aenderung im Issue (Begruendung, Auswirkung, Entscheidung)
|
||||
|
||||
Keine Aenderung ohne dokumentierte Freigabe.
|
||||
|
||||
## 6. Risikomanagement
|
||||
|
||||
### Vorgehen
|
||||
|
||||
- Initiale Risiken im PID erfasst
|
||||
- Risikoliste wird pro Meilenstein-Review aktualisiert
|
||||
- Neue Risiken werden als GitLab Issues erfasst (Label: `risk`)
|
||||
- Jedes Risiko hat: Beschreibung, Wahrscheinlichkeit, Auswirkung, Massnahme, Verantwortlicher
|
||||
|
||||
### Risiko-Bewertung
|
||||
|
||||
| Wahrscheinlichkeit / Auswirkung | Niedrig | Mittel | Hoch |
|
||||
|----------------------------------|---------|---------|---------|
|
||||
| Hoch | Mittel | Hoch | Kritisch|
|
||||
| Mittel | Niedrig | Mittel | Hoch |
|
||||
| Niedrig | Niedrig | Niedrig | Mittel |
|
||||
|
||||
Kritische Risiken werden sofort eskaliert (siehe Eskalationspfad Stufe 3).
|
||||
|
||||
---
|
||||
|
||||
*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*
|
||||
@@ -0,0 +1,106 @@
|
||||
# Quality Assurance Plan (QA-Plan)
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------|-------------------------------|
|
||||
| Projekt | [Projektname] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Entwurf / Freigegeben] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
|
||||
---
|
||||
|
||||
## 1. QA-Aktivitaeten pro Phase
|
||||
|
||||
| Phase | QA-Aktivitaet | Verantwortlich |
|
||||
|------------------------|--------------------------------------------------------|----------------|
|
||||
| Anforderungsanalyse | Review der Anforderungen (Vollstaendigkeit, Konsistenz, Testbarkeit) | QA / Reviewer |
|
||||
| Architektur | Architektur-Review (Modularitaet, Safety-Konzept) | QA / Reviewer |
|
||||
| Implementierung | Code-Review (MR-Approval), MISRA-Pruefung (CI) | Reviewer / CI |
|
||||
| Integration & Test | Test-Review, Coverage-Pruefung, Traceability-Check | QA / CI |
|
||||
| Verifikation | Gesamtpruefung: alle Kriterien erfuellt? | QA |
|
||||
| Release | Release-Audit: alle Work Products vollstaendig? | QA |
|
||||
|
||||
## 2. Zu pruefende Work Products
|
||||
|
||||
| Work Product | Review-Art | Pruefkriterien |
|
||||
|----------------------------------|------------------|---------------------------------------------|
|
||||
| PID | Peer Review | Vollstaendig, konsistent mit Vertrag |
|
||||
| PM-Plan | Peer Review | Realistisch, Risiken adressiert |
|
||||
| Software Requirements | Technical Review | Eindeutig, testbar, ASIL zugeordnet |
|
||||
| Architektur-Dokumentation | Technical Review | Modular, Schnittstellen definiert, Safety-Konzept |
|
||||
| Quellcode | Peer Review (MR) | MISRA-konform, getestet, lesbar |
|
||||
| Unit Tests | Peer Review | Abdeckung, Randfaelle, Traceability |
|
||||
| Testberichte | Peer Review | Pass/Fail dokumentiert, Coverage erreicht |
|
||||
| MISRA Compliance Report | Peer Review | Abweichungen dokumentiert und genehmigt |
|
||||
| Traceability-Matrix | QA-Pruefung | Keine Luecken, bidirektional |
|
||||
|
||||
## 3. Review-Arten
|
||||
|
||||
| Review-Art | Teilnehmer | Formalitaet | Wann |
|
||||
|---------------------|-------------------------------|-------------|----------------------------------|
|
||||
| Peer Review | 1 Reviewer | Niedrig | Jeder MR, Dokument-Aenderungen |
|
||||
| Technical Review | 2+ Reviewer, inkl. Tech Lead | Mittel | Architektur, Safety-Code, Plaene |
|
||||
| Inspektion | Moderator + 2+ Reviewer | Hoch | Safety-kritische Artefakte (ASIL C/D) |
|
||||
|
||||
Peer Reviews laufen ueber GitLab MR-Approvals. Technical Reviews und Inspektionen werden zusaetzlich mit Review-Protokoll dokumentiert.
|
||||
|
||||
## 4. Entry/Exit-Kriterien
|
||||
|
||||
### Entry-Kriterien (Beginn einer Phase)
|
||||
|
||||
| Phase | Entry-Kriterien |
|
||||
|----------------------|--------------------------------------------------------|
|
||||
| Architektur | Requirements reviewed und freigegeben |
|
||||
| Implementierung | Architektur reviewed und freigegeben |
|
||||
| Integration & Test | Code-Reviews abgeschlossen, Unit Tests gruen |
|
||||
| Verifikation | Alle Tests durchgefuehrt, Coverage gemessen |
|
||||
| Release | Alle Exit-Kriterien der Verifikation erfuellt |
|
||||
|
||||
### Exit-Kriterien (Abschluss einer Phase)
|
||||
|
||||
| Phase | Exit-Kriterien |
|
||||
|----------------------|--------------------------------------------------------|
|
||||
| Anforderungen | Alle Requirements reviewed, ASIL zugeordnet, testbar |
|
||||
| Architektur | Architektur reviewed, Schnittstellen definiert |
|
||||
| Implementierung | MISRA-konform, Unit Tests gruen, Coverage-Ziel erreicht |
|
||||
| Integration & Test | Integrationstests gruen, keine offenen Critical Findings |
|
||||
| Verifikation | Traceability vollstaendig, alle Findings geschlossen oder bewertet |
|
||||
| Release | Alle Work Products vollstaendig, QA-Freigabe erteilt |
|
||||
|
||||
## 5. Non-Conformity-Prozess
|
||||
|
||||
1. Abweichung wird erkannt (Review, Audit, Test)
|
||||
2. Non-Conformity Report erstellen (GitLab Issue, Label: `non-conformity`)
|
||||
3. Schweregrad zuweisen: Critical / Major / Minor
|
||||
4. Ursachenanalyse durchfuehren
|
||||
5. Korrekturmassnahme definieren und umsetzen
|
||||
6. Wirksamkeitspruefung nach Umsetzung
|
||||
7. Issue schliessen mit Verweis auf Korrekturnachweis
|
||||
|
||||
**Eskalation:** Critical Non-Conformities werden sofort an den Auftraggeber gemeldet.
|
||||
|
||||
## 6. Reporting an Management
|
||||
|
||||
| Report | Haeufigkeit | Inhalt |
|
||||
|---------------------------|------------------|-------------------------------------------|
|
||||
| QA-Status-Report | Pro Meilenstein | Offene Findings, NC-Status, Coverage-Stand |
|
||||
| Meilenstein-Bewertung | Pro Phase-Ende | Entry/Exit-Kriterien geprueft |
|
||||
| Release-Bewertung | Vor Release | Gesamtbewertung aller QA-Kriterien |
|
||||
|
||||
## 7. QA-Metriken
|
||||
|
||||
| Metrik | Ziel | Messung |
|
||||
|---------------------------------|-------------------------|----------------------------------|
|
||||
| Requirement Coverage | 100% | Anforderungen mit verlinktem Test |
|
||||
| Code Coverage (Statement) | >= [X]% | gcov/lcov in CI |
|
||||
| Code Coverage (Branch) | >= [X]% | gcov/lcov in CI |
|
||||
| MC/DC Coverage (falls ASIL C/D) | >= [X]% | MCDC-Star / kommerziell |
|
||||
| MISRA Violations | 0 (oder alle genehmigt)| Cppcheck MISRA-Addon in CI |
|
||||
| Offene Findings (Critical) | 0 vor Release | GitLab Issues |
|
||||
| Offene Non-Conformities | 0 Critical/Major | GitLab Issues |
|
||||
| Review-Abdeckung | 100% MRs reviewed | GitLab MR-Approvals |
|
||||
|
||||
---
|
||||
|
||||
*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*
|
||||
@@ -0,0 +1,74 @@
|
||||
# Review-Protokoll
|
||||
|
||||
| Feld | Wert |
|
||||
|-------------------------|-----------------------------------------|
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Review-Art | [Peer Review / Technical Review / Inspektion] |
|
||||
| Moderator | [Name] |
|
||||
| Protokollfuehrer | [Name] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Teilnehmer
|
||||
|
||||
| Name | Rolle | Anwesend |
|
||||
|---------------------|--------------------------|----------|
|
||||
| [Name] | Moderator | Ja / Nein |
|
||||
| [Name] | Autor | Ja / Nein |
|
||||
| [Name] | Reviewer | Ja / Nein |
|
||||
| [Name] | Reviewer | Ja / Nein |
|
||||
|
||||
## 2. Reviewtes Work Product
|
||||
|
||||
| Feld | Wert |
|
||||
|-------------------|-------------------------------------------|
|
||||
| Work Product | [z.B. Architektur-Dokumentation, Modul XY, Anforderungen SWR-040 bis SWR-060] |
|
||||
| Version / Commit | [Version oder Git-Commit-Hash] |
|
||||
| GitLab-Referenz | [MR-Link / Wiki-Seite / Issue-Nummern] |
|
||||
|
||||
## 3. Review-Vorbereitung
|
||||
|
||||
| Reviewer | Vorbereitungszeit (h) | Vorbereitung abgeschlossen |
|
||||
|-------------------|-----------------------|----------------------------|
|
||||
| [Name] | [X] | Ja / Nein |
|
||||
| [Name] | [X] | Ja / Nein |
|
||||
|
||||
## 4. Findings
|
||||
|
||||
| ID | Beschreibung | Schwere | Verantwortlich | Fälligkeit | Status |
|
||||
|------|---------------------------------|-------------------|----------------|-------------|-------------|
|
||||
| F-01 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen |
|
||||
| F-02 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen |
|
||||
| F-03 | [Beschreibung des Findings] | Critical / Major / Minor | [Name] | [Datum] | Offen |
|
||||
|
||||
### Schweregrade
|
||||
|
||||
- **Critical:** Sicherheitsrelevant oder funktional falsch. Muss vor Freigabe behoben werden.
|
||||
- **Major:** Signifikanter Fehler oder Luecke. Muss behoben werden, kann aber terminiert werden.
|
||||
- **Minor:** Verbesserungsvorschlag, Stil, Lesbarkeit. Behebung empfohlen.
|
||||
|
||||
## 5. Entscheidung
|
||||
|
||||
| Entscheidung |
|
||||
|-----------------------------------------------------------|
|
||||
| [ ] Freigegeben |
|
||||
| [ ] Bedingt freigegeben (nach Behebung der Critical/Major Findings) |
|
||||
| [ ] Nicht freigegeben (erneutes Review erforderlich) |
|
||||
|
||||
**Bedingungen fuer bedingte Freigabe:**
|
||||
[Falls zutreffend: welche Findings muessen behoben werden, wer prueft die Behebung]
|
||||
|
||||
## 6. Unterschriften / Nachweis
|
||||
|
||||
| Rolle | Name | Datum | Nachweis |
|
||||
|----------------------|---------------------|-------------|------------------------------|
|
||||
| Moderator | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] |
|
||||
| Reviewer 1 | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] |
|
||||
| Reviewer 2 | [Name] | [Datum] | [Unterschrift / GitLab-MR-Approval] |
|
||||
| Autor | [Name] | [Datum] | |
|
||||
|
||||
**GitLab-MR-Link:** [URL zum Merge Request, falls zutreffend]
|
||||
|
||||
---
|
||||
|
||||
*Dieses Protokoll wird im GitLab-Wiki unter Review-Protokolle/ abgelegt.*
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
active: true
|
||||
level: 1.0
|
||||
links:
|
||||
- SYS-XXX: [hash]
|
||||
---
|
||||
|
||||
# SA-XXX: [Element-Name]
|
||||
|
||||
> **System Architectural Design Element (ASPICE SYS.3).**
|
||||
> Beschreibt ein Element der System-Architektur und sein Mapping auf System-Anforderungen.
|
||||
|
||||
| Feld | Wert |
|
||||
|----------|-------------------------------|
|
||||
| Projekt | [Projektname] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Entwurf / Freigegeben] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
| Autor | [Name] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Verantwortung
|
||||
|
||||
[Was tut dieses Element? Ein bis zwei Saetze. Welcher Zweck im Gesamtsystem.]
|
||||
|
||||
## 2. System-Kontext
|
||||
|
||||
[PlantUML-Diagramm: dieses Element im Verhaeltnis zu Nachbarsystemen / Umgebung.]
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
!define COMPONENT(x) component "x" as x
|
||||
COMPONENT([Element])
|
||||
[Element] --> [Nachbarsystem A] : Schnittstelle X
|
||||
[Nachbarsystem B] --> [Element] : Schnittstelle Y
|
||||
@enduml
|
||||
```
|
||||
|
||||
## 3. Allokation
|
||||
|
||||
| Anforderung | Allokation auf | Bemerkung |
|
||||
|---------------|----------------|---------------------------|
|
||||
| SYS-XXX | dieses Element | [vollstaendig / teilweise] |
|
||||
| SYS-YYY | dieses Element | [Begruendung] |
|
||||
|
||||
Allokations-Regel: jede verlinkte System-Anforderung muss eindeutig auf HW, SW oder Mechanik abgebildet werden.
|
||||
|
||||
## 4. Schnittstellen zur Umgebung
|
||||
|
||||
| Schnittstelle | Richtung | Typ | Bemerkung |
|
||||
|---------------|---------------|----------------------|--------------------------|
|
||||
| [Name] | in / out / io | [CAN / SPI / GPIO / ...] | [Protokoll-Verweis] |
|
||||
|
||||
## 5. Subkomponenten / Aufteilung
|
||||
|
||||
[Falls dieses System-Element aus mehreren Subkomponenten besteht: kurze Auflistung mit Verweis auf weitere SA- oder SWA-Elemente.]
|
||||
|
||||
| Subkomponente | Realisierung | Verweis |
|
||||
|---------------|--------------------|-------------------|
|
||||
| [Name] | [HW / SW / Mechanik] | SWA-XXX / SA-YYY |
|
||||
|
||||
## 6. Dynamisches Verhalten
|
||||
|
||||
[PlantUML-Sequenz oder State-Diagramm fuer kritische Ablaeufe.]
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
actor Nutzer
|
||||
Nutzer -> [Element]: Anforderung
|
||||
[Element] -> [Nachbar]: weiterleiten
|
||||
[Nachbar] --> [Element]: Antwort
|
||||
[Element] --> Nutzer: Ergebnis
|
||||
@enduml
|
||||
```
|
||||
|
||||
## 7. Nichtfunktionale Eigenschaften
|
||||
|
||||
| Aspekt | Anforderung / Zielwert |
|
||||
|---------------------|-----------------------------|
|
||||
| Worst-Case Timing | [z.B. < 10 ms Reaktionszeit]|
|
||||
| Speicherbedarf | [z.B. < 64 KB Flash] |
|
||||
| Stromaufnahme | [z.B. < 200 mA bei 12 V] |
|
||||
| Umgebungsbedingungen | [Temperatur, EMV] |
|
||||
| Sicherheitsziel | [Verweis auf SG-XXX, falls vorhanden] |
|
||||
|
||||
## 8. Designentscheidungen
|
||||
|
||||
| Entscheidung | Alternativen | Begruendung |
|
||||
|--------------|--------------|-------------|
|
||||
| [Was] | [Was sonst noch erwogen wurde] | [Warum diese Wahl] |
|
||||
|
||||
## 9. Verifikation
|
||||
|
||||
| Anforderung | Verifikations-Methode | Test-ID |
|
||||
|-------------|------------------------|-------------------|
|
||||
| SYS-XXX | [Review / Test / Analyse] | TST-SYS-XXX |
|
||||
|
||||
Jede in den `links` referenzierte System-Anforderung muss mindestens eine Verifikations-Methode haben.
|
||||
|
||||
---
|
||||
|
||||
*Aenderungen an diesem Architektur-Element gehen per PR mit mind. 2 Technical-Review-Approvals (siehe SWE-Plan).*
|
||||
@@ -0,0 +1,148 @@
|
||||
---
|
||||
active: true
|
||||
level: 1.0
|
||||
links:
|
||||
- SWE-XXX: [hash]
|
||||
---
|
||||
|
||||
# SWA-XXX: [Komponenten-Name]
|
||||
|
||||
> **Software Architectural Design Element (ASPICE SWE.2).**
|
||||
> Beschreibt eine Software-Komponente und ihr Mapping auf Software-Anforderungen.
|
||||
|
||||
| Feld | Wert |
|
||||
|----------|-------------------------------|
|
||||
| Projekt | [Projektname] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Entwurf / Freigegeben] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
| Autor | [Name] |
|
||||
| Parent | [SA-XXX, falls vorhanden] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Verantwortung
|
||||
|
||||
[Ein bis zwei Saetze: Was tut diese Komponente? Wo ist die Abgrenzung zu Nachbar-Komponenten?]
|
||||
|
||||
## 2. Statische Sicht
|
||||
|
||||
### 2.1 Komponentendiagramm
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
package "[Komponenten-Name]" {
|
||||
[Submodul A]
|
||||
[Submodul B]
|
||||
}
|
||||
[Submodul A] --> [Submodul B]
|
||||
[Komponenten-Name] ..> [Nachbar-Komponente] : nutzt
|
||||
@enduml
|
||||
```
|
||||
|
||||
### 2.2 Eingebettete / verwendete Komponenten
|
||||
|
||||
| Komponente | Verweis | Verwendung |
|
||||
|---------------|----------|--------------------------|
|
||||
| [Name] | SWA-YYY | [wofuer] |
|
||||
|
||||
## 3. Schnittstellen
|
||||
|
||||
### 3.1 Bereitgestellte Schnittstelle (Provided)
|
||||
|
||||
```c
|
||||
/**
|
||||
* @brief [Kurzbeschreibung]
|
||||
* @param [name] [Bedeutung, Wertebereich]
|
||||
* @return [Status / Wert]
|
||||
* @pre [Vorbedingung]
|
||||
* @post [Nachbedingung]
|
||||
*/
|
||||
Status component_init(const Config* cfg);
|
||||
```
|
||||
|
||||
| Funktion | Zweck | Pre-Condition | Post-Condition |
|
||||
|------------------|----------------------|-----------------------|------------------------|
|
||||
| component_init | Initialisierung | cfg != NULL | Komponente betriebsbereit |
|
||||
| component_send | Daten senden | initialisiert | Daten in TX-Buffer |
|
||||
|
||||
### 3.2 Benoetigte Schnittstelle (Required)
|
||||
|
||||
| Schnittstelle | Bereitgestellt von | Zweck |
|
||||
|-------------------|--------------------|-----------------------|
|
||||
| ILogger::log() | LoggerComponent | Diagnose / Tracing |
|
||||
| IClock::now() | ClockComponent | Zeitstempel |
|
||||
|
||||
## 4. Dynamisches Verhalten
|
||||
|
||||
### 4.1 Sequenzdiagramm (kritischer Ablauf)
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
participant App
|
||||
participant "[Komponente]" as C
|
||||
participant HW
|
||||
App -> C: init(cfg)
|
||||
C -> HW: configure
|
||||
HW --> C: ok
|
||||
C --> App: STATUS_OK
|
||||
@enduml
|
||||
```
|
||||
|
||||
### 4.2 Zustandsdiagramm (falls zutreffend)
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
[*] --> Uninitialized
|
||||
Uninitialized --> Ready : init()
|
||||
Ready --> Busy : send()
|
||||
Busy --> Ready : tx_done
|
||||
Ready --> Error : fault
|
||||
Error --> Ready : reset()
|
||||
@enduml
|
||||
```
|
||||
|
||||
## 5. Ressourcen-Bedarf
|
||||
|
||||
| Ressource | Worst-Case | Methode der Bestimmung |
|
||||
|-------------------|--------------|-----------------------------|
|
||||
| Stack | [z.B. 256 B] | [Messung / statische Analyse] |
|
||||
| Heap | [z.B. 0 B] | [keine Heap-Nutzung] |
|
||||
| Flash | [z.B. 4 KB] | [Map-File des Linkers] |
|
||||
| RAM (statisch) | [z.B. 128 B] | [Map-File des Linkers] |
|
||||
| CPU-Last | [z.B. < 1 %] | [Messung auf Zielsystem] |
|
||||
| Worst-Case Timing | [z.B. 200 us / Aufruf init()] | [Messung HiL] |
|
||||
|
||||
## 6. Fehlerverhalten
|
||||
|
||||
| Fehlerfall | Erkennung | Reaktion |
|
||||
|-----------------------|-------------------|---------------------------|
|
||||
| Ungueltige Konfig | Parameter-Check | Status STATUS_EINVAL |
|
||||
| HW-Timeout | Timer | Retry, dann STATUS_TIMEOUT |
|
||||
| Buffer voll | Check vor Schreiben | STATUS_NOSPACE |
|
||||
|
||||
## 7. Designentscheidungen
|
||||
|
||||
| Entscheidung | Alternative(n) | Begruendung |
|
||||
|------------------------|------------------|--------------------------|
|
||||
| [z.B. statische Allokation] | [Heap] | [deterministisch, MISRA] |
|
||||
| [Lock-Strategie] | [Mutex / lock-free] | [Begruendung] |
|
||||
|
||||
## 8. Mapping auf Anforderungen
|
||||
|
||||
| Anforderung | Wie abgedeckt | Verifikations-Test |
|
||||
|---------------|----------------------------------------------|----------------------------|
|
||||
| SWE-XXX | [welcher Teil dieser Komponente erfuellt es] | TST-UNIT-XXX, TST-INT-YYY |
|
||||
| SWE-YYY | [...] | TST-UNIT-YYY |
|
||||
|
||||
Jede in den `links` referenzierte SWE-Anforderung muss in dieser Tabelle einen Eintrag haben.
|
||||
|
||||
## 9. Detail-Design
|
||||
|
||||
Detail-Design (ASPICE SWE.3) wird ab ASIL-C separat in `arch/swd/SWD-XXX.md` gefuehrt.
|
||||
Fuer ASIL-A/B und QM ist Code + Header-Kommentare ausreichend.
|
||||
|
||||
---
|
||||
|
||||
*Aenderungen an diesem Architektur-Element gehen per PR mit mind. 2 Technical-Review-Approvals (siehe SWE-Plan).*
|
||||
@@ -0,0 +1,132 @@
|
||||
# Software Development Plan (SWE-Plan)
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------|-------------------------------|
|
||||
| Projekt | [Projektname] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Entwurf / Freigegeben] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Entwicklungsmethode
|
||||
|
||||
[Beschreibung der Vorgehensweise: iterativ, V-Modell-angelehnt, oder hybrid.]
|
||||
|
||||
Grundstruktur folgt dem V-Modell (ISO 26262 Part 6):
|
||||
- Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung
|
||||
- Rechte Seite: Unit Test → Integrations-Test → System-Test
|
||||
- Iterationen innerhalb der Phasen moeglich
|
||||
|
||||
Aenderungen werden ueber Change Requests gesteuert (siehe PM-Plan).
|
||||
|
||||
## 2. Programmiersprache und Standards
|
||||
|
||||
| Aspekt | Festlegung |
|
||||
|---------------------|-----------------------------------------------------|
|
||||
| Sprache | [C (C99/C11) / C++ (C++14/17) / Rust] |
|
||||
| Coding Standard | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023] |
|
||||
| Projekt-Guidelines | [Verweis auf Coding-Guidelines im Wiki] |
|
||||
| Namenskonvention | [z.B. snake_case fuer Funktionen, UPPER_CASE fuer Makros] |
|
||||
|
||||
### MISRA-Handhabung
|
||||
|
||||
- Alle Required- und Mandatory-Regeln werden eingehalten
|
||||
- Advisory-Regeln: Liste der angewendeten Regeln im Wiki dokumentiert
|
||||
- Abweichungen werden per MISRA Deviation Record dokumentiert
|
||||
- Projektweite Abweichungen per MISRA Deviation Permit genehmigt
|
||||
- MISRA-Pruefung laeuft automatisch in der CI-Pipeline
|
||||
|
||||
## 3. Build-Umgebung
|
||||
|
||||
| Komponente | Tool / Version |
|
||||
|--------------------|-----------------------------------------------------|
|
||||
| Build-System | [CMake X.Y / SCons X.Y / Make] |
|
||||
| Compiler | [GCC ARM X.Y / Clang X.Y] |
|
||||
| Zielplattform | [z.B. ARM Cortex-R5, Cortex-M4] |
|
||||
| Host-Plattform | [Linux x86_64 / macOS ARM64] |
|
||||
| CI-Runner | [GitLab Runner, Docker Image: ...] |
|
||||
|
||||
Build-Umgebung ist reproduzierbar: entweder per Docker-Image oder per dokumentierter Toolchain-Installation.
|
||||
|
||||
## 4. Branching-Strategie
|
||||
|
||||
```
|
||||
main — Stabiler, freigegebener Stand
|
||||
develop — Aktueller Entwicklungsstand
|
||||
feature/SWR-XXX — Feature-Branch pro Anforderung
|
||||
bugfix/BUG-XXX — Bugfix-Branch
|
||||
release/vX.Y — Release-Vorbereitung
|
||||
hotfix/vX.Y.Z — Kritische Fixes nach Release
|
||||
```
|
||||
|
||||
- Feature-Branches von `develop` abzweigen
|
||||
- Merge nach `develop` nur per MR mit Approval
|
||||
- `main` und `release/*` sind geschuetzt (kein direkter Push)
|
||||
- Branch-Name enthaelt Issue-Nummer
|
||||
|
||||
Details: siehe `gitlab-aspice-setup.md`.
|
||||
|
||||
## 5. Review-Verpflichtungen
|
||||
|
||||
| Artefakt | Review-Art | Mindest-Approvals |
|
||||
|-----------------------------|-------------------|--------------------|
|
||||
| Quellcode (MR) | Peer Review | 1 |
|
||||
| Safety-relevanter Code | Technical Review | 2 |
|
||||
| Architektur-Dokument | Technical Review | 2 |
|
||||
| Anforderungen | Technical Review | 1 |
|
||||
| Testfaelle | Peer Review | 1 |
|
||||
|
||||
Jeder MR muss vor dem Merge reviewed und approved sein. Self-Merges sind nicht erlaubt (Ausnahme: 1-Person-Projekt mit dokumentiertem Self-Review).
|
||||
|
||||
## 6. Definition of Done
|
||||
|
||||
Ein Feature / eine Anforderung gilt als "Done" wenn:
|
||||
|
||||
- [ ] Code ist implementiert und kompiliert fehlerfrei
|
||||
- [ ] MISRA-Check in CI ist gruen (keine neuen Violations)
|
||||
- [ ] Static Analysis (Cppcheck, clang-tidy) hat keine neuen Findings
|
||||
- [ ] Unit Tests sind geschrieben und gruen
|
||||
- [ ] Coverage-Ziel ist erreicht (siehe Abschnitt 8)
|
||||
- [ ] MR ist reviewed und approved
|
||||
- [ ] Anforderung ist mit Test verlinkt (Traceability)
|
||||
- [ ] Dokumentation ist aktualisiert (falls betroffen)
|
||||
|
||||
## 7. Integration und Test-Strategie
|
||||
|
||||
| Teststufe | Verantwortlich | Umgebung | Automatisierung |
|
||||
|---------------------|----------------|----------------|-----------------|
|
||||
| Unit Test | Entwickler | Host (x86) | CI-Pipeline |
|
||||
| Integrations-Test | Entwickler | Host / SiL | CI / manuell |
|
||||
| System-Test | Test / QA | SiL / HiL | teilweise |
|
||||
| Abnahme-Test | Auftraggeber | HiL / Fahrzeug | manuell |
|
||||
|
||||
- Unit Tests laufen auf Host-Plattform (Cross-Compilation fuer Tests auf x86)
|
||||
- Integrationstests pruefen Zusammenspiel der Module
|
||||
- System-Tests pruefen gegen System-Anforderungen
|
||||
- HiL-Tests werden vom Auftraggeber bereitgestellt oder gemeinsam definiert
|
||||
|
||||
## 8. Coverage-Ziele
|
||||
|
||||
| ASIL | Statement Coverage | Branch Coverage | MC/DC |
|
||||
|------|--------------------|-----------------|----------|
|
||||
| QM | >= 80% empfohlen | — | — |
|
||||
| A | >= 80% | empfohlen | — |
|
||||
| B | >= 80% | >= 80% | — |
|
||||
| C | >= 90% | >= 80% | empfohlen|
|
||||
| D | >= 90% | >= 90% | >= 80% |
|
||||
|
||||
Konkrete Zielwerte fuer dieses Projekt:
|
||||
|
||||
| Metrik | Zielwert |
|
||||
|---------------------|------------|
|
||||
| Statement Coverage | >= [X]% |
|
||||
| Branch Coverage | >= [X]% |
|
||||
| MC/DC | >= [X]% (falls anwendbar) |
|
||||
|
||||
Coverage wird in der CI gemessen und als Artefakt archiviert. Abweichungen vom Ziel werden begruendet und im QA-Report dokumentiert.
|
||||
|
||||
---
|
||||
|
||||
*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*
|
||||
@@ -0,0 +1,121 @@
|
||||
# Testplan
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------|-------------------------------|
|
||||
| Projekt | [Projektname] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Entwurf / Freigegeben] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
| Bezug | SWE-Plan Version [X.Y] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Testziele
|
||||
|
||||
- Nachweis, dass die Software die spezifizierten Anforderungen erfuellt
|
||||
- Nachweis der strukturellen Code-Abdeckung gemaess ASIL-Vorgaben
|
||||
- Nachweis der Robustheit gegenueber Fehlbedienung und Grenzwerten
|
||||
- Identifikation von Defekten vor der Integration / Auslieferung
|
||||
|
||||
## 2. Teststrategie
|
||||
|
||||
| Teststufe | Testziel | Methode | Automatisierung |
|
||||
|---------------------|---------------------------------------------|------------------|-----------------|
|
||||
| Unit Test | Einzelne Funktionen / Module korrekt | White-Box | CI (automatisch)|
|
||||
| Integrations-Test | Zusammenspiel der Module | Grey-Box | CI / SiL |
|
||||
| System-Test | Erfuellung der System-Anforderungen | Black-Box | SiL / HiL |
|
||||
| Regressionstest | Keine Seiteneffekte durch Aenderungen | Automatisiert | CI |
|
||||
|
||||
### Unit Tests
|
||||
|
||||
- Framework: [CppUTest / Google Test / Unity+CMock]
|
||||
- Laufen auf Host-Plattform (x86)
|
||||
- Jede Anforderung hat mindestens einen zugehoerigen Testfall
|
||||
- Negative Tests und Grenzwerte sind Pflicht
|
||||
|
||||
### Integrationstests
|
||||
|
||||
- Pruefen Schnittstellen zwischen Modulen
|
||||
- Laufen auf Host oder SiL-Umgebung
|
||||
- Kommunikationsschnittstellen (CAN, SPI, UART) werden per Mock oder Simulator getestet
|
||||
|
||||
### System-Tests
|
||||
|
||||
- Pruefen gegen System-Anforderungen
|
||||
- Laufen auf SiL oder HiL
|
||||
- Testfaelle werden aus System-Requirements abgeleitet
|
||||
|
||||
## 3. Coverage-Ziele
|
||||
|
||||
| Metrik | Zielwert | Messung |
|
||||
|---------------------|----------------|------------------|
|
||||
| Statement Coverage | >= [X]% | gcov/lcov |
|
||||
| Branch Coverage | >= [X]% | gcov/lcov |
|
||||
| MC/DC | >= [X]% (falls anwendbar) | MCDC-Star / kommerziell |
|
||||
|
||||
Referenz: ISO 26262 Part 6, Table 9.
|
||||
|
||||
| ASIL | Statement | Branch | MC/DC |
|
||||
|------|-----------|---------|--------------|
|
||||
| QM | empfohlen | — | — |
|
||||
| A | Pflicht | empfohlen | — |
|
||||
| B | Pflicht | Pflicht | — |
|
||||
| C | Pflicht | Pflicht | empfohlen |
|
||||
| D | Pflicht | Pflicht | Pflicht |
|
||||
|
||||
## 4. Testumgebung
|
||||
|
||||
| Komponente | Beschreibung |
|
||||
|---------------------|----------------------------------------------------|
|
||||
| Host-Plattform | [Linux x86_64 / macOS ARM64] |
|
||||
| Cross-Compiler | [GCC ARM X.Y] |
|
||||
| Test-Framework | [CppUTest / Google Test / Unity] |
|
||||
| SiL-Framework | [Python + pytest, Kommunikation: UART/CAN/TCP] |
|
||||
| HiL-System | [dSPACE Scalexio / vom Kunden gestellt / entfaellt] |
|
||||
| CI-Runner | [GitLab Runner, Docker Image: ...] |
|
||||
|
||||
## 5. Testdaten
|
||||
|
||||
- Testdaten werden im Repository unter `tests/data/` versioniert
|
||||
- Grenzwerte aus Anforderungen ableiten
|
||||
- Ungueltige Eingaben explizit testen
|
||||
- Testdaten fuer Regressionen aus Bug-Reports ableiten
|
||||
|
||||
## 6. Pass/Fail-Kriterien
|
||||
|
||||
### Einzelner Testfall
|
||||
|
||||
- **Pass:** Erwartetes Ergebnis stimmt mit tatsaechlichem ueberein
|
||||
- **Fail:** Abweichung vom erwarteten Ergebnis
|
||||
|
||||
### Teststufe gesamt
|
||||
|
||||
| Kriterium | Bedingung fuer Pass |
|
||||
|----------------------------------------|----------------------------------------|
|
||||
| Alle Testfaelle ausgefuehrt | Ja |
|
||||
| Alle Testfaelle bestanden | Ja (oder Fails bewertet und genehmigt) |
|
||||
| Coverage-Ziel erreicht | Ja |
|
||||
| Keine offenen Critical Findings | Ja |
|
||||
| Traceability vollstaendig | Jede Anforderung hat mindestens einen Test |
|
||||
|
||||
Fehlgeschlagene Tests, die nicht behoben werden, muessen per Non-Conformity oder Change Request dokumentiert und bewertet werden.
|
||||
|
||||
## 7. Traceability
|
||||
|
||||
Jeder Testfall muss auf mindestens eine Anforderung rueckfuehrbar sein.
|
||||
|
||||
```
|
||||
Anforderung (GitLab Issue, Label: req::software)
|
||||
→ Testfall (GitLab Issue, Label: test::unit / test::integration / test::system)
|
||||
→ Testergebnis (CI-Artefakt / JUnit-XML)
|
||||
```
|
||||
|
||||
Umsetzung:
|
||||
- Testfall-Issue verlinkt auf Anforderungs-Issue ("relates to" oder "verified by")
|
||||
- Im Testcode: Kommentar mit Anforderungs-ID (`// Verifies: SWR-042`)
|
||||
- Traceability-Report wird per Skript aus GitLab API generiert
|
||||
|
||||
---
|
||||
|
||||
*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*
|
||||
@@ -0,0 +1,67 @@
|
||||
# Traceability-Matrix
|
||||
|
||||
## Prinzip
|
||||
|
||||
Die Traceability-Matrix stellt die Rueckverfolgbarkeit von der Anforderung bis zum Test sicher:
|
||||
|
||||
```
|
||||
System-Anforderung → Software-Anforderung → Architektur-Element → Implementierung (MR/Datei) → Testfall → Testergebnis
|
||||
```
|
||||
|
||||
Jede Ebene muss bidirektional verfolgbar sein:
|
||||
- **Vorwaerts:** Anforderung → wurde sie implementiert und getestet?
|
||||
- **Rueckwaerts:** Testfall → welche Anforderung verifiziert er?
|
||||
|
||||
## Tabellenstruktur
|
||||
|
||||
| Sys-Req | SW-Req | ASIL | Arch-Element | Implementierung | Testfall | Test-Ergebnis | Status |
|
||||
|---------|---------|------|--------------|----------------------|----------|---------------|--------------|
|
||||
| SYR-001 | SWR-010 | B | MOD-Timer | MR !23, timer.c | TC-010 | Pass (v1.2) | Vollstaendig |
|
||||
| SYR-001 | SWR-011 | B | MOD-Timer | MR !23, timer.c | TC-011 | Pass (v1.2) | Vollstaendig |
|
||||
| SYR-002 | SWR-020 | A | MOD-CAN | MR !31, can_driver.c | TC-020 | Pass (v1.2) | Vollstaendig |
|
||||
| SYR-003 | SWR-030 | B | MOD-Watchdog | — | — | — | Offen |
|
||||
| — | SWR-040 | QM | MOD-Diag | MR !35, diag.c | TC-040 | Fail (v1.1) | Finding offen|
|
||||
|
||||
## Spalten-Erklaerung
|
||||
|
||||
| Spalte | Beschreibung |
|
||||
|------------------|----------------------------------------------------------------|
|
||||
| Sys-Req | System-Anforderungs-ID (GitLab Issue mit Label `req::system`) |
|
||||
| SW-Req | Software-Anforderungs-ID (GitLab Issue mit Label `req::software`) |
|
||||
| ASIL | Zugewiesener ASIL-Level |
|
||||
| Arch-Element | Architektur-Modul oder -Komponente |
|
||||
| Implementierung | Merge Request und/oder Datei |
|
||||
| Testfall | Testfall-ID (GitLab Issue mit Label `test::*`) |
|
||||
| Test-Ergebnis | Pass/Fail mit Version/Datum |
|
||||
| Status | Vollstaendig / Offen / Finding offen |
|
||||
|
||||
## Lueckenanalyse
|
||||
|
||||
Die Matrix macht Luecken sichtbar:
|
||||
|
||||
- **Anforderung ohne Test:** Zeile ohne Testfall-Eintrag → Test fehlt
|
||||
- **Anforderung ohne Implementierung:** Zeile ohne MR → nicht implementiert
|
||||
- **Test ohne Anforderung:** Testfall der keiner Anforderung zugeordnet ist → ueberpruefen
|
||||
- **Fail ohne Finding:** Fehlgeschlagener Test ohne dokumentiertes Finding → nacharbeiten
|
||||
|
||||
## Automatische Generierung aus GitLab
|
||||
|
||||
Diese Matrix kann aus GitLab-Issues automatisch generiert werden:
|
||||
|
||||
1. Python-Skript liest ueber GitLab API alle Issues mit `req::*`-Labels
|
||||
2. Folgt Issue-Links zu Architektur-Issues, MRs und Test-Issues
|
||||
3. Liest CI-Pipeline-Ergebnisse (JUnit-XML) fuer Testergebnisse
|
||||
4. Erzeugt die Matrix als Markdown-Tabelle oder CSV
|
||||
|
||||
**Voraussetzung:** Issues sind korrekt verlinkt und gelabelt (siehe `gitlab-aspice-setup.md`).
|
||||
|
||||
**Ausgabe-Formate:**
|
||||
- Markdown (fuer Wiki / Dokumentation)
|
||||
- CSV (fuer Import in Kundensysteme)
|
||||
- HTML (fuer Reporting)
|
||||
|
||||
Ein Beispiel-Skript liegt unter `tools/traceability-report.py` im Projekt-Repository.
|
||||
|
||||
---
|
||||
|
||||
*Die aktuelle Traceability-Matrix wird bei jedem Release aktualisiert und im Wiki abgelegt.*
|
||||
@@ -0,0 +1,144 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>Angebot: Accessibility Audit – slohmaier Engineering</title>
|
||||
<style>
|
||||
:root {
|
||||
--text: #111417;
|
||||
--text-light: #525c69;
|
||||
--border: #d0d5dd;
|
||||
--bg: #ffffff;
|
||||
color-scheme: light dark;
|
||||
}
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--text: #f0f2f4;
|
||||
--text-light: #9ca3af;
|
||||
--border: #2a2e33;
|
||||
--bg: #111417;
|
||||
}
|
||||
.logo-light { display: none !important; }
|
||||
.logo-dark { display: block !important; }
|
||||
}
|
||||
@media (prefers-color-scheme: light) {
|
||||
.logo-dark { display: none !important; }
|
||||
.logo-light { display: block !important; }
|
||||
}
|
||||
body {
|
||||
font-family: Aptos, Inter, -apple-system, Helvetica Neue, Arial, sans-serif;
|
||||
font-size: 16px;
|
||||
line-height: 1.65;
|
||||
color: var(--text);
|
||||
background: var(--bg);
|
||||
max-width: 820px;
|
||||
margin: 0 auto;
|
||||
padding: 48px 40px;
|
||||
}
|
||||
.logo img { width: 280px; height: auto; margin-bottom: 32px; display: block; }
|
||||
h1 { font-size: 2rem; font-weight: 700; margin-top: 0; }
|
||||
h2 { font-size: 1.2rem; font-weight: 600; border-bottom: 1px solid var(--border); padding-bottom: 6px; margin-top: 40px; }
|
||||
h3 { font-size: 1rem; font-weight: 600; margin-top: 24px; }
|
||||
hr { border: none; border-top: 1px solid var(--border); margin: 32px 0; }
|
||||
table { width: 100%; border-collapse: collapse; font-size: 0.95rem; }
|
||||
th { text-align: left; border-bottom: 2px solid var(--border); padding: 8px 12px; font-weight: 600; }
|
||||
td { border-bottom: 1px solid var(--border); padding: 8px 12px; color: var(--text-light); }
|
||||
p { color: var(--text); }
|
||||
ul { color: var(--text-light); }
|
||||
strong { color: var(--text); }
|
||||
ol li { margin-bottom: 4px; }
|
||||
.meta { color: var(--text-light); font-size: 0.95rem; }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<div class="logo">
|
||||
<img src="https://slohmaier.com/branding/logo-doc-light.svg" alt="slohmaier" class="logo-light" />
|
||||
<img src="https://slohmaier.com/branding/logo-doc-dark.svg" alt="slohmaier" class="logo-dark" />
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
|
||||
<h1>Angebot: Accessibility Audit</h1>
|
||||
|
||||
<p class="meta">
|
||||
<strong>Datum:</strong> 03.04.2026
|
||||
<strong>Version:</strong> 1.0<br>
|
||||
<strong>Projekt:</strong> Accessibility Review – DemoApp v2.3<br>
|
||||
<strong>Auftraggeber:</strong> Acme GmbH, Berlin
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<h2>Zusammenfassung</h2>
|
||||
<p>Dieses Angebot beschreibt den Umfang und die Konditionen für einen Accessibility Audit der Windows-Desktop-Anwendung DemoApp v2.3, mit Fokus auf NVDA-Screenreader-Kompatibilität.</p>
|
||||
|
||||
<h2>Inhalt</h2>
|
||||
|
||||
<h3>1. Ziel</h3>
|
||||
<p>Prüfung der Anwendung auf Bedienbarkeit mit NVDA (Windows) sowie Identifikation und Beschreibung konkreter Accessibility-Mängel mit Handlungsempfehlungen.</p>
|
||||
|
||||
<h3>2. Umfang</h3>
|
||||
<ul>
|
||||
<li>Vollständiger Durchgang aller Hauptdialoge und Workflows mit NVDA</li>
|
||||
<li>Prüfung auf UIA-Baumstruktur und korrekte Rollen/Namen/Beschreibungen</li>
|
||||
<li>Dokumentation aller Befunde mit Reproduktionsschritten und Schweregrad</li>
|
||||
<li>Priorisierte Handlungsempfehlungen</li>
|
||||
</ul>
|
||||
<p><strong>Nicht enthalten:</strong> Implementierung von Korrekturen, Regressionstesting nach Fixes.</p>
|
||||
|
||||
<h3>3. Anforderungen</h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>Nr.</th><th>Anforderung</th><th>Priorität</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>1</td><td>Vollständige NVDA-Bedienbarkeit aller Workflows</td><td>Muss</td></tr>
|
||||
<tr><td>2</td><td>UIA-konforme Benennung aller Steuerelemente</td><td>Muss</td></tr>
|
||||
<tr><td>3</td><td>Tastaturnavigation ohne Maus</td><td>Muss</td></tr>
|
||||
<tr><td>4</td><td>Logische Fokusreihenfolge</td><td>Soll</td></tr>
|
||||
<tr><td>5</td><td>Kontraste mind. WCAG 2.1 AA</td><td>Soll</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3>4. Vorgehen</h3>
|
||||
<ol>
|
||||
<li>Einrichtung der Testumgebung (Windows 11, NVDA 2024.4)</li>
|
||||
<li>Manueller Test aller Hauptdialoge und Workflows</li>
|
||||
<li>UIA-Dump-Analyse mit dumpUIA</li>
|
||||
<li>Dokumentation der Befunde</li>
|
||||
<li>Übergabe Auditbericht als PDF</li>
|
||||
</ol>
|
||||
<p>Geschätzte Dauer: <strong>3 Werktage</strong></p>
|
||||
|
||||
<h3>5. Offene Punkte</h3>
|
||||
<ul>
|
||||
<li>Übergabe Testversion der Anwendung</li>
|
||||
<li>Zugang zu Testdaten für repräsentative Workflows</li>
|
||||
</ul>
|
||||
|
||||
<h3>6. Lieferergebnis</h3>
|
||||
<p>Auditbericht (PDF) mit:</p>
|
||||
<ul>
|
||||
<li>Zusammenfassung und Gesamtbewertung</li>
|
||||
<li>Vollständige Befundliste mit Schweregrad, Screenshot, Reproduktionsschritten</li>
|
||||
<li>Priorisierte Handlungsempfehlungen</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<h2>Konditionen</h2>
|
||||
<p>
|
||||
Tagessatz: auf Anfrage<br>
|
||||
Zahlungsziel: 14 Tage nach Rechnungsstellung<br>
|
||||
Gültig bis: 17.04.2026
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<p><strong>Stefan Lohmaier</strong><br>
|
||||
slohmaier.com · stefan@slohmaier.de</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,76 @@
|
||||
<!-- slohmaier Engineering – Angebotsvorlage -->
|
||||
<!-- Verwendung: Platzhalter {{ ... }} ersetzen, dann mit pandoc exportieren -->
|
||||
<!-- Export: pandoc angebot.md -o angebot.html --standalone -->
|
||||
<!-- Beispiel: angebot-beispiel.html -->
|
||||
|
||||
<div class="logo">
|
||||
<img src="https://slohmaier.com/branding/logo-doc-light.svg" alt="slohmaier" class="logo-light" />
|
||||
<img src="https://slohmaier.com/branding/logo-doc-dark.svg" alt="slohmaier" class="logo-dark" />
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# Angebot: {{ Titel }}
|
||||
|
||||
**Datum:** {{ datum }}
|
||||
**Version:** 1.0
|
||||
**Projekt:** {{ projektname }}
|
||||
**Auftraggeber:** {{ auftraggeber }}
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
{{ Kurze Beschreibung was angeboten wird }}
|
||||
|
||||
---
|
||||
|
||||
## Inhalt
|
||||
|
||||
### 1. Ziel
|
||||
|
||||
{{ Was soll erreicht werden? }}
|
||||
|
||||
### 2. Umfang
|
||||
|
||||
{{ Was ist enthalten? Aufzaehlung der Leistungen }}
|
||||
|
||||
**Nicht enthalten:** {{ Was ist explizit ausgeschlossen? }}
|
||||
|
||||
### 3. Anforderungen
|
||||
|
||||
| Nr. | Anforderung | Prioritaet |
|
||||
|-----|-------------|------------|
|
||||
| 1 | ... | Muss |
|
||||
| 2 | ... | Soll |
|
||||
| 3 | ... | Kann |
|
||||
|
||||
### 4. Vorgehen
|
||||
|
||||
1. {{ Schritt 1 }}
|
||||
2. {{ Schritt 2 }}
|
||||
3. {{ Schritt 3 }}
|
||||
|
||||
Geschaetzte Dauer: **{{ Dauer }}**
|
||||
|
||||
### 5. Offene Punkte
|
||||
|
||||
- [ ] {{ Voraussetzung 1 }}
|
||||
- [ ] {{ Voraussetzung 2 }}
|
||||
|
||||
### 6. Lieferergebnis
|
||||
|
||||
{{ Was wird am Ende geliefert? Format, Umfang }}
|
||||
|
||||
---
|
||||
|
||||
**Konditionen**
|
||||
|
||||
Tagessatz: auf Anfrage
|
||||
Zahlungsziel: 14 Tage nach Rechnungsstellung
|
||||
Gueltig bis: {{ datum + 14 Tage }}
|
||||
|
||||
---
|
||||
|
||||
**Stefan Lohmaier**
|
||||
slohmaier.com · stefan@slohmaier.de
|
||||
Reference in New Issue
Block a user