Mtodo de Estimacin Puntos Casos de Uso (Use Case Points)

El mtodo de Puntos Casos de Uso (Use Case Points) fue desarrollado en 1993
por Gustav Kamer, bajo la supervisin de Ivar Jacobson (creador de los casos de
uso y gran promovedor del desarrollo de UML y el Proceso Unificado).

Este mtodo ha sido ampliamente utilizado por la empresa Rational. Su principal

ventaja es su rpida adaptacin a empresas que ya estn utilizando la tcnica de
Casos de Uso.

Para el clculo se procede de forma similar a Puntos de Funcin: se calcula

una cuenta no ajustada Puntos Casos de Uso (UAUCP), asignando una
complejidad a los actores y a los casos de uso.
Esta complejidad ser ponderada con un Factor de Ajuste tcnico y por un Factor
de Ajuste relativo al entorno de implantacin, obteniendo tras ello una cuenta de
Puntos Casos de Uso Ajustados.

Veamos a continuacin en detalle los pasos del mtodo:

1) Clasificar cada interaccin entre actor y caso de uso segn su

complejidad y asignar un peso en funcin de sta. Para poder clasificar la
complejidad de los actores debemos analizar la interaccin de ste con el
sistema que se va a desarrollar.
La complejidad de los actores puede corresponderse con una de las tres
categoras posibles:
o a. Simple. Representa a otro sistema con una API definida. Se le asigna un
peso de valor 1.
o b. Medio. Representa a otro sistema que interacta a travs de un protocolo
de comunicaciones. Por ejemplo TCP/IP o a travs de un interfaz por lnea de
comandos. Se le asigna un peso de valor 2.
o c. Complejo. La interaccin se realiza a travs de una interfaz grfica. Se le
asigna un peso de valor 3.
 TIPO DE INTERACCIN PESO ASIGNADO
Simple
1
(a travs de API)
Media
2
(a travs de protocolo)
Compleja
3
(a travs de interfaz grfica)

Tabla con los pesos en funcin de la complejidad de la interaccin con los actores

2) Calcular la complejidad de cada caso de uso segn el nmero de

transacciones o pasos del mismo. Para calcular la complejidad de un caso de
uso debemos determinar el nmero de transacciones, incluyendo los caminos
alternativos.
Se entiende por transaccin a un conjunto de actividades atmicas, donde se
ejecutan todas ellas o ninguna.
En funcin del nmero de transacciones que posee un caso de uso se clasifica
el caso de uso como simple, medio o complejo, siendo la asignacin de pesos la
que se muestra en la tabla siguiente:

N DE TRANSACCIONES DEL CASO DE USO TIPO PESO

menor o igual que 3 Simple 5

mayor o igual que 4 y menor que 7 Medio 10

mayor o igual que 7 Complejo 15

Tabla con los pesos en funcin de la complejidad de los casos de uso

3) Calcular los Puntos Casos de Uso No Ajustados (UUCP) del sistema. Se

obtienen sumando los Puntos Casos de Uso de todos y cada uno de los actores
y casos de uso que se han identificado y catalogado en funcin de su
complejidad.
4) Clculo de los Factores Tcnicos (TCF). A cada uno de los Factores
Tcnicos de la tabla siguiente se le asigna un valor de influencia en el proyecto
entre 0 (no tiene influencia) a 5 (esencial), 3 se considera de influencia media.
Obtenidos los grados de influencia se multiplican por el peso de cada factor y
con la siguiente frmula se calcula el Factor Tcnico que aplica:

FACTOR DESCRIPCIN PESO INFLUENCIA

R1 Sistema Distribuido 2 n

R2 Objetivos de rendimiento 1 n

R3 Eficiencia respecto al usuario final 1 p

R4 Procesamiento complejo 1 q

R5 Cdigo reutilizable 1 r

R6 Instalacin sencilla 0,5 s

R7 Fcil utilizacin 0,5 t

R8 Portabilidad 2 u

R9 Fcil de cambiar 1 v

R10 Uso Concurrente 1 w

R11 Caractersticas de seguridad 1 x

R12 Accesible por terceros 1 y

R13 Se requiere formacin especial 1 z

Tabla con los Factores Tcnicos para el clculo del TCF

 5) Clculo de los Factores de Entorno. A cada uno de los Factores de Entorno
