Desvelamos el misterio de las métricas de software: la guía para entender Puntos Función, SNAP, COSMIC, Nesma y SFP

¿Te sientes perdido en el complejo mundo de las métricas de software? Tranquilo, con esta guía te ayudaremos a entender de forma sencilla las diferencias entre los distintos métodos como Puntos Función, SNAP, COSMIC, Nesma y SFP.  

Tanto si eres un desarrollador, project manager o simplemente te interesa conocer más a fondo el funcionamiento del desarrollo de software, esta guía te proporcionará los conocimientos que necesitas para adentrarte en el mundo de las métricas de software con mayor confianza. ¿Estás listo?  

Los Puntos Función IFPUG (FPA): La clave para medir la funcionalidad del software 

Los Puntos Función de IFPUG son un método estándar de facto para medir la funcionalidad de un sistema de software. Introducido por primera vez por Allan J. Albrecht a finales de los setenta, proporciona una forma estandarizada de estimar el tamaño y la complejidad de un proyecto. Esto permite una mejor asignación de recursos y planificación del proyecto. 

Se basa en dividir las funcionalidades del sistema en dos tipos: funciones transaccionales y funciones de datos, evaluando sus componentes y asignando valores en puntos función según su complejidad (baja, media o alta). Al sumar estos puntos función, se obtiene una medida del tamaño del proyecto.  

La ventaja de utilizar los Puntos Función es que proporcionan una medida objetiva del tamaño funcional de un sistema de software. Y así podemos comparar distintos proyectos, estimar el esfuerzo y recursos necesarios de desarrollo y realizar un seguimiento de la productividad. Sirven también de lenguaje común entre desarrolladores, jefes de proyecto y otras partes interesadas, lo que facilita la comunicación y el entendimiento. 

Cuantificando los requisitos no funcionales con SNAP  

Mientras que los Puntos de Función se centran en los aspectos funcionales de un sistema de software, SNAP mide los requisitos no funcionales (Software Non-functional Assessment Process). Estos requisitos incluyen factores como el rendimiento, la mantenibilidad, la seguridad y la fiabilidad.  

SNAP sigue un enfoque similar al de los puntos de función, pero en lugar de medir la funcionalidad (“qué” hará el software), mide el tamaño y la complejidad de los requisitos no funcionales («cómo» lo hará el software). Los puntos SNAP son, por tanto, complementarios a los puntos de función. Son necesarios para mejorar la precisión de las previsiones de esfuerzo y calendario. 

SNAP es útil porque proporciona una medida cuantitativa de los requisitos no funcionales, lo que nos permite evaluar los atributos de calidad de un sistema de software. Esto ayuda a identificar posibles riesgos y problemas en una fase temprana del proceso de desarrollo y, por tanto, poder tomar medidas correctivas y garantizar el cumplimiento de los estándares de calidad deseados. 

COSMIC: Explorando con detalle la complejidad del software 

COSMIC es otra métrica utilizada para medir el tamaño funcional y la complejidad de un sistema de software, desarrollado por el Common Software Measurement International Consortium (COSMIC). 

El método COSMIC FFP se basa en los movimientos de datos en diferentes niveles jerárquicos y componentes llamados pares. Cada par contiene procesos funcionales que se componen de movimientos de datos, como entradas, salidas, lecturas y escrituras. Cada movimiento de datos tiene un valor de 1 CFP (Cosmic Function Point). El tamaño de un proceso funcional se determina sumando los tamaños de los movimientos de datos y el tamaño funcional total del software se obtiene sumando los tamaños de todos los procesos funcionales. En el caso de modificaciones en el software, el tamaño de la modificación se calcula considerando los cambios en los movimientos de datos. El resultado del tamaño funcional total del sistema de software puede utilizarse para estimación, planificación de proyectos y medición del rendimiento. 

COSMIC ofrece una medida más detallada y precisa comparada con otros métodos, considerando la complejidad de las estructuras de datos y la lógica de procesamiento. 

El método Nesma: La métrica de software adaptada a la evolución 

El método Nesma, desarrollado por la Netherlands Software Metrics Association (Nesma), es otra popular métrica de software. Se usa para medir el tamaño y la complejidad de un sistema de software, especialmente para proyectos de mantenimiento o mejora, considerando los cambios realizados en las funciones transaccionales y de datos.  

¿Cómo cuenta estos cambios? De la siguiente manera: las funciones nuevas se cuentan como en el método de IFPUG, las funciones modificadas se cuentan considerando el impacto de los cambios realizados, y las funciones eliminadas tienen un valor fijo. Se utiliza un factor de impacto para determinar qué porcentaje de la función se vio afectado por los cambios. Esto permite calcular cuántos puntos función de la función completa se ven afectados.  

