XIV Congreso Internacional de la Academia de Ciencias Administrativas A. C. (ACACIA)

Modelo de predicción de Puntos de Función de IFPUG a partir de Puntos de relato de Agile

Mesa: 11. Ingeniería y Gestión de Sistemas

Autor: M.A.(O) Ricardo Chávez Arellano Coautores: Dr. Juan José Cuadrado Gallego y Dr. Daniel Pineda Domínguez ESCA Santo Tomás – IPN Doctorado en Ciencias Administrativas

El Sabinal #50, Col. Lomas del Parque, Tultitlán, Edo. De México C.P. 54958, Tel. Oficina (55) 5270-4456, Tel. Casa (55) 5884-5924, email: [email protected], [email protected]

Monterrey N.L. del 27 al 30 de Abril de 2010

I. INTRODUCCIÓN La industria del software es uno de los pilares de la economía mundial, pues sus productos y servicios son fundamentales para el funcionamiento de la sociedad y las organizaciones en nuestro tiempo, con un grado de dependencia notable en su correcto funcionamiento. Es común que las organizaciones decidan invertir en sistemas de información para administrar automáticamente su información, la cual comúnmente se produce a través de un conjunto de actividades identificado como un proyecto de desarrollo de sistemas.

Esta investigación se enmarca en la industria del software y en particular aborda el tema de la cuantificación de la funcionalidad de desarrollos de software bajo el nuevo paradigma conocido como Agile, que forma parte de las tareas de la administración de proyectos de desarrollo de software.

El objetivo general de este trabajo es desarrollar una metodología de conversión entre los métodos de medición de funcionalidad de software de Puntos de Función (IFPUG) y Puntos de Relato (Agile), que eficientice los proyectos de desarrollo de software, analizando proyectos con ambas metodologías y obteniendo el análisis de las diferencias.

La aportación de este trabajo es ser el pionero en la investigación de un modelo matemático de conversión entre la metodología de Puntos de Función de IFPUG y de Puntos de Relato de Agile. Es por esta razón que el valor metodológico de esta investigación es ser considerada como la primera para obtener un modelo matemático de conversión entre dichas metodologías.

Esta investigación proporciona evidencia de que los proyectos de desarrollo de software realizados bajo el paradigma conocido como Agile, pueden ser más eficientes, cuando utilizan un modelo matemático de conversión entre Puntos de

Relato y Puntos de Función de IFPUG para la cuantificación de la funcionalidad del software.

La necesidad de esta investigación surge de la inexistencia de una metodología de conversión entre los métodos de medición de funcionalidad de software de Puntos de Función (IFPUG) y Puntos de Relato (Agile), lo cual impide a los proyectos de desarrollo de software ser más eficientes.

Este trabajo tuvo como referencia a los proyectos desarrollados en el marco conceptual de Agile dentro de una organización de Servicios de Tecnologías de Información que utilizan la metodología de Puntos de Función como su forma de medir el tamaño de la funcionalidad desde hace de más de 30 años y Puntos de Relato como una forma de estimar el tamaño de los requerimientos de usuario.

Orígenes de la Industria del Software La industria del software, como en muchos otras industrias destaca diferencias significativas entre los países desarrollados y aquellos en vías de desarrollo así como en el tamaño siendo las empresas multinacionales las que mayor participación en el mercado. La industria del software se encuentra en el marco de las Tecnologías de Información y Comunicaciones (TICs por sus siglas en inglés) estas últimas reflejan las condiciones de la economía de los países y más específicamente con el PIB per capita, teniendo este último concepto una intima relación con la productividad y competitividad de un país (Zermeño R. y S. Espinosa, 2005).

El origen de esta industria está ligado con las primeras computadoras, siendo el primer antecesor una máquina electrónica digital con válvulas de vacío (conocidos como bulbos) llamada Computadora e Integradora Numérica Electrónica (Electronical Numerical Integrator and Computer o ENIAC por sus

siglas en inglés), en 1945. Con esto se dio origen a la primera generación de computadoras (de Pablos, C. et al, 2004).

