CMM – Capability Maturity Model

Resumen
El modelo de madurez de capacidad (CMM) surge como iniciativa de SEI, a
requerimiento del Gobierno Federal de los Estados Unidos de América. Este modelo
propone un esquema de cinco niveles de madurez logrados mediante pequeños cambios
evolutivos en determinadas áreas. Se considera que una organización ha alcanzado un
nivel de madurez si ha institucionalizado todas las prácticas incluidas en ese nivel y sus
inferiores.

Los cinco niveles son:

1 – Inicial
2 – Repetible
3 – Definido
4 – Gestionado
5 – Optimizado
Cada área clave es abordada por medio de un conjunto de prácticas o procesos clave,
organizadas en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de
proceso define un conjunto de buenas prácticas que habrán de ser:
1. Definidas en un procedimiento documentado
2. Provistas (la organización) de los medios y formación necesarios
3. Ejecutadas de un modo sistemático, universal y uniforme(institucionalizadas)
4. Medidas
5. Verificadas

Estas características reciben el nombre de características comunes. Las características

1,2 4 y 5 institucionalizan las mejoras del proceso mientras que la 3 es la que realmente
implementa la mejora.

Finalmente se concluye que CMM es un modelo que si bien provee un soporte para
madurar un proceso, no asegura que el producto construido en los proyectos sea el
correcto. Además a medida que los niveles aumentan, la cantidad de documentación que
institucionaliza es mucho mayor.

Ingenieria de Software 2006 – U.N.C.P.B.A. 1

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Objetivos
9 Narrar brevemente la historia del Modelo de Capacidad de la Madurez.
9 Presentar una visión general de la estructura interna.
9 Describir brevemente los niveles de madurez de los procesos.
9 Describir las areas claves de cada nivel.
9 Introducir brevemente solo las prácticas claves Practicas Realizadas que sirven
como guia para cumplir con determinados objetivos en cada nivel.

Ingenieria de Software 2006 – U.N.C.P.B.A. 2

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Resumen ........................................................................................................................... 1
Objetivos........................................................................................................................... 2
Modelo de capacidad y madurez ...................................................................................... 4
Motivación.................................................................................................................... 4
Madurez de una Organización...................................................................................... 4
Visión general de CMM ............................................................................................... 5
Los cinco niveles de maduración de proceso de software............................................ 6
Entendiendo el CMM ................................................................................................... 7
Características de Comportamiento de los Niveles de Madurez ...................................... 7
Nivel 1: Nivel Inicial (Initial Level) ......................................................................... 8
Nivel 2: Nivel Repetible (Repeteable Level)............................................................ 8
Nivel 3: Nivel Definido (Defined Level) .................................................................. 9
Nivel 4: Nivel Administrado (Manager Level) ...................................................... 10
Nivel 5: Nivel Optimizando (Optimizing Level) .................................................... 10
Capacidad de Proceso y Predicción de la Performance.......................................... 11
Salteando Niveles de Madurez ................................................................................... 12
Definición operacional de CMM.................................................................................... 14
La estructura interna de los Niveles de Madurez ....................................................... 14
Áreas claves de proceso en el Nivel 2 ................................................................... 17
Áreas claves de proceso en el Nivel 3 ................................................................... 18
Áreas claves de proceso en el Nivel 4 ................................................................... 19
Áreas claves de proceso en el Nivel 5 ................................................................... 20
Conclusión ...................................................................................................................... 22
Apéndice A - Key Practices............................................................................................ 23
Nivel 2 ........................................................................................................................ 23
Administración de requerimientos.......................................................................... 23
Planeamiento del proyecto de software:................................................................. 24
Control de proyectos de software:.......................................................................... 26
Aseguramiento de la calidad del software:............................................................. 29
Administración de configuración de software:....................................................... 30
Nivel 3 ........................................................................................................................ 32
Concentración del proceso organizacional:............................................................ 32
Definición de procesos organizacionales: .............................................................. 32
Programa de capacitación:...................................................................................... 34
Administración integral de software: ..................................................................... 35
Coordinación entre grupos: .................................................................................... 36
Peer reviews............................................................................................................ 37
Nivel 4 ....................................................................................................................... 37
Administración Cuantitativa de Procesos............................................................... 37
Nivel 5 ........................................................................................................................ 43
Prevención de Defectos: ......................................................................................... 43
Administración de Cambios tecnológicos .............................................................. 45
Ejecución de Peer Reviews .................................................................................... 45
Administración de cambios: ................................................................................... 47
Apéndice B – Glosario de Términos .............................................................................. 49
Apendice C – Referencias .............................................................................................. 50

Ingenieria de Software 2006 – U.N.C.P.B.A. 3

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Modelo de maduración de la capacidad

Motivación
Luego de varias décadas de no obtener resultados satisfactorios al con nuevas
tecnologías y metodologías de software, el sector empresarial y gubernamental, se da
cuenta que sufre de incapacidad al manejar sus procesos de software. Por esos años, los
proyectos generalmente padecían de demoras excesivas así como duplicación del
presupuesto acordado. En estas circunstancias era imposible apreciar las ventajas podían
proveer las nuevas metodologías y métodos.

Es por eso que en noviembre de 1986, el Software Engineering Institute (SEI), con la
asistencia de Mitre Corporation, comenzó a desarrollar un framework de madurez de
proceso, el que asistiría a las organizaciones a mejorar su proceso de Software. En
septiembre de 1987, el SEI presenta una breve descripción del mencionado [Humphrey
87a] el cual fuera posteriormente profundizado en el libro de Humphrey “Managing
the Software Process” [Humphrey89]. Dos métodos, ”Aseguración de procesos de
software” y “Cuestionario de madurez y evaluación” [Humphrey87b] fueron
desarrollados para aproximar la madurez de procesos de Software.

Luego de experimentar por cuatro años el framework de Madurez de Procesos y una

versión preliminar del cuestionario de madurez, el SEI evolucionó el mencionado
framework a lo que es el Modelo de madurez de capacidad (o Capability Maturity
Model for Software) (CMM) [Paulk91, Weber91]. El CMM presenta un conjunto de
prácticas recomendadas dentro de varias áreas de proceso clave que han demostrado
realzar la capacidad de proceso del Software. Está basado en el conocimiento adquirido
por mejoras en el proceso de software y extensivo feedback tanto de la industria como
del gobierno.

Este modelo provee a las organizaciones de Software de una guía de cómo controlar los
procesos para desarrollar y mantener software además de cómo evolucionar en una
cultura de ingeniería de Software y administración de excelencia. Fue diseñado para
guiar a las organizaciones a seleccionar estrategias para mejorar procesos determinando
la madurez actual del proceso e identificando algunos inconvenientes críticos en la
calidad de Software y mejora del proceso. Concentrándose en un conjunto de
actividades y trabajando agresivamente para lograrlas, una organización puede mejorar
la amplitud de proceso permitiendo logros continuos y capacidad perdurable.

Madurez de una Organización

Una organización de Software puede clasificarse de acuerdo a cuan madura sea.
La madurez está relacionada con el seguimiento fiel a un proceso preestablecido.
En organización de software inmadura, los procesos generalmente son improvisados por
quienes llevan adelante cada proyecto en toda su duración. Hay casos que si bien existe
un proceso de software especifico, el mismo no es seguido fielmente durante el
proyecto. Las organizaciones con estas características se las conoce como reactivas o
reaccionarias ya que los managers suelen estar concentrados en resolver crisis
inmediatas (mas bien conocidas como “apagar el incendio”). Sucede que la
planificación y los presupuestos son excedidos con frecuencia debido a que sus
estimaciones no están basadas en datos reales. Esta situación hace que las

Ingenieria de Software 2006 – U.N.C.P.B.A. 4

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

organizaciones inmaduras vean comprometida la calidad y funcionalidad de sus

productos cuando se imponen deadlines estrictos (fecha de entrega).

No existen bases sólidas para realizar un juicio sobre la calidad de un producto o para
resolver un problema de producción o de proceso. Esto conlleva a que la calidad del
producto no sea predecible y que las actividades que se realizan para incrementar la
calidad como la verificación y testeo, se vean restringidas o eliminadas cuando se
exceden los planes.

En cambio, las organizaciones de software maduras poseen una gran capacidad

de organización a la hora de manejar el desarrollo de software y el proceso de
mantenimiento. El proceso es rigurosamente respetado y conocido con precisión por el
staff existente y los nuevos empleados. Los procesos definidos están listos para ser
usados [Humphrey91b] y son consientes en la manera en la que el trabajo es realizado.
Estos procesos son actualizados cuando es necesario, y se buscan mejoras a través de
pruebas pilotos controladas realizando análisis de costo beneficio. Los roles y las
responsabilidades dentro del proceso definido son claramente establecidas en cada
proyecto y en toda la organización.

En organizaciones maduras, los managers controlan la calidad del producto de

software a la vez que estiman la satisfacción del cliente. Hay bases cuantitativas y
objetivas para la evaluación de la calidad del producto y el análisis del problema con el
producto y el proceso. Se usan datos históricos para el planeamiento y el presupuesto.
Todo esto hace que los resultados esperados para el costo, planeamiento, funcionalidad
y calidad del producto sean generalmente alcanzados. En general, se sigue fielmente un
proceso disciplinado ya que todos los participantes entienden el valor de hacerlo,
además de que existe la infraestructura necesaria para soportar el proceso.

Visión general de CMM

En las organizaciones de Software que quieren mejorar sus procesos de

producción uno de los problemas que surgen es que no hay acuerdo sobre qué mejoras
deben realizarse. Para solucionar este conflicto es necesario contar con una estrategia
organizativa que provea una lista ordenada de mejoras a aplicar. CMM propone
alcanzar los resultados mediante pequeños cambios evolutivos. El framework de
maduración de proceso de software [Humphrey 87a] ordena los cambios por etapas de
manera tal que el mejoramiento de cada una de ellas brinde una base sobre la cual
encarar la siguiente etapa de mejora. De esta manera, el framework describe una
estrategia para mejoras continuas, guiando el avance e identificando deficiencias en la
organización; sin embargo CMM no provee mejoras rápidas.

CMM brinda, a las organizaciones de software una guía de cómo controlar sus
procesos para desarrollo y mantenimiento del software, y como evolucionar hacia la
cultura de ingeniería de software y excelencia en la administración. El CMM fue
diseñado para guiar a la organización de software en el proceso de selección de
estrategias de mejoras para determinar el nivel actual de madurez e identificar algunos
problemas críticos en la calidad del software y en la mejora del proceso. La forma de
lograr los objetivos propuesta es concentrarse en un conjunto de actividades y trabajar

Ingenieria de Software 2006 – U.N.C.P.B.A. 5

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

agresivamente para lograrlas de manera que estas provean logros continuos y duraderos
en el proceso de software.

Los cinco niveles de maduración de proceso de software

La mejora continua de procesos esta basada en realizar pequeños cambios
evolutivos en lugar de una innovación revolucionaria [Imai86]. El CMM brinda a las
organizaciones un marco para organizar los pasos de la mejora en cinco niveles de
madurez, estableciendo fundamentos para la mejora continua del proceso. Estos cinco
niveles, definen una escala ordenada para evaluar la madurez del proceso de software.
Además, estos niveles sirven para priorizar sus esfuerzos para la mejora.

Un nivel de maduración es una plataforma definida con objetivos claros de manera tal,

que cuando son cumplidos, se estabiliza una componente importante del proceso de
software. Cada uno de los niveles de madurez provee fundamentos para la mejora del
siguiente nivel, resultando en un crecimiento en la capacidad de la organización.

En la figura anterior se muestran los cinco niveles de maduración junto con las acciones
prioritarias para lograr un ascenso de un nivel a otro. Los cinco niveles pueden ser
descriptos brevemente como:
1. Inicial: el proceso de software esta caracterizado como ad hoc y
ocasionalmente caótico. Algunos procesos están definidos, y el éxito depende
del esfuerzo individual y no de la organización.
2. Repetible: procesos administrativos básicos en los proyectos para el
seguimiento de costo, planeamiento y funcionalidad. La disciplina necesaria
en los procesos1 es acorde para repetir éxitos anteriores de proyectos con

1
Todas las veces que se nombra tanto al proceso, como a los productos, actividades y proyectos se está
refiriendo al proceso (productos, actividades, etc.) del software, salvo que se indique lo contrario.

Ingenieria de Software 2006 – U.N.C.P.B.A. 6

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

aplicaciones similares.
3. Definido: el proceso para la administración y la ingeniería esta documentado,
estandarizado e integrado a un proceso estándar para la organización. Todos
los proyectos usan una versión del proceso estándar de la organización
aprobada y ajustada para el desarrollo y manutención del software.
4. Administrado: Se detalla medidas para que el proceso de software y la
calidad del producto sean recolectados. Ambos son entendidos y controlados
cuantitativamente.
5. Optimizado: existe un feedback cuantitativo del proceso, lo que permite una
mejora continua del mismo. También se manejan ideas y tecnologías
innovadoras.

Entendiendo el CMM
El CMM es un modelo descriptivo en el sentido que describe los atributos esenciales
que se esperan para caracterizar a una organización en un nivel de maduración en
particular. Es decir, es un modelo normativo en el sentido de que detalla prácticas que
caracterizan el tipo normal de comportamiento que se espera en los proyectos de gran
escala de una organización en el contexto de contrataciones gubernamentales. La
intención es que el CMM brinde un nivel de abstracción que no sea excesivamente
restricto, sino cómo el proceso de software es implementado.

En cualquier contexto en el cual el CMM puede ser aplicado, se debería usar una
interpretación razonable de las actividades a realizar.

El CMM no es prescriptito, es decir no dice a la organización cómo debe mejorar. El

