Integración del modelo de madurez de la capacidad en segundo plano (CMMI)
Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013
El Instituto de ingeniería de software publica la guía definitiva de integración del modelo de madurez de la capacidad (CMMI) para el desarrollo como "CMMI: Guidelines for Process Integration and Product Improvement". En este libro se describe específicamente la versión 1.3 de CMMI for Development (CMMI-DEV), que es uno de los modelos del conjunto de productos CMMI. También puede encontrar "CMMI Consalida: una introducción práctica a la mejora de procesos integrados" para ser un libro útil y accesible sobre CMMI.
Nota
Las instrucciones proporcionadas aquí se basan en la versión 1.3 para CMMI y admiten el proceso de CMMI disponible con Azure DevOps. En este momento no existe ningún plan para actualizar este contenido para admitir versiones posteriores.
Notas históricas
CMMI comenzó en 1987 como modelo de madurez de la capacidad (CMM), un proyecto del Instituto de ingeniería de software (SEI). SEI es un centro de investigación de Carnegie-Mellon University, que se estableció y fue Estados Unidos Department of Defense. Publicado por primera vez en 1991, CMM for Software comenzó como una lista de comprobación de factores críticos de éxito. El modelo también se basa en la investigación en International Business Machines (IBM) Corporation y en líderes de control de calidad del siglo XX, como Edward Crosby y W. Edwards Deming. Tanto el nombre, el modelode madurez de capacidad como los cinco niveles de representación por fases se inspiraron en el modelo de madurez de fabricación de Crosby. Aplicado principalmente a programas de defensa, CMM ha logrado una adopción considerable y ha sometido a 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 era confusa. En respuesta, el gobierno ha financiado un proyecto de dos años para crear un único marco extensible que integre la ingeniería de sistemas, la ingeniería de software y el desarrollo de productos. En este esfuerzo han participado 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 receta que se va a seguir. En su lugar, CMMI-DEV proporciona un conjunto de comportamientos organizativos que han demostrado ser de uso 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 preguntas críticas son quizás los problemas más incomprendidos con 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 le proporciona una comprensión de los elementos organizativos y ayuda en las discusiones sobre cómo y qué se puede y debe mejorar.
Un modelo ofrece las siguientes ventajas:
- Proporciona un marco y un lenguaje comunes para ayudar a comunicarse.
- Aprovecha años de experiencia
- Ayuda a los usuarios a considerar la imagen grande mientras se centran en n mejoras
- A menudo es compatible con instructores y consultores.
- Puede ayudar a resolver los problemas proporcionando estándares acordados.
¿Cuál es el propósito del modelo CMMI?
El propósito del modelo CMMI es evaluar la madurez de los procesos de una organización y proporcionar instrucciones sobre cómo mejorar los procesos, con el objetivo de mejorar 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 factores de riesgo en la capacidad de una organización de ofrecer productos de alta calidad. Otra perspectiva de la administración del riesgo es el rendimiento de una organización bajo esfuerzo. Una organización de alta madurez y alta capacidad puede responder fácilmente a eventos inesperados y desenlome. Una organización con una madurez baja y una capacidad inferior tiende a entrar en el miedo bajo el esfuerzo, seguir a la vista los procedimientos obviados o lanzar todo el proceso por completo y volver al caos.
Sin embargo, cmmi no es un indicador probado del rendimiento económico de una organización. Aunque las organizaciones con mayor madurez pueden administrar mejor el riesgo y ser más predecibles, existe evidencia de que las empresas de mayor madurez tienden a ser inversas al riesgo. La aversión al riesgo puede dar lugar a una falta de innovación o evidencia de una mayor burocracia que da lugar a largos plazos y a una falta de oportunidades. 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 manera 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. Una evaluación de una organización evaluaría el nivel en el que estaba funcionando, y este nivel sería un indicador de su capacidad para administrar el riesgo y, a medida que, cumpliría sus promesas.

Los niveles 4 y 5 suelen denominarse los niveles de gran madurez. A menudo hay una clara diferencia entre las organizaciones de mayor madurez, que muestran los comportamientos cuantitativos de administración y optimización, y las organizaciones de madurez más bajas, que simplemente se administran o que se encuentran siguiendo procesos definidos. Las organizaciones de mayor madurez muestran una menor variabilidad en los procesos y, a menudo, usan indicadores principales como parte de un método de administración que se puede defender estadísticamente. Como resultado, las organizaciones de mayor madurez tienden a ser más predecibles y más rápidas a la hora de responder a la nueva información, suponiendo que otras burocracias no se meten en el camino. En los casos en los que las organizaciones de baja madurez tienden a demostrar su esfuerzo, las organizaciones de madurez alta pueden seguir a la vista los procesos cuando están bajo presión y no reconocen que un cambio de proceso puede ser una respuesta más adecuada.
La funcionalidad de proceso de los modelos de representación continua dentro de cada una de las 22 áreas de proceso individualmente, lo que permite a la organización adaptar sus esfuerzos de mejora a los procesos que ofrecen el mayor valor empresarial. 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 de la organización es el nivel que la mayoría de los directores y ejecutivos comprenden, hay maneras de asignar los resultados de una evaluación continua del modelo en las cinco fases.

El uso del modelo staged como base para un programa de mejora de procesos puede ser peligroso cuando los implementadores olvidan que CMMI no es un proceso ni un modelo de flujo de trabajo. En su lugar, CMMI está diseñado para proporcionar objetivos para que el proceso y el flujo de trabajo lo alcancen. El hecho de cumplir estos objetivos mejorará la madurez de la organización y la probabilidad de que los eventos se desarrollen 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 logrado el éxito como guía para procesar la mejora. Algunas empresas de consultoría optan solo por 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 los niveles de madurez. El modelo continuo también se presta a aplicar la mejora del proceso en las áreas en las que es más probable que aproveche una ventaja económica 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 | Resolución de análisis & causal |
| CM | Administración de la configuración |
| DAR | Resolución de análisis de & decisiones |
| IPM | Administración integrada de proyectos |
| MA | Análisis de & medidas |
| OID | Implementación de innovación & organizativa |
| 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 | Project supervisión & Control |
| PP | Planeación de proyectos |
| PPQA | Procesar & Product Quality Assurance |
| 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 | para complementos |
| 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.
proceso
En la representación continua, las áreas de proceso se corresponden con grupos funcionales, tal como se muestra en la siguiente ilustración.
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 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 incluyen subprácticas de prácticas genéricas y específicas y productos de trabajo típicos.
Solo se requieren objetivos genéricos y específicos. Todo lo demás se proporciona a título orientativo. Para obtener ejemplos de componentes esperados e informativos, la documentación de CMMI extraía datos de grandes proyectos de sistemas de defensa y espacio. Es posible que estos proyectos no reflejen el tipo de proyectos que se llevan a cabo en su organización, ni que reflejen tendencias más recientes en el sector, como la aparición de métodos de desarrollo de software agile.
Artículos relacionados
- Proceso CMMI
- Software Engineering Institute publica la versión 1.3 de CMMI Product Suite
- CMMI para el desarrollo: Directrices para la integración de procesos y la mejora del producto, tercera edición
- CMMI para el desarrollo: Directrices para la integración de procesos y la mejora del producto (serie SEI en ingeniería de software)
- ¿Qué es el desarrollo ágil?