Integración del modelo de madurez de capacidad

Programa de capacitación y evaluación de mejora a nivel de procesos

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]

Descripción general

Características de los niveles de madurez. [3]

Originalmente CMMI aborda tres áreas de interés:

  1. Desarrollo de productos y servicios – CMMI para Desarrollo (CMMI-DEV),
  2. Establecimiento y gestión de servicios, – CMMI para Servicios (CMMI-SVC), y
  3. Adquisición de productos y servicios – CMMI para Adquisición (CMMI-ACQ).

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]

Historia

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.

Temas

Representación

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]

Marco de trabajo del modelo (v1.3)

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.

Áreas de proceso centrales de Integración del modelo de madurez de capacidad (CMMI)
AbreviaturaÁrea de procesoCategoríaNivel de madurez
AUTOAnálisis causal y resoluciónApoyo5
CENTÍMETROGestión de configuraciónApoyo2
DARAnálisis y resolución de decisionesApoyo3
Manejo Integrado de Plagas (MIP)Gestión integrada de proyectosGestión de proyectos3
MAMÁMedición y análisisApoyo2
Departamento de policía de OregónDefinición de proceso organizacionalGestión de procesos3
OPFEnfoque en el proceso organizacionalGestión de procesos3
OPMGestión del rendimiento organizacionalGestión de procesos5
OposiciónDesempeño del proceso organizacionalGestión de procesos4
Antiguo TestamentoCapacitación organizacionalGestión de procesos3
Compañía Médica ProtegidaSeguimiento y control de proyectosGestión de proyectos2
PÁGINASPlanificación de proyectosGestión de proyectos2
Aseguramiento de la calidad de la protecciónAseguramiento de la calidad de procesos y productosApoyo2
Promedio de precios de materias primas (QPM)Gestión cuantitativa de proyectosGestión de proyectos4
REQUISITOSGestión de requisitosGestión de proyectos2
RSKMGestión de riesgosGestión de proyectos3
SAMGestión de acuerdos con proveedoresApoyo2

Niveles de madurez de los servicios

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

  • CM – Gestión de la configuración
  • MA – Medición y Análisis
  • PPQA – Garantía de calidad y procesos
  • REQM – Gestión de requisitos
  • SAM – Gestión de acuerdos con proveedores
  • SD – Entrega de servicios
  • WMC – Seguimiento y control de obra
  • WP – Planificación del trabajo

Nivel de madurez 3 – Definición

  • CAM – Gestión de capacidad y disponibilidad
  • DAR – Análisis y resolución de decisiones
  • IRP – Resolución y prevención de incidentes
  • IWM – Gestión Integrada del Trabajo
  • OPD – Definición de proceso organizacional
  • OPF – Enfoque en Procesos Organizacionales...
  • OT – Capacitación organizacional
  • RSKM – Gestión de riesgos
  • SCON – Continuidad del servicio
  • SSD – Desarrollo de sistemas de servicios
  • SST – Transición del sistema de servicio
  • STSM – Gestión Estratégica de Servicios

Nivel de madurez 4: gestión cuantitativa

  • OPP – Desempeño de procesos organizacionales
  • QWM – Gestión cuantitativa del trabajo

Nivel de madurez 5: Optimización

  • CAR – Análisis causal y resolución.
  • OPM – Gestión del Desempeño Organizacional.

Modelos (v1.3)

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.

  • CMMI para desarrollo (CMMI-DEV), v1.3 se lanzó en noviembre de 2010. Aborda los procesos de desarrollo de productos y servicios.
  • CMMI for Acquisition (CMMI-ACQ), v1.3 se lanzó en noviembre de 2010. Aborda los procesos de gestión de la cadena de suministro, adquisición y subcontratación en el gobierno y la industria.
  • CMMI para Servicios (CMMI-SVC), v1.3 se lanzó en noviembre de 2010. Aborda la orientación para la prestación de servicios dentro de una organización y a clientes externos.

Modelo (v2.0)

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:

  1. Las "Áreas de proceso" se han sustituido por "Áreas de práctica" (PA). Estas últimas están organizadas por niveles, no por "Objetivos específicos".
  2. Cada PA se compone de una sección "central" [es decir, una descripción genérica y libre de terminología] y una sección "específica del contexto" [es decir, una descripción desde la perspectiva de Agile/Scrum, desarrollo, servicios, etc.].
  3. Dado que ahora todas las prácticas son obligatorias de cumplir, se ha eliminado la sección "Esperado".
  4. Las "Prácticas genéricas" se han incluido en una nueva área denominada "Infraestructura de gobernanza e implementación", mientras que se han omitido las "Prácticas específicas".
  5. Se hace hincapié en garantizar la implementación de las actividades prácticas y que estas se practiquen continuamente hasta que se conviertan en un "hábito".
  6. Todos los niveles de madurez se centran en la palabra clave "rendimiento".
  7. Se han incluido dos y cinco PA opcionales del ámbito de "Seguridad" y "Protección".
  8. Se han fusionado las áreas de proceso del PCMM.

