El documento describe el Modelo CMMi, un conjunto de buenas prácticas para mejorar los procesos de desarrollo de software y sistemas. Explica que el CMMi ofrece una guía para la mejora continua mediante dos representaciones: por etapas, con niveles de madurez, y continua, con niveles de capacidad de las áreas de proceso. También describe las constelaciones, estructura y áreas de proceso del modelo.

1. El Modelo CMMi

2. Contenido
• ¿Qué es el modelo CMMi?
• Historia del modelo CMMi
• Constelaciones
• Estructura
• Niveles (Stage, Continua)
• Areas del Proceso del Modelo: CMMI – DEV
– Project Planing
– Project Monitoring and Control
– Requerimients Management
• Otras Areas del Proceso

3. ¿Qué es el modelo CMMi?
• Capability Maturity Model Integration
• Es un modelo de buenas prácticas.
• ¿Qué significa el término “modelo”?
• Algunos lo definen como un “conjunto de
modelos” de mejora de procesos.

4. ¿Qué es el modelo CMMi?
• Buenas prácticas para mejorar el desempeño
de las organizaciones de software.

5. ¿Para qué se utiliza el modelo CMMi?
• Como una guía para la mejora de procesos en
proyectos y organizaciones.
• Para ayudar a establecer objetivos de mejora y
prioridades.
• Como un modelo de referencia de buenas
prácticas.
• Para ayudar a asegurar procesos estables, capaces
y maduros.
• Permite diagnosticar el estado actual de las
prácticas en las organizaciones.

6. CMMi y los Objetivos del Negocio
• Las prácticas de CMMi deben interpretarse en
el contexto de la organización.
• La implementación de las prácticas debe estar
alineada con los objetivos del negocio.
• Adicionalmente, es necesario definir objetivos
de mejora.

7. Beneficios del modelo CMMi
• Mejora en predictibilidad del cronograma y presupuesto

8. Beneficios del modelo CMMi
• Mejora en productividad y calidad (para software)

9. Beneficios del modelo CMMi
Tomado de “Performance Results of CMMi® Based Process
Improvement – CMU/SEI-2006-TR-004
Categoría de desempeño Mediana
de mejora
Número de
datos
Menor
mejora
Mejora más
alta
Costo 34% 29 3% 87%
Cronograma 50% 22 2% 95%
Productividad 61% 20 11% 329%
Calidad 48% 34 2% 132%
Satisfacción del cliente 14% 7 -4% 55%
Retorno sobre inversión (ROI) 4.0: 1 22 1.7: 1 27.7: 1

10. Adopción del modelo CMMi
Tomado de “CMMI for DEV SCAMPI Class A Appraisal Results
2010 Mid-Year Update”

11. Adopción del modelo CMMi
Tomado de “CMMI for DEV SCAMPI Class A Appraisal Results
2010 Mid-Year Update”

12. Adopción del modelo CMMi
Tomado de “CMMI for DEV SCAMPI Class A Appraisal Results 2010 Mid-Year Update”

13. Historia de CMMi
• 1930 – Walter Shewhart inicia trabajos
sobre mejora de procesos con sus
principios de control de calidad
estadístico.
• Deming (1986), Crosby (1979), Juran
(1988) refinan estos principios.
• En 1984, el Departamento de Defensa de los
Estados Unidos establece el Software
Engineering Institute (SEI) en la universidad
de Carnegie Mellon.
• Watts Humphrey y otros extienden estos
principios y lo aplican en IBM y el SEI

14. Historia de CMMi
• 1989 – Watts Humphrey publica el libro Managing
the Software Process.
• El SEI toma los principios de Humphrey y publica
los modelos CMM.
• En el año 2000 surge el CMMi, como un
framework que integra las disciplinas de
los modelos CMM anteriores.

15. Constelaciones CMMi
• Inicialmente, sólo se tenía CMMi para desarrollo de software /
sistemas.
• El SEI planificó expandir el modelo para atender nuevas áreas
de interés. Se crearon 3 constelaciones:
– CMMi para Adquisiciones
– CMMi para Servicios
– y, al modelo original se le denominó CMMi para Desarrollo.

16. Constelaciones CMMi
• CMMi para Desarrollo (CMMi-DEV)
– Modelo de referencia que cubre las actividades de
desarrollo de productos de software y sistemas.
– Utilizado por organizaciones de diversas industrias,
como
• Aeroespacial
• Banca
• Hardware de computadoras
• Software
• Defensa
• Fabricación de automóviles
• Telecomunicaciones, etc.

17. Constelaciones CMMi
• CMMi para Adquisiciones (CMMi-ACQ)
– Describe las prácticas a utilizar cuando se
adquieren productos y servicios.
– Considera los siguientes aspectos del proceso de
adquisición:
• Externos: La adquisición en sí del producto, servicio,
sistemas y capacidades necesarias.
• Internos: Para asegurar que el proceso de adquisición es
conducido con disciplina.

18. Constelaciones CMMi
• CMMi para Servicios (CMMi-SVC)
– Cubre las actividades requeridas para establecer,
entregar y gestionar servicios.
– Un servicio es un producto intangible, no
almacenable. Ejemplo: Entrenamiento, logística,
mantenimiento, investigación, consultoría, etc.
– Contiene prácticas para la gestión del trabajo,
gestión de procesos, establecimiento de servicio,
su entrega y soporte, etc.

