Traducido del inglés al español - www.onlinedoctranslator.

com

La inmadurez de CMM
por James Bach
james@satisfice.com
(Anteriormente de Borland International)
Este artículo se publicó originalmente en la edición de septiembre = 9194 de American Programmer.

El modelo de madurez de capacidad (CMM) del Software Engineering Institute (SEI) recibe mucha publicidad. Dado que el
instituto está financiado por el Departamento de Defensa de los EE. UU. por una suma de decenas de millones de dólares
cada año [1], esto no debería sorprender = 97 la gente del SEI son los expertos en procesos oficiales de las fuerzas armadas,
y tienen los recursos para correr la voz sobre lo que hacen. Pero, dado también que el CMM es un conjunto amplio y cada
vez más profundo de afirmaciones sobre lo que constituye una buena práctica de desarrollo de software, es razonable
preguntarse de dónde provienen esas afirmaciones y si de hecho son completas y correctas.

Mi tesis, en este ensayo, es que el CMM es una mitología particular de la evolución del proceso de software que no puede
pretender legítimamente ser una representación natural o esencial de los procesos de software.

El CMM es, en el mejor de los casos, un consenso entre un grupo particular de teóricos y profesionales de la ingeniería de software sobre
una colección de prácticas efectivas agrupadas de acuerdo con un modelo simple de evolución organizacional. Como tal, es potencialmente
valioso para aquellas empresas que carecen por completo de conocimientos de software, o para aquellas que tienen mucho y, por lo tanto,
pueden evitar sus escollos.

En el peor de los casos, el CMM es un encubrimiento que oscurece la verdadera dinámica de la ingeniería de software y suprime
los modelos alternativos. Si una organización lo sigue por sí mismo, en lugar de simplemente como un requisito exigido por un
contrato gubernamental en particular, es muy posible que conduzca al colapso del potencial competitivo de esa empresa. Por
estas razones, el CMM es impopular entre muchas de las empresas altamente competitivas e innovadoras que producen software
comercial de envoltura retráctil.

Una breve descripción del CMM

El CMM [7] fue concebido por Watts Humphrey, quien se basó en el trabajo anterior de Phil Crosby. El desarrollo
activo del modelo por parte del SEI comenzó en 1986.
Consiste en un grupo de "prácticas clave", ni nuevas ni exclusivas de CMM, que se dividen en cinco niveles que representan
las etapas que deben atravesar las organizaciones en el camino hacia la "madurez". El SEI ha definido un riguroso método
de evaluación de procesos para evaluar qué tan bien una organización satisface las metas asociadas con cada nivel. Se
supone que la evaluación debe ser dirigida por un evaluador líder autorizado.

Los niveles de madurez son:

1. Inicial (caótico, ad hoc, heroico)

2. Repetible (gestión de proyectos, disciplina de procesos)
3. Definido (institucionalizado)
4. Gestionado (cuantificado)
5. Optimización (mejora de procesos)

Se supone que una forma en que las empresas deben usar el modelo es primero evaluar su nivel de madurez y luego formar un
plan específico para llegar al siguiente nivel. No se permite saltarse niveles.

El CMM se pensó originalmente como una herramienta para evaluar la capacidad de los contratistas gubernamentales para realizar
un proyecto de software contratado. Puede ser adecuado para ese propósito; No sé. Mi preocupación es que también se
promociona como un modelo general para la mejora de procesos de software. Enqueaplicación, el CMM tiene serias debilidades.

Las empresas de envoltura retráctil, que también se han denominado empresas comerciales listas para usar o empresas de
paquetes de software, incluyen Borland, Claris, Apple, Symantec, Microsoft y Lotus, entre otras. Muchas de estas empresas rara vez
gestionan sus documentos de requisitos de forma tan formal como describe el CMM. Este es un requisito para

alcanzar el nivel 2, por lo que todas estas empresas probablemente caerían en el nivel 1 del modelo.

