La integración del modelo de madurez de capacidad ( CMMI ) es un programa de evaluación y capacitación para la mejora del nivel de procesos. Administrado por el Instituto CMMI , filial de ISACA , fue desarrollado en la Universidad Carnegie Mellon (CMU). Es requerido por muchos contratos del gobierno de EE. UU., especialmente en el desarrollo de software . CMU afirma que CMMI se puede utilizar para guiar la mejora de procesos en un proyecto, división o toda una organización. CMMI define los siguientes niveles de madurez para los procesos: Inicial, Gestionado, Definido, Gestionado Cuantitativamente y Optimización. 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á registrada en la Oficina de Patentes y Marcas de EE. UU. por CMU. [1]
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 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 se puede utilizar como marco para evaluar la madurez del proceso de la organización. [2] En enero de 2013, todo el conjunto de productos CMMI fue transferido del SEI al Instituto CMMI, una organización recién creada en Carnegie Mellon. [3]
CMMI fue desarrollado por el proyecto CMMI, cuyo objetivo era mejorar la usabilidad de los modelos de madurez integrando muchos modelos diferentes en un solo marco. El proyecto estuvo formado por 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 capacidad (CMM) o Software CMM. La CMM se desarrolló desde 1987 hasta 1997. En 2002, se lanzó la versión 1.1, la versión 1.2 siguió en agosto de 2006 y la versión 1.3 en noviembre de 2010. Algunos cambios importantes en CMMI V1.3 [4] son el soporte del desarrollo ágil de software . [5] mejoras a las prácticas de alta madurez [6] y alineación de la representación (por etapas y continua). [7]
Según el Instituto de Ingeniería de Software (SEI, 2008), CMMI ayuda a "integrar funciones organizativas 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". [8]
Mary Beth Chrissis, Mike Konrad y Sandy Shrum Rawdon fueron el equipo de autores de la publicación impresa de CMMI para desarrollo versiones 1.2 y 1.3. La publicación 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 impresa de CMMI para servicios versión 1.3. Rawdon "Rusty" Young fue el arquitecto jefe del desarrollo de CMMI versión 2.0. Anteriormente fue propietario de producto CMMI y líder de calidad de SCAMPI para el Instituto de Ingeniería de Software.
En marzo de 2016 el Instituto CMMI fue adquirido por ISACA .
En la versión 1.3 CMMI existía en dos representaciones: continua y por etapas. [2] La representación continua está diseñada para permitir al usuario centrarse 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. [2]
En la versión 2.0 se canceló la separación de representación anterior y ahora solo hay un modelo cohesivo. [9]
Dependiendo de las áreas de interés (adquisición, servicios, desarrollo) utilizadas, las áreas de proceso que contiene variarán. [10] Las áreas de proceso son las áreas que será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.
Las áreas de proceso a continuación y sus niveles de madurez se enumeran para el modelo CMMI para servicios:
Nivel de madurez 2 – Gestionado
Nivel de madurez 3 – Definido
Nivel de madurez 4: gestionado cuantitativamente
Nivel de madurez 5: optimización
Las mejores prácticas de CMMI se publican en documentos llamados modelos, cada uno de los cuales aborda un área de interés diferente. La versión 1.3 proporciona 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 donde cada área de proceso tiene potencialmente una referencia específica a uno o más de estos tres aspectos. Al tratar de mantenerse al día con la industria, el modelo también hace 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:
Una organización no puede certificarse en CMMI; en cambio, se evalúa una organización . Dependiendo del tipo de evaluación, la organización puede recibir una calificación de nivel de madurez (1 a 5) o un perfil de logro de nivel de capacidad.
Muchas organizaciones consideran valioso medir su progreso mediante la realización de una evaluación. Las tasaciones generalmente se realizan por una o más de las siguientes razones:
Las evaluaciones de organizaciones que utilizan un modelo CMMI [11] deben cumplir con los requisitos definidos en el documento Requisitos de Evaluación para CMMI (ARC). Hay 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 ellas, la evaluación de clase A es la más formal y la única que puede resultar en una calificación de nivel. Los equipos de evaluación utilizan un modelo CMMI y un método de evaluación compatible 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. [12] Los resultados de una tasación SCAMPI pueden publicarse (si la organización evaluada lo aprueba) en el sitio web CMMI de la SEI: Resultados de la tasació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 de las EPG y PAT sean capacitados en el CMMI, que se realice una evaluación informal (SCAMPI C) y que se prioricen áreas de proceso para mejorar. 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 software CMM anterior y CMMI. [13] 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 es de 20 meses adicionales. Desde la publicación del CMMI, el tiempo medio para pasar del Nivel 1 al Nivel 2 es de 5 meses, y el tiempo medio para pasar al Nivel 3 es de otros 21 meses. Estas estadísticas se actualizan y publican cada seis meses en un perfil de madurez. [ cita necesaria ]
La metodología de proceso de software del equipo del Instituto de Ingeniería de Software (SEI) y el uso de modelos CMMI se pueden utilizar para elevar el nivel de madurez. Un nuevo producto llamado Método de Mejora Acelerada [14] (AIM) combina el uso de CMMI y TSP. [15]
Para abordar las preocupaciones de seguridad de los usuarios, hay dos guías de seguridad no oficiales disponibles. Teniendo en cuenta el caso del contenido de seguridad en CMMI para servicios, hay un área de proceso, Gestión de seguridad. [16] Security by Design 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. [17]
El SEI publicó un estudio que dice que 60 organizaciones midieron aumentos de desempeño en las categorías de costo, cronograma, productividad, calidad y satisfacción del cliente. [18] 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 aumente el rendimiento en todas las organizaciones. Es posible que una empresa pequeña con pocos recursos tenga menos probabilidades de beneficiarse de CMMI; Esta visión está respaldada por el perfil de madurez del proceso (página 10). De las organizaciones pequeñas (<25 empleados), el 70,5 % se evalúan en el nivel 2: Gestionado, mientras que el 52,8 % de las organizaciones con entre 1.001 y 2.000 empleados se clasifican 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 ágil de software , ambos enfoques tienen mucho en común. Creen que ninguna de las dos formas es la "correcta" para desarrollar software, pero que hay fases en un proyecto en las que una de las dos es más adecuada. Sugieren que se deberían 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 ellos por separado. [19] David J. Anderson (2005) da sugerencias sobre cómo interpretar CMMI de una manera ágil. [20]
CMMI Roadmaps, [21] que son un enfoque basado en objetivos para seleccionar e implementar áreas de proceso relevantes del modelo CMMI-DEV, pueden proporcionar orientación y enfoque para la adopción efectiva de CMMI. Existen varias hojas de ruta de 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, [22] las hojas de ruta de integración de productos y productos CMMI [23] y las hojas de ruta de medidas y procesos de CMMI. [24] Estas hojas de ruta combinan los puntos fuertes de las representaciones escenificadas 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. [25] Para concluir con un uso similar de CMMI, la Programación Extrema ( XP ), un método de ingeniería de software, ha sido evaluado con CMM/CMMI (Nawrocki et al., 2002). Por ejemplo, se evaluó que el enfoque de gestión de requisitos de XP, que se basa en la comunicación oral, no cumplía con CMMI.
CMMI se puede evaluar utilizando dos enfoques diferentes: por etapas y continuo. El enfoque por etapas produce resultados de evaluación en uno de cinco niveles de madurez. El enfoque continuo produce uno de cuatro niveles de capacidad. Las diferencias entre estos enfoques se sienten sólo en la evaluación; las mejores prácticas son equivalentes y dan como resultado resultados de mejora de procesos equivalentes.
