Una fábrica de tornillos realiza 100 tornillos por persona y minuto de trabajo, de los que desecha 5 por defectuosos. Cuando medimos su productividad diremos que produce 95 tornillos por minuto de persona, no 100 ¿verdad? Si en vez de tornillos hubiéramos hablado de software hubiéramos considerado 100 puntos función. ¿Por qué? Porque, en general, cuando se mide la productividad de software no se considera su calidad, es decir, no se “desecha” software. Pero ¿cómo calcular la productividad considerando la calidad del software? Aquí os va alguna idea.

Hablando de calidad de software existen dos conceptos que podríamos aplicar: se trata de las deudas técnica y funcional. Llamamos deuda técnica al esfuerzo (en términos de carga de trabajo) que un desarrollador de software deberá realizar tras la puesta en Producción para resolver los errores técnicos (errores en el análisis, el diseño o la codificación) que contiene el software. Llamamos deuda funcional al esfuerzo para resolver los errores funcionales (por los que el software no realiza su función tal como estaba prevista) que, igualmente, se deberá realizar después del paso a Producción. Por tanto, si pudiéramos conocer tanto una como otra podríamos utilizar sus valores para calcular de una manera más aproximada la productividad como:

Productividad = Cantidad de producto software /(Esfuerzo incurrido en el desarrollo + Deuda técnica + Deuda funcional)

Observad que no podemos reducir el numerador, como se hace con los tornillos, pues no se desecha software, sino que buscamos la manera de matizar el resultado a través del denominador (esfuerzo).

Existen herramientas que nos ayudan a calcular de una manera razonablemente aproximada (y convincente) una parte de la deuda técnica, analizando cómo está codificado el software. Si se considerara oportuno se podría completar este cálculo a través de las revisiones de los documentos de ingeniería (análisis funcional, diseño orgánico, casos de prueba, etc.). Además, se pueden implementar mecanismos que nos ayuden a calcular, también de una manera convincente, la deuda funcional, a través de la cantidad de casos de prueba previstos y definidos, sus ejecuciones y sus resultados (errores encontrados y corregidos). Sin embargo, hoy en día todavía no se calculan estos datos de manera extendida, lo que impide su uso.

Entonces, ¿cómo matizar el resultado de la productividad en función de la calidad del software producido? Os sugiero que defináis, calculéis y analicéis métricas e indicadores de calidad del software como, por ejemplo:

• La cantidad de casos de prueba definidos, ejecutados y con resultado correcto, pues cuantos más casos de prueba se hayan definido y ejecutado de manera correcta más garantías tenemos de que el software producido deja menos deuda funcional.
• La cantidad de errores resueltos frente a la de errores reales encontrados. También está orientado a percibir la deuda funcional remanente.
• El volumen de incidencias en Producción provocadas por el software, que nos habla de la calidad real del software puesto en Producción, lo que disminuye el dato de productividad pues se debería considerar el esfuerzo incurrido en corregir el software que, claro está, no aporta mayor producción.
• La cantidad de errores encontrados por unidad de producto. Cuantos menos errores se encuentren por unidad de producto mejor será la calidad del software y, por tanto, menor será la deuda funcional esperada.
• La cantidad de producto probado frente al realizado. Si ambos valores son muy próximos, la garantía de calidad del software es mayor (menor deuda funcional).

Ahora, asignando un coste unitario al valor correspondiente del indicador podremos obtener una aproximación al coste pendiente. Por ejemplo, asignando un coste unitario de resolución estimado a cada error encontrado y no corregido podréis estimar el coste previsto de resolución de errores conocidos.

Todas estas métricas e indicadores os harán percibir la calidad realmente obtenida en el software y podréis haceros una idea del esfuerzo que todavía queda por hacer (e incluso determinarlo de manera aproximada pero razonada), lo que reforzará la precisión y comprensión del dato de productividad.

Leda MC ofrece servicios de soporte al gobierno integral del desarrollo y mantenimiento de software que pueden incluir actividades para el cálculo de las deudas técnica y funcional, y su repercusión sobre el coste final del software y, por tanto, sobre la productividad real.