Implantación práctica del modelo CMMI

Para la correcta implantación del modelo, se deben seguir estos cuatro pasos de tal forma que de un proceso actual se pase a una solución al proceso, sea cual sea el mismo:

1. Identificar el proceso actual de una organización o proyecto, de tal forma que se conozcan todos los requisitos del proceso a realizar, o se conozca en profundidad el proceso inicial que se requiere mejorar.

1. Revisar las buenas prácticas que el CMMI establece para las actividades de requisitos e identificar en el proceso actual, de tal forma que se conozcan todas las buenas prácticas aconsejadas que no se están realizando en ese proceso, de la misma manera, se puede realizar el mismo proceso pero a la inversa con los errores aprendidos, ya sea de documentos propios de CMMI como de lecciones aprendidas en la empresa.

1. Dentro del proceso actual de requisitos, se deben realizar las buenas prácticas a poner en marcha dentro del proceso, de tal forma que los encargados del proceso conozcan lo que deben hacer. Probar la solución en un proyecto, corregir defectos, realizar ajustes y seguir probando en más proyectos para seguir mejorando y aprendiendo.

1. No existen ejemplos ni herramientas en las que basarse porque justamente es un modelo de procesos, no es el proceso de alguna organización, es decir no se trata de copiar lo que otros han hecho en su organización, porque podría, y seguramente así será, no valer para el caso a estudiar. El CMMI se aplica sobre algún proceso de alguna organización o proyecto y no de forma estándar sobre cualquier proceso de un tipo. El CMMI sirve para mejorar un proceso, primero se debe tener el proceso a mejorar, sea el que sea. Si no tienes un proceso a mejorar, entonces no puede aplicar CMMI ni ningún otro modelo de mejora de procesos.

Origen de CMMI, el CMM

[caption id="" align="alignright" width="300" caption="Image via Wikipedia"][/caption]

El CMMI (Capability Maturity Model Integration), nace a finales de los años 80 (exactamente, 1987) dentro de la industria militar de los Estados Unidos de América, y su primera finalidad inicial fue la de evaluar los procesos de software más críticos, hoy ese modelo ha madurado a una serie de reglas y de buenas prácticas apoyada en una serie de herramientas software y no software para el uso o puesta en marcha de procesos de mejora continua en desarrollo y mantenimiento de sistemas informáticos.

Este modelo no es exclusivo del software ya que es aplicable a muchas otras áreas, los principales pilares sobre los que se levantó esta idea, fueron estas 22 áreas de proceso:

• Análisis de Causas y Resolución


• Gestión de la configuración


• Análisis de Decisiones y Resolución


• Gestión Integrada de Proyectos


• Medición y Análisis


• Innovación y Despliegue Organizacionales


• Definición de procesos organizacionales


• Enfoque Organizacional en Procesos


• Rendimiento de Procesos Organizacionales


• Formación Organizacional


• Monitorización y Control de Proyecto


• Planificación de proyecto


• Aseguramiento de calidad de Procesos y Productos


• Integración de Producto


• Gestión Cuantitativa de Proyectos


• Gestión de Requerimientos


• Desarrollo de Requerimientos


• Gestión de Riesgos


• Gestión de Acuerdos con Proveedores


• Solución Técnica


• Validación


• Verificación

Como puede verse, todos estos ideales, iniciales, no son solo aplicables a proyectos de software, sino que cualquier tipo de empresa, de cualquier ámbito puede aplicarlos a su modelo empresarial, el nacimiento de CMM, precursor de CMMI, es la reacción a una encuesta sobre proyectos de software, que tiene lugar en EEUU, y cuyos resultados fueron los siguientes:

• El 30% de los proyectos se cancelan.


• El 54% de los proyectos exceden ampliamente, costes y tiempo.


• El 16% de los proyectos finaliza, dentro del tiempo y coste previsto, dando la funcionalidad deseada de forma satisfactoria

Los resultados de esta encuesta, llevan al ejército americano, a tomar una decisión, y por lo tanto, a través del SEI (Software Engineering Institute), instaura, como estándar para la creación de software el CMM, y obliga a todos sus proveedores a certificarse en el mismo, para poder abastecer, de tal forma que prácticamente, todos aceptan a CMM, como el método de trabajo.

Documentación CMMI

La documentación de CMMI, merece un capítulo aparte, ya que puede ser, el punto más renegado por parte de los empleados, se admite que el modelo CMMI, implica una enorme carga de papeleo para los empleados, que debe ser gestionado de una forma correcta, no se debe dejar para el último momento de los proyectos toda la documentación, sino hacerla de forma escalonada, y con las ideas frescas de lo que se está haciendo en ese momento, porque si no, se pierde el objetivo de los documentos que se deben realizar.

