ITBA REPORTES TECNICOS CAPIS

CALIDAD DEL SOFTWARE

CMM - CAPABILITY MATURITY MODEL

Maestrando: Lic. Eduardo Diez

INTRODUCCION

El objetivo del presente artículo es brindar un análisis sobre la utilidad de aplicar los
lineamientos del Capability Maturity Model (CMM) en la obtención de productos de
software de calidad.

Con tal motivo, se desarrollarán brevemente, y sólo a modo de introducción, los

siguientes temas:

• Contexto y aspectos generales relativos a la ingeniería de software

• El paradigma de la calidad y sus principales elementos

Posteriormente, se brindará información específica del Capability Maturity Model,

tales como:

• Una breve descripción del CMM

• Estadísticas sobre la aplicación del CMM
• Críticas que se le suelen hacer al CMM

Finalmente, se presentarán:

• Un caso de aplicación con las experiencias y lecciones aprendidas

• Conclusiones finales

CONTEXTO

Antes de comenzar a tratar el tema de la calidad de software, es necesario situarse

en el contexto actual de la ingeniería de software. Este contexto se analizará desde
dos puntos de vista: La crisis del software y la realidad del software.

Crisis del software

En la década del 60 se reconoció que la ingeniería de software estaba en crisis. La

crisis perdura hasta nuestros días, siendo las principales características de la misma
las siguientes:

• El software no cubre todos los requisitos

• El software falla muy a menudo
1
ITBA REPORTES TECNICOS CAPIS
• El software debe ser modificado frecuentemente
• Los proyectos se retrasan o incluso se abandonan
• Los proyectos exceden los costos previstos

Por lo tanto, existe una recurrencia de la crisis del software con respecto a:

• Plazos
• Costos
• Expectativas
• Calidad

A modo de ejemplo, un reporte sobre contratos de desarrollo de software, realizado

en 1979 por el General Accounting Office (USA) revelaba los siguientes datos:

29%
Pagado y nunca 4%
entregado Usado como
se entregó

22%
45% Modificado o rehecho
No pudo para poder usarse
ser usado

Realidad del software

Por otro lado, existen hechos innegables relacionados con la ingeniería de software,
algunos de ellos son los siguientes:

• Existe una necesidad de software cada vez más complejo y crítico

• La producción de software es una actividad creativa e intelectual realizada,
principalmente, por seres humanos, que no se puede delegar a máquinas
• Las técnicas de ingeniería de software deben ser acompañadas por:
• Sentido común
• Competencia
• Experiencia
• Aceptación del principio de “No silver bullet”

De lo anterior se desprende que, cualquiera sea la solución que se busque a la crisis

del software, ésta no será mágica, única ni prescindirá de la participación humana.

2
ITBA REPORTES TECNICOS CAPIS

ASPECTOS GENERALES

Además del contexto ya presentado, se tratará brevemente el concepto de proceso

de software, ya que el artículo girará alrededor del mismo.

Proceso de software

A continuación se dan dos definiciones de proceso de software:

• Es el proceso a través del cual los requerimientos de usuario son traducidos en

especificaciones funcionales, las especificaciones funcionales en especificaciones
de diseño, las especificaciones de diseño en código, el cual es testeado,
documentado y liberado para ser usado por el usuario (IEEE)

• Es el conjunto de herramientas, métodos y prácticas que usamos para producir un

producto de software (Humphrey W.)

Ahora bien, el proceso de software en cualquier organización puede ser inmaduro o

maduro.

Proceso inmaduro

Un proceso de software inmaduro, tendrá las siguientes características:

• Improvisación
• Falta de rigurosidad
• Organización reactiva - Apaga incendios
• Requerimientos no controlados
• La ausencia de mediciones provoca la falta de base para predecir atributos del
proceso o del producto
• Excesos en plazos y presupuestos previstos
• Sacrificio de calidad y funcionalidad

Proceso maduro

Por su parte, un proceso de software maduro, tendrá las siguientes características:

• Administración de requerimientos y del proceso

• Proceso comunicado, usable, consistente y actualizado
• Roles y responsabilidades definidas
• Monitoreo gerencial
• Las mediciones rigurosas generan una base objetiva para predecir y juzgar
atributos del proceso y del producto
• Realismo de cronogramas y presupuestos
• Se alcanzan los resultados esperados
3
ITBA REPORTES TECNICOS CAPIS
PARADIGMA DE LA CALIDAD

El paradigma de calidad es aplicable a todas las actividades que se llevan a cabo en