El surgimiento de la producción de software como actividad independiente, tuvo lugar con la aparición de las primeras computadoras comerciales, siendo en 1955 cuando surgió la primera empresa de software independiente, la Computer Usage Company (CUC), dando paso al boom en las empresas productoras de software. En la década de los setenta surgió la primera empresa que desarrolló y comercializó por cuenta propia un producto de software, la compañía ADR. Al mismo tiempo surgieron lenguajes de programación especializados (Fortran y COBOL), reemplazando al lenguaje ensamblador, lo que ayudó a reducir costos de desarrollo. Esto provocó el surgimiento de empresas desarrolladoras de soluciones. La industria del software independiente se desarrolló en Estados Unidos, gracias a que la empresa IBM introdujo la separación del cobro del software (Mochi, 2006).

Los últimos años ha visto un boom en la red Internet, lo que ha favoreció no sólo a la industria del software sino a la de telecomunicaciones y electrónica.

La industria del software en México La industria del software en México hacia finales de los años setenta y principios de los ochenta era escasa, pero para 1983 se inició la difusión de la computadora personal en nuestro país. Siendo una de las principales la compañía Printaform. La compañía Aspel surgió en 1981 y se dedicó principalmente a la comercialización de software para sistemas administrativos, por otra parte en 1982 llegó la hoja de cálculo Lotus 1-2-3. Otras compañías mexicanas que surgieron en la década de los ochenta fueron Siga Desarrollos y Digit. En 1986 Microsoft se establece en México, quien introdujo el concepto de pago de licencias por instalación en cada máquina, haciendo énfasis en que no sólo vendía el sistema operativo, sino también Excel, Word y PowerPoint. Por

otra parte la compañía Oracle llegó a México en 1987, siendo su cliente principal PEMEX (Ibid, p. 77).

La industria del software en el mundo en la actualidad La industria del software es liderada por compañías de países desarrollados, principalmente las de Estados Unidos. Asumiendo un papel importante en esta industria algunas naciones semidesarrollados o semiindustrializados como India, Israel e Irlanda, seguidas de otras como Taiwán, China, Corea, Tailandia, Malasia, Filipinas y Vietnam. En Latinoamérica los más países más relevantes son Brasil y Argentina, siendo estos dos últimos competidores directos de México (Ibid, p. 81).

En particular, las diez primeras empresas de software en el mundo, de acuerdo a su volumen de ingresos son Microsoft, Oracle, SAP, Symantec/Veritas, Computer Associates, Electronic Arts, Adobe Systems, Amdocs, Intuit y Autodesk (OCDE, 2008). Tecnologías de Información y Comunicaciones en México No se conoce con exactitud el número de empresas desarrolladoras de software EN México, al no existir un censo exhaustivo. Más sin embargo en una muestra desarrollada por AMITI, compuesta por 206 empresas, indica que el perfil de esta industria, se trata básicamente de micros y pequeñas empresas, con un tamaño inferior al internacional que es de 250 empleados (González, 2006). Mientras que las empresas grandes representan un 5% y los grandes corporativos representan sólo el 0.5% de las empresas de este giro.

En la actualidad varias empresas mexicanas participan en la industria del software, siendo las más representativas Softek (quien adquirió a Ddemesis en 2003) y Praxis.

México participa muy poco el la subcontratación internacional de software, pues de acuerdo con un estudio realizado por The Offshore Development Group, sólo el 4% de sus clientes potenciales consideraba a México como una alternativa viable para realizar esta actividad (Mochi, 2006).

II. ADMINISTRACIÓN DEL PROCESO DE DESARROLLO DE SOFTWARE. Las organizaciones que desarrollan software, administran el proceso el desarrollo de software en el marco de una estructura organizacional definida por proyectos.

De acuerdo con el PMBOK proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único (PMI, 2004).

