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
5.3 KiB
5.3 KiB
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
mainunddevelopsind 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 (
@reqsTag im Code + Test-Datei) - Architektur-Element verlinkt (
@archTag 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.