El documento describe la estructura de cinco niveles de madurez del Modelo de Madurez del Proceso de Capacidad (CMM) para medir la madurez del proceso de software de una organización. Cada nivel establece una capacidad de proceso diferente, desde procesos ad-hoc en el Nivel 1 hasta procesos mejorados continuamente en el Nivel 5. El logro de cada nivel prepara el terreno para la siguiente etapa de mejora del proceso.

1. Capítulo 2: La Estructura Base de la Madurez del Proceso de Software
La mejora continua del proceso está basada en muchos pasos pequeños de evolución
más que en innovaciones revolucionarias. El CMM proporciona una estructura base
para organizar estos pasos de evolución en cinco niveles de madurez que colocan bases
sucesivas para una mejora continua del proceso. Estos cinco niveles de madurez definen
una escala ordinal para medir la madurez del proceso de software de una organización y
para evaluar su capacidad de proceso de software. También le ayudan a una
organización a priorizar sus esfuerzos de mejora.
Un nivel de madurez es una base evolucionaria bien definida hacia el logro de un
proceso de software maduro. Cada nivel de madurez comprende un conjunto de
objetivos del proceso que, cuando se logran, estabilizan un componente importante del
proceso de software. El logro de cada nivel de la estructura de madurez establece un
componente diferente en el proceso del software, resultando en un aumento en la
capacidad para procesos de la organización.
La organización del CMM en los cinco niveles que se muestran en la Fig. 2.1 le
da prioridad a las acciones de mejora para aumentar la madurez del proceso del
software. Las flechas etiquetadas indican el tipo de capacidad de proceso que se está
institucionalizando por la organización en cada nivel de la estructura de madurez.
Los cinco niveles pueden describirse brevemente como:
1. Inicial El proceso de software está caracterizado como ad hoc, y
ocasionalmente incluso caótico. Hay pocos procesos definidos, y
el éxito depende de esfuerzos individuales y heroicos.
2. Repetible Los procesos básicos de administración del proyecto están
establecidos para controlar el costo, los tiempos y la
funcionalidad. Está en lugar la disciplina necesaria del proceso
para repetir éxitos anteriores sobre proyectos con aplicaciones
similares.
3. Definido El proceso de software está documentado, estandarizado e
integrado en un proceso de software estándar para la organización
tanto para las actividades de administración como para las de
ingeniería. Todos los proyectos usan una versión aprobada y
hecha a medida del proceso de software estándar de la
organización para desarrollar y mantener el software.
4. Administrado Se juntan medidas detalladas del proceso del software y de la
calidad del producto. Tanto el proceso del software como los
productos se controlan y comprenden cuantitativamente.
5. Optimizante Se hace posible un proceso de mejoras continuas gracias al
feedback cuantitativo desde el proceso y a partir de ideas y
tecnologías innovadoras.
Estos cinco niveles reflejan el hecho de que el CMM es un modelo para mejorar
la capacidad de las organizaciones de software. Las prioridades en el CMM, según se
expresa con estos niveles, no están dirigidas a proyectos individuales. Un proyecto
problemático bien podría darle prioridad a sus problemas en una forma diferente de la
taxonomía dada por el CMM. Sus soluciones pueden ser de un valor limitado para el
resto de la organización porque otros proyectos pueden tener diferentes problemas o no
poder sacar ventaja de sus soluciones porque carecen de las bases necesarias para
implementar las soluciones. El CMM se enfoca en procesos que son de valor en toda la
organización.
1

