EstimacionPorPCUyPF v.1

Estimacin por puntos de casos de uso y
por puntos de funcin
Versin 1.0
Hoja 1 de 57
Solus S.A. Av. San Martn 1351 pisos 1 y 5 - (M5500ABA) Mendoza Argentina
Tel./fax: +54 261 429-4115 http://www.solus.com.ar
ndice
1. INTRODUCCIN........................................................................... 3
2. ASPECTOS NECESARIOS EN LA ESTIMACIN............................... 4
3. MTODOS DE ESTIMACIN ......................................................... 7
4. MTODO DE ESTIMACIN POR PUNTOS DE CASOS DE USO ....... 10
5. MTODO DE ESTIMACIN POR PUNTOS DE FUNCIN................ 16
6. AJUSTE DEL MTODO DE ESTIMACIN POR PUNTOS DE FUNCIN

PARA LA ETAPA DE MANTENIMIENTO ............................................ 27
7. REDUCCIN DE LOS DESVOS EN LAS ESTIMACIONES .............. 29
8. UNIFICACIN DE LAS BASES DE ESTIMACIN PARA PUNTOS DE

CASOS DE USO Y PUNTOS DE FUNCIN ......................................... 50
9. DATOS ESTNDARES DE REFERENCIA ....................................... 54
10. GLOSARIO ............................................................................... 56
Hoja 2 de 57
1. Introduccin
Al estimar es fundamental tener en cuenta dos cuestiones:
en qu momento se realizar la estimacin

con qu informacin se cuenta en ese momento para poder estimar
Desde el punto de vista del momento de la estimacin, en el desarrollo de

software existen dos grandes momentos:
antes de comenzar un proyecto, por lo que se debe estimar el

proyecto entero
cuando se est en etapa de mantenimiento (proyecto terminado) y se
deben estimar pequeos cambios
La informacin con que se cuenta en cada uno de estos momentos nos

permitir utilizar tcnicas diferentes de estimacin, ms adecuadas y por
consiguiente ms precisas en cada uno de esos momentos, a saber:
antes de comenzar un proyecto slo hay casos de uso (no hay

cdigo, ni tablas, ni interfaces)
en la etapa de mantenimiento ya hay cdigo, tablas, interfaces y
generalmente los cambios son pequeos (las funcionalidades no
alcanzan a conformar un caso de uso); adems es ms preciso
estimar sobre elementos concretos (tablas, interfaces) que sobre
elementos planificados (casos de uso)
Por este motivo ser necesario emplear las dos tcnicas de estimacin, por
puntos de casos de uso y por puntos de funcin. A lo largo de este
documento explicaremos cmo emplear ambas tcnicas en forma
combinada segn el momento de la estimacin.
El documento, en cuanto a su contenido y redaccin, ms la adaptacin de

las reglas de estimacin por puntos de casos de uso y la combinacin de
este mtodo con el de puntos de funcin, fue elaborado por Fernando
Pinciroli, presidente de la empresa Solus S.A. de Argentina.
Las reglas de estimacin por puntos de funcin descritas en este documento

estn basadas en el Manual de Prcticas de Estimacin por Puntos de
Funcin, release 3.3, publicado por el International Function Point Users
Group (IFPUG) y adaptadas por Carlos Simes, de la empresa Synapsis
Soluoes e Servios IT de Brasil.
Hoja 3 de 57
2. Aspectos necesarios en la estimacin
A continuacin establecemos los aspectos que se deben considerar junto
con la estimacin y que son esenciales para poder estimar correctamente.
Sin ellos, la estimacin prcticamente carece de sentido.
a. Medir (si no se mide no tiene sentido estimar!)

Cuando un estima est realizando una prediccin. Si no verifica si la
prediccin se cumple o no, entonces no se sabe si se puede confiar en
esa supuesta capacidad de prediccin.
Por lo tanto, antes de empezar a estimar hay que comenzar a

establecer procesos de medicin. Estas mediciones servirn para
muchos aspectos que profundizaremos detallaremos luego:
para verificar si la estimacin fue correcta

para detectar las oportunidades de mejora
para calibrar los mtodos de estimacin
para obtener bases de datos estadsticas de las
caractersticas de la organizacin que permitan impactar en
los mtodos de estimacin
para determinar si los desvos son a causa de la estimacin,
de la ejecucin de las actividades estimadas, o de ambas
b. Estimar objetivamente
Aun cuando los mtodos de estimacin proponen un procedimiento
detallado, en muchas partes de estos mtodos es necesario aplicar el
juicio humano. En estos puntos se pone subjetividad a los mtodos y
luego no se sabr si los desvos son por los mtodos o por el juicio
humano subjetivo aportado.
Por esta razn se deben establecer todos los criterios que

razonablemente logren disminuir el impacto de la subjetividad
humana.
Hoja 4 de 57
c. Estimar uniformemente
Suponiendo que se logr estimar en forma objetiva, ahora resta
lograr que siempre se estime del mismo modo, dado que as ser
posible comparar las estimaciones y, luego de estimar varias veces,
sacar las conclusiones que permitan calibrar los mtodos de
estimacin empleados.
La uniformidad se logra de varios modos, cosa que tambin

detallaremos luego en el documento:
aplicando siempre el mismo mtodo

minimizando los puntos en los que se calibran los mtodos
logrando que las estimaciones por casos de uso y por
puntos de funcin se realicen sobre las mismas bases
d. Calibrar
Una vez logrado todo lo anterior, tras la aplicacin de estos mtodos
varias veces (normalmente se habla de al menos tres veces), con la
informacin obtenida con las mediciones y tras un anlisis adecuado
de los resultados obtenidos, se debern calibrar los mtodos para
ajustarlos a las caractersticas de la organizacin y a la naturaleza de
sus proyectos.
e. Combinar mtodos
Se deben emplear otros mtodos de estimacin complementarios
hasta tanto se est seguro de que las estimaciones con estos
mtodos son adecuadas, mxime cuando esos otros mtodos
complementarios se estaban utilizando desde antes.
f. Estimar por mdulos

Es conveniente que, ms all de que se obtenga una estimacin final
para el proyecto completo, la estimacin se detalle por mdulo. As
ser posible en el futuro determinar las diferencias que pudieran
haber habido en las estimaciones en funcin de las mediciones
realizadas y las dificultades encontradas en los diferentes mdulos.
Hoja 5 de 57
g. Reestimar a lo largo del proyecto
Las estimaciones se deberan repetir a lo largo del proyecto de modo
de, adems de continuar controlando el proyecto, poder ir
aprendiendo a partir de las diferencias halladas en cada estimacin.
Hoja 6 de 57
3. Mtodos de estimacin
Los mtodos de estimacin por puntos de casos de uso y por puntos de
funcin son muy semejantes. La diferencia radica en sobre qu bases se
estima, que sern casos de uso en el primer mtodo y elementos fsicos del
software en el segundo.
A continuacin describimos los pasos de la estimacin de ambos mtodos a

fin de entender hasta qu punto son semejantes.
En la seccin 4 de este documento volveremos a repetir este proceso en

forma detallada para la estimacin por puntos de casos de uso y en el punto
5 haremos lo propio con la estimacin por puntos de funcin.
A. Estimar el tamao del software a construir
Paso #1: obtener los puntos no ajustados

En cualquiera de los mtodos, los requisitos estn materializados en
casos de uso en uno de los mtodos o en la cantidad de elementos a
crear o modificar en el otro.
Por lo tanto, el primer paso consistir en obtener una primera medida

del tamao de la aplicacin, que por el momento llamamos sin
ajustar hasta tanto consideremos otros factores de importancia.
As, hacemos una sumatoria de los puntos de cada elemento a

considerar, puntaje que es directamente proporcional a la
complejidad de los elementos.
Esta sumatoria se llamar Puntos de Casos de Uso no Ajustados y

Puntos de Funcin no Ajustados segn sea el mtodo.
Paso #2: obtener los factores de complejidad

tcnica
Adems de los requisitos especficos del dominio del problema,
muchas veces encontramos otros requisitos adicionales y globales de
Hoja 7 de 57
la aplicacin, como por ejemplo la necesidad de portabilidad, facilidad
de uso, etc.
En la medida en que haya ms cantidad de estos requisitos globales,

el tamao del software a construir aumentar. Por esta razn
haremos una nueva sumatoria de la influencia que le asignamos a
cada uno de estos factores, a los que se denomina factores de
complejidad tcnica (en adelante FCT).
Es importante tener en cuenta que para cumplir con el objetivo

mencionado en el punto 2.c Estimar uniformemente, en particular
haciendo que las estimaciones por puntos de casos de uso y por
puntos de funcin se hagan sobre las mismas bases es que tuvimos
que unificar los factores de complejidad tcnica que se utilizan en
ambos mtodos. Estos ajustes y sus correspondientes fundamentos
se pueden encontrar en la seccin 8 de este documento.
Paso #3: estimar el tamao del software

Finalmente se multiplican los puntos no ajustados por los FCT y se
obtienen los puntos de casos de uso ajustados al tamao o los
puntos de funcin ajustados al tamao, que corresponden al
tamao objetivo del software a desarrollar.
B. Estimar el esfuerzo de construir el software

ambiental
Sin lugar a dudas un software con un tamao en particular ser
desarrollado con ms rapidez y eficiencia por un equipo de trabajo de
determinadas caractersticas que por otro de caractersticas
diferentes.
Por esta razn es que se deben calcular estas caractersticas