La Administración de proyectos es la aplicación del conocimiento, herramientas y técnicas a actividades para cumplir los requerimientos de un proyecto. La Administración de proyectos es llevada a cabo a través de la aplicación e integración de procesos de inicio, planeación, ejecución, monitoreo y control de Administración de proyectos (PMI, 2004).

De alguna manera la administración de proyectos ha existido por miles de años, como probablemente fue usada en la construcción de las maravillas modernas del mundo antiguo. Aunque la administración de proyectos modera fue alrededor de inicios del siglo XX (Brandon, 2005).

El gerente de proyectos o la organización puede dividir los proyectos en fases para proporcionar un mejor control de la administración, estas fases en su conjunto son conocidas como ciclo de vida de proyecto. Muchas organizaciones identifican un conjunto de ciclos de vida para usarse en todos sus proyectos. El ciclo de vida define las fases que conectan el inicio de un proyecto con su final (PMI, 2004).

Los gerentes de proyectos se encuentran inmersos en lo que se conoce como “Sistema de Administración de proyectos”, el cual es un conjunto de herramientas, técnicas, metodologías, recursos y procedimientos usados para administrar un proyecto (Ibid, 2004). Dos de esas metodologías son Puntos de Función y Agile.

Tamaño en Puntos de Función (IFPUG) La mayoría de las empresas cuentan con una vaga idea de la funcionalidad en el software con el que cuentan y mucho menos cuánto de esa funcionalidad realmente se aprovecha. Tampoco cuentan con la productividad de sus programadores en términos de cuanta funcionalidad pueden desarrollar por unidad de tiempo. Eso les impide estimar, con fundamento, la inversión y el tiempo necesario para que su personal pueda desarrollar un proyecto de software o para evaluar la propuesta de personal a subcontratar.

En

consecuencia los retrasos en los proyectos así como los excesos en presupuesto son normales (Duran, 2003). El análisis de Puntos de Función (Function Points)1 es un conjunto de métodos que permiten cuantificar la funcionalidad del desarrollo de software desde el punto de vista del usuario, basándose principalmente en el diseño lógico. Dicha metodología es promovida por el Grupo Internacional de Usuarios de Puntos de Función (International Function Points User’s Group – IFPUG por sus siglas en inglés).

1

“Este documento contiene material que ha sido extraído del manual de prácticas de conteo del

IFPUG. Éste es reproducido, con el consentimiento del IFPUG” / "This document contains material that has been extracted from the IFPUG Counting Practices Manual. It is reproduced in this document with permission of IFPUG."

Los objetivos de esta metodología son medir la funcionalidad que el usuario solicita y recibe y por otra parte medir el desarrollo y el mantenimiento del software, independientemente de la tecnología utilizada para su implantación (IFPUG, 2005).

El manual de prácticas de conteo de Puntos de Función de IFPUG ha sido transformado en un estándar de la Organización de Estándares Internacionales (Internacional Standard Organization – ISO), se trata del estándar número ISO 14143-1 para la medición del tamaño funcional (Ibid, p. viii)2.

Los siguientes son los pasos de los que consta la metodología de Puntos de Función:

1. Determinar el tipo de trabajo. 2. Identificar el alcance y la frontera de la aplicación. 3. Contar las funciones de datos para determinar su contribución al conteo de Puntos de 4. Contar las funciones transaccionales para determinar su contribución al conteo de Puntos de Función sin ajustar. 5. Determinar el valor del factor de ajuste. 6. Calcular el conteo de Puntos de Función ajustados.

Por si sola la metodología de Puntos de Función permite conocer sólo el tamaño del software, pero sus usos son amplios3.

2

Con la exclusión de las 14 Características Generales del Sistema, las cuales no forman parte

del estándar de ISO, pues estas son consideradas requerimientos técnicos. 3

Para conocer más acerca de los usos, detalles de los pasos y formas de estimar Puntos de

Función consulte: Chávez, R. (2009). “Puntos de Función (Function Points): Entendiendo la metodología y sus aplicaciones en el desarrollo de sistemas”, Memorias del XII Congreso de ACACIA, Ciudad de México.

