Initial commit: demo-epb v1.0 — Elektrische Parkbremse Demo
Vollstaendige Demo des slohmaier Dev Process anhand einer EPB-Steuergeraet- Software. Zeigt ASPICE 4.0 / ISO 26262-konforme Entwicklung im Monorepo. Inhalte: - 5 Plaene (PID, PM-, QA-, SWE-, Test-Plan) in Word, ausgefuellt mit EPB-spezifischen Inhalten - 10 System-Anforderungen + 25 Software-Anforderungen (Doorstop-MD) - 5 System-Architektur-Elemente + 10 Software-Architektur-Elemente mit PlantUML-Diagrammen und vollstaendigem Mapping - 3 implementierte Komponenten (Apply Controller D, Actuator Driver B, Switch Debouncer QM) plus 7 Header-Stubs - 28 Unit-Tests, alle gruen, mit Coverage- und MISRA-Build-Targets - Audit-Artefakte: 1 Review-Protokoll, 1 Non-Conformity, 1 MISRA-Record - Gitea-Actions-CI-Pipeline (validate.yml) - Doorstop-Konfiguration fuer bidirektionale Traceability - Generator-Skript fuer alle 50 Reqs/Arch-Elemente aus Strukturdaten - README mit gefuehrter Tour fuer Prospects
This commit is contained in:
Stefan Lohmaier
@@ -0,0 +1,114 @@
|
||||
# Software Development Plan (SWE-Plan)
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------|--------------------------------------|
|
||||
| Projekt | demo-epb |
|
||||
| Datum | 2026-05-11 |
|
||||
| Version | 1.0 |
|
||||
| Status | Freigegeben |
|
||||
| ASIL | D (hoechste Komponente) |
|
||||
|
||||
---
|
||||
|
||||
## 1. Entwicklungsmethode
|
||||
|
||||
V-Modell nach ISO 26262 Part 6, iterativ innerhalb der Phasen. Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung. Rechte Seite: Unit-Test → Integrationstest → Systemtest.
|
||||
|
||||
Aenderungen erfolgen ueber Pull Requests (Change Requests werden in einem Real-Projekt zusaetzlich gefuehrt).
|
||||
|
||||
## 2. Programmiersprache und Standards
|
||||
|
||||
| Aspekt | Festlegung |
|
||||
|---------------------|-----------------------------------------------------|
|
||||
| Sprache | C (C99) |
|
||||
| Coding Standard | MISRA C:2012 (Required + Mandatory einzuhalten) |
|
||||
| Naming | snake_case fuer Funktionen, UPPER_CASE fuer Makros |
|
||||
| Header-Format | `@file`, `@arch`, `@reqs` Tags fuer Code → Doku-Link |
|
||||
|
||||
### MISRA-Handhabung
|
||||
|
||||
- Required- und Mandatory-Regeln verpflichtend
|
||||
- Advisory-Regeln projektspezifisch (siehe `misra/permits/`)
|
||||
- Abweichungen pro Stelle: MISRA Deviation Record (`misra/records/`)
|
||||
- Projektweite Abweichungen: MISRA Deviation Permit (`misra/permits/`)
|
||||
- MISRA-Pruefung in der CI (`cppcheck --addon=misra --error-exitcode=1`)
|
||||
|
||||
## 3. Build-Umgebung
|
||||
|
||||
| Komponente | Tool / Version |
|
||||
|--------------------|-----------------------------------------------------|
|
||||
| Build-System | CMake 3.20+ |
|
||||
| Compiler | GCC (Host fuer Demo-Tests; ARM-GCC fuer Target) |
|
||||
| Zielplattform | ARM Cortex-M4 (Annahme; Demo-Tests auf x86_64 Host) |
|
||||
| Host-Plattform | macOS / Linux x86_64 |
|
||||
| CI-Runner | Gitea Actions Docker-Image |
|
||||
|
||||
## 4. Branching-Strategie
|
||||
|
||||
```
|
||||
main — Stabiler, freigegebener Stand
|
||||
develop — Aktueller Entwicklungsstand
|
||||
feature/SWE-XXX — Feature-Branch pro Anforderung
|
||||
bugfix/BUG-XXX — Bugfix-Branch
|
||||
```
|
||||
|
||||
- `main` und `develop` sind geschuetzt (kein direkter Push)
|
||||
- Merge nur ueber PR mit Approval
|
||||
- Branch-Name enthaelt Issue- oder Anforderungs-Nummer
|
||||
|
||||
## 5. Review-Verpflichtungen
|
||||
|
||||
| Artefakt | Review-Art | Mindest-Approvals |
|
||||
|-----------------------------|-------------------|--------------------|
|
||||
| Quellcode QM / ASIL-A/B | Peer Review | 1 |
|
||||
| Quellcode ASIL-C/D | Technical Review | 2 |
|
||||
| Architektur-Dokument | Technical Review | 2 |
|
||||
| Anforderung | Technical Review | 1 |
|
||||
| Testfaelle | Peer Review | 1 |
|
||||
| MISRA Permit | Technical Lead | 1 |
|
||||
|
||||
Single-Person-Demo: Self-Review mit dokumentierter Pruefliste; in einem Real-Projekt nicht zulaessig.
|
||||
|
||||
## 6. Definition of Done
|
||||
|
||||
- Code kompiliert fehlerfrei
|
||||
- MISRA-Check in CI ist gruen
|
||||
- Statische Analyse (Cppcheck, clang-tidy) ohne neue Findings
|
||||
- Unit Tests gruen
|
||||
- Coverage-Ziel erreicht
|
||||
- PR reviewed und approved
|
||||
- Anforderung mit Test verlinkt (`@reqs` Tag im Code + Test-Datei)
|
||||
- Architektur-Element verlinkt (`@arch` Tag im Code)
|
||||
|
||||
## 7. Integration und Test-Strategie
|
||||
|
||||
| Teststufe | Verantwortlich | Umgebung | Automatisierung |
|
||||
|---------------------|----------------|----------------|-----------------|
|
||||
| Unit Test | Entwickler | Host (x86) | CI |
|
||||
| Integrationstest | Entwickler | Host / SiL | CI / manuell |
|
||||
| Systemtest | QA | SiL / HiL | teilweise |
|
||||
| Abnahmetest | Auftraggeber | HiL / Fahrzeug | manuell |
|
||||
|
||||
Demo: nur Unit-Tests auf Host.
|
||||
|
||||
## 8. Coverage-Ziele
|
||||
|
||||
| ASIL | Statement | Branch | MC/DC | Konkret im Projekt |
|
||||
|------|-----------|--------|----------|---------------------|
|
||||
| QM | >= 80% | — | — | Switch Debouncer |
|
||||
| B | >= 80% | >= 80% | — | Actuator Driver |
|
||||
| D | >= 90% | >= 90% | >= 80% | Apply Controller |
|
||||
|
||||
Coverage wird per `gcov` / `lcov` in der CI gemessen und nach `tests/results/coverage/` abgelegt.
|
||||
|
||||
## 9. Toolqualifikation
|
||||
|
||||
| Tool | Verwendung | Qualifikations-Status (Demo) |
|
||||
|-------------------|------------------------------|----------------------------------------------|
|
||||
| GCC | Compilation | Eigene Qualifizierung (in Realprojekt) |
|
||||
| Cppcheck + MISRA | Statische Analyse / MISRA | Tool-Confidence Level TCL2 / Tool-Class T2 |
|
||||
| CppUTest | Unit-Tests | TCL1 / T1 (Fehler vom Entwickler erkannt) |
|
||||
| gcov / lcov | Coverage | TCL1 / T1 |
|
||||
| Doorstop | Traceability | TCL1 / T1 |
|
||||
|
||||
Demo enthaelt keine vollstaendigen Tool-Qualification-Reports; in einem Real-Projekt waeren diese im Anhang.
|
||||
Reference in New Issue
Block a user