Historia del modelo CMM

El modelo surgió a partir de una necesidad militar por el departamento de defensa de los Estados Unidos a mediados de los 80’s. Esto debido a él gran índice de incumplimiento para los proyectos relativos al desarrollo e implementación del software. El departamento de defensa de los Estados Unidos solicitó al Software Engineering Institute (SEI) la definición de un modelo que ayudara a mejorar los procesos de desarrollo de software.

A partir de noviembre de 1986, el SEI desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software CMM la cual fue publicada en septiembre de 1987, el CMM tomó como base el concepto de la administración de la calidad Total (TQM), se puede decir que CMM es una aplicación de TQM para software.

CMM es:

• Una estrategia de mejora

• Una señalización de deficiencias dentro de una organización

• Una guía para poder avanzar hacia una cultura de calidad

CMM no es:

• Una solución rápida

• Un checklist que puede ser utilizado en todos los ambientes

Antes de adentrarnos un poco más en el modelo CMM, vamos a repasar algunas definiciones importantes de acuerdo con el SEI.

¿Qué es un modelo?

Cosa que sirve como pauta para ser imitada, reproducida o copiada

¿Qué es un proceso de software?

Conjunto de actividades, métodos, prácticas y transformaciones para desarrollar y mantener software y productos asociados.

¿Qué es la capacidad de un proceso?

El rango de resultados esperados que se pueden obtener tras seguir un proceso

¿Qué es la madurez de un proceso de software?

Es el punto hasta el cual un determinado proceso es explícitamente definido, administrado, medido, controlado y efectivo.

¿Qué es un área clave de proceso? (Key Process Area KPA)

Grupo de actividades relacionadas, que cuando se llevan a cabo en conjunto alcanzan un conjunto de metas (consideradas importantes para alcanzar la capacidad del proceso).

CMM

• Es un marco que describe los elementos claves de un proceso de software efectivo.

• Describe un camino de mejora evolutivo desde un proceso inmaduro a un proceso maduro y disciplinado.

• CMM describe prácticas para la planificación, ingeniería, y administración del desarrollo y mantenimiento de software.

• Cuando las organizaciones siguen estas prácticas se mejora la habilidad para cumplir las metas de costos, de planificación, de funcionalidad y calidad del producto.

ESTRUCTURA

Veamos la estructura del CMM como un edificio de 5 pisos que hay que subir, cada piso representa un nivel de madurez que hay que alcanzar. Imaginemos los KPA’s como plataformas intermedias que nos ayudarán a alcanzar las metas necesarias para subir de nivel, dichas plataformas se compondrán de varios escalones los cuales identificaremos como Practicas clave. Habrá que tener en cuenta que el número de escalones no será fijo entre cada nivel.

Niveles de Madurez

Nivel 1. Nivel Inicial

Una empresa estará en este nivel si su proceso es caótico, en donde no hay un ambiente estable para desarrollar o mantener software. Normalmente estos son los síntomas de empresas en nivel 1:

• Las metas alcanzadas no se cumplen en tiempo, costos y recursos planeados.

• Si se llegan a cumplir metas, es gracias a esfuerzos individuales excepcionales dentro del equipo de trabajo, más que a una buena planeación.

• Los objetivos de costos normalmente se sobrepasan

En este ambiente, la probabilidad de alcanzar un objetivo es casi nula. La capacidad es más bien una cualidad de las personas más que de una organización. Se alcanza el propósito de manera inconsciente.

Nivel 2. Repetible

Para pode estar en este nivel, la empresa necesita empezar a documentar su proceso, dejar un historial del trabajo realizado. Será necesario empezar a definir políticas para la administración de los proyectos y al mismo tiempo tener procedimientos para verificar el cumplimiento de dichas políticas. En la siguiente figura podemos ver como un proceso tiene definidas ciertas cajas negras (donde no conocemos exactamente qué pasa, pero al menos están definidas), en donde al final de cada caja, se dedica un cierto tiempo en verificar que se estén obteniendo los resultados esperados, en cada verificación se puede informar al cliente sobre el estatus.

En este nivel uno de los propósitos es poder repetir el éxito de proyectos anteriores, de ahí el nombre. Será necesario tener un historial de proyectos exitosos, donde se haya llegado al éxito a través de procesos bien definidos y documentados, pero al mismo tiempo mejorables. Esto ocasionará que en este nivel se puedan definir requerimientos, tiempos, costos y recursos de manera más real.

Nivel 3. Definido

En este nivel nos olvidaremos de las cajas negras del nivel 2. En este punto ya adquiere un proceso de software estándar que se aplica en toda la organización. Se unen las prácticas de ingeniería de software con la administración de procesos.

Algunos puntos clave:

• Los procesos se implementan y actualizan

• Se adoptan prácticas de ingeniería de software para estandarizar

• Programas de capacitación para que cada persona pueda cumplir son sus roles.

En el nivel 3 se logra procesos estables y consistentes, gracias a las prácticas de ingeniería de software y la administración de proyectos.

Nivel 4. Administrado

En este nivel se usan todos los datos previamente recolectados para identificar causas raíz de problemas, es decir, se forma la base cuantitativa de la organización. Este nivel se basa en mucho en datos cuantitativos, ya que cada decisión será respaldada por dichos datos. En base a toda la información se podrá aumentar la probabilidad de ser más precisos y con esto eliminar la incertidumbre.

