Stefan Lohmaier
6e458ae76f
ASPICE 4.0 / ISO 26262 Entwicklungsprozess fuer kleine Teams. Inhalte: - README mit hybrider Format-Strategie (Word + Markdown) - Toolstack (Gitea, Doorstop, Cppcheck, gcov, CppUTest, pandoc) - Markdown-Vorlagen fuer Requirements + Architektur (SA, SWA) - Markdown-Vorlagen fuer formelle Dokumente (PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan, Reviews, Non-Conformity, MISRA Permits/Records) - Word-Master-Template (slohmaier-doc-template.docx) mit ISO-9001- konformer Document Control, Formatvorlagen, Auto-Verzeichnissen - Build-Scripts (build_word_template.py, generate_word_vorlagen.sh) - gitea-aspice-setup.md, V-Modell-Infografik
5.6 KiB
5.6 KiB
Software Development Plan (SWE-Plan)
| Feld | Wert |
|---|---|
| Projekt | [Projektname] |
| Datum | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Entwurf / Freigegeben] |
| ASIL | [QM / A / B / C / D] |
1. Entwicklungsmethode
[Beschreibung der Vorgehensweise: iterativ, V-Modell-angelehnt, oder hybrid.]
Grundstruktur folgt dem V-Modell (ISO 26262 Part 6):
- Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung
- Rechte Seite: Unit Test → Integrations-Test → System-Test
- Iterationen innerhalb der Phasen moeglich
Aenderungen werden ueber Change Requests gesteuert (siehe PM-Plan).
2. Programmiersprache und Standards
| Aspekt | Festlegung |
|---|---|
| Sprache | [C (C99/C11) / C++ (C++14/17) / Rust] |
| Coding Standard | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023] |
| Projekt-Guidelines | [Verweis auf Coding-Guidelines im Wiki] |
| Namenskonvention | [z.B. snake_case fuer Funktionen, UPPER_CASE fuer Makros] |
MISRA-Handhabung
- Alle Required- und Mandatory-Regeln werden eingehalten
- Advisory-Regeln: Liste der angewendeten Regeln im Wiki dokumentiert
- Abweichungen werden per MISRA Deviation Record dokumentiert
- Projektweite Abweichungen per MISRA Deviation Permit genehmigt
- MISRA-Pruefung laeuft automatisch in der CI-Pipeline
3. Build-Umgebung
| Komponente | Tool / Version |
|---|---|
| Build-System | [CMake X.Y / SCons X.Y / Make] |
| Compiler | [GCC ARM X.Y / Clang X.Y] |
| Zielplattform | [z.B. ARM Cortex-R5, Cortex-M4] |
| Host-Plattform | [Linux x86_64 / macOS ARM64] |
| CI-Runner | [GitLab Runner, Docker Image: ...] |
Build-Umgebung ist reproduzierbar: entweder per Docker-Image oder per dokumentierter Toolchain-Installation.
4. Branching-Strategie
main — Stabiler, freigegebener Stand
develop — Aktueller Entwicklungsstand
feature/SWR-XXX — Feature-Branch pro Anforderung
bugfix/BUG-XXX — Bugfix-Branch
release/vX.Y — Release-Vorbereitung
hotfix/vX.Y.Z — Kritische Fixes nach Release
- Feature-Branches von
developabzweigen - Merge nach
developnur per MR mit Approval mainundrelease/*sind geschuetzt (kein direkter Push)- Branch-Name enthaelt Issue-Nummer
Details: siehe gitlab-aspice-setup.md.
5. Review-Verpflichtungen
| Artefakt | Review-Art | Mindest-Approvals |
|---|---|---|
| Quellcode (MR) | Peer Review | 1 |
| Safety-relevanter Code | Technical Review | 2 |
| Architektur-Dokument | Technical Review | 2 |
| Anforderungen | Technical Review | 1 |
| Testfaelle | Peer Review | 1 |
Jeder MR muss vor dem Merge reviewed und approved sein. Self-Merges sind nicht erlaubt (Ausnahme: 1-Person-Projekt mit dokumentiertem Self-Review).
6. Definition of Done
Ein Feature / eine Anforderung gilt als "Done" wenn:
- Code ist implementiert und kompiliert fehlerfrei
- MISRA-Check in CI ist gruen (keine neuen Violations)
- Static Analysis (Cppcheck, clang-tidy) hat keine neuen Findings
- Unit Tests sind geschrieben und gruen
- Coverage-Ziel ist erreicht (siehe Abschnitt 8)
- MR ist reviewed und approved
- Anforderung ist mit Test verlinkt (Traceability)
- Dokumentation ist aktualisiert (falls betroffen)
7. Integration und Test-Strategie
| Teststufe | Verantwortlich | Umgebung | Automatisierung |
|---|---|---|---|
| Unit Test | Entwickler | Host (x86) | CI-Pipeline |
| Integrations-Test | Entwickler | Host / SiL | CI / manuell |
| System-Test | Test / QA | SiL / HiL | teilweise |
| Abnahme-Test | Auftraggeber | HiL / Fahrzeug | manuell |
- Unit Tests laufen auf Host-Plattform (Cross-Compilation fuer Tests auf x86)
- Integrationstests pruefen Zusammenspiel der Module
- System-Tests pruefen gegen System-Anforderungen
- HiL-Tests werden vom Auftraggeber bereitgestellt oder gemeinsam definiert
8. Coverage-Ziele
| ASIL | Statement Coverage | Branch Coverage | MC/DC |
|---|---|---|---|
| QM | >= 80% empfohlen | — | — |
| A | >= 80% | empfohlen | — |
| B | >= 80% | >= 80% | — |
| C | >= 90% | >= 80% | empfohlen |
| D | >= 90% | >= 90% | >= 80% |
Konkrete Zielwerte fuer dieses Projekt:
| Metrik | Zielwert |
|---|---|
| Statement Coverage | >= [X]% |
| Branch Coverage | >= [X]% |
| MC/DC | >= [X]% (falls anwendbar) |
Coverage wird in der CI gemessen und als Artefakt archiviert. Abweichungen vom Ziel werden begruendet und im QA-Report dokumentiert.
Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.