Puntos de relato (Story Points) Agile es un nuevo paradigma de desarrollo de software, en el cual la cuantificación de sus requerimientos (llamados Relatos de usuario o User Stories), se hace en términos de Puntos de relato (Story Points), estos últimos representan el tamaño relativo de cada relato. El número de Puntos de relato es comúnmente cuantificado por los mismos miembros del equipo de desarrollo para conocer la velocidad de entrega y realizar la planeación del desarrollo en etapas llamadas iteraciones o sprints.

En los desarrollos Agile, es el equipo, no el gerente del proyecto, quien realiza las estimaciones. El cual representa un cambio radical en relación a otras técnicas de administración de proyectos, donde el gerente de proyecto comúnmente estima o influye en el esfuerzo y dirige a los miembros para cumplir con las fechas calendarizadas.

El uso del método de medición de Story Points está restringido a aquellos proyectos de desarrollo que usan la metodología Agile, no pudiendo ser usados en metodologías de desarrollo tradicionales.

La metodología de Story Points adolece de reconocimiento como estándar de la industria, pero que en algunas organizaciones que realizan sus estimaciones con una misma escala, cobra relevancia como precedente.

Tal vez la mejor forma de estimar el tamaño de los relatos de usuario se a través de la técnica conocida como Póquer de planeación (Planning pocker), pues combina tres métodos de estimación en uno (Analogía, opinión de experto y por desglose).

Los participantes en la actividad de Póquer de planeación (Planning pocker), son los miembros del equipo de desarrollo de software (desarrolladores, analistas, diseñadores, etc.). Es deseable que el equipo sea de no más de diez personas,

de otra manera es mejor separar al equipo en dos grupos si el equipo es muy grande. Aquí están los pasos a seguir: 1. Establecer la escala de medición, por ejemplo 0, 1, 2, 3, 5, 8, 13, 20, 40 y 100, y dar a cada participante una serie de tarjetas al inicio de la sesión. 2. El moderador (usualmente el Dueño de producto o un analista), lee la descripción del requerimiento, el cual está descrito en forma de Relatos de usuario. 3. Todas las preguntas que el equipo tenga son contestadas. 4. Una vez hecho lo anterior todos los participantes al mismo tiempo voltean sus tarjetas, para que todos los participantes puedan ver el número de Puntos de relato estimados. Si los estimados difieren mucho, las personas que estimaron los valores más bajo y alto proporcionan una explicación de su razonamiento para haber valorado de esa manera. 5. Dichos los puntos de vista, se realice una segunda ronda o hasta una tercera ronda para obtener un solo estimado.

Una de las ideas detrás de este método es tratar de llegar a estimar el tamaño de una manera económica, al no utilizar grandes recursos y obtener un grado de certeza aceptable.

III. ACERCA DEL MODELO, TRABAJO DE CAMPO Y RESULTADOS. En la sección I se describió los objetivos, beneficios y pasos de la metodología de Puntos de Función. En la sección II se mencionó que la metodología Agile, se está constituyendo en un nuevo paradigma para el desarrollo de proyectos de software. En ese marco de referencia los gerentes de proyectos tienen la responsabilidad de manipular sus recursos, con la finalidad de alcanzar el éxito de su proyecto, lo que equivale a acertar en el alcance, costo (presupuesto) y tiempo (calendario). A estos tres últimos se les conoce como la “triple restricción” y para estimarlos se puede utilizar una serie de herramientas y métodos para disminuir la incertidumbre.

En un extremo existen empresas que no realizan estimaciones del tamaño de la funcionalidad, lo que incrementa el peligro de fallar en las cotizaciones de desarrollo de software.

En el caso particular del análisis de Puntos de Función (IFPUG), se tiene como limitantes su alto costo, su relativa baja velocidad y el amplio margen de error entre analistas de Puntos de Función no certificados o con poca experiencia en dicha metodología.

