¡DETENTE! No sigas midiendo la productividad de tu proyecto software con una medida única de su tamaño.

Este Blog va dirigido a personas que tienen nociones básicas acerca de como se debe realizar la medición de la productividad en un proyecto software.

A lo largo de este Blog medirás junto a mí la productividad de un proyecto software, que tiene como objetivo realizar una aplicación Web [1].

Medir la productividad de un proyecto software mediante la relación de:

Productivity = Software Size / Effort (1)

No siempre genera una medición optima de la productividad de un proyecto, con la expresión (1) el tamaño del software es medido de una única forma, por ejemplo, mediante la cantidad de lineas de código. Sin embargo, en muchas ocasiones es posible tener varias medidas de tamaño significativas relacionadas con el esfuerzo, siendo difícil determinar cómo construir una medida de un solo tamaño a partir de las diferentes medidas individuales. Esto significa que no podemos usar (1) para medir la productividad.

Para medir la productividad de un proyecto software cuando el esfuerzo se relaciona con varias medidas de tamaño diferentes, es necesario realizar una amplia investigación del tema, y con esto responder algunas preguntas.

A lo largo de este Blog iré haciendo mención de dichas preguntas y respondiendo cada una de estas y de esa forma ir avanzando en la medición de la productividad de la aplicación web que se desea desarrollar, este podría no ser el caso de tu proyecto software, sin embargo, los pasos que deberás realizar para tu medición de productividad no difieren a los que se realizarán a continuación.

En el proyecto de la aplicación Web que se mencionó anteriormente, hacen uso de la siguiente ecuación base:

Productivity = AdjustedSize / Effort (2)

Las preguntas a responder a la hora de realizar una medición de productividad de software con tamaño multifactorial son:

1- ¿Qué factores o medidas de tamaño debes considerar en tu proyecto software? (No necesariamente para todo tipo de proyecto software deben considerarse las mismas medidas)

Para responder esta pregunta se puede realizar una investigación acerca de los factores que se han tomado en cuenta en proyectos similares, o realizar encuestas en empresas que realizan proyectos en el área de interés, con el fin de que los mismos ingenieros de software indiquen cuales son los factores más utilizados para medir la eficiencia de los productos software según su experiencia y según la opinión de los clientes.

Para el ejemplo de la página Web que se mencionó con anterioridad se tomaron en consideración las siguientes medidas:

• El número total de páginas web, incluyendo las páginas web nuevas, las proporcionadas por el cliente y las desarrolladas por terceros
• El número total de funciones de alto esfuerzo, incluye funciones de alto esfuerzo reutilizadas sin adaptación, adaptadas y nuevas, donde una función de alto esfuerzo es una función que tarda más de 12 horas en desarrollarse, suponiendo un único desarrollador
• El número total de imágenes nuevas.

Estas fueron consideradas luego de restringir y resolver problemas que se presentaron al examinar la base de dato que tenían disponible (usaron la base de datos Tukutuku).

Donde el AdjustedSize, es el esfuerzo total estimado para desarrollar una aplicación web, medida en horas-hombre. Incluye el esfuerzo dedicado a la recopilación de requisitos, diseño, implementación, pruebas, instalación, cualquier re-trabajo necesario durante el desarrollo, gestión de la configuración, reunión, capacitación e integración del nuevo personal

2- ¿Qué suposiciones explícitas debes realizar en tu estudio de productividad?

Para responder esta pregunta, puedes tomar en consideración las mismas suposiciones que mencionaré a continuación (ya que no varían con respecto al proyecto que estés realizando), o puedes investigar algunas otras que desees incluir o eliminar de tu estudio de productividad observando las características específicas que posee tu proyecto.

Para el ejemplo de la página Web se realizaron tres suposiciones:

• Suponen que la medición del tamaño del proyecto se encuentra fuertemente relacionada con el esfuerzo que requiere realizar el proyecto, por ende, las medidas que no estén relacionadas directamente con el esfuerzo no se tomarán en consideración.
• Que debe tenerse en cuenta la posibilidad de una economía o deseconomía de escala para realizar el análisis de productividad.
• Por último, suponen que es más fácil utilizar un modelo de regresión basado en el tamaño para construir una medida de productividad que tratar de construir un modelo de tamaño compuesto para medir el tamaño como una única medida.

3- ¿Qué métodos pueden usarse para tomar en consideración más de una medida de tamaño dominante en un proyecto software?

Para responder esta pregunta es necesario investigar que métodos se han utilizado para construir una medida de productividad multifactorial. De la investigación realizada por [1] voy a destacar a Reifer [2], el cual propuso realizar un conteo de los diferentes factores que estaban relacionados al tamaño de su proyecto software (cantidad de páginas web nuevas y reutilizadas, archivos de texto, animaciones, imágenes, entre otros) y luego realizar una combinación usando la ecuación de volumen de Halstead [3]. Y a Stensrud y Myrtveit [4] los cuales sugirieron usar el Análisis de datos envolventes (DEA), evaluando la productividad de los proyectos en relación con el proyecto más productivo que tiene valores de producción similares (es decir, medidas de tamaño).

Para el ejemplo se utiliza una medición relativa (al igual que el último caso mencionado), sin embargo difiere en que se relacionan un esfuerzo estimado (tomando en consideración todos aquellos factores o medidas de tamaño ya mencionadas en la pregunta 1) con el esfuerzo real (horas hombre dedicadas al proyecto, este valor se encuentra almacenado).

Se construyó el modelo de estimación de esfuerzo basado en el tamaño, utilizando regresión por pasos manual progresiva [5]. Esto es similar a la técnica paso a paso sugerida por Kitchenham [5], pero se usó además el recurso de diagrama variable adicional en la herramienta STATA para evaluar el impacto de cada variable candidata sobre los residuos del modelo actual en cada paso. Dado que las medidas de tamaño fueron muy asimétricas, se transformaron a una escala logarítmica natural para aproximarse a una distribución normal.

No se espera que la medida de productividad obtenida para un conjunto de datos específico se aplique a otros conjuntos. Para cada conjunto de datos independiente debe calcularse su ecuación de estimación apropiada antes de hacer el cálculo de la productividad de estos.

REFERENCIAS

[1] B. Kitchenham and E. Mendes, “Software Productivity Measurement Using Multiple Size Measures,” IEEE Trans. Software Eng., vol 30, no. 12, pp. 1023-1035, Dec. 2004.

[2] D. Reifer, “Web-Development: Estimating Quick-Time-to-Market Software,” IEEE Software, vol. 17, no. 8, pp. 57-64, Nov./Dec. 2000.

[3] M.H. Halstead, Elements of Software Science. Elsevier, 1977.

[4] E. Stensrud and I. Myrtveit, “Identifying High Performance ERP Projects,” IEEE Trans. Software Eng., vol. 29, no. 5, pp. 398-416, May 2003.

[5] B.A. Kitchenham, “A Procedure for Analysing Unbalanced Datasets,” IEEE Trans. Software Eng., vol. 24, no. 4, pp. 278-301, Apr. 1998.