Software benchmarking: información estratégica
No es novedad que benchmarking, tanto interno como externo, es una palabra mágica ampliamente utilizada en las organizaciones maduras de Tecnologías de Información (TI). Esta actividad de benchmarking, al menos inicialmente, no debería tener como objetivo premiar o sancionar, sino ofrecer información estratégica a la alta dirección: el grado de competitividad de una compañía en lo que respecta a productividad, calidad del producto, tiempo de desarrollo de un producto, relación calidad/precio, etc.
En el ranking, y comparando con el mismo sector de actividad, ¿estamos en las primeras posiciones, hacia la mitad, o cerca de los últimos puestos? Disponer de información fiel es extremadamente fascinante porque los resultados (números en mano) pueden no estar alineados con lo que inicialmente se tenía en mente. Si estamos en una posición incorrecta o incluso si se desconoce en cuál se está, se deberían de tomar medidas con cierta rapidez.
Un común denominador de las diferentes fuentes de benchmarking existentes es que las técnicas utilizadas para cuantificar el producto software están basadas en estándares. Es evidente que podremos utilizar métodos creados a medida para comparar diferentes aspectos internamente, incluso disponer de centenares de KPIs, pero si queremos comparar proyectos y productos con el mercado es necesario utilizar métodos estándares. Si utilizamos kilómetros como algo estándar para medir la distancia entre puntos, podremos comparar la velocidad (kilómetros por hora), el consumo (litros por kilómetro) y mucho más. Pero si utilizamos una métrica ad-hoc tal como “xyz”, podremos decir que un vehículo consume “0,25 litros por xyz” pero esto no se podrá comparar con nada estándar. En el caso de utilizar herramientas que proporcionen métricas no estándares, no será posible disponer de benchmarking estándar: los resultados únicamente podrán ser comparados con organizaciones que utilicen el mismo método “ad-hoc”; en muchos casos únicamente se podrá comparar con uno mismo.
El tamaño de software (es decir, la cantidad de producto fabricado) es esencial como base para evaluar proyectos y productos. Si tomamos como referencia el esfuerzo o el precio de venta estaremos confundiendo conceptos esenciales, los resultados estarán contaminados y no dejarán de ser un sinsentido.
Disponer de este tamaño de software a menudo suele ser más complejo cuando estamos ante grandes aplicaciones ya existentes, o ante toda una instalación. A pesar de que, en un mundo de teoría, todas las funcionalidades de un sistema deben estar correctamente documentadas y la documentación actualizada, la teoría no siempre se convierte en realidad.
Cuando hablamos de calcular el tamaño de instalaciones con centenares de miles de programas, creados en muchos casos por diferentes empresas a lo largo de varias décadas y con el conocimiento funcional disperso en un casi incontable número de documentos, determinar el tamaño software de una instalación/gran aplicación, puede convertirse en un interesante reto. Posiblemente tengamos, como única información, miles de programas e incluso la tarea de detectar, mediante un sistema de trazabilidad, cuáles son las funcionalidades y el software realmente utilizado en la actualidad, ya que a menudo existe la tendencia de no eliminar software obsoleto de los entornos de producción, aplicando la filosofía del “por si acaso”. ¿Se utilizan en la actualidad esos 84.784 programas existentes, y qué parte de ellos?
Si necesitamos, por ejemplo, medir grandes aplicaciones en un periodo corto de tiempo, o incluso toda la instalación, el tamaño del producto y estimar esfuerzos (por ejemplo, en el caso de mantenimientos / outsourcing) interfiriendo lo menos posible el día a día de los usuarios, será casi imposible utilizar un método ISO/IEC. Obviamente en teoría será posible, pero poner en escena esa teoría será algo más complejo.
En estos casos, utilizar una herramienta para obtener métricas automáticas y disponer de los resultados en un periodo corto de tiempo es esencial. Tiempo atrás participé en la invención de una de ellas para analizar y medir grandes volúmenes de software: métricas de tamaño, calidad del código físico, inter-relaciones con otros sistemas (a menudo mantenidos por terceras partes) y un conjunto variado de información a una velocidad de más de 5.000 líneas de código analizadas por segundo. En estos casos, focalizarse en el código físico, en lugar de en las funcionalidades, es la opción menos mala. Aunque alejado de métricas estándares de tamaño, es el enfoque más práctico y realista(siendo recomendable complementarse con otros ejes de información).
Posiblemente el mejor enfoque de automatización (automatizar el tamaño de software) debería aplicarse en las fases de diseño, transformando -de forma automática- documentos de diseño estándares y poder comparar diferentes versiones de documentos para redimensionar y replanificar, si es necesario, los proyectos. No es infrecuente descubrir que la documentación utilizada para determinar el tamaño de una aplicación, por ejemplo, no siempre está cerca de la realidad. Con estos sistemas de documentación funcional se podrán cubrir varios objetivos: definir herramientas para calcular el tamaño de forma precisa y, al mismo tiempo, asegurar que la documentación es estándar y no propietaria o con diferentes estilos, con una trazabilidad real y directa entre documentación/tamaño/esfuerzo. Todo un conjunto de beneficios, desde obtener automáticamente el tamaño en base a los documentos de diseño, generar documentos más estándares y asegurar que los requerimientos y los diseños son precisos y satisfacen perfectamente las necesidades de los clientes.
