CMMI DEV

ALUMNO

JESUS ALONSO GAMEZ SANCHEZ

26 SEPTIEMBRE DEL 2015 HERMOSILLO SONORA

1
HISTORIA

CMMI (Capability Maturity Model Integration) es un modelo de madurez de mejora

de los procesos para el desarrollo de productos y de servicios. Consiste en las
mejores prcticas que tratan las actividades de desarrollo y de mantenimiento que
cubren el ciclo de vida del producto, desde la concepcin a la entrega y el
mantenimiento. Esta ltima versin del modelo, presentada en esta obra, integra
los cuerpos del conocimiento que son esenciales para el desarrollo y el
mantenimiento, pero que se han tratado por separado en el pasado, tales como la
ingeniera del software, la ingeniera de sistemas, la ingeniera del hardware y de
diseo, los aspectos no funcionales y la adquisicin. Las denominaciones
anteriores de CMMI para la ingeniera de sistemas y la ingeniera del software
(CMMI-SE/SW) son reemplazadas por el ttulo CMMI para desarrollo, reflejando
as realmente la integracin completa de estos cuerpos de conocimiento y la
aplicacin del modelo en el seno de una organizacin. CMMI para desarrollo
(CMMI-DEV) propone una solucin integrada y completa para las actividades de
desarrollo y de mantenimiento aplicadas a los productos y a los servicios. CMMI
para desarrollo, versin 1.2, es una continuacin y actualizacin de CMMI versin
1.1 y ha sido simplificada gracias al concepto de constelaciones de CMMI,
donde un conjunto de componentes fundamentales puede ser ampliado mediante
material adicional a fin de proponer unos modelos especficos de aplicacin con
elevado contenido comn. CMMI-DEV es la primera de esas constelaciones y
representa al dominio de inters de desarrollo.

Propsito
El propsito de CMMI para desarrollo es ayudar a las organizaciones a mejorar
sus procesos de desarrollo y de mantenimiento, tanto para los productos como
para los servicios. Este libro se basa en CMMI para desarrollo v1.2 que ha sido
producida a partir del Marco de CMMI 1 en agosto de 2006. El Marco de CMMI
soporta el Conjunto de productos de CMMI, permitiendo generar mltiples
modelos, cursos de formacin y mtodos de evaluacin que dan soporte a
dominios de inters especficos. Una constelacin es una coleccin de
componentes de CMMI que incluye un modelo, sus materiales de formacin y los
documentos de evaluacin concernientes a un dominio de inters. Actualmente
hay tres constelaciones planificadas que se sostienen en el marco del modelo de
la v1.2: desarrollo, servicios y adquisicin. Las extensiones se utilizan para
extender las constelaciones mediante contenido especfico adicional. Esta obra
contiene la constelacin CMMI para desarrollo y contiene tanto CMMI-DEV de
base como CMMI-DEV con su grupo de extensiones IPPD (CMMI-DEV+IPPD). Si
no est aplicando IPPD, ignore la informacin que est marcada Extensin IPPD
y as estar utilizando el modelo CMMI para desarrollo.
2
CMMI-DEV 1.2
CMMI (Capability Maturity Model Integration) es un modelo que pueden utilizar las
organizaciones que lo deseen para mejorar todos sus procesos. Este modelo ha
sido creado dentro de Software Engineering Institute que pertenece a la Carnegie
Mellon University.
Actualmente se encuentra la versin 1.2 de CMMI, y dentro de esta versin nos
encontramos tres tipos diferentes de modelos enfocados a diferentes contextos.
CMMI-DEV o (CMMI for Development). Este modelo es el enfocado al desarrollo y
fue liberado en agosto de 2006. En este modelo se tratan procesos referidos a
desarrollo de productos y servicios.
CMMI-ACQ o (CMMI for Acquisition). Este modelo es el enfocado a la adquisicin
y fue liberado en noviembre de 2007. En este modelo se tratan procesos
relacionados con el gobierno y con la industria. Se trata la gestin de la cadena de
suministros, la adquisicin y contratacin externa.
CMMI-SVM o (CMMI for Services). Este modelo es el enfocado a la gestin,
establecimiento y entrega de servicios. Fue liberado en febrero de 2009.

Este modelo lo que nos propone es una serie de prcticas que se tienen que
seguir para mejorar los procesos y ser ms productivos. Estas prcticas estn
asignadas a determinadas reas de proceso los cuales estn dentro de ciertos
niveles de madurez. Para conseguir cada uno de los niveles de CMMI antes hay
que haber cumplido las prcticas de los niveles anteriores.
En la figura siguiente se muestra los diferentes niveles de madurez que tiene
CMMI:

3
0. Incompleto: Este nivel es cuando no se realiza ningn tipo de proceso, o que
no se consiguen sus objetivos.
1. Ejecutado: Toda organizacin que disponga de procesos y logran sus objetivos
estn dentro del nivel 1.
2. Gestionado: Aparte de disponer de procesos, estos son planificados, revisados
y evaluados para comprobar que cumplen los requisitos definidos.
3. Definido: A parte de tener gestionados los procesos, estos se ajustan a la
poltica de procesos marcada por la organizacin.
4. Cuantitativamente gestionado: Los procesos se controlan utilizando tcnicas
cuantitativas.
5. Optimizando: Adems de cumplir todas las condiciones de los niveles que le
preceden, de forma sistemtica se revisa y modifica o cambia para adaptarlo a los
objetivos del negocio.

El modelo CMMI v1.2 contiene las siguientes 22 reas de

proceso:
Anlisis de Causas y Resolucin (CAR)
Gestin de la configuracin (CM)
Anlisis de Decisiones y Resolucin (DAR)
Gestin Integrada de Proyectos (IPM)
Medicin y Anlisis (MA)
Innovacin y Despliegue Organizacionales(OID)
Definicin de procesos organizacionales (OPD)
Enfoque Organizacional en Procesos (OPF)
Rendimiento de Procesos Organizacionales (OPP)
Formacin Organizacional (OT)
Monitorizacin y Control de Proyecto (PMC)
Planificacin de proyecto (PP)
Aseguramiento de calidad de Procesos y Productos (PPQA)
Integracin de Producto (PI)
Gestin Cuantitativa de Proyectos (QPM)
Gestin de Requerimientos (REQM)
Desarrollo de Requerimientos (RD)
Gestin de Riesgos (RSKM)
Gestin de Acuerdos con Proveedores (SAM)
Solucin Tcnica (TS)

4
Validacin (VAL)
Verificacin (VER)

5
6
Tambin hay otra visin del modelo en donde se agrupan en categoras. Con esto
lo que se pretende es ir avanzando en la mejora de la organizacin en las
categoras que ms inters tengamos. A continuacin se muestra la estructura
que tendra esta visin:
Figura 6: Desglose reas de proceso Vs categoras CMMI
El funcionamiento de CMMI consiste en que sin importar la vista que utilicemos
(por niveles o por categoras) cada una de las reas hay que desarrollarlas. Para
ello existen para cada una de las reas de proceso unos objetivos especficos que
se realizarn cumpliendo una serie de prcticas especficas, y tambin unos
objetivos genricos donde se tocan temas como el compromiso, capacidades,
direccin o la verificacin y que se cumplirn realizando una serie de prcticas
genricas. En la figura siguiente se ilustra el ejemplo de la visin de niveles de
madurez.

7
En la figura anterior se aprecia que hay dos clases de objetivos, ahora a
continuacin se analizarn:

Objetivo genrico: son los objetivos que la organizacin debe alcanzar en el nivel
de capacidad donde est.
Objetivo especfico: estos objetivos se aplican a una nica rea de proceso y son
los que una organizacin debe cumplir para satisfacer el propsito del rea de
proceso.

Por otro lado tenemos la diferencia entre prcticas especficas y prcticas

genricas que a continuacin se analizan:
Prcticas genricas: estas prcticas pueden aplicarse a cualquier rea de proceso
y sirven para mejorar el funcionamiento de cualquier proceso. Con ellas se
cumplen los objetivos genricos.
Prcticas especficas: son actividades que son las encargadas de cumplir los
objetivos especficos.

Las organizaciones desean medir el cumplimiento de los requisitos definidos en

CMMI y ganar una clasificacin del nivel de madurez en el que estn. Esta
evaluacin la pueden utilizar para informar a sus clientes o proveedores acerca de
cmo gestionan los procesos internos de la organizacin.

8
El mtodo Standard CMMI Appraisal Method for Process Improvement (SCAMPI)
sirve para evaluar el cumplimiento de los requisitos de CMMI. Hay diferentes
clases de evaluaciones, pero la ms formal y la nica que puede resultar en una
clasificacin de nivel es la A.

CMMI-DEV 1.2 (NIVEL 2)

Todas las empresas por el mero hecho de existir tienen el nivel 1 de CMMI. Este
nivel es el que la organizacin tiene procesos y cumple objetivos. Pero las
organizaciones que desean mejorar la forma de trabajar, es decir, sus procesos,
deben avanzar al nivel 2 de CMMI.

El tiempo estimado de implantacin del nivel 2 suele ser de 12-24 meses

dependiendo de la aceptacin que tenga y del apoyo de la direccin. Como es un
cambio radical en la forma de trabajar de la empresa se necesita estar respaldado
por la direccin de la organizacin para que no se queden las cosas sin realizarse
del todo. Normalmente este es el nivel que cuesta ms implantar, ya que el resto
son pequeas mejoras de lo que ya se tiene.

Cuando la organizacin obtenga el nivel de madurez dos nos encontraremos ante

una organizacin con una disciplina para la gestin de proyectos, gestiona
correctamente los recursos, tendr polticas organizativas que sern
monitorizadas, habr visibilidad de las actividades realizadas y los proyectos se
guiarn por un plan de proyecto donde se especificar como ha de ser.

El nivel 2 es el nivel que pondr las bases para los futuros niveles de CMMI, ser
el encargado de crear un cierto orden dentro de los proyectos para que luego en
el nivel 3 se ordene la organizacin como tal.

Por tanto los objetivos ms importantes que tiene CMMI para este nivel son:
Los proyectos se gestionan de acuerdo a planes de proyecto.
Hay una visibilidad del trabajo que se est realizando.
Se gestionan los compromisos que se han de establecer con todas las personas
involucradas en el proyecto.

reas de proceso del Nivel 2 de CMM-CMMI

Siete son las reas de proceso dentro del nivel 2, estas son:
Gestin de Requisitos
Planificacin de proyectos
Seguimiento y Control de proyectos
Medicin y Anlisis
Gestin de acuerdos con proveedores
Gestin de la configuracin
Aseguramiento de la Calidad de Productos y Procesos

9
(REQM) Gestin de Requisitos
En REQM lo que se pretende es tener un control sobre los requisitos. Estos
requisitos deben estar a parte de bien identificados, comprensibles para todas las
partes interesadas que tengan relacin con los requisitos. Tambin estos
requisitos sern entrada de otras reas de proceso.
Otra de las cosas que las prcticas de esta rea de proceso pretenden mejorar es
el hecho de que los cambios efectuados sobre los requisitos sean controlados y
que no afecten a la integridad de lo ya definido.
Por otra parte el tema de la trazabilidad tambin es tratado en esta rea de
proceso. En cualquier momento se debe saber los requisitos de donde provienen
y la relacin entre requisitos de alto y bajo nivel.
Objetivo de REQM: Los requisitos son administrados, y se identifican las
inconsistencias entre los requisitos y los planes y otros artefactos del proyecto.
Prcticas Especficas:
SP 1.1 Comprender el significado de los requisitos
SP 1.2 Obtener compromiso de los participantes / interesados acerca de los
requisitos
SP 1.3 Administrar cambios a los requisitos
SP 1.4 Mantener la trazabilidad bidireccional de los requisitos
SP 1.5 Identificar inconsistencias entre los requisitos y otros productos del
proyecto

