Javier Garzs Parra

Emanuel A. Irrazbal
Roberto Santa Escolstica

Gua prctica de supervivencia

en una auditora CMMI
Nmero 2011-002

Boletn de la ETSII
ISSN: 2172-6620
Escuela Tcnica Superior de Ingeniera Informtica
Universidad Rey Juan Carlos

Gua prctica de supervivencia en una auditora CMMI

Javier Garzs Parra1, Emanuel A. Irrazbal1, Roberto Santa Escolstica2
1

Kybele Research Group, Universidad Rey Juan Carlos; Madrid, Espaa

{javier.garzas, emanuel.irrazabal}@urjc.es
2
Kybele Consulting, C/Oliva 18, 3A, 28231 Las Rozas, Madrid, Espaa
{roberto.santaescolastica}@kybeleconsulting.com

Abstract. Enfrentarse por primera vez a una auditora CMMI supone tener que
superar una gran carga de actividades y enfrentarse a una gran cantidad de
terminologa nueva y compleja. Por ello, esta gua pretende facilitar la tarea de
preparacin de una auditora CMMI, ayudando as a reducir el importante
sobreesfuerzo que habitualmente supone su realizacin.
Keywords: CMMI, SCAMPI, auditora, desarrollo, software.

Prefacio

Enfrentarse por primera vez a una auditora CMMI [1] supone tener que superar una gran
carga de actividades y enfrentarse a una gran cantidad de terminologa nueva y compleja. A
esto se aade que es habitual que las empresas, inmersas en su rutina diaria, no dispongan
de mucho tiempo para preparar las auditoras.
Bajo estos precedentes, conscientes de la necesidad cada vez mayor por parte de las
empresas de disponer de certificaciones software, pretendemos con esta gua facilitar la
tarea de preparacin de una auditora CMMI, ayudando a reducir el importante
sobreesfuerzo que supone su realizacin.
Pretendemos que esta gua sea un manual de supervivencia a la hora de enfrentarse a una
auditora de CMMI. Y como tal herramienta de supervivencia, proporciona lo ms bsico y
esencial para poder afrontar la auditora y de ah que hayamos pretendido que no supere 40
pginas de enfoque puramente prctico, an a riesgo de obviar por ello algn detalle o
matizacin terica, pero para este tipo de detalles existen otros muchos libros.
Comentar tambin, que este no es un documento de consultora, y tampoco est enfocado a
implantar CMMI o mejorar los procesos software, eso lo dejamos para otros textos. Este es
un documento esencialmente de preparacin para la auditora, que normalmente te ser de
utilidad si has liderado una mejora CMMI y en breve te enfrentars a la auditora o si te han

invitado a participar en el equipo de auditora.

1.1

Aclaracin sobre la terminologa

El trmino auditora. Siendo rigurosos, ms que auditora en CMMI el trmino correcto

sera evaluacin, que proviene del trmino anglosajn appraisal y que es el que se usa en
CMMI. Sin embargo, durante el texto utilizaremos la palabra auditora por ser la ms
utilizada en el da a da de las empresas, facilitando as el objetivo de simplificar la
terminologa de cara a la preparacin de una auditora CMMI.
Niveles de madurez y capacidad. CMMI define dos maneras de evaluar los procesos, por
niveles de capacidad y por niveles de madurez. La ms comn es esta ltima, que permite
la obtencin de un nivel de madurez para la organizacin. Por ello, durante esta gua
cuando hablamos de la auditora nos referiremos nicamente a la evaluacin por niveles de
madurez.
Terminologa en ingls. A lo largo de esta gua, en ocasiones aparecern ciertas
expresiones en ingls relacionadas con la auditora. Hemos decidido mantener esta
terminologa en ingls debido a que es la que se utiliza comnmente durante la auditora, y
con la que deberemos acabar familiarizndonos.
Trminos en castellano. Para mantener la mayor rigurosidad posible, los trminos
utilizados en esta gua y relacionados con CMMI que estn en castellano han sido extrados
de la traduccin realizada por la Ctedra de Mejora de Procesos de Software en el Espacio
Iberoamericano de la Universidad Politcnica de Madrid, publicada por el SEI como
traduccin de la versin 1.2 de CMMI for Development y titulada CMMI: Gua para la
integracin de procesos y la mejora de productos [2].
1.2

Versin del modelo

Esta gua est basada en la versin 1.2 del mtodo SCAMPI (ver captulo 2) de CMMI [3].
En el momento de elaboracin de esta gua, la versin 1.3 [4] del citado mtodo acababa de
ser liberada. Sin embargo, la versin 1.2 es an la de mayor uso y sobre la que se tiene una
mayor experiencia, por lo que esta gua entra en detalle en esa versin del mtodo. Los
detalles ms importantes en los que se diferencian las versiones 1.2 y 1.3 del SCAMPI son
comentados a lo largo de esta gua. Por otro lado, si bien existen actualmente 3
constelaciones CMMI, este documento se centra en el modelo CMMI-DEV, que
corresponde a desarrollo.

Las auditoras CMMI

Cuando una organizacin ha conseguido mejorar sus procesos e implantar los

correspondientes a un nivel de madurez CMMI (ver anexo), es comn que decida que ha
llegado el momento de presentarse a una auditora que corrobore dicha implantacin por un
tercero, un auditor externo. Y es ah cuando aparecen una serie de peculiaridades, tareas y
trminos que suelen causar mucha confusin en el equipo de mejora. En este captulo
aclararemos las principales dudas de carcter general que se plantean en el momento de
comenzar con una auditora CMMI.
2.1

Qu es un SCAMPI A y quin lo realiza?

Se denomina as a la evaluacin o auditora final de concesin oficial de un nivel de

madurez de CMMI. SCAMPI es el acrnimo de Standard CMMI Appraisal Method for
Process Improvement [3]. Este es un mtodo sobre cmo evaluar los diferentes procesos
de la organizacin, definiendo el nivel de madurez. Se distinguen tres tipos de SCAMPI (A,
B C) en funcin de la formalidad y la dificultad del mismo. El ms riguroso es el
SCAMPI A y es el que permite obtener el nivel de madurez oficial. Una vez superado el
SCAMPI A, es comn que la organizacin reciba un diploma acreditativo que indica el
nivel de madurez alcanzado.
El SCAMPI A debe ser realizado por una figura denominada Lead Appraiser. El Lead
Appraiser es una persona acreditada por el SEI (Software Engineering Institute,
organizacin propietaria del modelo CMMI) para realizar la evaluacin CMMI.
Finalmente, es el Lead Appraiser quin emite lo que se conoce como Appraisal Disclosure
Statement, documento que muestra los resultados de la evaluacin [5].
2.2

Quin respalda una auditora CMMI?

Comnmente se piensa que es el Software Engineering Institute (SEI), ya que es la

organizacin propietaria del modelo. Sin embargo, el SEI solamente acredita a los auditores
o Lead Appraiser para que puedan realizar evaluaciones CMMI. No es el SEI quien emite
un certificado, sino que son los auditores los que emiten un diploma en el que se indican los
datos y resultados de la auditora. Son estos auditores y las empresas partner del SEI en las
que trabajan los que se responsabilizan de los resultados de la evaluacin.
Por ello normalmente se utiliza el concepto evaluacin en vez de certificacin cuando nos
referimos a una auditora CMMI.

