# Software Development Plan (SWE-Plan)

| Feld            | Wert                                |
|-----------------|--------------------------------------|
| Projekt         | demo-epb                             |
| Datum           | 2026-05-11                           |
| Version         | 1.0                                  |
| Status          | Freigegeben                          |
| ASIL            | D (hoechste Komponente)              |

---

## 1. Entwicklungsmethode

V-Modell nach ISO 26262 Part 6, iterativ innerhalb der Phasen. Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung. Rechte Seite: Unit-Test → Integrationstest → Systemtest.

Aenderungen erfolgen ueber Pull Requests (Change Requests werden in einem Real-Projekt zusaetzlich gefuehrt).

## 2. Programmiersprache und Standards

| Aspekt              | Festlegung                                          |
|---------------------|-----------------------------------------------------|
| Sprache             | C (C99)                                              |
| Coding Standard     | MISRA C:2012 (Required + Mandatory einzuhalten)      |
| Naming              | snake_case fuer Funktionen, UPPER_CASE fuer Makros   |
| Header-Format       | `@file`, `@arch`, `@reqs` Tags fuer Code → Doku-Link |

### MISRA-Handhabung

- Required- und Mandatory-Regeln verpflichtend
- Advisory-Regeln projektspezifisch (siehe `misra/permits/`)
- Abweichungen pro Stelle: MISRA Deviation Record (`misra/records/`)
- Projektweite Abweichungen: MISRA Deviation Permit (`misra/permits/`)
- MISRA-Pruefung in der CI (`cppcheck --addon=misra --error-exitcode=1`)

## 3. Build-Umgebung

| Komponente         | Tool / Version                                      |
|--------------------|-----------------------------------------------------|
| Build-System       | CMake 3.20+                                          |
| Compiler           | GCC (Host fuer Demo-Tests; ARM-GCC fuer Target)      |
| Zielplattform      | ARM Cortex-M4 (Annahme; Demo-Tests auf x86_64 Host) |
| Host-Plattform     | macOS / Linux x86_64                                 |
| CI-Runner          | Gitea Actions Docker-Image                            |

## 4. Branching-Strategie

```
main              — Stabiler, freigegebener Stand
develop           — Aktueller Entwicklungsstand
feature/SWE-XXX   — Feature-Branch pro Anforderung
bugfix/BUG-XXX    — Bugfix-Branch
```

- `main` und `develop` sind geschuetzt (kein direkter Push)
- Merge nur ueber PR mit Approval
- Branch-Name enthaelt Issue- oder Anforderungs-Nummer

## 5. Review-Verpflichtungen

| Artefakt                    | Review-Art        | Mindest-Approvals |
|-----------------------------|-------------------|--------------------|
| Quellcode QM / ASIL-A/B     | Peer Review       | 1                  |
| Quellcode ASIL-C/D          | Technical Review  | 2                  |
| Architektur-Dokument        | Technical Review  | 2                  |
| Anforderung                  | Technical Review  | 1                  |
| Testfaelle                  | Peer Review       | 1                  |
| MISRA Permit                | Technical Lead    | 1                  |

Single-Person-Demo: Self-Review mit dokumentierter Pruefliste; in einem Real-Projekt nicht zulaessig.

## 6. Definition of Done

- Code kompiliert fehlerfrei
- MISRA-Check in CI ist gruen
- Statische Analyse (Cppcheck, clang-tidy) ohne neue Findings
- Unit Tests gruen
- Coverage-Ziel erreicht
- PR reviewed und approved
- Anforderung mit Test verlinkt (`@reqs` Tag im Code + Test-Datei)
- Architektur-Element verlinkt (`@arch` Tag im Code)

## 7. Integration und Test-Strategie

| Teststufe           | Verantwortlich | Umgebung       | Automatisierung |
|---------------------|----------------|----------------|-----------------|
| Unit Test           | Entwickler     | Host (x86)     | CI              |
| Integrationstest    | Entwickler     | Host / SiL     | CI / manuell    |
| Systemtest          | QA             | SiL / HiL      | teilweise       |
| Abnahmetest         | Auftraggeber   | HiL / Fahrzeug | manuell         |

Demo: nur Unit-Tests auf Host.

## 8. Coverage-Ziele

| ASIL | Statement | Branch | MC/DC    | Konkret im Projekt |
|------|-----------|--------|----------|---------------------|
| QM   | >= 80%    | —      | —        | Switch Debouncer   |
| B    | >= 80%    | >= 80% | —        | Actuator Driver    |
| D    | >= 90%    | >= 90% | >= 80%   | Apply Controller   |

Coverage wird per `gcov` / `lcov` in der CI gemessen und nach `tests/results/coverage/` abgelegt.

## 9. Toolqualifikation

| Tool              | Verwendung                  | Qualifikations-Status (Demo)                |
|-------------------|------------------------------|----------------------------------------------|
| GCC               | Compilation                  | Eigene Qualifizierung (in Realprojekt)       |
| Cppcheck + MISRA  | Statische Analyse / MISRA    | Tool-Confidence Level TCL2 / Tool-Class T2  |
| CppUTest          | Unit-Tests                   | TCL1 / T1 (Fehler vom Entwickler erkannt)   |
| gcov / lcov       | Coverage                     | TCL1 / T1                                    |
| Doorstop          | Traceability                 | TCL1 / T1                                    |

Demo enthaelt keine vollstaendigen Tool-Qualification-Reports; in einem Real-Projekt waeren diese im Anhang.