CMMI

Modelo + Evaluación · Examen ACL 2026

Qué es CMMI

Capability Maturity Model Integration. Desarrollado por el SEI (Software Engineering Institute) de Carnegie Mellon, financiado por el Departamento de Defensa de EEUU.

Guía a las organizaciones en cómo mejorar los procesos asociados al desarrollo y mantenimiento de software. ROI medio 4:1, incremento productividad 10–50%.

Idea clave CMMI dice QUÉ hay que hacer (prácticas). Los métodos y metodologías dicen CÓMO hacerlo.

Versiones

V1.3 Original

3 constelaciones independientes: CMMI-DEV (desarrollo), CMMI-ACQ (adquisición/subcontratación), CMMI-SVC (servicios a clientes).
Dos representaciones: Staged y Continuous.
16 PAs base + PAs específicas de cada constelación (CMMI-DEV añade PI, RD, SAM, TS, VAL, VER).
431 prácticas en total.

V2.0 ISACA

ISACA compra el CMMI Institute. Modelo único con arquitectura flexible.
Arquitectura totalmente Continua (Staged desaparece formalmente, pero existe mecanismo de equivalencia).
25 PAs totales, 18 comunes. Vista CMMI-DEV contiene 20 PAs.
Vistas predefinidas para evaluación: CMMI-DEV, CMMI-SVC, CMMI-SPM, People Management (CMMI-PPL).
Cada PA → Practice Groups (PG) numerados 1–5 (equivalentes al CL antiguo).
196 prácticas (frente a 431 de V1.3).

V3.0 Actual

Introduce dominios o dimensiones: DATA, DEV, PPL, SAF, SEC, SVC, SPM, VRT.
Nuevas PAs: DM, DQ (DATA), ESEC, MST (SEC), ESAF (SAF), EVW (VRT), WE (PPL).
Dominio DEV añade: TS (Technical Solution) + PI (Product Integration).

Dominio	Nombre	Qué cubre
`DEV`	Development	Ingeniería y desarrollo de productos software
`SVC`	Services	Gestión y entrega de servicios
`SPM`	Supplier Management	Gestión de proveedores y adquisiciones
`PPL`	People	Gestión y desarrollo de las personas (RR.HH.)
`DATA`	Data Management	Gobierno, calidad y gestión del ciclo de vida del dato
`SEC`	Security	Seguridad en el desarrollo y en la operación
`SAF`	Safety	Seguridad funcional y gestión de riesgos de seguridad física
`VRT`	Virtual/Remote Work	Trabajo en equipos distribuidos o virtuales

Estructura de una PA

Cada Process Area tiene una estructura fija con elementos Requeridos, Esperados e Informativos:

Elemento	Tipo	Descripción
Declaración del propósito	Informativo	Para qué sirve la PA
Notas introductorias	Informativo	Contexto y detalles adicionales
PAs relacionadas	Informativo	Otras PAs con las que interactúa
Metas específicas (SG)	Requerido	Objetivos propios de la PA
Prácticas específicas (SP)	Esperado	Cómo alcanzar las metas específicas
Ejemplo productos de trabajo / Subprácticas	Informativo	Evidencias y acciones concretas
Metas genéricas (GG)	Requerido	Objetivos de institucionalización (aplican a todas las PAs)
Prácticas genéricas (GP)	Esperado	Cómo alcanzar las metas genéricas
Subprácticas + Elaboraciones	Informativo	Orientación adicional

Leyenda del diagrama Requerido = rectángulo | Esperado = diamante | Informativo = elipse

Staged vs Continuous

Staged — Escalonado

Niveles de madurez 1–5
No es posible saltarse niveles
Resultado: nivel de madurez global de la organización
PAs agrupadas por nivel
Riesgo: "titulitis" → perseguir el nivel aunque los problemas reales estén en otras áreas

Nivel	Nombre	PAs
1	Inicial	—
2	Gestionado	REQM, PP, PMC, PPQA, MA, CM, SAM
3	Definido	DR, TS, VAL, VER, PI, IPM, DAR, OPD, OPF, OT, RISQM
4	Gest. Cuant.	OPP, QPM
5	Optimizado	OPM, CAR

Continuous — Continuo

Niveles de capacidad (CL) 1–5 por PA
Organización elige qué PAs mejorar y hasta qué CL
Enfoque flexible según necesidad real
Resultado: perfil de CLs por PA
Evita la titulitis: se trabaja lo que el negocio necesita

CL	Nombre
0	Incompleto
1	Realizado
2	Administrado
3	Definido
4	Cuantitativamente Administrado
5	Optimizado