2.3

Durante cunto tiempo son vlidos los resultados de la evaluacin?

Los resultados de la evaluacin son vlidos durante un mximo de 3 aos desde la fecha en
que se emite el Appraisal Disclosure Statement.
2.4

Es necesario evaluar todas las reas de proceso?

En funcin del nivel de madurez que se pretenda alcanzar, ser necesario evaluar una serie
de reas de proceso. Todas las reas de proceso correspondientes a un nivel de madurez son
obligatorias a excepcin de SAM (Supplier Agreement Management) (ver anexo para el
listado completo de reas de proceso de CMMI por nivel de madurez), que puede no ser
aplicable a la organizacin y por tanto no ser evaluada.
2.5

Qu costes internos han de tenerse en cuenta?

Adems de los costes propios de contratar la auditora, es necesario tener en cuenta que 4
personas deben de participar plenamente durante la misma (aproximadamente entre 8 y 12
das). Estas 4 personas deben cumplir con unos requisitos bastante estrictos (ver captulo 5)
por lo que normalmente se corresponden con perfiles cualificados dentro de la empresa. Por
lo tanto, no hay que olvidar que la organizacin tendr que soportar unos costes internos.

Fases y la duracin de la auditora

La realizacin de una auditora CMMI requiere llevar a cabo una serie de actividades. El
mtodo SCAMPI define varias actividades a realizar, que abarcan desde que la definicin
de los objetivos de la auditora hasta el reporte de los resultados de la evaluacin. Para
evitar complejidad innecesaria, no vamos a detallar todas las etapas, slo las que afectan
ms a la organizacin, que agruparemos en 3 fases. Para cada una de estas fases, se indica
una estimacin de su duracin. Hay que destacar que estas duraciones se refieren a la
duracin temporal de cada una de las fases, no al esfuerzo necesario para realizarlas (no son
das/hombre):
Preparacin y planificacin de la auditora: en esta fase se seleccionan los objetivos
de la mejora, se define el mtodo de captura de evidencias, etc. Esta fase es
realizada por el Lead Appraiser y tiene una duracin aproximada de 2 jornadas.
Readiness-review: en esta fase se estudia si la organizacin est preparada para la
auditora. La duracin de esta fase, que es realizada por el equipo de evaluacin, es
de aproximadamente 3 jornadas. Ampliaremos la informacin de esta fase en el
captulo 6.

Ejecucin de la auditora y comunicacin de resultados: durante esta actividad se

realiza la auditora final de concesin de un nivel de madurez de CMMI. Es
realizada por el equipo de evaluacin, y tiene una duracin estimada de 5 jornadas
para el nivel de madurez 2 y de 10 jornadas para el nivel de madurez 3.

Fig. 1. Fases de una evaluacin SCAMPI

Los proyectos que sern auditados y la unidad organizacional

Cuando se va a realizar una auditora SCAMPI, es necesario tener claro qu parte de la

organizacin va a ser evaluada. Al subconjunto de la organizacin que ser evaluado se le
denomina unidad organizacional. Este punto es importante porque una vez concedido el
nivel, el diploma que nos entreguen contendr explcitamente la unidad organizacional
evaluada. Por otro lado, una vez definida la unidad organizacional, se determinar qu
proyectos van a ser evaluados del total de la misma, estos proyectos formarn la muestra
de proyectos.
4.1

La unidad organizacional

La unidad organizacional se corresponde con la parte de la organizacin que va a ser

evaluada. Las partes o departamentos de una organizacin que componen la unidad
organizacional debern tener unos objetivos de negocio comunes y un conjunto de procesos
coherentes. Una unidad organizacional puede ser un departamento, un conjunto de
departamentos, una tipologa de proyectos, etc., o, en caso de ser una empresa pequea,
toda la organizacin.
Por ejemplo, puede darse el caso de una empresa multinacional con sedes en Madrid,
Buenos Aires y Cceres que defina que la unidad organizacional sea solamente una de las
sedes. Pero tambin puede darse el caso de una organizacin con varias sedes pero con tres
departamentos bien definidos (desarrollos internos, desarrollos a medida y desarrollos para

sistemas empotrados) que decida que la unidad organizacional sea el departamento de

desarrollos a medida, aunque este involucre a varias sedes.
4.2

La muestra de proyectos

Cuando se va a realizar una evaluacin SCAMPI, normalmente no se evalan todos los

proyectos de la unidad organizacional, sino que se selecciona una muestra de proyectos
representativa de la misma. La seleccin de los proyectos adecuados para la muestra es una
tarea importante dentro de una auditora CMMI, ya que estos deben cubrir todos los
factores crticos que se identifiquen dentro de la unidad organizacional.
A la hora de realizar la evaluacin, se distinguen tres tipos de proyectos, que pueden formar
parte de la muestra1:
Proyecto objetivo: es un proyecto que aporta evidencia objetiva (veremos qu es
una evidencia en el captulo 7) de todas las reas de proceso del nivel de madurez a
evaluar. A la hora de evaluar el proyecto no importa si este ha terminado o no (hay
por ejemplo proyectos que estn en mantenimiento un gran nmero de aos),
solamente se comprueba si proporciona evidencia para cada una de las reas de
proceso definidas en el nivel CMMI a evaluar. Un ejemplo de un proyecto de este
tipo puede ser un proyecto de desarrollo para un cliente que se encuentra al final de
la fase de pruebas. En el caso de que a lo largo del proyecto se hayan seguido
correctamente los procesos definidos en la organizacin, el proyecto podr
proporcionar evidencia de cada una de las reas de proceso del nivel de madurez
evaluado.
Proyecto no objetivo: es un proyecto que aporta evidencia objetiva de alguna de las
reas de proceso dentro del alcance de la evaluacin. Estos proyectos sirven como
complemento de los proyectos objetivos, para obtener mayor nmero de evidencias
de la realizacin de cada una de las prcticas definidas en CMMI (explicaremos
qu es una prctica en el captulo 7). Un ejemplo de un proyecto de este tipo puede
ser un proyecto de desarrollo de una Web iniciado en las ltimas fases de la
implantacin de CMMI, y que se encuentra an en el anlisis de requisitos. Este
proyecto puede proporcionar evidencias en algunas reas de proceso, como en la
Gestin de Requerimientos, pero difcilmente podr proporcionar evidencias para
todas las reas de proceso de nivel de madurez 2.
Funcin de apoyo: funcin organizativa que aporta evidencia objetiva de las reas
de proceso organizativas, por ejemplo formacin, el aseguramiento de la calidad,
RRHH, etc.
Para superar una evaluacin SCAMPI, es necesario presentar al menos un proyecto
objetivo. Adems, es necesario presentar tantos proyectos, objetivos o no objetivos, como
1

A partir de la versin 1.3 de SCAMPI ya no se distingue entre proyectos objetivos y no objetivos.

Adems, los proyectos pasan a ser denominados unidades bsicas.

sean necesarios para obtener al menos 3 evidencias de la realizacin de cada una de las
prcticas de cada rea de proceso a evaluar.2
Esto no es as para todas las reas de proceso. CMMI cuenta con algunas reas de proceso
que son a nivel de organizacin (por ejemplo, Formacin organizativa - OT)3. En el caso de
las prcticas de estas reas de proceso, slo es necesario proporcionar una evidencia, por lo
que la cuestin de nmero de proyectos no aplica para ellos.

