UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

Calculador de puntos de función y COCOMO

Generalidades del proyecto
Carlos Valdez 200217159
Jorge Yass 200413054
Gustavo Ayapan 200412831
Adie Juárez 200412978

08/01/2009

This article shows the general on the planning, development and launch of an application able to
calculate and estimate costs, resources and time of software projects. The main idea is to automate
manual processes and calculations that involve some risk of not being accurate. Thus, the program
becomes a useful tool for systems analyst, and the general professional to make estimates.
 1. Introducción 3. Estimaciones de recursos y costos

En la actualidad, se hace de imprescindible Utilizando el método de puntos de función, se

importancia la estimación del tiempo de
desarrollo de un proyecto, porque una mala
planificación de este tiempo, puede conllevar a
presentarle fechas apresuradas a los clientes y
por tanto a entregar un software que no tendría
la calidad deseada ni mínima a cumplir. En el
ámbito de desarrollo de software, existen
métodos para estimar dicho tiempo y recursos,
algunos empíricos, además de algunos métodos
más objetivos.
La técnica más utilizada actualmente es la de
Puntos de Función (es un método empírico), esta
consiste en utilizar registros de proyectos
anteriores, para tratar de hacer una proyección
del proyecto actual en cuestión de tiempo y
gastos. Sin embargo el cálculo por esta técnica
es muy tediosa sobre todo cuando se tienen
grandes registros o estos son demasiados.
Nuestro proyecto titulado PFCalculator, pretende
reducir ampliamente el tiempo invertido en esto,
simplificando en gran manera el proceso,
resumiendo a ingresar algunos de los
parámetros utilizados en el cálculo de puntos de
función. Sin embargo, los puntos de función, por
si solos, no nos dan mayor información. Es
necesario utilizarlos en combinación con otros
métodos de estimación, como COCOMO, el cual
nos permite estimar el esfuerzo, tiempo y
personal necesario para realizar un proyecto,
basándose en los puntos de función. Es por ello
que nuestro programa también puede hacer
estimaciones utilizando COCOMO, lo que le da un
matiz de herramienta indispensable al analista
de sistemas.
realizo un cálculo (someramente temprano)
sobre la estimación de puntos de función
ajustados que nos llevaría el proyecto, para
luego, estimar el esfuerzo, tiempo y tamaño del
equipo para desarrollarlo. Dicha estimación nos
dio un resultado de 335 puntos de función
.
A continuación, se uso el modelo orgánico y la
versión básica de COCOMO para estimar el
esfuerzo requerido (se eligieron porque el
proyecto es pequeño, y no tiene una complejidad
alta) y nos dio un resultado (en meses) de 9
aproximadamente. Este dato fue tomado como
erróneo por un margen muy alto, ya que elegimos
utilizar TIMEBOXES de una semana, y la entrega
del proyecto se acordó en 3 semanas (2
originalmente) por lo que el desarrollo no iba a
tomar ni siquiera un mes. Luego, se estimo el
tamaño del equipo, aquí el método nos dio un
resultado de 3.22, el dato fue tomado como 4, lo
que estuvo bastante bien, dado que en el equipo
de desarrollo habíamos 4 personas.
En resumen, sabíamos que por los TIMEBOXES
teníamos que entregar el proyecto en 3
semanas, pero se hicieron las estimaciones
correspondientes para tenerlas como referencia.
Sin duda, la elección de la versión Detallada de
COCOMO nos hubiera presentado un tiempo más
ajustado a la realidad.

2. Descripción de la aplicación

Este es un software que estima los puntos de

función para los módulos de un proyecto, que
puede almacenar dichos módulos por proyecto, y
que puede almacenar los puntos de función de
cada módulo. Además, permite que se guarde
información adicional y futura sobre los módulos,
como por ejemplo, el tiempo de desarrollo, de
corrección de fallas, etc. También, permite en
base a los puntos de función, estimar mediante
el modelo constructivo de costos (COCOMO) el
esfuerzo requerido en meses/hombre, el tiempo
de desarrollo en meses, y el tamaño del equipo
que se necesitaría para realizar el proyecto.
 4. Estimación de Riesgos

Elemento Riesgo Probabilidad Indicadores Categoría PSGR

de Control
Análisis Mal diseño del 45% 2 Realizar un buen
cronograma de estudio de las
actividades historia de usuario
y capacidades del
equipo de
desarrollo.
Desarrollo Incumplimiento de 40% Trabajo atrasado 2 Mediante las
los tiempos de durante el desarrollo reuniones diarias
entregas de la iteración. se determina el
establecidas. estado de la
iteración, y de
algún modo
acelerar el ritmo
de trabajo sin
comprometer la
calidad del
producto.
Desarrollo Mal diseño de la 25% Almacenamiento o Evaluar las
base de datos consulta de datos con posibles consultas
cierto grado de que se realizaran
dificultad. en la aplicación.
Desarrollo Mala integración de 20% 3 Se realizaran
los módulos con la pruebas para
base de datos verificar la
conexión y el
manejo de los
datos antes de
pasar a
producción.
Cualquier Mala comunicación 50% El proceso de 2 Incentivar al
fase entre el equipo de codificación puede no equipo de
desarrollo tener mayor avance. desarrollo para
que exponga sus
dudas.
Análisis Mal entendimiento 60% No se obtiene las 2 Permitir una
de los salidas esperadas comunicación
requerimientos mayor y fluida
entre el equipo y el
cliente.
 El siguiente es el diagrama entidad relación
5. Requerimientos utilizado en la base de datos:

Los requerimientos en base a la metodología que

utilizamos que fue XP, los obtuvimos por medio
de las historias de usuario, entre los
requerimientos de más peso tenemos:

La aplicación debe trabajar en base a

