Stefan Lohmaier
8ea3f3d8f4
The 25 files under templates-de/ lived in ~/ownCloud/Persönlich/slohmaier.com/vorlagen/
with no version control. They are the German-language counterpart of the
templates renamed to English in 247b831 — this repo already describes itself as
holding the ASPICE 4.0 / ISO 26262 methodology, templates and tools, so a
second home for templates would have been a duplicate.
Structure preserved as found (business/, engineering/, projekt/, qualitaet/).
No file renamed, no template content changed.
Not moved: vorlagen/slohmaier-doc-template.docx was byte-identical (MD5
31b2d0748eadf0314babf469725ee0b1) to templates-word/slohmaier-doc-template.docx
already in this repo.
Path references fixed in templates-de/README.md, which pointed at locations
that no longer exist: the ownCloud cp examples now clone from Gitea, the
generator script name follows the vorlagen/ -> templates/ rename
(generate_word_vorlagen.sh -> generate_word_templates.sh), the edit workflow
names templates/ and templates-de/ instead of the removed ownCloud copy, and
the master template is referenced at ../templates-word/.
6.3 KiB
6.3 KiB
Quality Assurance Plan (QA-Plan)
| Feld | Wert |
|---|---|
| Projekt | [Projektname] |
| Datum | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Entwurf / Freigegeben] |
| ASIL | [QM / A / B / C / D] |
1. QA-Aktivitaeten pro Phase
| Phase | QA-Aktivitaet | Verantwortlich |
|---|---|---|
| Anforderungsanalyse | Review der Anforderungen (Vollstaendigkeit, Konsistenz, Testbarkeit) | QA / Reviewer |
| Architektur | Architektur-Review (Modularitaet, Safety-Konzept) | QA / Reviewer |
| Implementierung | Code-Review (MR-Approval), MISRA-Pruefung (CI) | Reviewer / CI |
| Integration & Test | Test-Review, Coverage-Pruefung, Traceability-Check | QA / CI |
| Verifikation | Gesamtpruefung: alle Kriterien erfuellt? | QA |
| Release | Release-Audit: alle Work Products vollstaendig? | QA |
2. Zu pruefende Work Products
| Work Product | Review-Art | Pruefkriterien |
|---|---|---|
| PID | Peer Review | Vollstaendig, konsistent mit Vertrag |
| PM-Plan | Peer Review | Realistisch, Risiken adressiert |
| Software Requirements | Technical Review | Eindeutig, testbar, ASIL zugeordnet |
| Architektur-Dokumentation | Technical Review | Modular, Schnittstellen definiert, Safety-Konzept |
| Quellcode | Peer Review (MR) | MISRA-konform, getestet, lesbar |
| Unit Tests | Peer Review | Abdeckung, Randfaelle, Traceability |
| Testberichte | Peer Review | Pass/Fail dokumentiert, Coverage erreicht |
| MISRA Compliance Report | Peer Review | Abweichungen dokumentiert und genehmigt |
| Traceability-Matrix | QA-Pruefung | Keine Luecken, bidirektional |
3. Review-Arten
| Review-Art | Teilnehmer | Formalitaet | Wann |
|---|---|---|---|
| Peer Review | 1 Reviewer | Niedrig | Jeder MR, Dokument-Aenderungen |
| Technical Review | 2+ Reviewer, inkl. Tech Lead | Mittel | Architektur, Safety-Code, Plaene |
| Inspektion | Moderator + 2+ Reviewer | Hoch | Safety-kritische Artefakte (ASIL C/D) |
Peer Reviews laufen ueber GitLab MR-Approvals. Technical Reviews und Inspektionen werden zusaetzlich mit Review-Protokoll dokumentiert.
4. Entry/Exit-Kriterien
Entry-Kriterien (Beginn einer Phase)
| Phase | Entry-Kriterien |
|---|---|
| Architektur | Requirements reviewed und freigegeben |
| Implementierung | Architektur reviewed und freigegeben |
| Integration & Test | Code-Reviews abgeschlossen, Unit Tests gruen |
| Verifikation | Alle Tests durchgefuehrt, Coverage gemessen |
| Release | Alle Exit-Kriterien der Verifikation erfuellt |
Exit-Kriterien (Abschluss einer Phase)
| Phase | Exit-Kriterien |
|---|---|
| Anforderungen | Alle Requirements reviewed, ASIL zugeordnet, testbar |
| Architektur | Architektur reviewed, Schnittstellen definiert |
| Implementierung | MISRA-konform, Unit Tests gruen, Coverage-Ziel erreicht |
| Integration & Test | Integrationstests gruen, keine offenen Critical Findings |
| Verifikation | Traceability vollstaendig, alle Findings geschlossen oder bewertet |
| Release | Alle Work Products vollstaendig, QA-Freigabe erteilt |
5. Non-Conformity-Prozess
- Abweichung wird erkannt (Review, Audit, Test)
- Non-Conformity Report erstellen (GitLab Issue, Label:
non-conformity) - Schweregrad zuweisen: Critical / Major / Minor
- Ursachenanalyse durchfuehren
- Korrekturmassnahme definieren und umsetzen
- Wirksamkeitspruefung nach Umsetzung
- Issue schliessen mit Verweis auf Korrekturnachweis
Eskalation: Critical Non-Conformities werden sofort an den Auftraggeber gemeldet.
6. Reporting an Management
| Report | Haeufigkeit | Inhalt |
|---|---|---|
| QA-Status-Report | Pro Meilenstein | Offene Findings, NC-Status, Coverage-Stand |
| Meilenstein-Bewertung | Pro Phase-Ende | Entry/Exit-Kriterien geprueft |
| Release-Bewertung | Vor Release | Gesamtbewertung aller QA-Kriterien |
7. QA-Metriken
| Metrik | Ziel | Messung |
|---|---|---|
| Requirement Coverage | 100% | Anforderungen mit verlinktem Test |
| Code Coverage (Statement) | >= [X]% | gcov/lcov in CI |
| Code Coverage (Branch) | >= [X]% | gcov/lcov in CI |
| MC/DC Coverage (falls ASIL C/D) | >= [X]% | MCDC-Star / kommerziell |
| MISRA Violations | 0 (oder alle genehmigt) | Cppcheck MISRA-Addon in CI |
| Offene Findings (Critical) | 0 vor Release | GitLab Issues |
| Offene Non-Conformities | 0 Critical/Major | GitLab Issues |
| Review-Abdeckung | 100% MRs reviewed | GitLab MR-Approvals |
Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.