Críticas al CMM
Un estudio exhaustivo de las críticas al CMM está fuera del alcance de este artículo. Sin embargo, Capers Jones
y Gerald Weinberg son dos críticos notables.
en su libroEvaluación y Control de Riesgos de Software[6], Jones analiza su propio modelo, Software Productivity Research
(SPR), que fue desarrollado independientemente de CMM aproximadamente al mismo tiempo y compite con él en la
actualidad. Jones dedica un capítulo a delinear las debilidades del CMM. SPR tiene en cuenta muchos factores que CMM
actualmente ignora, como aquellos que contribuyen a la productividad de los ingenieros individuales.

En los dos volúmenes de suGestión de software de calidadserie [12,13], Weinberg está en desacuerdo con el concepto mismo de
madurez aplicado a los procesos de software, y en su lugar sugiere un paradigma basado enpatronesde comportamiento Weinberg
modela los procesos de software como interacciones entre humanos, en lugar de entre construcciones formales. Su enfoque
sugiere una evolución del "liderazgo de resolución de problemas" en lugar de procesos enlatados.

Problemas generales con CMM

No tengo el espacio para ampliar completamente todos los problemas que veo en el CMM. Aquí están los más grandes desde mi punto
de vista como especialista en procesos en el mundo de la envoltura retráctil:
=B7 El CMM no tiene una base teórica formal. Se basa en la experiencia de "gente muy bien informada". Por lo tanto,
la teoría subyacente de facto parece ser que los expertos saben lo que están haciendo. De acuerdo con tal principio,
cualquier otro modelo basado en experiencias de otras personas conocedoras tiene la misma veracidad.

=B7 El CMM solo tiene un apoyo empírico vago. Es decir, el respaldo empírico para CMM también podría interpretarse
para respaldar otros modelos. El modelo se basa principalmente en la experiencia de grandes contratistas gubernamentales
y en la propia experiencia de Watts Humphrey en el mundo de los mainframe. No tiene en cuenta el éxito de las empresas
retractiladas, y los niveles 1, 4 y 5 no están bien representados en los datos: el primero porque está tergiversado, los dos
últimos porque hay muy pocas organizaciones en esos niveles. El SEI, Mark Paulk, puede citar numerosos informes de
experiencia que respaldan a CMM, y me dice que se está realizando un estudio de validación formal. Eso está muy bien,
pero los informes anecdóticos que he visto y escuchado sobre el éxito con el CMM podrían interpretarse como evidencia del
éxito de las personas que trabajan juntas para lograr cualquier cosa. En otras palabras, sin uncomparaciónde modelos de
procesos alternativos bajo condiciones controladas, el caso empírico nunca puede cerrarse. Por el contrario, el caso se
mantiene abierto por los continuos contraejemplos en forma de organizaciones exitosas de nivel 1 y por la curiosa falta de
datos sobre las fallas del CMM (que puede deberse a la reticencia natural por parte de las empresas a detenerse en sus
errores, o de la SEI para registrarlos).

=B7 El CMM venera el proceso, pero ignora a las personas. Esto es evidente para cualquiera que esté familiarizado con el
trabajo de Gerald Weinberg, para quien los problemas de la interacción humana definen la ingeniería. Por el contrario, tanto
Humphrey como CMM mencionan a las personas de pasada [5], pero también las critican como poco confiables y asumen que los
procesos definidos pueden hacer que la excelencia individual sea menos importante. La idea de que el proceso compensa la
mediocridad es un pilar del CMM, en el que los humanos aparentemente están subordinados a procesos definidos. Pero, ¿dónde
está la justificación de esto? Para hacer que la excelencia sea menos importante, las tareas de resolución de problemas tendrían
que incorporarse de algún modo al proceso mismo. Nunca he visto un proceso así, pero si existe, tendría que ser bastante
complejo. Imagine una definición de proceso para jugar un juego de ajedrez repetiblemente bueno. Tal proceso existe, pero solo es
útil para las computadoras; un proceso útil para los humanos no ha sido documentado ni enseñado como una serie de pasos
inequívocos. ¿No son los problemas de software al menos tan complejos como los problemas de ajedrez?

