dev-process/templates/SWE-Plan-template.md

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.