Los participantes en la auditora

Para poder llevar a cabo una auditora CMMI, es necesario un equipo de trabajo que
cumpla unos requisitos mnimos. De esta manera se asegura la experiencia, el conocimiento
y las habilidades necesarias para participar en la auditora.
El personal necesario para participar en actividades o realizar tareas en una evaluacin
SCAMPI A (tanto de la organizacin a evaluar como de la organizacin evaluadora)
incluye los siguientes roles:
Sponsor. Es el encargado de liderar el proyecto de mejora. Normalmente, se
corresponde con un directivo de la organizacin.
Jefe del equipo de evaluacin (Appraisal Team Leader). Responsable de realizar la
evaluacin. El jefe del equipo de evaluacin debe ser un Lead Appraiser, y
pertenecer a una empresa partner del Software Engineering Institute (SEI) para
poder realizar la evaluacin, as como tener la experiencia y entrenamiento
necesario.
Coordinador de la organizacin (Organizational Unit Coordinator u OUC).
Encargado de facilitar la realizacin de la auditora. Proporciona la informacin
necesaria al evaluador. Es comn que se corresponda con el responsable de calidad
de la organizacin.
Miembros del equipo de evaluacin (Appraisal Team Members o ATM). Personal
de la organizacin a auditar y que cumple con los requisitos para formar el equipo
de evaluacin, y que cuenta con la experiencia y el entrenamiento suficiente.
Participantes seleccionados. Encargados de proporcionar la informacin necesaria.
Es comn que sean jefes de proyecto de los proyectos evaluados.
La evaluacin SCAMPI A debe ser realizada por un equipo evaluador formado por un
evaluador lder -SCAMPI Lead Appraiser y 4 integrantes (ATM). Cada uno de estos 4
2

En la versin 1.3 de SCAMPI, el nmero de proyectos a incluir en la muestra se calcula

cuantitativamente, en funcin del nmero de los subgrupos (proyectos de la organizacin que cuentan
con unas mismas caractersticas para la implementacin de los procesos en cuanto a lugar de
implementacin, cliente, tamao, etc.) y de las unidades bsicas.
3 Los procesos y sus acrnimos pueden ser consultados en el Anexo de este documento.

ATM, debe satisfacer los siguientes requisitos:

Debe haber asistido previamente al curso oficial del SEI Introduction to CMMI.
Debe tener disponibilidad completa durante la evaluacin (fases de preparacin y
ejecucin). Aproximadamente 8 y 12 das para los niveles de madurez 2 y 3
respectivamente.
Debe ser independiente de los proyectos evaluados. No podr por tanto ser
responsable de ninguno de los proyectos seleccionados para la evaluacin, ni ser
responsables directos o indirectos de aquellas personas que sern entrevistadas
durante la evaluacin.
Cada miembro del equipo evaluador debe tener al menos 6 aos de experiencia
promedio en el campo de desarrollo software y la suma de experiencias de los
miembros del equipo debe ser de al menos 25 aos como experiencia total del
grupo. Es recomendable que cada miembro del equipo tenga al menos 3 aos de
experiencia en cada una de las disciplinas que sern parte de la evaluacin 4.
Al menos un miembro del equipo de evaluacin deber tener al menos 6 aos de
experiencia en la gestin de proyectos software. El equipo evaluador en total
deber tener al menos 10 aos de experiencia en dicha gestin.
El equipo de evaluacin deber tener unos conocimientos adecuados de las
diferentes fases del ciclo de vida de desarrollo de los proyectos y sobre diferentes
entornos y dominios de negocio de los proyectos de la organizacin evaluada. Al
menos dos miembros del equipo han de tener experiencia prctica.
Es altamente recomendable que los miembros del equipo de evaluacin puedan
leer documentacin tcnica en ingls, dado que mucho del material de soporte del
mtodo SCAMPI est en este idioma.
El SCAMPI Lead Appraiser es quien finalmente decide la aceptacin o no de los
miembros del equipo evaluador y es el responsable de asegurar que sus
cualificaciones y su sostenibilidad estn acordes con el propsito de la evaluacin.

La fase Readiness review

El objetivo de esta fase es conocer si la organizacin est preparada para afrontar la

auditora. En esta fase se analizan las evidencias objetivas, la preparacin del equipo de
evaluacin y la preparacin logstica (instalaciones, equipamiento, disponibilidad, etc.) para
conocer si es posible llevar a cabo la auditora. Tras la realizacin de esta etapa, se decide si
continuar con el plan tal como estaba previsto, si es necesario realizar una re-planificacin o
si es mejor cancelar el proyecto. El Lead Appraiser es el responsable de tomar esta decisin,
en funcin de los resultados de la realizacin de esta evaluacin.

En la versin 1.3 de SCAMPI, los requisitos para formar parte del equipo de evaluacin se han
modificado ligeramente. Ya no es necesario tener 3 aos de experiencia en el campo de la evaluacin,
sino 2 aos. Adems, se han endurecido los requisitos para los niveles altos de madurez.

En la fase readiness review deben participar al menos:

El jefe del equipo de evaluacin.
Es recomendable que participe al menos un representante de cada proyecto
evaluado dentro de la unidad organizacional.
Cualquier otro representante de la unidad organizacional que se desee.
Las tareas principales que se realizan en esta fase son las siguientes:
Evaluar las evidencias para la auditora. En esta fase, se analizan las PIIDB o bases
de datos de evidencias (en el captulo 7 se trata en detalle este tema), analizando
los artefactos incorrectos, los que faltan y los que estn incompletos, para los
diferentes proyectos de la muestra.
Evaluar las instalaciones, el equipamiento y la disponibilidad del equipo, para
concretar si es posible llevar a cabo una auditora CMMI.
Evaluar la preparacin del equipo. En esta fase se realiza una formacin para que
el equipo est preparado para la auditora. Durante esta fase se determina si el
equipo est preparado para superar una evaluacin CMMI, para lo que se analiza
cmo operan los equipos entre s, su efectividad, etc.
Una vez que se ha completado la fase Readiness Review, se lleva a cabo la evaluacin
final, que en caso de superarla da como resultado el nivel de madurez alcanzado.

Los indicadores de implementacin de la prctica (PII) y la

base de datos de indicadores (PIIDB)

Para comprender qu son los indicadores de implementacin de la prctica es necesario

conocer primero la estructura de un rea de proceso. Las reas de proceso estn compuestas
de unos objetivos, que deben ser alcanzados para cumplir con el rea de proceso. Se
distinguen dos tipos de objetivos, los objetivos genricos (GG), que son comunes a todas
las reas de proceso, y los objetivos especficos (SG), que son definidos por cada rea de
proceso.
Estos objetivos se dividen a su vez en prcticas, que son actividades que se consideran
importantes para alcanzar el objetivo del rea de proceso. Se distinguen tambin dos tipos
de prcticas, las prcticas genricas (GP), que son comunes a todas las reas de proceso, y
las prcticas especficas (SP), que son propias de cada rea de proceso. La Figura 2 muestra
como se estructura un rea de proceso en cuanto a sus objetivos y prcticas.

Fig. 2. Estructura de un rea de proceso

