Files
demo-epb/docs/plans-md/PM-Plan.md
T
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
feat(i18n): full English translation of demo-epb
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.
2026-05-12 03:37:51 -07:00

64 lines
3.1 KiB
Markdown

# 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 `.md` file 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 |
| Email | 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.