Componentes de CMMI - is2-srr

Capability Maturity Model Integration
CMMI
Christian Gomez, Marcelo Ferreira, Marcelo Rodas
Universidad Nacional de Asunción, Facultad Politécnica
8vo. Semestre, Ingeniería Informática. 2008.
{cgomezpy,jmferreira1978,rodas.marcelo}@gmail.com
Trabajo Práctico de Ingeniería de Software III
Profesor MSc. Luis G. Salinas
Abstract
Este documento presenta una concisa definición y algunas caracteristicas relativas a CMMI, de tal forma a
mostrar de forma compacta y breve las principales caracteristicas de este Modelo. Especificamente, se
presentan los conceptos básicos, su historia, sus origenes, su estructura general y las ventajas y desventajas
frente a otras tecnicas. Se pretende que sirva de referencia inicial a quienes pretendan adentrarse en el
mismo.
Palabras Clave: CMMI, ingeniería de software, modelo, madurez, calidad, prácticas.
Contenido
Introducción ..................................................................................................................................... 4
Definiciones ..................................................................................................................................... 5
¿Qué es CMMI según el SEI? .......................................................................................................... 5
Madurez. .......................................................................................................................................... 5
Madurez de un proceso de software. ................................................................................................ 5
Beneficios de la mejora de procesos. ............................................................................................... 6
Beneficios CMMI ............................................................................................................................ 6
Modelos y Framework CMMI ......................................................................................................... 6
Modelos de CMMI ........................................................................................................................... 6
Versión 1.1 ....................................................................................................................................... 6
Versión 1,2 ....................................................................................................................................... 8
Framework CMMI ........................................................................................................................... 8
Breve Reseña de CMM .................................................................................................................... 8
Historia............................................................................................................................................. 8
Componentes de CMM. ................................................................................................................... 9
Área de proceso. ............................................................................................................................ 11
Componentes Requeridos .............................................................................................................. 11
Componentes Esperados ............................................................................................................... 12
Componentes Informativos ............................................................................................................ 12
Representaciones de CMMI ........................................................................................................... 12
Representación Escalonada. ........................................................................................................... 13
Representación Continua. .............................................................................................................. 13
Las dos representaciones en CMMI. .............................................................................................. 14
Nivel 1: Inicial .............................................................................................................................. 16
Nivel 2: Gestionado ....................................................................................................................... 16
Nivel 3: Definido .......................................................................................................................... 17
Obs.: Una diferencia crítica entre ambos es el alcance de descripciones de procesos,
estándares y procedimientos. Dado que en el nivel 3 los procesos son descritos más
rigurosamente y con mayor detalle. .............................................................................................. 17
Nivel 4: Cuantitativamente Gestionado ....................................................................................... 17
Obs.: En el nivel 4 el rendimiento de los procesos es cuantitativamente predecible,
utilizando técnicas estadísticas, mientras que en el nivel 3 son cualitativamente predecibles. ..... 17
Nivel 5: Optimizado ...................................................................................................................... 17
Obs.: En el nivel 4 se busca establecer una predicción estadística de los resultados,
analizando causas especiales de variación, mientras que en el nivel 5 se busca establecer
causas comunes de variación y corregir la media de rendimiento de los procesos. ....................... 17
Áreas de Proceso. ........................................................................................................................... 17
¿Cómo llegar al nivel 2? ................................................................................................................ 18
Nivel 2 de CMMI. .......................................................................................................................... 18
Planificación del proyecto.............................................................................................................. 19
Seguimiento y control del proyecto ............................................................................................... 20
Gestión de acuerdos con proveedores ............................................................................................ 20
Medidas y análisis .......................................................................................................................... 20
Medidas de calidad en el proceso y en el producto........................................................................ 21
Gestión de la configuración ........................................................................................................... 21
Nivel 3 de CMMI. .......................................................................................................................... 21
Metas Globales .............................................................................................................................. 22
Gestión de requisitos. ..................................................................................................................... 22
Solución técnica ............................................................................................................................. 22
Integración del producto ................................................................................................................ 23
Verificación ................................................................................................................................... 23
2/31
Validación ...................................................................................................................................... 23
Enfoque organizacional del proceso .............................................................................................. 23
Definición del proceso de la organización ..................................................................................... 24
Formación en la organización ........................................................................................................ 24
Gestión de riesgos .......................................................................................................................... 24
Análisis de decisiones y resolución ............................................................................................... 25
Ventajas y Desventajas de CMMI. ................................................................................................. 25
El Principal beneficios se relaciona a la mejora de procesos. Esta mejora genera lo siguiente: .... 25
Empresas Relacionadas. ................................................................................................................. 26
CONCLUSIONES ......................................................................................................................... 27
FUENTES ...................................................................................................................................... 28

Introducción
Capability Maturity Model Integration (CMMI) es un modelo para la mejora de procesos que proporciona
a las organizaciones los elementos esenciales para procesos eficaces. Su idea principal es presentar una
estructura a seguir para el desarrollo de software, de tal forma a que se pueda controlar y medir cada parte
del proceso completo de desarrollo.
Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay dos
áreas de interés cubiertas por los modelos de CMMI: Desarrollo y Adquisición.
La versión actual de CMMI es la versión 1.2. Hay tres constelaciones de la versión 1.2 disponible:
 CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue liberado en
agosto de 2006. En él se tratan procesos de desarrollo de productos y servicios.
 CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en
noviembre de 2007. En él se tratan la gestión de la cadena de suministro, adquisición y
contratación externa en los procesos del gobierno y la industria.
 CMMI para servicios (CMMI-SVC o CMMI for Services), actualmente un borrador, está diseñado
para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.
Dentro de la constelación CMMI-DEV, existen dos modelos:
 CMMI-DEV
 CMMI-DEV + IPPD (Integrated Product and Process Development)
Además, el SEI es el instituto que creó y mantiene el modelo de calidad CMM - CMMI
Se basó en la experiencia de otros modelos de la industria como son:
 Capability Maturity Model for Software (SW-CMM) v2.0 draft C.
 Electronic Industries Alliance Interim Standard (EIA/IS) 731.
 Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98.
Estas prácticas, técnicas, métodos se formularon en base a la experiencia de las organizaciones que
experimentaban lo siguiente:
 Los planes se hacen pero no necesariamente se siguen.
 No se hace un seguimiento del trabajo con el plan. Los planes no se ajustan.
 Los requerimientos no son consistentes. No se hace una gestión de cambios.
 Las estimaciones son irreales. La subestimación es común.
 Los defectos son descubiertos en la fase de pruebas, o peor aún, por el cliente.
 El éxito depende de esfuerzos heroicos de “gurús”.
Para completar con el proyecto generalmente estas situaciones sucedían/suceden:
 Las personas trabajan más tiempo y más rápido.
 Las personas se mueven de proyecto en proyecto.
 Se recortan requerimientos del proyecto.
 Los proyectos agregan más personas.
 Todos recortan las esquinas.
 Un héroe salva el día.
Y en resumen se tenía/tiene que:

Los Compromisos son incumplidos.

Entrega tardía del software.
 Por la visibilidad inadecuada de la gestión.

Muchos imprevistos.

Problemas de calidad.

Los trabajos se rehacen demasiado.

Las funciones no funcionan correctamente.

Insatisfacción del cliente.

Baja moral.


Gente frustrada.
Control inadecuado.
Por lo tanto el CMMI trata estos problemas de manera que las organizaciones adopten estándares y mejoren
la gestión y calidad del producto software y sus procesos en general. Por los problemas anteriormente
citados, se lo puede concebir al CMMI como:

Un enfoque de mejora de procesos que proporciona a las organizaciones los elementos esenciales
de la eficacia de los procesos.

Un framework para organizar y priorizar actividades.

Técnicas de apoyo para la coordinación de actividades de múltiples disciplinas que podrían ser
necesarias para construir con éxito un producto.

Una guiá de mejora de proceso a través de un proyecto, una división, o de toda una organización.


Definiciones
¿Qué es CMMI según el SEI?
® Capability Maturity Model Integration (CMMI) es un enfoque de mejora de procesos que proporciona a
las organizaciones los elementos esenciales de la eficacia de los procesos. Se puede usar para guiar el
proceso de mejora a través de un proyecto, una división, o de toda una organización. CMMI ayuda a
integrar funciones tradicionalmente separadas de organización, establecer objetivos de mejora de procesos
y prioridades, proporcionar orientación en cuanto a procesos de calidad, y proporcionar un punto de
referencia para la evaluación de los procesos actuales.