(PP) Planificacin de proyectos

Esta rea de proceso lo que hace es establecer un orden dentro de los proyectos.
Para establecer este orden lo que se tiene es un plan desarrollado con base a los
requisitos de REQM.
Dentro de este plan habr estimaciones del proyecto para saber cunto va a
costar, que va a necesitar y cundo se aleja de lo fijado, se definir el ciclo de
vida para establecer en cada etapa lo que hay que hacer, se identificarn riesgos
que puedan provocar retrasos en el proyecto y obtener el compromiso de todos
los participantes entre otras cosas.
Este orden no es algo fijo que se realiza una vez y ya no se modifica. Este plan de
proyecto debe ser algo que vaya evolucionando con el paso del tiempo
adaptndose al contexto de cada momento realizando las modificaciones que
sean oportunas.
Objetivos de PP: Se realizan y mantienen estimaciones de las magnitudes del
proyecto, Se establece y mantiene un plan de proyecto que es empleado para
administrar el proyecto, y Los compromisos con el plan estn formalmente
establecidos y son mantenidos a lo largo del proyecto.
Prcticas Especficas:
SP 1.1 Estimar el alcance del proyecto
SP 1.2 Estimar atributos de las tareas y de los productos del proyecto

10
SP 1.3 Definir el ciclo de vida del proyecto
SP 1.4 Estimar esfuerzo y costo del proyecto
SP 2.1 Establecer el cronograma y el presupuesto del proyecto
SP 2.2 Identificar los riesgos del proyecto
SP 2.3 Planificar la administracin de datos del proyecto
SP 2.4 Planificar recursos necesarios para el proyecto
SP 2.5 Planificar la adquisicin de conocimiento y habilidades
SP 2.6 Planificar la participacin de los interesados en el proyecto
SP 2.7 Establecer el plan del proyecto
SP 3.1 Revisar todos los planes que puedan afectar al proyecto
SP 3.2 Ajustar el plan de proyecto para reflejar recursos estimados vs. disponibles
SP 3.3 Obtener compromisos respecto al plan

(PMC) Monitorizacin y Control de proyectos

La idea de esta rea de proceso ser la de controlar el plan de proyecto mediante
monitorizacin. Para ello se deber controlar las horas de trabajo, tener informes
de avance, revisiones en algunos puntos, etc.
Con estas monitorizaciones luego se podr tomar acciones correctivas si se ve
que el trabajo se desva demasiado del plan a seguir. El beneficio que nos
proporciona esta rea de proceso es la de anticiparnos a los problemas. No es lo
mismo darse cuenta que el proyecto se ha desviado del plan a seguir al final
donde cuesta siempre ms cualquier cambio que conforme se est realizando el
trabajo detectarlo y ajustar lo necesario para que vuelva al plan.
Objetivos de PMC: El avance y la performance del proyecto se monitorean
respecto a lo establecido en el plan de proyecto y Cuando los resultados o la
performance del proyecto se desvan significativamente del plan se gestionan
acciones correctivas.
Prcticas Especficas:
SP 1.1 Monitorear los parmetros de planificacin del proyecto
SP 1.2 Monitorear los compromisos
SP 1.3 Monitorear los riesgos del proyecto
SP 1.4 Monitorear la administracin de datos del proyecto
SP 1.5 Monitorear la participacin de los interesados
SP 1.6 Conducir revisiones de avance
SP 1.7 Conducir revisiones de cumplimientos de hitos
SP 2.1 Analizar temas pendientes
SP 2.2 Ejecutar acciones correctivas
SP 2.3 Administrar acciones correctivas

(MA) Medicin y Anlisis

Para poder mejorar en algo, ese algo debe de ser medible para poder desde un
estado pasar a otro donde se mejore. Esta rea de proceso lo que pretende es
desarrollar una capacidad de medicin con la que se pueda ayudar a obtener las
necesidades de informacin requeridas.

11
Los datos deben tener relacin con los objetivos de la organizacin para que la
informacin que se saque de ellos sea til.
Lo que se har en esta rea es indicar procedimientos para la recogida de datos,
para su almacenamiento y para su modificacin en informacin til.
Estas mediciones pueden agruparse en dos grupos diferentes: por un lado los
empleados para monitorear los proyectos (lneas de cdigo, horas invertidas, etc.)
y otros ms generales (proyectos finalizados a tiempo, promedio de retraso, etc.).
Objetivos de MA: Las actividades de medicin y anlisis estn alineadas con los
objetivos y necesidades de informacin. y Se proveen mediciones que
satisfacen necesidades y objetivos de informacin.
Prcticas Especficas:
SP 1.1 Establecer objetivos de las mediciones
SP 1.2 Especificar mtricas
SP 1.3 Especificar procedimientos de recoleccin y almacenamiento de datos
SP 1.4 Especificar procedimientos de anlisis
SP 2.1 Recolectar datos
SP 2.2 Analizar datos
SP 2.3 Almacenar datos y resultados
SP 2.4 Comunicar resultados

(PPQA) Aseguramiento de la Calidad de Productos y Procesos

Lo que esta rea de proceso pretende es asegurarse que se cumplen los
estndares y los procesos que se han establecido. Para ello debern ser
evaluados de una forma objetiva, preferiblemente por personas ajenas a los
productores y que determinarn si se estn cumpliendo los estndares y los
procedimientos. En caso de no cumplirse algo se notificar a las personas
correspondientes para subsanar el problema. La diferencia entre el rea de
proceso de validacin del nivel tres de madurez, con respecto a esta rea de
proceso es que a diferencia de la de validacin que comprueba si se cumplen los
requisitos PPQA lo que hace es simplemente comprobar si se cumplen los
estndares y procesos.
Objetivos de PPQA: Se evala objetivamente la adhesin de los procesos y
artefactos a los estndares y descripciones de proceso vigentes y El no
cumplimiento de los estndares y descripciones de proceso es objetivamente
comunicado y su resolucin asegurada.
Prcticas Especficas:
SP 1.1 Evaluar procesos objetivamente
SP 1.2 Evaluar productos y servicios objetivamente
SP 2.1 Comunicar y asegurar la resolucin de cuestiones de calidad
SP 2.2 Establecer y mantener registros de las actividades de aseguramiento de la
calidad

12
(CM) Gestin de la Configuracin
Esta rea de proceso lo que pretende es mantener un control sobre todos los
elementos que componen el proyecto, sean entregables o no. Para ello
mantendr la integridad de todos los elementos del proyecto.
Dentro de todas las reas de proceso del nivel 2 de CMMI est tal vez sea la ms
compleja dado que a las empresas les suele costar organizarse en cuanto a tener
controladas las versiones de lo que estn realizando.
Objetivos de CM: Se establecen lneas base de los artefactos puestos bajo
administracin de la configuracin. y Los cambios a los artefactos son
monitoreados y controlados.
Prcticas Especficas:
SP 1.1 Identificar tems de configuracin
SP 1.2 Establecer un sistema de administracin de la configuracin
SP 1.3 Crear o liberar lneas base
SP 2.1 Monitorear pedidos de cambio
SP 2.2 Controlar tems de configuracin
SP 3.1 Establecer la configuracin de gestin de registros
SP 3.2 Realizar auditoras de revisin

(SAM) Gestin de Acuerdos con Proveedores

SAM lo que pretende es controlar todo lo relacionado con los proveedores. Se
tendr un control de cules son los proveedores que tenemos a nuestra
disposicin y que nos ofrecen, teniendo tambin constancia de sus caractersticas
para una posterior decisin de cul elegir.
Tambin segn el producto de los proveedores se suelen controlar sus procesos
para asegurar los plazos de entrega y las caractersticas del producto adquirido.
Hay que destacar que no todos los proveedores son agentes externos a la
empresa. Puede darse la situacin que los productos para un proyecto sean el
resultado de otros proyectos de la empresa, por lo que habr que tratarlos como
proveedores para formalizar acuerdos.
Objetivos de SAM: Se establecen y mantienen acuerdos con proveedores y Los
acuerdos con los proveedores son satisfechos por el proyecto y por los
proveedores.
Prcticas Especficas:
SP 1.1 Determinar tipo de adquisicin
SP 1.2 Seleccionar proveedores
SP 1.3 Establecer acuerdos con proveedores
SP 2.1 Ejecutar acuerdos con proveedores
SP 2.2 Monitor de procesos de Seleccin de Proveedores
SP 2.3 Evaluar los Work Produts del proveedor seleccionados
SP 2.4 Aceptar el producto adquirido
SP 2.5 Transicin de productos

13
Implantacin del modelo en la empresa
En este apartado se detalla para cada uno de las reas de proceso de CMMI-
DEV2 las mejoras a seguir para cumplir la norma.
Para la implantacin de CMMI-DEV2 dentro de una empresa la metodologa a
seguir sera primero de todo conocer el estado inicial de la empresa respecto a las
normas de CMMI para posteriormente en base a los resultados obtenidos definir
las mejoras necesarias que hay que tomar. Para obtener dicho estado inicial se
realiza un cuestionario para cada una de las reas de proceso de CMMI, en estos
cuestionarios (que se encuentran en el apndice) se formulan preguntas que hay
que contestar si se realiza lo que especifica la pregunta o no. En caso de
necesitar alguna aclaracin habr un apartado de comentarios para tener en
cuenta algo respecto a la respuesta de la pregunta. En general las preguntas que
tengan como respuesta NO, sern las que tendrn que tener una propuesta para
convertirla en un SI y as cumplir la norma. Tambin puede ocurrir que algunas
contestaciones SI, tengan como comentarios algo que aunque en general la
respuesta es afirmativa hay cosas que podran mejorar.
A continuacin en el grfico siguiente se refleja el estado de los cuestionarios de
cada una de las reas de proceso indicando las cuestiones que se respondieron
afirmativamente y las que se respondieron negativamente.

Resultados cuestionarios CMMI

14
Analizando la grfica podemos ver como abundan ms las respuestas negativas
que las afirmativas. En los casos de REQM, PMC, SAM y sobretodo PPQA hay
que mejorar mucho porque la mayora de las respuestas fueron negativas. Por el
contrario MA, CM y PP las respuestas mayoritarias fueron las afirmativas o en el
caso de CM iguales que las negativas, por lo que aqu se parte con cierto nivel
que hay que mejorar. En terminos generales tenemos que la inmensa mayora de
todas las cuestiones han sido respondida negativamente por lo que hay mucho
trabajo que realizar de cara a cumplir las normas de CMMI-DEV2.
En la grfica siguiente se muestra la comparacin entre respuestas afirmativas y
negativas totales de los cuestionarios:

Relacin respuestas SI / NO de los cuestionarios

Y por ltimo se muestra en las dos siguientes grficas la realacin de respuestas
afirmativas con respecto a cada una de las reas de proceso y de igual modo con
las respuestas negativas.

15
Relacin respuestas SI de las reas de proceso

