1

El CMM
Guas para Mejorar el Proceso de Software
Parte Uno: El CMM para Software: Antecedentes, Conceptos, Estructura y Uso
Captulo 1: Presentacin de la Madurez del Proceso de Software
La satisfaccin del cliente se ha vuelto el slogan de muchas organizaciones que intentan sobrevivir y prosperar en el mundo altamente competitivo de la actualidad. Al mismo tiempo que las organizaciones se enfocan en la satisfaccin del cliente hay una sensacin creciente de que la calidad del software es el enlace dbil al desarrollar productos de alta calidad. La crisis de software que ha persistido durante las pasadas dos o tres dcadas se ha vuelto aun ms crtica a medida que el software invade nuestra vida cotidiana. La frase crisis del software puede ser injusta. El software es invasor debido a su poder, y la tecnologa del software est avanzando a una velocidad arrolladora. A pesar de estos avances, parece que la complejidad de los problemas a los que se dirige el software est creciendo ms rpidamente que nuestra capacidad para desarrollar y mantener el software. La capacidad para desarrollar y entregar software confiable que se pueda usar dentro de los tiempos y presupuestos estipulados sigue eludiendo a la mayora de las organizaciones de software. La bsqueda de soluciones para estos desafos ha continuado por muchos aos. Luego de dos dcadas de promesas incumplidas en cuanto a ganancias en calidad y productividad de la aplicacin de nuevas tecnologas y metodologas de software, las organizaciones se estn dando cuenta ahora de que su problema fundamental es la falta de capacidad para administrar los procesos de software. En muchas organizaciones, los proyectos tardan demasiado y se exceden del presupuesto, y los beneficios de mejores mtodos y herramientas no puede apreciarse en el torbellino de un proyecto catico y sin disciplina. Los ejemplos de catstrofes de software abundan. Una revisin no publicada de 17 contratos importantes de software del Departamento de Defensa (DoD) encontr que el perodo de 28 meses de promedio no se haba cumplido por 20 meses. Un proyecto de 4 aos no se haba entregado por 7 aos; ningn proyecto se haba cumplido a tiempo. El despliegue del bombardero B1 fue demorado por un problema de software, y el programa de 58 mil millones de dlares de aeronaves A12 fue cancelado en parte por la misma razn. Un informe reciente de la Oficina de Contabilidad Gubernamental (GAO) [GAO-93-13] sobre los mayores desafos de software dice: Hemos informado repetidamente sobre el aumento de costos en millones de dlares demoras en tiempo no de meses sino de aos, y sistemas de varios miles de millones de dlares que no funcionan como se haba previsto. Luego de resumir ms de 20 casos de estudios de GAO relacionados con software o problemas relacionados con software en el ejrcito, este informe concluye: La comprensin del software como producto y del desarrollo de software como proceso no se est manteniendo al ritmo de la creciente complejidad y dependencia del software de sistemas existentes y nuevos crticos para su misin. Mientras que el ejrcito tiene sus propios problemas nicos, la industria tiene sus propios problemas tambin. Administradores de la industria han dicho: Prefiero tenerlo mal antes que tarde. Siempre se puede arreglar ms adelante. Las consecuencias de esta actitud sobre la satisfaccin del cliente parecen claras. Para muchas organizaciones, ya sean militares o comerciales, el mensaje es que proyectos grandes de software significan problemas potenciales. Un grupo de trabajo que investig la crisis del software [DoD87] escribi que pocas reas tienen un vaco tan grande entre la mejor prctica actual y la prctica promedio actual, y continu para concluir que los mayores problemas en la actualidad con el desarrollo de software militar no son problemas tcnicos, sino problemas de administracin.

