Stefan Lohmaier
fb2c083551
Validate / build-test (macos-latest) (push) Failing after 3s
Validate / build-test (windows-latest) (push) Failing after 15s
Validate / build-test (ubuntu-latest) (push) Successful in 17s
Validate / reports (push) Successful in 50s
Release / release (push) Successful in 50s
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.
3.1 KiB
3.1 KiB
Project Management Plan (PM Plan)
| Field | Value |
|---|---|
| Project | demo-epb |
| Date | 2026-05-11 |
| Version | 1.0 |
| Status | Released |
1. Project organisation
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. Work packages
| 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. Change control
- 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
.mdfile or Word document
4. Configuration management
| 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. Communication
| Channel | Purpose |
|---|---|
| Gitea Issues | Bug tracking, tasks |
| Gitea PRs | Review, approval, audit trail |
| Matrix chat | Quick alignment |
| Formal releases (cc client) |
6. Reporting
- 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. Closure
The project is considered closed when all success criteria from the PID are met and the v1.0 git tag is set.