Aseguramiento de la Calidad

1. Normas y estándares

ISO 9000, ISO 9001, ISO/IEC 15504, ITmark

ISO 9000

Vocabulario y fundamentos

Define los términos y conceptos del sistema de gestión de calidad. No contiene requisitos — solo vocabulario. Es la base terminológica para entender las demás normas de la familia.

ISO 9000 ≠ requisitos. Los requisitos están en ISO 9001.

ISO 9001

Requisitos del SGC

La norma certificable. Establece los requisitos que debe cumplir un sistema de gestión de calidad. Las empresas se certifican en ISO 9001, no en ISO 9000.

Cláusula 9.1.2: medir la satisfacción del cliente es obligatorio.

ISO/IEC 15504 · SPICE

Evaluación de procesos SW

Marco internacional para evaluar la madurez de procesos software. Define niveles de capacidad (0–5) por proceso. Base para CMMI y para la parte de proceso software de ITmark.

🎯 EXAMEN: AENOR vs ENAC (¡confunden siempre en el examen!)

🏭 AENOR

✅ NORMALIZA (elabora normas UNE)
✅ CERTIFICA empresas en ISO 9001
✅ Una de varias entidades certificadoras
❌ NO es "la encargada exclusiva"

🏛️ ENAC

✅ ACREDITA a organismos certificadores
✅ Verifica que AENOR es competente
❌ NO certifica empresas directamente
❌ NO emite normas

PREGUNTAS DE EXAMEN CLÁSICAS:
❌ "ENAC puede emitir normas" → FALSO
❌ "AENOR solo normaliza pero no certifica" → FALSO
✅ "AENOR hace las dos cosas: normalizar Y certificar" → VERDADERO

¿Quién certifica qué?

ISO 9001

