Métricas esenciales de TI: productividad, calidad, competitividad y deuda técnica
Una fascinante capacidad de las Tecnologías de la Información (TI) es liberar a las personas de aquellas tareas repetitivas que pueden ser hechas por aplicaciones informáticas a una velocidad de millones de instrucciones por segundo. Las TI ayudan a las organizaciones a ser más competitivas, a proporcionar más valor, y a que las tareas en las que el ser humano no aporta valor añadido sean hechas por máquinas. Pero, ¿puede esta automatización reemplazar a las personas en lo que respecta a medir el tamaño de las aplicaciones?
Uno de los secretos de los métodos para medir el software realizado (tales como el Tamaño Funcional ISO/IEC que será la base de las métricas más estratégicas; si se toma como base el concepto “horas” de proyecto será el mundo al revés), es que el tamaño se obtiene en base a las funcionalidades que el usuario recibe y no en el código físico del software, número de programas o tablas utilizadas. Más líneas de código no tiene por qué ser sinónimo de un producto de mayor tamaño; posiblemente sea sinónimo de una solución poco inteligente. Otro punto clave es que diferentes expertos en medición llegarán al mismo tamaño, en lo que refiere a medir una instalación, aplicación, adaptación o cambio. Para determinar el tamaño no es necesario conocer el lenguaje de programación ni incluso analizar técnicamente cómo la aplicación ha sido desarrollada. El Tamaño Funcional del Software (Functional Size Measurement, FSM), nacido de la mano de IFPUG y también conocido como Function Points, es un método universal para medir el producto que el usuario recibe, que ha sido mejorado a lo largo de la historia, y está en continuo progreso.
A menudo crea cierta confusión, e incluso malentendidos, el exceso de métricas que comparten la palabra “Points” o incluso las palabras “Function Points” para denominar conceptos totalmente diferentes. Esto puede contribuir en una especie de contaminación de conceptos, porque cuando alguien ve una métrica que termina con “Points” o con “Function Points” pueden pensar que es similar a otra; por ejemplo, Function Points frente a Story Points.
Con demasiada frecuencia he oído a mucha gente defender que se cuente manualmente el tamaño de los productos de software y, por otra parte, a otros argumentando las bondades del conteo automático, pero en cualquier caso ambos enfoques deberían delimitarse ya que crean diferentes métricas. El hecho de que compartan el mismo nombre, “Function Points”, no ayuda y, como se ha mencionado, puede crear confusión: Automated Function Points (AFPs) no son Puntos Función IFPUG calculados de forma automática porque el método de cálculo es diferente y los resultados son también diferentes.
Los AFPs se calculan en base al código software realizado (dependiente del código) y Function Points (o Tamaño Funcional) están basados en las funcionalidades que el usuario recibe. En algunos casos el porcentaje de desviación entre ambos puede ser pequeño, pero en otros puede ser considerablemente alto.
AFP está apoyado por Consortium for IT Software Quality (CISQ), teniendo como cofundadores el Object Management Group (OMG) y el Software Engineering Institute (SEI). Su especificación está basada en las principales ideas del estándar IFPUG, intentando ser lo más similar posible a éste.
A pesar del hecho de que AFP intenta utilizar la misma filosofía que IFPUG, es extremadamente complejo transformar líneas de código de software y modelos de datos físicos en conceptos de IFPUG tales como el proceso elemental, proceso único, límites, temporalidad, entidades internas lógicas o entidades lógicas externas (únicamente como ejemplos). Intentar comparar AFPs con el Tamaño Funcional estándar acaba siendo un reto interesante.
El objetivo de este artículo no es elogiar el método de IFPUG (sobre el que se fundamentan a su vez otros) ni ser crítico con AFP; simplemente recordar que son dos métodos diferentes y que los AFPs no son IFPUG Function Points calculados de forma automática. Ambos pueden proporcionar resultados más o menos similares o completamente diferentes; cuestión de suerte.
El concepto “cantidad de software” (o Tamaño Funcional) cubre una variedad de propósitos en diferentes momentos a lo largo de un proyecto. El Tamaño Funcional es utilizado en la fase de estimación (transformando tamaño en esfuerzo y esfuerzo en coste, o directamente convertir tamaño en coste basado en un importe por unidad de tamaño), para analizar cambios en requerimientos (o descubrir requerimientos omitidos) y a efectos de replanificación, creando diferentes fotos del tamaño en diferentes momentos a lo largo del proyecto, para medir el producto creado y como base para conocer la productividad, calidad, benchmarking, etc. Los propósitos son vitales para compañías de TI o departamentos de TI.
El punto importante es utilizar esta métrica “Functional Size” desde las fases más tempranas del proyecto. Calcular el tamaño del producto basado en el código software realizado implica que el “tamaño” únicamente puede obtenerse y utilizarse una vez que el software (código) ha sido creado. Por lo tanto, no es posible utilizarlo en las fases más tempranas de un proyecto, tales como requerimientos, estimación o análisis. Este hecho no aplica únicamente a AFPs, sino a cualquier método que se fundamente en el software físico creado: los datos únicamente pueden ser utilizados tras haber sido creado el software.
Determinar el precio de un proyecto basado en el Tamaño Funcional del producto que se construye es algo habitual en países como Brasil e Italia, auspiciado mayoritariamente por las administraciones públicas y por las grandes entidades, e incluso existiendo unos precios “de mercado” por unidad de medida. Se trata de un coste de producto basado en las funcionalidades del mismo, poniendo más énfasis en las actividades de requerimientos y evitando al máximo desviaciones en esos requerimientos. Este es un hecho que contribuye negativamente al éxito del proyecto (modificaciones sobre la marcha, retrasos en los proyectos, calidad del producto menor a la deseada debido a falta de tiempo o a incompletas pruebas de regresión) y en el fascinante concepto “Technical Debt” o Deuda Técnica.
Estos conceptos de “productividad”, “calidad” y “benchmarking” mencionados anteriormente deberían ser considerados estratégicos (medidos, con tendencias históricas, y comparados internamente y externamente) por la más alta dirección de las empresas. A medio y largo plazo influenciarán en el éxito de una empresa, en la competitividad de la misma, en el servicio proporcionado a los clientes y en los resultados, entre otros.
Artículo publicado originalmente en MetricViews, la publicación bianual editada por IFPUG. Basada en Estados Unidos, IFPUG es probablemente la organización líder mundial en lo que se refiere a tamaño de software, estándares, y métricas de Tecnologías de Información, y engloba a los máximos expertos mundiales en estas áreas.
