Preguntas y respuestas sobre Análisis de Puntos Función

 

 

Esta lista de preguntas y respuestas sobre Análisis de Puntos de Función (FPA,por sus siglas en inglés) fue elaborada a partir de las inquietudes que surgieron dentro de los entrenamientos y servicios de consultoría prestados, además de las listas de discusión en las que participan sus profesionales.

 

Entendemos que esta lista resulta muy útil para nuestros clientes y profesionales interesados en FPA. Con el fin de de revisar y actualizar esta lista con nuevas preguntas periódicamente, esperamos contar con sus contribuciones. Puede también enviarnos sus preguntas a a través de nuestra página de contacto.

 

En algunas preguntas serán citados términos técnicos del FPA. En caso de que tenga alguna duda, sugerimos que consulte en nuestro glosario.

1 ¿Qué es Análisis de Puntos de Función? ¿Qué es Punto de Función?

 

El Análisis de Puntos de Función (FPA, por sus siglas en inglés) es una técnica de medición de las funcionalidades ofrecidas por un software desde el punto de vista de sus usuarios. Punto de función (FP, pos sus siglas en inglés) , que es su unidad de medida, tiene por objetivo tornar la medición independiente de la tecnología utilizada para su construcción. Es decir, el FPA busca medir lo que el software hace y no como es construido.

 

Por tanto, el proceso de medición (también llamado conteo de puntos de función) se bada en una evaluación estandarizada de los requerimientos funcionales del usuario. Este procedimiento de medición está descrito por el IFPUG en su Manual de Prácticas de Medición.

 

Las principales técnicas de estimación de proyectos de desarrollo de software asumen que el tamaño de software es un vector importante para la determinación del esfuerzo para su construcción. Por lo anterior, saber su tamaño es uno de los primeros pasos del proceso de estimación de esfuerzo, plazo y costo.

 

Es importante destacar que los puntos de función no miden directamente el esfuerzo, la productividad y el costo. Es exclusivamente una medida de tamaño funcional del software. Los puntos de función en conjunto con otras variables, son usados para derivar la productividad, estimar el esfuerzo y el costo del proyecto de software.

 

Para saber un poco más, vea nuestros videos sobre:

  • ¿Qué es el análisis de Puntos de Función? – Presenta la definición del Análisis de Puntos de Función, los responsables por su mantenimiento y evolución, el objetivo de la medición (lo que se mide y es considerado por el análisis).

 

*FPA: Function Point Analisys, también llamado Análisis por Puntos de Función o Análisis de Puntos Función.

 

2 ¿Quién inventó el FPA? ¿Cómo surgió?

 

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.

 

3 ¿La técnica FPA es propiedad de alguna empresa?

 

No. A pesar de haber surgido en IBM, el resultado de ese proyecto fue abierto a toda la comunidad de software en 1984.

 

 

4 ¿Cuáles son los beneficios del Análisis de Punto de Función?

 

Se pueden destacar varios beneficios de la aplicación del Análisis de Puntos de Función en las organizaciones:

 

  • Es una herramienta que permite determinar el tamaño de un paquete de software, a través de mediciones de las funciones que corresponden a los requerimientos. Al evaluar el costo del paquete, el tamaño de las funciones que serán efectivamente utilizadas, la productividad y el costo del equipo es posible realizar un análisis de tipo “make or buy”. 

 

  • Apoya a los usuarios en la determinación de los beneficios de un paquete a través de la medición de las funciones que específicamente corresponden a sus requerimiento, haciendo posible realizar un análisis de tipo “make or buy”. 

 

  • Soporta el análisis de productividad y calidad, ya sea directamente o en conjunto con otras métricas como esfuerzo, defectos y costo. Por ello, si el proceso de desarrollo es caótico (cada proyecto es desarrollado de forma diferente) al igual que la medición de los puntos de función de los proyectosy el registro del esfuerzo, el análisis de productividad será perjudicado. 

 

  • Apoya la gerencia del alcance de proyectos. El desafío de todo gerente de proyectos es controlar el “Scope Creep” o aumento de su alcance. Al realizar estimaciones de proyectos con puntos de función en cada fase de su ciclo de vida es posible determinar si los requerimientos funcionales aumentarán o disminuirán, y si esta variación corresponde a nuevos requerimientos o a los ya existentes (que fueron más detallados). 

 

  • Complementa la gerencia de los requerimientos al apoyar su verificación y solidez. El proceso de medición de puntos de función favorece un análisis sistemático y estructurado de la especificación de requerimientos y trae beneficios semejantes en su revisión. 

 

  • Un medio para estimar el costo y los recursos para el desarrollo y mantenimiento de software. A través de la estimación de puntos de función en el inicio del ciclo de vida de un proyecto de software, es posible determinar su tamaño funcional. Esta medida puede ser utilizada como entrada para diversos modelos de estimaciones de esfuerzo, plazo y costo. 

 

  • Una herramienta que fundamenta la negociación de contratos. Los puntos de función permiten generar diversos indicadores de niveles de servicio (SLA – “Service Level Agreement”) en contratos de desarrollo y mantenimiento de proyectos. Además de esto, permite el establecimiento de contratos a precio unitario – puntos de función – en los que la unidad representa un bien tangible para el cliente. Esta modalidad posibilita una mejor distribución de riesgo entre el cliente y el proveedor. 

 

  • Un factor de normalización para comparar la productividad de desarrollo de software en la utilización de diferentes técnicas. Diversas organizaciones, como el ISBSG, disponibilizan una base de datos de proyectos de software que permiten la realización de benchmarking con proyectos similares del mercado.

 

 

El siguiente video Beneficios del Análisis de Puntos de Función presenta los beneficios de la aplicación del Análisis de Puntos de Función.

 

  

5 ¿Es necesario ser desarrollador de software (Analista de sistemas, programador, etc) para usar FPA?

 

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.

 

 

6 ¿Existe alguna entidad u organización responsable por la estandarización del FPA?

 

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.

 

 


7 ¿Hay alguna evolución en el FPA después de su creación?

 

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.

 

 

8 ¿Qué es la certificación CFPS del IFPUG?

 

El programa de certificación CFPS (Certified Function Point Specialist) reconoce formalmente los profesionales capaces de realizar mediciones de puntos de función precisas y consistentes y que también conocen las prácticas de medición más recientes del IFPUG.

 

Para ser certificado, el profesional debe ser aprobado en un examen elaborado por el IFPUG cuya tasa de acierto mínima debe ser de 90%. Este examen consiste en aproximadamente 150 preguntas de selección múltiple basadas en el Manual de Prácticas de Medición. La duración de la prueba es de 3 horas. Es un examen de difícil aprobación en función del tiempo disponible y la exigencia de su tasa de acierto. Desafortunadamente, el IFPUG no divulga ninguna información relativa a la tasa de aprobación en el examen.

 

La validez de la certificación es de tres años. Después de esto, el profesional debe presentarse nuevamente al examen para la renovación de la certificación o participar del programa de extensión de certificación (es independiente de la versión del manual). Este programa (válido apenas para CFPS), permite que se prorrogue en dos años más la validez de la certificación a través de la acumulación de créditos en diversas actividades como: realizar mediciones de puntos de función, ministrar cursos, escribir artículos o libros, participar como voluntario de alguno de los comités del IFPUG, entre otras. Esta renovación puede ser realizada dos veces consecutivas, después de las cuales el profesional deberá obligatoriamente realizar al examen para renovar su certificación.

 

En sus inicios, el examen era realizado en papel con corrección manual. A partir de Julio de 2008, el examen fue automatizado para ser aplicado por cualquier centro acreditado por Prometric en el mundo. A partir de Noviembre de 2016 el examen pasó a ser aplicado por iSQI, en la modalidad Flex, que significa que el candidato puede hacer el examen de manera remota. Se puede presentar en inglés, portugués y italiano.

 

No se exige ningún tipo de formación especial, experiencia con FPA o realizar un curso de preparación de la certificación. El único prerrequisito para presentar el examen es ser afiliado al FPUG. Por ello, sin una preparación adecuada la probabilidad de aprobación es menor. Para la renovación de la certificación, es necesaria una preparación con casos de estudios y ejercicios. Nuestro curso de Preparación para el examen CFPS fue elaborado específicamente para apoyar a profesional en su proceso de preparación para la certificación CFPS.

 

 

9 Tips para el exámen CFPS del IFPUG

 

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.

 

 

 


10. ¿Cuál es el costo para obtener la certificación CFPS del IFPUG?

 

A partir de 2004, el IFPUG definió que sólo personas afiliadas al IFPUG pueden inscribirse para el examen CFPS. Además, aquellos que aprueben el examen deben mantener su afiliación regular por todo el período de validez de la certificación. Por tanto, los costos para la certificación deben ser analizados conjuntamente con los costos de la afiliación al IFPUG. Para más información, por favor visite http://www.ifpug.org/?page_id=26

 

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 mundial -  US$ 1.850,00

Para la empresa que desea certificar 3 o más profesionales, la afiliación corporativa es la mas económica. El Manual de Prácticas de Medición, que es la referencia para el examen de certificación, está disponible para descarga gratuita solamente para afiliados.

 

El costo para la inscripción es de US$ 250,00 por persona. 

 

Consciente de todos estos costos, ofrecemos el curso de Preparación para el Examen de Certificación del IFPUG con los siguientes beneficios:

  • Garantía exclusiva para participar gratuitamente en otra edición del curso, en caso de no aprobar. 
  • Descuento del 80% para el ex-alumno que necesita renovar su certificación o no presentó el xamen.
  • Único curso en el mercado en la modalidad de enseñanza a distancia con total flexibilidad de horarios. ¡Inscríbase aquí!
  • Instructores certificados CFPS por el IFPUG y con de experiencia en el uso del FPA.
  • Posibilidad de realizar cursos in-company con el número de participantes, fechas y horarios  más convenientes.

11.¿Quién usa Análisis de Puntos de Función en el Mundo?

 

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. 

 

12. ¿Es posible utilizar el FPA en un proyecto orientado a objetos?

 

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. 

 

 

13. ¿Cuál es el tamaño para considerar un proyecto de software pequeño, medio o grande?

 

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.

 

 

14. ¿Cuál es el precio de un Punto de Función?

 

El valor cambia de acuerdo al trabajo exigido para la entrega de las funcionalidades del software según el estándar técnico, calidad solicitada  y cantidad de entregables (artefactos del proyecto, documentos, modelos, etc.) exigidos por el cliente. Todo aquello que afecta el costo de forma significativa, pero que no tiene relación directa con el tamaño medido por el FPA, termina siendo incluido en el precio del punto de función:

 

  • Ejemplo 1: Se espera que el precio del punto de función sea menor en una empresa que trabaja con codificación y pruebas de sistemas al de aquella que realiza todo el ciclo de desarrollo del sistema, desde el levantamiento de requerimientos hasta la implantación.

 

  • Ejemplo 2: Se espera que el precio del punto de función sea menor cuando sólo se debe entregar el software y mayor cuando deben ser entregados varios documentos (subproductos) como: modelos de UML, manual de usuario, soporte online, prototipos, casos de uso planos y pruebas, etc.

 

  • Ejemplo 3: Actualmente, la variedad de tecnología disponible para desarrollo de sistemas es enorme. Cada una de éstas puede influenciar directamente en la productividad (tanto positiva como negativamente) del trabajo a ser realizado. Es bastante común en el mercado la diferenciación del $/FP de acuerdo con la plataforma tecnológica (mainframe, web, cliente-servidor, etc.) y/o el lenguaje de programación (Cobol, C++; Java, .Net, etc.)

 

  • Ejemplo 4: El FPA según el estándar IFPUG, mide mantenimientos desconsiderando el tamaño que la función. Generalmente, el esfuerzo para mantener una función suele ser inferior al de su desarrollo. Por tanto, hay diferenciación del precio de punto de función en proyectos de mejora para nuevas, modificadas y eliminadas funcionalidades.

 

