Stefan Lohmaier
1855162e6d
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
115 lines
5.3 KiB
Markdown
115 lines
5.3 KiB
Markdown
# 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.
|