¿Es posible convertir el tamaño funcional de un software medido con un estándar en unidades de tamaño funcional usando otro estándar sin tener que volver a medir el software?
¿Qué consideraciones se deben tener en cuenta para poder hacerlo?
¿Existen ecuaciones de convertibilidad que permitan hacer estas conversiones de manera rápida, confiable y precisa?
Las anteriores son interrogantes que seguramente nos hemos hecho quienes ya trabajamos con métricas estándares y entendemos los beneficios de utilizarlas, sin embargo por eta misma razón si disponemos de datos históricos de proyectos que hemos medidos en algún estándar y deseamos, por ejemplo, movernos de un estándar de medición de primera generación a un estándar de medición de segunda generación como COSMIC, seguramente deseamos conservar toda esta base de conocimiento pero en la nueva unidad, por lo cual nos hemos preguntado si es posible hacer estas conversiones de manera fácil y rápida sin tener que volver a medir todas las piezas de software con los inherentes costos de esfuerzo y dinero que eso representa.
Aquí comentaremos bajo que consideraciones es posible hacer estás conversiones y qué caminos documentados en la literatura existen en la actualidad.
Los métodos de medición de tamaño funcional (FSM) de “primera generación”, como los métodos IFPUG, MkII y Nesma, y el método COSMIC de “segunda generación”, todos expresan sus tamaños en una variedad de “puntos de función”. Sin embargo, las mediciones no son directamente comparables ya que cada método tiene sus propias reglas y procesos de medición y, por lo tanto, diferentes escalas de medición; es decir las unidades de “puntos de función” no son equivalentes entre sí, por lo tanto, una unidad (1 punto de función) representa diferente tamaño de funcionalidad entre los diferentes estándares.
Para que esto sea completamente claro pensemos en la unidad de medida “kilómetro” (km) en el sistema internacional de unidades y en la unidad de medida “milla” (mi) en el sistema anglosajón de unidades; si comparamos la longitud física de ambas unidades nos damos cuenta de que representan una longitud diferente, por lo tanto, no son equivalentes uno a uno, es decir 1 km ≠ 1 mi. Lo mismo sucede en el dimensionamiento del software, un punto de función en el estándar IFPUG es diferente a un punto de función en el estándar COSMIC, es decir 1 FP ≠ 1 CFP.
Afortunadamente, así como existen ecuaciones de conversión para pasar medidas en millas a medidas en kilómetros y viceversa; también es posible disponer de ecuaciones de conversión para pasar el tamaño funcional de un software medido por ejemplo en FP de IFPUG a CFP de COSMIC; sin embargo mientras que la ecuación de conversión de millas a kilómetros es única y completamente precisa para convertir de manera uno a uno cualquier dimensión en millas a kilómetros; en el caso del dimensionamiento del software las ecuaciones ni son únicas ni son 100% precisas.
Entender porque sucede esto es muy sencillo; en el caso de las unidades de medida kilómetro y milla el método para medir una longitud ya sea en millas o en kilómetros es el mismo, consistente en encontrar cuantas veces cabe la unidad de medida en lo que queremos medir; sin embargo, en el software los diferentes métodos de medición tienen reglas y procedimientos diferentes, es decir, cada uno mide cosas distintas.
Generalmente nos referiremos a los métodos IFPUG/Nesma, MkII y COSMIC en su forma estándar, es decir “Puntos de función no ajustados”, para que pueda ser comparable, ya que los “factores de ajuste de valor” de IFPUG y MkII no son reconocidos por los métodos Nesma o COSMIC.
Prácticamente todos los métodos son equivalentes en muchos de sus conceptos como el propósito de lo que se cuenta, el concepto de lo que es una aplicación, el alcance de lo que se cuenta, la frontera o los límites del software que se mide, los usuarios del software; sin embargo en lo que no son equivalentes es en la forma en que modelan y cuentan los datos que almacena y manipula el software; de ahí que no existan funciones de conversión precisas, una de esta diferencias fuertes es por ejemplo que IFPUG/Nesma si catalogan la complejidad de la funcionalidad y el peso que tiene en la contribución del tamaño; mientras que MkII y COSMIC no lo consideran debido a las desventajas que implican, para darle solidez y consistencia al método de medición.
Tomando en cuenta las consideraciones anteriores, si bien no es posible la conversión de cualquier tamaño funcional en cualquier método de primera generación a tamaños funcionales en COSMIC, si se puede obtener una relación entre los tamaños medidos, por lo tanto, cuando hablamos de conversiones nos referimos a la correlación que existe entre las distintas unidades.
El objetivo principal por los que queríamos hacer estas conversiones es para determinar una fórmula de conversión de tamaños calculados con métodos de primera generación a tamaños COSMIC, considerando que disponemos de una base de datos histórica abundante en un estándar de primera generación y deseamos movernos a COSMIC sin perder la información histórica y disponiendo de elementos para recalibrar por ejemplo todos los métodos o herramientas de estimación que tengamos.
Bajo la consideración anterior lo que necesitamos es identificar una fórmula local para convertir las mediciones existentes de toda la base de datos histórica, en la literatura hay varios de estos estudios con sus respectivas fórmulas encontradas como se pueden consultar en los apéndices de la guía COSMIC sobre como convertir puntos de función de primera generación a tamaños COSMIC [1].
Un método general para poder derivar estas formulas locales sería el siguiente [1]:
- Seleccionar grupos de proyectos con características similares, cada grupo debe ser tratado por separado ya que tendrá su propia ecuación de conversión, los pasos siguientes se aplican por separado para cada grupo
- Seleccionar del grupo una muestra representativa de proyectos que estén medidos en ambos estándares (sino lo están se deberán medir), de manera que cada proyecto de la muestra disponga de su tamaño en los dos estándares
- Calcular el coeficiente de determinación R2 y verificar si es bueno, es decir que sea alto lo más cercano a “1”. Si la R2 no es buena, entonces identificar puntos atípicos (outliers) y regresar al paso (a). Si la R2 es buena seguir al paso (d)
- Validar el nivel de precisión de la conversión respecto del tamaño real. Si el nivel de precisión no es adecuado no se puede usar la función de conversión.
- Convertir los tamaños funcionales del resto de los proyectos que no formaron parte de la muestra, con lo cual tendremos todo el conjunto histórico de proyectos del conjunto identificado convertidos a unidades del estándar seleccionado.
Como es claro de las explicaciones anteriores es importante señalar, que las ecuaciones de conversión son diversas dependiendo de la muestra y de las características de los proyectos; por lo cual todas las ecuaciones de conversión deben ser calculadas localmente. Cabe señalar que, si se utiliza una ecuación de alguien más, es decir, no calibrada localmente, no se puede garantizar que funcione correctamente.
La plataforma tecnológica MENSURA® desarrollada por SPINGERE; liberará próximamente funcionalidades para poder hacer este tipo de conversiones entre los diferentes estándares de medición; para más información consultar https://mensura.com.mx/.
[1] COSMIC Functional Size Measurement Method, “Guideline on how to convert ‘First Generation’ Function Point sizes to COSMIC sizes”. Version 1.0, November 2016.
[2] Common Software Measurement International Consortium (COSMIC), Measurementt Manual for ISO 19761, Part 1, Part 2, Part 3. Version 5.0, May 2020.