En resu­men, no existe un pre­cio único para el punto de fun­ción. Debe eva­luar el con­junto de acti­vi­da­des rela­ti­vas a la dis­po­ni­bi­li­dad de las fun­ci­o­na­li­da­des medi­das en pun­tos de fun­ción, el modelo de con­trato que dic­tará la remu­ne­ra­ción de un punto de fun­ción y tam­bién los aspec­tos no fun­ci­o­na­les que son des­con­si­de­ra­dos en la medi­ción de los pun­tos de fun­ción para obte­ner una refe­ren­cia con­fi­a­ble. La mejor alter­na­tiva para obte­ner esta refe­ren­cia es ana­li­zar los proyec­tos rea­li­za­dos.

 

Para los proyec­tos con­clui­dos, una infor­ma­ción dis­po­ni­ble es lo que se pagó por cada proyecto y las acti­vi­da­des que esta­ban incluidas. En caso de que el tamaño fun­ci­o­nal (PF) de los proyec­tos no esté dis­po­ni­ble, se puede obte­ne a tra­vés de una medi­ción o estimación. Teniendo el pre­cio del proyecto y su tamaño en pun­tos de fun­ción, se puede obtener el precio por punto de fun­ción ($/PF).

 

Sin embargo, cuando una empresa posee diferentes tipos de proyec­tos, se recomienda realizar un aná­li­sis del $/PF para cada cate­go­ría ya que un único pre­cio no será repre­sen­ta­tivo. 

 

15. ¿Es posible aplicar el FPA en tareas que no son organizadas en proyectos?

 

Nor­mal­mente, este tipo de tra­bajo tiene un alcance muy limi­tado. Como con­se­cu­en­cia es difí­cil esta­blecer una rela­ción entre el tamaño fun­ci­o­nal y otras métri­cas fun­da­men­ta­les como esfu­erzo, plazo y costo. Sin embargo, se debe recor­dar que el FPA no es sim­ple­mente una her­ra­mi­enta para gene­ra­ción de estimaciones uti­li­zada en la pla­ne­ación de proyec­tos. La natu­ra­leza de ese tra­bajo se carac­te­ri­za no como un proyecto, sino como una ope­ra­ción continua.

 

El dimen­si­o­na­mi­ento de las órde­nes de ser­vi­cio que repre­sen­tan los requerimientos (no siem­pre fun­ci­o­na­les), que son objeto de man­te­ni­mi­ento, puede no pre­sentar una rela­ción linear con el esfu­erzo de su rea­li­za­ción. Sin embargo, teniendo en cuenta el uni­verso com­pren­dido por el con­junto de estas solicitudes en períodos mayores, se puede lle­gar a con­clu­si­o­nes distintas.

 

Por ejem­plo, una deter­mi­nada soli­ci­tud de man­te­ni­mi­ento que no tenga el aumento, modi­fi­ca­ción o eliminación de fun­ci­o­na­li­dad de deter­mi­nado sis­tema. En este caso, es inú­til saber que el tamaño fun­ci­o­nal del man­te­ni­mi­ento es de cero pun­tos de fun­ción. Sin embargo, el sistema donde se hace el man­te­ni­mi­ento tiene un tamaño fun­ci­o­nal y permite acom­pañar la evo­lu­ción de la can­ti­dad de horas de man­te­ni­mi­ento por punto de fun­ción de este sis­tema. Tal ten­den­cia ayuda a eva­luar si es necesario sus­ti­tuirlo por un nuevo.

 

Suponga que en una orga­ni­za­ción hay un pro­ceso donde, des­pués de que la orden de ser­vi­cio es aten­dida por el equipo de man­te­ni­mi­ento, el pro­ducto pasa por un pro­ceso de homo­lo­ga­ción. El con­junto de fun­ci­o­na­li­da­des en homo­lo­ga­ción puede ser dimen­si­o­nado en tér­mi­nos de pun­tos de fun­ción. De la misma forma, puede ser docu­men­tada la can­ti­dad de defec­tos iden­ti­fi­ca­dos. El acom­paña­mi­ento del inter-relacionamiento de estas dos métri­ca, Pun­tos de Fun­ción y Defec­tos, durante un peri­odo de tiempo permite identificar los pro­ble­mas en el pro­ceso de man­te­ni­mi­ento. Con base en esa ten­den­cia, es posi­ble empren­der acci­o­nes para dis­mi­nuir esta relación.

 

 

16. ¿Dos funciones, significativamente distintas en el esfuerzo de su implementación, tienen el mismo número de puntos de función?

 

Los Puntos de Fun­ción miden el tamaño fun­ci­o­nal del soft­ware y no el esfu­erzo invo­lu­crado en su implementación. Cuanta más linealidad exista entre el tamaño fun­ci­o­nal y el esfu­erzo, es decir, la pro­duc­ti­vi­dad, mayor será el valor prác­tico de la medida obte­nida. Cuanto más lineal sea esta rela­ción, más fácil­mente pue­den ser extra­po­la­das otras medi­das a par­tir del tamaño fun­ci­o­nal, como el costo y el esfu­erzo. 

 

En un nivel micro, en la eva­lu­a­ción de dimen­si­o­na­mi­ento de dos tran­sac­ci­o­nes, el poten­cial de des­vi­a­ción en la pro­duc­ti­vi­dad deri­vada es alto. En la medida en que se expande esta mu­es­tra per­ci­bi­mos que las situ­a­ci­o­nes extre­mas se com­pen­san y, en media, hay una line­a­li­dad mayor entre el esfu­erzo y el tamaño funcional.

 

En un proyecto espe­ci­fico, tam­bién exis­ten situ­a­ci­o­nes en las que el cál­culo de líneas de código, que es una medida alternativa a puntos de función, no está direc­ta­mente rela­ci­o­nada con el esfu­erzo invo­lu­crado en la espe­ci­fi­ca­ción, docu­men­ta­ción y pruebas. Por ejemplo, en dos proyectos con dife­ren­tes requerimientos de calidad o demanda en la espe­ci­fi­ca­ción, uno será más “com­plejo” y tendrá más nece­si­dad de esfu­erzo de desar­rollo,dando como resultado un número diferente de líneas de código. Esto, sin mencionar, otras limi­ta­ci­o­nes inhe­ren­tes a la métrica de LOC.

 

 

17. ¿Por qué no existen herramientas para el cálculo automático de los puntos de función de un sistema?

 

Exis­ten diver­sos soft­ware que, a par­tir de su modelo o código fuente, cal­cu­lan su tamaño en pun­tos de fun­ción. Sin embargo, el resultado pre­sen­ta­do por dis­tin­tas her­ra­mi­en­tas y el cálculo manual cambia. La variación radica en los archi­vos, telas, repor­tes y otros ele­men­tos que utiliza cada una. Sin embargo, muchas veces hay una rela­ción directa entre estos obje­tos, las fun­ci­o­nes de dados y las tran­sac­ci­o­nes de Análisis de Puntos de Función. Se debe tener en cuentra que la téc­nica mide sola­mente fun­ci­o­nes lógi­cas del sis­tema. Y estas her­ra­mi­en­tas tie­nen difi­cul­tad en dife­ren­ciar fun­ci­o­nes lógi­cas de fun­ci­o­nes físi­cas.

 

Por ejem­plo, no todos los archivo o tablas de un pro­grama cor­res­ponden a un archivo lógico interno o un archivo de inter­face externa, a pesar de que un pro­ceso sea implan­tado a tra­vés de diver­sas telas. Para que la medi­ción sea hecha cor­rec­ta­mente, el soft­ware debería tener la habilidad para hacer este dis­cer­ni­mi­ento, es decir, leer el pro­grama e inter­pre­tar los requerimientos de usu­a­rio. Por el momento, no existe un soft­ware con esta inte­li­gen­cia artificial. 

 

Otras her­ra­mi­en­tas utilizan la téc­nica de back­fi­ring, que con­siste en deri­var el número de pun­tos de fun­ción a par­tir de la can­ti­dad de líneas de código del pro­grama. Se basa en una rela­ción preestablecida entre LOC y PF. Sin embargo, esta téc­nica tiene muchas crí­ti­cas y su apli­ca­ción es restringida. Exis­ten softwa­res de apoyo al pro­ceso de cál­culo de pun­tos de fun­ción que auto­ma­ti­zan parte del pro­ceso. La deci­sión y aná­li­sis de lo que debe ser con­si­de­rado, con­ti­nua siendo res­pon­sa­bi­li­dad de un usu­a­rio humano. 

 

 

18. ¿Qué es backfiring?

 

Este método con­siste en deri­var el número de pun­tos de fun­ción de la apli­ca­ción a par­tir de su tamaño físico. Se miden las líneas de código (LOC), uti­li­zando un fac­tor de con­ver­sión cons­tante depen­di­ente del len­guaje de pro­gra­ma­ción. Una vez que el cál­culo de líneas de código es hecho a tra­vés de her­ra­mi­en­tas auto­má­ti­cas, el número de pun­tos de fun­ción podría ser deri­vado de inme­di­ato. Por ejem­plo, uti­li­zando un fac­tor de con­ver­sión de 80 LOC/PF y una apli­ca­ción con 80.000 líneas de código Java, da como resultado 1.000 pun­tos de fun­ción para esa misma aplicación.

 

Sin embargo, esta téc­nica pre­senta erro­res fre­cu­en­te­mente cuando es comparada con un cál­culo manual de pun­tos de fun­ción de una apli­ca­ción. Esto se debe a que se asume una rela­ción linear entre el tamaño fun­ci­o­nal (en pun­tos de fun­ción) y el tamaño físico del pro­grama (en líneas de código), que son gran­de­zas dis­tin­tas. Otro aspec­to es que no hay con­senso entre las dis­tin­tas orga­ni­za­ci­o­nes que publi­can estas rela­ci­o­nes. Los núme­ros pre­sen­ta­dos pue­den diver­gir hasta un 100%. Cuando se tiene un escena­rio del sis­tema desar­rol­lado con ua combinación de len­guaje de pro­gra­ma­ción, la cues­tión se com­plica cada vez más. La siguiente tabla pre­senta un ejem­plo de esas vari­a­ci­o­nes para el len­guaje COBOL:

 

Fuente

Fac­tor de Con­ver­sión (COBOL)

Quan­ti­ta­tive Soft­ware Management

77 LOC/PF

Capers Jones

107 LOC/PF

David Con­sul­ting Group

177 LOC/PF

 

Estas variaciones pueden explicarse por las dis­tin­tas premisas usadas en la defi­ni­ción de línea de código y bases de proyec­tos con carac­te­rís­ti­cas muy dis­tin­tas. DE ahí nace la nece­si­dad de cali­brar ese fac­tor de con­ver­sión para la rea­li­dad de los proyec­tos desar­rol­la­dos por la pro­pia orga­ni­za­ción. Sin embargo, para efec­tuar esa cali­bra­ción se debe usar una mu­es­tra repre­sen­ta­tiva de proyec­tos desar­rol­la­dos en deter­mi­nado len­guaje y un pro­fe­si­o­nal con expe­ri­en­cia para saber inter­pre­tar los resul­ta­dos y las razo­nes de posi­bles dis­tor­si­o­nes para ese fac­tor de conversión.

 

Debido a esos fac­to­res, apli­car back­fi­ring para obte­ner un tamaño en pun­tos de fun­ción a par­tir de líneas de código, es una téc­nica arri­es­gada y sujeta a un mar­gen de error mayor. El pro­prio IFPUG resalta en su FAQ, que puede ser usada (con cau­tela) en sis­te­mas lega­dos, en los que un cál­culo manual de pun­tos de función es invi­a­ble en la prác­tica y la pre­ci­sión no es un fac­tor crí­tico.

 

