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.0 KiB
3.0 KiB
Quality Assurance Plan (QA Plan)
| Field | Value |
|---|---|
| Project | demo-epb |
| Date | 2026-05-11 |
| Version | 1.0 |
| Status | Released |
1. Quality goals
- Complete traceability: SYS → SA → SWE → SWA → Code → Test
- 0 MISRA Required violations (deviations documented)
- 0 static-analysis findings at High / Error level
- Coverage targets met (see SWE Plan section 8)
- All PRs reviewed and approved
2. Quality measures
| Measure | Tool / Method | Frequency |
|---|---|---|
| Traceability check | doorstop check |
every push |
| MISRA check | Cppcheck + MISRA addon | every push |
| Static analysis | Cppcheck, clang-tidy | every push |
| Unit tests | CppUTest | every push |
| Coverage | gcov / lcov | every push |
| Peer review | Gitea PRs | every change |
| Architecture review | Technical review, 2 approvers | on changes |
| Audit preparation | doorstop publish + Word docs | on release |
3. Reviews
| Artefact | Review type | Min. approvers |
|---|---|---|
| Requirements | Technical review | 1 |
| Architecture element | Technical review | 2 |
| Code (QM / ASIL-A/B) | Peer review | 1 |
| Code (ASIL-C/D) | Technical review | 2 |
| Plans and reports | Peer review | 1 |
| MISRA deviation permit | Technical lead | 1 |
4. Non-conformity management
Deviations from the plan or from requirements are documented as a non-conformity (NC):
- Path:
docs/non-conformities/NC-XXX.docx - Each NC has a unique ID
- Severity classification: Critical / Major / Minor
- Corrective action and verification are tracked
- Example NC present: NC-001
5. Audit preparation
Audit readiness is maintained continuously:
- Git history is the audit trail (no direct push to
main) docs/plans-md/holds the released plans (Word indocs/alongside)docs/traceability/holds the auto-generated matricesmisra/records/holds MISRA deviation recordstests/results/holds test and coverage reports (CI artefacts)docs/reviews/holds review minutes
6. Improvement actions
Every sprint closure includes a brief lessons-learned note in docs/lessons-learned/. Skipped in this demo because it is a single-sprint project.