UNIVERSIDAD DE EL SALVADOR

FACULTAD DE INGENIERIA Y ARQUITECTURA

ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS
HERRAMIENTAS DE PRODUCTIVIDAD

UNIDAD V
MEDICION DE LA PRODUCTIVIDAD

5.1. MEDICION DE LA PRODUCTIVDAD

En la Unidad I estudiamos que la productividad es la razn entre el producto (el software) y los insumos
utilizados para su desarrollo.

productiv idad=

atributos del software

esfuerzo total de desarrollo

El estndar ISO 9126 nos provee de un modelo para definir los atributos que debe tener un software de calidad.
Ya hemos estudiado tambin que el esfuerzo total de desarrollo consiste en medir los recursos utilizados en el
proceso de desarrollo: monetarios, temporales, humanos, materiales, etc.
Cuando se trata de un proceso de desarrollo terminado, el clculo de la productividad resultar sencillo de
calcular, en la medida en que ya conocemos ambas variables.
Sin embargo, uno de los problemas ms comunes a la hora de iniciar un proyecto de desarrollo es la estimacin.
Cuando un cliente nos solicita el desarrollo de un software, cmo podemos saber qu tan grande es ese
software?, cmo saber cunto esfuerzo requiere su desarrollo?, y por ende; cunto tiempo necesitamos para su
desarrollo?, cunto debemos cobrar por ese proyecto?.
Ya hemos mencionado, en la Unidad I; cuales son los costos que se deben considerar en un proyecto. En la fase
de Planificacin, estos costos estarn determinados por las actividades que se hayan definido para la realizacin
del proyecto, los recursos necesarios para realizar estas actividades y el tiempo de cada actividad.
El proceso de Programacin de proyectos por lo tanto, requiere de un punto de partida para definir estas
variables (actividades, tiempos y recursos).
Durante las primeras etapas de la evolucin del proceso de desarrollo de software, se crearon una serie de
mtricas que respondan a la tecnologa y tcnicas utilizadas para el desarrollo:

Medidas relacionadas con el tamao: Estas mtricas se relacionan con el tamao de la salidas de alguna
actividad (proceso en el software). Las ms comunes son: lneas de cdigo fuente entregadas, nmero de
instrucciones de cdigo objeto entregado, nmero de pginas de documentacin del sistema.

Medidas relacionadas con la funcin: Estas mtricas se relacionan con la funcionalidad total del software
entregado. Las ms conocidas fueron: Puntos de Funcin, Puntos Caracterstica y Puntos Objeto.

Algunas de estas mtricas han quedado en desuso con el tiempo, debido a que ya no se ajustan a las tcnicas o a
la tecnologa utilizada para el desarrollo.

A. PUNTOS DE FUNCION
La mtrica Punto de Funcin (Function Points FP-), fue creada por Allan Albrecht en 1979. como una tcnica
de estimacin del tamao del software sobre la base de la funcionalidad entregada al usuario,
independientemente de la tecnologa utilizada para su desarrollo. La mtrica ha sobrevivido hasta nuestra poca,
habindose desarrollado muchas variantes.
Uno de los consensos ms importantes sobre su aplicacin es la necesidad de establecer qu se debe medir y
cmo se medir. Esto generalmente responde al hecho de que las estimaciones de software a travs de esta
mtrica pueden darse en etapas muy tempranas del desarrollo. Desde la planificacin, donde se cuentan con
informacin muy bsica sobre lo que ser el software, hasta etapas finales donde ya se tienen claras las

caractersticas del software construido. De hecho, esta mtrica es usualmente aplicada en fase de anlisis, donde
ya se tiene una idea ms clara sobre las caractersticas del software que se est desarrollando, y sirve para
revaluar la estimacin realizada al inicio.

IFPUG ISO/IEC 20926:2009

Una versin de la mtrica Puntos de Funcin es la creada por el Grupo Internacional de Usuarios de Puntos de
Funcin (IFPUG, por sus siglas en ingls International Function Point Users Group).
El conteo de puntos de funcin puede estar asociado los siguientes proyectos o aplicaciones:
1. Proyecto de desarrollo. Mide las funciones que sern provistas al usuario con la primera instalacin del
software entregado con el proyecto est completado.
2. Proyecto de mejora. Mide las modificaciones que se deben realizar (funciones a agregar, modificar o
quitar) a una aplicacin existente.
3. Aplicacin. Los puntos de funcin de desarrollo y de proyecto estn asociadas a una aplicacin
instalada. Los puntos de funcin de aplicacin miden las funciones que una aplicacin provee
actualmente a un usuario. El nmero es inicializado con los puntos de funcin del proyecto de desarrollo
de la aplicacin (primera versin de la aplicacin), cuando este ha sido terminado y se actualiza cada vez
que se complete un proyecto de mejora que modifique las funciones de una aplicacin.

El uso de Puntos de Funcin para proyectos de mejora requieren de otras consideraciones que no abordaremos
en esta asignatura. Nos centraremos en la aplicacin del mtodo para un proyecto de desarrollo.

PUNTOS DE FUNCIN NO AJUSTADOS

Los puntos de funcin no ajustados, es la estimacin inicial del tamao del software. El estndar IFPUG rene
las funciones en 2 grupos:
1. Funciones de datos. Las funciones de datos representan la funcionalidad provista al usuario que satisface
los requerimientos de datos, tanto internos como externos.
1. Archivos lgicos internos (Internal Logical Files) (ILF)
2. Archivos de interfaz externos (External Inteface Files) (EIF)
2. Funciones de transaccin:
1. Entradas externas (External Inputs) (EI)
2. Salidas externas (External Outputs) (EO)
3. Consultas externas (External Inquiries) (EQ)

Antes de describir como realizar el conteo de los elementos que conforman la mtrica, hay que definir los
siguientes trminos:
Identificable por el usuario. Se refiere a los requerimientos definidos para procesos y grupos de datos
acordados y comprendidos por los usuarios y el equipo de desarrollo.
Proceso elemental. Un proceso elemental es la unidad ms pequea de una actividad que tiene un

significado para el usuario. Por ejemplo, un requerimiento de usuario puede ser la capacidad para
agregar un nuevo empleado a travs de una aplicacin para la gestin de planillas. La informacin de un
empleado incluye el salario y el puesto. Desde la perspectiva del usuario, la unidad ms pequea es
agregar un nuevo empleado, y no ingresar el salario o el puesto.
Un proceso elemental puede ser de entrada, de salida o de consulta. Un proceso elemental de entrada se
referir a la creacin, actualizacin o eliminacin de grupos de datos. Podemos ver este proceso como
las operaciones C, U y D de un proceso CRUD (Create, Read, Update, Delete).
Un proceso elemental de salida se referir a la presentacin de datos almacenados. Podemos ver este
proceso como una operacin R de un proceso CRUD. De igual manera, un proceso elemental de
consulta ser visto como una operacin R de un proceso CRUD.
Mantenimiento. Se refiere a la capacidad de acceder y modificar los datos a travs de un proceso
elemental. En este documento, cuando nos refiramos a mantener, nos referiremos a esa capacidad.
Informacin de control. Es un dato que influye en un proceso elemental de la aplicacin, y que
especifica qu, cundo o cmo los datos son procesados.
Lgica de procesamiento. La lgica de procesamiento es definida como requerimientos especficos por
el usuario para completar un proceso elemental. Esos requerimientos pueden incluir: validaciones,
frmulas matemticas, conversiones de datos, filtrado de datos, condiciones para aplicar las reglas del
negocio, la actualizacin de uno o ms archivos lgicos internos, referencias a uno o ms archivos
lgicos internos o archivos de interfaz externa, retorno de informacin de control.

ARCHIVOS LGICOS INTERNOS (ILF).

Un ILF es un conjunto de datos o informacin de control lgicamente agrupados e identificables por el usuario y
delimitado por la aplicacin. El objetivo principal de un ILF es almacenar y mantener datos a travs de uno o
ms procesos elementales de la aplicacin. En este sentido podemos decir que los ILF son:
1. El conjunto de datos de control o informacin relacionados al usuario. Por ejemplo: Informacin de
control de la aplicacin (archivos de configuracin).
2. El conjunto de datos administrados a travs de un proceso elemental. Por ejemplo:

Tablas de bases de datos relacionales

Archivos planos

Repositorios de almacenamiento de datos LDAP

Los datos manejados por el sistema constan de los siguientes elementos.

Tipo de elemento de dato (Data Element Type) (DET): Es un campo nico y no repetible reconocido por el
usuario.
Tipo de elemento de registro (Record Element Type) (RET): Es un subconjunto de DETs reconocidos por el
usuario en un ILF o un EIF. Existen dos tipos de RET:

Opcionales. Los tipos de RET opcionales son subgrupos de elementos de datos que no son necesarios
para crear una instancia de datos.

Obligatorios. Los tipos de RET obligatorios son subgrupos de elementos de datos que el usuario deber
usar (al menos uno), para crear una instancia de datos.

Desde un enfoque ER, los RET se refieren a las relaciones obligatorias (mandatorias), que se expresan en las
llaves forneas, y a aquellos atributos obligatorios (NOT NULL) de las tablas. Cada una de las llaves forneas
obligatorias debe contar como un RET, los atributos obligatorios pertenecientes a la tabla (propios) como otro
RET y los atributos que que son opcionales (incluyendo las llaves forneas) como otro RET.
Note que este concepto tiene una implicacin conceptual. Por ejemplo, los grupos que se generan a partir de las
llaves forneas representan el hecho de qu, para crear una instancia de datos de la tabla en anlisis, se requiere
que las otras instancias sean creadas previamente.
Se debe contar un RET para cada subgrupo identificado en el ILF o EIF. Cuando no se reconozca ningn RET en
un ILF o ELF, deber contarse como 1.
Para calcular la complejidad de los ILF usaremos la cantidad de los DET que contenga en relacin a los RET,
usando la siguiente tabla:
RET/DET

1-19

20-50

51+

Simple

Simple

Complejo

2-5

Simple

Medio

Complejo

6+

Medio

Complejo

Complejo

Reglas de identificacin:
Para ser contado como ILF, el conjunto de datos debe cumplir con las siguientes reglas:
1. Es lgica e identificable por el usuario.
2. Es mantenible a travs de un proceso elemental de la aplicacin.

ARCHIVOS DE INTERFAZ EXTERNA (EIF)

Un EIF es un conjunto de datos o informacin de control identificables por el usuario, lgicamente agrupados,
referenciados por la aplicacin, pero mantenido desde otra aplicacin que est fuera de los lmites de la
aplicacin que deseamos estimar.
Los EIF son utilizados para trasmitir o recuperar informacin procedentes de otros sistemas, cintas, discos,
gestor de comunicaciones, etc. El objetivo principal de los EIF es mantener las referencias a los datos a travs de
uno o ms procesos elementales de la aplicacin.
La tabla de complejidad de los EIF es la misma que la usada para los ILF.
Reglas de identificacin:
Para ser contado como un EIF, el conjunto de datos o informacin de control debe cumplir con las siguiente
reglas:
1. Ser lgica e identificable por el usuario.
2. Es referenciado por la aplicacin, pero se encuentra fuera de ella.

3. El conjunto de datos no es mantenible por la aplicacin.

4. Es un ILF en otra aplicacin.

Reglas para identificar los DET en los ILF y EIF:

1. Debe contarse como un DET cada campo identificable por el usuario y nico (no repetido) que es
mantenido o devuelto de un ILF o un EIF, a travs de la ejecucin de un proceso elemental.
2. Debe contarse como un DET cada pieza de dato requerido por el usuario para establecer una relacin
con otro ILF o un EIF (llaves forneas).

ENTRADAS EXTERNAS (EI)

Una EI es un proceso elemental que permite procesar los datos o la informacin de control que ingresa a la
aplicacin. El objetivo principal de las EI es mantener uno o ms ILF.

Tipo de Referencia de Archivo (File Reference Type) (FTR). Una FRT puede ser:

Una referencia a un ILF para lectura o mantenimiento por una transaccin.

Una referencia a un EIF para lectura por una transaccin.

El nivel de complejidad de las EI se mide en funcin de la cantidad de los tipos de elementos de dato (DET) y
las tipos de referencia de archivo (FTR).

FTR/DET

1-4

5-15

16+

0-1

Simple

Simple

Complejo

Simple

Medio

Complejo

3+

Medio

Complejo

Complejo

Reglas de identificacin:
1. Los datos o informacin de control deben provenir de fuera de la aplicacin
2. Al menos un ILF debe ser mantenido si los datos de entrada no son de control. En caso de que se trate de
informacin de control, debe alterar el comportamiento del sistema.
3. Al menos una de las tras condiciones descritas a continuacin se cumple:
La lgica de procesamiento es nica, respecto a la lgica de procesamiento realizado por otras EI.
El conjunto de elementos de dato es diferente del conjunto de datos identificados en otras EI.
Los ILF o EIF son diferentes de otros archivos referenciados por otra EI.
Reglas para identificar los DET y FRT en las EI:
1. No se debe contar los campos que son devueltos o derivados por el sistema y almacenados en un ILF

durante el proceso elemental si el campo no cruza los lmites de la aplicacin. Por ejemplo, cuando se
agrega una orden de un cliente, el precio unitario es devuelto automticamente por cada item que se
agrega a la orden y almacenado en el registro de la factura. El precio unitario no debe contarse como
elemento de dato para la entrada externa, porque dicho dato se encuentra almacenado en el sistema.
2. Los mensajes de error, confirmacin o cualquier tipo de mensaje de respuesta del sistema deben contarse
como un solo DET.
3. Aunque existan varias formas de iniciar, confirmar, cancelar o continuar un proceso, debe ser contado
como un nico DET.
4. Se debe contar un FRT para cada ILF mantenido.
5. Contar un FRT para cada ILF o EIF ledo durante el proceso entrada.
6. Contar solo un FRT por cada ILF si dicho archivo es mantenido y ledo.

SALIDAS EXTERNAS (EO)

Una EO es un proceso elemental que enva datos o informacin de control fuera de la aplicacin. El objetivo
principal de una salida externa es presentar la informacin al usuario a travs de otro proceso lgico o en adicin
a un proceso de recuperacin de datos o de informacin de control.
El nivel de complejidad de las EO se mide en funcin de la cantidad de los DET y FRT de acuerdo a la siguiente
tabla:

FRT/DET

1-5

6-19

20+

0-1

Simple

Simple

Complejo

2-3

Simple

Medio

Complejo

4+

Medio

Complejo

Complejo

Reglas de identificacin:
1. Al menos una de las siguientes reglas de proceso elemental debe cumplirse:
1. La lgica de procesamiento del proceso elemental contiene al menos una frmula matemtica o
clculo.
2. La lgica de procesamiento del proceso elemental crea datos derivados.
3. La lgica de procesamiento del proceso elemental mantiene al menos a un ILF.
4. La lgica de procesamiento del proceso elemental produce alteraciones en el comportamiento del
sistema.
Reglas para la identificacin de DET y FRT en las EO:
1. Contar un FRT para cada ILF mantenido durante el proceso elemental.
2. Contar solo un FRT por cada ILF cuando dicho archivo sea mantenido y ledo durante el proceso
elemental.

CONSULTAS EXTERNAS (EQ)

Una EQ es un proceso elemental que enva datos o informacin de control fuera de la aplicacin. El objetivo
principal de las EQ es presentar la informacin al usuario a travs de un proceso de recuperacin de datos.
La tabla de complejidad de las EQ es la misma que para las EO.
Reglas de identificacin:
1. La lgica de procesamiento del proceso elemental devuelve datos o informacin de control de un ILF o
EIF.
2. La lgica de procesamiento del proceso elemental no contiene frmulas matemticas o clculos.
3. La lgica de procesamiento del proceso elemental no crea datos derivados.
4. La lgica de procesamiento del proceso elemental no mantiene archivos lgicos internos.
5. La lgica de procesamiento del proceso elemental no altera el comportamiento del sistema.

Reglas comunes para el conteo de EO y EQ:

