Stefan Lohmaier
fb2c083551
Validate / build-test (macos-latest) (push) Failing after 3s
Validate / build-test (windows-latest) (push) Failing after 15s
Validate / build-test (ubuntu-latest) (push) Successful in 17s
Validate / reports (push) Successful in 50s
Release / release (push) Successful in 50s
Phase 2 of the English translation: Word documents (filled, EPB-specific): - 8 plans (PID, PM, QA, SWE, Test, Project Manual, CM, RM) - 6 safety docs (HARA, Safety Case, FMEDA, MISRA Compliance, Verification Report, Tool Qualification Cppcheck) - 2 manuals (User, Service) - 3 audit artefacts (Review minutes, NC-001, MISRA-REC-001) - All regenerated via pandoc from English markdown sources Code, tests, headers: - All file headers, struct comments, function docstrings in English - All test names (TEST_BEGIN strings) translated - Inline comments translated - 46 tests still green after translation CI workflows: - All step names in English - Step descriptions, comments, release notes template in English README.md fully rewritten in English with proper guided tour. Phase 3 (still pending): dev-process repo templates + toolstack/setup docs.
115 lines
5.3 KiB
Markdown
115 lines
5.3 KiB
Markdown
# Software Development Plan (SWE Plan)
|
|
|
|
| Field | Value |
|
|
|-----------------|--------------------------------------|
|
|
| Project | demo-epb |
|
|
| Date | 2026-05-11 |
|
|
| Version | 1.0 |
|
|
| Status | Released |
|
|
| ASIL | D (highest component) |
|
|
|
|
---
|
|
|
|
## 1. Development method
|
|
|
|
V-model per ISO 26262 Part 6, iterative within phases. Left side: requirements → architecture → detailed design → implementation. Right side: unit test → integration test → system test.
|
|
|
|
Changes go through pull requests (change requests are tracked separately in a real project).
|
|
|
|
## 2. Programming language and standards
|
|
|
|
| Aspect | Decision |
|
|
|---------------------|-----------------------------------------------------|
|
|
| Language | C (C99) |
|
|
| Coding standard | MISRA C:2012 (Required + Mandatory mandatory) |
|
|
| Naming | snake_case for functions, UPPER_CASE for macros |
|
|
| Header format | `@file`, `@arch`, `@reqs` tags linking code to docs |
|
|
|
|
### MISRA handling
|
|
|
|
- Required and Mandatory rules are mandatory
|
|
- Advisory rules are project-specific (see `misra/permits/`)
|
|
- Per-site deviations: MISRA deviation record (`misra/records/`)
|
|
- Project-wide deviations: MISRA deviation permit (`misra/permits/`)
|
|
- MISRA check runs in CI (`cppcheck --addon=misra --error-exitcode=1`)
|
|
|
|
## 3. Build environment
|
|
|
|
| Component | Tool / Version |
|
|
|--------------------|-----------------------------------------------------|
|
|
| Build system | CMake 3.20+ |
|
|
| Compiler | GCC (host for demo tests; ARM-GCC for target) |
|
|
| Target platform | ARM Cortex-M4 (assumption; demo tests run on x86_64 host) |
|
|
| Host platform | macOS / Linux x86_64 |
|
|
| CI runner | Gitea Actions Docker image |
|
|
|
|
## 4. Branching strategy
|
|
|
|
```
|
|
main — stable, released state
|
|
develop — current development state
|
|
feature/SWE-XXX — feature branch per requirement
|
|
bugfix/BUG-XXX — bug-fix branch
|
|
```
|
|
|
|
- `main` and `develop` are protected (no direct push)
|
|
- Merge only via PR with approval
|
|
- Branch name includes the issue or requirement number
|
|
|
|
## 5. Review obligations
|
|
|
|
| Artefact | Review type | Min. approvals |
|
|
|-----------------------------|---------------------|-----------------|
|
|
| Source code QM / ASIL-A/B | Peer review | 1 |
|
|
| Source code ASIL-C/D | Technical review | 2 |
|
|
| Architecture document | Technical review | 2 |
|
|
| Requirement | Technical review | 1 |
|
|
| Test cases | Peer review | 1 |
|
|
| MISRA permit | Technical lead | 1 |
|
|
|
|
Single-person demo: self-review with documented checklist; not permissible in a real project.
|
|
|
|
## 6. Definition of Done
|
|
|
|
- Code compiles without errors
|
|
- MISRA check in CI is green
|
|
- Static analysis (Cppcheck, clang-tidy) has no new findings
|
|
- Unit tests are green
|
|
- Coverage target reached
|
|
- PR reviewed and approved
|
|
- Requirement linked to a test (`@reqs` tag in code + test file)
|
|
- Architecture element linked (`@arch` tag in code)
|
|
|
|
## 7. Integration and test strategy
|
|
|
|
| Test level | Owner | Environment | Automation |
|
|
|--------------------|----------------|---------------|------------------|
|
|
| Unit test | Developer | Host (x86) | CI |
|
|
| Integration test | Developer | Host / SiL | CI / manual |
|
|
| System test | QA | SiL / HiL | partial |
|
|
| Acceptance test | Customer | HiL / vehicle | manual |
|
|
|
|
Demo: only unit tests on host.
|
|
|
|
## 8. Coverage targets
|
|
|
|
| ASIL | Statement | Branch | MC/DC | Concrete in this project |
|
|
|------|-----------|--------|----------|---------------------------|
|
|
| QM | ≥ 80% | — | — | Switch Debouncer |
|
|
| B | ≥ 80% | ≥ 80% | — | Actuator Driver |
|
|
| D | ≥ 90% | ≥ 90% | ≥ 80% | Apply Controller |
|
|
|
|
Coverage is measured via `gcov` / `lcov` in CI and stored under `tests/results/coverage/`.
|
|
|
|
## 9. Tool qualification
|
|
|
|
| Tool | Use | Qualification status (demo) |
|
|
|-------------------|------------------------------|-----------------------------------------------|
|
|
| GCC | Compilation | Own qualification (in real project) |
|
|
| Cppcheck + MISRA | Static analysis / MISRA | Tool Confidence Level TCL2 / Tool Class T2 |
|
|
| CppUTest | Unit tests | TCL1 / T1 (defects caught by developer) |
|
|
| gcov / lcov | Coverage | TCL1 / T1 |
|
|
| Doorstop | Traceability | TCL1 / T1 |
|
|
|
|
The demo does not include full tool-qualification reports; in a real project these would live in an appendix.
|