Información general de CMMI

La guía definitiva del modelo Capability Maturity Model Integration (CMMI) for Development está publicada por el Instituto de ingeniería de software como "CMMI: Guidelines for Process Integration and Product Improvement". Este libro describe específicamente CMMI para Development (CMMI-DEV) versión 1.3, que es uno de los modelos del conjunto actual del producto CMMI cuando se escribió este tema. Este modelo es muy estable y seguramente seguirá siendo el modelo de referencia mucho más allá de 2010. "CMMI Distilled: A Practical Introduction to Integrated Process Improvement" es también un libro útil y accesible sobre este tema. Para más información sobre estos dos libros, vea la sección Recursos adicionales que figura más adelante en este tema.

El modelo CMMI vio la luz en 1987 como Capability Maturity Model (CMM), un proyecto del Software Engineering Institute, que es un centro de investigación de la Universidad Carnegie-Mellon. Este centro lo fundó y lo financia el Departamento de Defensa de los Estados Unidos. En 1991, se publicó por primera vez el modelo CMM for Software, que está basado en una lista de comprobación de los principales factores de éxito de los proyectos de desarrollo de software realizados a finales de los años setenta y principios de los años ochenta. El modelo también se fundamenta en las investigaciones realizadas por International Business Machines (IBM) Corporation y por Philip Crosby y W. Edwards Deming, destacados representantes del ámbito de control de calidad del siglo XX. Tanto el nombre, Capability Maturity Model, como los cinco niveles de la representación por etapas (que se abordará más adelante en este tema) están inspirados en el modelo de madurez Manufacturing Maturity Model de Crosby. Aplicado principalmente a programas de defensa, el modelo CMM ha logrado una aceptación considerable y se ha sometido a varias revisiones e iteraciones. Su éxito condujo al desarrollo de modelos CMM para diversos ámbitos más allá del ámbito de software. La proliferación de nuevos modelos dio lugar a confusión, por lo que el gobierno financió un proyecto de dos años en el que participaban más de 200 expertos del mundo industrial y académico a fin de crear un solo marco extensible para la ingeniería de sistemas, la ingeniería de software y el desarrollo de productos. El resultado fue CMMI.

Lo más importante que se debe saber de CMMI-DEV es que se trata de un modelo. No se trata de un proceso ni de una prescripción que se deba seguir. Es un conjunto de comportamientos organizativos de méritos demostrados en el marco del desarrollo de software y la ingeniería de sistemas. ¿Por qué debe usarse este tipo de modelo? ¿Cuál es su propósito? ¿Y cuál es la mejor forma de utilizarlo? Son preguntas esenciales que hacen referencia a aspectos de CMMI que han originado el mayor número de malentendidos.

¿Por qué debe usarse un modelo?

Si no se dispone de un modelo de cómo funcionan las organizaciones, qué funciones necesitan y cómo interactúan estas funciones, es difícil encauzar los esfuerzos de mejora. Un modelo nos permite comprender los elementos específicos de las organizaciones y ayuda a formular y a hablar de lo que hay que mejorar y de cómo se pueden lograr dichas mejoras. Un modelo ofrece las siguientes ventajas:

• proporciona un marco y un lenguaje comunes que ayudan a comunicarse,

• aporta años de experiencia,

• ayuda a los usuarios a no perder de vista la idea global cuando se enfocan específicamente en la mejora,

• suele tener el respaldo de instructores y consultores,

• puede proporcionar un estándar para ayudar a salvar las discrepancias.

¿Cuál es el propósito del modelo CMMI?

El libro de texto indicará que el propósito del modelo es evaluar la madurez de los procesos de una organización y proporcionar una orientación referente a cómo mejorar los procesos que darán lugar a mejores productos. Cuando se habla directamente con personas del Software Engineering Institute, es posible que digan que CMMI es un modelo para la administración de riesgos y que indica la capacidad de una organización para administrar los riesgos. Esta indicación es un indicio de la probabilidad con la que una organización puede cumplir sus promesas o proporcionar productos de alta calidad que sean atractivos para el mercado. Otro enfoque es que el modelo proporciona un buen indicador de cómo actuará una organización en situaciones de estrés. Una organización de gran madurez y altas capacidades afrontará con calma las situaciones inesperadas y de estrés, reaccionará, realizará cambios y seguirá adelante. Una organización con un reducido nivel de madurez y pocas capacidades tenderá a dejarse llevar por el pánico en situaciones de estrés, seguirá a ciegas los procedimientos obviados, o bien, desbaratará todos los procesos y volverá al caos.