Reglas para identificar DET y FRT en EO y EQ:
1. Se debe contar un FRT por cada archivo ILF o EIF ledo en el proceso elemental.
2. Las funciones envan datos o informacin de control hacia afuera de la aplicacin.
3. Al menos una de las siguientes reglas debe cumplirse:
3.1. La lgica de procesamiento es nica respecto a la lgica de procesamiento realizada por otras EO y
EQ en la aplicacin.
3.2. El conjunto de elementos de datos identificados, es diferente al conjunto de datos identificados en
otras EO o EQ.
3.3. Los ILF y EIF referenciados son diferentes a los archivos referenciados por otras EO y EQ.
4. Contar un DET para cada campo identificable por el usuario, nico; que entra a la aplicacin y es
requerido para especificar cuando, qu y como los datos los datos deben ser devueltos por el proceso
elemental.
5. Contar un DET para cada campo identificable por el usuario, nico; que salga de la aplicacin. Por
ejemplo: Un mensaje de xito debe ser contado como un tipo de elemento de dato.
6. Si un DET entra y sale del sistema, debe ser contado solo una vez para el proceso elemental.
7. Contar un DET por la capacidad de enviar un mensaje de error o confirmacin.
8. Aunque existan varias formas de iniciar, confirmar, cancelar o continuar un proceso, debe ser contado
como un nico DET.
9. No se deben contar campos que son devueltos o generados por el sistema y almacenados en un ILF
durante el proceso elemental, si el campo no cruza la frontera de la aplicacin.
10. No se deben contar DET literales. Por ejemplo: Ttulos de reportes, cabeceras de columnas, o etiquetas
(labels).

La tabla general para el clculo de los puntos de funcin no ajustados es la siguiente:

PARAMETRO DE MEDIDA

FACTOR DE PESO
SIMPLE

MEDIO

COMPLEJO

Archivos Lgicos Internos

10

15

Archivos de Interfaz Externa

10

Entradas Externas

Salidas Externas

Consultas Externas

Contaremos de forma individual los parmetros de medida por cada factor de peso. Es decir, se contarn por
separados los parmetros segn el peso que tengan. Por ejemplo, se pueden tener 3 entradas Simples, 4 promedio
y 5 complejas.
El total de puntos de funcin sern los puntos de funcin no ajustados (UPF).

EJEMPLO:
En el proceso de desarrollo de una aplicacin para la administracin de Recursos Humanos para una empresa
transnacional, el usuario requiere lo siguiente:
1. La capacidad de mantener informacin de los empleados. Esto es ingresar, consultar y generar reportes
sobre los empleados. Al registrar un empleado nuevo, la fecha estimada de retiro es calculada
automticamente y almacenada como parte del registro del empleado. El reporte a generar debe mostrar
la lista de los empleados con sus fechas estimadas de retiro. La informacin del empleado es:
Cdigo del empleado, que debe ser generado por el sistema.
Nombre del empleado
Direccin
Salario
Puesto asignado
Fecha estimada de retiro
2. Ingresar, consular y generar reportes de los puestos de trabajo. Los datos de los puestos de trabajo son:
Cdigo de puesto
Nombre nominal del puesto
Salario base
Cdigo de puesto ocupado.
Nombre funcional del puesto

 Descripcin del puesto

3. Generar una consulta y un reporte de empleados con los respectivos puestos asignados. Los criterios de
filtrado de los datos deben ser: cdigo del puesto, salario base, nombre nominal, oficina, nombre
funcional del puesto, salario asignado y fecha de asignacin. La consulta deber mostrar cdigo del
empleado, nombre, cdigo del puesto, numero de lnea, salario base, nombre funcional del puesto,
salario asignado y la fecha de asignacin.
4. Una interfaz con el Sistema de Activo Fijo para consultar informacin de las oficinas de la empresa. La
informacin incluye ubicacin, cdigo y descripcin de cada oficina.
5. El usuario necesita adems la capacidad de configurar el formato en que se imprimirn los reportes de
los puestos de trabajo asignados a los empleados. El requerimiento especfico, por parte del usuario es:
1. Controlar los siguientes aspectos de la forma en como se generan los reportes:
1. Configurar campos de ordenamiento
2. Cuando se debe generar el reporte: una copia de la ficha resumida o generar una impresin
completa.
2. Almacenar las preferencias de impresin y permitir cambios.
3. Mostrar un mensaje para confirmar que los cambios han sido realizados y almacenados.
6. Imprimir los cheques de pago para los empleados. El requerimiento especifica que cada vez que un
cheque sea impreso, se debe marcar el pago como pagado.

La planilla es generada mensualmente, y al salario base de cada empleado debe sumarse y restarse
respectivamente, las bonificaciones y los descuentos.
La empresa cuenta con sucursales en 20 pases al rededor del mundo y cada sucursal tiene un promedio de 15
empleados.
Las cuentas bancarias promedio son de 2 por pas.
Note que aunque no es un requerimiento explcito, es necesario proveer al usuario una forma de asignar los
puestos a los empleados. De otra manera no podra consultar los puestos asignados.

Identificando los ILF

Al hacer un anlisis ER del conjunto de datos que intervienen en el requerimiento, podemos llegar al siguiente
modelo lgico.

Cada una de las tablas del modelo ER constituye un ILF.

No obstante, el requerimiento 2 del usuario establece algunos campos de control para la configuracin del
formato de salida de los reportes de puestos. Asumiremos que esta configuracin no ser almacenada en la base
de datos, sino en un archivo de configuracin en formato XML. Dado que la informacin de control est
relacionada nicamente a la forma en que se generarn los reportes de puestos, podemos concluir que se trata de
un solo conjunto de datos relacionados, que no podemos dividir. Por tal razn, contar como un solo ILF.
El total de ILF de nuestro sistema ser 9. 8 correspondientes a las tablas de la base de datos y 1 archivo de
configuracin en formato XML.
Note que los campos IDs autogenerados no son contados como DET, puesto que no son reconocibles por el
usuario, pero si son contados cuando aparecen en otra tabla como llave fornea.
El atributo activo de la tabla asignacin no es contada, puesto que no es reconocida por el usuario. Dado que el
empleado puede cambiar de puesto en algn momento, el registro no ser modificado, ser desactivado y un
nuevo registro se agregar. La asignacin activa ser la que se muestre al usuario en todo momento.
Para el conteo de los RET identificamos aquellos atributos que son obligatorios para insertar un registro en la
entidad correspondiente. Por ejemplo, es posible insertar un registro en la entidad detalle_planilla sin que se
haya creado el registro de la planilla?. Es posible insertar un registro en la entidad detalle_planilla sin que se
haya creado el registro en la tabla asignacion?. Note que los atributos codigo_empleado y codigo_puesto son
una sola llave fornea en la entidad detalle_planilla, por lo que debern contar como un solo RET.
Note que los RET no se cuentan segn los DET del ILF o EIF, sino en funcin del conjunto de datos que se
encuentran en el archivo (sean o no DET).

ILF

RET

DET

COMPLEJIDAD

empleado

Simple

planilla

Simple

puesto

Simple

cuenta_bancaria

Simple

ILF

RET

DET

COMPLEJIDAD

detalle_planilla

Simple

cheque

Simple

descripcion_puesto

Simple

asignacion

Simple

configuracion_impresion

Simple

Los PF totales para los ILF se detalla a continuacin:

PARAMETRO DE MEDIDA

FACTOR DE PESO

CUENTA SIMPLE MEDIO

Archivos Lgicos Internos

COMPLEJO

TOTAL

63

PUNTOS DE FUNCION POR LOS ILF

63

Identificando los EIF

El requerimiento del usuario nos presenta la necesidad de que el sistema se comunique con otro sistema. Esto
significa que necesitaremos de una interfaz con el Sistema de Activo Fijo para consultar informacin de las
oficinas de la empresa.
Es claro que los datos de los empleados corresponden al ILF empleado y que los datos provenientes de la
aplicacin del Sistema de Activo Fijo, correspondern a un EIF.
Ya hemos identificado el EIF en nuestro modelo lgico de base de datos. Al aplicar la tabla de complejidad para
determinar los factores de peso a aplicar, tendramos:

EIF
edificio

RET

DET

COMPLEJIDAD

Simple

Los PF para las EIF se calcularn como sigue:

PARAMETO DE MEDIDA

FACTOR DE PESO

CUENTA SIMPLE MEDIO

Archivos de Interfaz Externa

TOTAL PUNTOS DE FUNCION POR LOS EIF

COMPLEJO

TOTAL

7
7

