Stefan Lohmaier
294b9956f9
Validate / build-test (macos-latest) (push) Failing after 2s
Validate / build-test (windows-latest) (push) Failing after 15s
Validate / build-test (ubuntu-latest) (push) Failing after 15s
Validate / reports (push) Has been skipped
Release / release (push) Successful in 57s
3 neue Plaene: - Project Manual: Master-Wegweiser fuer neue Projektmitglieder, Lese-Reihenfolge, Rollen, Lebenszyklus, Dokumenten-Landschaft - Configuration Management Plan: CIs, Baselines, Change Control, Release-Prozess, Aufbewahrungsfristen (ASPICE SUP.8) - Risk Management Plan: Projekt-Risiken (abgegrenzt von HARA), Klassifikations-Skala, Risiko-Register, Eskalations-Pfad Landing-Page (Startseite): - tools/generate_landing_page.py erzeugt build/index.html - Standalone-HTML, oeffnet im Browser ohne Server - KPI-Cards: SG/SYS/SWE/Arch/Komponenten/Tests-Counts - Sektionen mit Links: Plaene, Safety, Manuals, Audit, Reports, Diagramme, Source-Code, externe Links - Existenz-Check: nicht-generierte Reports werden grau markiert - Im Release-Bundle als index.html ganz oben CI-Integration: - validate.yml: neuer Step "Landing-Page" + Upload als Artefakt - release.yml: Landing-Page generieren + ins Bundle einbauen, zusaetzlich Source-Code im Bundle (war vorher nur als tar.gz) Makefile: neues Target `make landing-page`
173 lines
7.5 KiB
Markdown
173 lines
7.5 KiB
Markdown
---
|
|
doc-id: SLM-EPB-PM-MAN-001
|
|
version: 1.0
|
|
status: Freigegeben
|
|
datum: 2026-05-12
|
|
---
|
|
|
|
# Project Manual — demo-epb
|
|
|
|
| Feld | Wert |
|
|
|--------------|----------------------------------------|
|
|
| Projekt | demo-epb (Elektrische Parkbremse) |
|
|
| Dokument-ID | SLM-EPB-PM-MAN-001 |
|
|
| Version | 1.0 |
|
|
| Status | Freigegeben |
|
|
| Datum | 2026-05-12 |
|
|
| Zielgruppe | Neue Projektmitglieder, Auditoren |
|
|
|
|
---
|
|
|
|
## 1. Zweck
|
|
|
|
Dieses Project Manual ist der **Einstieg** ins demo-epb Projekt. Es beantwortet:
|
|
|
|
- Was wird gebaut?
|
|
- Welche Dokumente gibt es, in welcher Reihenfolge lesen?
|
|
- Wer ist verantwortlich wofuer?
|
|
- Wie laeuft der Entwicklungs- und Freigabe-Zyklus?
|
|
|
|
## 2. Was ist demo-epb?
|
|
|
|
Eine vollstaendige Demo des **slohmaier Dev Process** anhand einer
|
|
EPB-Steuergeraet-Software. Ziel ist **nicht** die produktive Software, sondern
|
|
der Nachweis ASPICE 4.0 / ISO 26262-konformer Entwicklung.
|
|
|
|
Detail: `docs/plaene/PID.docx`.
|
|
|
|
## 3. Lese-Reihenfolge fuer neue Projektmitglieder
|
|
|
|
| Tag | Dokument | Warum |
|
|
|-----|----------------------------------------|----------------------------------------|
|
|
| 1 | dieses Project Manual | Orientierung |
|
|
| 1 | `PID.docx` | Was + Warum |
|
|
| 1 | `User-Manual.docx` | Produkt-Verstaendnis |
|
|
| 2 | `HARA.docx` + `Safety-Case.docx` | Sicherheits-Konzept |
|
|
| 2 | `SWE-Plan.docx` + `QA-Plan.docx` | Engineering-Konventionen |
|
|
| 3 | `reqs/` + `arch/` (Markdown) | Anforderungen + Architektur |
|
|
| 3 | `src/apply_controller.c` | Beispiel ASIL-D Code |
|
|
| 4 | `traceability/index.html` | Vernetzung der Artefakte |
|
|
| 4 | `coverage/index.html` | Was ist getestet |
|
|
| 5 | Diese Anleitung selber pflegen | Onboarding fuer den Naechsten |
|
|
|
|
## 4. Dokumenten-Landschaft
|
|
|
|
```
|
|
demo-epb/
|
|
├── docs/plaene/ ← PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan, CM-Plan, RM-Plan
|
|
├── docs/safety/ ← HARA, Safety-Case, FMEDA, MISRA-Compliance, Verification-Report, Tool-Qualification
|
|
├── docs/manuals/ ← User-Manual, Service-Manual
|
|
├── docs/reviews/ ← Review-Protokolle
|
|
├── docs/non-conformities/ ← NC-Eintraege
|
|
├── misra/records/ ← MISRA Deviation Records
|
|
├── reqs/sys/ ← Doorstop-MD System Requirements
|
|
├── reqs/swe/ ← Doorstop-MD Software Requirements
|
|
├── arch/sys/ ← Doorstop-MD System Architecture + PlantUML
|
|
├── arch/swe/ ← Doorstop-MD Software Architecture + PlantUML
|
|
├── safety/sg/ ← Doorstop-MD Safety Goals (ASIL-Ableitung)
|
|
├── src/ ← C-Code, mit @arch + @reqs Tags im Header
|
|
├── tests/ ← Unit-Tests mit @reqs Tags
|
|
├── tools/ ← Python-Skripte (Traceability, PlantUML, Reports)
|
|
├── .gitea/workflows/ ← CI-Pipelines (validate + release)
|
|
└── docs/index.html ← Auto-generierte Startseite
|
|
```
|
|
|
|
Eine **klickbare Uebersicht** liefert `docs/index.html` (Browser oeffnen).
|
|
|
|
## 5. Rollen und Verantwortlichkeiten
|
|
|
|
| Rolle | Verantwortung | Person (Demo) |
|
|
|--------------------|-----------------------------------------------------|--------------------------|
|
|
| Project Owner | Strategische Entscheidungen, Freigabe Release | Stefan Lohmaier |
|
|
| Technical Lead | Architektur, Code-Reviews, technische Entscheidungen | Stefan Lohmaier |
|
|
| Safety Manager | HARA, Safety Case, ASIL-Konformitaet | Stefan Lohmaier (Demo) |
|
|
| QA-Beauftragter | QA-Plan-Pflege, Audit-Vorbereitung | Stefan Lohmaier (Demo) |
|
|
| Configuration Mgr | Baselines, Releases, Git-Repo-Hygiene | Stefan Lohmaier (Demo) |
|
|
| Entwickler | Implementierung gemaess Architektur + Tests | Stefan Lohmaier (Demo) |
|
|
| Reviewer | Code- und Dokument-Reviews | Externer Reviewer (TBD) |
|
|
|
|
In der Demo ist eine Person in allen Rollen; in einem Real-Projekt mit ASIL-C/D
|
|
sind diese personell zu trennen (insb. Entwickler ungleich Reviewer fuer
|
|
sicherheitskritischen Code).
|
|
|
|
## 6. Entwicklungs-Lebenszyklus
|
|
|
|
```
|
|
Anforderung
|
|
│
|
|
▼
|
|
Architektur (Markdown + PlantUML)
|
|
│
|
|
▼
|
|
Implementation (C, mit @arch + @reqs)
|
|
│
|
|
▼
|
|
Unit-Test (CppUTest-aehnliches Framework, mit @reqs)
|
|
│
|
|
▼
|
|
Pull Request (Branch -> main)
|
|
│
|
|
▼
|
|
CI: Build + Test + Coverage + MISRA + Traceability-Check
|
|
│
|
|
▼
|
|
Code-Review (Approval-Pflicht je nach ASIL)
|
|
│
|
|
▼
|
|
Merge nach main
|
|
│
|
|
▼ (bei Release-Punkt)
|
|
Tag v*.*.*
|
|
│
|
|
▼
|
|
CI Release-Workflow: Bundle + Gitea-Release
|
|
```
|
|
|
|
## 7. Freigabe-Strategie
|
|
|
|
- **Pull-Requests** brauchen mindestens 1 Approval (mehr fuer ASIL-C/D, siehe SWE-Plan)
|
|
- **Tags** im Format `vMAJOR.MINOR.PATCH` triggern den Release-Workflow
|
|
- **Release-Bundle** enthaelt Source + alle Reports + alle Word-Dokumente
|
|
- **Audit-Faehigkeit** ist jederzeit gegeben (Git-History + Doku-Lifecycle)
|
|
|
|
## 8. Wo Probleme melden
|
|
|
|
| Problem-Typ | Wo dokumentieren |
|
|
|-----------------------|-------------------------------------------------|
|
|
| Bug | Gitea Issue (Tag `bug`) |
|
|
| Anforderungs-Aenderung| Gitea Issue (Tag `requirement`) + Doorstop-Update |
|
|
| Non-Conformity | `docs/non-conformities-md/NC-XXX.md` -> Word |
|
|
| MISRA-Abweichung | `misra/records-md/MISRA-REC-XXX.md` -> Word |
|
|
| Sicherheits-Problem | Sofort an Safety Manager + NC |
|
|
|
|
## 9. Tools
|
|
|
|
Siehe `infrastructure/` im iCloud-Workspace fuer Setup-Details. Kurzform:
|
|
|
|
- **Gitea** (gitea.slohmaier.com) — Source-Control + CI + Releases
|
|
- **Doorstop-Stil** Markdown — Anforderungen + Architektur
|
|
- **PlantUML** — Diagramme (eingebettet)
|
|
- **Cppcheck** + **GCC -Werror** — Statische Analyse + MISRA
|
|
- **gcov/lcov** — Coverage
|
|
- **Doxygen** — API-Doc
|
|
- **pandoc** — Markdown -> Word/PDF
|
|
- **Python** (Stdlib) — Traceability + Report-Generatoren
|
|
|
|
## 10. Verwandte Dokumente
|
|
|
|
| Plan | Datei | Inhalt |
|
|
|----------------------|-------------------------------------|----------------------------------------|
|
|
| Project Initiation | `PID.docx` | Was + Warum |
|
|
| Projekt-Management | `PM-Plan.docx` | Arbeitspakete, Termine, Stakeholder |
|
|
| Quality Assurance | `QA-Plan.docx` | Reviews, Audits, NC-Management |
|
|
| Configuration Mgmt | `CM-Plan.docx` | Baselines, Releases, Change Control |
|
|
| Risk Management | `RM-Plan.docx` | Risiken, Mitigation, Monitoring |
|
|
| Software Development | `SWE-Plan.docx` | Sprache, Standards, Coverage-Ziele |
|
|
| Test | `Test-Plan.docx` | Test-Strategie |
|
|
|
|
## 11. Aenderungshistorie
|
|
|
|
| Version | Datum | Aenderung | Autor |
|
|
|---------|-------------|---------------------|-------------|
|
|
| 1.0 | 2026-05-12 | Erstfreigabe | S. Lohmaier |
|