MetricasSoftwareRev3-09032006 - Gloria Mendoza

Vista previa del material en texto

Sistemas de Gestión II 
 
Métricas del Software 
Revisión 3 
Trabajo realizado por: 
Rubén Muccilli 
Melina Potenza 
 
Docentes revisores: 
Est. Mónica Grasso 
Ing, Cristian Bigatti 
 
-2006- 
Sistemas de Gestión II 
Métricas del software 
 
 
1. Acerca de CMMI................................................................................... 3 
1.1 Enfoque en procesos....................................................................... 3 
1.2 Premisa de la mejora de procesos ................................................... 3 
1.3 La importancia de un modelo .......................................................... 3 
1.4 ¿Qué es CMMI? ............................................................................... 3 
1.4.1 Antes y después de CMMI ......................................................... 4 
1.4.2 Estructura de CMMI (Representación por Niveles) ..................... 4 
1.4.3 Niveles de madurez .................................................................. 4 
2. Introducción a las mediciones .............................................................. 6 
2.1 Algunas definiciones ....................................................................... 6 
2.2 Beneficios de las mediciones........................................................... 7 
2.3 Atributos de un programa de medición exitoso ................................ 7 
2.4 Los nueve principios de las mediciones ........................................... 7 
3. Clasificación de indicadores ................................................................. 8 
4. Indicadores por nivel de madurez ........................................................ 9 
5. Desarrollo de Indicadores ...................................................................13 
5.1 Progreso ......................................................................................13 
5.1.1 Proporción de tiempo de retrabajo sobre el tiempo total de cada 
proyecto ..........................................................................................13 
5.2 Esfuerzo ........................................................................................15 
5.2.1 Proporción de esfuerzo de retrabajo sobre el esfuerzo total por 
proyecto. .........................................................................................15 
5.3 Costo ............................................................................................17 
5.3.1 Costo real vs. Estimado con límites de control. .........................17 
5.4 Calidad..........................................................................................20 
5.4.1 Estado de los issues de no conformidades. ...............................20 
5.4.2 Estado de los ítems de acción. ..................................................21 
5.4.3 Causas de problemas reportados..............................................23 
5.4.4 Resultado de Revisión por Pares ..............................................26 
5.5 Estabilidad ....................................................................................27 
5.5.1 Número de cambios a requerimientos y aclaraciones de 
requerimientos con rangos. ..............................................................27 
5.6 Entrenamiento...............................................................................27 
5.6.1 Número de clases ofrecidas real vs. Estimado. ..........................27 
5.7 Performance del proceso ...............................................................27 
5.7.1 Número de cambios al proceso.................................................27 
5.8 Satisfacción del cliente ..................................................................27 
6. Glosario .............................................................................................27 
Fuentes..................................................................................................27 
Sistemas de Gestión II 
Métricas del software 
 
Página 3 de 42 
Revisión 3 
1. Acerca de CMMI 
 
1.1 Enfoque en procesos 
 
De acuerdo a la IEEE3 (Institute of Electrical and Electronics Engineers) un Proceso 
es una secuencia de pasos realizados para un propósito dado. 
El SEI define al “Proceso de software” como el conjunto de actividades, métodos, 
prácticas y transformaciones que la gente usa para desarrollar y mantener 
software. 
Los procesos involucran la utilización de un conjunto de recursos y actividades 
interrelacionadas. Tales recursos pueden incluir personas, instalaciones, equipos, 
técnicas y métodos. Existen 3 dimensiones críticas: los procesos, las personas y la 
tecnología. Hacemos hincapié en los procesos y decimos que “los mejores recursos 
no pueden desempeñarse de la mejor manera si el 
proceso no es entendido ni bien ejecutado”. 
Los procesos son el mayor determinante de costos, tiempo y calidad, y son los que 
realmente permiten “independizarse” de las personas. 
 
1.2 Premisa de la mejora de procesos 
 
“La calidad de un producto está determinada por la calidad del proceso que se usa 
para desarrollarlo y para mantenerlo”. 
Esta premisa se logra enfocando el proceso como producto. 
El objetivo del proceso de administración del software es el de crear productos 
acordes al plan mientras, simultáneamente, perfeccionamos a la organización para 
crear mejores productos. 
Un proceso de software efectivo total debe considerar la relación entre todas las 
tareas requeridas, las herramientas y métodos usados y las habilidades, 
entrenamientos y motivación de las personas involucradas. 
El principio básico para esto es el Proceso de Control Estadístico. Un proceso está 
bajo Control Estadístico si su performance futura es predecible dentro de los límites 
estadísticos establecidos. 
 
1.3 La importancia de un modelo 
 
Un modelo provee 
§ Un punto de partida 
§ El beneficio de experiencias anteriores 
§ Un lenguaje común y una visión compartida 
§ Un marco de trabajo para priorizar acciones 
 
Un modelo NO es un proceso. 
El modelo muestra Qué hacer, no Cómo hacerlo ni Quién debe hacerlo. 
 
1.4 ¿Qué es CMMI? 
 
Capability Maturity Model Integration 
(Modelo de Madurez de Capacidades Integrado) 
 
• Es un modelo de referencia sobre prácticas maduras de alguna disciplina 
específica. 
• Provee guías para mejorar los procesos de la organización y la habilidad 
para administrar el desarrollo, adquisición y mantenimiento de productos y 
servicios. 
• Integra las disciplinas de ingeniería de sistemas y de software dentro del 
marco de trabajo de la mejora de procesos. 
 
Sistemas de Gestión II 
Métricas del software 
 
Página 4 de 42 
Revisión 3 
1.4.1 Antes y después de CMMI 
 
 
 
 
1.4.2 Estructura de CMMI (Representación por Niveles) 
 
 
 
1.4.3 Niveles de madurez 
 
• Los niveles de madurez proporcionan una manera de predecir el 
funcionamiento futuro de una organización 
• Cada nivel es una base evolutiva que fundamenta los procesos de mejora 
continua. 
• Cada vez que se alcanza un Nivel de Madurez, se incrementa la 
productividad del proceso y de las organizaciones. 
• En la representación por niveles (staged) existen 5 Niveles de Madurez. 
 
Nivel Inicial o Realizado: 
• La organización no posee un ambiente estable de desarrollo de software. 
• Ausencia de gerencia de proyectos. 
Se controla la calidad del producto y se 
garantiza la satisfacción del cliente 
No se puede predecir la calidad del producto 
Existen objetivos cuantificables para medir la 
calidad del producto 
La calidad del producto no es definida sobre 
una base objetiva 
Las estimaciones de costos y tiempos se basan 
en experiencias anteriores, reales y 
cuantificadas 
No se hacen estimaciones de costos y tiempo 
reales 
 
Los roles y responsabilidades de los grupos y 
sus miembros están claramente definidos. 
Actúa en respuesta a las crisis que surjan 
Los procesos técnicos y gerenciales están 
establecidos, son comunicados a toda la 
organización y se exige su aplicación 
Improvisa o no emplea la gerencia deproyectos 
Tiene definido e implantado el método de 
desarrollo y mantenimiento de software 
Improvisa o no sigue rigurosamente los 
procesos de software 
Organización madura Organización inmadura 
Sistemas de Gestión II 
Métricas del software 
 
Página 5 de 42 
Revisión 3 
• El proceso de software es cambiante e irregular. 
• Durante las crisis, los grupos abandonan el método y se concentran en la 
codificación y pruebas. 
• Los planes, estimaciones y calidad son impredecibles. 
• El rendimiento y el éxito dependen de la capacidad individual de los 
miembros del grupo. 
• La capacidad es una característica de los individuos y no de la organización. 
 
Nivel Administrado: 
• La organización establece políticas para gerencia r los proyectos de software 
y procedimientos para implantar estas políticas. 
• Los procesos están bajo un control efectivo de un sistema de gerencia de 
proyectos basado en experiencias anteriores. 
• Los procesos son definidos, documentados, practicados, medidos, obligados 
y mejorables. 
• Los procesos de software son estables y repetibles. 
• Existen estándares de desarrollo definidos y exigidos. 
• La calidad es controlada. 
 
Nivel definido: 
• Los procesos de software son definidos: 
– estandarizados, documentados e institucionalizados. 
• Se institucionaliza un proceso estándar de desarrollo de software que 
integra en uno solo: 
– los procesos de ingeniería de software y 
– gerencia de proyectos de software 
• Existe un entendimiento común de los procesos, funciones y 
responsabilidades. 
• La organización mantiene un grupo dedicado a la definición, mejoramiento y 
difusión del proceso estándar. 
• El proceso estándar es adaptado a cada tipo de proyecto. 
 
Nivel Cuantitativamente Administrado: 
• La organización define metas de calidad cuantitativas para: 
– los productos de software y 
– los procesos de software 
• El proceso estándar es medible o cuantificable: 
– La productividad y la calidad se miden y se registran para cada 
proyecto 
• La calidad del software es predecible. 
• Mediante el uso de métricas de software, se crea una base de datos 
cuantitativa para la evaluación y estimación en proyectos futuros. 
• La capacidad del proceso de software es cuantificable y predecible. 
 
Nivel Optimizado: 
• La organización se orienta hacia el mejoramiento contínuo de sus procesos 
de software 
– La organización identifica las debilidades y fortalezas de su proceso y 
determina maneras de mejorar su capacidad. 
• La organización busca aumentar la capacidad y el rendimiento de sus 
procesos. 
• Se incorporan nuevas tecnologías y métodos para mejorar los procesos. 
• El mejoramiento ocurre a través de: 
– El avance incremental del proceso 
– Uso de nuevas tecnologías y métodos 
 
 
Sistemas de Gestión II 
Métricas del software 
 
Página 6 de 42 
Revisión 3 
 
 
2. Introducción a las mediciones 
 