La misin del Instituto de Ingeniera del Software (SEI) es proporcionar liderazgo para avanzar el estado de la prctica de la ingeniera de software para mejorar la calidad de los sistemas que dependen del software. La misin del Programa del Proceso del Software del SEI es proporcionar liderazgo al ayudar a organizaciones de software a desarrollar y mejorar continuamente su capacidad para identificar, adoptar y usar prcticas tcnicas y de administracin coherentes. Estas prcticas comprenden procesos de ingeniera de software medidos en forma efectiva, bien definidos y disciplinados para el propsito de entregar software de calidad que cumpla con los compromisos en cuanto a costo y tiempo. El CMM para Software desarrollado por el SEI es una estructura base que describe los elementos clave de un proceso de software efectivo. El CMM describe un camino de desarrollo evolucionario para organizaciones de software desde un proceso inmaduro y ad-hoc a uno maduro y disciplinado. Este camino est compuesto por cinco niveles de madurez. Las caractersticas y estructura de estos niveles se describen en los Captulos 2 y 3 respectivamente. El CMM cubre prcticas para el planeamiento, ingeniera y administracin para el desarrollo y mantenimiento de software. Cuando se siguen adecuadamente, estas prcticas mejoran la capacidad de las organizaciones de satisfacer los objetivos en cuanto a costo, plazos, funcionalidad y calidad del producto. El CMM gua a las organizaciones de software que quieren ganar control sobre sus procesos para desarrollar y mantener el software y para evolucionar hacia una cultura de ingeniera de software y excelencia de administracin. Su propsito es guiar a estas organizaciones durante la seleccin de estrategias de procesos de mejoras por medio de la determinacin de su madurez de proceso actual y la identificacin de algunos temas de los ms crticos para mejorar sus procesos de software y su calidad de software. Al enfocarse en un conjunto limitado de actividades y en trabajar en forma agresiva para lograrlas, una organizacin puede mejorar en forma continua sus procesos de software en toda la organizacin para posibilitar ganancias continuas y duraderas en la capacidad de procesos de software. 1.1 La Evolucin del CMM En noviembre de 1986, el SEI, con la ayuda de la Corporacin Mitre, comenz a desarrollar una estructura de madurez de procesos que ayudara a las organizaciones a mejorar su proceso de software. Este esfuerzo se inici en respuesta a un pedido de proveer al gobierno federal un mtodo para evaluar la capacidad de sus contratistas de software. En septiembre de 1987 el SEI edit una breve descripcin de la estructura de la madurez de procesos de software [Humphrey 87a], que ms adelante fue extendida en el libro de Humphrey, Managing the Software Process [Humphrey89a]. Se desarrollaron dos mtodos, la avaluacin del proceso de software1 y la evaluacin de la capacidad de software2, y un cuestionario de madurez [Humphrey 87b] para tasar la madurez de procesos de software. Luego de cuatro aos de experiencia con la estructura de madurez del proceso de software y con el cuestionario de madurez de 1987, la estructura de madurez del SEI evolucion hasta el Modelo de Madurez de Capacidad para el Software [Paulk91, Weber91]. El CMM est basado en prcticas reales,
La avaluacin de procesos de software es una tasacin hecha por un equipo entrenado de profesionales de software para determinar el estado del proceso de software actual de una organizacin, para determinar los temas de alta prioridad relacionados con los procesos de software que una organizacin enfrenta, y para obtener el soporte organizacional para la mejora de procesos de software. La avaluacin es un paso crtico en un programa interno de mejora de procesos. 2 La evaluacin de la capacidad del software es una tasacin hecha por un equipo entrenado de profesionales para identificar contratistas calificados para realizar trabajos de software o para monitorear el estado del proceso de software usado en un esfuerzo de software existente.
1

