Empresas certificadas con CMMI en México y el mundo en el 2012

Isc091075 Violeta Tapia Hernández

Empresas certificadas con CMMI en México y el mundo en el 2012

La industria del software se ha extendido de manera extraordinaria, debido entre otras cosas, al abaratamiento de costos de hardware y a la necesidad de contar con sistemas de información y presencia en Internet tan sólo para permanecer competitivos. Sin embargo, un problema que ha plagado a la industria desde su nacimiento ha sido el tema de la calidad: existen escasas aproximaciones, estándares o mejores prácticas por lo que cientos de ingenieros de software, administradores de proyectos y académicos se han devanado los sesos para encontrar una solución ante constantes proyectos que fallan en cumplir las expectativas, se retrasan o consumen más presupuesto del que les fue otorgado. Sin embargo, uno de los modelos de calidad más recientes y que mayor aceptación ha tenido es el denominado Integración de Modelos de Madurez de Capacidades (Capability Maturity Model Integration – CMMI).

Los orígenes de CMMI

A principios de la década de 1980 varios proyectos encargados por el Departamento de Defensa de los Estados Unidos (US Department of Defense – DoD) se batieron de forma espectacular: los proveedores encargados de realizar dichos proyectos se extendieron más allá del presupuesto y tiempos provistos, si es que llegaron a terminarlos. Cabe destacar que en aquél entonces, todos los proyectos licitados por el gobierno de los Estados Unidos – incluyendo sus fuerzas armadas – elegían al ganador tan sólo basándose en el precio.

Así entonces, el DoD se vio forzado a fundar el Instituto de Ingeniería de Software (Software Engineering Institute – SEI) administrado por laUniversidad Carnegie Mellon, cuya misión primordial era determinar un marco o modelo de madurez con el que se podría juzgar la capacidad de una compañía para producir software. Para 1987 dicho instituto había desarrollado el Modelo de Capacidad y Madurez (Capability Maturity Model – CMM). En 1991, el SEI publicó la versión 1.0 del CMM para desarrollo de software (SW-CMM), con lo que más de 30,000 personas de aproximadamente 2,400 organizaciones fueron capacitadas para certificar a sus respectivas empresas en CMM y poder participar en licitaciones para el gobierno Estadounidense, que actualmente basa sus decisiones principalmente en el nivel de madurez de los participantes. Ya en 1997 se inician los trabajos para actualizar el CMM e incorporar estándares internacionales. En el año 2000 se libera la primera versión de este nuevo modelo, ahora denominado como CMMI:

CMMI es una estrategia de mejora de procesos que proporciona a las organizaciones los elementos esenciales que en última instancia, mejoran su rendimiento. CMMI puede ser usada para guiar la mejora de procesos en un proyecto, una división o una organización entera. Ayuda a integrar funciones tradicionalmente separadas de la organización, establece objetivos y prioridades de mejora de procesos, proporciona una guía para los procesos de calidad y proporciona un punto de referencia para evaluar los procesos actuales.

– CMMI Overview, Software Engineering Institute.

En pocas palabras, CMMI es una metodología de mejora de procesos, NO una metodología de desarrollo de software, de gestión de proyectos o de gestión del ciclo de vida de software. Básicamente CMMI es un checklist donde si el departamento, proyecto o empresa a evaluar posee los entregables que se esperan por cada nivel de madurez, pasará correctamente la certificación. En la actualidad existen cinco niveles de madurez cubiertos por el modelo, lo que permite identificar aquellas empresas que "están verdes" de aquellas que pueden asegurar con relativa autoridad, que saldrán adelante al implementar proyectos de alta complejidad y riesgo. En la siguiente tabla se muestran los cinco niveles así como las áreas de proceso que se evalúan dentro de cada nivel:

Nivel Enfoque Áreas de Proceso

5

Optimizado Mejora de procesos continua CAR – Análisis y Resolución Causal

OID – Innovación y Despliegue Organizacional

4

Cuantitativamente Administrado Gestión cuantitativa de los procesos QPM – Gestión de Proyectos Cuantitativa

OPP – Desempeño de Procesos Organizacionales

3

Definido Estandarización de procesos DAR – Análisis de Decisión y Resolución

IPM – Gestión Integral de Proyectos + IPPD

OPD – Definición Organizacional de Procesos + IPPD

OPF – Enfoque Organizacional de Procesos

OT – Capacitación Organizacional

PI – Integración de Productos

RD – Desarrollo de Requerimientos

RSKM – Gestión de Riesgo

TS – Solución Técnica

VAL – Validación

VER – Verificación

2

Administrado Gestión de proyectos básica CM – Gestión de la Configuración

MA – Medición y Análisis

PMC – Monitoreo y Control de Proyectos

PP – Planeación de Proyectos

PPQA – Aseguramiento de Calidad de Productos y Procesos

REQM – Administración de Requerimientos

SAM – Gestión de Acuerdo con Proveedores

1

Inicial Dependencia por personal competente ("héroes") y sus herramientas. Este nivel no es evaluado por CMMI.

De acuerdo al nivel de certificación se requerirán los documentos o pruebas de que los procesos a evaluar se están llevando a cabo. Por ejemplo, para la evaluación de CMMI Nivel 2, es necesario revisar el área de procesos denominada como Planeación de Proyectos (Project Planning – PP). Esto requiere demostrar que se están llevando a cabo las actividades correspondientes mediante los siguientes Objetivos Específicos (OE) así como las Prácticas Específicas (PE) de ésta área de procesos:

• OE 1: Establecer Estimados

° PE 1.1: Estimar el Alcance del Proyecto

° PE 1.2: Establecer Estimados del Trabajo y Tareas

° PE 1.3: Definir el ciclo de vida del proyecto

° PE 1.4: Determinar Estimados de Esfuerzo y Costo

• OE 2: Desarrollo de un Plan de Proyecto

° PE 2.1: Establecer el Presupuesto y Calendario

° PE 2.2: Identificar los Riesgos del Proyecto

° PE 2.3: Plan para Gestión de Datos

° PE 2.4: Plan de Recursos del Proyecto

° PE 2.5: Plan para Conocimiento y Habilidades Requeridos

° PE 2.6: Plan para Participación de Stakeholders

° PE 2.7: Establecer Plan de Proyecto

• OE 3: Obtener el compromiso con el Plan

° PE 3.1: Revisión de Planes que Afectan el Proyecto

° PE 3.2: Reconciliar Trabajo y Niveles de Recursos

° PE 3.3: Obtener

...