Initial commit: slohmaier Dev Process v1.0
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
This commit is contained in:
Stefan Lohmaier
@@ -0,0 +1,132 @@
|
||||
# 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.*
|
||||
Reference in New Issue
Block a user