De acuerdo con Capers Jones (2008), el costo promedio de un analista de Puntos de Función certificado es de aproximadamente 2,500 dólares americanos por día, pudiendo contar alrededor de hasta 400 Puntos de Función diariamente, lo que da un costo de aprox. 6.25 dólares americanos por Punto de Función.

En el estado del arte revisado, no existe hasta el momento un método de conversión confiable que permita pasar de Puntos de Función a Story Points y viceversa, lo único que existe es una hipótesis planteada, pero no verificada enunciada por Capers Jones (2007) “De examinar algunos relatos (stories) y observando los Puntos de Relato (Story Points), se puede hipotetizar que un Story Point es más o menos equivalente a dos Puntos de Función. Una iteración (sprint) completo es más o menos equivalente a cerca de 20 Puntos de Función”.

Dado que existe la necesidad de equipos de desarrollo Agile para conocer ambas unidades y, por lo tanto, invertir recursos en su obtención, lo cual aumenta el número de horas de proyecto de Agile, lo que representa una tarea que va en contra de su filosofía.

De tal manera que el problema es que no existe un modelo matemático de conversión entre los métodos de cuantificación de la funcionalidad de software de Puntos de Función, promovido por IFPUG y de Puntos de Relato de Agile.

El trabajo de campo se realizó en una empresa multinacional de Tecnologías de Información, la cual ha migrado gran cantidad de sus proyectos desarrollados bajo

metodología tradicional de cascada al nuevo paradigma de desarrollo

Agile.

Los datos usados en el análisis cuantitativo provienen de proyectos de desarrollo de software de la compañía bajo estudio, medidos usando la versión 4.2.1 del método IFPUG de Puntos de Función. Dichas mediciones fueron realizados por analistas expertos y certificados por IFPUG, en el caso de Agile fueron realizados por los propios equipos de desarrollo de Software quienes han sido entrenados en la metodología de Puntos de Relato asegurando la correcta aplicación de ambos métodos. Además de datos secundarios provenientes de bases de datos internas de la compañía bajo estudio.

Todas las mediciones han sido realizadas usando los documentos de especificación de requerimientos, ya sea en forma de manuales de usuario, de diseño interno o externo, o bien con la descripción de relatos de usuario.

Los conteos de Puntos de Función se han tomado sin valor de factor de ajuste, para dar cumplimiento con el estándar de la Organización de Estándares Internacionales (Internacional Standard Organization – ISO) número ISO 141431 para la medición del tamaño funcional.

De la muestra de treinta tres proyectos, fueron descartados algunos de acuerdo a los siguientes criterios: a) Cuando no se pudo obtener el número de Puntos de Relato. b) Cuando los conteos de Puntos de Función fueron realizados por analistas no certificados c) Cuando los conteos de Puntos de Función no fueron revisados por un colega (otro analista de Puntos de Función certificado) d) Cuando los conteos de Puntos de Función no eran detallados, sino aproximados o estimados.

De tal forma que los datos utilizados provienen de veinte proyectos y cuyos resultados se presentan en la tabla 1. La primer columna es el número consecutivo del número de proyecto, la segunda columna es el número de Puntos de relato (la cual es la variable dependiente, x) y la tercer columna es el número de Puntos de Función sin ajustar (variable independiente, y).

Número de proyecto 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Puntos de relato (x) 234 55 341 94 411 233 225 72 121 191 112 298 1186 349 276 1770 567 433 40 205

Puntos de función (y) 281 226 185 122 199 258 108 130 304 137 233 499 850 93 198 612 305 252 66 120

Tabla 1: resultados de las mediciones de Puntos de Función y Puntos de relato

Se utilizó el análisis de regresión lineal para encontrar relaciones entra las mediciones de ambas metodologías de medición de funcionalidad de software. El análisis de regresión permite estimar o predecir valores no conocidos de una variable a partir de valores conocidos de otra. Si dos variables están correlacionadas, esto quiere decir que existe una asociación o relación entre ambas, y un diagrama de puntos se puede ajustar a una curva, a la cual se llama curva de regresión y a la ecuación matemática de la curva de regresión se le conoce como ecuación de regresión, es así que si se estudian dos variables, siempre se tendrán dos líneas de regresión (Goyal, 2007).