Identificando las EI
El requerimiento 1 especifica: La capacidad de mantener informacin de los empleados. Esto es ingresar,
consultar y generar reportes sobre los empleados. Al registrar un empleado nuevo, la fecha estimada de retiro
es calculada automticamente y almacenada como parte del registro del empleado. El requerimiento del
usuario incluye la capacidad para generar la lista de los empleados con sus fechas estimadas de retiro.
Resulta evidente que el requerimiento incluye una entrada de datos, ya que para almacenar los datos de un nuevo
empleado, los datos deben provenir de fuera de la aplicacin. Para registrar un empleado, la entrada har
referencia a un solo ILF: empleado. Los DET sern 5, ya que aunque tanto el cdigo del empleado como la fecha
estimada de retiro son calculados por el sistema, sern mostrados al usuario una vez guardados los datos.
Para el requerimiento de modificacin de los datos de un empleado debe considerarse la regla de conteo de EI
relacionada al proceso elemental: La lgica de procesamiento es nica, respecto a la lgica de procesamiento
realizado por otras EI?, El conjunto de elementos de dato es diferente del conjunto de datos identificados en
otras EI?, Los ILF o EIF son diferentes de otros archivos referenciados por otra EI?. Podemos concluir que el
requerimiento de edicin corresponde al mismo proceso elemental que el de registro.
Ntese que el requerimiento de Registro/Edicin de puestos hace referencia a las 2 tablas, que corresponde a una
entidad fuerte (puesto) y una dbil (descripcion_puesto). Adems, supondremos que los campos ID sern
identificadores autogenerados por la base de datos y que no sern mostrados al usuario en las interfaces de
entrada, de manera que los DET referenciados por la entrada solamente incluyen los datos ingresados por el
sistema.
Ntese tambin que el proceso asignacin de puestos conlleva dos consultas. La primera, una consulta sobre
cmo identificaremos al empleado al que deseamos asignar el puesto y el puesto que deseamos asignarle. Estos
procesos elementales sern contados en los respectivos apartados. Es importante resaltar tambin que los DET de
dicho requerimiento cuentan los IDs de las llaves forneas, puesto que salen (durante las consultas descritas
anteriormente) e ingresan nuevamente (cuando el usuario selecciona los elementos de dato correspondientes).
La interfaz para cumplir con el requerimiento de configuracin de los reportes de puestos puede suponerse de la
siguiente forma:

Como ya se mencion, la informacin recolectada por la EI no es informacin del dominio del sistema, sino
informacin de control. La identificacin de los DET supone que la lista desplegable con los nombres de los
campos est quemada en la interfaz, puesto que dichos campos no estn almacenados en ningn archivo fsico
o en una tabla de la base de datos.
Si partiramos del otro supuesto, tanto los FRT como los DET se veran afectados.
No obstante, es importante retomar la regla de identificacin de DET para EI: Contar un DET por la capacidad
de enviar un mensaje de error o confirmacin. Por tal razn, los DET identificados para esta entrada sern 3.
REQUERIMIENTO

FRT

DET

COMPLEJIDAD

Registro/Edicin de empleados

Simple

Registro/Edicin de puestos

Medio

Registro/Edicin de asignaciones de puesto

Simple

Configuracin de reportes de puestos

Simple

Los PF para las EI se detallan en la siguiente tabla:

PARAMETRO DE MEDIDA

FACTOR DE PESO

CUENTA SIMPLE MEDIO COMPLEJO TOTAL

Entradas Externas

Entradas Externas

TOTAL PUNTOS DE FUNCION POR LAS EI

13

Identificacin de las salidas

El requerimiento especifica que cada vez que un cheque sea impreso, se debe marcar el pago como pagado.
Ntese que la estructura del ILF cheque tiene 7 DET. Sin embargo, solamente son mostrados al usuario 3 DET
de dicho ILF. De igual manera, del ILF cuenta, nicamente se muestra al usuario 1 solo DET.
Ntese tambin que el proceso elemental mantiene uno de los DET del ILF cheque (pagado), cambiando su valor
a verdadero. Sin embargo, este campo nunca es mostrado al usuario, por lo que no debe contar como una DET.

PROCESO ELEMENTAL

FRT

DET

COMPLEJIDAD

Imprimir cheque

Simple

Nmina de empleados con sus fechas de

retiro

Simple

Consulta de empleados con sus respectivos

puestos de trabajo

10

Medio

Los PF para las EO se detallan continuacin:

PARAMETRO DE MEDIDA

FACTOR DE PESO

CUENTA SIMPLE

MEDIO

COMPLEJO TOTAL

Salidas Externas

Salidas Externas

TOTAL PUNTOS DE FUNCION POR EO

13

Identificando consultas
Las consultas pueden ocurrir como una requerimiento del usuario o como parte de una entrada. Las consultas
requeridas explcitamente por el usuario normalmente tienen implcita una entrada, el formulario a travs de los
que se especifican los criterios de filtrado. Tpicamente estos criterios de filtrado son acordados con el usuario.
En los casos de que no se tenga dicha especificacin, se puede asumir que los criterios de bsqueda sern todos
aquellos campos que no acepten valores nulos y que no contengan valores de texto muy largos como
descripciones, direcciones, etc.
El caso ms comn de las consultas que no son requerimientos especficos del usuario, que son llamadas
Consultas implcitas, son las listas desplegables (ComboBox) de los formularios de entrada.
Este es el caso de la EI de la asignacin de puestos. Para asignar un puesto a un empleado, primero hay que
seleccionarlo, por lo que es necesaria una consulta para mostrar los empleados al usuario. Una vez seleccionado
el usuario es necesario indicar qu puesto es el que se le va asignar. Para ello, es necesario mostrar los puestos
para que el usuario los seleccione en una lista desplegable.
En esta entrada, la consulta de empleados no cumplen con la regla de que, la lgica de procesamiento de la
consulta y los archivos referenciados sean diferentes a otras consultas identificadas, porque ya existen como
parte de la edicin de empelados. Sin embargo, la consulta de puestos, utilizada para llenar la lista desplegable
difiere respecto a la lgica de procesamiento de la consulta de puestos para edicin. En el primer caso, se
recuperan todos los puestos y en la segunda, se filtran de acuerdo a los criterios especificados por el usuario.
Lo mismo ocurre con la consulta de puestos asignados, puesto que la regla debe aplicarse para EO y EQ.
Tanto las consultas como las salidas pueden tener asociadas entradas para especificar los valores que el usuario
desea ver. Esto es lo que se conoce como la parte de entrada de la salida o la consulta. Sin embargo, esto no
debe ser contado como entrada.

REQUERIMIENTO

FRT

DET

COMPLEJIDAD

Registro/Edicin de Empleados

Simple

Registro/Edicin de puestos

Simple

Registro/Edicin de asignaciones de puestos

Medio

Simple

Registro/Edicin de
(Consulta de puestos)

asignaciones

de

puestos

El total de PF para las EQ se detalla en la siguiente tabla:

PARAMETRO DE MEDIDA

FACTOR DE PESO

CUENTA SIMPLE

MEDIO

COMPLEJO TOTAL

Consultas Externas

Consultas Externas

TOTAL PUNTOS DE FUNCION POR EQ

PARAMETRO DE MEDIDA

13

TOTAL

Archivos Lgicos Internos

63

Archivos de Interfaz Externa

Entradas Externas

13

Salidas Externas

13

Consultas Externas

13
TOTAL UFP

109

Para realizar el ajuste de los puntos de funcin, se aplica la siguiente frmula:

Donde los Fi son 14 valores de ajuste a la complejidad. Dichos valores son una serie de consideraciones para las
que debemos valuar el impacto que puedan tener en el sistema en desarrollo. Esta valuacin puede tomar valores
enteros entre 0 y 5, donde 0 ser un bajo impacto o necesidad de implementar dicho factor y 5 un alto impacto o
necesidad de implementar dicho factor.

CRITERIOS DE VALORES DE AJUSTE A LA COMPLEJIDAD