refleja lo mejor del estado de la prctica, refleja las necesidades de individuos que realizan mejoras a procesos de software y tasaciones de procesos de software, est documentado, y est disponible al pblico. El CMM est basado en conocimiento adquirido de avaluaciones de procesos de software y de una retroalimentacin extensiva proveniente tanto de la industria como del gobierno. La edicin inicial del CMM fue revisada y usada por la comunidad del software durante 1991 y 1992. Se adquirieron conocimientos adicionales sobre la madurez del proceso de software por: estudio de organizaciones que no son de software, realizacin y observacin de avaluaciones de procesos de software y de evaluaciones de capacidad de software, solicitud y anlisis de solicitudes de cambio al modelo, participacin en reuniones y workshops con representantes de la industria y el gobierno, y solicitud de respuestas de revisores de la industria y el gobierno. En base a este conocimiento adicional, el CMM y sus prcticas se revisaron, creando as la versin actual [Paulk93a, Paulk93b]. El CMM continuar evolucionando con el campo del software mientras desarrollamos una verdadera disciplina de ingeniera y seguimos aprendiendo sobre la administracin efectiva de procesos de software. Durante los prximos aos, el CMM sufrirn pruebas intensivas a travs del uso en las evaluaciones de procesos de software y programas de mejoras de procesos. Es un documento viviente que ser mejorado continuamente, aunque se anticipa que la versin actual del CMM seguir siendo la lnea base por lo menos hasta 1997. Esto proporciona un equilibrio realista y apropiado entre las necesidades de estabilidad y de mejoras continuadas. Los factores que influenciarn la evolucin continuada del CMM incluyen actividades estndar internacionales, as como el feedback del usuario. El SEI est trabajando con la Organizacin Internacional para la Estandarizacin (ISO) en sus esfuerzos para construir estndares internacionales para la avaluacin, mejora y evaluacin de la capacidad de los procesos de software. Este esfuerzo integrar conceptos de muchos mtodos de mejora de diferentes procesos. El desarrollo de los estndares ISO (y las contribuciones de otros mtodos) influenciar el CMM v2, incluso a medida que el trabajo del proceso SEI influencia las actividades del ISO. El proyecto SPICE de ISO (Determinacin de la Capacidad y Mejora del Proceso de Software) se describe en el Apndice G. La revisin de ISO 9001 planeada para 1996 tambin influenciar la revisin del CMM. 1.2 Organizaciones de Software Maduras e Inmaduras Para comprender qu mejoras son las ms crticas para una organizacin, uno debe primero comprender las diferencias entre las organizaciones de software maduras e inmaduras. En una organizacin de software inmadura, los procesos de software son generalmente improvisados por practicantes y sus administradores durante el curso de un proyecto. Incluso si un proceso de software ha sido especificado, no es rigurosamente seguido o aplicado. La organizacin de software inmadura es reaccionaria, y sus administradores estn normalmente enfocados hacia la resolucin de crisis inmediatas (mejor conocido como luchar contra el fuego). Estas organizaciones se sobrepasan tanto en plazos como en presupuestos en forma rutinaria porque no se basan en estimaciones realistas. Cuando se imponen plazos rgidos, pueden relegar la funcionalidad y calidad del producto para cumplir con el plazo. En una organizacin inmadura no hay una base objetiva para juzgar la calidad del producto o para resolver problemas del proceso o del producto. Hay poco entendimiento acerca de cmo los pasos del proceso del software afectan la calidad, y la calidad del producto

es difcil de predecir. Ms aun, las actividades cuyo objetivo es mejorar la calidad, como ser revisiones y pruebas, a menudo se ven reducidas o eliminadas cuando los procesos se atrasan. El cliente conoce poco del programa hasta el momento de la entrega. Una organizacin de software madura, en contraste, posee una capacidad en toda la organizacin de manejar el desarrollo del software y los procesos de mantenimiento. Le comunica en forma precisa el proceso de software tanto al personal existente como a los nuevos empleados, y realiza las actividades de acuerdo al proceso planeado. Los procesos encargados se documentan, se pueden usar y son consistentes con la forma con la que el trabajo realmente se hace. Las definiciones del proceso se actualizan cuando es necesario, y las mejoras se desarrollan a travs de pruebas piloto controladas y/o de anlisis en cuanto al beneficio por costo. Toda la organizacin est activamente involucrada en las actividades de mejora. Los roles y responsabilidades dentro del proceso son claros todo a lo largo del proyecto y de la organizacin. En una organizacin madura, los administradores monitorean la calidad de los productos de software y el proceso que los produce. Hay una base objetiva y cuantitativa para juzgar la calidad del producto y analizar problemas con el producto y el proceso. Los plazos y presupuestos se basan en la performance histrica y son realistas; los resultados esperados en cuanto al costo, plazo, funcionalidad y calidad del producto normalmente se logran. En general, la organizacin madura sigue un proceso disciplinado en forma consistente porque todos los participantes comprenden el valor de hacerlo de esa manera, y existe la infraestructura necesaria para soportar el proceso. Para usar una de las metforas de Humphrey, una organizacin con un proceso de software inmaduro se asemeja a un equipo de baseball de la Liga Inferior. Cuando se golpea la bola, algunos jugadores corren hacia ella, mientras que otros se quedan parados y miran, tal vez ni siquiera pensando en el juego. En contraste, una organizacin madura es como un equipo de baseball profesional. Cuando se golpea la bola, cada jugador reacciona de una manera disciplinada. Dependiendo de la situacin, el pitcher puede cubrir la base home, los que juegan dentro del campo pueden intentar un juego doble y los que juegan dentro del campo prepararse para apoyar a sus compaeros de equipo. Aunque normalmente no pensamos en el juego en trminos de proceso, la misma clase de disciplina y preparacin que separa a la Liga Inferior de los profesionales es la que separa a las organizaciones de software inmaduras de las maduras. 1.3 Conceptos Fundamentales que Yacen debajo de la Madurez de Procesos Antes de comprender completamente la madurez del proceso de software es necesario comprender algunos de los conceptos bsicos que se usan para describir a las organizaciones maduras. El CMM se enfoca en la capacidad de las organizaciones de software de producir productos de alta calidad en forma consistente y que se puede predecir. La capacidad de los procesos de software es la capacidad inherente de un proceso de software de producir los resultados planeados. Qu es un proceso? Un proceso es una secuencia de pasos realizados para un propsito dado. Dicho de una forma ms simple, el proceso es lo que uno hace. El proceso integra a la gente, herramientas y procedimientos, como se ilustra en la Fig. 1.1. El proceso es lo que hace la gente, usando procedimientos, mtodos, herramientas y equipamiento para transformar material crudo (entradas) en un producto (salida) que es de valor para los clientes. La descripcin de un proceso no es un proceso. Slo se puede hablar de proceso cuando las actividades se hacen o los mtodos se usan. Los estndares y procedimientos que no se usan son simplemente cosas que se almacenan en un estante; en tal caso, el proceso es ad-hoc, dado que la descripcin del proceso putativo no se sigue. El proceso y la descripcin del proceso frecuentemente, y tal vez en forma poco precisa, se usan en forma intercambiable. Un proceso de software puede definirse como un conjunto de actividades, mtodos,