16
Relacin respuestas NO de las reas de proceso
Proposiciones de mejora con respecto a las Prcticas Genricas (Nivel 2)
El cuestionario de estado inicial de las prcticas genricas de nivel 2 consta de 18
preguntas, las cuales han tenido una respuesta afirmativa 11 y negativa 7, por lo
que la tasa de cumplimiento es del 61%.

Relacin respuestas SI / NO de las Generic Goals

A continuacin se detallan las preguntas contestadas negativamente:
(1)GP2.1: Se definen de antemano las expectativas de la organizacin en
todos los procesos y se hacen visibles a los involucrados? (MEJORA)

Es importante definir las expectativas de la organizacin en cuanto a los

procesos. Estas expectativas deben ser visibles a aquellos procesos en la
organizacin que vayan a verse afectados. Normalmente, el encargado de la
gestin es la persona responsable de comunicar y establecer estas
especificaciones.

17
 (2)GP2.2: Se define un plan para los procesos con la descripcin del proceso;
normas y requisitos para los trabajos y servicios del proceso; objetivos especficos
para la realizacin del proceso; dependencias entre trabajos, servicios y recursos;
recursos necesarios; asignacin de responsabilidades, formacin necesaria;
productos del trabajo y su nivel de control; mtricas para proporcionar detalles
sobre el rendimiento del proceso; participacin de los interesados; actividades de
supervisin del proceso; revisin de objetivos de las actividades del proceso;
evaluacin de la gestin de las actividades del proceso y los Work Products?
(REALIZACIN)

Antes que nada hay que especificar los procesos que van a haber y que estos
estn consensuados con las partes implicadas.
Para esto se tendr que realizar un documento independiente, donde se
describirn los procesos, normas y procedimientos.
Este documento que puede ser impreso o guardarse en formato digital debe tratar
los siguientes puntos:
Descripcin del proceso.
Normas y requisitos para los Work Products y servicios del proceso.
Objetivos especficos para el desempeo del proceso (por ejemplo, la calidad, la
escala de tiempo, tiempo de ciclo, y la utilizacin de recursos).
Dependencias entre las actividades, Work Products, y servicios del proceso.
Recursos (incluida la financiacin, la gente, y herramientas) necesarios para
realizar el proceso.
Asignacin de responsabilidades y autoridad.
Formacin necesaria para la realizacin y el apoyo al proceso.
Work Products para ser controlados y el nivel de control que deben aplicarse.
Requisitos de mtricas para proporcionar ms detalles sobre el rendimiento del
proceso, los Work Products, y sus servicios.
Participacin de los interesados.
Actividades de vigilancia y control del proceso.
Evaluacin de objetivos de las actividades del proceso.
Examen de la gestin de actividades para el proceso y Work Products

Este plan podr ser revisado cuando sea necesario y efectuar cambios sobre l.

18
 (4)GP2.4: Se asignan para cada proceso responsable para realizar el proceso
y que archiven los resultados especficos? Esto se guardar o bien con una
descripcin detallada de los puestos de trabajo o bien en un documento vivo
como el plan de proceso. (MEJORA)

Hay que garantizar que exista cierta responsabilidad para realizar los procesos y
archivar los resultados durante toda la vida del proceso. Por esto hay que detallar
las personas que sern responsables de cada parte del proceso y asignarles
autoridad competente.
Estas asignaciones de responsabilidad pueden o bien detallarse en las
descripciones de los puestos de trabajo o bien puede utilizarse otro tipo de
documentos como el plan de proceso.
A parte de una asignacin esttica de las responsabilidades, tambin puede
ocurrir una estrategia de asignacin dinmica de responsabilidades, donde van
cambiando las personas responsables de ciertas partes. Para esto es necesario
que esta cesin de responsabilidades y la aceptacin de las mismas estn
garantizadas durante todo el proceso.
(5)GP2.4: Se asignan responsables generales para los procesos, y
responsables para cosas especficas del proceso adems de que todos ellos lo
entienden todo y lo aceptan? (MEJORA)

Es necesario disponer de un responsable general para cada uno de los procesos

que controle al resto. A parte del responsable general existirn responsables para
cosas especficas dentro del proceso.
Todas estas responsabilidades debern estar aceptadas por la persona que las
asume y deber entender su papel con dichas responsabilidades.
(7)GP2.5: Se da una formacin por encima a las personas que interactan con
el proceso? (REALIZACIN)

Las personas dentro de un proceso deben disponer de la formacin adecuada

para realizar sus trabajos, pero es igual de importante que las personas
relacionadas con los procesos lo conozcan y dispongan de un nivel bsico de
conocimientos sobre el tema con tal de entenderlo y saber interactuar con el
proceso de la mejor forma posible. Esta formacin debe ser superficial y para
orientar en la interaccin con el proceso. 36

19
La formacin apoya el xito de la ejecucin del proceso mediante el
establecimiento de un entendimiento comn del proceso y de impartir las
habilidades y los conocimientos necesarios para llevar a cabo el proceso.
(8)GP2.6: Se tiene un control de versiones con los cambios realizados de los
productos del proceso? (MEJORA)

Es recomendable disponer de un control de versiones de los Work Products de

los procesos de una forma bien controlada para as poder actuar ante posibles
complicaciones al poder disponer de una versin anterior del producto.
Son copias de seguridad pero aadiendo informacin de contexto para saber el
estado en que est el Work Product.
Para los Work Products existen diferentes niveles de control que pueden aplicarse
en distintos momentos en el tiempo. En algunos casos puede ser suficiente un
control de versiones. Este control de versiones suele estar controlado
exclusivamente por el propietario del Work Product. En ocasiones puede ser
necesario que algn Work Product sea colocado bajo una gestin de
configuracin (rea de proceso CM de CMMI). Este tipo de control incluye
definicin y establecimiento de lneas base.
(17)GP2.9: Se evala el cumplimiento del proceso por personal interno de la
empresa pero ajeno al proceso o proyecto, o bien por personal externo a la
empresa? (REALIZACIN)

Como pasa en las auditoras para comprobar la calidad de los procesos se

necesita de un equipo objetivo para llevar tales observaciones. En el caso de
comprobar que se ejecutan los procesos de la forma adecuada se necesita de
personal externo a la empresa o bien objetiva para realizarla correctamente. Este
control supervisar el proceso da a da para detectar posibles anomalas y poder
posteriormente tomar acciones correctivas para combatir los problemas.
Para esta tarea se medir el rendimiento obtenido con respecto al rendimiento
estimado en el plan valorando de igual modo los logros obtenidos.
Cuando se identifiquen posibles problemas que hagan que el proceso se desvi
del plan del proceso se tomarn las medidas oportunas y posteriormente se har
un seguimiento de estas medidas a lo largo del tiempo para comprobar que hacen
el efecto deseado. 37

20
Proposiciones de mejora con respecto a las Prcticas Especficas REQM
El cuestionario de estado inicial de las prcticas especficas REQM consta de 14
preguntas, las cuales han tenido una respuesta afirmativa 3 y negativa 11, por lo
que la tasa de cumplimiento es del 21%.
Grficamente la proporcin entre respuestas afirmativas y negativas quedara de
la siguiente forma:
Relacin respuestas SI / NO de REQM

A continuacin se detallan las preguntas contestadas negativamente:

(2)SP1.1: Se han establecido criterios objetivos para la evaluacin y
aceptacin de los requisitos (ej.: clara y adecuadamente definido, completo,
consistente con otros requisitos, identificado unvocamente, implementable
adecuadamente, testeable, trazable)? (REALIZACIN)

La falta de evaluacin y de criterios de aceptacin a menudo da lugar a la

insuficiencia de la verificacin, una revisin costosa, o el rechazo del cliente. Para
ello es adecuado tener una serie de criterios por los que aceptaremos los
requisitos. No hay necesidad de documentarlo de una forma formal, pero s es
conveniente acordarlo con anterioridad de algn modo.
Como ejemplos de evaluacin y criterios de aceptacin para los requisitos
podemos encontrar los siguientes:
Claro y debidamente definido
Completo
Consistente con los dems requisitos
Identificado unvocamente
Apropiado para implementar
Verificable (testeable)
Trazable

21
 (3)SP1.1: Se analizan los requisitos para garantizar que se cumplen los
criterios de aceptacin establecidos? (REALIZACIN)

De poco sirve tener unos criterios de evaluacin y aceptacin si despus no se

usan. Al recibir nuevos requisitos estos deben ser revisados viendo si cumplen o
no con los criterios identificados con anterioridad. De no cumplirlos se notificar a
los responsables de los requisitos para que tomen las medidas oportunas y lo
reescriban adaptndose a los criterios preestablecidos, o tambin pueden
aceptarse teniendo en cuenta los problemas que ocasionarn al no cumplir los
criterios establecidos.

(6)SP1.2: Se evala el impacto de los requisitos (y de los cambios a

requisitos) sobre los compromisos ya existentes? (MEJORA)

Cada vez que haya un cambio en algn requisito o bien cuando se va a iniciar un
nuevo requisito se debe evaluar el impacto que tendr sobre los compromisos ya
existentes junto con los participantes del proyecto para intentar detectar posibles
problemas futuros por falta de tiempo, inconsistencia con lo que ya hay u otros
problemas.

(8)SP1.3: Se registran las peticiones de cambio a los requisitos (fuente, razn,

versin a la que afecta,...)? (REALIZACIN)

Para tener un cierto control sobre los cambios en los requisitos y saber en todo
momento que se est haciendo hay que tener un documento donde se registren
dichos cambios. Para ello tenemos por ejemplo la plantilla Plantilla Registro de
requisitos del cliente (Apndice 9.9). Este documento pretende servir para el
seguimiento y control de los distintos requisitos que se aaden o modifican en un
proyecto, por parte del cliente. En ella se listan los distintos requisitos con su
origen, fecha, tipo de requisito, etc. Las caractersticas que se reflejen en esta
tabla pueden modificarse dependiendo de las necesidades.
Dicho documento constar de dos partes que ahora comentaremos. La primera
de ellas es donde registraremos un resumen de los requisitos mediante una tabla
con las siguientes columnas: fecha (en que ha sido modificado o recibido), origen
(informacin sobre el origen del requisito), requisitos del cliente, tipo de requisito,
comentarios, accin (lo que se va a hacer al respecto). La segunda parte es
donde introduciremos todos los supuestos que se hayan hecho a la hora de
guardar los requisitos del cliente.

22
 (9)SP1.3: Se ha establecido claramente quin es el responsable de
aprobar/rechazar una peticin de cambio a un requisito?; se han definido
criterios de escalado para tomar esta decisin? (MEJORA)

Hay que dejar claro quin ser el responsable que aceptar o rechazar los
cambios de peticin teniendo en cuenta el impacto sobre el estado actual del
proyecto o por criterios de aceptacin. Dicho responsable se puede definir dentro
de la plantilla Plantilla Plan de gestin de requisitos (Apndice 9.10) en el
apartado de roles. En dicho apartado se puede definir un rol que se encargue de
esto y asignarle uno o varios responsables. As siempre que entren nuevos
requisitos debern pasar por dichas personas que analizarn convenientemente
todas las partes implicadas. Una aceptacin / rechazo de requisitos sin control
puede ocasionar problemas de incoherencias con otros requisitos o problemas
futuros por no haberlos analizado con anterioridad.

(10)SP1.3: Se controla el estado de los requisitos?; existen atributos que

indiquen el estado actual de cada requisito? (REALIZACIN)

