Compartir a través de

Contexto de la integración del modelo de madurez y de capacidad (CMMI)

  • Artículo

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

La guía definitiva para la integración del modelo de madurez y de capacidad (CMMI) para desarrollo se publica en el Instituto de Ingeniería de Software como "CMMI: Directrices para la integración de procesos y la mejora de los productos". En este libro se describe específicamente la versión 1.3 de CMMI para desarrollo (CMMI-DEV), que es uno de los modelos del conjunto de productos CMMI. Otro libro útil y accesible sobre CMMI es "Síntesis de CMMI: Una introducción práctica a la mejora de procesos integrados".

Nota:

La guía que se proporciona aquí se basa en la versión 1.3 de CMMI y admite el proceso CMMI disponible con Azure DevOps. En este momento, no está previsto actualizar este contenido para admitir versiones posteriores.

Notas históricas

El CMMI comenzó en 1987 como modelo de madurez y de capacidad (CMM), un proyecto del Instituto de ingeniería de software (SEI). El SEI es un centro de investigación de la Universidad Carnegie-Mellon creado y financiado por el Departamento de Defensa de Estados Unidos. Publicado por primera vez en 1991, el CMM para software comenzó como una lista de comprobación de factores de éxito críticos. El modelo también se basaba en las investigaciones de International Business Machines (IBM) Corporation y de líderes del siglo XX de garantía de calidad, como Philip Crosby y W. Edwards Deming. Tanto el nombre, Modelo de madurez y de capacidad, como los cinco niveles de representación por etapas están inspirados en el modelo de madurez de Crosby. Aplicado principalmente a programas de defensa, CMM ha logrado una aceptación considerable y ha pasado por varias revisiones. Su éxito condujo al desarrollo de modelos CMM para diversos ámbitos más allá del ámbito de software. La proliferación de nuevos modelos confundía. Como consecuencia, el gobierno financió un proyecto de dos años para crear un solo marco extensible que integrara la ingeniería de sistemas, la ingeniería de software y el desarrollo de productos. En este trabajo participaron más de 200 expertos académicos y del sector. El resultado fue CMMI.

CMMI-DEV es un modelo. No es un proceso ni una prescripción. En cambio, CMMI-DEV proporciona un conjunto de comportamientos organizativos que han demostrado su utilidad en el 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? Estas cuestiones críticas son quizá los problemas más incomprendidas del CMMI.

¿Por qué debe usarse un modelo?

Los esfuerzos de mejora requieren un modelo de cómo funciona su organización, qué funciones necesitan y cómo interactúan esas funciones. Un modelo permite comprender los elementos organizativos y ayuda a analizar cómo y qué puede y debe mejorarse.

Un modelo ofrece las siguientes ventajas:

  • Proporciona un marco y un lenguaje comunes que ayudan a comunicarse.
  • Aprovecha años de experiencia.
  • Ayuda a los usuarios a tener en cuenta el panorama general al tiempo que se centra en la mejorar
  • Suele tener el apoyo de instructores y consultores.
  • Puede ayudar a resolver los desacuerdos al ofrecer estándares acordados.

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

La finalidad del modelo CMMI es evaluar la madurez de los procesos de una organización y ofrecer orientación para mejorarlos, con el objetivo de optimizar los productos. Además, CMMI es un modelo para la administración de riesgos y proporciona una manera de medir la capacidad de una organización para administrar el riesgo. La capacidad de administrar los factores de riesgo influye en la capacidad de una organización para ofrecer productos de alta calidad. Otra perspectiva sobre la administración del riesgo es lo bien que funciona una organización en situaciones de estrés. Una organización de alta madurez y alta capacidad puede responder fácilmente a eventos inesperados y estresantes. Una organización poco madura y con menos capacidad tiende a dejarse llevar por el pánico en situaciones de estrés, a seguir ciegamente procedimientos obviados o a desechar por completo todo proceso y retroceder hasta el 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 al riesgo. Esta aversión puede llevar a una falta de innovación o un mayor grado de burocracia que da lugar a plazos largos y 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 valoració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 evaluar 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 sus promesas.

Representación por etapas de CMMI

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.

La representación continua modela la capacidad de los procesos 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 evaluaciones según este modelo dan lugar a perfiles de capacidad en lugar de un mero número. Dado que el nivel de madurez organizativa es el nivel que entienden la mayoría de los directivos y ejecutivos, existen formas de asignar los resultados de una evaluación continua del modelo a las cinco etapas.

Representación continua de CMMI

El uso del modelo por etapas como base para un programa de mejora de procesos puede ser peligroso cuando los implementadores olvidan que el CMMI no es un proceso ni un modelo de flujo de trabajo. En su lugar, el CMMI está diseñado para proporcionar objetivos que el proceso y el flujo de trabajo alcanzarán. 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 evaluación. El objetivo de cualquier actividad orientada a mejorar los procesos debe ser una mejora mensurable, no un número.

El modelo continuo ha tenido éxito como guía para la mejora de procesos. Algunas empresas de consultoría eligen solo ofrecer orientación sobre el modelo continuo. La diferencia más obvia es que un programa de mejora de procesos diseñado en torno al modelo continuo no tiene objetivos artificiales determinados por niveles de madurez. El modelo continuo también se presta a aplicar la mejora de procesos en las áreas en las que es más probable que suponga un beneficio económico para 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

En la tabla siguiente se enumeran las 22 áreas de proceso que componen el modelo CMMI (versión 1.3):

Acrónimo Área de proceso
CAR Análisis causal y resolución
CM Administración de la configuración
DAR Análisis de decisiones y resolución
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.

Representación por fases que muestra áreas de proceso

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

Representación continua que muestra áreas de proceso

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 corresponde 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 incluyen subprocedimientos de procedimientos genéricos y específicos y productos de trabajo típicos.

Solo se requieren metas genéricas y específicas. Todo lo demás se proporciona a título orientativo. En lo relativo a ejemplos de componentes esperados e informativos, la literatura sobre CMMI extrajo datos de grandes proyectos espaciales y de sistemas de defensa. 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 Agile.