Puntos de Función como herramienta para la Valoración de Software

 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.