prcticas y transformaciones que la gente emplea para desarrollar y mantener el software y sus productos asociados (por ejemplo, planes de proyectos, documentos de diseo, cdigo, casos de prueba y manuales del usuario). A medida que una organizacin madura, el proceso de software se va definiendo mejor y se implementa de una forma ms consistente en toda la organizacin. El CMM se enfoca en el proceso como una forma de darle el poder a la gente que hace el trabajo. La premisa subyacente de la administracin del proceso de software es que la calidad de un producto de software est en gran parte determinada por la calidad del proceso usado para desarrollarlo y mantenerlo. Un proceso de software efectivo une gente, herramientas y mtodos en un todo integrado. La capacidad del proceso de software describe el rango de resultados esperados que pueden lograrse siguiendo un proceso de software. La capacidad del proceso de software de una organizacin proporciona un medio de predecir las salidas ms probables a esperar del siguiente proyecto de software que la compaa tome. La performance del proceso de software representa los resultados reales logrados al seguir un proceso de software. De esta manera la performance del proceso de software se enfoca en el resultado logrado, mientras que la capacidad del proceso de software se enfoca en los resultados esperados. La madurez del proceso de software es el punto al cual el proceso especfico est definido, administrado, medido y controlado en forma explcita y su efectividad. La madurez implica un potencial para el crecimiento en la capacidad e indica tanto la riqueza del proceso de software de una organizacin como la consistencia con la que se aplica a proyectos en toda la organizacin. La madurez de los procesos de software implica que debe cultivarse la capacidad del proceso de software. La mejora requiere un soporte fuerte de administracin y un enfoque a largo plazo que sea consistente. A medida que una organizacin de software madura, necesita una infraestructura y cultura para soportar sus mtodos, prcticas y procedimientos de manera que subsistan aun despus de que los que los definieron originalmente se hayan ido. La cultura de la organizacin puede resumirse como sa es la forma en la que hacemos las cosas aqu. Se ve en las expectativas de la gente en cuanto a cmo trabajan juntos. Una de las determinantes de la cultura organizacional es su infraestructura. La infraestructura es el esqueleto base subyacente de una organizacin o sistema, incluyendo las estructuras, polticas, estndares, entrenamiento, facilidades y herramientas organizacionales, que soporta su performance. La institucionalizacin es la construccin de la infraestructura y de la cultura para soportar los mtodos, prcticas y procedimientos de manera que sean la forma de llevar adelante los negocios. El resultado de la institucionalizacin es el despliegue de los procesos de software que son efectivos, usables y que se aplican en forma consistente en toda la organizacin. 1.4 Administracin de Calidad Total y el CMM Aunque los administradores e ingenieros de software a menudo conocen sus problemas en gran detalle, pueden no estar de acuerdo en cuanto a qu mejoras son las ms importantes. Sin una estrategia organizada para las mejoras es difcil lograr un consenso entre la administracin y el personal profesional sobre qu actividades de mejora se deben tomar primero. Para lograr resultados duraderos de los esfuerzos de mejorar el software, es necesario disear un camino evolutivo que aumente la madurez del proceso de software de una organizacin en etapas. El CMM ordena estas etapas de manera que las mejoras en cada etapa proporcionen una base sobre la cual construir las mejoras que se tomen en la etapa siguiente. De esta manera una estrategia de mejoras extrada de un esqueleto base de la madurez de un proceso de software proporciona un mapa de carretera una mejora continua del proceso. Identifica las deficiencias en la organizacin y gua el avance; no tiene el objetivo de proporcionar una reparacin