especficas del equipo de trabajo y que se denominan factores de
complejidad ambiental (en adelante FCA).
Hoja 8 de 57
Al igual que con los FCT, se har la sumatoria de la influencia que le
asignamos a cada uno de estos factores de FCA.
Paso #5: estimar el esfuerzo de desarrollar el

software
Slo se deben multiplicar los puntos ajustados al tamao por los FCA
y se obtienen los puntos de casos de uso ajustados al esfuerzo o los
puntos de funcin ajustados al esfuerzo, que corresponden al
esfuerzo objetivo que demandar desarrollar el software.
C. Traducir el esfuerzo en horas y dinero
Paso #6: obtener las horas de desarrollo

Los puntos finalmente ajustados se multiplican por un multiplicador
de horas, que no es otra cosa que el valor de a cuntas horas
equivale un punto de casos de uso o un punto de funcin.
El total es el total de horas del desarrollo del software.
Paso #7: obtener el costo del desarrollo

Se calcula el costo de las horas totales en funcin de la duracin que
se le quiere dar al desarrollo y de la cantidad y calidad de los recursos
humanos que se asignen para cumplir el desarrollo en ese tiempo.
Hoja 9 de 57
4. Mtodo de estimacin por puntos de
casos de uso
Este mtodo fue elaborado por Gustav Karner en 1993, por lo que tambin
se lo conoce como mtodo de Karner, cuando trabajaba en la empresa
Ericsson, bajo la supervisin de Ivar Jacobson, el creador de la tcnica de
casos de uso
El mtodo viene siendo utilizado por numerosas empresas, entre ellas Sun e
IBM, con resultados muy satisfactorios
Se emplea tempranamente en el ciclo de vida del desarrollo de software,

con la lista de casos de uso del sistema pero antes de que los casos de uso
sean escritos en forma detallada
A continuacin describiremos en detalle los siete pasos del mtodo

mencionados en el punto anterior pero adaptados a este mtodo en
particular.
Paso #1: obtener los puntos de casos de uso no

ajustados
Los elementos a medir son los casos de uso y los actores. Ambos se
clasifican en tres tipos segn su complejidad.
casos de uso de complejidad baja

casos de uso de complejidad media
casos de uso de complejidad alta
actores de complejidad baja

actores de complejidad media
actores de complejidad alta
La complejidad de los casos de uso se establece en funcin de la

cantidad de escenarios clave que contenga cada caso de uso,
mientras que la de los actores es funcin del tipo de actor.
caso de uso de complejidad baja: menos de 4 escenarios

caso de uso de complejidad media: entre 4 y 7 escenarios
Hoja 10 de 57
caso de uso de complejidad alta: ms de 7 escenarios
actores de complejidad baja: llamadas a API

actores de complejidad media: interaccin con otros
sistemas
actores de complejidad alta: actores humanos
A cada uno de los tipos se les asigna una cantidad de puntos de casos
de uso no ajustados.
caso de uso de complejidad baja: 5 puntos

caso de uso de complejidad media: 10 puntos
caso de uso de complejidad alta: 15 puntos
actores de complejidad baja: 1 punto

actores de complejidad media: 2 puntos
actores de complejidad alta: 3 puntos
Por ltimo se multiplica la cantidad de puntos por la cantidad de

casos de uso, actores y complejidad segn corresponda y la
sumatoria final es el nmero de Puntos de Casos de Uso no
Ajustados.
Paso 2: obtener los factores de complejidad

tcnica
Existe una serie de factores a considerar y que se pueden observar en
la tabla 1. Estos factores tienen un peso relativo entre s, que se
describe en la columna Peso.
Lo que se debe realizar es la asignacin a cada uno de estos factores

de un valor entero en la escala de 0 a 5, en donde 0 significa no es
significativo y 5 es muy significativo, en funcin de cunto se
considere que ese factor es aplicable al software a desarrollar. Este
valor se encuentra, justamente, en la columna Valor de la tabla 1.
Por ltimo se multiplica el peso de cada factor por el valor que se le

asign y se realiza la sumatoria de todos los productos, resultado al
que se lo denomina Factor de Complejidad Tcnica no Ajustado.
Hoja 11 de 57
Tabla 1: clculo de FCT
Factor Peso Valor Producto

FCT01 Sistema distribuido 2,0 5 10
FCT02 Objetivos de rendimiento 1,0 4 4
FCT03 Eficiencia para el usuario final 1,0 2 2
FCT04 Procesamiento interno complejo 1,0 4 4
FCT05 Cdigo reutilizable 1,0 2 2
FCT06 Facilidad de instalacin 0,5 5 2,5
FCT07 Facilidad de uso 0,5 3 1,5
FCT08 Portabilidad 2,0 3 6
FCT09 Facilidad de cambio 1,0 3 3
FCT10 Volumen de transacciones y
1,5 2 3
concurrencia
FCT11 Caractersticas especiales de
1,5 2 3
equipamiento y seguridad
FCT12 Comunicacin de datos 1,0 5 5
FCT13 Acceso directo de terceras partes 1,5 3 4,5
Factor de Complejidad Tcnica no Ajustado (FCTnoA): 50,5
Este valor resultante se ajusta segn la siguiente frmula
FCT = 0,6125 + (0,01 * FCTnoA)
y as se obtiene el Factor de Complejidad Tcnica del desarrollo a

realizarse.
Es importante tener en cuenta que en caso de variarse alguno de los

parmetros fijos de la tabla (cantidad de factores o peso), se debe
ajustar la frmula de modo que si le asignramos a todos los factores
un valor de 2,5 el resultado de la frmula d un FCT = 1.
Los criterios para asignar los valores se encuentran en el punto 7.b de

este documento.
Recurdese que para cumplir con el objetivo mencionado en el punto

2.c Estimar uniformemente, en particular haciendo que las
estimaciones por puntos de casos de uso y por puntos de funcin se
hagan sobre las mismas bases es que tuvimos que unificar los
Hoja 12 de 57
factores de complejidad tcnica que se utilizan en ambos mtodos.
Estos ajustes y sus correspondientes fundamentos se pueden
encontrar en la seccin 8 de este documento.

Se multiplican los Puntos de Casos de Uso no Ajustados por los FCT
y se obtienen los Puntos de Casos de Uso Ajustados al Tamao, que
corresponden al tamao objetivo del software a desarrollar.

ambiental
Los factores ambientales a considerar se pueden observar en la tabla
2. Tambin estos factores tienen un peso relativo entre s y se les
debe asignar un valor entero en la escala de 0 a 5, en donde 0
significa no es significativo y 5 es muy significativo, en funcin de
cunto se considere que ese factor es aplicable al software a
desarrollar.
Luego se multiplica el peso de cada factor por el valor que se le

que se lo denomina Factor de Complejidad Ambiental no Ajustado.
Tabla 2: clculo de FCA

FCA01 Familiaridad con el proceso 1,5 4 6
FCA02 Experiencia en el dominio del
0,5 3 1,5
problema
FCA03 Experiencia en orientacin a objetos 1,0 4 4
FCA04 Capacidad del analista lder 0,5 4 2
FCA05 Motivacin 1,0 3 3
FCA06 Requisitos estables 2,0 4 8
FCA07 Recursos humanos part-time -1,0 0 0
Hoja 13 de 57
FCT08 Dificultad del lenguaje de
-1,0 3 3
programacin
Factor de Complejidad Ambiental no Ajustado
21,5
(FCAnoA):
FCA = 1,338 + (-0,03 * FCAnoA)
y as se obtiene el Factor de Complejidad Ambiental del desarrollo a

realizarse.
En caso de variarse alguno de los parmetros fijos de la tabla

(cantidad de factores o peso), tambin se debe ajustar la frmula de
modo que si le asignramos a todos los factores un valor de 2,5 el
resultado de la frmula d un FCA = 1.

este documento.

software
Se deben multiplicar los Puntos de Casos de Uso Ajustados al
Tamao por los FCA y se obtienen los Puntos de Casos de Uso
Ajustados al Esfuerzo, que corresponden al esfuerzo objetivo que
demandar desarrollar el software.

La equivalencia de horas por cada punto de caso de uso se establece
teniendo en cuenta que si hay pocos factores ambientales mal
calificados o muchos mal calificados, el multiplicador de horas deber
considerar menos horas o ms horas respectivamente debido a que
en el segundo caso ser ms riesgoso desarrollar el software o, en
otras palabras, es ms probable que a ese equipo de desarrollo le
Hoja 14 de 57
demande ms esfuerzo (ms horas) desarrollar el software que a un
mejor equipo de desarrollo.
As, si la cantidad de los FCA desde FCA01 hasta FCA06 con valores
asignados menores que 3, y de FAC desde FCA07 hasta FCA08
mayores que 3 es menor o igual a 2, entonces hay que considerar el
multiplicador de horas hombre (MHH) igual a 20 horas por punto de
casos de uso.
Si la cantidad es igual a 3 a 4, entonces hay que considerar MHH =

30.
En caso de que la cantidad sea mayor que 4, se debera considerar

que afrontar con ese equipo o en esas condiciones ser tan riesgoso
que hasta incluso habra que considerar abandonarlo o no afrontarlo.

Para el clculo del costo se puede multiplicar por un precio fijo
promedio o realizar un anlisis de la cantidad de recursos humanos
por tipo que se asignarn. En este ltimo caso, la empresa Solus S.A.
provee una herramienta para calcular los costos de este modo.
Hoja 15 de 57
5. Mtodo de estimacin por puntos de
funcin
La tcnica de Anlisis por Puntos de Funcin es una tcnica de medicin de
sistemas desarrollada por Allan J. Albrecht (IBM, White Plains) en 1979.
Esta tcnica dimensiona el software calificando su funcionalidad basada en