Trampa de examen El modelo escalonado puede provocar "titulitis": mejorar áreas no críticas solo para subir de nivel, ignorando los problemas reales. La profesora lo compara con "tratar una pierna rota haciéndose la manicura".

CMMI V2.0 — Detalles

Arquitectura totalmente Continua. La representación Staged desaparece, pero existe un mecanismo de equivalencia para comparar con niveles.
Cada PA se divide en Practice Groups (PG) numerados 1 a 5 (equivalen al CL de la versión antigua continua).
Cada PG contiene Practices (prácticas concretas).
Vista CMMI-DEV: 20 PAs.

Tabla de PAs V2.0 — máximo nivel de cada PA

Verde = PG disponible. Rojo = PG no disponible para esa PA.

PA	CL1	CL2	CL3	CL4	CL5
CAR, DAR, RSK, OT, PCM, PAD, PR, VV, TS, PI, MPM, SAM, PQA	✓	✓	✓	✗	✗
CM, MC, PLAN, EST, RDM, GOV, II	✓	✓	✓	✗	✗
MPM (gestión rendimiento)	✓	✓	✓	✓	✓

Nota: CM llega hasta CL3 sin PG4/5 disponible. PLAN llega a CL4. Consultar tabla del slide para detalle exacto.

PAs y qué aspectos del ciclo de vida tratan

Las Core PAs de V2.0 (comunes a todas las vistas). Cada una cubre un aspecto concreto del ciclo de vida del software.

Requisitos y análisis Requisitos

RDM — Requirements Development & Management

Gestión de Requisitos

Extracción, análisis, trazabilidad bidireccional y control de requisitos. Desde necesidades del cliente hasta requisitos priorizados y comprometidos.

Estimación y planificación Planificación

EST — Estimating

Estimación

Calcular tamaño, esfuerzo, duración y coste basándose en datos históricos y métodos formales.

PLAN — Planning

Planificación de proyectos

Definir tareas, cronograma, recursos, compromisos y plan del proyecto. Usar procesos estándar de la organización.

Seguimiento y control Gestión

MC — Monitor and Control

Monitorización y Control

Supervisar resultados reales vs planes. Tomar medidas correctivas cuando hay desviaciones significativas.

RSK — Risk Opportunity Management

Gestión de Riesgos

Identificar, registrar, analizar y mitigar riesgos y oportunidades a lo largo de todo el proyecto.

SAM — Supplier Agreement Management

Gestión de Proveedores

Gestionar acuerdos con proveedores externos para asegurar que cumplen los requisitos establecidos.

Diseño, construcción e integración Desarrollo

TS — Technical Solution

Solución Técnica

Diseñar y construir la solución que cumpla los requisitos. Evaluar alternativas (crear/comprar/reutilizar). Dominio DEV.

PI — Product Integration

Integración del Producto

Ensamblar componentes, gestionar interfaces y entregar la solución integrada al cliente. Dominio DEV.

Verificación, validación y revisión Pruebas/QA

VV — Verification and Validation

Verificación y Validación

Verificar que los requisitos se implementan correctamente. Validar que la solución funciona en su entorno de destino.

PR — Peer Reviews

Revisiones entre pares

Revisar productos de trabajo por compañeros para detectar defectos de forma temprana antes de pruebas formales.

Configuración y calidad Transversal

CM — Configuration Management

Gestión de la Configuración

Control de versiones e integridad de productos. Líneas base, control de cambios, auditorías de configuración.

PQA — Process Quality Assurance

Aseguramiento Calidad del Proceso

Evaluaciones objetivas del cumplimiento de procesos y productos respecto a los estándares establecidos.

Organización Organización

PAD — Process Asset Development

Desarrollo de Activos de Proceso

Crear y mantener los activos de procesos organizacionales (fábrica). PAD = fábrica, PCM = estrategia.

PCM — Process Management

Gestión de Procesos

Planificación e implementación de mejoras de procesos. Estrategia organizacional de mejora.

OT — Organizational Training

Formación Organizacional

Desarrollar habilidades y conocimientos críticos en los equipos para soportar los procesos.

MPM — Managing Performance & Measurement

Gestión del Rendimiento y Medición

Establecer métricas de rendimiento y objetivos empresariales. Analizar datos para mejora continua.

GOV — Governance

Gobierno

Responsabilidad y patrocinio de la alta dirección en los procesos de mejora.

II — Implementation Infrastructure

Infraestructura de Implementación