Cuando una empresa de software decide implementar una norma de calidad, tal 
como ISO 9001:2000, o un modelo como CMMI (Capability Maturity Model 
Integration) con el objetivo de mejorar sus procesos y lograr la satisfacción del 
cliente, se encuentra con la necesidad ineludible de definir e implementar 
mediciones que reflejen el estado de procesos y proyectos. 
Esta tarea, que no es nada sencilla, se vuelve más compleja a medida que la 
empresa madura hacia los niveles superiores de CMMI (modelo que tomaremos 
como marco para el desarrollo de este trabajo). 
Las métricas iniciales definidas en el Nivel 2 “Administrado”, se profundizan en los 
niveles superiores, hasta llegar a un nivel 4 donde la empresa es capaz de 
administrar sus proyectos y la performance de sus procesos a través de 
indicadores. En este nivel, es imprescindible aplicar técnicas estadísticas para 
monitorear el proceso y predecir su comportamiento futuro, siendo la más aplicada 
el Control estadístico de procesos (CEP). 
Finalmente, en el nivel 5, “Optimizado”, la empresa es capaz de medir 
cuantitativamente el impacto de cada mejora implementada en el proceso o el 
beneficio que produjo la inserción de una nueva tecnología. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 1: Relaciones entre indicadores y niveles de madurez 
 
2.1 Algunas definiciones 
 
Indicador: es una representación de datos de mediciones que provee una idea del 
proceso de desarrollo de software y/o de las actividades de mejora de procesos. 
 
Medición: El acto o proceso de medir algo. También puede ser un resultado, tal 
como una figura expresando la extensión o valor que es obtenido al medir. 
 
Medida: Una unidad o estándar de medición / la extensión, dimensiones, 
capacidad, etc. de algo relacionado a un estándar / un acto o proceso de medición / 
un resultado de una medición. 
 
Medir: Determinar la cantidad, volumen, extensión o grado de algo en términos de 
una unidad estándar o monto fijo, usualmente a través de un instrumento o 
proceso. 
Nivel de madurez 
Indicadores 
Aplican a un… 
Usuarios durante las 
etapas del ciclo de 
vida. 
Entradas Áreas de Proceso 
Objetivos 
Usados por… 
Evalúan el 
progreso para 
lograr… 
Cumplen… Usan… 
Sistemas de Gestión II 
Métricas del software 
 
Página 7 de 42 
Revisión 3 
 
Métrica: En este documento, métrica es usado como sinónimo de medida. 
 
2.2 Beneficios de las mediciones 
 
Las empresas con programas de medición exitosos, cuentan con los siguientes 
beneficios: 
§ Conocimiento del desarrollo del producto. 
§ Capacidad de cuantificar las decisiones trade-off (aquellas que involucran a 
más de un área de la empresa). 
§ Mejor planeamiento, control y monitoreo de los proyectos. 
§ Mejor entendimiento del proceso de desarrollo de software y del ambiente 
de desarrollo. 
§ Identificación de áreas de potenciales mejoras a procesos, así como de 
objetivos de medición del esfuerzo de mejora. 
§ Comunicación mejorada. 
§ Identificación y corrección temprana de problemas. 
§ Administración efectiva de riesgos. 
 
 
2.3 Atributos de un programa de medición exitoso 
 
§ Existe un compromiso organizacional bien establecido y sostenido. 
§ La organización realmente utiliza los resultados de las mediciones. 
§ El proceso de medición está bien planificado. 
§ La recolección de las mediciones está automatizada. 
§ Las mediciones están definidas objetivamente y sin ambigüedades. 
§ El proceso de medición se mejora continuamente. 
§ Los resultados se comunican. 
 
2.4 Los nueve principios de las mediciones 
 
1. Usar issues1 y objetivos para derivar los requerimientos de mediciones 
2. Definir y recolectar mediciones basadas en los procesos técnicos y de 
administración. 
3. Recolectar datos a un nivel suficiente de detalle para identificar y aislar 
problemas. 
4. Implementar una capacidad de análisis independiente. 
5. Usar un proceso sistemático de análisis para conectar mediciones con 
decisiones. 
6. Interpretar los resultados de las mediciones en el contexto de otra 
información del proyecto. 
7. Integrar las mediciones al proceso de administración del proyecto a través 
del ciclo de vida. 
8. Usar las mediciones como base para una comunicación objetiva. 
9. Enfocarse inicialmente en el análisis del nivel del proyecto. 
 
 
1 Issue: asunto a resolver, problema del proyecto. 
Sistemas de Gestión II 
Métricas del software 
 
Página 8 de 42 
Revisión 3 
2.5 Usuarios de las mediciones 
 
Figura 2: Usuarios de las mediciones 
 
Todos los niveles de la administración de proyectos pueden usar los indicadores 
para planear y controlar el costo, cronograma, calidad, riesgos y recursos del 
proyecto. Adicionalmente, los indicadores le permiten a los administradores del 
proyecto tomar decisiones con información y discutir el estado y performance del 
proyecto con la administración senior y el cliente. 
El Grupo de Procesos de Ingeniería de Software puede usar los indicadores para 
mejorar el proceso, así como también la organización, para determinar la calidad delos productos y procesos del proyecto, y para monitorear la efectividad de las 
mejoras llevadas a cabo. 
La administración senior, desea visibilidad del costo, cronograma, calidad, riesgos, 
recursos y mejoras que ocurren en cada proyecto bajo su control, pero usualmente 
está interesado en el proceso como un todo y no en los detalles. Los indicadores 
proveen esta visibilidad, así como también una base de discusión con el 
administrador del proyecto y los clientes. Los indicadores también le proveen al 
administrador senior información acerca de la capacidad de la organización como 
un todo. 
El cliente puede usar los indicadores para realizar el seguimiento del costo, 
cronograma, riesgos y calidad del proyecto. La comunidad de investigación está 
interesada en obtener un conjunto de datos certeros consistentemente definidos 
que puedan ser usados en las mediciones que forman los indicadores. 
 
 
3. Clasificación de indicadores 
 
A continuación, se presentan las categorías que se utilizarán para clasificar los 
indicadores (propuestas por Baumert, John y McWhinney Mark en su libro “Software 
Measure and the Capability Maturity Model”): 
 
Clasificación del Indicador Descripción 
Progreso Provee información de cuan bien el 
Indicadores 
del software 
Administración 
Senior 
(visibilidad) 
Clientes 
(Seguimiento) 
Comunidad de 
investigación 
(investigaciones) 
Administradores 
del proyecto de 
Software 
(Planeación y 
Control) 
Grupo de 
Procesos de 
Ing. Del 
Software 
(mejora) 
Internos 
al 
proyecto 
Externos 
al 
proyecto 
Sistemas de Gestión II 
Métricas del software 
 
Página 9 de 42 
Revisión 3 
proyecto se está desarrollando con 
respecto a sus compromisos de 
cronograma (programación). 
Esfuerzo Provee visibilidad acerca de la 
contribución del staff con respecto a los 
costos del proyecto, adherencia al 
cronograma y calidad del producto. 
Costo Provee el seguimiento de los costos 
reales versus los costos estimados y 
provee estimaciones de los costos de los 
proyectos futuros. 
Calidad 
Resultados de auditorías de 
aseguramiento de la calidad (QA) del 
software 
Provee estimaciones de la calidad del 
producto y conformidad del staff con 
respecto a los procesos del proyecto. 
Reportes de revisiones Provee el estado de los ítems de acción 
de las revisiones de los ciclos de vida. 
Reportes de problemas Provee una idea de la calidad de los 
productos y procesos y la efectividad del 
testing. 
Resultados de revisiones por pares Provee una idea de la calidad de los 
productos intermedios y finales y de las 
revisiones por pares y procesos de 
desarrollo. 
Prevención de defectos Provee una idea de las causas de 
defectos y el efecto de las actividades 
de prevención de defectos en el ratio de 
inserción de defectos. 
Estabilidad 
Estabilidad de Requerimientos Provee visibilidad de la magnitud e 
impacto de los cambios a 
requerimientos. 
Estabilidad de Tamaño Provee una idea de la completitud y 
estabilidad de los requerimientos y de la 
capacidad del staff para completar el 
proyecto dentro del presupuesto y 
tiempo previsto. 
Efectividad de la tecnología Provee información de cuan bien el 
proyecto se está desarrollando con 
respecto a sus requerimientos/metas de 
utilización de recursos de computadora. 
Entrenamiento Provee visibilidad de la efectividad del 
programa de entrenamiento de la 
organización en el cumplimiento de los 
requerimientos de habilidades. 
Performance del proceso Provee una idea de la efectividad y 
calidad del proceso definido. 
Satisfacción del cliente Brinda información acerca de la 
satisfacción de los clientes con los 
servicios y productos brindados. 
 
 
4. Indicadores por nivel de madurez 
 
En las tablas siguientes, veremos qué indicadores son recomendados por cada 
categoría, para cada nivel de madurez de CMMI. 
Sistemas de Gestión II 
Métricas del software 
 
Página 10 de 42 
Revisión 3 
 
Clasificación del 
Indicador 
Nivel Administrado Nivel Definido 
Progreso Fechas de finalización 
reales vs. Estimadas. 
 Diagrama de Gantt. 
Fechas de finalización 
reales vs. Estimadas 
con rangos. 
Diagrama de Gantt. 
Diagrama de PERT . 
Esfuerzo Perfil de staff estimado 
vs. Real. 
Perfil de staff estimado 
vs. Real con mayor 
granularidad. 
Costo Costo real vs. Estimado. 
Variaciones de costo y 
cronograma. 
Costo real vs. Estimado 
con rangos2. 
Índices de performance 
de costo y cronograma. 
Calidad 
Resultados de 
auditorías de 
aseguramiento de la 
calidad (QA) del 
software 
Estado de los issues de 
no conformidades. 
Estado de los issues de 
no conformidades. 
Información de 
auditorías. 
Información de tamaño 
de muestra. 
Reportes de revisiones Estado de los ítems de 
acción. 
Estado de los ítems de 
acción. 
Reportes de problemas Estado de los reportes 
de problemas. 
Número de problemas 
reportados abiertos, 
cerrados y no evaluados 
durante el período del 
reporte. 
Densidad de reportes de 
problemas. 
Comparación entre los 
reportes de problemas y 
los casos de prueba 
pasados. 
Estado de los reportes 
de problemas. 
Número de problemas 
reportados comparados 
con datos históricos. 
Tiempo que 
permanecen abiertos los 
reportes de problemas. 
Número de reportes de 
problemas por producto. 
Resultados de 
revisiones por pares 
 Número de defectos 