=B7 El CMM venera la institucionalización del proceso por su propio bien. Dado que el CMM se preocupa principalmente por la
capacidad de compromiso de una organización, este sesgo es comprensible. Pero, la capacidad de compromiso de una organización es
simplemente una expresión de la capacidad de ejecución de un equipo de proyecto. Incluso si los procesos necesarios no están
institucionalizados formalmente, es muy posible que estén en su lugar, de manera informal, en virtud de la habilidad de los miembros del
equipo. La institucionalización no garantiza nada, y los esfuerzos por institucionalizar a menudo conducen a una bifurcación entre un
proceso público demasiado simplificado y un rico proceso privado que debe practicarse de manera encubierta. Incluso si la
institucionalización es útil, ¿por qué no institucionalizar un sistema para identificar y mantener a los contribuyentes clave en la organización
y dejarles los procesos a ellos?

=B7 El CMM contiene muy poca información sobre la dinámica del proceso. Esto hace que sea confuso discutir la
relación entre prácticas y niveles con un proponente de CMM, debido a todas las suposiciones ocultas. Por ejemplo, ¿por
qué no se entrena en el nivel 1? La capacitación es especialmente importante en el nivel 1, donde puede
adoptar la forma de tutoría o de formación genérica en cualquiera de las competencias de la ingeniería del software. La
respuesta parece ser quenadase coloca en el nivel 1, porque el nivel 1 se define simplemente como no estar en el nivel 2. La
suposición oculta aquí es que no importa quiénes somos, qué problemas enfrentamos y lo que ya estamos haciendo:solo
llega al nivel 2. En otras palabras, el CMM no percibe ni se adapta a las condiciones de la organización cliente. Por lo tanto, el
entrenamiento o cualquier otra práctica informal en el nivel 1, sin importar cuán efectiva sea, podría ser aplastada
accidentalmente por un CMM ciego y estático. Otro ejemplo: ¿Por qué la prevención de defectos es una práctica de nivel 5?
En Borland utilizamos autopsias de proyectos para analizar y mejorar nuestros procesos, ¿no es eso una forma de
prevención de defectos? Hay muchos ejemplos de este tipo que podría citar, basados en una lectura del documento CMM
1.1 (aunque no revisé el voluminoso documento de Prácticas Clave) y el apéndice de Humphrey's Gestión del proceso de
software [5]. Básicamente, la mayoría y quizás todas las prácticas clave podrían realizarse de manera útil en el nivel 1,
dependiendo de la dinámica particular de la organización en particular. En lugar de modelar realmente esas dinámicas de
proceso, como lo hace Weinberg en su trabajo, el CMM simplemente las estratifica.

=B7 El CMM fomenta el desplazamiento de las metas de la verdadera misión de mejorar el proceso a la misión
artificial de lograr un mayor nivel de madurez. A esto lo llamo "envidia de nivel", y generalmente tiene el efecto de cegar a
una organización sobre el uso más efectivo de sus recursos. El propio SEI reconoce esto como un problema y ha tomado
algunas medidas para corregirlo. Sin embargo, el problema está integrado en la estructura misma del modelo y será muy
difícil de exorcizar.

Pies de barro: El malentendido fundamental del CMM sobre las Organizaciones de nivel 1

El mundo de la tecnología prospera mejor cuando se deja a las personas solas para que sean diferentes, creativas y desobedientes.
- - Don Valentine, capitalista de riesgo de Silicon Valley [8]

Además de las preocupaciones mencionadas anteriormente, el argumento más poderoso contra el CMM como
receta efectiva para los procesos de software son las muchas empresas exitosas que, según el CMM, no deberían
existir. Este punto se hace más fácilmente en el contexto de Silicon Valley.