Algu­nos pro­fe­si­o­na­les creen que back­fi­ring es una manera rápida y barata de obte­ner el tamaño en pun­tos de fun­ción del port­fo­lio de apli­ca­ci­o­nes de una orga­ni­za­ción. Otros argu­men­tan que es mejor inver­tir en el cál­culo manual de los pun­tos de fun­ción y tener con­fi­a­bi­li­dad de los datos con com­pen­sa­ción a largo plazo.

 

Por otro lado, muchos mode­los de estimación de soft­ware, como el COCOMO II, uti­li­zan como datos de entrada el tamaño en líneas de código. En esos casos, es común rea­li­zar el inverso: obte­ner el número de líneas de código a par­tir del tamaño en pun­tos de fun­ción, debido a que en las fases ini­ci­a­les de un proyecto de soft­ware es más fácil esti­mar o medir su tamaño en pun­tos de fun­ción. Las con­si­de­ra­ci­o­nes ante­ri­o­res sobre back­fi­ring también son válidas en estos casos. 

 

19. ¿Qué es el estándar ISO/IEC de medición de tamaño funcional?

 

Con el obje­tivo de resol­ver las incon­sis­ten­cias exis­ten­tes entre diver­sos méto­dos sur­gi­dos a par­tir del modelo de Aná­li­sis de Pun­tos de Fun­ción pro­pu­esto por Allan Albre­cht y esta­ble­cer un método más rigo­roso de medi­ción de tamaño fun­ci­o­nal, fue creado un grupo de tra­bajo deno­mi­nado WG12 (Wor­king Group 12), subor­di­nado al SC7 (Sub-Committee Seven) del JTC1 ( Joint Tech­ni­cal Com­mit­tee One) y regulado por la ISO (Inter­na­ci­o­nal Orga­ni­za­tion for Standarzation) en con­junto con el IEC (INtern­ci­o­nal Engineering).

 

Como el resul­tado, fue esta­ble­cida la norma 14.143, que es divi­dida en cinco partes:

 

14.143–1: Defi­ni­ción de concepción

14.143–2: Eva­lu­a­ción de la Con­for­mi­dad de Méto­dos de Medi­ción de Soft­ware con Rela­ción a el patrón ISO/IEC 14143–1

14.143–3: Veri­fi­ca­ción de un Método de Medi­ción de Tamaño Funcional

14.143–4: Modelo de Refe­ren­cia para Medi­ción Fun­ci­o­nal de Tamaño

14.143–5: Deter­mi­na­ción de Domi­nios Fun­ci­o­na­les para uso con Medi­ción de Tamaño Funcional.

 

La norma ISO/IEC 14143 fue desar­rol­lada para garan­tizar que todos los méto­dos de Medi­ción de Tamaño Fun­ci­o­nal sean basa­dos en con­cep­tos simi­la­res y que pue­dan ser probados para ase­gu­rar un comportamiento similar y de forma espe­rada por un método de medi­ción, depen­di­endo de los domi­nios fun­ci­o­na­les a los que se se aplican.

 

Al final de 2002, la téc­nica de Aná­li­sis de Pun­tos de Fun­ción, en su ver­sión No. 4 del manual del IFPUG, fue apro­bada (bajo la norma 20.296) como un método de Medi­ción de Tamaño Fun­ci­o­nal conforme la norma ISO/IEC 14.143.

 

 

20. ¿Además del Análisis de Puntos de Función del IFPUG, existen otros métodos estándar de medición funcional?

 

Sí, exis­ten otros tres méto­dos estándar de medi­ción funcional:

 

1. NESMA – Aso­ci­a­ción de Métri­cas de Holanda. La NESMA man­ti­ene su pro­prio manual de cál­culo, actu­al­mente en la ver­sión 2.0. Su pri­mera ver­sión fue publicada en 1990. Su filo­so­fía, con­cep­tos, tér­mi­nos y reglas tuvieron como referencia el IFPUG, con algu­nas variaciones en sus direc­tri­ces. La medi­ción de un proyecto de desar­rollo o de una apli­ca­ción pro­duce resul­ta­dos pró­xi­mos tanto en el abor­daje del IFPUG como en el de NESMA. Sin embargo, estas orga­ni­za­ci­o­nes tienen enfoques distintos para la apli­ca­ción del Aná­li­sis de Pun­tos de Fun­ción en proyec­tos de mejora de software.

 

2. Mark II – Fue for­mu­lado por Char­les Symons a mediados de la década de 1980, pero su dise­mi­na­ción fue difícil inicialmente porque pertenecía a la con­sul­to­ría KPMG. Actu­al­mente, es un método de domi­nio público regulado por la aso­ci­a­ción de métri­cas de Inglaterra – UKSMA. Es un método de apli­ca­ción res­tringida al Reino Unido.

 

3. COSMIC – En 1997, un grupo de investigación de la Uni­ver­si­dad de Que­bec presentó un método de medi­ción fun­ci­o­nal para sis­te­mas en tiempo real, deno­mi­nado Full Func­tion Points (FFP). En 1998, un grupo de espe­ci­a­lis­tas en medi­ción de soft­ware cons­ti­tuyó COSMIC (Com­mon Soft­ware Mea­su­re­ment Inter­na­ci­o­nal Con­sor­tium) con el obje­tivo de desar­rol­lar un nuevo método de medi­ción de tamaño fun­ci­o­nal basado en las mejo­res carac­te­rís­ti­cas de los méto­dos exis­ten­tes y que incor­po­rara nue­vas ideas. 

 

Este método pro­pu­esto en 2000, denominado COSMIC-FFP, fue una versión actualizada del método FFP. A pesar de que no es una téc­nica tan dise­mi­nada como la del IFPUG, existen varias investigaciones en torno y el mercado sigue atento a sus novedades. 

 

 

21. ¿Cuáles son los primeros pasos para aplicar el FPA en mi Organización?

 

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) 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.)

 

 

22. ¿Cuáles son las orientaciones iniciales para la aplicación del FPA en estimación de proyectos de software?

 

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. 

 

 

23. ¿Cuáles son las orientaciones iniciales para la aplicación del FPA en contratos de desarrollo de software?

 

 

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. 

 

 

24. ¿Cuáles son las orientaciones generales para el uso del FPA en el proceso de benchmarking de la productividad en el desarrollo de software?

 

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.

 

25. ¿La estimación del esfuerzo (horas) a partir del tamaño (PF) es relativa sólo a las actividades de construcción o de todo el ciclo?

 

Las principales preguntas que un proceso de estimación de software intenta responder están relacionadas al tiempo necesario para concluír un proyecto y al costo de su desarrollo. Las respuestas, a su vez, sólo pueden ser consideradas confiables si todas las actividades involucradas en la producción del software fueran estimadas respecto a los factores que afectan las variables de tiempo y costo. Tales actividades incluyen desde la definición de requerimientos hasta las pruebas e implantación del producto.

 

El análisis de puntos de función es un método utilizado para identificar uno de esos factores: el tamaño del software. En un proceso de estimación de software y el tamaño es la primera grandeza a ser analizada. Sin éste, las demás estimacioness (como esfuerzo, duración, costo y número de defectos) no pueden ser determinadas sin que sea adicionado un alto grado de subjetividad a los resultados.

 

Con base en la cantidad de puntos de función es posible obtener indicadores como la tasa de entrega (H/FP), costo ($/FP) e indicadores de calidad (Defectos/FP) de proyectos ya realizados. Se pueden entonces extrapolar estas informaciones (de otra forma inaccesible o de dificil apuración) para la aplicación en procesos de estimación de nuevos proyectos.

 

Simplificando, si se sabe CUANTO debe ser producido, se puede extrapolar cuál será el esfuerzo, plazo y costo de este trabajo. De ahí, se pueden distribuir estos valores entre las varias fases del ciclo de vida del desarrollo de software, desde que sean conocidos los porcentajes de distribución de esfuerzo determinados por el proceso de producción de software adoptado por la organización.

 

 

26. ¿En cuáles situaciones la tercerización de la medición de puntos de función puede tener más beneficios?

 

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.

 

 

27. ¿Qué son puntos por Caso de Uso (o Use case points)?

 

 

Hasta el inicio de la década de 1990, existía una falsa noción de que el FPA no era adecuado para medir sistemas orientados a objetos. Aquellos que compartían esta noción, en la práctica desconocían el FPA.

 

Con la diseminación de la construcción y proyecto de sistemas orientados a objetos, hubo también un cambio en la forma de especificar y modelar los sistemas. El UML y los casos de uso rapidamente se volvieron estándar en la industria de software.

 

Dentro de este contexto, en 1993 Gustav Karner propuso en un trabajo académico la metodología de los puntos por Caso de Uso (basado en el Análisis de Puntos de Función) con el objetivo de estimar recursos para proyectos de software orientados a objetos desarrollados utilizando el proceso objectory.

 

El proceso de medición del PCU consiste (resumidamente) en:

 

1- Contar los actores e indentificar su complejidad
2- Contar los casos de uso e identificar su complejidad
3- Calcular los PCUs no ajustados
4- Determinar el factor de complejidad técnica
5- Determinar el factor de Complejidad ambiental
6- Calcular los PCUs ajustados

 

Con el resultado de esta medición y la productividad media de la organización para producir un PCU, se puede estimar el esfuerzo total para el proyecto.

 

 

 

28. ¿Cuáles son las ventajas del FPA en relación a los Puntos por Caso de uso (PCU o UCP)?

 

En primer lugar, es necesario aclarar que solamente la técnica del PCU es adecuada para medir sistemas cuyos requerimientos fueron expresados a través de casos de uso. El FPA puede ser utilizado también para medir sistemas cuyos requerimientos fueron documentados utilizando otra metodología.

 

A continuación son listadas algunas ventajas del FPA en relación al PCU:

 

1. El PCU solamente puede ser aplicado en proyectos de mejora cuya especificación haya sido expresada en casos de uso. La medición del FPA puede realizarse independiente de la forma en la que sus requerimientos son expresados. Esta ventaja del FPA fue citada por el propio Gustav Karner en su trabajo original "Resource Estimation for Objectory Projects"(1993). 

 

2. No es posible aplicar el PCU en la medición de aplicaciones existentes cuya documentación esté desactualizada o ni siquiera exista. La alternativa sería escribir los casos de uso de estas aplicaciones para medirlas. Sin embargo, esto volvería la medición inviable en un análisis de costo Vs beneficio. Con el FPA es posible realizar la medición analizando la propia aplicación en uso.

 

3. No existe un estándar único para la escritura del caso de uso. Diferentes estilos en la escritura de los casos de uso o en su granularidad pueden llevar a resultados diferentes en la medición por PCU. La medición por el FPA de los casos de uso de un sistema siempre llegará al mismo resultado independiente del estilo de escritura de los casos de uso o de su granularidad, pues el FPA "quiebra" el requerimiento en el nivel adecuado para la medición usando el concepto de proceso elemental.

 

4. Debido a que el proceso de medición del PCU se basa en Casos de Uso, el método no puede ser empleado antes de concluir el análisis de requerimientos del proyecto. La mayoría de las veces, existe la necesidad de obtener una estimación antes de la finalización de esta etapa. El proceso de medición del FPA sólo puede ser empleado después del levantamiento de los requerimientos del proyecto. Sin embargo, existen técnicas estimadas de tamaño en puntos de función que pueden ser aplicadas con éxito antes de que el análisis de requerimientos sea concluido. Un ejemplo de esto, son las mediciones indicativa y estimativa propuestas por la NESMA. Vea el artículo Medición Anticipada de Puntos de Función.

 

5. El método del PCU no contempla la medición de proyectos de mejora (mantenimiento) de software, solamente proyectos de desarrollo. El FPA contempla la medición de proyectos de desarrollo, proyectos de mejora y aplicaciones. Estos otros tipos de medición cumplen un importante papel en programas de métricas y en la contratación de desarrollo de software.

 