2. 2.1 Caracterización del Comportamiento de los Niveles de Madurez
Los niveles de madurez del 2 al 5 pueden caracterizarse a través de las actividades
realizadas por la organización para establecer o mejorar el proceso de software, por las
actividades realizadas en cada proyecto, y por la capacidad de proceso resultante en
todos los proyectos.
2.1.1 Nivel 1: El Nivel Inicial
En el Nivel Inicial, la organización típicamente no proporciona un ambiente estable para
desarrollar y mantener el software. El sobre-compromiso es una característica de las
organizaciones del Nivel 1, las que frecuentemente tienen dificultades en asumir
compromisos que el personal pueda cumplir con un proceso de ingeniería ordenado,
resultando en una serie de crisis. Durante una crisis, los proyectos típicamente
abandonan los procedimientos planeados y se revierten a la codificación y al testeo. El
éxito depende de tener un manager excepcional y un equipo de software efectivo y
fogueado. Ocasionalmente, managers de software capaces y fuertes logran soportar las
presiones para tomar atajos en el proceso del software; pero cuando ellos abandonan el
proyecto su influencia estabilizadora se va con ellos. Incluso un proceso fuerte de
ingeniería no puede superar la inestabilidad creada por la ausencia de prácticas de
administración sensatas.
A pesar de este proceso ad-hoc, incluso caótico, las organizaciones de Nivel 1
frecuentemente desarrollan productos que funcionan, aunque pueden excederse en
presupuesto y en tiempo. El éxito en las organizaciones de Nivel 1 depende de la
competencia y del heroísmo de la gente de la organización1
y no puede repetirse a
menos que los mismos individuos competentes sean asignados al siguiente proyecto. De
esta manera, en el Nivel 1, la capacidad es una característica de los individuos, no de la
organización.
2.1.2 Nivel 2: El Nivel Repetible
En el Nivel Repetible, están establecidas las políticas para administrar un proyecto de
software y los procedimientos para aplicar estas políticas. El planeamiento y la
administración de nuevos proyectos se basa en la experiencia con proyectos similares.
La capacidad del proceso se ve mejorada por el establecimiento de una disciplina de
administración del proceso básico sobre una base de proyecto a proyecto. Los proyectos
implementan procesos efectivos que están definidos, documentados, practicados,
entrenados, medidos, aplicados, y mejorables.
Los proyectos en las organizaciones de Nivel 2 tienen controles básicos de
administración de software instalados. Se hacen compromisos realistas de proyectos, en
base a los resultados observados en proyectos previos y en los requerimientos del
proyecto actual. Los administradores del software para un proyecto rastrean los costos,
tiempos y funcionalidad del software; los problemas para cumplir los compromisos se
identifican a medida que surgen. Los requerimientos de software y los productos
desarrollados para satisfacerlos son de línea base, y su integridad está controlada. Los
estándares del proyecto de software están definidos, y la organización asegura que se
siguen fielmente. El proyecto de software funciona con sus subcontratistas, si los hay,
para establecer una relación cliente-proveedor efectiva.
1 L a selección, contratación, desarrollo y retención de gente competente son temas de importancia en
todos los niveles de madurez, pero están en gran medida fuera del alcance del CMM.
2

3. Los procesos de una organización de Nivel 2 pueden diferir entre proyectos. El
requerimiento organizacional para lograr el Nivel 2 es que haya políticas a nivel de
organización que guíen a los proyectos en el establecimiento del proceso de
administración adecuado.
La capacidad de proceso de software de las organizaciones de Nivel 2 puede
resumirse como disciplinada porque el planeamiento y el seguimiento del proyecto de
software es estable y pueden repetirse los éxitos anteriores. El proceso del proyecto está
bajo el control efectivo de un sistema de administración de proyectos, siguiendo planes
realistas basados en la performance de proyectos previos
2.1.3 Nivel 3: El Nivel Definido
En el Nivel Definido hay un proceso (o procesos) estándar documentado para
desarrollar y mantener el software, y se usa a través de la organización. Conocido dentro
de CMM como el proceso de software estándar de la organización, este proceso
estándar incluye tanto ingeniería de software como procesos de administración y los
integra en un todo coherente. Los procesos establecidos en el Nivel 3 se usan (y se
cambian, según sea apropiado) para ayudar a los administradores de software y al
personal técnico a desempeñarse más efectivamente. La organización aprovecha las
prácticas de ingeniería de software efectivas al estandarizar su proceso de software. Se
le asigna la responsabilidad de las actividades del proceso de software un grupo dentro
de la organización (por ejemplo, un grupo de proceso de ingeniería de software o SEPG
[Fowler90]). Se implementa un programa de entrenamiento en toda la organización para
asegurarse que el personal y los administradores tengan el conocimiento y la
capacitación requeridos para cumplir con sus roles asignados.
Los proyectos ajustan el proceso de software estándar de la organización para
desarrollar sus propios procesos de software definidos, lo que explica las características
únicas del proyecto. El proceso adecuado al proyecto se conoce en CMM como proceso
de software definido del proyecto. Es el proceso usado en desarrollar las actividades del
proceso. Un proceso de software definido contiene un conjunto coherente e integrado de
procesos de administración e ingeniería de software bien definido. Un proceso bien
definido puede caracterizarse como incluyendo criterios de prontitud, entradas,
estándares y procedimientos para realizar el trabajo, mecanismos de verificación (como
ser revisiones de los pares), salidas, y criterios de terminación. Como el proceso de
software está bien definido, la administración tiene un buen conocimiento en el
progreso técnico sobre el proceso.
La capacidad del proceso de software de las organizaciones de Nivel 3 pueden
resumirse como estándares y consistentes porque tanto la ingeniería de software como
las actividades de administración son estables y repetibles. Dentro de líneas de
productos establecidas, el costo, los plazos, y la funcionalidad están bajo control, y se
sigue la calidad del software. Esta capacidad de proceso está basada en una
comprensión común y generalizada de las actividades, roles y responsabilidades en un
proceso de software definido.
2.1.4 Nivel 4: El Nivel Administrado
En el Proceso Administrado la organización establece objetivos de calidad cuantitativos
tanto para los productos de software como para los procesos. Se miden la productividad
y la calidad para las actividades de los procesos de software importantes en todos los
proyectos como parte del programa de mediciones de la organización. Se usa una base
de datos de los procesos de software de toda la organización para recolectar y analizar
los datos disponibles de los procesos de software definidos de los proyectos. Los
3