de tom peters,Prosperando en el caos[9], equivale a un manifiesto para Silicon Valley. Sitúa la innovación, la no
linealidad y la revolución en curso en el centro de su visión del mundo. Aquí en el Valle, la innovación reina
suprema, y es desde el punto de vista del innovador que el CMM parece más perdido. La experiencia personal en
Apple y Borland, y el contacto con muchos otros en la década que pasé aquí, respaldan esta opinión.

Los defensores del CMM comúnmente confunden a sus críticos como antiproceso, y algunos de nosotros lo somos. Pero muchos de
nosotros, incluyéndome a mí, somos especialistas en procesos. Creemos en los tipos de procesos que respaldan la innovación. Nuestro
énfasis está en el liderazgo sistemático de resolución de problemas para permitir la innovación, en lugar del mero control de procesos
para permitir soluciones estándar.

La innovación per se no aparece en el CMM en absoluto, y solo se sugiere en el nivel 5. Esto es impactante, ya que las empresas
más innovadoras en la industria del software (por ejemplo, General Magic, pionera en tecnología de comunicación digital personal)
operar en el nivel 1, según el modelo. Esto incluye también a Microsoft, y ciertamente a Borland [2]. Sin embargo, en términos de
CMM, estas empresas no se consideran diferentes a cualquier nueva empresa fallida o empresa siderúrgica paralizada. Por el
contrario, empresas como IBM, que según todos los informes ha hecho un verdadero lío con el Proyecto de Automatización
Avanzada de la Administración Federal de Aviación, obtienen una puntuación alta en términos de madurez (según un miembro de
un equipo de auditoría del gobierno con el que hablé).

Ahora, el SEI argumenta que la innovación está fuera de su alcance y que el CMM simplemente establece un marco
dentro del cual la innovación puede ocurrir más libremente. De acuerdo con la literatura de innovación, sin embargo,
nada podría estar más lejos de la verdad. Preocupado por la previsibilidad, el CMM ignora por completo la dinámica de
la innovación.

Dicha dinámica está documentada enProsperando en el caos,Reingeniería de la Corporación[4], yLa quinta disciplina[10], tres
conocidos libros sobre innovación empresarial. Donde los innovadores aconsejan a las empresas que sean flexibles, el CMM les
aconseja que sean predecibles. Donde los innovadores sugieren empujar la autoridad hacia abajo en la organización, el CMM la
empuja hacia arriba. Donde los innovadores recomiendan una innovación constructiva constante, el CMM lo confunde con el caos
en el nivel 1. Donde los innovadores dependen de un rastro de experiencias de aprendizaje, el CMM depende de un rastro de
papel.
En ninguna parte es más evidente el cisma entre estas cosmovisiones opuestas que en la cuestión del heroísmo. El SEI considera
el heroísmo como un sacrificio insostenible por parte de individuos particulares que tienen dones especiales. Considera que el
heroísmo es la única razón por la que las empresas de nivel 1 tienen éxito, cuando tienen éxito.
El heroísmo que se practica con más frecuencia en las empresas exitosas de nivel 1 es algo mucho menos místico.
Nuestro heroísmo significa tomar la iniciativa para resolver problemas ambiguos. Esto no significa quemar a la gente y
tirarla, como afirma el SEI. El heroísmo es un conjunto de comportamientos definibles y enseñables que mejoran y
honran la creatividad (como ha demostrado una unidad del Centro de Microelectrónica de United Technologies [3]). Es
comunicación y respeto mutuo. Significa el despliegue selectivo de procesos, no de acuerdo con el mandato de gestión,
sino de acuerdo con las habilidades del equipo.

El dominio personal está en el centro del heroísmo, pero tampoco tiene cabida en el CMM, excepto a través de la
institución de un programa de formación formal. Peter Senge [10], tiene esto que decir sobre el dominio:

"Hay razones obvias por las que las empresas se resisten a fomentar el dominio personal. Es 'suave', basado en parte
en conceptos no cuantificables como la intuición y la visión personal. Nadie podrá medir con tres decimales cuánto
contribuye el dominio personal a la productividad. y el resultado final. En una cultura materialista como la nuestra, es
difícil incluso discutir algunas de las premisas del dominio personal. '¿Por qué la gente necesita hablar de estas
cosas?' alguien puede preguntar. '¿No es obvio? ¿No lo sabemos ya?'"