6. No existe un grupo de usuarios u organizaciones responsables por la estandarización o evolución del método PCU; y la bibliografía sobre el asunto es escasa. No hay un cuerpo de conocimiento oficial sobre PCU. Para el FPA existe el FPUG, que es el responsable por mantener y actualizar el Manual de Prácticas de Medición. También, hay diversos foros de discusión sobre el FPA para cambiar experiencias.

 

7. El método PCU no es adherente a la norma ISO/IEC 14143 que define un modelo para la medición funcional de software. El FPA, conforme el manual del IFPUG, está estandarizado según la norma ISO/IEC 20926 como un método de medición funcional adherente a la ISO/IEC 14.143.

 

8. No existe un programa de certificación de profesionales que reconozca la técnica del PCU y  la apliquen de forma adecuada. El IFPUG posee el programa de certificación CFPS para el FPA.

 

9. El factor ambiental inmerso en el PCU dificulta su aplicación en programas de métricas de software y benchmarking entre organizaciones, ya que el tamaño de un proyecto es variable; sin que su funcionalidad por lo menos cambie. Si un mismo proyecto es entregado por dos equipos distintos, la medición de los puntos por caso de uso de este proyecto será también diferente en cada situación. Es decir, el mismo proyecto tiene dos tamaños.

 

10. La determinación de los factores técnicos y ambientales del PCU está sujeta a un cierto grado de subjetividad que dificulta la consistencia de la aplicación del método en diferentes organizaciones. El factor de ajuste del FPA también posee el mismo problema, El IFPUG posee directrices específicas que ayudar a minimizar (pero no eliminar) este impacto. Sin embargo, el uso del factor de ajuste en el FPA es opcional y la medición de los puntos de función no ajustados actualmente es un proceso objetivo.

 

Dentro de las ventajas citadas del PCU en relación al FPA, algunas podrían ser superadas con ajustes simples. Sin embargo, no hay beneficio adicional del PCU en relación al FPA. Usar ambos métodos tampoco compensaría el costo adicional de medición para entrenar el equipo en los dos métodos.

 

Aunque el FPA no es una técnica perfecta, posee madurez en el mercado con relación a su uso y el IFPUG trabaja continuamente para su evolución.

 

 

 

29. ¿Qué tipos de software pueden ser medidos por el FPA?

 

El Análisis de Puntos de Función (FPA) es una técnica para medir las funcionalidades ofrecidas por un software a sus usuarios. Esta medición es siempre hecha desde una perspectiva externa; desde el punto de vista de los usuarios. Cabe destacar que el concepto de usuario para el FPA es más amplio; usaurio es cualquier persona o cosa que interactúa con el software en cualquier momento, es decir, puede ser tanto una persona actuando como usuario final u otro software que utiliza servicios del software en análisis.

 

Considerando que cualquier software ofrece uno o más servicios (funciones) para alguien (persona o cosa); entonces se puede concluir que cualquier software puede ser medido por el FPA.

 

Un error común es usar como punto de vista del análisis únicamente el usuario final. En algunos casos, el software será parcialmente (o completamente) "Invisible" para el usuario final, generando una conclusión errdad: el FPA no sirve para medir aquel software. El error más común es aprender los principios del FPA aplicados a sistemas con pantallas e informes. Sin embargo, cuando éste se enfreta a un software que no posee pantallas, como por ejemplo, con procesamiento batch, middlwares, software básicos, es natural sentir dificultades para hacer la medición.

 

Cuando el objetivo es medir un driver de impresora y no hay un usuario final (persona) para este tipo de software, el primero es "invisible" para el usuario final. Sin embargo, el driver de impresora existe para ofrecer servicios a alguien; en este caso el sistema operativo. Por tanto, al analizar el driver de la impresora en la perspectiva del sistema operativo, es posible ver funciones; por ejemplo: funciones para iniciar la impresora, informar la situación general del dispositivo, imprimir, alterar tinta próxima del final, entre otros.

 

 

30. ¿El FPA puede generar estimaciones para las pruebas de aceptación y de sistemas?

 

Las afir­ma­ci­o­nes y cues­ti­o­na­mi­en­tos dis­tor­cionados sobre la téc­nica de Aná­li­sis de Pun­tos de Fun­ción, demuestran el descono­ci­mi­ento sobre el asunto. Por ejemplo, la falsa afir­ma­ción “El Aná­li­sis de Pun­tos de Fun­ción no sirve para medir sis­te­mas ori­en­ta­dos a objetos".

 

Reci­en­te­mente, con la con­so­li­da­ción de la UML como el len­guaje estándar de mer­cado para el aná­li­sis y el proyecto ori­en­tado a obje­tos, otra afir­ma­ción falsa es que el Aná­li­sis de Pun­tos de Fun­ción no sirve para medir sis­te­mas que tie­nen requerimientos expresados con espe­ci­fi­ca­ci­o­nes de casos de uso. Una dis­cu­sión espe­cí­fica sobre ese asunto fue pre­sen­tada en el Bole­tín de Marzo de 2004 del IFPUG.

 

Desde 1990, una téc­nica de geren­cia de pruebas sur­gida en Holanda, lla­mada “TMap – Test Mana­ge­ment Appro­ach” viene con­quis­tando adep­tos. Fue impul­sada por la tendencia de ini­ci­a­ti­vas de mejo­ra de pro­ce­sos basa­das en patro­nes de cali­dad como ISO y CMMI. Su imple­men­ta­ción es apoyada por una téc­nica de Estimación de Prueba lla­mada Test Point Analy­sis (TPA) o Aná­li­sis de Pun­tos de Prueba que, a su vez, tiene como referencia el Aná­li­sis de Pun­tos de Función.

 

La TPA es uti­li­zada espe­cí­fi­ca­mente para esti­mar el esfu­erzo nece­sa­rio en la eje­cu­ción de tes­tes de acep­ta­ción y de sis­te­mas. Para eso, la TPA con­si­dera rele­van­tes, ade­más del tamaño fun­ci­o­nal deter­mi­nado por los pun­tos de fun­ción, otros dos ele­men­tos: la estra­te­gia de tes­t y la pro­duc­ti­vi­dad. De la misma forma, cuando trata el ele­mento tamaño funcional, adi­ci­ona fac­to­res que tienen una influ­en­cia mayor en el esfu­erzo, como com­ple­ji­dad algo­rít­mica, grado de inte­gra­ción con otras fun­ci­o­nes y uni­for­mi­dad funcional.

 

A pesar de ser una téc­nica con­sis­tente y útil para el aumento de cali­dad del pro­ceso y pro­ducto de soft­ware, la TPA plantea un con­cepto diferente sobre el aná­li­sis de pun­tos de fun­ción, cuando afirma que ésta no puede ser uti­li­zada en la Estimación de esfu­erzo de las acti­vi­da­des invo­lu­cra­das en las pruebas de acep­ta­ción y de sis­tema. Esto indica que el FPA con­si­dera las par­ti­cu­la­ri­da­des del pro­ceso de desar­rollo durante la apli­ca­ción de la téc­nica de cál­culo, lo cual no es verdadero.

 

El resul­tado de la apli­ca­ción de la TPA es medido en uni­dad de esfu­erzo (horas), dife­ren­te del aná­li­sis de pun­tos de fun­ción, que mide el tamaño fun­ci­o­nal del proyecto de soft­ware. De esa forma, el esfu­erzo emple­ado en las pruebas no es medidio directamente. El FPA tampoco mide el esfu­erzo emple­ado en la fase de aná­li­sis, proyecto o cons­truc­ción del soft­ware. Su prin­ci­pal fun­ción es medir la fun­ci­o­na­li­dad entre­gada por el proyecto de soft­ware. Sin embargo, los pun­tos de fun­ción pue­den ser uti­li­za­dos como datos de entrada de un pro­ceso de esti­mación de esfu­erzo de las dife­ren­tes fases del desar­rollo, como fue mencionado en el Bole­tín de Enero de 2004.

 

El mayor bene­fi­cio de la TPA está en reu­nir de forma sis­te­má­tica los fac­to­res que influ­yen en el esfu­erzo espe­cí­fico de una de las eta­pas del pro­ceso de desar­rollo, pro­du­ci­endo resul­ta­dos más precisos.

 

 

 

31. ¿Cuál es el concepto del término “Usuario” para el FPA?

 

Cuando se menciona el tér­mino “usu­a­rio” en el área de Tecnología de la Información, gene­ral­mente se refiere a la per­sona que interactua o uti­liza un software.

 

Teniendo en cuenta que el FPA es un método estándar que mide el soft­ware desde el punto de vista del usu­a­rio, el tér­mino usu­a­rio tiene un sen­tido más amplio. Según el Manual de Prác­ti­cas de Medición, usu­a­rio es cual­quier per­sona o cosa que se comu­nica o interactua con el soft­ware en cual­quier momento. Es decir, ade­más de una per­sona, un usu­a­rio puede ser un grupo de per­so­nas que juega un papel espe­ci­fico durante su ite­ra­ción con el soft­ware: el ges­tor de un depar­ta­mento, otro soft­ware y otro equipo. Para el FPA, inte­ractuar con el soft­ware sig­ni­fica enviar datos para la apli­ca­ción o reci­bir datos de esta.

 

Cabe obser­var que esta defi­ni­ción de usu­a­rio tiene un sen­tido pró­ximo al con­cepto de un actor de un caso de uso: cual­quier per­sona y/o cosa que interactúa con el sis­tema y espera un resul­tado de valor pro­du­cido por la eje­cu­ción de uno o diver­sos casos de uso.

 

Teniendo en cuenta ese con­cepto de usu­a­rio, durante un cál­culo de pun­tos de fun­ción con­vi­ene bus­car en el con­junto de usu­a­rios posi­bles aquel que tenga la visión que mejor repre­senta las fun­ci­o­nes que la apli­ca­ción. Por ejem­plo, la apli­ca­ción de autoservicio de un banco tiene como usu­a­rios: el cli­ente del banco, el fun­ci­o­na­rio de la agen­cia, el gerente del depar­ta­mento res­pon­sa­ble, el usu­a­rio que espe­ci­fica los requerimientos y las reglas de nego­cio.

 

 

32. ¿Cómo el FPA define el término “Aplicación”?

 

En el área de tec­no­lo­gía de infor­ma­ción, de manera gene­ral, el tér­mino “apli­ca­ción” es uti­li­zado para desig­nar un pro­grama eje­cu­ta­ble que cum­ple una serie de obje­ti­vos espe­cí­fi­cos de los usu­a­rios. Como ejem­plos clá­si­cos pode­mos citar la cal­cu­la­dora del Win­dows, o Cuen­tas a Pagar, etc.

 

Los desar­rol­la­do­res, por su lado, sue­len deter­mi­nar el alcance de las apli­ca­ci­o­nes según la seg­men­ta­ción física del soft­ware. Por lo anterior, un con­junto único de fun­ci­o­nes rela­ci­o­na­das es sepa­rado según cues­ti­o­nes tecnológicas:

  1. Los modos de eje­cu­ción física. Ejem­plo, fun­ci­o­nes eje­cu­ta­das batch o on-line.
  2. Las pla­ta­for­mas físi­cas en que los sub­con­jun­tos de fun­ción resi­den. Ejem­plo, main­frame o PC (pla­ta­forma baja).
  3. Las arqui­tec­tu­ras donde las apli­ca­ci­o­nes son proyec­ta­das. Ejem­plo, desk­top, cliente-servidor, web o 3-tier.

En el aná­li­sis de pun­tos de fun­ción una apli­ca­ción es defi­nida según la visión del usu­a­rio y de acu­erdo con con­si­de­ra­ci­o­nes de nego­cio y no con cues­ti­o­nes téc­ni­cas. Según el Manual de Prác­ti­cas de Cál­culo (CPM), una apli­ca­ción es un con­junto de datos y pro­ce­di­mi­en­tos, módu­los o sub­sis­te­mas. Fre­cu­en­te­mente, el tér­mino “apli­ca­ción” es uti­li­zado como sinó­nimo de sis­tema, sis­tema apli­ca­tivo o sis­tema de información.

 

Para el Aná­li­sis de Pun­tos de Fun­ción, la definición del tér­mino y su iden­ti­fi­ca­ción (deli­mi­tada por su fron­tera) de apli­ca­ción correctas  son la base para el empleo con­sis­tente de la téc­nica, evi­tando sobredimensionamientos o subdimensionamiento durante los cálculos.

33. ¿Es posible usar el FPA en proyectos que siguen un enfoque "Ágil"?

 

¡Claro que si! El FPA es una técnica independiente de la tecnología usada para modelar o implementar un software. Por ello, un software tendrá el mismo tamaño en puntos de función así sea desarrollado utilizando un enfoque ágil u cualquier otro enfoque.

 

Lo que irá a diferenciar la medición de un proyecto "ágil" y otro tradicional serán los artefactos usados para realizar el análisis. En un enfoque más convencional, por ejemplo similar al RUP, los artefactos usados para la medición serán probablemente especificaciones de casos de uso, que son descripciones detalladas de las funcionalidades desde el punto de vista del usuario con el software.

 

En el enfoque ágil, existe un mayor enfoque en entregar el software funcionando y no en producir una documentación detallada de lo que será realizado. Por lo anterior, para la medición en un enfoque ágil son usadas las historias de usuario, que son descripciones breves de las funcionalidades deseadas por el usuario.

 

Sin embargo, las historias de usuario no son suficientes para proveer toda la información necesaria para la medición de los puntos de función (aunque sean suficientes para ofrecer una estimación/aproximación del tamaño en FPs). Entonces, ¿Cómo se mide el proyecto?

 

El desarrollador tampoco construye el software únicamente con la información de las historias de usuario. Se necesita que los requerimientos sean detallados para que se pueda construir el software deseado. Por lo que, éste podrá encontrar una información más detallada, además de las historias de usuario, con el propio usuario. El enfoque ágil busca que el usuario participe del equipo de desarrollo, en una interacción próxima con los desarrolladores.

 

Por ello, el desarrollador podrá usar información detallada de los requerimientos para construir el software y realizar la medición de Puntos de Función.

 

 

34. ¿Cuáles son los objetivos del Manual de Prácticas de Medición del IFPUG?

 

  • Ofre­cer una des­crip­ción clara y detal­lada de la medición de pun­tos de función.

 

  • Garan­tizar que los cál­cu­los sean con­sis­tentes con las prác­ti­cas de los miem­bros afili­a­dos al IFPUG.

 

  • Ofre­cer ori­en­ta­ción sobre la realización de los cál­cu­los de pun­tos de fun­ción basa­das en los arte­fac­tos y las meto­do­lo­gías más uti­li­za­das de desar­rollo de software.

 

  • Pro­veer un enten­di­mi­ento común para que los desarrolladores de her­ra­mi­en­tas ofrezcan soporte auto­má­tico al cál­culo de pun­tos de función.

 

  • Ser adhe­rente al estándar ISO/IEC 14143–1 de medi­ción fun­ci­o­nal de software.

 

35. ¿Cómo es el proceso de cálculo de puntos de función?

 

Resu­mi­da­mente el pro­ceso de cál­culo de pun­tos de fun­ción es com­pu­esto por los sigui­en­tes pasos:

 

1. Iden­ti­fi­ca­ción del pro­pó­sito de la medición:

 

En este paso, el obje­tivo es aclarar lo que se pre­tende atender y el pro­blema que será resuelto con el cál­culo. La forma en que los pasos sigui­en­tes son con­du­ci­dos depende direc­ta­mente de ese propósito.

 

 

2. Deter­mi­na­ción del tipo de cálculo:

 

Exis­ten tres tipos de cál­culo de pun­tos de fun­ción. La dife­ren­cia en el pro­ce­di­mi­ento adop­tado entre esos tipos de cál­culo está en las for­mu­las apli­ca­das en el paso final del cálculo.

 

  • Proyecto de desar­rollo: Mide todas las fun­ci­o­nes que el proyecto entre­gará y even­tu­a­les fun­ci­o­nes de con­ver­sión de datos.

 

  • Proyecto de mejo­ra: Mide las fun­ci­o­nes alte­ra­das, inclui­das y exclui­das por el proyecto y even­tu­a­les fun­ci­o­nes de con­ver­sión de datos.

 

  • Apli­ca­ción: Mide las fun­ci­o­nes de un soft­ware instalado.

3. Iden­ti­fi­ca­ción de la fron­tera de la apli­ca­ción y del alcance del cálculo:

 

La fron­tera de la apli­ca­ción es la inter­faz con­cep­tual entre el soft­ware y el usu­a­rio. Ésta divide el soft­ware y el mundo externo. Es un ele­mento esen­cial para la cor­recta iden­ti­fi­ca­ción de las fun­ci­o­nes del tipo dato y tran­sac­ción en los pasos sigui­en­tes. El alcance del cál­culo define lo que hará parte del cál­culo de pun­tos de función.

 

4. Cál­culo de las fun­ci­o­nes tipo dato:

 

Las fun­ci­o­nes del tipo dato repre­sen­tan los requerimientos de alma­ce­na­mi­ento del usu­a­rio. Son cla­si­fi­ca­dos en:

 

  • Fichero Lógico Interno (ILF): Gru­pos de datos lógi­ca­mente rela­ci­o­na­dos (del punto de vista del usu­a­rio) y man­te­nido por la pro­pia aplicación.

 

  • Fichero de Inter­faz Externo (EIF): Gru­pos de datos lógi­ca­mente rela­ci­o­na­dos (del punto de vista del usu­a­rio) y sola­mente de pun­tos de fun­ción de otras aplicaciones.

 

En ese paso son iden­ti­fi­ca­dos todos los ILFs/EIFs del sis­tema. La com­pleji­dad es determinada según dos pará­me­tros (tipo de dato y tipos de regis­tro) y; aso­ci­ada a cada com­ple­ji­dad una can­ti­dad de pun­tos de fun­ción correspondiente.

 

5. Cál­culo de las fun­ci­o­nes de tipo transacción:

 

Las fun­ci­o­nes del tipo tran­sac­ción repre­sen­tan los requerimientos de pro­ce­sa­mi­ento del usu­a­rio. Son cla­si­fi­ca­das en:

 

  • Entra­das Exter­nas (EI): Tran­sac­ci­o­nes con el obje­tivo de actu­a­li­zar  fiche­ros lógi­cos inter­nos o modi­fi­car el com­por­ta­mi­ento del sistema.
  • Con­sulta Externa (EQ): Tran­sac­ci­o­nes que repre­sen­tan una sim­ple recu­pe­ra­ción de datos de  fiche­ros lógi­cos inter­nos y/o fiche­ros de inter­faz externa.
  • Salida Externa (EO): Tran­sac­ci­o­nes con el obje­tivo de repre­sen­ta­ción de infor­ma­ción, ade­más envol­vi­endo lógica de pro­ce­sa­mi­ento adi­ci­o­nal a una con­sulta externa.

 

En ese paso son iden­ti­fi­ca­das todas las tran­sac­ci­o­nes del sis­tema. Su com­ple­xi­da­d es deter­mi­na­da con base en dos pará­me­tros (tipos de dato y archivos refe­ren­ci­a­dos) y; aso­ci­ada a cada com­pleji­dad existe una can­ti­dad de pun­tos de fun­ción correspondiente.

 

6. Cál­culo de fac­tor de ajuste:

 

El fac­tor de ajuste repre­senta la influ­en­cia de los requerimientos téc­ni­cos y de cali­dad en el tamaño del soft­ware. Es cal­cu­lado con base en las 14 Carac­te­rís­ti­cas Gene­ra­les del Sis­te­mas (CGS) lis­ta­das a seguir:

 

  • Comu­ni­ca­ción de Datos
  • Pro­ce­sa­mi­ento Distribuido
  • Rendimiento
  • Con­fi­gu­ra­ción Alta­mente Utilizada
  • Volu­men de Transacciones
  • Entrada de Datos OnLine
  • Efi­ci­en­cia del Usu­a­rio Final
  • Actu­a­li­za­ción On-Line
  • Com­ple­ji­dad de Procesamiento
  • Reu­ti­li­za­ción
  • Faci­li­dad de Instalación
  • Faci­li­dad de Operación
  • Múl­ti­ples Locales
  • Faci­li­dad de Cambio

 

Cada una de esas carac­te­rís­ti­cas debe ser ana­li­zada con rela­ción a su nivel de influ­en­cia sobre el sis­tema y pun­tu­ada de 0 (nin­guna influ­en­cia) a 5 (influ­en­cia grande). Se deberán sumar todas esas pun­tu­a­ci­o­nes para obte­ner el nivel total de influ­en­cia (TDI). Es posible usar la sigui­ente fór­mula para obte­ner el fac­tor de ajuste: VAF = (TDI x 0,01)+ 0,65.

 

Actu­al­mente, este es un paso opci­o­nal del pro­ceso de cál­culo. Muchas orga­ni­za­ci­o­nes des­con­si­de­ran el fac­tor de ajuste y usan sola­mente la medi­ción de los pun­tos de fun­ción no ajus­ta­dos. Las ori­en­ta­ci­o­nes para la deter­mi­na­ción del VAF pueden ser úti­les para la diferenciación entre requerimientos fun­ci­o­na­les y requerimientos téc­ni­cos y de calidad.

 

7. Cál­culo de pun­tos de fun­ci­o­nes ajustados.

 

El cál­culo final de los pun­tos de fun­ción ajus­tados con­siste bási­ca­mente en mul­ti­pli­car el fac­tor de ajuste por los pun­tos de fun­ción no ajus­ta­dos. Sin embargo, exis­ten fór­mu­las espe­cí­fi­cas para cada tipo de cálculo:

 

  • Proyecto de desar­rollo: DFP = (UFP+CFP) x VAF, donde:

 

UFP – Pun­tos de fun­ción de la apli­ca­ción a ser instalada

 

CFP – Pun­tos de fun­ción de las fun­ci­o­na­li­da­des de con­ver­sión de datos

 

VAF – Valor del fac­tor de ajuste

 

 

  • Proyecto de mejo­ría: EFP = [(ADD + CHGA + CFP) x VAFA] + (DEL x VAFB), donde:

 

ADD – Pun­tos de fun­ción de las fun­ci­o­na­li­da­des adicionadas

 

CHGA – Pun­tos de fun­ción de las fun­ci­o­na­li­da­des alteradas

 

CFP – Pun­tos de fun­ción de las fun­ci­o­na­li­da­des de con­ver­sión de datos

 

VAFA – Valor del fac­tor de ajuste del soft­ware des­pués el proyecto de mejora

 

DEL – Pun­tos de fun­ción de las fun­ci­o­na­li­da­des excluidas

 

VAFB – Valor de fac­tor de ajuste del soft­ware antes del proyecto de mejora

 

 

  • Apli­ca­ción: AFP = ADD x VAF

 

Para saber un poco más, vea nuestros videos:

 

 

 

 

 

36. ¿Cuál indicador de productividad (FP/hombre-mes) o tasa de entrega (horas/FP) debe ser utilizado para estimar el esfuerzo de proyectos?

 

 

Existe una ten­ta­ción entre los pro­fe­si­o­na­les en usar indi­ca­do­res “de mer­cado” para sus esti­maciones basa­das en pun­tos de fun­ción. Cier­ta­mente, exis­ten diver­sas fuen­tes en las que es posible obte­ner núme­ros rela­ci­o­na­dos a la pro­duc­ti­vi­dad con pun­tos de fun­ción para diver­sos con­tex­tos tec­no­ló­gi­cos. El ISBSG (Inter­na­ci­o­nal Soft­ware Ben­ch­mar­king Stan­dards Group) es una de ellas. Sin embargo, usar esas fuen­tes des­con­si­de­rando sus cálculos y el con­texto de la orga­ni­za­ción es un error. Bajo esas condiciones, las esti­maciones no ten­drán la con­fi­a­bi­li­dad nece­sa­ria o alguna uti­li­dad práctica.

 

La mejor forma de obte­ner indi­ca­do­res de pro­duc­ti­vi­dad útiles en las esti­ma­ciones con pun­tos de fun­ción es apu­rar ese indi­ca­dor a tra­vés de los proyec­tos desar­rol­la­dos por la propia orga­ni­za­ción. El pri­mer paso para hacer esto, es tener como referencia los proyec­tos pasa­dos y calcular las dos gran­de­zas que com­po­nen el indi­ca­dor de pro­duc­ti­vi­dad: el tamaño (en pun­tos de fun­ción) y el esfu­erzo (horas). A partir de estos datos, se puede calcular de forma directa a la pro­duc­ti­vi­dad de aquel proyecto. Si cada proyecto tuvi­era un número de pro­duc­ti­vi­dad dis­tinto, ¿Cuál debe ser emple­ado en el proyecto a ser estimado?

 

Cier­ta­mente, cada proyecto puede pre­sen­tar un número dis­tinto, pero si este pro­ce­di­mi­ento es repe­tido para un con­junto mayor de proyec­tos será posi­ble obser­var que para deter­mi­na­dos sub­con­jun­tos, la pro­duc­ti­vi­dad es bas­tante seme­jante. Eso ocurre cuando los proyec­tos tie­nen carac­te­rís­ti­cas seme­jan­tes en rela­ción a los fac­to­res que afec­tan direc­ta­mente el esfu­erzo para desar­rol­lar­los.

 

Luego, es razo­na­ble con­cluir que depen­di­endo de la natu­ra­leza de los proyec­tos desar­rol­la­dos por la orga­ni­za­ción, no habrá un único indi­ca­dor de pro­duc­ti­vi­dad para todos los proyec­tos; pero sí indi­ca­do­res de pro­duc­ti­vi­dad por gru­pos de proyecto seme­jan­tes. El pri­mer paso para esti­mar un nuevo proyecto es incluirlo en algún grupo de proyectos y usar el indi­ca­dor de pro­duc­ti­vi­dad ade­cu­ado. Pero, ¿Cuá­les son los fac­to­res que defi­nen esos gru­pos de proyectos?

 

Cual­quier vari­a­ble que tenga capa­ci­dad de pro­du­cir un impacto sig­ni­fi­ca­tivo en el esfu­erzo del proyecto debe ser lle­vada en con­si­de­ra­ción en el aná­li­sis de seg­men­ta­ción de gru­pos de proyecto. Con­vi­ene des­ta­car que los fac­to­res pue­den ser dis­tin­tos por empresa. Por ejem­plo: el uso o no de una deter­mi­nada meto­do­lo­gía de desar­rollo de sis­te­mas en el proyecto puede afec­tar su pro­duc­ti­vi­dad. Sin embargo, si en una deter­mi­nada empresa todos los proyec­tos siguen la misma meto­do­lo­gía, este fac­tor será cons­tante y no ten­drá rele­van­cia para la seg­men­ta­ción de proyectos.

 

Sin la pre­ten­sión de esta­ble­cer una lista com­pleta, se pueden citar los sigui­en­tes factores:

 

  • Tipo de proyecto: desar­rollo, mejo­ra, migra­ción, redesarrollo.

 

  • Pla­ta­forma tec­no­lo­gía: main­frame, web, cli­ente-ser­vi­dor, sis­tema embutido.

 

  • Orden de magnitud de los proyectos.

 

  • Tamaño de equipo de desarrollo.

 

  • Her­ra­mi­en­tas de desarrollo.

 

  • Meto­do­lo­gía empleada.

 

  • Área de negocio.

 

  • Número de usuarios.

 

37. ¿Dónde es posible obtener el Manual de Practicas de Conteo del IFPUG?

 

El manual de prác­ti­cas de medición es ofre­cido únicamente por el IFPUG. Para los afili­a­dos está dis­po­ni­ble para descarga gra­tui­ta. Para los no afili­a­dos, se debe adqui­rir direc­ta­mente con el IFPUG.

 

Este manual no es de acceso al público, lo cual difi­culta la difu­sión de la téc­nica de pun­tos de fun­ción. Las orga­ni­za­ci­o­nes res­pon­sa­bles por otros méto­dos de medi­ción fun­ci­o­nal como Mark II (UKSMA) y el COSMIC pro­por­ci­o­nan acceso gra­tuito a sus manuales.

 

Su ver­sión ori­gi­nal está en inglés, pero existen otras versiones dis­po­ni­bles en español, ita­li­ano, core­ano y portugués.

 

 

38. ¿Cuántos puntos de función un analista cuanta en un día?

 

Hay una vari­a­ción en la pro­duc­ti­vi­dad en cuanto a la medición de pun­tos de fun­ción por día para un pro­fe­si­o­nal, cau­sada prin­ci­pal­mente por:

 

  • Cono­ci­mi­ento del nego­cio sobre el proyecto/sistema en el que actúa: Si el ana­lista de métri­cas tiene cono­ci­mi­ento del nego­cio, ten­drá faci­li­dad para efec­tuar la medi­ción a pesar de que la docu­men­ta­ción del proyecto/sistema no sea de calidad.

 

  • Cali­dad de la docu­men­ta­ción dis­po­ni­ble: La prin­ci­pal fuente de infor­ma­ción para el cál­culo es la docu­men­ta­ción del proyecto/ sis­tema. Si la docu­men­ta­ción está incom­pleta o ambi­gua, se consumirá más tiempo en la resolución de dudas refe­ren­tes a los requerimientos. La docu­men­ta­ción insu­fi­ci­ente para la medi­ción es uno de los pro­blemas más comunes en el cál­cu­lo de la apli­ca­ción y proyec­tos de mejora.

 

  • Expe­ri­en­cia: Cuanta más expe­ri­en­cia el ana­lista tiene en cál­cu­los, más rápido realiza el aná­li­sis de requerimientos Él aprende a bus­car infor­ma­ci­o­nes que son rele­van­tes para la medi­ción en la docu­men­ta­ción y a separar lo que no le inte­resa, lo cual permite ahorrar tiempo de aná­li­sis en un asunto que no afec­tará la medi­ción). La expe­ri­en­cia acu­mu­lada evita que se analicen situ­a­ci­o­nes que ya fueron retomadas anteriormente. 

 

  • Dis­po­ni­bi­li­dad de los usu­a­rios: A pesar de que se tenga la docu­men­ta­ción dis­po­ni­ble del sis­tema, es nece­sa­rio entre­vis­tar a sus usu­a­rios para com­ple­men­tar alguna nece­si­dad de infor­ma­ción que no fue docu­men­tada o no fue hecho de forma clara. Para sis­te­mas que no tie­nen docu­men­ta­ción, la única forma de medir­los es con el apoyo de los usu­a­rios. Si no hay un usu­a­rio dis­po­ni­ble para brindar la información necesaria, el ana­lista de métri­cas tendrá que esperar a su respuestas para continuar con la medición.

 

  • Pro­pó­sito del cál­culo: Depen­di­endo de la cues­tión que se desea res­pon­der con el cál­culo a ser rea­li­zado, la pre­ci­sión y ras­tre­a­bi­li­dad pue­den no ser asuntos prioritarios. Se puede ana­li­zar de forma más super­fi­cial la docu­men­ta­ción y tam­bién evi­tar un esfu­erzo adi­ci­o­nal en la docu­men­ta­ción del pro­prio cál­culo. Es decir, se puede optar por una esti­ma­ción de tamaño en lugar de la propia medi­ción. Esto dependerá de los nive­les de docu­men­ta­ción y el tiempo destinado a la actividad.

 

  • Auto­mo­ción de pro­ceso: soft­ware de apoyo puede agi­li­zar el cál­culo, prin­ci­pal­mente de las par­tes del pro­ceso que no invo­lu­cran análisis.

 

  • Tipo de cál­culo: En gene­ral, la pro­duc­ti­vi­dad en los proyectos de mejo­ra es mayor que en los proyectos de desar­rollo o cál­culo de apli­ca­ción; prin­ci­pal­mente si la apli­ca­ción está  en man­te­ni­mi­ento (objeto del proyecto de mejo­raa). Lo contrario ocurre, si la medi­ción es para un proyecto de mejo­raa de una apli­ca­ción que nunca fue medida y no tiene docu­men­ta­ción disponible.

 

  • Guía de Cál­culo: La guía de cál­culo es un docu­mento que sim­pli­fica y con­tex­tu­a­liza las reglas del IFPUG para las situ­a­ci­o­nes espe­cí­fi­cas de una orga­ni­za­ción. Para ana­lis­tas con poca expe­ri­en­cia o con poco cono­ci­mi­ento del con­texto de la orga­ni­za­ción, este artefacto faci­li­tará bas­tante el tra­bajo de medi­ción, pro­por­ci­o­nando agilidad.

 

Ana­li­zando la situación desde un escenario poco favorable, donde los fac­to­res cita­dos ante­ri­or­mente esta­rían influ­en­ci­ando de forma nega­tiva el tra­bajo de medi­ción, un límite infe­rior para la pro­duc­ti­vi­dad seria 100 PF/día. Para un esce­na­rio favorable sería razo­na­ble con­si­de­rar 1.000 PF/día. Se puede des­ta­car que la pro­duc­ti­vi­dad media no está en el medio de este rango, pero si más de cerca del esce­na­rio menos favorable, que cor­res­ponde a las situ­a­ci­o­nes más comu­nes. 

 

Depen­di­endo de las espe­ci­fi­ci­da­des que una orga­ni­za­ción tiene, ésta puede even­tu­al­mente pre­sen­tar núme­ros fuera de los rangos citados, pero no significa que sea un com­por­ta­mi­ento típico espe­rado. La pro­duc­ti­vi­dad debajo de 100 PF/día es señal de pro­blema, por lo que se recomienda inves­ti­gar y ata­car sus cau­sas. Muchas veces, el ana­lista de métri­cas eje­cuta acti­vi­da­des de aná­li­sis de requerimientos debido a la falta de docu­men­ta­ción o a la baja cali­dad de la misma. En este caso, no es correcto incluir este esfu­erzo dentro de la medi­ción, pero si en el aná­li­sis de requerimientos.

 

Es conveniente destacar que la pro­duc­ti­vi­dad no es cons­tante durante todo el pro­ceso. El tiempo de pre­pa­ra­ción, aná­li­sis de la docu­men­ta­ción y escla­re­ci­mi­ento de dudas es más pre­do­mi­nante en el ini­cio del cál­culo que dentro del pro­pio cál­culo. Des­pués de esas eta­pas, lo nor­mal es que éste fluya más rápido.

 

 

39. ¿Cuáles son las herramientas indicadas para apoyar e/o automatizar (parcialmente) el uso del APF?

 

El pri­mer punto a tener en cuenta es que no exis­ten her­ra­mi­en­tas capa­ces de pro­du­cir de manera auto­má­tica un cál­culo de pun­tos de fun­ción de forma con­fi­a­ble. Sin embargo, exis­ten her­ra­mi­en­tas dis­po­ni­bles capa­ces de apoyar, auto­ma­ti­zar (par­ci­al­mente), almacenar y gestionar los resultados de los cálculos de medición.

 

La her­ra­mi­enta de uso más sim­ple para regis­trar un cál­culo de pun­tos de fun­ción es una pla­nilla. En la sec­ción Recur­sos de nuestra página, está diis­po­ni­ble una pla­nilla de acceso público para el cál­culo de pun­tos de fun­ción. Su uso empi­eza a ser poco prác­tico en la medida que se inten­si­fica el numero de cál­culos. El con­trol del repositorio es manual y la can­ti­dad cre­ci­ente de datos, pasa a ser una tarea más costosa.

 

