6 Desventajas Clave de las Métricas Técnicas frente a las Métricas Funcionales

Imagen de R I O M A N S O.

Los aspectos técnicos del software también llamados medidas a posteriori o medidas sintácticas, son las medidas que se encargan de contabilizar componentes físicos del software tales como las líneas de código generadas, número de programas creados, número de ficheros fuente, número de paginas de documentación generada, etc.

Los aspectos funcionales del software o también llamados medidas a priori o medidas semánticas, son medidas enfocadas a contabilizar componentes funcionales del software, como por ejemplo los accesos a Entidades, las entradas de datos, las salidas de datos, etc.

La medidas físicas, y las métricas derivadas de ellas, se caracterizan sobre todo porque son unas medidas muy exactas y bastante objetivas: número de líneas de código de un programa es el que es, no es interpretable, aunque también tenemos que pagar un precio por esa exactitud y es que debemos esperar a que el software esté construido para poder realizar la medición de las mismas.

En un primer momento pueden parecer, por ello, unas medidas muy útiles a la hora de describir el software pero si ahondamos en su análisis encontramos una serie de desventajas que puede hacer contraproducente su uso:

1. Medidas no uniformes, dificultad en estimar. Como acabamos de ver, al ser medidas a posteriori se obtiene su valor exacto al finalizar el proyecto pero es bastante difícil poder realizar una previsión de cómo irá evolucionando dicho valor conforme vaya avanzando el desarrollo del mismo. De hecho, hay fases de avance del proyecto que pueden no estar asociadas de ninguna forma con los parámetros físicos y por tanto no nos puedan servir para estimar el esfuerzo de dichas fases (por ejemplo, la toma de requisitos afecta al desarrollo final del proyecto pero no se puede estimar un número de líneas de código preciso para el control).
La estimación en estos casos se debe basar más en una base histórica de proyectos dentro de la propia organización, donde podamos contrastar las características del proyecto, en cuanto a dimensión y recursos aportados, con otros ya realizados y que nos sirvan de guía, junto con la experiencia del propio analista, en la confección de estimaciones y previsiones.
2. Definición de la medida imprecisa. Como comentábamos anteriormente, el valor de la medida es exacto y es objetivo y esto es una de las ventajas que poseen estas medidas pero aunque su valor, una vez establecido, es exacto la propia definición de la medida puede no ser exacta. Por ejemplo, cuando definimos una medida como líneas de código fuente sin añadir más, nos puede llevar a que comparemos dos sistemas en los cuales en uno estemos contando las líneas de código fuente en un lenguaje de alto nivel y en otro estemos contando las líneas de código máquina generadas por el compilador. También que en uno estemos contando las líneas generadas automáticamente por la arquitectura de dicho sistema y en otro las estemos obviando porque no forman parte de nuestro desarrollo. Por tanto, un problema que nos encontramos es que la definición de la medida en sí debe constar de algo más que su propio nombre porque si no puede dar errores y que estemos comparando medidas diferentes (Kgs de tocino frente a Km/h de velocidad).
3. Medidas de naturaleza técnica. Estas medidas en cuanto son relativas a características físicas del software que se está desarrollando, implican obviamente que los agentes implicados en su análisis y que necesiten revisar sus valores, deban conocer el software y sus características. Esto hace que todo aquel que no esté versado en conocimientos técnicos de desarrollo de software no pueda interpretar correctamente los distintos valores obtenidos y por tanto estas medidas no nos permiten aportar información al usuario final de la aplicación, que normalmente desconoce el desarrollo de software, y lo que es peor, el usuario final de la aplicación no nos puede aportar su experiencia y conocimientos del entorno y de los procesos de negocio de la aplicación para contrastar las estimaciones realizadas.
4. Dependencia del entorno tecnológico. Al medir aspectos físicos del software de desarrollo, estas medidas tienen una dependencia extrema con respecto a las herramientas y lenguajes de programación que se hayan utilizado en el proceso de diseño y codificación del mismo. Una vez realizado el análisis de un proyecto, podremos optar por distintos lenguajes/entornos en los cuales implementarlo y los valores físicos obtenidos para cada uno de ellos pueden variar mucho, por ejemplo si realizamos el análisis y diseño de un sencillo editor de texto y luego realizamos dos implementaciones del mismo, una de ellas en Java y otra en Visual C++, ambas implementaciones tendrán un distinto número de líneas de código fuente. Esto nos hace ligar nuestra medición a la tecnología sobre la cual la estamos realizando.
5. Dependencia del entorno metodológico. La realización de los desarrollos de software bajo una metodología definida de diseño y programación, siguiendo unas pautas de estructuración y creación de clases, módulos y/o paquetes, con una nomenclatura determinada, siguiendo unas directrices para la mejora del mantenimiento del código en general, pueden hacer que un mismo proyecto implementado siguiendo las directrices establecidas o implementado sin seguirlas, tengan valores completamente diferentes en dichas medidas.
6. Dependencia del entorno humano. Como acabamos de indicar en el punto anterior, el seguimiento de una metodología se traslada directamente a las medidas que podemos obtener de un proyecto en concreto. Así mismo, la capacidad de los desarrolladores, del entorno humano del proyecto, también tiene una alta influencia en el desarrollo del mismo, ya sea por la pericia/impericia de los mismos, por los conocimientos que haya adquirido o por los desconocimientos que posean, etc.