su diseo lgico.
Es importante tener en cuenta que una funcionalidad apunta a qu debe

proveer el sistema y no cmo debe hacerlo. De este modo, como esta
tcnica se basa en la perspectiva del usuario, solamente se emplean para la
estimacin aquellos elementos del software que son visibles por el usuario.
Las reglas de estimacin por puntos de funcin descritas en este documento

estn basadas en el Manual de Prcticas de Estimacin por Puntos de
Funcin, release 3.3, publicado por el International Function Point Users
Group (IFPUG 1) y adaptadas por Carlos Simes, de la empresa Synapsis
Soluoes e Servios IT de Brasil.
Paso #1: obtener los puntos de funcin no

ajustados
Los elementos a medir son archivos, actividades de entrada, salida y
consultas, vistos desde la perspectiva del usuario:
1. Archivo lgico interno: son almacenamientos de datos

lgicamente relacionados y que son mantenidos por la
aplicacin
2. Archivo de interfaz externa: son almacenamientos de

datos lgicamente relacionados que son utilizados por la
aplicacin pero son mantenidos por otro sistema
3. Entradas externas: son las actividades que realiza el

usuario por medio de un proceso lgico nico con el objeto de
1
http://www.ifpug.org/
Hoja 16 de 57
crear, modificar o eliminar datos de los archivos lgicos
internos
4. Salidas externas: son las actividades de la aplicacin que

tienen como objetivo extraer datos de la aplicacin
5. Consultas externas: son las actividades que obtienen o

presentan datos a partir de una consulta
Todos estos elementos se clasifican en tres tipos segn su

complejidad. Veremos a continuacin la estimacin de puntos de
funcin para cada uno de los casos.
1. Archivo lgico interno
Para calcular sus puntos de funcin se considera el nmero de

registros lgicos y el nmero de tems de datos alcanzados por la
funcionalidad a desarrollar.
Un tem de datos o un campo de un archivo lgico interno es una

subdivisin de un grupo de datos lgicamente relacionados que tiene
un significado propio y puede ser identificada por el usuario.
Con respecto a los tems se debe tener en cuenta:
cuando un tem proviene de la subdivisin de un tem mayor,

slo se debe contar el tem mayor
los tems que no sean utilizados por la aplicacin no se deben
contar
los tems que se almacenan varias veces en ms de un campo
del archivo se deben contar slo una vez
los campos repetitivos idnticos en formato que existen para
permitir mltiples ocurrencias de un tem, se deben contar slo
una vez
Para calcular la complejidad, considerar:
Nmero de... tems de datos referenciados

registros lgicos 51 en
1 a 19 20 a 50
referenciados adelante
1 Baja baja media
2a5 baja media alta
Hoja 17 de 57
6 en adelante media alta alta
A cada uno de los tipos se les asigna una cantidad de puntos de

funcin no ajustados.
archivos lgicos internos de complejidad baja: 7 puntos

archivos lgicos internos de complejidad media: 10 puntos
archivos lgicos internos de complejidad alta: 15 puntos
2. Archivo de interfaz externa

registros lgicos y el nmero de tems de datos alcanzados por la

registros lgicos 51 en
1 a 19 20 a 50
1 baja Baja media
2a5 baja Media alta
6 en adelante media Alta alta

archivos de interfaz externa de complejidad baja: 7 puntos

archivos de interfaz externa de complejidad media: 10
puntos
archivos de interfaz externa de complejidad alta: 15 puntos
3. Entrada externa

archivos y el nmero de tems de datos alcanzados por la
Hoja 18 de 57
El nmero de archivos referenciados es la sumatoria del nmero de
archivos lgicos internos y de archivos de interfaz externa
actualizados o consultados por la entrada externa.
Adems de las consideraciones anteriores para los tems de datos, en

el caso de las entradas externas tambin se deben considerar:
- contar como un tem cada lnea de comando, tecla de funcin

o campo que provean al usuario la capacidad de especificar una
accin a ser tomada por la entrada externa
- contar como un tem cada campo no informados por el

usuario, pero que sea generado automticamente por la
aplicacin y que actualice un archivo lgico interno
- contar como un tem cada mensaje de error o confirmacin

asociado a un proceso de validacin de datos de entrada
externa

archivos 16 en
1a4 5 a 15
1 baja Baja media
2 baja Media alta
3 en adelante Media Alta alta

entrada externa de complejidad baja: 3 puntos

entrada externa de complejidad media: 4 puntos
entrada externa de complejidad alta: 5 puntos
4. Salida externa

archivos y el nmero de tems de datos alcanzados por la
Hoja 19 de 57
Adems de las consideraciones generales para los tems de datos, en
el caso de las entradas externas tambin se debe considerar que:
- los textos no se cuentan como tems de datos
- la fecha, la hora y los controles de paginacin no son tems

de datos
- se deben contar como tems de datos los campos que

totalizan a otros, como subtotales, o totales

archivos 20 en
1a5 6 a 19
1 Baja Baja media
23 Baja Media alta

entrada externa de complejidad baja: 4 puntos

entrada externa de complejidad media: 5 puntos
entrada externa de complejidad alta: 7 puntos
5. Consulta externa
Para calcular sus puntos de funcin se deben evaluar la parte de

entrada y de salida por separado, considerndose la mayor
complejidad que se obtenga en cualquiera de ellas.
Las complejidades funcionales de la entrada y de la salida se obtienen

a partir de la cantidad de archivos y de tems de datos referenciados
en cada una de esas etapas.
El nmero de tems referenciados en la etapa de entrada es el

nmero de parmetros provistos.
Hoja 20 de 57
El nmero de tems de la parte de salida es el total de campos
identificados por el usuario que aparecen en la consulta.
Se deben tomar las mismas consideraciones para los tems de datos

mencionadas para las salidas externas.
Para calcular la complejidad de la parte de entrada, considerar:

archivos 16 en
1a4 5 a 15
1 Baja Baja media
2 Baja Media alta
Para calcular la complejidad de la parte de salida, considerar:

archivos 20 en
1a5 6 a 19
1 Baja Baja media
23 Baja Media alta

consulta externa de complejidad baja: 3 puntos

consulta externa de complejidad media: 4 puntos
consulta externa de complejidad alta: 6 puntos
Por ltimo, se multiplica la cantidad de puntos por la cantidad de

archivos lgicos internos, archivos de interfaz externa, entradas
externas, salidas externas y consultas externas y complejidad segn
corresponda y la sumatoria final es el nmero de Puntos de Funcin
no Ajustados.

tcnica
Hoja 21 de 57
Existe una serie de factores a considerar y que se pueden observar en
la tabla 3.
Lo que se debe realizar es la asignacin a cada uno de estos factores

de un valor entero en la escala de 0 a 5, en donde 0 significa no es
significativo y 5 es muy significativo, en funcin de cunto se
considere que ese factor es aplicable al software a desarrollar. Este
valor se coloca, justamente, en la columna Valor de la tabla 1.
Por ltimo se realiza la sumatoria de todos los valores, resultado al

que se lo denomina Factor de Complejidad Tcnica no Ajustado.
Tabla 3: clculo de FCT para puntos de funcin
Factor Valor
FCT01 Sistema distribuido 5
FCT02 Objetivos de rendimiento 4
FCT03 Eficiencia para el usuario final 2
FCT04 Procesamiento interno complejo 4
FCT05 Cdigo reutilizable 2
FCT06 Facilidad de instalacin 5
FCT07 Facilidad de uso 3
FCT08 Portabilidad 3
FCT09 Facilidad de cambio 3
FCT10 Volumen de transacciones y concurrencia 2
FCT11 Caractersticas especiales de equipamiento
2
y seguridad
FCT12 Comunicacin de datos 5
FCT 13 Actualizacin en lnea 5
FCT14 Entrada de datos en lnea 3
Factor de Complejidad Tcnica no Ajustado
48
(FCTnoA):
FCT = 0,65 + (0,01 * FCTnoA)
Hoja 22 de 57
y as se obtiene el Factor de Complejidad Tcnica del desarrollo a
realizarse.
Es importante tener en cuenta que en caso de variarse los factores de

la tabla, se debe ajustar la frmula de modo que si le asignramos a
todos los factores un valor de 2,5 el resultado de la frmula d un
FCT = 1.

este documento.
Recurdese que para cumplir con el objetivo mencionado en el punto

2.c Estimar uniformemente, en particular haciendo que las
estimaciones por puntos de casos de uso y por puntos de funcin se
hagan sobre las mismas bases es que tuvimos que unificar los
factores de complejidad tcnica que se utilizan en ambos mtodos.
Estos ajustes y sus correspondientes fundamentos se pueden
encontrar en la seccin 8 de este documento.

Se multiplican los Puntos de Funcin no Ajustados por los FCT y se
obtienen los Puntos de Funcin Ajustados al Tamao, que
corresponden al tamao objetivo del software a desarrollar.

ambiental
Si bien en el mtodo de estimacin por puntos de funcin no se utiliza
el ajuste por factores de complejidad ambiental, nosotros lo
mantendremos por una razn de homogeneidad en los mtodos.
Los factores ambientales a considerar se pueden observar en la tabla

2. Tambin estos factores tienen un peso relativo entre s y se les
debe asignar un valor entero en la escala de 0 a 5, en donde 0
significa no es significativo y 5 es muy significativo, en funcin de
Hoja 23 de 57
cunto se considere que ese factor es aplicable al software a
desarrollar.
Luego se multiplica el peso de cada factor por el valor que se le