CMM dice en qué nivel se encuentra una organización sin decir una manera especifica
de cómo llegar a él. Puede tomar varios años pasar de nivel 1 a 2, aunque aumentar de
nivel 2 a 3, de 3 a 4, etc. solo toma aproximadamente dos años.

Mejoramientos en el proceso de software ocurren dentro del contexto de los planes

estratégicos y objetivos de negocio de la empresa, sus estructuras organizativas, la
tecnología usada, su cultura social, y su sistema de administración. El CMM se
concentra en aspectos del proceso de la Administración de calidad total producida;
mejoramientos de procesos exitosos que los aspectos externos al alcance del proceso de
software son también.

Características de Comportamiento de los Niveles de

Madurez
La madurez de los niveles 2 a 5, se puede caracterizar a través de:

• Las Actividades que realiza la organización para establecer o mejorar el proceso

de software.
• Las Actividades desarrolladas en casa proyecto
• La Capacidad de proceso resultante a través de los proyectos.

Ingenieria de Software 2006 – U.N.C.P.B.A. 7

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

A su vez, cada nivel de CMM, aumenta la visibilidad dentro del proceso de software
tanto para el manager como para el equipo de ingeniería: los ingenieros de software
tienen una visión detallada del estado del proyecto porque son los primeros que reciben
información acerca del estado y la performance del proyecto. En grandes proyectos, la
visión está usualmente está delimitada por la experiencia personal en el área de su
responsabilidad, por lo que podemos entonces, caracterizar también a los niveles de
madurez por el nivel de visibilidad que este posee.

A continuación se describirá brevemente cada uno de los niveles teniendo en cuenta

todos y cada uno de los aspectos anteriores.

Nivel 1: Nivel Inicial (Initial Level)

• La organización típicamente, no provee un ambiente estable para el desarrollo y

mantenimiento del software, por lo que, los beneficios de una buena práctica de
ingeniería de software, se ven socavados por un inefectivo planeamiento y
sistemas obligados a reaccionar. Aunque las organizaciones de Nivel 1,
frecuentemente se caracterizan por ser ad hoc e incluso caóticas, los procesos
que éstas desarrollan, en su mayoría, son productos que funcionan, aunque estén
por encima del presupuesto y del cronograma previamente estipulados.

• Durante una crisis, los proyectos abandonan los procedimientos planeados y se

limitan al código y al testeo. El éxito depende en su totalidad, de tener un buen
manager y del equipo de software.

• La capacidad de los procesos de software de la organización es impredecible, el

proceso de software constantemente esta cambiando mientras el trabajo
progresa. La planificación, el presupuesto, la funcionalidad y la calidad del
producto son impredecibles. La performance depende de las capacidades de los
individuos y varía de acuerdo a sus habilidades, conocimientos y motivaciones.
La capacidad, es una característica de los individuos, no de las organizaciones.
Las organizaciones de Nivel 1, con frecuencia, se exceden en los cronogramas y
fechas de entrega por un amplio margen. El tiempo de desarrollo se ve
incrementado por las actividades que hay que realizar para corregir errores.

• En el nivel inicial, el proceso de software es una entidad amorfa, una caja negra,
y la visibilidad de los procesos del proyecto es limitada. Como la secuencia de
actividades no está bien definida, los administradores tienen una gran dificultad
para definir el estado del progreso del proyecto, los tiempos y sus actividades.
Los requerimientos dentro del proceso de software fluyen de manera
descontrolada.

Nivel 2: Nivel Repetible (Repeteable Level)

• Un objetivo de este nivel es institucionalizar procesos de administración

efectivos para los proyectos de software, que permitan a las organizaciones
repetir prácticas exitosas desarrolladas en proyectos anteriores, aunque la

Ingenieria de Software 2006 – U.N.C.P.B.A. 8

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

implementación específica del proceso pueda variar en los distintos proyectos.

Los administradores se deben centrar en sus propios procesos para adquirir una
disciplina de proceso de software. Éstos pueden diferir entre los proyectos de la
organización; las organizaciones deben “tener” políticas que sirvan como guía
para “establecer” una correcta administración de los procesos.

• Los proyectos implementan procesos efectivos que son definidos,

documentados, utilizados, entrenados, medidos, reforzados y mejorados. Se
definen los estándares de los proyectos de software y la organización asegura
que éstos serán fielmente respetados. El manager del proyecto controla los
costos, cronogramas y funcionalidades; los problemas en el cumplimiento de los
compromisos son identificados a medida que [Link] proyecto de software
trabaja con subcontratantes, si existiera alguno, para establecer una relación
cliente – proveedor efectiva.

• La capacidad de los procesos de software de una organización de Nivel 2, es

disciplinada, la planificación y el control del proyecto de software es estable y
éxitos anteriores pueden ser repetidos. El proceso del proyecto está bajo un
control efectivo del sistema de administración del proyecto, siguiendo planes
realistas y basados en la performance de proyectos previos.

• En este nivel, se realiza un control requerimientos del cliente vs. trabajo

realizado, y se establecen prácticas básicas para la administración de los
proyectos. El proceso de desarrollo de software puede ser visto como una
sucesión de cajas negras que, en ciertos puntos de transición (los de control),
permiten a los administradores incrementar su visibilidad mientras las
actividades fluyen dentro de esas cajas. El administrador puede no conocer las
actividades realizadas dentro de las cajas. Se conocen tanto los puntos de control
para confirmar el avance como los productos finales del proceso.

Nivel 3: Nivel Definido (Defined Level)

• En este nivel, se documenta el proceso (o los procesos) estándares para el

desarrollo y mantenimiento de software de toda la organización. Éstos procesos,
se usan (y mantienen) para ayudar a los administradores de software y al equipo
técnico a desempeñarse de manera más eficiente. La organización explota las
prácticas efectivas de ingeniería de software cuando estandariza sus procesos de
software.

• Los proyectos se ajustan a los procesos de software estándares de la

organización para desarrollar su propio proceso de software definido, el cual se
adapta a las características únicas del proyecto (lo que se conoce como proceso
de software definido del proyecto). Un proceso bien definido puede ser
caracterizado como aquel que incluye legibilidad, criterio, entradas, estándares y
procedimientos para realizar el trabajo, mecanismos de verificación, salidas, y
criterios de completitud. Como el proceso de software está bien definido, la
administración tiene una buena visión interna del progreso técnico del proyecto.

Ingenieria de Software 2006 – U.N.C.P.B.A. 9

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

• La capacidad del proceso de software de las organizaciones de nivel 3 puede ser

resumida como estándar y consistente porque tanto la ingeniería de software
como las actividades de administración son estables y repetibles. Esta capacidad
de proceso se basa en un entendimiento común y organizacional de las
actividades, roles, y responsabilidades en un proceso de software definido.

• En el nivel definido, la estructura interna de las cajas, es decir, las tareas en el

proceso de software del proyecto, son visibles y representan la forma en la que
el proceso de software estándar de la organización ha sido aplicado a proyectos
específicos. Administradores e ingenieros entienden sus roles y
responsabilidades en el proceso y como sus actividades interactúan en el nivel
adecuado de detalle. La administración está preparada para riesgos que puedan
ocurrir.

Nivel 4: Nivel Administrado (Manager Level)

• La organización establece objetivos de calidad tanto para productos como para

procesos de software. Una base de datos de procesos de software de la
organización, se usa para recolectar y analizar los datos disponibles de los
procesos de software definidos de los proyectos. Éstos procesos de software son
implementados con medidas bien definidas y consistentes. Estas medidas
establecen los fundamentos cuantitativos para evaluar los procesos y productos
de software del proyecto.

• Los proyectos alcanzan el control sobre sus productos y procesos

disminuyendo la variación de la performance de sus procesos para mantenerse
en límites cuantitativos aceptables. Las variaciones significativas de la
performance del proceso pueden ser distinguidas de la variación aleatoria
(ruido), particularmente en las líneas de producto establecidas. Los riesgos
involucrados al mover la curva de aprendizaje (¿?) del dominio nuevo de una
aplicación son conocidos y administrados cuidadosamente.

• La capacidad del proceso de software de las organizaciones de nivel 4 puede

ser resumida como predecible, porque el proceso se mide y opera dentro de
límites cuantitativos. Este nivel de capacidad de proceso, permite a una
organización predecir tendencias en la calidad de software y productos que se
ajusten a esos límites; en caso de que se excedan, se toman acciones corregir la
situación. Los productos de software son de una calidad predeciblemente alta.

• Los procesos de software definidos se instrumentan y controlan

cuantitativamente. Los administradores son capaces de medir el progreso y los
problemas. Tiene una base cuantitativa para tomar decisiones. Su habilidad para
predecir las salidas crece de forma estable y precisa mientras que la variabilidad
en el proceso disminuye.

Nivel 5: Nivel Optimizando (Optimizing Level)

Ingenieria de Software 2006 – U.N.C.P.B.A. 10

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

• En el Nivel Optimizado, toda la organización se concentra en la mejora

continua del proceso. La organización tiene los medios para identificar
proactivamente las debilidades y fortalezas del proceso, con el objetivo de
prevenir los defectos. Los datos, en la efectividad de los procesos de
software, se usan para realizar análisis de costo/beneficios de nuevas
tecnologías y de cambios propuestos a los procesos de software de la
organización. Se identifican y transfieren, a lo toda la organización,
innovaciones que aprovechan lo mejor de la práctica de ingeniería de
software.

• Durante el desarrollo del proyecto, se analizan defectos para determinar su

causa. Se evalúan los procesos de software para prevenir la recurrencia en
tipos de defectos conocidos y esto se transfiere a toda la organización.

• La capacidad del proceso de software de las organizaciones de nivel 5 puede

ser caracterizada como de mejoramiento continuo, las organizaciones se
esfuerzan continuamente en ampliar el rango de la capacidad de sus
procesos, mejorando así la performance de sus proyectos; este mejoramiento
se da por dos causas: el avance incremental en los proyectos existentes, y por
las innovaciones usando nuevas tecnologías y métodos. Las mejoras de
tecnologías y métodos se planean y administran como actividades de
negocios ordinarias.
• La disciplina y el cambio son una forma de vida y las actividades
defectuosas se identifican y reemplazan. La visibilidad se extiende más allá
de la existencia de los procesos y dentro de los efectos de potenciales
cambios a los mismos. Los administradores son capaces de estimar y de
hacer un seguimiento cuantitativo del impacto y de la efectividad del
cambio.

Capacidad de Proceso y Predicción de la Performance

La madurez del proceso de software de una organización, ayuda a predecir la

habilidad de los proyectos para alcanzar los objetivos. A medida que el proceso de
software de la organización va madurando, las organizaciones obtienen una mejoría en
alcanzar sus objetivos esperados en tres aspectos:

1. Predicción: la diferencia entre los resultados esperados y los resultado obtenidos

disminuye en los procesos
2. Control: al incrementar la madurez la variabilidad de los resultados actuales
entorno a los resultados esperados disminuye.
3. Efectividad; los resultados esperados mejoran al incrementarse la madurez de la
organización; los costos disminuyen, los tiempos de desarrollo se tornan más
cortos y la productividad y calidad aumentan.

En la figura, las salidas del proyecto de software son más predecibles eliminado el ruido
del proceso conforme aumenta la madurez. En sistemas sin precedentes, las nuevas
tecnologías y aplicaciones, disminuyen la capacidad de un proceso e incrementan la
variabilidad. La administración y las prácticas de ingeniería características de
organizaciones más maduras ayudan a identificar y tratar los problemas más temprano

Ingenieria de Software 2006 – U.N.C.P.B.A. 11

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

en el ciclo de desarrollo. En algunos casos un proceso maduro significa que proyectos

que fallarán se identifican antes en el proceso de software.

Salteando Niveles de Madurez

Los niveles de madurez de CMM, especifican las características de una

organización para un nivel de madurez. Cada nivel se sienta sobre las bases de los
niveles que lo preceden para implementar los procesos efectiva y eficientemente.

De cualquier forma, las organizaciones pueden hacer un uso beneficioso de los

procesos descriptos en niveles superiores; los procesos de ingeniería tales como el
análisis de requerimientos, el diseño, la codificación y el testeo, no se discuten hasta el
Nivel 3 de CMM, pero las organizaciones de Nivel 1 deben desarrollar estas
actividades. Una organización de Nivel 1 o de Nivel 2, puede ser capaz de realizar peer
reviews (Nivel 3), hacer Análisis de Pareto (Nivel 4) ó probar nuevas tecnologías (Nivel
5) y sacar provecho de estas técnicas.

Sin embargo, estos procesos no pueden lograr por completo su potencial, hasta
que no se hallan establecido las correspondientes bases; peer reviews no pueden ser

Ingenieria de Software 2006 – U.N.C.P.B.A. 12

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

completamente efectivo hasta que el producto de software no esté implementado

consistentemente.

Saltear niveles es contraproducente pues cada nivel representa la base necesaria

para alcanzar el nivel siguiente. CMM identifica los niveles a través de los cuales la
organización debe desenvolverse para establecer una cultura de ingeniería de software
de excelencia. Aquellos niveles que no tienen estas bases correctamente desarrolladas,
fallan en los puntos en los que son más necesarios y no proveen ningún aporte al futuro
mejoramiento.

Los esfuerzos por mejorar los procesos, se deben centrar en las necesidades de la
organización en el contexto de su “ambiente de negocio”. La habilidad para
implementar procesos de niveles de madurez más altos, no implica que estos niveles
puedan ser salteados.

Ingenieria de Software 2006 – U.N.C.P.B.A. 13

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Definición operacional de CMM

