Puntos de Función como herramienta para la Valoración de Software Guilherme Simões, Curtis Graham y Carlos Vazquez Fatto Consultoría y Sistemas (www.fattocs.com) [email protected], [email protected] Atribuir un valor monetario a una aplicación de software puede ser un proceso complejo. A continuación, se describen algunas razones para hacerlo: • Gestión de activos de TI: o Contabilizar el software como parte de los activos de la organización. o Vender la aplicación a otra empresa. o Confirmar la valoración hecha por un tercero. o Identificar cuáles componentes del software son los más valiosos. • Apoyo en la toma de decisiones de Proyectos de TI: o Analizar si vale la pena desarrollar un software o si es mejor comprarlo. o Ayudar en la evaluación y toma de decisiones con respecto a costo y plazo. o Gestionar de manera eficiente los riesgos. El problema surge cuando una empresa desea valorar su software en términos monetarios, pero no tiene forma de calcular este valor objetivamente. Análisis de Puntos de Función, proporciona la base para calcular lógicamente la primera variable en la valoración del software: El costo relacionado con su desarrollo. INTRODUCCIÓN Análisis de Puntos de Función es un método para medir la visión lógica del software, ya que cuantifica el tamaño funcional determinado por sus requisitos funcionales. El método fue desarrollado en IBM en la década de 1970 y ha sido estandarizado, mantenido y mejorado en la actualidad por el IFPUG (International Function Point Users Group.

MÉTODO DE VALORACIÓN DE SOFTWARE Cuando se valoriza una aplicación de software, es importante considerar que el valor monetario se expresa como un rango, usando el costo para su desarrollo como el ‘piso’ (valor mínimo) y los resultados, los problemas resueltos y oportunidades como el techo' (valor máximo). El esfuerzo y el costo son variables directamente relacionadas con el tamaño funcional. Hay varios modelos de estimación que utilizan el tamaño funcional como insumo para estimar el esfuerzo o el costo. Para este artículo, vamos a ofrecer una más simple: Costo = Funcional Tamaño x Velocidad de entrega x Persona - Valor hora. El valor del software es algo percibido de manera distinta por cada entidad. Por tanto, podemos decir de cierta manera que este valor es subjetivo. Por ejemplo, un vaso de agua para quien está en un desierto sin beber agua hace varias horas vale mucho más que para una persona que está nadando en un río de agua cristalina. Una organización que consigue agilizar un proceso operacional en un 50% con el uso de un determinado software, tiene una percepción de mayor valor de éste que otra que irá a disfrutar de una ganancia de agilidad de tan sólo un 5%. El valor agregado ofrecido al negocio (techo) incluye componentes como procesos operacionales (flujo que relaciona diferentes funciones de negocio), niveles de calidad (número de defectos), niveles de rendimiento y tiempo para posicionamiento de mercado. Teniendo en cuenta esta cuestión de la percepción subjetiva del valor, aquí se considerará solamente el piso de la valoración (valor mínimo) basada en su tamaño funcional. Otras variables que se pueden calcular son los

  niveles de calidad y duración. Estas dos variables se consideran bajo la discreción del cliente en cuanto a la atribución de valor monetario a la aplicación.

incertidumbre por COCOMO II como por la Evaluación de Proyectos y Técnica de Revisión – PERT (Project Evaluation and Review Technique).

TASAS DE ENTREGA Y BENCHMARKING PARA DESARROLLO DE PROYECTOS DE SOFTWARE

COCOMO II es un modelo de estimación que permite la estimación de costo, esfuerzo y planeación [4]. Además, COCOMO II se complementa con el cono de incertidumbre que a lo largo del ciclo de vida del proyecto, describe como el grado de incertidumbre disminuye a medida que pasa el tiempo. Un ejemplo de esto, puede ser la incertidumbre de que nuevos requisitos puedan aparecer de repente, lo que se conoce como “Scope Creep”.

Una vez que el tamaño funcional de la aplicación es determinado a partir de sus requisitos [1] [2], es necesario determinar la tasa de entrega para desarrollar una aplicación como ésta (del mismo tamaño funcional) a partir de cero. El mejor método para esto es calcular la tasa de entrega utilizando datos históricos de proyectos anteriores. Sin embargo, a veces no hay datos suficientes. Una alternativa, no tan buena como la primera, es utilizar una fuente de referencia para encontrar una tasa de entrega. Hay varias fuentes de referencia para datos de proyectos de software: Gartner Group, ISBSG y libros de Capers Jones, son algunos de ellos. Por ejemplo, podemos extraer una tasa de entrega del International Software Benchmarking Standards Group (ISBSG) conjunto de datos R11 [3] utilizando los siguientes campos como parámetros para un proyecto dado: a. Calidad de datos: Datos con calidad insuficiente fueron excluidos. b. Tipo de Medición Usado: IFPUG, NESMA. c. Tamaño Funcional: No nulo. d. Nivel de Esfuerzo: No nulo. e. Año del Proyecto: Después de 2002. f. Tipo de Desarrollo: Nueva desarrollo. g. Lenguaje de Programación Primario: JAVA Usando el porcentaje de frecuencia de la información de referencia, la tasa de ejecución calculada fue de 14 Persona- Horas por Punto de Función (PH / FP) con un factor de confianza del 80% de que este número no es subestimado. La tasa de entrega junto con el tamaño funcional permitiría teóricamente calcular el esfuerzo requerido (Esfuerzo Requerido = Puntos de Función * Velocidad de entrega) para la entrega del software. Sin embargo, como esta tasa de entrega fue estimado, la incertidumbre deberá ser incluida en el cálculo. Esto fue considerado tanto por el cono de

Utilizando el cono de incertidumbre, un respectivo rango de variables necesita ser seleccionado de acuerdo a la etapa del ciclo de vida en la que se encuentra el proyecto. Si esta información no está disponible, se puede determinar por el nivel de detalle de la documentación proporcionada por el cliente. La figura anterior representa el Cono de la incertidumbre [5]. Después de que los rangos se han seleccionado en el cono de incertidumbre, la Evaluación de Proyectos y Técnica de Revisión (PERT) utiliza estos datos como entradas. La fórmula PERT es un método desarrollado por Booz, Allen y Hamilton en la década de 1950 que permitió una mayor precisión en la prospección. Esto se logra mediante el cálculo de la media de tres factores: la estimación nominal, estimación pesimista y estimación optimista [6]. PROMEDIO PONDERADO PARA ESTIMACIONES DE PROYECTOS Promedio Ponderado = [Estimación Optimista + 4 (Estimación Nominal) + Estimación pesimista] / 6

  Las variables de estimación optimista y pesimista de la fórmula PERT anteriormente mencionada fueron reemplazadas por el valor correspondiente del rango del Cono de incertidumbre multiplicado por la estimación nominal. Una vez que se calcula el promedio ponderado PERT, es posible calcular el costo de la aplicación utilizando como referencia el dato de Persona – Valor hora horas como fue definido por el cliente. Costo de la aplicación = Esfuerzo requerido ponderado* Persona – Valor hora Sin embargo, este resultado representa el valor mínimo para la valoración de la aplicación como se mencionó al principio de este artículo. Las otras variables que contribuyen indirectamente a esta valoración fueron calculadas usando el tamaño funcional como entrada. De acuerdo a la estimación de los costos de software, la duración se puede calcular con la siguiente fórmula: Duración (meses) = AlcanceFPConstant

mismo nivel de madurez de la aplicación que se está midiendo, que en este caso era CMMI Nivel 5. Posibles defectos = 5.5 * Tamaño Funcional Defectos Delivered = 0.22 * Tamaño Funcional Con esta información, cualquier cliente interesado en el desarrollo de este tipo de aplicación de software tendrá que considerar el costo relacionado con la fijación de dichos defectos, incluso después de que la aplicación haya sido desarrollada. Análisis de Puntos de Función (APF), como se ve en el escenario anterior, puede ser considerado como algo más que una técnica de medición cuando se usa con otras herramientas. Usando datos de referencia y datos históricos, el APF se puede utilizar para estimar costos, la duración y calidad de cualquier software y así atribuir tanto directa (costo) como indirectamente (valor de negocio) su valor monetario.

ALCANCE REREFENCIAS En este caso, el alcance de la aplicación se refiere a su medición de tamaño funcional. La constante de FP, también proporcionada por la estimación de costos de software [7], fue seleccionada de una lista con diferentes constantes por tipo de proyecto (el paquete comercial fue elegido). Con estas dos variables, se calculó la duración para una aplicación similar. Con este tipo de información, cualquier cliente tiene la capacidad de reconocer el tiempo que se tardaría en desarrollar una aplicación como ésta y realizar un análisis de costo de oportunidad para ver si vale la pena el uso de sus recursos para desarrollarlo. NIVEL DE CALIDAD Nivel de calidad es otro componente indirecto que puede ser utilizado en el análisis de costo de oportunidad. Esta variable se puede definir en términos de defectos por punto función (Defectos / FP). Debido a que el nivel de calidad se ve afectado por el tipo de metodología que se utiliza para desarrollar la aplicación, el libro Applied Software Measurement – Global Analysis of Productivity and Quality [8] se utilizó como referencia. Los posibles defectos y defectos constantes entregados fueron utilizados con el

 

[1] Counting Practices Manual, International Function Point Users’ Group (IFPUG). 4.3.1. [2] Function Point Analysis For Software Enhancement Guidelines, NESMA, 2.2.1. [3] International Software Benchmarking Standards Group (ISBSG). 2009. New Development & Enhancements Repository R11. http://www.isbsg.org. [4] Software Cost Estimation with COCOMO II, Boehm, B.W. and Abts, C. and Brown, A.W. and Chulani, S. and Clark, B.K., 9780137025763, 2009, Prentice Hall. [5] Software Estimation: Demystifying the Black Art (Developer Best Practices), Steve McConnell, 9780735605350, 2006, Microsoft Press; 1 Edition. [6] A Guide to the Project Management Body of Knowledge: PMBOK(R) Guide, Project Management Institute, 9781935589679, 2013, Project Management Institute. [7] Estimating Software Costs, Caper Jones, 9780070659490, 2007. McGraw-Hill Education. [8] Applied Software Measurement: Global Analysis of Productivity and Quality, Caper Jones, 9780071502443, 2008, McGraw-Hill Education.