19. SubprácticasSubprácticasSubprácticas
Prácticas
genéricas
Prácticas
genéricas
Prácticas
específicas
Prácticas
específicas
Metas genéricasMetas genéricas
Metas
específicas
Metas
específicas
Componentes del CMMi
Área de
Proceso
Descripción
del
propósito
Notas
introductori
as
Áreas de
proceso
relacionadas
Metas
específicas Metas genéricas
Prácticas
específicas
Prácticas
genéricas
Ejemplo de
entregables
Subprácticas Subprácticas
Explicación
de prácticas
genéricas
Leyenda: Requerido Esperado Informativo

20. Área de Proceso (Process Areas)
• Conjunto de prácticas o actividades las que se
ejecutan de manera colectiva para alcanzar un
objetivo.
• Existen 22 áreas de proceso en CMMI-DEV.
• Ejemplo:
– Project Planning (PP)
– Project Monitoring and Control (PMC)
– Requirements Management (REQM)
– Technical Solution (TS)
– Validation (VAL), etc.
Área de
Proceso

21. Categorías de las Áreas de Proceso
Project Management
Integrated Project Management (IPM)
Project Monitoring and Control (PMC)
Project Planning (PP)
Quantitative Project Management (QPM)
Requirements Management (REQM)
Risk Management (RSKM)
Supplier Agreement Management (SAM)
Process Management
Organizational Performance Management (OPM)
Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
Organizational Process Performance (OPP)
Organizational Training (OT)
Engineering
Product Integration (PI)
Requirements Development (RD)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
Support
Causal Analysis and Resolution (CAR)
Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)

22. Niveles
• Proveen los medios que permiten medir la mejora de
procesos.
• Son utilizados por el CMMi para describir un camino
evolutivo hacia la mejora de los procesos.
• El objetivo es establecer un orden hacia el camino de
la mejora.
• Las 2 modalidades de caminos de mejora son
denominadas “Representaciones del Modelo”.

23. Ambos mecanismos se orientan a
estrategias de mejora diferentes

24. Representación por Etapas (Staged)
• Permite que la organización mejore en un conjunto de áreas
de procesos relacionadas, atendiendo incrementalmente un
conjunto de procesos sucesivos.
• Utiliza niveles de madurez como mecanismo para medir el
progreso incremental de la mejora.
• El nivel de madurez es un mecanismo de calificación que
permitirá realizar comparaciones entre organizaciones.

25. Representación por Etapas (Staged)
AP 1
AP 2
AP 3
AP 4
AP 5
…
AP a
AP b
AP c
…AP d
AP Ω
AP β
…
AP Ω
AP β
Cada etapa contiene
un grupo
predefinidos
de Áreas de Proceso
(AP)
Cada etapa, o
nivel de madurez,
se construye sobre
la base del que se
encuentra debajo

26. Representación por Etapas (Staged)
Riesgo
Retrabajo
Calidad
Productivi-
dad
Procesos
impredecibles,
pobremente
controlados y reactivos
Gestión básica de proyectos.
Procesos frecuentemente
reactivos
Procesos estandarizados y
proactivos
Procesos medidos y
controlados
(cuantitativamente)
Mejora continua de
procesos
¡¡¡El trabajo se realiza de alguna manera!!!

27. Nivel de Madurez 1 - Inicial
• Proceso usualmente ad-hoc y caótico.
• El éxito en estas organizaciones depende de las competencias
y “actos heroicos” de las personas.
• El software que alcanzan a producir usualmente sale del
presupuesto y cronograma.
“Las cosas se hacen de alguna
manera”

28. Nivel de Madurez 2 - Gestionado
• Los procesos se planifican y ejecutan de acuerdo a una
política. La política expresa la expectativa que tiene la
organización sobre cómo se debe ejecutar el proceso
• Se emplea personal capacitado y los recursos adecuados.
• Se monitorea, controla y revisa.
• Se evalúa “adherencia” (cumplimiento de los procesos)
Se tiene visibilidad de lo que sucede entre hitos determinados del proyecto.
Lo que ocurre dentro de las cajas no es estándar. Cada proyecto lo define, sin
embargo cumple las expectativas de la política

29. Nivel de Madurez 4 – Gestionado
Cuantitativamente
• Se establecen objetivos cuantitativos sobre la
calidad y desempeño de los procesos. En base
a estos se gestionan los proyectos.
• La calidad y desempeño se comprenden en
términos estadísticos.

30. Nivel de Madurez 5 – En Optimización
• Se enfoca en la mejora contínua de la
performance de los procesos.
• La mejora se basa en el entendimiento
cuantitativo de los objetivos del negocio y de
las necesidades de desempeño

31. Representación Contínua
• Permite que la organización se enfoque en mejorar
ciertas áreas de proceso identificadas.
• El mecanismo para medir el progreso de la mejora
son los niveles de capacidad (capability)

32. Representación Contínua
• Nivel de Capacidad 0 – Incompleto
– Es un proceso que no se realiza o se realiza
incompleto.
– Al menos una de las metas específicas del área de
proceso evaluada no se satisfacen
– No existe Meta Genérica para esta nivel, pues no
tiene sentido institucionalizar un proceso
ejecutado parcialmente.

33. Representación Contínua
• Nivel de Capacidad 1 – Realizado
– Es un proceso que cumple el trabajo necesario
para producir sus entregables.
– Las Metas Específicas del área de proceso se
satisfacen.
– Alcanzar el Nivel de Capacidad 1 constituye
mejoras importantes. Sin embargo, las mejoras se
pueden perder en el tiempo al no encontrarse
institucionalizado.

34. Representación Contínua
• Nivel de Capacidad 2 – Gestionado
– El área de proceso cumple con la Meta Genérica
GG 2 (Institucionalizar un proceso gestionado)
– Es un proceso que se planifica y ejecuta de
acuerdo con una política.
– Utiliza personal capacitado, con los recursos
adecuados.
– Es un proceso controlado.
– La disciplina que refleja este nivel de capacidad
ayuda a asegurar el cumplimiento de las prácticas
en momentos de crisis.

