La lista de Preguntas Frecuentes (FAQ) sobre el Análisis de Puntos de Función es una sintesis de preguntas y respuestas (Q&A) sobre el método IFPUG en específico y tambien sobre métricas de software en general. Ella incluye tambien las aplicaciones; en especial, en su inserción en estimaciones, presupuestos y en la contratación del desarrollo y sustentación de software en un contexto de Desarrollo Ágil o no.
Ella es un producto de las respuestas de nuestros instructores, consultores y ejecutivos a las preguntas levantadas por nuestros clientes y amigos a lo largo de más de 20 años ofreciendo servicios de outsourcing, consultoria e treinamento.
Usted puede colaborar, sugiriendo una nueva pregunta para inclusión en nuestro FAQ! Para eso, indicamos esa intención y compartir con nosotros.
Si hay algun termino desconocido, aproveche para conocer el Glosario de APPF.
¿Qué es el Análisis de Puntos de Función?
El FPA surgió a mediados de la década de 1970 como resultado de un proyecto desarrollado por Allan Albrecht, investigador de IBM. Su trabajo involucraba un estudio de productividad para proyectos de software desarrollados por una unidad de servicios de IBM.
Como no todos los proyectos usaban el mismo lenguaje de programación, Allan Albrecht buscó elaborar una medida que contemplara aspectos externos al software, en este caso, sus funcionalidades. Esta medida basada en la visión del usuario, era independiente del lenguaje de programación o de cualquier otro aspecto relacionado con la implementación del software. Él la denominó Puntos de Función.
En Octubre de 1979, el autor presentó y publicó el resultado de este estudio en el siguiente artículo: Measuring Application Development Productivity – Allan J. Albrecht (Versión en español: Midiendo la productividad del desarrollo de aplicativos). Ésto despertó el interés por parte de otras empresas y su uso comenzó a difundirse en los años siguientes hasta culminar con la formación del IFPUG en 1986. El contenido de este artículo además de ser una curiosidad histórica, tiene aplicación actual.
No.
A pesar de haber surgido en IBM, el resultado de ese proyecto fue abierto a toda la comunidad de software en 1984.
Los 7 principales beneficios del Análisis de Puntos de Función (APF)
No.
La gran ventaja del FPA es que está basada en la VISIÓN DEL USUARIO, permitiendo que sus conceptos puedan ser comprendidos tanto por el desarrollador como por el usuario.
El objetivo de la técnica es medir la funcionalidad que el software ofrece al usuario independientemente de la tecnología usada para la implementación del mismo.
Esa medición es basada solamente en los requerimientos que el software debe atender.
El estándar reconocido por la industria del software para el FPA es el Manual de Prácticas de Medición de Puntos de Función (CPM – Counting Practices Manual) regalado y actualizado por el IFPUG – International Function Point Users Group.
El IFPUG es una entidad sin ánimo de lucro, compuesta por personas y empresas de diversos países, cuya finalidad es promover una mejor gerencia de los procesos de desarrollo y mantenimiento de software a través del uso del FPA.
Si.
Desde la publicación de la propuesta del FPA en 1979, diversos refinamientos fueron incorporados a la técnica a lo largo de los años. Y este proceso aún continúa.
Sin embargo, la esencia de la técnica cambió poco, ya que es orientada a medir las funcionalidades que el software ofrece al usuario, independientemente de la plataforma tecnológica, metodología de desarrollo o lenguaje de programación usados para su construcción. Después de la fundación del IFPUG en 1986, fue creado un sistema consistente para su evolución.
Existe un comité responsable por la actualización del Manual de Prácticas de Medición, que es la referencia estándar para el uso del FPA y que actualmente se encuentra en la versión 4.3, publicada en Enero del 2010. No hay una periodicidad definida para que el IFPUG publique actualizaciones de su manual. Sin embargo, estas actualizaciones no buscan cambios radicales; intentan ofrecer claridad en relación a la definición de las reglas de medición; mejorando así la consistencia de las mediciones y reduciendo la subjetividad en las interpretaciones.
CFPS – ¿Qué es la Certificación de Especialista en Puntos de Función?
No hay un plazo para la preparación del examen; esto varia de acuerdo al profesional. Si el candidato usa FPA en su día a día, ciertamente necesitará de menos tiempo que aquel que lo hace apenas de forma periódica. En general, un plazo de tres meses de preparación es suficiente.
El texto de referencia fundamental es el Manual de Prácticas de Medición. No es necesario memorizar todo su contenido. Se recomienda que se lea por completo y que no queden dudas. Algunas preguntas de la prueba son basadas en sus ejemplos. Aunque todo el contenido es extraído del manual, éste no aborda nada referente al proceso de certificación. Por lo tanto, es importante buscar otras fuentes de estudio. El mejor indicador de preparación son los ejercicios simulados de la prueba.
Nuestro curso de Preparación para el examen CFPS ofrece mas de 1000 preguntas similares a las de la prueba, además del apoyo de nuestro equipo de instructores hasta la presentación del examen. En la versión de prueba del curso de Preparación para el examen CFPS es posible realizar algunos ejercicios, accesar a otros recursos e inclusive desarrollar un micro simulacro con 30 preguntas de forma gratuita.
CFPS – ¿Cuánto cuesta la Certificación de Especialista en Puntos de Función?
El IFPUG posee afiliados en más de 40 países alrededor del mundo, teniendo una fuerte presencia en Alemania, Australia, Brasil, Canadá, Corea del Sur, Estados Unidos, India, Inglaterra, Italia, Colombia, Uruguay, México, Argentina y Holanda.
Algunos ejemplos de empresas en el mundo que usan Análisis de Puntos de Función son: IBM, Unisys, Xerox, HP, CitiGroup, Tata Consulting Services, Lockheed Martin-EIS, Booz Allen & Hamilton, Nielsen Media Research, Banco de Brasil, Citibank, HSBC, Indra, Bank of Canada, Ralston Purina Co., Banco de la República (Banco Central de Colombia), Northrop Grumman Corp, Samsung SDS Co Ltd, BASF Corporation, Banco Central de Chile, Accenture, IBM, Petrobras, Pepsi Co, Compuware, Pricewaterhouse Cooper, Vale, Banco Santander, Petrobras y Telefónica, entre otras.
Si.
El FPA es una técnica independiente de la tecnología utilizada para modelar o implementar un software. Por ello, un sistema tendrá el mismo tamaño en puntos de función utilizando la metodología OO o cualquier otra.
La diferencia radica en la productividad (hora/FP). Haciendo una analogía con la construcción civil: Se puede construir una casa de 100 m2 de la manera convencional o utilizando módulos prefabricados. En ambos casos, el tamaño de la casa será el mismo, sólo el tiempo o costo de construcción que varian.
Las organizaciones desean que sus procesos de gestión de proyectos sean escalables de acuerdo con el tamaño del proyecto; los grandes proyectos son más rigorosos y formales en su gestión que los pequeños. Usar la misma metodología para cualquier proyecto, significa someter a los proyectos menores a un costo relativamente alto de gestión, es decir, es un desperdicio de recursos.
No existe una definición estándar en la industria para determinar si un proyecto de software es pequeño, medio y grande. Este es un concepto relativo. En realidad no siempre es necesario encuadrar el proyecto en esos tres niveles, Grande, Mediano o Pequeño. Las organizaciones que trabajan con proyectos siempre de corte similar, no necesitan esta clasificación y usar un único proceso de gestión para todos sus proyectos puede ser la mejor metodología. Algunas empresas usan procesos de gestión para sólo dos tipos de proyectos (pequeños y grandes) y otras definen más de tres niveles para la clasificación de los proyectos, por ejemplo: pequeño, medio, grande y muy grande; esta situación tiende a ser menos común.
En conclusión, el concepto de proyecto pequeño, mediano y grande es relativo. Cada organización puede establecer sus propios criterios para segmentar sus proyectos con relación al tamaño.
¿Cuál es el precio del punto de función (cuanto cuesta)?
Normalmente, este tipo de trabajo tiene un alcance muy limitado. Como consecuencia es difícil establecer una relación entre el tamaño funcional y otras métricas fundamentales como esfuerzo, plazo y costo. Sin embargo, se debe recordar que el FPA no es simplemente una herramienta para generación de estimaciones utilizada en la planeación de proyectos. La naturaleza de ese trabajo se caracteriza no como un proyecto, sino como una operación continua.
El dimensionamiento de las órdenes de servicio que representan los requerimientos (no siempre funcionales), que son objeto de mantenimiento, puede no presentar una relación linear con el esfuerzo de su realización. Sin embargo, teniendo en cuenta el universo comprendido por el conjunto de estas solicitudes en períodos mayores, se puede llegar a conclusiones distintas.
Por ejemplo, una determinada solicitud de mantenimiento que no tenga el aumento, modificación o eliminación de funcionalidad de determinado sistema. En este caso, es inútil saber que el tamaño funcional del mantenimiento es de cero puntos de función. Sin embargo, el sistema donde se hace el mantenimiento tiene un tamaño funcional y permite acompañar la evolución de la cantidad de horas de mantenimiento por punto de función de este sistema. Tal tendencia ayuda a evaluar si es necesario sustituirlo por un nuevo.
Suponga que en una organización hay un proceso donde, después de que la orden de servicio es atendida por el equipo de mantenimiento, el producto pasa por un proceso de homologación. El conjunto de funcionalidades en homologación puede ser dimensionado en términos de puntos de función. De la misma forma, puede ser documentada la cantidad de defectos identificados. El acompañamiento del inter-relacionamiento de estas dos métrica, Puntos de Función y Defectos, durante un periodo de tiempo permite identificar los problemas en el proceso de mantenimiento. Con base en esa tendencia, es posible emprender acciones para disminuir esta relación.
Los Puntos de Función miden el tamaño funcional del software y no el esfuerzo involucrado en su implementación. Cuanta más linealidad exista entre el tamaño funcional y el esfuerzo, es decir, la productividad, mayor será el valor práctico de la medida obtenida. Cuanto más lineal sea esta relación, más fácilmente pueden ser extrapoladas otras medidas a partir del tamaño funcional, como el costo y el esfuerzo.
En un nivel micro, en la evaluación de dimensionamiento de dos transacciones, el potencial de desviación en la productividad derivada es alto. En la medida en que se expande esta muestra percibimos que las situaciones extremas se compensan y, en media, hay una linealidad mayor entre el esfuerzo y el tamaño funcional.
En un proyecto especifico, también existen situaciones en las que el cálculo de líneas de código, que es una medida alternativa a puntos de función, no está directamente relacionada con el esfuerzo involucrado en la especificación, documentación y pruebas. Por ejemplo, en dos proyectos con diferentes requerimientos de calidad o demanda en la especificación, uno será más “complejo” y tendrá más necesidad de esfuerzo de desarrollo,dando como resultado un número diferente de líneas de código. Esto, sin mencionar, otras limitaciones inherentes a la métrica de LOC.
Existen diversos software que, a partir de su modelo o código fuente, calculan su tamaño en puntos de función. Sin embargo, el resultado presentado por distintas herramientas y el cálculo manual cambia. La variación radica en los archivos, telas, reportes y otros elementos que utiliza cada una. Sin embargo, muchas veces hay una relación directa entre estos objetos, las funciones de dados y las transacciones de Análisis de Puntos de Función. Se debe tener en cuentra que la técnica mide solamente funciones lógicas del sistema. Y estas herramientas tienen dificultad en diferenciar funciones lógicas de funciones físicas.
Por ejemplo, no todos los archivo o tablas de un programa corresponden a un archivo lógico interno o un archivo de interface externa, a pesar de que un proceso sea implantado a través de diversas telas. Para que la medición sea hecha correctamente, el software debería tener la habilidad para hacer este discernimiento, es decir, leer el programa e interpretar los requerimientos de usuario. Por el momento, no existe un software con esta inteligencia artificial.
Otras herramientas utilizan la técnica de backfiring, que consiste en derivar el número de puntos de función a partir de la cantidad de líneas de código del programa. Se basa en una relación preestablecida entre LOC y PF. Sin embargo, esta técnica tiene muchas críticas y su aplicación es restringida. Existen softwares de apoyo al proceso de cálculo de puntos de función que automatizan parte del proceso. La decisión y análisis de lo que debe ser considerado, continua siendo responsabilidad de un usuario humano.
Este método consiste en derivar el número de puntos de función de la aplicación a partir de su tamaño físico. Se miden las líneas de código (LOC), utilizando un factor de conversión constante dependiente del lenguaje de programación. Una vez que el cálculo de líneas de código es hecho a través de herramientas automáticas, el número de puntos de función podría ser derivado de inmediato. Por ejemplo, utilizando un factor de conversión de 80 LOC/PF y una aplicación con 80.000 líneas de código Java, da como resultado 1.000 puntos de función para esa misma aplicación.
Sin embargo, esta técnica presenta errores frecuentemente cuando es comparada con un cálculo manual de puntos de función de una aplicación. Esto se debe a que se asume una relación linear entre el tamaño funcional (en puntos de función) y el tamaño físico del programa (en líneas de código), que son grandezas distintas. Otro aspecto es que no hay consenso entre las distintas organizaciones que publican estas relaciones. Los números presentados pueden divergir hasta un 100%. Cuando se tiene un escenario del sistema desarrollado con ua combinación de lenguaje de programación, la cuestión se complica cada vez más. La siguiente tabla presenta un ejemplo de esas variaciones para el lenguaje COBOL:
| Fuente | Fator de Conversión(COBOL) |
| Quantitative Software Management | 77 LOC/PF |
| Capers Jones | 107 LOC/PF |
| David Consulting Group | 177 LOC/PF |
Estas variaciones pueden explicarse por las distintas premisas usadas en la definición de línea de código y bases de proyectos con características muy distintas. DE ahí nace la necesidad de calibrar ese factor de conversión para la realidad de los proyectos desarrollados por la propia organización. Sin embargo, para efectuar esa calibración se debe usar una muestra representativa de proyectos desarrollados en determinado lenguaje y un profesional con experiencia para saber interpretar los resultados y las razones de posibles distorsiones para ese factor de conversión.
Debido a esos factores, aplicar backfiring para obtener un tamaño en puntos de función a partir de líneas de código, es una técnica arriesgada y sujeta a un margen de error mayor. El proprio IFPUG resalta en su FAQ, que puede ser usada (con cautela) en sistemas legados, en los que un cálculo manual de puntos de función es inviable en la práctica y la precisión no es un factor crítico.
Algunos profesionales creen que backfiring es una manera rápida y barata de obtener el tamaño en puntos de función del portfolio de aplicaciones de una organización. Otros argumentan que es mejor invertir en el cálculo manual de los puntos de función y tener confiabilidad de los datos con compensación a largo plazo.
Por otro lado, muchos modelos de estimación de software, como el COCOMO II, utilizan como datos de entrada el tamaño en líneas de código. En esos casos, es común realizar el inverso: obtener el número de líneas de código a partir del tamaño en puntos de función, debido a que en las fases iniciales de un proyecto de software es más fácil estimar o medir su tamaño en puntos de función. Las consideraciones anteriores sobre backfiring también son válidas en estos casos.
Con el objetivo de resolver las inconsistencias existentes entre diversos métodos surgidos a partir del modelo de Análisis de Puntos de Función propuesto por Allan Albrecht y establecer un método más rigoroso de medición de tamaño funcional, fue creado un grupo de trabajo denominado WG12 (Working Group 12), subordinado al SC7 (Sub-Committee Seven) del JTC1 ( Joint Technical Committee One) y regulado por la ISO (Internacional Organization for Standarzation) en conjunto con el IEC (INterncional Engineering).
Como el resultado, fue establecida la norma 14.143, que es dividida en cinco partes:
14.143–1: Definición de concepción
14.143–2: Evaluación de la Conformidad de Métodos de Medición de Software con Relación a el patrón ISO/IEC 14143–1
14.143–3: Verificación de un Método de Medición de Tamaño Funcional
14.143–4: Modelo de Referencia para Medición Funcional de Tamaño
14.143–5: Determinación de Dominios Funcionales para uso con Medición de Tamaño Funcional.
La norma ISO/IEC 14143 fue desarrollada para garantizar que todos los métodos de Medición de Tamaño Funcional sean basados en conceptos similares y que puedan ser probados para asegurar un comportamiento similar y de forma esperada por un método de medición, dependiendo de los dominios funcionales a los que se se aplican.
Al final de 2002, la técnica de Análisis de Puntos de Función, en su versión No. 4 del manual del IFPUG, fue aprobada (bajo la norma 20.296) como un método de Medición de Tamaño Funcional conforme la norma ISO/IEC 14.143.
Sí, existen otros tres métodos estándar de medición funcional:
1. NESMA – Asociación de Métricas de Holanda. La NESMA mantiene su proprio manual de cálculo, actualmente en la versión 2.0. Su primera versión fue publicada en 1990. Su filosofía, conceptos, términos y reglas tuvieron como referencia el IFPUG, con algunas variaciones en sus directrices. La medición de un proyecto de desarrollo o de una aplicación produce resultados próximos tanto en el abordaje del IFPUG como en el de NESMA. Sin embargo, estas organizaciones tienen enfoques distintos para la aplicación del Análisis de Puntos de Función en proyectos de mejora de software.
2. Mark II – Fue formulado por Charles Symons a mediados de la década de 1980, pero su diseminación fue difícil inicialmente porque pertenecía a la consultoría KPMG. Actualmente, es un método de dominio público regulado por la asociación de métricas de Inglaterra – UKSMA. Es un método de aplicación restringida al Reino Unido.
3. COSMIC – En 1997, un grupo de investigación de la Universidad de Quebec presentó un método de medición funcional para sistemas en tiempo real, denominado Full Function Points (FFP). En 1998, un grupo de especialistas en medición de software constituyó COSMIC (Common Software Measurement Internacional Consortium) con el objetivo de desarrollar un nuevo método de medición de tamaño funcional basado en las mejores características de los métodos existentes y que incorporara nuevas ideas.
Este método propuesto en 2000, denominado COSMIC-FFP, fue una versión actualizada del método FFP. A pesar de que no es una técnica tan diseminada como la del IFPUG, existen varias investigaciones en torno y el mercado sigue atento a sus novedades.
El primer paso es identificar los objetivos de la organización. El Análisis de Puntos de Función puede ser empleado con varios fines: estimación de proyectos de software, unidad de medición de contratos, apoyo al control de calidad y productividad, benchmarking y programa de métricas.
Cada enfoque específico posee sus particularidades, sin embargo existen aspectos comunes a todos ellos, que destacamos a continuación:
- Apoya la dirección de la organización: Los resultados del empleo del FPA en la organización, no siempre serán inmediatos. Su éxito dependerá de la dedicación y empleo de recursos humanos y financieros, así como cualquier programa cuyo objetivo sea la mejora de procesos.
- Aprovechar oportunidades existentes con objetivos comunes: Ejemplos de estas iniciativas son: ISO, SIX-Sigma, CMM, PMI, Balance Scorecard. Es necesario mostrar el valor de estas iniciativas y saber relacionarlo (mostrar para los patrocinadores) cómo el FPA contribuye con los objetivos de iniciativas alternas.
- Capacitación: Conocer correctamente la técnica es fundamental. Es sorprendente el número de casos en los que el FPA es aplicado incorrectamente. Pocas veces terminan con éxito. La referencia oficial de la técnica es el manual del IFPUG, el CPM (Counting Practices Manual). Las siguientes acciones pueden contribuir:
- Contratar un curso In-Company para todo el equipo involucrado, adecuando la carga horaria o el programa del curso con los objetivos del proceso y realidad de la organización. En este caso, FATTO sugiere una semana de capacitación: Análisis de Puntos de Función: Fundamentos, Beneficios e Implantación (8 Horas), Capacitación en Análisis de Puntos de Función (16 Horas) y Taller de Medición de Puntos de Función: El puente de la teoría a la práctica (16 Horas).
- Inscribir personas claves en el proceso, en cursos abiertos sobre la técnica de Análisis de Puntos de Función. Consulte Nuestros Cursos para más información.
- Establezca objetivos iniciales alcanzables. Comience con un proyecto piloto en un sistema simple. Evalúe los resultados, efectúe las correcciones necesarias, revise los objetivos y continue.
- Sea consciente de las limitaciones de la técnica: Existen domínios de problemas en los que el FPA no es indicado. Por ejemplo, en sistemas de optimización, la técnica no es adecuada para medir las partes con alta complejidad algorítmica.
- En caso de que existan dudas, haga la analogía con el metro cuadrado. En general, esto es suficiente para resolver la pregunta.
- Busque ayuda si es necesario. Una consultoría externa puede agilizar el proceso con más experiencia y ayuda en la corrección de errores.
- No compare proyectos con diversas características. Las comparaciones deben ser hechas sólo entre proyectos que sean similares (procesos de desarrollo, plataforma tecnológica, área de negocio etc.)
Además de las consideraciones generales presentadas en la pregunta No. 21, a continuación son presentadas algunas orientaciones específicas para el uso de puntos de función en estimaciones:
A pesar de que algunos autores citen el uso de puntos de función para derivar directamente estimaciones de plazo, defectos y tamaño del equipo, el uso más común es para estimaciones de esfuerzo (generalmente cantidad de horas). El proceso para estimar esfuerzo es simple: dada una productividad (horas/punto de función) en determinado ambiente de desarrollo, basta multiplicarla por el tamaño funcional del software para obtener la estimación deseada.
Sin embargo, la pregunta clave es: ¿Cuál productividad se debe emplear? Algunos analistas utilizan los indicadores de mercado publicados por diversas organizaciones, pero se sienten inconfirmes con el resultado obtenido, debido a que no hay números mágicos. La productividad a ser empleada debe ser obtenida en cada organización, y no a partir de una medida del mercado, ya que debe reflejar su realidad del proceso de desarrollo en determinado contexto: herramienta de desarrollo, área de negocio o plataforma tecnológica.
Para obtener números más apropiadas, las empresas pueden recurrir a los datos de proyectos anteriores y recuperar su información de esfuerzo y tamaño en puntos de función agrupando los proyectos similares y si es posible, obtener un indicador de productividad confiable.
Además de las consideraciones generales de la pregunta 21, son presentadas a continuación algunas orientaciones específicas para el uso de puntos de función en los tres principales modelos de contratación utilizados:
1. Hora/Hombre
2. Precio Global Fijo
3. Precio Unitario
En caso de que la modalidad de contratación utilizada sea Hora/Hombre, en la que la remuneración del proveedor no se basa en los resultados presentados, pero si en la cantidad de horas de trabajo en un período de tiempo, se puede utilizar FPA para, por ejemplo, monitorear la productividad del equipo. Para ello, basta que los datos de los resultados (puntos de función) sean medidos junto con los datos del esfuerzo (horas) y que sean realizadas evaluaciones que relacionen ambas informaciones.
Cuando la contratación tiene como referencia el precio global fijo, el FPA puede ser utilizado como un factor de normalización de precio, buscando garantizar que el valor cobrado por funcionalidades adicionales no previstas o durante la fase de mantenimiento, sea compatible con el valor cobrado en el momento de la contratación del servicio.
Se mide el tamaño del proyecto en puntos de función y a partir del valor total cobrado por el proveedor, se calcula el valor del punto de función. Las nuevas propuestas son medidas respecto a su tamaño y entonces se aplica el valor del punto de función para obtener el valor de las nuevas funcionalidades. Este valor puede ser comparado entonces con el valor propuesto por el proveedor.
No obstante, el modelo que mejor equilibra las deficiencias de la contratación por Hora/Hombre y precio global fijo, es el del precio unitario (puntos de función). En caso de que el proveedor tenga una productividad baja, no será remunerado por el tiempo extra consumido y podrá obtener una mejor rentabilidad si el alcance del servicio aumenta. No serán necesarias las negociaciones desgastantes para establecer un valor por el servicio adicional. En esta modalidad, un factor importante es la definición correcta del valor del punto de función, conforme la pregunta 14.
En cualquiera de las modalidades de contratación adoptada, se debe tener cuidado con los conflictos de interés: la medición del servicio en puntos de función nunca debe ser realizada solamente por el proveedor pues será remunerado justamente por el resultado de la medición. Esta práctica indeseable es observada en algunas organizaciones (inclusive públicas). Se puede utilizar personal interno para realizar la medición, o en el escenario menos favorable,validar por muestras de las mediciones realizadas. Otra opción es contratar una empresa externa para este servicio.
El proceso de benchmarking de la productividad del desarrollo de software, asi como el de cualquier otro indicador, depende fundamentalmente del siguiente cuestionamiento: ¿Existen datos válidos internos, comparables con aquellos que serán obtenidos en el mercado?
En realidad, la importancia de esa pregunta se percibe cuando se afirma que "No se puede realizar Benchmarking de un dato que no fue calculado". Apesar de parecer obvia, la simplicidad de esa afirmación desaparece al evaluar el esfuerzo necesario para obtener datos internos confiables, que muestren la realidad de la organización.
El proceso comienza con la recolección de los datos. No es suficiente escribir un cuestionario y entregarlo para que las personas respondan. Es necesario tener un plan para garantizar que las definiciones de las variables de interés y las posibles respuestas estén claras antes de iniciar la recolección de los datos. Una mayor inversión en la planeación resulta en la reducción del riesgo de la recolección de datos errados y el esfuerzo en la validación de los mismos.
Por analogía y teniendo como referencia el concepto de productividad, se puede afirmar que no es posible realizar el benchmarking de la productividad del desarrollo de software sin el conocimiento de los datos de tamaño y esfuerzo de los proyectos de la organización. El tamaño generalmente es medido en Puntos de Función (FP) y el esfuerzo en horas (H). Conforme ya mencionado, la recolección de esos datos debe ser realizada de forma que puedan ser comparados con los indicadores obtenidos en el mercado. La clave para el éxito del Benchmarking es la extratificación de los datos. Es fundamental que las recolectas sean realizadas según la similaridad de los proyectos, una vez que la productividad puede ser altamente variable dependiendo del sector de negocios del proyecto, de la plataforma de hardware y software, de la época en que el proyecto fue iniciado, etc.
El benchmarking es realizado, entonces, sobre la misma extratificación adoptada en el momento de las recolectas de los datos internos de la organización. Sin embargo, en ese momento es necesario observar atentamente algunas otras cuestiones, buscando explorar el nivel de adecuación del indicador a un determinado proyecto o ambiente:
a) ¿Los critérios de recolecta de horas utilizados en la elaboración de los indicadores de mercado son compatibles con los utilizados en la organización?
Por ejemplo: ¿Cuántas horas son consideradas en un mes de trabajo (126, 160, 168, etc.)? ¿Cuál es la carga horaria diaria de trabajo (4, 6, 8, etc)?
b) ¿El método de medición del tamaño funcional utilizado en la elaboración del indicador de mercado es compatible con el de la organización?
Por ejemplo: ¿Se utilizó el factor de ajuste definido por le método del IFPUG?
C) ¿Las actividades involucradas, los productos generados y la metodología adoptada envuelven el uso de recursos que el contexto y análisis exigen?
Por ejemplo: ¿Cuáles modelos de proyectos y diagramas son utilizados? ¿Existen papeles definidos para cada actividad realizada, inclusive para implementar el control de calidad de los proyectos?
d) Así sean diferentes, ¿El riesgo de esta variabilidad es aceptable?
Otro factor a ser considerado es la importancia de la actualización de los datos utilizados en benchmarking. Se debe tener en cuentra que entre más proyectos sean utilizados en el proceso de benchmarking, es mejor. Después de que sean tomados todos los cuidados necesarios, si aún hay dudas respecto a los resultados obtenidos para la productividad del desarrollo de software, utilice un intervalo en vez de un valor exacto para el indicador.
¿Qué actividades están incluidas en el punto de función?
La evaluación sobre si se debe tercerizar la medición de puntos de función básicamente involucra los mismos asuntos de tercerizar cualquier otra actividad. A continuación, se destacan las situaciones específicas donde la tercerización puede ser favorable para la organización contratante:
- En el período inicial de la aplicación de la técnica dentro de la organización, la medición de algunos proyectos por un profesional experimentado con el acompañamiento de parte del equipo del cliente puede agilizar el proceso y también ayudar en la absorción del conocimiento práctico por el equipo. En la práctica, esto es un tipo de Mentoring.
- Un profesional con experiencia posee más agilidad en el proceso de medición. En caso de que la organización no posea colaboradores con este perfil, el alcance de la medición sea muy grande y el tiempo para realizarla sea limitado, es más conveniente contratar un profesional externo con experiencia en medición actuando en conjunto con un profesional de la organización que conozca los sistemas a ser medidos.
- Cuando la medición sea una necesidad esporádica, el costo-beneficio para capacitar un profesional interno y mantenerlo actualizado puede ser desventajoso en relación a la contratación puntual de un tercero.
- Cuando la medición de puntos de función sea una necesidad sistemática es importante que existan profesionales internos capacitados. En este caso, la tercerización puede ser conveniente en los picos de la demanda.
- Cuando existe la necesidad de que la medición sea realizada (o auditada) por un profesional certificado (CFPS).
FATTO cuenta con un equipo de especialistas certificados capaces de ayudar su organización no sólo en el proceso de medición de puntos de función, sino también en la correcta aplicación del FPA en estimaciones, programa de métricas y contratación de software. Para más información entre en contacto a través del correo contacto@fattocs.com.
El Análisis de Puntos de Función (APF) es una técnica para medir las funcionalidades ofrecidas por un software a sus usuarios. Y esta medición siempre se realiza desde una perspectiva externa; desde el punto de vista de los usuarios. Sin embargo, cabe destacar que el concepto de usuario para el APF no se limita solo al usuario final del software. Usuario para APF es cualquier persona o cosa que interactúa con el software en cualquier momento. Es decir, usuario para APF puede ser tanto una persona actuando como usuario final del software como también otro software que utiliza los servicios del software en análisis.
Considerando que todo y cualquier software existe para ofrecer uno o más servicios (funciones) a alguien (persona o cosa); entonces se concluye que todo y cualquier software puede ser medido por el APF.
Un error común de algunos principiantes con el APF es usar como punto de vista del análisis solo al usuario final. En este caso, algunos softwares serán parcialmente (o completamente) “invisibles” para este usuario. Y de ahí el principiante concluye erróneamente que el APF no sirve para medir ese software. Lo más común es que el principiante aprenda los principios del APF aplicados a sistemas con pantallas e informes. Sin embargo, cuando se enfrenta a softwares que no tienen pantallas, softwares con procesamiento batch, middlewares, softwares básicos, es natural sentir dificultad para realizar la medición.
Imaginemos que el objetivo fuera medir un controlador de impresora. Pues bien, no hay un usuario final (persona) para este tipo de software. Desde esta perspectiva, el controlador de impresora es “invisible” para el usuario final. Sin embargo, el controlador de impresora existe para ofrecer servicios a alguien; en este caso, el sistema operativo. Analizando, por lo tanto, el controlador de impresora desde la perspectiva del sistema operativo, es posible ver funciones; por ejemplo: funciones para iniciar la impresora, informar sobre el estado general del dispositivo, expulsar una hoja, imprimir, alertar sobre la tinta cercana al final, entre otras.
En la literatura, frecuentemente nos encontramos con muchas afirmaciones y cuestionamientos distorsionados sobre la técnica del análisis de puntos de función, que no demuestran nada más que la falta de conocimiento sobre el tema. ¿Quién no ha escuchado la falsa afirmación “el análisis de puntos de función no sirve para medir sistemas orientados a objetos”?
Más recientemente, con la consolidación de UML como el lenguaje estándar del mercado para el análisis y el diseño orientado a objetos, otra frecuente falsa afirmación es que el análisis de puntos de función no sirve para medir sistemas cuyos requisitos fueron expresados según especificaciones de casos de uso. Una discusión específica sobre este tema fue presentada en el Boletín de Marzo de 2004.
Desde finales de la década de los 90, una técnica de gestión de pruebas surgida en los Países Bajos, llamada “TMap - Test Management Approach” ha ido ganando adeptos, impulsada por la ola de iniciativas de mejora de procesos basadas en estándares de calidad como ISO y CMM. Su implementación está respaldada por una técnica de estimación de pruebas llamada Test Point Analysis (TPA) o Análisis de Puntos de Prueba que, a su vez, se basa en el Análisis de Puntos de Función.
La TPA se utiliza específicamente para estimar el esfuerzo necesario en la ejecución de pruebas de aceptación y de sistema. Para ello, la TPA considera relevantes, además del tamaño funcional determinado por los puntos de función, otros dos elementos: la estrategia de pruebas y la productividad. Incluso cuando trata el elemento “tamaño”, añade factores que tienen más influencia en el esfuerzo que específicamente en el tamaño funcional, como la complejidad algorítmica, el grado de integración con otras funciones y la uniformidad funcional.
Aunque es una técnica consistente y útil para aumentar la calidad del proceso y producto de software, la TPA promueve otro concepto distorsionado sobre el análisis de puntos de función, cuando afirma que esta no puede ser utilizada en la estimación del esfuerzo de las actividades involucradas en las pruebas de aceptación y de sistema. Pues bien, afirmar esto significa decir que la FPA considera las particularidades del proceso de desarrollo durante la aplicación de la técnica de conteo. Lo cual no es cierto.
El resultado de la aplicación de la TPA se mide en unidades de esfuerzo (horas), a diferencia del análisis de puntos de función, que mide el tamaño funcional del proyecto de software. De esta forma, así como realmente no mide directamente el esfuerzo empleado en las pruebas, la FPA tampoco mide el esfuerzo empleado en la fase de análisis, diseño o construcción del software. Su función principal es medir la funcionalidad entregada por el proyecto de software. Sin embargo, los puntos de función pueden, perfectamente, ser utilizados como dato de entrada de un proceso de estimación del esfuerzo de las diferentes fases del desarrollo, como ya se discutió en el Boletín de Enero de 2004.
El mayor beneficio de la TPA está en conseguir reunir, de forma sistemática, los factores que influyen en el esfuerzo específico de una de las etapas del proceso de desarrollo, produciendo resultados más precisos.
¿Qué es el Usuario para el Análisis de Puntos de Función?
En el área de la tecnología de la información, en general, el término “aplicación” se utiliza para designar un programa ejecutable que cumple uno o un conjunto de objetivos específicos de los usuarios. Como ejemplos clásicos podemos citar la Calculadora de Windows, el Word, las Cuentas por Pagar, etc.
Los desarrolladores, a su vez, suelen determinar el alcance de las aplicaciones según la segmentación física del software. De esta manera, un conjunto único de funciones relacionadas se separa según cuestiones tecnológicas:
- Los modos de ejecución física. Por ejemplo, funciones ejecutadas en batch o en línea;
- Las plataformas físicas en las que residen los subconjuntos de funciones. Por ejemplo, mainframe o PC (plataforma baja);
- Las arquitecturas según las cuales se diseñan las aplicaciones. Por ejemplo, escritorio, cliente-servidor, web o 3-tier.
En el análisis de puntos de función, una aplicación se define según la visión del usuario y de acuerdo con consideraciones de negocio y no con cuestiones técnicas. Según el Manual de Prácticas de Conteo (CPM), una aplicación es un conjunto cohesivo de datos y procedimientos automatizados que soportan un objetivo de negocio, y puede consistir en uno o más componentes, módulos o subsistemas. Frecuentemente, el término “aplicación” se utiliza como sinónimo de sistema, sistema aplicativo o sistema de información.
Para el análisis de puntos de función, la correcta comprensión del término y, a su vez, la correcta identificación de una aplicación (delimitada por su frontera) es la base para el uso consistente de la técnica, evitando sobredimensionamientos o subdimensionamientos durante los conteos.
¡Ciertamente que sí! El APF es una técnica independiente de la tecnología utilizada para modelar o implementar un software. Por lo tanto, un software tendrá el mismo tamaño en puntos de función ya sea desarrollado utilizando un enfoque ágil u otro enfoque cualquiera.
Lo que diferenciará la medición de un proyecto “ágil” y otro tradicional serán los artefactos utilizados para realizar el análisis. En un enfoque más convencional, por ejemplo similar al RUP, los artefactos utilizados para la medición serán probablemente especificaciones de casos de uso, que son descripciones detalladas de las funcionalidades desde la óptica de la interacción del usuario con el software.
En el enfoque ágil hay un énfasis mayor en entregar el software funcionando que en producir una documentación detallada de lo que se hará. Por lo tanto, lo más probable es que se utilicen para la medición en un enfoque ágil las historias de usuario, que son descripciones breves de las funcionalidades deseadas por el usuario.
Sin embargo, solo las historias de usuario no son suficientes para proporcionar toda la información necesaria para la medición de los puntos de función (aunque sean suficientes para proporcionar una estimación/aproximación del tamaño en PFs). Entonces, ¿cómo se medirá el proyecto?
Pues bien, el desarrollador tampoco puede construir el software solo con la información de las historias de usuario. Se necesitan requisitos más detallados para poder construir el software deseado. ¿Y dónde obtiene el desarrollador información más detallada, además de las historias de usuario, para construir el software? ¡Muy probablemente con el propio usuario! El enfoque ágil promueve que el usuario participe en el equipo de desarrollo, en una interacción muy cercana con los desarrolladores.
Por lo tanto, considerando que el desarrollador obtiene información detallada de los requisitos para construir el software, esa misma información será útil para el proceso de medición de los PFs.
El Manual de Prácticas de Conteo (o Counting Practices Manual - CPM) del IFPUG tiene los siguientes objetivos:
• Proporcionar una descripción clara y detallada de cómo contar puntos de función.
• Garantizar que los conteos sean consistentes con las prácticas de conteo de los miembros afiliados al IFPUG.
• Proporcionar orientación sobre cómo realizar conteos de puntos de función basados en artefactos de las técnicas y metodologías de desarrollo de software más utilizadas.
• Proveer un entendimiento común para que los desarrolladores de herramientas proporcionen soporte automático al conteo de puntos de función.
• Ser adherente al estándar ISO/IEC 14143-1 de medición funcional de software.
Para el objetivo de aprender a aplicar el Análisis de Puntos de Función, el manual no es tan didáctico. Una alternativa más didáctica es el libro Análisis de Puntos de Función: Medición, Estimaciones y Gestión de Proyectos de Software. Si el objetivo es estudiar para el examen CFPS, entonces el manual es material obligatorio para el estudio.
¿Cómo es el proceso de conteo de Puntos de Función?
¿Cuál es la productividad del punto de función para estimar el esfuerzo?
Descarga del CPM – Manual de la APF – Manual de Prácticas de Conteo
Hay una gran variación en la productividad de la contabilidad de puntos de función por día para un profesional, causada principalmente por:
- Conocimiento del negocio sobre el cual el proyecto/sistema actúa: si el analista de métricas tiene conocimiento del negocio, tendrá facilidad para efectuar la medición, incluso si la documentación del proyecto/sistema no está en buena calidad.
- Calidad de la documentación disponible: la principal fuente de información para la contabilidad es la documentación del proyecto/sistema. Si la documentación está incompleta o ambigua, se consumirá más tiempo para aclarar dudas referentes a los requisitos. La documentación insuficiente para la medición es un problema más común para contabilidades de aplicación y proyectos de mejora.
- Experiencia de los contadores: cuanto más experiencia adquiere el analista en contabilidades, más ágil es en el análisis de los requisitos. Aprende a buscar qué información es relevante para la medición en la documentación y a descartar lo que no interesa (ahorrando tiempo de análisis de algo que no afectará la medición). La experiencia acumulada también evita que se tenga que consumir tiempo en el análisis de situaciones que ya ha manejado anteriormente.
- Disponibilidad de los usuarios: muchas veces, incluso con documentación disponible del sistema, es necesario entrevistar a los usuarios para complementar alguna necesidad de información que no fue documentada o documentada de forma no clara. Para sistemas heredados que no tienen documentación, la única forma de medirlos es con el apoyo de los usuarios. Si no hay un usuario disponible para proporcionar información, el analista de métricas esperará esa disponibilidad para poder continuar con la medición.
- Propósito de la contabilidad: dependiendo de la cuestión que se desea responder con la contabilidad a realizar, la precisión de la contabilidad y su rastreabilidad pueden no ser cuestiones primarias. Así, se puede analizar de forma más superficial la documentación y también evitar un esfuerzo adicional en la documentación de la propia contabilidad. Es decir, se puede optar por una estimación de tamaño en lugar de propiamente la medición. Incluso la medición puede hacerse con diferentes niveles de documentación, lo cual influye en el tiempo gastado en esta actividad.
- Automatización del proceso: los softwares de apoyo pueden agilizar la contabilidad, principalmente las partes del proceso que no involucran análisis.
- Tipo de medición: en general, la productividad para contar proyectos de mejora es mayor que la de proyectos de desarrollo o contabilidad de aplicación; principalmente si la aplicación que está siendo mantenida (objeto del proyecto de mejora) ya ha sido contada. Pero lo inverso también puede ocurrir, si la medición es para un proyecto de mejora de una aplicación que nunca ha sido medida y que tiene poca documentación disponible.
- Guía de Contabilidad: la guía de contabilidad es un documento que simplifica y contextualiza las reglas del IFPUG para las situaciones específicas de una organización. Para analistas con poca experiencia o con poco conocimiento del contexto de la organización, la guía facilitará bastante el trabajo de medición, proporcionando agilidad.
Analizando un escenario de peor caso, donde los factores mencionados anteriormente estarían influyendo de forma negativa en el trabajo de medición, un límite inferior para la productividad sería 100 PF/día. Para un escenario de mejor caso, sería razonable considerar 1.000 PF/día.
Cabe destacar que la productividad media no está en el medio de esta franja, sino más cerca del escenario de peor caso, que corresponde a las situaciones más comunes de encontrar en el día a día.
Dependiendo de las especificidades que una organización posee, puede eventualmente presentar números fuera de la franja mencionada, pero no sería un comportamiento típico esperado.
Una productividad por debajo de 100 PF/día es señal de problema, se debe investigar y atacar sus causas. Muchas veces el analista de métricas ejecuta actividades de análisis de requisitos, debido a la falta de documentación o a la baja calidad de la misma.
Muchas veces el analista de métricas realiza actividades de análisis de requisitos, debido a la falta de documentación o a la baja calidad de la misma. No sería correcto computar este esfuerzo como el de medición, sino como el de análisis de requisitos.
Conviene destacar que la productividad no es constante durante todo el proceso. El tiempo de preparación, análisis de la documentación y aclaración de dudas es más predominante al inicio del conteo que el propio conteo en sí. Después de estas etapas, lo normal es que el conteo fluya más rápidamente.
El primer punto a destacar en esta cuestión es que no existen herramientas capaces de producir de manera automática una contabilidad de puntos de función de forma confiable. Las razones para esto fueron abordadas en la pregunta 17 de nuestro FAQ. Sin embargo, existen herramientas disponibles capaces de apoyar y automatizar parcialmente el proceso de contabilidad de puntos de función y también de almacenar y gestionar los resultados de las contabilidades.
La herramienta de uso más simple para registrar una contabilidad de puntos de función es una hoja de cálculo. En la sección Recursos de nuestro sitio hay disponible gratuitamente una hoja de cálculo formateada para contabilidades de puntos de función. A pesar de ser la herramienta más simple y la primera en ser usada por muchos, su uso comienza a ser poco práctico a medida que se intensifica el número de contabilidades. El control del repositorio de las contabilidades en general es manual, y con la cantidad creciente de datos, la tarea se vuelve costosa.
Cuando la organización comienza a percibir que la hoja de cálculo ya no atiende sus necesidades actuales, una evolución natural es buscar en el mercado herramientas con más recursos. El IFPUG posee un proceso de certificación para las herramientas de apoyo a la contabilidad de puntos de función. La lista de herramientas actualmente certificadas puede ser visualizada en la página de certificación de software del IFPUG. Según este proceso, las herramientas pueden ser clasificadas en tres tipos:
Tipo 1: El usuario hace la contabilidad de puntos de función manualmente y el software proporciona las funcionalidades de recolección de datos y cálculos.
Tipo 2: El software proporciona las funcionalidades de recolección de datos y cálculos y el usuario y el sistema hacen la contabilidad de puntos de función interactivamente, a través de preguntas presentadas por el sistema y acciones tomadas automáticamente en función de las respuestas proporcionadas.
Tipo 3: El software produce automáticamente una contabilidad de puntos de función usando varias fuentes de información, como la base de datos de la aplicación, la propia aplicación y artefactos de las herramientas de desarrollo. El usuario puede ingresar datos interactivamente, pero su participación durante la contabilidad es mínima. Es importante destacar que no existen herramientas certificadas de este tipo.
Aunque existen varias opciones de herramientas en el mercado para apoyar el uso de puntos de función, muchas organizaciones optan por desarrollar una herramienta propia integrada a sus sistemas de control internos. Algunas razones para esto pueden ser:
- El costo para desarrollar una solución interna es menor que el costo de adquisición y mantenimiento de los paquetes disponibles en el mercado.
- La falta de soporte local para la solución, ya que la mayoría de las herramientas disponibles en el mercado son extranjeras.
- Necesidades de integración con sistemas internos.
Cuando se habla de los requisitos de hardware necesarios para el entorno de ejecución de un determinado software, el enfoque de la cuestión está en los requisitos técnicos o de calidad del mismo, como la capacidad de procesamiento, el volumen de transacciones y de datos, el número de usuarios, la seguridad, etc. Los requisitos funcionales no influyen en nada en esta cuestión. Por lo tanto, no hay ninguna relación directa entre el tamaño de un software en puntos de función (ya sea ajustado o no) con el hardware necesario para su ejecución.
Sin embargo, el factor de ajuste, analizado de forma aislada del tamaño funcional, contempla varias características generales del sistema (Procesamiento Distribuido, Rendimiento, Configuración Altamente Utilizada, Volumen de Transacciones) que podrían ayudar en la definición de los requisitos de hardware de un software, pero aun así sería un análisis insuficiente para la definición del hardware.
Sí; sin embargo, no todos los mantenimientos en un software pueden ser medidos con el APF. Solo los mantenimientos que alteran los requisitos funcionales de un software pueden ser medidos por el APF. En este caso, el IFPUG usa el término “mejora” en lugar de “mantenimiento” para destacar que la mejora no es cualquier mantenimiento.
En el concepto del IFPUG, la mejora mide todas las funciones que serán añadidas, alteradas o eliminadas de la aplicación, así como las eventuales funciones de conversión de datos.
Los mantenimientos para la corrección de defectos o para mantener solo requisitos no funcionales no son medidos por el APF.
La única información de un software necesaria para contar puntos de función son sus requisitos funcionales. Por lo tanto, una vez que los requisitos estén elaborados, cualquiera que sea la fase del proyecto es posible realizar la medición de su tamaño. Es importante destacar también que la forma en que sus requisitos están documentados o expresados es irrelevante para la medición, esto solo refuerza que el APF mide el software de manera independiente de cómo está modelado, diseñado o construido.
Sin embargo, es válido plantear la siguiente cuestión: si solo es posible contar puntos de función después de la definición de los requisitos, ¿cómo producir estimaciones para el proyecto antes de ese momento, que es precisamente cuando la necesidad de estimaciones es más demandada? ¿En este caso, los puntos de función aún pueden ser útiles?
Aunque no sea posible hacer el conteo de puntos de función en los momentos iniciales del proyecto (antes del detalle de los requisitos), aún así es posible estimar su tamaño en puntos de función. Existen varias técnicas para estimar el tamaño en puntos de función de un software, entre las más comunes, dos fueron propuestas por la asociación de métricas de software de Holanda - NESMA. Son los enfoques: conteo indicativo y conteo estimativo, detallados en:
Análisis temprana de Puntos de Función (Early FPA Counting) - FATTO (fattocs.com)
Gestión de Proyectos: ¿El APF es una metodología de GP?
La esencia del APF, promovida por el IFPUG, es que el proceso de conteo de puntos de función debe ser consistente (diferentes personas midiendo el mismo proyecto deben obtener resultados similares) y también, pero principalmente, que el conteo sea lo suficientemente simple para minimizar el esfuerzo de medición, reduciendo el impacto sobre el esfuerzo global del proyecto.
Al igual que cualquier otra actividad de un proyecto de desarrollo o mantenimiento de software, realizar un conteo de puntos de función demanda el esfuerzo de un profesional del equipo. Por lo tanto, habrá un esfuerzo adicional en el proyecto para realizar la medición.
Lo que se debe considerar es que los beneficios obtenidos por la realización de la medición compensen el esfuerzo adicional gastado. En teoría, el software puede ser desarrollado solo con las actividades de codificación; sin embargo, se realizan otras actividades (como análisis, planificación, modelado, pruebas, etc.) que “incrementan” el esfuerzo del proyecto pero que proporcionan beneficios que superan ese esfuerzo adicional.
Traducido en números, lo ideal sería que este esfuerzo ocasionado por la medición no superara el 2% del esfuerzo total del proyecto. Es importante destacar que, en muchos casos donde esto no ocurre, la causa está en una deficiencia de la especificación de los requisitos. En estos casos, la mayor parte del esfuerzo del conteo de puntos de función termina siendo consumido en entrevistas, revisión y detalle de requisitos. Actividades que deberían haberse realizado en la fase de especificación propiamente dicha.
Básicamente todas las actividades que tienen relación directa con la construcción y entrega de los requisitos funcionales: levantamiento y especificación de requisitos, análisis, diseño, modelado, gestión del proyecto, codificación, pruebas, apoyo a la homologación del usuario, implementación y transferencia de conocimiento del servicio ejecutado. Se pueden producir varios artefactos en estas actividades, como: código fuente, diagramas, modelos, casos de uso, manuales, planes, actas, etc.
Como complemento al párrafo anterior, cualquier actividad no directamente relacionada con los requisitos funcionales del proyecto de desarrollo/mantenimiento del software no está en el alcance de la estimación por PF. Ejemplos: capacitación de usuarios, seguimiento del sistema en producción, administración de la base de datos, atención de dudas o quejas de usuarios, actividades de soporte a la infraestructura tecnológica, etc.
También es posible realizar la estimación para solo algunas actividades específicas del proyecto. Para esto es necesario conocer la distribución (%) del esfuerzo que cada fase suele consumir del proyecto total. Conociendo esta relación, se estima el esfuerzo total del proyecto y se aplica el porcentaje de cada fase deseada para saber el esfuerzo estimado para esas actividades.
La mayoría de los errores encontrados en un recuento de puntos de función de un sistema son causados por cuatro factores:
- Desconocimiento de la técnica: todavía hay un gran número de profesionales que son designados para contar puntos de función de un sistema sin el conocimiento necesario del proceso de conteo. Tal vez esto ocurra porque hay una idea generalizada de que la APF es muy simple. Y en realidad lo es, pero esto no significa que no sea necesario un entrenamiento profesional o un estudio más dedicado de la técnica. Con solo un conocimiento superficial de la APF es muy probable que el analista cometa errores básicos. Sobre este aspecto, el IFPUG estableció su programa de certificación profesional CFPS, que busca garantizar que el profesional certificado conoce todas las definiciones y reglas de su Manual de Prácticas de Conteo en su versión más reciente.
- Dejar que el conteo sea “contaminado” por la implementación: la APF es una técnica para medir requisitos funcionales de un software. Es decir, mide lo que el usuario solicita y recibe del software independientemente de cómo se haya implementado. Por lo tanto, el resultado de un recuento de puntos de función debe ser el mismo, sea cual sea la solución de implementación (proceso, arquitectura, herramientas, entorno computacional, etc.) adoptada por el desarrollador. Contar puntos de función de un sistema es un ejercicio de abstracción del problema de negocio del usuario que el software debe atender. Sin embargo, no siempre es una tarea fácil y, incluso, analistas de puntos de función experimentados pueden desviar el enfoque del conteo hacia la solución de implementación del desarrollador. Muchas veces el analista es inducido en este camino por falta de documentación adecuada.
- Falta de conocimiento del negocio: no sirve de nada ser especialista en la APF y no conocer el negocio del usuario. Para que el recuento de puntos de función se realice correctamente, es decir, desde el punto de vista del usuario, es necesario que el analista de puntos de función busque primero el entendimiento del negocio y solo después realice el recuento de puntos de función. Muchas veces no hay tiempo disponible para que el analista de puntos de función busque este conocimiento. En este caso, trabajará en colaboración con un analista de negocio o con un usuario para poder realizar el recuento de puntos de función.
- Calidad de los requisitos disponibles: se habla mucho en la ingeniería de software sobre la importancia del levantamiento de requisitos y del impacto que esto tiene en todo el proyecto cuando esta tarea no se ejecuta bien. Para el recuento de puntos de función no es diferente. Si los documentos de donde el analista de puntos de función extrae los requisitos del usuario para realizar el recuento están ambiguos, incompletos o mal escritos, ciertamente el resultado del recuento se verá afectado.
Esta relación de factores no está presentada en ningún orden específico, pero es bastante representativa de los principales factores que causan recuentos de puntos de función incorrectos.
No hay un documento específico de uso obligatorio para medir un software (o contar puntos de función). Cualquier documento en el que sea posible extraer información de los requisitos del usuario puede ser utilizado en una medición de puntos de función. Ya sean casos de uso, manuales, prototipos, documentos de visión, modelo de datos, modelo de clases, etc. Esto es coherente con el propio objetivo de la APF, que es ser una técnica independiente de la implementación del software. Se puede implementar un software a través de diferentes métodos y herramientas para análisis, modelado y construcción, para diversas plataformas computacionales; pero nada de esto afecta la medición del mismo en puntos de función.
Es claro que ciertos tipos de documentos pueden proporcionar la información necesaria para una medición de puntos de función de manera más fácil. Otros documentos pueden contener solo parte de la información necesaria para la medición de PFs, siendo necesario el análisis conjunto de más documentos para efectuar la medición. Así como también otros documentos, por tener un carácter más técnico para el proceso de desarrollo de software, pueden requerir más trabajo para extraer los requisitos del usuario. El mejor documento para utilizar en una medición de PFs es aquel que contiene los requisitos del usuario explicitados en el lenguaje de su negocio, y no en un lenguaje de TI.
Cada organización tiene su propio proceso de desarrollo particular, produciendo una cantidad de documentos (o artefactos) distintos en determinadas fases del proceso. Por lo tanto, el momento en el que se realiza la medición también determina qué documentos estarán disponibles para efectuar el trabajo de medición (o estimación) del tamaño funcional del proyecto.
Los requisitos del software son fundamentales para el APF, ya que el proceso de medición se basa exclusivamente en ellos. El insumo básico de la medición son los requisitos del sistema. Cabe destacar que el APF mide solo una parte de los requisitos del usuario para el sistema: los requisitos funcionales. Los requisitos no funcionales no son medidos por el APF. Sin embargo, en un modelo de estimación de costos basado en PF (costo = tamaño (PF) x IP ($/PF)), ambos tipos de requisitos (funcionales y no funcionales) son considerados: el primero afectara el tamaño funcional y el segundo afectar a el costo unitario ($/PF).
Debido a esta importancia de los requisitos para el APF, cuanto mejor sea la calidad de los requisitos, más fácil y ágil se vuelve el proceso de medición, y más preciso es el resultado. Requisitos de mala calidad afectan negativamente todo el proyecto de software, incluida la actividad de medición. Sin embargo, un efecto colateral beneficioso del proceso de medición es precisamente evidenciar fallas en los requisitos. Cuanto antes se identifiquen estas fallas en el proyecto, menor será el costo de corregirlas y mayor la probabilidad de éxito del proyecto
COSMIC es un acrónimo para Common Software Measurement International Consortium. Es la organización responsable de la definición y mantenimiento del método de medición del tamaño funcional que lleva el mismo nombre. Su método de medición:
- Es el primero diseñado para conformidad con los estándares del consorcio entre la ISO y el IEC (ISO/IEC 14143).
- Define una medida estándar del tamaño funcional del software. Aunque diseñado para dominios de software como: sistemas de información gerencial, tiempo real e infraestructura, tiene una aplicabilidad bastante amplia.
- Posee una flexibilidad que permite el desarrollo de extensiones locales del método para tratar problemas específicos, por ejemplo: software con procesamiento matemático intensivo, algoritmos complejos y procesamiento de variables continuas como audio y video.
La aplicación del método produce una medición (o una aproximación del tamaño según el interés y el momento en el ciclo de vida en que se encuentre) expresada en la unidad denominada Puntos de Función COSMIC (PFC).
Ofrece un nivel de confiabilidad compatible para todos los tipos de software, es de dominio público y sin costos, tiene reconocimiento total por la ISO/IEC y su base conceptual es compatible con la moderna ingeniería de software. Estimaciones y medición de desempeño (como la proyección o la evaluación de metas de productividad y calidad) pueden realizarse con mayor precisión si la unidad de producto utilizada es el Punto de Función COSMIC. El método considera que la medición de un pedazo de software depende esencialmente de su uso y permite la medición del mismo software en múltiples perspectivas.
Para entender un poco más la diferencia del método COSMIC del método IFPUG, vea ¿Cuál es la diferencia entre los métodos COSMIC e IFPUG?
El método COSMIC es tema de nuestro curso “Medición y Estimación de Software con el Método COSMIC”.
El método COSMIC está para el método IFPUG en la medición del tamaño funcional como C# está para COBOL en los lenguajes de programación.
¿Por qué una funcionalidad de transacción puede llegar como máximo a 07 PF cuando usamos el método IFPUG? Porque el estudio para crear el método se realizó con una muestra de 22 proyectos entre 1974 y 1979 y los números utilizados en las tablas de complejidad se basaban en:
"Estas cuentas están ponderadas por los números proyectados para reflejar el valor de la función para el cliente. Las ponderaciones utilizadas fueron determinadas por debates y juicios. Estos pesos nos han dado buenos resultados:
Número de Entradas x 4; Número de Salidas x 5; Número de Consultas x 4; Número de Archivos Maestros x 10."
- Allan Albrecht en Medición de la Productividad del Desarrollo de Aplicaciones (1979).
Tener previamente definidos estos pesos entre 3 y 15 PF por funcionalidad provoca una serie de problemas. Fenómenos como el aumento de la variabilidad en estimaciones y la mayor dificultad en la planificación y en la evaluación del desempeño en el contexto en que la métrica está insertada (proyecto, empresa, equipo, etc.).
Por ejemplo:
¿Cómo tratar la cuenta de los datos de código en un escenario en el que los mismos necesitan una apropiación directa de costos? Una transacción de mantenimiento en datos de código, como mínimo, contribuiría (si fuera medida) con 03 PF; estaría muy cerca de un mantenimiento de registro aunque la diferencia en el esfuerzo sea brutal. ¿Cómo lidiar con las varias funcionalidades con diversas pequeñas variaciones y, aun así, como máximo puede contribuir con 07 PF? Aunque requieran un esfuerzo mucho mayor que otras, todas chocan con el mismo techo.
La respuesta para todas estas cuestiones es considerar que hay momentos en que se obtiene una productividad mayor que la productividad media y hay momentos en que se obtiene una productividad menor que la productividad media… ¿Pero es necesaria una dispersión tan grande? Usando el método COSMIC, no.
En el método COSMIC, no hay ningún criterio empírico de complejidad. ¡No hay un entendimiento común en la comunidad de ingeniería de software de lo que sea complejidad! El método simplemente cuenta cada movimiento de un grupo de datos entre el software y el usuario, o entre el software y algún mecanismo de almacenamiento, como una unidad, un punto de función COSMIC.
Otra diferencia entre los dos métodos es el tratamiento del mantenimiento. Mientras que el método IFPUG considera solo funcionalidades incluidas, alteradas y excluidas, el método COSMIC considera los movimientos de datos incluidos, alterados o excluidos. Con esto, se da una solución mucho más eficaz que la solución dada por IFPUG y mucho más elegante que la adopción de factores de impacto entre 0,25 y 1,50 por NESMA en su punto de función de mejora. Con el enfoque COSMIC, los resultados de la medición pueden ser utilizados en diversos casos que, cuando se miden usando el método IFPUG, se clasifican como requisitos no funcionales y que no pueden ser medidos por un método de medición del tamaño funcional.
El método IFPUG trabaja esencialmente con la medición en una capa de aplicación. Esto dificulta la medición del software en escenarios que involucran, por ejemplo, el cambio de una infraestructura de soporte como una base de datos, sistema operativo o servidor de aplicaciones. Ya el método COSMIC tiene intrínseco en su modelo el concepto de capa y el papel de usuario que un software en una capa superior tiene en relación con el software en una capa inferior.
Además del concepto de capa, COSMIC trae el concepto de componentes pares, que permite que una misma aplicación sea medida considerando, por ejemplo, su capa de presentación, su capa de reglas de negocio y su capa de persistencia. Obviamente, la suma de las partes será mayor que el todo porque la medición de las partes considera movimientos internos; sin embargo, el método orienta en cómo trabajar en estos escenarios.
Mientras que en el método IFPUG hay una página que describe lo que es propósito, alcance y frontera de la aplicación, en el método COSMIC hay toda una fase denominada Estrategia de Medición para colocar el software en análisis en el modelo de contexto de software con las diferentes capas y componentes pares según los objetivos de la medición y los requisitos del usuario.
El proceso de medición COSMIC tiene tres fases:
Fase de Definición de la Estrategia de Medición:
Consiste en evaluar los objetivos de la medición para definir el propósito de la medición de cada parte del software a ser medida, incluyendo sus fronteras.
Fase de Mapeo:
Evalúa los requisitos funcionales del usuario de los artefactos del software a ser medido en términos del modelo general de software. Este modelo define que una función del software (o proceso funcional) está compuesta por dos tipos de subprocesos: movimientos y manipulación de datos. Para simplificar, solo se miden los movimientos de datos de un proceso funcional, y hay cuatro tipos de movimientos: entrada, salida, lectura y escritura.
Fase de Medición:
Asocia a cada movimiento de datos entre las fronteras definidas en las fases anteriores el valor de un punto de función COSMIC, suma los movimientos de datos de cada proceso funcional y luego el tamaño de todos los procesos funcionales considerados en el alcance del análisis para obtener el resultado final de la medición.
Para más detalles, consulte el Manual de Medición COSMIC en http://www.cosmic-sizing.org/ o nuestra tarjeta de referencia rápida: COSMIC Quick Reference Card.
Medición y Estimación de Software con Puntos COSMIC (youtube.com)
El costo para la inscripción en el examen es de US$175,00 por persona y puede hacerse directamente en https://isqi-shop.org/index.php?id_product=42&controller=product&search_query=snap&results=1.
Solo las personas afiliadas al IFPUG pueden inscribirse para el examen de certificación CSP - SNAP Practitioner. De esta manera, los costos para la certificación deben ser analizados conjuntamente con los costos de la afiliación al IFPUG.
Importante: los profesionales certificados deben mantener su afiliación regular durante todo el período de validez de la certificación, bajo pena de que la misma sea cancelada. Por lo tanto, existen varias modalidades de afiliación, las más comunes son:
- Individual - US$185,00
- Corporativa (una única región geográfica) - US$625,00
- Corporativa Nacional - US$1.200,00
- Corporativa Mundial - US$1.850,00
Fuente: http://www.ifpug.org/membership/membership-duesfees/
Consejo 1: Para la empresa que desea certificar a partir de 3 profesionales, la afiliación corporativa se vuelve más económica.
Consejo 2: Capacítese en el método de Medición No Funcional - SNAP en nuestro curso en línea.
Consejo 3: En lugar de formar personas y asumir los costos de certificación y mantenimiento de la certificación, contrate nuestra Oficina de Métricas, con varios profesionales certificados en SNAP.
El Programa de Extensión de Certificación (CEP) del IFPUG fue creado para aquellas personas que poseen una designación CFPS en la versión Major del Manual de Prácticas de Conteo (CPM) del IFPUG y que cumplan con los criterios de crédito de actividades previstos en el programa. Esta extensión puede ser solicitada por un período de 1 a 3 años, debiendo la persona enviar la información y comprobaciones solicitadas por el programa, dentro del plazo previsto.
Nota: no hay limitación en la solicitud de extensión, siendo la única restricción que la persona solicitante de extensión la pida en la versión Major compatible con la versión de su certificación.
Más información en http://www.ifpug.org/certification/cfps-certification-extension-program/
