Puntos de función – comparación

Echamos un vistazo a las diversas formas de medir el tamaño del software.

Dimensionar el software no es fácil, porque existen cientos de lenguajes, arquitecturas y técnicas para escribirlo. La industria ha probado muchos enfoques diferentes a lo largo de los años, pero el más eficaz es un enfoque llamado dimensionamiento funcional. Saber el tamaño es generalmente más útil antes de escribir el código. El tamaño también puede ser un indicador de la cantidad de funcionalidad empresarial involucrada. Aquí se analizan técnicas como contar historias de usuarios, contar puntos de historias y los principales métodos de análisis de puntos de función: puntos de función COSMIC y puntos de función tradicionales (IFPUG). También es posible evaluar el tamaño una vez escrito el código, aunque esto suele ser menos útil.

Directo al grano: le recomendamos que utilice puntos de función COSMIC en la mayoría de los casos. ¿Por qué? porque son válidos, confiables, consistentes, imposibles de jugar, rápidos de medir y adecuados para el trabajo ágil donde es posible que no se conozcan todos los requisitos desde el principio.

¿Por qué es importante el tamaño del software?

El desarrollo de software requiere mucha mano de obra y conocimiento. El mayor factor de costos para el desarrollo de software suele ser el esfuerzo humano para crearlo, diseñarlo y probarlo. Lo que generalmente queremos saber es cuánto esfuerzo y cuánto tiempo llevará lograrlo. Hay muchos factores que afectan el tiempo y el esfuerzo. El factor más significativo es Tamaño del software.  Entonces, veamos los diversos enfoques para dimensionar el software. Muchas veces confundimos dimensionamiento con estimación del esfuerzo. Por ejemplo, los puntos de la historia y el tamaño de la camiseta son en realidad solo una estimación del esfuerzo, no el tamaño.

Líneas de código

La mayoría de las herramientas de codificación crean líneas de código de forma fácil y automática. Hay dos valores principales, el número bruto de líneas utilizadas (LOC) y el número neto de líneas de código funcional (SLOC).

Contar líneas de código tiene un mérito limitado en la gestión de proyectos de software. Consideremos, por ejemplo, dos desarrolladores que escriben 50 líneas de código en un día. Podría ser que uno de los desarrolladores escriba un código conciso y eficiente que haga un buen uso de la capacidad del lenguaje subyacente. Sus 50 líneas ofrecen una funcionalidad significativa, posiblemente incluso una aplicación completa (pequeña), mientras que la otra podría simplemente realizar una validación muy básica. Superficialmente, ambos son tan productivos como los demás: ambos escriben 50 líneas por día. Esta es la razón principal por la que limitamos el uso de SLOC para dimensionar el software. RÁPIDO, INCONSISTENTE, ENGAÑOSO

Contando historias

Mucha gente opina que contar el número de historias es tan bueno como cualquier otra cosa. Este es un enfoque poco confiable ya que algunas historias de usuarios son tareas de desarrollo importantes, realmente podríamos llamarlas épicas, mientras que otras historias de usuarios son tan triviales que no involucran ninguna funcionalidad reconocible por el usuario. El rango que normalmente vemos es de 0 a 120 CFP. Como puede ver, estamos utilizando la metodología de dimensionamiento COSMIC para validar si otros enfoques tienen mérito. RÁPIDO, INCONSISTENTE, ENGAÑOSO

Contando puntos de la historia

Los puntos de historia son un indicador arbitrario de la medición del tamaño que solo debe usarse dentro de un equipo. No son una medida ni una métrica válida para determinar el progreso contra el equipo. Recuerde que los puntos de la historia pueden cambiar con el tiempo y son una opinión inconsistente sobre la duración probable de una actividad. Son muy fáciles de jugar para quienes realizan el conteo. La popularidad de los puntos de la historia es un comportamiento un tanto extraño de la mayoría de la industria del software: su popularidad no es merecida. Por otro lado, COSMIC Sizing y IFPUG Sizing son estándares ISO formales y consistentes para medir el tamaño.

Una historia de usuario puede variar drásticamente en tamaño. Una historia se puede entregar en minutos, otra puede requerir que todo un equipo trabaje durante un mes. Contar historias de diferente tamaño es una indicación de progreso, pero no es una medida válida de progreso.  LENTO, INCONSISTENTE, ENGAÑOSO

Análisis de puntos de función

Dimensionamiento funcional estándar ISO

La única forma consistente de medir el tamaño del software (a partir de 2023) es el tamaño funcional. Existen dos estándares principales para el dimensionamiento funcional:   Puntos de función IFPUG (1.ª generación) y  Puntos de Función CÓSMICA Puntos (2da Generación).

Ambos estándares de Function Point son maduros, válidos y probados (IFPUG:1974, COSMIC:1998). Son una descripción consistente y centrada en el usuario y una medida de funcionalidad en términos de entradas y salidas y datos almacenados. Se cuentan examinando los requisitos y aplicando algunas reglas/principios para determinar los tipos de datos que se mueven y almacenan. Ambos estándares son maduros, se mantienen de forma independiente y su aprendizaje es gratuito o económico. Recomendamos la metodología de dimensionamiento COSMIC de 2ª Generación. Las unidades de la metodología de dimensionamiento COSMIC son el Punto de Función COSMIC (CFP). El trabajo para realizar el dimensionamiento de los puntos de función se denomina análisis de puntos de función (FPA).

