La estimación del software es uno de los primeros pasos en un proyecto de planeación de software. Esta incluye el cálculo de su tamaño, el esfuerzo de desarrollo, costo e itinerario. FP se convertido en la forma más popular para medir un sistema de software.
Function points (FPs) fueron desarrollados en
IBM por Allan J. Albrecht tarde en los 70s, para medir el tamaño del software propuesto para desarrollo. Tal parece que la metodología FP estaba orientada hacia el desarrollo de sistemas en las plataformas IBM usando COBOL para los procesos por lotes. A partir de entonces y hasta la aparición de end-user computing (EUC) y graphical user interface (GUI), los FPs fueron la forma correcta de medir un sistema de software.
Esto fue ya hace algunas décadas, lo cual es un largo tiempo en el mundo de la computación. Desde entonces la metodología FP se ha vuelto realmente popular, tanto, que existe una asociación llamada
International Function Point User Group (IFPUG). IFPUG sobrepasa la metodología FP, y lleva a cabo exámenes y ofrece a los partidarios de FP certificaciones
Certified Function Points Specialist (CFPS). El desarrollo de software avanzo desde programas de lotes en cascadas hacia el desarrollo de GUI orientado a los eventos. Los archivos planos fueron remplazados por tablas para la gestión de sistemas de bases de datos. Excepto DB2 de IBM, otros sistemas de gestión de bases de datos relacionales (RDBMSs) no utilizan el termino “archivo lógico.” Estos progresos hicieron los resultados de FP difíciles para la métrica del sistema.
Hoy en día las aplicaciones Web están reemplazando rápidamente las aplicaciones instaladas en el servidor del cliente, pero las aplicaciones Web han traído consigo además complicaciones propias de ellas. Por ejemplo, un mensaje de error de codificación, será considerado como un tipo de elemento dato (DET) en la metodología FP. Pero los desarrolladores son capaz ahora de digerir que la pantalla de confirmación, orgullosamente mostrando el mensaje de “gracias” en una pagina Web HTML, no es más que DET, y un gran esfuerzo de programación fue invertido allí.
La discusión se centra en la confusión que los desarrolladores de software enfrentan al tratar de adaptar sus sistemas a la metodología FP. Dados los cambios en el panorama de la industria del software, se ha sobrepasado la metodología FP introducida aproximadamente hace 30 años. Por lo tanto, la pregunta radica en la relevancia de la metodología FP para medir los sistemas actuales.
A continuación tendremos un examen de la metodología usada por FP para responder dicha pregunta. Como usted observará, la mayor parte es una crítica al método FP. Si usted esta en desacuerdo con la perspectiva, siéntase libre de enviarme un correo electrónico con su perspectiva.
¿Qué es un FP?
Originalmente, era considerado un identificador para el usuario de funciones distintas, pero esto es una paradoja. Si esto fuese verdad, la metodología FP no debería incluir archivos lógicos internos (IFL, del inglés
Internal Logical File) y archivos externos de interfase (EIF, External Interface File) en sus cálculos, ya que los usuarios que no tienen experiencia en el desarrollo de software no puede identificar estos dos tipos de transacciones.
¿Entrada, salida o preguntas externas?
Hoy en día, la mayoría de salidas están dirigidas hacia la pantalla. Incluso los reportes se presentan en la pantalla, con la posibilidad de imprimirlos si se desea. La salida o entrada externa son procesos elementales, donde la información se cruza en las fronteras de salida o entrada del sistema. Las preguntas externas mencionan explícitamente entradas y salidas. Hoy en día, todas las aplicaciones están orientadas a los eventos, lo que significa que toda entrada esta siempre asociada a un proceso. ¿Significa esto que los procesos de entradas y salidas externas son preguntas?
Agregar, modificar, borrar y preguntar
En el pasado estas cuatro funciones requerían de diferentes programas, y por lo tanto, cuatro FPs diferentes. Ahora, dadas las mejoras en el lenguaje de programación y tecnologías RDBMS, todas cuatro se posibilitan por medio de una sola pantalla. ¿Deberíamos entonces aún contar cuatro transacciones diferentes de FP?
Entrada externa
En los días de COBOL, una pantalla era una entrada externa. En la actualidad con GUI, una pantalla no es solo una entrada externa, puede además ser una pregunta o salida externa. Por lo tanto, existe confusión en cuanto a que parte de la pantalla es entrada, y que porción es pregunta o salida externa.
Salida externa
Un reporte dirigido hacia la impresora o la pantalla se consideraba una salida externa, y todas las columnas estaban alineadas a través de los programas. Hoy, tenemos escritores de reportes que se encargan de la mayoría de estas tareas de los programadores. De todas formas, el programador debe incluir algún código para llamar el archivo de reporte y pasar los parámetros necesarios a este. Este código adicional tiene solo unas líneas de largo, ya que el programador no esta escribiendo el código para derivar datos, alinear columnas, derivar grupos o totales. El o ella solo están diseñando el reporte, lo que simplifica la derivación de información en gran medida. El esfuerzo del programador para producir los reportes disminuye considerablemente; tanto es así, que un simple reporte con múltiples columnas con los totales de los grupos y un par de tablas, puede ser producido en cuestión de media hora con la ayuda del los escritores de reportes. Por lo tanto ¿qué tan validas son las normalizaciones y reglas de peso de las salidas externas en un FP?
ILF y EIF
Con COBOL, un archivo debía ser descrito en detalle en cada programa o ser traído desde una librería. Un cambio en un archivo causaba cambios en cada sistema que usaba dicho archivo. Los errores en la descripción del archivo en la librería causaba errores de programación y reempezar los programas era una tarea complicada. El mantenimiento de archivos de datos era además una tarea tediosa. Con RDBMS, tener hoy una interfase interactiva de usuario para definir y mantener tablas, además de gestionar automáticamente los índices, se ha vuelto tan fácil que la mayoría de los programadores de hoy pueden no utilizar archivos
indexed sequential access method (ISAM) archivos invertidos, entre otros. He conocido unos cuantos programadores de la actualidad quienes tienen mas de cuatro años de experiencia y nunca han escuchado de los archivos planos. Ahora bien, ¿es aún justificable asignar un gran peso a ILF y EIFs?
Relevancia de la complejidad
En los tiempos de COBOL, el hardware de las computadoras tenían capacidad limitada y las computadoras tenían un número limitado de periferias para abrir varios archivos al mismo tiempo. En la actualidad, con discos duros y RDBMS, cualquier número de archivos puede ser abierto simultáneamente. Igualmente el RAM de las computadoras era limitado, lo cual limitaba el tamaño del programa y el uso de las variables dentro del programa debía hacerse con sumo cuidado. Hoy con la disponibilidad de cantidades masivas de RAM, estas restricciones no son pertinentes en la actualidad.
Además en el pasado, la programación era una actividad compleja ya que usted debía manejar el número de variables declaradas, para no declarar variables innecesarias, e insertar declaraciones para liberar memoria usada por variables que no se requerían más. Cuando se requería abrir más archivos al mismo tiempo, se debía quebrar las funcionalidades en más programas. Pero hoy en día, este no es el caso, y por lo tanto esta complejidad no mas aplicable.
Complejidad y tamaño del software
La metodología FP usa tres niveles de complejidad (ejemplo: baja, promedio y alta), y ello normaliza cada transacción FP. Una transacción simple termina en un número menor de FP. En la medida en que incrementa la complejidad, el número de FP por transacción incrementa. Existen dos preocupaciones al respecto:
- El termino “complejidad” es equivocado aquí. Decimos que algo es complejo si no entendemos o si no hemos sido capacitados para hacerlo. Pero para las personas capacitadas en el desarrollo de software, ¿Cómo se puede aplicar el término complejidad? De pronto el termino mas apropiado seria “densidad”, ya que ello implica que se añaden mas componentes a una sola pantalla.
- La complejidad no incrementa el tamaño, solo el porcentaje de lograrlo. Por ejemplo una milla es una milla independientemente de si se trata de una carretera pavimentada o si es un terreno empinado, pero la distancia permanece como una milla. La metodología FP incrementa el tamaño.
En mi opinión, incrementar el tamaño del software basado en complejidad es insostenible.
Características generales del sistema y factor de ajuste de valor (FAV )
La metodología FP utiliza 14 características generales del sistema (CGS) para calcular un FAV que se usa en el ajuste del tamaño del software. My primera crítica a este respecto es que no es correcto usar FAV o cualquier otro factor para ajustar el tamaño del software, dado que el tamaño no cambia. FAV debería usarse solamente para influenciar el porcentaje de logros (productividad). Mi segunda crítica es que muchos de estos factores no son apropiados en el ambiente de hoy. Una revisión masiva es pertinente en este caso, si es que se deben usar.
Conversión del tamaño del software en esfuerzo
Los partidarios de FP sugieren usar una sola figura de productividad para convertir FP en esfuerzo. Por ejemplo, digamos que se requieren 10 horas por FP. Si el tamaño de un producto de software esta estimado en 100 FPs, el esfuerzo necesario seria 100 multiplicado por 10: 1.000 horas por persona. Ahora, el trabajo de desarrollo de software esta clasificado en cuatro clases principales: 1) análisis de requerimientos, 2) diseño del software, 3) codificación y 4) la prueba. Estas cuatro clasificaciones difieren significativamente una de otra en su naturaleza y la productividad varia en cada clasificación. De allí que se debe utilizar cuatro figuras diferentes de productividad para obtener el esfuerzo necesario para las cuatro diferentes clases de construcción de software.
Conclusión
Cuando se desarrollo por primera vez, la metodología FP lleno un vacío; y fue una excelente medida para evaluar software. Pero la metodología FP se ha vuelto terriblemente obsoleta, principalmente por los desarrollos en cuanto a herramientas de software y hardware. Otras metodologías y unidades de medidas son más relevantes al ambiente actual. Algunos ejemplos incluyen
use case points (UCPs), los cuales están basados en la metodología unified modeling language
(UML); object points (OPs) , que simplifican el conteo y no usa factores ambientales para influir en el tamaño del software;
y software size units (SSUs) , el cual no utiliza los factores de complejidad o de ambiente para influir la valuación del software.
Sobre el autor:
Murali Chemuturi pertenece a la Indian Institution of Industrial Engineering y es un antiguo miembro de la Computer Society of India. Es un veterano en la industria de desarrollo de software y líder actual de
Chemuturi Consultants, quienes proveen consultoría en calidad y capacitación de procesos de software. Su opinión es apreciada, contáctese con el autor:
murali@chemuturi.com.