Estimacin de proyectos de software

1. Estimaciones basadas en el tamao del software

3.1 Mtrica LDC

Para realizar estimaciones basadas en el tamao del software, es fundamental tener en
cuenta la cantidad de lneas de cdigo fuente (LCF) que constituyen el programa. Para que la
estimacin del tamao del software sea un poco ms sencilla, es aconsejable que se
mantengan registros bsicos que permitan crear una tabla de datos como la que se mostrar
a continuacin, la cual permitir tener una gua acerca del tamao del software:

Tabla 1
Tabla de histrico de proyectos
Proyecto
REDMINE
SGVA
MANTIS

LDC

Esfuerzo

12100
27200
20200

24
62
43

$ (Miles)

Pag. Doc

168
440
314

Errores

365
1224
1050

Defectos

134
321
256

Personas

29
86
64

De la tabla anterior se puede deducir lo siguiente:

El proyecto REDMINE consta est compuesto por 12100 lneas de cdigo fuente, se necesit
del esfuerzo de 24 persona por mes y tuvo un costo de 168000, la documentacin del
proyecto consta de 365 pginas, se registran 134 errores en la fase de pruebas del proyecto y
el usuario del software reporta 29 errores en el primer ao de uso.
Los valores y esfuerzos registrados en la tabla anterior incluyen todas las fases del desarrollo
del software (Anlisis, Diseo, Codificacin y Pruebas) y no solo la codificacin. De esta
manera y con los datos contenidos en la tabla se puede obtener un conjunto de mtricas
simples adicionales:

Tabla 2
Tabla de Mtricas simples LDC
Mtrica
No. Errores por LDC
No. Defectos por LDC
Costo por LDC
LDC por persona-mes

Operacin
Errores/LDC
Defectos/LDC
$(Miles)/LDC
LDC/Esfuerzo

Resultado
0,001
0,002
$ 13,88
904 LDC/p-m

3
5
6

La mtrica LDC por persona-mes se puede usar como una medida de la productividad del
equipo de desarrollo en el proyecto Alfa, es decir, nos dice que en promedio un programador
escriba (produca) 904 lneas de cdigo al mes. Cuando se va a estimar el costo de un
proyecto nuevo, se puede comparar sus caractersticas con las de los proyectos registrados
en la tabla histrica y de ah obtener las LDC requeridas para un proyecto de ese tipo. Es
lgico pensar que para el proyecto nuevo se requiera escribir un nmero Aproximado de
LDC al que se requiri en un proyecto anterior parecido.

3.1.1 Ventajas Mtrica LDC

Es una mtrica fcil de comprender.

Muchos modelos, herramientas automticas y literatura de estimacin se

basan en LDC.

3.1.2 Desventajas Mtrica LDC

Las LDC son dependientes del lenguaje. Escribir el mismo programa en lenguajes
diferentes puede arrojar una diferencia en LCF bastante grande.
Resulta difcil que el planificador estime las LCF a producirse mucho antes de que se
complete el anlisis y el diseo, ms an si no tiene datos histricos.

3.2. Mtricas orientadas a la Funcin

Los puntos de funcin hace referencia a una mtrica con la cual se puede medir tambin el
tamao de un proyecto. Consiste en evaluar las caractersticas de cada funcionalidad que
debe proporcionar el software. Los puntos de funcin son ms fciles de determinar a partir de
la especificacin de requisitos que las LDC y proporcionan una medida ms exacta del
tamao del programa. El nmero de puntos de funcin en un programa se basa en el nmero
y complejidad de los siguientes elementos:
Entradas
o

Pantallas, formularios de captura, cuadros de dilogo, controles o mensajes, a

travs de los cuales el usuario final pueda aadir, borrar, modificar datos del
programa.

Salidas
o

Pantallas, informes, grficas o mensajes que el programa genera para el

usuario final. Esto incluye cualquier salida que tenga un formato diferente a
otros tipos de salida.

 Peticiones
o

Normalmente entendido como Consultas que son una E/S interactiva, simple e
inmediata. Las consultas recuperan datos de una base de datos y muestra solo
el formato elemental.

Archivos Lgicos Internos

o

Archivos que estn bajo el control completo del programa a desarrollar. Puede
ser un nico archivo plano (de texto o ASCII) o de una nica tabla en una base
de datos relacional.

Archivos de Interfaz Externos

o

Archivos controlados por otros programas, con los que el programa va a

interactuar. Pueden ser cualquier archivo que salga o entre al programa.

3.2.1. Procedimiento para calcular el Punto de Funcin:

Llenar la columna de CUENTA de la siguiente tabla de valores, donde se
determinan 5 caractersticas del mbito de la informacin.
Tabla 3
Tabla de valores del dominio de la informacin
Parmetro
Entradas
de
usuario
Salidas
de
usuario
Peticiones
de
usuario
Archivos
Interfaces
externas
CUENTA TOTAL

CUENTA

Factor de ponderacin
Simple

Medio

Complejo

10

15

15

10

10

Subtotal

Multiplicar el valor de CUENTA por el Factor de Ponderacin indicado,

dependiendo de su complejidad para obtener Subtotal. Se asocia un valor
de complejidad a cada medida, tomando en cuenta la heurstica de la
siguiente tabla.
Tabla 4
Tabla de complejidades

Tipos
de
referenciados

archivos Tipos de datos elementales

01-may
Bajo
Bajo
Medio

0-1
02-mar
4+

jun-19
Bajo
Medio
Alto

20+
Medio
Alto
alto

Obtener CUENTA TOTAL

Evaluar los siguientes 14 atributos que impactan en el desarrollo, en escala
de 0 a 5.
Tabla 5
Factores de influencia en la dificultad del sistema
FACTORES DE INFLUENCIA
DIFICULTAD DEL SISTEMA

EN

LA

Ejemplo

1. Comunicaciones de datos

Una aplicacin para el sector

bancario, donde se requieren
numerosas
transacciones
monetarias.

2. Procesamiento distribuido

Un motor de bsqueda en Internet,

donde el procesamiento est
distribuido
en
decenas
de
mquinas.

3. Objetivos de rendimiento

Una aplicacin para el control del

trfico areo, que debe proporcionar
continuamente informacin precisa
sobre la posicin y rumbo de los
aviones.

4. Configuracin de uso intensivo

Un sistema para matrculas en una

universidad,
donde
concurren
cientos de alumnos al mismo
tiempo.

5. Tasas de transaccin rpidas

Una aplicacin para el sector

bancario, donde deben realizarse
millones de transacciones durante la
noche.

6. Entrada de datos en lnea

Un programa en el que los datos de

entrada provienen de papeles o
formularios impresos.

7. Amigabilidad en

Un programa de anlisis financiero

utilizado por el directivo de una
empresa, capaz de orientarle y
asesorarle.

8. Actualizacin de datos en lnea

Una aplicacin para reserva de

billetes, en la que deben bloquearse
y modificarse ciertos registros en las
BB.DD. para evitar que un mismo
asiento sea vendido dos veces.

9. Procesamiento complejo

Un sistema para diagnstico

mdico, el cual realiza costosas
operaciones de decisin lgica
hasta obtener un resultado.

10. Reusabilidad

Un procesador de textos en el que,

por ejemplo, su barra de mens
puede utilizarse desde una hoja de
clculo, un generador de informes
de una base de datos, etc.

11. Facilidad de instalacin

Cualquier aplicacin de propsito

general, de tal forma que cualquier
persona
pueda
realizar
la
instalacin fcilmente.

12. Facilidad operacional

Una aplicacin para tratamiento de

grandes cantidades de informacin,
donde es muy importante la
efectividad de los procesos de
backup y recuperacin de datos.

13. Adaptabilidad

Una aplicacin software para una

multinacional con oficinas en varios
pases.

14. Versatilidad

Un sistema que admite diversas

situaciones de uso, tanto para
facilitar los cambios como para ser
utilizada por el usuario

Para la estimacin de software en base al tamao, se cuenta con ms tcnicas que permiten
dicha medicin, a continuacin se relacionan las siguientes:
Tamao en lgica difusa: Este enfoque utiliza las tcnicas aproximadas
de razonamiento que son la piedra angular de la lgica difusa.
Tamao de componentes estndar: el software se compone de un
nmero de componentes estndar que son genricos para un rea en
particular de la aplicacin.

Tamao del cambio: este enfoque se utiliza cuando un proyecto

comprende la utilizacin de software existente que se debe modificar de
alguna manera como parte de un proyecto.

3.3.

Estimacin basada en el problema

Los datos de LDC y PF son distintas tcnicas de estimacin, pero que tienen varias
caractersticas en comn, y se utilizan en dos formas para estimar el proyecto de software:
Como variable para estimar el tamao del software
Como mtrica de lnea base recolectada de proyectos histricos.
Teniendo el mbito del software, se descompone el mismo en funciones problemas, para ser
evaluadas individualmente y obtener valores para LDC y PF, entonces se aplican mtricas
(LDC/p-m o PF/p-m) las cuales resultan en el tamao o costo de la funcin, que
combinadas derivan en la estimacin global del proyecto. Sin embargo esta estimacin
basada en mtricas de productividad es dispersa, por lo que se debe considerar que no es
suficiente, el dominio del problema debe calcular las mtricas de LDC/p-m o PF/p-m.
Cuando se estima un nuevo proyecto primero debe ubicarse en un dominio, y luego aplicar
el promedio del dominio apropiado para la productividad y as generar la estimacin.
El valor esperado se calcula mediante una ponderacin de:
S = (Sopt + 4Sm + Spes) / 16

3.4.

Estimacin basada en casos de uso

Proceso de estimacin

Definir los principales usuarios del sistema

Definir las metas de los usuarios
Definir los Casos de Uso
Calcular el esfuerzo de implementar los Casos de Uso

3.4.1. Clasificar cada interaccin entre actor y caso de uso segn su complejidad y asignar
un peso en funcin de sta
Para poder clasificar la complejidad de los actores debemos analizar la interaccin de
ste con el sistema que se va a desarrollar.
La complejidad de los actores puede corresponderse con una de las tres categoras
posibles:
a. Simple. Representa a otro sistema con una API definida. Se le asigna un
peso de valor 1.
b. Medio. Representa a otro sistema que interacta a travs de un protocolo de
comunicaciones. Por ejemplo TCP/IP o a travs de un interfaz por lnea de
comandos. Se le asigna un peso de valor 2.
c. Complejo. La interaccin se realiza a travs de una interfaz grfica. Se le
asigna un peso de valor 3.
3.4.2. Calcular la complejidad de cada caso de uso segn el nmero de transacciones o
pasos del mismo
Para calcular la complejidad de un caso de uso debemos determinar el nmero de
transacciones,
incluyendo
los
caminos
alternativos.
Se entiende por transaccin a un conjunto de actividades atmicas, donde se ejecutan
todas
ellas
o
ninguna.
En funcin del nmero de transacciones que posee un caso de uso se clasifica el
caso de uso como simple, medio o complejo, siendo la asignacin de pesos la que se
muestra en la tabla siguiente:
Tabla 6 pesos en funcin de la complejidad de los casos de uso

N de Transacciones del Caso de Uso

Tipo

Peso

menor o igual que 3

Simple

mayor o igual que 4 y menor que 7

mayor o igual que 7

Medio
Complejo

10
15

Imagen 1. Definicin de metas del usuario

3.4.3. Calcular los Puntos Casos de Uso No Ajustados (UUCP) del sistema

Se obtienen sumando los Puntos Casos de Uso de todos y cada uno de los actores y
casos de uso que se han identificado y catalogado en funcin de su complejidad.
Se pueden documentar:
o
o
o

Escenarios de uso
Casos de uso formales
Casos de uso informales

Los casos de uso informales son ms rpidos de definir

Los casos de uso formales permiten capturar detalles adicionales que
ayudan a validar la complejidad de los casos de uso

Los detalles adicionales NO son necesarios para crear un clculo del

coste del proyecto mediante puntos de casos de uso
3.4.4. Clculo de los Factores Tcnicos (TCF)

A cada uno de los Factores Tcnicos de la tabla siguiente se le asigna un valor de

influencia en el proyecto entre 0 (no tiene influencia) a 5 (esencial), 3 se considera de
influencia
media.

Obtenidos los grados de influencia se multiplican por el peso de cada factor y con la
siguiente frmula se calcula el Factor Tcnico que aplica:

Tabla 7 Factores Tcnicos para el clculo del TCF

Factor

Descripcin

Peso

Influencia

R1

Sistema Distribuido

R2
R3

Objetivos de rendimiento
Eficiencia respecto al usuario final

1
1

n
p

R4
R5

Procesamiento complejo
Cdigo reutilizable

1
1

q
r

R6
R7

Instalacin sencilla
Fcil utilizacin

0,5
0,5

s
t

R8
R9

Portabilidad
Fcil de cambiar

2
1

u
v

R10
R11

Uso Concurrente
Caractersticas de seguridad

1
1

w
x

R12
R13

Accesible por terceros

Se requiere formacin especial

1
1

y
z

3.4.5. Clculo de los Factores de Entorno

A cada uno de los Factores de Entorno de la tabla siguiente se le asigna un valor de
influencia en el proyecto entre 0 (no tiene influencia) a 5 (esencial), 3 se considera de
influencia media. Obtenidos los grados de influencia se multiplican por el peso de
cada factor y con la siguiente frmula se calcula el Factor de Entorno que aplica:

Tabla 8 Factores de Entorno para el clculo del EF

Descripcin

Peso

Influenci
a

R1

Familiar con RUP

1,5

n1

R2
R3

Experiencia en la aplicacin
Experiencia con orientacin a objetos

0,5
1

n2
n3

Factor

R4
R5

Capacidades de anlisis
Motivacin

0,5
1

n4
n5

R6
R7

Requisitos estables
Trabajadores a tiempo parcial

2
-1

n6
n7

R8

Lenguaje completo

-1

n8

3.4.6. Obtencin de los Puntos Casos de Uso Ajustados

Una vez calculados los dos factores calculamos el valor ajustado de Puntos Casos de
Uso con la siguiente frmula:

Una vez obtenido el nmero de Puntos Casos de Uso, si se quiere obtener el esfuerzo
necesario para llevarlos a cabo en el mtodo se provee de un factor de productividad.
El autor propone un valor de 20 horas/persona aunque existen distintas propuestas
sobre este valor.
Este esfuerzo calculado no abarcara a todas las fases del proyecto sino nicamente a
la codificacin de los Casos de Uso no estando contemplada otras fases del
desarrollo.
Por tanto, para calcular el esfuerzo total del proyecto habra que estimar el esfuerzo
en realizar el resto de actividades del proyecto y sumarlas a las obtenidas por el
mtodo de Puntos Casos de Uso

Imagen 2. Clculo del esfuerzo de implementar los Casos de Uso

Conclusiones
Las estimaciones de proyectos de software se realizan durante el estudio preliminar del
problema y a medida que se avanza en el desarrollo del mismo, dicha estimacin se
revisa y refina durante el anlisis de factibilidad del proyecto. Una estimacin mejorada
se presenta durante las especificaciones del software y la estimacin final durante la
revisin del diseo. Para realizar estimaciones de costos y esfuerzos hay tres opciones:
Basar las estimaciones en proyectos similares ya terminados.
o

Es razonable si el cliente, condiciones de administracin, el medio

ambiente, los requisitos, las fechas lmites, son similares a proyectos
anteriores.

A pesar de eso la experiencia anterior no ha sido siempre un buen

indicador de resultados futuros.

Utilizar tcnicas de descomposicin del problema.

o

Utilizan un enfoque de divide y vencers.

Descomponen el proyecto en sus funciones principales y la estimacin del

costo y esfuerzo puede realizarse en base a mtricas histricas de manera
ms fiable.

 Desarrollar un modelo emprico de clculo de costos y esfuerzos.

o Se basan en datos histricos y son de la forma d = f (vi) donde d es

el valor estimado (p.e. esfuerzo, costo, duracin del proyecto) y
los vi son algunos parmetros independientes (p.e. LOC o PF
estimados).

A cada atributo se le asignar un valor dependiendo del grado de influencia de

stos.
Sin Influencia (0). El sistema no contempla este atributo.
Influencia Mnima (1). La influencia de este atributo es muy poco significativa.
Influencia Moderada (2). El sistema contempla este atributo y su influencia,
aunque pequea, ha de ser considerada.
Influencia Apreciable (3). La importancia de este atributo debe ser tenida en
cuenta, aunque no es fundamental.
Influencia Significativa (4). Este atributo tiene una gran importancia para el
Sistema.
Influencia Muy Fuerte (5). Este atributo es esencial para el sistema y se lo debe
tomar en cuenta a la hora del diseo.
5. Sumar los puntos asignados a cada factor y obtener un TOTAL GI que indica un
valor de ajuste de complejidad.
6. Calcular Punto de Funcin, utilizando la siguiente frmula:
PUNTO FUNCIN = CUENTA_TOTAL * (0,65+ 0,01*TOTAL GI)
Los valores constantes de la ecuacin anterior y los factores de peso aplicados en
las encuestas de los mbitos de informacin han sido determinados
empricamente.
Una vez calculado el punto de funcin se usan de forma analgica a las LDC
como medida de la productividad, calidad y otros productos del software.

Para calcular los puntos de funcin de un programa, se toma el nmero de entradas de menos
complejidad y se multiplica por 3, el nmero de salidas de menor complejidad y se multiplica
por 4, etc. La suma de estos nmeros nos da el total de puntos de funcin.
Caracterstica Baja Media Alta
Nmero de Entradas x 3 x 4 X 6 Nmero de Salidas X 4 X 5 X 7 Peticiones X 3 X 4 X 6
Archivos Internos X 7 X 10 X 15 Interfaces Externas X 5 X 7 X 10 Con los puntos de funcin
obtenidos se puede comparar el tamao del programa con proyectos anteriores y derivar el
costo del nuevo proyecto, o bien se puede usar el mtodo de estimacin de primer orden de
Jones, estudiado ms adelante
El proceso para crear una planificacin de desarrollo exacta consta de tres pasos :
Estimar el tamao del producto ( en nmero de lneas de cdigo fuente o puntos de funcin ).
Algunos proyectos saltan directamente a estimar el plan, pero una estimacin efectiva
necesita estimar primero el tamao del software para poder construirlo. Este paso es sin duda
el ms difcil intelectualmente. 2
. Estimar el esfuerzo ( personas - mes ).
Si tiene una estimacin exacta del tamao y los datos previos de la organizacin en proyectos
similares, es fcil realizar la estimacin del esfuerzo. 3.
Estimar el plan ( meses ).
Una vez que ha estimado el tamao y el esfuerzo, estimar la duracin del plan resulta casi
trivial. Estos tres pasos se pueden englobar dentro de un paso ms general, un metapaso :
Dar un intervalo de estimacin e ir refinando peridicamente ese intervalo, para ir
aumentando la precisin a medida que avanza el proyecto

Algunos de los principios que hay que tener presentes:

Retrasar la estimacin lo mximo posible. Cuanto ms se retrase, ms precisa ser.

Hacer estimacin por analoga. Utilizar el coste de proyectos similares.

Ley de Parkinson. El trabajo se extiende para rellenar el tiempo disponible.

Precio para ganar. El coste se estima en todo el dinero que el cliente puede gastar en
el proyecto.

Existen tcnicas de descomposicin. Estimas el coste descomponiendo el producto y/o

el proceso.

Existen modelos empricos. Modelos de regresin que relacionan esfuerzo con tamao
o funcionalidad.