4. procesos de software se instrumentan con mediciones bien definidas y consistentes.
Estas mediciones establecen la fundación cuantitativa para evaluar los procesos de
software de los proyectos y los productos.
Los proyectos logran un control sobre sus productos y procesos disminuyendo la
variación en la performance de sus procesos para caer dentro de límites cuantitativos
aceptables. Pueden distinguirse las variaciones significativas en la performance del
proceso de la variación al azar (ruido), particularmente dentro de líneas de productos
establecidas. Se conocen y se manejan cuidadosamente los riesgos involucrados en
elevar la curva de aprendizaje de un nuevo dominio de aplicación.
La capacidad de proceso de software de las organizaciones de Nivel 4 puede
resumirse como cuantificable y predecible porque el proceso está medido y funciona
dentro de límites cuantitativos. Este nivel de capacidad de proceso le permite a una
organización predecir tendencias en calidad de productos y procesos dentro de los
límites cuantitativos existentes. Como el proceso es a la vez estable y medido, cuando
ocurre alguna circunstancia excepcional, puede identificarse y tratarse la “causa
especial” de la variación. Cuando se exceden los límites predefinidos, se toman acciones
para comprender y corregir la situación. Los productos de software son de una alta
calidad predecible.
2.1.5 Nivel 5: El Nivel Optimizante
En el Nivel Optimizante toda la organización está enfocada en una mejora continua del
proceso. La organización tiene los medios para identificar debilidades y fortalecer el
proceso en forma proactiva, con el objetivo de prevenir la ocurrencia de defectos. Los
datos sobre la efectividad del proceso de software se usan para realizar análisis de
costo / beneficio de nuevas tecnologías y cambios propuestos al proceso de software de
la organización. Se identifican y transfieren a toda la organización las innovaciones que
explotan las mejores prácticas de ingeniería del software.
Los equipos de software en las organizaciones de nivel 5 analizan los defectos
para determinar sus causas. Evalúan el proceso de software para evitar que vuelvan a
ocurrir tipos conocidos de defectos y diseminan las lecciones aprendidas para toda la
organización.
El desperdicio crónico, en la forma de trabajo vuelto a hacer, puede encontrarse
en cualquier sistema simplemente debido a la variación al azar. Los esfuerzos
organizados para eliminar el desperdicio resultan en un cambio al sistema, o sea, en la
mejora del proceso por medio del cambio de las “causas comunes” de ineficiencia para
evitar que ocurra el desperdicio. Mientras que esto es verdad para todos los niveles de
madurez, es el enfoque del Nivel 5.
La capacidad del proceso de software de las organizaciones de Nivel 5 puede
caracterizarse como de mejoras continuas porque las organizaciones de Nivel 5
continuamente luchan para mejorar el alcance de la capacidad de su proceso, mejorando
así la performance del proceso de sus proyectos. las mejoras ocurren debido a avances
incrementales en el proceso existente y a innovaciones usando nuevas tecnologías y
métodos. La tecnología y las mejoras del proceso se planean y administran como
actividades de negocios ordinarias.
2.2 Salteando los Niveles de Madurez
El CMM identifica los niveles a través de los cuales una organización debería
evolucionar para establecer una cultura de excelencia de ingeniería de software. Como
4

