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