Un enfoque practico para las métricas de software

¿Cuáles son los beneficios de usar métricas? ¿Como se implementa un nuevo

programa de métricas o se mejoran los actuales? y ¿Qué debería hacer con los datos una
vez obtenidos? Estas son algunas preguntas que se hacen los managers de IT cuando
consideran las métricas de software. Hay muchas buenas razones para mantener
métricas en los proyectos software sin embargo muchos programas hacen que los
managers pierdan el foco o terminen “midiendo por el simple hecho de medir”.
Las métricas de software son unidades cuantitativas de medida para varios
aspectos de los proyectos de software. Un programa de métricas bien diseñado ayudará
a las decisiones que debe tomar el management y mejorara el retorno de la inversion
que se hace en IT. Hay muchos aspectos de los proyectos de software que pueden ser
medidos, pero no vale la pena medir todos.
Iniciar un nuevo programa de métricas o mejorar el actual consiste en 5 pasos:
 Identificar los objetivos de negocio.
 Elegir las métricas.
 Recolectar datos historicos.
 Automatizar los procesos de medición.
 Usar las métricas para tomar decisiones.

Identificar los objetivos de negocio

De los cinco pasos, la identificación de los objetivos de negocio es el más
importante. Los objetivos bien definidos nos permitirán:
 Habilitar un programa de métricas para mejorar los resultados del
negocio.
 Reducir el costo al mantener el programa bien definido y bien
encaminado.
 Asegurar una base para mejorar el retorno de la inversión en IT.
Puede ser difícil ganar adeptos a las métricas, especialmente cuando hay
managers no técnicos involucrados en la toma de decisiones. Por ejemplo, si tu CEO
pregunta por que debe invertir en algo que no es producir más software, quizás no te
ayude decir que la mayoría de las organizaciones de software lo hacen y que parece una
buena idea. En lugar de eso, deberías estar preparado para decir algo como: “Las
métricas de software nos van a ayudar a reducir la cantidad de fallas reportadas en los
sistemas al 25% sin incrementar los tiempos de desarrollo. De esta forma nos
ahorraremos el 150% de la inversión en el primer año”. Teniendo un fundamento así, es
mucho mas probable que convenzas a un manager de invertir en métricas de software.
En este fundamento es donde aparecen los objetivos del negocio. Concentrarse
en los objetivos del negocio ayudará a vender las métricas de software. El primer paso
es identificar objetivos de negocio relevantes. Algunas compañías publican objetivos de
negocio para el año actual. Algunos CIOs o vice presidentes de ingeniería traducirán
estos objetivos en metas para el área. Si no sabes los objetivos de tu compañía
pregúntales a los managers seniors. Si te es difícil encontrar objetivos de negocio que
pueden ser alcanzados usando métricas, proponé algunos. El cuadro “Objetivos
Comunes del negocio IT” da algunas
sugerencias.
Objetivos comunes del negocio IT
 Mejorar la calidad del software instalado
Elegir las métricas  Hacer compromisos factibles.
Una vez identificados los  Reducir los costos post instalación.
objetivos del negocio, el siguiente paso  Prevenir excesos en los costos y tiempos.
es elegir las métricas que lo soporten.  Hacer más con la misma cantidad de gente.
Las métricas a continuación son un  Estimar más rápido.
buen lugar para empezar, aunque hay  Entregar productos más rápido
otras métricas que pueden usarse y
quizás sean más apropiadas para tu organización.

Métricas de cronograma
Estos datos pueden ayudarte a prevenir excesos en los tiempos y costos al
proveer avisos anticipados de problemas con el cronograma. Estas métricas pueden
incluir medidas como el número de tareas terminadas tarde, y el número de tareas
replanificadas.

Métricas de requerimientos
Estos datos pueden servir como un indicador de excesos en los tiempos y costos.
Incluyen medidas de la cantidad o porcentaje de requerimientos cambiados y la cantidad
o el porcentaje de nuevos requerimientos. Requiere un procedimiento formal de pedidos
de cambios para capturar los datos apropiados.

Porcentaje cubierto por el testing

Esta métrica describa la cantidad de líneas de código “cubiertas” por el testing.
Varios estudios muestran que si no se usa esta métrica el testing solo cubre entre el 50 y
el 60 por ciento del código, dejando una gran cantidad de código con posibles fallas.
Probar midiendo y realizando un seguimiento de lo que se cubre con el testing puede
motivar la creación de nuevos casos de prueba que harán que se pruebe el 90% del
código. Resultando asi, en que se detectan más fallas por los testers que por los
usuarios. Arreglar estos errores antes de la instalación puede mejorar dramáticamente la
calidad del software y reducir los costos de soporte.