Es recomendable tener constancia mediante un documento del estado de los

requisitos en cualquier momento. Dicho documento debera de estar accesible a
todo el proyecto durante todo el ciclo de vida del producto. Suponiendo que se
tienen definidos todos los requisitos con un identificador nico que los identifica
inequvocamente se necesitara solamente una tabla con una columna para poner
el identificador o identificador y nombre del requisito, y otra columna donde se
pondra el estado en el que se encuentra. Los posibles estados lgicamente
deben de estar acotados y tener una leyenda con su explicacin para que no
exista ningn tipo de duda al respecto. Una posibilidad podra ser (Pendiente de
Aceptacin, No empezado, Iniciado, Pausado, Finalizado), pero es algo
que se puede adaptar al modo de trabajar fcilmente.
Este documento se puede tener por separado o bien integrarlo dentro del
documento Plantilla Registro de requisitos del cliente (Apndice 9.9) aadiendo
en este un nuevo apartado (el 1.3 Estado de los requisitos) donde se especificara
el estado de los requisitos.

(11)SP1.3: Se revisan el plan de proyecto y los Work Products relacionados

con los requisitos para asegurar que existe consistencia con los requisitos y los
cambios realizados en ellos? (REALIZACIN)

En cada cambio de un requisito o cuando se introduce alguno nuevo hay que

evaluar las posibles consecuencias que pueden derivar. Una de las cosas
importantes es ver el efecto sobre los Work Products ya existentes viendo si
produce alguna inconsistencia o problema.

23
Es mejor encontrar problemas sobre los Work Products existentes antes de
desarrollarlos y evitar el trabajo en vano o posibles problemas de volver a
versiones anteriores para corregir las modificaciones no deseadas.
(12)SP1.3: Existen Procesos, Procedimientos, Plantillas, Herramientas para
Gestin de Requisitos? La utilizan los proyectos? (MEJORA)

Por ltimo es recomendable tener un documento donde se especifique como se

van a recoger los requisitos, como se van a tratar, validar, gestionar cambios,
asignar roles. Para tal efecto disponemos de la plantilla Plan de Gestin de

(13)SP1.4: Se tiene una trazabilidad (ej.: matriz de trazabilidad) desde los

requisitos fuente hacia sus derivadas y a la inversa? (REALIZACIN)

24
Una buena forma de tener controlados todos los requisitos y saber los requisitos
de bajo nivel de donde proceden es disponer de una matriz de trazabilidad entre
los requisitos de alto nivel y sus respectivos requisitos de bajo nivel de los que se
compone. Un requisito de alto nivel, segn de lo que se trate puede desglosarse
en pequeos trozos de menor nivel y que pueden abordarse por separado. Como
ejemplo tenemos la matriz de trazabilidad en (Apndice 9.13) donde en horizontal
tenemos los requisitos de alto nivel y en vertical tenemos el conjunto de requisitos
de bajo nivel que son derivados de los de alto nivel. En todo momento en este
caso podemos fijarnos en un requisito de alto nivel y visualizar sus requisitos
derivados de un golpe de vista. De igual modo, se puede hacer a la inversa, se
puede saber el requisito de alto nivel del cual deriva un requisito de bajo nivel.
Para sealar que un requisito derivado Y (vertical) se corresponde con uno de alto
nivel Z (horizontal) se indicar con una X en la celda donde se cruza la fila del
requisito derivado con la columna del requisito de alto nivel de la tabla de
trazabilidad.
(13)SP1.4: Se tiene una trazabilidad (ej.: matriz de trazabilidad) entre los
requisitos y su relacin con objetos, personas, interfaces, procesos, Work
Products y funciones? (REALIZACIN)

Para saber en todo momento la relacin de los requisitos con respecto a lo que le
rodea es conveniente disponer de una matriz de trazabilidad entre requisitos y
objetos, personas, interfaces, procesos, Work Products o funciones. Cabe resaltar
que no es necesario tener en la misma tabla todos estos elementos. Es ms
recomendable tener una matriz de trazabilidad individual entre los requisitos y el
elemento en cuestin que tenerlo todo junto. As se puede prescindir de alguna
matriz no necesaria. Con esta matriz de trazabilidad podemos tanto navegar
desde el requisito hasta los elementos con los que est relacionado, como al
contrario saber un elemento en concreto con que requisito est relacionado. Estas
matrices son una herramienta muy potente y til para la identificacin de
elementos. Esta matriz tendr en horizontal los requisitos y en vertical los
elementos relacionados. Para marcar que un elemento est relacionado con un
requisito se indicar con una X en la celda en la que se cruzan la fila del
elemento y la columna del requisito. Como ejemplo de este tipo de matriz nos
encontramos con la del (Apndice 9.14), en donde los Elementos corresponden
al elemento que vayamos a trazar su trazabilidad (Work Products, personas,
objetos, etc.).
(14)SP1.5: Se identifican incoherencias entre los requisitos, los planes de
proyecto y los Work Products, se documentan y se toman medidas correctivas?
(REALIZACIN)

25
Uno de los grandes problemas de los requisitos es la incoherencia con respecto al
resto de requisitos, con los planes de proyecto o con los Work Products
existentes. Por ello es necesario un anlisis para evitar este tipo de situaciones.
Cuando nos encontramos ante una incoherencia de un requisito hay que indagar
en su origen y mucho ms importante descubrir la razn por la que se da dicha
incoherencia. Despus de esto hay que identificar los cambios que se deben
realizar o en los planes de proyecto o en los Work Products existentes para
eliminar al incoherencia. Tambin se puede rechazar o modificar el requisito
afectado para evitar la incoherencia.
Por ltimo se deber poner en marcha las acciones correctoras para arreglar la
incoherencia del requisito.
En un documento, como por ejemplo la estructura de documento del (Apndice
9.15) podemos dejar constancia de todos estos problemas de incoherencias, as
dispondremos de las razones por las que se han realizado ciertas tareas para
remediar una incoherencia detectada.
4.3 Proposiciones de mejora con respecto a las Prcticas Especficas MA
El cuestionario de estado inicial de las prcticas especficas MA consta de 31
preguntas, las cuales han tenido una respuesta afirmativa 17 y negativa 14, por lo
que la tasa de cumplimiento es del 55%.
Grficamente la proporcin entre respuestas afirmativas y negativas quedara de
la siguiente forma:
Figura 14: Relacin respuestas SI / NO de MA
A continuacin se detallan las preguntas contestadas negativamente:
(3)SP1.1: Se definen y documentan objetivos operativos de medicin para la
unidad de desarrollo alineados a los objetivos estratgicos de la organizacin?
(por ejemplo: objetivo estratgico-aumentar satisfaccin del

26
cliente, objetivo operativo para la unidad de desarrollo-reducir errores en
produccin) (REALIZACIN)

Los objetivos de medicin detallan la razn por la que realizar cierta medicin y su
anlisis, adems de especificar qu tipo de medidas pueden adoptarse con el
anlisis de los datos obtenidos.
Hay diferentes tipos de fuentes de estas mediciones, entre ellas encontramos la
gestin, proyecto, tcnica, producto o de procesos.
Como consecuencia de los anlisis de medicin o bien de los procesos para
conseguirlos pueden verse modificadas las necesidades de informacin.
Las fuentes de necesidades de informacin o los objetivos pueden incluir lo
siguiente segn CMMI:
Planes de proyecto
Seguimiento de los resultados de los proyectos
Entrevistas con los directores y otras personas que tienen necesidades de
informacin
Establecimiento de objetivos de gestin
Planes de estrategia
Planes de negocio
Requisitos formales u obligaciones contractuales
Gestiones problemticas o problemas tcnicos
Experiencias de otros proyectos o entidades de la organizacin
Puntos de referencia de industria externa
Planes de mejora de procesos

Por otro lado como posibles objetivos de medicin podramos tener:

Reducir el tiempo de entrega
Reducir los costes del ciclo de vida total
Entregar funcionalidad completamente especificada
Mejorar los niveles de calidad previos
Mejorar las puntuaciones previas de satisfaccin del cliente
Mantener y mejorar las relaciones adquiridas con los proveedores

(4)SP1.1: Se dispone una trazabilidad entre las necesidades de informacin y

los objetivos? (REALIZACIN)

27
Siempre es recomendable disponer de una trazabilidad entre necesidades de
informacin y los objetivos asociados. Con esta trazabilidad podramos responder
a Para qu vamos a medir esto? O Qu se mide con esto?
Podemos realizar una trazabilidad con una simple tabla donde en un eje
tengamos las necesidades de informacin y por otro lado los objetivos. De esta
forma de una forma rpida podemos saber la trazabilidad entre ambas cosas.
(5)SP1.1: Se revisan peridicamente los indicadores y se actualizan en caso
necesario? (REALIZACIN)

Los objetivos pueden y deben ser revisados y si procede actualizados cada cierto
tiempo. Al estar documentados estos objetivos pueden ser revisados por la
administracin o las partes interesadas. Tal vez los objetivos fijados en un
determinado momento eran demasiado ambiciosos para los recursos disponibles
por lo que pueden ser actualizados para adaptarse a los recursos existentes. Por
otro lado, puede que con los procesos de captura de datos de ciertas mediciones
se vea necesario o aconsejable introducir nuevas mediciones que mejoran el
cumplimiento de los objetivos fijados con anterioridad.
En cuanto a la gente que debe de estar involucrada en la revisin de objetivos as
como en el diseo de los planes de accin est la administracin, las partes
interesadas y los responsables de captura de datos para estas mediciones.
(6)SP1.2: Existe una definicin operativa clara y sin ambigedades para cada
indicador (ej.: descripcin del indicador, frmula, unidades de medicin, etc.)?
(REALIZACIN)

Para todas las medidas se tiene que disponer de una especificacin detallada y
deben ser cuantificables. Estas definiciones operativas se detallan de forma clara
y precisa.
Las medidas deben de responder a dos criterios principalmente. Una de ellas de
Comunicacin donde se debe responder a preguntas como Qu se mide?,
Cmo se mide?, Cules son las unidades de medida?, etc. El otro criterio sera
Repetividad y contesta preguntas como Puede repetirse la medicin con la
misma definicin para obtener los mismos resultados?

28
Por ltimo hay que tener en cuenta la diferencia entre medidas base y medidas
derivadas. Las primeras son las que se obtienen de forma directa y las
segundas son las que son una combinacin de varias medidas base. Por
ejemplo, como medida base tenemos las lneas de cdigo de un proyecto, y las
horas gastadas en el proyecto. Por otro lado como medida derivada tendramos
las lneas de cdigo por hora que sera una simple divisin entre las lneas de
cdigo hechas en general entre las horas invertidas en el proyecto para realizar
ese cdigo.

(7)SP1.2: Se identifican medidas candidatas basadas en los objetivos y se

clasifican? (REALIZACIN)

Las mediciones de los objetivos se refinan en mediciones ms especficas. Las

mediciones candidatas identificadas se clasifican y se especifican por su nombre
y unidades de medida.
(8)SP1.2: Se identifican medidas ya existentes que se ocupen ya de los
objetivos en el proyecto o en otros de la organizacin? (REALIZACIN)

El principal beneficio que nos ofrece la reutilizacin es el hecho de no volver a