1. Comunicacin de datos. La necesidad de transferencia o intercambio de datos determinar la
complejidad del diseo arquitectnico del software. Por ejemplo, si la aplicacin a estimar se tratar de
un servicio Web, ser necesario desarrollar capas especiales para la transferencia de datos, utilizar
patrones de diseo y protocolos especficos para este tipo de sistemas. En este tipo de aplicaciones el
peso que asignaremos es de 5.
2. Procesamiento de datos distribuido. El procesamiento de distribuido implica la necesidad de crear
nodos especficos de procesamiento (software o base de datos).
3. Rendimiento. Los parmetros para determinar la criticidad del rendimiento son usualmente provistas
por el usuario. Tiempos de respuesta rpido, mantener el mismo nivel de rendimiento con una alta
concurrencia y alto rendimiento. A la hora de valuar este factor, se debe considerar que el esfuerzo para

alcanzar el rendimiento depender de la plataforma de operacin, tecnologa de desarrollo y las

herramientas utilizadas para el desarrollo.
4. Configuracin fuertemente utilizada. Se refiere a la necesidad de incorporar configuraciones
adicionales en el hardware sobre el que se ejecutar la aplicacin o incorporar al diseo caractersticas
especiales para poder ejecutar la aplicacin en el hardware o servicios (servidor de aplicaciones o
servidor de base de datos).
5. Taza de transaccin. Se refiere a la frecuencia con la que las transacciones sern realizadas:
diariamente, semanalmente, mensualmente, etc.
6. Entrada de datos en lnea. Se refiere a la necesidad de que la entrada de los datos debe ser interactiva y
en tiempo real. Para valuar este factor, se toma como base el porcentaje de la aplicacin que debe ser en
lnea.
7. Eficiencia del usuario final. El factor se mide en funcin del nivel de conocimiento informtico del
usuario, y es inversamente proporcional al mismo. Esto es, entre menos experiencia con sistemas de
informacin tenga el usuario, mayores sern los niveles de usabilidad requeridos. Para medir este factor,
usualmente se acude a la medicin de los siguientes requerimientos de usabilidad:
Ayuda para la navegacin. Accesos rpidos, mens dinmicos, teclas de funcin, etc.
Mens
Ayuda en lnea y documentacin
Movimientos automticos del cursor
Scrolling
Impresin remota va transacciones en lnea.
Teclas de funcin pre-asignadas
Procesos por lotes originados en transacciones en lnea
Seleccin de datos desde las interfaces
Alto uso de video, resaltado, subrayado en colores y otro tipo de marcadores.
Documentacin impresa para el usuario de las transacciones realizadas.
Interfaces de ratn
Ventanas emergentes
El menor uso posible de interfaces para completar funciones de negocio
Soporte de dos idiomas
Soporte de mltiples idiomas.
8. Actualizacin en lnea. Se refiere a la necesidad de controlar las transacciones de datos. Por ejemplo, si
dos usuarios se encuentran consultando los datos de la misma tabla, y uno de ellos modifica un dato, el
otro usuario deber ver el cambio en tiempo real.
9. Complejidad del procesamiento. Se refiere a la necesidad de utilizar un alto nivel procesamiento
lgico o matemtico. Los elementos a considerar son:

 Control sensible. Por ejemplo: procesos de auditora especiales o procesos de seguridad especficos.
Alto nivel de procesamiento lgico.
Alto nivel de procesamiento matemtico.
Cantidad alta de excepciones en el procesamiento dan como resultado, que deben ser procesados
nuevamente.
Procesamiento complejo para manejar mltiples posibilidades de entradas/salidas.
10. Reusabilidad. Puede referirse a dos cosas:
1. El cdigo fuente debe ser reutilizable.
2. El software ser reutilizado para otros propsitos.
11. Fcil de instalar. Se refiere al nivel de dificultad para instalar la aplicacin.
12. Facilidad de operar. Se refiere a la efectividad y automatizacin del inicio, respaldo y procesos de
recuperacin.
13. Mltiples ubicaciones. Si los usuarios estn diseminados en ubicaciones de pases diferentes o
geogrficamente distantes, ser necesario el soporte de caractersticas distintas para cada ubicacin:
moneda, reglas transaccionales como impuestos, etc.
14. Facilidad de cambios. Facilidad de mantenimiento.

Para el ejemplo que nos ocupa podemos decir que los criterios que deben considerarse son:

CRITERIO

VALOR

DESCRIPCION

No es necesaria una comunicacin especial. Las tecnologas

actuales soportan la transferencia de datos va Web normal.

Comunicacin de datos

Sin embargo, para efectos de seguridad, ser necesario utilizar

certificados de seguridad SSL.
Rendimiento

Taza de transaccin

Entrada de datos en lnea

Eficiencia del usuario final

Actualizacin en lnea

Complejidad de procesamiento

La informacin relacionada a la planilla tendr la caracterstica de

que, si algo falla, debe ser procesada nuevamente.

Mltiples ubicaciones

Se trata de una empresa transnacional

Facilidad de cambios

TOTAL

Mensual
Uno de los requerimientos nos indica que el usuario desea una
aplicacin con altos niveles de usabilidad

37

Los Puntos de funcin sern entonces:

FP=109 x ( 0 .65+ ( 0. 01 x 37 ) )=111. 18

La productividad se calcula a travs de la frmula:

Donde las personas-mes es el esfuerzo requerido para el desarrollo del sistema.

En general, la productividad suele ser un factor con el que se cuenta, ya sea por experiencias de proyectos
previos o por estimaciones. El caso tpico es que deseamos saber cuanto tiempo nos tomar el proyecto y cuanto
personal necesitamos para realizarlo.
Supongamos que conocemos que en un proyecto similar con la misma tecnologa de desarrollo, la productividad
es de 40 puntos de funcin por persona al mes (FP/persona-mes), podemos calcular el esfuerzo as:

personames=FP/ productividad=111. 18/ 40=2 .7795

El esfuerzo es la cantidad de personas por meses que requeriremos para el proyecto. En este caso,
aproximadamente 3 analistas-programadores por mes. Pero Cmo calculamos el tiempo del proyecto?.
Si el esfuerzo hubiera sido 12.75, requeriramos aproximadamente 13 analistas por mes. Aqu, tendramos que
encontrar el mejor de los escenarios para estimar el tiempo del proyecto, podemos suponer que tenemos 3
analistas, en cuyo caso el tiempo del proyecto ser de 4.25 meses, aproximadamente 17 semanas. Si suponemos
que contamos con 2 analistas-programadores, requeriramos de 6.375 meses, aproximadamente 17 semanas.
Para el ejemplo que nos ocupa. Si partimos de que tendremos 3 analistas programadores, el proyecto tendra una
duracin de 0.9265 meses, aproximadamente 1 mes. Si suponemos que tenemos 2 analistas programadores,
requeriramos 1.38975 meses, aproximadamente 6 semanas.
El costo por punto de funcin se calcula:

Costo por PF=

Costo total
FP

La estimacin realizada est centrada nicamente en los requerimientos especficos descritos por el usuario. En
nuestro anlisis hemos dejado fuera el proceso de generacin de planilla y el mantenimiento de las cuentas
bancarias. Por otro lado, hemos omitido los procesos elementales de eliminacin, que se cuentan como entradas
y usualmente conllevan mensajes de confirmacin. Tambin hemos omitido mensajes de errores producto de los
procesos elementales estimados, excepto el que fue requerido por el usuario explcitamente.
Todos estas caractersticas influirn en la estimacin de los FP y por ende en el esfuerzo.
Contine desarrollando el problema considerando que:
1. A la hora de generar la planilla el sistema deber generar los registros (tuplas) de la tabla
detalle_planilla. Una vez generados esos registros, el usuario deber ingresar los descuentos y
bonificaciones a cada empleado, dado que ambos elementos estn fuera del alcance del sistema.
2. A la hora de generar los cheques, el sistema asumir por defecto que el campo a_favor_de del cheque es
el nombre del empleado, por lo que deber copiar ese dato en el campo, proveniente de la tabla
empleado. Sin embargo, el usuario puede modificar dicho campo en caso de ser necesario. Por ejemplo,
el empleado a delegado a un apoderado para que cobre su salario mientras est fuera del pas.
3. Para generar los cheques es necesario que el usuario pueda filtrar a los empleados (por su puesto o
unidad en la que trabaja) e indique con qu cuenta bancaria se pagarn dichos cheques. Note que el
nombre de la oficina en la que trabaja debe provenir de la aplicacin de Activos fijos.