una organización, en el artículo se tratarán los principios generales y su
aplicabilidad a la ingeniería de software.

Principales elementos

Veamos cuales son los principales elementos del paradigma:

• La naturaleza de la calidad: Orientación a los aspectos o características de un

producto o servicio que influyan en su capacidad para satisfacer necesidades
dadas, más que a la adecuación a estándares o a especificaciones
• La perspectiva del proceso: Focalización en el proceso más que en el producto
• Orientado a datos: Basado en la recolección, análisis y comparación de datos
• Focalización en el cliente: La obtención de la satisfacción del cliente es el objetivo
final de todo proceso
• Eliminación de defectos: Priorización de técnicas de prevención de defectos sobre
técnicas de detección y corrección
• Gestión para la calidad: La adopción del paradigma requiere del compromiso de la
alta dirección

Aplicación en ingeniería de software

En la ingeniería de software, la visión de la calidad no es única, dependiendo del

punto de vista desde el cual se la analice, se priorizarán distintos atributos:

Usuario:
Atributos externos
del producto

Ingeniero de software: Gerente de proyecto:

Atributos internos Atributos del proceso
del producto

4
 ITBA REPORTES TECNICOS CAPIS
Por otro lado, aplicar el paradigma no es tarea fácil en la ingeniería de software, ya
que los principios son casi siempre vagos y abstractos, y las consideraciones son
muy generales e imprecisas.

Adicionalmente, el profesional de ingeniería de software cuenta con una batería de

conceptos y actividades relacionadas con la calidad, pero que no suelen integrarse
correctamente, tales como:

• Testing
• Revisiones
• Verificaciones
• Auditorías
• SQA

De lo anterior se concluye que es lógico que exista un gran desconcierto por parte
de los profesionales de ingeniería de software al encarar un proyecto de mejora de
calidad del software. Este desconcierto se puede sintetizar en los siguientes
interrogantes:

• ¿Por dónde se empieza?

• ¿Se debe priorizar un punto de vista?
• ¿Qué punto de vista se prioriza?
• ¿La mejora debe ser gradual?
• ¿Cómo se estructura la mejora?
• ¿Cuánto se tarda en mejorar?
• ¿Cuánto cuesta mejorar?
• ¿Vale la pena?

Algunas de las organizaciones, modelos y normas que intentan dar respuestas a

éstos interrogantes son los siguientes:

• ISO - SPICE: Software Process Improvement and Capability Determination

• IEEE: Institute of Electrical and Electronics Engineering
• ESA: European Software Agency
• SEI - CMM: Capability Maturity Model

CMM - CAPABILITY MATURITY MODEL

Orígenes y evolución

Fue concebido en el año 1987 por el Instituto de Ingeniería de Software (SEI) de la

Universidad Carnegie Mellon (CMU).

Su principal objetivo era calificar a proveedores de software del Departamento de

Defensa (DoD) de USA, pero el modelo fue incorporado paulatinamente por
numerosas empresas.

5
 ITBA REPORTES TECNICOS CAPIS
Es actualmente un esquema que representa un camino de mejoramiento
recomendado para organizaciones que quieren incrementar la capacidad de su
proceso de software.

Usos

El CMM soporta los siguientes usos:

• Comprender las actividades necesarias para planear e implementar un programa

de mejora del proceso de software (SPI)
• Definir y mejorar el proceso de software
• Identificar fortalezas y debilidades en las organizaciones
• Identificar los riesgos de seleccionar entre diferentes proveedores de software

Fundamentos

Los siguientes son los fundamentos del modelo:

• La madurez recorre diferentes etapas

• La clave del crecimiento es entender dónde se está y a dónde se quiere llegar
• El proceso se mejora evolucionando a partir de lo preexistente
• El progreso requiere concentrar los esfuerzos en pocas áreas

Generalidades

A modo de introducción a temas que se desarrollarán a lo largo del artículo, se

mencionan las siguientes características del CMM:

• El modelo incorpora los principales elementos del paradigma de la calidad

• El modelo identifica:
• 5 niveles de madurez
• Mejoras claves requeridas por cada nivel
• Un orden de prioridades para escalar a niveles superiores
• El SEI proporciona:
• Servicio de apreciaciones (Assessments) del proceso de software (SPA)
• Programa de evaluación de la capacidad del software (SCE)

Estructura

La estructura completa del modelo se representa en el siguiente gráfico:

6
ITBA REPORTES TECNICOS CAPIS
Niveles de Contiene
madurez