Este es, creo, el corazón del problema y la razón por la cual CMM es peligroso para cualquier empresa fundada en la
innovación. Debido a que el CMM desconfía de las contribuciones personales, ignora las condiciones necesarias para nutrir
las ideas no lineales y se contenta con enterrarlas bajo una superestructura restrictiva, alcanzar el nivel 2 en la escala del
CMM puede muy bien apagar la única llama que encendió a la empresa. para empezar.
No dudo que tales compañías se vuelvan más predecibles, en la forma en que la vida se vuelve predecible si decidimos no salir
nunca de nuestras camas. Dudo que esas empresas puedan tener éxito durante mucho tiempo en un mundo dinámico si
trabajan en pijama.

Una alternativa a CMM

Si no es el modelo de madurez, ¿por qué marco podemos guiar la mejora genuina del proceso? Los marcos alternativos se
pueden encontrar en forma genérica enProsperando en el caos, que contiene 45 "recetas", oLa quinta disciplina, que
presenta, como es lógico, cinco disciplinas. las prescripciones deProsperando en el caosestán incorporados en una
herramienta organizacional llamadaLa auditoría de excelencia, yEl libro de campo de la quinta disciplina[11], que brinda
orientación adicional para crear organizaciones de aprendizaje, ya está disponible.

Una ventaja de estos modelos es que proporcionan dirección, sin imponer una forma particular a la
organización. En realidad, brindan orientación para crear un cambio organizacional.

Específico a la ingeniería de software, estoy trabajando en un modelo de proceso en Borland que consiste en un marco de
siete dimensiones para analizar problemas e identificar los procesos necesarios. Estas dimensiones son: factores
comerciales, factores de mercado, entregables del proyecto, cuatro procesos principales (compromiso, planificación,
implementación, convergencia), equipos, infraestructura del proyecto e hitos. El marco se conecta a un conjunto de "ciclos
de proceso" escalables. Los ciclos de proceso son recetas repetibles paso a paso para realizar ciertas tareas comunes.

El marco es esencialmente un repositorio situacional de heurísticas para llevar a cabo proyectos exitosos. Está destinado a ser
una referencia rápida para ayudar a los profesionales experimentados a decidir el mejor curso de acción.

La clave de este modelo es que los ciclos del proceso están subordinados al marco heurístico. Todo es una ayuda para el
juicio,nouna receta para los formalismos institucionales. La estructura del marco, como un conjunto de cuadrículas
bidimensionales, ayuda en la adaptación del proceso y pregunta "¿qué pasaría si...?"

En términos de este modelo, madurez significa reconocer problemas (mediante el análisis de la experiencia y el uso de
métricas) y resolverlos (mediante la definición selectiva y el despliegue de procesos formales e informales), y eso significa
desarrollar el juicio y la cooperación dentro de los equipos. A diferencia del CMM, no hay declaración a priori ni de los
problemas, ni de las soluciones. Esa determinación permanece firmemente en manos del equipo.
La desventaja de este modelo alternativo es que es más complejo y, por lo tanto, menos comercial. No hay respuestas
fáciles, y nuestro progreso no se puede trazar con los dedos de una mano. Pero debemos resistir la tentación de
alejarnos de la inconmensurable ya veces inefable realidad de la innovación de software.
Después de todo, eso sería inmaduro.

Posdata 02/99
En los cinco años transcurridos desde que escribí este artículo, ni la situación de CMM, ni mi evaluación de la misma, ha cambiado
mucho. La industria de defensa continúa apoyando al CMM. Algunas organizaciones comerciales de TI lo siguen, muchas otras no.
Las empresas de software que persiguen la gran fiebre del oro tecnológica de nuestro tiempo, Internet, la están ignorando en
masa. Los estudios que alegan que el CMM es valioso no consideran alternativas y dejan de lado datos críticos que permitirían un
análisis completo de lo que está pasando en las empresas que afirman haber subido en los niveles de CMM y haberse beneficiado
por ello.