Cuando se est realizando una auditora CMMI, es necesario comprobar que todos los
objetivos de cada rea de proceso definida en el nivel de madurez a evaluar han sido
alcanzados. Para ello, se comprueba que todas las prcticas definidas de cada objetivo han
sido satisfechas5. Si esto es as, la realizacin de cada prctica dejar algn tipo de rastro
(por ejemplo un documento, un acta de reunin, un email, etc.). A estos rastros se les
conoce como indicadores de implementacin de la prctica6 (Practice Implementation
Indicators o PII), que son, por lo tanto, el resultado de la implementacin de una prctica y
que sirven para comprobar que esta implementacin se ha realizado correctamente. Estos
indicadores de implementacin es lo que busca el auditor durante la auditora para
comprobar que se est realizando cada una de las prcticas y que se alcanzar, por lo tanto,
cada uno de los objetivos del rea de proceso correspondiente.
Se distinguen tres tipos de PII:
Artefacto directo: salidas tangibles que resultan de la implementacin directa de
una prctica. Los artefactos directos pueden ser documentos, entregables,
productos, material de formacin, etc. Un ejemplo de un artefacto directo para el
SP 1.2 del proceso de Planificacin del Proyecto, Establecer las estimaciones de
los atributos del producto de trabajo y de las tareas, puede ser un documento con
la estimacin de cierto proyecto resultante de la aplicacin del mtodo de
estimacin por analoga.
Casos especiales en artefactos directos:
En el caso de algunas prcticas, pueden aceptarse documentos como artefactos directos
incluso si estos no tienen el objetivo primario de conseguir la prctica. Por ejemplo, para
la prctica especfica SP 1.2 del proceso de Gestin de Configuracin: Establecer un

Esto es as en la mayora de las auditoras, aunque el modelo deja claro que los objetivos son
obligatorios pero las prcticas son solamente recomendadas.
6 A partir de la versin 1.3 de SCAMPI, los indicadores de implementacin de la prctica pasan
a llamarse evidencias objetivas.

sistema de gestin de la configuracin, puede ser considerado un artefacto directo un

esquema o descripcin del sistema de libreras del gestor de configuracin.
Artefacto indirecto: artefactos que son consecuencia de la implementacin de una
prctica, pero que no son el propsito para el cual se realiza la prctica. Los
artefactos indirectos pueden ser actas de reunin, informes de estado,
presentaciones, correos electrnicos, etc. Un ejemplo de artefacto indirecto para el
SP 1.2 del proceso de Planificacin del Proyecto, Establecer las estimaciones de
los atributos del producto de trabajo y de las tareas, puede ser un informe con las
horas imputadas a la realizacin de la estimacin por analoga del proyecto.
Afirmacin: confirmaciones de palabra (entrevistas) o escritas que corroboran la
implementacin de una prctica especfica o genrica. Ejemplos: entrevistas,
teleconferencias, cuestionarios, etc.
Los PII son utilizados por tanto para demostrar que existe evidencia objetiva de la
implementacin de cada una de las prcticas (ya sean especficas SP- o genricas SG-)
que van a ser evaluadas. Para que exista evidencia objetiva, el mtodo SCAMPI indica que
debe existir un artefacto directo que demuestre el propsito de la prctica y que este a su
vez sea corroborado por artefactos directos o afirmaciones7. Por lo tanto, para comprobar
que existe evidencia objetiva de la implementacin de la prctica, puede utilizarse la
siguiente frmula:
EVIDENCIA OBJETIVA = ARTEFACTO DIRECTO AND (ARTEFACTO
INDIRECTO OR AFIRMACION)
7.1

La PIIDB

Una Base de Datos de Indicadores de Implementacin de la Prctica 8 (Practice

Implementation Indicators DataBase o PIIDB) es una base de datos que almacena
evidencias de la implementacin de las diferentes prcticas (SP y SG) definidas en CMMI.
Las organizaciones pueden proporcionar una PIIDB como entrada a la evaluacin9 (de
hecho es muy recomendable trabajar desde el inicio con una PIIDB, para ordenar el trabajo
7

Para la versin 1.3 se han realizado intentos de simplificacin para la recoleccin de evidencias. A

partir de la versin 1.3, no existirn artefactos directos e indirectos, sino que sern conocidos como
artefactos simplemente. Con ello, simplemente ser necesario centrarse en que existen artefactos que
cumplan con la prctica evaluada. Por su parte, las afirmaciones debern ser ms completas, de manera que
ayuden a entender la prctica. A partir de la versin 1.3, la frmula para comprobar la existencia de una
evidencia es:
EVIDENCIA = ARTEFACTO AND AFIRMACIN
8
9

A partir de la versin 1.3 de SCAMPI, la PIIDB pasa a llamarse Base de Datos de Evidencias Objetivas.
Una PIIDB est compuesta de tantas Descripciones de PII (PII Description o PIID) como prcticas
existan en las reas de proceso que van a ser evaluadas. Una PIID es una estructura que almacena la
informacin necesaria de un PII (por ejemplo su descripcin, el artefacto directo, el artefacto indirecto y
la afirmacin).

y obtener una evaluacin constante). Esta PIIDB mostrar la trazabilidad de las prcticas
del modelo a las reas de proceso correspondientes y a las evidencias objetivas usadas para
verificar la implementacin de la prctica. En la Figura 3 se muestra un extracto de una
PIIDB, en la que se muestran los campos a completar para la prctica 1.4 Determinar
estimaciones de esfuerzo y costes del rea de proceso de planificacin del proyecto (PP).
Para que exista evidencia objetiva de la realizacin de esta prctica, este extracto de la
PIIDB debera contener para cada proyecto un artefacto directo y un artefacto indirecto o
una afirmacin.

Fig. 3. Campos a completar en una PIIDB para una prctica

Tabla 1. La PIIDB de nivel 2 en nmeros

La PIIDB de nivel 2 en nmeros

Por cada rea de proceso (en total son 7) y por cada prctica especfica (SP) y cada
prctica genrica (SG) ser necesario completar un total de entre 6 y 9 indicadores
(PII). La diferencia est en si se presenta solo un artefacto indirecto, solo una
afirmacin o ambos. En ocasiones la misma empresa buscar tener ambos
indicadores para dar mayor fortaleza a la evidencia. La cantidad total de SP y SG es
de 136. La cantidad total de indicadores entonces sern entre 816 y 1224.

Ejemplo de PIIDB

Normalmente, completar una PIIDB es una tarea extensa y que lleva asociados unos
importantes costes internos. Es por ello que se recomienda comenzar a trabajar con
ella cuanto antes, e ir completando progresivamente los indicadores, consiguiendo as
encontrar y comprobar tanto los puntos fuertes del proceso de desarrollo como los
aspectos ms dbiles, en los que deberan centrarse los mayores esfuerzos.
A lo largo de este captulo vamos a detallar ejemplos de artefactos directos e
indirectos para cada una de las prcticas de las reas de proceso de nivel 2. Estas
tablas deben tomarse solo como un ejemplo, por lo que en la implantacin que las
empresas llevan a cabo pueden encontrarse otros artefactos.

8.1

Prcticas genricas de nivel 2

Tabla 2. Prcticas genricas de nivel 2

GP 2.1 Establecer una

poltica de la
organizacin

GP 2.2 Planificar el
proceso

GP 2.3 Proporcionar
recursos

GP 2.4 Asignar
responsabilidad
GP 2.5 Formar al
personal