realizar un trabajo ya hecho con anterioridad, adems de que ya ha sido probado
y mejorado si se necesita. Por eso es recomendable buscar entre las medidas de
otros proyectos o del mismo proyecto para ver si ya hay alguna medida para el
objetivo a realizar, en tal caso simplemente es cuestin de copiarlo revisndolo
por si hay que realizar alguna modificacin o adaptacin.
(10)SP1.3: Se identifican las medidas que son necesarias pero que no estn
disponibles an? (REALIZACIN)

Hay que tener tambin en cuenta que nos siempre estn disponibles todos los
datos para realizar las mediciones. O bien porque an no se ha completado una
medicin que es necesaria para otra, o bien porque no se dispone de los recursos
necesarios para abordar dicha medicin. De todas formas se debe de identificar
dichas medidas como si lo estuvieran para cuando estn disponibles.
(12)SP1.3: Para cada indicador, se ha especificado cmo calcular la medida,
la frecuencia de clculo, quin es el responsable de tomar la medida y dnde se
ha de guardar su resultado? (Por ejemplo: de dnde obtener los datos de entrada
al indicador, forma de clculo, posibles procedimientos y herramientas para su
obtencin). (REALIZACIN)

Para cada una de las medidas se ha de especificar de una forma clara el cmo,
cundo y dnde los datos se recogern. Los datos recogidos sern almacenados
en un lugar accesible para su posterior anlisis y se tendr que detallar si estos

29
datos van a ser reutilizados posteriormente para un reanlisis o bien se usaran de
cara a la documentacin del proyecto.
Segn la norma de CMMI las cuestiones tpicas que se deberan contestar seran:
Quin va a ser la persona responsable de obtener los datos?
Se ha determinado en que momentos del proceso y con qu frecuencia se
recogern los datos para la medicin?
Se dispone del tiempo necesario para pasar los resultados de las mediciones a
los repositorios de datos, bases de datos o a los usuarios finales identificados?
Existen herramientas de apoyo o de almacenamiento de datos para dicha
recogida de datos que haga ms eficiente su recogida?
Quin ser el responsable que se encargar de la seguridad de los datos, as
como de su almacenamiento y recuperacin?

(17)SP1.4: Se especifica el procedimiento de anlisis y los informes que se

prepararn? (REALIZACIN)

Hay que en una etapa temprana especificar los anlisis que se llevarn a cabo
con los datos obtenidos y la forma en la que estos sern presentados a las
personas interesadas.
Hay que tener en cuenta dos criterios:
Hay que abordar explcitamente el anlisis documentado de la medicin de
objetivos.
Los resultados presentados deben ser entendidos por la gente a la que va dirigido
y en caso contrario explicarles la informacin, sino las mediciones no tendrn
ninguna utilidad si no son entendibles.

Cuando se presenta la informacin a las personas interesadas de estas

mediciones hay que elegir correctamente la forma en que se visualizar y utilizar
tcnicas de presentacin como graficas de barras, circulares, etc. Tambin segn
el caso puede ser conveniente el uso de estadsticas descriptivas tales como la
media, moda, desviacin, etc.
Por otro lado hay que explicar cmo manejar las mediciones en las cuales falta
an algn dato relevante.
(18)SP1.4: Se analizan los datos de acuerdo al procedimiento de anlisis
definido (responsable de anlisis, forma de anlisis, frecuencia)? (REALIZACIN)

30
Con anterioridad a la recogida de datos se ha procedido a definir los
procedimientos de anlisis de estos datos as como aspectos como quien ser el
encargado de realizar dicho anlisis, la forma en la que se analizarn los datos y
se presentarn as como la frecuencia con la que se realizar dichos anlisis. Por
esto es conveniente seguir estos procedimientos.
De todas formas si por alguna razn se detectara que los procedimientos,
persona responsable del anlisis o la frecuencia de anlisis no son las adecuadas
se puede modificar esta definicin de procedimientos del anlisis para adecuarlos
a las necesidades actuales.

(19)SP1.4: Para cada indicador, se ha especificado quin y a quines se han

de comunicar los resultados de la medida? (REALIZACIN)

Se tienen que especificar unos procedimientos de comunicacin de los anlisis.

Por un lado es conveniente identificar la persona encargada de transmitir estos
anlisis que no tiene por qu ser la misma persona que los ha analizado. Por otro
lado hay que tener en cuenta a que personas va a ser dirigido estos anlisis de
forma que se adapte la informacin a lo que necesitan saber las personas
interesadas y adaptarse a lo que conocen. Por ltimo hay que especificar el cmo
se presentar la informacin y cuando, si en un informe de progreso, un informe
escrito o una reunin personal entre otras modalidades.

(21)SP1.4: Se especifican los criterios para evaluar la utilidad de los anlisis?

(REALIZACIN)

Todos los anlisis deben estar sujetos a una revisin para comprobar la utilidad
que tienen realmente. Para ello se tienen que especificar una serie de criterios
con los que poder evaluarlos.
Como posibles criterios para evaluar la utilidad de los anlisis podramos analizar
si los anlisis son previstos en el momento oportuno no retrasndose y perdiendo
utilidad por ofrecer unos datos valiosos a destiempo. Tambin hay que tener en
cuenta si los anlisis realizados son comprensibles para la gente a la que va
dirigido. Unos anlisis que no sean entendibles por la gente que lo va a utilizar no
tienen ninguna utilidad. Por otro lado hay que ver si estos anlisis tienen alguna
utilidad de cara a la toma de decisiones. Por ltimo hay que tener en cuenta si el
beneficio que nos ofrece el disponer de estos anlisis compensa el trabajo
invertido en conseguir estos anlisis.
Como posibles criterios para evaluar la realizacin de la medicin habr que tener
en cuenta si los datos que faltan son mayores del umbral de incoherencia
especificado, disponer de un sesgo de la seleccin de muestreo donde solo se 48

31
analizar los datos que van a satisfacer las necesidades de los usuarios finales.
Tambin es necesario ver si la medicin puede ser repetible como la estadstica
fiable. Por ltimo hay que tener en cuenta si las suposiciones estadsticas se han
cumplido para evitar posibles errores.
(24)SP2.2: Se realizan mediciones adicionales si son necesarias para la
presentacin de los resultados? (REALIZACIN)

Los resultados de los anlisis pocas veces son evidentes por lo que es necesaria
una tarea de interpretacin de los resultados obtenidos as como la extraccin de
conclusiones preliminares.
Para una mejora en la interpretacin de los resultados o de cara a la exposicin
de los resultados de cara al usuario final tal vez sea necesario realizar una serie
de clculos adicionales obteniendo medidas derivadas nuevas para clarificar lo
que se va a exponer. De igual modo que el anlisis de las medidas principales,
hay que tener en cuenta el coste que conlleva las nuevas mediciones adicionales
y compararlo con los beneficios que nos proporcionar para entender los
resultados.
(29)SP2.3: Se asegura la seguridad sobre el acceso a los datos (uso exclusivo
del algn grupo o personal, uso indebido)? (REALIZACIN)

El hecho de almacenar los datos recogidos proporciona la oportunidad de usarlos

en otras mediciones futuras o anlisis de resultados. Es bueno disponer de un
contexto de cara a las futuras mediciones para tener en cuenta anlisis anteriores
y poder compararlos con los que se hagan actualmente.
La informacin almacenada suele contener lo siguiente:
Planes de medida
Las especificaciones de las medidas
El conjunto de datos recogidos
Anlisis e informes de las medidas

Toda la informacin anterior que se almacena es necesaria de cara a poder

entender los datos en el futuro.
El lugar donde se almacenan esta informacin vara segn la extensin de los
anlisis. Si tenemos unas mediciones muy especficas lo almacenaremos dentro
de la carpeta del proyecto especfico, pero si por el contrario, se trata de unas
mediciones muy globales que se utilizarn para otros proyectos lo mejor es
disponer de un directorio global de proyectos donde almacenar dicha informacin.

32
Por ltimo esta informacin si lo requiere debe de disponer de un control de
acceso para salvaguardar la seguridad de estos. Para prevenir el uso incorrecto
de los datos hay que educar a los usuarios en el buen uso de los datos y controlar
el acceso a determinadas personas.
Como ejemplos de malos usos de esta informacin tenemos:
Divulgacin de informacin privada que se nos proporcion con confianza.
Interpretacin inadecuada o engaosa de la informacin para beneficio propio.
Las medidas son utilizadas indebidamente para evaluar a las personas o para
clasificar a los proyectos.
Cuestionar la integridad de ciertas personas.

4.4 Proposiciones de mejora con respecto a las Prcticas Especficas PMC

El cuestionario de estado inicial de las prcticas especficas PMC consta de 19
preguntas, las cuales han tenido una respuesta afirmativa 4 y negativa 15, por lo
que la tasa de cumplimiento es del 21%.
Grficamente la proporcin entre respuestas afirmativas y negativas quedara de
la siguiente forma:
Figura 15: Relacin respuestas SI / NO de PMC
A continuacin se detallan las preguntas contestadas negativamente:
(1)SP1.1: Existen informes del estado del proyecto que recojan los valores
actuales VS planificados respecto al calendario? (REALIZACIN)

Es importante disponer de un seguimiento del estado del proyecto en cada

momento. Para ello peridicamente se deber realizar una serie de mediciones de
las actividades e hitos, comprobando en qu estado se encuentran en ese
momento. 50

33
Con las mediciones del estado de las actividades y de los hitos cada cierto
tiempo, hay que compararlo con el calendario especificado en el plan de proyecto.
Esto se hace para detectar posibles desviaciones del programa que ya se
estimaron en el plan de proyecto cuando se document. En caso de detectar
desviaciones se debern tomar las medidas oportunas para volver al plan
marcado.
(3)SP1.1: Existen informes del estado del proyecto que recojan los valores
actuales VS planificados de los atributos de los Work Products y las tareas?
(REALIZACIN)

De igual modo que se controlan peridicamente el estado de las actividades y los

hitos de un proyecto hay que controlar los Work Products y las tareas. Para ello
cada cierto tiempo se comprobar su estado y se ver en la planificacin del plan
de proyecto si existe algn tipo de desviacin. En caso de detectarse cualquier
desviacin que aleje del calendario fijado en el plan de proyecto se tomarn
medidas con la intencin de solucionarlo.
(5)SP1.1: Existen informes del estado del proyecto que recojan los valores
actuales VS planificados respecto a los conocimientos del personal?
(REALIZACIN)

A lo largo de un proyecto tal vez sea necesario que el personal asociado al

proyecto adquiera cierto tipo de conocimientos para el desarrollo de este. Al inicio
del proyecto se fijan los conocimientos que sern necesarios alcanzar a travs de
una formacin especfica y en base a esta especificacin se comprobar si se van
adquiriendo los conocimientos adecuados segn la planificacin inicial. En caso
de no disponer de ellos en los tiempos especificados se debern tomar medidas
para solucionarlo. Dado que se supone que estos conocimientos son necesarios
para el desarrollo del proyecto, es de vital importancia que estos plazos se
cumplan para no retrasar en exceso el proyecto.
En cuanto a la formacin puede darse una formacin por una entidad externa al
proyecto, gente especializada en el conocimiento a adquirir, o bien una formacin
personal, autodidacta, en la que el personal ser el encargado de formarse
individualmente con la informacin que se le suministre o pueda encontrar en su
entorno (internet, biblioteca, libros de consulta de la empresa, compaeros, etc.)
(6)SP1.1: Se documentan las desviaciones significativas de parmetros
analizados?(REALIZACIN)

