Files

T

Stefan Lohmaier 1855162e6d Initial commit: demo-epb v1.0 — Elektrische Parkbremse Demo

Vollstaendige Demo des slohmaier Dev Process anhand einer EPB-Steuergeraet-
Software. Zeigt ASPICE 4.0 / ISO 26262-konforme Entwicklung im Monorepo.

Inhalte:
- 5 Plaene (PID, PM-, QA-, SWE-, Test-Plan) in Word, ausgefuellt mit
  EPB-spezifischen Inhalten
- 10 System-Anforderungen + 25 Software-Anforderungen (Doorstop-MD)
- 5 System-Architektur-Elemente + 10 Software-Architektur-Elemente
  mit PlantUML-Diagrammen und vollstaendigem Mapping
- 3 implementierte Komponenten (Apply Controller D, Actuator Driver B,
  Switch Debouncer QM) plus 7 Header-Stubs
- 28 Unit-Tests, alle gruen, mit Coverage- und MISRA-Build-Targets
- Audit-Artefakte: 1 Review-Protokoll, 1 Non-Conformity, 1 MISRA-Record
- Gitea-Actions-CI-Pipeline (validate.yml)
- Doorstop-Konfiguration fuer bidirektionale Traceability
- Generator-Skript fuer alle 50 Reqs/Arch-Elemente aus Strukturdaten
- README mit gefuehrter Tour fuer Prospects

2026-05-11 13:51:02 -07:00

3.2 KiB

Raw Blame History

Projektmanagement-Plan (PM-Plan)

Feld	Wert
Projekt	demo-epb
Datum	2026-05-11
Version	1.0
Status	Freigegeben

1. Projektorganisation

Single-Person-Projekt mit dokumentierter Rollentrennung. In einem Real-Projekt waeren QA, TL und Entwickler personell getrennt; hier wird der Audit-Trail durch Self-Review mit Begruendung gefuehrt (siehe SWE-Plan, Abschnitt 5).

2. Arbeitspakete

WP-ID	Arbeitspaket	Verantwortlich	Status
WP-01	Projektplanung (PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan)	S. Lohmaier	Done
WP-02	System-Anforderungen (SYS-001..010)	S. Lohmaier	Done
WP-03	Software-Anforderungen (SWE-001..025)	S. Lohmaier	Done
WP-04	System-Architektur (SA-001..005)	S. Lohmaier	Done
WP-05	Software-Architektur (SWA-001..010)	S. Lohmaier	Done
WP-06	Implementierung Demo-Komponenten	S. Lohmaier	Done
WP-07	Unit-Tests + Coverage	S. Lohmaier	Done
WP-08	CI-Pipeline (Gitea Actions)	S. Lohmaier	Done
WP-09	Audit-Artefakte (Review, NC, MISRA-Record)	S. Lohmaier	Done

3. Aenderungsverwaltung

Aenderungen an freigegebenen Artefakten erfolgen ueber Pull Requests
Jeder PR braucht mindestens 1 Approval (siehe SWE-Plan, Abschnitt 5)
Bei Aenderung von Architektur oder Anforderungen ist die Traceability-Matrix neu zu erzeugen (doorstop publish)
Aenderungshistorie wird in der jeweiligen .md-Datei oder Word-Datei revisioniert

4. Konfigurationsmanagement

Artefakt-Typ	Versionsverwaltung	Baseline-Mechanismus
Code	Git (Gitea)	Git-Tag (z.B. v1.0.0)
Anforderungen / Arch	Git + Doorstop	Git-Tag + doorstop publish
Word-Dokumente	Git	Datei-Versionsstempel + Revisions-History im Dokument
CI-Konfiguration	Git	Versionsdatei + Tag

5. Kommunikation

Kanal	Zweck
Gitea Issues	Bug-Tracking, Tasks
Gitea PRs	Review, Approval, Audit-Trail
Matrix Chat	Schnelle Abstimmung
E-Mail	Formelle Freigaben (CC: Auftraggeber)

6. Berichtswesen

Wochenstatus per E-Mail (in Real-Projekten)
Audit-Report bei Projektabschluss (PDF aus Doorstop + Word-Plaene)
Coverage- und MISRA-Reports werden bei jedem Push aktualisiert (CI-Artefakte)

7. Abschluss

Projekt gilt als abgeschlossen, wenn alle Erfolgskriterien aus dem PID erfuellt sind und ein Git-Tag v1.0 gesetzt ist.

3.2 KiB Raw Blame History