En el diagrama de puntos de la figura 1, visualiza los pares de observaciones de los proyectos. La línea trazada, representa la línea recta que mejor se ajusta al modelo de regresión. Estimación de Puntos de Función (IFPUG) a partir de Puntos de Relato (Agile) 900 800

y = 0.3592x + 129.37

700

R = 0.6019

Puntos de función

2

600 500 400 300 200 100 0 0

200

400

600

800

1000

1200

1400

1600

1800

Puntos de relato

Figura 1: diagrama de dispersión y línea recta de mejor ajuste

Un modelo de regresión simple se representa de la siguiente manera: y = 0 + 1x

El análisis estadístico dio los siguientes resultados: Mínimo de Puntos de Función = 66 Máximo de Puntos de Función = 850 Media aritmética = 258.90 Puntos de Función. Coeficiente de correlación de Pearson = 0.775796465 R2 o coeficiente de determinación = 0.601860156 Pendiente (1) = 0.359159958 Interceptor u ordenada al origen (0) = 129.3689611

2000

A partir de los datos anteriores, el modelo de conversión propuesto entre Puntos de relato y Puntos de Función (IFPUG) es el siguiente: y = 129.37 + 0.3592x

El coeficiente de correlación de Pearson indica que existe una relación fuerte entre las dos variables (0.775796465) y el valor del coeficiente de determinación (0.601860156), implica que aproximadamente el 60% de los casos puede explicarse a través del modelo.

La prueba de significancia de la regresión se realizó a través del análisis de varianza del modelo. Para ello se planteó la hipótesis H: 1 0 y H0: 1 = 0. La hipótesis nula se puede interpretar así: dado que 1 es la pendiente y como ésta mide el grado de relación entre la variable dependiente e independiente, entonces si 1 = 0, entonces los datos de la suma de cuadrados de la regresión y de los residuales son independientes y por lo tanto no existe relación entre la variable “x” (Puntos de relato) y la variable “y” (Puntos de Función).

Para esta prueba se utilizó la distribución F de Snedecor y en esta prueba, el valor observado F0 debe ser grande si 1 0. Para un nivel de significancia de 95% (= 5%) el valor tabular de F0.05,1,18 es 4.41 y el estadístico F0 (llamada F de Snedecor) de la prueba es: Fuente de la variación Regresión Residual Total

Suma de cuadrados 426,085.57 78,178.14 504,263.71

Grados de Error cuadratico libertad medio 1.00 426,085.57 18.00 78,178.14 19.00

F0 5.45018826

Como el valor de F0 =5.45018826 y F0.05,1,18 es 4.41, entonces la hipótesis nula se rechaza y por lo tanto para un nivel de significancia de 95% existe relación entre ambas variables.

Adicionalmente al modelo de predicción, se realizó un análisis de eficiencia de administración de estos proyectos se observa en la tabla 2. La columna “Horas de análisis de FPs” corresponde al número total de horas dedicadas por los analistas de Puntos de Función en el respectivo proyecto. La columna “Costo análisis de FPs (MXN)” representa el costo asociado al análisis de Puntos de Función en moneda nacional. La siguiente columna llamada “% en relación a hrs de des.” indica el porcentaje que representa el número de horas del análisis de Puntos de Función en relación al número total de horas de desarrollo del proyecto. Núm de Horas análisis Costo análisis % en relación a Proyecto de FPs de FPs (MXN) hrs de des. 1 46 $ 15,571.92 2.09 2 27 $ 8,608.14 5.40 3 32.5 $ 16,128.13 0.36 4 47 $ 23,153.72 1.47 5 77.5 $ 19,062.02 0.40 6 31 $ 10,710.81 0.34 7 13 $ 4,491.63 0.16 8 24 $ 8,292.24 0.11 9 21 $ 7,255.71 0.08 10 19.5 $ 6,368.21 0.33 11 39.5 $ 14,339.94 0.18 12 21 $ 7,255.71 1.04 13 36.5 $ 11,812.82 0.54 14 28.5 $ 9,464.97 0.31 15 37.5 $ 11,734.08 0.55 16 30 $ 7,509.75 0.12 17 25 $ 8,637.75 0.42 18 12.5 $ 4,318.88 1.40 19 10 $ 3,455.10 0.17 20 18.5 $ 6,391.94 0.64 Promedio 29.875 $ 10,228.17 0.81