La principal ventaja del método NESMA radica en su enfoque adaptado a proyectos de mejora, ofreciendo una medición más precisa y confiable del tamaño y los cambios en el software. 

Simple Function Points o la medición simplificada 

El método Simple Function Point (SFP) fue diseñado por Roberto Meli en 2010 como una versión simplificada de la métrica tradicional de puntos de función. Su objetivo es ofrecer un enfoque más accesible, rápido y práctico para medir el tamaño y el esfuerzo del software, sobre todo en momentos en los que disponemos de poca información. 

SFP se enfoca en solo dos componentes funcionales básicos: Procesos Elementales y Archivos Lógicos. No requiere identificar la «intención principal» de las funcionalidades ni diferenciar entre archivos lógicos internos y externos. Además, no considera la complejidad interna de los componentes, lo que hace que el proceso sea más rápido y se necesiten menos detalles.  

Entre sus ventajas destacamos que SFP permite una estimación más rápida y sencilla del tamaño y el esfuerzo del software. Además, es un método rápido y fácil de aprender, se puede aplicar en las etapas iniciales del ciclo de vida del software porque necesita menos detalles y se integra bien con los puntos de historia en procesos ágiles. 

Las métricas vistas de otra manera…  

¿Has llegado hasta aquí, pero sigues sin tenerlo del todo claro? Vamos a imaginar por un momento que el desarrollo de un producto software fuera la organización de un evento. Y debemos estimar el tiempo y el esfuerzo que nos llevará a cabo. 

• Con los Puntos Función mediríamos la funcionalidad del evento, el “qué”: dividirías las diferentes funciones del evento en dos tipos: las actividades que realizas (funciones transaccionales) y los elementos necesarios, como la decoración, la música y la comida (funciones de datos). Asignarías puntos a cada actividad y elemento del evento según sus componentes y complejidad. Al sumar todos los puntos, obtendrías una medida del tamaño y la complejidad del evento. Esto te ayudaría a asignar recursos adecuados y planificarlo mejor. 
• Con SNAP se medirían los requisitos no funcionales del evento, es decir, «cómo» se llevarán a cabo las actividades: el rendimiento, la seguridad y la calidad del evento. Por ejemplo, podrías medir la duración del evento (rendimiento), implementar medidas de seguridad para los asistentes (seguridad) y asegurarte de que la música y el entretenimiento sean de alta calidad (calidad). SNAP te proporcionaría una medida cuantitativa de cómo cumple el evento con estos requisitos no funcionales. 
• En la organización del evento, COSMIC nos serviría para medir la complejidad y cantidad de tareas involucradas en su preparación. En lugar de simplemente contar las actividades y elementos, COSMIC consideraría los movimientos de datos y las interacciones entre ellos. Por ejemplo, podrías medir la cantidad de oradores, la duración de cada intervención, la logística de los espacios y los requerimientos técnicos para las presentaciones. Al sumar todas estas métricas, obtendrías una medida más precisa de la complejidad y el esfuerzo involucrado en su organización. 
• Supongamos que ya has organizado eventos similares en el pasado y estás buscando mejorar tus procesos. Con el método Nesma medirías el tamaño y la complejidad del evento teniendo en cuenta los cambios y mejoras que haces en comparación con eventos anteriores: si has modificado la agenda, añadido nuevas actividades o cambiado el tipo de catering. Con Nesma calcularías cuánto ha cambiado el evento en términos de tamaño y complejidad, teniendo en cuenta los elementos nuevos o modificados. 

• Y con los Simple Function Points solo tendrías en cuenta dos componentes básicos: el número de actividades esenciales del evento (procesos elementales) y cuántos elementos como comida y bebida necesitas (archivos lógicos), sin valorar su complejidad. Te permitiría una estimación rápida y sencilla del tamaño y esfuerzo requeridos para organizarlo. 

Como ves tras leer esta guía, las métricas comparten el objetivo común de medir el tamaño y la complejidad del software, pero difieren en sus enfoques, reglas y directrices. Es esencial evaluar las necesidades de la organización y el proyecto antes de seleccionar la o las que mejor se ajusten a nuestros objetivos. 

Si quieres aprender alguna de estas metodologías de medición software, visita nuestra Academy para ver los próximos cursos online disponibles. Y puedes pedir una demo de nuestra herramienta SAAS de estimación software Quanter, con la que te hacemos aún más fácil la estimación y el seguimiento de tus proyectos de desarrollo. 

En esta guía de métricas de software hemos repasado cinco de los métodos de medición más utilizados. ¡No te pierdas nuestro próximo artículo! En el que hablaremos sobre las ventajas del uso de las métricas y os daremos consejos para implementarlas con éxito.