Estimacin de Costos, Esfuerzo y Recursos

Al momento de iniciar un proyecto de desarrollo de un producto de software, es importante

poder determinar cul ser el presupuesto en dinero y tiempo que tomar la construccin del
mismo. Un error en la estimacin del esfuerzo, costo y tiempo puede resultar desastroso para
las personas y organizaciones involucradas en el desarrollo del producto, debido a que
probablemente se duplique el costo previsto inicialmente, originando grandes prdidas
econmicas a la empresa duea del sistema, o simplemente se cancele el proyecto, perdiendo
todo el trabajo realizado.
Todo gerente de proyecto y analista de sistemas debera ser capaz de poder hacer una
estimacin de costos, que se acerque lo ms posible al costo real, que supondr el desarrollo
del sistema de informacin. Sin embargo esta es una labor difcil, ya que el esfuerzo, el costo
y el tiempo que toma hacer el producto, muchas veces deben ser establecidos antes de
poseer suficiente informacin sobre el mismo, incluso antes que comience su diseo, lo que
conlleva a que la persona encargada de realizar este anlisis deba tener mucha experiencia
en el desarrollo de software, para poder realizar una estimacin con base en el costo de
proyectos anteriores.
Durante mucho tiempo se han realizado estudios y se han creado tcnicas para facilitar
este trabajo, son muchos los autores que han propuesto diversas tcnicas a lo largo de la
historia de la ingeniera de software, por tanto durante este trabajo, abordaremos algunas de
las ms importantes y destacadas hasta la fecha.

Estimacin
La estimacin segn la Real Academia Espaola es el Aprecio y valor que se da y
en que se tasa y considera algo, En el rea de informtica, la estimacin es el anlisis del
tiempo, esfuerzo y recursos que tomar la creacin de un producto de software, es
prcticamente una obligacin para los gerentes del proyecto hacer este estudio para poder
as determinar el presupuesto necesario para su desarrollo. Esta labor no es fcil, ya que
son muchas las variables que se deben tener en cuenta al momento de realizar el anlisis,
como son las humanas, tcnicas, el entorno y las limitaciones propias del negocio, as como
tambin la poca informacin inicial de la magnitud del sistema, por lo que se necesita
realizar una prediccin de los costos, el personal requerido, los insumos y el tiempo que
tomar desarrollar cada una de las funcionalidades del software. Un error en el clculo del
presupuesto, podra significar el fracaso del proyecto.
Para reducir los riesgos de subestimar el costo del producto, se han creado varias
tcnicas, algunas basadas en algoritmos y otras en la pericia y experiencia de expertos,
personas que ya han estado involucradas en desarrollos similares anteriores. A continuacin
de detallarn algunas de las tcnicas ms conocidas, creadas para este fin.
Tcnicas de Descomposicin

Para facilitar el proceso de anlisis de un software, el sistema se debe descomponer

en varias funciones o componentes, para analizarlos por separado y realizar una estimacin
ms sencilla, y as luego poder unir todos los fragmentos y obtener una estimacin total del
costo del proyecto.
Por tanto la primera mtrica en la que nos basamos para realizar este anlisis es el
tamao del software, el cual puede ser medido en lneas de cdigos (LDC) o en puntos de
funciones (PF).
La tcnica LDC mide en forma directa el tamao del software. Se calcula contando
todas las instrucciones en cdigo fuente de cada uno de los componentes del sistema,
excluyendo los comentarios. Este mtodo tiene como desventaja que la medida del software
cambiar dependiendo del lenguaje de programacin en que est escrito, por ejemplo, un
programa desarrollado en lenguaje Java tendr menos lneas que el mismo programa escrito
en C.Mientras tanto la tcnica PF hace una medicin indirecta, mediante la estimacin de las

entradas, salidas, archivos de datos, y peticiones externas, segn algunos autores, como
refiere Pressman dicen que el PF es independiente del lenguaje de programacin, lo que lo
hace ideal para aplicaciones que usan lenguajes convencionales y no procedurales, y que se
basa en datos que es ms probable que se conozcan tempranamente en la evolucin de un
proyecto, lo que hace al PF ms atractivo como enfoque de estimacin (Pressman, 2010) ,
mientras que autores detractores dicen que este mtodo es subjetivo, ya que los datos que se
requieren para el clculo son difciles de recopilar.
Hay incluso quienes relacionan ambas mtricas y proponen mediciones de lneas de
cdigo requeridas para construir un punto de funcin.
Para calcular los puntos de funcin se usa la siguiente ecuacin:
= [0.65 + (0.01 ( ))]
Donde el conteo total es la suma de todas las entradas PF obtenidas, que se muestran
en la siguiente imagen:

Y los ( = 1 14) son factores de ajustes de valor con base en respuestas a las
siguientes preguntas:
1. El sistema requiere respaldo y recuperacin confiables?
2. Se requieren comunicaciones de datos especializadas para transferir informacin
hacia o desde la aplicacin?
3. Existen funciones de procesamiento distribuidas?
4. El desempeo es crucial?

5. El sistema correr en un entorno operativo existente enormemente utilizado?

6. El sistema requiere entrada de datos en lnea?
7. La entrada de datos en lnea requiere que la transaccin de entrada se construya
sobre mltiples pantallas u operaciones?
8. Los ALI se actualizan en lnea?
9. Las entradas, salidas, archivos o consultas son complejos?
10. El procesamiento interno es complejo?
11. El cdigo se disea para ser reutilizable?
12. La conversin y la instalacin se incluyen en el diseo?
13. El sistema se disea para instalaciones mltiples en diferentes organizaciones?
14. La aplicacin se disea para facilitar el cambio y su uso por parte del usuario?
Cada una de estas preguntas se responde usando una escala que vara de 0 (no
importante o aplicable) a 5 (absolutamente esencial). Los valores constantes en la ecuacin
y los factores ponderados que se aplican a los conteos de dominio de informacin se
determinan de manera emprica.
Tcnica de descomposicin del problema

Esta estimacin puede basarse en hechos histricos o en la intuicin del analista, se

apoya en las mtricas vistas anteriormente. Independiente de la variable de estimacin que
se utilice, se debe comenzar por estimar un rango de valor para cada funcin y as
determinar un valor optimista, otro pesimista y otro ms probable. Luego de realizado este
paso, se puede calcular un valor de tres puntos o esperado. Este valor esperado se calcula
como un promedio ponderado de las estimaciones optimista, ms esperada, y la pesimista.
=

+ 4 +
6

Una vez determinado el valor esperado para la variable de estimacin se aplican

datos de productividad histricos LOC o PF.
En la siguiente imagen se representa el proceso de anlisis de estimacin por
descomposicin del problema.

Tcnica de descomposicin basada en proceso

Esta tcnica de estimacin es la ms utilizada para estimar un proyecto, usando como

base de estimacin cada uno de los procesos que se realizaran durante la construccin del
software. Como en las tcnicas basadas en problemas, la estimacin basada en proceso
comienza con un delineado de las funciones de software obtenidas del mbito del proyecto.
Para cada funcin debe realizarse una serie de actividades de marco conceptual (Pressman,
2010).

Despus de que se combinan las funciones del sistema y los procesos a utilizar, se
estima el esfuerzo (hombre-mes) que se realizar para cada actividad del proyecto. Luego se
aplican las tarifas de la mano de obra (costo/unidad).

Estimacin Basada en casos de uso

Este mtodo cuenta con algunas desventajas de entrada, ya que los casos de uso son
visiones subjetivas de lo que debe realizar el sistema, y por tanto los niveles de abstraccin
pueden llegar a ser muy altos, lo que trae como consecuencia que no se pueda ver a primera
vista la complejidad de las operaciones que implica cumplir con ese caso de uso, Adems de
existen muchas formas de describir un caso de uso, no existe un estndar. Para utilizar esta
tcnica primero se define en qu nivel de abstraccin va estar cada caso de uso, se considera
la cantidad de pginas de cada caso de uso, el tipo de software que se est construyendo y
una arquitectura inicial del sistema. Una vez establecidas dichas caractersticas pueden
usarse datos empricos para establecer el nmero estimado de LOC o PF por caso de uso
(por cada nivel de la jerarqua). Entonces se usan datos histricos a fin de calcular el esfuerzo
requerido para desarrollar el sistema. (Pressman, 2010)
La siguiente ecuacin representa la forma de calcular el esfuerzo requerido:

= + [( 1) + ( 1)]

donde
N = Nmero real de casos de uso.
= LOC promedio histricas por caso de uso para este tipo de subsistema
= representa un ajuste con base en n por ciento de , donde n se
define localmente y representa la diferencia entre este proyecto y los proyectos
promedio
= escenarios reales por caso de uso
= escenarios promedio por caso de uso para este tipo de subsistema
= pginas reales por caso de uso.
= pginas promedio por caso de uso para este tipo de subsistema

Modelos de Estimacin Empricos

Todo modelo de estimacin utiliza frmulas empricamente inferidas para predecir el
esfuerzo como una funcin de LOC o PF (Pressman, 2010), lo cual nos dice que se utilizan
los clculos realizados en proyectos anteriores. Sin embargo se debe tener en cuenta que una
misma frmula no puede servir para todo tipo de software, por tanto hay que tener cierta
pericia, al momento de aplicar una frmula a un nuevo proyecto.
La ecuacin bsica que utiliza este tipo de modelo es:
= + ( )
donde A, B y c son constantes derivadas empricamente, E es el esfuerzo en persona-meses
y es la variable de estimacin (LOC o PF).
Algunos de los modelos de regresin que utilizan este enfoque pueden ser COCOMO
es sus versiones intermedia y avanzada, y el modelo Baylei-Basili.
Modelo COCOMO

Este modelo llamado Constructive Cost Model fue desarrollado en la dcada de los 80
por Barry Bohem con la intencin de ayudar a entender a la gente, las consecuencias de las
decisiones que se toman en la puesta en marcha, desarrollo y soporte de un producto de
software (Boehm, 1984) .
Introduce tres jerarquas para los modelos de estimacin:
1. Bsico: calcula el esfuerzo y el coste del desarrollo de software en funcin del
tamao del programa, expresado en las lneas estimadas de cdigo (LDC).
2. Intermedio: calcula el esfuerzo del desarrollo de software en funcin del
tamao del programa y de un conjunto de conductores de costo que incluyen
la evaluacin subjetiva del producto, del hardware, del personal, y de los
atributos del proyecto.
3. Avanzado: incorpora todas las caractersticas de la versin intermedia y lleva
a cabo una evaluacin del impacto de los conductores de costo en cada fase
del proceso de desarrollo del sistema.
Tambin se definen tres tipos distintos de proyectos de software:

1. Modo Orgnico: proyectos pequeos y sencillos en los que trabajan pequeos

equipos, con buena experiencia en la aplicacin, sobre un conjunto de
requisitos un poco rgidos.
2. Modo Semiacoplado: software intermedio en tamao y complejidad, en los
que equipos con diferentes niveles de experiencia, deben satisfacer
requerimientos un poco o medio rgidos.
3. Modo Empotrado: son aplicaciones que deben ser construidas en un conjunto
de hardware, software y restricciones operativas muy restringidas.
Las ecuaciones de estimacin del esfuerzo de desarrollo tienen la forma
= ()
donde

S es el nmero de lneas de cdigo.

m(X) es un multiplicador que depende de 15 atributos

en la siguiente tabla se muestran los coeficientes para los diferentes modos

El modelo bsico busca estimar de manera rpida y sencilla los proyectos de pequeo y
mediano tamao. Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el
tiempo de desarrollo.

= 2.4 1.05 donde se expresa en personas-mes y es el tamao expresado

en miles de lneas de cdigo fuente.

0.38
= 2.5
expresa el tiempo de desarrollo, donde se obtiene de la ecuacin

anterior y es el tiempo expresado en meses.

Las ecuaciones, anteriormente descritas, se aplican para software de tipo orgnico, en el

caso de los modos semiencajado y empotrado se utilizan las mismas ecuaciones pero con
diferentes coeficientes. Cabe destacar que a medida que se incrementa la complejidad del
proyecto, aumenta el valor de la constante, ya que se necesita mayor esfuerzo del personal.