Tabla 2: resultados de horas, costo y porcentaje del tiempo de desarrollo

El número de horas mínimo de análisis de Puntos de Función fue 10 horas y el máximo fue 77.5 horas, mientras que el promedio fue 29.875 horas.

El costo mínimo de un análisis de Puntos de Función fue $3,455.10 pesos, el máximo fue $23,153.72 y el promedio $10,228.17 pesos.

El costo total de todos los análisis de Puntos de Función fue $204,563.44 pesos.

En promedio 0.81% del tiempo de desarrollo equivale al tiempo dedicado al análisis de Puntos de Función. Es decir que por cada 1000 horas de desarrollo 8.1 horas se dedicaran a realizar un análisis de Puntos de Función.

Lo anterior quiere decir que proyectos con características similares ahorrarían en promedio 29.875 horas por concepto de análisis de Puntos de Función, equivalente a un costo promedio de $10,228.17 pesos.

IV. Consideraciones finales. Puntos de Función es una de las medidas de software más usadas, siendo sus orígenes en los años setenta, y es una de las más ampliamente aceptadas en todo el mundo. Esta metodología ha evolucionado y ha sido promovida por el Grupo Internacional de Usuarios de Puntos de Función (IFPUG – Internacional Function Points User’s Group). Dicha asociación de métricas de software es la más antigua de su genero y está representada por alrededor de 3000 miembros y 25 países. Lo que demuestra su amplio uso y alcance alrededor del mundo.

El uso del método de medición de Story Points está restringido a aquellos proyectos de desarrollo que usan la metodología Agile, no pudiendo ser usados

en metodologías de desarrollo tradicionales. Mientras que el método de Use case Points está restringido a aquellos proyectos que documentan sus requerimientos en forma de casos de uso, mientras que la metodología de Puntos de Función puede ser usada en los mismos campos de aplicación de Story Points y de Use case Points.

La medición del tamaño de la funcionalidad de los desarrollos de software por si sola no garantiza el éxito de ningún proyecto, pero utilizándola en conjunción con otras medidas, en un marco de métricas de proyecto, ayuda a reducir la incertidumbre utilizando métodos y herramientas de uso generalmente aceptados.

En la medida que los gerentes o responsables de un proyecto de desarrollo de sistemas lo utilicen cada vez más, se darán cuenta de lo útil y benéfico que es para ellos y su organización.

Los métodos de Puntos de Función (IFPUG) y Puntos de Relato para obtener el tamaño de la funcionalidad están formulados en lenguaje natural y por su naturaleza está sujeto a ambigüedades y a una interpretación subjetiva, estos inconvenientes tratan de minimizarse con reglas y estándares bien definidos para que las mediciones hechas por diferentes personas sean lo más parecidas posibles.

Aún cuando la mayoría de las mediciones fueron revisadas por un colega, no es posible afirmar que las medidas realizadas estén libres de errores.

La aplicación del modelo matemático propuesto de predicción, permitirá a los proyectos de desarrollo de software realizados bajo la metodología Agile, estimar el número de Puntos de Función a partir del número de Puntos de relato, reduciendo considerablemente los costos asociados al análisis de Puntos de Función y para aquellos que era impensable realizarlos por su alto costo, les

permitirá obtener valores del tamaño de Puntos de Función y usarlos de acuerdo a lo establecido en la sección III (usos de Puntos de Función).

La presente investigación pretende brindar tres tipos de aportaciones: metodológica, teórica y económica.