5. cada nivel de madurez en el CMM es una base necesaria sobre la que se construirá el
siguiente nivel, tratar de saltearse niveles puede ser contraproductivo.
Las organizaciones pueden instituir mejoras específicas al proceso en el
momento que elijan, incluso antes de estar preparadas para avanzar al nivel en el que se
recomienda la práctica específica. Sin embargo, las organizaciones deberían comprender
que la estabilidad de estas mejoras corre un mayor riesgo porque las bases para la
institucionalización exitosa no han sido completadas. Los procesos sin los fundamentos
adecuados pueden fallar en cualquier punto en el que se los necesite - bajo presión.
Por ejemplo, un proceso de software bien definido que es característico de una
organización de Nivel 3 puede colocarse con un gran riesgo si las prácticas de
administración del nivel 2 son deficientes. Por ejemplo, la administración puede
preparar una agenda de compromisos pobremente planeada o no poder controlar los
cambios a los requerimientos de línea base. En forma similar, muchas organizaciones
recolectan datos detallados característicos del Nivel 4, sólo para encontrase con que los
datos resultan ininterpretables debido a la inconsistencia en el proceso de desarrollo de
software y las definiciones de medición.
Al mismo tiempo, debe reconocerse que los esfuerzos para mejorar el proceso
deberían enfocarse en las necesidades de la organización en el contexto de su ambiente
de negocios y que prácticas de niveles superiores pueden ser útiles para las necesidades
actuales de una organización o proyecto. Por ejemplo, a las organizaciones que quieren
pasar del Nivel 1 al 2 frecuentemente se les dice que establezcan un grupo de proceso de
ingeniería de software (SEPG), que es un atributo de las organizaciones de Nivel 3.
Mientras que un SEPG no es una característica necesaria de una organización de nivel
2, puede ser una parte útil de la receta para lograr el Nivel 2.
Esto a veces se describe como establecer un SEPG de Nivel 1 para llevar a la
organización de Nivel 1 hasta un Nivel 2. Las actividades de mejora al proceso de
software de Nivel 1 pueden depender principalmente de la lucidez y competencia del
personal del SEPG hasta que haya una infraestructura para soportar mejoras más
disciplinadas y abarcativas.
Otro ejemplo es el proceso de construcción del software. Ciertamente
esperaríamos que las organizaciones de Nivel 1 realizaran un análisis, diseño,
codificación y prueba de los requerimientos. Sin embargo, estas actividades no se
describen en el CMM hasta el nivel 3, en donde se describen como procesos de
ingeniería coherentes y bien integrados.
En forma similar, los procesos cambian al pasar del Nivel 1 al Nivel 2. La
mejora de los procesos ocurre a medida que una organización asciende por los niveles
de madurez. Sin embargo, la masterización del manejo de cambios continuos en el
proceso es característica de las organizaciones del Nivel 5.
Estas variaciones para implementar las mejoras al proceso del software son
artefactos en la forma en que se definen las áreas de procesos claves. Un área de
proceso clave describe un proceso completamente implementado e institucionalizado,
uno que ha sido masterizado por una organización. Una organización de Nivel 1 podría
implementar casi cualquier proceso descripto en el CMM, aunque tal vez de una manera
incompleta o ad hoc.
Por el simple hecho que una organización de Nivel 1 realice un proceso de una
manera ad hoc, esto no debe desmerecer el hecho de que lo realiza. La confiabilidad y
consistencia de este proceso puede y debe mejorarse. la capacidad de una organización
puede germinar de la semilla de un proceso ad hoc.
5

