2.

ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

4. ESTIMACIN EN
DESARROLLO DE
SOFTWARE.
1. INTRODUCCIN.
Este tema se centra en la estimacin del esfuerzo que tendr que realizar
una empresa para desarrollar una aplicacin. Por esfuerzo nos referimos a la
cantidad de recursos humanos, usualmente medidos en meses/hombre.
Partiremos de que ya se ha realizado un anlisis estructurado y disponemos
de la especificacin de requerimientos del sistema. Por desgracia esto no es
habitual, como dice Edward Yourdon un problema de la estimacin es que se
nos pide que la realicemos cuando an no est claro que desea el usuario (no
disponemos de la especificacin).
Comparando esta ingeniera con la arquitectura (construccin de
edificios), el arquitecto para valorar lo que costar construir un edificio
necesitar tener los planos de ste. Adems, lo que en urbanismo se conoce
con el nombre de edificio singular ,edificios que tienen formas extraas (la
Sagrada Familia de Gaudi, etc.), tienden a salirse del standard y deben ser
valorados cuidadosamente. En el desarrollo de software nos podemos
encontrar con algo similar, la gran mayora de las aplicaciones que se
desarrollan se hacen muy a medida del usuario, es decir se apartan con
mucha frecuencia de lo que seran aplicaciones fcilmente estimables.
Descompondremos el proceso de estimacin del esfuerzo necesario para
realizar el desarrollo de una aplicacin informtica como muestra la figura 1.

13

figura 1
PLANIFICACIN DE PROYECTOS INFORMATICOS

Especificacin de
requerimientos

Medir lo que
quiere el
usuario

Medida de lo que
quiere el usuario

Requisitos a
Cumplir

Tareas a
realizar

Estimacin Descomponer
del Esfuerzo por fases y
tareas
Estimar lo
que Costara
(esfuerzo)

Historial
Empresa

MEDIR LO QUE QUIERE EL USUARIO, volviendo al ejemplo anterior

sera como medir la casa que se quiere es decir lo que seran m2 de suelo,
pilares, vigas, etc., (en otros temas veremos lo relacionado con las calidades
y tambin los riesgos de construir en zonas ssmicas). Conociendo los
elementos (pilares, etc.) de los que constar nuestro sistema, pasamos a
valorar cada uno de ellos. Hay pilares gordos, finos, altos y bajos, cada uno
requiere una cantidad de hormign diferente, un trabajo de encofrado, etc..
Para valorar cada elemento utilizaremos medidas "objetivas" (con
estadsticas anteriores) y una dimensin "homognea". En el caso de la
construccin es difcil pensar en una medida "homognea" ya que intervienen
muchas dimensiones m3 hormign, m2 cristal, horas de trabajo, etc.. En el
caso de proyectos informticos esta medida har referencia, de forma
indirecta, a la cantidad de esfuerzo humano y tcnico a aplicar. Sumando las
valoraciones de cada elemento obtendremos una primera aproximacin del
esfuerzo demandado.
Tambin deberemos valorar otros factores que pueden afectar al coste,
tales como el tener que armonizar con el entorno o si el lugar de
construccin es muy lluvioso o muy fro.
A lo largo del tema transferiremos esta estructura de clculo al caso de
proyectos informticos.

14

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

ESTIMAR LO QUE COSTAR, Una vez medido lo que quiere el

usuario debemos estimar lo que le costar a nuestra empresa desarrollar este
proyecto. Para realizar este proceso hace falta experiencia en valoraciones.
Esta experiencia puede gestionarse de dos formas diferentes, individual y de
empresa:
La experiencia individual es la que aporta un individuo de la
organizacin que, tras acumular muchas experiencias en su mente,
tiene una apreciacin de "por donde van los tiros".
La experiencia de empresa se basa en la informacin que sta ha ido
acumulando en ficheros histricos sobre valoraciones realizadas y
costes reales de desarrollos realizados.
sta ltima forma de experiencia es ms deseable que la primera ya que
permite un mayor cmulo de informacin, ms proyectos. Tambin es menos
dependiente de las personas, con lo que la empresa ser ms estable a
posibles prdidas de personal. Adems esta ms estructurada ya que se
pueden recoger todas las medidas que los diferentes directores de proyecto
estimen necesarias. Por ejemplo podra recoger informacin sobre
herramientas usadas, grado de experiencia al aplicarse, etc.. Esto no quiere
decir que la primera sea innecesaria, sino que habr que conjugar las dos, ya
que siempre habrn momentos en los que aplicar el "sentido comn" y este es
imposible de sintetizar completamente.
DESCOMPONER EL ESFUERZO POR FASES. Una vez obtenido el
esfuerzo, meses/hombre o similares, hay que asignar estos esfuerzos a tareas
y personas, dado que no suele cobrar lo mismo el analista que el
programador, el que tiene experiencia y el que no, etc.. Lo razonable es
identificar a grandes rasgos las diferentes componentes del proceso de
desarrollo del software de modo que cada a una se pueda asignar un tipo
determinado de personal.
Una vez conocidas las tareas a realizar se deber programar (planificar), el
proceso de desarrollo y de esta planificacin obtendremos una estimacin
econmica del coste. Este punto lo veremos en otros temas.

15

PLANIFICACIN DE PROYECTOS INFORMATICOS

En este tema revisaremos varios mtodos para realizar estimaciones del

coste de software. Nos centraremos en uno de los que actualmente tiene ms
respaldo entre los consultores, adems de soporte con herramientas CASE e
incluso parece ser que se encamina a transformarse en un standard.

2. METODOS UTILIZADOS PARA LA ESTIMACIN

DE PROYECTOS.
La estimacin de proyectos acompaa a cualquier ingeniera y la
informtica no es una excepcin. Otro tema son los mtodos utilizados y su
fiabilidad (conformidad con los resultados obtenidos). Dada la juventud de la
informtica hasta hace poco no se vislumbraban mtodos estndar. Esta es
una de las razones que hace aconsejable el hacer un pequeo repaso a los
mtodos utilizados hasta hoy en da. La siguiente clasificacin ha sido
ampliada en clase:
Mtodos basados exclusivamente en la experiencia:
Juicio experto
Puro, tal y como lo propone Gibson (pgina 59)
Delphi que es la propuesta de OConell (pgina 128)
Analoga. King en la pgina 86 da una visin detallada, aunque
con estos mtodos cada uno se lo adapta. OConell tambin lo
comenta
Distribucin de la utilizacin de recursos en el ciclo de vida como
base de la estimacin como propone King (pgina 86)
Mtodo basado exclusivamente en los recursos: Parkinson:
Mtodo basado exclusivamente en el mercado: Precio para vender

16

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

Mtodo basado en los componentes del producto a desarrollar o

proceso de desarrollo:
Top-Down
Bottom-up
Mtodos algortmicos, se basan en la utilizacin de frmulas que
aplicadas sobre modelos top-down o bottom-up producen una
estimacin de coste del proyecto
Barry W. Boehm en su articulo titulado Software Engineering
Economics hace un repaso de algunos de estos mtodos.

3. PUNTOS DE FUNCIN.
Esta tcnica de medicin y estimacin trata de evaluar una aplicacin
informtica en base a sus caractersticas externas. Estas caractersticas se
descomponen en dos grupos: la funcionalidad que provee el sistema y los
factores de complejidad. La funcionalidad que provee el sistema son aquellos
elementos que dan soporte a formularios de entrada, salidas, consultas y
ficheros a los que debe dar soporte la aplicacin. Los factores de
complejidad son indicadores del entorno en que se ha de desarrollar y
explotar la aplicacin informtica.
Este mtodo de estimacin contempla la aplicacin a desarrollar como
una caja negra, es decir, no se interesa por las interioridades de la aplicacin,
sino que se centra en lo que puede ver el usuario.
El ejemplo clsico de una caja negra es el equipo de msica, en el que los
usuarios estn interesados por su funcionamiento externo, la calidad del
sonido y el coste, prescindiendo usualmente de como estn construidos los
circuitos integrados o sus transistores.
Por otra parte evaluamos de forma explcita los factores de desarrollo que
influyen sobre la productividad como lenguajes de desarrollo, entornos de
trabajo, etc. Seguiremos manteniendo la idea de caja negra, ya que los
17

PLANIFICACIN DE PROYECTOS INFORMATICOS

gestores del desarrollo no estn interesados en cmo se desarrolla en cada

lenguaje (ensamblador, 4GL, etc.) sino que se centran en los diferentes
niveles de productividad que se tiene con cada uno de ellos. El que realiza la
estimacin necesitar tener informacin histrica que sea apropiada sobre los
lenguajes, como veremos ms adelante.
3.1. IDENTIFICACIN DE LOS ELEMENTOS DE FUNCIN.
Partimos de una especificacin de la aplicacin a desarrollar, en nuestro
caso suponemos que est disponible el DFD de sta, el modelo EntidadRelacin de los datos y el Diccionario de Datos que definen a la aplicacin.
La funcionalidad que provee el sistema esta asociada a los siguientes
componentes de la aplicacin:
Entradas desde el exterior del sistema (Pantallas, lecturas de scanner,
etc.).
Salidas al exterior (Pantallas, Listados, etc.).
Consultas (entrada seguida de una salida).
Ficheros lgicos internos, grupos de datos que se mantienen
internamente.
Ficheros de interfaz, grupos de datos que se mantienen externamente.
Veamos algunas definiciones previas:
Proceso elemental: es la menor unidad de actividad que tiene sentido
para el usuario, conocedor del sistema en estudio.
Datos e informaciones de control: son los datos elementales con que
trabaja la aplicacin en estudio. Nos referiremos a ellos siempre como
datos aunque se componen de los Datos propios del sistema en estudio
ms las Informaciones de Control que solicita el usuario (mensajes de
error, claves de seguridad, etc.)

18

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

figura 2

Lgica de proceso: se trata de procesos que se producen como

consecuencia de un proceso elemental y puede ser de dos tipos:
Ediciones, algoritmos o clculos
Accesos a un fichero ya sea para consulta o actualizacin
Veamos en detalle cada tipo de elemento de funcin, su definicin, y
ejemplos de stos.
3.1.1. ENTRADAS DESDE EL EXTERIOR DEL SISTEMA.
En esta categora clasificaremos todos los procesos elementales que hacen
llegar a la aplicacin datos desde
el exterior, provenientes de un
usuario o de otra aplicacin. El
flujo de datos deber tener una
sola direccin, del exterior al
interior. Como consecuencia de
una entrada siempre deber
actualizarse un fichero lgico
interno. En la figura 2 se muestra
su apariencia en el DFD.

Ejemplo de estas entradas son los procesos asociados a:

Pantallas para entrada de datos a la aplicacin en cada transaccin.
Otros tipos de entradas como lecturas de cdigos de barras, tarjetas
magnticas, captura de imgenes, voz, o cualquier otro sistema que se
utilice para obtener informacin suministrada por el usuario.
Un mismo formato externo de pantalla de entrada que se utilice varias
veces, se contar como diferentes procesos en el caso de estar soportado con
19

figura 3
PLANIFICACIN DE PROYECTOS INFORMATICOS

una lgica distinta. Nos realizamos las siguientes preguntas para asegurarnos
de contar una entrada:

Cuestin:
Entran datos desde exterior de la aplicacin
Existen datos en algn fichero lgico interno que son actualizados
El proceso es la unidad mnima de actividad que tiene sentido para el
usuario
El proceso es completo y deja al sistema en un estado consistente
Para el proceso subyacente se debe de cumplir
A
Lgica del proceso exclusiva de esta entrada, o la primera vez
que la contamos
B
Los datos elementales son diferentes de otras entradas

Respuesta
S
S
S
S
AoB

3.1.2. SALIDAS
En esta categora clasificaremos los procesos elementales que elaboran
informaciones dentro del sistema y que se transmitan a un usuario u otra
aplicacin atravesando la frontera del sistema. En la figura 3 se muestra su
apariencia en el DFD.
Las salidas estn asociadas a:
20

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

Pantallas para informar al usuario del resultado de un proceso. Este

puede ser correcto o errneo.
Listados que se producen como consecuencia de un proceso, incluimos
cualquier formato, ya sean textos, grficos, cdigos de barras, etc..
Formatos especiales de salida como grabacin de bandas magnticas,
etc.
Transferencias de datos a otras aplicaciones, ya sea mediante ficheros
editados con el formato requerido o transmisiones de datos.
Identificaremos distintas salidas aunque tengan el mismo formato si la
lgica de generacin es diferente, o viceversa aunque tengan la misma lgica,
difieran los datos elementales que la componen.
Si de un mismo listado se hacen varias copias para enviar a diferentes
usuarios, slo se contar una vez. Por el contrario si un listado incluye varias
lgicas de generacin se contar varias veces, por ejemplo listado de
compras de clientes se podra componer de un listado individualizado y a
continuacin de un listado resumido por zonas. Los mensajes de error que se
producen en la edicin de una entrada no se han de contar, ya que pertenecen
a la entrada.
Nos realizamos las siguientes preguntas para asegurarnos de contar una
salida:
Cuestin:
El proceso enva datos o informacin al exterior de la aplicacin
El proceso es la unidad mnima de actividad con sentido para el usuario
El proceso es completo y deja al sistema en un estado consistente
Para el proceso subyacente se debe de cumplir
A Lgica del proceso exclusiva de esta salida (o primera vez)
B Los datos elementales son diferentes de otras salidas

Respuesta
S
S
S
AoB

21

figura 4
PLANIFICACIN DE PROYECTOS INFORMATICOS

3.1.3. CONSULTAS.
En esta categora clasificaremos los procesos elementales que estn
formados por una combinacin de entrada y salida, produciendo una consulta
a los datos.
La salida no puede contener informacin derivada (calculada). Como
consecuencia de una consulta no se modifican los datos del sistema (de
ningn Fichero Lgico Interno).
En la figura 4 se muestra su
apariencia en el DFD.

Son usuales en los sistemas EN_LNEA, Las entradas de datos

EN_LNEA suelen ir precedidas de una consulta.
Nos realizamos las siguientes preguntas para asegurarnos de contar una
consulta:
Cuestin:
Una peticin atraviesa la frontera del sistema
El proceso enva datos o informacin al exterior de la aplicacin
Se recuperan datos
No se calculan datos derivados para enviar al exterior
El proceso (entrada/salida) es la unidad mnima de actividad que tiene
sentido para el usuario
El proceso es completo y deja al sistema en un estado consistente
El proceso no actualiza ningn Fichero Lgico Interno
Para el proceso subyacente se debe de cumplir

22

Respuesta
S
S
S
S
S
S
S
AoB

figura 5
2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

A
B

Lgica del proceso en su parte de entrada o salida, es distinto del de

otras consultas del sistema (o la primera vez)
Los datos elementales de la entrada o salida son diferentes de otras
consultas

3.1.4. FICHEROS LGICOS INTERNOS.

Un fichero lgico interno es un grupo de datos relacionados, tal y como
los percibe el usuario y que son mantenidos por la aplicacin. Es decir, como

se usaran en un sistema manual.

Es importante diferenciar estos de las entidades, relaciones, las tablas o
los ficheros resultantes del diseo fsico. Se identifican a las agrupaciones de
datos que el usuario ya conoce como relevantes para el sistema, por ejemplo:
Clientes, Artculos, Facturas, Proveedores, etc.
Los ficheros se cuentan una sola vez independientemente del nmero de
procesos o frecuencia con que sean accedidos. Por supuesto de las veces que
aparezcan en los DFD para mejorar la legibilidad.
No hay que contar los ficheros de ndices ni los ficheros intermedios
creados durante el diseo para simplificar el desarrollo, por ejemplo ficheros
de spool por no disponer de impresora dedicada, etc.. Los ficheros
intermedios inherentes a la filosofa de la aplicacin s que se cuentan, por
ejemplo matrcula-curso-97-98 que es actualizado por la aplicacin y que el
usuario ha solicitado su existencia hasta que se cierre la matrcula del curso y
que ms tarde se consolida en el fichero de alumnos UPV, etc.
23

PLANIFICACIN DE PROYECTOS INFORMATICOS

figura 6

Nos realizamos las siguientes preguntas para asegurarnos de contar un

Fichero Lgico Interno:
Cuestin:
Se trata de una agrupacin de datos lgica o identificable desde el punto de
vista del usuario y satisface un requerimiento especfico del usuario
La agrupacin de datos es mantenida por procesos de la aplicacin en
estudio
La agrupacin de datos es mantenida mediante un proceso elemental de la
aplicacin
La agrupacin de datos no ha sido contada como un fichero de interfaz
externo

Respuesta,
S
S
S
S

3.1.5. FICHEROS DE INTERFAZ EXTERNOS.

DIAGRAMA DE CONTEXTO

Un fichero de interfaz externo es un grupo de datos relacionados, tal y

como los percibe el usuario, referenciados por la aplicacin, pero mantenidos
por otra aplicacin. Es decir, nuestra aplicacin nunca actualizar un fichero
de este tipo y adems ser un fichero interno de otra aplicacin.
Pueden ser ficheros que son generados por otra aplicacin y distribuidos
en la empresa. Aparecern en el diagrama de contexto. Si el fichero que
aparece en el diagrama de contexto lo utiliza un proceso para cargar ficheros
internos, entonces se deber contemplar como una entrada. En caso de
escribirse un fichero, que aparece en el diagrama de contexto, con el fin de
que sea entrada a otra aplicacin, deber contarse como una salida. Slo
contaremos como ficheros externos a aquellos que son mantenidos por otras
aplicaciones y de los que nuestra aplicacin hace uso.
24

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

Nos realizamos las siguientes preguntas para asegurarnos de contar un

Fichero de Interfaz Externo:
Cuestin:
Respuesta
Se trata de una agrupacin de datos lgica o identificable S
desde el punto de vista del usuario y satisface un
requerimiento especfico del usuario
La agrupacin de datos es referenciada, y externa, a la S
aplicacin en estudio
La agrupacin de datos no es mantenida mediante la S
aplicacin en estudio
La agrupacin de datos ha sido contada como un fichero S
lgico Interno en otra aplicacin
La agrupacin de datos no ha sido contada como un fichero S
lgico Interno de la aplicacin en estudio
3.2. CLCULO DE LOS PUNTOS DE FUNCIN SIN AJUSTAR.
Las siguientes tablas muestran como clasificar los diferentes elementos de
funcin y asignarles pesos. As por ejemplo una entrada que contenga 10
atributos y que en su lgica se requiera acceder a un fichero diremos que se
clasifica de complejidad baja y tiene asociados tres puntos de funcin, ver
tablas adjuntas.
CLASIFICACIN
ENTRADAS
0 1 ficheros accedidos
2 ficheros accedidos
3 ms ficheros accedidos

Nmero de
Campos o
1-4 Atributos

CLASIFICACIN
SALIDAS
0 1 ficheros accedidos
2 3 ficheros accedidos
4 ms ficheros accedidos

Nmero de
Campos o
1-5 Atributos
BAJA
4
BAJA
4
MEDIA
5

BAJA
BAJA
MEDIA

5-15 Atributos
3
3
4

BAJA
MEDIA
ALTA

6-19 Atributos
BAJA
4
MEDIA
5
ALTA
7

4
6

16 ms Atrib.
MEDIA
4
ALTA
6
ALTA
6

20 ms Atrib.
MEDIA
5
ALTA
7
ALTA
7

En el caso de las consultas diferenciaremos la complejidad de lo que sera

la entrada y la salida, le asignaremos la complejidad mayor de las dos (baja,
media o alta), pero solo un peso (3, 4 6), equivalente al de una entrada de
la complejidad calculada.
25

PLANIFICACIN DE PROYECTOS INFORMATICOS

Los ficheros de las entradas, salidas y consultas se calculan a partir de los

ficheros, lgicos internos o de interfaz externos, que son accedidos durante
el proceso asociado.
Los atributos son tipos de datos elementales reconocibles por el usuario.
En las entradas se contarn tambin aquellos datos que son almacenados en
un fichero como consecuencia de la entrada. Los datos que se almacenen en
muchos campos se contarn slo una vez. Ejemplo DNI en la gestin de
notas. En las salidas se contarn los campos calculados, por ejemplo totales.
En las salidas no se deben contar ni los literales ni los campos provenientes
de variables del sistema como fecha, nmero de pgina, opciones de prxima
pgina o pgina previa. Siempre se contarn los mensajes de verificacin y
error como un campo que puede contener estos valores. Tambin se cuentan
las opciones que indican la tarea a realizar, ejemplos son: aceptar o continuar.
Complejidad FICHEROS
LGICOS INTERNOS
1 Registro Lgico
2-5 Registros Lgicos
6 o ms Registros Lgicos

Nmero de
o
1-19Campos
Atributos

Complejidad FICHEROS
INTERFAZ EXTERNOS
1 Registro Lgico
2-5 Registros Lgicos
6 o ms Registros Lgicos

Nmero de
o
1-19Campos
Atributos

BAJA
BAJA
MEDIA

BAJA
BAJA
MEDIA

7
7
10

5
5
7

20-50 Atributos
BAJA
7
MEDIA
10
ALTA
15

51 o Atributos
MEDIA
10
ALTA
15
ALTA
15

20-50 Atributos

51 Atributos

BAJA

MEDIA

MEDIA
ALTA

5
7
10

ALTA
ALTA

7
10
10

Cuando se cuenten los atributos en un fichero se tendr en cuenta:

Slo aquellos que el usuario es capaz de reconocer, aunque aparezcan

de forma repetida se cuentan una sola vez.

Se han de contar los campos que hacen falta para mantener las
relaciones con otros ficheros Internos o Externos.

Contar como un solo campo aquellos que aparecen como

consecuencia de las tcnicas utilizadas en la implementacin fsica:

26

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

Campos que aparecen ms de una vez en una agrupacin de datos

por la tecnologa o implementacin. Por ejemplo un DNI que
aparezca en alumno y en una tabla de aficiones, si hemos decidido
que forman parte del mismo fichero las dos tablas.

Campos repetidos con el mismo formato pero que estn para

permitir mltiples ocurrencias. Por ejemplo nota ordinaria
(Febrero) y nota extraordinaria (Junio)

Para contar los registros lgicos (tipo de registro) de una agrupacin de

datos (fichero), se han de tener en cuenta las siguientes reglas:

Todo fichero tiene un conjunto de datos bsicos (no repetitivos) ms

otros registros lgicos.

Un registro lgico es un subgrupo de datos elementales de un fichero,

identificables por el usuario. Hay dos tipos de subgrupos los
obligatorios y los opcionales. En el fichero de alumnos sera
obligatorio sus datos de acceso (Mayor-25, FP, COU y Otras-Carreras
que contendrn datos diferentes, habr slo uno de estos, con el que
accedi a la carrera actual) y opcionales como sus aficiones
deportivas, aficiones de lectura, etc. que pueden aparecer o no.

Contar un registro lgico por cada subgrupo, opcional u obligatorio.

Si no hay subgrupos contar un registro lgico.

Con esto se puede realizar la clasificacin de los elementos de funcin. A

continuacin hay que calcular los puntos de funcin sin ajustar, para ello se
puede utilizar la siguiente tabla, que adems deja documentado el clculo del
los Puntos de Funcin sin Ajustar (PFSA).

27

PLANIFICACIN DE PROYECTOS INFORMATICOS

Tipo Elemento

Dificultad

Entradas

Simple
Media
Compleja
Total Puntos de
Funcin
Entradas
Simple
Media
Compleja
Total Puntos de
Funcin Salidas
Simple
Media
Compleja
Total Puntos de
Funcin
Consultas
Simple
Media
Compleja
Total Puntos de
Funcin
Ficheros
Simple
Media
Compleja
Total Puntos de
Funcin
Ficheros
de
Interfaz

Salidas

Consultas:
Mximo Complejidad(
Entrada, Salida )
Ficheros Internos

Ficheros de
Interfaz

Total Puntos de
Funcin
Sin

Peso
3
4
6

Cantid
ad
E1
E2
E3

Total
Puntos
3 * E1
4 * E2
6 * E3

Total Elemento

Peso * Ei
4
5
7

S1
S2
S3

4 * S1
5 * S2
7 * S3

3
4
6

C1
C2
C3

3 * C1
4 * C2
6 * C3

7
10
15

F1
F2
F3

7 * F1
10 * F2
15 * F3

5
7
10

I1
I2
I3

5 * I1
7 * I2
10 * I3

Peso * Si

Peso * Ci

Peso * Fi

Peso * Ii
Peso*Xij

3.3. IDENTIFICACIN DE LOS FACTORES DE COMPLEJIDAD.

Los Puntos de Funcin sin ajustar son una aproximacin de la
complejidad del sistema, pero quedan caractersticas externas que no hemos
contemplado, as como caractersticas del proceso de desarrollo del sistema
informtico que influirn en el coste del sistema y que podemos cuantificar
desde las primeras fases del desarrollo. Estos factores adicionales segn
Albrecht son catorce. Cada factor tomar un valor entre 0 y 5, de modo que
cuanta ms importancia tenga un factor mayor valor se le asignar.
28

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

La siguiente tabla indica los valores posibles de un factor y su significado.

Valor asignado
0
1
2
3
4
5

Significado del valor

Sin influencia, factor no presente
Influencia insignificante, muy baja
Influencia moderada o baja
Influencia media, normal
Influencia alta, significativa
Influencia muy alta, esencial

Con estos valores calculados, los sumaremos y obtendremos el Factor de

Complejidad Total.
A continuacin describimos cada factor e indicamos cuando deberan
tomar los valores extremos, a modo de gua.
1) COMUNICACIN DE DATOS.
Los datos usados en el sistema se envan o reciben por lneas de
comunicaciones.
0 Sistema aislado del exterior (slo usuarios directos. Ej.: PC; BATCH ).
1 Aplicacin batch con entrada de datos remota o (exclusiva) utilizacin
de perifricos de salida remotos.
2 Aplicacin batch con entrada de datos remota y utilizacin de
perifricos de salida remotos.
3 plicacin de captura de datos En_Lnea o hay un sistema de
teleproceso que pasa los datos a la aplicacin batch o sistema de
consulta.
4 Varios teleprocesos pero con el mismo protocolo de comunicaciones.
5 Hay teleproceso con varios protocolos de comunicacin. Sistema
Abierto y con interfaces de todo tipo al exterior.
29

PLANIFICACIN DE PROYECTOS INFORMATICOS

2) PROCESO DISTRIBUIDO.
Existen Procesos o Datos distribuidos, y el control de estos forma parte
del sistema.
0 Sistema totalmente Centralizado o no tiene como objetivo el transferir
datos o procesos entre componentes del sistema.
1 El sistema realiza sus procesos en un equipo, pero las salidas se
preparan de modo que son utilizadas va software de otros equipos.
Por ejemplo a la salida del sistema se accede va una hoja de clculo o
un procesador de textos en un PC.
2 El sistema captura los datos en un equipo, que les da formato, siendo
enviados a otro equipo del sistema que los trata.
3 Proceso distribuido pero con transferencia de datos "en lnea" en una
sola direccin.
4 Proceso de datos distribuidos y transferencia de datos "en lnea" en
ambas direcciones. Por ejemplo una red de cajeros automticos en
donde stos procesan parte la transaccin.
5 El sistema esta ejecutndose en una red con procesos cooperantes
ejecutndose en distintos equipos.
3) OBJETIVOS DE RENDIMIENTO.
Si el rendimiento es un requisito del sistema. Es decir es crtico algn
factor como tiempo de respuesta o cantidad de operaciones por hora. Se
tendr que hacer consideraciones especiales durante el diseo, codificacin y
mantenimiento.
0 Rendimiento normal (el que suelen dar los sistemas informticos en los
que no se pone nfasis en este tema).

30

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

1 Se indican requerimientos de rendimiento y del diseo que son

revisados, pero no es necesario tomar medidas especiales.
2 El tiempo de respuesta o cantidad de operaciones por hora es crtico en
algunos momentos. No se solicita que realicemos un diseo de la
utilizacin de la CPU. Los procesos debern estar terminados antes de
la siguiente sesin de trabajo (prximo da)
3 El tiempo de respuesta o cantidad de operaciones por hora es crtico
durante todas las horas de trabajo. No se solicita que realicemos un
diseo de la utilizacin de la CPU. Los requerimientos indican que los
procesos con sistemas de interfaz debern estar terminados segn
ciertas restricciones.
4 Adems, los requerimientos indican que el tiempo de respuesta o la
cantidad de operaciones por hora es lo suficientemente crtico, como
para requerir tareas de anlisis de rendimiento durante la fase de
diseo.
5 Adems se utilizan herramientas de anlisis de rendimiento durante el
diseo, desarrollo e instalacin, con el objetivo de alcanzar el
rendimiento demandado por el usuario.
4) CONFIGURACIN DE EXPLOTACIN USADA INTENSAMENTE
POR OTROS SISTEMAS.
El sistema tendr que ejecutarse en un equipo en el que coexistir con
otros, compitiendo por los recursos, y esta es una caracterstica fundamental,
teniendo que tenerse en cuenta en las fase de diseo.
0 No se han indicado restricciones ni explcita ni implcitamente.
1 Existen restricciones, pero son las usuales de cualquier equipo
departamental. No es necesario hacer consideraciones especiales.
2 El usuario declara explcitamente caractersticas de seguridad o
relativos a tiempos.
31

PLANIFICACIN DE PROYECTOS INFORMATICOS

3 Algunos programas deben funcionar con restricciones en algn

procesador.
4 Las restricciones operativas definidas implican que el software deber
funcionar con restricciones de uso del procesador central o en un
procesador dedicado.
5 Adems, hay restricciones especiales para la aplicacin en los
componentes distribuidos del sistema.
5) TASA DE TRANSACCIONES.
La tasa de transacciones ser elevada.
Se tendr que hacer
consideraciones especiales durante el diseo, codificacin e instalacin.
0 No se prevn perodos con picos de transacciones.
1 Se prevn picos de operaciones de forma regular, pero poco frecuente
(mensualmente, trimestralmente o anualmente). Ejemplos seran la
automatricula, los cierres de contabilidad, o el prstamo de libros antes
de los exmenes.
2 Se prevn picos de operaciones semanales.
3 Se prevn horas punta, diarias. Ejemplo sera las ventas en los
supermercados.
4 La tasa de transacciones se prev tan elevada que durante el diseo se
debe incluir tareas de anlisis del rendimiento.
5 Se ha especificado una cantidad de transacciones muy elevada. Se
utilizarn herramientas de anlisis de rendimiento durante el diseo,
implementacin e instalacin.

32

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

6) ENTRADA DE DATOS EN-LNEA.

La entrada de datos ser directa desde el usuario a la aplicacin, de
forma interactiva.
0 No hay entrada de datos interactiva, todo es batch.
1 Entre el 1% y el 7% de las transacciones son entradas interactivas.
2 Entre el 8% y el 15% de las transacciones son entradas interactivas.
3 Entre el 16% y el 23% de las transacciones son entradas interactivas.
4 Entre el 24% y el 30% de las transacciones son entradas interactivas.
5 La entradas de datos interactivas superan el 30% de las transacciones.
7) EFICIENCIA CON EL USUARIO FINAL.
Se demanda eficiencia para el usuario en su trabajo, es decir se tiene que
disear e implementar la aplicacin con interfaces fciles de usar y con
ayudas integradas. Los tipos de elementos asociados a la eficiencia del
usuario son:

Mens.

Ayudas "en lnea".

Movimiento automtico del cursor.

Efectos de Scroll (papiro).

Impresin remota (mediante transacciones en lnea)

Teclas de funcin predefinidas

Lanzamiento de procesos batch desde las transacciones "en lnea".

Seleccin mediante cursor de datos de la pantalla.

Pantallas con muchos colores y efectos.

Documentacin impresa de las operaciones en lnea.

Uso de ratn.

Ventanas de "pop-up".

Forzar la aplicacin a tener el menor nmero posible de pantallas por

transaccin.

Aplicacin bilinge (cuenta por cuatro).

33

PLANIFICACIN DE PROYECTOS INFORMATICOS

Aplicacin Multilinge (ms de dos, cuenta por seis).

Toma el valor:
0 No hay especial nfasis en los interfaces de uso con el usuario.
1 De uno a tres de los factores anteriores.
2 De cuatro a cinco.
3 Seis o ms factores, pero sin especiales requerimientos de eficiencia.
4 Ms de seis factores, con requerimientos lo suficientemente especficos
como para justificar en el diseo estudios de los factores humanos.
Ejemplo: minimizar la cantidad de pulsaciones, proveer valores por
defecto, uso de marcos estandarizados, etc..
5 Igual al anterior, pero los requerimientos son tan fuertes que se
demanda la construccin de prototipos y utilizacin de herramientas
para su evaluacin y comprobar que se alcanzarn los objetivos.
8) ACTUALIZACIONES EN-LNEA.
Los ficheros maestros y las Bases de Datos son modificadas directamente
de forma interactiva.
0 No hay actualizaciones interactivas.
1 Actualizacin en lnea de uno a tres ficheros con informacin de
control. Ejemplo fichero con usuarios, horas en que se puede acceder,
etc.. La cantidad de actualizaciones es baja y es fcil recuperar el
fichero.
2 Igual al anterior, pero con cuatro o ms ficheros de control.

34

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

3 Actualizacin En-Lnea de ficheros lgicos internos importantes.

Ejemplo: en un banco sera TRANSACCIONES, CLIENTES,
CUENTAS, etc..
4 Adems de lo anterior, es esencial la proteccin ante perdidas y el
sistema se ha de disear e implementar con estas consideraciones.
5 Gran cantidad de actualizaciones interactivas, debindose considerar
los costes de recuperacin. Adems deben tenerse sistemas de
recuperacin, en caso de fallo, muy automatizados y con poca
intervencin del operador.
9) LGICA DE PROCESO INTERNO COMPLEJA.
La complejidad de los procesos es una caracterstica de la aplicacin.
Alguno de las siguientes caractersticas estn presentes:
a) Los algoritmos matemticos especificados complejos.
b) Procesos con lgica compleja.
c) Se han especificado muchas excepciones,
transacciones incompletas, que debern tratarse.

consecuencia

de

d) Manejar mltiples dispositivos de entrada/salida.

e) La aplicacin llevar incorporados sistemas de seguridad y control.
La complejidad algortmica realmente est mal resuelta en esta tcnica.
Hay que tener en cuenta que se ha desarrollado pensando en sistemas de
proceso empresarial. Para sistemas complejos algortmicamente hay tcnicas
que miden la complejidad como las de McCabe.
La valoracin ser la siguiente:
0 No se da ninguna de las caractersticas anteriores.
1 Se da una caracterstica de las enunciadas.
35

PLANIFICACIN DE PROYECTOS INFORMATICOS

2 Se dan dos caractersticas de las enunciadas.

3 Se dan tres caractersticas de las enunciadas.
4 Se dan cuatro caractersticas de las enunciadas.
5 Se dan las cinco caractersticas de las enunciadas.
10) REUSABILIDAD DEL CDIGO.
Se tendr que hacer consideraciones especiales durante el diseo,
codificacin y mantenimiento para que el cdigo se reutilice en otras
aplicaciones.
0 No se piensa en reutilizar el cdigo a generar.
1 Se pretende reutilizar el cdigo a generar dentro de la propia
aplicacin.
2 Menos del 10% de la aplicacin tiene en cuenta las necesidades de ms
de un usuario (sistema).
3 El 10% de la aplicacin o ms tiene en cuenta las necesidades de ms
de un usuario (sistema).
4 La aplicacin ha sido especficamente empaquetada y/o documentada
para ser fcil de reutilizar. La aplicacin se adaptar a las necesidades
de los usuarios a nivel de cdigo.
5 La aplicacin ha sido especficamente empaquetada y/o documentada
para ser fcil de reutilizar. La aplicacin se adaptar a las necesidades
de los usuarios por medio de parmetros.

36

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

11) CONTEMPLA LA CONVERSIN E INSTALACIN.

Se proveern facilidades de instalacin y conversin en el sistema. Se
desea que la conversin del sistema antiguo sea fcil de realizar durante la
puesta en marcha del sistema nuevo.
0 No reemplazamos un sistema existente o no se requiere conversin.
Tampoco se enuncia nada sobre la instalacin.
1 Se solicita facilidad de instalacin.
2 Se ha solicitado procesos de conversin e instalacin, se han
construido guas y han sido probadas, pero no son considerados
importantes en el proyecto.
3 Se han solicitado procesos de conversin e instalacin, dndose guas
explcitas, y estos procesos han de ser probados. En este proyecto se
considera muy importante el proceso de conversin.
4 Adicionalmente a la valoracin de 2 se aade el que tendrn que
desarrollarse herramientas de conversin e instalacin probadas.
5 Adicionalmente a la valoracin de 3 se aade el que tendrn que
desarrollarse herramientas de conversin e instalacin probadas. El
sistema es crtico para la empresa y ya estaba automatizado. Los
usuarios no pueden permitirse el lujo de tener problemas o bajo
rendimiento durante la transicin. Estas condiciones se han descrito
como requisitos a cumplir por el sistema.
12) FACILIDAD DE OPERACIN.
Entendemos por operacin del sistema los trabajos asignados al centro de
proceso de datos para una aplicacin dada como: arranque, parada,
recuperacin ante fallos, copias de seguridad. Aqu tendremos en cuenta la
minimizacin de las actividades manuales en el CPD. As, sta caracterstica
se valora cuando se ha descrito desde las primeras fases, habiendo de
dedicarse especial atencin durante el diseo, codificacin y pruebas.
37

PLANIFICACIN DE PROYECTOS INFORMATICOS

Se pueden tener en cuenta las siguientes posibilidades de automatizacin:

Se proveer de procesos de arranque, back-up y recuperacin pero con

intervencin del operador.

Se proveer de procesos de arranque, back-up y recuperacin pero sin

intervencin del operador (vale por dos).

En la aplicacin se minimiza la necesidad de montar cintas u otros

dispositivos de almacenamiento externo.

Se minimiza la necesidad de manejar papel.

Valoraremos con:
0 No se especifica nada, en todo caso lo que debieran ser procedimientos
usuales de back-up.
1 a 4 sumar la cantidad de tems en la lista anterior.
5 Sistema automtico sin intervencin humana.
13) INSTALACIONES MLTIPLES
El sistema ha de incluir los requerimientos de diversas empresas o
departamentos en donde se ejecutar (incluso distintas plataformas). Estas
caractersticas estarn presentes durante el diseo, codificacin y pruebas.
0 En slo un lugar.
1 Mltiples lugares pero con idntico Hardware y entorno Software.
2 En el diseo se ha de tener en cuenta que rodar en diferentes
entornos, pero con Hardware y Software similares.
3 La aplicacin deber rodar en mltiples entornos de Hardware o
Software y se tiene en cuenta desde la fase de diseo.
38

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

4 Se documentar y se planearn sistemas para dar soporte a la

situaciones descritas en las valoraciones 1 o 2.
5 Se documentar y se planearn sistemas para dar soporte a la situacin
descrita en la valoracin 3.
14) FACILIDAD DE CAMBIOS
Se tendr que hacer consideraciones especiales durante el diseo,
codificacin y mantenimiento para que en el sistema sea fcil de introducir
cambios y fcil de adaptar al usuario. Esto contemplara:
a)

Consultas flexibles del usuario. Podemos tener Consultas:

Simples con condiciones lgicas And/Or que implican un solo

fichero lgico. Contar 1.

Medias con condiciones lgicas de complejidad media mediante

And/Or que relacionan a ms de un fichero lgico. Contar 2.

Complejas con condiciones lgicas muy complejas mediante

combinaciones lgicas And/Or entre varios ficheros lgicos).
Contar 3.
b)

Parmetros de la aplicacin va tablas ajenas al cdigo.

El cambio de la configuracin se hace efectivo al arrancar el

sistema al da siguiente. Contar 1.

El cambio de la configuracin se hace interactivamente y tiene

efecto inmediato. Contar 2.

Toma el valor::
0 No se especifica nada.
1 Se da un tem de los descritos anteriormente con valor 1.
39

PLANIFICACIN DE PROYECTOS INFORMATICOS

2 Se dan algunos tems de los descritos anteriormente acumulando un

valor de 2.
3 Se dan algunos tems de los descritos anteriormente acumulando un
valor de 3.
4 Se dan algunos tems de los descritos anteriormente acumulando un
valor de 4.
5 Se dan algunos tems de los descritos anteriormente acumulando un
valor de 5.

40

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

CLCULO DEL FACTOR DE COMPLEJIDAD TOTAL.

La siguiente tabla documenta el clculo del factor de complejidad total
(FCT).
#

Factor de Complejidad

Comunicacin de Datos.

Proceso Distribuido.

Objetivos de Rendimiento

Configuracin de Explotacin compartida

Tasa de Transacciones

Entrada de Datos EN-LNEA

Eficiencia con el Usuario Final

Actualizaciones EN-LNEA

Lgica del Proceso Interno Compleja

10

Reusabilidad del Cdigo

11

Contempla la Conversin e Instalacin

12

Facilidad de Operacin

13

Instalaciones Mltiples

14

Facilidad de Cambios

Valor (0..5)

Valori

Fact
or de

3.4. OBTENCIN DE LOS PUNTOS DE FUNCIN AJUSTADOS.

Para obtener los puntos de funcin ajustados de una aplicacin se utiliza
la siguiente frmula:
PFA = PFSA * (0.65 + (0.01 * FCT))

41

PLANIFICACIN DE PROYECTOS INFORMATICOS

Esta frmula indica que en principio cada factor de complejidad puede

actuar sobre los PFSA incrementando
o decrementando en un 2,5% la
140
cantidad de puntos de funcin
120
ajustados.
100
80
60
40
20
0
0

35

70

De forma global producir una valoracin de los PFA de entre el 65% y el

135% del PFSA.
Para calcular los puntos de funcin de un proyecto nos podemos
encontrar en tres situaciones:

La aplicacin a desarrollar parte de cero. No tenemos nada

desarrollado que podamos utilizar, ni tenemos que convertir datos de
una aplicacin previa. En este caso se aplica la frmula que mide el
tamao de la aplicacin.

La aplicacin a desarrollar parte de una aplicacin previa de la que

slo se desea convertir los datos a la nueva aplicacin. Deberemos
aadir a los puntos de funcin sin ajustar el tamao que incorporaran
las utilidades de conversin (puntos de funcin de la conversin
CONVER). As:
PFC=(PFSA+CONVER)*(0,65+(0,01*FCT))

42

El clculo ms complejo se da cuando modificamos una aplicacin. La

frmula a utilizar es:

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

PFM = [(AADIDO+CAMBIADO+CONVER) * (0,65+(0,01*FCD))] +

(BORR*(0,65+(0,01*FCP)))
Donde se introducen los PF aadidos, cambiados, borrados y de
conversin, as como los factores de complejidad despus de la modificacin
(FCD) y los factores de complejidad previos a la modificacin (FCP)

4. ESTIMACIN DEL ESFUERZO REQUERIDO

POR LA APLICACIN.
El objetivo ahora es estimar la cantidad de esfuerzo necesario para
desarrollar la aplicacin. Este esfuerzo se mide en horas/hombre,
meses/hombre o aos/hombre. Los puntos de funcin en cierto modo son
una medida subjetiva (aunque el objetivo de IFPUG es que esta subjetividad
se minimice), ya que se puede realizar valoraciones diferentes por personas
con diferentes puntos de vista. Adems en principio este nmero no dice
nada, nos hace falta conocer la cantidad de meses/hombre que costar cada
punto de funcin.
La cantidad de horas/hombre por punto de funcin es algo difcil e
impreciso de valorar, de forma global. Esto es normal, lo contrario sera
suponer que la productividad de todas las empresas de desarrollo de
software es igual.
Se ha constatado que en una misma empresa se pueden realizar
estimaciones muy buenas conociendo su productividad histrica, aqu si que
tiene sentido el esperar que los puntos de funcin tengan cierta uniformidad,
cuando se utilizan entornos similares.
De forma general, para proyectos de tamao medio (300 PFA), se han
publicado valores como los mostrados en la siguiente tabla:
Entorno, Lenguaje
Ensamblador
COBOL
Lenguajes 4GL

Horas / Punto Funcin Lneas Cdigo/P.Funcin

20 a 30
300
10 a 20
100
5 a 10
20
43

PLANIFICACIN DE PROYECTOS INFORMATICOS

De todos modos esto no deja de ser una orientacin ya que como indica
Thomsett algunas organizaciones usan valores como 40 horas por punto de
funcin en COBOL.
Dreger comenta que la productividad no slo vara entre programadores,
sino que tambin con el tamao del proyecto. Indica que en algunos estudios
se ha llegado a la conclusin de que un equipo medio, en un proyecto de 400
PFA, utiliza 20 horas por punto de funcin, mientras que en un proyecto de
2000 PFA, pasa a ser de 52 horas por punto de funcin.
En cualquier caso nuestra empresa deber mantener una base de datos con
la informacin de los proyectos realizados en sta. Se deber tener como
mnimo los puntos de funcin que se estimaron en cada proyecto, los que
resultaron a final del proyecto, el esfuerzo que cost, el entorno y los
lenguajes utilizados. Si deseamos una mejor informacin deberamos
mantener la informacin de base para calcular los puntos de funcin, factores
de complejidad y aadir aquellos factores que pensemos que son relevantes
en nuestra organizacin. Un ejemplo de esto puede ser el suponer que el
apoyo de la alta direccin es un elemento clave, as pues lo valoraremos de 0
a 5 y mantendremos esta informacin para posibles interpretaciones futuras.
Con todas las cautelas que hemos indicado, podemos calcular el esfuerzo
requerido en nuestra organizacin para un proyecto como:
Esfuerzo = PFA * Promedio_Organizacin( Lenguaje )

Suponiendo que nuestra organizacin realiza proyectos de caractersticas

similares. con tamaos de entre 200 y 500 puntos de funcin. Para una
mayor precisin consultar la bibliografa.
Con esto obtendremos una aproximacin a la cantidad bruta de horas,
meses o aos hombre necesarios.

44

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

Hay que tener en cuenta que normalmente, aunque se trabaja 8 horas

diarias, slo 5 son productivas, que un mes tiene 20 das de trabajo efectivos,
y que un ao tiene 11 meses de trabajo. Es decir aproximadamente un ao
tiene 220 das de trabajo real.

5. OTRAS UTILIDADES DE LAS MEDICIONES

MEDIANTE PUNTOS DE FUNCIN.
Dado que lo que realmente miden los puntos de funcin es la
funcionalidad de una aplicacin informtica, tambin se utilizan para:

Comparar lo que solicit el cliente con lo que recibi.

Comparar la productividad de los diferentes entornos de desarrollo.

Comparar la calidad que se obtiene mediante las diferentes tcnicas de

desarrollo.

6. BIBLIOGRAFA Y REFERENCIAS A
CONSULTAR.
1. Albrecht, A.J. and Gaffney, J.E.. "Software Function, Source Lines of
Code, and Development Effort Prediction: A Software Science
Validation". IEEE Transaction on Software Engineering, Vol. SE-9, N 6,
Nov. 1983, pp. 639-648. (Hemeroteca UPV).
2. Boehm, Barry. Software Engineering Economics. Reimpreso en Software
Management (4 ed.), Donald J. Reifer, IEEE Computer Society Press
1993. (Biblioteca UPV).
3. Dreger, J.B. "Function Point Analysis", Prentice Hall, 1989. (Biblioteca
UPV).
4. Gibson, Robin. Managing Computer Projects. Avoiding the Pitfalls.
Prentice Hall, 1992. (Biblioteca UPV).
5. International Function Point Users Group: "Function Point as an Asset Reporting to Management", 1992. (Disponible para consulta restringida
en el Dpto.).

45

PLANIFICACIN DE PROYECTOS INFORMATICOS

6. International Function Point Users Group: "Function Point Counting

Practices Manual: Case Studies (Case Study 2)", Release 1.0, 1994.
(Disponible para consulta restringida en el Dpto.).
7. International Function Point Users Group: "Function Point Counting
Practices Manual", Release 4.0, 1994. (Disponible para consulta
restringida en Dpto.).
8. Jones, Capers. Applied Software Measurement - Assuring Productivity
and Quality". McGraw Hill, 1991. (Biblioteca UPV).
9. Jones, Capers. Assessment and Control of Software Risks. Yourdon
Press, Prentice Hall, 1994. (Biblioteca UPV).
10. King, Davis. Project Management Made Simple. A guide to successful of
computer Systems projects . Yourdon Press, Prentice Hall, 1992.
(Biblioteca UPV).
11. Kemerer, C.F.. "Reliability of Function Point Measurement: A Field
Experiment", Communications of the ACM, Feb. 1993. (Hemeroteca
UPV).
12. Kemerer, C.F. and Porter B.S.. "Improving the Reliability of Function
Point Measurement: An Empirical Study", IEEE Transaction on Software
Engineering, Vol. SE-18, N 11, Nov. 1992, pp. 1011-1024.
(Hemeroteca).
13. Low, G.C. and Jeffery, D.R.. "Function Point in the Estimation and
Evaluation of the Software Process", IEEE Transaction on Software
Engineering, Vol. SE-16, N 1, Jan. 1990, pp. 64-71. (Hemeroteca
UPV).
14. OConell, Fergus. How to Run Successful projects. BCS Series, Prentice
Hall, 1994. (Biblioteca UPV).
15. Pressman, R. Ingeniera del Software, un enfoque aplicado. McGraw Hill
1993. (Biblioteca UPV)
16. Thomsett, Rob. Third Wave Project Management: a Handbook for
Managing the Complex Information Systems of the 1990s. Yourdon
Press, Prentice Hall, 1993. (Biblioteca UPV).

46