El modelo CMMI no es un buen indicador del rendimiento económico de una organización. Si bien las organizaciones de gran madurez pueden administrar mejor el riesgo y ser más predecibles, está demostrada la aversión de estas organizaciones hacia el riesgo. Esta aversión puede conducir a una falta de innovación o un mayor grado de burocracia que da lugar a plazos de producción significativos y una falta de competitividad. Las empresas con un reducido nivel de madurez suelen ser más innovadoras y creativas pero caóticas e impredecibles. Cuando se logran resultados, suelen ser el fruto del esfuerzo heroico de algunas personas individuales o administradores.

¿Cuál es la mejor forma de usar el modelo CMMI?

El modelo se diseñó para que se use como base de las iniciativas enfocadas a mejorar los procesos y, en el ámbito de la evaluación, únicamente como ayuda para medir las mejoras. Este enfoque ha dado lugar a resultados mixtos. Resulta demasiado fácil confundir el modelo con una definición de proceso e intentar seguirlo en lugar de considerarlo como un mapa que identifica las lagunas en los procesos existentes que habría que rellenar. El bloque de creación fundamental del modelo CMMI es un área de proceso que define los objetivos y varias de las actividades que se suelen realizar para lograr dichos objetivos. Un ejemplo de un área de proceso es el control de calidad de los procesos y productos. Otro ejemplo es la administración de las configuraciones. Es importante entender que un área de proceso no es un proceso. Un solo proceso puede atravesar varias áreas de proceso y una sola área de proceso puede abarcar varios procesos.

En realidad, CMMI-DEV representa dos modelos que comparten los mismos elementos subyacentes. El primero y el más conocido es el modelo de la representación por etapas, que presenta 22 áreas de proceso asignadas a uno de los cinco niveles de madurez organizativa. Al valorar una organización, se evaluaría su nivel de funcionamiento y este nivel sería un indicador de su capacidad para administrar los riesgos y, por consiguiente, cumplir con sus promesas.

Los niveles 4 y 5 suelen denominarse los niveles de gran madurez. Suele haber una diferencia clara entre las organizaciones de gran madurez, que manifiestan comportamientos de administración cuantitativa y optimización, y las organizaciones con bajo nivel de madurez, que simplemente se administran o siguen los procesos definidos. Las organizaciones de gran madurez tienen una menor variabilidad en los procesos y suelen utilizar importantes indicadores como parte de un método de administración basado en estadísticas. Como resultado, estas organizaciones tienden a ser más predecibles y a responder con mayor rapidez a información nueva, suponiendo que la burocracia no se lo impida. Las organizaciones con un reducido grado de madurez tienden a realizar esfuerzos heroicos mientras que las organizaciones de gran madurez siguen a ciegas los procesos en situaciones de estrés y no reconocen que un cambio en los procesos podría ser una respuesta más adecuada.

El segundo, la representación continua, modela la capacidad de proceso en cada una de las 22 áreas de proceso y permite a la organización ajustar sus esfuerzos de mejora a los procesos que aporten el mayor valor de negocio. Esta representación está más en línea con el modelo original de Crosby. Las valoraciones según este modelo dan lugar a perfiles de capacidad en lugar de un mero número. Por supuesto, dado que el nivel de madurez organizativa es el nivel que la mayoría de los directivos y ejecutivos entienden, es posible asignar los resultados de una evaluación según el modelo continuo a las cinco etapas.

Usar el modelo por etapas como base de un programa enfocado a mejorar los procesos puede ser peligroso porque los implementadores podrían olvidarse de que el modelo CMMI no es un proceso ni un flujo de trabajo sino que proporciona los objetivos que los procesos y flujos de trabajo deben alcanzar. Si se cumplen esos objetivos, mejorará la madurez de la organización y aumentará la probabilidad de que todo transcurra según lo previsto. Quizás el mayor error sea convertir el hecho de alcanzar un nivel en un objetivo y crear procesos y una infraestructura simplemente para superar la valoración. El objetivo de cualquier actividad orientada a mejorar los procesos debe ser una mejora mensurable, no un número.