que se lo denomina Factor de Complejidad Ambiental no Ajustado.
Tabla 2: clculo de FCA

FCA01 Familiaridad con el proceso 1,5 4 6
FCA02 Experiencia en el dominio del
0,5 3 1,5
problema
FCA03 Experiencia en orientacin a objetos 1,0 4 4
FCA04 Capacidades en los analistas lderes 0,5 4 2
FCA05 Motivacin 1,0 3 3
FCA06 Requisitos estables 2,0 4 8
FCA07 Recursos humanos part-time -1,0 0 0
FCT08 Dificultad del lenguaje de
-1,0 3 3
programacin
Factor de Complejidad Ambiental no Ajustado
21,5
(FCAnoA):
FCA = 1,338 * (-0,03 * FCAnoA)
y as se obtiene el Factor de Complejidad Ambiental del desarrollo a

realizarse.
En caso de variarse alguno de los parmetros fijos de la tabla

(cantidad de factores o peso), tambin se debe ajustar la frmula de
modo que si le asignramos a todos los factores un valor de 2,5 el
resultado de la frmula d un FCA = 1.

este documento.
Hoja 24 de 57
software
Se deben multiplicar los Puntos de Funcin Ajustados al Tamao por
los FCA y se obtienen los Puntos de Funcin Ajustados al Esfuerzo,
que corresponden al esfuerzo objetivo que demandar desarrollar el
software.

La equivalencia de horas por cada punto de funcin se establece
teniendo en cuenta que si hay pocos factores ambientales mal
calificados o muchos mal calificados, el multiplicador de horas deber
considerar menos horas o ms horas respectivamente debido a que
en el segundo caso ser ms riesgoso desarrollar el software o, en
otras palabras, es ms probable que a ese equipo de desarrollo le
demande ms esfuerzo (ms horas) desarrollar el software que a un
mejor equipo de desarrollo.
As, si la cantidad de los FCA desde FCA01 hasta FCA06 con valores
asignados menores que 3, y de FAC desde FCA07 hasta FCA08
mayores que 3 es menor o igual a 2, entonces hay que considerar el
multiplicador de horas hombre (MHH) igual a 20 horas por punto de
funcin.
Si la cantidad es igual a 3 a 4, entonces hay que considerar MHH =

30.
En caso de que la cantidad sea mayor que 4, se debera considerar

que afrontar con ese equipo o en esas condiciones ser tan riesgoso
que hasta incluso habra que considerar abandonarlo o no afrontarlo.

Para el clculo del costo se puede multiplicar por un precio fijo
promedio o realizar un anlisis de la cantidad de recursos humanos
Hoja 25 de 57
por tipo que se asignarn. En este ltimo caso, la empresa Solus S.A.
provee una herramienta para calcular los costos de este modo.
Hoja 26 de 57
6. Ajuste del mtodo de estimacin por
puntos de funcin para la etapa de
mantenimiento
El clculo se debe realizar teniendo en cuenta tres elementos:
funcionalidad de la aplicacin incluida en los requerimientos del

usuario para el proyecto
funcionalidad de conversin incluida en los requerimientos del usuario
para el proyecto
factor de ajuste de valor para la aplicacin
La funcionalidad de la aplicacin consta de:
puntos de funcin identificados en la funcionalidad que se agregar

en el mantenimiento
puntos de funcin contados en las modificaciones en la funcionalidad
existente durante la etapa de mantenimiento
puntos de funcin contados para la funcionalidad excluida durante la
etapa de mantenimiento
La funcionalidad de conversin consta de los puntos de funcin debidos a

cualquier funcionalidad de conversin solicitada por el usuario.
El factor de ajuste de valor puede ser de dos tipos:
factor de ajuste de valor de la aplicacin antes del inicio de la etapa

de mantenimiento
factor de ajuste de valor de la aplicacin despus de completarse la
etapa de mantenimiento
Frmula:
PF_MANTENIMIENTO = [(PF_INCLUIDO + PF_CONVERSIN)] *

FA_ACTUAL) + (PF_EXCLUIDO * FA_ANTERIOR)
Nota: cuando se implanta un proyecto de mantenimiento/mejora, la cuenta

de los puntos de funcin se debe actualizar para reflejar los cambios en las
funcionalidades de la aplicacin.
Hoja 27 de 57
La siguiente frmula se utiliza para calcular los puntos de funcin de la
aplicacin despus del proyecto de mantenimiento/mejora:
PFA = [(PFSnoA + PFAnoA + PFCDnoA) (PFCAnoA + PFEnoA)] * FADM
Donde:
PFA es la cuenta ajustada de los puntos de funcin de la aplicacin
PFSnoA es la cuenta no ajustada de los puntos de funcin del

software antes del inicio de la etapa de mantenimiento/mejora
PFAnoA es la cuenta no ajustada de los puntos de funcin de las

funcionalidades agregadas por el mantenimiento/mejora
PFCDnoA es la cuenta no ajustada de los puntos de funcin de las

funcionalidades modificadas por el mantenimiento/mejora. Este
nmero refleja el tamao de las funcionalidades despus de los
cambios.
PFCAnoA es la cuenta no ajustada de los puntos de funcin de las

funcionalidades modificadas por el mantenimiento/mejora. Este
nmero refleja el tamao de las funcionalidades antes de los
cambios.
PFEnoA es la cuenta no ajustada de los puntos de funcin de las

funcionalidades eliminadas por el mantenimiento/mejora.
FADM es el factor de ajuste de valor de la aplicacin despus de la

finalizacin del mantenimiento/mejora.
Hoja 28 de 57
7. Reduccin de los desvos en las
estimaciones
Los desvos en las estimaciones se deben minimizar hacindolos tender a
cero. En este punto consideraremos las cuestiones que se deben tener en
cuenta para lograr estimaciones ms precisas.
a. Se debe saber exactamente qu es lo que se

mide
En el mtodo de estimacin por caso de uso se debe saber
exactamente qu es un caso de uso, cmo deben ser los actores y
qu son los escenarios clave.
En el mtodo de estimacin por punto de funcin hay que entender

correctamente los archivos, las salidas, entradas y consultas.
1. Casos de uso
Dependiendo del mtodo de escritura de los casos de uso, la

estimacin puede verse gravemente afectada, ya que el mtodo est
pensado para una forma estndar de redaccin de los casos de uso.
Por este motivo, hay que evitar escribir los casos de uso demasiado
generales o demasiado atomizados. La granularidad debe estar de
acuerdo con la definicin de caso de uso: porcin de la funcionalidad
de un sistema que provee un resultado de valor desde la perspectiva
del actor que la requiere.
En la medida en que se escriban casos de uso con un estilo diferente

al estndar, se deberan modificar los valores empleados para asignar
puntos de casos de uso segn las diferentes complejidades, pero sin
lugar a dudas que esto sera una prctica totalmente contraria a lo
que dicta la razn, porque directamente se estara inventando un
mtodo sin llevar a cabo todo lo que ello exige.
Adicionalmente se debe tener en cuenta qu hacer con los casos de

uso por inclusin, extensin y generalizacin, para lo que sugerimos
lo siguiente:
Hoja 29 de 57
Inclusin: no se deben considerar en los casos de uso base los
escenarios del caso de uso de inclusin y se debe contar a ste
slo una vez
Extensin: se debe contar cada uno de los casos de uso de
extensin
Generalizacin: no se deben contar, ya que slo se deberan
utilizar para darle ms estilo al diagrama y no para reutilizar
funcionalidad
Si bien Karner recomend no contar los casos de uso de inclusin

y extensin, hoy existe un consenso generalizado en la comunidad
internacional apoyando la postura que nosotros proponemos al
respecto.
2. Actores
Se debe recordar que los actores deben representar un rol y no una

persona fsica. Adems se debe evitar el representar a los actores
con los cargos jerrquicos de una organizacin y tampoco debe existir
el actor tiempo o usuario.
Por supuesto que lo mejor es modelar la cantidad de actores que

corresponda, pero ante la duda poner menos actores o ms, siempre
se tendr ms probabilidad de estar en lo correcto al modelar ms.
Se debe tener en cuenta qu hacer con los actores supertipo en una

generalizacin:
Actor supertipo abstracto: slo se debe contar si instancia

algn caso de uso
Actor supertipo concreto: se debe contar cada uno de ellos
3. Archivos lgicos internos
Son los requerimientos de almacenamiento cuyo mantenimiento debe

ser realizado por la propia aplicacin. Estos archivos son grupos de
datos lgicamente relacionados que son utilizados y mantenidos
dentro de los lmites de la aplicacin.
Se pueden identificar segn los siguientes criterios:
Hoja 30 de 57
son datos que se mantienen dentro de los lmites de la
aplicacin
son mantenidos por medio de un proceso patrn de la
aplicacin
el usuario los identifica como requisitos de la aplicacin
No deben ser:
archivos temporales
archivos de trabajo
archivos de clasificacin de datos
archivos para registrar transacciones de entradas externas
hasta tanto sean procesados por la aplicacin
archivos que se utilizan a causa de la tecnologa empleada
archivos de parmetros
archivos de ndices
archivos para codificacin de datos
4. Archivos lgicos externos
Son grupos de datos lgicamente relacionados o informaciones de

control especificadas por el usuario que son utilizados por la
aplicacin pero son mantenidos por otra aplicacin diferente.
Los grupos de datos lgicamente relacionados son aquellos que el

usuario percibe como que deben estar juntos para alcanzar un
resultado en particular.
Las informaciones de control son los datos que utiliza la aplicacin