resultados de SAPF y CP y debe de ser
capaz de calcular puntos de función
ajustados (PFA).
Se requiere almacenamiento de los
resultados obtenidos.
Se requiere almacenamiento de datos
adicionales a las PFA, tales como horas
de desarrollo, numero de fallas, etc.
Se requiere que la aplicación pueda
realizar estimaciones en base a COCOMO.
Se requiere que la aplicación sea intuitiva,
sencilla de utilizar, y lo más importante,
exacta en los cálculos que realice. 7. Metodología
Requerimientos como los FURPS son
deseables, pero no críticos, exceptuando Para el desarrollo del proyecto “Calculador de
quizá la confiabilidad, como ya lo puntos de función y COCOMO” se decidió utilizar
mencionamos. la metodología de desarrollo ágil XP, por las
siguientes razones (considerando que no
tenemos mucho tiempo):
6. Arquitectura
Diagrama de clases: Busca la sencillez y simplicidad
Permite iteraciones rápidas a través del
uso de los spikes
Se programa en parejas
Permite una comunicación total
La documentación no es exhaustiva
Nuestro equipo de trabajo es pequeño (4
programadores)
La fecha de entrega es fija (08/01/2009)
Los requerimientos no están
completamente claros, y algunos se
modifican a través del desarrollo.

8. Iteraciones
Iteración 1 – Cálculo de PFA: Todo lo relativo a
las fórmulas, maneras de ingreso de datos y
cálculos de puntos de función.

Diseño de interfaz
Diseño de algoritmo de cálculo de los
SAPF
Implementación del algoritmo
Prueba de funcionalidad
Iteración 2 – Almacenamiento y Consulta:
conlleva el diseño e implementación de una
pequeña base de datos, métodos para Segundo prototipo
almacenar y consultas.

Diseño o modificación de alguna interfaz

ya hecha
Diseño de un modelo relacional
Implementación del modelo relacional en
una base de datos
Implementación de métodos para
almacenar la información

Iteración 3 – Estimaciones con COCOMO:

implementación de versiones y modelos, con sus
ajustadores y formulas correspondientes.

Interfaces de selección de versiones y

modelos de COCOMO
Diseño del algoritmo de COCOMO
Implementación del algoritmo de COCOM

Evolución del prototipo

Primer prototipo

Prototipo Final

9. Pruebas
Se realizaron pruebas de funcionalidad, al
término de cada iteración para comprobar que
los cálculos eran realizados exactamente y que
se seguía de manera fiel los métodos de
estimación utilizados.
10. Discusiones
La aplicación queda como base para un
posterior proyecto que gestione de
manera completa la estimación de los
proyectos de software, ofreciendo
variadas técnicas y métodos, para que
con semejante abanico de posibilidades,
el usuario (el analista de sistemas en este
caso) pueda tomar decisiones más
exactas y mejor ajustadas a la realidad,
con menos incertidumbre y más
seguridad.
Los métodos, como tales, no pueden ser
tomados como una referencia absoluta e
inamovible en cuanto a sus resultados. La
experiencia e intuición de los analistas
experimentados sigue siendo la mejor
estimación posible, sin embargo, es
bueno ayudarse teniendo una referencia
comprobada como buena a través de
cientos de proyecto de software, para la
realización de las estimaciones, y es aquí
donde entra en juego nuestra aplicación.
Conclusiones
En la actualidad es muy utilizada la
técnica de puntos de función, sin
embargo esta técnica aunque en primer
plano parece simple, en la realidad
resulta tremendamente tediosa, por lo
cual es necesario que para poder aplicar
esta técnica de manera correcta y ahorrar
tiempo se debe de automatizar el
proceso, que es el objetivo principal del
proyecto.
Aunque las técnicas de estimación son
utilizadas y a menudo producen
resultados acertados, la realidad es que
este proceso depende mucho de la
experiencia del que lo calcula, es decir
que su criterio siempre es necesario, por
lo que los métodos de estimación tienden
a ser subjetivos.
El formar parte de un equipo que se debe
de auto organizar y auto dirigir es una
experiencia nueva y enriquecedora, da la
pauta a que se puedan correr ciertos
riesgos que sabemos serán absorbidos
por el equipo entero, pero que a la larga,
nos dará experiencia sobre lo que hicimos
bien y lo que no, ayudándonos a mejorar
para los próximos proyectos que vengan.
Sobre los autores
Carlos Valdez es estudiante de 10º semestre, se
especializa en el diseño de sitios y páginas Web,
programación en Java, y se maneja con soltura
en entornos GNU/Linux. Pueden contactarlo a
través del mail darkcavs@gmail.com.
Gustavo Ayapan es estudiante de 10º semestre,
se enfoca en el desarrollo a través de productos
Microsoft, y una de sus aficiones son las redes
sociales y el chat. Pueden contactarlo a través
del mail inguss05@gmail.com.
Audie Juárez es un estudiante de 10º semestre,
aficionado a los automóviles y al diseño web, con
altos conocimientos sobre programación en
Visual Basic, GNU/Linux, etc. Pueden contactarlo
por el mail audie_rene@hotmail.com.
Jorge Yass es estudiante de 10º semestre, es
aficionado a jugar ajedrez y a programar, su
lenguaje favorito es Turbo Pascal y no teme que
lo tachen de obsoleto. Pueden contactarlo al mail
jylatin@gmail.com.
Referencias y material consultado
Guía sobre la elaboración de un artículo
de proyectos de software. Ing. Luis Espino.
Contenido de la clase magistral y
laboratorio del curso de Software
Avanzado, escuela de vacaciones
Diciembre 2008. Ing. Luis Espino y Aux.
Mario Bautista.
Pressman, Roger. S. Ingeniería del
Software, McGraw Hill, 6ta edición.