35. Representación Contínua
• Nivel de Capacidad 3 – Definido
– El área de proceso cumple con la Meta Genérica
GG 3 (Institucionalizar un proceso definido)
– Es un proceso que se ajusta a partir de los
procesos estándar de la organización.
– Se contribuye a la mejora del proceso brindando
mejoras y lecciones aprendidas.

36. Resumen comparativo
• La organización selecciona las
áreas de proceso y los niveles de
capacidad según sus propios
objetivos de mejora.
• La mejora se mide utilizando
niveles de Capacidad.
– Miden la madurez de procesos
particulares a través de la
organización.
– Van de 0 a 3
• Conveniente cuando se tiene
poco presupuesto para la mejora,
o se requieren “Quick wins”
• La organización selecciona las áreas
de proceso basada en el nivel de
madurez seleccionado.
• La mejora se mide utilizando niveles
de Madurez
– Miden la madurez de un conjunto de
procesos a través de la organización.
– Van de 1 a 5
Representación Contínua
(Continuous)
Representación por Etapas
(Staged)

37. Areas del Proceso del Modelo: CMMI - DEV
• Lineamientos adicionales para la correcta
interpretación del modelo.
• Areas de Proceso:
– Project Planning (PP)
– Project Monitoring and Control (PMC)
– Requirements Management (REQM)

38. Project Planning - PP
• PP nos dice que las siguientes son las
buenas prácticas que permiten establecer
estimados:

39. Project Planning - PP
• PP nos dice que las siguientes son las
buenas prácticas que permiten establecer
estimados:

40. PP SP 1.1 Estimar el alcance del
proyecto
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
- No sabemos todo lo
que debemos hacer en
el proyecto (no todo es
programar y probar).
- Inclusive estimamos
esfuerzo sin saberlo.
- Ejemplo: “Tenemos
que migrar la data del
sistema antiguo!!! No
nos alcanza el tiempo
para eso.
Establecer una estructura
de descomposición del
trabajo de alto nivel, para
estimar el alcance del
proyecto.
Debemos saber qué hay
que hacer, antes de decir
cuánto esfuerzo nos va a
tomar.
-Preparar un WBS (en alto
nivel)
-Cuadro en Excel con la lista de
las actividades en alto nivel del
proyecto.
- Si es una lista estándar
(plantilla) asegurar que se
pueden adicionar actividades
particulares del proyecto.

41. PP SP 1.2 Establecer las estimaciones de los
atributos del producto de trabajo y las tareas
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Los estimados son de
baja calidad.
Se estima en base a
atributos cualitativos,
que sólo el que estima
comprende.
Sólo aplicamos juicio
de experto.
Establecer y mantener
estimados de atributos de
entregables y tareas.
“Tamaño” es el atributo
más utilizado.
Típicamente, se asignan
niveles de complejidad.
Se debe establecer qué
atributos son los que los
proyectos deben medir.
Implementar una técnica como
Puntos de Función, Puntos de
Casos de Uso, etc., satisface
esta práctica.
Otras como Planning Poker
también cumplen.
Se puede definir una técnica
ad-hoc, siempre y cuando
queden establecidos los
atributos a medir.

42. PP SP 1.3 Definir el Ciclo de Vida del Proyecto
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
- Tenemos que estimar
esfuerzo, y no tenemos
idea clara de los pasos
o etapas por la que
debe seguir el proyecto
(¿Qué debo hacer
antes de desarrollar?
¿cómo puedo
fraccionar un
proyecto?...)
- ¿Qué etapas de
ingeniería tiene el
proyecto? (no todo es
programar).
Definir (o seleccionar) el
ciclo de vida que seguirá el
proyecto.
El paso entre fases
constituyen puntos para
evaluar y tomar decisiones.
Es necesario comprender el
ciclo de vida para
determinar el alcance de la
planificación.
Varias alternativas:
-Tener una descripción que
indique en qué fases se divide
un proyecto (ej. Análisis,
diseño; sprints; etc.), que
indique qué sucede en cada
una de ellas. Si se tiene más de
uno, el proyecto la selecciona.
- Definir un ciclo de vida
particular y utilizarlo.
-Adherirse a metodologías (ej.
RUP)