Cuando la orga­ni­za­ción percibe que la pla­nilla no ati­ende sus nece­si­da­des actu­a­les, una reacción natu­ral es bus­car en el mer­cado her­ra­mi­en­tas con más recur­sos. El IFPUG tiene un pro­ceso de cer­ti­fi­ca­ción para las her­ra­mi­en­tas de apoyo para el cál­culo de pun­tos de fun­ción. La lista de her­ra­mi­en­tas actu­al­mente cer­ti­fi­ca­das puede ser visu­a­li­zada en SOFTWARE CERTIFICATIONDe acuerdo a esto, las her­ra­mi­en­tas pueden ser cla­si­fi­ca­das en tres tipos:

 

  • Tipo 1: El usu­a­rio hace el cál­culo de pun­tos de fun­ción manu­al­mente y el soft­ware ofrece las fun­ci­o­na­li­da­des de recolección de datos y cálculos.

 

  • Tipo 2: El soft­ware ofrece las fun­ci­o­na­li­da­des de recolección de datos y cál­cu­los y el usu­a­rio y el sis­tema hacen el cál­culo de pun­tos de fun­ción inte­rac­ti­va­mente, a tra­vés de pre­gun­tas pre­sen­ta­das por el sis­tema y acci­o­nes sejecutadas en fun­ción de las res­pu­es­tas ofrecidas.

 

  • Tipo3: El soft­ware pro­duce auto­má­ti­ca­mente un cál­culo de pun­tos de fun­ción usando diver­sas fuen­tes de infor­ma­ción, como la base de datos de la apli­ca­ción, la pro­pia apli­ca­ción y arte­fac­tos de las her­ra­mi­en­tas de desar­rollo. El usu­a­rio puede ingresar datos inte­rac­ti­va­mente, pero se involucra limitadamente durante el cál­culo. Es impor­tante des­ta­car que no exis­ten her­ra­mi­en­tas cer­ti­fi­ca­das de este tipo.

 

Sin embargo, exis­ten diver­sas opci­o­nes de her­ra­mi­en­tas en el mer­cado para apoyar el uso de pun­tos de fun­ción. Muchas orga­ni­za­ci­o­nes optan por desar­rol­lar una her­ra­mi­enta pro­pia inte­grada a sus sis­te­mas de con­tro­les inter­nos. Algu­nas razo­nes para esto pue­den ser:

 

  • El costo para desar­rol­lar una solu­ción interna es menor que el costo de adqui­si­ción y man­te­ni­mi­ento de los paque­tes dis­po­ni­bles en el mercado.

 

  • La falta de soporte local para la solu­ción. La mayo­ría de las her­ra­mi­en­tas dis­po­ni­bles en el mer­cado son extranjeras.

 

  • Nece­si­da­d de inte­gra­ción con sis­te­mas internos.

     

     

40. ¿Existe alguna relación entre el tamaño en puntos de función de un software y el hardware usado para su ejecución?

 

Cuando se trata de requerimientos de hard­ware nece­sa­rios para el ambi­ente de eje­cu­ción de un deter­mi­nado soft­ware, se da enfoque en requerimientos téc­ni­cos o de cali­dad, como capa­ci­dad de pro­ce­sa­mi­ento, volu­men de tran­sac­ci­o­nes y de datos, número de usu­a­rios, segu­ri­dad, entre otros.

 

Los requerimientos fun­ci­o­na­les no tienen influencia. Sin embargo, no hay nin­guna rela­ción directa entre el tamaño de un soft­ware en pun­tos de fun­ción (sea ajus­tado o no) y el hard­ware nece­sa­rio para su ejecución.

 

Sin embargo, el fac­tor de ajuste ana­li­zado de forma ais­lada del tamaño fun­ci­o­nal, con­tem­pla diver­sas carac­te­rís­ti­cas gene­ra­les de sis­tema (Pro­ce­sa­mi­ento Dis­tri­buido, Per­for­mance, Con­fi­gu­ra­ci­o­nes Alta­mente Uti­li­zada, Volu­men de Tran­sac­ci­o­nes) que podrían apoyar la defi­ni­ción de los requerimientos de hard­ware de un soft­ware. A pesar de esto, sería un aná­li­sis insu­fi­ci­ente para la defi­ni­ción de hardware.

 

 

 

41. ¿Es posible aplicar el APF en proyectos de mantenimiento de sistemas?

 

Si, pero no todos los man­te­ni­mi­en­tos de soft­ware pueden ser medi­dos con APF, sólo los man­te­ni­mi­en­tos que alte­ran los requerimientos fun­ci­o­na­les de un soft­ware. En este caso, el IFPUG uti­liza el tér­mino “mejo­ra” en vez de “man­te­ni­mi­ento”, con el fin de aclarar que la mejo­ra no se refiere a cual­quier man­te­ni­mi­ento.

 

En el con­cepto del IFPUG, la mejo­ra mide las fun­ci­o­nes que serán adi­ci­o­na­das, alte­ra­das o exclui­das de la apli­ca­ción y fun­ci­o­nes de con­ver­sión de datos.

 

Los man­te­ni­mi­en­tos para cor­rec­ción de defec­tos y requerimientos no fun­ci­o­na­les no so medi­dos por el APF.

42. ¿En qué momento del ciclo de vida del proyecto de software es posible contar los puntos de función?

 

La única infor­ma­ción de un soft­ware nece­sa­ria para con­tar pun­tos de fun­ción son sus requi­si­tos fun­ci­o­na­les. Una vez que los requi­si­tos están esta­ble­ci­dos, cual­quiera que sea la fase del proyecto es posi­ble rea­li­zar la medi­ción de su tamaño. Es impor­tante des­ta­car tam­bién que la forma por donde sus requi­si­tos están docu­men­ta­dos o expre­sados es irre­le­vante para la medi­ción. Esto sola­mente refu­erza que el Análisis de Puntos de Función (APF) que mide el soft­ware funciona de manera inde­pen­di­ente a su modelo proyec­tado o construido.

 

Sin embargo es válida la sigui­ente cues­tión: Si sólo es posi­ble con­tar pun­tos de fun­ción des­pués de la defi­ni­ción de los requi­si­tos, ¿Cómo pro­du­cir esti­ma­ti­vas para el proyecto antes de ese momento, en el que jus­ta­mente la necesidad por esti­ma­ti­vas es mayor?. En este caso, ¿ El Análisis con Puntos de Función pue­den ser útil?

 

Aunque no se puedan calcular los pun­tos de fun­ción en momento ini­ci­a­les del proyecto (antes que los requi­si­tos sean definidos), es posi­ble esti­mar su tamaño funcional. Exis­ten diver­sas téc­ni­cas alternas para esti­mar el tamaño en pun­tos de fun­ción de un soft­ware. Entre las más comu­nes se encuentran las propuestas por la aso­ci­a­ción de métri­cas de software de Holanda - NESMA.: medición estimativa e medición indicativa. Ver el artículo Análisis temprana de Puntos de Función (Early FPA Counting)

 

43. ¿El APF es una técnica de gestión de proyectos de software?

 

No, APF es un método para medir el tamaño fun­ci­o­nal de un soft­ware. Solo cuan­ti­fica las fun­ci­o­na­li­da­des que el soft­ware ofrece a los usu­a­rios. Sin embargo la téc­nica puede ser una her­ra­mi­enta, entre diver­sas que exis­ten, que el gerente de proyec­tos puede uti­li­zar para apoyar en tareas de gestión.

 

El pro­ceso de medi­ción, tanto cuanto el resul­tado de la medi­ción, ayuda a traer visi­bi­li­dad a diver­sos aspec­tos de proyecto, como por ejem­plo escopo y requisitos.

 

La aso­ci­a­ción entre tamaño fun­ci­o­nal y otras gran­de­zas, como esfu­erzo, costo, can­ti­dad de defec­tos, posi­bi­lita la gene­ra­ción de indi­ca­dora úti­les a la geren­cia para el acom­paña­mi­ento de pro­duc­ti­vi­dad y cali­dad. El indi­ca­dor de pro­duc­ti­vi­dad es muy emple­ado para la gene­ra­ción de esti­ma­ti­vas (basa­das en pun­tos de fun­ción) para el proyecto.

 

 

 

44. ¿El APF carga el esfuerzo de un proyecto de software?

 

La esen­cia del APF, pro­pu­esta por IFPUG, es que el pro­ceso de cál­culo de pun­tos de fun­ción debe ser con­sis­tente (per­so­nas dife­ren­tes midi­endo el mismo proyecto deben encon­trar resul­ta­dos simi­la­res) y tam­bién, prin­ci­pal­mente, que el cál­culo sea sim­ples lo sufi­ci­ente para mini­mi­zar el esfu­erzo de medi­ción, redu­ci­endo el impacto sobre el esfu­erzo glo­bal del proyecto.

 

Como cual­quier acti­vi­dad de un proyecto de desar­rollo o man­te­ni­mi­ento de soft­ware, rea­li­zar el cál­culo de pun­tos de fun­ción demanda un esfu­erzo de un pro­fe­si­o­nal del equipo. Luego habrá un esfu­erzo adi­ci­o­nal en el proyecto para que rea­li­zada la medición.

 

Hay que con­si­de­rar que los bene­fi­cios obte­ni­dos por la rea­li­za­ción de la medi­ción com­pen­san el esfu­erzo adi­ci­o­nal des­pren­dido. En tesis el soft­ware puede ser desar­rol­lado sola­mente con las acti­vi­da­des de codi­fi­ca­ción; sin embargo otras acti­vi­da­des son rea­li­za­das (como aná­li­sis, pla­ne­a­mi­ento, mode­lado, tesis) que va a gra­var el esfu­erzo del proyecto pero pro­por­ci­o­nan bene­fi­cios que suplan­tan ese esfu­erzo adicional.

 

Tra­du­ci­endo en núme­ros, lo ideal sería que ese esfu­erzo oca­si­o­nado por la medi­ción no ultra­pase 2% de esfu­erzo total del proyecto. Es impor­tante des­ta­car que, en muchos casos donde esto no ocurre, la causa está en una defi­ci­en­cia de la espe­ci­fi­ca­ción de los requi­si­tos. En estos casos la mayor parte del esfu­erzo del cál­culo de pun­tos de fun­ción acaba siendo con­su­mido en entre­vis­tas, revi­sión y detal­les de los requi­si­tos. Acti­vi­da­des que debe­rían haber sido rea­li­za­das en la fase de espe­ci­fi­ca­ción pro­pi­a­mente dicho.

 

 

45. ¿Cuáles actividades son comprendidas en la estimación de esfuerzo (utilizando punto de función) de un proyecto de software?

 

Bási­ca­mente todas las acti­vi­da­des que ten­gan rela­ción directa con las cons­truc­ción y entrega de los requi­si­tos fun­ci­o­na­les: levan­ta­mi­ento y espe­ci­fi­ca­ción de requi­si­tos, aná­li­sis, diseño, mode­lado, geren­cia del proyecto, codi­fi­ca­ción, pruebas, apoyo a la homo­lo­ga­ción del usu­a­rio, despliegue y trans­fe­ren­cia de cono­ci­mi­ento de los ser­vi­cios eje­cu­ta­dos.

 

Siendo que varios arte­fac­tos pue­den ser pro­du­ci­dos en estas acti­vi­da­des, como: código fuente, dia­gra­mas, mode­los, casos de uso, manu­a­les, pla­nos, atas, etc.

 

Por com­ple­mento al pará­grafo ante­rior, cual­qui­era acti­vi­dad no direc­ta­mente rela­ci­o­nada a los requi­si­tos fun­ci­o­na­les del proyecto de desarrollo/mantenimiento de soft­ware no está en el alcance de la esti­mación por PF. Ejem­plos: entre­na­mi­ento de usu­a­rios, acom­paña­mi­ento del sis­tema en pro­duc­ción, admi­nis­tra­ción de la base de datos, aten­di­mi­ento de dudas o recla­ma­ci­o­nes de usu­a­rios, acti­vi­da­des de soporte a la infra-estructura tec­no­ló­gica, etc.

 