Una cosa sobre mi opinión ha cambiado. Me siento más cómodo con la distinción entre la filosofía de CMM y la
lista de problemas de CMM. Como lista de problemas que vale la pena abordar en el curso de la mejora del
proceso de software, el CMM es útil y benigno. Yo diría que está incompleto y confuso en algunos lugares, pero
eso no es gran cosa. El problema comienza cuando se adopta el CMM como filosofía para una buena ingeniería
de software.

Aun así, me ha quedado mucho más claro por qué la filosofía CMM es mucho más popular de lo que merece. Da
esperanza y una ilusión de control a la gerencia. Ante la deprimente realidad de que el éxito del desarrollo de
software depende de tantos factores y juicios sutiles y dinámicos, el CMM proporciona un plan paso a paso para
haceralguna cosapoco sutil y crearalguna cosasólido. La parte triste es que este plan paso a paso generalmente se
convierte en un sustituto de la educación genuina en gestión de ingeniería y la mejora genuina de procesos.

En los últimos años, he asistido a las clases de Jerry Weinberg sobre gestión y cambio artístico: Liderazgo en resolución de
problemas, y elCambiar de tienda. Me he convertido en parte de él.Grupo de desarrollo de gestión de ingeniería de software
programa, y elFORMAforo. La información sobre todos estos está disponible enhttp://www.ge=raldmweinberg.com . Desde mi
punto de vista, el trabajo de Jerry continúa ofreciendo una excelente alternativa a todo el paradigma del CMM: los gerentes primero
deben aprender a ver, escuchar y pensar sobre los sistemas humanos antes de que puedan tener la esperanza de controlarlos. Los
proyectos de software son sistemas humanos = 97tratan con él.

Un último enchufe. Añadir a tu lista de lecturaLa lógica del fracaso, por Dietrich Dorner. Dorner analiza cómo las personas
hacen frente a la gestión de sistemas complejos. Sin mencionar el desarrollo de software o la madurez de la capacidad, es
un argumento elocuente en contra de la filosofía CMM que encontrará.

Referencias
1. Berti, Pat, "Cuatro escuelas de Pensilvania esperan recortes de defensa". Pittsburgh Business Times, 22 de enero de 1990 v9 n24

2. Coplien, James, "Artesanía de software de Borland: una nueva mirada al proceso, la calidad y la productividad",
Actas de la 5ª Conferencia Internacional de Borland, 1994
3. Couger, J. Daniel; McIntyre, Scott C.; Higgins, Lexis F.; Snow, Terry A., "Uso de un enfoque ascendente para la mejora de
la creatividad en el desarrollo de SI". Journal of Systems Management, septiembre de 1991 v42 n9 p23(6)
4. Martillo, Michael; Champy, James, Reingeniería de la Corporación, HarperCollins, 1993
5. Humphrey, Watts, Gestión del proceso de software, cap. 2, Addison-Wesley, 1989
6. Jones, Capers, Evaluación y control de riesgos de software, Prentice-Hall, 1994
7. Paulk, Mark, et al, Modelo de madurez de capacidad 1.1 (CMU/SEI-93-TR-24)
8. Peters, Tom, The Tom Peters Seminar: Crazy Times Call for Crazy Organizations, Random House, 1994
9. Peters, Tom, Thriving on Chaos: Handbook for a Management Revolution, HarperCollins, 1987
10. Senge, Peter, La quinta disciplina, Doubleday, 1990
11. Senge, Peter, El libro de campo de la quinta disciplina, Doubleday, 1994
12. Weinberg, Gerald M., Quality Software Management, v. 1 Systems Thinking, Dorset House, 1991
13. Weinberg, Gerald M., Quality Software Management, v. 2 Medición de primer orden, Dorset House, 1993