Eje 14: Certificación (provisional)
Nota: Este capítulo describe planificaciones para la Fase 3 (Q2–Q4 2027). Las aptitudes para la certificación aquí esbozadas están previstas o planificadas. Su consecución depende del éxito de la comunidad y de la aceptación del GCBoK. En este momento (2026), nadie puede predecirlo con seriedad.
Objetivo
Establecer un esquema de certificación para el cumplimiento normativo nativo de Git basado en el GCBoK, que cumpla los requisitos estructurales de ISO/IEC 24773 (BoK como base para esquemas de certificación) — siempre que la comunidad adopte el GCBoK como estándar de referencia normativo.
ISO/IEC 24773 — Requisitos estructurales (resumen)
ISO/IEC 24773 define cómo debe estructurarse un Body of Knowledge (BoK) para que pueda servir como base para esquemas de certificación. Requisitos clave:
| Nivel | Término ISO/IEC 24773 | Equivalente GCBoK (estado) |
|---|---|---|
| 1 | Knowledge Areas (KAs) | 14 ejes (01–14) — disponibles |
| 2 | Competencies por KA | previsto — definir por eje |
| 3 | Learning Outcomes | planificado — objetivos de aprendizaje medibles por competencia |
| 4 | Assessment Criteria | previsto — criterios de evaluación para exámenes |
| 5 | Professional Roles | planificado — asignación de roles (p. ej., Compliance Engineer, Auditor) |
| 6 | Competency Levels | previsto — niveles (Entry / Practitioner / Expert) |
Enfoque planificado (Fase 3, Q2–Q4 2027)
1. Definición de competencias por eje (previsto)
Para cada uno de los 14 ejes se deberán formular 2–4 competencias. Ejemplo (eje 02 — Conceptos):
| ID de competencia | Título (título provisional) | Descripción (planificada) |
|---|---|---|
GCBOK-02-C1 |
Aplicar la clasificación V7GUID | Asignar de forma determinista la jerarquía L1–L6 + campos de identificación ampliados (RepositoryId, ProcessTypeId, GatewayId, VariantId) |
GCBOK-02-C2 |
Construir cadenas de evidencia (Evidence Chains) | Construir encadenamiento prev_sha256, firmas GPG, cadenas de evidencia V7GUID para comprobaciones GoBD |
GCBOK-02-C3 |
Validar la cadena de evidencia criptográfica | Verificar el hash de commit de Git + firma GPG + V7GUID como comprobación O(1) |
2. Resultados de aprendizaje por competencia (planificado)
Por cada competencia, 2–3 resultados de aprendizaje medibles (taxonomía de Bloom: Remember → Create).
Ejemplo GCBOK-02-C1:
| ID LO | Formulación (planificada) | Nivel Bloom |
|---|---|---|
GCBOK-02-C1-LO1 |
Poder explicar los seis niveles de jerarquía (L1–L6) y su anchura de 4 bits | Understand |
GCBOK-02-C1-LO2 |
Determinar la notación class correcta (L1_L2_L3_L4_L5_L6) para una evidencia dada |
Apply |
GCBOK-02-C1-LO3 |
Detectar y corregir una clasificación V7GUID errónea según las reglas del diccionario | Analyze |
3. Criterios de evaluación (previsto)
| Criterio | Descripción (prevista) |
|---|---|
| Examen teórico | Opción múltiple / respuesta corta sobre conceptos, definiciones, normas |
| Ejercicio práctico | En un entorno de prueba Git: generar V7GUID, crear sidecar, validar cadena de evidencia |
| Estudio de caso | Resolver un escenario de cumplimiento normativo dado (p. ej., cierre anual GoBD) con herramientas GCBoK |
4. Mapeo de roles profesionales (planificado)
| Rol | Ejes relevantes (ejemplo) | Nivel de certificación (previsto) |
|---|---|---|
| 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. Niveles de competencia (previsto)
| Nivel | Denominación | Requisitos (previstos) |
|---|---|---|
| Entry | Comprensión de fundamentos | Haber superado el examen teórico; haber leído los capítulos 01–06 del GCBoK |
| Practitioner | Competencia de usuario | Entry + ejercicio práctico + 1 estudio de caso; mínimo 1 año de experiencia en proyectos |
| Expert | Competencia de diseño | Practitioner + varios estudios de caso; contribución a la comunidad (PRs, revisiones, traducciones); mínimo 3 años de experiencia |
Dependencias y riesgos
| Factor | Influencia en la certificación |
|---|---|
| Aceptación de la comunidad | Sin un uso amplio del GCBoK como obra de referencia, no habrá demanda de certificación |
| Madurez de las herramientas | Webstatic, OPA, herramientas OSCAL deben ser estables y documentadas |
| Ecosistema de socios | Asociaciones BSI/ENISA (hoja de ruta Fase 3) como ancla de credibilidad |
| Marco legal | Los esquemas de certificación en DE/UE requieren acreditación (DAkkS o similar) |
Próximos pasos (provisionales)
- Recopilar feedback de la comunidad (Issues y Discusiones en Gitea) — ¿existe demanda?
- Desarrollar competencias piloto para 2–3 ejes (p. ej., 02, 04, 05) y someterlas a revisión
- Taller de resultados de aprendizaje con formadores/examinadores potenciales
- Herramientas de evaluación prototípicas (¿basadas en webstatic? ¿exportación OSCAL?)
- Decisión: continuar solo si hay respuesta positiva de la comunidad
Referencias
- ISO/IEC 24773:2019 — Software and systems engineering — Certification of software and systems engineering professionals
- GCBoK Capítulo 00 (Índice) — Posicionamiento como BoK
- GCBoK Capítulo 10 (Hoja de ruta) — Fase 3: Esquema de certificación (ISO/IEC 24773)
- GCBoK Capítulo 11 (Referencia GCC) — Finalidad sin ánimo de lucro y autoridad normativa