34
En los proyectos hay que controlar tanto las actividades e hitos, Work Products y
tareas, costes y esfuerzo, recursos, y conocimientos a adquirir por el personal del
proyecto. Todo este control es a fin de encontrar posibles desviaciones que
puedan dificultar el cumplimiento del calendario especificado en el plan de
proyecto. Cuando existan desviaciones habr que documentarlas mediante un
registro de desviaciones significativas. Este documento se ir actualizando
conforme se vayan detectando desviaciones en los elementos mencionados
anteriormente.
(7)SP1.2: Se identifican y documentan los compromisos no satisfechos (o que
corren riesgo de no ser satisfechos)?(MEJORA)

Peridicamente se deben controlar los compromisos especificados al inicio del

proyecto. Al realizar este control se puede encontrar con que existen
compromisos que no han sido satisfechos o que tienen el riesgo de no llegar a
cumplirse. En estos casos hay que documentar estos controles mediante unas
actas de comentarios de compromisos donde se detallarn tanto los compromisos
que no han sido cumplidos junto con sus razones y los compromisos que tienen
riesgo de no cumplirse junto con sus respectivas razones por las cuales pueden
no cumplirse.
(8)SP1.2: Se documenta los resultados de las revisiones
realizadas?(REALIZACIN)

Los controles peridicos efectuados en las actividades e hitos, Work Products y

tareas, conocimientos necesarios, coste y esfuerzo, y recursos necesarios deben
ser documentados mediante un registro.
Los controles peridicos de compromisos no satisfechos o bien que tengan
riesgos de no cumplirse debern ser documentados mediante un acta de
comentarios de compromisos.
(11)SP1.4: En caso de datos sensibles (ej.: datos sujetos a LOPD), se
comprueba peridicamente que se estn siguiendo los requisitos y
procedimientos establecidos para asegurar la privacidad y seguridad de los
datos? (REALIZACIN)

Ciertos datos por sus caractersticas estn sujetos a la Ley Orgnica de

Proteccin de Datos de Carcter Personal (LOPD). Esta ley tiene como objetivo

35
garantizar y proteger los datos personales, los derechos fundamentales de las
personas fsicas, y sobre todo su honor, intimidad y privacidad.
Este es un tema delicado que de no tratarse con cautela puede propiciar graves
problemas para la organizacin. Segn datos de la Agencia Espaola de
Proteccin de Datos estas seran las posibles sanciones:
Las sanciones leves van desde 601,01 a 60.101,21
Las sanciones graves van desde 60.101,21 a 300.506,05
Las sanciones muy graves van desde 300.506,05 a 601.012,10
Lo correcto sera que estos datos fueran almacenados en algn lugar donde
tuvieran nicamente acceso las personas que deban tener este acceso, haciendo
imposible su acceso por personas ajenas al proyecto o que no puedan acceder a
dichos datos.
(12)SP1.5: En el plan de proyecto se han definido la involucracin y las
responsabilidades de las personas interesadas para las distintas actividades se
revisa que todo esto se est cumpliendo? (MEJORA)

En el plan del proyecto inicialmente se debe de especificar cules sern las

personas involucradas en ciertas partes del proyecto y responsables para las
distintas actividades.
Mediante unos registros de participacin de las personas interesadas se deber
peridicamente tener un control de su participacin en el proyecto. En caso de
encontrar problemas o defectos debern documentarse de igual modo y tomar
medidas al respecto.
(13)SP1.6: Se realizan reuniones de seguimiento peridicas del equipo de
proyecto para tratar el progreso tcnico, planes y posibles problemas contra lo
definido en el plan? Se documenta el resultado de las mismas? (MEJORA)

Peridicamente debe de realizarse reuniones que comprueben el estado del

proyecto teniendo en cuenta su progreso actual, los planes establecidos con
anterioridad y posibles problemas detectados.
Con estas reuniones se controlar el estado del proyecto en general y se
comunicar los resultados a las personas interesadas como clientes,
proveedores, otras personas dentro del proyecto, etc.
Estas reuniones son adecuadas para detectar y formalizar posibles solicitudes de
cambio en Work Products y procesos.

36
Tambin en estas reuniones con las medidas obtenidas de la recogida de datos
vista en el rea de proceso MA se podrn analizar ciertos aspectos del proyecto
para detectar posibles desviaciones sobre el plan de proyecto inicial.
(14)SP1.7: Se revisan peridicamente los logros y resultados de ciertos hitos
seleccionados, identificando posibles problemas contra el plan definido? Se
documenta el resultado? (MEJORA)

Al principio del proyecto, cuando se define el plan de proyecto se pueden

seleccionar ciertos hitos que sern revisados peridicamente comprobando
cuales cumplen los resultados previstos.
En algunas revisiones tal vez aparezcan problemas que afecten al plan definido
por lo que habr que documentarlos y comunicarlo a las personas interesadas del
proyecto para tomar una decisin que solucione el problema.
(15)SP2.1: Se lleva un registro de los problemas ms significativos que surgen
en el proyecto (posibles fuentes de problemas: durante las actividades de
verificacin y validacin, desviaciones significativas respecto del plan, riesgos,
problemas con las partes interesadas, baja de un miembro del equipo de
proyecto, etc.)? (MEJORA)

A lo largo de los proyectos surgen infinidad de problemas que pueden ocasionar

serios problemas de cara a seguir la planificacin del plan de proyecto. Esta es
una de las razones por las que hay que documentar cualquier problema
significativo de cualquier ndole para una posterior revisin.
Posibles problemas pueden ser muchos, desde errores de programacin, hasta
bajas de personales. Cualquier problema significativo, a la larga puede ocasionar
un problema mayor si no es tratado correctamente que altere significativamente la
planificacin.
Todos los problemas es mejor atajarlos desde la raz, en el momento en que se
producen cuando estn ms localizados y pueden evitarse consecuencias del
problema. En caso de no revisar los problemas, estos pueden a su vez
desencadenar nuevos problemas mayores tal vez insalvables.
Por todo esto es necesario disponer de un registro donde se vayan anotando todo
tipo de problemas encontrados que puedan afectar al proyecto. Con esto en las
reuniones de control se podrn revisar y buscar posibles soluciones.
(16)SP2.1: Se documentan el anlisis y las razones por las que el problema
requiere o no accin correctiva? (REALIZACIN)

37
Cuando se registra un problema de un proyecto se debe analizar para primero
saber la importancia que tiene, si merece la pena tratarlo como un problema vital
para el desarrollo del proyecto. En cualquiera de los casos los problemas deben
despus de su anlisis reflejar si el problema merece tomar acciones correctivas o
si por el contrario el problema aunque existe no es relevante y puede seguir todo
como hasta el momento. Se elija que se deben tomar medidas o que no se deben
tomar, es necesario indicar las razones para tal decisin de la forma ms precisa
posible.
Con esta documentacin en las reuniones donde se traten los problemas del
proyecto ya se ver las acciones a realizar, pudiendo tomar incluso medidas
sobre problemas en los que no se vea necesario tomar medidas correctivas.

38
FUENTES

http://www.teamsoft.com.pe/blog/implementando-cmmi-por-donde-empezar/

http://www.sei.cmu.edu/publications/documents

39
ANEXOS

CASOS DE IMPLEMENTACIONES

Implementando CMMI: Por dnde

empezar?
OCTOBER 9, 2013 AT 11:46 AM

La implementacin del nivel 3 del modelo CMMI nos demor 8 meses a diferencia de los
9 meses que nos demor implementar el nivel 2, aunque en realidad la implementacin
del nivel 2 fue muchsimo mayor si contamos el primer esfuerzo que se realiz en
TeamSoft, en donde se definieron varios procesos, formatos, plantillas, entre otros
documentos, trabajados todos bajo las prcticas del modelo en su versin 1.1. En este
primer esfuerzo se cometi el error de considerar las reas de proceso del modelo como
procesos de la empresa. Bueno este y otros inconvenientes se solucionaron cuando se
cre formalmente un proyecto interno en TeamSoft para implementar el nivel 2 del
modelo, que para ese entonces ya se encontraba en su versin 1.2.

Resalto el echo de la duracin porque el nivel 3 significa en nmero de prcticas tres

veces ms que la cantidad de prcticas contenidas en el nivel 2. Entonces la pregunta es,
cmo pudimos implementarlo ms rpido si contbamos con la misma cantidad de
personas en el equipo?, en todo caso qu hicimos bien?.

En realidad en ambos proyectos, el de la implementacin del nivel 3 y el del nivel 2 (en su

segundo intento), utilizamos una metodologa basada en el modelo IDEAL (modelo
publicado por el Software Engineering Institute).

40
 Modelo IDEAL publicado por el SEI

Este modelo se llamada IDEAL por las iniciales de las cinco fases que lo describen:
Iniciacin, Diagnstico, Establecimiento, Accin y Aprendizaje (Learning) y que en
resumen es una gua para implementar acciones de mejoras organizacionales en
general.

41
 Modelo IDEAL publicado por el SEI

En TeamSoft creamos una metodologa de trabajo basado en este modelo y

consideramos la implementacin del modelo CMMI como una gran accin de mejora, que
dado su esfuerzo y tiempo lo denominamos proyecto de mejora.

A continuacin les detallar los 8 puntos ms resaltantes que realizamos al iniciar la

implementacin del modelo CMMI:

Obtener el involucramiento de la Gerencia o tener un Sponsor de peso. La

implementacin del modelo CMMI en TeamSoft se consider como un proyecto ms
que se una a la cartera de proyectos en marcha que eran monitoreados directamente
por la Gerencia en las reuniones quincenales donde cada Jefe de Proyecto deba
informar su avance, problemas, riesgos, entre otros temas relacionados con su
proyecto.

Recibir una capacitacin en el modelo. Nosotros nos preparamos en talleres,

conferencias y diplomados. Adicionalmente recibimos asesoras externas que nos
ayudo a acelerar el entendimiento de las prcticas, ya que en muchas ocasiones
necesitamos de ejemplos o maneras distintas de implementar las prcticas o de
clarificar conceptos, entre otros. Contar con esta clase de asesora nos permito
adems estar alineados con lo que se esperaba de la evaluacin SCAMPI A (tipo de
evaluacin que otorga como resultado la valorizacin en el nivel obtenido, es decir si
nos certificamos o no).

Definir el objetivo de mejora. Este punto es muy importante ya que nos permiti
comparar la situacin actual versus la que tuvimos luego de implementar el modelo
CMMI, as pudimos medir si llegamos al objetivo trazado o tambin nos permiti
42
 costear los beneficios conseguidos. Por ejemplo nuestro objetivo de mejora fue reducir
la densidad de errores. Por otro lado contar con un objetivo de mejora medible y
alcanzable, nos permiti darle sostenibilidad al esfuerzo incurrido en la implementacin
del modelo.

Analizar la situacin actual. Aparentemente puede tomarse como un retraso o como

una actividad innecesaria, pero en realidad para empezar cualquier emprendimiento es
necesario conocer de dnde y en que condiciones partimos. En TeamSoft, cuando
analizamos la situacin de partida comprobamos que algunas de las prcticas del
modelo ya las estbamos cumpliendo de alguna manera.

Formar un grupo de trabajo. El xito y la mejor aceptacin de lo definido resulta

cuando se establece un grupo de trabajo incluyendo a los mismos ejecutores y
expertos, es decir Analistas Funcionales, Jefes de Proyectos, entre otros roles
afectados por la implementacin, quienes conjuntamente con los integrantes del rea
de Mejora de Procesos crean y definen los documentos necesarios o idean la mejor
forma de implementar la prctica buscando siempre el valor agregado al Cliente o a la
Empresa.

Tener un plan de trabajo. No tengo mucho que comentar al respecto, slo hacerles
recordar que contar con un plan de trabajo nos ayuda a no perder de vista el objetivo.

Contar con una metodologa. Por ejemplo el modelo IDEAL, del cual ya hablamos al
inicio.

Mapeo de las prcticas versus lo implementado. Esta actividad ser obligatoria

realizar cuando abordemos una evaluacin SCAMPI A, pero no por ello la debemos
restarle importancia. Para m este mapeo es muy til cuando realicemos una
adecuacin en el proceso o en la plantilla y necesitemos evaluar si est referenciada o
es evidencia directa de una prctica

43
EMPRESAS CMMI

La industria del software se ha extendido de manera extraordinaria, debido

entre otras cosas, al abaratamiento de costos de hardware y a la necesidad de
contar con sistemas de informacin y presencia en Internet tan slo para
permanecer competitivos. Sin embargo, un problema que ha plagado a la
industria desde su nacimiento ha sido el tema de la calidad: existen escasas
aproximaciones, estndares o mejores prcticas por lo que cientos de
ingenieros de software, administradores de proyectos y acadmicos se han
devanado los sesos para encontrar una solucin ante constantes proyectos
que fallan en cumplir las expectativas, se retrasan o consumen ms
presupuesto del que les fue otorgado. Sin embargo, uno de los modelos de
calidad ms recientes y que mayor aceptacin ha tenido es el denominado
Integracin de Modelos de Madurez de Capacidades (Capability Maturity Model
Integration CMMI).

Los orgenes de CMMI

A principios de la dcada de 1980 varios proyectos encargados por el

Departamento de Defensa de los Estados Unidos (US Department of Defense
DoD) se batieron de forma espectacular: los proveedores encargados de
realizar dichos proyectos se extendieron ms all del presupuesto y tiempos
provistos, si es que llegaron a terminarlos. Cabe destacar que en aqul
entonces, todos los proyectos licitados por el gobierno de los Estados Unidos
incluyendo sus fuerzas armadas elegan al ganador tan slo basndose en el
precio.

As entonces, el DoD se vio forzado a fundar el Instituto de Ingeniera de

Software (Software Engineering Institute SEI) administrado por
laUniversidad Carnegie Mellon, cuya misin primordial era determinar un
marco o modelo de madurez con el que se podra juzgar la capacidad de una
compaa para producir software. Para 1987 dicho instituto haba desarrollado
el Modelo de Capacidad y Madurez (Capability Maturity Model CMM). En
1991, el SEI public la versin 1.0 del CMM para desarrollo de software (SW-
CMM), con lo que ms de 30,000 personas de aproximadamente 2,400
organizaciones fueron capacitadas para certificar a sus respectivas empresas
en CMM y poder participar en licitaciones para el gobierno Estadounidense,
que actualmente basa sus decisiones principalmente en el nivel de madurez de
los participantes. Ya en 1997 se inician los trabajos para actualizar el CMM e
incorporar estndares internacionales. En el ao 2000 se libera la primera
versin de este nuevo modelo, ahora denominado como CMMI:

44
 CMMI es una estrategia de mejora de procesos
que proporciona a las organizaciones los
elementos esenciales que en ltima instancia,
mejoran su rendimiento. CMMI puede ser usada
para guiar la mejora de procesos en un proyecto,
una divisin o una organizacin entera. Ayuda a
integrar funciones tradicionalmente separadas de
la organizacin, establece objetivos y prioridades
de mejora de procesos, proporciona una gua para
los procesos de calidad y proporciona un punto de
referencia para evaluar los procesos actuales.
CMMI Overview, Software Engineering
Institute.

En pocas palabras, CMMI es una metodologa de mejora de procesos, NO una

metodologa de desarrollo de software, de gestin de proyectos o de gestin
del ciclo de vida de software. Bsicamente CMMI es un checklist donde si el
departamento, proyecto o empresa a evaluar posee los entregables que se
esperan por cada nivel de madurez, pasar correctamente la certificacin. En
la actualidad existen cinco niveles de madurez cubiertos por el modelo, lo que
permite identificar aquellas empresas que "estn verdes" de aquellas que
pueden asegurar con relativa autoridad, que saldrn adelante al implementar
proyectos de alta complejidad y riesgo. En la siguiente tabla se muestran los
cinco niveles as como las reas de proceso que se evalan dentro de cada
nivel:

Nivel Enfoque reas de Proceso

CAR Anlisis y Resolucin
Mejora de
5 Causal
procesos
Optimizado OID Innovacin y
continua
Despliegue Organizacional
QPM Gestin de Proyectos
4 Gestin
Cuantitativa
Cuantitativamente cuantitativa de
OPP Desempeo de
Administrado los procesos
Procesos Organizacionales
DAR Anlisis de Decisin
y Resolucin
IPM Gestin Integral de
Proyectos + IPPD
3 Estandarizacin OPD Definicin
Definido de procesos Organizacional de Procesos +
IPPD
OPF Enfoque
Organizacional de Procesos
OT Capacitacin

45
 Organizacional
PI Integracin de Productos
RD Desarrollo de
Requerimientos
RSKM Gestin de Riesgo
TS Solucin Tcnica
VAL Validacin
VER Verificacin
CM Gestin de la
Configuracin
MA Medicin y Anlisis
PMC Monitoreo y Control
de Proyectos
Gestin de PP Planeacin de Proyectos
2
proyectos PPQA Aseguramiento de
Administrado
bsica Calidad de Productos y
Procesos
REQM Administracin de
Requerimientos
SAM Gestin de Acuerdo
con Proveedores
Dependencia por personal competente
1
("hroes") y sus herramientas. Este nivel no es
Inicial
evaluado por CMMI.

De acuerdo al nivel de certificacin se requerirn los documentos o pruebas de

que los procesos a evaluar se estn llevando a cabo. Por ejemplo, para la
evaluacin de CMMI Nivel 2, es necesario revisar el rea de procesos
denominada como Planeacin de Proyectos (Project Planning PP). Esto
requiere demostrar que se estn llevando a cabo las actividades
correspondientes mediante los siguientes Objetivos Especficos (OE) as como
las Prcticas Especficas (PE) de sta rea de procesos:

OE 1: Establecer Estimados
PE 1.1: Estimar el Alcance del Proyecto
PE 1.2: Establecer Estimados del Trabajo y
Tareas
PE 1.3: Definir el ciclo de vida del proyecto
PE 1.4: Determinar Estimados de Esfuerzo y
Costo
OE 2: Desarrollo de un Plan de Proyecto
PE 2.1: Establecer el Presupuesto y Calendario
PE 2.2: Identificar los Riesgos del Proyecto
PE 2.3: Plan para Gestin de Datos
PE 2.4: Plan de Recursos del Proyecto
PE 2.5: Plan para Conocimiento y Habilidades

46
 Requeridos
PE 2.6: Plan para Participacin de Stakeholders
PE 2.7: Establecer Plan de Proyecto
OE 3: Obtener el compromiso con el Plan
PE 3.1: Revisin de Planes que Afectan el
Proyecto
PE 3.2: Reconciliar Trabajo y Niveles de
Recursos
PE 3.3: Obtener Compromiso con el Plan

Recalcando nuevamente que CMMI no es una metodologa de desarrollo o

gestin, sta asume que la empresa o rea por certificar ya posee los
estndares necesarios para comprobar su nivel de madurez, por lo que la
entidad certificadora no solicitar un artefacto de alguna metodologa
especfica. Sin embargo, slo como referencia: si estuvisemos
implementando correctamente RUP en conjunto con el PMBOK en nuestros
proyectos, pasaramos prcticamente sin esfuerzo la evaluacin para una
certificacin en CMMI-2 y tendramos una pequea parte de los puntos
cubiertos por CMMI-3.

Por qu es tan importante CMMI?

Resumiendo: dinero. Originalmente CMM y su actualizacin CMMI se pensaron

como metodologas de procesos que permitiran a muchas empresas de
desarrollo de software ser proveedores del gobierno Norteamericano y ste
puede ser muy dadivoso, sobre todo en contratos para la defensa. Sin
embargo, CMMI se est convirtiendo poco a poco en un estndar que puede
ser usado para promocionar la capacidad de desarrollar software de alta
criticidad, o que puede dar una ventaja competitiva si se desea participar en
proyectos de alta complejidad y riesgo, que por obvias razones, tienen un alto
precio y muy buenas ganancias. Por ejemplo, Boeing, General Dynamics, IBM,
Lockheed Martin, Motorola, Raytheon o Toshiba son algunas de las empresas
que han alcanzado el nivel 5 de CMMI, lo que les abre las puertas a proyectos
de decenas o cientos de millones de dlares.

Quines estn certificados en CMMI en el mundo?

Al 22 de Julio de 2010 existan 3,060 certificaciones activas proporcionadas

por el SEI (ver aqu el listado). Muchas de stas son compartidas por varios
pases, debido a que alguna parte del proyecto, rea o empresa certificados se
lleva de manera descentralizada. Por ejemplo, la compaa EADS(European
Aeronautic Defense and Space Company) es un conglomerado Europeo que
certific su divisin de Sistemas de Comunicaciones de Defensa (Defense and
Communications Systems DCS) en el segundo nivel de CMMI el 10 de Junio
de 2009. Esta certificacin es compartida por Alemania, Francia, Reino Unido y
Finlandia, debido a que ciertas reas de investigacin y desarrollo de la
47
divisin se encuentran repartidas entre estos cuatro pases. As entonces,
existen 3,135 certificaciones otorgadas a 72 pases del mundo. El top 10 de
certificaciones a nivel mundial, no es de extraarse, se lo llevan algunas de las
economas ms grandes del planeta:

Pas Certificaciones
China 1,048
Estados Unidos 680
India 294
Espaa 131
Brasil 98
Japn 87
Corea del Sur 71
Francia 70
Mxico 70
Taiwn 67
Resto del Mundo 519

Aqu surgen algunas observaciones que vale la pena mencionar:

Es impresionante ver cmo China se est apoderando del mundo: con poco
ms de la tercera parte de las certificaciones otorgadas a nivel mundial
(1,048), el futuro es de ellos.

Estados Unidos y Canad agrupan 702 certificaciones, muchas de ellas

compartidas; esto permite consolidar a esta regin de Norteamrica como una
sola potencia que an as, se ve pequea comparada con la basta cantidad de
certificaciones que posee China.

Europa tiene 371 certificaciones, de las cuales poco ms de la tercera parte

(131) son de Espaa, el pas ms avanzado en este sentido.

Latinoamrica en su conjunto est adquiriendo importancia: con Brasil (98)

y Mxico (70) a la cabeza, existen 280 certificaciones otorgadas a la regin.
Los pases Latinoamericanos que cuentan con alguna certificacin incluyen
Argentina (47), Chile (26), Colombia (18), Per (10), Uruguay (4), Costa Rica
(4), Guatemala (1), Panam (1), Paraguay (1), El Salvador (1) y Venezuela
(1).

48
 La triste realidad del frica Subsahariana es que siguen estando muy
atrasados con respecto al resto del mundo; actualmente cuentan con apenas 5
certificaciones, contribuidas por Sudfrica (2), Ghana (1), Mauricio (1) y
Malawi (1).

Finalmente, el caso para la araa: Rusia cuenta con apenas 4

certificaciones. Sin embargo, se nota perfectamente que dichos
reconocimientos fueron requeridos para captar dlares: MERA Networks, el
Centro de Diseo Boeing en la ciudad de Mosc (Moscow Boeing Design
Center), Auriga Inc. y Reksoft Co.Ltd. son las empresas Rusas que cuentan
con este tipo de certificacin.

El caso Mexicano

En la actualidad tenemos 70 instituciones certificadas con CMMI en Mxico, de

las cuales tres se comparten conjuntamente con Argentina y una con los
Estados Unidos:

Estado de
Empresa rea Certificada Fecha Nivel la
Repblica
Tecnologa de
Tecnologa de Gestin
Gestin y
y Comunicacin S.A. 07/05/2010 2 CHIH
Comunicacin
de C.V.
S.A. de C.V.
SAITOSOFT
PROJECT
SAITOSOFT, S.A. DE MANAGEMENT
28/03/2008 2 DF
C.V. AND QUALITY
ASSURANCE
AREAS
ITE Software
ITE Soluciones S.A. de
Development 12/06/2009 2 DF
C.V.
Unit
Centro de
Centro de Inteligencia
Inteligencia
Competitiva S.A. de 25/09/2009 2 DF
Competitiva
C.V.
(CIC)
Technology
Mapdata S.A. de C.V. 16/10/2009 2 DF
Direction
Development and
Tecnologa, Asesora,
Support & 13/11/2009 2 DF
Sistemas, S.A. de C.V.
Consulting Units
e-Nfinito e-Nfinito 12/02/2009 2 GTO

49
 Serv.
Informaticos &
Universidad Tec. de
Tecnologica de Leon Informacion y 17/12/2009 2 GTO
(UTL) Comunicacion:
Software
Development
Software
SIMBIOSYS S.C. Development 30/04/2010 2 GTO
Area
COMPUTACION EN COMPUTACION
ACCION, S.A. DE EN ACCION, 07/02/2009 2 JAL
C.V. S.A. DE C.V.
DAWCONS: DW IT Software
SERVICES S.A. DE Development 08/01/2010 2 JAL
C.V. Services
Area de
Ejecutivos en Desarrollo de
Computacin y Software Interna 19/03/2010 2 JAL
Servicios S.A. de C.V. de
Compusoluciones
Tecnologa en
Informtica y Development
15/04/2010 2 JAL
Administracin S.A. de Area
C.V.
GEUSA, Grupo
Systems
Embotelladoras Unidas 30/04/2010 2 JAL
Department
S.A. de C.V.
Operations and
ilinium S.A. 09/08/2007 2 NL
Development
Software
Development
Kernel Technologies
Team including 29/09/2007 2 NL
Group
the Quality
Assurance Team
Tecnologico de
Tecnologico de
Monterrey 12/12/2008 2 NL
Monterrey VRHTI
VRHTI DPSI
i-place i-place 30/01/2009 2 NL
Custom Software
Consiss S.A. de C.V. 28/08/2009 2 NL
Development
T-Systems Mxico, T-SYSTEMS
01/02/2008 2 PUE
S.A. de C.V. MEXICO

50
Universidad Popular
Direccin de
Autnoma del Estado
Sistemas de 22/05/2009 2 PUE
de Puebla,
Informacin
A.C.(UPAEP)
Vision Software
Vision Software
Factory, S.A. de 21/12/2007 2 QRO
Factory, S.A. de C.V.
C.V.
Software
Business Intelligent
Development 31/08/2007 2 SIN
Software, SA de CV
Team
Software
ARASYS S.A. DE
Development 23/11/2007 2 SIN
C.V.
Projects
DPSoft Software
DPSoft S.A. de C.V. Development 30/11/2007 2 SIN
Team
Sistemas
Sistemas Programacin
Programacin 29/08/2008 2 SIN
Coppel SA de CV
Coppel SA de CV
MACRO PRO S.A. de Macropro New
12/09/2008 2 SIN
C.V. Developments
Custom Software
Applied Protocol Development and
13/11/2009 2 SIN
Interfaces S.A. de C.V. Software
Manteinance
Factor Informtico de
Operations Unit 23/04/2010 2 SIN
Negocios S.A. de C.V.
RQPortillo Firm S. de Consultancy and
10/06/2010 2 SIN
R.L. de C.V. Support Units
PLENUMSOFT
SERVICIOS Y
INGENIERIA
SUMINISTROS EN 24/07/2008 2 YUC
DE SOFTWARE
INFORMATICA, S.A.
DE C.V
Brainup Systems S.A. BUS
de C.V.(Compartida Development and 17/07/2009 2 DF
con Argentina) Services
Zentrum Ziztemaz S.A. Zentrum
26/11/2009 3 BC
De C.V. Ziztemaz Tijuana
Interlogic
Logica Interactiva S.A.
Software 15/09/2009 3 CHIH
de C.V.
Engineering Area

51
 Intelligent
Intelligent Network
Network
Technologies S.A. de 18/09/2009 3 COAH
Technologies
C.V.
S.A. de C.V.
IDS Comercial S.A. de IDS Project
14/03/2008 3 DF
C.V. Development
Informtica Integral
Sinersys
Empresarial S.A. de 14/03/2008 3 DF
Technologies
C.V.
SERVICIOS SERVICIOS
TELEPRO, S.A. DE TELEPRO, S.A. 29/05/2008 3 DF
C.V. DE C.V.
Accenture Technology Accenture
22/08/2008 3 DF
Solutions Mexico MXDC
Mexico City SAT
account
Servicio de
Aduanas Area
EDS, an HP Company 15/10/2008 3 DF
AGA-
Administracin
General de
Aduanas
BLITZ
BLITZ SOFTWARE 20/12/2008 3 DF
SOFTWARE
QuarkSoft S.C. QuarkSoft S.C. 27/02/2009 3 DF
Azertia
Tecnologias de la
Azertia Tecnologias de
Informacin
la Informacin Mxico
Mxico S.A. de
S.A. de C.V. (Una 13/03/2009 3 DF
C.V. (Una
Empresa de INDRA
Empresa de
SISTEMAS S.A.)
INDRA
SISTEMAS S.A.)
T&D AUTOMATED
TESTING AND
DEVELOPMENT GRUPO TECNIS 03/04/2009 3 DF
SOFTWARE, S.A. DE
C.V.
Software
Development and
Vision Consulting 25/09/2009 3 DF
Maintenance
Projects
Software
AsTecI S.A. de C.V. 28/01/2010 3 DF
Development and
52
 Maintenance
Grupo Modelo
IBM AMS Mexico 19/03/2010 3 DF
Account
Grupo Nacional
IBM AMS Mexico Provincial 04/06/2010 3 DF
Account
D&T Tecnologa S de Deloitte GDC
31/07/2009 3 GTO
RL de CV Mxico
VENTUS Technology VENTUS
22/03/2008 3 NL
S.A. de C.V. Technology
World Software World Software
Services Group, SA de Services Group, 25/03/2009 3 NL
CV SA de CV
Software
AD INFINITUM S.A. development and
14/08/2009 3 NL
de C.V. implementation
services
SYTECSO, S.A. de
Software Factory 28/08/2009 3 NL
C.V
Expert Sistemas
Expert
Computacionales S.A. 29/08/2009 3 NL
Tecnologa
de C.V.
OPEN ROAD
OPEN ROAD
Solutions S de RL de
Solutions S de RL 19/12/2008 3 QRO
CV Queretaro
de CV
Mexico
ALTEC Mexico S.A. ALTEC Mexico
19/06/2009 3 QRO
de C.V. S.A de C.V.
ImagenSoft by Imagen
ImagenSoft
y Sistemas 03/07/2008 3 SIN
Projects Division
Computacionales, S.C.
Expresin Informativa
New
y Tcnicas
Developments 18/12/2008 3 SIN
Organizadas S.A. de
Division
C.V. (xito Software)
DESARROLLADORA
IT Deparment 04/06/2010 3 SIN
HOMEX S.A. DE C.V
QUALISYS
TSI ARYL S. de R.L.
SYSTEMS 12/09/2008 3 SON
de C.V.
AREA
INNEVO (Susoc & Innevo Software 07/09/2007 3 JAL

53
 Vates S.A. de Development
C.V.)(Compartida Services, Product
con Argentina) Factory
CRS IT Consulting Technical
S.A. de Solution
03/07/2009 3 DF
C.V.(Compartida con Implementation
Argentina) Unit
Sieena Software S. de
Sieena Software
R. L. de C. COAH,
S. de R. L. de C. 17/07/2009 3
V.(Compartida con NL
V.
Estados Unidos)
Custom Software
INNEVO Development 11/06/2010 4 JAL
Unit
Hildebrando Software Hildebrando
07/09/2007 5 AGS
Factory Software Factory
ULTRASIST S.A. de
ULTRASIST 28/03/2009 5 DF
C. V.
CEDS (Center of
PRAXIS DE
Excellence for
MXICO, S.A. DE 18/12/2009 5 DF
Development of
C.V.
Software)
Application
IBM Management 30/03/2010 5 JAL
Services Mexico
GDC Monterrey
Softtek High Growth 04/12/2009 5 NL
Accounts
SigmaTao
SigmaTao Factory,
Factory, S.A. de 24/08/2007 5 QRO
S.A. de C.V.
C.V.

Lo que me parece remarcable es que en Mxico existan cinco certificaciones

CMMI Nivel 5, lo que deja al pas por encima de casi todas las dems naciones
con este nivel de madurez, con la excepcin de la India (63), los Estados
Unidos (40) y China (20). Esto significa que aunque hay todava pocas
empresas con CMMI, las que existen tienen un nivel elevado. Esto tambin se
demuestra porque a diferencia de aquellos pases, la mayora de las empresas
Mexicanas certifican a la empresa como un todo, no slo un rea o proyecto
especficos.

Por otro lado, se nota bastante cun centralizada se encuentra la industria del
software en Mxico, pues casi todas las certificaciones se aglomeran en el

54
Distrito Federal (22), Nuevo Len (12), Sinaloa (11) y Jalisco (8). Guanajuato
y Quertaro contribuyen con 4 certificaciones cada uno, mientras Chihuahua,
Coahuila y Puebla contribuyen con 2 certificaciones por entidad. Finalmente,
en Sonora, Aguascalientes, Baja California y Yucatn existe una empresa
certificada por estado. La sorpresa aqu es Sinaloa, pues ha sobrepasado a
Jalisco (y el Silicon Valley Mexicano) por el nmero de certificaciones. Ms an
cuando Sinaloa es considerado tradicionalmente como un estado agricultor,
ganadero o turstico. Bien por los Sinaloenses!

Conclusiones

CMMI sirve no slo como plataforma para promocionarnos ante un mercado

global; el hecho de que las compaas e instituciones de tecnologa ms
importantes del mundo como la NASA, Siemens, T-Systems, Samsung o
Accenture tengan una certificacin de este tipo implican que s sirve como
modelo de mejora de procesos para desarrollar productos y servicios con altos
estndares de calidad. De hecho, aquellas empresas que no estn en la lista
son las que para bien o para mal, acaban por desaparecer o ser compradas
por la competencia.

55
56
57