abiertos y cerrados. 
Número de defectos por 
producto. 
Densidad de defectos. 
Análisis de Pareto de los 
defectos. 
Gráficos de control 
preliminares. 
Prevención de defectos 
Estabilidad 
Estabilidad de 
Requerimientos 
Número de cambios a 
requerimientos y 
aclaraciones de 
requerimientos. 
Distribución de los 
requerimientos por 
Número de cambios a 
requerimientos y 
aclaraciones de 
requerimientos con 
rangos. 
Distribución de los 
 
2 En este documento, el término rango es utilizado como sinónimo de intervalo. 
Sistemas de Gestión II 
Métricas del software 
 
Página 11 de 42 
Revisión 3 
release. requerimientos por 
release. 
Distribución de los 
cambios a 
requerimientos por tipo 
de requerimiento. 
Tiempo que los cambios 
a requerimientos 
permanecen abiertos. 
Número de waivers 3 
solicitadas y aceptadas 
de los requerimientos. 
Estabilidad de Tamaño Crecimiento del tamaño. 
Distribución del tamaño 
por release. 
Crecimiento del tamaño 
con rangos. 
Distribución del tamaño 
por release. 
Efectividad de la 
tecnología 
Perfiles de utilización de 
recursos de 
computadora reales vs. 
Estimados. 
Perfiles de utilización de 
recursos de 
computadora reales vs. 
Estimados. 
Entrenamiento Número de clases 
ofrecidas real vs. 
Estimado. 
Asistencia real vs. 
Estimada. 
Perfil de calidad de los 
cursos. 
Número de waivers de 
entrenamiento. 
Performance del 
proceso 
 Número de cambios al 
proceso. 
Número de waivers al 
proceso. 
Satisfacción del cliente Porcentaje de clientes 
satisfechos e 
insatisfechos. 
 
 
Clasificación del 
Indicador 
Nivel Cuantitativamente 
Administrado 
Nivel Optimizado 
Progreso Fechas de finalización 
reales vs. Estimadas 
con límites de control. 
Diagrama de Gantt. 
Diagrama de PERT. 
Proporción de tiempo de 
retrabajo sobre el 
tiempo total de cada 
proyecto. 
Proporción de tiempo 
insumido en actividades 
que experimentaron 
cambios al proceso. 
Esfuerzo Igual al nivel Definido. Proporción de esfuerzo 
de retrabajo sobre el 
esfuerzo total por 
proyecto. 
Proporción de esfuerzo 
insumido en actividades 
 
3 Waiver: renuncia, concesión. Algo que se permite eliminar o no hacer como 
excepción. 
Sistemas de Gestión II 
Métricas del software 
 
Página 12 de 42 
Revisión 3 
que experimentaron 
cambios al proceso. 
Costo Costo real vs. Estimado 
con límites de control. 
Índices de performance 
de costo y cronograma. 
Costos y beneficios 
comparativos de 
alternativas de mejorasal proceso y tecnologías 
y actividades de 
prevención de defectos. 
Costo y beneficio real 
vs. estimado de una 
actividades alternativa 
de mejora a procesos, 
de prevención de 
defectos o tecnología. 
Calidad 
Resultados de 
auditorías de 
aseguramiento de la 
calidad (QA) del 
software 
Igual al nivel Definido. Igual al nivel Definido. 
Reportes de revisiones Igual al nivel Definido. Igual al nivel Definido. 
Reportes de problemas Causas de problemas 
reportados. 
Eficiencia de desarrollo, 
testing e 
implementación. 
Igual a los niveles 
Definido y 
Cuantitativamente 
Administrado. 
Resultados de 
revisiones por pares 
Número de defectos 
abiertos y cerrados. 
Número de defectos por 
producto. 
Densidad de defectos. 
Análisis de Pareto de los 
defectos. 
Gráficos de control de 
las características de las 
revisiones por pares. 
Igual al nivel Definido. 
Prevención de defectos Perfiles de categorías de 
defectos. 
Proporción de inserción 
de defectos. 
Estabilidad 
Estabilidad de 
Requerimientos 
Igual al nivel Definido. Igual al nivel Definido. 
Estabilidad de Tamaño Crecimiento del tamaño 
con límites de control. 
Distribución del tamaño 
por release. 
Igual a los niveles 
Definido y 
Cuantitativamente 
Administrado. 
Efectividad de la 
tecnología 
Igual al nivel Definido. Igual al nivel Definido. 
Entrenamiento Igual al nivel Definido. Igual al nivel Definido. 
Performance del 
proceso 
Igual al nivel Definido. Igual al nivel Definido. 
Satisfacción del cliente Igual al nivel Definido. Igual al nivel Definido. 
 
 
 
Sistemas de Gestión II 
Métricas del software 
 
Página 13 de 42 
Revisión 3 
 
 
5. Desarrollo de Indicadores 
 
A continuación se desarrollarán los indicadores más significativos de cada categoría, 
de acuerdo a los niveles superiores de madurez del Modelo CMMI. 
 
5.1 Progreso 4 
 
La diferencia entre progreso y esfuerzo 
La principal diferencia entre los indicadores de progreso y esfuerzo es que los 
primeros se miden en días transcurridos, y los segundos en horas de trabajo 
efectivas. 
Veamos un ejemplo: Supongamos que una empresa de software quiere monitorear 
el desvío entre los tiempos estimados y reales de sus proyectos de desarrollo. Si 
determinada tarea del proyecto, por ejemplo, la codificación, debía llevar 20 horas 
hombre y llevó 30, tuve un desvío en esfuerzo del 50%. Ahora bien: si yo 
planifiqué entregar el software terminado en 30 días y lo entregué en 45, tuve un 
desvío en progreso del 50%. 
 
5.1.1 Proporción de tiempo de retrabajo5 sobre el tiempo total de cada 
proyecto 
 
En el nivel Cuantitativamente Administrado, el progreso se controla y mide 
estadísticamente. Los indicadores de progreso en el nivel Optimizado examinan el 
efecto de las actividades de mejora a procesos, innovación tecnológica y de 
prevención de defectos. Los cambios al proceso de desarrollo deberían causar que 
el tiempo insumido en cada actividad disminuya, incrementando la productividad. 
Mientras los cambios a procesos ocurren, el progreso no está bajo control 
estadístico, pero se estabilizará luego de un período de tiempo. La variación en la 
performance será menor, por lo que los límites de control serán más cercanos al 
promedio. Mientras el proceso está cambiando, el progreso debe ser monitoreado 
para asegurarse de que los cambios no son perjudiciales. 
 
Objetivo: Proveer a los administradores información de los efectos de la prevención 
de defectos, la innovación tecnológica y las mejoras a procesos en el progreso de 
los proyectos. 
 
Indicadores: 
§ Proporción de tiempo de retrabajo sobre el tiempo total del proyecto por 
proyecto. 
§ Seguimiento de la proporción de tiempo insumido en actividades que 
sufrieron cambios en el proceso. 
 
Etapa del ciclo de vida: todas. 
 
 
Usuarios: 
§ Todos los niveles de administradores de proyectos de software. 
§ Grupo de procesos de ingeniería del software (SEPG). 
 
Entradas: 
§ Plan de desarrollo del proyecto de software. 
 
4 Los indicadores de progreso se miden en días transcurridos. 
5 El tiempo de retrabajo se refiere al tiempo insumido en realizar nuevamente una 
tarea debido a fallas o no conformidades la primera vez que se realizó. 
Sistemas de Gestión II 
Métricas del software 
 
Página 14 de 42 
Revisión 3 
§ Tiempo planeado y real insumido en actividades. 
 
Interpretación: 
La figura 3 muestra un diagrama de dispersión de la proporción de retrabajo para 
varios proyectos. 
En la figura 3, el eje y es la proporción de tiempo insumido en retrabajo sobre el 
tiempo total del proyecto. Cada punto en el diagrama es un proyecto que se 
completó en ese mes. 
 
La figura 4 muestra el mismo diagrama con límites de control y una línea promedio 
derivada de los datos. Antes del mes 4, las proporciones son altas y varían 
ampliamente. El procedimiento de prevención de defectos fue puesto en marcha 
durante el mes 5. Aunque sigue existiendo una gran variación durante el mes 5 
hasta el mes 7, la tendencia indica que los procedimientos son efectivos. Para el 
mes 8, el nuevo procedimiento se ha estabilizado, las proporciones han caído y 
nuevos límites de control han sido establecidos. Cabe aclarar que estos límites de 
control son provisorios, debido a que no se poseen datos suficientes aún para 
calcular los límites definitivos. 
 
El gráfico de la figura 4 se puede usar también para realizar el seguimiento de la 
proporción de tiempo de revisiones por pares, codificación, prueba y otras 
actividades sobre el total de tiempo de desarrollo. Esto permite a la organización 
determinar su performance con respecto a esfuerzos preventivos y reactivos, esto 
es, la organización puede comparar el tiempo empleado en diseñar en oposición 
con el tiempo empleado en codificar o el tiempo empleado en revisiones por pares 
versus el tiempo empleado en testing. El énfasis debe estar en las actividades 
preventivas. 
 
 
 
 
 
 
 
Figura 3: Diagrama de dispersión de la proporción de tiempo insumido en actividades de retrabajo para 
varios proyectos. 
 
 
 
Meses 
Procedimiento de 
prevención de 
defectos definido 
Pr
op
or
ci
ón
 d
e 
re
tr
ab
aj
o 
so
b
re
 t
ie
m
p
o 
to
ta
l 
Sistemas de Gestión II 
Métricas del software 
 
Página 15 de 42 
Revisión 3 
 
 
 
 
Figura 4: Proporción de tiempo insumido en actividades de retrabajo para varios proyectos, con límites 
de control. 
 
 
 
5.2 Esfuerzo6 
 
5.2.1 Proporción de esfuerzo de retrabajo sobre el esfuerzo total por 
proyecto. 
 
Los indicadores de esfuerzo en el nivel Optimizado examinan los efectos de las 
actividades de mejora a proceso, innovación tecnológica, y actividades de 
prevención de defectos en esfuerzo. 
 
Objetivo: Proveer a los administradores información acerca de los efectos de la 
prevención de defectos, innovación tecnológica, y mejoras a procesos en el 
esfuerzo del proyecto. 
 
