Modelo de la madurez de la capacidad (CMM)

Modelo de la madurez de la capacidad (CMM) es a proceso modelo de la madurez de la capacidad que ayuda en la definición y entender de una organización procesos.

CMM primero fue descrito en un libro Manejo del proceso del software por Vatios de Humphrey (publicación. Addison-Wesley Conocían a Professional, Massachusetts, 1989), y por lo tanto también como “CMM de Humphrey”. Vatios de Humphrey basado le en el trabajo anterior de Phil Crosby. Desarrollo activo de este modelo por SEI (Departamento de los E.E.U.U. del instituto de la tecnología de dotación lógica de la defensa) comenzó en 1986. El SEI estaba en Universidad Carnegie-Mellon en Pittsburgh.

El CMM fue pensado originalmente como herramienta para objetivo determinar la capacidad de los contratistas del gobierno procesos para realizar un proyecto contraído del software. Aunque viene del área del desarrollo del software, puede (y ha sido y está siguiendo siendo) ser aplicado mientras que un modelo generalmente aplicable a la ayuda en entender la madurez de la capacidad de proceso de organizaciones en áreas diversas. Por ejemplo, tecnología de dotación lógica, ingeniería de sistema, gerencia de proyecto, mantenimiento del software, gerencia de riesgo, adquisición del sistema, tecnología de información (ÉL), gerencia de personal. Se ha utilizado extensivamente para software de la aeroelectrónica y proyectos del gobierno alrededor del mundo.

El CMM ha sido reemplazado por una variante - CMMI (Integración del modelo de la madurez de la capacidad). El viejo CMM fue retitulado a la tecnología de dotación lógica CMM (SE-CMM) y las acreditaciones de las organizaciones basadas en SE-CMM expiraron el 31 de diciembre de 2007.

Las variantes de los modelos de la madurez derivaron del CMM han emergido sobre los años, incluyendo, por ejemplo, seguridad del software dirigiendo CMM SSE-CMM Modelo de la madurez de la capacidad de la gente y el modelo de la madurez del mantenimiento del software S3M.

Los modelos de la madurez internacionalmente se han estandardizado como parte de ISO 15504.

El Modelo de Madurez de Capacidades o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).

El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de América y gestionado por la Universidad Carnegie-Mellon. "CMM" es una marca registrada del SEI.

A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América (en particular del Departamento de Defensa, DoD), desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993.

Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:

·         Definidas en un procedimiento documentado

·         Provistas (la organización) de los medios y formación necesarios

·         Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)

·         Medidas

·         Verificadas

A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.

Los niveles son:

1 - Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible.

2 - Repetible. En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.

3 - Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detalladas y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).

4 - Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.

5 - Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.

Ventajas

• Análisis causal y resolución
• Gerencia de la configuración
• Análisis y resolución de la decisión
• Gerencia de proyecto integrada
• Medida y análisis
• Innovación y despliegue de organización
• Definición de proceso de organización
• Foco de proceso de organización
• Funcionamiento de proceso de organización
• Entrenamiento de organización
• Supervisión y control del proyecto
• Planeamiento del proyecto
• Proceso y aseguramiento de la calidad del producto
• Integración del producto
• Gerencia de proyecto cuantitativa
• Gerencia de los requisitos
• Desarrollo de los requisitos
• Gerencia de riesgo
• Gerencia del acuerdo del surtidor
• Solución técnica
• Validación
• Verificación

Desventajas

1. Resistencia al cambio
2. Falta de patrocinio de la alta dirección
3. Falta de experiencia en programas de mejora de procesos
4. No se tiene un conocimiento especializado en Ingeniería de Software
5. No se tiene un conocimiento especializado en Administración de Proyectos
6. No se tiene conocimiento sobre modelos de calidad