slohmaier/dev-process
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(i18n): dev-process repo in English

Browse Source 
- README.md: full English rewrite
- All 13 vorlagen MD templates hand-translated:
  PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan,
  SA, SWA, Review-Protokoll, Non-Conformity,
  MISRA-Deviation-Permit, MISRA-Deviation-Record,
  Traceability-Matrix, angebot (quotation)
- Master Word template (slohmaier-doc-template.docx) regenerated
  in English: cover page, document control, TOC headers,
  classification banner all English
- All derived Word vorlagen regenerated from English MD sources

Still to translate: toolstack.md, gitea-aspice-setup.md
This commit is contained in:
Stefan Lohmaier
2026-05-12 03:42:35 -07:00
parent 6e458ae76f
commit d5cfec9e42
25 changed files with 774 additions and 875 deletions
Download Patch File Download Diff File Expand all files Collapse all files
vorlagen/SWE-Plan-vorlage.md
+89 -89
View File
@@ -1,132 +1,132 @@
# Software Development Plan (SWE-Plan)
# 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] |
| Field | Value |
|------------------|--------------------------------|
| Project | [Project name] |
| Date | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Draft / Released] |
| ASIL | [QM / A / B / C / D] |
---
## 1. Entwicklungsmethode
## 1. Development method
[Beschreibung der Vorgehensweise: iterativ, V-Modell-angelehnt, oder hybrid.]
[Describe the approach: iterative, V-model aligned, or 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
The base structure follows the V-model (ISO 26262 Part 6):
- Left side: requirements → architecture → detailed design → implementation
- Right side: unit test → integration test → system test
- Iterations within phases are possible
Aenderungen werden ueber Change Requests gesteuert (siehe PM-Plan).
Changes are managed via change requests (see PM Plan).
## 2. Programmiersprache und Standards
## 2. Programming language and standards
| Aspekt | Festlegung |
| Aspect | Decision |
|---------------------|-----------------------------------------------------|
| 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] |
| Language | [C (C99/C11) / C++ (C++14/17) / Rust] |
| Coding standard | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023] |
| Project guidelines | [Reference to coding guidelines in the wiki] |
| Naming convention | [e.g. snake_case for functions, UPPER_CASE for macros] |
### MISRA-Handhabung
### MISRA handling
- 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
- All Required and Mandatory rules are observed
- Advisory rules: list of applied rules documented in the wiki
- Deviations are documented per MISRA deviation record
- Project-wide deviations are approved via MISRA deviation permit
- MISRA check runs automatically in the CI pipeline
## 3. Build-Umgebung
## 3. Build environment
| Komponente | Tool / Version |
| Component | Tool / Version |
|--------------------|-----------------------------------------------------|
| Build-System | [CMake X.Y / SCons X.Y / Make] |
| 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: ...] |
| Target platform | [e.g. ARM Cortex-R5, Cortex-M4] |
| Host platform | [Linux x86_64 / macOS ARM64] |
| CI runner | [Gitea Runner, Docker image: ...] |
Build-Umgebung ist reproduzierbar: entweder per Docker-Image oder per dokumentierter Toolchain-Installation.
The build environment is reproducible: either via a Docker image or via a documented toolchain installation.
## 4. Branching-Strategie
## 4. Branching strategy
```
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
main — stable, released state
develop — current development state
feature/SWE-XXX — feature branch per requirement
bugfix/BUG-XXX — bug-fix branch
release/vX.Y — release preparation
hotfix/vX.Y.Z — critical fixes after 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
- Feature branches are taken off `develop`
- Merge to `develop` only via PR with approval
- `main` and `release/*` are protected (no direct push)
- Branch name includes the issue number
Details: siehe `gitlab-aspice-setup.md`.
Details: see `gitea-aspice-setup.md`.
## 5. Review-Verpflichtungen
## 5. Review obligations
| 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 |
| Artefact | Review type | Min. approvals |
|-----------------------------|--------------------|-----------------|
| Source code (PR) | Peer review | 1 |
| Safety-relevant code | Technical review | 2 |
| Architecture document | Technical review | 2 |
| Requirements | Technical review | 1 |
| Test cases | 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).
Every PR must be reviewed and approved before merge. Self-merges are not permitted (exception: 1-person project with documented self-review).
## 6. Definition of Done
Ein Feature / eine Anforderung gilt als "Done" wenn:
A feature / requirement is "Done" when:
- [ ] 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)
- [ ] Code is implemented and compiles without errors
- [ ] MISRA check in CI is green (no new violations)
- [ ] Static analysis (Cppcheck, clang-tidy) has no new findings
- [ ] Unit tests are written and green
- [ ] Coverage target is reached (see section 8)
- [ ] PR is reviewed and approved
- [ ] Requirement is linked to a test (traceability)
- [ ] Documentation is updated (if affected)
## 7. Integration und Test-Strategie
## 7. Integration and test strategy
| 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 |
| Test level | Owner | Environment | Automation |
|--------------------|----------------|---------------|------------------|
| Unit test | Developer | host (x86) | CI pipeline |
| Integration test | Developer | host / SiL | CI / manual |
| System test | Test / QA | SiL / HiL | partial |
| Acceptance test | Client | HiL / vehicle | manual |
- 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
- Unit tests run on the host platform (cross-compilation for x86 testing)
- Integration tests verify module interaction
- System tests verify against system requirements
- HiL tests are provided by the client or jointly defined
## 8. Coverage-Ziele
## 8. Coverage targets
| ASIL | Statement Coverage | Branch Coverage | MC/DC |
| ASIL | Statement coverage | Branch coverage | MC/DC |
|------|--------------------|-----------------|----------|
| QM | >= 80% empfohlen | — | — |
| A | >= 80% | empfohlen | — |
| B | >= 80% | >= 80% | — |
| C | >= 90% | >= 80% | empfohlen|
| D | >= 90% | >= 90% | >= 80% |
| QM | ≥ 80% recommended | — | — |
| A | ≥ 80% | recommended | — |
| B | ≥ 80% | ≥ 80% | — |
| C | ≥ 90% | ≥ 80% | recommended |
| D | ≥ 90% | ≥ 90% | ≥ 80% |
Konkrete Zielwerte fuer dieses Projekt:
Concrete target values for this project:
| Metrik | Zielwert |
| Metric | Target |
|---------------------|------------|
| Statement Coverage | >= [X]% |
| Branch Coverage | >= [X]% |
| MC/DC | >= [X]% (falls anwendbar) |
| Statement coverage | ≥ [X]% |
| Branch coverage | ≥ [X]% |
| MC/DC | ≥ [X]% (where applicable) |
Coverage wird in der CI gemessen und als Artefakt archiviert. Abweichungen vom Ziel werden begruendet und im QA-Report dokumentiert.
Coverage is measured in CI and archived as an artefact. Deviations from the target are justified and documented in the QA report.
---
*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*
*Changes to this plan are versioned in the Gitea wiki.*