Indica Areas clave Organizado por

de proceso

Capacidad del Alcanza Aspectos Contiene

proceso comunes

Encara Practicas
Metas
clave

Implement. e Describe
Institucional.

Infraestructura
o actividades

A continuación se describen brevemente cada uno de los componentes de la

estructura.

Niveles de madurez

Los niveles de madurez se representan en el siguiente gráfico:

Proceso en Nivel 5
mejora continua Optimizado

Proceso Nivel 4
predecible Administrado

Proceso Nivel 3
estándar consistente Definido

Proceso Nivel 2
disciplinado Repetible

Nivel 1
Inicial

7
ITBA REPORTES TECNICOS CAPIS
Características por nivel

NIVEL 1 - INICIAL

• Proceso ad-hoc y a veces caótico

• La organización generalmente opera sin procesos formalizados, estimaciones de
costo o planes de proyecto
• Aunque existan algunos procesos formalizados, no existen mecanismos que
permitan asegurar que se cumplan
• El éxito depende del esfuerzo individual
• Una representación gráfica del nivel podría ser la siguiente:

NIVEL 2 - REPETIBLE

• Procesos básicos de gestión para manejar costos, cronogramas y funcionalidad

establecidos
• La disciplina del proceso permite la repetición de éxitos anteriores en proyectos
similares
• La fuerza de la organización está dada por la existencia de experiencia en
desarrollo de procesos similares pero existen riesgos al presentarse nuevos
desafíos
• Una representación gráfica del nivel podría ser la siguiente:

NIVEL 3 - DEFINIDO

• El proceso para gerentes e ingenieros está documentado e integrado en un

proceso estándar para la organización
• Todos los proyectos usan una versión aprobada y adaptada del proceso estándar
de la organización
• Un grupo de proceso de ingeniería de software (SEPG) ha sido establecido para
focalizar y liderar esfuerzos de mejora
• Una representación gráfica del nivel podría ser la siguiente:

8
ITBA REPORTES TECNICOS CAPIS
NIVEL 4 - ADMINISTRADO

• Existen mediciones detalladas del proceso y calidad del producto

• El producto y el proceso son cuantitativamente conocidos y controlados
• Una representación gráfica del nivel podría ser la siguiente:

NIVEL 5 - OPTIMIZADO

• La organización busca identificar aquellos elementos más débiles del proceso y

optimizarlos sobre la base de un análisis defecto-causa y prevención de defectos
• Existen datos que justifican la aplicación de nuevas ideas o tecnologías a
determinadas tareas críticas y la evidencia cuantitativa permite conocer el grado
de eficacia alcanzado al implementarlas en proyectos piloto
• Una representación gráfica del nivel podría ser la siguiente:

Areas clave de proceso

Son las mejoras claves requeridas por cada nivel, para acceder al siguiente:

NIVEL 2 - REPETIBLE

Se concentran en establecer controles básicos de gestión de proyectos:

• Administración de requerimientos
• Planificación de proyectos de software
• Control y supervisión de proyectos
• Supervisión de subcontratos de software
• Afirmación de calidad del software
• Supervisión de la configuración del software

9
ITBA REPORTES TECNICOS CAPIS

NIVEL 3 - DEFINIDO

Direccionan aspectos organizacionales y del proyecto, lo que establece una

infraestructura que institucionaliza procesos de ingeniería de software y gestión, a lo
largo de todos los proyectos:

• Focalización orgánica en el proceso

• Definición de proceso organizacional
• Programa de entrenamiento
• Administración integrada del software
• Ingeniería de producto
• Coordinación intergrupal
• Revisiones por pares

NIVEL 4 - ADMINISTRADO

Se concentran en establecer una comprensión cuantitativa y cualitativa del proceso y

de los productos:

• Administración cuantitativa del proceso

• Administración de la calidad del software

NIVEL 5 - OPTIMIZADO

Cubren los aspectos de la organización y de los proyectos que deben atenderse

para
implementar una mejora continua y medible del proceso de software:

• Prevención de defectos
• Administración del cambio del proceso
• Administración del cambio tecnológico

Aspectos comunes

Son atributos que permiten que la implementación o institucionalización de un área

clave de proceso sea efectiva, repetible y perdurable, por ejemplo:

• Compromisos para la ejecución

• Habilidad para ejecutar
• Actividades a ejecutar
• Mediciones y análisis
• Verificación de implementación

10
ITBA REPORTES TECNICOS CAPIS
Practicas clave