Tal como se comentara anteriormente, CMM representa un framework para realizar
mejoras sobre organizaciones que desarrollan software y desean incrementar la
capacidad de su proceso de producción. Se considera al CMM como un modelo
descriptivo dado que describe atributos claves que se esperan para caracterizar una
organización en un determinado nivel de madurez. Por otro lado, es considerado un
modelo normativo en el sentido que existen prácticas que caracterizan los tipos de
comportamiento esperados de una organización que realiza proyectos a gran escala.

El CMM describe el resultado esperado del proceso pero sin indicar como
implementarlo, es por eso que es considerado prescriptivo. Por otra parte, CMM tiene
una estructura diseñada para proveer soporte a diferentes grupos o equipos dentro de la
organización.

• Grupos de verificación usan CMM para identificar puntos débiles o

problemáticos en la organización.

• Equipos de evaluación usan el CMM para identificar los riesgos de seleccionar

entre diferentes contratistas, ganar licitaciones y monitorear contratos.

• Gerentes y Staff Técnico usa CMM para entender actividades necesarias para
planificar e implementar una mejora en el proceso de la organización.

• Grupos de Mejora de Proceso tales como SEPG usan CMM como guía para
definir y mejorar el Proceso de Software de la organización.

Dada la vasta aplicación del CMM, es necesario que sea descompuesto en suficiente
detalle para que las recomendaciones de cada proceso puedan ser derivadas desde la
estructura de los niveles de madurez. La descomposición, además, indica que los
procesos y su estructura caracterizan la madurez y capacidad del proceso de software.

La estructura interna de los Niveles de Madurez

Cada nivel de madurez ha sido descompuesto en distintas partes. A excepción del nivel
1, la descomposición de cada nivel abarca desde resúmenes abstractos hasta su
definición operacional en prácticas claves. Cada nivel de madurez se compone de varias
áreas de proceso clave. Según [KPCMM93] un área de proceso clave es un abanico de
actividades interrelacionadas, que cuando son llevadas a cabo, logran un conjunto de
objetivos considerados importantes para establecer la capacidad de un proceso. Cada
área clave de proceso ha sido cuidadosamente definida para abordar un único nivel de
madurez. Por convención, cada una de estas, es organizada en cinco grupos llamadas
características comunes. Estas son atributos que indican que tanto la implementación
como la institucionalización, es efectiva, repetible y perdurable.

Ingenieria de Software 2006 – U.N.C.P.B.A. 14

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Los cinco grupos son:

Objetivos a realizar: Describe acciones que la organización debe tomar para asegurarse
que el proceso esta establecido y perdurará. Típicamente involucra establecer políticas
organizacionales y aval de la cúpula administrativa.

Capacidad para realizar: Precondiciones que deben existir en un proyecto u

organización para implementar el proceso de software completamente. Suele involucrar
recursos, estructura organizacional y entrenamiento.

Actividades desarrolladas: Describen los roles y procedimientos necesarios para

implementar un área clave de proceso. Típicamente involucra planes y procedimientos,
realizar el trabajo, seguirlo y tomar acciones correctivas.

Medición y análisis: Describe la necesidad de medir el proceso y analizar dichas

mediciones. En general suele incluir ejemplos de las medidas que pueden ser tomadas
para determinar el nivel y efectividad de las Actividades desarrolladas.

Verificar Implementación: Describe pasos para asegurarse que las actividades son
desarrolladas en el marco del proceso que ha sido establecido. Involucra revisiones y
auditorias de la gerencia y aseguramiento de la calidad del software.

En resumen, Actividades desarrolladas describe lo que debe ser implementado para

lograr capacidad del proceso. Las demás prácticas institucionalizan las prácticas
descriptas en la primera.

Cada área clave identifica un conjunto de actividades que cuando son ejercidas en
conjunto, logran objetivos considerados importantes para incrementar la capacidad de
un proceso. Al plantearse un camino para abordar un área clave, este puede diferir de
proyecto en proyecto debido a diferencias en el entorno o en el dominio. Sin embargo,
todos los objetivos del área clave deben ser satisfechos para cumplimentar un área clave
de proceso. En esta situación se dice que la organización ha institucionalizado su
capacidad de proceso caracterizado por el área clave.

Ingenieria de Software 2006 – U.N.C.P.B.A. 15

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Clasificar a un área como clave es reconocer que dicha área es imprescindible para
lograr un determinado nivel. El CMM no describe todas las áreas involucradas en el
desarrollo y mantenimiento del software, sino solo aquellas que han sido identificadas
como determinantes de la capacidad de un proceso. Aunque otros factores afecten la
performance del proceso, estas áreas fueron identificadas debido a que realmente
mejoran la capacidad del proceso de una organización.

Las áreas clave de proceso pueden ser consideradas los requerimientos para alcanzar
un nivel de madurez. Para que esto se cumpla, las áreas claves para ese nivel (y para
niveles más bajos) deben satisfacerse y los procesos deben institucionalizarse.

Los objetivos de cada área clave deben resumirse en prácticas clave y pueden ser
usados como determinantes de cuándo una organización o proyecto ha implementado
eficientemente el área clave de proceso. Los objetivos significan la visibilidad, los
límites y la intención de cada área clave de proceso. Al adaptar las prácticas clave de un
área clave de proceso a un proyecto o situación de una organización específica los
objetivos se pueden usar para determinar si la adaptación es o no razonable. De manera
análoga, cuando se evalúan alternativas de implementación de un área clave de proceso,

Ingenieria de Software 2006 – U.N.C.P.B.A. 16

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

los objetivos pueden utilizarse para determinar si la alternativa satisface la intención del
área clave de proceso.

A continuación se describe brevemente el objetivo a cumplimentar en cada nivel,

narrando las áreas claves que son abordadas para tal fin.

Áreas claves de proceso en el Nivel 2

Objetivo: Establecer la administración y control básico del proyecto.

Administración de requerimientos: Establecer un entendimiento común entre el cliente

y los requerimientos del proyecto. Es la base para planificar y administrar el proyecto de
software. Dado que los requerimientos del cliente con frecuencia evolucionan y
cambian, documentar y controlarlos es sumamente necesario para posteriormente
usarlos como base en estimaciones, planeamiento y control de las actividades del
proyecto de software a través de todo su ciclo de vida.

Planeamiento del proyecto de software: Establecer planes razonables para realizar la

ingeniería de software y para administrar el proyecto. Se basa en desarrollar
estimaciones realistas para llevar a cabo el trabajo y establecer los compromisos
necesarios. Estos comienzan con una declaración del trabajo y las restricciones y las
metas que definen y limitan el proyecto de software. El proceso de planeación del
software incluye pasos para estimar el tamaño del software y los recursos necesarios,
para producir un cronograma, para identificar y estimar los riesgos, y para negociar los
compromisos. El plan se documenta y se mantiene como una herramienta necesaria para
administrar el proyecto de software.

Control de proyectos de software: Establecer una adecuada visibilidad del progreso real
para que la administración pueda tomar acciones correctivas cuando la performance del
proyecto se desvíe significativamente de lo planeado. La administración involucra
controlar y revisar los resultados contra el plan y tomar acciones correctivas cuando
sean necesarias, basándose en los resultados reales. Estas acciones pueden incluir:
revisar el plan de desarrollo de software para que refleje los resultados actuales,
replanificar el trabajo restante, y/o tomar acciones para mejorar la performance.

Administración de subcontratos: Seleccionar minuciosamente subcontratantes de

software y administrarlos efectivamente. Generalmente, la selección de subcontratantes
se basa en la habilidad para realizar el trabajo, aunque en ciertas ocasiones se basan
alianzas estratégicas de negocio. El trabajo realizado por el subcontratante y los planes
para el trabajo son documentados, y el principal contratista monitorea la performance de
esos planes.

Aseguramiento de la calidad del software: Proveer una administración que posea

apropiada visibilidad dentro del proceso que esta siendo utilizado por el proyecto de
software y los productos construidos. La visibilidad mencionada se alcanza revisando y
auditando los productos de software y las actividades para verificar que cumplen con los
estándares y procedimientos aplicables.

Ingenieria de Software 2006 – U.N.C.P.B.A. 17

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Administración de configuración de software: Establecer y mantener la integridad de

los productos del proyecto a través del ciclo de vida del mismo. La manera de alcanzar
esta, es identificando la configuración del software en ciertos puntos dados, controlando
sistemáticamente los cambios a la configuración, y manteniendo la integridad de la
configuración a través del ciclo de vida del software. Las líneas guía del software son
mantenidas en una librería de líneas guía a medida que se van desarrollando. Los
cambios a las líneas guía y a la versión del producto de software construido, son
sistemáticamente controladas y la configuración es auditada

Áreas claves de proceso en el Nivel 3

Objetivos: Atacar problemas del proyecto y de la organización, mientras ésta

establece una infraestructura que institucionaliza una ingeniería de software y
administración de procesos efectiva a través de todos los proyectos.

Concentración del proceso organizacional: Establecer la responsabilidad

organizacional para las actividades del proceso de software que mejoran la capacidad
del proceso de toda la organización.
Los resultados primarios de las actividades de este área clave, son un conjunto de
verificaciones de procesos de software, los cuales son descriptos en Definición de
procesos organizacionales.

Definición de procesos organizacionales: Desarrollar y mantener un conjunto de datos

de los procesos de software utilizables que mejoran la performance del proceso a través
del proyecto y proveen una base para definir datos significativos para la administración
cuantitativa de procesos. Estos datos pueden ser recolectados de muchas formas; por
ejemplo, las descripciones de los ciclos de vida de software pueden ser una parte
integral de los procesos de software estándar de la organización. La taxonomía provista
en este área clave delimita los aspectos de la definición de procesos que necesitan ser
tratados.

Programa de capacitación: Desarrollar las habilidades y el conocimiento de los

individuos para que puedan cumplir con sus roles efectiva y eficientemente.

La capacitación o entrenamiento es una responsabilidad organizacional, pero los

proyectos de software son responsables de identificar sus necesidades en cuanto a
habilidades y de proveer el entrenamiento necesario cuando las necesidades del
proyecto son únicas.

Un programa de entrenamiento comienza por identificar necesidades de entrenamiento

de la organización, del proyecto, y del individuo, para así desarrollar un entrenamiento
adecuado a las necesidades identificadas. Estas necesidades pueden ser específicas para
el proyecto o el individuo en un momento particular, pero el entrenamiento requerido
puede identificarse basándose en los roles y responsabilidades especificadas en el
proceso de software estándar de la organización. Algunas habilidades son efectiva y
eficientemente impartidas a través de vehículos informales, por ejemplo, la tutoría.

Ingenieria de Software 2006 – U.N.C.P.B.A. 18

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Otras habilidades necesitan vehículos de entrenamiento más formales, como por

ejemplo, entrenamiento en aulas.

Administración integral de software: Integrar la ingeniería de software y la

administración de actividades en un coherente, y definido proceso de software que es
adaptado al proceso de software estándar de la organización. Dicha adaptación se basa
en el entorno de negocios y las necesidades técnicas del proyecto.
Esta área clave de proceso es la evolución del planeamiento del proyecto de software y
del control del proyecto de software en el nivel 2 para tomar ventaja de la
infraestructura organizacional establecida en el nivel 3.

Ingeniería de productos de software: Llevar a cabo consistentemente un proceso

ingenieril bien definido que integre todas las actividades de ingeniería necesarias para
producir software correcto y consistente de manera efectiva y eficiente. La ingeniería de
productos de software describe las actividades técnicas del proyecto, por ejemplo,
análisis de requerimientos, diseño, codificación y prueba.
Estos procesos de ingeniería involucran documentar los productos de software y
mantener la consistencia y facilidad de seguimiento entre ellos. Esto es necesario para
asegurar una transición controlada entre las etapas del ciclo de vida del software y para
proveer productos de software de alta calidad al cliente.

Coordinación entre grupos: Establecer un medio para que el grupo de ingeniería de

software participe activamente junto con otros grupos de ingeniería de manera tal que el
proyecto satisfaga las necesidades del cliente efectiva y eficientemente.
El grupo de ingeniería de software debe trabajar pro activamente con los otros grupos de
ingeniería para determinar los requerimientos y objetivos a nivel sistema. Idealmente
esto conformaría un equipo de producto integrado o alguna forma de ingeniería
concurrente. En cualquier caso las interfaces e interacciones entre los grupos deben ser
planeadas y administradas para asegurar la calidad e integridad del sistema en su
totalidad. Todos los grupos de ingeniería deben conocer el estado y los planes de los
demás grupos, y los asuntos relativos al sistema y a los grupos deben recibir atención
apropiada.

Revisiones puntuales: Eliminar defectos de los productos de software eficientemente y

en etapas tempranas.
Un efecto importante es desarrollar un mejor entendimiento de los productos de
software y de los defectos que deben ser prevenidos. La revisión es un método de
ingeniería importante y efectivo, que se puede implementar mediante inspecciones,
revisiones estructuradas y otros métodos.

Áreas claves de proceso en el Nivel 4

Objetivo: Establecer un entendimiento cuantitativo, tanto del proceso de software

como de los productos que se construyen.

Administración cuantitativa de procesos: Controlar la performance de procesos del

proyecto de software de manera cuantitativa. La performance de procesos de software
representa los resultados reales alcanzados al seguir un proceso de software. Existirán
variaciones aleatorias (ruidos) en cualquier proceso. Con un proceso estable, la

Ingenieria de Software 2006 – U.N.C.P.B.A. 19

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

performance se encuentra generalmente dentro de intervalos conocidos. Cuando la

performance cae fuera de esos intervalos, se necesita identificar esa “causa especial” de
la variación y, de ser apropiado, corregir las circunstancias que llevaron a que ocurra esa
variación. El resultado de satisfacer esta área clave es un proceso que permanece estable
y cuantitativamente predecible.