Parece que el modelo continuo tiene más éxito como guía para mejorar los procesos y algunas consultorías optan por ofrecer únicamente asesoramiento en torno al modelo continuo. La diferencia más obvia reside en que un programa orientado a mejorar los procesos que se ha diseñado basándose en el modelo continuo no tiene objetivos artificiales que vengan determinados por los niveles de madurez. Asimismo, el modelo continuo se presta de manera más natural a aplicar las mejoras de proceso en las áreas donde proporcione con mayor probabilidad un beneficio económico a la organización. Por consiguiente, las organizaciones que siguen el modelo continuo son las que obtienen con mayor probabilidad una respuesta positiva a una iniciativa basada en el modelo CMMI. Es más, las respuestas positivas son las que conducen con mayor probabilidad al desarrollo de un ciclo virtuoso de mejoras.

Elementos del modelo CMMI

El modelo CMMI se divide en las 22 áreas de proceso que se muestran en la siguiente tabla:

Acrónimo	Área de procesos
CAR	Análisis y resolución causal
CM	Administración de configuración
DAR	Análisis y resolución de decisiones
IPM	Administración integrada de proyectos
MA	Medida y análisis
OID	Innovación e implementación organizativas
OPD	Definición de procesos organizativos
OPF	Enfoque de los procesos organizativos
OPP	Rendimiento de los procesos organizativos
OT	Aprendizaje organizativo
PI	Integración de productos
PMC	Control y supervisión de proyectos
PP	Planeación de proyectos
PPQA	Control de calidad de procesos y productos
QPM	Administración cuantitativa de proyectos
RD	Definición de requisitos
REQM	Administración de requisitos
RSKM	Administración de riesgos
SAM	Administración de acuerdos con proveedores
TS	Solución técnica
VER	Comprobación
VAL	Validación

En la representación por etapas, cada área de proceso se corresponde con una etapa, tal como se muestra en la siguiente ilustración.

En la representación continua, las áreas de proceso se corresponden con grupos funcionales, tal como se muestra en la siguiente ilustración.

Cada área de proceso consta de componentes necesarios, esperados e informativos. En realidad, solo se requieren los componentes necesarios para superar una valoración según el modelo. Los componentes necesarios son los objetivos genéricos y específicos de cada área de proceso. Los componentes esperados son los procedimientos genéricos y específicos para cada objetivo genérico o específico. Dado que un componente esperado no es obligatorio, se puede reemplazar un procedimiento genérico o específico por otro equivalente. Los procedimientos esperados sirven para orientar a los implementadores y los responsables de la valoración. Si se opta por un procedimiento alternativo, le corresponderá al implementador notificárselo a la persona encargada de la valoración y justificar la elección de dicho procedimiento alternativo. Los componentes informativos facilitan detalles que ayudan a los implementadores a poner en marcha una iniciativa de mejora de procesos basada en el modelo CMMI. Los componentes informativos son subprocedimientos de los procedimientos genéricos y específicos y productos de trabajo típicos.

Es muy importante comprender que solo se requieren objetivos genéricos y específicos. Todo lo demás se proporciona a título orientativo. Los ejemplos de componentes esperados e informativos que se encuentran en la literatura sobre CMMI suelen provenir de grandes proyectos del ámbito del espacio y de la integración de sistemas de defensa. Estos proyectos los dirigen empresas que financian y apoyan el Software Engineering Institute de la Universidad Carnegie-Mellon. Quizás estos proyectos no reflejen el tipo de proyectos que se llevan a cabo en su empresa ni tampoco reflejen las últimas tendencias del sector, como la aparición de los métodos de desarrollo de software ágil.

Recursos adicionales

Para más información, vea los recursos web siguientes:

• CMMI for Development, Version 1.3, Improving processes for developing better products and services (CMMI for Development, Version 1.3, Mejora de procesos para desarrollar mejores productos y servicios) Software Engineering Process Management Program

• CMMI Institute

• CMMI: Guidelines for Process Integration and Product Improvement (Directrices para la integración de procesos y la mejora de productos), 2ª edición, Mary Beth Chrissis, Mike Konrad y Sandy Shrum; Addison-Wesley Professional, 2006.

• CMMI Distilled: A Practical Introduction to Integrated Process Improvement (CMMI: Una introducción práctica a la mejora de procesos integrada), 3ª edición, Dennis M. Ahren, Aaron Clause y Richard Turner; Addison-Wesley Professional, 2008.

Vea también

Conceptos

MSF for CMMI Process Improvement para Visual Studio ALM