Aporte de herramientas y recursos para soportar la implementación de los procesos.

DAR — Decision Analysis & Resolution

Análisis y Resolución de Decisiones

Metodologías estructuradas para la toma de decisiones formales con criterios y alternativas.

CAR — Causal Analysis & Resolution

Análisis Causal y Resolución

Identificación de causas raíz de defectos y problemas para prevenirlos en el futuro.

SCAMPI — Tipos de auditoría

SCAMPI (Standard CMMI Appraisal Method for Process Improvement) es el método oficial de evaluación. Hay 3 tipos según en qué momento del programa de mejora se aplican.

Ojo No hay certificación oficial CMMI. Solo los diplomas que emiten los evaluadores (Lead Appraiser). No es el SEI quien certifica.

Pregunta típica de examen ¿Cuáles son los tipos de SCAMPI y en qué parte del proceso de mejora se aplican?

SCAMPI A — Benchmark

Diploma oficial CMMI
El más riguroso
Muestreo aleatorio de evidencias
Válido 3 años
El más caro
Se aplica al FINAL del programa de mejora

SCAMPI B — Sustainment

No genera diploma
Mantener la madurez lograda
Extiende el resultado de A +2 años
Se aplica DURANTE el programa
Máximo 3 B antes de un nuevo A
Menos riguroso que A

SCAMPI C — Evaluation

No genera diploma
Foto rápida del estado actual
Se aplica al INICIO del programa
El menos riguroso
El más barato
Sirve para planificar la mejora

SCAMPI	Nombre	Diploma	Momento	Rigor / Coste
A	Benchmark appraisal	Sí — válido 3 años	Al FINAL	El más riguroso y caro
B	Sustainment appraisal	No	DURANTE (máx. 3)	Menos riguroso. Extiende A +2 años
C	Evaluation appraisal	No	Al INICIO	El menos riguroso y barato

Técnicas de auditoría: entrevistas y revisión documental.

Quién evalúa (I y II)

Quién evalúa (I) — Roles institucionales

Se suele pensar que evalúa el SEI por ser propietario de CMMI. No es cierto.
El SEI acredita a los auditores → Lead Appraiser (LA).
No es el SEI quien emite el diploma: son los LA y la empresa "SEI partner" en la que trabajan.
Tras el Benchmark appraisal, el LA envía documentación al SEI para que asegure la calidad.
Si todo va bien, los resultados se publican en el PARS (Published Appraisal Results).

Quién evalúa (II) — Participantes en un Benchmark Appraisal

Rol	Descripción
Sponsor	Lidera el proyecto de mejora. Normalmente un directivo de la organización.
Appraisal Team Leader (LA)	Jefe del equipo de evaluación. Responsable de realizar la evaluación. Es un Lead Appraiser certificado.
ATMs (Appraisal Team Members)	Miembros del equipo. Personal interno y/o externo con suficiente conocimiento y experiencia.
OUC (Organizational Unit Coordinator)	Coordinador de la organización. Actúa de interfaz entre el equipo evaluador y la empresa. Proporciona la información al evaluador. Normalmente es el responsable de calidad.
Participantes seleccionados	Jefes de proyecto o desarrolladores de los proyectos evaluados. Aportan información durante la evaluación.

Qué se evalúa

La empresa selecciona las PAs y sus PGs a evaluar.
Se define la unidad organizacional: qué parte de la organización queda dentro del alcance (un departamento, varios, tipo de proyectos, empresa completa...).
Se selecciona una muestra de proyectos representativa de la unidad organizacional.

Tipos de proyectos en la muestra

Tipo	Descripción	Obligatorio
Proyecto objetivo	Proporciona evidencia para todas las PAs a evaluar. No importa si ha terminado o no.	Al menos 1
Proyecto no objetivo / Función de apoyo	Aporta evidencia de alguna de las PAs. Sirve de apoyo al proyecto objetivo.	Opcional

Cómo se evalúa (I) — Evidencias objetivas

La auditoría comprueba que todos los PGs de las PAs han sido alcanzados. Se comprueban las practices. Cada practice deja un rastro (evidencia objetiva).

Tipos de evidencia objetiva

Tipo	Qué es	Cuándo
Artefacto	Salida directa o indirecta de la implementación de una práctica. Ej.: plan de proyecto, doc. de estimación, horas imputadas, registros...	Pre On-site
Afirmación	Confirmación en palabras o escritas que corrobora la implementación (entrevistas, cuestionarios). También pueden ser negativas.	On-site