Evale la diferencia entre los resultados de las mtricas si se incorpora al sistema la capacidad para llevar un
control de los descuentos por: seguro social, fondo de pensiones, impuesto sobre la renta y otros tipos de
descuento como prstamos, cuotas de paternidad, inasistencias, etc.
El sistema deber calcular automticamente los descuentos de ley, y deber permitir al usuario ingresar los
descuentos adicionales como prstamos, cuotas de paternidad, inasistencias, etc.

B. PUNTOS DE FUNCION (NESMA FPA ISO/IEC 24570:2005)

La versin de NESMA (Asociacin Holandesa de Usuarios de Mtricas de Software -Netherlands Software
Metrics Users Association-), al estar basada en la definicin de la mtrica original, propuesta por Albrecht,
utiliza la misma terminologa respecto al estndar de IFPUG.
Ambas mtricas, distinguen los mismos tipos de funciones de usuario.
1. Funciones de datos:
1. Entradas externas (External Inputs) (EI).
2. Consultas externas (External inquires) (EQ)
2. Funciones de transaccin:
1. Archivos lgicos internos (Internal Logical Files) (ILF)
2. Archivos de interfaces externos (External Interface File) (EIF)
3. Salidas externas (External Outputs) (EO)

CONTEO DE PUNTOS DE FUNCION EN FASES TEMPRANAS DEL

PROCESO DE DESARROLLO
NESMA reconoce tres mtodos de conteo de puntos de funcin:
1. Puntos de funcin detallados
2. Puntos de funcin estimados
3. Puntos de funcin indicativos
El mtodo de conteo detallado es el que hemos descrito anteriormente para IFPUG. Adems de utilizar la misma
terminologa y nomenclatura, las reglas para determinar el tipo y complejidad de una funcin son las mismas en
ambos mtodos, con algunas diferencias que describiremos posteriormente. Antes, describiremos los dos
mtodos adicionales.
Los mtodos de puntos de funcin estimados e indicativos han sido desarrollados por NESMA para posibilitar el
conteo de puntos de funcin en fases tempranas del desarrollo.
En las fases tempranas de desarrollo suele ser comn que los requerimientos son poco claros, incompletos o no
se ha delimitado el alcance de la aplicacin a desarrollar. Esta situacin impide que podamos hacer una
estimacin detallada de los Puntos de funcin.

PUNTOS DE FUNCIN ESTIMADOS

Este mtodo consiste en identificar todos los tipos de funciones (ILF, EIF, EI, EO y EQ) de la misma forma que
el proceso detallado, pero asignando los valores de complejidad predefinidos as:

Asignar complejidad Simple a todas las funciones de transaccin.

Asignar complejidad Media a todas las funciones de datos.

PUNTOS DE FUNCIN INDICATIVOS

Este mtodo est basado nicamente en las funciones de datos (ILF y EIF).
Una vez identificados los ILF y EIF calcular el tamao indicativo con la siguiente frmula:

El tamao indicativo calculado corresponde a los puntos de funcin no ajustados.

PROYECTOS DE DESARROLLO Y PROYECTOS DE MEJORA

Una de las diferencias ms significativas de NESMA respecto a IFPUG es la estimacin de proyectos de mejora.
Mientras IFPUG estima el tamao total del sistema con los cambios incluidos, NESMA estima nicamente los
cambios a realizar.
Esto queda claro en la definicin de los tipos de medicin de puntos de funcin que realiza IFPUG, ya que
asume que los puntos de funcin de aplicacin sern actualizados una vez que se estime el proyecto de mejora.

DIFERENCIAS ENTRE IFPUG Y NESMA DETALLADO

Las deferencias entre ambas mtricas son muy pocas y de hecho despreciables.
Como hemos dicho anteriormente, ambos mtodos utilizan la misma terminologa y reglas muy similares para el
conteo de los tipos de puntos de funcin.
Podemos sealar como una ventaja el hecho de que NESMA describe ms detalladamente los criterios y reglas
que deben aplicarse para la identificacin y el conteo de los elementos de los tipos de funciones. Sin embargo,
algunos de esos criterios pueden reir con el criterio tcnico de quien aplica la norma, o resultar en un proceso
muy complejo para ciertos tipos de aplicaciones o tamaos de proyecto.
La ventaja de contar con una especificacin detallada de NESMA, depender del nivel de experiencia y criterios
del estimador.

CONSULTAS EXTERNAS VS. SALIDAS EXTERNAS

Para IFPUG, una EQ es definida como una funcin que presenta datos al usuario, provenientes de un ILF o de
un EIF, sin incorporar procesamiento adicional. Es decir, la lgica de procesamiento no incorpora clculos
matemticos, actualizaciones, etc.
Para NESMA, aplica la misma regla. Sin embargo, adicionalmente establece que para las EQ, debe especificarse
una clave nica de seleccin (una clave para el filtrado de los datos. Por ejemplo: un criterio de bsqueda).
En algunos casos, para el estndar IFPUG una funcin ser contada como una consulta externa, mientras que
para NESMA, ser contada como una salida externa. Por ejemplo, una interfaz para desplegar todos los clientes
de una empresa.
Ntese que esto significa que las reglas de conteo para ambas mtricas difiere en cuanto a qu, NESMA

considera que para una consulta externa debe especificar una opcin de filtrado, y dado que desplegar todos los
clientes de la empresa, no cuenta con dicho filtro, debe ser contada como salida externa. Sin embargo, para
IFPUG, las salidas deben contener al menos un clculo matemtico..

COMPLEJIDAD DE UNA CONSULTA EXTERNA

Para NESMA, la complejidad funcional del componente de entrada de una EQ est basada en las reglas de
complejidad para una EI. La complejidad del componente de salida est basada en las reglas de las funciones de
EO. La complejidad a usar en las consultas externas ser la mayor de las dos.
Para IFPUG la complejidad est determinada de la misma forma que las transacciones, contando el mismo
nmero de DET que salen de la aplicacin e identificando los FRT.

CONSULTA IMPLCITA
Cuando se modifica o se elimina un dato, los datos a menudo son presentados primero al usuario. Esto es
llamado una consulta implcita.
Para NESMA, el objetivo subyacente de una funcin siempre es el principal. NESMA por lo tanto no considera
la consulta implcita como una funcin de transaccin adicional, sino la asume como parte integral de la
modificacin (o la eliminacin). El tipo de elemento de dato presentado al usuario por la consulta implcita es
contada como parte de la modificacin (o eliminacin). NESMA solamente cuenta la consulta externa si esta es
especficamente identificada por el usuario para ese propsito o para consultas de datos.
IFPUG no cuenta con reglas especficas respecto a esta situacin. Generalmente, estas consultas implcitas son
contadas como consultas externas separadas en el estndar IFPUG, si no se han contado como otra funcin.

TABLAS DE CDIGOS
NESMA define las tablas de cdigos o tablas FPA (Funtcion Point Analisys Tables) como tablas que tienen
cualquiera de las siguientes caractersticas:
1. Una tabla que contiene un solo registro. Por ejemplo, una tabla que contiene informacin acerca de una
empresa en particular: nombre y direccin.
2. Una tabla que contiene solo datos constantes. Por ejemplo, una tabla que contiene los elementos de la
tabla peridica.
3. Catlogos de datos que contienen campos con la misma informacin en diferentes formatos. Por
ejemplo: La tabla tipo de cliente puede contener la descripcin del tipo de cliente y una abreviatura. Un
catlogo de productos puede contener, adems del cdigo del producto, una descripcin del producto en
diferentes idiomas: espaol, ingls, francs, etc.
4. Las tablas que contienen valores lmites, valores mnimos y mximos.

El proceso de conteo, NESMA clasificar todas las tablas de cdigos como un ILF o EIF segn sea el caso. El
nmero de RET ser el nmero de tablas de cdigo identificadas. Todas las tablas de cdigo generarn una IE,
EQ y EO. Si se trata de un EIF no se contarn como funciones de transaccin, aunque se existan EO o EQ.
IFPUG considera las tablas de cdigos como aspectos tcnicos de implementacin o requerimientos de calidad
del usuario, y no como parte de los requerimientos funcionales del usuario. IFPUG por lo tanto, no cuenta las
tablas de cdigo y las funciones transaccionales asociadas a ellas.

