feat(i18n): dev-process repo in English
- README.md: full English rewrite - All 13 vorlagen MD templates hand-translated: PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan, SA, SWA, Review-Protokoll, Non-Conformity, MISRA-Deviation-Permit, MISRA-Deviation-Record, Traceability-Matrix, angebot (quotation) - Master Word template (slohmaier-doc-template.docx) regenerated in English: cover page, document control, TOC headers, classification banner all English - All derived Word vorlagen regenerated from English MD sources Still to translate: toolstack.md, gitea-aspice-setup.md
This commit is contained in:
Stefan Lohmaier
+52
-62
@@ -1,85 +1,75 @@
|
||||
# Projektplan (PM-Plan)
|
||||
# Project Management Plan (PM Plan)
|
||||
|
||||
| Feld | Wert |
|
||||
|-----------------|-------------------------------|
|
||||
| Projekt | [Projektname] |
|
||||
| Datum | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Entwurf / Freigegeben] |
|
||||
| Bezug | PID Version [X.Y] |
|
||||
| Field | Value |
|
||||
|-----------------|--------------------------------|
|
||||
| Project | [Project name] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Draft / Released] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Projektphasen und Meilensteine
|
||||
## 1. Project organisation
|
||||
|
||||
| Phase | Start | Ende | Meilenstein |
|
||||
|------------------------|-------------|-------------|--------------------------------------|
|
||||
| Anforderungsanalyse | [Datum] | [Datum] | Requirements Complete |
|
||||
| Architektur | [Datum] | [Datum] | Architecture Complete |
|
||||
| Implementierung | [Datum] | [Datum] | Code Complete |
|
||||
| Integration & Test | [Datum] | [Datum] | Integration Complete |
|
||||
| Verifikation | [Datum] | [Datum] | Verification Complete |
|
||||
| Release | [Datum] | [Datum] | Release |
|
||||
[Describe organisation, roles, escalation path. Distinct from the role section in the PID — here you go into more detail on day-to-day collaboration.]
|
||||
|
||||
Phasen koennen ueberlappen (iterativ). Meilenstein-Kriterien sind im QA-Plan definiert.
|
||||
## 2. Work packages
|
||||
|
||||
## 2. Ressourcen und Rollen
|
||||
| WP-ID | Work package | Owner | Effort (PD) | Due | Status |
|
||||
|-------|------------------------|----------------|-------------|-----------|--------|
|
||||
| WP-01 | [name] | [Name] | [n] | [Date] | [open] |
|
||||
| WP-02 | [name] | [Name] | [n] | [Date] | [open] |
|
||||
|
||||
| Rolle | Person | Verfuegbarkeit | Aufgaben |
|
||||
|--------------------------|---------------------|-------------------|---------------------------------|
|
||||
| Projektleiter / Entwickler | Stefan Lohmaier | [X Tage/Woche] | Planung, Implementierung, Tests |
|
||||
| Reviewer | [Name / extern] | [nach Bedarf] | Code- und Dokument-Reviews |
|
||||
| QA | [Name / extern] | [nach Bedarf] | QA-Audits, Prozessueberwachung |
|
||||
| Auftraggeber | [Name] | [nach Bedarf] | Anforderungsklaerung, Abnahme |
|
||||
## 3. Schedule
|
||||
|
||||
## 3. Kommunikationsplan
|
||||
| Phase | Start | End | Result |
|
||||
|--------------------------|-------------|-------------|-------------------------------|
|
||||
| Concept | [Date] | [Date] | PID released |
|
||||
| Requirements | [Date] | [Date] | SRS released |
|
||||
| Architecture | [Date] | [Date] | Architecture document |
|
||||
| Implementation | [Date] | [Date] | Code complete |
|
||||
| Verification | [Date] | [Date] | Test report |
|
||||
| Release | [Date] | [Date] | Release package |
|
||||
|
||||
| Aktivitaet | Haeufigkeit | Teilnehmer | Medium |
|
||||
|--------------------------|--------------|---------------------------|---------------------|
|
||||
| Status-Update | [Woechentlich] | Auftraggeber, PL | E-Mail / Call |
|
||||
| Technische Abstimmung | [Nach Bedarf] | Entwickler, Auftraggeber | Call / GitLab Issue |
|
||||
| Meilenstein-Review | [Pro Phase] | Alle Beteiligten | Meeting |
|
||||
| QA-Report | [Pro Phase] | QA, PL, Auftraggeber | Dokument (Wiki) |
|
||||
## 4. Change management
|
||||
|
||||
## 4. Eskalationspfad
|
||||
- Changes go through change requests (CR)
|
||||
- CR ID: `CR-XXX`, tracked in Gitea Issues
|
||||
- For ASIL-relevant changes: re-run impacted reviews (architecture, code, tests)
|
||||
- Re-baselining via git tag (see CM Plan)
|
||||
|
||||
| Stufe | Situation | Eskalation an | Frist |
|
||||
|-------|----------------------------------------------|----------------------------|-------------|
|
||||
| 1 | Technische Blockade | Auftraggeber (technisch) | 2 Arbeitstage |
|
||||
| 2 | Terminverschiebung > 1 Woche | Projektverantwortlicher | 1 Arbeitstag |
|
||||
| 3 | Scope-Aenderung oder Safety-Concern | Management Auftraggeber | sofort |
|
||||
## 5. Communication
|
||||
|
||||
## 5. Aenderungsmanagement
|
||||
| Channel | Use | Frequency |
|
||||
|-----------------|--------------------------------------|-------------|
|
||||
| Gitea Issues | Tickets, bugs, change requests | as needed |
|
||||
| Gitea PRs | Reviews, approval, audit trail | per change |
|
||||
| Status report | Project status update | weekly |
|
||||
| Standup | Quick alignment | daily |
|
||||
| Review meeting | Architecture / design / code reviews | per CR |
|
||||
|
||||
Aenderungen an Anforderungen, Scope oder Zeitplan werden als Change Request behandelt:
|
||||
## 6. Risk management
|
||||
|
||||
1. Change Request als GitLab Issue erfassen (Label: `change-request`)
|
||||
2. Auswirkungsanalyse: betroffene Anforderungen, Code, Tests, Zeitplan
|
||||
3. Bewertung und Freigabe durch Auftraggeber
|
||||
4. Bei Freigabe: betroffene Work Products aktualisieren, Traceability nachfuehren
|
||||
5. Dokumentation der Aenderung im Issue (Begruendung, Auswirkung, Entscheidung)
|
||||
See `RM Plan` (separate document). Top-level summary here:
|
||||
|
||||
Keine Aenderung ohne dokumentierte Freigabe.
|
||||
| ID | Risk | Status |
|
||||
|------|----------------------------------|-------------|
|
||||
| R-01 | [Top risk] | [Mitigated] |
|
||||
| R-02 | [Top risk] | [Open] |
|
||||
|
||||
## 6. Risikomanagement
|
||||
## 7. Reporting
|
||||
|
||||
### Vorgehen
|
||||
- **Weekly status:** email to client with progress + open items
|
||||
- **Audit report:** at project closure, PDF from Doorstop + Word plans
|
||||
- **CI artefacts:** updated on every push (coverage, MISRA, traceability)
|
||||
|
||||
- Initiale Risiken im PID erfasst
|
||||
- Risikoliste wird pro Meilenstein-Review aktualisiert
|
||||
- Neue Risiken werden als GitLab Issues erfasst (Label: `risk`)
|
||||
- Jedes Risiko hat: Beschreibung, Wahrscheinlichkeit, Auswirkung, Massnahme, Verantwortlicher
|
||||
## 8. Closure
|
||||
|
||||
### Risiko-Bewertung
|
||||
|
||||
| Wahrscheinlichkeit / Auswirkung | Niedrig | Mittel | Hoch |
|
||||
|----------------------------------|---------|---------|---------|
|
||||
| Hoch | Mittel | Hoch | Kritisch|
|
||||
| Mittel | Niedrig | Mittel | Hoch |
|
||||
| Niedrig | Niedrig | Niedrig | Mittel |
|
||||
|
||||
Kritische Risiken werden sofort eskaliert (siehe Eskalationspfad Stufe 3).
|
||||
The project is considered closed when:
|
||||
- All success criteria from the PID are met
|
||||
- A `v1.0.0` git tag is set
|
||||
- The release package has been delivered to the client and accepted
|
||||
|
||||
---
|
||||
|
||||
*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*
|
||||
*Changes to this plan are versioned in the Gitea wiki.*
|
||||
|
||||
Reference in New Issue
Block a user