rpida para los proyectos en problemas. La estructura en etapas del CMM est basada en principios de calidad del producto que han existido por los ltimos 60 aos. En la dcada del 30, Walter Shewart promulg los principios del control estadstico de calidad. Sus principios se desarrollaron ms y se demostraron exitosamente en el trabajo de W. Edwards Deming [Deming86] y Joseph Juran [Juran88, Juran89]. Estos principios han sido adaptados por el SEI en una estructura base que establece la administracin de un proyecto y las bases de ingeniera para un control cuantitativo del proceso de software, que es la base para una mejora continua del proceso. La estructura base de la madurez en la que estos principios de calidad han sido adaptados fue inspirada por primera vez por Philip Crosby en su libro La Calidad es gratis [Crosby79]. La grilla de madurez de la administracin de la calidad de Crosby describe 5 etapas evolutivas para adoptar prcticas de calidad. Esta estructura base de madurez fue adaptada al proceso de software por Ron Radice y sus colegas, trabajando bajo la direccin de Watts Humphrey en IBM [Radice85]. Humphrey llev esta estructura base de madurez al Instituto de Ingeniera del Software en 1986, refin el concepto de los niveles de madurez y desarroll la base para su uso actual en toda la industria del software. El CMM es por lo tanto una aplicacin de los conceptos de administracin de procesos de la Administracin de Calidad Total (TQM, Total Quality Management) al software, como se ilustra en la Fig. 1.2. El TQM puede definirse como la aplicacin de mtodos cuantitativos y de recursos humanos para mejorar los materiales y servicios provistos como entradas a una organizacin y para mejorar todos los procesos dentro de la organizacin. El objetivo del TQM es satisfacer las necesidades del cliente, ahora y en el futuro. Al hacer mejoras al proceso de software es importante recordar que los esfuerzos de mejoras funcionan dentro del contexto mayor de un negocio. Los esfuerzos de mejoras deberan alinearse con las necesidades de la organizacin como negocio y con los esfuerzos TQM que puedan existir dentro de la organizacin. Esta alineacin tendr un efecto crtico sobre el xito del esfuerzo de mejora del proceso del software. 1.5 Satisfaccin del Cliente El objetivo de la satisfaccin del cliente en TQM es el objetivo del CMM. Una de las necesidades detrs del trabajo del proceso de software del SEI fue la necesidad del DoD de identificar contratistas de software calificados. El mtodo de evaluacin de la capacidad de software, en donde una agencia de adquisicin usa el CMM para evaluar la fortaleza, debilidades y riesgos de seleccionar un contratista de software en particular y/o para monitorear un contrato de software, resulta de eta necesidad del cliente. El CMM no especifica explcitamente que el cliente debe quedar satisfecho (o encantado) con el producto de software. El CMM s especifica que el proveedor de software debe trabajar con el cliente para entender los requerimientos del cliente y debe construir productos de software que satisfagan las necesidades del cliente segn se documente en los requerimientos asignados al componente de software del sistema o producto total que se est suministrando. Filosficamente, algunos pueden sostener que dejar al cliente encantado debe ser buscado en forma ms especfica. La satisfaccin del cliente debera ser una componente crtica de la mejora del proceso de cualquier organizacin o de los esfuerzos de administracin de calidad, y debera atacarse como apropiado en el entorno del negocio de la organizacin. Tambin hay otra cara de la moneda. El CMM se enfoca en los procesos del suministrador de software, pero la relacin cliente-suministrador es una calle de dos manos. En un contexto contractual, el cliente externo es parte del sistema que produce productos y comparte la responsabilidad de proporcionar un ambiente sano para el proveedor. 1.6 Beneficios y Riesgos de las mejoras Basadas en un Modelo