para lograr la total conformidad de los requisitos del usuario con las
funciones del negocio.
son datos almacenados fuera de los lmites de la aplicacin

no sufren mantenimiento por medio de procesos de la
aplicacin
el usuario los identifica como requisitos de la aplicacin
No deben ser:
Hoja 31 de 57
datos recibidos de otras aplicaciones utilizados para agregar,
modificar o eliminar datos de un archivo lgico interno (si fuera
as, estos datos externos seran datos de transaccin y, por
consiguiente, se deberan considerar como entrada externa)
datos cuyo mantenimiento es realizado por la aplicacin y que
son accedidos por otra aplicacin diferente
datos procesados y formateados para el uso de otra aplicacin
(en este caso seran una salida externa)
5. Entrada externa
Procesan datos o informaciones de control que ingresan a travs de la

frontera de la aplicacin y por medio de un proceso lgico nico
actualizan archivos lgicos internos. Las informaciones de control
pueden o no actualizar directamente un archivo lgico interno.
Se considera que una entrada externa es nica si posee un formato

diferente o si precisa un procesamiento lgico diferente de otras
entradas externas que tengan el mismo formato.
El formato se define como el conjunto de datos ordenados en una

secuencia nica dentro de la aplicacin.
las entradas externas deben actualizar uno o ms archivos

lgicos internos
deben ser identificadas por el usuario como una funcin de
negocio o como un requisito de la aplicacin
cada actividad de mantenimiento (creacin, modificacin,
eliminacin) se debe considerar como una entrada externa
las entradas externas duplicadas (realizan la misma funcin de
negocio) se deben considerar por separado en caso de que
utilicen medios diferentes para su realizacin
No deben ser:
datos de referencia: datos externos utilizados por la aplicacin

y que no son actualizados en los archivos lgicos internos
Hoja 32 de 57
parmetros de entrada que apuntan a la recuperacin de datos
en una consulta externa (parte de la entrada de una consulta
externa)
pantallas de control de acceso a la aplicacin que no actualizan
archivos lgicos internos
pantallas que proveen funcionalidad de seleccin o navegacin
y no actualizan archivos lgicos internos
mtodos mltiples para ejecutar una misma lgica de entrada
externa
6. Salida externa
Son las actividades de la aplicacin que tienen como resultado la

salida de datos fuera de los lmites de la aplicacin.
Se considera que una salida externa es nica si posee un formato

diferente o si precisa un procesamiento lgico diferente que otras
salidas externas con el mismo formato.
son procesos que envan datos o informacin de control fuera

de los lmites de la aplicacin
deben ser identificadas por los usuarios como una funcin del
son datos residentes en los archivos lgicos internos que son
procesados o formateados para ser transferidos hacia otra
aplicacin
cada uno de los informes que provee la aplicacin
los informes idnticos que se producen en diferentes medios
deben ser considerados salidas externas diferentes, siempre y
cuando esta multiplicidad de medios sea provista por la
aplicacin
los informes en lnea que no sean parte de la salida de una
consulta externa
No deben ser:
pantallas de ayuda
mltiples formas de ejecutar una misma lgica de salida
Hoja 33 de 57
los mltiples informes que posean el mismo formato y la
misma lgica de procesamiento (se deben considerar una nica
salida externa)
los informes creados por el usuario mediante herramientas de
extraccin de datos flexibles, aun cuando estas herramientas
sean provistas por la aplicacin
informes producidos por directamente usando SQL
7. Consulta externa
Son las necesidades de recuperacin inmediata de datos de la

aplicacin. Es una combinacin de entrada y salida de datos donde
una consulta externa no posee datos derivados y no actualiza ningn
archivo lgico interno.
Se considera que una consulta externa es nica si posee un formato

diferente de otras, ya sea en la entrada o en la salida, o si precisa un
procesamiento lgico diferente de otras consultas externas an
cuando stas fueran idnticas en formato.
Los datos derivados son aquellos que requieren un procesamiento

diferente de acceso, recuperacin, totalizacin, edicin u
ordenamiento de los datos contenidos en los archivos lgicos internos
o en los archivos de interfaz externa.
una combinacin nica de entrada y salida de datos para la

aplicacin
deben ser identificadas por el usuario como una funcin del
consultas implcitas: pantallas de modificacin o eliminacin de
datos, que muestran lo que ser modificado o eliminado antes
de que la accin se haga efectiva (si las pantallas son idnticas
se debe considerar una sola consulta externa y si adems son
idnticas a la consulta propiamente dicha slo se debe
considerar la funcin de consulta como una consulta externa)
mens con consulta implcita: las pantallas de mens que
adems de permitir la seleccin de una opcin permiten
informar parmetros para realizar la consulta en la pantalla
escogida se deben considerar como la entrada de la consulta
Hoja 34 de 57
externa y la pantalla de respuesta ser la parte de salida de la
consulta externa
las pantallas de seleccin de informes en los que se informan
los parmetros para la obtencin del informe escogido se
consideran como la parte de entrada de la consulta externa; la
parte de la salida de la consulta externa se debe considerar con
una complejidad funcional baja
pantallas de acceso a la aplicacin que proveen funciones de
seguridad provista por la aplicacin
pantallas de ayuda, que se deben contar una sola vez cuando
puedan ser obtenidas con diferentes mecanismos de seleccin
desde diversos puntos de la aplicacin; en estos casos se debe
tener en cuenta lo siguiente para los diferentes tipos de
pantalla de ayuda:
- las pantallas de ayuda a pantalla completa se deben

considerar de complejidad baja independientemente de
la cantidad del texto presentado
- la ayuda sensible al contexto se debe considerar

computando un tem de dato para la parte de entrada
para cada campo sensible a esta funcin
No deben ser:
mensajes de error o de confirmacin asociados a las entradas,

salidas o consultas externas
subsistema de ayuda que puede ser accedido
independientemente de la aplicacin
pantallas de control de acceso a la aplicacin que no proveen
funcionalidad de control de seguridad
pantallas que solo proveen la funcionalidad de seleccin o de
navegacin las funciones de la aplicacin
los datos derivados de datos contenidos en los archivos lgicos
internos o en los archivos de interfaz externa se deben
considerar como una salida externa
mltiples mtodos para ejecutar una misma lgica de consulta
externa
b. Se debe quitar subjetividad a los factores de

complejidad tcnica y ambiental
Hoja 35 de 57
Hay que considerar que cada variacin unitaria en los valores de los
FCT tiene un impacto muy grande en la estimacin, puesto que segn
los valores que se asignen a estos factores, un proyecto de 100 horas
podra reducirse a 60 horas o pasar a ser de 130 horas.
El impacto en la variacin de los valores de los FCA puede hacer que

un proyecto de 100 horas pueda reducirse a 72,5 horas o pasar a ser
de 140 horas.
Adicionalmente, tras la asignacin de valores hay que determinar si

se la hizo en forma optimista o pesimista y revisarla en caso
afirmativo de alguna de estas dos posturas.
A fin de quitar la subjetividad en la asignacin de valores a los

factores de complejidad tcnica y ambiental en ambos mtodos de
estimacin es que sugerimos el empleo de los siguientes criterios:
1. Factores de complejidad tcnica para ambos mtodos
FCT01: Sistema distribuido
Considera el grado de distribucin del procesamiento entre varias

unidades de procesamiento (CPUs).
Valor Criterio
No se requiere transferencia automtica de datos o
0
procesamiento entre varias CPUs
Se solicita que la aplicacin prepare datos para que el
usuario final los procese en otra CPU de la instalacin
1
utilizando software genrico (planillas de clculo, editores de
texto, bases de datos)
Se solicita que se preparen datos y se los transfiera a otra
2 CPU de la instalacin para su procesamiento (transferencia
de archivos)
Se solicita procesamiento distribuido y transferencia de
3 datos en lnea pero en una nica direccin (procesa en una
CPU y transfiere a otra CPU)
Se solicita procesamiento distribuido y transferencia de
4 datos en lnea en ambas direcciones (procesamiento
cooperativo)
5 Se solicita que la aplicacin determine dinmicamente cul
Hoja 36 de 57
es la CPU ms apropiada para ejecutar una funcin
FCT02: Performance
Considera los objetivos de performance establecidos por el usuario

que afecten el diseo, la construccin, la implementacin o el soporte
de la aplicacin.
Valor Criterio
0 No se solicitan requisitos especiales de performance
Se solicitaron requisitos de performance pero no hay que
1
tomar medidas especiales
El tiempo de respuesta es crtico durante las horas pico; no
2 se requiere diseo de uso del procesador; el tiempo de
procesamiento siempre es para el da siguiente
El tiempo de respuesta es crtico durante todo el horario de
operaciones; no se requiere diseo de uso del procesador;
3
las restricciones de tiempo de procesamiento son impuestas
por otros sistemas
El usuario solicita requerimientos de performance bastante
4 rigurosos al punto de requerir tareas de anlisis de
performance durante el anlisis y el diseo de la aplicacin
Adems de lo dicho en el punto anterior, hay que utilizar
herramientas de anlisis de performance durante la etapa
5
de diseo, desarrollo o implementacin a fin de poder
asegurar la performance requerida por el usuario
FCT03: Eficiencia para el usuario final
Considera que existen objetivos de eficiencia para el usuario final que

deben ser reflejadas en mejores diseos o funcionalidades especiales,
como por ejemplo:
navegacin por mens

