# 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.