MetricasSoftware - Gloria Mendoza

Vista previa del material en texto

Sistemas de Gestión II
Métricas del Software
Trabajo Realizado por:
Melina Potenza
Rubén Muccilli
Docentes:
Est. Mónica Grasso
Ing. Cristian Bigatti
2
Agenda
Acerca de CMMI
Introducción a las mediciones
Clasificación de indicadores
Desarrollo de algunos indicadores
3
Acerca de CMMI – Enfoque en 
procesos
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. Existen 3 dimensiones 
críticas: los procesos, las personas y la 
tecnología. 
Los procesos son el mayor determinante de 
costos, tiempo y calidad, y son los que 
realmente permiten “independizarse” de las 
personas. 
4
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”.
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.
5
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.
6
¿Qué es CMMI?
Capability Maturity Model Integration
(Modelo de Madurez de Capacidades 
Integrado) 
Es un modelo de referencia sobre prácticas 
maduras de una 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.
7
Estructura de CMMI 
(Representación por niveles)
Nivel de Madurez
Área de Proceso 1 Área de Proceso m
Área de Proceso n
Objetivos 
Genéricos
Objetivos
Específicos
Prácticas 
Genéricas
Prácticas 
Específicas
8
Niveles de madurez
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.
9
Nivel 1 – Inicial o realizado
Ausencia de gerencia de proyectos. 
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.
10
Nivel 2 - Administrado
La organización establece políticas para 
gerenciar los proyectos de software y 
procedimientos para implantar estas 
políticas.
Los procesos de software son estables y 
repetibles.
Existen estándares de desarrollo 
definidos y exigidos.
La calidad es controlada.
11
Nivel 3 - Definido
Los procesos de software son definidos, 
estandarizados, documentados e 
institucionalizados.
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.
12
Nivel 4 – 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.
13
Nivel 5 - Optimizado
La organización identifica las debilidades 
y fortalezas de su proceso y determina 
maneras de mejorar su capacidad. 
Se incorporan nuevas tecnologías y 
métodos para mejorar los procesos.
14
Introducción a las mediciones: 
Algunas definiciones
Indicador: 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.
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: sinónimo de medida.
15
Usuarios de las mediciones
Administración 
Senior
(visibilidad)
Administradores 
del proyecto de 
Software
(Planeación y 
Control)
Indicadores 
del software
Clientes
(Seguimiento)
Comunidad de 
investigación
(investigaciones)
Grupo de Procesos 
de Ing. Del Software
(mejora)
Internos al proyecto Externos al proyecto
16
Clasificación de indicadores
Progreso: Provee información de cuan 
bien el 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. 
17
Clasificación de indicadores 
(cont.)
Costo: Provee el seguimiento de los 
costos reales versus los costos 
estimados y provee estimaciones de los 
costos de los proyectos futuros. 
18
Clasificación de indicadores 
(cont.)
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. 
19
Clasificación de indicadores 
(cont.)
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. 
20
Clasificación de indicadores 
(cont.)
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. 
21
Clasificación de indicadores 
(cont.)
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. 
22
Clasificación de indicadores 
(cont.)
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. 
23
Desarrollo de Indicadores
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.
Ejemplo: Supongamos que una empresa de software quiere 
monitorear el desvío entre los tiempos estimadosy 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%. 
24
Categoría: PROGRESO
Proporción de tiempo de retrabajo
sobre el tiempo total de cada 
proyecto 
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ó. 
25
Proporción del tiempo de 
retrabajo… (cont.)
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. 
26
Proporción de tiempo insumido en 
actividades de retrabajo para varios 
proyectos, con límites de control. 
Pr
o
p
o
rc
ió
n
 d
e 
re
tr
ab
aj
o
so
b
re
 
ti
em
p
o
 t
o
ta
l
Meses
27
Proporción del tiempo de 
retrabajo… (cont.)
Interpretación
Cada punto representa el nivel de retrabajo de un 
proyecto cerrado en ese mes.
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. 
La tendencia indica que los procedimientos son 
efectivos.
Mes 8: se establecen nuevos límites de control 
(provisorios hasta tener más datos) 
28
Proporción de tiempo de retrabajo
sobre el tiempo total de cada 
proyecto 
Categoría: ESFUERZO
Al igual que los indicadores de Progreso, estos indicadores sirven para 
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. 
29
Pr
o
p
o
rc
ió
n
 d