MEDIOS FSICOS
Dado que NESMA se centra en la funcionalidad subyacente, ignora los medios fsicos en el conteo de lo factores
de puntos de funcin.
Independientemente del medio desde que ingresen los datos al sistema, sern contados como una EI. Lo mismo
aplica cuando los datos sean almacenados en algn medio externo.
IFPUG no define ninguna regla al respecto, por lo que podemos suponer que al igual que NESMA, los datos
sern contados en las respectivas funciones.

CONSULTAS QUE CONTIENEN MLTIPLES CRITERIOS DE SELECCIN (SITUACIONES AND/OR)

En NESMA solamente son contadas las selecciones (consultas con criterios de bsqueda) mutuamente
excluyentes. Es decir, cuenta nicamente una combinacin de todos los criterios de seleccin.
En IFPUG no se especifican reglas para esta situacin. Algunos usuarios de IFPUG por lo tanto, cuentan como
funciones diferentes, cada combinacin de los criterios de seleccin.
Como criterio para la aplicacin de IFPUG, usaremos el criterio empleado por NESMA.

C. PUNTOS DE CASOS DE USO

Puntos de Caso de Uso (Use Case Point) es un mtodo de estimacin de esfuerzo para proyectos de software, a
partir de los casos de uso. Fue desarrollado por Gustav Karner en 1993 y fue supervisado por Ivar Jacobson.
Est basado en el mtodo de Puntos de funcin, pero basado en la idea de que los requerimientos funcionales del
usuario son descritos a travs de Casos de uso.
El modelo reconoce 4 elementos a contabilizar en el proceso:
1. Puntos de Casos de Uso sin Ajustar (Unadjusted Use Case Point) (UUCP). Que est basado en los
elementos ms importantes del anlisis de casos de uso.
1.1. Peso de los actores sin ajustar (Unadjusted Actors Weight)
1.2. Peso de los casos de uso sin ajustar (Unadjusted Use Case Weight)
2. Factores tcnicos de complejidad (Technical Complexity Factor) (TCF)
3. Factores ambientales (Enviroment Factors) (EF)

PUNTOS DE CASOS DE USO SIN AJUSTAR (UUCP)

De forma anloga que los Puntos de funcin no ajustados, el primer paso para calcular los puntos de casos de
uso es estimar los UUCP
Los UUCP son la sumatoria los pesos de los actores sin ajustar (UAW) y los pesos de los casos de uso sin ajustas
(UUCW).

PESO DE LOS ACTORES SIN AJUSTAR (UAW)

Para obtener el valor de los UAW se deben sumar los pesos de los actores que se espera tenga la aplicacin,
segn su tipo.
La complejidad de los actores se determina de acuerdo al tipo de actor. Los tipos de actores reconocidos en la
mtrica son:

Simple. Se trata de otra aplicacin externa, que deber interactuar con la aplicacin que deseamos
estimar. Esta interaccin se realizar mediante una interfaz de programacin definida y conocida
(Application Programming Interface API-).

Medio. Se refiere a otra aplicacin externa que deber interactuar con la aplicacin que deseamos
estimar. Esta vez, a travs de un protocolo de comunicacin. Un ejemplo de esto son los servicios Web
(SOAP, RESTful, etc.)

Complejo. Un usuario fsico que se espera interaccione a travs de una interfaz de usuario.

Los pesos de cada uno de los tipos de actores (AW) se muestran en la siguiente tabla:

TIPO

PESO

Simple

Medio

Complejo

PESO DE LOS CASOS DE USO SIN AJUSTAR (UUCW)

Para obtener el valor de los UUCW, se suman los pesos de los casos de uso que conformarn la aplicacin, segn
su nivel de complejidad. El peso de los casos de uso est determinada por el tipo de caso de uso del que se trate,
y del enfoque que utilicemos para su estimacin.

Enfoque transaccional
Ivar Jacobson (creador del concepto de casos de uso) describe una transaccin de caso de uso como un viaje ida
y vuelta, que inicia con el actor hacia el sistema y retorna al actor. Una transaccin es finalizada cuando el
sistema queda esperando por una nueva entrada.
En otras palabras, una transaccin es un evento, que el sistema debe responder y quedar en espera de una nueva
accin. Por ejemplo:
Supongamos un formulario en el que un usuario tenga que seleccionar un departamento del pas, y el sistema
debe mostrar en otra lista, los municipios que corresponden a ese departamento. La seleccin que hace el usuario
a la lista de departamentos, constituye un evento al que el sistema debe responder. El sistema llenar la lista de
municipios que corresponden y quedar en espera de un nuevo evento.
Posteriormente el usuario llena otros campos del formulario en cuestin y hace clic en el botn Guardar.
El sistema guarda los datos, limpia el formulario y finaliza el caso de uso.
En este ejemplo, el caso de uso tendr 2 transacciones. La primera ser, responder al evento de seleccionar un
departamento y la siguiente ser el de responder a la solicitud de almacenar los datos.
Cuntas transacciones tendra el caso de uso si ambas listas, la de departamentos y la de municipios fueran
llenadas desde que se carga el formulario y no se requiriera que se filtren los municipios?. El caso de uso
solamente tendra una transaccin.

Consideraciones para identificar las transacciones en un caso de uso:

1. Las transacciones no siempre son los pasos del caso de uso. Las transacciones deben conllevar un ciclo
completo de ida y vuelta entre el actor y el sistema. Esto es especialmente importante para sistemas Web,
donde algunas validaciones o mensajes son mostrados del lado del cliente, en este caso; los eventos del
actor no llegan hasta el servidor.
2. Las transacciones no son actividades de la base de datos. Algunos autores suelen definir las
transacciones de un caso de uso como el conjunto de operaciones CRUD que se realizan en dicho caso
de uso. Aunque en la prctica suele ser una aproximacin muy buena, no siempre es vlido,
especialmente cuando se trata de sistemas que no utilizan bases de datos o archivos de almacenamiento.
En los casos en que la aplicacin utilice almacenes de datos, es posible encontrar un caso de uso en el
que el sistema deba realizar operaciones con los datos de entrada, posteriormente mostrarlos al usuario

para su verificacin/modificacin y hasta una segunda iteracin guardarlos a solicitud del actor.
En este caso, los clculos realizados por el sistema constituyen una transaccin, sin haber realizado
ninguna operacin de base de datos.
3. Se debe mantener las transacciones de casos de uso en el nivel adecuado. Supongamos que un
requerimiento de usabilidad del cliente es que se incorporen mtodos abreviados o combinaciones de
teclas para acceder a ciertas operaciones del sistema (como Ctrl + G). El sistema reaccionar ante una
combinacin de teclas, pero eso no necesariamente debe ser contado como una transaccin, sino ms
bien como uno de sus pasos.
4. Transacciones y flujos de eventos. Debe tomarse en cuenta que las especificaciones de los casos de uso
persiguen ser abstractas y por ende genricas. En el ejemplo anterior del formulario de departamentos y
municipios, si el usuario selecciona primero el departamento de San Salvador y posteriormente el de San
Miguel, no se trata de dos transacciones del caso de uso, sino ms bien de uno solo.
5. Los flujos alternativos tendrn al menos una transaccin. Supongamos que al momento de iniciar el
proceso de almacenamiento del formulario del ejemplo anterior ocurre un error. La transaccin del flujo
normal (el proceso de almacenamiento), iniciar una nueva transaccin para que el sistema muestre un
mensaje de error al usuario y queda en espera de que el usuario modifique los datos o cancele la
operacin. O que muestre al usuario una forma alternativa de realizar el proceso.

En el enfoque transaccional, la complejidad de los casos de uso se define como sigue:

Simple. El caso de uso incluye al menos 3 transacciones.

Medio. El caso de uso incluye entre 4 y 7 transacciones.

Complejo. El caso de uso incluye ms de 7 transacciones.

La tabla de pesos de los casos de uso (UCW) en este enfoque es la siguiente:

TIPO DE CASO DE USO

PESO

Simple

Medio

10

Complejo

15

Enfoque estructural
Este enfoque est basado en las clases de anlisis, que considera el nmero de clases que usar cada caso de uso
para realizar lo requerido.
En este enfoque la complejidad de los casos de uso se define como sigue:

Simple. El caso de uso utiliza menos de 5 clases.

