slohmaier/demo-epb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity

feat(i18n): full English translation of demo-epb
Validate / build-test (macos-latest) (push) Failing after 3s
Details
Validate / build-test (windows-latest) (push) Failing after 15s
Details
Validate / build-test (ubuntu-latest) (push) Successful in 17s
Details
Validate / reports (push) Successful in 50s
Details
Release / release (push) Successful in 50s
Details

Browse Source 
Phase 2 of the English translation:

Word documents (filled, EPB-specific):
- 8 plans (PID, PM, QA, SWE, Test, Project Manual, CM, RM)
- 6 safety docs (HARA, Safety Case, FMEDA, MISRA Compliance,
  Verification Report, Tool Qualification Cppcheck)
- 2 manuals (User, Service)
- 3 audit artefacts (Review minutes, NC-001, MISRA-REC-001)
- All regenerated via pandoc from English markdown sources

Code, tests, headers:
- All file headers, struct comments, function docstrings in English
- All test names (TEST_BEGIN strings) translated
- Inline comments translated
- 46 tests still green after translation

CI workflows:
- All step names in English
- Step descriptions, comments, release notes template in English

README.md fully rewritten in English with proper guided tour.

Phase 3 (still pending): dev-process repo templates + toolstack/setup docs.
This commit is contained in:
Stefan Lohmaier
2026-05-12 03:37:51 -07:00
parent a47e0aed3e
commit fb2c083551
54 changed files with 1528 additions and 1600 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plans-md/PM-Plan.md
+44 -44
View File
@@ -1,63 +1,63 @@
# Projektmanagement-Plan (PM-Plan)
# Project Management Plan (PM Plan)
| Feld | Wert |
| Field | Value |
|-----------------|--------------------------------------|
| Projekt | demo-epb |
| Datum | 2026-05-11 |
| Project | demo-epb |
| Date | 2026-05-11 |
| Version | 1.0 |
| Status | Freigegeben |
| Status | Released |
---
## 1. Projektorganisation
## 1. Project organisation
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).
Single-person project with documented role separation. In a real project, QA, TL, and developer would be separate persons; here the audit trail is maintained through self-review with rationale (see SWE Plan, section 5).
## 2. Arbeitspakete
## 2. Work packages
| 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 |
| WP-ID | Work package | Owner | Status |
|-------|---------------------------------------------|----------------|--------|
| WP-01 | Project planning (PID, PM, QA, SWE, Test) | S. Lohmaier | Done |
| WP-02 | System Requirements (SYS-001..010) | S. Lohmaier | Done |
| WP-03 | Software Requirements (SWE-001..025) | S. Lohmaier | Done |
| WP-04 | System Architecture (SA-001..005) | S. Lohmaier | Done |
| WP-05 | Software Architecture (SWA-001..010) | S. Lohmaier | Done |
| WP-06 | Implementation of demo components | S. Lohmaier | Done |
| WP-07 | Unit tests + coverage | S. Lohmaier | Done |
| WP-08 | CI pipeline (Gitea Actions) | S. Lohmaier | Done |
| WP-09 | Audit artefacts (Review, NC, MISRA record) | S. Lohmaier | Done |
## 3. Aenderungsverwaltung
## 3. Change control
- 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
- Changes to released artefacts go through pull requests
- Every PR needs at least 1 approval (see SWE Plan, section 5)
- When requirements or architecture change, the traceability matrix must be regenerated (`doorstop publish`)
- Revision history is maintained inside the respective `.md` file or Word document
## 4. Konfigurationsmanagement
## 4. Configuration management
| 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 |
| Artefact type | Versioning | Baseline mechanism |
|-------------------|-----------------------|------------------------------------|
| Code | Git (Gitea) | Git tag (e.g. v1.0.0) |
| Requirements / Arch | Git + Doorstop | Git tag + doorstop publish |
| Word documents | Git | File version stamp + revision history in the document |
| CI configuration | Git | Version pin + tag |
## 5. Kommunikation
## 5. Communication
| Kanal | Zweck |
|---------------|-----------------------------------|
| Gitea Issues | Bug-Tracking, Tasks |
| Gitea PRs | Review, Approval, Audit-Trail |
| Matrix Chat | Schnelle Abstimmung |
| E-Mail | Formelle Freigaben (CC: Auftraggeber) |
| Channel | Purpose |
|---------------|--------------------------------------|
| Gitea Issues | Bug tracking, tasks |
| Gitea PRs | Review, approval, audit trail |
| Matrix chat | Quick alignment |
| Email | Formal releases (cc client) |
## 6. Berichtswesen
## 6. Reporting
- 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)
- Weekly status by email (in real projects)
- Audit report at project closure (PDF from Doorstop + Word plans)
- Coverage and MISRA reports are refreshed on every push (CI artefacts)
## 7. Abschluss
## 7. Closure
Projekt gilt als abgeschlossen, wenn alle Erfolgskriterien aus dem PID erfuellt sind und ein Git-Tag `v1.0` gesetzt ist.
The project is considered closed when all success criteria from the PID are met and the `v1.0` git tag is set.