GP 2.6 Gestionar
configuraciones

ARTEFACTO
DIRECTO
Plan de calidad que
contemple el desarrollo
software, los procesos de
nivel 2 y que se encuentre
firmado y respaldado por la
gerencia.
Documentos
para
planificar cada uno de los
procesos, y que contienen
su
descripcin,
sus
objetivos,
sus
responsabilidades,
sus
dependencias,
las
mediciones a realizar para el
proceso, etc.
Descripcin de
los
equipos
y
recursos
(humanos y materiales)
disponibles
para
la
realizacin del proceso.
Documento de roles y
responsabilidades para cada
proceso.

ARTEFACTO
INDIRECTO
Comunicacin del plan de
calidad a la empresa (correos,
wiki, pgina Web, etc.).

Tareas de formacin
realizadas: temario de los
mismos,
materiales,
objetivos de la realizacin
de la formacin, exmenes,
etc.
Gestor de configuracin
del cdigo fuente (SVN,
CVS, etc.).

Informe de asistencia a los

cursos de formacin por parte
del personal.

Gestor de configuracin
documental
(SharePoint,
wiki, etc.).
Sistemas de copias de
seguridad.

Horas
proyecto.

imputadas

al

Facturas de compra de
equipos o de herramientas.
Horas imputadas a las
tareas de gestin del proyecto.
Actas
de
reunin
convocadas en las que se
nombran los responsables.

Logs que muestren el uso

de cada una de las
herramientas de gestin de
configuracin.

GP 2.7 Identificar e
involucrar a las partes
interesadas relevantes

Plan de comunicacin
establecido en el que se
identifican a los implicados
en el proceso.

Actas de reunin en la que

participan los diferentes
involucrados en el proyecto.
Correos de convocatoria.

GP 2.8 Monitorizar y
controlar el proceso

Informes de medicin
intermedios
de
los
productos software.

Acciones
correctivas
asociadas a las mediciones
del rendimiento de los
procesos. Comunicacin de
los resultados.

Informes de medicin
del rendimiento de los
procesos.
Informes de auditora
interna y externa de los
procesos.

GP 2.9 Evaluar
objetivamente la
adherencia
GP 2.10 Revisar el estado
con el nivel directivo

8.2

Resultado de la reunin
con la direccin para revisar
los
procesos
de
la
organizacin.

Horas imputadas a tareas

de auditora.
Registros de auditora,
contratacin de auditores, etc.
Actas
de
reunin,
convocatorias, calendario de
planificacin, etc.

rea de proceso: Gestin de Acuerdos con Proveedores (SAM)

Tabla 3. rea de proceso: Gestin de Acuerdos con Proveedores (SAM)

ARTEFACTO
ARTEFACTO
DIRECTO
INDIRECTO
SG 1 Establecer los acuerdos con proveedores
SP 1.1 Determinar el
tipo de compra

SP 1.2 Seleccionar los

proveedores

SP 1.3 Establecer los

acuerdos con el
proveedor

Poltica de acuerdos con

proveedores, definiendo los
tipos de compras posibles
(productos
off-the-shelf,
productos a medida, etc.).
Plantilla
de
homologacin
de
proveedores.
Listado de proveedores.
Contrato
con
el
proveedor.

Requisito del proyecto

donde se describe el mdulo a
contratar.

Informe de homologacin.

Acta de reunin donde se

ha realizado el acuerdo.

SG 2 Satisfacer los acuerdos del proveedor

SP 2.1 Realizar el
acuerdo del proveedor

SP 2.2 Monitorizar los

procesos seleccionados
del proveedor

SP 2.3 Evaluar los

productos a medida
seleccionados del
proveedor
SP 2.4 Aceptar los
productos adquiridos
SP 2.5 Transferir los
productos

Informes de cierre de
acuerdos y de progreso del
proveedor.
Informes de seguimiento
del proveedor.
Informes
de
discrepancias.
Listado de productos de
trabajo seleccionados a
evaluar del proveedor e
informes sobre la seleccin.
Procedimiento
y
resultados de pruebas de
aceptacin.
Planes de transicin y
despliegue, gestin del
cambio, paso a produccin,
a pre-produccin, etc.
Informes de formacin
sobre los nuevos productos.

8.3

Incidencias registradas.
Actas de reuniones de
seguimiento.
Horas imputadas a la
monitorizacin de actividades
del proveedor.

Horas imputadas a la
evaluacin de productos de
terceros.
Incidencias
resolucin.

histricas

Horas imputadas por cada

empleado
involucrado
a
actividades de formacin
relacionadas con el producto.
Informe de incidencias
durante el despliegue.

rea de proceso: Gestin de requerimientos (REQM)

Tabla 4. rea de proceso: Gestin de requerimientos (REQM)

ARTEFACTO DIRECTO

ARTEFACTO
INDIRECTO

SG 1 Gestionar los requerimientos

SP 1.1 Obtener una
comprensin de los
requerimientos

SP 1.2 Obtener el
compromiso sobre los

Aplicacin de un listado de
criterios definidos para la
evaluacin y la aceptacin de los
requisitos.
Resultados del anlisis de los
requisitos frente a los criterios
de aceptacin.
Documento de requisitos
aceptado.

Correos
electrnicos o actas
de reunin en los
cuales se evidencia el
entendimiento,
negociacin
o
cambio de requisitos.
Histrico
requisitos

de
cuyo

requerimientos

SP 1.3 Gestionar los

cambios en los requerimientos

Acta de reunin donde se

aceptan los requisitos.
Peticiones
de
cambio
asociadas con requisitos.
Requerimientos versionados.
Tareas para cada peticin de
cambio: trazabilidad de la
peticin de cambio con las
tareas.

SP 1.4 Mantener una

trazabilidad bidireccional de
los requerimientos

SP 1.5 Identificar las

inconsistencias entre el
trabajo del proyecto y los
requerimientos

8.4

Matriz de trazabilidad entre

requisitos y los dems elementos
que componen el producto
software (ej. diseo, casos de
prueba, cdigo fuente, etc.).
Informe de pruebas.
Listado de inconsistencias.

estado pasa a ser

aceptado.
Histrico
de
requisitos
cuyo
estado haya pasado a
abierto tras haber
sido cerrado.
Estimacin de las
tareas asociadas al
cambio
en
un
requisito.
Anlisis
de
cambio donde se ha
utilizado la matriz de
trazabilidad
para
valorar el impacto.
Acciones
correctivas asociadas
a las inconsistencias
encontradas entre el
proyecto
y
los
requisitos.

rea de proceso: Planificacin de Proyecto (PP)

Tabla 5. rea de proceso: Planificacin de Proyecto (PP)

SP 1.1 Estimar el
alcance del proyecto

SP 1.2 Establecer las

estimaciones de los
atributos del producto
de trabajo y de las tareas

ARTEFACTO
ARTEFACTO
DIRECTO
INDIRECTO
SG 1 Establecer estimaciones
Oferta o plan de
Horas imputadas a la tarea
proyecto donde se indican de estimacin del alcance,
el alcance del sistema.
oferta inicial, estudio de
viabilidad, etc.
Descripcin de las tareas
a realizar durante el
proyecto.
Diagrama de Gantt en el
Horas imputadas a la
que se describen la duracin realizacin de la estimacin
de las tareas, en base a una por analoga, punto funcin,
estimacin por analoga.
puntos pker, etc.