EN el modelo bsico se debe tener cuidado al utilizar estas estimaciones, ya que no se toman
en cuenta muchos factores que inciden en el desarrollo de una aplicacin.
En el modelo intermedio se introducen quince atributos de coste para tener en cuenta el
entorno del trabajo. Estos atributos se usan para ajustar el coste nominal del proyecto al
entorno real, incrementando la precisin de la estimacin. Para cada modo de desarrollo
(orgnico, semiencajado y empotrado) los nuevos atributos de coste intervienen como
multiplicadores en el coste nominal para producir el coste ajustado. Las ecuaciones se
mantienen prcticamente igual, solo con algunas variaciones en los coeficientes.

Los

quince atributos se agrupan en cuatro categoras: atributos del producto,

atributos del ordenador, atributos del personal y atributos del proyecto.

1. Atributos del producto

RELY: garanta de funcionamiento requerida al software
DATA: tamao de la base de datos
CPLX: complejidad del producto
2. Atributos del ordenador
TIME: restriccin de tiempo de ejecucin
STOR: restriccin del almacenamiento principal
VIRT: volatilidad de la mquina virtual
TURN: tiempo de respuesta del ordenador
3. Atributos del personal
ACAP: capacidad del analista
AEXP: experiencia en la aplicacin
PCAP: capacidad del programador
VEXP: experiencia en mquina virtual
LEXP: experiencia en lenguaje de programacin
4. Atributos del proyecto
MODP: prcticas de programacin modernas
TOOL: utilizacin de herramientas software
SCED: plan de desarrollo requerido. (El modelo COCOMO, s.f.)

En la siguiente imagen, se puede ver de forma detallada los valores que toma cada
uno de los atributos, dependiendo del tipo de software que se va a construir.

En el modelo avanzado se agregan dos caractersticas, multiplicadores de esfuerzos

sensitivos a la fase, ya que en cada fase del desarrollo del software, algunas se ven ms
afectadas por ciertos atributos que otras; y una jerarqua del producto a tres niveles, que son
mdulo, subsistema y sistema, la cuantificacin se debe llevar a cabo en el nivel apropiado.
El modelo COCOMO II

Despus de que el modelo COCOMO introducido por Barry Bohem en el ao 1981 se

convirtiera en uno de los ms utilizados, sufri una evolucin hacia un modelo de estimacin
ms exhaustivo, llamado COCOMO II. Este modelo tambin es una jerarqua de modelos de
estimacin que se centra en los siguientes aspectos:
1. Modelo de composicin de aplicacin. Se usa durante las primeras etapas de la
ingeniera de software, cuando son primordiales la elaboracin de prototipos de las interfaces
de usuario, la consideracin de la interaccin del software y el sistema, la valoracin del
rendimiento y la evaluacin de la madurez de la tecnologa.
2. Modelo de etapa temprana de diseo. Se usa una vez estabilizados los requisitos
y establecida la arquitectura bsica del software.
3. Modelo de etapa postarquitectnica. Se usa durante la construccin del software.
(Pressman, 2010)
En este modelo tambin se necesitan mtricas para determinar la dimensin del
proyecto. Generalmente se usan los puntos de objetos, los cuales se calculan contando el
nmero de pantalla, reportes y componentes que se requieren para construir la aplicacin.

10

Para realizar el clculo se utiliza la siguiente frmula:

NOP = (puntos de objeto) X [(100 - %reuso)/100]
Donde el %reuso se utiliza cuando se hace un desarrollo por componentes y se
reutilizan varios de los objetos y NOP se define como nuevos puntos de objetos.
Para obtener la tasa de productividad, se divide los nuevos punto de objeto entre
persona-mes, donde se debe tomar en cuenta los diferentes niveles de experiencia del
desarrollador y la madurez del ambiente.
Finalmente para obtener el esfuerzo estimado se dividen los nuevos puntos de objetos
entre la productividad, calculada anteriormente.
=

Mtodo de Putnam Modelo SLIM

Surge en el ao 1978 para proveer un mtodo para estimar tiempo y esfuerzo. Fue
desarrollado por Putnam y lo llam modelo SLIM.
Putnam utiliza observaciones empricas sobre niveles de productividad para derivar
su ecuacin de software a partir de la frmula bsica de la curva de Rayleigh.

Esta ecuacin es:

4/3

= 1/3
donde

S es el nmero de lneas de cdigo

K es el esfuerzo del ciclo de vida en hombre-aos

es el tiempo de desarrollo en aos

es una constante tecnolgica

11

El modelo SLIM utiliza varias curvas separadas para diseo y codificacin, test y
validacin, mantenimiento, y gerenciamiento. Esta ecuacin permite jugar con el tiempo de
entrega del proyecto, ya que segn la misma, el esfuerzo es inversamente proporcional a la
potencia cuarta del tiempo de entrega. Por ejemplo, esta ecuacin dice que uno puede cortar
el costo del software a la mitad, simplemente incrementando su tiempo de desarrollo en un 19
por ciento (Boehm, 1984).
Tcnica Delphi

Fue creada en los aos cuarenta en EE.UU., pero se comienza a utilizar en la

informtica a partir del ao 1981, cuando es introducida por Barry Bohum. Esta tcnica cuanta
con una serie de pasos que listamos a continuacin:

Un coordinador proporciona a cada experto una especificacin del proyecto propuesto

y un impreso para expresar su opinin.

Los expertos rellenan el formulario de manera annima. Pueden hacer preguntas al

coordinador pero no entre ellos.

El coordinador ofrece a cada experto el valor medio de las opiniones recogidas. Se

pide una nueva estimacin annima indicando las razones de las posibles
modificaciones.

Se repite el proceso de recogida de opiniones hasta llegar a un consenso. No se

realizan reuniones en grupo en ningn momento.
Luego Bohum propuso un refinamiento a esta tcnica agregando dos nuevos pasos:

El coordinador proporcionada a cada experto una especificacin del proyecto

propuesto y un impreso para expresar su opinin.

El coordinador rene a los expertos para que intercambien puntos de vista sobre el
proyecto.

Los expertos rellenan el impreso de manera annima.

El coordinador ofrece a cada experto el valor medio de las opiniones recogidas. Se

pide una nueva estimacin annima, sin indicar las razones de las posibles
modificaciones.

El coordinador convoca una reunin para que los expertos discutan las razones de las
diferencias entre sus estimaciones.

Se rellenan annimamente los impresos y se repite los puntos 4, 5 y 6 hasta llegar a

un consenso.

12

Cuadro Comparativo
Descomposicin del

Descompos

Descomposicin

COCOMO

COCOMO II

SLIM

Delphi

Problema

icin en

en casos de uso

1981

1995

1978

1940/1981

Pginas casos de

LOC, factores

KLOC, PF, puntos de

LOC y PF

uso, LOC, PF

de ajustes

objetos

procesos
Ao
Creacin
Mtricas

Mtodo
estimacin

LOC y PF

LOC y PF

+ 4 +
6

= ()

+ [( 1)

4/3

= 1/3

Opiniones de
expertos
escritas en
formularios

+ ( 1)]

rea de

Software

Software

Software

Software y Entorno

Software

Entorno

Estudio
Criterio

Software y

Objetivo

Subjetivo

Subjetivo

Subjetivo

Software y
Entorno

Subjetivo

Subjetivo

Subjetivo

Conclusin

Como se pudo ver, son muchas las tcnicas de estimacin de esfuerzo y costo
creadas a lo largo del tiempo, que se han ido actualizando conforme han ido apareciendo
nuevos paradigmas en el desarrollo de software. Sin embargo ninguna de las tcnicas
garantiza una fiabilidad total, ya que cada proyecto es distinto y los factores que inciden en su
costo pueden ser distintos.
Cada una de las tcnicas vistas ofrece un mtodo para tener una estimacin
aproximada del esfuerzo y el costo que tomar desarrollar un proyecto, pero los valores
finales, dependern de la experiencia y la pericia que posea la persona que analiza la
estimacin, y as poder obtener un presupuesto que se ajuste a la realidad de cada
organizacin.

Bibliografa

Boehm, B. W. (1984). Software Engineering Economics. IEEE Transactions on Software

Engineering, 200-217.
El modelo COCOMO. (s.f.). Obtenido de www.sc.ehu.es:
http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm
Mtodos de Estimacin. (s.f.). Obtenido de http://www.lsi.us.es/docencia/get.php?id=326
Pressman, R. S. (2010). Ingeniera del Software. Un enfoque prctico. Mxico, D. F.:
McGRAW-HILL.

15