refactor(i18n): rename vorlagen/ -> templates/, *-vorlage -> *-template
Final German naming cleanup in dev-process: - vorlagen/ -> templates/ - vorlagen-word/ -> templates-word/ - tools/generate_word_vorlagen.sh -> tools/generate_word_templates.sh - *-vorlage.md / *-vorlage.docx -> *-template.md / *-template.docx - Review-Protokoll-vorlage.* -> Review-Minutes-template.* - angebot-vorlage.* -> quote-template.* - angebot-beispiel.html -> quote-example.html All references in README.md, toolstack/toolstack.md, build_word_template.py, and generate_word_templates.sh updated. The master Word style template (slohmaier-doc-template.docx) was already English-named. The dev-process repo is now fully English in both content and structure.
This commit is contained in:
Stefan Lohmaier
@@ -0,0 +1,132 @@
|
||||
# Software Development Plan (SWE Plan)
|
||||
|
||||
| Field | Value |
|
||||
|------------------|--------------------------------|
|
||||
| Project | [Project name] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Draft / Released] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Development method
|
||||
|
||||
[Describe the approach: iterative, V-model aligned, or hybrid.]
|
||||
|
||||
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
|
||||
|
||||
Changes are managed via change requests (see PM Plan).
|
||||
|
||||
## 2. Programming language and standards
|
||||
|
||||
| Aspect | Decision |
|
||||
|---------------------|-----------------------------------------------------|
|
||||
| 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 handling
|
||||
|
||||
- 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 environment
|
||||
|
||||
| Component | Tool / Version |
|
||||
|--------------------|-----------------------------------------------------|
|
||||
| Build system | [CMake X.Y / SCons X.Y / Make] |
|
||||
| Compiler | [GCC ARM X.Y / Clang X.Y] |
|
||||
| Target platform | [e.g. ARM Cortex-R5, Cortex-M4] |
|
||||
| Host platform | [Linux x86_64 / macOS ARM64] |
|
||||
| CI runner | [Gitea Runner, Docker image: ...] |
|
||||
|
||||
The build environment is reproducible: either via a Docker image or via a documented toolchain installation.
|
||||
|
||||
## 4. Branching strategy
|
||||
|
||||
```
|
||||
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 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: see `gitea-aspice-setup.md`.
|
||||
|
||||
## 5. Review obligations
|
||||
|
||||
| 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 |
|
||||
|
||||
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
|
||||
|
||||
A feature / requirement is "Done" when:
|
||||
|
||||
- [ ] 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 and test strategy
|
||||
|
||||
| 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 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 targets
|
||||
|
||||
| ASIL | Statement coverage | Branch coverage | MC/DC |
|
||||
|------|--------------------|-----------------|----------|
|
||||
| QM | ≥ 80% recommended | — | — |
|
||||
| A | ≥ 80% | recommended | — |
|
||||
| B | ≥ 80% | ≥ 80% | — |
|
||||
| C | ≥ 90% | ≥ 80% | recommended |
|
||||
| D | ≥ 90% | ≥ 90% | ≥ 80% |
|
||||
|
||||
Concrete target values for this project:
|
||||
|
||||
| Metric | Target |
|
||||
|---------------------|------------|
|
||||
| Statement coverage | ≥ [X]% |
|
||||
| Branch coverage | ≥ [X]% |
|
||||
| MC/DC | ≥ [X]% (where applicable) |
|
||||
|
||||
Coverage is measured in CI and archived as an artefact. Deviations from the target are justified and documented in the QA report.
|
||||
|
||||
---
|
||||
|
||||
*Changes to this plan are versioned in the Gitea wiki.*
|
||||
Reference in New Issue
Block a user