Planificacin del sprint

backlog.

SP 1.3 Definir el ciclo

de vida del proyecto

SP 1.4 Determinar las

estimaciones de esfuerzo
y costes

Informe
con
los
resultados de la estimacin.
Una seccin, usualmente
incorporada al plan de
proyecto donde se describen
las fases que contendr el
proyecto (anlisis, diseo,
despliegue,
iteraciones,
etc.), la relacin entre estas
fases y su ordenacin
temporal (cascada, iterativo,
incremental, etc.).
Informe en el que se
representan los resultados
de la estimacin del
esfuerzo necesario y el
mtodo usado.

Hitos definidos en un
diagrama de Gantt.

Horas imputadas a la tarea

de estimacin.
Herramienta de clculo de
esfuerzo y coste completada.

Hoja de costes para el

proyecto y el procedimiento
de clculo.

SP 2.1 Establecer el
presupuesto y el
calendario

SP 2.2 Identificar los

riesgos del proyecto

Definicin de recursos
necesarios
(memoria,
capacidad de red, etc.) para
la realizacin del proyecto.
SG 2 Desarrollar un plan de proyecto
Seccin de presupuesto
Horas imputadas a la tarea
del documento del plan de de
elaboracin
del
Proyecto.
presupuesto y calendario.
Diagrama de PERT en el
que se identifican las
distintas tareas y sus
dependencias.
Matriz
de
riesgos
identificados
para
el
proyecto.
Checklist que evala los
riesgos para el proyecto.

Herramienta de clculo de
esfuerzo y coste completada.

Catlogo
riesgos.

genrico

de

Horas imputadas a la tarea

de identificacin de riesgos.

SP 2.3 Planificar la
gestin de los datos

SP 2.4 Planificar los

recursos del proyecto

Listado de los datos

gestionados en el proyecto,
con la descripcin del
formato, requisitos de
privacidad y seguridad.
Descripcin del sistema
de Backup. Datos que
requieren confidencialidad.
Listado de equipamiento,
instalaciones y software
asociado con el proyecto.

SP 2.5 Planificar el
conocimiento y las
habilidades necesarias

Listado de recursos
humanos necesarios.
Listado de habilidades
necesarias por parte de los
miembros del equipo.

SP 2.6 Planificar la
involucracin de las
partes interesadas

Plan de personal y de
nuevas contrataciones.
Listado
de
los
participantes del proyecto y
rol que juegan en el mismo.

Estructura de carpetas y
permisos para controlar datos
confidenciales.
Logs de backups realizados
para el proyecto.

Orden de
equipamiento.

compra

de

Acta de reunin interna de

arranque.
Actividades de formacin
para los perfiles del proyecto.
Material de formacin.

Comunicacin formal a
las
personas
que
participarn en el proyecto
(cliente,
desarrolladores,
equipo de pruebas, etc.).

SP 2.7 Establecer el
plan de proyecto

SP 3.1 Revisar los

planes que afectan al
proyecto

Plan de comunicacin y
relaciones
entre
los
participantes.
Plan de proyecto.

Acta de reunin de
arranque del proyecto en la
que participan tanto el cliente
como
los
principales
involucrados en el proyecto y
se explica el plan de
comunicacin.

Horas imputadas a la tarea

de planificacin.

Plantilla de plan de
proyecto.
SG 3 Obtener el compromiso con el plan
Matriz de relaciones
Registro de resolucin de
entre
proyectos, conflictos (correo, acta, etc.).
planificacin de proyectos y
recursos asignados en la

unidad organizacional.

SP 3.2 Reconciliar los

niveles de trabajo y de
recursos

SP 3.3 Obtener el
compromiso con el plan

8.5

Documento
con
la
ocupacin de recursos de la
organizacin.
Presupuestos
renegociados. Control de la
asignacin y capacidad de
los recursos

Revisin en herramienta de
gestin de personal y control
de horas, as como el ajuste de
recursos y tareas.

Reestimacin de las
tareas de los implicados que
tengan una dedicacin que
no sea aceptable.
Aceptacin por los
afectados del plan de
proyecto.

Acta de reunin de inicio

del
proyecto
con
la
participacin del equipo.

rea de proceso: Monitorizacin y Control del Proyecto (PMC)

Tabla 6. rea de proceso: Monitorizacin y Control del Proyecto (PMC)

ARTEFACTO
ARTEFACTO
DIRECTO
INDIRECTO
SG 1 Monitorizar el proyecto frente al plan
SP 1.1 Monitorizar los
parmetros de
planificacin del
proyecto

SP 1.2 Monitorizar los

compromisos

SP 1.3 Monitorizar los

riesgos del proyecto

Actas de las reuniones

de seguimiento llevadas a
cabo.
Herramienta
de
seguimiento (por ejemplo
Gantt de seguimiento, Trac,
etc.).
Identificacin
de
desviaciones
en
el
proyecto.
Actas de reunin de
seguimiento, informes de
avance, de cumplimiento
de hitos, etc.
Histrico de cambios en
los riesgos.

Registro de la revisin de
las horas imputadas al
proyecto.

Horas
imputadas
seguimiento del proyecto.

al

Acta de reunin de
seguimiento en la que se tratan
explcitamente los riesgos del

proyecto.

SP 1.4 Monitorizar la
gestin de datos

Identificacin de nuevos
riesgos a lo largo del
proyecto.
Servidor de integracin
continua.

SP 1.5 Monitorizar la
involucracin de las
partes interesadas
SP 1.6 Llevar a cabo
revisiones de progreso

Registro de tareas de
gestin de datos.
Actas de reunin de
entrega
de
hitos
intermedios.
Informes de avance del
seguimiento.

Histrico de revisiones en
gestor de configuracin.
Correos o notificaciones
entre los implicados.

Actas de reunin de
seguimiento.

SP 1.7 Llevar a cabo

revisiones de hitos

Actas de reunin de
entrega
intermedia,
reuniones intermedias de
chequeo con el cliente.

Logs del
backups.

sistema

de

Horas imputadas por parte

del equipo a tareas del
proyecto.
Impedimentos detectados
durante las reuniones de
seguimiento.
Histrico de entregables.
Histrico de incidencias.

Riesgos
del
proyecto
Acta de reunin de final revisados
durante
la
de un Sprint.
realizacin del hito.
SG 2 Gestionar las acciones correctivas hasta su cierre
SP 2.1 Analizar
Incidencias registradas y
Peticiones de cambio
problemas
analizadas.
asociadas.

SP 2.2 Llevar a cabo

las acciones correctivas

SP 2.3 Gestionar las

acciones correctivas

Documento o registro de
acciones correctivas.

Histrico de acciones
correctivas, participantes,
planes derivados, etc.

Planificacin modificada
incluyendo las incidencias y
su estimacin.
Incidencias resueltas.
Histrico de cambios de
estado de las incidencias
Acta de reunin al final del
hito en la que se incluye la
revisin de las incidencias y
las
acciones
correctivas
asociadas.

8.6

rea de Proceso: Gestin de Configuracin (CM)

Tabla 7. rea de Proceso: Gestin de Configuracin (CM)

SP 1.1 Identificar
elementos de
configuracin

SP 1.2 Establecer un
sistema de gestin de la
configuracin