6. 2.3 Visibilidad dentro del Proceso de Software
Cada nivel del CMM aumenta la visibilidad dentro del proceso de software tanto para
los managers como para el personal de ingeniería. Los ingenieros del software tienen
una visión detallada del estado del proyecto porque tienen información de primera mano
sobre el estado y performance del proyecto. Sin embargo, en proyectos más grandes, la
visión que tienen del mismo normalmente se deriva sólo de su experiencia personal en
su área de responsabilidad. Los que están fuera del proyecto sin una exposición al
mismo de primera mano, como ser los senior manager, carecen de visibilidad en el
proceso del proyecto y por lo tanto sólo se apoyan en revisiones periódicas para obtener
la información que necesitan para monitorear el progreso. La Figura 2.2, creada por Jeff
Perdue, ilustra el nivel de visibilidad en el estado y la performance del proyecto
proporcionados al manager en cada nivel de madurez del proceso.
En el Nivel 1, el proceso de software es una entidad amorfa - una caja negra - y
la visibilidad del proceso del proyecto es limitada. Como la división en etapas de las
actividades está pobremente definida, a los managers les cuesta mucho establecer el
estado de las actividades y del progreso del proyecto.2
Los requerimientos fluyen en el
proceso de software de una manera no controlada, y resulta un producto. El desarrollo
del software es frecuentemente visto como magia negra, especialmente por los
managers que no están familiarizados con el software. El cliente puede evaluar si el
producto satisface los requerimientos sólo cuando se lo entregan.
En el Nivel 2 se controlan los requerimientos del cliente y los productos de
trabajo, y se han establecido prácticas básicas de administración del proyecto. Estos
controles de administración permiten una visibilidad dentro del proyecto en ciertas
ocasiones. El proceso de construir el software puede verse como una sucesión de cajas
negras que permiten una visibilidad dentro del proyecto en los puntos de transición
(fundamentos del proceso) a medida que la actividad fluye entre las cajas. Aunque la
administración puede no conocer los detalles de lo que está pasando en la caja, se
conocen y están identificados los productos del proceso y los puntos de verificación
para confirmar que el proceso está funcionando. La administración reacciona a los
problemas a medida que éstos ocurren. El cliente puede revisar el producto en puntos de
verificación definidos durante el proceso de software.
En el nivel 3 es visible la estructura interna de las cajas, o sea, las tareas en el
proceso de software definido del proyecto. La estructura interna representa la forma en
la que se ha aplicado el proceso de software estándar de la organización a proyectos
específicos. Tanto los managers como los ingenieros comprenden sus roles y
responsabilidades dentro del proceso y cómo sus actividades interactúan en el nivel de
detalle apropiado. La administración se prepara proactivmente para riesgos que puedan
surgir. El cliente puede obtener actualizaciones de estado rápidas y precisas porque los
procesos definidos proporcionan una gran visibilidad dentro de las actividades del
proyecto.
En el Nivel 4, el proceso de software definido está cuantitativamente
instrumentado y controlado. Los managers pueden medir el progreso y los problemas.
Tienen una base objetiva y cuantitativa para la toma de decisiones. Su capacidad para
predecir resultados se vuelve constantemente más precisa a medida que la variabilidad
en el proceso disminuye. El cliente puede establecer una comprensión cuantitativa de la
capacidad del proceso y del riesgo antes de que el proyecto comience.
En el Nivel 5, se prueban continuamente nuevas formas mejoradas de construir
2 Esto conduce a la regla algo humorística de Noventa - Noventa: 90% del proyecto está completo el 90%
del tiempo.
6