Tamaño del software

En un proyecto el tamaño del software nos lleva a una duración del calendario, a
un esfuerzo y a un costo. Las líneas de código y los puntos de función son las métricas
de tamaño más usadas, aunque también hay muchas unidades de medida orientadas a
objetos. Las líneas de código le permiten al management hacer proyecciones top-down
precisas y se recomienda para las mayorías de las organizaciones de IT. Los puntos de
función permiten proyecciones más efectivas para el esfuerzo y el costo, pero son
mucho mas difíciles de calcular y requieren experiencia.
Las líneas de código deben ser contadas excluyendo las líneas comentadas; a
esta medida se la llama líneas de código no comentadas (NCSS, por noncomment
source statements), o miles de líneas de código no comentadas (KNCSS). Muchas reglas
estomacales expresan la productividad de un programador en líneas de código, por
ejemplo 350 NCSS por mes hombre. Las estimaciones para un proyecto nuevo pueden
ser hechas de forma rapida usando una estimacion para la cantidad de NCSS y esa regla
estomacal. Los NCSS a ser desarrollados pueden ser estimados basandose en datos
históricos de proyectos anteriores. Medir la productividad de un programado, y realizar
acciones para mejorarla, puede ayudar a una organización a hacer más con la misma
cantidad de gente.

Densidad de fallas

La cantidad de fallas no resultas por KNCSS es la unidad de medida básica para

medir calidad. Algunas organizaciones definen estándares basados en la densidad de
fallas, por ejemplo no más de 0,25 fallas por 1 KNCSS (Mil líneas de código) para
hacer un deploy. Los datos de la industria muestran que la mayoría de las
organizaciones descubren 7 fallas por cada mil líneas de código durante el testing. Esta
medida puede ser usada como un bechmark de calidad.
Por ejemplo, una organización de IT fue capaz de reducir los costos de soporte al
establecer estándares de instalación basados en la densidad de fallas. Con una calidad de
software superior al momento de la instalación, los usuarios descubrieron menos fallas y
se necesitó menos esfuerzo durante el mantenimiento.

Tasas de alta y cierre de fallas.

Un mecanismo robusto para determinar cuando está listo un software para ser
entregado. Las tasas de alta y cierre de fallas miden la cantidad de fallas encontradas y
resultas en un periodo de tiempo, normalmente por día o por semana. Esta medida
puede ayudar a entregar software antes al indicar lapsos de tiempo donde la tasa de
descubrimiento de fallas sea cero y permita concentrarse en mejorar la tasa de cierre de
fallas.
La tasa de cierre, a diferencia de la de alta, normalmente lleva el ritmo del
testing porque en general es más fácil detectar fallas que arreglarlas. Por eso es que es
bueno llevar las dos medidas.
Estas medidas también ayudan a prevenir probar de más. Las dos medidas
llegarán a cero cuando el software está listo para ser entregado.
Por ejemplo una organización de IT se encontraba en el medio de la prueba de
sistema para un proyecto muy grande, con más de 200 fallas abiertas y sin ninguna
manera de predecir cuando el sistema iba a estar listo para ser entregado. Al medir y
hacer un seguimiento de estas tasas pudieron determinar cuando iba a estar listo. Luego,
al accionar para mejorar la tasa de cierre pudieron llegar a tiempo incluso cuando
aparecieron algunas sorpresas en el testing.

Métrica del riesgo total del proyecto

La posibilidad de llegar a una fecha particular es expresada como un porcentaje,
o un nivel de confianza. Calcular esta métrica durante la planificación del proyecto es
un método de estimación que puede prevenir hacer compromisos que no se pueden
cumplir. Por ejemplo, una organización de IT usó este método para calcular una
contingencia del cronograma para asegurarse que los compromisos eran factibles.
Mientras un proyecto esta en progreso esta métrica puede resaltar proyectos que
están más necesitados de atención por parte del management. Por ejemplo, los proyectos
con menos del 50% de confianza tienen que tener una atención del lider para evitar
excesos en el costo y en el tiempo.
Recolectar datos históricos
El tercer paso para establecer o mejorar un programa de métricas es recoger
datos históricos para las métricas elegidas. Muchas métricas del software no tienen
valor por si mismas, pero pueden ofrecer información valiosa solamente cuando son
normalizadas dentro de un contexto de datos históricos. Podes deducir algunos datos por
registros de proyectos anteriores mientras que otros datos requieren construir una base
de datos a con el tiempo.
Por ejemplo, las líneas de código son fáciles de medir en proyectos anteriores,
usando herramientas que cuentan las líneas. Con este dato histórico, será mucho mas
fácil predecir la cantidad de líneas de código para nuevos proyectos. También, con los
datos de cuanto esfuerzo fue necesario para completar los proyectos anteriores, los
managers pueden estimar la productividad de los programadores y usar esa información
como una regla para estimar tiempo.
Las fuentes de datos históricos que ya están disponibles gracias a tu proceso
actual pueden ser:
 Código fuente
 Cronogramas
 Registros de pedidos de cambios
 Reportes de los managers
 Datos de soporte de los productos (cuáles productos tuvieron la mayor
cantidad de consultas por parte de los clientes y por qué)