Indicadores: 
§ Proporción de esfuerzo de retrabajo sobre el esfuerzo total del proyecto por 
proyecto. 
§ Seguimiento de la proporción de esfuerzo insumido en actividades que han 
experimentado cambios al proceso. 
 
Etapa del ciclo de vida: todas. 
 
Usuarios: 
§ Todos los niveles de administradores de proyectos de software. 
§ Grupo de procesos de ingeniería del software (SEPG). 
 
Entradas: 
§ Plan de desarrollo del proyecto de software. 
§ Esfuerzo planeado y real insumido en actividades. 
 
Interpretación: 
 
6 Los indicadores de esfuerzo se miden en horas insumidas. 
Procedimiento de 
prevención de 
defectos definido 
Pr
op
or
ci
ón
 d
e 
re
tr
ab
aj
o 
so
b
re
 t
ie
m
p
o 
to
ta
l 
Meses 
Sistemas de Gestión II 
Métricas del software 
 
Página 16 de 42 
Revisión 3 
La figura 5 muestra un diagrama de dispersión de la proporción de retrabajo para 
varios proyectos con límites de control y una línea promedio derivada de los datos. 
 
En la figura 5, el eje y es la proporción de esfuerzo insumidoen retrabajo sobre el 
esfuerzo total del proyecto. Cada punto en el diagrama es un proyecto que se 
completó en ese mes. Una vez que el retrabajo es reducido, la productividad 
mejora ya que el staff no tiene que repetir trabajos en una actividad particular. Son 
necesarias menos iteraciones para completar la actividad o producto. 
 
En la figura, las proporciones son altas y varían ampliamente antes del mes 4. El 
procedimiento de prevención de defectos fue puesto en marcha durante el mes 5. 
Aunque sigue existiendo una gran variación durante el mes 5 hasta el mes 7, la 
tendencia indica que los procedimientos son efectivos. Para el mes 8, fueron 
establecidos nuevos límites de control provisorios, que serán monitoreados y 
recalculados hasta verificar que el procedimiento sea estable nuevamente. 
 
El gráfico de la figura se puede usar también para realizar el seguimiento de la 
proporción de esfuerzo de revisiones por pares, codificación, prueba y otras 
actividades sobre el total de esfuerzo de desarrollo. Esto permite a la organización 
determinar su performance con respecto a esfuerzos preventivos y reactivos, esto 
es, la organización puede comparar el esfuerzo empleado en diseñar en oposición 
con el esfuerzo empleado en codificar o el esfuerzo empleado en revisiones por 
pares versus el esfuerzo empleado en testing. El énfasis debe estar en las 
actividades preventivas. 
 
 
 
 
Figura 5: Proporción del esfuerzo insumido en actividades de retrabajo para varios proyectos. 
 
 
 
 
 
 
 
 
 
 
 
Procedimiento de 
prevención de 
defectos definido 
Pr
op
or
ci
ón
 d
e 
re
tr
ab
aj
o 
so
b
re
 t
ie
m
p
o 
to
ta
l 
Meses 
Sistemas de Gestión II 
Métricas del software 
 
Página 17 de 42 
Revisión 3 
5.3 Costo 
 
5.3.1 Costo real vs. Estimado con límites de control. 
 
En el nivel Cuantitativamente Administrado, aplicamos control estadístico de 
procesos para la confección de indicadores tales como un reporte de estado de 
costo/crongrama. El administrador del proyecto de software usa datos históricos y 
cálculos estadísticos para establecer los límites de control. Para el monitoreo de la 
performance del costo, el administrador determina la causa cuando el costo 
presupuestado para el trabajo realizado y el costo real del trabajo realizado caen 
fuera de los límites de control. 
También en el nivel Cuantitativamente Administrado, el costo de la calidad es 
medido adicionalmente al costo de otros elementos del proyecto. 
 
Objetivo: Realizar el seguimiento de los costos reales contra el plan de proyecto y 
presupuestar el costo de futuros proyectos. 
 
Indicadores: 
§ Performance del costo actual del trabajo realizado contra el costo 
presupuestado para el trabajo programado. 
§ Performance del costo presupuestado del trabajo realizado contra el costo 
presupuestado del trabajo programado. 
§ Seguimiento de la variación del costo. 
§ Seguimiento de la variación del cronograma. 
§ Seguimiento de los índices de performance de costo y cronograma. 
 
Etapas del ciclo de vida: Todas. 
 
Usuarios: Todos los niveles de la administración. No sólo los administradores de 
proyectos de desarrollo de software, sino también de grupos de soporte tales como 
aseguramiento de la calidad, administración de la configuración del software, y 
entrenamiento. 
 
Definiciones: 
CPTP: Costo Presupuestado para el Trabajo Programado. Es el costo estimado de 
todas las actividades que se deberían haber realizado en el proyecto al día de hoy. 
CPTR: Costo Presupuestado para el Trabajo Realizado. Es el costo estimado de 
todas las actividades que efectivamente se realizaron en el proyecto al día de hoy 
(pueden ser menos actividades que las programadas o actividades diferentes). 
CRTR: Costo Real del Trabajo Realizado. Es el costo real de todas las actividades 
que efectivamente se realizaron en el proyecto al día de hoy (pueden ser menos 
actividades que las programadas o actividades diferentes). 
 
Entradas: 
El Costo Presupuestado para el Trabajo Programado (CPTP), el Costo 
Presupuestado para el Trabajo Realizado (CPTR) y el Costo Real del Trabajo 
Realizado (CRTR) son determinados para todas las actividades del proyecto 
incluyendo: 
§ Administración de requerimientos. 
§ Actividades de planificación del software. 
§ Trabajo técnico. 
§ Actividad de subcontratistas. 
§ Administración de subcontratistas. 
§ Actividades de aseguramiento de la calidad del software. 
§ Actividades de administración de la configuración del software. 
§ Actividades de definición y mejora de procesos. 
§ Actividades de coordinación intergrupal. 
Sistemas de Gestión II 
Métricas del software 
 
Página 18 de 42 
Revisión 3 
§ Actividades de medición y análisis del proceso. 
§ Actividades de prevención de defectos (para el nivel 5). 
§ Actividades de innovación tecnológica (para el nivel 5). 
 
Interpretación: 
 
En la figura 6 la performance del costo a la fecha es favorable, ya que el CRTR es 
mejor que el CPTR (la variación del costo es positiva). Sin embargo, la proporción 
de gastos aumenta como se ve en la pendiente creciente del CRTR durante el 
transcurso de los últimos dos meses. La línea del CPTR se mantiene relativamente 
plana. Estas dos líneas indican que el proyecto está gastando dinero, pero no está 
cumpliendo con el trabajo que estaba programado. Acorde a esto, la variación de 
costo positiva que ocurría en los meses previos está erosionando. Existe también 
una situación de cronograma desfavorable (la variación del cronograma es 
negativa). El CPTR continúa por debajo de la línea del CPTP, indicando que el este 
proyecto está retrasado. De todas formas, como el CPTR y el CPTP están 
convergiendo lentamente, el monto de retraso está disminuyendo. 
 
 
 
 
Figura 6: Reporte de estado de costo/cronograma mostrando el rango permitido para el costo 
presupuestado del trabajo programado. 
 
La figura 7 muestra la performance de las variaciones de costo y cronograma a 
través del tiempo para un proyecto diferente. La figura se focaliza en las 
variaciones y habitualmente muestra más convincentemente los problemas o éxitos 
del proyecto. La variación se define como (costo estimado – costo real)/costo real. 
La figura 7 muestra que este proyecto comenzó con una variación negativa del 
costo, logró revertirlo, pero luego en el mes 6 retornó a una pendiente negativa. La 
pendiente negativa empinada desde el mes 5 al mes 7 indica que el proyecto 
enfrentó un serio problema. De hecho, la gran variación negativa del cronograma 
en los meses precedentes realmente predijo el problema. En el intento de 
solucionar el problema de atraso en el cronograma, el proyecto gastó dinero de 
más y trajo una condición de costo sobrepasado. 
 
CPTP 
CPTR 
CRTR 
Meses 
Costo 
($1K) 
Costo programado al finalizar el proyecto 
Hoy 
Sistemas de Gestión II 
Métricas del software 
 
Página 19 de 42 
Revisión 3 
 
 
 
Figura 7: Reporte de variación 
 
El monto y el signo de la variación son importantes. Una organización usa sus datos 
históricos para determinar los rangos normales de variaciones de costo y 
cronograma. Una organización usa esos rangos para establecer umbrales límite en 
las variaciones. Por ejemplo, una organización puede adoptar + - 10% como riesgo 
bajo, +- 10 a 15% como riesgo moderado (y la posible necesidad de una acción 
correctiva) y cualquier variación mayor a +-15% como un riesgo alto que necesita 
una acción correctiva. El administrador del área que excede el umbral explica al 
nivel siguiente de administración la causa de la variación y la acción correctiva a ser 
tomada. Si la variación permanece consistentemente más allá de los umbrales, la 
organización deberá reexaminar sus procesos de estimación y programación. De la 
misma forma, si las variaciones permanecen consistentemente dentro del umbral, 
la administración podría redefinir los umbrales, permitiendo tolerancias menores. 
Cuando las variaciones son tan grandes que el plan ya no es válido, los 
administradores replanificanlos elementos del proyecto de acuerdo con el 
procedimiento documentado para el proyecto. 
 
Otra manera de analizar la performance del proceso es a través de los índices de 
performance de costo y cronograma. El índice de performance de costo (IPC) es la 
razón entre el costo presupuestado del trabajo realizado y el costo real del trabajo 
realizado, expresado como porcentaje [IPC = (CPTR / CRTR)*100%]. El índice de 
performance de cronograma (IPCR) es la razón entre el costo programado para el 
trabajo realizado y el costo programado para el trabajo programado, expresado 
como porcentaje [IPCR = (CPTR / CPTP)*100%]. 
La figura 8 muestra ejemplo del comportamiento de los índices de performance de 
costo y cronograma. Ambos índices son indicadores muy eficientes. Un índice de 
performance de costo del 50% indica que sólo la mitad del trabajo presupuestado 
ha sido realizado con el costo real para lograrlo. Esta es una performance muy 
pobre, y la razón por la cual esa performance debe ser determinada. Similarmente, 
si la mitad del trabajo programado, medido en dólares, ha sido realmente realizado, 
el índice de performance de cronograma será del 50%. 
 
