CMMi y la Necesidad de un Modelo Integrado

A mediados de la decada los 80' se hizo evidente para el Departamento de Defensa de los Estados Unidos de que la gran cantidad de sistemas que se estaban desarrollando para aplicaciones de defensa que eran intensivos en software, no estaban cumpliendo con los requisitos establecidos y se estaban elevando descontroladamente los costos.

El Software Engineering Institute (SEI), como parte de la Carnegie Mellon University, fue fundado por el Departamento de Defensa como un centro de para la investigación y desarrollo, con la misión de liderar y promover las prácticas de la Ingeniería de Software para mejorar la calidad de los sistemas basados en software.

Inicialmente el modelo se enfocó predominantemente en los procesos de Ingeniería de Software. Las actividades del ciclo de vida del software que coincidían con las descripciones encontradas en la ISO9001:1994 fueron colocadas todas juntas en una Area de Proceso Clave (Key Process Area) llamada Ingeniería de Producto.

Muchos debates tomaron lugar en los sagrados salones del SEI durante el desarrollo del CMMI v1.0 con respecto a la necesidad de una descripción más detallada de las actividades del ciclo de vida versus mantener un cierto tamaño y un número de Areas de Proceso Claves que fueron desarrolladas en el Nivel 3 de Madurez. Al final, se decidió mantener sólo una Área de Proceso Clave llamada "Ingeniería" donde se describen las actividades o funciones que se mantendría compatibles con el resto de KPA en CMM.

Mientras el uso de CMM crecía rápidamente alrededor del mundo, comenzó a verse clara y rápidamente que el foco estricto en la Ingeniería de Software, no satisfacía las necesidades de negocio o sistemas intensivos en software. Una asesoría conducida por Jeff Perdue del Institute of Software Process Improvement (ISPI) mostró que la necesidad por un proceso de mejora de "sistemas" de ingeniería era inmediata y los resultados serían precisos. Finalmente varios modelos CMM fueron desarrollados para una gran variedad de disciplinas, aparte de la ingeniería de software. Estos modelos incluidos para la adquisición de software, la gestión de personas, desarrollo y la integración de producto y procesos.

Aunque estos modelos resultaron útiles para muchas organizaciones, el uso de múltiples modelos también se convirtió en un problema. Las organizaciones que deseaban centrarse en su mejora en todas las disciplinas tuvieron dificultades. Las diferencias entre los modelos específicos de cada disciplina, incluyendo sus arquitecturas, contenidos y enfoques, limitaban la habilidad de las organizaciones para enfocar sus esfuerzos en mejorar sus procesos exitosamente. Adicionalmente, la aplicación de múltiples modelos que no estaban consistentemente integrados dentro y a través de una organización, resultaba en altos costos en términos de capacitación, evaluaciones y actividades de mejora.

El proyecto CMMi fue formado para superar el problema de usar múltiples CMM. La misión del equipo del modelo CMMi fue combinar tres modelos:

1. SW-CMM: Capability Maturity Model for Software (v2.0 draft C).
2. Electronic Industries Alliance Interim Standard (EIA/IS 731).
3. Integrates Product Development Capability Maturyty Model (IPD-CMM v0.98)

En definitiva, el objetivo era integrar estos modelos en un único framework para su uso por organizaciones que persiguen en toda la empresa la mejora de sus procesos.

La necesidad de un modelo integrado se puede apreciar en como evolucionó CMMi en el set de modelos que representa hoy en día.

REFERENCIAS:

• Introduction to the Architecture of the CMMI® Framework
• Addison Wesley - CMMI for Development 3rd Edition Mar 2011
• Addison Wesley Professional - CMMI for Services - Guidelines for Superior Service - 2nd Edition - Mar 2011
• Practical Insight into CMMI