Automatizar los procesos de medición.

Después de que elegiste las métricas y recogiste los datos históricos, podes
empezar a tomar medidas. Puede ser tan simple como pedirle a los lideres de proyecto
que hagan reportes de las métricas elegidas o tan complejo como contratar nuevo
personal para que implemente un herramienta de medición.
Un mandato de un manager es útil pero no suficiente para soportar un programa
de métricas sostenible. Aunque debes identificar a un campeón de métricas dentro de la
organización no es rol full-time. Todo el staff debería tener herramientas para
implementar el programa:
 Conocimiento (obtenido a través de capacitación o esfuerzos de
comunicación)
 Templates (hojas para registrar los datos)
 Planillas de calculo
 Reportes predefinidos
 Herramientas de software
En general, deberías automatizar todo lo que sea posible. Esto reducirá el
esfuerzo requerido para recolectar las métricas y mejorar el retorno de la inversión.
Podes obtener una automatización básica, como la que soporta una simple planilla de
cálculo, con poca inversión.
No es inusual encontrar resistencia a las métricas por parte de los que son
medidos. La capacitación y la comunicación pueden minimizar la resistencia siempre y
cuando incluyas a todos lo afectados.
Deben entender los objetivos de negocio
para los que se crearon las métricas. Checklist de Métricas
Asegurarles que las métricas no son  Entendidas por el management
medidas de performance personal, sino  Fáciles de implementar
que miden el progreso del proceso. Las  Entendidas por los desarrolladores
 Medidas consistentes entre todos los
métricas elegidas en base a objetivos del
proyectos
proyecto deberían ser aceptadas más
fácilmente, especialmente si cumple con los criterios del cuadro “Checklist de
Métricas”.

Usar las métricas para tomar decisiones.

Las métricas no llevaran a una mejora en el retorno de la inversión a menos que
los managers las usen para tomar decisiones. Algunas decisiones en las que pueden
jugar un ron son:
 Si un producto esta listo para ser entregado o no.
 Costo y tiempo de un proyecto.
 Cuanta contingencia incluir para el costo y tiempo de un plan.
 Donde invertir para tener un mayor retorno.
 Cuando empezar la capacitación de los usuarios.
Los managers deberían pedir métricas antes de tomar decisiones como estas. Por
ejemplo, pueden usar la tasa de alta y cierre de fallas para decidir si un producto está
listo o no. Conocer el riesgo total del proyecto puede ayudar a los managers cuanta
contingencia incluir en un plan para el tiempo y costo.
El aspecto final a considerar es hacer un seguimiento de los resultados de tu
programa de métricas. Solo deberías seguir los resultados en términos de los objetivos
de negocio originales. Por ejemplo, si el objetivo era reducir un 25% la cantidad de
fallas reportadas en módulos ya instalados, hacer un seguimiento de este dato y usarlo
para medir el éxito del programa de métricas. Documentar los resultados ayuda a
asegurar, que mientras los objetivos de negocio evoluciona, las métricas se mantienen
siendo una parte relevante y vital de los proyectos de software.

Mirando hacia atrás

Imaginá que estás mirando hacia atrás luego del primer año de tu programa de
métricas. Identificaste objetivos de negocio claves e implementaste 3 métricas que los
soportaban: código cubierto por el testing, tasas de alta y cierre de fallas y riesgo total
del proyecto.
Le presentas el reporte a tu jefe: Las pruebas del sistema duran dos semanas
menos en promedio, los pedidos de soporte en los nuevos sistemas se redujeron en un
10%, y tu idea de la contingencia basada en el riego redujo las demoras en un 50%. El
presidente te felicita. Tu jefe te llama a su oficina para hablarte sobre el ascenso que
querías.
Si bien las métricas no son una bala de plata, elegir métricas basadas en
objetivos de negocio e implementarlas correctamente puede llevar a mejoras
cuantificables. Seguir estos cinco pasos descritos en el articulo te ayudará a entender
mejor el proceso de desarrollo de software, así como también a encontrar y eliminar
causas de problemas recurrentes. Todo eso ayudará a mejorar el retorno de la inversión.