# 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.