Meses 
V
a
ri
a
ci
ó
n
 (
%
) 
Hoy 
Variación de Costo - - - - 
Variación de Cronograma 
Sistemas de Gestión II 
Métricas del software 
 
Página 20 de 42 
Revisión 3 
 
 
Figura 8: Ejemplo de reporte de Índices de Performance 
 
 
5.4 Calidad 
 
5.4.1 Estado de los issues de no conformidades. 
 
El personal de aseguramiento de la calidad de una empresa que aspira a evaluar el 
modelo CMMI, debe realizar periódicamente auditorías de calidad de producto y de 
proceso. Durante una auditoría de proceso, el grupo de aseguramiento de la calidad 
de software audita el proceso para revisar el proceso definido para el proyecto, 
administrar los costos, la planificación, los riesgos y las actividades técnicas y 
también utiliza y controla la base de datos del proceso de software para planificar y 
estimar. 
 
Objetivo: Proveer al Administrador del Proyecto de Software una evaluación 
independiente de la calidad del producto y de la adherencia del staff del proyecto a 
los procesos que crean el producto. 
 
Indicadores: 
§ Seguimiento del número, tipo y severidad de los issues de no conformidad 
encontrados durante una auditoría. 
§ Seguimiento de la proporción en la cual los issues de no conformidades son 
resueltos. 
 
Etapas del ciclo de vida: todas. 
 
Usuarios: 
§ Gerentes de nivel medio. 
§ Gerente del proyecto de software. 
§ Gerentes senior. 
§ Personal de aseguramiento de la calidad. 
 
Entradas: 
§ Número de issues de no conformidades en un período determinado: 
o Total 
o Abiertos 
o Cerrados 
§ Para cada issue de no conformidad: 
IPC 
 
IPCR 
Meses 
Ín
d
ic
e 
d
e 
Pe
rf
or
m
an
ce
 (
%
) 
Hoy 
Sistemas de Gestión II 
Métricas del software 
 
Página 21 de 42 
Revisión 3 
o Fecha de apertura 
o Tipo (por ejemplo, una no conformidad del producto referida a un 
estándar o una no conformidad de proceso). 
o Severidad (grado de no conformidad, por ejemplo, el producto no 
puede ser entregado como está, el producto debe ser corregido para 
la próxima versión, un cambio a un proceso es recomendado). 
o Fecha de cierre. 
§ Número de auditorías realizadas en un período determinado. 
§ Para cada auditoría: 
o Tipo de auditoría (de producto o de proceso). 
o Tamaño de la muestra (para cada auditoría de producto). 
 
Interpretación: 
La figura 9 compara el número de no conformidades de políticas, producto y 
proceso detectadas durante las auditorías de aseguramiento de la calidad en un 
período determinado. 
La figura muestra que el proceso de revisión por pares es efectivo, ya que fueron 
reportadas muy pocas no conformidades de producto. Estas no conformidades 
probablemente fueron encontradas en revisiones por pares y corregidas antes de la 
auditoría. Esto puede verificarse analizando los indicadores de revisiones por pares. 
El número de no conformidades de proceso es mayor a las de producto debido a 
que no existe un proceso anterior, tal como el de revisiones por pares, que actúe 
en forma directa sobre estas no conformidades. Las mismas son econtradas en las 
auditorías y analizadas posteriormente por el SEPG, para determinar causas de 
problemas recurrentes y mejorar los procesos. 
El personal de Aseguramiento de la calidad puede también preparar un informe que 
resuma las actividades de aseguramiento de la calidad. Este reporte puede incluir el 
número de auditorías realizadas de cada tipo, y un resumen de cada auditoría. Este 
información incluye tamaño de la muestra y porcentaje del total que representa. 
 
 
 
 
 
 
Figura 9: Número de issues de no conformidad por tipo en las auditorías del período. 
 
 
5.4.2 Estado de los ítems de acción. 
 
Objetivo: Proveer al Gerente de proyecto de software, gerencias senior y al cliente 
información acerca del estado de los ítems de acción originados durante una 
revisión del ciclo de vida. 
 
Número de 
issues de no 
conformidad 
 
Tipo de issues de no 
conformidad 
 
Proceso 
 
Producto 
 
Política 
 
Sistemas de Gestión II 
Métricas del software 
 
Página 22 de 42 
Revisión 3 
Indicadores: 
§ Seguimiento del número, tipo y prioridad de los ítems de acción registrados 
durante una revisión. 
§ Seguimiento de la proporción en la cual los ítems de acción están siendo 
realizados. 
 
Etapas del Ciclo de vida: todas. 
 
Usuarios: 
§ Gerente del proyecto de software 
§ Clientes 
§ Gerentes senior 
§ Personal de aseguramiento de la calidad 
§ Ingenieros de software 
 
Definiciones: 
Ítem de acción: Cualquier revisión de discrepancia, clarificación o issue que debe 
ser resuelta por el proyecto o el cliente. Un ítem de acción surge de revisiones 
formales con el cliente o de revisiones por pares. 
 
Entradas: 
§ Número de ítems de acción: 
o Total 
o Abiertos 
o Cerrados 
§ Para cada ítem de acción: 
o Fecha de apertura 
o Tipo (por ejemplo, cambio a la documentación, análisis adicional 
requerido, resolución de un tema “a determinar”, cambio al proceso). 
o Prioridad (ranking de la importancia relativa de cada ítem de acción). 
o Fecha de cierre. 
 
 
Interpretación: 
 
En el Nivel Definido la organización tiene sus procesos definidos y datos históricos 
para utilizar. Estos datos se pueden usar para predecir el tiempo que llevará 
determinada actividad. El Gerente de Proyecto puede usar los datos de proyectos 
anteriores y de revisiones anteriores del proyecto para predecir cuánto tiempo 
llevará cerrar un ítem de acción de determinada prioridad o tipo. Esta información 
puede ser obtenida determinando el tiempo promedio que los ítems de acción de 
cada prioridad o tipo de revisiones anteriores o proyectos similares permanecieron 
abiertos. La tabla de la figura 10 compara la performance de un proyecto para 
cumplir ítems de acción contra los promedios obtenidos de datos históricos. 
El proyecto está cumpliendo con los ítems de acción de menor prioridad más rápido 
que el promedio y se está comportando como un proyecto promedio con respecto a 
los ítems de acción de prioridad media. El proyecto está cumpliendo con los ítems 
de acción de todos los productos (todas las prioridades combinadas) más rápido 
que el promedio, pero no está comportándose tan bien con respecto a los ítems de 
acción relacionados a los procesos. 
 
Ítems de Acción Valor Promedio Valor en el proyecto (a 
la fecha) 
Prioridad del producto 
1 4 horas 3 horas 
2 4 horas 4 horas 
3 1 semana 1 semana 
Sistemas de Gestión II 
Métricas del software 
 
Página 23 de 42 
Revisión 3 
4 1 mes 3 semanas 
Todos los productos 9 días 7 días 
Todos los procesos 3 meses 3.5 meses 
 
Figura 10: Tiempo que los ítems de acción permanecen abiertos. 
 
5.4.3 Causas de problemas reportados. 
 
Objetivo: 
Proveer a los Gerentes de Software una visión de la calidad del producto, la 
confiabilidad del software y la efectividad del testing; y proveer al grupo de 
procesosde ingeniería de software información del proceso de desarrollo. 
 
Indicadores: 
§ Tendencias de: 
o Número, tipo y severidad de los problemas reportados. 
o Densidad de los reportes de problemas, esto es, el número de 
reportes de problemas por unidad de tamaño. 
o Proporción en la cual los reportes de problemas son corregidos. 
o Número de defectos en cada componente de software. 
 
§ Relación entre los números de problemas reportados y el número de casos 
de test pasados. 
 
Etapas del ciclo de vida: Test de integración y de aceptación. 
 
Usuarios: 
§ Gerente del proyecto de software. 
§ Personal de aseguramiento de la calidad del software. 
§ Gerente de testing. 
§ Gerentes de desarrollo de primera línea y de nivel medio. 
§ Grupo de procesos de ingeniería del software. 
Definiciones: 
CSCI: Ítem de configuración de software. Un ítem de configuración es un producto 
de trabajo cuya manipulación debe ser controlada: deben manejarse versiones, los 
cambios que se le realicen deben quedar registrados, se deben poder recuperar 
versiones anteriores, etc. Un ejemplo de esto puede ser el código fuente, o los 
documentos generados por el proceso de desarrollo tales como la Especificación de 
requerimientos. 
 
Entradas: 
§ Número de problemas reportados: 
o Total 
o Abiertos 
o Cerrados 
§ Número de casos de test : 
o Programados 
o Aprobados 
§ Tamaño del producto. 
§ Para cada reporte de problemas: 
o Fecha de apertura 
o Fecha de cierre. 
o Fecha de evaluación del problema reportado. 
o Tipo. 
o Severidad. 
o Tipo (categoría) de defecto. 
o Severidad del defecto. 
Sistemas de Gestión II 
Métricas del software 
 
Página 24 de 42 
Revisión 3 
o Identificación del producto. 
o Identificación del reporte de problema. 
o Fuente del problema. 
o Causa del defecto. 
o Etapa del ciclo de vida en la cual fue detectado el problema. 
o Actividad en la cual el defecto fue introducido. 
o Unidades afectadas por el defecto. 
 
Notar que alguna información requerida para cada reporte de problema sólo puede 
obtenerse luego de que el problema ha sido analizado y el problema reparado. 
 
 
Interpretación: 
 
El proyecto puede usar datos históricos para compararse contra proyectos similares 
y predecir el número de reportes de problemas esperado. 
La figura 11 compara el número total de reportes de problemas detectados contra 
el rango del promedio del total de reportes de problemas detectados por semana 
obtenido de los datos históricos. El gerente del proyecto de software necesita 
determinar porqué en la semana 7 este CSCI comenzó a exceder la norma. ¿El 
equipo de testeo pospuso el comienzo de los test más complejos?¿Decreció la 
calidad de los CSCI repentinamente?¿No fueron suficientes los test tempranos para 
detectar estos defectos?. En general, si el número de reportes de problemas excede 
el umbral superior, las posibles causas son: software poco confiable, 
requerimientos mal interpretados o software extremadamente complejo. Si el 
número de reportes de problemas es menor que el umbral inferior, las posibles 
causas son software confiable o testing inadecuado. 
 