Evaluación

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:

  1. Para determinar qué tan bien se comparan los procesos de la organización con las mejores prácticas de CMMI e identificar áreas donde se pueden realizar mejoras.
  2. Informar a los clientes externos y proveedores sobre qué tan bien se comparan los procesos de la organización con las mejores prácticas de CMMI
  3. Para cumplir con los requisitos contractuales de uno o más clientes

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]

Seguridad

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:

  • OPSD – Preparación organizacional para un desarrollo seguro
  • SMP – Gestión Segura de Proyectos
  • SRTS – Requisitos de seguridad y solución técnica
  • SVV – Verificación y validación de seguridad

Si bien no afectan los niveles de madurez o capacidad, estas áreas de proceso pueden informarse en los resultados de la evaluación. [18]

Aplicaciones

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.

Véase también

Referencias

  1. ^ "Cambios de contenido de CMMI. Versión: V3.0, 6 de abril de 2023". CMMI Institute.
  2. ^ "Sistema de búsqueda electrónica de marcas (TESS)". tmsearch.uspto.gov . Consultado el 21 de diciembre de 2016 .
  3. ^ abcd Sally Godfrey (2008) [software.gsfc.nasa.gov/docs/What%20is%20CMMI.ppt ¿Qué es CMMI?]. Presentación de la NASA. Consultado el 8 de diciembre de 2008.
  4. ^ "Instituto CMMI - Página de inicio".
  5. ^ "CMMI V1.3: resumen". Ben Linders . 10 de enero de 2011.
  6. ^ "CMMI V1.3: ágil". Ben Linders . 20 de noviembre de 2010.
  7. ^ "Se lanzó CMMI V1.3: se aclaró el alto grado de madurez". Ben Linders . 2 de noviembre de 2010.
  8. ^ "CMMI V1.3: Implementación de CMMI". Ben Linders . 16 de noviembre de 2010.
  9. ^ Descripción general de CMMI. Instituto de Ingeniería de Software. Consultado el 16 de febrero de 2011.
  10. ^ "CMMI Institute - Áreas de práctica, categorías y áreas de capacidad básicas". Archivado desde el original el 16 de diciembre de 2018 . Consultado el 15 de diciembre de 2018 .
  11. ^ "Áreas de proceso CMMI V1.3". Ben Linders . 18 de septiembre de 2023.
  12. ^ Para conocer los últimos resultados de evaluación CMMI publicados, consulte el sitio web de SEI Archivado el 6 de febrero de 2007 en Wayback Machine .
  13. ^ "Método estándar de evaluación CMMI para la mejora de procesos (SCAMPISM) A, versión 1.2: Documento de definición del método". CMU/SEI-2006-HB-002 . Instituto de Ingeniería de Software. 2006 . Consultado el 23 de septiembre de 2006 .
  14. ^ "Perfil de madurez del proceso" . Consultado el 16 de febrero de 2011 .
  15. ^ "Biblioteca digital SEI". resources.sei.cmu.edu . 9 de febrero de 2024.
  16. ^ "Descripción general del TSP". resources.sei.cmu.edu . 13 de septiembre de 2010.
  17. ^ Eileer Forrester y Kieran Doyle. Consideración del caso del contenido de seguridad en CMMI para servicios (octubre de 2010)
  18. ^ Tecnología corporativa de Siemens AG. Seguridad por diseño con CMMI para desarrollo, versión 1.3 (mayo de 2013)
  19. ^ "Resultados del rendimiento de CMMI" . Consultado el 23 de septiembre de 2006 .
  20. ^ Sutherland, Jeff; Ruseng Jakobsen, Carsten; Johnson, Kent. "Scrum y CMMI Nivel 5: La poción mágica para los guerreros del código" (PDF) . Tecnología de objetos Jeff Sutherland .
  21. ^ Anderson, DJ (20 de julio de 2005). "Ampliar la metodología ágil para adaptarla al nivel 3 de CMMI: la historia de la creación de MSF para la mejora de procesos y la reglamentación CMMI/spl en Microsoft Corporation". Agile Development Conference (ADC'05) . pp. 193–201. doi :10.1109/ADC.2005.42. ISBN . 0-7695-2487-7. S2CID  5675994 – vía IEEE Xplore.
  22. ^ "Hojas de ruta CMMI". resources.sei.cmu.edu . 31 de octubre de 2008.
  23. ^ "CMMI V1.3: La hoja de ruta del proyecto CMMI". Ben Linders . 7 de diciembre de 2010.
  24. ^ "CMMI V1.3: Hojas de ruta de productos e integración de productos CMMI". Ben Linders . 14 de diciembre de 2010.
  25. ^ "CMMI V1.3: Hojas de ruta de medición y proceso CMMI". Ben Linders . 28 de diciembre de 2010.
  26. ^ "Uso de CMMI para mejorar la gestión del valor ganado". resources.sei.cmu.edu . 30 de septiembre de 2002 . Consultado el 30 de junio de 2022 .
  • Sitio web oficial
Retrieved from "https://en.wikipedia.org/w/index.php?title=Capability_Maturity_Model_Integration&oldid=1251977938"