El uso de un modelo como el CMM como estructura base para las mejoras puede resultar en muchos beneficios. El CMM ayuda a forjar una visin compartida de lo que significa la mejora del proceso de software para la organizacin. Establece un lenguaje comn para hablar acerca del proceso de software, y define un conjunto de prioridades para atacar problemas de software. El CMM apoya la medicin del proceso de software proporcionando una estructura base para realizar apreciaciones confiables y consistentes. Aunque el juicio humano no puede extraerse de estas apreciaciones de procesos, el CMM proporciona una base para la objetividad. Esta estructura base de medicin tambin sirve de soporte a comparaciones en toda la industria a travs de informes del estado de la prctica [Humphrey89b, Kitson92, Herbsleb94] y estudios de casos de mejoras de procesos de software [Humphrey91b, Lipke92, Dion93, Wohlwend93]. Tal vez ms importante que esto, el CMM construye un conjunto de procesos y prcticas que han sido desarrollados en colaboracin con una amplia eleccin de practicantes. Cientos de profesionales del software revisaron el CMM durante su desarrollo. Miles de sus comentarios y solicitudes de cambios sobre los diversos borradores del CMM fueron revisados y resueltos por los equipos de revisin y desarrollo del CMM, y se estableci un Panel de Consejos sobre el CMM para ayudar al SEI a entender y resolver temas elevados por la comunidad. Ms de 300 personas participaron en el ltimo workshop de CMM antes de la edicin de la versin actual de CMM. Mientras que no hubo un acuerdo unnime sobre las recomendaciones a veces en conflicto, es justo decir que el CMM representa un consenso amplio de buenas prcticas de administracin y de ingeniera de software. Sin embargo, basar los esfuerzos de mejora en un modelo no est libre de riesgos. En las palabras de George Box: Todos los modelos son incorrectos; algunos modelos son tiles. Los modelos son simplificaciones del mundo real que representan, y el CMM no es una descripcin exhaustiva del proceso de software. No es comprehensiva; slo toca otros factores que no pertenecen al proceso, como la gente y la tecnologa, que afectan el xito de los procesos de software. El CMM representa un enfoque de ingeniera con sentido comn a la mejora del proceso de software. Los niveles de madurez, las reas de proceso claves, las caractersticas comunes, y las prcticas clave se ha discutido y revisado en forma extensa dentro de la comunidad del software. Aunque el CMM no es perfecto, representa un amplio consenso de la comunidad del software y es una herramienta til para guiar los esfuerzos de mejorar el proceso del software. El CMM proporciona una estructura conceptual para mejorar la administracin y el desarrollo de los productos de software de una manera disciplinada y consistente. No garantiza que los productos de software se construirn exitosamente o que todos los problemas en la ingeniera del software se resolvern adecuadamente. Sin embargo, informes actuales de programas de mejoras basados en CMM indican que puede mejorar la posibilidad de que una organizacin de software lograr sus objetivos de productividad, calidad y costos. El CMM identifica prcticas para un proceso de software maduro y proporciona ejemplos del estado de la prctica (y en algunos casos, el estado del arte), pero no est pensado para ser exhaustivo u obligatorio. El CMM identifica las caractersticas de un proceso de software efectivo, pero la organizacin madura atiende a todos los temas que son esenciales para un proyecto exitoso, incluyendo la gente y la tecnologa, as como al proceso. El CMM es una herramienta para ayudar a las organizaciones de software a mejorar su proceso de software. Tambin puede ayudar a las organizaciones de adquisicin a seleccionar y manejar a los contratistas de software. Sin embargo, el CMM es slo una herramienta, y debe usarse en forma inteligente para ayudar a que las organizaciones atiendan a sus necesidades de negocios especficas. El propsito del CMM es describir buenas prcticas de administracin e ingeniera segn se organizan por la estructura base de madurez. Se necesita un sano juicio para usar el CMM correctamente y con inteligencia. Inteligencia, experiencia y conocimiento deben darle una interpretacin adecuada al CMM en

un ambiente especfico. Esta interpretacin debe basarse en las necesidades del negocio y en los objetivos de la organizacin y os proyectos. Una aplicacin rutinaria del CMM orientada hacia la checklist tiene el potencial de daar a la organizacin en vez de ayudarla. El logro de niveles ms altos de madurez del proceso de software es gradual y requiere de un compromiso a largo plazo con una mejora continua del proceso. Las organizaciones de software pueden tardar diez aos o ms en construir la base, y la cultura orientada hacia, para una mejora continua del proceso. Aunque un programa de mejora de un proceso de una dcada de duracin es ajeno a l mayora de las compaas de software, se requiere este esfuerzo sostenido para producir organizaciones de software maduras.