Puntos de Función CÓSMICA. RECOMENDADO

Algunos de los beneficios clave del estándar COSMIC FP son:

1. COSMIC Sizing se basa en principios de diseño de software. Como estándar, no es necesario realizar ajustes cuando se aplica a diferentes tipos de software (codificación personalizada, middleware, aplicaciones web, software de múltiples capas, software de sistema, sistemas integrados o proyectos de almacenamiento de datos).
2. COSMIC nos da una definición de un único punto de función, cada movimiento de un grupo de datos Entrada, Salida, Lectura, Escritura cuenta como 1 CFP.
3. La CFP se puede medir con precisión a partir de requisitos incompletos, lo que los hace adecuados para Agile y diversas formas de trabajo Agile escalado.
4. Los CFP son más rápidos y fáciles de aprender que los IFPUG FP. (1/3 del número de páginas para todo el programa de metodología)
5. COSMIC FP se puede determinar automáticamente con un mayor grado de precisión que IFPUG mediante un análisis de requisitos automatizado.

Para conocer más sobre COSMIC Sizing recomendamos La guía para dimensionar el software de Charles Symons

Puntos de función IFPUG

Habiendo dicho que COSMIC FP es preferible a los tradicionales IFPUG FP, este último se beneficia de mayores volúmenes de datos de referencia publicados y disponibles. La metodología de dimensionamiento IFPUG se diseñó en la década de 1970, cuando el diseño de software tenía menos capas y estaba menos segregado que en la actualidad. Los estándares permanecen prácticamente sin cambios desde su concepto inicial. Nos gusta IFPUG FP, pero preferimos COSMIC FP. Los puntos de función simples son una aproximación de IFPUG FP adoptada por la organización en 2019. ScopeMaster estima ambos IFPUG y FP sencilla.

Contar puntos de función manualmente

Hasta ahora, contar los puntos de función ha sido un proceso manual laborioso. Es necesario leer los requisitos y luego registrar los recuentos de los puntos de función en papel o en una hoja de cálculo. Solo se logran recuentos precisos y consistentes si el recuento lo realiza un especialista en puntos de función certificado y con experiencia. En promedio, un medidor certificado puede medir hasta 2000 FP/semana, lo que equivale aproximadamente a $2m de software.  LENTO, PRECISO

Estimación del tamaño del punto de función

Utilizando algunas reglas generales, los recuentos estimados de PF se pueden lograr observando una serie de factores que contribuyen. Si su aplicación es predominantemente una aplicación de tipo base de datos, puede contar la cantidad de tablas de datos que mantiene la aplicación. Luego multiplica el número de tablas por 27-30 para obtener una estimación de IFPUG. Esta es solo una de las muchas reglas generales útiles y no se debe confiar en ella para nada que no sea un tamaño de alto nivel. Velocidad de conteo: 5000 – 50 000 FP / persona semana  RÁPIDO, INCORRECTO

Puntos de función contraproducentes de líneas de código

La mayoría de los lenguajes de software han publicado promedios de líneas de código por punto de función. Por ejemplo, 50 líneas de Java equivalen, en promedio, a un punto de función. Contar las líneas de código y dividirlas por este número se llama "contraproducente". Esto es útil después el código ha sido escrito. Debe tener cuidado con este enfoque, especialmente cuando utiliza grandes volúmenes de marcos preescritos que pueden necesitar excluirse de un recuento de código personalizado. Velocidad de conteo: hasta 5.000 FP/persona semana.  RÁPIDO, INEXACTO, ENGAÑOSO

Conteo automatizado de puntos de función a partir del código

Ahora es posible automatizar el conteo de puntos de función desde el código. La compañía Cast Software ha desarrollado un software que realizará un recuento de puntos de función automatizado confiable basado en el código de la aplicación existente. Se necesita algo de esfuerzo para preparar el código para que pueda interpretarse y luego se puede lograr un recuento confiable. Esto es muy superior al enfoque contraproducente. Tiene el beneficio adicional de proporcionar una visión profunda del código de la aplicación.   RÁPIDO, CONSISTENTE, PRECISO

Dimensionamiento automatizado del punto de función COSMIC

Con ScopeMaster® puede beneficiarse de un recuento automatizado de puntos de función COSMIC en cuestión de minutos. Al analizar el texto de los requisitos del usuario, podemos detectar el tamaño funcional (movimientos de datos). ScopeMaster® proporcionará un resultado consistente con una precisión superior a 85% en comparación con un recuento manual realizado por un medidor experto.

Los resultados son coherente y transparente. Combinado con una verificación manual por parte de un especialista en puntos de función, vemos tasas de conteo de 10 000 a 20 000 FP por semana hombre. (aproximadamente $10- $20m de software) RÁPIDO, CONSISTENTE, BASTANTE EXACTO

Algunos de los análisis de tallas que ScopeMaster® genera automáticamente de sus historias de usuario escritas.

Conclusión

Si desea determinar el tamaño de una aplicación de los requisitos escritos Tiene dos opciones principales: contar los puntos de función manualmente o utilizar ScopeMaster® para contarlos por usted. Si ya tiene un código de aplicación que desea medir, existen opciones adicionales: contraproducente a partir de las líneas de código, estimación a partir de componentes técnicos (por ejemplo, basándose en el recuento de una tabla de base de datos) o mirar la automatización del dimensionamiento funcional de CAST Software. .