# Software Development Plan (SWE-Plan)

| Feld            | Wert                          |
|-----------------|-------------------------------|
| Projekt         | [Projektname]                 |
| Datum           | [YYYY-MM-DD]                  |
| Version         | [1.0]                         |
| Status          | [Entwurf / Freigegeben]       |
| ASIL            | [QM / A / B / C / D]         |

---

## 1. Entwicklungsmethode

[Beschreibung der Vorgehensweise: iterativ, V-Modell-angelehnt, oder hybrid.]

Grundstruktur folgt dem V-Modell (ISO 26262 Part 6):
- Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung
- Rechte Seite: Unit Test → Integrations-Test → System-Test
- Iterationen innerhalb der Phasen moeglich

Aenderungen werden ueber Change Requests gesteuert (siehe PM-Plan).

## 2. Programmiersprache und Standards

| Aspekt              | Festlegung                                          |
|---------------------|-----------------------------------------------------|
| Sprache             | [C (C99/C11) / C++ (C++14/17) / Rust]              |
| Coding Standard     | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023]     |
| Projekt-Guidelines  | [Verweis auf Coding-Guidelines im Wiki]             |
| Namenskonvention    | [z.B. snake_case fuer Funktionen, UPPER_CASE fuer Makros] |

### MISRA-Handhabung

- Alle Required- und Mandatory-Regeln werden eingehalten
- Advisory-Regeln: Liste der angewendeten Regeln im Wiki dokumentiert
- Abweichungen werden per MISRA Deviation Record dokumentiert
- Projektweite Abweichungen per MISRA Deviation Permit genehmigt
- MISRA-Pruefung laeuft automatisch in der CI-Pipeline

## 3. Build-Umgebung

| Komponente         | Tool / Version                                      |
|--------------------|-----------------------------------------------------|
| Build-System       | [CMake X.Y / SCons X.Y / Make]                      |
| Compiler           | [GCC ARM X.Y / Clang X.Y]                           |
| Zielplattform      | [z.B. ARM Cortex-R5, Cortex-M4]                     |
| Host-Plattform     | [Linux x86_64 / macOS ARM64]                         |
| CI-Runner          | [GitLab Runner, Docker Image: ...]                   |

Build-Umgebung ist reproduzierbar: entweder per Docker-Image oder per dokumentierter Toolchain-Installation.

## 4. Branching-Strategie

```
main              — Stabiler, freigegebener Stand
develop           — Aktueller Entwicklungsstand
feature/SWR-XXX   — Feature-Branch pro Anforderung
bugfix/BUG-XXX    — Bugfix-Branch
release/vX.Y      — Release-Vorbereitung
hotfix/vX.Y.Z     — Kritische Fixes nach Release
```

- Feature-Branches von `develop` abzweigen
- Merge nach `develop` nur per MR mit Approval
- `main` und `release/*` sind geschuetzt (kein direkter Push)
- Branch-Name enthaelt Issue-Nummer

Details: siehe `gitlab-aspice-setup.md`.

## 5. Review-Verpflichtungen

| Artefakt                    | Review-Art        | Mindest-Approvals |
|-----------------------------|-------------------|--------------------|
| Quellcode (MR)              | Peer Review       | 1                  |
| Safety-relevanter Code      | Technical Review  | 2                  |
| Architektur-Dokument        | Technical Review  | 2                  |
| Anforderungen               | Technical Review  | 1                  |
| Testfaelle                  | Peer Review       | 1                  |

Jeder MR muss vor dem Merge reviewed und approved sein. Self-Merges sind nicht erlaubt (Ausnahme: 1-Person-Projekt mit dokumentiertem Self-Review).

## 6. Definition of Done

Ein Feature / eine Anforderung gilt als "Done" wenn:

- [ ] Code ist implementiert und kompiliert fehlerfrei
- [ ] MISRA-Check in CI ist gruen (keine neuen Violations)
- [ ] Static Analysis (Cppcheck, clang-tidy) hat keine neuen Findings
- [ ] Unit Tests sind geschrieben und gruen
- [ ] Coverage-Ziel ist erreicht (siehe Abschnitt 8)
- [ ] MR ist reviewed und approved
- [ ] Anforderung ist mit Test verlinkt (Traceability)
- [ ] Dokumentation ist aktualisiert (falls betroffen)

## 7. Integration und Test-Strategie

| Teststufe           | Verantwortlich | Umgebung       | Automatisierung |
|---------------------|----------------|----------------|-----------------|
| Unit Test           | Entwickler     | Host (x86)     | CI-Pipeline     |
| Integrations-Test   | Entwickler     | Host / SiL     | CI / manuell    |
| System-Test         | Test / QA      | SiL / HiL      | teilweise       |
| Abnahme-Test        | Auftraggeber   | HiL / Fahrzeug | manuell         |

- Unit Tests laufen auf Host-Plattform (Cross-Compilation fuer Tests auf x86)
- Integrationstests pruefen Zusammenspiel der Module
- System-Tests pruefen gegen System-Anforderungen
- HiL-Tests werden vom Auftraggeber bereitgestellt oder gemeinsam definiert

## 8. Coverage-Ziele

| ASIL | Statement Coverage | Branch Coverage | MC/DC    |
|------|--------------------|-----------------|----------|
| QM   | >= 80% empfohlen   | —               | —        |
| A    | >= 80%             | empfohlen       | —        |
| B    | >= 80%             | >= 80%          | —        |
| C    | >= 90%             | >= 80%          | empfohlen|
| D    | >= 90%             | >= 90%          | >= 80%   |

Konkrete Zielwerte fuer dieses Projekt:

| Metrik              | Zielwert   |
|---------------------|------------|
| Statement Coverage  | >= [X]%    |
| Branch Coverage     | >= [X]%    |
| MC/DC               | >= [X]% (falls anwendbar) |

Coverage wird in der CI gemessen und als Artefakt archiviert. Abweichungen vom Ziel werden begruendet und im QA-Report dokumentiert.

---

*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*