Madurez.
Implica la potencialidad de poder crecer e indica tanto la riqueza de un proceso de software de una
organización como la consistencia con que se aplica en proyectos de toda la organización. También es el
grado de mejora continua que se realiza en un proceso respecto a un estado.
El grado con que el proceso está:
 Definido y documentado: En cada momento el proceso indica los pasos a seguir. Cuanto más
sabemos del proceso mejor será lo producido..
 Administrado y controlado: Se dispone de fondos, recursos, formación, etc. Se conocen los riegos y
se está preparado para ello.
 Medido y sea efectivo.

Madurez de un proceso de software.
Se refiere a un proceso específico que está explícitamente definido, administrado, medido, controlado, y es
efectivo.
 Organización inmadura: en donde los procesos de software generalmente se
improvisan, esto
incluye la posibilidad que, aún especificados los procesos, ellos no
se desarrollen en forma
rigurosa.
 Organización madura: Posee la habilidad en toda su organización para administrar
tanto
el
desarrollo como la manutención de proyectos.
Comparación de Madurez en las empresas.
Empresa INMADURA
Empresa MADURA
Apaga fuegos
Tiene procesos definido
Tiene pocos recursos propios
Tiene responsabilidades definidas
Tiene éxito gracias a los héroes
El conocimiento está en la organización
Hay altibajos en la productividad por rotación de Resultados predecibles
recursos
Entrega con la calidad esperada
Las planificaciones son poco realistas.
Cumple plazos de entrega
Mucho esfuerzo dedicado a “mantenimiento”
Incrementa la productividad
Los plazos de entrega son impredecibles
Reconocer las mejoras
Los empleados están descontentos
Satisface a los clientes
Los empleados están a gusto

Beneficios de la mejora de procesos.
Los siguientes son algunos de los beneficios y las razones de negocio para la ejecución del proceso de
mejora:
 La calidad de un sistema es altamente influenciada por la calidad del proceso utilizado para
adquirir, desarrollar y mantener.
 La mejora de procesos aumenta la calidad de los productos y servicios así como las organizaciones
que aplican esto para alcanzar sus objetivos de negocio.
 Los objetivos de la mejora de procesos están alineados con los objetivos de negocio.

Beneficios CMMI
La suite CMMI está a la vanguardia de la mejora del proceso, ya que proporciona una mezcla de las más
recientes prácticas para la mejora el desarrollo de productos, servicios y el mantenimiento. Con el CMMI
se permite a las organizaciones a hacer lo siguiente:
 La gestión y la ingeniería de las actividades están más explícitamente enlazadas para los objetivos
del negocio.
 Ampliar el alcance de la visibilidad y en el ciclo de vida del producto y de las actividades de
ingeniería para asegurar que el producto o servicio satisface las expectativas del cliente
 Incorporar la experiencia adquirida en otras zonas de las mejores prácticas (por ejemplo, la
medición, la gestión de riesgos, y gestión de proveedores)
 Aplicar prácticas de alta madurez más robustas.
 Dirección organizacional adicional de funciones críticas para sus productos y servicios.
 Cumplir lo más completamente con las normas ISO.


Modelos y Framework CMMI
Modelos de CMMI
Existen diferentes instancias del modelo CMMI, cada una de las cuales se enfoca en un determinado
conjunto de actividades. La siguiente es una lista de los modelos existentes en la actualidad.
■
Versión 1.1
CMMI-SE/SW/IPPD/SS
Este modelo incluye la ingeniería de sistemas, ingeniería de software, desarrollo integrado de productos y
procesos, y el abastecimiento de proveedor.
CMMI-SE/SW
Este modelo incluye la ingeniería de sistemas y la ingeniería de software.
CMMI-SE/SW/IPPD
Este modelo incluye la ingeniería de sistemas, ingeniería de software, y el desarrollo integrado de productos
y procesos.
CMMI-SW
Este modelo incluye la de software.
■
Versión 1,2
CMMI for Developed (CMMI-DEV) versión 1,2 es una actualización de CMMI-SE/SW/IPPD/SS, versión
1,1.
En la nueva versión, se incluye el concepto de constelaciones CMMI. Una constelación es un conjunto de
componentes CMMI diseñados para satisfacer las necesidades de un área específica de interés. Una
constelación puede producir uno o más modelos de CMMI y formas de evaluación y materiales de
capacitación relacionados. CMMI para el Desarrollo es la primera de estas constelaciones.
Figura 1. Constelaciones de CMMI v1.2

Framework CMMI
El framework CMMI es la estructura que organiza los componentes utilizados en la generación de modelos,
materiales de capacitación, y los métodos de evaluación.
El CMMI Product Suite es la colección completa de modelos, materiales de capacitación, evaluación y
métodos generados por el Framework de CMMI.
Los componentes en el marco CMMI se organizan en grupos, llamados constelaciones, que facilitan la
construcción de los modelos aprobados.
Durante el desarrollo de la versión v1.2, CMMI-SE/SW/IPPD/SS se trasladó a la constelación CMMI for
Developed (CMMI-DEV).
Dos nuevas constelaciones han sido encargados por el CMMI Steering Group
 CMMI para Servicios (CMMI – SVC)
 Adquisición de CMMI (CMMI - ACQ)