7. el software, de una manera controlada, para mejorar la productividad y la calidad. El
cambio disciplinado es una forma de vida: cada vez que se identifican actividades
ineficientes o propensas al error se reemplazan o revisan. Hay una visión clara que se
extiende más allá de los procesos existentes y dentro de los efectos de cambios
potenciales a los procesos. Los managers pueden estimar y luego rastrear
cuantitativamente el impacto y la efectividad del cambio. El cliente y la organización de
software siguen trabajando juntos para establecer una relación cliente - proveedor
fuerte.
En los cinco niveles, la capacidad del proceso interactúa con las personas, la
tecnología y la medición a medida que una organización madura, como se ilustra en la
Tabla 2.1.
2.4 Predicción de la Performance
La madurez del proceso de software de una organización ayuda a predecir la capacidad
de un proyecto de lograr sus objetivos. Los proyectos en las organizaciones de Nivel 1
experimentan amplias variaciones en lograr objetivos de costo, plazos, funcionalidad y
calidad. La Figura 2.3 ilustra las clases de mejoras esperadas en predictabilidad, control
y efectividad en la forma de densidad de probabilidad para la performance probable de
un proyecto particular con respecto a objetivos, que pueden ser plazos, costo, calidad,
etc.
La primera mejora esperada a medida que una organización madura es en
predictabilidad. A medida que la madurez aumenta, la diferencia entre los resultados
deseados y los obtenidos disminuye a través de los proyectos. Por ejemplo, las
organizaciones de Nivel 1 a menudo no cumplen con la fecha de entrega originalmente
pactada por un amplio margen, mientras que las organizaciones de mayor nivel de
madurez deberían poder cumplir las fechas previstas con una mayor precisión.
La segunda mejora es en control. A medida que la madurez aumenta, la
variabilidad de los resultados reales con respecto a los propuestos disminuye. Por
ejemplo, en las organizaciones de Nivel 1 las fechas de entrega para proyectos de
tamaño similar no son predecibles y varían grandemente de una a otra. Sin embargo, en
organizaciones con niveles de madurez más altos, serán entregados dentro de un rango
menor.
La tercera mejora es en efectividad. Los resultados esperados mejoran a medida
que la madurez de la organización aumenta. O sea, a medida que la organización de
software madura, los costos disminuyen, el tiempo de desarrollo se acorta y la
productividad y la calidad aumentan. En una organización de nivel 1, el tiempo de
desarrollo puede ser bastante largo debido a la cantidad de trabajo que se hace dos veces
para corregir errores [Cooper93]. En contraste, las organizaciones de niveles de
maduración más altos tienen una efectividad de proceso aumentada y un trabajo hecho
dos veces reducido, lo que resulta en un tiempo de desarrollo más corto.
Como se ilustra en la Figura 2.4, se esperan las tres mejoras a medida que el
proceso de software de la organización madura. Estas expectativas se basan en los
resultados cuantitativos que las mejoras del proceso han logrado en otras industrias, y
son consistentes con los resultados del estudio del caso inicial informados por las
organizaciones de software [Dion93, Humphrey91b, Lipke92, Wohlwend93].
Nótese la interacción entre la predictabilidad y la efectividad a medida que una
organización pasa del Nivel 1 al Nivel 2. Debido a la mejora en la estimación, los planes
se vuelven más realistas, conduciendo a un planeamiento de plazos más largos. Al
7

8. mismo tiempo, debido a las mejoras en la realización del proyecto, los tiempos de ciclo
se acortan, lo que conduce a plazos reales más cortos. En este gráfico hemos elegido
enfatizar el plazo más realista indicando que “Objetivo N” es ahora “Objetivo N+a”.
Los plazos pueden ser más cortos en el Nivel 2 que en el Nivel 1, pero la relación exacta
dependerá de la predictabilidad y efectividad de línea base de los procesos de la
organización cuando comenzó su programa de mejoras al proceso de software.
Las mejoras en la predicción de los resultados de un proyecto representadas en la
Figura 2.4 suponen que los resultados del proyecto de software se vuelven más
predecibles a medida que se elimina el ruido, a menudo bajo la forma de trabajo hecho
dos veces, del proceso de software. Sistemas sin precedentes complican el panorama, ya
que nuevas tecnologías y aplicaciones disminuyen la capacidad del proceso aumentando
su variabilidad. Incluso en el caso de sistemas sin precedentes, las prácticas de
administración e ingeniería características de las organizaciones más maduras ayudan a
identificar y tratar los problemas más temprano en el ciclo de desarrollo de lo que serían
detectadas en organizaciones menos maduras. En algunos casos, un proceso maduro
significa que se identifican proyectos “fallidos” más temprano en el ciclo de vida del
software, y la inversión en una causa perdida es minimizada.
8