e 
re
tr
ab
aj
o
so
b
re
 
ti
em
p
o
 t
o
ta
l
Meses
Proporción de tiempo insumido en 
actividades de retrabajo para varios 
proyectos, con límites de control. 
30
Proporción del tiempo de 
retrabajo… (cont.)
Interpretación
La figura 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.
El eje y es la proporción de esfuerzo insumido en 
retrabajo sobre el esfuerzo total del proyecto. Cada 
punto en el diagrama es un proyecto que se completó 
en ese mes. 
31
Categoría: COSTO
Costo real vs. estimado con 
límites de control 
Objetivo: Realizar el seguimiento de los costos 
reales contra el plan de proyecto y presupuestar el 
costo de futuros proyectos.
El administrador del proyecto de software usa 
datos históricos y cálculos estadísticos para 
establecer los límites de control 
32
Costo real vs. Estimado (cont.)
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).
33
CPTP
CPTR
CRTR
Meses
Reporte de estado de costo/cronograma mostrando 
el rango permitido para el costo presupuestado 
del trabajo programado.
Costo 
($1K)
34
Costo real vs. Estimado (cont.)
Interpretación:
La performance del costo a la fecha es favorable, 
ya que el CRTR es menor que el CPTR.
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. 
35
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. 
El objetivo de este indicador es 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.
Estado de los issues de no 
conformidades 
Categoría: CALIDAD
36
Estado de los issues de no 
conformidades (cont.) 
Proceso Producto Política
Número 
de issues 
de no 
conformi
dad
Tipo de issues de no conformidad
37
Estado de los issues de no 
conformidades (cont.) 
Interpretación:
La figura 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. 
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 encontradas en las 
auditorías y analizadas posteriormente por el SEPG, para 
determinar causas de problemas recurrentes y mejorar los 
procesos.
38
Categoría: CALIDAD
Resultado de revisiones 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 
39
Distribución de las categorías de 
defectos para revisiones de 
unidades de diseño.
Número 
de 
defectos
Violaciones 
de 
estándares
Defectos 
de 
Interfaz
Defectos 
de lógica
Otros
40
Distribución de las categorías de 
defectos para revisiones de unidades 
de diseño - Interpretación.
La figura 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 la calidad debería tomar acciones para disminuir 
este tipo de defectos (por ej. Brindar una capacitación 
sobre estándares de diseño).
41
Densidad de defectos por cada 
actividad del ciclo de vida de un 
proyecto.
0 1 2 3 4 5
Análisis de requerimientos
Diseño
Diseño detallado de unidad
Codificación de unidad
Testeo de unidad
Integración y test
Actividad 
del ciclo 
de vida
42
Densidad de defectos por cada 
actividad del ciclo de vida de un 
proyecto - Interpretación
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. 
43
Número de cambios a 
requerimientos y aclaraciones de 
requerimientos con rangos. 
Categoría: ESTABILIDAD
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. 
El objetivo de este indicador es proveer al gerente del 
proyecto de softwarey al grupo de procesos de ingeniería 
de software (SEPG) visibilidad acerca de la naturaleza y 
magnitud de los cambios a requerimientos.
44
Número total de cambios a requerimientos 
y número de cambios por tipo de 
requerimiento. 
C
am
b
io
s 
a 
R
eq
u
er
im
ie
n
to
s 
ap
ro
b
ad
o
s
Meses
45
Número de cambios a 
requerimientos… (cont.)
Interpretación:
La figura 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. 
46
Número de clases ofrecidas real 
vs. Estimado.
Categoría: ENTRENAMIENTO
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. 
El objetivo de este indicador es 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.
47
Número de clases ofrecidas 
cada mes
Clases
Meses
48
Número de clases ofrecidas real 
vs. Estimado (cont.)
Interpretación:
La figura 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 
recursos, o un número insuficiente de estudiantes 
que requieren el curso.
49
Número de cambios al proceso
Categoría: PERFORMANCE DEL 
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. 
El objetivo de este indicador es proveer un 
valor de la estabilidad del proceso definido y 
proveer al SEPG con una idea de la calidad 
del proceso definido.
50
Número de cambios al 
proceso (cont.)
Pedidos de 
cambio
Cambios 
aprobados
Pedidos 
de 
cambio 
al
proceso
Meses
51
Número de cambios al 
proceso (cont.)
Interpretación:
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. 
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 planificación apropiada para introducir el cambio.
52
Porcentaje de clientes satisfechos 
e insatisfechos. 
Categoría: SATISFACCIÓN DEL 
CLIENTE
El objetivo de este indicador es 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.
53
Porcentaje de clientes 
insatisfechos
62
64
66
68
70
72
74
76
78
80
ju
n-
03
se
p-
03
di
c-
03
m
ar
-0
4
ju
n-
04
se
p-
04
di
c-
04
m
ar
-0
5
ju
n-
05
se
p-
05
di
c-
05
54
Cantidad de clientes 
insatisfechos por causa
0
1
2
3
4
5
6
7
8
9
Tiempos de
entrega
Errores en el
producto
Conocimientos
del personal
Precio del
producto
Servicio
Postventa
0,00
20,00
40,00
60,00
80,00
100,00
120,00
55
Porcentaje de clientes satisfechos 
e insatisfechos - Interpretación
La primer figura 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 segunda figura, 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.
56
Conclusiones
Los indicadores vistos son solamente ejemplos, 
cada empresa debe seleccionar las variables 
que le sean útiles para poder gerenciar sus 
procesos y proyectos. 
Seleccionar dichas variables, es el punto más 
difícil del proceso de medición. Recordar 
siempre “mantenerlo simple”.
Sin datos fieles es imposible conocer el estado 
de nuestros procesos y proyectos (dijo Demming
“En Dios confío, los demás muéstreme datos”).
57
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.
Gonzalez, Alejandra, Tartarelli, Diego, Colombo, Viviana: “CMMI 
en Argentina”. 33 JAIIO. Concurso de trabajos estudiantiles EST 
2004. Categoría Trabajos de Cátedra. Área Ingeniería de 
software.
http://www.therationaledge.com/
http://www.therationaledge.com/
	Sistemas de Gestión IIMétricas del Software
	Agenda
	Acerca de CMMI – Enfoque en procesos
	Premisa de la mejora de procesos
	La importancia de un modelo
	¿Qué es CMMI?
	Estructura de CMMI (Representación por niveles)
	Niveles de madurez
	Nivel 1 – Inicial o realizado
	Nivel 2 - Administrado
	Nivel 3 - Definido
	Nivel 4 – Cuantitativamente administrado
	Nivel 5 - Optimizado
	Introducción a las mediciones: Algunas definiciones
	Usuarios de las mediciones
	Clasificación de indicadores
	Clasificación de indicadores (cont.)
	Clasificación de indicadores (cont.)
	Clasificación de indicadores (cont.)
	Clasificación de indicadores (cont.)
	Clasificación de indicadores (cont.)
	Clasificación de indicadores (cont.)
	Desarrollo de Indicadores
	Proporción de tiempo de retrabajo sobre el tiempo total de cada proyecto
	Proporción del tiempo de retrabajo… (cont.)
	Proporción de tiempo insumido en actividades de retrabajo para varios proyectos, con límites de control.
	Proporción del tiempo de retrabajo… (cont.)
	Proporción de tiempo de retrabajo sobre el tiempo total de cada proyecto
	Proporción del tiempo de retrabajo… (cont.)
	Costo real vs. estimado con límites de control
	Costo real vs. Estimado (cont.)
	Costo real vs. Estimado (cont.)
	Estado de los issues de no conformidades
	Estado de los issues de no conformidades (cont.)
	Estado de los issues de no conformidades (cont.)
	Resultado de revisiones por pares
	Distribución de las categorías de defectos para revisiones de unidades de diseño.
	Densidad de defectos por cada actividad del ciclo de vida de un proyecto.
	Densidad de defectos por cada actividad del ciclo de vida de un proyecto - Interpretación
	Número de cambios a requerimientos y aclaraciones de requerimientos con rangos.
	Número total de cambios a requerimientos y número de cambios por tipo de requerimiento.
	Número de cambios a requerimientos… (cont.)
	Número de clases ofrecidas real vs. Estimado.
	Número de clases ofrecidas cada mes
	Número de clases ofrecidas real vs. Estimado (cont.)
	Número de cambios al proceso
	Número de cambios al proceso (cont.)
	Número de cambios al proceso (cont.)
	Porcentaje de clientes satisfechos e insatisfechos.
	Porcentaje de clientes insatisfechos
	Cantidad de clientes insatisfechos por causa
	Porcentaje de clientes satisfechos e insatisfechos - Interpretación
	Conclusiones
	Fuentes