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
133 lines
5.6 KiB
Markdown
133 lines
5.6 KiB
Markdown
# 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 `develop` abzweigen
|
|
- Merge nach `develop` nur per MR mit Approval
|
|
- `main` und `release/*` 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.*
|