La figura 12 es un ejemplo de lo que una organización puede hacer con datos 
históricos. Esta figura muestra el número de defectos detectados cada mil líneas de 
código fuente (KSLOC) para cada etapa del ciclo de vida del proyecto y el rango 
observado de los datos históricos. 
 
 
 
 
Figura 11: Número de problemas reportados comparado con el rango determinado de los datos 
históricos de proyectos similares por semana. 
 
 
 
Hoy 
Planeado 
Real 
Reportes de 
Problemas 
Semanas 
Sistemas de Gestión II 
Métricas del software 
 
Página 25 de 42 
Revisión 3 
 
 
 
 
Figura 12: Modelo de Proporción de Errores de un Laboratorio de Ingeniería de Software. 
 
 
 
Además de graficar el número total de reportes de problemas detectados por cada 
CSCI, el administrador del proyecto de software también mira los gráficos de los 
números de reportes de problemas abiertos y cerrados. Una forma de mirar está 
información es la de la figura 13. Esta figura, preparada para cada período de 
reporte, muestra por cuánto tiempo los reportes de problemas de una severidad 
determinada permanecieron abiertos. La figura indica qué tan rápidamente el 
equipo de desarrollo de software está solucionando los problemas de esta 
severidad. Si el tiempo se vuelve demasiado largo, el Gerente necesita saber y 
entender las razones. 
 
 
 
 
Figura 13: Duración de tiempo que permanecen abiertos los reportes de problemas de severidad X 
 
 
 
 
 
Planificación 
Errores 
por 
KSOLOC 
Semanas 
Número de 
reportes de 
problemas 
abiertos de 
severidad 
nivel X 
Sistemas de Gestión II 
Métricas del software 
 
Página 26 de 42 
Revisión 3 
 
La figura 14 muestra el número de reportes de problemas detectados por cada 
producto de trabajo del software. En este ejemplo, los CSCI son usados como 
productos de trabajo, pero el gráfico se puede hacer también por módulos, 
unidades, o componentes del software como productos de trabajo. 
Para que este gráfico sirva para productos de diferentes tamaños, el número de 
reportes de problemas debe ser normalizado, por ejemplo, el número de defectos 
detectado cada mil líneas de código. 
Sin importar cómo se decida realizar el gráfico, éste permite al gerente del proyecto 
de software hacer lo siguiente: 
o Comparar los datos de reportes de problemas de muchos productos de 
trabajo relacionados. 
o Identificar aquellos productos de trabajo que pueden requerir un análisis 
más profundo para determinar posibles problemas del producto o proceso 
que resultan en más reportes de problemas. 
o Identificar productos de trabajo en los cuáles estaban concentrados varios 
reportes de problemas. 
o Identificar productos de baja calidad. 
 
 
 
 
Figura 14: Número total de reportes de problemas por ítem de configuración de software. 
 
 
 
 
 
5.4.4 Resultado de Revisión por Pares 
 
El principio básico del proceso de revisión por pares es la de encontrar defectos en 
los productos medios de software y removerlos para que el producto final sea de 
alta calidad. 
Las mediciones sobre los datos de las revisiones por pares pueden proveer 
información sobre el número y tipo de defectos de encontrados. Estos datos 
documentan la eficiencia y eficacia de la revisión por pares y apuntan a problemas 
potenciales en el proceso usado para desarrollar el producto, además de identificar 
defectos en el producto. 
 
Objetivo: 
CSCI 
Número de 
reportes de 
problemas 
Sistemas de Gestión II 
Métricas del software 
 
Página 27 de 42 
Revisión 3 
§ Brindar a los gerentes de software y al personal de Aseguramiento de 
Calidad de Software una idea sobre la calidad del producto intermedio y 
final. 
§ Proveer a SEPG con una idea de los procesos de revisión por pares y 
desarrollo. 
 
Indicadores: 
§ Seguimiento de los siguientes puntos: 
o Número de defectos encontrados durante las revisiones por pares. 
o Tipo y severidad de los defectos. 
o Número de Re-Revisiones requeridas 
o Porcentaje de defectos que fueron tratados. 
o Número de defectos en cada componente de software. 
o Número de defectos en cada tipo de producto. 
o Eficiencia de la detección de defectos 
 
Etapa del ciclo de vida: todas. 
 
Usuarios: 
§ Gerentes de software. 
§ Personal de Aseguramiento de Calidad de Software. 
§ Grupo de procesos de Ingeniería de Software. 
 
 
Entradas: 
§ Por cada revisión por pares: 
o Tipo de revisión 
o Número de ítems revisados 
o Ítems de acción abiertos 
o Ítems de acción cerrados 
o Identificación del producto revisado 
o Tamaño del producto 
o Tiempo de preparación para cada revisión 
o Lead Time preparación 
o Duración de la revisión 
o Tamaño del grupo de revisión 
o Estructura del grupo de revisión 
o Número de defectos encontrados 
§ Por cada defec to 
o Severidad 
o Tipo 
o Esfuerzo dedicado al retrabajo 
o Etapa del ciclo de vida en el cual se introdujo en el producto 
o Número de unidadesafectados por el defecto 
o Número de unidades que incluyen el defecto 
 
• Número de revisiones por pares 
• Número de re-revisiones 
 
Interpretación: 
 
La figura 15 muestra el número de defectos abiertos y cerrados y el número total 
de defectos versus el tiempo. 
Durante la planificación del proyecto, el administrador estima el número de 
defectos esperado, en base a información histórica, y asegura que esa estimación 
es consistente con la estimación de costo y la planificación. 
Sistemas de Gestión II 
Métricas del software 
 
Página 28 de 42 
Revisión 3 
El número de defectos representa el retrabajo que se debe completar para que el 
producto sea entregado al cliente. Si el retrabajo no fue correctamente estimado va 
a existir un impacto en el costo y en la planificación. 
Idealmente, el número de defectos abiertos en cualquier momento debería ser 
cercano a cero. Si se desvía sustancialmente de cero o sigue creciendo, el gerente 
debe reevaluar la distribución de los recursos. Dependiendo de la severidad de los 
mismos el gerente puede poner personal a trabajar en esos defectos o continuar 
con la implementación. La figura 15 en conjunto con otras puede ayudar a tomar 
esa decisión. 
 
 
 
 
 
Figura 15: Número de defectos totales, abiertos y cerrados. 
 
 
La figura 16 muestra una vista alternativa de los datos. Provee una medida de la 
velocidad en la cual el grupo de desarrolladores está respondiendo a los defectos 
reportados. La figura muestra una tendencia de los desarrolladores a no dedicarse 
a la corrección de defectos. Después de la semana 3 la performance de los 
desarrolladores mejora con respecto a los defectos y se mantiene constante 
alrededor de 75 por ciento hasta la semana 7. Después de esta semana el equipo 
es bastante sensible a los defectos. 
 
Cuando analizamos la figura, el gerente debe estar informado sobre el tamaño de 
los cambios. Si la mayoría de los defectos requiere sólo un cambio menor en el 
producto, sólo un pequeño esfuerzo se puede necesitar para arreglarlos. 
 
 
Semanas 
Abiertos 
Cerrados 
Totales 
Defectos 
Sistemas de Gestión II 
Métricas del software 
 
Página 29 de 42 
Revisión 3 
 
 
 
Figura 16: Porcentaje de defectos cerrados. 
 
Luego de la finalización de una actividad del ciclo de vida, un análisis de Pareto 
puede ser realizado sobre los tipos de defectos descubiertos durante esa actividad. 
La figura 17 muestra un ejemplo de una distribución de posibles categorías de 
defectos para unidades de diseño de revisión. La figura puede usarse para 
determinar cuales categorías son la mayor fuente de defectos en un tipo de revisión 
determinado. En el ejemplo se observa que las fallas por no respetar los estándares 
es la categoría dominante seguida por los errores de interfaces. El personal de 
aseguramiento de calidad podría brindar un curso de repaso de los estándares de 
diseño de unidades, previo a la próxima actividad de diseño de unidades. Por otro 
lado el SEPG podría revisar el diseño del proceso para determinar si se puede 
disminuir de manera considerable el alto número de defectos de interfaces. 
 
 
 
 
 
 
Figura 17: Distribución de las categorías de defectos para revisiones de unidades de diseño. 
 
Semanas 
Defectos 
Cerrados 
(%) 
Número 
de 
defectos 
Violaciones 
de 
estándares 
Defectos de 
Interfaz 
Defectos de 
lógica 
Otros 
Sistemas de Gestión II 
Métricas del software 
 
Página 30 de 42 
Revisión 3 
La figura 18 muestra el número de defectos encontrados en cada producto de 
software (CSCI). Los datos están normalizados para brindar una densidad de los 
defectos para cada CSCI. 
 El gerente o el personal de aseguramiento de calidad usa la figura 18: 
§ Para comparar datos de defectos de múltiples trabajos de productos 
relacionados. 
§ Como una predicción de qué CSCI o componente de software es más 
probable que genere más reportes de problemas, requiera más testing o 
requiera más esfuerzo de mantenimiento. 
§ Para identificar esos trabajos de productos que requieran más análisis para 
identificar problemas de proceso o producto que causan un alto número de 
defectos. 
§ Para determinar un producto de trabajo que generó pocos defectos. Este 
producto puede merecer ser analizado, para determinar porqué tuvo menos 
defectos que los otros productos de trabajo. Si un proceso diferente fue 
usado, quizás este proceso puede ser usado para todos los productos. 
 
La figura muestra un límite superior en la densidad de defectos. Ese límite se basa 
en datos históricos o en metas de calidad que tiene el proyecto o la organización. 
En este ejemplo los gerentes o el personal de aseguramiento de calidad deben 
determinar el porque D tiene una baja densidad y E tiene un alta densidad de 
defectos. Una baja densidad de defectos inusual puede indicar una calidad alta del 
producto o una pobre calidad en el proceso de revisión por pares. 
 
 
 
 
Figura 18:Densidad de defectos por CSCI. 
 
