Capability Maturity Model Integration ( CMMI ) es un programa de evaluación y capacitación para la mejora de procesos a nivel de proceso. Administrado por el CMMI Institute , una subsidiaria de ISACA , fue desarrollado en la Universidad Carnegie Mellon (CMU). Es requerido por muchos contratos del gobierno de los EE. UU., especialmente en el desarrollo de software . CMU afirma que CMMI se puede utilizar para guiar la mejora de procesos en un proyecto, una división o una organización entera.
CMMI define los siguientes cinco niveles de madurez (del 1 al 5) para los procesos: inicial, gestionado, definido, gestionado cuantitativamente y optimizado. La versión 3.0 de CMMI se publicó en 2023; [1] La versión 2.0 se publicó en 2018; La versión 1.3 se publicó en 2010 y es el modelo de referencia para el resto de la información de este artículo. CMMI está registrado en la Oficina de Patentes y Marcas de EE. UU. por CMU. [2]
Originalmente CMMI aborda tres áreas de interés:
En la versión 2.0 estas tres áreas (que anteriormente tenían un modelo separado cada una) se fusionaron en un solo modelo.
CMMI fue desarrollado por un grupo de la industria, el gobierno y el Instituto de Ingeniería de Software (SEI) de la CMU. Los modelos CMMI brindan orientación para desarrollar o mejorar procesos que cumplan con los objetivos comerciales de una organización. Un modelo CMMI también puede usarse como marco para evaluar la madurez del proceso de la organización. [3] En enero de 2013, toda la suite de productos CMMI se transfirió del SEI al Instituto CMMI, una organización recién creada en Carnegie Mellon. [4]
CMMI fue desarrollado por el proyecto CMMI, cuyo objetivo era mejorar la usabilidad de los modelos de madurez mediante la integración de muchos modelos diferentes en un único marco. El proyecto contó con la participación de miembros de la industria, el gobierno y el Instituto de Ingeniería de Software Carnegie Mellon (SEI). Los principales patrocinadores incluyeron la Oficina del Secretario de Defensa ( OSD ) y la Asociación Industrial de Defensa Nacional .
CMMI es el sucesor del modelo de madurez de capacidades (CMM) o CMM de software. El CMM se desarrolló desde 1987 hasta 1997. En 2002 se lanzó la versión 1.1, seguida de la versión 1.2 en agosto de 2006 y la versión 1.3 en noviembre de 2010. Algunos cambios importantes en CMMI V1.3 [5] son el soporte del desarrollo de software ágil , [6] mejoras en las prácticas de alta madurez [7] y la alineación de la representación (por etapas y continua). [8]
Según el Software Engineering Institute (SEI, 2008), CMMI ayuda a "integrar funciones organizacionales tradicionalmente separadas, establecer objetivos y prioridades de mejora de procesos, proporcionar orientación para procesos de calidad y proporcionar un punto de referencia para evaluar los procesos actuales". [9]
Mary Beth Chrissis, Mike Konrad y Sandy Shrum Rawdon fueron el equipo de autores de la publicación en papel de CMMI para Desarrollo Versión 1.2 y 1.3. La publicación de Addison-Wesley de la Versión 1.3 estuvo dedicada a la memoria de Watts Humphry. Eileen C. Forrester, Brandon L. Buteau y Sandy Shrum fueron el equipo de autores de la publicación en papel de CMMI para Servicios Versión 1.3. Rawdon "Rusty" Young fue el arquitecto principal del desarrollo de CMMI versión 2.0. Anteriormente fue el Propietario del Producto CMMI y el Líder de Calidad SCAMPI para el Instituto de Ingeniería de Software.
En marzo de 2016, el Instituto CMMI fue adquirido por ISACA .
En abril de 2023, se lanzó CMMI V3.0.
En la versión 1.3, CMMI existía en dos representaciones: continua y por etapas. [3] La representación continua está diseñada para permitir que el usuario se centre en los procesos específicos que se consideran importantes para los objetivos comerciales inmediatos de la organización, o aquellos a los que la organización asigna un alto grado de riesgos. La representación por etapas está diseñada para proporcionar una secuencia estándar de mejoras y puede servir como base para comparar la madurez de diferentes proyectos y organizaciones. La representación por etapas también permite una fácil migración de SW-CMM a CMMI. [3]
En la versión 2.0 se canceló la separación de representación anterior y ahora solo hay un modelo cohesivo. [10]
Dependiendo de las áreas de interés (adquisición, servicios, desarrollo) utilizadas, las áreas de proceso que contiene variarán. [11] Las áreas de proceso son las áreas que estarán cubiertas por los procesos de la organización. La siguiente tabla enumera las diecisiete áreas de proceso centrales de CMMI que están presentes para todas las áreas de interés de CMMI en la versión 1.3.
A continuación se enumeran las áreas de proceso y sus niveles de madurez para el modelo CMMI para servicios:
Nivel de madurez 2: Gestionado
Nivel de madurez 3 – Definición
Nivel de madurez 4: gestión cuantitativa
Nivel de madurez 5: Optimización
Las mejores prácticas de CMMI se publican en documentos denominados modelos, cada uno de los cuales aborda un área de interés diferente. La versión 1.3 ofrece modelos para tres áreas de interés: desarrollo, adquisición y servicios.
En la versión 2.0 DEV, ACQ y SVC se fusionaron en un único modelo en el que cada área de proceso tiene potencialmente una referencia específica a uno o más de estos tres aspectos. En un intento por mantenerse al día con la industria, el modelo también tiene una referencia explícita a aspectos ágiles en algunas áreas de proceso.
A continuación se detallan algunas diferencias clave entre los modelos v1.3 y v2.0:
No es posible certificar una organización en CMMI, sino que se la evalúa . Según el tipo de evaluación, se le puede otorgar a la organización una calificación de nivel de madurez (1 a 5) o un perfil de logro de nivel de capacidad.
Muchas organizaciones consideran que es útil medir su progreso mediante una evaluación. Las evaluaciones se realizan normalmente por una o más de las siguientes razones:
Las evaluaciones de organizaciones que utilizan un modelo CMMI [12] deben cumplir con los requisitos definidos en el documento Requisitos de evaluación para CMMI (ARC). Existen tres clases de evaluaciones, A, B y C, que se centran en identificar oportunidades de mejora y comparar los procesos de la organización con las mejores prácticas de CMMI. De estas, la evaluación de clase A es la más formal y es la única que puede dar como resultado una calificación de nivel. Los equipos de evaluación utilizan un modelo CMMI y un método de evaluación conforme con ARC para guiar su evaluación de la organización y su informe de conclusiones. Los resultados de la evaluación pueden luego usarse (por ejemplo, por un grupo de procesos) para planificar mejoras para la organización.
El método de evaluación estándar CMMI para la mejora de procesos (SCAMPI) es un método de evaluación que cumple con todos los requisitos de ARC. [13] Los resultados de una evaluación SCAMPI pueden publicarse (si la organización evaluada lo aprueba) en el sitio web CMMI del SEI: Resultados de evaluación SCAMPI publicados. SCAMPI también respalda la realización de evaluaciones ISO/IEC 15504 , también conocida como SPICE (Mejora de procesos de software y determinación de capacidad), etc.
Este enfoque promueve que los miembros del EPG y los PAT reciban capacitación en el CMMI, que se realice una evaluación informal (SCAMPI C) y que se prioricen las áreas de proceso para su mejora. Los enfoques más modernos, que implican la implementación de procesos compatibles con CMMI disponibles comercialmente, pueden reducir significativamente el tiempo necesario para lograr el cumplimiento. SEI ha mantenido estadísticas sobre el "tiempo para ascender" para las organizaciones que adoptan el anterior CMM de software, así como el CMMI. [14] Estas estadísticas indican que, desde 1987, el tiempo medio para pasar del Nivel 1 al Nivel 2 es de 23 meses, y del Nivel 2 al Nivel 3 son 20 meses adicionales. Desde el lanzamiento del CMMI, el tiempo medio para pasar del Nivel 1 al Nivel 2 es de 5 meses, y el movimiento medio al Nivel 3 son otros 21 meses. Estas estadísticas se actualizan y publican cada seis meses en un perfil de madurez. [ cita requerida ]
La metodología de procesos de software del equipo del Software Engineering Institute (SEI) y el uso de modelos CMMI pueden utilizarse para elevar el nivel de madurez. Un nuevo producto llamado Accelerated Improvement Method [15] (AIM) combina el uso de CMMI y TSP. [16]
Para abordar las preocupaciones de seguridad de los usuarios, hay disponibles dos guías de seguridad no oficiales. Considerando el caso de seguridad El contenido en CMMI para servicios tiene un área de proceso, Gestión de seguridad. [17] Seguridad por diseño con CMMI para desarrollo, versión 1.3 tiene las siguientes áreas de proceso:
Si bien no afectan los niveles de madurez o capacidad, estas áreas de proceso pueden informarse en los resultados de la evaluación. [18]
El SEI publicó un estudio en el que se afirma que 60 organizaciones midieron aumentos de rendimiento en las categorías de costo, cronograma, productividad, calidad y satisfacción del cliente. [19] El aumento medio en el rendimiento varió entre el 14% (satisfacción del cliente) y el 62% (productividad). Sin embargo, el modelo CMMI se ocupa principalmente de qué procesos deben implementarse, y no tanto de cómo pueden implementarse. Estos resultados no garantizan que la aplicación de CMMI aumentará el rendimiento en todas las organizaciones. Una empresa pequeña con pocos recursos puede tener menos probabilidades de beneficiarse de CMMI; esta opinión está respaldada por el perfil de madurez de procesos (página 10). De las organizaciones pequeñas (<25 empleados), el 70,5% se evalúa en el nivel 2: Gestionado, mientras que el 52,8% de las organizaciones con 1.001–2.000 empleados se califican en el nivel más alto (5: Optimización).
Turner y Jain (2002) sostienen que, aunque es obvio que existen grandes diferencias entre CMMI y el desarrollo de software ágil , ambos enfoques tienen mucho en común. Creen que ninguna de las dos formas es la "correcta" de desarrollar software, pero que hay fases en un proyecto en las que una de las dos es más adecuada. Sugieren que se deben combinar los diferentes fragmentos de los métodos en un nuevo método híbrido. Sutherland et al. (2007) afirman que una combinación de Scrum y CMMI aporta más adaptabilidad y previsibilidad que cualquiera de los dos por separado. [20] David J. Anderson (2005) da pistas sobre cómo interpretar CMMI de manera ágil. [21]
Las hojas de ruta CMMI, [22] que son un enfoque orientado a objetivos para seleccionar e implementar áreas de proceso relevantes del modelo CMMI-DEV, pueden proporcionar orientación y enfoque para una adopción eficaz de CMMI. Existen varias hojas de ruta CMMI para la representación continua, cada una con un conjunto específico de objetivos de mejora. Algunos ejemplos son la hoja de ruta del proyecto CMMI, [23] las hojas de ruta de productos e integración de productos CMMI [24] y las hojas de ruta de procesos y mediciones CMMI [25] . Estas hojas de ruta combinan las fortalezas de las representaciones por etapas y continuas.
Se ha descrito la combinación de la técnica de gestión de proyectos gestión del valor ganado (EVM) con CMMI. [26] Para concluir con un uso similar de CMMI, se ha evaluado la Programación Extrema ( XP ), un método de ingeniería de software, con CMM/CMMI (Nawrocki et al., 2002). Por ejemplo, el enfoque de gestión de requisitos XP, que se basa en la comunicación oral, fue evaluado como no compatible con CMMI.
CMMI se puede evaluar utilizando dos enfoques diferentes: por etapas y continuo. El enfoque por etapas arroja resultados de evaluación como uno de cinco niveles de madurez. El enfoque continuo arroja uno de cuatro niveles de capacidad. Las diferencias entre estos enfoques se perciben solo en la evaluación; las mejores prácticas son equivalentes, lo que da como resultado resultados de mejora de procesos equivalentes.