43. PP SP 1.4 Determinar las estimaciones de
esfuerzo y coste
PROBLEMA (En
organizaciones inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Los estimados no se basan
en criterios objetivos.
Se suele estimar
“duración”, en lugar de
esfuerzo.
En gran medida (o
totalmente) se basan en
juicio de experto: no son
reproducibles.
No se conoce cómo se
llegó a los resultados.
Estimar el esfuerzo y costo
utilizando modelos de
estimación o datos
históricos, a partir de los
atributos (SP 1.2).
Se estima el esfuerzo y
costo tanto de entregables
como de tareas.
Documentar los supuestos
identificados
(especialmente cuando no
se tienen información
histórica).
Aplicar la técnica de estimación
definida (SP 1.2). Puede ser una
técnica adhoc.
Registrar supuestos. La técnica
debe permitir comprender cómo
se llegaron a los estimados
propuestos.
La técnica debe tratar de
minimizar las diferencias de
estimación, al ser ejecutada por
personas diferentes.
Utilizar información histórica.

44. Project Planning - PP
• PP nos dice que las siguientes son las
buenas prácticas básicas de planificación:

45. PP SP 2.1 Establecer el presupuesto y el
calendario
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
-No se conocen las
actividades del proyecto
- No se conocen las
dependencias entre tareas
- ¿Quién hace… qué?
- ¿Cuáles son los hitos del
proyecto?
- ¿Cómo se determina la
duración de las tareas?
- No se planifican las
tareas de gestión!!
Establecer y mantener el
presupuesto y calendario.
Se conocen los hitos y
supuestos del calendario.
Se conocen las dependencias.
Debe estar relacionado a la
estimación de esfuerzo.
Utilizar MS Project, indicando
dependencias; work y duration
adecuadamente; asignando
recursos a cada tarea y señalando
hitos.
Tener una plantilla de desacripción
del costo del proyecto.
Utilizar un cronograma en Excel,
con la información del punto
anterior, y los costos necesarios.
Utilizar un cronograma en alto
nivel, y planificar cada iteración
aplicando SCRUM.

46. PP SP 2.2 Identificar los riesgos del proyecto
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
No se anticipan a los
posibles problemas, a
pesar de ser predecibles.
Las organizaciones suelen
ser totalmente reactivas.
Prefieren que los riesgos
se conviertan en
problemas, y recién en
ese momento hacer algo
para resolverlos.
-Identificar y analizar los
riesgos del proyecto.
- ‘Analizar’ significa describirlos
y priorizarlos, evaluando
típicamente la probabilidad y el
impacto.
- Deben ser gestionados con los
stakeholders afectados.
- Durante la planificación se deben
identificar los riesgos asociados al
proyecto.
- El resultado debe registrarse en
algún lugar (ejemplo: Excel), pues
luego (durante la ejecución del
proyecto), se deben gestionar. (Ver
PMC)

47. PP SP 2.3 Planificar la gestión de los datos
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
- No sabemos qué
información requerimos ni
cuál vamos a producir.
- La información se
encuentra dispersa en
muchos lugares.
- No existe control de
acceso (todos pueden ver
/ modificar todo)
- Cierta data cambia
libremente, sin dejar
rastro ni evaluar impacto.
Planificar la gestión de los
datos del proyecto.
Debemos saber:
-Qué información debemos
recolectar y producir
- Cómo la vamos a proteger
- Cómo la vamos a cambiar
-Tener algún procedimiento que
indique qué información se
requiere y cuál se produce.
- Tener mecanismos para el
almacenamiento de datos.
Ejemplo: Sharepoint, aunque
podría utilizarse el file system en
conjunto con procedimientos.
- Establecer niveles de acceso (ej.
por rol)
- Manejar control de versiones en
ciertos entregables.

48. PP SP 2.4 Planificar los recursos del proyecto
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
La planificación de
recursos se enfoca
usualmente en Jefe de
Proyecto, Desarrolladores
y QA.
- No se identifican los
recursos para todas las
fases: equipamiento de
testing, …
Planificar los recursos para
ejecutar el proyecto.
Los recursos no son sólo
personas. Incluyen además:
- Equipamiento
- insumos o materiales
- métodos / procedimientos
Esta información debe quedar
documentada.
Tener un documento que indique
los requerimientos necesarios de
procesos, personal, equipamiento,
infraestructura.
Considerar todas las fases del
proyecto (no sólo desarrollo y
testing).

49. PP SP 2.5 Planificar el conocimiento y
habilidades necesarios
PROBLEMA (En
organizaciones inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Se espera contar con personal
con conocimiento y habilidades
suficientes.
Ocurren algunas de estas
situaciones:
-No se evalúa si el personal
cuenta con las habilidades y
conocimiento necesarios.
-Se hace poco para mejorar el
conocimiento y habilidades del
personal que lo requiere.
- Se cuenta con que el personal
“aprenderá sobre la marcha”.
Planificar el conocimiento y
habilidades necesarias para
ejecutar el proyecto.
Evaluar el nivel de
conocimiento de las personas
asignadas, e identificar las
necesidades de capacitación
(internas o externas).
Incluir las actividades de
entrenamiento en el plan.
Incluir en el plan de proyecto,
un plan que indique las
acciones de entrenamiento
definidas.
Identificar qué personas
requieren cada
entrenamiento.
Utilizar una descripción de
perfiles, en las que se indique
los conocimientos y
habilidades. Esto permitirá
identificar brechas y tomar
acción.

50. PP SP 2.6 Planificar el involucramiento de las
partes interesadas
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Se sabe que se necesita el
involucramiento de
muchos para ejecutar un
proyecto. Sin embargo, no
se planifica y coordina
oportunamente.
Se cuenta con que se
tendrá a las partes
disponibles cuando se
requiera.
Planificar el involucramiento de
los stakeholders identificados.
Considerar los stakeholders de
todas las fases del proyecto.
Identificar los relevantes: los
afectados por las actividades, y
aquellos con la experiencia
necesaria para realizar las
actividades.
Tener una matriz con los
stakeholders en las columnas y las
actividades del proyecto en las
filas. Marcar el nivel de interacción
en la intersección de manera que
se sepa cómo involucrar a cada uno
de ellos.
Otra manera es tener una plantilla
de cronograma, indicando qué rol
se involucra en cada actividad.
Indicar explícitamente para qué se
requiere el involucramiento.

51. PP SP 2.7 Establecer el Plan del Proyecto
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
- Usualmente, no se tiene
un plan que cubra todas
las prácticas de PP
mencionadas.
Todos los elementos relevantes
de la planificación deben
integrarse.
Une todo de manera lógica:
-Consideraciones sobre ciclo de
vida.
- Tareas técnicas y de gestión.
- Presupuestos y cronogramas.
- Hitos
- Gestión de Datos
- Recursos necesarios y
habilidades.
- Interacción con stakeholders.
Tener todos los elementos
documentados de las prácticas
anteriores de PP, unidos o
referenciados, de manera que se
puedan revisar en su conjunto.
El plan de proyecto no tiene que
ser necesariamente un documento
Word. Puede ser un conjunto de
plantillas, o sistemas, o la
combinación de ellos.

52. PP SP 3.1 Revisar los planes que afectan el
proyecto
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Los proyectos
generalmente
dependen de
actividades presentes
en otros planes.
No se identifican estas
dependencias, lo que
no permite anticipar
problemas existen
retrasos en estos
planes.
Revisar todos los planes que afectan
el proyecto para comprender los
compromisos del proyecto.
Generalmente, los proyectos tienen
dependencias con otros planes
internos y externos. Estos deben
identificarse para ser monitoreados.
Ejemplo: Plan de QA, plan de compra
de equipos, plan de capacitación, etc.
Planificar el seguimiento a estos
planes
Identificar y documentar los
planes, de manera que se pueda
hacer seguimiento a su
progreso.

53. PP SP 3.2 Reconciliar los niveles de trabajo y de
recursos
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Los planes suelen basarse
en recursos estimados
que difieren de los reales.
Por ejemplo:
-Menor personal al
necesario.
- Personal con menores
conocimientos o
habilidades.
Es común que el proyecto
inicia con estas diferencia
(aún siendo conocidas) sin
resolverse.
Reconciliar el plan del proyecto
para reflejar los recursos
disponibles y los estimados.
Una vez conocidos los recursos
reales, evaluar las diferencias
contra lo estimado, y resolver
las diferencias (negociando,
modificando el alcance, etc.)
Básicamente, se requiere aplicar
directamente la práctica.
Usualmente, se realizan reuniones
con los stakeholders relevantes
(gerente que asigna los recursos,
cliente que define el alcance, etc.)
y se resuelven las diferencias que
puedan surgir.
El plan y cronograma debe
evidenciar cambios como resultado
de la reconciliación.

54. PP SP 3.3 Obtener el compromiso con el plan
PROBLEMA (En
organizaciones inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
No se conoce el detalle de lo
que se debe hacer.
Los plazos y el alcance del
proyecto es desconocido por
los involucrados, quienes
adquieren conocimiento de
partes del proyecto.
Los plazos y costos pueden
estar lejos de la realidad. No
son revisados por los
involucrados.
Obtener el compromiso de las
partes interesadas relevantes,
responsables de ejecutar y dar
soporte a la ejecución del plan.
Interactuar con los stakeholders
hasta que sientan confianza de
poder ejecutar sus tareas en el
costo y plazo establecido en el
plan.
El objetivo es asegurar que el
plan se fundamente en objetivos
alcanzables, validados por
aquellos que lo ejecutarán.
Presentar el plan de proyecto
a los stakeholders en una o
más reuniones.
Los participantes se
comprometen con el plan
(firmando un documento o
no, depende del contexto del
negocio)

55. Project Monitoring and Control - PMC

56. PMC SP 1.1 Monitorizar los parámetros de
planificación del proyecto
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Generalmente, los
proyectos hacen
seguimiento sólo al
avance, y no a otros
parámetros como
tamaño, esfuerzo,
etc.
Se pierde la
oportunidad de
tomar acción
cuando existen
desviaciones.
Monitorear los valores
reales de los parámetros
de planificación contra el
plan.
Realizar seguimiento a los
valores reales. Documentar
el resultado.
Tener registros de las
desviaciones significativas
al comparar estimados vs
reales: tamaño, esfuerzo,
plazo, etc.
Al tener registrados los parámetros
de estimación (PP SP 1.2 y SP 1.4),
adicionar los valores reales.
Ejemplo: Esfuerzo y complejidad de
un caso de uso (estimados vs real).
Hacer seguimiento al avance
(cronograma), considerando
avance esperado vs real.
Evaluar las desviaciones y guardar
registro de ellas. Tomar acción
correctiva, y guardar registro de
ella.

57. PMC SP 1.2 Monitorizar los compromisos
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
¿Se conocen todos los
compromisos del
proyecto? (internos o
externos)
¿Se sabe cuáles se
cumplieron? ¿cuáles
tienen problemas?
Se monitorean los
compromisos contra
aquellos establecidos en el
plan.
Se tiene una lista de
compromisos en algún lugar
(lista, cronograma, etc.)
Mediante alguna actividad
se revisa que se cumplan.
Por ejemplo, tener reuniones
con una periodicidad definida,
con los diferentes roles del
proyecto, y revisar si se
cumplieron los compromisos
descritos en el cronograma.
Registrar si se cumplieron o no,
los problemas asociados, etc.

58. PMC SP 1.3 Monitorizar los riesgos del
proyecto
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Usualmente no se
identifican ni gestionan
riesgos.
No se realiza
seguimiento a riesgos
identificados.
Monitorear los riesgos
contra aquellos definidos en
el plan.
Actualizar el estado de los
riesgos identificados,
incluyendo sus atributos
(probabilidad, impacto)
Identificar nuevos riesgos
Mantener el registro de
riesgos definido, actualizando
sus atributos según los riesgos
o sus características varíen.
Analizar los riesgos con los
equipos. Puede ser en
reuniones grupales (en las
que también se toquen otros
temas).

59. PMC SP 1.4 Monitorizar la gestión de
datos
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
No se hace seguimiento
a:
-Los documentos o
entregables en general
que se acordó producir o
que se deben recibir.
- No se controla que se
tomen los mecanismos
que garanticen la
disponibilidad de los
datos.
Se verifica que la
documentación se esté
gestionando según lo
planificado.
La periodicidad de esta
revisión es definida por el
proyecto.
Ejemplo:
-En las reuniones de avance del
proyecto se verifica que la
documentación establecida se
está preparando.
-Se verifica que la información
requerida ha sido obtenida.
- Con menor frecuencia se
revisa que los niveles de
acceso establecidos se
cumplan.

60. PMC SP 1.5 Monitorizar la involucración
de las partes interesadas
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Es frecuente que no se
identifiquen y
coordinen las acciones
de involucramiento.
El seguimiento a su
ejecución suele no ser
riguroso.
Esos ocasiona
incumplimiento y
problemas al proyecto
Se asegura que las
interacciones definidas con
el plan se cumplan.
Si las actividades de
involucramiento se
encuentran incluidas en el
cronograma, esta práctica se
satisface haciendo
seguimiento al mismo.
Si las actividades se
encuentran en el cronograma,
se satisface la práctica al
realizar el seguimiento al
documento que lo contenga
Si el cronograma contiene
también los compromisos,
entonces esta práctica y la
PMC SP 1.2 se satisfacen
juntas.

61. PMC SP 1.6 Llevar a cabo revisiones de
progreso
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Es común que los
equipos de proyecto no
tengan visión integral
sobre el progreso del
proyecto.
Se refiere al monitoreo del
“status” del proyecto, en un
punto determinado del
tiempo.
Participan los representantes
del proyecto, y se informan
sobre el estado.
Se determinan problemas
significativos o de
desempeño que se deban
atender.
Ejemplo: En reuniones de
periodicidad definida (ej.: 1
vez por semana), se hace
seguimiento al avance,
revisando las variables de
desempeño establecidas.
Los integrantes observan el
status del proyecto, se revisa
la lista de problemas, se
comunica cualquier situación
que requiera atención.

62. PMC SP 1.7 Llevar a cabo revisiones de
hitos
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Los hitos son puntos en el
tiempo con metas
intermedias del proyecto.
Estos hitos no son
aprovechados para
evaluar con los usuarios y
stakeholders lo alcanzado
y establecer las
condiciones de lo que
continúa.
Revisar los logros y
resultados del proyecto
en hitos seleccionados.
Los hitos son momentos
planificados en los que se
realiza un seguimiento
riguroso del estado, para
entender qué tan bien
estamos logrando los
requerimientos de los
stakeholders.
Tener reuniones formales con
el cliente y stakeholders
relevantes, para revisar lo
alcanzado, aceptarlo
formalmente y evaluar los
pasos siguientes.
Producir un acta que
evidencie los acuerdos.
Pueden ser reuniones en las
que se revisen otros temas
adicionales.

63. PMC SP 2.1 Analizar problemas
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
La gestión de problemas
suele ser empírica y sin
registro ni seguimiento
formal.
No se hace seguimiento a
las acciones correctivas
(como si fueran tareas
del proyecto).
Recolectar y analizar los
problemas y determinar
acciones correctivas para
resolverlos.
Se establece un mecanismo
para la gestión de los
problemas, en el que se
indica dónde se registran, las
acciones correctivas
asignadas así como los
responsables.
Los problemas que
aparecen como resultado
de las acciones de
seguimiento anteriores son
analizados.
Tener algún mecanismo (ej.
formato en Excel), en el que
se listen los problemas
identificados, así como las
acciones correctivas
establecidas y sus
responsables.

64. PMC SP 2.2 Llevar a cabo las acciones
correctivas
PROBLEMA (En
organizaciones inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Algunas acciones
correctivas pueden
asignarse, pero la
información no se registra.
No se sabe qué problemas
no tienen acción asignada.
Si el jefe de proyecto no se
encuentra disponible, nadie
puede hacer seguimiento a
los problemas pues no
están registrados.
Tomar acción correctiva
sobre los problemas
identificados.
Las acciones correctivas
contienen información
concreta: tarea a
realizar (a nivel de
detalle que pueda ser
comprendida por el
responsable de su
realización), fecha de
realización, estado.
En la plantilla definida para el
registro del problema,
describir las acciones
correctivas tomadas,
indicando el responsable y la
fecha estimada de su
realización.

65. PMC SP 2.3 Gestionar las acciones
correctivas
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
No se sabe qué acciones
correctivas fueron
definidas ni quiénes son
los responsables.
No se conoce cuántas de
ellas se encuentran
pendientes de realizar,
cuántas se realizaron, y
si el problema se puede
considerar resuelto.
Gestionar las acciones
correctivas hasta su cierre.
En el formato designado para
registrar los problemas y sus
acciones, se tienen campos
para indicar el resultado del
seguimiento, así como estado
de la acción correctiva y del
problema.
Su seguimiento es realizado
por el jefe de proyecto con
periodicidad establecida

66. Requirements Management (REQM)

67. REQM SP 1.1 Obtener una comprensión de
los requerimientos
PROBLEMA (En
organizaciones inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Recibimos requerimientos
de múltiples fuentes,
formas, en distinto formato.
No se valida que los
requerimientos cumplan los
criterios que aseguren su
calidad.
Desarrollar un
entendimiento sobre el
significado de los
requerimientos.
Existen criterios para
recibir y aceptar
requerimientos.
Se tienen actividades
para alcanzar
entendimiento
Definir criterios y
documentarlos. Ejemplo: (1)
personas autorizadas para
proporcionar
requerimientos. (2) plantilla
para especificar
requerimientos. (3) nivel de
detalle (4) evitar términos
ambiguos.
Se realizan actividades para
revisar la lista de
requerimientos, la cual se
establece y es conocida.

68. Relación entre las áreas de proceso
REQM y RD
• El área de proceso RD (Desarrollo de Requerimientos) está
relacionada a REQM.
• RD indica las prácticas para alcanzar la comprensión de los
requerimientos (que corresponde al objetivo de la SP 1.1 de
REQM).
• REQM contiene lo básico (la gestión), mientras que RD las
prácticas más complejas que permiten comprender los
requerimientos.
SP 1.1
SP 1.2
SP 1.3
SP 1.4
SP 1.5
REQM
RD
SP 1.1
…
SP 3.5

69. REQM SP 1.2 Obtener el compromiso
sobre los requerimientos
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Aquellos responsables de
desarrollar / probar el
código no conocen los
requerimientos.
Son ellos quienes pueden
evaluar la factibilidad de
elaborarlos.
Usualmente, el proyecto
se entera de dificultades
en su desarrollo
demasiado tarde.
Obtener el compromiso
con los requerimientos
de los participantes del
proyecto.
Considerar también el
compromiso con los
cambios a los
requerimientos.
Existe evidencia del
compromiso.
Ejemplo: Tener una reunión
con los desarrolladores y
testers, luego de que estos
revisen los requerimientos.
En la reunión expresan su
compromiso, considerando los
plazos.
Se produce un acta con el
resultado de la reunión.

70. REQM SP 1.3 Gestionar los cambios de los
requerimientos
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
No se tienen mecanismos
controlados para la
gestionar los cambios
(que sabemos que
sucederán siempre)
No conocemos el impacto
completo del cambio.
No sabemos qué
requerimientos
cambiaron, y si se aplicó
el cambio o no.
Gestionar los cambios a los
requerimientos, a medida
que estos evolucionan a lo
largo del proyecto.
Se evalúa el impacto con los
involucrados, y se aplican o
descartan los cambios,
según sea el acuerdo.
Se documentan el cambio
(fuente, detalle e impacto)
Definir un proceso de control
de cambios, que indique
quiénes participan.
Registrar los cambios en un
formato, indicando el estado
del mismo.
Hacer seguimiento a la
aplicación de los cambios
(como parte de las
actividades de seguimiento
del proyecto).

71. REQM SP 1.4 Mantener la trazabilidad
bidireccional de los requerimientos
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Usualmente no se sabe
si todos los entregables
intermedios
(especificaciones, casos
de prueba, etc.) cubren
todos los
requerimientos.
Mantener trazabilidad
bidireccional entre los
requerimientos y
entregables.
Debe indicar trazabilidad
entre: requerimientos,
requerimientos derivados,
especificaciones, casos de
prueba, releases, código
fuente, etc.
Varias maneras:
Tener una matriz de
trazabilidad en Excel.
Indicar en los entregables el
número de requerimiento
asociado. Ejemplo: En las
especificaciones, código
fuente, etc., indicar qué
requerimientos satisface.

72. REQM SP 1.5 Identificar las inconsistencias entre el
trabajo del proyecto y los requerimientos
PROBLEMA (En
organizaciones
inmaduras)
PRÁCTICA DE CMMi
(“Qué hacer”)
IMPLEMENTACIÓN
(“Cómo hacerlo”)
Algunas ideas
Inicialmente, se procura
tener un plan de trabajo
en línea con los
requerimientos
acordados.
Sin embargo, suele
suceder que los planes
no contemplan los
nuevos requerimientos o
cambios al alcance de los
acordados inicialmente.
Identificar las
inconsistencias entre los
planes del proyecto, los
productos de trabajo y los
requerimientos.
Ejemplo:
- Hacer seguimiento a los
cambios a los
requerimientos aceptados.
Asegurar que el cronograma
los considere y que alguien
tenga asignado atenderlo.

73. Otras áreas de proceso del CMMi
• Propósito
– Comprender los objetivos principales del resto de
áreas de proceso que comprende el CMMi.
– Conocer cuáles son las relaciones entre las áreas de
proceso.

74. Desarrollo de Requerimientos
(Requirements Development – RD)
• Pertenece al Nivel 3 (rep. por Etapas)
• Propósito:
– “Elicitar”, analizar y establecer los requerimientos de
cliente, producto y componente de producto.
• Aspectos principales
– Elicitar necesidades y transformarlas en
requerimientos.
– Establecer requerimientos de producto y de
componente de producto.

75. Desarrollo de Requerimientos
(Requirements Development – RD)
• Aspectos principales (continuación)
– Asignar los requerimientos de componente de producto.
– Identificar requerimientos de interfase.
– Establecer conceptos operacionales y escenarios.
– Analizar requerimientos:
• Identificar requerimientos clave
• Priorizar
• Alcanzar balance entre requerimientos y restricciones del
proyecto
– Validar los requerimientos

76. Solución Técnica (Technical Solution – TS)
• Pertenece al Nivel 3 (rep. por Etapas)
• Propósito:
– Seleccionar, diseñar e implementar soluciones a los
requerimientos.
• Aspectos principales
– Evalúa y selecciona soluciones (enfoques de diseño o
diseños preliminares), que potencialmente satisfacen un
conjunto de requerimientos asignados. Establece criterios
para evaluar a la mejor solución.
– Desarrollo de diseños detallados aplicando criterios.
– Diseño de interfases.

77. Solución Técnica (Technical Solution – TS)
• Aspectos principales (continuación)
– Analizar si es conveniente construir, comprar o reusar.
– Desarrollar la solución (codificar), adhiriéndose a
estándares y realizando pruebas unitarias.

78. Integración de Producto (Product
Integration – PI)
• Pertenece al Nivel 3 (rep. por Etapas)
• Propósito:
– Ensamblar el producto, asegurar que el producto
integrado se comporta adecuadamente, y entregar el
producto.
• Aspectos principales:
– Establecer la estrategia de integración.
– Establecer el entorno de integración.
– Establecer el proceso de integración y criterios.

79. Integración de Producto (Product
Integration – PI)
• Aspectos principales (continuación):
– Adicionalmente, PI tiene especial énfasis en la gestión
de interfases:
• Revisar las descripciones de las interfases.
• Gestionar las definiciones y diseños de las interfases, así
como sus cambios.
– ¿Qué se considera interfases?
• Cualquier mecanismo que permita comunicar partes
dentro de un sistema (interfases internas), o comunicar
entre sistemas (interfases externas)
• Todas ellas deben ser gestionadas.

80. Verificación (Verification – VER)
• Pertenece al Nivel 3 (rep. por Etapas)
• Propósito:
– “Verificar” significa “asegurar que construimos algo
correctamente”.
• Aspectos principales:
– Todas las actividades de verificación deben ser
planificadas y tener procedimientos establecidos.
– Realizar revisiones de pares.
• Son revisiones entre colegas (un desarrollador revisa el trabajo
de otro desarrollador).
• Se utilizan checklists.
• Se registran las observaciones y se hace seguimiento a su
corrección.

81. Validación (Validation – VAL)
• Pertenece al Nivel 3 (rep. por Etapas)
• Propósito:
– “Validación” significa “asegurar que se construyó lo
correcto”.
– Demostrar que el producto o componente de producto
satisface totalmente el uso esperado, al ser colocado en
el ambiente de ejecución esperado.
• Aspectos principales:
– Se tiene un criterio definido para guiar las pruebas: Casos
de Prueba.
– Se analizan los resultados, y toman decisiones

82. Relación entre las áreas de proceso de
Ingeniería

83. Gestión de Acuerdos con Proveedores
(Supplier Agreement Management –SAM)
• Pertenece al Nivel 2 (rep. por Etapas)
• Propósito
– Gestionar la compra de productos y componentes que se
entregan al cliente. Involucra:
• Determinar el mecanismo de compra.
• Seleccionar los proveedores.
• Establecer y mantener los acuerdos con los proveedores.
• Realizar el acuerdo del proveedor.
• Monitorizar los procesos del proveedor.
• Evaluar los productos suministrados por el proveedor.
• Aceptar la entrega de los productos adquiridos.
• Entregar los productos al proyecto.

84. Gestión Integrada de Proyectos
(Integrated Project Management –IPM)
• Pertenece al Nivel 3 (rep. por Etapas)
– Es una evolución de la gestión de proyectos que
indican PP y PMC.
– Cada proyecto ajusta los procesos estándares para
que satisfacer sus necesidades.
• Se ajustan los ciclos de vida, estándares, procesos, etc.
• Se toma en cuenta las lecciones aprendidas y data de
proyectos anteriores.

85. Gestión Cuantitativa de Proyectos
(Quantitative Project Management –QPM)
Requeri
mientos
Diseño
Programac
ión
Pruebas
unitarias
Pruebas de
integración
Pruebas
de sistema
BD
Se toman métricas para
ser utilizadas en el control
oportuno del proyecto.
Se toman
medidas,
métricas,
indicadores, y
son almacenados

86. Gestión de Riesgos (RSKM)
• La organización establece:
– Fuentes de riesgos
– Parámetros de riesgos
– Estrategias de gestión de riesgos
• Se evalúan y categorizan los riesgos
• Se desarrollan planes de mitigación, acorde con
la estrategia seleccionada.
• Como es nivel 3,… las fuentes de riesgos y otros
parámetros provienen (también) de experiencias
en proyectos anteriores.

87. Medición y Análisis (Measurement and
Analysis – MA)
• Pertenece al Nivel 2 (rep. por Etapas)
• Propósito:
– Desarrollar y sostener la capacidad de efectuar
mediciones, para soportar las necesidades de gestión.
• Aspectos principales:
– Se deben establecer objetivos de medición.
– Definir procedimientos de obtención de datos,
interpretación, reporte, etc.
– En niveles de madurez mayores (3 en adelante) se
requiere un repositorio de métricas, que consolide
indicadores a nivel organizacional).

88. Aseguramiento de la Calidad de Proceso y
Producto - PPQA
• Pertenece al Nivel 2 (rep. por Etapas)
• Propósito:
– Asegurar que los procesos se cumplan, tal como han sido
definidos.
• Aspectos principales:
– Se trata de controles que se ejecutan durante el ciclo de
vida del proyecto.
– Las no-conformidades encontradas deben resolverse,
para que el proyecto pueda continuar con la siguiente
fase.
– Permite satisfacer la G.P. 2.9.

89. Gestión de Configuración
• Pertenece al Nivel 2 (rep. por Etapas)
• Propósito: establecer y mantener la integridad de los
productos de trabajo.
• La integridad se alcanza:
– Identificando el estado de configuración. Es decir, si un
elemento constituye
• La versión vigente, acordada o aceptada
– Controlando los cambios a los elementos
• Algunos requerirán un control riguroso, analizando impacto.
• Otros sólo requerirán ser versionados, y guardar historia de
cambios.

90. Capacitación Organizacional
• Pertenece al Nivel 3 (rep. por Etapas)
• Propósito: Desarrollar las habilidades y el
conocimiento de las personas para que puedan
realizar sus roles eficaz y eficientemente.
• Demuestra el carácter ‘proactivo’ de una
organización Nivel 3.
• La organización se preocupa en identificar las
necesidades de conocimiento y habilidades a nivel
organizacional.
• Se establece un plan estratégico y se imparte la
capacitación.
• Se mide la eficacia del entrenamiento.

91. Relación entre las áreas de proceso de
Soporte (básicas)