de la tabla siguiente se le asigna un valor de influencia en el proyecto entre 0
(no tiene influencia) a 5 (esencial), 3 se considera de influencia media.
Obtenidos los grados de influencia se multiplican por el peso de cada factor y
con la siguiente frmula se calcula el Factor de Entorno que aplica:

FACTOR DESCRIPCIN PESO INFLUENCIA

R1 Familiar con RUP 1,5 n1

R2 Experiencia en la aplicacin 0,5 n2

R3 Experiencia con orientacin a objetos 1,0 n3

R4 Capacidades de anlisis 0,5 n4

R5 Motivacin 1,0 n5

R6 Requisitos estables 2,0 n6

R7 Trabajadores a tiempo parcial -1,0 n7

R8 Lenguaje complejo -1,0 n8

Tabla con los Factores de Entorno para el clculo del EF

6) Obtencin de los Puntos Casos de Uso Ajustados. Una vez calculados los
dos factores calculamos el valor ajustado de Puntos Casos de Uso con la
siguiente frmula:

Una vez obtenido el nmero de Puntos Casos de Uso, si se quiere obtener el

esfuerzo necesario para llevarlos a cabo en el mtodo se provee de un factor de
productividad.
El autor propone un valor de 20 horas/persona aunque existen distintas
propuestas sobre este valor.

Este esfuerzo calculado no abarcara a todas las fases del proyecto sino
nicamente a la codificacin de los Casos de Uso no estando contemplada otras
fases del desarrollo.

Por tanto, para calcular el esfuerzo total del proyecto habra que estimar el
esfuerzo en realizar el resto de actividades del proyecto y sumarlas a las
obtenidas por el mtodo de Puntos Casos de Uso.
 Estimacin Basada en Puntos de Funcin

Sus objetivos son:

Medir lo que el usuario pide y lo que el usuario recibe.
Medir independientemente de la tecnologa utilizada en la implantacin
del sistema.
Proporcionar una mtrica del tamao.
Proporcionar un medio para la estimacin del software.
Proporcionar un factor de normalizacin para la comparacin de distintos software.

Una vez presentado el mtodo, su autor realiz mejoras sobre el modelo inicial y
ha publicado diferentes versiones del mismo. En 1986, Allan Albrecht funda
el Grupo Internacional de Usuarios de Puntos de Funcin (en ingls International
Function Point User Group IFPUG). Esta organizacin se encarga de la difusin
del mtodo y de la publicacin de manuales de uso y documentos de cmo sacar
provecho del mismo.
Los Puntos de Funcin fueron diseados originariamente para ser aplicados
a sistemas de informacin de gestin, es por ello que se puso nfasis en la
dimensin de datos, excluyendo las dimensiones funcionales y de control. Su
aplicacin no era del todo adecuada para sistemas de ingeniera y embebidos,
pero con el correr del tiempo, se fueron subsanando estos inconvenientes. An
as, han surgido algunas variantes, entre las que se pueden contar:
Feature Points (Puntos de Caractersticas): este mtodo fue propuesto por
Caper Jones [Jones, 1987] como una alternativa que permitiera obtener puntos de
funcin en software cientfico y de ingeniera. Para evitar confusiones con los
Puntos de Funcin, Jones lo denomin puntos de caracterstica (en ingls feature
points). Actualmente es usado con mucho xito en software del tipo CAD (del
ingls Computer Aided Design), sistemas embebidos y sistemas en tiempo real.
MK II FPA: propuesto por Charles R. Symons [Symons, 1998], este mtodo es
una derivacin de los Puntos de Funcin de Albrecht, el que considera al sistema
que se est analizando, compuesto por cinco tipos de componentes (entradas
externas, salidas externas, consultas externas, grupos de datos lgicos internos y
externos), mientras que el MK II FPA mira al sistema como una coleccin de
transacciones lgicas discretas, compuestas cada una de ellas por
entrada, proceso y salida. Si se usan herramientas modernas de diseo para
el desarrollo del software, y esas herramientas permiten identificar fcilmente las
transacciones lgicas, resulta apropiado el uso de este mtodo.
3-D Function Point: entre los aos 1989 y 1992, Scott Whitmire [Whitmire, 1992]
desarroll un mtodo para la empresa internacional de aeronavegacin Boing.
El objetivo fue ampliar su espectro a sistemas con elevada complejidad como los
sistemas en tiempo real. El trmino 3D, se refiere a que considera tres
dimensiones en las que puede proyectarse un sistema software; ellas son:
datos, funciones y control. Visto de esta forma, resulta atractivo el uso del mtodo,
para aquel tipo de software, pero presenta el inconveniente de la necesidad de
disponer de mayor cantidad de informacin acerca del sistema, sobre todo de la
complejidad de los algoritmos a implementarse; esta informacin no siempre est
disponible en las primeras etapas del desarrollo.
Full Function Points (Puntos de Funcin Completos): esta tcnica ha sido
desarrollada por un equipo de la Universidad de Qubec en Montreal (Canad)
[Abran A., et al., 1998], siendo muy eficiente en la medicin de puntos de funcin
en sistemas de control, tiempo real y embebido. Particularmente, los sistemas en
tiempo real presentan dos factores crticos: primero, el tiempo de respuesta y en
segundo lugar, su interaccin con entidades externas. Los puntos de funcin de
Albrecht tienen limitaciones para medir sistemas software en tiempo real. Estos
ltimos trabajan con dos tipos de estructura de datos de control: grupo lgico de
ocurrencia mltiple, que puede tener ms de una instancia por cada tipo
de registro y el grupo lgico de ocurrencia nica, que puede tener solamente una
instancia por cada tipo de registro. En lo que respecta a las transacciones, los
sistemas en tiempo real, presentan una variacin importante en la cantidad de
subprocesos por proceso; es decir, el mtodo debera contemplar que
unos procesos contaran con unos pocos subprocesos y otros en cambio, con un
nmero significativo de ellos. Los puntos de funcin se basan ms en el nmero
de procesos que en el de subprocesos. Para paliar este inconveniente, Full
Function Points introduce en el clculo no solamente a los procesos, sino que
tambin incluye a los subprocesos.
COSMIC FFP: a finales de 1998, un grupo de expertos en mtricas de software,
establecieron el Common Software Measurement International Consortium
(COSMIC FFP). La iniciativa de COSMIC, ha sido bsicamente la de dar
respuesta a proveedores y a clientes de servicios de desarrollo de software,
principalmente en aquellos contratos de terceros donde no haba reglas claras
acerca del valor de este tipo de servicio. En tal sentido COSMIC apunta a
satisfacer tanto a proveedores de software que deben traducir los requerimientos
del cliente en un tamao del software como un paso clave en la estimacin de
los costos del proyecto, como a los clientes que quieren conocer ese tamao
recibido como un componente importante para la medicin del rendimiento del
proveedor. El mtodo se puede aplicar a dominios de software de gestin, tiempo
real e hbridos.

Fig 1. Evolucin de los mtodos de estimacin basados en FP

Existen herramientas automticas de estimacin que implementan tcnicas de
descomposicin o modelos empricos y estn provistas de entornos grficos,
interfaz interactiva y uso estandarizado que hacen de ellas una buena opcin.
Adems permiten describir caractersticas de la organizacin (experiencia,
entorno, etc.) y el software a desarrollar para que a partir de estos datos, sea
posible obtener estimaciones de costo, tiempo y esfuerzo. Algunas herramientas
se muestran en la tabla 1:

Tabla 1. Ejemplos de herramientas automticas de estimacin

La tcnica de medicin del tamao en punto-funcin consiste en asignar una
cantidad de "puntos" a una aplicacin informtica segn la complejidad de los
datos que maneja y de los procesos que realiza sobre ellos, siempre tratando de
considerarlo desde el punto de vista del usuario.
Los puntos de funcin se calculan completando la tabla de la Figura 3. Se
determinan cinco caractersticas de dominios de informacin y se proporcionan
las cuentas en la posicin apropiada de la tabla. Los valores de los dominios de
informacin se definen de la forma siguiente:
Nmero de entradas de usuario. Se cuenta cada entrada de usuario que
proporciona diferentes datos orientados a la aplicacin. Las entradas se deberan
diferenciar de las peticiones, las cuales se cuentan de forma separada.
Nmero de salidas de usuario. Se cuenta cada salida que proporciona al usuario
informacin orientada a la aplicacin. En este contexto la salida se refiere
a informes, pantallas, mensajes de error, etc. Los elementos de datos particulares
dentro de un informe no se cuentan de forma separada.
Nmero de peticiones de usuario. Una peticin se define como una entrada
interactiva que produce la generacin de alguna respuesta del software inmediata
en forma de salida interactiva. Se cuenta cada peticin por separado.
Nmero de archivos. Se cuenta cada archivo maestro lgico (esto es, un grupo
lgico de datos que puede ser una parte de una gran base de datos o un archivo
independiente).
Nmero de interfaces externas. Se cuentan todas las interfaces legibles por la
mquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para
transmitir informacin a otro sistema.
Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor
de complejidad. Las organizaciones que utilizan mtodos de puntos de funcin
desarrollan criterios para determinar si una entrada en particular es simple, media
o compleja. No obstante la determinacin de la complejidad es algo subjetiva.

Fig 3. Clculo de puntos de funcin.

Para calcular puntos de funcin, se utiliza la relacin siguiente:
FP = cuenta-total x [ 0,65 + 0,01 x (Fi ) ] (1)
Donde cuenta-total es la suma de todas las entradas obtenidas de la figura 3. Fi
donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados
en las respuestas a las siguientes preguntas:
1. Requiere el sistema copias de seguridad y de recuperacin fiables?
2. Se requiere comunicacin de datos?
3. Existen funciones de procesamiento distribuido?
4. Es crtico el rendimiento?
5. Se ejecutara el sistema en un entorno operativo existente y fuertemente
utilizado?
6. Requiere el sistema entrada de datos interactiva?
7. Requiere la entrada de datos interactiva que las transacciones de entrada se
lleven a cabo sobre mltiples pantallas u operaciones?
8. Se actualizan los archivos maestros de forma interactiva?
9. Son complejas las entradas, las salidas, los archivos o las peticiones?
10. Es complejo el procesamiento interno?
11. Se ha diseado el cdigo para ser reutilizable?
12. Estn incluidas en el diseo la conversi6n y la instalaci6n?
13. Se ha diseado el sistema para soportar mltiples instalaciones en diferentes
organizaciones?
14. Se ha diseado la aplicaci6n para facilitar los cambios y para ser fcilmente
utilizada por el usuario?
Cada una de las preguntas anteriores es respondida usando una escala con
rangos desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial).

Los valores constantes de la ecuacin (1) y los factores de peso que se aplican a
las cuentas de los dominios de informacin se determinan empricamente. Una
vez que se han calculado los puntos de funcin, se utilizan de forma anloga a las
lneas de cdigo como forma de normalizar las medidas
de productividad, calidad y otros atributos del software.
Una vez calculado los puntos de funcin se usan de forma analgica a las lneas
de cdigo como medida de la productividad, calidad y otros productos del
software.
 Productividad = PF / persona-mes
Calidad = Errores / PF
Costo = Dlares / PF
Documentacin = Pags. Doc / PF
El proceso de clculo y obtencin de puntos de funcin y su posible
transformacin a lneas de cdigo se esquematiza en la figura:

Fig. 2 Proceso de clculo de puntos de funcin y transformacin a lneas de cdigo

Hay muchos usos de los puntos funcin ms all de los programas de estimacin,
esfuerzo y costo. Entre ellos tenemos:
El uso de puntos funcin para estimar casos de prueba.
El uso de puntos funcin para ayudar a entender rangos de productividad amplios.
El uso de puntos funcin para ayudar a entender el crecimiento de Proyectos.
El uso de puntos funcin para ayudar a calcular el costo real del software.
 El uso de puntos funcin para ayudar a estimar el costo de proyectos,
la programacin y el esfuerzo.
El uso de puntos funcin para ayudar a entender los costos de mantenimiento.
El uso de puntos funcin para ayudar con las negociaciones de contrato.
El uso de puntos funcin para desarrollar un estndar de establecimiento de
mtricas.

El uso de puntos funcin para estimar casos de prueba

Muchos intentos se han realizado para tratar de establecer una relacin entre
puntos funcin y los esfuerzos asociados con el desarrollo de software. La
dificultad de establecer esta relacin estriba en el hecho de que solo la relacin
entre puntos funcin y el ciclo de vida completo del software son examinados. Esta
seccin examina la relacin entre puntos funcin y las pruebas -- en particular la
relacin entre los casos de prueba y los puntos funcin. La relacin entre puntos
funcin y el nmero de casos de prueba es muy fuerte. Capers Jones estima que
el nmero de casos de prueba aproximadamente ser igual al nmero de puntos
funcin elevado a la potencia 1.2 (FP 1.2). Esto es, los casos de prueba crecen en
una proporcin mayor que los puntos funcin. Esto es intuitivo porque cuando una
aplicacin crece, el nmero de interrelaciones dentro de la aplicacin se vuelven
ms complejas.
Por ejemplo, si una aplicacin de desarrollo tiene 1,000 puntos funcin, debe
haber aproximadamente 4,000 casos de prueba. Obviamente, el equipo de
desarrollo debe empezar a crear casos de prueba tan pronto como sea posible. Si
el equipo de desarrollo espera hasta que el cdigo ha sido completado,
posiblemente slo lograrn crear menos de 4,000 casos de prueba.
El uso de puntos funcin para ayudar a entender rangos de productividad amplios

Las medidas de productividad inconsistentes entre proyectos pueden ser un

indicador de que un proceso estndar no se est siguiendo. Productividad se
define como la razn entre entradas / salidas. Para software, productividad se
define como la cantidad de esfuerzo requerido para lograr un cierto grado de
funcionalidad (como se mide en puntos funcin).
Muchas organizaciones sufren cuando sus niveles de productividad son mayores o
menores del 100 por ciento. Esto es verdad aun cuando hayan contado los puntos
funcin correctamente y capturado los tiempos consistentemente. Las
organizaciones se quejan de anlisis de productividad sin valor. En la mayora de
las organizaciones, el software se crea de muy diferentes maneras, usando muy
diferentes procesos (y en muchos casos, sin procesos). Si el software se
desarrolla inconsistentemente, como consecuencia las medidas de productividad
tambin resultan inconsistentes. Lo mismo puede ser cierto para cualquier proceso
de produccin. Los cambios bruscos en las medidas de productividad entre
proyectos son una indicacin de que no se est siguiendo un proceso estndar.
En la medida que los equipos de trabajo se adhieren a un proceso estndar de
desarrollo, los rangos de productividad se deben estabilizar y ser ms
consistentes.
El uso de puntos funcin para ayudar a entender el crecimiento de proyectos

El anlisis de puntos funcin provee un mecanismo para monitorizar el crecimiento

de proyectos. El conteo de puntos funcin al final de las fases de obtencin de
requisitos, anlisis, diseo e implementacin se pueden comparar. El conteo de
puntos funcin al final de los requisitos y/o diseo se puede comparar a los puntos
funcin al final del proyecto. Si el nmero de puntos funcin se ha incrementado,
se puede asumir que el proyecto ha sido definido de mejor manera o que el
proyecto ha crecido en realidad. El crecimiento es una indicacin de la exactitud
con que los requisitos fueron recogidos y/o comunicados al equipo del proyecto. El
crecimiento de todos los proyectos debe ser monitorizado. Si el crecimiento de los
proyectos declina a travs del tiempo, se asume de manera natural que la
comunicacin con el usuario ha mejorado.
El uso de puntos funcin para ayudar a calcular el costo real del software

La mayora de las organizaciones subestima en gran medida el costo del software.

El costo real del software es la suma de todos los costos durante la vida de un
proyecto, incluyendo los mejoramientos esperados y los costos de mantenimiento.
De hecho, el clculo real debera ser el valor presente de todos los desarrollos,
mejoras, y costos de mantenimiento esperados durante la vida del proyecto. Este
 tipo de anlisis demuestra la recompensa de invertir en un diseo y anlisis de
primera. Cuanto ms se invierta en un buen diseo, ms se va a ahorrar en
futuros costos de mantenimiento y mejoras. Es importante tener un costo unitario
para evaluar la inversin inicial y comparar sta con los gastos posteriores. El
costo unitario puede ser horas/PF o $/PF. Los incrementos en la inversin inicial
deben reducir el costo unitario de actividades de mejora y mantenimiento futuras.

El uso de puntos funcin para ayudar a estimar el costo de proyectos, la programacin

y el esfuerzo

La estimacin exitosa usando puntos funcin se basa en varias tcnicas de

estimacin: Top-Down, Analoga y Consejo de Expertos. La estimacin Top-Down
es una tcnica de estimacin que calcula el programa entero, costo y esfuerzo
usando parmetros amplios. Los parmetros amplios y las comparaciones estn
basados en datos histricos usando tcnicas estimativas de Analoga. El Consejo
de Expertos se obtiene de expertos con experiencia en proyectos similares o
experiencia en el uso de puntos funcin.
La comparacin de proyectos con otros similares es una actividad crtica para
lograr una estimacin exitosa. Cuando se evalan proyectos similares, se debe
considerar lo siguiente:
Tipo de plataforma de hardware - Mainframe, Cliente-Servidor, PC
Tipo de lenguaje - COBOL, C, C++
Tipo de proyecto - Software del Sistema, Software intermedio, Software de
aplicacin
Tipo de sistema operativo: MVS, Windows, Unix

Una vez que los proyectos han sido determinados, obtener los siguientes datos:
Medida histrica de entrega (horas por punto funcin) de proyectos similares
Programas histricos (duracin de programas por punto funcin) de proyectos
similares
Costos histricos (dlares por punto funcin)
Una vez que el tamao del proyecto se ha determinado en puntos funcin, el
estimado de horas, costo y programa se puede calcular. Los clculos se deben
hacer con datos de proyectos similares como se describi anteriormente.
Por ejemplo, si se determina que el tamao del proyecto actual es de 500 puntos
funcin y la medida de entrega de un proyecto similar es $10 por punto funcin,
entonces el costo total esperado para el proyecto sera $10 ($/punto funcin) x
500 PFs = $5,000 dlares. Pueden hacerse clculos similares para programas,
duracin y horas.
El uso de puntos funcin para ayudar a entender los costos de mantenimiento

Muchos presupuestos de mantenimiento se establecen basados en ejecuciones

de aos pasados. Muchas organizaciones tratan de reducir los costos de
mantenimiento y no planean incrementarlos ao por ao para cualquier aplicacin
particular. Si la nueva funcionalidad es encontrada y aadida al producto base, los
costos unitarios de mantenimiento pueden bajar mientras los gastos reales de
mantenimiento permanecen constantes o se incrementan. Si los costos de
mantenimiento se incrementan a un ritmo menor que los puntos funcin, el
crecimiento de los costos de mantenimiento en realidad disminuye. Por ejemplo, si
una organizacin gasta $100,000 para mantener 10,000 puntos funcin o $10 por
punto funcin, pero el nmero de puntos funcin crece 10% a 11,000 y los dlares
de mantenimiento permanecen constantes, entonces los costos de mantenimiento
por punto funcin disminuye a $9. Muchos ejecutivos de sistemas no entienden ni
asimilan este concepto.
El uso de puntos funcin para ayudar con las negociaciones de contrato

Los administradores de contratos pueden usar su conocimiento en puntos funcin

para construir y manejar proyectos basados en el precio por punto funcin y
tambin en la comparacin de los precios de los vendedores. Estas personas
establecen un uso efectivo en cuanto a costo, de terceras partes, en el desarrollo,
validan las propuestas basados en el tamao de puntos funcin y pueden evaluar
el impacto de proyectos cancelados.
Los puntos funcin pueden ser usados para ayudar a especificar los productos
claves a entregar a un vendedor, para asegurar que los niveles apropiados de
funcionalidad van a ser entregados y desarrollar medidas objetivas de efectividad
de costos y calidad. Son los ms efectivamente usados en contratos de precio fijo
como un medio para especificar exactamente lo que se va a entregar. Desde una
perspectiva interna, el manejo exitoso de los contratos de precio fijo depende
absolutamente de la representacin precisa del esfuerzo. La estimacin de este
esfuerzo (en el ciclo de vida completo) puede ocurrir slo cuando una mtrica
normalizada, tal como la provista por los puntos funcin, se aplica.
Resumiendo, el anlisis de puntos funcin provee el mejor mtodo objetivo para
medir los proyectos de software, y para manejar el tamao de los proyectos de
software durante su desarrollo. Es el mejor mtodo de manejar el riesgo en dos
vertientes. Primero, el cliente (usuario/especificador) puede aceptar ms
fcilmente el riesgo para un determinado tamao de proyecto de software (en
puntos funcin). Segundo, el desarrollador puede ms fcilmente aceptar
los riesgos para el costo de produccin (el costo por punto funcin). Adherirse a un
conteo consistente de puntos funcin optimiza esta relacin y facilita el desarrollo
en lnea y bajo presupuesto.
La asignacin de precios de "software externo" (p.ej. el diseado para uso fuera
de la organizacin) puede ser encauzado directamente al esfuerzo de produccin
cuando se requieren mtricas funcionales. Si un desarrollador de software sabe
exactamente cul va a ser su costo interno de desarrollo de un punto funcin, se
puede incorporar a los algoritmos de costeo usados para determinar los precios
externos. Sin un entendimiento claro del tiempo y esfuerzo por punto funcin, la
asignacin de precios a los paquetes de software continuar siendo difcil.
El uso de puntos funcin para desarrollar un estndar de establecimiento de mtricas

Por supuesto, los puntos funcin necesitan usarse en asociacin con las otras
medidas. De hecho, los puntos funcin por s mismos proveen poco o nada de
beneficio. Muchas mtricas necesitan ser reportadas al nivel organizativo. Por
ejemplo, tanto la mtrica de productividad/costo como la mtrica de calidad
necesitan ser reportadas al nivel organizativo. Las mtricas de productividad/costo
son usadas para demostrar la medida y el costo de la funcionalidad que se est
entregando. Las mtricas de calidad son usadas para demostrar niveles existentes
de calidad y para monitorizar los esfuerzos continuos de mejoramiento en el
proceso de desarrollo del software. Estas mtricas deben ser monitorizadas y
estudiadas en sus tendencias.
Resultados de una Experiencia en la Determinacin del Tamao de un Software.

La experiencia se desarroll dentro de la asignatura Gestin de Proyectos de

Ingeniera de Software, un electivo de quinto ao de la carrera de Ingeniera
Informtica en la Universidad de Concepcin. Esta experiencia consisti en un
simulacro de llamado a licitacin para el desarrollo de un producto software para
una organizacin ficticia. La experiencia se realiz sobre la base de una
especificacin de requisitos considerada buena (no ambigua y bastante completa).
Una de las tareas que los alumnos debieron ejecutar para responder a este
llamado, fue determinar el tamao del producto, estimar costos y plazos. La
mayora de ellos escogi la mtrica puntos de funcin por sobre otras (puntos de
caracterstica, lneas de cdigo) por las ventajas que esta mtrica tiene. Todos los
alumnos manejaban la tcnica de conteo de puntos de funcin, y utilizaron el
mismo mtodo (gua) para realizar el conteo. Todos los alumnos debieron entregar
el detalle de las tareas desarrolladas como anexo a la propuesta, por lo que se
pudo verificar la correcta aplicacin del mtodo para el caso de la estimacin del
tamao del software a desarrollar. A continuacin, se presentan los resultados
obtenidos en la experiencia descrita anteriormente y una hiptesis explicativa de
los resultados.
Para presentar una respuesta a un llamado a licitacin, 13 alumnos de quinto ao
debieron determinar una buena estimacin del tamao del producto a desarrollar,
eligiendo 10 de ellos la mtrica puntos de funcin.
Los resultados obtenidos se muestran en la tabla y grficos siguientes. En ellos
se muestra la medida en puntos de funcin obtenida por cada alumno, en un
rango de 181 a 759.
La desviacin estndar de estos datos es de aproximadamente 211 PF (Puntos de
Funcin) sobre el promedio, lo que es sin duda muy alto. Esta gran diferencia
condujo a estimaciones de esfuerzo y plazos drsticamente distintas. Esto influy
directamente en la cantidad de personal que cada alumno asign al proyecto y a la
organizacin del mismo (provocando impacto tambin en la funcin de staffing),
adems de la influencia directa en los costos y plazos. Durante el desarrollo del
proyecto, las diferencias en estas estimaciones provocaran grandes diferencias
tambin en la direccin, por lo que estara efectivamente afectando al proyecto en
su conjunto, y por lo tanto al xito o fracaso del mismo.
Algo interesante e inesperado result este clculo dispar entre candidatos a
ingenieros civiles informticos sobre la base de una misma especificacin de
requisitos y un mismo mtodo de clculo de puntos de funcin.
La asignacin de complejidad que el mtodo exige para cada tem (entrada,
salida, consulta, archivo lgico, archivo de interfaz), es un tanto subjetiva y
normalmente difiere de un desarrollador a otro, pero esto no explicara una
desviacin de tal magnitud (211 puntos de funcin).
La causa de estas diferencias de tamao estimado est en el entendimiento de
qu constituye efectivamente una salida externa, una entrada externa, un archivo
lgico interno y una consulta.
La especificacin del software que fue objeto de medicin, est organizada por
tipo de informacin. Los reportes y consultas estn claramente especificados,
mediante un diseo de formularios, pero no as las entradas. Slo se especifican
los datos que se deben ingresar.
De lo anterior, se puede deducir que el nmero de salidas y consultas estaba ms
bien claro, y que la causa de las grandes diferencias estuvo en las entradas y
archivos lgicos internos.
Para el caso de las entradas, dado que no se especificaba cul conjunto de datos
sera ingresado simultneamente, algunos alumnos los agruparon segn su
criterio, obteniendo un nmero de entradas cercano al nmero de consultas y
salidas, pero otros consideraron que cada dato a ingresar constitua una entrada,
por lo que el nmero de entradas aument en gran medida. A pesar de que la
complejidad de las entradas que involucran a ms de un dato es mayor que la de
una entrada de un solo dato, esto no alcanz a corregir la diferencia entre las
medidas.
Para el caso de los archivos lgicos internos, algunos alumnos agruparon
grandes conjuntos de informacin en un archivo lgico interno, mientras que otros
modelaron la informacin en un esquema entidad relacin, obteniendo una
aproximacin mucho ms cercana a la cantidad de tablas que efectivamente
implementaran. Evidentemente, el nmero de archivos lgicos internos fue mucho
mayor en el segundo caso.
Otro factor de dificultad para realizar el clculo del tamao del software fue la
existencia del requisito "se debe posibilitar la capacidad de realizar consultas no
estructuradas". Este requisito fue tratado de maneras dismiles: fue dejado fuera,
considerado al equivalente de 15 o ms consultas complejas, o se decidi que se
utilizara una interfaz a alguna herramienta que proveyera dicha funcionalidad.
Este punto tambin provoc diferencias.
Otro factor importante, que se da tambin en los casos reales (esta experiencia
fue acadmica), fue la presin a la que estaban sujetos los participantes. Deban
entregar una propuesta de calidad dentro de los plazos, o su castigo sera
equivalente a no ganarse el proyecto: una baja calificacin, o peor an, reprobar la
 asignatura. Por otro lado, al tener el conocimiento de que el ganador del proyecto
no tendra que desarrollarlo, podan arriesgarse a hacer ofrecimientos interesantes
y convenientes, pues no ponan en juego su prestigio. Este es un riesgo que
normalmente no debieran correr las empresas proveedoras de servicios de
desarrollo de software serio, las que debieran hacer estimaciones ms bien
conservadoras.
Combinacin de las alternativas para la estimacin de Proyectos de Software.

Cocomo y la tcnica de estimacin de puntos de funcin

El mtodo Cocomo permite determinar los valores de las siguientes dos variables:
Meses/hombre a aplicar al proyecto

Meses totales del proyecto (dependiendo de factores tales como los atributos de
fiabilidad requerida del software, tamao de la base de datos, complejidad del
producto, limitaciones en el tiempo de ejecucin, limitaciones
de memoria principal, volatilidad de la mquina virtual, frecuencia de cambio en el
modelo de explotacin del ordenador, capacitacin de los analistas, experiencia en
aplicaciones, capacitacin de los programadores, experiencia en la mquina
virtual, experiencia en el lenguaje de programacin, prcticas modernas de
programacin, uso de herramientas para el desarrollo del software y limitaciones
en la planificacin).

Esta tcnica requiere de un dato elemental determinado por la cantidad de

sentencias de cdigo del proyecto a la que posteriormente se aplican diferentes
algoritmos que varan de acuerdo al modelo de desarrollo elegido (Orgnico,
Semilibre o Libre) para entallarlo finalmente de acuerdo a factores de ajuste
seleccionados a partir de las caractersticas especficas del proyecto.
Esta informacin se convierte en el aspecto crtico del mtodo ya que ese valor es
un parmetro difcil de determinar con exactitud y puede variar considerablemente
segn las metodologas de desarrollo utilizadas. El camino para resolver este
aspecto crtico es mediante la aplicacin de otra tcnica, la de Puntos de Funcin.
Figura 4: Estimacin de Proyectos por el mtodo de Puntos de Funcin