{"id":1661,"date":"2015-04-14T11:59:24","date_gmt":"2015-04-14T10:59:24","guid":{"rendered":"http:\/\/qualilogy.com\/es\/?p=1661"},"modified":"2015-11-15T09:48:26","modified_gmt":"2015-11-15T08:48:26","slug":"suenan-los-desarrolladores-con-puntos-de-funcion-automatizados-2","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/suenan-los-desarrolladores-con-puntos-de-funcion-automatizados-2\/","title":{"rendered":"\u00bfSue\u00f1an los desarrolladores con Puntos de Funci\u00f3n Automatizados? (II)"},"content":{"rendered":"

\"Qualilogy<\/a>Nos preguntemos en el post anterior<\/a>, \u00bfpor qu\u00e9 los desarrolladores generalmente no tienen conocimiento de los Puntos de Funci\u00f3n? Y si esta medida podr\u00eda serlos \u00fatil.<\/p>\n

Nuestra respuesta es m\u00e1s bien negativa, sobre todo si tenemos en cuenta que tal estimaci\u00f3n se realiza manualmente por consultores y con un proceso a veces bastante complejo. Hay muchas certificaciones cuyo objetivo es validar que un consultor domina estos conceptos y sepa ponerlos en pr\u00e1ctica de manera operacional. <\/p>\n

No es realmente lo que puede atraer desarrolladores que, en mi opini\u00f3n, m\u00e1s bien preferir\u00e1n invertir en una nueva tecnolog\u00eda, un nuevo lenguaje, el \u00faltimo framework de moda, un desarrollo de c\u00f3digo abierto, etc.<\/p>\n

Ahora imaginamos que el c\u00e1lculo de los puntos de funci\u00f3n se pueda automatizar: \u00bfser\u00eda suficiente para que los desarrolladores adopten esta medida?<\/p>\n

Automated Function Points (AFP)<\/h2>\n

El Object Management Group (OMG) ha realizado una normativa de especificaciones<\/a> que describe los requisitos para automatizar la medici\u00f3n de puntos de funci\u00f3n.<\/p>\n

Limitaciones<\/h3>\n

Este documento establece unas diferencias con una estimaci\u00f3n manual de Puntos de Funci\u00f3n. Por ejemplo, la secci\u00f3n\u00a0\u00ab 1.3 Limitations \u00bb explica que esta norma no se aplica a\u00a0\u00ab la medici\u00f3n\u00a0 de los cambios de una aplicaci\u00f3n o del mantenimiento de funcionalidades [existentes], tambi\u00e9n llamado Enhancement Function Points \u00bb.<\/p>\n

Si este es el caso, entonces ser\u00eda m\u00e1s bien una gran discrepancia si los Puntos de Funci\u00f3n automatizados se pueden usar solamente en nuevos desarrollos, y no con las versiones sucesivas de una aplicaci\u00f3n. Sabemos que el 80% o el 90% de los proyectos son de mantenimiento de aplicaciones, los nuevos proyectos son m\u00e1s o menos una minor\u00eda.<\/p>\n

Por otra parte, estas especificaciones no pretenden (\u00ab 2.1 Conformance \u00bb) a un estricto cumplimiento de la medici\u00f3n manual de los Puntos de Funci\u00f3n, sobre todo por las dificultades … para automatizar completamente un proceso manual. La secci\u00f3n\u00a0\u00ab 2.3 Consistency with IFPUG CPM \u00bb explica que \u00ab esta norma toma decisiones expl\u00edcitas \u00bb cuando, en algunas situaciones, las normas promulgadas por el IFPUG (1) pueden ser bastante imprecisas.<\/p>\n

En la misma secci\u00f3n, explica que el consultor IFPUG tendr\u00e1 que realizar algunas interpretaciones acerca del dise\u00f1o y desarrollo de los elementos funcionales, lo que obviamente es imposible por una herramienta de software, que no puede decidir por s\u00ed misma si una estructura de datos o una transacci\u00f3n es importante o no para la aplicaci\u00f3n:\u00a0\u00ab El [software] no puede capturar cualquiera de las intenciones del dise\u00f1ador que no deje una huella en el c\u00f3digo fuente. \u00bb<\/p>\n

As\u00ed que la propia norma establece claramente que \u00ab contar Puntos de Function automatizados … puede diferir de los recuentos manuales efectuados por un consultor IFPUG certificado \u00bb.<\/p>\n

Implementaci\u00f3n de la norma<\/h3>\n

El resto del documento enumera los pasos necesarios para contar AFP. No voy a detallar estas operaciones, sino simplemente listar lo que, en base a mi experiencia en herramientas de an\u00e1lisis de c\u00f3digo, puede causar discrepancias con el calculo manual de FP o tener consecuencias para la aplicaci\u00f3n de esta norma en el ciclo de vida de un proyecto.<\/p>\n

Fronteras<\/h3>\n

El primer paso consiste en definir las fronteras (‘outbounds’) de la aplicaci\u00f3n a nivel funcional, desde el punto de vista del usuario, para determinar lo que est\u00e1 en la aplicaci\u00f3n, y entonces el c\u00f3digo que analizar, y qu\u00e9 es externo a la aplicaci\u00f3n y por lo tanto fuera del an\u00e1lisis automatizado de Puntos de Funci\u00f3n.<\/p>\n

Consideramos como ejemplo una sencilla gesti\u00f3n de hojas de actividades (timesheets) para una empresa de TI en la que un empleado ingresa las tareas y el tiempo dedicado para un cliente y al final emitir factura. Esta aplicaci\u00f3n no gestiona ella misma los empleados de la empresa, pero va a recuperar esta informaci\u00f3n del sistema de gesti\u00f3n de Recursos Humanos. Del mismo modo, los diferentes tipos de actividades, facturables o no, suelen ser gestionados por el sistema contable. Y la informaci\u00f3n sobre el cliente y el servicio a prestar deber\u00edan reflejarse en el sistema comercial.<\/p>\n

Si nuestra aplicaci\u00f3n maneja su propio acceso a los datos de estos otros sistemas, entonces estos son internos y deben tenerse en cuenta en nuestra evaluaci\u00f3n de Puntos de Funci\u00f3n Automatizados. Sin embargo, si se utiliza a componentes de estos otros sistemas para conseguir los datos necesarios, entonces estos tratamientos son externos y no est\u00e1n en el \u00e1mbito de an\u00e1lisis de la aplicaci\u00f3n.<\/p>\n

A veces, para no decir a menudo, la elecci\u00f3n ser\u00e1 dif\u00edcil, si no imposible. Si tenemos unos servicios Web entre diferentes aplicaciones, \u00bfdonde conectarlos? \u00bfA cual aplicaci\u00f3n? \u00bfDeben ser considerados? Tenemos unos CopyBooks, equivalente a ‘include’ en aplicaciones Mainframe-Cobol, que describen las tablas DB2 y son reutilizables por todas las aplicaciones que acceden a estas tablas. Si 15 aplicaciones utilizan una misma tabla, todas trabajan con el mismo CopyBook (bueno, esto es lo que se supone que deber\u00edan hacer). \u00bfA que aplicaci\u00f3n vincular este CopyBook? \u00bfY qu\u00e9 hay de un ERP u otro paquete de softwares que consta con varios m\u00f3dulos altamente integrados y imbricados?<\/p>\n

Desglose del c\u00f3digo de la aplicaci\u00f3n<\/h3>\n

Obviamente, tenemos ya que hacernos estas mismas preguntas cada vez que se configura un nuevo an\u00e1lisis de c\u00f3digo, ya sea para el recuento de puntos de funci\u00f3n o no. Pero si est\u00e1s interesado s\u00f3lo en la calidad del c\u00f3digo, que un tal componente pertenece o no a dicha aplicaci\u00f3n no es cr\u00edtico: lo que deseas es comprobar si el componente tiene o no violaciones de buenas pr\u00e1cticas de programaci\u00f3n. Esto es lo que suele ocurrir, por ejemplo, para aplicaciones en Cobol Mainframe, donde las aplicaciones no tienen realmente fronteras. M\u00e1s a menudo, tratamos de configurar los an\u00e1lisis de acuerdo con algunos criterios \u00fatiles para nuestra evaluaci\u00f3n de la calidad, por ejemplo, en funci\u00f3n de su tipo transaccional o batch, porque un defecto en el rendimiento va a ser peor para una aplicaci\u00f3n TP con un usuario frente a la pantalla que para una aplicaci\u00f3n Batch sin usuario y que se ejecuta durante la noche.<\/p>\n

Cuando los l\u00edmites de aplicaci\u00f3n no son claras, el segundo criterio m\u00e1s utilizado para el desglose del c\u00f3digo y la configuraci\u00f3n de los an\u00e1lisis es de tipo organizacional: reunir todos los componentes administrados por el mismo equipo, y que normalmente se encuentran en un espacio (directorio de red, biblioteca mainframe, repositorio de una herramienta de gesti\u00f3n de configuraci\u00f3n, etc.), administrado por el equipo. Esta configuraci\u00f3n basada en ‘quien hace qu\u00e9’ resulta cr\u00edtica en algunos casos de uso, por ejemplo para un Quality Gate o un benchmarking de la calidad de c\u00f3digo entre distintos proveedores o equipos internos. En estos casos, estamos interesado en los defectos a\u00f1adidos o corregidos en versiones posteriores de la aplicaci\u00f3n, con el fin de decidir sobre aceptar (OK) o rechazar (KO) una nueva versi\u00f3n o si tu proveedor externo est\u00e1 trabajando correctamente o no, si hace o no los esfuerzos para mejorar y c\u00f3mo se compara con otros proveedores.<\/p>\n

Este es tambi\u00e9n el criterio organizativo \u2013 quien gestiona cual componente \u2013 que debemos utilizar si queremos medir la productividad de los desarrolladores. Pero veo aparecer algunas dificultades adicionales. En primer lugar, la necesidad de precisi\u00f3n y de rigor es m\u00e1s importante. Si le dices a un desarrollador que has encontrado el mismo incumplimiento de las buenas pr\u00e1cticas de programaci\u00f3n en 10 componentes que \u00e9l ha cambiado, y, de hecho, uno de ellos no est\u00e1 dentro de su responsabilidad, sin embargo, \u00e9l repiti\u00f3 esta mala pr\u00e1ctica en 9 de cada 10 componentes, y por lo tanto debe mejorar. De hecho, en el caso de Quality Gate, una sola ocurrencia es suficiente si est\u00e1 de tipo Blocker. Pero si le dices a un desarrollador o un proveedor que \u00e9l no trabaja lo suficiente, y olvides un componente en tu an\u00e1lisis automatizado de los puntos de funci\u00f3n, tu conclusi\u00f3n ser\u00e1 muy probablemente discutida y de manera bien vehemente. Un desarrollador puede pasar varias horas o varios d\u00edas en un solo m\u00e9todo o una sola funci\u00f3n. La omisi\u00f3n de un \u00fanico objeto entre muchos miles puede falsear los resultados, as\u00ed que mucho cuidado.<\/p>\n

Otro problema: te interesa solamente el c\u00f3digo modificado por el equipo del proyecto, porque del mismo modo que no puedes responsabilizar un outsourcer de los defectos ya presentes en el c\u00f3digo que recibi\u00f3 por mantenimiento, tampoco puedes medir la productividad del c\u00f3digo ya existente, sino del c\u00f3digo que \u00e9l ha modificado o escrito. Pero no se puede medir los puntos de funci\u00f3n del c\u00f3digo modificado solo: es necesario identificar las estructuras de datos y las transacciones correspondientes, desde la capa de presentaci\u00f3n hasta la capa de datos. Esto s\u00f3lo es posible si vuelves a analizar toda la aplicaci\u00f3n, calculando la diferencia del n\u00famero de puntos de funci\u00f3n con una versi\u00f3n anterior. Y eso solamente si consideramos que esta norma se aplica a las nuevas versiones (v\u00e9ase la limitaci\u00f3n mencionada anteriormente).<\/p>\n

Por lo que es m\u00e1s complicado, pero tambi\u00e9n m\u00e1s dif\u00edcil de interpretar. Imaginamos dos equipos que produjeron 100 puntos de funci\u00f3n, el primero en una aplicaci\u00f3n que mide 1 000 FP, el segundo en una aplicaci\u00f3n que tiene 10 000 FP. Supongo que el esfuerzo no es lo mismo, del mismo modo que no podemos comparar el trabajo de a\u00f1adir 1 000 l\u00edneas de c\u00f3digo (LOC) en una aplicaci\u00f3n que tiene ya 10 000 o en 100 000 LOC. De hecho, algunos expertos creen que el recuento de puntos funci\u00f3n debe realizarse de manera diferente para aplicaciones de tama\u00f1o muy peque\u00f1o o muy alto.<\/p>\n

\u00daltima cosa: hay que excluir del an\u00e1lisis las librar\u00edas, los frameworks, los componentes reutilizables y otras dependencias externas a la aplicaci\u00f3n, sino tambi\u00e9n todas las tablas o los archivos que no entran dentro de la aplicaci\u00f3n. Sin embargo, se analizar\u00e1 estos objetos con el fin de encontrar las transacciones entre las diferentes capas de la aplicaci\u00f3n y por lo tanto les consideremos en el an\u00e1lisis, pero \u00ab claramente identificados como externos \u00bb, como dictan las especificaciones de la norma OMG. Este documento pone de relieve la importancia de esta etapa de definir el alcance del an\u00e1lisis, y para ello se requiere la presencia de un experto en aplicaci\u00f3n (SME), o incluso el ‘aplication owner’.<\/p>\n

An\u00e1lisis<\/h3>\n

El resto del documento describe los pasos del proceso de recuento AFP:<\/p>\n

    \n
  • Identificar todas las funciones en el c\u00f3digo y clasificarlas en funciones de datos y funciones transaccionales,<\/li>\n
  • teniendo en cuenta la naturaleza interna o externa de las estructuras de datos,<\/li>\n
  • antes de realizar la estimaci\u00f3n de puntos de funciones para cada una de ellos<\/li>\n<\/ul>\n

    Estos requisitos exigen que el software de an\u00e1lisis de c\u00f3digo sea capaz de tener en cuenta las bases de datos, relacionales o no \u2013 algunas aplicaciones Cobol utilizan bases de datos jer\u00e1rquicas \u2013 pero tambi\u00e9n todo tipo de archivos, lo que no es muy natural para una herramienta de este tipo.<\/p>\n

    Tambi\u00e9n es necesario identificar cada estructura l\u00f3gica de datos con el fin de vincularlas con las transacciones. Sin embargo, estas estructuras pueden estar dispersas en varias tablas, y el documento especifica las restricciones que deben respetarse para identificar estructuras de tipo ‘master-detail’. En nuestro ejemplo de gesti\u00f3n de Timesheets, una persona rellena varias hojas de actividad, posiblemente para diferentes clientes. Cada timesheet constar\u00e1 de varias actividades, lo que significa que la tabla ‘Timesheet’ es de tipo ‘detail’ para las entidades ‘Proveedor’ o ‘Cliente’, y ‘master’ para ‘Actividades’.<\/p>\n

    El est\u00e1ndar OMG recomienda utilizar las reglas de nomenclatura para reconocer tablas, vistas, \u00edndices, claves, etc. que identifican estas estructuras de datos y sus relaciones. Esto implica que:<\/p>\n

      \n
    • Existen estas reglas.<\/li>\n
    • Est\u00e1n aplicadas por el equipo del proyecto.<\/li>\n
    • El software de an\u00e1lisis est\u00e1 configurado para reconocer estas reglas, y los objetos correspondientes.<\/li>\n<\/ul>\n

      Tambi\u00e9n debe ser capaz de analizar cualquier tipo de archivo y su estructura interna \u2013 tabular (flat-files, archivos CSV, etc.) o arborescente (xml, html, etc.). S\u00f3lo que en este caso no tenemos claves o \u00edndices para saber como agrupar los datos en estructuras l\u00f3gicas, y el software de c\u00e1lculo de AFP debe elegir \u2013 por lo general, considerando un archivo como una \u00fanica entidad l\u00f3gica \u2013 opci\u00f3n que no escoger\u00eda necesariamente un consultor IFPUG.<\/p>\n

      Hay que comprobar tambi\u00e9n si un archivo es temporal o no, y si los datos que contiene son gestionados o no por un usuario. Por ejemplo, un archivo log de errores, utilizable s\u00f3lo por el programador, se debe excluir del \u00e1mbito de an\u00e1lisis.<\/p>\n

      Una vez identificadas las estructuras de datos, tenemos que hacer lo mismo con las transacciones que gestionan los datos a trav\u00e9s de las capas de la aplicaci\u00f3n, e identificar a los ‘inputs’ de los ‘outputs’ a trav\u00e9s de las operaciones realizadas: leer (‘read’) o escribir (‘write’) o editar\/borrar datos. Esto implica, seg\u00fan la norma de:<\/p>\n

        \n
      • \u00ab capturar las transacciones desde\u00a0la interfaz de usuario \u00bb,<\/li>\n
      • \u00ab para identificar los eventos que interact\u00faan con la capa de datos \u00bb y<\/li>\n
      • \u00ab los outputs creados por estas transacciones de [gesti\u00f3n de] datos.<\/li>\n<\/ul>\n

        Tambi\u00e9n de acuerdo con el documento, identificar tales operaciones requiere:<\/p>\n

          \n
        • Poder encontrar v\u00ednculos entre los diferentes objetos, que constituyen un ‘camino’ (path) desde el principio y hasta el final de la transacci\u00f3n;<\/li>\n
        • Poder tener en cuenta los numerosos caminos existentes, con el fin de agrupar todas las operaciones en las estructuras de datos en una \u00fanica transacci\u00f3n;<\/li>\n
        • Poder declarar en la herramienta los elementos de c\u00f3digo externos (analizados o no) con el fin de reconstruir las transacciones, o al menos una lista de los elementos que faltan. Para reconstruir una transacci\u00f3n completa, a veces se necesitar\u00e1 analizar los componentes externos a la aplicaci\u00f3n, pues incluirlos en el an\u00e1lisis pero excluy\u00e9ndolos del recuento.<\/li>\n<\/ul>\n

          Automated Function Points: \u00bfqu\u00e9 medida?<\/h2>\n

          Como podemos ver, el documento de la norma OMG especifica los requisitos para el uso de los Puntos de Funci\u00f3n automatizados, as\u00ed como sus limitaciones. Los puntos que considero m\u00e1s importante a recordar son los siguientes.<\/p>\n

          Per\u00edmetro<\/h3>\n

          La norma no se aplica a \u00ab la medici\u00f3n de los cambios de una aplicaci\u00f3n o del mantenimiento de sus funcionalidades \u00bb, y por lo tanto s\u00f3lo se aplicar\u00eda a los nuevos desarrollos. Si este es el caso, limita much\u00edsimo su uso e su inter\u00e9s.<\/p>\n

          Medidas AFP e IFPUG<\/h3>\n

          La norma no pretende a una estricta conformaci\u00f3n con la medici\u00f3n manual de Puntos de Funci\u00f3n, ya que \u00ab contar Automated Function Points …\u00a0puede diferir de los recuentos manuales realizados por un consultor IFPUG certificado \u00bb.<\/p>\n

          Esto me parece un primer punto importante: los Puntos de Funci\u00f3n automatizados no son Puntos de Funci\u00f3n IFPUG. Es otra medida, que tiene la ventaja de ser computable autom\u00e1ticamente por una herramienta, y por lo tanto con menos esfuerzo que un recuento manual, pero tambi\u00e9n con un resultado diferente.<\/p>\n

          Configuraci\u00f3n<\/h3>\n

          Contar Puntos de Funci\u00f3n automatizados requiere identificar y ensamblar en componentes funcionales todas las estructuras de datos y las transacciones, y decidir cu\u00e1les son internas o externas, temporales o no, para el usuario o no, y configurar todo eso. Esto supone:<\/p>\n

            \n
          • El conocimiento de la aplicaci\u00f3n por el SME o experto del proyecto.<\/li>\n
          • El conocimiento de los Puntos de Funci\u00f3n automatizados para determinar el alcance del an\u00e1lisis y los elementos que se deben tomar en cuenta.<\/li>\n
          • El conocimiento de la herramienta y sus par\u00e1metros para configurar el an\u00e1lisis, de acuerdo con los dos puntos anteriores.<\/li>\n<\/ul>\n

            Esta fase de configuraci\u00f3n es obviamente crucial si queremos lograr un resultado m\u00e1s objetivo y por lo tanto lo m\u00e1s cre\u00edble posible cuando se trata de medir la productividad de un equipo.<\/p>\n

            An\u00e1lisis y validaci\u00f3n<\/h3>\n

            Un recuento de Puntos de Funci\u00f3n automatizado por una herramienta supone que esta sea capaz de:<\/p>\n

              \n
            • Analizar cualquier tipo de componente.<\/li>\n
            • Identificar todos los v\u00ednculos entre estos componentes.<\/li>\n
            • Ensamblar todos estos enlaces en caminos (‘path’) para constituir transacciones, con el m\u00ednimo posible de falsos positivos.<\/li>\n<\/ul>\n

              Pero es raro que una herramienta de an\u00e1lisis de c\u00f3digo sea capaz de reconocer y analizar cualquier tipo de objeto y de archivo. Por ejemplo, una caracter\u00edstica importante de nuestra aplicaci\u00f3n de gesti\u00f3n de Timesheets ser\u00e1 de producir hojas de actividades para su validaci\u00f3n antes de facturaci\u00f3n, usualmente en diferentes formatos: Excel, PDF, etc. No conozco ninguna herramienta de an\u00e1lisis de c\u00f3digo que reconozca este tipo de archivo.<\/p>\n

              Buscar todos los v\u00ednculos entre los componentes puede ser dif\u00edcil o imposible para algunas tecnolog\u00edas. El uso de frameworks (Spring, Hibernate, etc.) complica este tipo de an\u00e1lisis, y supone un trabajo importante para validar los resultados con el fin de evitar falsos positivos, luego para comprobar las transacciones y el recuento de los puntos de funci\u00f3n.<\/p>\n

              Conclusi\u00f3n<\/h3>\n

              En conclusi\u00f3n, creo que los Puntos de Funci\u00f3n automatizados son una medida diferente, que produce resultados distintos de un c\u00e1lculo manual que lleva a cabo un consultor IFPUG. En una situaci\u00f3n ideal, se requerir\u00eda la presencia de un tal consultor para participar en la definici\u00f3n del alcance del an\u00e1lisis, la configuraci\u00f3n de la herramienta, la validaci\u00f3n de los resultados. Esto suponiendo que la herramienta sea capaz de identificar todos los componentes, los v\u00ednculos entre ellos, todas las estructuras de datos y las transacciones, etc.<\/p>\n

              Incluso en tal caso ideal, creo que la diferencia entre una estimaci\u00f3n manual y una medici\u00f3n de AFP es de al menos 10% a 20%, con mayor frecuencia entre el 40% y el 50%. Eso me parece un m\u00ednimo para unas aplicaciones o tecnolog\u00edas espec\u00edficas, y la diferencia podr\u00eda ser m\u00e1s importante, por ejemplo, para una aplicaci\u00f3n Cobol Batch (muchos archivos), un\u00a0ERP con diferentes m\u00f3dulos\u00a0integrados, en caso de frameworks, etc.<\/p>\n

              Automated Function Points: \u00bfpara qui\u00e9n?<\/h2>\n

              La puesta en marcha de Automated Function Points requiere un esfuerzo significativo, que debe repetirse cada vez que la aplicaci\u00f3n ser\u00e1 sometida a grandes cambios en sus funcionalidades (suponiendo que esta norma tambi\u00e9n se aplica a las nuevas versiones).<\/p>\n

              Esto excluye inmediatamente su uso en un ciclo de integraci\u00f3n contin\u00faa, cuando el prop\u00f3sito de un an\u00e1lisis de c\u00f3digo es identificar violaciones cr\u00edticas o bloqueantes de buenas pr\u00e1cticas de programaci\u00f3n para, por ejemplo, corregirlos antes de un Quality Gate o para evitar la inflaci\u00f3n de la Deuda T\u00e9cnica. As\u00ed que no veo c\u00f3mo los desarrolladores pueden estar interesados \u200b\u200ben AFP e integrarlos en un ciclo de desarrollo de software.<\/p>\n

              Esto no significa que los AFP no demuestran beneficios. Dos consultores IFPUG calculando manualmente puntos de funci\u00f3n conseguir\u00e1n muy a menudo resultados diferentes, mientras que una medici\u00f3n automatizada producir\u00e1 siempre el mismo resultado, de manera repetible. El esfuerzo de implementaci\u00f3n, incluso si es importante, sin embargo, ser\u00e1 inferior a la inversi\u00f3n requerida para una estimaci\u00f3n manual, especialmente para grandes aplicaciones.<\/p>\n

              Simplemente, se trata de otra medida que requiere una validaci\u00f3n importante de los elementos de an\u00e1lisis\u00a0 \u2013 inputs\/outputs, internos\/externos, temporal o no, para el usuario o no, estructuras de datos y transacciones, falsos positivos, etc. \u2013 para que se pueda utilizar como una medida de tama\u00f1o funcional de una aplicaci\u00f3n.
              \nCreo que est\u00e1 reservado para los expertos en an\u00e1lisis de c\u00f3digo, pero tambi\u00e9n con un buen conocimiento de los puntos de funci\u00f3n, si se quiere utilizar para hacer benchmarkings entre diferentes aplicaciones y tecnolog\u00edas.<\/p>\n

              Me parece peligroso utilizarla para medir la productividad de los equipos o los proveedores: ser\u00e1 demasiado f\u00e1cil de impugnar los resultados producidos en dicho contexto.<\/p>\n

              Creo que puede ser \u00fatil como parte de una retro-documentaci\u00f3n antes de transferir una aplicaci\u00f3n a un otro equipo, una refactorizaci\u00f3n o una reingenier\u00eda (portar la aplicaci\u00f3n a otra tecnolog\u00eda). En estos casos, todo lo que puede facilitar la comprensi\u00f3n funcional de la aplicaci\u00f3n, la estimaci\u00f3n de la cobertura de pruebas y la estimaci\u00f3n de la carga de trabajo ser\u00e1 \u00fatil, incluso si la medida carece de precisi\u00f3n.<\/p>\n

              Y t\u00fa, ves otros casos de uso de esta medida?<\/p>\n

               <\/p>\n

              (1) IFPUG : International Function Points User Group, que produce el Function Point Counting Practices Manual (FP CPM).<\/p>\n","protected":false},"excerpt":{"rendered":"

              Nos preguntemos en el post anterior, \u00bfpor qu\u00e9 los desarrolladores generalmente no tienen conocimiento de los Puntos de Funci\u00f3n? Y si esta medida podr\u00eda serlos \u00fatil. Nuestra respuesta es m\u00e1s bien negativa, sobre todo si tenemos en cuenta que tal estimaci\u00f3n se realiza manualmente por consultores y con un proceso a veces bastante complejo. Hay […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-1661","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1661"}],"collection":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/comments?post=1661"}],"version-history":[{"count":26,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1661\/revisions"}],"predecessor-version":[{"id":1687,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1661\/revisions\/1687"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=1661"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=1661"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=1661"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}