Breve Reseña de CMM
Historia
Antes de comenzar a describir el modelo propiamente dicho, hablaremos un poco de su historia y
nacimiento.
En su momento,el departamento de defensa de los estados unidos tenía muchos problemas con el software
que encargaba desarrollar a otras empresas, los presupuestos se disparaban, las fechas alargaban más y más.
Vale decir que estos problemas existen aun, principalmente en los casos donde no se utiliza un modelo de
mejora de Procesos.
Dado que esta situación les parecía intolerable convocó un comité de expertos para que solucionase estos
problemas, en el año 1983 dicho comité concluyó lo siguiente: "Tienen que crear un instituto de la
ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento
de Defensa".
Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que
explicar como van a resolver estos 4 problemas", se presentaron diversos estamentos y la Universidad
Carnegie Mellon ganó el concurso en 1985, creando el SEI.
El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM CMMI
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de
América, desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de
software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW-CMM
(CMM para Software), cuya última versión (v1.1) se publicó en febrero de 1993.
Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso
(KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de
ser:






Definidas en un procedimiento documentado
Provistas de los medios y formación necesarios
Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
Medidas
Verificada
Componentes de CMM.
Como sabemos el CMM es un marco de trabajo que describe los elementos claves de un proceso de
Software Efectivo, nos muestra un camino de mejora evolutivo desde un proceso inmaduro a un proceso
maduro y disciplinado. Para estos son descritas prácticas para la planificación, ingeniería y administración
del desarrollo y mantenimiento de Software.
Cuando las organizaciones se ciñen a estas prácticas se mejora la habilidad para cumplir las metas de
costos, planificación, funcionalidad y calidad del producto.
A
mostramos un
muestra los
del Modelo
forma
continuación
gráfico que
componentes
CMM de una
estructural:
Figura 2.Componentes Principales de CMM
 Niveles de Madurez: es una plataforma evolutiva bien definida con el propósito de lograr un
proceso de software maduro. Los cinco niveles proveen la estructura de más alto nivel de CMM.
 Capacidades del Proceso: las capacidades del proceso de software describen el rango de resultados
esperados que pueden ser logrados siguiendo un proceso de software. Las capacidades de procesos
de software de una organización proveen una forma de predecir fielmente las salidas esperadas del
próximo proyecto de software encarado por la organización.
 Áreas de Proceso Claves: cada una identifica una serie de actividades relacionadas, que cuando se
realizan colectivamente, logran un conjunto de objetivos considerados importantes para establecer
las Capacidades del Proceso en ese nivel de madurez. Las Áreas de Proceso Claves se diseñaron
para que residan en un sólo Nivel de Madurez. Por ejemplo: una de las Áreas Clave de Proceso para
el Nivel 2 es Planificación de Proyectos de Software.
 Características (Funciones) Comunes: las prácticas claves están divididas en cinco secciones de
características comunes: Requisitos a Realizar, Habilidad para Realizar, Actividades Realizadas,
Mediciones y Análisis, y Verificación de la Implementación. Las características comunes son
atributos que indican si la implementación y la institucionalización de un Área Clave de Proceso es
efectiva y repetible. Las Características Comunes de Actividades Realizadas describen las
actividades de implementación. Las otras cuatro describen los factores de institucionalización, que
hacen que un proceso sea parte de la cultura de la organización.
 Objetivos: resumen las prácticas claves de un Área de Proceso Clave, y pueden usarse para
determinar si una organización o proyecto ha implementado efectivamente un APC. Representan el
alcance, los límites, y la intención de cada APC. Por Ejemplo: un objetivo del APC Planificación de
Proyectos de Software es “Las estimaciones del software son documentadas para su uso en la
planificación y seguimiento del proyecto de software”.
 Prácticas Claves (PC): cada APC es descrito en términos de Prácticas Claves que, cuando son
implementadas, ayudan a satisfacer los objetivos de esa Área de Procesos Clave. Describen la
infraestructura y las actividades que contribuyen a una implementación e institucionalización
efectiva del APC. Ejemplo: una PC para el APC Planificación de Proyectos de Software es:”El plan
de desarrollo del proyecto de software es desarrollado de acuerdo a un procedimiento
documentado”.

Componentes de CMMI
Figura 4. Componentes de CMMI
Cómo modelo, CMMI tiene varios componentes que constituyen las herramientas mediante los cuales se
realiza la evaluación. Se describe a continuación, brevemente algunos d esos componentes, que se pueden
ver en la figura.

Área de proceso.
Conjunto de prácticas relacionadas que son ejecutadas de forma conjunta para conseguir un conjunto de
objetivos. En la siguiente sección revisamos estas áreas con mayor detalle.

Componentes Requeridos
 Objetivo genérico: Los objetivos genéricos asociados a un nivel de capacidad establecen lo que
una organización debe alcanzar en ese nivel de capacidad.
Ejemplo:
 Institucionalizar un proceso definido
 Institucionalizar un proceso gestionado
El logro de cada uno de esos objetivos en un área de proceso significa mejorar el control en la ejecución del
área de proceso
 Objetivo específico: Los objetivos específicos se aplican a una única área de proceso y localizan
las particularidades que describen que se debe implementar para satisfacer el propósito del área de
proceso.
Ejemplo:
 Registrar y controlar cambios
 Desarrollar requerimientos del cliente
 Desarrollar requerimientos del producto

Componentes Esperados
 Práctica genérica: Una práctica genérica se aplica a cualquier área de proceso porque puede
mejorar el funcionamiento y el control de cualquier proceso.
Ejemplo:
 Establecer una política organizacional
 Planear el proceso
 Entrenar al personal

Práctica específica: Una práctica específica es una actividad que se considera importante en la
realización del objetivo específico al cual está asociado.
Ejemplo:
 Identificar elementos de Interfases
 Establecer una definición de la funcionalidad requerida.
Las prácticas específicas describen las actividades esperadas para lograr la meta específica de un área de
proceso











Componentes Informativos
Propósito
Notas introductorias
Nombres
Tablas de relaciones práctica - objetivo
Prácticas
Productos típicos
Sub-prácticas: Una sub-práctica es una descripción detallada que sirve como guía para la
interpretación de una práctica genérica o especifica.
Ampliaciones de disciplina: Las ampliaciones contienen información relevante de una disciplina
particular y relacionada con una práctica especifica.
Elaboraciones de prácticas genéricas: Una elaboración de una práctica genérica es una guía de
cómo la práctica genérica debe aplicarse al área de proceso.
Representaciones de CMMI
La representación del modelo es un concepto que se relaciona con la estructura arquitectónica del mismo.
Una de las fuentes del modelo, CMM para Software (SW-CMM), utilizaba un modelo "escalonado". Otra
fuente, el Modelo de Capacidad de Ingeniería de sistemas (SE-CMM), en cambio utilizaba un modelo
"continuo". La tercera fuente, el Desarrollo Integrado de Productos (IPD-CMM), era "híbrido"
combinando los rasgos tanto del escalonado como del continuo.
El modelo para software (CMM-SW) establece 5 niveles de madurez para clasificar a las organizaciones, en
función de qué áreas de procesos consiguen sus objetivos y se gestionan con principios de ingeniería. A
esto se denomina un modelo escalonado, o centrado en la madurez de la organización.
El modelo para ingeniería de sistemas (SE-CMM), sin embargo, se establecen 6 niveles posibles de
capacidad para cada una de las 18 áreas de proceso implicadas en la ingeniería de sistemas. No agrupa los
procesos en 5 tramos para definir el nivel de madurez de la organización, sino que directamente analiza la
capacidad de cada proceso por separado. Es lo que se denomina un modelo continuo.
En el equipo de desarrollo de CMMI había defensores de ambos tipos de representaciones. El resultado fue
la publicación del modelo con dos representaciones: continua y escalonada. Son equivalentes, y cada
organización puede optar por adoptar la que se adapte a sus características y prioridades de mejora

Representación Escalonada.
Una representación escalonada proporciona un mapa predefinido a seguir para la mejora de la organización,
basada en la agrupación probada y el ordenamiento de procesos y relaciones de organización asociadas.
En esta representación, cada etapa del proceso de mejora se define como un nivel de madurez específico.
Cada nivel tiene su propio juego de áreas de proceso que indican donde debería enfocarse para mejorar el
proceso de la organización. Cada una de estas áreas es descrita en términos de las prácticas que contribuyen
a la satisfacción de sus objetivos. El progreso ocurre mediante la satisfacción de los objetivos de todo el
área de proceso en un nivel de madurez particular, antes de escalar al siguiente nivel.
Figura 5. Representación Escalonada
Las estimaciones sobre una representación escalonada, evalúa a la organización como un todo
determinando cuántas áreas de proceso han sido logradas, o sea, cuántos objetivos de dichas áreas han sido
logrados. En base a esto, se define en que nivel de madurez se encuentra la organización.

Representación Continua.
Esta representación proporciona una guía menos específica sobre el orden en el cual la mejora debería ser
lograda. Se le llama continuo porque ninguna de las etapas discretas son asociadas con la madurez de
organización.
Del mismo modo que en la representación escalonada, se tienen áreas de proceso y prácticas en cada área,
sin embargo, estas son organizadas de una manera que apoya el proceso individual y el crecimiento de
cada área. La mayor parte de las prácticas asociadas con la mejora de proceso son genéricas; son externos
al proceso individual de las áreas, y se aplican a todas las áreas de proceso. Las prácticas genéricas son
agrupadas en niveles de capacidad (CLs), cada uno de los cuales tiene una definición que es
aproximadamente equivalente a la definición de los niveles de madurez en un modelo organizado. Las
áreas de proceso son mejoradas e institucionalizadas mediante la puesta en práctica de las prácticas
genéricas en aquel área de proceso.
Figura 6. Representación Continua.
En el caso de la representación continua, las metas no se indican específicamente, lo que pone más énfasis
en las prácticas. El nivel de capacidad colectivo de todas las áreas de proceso, determina el mejoramiento
de la organización.
Entonces, en la evaluación de este modelo, cada área de proceso es calificada con su propio nivel de
capacidad. Entonces, la organización podría tener diferentes áreas de proceso con diferentes calificaciones.
De esta manera, una organización podría enfocarse más en lograr los objetivos de un área de proceso en el
cual necesita mejorar.

Las dos representaciones en CMMI.
En CMMI, se planteó el desafío de crear un modelo único que pueda ser visto desde dos perspectivas
diferentes, la continua y la escalonada. Esto significaba que ambas representaciones tenían que incluir la
misma información básica, o sea, una evaluación CMMI dirigida desde cualquier representación, debería
resultar en los mismos hallazgos, sin importar cual de las representaciones fue utilizado durante el proceso
de evaluación.
En la entrega inicial, sin embargo, el equipo del CMMI decidió no tener una representación única, aunque
esto no afectó la decisión de tener las mismas áreas de proceso en las dos representaciones, lo que
permitiría la mezcla y la transición a un modelo híbrido en el futuro.
En CMMI existen dos objetivos muy claros

Conservar los niveles de madurez por etapas para mantener la flexibilidad necesaria en muchas
organizaciones que tienen que adaptar sus procesos de mejora a sus metas de negocios y no
viceversa.

La transición de organizaciones del CMM v1.1 al CMMI debería ser tan fácil como fuera posible
para proteger las considerables inversiones hechas
De esta manera, CMMI tiene las dos representaciones para cumplir con estos objetivos y las 25 áreas de
proceso de CMMI-SE/SW/IPPD/SS se dividen en cuatro niveles de madurez en la representación
escalonada y en cuatro categorías de proceso en la representación continua.
Tabla 5.3.1. Agrupamiento escalonado.
Nivel Acrónimo (en inglés)
Área de Proceso.
2
REQM
PP
PMC
SAM
MA
PPQA
CM
Administración de Requerimientos.
Planeamiento de Proyectos
Monitoreo y control de proyecto.
Administración de acuerdo cliente/servidor
Mediciones y Análisis
Proceso y aseguramiento de la calidad
Administración de la configuración
3
RD
TS
PI
VER
VAL
OPF
OPD
OT
IPM
RSKM
IT
ISM
DAR
OEI
Desarrollo de requerimientos
Soluciones Técnicas
Integración de Producto
Verificación
Validación
enfoque en procesos de organización
Definición de los procesos organizacionales
Entrenamiento organizacional
Administración integrada de Proyecto
Administración de riesgos.
“Integrated Teaming”
Administración de proveedor integrado.
Resolución y análisis de decisión.
Ambiente organizacional para la integración
4
OPP Productividad de los proceso organizacionales.
QPM Administración cuantitativa del proyecto
5
OID Innovación y Desarrollo organizacional
CAR Resolución y análisis causales.
Tabla 5.3.2. Agrupamiento continuo.
Categorías
Acrónimo (inglés)
Administración
de Procesos
OPF
OPD
OT
OPP
OID
Administración
del Proyecto
PP
PMC
SAM
IPM
RSKM
IT
ISM
QPM
Ingeniería
Área de Proceso.
Enfoque en el proceso organizacional
Definición de proceso organizacional
Entrenamiento organizacional
Productividad de proceso organizacional
Innovación y Desarrollo organizacional
Planeamiento de Proyectos
Monitoreo y control de proyecto.
Administración de acuerdo cliente/servidor
Administración de proveedor integrado.
Administración de Riesgos
“Integrated Teaming”
Resolución y análisis de decisión
Administración cuantitativa del proyecto
REQM Administración de Requerimientos.
RD
TS
PI
VER
VAL
Soporte

CM
PPQA
MA
DAR
OEI
CAR
Desarrollo de Requerimientos
Soluciones Técnicas
Integración de Producto
Verificación
Validación
Administración de la configuración
Resolución y análisis causales.
Mediciones y Análisis
Resolución y análisis de decisión
Ambiente organizacional para la integración
Resolución y análisis causal.
Niveles de CMMI.
Figura 3.Niveles de CMM
CMMI, define la madurez de una organización con un determinado nivel. Los niveles de madurez de
CMMI son en esencia, heredados de su predecesor CMM.








Nivel 1: Inicial
Los procesos son habitualmente adhoc y caóticos
Estado inicial donde el desarrollo se basa en la heroicidad y responsabilidad de los individuos.
Los procedimientos son inexistentes o localizados en áreas concretas.
No existen plantillas definidas a nivel corporativo.
La organización no provee un ambiente estable.
Frecuentemente se exceden en el presupuesto y tiempo de sus proyectos.
Nivel 2: Gestionado
 Todos los “Objetivos Específicos y Genéricos” de todas las “Áreas de Proceso del Nivel 2 han sido
alcanzadas.
 Los proyectos son planificados, realizados, medidos y controlados.
 Se normalizan las buenas prácticas en el desarrollo de proyectos (en base a la experiencia y al





método).
En este nivel consolidado, las buenas prácticas se mantienen en los momentos de estrés.
Se definen hitos para la revisión de los productos.
El progreso del proyecto es visible por el Gerente en cada hito.
Los resultados son revisados con los participantes y son controlados.
Los resultados satisfacen los requerimientos especificados, estándares y objetivos.

Nivel 3: Definido
 Todos los objetivos específicos y genéricos de todas las Áreas de proceso de los niveles 2 y 3 han







sido alcanzadas.
Los procesos están caracterizados y comprendidos.
La organización entera participa en el proceso eficiente de proyecto software.
Se conoce de antemano los procesos de construcción de software.
Existen métodos y plantillas bien definidas y documentados.
Los procesos no solo afectan a los equipos de desarrollo sino a toda la organización relacionada.
Los proyectos se pueden definir cualitativamente.
El gerente de la organización define objetivos para los proyectos basados en el conjunto estándar de
procesos.
Obs.: Una diferencia crítica entre ambos es el alcance de descripciones de procesos, estándares
y procedimientos. Dado que en el nivel 3 los procesos son descritos más rigurosamente y con
mayor detalle.

Nivel 4: Cuantitativamente Gestionado
 Son establecidos objetivos cuantitativos para calidad y rendimiento de procesos utilizados como
criterio para la gestión de los procesos.
 Las medidas detalladas del rendimiento de los procesos son estadísticamente analizadas.
 Las estadísticas son almacenadas para aprovechar su aportación en siguientes proyectos.
 Son identificados motivos especiales para la variación de los procesos.
Obs.: En el nivel 4 el rendimiento de los procesos es cuantitativamente predecible, utilizando
técnicas estadísticas, mientras que en el nivel 3 son cualitativamente predecibles.

Nivel 5: Optimizado
 En base a criterios cuantitativos se pueden determinar las desviaciones más comunes y optimizar
procesos. En este nivel los procesos son continuamente mejorados sobre la base de una comprensión
cuantitativa.
 Se centra en una mejora continua por medio de mejoras tecnológicas tanto incrementales como de
innovación.
 En los siguientes proyectos se produce una reducción de costes gracias a la anticipación de
problemas y la continua revisión de procesos conflictivos.
Obs.: En el nivel 4 se busca establecer una predicción estadística de los resultados, analizando
causas especiales de variación, mientras que en el nivel 5 se busca establecer causas comunes de
variación y corregir la media de rendimiento de los procesos.

Áreas de Proceso.
Las áreas de proceso que ayudan a mejorar o evaluar CMMI son 22 en la versión que integra desarrollo de
software e ingeniería de sistemas (CMMI-SE/SW) y 25 en la que cubre también integración de producto
(CMMI-SE/SW/IPPD).
Vistas desde la representación continua del modelo, se agrupan en 4 categorías según su finalidad: Gestión
de proyectos, Ingeniería, Gestión de procesos y Soporte a las otras categorías.
Vistas desde la representación escalonada, se clasifican en los 5 niveles de madurez. Al nivel de madurez 2
pertenecen las áreas de proceso cuyos objetivos deben lograr la organización para alcanzarlo, ídem con el
3, 4 y 5 .
Tabla7.1. Áreas de proceso de CMMI sintetizados.
Área de proceso
Categoría
Nivel de madurez
Análisis y resolución de problemas
5
Soporte
Gestión de la configuración
Análisis y resolución de decisiones
Soporte
Soporte
Gestión integral de proyecto
Gestión integral de proveedores
Gestión de proyectos 3
Gestión de proyectos 3
Gestión de equipos
Gestión de proyectos 3
Medición y análisis
Entorno organizativo para integración
Soporte
Soporte
2
3
Innovación y desarrollo
Gestión de procesos
5
Definición de procesos
Procesos orientados a la organización
Gestión de procesos
Gestión de procesos
3
3
Rendimiento de los procesos de la Org. Gestión de procesos
Formación
Gestión de procesos
4
3
Integración de producto
Ingeniería
3
Monitoreo y control de proyecto
Planificación de proyecto
Gestión de proyectos 2
Gestión de proyectos 2
Gestión calidad procesos y productos
Gestión cuantitativa de proyectos
Soporte
2
Gestión de proyectos 4
Desarrollo de requisitos
Ingeniería
Gestión de requisitos
Gestión de riesgos
Ingeniería
2
Gestión de proyectos 3
Gestión y acuerdo con proveedores
Solución técnica
Gestión de proyectos 2
Ingeniería
3
Validación
Ingeniería
3
Verificación
Ingeniería
3

2
3
3
¿Cómo llegar al nivel 2?
El nivel 1 de CMMI es el nivel en el que están todas las empresas, más bien tendrían que haberle llamado
nivel 0, ya que solo por el mero hecho de existir como empresa de software uno se encuentra en el nivel 1.
Por lo tanto todas aquellas empresas que quieren implantar CMM-CMMI o tan sólo quieren mejorar su
manera de trabajar para conseguir mejores resultados quieren avanzar hasta el nivel 2.
El nivel 2 de CMMI pese al ser el primer nivel es muchas veces el más difícil de alcanzar y esto es porque
requiere que cambiemos la forma de trabajar de la empresa, lo que la mayoría de las veces implica un
cambio cultural de la misma. Por este motivo es necesario un fuerte apoyo de la dirección para afrontar este
cambio, ya que sin él no se tiene suficiente autoridad en momentos difíciles, resumiendo: No se debe
intentar alcanzar el CMM-CMMI nivel 2 sin un firme apoyo de la dirección.
En la sección de las áreas de proceso, nos limitamos a citar los mismos. Sin embargo, cada nivel tiene áreas
de proceso, para los cuales se tienen prácticas y metas asociadas que no se trataran extensivamente en el
presente trabajo de investigación, a excepción de los Niveles 2 y 3.

Nivel 2 de CMMI.
Para llegar a este nivel de CMMI, se deben implantar los siguientes procesos dentro de la empresa:

Gestión de Requisitos.

Planificación del proyecto

Seguimiento y control del proyecto




Gestión de acuerdos con proveedores
Medida y análisis
Medidas de calidad en el proceso y el producto
Gestión de configuración
Antes de continuar, daremos significado a algunas siglas:

SG: Meta Específica

GG: Meta Global

SP: Práctica Específica

GP: Práctica Global
Además, la consecución de las metas específicas de cada nivel implica conseguir alguna de las siguientes
metas globales que detallamos a continuación. De ahora en adelante nos referiremos a ellas por el número
(GG n(nivel)):

GG 2: Institucionalizar un proceso gestionado

GP 2.1: Establecer las políticas de la organización

GP 2.2: Planificar los procesos

GP 2.3: Proporcionar los recursos adecuados

GP 2.4: Asignar las responsabilidades

GP 2.5: Formar al personal

GP 2.6: Gestionar la configuración

GP 2.7: Identificar los actores importantes

GP 2.8: Monitorear y controlar los procesos

GP 2.9: Evaluar objetivamente el cumplimiento

GP 2.10: Revisar el proyecto con los responsables de mayor nivel
■
Planificación del proyecto
El objetivo de este proceso es establecer y mantener planes que definan las actividades a realizar en el
proyecto, y en base a las mismas, establecer el presupuesto y los cronogramas del proyecto. A continuación
se desglosan las metas a conseguir con este proceso, y las prácticas que se requieren para conseguir estas
metas:
SG 1. Establecer estimaciones. Para ello hay que:

SP 1.1. Estimar el alcance del proyecto (relación de tareas).

SP 1.2. Realizar estimaciones de los productos de trabajo y atributos de las tareas (tamaño en
puntos función, líneas de código, etc).

SP 1.3. Definir el ciclo de vida del proyecto (diferentes fases del proyecto).

SP 1.4. Realizar estimaciones de esfuerzo y coste.
SG 2. Desarrollar el plan de proyecto – un documento formal que se utilizará para manejar y controlar la
ejecución del proyecto. Este documento estará basado en los requisitos del proyecto y en las estimaciones
anteriores. Para conseguir esta meta hay que:

SP 2.1. Establecer el presupuesto y calendario del proyecto.

SP 2.2. Identificar los riesgos del proyecto.

SP 2.3. Definir un plan para administrar los datos, entendiendo por datos cualquier documentación
requerida para soportar un programa en cualquiera de sus facetas (administración, control de
cambios, logística, etc)

SP 2.4. Definir un plan para administrar los recursos, entendiendo por recurso una máquina,
materiales, métodos, etc.

SP 2.5. Definir un plan para administrar los conocimientos y habilidades.

SP 2.6. Definir un plan para involucrar a los interesados.

SP 2.7. Establecer el Plan General del proyecto.
SG 3. Obtener un compromiso para realizar el plan – Se establecen y mantienen compromisos con todos
los involucrados en el proyecto con las actividades definidas en el Plan de proyecto. Para conseguir esta
meta hay que realizar las siguientes prácticas:

SP 3.1. Revisar los planes que afectan al proyecto (con los involucrados).


SP 3.2. Reconciliar el trabajo y el nivel de los recursos.
SP 3.3. Conseguir el compromiso de los involucrados con el Plan de proyecto.
Con estas metas específicas se consigue la meta global GG 2.
■
Seguimiento y control del proyecto
El objetivo de este proceso es controlar el progreso del proyecto de forma que se puedan tomar acciones
correctivas apropiadas cuando el progreso del proyecto se desvía significativamente del plan. Se cumple
con el seguimiento y control de proyectos si se cumple con las siguientes prácticas:
SG 1. Monitorizar el proyecto de acuerdo con el Plan. Para ello hay que:
 SP 1.1. Monitorizar los parámetros del Plan de proyecto (% de avance, fechas reales vs fechas
estimadas, número de requerimientos atendidos vs los planeados, etc).
 SP 1.2. Monitorizar los compromisos.
 SP 1.3. Monitorizar los riesgos.
 SP 1.4. Monitorizar Plan de administración de datos (que los datos existan y estén
almacenados en el lugar correcto).
 SP 1.5. Monitorizar de la involucración de los interesados .
 SP 1.6. Realizar revisiones del progreso del proyecto (avance del mismo).
 SP 1.7. Realizar revisiones de los hitos del proyecto.
SG 2. Administrar acciones correctivas a tomar – Se realizan acciones correctivas cuando los resultados
que se van obteniendo en el proyecto se desvían significativamente del Plan inicial. Para ello hay que:
 SP 2.1. Analizar los problemas.
 SP 2.2. Tomar acciones correctivas.
 SP 2.3. Administrar las acciones correctivas.
Con estas metas específicas se consigue la meta global GG 2.
■
Gestión de acuerdos con proveedores
El objetivo de este proceso es controlar la adquisición de productos proporcionados por los proveedores con
los cuales existe un acuerdo formal. Este proceso se cumple si se cumplen las siguientes prácticas:
SG 1. Establecer acuerdos con proveedores. Para ello hay que:
 SP 1.1. Determinar el tipo de adquisición.
 SP 1.2. Seleccionar proveedores.
 SP 1.3. Establecer acuerdos con proveedores.
SG 2. Satisfacer los acuerdos con proveedores. Para ello hay que:
 SP 2.1. Revisar los productos comerciales ya hechos (COTS Products, Comercial off-the-shell
Products, en contraposición a productos realizados a medida).
 SP 2.2. Ejecutar los acuerdos con los proveedores.
 SP 2.3. Aceptar el productor adquirido.
 SP 2.4. Efectuar la transición de productos.
Con estas metas específicas se consigue la meta global GG 2.
■
Medidas y análisis
El propósito de este proceso es desarrollar y mantener la capacidad de tomar mediciones para atender las
necesidades de información de cómo va el proyecto. Se cumple con este proceso si se cumple con las
siguientes prácticas:
SG 1. Alinear actividades de medición y análisis con los objetivos y las necesidades de información. Para
ello hay que:
 SP 1.1. Definir cuales van a ser los objetivos de la medición.
 SP 1.2. Especificar medidas (métricas básicas, número de requerimientos, esfuerzo esperado
en la corrección de errores).
 SP 1.3. Establecer procedimientos de recolección de datos y almacenamiento de los mismos.
 SP 1.4. Establecer el procedimiento de análisis.
SG 2. Proporcionar resultados de las mediciones
 SP 2.1. Guardar las mediciones.
 SP 2.2. Analizar las mediciones (para ver si los datos obtenidos son correctos).
 SP 2.3. Almacenar los datos y resultados obtenidos (métricas básicas y calculadas).
 SP 2.4. Comunicar los resultados del proceso a los involucrados.
Con estas metas específicas se consigue la meta global GG 2.
■
Medidas de calidad en el proceso y en el producto
El objetivo de este proceso es proporcionar personal cuyo objetivo sea profundizar en el proceso y en los
productos de trabajo asociados. Se cumple con este proceso si se cumple con las siguientes prácticas:
SG 1. Evaluar objetivamente procesos y productos de trabajo. Para ello hay que:
 SP 1.1. Evaluar objetivamente los procesos.
 SP 1.2. Evaluar objetivamente los productos de trabajo y servicios.
SG 2. Proporcionar comunicación interna objetiva. Para ello hay que:
 SP 2.1. Comunicar las no conformidades y asegurar su resolución.
 SP 2.2. Establecer y mantener registro de actividades.
Con estas metas específicas se consigue la meta global GG 2.
■
Gestión de la configuración
El propósito de este proceso es establecer y mantener la integridad de los productos de trabajo manteniendo
un control de sus versiones, lo que implica mantener una identificación, control y auditoria de cada versión.
Se cumple con este proceso si se cumple con las siguientes prácticas:
SG 1. Establecer líneas base. Para ello hay que:
 SP 1.1. Identificar cada componente susceptible de ser versionado.
 SP 1.2. Establecer y mantener un sistema de administración de la configuración.
 SP 1.3. Crear líneas base (para uso interno o para entregar al cliente).
SG 2. Seguimiento y control de cambios. Para cumplir con esta meta hay que:
 SP 2.1. Monitorizar los requisitos de cambio.
 SP 2.2. Controlar los componentes que han cambiado.
SG 3. Establecer la integridad
 SP 3.1. Establecer y mantiene registros describiendo cada iteración de la configuración.
 SP 3.2. Ejecutar auditorias a la configuración para mantener la integridad.
Con estas metas específicas se consigue la meta global GG 2.

Nivel 3 de CMMI.
Dando un pincelazo al nivel 3, podemos decir que alcanzar este nivel significa que la forma de desarrollar
proyectos está definida, es decir, está establecida, documentada, y existen métricas (obtención de datos
objetivos) para la consecución de objetivos concretos. Los procesos que hay que implantar para alcanzar
este nivel son:
 Gestión de requisitos
 Solución técnica
 Integración del producto
 Verificación
 Validación





■
Metas Globales




■
Enfoque organizacional del proceso
Definición del proceso de la organización
Formación en la organización
Gestión de riesgos
Análisis de decisiones y resolución
GG 3: Institucionalizar un proceso definido
GG 2: Institucionalizar un proceso gestionado
GP 3.1: Establecer procesos definidos
GP 3.2: Recuperar información para la mejora
Gestión de requisitos.
El objetivo de este proceso es generar y analizar requisitos de clientes, del producto a desarrollar y de sus
componentes. A continuación se desglosan las metas a conseguir con este proceso, y las prácticas que se
requieren para conseguir estas metas:
SG 1. Desarrollar los requisitos del cliente. Para ello hay que:
 SP 1.1. Obtener las necesidades de los participantes.
 SP 1.2. Desarrollar los requisitos de los clientes.
SG 2. Desarrollar los requisitos del Producto. Para ello hay que:
 SP 2.1. Establecer los requisitos del producto y componentes que integran el producto.
 SP 2.2. Asignar los requisitos a cada componente.
 SP 2.3. Identificar los requisitos de interfaces.
SG 3. Analizar y validar los requisitos. Para ello hay que:
 SP 3.1. Establecer y mantener los conceptos operacionales y escenarios asociados.
 SP 3.2. Establecer y mantener una definición de la funcionalidad requerida.
 SP 3.3. Analizar los requisitos.
 SP 3.4. Analizar los requisitos para ver su alcance.
 SP 3.5. Validar los requisitos con métodos que sean entendibles.
Con estas metas específicas se consiguen la meta global GG 3.
■
Solución técnica
El propósito de este proceso es desarrollar e implementar soluciones a los requisitos; las soluciones, diseños
e implementaciones abarcan productos, componentes del producto y ciclos de vida asociados al producto.
Se cumple con la solución técnica si se cumple con las siguientes metas específicas:
SG 1. Seleccionar soluciones para los componentes del producto
 SP 1.1. Desarrollar alternativas detalladas y criterios de selección (costos, rendimiento técnico,
complejidad, limitaciones tecnológicas, riesgos, facilidad de uso, etc).
 SP 1.2. Evolucionar conceptos operacionales y escenarios (modo de operación, estado de la
operación para cada componente).
 SP 1.3. Seleccionar soluciones para los componentes del producto.
SG 2. Crear el diseño. Para ello hay que:
 SP 2.1. Diseñar el producto o los componentes del producto (diseño detallado).
 SP 2.2. Establecer un paquete de datos técnicos (conjunto de especificaciones de un paquete).
 SP 2.3. Diseñar interfaces utilizando criterios.
 SP 2.4. Realizar los análisis de construcción, compra o reutilización.
SG 3. Implementar el diseño del producto. Para ello hay que:
 SP 3.1. Implementar el diseño (codificación, re-usabilidad de código, pruebas unitarias).
 SP 3.2. Desarrollar la documentación de soporte del producto.
■
Integración del producto
El propósito es integrar el producto a partir de sus componentes, asegurar que el producto (como parte de la
integración) funciona correctamente, y entregar el producto. Se debe cumplir con las siguientes prácticas
específicas:
SG 1. Preparar la integración del producto:
 SP 1.1. Determinar la secuencia de integración.
 SP 1.2. Establecer el entorno de integración del producto.
 SP 1.3. Establecer los criterios y procedimientos de integración del producto.
SG 2. Asegurar la compatibilidad de las interfaces:
 SP 2.1. Revisar la completitud de las revisiones de las interfaces.
 SP 2.2. Administrar las interfaces.
SG 3. Integrar los componentes del producto y entregar el producto:
 SP 3.1. Confirmar que los componentes del producto están listos para la integración.
 SP 3.2. Integrar los componentes del producto.
 SP 3.3. Evaluar las integraciones de los componentes del producto ya integrados.
 SP 3.4. Empaquetar y entregar el producto o componente.
■
Verificación
El propósito es asegurar que los productos de trabajo seleccionados responden a los requerimientos
especificados. A continuación se desglosan las metas a conseguir con este proceso, y las prácticas que se
requieren para conseguir estas metas:
SG 1. Preparar la verificación
 SP 1.1. Seleccionar los productos de trabajo para la verificación
 SP 1.2. Establecer el entorno de verificación.
 SP 1.3. Establecer los procedimientos y criterios de verificación.
SG 2. Realizar revisiones por terceros
 SP 2.1. Preparar revisiones por terceros.
 SP 2.2. Realizar revisiones por terceros.
 SP 2.3. Analizar resultados de revisiones por terceros.
SG 3 Verificar los productos de trabajo seleccionados
 SP 3.1. Realizar la verificación.
 SP 3.2. Analizar los resultados de la verificación e identificar las acciones correctivas.
■
Validación
El propósito es demostrar que un producto o componente satisface su uso pretendido, en el ambiente
operativo planeado. A continuación se desglosan las metas a conseguir con este proceso, y las prácticas que
se requieren para conseguir estas metas:
SG 1. Preparar la validación.
 SP 1.1. Seleccionar los productos a validar.
 SP 1.2. Establecer el entorno de validación.
 SP 1.3. Establecer los procedimientos y criterios de validación.
SG 2. Validar los productos o componentes de los productos.
 SP 2.1. Realizar la validación.
 SP 2.2. Analizar los resultados de la validación.
■
Enfoque organizacional del proceso
SG 1. Determinar las oportunidades de mejora del proceso.
 SP 1.1. Establecer las necesidades organizacionales del proceso.
 SP 1.2. Evaluar los procesos de la organización.
 SP 1.3. Identificar mejoras en los procesos de la organización.
SG 2. Planificar e implementar las actividades de mejora de los procesos.
 SP 2.1. Establecer los planes de acción para los procesos.
 SP 2.2. Implementar los planes de acción para los procesos.
 SP 2.3. Desplegar recursos organizacionales para el proceso.
 SP 2.4. Incluir experiencias relacionadas con el proceso organizacional.
■
Definición del proceso de la organización
El objetivo de este proceso es establecer y mantener un conjunto utilizable de recursos organizacionales del
proceso. A continuación se desglosan las metas a conseguir con este proceso, y las prácticas que se
requieren para conseguir estas metas:
SG 1. Establecer los recursos organizacionales del proceso.
 SP 1.1. Establecer procesos estándar.
 SP 1.2. Establecer descripciones del modelo de ciclo de vida.
 SP 1.3. Establecer criterios y líneas generales de adaptación.
 SP 1.4. Establecer un almacén de medidas de la organización.
 SP 1.5. Establecer la librería de recursos del proceso a nivel organizacional.
■
Formación en la organización
El propósito de este proceso es desarrollar las habilidades y conocimientos de las personas para que puedan
desarrollar sus roles de forma eficiente.
SG 1. Habilitar a la organización para formar a su personal.
 SP 1.1. Establecer las necesidades estratégicas de formación.
 SP 1.2. Determinar qué necesidades de formación son responsabilidad de la organización.
 SP 1.3. Establecer un plan táctico de formación para la organización.
 SP 1.4. Establecer la capacidad de formación.
SG 2. Proporcionar la formación necesaria.
 SP 2.1. Dar la formación
 SP 2.2. Establecer registros de formación.
 SP 2.3. Determinar la efectividad de la formación.
■
Gestión de riesgos
El objetivo de la gestión de riesgos es identificar problemas potenciales antes de que ocurran, de forma que
las actividades asociadas a ese manejo de riesgos se puedan planificar y realizar según se necesiten a lo
largo de la vida del producto o proyecto para mitigar impactos adversos para la consecución de los
objetivos. A continuación se desglosan las metas a conseguir con este proceso, y las prácticas que se
requieren para conseguir estas metas:
SG 1. Preparar la gestión de riesgos
 SP 1.1. Determinar los orígenes y categorías de los riesgos.
 SP 1.2. Definir los parámetros de los riesgos.
 SP 1.3. Establecer una estrategia de gestión de riesgos.
SG 2. Identificar y analizar los riesgos
 SP 2.1. Identificar riesgos.
 SP 2.2. Evaluar, categorizar y priorizar riesgos.
SG 3. Mitigar riesgos
 SP 3.1. Desarrollar planes para reducir los riesgos.
 SP 3.2. Implementar los planes de reducción de riesgos.
■
Análisis de decisiones y resolución
El objetivo del análisis de decisiones y la resolución es analizar las posibles decisiones utilizando un
proceso formal de evaluación que evalúe las alternativas identificadas en base a criterios establecidos. A
continuación se desglosan las metas a conseguir con este proceso, y las prácticas que se requieren para
conseguir estas metas:
SG 1. Evaluar alternativas
 SP 1.1. Establecer las líneas maestras para el análisis de toma de decisiones.
 SP 1.2. Establecer los criterios de evaluación.
 SP 1.3. Identificar soluciones alternativas.
 SP 1.4. Seleccionar métodos de evaluación.
 SP 1.5. Evaluar alternativas.
 SP 1.6. Seleccionar soluciones.

Ventajas y Desventajas de CMMI.
Ventajas Generales

El Principal beneficios se relaciona a la mejora de procesos. Esta mejora genera lo siguiente:
La calidad de un sistema es altamente influenciada por la calidad del proceso utilizado para
adquirir, desarrollar y mantener.

La mejora de procesos aumenta la calidad de los productos y servicios así como las
organizaciones que aplican esto para alcanzar sus objetivos de negocio.

Los objetivos de la mejora de procesos están alineados con los objetivos de negocio.
La gestión y la ingeniería de las actividades están más explícitamente enlazadas para los objetivos
del negocio.
Ampliar el alcance de la visibilidad y en el ciclo de vida del producto y de las actividades de
ingeniería para asegurar que el producto o servicio satisface las expectativas del cliente
Incorporar la experiencia adquirida en otras zonas de las mejores prácticas.
Aplicar prácticas de alta madurez más robustas, ya que el modelo trata de convivir con estas
prácticas.
Dirección organizacional adicional de funciones críticas para sus productos y servicios.
Cumplir lo más completamente con las normas ISO.







Desventajas Generales

La implantación de un modelo de estas características es un proceso largo y costoso que puede
costar varios años de esfuerzo. Aun así el beneficio obtenido para la empresa es mucho mayor que lo
invertido.
Comparación con el Modelo ITIL
ITIL se centra en ofrecer servicios de alta calidad, partiendo de un enfoque estratégico basado en el
triángulo procesos-personas-tecnología. A partir de este modelo se ofrece un método probado para
gestionar procesos, roles y actividades, así como sus interrelaciones. Puede utilizarse en organizaciones que
ya tengan sus propios métodos y actividades de Gestión de Servicios, independientemente de su tamaño.
La principal ventaja de ITIL es que ha demostrado su eficacia con su enfoque a la gestión de servicios de
TI. Esto significa:
1. Mayor alineamiento de TI con el negocio / enfoque a cliente.
2. Resolución de incidencias y problemas más rápida y eficiente.
3. Reducción del número de llamadas al Service Desk.
4. Aumento del ratio de resolución de incidencias en primera instancia.
5. Implantación de cambios más rápida / mejor control de cambios.
6. Reducción del número de cambios que necesiten ser revocados.
7. Efectiva Gestión de la Capacidad.
8. Mejor control de activos
El gran problema de ITIL es que no cubre adecuadamente las fases de desarrollo de software ni la gestión
de proyectos asociada a esa fase de construcción de activos software.
Analizando ambos modelos, podemos observar que CMMI se centra en garantizar la calidad en el
desarrollo de software mientras que ITIL garantiza la explotación del producto software. Por ello, muchas
empresas consideran que ambas metodologías no son excluyentes, sino complementarias.
Comparación con el Modelo SIX SIGMA
Six Sigma tiene como finalidad identificar y remover las causas de defectos y errores en los procesos de
negocios y manufacturación. Utiliza un conjunto de métodos de administración de calidad, incluyendo
métodos estadísticos, y creando una infraestructura especial de personas en la organización quienes son
expertos en estos métodos. Cada Proyecto Six Sigma llevado a cabo en una organización sigue una
secuencia definida de pasos y tiene cuantificadores de objetivos financieros (reducción de costos o aumento
de ganancias).
Analizando ambos modelos, podemos observar que CMMI se centra en resolver los ¿Qué? del problema; y
por otro lado, SIX SIGMA se centra en resolver los ¿Cómo?. Esto indica que CMMI trata de identificar las
causas (que genera problemas y que debo hacer), y SIX SIGMA es más práctico y especifico, ya que trata
de identificar directamente la forma para solucionar los problemas (como soluciono los problemas).
Es importante mencionar que en conjunto pueden ayudar a las organizaciones mejorar sus ubicaciones en el
mercado, competitividad y lograr metas del negocio más rápidamente.
Comparación con el Modelo ISO 9001:2000
La norma ISO 9001:2000 está estructurada en ocho capítulos, refiriéndose los cuatro primeros a
declaraciones de principios, estructura y descripción de la empresa, requisitos generales, etc., es decir, son
de carácter introductorio. Los capítulos cinco a ocho están orientados a procesos y en ellos se agrupan los
requisitos para la implantación del sistema de calidad.
Algunas de las características que CMMI abarca pero ISO pasa por alto, o simplemente no lo menciona
son:

Institucionalización. CMMI insiste en el hecho que los procesos deben ser parte del negocio, de tal
forma que se vuelvan parte de la cultura organizacional.

Enfoque en Entrenamiento Organizacional. CMMI tiene un área separada para manejar el
entrenamiento, ya que es parte esencial de la evolución de la empresa.

Mantener Librerías de procesos valiosos. Todas las documentaciones donde se definen los
procesos, políticas, planes, materiales de entrenamiento, etc.; son parte importante del valor de la
empresa.

Disciplina de Administración de Riesgos. CMMI tiene maneras de identificar de forma
disciplinada los posibles riesgos que se pueden presentar.

Concepto del Inversionista (stakeholder). En CMMI el concepto de stakeholder es más amplio, al
incluirle a los responsables o encargados del proyecto.
Estas características muestran como CMMI tiene un concepto más amplio que ISO. Sin embargo, esto no
hace que las prácticas de ISO incorrecto, solo son más específicas, y en todo caso, se deben utilizar varias
normas de ISO para tratar de abarcar lo de CMMI.

Empresas Relacionadas.
Empresas Con Nivel de Madurez 5 del año 2008
Como se puede observar en la página web del SEI, existen muchas empresas que adquieren la certificación
de CMMI en sus distintos niveles. Por ejemplo, se pueden ver en la Figura 10 algunas de las empresas
certificadas en nivel 5 durante el 2008.
Empresas y Unidades de Procesos
Accenture -Accenture India Delivery Center.
Accenture Technology Solutions - Coritel Spain Delivery Centre (SDC).
W&C, Products & Nokia-Siemens Business units in Aricent India
BAE Systems - BAE Systems: Ground Systems
Air, Missile, and National Defense (AMND) Development Engineering (DE) a
part of Computer Sciences Corporation (CSC), North American Public Sector
(NPS), Defense Division
General Dynamics C4 Systems – Mass
Hewlett Packard GDAS India Center
Hexaware Technologies Limited - Mumbai and Chennai Centres
iGATE Global Solutions Offshore SW Development
Infosys Technologies Australia Pty Ltd
Fecha de
Certificación
Aug 29, 2008
Jul 18, 2008
Sep 05, 2008
Oct 03, 2008
May 09, 2008
Mar
Mar
Mar
Aug
Sep
07,
19,
31,
29,
10,
2008
2008
2008
2008
2008
Figura 10. Algunas Empresas con Nivel de Madurez 5 del año 2008.
Empresas en Paraguay
Las empresas paraguayas Century System, Inventiva AP, Optimiza, Excelsis, Grupo Interactiva, Netvision
e ITH iniciaron las acciones tendientes a obtener la acreditación Capability Maturity Model Integration o
CMMI, como se puede ver en la página Web de la Cámara de Tecnología de la Información del Paraguay.
En la actualidad ninguna empresa paraguaya tiene certificación CMMI.
Por otro lado, existen empresas consultoras internacionales presentes en el país que buscan desarrolladores
con experiencia en CMMI.
Empresas en Otros Países
Chile tiene una página Web donde se listan las empresas chilenas con certificación CMMI, por otro lado
Argentina y Brasil más bien son esfuerzos individuales para mostrar las empresas con certificación CMMI.
Según el reporte de semestral de SEI, Argentina se encuentra en el puesto 12, en segundo lugar
deLatinoamérica, el cual está liderado por Brasil, en cuanto a certificaciones CMMI se refiere.
Acerca de Argentina, durante los últimos seis meses pasó de 26 a 46 empresas con niveles de madurez.
Además, se reportaron 31 evaluaciones de nivel 2, 10 de nivel 3, 2 de nivel 4 y 3 de nivel 5. Del dato se
deduce que las empresas no se quedan en nivel 2, sino que siguen realizando evaluaciones hacia los niveles
de madurez superiores.
La lista siguiente en la Figura 11, es proveída por la Red Chilena para el mejoramiento del proceso de
Software.
N°
Empresa
Modelo
Nivel
Fecha
01
Altec Chile – Procesos de Proyectos
SW-CMMI
3
Dic-2006
02
03
04
05
06
Altec Chile – Procesos de Mantenimiento
SONDA Sistemas Financieros
Adexus
TUXPAN Software S.A.
LAN Airlines S.A.
SW-CMMI
SW-CMMI
SW-CMMI
SW-CMMI
SW-CMMI
5
3
2
3
2
Dic-2005
Jun-2005
Abr-2005
Mar-2005
Mar-2004
Figura 11. Evaluaciones CMMI en Chile.
Finalmente, en la página www.calidaddelsoftware.com se puede ver un listado no oficial de empresas con
certificación CMM/CMMI en España. Existen un par de Empresas con niveles de Madurez 5, pero en su
mayoría se encuentran con un nivel 3.

CONCLUSIONES
Luego de todo lo expuesto en este trabajo, llega la hora de dar a conocer conclusiones importantes a las que
llegamos durante la elaboración de este trabajo.
Muchos podrían pensar o preguntarse, ¿Por qué centrarme en los Procesos? Por todo lo expuesto podemos
deberíamos ser capaces de ver como nos ayuda un modelo de procesos, sin embargo, aun existen falsas
creencias que debemos dejar de lado, como las que citamos a continuación:
 No necesito procesos, porque tengo…



Muy buenas personas.
Tecnología avanzada
Un gerente experimentado
Y además se suele pensar algunas cosas sobre el proceso que no son así, como por ejemplo:
 Interfiere con la creatividad del equipo.
 Introduce burocracia y reglamentaciones.
 No son necesarios cuando se construyen prototipos.
 Son útiles solamente en proyectos de gran envergadura.
 Nos quita agilidad en un mercado muy cambiante.
 Cuesta demasiado (aunque esto no es tan falso).
En cuanto a esas creencias, podemos decir que los procesos complementan los recursos con los que cuenta
una empresa y trato de utilizarlos de la manera más eficiente posible, así como lo propone el CMMI.
Podemos decir que un modelo de procesos complementa el enfoque sobre las personas dado que:
 Le experiencia y entrenamiento de la fuerza de trabajo no siempre es suficiente.
 El trabajo duro no es la respuesta.
 Un proceso bien definido puede proveer la forma mas inteligente de trabajar y de ahorrar recursos.
 Cambia el enfoque de los problemas de las personas a los problemas de los procesos.
Además decimos que complementa el enfoque sobre la tecnología por lo siguiente:
 La tecnología por si sola no precisamente será bien utilizada.
 La tecnología, en el contexto de una planificación de procesos apropiada, podrá proveer el
máximo beneficio.
Para los que quedan aun un tanto escépticos con respecto al CMMI, podemos dar ciertos datos estadísticos
que muestran que CMMI funciona:
 Reduce costos en un 20% en promedio
 Reduce tiempos en un 37% en promedio
 Aumenta la productividad en un 62% en promedio.
 Aumenta la calidad en un 50%.
 Satisfacción del cliente en un 14%.
Para ir finalizando podemos decir que CMMI logra sus objetivos dado que se concentra en reducir el costo
de “No Calidad”, estos son los costos por retrasos en corrección de defectos, aplicación de garantías a
clientes, devolución de productos, litigios, etc. Y obviamente al reducir esto se aumenta la satisfacción del
cliente y también la productividad y rentabilidad. Además de esto vale recabar en que CMMI apoya
completamente estrategias de Fabrica/Maquila de Software, que es lo que se conoce como una estrategia de
“Excelencia Operacional” que puede atraer inversionistas al País.

FUENTES

CMMI® Distilled: A Practical Introduction to Integrated Process
Improvement, Second Edition, Dennis M. Ahern, Aaron Clouse, Richard Turner.


Definiciones y conceptos fundamentales del modelo
CMMI. Referencias y explicaciones de los diversos elementos del modelo.
http://www.sei.cmu.edu/cmmi/general/index.html

Página oficial de CMMI. Verificamos en este sitio la
información de nuestras demás fuentes.

Capability Maturity Model® Integration (CMMI®) Version 1.2
Overview. Software Engineering Institute (SEI). Carnegie Mellon University. 2007.

NOTAS DE SEMINARIO: “Introducción a las Metodologías Ágiles
y la Madurez del Proceso de Software”. MSc. Guillermo González. Presentado durante la Etyc
2006.

Algunas imágenes y listados son más concisos.

http://www.spin-chile.cl/

Sitio de la Red Chilena para el Mejoramiento del
software. Con ontiene una lista actualizada de las empresas evaluadas en Chile junto con
el respectivo nivel alcanzado.

http://es.wikipedia.org/wiki/CMMI

Comentarios adicionales sobre algunos puntos.

http://www.ingenierosoftware.com/calidad/cmm-cmmi.php

Informaciones complementarias sobre las áreas de
proceso y otros temas.

http://www.softwaresantafe.com/noticias/ssf_6_03.htm


Información sobre experiencia CMMI en Argentina.
Process Maturity Profile CMMI® v1.1 SCAMPISM v1.1 Class A
Appraisal Results 2005 End-Year Update. Software Engineering Institute. Carnegie Mellon
University. March 2006

Informe del SEI sobre el estado actual de CMMI.

http://www.rumbosdelperu.com/rumboscolombia_lider_software.htm

Casos de éxito en Colombia.
Empresas relacionadas a CMMI.

http://www.ctip.org.py/v2/2008/06/empresas-del-gremio-encapacitacion-para-cmmi/

Contiene datos sobre las primeras iniciativas de
empresas paraguayas para obtener capacitación CMMI.

http://www.spin-chile.cl/

Sitio de la Red Chilena para el Mejoramiento del
software. Contiene una lista de las empresas evaluadas en Chile junto con el respectivo
nivel alcanzado.

www.psl.com.co

Sitio de la empresa colombiana de nivel CMMI 5. A
partir de este sitio se encuentran referencias a las demás empresas con evaluación CMMI
de Colombia.

http://www.calidaddelsoftware.com/documentos/listaempresascmmi.
pdf

Contiene datos interesantes, no oficiales, sobre el
avance de CMMI en España.
Otros Modelos de Procesos.

http://www.mkm-pi.com/mkmpi.php?article1817

Contiene datos comparativos del modelo ITIL con
respecto a CMMI.

http://www.sei.cmu.edu/cmmi/adoption/pdf/murthy.pdf

Contiene datos comparativos del modelo SIX SIGMA
con respecto a CMMI.

http://en.wikipedia.org/wiki/Six_Sigma

Contiene datos del modelo SIX SIGMA.

http://es.wikipedia.org/wiki/ISO_9001

Contiene datos del modelo ISO_9001.