documentacin o ayuda en lnea
movimiento automtico del cursor
movimiento de pantalla vertical y horizontal (scroll)
impresin remota va transaccin en lnea
teclas de funciones predefinidas o programables por el usuario
Hoja 37 de 57
envo de tareas para ejecucin en batch a partir de
transacciones en lnea
seleccin de datos en pantalla mediante movimientos del
cursor
uso intensivo de video inverso, brillo intenso, colores,
subrayado y otros recursos de video
impresin de documentacin del sistema/rutina/funcin por
medio de hardcopy en transacciones en lnea
interfaz para mouse
ventanas pop-up
minimizar el nmero de pantallas para ejecutar las funciones
del negocio
facilidad de navegacin entre pantallas por medio de teclas de
funcin o de navegacin directa
soporte bilinge (contar como 4 tems)
soporte multilinge (contar como 6 tems)
Valor Criterio
No se solicita que la aplicacin cumpla con ninguno de los
0
tems de la lista
1 Se solicita el cumplimiento de 1 a 3 tems
2 Se solicita el cumplimiento de 4 a 5 tems
3 Se solicita el cumplimiento de 6 tems o ms
Se solicita el cumplimiento de 6 tems o ms y los
requerimientos de eficiencia del usuario final son tan
4 rigurosos como para que la fase de diseo exija el anlisis
de defaults o plantillas para minimizar el esfuerzo de uso de
teclado
Se solicita el cumplimiento de 6 tems o ms y se requiere
5 el uso de herramientas para demostrar que se alcanzan los
objetivos de eficiencia exigidos
FCT04: Procesamiento interno complejo
Considera que la complejidad del procesamiento tendr impacto en el

diseo o la construccin, al tener que contemplar algunas exigencias
como las siguientes:
procesamiento especial de auditora o de seguridad

procesamiento lgico extensivo
Hoja 38 de 57
procesamiento matemtico extensivo
gran cantidad de procesamiento de excepciones por
interrupciones, fallas, etc.
procesamiento complejo para manipular mltiples posibilidades
de entrada, salida, medios y tipos de equipamiento
Valor Criterio
No se solicita que la aplicacin cumpla con ninguno de los
0
tems de la lista
1 Se solicita el cumplimiento de 1 tem
2 Se solicita el cumplimiento de 2 tems
5 Se solicita el cumplimiento de los 5 tems
FCT05: Cdigo reutilizable
Considera que la aplicacin y su cdigo deben disearse, construirse

y mantenerse de modo de poder ser reutilizados en otras aplicaciones
mediante parametrizacin.
Valor Criterio
0 No se solicita desarrollar cdigo reutilizable
Se solicita reutilizacin de cdigo dentro de la misma
1
aplicacin
Se solicita escribir menos del 10% del cdigo para su
2
reutilizacin en otras aplicaciones
Se solicita escribir el 10% o ms del cdigo para su
3
reutilizacin en otras aplicaciones
Se solicita que la aplicacin se disee y documente y se
4
optimice el cdigo fuente para facilitar su reutilizacin
Se solicita que la aplicacin sea reutilizable y que la
5 parametrizacin para su adecuacin sea administrada por el
usuario
FCT06: Facilidad de instalacin
Hoja 39 de 57
Considera el nivel de facilidad de implementacin y las herramientas
de conversin de datos que sean caractersticas de la aplicacin.
Valor Criterio
0 No se solicita ninguna consideracin especial al respecto
No se solicita ninguna consideracin especial al respecto
1 pero se necesita un procedimiento especial para la
instalacin
Se solicitan requisitos de implementacin y conversin de
datos y se deben preparar rutinas de implantacin y
2
conversin de datos, considerndose que la conversin de
datos no provoca un impacto importante
datos y se deben preparar rutinas de implantacin y
3
conversin de datos, considerndose que la conversin de
datos provoca un impacto importante
datos y se deben utilizar y probar herramientas de
4
implantacin y conversin, considerndose que la
conversin de datos no provoca un impacto importante
datos y se deben utilizar y probar herramientas de
5
implantacin y conversin, considerndose que la
conversin de datos provoca un impacto importante
FCT07: Facilidad de uso
Considera las especificaciones de la aplicacin que demandan

procedimientos automticos que minimicen la intervencin manual de
los usuarios.
Valor Criterio
No se solicita ninguna consideracin especial al respecto,
0
salvo los procedimientos normales de copia de seguridad
Se solicitan procedimientos eficientes de inicializacin, copia
1 de seguridad, recuperacin de copias de seguridad, pero es
necesaria la intervencin del usuario
Se solicitan procedimientos eficientes de inicializacin, copia
2 de seguridad, recuperacin de copias de seguridad, pero no
es necesaria la intervencin del usuario
3 Se solicita que la aplicacin minimice la operacin de
Hoja 40 de 57
montaje del soporte fsico de la copia de seguridad
4 Se solicita que se minimice la manipulacin de formularios
Se solicita que la aplicacin no requiera la intervencin del
5 usuario durante su funcionamiento normal, salvo en el caso
de inicializacin y parada del sistema
FCT08: Portabilidad
Considera si la aplicacin debe soportar un uso geogrficamente

distribuido dentro de una organizacin o en mltiples organizaciones.
Valor Criterio
0 No se solicita que la aplicacin se use en ms de un sitio
Se solicita que la aplicacin se use en ms de un sitio pero
1
en ambientes de software y hardware idnticos
2
en ambientes de software y hardware parecidos
3
en ambientes de software y hardware diferentes
Se debe elabora y documentar un plan de prueba y
mantenimiento para que la aplicacin soporte su uso en
4
varios sitios con ambientes de software y hardware iguales o
parecidos
Se debe elabora y documentar un plan de prueba y
mantenimiento para que la aplicacin soporte su uso en
5
varios sitios con ambientes de software y hardware
diferentes
FCT09: Facilidad de cambio
Considera si la aplicacin se debe disear, desarrollar y mantener al

prever informes flexibles, parametrizacin de datos para el control del
negocio y que el usuario los pueda modificar en cualquier momento.
Valor Criterio
0 No se solicita que la aplicacin considere nada al respecto
Se solicita un recurso flexible de consulta y de emisin de
1
informes capaz de manipular solicitudes simples, con lgica
Hoja 41 de 57
and/or y accediendo a un nico archivo lgico interno
informes capaz de manipular solicitudes de complejidad
2
media, con lgica and/or y accediendo a ms de un archivo
lgico interno
informes capaz de manipular solicitudes de complejidad alta,
3
con lgica and/or y accediendo a ms de un archivo lgico
interno
En caso de que el usuario debe poder administrar la informacin

por medio de procesos en lnea e interactivos, al puntaje de la
tabla se le debe sumar:
1, si estas alteraciones slo se efectivizan al da siguiente

2, si estas alteraciones deben ser inmediatas
FCT10: Volumen de transacciones y concurrencia
Considera si la aplicacin tiene tal volumen de transacciones que se

vern afectados el diseo, la construccin o el mantenimiento de la
aplicacin.
Valor Criterio
0 No existen perodos de picos de transacciones
Se esperan picos diarios, semanales o mensuales de
1
transacciones
Se esperan altos volmenes de transacciones de modo que
2
fuerzan tareas de anlisis de impacto en la fase de diseo
Se esperan altos volmenes de transacciones de modo que
3 exigen el empleo de herramientas de anlisis de
performance en las fases de diseo o de construccin
En caso de que los volmenes de transacciones adems deban ser

concurrentes, dependiendo del grado de concurrencia al puntaje
de la tabla se le debe sumar:
0, si la aplicacin ser usada por un nico usuario

1, si se requiere que la aplicacin soporte un cierto nmero de
usuarios concurrentes con bloqueo de registros
Hoja 42 de 57
2, si se requiere que la aplicacin sea usada por un nmero
ilimitado de usuarios
FCT11: Caractersticas especiales de equipamiento y

seguridad
Considera si la aplicacin exige consideraciones especiales en el

diseo para que la configuracin del equipo escogido no quede
sobrecargada.
Valor Criterio
0 No existen solicitudes al respecto
Algunas porciones especficas de la aplicacin requieren
1
dedicacin especial a nivel de procesador
Se requiere atencin especial a nivel de procesador o
2
procesador dedicado para ejecutar la aplicacin
Las restricciones operacionales son agravadas por la
3 existencia de sobrecarga a nivel de las CPUs distribuidas en
la instalacin
En caso de que existan solicitudes especiales de seguridad, al

puntaje de la tabla se le debe sumar:
1, si se requiere que la aplicacin administre ella misma su

seguridad
2, si se requiere que la aplicacin administre ella misma su
seguridad con mecanismos de encriptacin
FCT12: Comunicacin de datos
Considera si los datos o la informacin de control son enviados o

recibidos en la aplicacin por medio de mecanismos de comunicacin
de datos.
Valor Criterio
El procesamiento es batch o ejecutado en un nico
0
procesador aislado
Hoja 43 de 57
La aplicacin es batch y posee entrada de datos o impresin
1
remotos (uno de los dos)
La aplicacin es batch y posee entrada de datos e impresin
2
remotos (los dos)
Se realiza captura de datos en lnea, va Terminal, red de
3 computadores o front-end para alimentar procesos en batch
o sistemas de consulta
Se requiere ms de un front-end, pero la aplicacin soporta
4
slo un tipo de protocolo de comunicacin
Se requiere ms de un front-end, pero la aplicacin soporta
5
varios tipos de protocolos de comunicacin
2. Factor de complejidad tcnica para el mtodo de

estimacin por puntos de casos de uso
FCT13: Acceso directo de terceras partes
Considera el acceso a la aplicacin por personas u organizaciones