Los documentos que se solicitan dentro del modelo, son los siguientes, para los niveles 3, 4 y 5, de CMMI, deben de documentarse, todos los procesos que se realizan, de manera que, quede constancia de lo que hace cada parte del software, en el caso de ser este el objetivo, es decir, no vale, con representar la funcionalidad integrada de una aplicación, sino que hace falta documentar la de cada parte aislada de la misma, documentando para cada objeto o parte del todo, modificando las pruebas unitarias y un cuaderno de carga de trabajo del mismo.

Por otra parte, toda la documentación que se crea, debe ser rastreable desde un solo punto, esta parte, está abierta a la interpretación de la empresa, pero se indica un modelo de matrices de trazabilidad y/o tablas, que relacionan mediante unos códigos y descripción, la situación exacta de los documentos, desde un solo punto común al proyecto, éste puede ser un repositorio de versiones, de documentos (como SVN o CVS) o sistemas más complejos, como pueden ser Lotus NOTES o repositorios propios.

Nacimiento de CMMI

Siguiendo con la evolución del modelo, en el año 2002, el SEI, relanza CMM, y lo renombra, como CMMI, este modelo, integra todas las áreas funcionales, no exclusivamente, la de desarrollo y mantenimiento, sino que llega hasta los recursos humanos, adquisición o producción.

También reinventa el modo de valorar los procesos, lo hace de una forma individualizada, aunque sigue manteniendo el sistema de niveles de CMM, dentro del nuevo CMMI, se pueden distinguir tres áreas a las que denomina de la siguiente manera:

• CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue dado a conocer en agosto de 2006. En él se tratan procesos de desarrollo tanto productivos como de servicios, se pueden diferenciar los dos:
  
  
  
  • CMMI-DEV, para el desarrollo en servicios
  
  
  • CMMI-DEV + IPPD (Integrated Product and Process Development) para la integración de producción y desarrollo de procesos.
  
  
  
  


• CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), la versión 1.2 llega a las empresas en noviembre de 2007. En él se tratan la gestión de la cadena de suministro (suppy chain management), adquisición y contratación externa en los procesos del gobierno y la industria.


• CMMI para servicios (CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las actividades que requieren del uso de servicios, en su forma más amplia.

Filosofía CMM

CMM, basa su idea de calidad, del principio de calidad del Doctor Joseph Jurán, del cual se desprende la trilogía de Jurán:

• Control de calidad.


• Mejora de nivel o cambio significativo.


• Planificación de la calidad.

De esta trilogía se desprende, las ideas de mejora continua y buenas prácticas que tanto ensalzan CMM, además Jurán afirma, que para mejorar un proceso, ya sea este de producción, industrial, software, o el que sea, primero hace falta tenerlo controlado, y para controlarlo, hace falta documentarlo, ya que el conocimiento de los empleados, implican control en los procesos, siempre y cuando, estos sigan encargados del mismo, en el momento que los pierdes, estás perdido, por lo que hace falta controlar estos procesos, de otra manera, mucho más objetiva y constante.

CMM, tiene una filosofía orientada al servicio, los conceptos de mejora continua y gestión de la información y del conocimiento, son básicos, ya que para la toma de decisiones en una empresa, es muy importante, definir claramente lo que se conoce y almacenarlo de la forma correcta, alejar el conocimiento tácito de la mente de los empleados para acercarlo a la empresa, mediante el almacenamiento del mismo, las herramientas de gestión de este tipo de valores, no están definidas expresamente en el modelo ya que considera, que cada organización debe evaluar su situación y adaptarse a la misma, el modelo original distingue cinco niveles de madurez, dentro de la integración del mismo en la empresa, que son:

1. Inicial. Las organizaciones en este nivel no tienen un ambiente, lo suficientemente apto para el desarrollo y mantenimiento de software. El destino de los proyectos que se realizan en este grupo de empresas, depende en gran medida del talento individual de los empleados y coordinadores.


2. Repetible. En este nivel, las organizaciones empiezan a estar gestionadas, sus proyectos tienen diferentes sistemas de métrica, para poder asegurar el correcto funcionamiento de los proyectos.


3. Definido. En este nivel, además de tener ya alcanzada una madurez suficiente en cuanto a la gestión de proyectos, las organizaciones disponen de correctos procedimientos de coordinación de grupos, sistemas multidisciplinares, formación de los empleados, técnicas de ingeniería más detalladas y un nivel superior de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews), que son quizá uno de los mayores logros del modelo, muy alabado y al que dedicaremos unas líneas más adelante.


4. Gestionado. Se gestionan los riesgos de una forma clara, y se adelanta a las situaciones tanto adversas como positivas, las decisiones se toman en un entorno estable, de tal forma que al tener una capacidad de medición muy exacta de lo que pasará, estas se ven mejoradas por el conocimiento. El software que se crea es de muy alta calidad.


5. Optimizado. La empresa en su totalidad está constantemente reabastecida de buenas prácticas y de un proceso de mejora continua. Se gestiona al mismo tiempo el proceso de innovación, retroalimentado por los propios procesos de mejora continua.