Una breve historia de CMMI

Cuando me inicié en el desarrollo de software, fines de los 70, comienzos de los 80, la situación de software, hardware, recursos, metodologías, formas de trabajo, eran totalmente diferentes a las de ahora. Los mainframe eran (por lo menos en Argentina) el equipo ha usar. Los sistemas eran ejecutados dentro de un centro de cómputos, todo controlado. Los usuarios finales sólo recibían el resultado de proceso, posiblemente, horas y horas de listados de impresoras de puntos, dando información que la gerencia debía digerir, tal vez una vez al mes.

Pero el resto del mundo, ya estaba cambiando. La aparición de la computación personal, y de software para esos sistemas, la adopción luego de las redes para ese tipo de máquinas, el incremento espectacular del acceso a esos recursos por los usuarios finales, y la creación de un nuevo mercado, el software de aplicaciones, cambió todo el horizonte.

Antes de ese cambio, el control y la disciplina en el procesamiento de datos se conseguía por lo que se llamó “estabilidad por limitación”. No cualquiera podía programar, no cualquiera accedía a sistemas de información, no cualquiera los operaba y los usaba. Pero al cambiar el entorno, surgieron problemas en mantener la estabilidad de los sistemas. La adopción de nueva tecnología se volvió una ventaja, pero también un problema a manejar. El gobierno de EE.UU. reacciona, estableciendo el Software Engineering Institute en la universidad Carnegie Mellon. El instituto no es una iniciativa privada, sino que está soportado por los impuestos que pagan los norteamericanos. Inicialmente fue “sponsoreado” por el Departamento de Defensa (el DoD), que estaba preocupado por la calidad del software que quería adquirir y soportar (recordemos que en ese tiempo, su preocupación también dió pie a otras iniciativas, como el lenguaje ADA).

En esos momentos, había modelos de manejo de la calidad, principalmente implantados en la industria. La serie ISO 9000 comenzaba a obtener amplia adopción, los japoneses producían innovaciones como entrega Just In Time y Assembly-Line-Control. Six Sigma estaba emergiendo en lugares como Motorola y General Electric.

El SEI toma estudia esas implementaciones, y a los trabajos de americanos expertos y promotores de la calidad, como Philip Crosby, Malcolm Balbridge, George Box y Edwards Deming. Ese esfuerzo dió un primer fruto con la publicación del trabajo de Watts Humphrey en 1987: Managing the Software Process. El libro sintetizaba el pensamiento crítico en el manejo de la calidad, y aplicaba una serie de pasos prácticos, organizados en niveles de maduración. Una empresa podría entonces ir implementando en forma escalonada, esos niveles.

Ese mismo año, el SEI usa lo planteado por Humphrey como base para la primera versión del Capability Maturity Model.

Me gustaría en otros post ir viendo más en detalle qué eso de CMM, y cómo evolucionó, hasta llegar a distintos “flavors”, y al CMMI-Dev, por ejemplo. Pero ahora, revisemos dos puntales del CMM.

El CMM está fundado en dos bien conocidos principios de calidad. El primero: “el proceso funciona”. Es decir, que si una organización o grupo tiene que producir un resultado, sea producto de software o un auto, se logra asegurar una mejor calidad usando una serie de pasos definidos, un proceso, que usando cada vez lo que se nos ocurra.

El otro gran principio es “la organización que ejecuta es un organización que aprende” (“performing organization is a learning organization”). Ante el cambio continuo de tecnologías y ambiente de mercado, una organización exitosa debe no quedarse en el tiempo, o anquilosarse en un proceso fijo, sino que debe aprender, y aprovechar las lecciones aprendidas para mejorar justamente el proceso. La organización opera siempre en “modo de aprendizaje”. La actitud “ya lo sabemos todo” no se acepta. La organización debe tener conciencia de lo que sabe, de lo que aprende, de lo que puede mejorar, y de los cambios que acontecen.

Esos dos principios, si bien venían de otros ámbitos, eran nuevos en la industria del software. El DoD creyó en esos principios, y adoptó el modelo. Luego vendrían otros “early adopters”. En 5 años, más de 5000 organizaciones de IT habían adoptado el CMM como el modelo de calidad. Aparecieron varios CMM para distintas disciplinas.

Con el tiempo, se integraron varios de esos “flavors” en el CMMI (I de integrado), en 1999. En 2006, quedó establecido el CMMI-Dev para desarrollo, y el CMMI-ACQ para compras.

En los últimos años, hemos visto cómo cada vez más empresas, fuera de EEUU, y en mi país, Argentina, han ido adoptando e implementando las ideas y niveles de CMMI. Y en los contratos, cada vez más se pide al proveedor cumplir con algún nivel.

Fuente consultada: Process Improvement Essentials, CMMI, ISO 9001, Six Sigma, James R. Persse, O’Reilly. Gracias a la biblioteca de Southworks!

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/

This entry was posted in 3463, 6791. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>