ajenas a los desarrolladores o a los propietarios del sistema,
considerndose aspectos tales como:
la aplicacin est disponible al pblico en Internet

la aplicacin mantiene y administra integracin con terceras
partes
la aplicacin consume servicios de terceras partes (contar un
tem por cada tercera parte involucrada)
la aplicacin publica y documenta una API pblica
la aplicacin debe manipular software directamente sin una API
pblica (contar como 2 tems)
Valor Criterio
0 No se requiere ningn tem de la lista
1 Se requiere slo un tem de la lista
2 Se requieren dos tems de la lista
3 Se requieren tres tems de la lista
4 Se requieren cuatro tems de la lista
5 Se requieren cinco tems de la lista
Hoja 44 de 57
3. Factores de complejidad tcnica para el mtodo de
estimacin por puntos de funcin
FCT13: Actualizacin en lnea
Considera si la aplicacin permite la actualizacin en lnea de archivos

lgicos internos.
Valor Criterio
0 No se requiere nada al respecto
Se solicita actualizacin en lnea de uno a tres archivos
1 lgicos internos; el volumen de actualizacin es bajo y la
recuperacin de datos es simple
Se solicita actualizacin en lnea de cuatro o ms archivos
2 lgicos internos; el volumen de actualizacin es bajo y la
recuperacin de datos es simple
Se solicita actualizacin en lnea de la mayora de los
3
archivos lgicos internos
Se solicita actualizacin en lnea de la mayora de los
4 archivos lgicos internos; la proteccin contra prdidas de
informacin es esencial y depende de la aplicacin
Adems del punto anterior, los altos volmenes de datos
5 exigen consideraciones sobre el costo de procesamiento de
recuperacin y stos exigen procedimientos automatizados
FCT14: Entrada de datos en lnea
Considera el grado de necesidad de entrada de datos en lnea de la

aplicacin.
Valor Criterio
0 Todas las transacciones se procesan en batch
Se solicita que el 1% al 7% de las transacciones sean
1
entradas de datos interactivas
2
3
4 Se solicita que el 24% al 30% de las transacciones sean
Hoja 45 de 57
Se solicita que ms del 30% de las transacciones sean
5
4. Factores de complejidad ambiental
FCA01: Familiaridad con el proceso
Considera la cantidad de proyectos en los que los miembros del

equipo usaron el proceso de desarrollo definido en la organizacin. Se
consideran proyectos de un mnimo de tres meses de duracin y de
tres desarrolladores como mnimo.
Valor Criterio
0 El equipo no est familiarizado con el proceso
1 El equipo tiene slo un conocimiento terico del proceso
2 Slo un miembro lo us al menos una vez
3 Ms de un miembro lo us ms de una vez
4 Al menos la mitad del equipo lo us en tres proyectos o ms
5 Todo el equipo lo us al menos en tres proyectos o ms
FCA02: Experiencia en el dominio del problema
Considera la experiencia en el dominio del problema, aunque se

puede dar una pequea consideracin al haber participado en
proyectos en general. Se consideran proyectos de un mnimo de tres
meses de duracin y de tres desarrolladores como mnimo.
Valor Criterio
0 Todo el equipo es novato
Slo uno tiene experiencia en al menos un ao y medio y el
1
resto es novato
2 Ms de uno tiene experiencia en al menos un ao y medio
3 Todos tienen experiencia en al menos un ao y medio
4 La mayora tiene experiencia en ms de dos aos
5 Todo el equipo es experto
Hoja 46 de 57
FCA03: Experiencia en orientacin a objetos
Considera la experiencia real en el uso prctico de orientacin a

objetos en anlisis, diseo y construccin. Se consideran proyectos de
un mnimo de tres meses de duracin y de tres desarrolladores como
mnimo.
Valor Criterio
0 Todo el equipo es novato
1 Todos los miembros tienen experiencia en al menos un ao
Adems del punto anterior, la mitad tiene experiencia en
2
ms de un ao y medio
Adems del punto anterior, la mitad tiene experiencia en
3
ms de dos aos
4 Todo el equipo tiene experiencia en ms de dos aos
5 Todo el equipo es experto
FCA04: Capacidad de los analistas lderes
Considera la experiencia de los analistas lderes, contando el tiempo

como lder dado que su performance real en ese rol es difcil de
medir. Se consideran proyectos de un mnimo de tres meses de
duracin y de tres desarrolladores como mnimo.
Valor Criterio
0 El analista lder es novato
1 El analista lder tiene experiencia en un proyecto
2 El analista lder tiene experiencia entre dos y tres proyectos
El analista lder tiene ms de dos aos de experiencia en
3
ms de tres proyectos
El analista lder tiene ms de dos aos de experiencia en
4
ms de tres proyectos
El analista lder tiene ms de tres aos de experiencia en
5
ms de cuatro proyectos
FCA05: Motivacin
Hoja 47 de 57
Considera la motivacin del equipo completo. Dado que es difcil de
medir, se puede considerar la eficiencia del equipo y la cantidad de
horas extra que realizan por voluntad propia.
Valor Criterio
0 El equipo no est motivado
1 Menos de la mitad del equipo est motivado
Entre la mitad y las tres cuartas partes del equipo estn
2
motivados
3 Todo el equipo est motivado
4 El equipo est muy motivado
5 El equipo est muy motivado e inspirado
FCA06: Requisitos estables
Considera los cambios que se prev que tendrn los requisitos

durante la etapa de desarrollo y la inseguridad en los requisitos. Se
deberan considerar aspectos tales como:
existe una especificacin de requisitos formal tomada como

lnea base y firmada por los usuarios
existe un sistema de administracin de cambios
se realizan informes de avance detallados semanalmente
el proyecto es slo una reconversin a otra tecnologa o un
cambio de plataforma de una aplicacin existente
existen prototipos
Valor Criterio
0 Habr muchos cambios e inseguridad en los requisitos
1 Habr cambios peridicos e inseguridad en los requisitos
Habr cambios peridicos en los requisitos y se est seguro
2
de ellos
Habr pocos cambios peridicos en los requisitos y se est
3
seguro de ellos
4 No habr cambios en los requisitos y se est seguro de ellos
5 Adems del punto anterior, se trata de una reconversin
FCA07: Recursos humanos part-time
Hoja 48 de 57
Considera el tiempo que le dedican en promedio los miembros del
equipo al proyecto cada jornada.
Valor Criterio
0 No hay recursos part-time
1 Hasta el 10% del equipo es part-time
5 Todo el equipo es part-time
FCA08: Dificultad del lenguaje de programacin
Considera la experiencia de los desarrolladores en el lenguaje de

programacin y la cantidad de lenguajes que se van a emplear.
Valor Criterio
0 Todos son programadores expertos
1 La mayora tiene ms de dos aos de experiencia
2 Todos tienen ms de un ao y medio de experiencia
3 La mayora tiene ms de un ao de experiencia
Menos de la mitad tiene un ao de experiencia y el resto es
4
novato
5 Todos los programadores son novatos
Hoja 49 de 57
8. Unificacin de las bases de estimacin
para puntos de casos de uso y puntos
de funcin
Si bien el mtodo de estimacin por puntos de casos de uso se cre

basndose en el de estimacin por puntos de funcin y, por
consiguiente, comparten la forma de clculo, al entrar en detalle hay
obvias diferencias.
Por otra parte, al querer utilizar en forma combinada el mtodo de

estimacin por puntos de casos de uso para estimar proyectos y
luego el de puntos de funcin para estimar pedidos de cambio y
mantenimiento, nos obliga a tener que estimar sobre las mismas
bases de modo de no cambiar los criterios al pasar del inicio del
proyecto, en el que usbamos puntos de casos de uso, a la etapa de
construccin y mantenimiento en donde utilizaremos puntos de
funcin.
El primer punto que debemos considerar para la unificacin de tales

criterios es el conjunto de factores de complejidad tcnica. En el
mtodo de puntos de casos de uso existen trece factores y en el de
puntos de funcin catorce, de los cuales coinciden en nueve.
Los nueve factores coincidentes son:
Procesamiento distribuido
Eficiencia del usuario final
Complejidad del procesamiento
Facilidad de instalacin
Portabilidad
Facilidad de cambios
Facilidad de uso
Performance
Reutilizacin de cdigo
Los factores no coincidentes para el mtodo de puntos de casos de

uso son:
1. Concurrencia
Hoja 50 de 57
2. Caractersticas especiales de seguridad
3. Acceso directo de terceras partes
4. Facilidades de entrenamiento especial del usuario
Los factores no coincidentes para el mtodo de puntos de funcin

son:
5. Comunicacin de datos
6. Actualizacin en lnea
7. Entrada de datos en lnea
8. Volumen de transacciones
9. Utilizacin de equipamiento
Los criterios para la unificacin fueron los siguientes:
a. Utilizar en los dos mtodos un factor denominado

Volumen de transacciones y concurrencia
De este modo se estaran unificando los factores 1 y 8 de las

dos listas anteriores y esto tiene sentido ya que son factores
homogneos al permitirnos estimar el volumen de
transacciones considerando, a su vez, cuntas de estas
transacciones deben ejecutarse en forma concurrente.
Adems, en el mtodo de estimacin por puntos de caso de

uso incrementamos el peso relativo de este factor de 1 a 1,5
para compensar la combinacin de los dos criterios.
b. Utilizar en los dos mtodos un factor denominado

Caractersticas especiales de equipamiento y
seguridad
De este modo se estaran unificando los factores 2 y 9 de las

dos listas anteriores y, nuevamente, esto tiene sentido ya que
tambin se trata de factores homogneos debido a que en los
mtodos originales en ambos casos nos exige evaluar las
caractersticas especiales que deber tener la aplicacin para
adaptarse al hardware.

Hoja 51 de 57
c. Utilizar en el mtodo de puntos de caso de uso el
criterio Acceso directo de terceras partes y luego en
el de puntos de funcin los dos criterios
Actualizacin en lnea y Entrada de datos en lnea
al ser criterios equivalentes
Estos dos criterios del mtodo de puntos de funcin se basan

en la cuenta de la cantidad de archivos y transacciones que en
una etapa temprana (al iniciar un proyecto) no se conocen y,
por lo tanto, nos obliga a estimarlas con el criterio equivalente
de Acceso directo de terceras partes.
Una vez avanzado el proyecto, cuando comienzan a aparecer

pedidos de cambio, o en la etapa de mantenimiento, ya ser
posible calcular los factores del mtodo de puntos de funcin al
existir archivos e informacin ms concreta.
Sin dudas, no debera haber un salto importante en la

valoracin de estos factores entre la etapa temprana y la etapa
posterior, caso contrario estaramos en presencia de algn
cambio en los requisitos que debi ser administrado en algn
momento, ya que estos criterios de ambos mtodos son
homogneos y apuntan a la consideracin de los mismos
requisitos.

d. Agregar en el mtodo de estimacin por puntos de

caso de uso el criterio Comunicacin de datos del
mtodo de puntos de funcin
Consideramos que esto no provocara un impacto importante

en el mtodo de estimacin por puntos de casos de uso si se le
da el peso relativo adecuado y se corrigen las frmulas de
ajuste de los factores en base a estos cambios.
e. Eliminar del mtodo de estimacin por puntos de caso

de uso el criterio Facilidades de entrenamiento
especial del usuario
Hoja 52 de 57
Consideramos que esto tampoco provocara un impacto
importante ya que la documentacin y el entrenamiento del
usuario son actividades propias del ciclo de vida del desarrollo
de software y, justamente, las horas hombre que se calculan
contemplan estas actividades del ciclo de vida del desarrollo de
software.
Ntese que, en definitiva, prcticamente el ajuste se hizo sobre el

mtodo de estimacin por puntos de casos de uso, variando casi
imperceptiblemente los factores para el mtodo por puntos de
funcin. Esto es as debido a que el mtodo e estimacin por puntos
de funcin est regulado por una organizacin internacional, con todo
lo que esto implica, mientras que el de casos de uso no y, por
consiguiente, consideramos menos riesgoso y mucho ms prudente
realizar la adaptacin en este sentido.
Hoja 53 de 57
9. Datos estndares de referencia
Se debe considerar que estos datos estndares son presentados slo
con la finalidad de aportar una referencia, y los valores se deben
tomar slo en cuanto a los rdenes de magnitud.
1. Datos estndares para el mtodo de estimacin por

puntos de casos de uso
La empresa Ericsson donde nacieron los casos de uso y, por

consiguiente, donde se supone que se escriban los casos de uso de
manera ms estndar, modelando porciones grandes de una nueva
generacin de cambios de telfono, que se estima en ms de 600
personas/ao con un pico de 400 desarrolladores tuvo 200 casos de
uso.
El RUP dice que un proyecto promedio de un sistema administrativo

(no tcnico) de 6 a 8 meses y de 10 a 15 personas tendra alrededor
de 30 casos de uso.
Un consultor de Rational/IBM plantea que el proyecto ms grande en

el que particip, de 4 aos de duracin con 300 personas, posea
alrededor de 280 casos de uso.
Es importante tener en cuenta que a medida que los proyectos son

menores tendrn proporcionalmente ms cantidad de casos de uso.
2. Datos estndares para el mtodo de estimacin por

puntos de funcin
Hoja 54 de 57
10. Relacin directa entre puntos de
casos de uso y puntos de funcin
Existen opiniones diversas; mientras algunos autores opinan que no
se pueden comparar2, otros proponen equivalencia matemtica entre
ellos3.
Para el autor del primer caso, un proyecto de cuatro aos con

trescientas personas involucradas, con doscientos ochenta casos de
uso tuvo entre nueve mil y catorce mil puntos de funcin.
Para el autor del segundo caso, obtuvo las siguientes relaciones: 1 PF

= 1,4615 PCU para proyectos elaborados dentro del mbito
acadmico y 1 PF = 2,8905 PCU para proyectos de la industria.
En particular, nosotros nos oponemos a la relacin directa entre

ambos; an cuando puede existir consideramos que se requieren
muchos proyectos con caractersticas demasiado especiales para
poder obtenerla con la precisin que se requiere. A lo sumo se puede
utilizar a modo de referencia y se debera obtener en el mbito de
cada empresa en particular. De hecho, ntese la gran diferencia de
valores obtenidos por el mismo autor que apoya la relacin directa.
2
Cfr. PROBASCO, Leslee. Dear Dr. Use Case: What About Function Points and
Use Cases?. Rational Software Canada, 2002,
http://www.therationaledge.com/content/aug_02/t_drUseCase_lp.jsp
3
Cfr. PEREIRA DE ANDRADE, Edmia Leonor. Pontos de caso de uso e pontos
de funo na gesto de estimativa de tamanho de projetos de software
orientados a objetos. Tesis de maestria del Programa de posgraduacin em
gestin del conocimiento y tecnologa de la informacin. Universidad Catlica de
Brasilia, 2004.
Hoja 55 de 57
11. Glosario
A
B
C
D
E
F
G
H
I
J
K
L
M
N
Hoja 56 de 57
O
P
Q
R
S
T
U
V
W
X
Y
Z
Hoja 57 de 57

EstimacionPorPCUyPF v.1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

EstimacionPorPCUyPF v.1

Cargado por

Copyright:

Formatos disponibles

Estimacin por puntos de casos de uso y

por puntos de funcin

2. ASPECTOS NECESARIOS EN LA ESTIMACIN............................... 4

3. MTODOS DE ESTIMACIN ......................................................... 7

4. MTODO DE ESTIMACIN POR PUNTOS DE CASOS DE USO ....... 10

5. MTODO DE ESTIMACIN POR PUNTOS DE FUNCIN................ 16

6. AJUSTE DEL MTODO DE ESTIMACIN POR PUNTOS DE FUNCIN

7. REDUCCIN DE LOS DESVOS EN LAS ESTIMACIONES .............. 29

8. UNIFICACIN DE LAS BASES DE ESTIMACIN PARA PUNTOS DE

9. DATOS ESTNDARES DE REFERENCIA ....................................... 54

10. GLOSARIO ............................................................................... 56

en qu momento se realizar la estimacin

Desde el punto de vista del momento de la estimacin, en el desarrollo de

antes de comenzar un proyecto, por lo que se debe estimar el

La informacin con que se cuenta en cada uno de estos momentos nos

antes de comenzar un proyecto slo hay casos de uso (no hay

El documento, en cuanto a su contenido y redaccin, ms la adaptacin de

Las reglas de estimacin por puntos de funcin descritas en este documento

a. Medir (si no se mide no tiene sentido estimar!)

Por lo tanto, antes de empezar a estimar hay que comenzar a

para verificar si la estimacin fue correcta

Por esta razn se deben establecer todos los criterios que

La uniformidad se logra de varios modos, cosa que tambin

aplicando siempre el mismo mtodo

f. Estimar por mdulos

A continuacin describimos los pasos de la estimacin de ambos mtodos a

En la seccin 4 de este documento volveremos a repetir este proceso en

A. Estimar el tamao del software a construir

Paso #1: obtener los puntos no ajustados

Por lo tanto, el primer paso consistir en obtener una primera medida

As, hacemos una sumatoria de los puntos de cada elemento a

Esta sumatoria se llamar Puntos de Casos de Uso no Ajustados y

Paso #2: obtener los factores de complejidad

En la medida en que haya ms cantidad de estos requisitos globales,

Es importante tener en cuenta que para cumplir con el objetivo

Paso #3: estimar el tamao del software

B. Estimar el esfuerzo de construir el software

Paso #4: obtener los factores de complejidad

Por esta razn es que se deben calcular estas caractersticas

Paso #5: estimar el esfuerzo de desarrollar el

C. Traducir el esfuerzo en horas y dinero

Paso #6: obtener las horas de desarrollo

El total es el total de horas del desarrollo del software.

Paso #7: obtener el costo del desarrollo

Se emplea tempranamente en el ciclo de vida del desarrollo de software,

A continuacin describiremos en detalle los siete pasos del mtodo

Paso #1: obtener los puntos de casos de uso no

casos de uso de complejidad baja

actores de complejidad baja

La complejidad de los casos de uso se establece en funcin de la

caso de uso de complejidad baja: menos de 4 escenarios

actores de complejidad baja: llamadas a API

caso de uso de complejidad baja: 5 puntos

actores de complejidad baja: 1 punto

Por ltimo se multiplica la cantidad de puntos por la cantidad de

Paso 2: obtener los factores de complejidad

Lo que se debe realizar es la asignacin a cada uno de estos factores

Por ltimo se multiplica el peso de cada factor por el valor que se le

Factor Peso Valor Producto

Este valor resultante se ajusta segn la siguiente frmula

FCT = 0,6125 + (0,01 * FCTnoA)

y as se obtiene el Factor de Complejidad Tcnica del desarrollo a

Es importante tener en cuenta que en caso de variarse alguno de los

Los criterios para asignar los valores se encuentran en el punto 7.b de