Administración de calidad de software: Desarrollar un entendimiento cuantitativo de la

calidad de los productos de software del proyecto y alcanzar objetivos de calidad
específicos.

Los objetivos cuantitativos se establecen para los productos de software, basándose en

las necesidades de la organización, el cliente, o el usuario final. Para que estos objetivos
se alcancen, la organización establece estrategias y planes, y el proyecto ajusta
específicamente sus procesos de software definidos para alcanzar los objetivos de
calidad. La administración de calidad de software está concentrada en los productos,
mientras que la administración cuantitativa de procesos está concentrada en los
procesos.

Áreas claves de proceso en el Nivel 5

Objetivo: Cubrir los inconvenientes que las organizaciones y proyectos deben localizar
para implementar mejoras continuas y medibles de procesos de software.

Prevención de Defecto: Identificar las causas de los defectos y prevenirlos de su

reincidencia.

El proceso de software analiza los procesos, identifica sus causas y toma acciones para
prevenirlos de su reincidencia. Muchas veces esto involucra el cambio del proceso de
software definido en el proyecto. El análisis causal resultaría también en cambiar
elementos del proceso estándar de la organización para controlar las causas comunes de
la variación. La Prevención de Defectos es un mecanismo de mejora incremental del
proceso de software en una forma evolutiva.

Administración de Cambio de Tecnología: Identificar nuevas tecnologías beneficiosas

(herramientas, métodos y procesos) y transferirlas a la organización de un manera
ordenada.

Concentrarse en la transición de la tecnología implica identificar, seleccionar, y evaluar

nuevas tecnologías e incorporar aquellas que sean efectivas a la organización. El
objetivo es mejorar la calidad de software, incrementar la productividad y reducir en
tiempo de desarrollo del producto. El resultado de este foco es la innovación eficiente
en un mundo cambiante. La Administración del Cambio de Tecnología se refiere a la
mejora del proceso de software de una manera revolucionaria.

Administración del Cambio del Proceso: Mejorar continuamente el proceso de software

usado en la organización con la intensión de mejorar la calidad del software,
aumentando la productividad y reduciendo el tiempo para el desarrollo del producto.
La mejora continua del proceso incluye la definición de los objetivos de la mejora de
procesos y, con la ayuda de la cúpula administrativa, identificar proactiva y

Ingenieria de Software 2006 – U.N.C.P.B.A. 20

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

sistemáticamente, evaluando, e implementando mejoras al proceso de software estándar

de la organización y al proceso de software definido del proyecto. La Administración
del Cambio del Proceso entrega de manera apropiada cambios incrementales evolutivos,
cambios innovadores y revolucionarios.

Ingenieria de Software 2006 – U.N.C.P.B.A. 21

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Conclusión
El modelo de capacidad y madurez formaliza una aproximación a la mejora del proceso
de software. En la comunidad del Software se han investigado con gran detalle los
niveles de madurez, las áreas clave de proceso, características comunes y claves
prácticas. Aunque CMM no es perfecto, este ha logrado gran aceptación en las
organizaciones cuyas intenciones son mejorar su proceso de producción de software. Es
una herramienta útil para priorizar los esfuerzos a realizar cuando se mejore un proceso.

El CMM provee una estructura conceptual para mejorar y administrar el proceso de

desarrollo de productos de software de manera consistente. Este no garantiza que los
productos serán exitosos o cuál es la forma correcta de ingeniería. Sin embargo casos
sobre la aplicación de CMM indican que éste lleva a realizar productos que logran los
objetivos de costo, calidad y productividad. [Dion92, Humphrey91b, Lipke92,
Wohlwend93].

El CMM identifica prácticas para procesos de software maduros y provee ejemplos del
estado de la práctica pero no indica que sean exhaustivas u obligatorias. No indica
estrategias para mejora del proceso a corto plazo, existe un periodo de adaptación donde
puede replantearse si la mejora que se está llevando a cabo por el buen camino.

El volumen de documentación que es agregado a medida que se escala un nivel de

madurez es importante, lo que lleva a las organizaciones de niveles altos a pasar la
mayoría del tiempo documentando. Además, esto condiciona el tamaño de las
organizaciones para las cuales es conveniente adoptar CMM: Cuando el tamaño de la
organización lo permite, el aplicar CMM puede traer importantes beneficios en los
costos de desarrollo y en lo acertado de las estimaciones realizadas.

Ingenieria de Software 2006 – U.N.C.P.B.A. 22

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Apéndice A - Key Practices

En esta sección se explican las prácticas claves que sirven para implementar la mejora
de un proceso. Las prácticas que institucionalizan el nivel de madurez de una
organización se pueden encontrar con nivel de detalle en Key Practices of the
Capability Maturity ModelSM, Versión 1.1 de Paulk, Weber, Garcia, Crisis y Bush.[]

Como se mencionó en la sección 2, cada área clave del proceso se divide en prácticas
clave que contribuyen a cumplir con sus objetivos. Las prácticas clave describen la
infraestructura y actividades que en mayor medida contribuyen a la implementación e
institucionalización del área clave del proceso.

Estas prácticas clave, también llamadas prácticas clave de alto nivel, establecen las
políticas, procedimientos y actividades fundamentales para el área clave del proyecto.
Están compuestas por sub prácticas, que describen lo que uno esperaría encontrar
implementado para la práctica clave de alto nivel

Las prácticas clave no deben ser interpretadas por cómo se deben lograr los objetivos, si
no como qué es lo que se debe hacer. Pueden ser usadas para evaluar si los objetivos del
área clave de proceso fueron alcanzados. Su intención es proveer una descripción de los
elementos o principios esenciales de un proceso de software efectivo, los cuáles son
aplicables a una gran variedad de proyectos y organizaciones, dejando su
implementación a cada organización en particular, de acuerdo con su cultura y su
experiencia.

A continuación se describen brevemente las prácticas clave para cada área clave del
proceso de cada nivel.

Nivel 2

Administración de requerimientos

- El grupo de ingeniería de software revisa los requerimientos antes de que se

incorporen al proyecto de software.
o Se identifican los requerimientos incompletos y faltantes.
o Se revisan los requerimientos para determinar si son factibles y
apropiados, si están claramente establecidos, si son consistentes y
testeables.
o Cualquier requerimiento que parezca tener problemas es revisado con el
grupo responsable de obtener los requerimientos y se realizan los
cambios necesarios.
o Los compromisos resultantes de los requerimientos encontrados se
negocian con los grupos afectados (Por ej, grupo de diseño, grupo de
testeo, grupo de estimación, SQA, etc)

Ingenieria de Software 2006 – U.N.C.P.B.A. 23

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

- El grupo de ingeniería de software usa los requerimientos encontrados como

base para los planes, productos y actividades. Los requerimientos encontrados:
o Son administrados y controlados (hay control de versiones y de cambios)
o Son la base para el plan de desarrollo de software
o Son la base para desarrollar los requerimientos del software

- Se revisan los cambios en los requerimientos encontrados y se incorporan al

proyecto.
o Se evalúa el impacto a los compromisos existentes y se negocian los
cambios según sea apropiado
o Se identifican, evalúan, se estima el riesgo, se documentan, planean, se
comunican a los grupos afectados y se rastrean hasta ser completados los
cambios necesarios en los planes de software, productos y actividades
resultados de los cambios en los requerimientos.

Planeamiento del proyecto de software:

- El grupo de ingeniería de software participa en el equipo de propuesta de

proyecto.
o El grupo de ingeniería de software se involucra en la preparación y
emisión de la propuesta, la discusión y emisión de las aclaraciones y en
la negociación de los cambios a los compromisos que afectan al proyecto
de software.
o El grupo de ingeniería de software revisa los compromisos propuestos
para el proyecto (objetivos técnicos, solución técnica al sistema,
presupuesto, cronograma, recursos, estándares, etc).
- El planeamiento del proyecto de software se inicia en las primeras etapas, y en
paralelo con, el planeamiento general del proyecto.
- El grupo de ingeniería de software participa en el planeamiento general del
proyecto, junto con otros grupos afectados, a través de la vida del proyecto.
o El grupo de ingeniería de software revisa los planes de nivel de proyecto
- Se revisan los compromisos hechos a personas y grupos fuera de la organización
junto con la cúpula administrativa de acuerdo a un procedimiento documentado.
- Se define un ciclo de vida del software con etapas predefinidas de tamaño
manejable (cascada, espiral, etc).
- Se desarrolla el plan de desarrollo de software para el proyecto, de acuerdo a un
procedimiento documentado. Este procedimiento típicamente especifica que:
o El plan de desarrollo de software se basa en los estándares del cliente,
según sea apropiado; en los estándares del proyecto; en la declaración de
trabajo aprobada y en los requerimientos encontrados.
o Se negocian los planes para grupos relacionados con el software que
estén involucrados en las actividades del grupo de ingeniería de software
(SQA, SCM, etc.), se presupuestan los esfuerzos de soporte y se
documentan los acuerdos.
o Se hace lo mismo para la participación del grupo de ingeniería de
software en las actividades de otros grupos relacionados con el software.

Ingenieria de Software 2006 – U.N.C.P.B.A. 24

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

o El plan de desarrollo de software es revisado por el Project Manager, por

el Project Software Manager, otros Managers de software y otros grupos
afectados.
o Se administra y con trola el plan de desarrollo de software
- Se documenta el plan para el proyecto de software. Este plan cubre:
o El propósito, alcance y objetivos del proyecto de software
o La elección del ciclo de vida del software
o Identificación de los procedimientos, métodos y estándares elegidos para
desarrollar y/o mantener el software (plan de desarrollo de software,
SCM, SQA, etc.).
o Identificación de los productos de software a ser desarrollados
o Estimaciones del tamaño de los productos de software y de cualquier
cambio aplicado a ellos.
o Estimaciones de los costos y esfuerzo del proyecto.
o Uso estimado de recursos computacionales críticos.
o Cronograma del proyecto, incluyendo identificación de milestones y
revisiones.
o Identificación y evaluación de los riesgos del proyecto.
o Planes para las herramientas e instalaciones de ingeniería de software del
proyecto.
- Se identifican productos de software necesarios para establecer y mantener el
control del proyecto.
- Se derivan las estimaciones del tamaño o cambios en el tamaño de los productos
del software de acuerdo a un procedimiento documentado. Este procedimiento
típicamente especifica que:
o Se realicen estimaciones de tamaño para los mayores productos y
actividades (puntos función, líneas de código, etc.).
o Se descomponen los productos hasta la granularidad necesaria para
alcanzar los objetivos de estimación.
o Se usan datos históricos donde sea posible.
o Se documentan las suposiciones de estimación de tamaño.
o Se documentan, revisan y acuerdan las estimaciones de tamaño.
- Se derivan las estimaciones para el esfuerzo y el costo del proyecto de acuerdo a
un procedimiento documentado. Este procedimiento típicamente especifica que:
o Las estimaciones para el esfuerzo y el costo del proyecto se relacionan
con las estimaciones del tamaño de los productos (o sus cambios).
o Se usan los datos de productividad (históricos y/o actuales) cuando estén
disponibles. Las fuentes de esos datos se documentan.
o Las estimaciones de esfuerzo, personal y costos se basan en experiencia
previa.
o Se documentan, revisan y se acuerdan las estimaciones y las
suposiciones hechas al derivar las mismas.
- Se derivan las estimaciones para el uso de recursos de computación críticos del
proyecto de acuerdo a un procedimiento documentado. Este procedimiento suele
especificar que:
o Se identifican los recursos de computación críticos para el proyecto.
o Se relacionan las estimaciones para los recursos de computación críticos
con el tamaño de los productos, la carga de procesamiento operacional y
el tráfico de comunicaciones.

Ingenieria de Software 2006 – U.N.C.P.B.A. 25

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

o Se documentan, revisan y se acuerdan las estimaciones de los recursos de

computación críticos.
- Se deriva el cronograma del proyecto de acuerdo a un procedimiento
documentado. Este procedimiento suele especificar que:
o Se relaciona el cronograma con el tamaño estimado de los productos y
con el costo y el esfuerzo
o El cronograma se basa en experiencias anteriores.
o El cronograma se acomoda a las fechas impuestas para los milestones,
fechas críticas de dependencias y otras restricciones.
o Las actividades del cronograma son de duración apropiada y los
milestones tienen una separación temporal apropiada para soportar
certeza en la medición del progreso.
o Se documentan las suposiciones hechas al derivar el cronograma.
o Se documenta, revisa y acuerda el cronograma.
- Se identifican, evalúan y documentan los riesgos asociados con el costo,
recursos, cronograma y aspectos técnicos del proyecto.
o Se analizan y priorizan los riesgos en base a su impacto potencial en el
proyecto.
o Se identifican las contingencias para los riesgos.
- Se preparan los planes para las instalaciones de ingeniería y herramientas de
soporte para el proyecto
o Se basan las estimaciones de requerimientos de capacidad para esas
instalaciones y herramientas de soporte en las estimaciones de los
productos y otras características.
o Se asignan las responsabilidades y se negocian los compromisos para
obtener o desarrollar esas instalaciones y herramientas de soporte.
o Los planes son revisados por todos los grupos afectados.
- Se registran los datos del planeamiento del software
o La información registrada incluye las estimaciones y la información
necesaria para reconstruir las mismas y evaluar su coherencia.
o Los datos de planeamiento del software son administrados y controlados.

Control de proyectos de software:

- Se utiliza un plan de desarrollo de software para comunicar el estado y llevar