Describen una infraestructura o actividades necesarias para implementar o

institucionalizar un área clave de proceso.

Evaluación del proceso

Finalmente, la evaluación tiene como objetivo determinar y evaluar la capacidad y

madurez del proceso de software de una organización, y ubicarlo en un nivel del
CMM. Existen dos tipos de evaluaciones:

• Apreciación (Assessment) del proceso de software (SPA): Realizada por

profesionales del SEI o autorizados o independientes, en conjunto con personal
de la organización. Se asemeja a contratar una consultoría.
• Evaluación de la capacidad del software (SCE): Realizado por agentes
gubernamentales a contratistas o proveedores de software. Se asemeja a una
auditoría externa.

Ambas evaluaciones se basan en las respuestas, por Si o por No, a un cuestionario

y en la aplicación de un algoritmo sobre las mismas.

ESTADISTICAS SOBRE LA APLICACION DEL CMM

A continuación se presenta una serie de estadísticas y observaciones relativas a la

aplicación del modelo:

El nivel de madurez de las organizaciones, según un estudio del Software

Engineering Measurement and Analisys Team del SEI, realizado en Marzo de 1996
sobre un total de 477 organizaciones, 83% de las cuales corresponden a USA, es el
siguiente:

70%

60%

50%

40%

30%

20%

10%

0%
Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5
68.8% 18.0% 11.3% 1.5% 0.4%

11
 ITBA REPORTES TECNICOS CAPIS
Los cambios en el nivel de madurez de las organizaciones, según un estudio del
Software Engineering Measurement and Analisys Team del SEI, realizado en Marzo
de 1996 sobre un total de 28 re-apreciaciones, es el siguiente:

11%
Bajó el nivel

18%
71% Permaneció
Elevó el nivel igual

Algunos datos promedio de un estudio realizado sobre los primeros 3 niveles

(Estudio de Junio de 1997 - Fuente: [1]) son los siguientes:

• Tiempo requerido para pasar del nivel 1 al 2: 26 meses

• Tiempo requerido para pasar del nivel 2 al 3: 24 meses
• Inversión aproximada requerida: 1400 U$S por año por ingeniero de software
• Reducción de defectos post-release alcanzada: 39% por año
• Productividad ganada: 35% por año
• Relación costo/beneficio lograda: 1 a 5

Algunas observaciones del estudio realizado sobre los primeros 3 niveles (Estudio
de Junio de 1997 - Fuente: [1]) son las siguientes:

• Mejora en la capacidad para alcanzar:

• Cronogramas y presupuestos previstos
• Calidad del producto requerida
• Mejora de la moral del equipo de desarrollo
• Baja la satisfacción del cliente en nivel 2 y sube considerablemente en el nivel 3

CRITICAS USUALES

A continuación se presentan las principales críticas que se le suelen hacer al CMM.

El objetivo del presente artículo no es analizar cada una de las críticas, sino
solamente mencionarlas:

• El algoritmo utilizado para calificar el proceso de software de una organización no

es el adecuado y las preguntas clave no son correctas ni suficientes
• Las preguntas utilizadas en la evaluación son binarias (Si - No), lo que no permite
registrar los matices de la realidad
• El modelo es sólo aplicable a grandes organizaciones que desarrollan grandes
proyectos
12
ITBA REPORTES TECNICOS CAPIS
• El modelo permite comparar procesos de software de grandes organizaciones con
los de pequeñas organizaciones, favoreciendo a las primeras
• La aplicación del modelo requiere una inversión importante
• La aplicación del modelo vuelve a una organización rígida, burocrática y menos
capaz de encontrar soluciones creativas a problemas técnicos
• El nivel 1 es una “bolsa” en la que se ubican organizaciones con niveles de
madurez muy diferentes
• Los niveles de madurez no garantizan el éxito. Existen proyectos exitosos en el
nivel 1 y fracasos en niveles superiores
• Algunas de las prácticas de medición recomendadas por el SEI han demostrado
no funcionar (por ej. los basados en líneas de código)

APLICACION DEL CAPABILITY MATURITY MODEL

Experiencia

En la Gerencia de Sistemas de una compañía administradora de redes de cajeros

automáticos, se decidió iniciar un proyecto de mejora de calidad del proceso
software.

La situación al iniciar el proyecto era la típica de toda organización de nivel 1,

reuniendo todas sus características.

Adicionalmente existían distintos departamentos de desarrollo, cada uno de ellos