Es posi­ble tam­bién rea­li­zar la esti­ma­ción para sola­mente acti­vi­da­des espe­cí­fi­cas del proyecto. Para esto, es nece­sa­rio cono­cer la dis­tri­bu­ción (%) de esfu­erzo que casa fase con­sume del proyecto todo. Cono­ci­endo esta rela­ción, se esti­ma el esfu­erzo total del proyecto y se apli­ca el porcentual de cada fase dese­ada para saber el esfu­erzo esti­mado de aquel­las actividades.

 

 

46. ¿Cuáles son las principales causas para errores en un cálculo de punto de función?

 

La mayo­ría de los erro­res encon­tra­dos en un cál­culo de pun­tos de fun­ción de un sis­tema es oca­si­o­nada por 4 factores:

  • Des­co­no­ci­mi­ento de la téc­nica: aun hay un gran número de pro­fe­si­o­na­les que son desig­na­dos para con­tar pun­tos de fun­ción de un sis­tema sin el cono­ci­mi­ento nece­sa­rio del pro­ceso del cál­culo. Qui­zás esto ocurra por haber una idea gene­ra­li­zada de que el APF sea muy sim­ples. Y en la rea­li­dad ella es, sin embargo esto no sig­ni­fica que sea des­ne­ce­sa­rio entre­na­mi­ento pro­fe­si­o­nal o un estu­dio más dedi­cado de la téc­nica.

     

    Con sola­mente un cono­ci­mi­ento super­fi­cial del APF es bien pro­ba­ble que el ana­lista cometa erro­res bási­cos. Sobre este aspecto, el IFPUG esta­blece su pro­grama de cer­ti­fi­ca­ción pro­fe­si­o­nal CFPS, que visa garan­tir que el pro­fe­si­o­nal cer­ti­fi­cado conoce todas las defi­ni­ci­o­nes y reglas de su Manual de Prac­ti­cas de Cál­culo en su ver­sión más recenté.

     

  • Dejar el cál­culo ser “con­ta­mi­nado” por la implan­ta­ción: el APF es una téc­nica para medir requi­si­tos fun­ci­o­na­les de un soft­ware. O sea, mide lo que el usu­a­rio soli­cita y recibe del soft­ware inde­pen­di­ente de cómo este fue imple­men­tado. Luego, el resul­tado de una cál­culo de pun­tos de fun­ción tiene que ser lo mismo, inde­pen­di­ente de la solu­ci­ona de imple­men­ta­ción (pro­ceso, arqui­tec­tura, her­ra­mi­en­tas, ambi­ente com­pu­ta­ci­o­nal) adop­tada por el desen­vol­ve­dor.

     

    Con­tar pun­tos de fun­ción de un sis­tema es un ejer­ci­cio de abs­trac­ción de pro­blema de nego­cio de usu­a­rio que el soft­ware debe aten­der, sin embargo ni siem­pre esto es una tarea fácil y mismo ana­lis­tas de pun­tos de fun­ción con expe­ri­en­cia pue­den des­viar el foco del cál­culo para la solu­ción de imple­men­ta­ción del desen­vol­ve­dor. Muchas veces el ana­lista es indu­cido en este camino por falta de docu­men­ta­ción adecuada.

     

  • Falta de cono­ci­mi­ento de nego­cio: de nada sirve ser espe­ci­a­lista en APF y no cono­cer el nego­cio del usu­a­rio. Para que el cál­culo de pun­tos de fun­ción sea hecho de forma cor­recta, o sea, de punto de vista de usu­a­rio, es nece­sa­rio que el ana­lista de pun­tos de fun­ción bus­que el enten­di­mi­ento de nego­cio pri­mero y sola­mente des­pués rea­lice el cál­culo de pun­tos de fun­ción.

     

    Muchas veces no hay tiempo dis­po­ni­ble para que el ana­lista de pun­tos de fun­ción bus­que este cono­ci­mi­ento. En este caso él ira actuar en con­junto con un ana­lista de nego­cio o con un usu­a­rio para poder rea­li­zar el cál­culo de pun­tos de función.

     

  • Cali­dad de los requi­si­tos dis­po­ni­bles: mucho se dice en la inge­ni­e­ría de soft­ware sobre la impor­tan­cia del levan­ta­mi­ento de requi­si­tos y del impacto que esto tiene en todo el proyecto cuando esta tarea no es bien eje­cu­tada. Para el cál­culo de pun­tos de fun­ción esto no es dife­rente. Si los docu­men­tos de donde el ana­lista de pun­tos de fun­ción extrae los requi­si­tos del usu­a­rio para rea­li­zar el cál­culo están ambi­guos, incom­ple­tos o mal escri­tos, cier­ta­mente el resul­tado del cál­culo será afectado.

Esta rela­ción de fac­to­res no están pre­sen­ta­das en nin­guna orden espe­ci­fica, pero es bas­tante repre­sen­ta­tiva de los prin­ci­pa­les fac­to­res que cau­san el cál­culo de pun­tos de fun­ción incorrectas.

47. ¿Cuáles los documentos son necesarios para el cálculo de punto de función?

 

No hay un docu­mento espe­cí­fico de uso obli­ga­to­rio para medir un soft­ware (o con­tar pun­tos de fun­ción). Cual­quier docu­mento donde sea posi­ble extraer infor­ma­ci­o­nes de los requi­si­tos del usu­a­rio puede ser uti­li­zado en un cál­culo de pun­tos de fun­ción. Sean ellos casos de uso, manu­a­les, pro­to­ti­pos, docu­men­tos de visión, modelo de imple­men­ta­ción de soft­ware.

 

Se puede imple­men­tar un soft­ware a tra­vés de dis­tin­tos méto­dos y her­ra­mi­en­tas para aná­li­sis, mode­lado y cons­truc­ción, para diver­sas pla­ta­for­mas com­pu­ta­ci­o­na­les; pero nada de eso afecta la medi­ción de lo mismo en pun­tos de función.

 

Es claro que deter­mi­na­dos tipos de docu­men­tos pue­den traer la infor­ma­ción para un cál­culo de pun­tos de fun­ción de manera más fácil. Otros docu­men­tos pue­den con­te­ner sola­mente parte de la infor­ma­ción nece­sa­ria para el cál­culo de PFs, siendo nece­sa­rio el aná­li­sis con­junta de más docu­men­tos para efec­tu­arse la medi­ción.

 

Así como tam­bién otros docu­men­tos, como tie­nen un carác­ter más téc­nico para el pro­ceso de desar­rollo de soft­ware, pue­den ser más tra­ba­jo­sos para extraer los requi­si­tos de usu­a­rio. El mejor docu­mento para uti­li­zarse un cál­culo de PFs es aquel que con­ti­ene los requi­si­tos del usu­a­rio expli­ci­ta­dos en la len­guaje de su nego­cio, y no en len­guaje de TI.

 

Cada orga­ni­za­ción tiene su pro­ceso de desar­rollo par­ti­cu­lar, pro­du­cir una can­ti­dad de docu­men­tos (o arte­fac­tos) dis­tin­tos en deter­mi­na­das fases del pro­ceso. Luego, el momento donde la medi­ción es hecha acaba deter­mi­nando tam­bién cua­les docu­men­tos esta­rán dis­po­ni­bles para efec­tu­arse el tra­bajo de medi­ción (o esti­ma­tiva) del tamaño fun­ci­o­nal del proyecto.

48. ¿Cuál la importancia de los requisitos de software para el APF?

 

Los requi­si­tos de soft­ware son fun­da­men­ta­les para el APF, pues el pro­ceso de medi­ción es basado exclu­si­va­mente en ellos. La entrada básica de medi­ción son los requi­si­tos de sis­tema. Con­vi­ene des­ta­car que el APF mide sola­mente una parte de los requi­si­tos de usu­a­rio para el sis­tema: los requi­si­tos fun­ci­o­na­les no son medi­dos por el APF.

 

Ade­más en un modelo de esti­ma­tiva de costo basado en PF (costo = tamaño x $/PF), ambos los tipos de requi­si­tos (fun­ci­o­na­les y no fun­ci­o­na­les) son con­si­de­ra­dos: el pri­mer irá

afec­tar el tamaño fun­ci­o­nal y el segundo afec­tara el costo uni­ta­rio ($/PF).

 

Debido a esta impor­tan­cia de los requi­si­tos para el APF, cuanto mejor la cali­dad de los requi­si­tos, el pro­ceso de medi­ción tor­nase más fácil, ágil y pre­ciso el resul­tado. Requi­si­tos de cali­dad malos afec­tan nega­ti­va­mente todo el proyecto de soft­ware, incluso la acti­vi­dad de medi­ción. Ade­más un efecto cola­te­ral bené­fico de pro­ceso de medi­ción es jus­ta­mente evi­den­ciar fal­las en os resul­ta­dos. Cuanto más tem­prano en el proyecto estas fal­las fue­ren iden­ti­fi­ca­das, más pequeño el costo de arre­glar­las y mayor la opor­tu­ni­dad de suceso de proyecto.

 

 

49. ¿Cómo puedo obtener una medición simple?

 

 

El objetivo de la medición son los requerimientos funcionales del usuario. Estos son derivados de artefactos disponibles desde antes de la implementación (o diseño) y después de ésta, como por ejemplo el software en operación plena.

 

Es común que artefactos de antes del diseño del software, que deberían describir la interacción del usuario con el software en términos del intercambio de datos y de la reglas de negocio relacionadas, describan como el software debe ser desarrollado.

 

Por ejemplo, desde el punto de vista del usuario, hay una única entrada de datos con el objetivo de actualizar una base de datos corporativa. Sin embargo, es necesario el desarrollo de dos programas de computador para eso. Es de esta manera, porque hay requerimientos de desempeño que no permiten que todo el procesamiento sea hecho de una vez; es necesario primero que se reciba y se confirme la validez de los datos para luego en la noche, cuando el volumen de transacción es menor, empezar el procesamiento de actualización efectiva en la base de datos corporativa.

 

El analista elabora dos casos de uso para describir la primera parte del procesamiento y otro caso de uso para describir la segunda.

 

El analista de puntos de función no debe solamente evaluar los casos de uso, debe evaluar si esos artefactos no fueron elaborados desde un punto de vista técnico.

 

Eso promueve la discusión en cuanto a la medición. No es que el método de medición que no sea simple. Es la correcta identificación de los requerimientos funcionales. Por eso, el método de puntos de función es también una herramienta para la verificación de la producción en la ingeniería de requerimientos.

 

El ejemplo provisto es uno con artefactos de antes de la implementación. Ahora presentamos otro diferente.

 

Cuando se evalúa el software o representaciones del software como su modelo de datos final, el proyecto de clases o el código, no se tiene una referencia en términos de la tareas y servicios del usuario. Es posible que una tarea única sea descompuesta en varios pasos implementados en transacciones diferentes.

 

Entonces cuando se hace la medición basada en estos insumos, es necesaria la información complementaria sobre el motivo para esa recomposición más allá que aquella asociada al nivel de una tarea del usuario. Esto también genera divergencias cuando se mide el software con puntos de función.

 

Observe que no es un problema inherente al método de medición y si a la representación adecuada del software para la medición.

 

Hay muchos profesionales que creen que saben el método del IFPUG. Sin embargo, lo que desean es una correspondencia perfecta entre las construcciones del proyecto e implementación con los componentes funcionales básicos del Análisis de Puntos de Función (EE, SE, CE, ALI, AIE). Eso no existe.

 

Uno de los puntos positivos al usar el Análisis de Puntos de Función PF es exactamente disminuir la brecha entre la visión de negocio, el proceso de negocio desde el punto de vista de sus tareas y servicios y la visión de TI con los términos y decisiones técnicas. La dificultad, por lo tanto, no está en la medición sino en disminuir la distancia entre estos dos mundos.

 

 

 

.

 

.