cuenta de las actividades.
o Se actualiza este plan a medida que el trabajo avanza para reflejar los
logros, particularmente cuando se completan los milestones.
o El plan debe estar disponible inmediatamente para el grupo de ingeniería
de software, los administradores, la cúpula administrativa y otros grupos
afectados.
- Se revisa el plan de desarrollo de software de acuerdo a un procedimiento
documentado. Este proceso normalmente especifica que:
o Se revisa el plan de desarrollo de software para incorporar refinamientos
y cambios en el plan, especialmente cuando los planes cambian de
manera significativa.
o Se actualiza el plan para incorporar todos los nuevos compromisos y
cambios a los compromisos.

Ingenieria de Software 2006 – U.N.C.P.B.A. 26

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

o Se revisa el plan de desarrollo de software en cada revisión.

o Se administra y controla el plan de desarrollo de software.
- Se revisan junto con la cúpula administrativa los compromisos del proyecto, y
cambios a los mismos hechos para individuos y grupos externos a la
organización de acuerdo a un procedimiento documentado.
- Se comunican los cambios aprobados en los compromisos que afecten al
proyecto a los miembros del grupo de ingeniería de software y a los demás
grupos relacionados
- Se lleva registro del tamaño de los productos (o cambios en el tamaño de los
mismos) y se toman acciones correctivas según sea necesario.
o Se lleva cuenta del tamaño de los mayores productos.
o Se compara el tamaño real del código (generado, completamente testeado
y entregado) con las estimaciones documentadas en el plan de desarrollo
de software.
o Se comparan las unidades reales de documentación entregadas con las
estimaciones documentadas en el plan de desarrollo de software.
o Se refina, monitorea y ajusta de forma regular el tamaño global
proyectado de los productos (estimados y reales).
o Se negocian y documentan los cambios en las estimaciones del tamaño
de los productos que afecten los compromisos realizados con los grupos
afectados.
- Se lleva cuenta del esfuerzo y costos del proyecto, y se toman acciones
correctivas según sea necesario.
o Se comparan las gastos de esfuerzo y los costos por tiempo y por trabajo
completado contra las estimaciones documentados en el plan de
desarrollo de software para identificar excesos y subestimaciones.
o Se lleva registro de los costos y se comparan contra las estimaciones
documentadas en el plan de desarrollo de software.
o Se compara el esfuerzo y el personal asignado con las estimaciones
documentadas en el plan de desarrollo de software.
o Se negocian y documentan los cambios en el personal y otros costos que
afecten los compromisos con los grupos afectados.
- Se monitorean los recursos computacionales críticos y se toman acciones
correctivas según sea necesario,
o Se monitorean y comparan el uso real y estimado de los recursos
computacionales críticos contra las estimaciones para cada componente
importante tal y como fueron documentadas en el plan de desarrollo de
software.
o Se negocian los cambios en las estimaciones de recursos
computacionales críticos con los grupos afectados y se documentan
- Se monitorea el cronograma del proyecto y se toman acciones correctivas según
sean necesarias.
o Se comparan las culminaciones de las actividades, milestones y otros
compromisos contra el plan de desarrollo de software
o Se evalúa el impacto en futuras actividades y milestones de los efectos
de culminaciones tempranas o tardías de las actividades, milestones y
otros compromisos.
o Se negocian y documentan las revisiones del cronograma que afecten los
compromisos con los grupos afectados.

Ingenieria de Software 2006 – U.N.C.P.B.A. 27

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

- Se monitorean las actividades técnicas de ingeniería de software y se toman

acciones correctivas según sean necesarias.
o Los miembros del grupo de ingeniería de software reportan regularmente
su estado técnico a su administrador inmediato.
o Se comparan los contenidos de las entregas de software para sucesivas
builds contra los planes documentados en el plan de desarrollo de
software.
o Se reportan y documentan problemas en cualquiera de los productos.
o Se monitorean los reportes de problemas hasta su cierre.
- Se monitorean los riesgos asociados con costos, recursos, cronograma y aspectos
técnicos del proyecto.
o Se ajustan las prioridades de los riegos y sus planes de contingencia
según la información que se va haciendo disponible.
o Se revisan regularmente las áreas de riesgo con el Project manager.
- Se registran los datos de mediciones reales y replaneamiento del proyecto.
o La información registrada incluye las estimaciones e información
asociada para reconstruir las estimaciones y verificar su coherencia.
o Se administra y controla la información del replaneamiento.
o Se archivan los datos de planeamiento, replaneamiento y mediciones
reales para su uso en proyectos en curso y futuros.
- El grupo de ingeniería de software conduce revisiones internas periódicas para
monitorear el progreso técnico, los planes, el desempeño y los problemas contra
el plan de desarrollo de software. Estas revisiones se conducen entre:
o Los managers inmediatos y sus líderes de tareas
o El manager de software del proyecto, los managers de software
inmediatos y otros managers de software según sea apropiado.
- Se realizan revisiones formales para verificar los cumplimientos y resultados del
proyecto en milestones seleccionados de acuerdo a un procedimiento
documentado.
o Se planean estas revisiones para que tengan lugar en puntos
significativos del cronograma del proyecto, tales como el principio o
finalización de etapas seleccionadas.
o Estas revisiones son conducidas junto con el cliente, usuario final y
grupos afectados dentro de la organización, según sea necesario.
o Las revisiones usan materiales que son revisados y aprobados por los
managers responsables.
o Las revisiones verifican los compromisos, planes y estado de las
actividades, así también como los riesgos del proyecto.
o Estas revisiones tienen como resultado la identificación y documentación
de asuntos, acciones y decisiones significativas, y también el
refinamiento del plan de desarrollo de software si es necesario.

Ingenieria de Software 2006 – U.N.C.P.B.A. 28

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Aseguramiento de la calidad del software:

- Se prepara un plan de SQA para el proyecto, de acuerdo a un procedimiento

documentado. Este procedimiento normalmente especifica que:
o El plan de SQA se desarrolla en las etapas tempranas, y en paralelo a, el
plan general del proyecto.
o Los grupos e individuos afectados revisan el plan de SQA.
o Se administra y controla el plan de SQA.
- Se realizan las actividades del grupo de SQA de acuerdo a lo establecido en el
plan. Este plan cubre:
o Responsabilidades y autoridad del grupo de SQA
o Requerimientos de recursos para el grupo de SQA (personal,
herramientas e instalaciones).
o Cronograma y fondos para las actividades del grupo de SQA durante el
proyecto.
o La participación del grupo de SQA en establecer el plan de desarrollo,
estándares y procedimientos para el proyecto.
o Las evaluaciones a ser realizadas por el grupo de SQA.
o Las auditorias y revisiones a ser realizadas por el grupo de SQA.
o Los procedimientos y estándares del proyecto a ser usados como base
para las revisiones y auditorias del grupo de SQA.
o Procedimientos para documentar y monitorear asuntos de
incompatibilidad hasta su cierre.
o La documentación que el grupo de SQA debe producir.
o Los métodos y la frecuencia en que el grupo de SQA informará de sus
actividades al grupo de ingeniería de software y otros grupos
relacionados.
- El grupo de SQA participa en la preparación y revisión del plan de desarrollo de
software, estándares y procedimientos para el proyecto.
o El grupo de SQA provee consultoría y revisiones de los planes
estándares y procedimientos con respecto a cumplimiento de la política
organizacional, de los estándares y requerimientos impuestos desde
afuera de la organización, estándares apropiados para el uso del proyecto,
tópicos que deberían ser verificados en el plan de desarrollo de software.
o El grupo de SQA verifica que los planes, estándares y procedimientos
estén en su lugar y puedan ser usados para revisar y auditar el proyecto.
- El grupo de SQA revisa las actividades de ingeniería de software para verificar
su cumplimiento.
o Se evalúan las actividades contra el plan de desarrollo de software y los
estándares y procedimientos designados.
o Se identifican, documentan y monitorean las desviaciones hasta su cierre.
o Se verifican las correcciones.
- El grupo de SQA audita los productos designados para verificar su
cumplimiento.
o Se evalúan los productos entregables antes de que sean entregados al
cliente.
o Se evalúan los productos contra los estándares, procedimientos y
requerimientos contractuales designados
o Se identifican, documentan y monitorean las desviaciones hasta su cierre.
o Se verifican las correcciones.

Ingenieria de Software 2006 – U.N.C.P.B.A. 29

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

- El grupo de SQA reporta periódicamente los resultados de sus actividades al

grupo de ingeniería de software.
- Se documentan y manejan las desviaciones identificadas en las actividades y los
productos de acuerdo a un procedimiento documentado.
o Se documentan y resuelven las desviaciones del plan de desarrollo de
software y de los estándares y procedimientos designados, junto con los
líderes de tareas, managers, o Project manager donde sea posible.
o Se documentan las desviaciones no resolubles del plan de desarrollo de
software y de los estándares y procedimientos designados y se presentan
al administrador senior designado para recibir los elementos que no
cumplan.
o Se revisan periódicamente los elementos que no cumplen presentados al
administrador senior hasta que sean resueltos.
o Se administra y controla la documentación de elementos que no
cumplen.
- El grupo de SQA conduce revisiones periódicas de sus actividades y
descubrimientos junto con el personal de SQA del cliente, según sea apropiado.

Administración de configuración de software:

- Se prepara un plan de SCM para cada proyecto de acuerdo a un procedimiento

documentado.
o El plan de SCM se desarrolla en las etapas tempranas, y en paralelo a, el
plan general del proyecto.
o Los grupos e individuos afectados revisan el plan de SCM.
o Se administra y controla el plan de SCM.
- Se usa un plan de SCM documentado y aprobado como la base para desarrollar
las actividades de SCM. Este plan cubre:
o Las actividades de SCM a ser desarrolladas, el cronograma de las
actividades, las responsabilidades asignadas y los recursos necesarios
(incluyendo personal, herramientas e instalaciones).
o Los requerimientos y actividades de SCM a ser realizadas por el grupo
de ingeniería de software y otros grupos relacionados.
- Se establece un sistema de biblioteca de administración de la configuración
como repositorio de las líneas de base del software. El sistema de biblioteca:
o Soporta múltiples niveles de control de SCM
o Proporciona el almacenado y recuperación de elementos/unidades de
configuración.
o Proporciona la compartición y transferencia de elementos/unidades de
configuración entre los grupos afectados y entre los niveles de control
dentro de la biblioteca.
o Ayuda en el uso de estándares del producto para elementos/unidades de
configuración
o Proporciona almacenado y recuperación de versiones archivadas de
elementos/unidades de configuración.
o Ayuda a asegurar la creación correcta de productos desde la biblioteca de
línea base del software.
o Proporciona almacenamiento, actualización y recuperación de registros
de SCM.

Ingenieria de Software 2006 – U.N.C.P.B.A. 30

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

o Soporta la producción de reportes de SCM.

o Proporciona mantenimiento de la estructura y contenidos de la
biblioteca.
- Se identifican los productos a ser puestos bajo administración de configuración.
o Los elementos/unidades de configuración se eligen en base a un criterio
documentado.
o Se asignan identificadores únicos a los elementos/unidades de
configuración.
o Se especifican las características de cada elementos/unidad de
configuración.
o Se especifica a qué línea base pertenece cada elemento/unidad de
configuración.
o Se especifica en qué punto de su desarrollo cada elemento/unidad de
configuración se coloca bajo administración de configuración.
o Se identifica a la persona responsable de cada elemento/unidad de
configuración.
- Se inicializan, registran, revisan, aprueban y monitorean los pedidos de cambio
y reportes de problemas para todas las unidades de configuración de acuerdo a
un procedimiento documentado.
- Se controlan los cambios en las líneas bases de acuerdo a un procedimiento
documentado. Este procedimiento normalmente especifica que:
o Se realizan revisiones y/o tests de regresión para asegurar que los
cambios no han causado ningún efecto no intencionado en la línea base.
o Sólo se admiten unidades de configuración aprobadas por el SCCB en la
biblioteca de la línea de base.
o Se sacan y vuelven a entrar las unidades de configuración de forma que
se mantenga la correctitud e integridad de la biblioteca de la línea base.
- Se crean los productos de la biblioteca de la línea de base y se controla su
release de acuerdo a un procedimiento documentado.
o El SCCB autoriza la creación de productos desde la biblioteca base.
o Los productos de la biblioteca base, tanto para uso interno como externo,
se construyen de las unidades de configuración en la biblioteca base.
- Se registra el estado de las unidades de configuración de acuerdo a un
procedimiento documentado.
o Se registran las acciones de administración de configuración con
suficiente detalle como para que el contenido y estado de cada unidad de
configuración sea conocido y las versiones anteriores puedan ser
recuperadas.
o Se mantienen el estado actual y la historia de cada unidad de
configuración.
- Se desarrollan los reportes estándar documentando las actividades del SCM y los
contenidos de la línea base, y se ponen a disposición de los grupos e individuos
afectados.
- Se conducen auditorias sobre la línea de base de acuerdo a un procedimiento
documentado. Este procedimiento suele especificar que:
o Hay preparación adecuada para la auditoria
o Se evalúa la integridad de las líneas de base
o Se revisan la estructura e instalaciones del sistema de biblioteca de
administración de configuración

Ingenieria de Software 2006 – U.N.C.P.B.A. 31

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

o Se verifica la completitud y correctitud de los contenidos de la biblioteca

base.
o Se verifica el cumplimiento de los estándares de SCM aplicables.
o Se reportan los resultados de la auditoria al Project manager.
o Las acciones de la auditoria se monitorean hasta su cierre.

Nivel 3
Concentración del proceso organizacional:

- Se evalúa periódicamente el proceso y se desarrollan planes de acción para hacer