La figura 19 muestra la densidad de defectos por cada etapa del ciclo de vida. Esta 
figura es un gráfico del número total de defectos detectados para un tipo particular 
de revisión por pares durante un desarrollo particular o versión dividida por el 
número de ese tipo de revisión realizada durante esa etapa del ciclo de vida. La 
figura muestra información sobre la efectividad de los distintos tipos de revisiones. 
Si la densidad de los defectos en menor en las etapas tempranas del ciclo de vida 
que en las últimas, el SEPG debe analizar el proceso de revisión por pares en las 
etapas tempranas ya que es deseable encontrar defectos en forma temprana. Una 
vez que hay datos históricos recolectados se pueden usar para estimar el número 
de defectos esperado. La detección de defectos tempranos en el ciclo de vida puede 
CSCI 
Defectos cada 
100 líneas de 
código 
Límite superior 
Sistemas de Gestión II 
Métricas del software 
 
Página 31 de 42 
Revisión 3 
indicar un proceso de software maduro o que el proyecto tiene personal con técnica 
y nivel de experiencia adecuado trabando en el mismo. 
 
 
 
 
 
 
 
 
 
Figura 19: Densidad de defectos por cada actividad del ciclo de vida de un proyecto. 
 
La figura 20 muestra el número de defectos de requerimientos detectados durante 
cada actividad del ciclo de vida. Si la mayoría de esos defectos son encontrados 
tarde en el ciclo de vida, el proceso de revisión por pares durante las etapas 
tempranas del proceso de definición de requerimientos debe ser mejorado. Figuras 
similares pueden ser graficadas para los defectos detectados durante el diseño y el 
código. La figura puede ser graficada también usando el porcentaje de defectos de 
requerimientos encontrados en cada etapa del ciclo de vida, manteniendo la misma 
interpretación. 
 
 
 
 
 
 
 
 
 
Figura 20: Densidad de defectos de requerimientos encontrados durante las revisiones por pares en 
diferentes actividades del ciclo de vida. 
Defectos por 
inspección 
Análisis 
de 
Requerim. 
Diseño Diseño 
Detallado 
De 
Unidad 
Codific. 
De 
unidad 
Testeo 
De 
unidad 
Integración 
y test 
Actividad del ciclo de vida 
Densidad 
de 
defectos 
Análisis 
de 
Requerim. 
Diseño Diseño 
Detallado 
De 
Unidad 
Codific. 
De 
unidad 
Testeo 
De 
unidad 
Integración 
y test 
Actividad del ciclo de vida 
Sistemas de Gestión II 
Métricas del software 
 
Página 32 de 42 
Revisión 3 
 
5.5 Estabilidad 
 
5.5.1 Número de cambios a requerimientos y aclaraciones de 
requerimientos con rangos. 
 
La falta de estabilidad en los requerimientos puede llevar a productos de baja 
calidad, incremento de los costos del proyecto y desvíos en la planificación del 
proyecto. 
 
Objetivo: 
Proveer al gerente del proyecto de software y al grupo de procesos de ingeniería de 
software (SEPG) visibilidad acerca de la naturaleza y magnitud de los cambios a 
requerimientos. 
 
Indicadores: 
§ Número total de: 
o Cambios a requerimientos 
o Cuestiones “a determinar” (TBD delinglés “to be determinated”). 
§ Número total de waivers de los requerimientos del contrato inicial. 
§ Tiempo de análisis y realización de los pedidos de cambio. 
§ Esfuerzo (horas) requerido para la implementación de los cambios. 
 
Etapas del ciclo de vida: Todas, es más importante durante el análisis de 
requerimientos y el diseño. 
 
Usuarios: 
§ Ingenieros de software para controlar y monitorear los requerimientos. 
§ Grupo de procesos de ingeniería de software para obtener fuentes y razones 
de intestabilidad. 
§ Gerente del proyecto de software. 
 
Entradas: 
§ Número total de requerimientos. 
§ Número de cambios a los requerimientos: 
o Propuestos 
o Abiertos 
o Aprobados 
o Incorporados a la línea base 
§ Por cada cambio a los requerimientos: 
o El ítem de configuración de software (CSCI) afectado. 
o La fuente del pedido (cliente, ingeniero de software, etc.) 
o Tipo de requerimiento (funcional, performance, etc.) 
§ Número de TBD (“a determinar”) en las especificaciones de requerimientos. 
§ Número de requerimientos programados para cada versión o release del 
software. 
§ Fecha del cambio a requerimiento. 
§ Fecha de la aprobación del cambio a requerimiento. 
§ Esfuerzo y costo para analizar el cambio propuesto y para llegar a un 
acuerdo. 
§ Tamaño y costo de implementar el test, incluyendo estimación inicial y 
valores reales (para cambios mayores solamente). 
 
Interpretación: 
 
La Figura 21 muestra el número de cambios a requerimientos y el rango de 
cambios a requerimientos observados en el pasado, en proyectos similares. 
Sistemas de Gestión II 
Métricas del software 
 
Página 33 de 42 
Revisión 3 
Idealmente, el número de cambios a requerimientos disminuye mientras el 
proyecto avanza a través del ciclo de vida. 
El gerente del proyecto de software puede realizar un seguimiento del 
comportamiento del proceso comparado con proyectos similares anteriores. Si el 
proyecto cae fuera de los rangos, el gerente deberá determinar las causas. 
La información que provee este indicador se puede utilizar junto con los indicadores 
de costo y esfuerzo para verificar las estimaciones realizadas. Cuando analiza este 
gráfico, el gerente del proyecto debe ser conciente del tamaño de cada cambio. Un 
solo cambio puede tener un gran impacto en el costo, esfuerzo y planificación, 
mientras que muchos cambios a requerimientos pequeños pueden tener muy poco 
impacto en costo, esfuerzo y planificación. 
 
 
 
 
 
Figura 21: Número total de cambios a requerimientos. 
 
 
La figura 22 muestra el número total de cambios a requerimientos aprobados hasta 
la fecha y los separa en tipo de requerimiento. El gerente del proyecto, el SEPG, o 
el personal de ingeniería de software puede determinar qué tipo de requerimiento 
es dominante. Si el gráfico muestra que la mayoría de los cambios se deben a un 
solo tipo de requerimiento, entonces la causa necesita ser determinada. Los tipos 
de requerimientos del gráfico fueron elegidos como representativos y no están 
completos. 
 
 
 
Planeado 
 
Real 
Meses 
Cambios a 
requerimientos 
SDR: Revisión del diseño del sistema. 
SSR: Revisión de la especificación del 
software. 
PDR: Revisión del diseño preliminar. 
CDR: Revisión del diseño crítico. 
Sistemas de Gestión II 
Métricas del software 
 
Página 34 de 42 
Revisión 3 
 
 
 
Figura 22: Número total de cambios a requerimientos y número de cambios por tipo de requerimiento. 
 
 
 
5.6 Entrenamiento 
 
5.6.1 Número de clases ofrecidas real vs. Estimado. 
 
Un staff entrenado es un activo importante para el gerente del proyecto de 
software. El gerente debe asegurar que el staff tiene las habilidades y 
conocimientos necesarios para realizar sus tareas asignadas. 
 
Objetivo: 
Proveer a los gerentes una visión del proceso de entrenamiento, para asegurar la 
utilización efectiva del entrenamiento y para proveer a los gerentes con una medida 
de las habilidades de su equipo de trabajo. 
 
Indicadores: 
§ Desviación en: 
o Número de clases dadas vs. Número de clases planificadas. 
o Asistencia real vs. Asistencia planificada 
§ Calidad del programa de entrenamiento. 
 
Etapas del ciclo de vida: todas. 
 
Usuarios: 
§ Gerente del proyecto de software para lo particular del proyecto. 
§ Gerencias senior para los costos consolidados del programa de 
entrenamiento de la organización. 
§ SEPG para evaluar si el programa de entrenamiento es apropiado y efectivo. 
 
Definiciones: 
Curso: dictado de un tema en particular, por ejemplo, análisis de requerimientos. 
Meses 
Cambios a 
Requerimientos 
aprobados 
SDR: Revisión del diseño 
del sistema. 
SSR: Revisión de la 
especificación del 
software. 
PDR: Revisión del diseño 
preliminar. 
CDR: Revisión del diseño 
crítico. 
Interface 
Funcionales 
Sistemas de Gestión II 
Métricas del software 
 
Página 35 de 42 
Revisión 3 
Clase: Número de veces que se dicta determinado curso. Por ejemp lo, puede haber 
sólo un curso de análisis de requerimientos, pero hay seis clases en un mes para 
ese curso (es decir, el curso se dicta 6 veces en un mes). 
 
Entradas: 
§ Planes de entrenamiento. 
§ Número de clases dadas. 
§ Registros de asistencia. 
§ Tipo de personal entrenado (por ejemplo técnico, personal de soporte, 
gerentes). 
§ Resultados del entrenamiento. 
 
Interpretación: 
La figura 23 muestra el número planificado de clases ofrecidas versus el número 
real ofrecido en un período. Existirá un gráfico para cada curso. La desviación del 
plan puede indicar la falta de un plan detallado, o compromiso con el plan de 
entrenamiento. La desviación también puede reflejar la falta de instructores 
disponibles, o un número insuficiente de estudiantes que requieren el curso. 
La figura 24 muestra la asistencia real versus la planificada. Existirá un gráfico para 
cada curso. La desviación del plan puede indicar la falta de recursos o interés de los 
participantes. 
 
 
 
 
Figura 23: Número de clases ofrecidas cada mes. 
 
 
 
 
 
 
 
Planeado 
Real 
Hoy 
Meses 
Clases 
Sistemas de Gestión II 
Métricas del software 
 
Página 36 de 42 
Revisión 3 
 
 
 
Figura 24: Asistencia total 
 
 
 
5.7 Performance del proceso 
 
5.7.1 Número de cambios al proceso. 
 
Un gran número de pedidos de cambios al proceso indica que el proceso no es tan 
eficiente como se cree o que no es apropiado para el proyecto. 
 