con características y operatorias propias, y proyectos interdepartamentales.

Se conforma un Equipo de Ingeniería de Software, con integrantes de cada uno de

los departamentos, con el objeto de mejorar el proceso de software.

Luego de una etapa de desconcierto en la cual el equipo no sabía como encarar el

tema, se accedió a material bibliográfico referente al CMM.

Se siguen entonces los lineamientos del CMM, adaptándolos a las características y

problemática de la organización. Al poco tiempo se determinan las principales
falencias y se establecen objetivos inmediatos.

Los logros obtenidos a la fecha, como consecuencia del proyecto emprendido son
los siguientes:

• Establecimiento de un lenguaje común entre departamentos

• Establecimiento de una forma común de administrar proyectos
• Se contrató una consultora para apoyar el proceso
• Se creó la función de SQA
• Se está definiendo un ciclo de vida estándar

Lecciones aprendidas

13
ITBA REPORTES TECNICOS CAPIS
Se han aprendido las siguientes lecciones como consecuencia de la aplicación del
modelo:

• El proceso de mejora requiere el compromiso visible de la dirección de la

organización, el soporte de los distintos niveles jerárquicos y el involucramiento de
los equipos de desarrollo

• El proceso de mejora debe ser planeado, gestionado y se le deben asignar

suficientes recursos

• El proceso de mejora requiere un cambio cultural en toda la organización, es por

ello que debe ser coordinado con todas las áreas

• Es importante conseguir resultados rápidamente para mantener la motivación, el

esfuerzo y el interés

• No es serio plantear objetivos de mejora sin plazos de concreción.

• Es negativo que existan en la organización experiencias previas de procesos de

mejora no exitosos.

• El proceso de mejora no debe ser abandonado, suspendido o disminuido a causa

de otros eventos.

• El SEPG debe ser integrado por personas altamente reconocidas

profesionalmente.

• Es conveniente contar con soporte adicional de profesionales con experiencia en

mejoras de procesos de software

CONCLUSIONES

De lo expuesto se pueden extraer las siguientes conclusiones:

• El paradigma de la calidad es aplicable a la ingeniería de software por medio de

modelos de mejora.

• El CMM es un modelo efectivo para mejorar el proceso de software y por ende la

calidad de sus productos, pero no es el único.

• Un buen profesional debe determinar objetivamente cuál es el modelo que más

conviene aplicar en una organización dadas las características de la misma.

• Es válido que una organización adecue y adapte un determinado modelo a sus

propias características.

14
ITBA REPORTES TECNICOS CAPIS
• Cualquiera sea el modelo seleccionado, el proceso de mejora requiere
compromiso, inversión y constancia.

GLOSARIO

• CMM: Capability Maturity Model

• CMU: Carnegie Mellon University
• DoD: Department of Defense
• ESA: European Software Agency
• IEEE: Institute of Electrican and Electronics Engineering
• ISO: International Standard Organization
• SCE: Software Capability Evaluation
• SEI: Software Engineering Institute
• SEPG: Software Engineering Process Group
• SPA: Software Process Assessment
• SPI: Software Process Improvement
• SPICE: Software Process Improvement and Capability Determination
• SQA: Software Quality Assurance

BIBLIOGRAFIA

Libros

• Software Engineering Institute

The Capability Maturity Model: Guidelines for Improving the Software Process
Addison-Wesley, Reading, Pa. 1995
• Humphrey W.
A Discipline of Software Engineering
Addison-Wesley, Reading, Pa. 1995
• Humphrey W.
Managing the Software Process
Addison-Wesley, Reading, Pa. 1989

15
ITBA REPORTES TECNICOS CAPIS

Artículos

• Fox C. - Frakes W.
The Quality Approach: Is it Delivering?
Communications of the ACM - Junio 1997 - Vol. 40 - Nro. 6
• [1] Herbleb J. - Zubrow D. - Goldenson D. - Hayes W. - Paulk M.
Software Quality and the Capability Maturity Model
Communications of the ACM - Junio 1997 - Vol. 40 - Nro. 6
• [2] Software Engineering Measurement and Analisys Team
Process Maturity Profile of the Software Community - 1996 Update
SEI - CMU - Abril 1996
• Jones C.
Model Flaws: Gaps in SEI Programs
Software Development - Marzo 1995
• Bollinger T. - McGowan C.
A Critical Look at Software Capability Evaluations
IEEE Software - Julio 1991

16
ITBA REPORTES TECNICOS CAPIS

17