frente a los descubrimientos
- La organización desarrolla y mantiene un plan para sus actividades de desarrollo
y mejoras del proceso. Este plan:
o Usa los planes de acción de la evaluación del proceso y otras iniciativas
de mejoramiento de la organización como entrada principal.
o Define las actividades que serán realizadas y el cronograma para estas
actividades.
o Especifica los grupos e individuos responsables de estas actividades.
o Identifica los recursos necesarios, incluyendo personal y herramientas.
o Realiza peer reviews la primera vez que se produce, y cuando se realizan
revisiones importantes.
o Es revisado y acordado por los managers y la cúpula administrativa de la
organización.
- Se coordinan a nivel organizacional las actividades de la organización y del
proyecto para mejorar sus procesos.
- Se coordina el uso de la base de datos del proceso de la organización a nivel
organizacional.
- Nuevos procesos, métodos y herramientas de uso limitado en la organización se
monitorean, evalúan y, donde es apropiado, son transferidos a otras partes de la
organización.
- Se coordina el entrenamiento para los procesos de la organización y de los
proyectos a lo largo de la organización.
o Se preparan los planes de entrenamiento en materias relacionadas con los
procesos de los proyectos y de la organización.
o El grupo responsable de las actividades del proceso de la organización
puede preparar y realizar el entrenamiento si es apropiado.
- Se informa a los grupos involucrados en implementar los procesos sobre las
actividades de la organización y de los proyectos para el desarrollo y mejora del
proceso.

Definición de procesos organizacionales:

Ingenieria de Software 2006 – U.N.C.P.B.A. 32

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

- Se desarrolla y mantiene el proceso estándar de la organización de acuerdo a un

procedimiento documentado. Este proceso normalmente especifica que:
o El proceso estándar de la organización satisface las políticas, estándares
de proceso y de producto impuestos en la organización
o El proceso estándar de la organización satisface los procesos y productos
estándar normalmente impuestos a los proyectos de la organización por
sus clientes.
o Se incorporan herramientas y métodos de ingeniería de software de
vanguardia al proceso estándar de la organización según sea apropiado.
o Se describen las interfaces internas del proceso entre las distintas
disciplinas.
o Se describen las interfaces externas entre el proceso y los procesos de
otros grupos afectados.
o El grupo responsable de las actividades del proceso de software de la
organización documenta, revisa y aprueba los cambios propuestos al
proceso estándar de la organización.
o Se definen los planes para introducir cambios a los procesos de los
proyectos en curso según sea apropiado.
o Se realizan peer reviews a la descripción del proceso estándar de la
organización la primera vez que se desarrolla y cuando se le realizan
cambios o agregados importantes.
o Se coloca la descripción del proceso estándar de la organización bajo
administración de la configuración.
- Se documenta el proceso estándar de la organización de acuerdo a los estándares
establecidos en la organización.
o Se descompone el proceso en sus elementos constituyentes hasta la
granularidad necesaria para entender y describir el proceso.
o Se describe cada elemento en función de los procedimientos, prácticas,
métodos y tecnologías necesarios; los estándares aplicables, las entradas,
los productos producidos, etc.
- Se documentan y mantienen las descripciones de los ciclos de vida aprobadas
para el uso del proyecto.
o Los ciclos de vida son compatibles con el proceso estándar de la
organización.
o El grupo responsable de las actividades del proceso de la organización
documenta, revisa y aprueba los cambios propuestos para las
descripciones de los ciclos de vida, antes de que sean incorporadas.
o Se someten a peer reviews las descripciones de los ciclos de vida cuando
son desarrolladas inicialmente y cuando se realizan cambios importantes
a las mismas.
o Se administran y controlan las descripciones de los ciclos de vida.
- Se desarrollan y mantienen las guías y el criterio para el ajuste del estándar de la
organización para un proyecto.
o Estas cubren las guías y el criterio para seleccionar y ajustar el ciclo de
vida para el proyecto, ajustar el proceso estándar de la organización para
contener el ciclo de vida y las características del proyecto, y estándares
para documentar el proceso definido para el proyecto.
o El grupo responsable de las actividades del proceso de la organización
documenta, revisa y aprueba los cambios propuestos a las guías y
criterios de ajuste.

Ingenieria de Software 2006 – U.N.C.P.B.A. 33

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

o Se administran y controlan las guías y criterios de ajuste.

- Se establece y mantiene la base de datos del proceso de la organización
o Se establece la base de datos para obtener y disponer de los datos del
proceso y productos resultantes.
o Se revisa la integridad del contenido de la base de datos y se revisan los
datos ingresados a la misma.
o Se administra y controla la base de datos.
o Se controla el acceso a la base de datos para asegurar la veracidad,
integridad y completitud de los datos.
o
- Se establece y mantiene una biblioteca de documentación relacionada con el
proceso.
o Se revisan los elementos candidatos y los que pueden llegar a ser útiles
en el futuro se agregan a la biblioteca.
o Se catalogan los elementos de documentación para facilitar su acceso.
o Se revisan las revisiones hechas a los elementos que se encuentran en la
biblioteca y los contenidos de la misma se actualizan según sea
apropiado.
o Se ponen los contenidos de la biblioteca a disposición de los proyectos y
otros grupos relacionados.
o Se revisa periódicamente el uso de cada elemento y los resultados se
utilizan para mantener los contenidos de la biblioteca.
o Se administran y controlan los contenidos de la biblioteca.

Programa de capacitación:

- Cada proyecto desarrolla y mantiene un plan de capacitación que especifica sus

necesidades de entrenamiento. Este plan cubre:
o Las habilidades necesarias y cuándo son necesarias.
o Las habilidades para les cuales se requiere capacitación y las que se
conseguirán por otros medios.
o El entrenamiento necesario, para quiénes es necesario y cuando se
necesita.
o Cómo se dará el entrenamiento.
- Se revisa y desarrolla el plan de capacitación de la organización de acuerdo a un
procedimiento documentado.
o El plan usa las necesidades de entrenamiento de los proyectos
identificadas en sus planes de capacitación
o Se identifica el entrenamiento específico que será provisto en base a las
habilidades que necesita la organización y cuándo se necesitan esos
conocimientos.
o Se revisa el plan de capacitación de la organización, según sea
apropiado, para incorporar cambios.
o Los individuos afectados revisan el plan de capacitación de la
organización cuando se produce por primera vez, y cuando se realizan
revisiones importantes.
o Se administra y controla el plan de entrenamiento de la organización.

Ingenieria de Software 2006 – U.N.C.P.B.A. 34

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

o Se pone el plan de entrenamiento de la organización a disposición de los

grupos e individuos afectados.
- Se realiza la capacitación de la organización de acuerdo con el plan de
capacitación de la misma. El plan cubre:
o El entrenamiento específico necesario dentro de la organización y
cuándo es necesario.
o El entrenamiento que será obtenido de fuentes externas y el que proveerá
el grupo de entrenamiento.
o Los fondos y recursos necesarios para preparar y llevar a cabo el
entrenamiento (incluyendo personal, herramientas e instalaciones).
o Los estándares para los materiales de instrucción usados en los cursos de
entrenamiento desarrollados por el grupo de entrenamiento.
o El cronograma para desarrollar y revisar los cursos de entrenamiento a
ser desarrollados.
o El cronograma para realizar la capacitación, basado en las fechas
necesarias y en el número de estudiantes esperado.
o Los procedimientos para seleccionar las personas que recibirán
entrenamiento, para registrarse y participar en las capacitaciones, para
llevar registros de las capacitaciones dadas y para recolectar, revisar y
usar las evaluaciones.
- Se desarrollan y mantienen los cursos de capacitación preparados a nivel
organizacional de acuerdo a los estándares organizacionales.
o Se desarrolla una descripción de cada curso.
o Se revisan los materiales para los cursos.
o Se administran y controlan los materiales para cada curso.
- Se establece y utiliza un procedimiento para el entrenamiento necesario, para
determinar si los individuos ya tienen los conocimientos y habilidades
necesarios para desarrollar sus roles asignados.
o Se mantienen registros de todos los estudiantes que completan
exitosamente cada curso u otra actividad de entrenamiento.
o Se mantienen registros de todos los estudiantes que completan
exitosamente sus capacitaciones necesarias asignadas.
o Los registros de entrenamientos completados se ponen a disposición del
personal y de los administradores para su consideración en las
designaciones.

Administración integral de software:

- Se desarrolla el proceso definido para el proyecto, ajustando el proceso estándar

de la organización de acuerdo a un procedimiento documentado.
o Se elije un ciclo de vida de todos los aprobados por la organización, se
modifica, si es necesario, de formas permitidas por las guías de ajuste de
la organización, y se documenta de acuerdo a los estándares de la
organización.
o Se documenta la descripción del proceso definido para el proyecto.
o El grupo responsable de coordinar las actividades del proceso de la
organización revisa el ajuste del proceso estándar de la organización para
el proyecto, y la cúpula administrativa lo aprueba.

Ingenieria de Software 2006 – U.N.C.P.B.A. 35

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

o Se documentan las renuncias para desviaciones contractuales de los

requerimientos del proceso, y la cúpula administrativa y el cliente las
revisan y aprueban.
o Se administra y controla la descripción del proceso definido para el
proyecto.
- Se revisa el proceso definido de cada proyecto de acuerdo a un procedimiento
documentado.
o Se revisan y documentan sistemáticamente los cambios derivados de las
lecciones obtenidas por monitorear las actividades de los proyectos de la
organización; de los cambios propuestos por el proyecto y por los datos
de mediciones al proceso y los productos.
o Los cambios al proceso definido para el proyecto son revisados y
aprobados antes de ser incorporados.
- Se desarrolla y mantiene el plan de desarrollo de software del proyecto, el cual
describe el uso del proceso definido para el proyecto, de acuerdo a un
procedimiento documentado.

Coordinación entre grupos:

- El grupo de ingeniería de software y los otros grupos de ingeniería participan

junto con el cliente y los usuarios finales para establecer los requerimientos del
sistema.
o Definen las características criticas del los requerimientos del cliente y de
los usuarios finales.
o Se negocian las dependencias críticas.
o Se documenta el criterio de aceptación para cada producto entregado al
usuario final o al cliente.
- Representantes del grupo de ingeniería de software del proyecto trabajan con
representantes de los otros grupos de ingeniería para monitorear y coordinar las
actividades técnicas y resolver asuntos técnicos.
o Los representantes de estos grupos monitorean y coordinan las
actividades técnicas coordinando la especificación y realizando
revisiones y aprobaciones de los requerimientos y diseño del sistema,
proveyendo el análisis y la revisión técnica necesarios para administrar y
controlar cambios en los requerimientos del sistema y objetivos del
proyecto a través del ciclo de vida del mismo.
o Los representantes de los grupos se encargan de los asuntos técnicos
resolviendo conflictos a nivel del proyecto y clarificando los
requerimientos y problemas de diseño.
- Se utiliza un plan documentado para comunicar los compromisos entre grupos y
para coordinar y monitorear el trabajo realizado.
o Este plan es la base para el cronograma del proyecto, los aspectos
técnicos y contractuales del proyecto y para la asignación de
responsabilidades a los grupos de ingeniería.
o También se usa para coordinar las actividades entre distintos grupos de
ingeniería.
o El plan se pone a disposición de los miembros de todos los grupos de
ingeniería.

Ingenieria de Software 2006 – U.N.C.P.B.A. 36

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

o El plan se actualiza para incorporar los compromisos intergrupos y los

cambios a esos compromisos.

Peer reviews

- Se planean las peer reviews y se documentan los planes. Estos planes:

o Identifican los productos que serán sometidos a peer review, entre ellos
los identificados en el proceso estándar de la organización.
o Especifica el cronograma de las peer reviews.
- Se realizan las peer reviews de acuerdo a un procedimiento documentado.
o Se planean las peer reviews y son dirigidas por líderes entrenados de
peer review.
o Se entrega con anticipación el material de revisión a los peer reviewers
para que puedan prepararse adecuadamente.
o Se les asignan los roles a los revisores.
o Se especifica y sostiene el criterio de finalización de las peer reviews.
o Se usan listas de verificación para identificar de manera consistente el
criterio para la revisión de los productos.
o Se monitorean las acciones identificadas en las peer reviews hasta que
son resueltas.
o Se usa como criterio de finalización la finalización exitosa de las peer
reviews, incluyendo el trabajo a rehacer para encargarse de los elementos
identificados en las mismas.
- Se guardan los datos sobre la realización y resultados de las peer reviews.

Nivel 4
Administración Cuantitativa de Procesos
Actividad 1:
El plan del proyecto de software para la administración de proceso cuantitativo
es desarrollado de a cuerdo al procedimiento documentado.
Este procedimiento generalmente especifica el siguiente:
• El plan de administración de proceso esta basado en :
• Los objetivos estratégicos de la organización para la calidad del
producto, productividad, y tiempo del ciclo de desarrollo del producto.
• Los programas de medición de la organización.
• Los procesos de software estándares de la organización.
• Las mediciones de desempeño de los procesos de software de otros
proyectos.
1. La descripción de los procesos de software definidos de otros
procesos.
• El plan experimenta peer review.
• El plan es revisado por un grupo responsable para las actividades de
procesos de software de la organización.
• El plan es administrado y controlado. Esto implica que la versión del
producto en uso durante un tiempo dado es conocida (la versión de
Ingenieria de Software 2006 – U.N.C.P.B.A. 37
Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

control) y los cambios que son incorporados se hacen de manera