Regla de oro Para validar una practice se busca: Artefacto AND Afirmación positiva. No basta solo uno de los dos.

Calificación de prácticas: FI / LI / PI / NI

Para cada practice se determina el grado de implementación:

Fully Implemented. Artefactos directos presentes y adecuados. Apoyados por artefactos indirectos y/o afirmaciones. No se detectan debilidades significativas.

Largely Implemented. Artefactos directos presentes y adecuados. Apoyados por evidencias. Se han notado una o más debilidades (ej.: criterios de análisis ambiguos).

Partially Implemented. Artefactos directos inadecuados o inexistentes. Artefactos indirectos y/o afirmaciones indican que parte de la práctica ha sido implementada.

Not Implemented. Artefactos directos inexistentes o inadecuados. No se encuentra otra evidencia que soporte la práctica.

PG satisfecho

Los PGs se evalúan como satisfechos o no satisfechos.

Regla clave — pregunta de examen Un PG se considera satisfecho si TODAS sus practices son FI o LI.
Sin embargo, aunque todas sean FI o LI, si la mayoría tienen debilidades podría considerarse que el PG NO ha sido satisfecho.

Si alguna practice es PI o NI → el PG no está satisfecho.
La evaluación es bottom-up: practice → PG → PA.

Fases de la evaluación

Pre On-Site (≈6 meses antes)

Presentar — Obtener compromiso de gerencia y organización. Al menos 6 meses antes. Sponsor + LA.

Planificar — ATMs, formación, unidad organizacional, muestra de proyectos, calendario, riesgos, logística. 4 meses antes. Sponsor + LA + OUC.

Preparar — Ejecutar formación, completar BDEO (Base de Datos Evidencias Objetivas), Readiness Review, completar Plan de Evaluación en SAS. Entre 4m y 2 semanas antes. LA + OUC + ATMs.

On-Site (5–10 días)

La BDEO y resto de información del sistema de calidad se copian a un repositorio aislado. Solo se añade información solicitada (no puede ser de nueva creación).

Revisión documental, entrevistas y cuestionarios. Reuniones: inicial, resultados preliminares, resultados finales.

Para cada practice: artefacto directo + (artefacto indirecto y/o afirmación). Participantes: LA + OUC + ATMs + representantes seleccionados.

"Lo que sucede en la evaluación, se queda en la evaluación." Confidencialidad.

Importante El incumplimiento de la regla de "no añadir nueva documentación durante el On-Site" puede causar fin de la evaluación.

Publicación (siguientes 2 semanas)

Completar el registro de evaluación en el SAS.

Anunciar los resultados a la organización.

Anunciar los resultados en prensa y publicaciones del sector.

Preguntas trampa clave

Afirmación	Verdad
"El SEI certifica a las empresas en CMMI."	FALSO No hay certificación oficial. Los diplomas los emiten los Lead Appraiser (LA), no el SEI. El SEI solo acredita a los LA.
"Para que un PG esté satisfecho basta con que la mayoría de sus practices sean FI o LI."	FALSO Deben ser TODAS FI o LI. Si alguna es PI o NI, el PG no está satisfecho.
"En el modelo Staged se pueden saltar niveles si se cumplen todos los requisitos."	FALSO No es posible saltarse niveles en el modelo escalonado.
"El modelo Continuous produce un nivel de madurez global de la organización."	FALSO Produce un perfil de CLs por PA. El nivel global es del modelo Staged (o mecanismo de equivalencia en V2.0).
"Una afirmación negativa en una entrevista no puede usarse como evidencia."	FALSO Las afirmaciones también pueden ser negativas y cuentan como evidencia.
"El OUC (Organizational Unit Coordinator) es siempre un auditor externo."	FALSO Es el coordinador interno de la organización, normalmente el responsable de calidad. Actúa de interfaz con el equipo evaluador.
"Durante el On-Site, la empresa puede añadir documentación nueva si el evaluador la solicita."	FALSO Solo se añade información que ya existía. Nueva documentación creada durante el On-Site no es válida y puede terminar la evaluación.
"El Sustainment appraisal tiene la misma extensión que el Benchmark."	FALSO Es una auditoría más reducida. Su objetivo es verificar que la madurez se mantiene.
"V2.0 es totalmente continuo y elimina la representación staged."	VERDADERO La arquitectura es totalmente continua, pero existe un mecanismo de equivalencia para comparar con niveles de madurez.
"TS y PI son PAs del dominio DEV, no del Core."	VERDADERO Son específicas del dominio Development (DEV). El resto de PAs son Core (comunes a todas las vistas).