Medio. El caso de uso utiliza entre 5 y 10 clases.

Complejo. El caso de uso utiliza ms de 10 clases.

La tabla de pesos de los casos de uso en este enfoque es la siguiente:

TIPO DE CASO DE USO

PESO

Simple

Medio

10

Complejo

15

Este enfoque es menos utilizado, dado que requiere de un anlisis ms profundo de los requerimientos. Un
modelo conceptual de clases es requerido para la aplicacin de este enfoque.
Los puntos de casos de uso ajustados (o simplemente puntos de casos de uso, Use Case Points -UCP-). Se
calculan multiplicando los UUCP, por los TCF, por los EF, as:

Los factores pueden ser valuados con valores discretos entre 0 y 5. Donde el valor de 0 significa que el factor es
relevante y 5 significa que el factor es esencial

FACTORES DE COMPLEJIDAD TCNICA (TCF)

El factor de ajuste de la complejidad tcnica se calcula mediante la valuacin de un conjunto de los factores que
determinan la complejidad tcnica de la aplicacin a desarrollar.
Los factores a considerar con sus respectivos pesos son:

FACTOR

DESCRIPCION

PESO

T1.

Sistema distribuido

T2.

Rendimiento

T3.

Eficiencia del usuario final

T4.

Complejidad del procesamiento

T5.

Reusabilidad

T6.

Fcil de instalar

0.5

T7.

Facilidad de uso

0.5

T8.

Portabilidad

T9.

Facilidad de cambios

T10.

Concurrencia

T11.

Seguridad

T12.

Provee acceso directo a terceros

T13.

Se requiere facilidades especiales de entrenamiento a usuarios

El total de factores tcnicos (TF) se calcula de la siguiente forma:

Donde WTi son los pesos correspondientes a cada uno de los factores de ajuste y VTi son los valores asignados.
El TCF se calcula:

FACTORES AMBIENTALES (EF)

Los factores ambientales se refieren a la experiencia y capacidades del equipo de desarrollo.

FACTOR

DESCRIPCION

PESO

E1.

Familiarizado con el proyecto de desarrollo

1.5

E2.

Experiencia en la aplicacin

0.5

E3.

Experiencia en orientacin a objetos

E4.

Capacidad del analista lder

0.5

E5.

Motivacin del equipo

0.5

E6.

Estabilidad de los requerimientos

E7.

Personal a tiempo parcial

-1

E8.

Lenguaje de programacin complejo

-1

El total de los factores ambientales es:

Donde WEi son los pesos correspondientes a cada factor, y VEi son los valores asignados.
El EF se calcula:

ESFUERZO (E)
Para el clculo del esfuerzo utilizaremos la propuesta de Scheider y Winters. La propuesta consiste en utilizar los
EF para estimar el esfuerzo individual de cada miembro del equipo de trabajo, utilizando los siguientes factores
de conversin (CF).

Se contabilizan cuantos factores que afectan al EF estn por debajo del valor medio (3), para los factores
E1 a E6.

Se contabilizan cuantos factores que afectan al EF estn por encima del valor medio (3), para los
factores E7 y E8.

Este conteo permitir eligir el factor de conversin de Horas-Persona/UCP, de acuerdo a la siguiente tabla:

HORAS-PERSONA (CF)

INTERVALO

20

<=2

28

<=4

36

>=5

El esfuerzo entonces ser calculado:

Esta estimacin asume que el esfuerzo estimado corresponde nicamente a la fase de programacin del proyecto.
Para calcular el esfuerzo total del proyecto se utiliza la siguiente tabla:

ACTIVIDAD

PORCENTAJE

Anlisis

10%

Diseo

20%

Programacin

40%

Pruebas

15%

Implementacin

15%

La suposicin de que el esfuerzo estimado corresponde nicamente al 40% del esfuerzo total del proyecto suele
dar como resultado tiempos muy grandes en relacin a otras mtricas. 1

1. El esfuerzo de desarrollo orientado a objetos usualmente conlleva metodologas no secuenciales, por lo que el
esfuerzo calculado debera representar al menos las fases de anlisis, diseo y programacin, que representan el
70% del esfuerzo total del proyecto. [Nota del autor]

EJEMPLO
Retomaremos el ejemplo desarrollado a travs de Puntos de funcin.

Identificando actores
Dada la definicin de los actores de los casos de uso, podemos observar claramente que tendremos dos actores.
El usuario de RRHH o Encargado de planilla y el Sistema de Activos Fijos.
Asumiremos que la interfaz a travs de la que se comunicar con el Sistema de Activos Fijos ser a travs de
componentes de software programados a travs de un API conocido. Esto es, que desarrollaremos un
componente del software que se conectar a la base de dicho sistema para acceder a los datos.

ACTOR

CANTIDAD

TIPO

Usuario RRHH

Complejo

Sistema de activos fijos

Simple

TIPOS DE
ACTORES

CUENTA

FACTOR

TOTAL

Simple

Complejo

TOTAL DE UWA

Identificacin de casos de uso

CASO DE USO

TRANSACCIONES

TIPO

Consultar empleados

Simple

Ingresar/Editar empleados

Simple

Consultar empleados por puesto de trabajo

Simple

Asignar puesto de trabajo

Simple

Consultar puesto de trabajo

Simple

Ingresar/Editar puesto de trabajo

Simple

Configurar preferencias de impresin

Simple

Generar cheques

Simple

TIPOS DE CASOS
DE USO
Simple

CUENTA

FACTOR

TOTAL

40

TOTAL DE UWC

UUCP= 4+ 40=44

40

Determinando los TCF

FACTOR

DESCRIPCION

VALOR

PESO

TOTAL

T2. Rendimiento
T3.Eficiencia del usuario final

Uno de los requerimientos nos indica que

el usuario desea una aplicacin con altos
niveles de usabilidad

T7. Facilidad de uso

De nuevo, el mismo requerimiento nos

indica que el usuario desea una aplicacin
con altos niveles de usabilidad

0.5

2.5

T9. Facilidad de cambios

T11. Seguridad

TOTAL DE TF

22.5

Identificando los EF
FACTOR

VALOR

PESO

TOTAL

E1. Familiarizado con el proyecto de El equipo no est familiarizado con este

desarrollo
tipo de proyectos de desarrollo

1.5

E2. Experiencia en la aplicacin

Dado que se trata de un proyecto nuevo,

no se cuenta con experiencia en esta
aplicacin

0.5

E3. Experiencia en orientacin a El equipo si cuenta con experiencia con

objetos
desarrollo Orientado a Objetos

E4. Capacidad del analista lder

Capacidad y experiencia

0.5

2.5

E5. Motivacin del equipo

El equipo siempre est motivado

0.5

2.5

E6. Estabilidad de los requerimientos

Los requerimientos son claros

10

E7. Personal a tiempo parcial

No se tiene personal a tiempo parcial

-1

-1

E8. Lenguaje
complejo

de

DESCRIPCION

programacin El lenguaje no es complejo

TOTAL DE EF

UCP=UUCPxTCFxEF= 44 x 0 . 825 x 0 . 8=29 . 04

20

Calculando el esfuerzo
Identificando el factor de conversin
EF que estn debajo de la media de E1 a E6: 2
EF que estn encima de la media de E7 y E8: 0
CF: 20 horas-persona

E=UCPxCF=29 . 04 x 20=580.8
El esfuerzo requerido ser de 580.8 horas-persona. Suponiendo que tenemos un equipo de desarrollo de 3
personas. La fase de programacin del proyecto se realizar en 1.21 meses. Es decir, aproximadamente 5
semanas.

ACTIVIDAD

PORCENTAJE

TIEMPO (Meses)

Anlisis

10%

0.30

Diseo

20%

0.61

Programacin

40%

1.21

Pruebas

15%

0.45

Implementacin

15%

0.45

TOTAL

3.025

Para contrastar esta respuesta, calcularemos cuanto ser el tiempo de desarrollo si asumimos que la estimacin
incluye las tres primeras fases del proceso de desarrollo:

ACTIVIDAD

PORCENTAJE

Anlisis

10%

Diseo

20%

Programacin

40%

Pruebas

15%

0.26

Implementacin

15%

0.26

TOTAL

TIEMPO (Meses)
1.21

1.73