controlada (i.e. Control de cambios).
Actividad 2:
Las actividades de administración de procesos cuantitativos del proyecto de
software son desempeñadas de acuerdo con el plan de administración de proceso de
calidad del proyecto.
El plan cubre:
• Las metas y los objetivos de las actividades de administración de los
procesos cuantitativos.
• Las tareas u otras actividades de software que serán medidas y
analizadas.
• La instrumentación del proceso de software definido del proyecto. Esta
basada en el programa de medición, descripción del proceso de software
estándar y descripción de los procesos de software definidos de la
organización.
• Las actividades de administración de procesos cuantitativos a ser
ejecutadas y el cronograma para estas actividades.
• Los grupos e individuos responsables para las actividades de
administración de procesos cuantitativos.
• Los recursos requeridos para ejecutar las actividades de administración
de procesos cuantitativos, incluyendo al staff y herramientas.
• El procedimiento seguido para ejecutar las actividades.

Actividad 3:
Las estrategias para la recolección de datos y el análisis cuantitativo son
ejecutadas y determinadas en base al proceso de software definido del proyecto.
Los atributos del proceso de software definido del proyecto que son considerado
incluyen aquellas que e son consideradas importantes:
• Las tareas, actividades y sus relaciones con cada uno de los otros
• Los productos y sus relaciones con cada uno de los otros y con el proceso de
software definido del proyecto Los puntos de control de proceso y
recolección de datos.

Actividad 4
Los datos de medición usados para el control cuantitativo de procesos de
software definidos del proyecto. Estos son recolectados de a cuerdo al procedimiento
documentado.
Este procedimiento generalmente especifica:
• Los datos de medición colectados apoyan a las metas y objetivos de mediciones
de la organización y el proyecto
o Los datos de medición específicos son recolectados, sus definiciones de
precisión, uso intencional y análisis de cada medida, y los puntos de
control de proceso con el cual serán recolectados son definidos.
Ejemplos de datos medidos incluye:
• Estimado/planeado versus los datos existentes sobre costo, tamaño de
software y cronograma.
• Datos producidos.
• Medidas cualitativas como definido en el plan de calidad de software.
• Efectividad de capacitación.
• Alcance y eficiencia de prueba.

Ingenieria de Software 2006 – U.N.C.P.B.A. 38

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

• Mediciones de confiabilidad de software.

• Número y gravedad de defectos encontrados en el código de software.
• Número y tasa de clausura de ítems de acción.
• Las mediciones se elige desde el ciclo completo de vida de software (ej. Etapas
de desarrollo y post desarrollo).
o Las mediciones cubren las propiedades principales actividades de
procesos de software y productos de trabajos de software principales.
o Los datos medidos que están relacionados con el proceso de software de
la organización son uniformemente recolectados a lo largo del proyecto
de software.
o Las medidas son seleccionadas para dar soporte a las actividades de
análisis predefinido. En algunos casos, las medidas pueden ser
orientadas a la investigación y deben ser diseñadas explísitamente como
tal.
o La validación de los datos medidos son independientemente evaluados.
o Los datos medidos recolectados son almacenados en la base de datos de
proceso de software de la organización como propios.
Actividad 5:
El proceso de software definido del proyecto es analizado y sometido a un
control de calidad de acuerdo con el procedimiento documentado.
Este procedimiento especifica:
v La actividad de análisis de datos específica es predefinida. La descripción de
las mismas cubre:
• requerimientos de datos de entrada.
• Herramientas usadas.
• Ejecución de manipulación de datos.
• Información a ser derivada.
• Criterios de decisión usados en el análisis y que acciones tomar como
resultado del análisis.
Ejemplos de estas técnicas de análisis son:
• Diagramas de paretto.
• Cuadros de control.
• Diagramas de tendencias.
• Diagrama de dispersión.
• Datos de medición sobre las actividades del proceso a trabes de los procesos de
software definidos del proyecto son recolectados, identificados y analizados.
• Las medidas seleccionadas apropiadamente chárrate san el proceso que
representa.
• Los valores esperados para la media y la varianza son especificados para cada
medida.
• Los limites aceptables para cada medida son definidos y la línea base del
desempeño del proceso del proyecto es establecida. Un ejemplo de
establecimiento de límites aceptables es calcular la desviación histórica
proveniente del promedio de desempeño del proceso.
• Los valores actuales de cada medición es comparado con los valores esperados
de la media y la varianza. Un ejemplo de comparación incluye:
• Compara la cantidad de horas de peer review consumidas por las
miles de líneas de código fuente con los límites superiores e inferiores
determinados en el análisis histórico.
• Comparar el coeficiente de expansión de requerimientos de software

Ingenieria de Software 2006 – U.N.C.P.B.A. 39

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

dentro de el numero de líneas del código fuente con los limites

superiores e inferiores determinados en el análisis histórico.
• Ajustes son hechos para traer el desempeño del proceso actual en líneas con
limites aceptables definidos es apropiado.
• Cuando el proceso de software definido de un proyecto es controlado
cuantitativamente, la línea base es establecida para:
o La definición de medidas.
o Los datos medidos actualmente.
o Los limites aceptables para las mediciones.
• La línea base de desempeño del proceso para el proyecto de software es
administrada y controlada.

Actividad 6:
Reportes que documentan los resultados de las actividades de administración del
proceso cuantitativo proyecto de software son preparados y distribuidos.
• El resultado del análisis de datos es revisado con quienes influyen sobre los
datos antes de que sean informados a cualquier otro.
• Los software manager, lideres de tareas y la cúpula administrativa reciben
reportes regulares apropiados para sus necesidades.
• El grupo de control de calidad también recibe el informe regular apropiado para
sus necesidades.
• El manager del proyecto, cúpula administrativa, managers y líderes de tareas
reciben reportes especializados sobre sus requerimientos.

Actividad 7:
La línea base de capacidad de proceso para el proceso de software estándar de la
organización es establecido y mantenido de acuerdo al procedimiento documentado.
Este procedimiento especifica que:
o Los datos del proceso de software del proyecto, el cual es resumido en la
su línea base ejecutada en el proceso, es registrado en la base de datos de
procesos de software de la organización.
o La línea base de desempeño de proceso para cada proceso de software
definido del proyecto es incorporado, como propia, dentro de la línea
base de capacidad de proceso para el proceso de software estándar de la
organización.
o La línea base de la capacidad para el proceso de software estándar de la
organización es documentada.
o Tendencias de capacidad de proceso son examinadas para predecir
problemas probables u oportunos para solucionarlos. Ejemplos de
tendencias de capacidades usadas incluye:
• Predicción de ocurrencias de defectos de software comparadas con las
predicciones existentes.
• Predecir la distribución y características de los defectos de los
productos basado en los datos provenientes de las peer reviews o de
los tests.
Ejemplos de áreas que son una fuente de defectos probables incluye:
• Ítems para estimaciones y planeamiento.
• Actividades ejecutadas antes del ciclo de vida del software como el
análisis de requerimientos.
• Principales ítems de documentación

Ingenieria de Software 2006 – U.N.C.P.B.A. 40

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

• Actividades e ítems que tendieron a dar defectos en el pasado.

• Actividades para la implementación de cambios y defectos reparados.
• Actividades de intensiva labor.
Ejemplos de áreas que probablemente deban ser mejoradas incluye

• Actividades que en otros proyectos y organizaciones han sido