SP 1.3 Crear o liberar

lneas base

SP 2.1 Seguir las

peticiones de cambio
SP 2.2 Controlar los
elementos de
configuracin

ARTEFACTO
ARTEFACTO
DIRECTO
INDIRECTO
SG 1 Establecer lneas base
Documento
o
Tiempo dedicado a su
herramienta donde se elaboracin, horas, actas, etc.
identifican los elementos de
configuracin de las lneas
base. Pueden ser productos
que se entregan al cliente,
herramientas,
diseos,
planes
de
pruebas,
prototipos, resultados de
pruebas, documentos, etc.
Herramienta de gestin
Histrico de revisiones y
de la configuracin (SVN, roles de acceso al sistema de
CVS, etc.).
gestin de la configuracin.
Logs de herramientas de
gestin de configuracin.
Histrico de entregas
formales realizadas.

Descripcin de las
entregas formales a realizar
durante el proyecto, tanto
de productos software
como de documentacin,
describiendo los elementos
que contiene.
SG 2 Seguir y controlar los cambios
Peticiones de cambio
Registro con la aprobacin
realizadas
durante
el o denegacin de un cambio en
proyecto.
el sistema.
Servidor de integracin
Logs de ejecuciones del
continua
que
integra servidor
de
integracin
peridicamente el cdigo continua.
realizado
hasta
ese
momento,
identificando
Registros de auditora
errores o conflictos.
interna o externa.
No
conformidades
identificadas durante las
auditoras
internas
y
externas.

SP 3.1 Establecer
registros de gestin de la
configuracin

SP 3.2 Realizar
auditoras de
configuracin

8.7

SG 3 Establecer la integridad
Revisiones de las tareas
Incidencias en la gestin de
de gestin de configuracin configuracin
(ej.
establecimiento de ramas,
Revisiones
de
los merges que no funcionan).
cambios
implementados
entre dos versiones de la
Histrico de cambios en la
lnea base.
herramienta de gestin de la
configuracin.
Informe de auditora
No
conformidades
interna o externa.
extradas de la realizacin de
la auditora.

rea de proceso: Medicin y Anlisis (MA)

Tabla 8. rea de proceso: Medicin y Anlisis (MA)

ARTEFACTO
ARTEFACTO
DIRECTO
INDIRECTO
SG 1 Alinear las actividades de medicin y anlisis
SP 1.1 Establecer los
Documento con los
Correos de sugerencias de
objetivos de medicin
objetivos de medicin, indicadores.
donde se indican los
objetivos de negocio y su
Histrico de indicadores.
relacin
con
los
indicadores de medicin.
SP 1.2 Especificar las
Descripcin de los
Actas de reunin para la
medidas
indicadores de medicin: definicin de los indicadores.
unidades
de
medida,
mecanismo de recogida,
Histrico de resultados de
periodicidad
de
la las mediciones.
recoleccin, objetivo de la
medicin, etc.
Catlogo genrico de
mtricas.
SP 1.3 Especificar los
Descripcin de los
Procedimiento de medicin
procedimientos de
indicadores de medicin: y anlisis desarrollado.
recogida y de
unidades
de
medida,
almacenamiento de datos mecanismo de recogida,
Logs de las herramientas
etc.
de recoleccin automtica de
datos.
Seccin
en
la
documentacin donde se
indica cmo se almacenan

los datos.
Descripcin de los
Plantilla de los informes de
indicadores de medicin, indicadores.
umbrales y anlisis a
realizar.
SG 2 Proporcionar los resultados de la medicin
SP 2.1 Recoger los
Informe que contenga
Horas imputadas a realizar
datos de la medicin
los datos extrados de la el informe.
medicin.
Logs de las herramientas
de recoleccin automtica de
datos.
SP 2.2 Analizar los
Informe de anlisis de
Acta de reunin de anlisis
datos de la medicin
los datos obtenidos.
de datos.
SP 1.4 Especificar los
procedimientos de
anlisis

SP 2.3
Almacenamiento de datos
y los resultados
SP 2.4 Comunicar los
resultados

BBDD de indicadores,
con los resultados de las
mediciones anteriores y
actuales.
Correo electrnico, acta,
etc. donde se evidencie la
comunicacin
de
los
resultados

Acciones
correctivas
asociadas con el anlisis.
Horas imputadas al anlisis
y almacenamiento de los
resultados.
Contestaciones
a
comunicaciones
de
resultados.

las
los

Acciones
correctivas
identificadas en base a los
resultados.

8.8

rea de proceso: Aseguramiento de la Calidad del Proceso y del Producto

(PPQA)

Tabla 9. rea de proceso: Aseguramiento de la Calidad del Proceso y del Producto (PPQA)

ARTEFACTO DIRECTO

ARTEFACTO INDIRECTO

SG 1 Evaluar objetivamente los procesos y los productos de trabajo

SP 1.1 Evaluar
Plan de calidad donde se
Actas de reunin de
objetivamente los
han registrado las diferentes evaluacin de los procesos.
procesos
auditoras independientes
que se realizarn a los
Horas imputadas a las
proyectos.
auditoras.

Informe de auditora
interna o externa.

SP 1.2 Evaluar
objetivamente los
productos y los servicios

No
conformidades
detectadas
durante
la
auditora.
Informes de pruebas de
los productos y servicios.

Registro de auditora.

Histrico de casos de
prueba.

Informes de auditora
Horas imputadas a las
interna o externa realizada auditoras.
al proyecto.
SG 2 Proporcionar una visin objetiva
SP 2.1 Comunicar y
No
conformidades
Acciones
correctivas
asegurar la resolucin de detectadas
durante
la asociadas
a
las
no
las no-conformidades
auditora comunicadas a los conformidades.
proyectos y asignadas al
responsable
de
la
resolucin.
SP 2.2 Establecer
Plan de calidad e
Horas imputadas a las
registros
informes de auditora.
auditoras.
Almacenamiento de las
no
conformidades
identificadas
en
las
auditoras.

El mtodo de evaluacin

Para que una organizacin pueda alcanzar un cierto nivel de madurez, es necesario que se
implementen las reas de proceso que CMMI define para ese nivel de madurez (ver Figura
4 o Anexo). Para que un rea de proceso sea correctamente implementada, deben
alcanzarse los objetivos definidos para esa rea de proceso, que a su vez se consiguen
mediante la implementacin de las prcticas de cada objetivo (especficas -SP- y genricas GP-).

Fig. 4. Niveles de madurez definidos en CMMI

Cuando se va a evaluar la implementacin de las prcticas se comienza desde abajo hasta
arriba, esto es, evaluando en primer lugar el cumplimiento de las prcticas, posteriormente
los objetivos, luego las reas de proceso y finalmente el nivel de madurez.
9.1

Cumplir con las prcticas genricas (GP) y especficas (SP)

Se ha de comprobar si se cumplen las prcticas definidas para cada una de las reas de
proceso definidas en el nivel de madurez. Para comprobar si se cumplen, SCAMPI define
una escala que determina si se han implementado completamente, parcialmente o no se han
implementado. La escala puede verse en la siguiente tabla:

Tabla 10. Calificacin de las prcticas

Calificacin

Descripcin

Fully Implemented (FI)

Artefactos directos presentes y adecuados

Artefactos indirectos y/o afirmaciones
No se han notado debilidades

