Achse 14: Zertifizierung (vorläufig)
Hinweis: Dieses Kapitel beschreibt Planungen für Phase 3 (Q2–Q4 2027). Die hier skizzierten Zertifizierungstauglichkeiten sind vorgesehen bzw. geplant. Ihr Erreichen ist abhängig vom Community-Erfolg und der Akzeptanz des GCBoK. Zum jetzigen Zeitpunkt (2026) kann das niemand ernsthaft vorhersagen.
Ziel
Ein Zertifizierungsschema für Git-native Compliance auf Basis des GCBoK zu etablieren, das die Strukturvorgaben von ISO/IEC 24773 (BoK als Grundlage für Zertifizierungsschemata) erfüllt — sofern die Community das GCBoK als normativen Referenzstandard annimmt.
ISO/IEC 24773 — Strukturvorgaben (Kurzüberblick)
ISO/IEC 24773 definiert, wie ein Body of Knowledge (BoK) aufgebaut sein muss, damit es als Basis für Zertifizierungsschemata dienen kann. Kernforderungen:
| Ebene | ISO/IEC 24773 Begriff | GCBoK-Entsprechung (Status) |
|---|---|---|
| 1 | Knowledge Areas (KAs) | 14 Achsen (01–14) — vorhanden |
| 2 | Competencies pro KA | vorgesehen — pro Achse definieren |
| 3 | Learning Outcomes | geplant — messbare Lernziele je Competency |
| 4 | Assessment Criteria | vorgesehen — Bewertungsmaßstäbe für Prüfungen |
| 5 | Professional Roles | geplant — Rollen-Zuordnung (z. B. Compliance Engineer, Auditor) |
| 6 | Competency Levels | vorgesehen — Stufen (Entry / Practitioner / Expert) |
Geplante Vorgehensweise (Phase 3, Q2–Q4 2027)
1. Competency-Definition pro Achse (vorgesehen)
Für jede der 14 Achsen sollen 2–4 Competencies formuliert werden. Beispiel (Achse 02 — Konzepte):
| Competency ID | Titel (Arbeitstitel) | Beschreibung (geplant) |
|---|---|---|
GCBOK-02-C1 |
V7GUID-Klassifikation anwenden | L1–L6 Hierarchie + erweiterte Kennfelder (RepositoryId, ProcessTypeId, GatewayId, VariantId) deterministisch zuordnen |
GCBOK-02-C2 |
Beleg-Ketten (Evidence Chains) konstruieren | prev_sha256-Verkettung, GPG-Signaturen, V7GUID-Belegketten für GoBD-Nachweise aufbauen |
GCBOK-02-C3 |
Cryptographic Evidence Chain validieren | Git-Commit-Hash + GPG-Signatur + V7GUID als O(1)-Prüfbarkeit verifizieren |
2. Learning Outcomes je Competency (geplant)
Pro Competency 2–3 messbare Learning Outcomes (Bloom-Taxonomie: Remember → Create).
Beispiel GCBOK-02-C1:
| LO ID | Formulierung (geplant) | Bloom-Stufe |
|---|---|---|
GCBOK-02-C1-LO1 |
Die sechs Hierarchie-Ebenen (L1–L6) und ihre 4-Bit-Breite erklären können | Understand |
GCBOK-02-C1-LO2 |
Für einen gegebenen Beleg die korrekte class-Notation (L1_L2_L3_L4_L5_L6) bestimmen |
Apply |
GCBOK-02-C1-LO3 |
Eine fehlerhafte V7GUID-Klassifikation anhand der Dictionary-Regeln erkennen und korrigieren | Analyze |
3. Assessment Criteria (vorgesehen)
| Kriterium | Beschreibung (vorgesehen) |
|---|---|
| Theoretische Prüfung | Multiple-Choice / Kurzantwort zu Konzepten, Definitionen, Normen |
| Praktische Übung | In einer Test-Git-Umgebung: V7GUID erzeugen, Sidecar anlegen, Beleg-Kette validieren |
| Fallstudie | Gegebenes Compliance-Szenario (z. B. GoBD-Jahresabschluss) mit GCBoK-Mitteln lösen |
4. Professional Roles Mapping (geplant)
| Rolle | Relevante Achsen (Beispiel) | Zertifizierungsstufe (vorgesehen) |
|---|---|---|
| Compliance Engineer | 01, 02, 04, 05, 06 | Practitioner |
| Git-native Auditor | 01, 02, 05, 07, 14 | Expert |
| Developer (GitCover Stack) | 02, 03, 04, 06 | Entry → Practitioner |
| PMO / Governance Lead | 01, 05, 07, 10, 14 | Practitioner → Expert |
5. Competency Levels (vorgesehen)
| Stufe | Bezeichnung | Voraussetzungen (vorgesehen) |
|---|---|---|
| Entry | Grundlagenverständnis | Theoretische Prüfung bestanden; GCBoK-Kapitel 01–06 gelesen |
| Practitioner | Anwenderkompetenz | Entry + praktische Übung + 1 Fallstudie; mind. 1 Jahr Projekterfahrung |
| Expert | Gestalterkompetenz | Practitioner + mehrere Fallstudien; Community-Beitrag (PRs, Reviews, Übersetzungen); mind. 3 Jahre Erfahrung |
Abhängigkeiten und Risiken
| Faktor | Einfluss auf Zertifizierung |
|---|---|
| Community-Akzeptanz | Ohne breite Nutzung des GCBoK als Referenzwerk keine Nachfrage nach Zertifizierung |
| Tool-Reife | Webstatic, OPA, OSCAL-Tooling müssen stabil und dokumentiert sein |
| Partner-Ökosystem | BSI/ENISA-Partnerschaften (Roadmap Phase 3) als Glaubwürdigkeitsanker |
| Rechtliche Rahmenbedingungen | Zertifizierungsschemata in DE/EU benötigen Akkreditierung (DAkkS o. ä.) |
Nächste Schritte (vorläufig)
- Community-Feedback einholen (Gitea Issues, Discussions) — ist Bedarf da?
- Pilot-Competencies für 2–3 Achsen (z. B. 02, 04, 05) ausarbeiten und reviewen
- Learning-Outcome-Workshop mit potenziellen Trainern/Prüfern
- Assessment-Tooling prototypisch (webstatic-basiert? OSCAL-Export?)
- Entscheidung: Weiterverfolgung nur bei positivem Community-Echo
Referenzen
- ISO/IEC 24773:2019 — Software and systems engineering — Certification of software and systems engineering professionals
- GCBoK Kapitel 00 (Index) — Positionierung als BoK
- GCBoK Kapitel 10 (Roadmap) — Phase 3: Zertifizierungsschema (ISO/IEC 24773)
- GCBoK Kapitel 11 (Referenz GCC) — Gemeinnützigkeit und normative Autorität