Objetivo: 
Proveer un valor de la estabilidad del proceso definido y proveer al SEPG con una 
idea de la calidad del proceso definido. 
 
Indicadores: 
Seguimiento del número de: 
§ Pedidos de cambio al proceso de software. 
§ Waivers a los requerimientos del proceso de software. 
 
Etapas del ciclo de vida: todas. 
 
Usuarios: 
§ Gerente del proceso de software. 
§ SEPG. 
§ Gerentes senior. 
 
Entradas: 
§ Plan de proceso 
§ Pedidos de cambio al proceso: 
o Cantidad de abiertos 
o Cantidad de aprobados 
o Cantidad de rechazados 
o Cantidad de incorporados 
§ Para cada cambio a proceso: 
Real 
Hoy 
Meses 
Asistencia 
Sistemas de Gestión II 
Métricas del software 
 
Página 37 de 42 
Revisión 3 
o Fuente del pedido (grupo, departamento, etc.) 
o Impacto del pedido (por ejemplo menor o mayor). 
 
Interpretación: 
La figura 25 muestra el número total de pedidos de cambios y el número de 
pedidos aprobados para un período determinado. Un número alto de pedidos de 
cambios indica que el personal no comprende lo suficiente el proceso o que el 
proceso estándar es inapropiado y debe ser revisado. Un número alto de pedidos de 
cambio aprobados indica que el proceso es inestable. 
En el gráfico no se muestran los pedidos que fueron aprobados pero no 
incorporados. Los cambios a procesos deben ser cuidadosamente administrados, 
como los cambios a requerimientos. Una vez que un cambio a requerimiento es 
aprobado, debe realizarse una planific ación apropiada para introducir el cambio. 
 
 
 
 
Figura 25: Pedidos de cambio al proceso 
 
5.8 Satisfacción del cliente 
 
5.8.1 Porcentaje de clientes satisfechose insatisfechos. 
 
Objetivo: 
Proveer a los Gerentes Senior y a la Gerencia General una visión de cómo los 
clientes perciben el nivel de los productos y servicios brindados por la empresa. 
 
Indicadores: 
§ Porcentaje de Clientes Satisfechos vs. Porcentaje de Clientes Insatisfechos. 
§ Número de clientes insatisfechos por causa. 
 
Etapas del Ciclo de vida: todas 
 
 
Usuarios: 
§ Gerentes senior para evaluar el desempeño de su sector. 
§ Gerente General para evaluar el desempeño de toda la organización. 
 
Pedidos de 
cambio 
Cambios 
aprobados 
Pedidos de 
cambio al 
proceso 
Meses 
Sistemas de Gestión II 
Métricas del software 
 
Página 38 de 42 
Revisión 3 
Entradas: 
§ Resultado de las encuestas de satisfacción. 
§ Definición de cliente (por ejemplo: todos aquellos que tengan hayan 
utilizado los servicios de la empresa durante el último año, y que no tengan 
proyectos vigentes en la actualidad). 
 
Interpretación: 
 
Este indicador permite monitorear el nivel de satisfacción de los clientes de la 
empresa con respecto a diferentes aspectos de sus productos y servicios. Es 
fundamental que el valor de este indicador aumente mes a mes, lo que dará una 
visión de la mejora continua de los procesos. 
Para obtener este valor, se puede realizar una encuesta telefónica o en persona a la 
cantidad de clientes que la empresa determine, siempre teniendo en cuenta que la 
muestra sea representativa del total de los clientes. También puede optarse por 
encuestar a todos los clientes definidos como tales. 
La figura 26 muestra el porcentaje de clientes satisfechos vs. El porcentaje de 
clientes insatisfechos para las encuestas realizadas en diciembre de 2005. 
La figura 27 muestra la tendencia del porcentaje de clientes satisfechos. Si esta 
tendencia es descendente, deben analizarse las causas y tomar acciones para 
revertir la situación. 
La figura 28 muestra la cantidad de clientes insatisfechos por causa. Si el gráfico 
muestra una causa que predomina sobre las demás, el Gerente debe tomar las 
acciones correspondientes para eliminar el problema. Las causas presentadas son 
sólo una selección de las posibles. 
 
 
Figura 26: porcentaje de clientes satisfechos vs. porcentaje de clientes insatisfechos (diciembre 2005) 
 
62
64
66
68
70
72
74
76
78
80
jun
-0
3
se
p-
03
dic
-0
3
ma
r-0
4
jun
-0
4
se
p-
04
dic
-0
4
ma
r-0
5
jun
-0
5
se
p-
05
dic
-0
5
 
Figura 27: Porcentaje de clientes satisfechos 
 
 
Satisfechos 
78% 
Insatisfechos 
22% Tamaño muestral: 100 
clientes 
Sistemas de Gestión II 
Métricas del software 
 
Página 39 de 42 
Revisión 3 
0
1
2
3
4
5
6
7
8
9
T
ie
m
p
o
s 
d
e
e
n
tr
e
g
a
E
rr
o
re
s 
e
n
 e
l
p
ro
d
u
ct
o
C
o
n
o
ci
m
ie
n
to
s
d
e
l 
p
e
rs
o
n
a
l
S
e
rv
ic
io
P
o
st
ve
n
ta
P
re
ci
o
 d
e
l
p
ro
d
u
ct
o
 
Figura 28: Cantidad de clientes insatisfechos por causa 
 
Sistemas de Gestión II 
Métricas del software 
 
Página 40 de 42 
Revisión 3 
6. Glosario 
 
CPTP: Costo Presupuestado para el Trabajo Programado. Es el costo estimado de 
todas las actividades que se deberían haber realizado en el proyecto al día de hoy. 
 
CPTR: Costo Presupuestado para el Trabajo Realizado. Es el costo estimado de 
todas las actividades que efectivamente se realizaron en el proyecto al día de hoy 
(pueden ser menos actividades que las programadas o actividades diferentes). 
 
CRTR: Costo Real del Trabajo Realizado. Es el costo real de todas las actividades 
que efectivamente se realizaron en el proyecto al día de hoy (pueden ser menos 
actividades que las programadas o actividades diferentes). 
 
CSCI: Véase Ítem de configuración de software. 
 
Esfuerzo: cantidad de horas que insume la realización de una tarea. 
 
Indicador: es una representación de datos de mediciones que provee una idea del 
proceso de desarrollo de software y/o de las actividades de mejora de procesos. 
 
Issue: asunto a resolver, problema del proyecto. Por ejemplo: se detecta a través 
de un indicador que hay un desvío en esfuerzo del 40% en un proyecto. Esto debe 
tratarse como un issue del proyecto: buscar la causa raíz, implementar una 
solución y realizar un seguimiento del issue hasta su clausura. 
 
Ítem de Acción: Cualquier revisión de discrepancia, clarificación o issue que debe 
ser resuelta por el proyecto o el cliente. Un ítem de acción surge de revisiones 
formales con el cliente o de revisiones por pares. 
 
Ítem de Configuración: Un ítem de configuración es un producto de trabajo cuya 
manipulación debe ser controlada: deben manejarse versiones, los cambios que se 
le realicen deben quedar registrados, se deben poder recuperar versiones 
anteriores, etc. Un ejemplo de esto puede ser el código fuente, o los documentos 
generados por el proceso de desarrollo tales como la Especificación de 
requerimientos. 
 
Línea Base: el paquete de datos técnicos inicial (incluyendo el código fuente). 
 
Medición: El acto o proceso de medir algo. También puede ser un resultado, tal 
como una figura expresando la extensión o valor que es obtenido al medir. 
 
Medida: Una unidad o estándar de medición / la extensión, dimensiones, 
capacidad, etc. de algo relacionado a un estándar / un acto o proceso de medición / 
un resultado de una medición. 
 
Medir: Determinar la cantidad, volumen, extensión o grado de algo en términos de 
una unidad estándar o monto fijo, usualmente a través de un instrumento o 
proceso. 
 
Métrica: En este documento, métrica es usado como sinónimo de medida. 
 
Paquete de datos técnico: Un conjunto de items que puede incluir lo siguiente (si 
esa información es apropiada para el tipo de producto o componente de producto: 
§ Descripción de la arquitectura del producto 
§ Requerimientos 
§ Descripciones de componentes del producto 
§ Descripciones de ciclos de vida relacionados al producto 
Sistemas de Gestión II 
Métricas del software 
 
Página 41 de 42 
Revisión 3 
§ Características clave del producto 
§ Características físicas requeridas y restricciones. 
§ Requerimientos de interfaz. 
§ Criterio de verificación para asegurar que los requerimientos han sido 
cumplidos. 
§ Condiciones de uso (ambientes) y escenarios de operación/uso. 
§ Razonamiento para decisiones y características (requerimientos, decisiones 
de diseño, etc.) 
 
Producto: Producto final a entregar (software o sistema terminado). 
 
Producto de trabajo: toda documentación o producto intermedio generado 
durante el proceso de desarrollo, por ejemplo la Especificación de Requerimientos, 
o la documentación del diseño del sistema. 
 
Progreso: Días insumidos en la realización de una tarea. 
 
SEPG: Grupo de procesos de ingeniería de software. Grupo de especialistas que 
realiza la definición y mejora de los procesos de software usados por la 
organización. 
 
Waivers: renuncia, concesión. Algo que se permite eliminar o no hacer como 
excepción. 
Sistemas de Gestión II 
Métricas del software 
 
Página 42 de 42 
Revisión 3 
Fuentes 
- Baumert, John y McWhinney Mark: “Software Measure and the Capability 
Maturity Model”. Software Engineering Institute, 1992. 
- “The rational Edge”: edición de enero de 2003. www.therationaledge.com 
- Zemel, Tami: “Software and systems measurement according to de PSM 
Approach”. 
- Softeare Engineering Institute. “Capability Maturity Model® Integration 
(CMMISM)”, Versión 1.1. Staged Representation. 
- Polo Tecnológico Rosario: “Curso introductorio CMMI”, 2003. 
- Alejandra Gonzalez, Diego Tartarelli, Viviana Colombo: “CMMI en Argentina”. 33 
JAIIO. Concurso de trabajos estudiantiles EST 2004. Categoría Trabajos de 
Cátedra. Área Ingeniería de software.