feat(i18n): dev-process repo in English
- README.md: full English rewrite - All 13 vorlagen MD templates hand-translated: PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan, SA, SWA, Review-Protokoll, Non-Conformity, MISRA-Deviation-Permit, MISRA-Deviation-Record, Traceability-Matrix, angebot (quotation) - Master Word template (slohmaier-doc-template.docx) regenerated in English: cover page, document control, TOC headers, classification banner all English - All derived Word vorlagen regenerated from English MD sources Still to translate: toolstack.md, gitea-aspice-setup.md
This commit is contained in:
Stefan Lohmaier
@@ -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.*
|
||||
|
||||
@@ -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.*
|
||||
|
||||
@@ -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`).*
|
||||
|
||||
+52
-62
@@ -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.*
|
||||
|
||||
+48
-86
@@ -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.*
|
||||
|
||||
@@ -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/.*
|
||||
|
||||
+55
-55
@@ -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).*
|
||||
|
||||
+71
-72
@@ -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).*
|
||||
|
||||
@@ -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.*
|
||||
|
||||
@@ -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.*
|
||||
|
||||
@@ -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.*
|
||||
|
||||
+34
-34
@@ -1,7 +1,7 @@
|
||||
<!-- slohmaier Engineering – Angebotsvorlage -->
|
||||
<!-- Verwendung: Platzhalter {{ ... }} ersetzen, dann mit pandoc exportieren -->
|
||||
<!-- slohmaier Engineering – Quotation template -->
|
||||
<!-- Use: replace {{ ... }} placeholders, then export with pandoc -->
|
||||
<!-- Export: pandoc angebot.md -o angebot.html --standalone -->
|
||||
<!-- Beispiel: angebot-beispiel.html -->
|
||||
<!-- Example: angebot-beispiel.html -->
|
||||
|
||||
<div class="logo">
|
||||
<img src="https://slohmaier.com/branding/logo-doc-light.svg" alt="slohmaier" class="logo-light" />
|
||||
@@ -10,65 +10,65 @@
|
||||
|
||||
---
|
||||
|
||||
# Angebot: {{ Titel }}
|
||||
# Quotation: {{ title }}
|
||||
|
||||
**Datum:** {{ datum }}
|
||||
**Date:** {{ date }}
|
||||
**Version:** 1.0
|
||||
**Projekt:** {{ projektname }}
|
||||
**Auftraggeber:** {{ auftraggeber }}
|
||||
**Project:** {{ project name }}
|
||||
**Client:** {{ client }}
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
## Summary
|
||||
|
||||
{{ Kurze Beschreibung was angeboten wird }}
|
||||
{{ Short description of what is being offered }}
|
||||
|
||||
---
|
||||
|
||||
## Inhalt
|
||||
## Content
|
||||
|
||||
### 1. Ziel
|
||||
### 1. Goal
|
||||
|
||||
{{ Was soll erreicht werden? }}
|
||||
{{ What is to be achieved? }}
|
||||
|
||||
### 2. Umfang
|
||||
### 2. Scope
|
||||
|
||||
{{ Was ist enthalten? Aufzaehlung der Leistungen }}
|
||||
{{ What is included? List of services }}
|
||||
|
||||
**Nicht enthalten:** {{ Was ist explizit ausgeschlossen? }}
|
||||
**Not included:** {{ What is explicitly excluded? }}
|
||||
|
||||
### 3. Anforderungen
|
||||
### 3. Requirements
|
||||
|
||||
| Nr. | Anforderung | Prioritaet |
|
||||
| # | Requirement | Priority |
|
||||
|-----|-------------|------------|
|
||||
| 1 | ... | Muss |
|
||||
| 2 | ... | Soll |
|
||||
| 3 | ... | Kann |
|
||||
| 1 | ... | Must |
|
||||
| 2 | ... | Should |
|
||||
| 3 | ... | Could |
|
||||
|
||||
### 4. Vorgehen
|
||||
### 4. Approach
|
||||
|
||||
1. {{ Schritt 1 }}
|
||||
2. {{ Schritt 2 }}
|
||||
3. {{ Schritt 3 }}
|
||||
1. {{ Step 1 }}
|
||||
2. {{ Step 2 }}
|
||||
3. {{ Step 3 }}
|
||||
|
||||
Geschaetzte Dauer: **{{ Dauer }}**
|
||||
Estimated duration: **{{ duration }}**
|
||||
|
||||
### 5. Offene Punkte
|
||||
### 5. Open items
|
||||
|
||||
- [ ] {{ Voraussetzung 1 }}
|
||||
- [ ] {{ Voraussetzung 2 }}
|
||||
- [ ] {{ Precondition 1 }}
|
||||
- [ ] {{ Precondition 2 }}
|
||||
|
||||
### 6. Lieferergebnis
|
||||
### 6. Deliverable
|
||||
|
||||
{{ Was wird am Ende geliefert? Format, Umfang }}
|
||||
{{ What is delivered at the end? Format, scope }}
|
||||
|
||||
---
|
||||
|
||||
**Konditionen**
|
||||
**Terms**
|
||||
|
||||
Tagessatz: auf Anfrage
|
||||
Zahlungsziel: 14 Tage nach Rechnungsstellung
|
||||
Gueltig bis: {{ datum + 14 Tage }}
|
||||
Day rate: on request
|
||||
Payment terms: 14 days from invoice date
|
||||
Valid until: {{ date + 14 days }}
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user