¿Estás realizando una buena medición de productividad en tu proyecto software?
Para incrementar el nivel de productividad en cualquier proyecto es imprescindible medir (conocer) dicha productividad y usar los resultados obtenidos como herramienta para su posterior mejora, por lo cual esta medición debe encontrarse bien documentada con el fin de admitir comparaciones a lo largo del tiempo.
Realizar una medición óptima de la productividad en las industrias del software no suele ser tarea sencilla debido a que a diferencia de las empresas o industrias en las cuales el producto final es un elemento tangible, para las industrias del software existen activos intangibles que deben ser considerados a la hora de realizar dicha medición. Para las industrias software se debe tener en cuenta que existe eficiencia interna (relacionado con los programadores y los códigos creados) y eficiencia externa que involucra al usuario y de igual manera debe ser medida. Aun así, de forma general la productividad es P = Salida / Entrada.
La productividad de los proyectos software debe de clasificarse en dos etapas y medirse por separadas, una de “nuevo desarrollo” y otra de “mantenimiento”. También, depende del ambiente de desarrollo al cual se le realiza esta medida: sector, organización, departamento, proyecto, unidad o individuo; debe escogerse la métrica y los factores que vayan más acorde a este.
Antes de realizar la medida de la productividad se deben identificar los factores de entrada y de salida con las cuales se realizará dicho estudio. De igual manera, hasta la actualidad no existe una manera única y óptima de realizar esta medición, se han desarrollado diferentes métodos para esto, pero en general suelen trabajar con una cantidad limitada de factores, ya que tomar en cuenta todo aquello que influye a la productividad del proyecto requiere una enorme cantidad de datos, lo cual presenta una gran rigurosidad a la hora de recopilarlos y luego procesarlos.
Factores relacionados con el programa desarrollado, el personal de trabajo y los clientes, deben ser considerados para realizar el estudio de la productividad, como por ejemplo: lenguaje de programación, complejidad de programas, comprensión del código y la arquitectura, capacidad del personal, estabilidad del personal, participación del cliente y del usuario, entre muchos otros factores que se agregan o se eliminan de la lista dependiendo de los diferentes criterios que se vayan a tomar en consideración cuando se realiza dicho estudio. Es necesario resaltar que la mayoría de estos factores son difíciles de cuantificar y no existe mucha documentación sobre como tomarlos en consideración.
Ya sabiendo todo esto se presentarán algunas métricas usadas en la actualidad, de las cuales solo se mencionarán los aspectos mas importantes y no se profundizará en cada una de ellas. Esto debido a que en esta sección solo queremos introducir los conocimientos y aspectos básicos de la medición de la productividad para los proyectos software.
Organizando las métricas desde las mas fácil de implementar hasta la más complicada, se tiene:
- P = TLOC / Effort Esta es una de las métricas más utilizadas debido a la facilidad de su implementación, donde tenemos como entrada un Effort = Horas hombre, y una salida que representa el tamaño del software, medido por TLOC = SLOC + DLOC, siendo TLOC el total de lineas código, SLOC la cantidad de lineas de código fuente y DLOC la cantidad de lineas de documentación del código. El problema principal de esta métrica es que no se considera de ninguna forma el lenguaje de programación utilizado en el proyecto. Si el proyecto es desarrollado con un solo lenguaje o con más de un lenguaje de programación e incluso si es fácil o no programar en este, no presenta relevancia para esta métrica. En el caso de utilizar más de un lenguaje de programación no se considerará la variación en la dificultad de escritura que existe entre dichos programas, se contabilizarán las lineas de código como si se tratase de un mismo lenguaje.
- P = FP / Effort Para esta métrica tenemos como entrada un Effort = Horas hombre, y una salida de FP, donde FP representa los puntos de función que miden al software desde la perspectiva del usuario, asignándole a una aplicación más o menos puntos dependiendo de la complejidad de los datos que maneja y de los procesos que realiza sobre estos, de esta manera la métrica deja de lado los detalles de codificación. El problema principal que presenta esta métrica es su difícil utilización óptima, ya que se debe recopilar una gran cantidad de datos y eso es un trabajo riguroso, por otra parte, esta métrica es criticada por ser poco confiable, ya que los datos son subjetivos.
- P = DSI / Effort Para esta métrica tenemos como entrada un Effort = Meses hombre, y una salida DSI que representa la cantidad de instrucciones de código realmente entregadas. Esta métrica sirve de soporte para la medición de productividad cuando se reutiliza software, ya que esta métrica toma en cuenta las instrucciones entregadas (incluyendo los códigos que reutilicemos).
- DEA Esta métrica puede presentar múltiples entradas y salidas. DEA se basa en la estimación de una frontera de productividad a partir de los datos disponibles de observación. Esto lo hace sin tomar en cuenta una relación entre la entrada y la salida (como las métricas antes mencionadas), además, este modelo provee un procedimiento para diferenciar entre proyectos eficientes e ineficientes.
- P = AdjustedSize / Effort (métrica multifactorial) Para esta métrica se tiene como entrada el Effort que no necesariamente debe estar definido como el tiempo horas hombre, y una salida Size que representa un esfuerzo estimado que depende de más de una medida de tamaño del proyecto. Esta es una métrica que permite tomar en consideración múltiples factores. En otras palabras, es posible tener diferentes medidas de tamaño relacionadas significativamente con el mismo esfuerzo, y por ende no es válido medir la productividad utilizando solo uno de estos tamaños. Esta métrica permite, mediante algunos ajustes, realizar dicha medida de productividad tomando en cuenta cada uno de estos factores que describen al tamaño del software.
Video: https://youtu.be/oPRIjyphePE
