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.
64 lines
3.1 KiB
Markdown
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.
|