La aportación teórica hacia el área de Administración de proyectos de software, la cual sería provista de una herramienta, es decir el modelo matemático resultado de esta investigación, que ayudaría a reducir la incertidumbre en la estimación del tamaño de la funcionalidad en términos de la metodología de Puntos de Función (IFPUG) para proyectos realizados bajo el enfoque de Agile.

La metodología Agile requiere procesos ágiles, incluyendo por supuesto las estimaciones de software, el modelo resultante de la investigación, podría incorporarse a las prácticas de dicha metodología.

Desde el punto de vista económico, el proceso de estimación del tamaño de software realizado por el especialista de Puntos de Función, es una actividad en el que se reducirán los costos al realizarse de manera prácticamente automática a través del modelo propuesto, reduciendo costos incurridos y por lo tanto mejorando la eficiencia del proyecto de desarrollo, pues el costo del análisis de Puntos de Función por un analista certificado es de un promedio de 2,500 Dólares americanos por día (Jones, 2008).

Finalmente en cuanto a la aportación metodológicas, esta investigación es la primera en su tipo, pues no existen referentes de investigaciones anteriores que busquen modelo matemático de conversión entre las metodologías de Puntos de Función (IFPUG) y de Puntos de Relato (Agile), lo cual sentará un referente metodológico para futuras investigaciones que aborden este tema.

La presente investigación se encuentra en la etapa de análisis estadístico e interpretación de resultados, se tiene un modelo de regresión lineal y se estudiará la posibilidad de incorporar más variables al modelo para hacer uso de la regresión múltiple, sin descartar modelo que no sean lineales, los cuales podrían incluir modelos polinomiales o exponenciales. Los primeros resultados e interpretaciones se han dado y parecen ser prometedores.

Bibliografía Brandon, D. (2005). “Project management for modern information systems”. Idea Group Inc (IGI). Chávez, R. (2009). “Puntos de Función (Function Points): Entendiendo la metodología y sus aplicaciones en el desarrollo de sistemas”, Memorias del XII Congreso de ACACIA, México, D.F.

de Pablos, C., López-Hermoso J.J., Martín-Romo S. y S. Medina. (2004). "Informática y comunicaciones en la empresa". Editorial ESIC, Universidad Rey Juan Carlos, Madrid, España. Duran, S. E. (2003). “Puntos por función. Una métrica estándar para establecer el tamaño del software”. Boletín de política informática, Año XXVI, Número: 6. INEGI. González, D. (2006). “Estudio Exploratorio de la Relación entre Orientación Estratégica de Negocio y los Factores Críticos de Éxito de la Industria del Software”. Caso de Aplicación México. Universidad Politécnica de Valencia. International Function Point User’s Group. (2005). “Function Points Counting Practices Manual V. 4.2.1”, Princeton Junction, New Jersey.

Goyal, M. (2007). “Computer−Based Numerical & Statistical Techniques”. Laxmi Publications Pvt. Ltd. Jones, C. (2008). “Applied software measurement: global analysis of productivity and quality”, Edición: 3. McGraw-Hill.

Mochi Alemán, Prudencio Oscar. (2006). La industria del Software en México en el contexto internacional y latinoamericano. Centro Regional de Investigaciones Multidisciplinarias, UNAM. Cuernavaca, Morelos. OCDE. (2008), “Top 10 software firms”, Consultado el 18 de septiembre de 2009,

página de la Organización para la Cooperación y el Desarrollo

Económico: http://statlinks.oecdcode.org/932008041P1T009.XLS Project Management Institute. (2004). “A Guide to the Project Management Body of Knowledge, (PMBOK Guide)”. Tercera edición, Pennsylvania, ESTADOS UNIDOS.

Zermeño, R.

y S. Espinosa. (2005), “Evidencias del valor de TI para las

organizaciones mexicanas”. Select. Consultado el 13 de septiembre de 2009, página

de

la

enITma

http://www.cysp.com.mx/Ima/Amiti/Textoinfo/Evidencias_valor_TI.pdf

Consulting: