Estimación Basada en Puntos de Función y Soluciones Híbridas (página 2)

Sus objetivos
son:

• Medir lo que el usuario pide y lo que el usuario
  recibe.
• Medir independientemente de la tecnología utilizada en la
  implantación del sistema.
• Proporcionar una métrica del
  tamaño.
• Proporcionar un medio para la estimación del
  software.
• Proporcionar un factor de normalización para la comparación
  de distintos software.

Una vez presentado el método, 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 Función
(en inglés
International Function Point User Group – IFPUG).
Esta organización se encarga de la
difusión del método y de la publicación de
manuales de
uso y documentos de
cómo sacar provecho del mismo.

Los Puntos de Función fueron diseñados
originariamente para ser aplicados a sistemas de
información de gestión, es por ello que se puso
énfasis en la dimensión de datos, excluyendo
las dimensiones funcionales y de control. Su
aplicación no era del todo adecuada para sistemas de
ingeniería y embebidos, pero con el correr
del tiempo, se
fueron subsanando estos inconvenientes. Aún así,
han surgido algunas variantes, entre las que se pueden
contar:

Feature Points (Puntos de
Características): este método fue propuesto
por Caper Jones [Jones, 1987] como una alternativa que permitiera
obtener puntos de función en software científico y
de ingeniería. Para evitar confusiones con los Puntos de
Función, Jones lo denominó puntos de
característica (en inglés feature points).
Actualmente es usado con mucho éxito
en software del tipo CAD (del inglés Computer Aided
Design), sistemas embebidos y sistemas en tiempo real.

MK II FPA: propuesto por Charles R. Symons
[Symons, 1998], este método es una derivación de
los Puntos de Función 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
lógicos internos y externos), mientras que el MK II FPA
mira al sistema como una colección de transacciones
lógicas discretas, compuestas cada una de ellas por
entrada, proceso y
salida. Si se usan herramientas
modernas de diseño
para el desarrollo del
software, y esas herramientas permiten identificar
fácilmente las transacciones lógicas, resulta
apropiado el uso de este método.

3-D Function Point: entre los años
1989 y 1992, Scott Whitmire [Whitmire, 1992] desarrolló un
método para la empresa
internacional de aeronavegación Boing. El objetivo fue
ampliar su espectro a sistemas con elevada complejidad como los
sistemas en tiempo real. El término 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
método, para aquel tipo de software, pero presenta el
inconveniente de la necesidad de disponer de mayor cantidad de
información acerca del sistema, sobre todo
de la complejidad de los algoritmos a
implementarse; esta información no siempre está
disponible en las primeras etapas del desarrollo.

Full Function Points (Puntos de Función
Completos): esta técnica ha sido desarrollada por
un equipo de la Universidad de
Québec en Montreal (Canadá) [Abran A., et
al., 1998], siendo muy eficiente en la medición de puntos de función en
sistemas de control, tiempo real y embebido. Particularmente, los
sistemas en tiempo real presentan dos factores críticos:
primero, el tiempo de respuesta y en segundo lugar, su
interacción con entidades externas. Los puntos de
función de Albrecht tienen limitaciones para medir
sistemas software en tiempo real. Estos últimos trabajan
con dos tipos de estructura de
datos de control: grupo lógico de ocurrencia
múltiple, que puede tener más de una instancia por
cada tipo de registro y el
grupo lógico 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 variación importante en la cantidad de
subprocesos por proceso; es decir, el método
debería contemplar que unos procesos
contarían con unos pocos subprocesos y otros en cambio, con un
número significativo de ellos. Los puntos de
función se basan más en el número de
procesos que en el de subprocesos. Para paliar este
inconveniente, Full Function Points introduce en el cálculo no
solamente a los procesos, sino que también incluye a los
subprocesos.

COSMIC FFP: a finales de 1998, un grupo de
expertos en métricas de software, establecieron el Common
Software Measurement International Consortium (COSMIC FFP). La
iniciativa de COSMIC, ha sido básicamente la de dar
respuesta a proveedores y
a clientes de
servicios de
desarrollo de software, principalmente en aquellos contratos de
terceros donde no había 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
tamaño del software como un paso clave en la
estimación de los costos del
proyecto, como
a los clientes que quieren conocer ese tamaño recibido
como un componente importante para la medición del
rendimiento del proveedor. El método se puede aplicar a
dominios de software de gestión, tiempo real e
híbridos.

Fig 1. Evolución de los métodos de
estimación basados en FP

Existen herramientas automáticas de
estimación que implementan técnicas
de descomposición o modelos
empíricos y están provistas de entornos gráficos, interfaz interactiva y uso
estandarizado que hacen de ellas una buena opción.
Además permiten describir características de
la
organización (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
automáticas de estimación

La técnica de medición del tamaño
en punto-función consiste en asignar una cantidad de
"puntos" a una aplicación informática según 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 función se calculan completando la
tabla de la Figura 3. Se determinan cinco características
de dominios de información y se proporcionan las cuentas en la
posición apropiada de la tabla. Los valores de los
dominios de información se definen de la forma
siguiente:

Número de entradas de usuario. Se cuenta
cada entrada de usuario que proporciona diferentes datos
orientados a la aplicación. Las entradas se
deberían diferenciar de las peticiones, las cuales se
cuentan de forma separada.

Número de salidas de usuario. Se cuenta
cada salida que proporciona al usuario información
orientada a la aplicación. 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.

Número de peticiones de usuario. Una
petición se define como una entrada interactiva que
produce la generación de alguna respuesta del software
inmediata en forma de salida interactiva. Se cuenta cada
petición por separado.

Número de archivos. Se cuenta cada
archivo
maestro lógico (esto es, un grupo lógico de datos
que puede ser una parte de una gran base de datos
o un archivo independiente).

Número de interfaces externas. Se
cuentan todas las interfaces legibles por la máquina (por
ejemplo: archivos de datos
de cinta o disco) que se utilizan para transmitir
información 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 métodos de puntos de función
desarrollan criterios para determinar si una entrada en
particular es simple, media o compleja. No obstante la
determinación de la complejidad es algo
subjetiva.

Fig 3. Cálculo de puntos de
función.

Para calcular puntos de función, se utiliza la
relación 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
recuperación fiables?

2. ¿Se requiere comunicación de datos?

3. ¿Existen funciones de procesamiento
distribuido?

4. ¿Es crítico el rendimiento?

5. ¿Se ejecutaría 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
múltiples 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 diseñado el código
para ser reutilizable?

12. ¿Están incluidas en el diseño
la conversi6n y la instalaci6n?

13. ¿Se ha diseñado el sistema para
soportar múltiples instalaciones en diferentes
organizaciones?

14. ¿Se ha diseñado la aplicaci6n para
facilitar los cambios y para ser fácilmente 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 ecuación (1) y los
factores de peso que se aplican a las cuentas de los dominios de
información se determinan empíricamente. Una vez
que se han calculado los puntos de función, se utilizan de
forma análoga a las líneas de código como
forma de normalizar las medidas de productividad,
calidad y
otros atributos del software.

Una vez calculado los puntos de función se usan
de forma analógica a las líneas de código
como medida de la productividad, calidad y otros productos del
software.

Productividad = PF / persona-mes

Calidad = Errores / PF

Costo = Dólares / PF

Documentación = Pags. Doc / PF

El proceso de cálculo y obtención de
puntos de función y su posible transformación a
líneas de código se esquematiza en la
figura:

Fig. 2 Proceso de cálculo de
puntos de función y transformación a líneas
de código

Hay muchos usos de los puntos función más
allá de los programas de
estimación, esfuerzo y costo. Entre ellos
tenemos:

• El uso de puntos función para estimar casos de
  prueba.
• El uso de puntos función para ayudar a
  entender rangos de productividad amplios.
• El uso de puntos función para ayudar a
  entender el crecimiento de Proyectos.
• El uso de puntos función para ayudar a
  calcular el costo real del software.
• El uso de puntos función para ayudar a estimar
  el costo de proyectos, la programación y el esfuerzo.
• El uso de puntos función para ayudar a
  entender los costos de mantenimiento.
• El uso de puntos función para ayudar con las
  negociaciones de contrato.
• El uso de puntos función para desarrollar un
  estándar de establecimiento de
  métricas.

El uso de
puntos función para estimar casos de
prueba

Muchos intentos se han realizado para tratar de
establecer una relación entre puntos función y los
esfuerzos asociados con el desarrollo de software. La dificultad
de establecer esta relación estriba en el hecho de que
solo la relación entre puntos función y el ciclo de vida
completo del software son examinados. Esta sección examina
la relación entre puntos función y las pruebas — en
particular la relación entre los casos de prueba y los
puntos función. La relación entre puntos
función y el número de casos de prueba es muy
fuerte. Capers Jones estima que el número de casos de
prueba aproximadamente será igual al número de
puntos función elevado a la potencia 1.2 (FP
1.2). Esto es, los casos de prueba crecen en una
proporción mayor que los puntos función. Esto es
intuitivo porque cuando una aplicación crece, el
número de interrelaciones dentro de la aplicación
se vuelven más complejas.

Por ejemplo, si una aplicación de desarrollo
tiene 1,000 puntos función, 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 código ha sido
completado, posiblemente sólo lograrán crear menos
de 4,000 casos de prueba.

 El uso
de puntos función para ayudar a entender rangos de
productividad amplios

Las medidas de productividad inconsistentes entre
proyectos pueden ser un indicador de que un proceso
estándar no se está siguiendo. Productividad se
define como la razón 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 función).

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 función
correctamente y capturado los tiempos consistentemente. Las
organizaciones se quejan de análisis de productividad sin valor. En la
mayoría 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 también resultan inconsistentes. Lo mismo
puede ser cierto para cualquier proceso de producción. Los cambios bruscos en las
medidas de productividad entre proyectos son una
indicación de que no se está siguiendo un proceso
estándar. En la medida que los equipos de trabajo se
adhieren a un proceso estándar de desarrollo, los rangos
de productividad se deben estabilizar y ser más
consistentes.

El uso de puntos
función para ayudar a entender el crecimiento de
proyectos

El análisis de puntos función provee un
mecanismo para monitorizar el crecimiento de proyectos. El conteo
de puntos función al final de las fases de
obtención de requisitos, análisis, diseño e
implementación se pueden comparar. El conteo de puntos
función al final de los requisitos y/o diseño se
puede comparar a los puntos función al final del proyecto.
Si el número de puntos función 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
indicación 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 través del tiempo, se asume de
manera natural que la
comunicación con el usuario ha mejorado.

El uso de
puntos función para ayudar a calcular el costo real del
software

La mayoría 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 cálculo real debería
ser el valor presente de todos los desarrollos, mejoras, y costos
de mantenimiento esperados durante la vida del proyecto. Este
tipo de análisis demuestra la recompensa de invertir en un
diseño y análisis de primera. Cuanto más se
invierta en un buen diseño, más se va a ahorrar en
futuros costos de mantenimiento y mejoras. Es importante tener un
costo unitario para evaluar la inversión inicial y comparar ésta
con los gastos
posteriores. El costo unitario puede ser horas/PF o $/PF. Los
incrementos en la inversión inicial deben reducir el costo
unitario de actividades de mejora y mantenimiento futuras.
 

El uso de puntos función para ayudar a
estimar el costo de proyectos, la programación y el
esfuerzo

La estimación exitosa usando puntos
función se basa en varias técnicas de
estimación: Top-Down, Analogía y Consejo de
Expertos. La estimación Top-Down es una técnica de
estimación que calcula el programa entero,
costo y esfuerzo usando parámetros amplios. Los
parámetros amplios y las comparaciones están
basados en datos históricos usando técnicas
estimativas de Analogía. El Consejo de Expertos se obtiene
de expertos con experiencia en proyectos similares o experiencia
en el uso de puntos función.

La comparación de proyectos con otros similares
es una actividad crítica
para lograr una estimación exitosa. Cuando se
evalúan 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 aplicación
• Tipo de sistema
  operativo: MVS, Windows,
  Unix

Una vez que los proyectos han sido determinados, obtener
los siguientes datos:

• Medida histórica de entrega (horas por punto
  función) de proyectos similares
• Programas históricos (duración de
  programas por punto función) de proyectos
  similares
• Costos históricos (dólares por punto
  función)

Una vez que el tamaño del proyecto se ha
determinado en puntos función, el estimado de horas, costo
y programa se puede calcular. Los cálculos se deben hacer
con datos de proyectos similares como se describió
anteriormente.

Por ejemplo, si se determina que el tamaño del
proyecto actual es de 500 puntos función y la medida de
entrega de un proyecto similar es $10 por punto función,
entonces el costo total esperado para el proyecto sería
$10 ($/punto función)  x 500 PF’s = $5,000
dólares. Pueden hacerse cálculos similares 
para programas, duración y horas.

El uso de puntos función para ayudar a
entender los costos de mantenimiento

Muchos presupuestos
de mantenimiento se establecen basados en ejecuciones de
años pasados. Muchas organizaciones tratan de reducir los
costos de mantenimiento y no planean incrementarlos año
por año para cualquier aplicación particular. Si la
nueva funcionalidad es encontrada y añadida 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 función, el crecimiento de los
costos de mantenimiento en realidad disminuye. Por ejemplo, si
una organización gasta $100,000 para mantener 10,000
puntos función o $10 por punto función, pero el
número de puntos función crece 10% a 11,000 y los
dólares de mantenimiento permanecen constantes, entonces
los costos de mantenimiento por punto función disminuye a
$9. Muchos ejecutivos de sistemas no entienden ni asimilan este
concepto.

El uso de puntos función para ayudar con
las negociaciones de contrato

Los administradores de contratos pueden usar su conocimiento
en puntos función para construir y manejar proyectos
basados en el precio por
punto función y también en la comparación 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 tamaño de puntos función y
pueden evaluar el impacto de proyectos cancelados.

Los puntos función 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 más 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 representación precisa del
esfuerzo. La estimación de este esfuerzo (en el ciclo de
vida completo) puede ocurrir sólo cuando una
métrica normalizada, tal como la provista por los puntos
función, se aplica.

Resumiendo, el análisis de puntos función
provee el mejor método objetivo para medir los proyectos
de software, y para manejar el tamaño de los proyectos de
software durante su desarrollo. Es el mejor método de
manejar el riesgo en dos
vertientes. Primero, el cliente (usuario/especificador) puede
aceptar más fácilmente el riesgo para un
determinado tamaño de proyecto de software (en puntos
función). Segundo, el desarrollador puede más
fácilmente aceptar los riesgos para
el costo de
producción (el costo por punto función).
Adherirse a un conteo consistente de puntos función
optimiza esta relación y facilita el desarrollo en
línea y bajo presupuesto.

La asignación de precios de "software externo"
(p.ej. el diseñado para uso fuera de la
organización) puede ser encauzado directamente al esfuerzo
de producción cuando se requieren métricas
funcionales. Si un desarrollador de software sabe exactamente
cuál va a ser su costo interno de desarrollo de un punto
función, se puede incorporar a los algoritmos de costeo
usados para determinar los precios externos. Sin un entendimiento
claro del tiempo y esfuerzo por punto función, la
asignación de precios a los paquetes de software
continuará siendo difícil.

El uso de puntos función para
desarrollar un estándar de establecimiento de
métricas

Por supuesto, los puntos función necesitan usarse
en asociación con las otras medidas. De hecho, los puntos
función por sí mismos proveen poco o nada de
beneficio. Muchas métricas necesitan ser reportadas al
nivel organizativo. Por ejemplo, tanto la métrica de
productividad/costo como la métrica de calidad
necesitan ser reportadas al nivel organizativo. Las
métricas de productividad/costo son usadas para demostrar
la medida y el costo de la funcionalidad que se está
entregando. Las métricas 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 métricas deben ser monitorizadas y
estudiadas en sus tendencias.

Resultados de una Experiencia en la
Determinación del Tamaño de un
Software.

La experiencia se desarrolló dentro de la
asignatura Gestión de Proyectos de Ingeniería de
Software, un electivo de quinto año de la carrera de
Ingeniería Informática en la Universidad de
Concepción. Esta experiencia consistió en un
simulacro de llamado a licitación para el desarrollo de un
producto software para una organización ficticia. La
experiencia se realizó sobre la base de una
especificación 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 tamaño del
producto, estimar costos y plazos. La mayoría de ellos
escogió la métrica puntos de función por
sobre otras (puntos de característica, líneas de
código) por las ventajas que esta métrica tiene.
Todos los alumnos manejaban la técnica de conteo de puntos
de función, y utilizaron el mismo método
(guía) 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
aplicación del método para el caso de la
estimación del tamaño del software a desarrollar. A
continuación, se presentan los resultados obtenidos en la
experiencia descrita anteriormente y una hipótesis explicativa de los
resultados.

Para presentar una respuesta a un llamado a
licitación, 13 alumnos de quinto año debieron
determinar una buena estimación del tamaño del
producto a desarrollar, eligiendo 10 de ellos la métrica
puntos de función.

Los resultados obtenidos se muestran en la tabla y
gráficos siguientes. En ellos se muestra la medida
en puntos de función obtenida por cada alumno, en un rango
de 181 a 759.

La desviación estándar de estos datos es
de aproximadamente 211 PF (Puntos de Función) sobre el
promedio, lo que es sin duda muy alto. Esta gran diferencia
condujo a estimaciones de esfuerzo y plazos drásticamente
distintas. Esto influyó directamente en la cantidad de
personal que
cada alumno asignó al proyecto y a la organización
del mismo (provocando impacto también en la función
de staffing), además de la influencia directa en los
costos y plazos. Durante el desarrollo del proyecto, las
diferencias en estas estimaciones provocarían grandes
diferencias también en la dirección, por lo que estaría
efectivamente afectando al proyecto en su conjunto, y por lo
tanto al éxito o fracaso del mismo.

Algo interesante e inesperado resultó este
cálculo dispar entre candidatos a ingenieros civiles
informáticos sobre la base de una misma
especificación de requisitos y un mismo método de
cálculo de puntos de función.

La asignación de complejidad que el método
exige para cada ítem (entrada, salida, consulta, archivo
lógico, archivo de interfaz), es un tanto subjetiva y
normalmente difiere de un desarrollador a otro, pero esto no
explicaría una desviación de tal magnitud (211
puntos de función).

La causa de estas diferencias de tamaño estimado
está en el entendimiento de qué constituye
efectivamente una salida externa, una entrada externa, un archivo
lógico interno y una consulta.

La especificación del software que fue objeto de
medición, está organizada por tipo de
información. Los reportes y consultas están
claramente especificados, mediante un diseño de formularios, pero
no así las entradas. Sólo se especifican los datos
que se deben ingresar.

De lo anterior, se puede deducir que el número de
salidas y consultas estaba más bien claro, y que la causa
de las grandes diferencias estuvo en las entradas y archivos
lógicos internos.

Para el caso de las entradas, dado que no se
especificaba cuál conjunto de datos sería ingresado
simultáneamente, algunos alumnos los agruparon
según su criterio, obteniendo un número de entradas
cercano al número de consultas y salidas, pero otros
consideraron que cada dato a ingresar constituía una
entrada, por lo que el número de entradas aumentó
en gran medida. A pesar de que la complejidad de las entradas que
involucran a más 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 lógicos internos,
algunos alumnos agruparon grandes conjuntos de
información en un archivo lógico interno, mientras
que otros modelaron la información en un esquema entidad
relación, obteniendo una aproximación mucho
más cercana a la cantidad de tablas que efectivamente
implementarían. Evidentemente, el número de
archivos lógicos internos fue mucho mayor en el segundo
caso.

Otro factor de dificultad para realizar el
cálculo del tamaño del software fue la existencia
del requisito "se debe posibilitar la capacidad de realizar
consultas no estructuradas". Este requisito fue tratado de
maneras disímiles: fue dejado fuera, considerado al
equivalente de 15 o más consultas complejas, o se
decidió que se utilizaría una interfaz a alguna
herramienta que proveyera dicha funcionalidad. Este punto
también provocó diferencias.

Otro factor importante, que se da también en los
casos reales (esta experiencia fue académica), fue la
presión
a la que estaban sujetos los participantes. Debían
entregar una propuesta de calidad dentro de los plazos, o su
castigo sería equivalente a no ganarse el proyecto: una
baja calificación, o peor aún, reprobar la
asignatura. Por otro lado, al tener el
conocimiento de que el ganador del proyecto no tendría
que desarrollarlo, podían arriesgarse a hacer
ofrecimientos interesantes y convenientes, pues no ponían
en juego su
prestigio. Este es un riesgo que normalmente no debieran correr
las empresas
proveedoras de servicios de desarrollo de software serias, las
que debieran hacer estimaciones más bien
conservadoras.

Combinación de las alternativas para la
estimación de Proyectos de Software.

Cocomo y la técnica de estimación de
puntos de función

El método 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,
  tamaño de la base de datos, complejidad del producto,
  limitaciones en el tiempo de ejecución, limitaciones de
  memoria
  principal, volatilidad de la máquina virtual, frecuencia
  de cambio en el modelo de explotación del ordenador,
  capacitación de los analistas,
  experiencia en aplicaciones, capacitación de los
  programadores, experiencia en la máquina virtual,
  experiencia en el lenguaje de
  programación, prácticas modernas de
  programación, uso de herramientas para el desarrollo del
  software y limitaciones en la planificación).

Esta técnica requiere de un dato elemental
determinado por la cantidad de sentencias de código del
proyecto a la que posteriormente se aplican diferentes algoritmos
que varían de acuerdo al modelo de desarrollo elegido
(Orgánico, Semilibre o Libre) para entallarlo finalmente
de acuerdo a factores de ajuste seleccionados a partir de las
características específicas del
proyecto.

Esta información se convierte en el aspecto
crítico del método ya que ese valor es un
parámetro difícil de determinar con exactitud y
puede variar considerablemente según las
metodologías de desarrollo utilizadas. El camino para
resolver este aspecto crítico es mediante la
aplicación de otra técnica, la de Puntos de
Función.

Figura 4: Estimación de
Proyectos por el método de Puntos de
Función

En opinión de varios autores el método de
Puntos de Función presenta un aspecto crítico en lo
referido a la reutilización de módulos
preexistentes (por ejemplo varias salidas similares que poseen
una misma estructura con variaciones propias de cada una de
ellas). En este caso el método las considera a todas
diferentes y se miden de la forma descrita anteriormente con lo
que se considera que la cantidad de puntos de función
daría una cifra superior a la real deformando el
número final con la consabida incidencia (número de
sentencias de código del software) en la aplicación
del método Cocomo.

En resumen, la utilización combinada de dos
métodos (Puntos de Función y Cocomo) tienden a
proporcionar una estimación más precisa
tratándolos de la siguiente forma:

Primero la aplicación del método de Puntos
de Función para determinar las sentencias de código
del proyecto software, la cual mantiene una distorsión,
producida por no considerar esta técnica la
reutilización de módulos preexistentes.

En segundo lugar la aplicación del método
Cocomo partiendo de la información producida por el
anterior (sentencias de código) para llegar a una
estimación precisa de las horas hombre a aplicar y
fundamentalmente a la estimación de la duración
total del proyecto.

Finalmente y basándonos en que el paradigma de
objetos considera la reusabilidad como un factor básico y
entendiendo que el método descripto (Puntos de
Función) pareciera no tomar en cuenta estas
características, queda planteado a partir del presente
trabajo, una línea de investigación tendiente a analizar la
incidencia de las metodologías orientadas a objetos en
esta técnica de estimación a fin de elaborar los
factores de ajuste necesarios para reducir la distorsión
provocada.

Los casos de uso y la técnica de
estimación de puntos de función

Los casos de uso fueron introducidos en 1987 como una
herramienta de la técnica Objetory. Su utilización
en los procesos de Ingeniería de Software fue propuesta
por Ivar Jacobson y publicada en su libro Object
Oriented Software Engineering. Actualmente, su empleo se ha
extendido aún más, debido a su inclusión en
UML, por lo
que su uso en el desarrollo de software orientado a objetos se ha
vuelto altamente recomendable, y obligatorio. David Longstreet,
en uno de sus artículos, señala que el
análisis de puntos de función se puede aplicar de
manera sencilla con los casos de uso mejorando la calidad de los
documentos de requerimientos y, a la vez, mejorando la
estimación del proyecto de software. El aplicar la
técnica de puntos de función permite verificar y
validar el contenido de un documento de especificación de
Requisitos de software. Lo interesante de la aplicación de
ambas técnicas es que se puede actualizar el conteo de los
puntos de función cada vez que los casos de uso cambien y,
de esta manera, determinar el impacto que un caso de uso
específico puede producir en la estimación del
desarrollo de todo el proyecto.

Conclusiones

Puede concluirse, entonces, que el tiempo total de
duración de un proyecto está relacionado con las
características propias del mismo y no depende
directamente del lenguaje de implementación del
diseño como así tampoco de la cantidad de personal
a utilizar, sino que esta última es una consecuencia
directa de los dos valores estimados por el
método.

Para realizar la planificación de un proyecto
software, es necesario poseer una estimación certera del
esfuerzo necesario para el desarrollo lo más temprano
posible, idealmente, con sólo la etapa de
especificación de requisitos cubierta. De más
está decir que sin la especificación de requisitos
cualquier estimación será en la más completa
incertidumbre, pues cómo estimar el costo de realizar algo
que desconocemos? A esta altura del desarrollo del software,
difícilmente se puede realizar una estimación
certera de la cantidad de líneas de código que
tendrá la aplicación, ya que en este nivel no tiene
por qué estar decidida la herramienta de desarrollo y la
cantidad de líneas de código que serán
necesarias para implementar una función del software
dependen fuertemente del programador y la herramienta de
desarrollo.

Por otra parte, los puntos de función pueden ser
estimados con mayor certeza a partir de una buena
especificación de requisitos (aunque no con toda la
certeza deseada). Lamentablemente, cuando los proyectos se
plantean sobre la base de especificaciones vagas o inexistentes,
es muy poco lo que se puede hacer. La técnica de
estimación de proyectos Puntos de Función es muy
útil pero se deben tener en cuenta varios aspectos antes
de ponerla en práctica con el objetivo de lograr un
resultado lo más cercano posible a la realidad.

El Punto Función es una medida del tamaño
de un sistema de software y del proyecto que lo construye. Es una
unidad de medida así como la hora lo es para medir el
tiempo o el kilómetro para medir la distancia. El
Análisis de Punto Función se basa en la teoría
de que las funciones de una aplicación son la mejor medida
del tamaño de un sistema. El Punto Función mide el
software mediante la cuantificación de la funcionalidad
que el sistema le brinda al usuario basado fundamentalmente en el
diseño lógico. Es independiente del lenguaje de
computación, de la metodología de desarrollo, de la
tecnología utilizada y de la capacidad del equipo de
trabajo para desarrollar la aplicación.

El Análisis del Punto Función es un
método estándar de medición de desarrollo de
software desde el punto de vista del usuario. La cuenta de Punto
Función para proyectos de desarrollo mide las
funcionalidades que se le proporcionan al usuario conjuntamente
con la primera instalación del software producido cuando
el proyecto es terminado.

El método de cálculo por puntos de
función es subjetivo y puede arrojar resultados diversos
dependiendo de quién ejecute el método. Para
realizar el cálculo de los puntos de función debe
existir un consenso dentro de la organización para el
tratamiento de los requisitos que no se ajustan al método,
además de realizar un pre diseño para que este
tamaño sea una buena estimación del tamaño
real de la aplicación. Por otra parte, se deben manejar
aspectos como la re estimación del tamaño cada vez
que se va teniendo mayor conocimiento del producto, esto es, una
vez que se va avanzando dentro del desarrollo.

Requiere una dedicación adicional en los
proyectos de desarrollo de software, que suelen desenvolverse con
presupuestos ajustados. Su implantación en una
organización no acostumbrada a su uso suele resultar
penosa y requerir un fuerte compromiso de la dirección.
Suele ser vista por los desarrolladores como un mecanismo de
control de su trabajo.

Otros aspectos negativos serían:

• Resulta arduo formar al personal en su
  utilización y más todavía mantener unos
  criterios homogéneos de recuento.
• Carece de precisión cuando se trata de
  proyectos pequeños. Por debajo de unos 100 pf resulta
  demasiado poco fiable.
• Para resultar realmente útil, una
  organización de desarrollo y mantenimiento de software
  debe tener recontada la mayor parte de su base instalada, pero
  hacerlo resulta muy costoso especialmente si mantiene software
  adquirido a terceros.
• El factor de ajuste calculado a partir de las
  características generales del sistema resulta de dudosa
  utilidad.

Si bien el mismo es criticado por no ser aplicable a
todos los sistemas, el tamaño de la gran mayoría de
los sistemas del mercado puede ser
estimado utilizando esta técnica. En general, la
mayoría de las soluciones
alternativas que se proponen se basan en esta técnica de
Albrecht, modificando ligeramente algunos aspectos o
incorporándole algún nuevo elemento a estos cinco
identificados.

Bibliografía

[Albrecht, 1979] Albrecht, Allan J. 1979. Measuring
Aplication Development Productivity. Proc Of IBM applications.
Development Joint SHARE/GUIDE Symposium, Monterrey,
Páginas 83-92.

[Jones, 1987]. Jones, C. 1987. A Short History of
Function Points and Feature Points. Software Productivity
Research Inc. USA.

[Symons, 1998]. Symons, Charles R. 1998. Function Point
Analysis Difficulties and

Improvements. IEEE Transactions on Software Engineering.
Páginas 2-11.

[Whitmire, 1992]. Whitmire, Scott A. 1992. 3D Function
Points: Scientific and Real-Time Extensions to Function Points.
Pacific Nothwest Software Quality Conference.

[Abran A., et al., 1998]. Abran, A.; Desharnais
J. M.; Maya M.; St-Pierre D.; Bourque P. 1998. Design of a
Functional size Measurement for Real-Time Software. Research
Report N° 13.Software Engineering Management Research
Laboratory, Universite du Québec a Montreal, Canada.

[Pressman, 1998]. Pressman, Roger S 1998.
Ingeniería del Software. Un Enfoque Práctico.
Cuarta Edición. 581 páginas. Editorial Mc
Graw-Hill. ISBN 84-481-1186-9.

Pressman R.S, Ingeniería del Software. Un enfoque
práctico. Mc Grow Hill. 1994

Symons, Charles R. 1998. Function Point Análisis
Difficulties and Improvements. IEEE Transactions on Software
Engineering.

International Function Point users Group. Function
Point Counting Practices Manual. Release 4.0.
1994.

Sobre los Autores:

Elsydania López Guerra. Estudiante de cuarto año de Universidad de las
Ciencias
Informáticas. Ciudad de la Habana, Cuba.

Yulia Fustiel Alvarez. Estudiante de cuarto año de Universidad de las
Ciencias Informáticas. Ciudad de la Habana,
Cuba.

Abdiel Matos Nieto.
Estudiante de cuarto año de Universidad de las Ciencias
Informáticas. Ciudad de la Habana, Cuba.

Abdel Pérez
López. Estudiante de
cuarto año de Universidad de las Ciencias
Informáticas. Ciudad de la Habana, Cuba.

Cuba, Ciudad de la Habana, diciembre de
2007.

Elsydania Lopez Guerra