exitosamente automatizadas.
• Ítems y actividades no deliberativas y de soporte como capacitación y
herramientas.
• Actividades orientadas a la calidad como peer reviews y testeos .
• Actividades de labor intensiva.
• La línea base de capacidad para el proceso de software estándar de la
organización es administrado y controlado.
• Cuando un proyecto de software es considerablemente distinto a los proyectos
anteriores, es emprendido, una nueva línea base de desempeño de proceso es
establecida para ese proyecto como parte de ajustamiento del proceso de
software estándar de la organización(
• Algunos ejemplos de diferencias considerables de proyectos se encuentran en
nuevos dominios de aplicación, uso de tecnologías muy diferentes y cambios
significativos en el tamaño de la aplicación.
• Cambios en el proceso estándar de la organización es seguido y analizado para
evaluar los efectos en la capacidad del proceso.

Administración de Calidad de Software:

- Desarrollo y mantenimiento del plan del proyecto de software de calidad.

o Se desarrolla un entendimiento común de los requerimientos de calidad

de producto final y los usuarios.
o La calidad del software hace necesario priorizar y asignar los objetivos
que requieren la organización, el cliente y el usuario final.
o Se verifican y documentan las capacidades de los proyectos de software
definidos para satisfacer los objetivos de calidad.
o El plan de calidad de software debe satisfacer los planes de calidad de la
organización.
o Se basa el plan de calidad del software en planes previos o en proyectos
actuales de la organización.
o El plan de calidad de software es actualizado al principio del proyecto,
en los milestones mas importantes, y cuando se producen cambios
importantes de requerimientos.
o Se ejecutan peer reviews para el plan de calidad de software.
o Se revisa el plan de calidad de software por grupo.
o La cúpula administrativa revisa el plan de calidad.
o Se administra y controla el plan de calidad.
o El plan de calidad del software esta disponible para todos los grupos
afectados.

- Las actividades de la administración de calidad del software, se basan en el

plan de calidad del proyecto.

Ingenieria de Software 2006 – U.N.C.P.B.A. 41

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Lo que incluye:
o Los puntos en que la calidad de software se mide.
o Los objetivos de alto nivel para los productos de software.
o Las acciones que el proyecto de software implementara para mejorar la
performance de la calidad anterior.
o Las actividades para medir la calidad de los productos de software.
o Los objetivos de calidad para los productos.
o Las acciones a tomar cuando la calidad del producto de software no
cumplan los objetivos de calidad.

- Se definen, monitorea y controlan los objetivos cuantitativos de calidad del

proyecto para los productos de software a lo largo del ciclo de vida del
proyecto.

Lo que define:
o Las características de los productos de calidad a desarrollar y mantener.
o Las métricas para medir esas características.
o Por cada una de estas características, objetivos de calidad para los productos.
o Los objetivos de calidad para los productos de software en el plan de calidad
del proyecto.
o Los objetivos de calidad para cada etapa del ciclo de vida. Y se documentan. En
un paso posterior, se revisan los productos y etapas del ciclo de vida según
evoluciona el entendimiento sobre las necesidades de los usuarios finales, de los
clientes y de la organización.
- Se mide, analiza y compara la calidad de los productos del proyecto con los objetivos
cuantitativos de calidad de estos.
o Se planean las tareas de software para hacer frente a los objetivos de calidad del
proyecto. Entre las actividades que realiza el equipo se encuentran:
ƒ Revisiones de los objetivos de calidad para el producto.
ƒ Determinar si son aplicables estos objetivos.
ƒ Identificar su plan para adquirirlos.
ƒ Considerar cambios hechos en el proceso para obtener los objetivos de
calidad.
o Se mide la calidad de los productos para cada etapa del ciclo de vida.
o Se analizan y comparan las medidas de calidad con los objetivos, para
determinar si se satisficieron.
o Cuando un objetivo no puede se puede satisfacer sin comprometer a otro
objetivo, se toman acciones para resolver este conflicto:
ƒ Se analiza el costo que esto implica.
ƒ Se establecen objetivos de calidad alternativos y se analizan.
ƒ Se consulta a los clientes y usuarios finales.
ƒ Se planean y revisan los productos de software.

- Se les asigna a los subcontratistas objetivos cuantitativos de calidad.

Ingenieria de Software 2006 – U.N.C.P.B.A. 42

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Nivel 5
Prevención de Defectos:

ƒ El proyecto de software desarrolla y mantiene un plan por sus defectos:

ƒ Identificar actividades de prevención de defectos que puedan aparecer.
ƒ Especificar planificación de actividades de prevención
ƒ Cubrir las responsabilidades asignadas y recursos requeridos, incluyendo
el Staff y herramientas.
ƒ Revisión por pares

ƒ Al comienzo de una tarea, los miembros del equipo preparan actividades de la

tarea y las actividades para prevención de defectos relacionadas.

ƒ El proceso cubre
ƒ El proceso de software, estándares, procedimientos, métodos, y
herramientas aplicables a la tarea, con énfasis en cambios recientes.
Estos pueden se r implementados como experimentación de una
reunión de análisis.
ƒ Las entradas requeridas y disponibles para la tarea.
ƒ La salidas a ser producidas con ejemplos, si existen.
ƒ Los métodos a ser usados para evaluar las salidas.
ƒ Los métodos para verificar la adherencia al proceso.
ƒ Una lista de errores que son comúnmente cometidos e introducidos
durante la etapa actual y prevenciones preventivas para esos errores,

ƒ Las asignaciones del equipo.

ƒ Los objetivos de calidad del producto de software para las tareas del
proyecto de software.

ƒ Se realizan reuniones para analizar causas conducidas por el

procedimiento documentado típicamente específica:

ƒ Cada equipo que realiza una tarea de software conduce dirige reuniones
de análisis causal.
ƒ Una reunión de análisis de causas es conducida luego que se
complete la tarea.
ƒ Una reunión de análisis de causas es conducida siempre y cuando el
número de defectos encubiertos garantice reuniones adicionales.
ƒ Reuniones periódicas son conducidas luego que el producto de
software es entregado al cliente.
ƒ Se realizan reuniones de prevención de defectos durante la
realización del proceso. Una tarea de larga duración es el nivel de
esfuerzo de la tarea de soporte al cliente.

ƒ Las reuniones son encabezadas por una persona entrenada en dirigir este tipo
de reuniones.
ƒ Los defectos son detectados y se analizan la causa de raíz.
ƒ Los defectos son categorizados según su causa.

Ingenieria de Software 2006 – U.N.C.P.B.A. 43

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

ƒ Las acciones propuestas para prevenir la ocurrencia futura de defectos

identificados y similares son desarrolladas y documentadas.
ƒ Causas comunes de defectos son identificadas y documentadas.
ƒ Los resultados de los encuentros son grabados para ser usados por la
organización y en otros proyectos.

ƒ Cada uno de los equipos asignados para coordinar actividades de la prevención

de defectos se reúnen periódicamente para revisar y coordinar implementación
de propuestas de acciones desde el análisis causal

Los equipos deben:

ƒ Revisar la salida del análisis causal y seleccionar una acción propuesta
ƒ Revisar propuesta de acciones que les han sido asignadas por otros equipos
coordinando las actividades de prevención de defectos en la organización.
ƒ Revisar acciones tomadas por otros equipos en la organización para
asegurarse que tanto las acciones pueden ser aplicadas en sus actividades y
procesos.
ƒ Realizar un análisis preliminar de las propuestas de acción y asignarles
prioridades.

ƒ Reasignar propuestas de acciones a equipo en otro nivel en la organización.

ƒ Documentar las razones de las decisiones y proveer las razones quienes
enviaron las propuestas.
ƒ Asignar responsabilidad para implementar los ítems de acción resultantes de
las acciones propuestas.

o Implementación de los ítems de acción incluye realizar cambios

inmediatos a la actividad.
o Los miembros del equipo usualmente implementan los ítems de
acción, pero, en algunos casos, el equipo puede delegar la
implementación.

ƒ Se revisan los resultados de la experimentación de prevención de defectos y

se toman acciones para incorporar los resultados de los experimentos
exitosos, en el resto del proyecto o proceso.

ƒ Mantener el rastro del estado de las acciones propuestas y los ítems de

acción.
ƒ Documentar las mejoras del proceso de software para el proceso de software
estándar de la organización y el proyecto definido.

ƒ Revisar y verificar ítems de acción completados antes que sean cerrados.

ƒ Asegurarse que los esfuerzos significantes y éxitos en la prevención de
defectos son reconocidos.

ƒ Los datos de prevención de defectos son documentados y seguidos a por los

equipos coordinando actividades para prevención de defectos.
ƒ Propuestas de acción identificadas en las reuniones de análisis causal son
documentadas.
ƒ Ítems de acción resultantes de una propuesta de acción son documentados.

Ingenieria de Software 2006 – U.N.C.P.B.A. 44

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

ƒ Los datos de prevención de defectos son administrados y controlados.

ƒ Las revisiones a los estándares del proceso de la organización resultantes de las
acciones de prevención de defectos son incorporadas acorde a un procedimiento
documentado.

ƒ Revisiones al proceso de software resultante para ese proyecto resultante de la

acciones de prevención de defectos son incorporadas de acuerdo con un
procedimiento documentado

ƒ Miembros del grupo de ingeniería de Software y los grupos relacionados con el

software reciben un feedback sobre el estado y los resultados de las actividades
de prevención de defectos. El feedback provee:
ƒ Un resumen de las categorías más importantes de defectos.
ƒ La distribución de frecuencias de los defectos de mayor importancia.
ƒ Las innovaciones significantes y acciones tomadas para los defectos
principales
ƒ Un resumen del estado de las acciones propuestas y los ítems de acción.

Administración de Cambios tecnológicos

ƒ La organización desarrolla y mantiene un plan de administración de cambios
tecnológicos.
Este plan:
ƒ Cubre las responsabilidades asignadas y los recursos requeridos, incluyendo
staff y herramientas
ƒ Define una estrategia técnica a largo plazo para automatizar y mejorar los
estándares de la organización para realzar la posición de la organización en
el mercado.
ƒ Identifica los procedimientos a ser seguidos en realizar las actividades de
administración de los cambios tecnológicos.
ƒ Describe la aproximación de introducir nuevas tecnologías para satisfacer
necesidades específicas de la organización y proyectos.
ƒ Áreas de proceso son áreas potenciales para que los cambios
tecnológicos sean identificados
ƒ Aproximaciones para identificar oportunidades para cambios
tecnológicos son identificadas.
ƒ Se especifican determinadas tecnologías planeadas o candidatas.
ƒ Donde sea apropiado, se estima el tiempo de vida de la tecnología desde
la introducción hasta su reemplazo.
ƒ Los estudios del tradeoff de fabricar o comprar la tecnología es
documentado.
ƒ Las aproximaciones por tecnologías que o han sido aprobadas son
definidas.
ƒ La adquisición e instalación de procedimientos es definida.
ƒ El entrenamiento inicial, continuo y soporte es definido.

Ejecución de Peer Reviews

Ingenieria de Software 2006 – U.N.C.P.B.A. 45

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

ƒ El grupo responsable de administrar actividades de cambios tecnológicos

trabajan con los proyectos de software identificando las áreas de proceso en las
que cambia la tecnología.
Este grupo:
ƒ Solicita sugerencias sobre cambios tecnológicos. Identifica nuevas
tecnologías disponibles que pueden ser apropiadas para la organización
y las necesidades de proyecto.
ƒ Una búsqueda periódica es realizada para identificar tecnologías
comerciales disponibles que cumplen con las necesidades identificadas y
anticipadas.
ƒ Sistemáticamente se hacen esfuerzos para mantenerse alerta a trabajos
relevantes y tendencias tecnológicas.
ƒ Sistemáticamente se hacen esfuerzos para revisar las tecnologías usadas
externamente y compararlas con las usadas por la organización.
ƒ Se identifican áreas donde nuevas tecnologías han sido usadas con éxito
y los datos y documentación de experiencias de usarla, son recolectados
y analizados.

ƒ Evalúa nuevas tecnologías para determinar su aplicabilidad en la necesidad actual

y futuras en el proyecto.

ƒ Administradores de Software y el staff técnico se lo mantiene informado de

nuevas tecnologías
ƒ Información sobre nuevas tecnologías es consultada.
ƒ Información sobre tecnologías en uso por parte de la organización, es
consultada.
ƒ Información sobre el estado de la tecnología siendo transferida es
consultada.

ƒ El grupo responsable de los cambios tecnológicos de la organización

sistemáticamente analiza el estándar de la organización para identificar las áreas
donde se podría necesitar o podría ser beneficioso el uso de nueva tecnología. Este
grupo:

ƒ Analiza el estándar de la organización para determinar áreas donde nueva

tecnología podría ser beneficiosa.
ƒ Identifica cambios tecnológicos útiles y determina la economía de esos
cambios.
ƒ Define la relación que tienen la tecnología identificada con el estándar de
la organización.

ƒ Define las ventajas del cambio cualitativamente y cuantitativamente.

ƒ Determina la necesitad de guiar cada cambio potencial de tecnología.
ƒ Determina la prioridad de cada nueva tecnología candidata.
ƒ Documenta resultados de actividades de análisis.

Ingenieria de Software 2006 – U.N.C.P.B.A. 46

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

ƒ Las tecnologías son seleccionadas para la organización y los proyectos de software

de acuerdo a un procedimiento documentado. Este procedimiento típicamente
especifica que:
ƒ Pedidos para la adquisición de nuevas tecnologías están documentados.
ƒ Se requiere la aprobación de la gerencia con costos sobre el nivel
predefinido.

ƒ Un análisis preliminar de costo/beneficio es llevado a cabo para

potenciales cambios tecnológicos.
ƒ El criterio de selección predefinido y aprobado es usado para identificar
el beneficio potencial más alto.
ƒ Requerimientos y planes para el cambio tecnológico es definido y
documentado.
ƒ Se estiman (cuando sea práctico) la vida y los planes para
reemplazo/actualización.
ƒ Donde sea apropiado, se realiza un estudio del tradeoff, se revisa
y se documenta tanto si la tecnología debe ser desarrollada
internamente o contratada externamente.
ƒ Donde sea apropiado, el plan provee instalación de nueva
tecnología sobre una base piloto para determinar su efectividad y
beneficios económicos.
ƒ Los requerimientos y planes son revisados por los gerentes de los
grupos afectados y el grupo responsable de cambios tecnológicos.

ƒ Esfuerzos pilotos para mejorar la tecnología existentes son realizados

antes de introducir la nueva tecnología en la practica normal

ƒ Nueva tecnología apropiada es incorporada en el estándar de la

organización de acuerdo al proceso documentado.
ƒ Nueva tecnología es incorporada a los proyectos de software de la
organización de acuerdo a un procedimiento documentado.

Administración de cambios:

ƒ Un programa para mejorar el proceso es establecido, el cual impulsa a los

miembros de la organización a mejorar los procesos de la organización.

ƒ El grupo responsable de las actividades del proceso de Software, coordina las

actividades de mejora.
Este grupo:
ƒ Define los objetivos organizacionales y planes de medidas de performance
del proceso de software.
ƒ Revisa los objetivos organizacionales para la performance del proceso.
ƒ Participa en el esfuerzo de definir el entrenamiento que la organización
necesita para mejorar el proceso y para soportar el desarrollo y presentación
del material de entrenamiento.
ƒ Define y mantiene los procedimientos para manejar las propuestas de
mejoras.

Ingenieria de Software 2006 – U.N.C.P.B.A. 47

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

ƒ Revisar propuestas de mejoras de proceso y coordinar las acciones para esas

propuestas.

Ingenieria de Software 2006 – U.N.C.P.B.A. 48

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Apéndice B – Glosario de Términos

Actividad: Cualquier paso tomado o función realizada, ya sea física o mentalmente para
lograr algún objetivo.

Capacidad de un proceso de software describe el rango de resultados esperados que

pueden lograrse siguiendo el proceso de software. La capacidad de un proceso de
software de una organización brinda una manera de predecir el resultado más probable
para el siguiente proyecto de software que la organización emprenda.

Calidad de software: Es el grado en que un sistema, componente o proceso satisface un

requerimiento especifico o las necesidades del cliente.

Proceso de software: Un conjunto de actividades, métodos, practicas, y

transformaciones que las personas usan para desarrollar y mantener software y
productos asociados (e.g., planes de proyectos, documentos de diseños, código, caso de
testeo, y manuales de usuario).

Ingeniería de Software: es la rama de la ingeniería que aplica los principios de la ciencia

de la computación y las matemáticas para lograr soluciones costo-efectivas (eficaces en
costo o económicas) a los problemas de desarrollo de software", es decir, "permite
elaborar consistentemente productos correctos, utilizables y costo-efectivos" [Cota
1994].

Institucionalización: Es el proceso de construir una base una infraestructura y cultura

corporativa que soporte métodos, prácticas, y procedimientos del negocio
independientemente si quien lo haya definido permanezca en la organización. El uso de
políticas, estándares y estructuras organizativas institucionalizan un proceso.

Madurez de un proceso de software: Es la amplitud en la cual un proceso especifico es

explícitamente definido, manejado, medido, controlado y llevado a cabo. La madurez
implica un potencial para el crecimiento en la capacidad e indica la riqueza de la
organización y consistencia al realizar los proyectos. El proceso de de software es
claramente conocido por todos los integrantes de una organización madura. La
transmisión de conocimientos es a través de documentos y capacitación, y el proceso
esta continuamente controlado y mejorado por los usuarios. La capacidad y la calidad de
los productos de un proceso de software maduro es predecible con gran exactitud.

Desempeño de proceso de software: Representa el resultado real logrado siguiendo el

proceso de software. De esta manera, el desempeño se concentra sobre los resultados
alcanzados, mientras que la capacidad se centra en los resultados esperados. Basado en
los atributos de un proyecto especifico y el contexto del cual es conducido, el actual
desempeño del proyecto no refleja la entera capacidad de proceso de la organización,
por ejemplo, la capacidad de un proyecto esta restringida por el ambiente. Suele suceder
que un cambio drástico en la aplicación o en la tecnología puede colocar al staff del
proyecto en una curva de aprendizaje y causar que la capacidad y el desempeño del
proyecto no cubran la totalidad de la capacidad.

Ingenieria de Software 2006 – U.N.C.P.B.A. 49

Alvaríz – Bilbao – Goñi – Saavedra
 CMM – Capability Maturity Model

Apendice C – Referencias
Cota94 Cota A. 1994 "Ingeniería de Software". Soluciones Avanzadas. Julio de
1994. pp. 5-13.
Humphrey87a W.S. Humphrey, Characterizing the Software Process: A
Maturity Framework, Software Engineering Institute,
CMU/SEI-87-TR-11, ADA182895, June 1987.
Humphrey87b W.S. Humphrey and W.L. Sweet, A Method for Assessing
the Software Engineering Capability of Contractors,
Software Engineering Institute, CMU/SEI-87-TR-23,
ADA187320, September 1987.
Humphrey89 W.S. Humphrey, Managing the Software Process,
Addison-Wesley, Reading, MA, 1989.
Humphrey91 W.S. Humphrey, "Process Fitness and Fidelity,"
Proceedings of the Seventh International Software Process
Workshop, 16-18 October 1991.
Imai86 M. Imai, Kaizen: The Key to Japan's Competitive Success,
McGraw-Hill, New York, NY, 1986.
Paulk91 M.C. Paulk, B. Curtis, M.B. Chrissis, et al, Capability
Maturity Model for Software, Software Engineering
Institute, CMU/SEI-91-TR-24, ADA240603, August 1991.
Paulk93 M.C. Paulk, B. Curtis, M.B. Chrissis, and Charles V.
Weber, Capability Maturity Model for Software, Version
1.1, Software Engineering Institute, CMU/SEI-93-TR-24,
February 1993.
Weber91 C.V. Weber, M.C. Paulk, C.J. Wise, and J.V. Withey, Key
Practices of the Capability Maturity Model, Software
Engineering Institute, CMU/SEI-91-TR-25, ADA240604,
August 1991.

Ingenieria de Software 2006 – U.N.C.P.B.A. 50

Alvaríz – Bilbao – Goñi – Saavedra