Nivel 5. Optimizado

En este nivel la organización se dedica totalmente a mejorar su proceso, probando nuevas formas de construir software, pero de manera controlada. Se analizan los procesos en busca de las fortalezas y debilidades. Cuando un defecto es encontrado, es revisado y sustituido, tomando las medidas necesarias para que no se vuelva a presentar.

Como se puede observar en la figura, se agrega una etapa para la optimización del proceso. En este nivel, los directivos podrán estimar los cambios dando un seguimiento cuantitativo a los mismos. En conclusión, en este nivel la organización se dedica al mejoramiento continuo de su proceso tanto en capacidad como en madurez, aplicando nuevas tecnologías y métodos.

Áreas de Procesos Clave (KPAs)

Un nivel de madurez será obtenido si y solo si todas las KPAs comprendidas son cubiertas de manera satisfactoria, para saber esto, será necesario revisar las metas definidas en cada KPA.

De los 5 niveles de madurez solo hay uno que no tiene KPAs definidas, este es el nivel 1.

Prácticas Clave

Las prácticas clave son un conjunto de actividades que nos ayudarán a alcanzar el cumplimiento de un KPA especifico. Las prácticas clave se organizan en 5 grupos:

1. Compromiso. Este grupo define las actividades necesarias para asegurar el cumplimiento de procesos, asegurarse que sea realizado y que persista. Normalmente hace referencia al establecimiento de políticas organizacionales.

2. Habilidades necesarias. Permite definir todos los requerimientos previos para que la organización puede implementar los procesos (recursos, estructuras organizacionales, capacitación).

3. Actividades realizadas. Define las actividades, procedimientos y roles para implementar un KPA.

4. Medición y análisis. Describe practicas necesarias para poder determinar un estatus sobre cada uno de los procesos o actividades.

5. Verificación e implementación. Describe las actividades necesarias para asegurarse que el proceso sea llevado de acuerdo con lo establecido. Auditorias por parte de la administración y aseguramiento de la calidad de software.

Roles

Será necesario especificar que personas ocuparán los siguientes roles, esto con el objetivo de asegurar el cumplimiento de los procesos, además de reducir tiempos, costos y recursos.

• Gerencia superior. Se necesitará un compromiso por parte de la gerencia superior.

• Gerentes. Deberán planear, organizar, dirigir, y controlar el trabajo dentro de su área.

• Líderes de proyectos. Deberá de dirigir, controlar, administrar y regular un proyecto para construir un sistema de software o hardware/software.

• Líder de tarea de software. Funge como líder para una tarea específica dentro del proyecto. Provee dirección técnica al staff de trabajo.

• El staff (no gerentes). Realizan tareas asignadas, como desarrollo de software o configuración

Grupos

• Grupo de Ingeniería de software

  • Conformado por Gerentes y Staff técnico

  • Responsable de actividades de desarrollo y manutención del software

• Grupo de Ingeniería de procesos de software

  • Conformado por especialistas

  • Responsable de facilitar la definición, mantenimiento y mejoramiento del proceso de software.

• Grupo de sistema

  • Conformado por gerentes y Staff técnico

  • Responsable de especificar los requerimientos del sistema, asignar y definir las interfaces y monitorear el desarrollo de los componentes.

• Grupo de Pruebas de sistema

  • Gerentes y staff técnico

  • Responsable de planear y realizar las pruebas del sistema para asegurarse que se cumplan con los requerimientos

• Grupo de aseguramiento de la calidad

  • Gerentes y staff técnico

  • Planear e implementar las medidas de calidad para asegurarse que los estándares sean seguidos.

• Grupo de Administración de configuración de software

  • Gerentes y staff técnico

  • Responsables de actividades para lograr la creación de servicios de control y soporte dentro de la organización. Control de versiones, soporte en a la administración de sus productos de trabajo. Establecer y mantener la integridad de los productos de trabajo mediante la identificación, control, reporte y auditoria a la configuración.

• Grupo de Entrenamiento

  • Conformado por gerentes y staff

  • Coordinar las actividades de entrenamiento en una organización.

Valoración y Evaluaciones

Para determinar el nivel de madurez de una organización existen las siguientes dos apreciaciones:

• Valoración del proceso de software

• Evaluación de la capacidad del software

Estos los pasos comunes tanto para la valoración y evaluación.

Beneficios del CMM

• Ayuda a formar una visión compartida

• Establece un lenguaje común al hablar de procesos de software

• Define un conjunto de prioridades para atacar los problemas de software

• Provee una estructura conceptual para mejorar la administración y desarrollo de software

• Aumenta la posibilidad de que una organización alcance sus metas de costos, calidad y productividad

• Se adquiere una mejora en el control

CMMI

La evolución a CMMI corresponde a la mejora del CMM, basando esta mejora en modelos enfocados a otros sectores de la industria, por ejemplo el CMMI toma como punto de arranque los siguientes modelos:

• SW-CMM (Ingeniería de software)

• EIA/IS-731 (Electronic Industries Alliance/Interim Standard)

• IPD-CMM (Desarrollo de producto integrado)