Largely Implemented (LI)

Artefactos directos presentes y adecuados

Artefactos indirectos y/o afirmaciones
Se han notado una o ms debilidades

Partially Implemented (PI)

Artefactos directos no encontrados o inadecuados

Artefactos indirectos y/o afirmaciones indican que parte de
la prctica ha sido implementada
Se han notado una o ms debilidades

Artefactos directos presentes y adecuados

No se encuentra otra evidencia que soporte la prctica
Se han notado una o ms debilidades

Not Implemented (NI)

Artefactos directos no encontrados o inadecuados

No se encuentra otra evidencia que soporte la prctica
Se han notado una o ms debilidades

El equipo de auditora ir comprobando cada una de las prcticas de las reas de proceso,
comprobando el estado de implementacin en el que se encuentra cada una de las prcticas.
Para ello, revisa los indicadores de implementacin de la prctica (PII). A cada una de las
prcticas se le dar una calificacin, en funcin de las evidencias encontradas, segn la
Tabla 10. La Figura 5 muestra un ejemplo de calificacin de las prcticas de las rea de
proceso del nivel dos, detallando el Aseguramiento de la calidad de proceso y producto
(PPQA), en funcin de las evidencias que un auditor encontr.

Fig. 5. Evaluacin de las prcticas del rea de proceso PPQA

9.2

Cumplir con los objetivos genricos (GG) y especficos (SG)

Una vez que se han evaluado las prcticas, el equipo de auditora evala los objetivos. Los
objetivos se evalan como satisfechos (satisfied) y no satisfechos (unsatisfied). Para
evaluar si un objetivo ha sido satisfecho, se comprueban sus prcticas. Si todas sus prcticas
se evalan como FI o LI, se considera que el objetivo est satisfecho. Tambin es necesario
tener en cuenta el conjunto total de debilidades. Si la mayora de las prcticas tienen
debilidades, podra considerarse que el objetivo no ha sido satisfecho.
La Figura 6 muestra dos ejemplos de evaluacin del rea de proceso PPQA. En el primero
de ellos, tres objetivos no se encuentran satisfechos debido a que sus prcticas no se
encuentran correctamente implementadas. En el segundo de los casos, todas las prcticas se
han evaluado como correctas, por lo que los objetivos si se encuentran satisfechos.

Fig. 6. Ejemplo de evaluacin de los objetivos del rea de proceso PPQA

9.3

Cumplir con el rea de proceso

Una vez que se han evaluado los objetivos, se evala el rea de proceso. Para que el rea de
proceso se evale satisfactoriamente, todos los objetivos del rea de proceso (tanto
genricos como especficos) han de encontrarse satisfechos.
La Figura 7 muestra dos ejemplos de evaluacin del rea de proceso PPQA. En el primero
de ellos, el rea de proceso no se ha conseguido implementar completamente al no
cumplirse todos los objetivos. Sin embargo, en el segundo el rea de proceso se evala
satisfactoriamente al estar todos los objetivos satisfechos.

Fig. 7. Evaluacin del rea de proceso PPQA

9.4

Cumplir con el nivel de madurez

Por ltimo, para poder determinar el nivel de madurez, es necesario que todas las reas de
proceso definidas en ese nivel de madurez (ver anexo) se encuentren correctamente
implementadas.
La Figura 8 muestra dos ejemplos de la determinacin del nivel de madurez de una
organizacin. En el primero de ellos, no se ha podido alcanzar el nivel 2 de madurez al no
conseguir implementar correctamente todas las reas de proceso definidas en ese nivel de
madurez. En el segundo ejemplo, se obtiene el nivel de madurez 2 al estar correctamente
implementadas todas las reas de proceso correspondientes a ese nivel.10

Fig. 8. Evaluacin del nivel de madurez

Referencias
1.
2.
3.

4.

10

SEI.
CMMI
for
development,
version
1.3.
http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm.
SEI. CMMI: Gua para la integracin de procesos y la mejora de productos.
http://www.sei.cmu.edu/library/abstracts/whitepapers/cmmi-dev-v12-spanish.cfm.
SEI. Standard CMMI appraisal method for process improvement (SCAMPI) A,
version
1.2:
Method
definition
document.
http://www.sei.cmu.edu/library/abstracts/reports/06hb002.cfm.
SEI. Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A,

Se ha excluido el proceso de Gestin de acuerdos con proveedores (SAM), ya que es optativo en

funcin del tipo de organizacin.

5.

Version
1.3:
Method
Definition
http://www.sei.cmu.edu/library/abstracts/reports/11hb001.cfm.
SEI. Published appraisal results. http://sas.sei.cmu.edu/pars/pars.aspx.

Document.

Anexo: Las reas de proceso de CMMI

El modelo CMMI-DEV v1.311 establece 22 reas de proceso, divididas en categoras, para
guiar a las organizaciones en la mejora de sus procesos. Un rea de proceso, tambin
conocido como PA, de sus siglas en ingls Process Area, es un conjunto de prcticas
relacionadas que, cuando se implementan de forma colectiva, satisfacen un conjunto de
objetivos considerados importantes para alcanzar las mejoras en esa rea.
Para que la organizacin alcance un cierto nivel de madurez, ser necesario que cumpla con
todas las prcticas para las reas de procesos que ese nivel defina. Estas reas de proceso a
cumplir para cada nivel estn ya definidas y son las siguientes:
Nivel de madurez 2
Las reas de proceso que se enmarcan en este nivel de madurez son las siguientes:
Gestin de requerimientos (REQM)
Planificacin de proyecto (PP)
Monitorizacin y control del proyecto (PMC)
Gestin de acuerdos con proveedores (SAM)
Gestin de configuracin (CM)
Aseguramiento de la calidad de proceso y producto (PPQA)
Medicin y Anlisis (MA)
El rea de proceso Gestin de acuerdos con proveedores (SAM) slo ha de ser
implementada si las organizaciones externalizan actividades relacionadas con el desarrollo
software a otras empresas.
Nivel de madurez 3
Para alcanzar el nivel de madurez 3, es necesario implementar todas las reas de proceso
relativas al nivel 2, adems de las siguientes reas de proceso:
Desarrollo de requerimientos (RD)
11

Aunque en esta gua se trata principalmente la versin 1.2 del mtodo SCAMPI, los procesos aqu
descritos corresponden a la versin 1.3 de CMMI, en los que apenas hay cambios respecto a la 1.2.

Solucin tcnica (TS)

Integracin de producto (PI)
Verificacin (VER)
Validacin (VAL)
Definicin de procesos de la organizacin (OPD)
Enfoque de procesos de la organizacin (OPF)
Formacin organizativa (OT)
Gestin integrada de proyecto (IPM)
Gestin de riesgos (RSKM)
Anlisis de decisiones y resolucin (DAR)
Nivel de madurez 4
Para alcanzar el nivel de madurez 4, es necesario implementar todas las reas de proceso
relativas al nivel 3 de madurez, adems de las siguientes:
Gestin cuantitativa de proyecto (QPM)
Rendimiento de procesos de la organizacin (OPP)
Nivel de madurez 5
Para alcanzar el nivel 5 de madurez, es necesario implementar todas las reas de proceso
relativas al nivel de madurez 4, adems de las siguientes:
Anlisis causal y resolucin (CAR)
Gestin del rendimiento de la organizacin (OPM)