Entidades de certificación acreditadas (ej. AENOR, Bureau Veritas, Lloyd's…). AENOR es la única que además normaliza — el resto solo certifican.

CMMI

No existe "certificado CMMI". El SEI autoriza Lead Appraisers que realizan la evaluación SCAMPI A y declaran el nivel obtenido.

ITmark

ESI (European Software Institute) gestiona la certificación ITmark para PYMES TIC europeas.

🎯 EXAMEN: Proceso de certificación ISO 9001 — 3 fases

1. Auditoría de evaluación previa

OPCIONAL · 2-3 meses antes

Evalúa conformidad con ISO 9001 y documentación del SGC
Permite identificar gaps y aplicar acciones correctivas/preventivas antes de la auditoría oficial
Simula la auditoría de certificación

2. Auditoría de certificación

OBLIGATORIA · Genera el certificado

Plan de auditoría → auditoría del manual + SGC → reunión inaugural → realización → reunión de clausura
Si hay NC menores: plan de acciones correctivas (6 meses para resolverlas)
Si hay NC mayores: no se certifica hasta resolverlas
Informe formal enviado 2-4 semanas después al representante de la dirección

3. Auditorías de seguimiento

Cada 6 meses · Durante 3 años

Verifican que se mantiene la conformidad con ISO 9001
Evalúan una parte del SGC cada vez
Nunca más de 12 meses entre auditorías
Al cabo de 3 años: nueva auditoría de certificación completa

🎯 EXAMEN: ISO 9001:2015 — 3 cambios principales

Pregunta de examen: "¿Cuáles son los cambios principales de ISO 9001:2015?"

1️⃣ GESTIÓN DE RIESGOS (NUEVO Y CENTRAL)

Reemplaza a las "acciones preventivas" de versiones anteriores. Ahora el riesgo es el eje central del PDCA (Plan-Do-Check-Act).

→ Obligatorio identificar y gestionar riesgos que puedan afectar al SGC.

2️⃣ INFORMACIÓN DOCUMENTADA (nueva terminología)

Reemplaza a "documentos + registros". Ahora se llama "información documentada" y puede estar en cualquier formato (papel, digital, etc.).

→ Más flexible. No es obligatorio tener manual de calidad por escrito.

3️⃣ SIN Representante de la Dirección OBLIGATORIO

En ISO 9001:2000/2008 era obligatorio un "Representante de la Dirección". En 2015, la Alta Dirección decide cómo distribuir funciones.

→ Mayor flexibilidad en la estructura.

Otros cambios: 10 apartados nuevos (vs 8 en 2000), concepto "productos y servicios", se habla de "aplicabilidad" en vez de "exclusiones".

📚 TEMARIO: 7 Principios de ISO 9000:2015

Base conceptual de todo SGC. Aunque sale poco en examen, estos 7 principios fundamentan ISO 9001:2015:

1. Enfoque al cliente

Comprender y satisfacer necesidades del cliente y partes interesadas.

2. Liderazgo

Establecer dirección, propósito y cultura de la organización.

3. Compromiso de las personas

Las personas, competentes y comprometidas, son esenciales.

4. Enfoque a procesos

Resultados consistentes se logran entendiendo y gestionando procesos interrelacionados.

5. Mejora

Las organizaciones deben mejorar continuamente su desempeño.

6. Toma de decisiones basada en evidencias

Decisiones efectivas basadas en análisis e evaluación de datos.

7. Gestión de las relaciones

La organización gestiona sus relaciones con todas las partes interesadas (proveedores, clientes, comunidad).

🎯 EXAMEN: Apartado 8 ISO 9001:2008 — Medición, análisis y mejora

Nota: En ISO 9001:2008 el apartado 8 era "Medición, análisis y mejora". En la versión 2015 este contenido pasó a los apartados 9 y 10, pero el examen pregunta por la versión 2008.

8.1 — Generalidades

Planificar e implementar los procesos de seguimiento, medición, análisis y mejora necesarios para demostrar conformidad del producto, del SGC y mejorar continuamente su eficacia.

8.2 — Seguimiento y medición

8.2.1 Satisfacción del cliente — obligatorio medirla
8.2.2 Auditoría interna — verificar conformidad con el SGC
8.2.3 Seguimiento y medición de procesos
8.2.4 Seguimiento y medición del producto

8.3 — Control del producto no conforme

Identificar y controlar productos que no cumplen requisitos. Opciones: corrección, reproceso, aceptación bajo concesión, o rechazo. Toda NC debe quedar registrada.

8.4 — Análisis de datos

Recopilar y analizar datos para evaluar: satisfacción del cliente, conformidad con requisitos del producto, características y tendencias de procesos, y desempeño de proveedores.

8.5 — Mejora

8.5.1 Mejora continua

Mejorar la eficacia del SGC mediante política, objetivos, resultados de auditorías, análisis de datos y acciones correctivas/preventivas.

8.5.2 Acción correctiva

Eliminar la causa raíz de una no conformidad ya ocurrida. Investigar, actuar, verificar eficacia.

8.5.3 Acción preventiva

Eliminar la causa de una no conformidad potencial antes de que ocurra. Solo en ISO 9001:2008 — en 2015 se reemplaza por gestión de riesgos.

🎯 EXAMEN: Métricas recomendadas para una PYME que empieza ISO 9000

Criterio: sencillas de recopilar, alto impacto, bajo coste de implantación.

1. Satisfacción del cliente

Encuesta simple post-entrega (1–5). Obligatoria por 8.2.1. Fácil de implementar.

2. Tasa de no conformidades

NC detectadas / total entregas. Mide calidad del proceso interno.

3. Desviación de plazo

(Fecha real − Fecha planificada) / días planificados. Detecta problemas de gestión.

4. Densidad de defectos

Defectos / KLOC (o por entregable). Mide calidad del producto antes de entrega.

Por qué estas 4: cubren las 4 áreas del 8.4 (cliente, producto, proceso, proveedor) con mínimo esfuerzo de recogida de datos.

📚 TEMARIO: ISO 90003 — Guía de aplicación de ISO 9001 al software

La norma ISO 9001 es genérica. ISO 90003 es la guía que explica cómo aplicar ISO 9001 al desarrollo de software. No añade ni modifica requisitos — interpreta cómo cumplirlos en contexto software.

¿Para qué sirve ISO 90003?

Proporciona guía para adquisición, suministro, desarrollo, operación y mantenimiento de software
Independiente de tecnología, ciclo de vida, proceso y estructura organizativa
Identifica todos los aspectos de ISO 9001 que deben tratarse en SW
Las directrices NO son criterios de certificación: se certifica en ISO 9001, no en ISO 90003

Versiones vigentes

ISO/IEC/IEEE 90003:2018 — aplicación de ISO 9001:2015 al software. Vigente desde 29/11/2018
En España: PNE-ISO/IEC DIS 90003 (proyecto de norma española, publicado 15/03/2018 en BOE)
Surge porque ISO 9001 sola es demasiado genérica para proyectos de desarrollo SW

Relación familia ISO 9000: ISO 9000 (vocabulario) + ISO 9001 (requisitos, base de certificación) + ISO 9004 (mejora sostenida, va más allá de la certificación) + ISO 90003 (guía aplicación al SW). Para certificarse: solo ISO 9001.

10 pasos para llegar a la certificación ISO 9001

1

Establecer plan de trabajo: ¿dónde está? ¿a dónde va?

2

Iniciar proyecto de mejora con formación y voluntad de toda la empresa

3

Manual de calidad: ¿qué entiende la empresa por calidad?

4

Manual de procesos: ¿cómo se desarrolla el trabajo?

5

Implantar el SGC progresivamente, via proyectos piloto

6

Recoger datos para mejorar el sistema y comprometer a todos

7

Mejorar el sistema en base a los datos recogidos

8

Obtener certificación (si se desea): reconocimiento externo e independiente

9

Difundir públicamente el reconocimiento obtenido

10

Seguir trabajando para mejorar continuamente

2. Conceptos de calidad

Registro de calidad, no conformidad, satisfacción del cliente

Registro de calidad

Documento que proporciona evidencia objetiva de actividades realizadas o resultados obtenidos. A diferencia de otros documentos, los registros no se modifican: son la "huella" inmutable del proceso.

Ejemplos: actas de revisión, resultados de pruebas, informes de auditoría, registros de no conformidades.

No conformidad (NC)

Incumplimiento de un requisito. Puede ser de producto (el producto no cumple lo especificado) o de proceso (no se sigue el proceso definido).

Toda NC debe quedar registrada, tener un responsable, una acción correctiva y seguimiento hasta su cierre.

🎯 EXAMEN: La Crisis del Software (Datos históricos)

Estos porcentajes salen en examen. Apréndelos:

📉 DoD Americano, 1979 ($6.8 millones en proyectos software):

📌 48% — Entregado pero NUNCA USADO
📌 29% — Pagado pero NUNCA ENTREGADO
📌 19% — Usado con trabajo extra o abandonado
📌 3% — Usado después de cambios importantes
📌 1% — Usado tal como se entregó

→ Solo 4% fue realmente útil. 77% fue un fracaso total.

📈 Chaos Report (mejora histórica 1994-2006):

Evolución de proyectos EXITOSOS:

1994
16%

1996
27%

1998
26%

2000
28%

2006
35%

⚠️ El doble en 12 años, pero sigue siendo bajo. Proyectos fallidos: 31% (1994) → 19% (2006). El ROI de mejorar con CMM: 5:1.

Aseguramiento de Calidad (ACL / QA)

PROCESO. Verifica que el equipo sigue los procedimientos definidos. Se hace mediante auditorías internas.

¿Estamos haciendo las cosas como dijimos?

Ejemplo: Auditoría interna que verifica que el equipo usa plantillas, documentación correcta y realiza revisiones obligatorias.

Control de Calidad (CC / QC)

PRODUCTO. Verifica que el producto cumple requisitos. Revisiones técnicas, inspecciones, pruebas.

¿Lo que hemos hecho está bien?

Ejemplo: Revisión técnica formal del código (peer review) para detectar defectos antes de pruebas.

🎯 EXAMEN: Explica QA vs QC con ejemplos

Pregunta típica en examen: "Explica y da ejemplo de Aseguramiento (QA) y Control (QC) de Calidad"

🔵 QA — Aseguramiento

Orientación: PROCESO (¿lo estamos haciendo bien?)

Método: AUDITORÍAS internas

Quién: Responsable de Calidad (auditor independiente)

Ejemplo: El RC audita un proyecto y verifica que se usan plantillas correctas, se realizan revisiones obligatorias de fase (requisitos, programación, pruebas), existe plan de calidad y se siguen los procedimientos del SGC.

🔴 QC — Control

Orientación: PRODUCTO (¿lo que hacemos cumple requisitos?)

Método: REVISIONES TÉCNICAS, inspecciones, pruebas

Quién: Testers, revisores técnicos

Ejemplo: Revisión técnica formal del código (peer review) donde se detectan defectos antes de las pruebas. O pruebas unitarias/integración/sistema/aceptación que verifican que el producto funciona.

3. Auditorías

Tipos, proceso y perfil del auditor

1ª

Auditoría interna

La organización se audita a sí misma. El auditor debe ser independiente del área auditada (no puede auditar su propio trabajo).

2ª

Auditoría de cliente

El cliente audita a su proveedor para verificar que cumple los requisitos del contrato o de la norma exigida.

3ª

Auditoría de certificación

La única que puede otorgar un certificado. La realiza un organismo externo independiente, acreditado por la norma correspondiente.

Perfil del auditor

Independencia

No puede auditar su propio trabajo ni tener relación jerárquica con el auditado. Sin independencia, las conclusiones no son fiables.

Competencia técnica

Debe conocer el área o proceso que audita. No puede valorar conformidad sin entender qué se está haciendo.

Objetividad e imparcialidad

Sus conclusiones deben basarse exclusivamente en evidencias, no en opiniones o relaciones personales.

Evidencias objetivas en una auditoría

Son los datos que soportan las conclusiones. Sin evidencia, no hay hallazgo. Se recogen en una base de datos de evidencias durante la evaluación.

Directas

Artefactos producidos por el proceso: documentos, código, actas, planes. Las más fuertes.

Indirectas

Indicadores de que el proceso ocurrió: referencias en otros documentos, registros de herramientas.

Afirmaciones

Declaraciones de personas durante entrevistas. Válidas pero necesitan respaldo de evidencias más sólidas.

🎯 EXAMEN: Características del auditor (REPITE EN TODOS LOS EXÁMENES)

Esta pregunta sale casi idéntica en cada examen. Debes saberla de memoria:

Un auditor debe poseer 3 características OBLIGATORIAS:

🎯 1. INDEPENDENCIA
No puede auditar su propio trabajo. No puede tener relaciones jerárquicas con el auditado. Sin independencia, las conclusiones pierden credibilidad.
📊 2. OBJETIVIDAD
Sus conclusiones se basan SOLO en evidencias objetivas (artefactos, datos, afirmaciones documentadas). Nunca en opiniones personales o relaciones.
🧠 3. COMPETENCIA
Debe estar formado y ser experto en el área o proceso que audita. No puede evaluar lo que no entiende.

Cualquier definición que incluya estas 3 es correcta. A veces añaden: imparcialidad, ética, confidencialidad (pero las 3 obligatorias son siempre estas).

4. Métricas de calidad

PSM, catálogo de métricas, medición y análisis

PSM — Practical Software Measurement

Modelo/guía del Departamento de Defensa de EE.UU. para definir e implementar métricas en proyectos software. Proporciona un proceso estructurado: necesidades de información → métricas → datos.

Alineado con CMMI (PA de Measurement and Analysis — MA).

Categorías del catálogo de métricas

Proyecto Desviación de plazo, coste, progreso, esfuerzo en ACL por proyecto.

Producto Densidad de defectos, cobertura de pruebas, complejidad ciclomática, LOC.

Proceso Tiempo medio en ACL por proyecto, tasa de no conformidades, efectividad de revisiones.

Métricas de progreso de proyecto

Permiten comparar el avance real del proyecto con lo planificado. Ejemplos habituales:

Tiempo medio en ACL Σ horas ACL / nº proyectos

Densidad de defectos nº defectos / KLOC

Efectividad de revisiones defectos revisión / total defectos

Desviación de plazo (real - planificado) / planificado

🎯 EXAMEN: Los 8 campos de una métrica (APARECE EN EXAMEN)

Pregunta típica: "Define los campos que debe tener una métrica"

1️⃣ Nombre

Identificación descriptiva de la métrica.

2️⃣ Objetivo

¿Para qué sirve? ¿Qué queremos conocer?

3️⃣ Fórmula de cálculo

La expresión matemática exacta.

4️⃣ Unidad de medida

Horas, %, KLOC, hombre-día, etc.

5️⃣ Origen de los datos

¿De dónde extraemos los datos?

6️⃣ Datos de entrada

¿Qué datos necesitamos recopilar?

7️⃣ Periodo

¿Cada cuándo se mide? ¿Por proyecto?

8️⃣ Criterios de análisis

¿Cuándo es "bueno", "malo" o "aceptable"?

EJEMPLO PRÁCTICO (Junio 2019):
Si te piden: "Define una métrica: tiempo medio invertido en revisiones de progreso"
Debes indicar nombre, objetivo, fórmula (Σ horas × asistentes / nº revisiones), unidad (h·h), origen (registros), datos (horas inicio-fin), periodo (por proyecto), y criterios (> 2 h·h investigar).

GQM — Goal Question Metric Medición hasta cuadro de mando

Método estructurado para definir métricas partiendo de objetivos de negocio, no del revés. Evita recoger datos que nadie usa.

G

Goal (Objetivo)

¿Qué queremos mejorar? Ej: "Reducir los defectos en entrega"

Q

Question (Pregunta)

¿Qué debemos saber para medir ese objetivo? Ej: "¿Cuántos defectos se detectan en producción?"

M

Metric (Métrica)

Dato concreto que responde la pregunta. Ej: "Densidad de defectos en prod = defectos / KLOC"

Ejemplo GQM completo: Goal = "mejorar calidad de pruebas" → Question = "¿qué % del código se cubre?" → Metric = "Cobertura de pruebas = LOC probadas / LOC totales × 100%"

Cuadro de Mando de Calidad (Balanced Scorecard aplicado al SW)

Herramienta para integrar las métricas de calidad en 4 perspectivas que dan una visión global del estado del proceso y el producto.

Perspectiva	¿Qué mide?	Métricas ejemplo
Financiera	Coste de la calidad y ROI del esfuerzo en ACL	Coste de no conformidades, ROI de auditorías, % presupuesto en ACL
Cliente	Satisfacción del cliente y calidad percibida	Índice satisfacción cliente, defectos reportados post-entrega, reclamaciones
Procesos internos	Calidad del proceso de desarrollo	Densidad defectos, cobertura pruebas, eficacia de revisiones, NC cerradas/abiertas
Aprendizaje	Capacidad de mejora continua de la organización	Nivel CMMI alcanzado, % personal formado en calidad, lecciones aprendidas documentadas

5. CMMI — Capability Maturity Model Integration

Modelo de madurez, versiones, constelaciones y áreas de proceso

🎯 CONTENIDO EXAMEN

Lo más importante para el examen. Estos conceptos aparecen en todos los exámenes: niveles, PAs básicas, constelaciones, diferencia Staged/Continuous.

📚 TEMARIO COMPLETO

Resumen extenso de la asignatura. Detalles teóricos que complementan pero no son críticos para el examen.

¿Qué es CMMI?

Modelo desarrollado por el SEI (Software Engineering Institute) de la Carnegie Mellon University, financiado por el Departamento de Defensa de EE.UU. Proporciona un framework para mejorar procesos de desarrollo y mantenimiento de software, con potencial de 10-50% incremento de productividad y ROI 4:1.

CMMI no es una norma certificable como ISO 9001 — es un modelo de referencia. La evaluación de cumplimiento se realiza mediante SCAMPI.

Constelaciones de CMMI (versión 1.3)

CMMI tiene tres constelaciones originales, cada una enfocada a un contexto diferente:

CMMI-DEV

Desarrollo de productos y servicios software. La más común.

CMMI-ACQ

Calidad en la adquisición/compra de productos y servicios (subcontratación).

CMMI-SVC

Gestión de servicios a clientes (helpdesk, soporte, operaciones).

CMMI Staged

Propone 5 niveles de madurez sucesivos. Cada nivel se alcanza cuando se satisfacen todas las metas de sus PAs. No se puede saltarse niveles.

Es la representación más clásica. Un empresa va nivel 1 → 2 → 3 → 4 → 5.

CMMI Continuous

Se trabaja PA por PA, no por niveles. Cada PA tiene su propio Nivel de Capacidad (CL 0–5). La organización elige cuáles mejorar según sus objetivos.

Flexible: una empresa puede tener CL4 en Estimación y CL2 en Verificación.

5 Niveles CMMI Staged

Nivel	Nombre	Áreas de proceso (PA) representativas	Qué caracteriza este nivel
Nivel 1	Inicial	Ninguna definida	Procesos ad hoc. El éxito depende de las personas, no del proceso. Sin garantía de repetibilidad.
Nivel 2	Gestionado	REQM PP PMC MA PPQA CM SAM	Procesos planificados y gestionados a nivel de proyecto. Gestión de requisitos, planificación, seguimiento, QA y configuración. Repetibilidad a nivel proyecto.
Nivel 3	Definido	RD TS PI VER VAL DAR OPD OT	Institucionalización. Procesos estándar de toda la organización, no solo proyectos individuales. Arquitectura, verificación, validación, formación organizacional.
Nivel 4	Gestionado cuantitativamente	QPM OPP	Gestión estadística. Procesos controlados mediante técnicas cuantitativas y control estadístico. Predicción de calidad mediante datos.
Nivel 5	En optimización	CAR OPM	Mejora continua cuantitativa. Prevención de defectos y gestión del cambio basadas en análisis de causas raíz e innovación.

Metas vs. Prácticas en CMMI

SG — Metas Obligatorias. Un PA se satisface sólo si se logran todas sus metas. Si falla una, el PA entero no se cumple.

SP — Prácticas Esperadas pero intercambiables. Son la forma recomendada de lograr cada meta, pero se puede demostrar equivalencia con otras prácticas.

PA clave: PPQA (Nivel 2)

Process and Product Quality Assurance. El aseguramiento formal de calidad en CMMI. Audita que los procesos se siguen y que los productos cumplen los planes.

Ejemplo: revisar que el plan de pruebas se ejecuta correctamente en cada entrega.

CMMI 3.0 — Nueva arquitectura

Comprada por ISACA en 2018 y modernizada. Cambios principales:

Más Practice Areas

Pasó de 16 a 25 PAs para cubrir nuevas dimensiones: datos, seguridad, personas, trabajo virtual.

Arquitectura continua por defecto

Ahora todo es Continuous, con vistas predefinidas para comparación con versiones Staged antiguas.

Nuevos dominios

DATA (gestión de datos), SAF (seguridad), VRT (trabajo virtual), PPL (personas).

431 → 196 prácticas

Se redujeron de forma significativa para simplificar implementación.

📚 TEMARIO: Los 8 dominios de CMMI 3.0

Estos 8 dominios cubren todas las dimensiones de calidad en la organización:

1. DEV (Development) — Desarrollo de software. Las PAs clásicas de CMMI.

2. SVC (Services) — Gestión de servicios y soporte a clientes.

3. SPM (Supplier Management) — Gestión de proveedores y subcontratistas.

4. PPL (People/Workforce) — Gestión y desarrollo de personas.

5. SAF (Safety) — Seguridad de sistemas críticos.

6. SEC (Security) — Seguridad informática y datos.

7. DATA — Gestión de datos, calidad de datos.

8. VRT (Virtual Work) — Trabajo virtual y colaborativo.

📚 TEMARIO: 16 Core PAs (presentes en TODOS los dominios)

Estas 16 PAs son transversales y aparecen en todos los dominios:

• CAR — Causal Analysis & Resolution

• CM — Configuration Management

• DAR — Decision Analysis & Resolution

• EST — Estimating

• GOV — Governance

• II — Implementation Infrastructure

• MC — Monitor & Control

• MPM — Managing Performance & Measurement

• OT — Organizational Training

• PAD — Process Asset Development

• PCM — Process Change Management

• PLAN — Planning

• PQA — Process Quality Assurance

• PR — Peer Reviews

• RDM — Requirements Development & Management

• RSK — Risk & Opportunity Management

★ CRÍTICO: IMP — Implementation (nueva PA clave de CMMI 3.0)

IMP con 22 prácticas es la PA más grande de CMMI 3.0. Cubre la implementación del proceso de mejora con 5 niveles de capacidad:

Nivel	Qué hace IMP en ese nivel
N1	Recopilar datos para identificar y abordar los problemas de rendimiento.
N2	Objetivos de medición y rendimiento basados en necesidades del negocio. Definiciones operativas para las medidas. Recopilar, analizar y almacenar datos, tomando acciones correctivas.
N3	Enfoque organizacional. Proceso de calidad de datos. Repositorio de mediciones actualizado y utilizado. Los datos se analizan para mejorar. Comunicación periódica de resultados de rendimiento.
N4	Métodos estadísticos y cuantitativos. Seleccionar técnicas analíticas para gestionar el rendimiento y alcanzar las metas. Establecer modelos y parámetros de referencia de rendimiento. Predecir el logro de los objetivos.
N5	Técnicas estadísticas y cuantitativas para optimizar el rendimiento. Analizar datos de rendimiento para identificar áreas de mejora. Seleccionar e implementar propuestas de mejora basadas en su impacto potencial.

PAs clave de CMMI 3.0 — Resumen de niveles de capacidad

Las PAs más importantes para el examen, con lo que añade cada nivel:

PA	Nivel 1	Nivel 2	Nivel 3
RDM Requisitos	Registrar requisitos	Recopilar necesidades, trazabilidad bidireccional, obtener compromisos	Escenarios operativos, requisitos de interfaz, validar requisitos
PLAN Planificación	Lista de tareas + asignar personas	Presupuesto, cronograma, stakeholders, plan del proyecto	Procesos estándar org., activos organizacionales, repositorio mediciones
MC Seguimiento	Registrar finalización de tareas, resolver problemas	Supervisar reales vs estimados, tomar medidas correctivas ante desviaciones	Procesos estándar org., gestionar dependencias críticas, resolver con stakeholders
PQA Calidad	Identificar y abordar problemas de procesos/productos	Plan de QA con histórico, evaluar objetivamente, comunicar incumplimientos	Identificar y registrar oportunidades de mejora descubiertas en QA
CM Config.	Control de versiones básico	Identificar EC, líneas base, gestionar cambios, auditorías de configuración	(CM solo tiene N1 y N2)
VV Verif./Valid.	Realizar verificaciones y validaciones	Seleccionar componentes y métodos, desarrollar entorno V&V, registrar resultados	Criterios de V&V coherentes, analizar y comunicar resultados
PI Integración	Ensamblar la solución y entregarla al cliente	Estrategia y entorno de integración, procedimientos y criterios, confirmar componentes	Revisar interfaces periódicamente, confirmar compatibilidad

🎯 EXAMEN CRÍTICO: Las 22 PAs de CMMI-DEV V1.3

La profe pregunta: "esta actividad, ¿en qué PA entra y en qué nivel?"

Las marcadas con ★ CRÍTICA son las que más confunden y más se preguntan en examen.

NIVEL 2 — Managed · 7 PAs · Procesos controlados a nivel de proyecto

REQM N2 Requirements Management ★ CRÍTICA

Gestionar requisitos ya existentes: rastrear cambios, mantener trazabilidad entre requisitos y productos de trabajo, confirmar coherencia con el plan.

Confusión frecuente: REQM gestiona requisitos que ya existen. RD (N3) los crea.

PP N2 Project Planning ★ CRÍTICA

Estimar tamaño y esfuerzo. Crear el plan de proyecto. Planificar recursos, calendario y riesgos iniciales. Obtener compromisos de los participantes.

Confusión frecuente: PP crea el plan. PMC hace el seguimiento del plan ya creado.

PMC N2 Project Monitoring & Control ★ CRÍTICA

Seguimiento de hitos y progreso. Comparar avance real vs. plan. Tomar acciones correctivas cuando hay desviación. Revisar el estado del proyecto.

Clave: cualquier actividad de "comparar con el plan" o "acción correctiva" → PMC, no PP.

SAM N2 Supplier Agreement Management

Gestionar contratos con proveedores externos. Seleccionar y evaluar subcontratistas. Revisar entregables de terceros. Acordar requisitos con proveedores.

MA N2 Measurement & Analysis ★ CRÍTICA

Definir métricas del proyecto. Recolectar y almacenar datos de medición. Analizar resultados y reportarlos a la dirección.

Clave: todo lo que sea "métricas", "medir", "recolectar datos" en N2 → MA.

PPQA N2 Process & Product Quality Assurance

Auditar que los procesos se siguen correctamente. Revisar que los productos cumplen estándares. Reportar no-conformidades con objetividad e independencia.

CM N2 Configuration Management

Control de versiones de código y documentos. Gestionar baselines de configuración. Controlar solicitudes de cambio. Mantener integridad de la configuración.

NIVEL 3 — Defined · 11 PAs · Procesos estandarizados a nivel de ORGANIZACIÓN

RD N3 Requirements Development ★ CRÍTICA

CREAR requisitos: elicitar necesidades del cliente, analizar y elaborar requisitos, crear casos de uso, derivar requisitos del sistema y del software.

Confusión frecuente: RD crea requisitos nuevos. REQM (N2) gestiona los que ya existen.

TS N3 Technical Solution ★ CRÍTICA

Diseñar la arquitectura del sistema. Evaluar alternativas: Crear / Comprar / Reutilizar. Diseño detallado de componentes. Implementar el código.

Clave: "diseño de arquitectura", "crear/comprar/reutilizar" y "implementación" → siempre TS.

PI N3 Product Integration

Integrar componentes de software. Gestionar interfaces entre componentes. Verificar que la integración produce el sistema deseado.

VER N3 Verification ★ CRÍTICA

¿Lo construimos correctamente? Peer reviews (revisiones entre pares), inspecciones de código, pruebas técnicas internas. Verificación por el propio equipo.

Confusión frecuente: VER es interno (equipo). VAL es con el cliente.

VAL N3 Validation ★ CRÍTICA

¿Construimos lo correcto? Pruebas de aceptación con el cliente. Validar que el producto satisface necesidades reales. Demo al usuario final.

Confusión frecuente: VAL es con el cliente (externo). VER es el equipo revisando internamente.

OPF N3 Organizational Process Focus ★ CRÍTICA

Evaluar los procesos de la organización (ej. mediante SCAMPI). Planificar y coordinar mejoras de proceso. Aprender de evaluaciones y resultados.

Confusión frecuente: OPF planifica y coordina mejoras. OPD define y documenta el proceso estándar.

OPD N3 Organizational Process Definition ★ CRÍTICA

Crear y mantener la biblioteca de activos de proceso. Definir el proceso estándar de la organización. Gestionar activos de proceso reutilizables.

Confusión frecuente: OPD define el proceso estándar. OPF lo evalúa y mejora.

OT N3 Organizational Training

Identificar necesidades de formación organizacional. Crear plan de formación. Impartir cursos y certificaciones. Evaluar efectividad del entrenamiento.

IPM N3 Integrated Project Management

Adaptar y usar el proceso estándar de la organización en el proyecto concreto. Coordinar con equipos y partes interesadas. Gestionar el entorno de trabajo.

RSKM N3 Risk Management

Identificar y catalogar riesgos. Analizar probabilidad e impacto. Crear planes de mitigación. Monitorizar riesgos activamente durante el proyecto.

DAR N3 Decision Analysis & Resolution

Toma de decisiones formal con criterios explícitos y documentados. Evaluar alternativas técnicas. Seleccionar herramientas o tecnologías con criterios objetivos.

NIVEL 4 — Quantitatively Managed · 2 PAs · Gestión cuantitativa y estadística

OPP N4 Organizational Process Performance

Establecer baselines cuantitativas del rendimiento de procesos. Crear modelos estadísticos. Medir capacidad y variación de los procesos de la organización.

QPM N4 Quantitative Project Management

Gestionar el proyecto usando datos estadísticos. Seleccionar subprocesos para control cuantitativo. Controlar calidad y rendimiento con datos numéricos.

NIVEL 5 — Optimizing · 2 PAs · Mejora continua e innovación

OID N5 Org. Innovation & Deployment

Seleccionar y desplegar innovaciones en procesos o tecnología. Medir impacto de mejoras implantadas. Difundir mejores prácticas en la organización.

CAR N5 Causal Analysis & Resolution ★ CRÍTICA

Análisis de causas raíz de defectos. Prevención de defectos recurrentes. Retroalimentación sistemática para mejorar procesos de forma continua.

Clave: "causas raíz", "prevención de defectos", "análisis post-mortem" → siempre CAR (N5).

EXAMEN: PA → Qué aspecto del ciclo de vida del SW trata cada PA

La profe dice explícitamente: "saber qué aspectos del ciclo de vida del software trata cada PA". Esta tabla es lo que debes memorizar.

Fase SW lifecycle	PA en V1.3	PA en V2.0	Qué hace
Requisitos	REQM (N2) + RD (N3)	RDM	REQM gestiona requisitos ya existentes · RD los crea (elicitación, casos de uso, derivación)
Planificación	PP (N2)	PLAN + EST	Estimar tamaño/esfuerzo · crear plan de proyecto · planificar recursos y calendario
Seguimiento y control	PMC (N2) + IPM (N3)	MC	Comparar avance real vs. plan · tomar acciones correctivas · detectar desviaciones
Gestión de riesgos	RSKM (N3)	RSK	Identificar · analizar probabilidad/impacto · planes de mitigación · monitorizar
Diseño e implementación	TS (N3)	TS	Diseño arquitectura · análisis Crear/Comprar/Reutilizar · diseño detallado · codificación
Integración y entrega	PI (N3)	PI	Ensamblar componentes · estrategia de integración · confirmar que cumplen requisitos · entregar
Verificación (pruebas SW)	VER (N3)	VV	Verificar que los requisitos están correctamente implementados · pruebas de integración y sistema
Validación (con cliente)	VAL (N3)	VV	Confirmar que la solución funciona en el entorno de destino · pruebas de aceptación
Revisiones entre pares	VER (N3)	PR	Revisiones de código o documentos por compañeros para detectar defectos temprano
Medición y análisis	MA (N2)	MPM / IMP	Definir métricas · recolectar y analizar datos · reportar resultados a dirección
Calidad proceso y producto	PPQA (N2)	PQA	Auditar que se siguen los procesos · revisar productos · reportar NCs con independencia
Gestión configuración	CM (N2)	CM	Control de versiones · gestionar baselines · controlar solicitudes de cambio
Proveedores	SAM (N2)	SAM	Gestionar contratos con proveedores · seleccionar subcontratistas · revisar entregables
Toma de decisiones	DAR (N3)	DAR	Decisiones técnicas formales con criterios objetivos · evaluar alternativas documentadas
Procesos org. — definición	OPD (N3)	PAD	Crear y mantener el proceso estándar de la organización · biblioteca de activos de proceso
Procesos org. — mejora	OPF (N3)	PCM	Evaluar procesos (SCAMPI) · planificar y coordinar mejoras · aprender de evaluaciones
Formación	OT (N3)	OT	Identificar necesidades de formación · crear plan · impartir cursos · evaluar efectividad
Control cuantitativo org.	OPP (N4)	MPM	Baselines estadísticas del rendimiento de procesos · modelos cuantitativos organizacionales
Gestión cuantitativa proy.	QPM (N4)	MPM	Gestionar el proyecto con datos estadísticos · control cuantitativo de subprocesos
Análisis causal / mejora	CAR (N5)	CAR	Análisis causas raíz de defectos · prevención de defectos recurrentes · retroalimentación

Respuestas clave para examen (2019 pidió exactamente esto):

• Pruebas de integración → PI (N3) — Product Integration
• Pruebas de aceptación → VAL (N3) / VV (V2.0) — Validation
• Arquitectura software → TS (N3) — Technical Solution
• Trazabilidad de requisitos → REQM (N2) / RDM (V2.0)

Patrones típicos de pregunta de examen:

• "La organización realiza revisiones entre pares del código" → VER (N3)
• "Se controla el número de defectos encontrados por fase" → MA (N2)
• "Se gestiona el contrato con la empresa que desarrolla un módulo externo" → SAM (N2)
• "Se detecta una desviación respecto al plan y se toman acciones" → PMC (N2)
• "Se define la arquitectura y se evalúa si comprar o desarrollar" → TS (N3)
• "Se identifican los riesgos y se crean planes de mitigación" → RSKM (N3)
• "La organización define su proceso estándar de desarrollo" → OPD (N3)
• "Se analizan las causas raíz de los defectos para evitar que se repitan" → CAR (N5)
• "Se evalúa al proveedor con criterios formales antes de contratarlo" → DAR (N3)
• "El equipo recibe formación en la nueva metodología ágil" → OT (N3)
• "Se integran los módulos desarrollados por distintos equipos" → PI (N3)
• "Se mide la capacidad estadística de los procesos de la organización" → OPP (N4)
• "Se gestionan las versiones y cambios de los documentos del proyecto" → CM (N2)

6. Procedimientos prácticos en la empresa

Procesos de desarrollo y gestión de errores en el ciclo de vida

Clasificación de proyectos

El jefe de proyecto clasifica el proyecto al inicio según su complejidad. Esta clasificación determina qué actividades se ejecutan:

Pequeño

Se prescinde del diseño. El desarrollo incluye el propio diseño (existe ERS pero no documentación de diseño separada).

Mediano

Incluye diseño de alto nivel sobre plantilla de empresa. Revisión entre diseñadores y director técnico.

Grande

Diseño de alto nivel + diseño de bajo nivel. Mayor documentación y control.

Fases del ciclo de vida — Entradas, Salidas y Roles

1. Diseño (DAN / DBN) Entrada: ERS + Plan de proyecto

• Pequeños: no existe fase de diseño separada.
• Medianos: DAN (Diseño Alto Nivel) por Ingeniero de Software. Revisión opcional por Director Técnico. Salida: Doc.DAN + Plan de pruebas de sistema.
• Grandes: DAN + DBN (Diseño Bajo Nivel). Salida adicional: Doc.DBN + Plan de pruebas de integración.

2. Programación Entrada: DAN/DBN o ERS según tamaño

• Rol: Ingeniero de Software usa estándares de codificación de la empresa.
• Salida: Código fuente estandarizado y documentado + Plan de pruebas unitarias.
• Revisión opcional por Jefe de Proyecto.

3. Pruebas unitarias Entrada: código fuente + plan pruebas unitarias

• Roles: Ingeniero de Software + Process Owner. Herramientas: JUnit, SonarQube.
• Errores → Registro de Errores (NO al SIE).
• Salida: Informes de pruebas unitarias + Código fuente verificado + Informes de cobertura de código.

4. Pruebas de integración Entrada: componentes validados unitariamente + plan

• Roles: Desarrollador Backend + Arquitecto Software. Herramientas: REST Assured. Entorno de pruebas (solo lectura).
• Errores → Registro de Errores (NO al SIE).
• Salida: Informes de pruebas de integración + Sistemas integrados y validados.

5. Pruebas de sistema Entrada: software integrado + plan pruebas sistema

• Roles: Analista de Pruebas de Sistema + Jefe de Pruebas. Framework E2E. Entorno solo lectura.
• Errores → Registro de Errores y SIE.
• Salida: Informe final ejecución + Registro formal de defectos (SIE) + Línea base de producto + Registro de configuración.

6. Pruebas de aceptación Entrada: sistema certificado en pruebas sistema + plan

• Roles: Ingeniero de Software + Cliente. Entorno pre-producción. Herramienta de feedback y retrospectiva.
• Errores → SIE.
• Salida: Informe final + Producto software validado + Registro de errores (SIE) + Firma del acta de aceptación formal y transferencia a operaciones.

SIE — Sistema de Información de Errores

Entrada: errores de pruebas de sistema y aceptación solamente. No se registran errores de pruebas unitarias ni integración.

Acceso: cliente, desarrollador/tester, responsable de calidad.

Gestión: Jefe de Proyecto supervisa. Empleado redacta. JP asigna y supervisa la corrección.

Salida: Informe de estado, inspección y ensayo + Tabla de métricas (nº errores sistema/aceptación).

Registro de errores vs SIE

Registro de errores: Unitarias + Integración + Sistema + Aceptación. Informal, por fases.

SIE: Solo Sistema y Aceptación. Formal, con seguimiento oficial, accesible por el cliente.

Métricas de la empresa (Práctica)

Métrica	Fórmula	Unidad	Encargado
% desviación en tiempo	`((TR − TE) / TE) × 100`	%	Jefe de Proyecto
% desviación en coste	`((CR − CE) / CE) × 100`	%	Jefe de Proyecto
Nº errores en pruebas de sistema	`Σ errores`	Entero	Jefe de Proyecto
Nº errores en pruebas de aceptación	`Σ errores`	Entero	Jefe de Proyecto
Nº errores notificados por cliente	`Σ errores post-entrega`	Entero	Director Técnico + RC (no recomendado)

Otros procesos organizacionales

Formación del personal

• Solicitud de trabajador → administración RRHH.
• Si se deniega: se da motivo, sin registro.
• Si se acepta: se realiza y se registra. Trabajador comenta eficacia.
• Si no fue eficaz: se notifica a RRHH.

Compras y proveedores

• Base de datos de proveedores aceptados (con ISO 9000).
• Jefe de proyecto aprueba compra según hoja de requisitos.
• Responsable de compras solicita presupuesto, contrata, recibe.
• Si producto no es válido: se rechaza y se revisa proveedor en BD.

Atención al cliente

• Cliente contacta con hoja de reclamaciones o necesidades de producto.
• Si es reclamación: se asigna número + plan de actuación.
• Si es necesidad de producto: jefe de proyecto decide si es viable.
• Si se acepta: se actualiza software y se documenta la actualización.
• Si se rechaza: se justifica el rechazo.

Control de documentación del SGC

• Repositorio con la última versión del SGC, siempre actualizado.
• Todo el personal tiene acceso de lectura.
• Histórico de versiones anteriores en versión offline.
• Sugerencias de cambio → van al RC, quien decide si se aplican.
• Si hay modificación del SGC: todas las copias tangibles deben renovarse.

Acciones correctivas (NC real)

El auditor detecta y marca una no conformidad.
El RC revisa la hoja de acciones correctivas.
El personal asignado aplica las acciones.
Si se resuelve la NC → se cierra.
Si no se resuelve → se vuelve a revisar y se aplican nuevas acciones.

Acciones preventivas (NC potencial)

Un empleado o usuario sugiere una posible mejora o riesgo.
El RC estudia la viabilidad de la propuesta.
Si es viable → se aplica la mejora.
Si no es viable → se descarta justificando el porqué.

Nota: En ISO 9001:2015 desaparecen y se sustituyen por gestión de riesgos.

Verificaciones de fase (VF)

Definidas en el Plan de Proyecto. El RC designa el Auditor de fase (personal capacitado ajeno al proyecto).

VF-01 — Tras análisis/requisitos
VF-02 — Tras diseño
VF-03 — Tras pruebas

4 fases: Planificación → Ejecución (revisa PP, anota NCs, entrevista equipo) → Evaluación → Cierre

NCs Graves: bloquean el proyecto hasta corrección. NCs No graves: Plan de Acciones Correctivas (PAC) con responsable + fecha límite + modo de corrección. RC firma el cierre.

Auditorías generales

Se acuerdan con al menos 15 días de antelación.

RC + responsable del área auditada planifican la auditoría general.
RC escoge el Auditor General (externo al área).
4 fases: Planificación → Ejecución → Evaluación → Cierre
NCs Graves / No graves → PAC con responsable + fecha + modo corrección.
RC supervisa el desarrollo de acciones correctivas y firma el cierre.

Gestión del ciclo de vida del proyecto

Planificación

Director general asigna recursos y jefe de proyecto.
Jefe de proyecto recibe contrato + requisitos.
Estima coste, esfuerzo y tiempo; clasifica el proyecto (pequeño/mediano/grande).
Rellena plantilla: línea base, tareas, recursos.
RC revisa y director general aprueba.

Seguimiento

Jefe de proyecto elige tipo de seguimiento y fecha de inicio.
Se comparan resultados reales con la línea base.
Si hay desviaciones: se corrigen y se notifica al personal afectado.
Reuniones de seguimiento → informe aprobado por director técnico.

Cierre

Una vez completadas todas las actividades.
Reunión de clausura: jefe de proyecto, RC, director técnico, equipo.
Se documentan resultados, métricas finales y lecciones aprendidas.
RC revisa y aprueba el informe de cierre.
Salida: informe de cierre + lecciones aprendidas.

Gestión de la Configuración del Software (GCS)

ECS (Elementos de Configuración)

ECS empleados: compiladores, entornos de desarrollo, herramientas CASE.
ECS generados — Documentación: ERS, manual de usuario, otros docs técnicos.
ECS generados — Software: ficheros código fuente + scripts para compilar/construir.
RC los aprueba y almacena en el GCS. Se actualiza el control de versiones.

Líneas base

LB de requisitos: ERS aprobado → ECS integrada con ERS.
LB de producto: Pruebas de sistema superadas → ECS: ERS + doc. usuario + producto software → genera Hoja de Registro de Configuración.
Cualquier cambio tras establecer una LB → proceso formal de GCC.

Seguimiento detallado

JP analiza desviaciones contra Plan de Proyecto.
Si desvío > 20% → Re-planificación.
Si evento grave/imprevisto → Informe de Excepción al Director Técnico.
Solo proyectos grandes: actualización monitorización de riesgos.
Informe de seguimiento: RC revisa → Director Técnico aprueba.

GCC — Proceso de Gestión de Control de Cambios (4 fases)

1. Captura solicitud

Cliente → Hoja de Solicitud de Cambios (HSC) → JP registra en directorio
Errores aceptación → SIE
Mantenimiento → Atención al cliente → Hoja de Modificación (HM)

2. Evaluación

JP (proyecto activo) o Director Técnico (mantenimiento) analiza impacto
Aceptación → plan de cambios
Rechazo → comunicación razonada al cliente

3. Ejecución

Desarrolladores realizan modificaciones en entorno local
Se pasan PU + PI sobre ECS afectados
Se genera nueva versión del ECS

4. Cierre/Entrega

JP o DT cumplimenta Hoja de Registro de Cambios (HRC)
Producto consolidado instalado y entregado al cliente
Se actualizan cabeceras, registros de cambios para mantener trazabilidad

7. SCAMPI — Evaluación de nivel CMMI

Tipos de evaluación, evidencias y proceso

Tipo	¿Genera nivel CMMI oficial?	Evidencias que usa	Para qué se usa
A	Sí — único que lo hace	Directas + Indirectas + Afirmaciones	Evaluación oficial. Requiere Lead Appraiser autorizado por el SEI. Alta preparación y coste.
B	No	Directas + Afirmaciones	Evaluación interna o de preparación. Identifica gaps antes de un SCAMPI A.
C	No	Solo Afirmaciones	Gap analysis rápido. Encuestas y cuestionarios. El más ligero y económico.

🎯 EXAMEN: Los 3 tipos de SCAMPI (A/B/C)

Pregunta típica: "¿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
⏳ Válido 3 años
💰 Más caro
📅 Al FINAL del programa

🔄 SCAMPI B — Sustainment

❌ No genera diploma
🔄 Mantener madurez
⏳ Extiende A 2 años
📅 DURANTE el programa
Máximo 3 B antes nuevo A
Menos riguroso que A

📸 SCAMPI C — Evaluation

❌ No genera diploma
🔍 Foto rápida estado
📅 Al INICIO del programa
⚡ Menos riguroso
💰 Más barato
🎯 Para planificar mejora

Quién evalúa (I) — El SEI y los Lead Appraiser

· El SEI NO emite el diploma — lo hace el Lead Appraiser (LA) y la empresa SEI partner en que trabaja
· El SEI acredita a los auditores: Lead Appraiser
· Tras el Benchmark appraisal, el LA envía documentación al SEI para asegurar la calidad de la auditoría
· Si todo va bien, resultados se publican en PARS (Published Appraisal Results) del SEI

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

· Sponsor: directivo que lidera el proyecto de mejora
· LA (Lead Appraiser): jefe del equipo de evaluación, responsable del resultado
· ATMs (Appraisal Team Members): personal interno y/o externo con experiencia
· OUC (Organizational Unit Coordinator): interfaz entre evaluadores y empresa — normalmente el RC — proporciona la información al evaluador
· Participantes seleccionados: jefes de proyecto o desarrolladores de los proyectos evaluados

Qué se evalúa

PAs y PGs seleccionados

La empresa elige qué Process Areas y Practice Groups evaluar. No tiene que evaluar todos.

Unidad organizacional

Qué parte de la organización se evalúa: departamento, conjunto de departamentos, empresa completa...

Muestra de proyectos

Proyectos representativos de la unidad organizacional. Al menos 1 proyecto objetivo.

Proyecto objetivo:

Proporciona evidencia para TODAS las PAs a evaluar. No importa si ha terminado o no.

Proyecto no objetivo:

Aporta evidencia de alguna PA concreta. Sirve de apoyo.

Cómo se evalúa — Las 3 fases

PRE ON-SITE (~6 meses antes)

1. Presentar (≥6 meses antes)
Compromiso gerencia. Sponsor + LA.

2. Planificar (4 meses antes)
ATMs, formación, unidad org., muestra proyectos, calendario, riesgos. Sponsor + LA + OUC.

3. Preparar (4m a 2 semanas antes)
Ejecutar formación, completar BDEO, Readiness Review, Plan de Evaluación en SAS. LA + OUC + ATMs.

ON-SITE (5-10 días)

· BDEO se copia a repositorio aislado — solo se añade info solicitada en evaluación
· Revisión documental, entrevistas, cuestionarios
· Reuniones: inicial, resultados preliminares, resultados finales
· Para cada práctica: artefacto directo + indirecto y/o afirmación
· "Lo que sucede en la evaluación, se queda en la evaluación"

PUBLICACIÓN (2 semanas después)

· Completar registro en SAS
· Anunciar resultados a la organización
· Anunciar en prensa y publicaciones del sector

PG satisfecho si:

Todas sus prácticas son FI o LI. Si la mayoría tienen debilidades → PG no satisfecho.

Tipos de evidencias objetivas (lo que analiza el auditor):

Artefacto: salida directa o indirecta de implementar una práctica (plan de proyecto, doc. estimación, horas imputadas...). Se recoge en PRE ON-SITE.

Afirmación: confirmación oral o escrita que corrobora la práctica (entrevistas, cuestionarios). Se obtiene ON-SITE. Pueden ser negativas.

Se busca: Artefacto AND Afirmación (positiva)

Proceso de evaluación SCAMPI A

1.Planificación: definir alcance, PAs a evaluar, equipo, cronograma y coste.
2.Preparación (PRE ON-SITE): recoger y organizar artefactos en BDEO.
3.Evaluación on-site: entrevistas, revisión de artefactos, valoración Bottom-Up.
4.Informe: rating por PA, nivel obtenido, hallazgos.

Evaluación Bottom-Up (FI/LI/PI/NI)

Se evalúa práctica a práctica. Cada práctica tiene un rating:

✅ FI (Fully Implemented) — Artefacto directo, sin debilidades

🟡 LI (Largely Implemented) — Artefacto directo + debilidades menores

🔴 PI (Partially Implemented) — Artefactos inadecuados

❌ NI (Not Implemented) — Sin artefactos

Clave: Un PA se satisface solo si TODAS sus prácticas son FI o LI. Una sola PI → PA falla.

8. Otros modelos de calidad del software

SwTQM · MMIS V2 · ITmark — modelos complementarios a CMMI e ISO 9000

SwTQM — Software Total Quality Management 1 slide en examen

Aplicación de los principios del TQM (Total Quality Management) al desarrollo de software. El TQM surgió en los años 60 como evolución del control estadístico: "todos los departamentos, no solo el de calidad, tienen responsabilidad en alcanzar la calidad". SwTQM traslada eso al contexto software.

Principios clave

• Orientación al cliente: los requisitos del cliente son el punto de partida de la calidad
• Responsabilidad total: todos los miembros del equipo son responsables de calidad, no solo el auditor
• Calidad desde el inicio: se incorpora en el proceso, no se detecta solo en pruebas
• Mejora continua (PDCA): Plan → Do → Check → Act de Deming
• Decisiones basadas en datos: métricas, no intuición

Las 4 P's del proceso software (Pressman)

• Producto: software como producto → métricas, estándares de código
• Proceso: buen proceso → buen producto → CMM/CMMI, SPICE, ISO 9000
• Personas: equipo competente → formación, roles claros
• Problema: entender bien el problema → análisis de requisitos riguroso

Diferencia clave TQM vs QC/QA clásico: TQM/SwTQM integra la calidad en la cultura de la organización. QC solo controla el producto final; QA audita el proceso. TQM va más allá: responsabilidad colectiva, mejora continua, enfoque sistémico.

MMIS V2 — Modelo de Madurez de la Ingeniería del Software 1 slide en examen

Modelo europeo de mejora del proceso software, también conocido como Bootstrap. Fue la respuesta europea al CMM americano, alineado con la norma ISO 9000.

Características

• Promovido en la Unión Europea como alternativa a CMM
• Alineado con ISO 9000 (a diferencia del CMM original)
• Evaluaciones de diagnóstico del proceso software
• V2 amplía cobertura y simplifica la evaluación

Contexto modelos europeos

• Bootstrap → SPICE (ISO/IEC 15504) → ISO 33000
• SPICE fue promovido por ISO y materializa el esfuerzo europeo
• ITmark (ver abajo) usa SPICE/15504 como base para proceso
• Estrategia habitual: ISO 9000 primero, luego CMMI

ITmark

Certificación para PYMES TIC europeas

ITmark es una certificación diseñada específicamente para PYMES del sector TIC europeas. Evalúa tres dimensiones simultáneamente en una única auditoría, lo que reduce costes respecto a certificarse en cada norma por separado.

Proceso software

Basado en ISO/IEC 15504 (SPICE). Evalúa la madurez de los procesos de desarrollo.

Seguridad de la información

Basado en ISO/IEC 27001. Evalúa controles de seguridad y gestión de riesgos.

Gestión del negocio

Incluye siempre encuestas de satisfacción de empleados y clientes.

Basic

Nivel de entrada. Sin requisito de nivel CMMI previo. Para empresas que inician su proceso de mejora.

Silver

Nivel intermedio. Procesos más maduros en las tres dimensiones. Mayor rigor en la evaluación.

Elite

Nivel máximo. Requiere haber alcanzado CMMI nivel 2 en proceso software.

Puntos que conviene no confundir

• ITmark no es un paso previo para CMMI ni viceversa. Son certificaciones independientes.
• Las encuestas de satisfacción son parte obligatoria de ITmark, no opcionales.
• Los niveles son Basic, Silver y Elite — no existen niveles "F", "L1" ni ningún otro nombre.
• ITmark Elite exige CMMI nivel 2, no nivel 3.

9. Implementar calidad en un proyecto software

Cómo aplicar ACL y CC a lo largo del ciclo de vida

¿Qué actividades de calidad se hacen en cada fase?

Inicio del proyecto

Elaborar el Plan de Calidad: qué se va a verificar, con qué criterios, quién es responsable, qué métricas se recogerán y cuáles son los criterios de aceptación por fase.

Por fase

Revisiones técnicas e inspecciones del producto intermedio al final de cada fase (con criterios de entrada y salida definidos).

Durante el proyecto

Auditorías de proceso periódicas (PPQA): verificar que el equipo sigue el proceso definido, no solo que el producto tenga buen aspecto.

No conformidades

Registrar toda no conformidad con responsable y fecha límite. Seguimiento hasta cierre. Sin seguimiento, la NC no sirve de nada.

Cierre

Recoger métricas de calidad del proyecto (densidad de defectos, cobertura de pruebas, esfuerzo ACL) y documentar lecciones aprendidas para mejora continua.

Pasos para realizar aseguramiento de calidad

1. Planificación de la calidad

Definir plan de calidad, criterios de aceptación, métricas a recoger y responsables.

2. Aseguramiento (auditar el proceso)

Auditorías de conformidad con el proceso: ¿se está siguiendo lo definido?

3. Control (inspeccionar el producto)

Revisiones técnicas, walkthroughs, pruebas. ¿El producto cumple los requisitos?

4. Registro de evidencias y NC

Documentar evidencias, no conformidades y acciones correctivas con seguimiento.

5. Medición

Recoger métricas definidas, analizar tendencias, comparar con los objetivos del plan.

6. Mejora continua

Usar los datos y lecciones aprendidas para mejorar el proceso en futuros proyectos.

Productos adquiridos externamente (ISO 9001, cláusula 8.4)

ISO 9001 requiere controlar los productos y servicios suministrados externamente que afectan al producto final. Esto incluye:

Software comercial

Librerías, componentes, frameworks de pago.

Software libre (freeware)

Aunque no hay pago, hay adquisición. Si afecta al producto final, entra en el SGC.

Productos cedidos por el cliente

Deben verificarse, registrarse y protegerse. Se añade registro de recepción y estado.

Parte Práctica — Respuestas tipo examen

Los 5 bloques que pueden salir en la práctica (6 puntos). Aprende a responder cada uno.

CONTEXTO DE TODAS LAS PRÁCTICAS

El enunciado siempre parte de una PYME con un ciclo de vida establecido: Análisis → Diseño → Implementación → Pruebas. Tu respuesta debe ser específica: qué actividades, quién las realiza, con qué herramientas y cuándo.

BLOQUE 1 — Aseguramiento de la Calidad (QA)

Pregunta tipo: "¿Cómo implementarías el aseguramiento de calidad? / ¿Qué pasos son necesarios para realizar el aseguramiento de calidad?"

QA = Prevención. Se aplica al proceso. Objetivo: garantizar que el proceso de desarrollo se sigue correctamente antes de que aparezcan defectos.

1. Plan de Calidad

Quién: Responsable de Calidad (RC)
Cuándo: Inicio del proyecto, antes de comenzar el desarrollo
Qué contiene: objetivos de calidad, métricas, procedimientos a seguir, roles, calendario de VF y auditorías

2. Verificaciones de Fase (VF)

Quién: Auditor independiente del proyecto (ajeno al equipo)
VF-01: al final de Análisis — revisa ERS, casos de uso, entregables de análisis
VF-02: al final de Diseño — revisa documentación de diseño y arquitectura
VF-03: al final de Pruebas — revisa resultados de pruebas, actas
Resultado: NC Graves (bloquean el avance) o NC No Graves (se resuelven en paralelo)

3. Auditorías Internas

Quién: Auditor interno (independiente del área auditada)
Cuándo: Convocatoria con mínimo 15 días de antelación
Qué se audita: cumplimiento de procedimientos, plan de calidad, registros
Resultado: informe de auditoría con NCs y oportunidades de mejora

4. Seguimiento del Proyecto

Quién: RC + Jefe de Proyecto
Periodicidad: cada 2 semanas (revisiones de progreso)
Si desvío > 20%: re-planificación obligatoria
Si evento grave: Informe de Excepción al Director Técnico

5. Acciones Correctivas y Preventivas

Cuando una VF o auditoría detecta NCs: se registran, se asigna responsable y plazo, se verifican en la siguiente revisión. Las preventivas se aplican antes de que ocurra el problema, basándose en datos de métricas.

RESUMEN PASOS QA (para preguntas tipo "qué pasos son necesarios"):

Elaborar Plan de Calidad (RC, al inicio)
Planificar VF y auditorías en el calendario del proyecto
Ejecutar VF al final de cada fase (auditor independiente)
Registrar NCs y hacer seguimiento hasta cierre
Realizar auditorías internas (15 días de antelación)
Hacer seguimiento periódico del proyecto — re-planificar si desvío >20%
Aplicar acciones correctivas y preventivas
Revisar métricas para mejora continua

BLOQUE 2 — Control de la Calidad (QC)

Pregunta tipo: "¿Cómo implementarías el control de calidad? / ¿Qué pasos son necesarios para realizar el control de calidad?"

QC = Detección. Se aplica al producto. Objetivo: encontrar defectos en el software mediante pruebas ordenadas por fases.

Fase prueba	Quién la ejecuta	Herramientas	Cuándo	Registro
Unitarias	Ingeniero SW + Process Owner	JUnit, SonarQube	Al terminar cada módulo (Implementación)	No usa SIE
Integración	Dev Backend + Arquitecto SW	REST Assured	Al integrar componentes	No usa SIE
Sistema	Analista + Jefe de Pruebas	Herramientas E2E	Antes de entregar al cliente	SIE (obligatorio)
Aceptación	Ingeniero SW + Cliente	—	Con el cliente presente	SIE + firma acta

SIE — Sistema de Información de Errores

Solo se usa en pruebas de sistema y aceptación. NO en unitarias ni integración. Registra: defecto encontrado, severidad, responsable de corrección, estado (abierto/cerrado), fecha cierre.

RESUMEN PASOS QC (para preguntas tipo "qué pasos son necesarios"):

Planificar las pruebas (tipos, casos de prueba, responsables, herramientas)
Diseñar casos de prueba para cada fase
Ejecutar pruebas unitarias (Ingeniero SW + Process Owner, JUnit/SonarQube)
Ejecutar pruebas de integración (Dev Backend + Arquitecto SW, REST Assured)
Ejecutar pruebas de sistema (Analista + JP, E2E) — registrar defectos en SIE
Ejecutar pruebas de aceptación con el cliente — registrar en SIE
Corregir defectos encontrados y re-ejecutar las pruebas afectadas
Firma del acta de aceptación por el cliente

BLOQUE 3 — Gestión de la Configuración del Software (GCS)

Pregunta tipo: "¿Cómo implementarías la gestión de la configuración en este proyecto? / Describe los ECS y las líneas base."

Elementos de Configuración del Software (ECS)

Todo elemento que se identifica, versiona y controla dentro del sistema de gestión de configuración.

ECS Empleados (existen antes del proyecto):

Compiladores y entornos de desarrollo (IDE)
Herramientas CASE
Frameworks y librerías externas

ECS Generados (se producen en el proyecto):

Documentación: ERS, manual de usuario, diseño
Software: código fuente, ejecutables

Líneas Base (Baselines)

Una línea base es una versión aprobada formalmente de un ECS. A partir de ahí cualquier cambio requiere pasar por GCC.

LB de Requisitos:

Se establece cuando la ERS es aprobada formalmente. A partir de aquí los requisitos solo cambian por GCC.

LB de Producto:

Se establece cuando las pruebas de sistema son superadas. El software ya está listo para aceptación.

RESUMEN PASOS GCS:

Identificar todos los ECS del proyecto (empleados y generados)
Asignar identificador y versión a cada ECS
Establecer LB de Requisitos al aprobar la ERS
Controlar versiones de código fuente y documentación (herramienta de control de versiones)
Establecer LB de Producto al superar pruebas de sistema
Cualquier cambio sobre una LB → proceso GCC

BLOQUE 4 — Gestión de Cambios y Control (GCC)

Pregunta tipo: "¿Cómo gestionarías los cambios en este proyecto? / Describe el proceso de gestión de cambios."

GCC controla cualquier modificación sobre una línea base. Ningún cambio se aplica directamente — todo pasa por las 4 fases.

1

Captura de Solicitud

· Cualquiera puede solicitar un cambio
· Se rellena formulario SR (Solicitud de cambio)
· Se asigna identificador único

2

Evaluación

· Análisis de impacto (coste, plazo, alcance)
· CCB (Change Control Board) decide: aprobar / rechazar / aplazar
· Se documenta la decisión

3

Ejecución

· Se implementa el cambio aprobado
· Se actualiza la documentación afectada
· Se ejecutan pruebas de regresión

4

Cierre / Entrega

· Verificación del cambio implementado
· Actualización de la línea base
· Registro de cierre de la SR

Tipos de solicitud de cambio

RFC (Request for Change): Cambio en requisitos o funcionalidad ya baseline.

Problem Report (PR): Reporte de defecto o problema encontrado.

Improvement Request: Mejora propuesta, no es un defecto.

BLOQUE 5 — ISO apt. 8: Medición, Análisis y Mejora + Métricas

Pregunta tipo: "Según el apt. 8 de ISO 9000: i) qué se hace con medición, análisis y mejora ii) campos de una métrica iii) métricas para una PYME"

8.1 — Generalidades

Planificar e implementar los procesos de seguimiento, medición, análisis y mejora necesarios para demostrar la conformidad del producto, del SGC, y mejorarlo continuamente.

8.2 — Seguimiento y Medición

8.2.1 Satisfacción del cliente — medir percepción del cliente (encuestas, reclamaciones...)
8.2.2 Auditorías internas — verificar conformidad del SGC
8.2.3 Seguimiento y medición de los procesos
8.2.4 Seguimiento y medición del producto — pruebas

8.3 — Control del Producto No Conforme

Identificar, documentar y controlar el producto que no cumple los requisitos. Opciones: corregir, aceptar con autorización, o rechazar.

8.4 — Análisis de Datos

Recopilar y analizar datos para evaluar: satisfacción del cliente, conformidad con requisitos del producto, características de los procesos, proveedores.

8.5 — Mejora

8.5.1 Mejora continua: usar política, objetivos, auditorías, análisis de datos y revisión por dirección.

8.5.2 Acciones correctivas: eliminar causa de NC ya ocurrida. Requiere: identificar causa, implementar acción, verificar eficacia.

8.5.3 Acciones preventivas: eliminar causa de NC potencial (que aún no ha ocurrido).

Plantilla completa de una métrica — 8 campos

1. Nombre

Identificador único de la métrica

2. Objetivo

Para qué sirve, qué mide y por qué

3. Fórmula

Cálculo matemático de la métrica

4. Unidad

Horas, %, días, defectos...

5. Origen

De dónde vienen los datos (registros, herramientas...)

6. Datos de entrada

Qué datos concretos se necesitan para calcularla

7. Periodo

Con qué frecuencia se mide (semanal, por sprint, por fase...)

8. Criterios de análisis

Valores umbral — qué es aceptable, qué dispara alarma

Ejemplo: Métrica — Tiempo medio invertido en revisiones de progreso

Nombre	Tiempo medio en revisiones de progreso
Objetivo	Controlar el tiempo dedicado a revisiones de progreso para detectar desviaciones respecto a lo planificado
Fórmula	Σ(tiempo real en revisiones) / nº de revisiones realizadas
Unidad	Horas
Origen	Actas de reunión y registros de asistencia
Datos de entrada	Hora inicio y hora fin de cada revisión de progreso
Periodo	Por cada revisión de progreso (quincenal)
Criterios de análisis	< 2h: aceptable · 2-3h: revisar causas · > 3h: alarma, tomar acción correctiva

Métricas recomendadas para una PYME que implanta ISO 9000

Métrica	Qué mide	Tipo
Cumplimiento de hitos	% de hitos entregados en fecha respecto a los planificados	Proyecto
Densidad de defectos	Nº defectos encontrados / tamaño del módulo (KLOC o puntos función)	Producto
Tiempo de resolución de NCs	Días entre detección de NC y cierre de la acción correctiva	Proceso
Satisfacción del cliente	Puntuación media obtenida en encuestas o valoraciones del cliente	Cliente
Tiempo medio en revisiones de progreso	Horas medias invertidas por revisión de progreso del proyecto	Proyecto

DIFERENCIA CLAVE QA vs QC — siempre sale

QA — Aseguramiento
Prevención · aplica al proceso
Plan de calidad, VF, auditorías, seguimiento
Lo hace el RC y auditores

QC — Control
Detección · aplica al producto
Pruebas: unitarias → integración → sistema → aceptación
Lo hacen los ingenieros y el cliente

Aseguramiento de la Calidad

🚨 CRASH COURSE — LO QUE MÁS SALE EN EXAMEN

Vocabulario y fundamentos

Requisitos del SGC

Evaluación de procesos SW

¿Quién certifica qué?

10 pasos para llegar a la certificación ISO 9001

Registro de calidad

No conformidad (NC)

📉 DoD Americano, 1979 ($6.8 millones en proyectos software):

📈 Chaos Report (mejora histórica 1994-2006):

Auditoría interna

Auditoría de cliente

Auditoría de certificación

Perfil del auditor

Evidencias objetivas en una auditoría

PSM — Practical Software Measurement

Categorías del catálogo de métricas

Métricas de progreso de proyecto

GQM — Goal Question Metric Medición hasta cuadro de mando

Cuadro de Mando de Calidad (Balanced Scorecard aplicado al SW)

¿Qué es CMMI?

Constelaciones de CMMI (versión 1.3)

CMMI Staged

CMMI Continuous

5 Niveles CMMI Staged

Metas vs. Prácticas en CMMI

PA clave: PPQA (Nivel 2)

CMMI 3.0 — Nueva arquitectura

PAs clave de CMMI 3.0 — Resumen de niveles de capacidad

Clasificación de proyectos

Fases del ciclo de vida — Entradas, Salidas y Roles

SIE — Sistema de Información de Errores

Registro de errores vs SIE

Métricas de la empresa (Práctica)

Otros procesos organizacionales

Formación del personal

Compras y proveedores

Atención al cliente

Control de documentación del SGC

Acciones correctivas (NC real)

Acciones preventivas (NC potencial)

Verificaciones de fase (VF)

Auditorías generales

Gestión del ciclo de vida del proyecto

Planificación

Seguimiento

Cierre

Gestión de la Configuración del Software (GCS)

ECS (Elementos de Configuración)

Líneas base

Seguimiento detallado

Proceso de evaluación SCAMPI A

Evaluación Bottom-Up (FI/LI/PI/NI)

SwTQM — Software Total Quality Management 1 slide en examen

MMIS V2 — Modelo de Madurez de la Ingeniería del Software 1 slide en examen

Puntos que conviene no confundir

¿Qué actividades de calidad se hacen en cada fase?

Pasos para realizar aseguramiento de calidad

Productos adquiridos externamente (ISO 9001, cláusula 8.4)