Вы находитесь на странице: 1из 33

ESTIMACION DE COSTOS DE PROYECTOS DE SISTEMAS DE INFORMACION

http://ingenieroduqueescobar.blogspot.com/2010/06/estimacion-de-costos-deproyectos-de_19.html

1.1. Estimacin de costos de Proyecto


La estimacin y al calendarizacin del proyecto se llevan a cabo de forma
conjunta. Sin embargo. En las primeras etapas del proyecto se requieren
algunas estimaciones de costos, antes de que se tenga la calendarizacin
detallada. Estas estimaciones son necesarias para establecer un presupuesto
para el proyecto o para asignar un precio para el software de un cliente.

Una vez que el proyecto se encamina, las estimaciones se actualizan de forma


regular. Esto ayuda al proceso de planeacin y permite la utilizacin efectiva de
los recursos. Si el gasto real es significativamente ms grande que las
estimaciones, entonces el administrador del proyecto debe tomar algunas
acciones. Estas pueden ser solicitar recursos adicionales para el proyecto o
modificar el trabajo a realizar.

Existen tres parmetros involucrados en el clculo del costo total de un


proyecto de desarrollo de software:

Los costos del hardware y software, incluyendo mantenimiento;


Los costos de viajes y capacitacin;
Los costos de esfuerzo (los costos de pago a los ingenieros de software)

Para muchos proyectos, el costo dominante es el costo de esfuerzo. Las


computadoras que son suficientemente poderosas como para desarrollar el
software son relativamente baratas. Aunque los costos de viajes pueden ser
importantes si un proyecto se desarrolla en sitios distintos, son relativamente
bajos para muchos proyectos. Adems el uso de correos electrnico, fax y
teleconferencias reduce los viajes requeridos.

Los costos de esfuerzo no son simplemente los relacionados a los salarios de


los ingenieros de software involucrados en el proyecto. Las organizaciones
calculan los costos de esfuerzo en trminos de los costos de sobrecarga donde
se toma en cuenta el costo total de hacer funcionar la organizacin y dividen
este entre el nmero de personas productivas. Por lo tanto los siguientes
costos son parte de los costos de esfuerzo totales:

a. Los costos de proveer, calentar e iluminar oficinas.


b. Los costos del personal de apoyo como los contadores, secretarias,
limpiadores y tcnicos.
c. Los costos de las redes y las comunicaciones.
d. Los costos de los recursos centralizados como las bibliotecas, los recursos
recreativos, etctera.
e. Los costos de seguridad social y de beneficio de empleados como las
pensiones y los seguros de salud.

FACTOR
DESCRIPCION
Oportunidad de mercado
Una organizacin de desarrollo podra cotizar un bajo precio debido a que
desea moverse a un nuevo mercado del software. Aceptar un bajo beneficio en
un proyecto podra darle la oportunidad de obtener ms beneficios
posteriormente. La experiencia obtenida le permite desarrollar nuevos
productos.
Incertidumbre en la estimacin de costos
Si una organizacin esta insegura de su costo estimado por alguna
contingencia puede incrementar su precio por encima del beneficio normal.
Trminos contractuales
Un cliente puede estar dispuesto a permitir que el desarrollador retenga la
propiedad del cdigo fuente y que reutilice dicho cdigo en otros proyecto. Por
lo tanto, el precio cargado podra ser menor que si el cdigo fuente del
software se le entrega al cliente.
Volatilidad de los requerimientos

Si es probable que los requerimientos cambien, una organizacin puede reducir


los precios para ganar un contrato. Despus de que el contrato se asigna, se
cargan precios altos a los cambios en los requerimientos.
Salud financiera
Los desarrolladores en dificultades financieras podran bajar sus precios para
obtener un contrato. Es mejo tener beneficios ms bajos que los normales o
incluso quebrar antes que quedar fuera de los negocios.
Cuadro 1: Los factores que afectan la asignacin de precios al software.

Tpicamente, este factor de sobrecarga es alrededor de dos veces el salario del


ingeniero de software, dependiendo del tamao de la organizacin y sus
sobrecargas asociadas. Por lo tanto, si un ingeniero de software se le pagan
$90 000 al ao, el costo total de la organizacin es de $180 000 por ao a $15
000 por mes.

Calcular los costos del software se debe llevar a cabo de forma objetiva con el
fin de predecir de forma precisa cuanto le cotara al contratista desarrollar el
software. Si los costos del proyecto se calculan como parte de una oferta a un
cliente, entonces se tiene que tomar una decisin del precio que se le dar al
cliente. Por lo general, el precio es simplemente el costo ms el beneficio. Sin
embargo, la relacin entre el costo del proyecto y el precio al cliente por lo
regular no es tan simple.

Asignar un precio al software debe tomar en cuenta consideraciones


organizacionales, econmica, polticas y de negocios. En el cuadro N1 se
muestran los factores que se deben tomar en cuenta. Por lo tanto, no existe
una relacin sencilla entre el precio que se le da al cliente por el software y los
costos de desarrollo. Debido a las consideraciones organizacionales
involucradas, asignar el precio del proyecto por lo general le concierne al
administrador principal de la organizacin, as como a los administradores del
proyecto de software.

1.1.1. Productividad
La productividad en un sistema de manufactura se mide contando el nmero
de unidades que se producen y dividiendo ste entre el nmero de personashora requeridas para producirlas. Sin embargo, para cualquier problema de

software, existen muchas soluciones diferentes con distintos atributos. Una


solucin podra ejecutarse de forma ms eficiente mientras que otra podra ser
ms legible y fcil de mantener. Cuando se producen soluciones con diferentes
atributos, no tiene sentido comparar estas tasas de produccin.

Sin embargo, los administradores tienen que estimar la productividad de los


ingenieros en el proceso de desarrollo de software. Estas estimaciones son
necesarias para la estimacin del proyecto y para valorar si los procesos o las
mejoras tecnolgicas son efectivas. Por lo general, estas estimaciones de
productividad se basan en medir algunos atributos del software y dividir el
resultado entre el esfuerzo total requerido para el desarrollo. Existen dos tipos
de medidas utilizadas:

1.1.1.1. Medidas relacionadas con el tamao


Estas se relacionan con el tamao de alguna salida de una actividad. La
medida ms comn relacionada con el tamao son las lneas de cdigo fuente
entregadas. Otras medidas que se utilizan son el numero de instrucciones de
cdigo objeto entregado o el nmero de pginas de la documentacin.

1.1.1.2. Medidas relacionadas con la funcin


Estas se relacionan con la funcionalidad total del software entregado. La
productividad se expresa en trminos de la cantidad de funcionalidad til
producida en un tiempo dado. Los puntos de funcin y los puntos de objeto son
las medidas ms conocidas de este tipo.

Las lneas de cdigo fuente por programador-mes son una mtrica


ampliamente utilizada en la medida de la productividad. Esta se calcula
contando de nmero total de lneas del cdigo fuente que se entrega. La
cuenta se divide entre el tiempo total de programadores-mes requeridos para
completar el proyecto. Por lo tanto, este tiempo incluye el tiempo requerido
para el anlisis y diseo, codificacin, pruebas y documentacin.

Este enfoque se desarrollo cuando muchos de los programas estaban en


FORTRAN, lenguaje ensamblador o COBOL. Entonces, los programas se
tecleaban en tarjetas, con una instruccin en cada tarjeta. El nmero de lneas
del cdigo era fcil de calcular. Corresponda al nmero de tarjetas en la cabina

de tarjetas. Sin embargo, los programadores en lenguajes como JAVA o C++


consisten de declaraciones, instrucciones ejecutables; otras cuentan las
instrucciones ejecutables y comentarios. Incluyen macroinstrucciones que
ocupan varias lneas de cdigo. Existe ms de una instruccin por lnea. Por lo
tanto, no existe una relacin sencilla entre las instrucciones del programa y las
lneas de un listado.

Algunas tcnicas de conteo de lneas consideran solo las instrucciones


ejecutables; otras cuentan las instrucciones ejecutables y las de datos; algunas
cuentan cada lnea que no est en blanco en el programa, independientemente
de lo que est en esa lnea. Se han propuesto estndares para el conteo de
lneas para varios lenguajes (Park, 1992) pero stos no son ampliamente
conocidos. Las comparaciones de productividad en las organizaciones son
imposibles a menos que cada organizacin utilice el mismo mtodo para contar
las lneas de cdigo.

Comparar la productividad de los diferentes lenguajes de programacin


tambin da impresiones engaosas de productividad del programador. Entre
ms expresivo sea un lenguaje de programacin, ms baja es la productividad
aparente. Esta anomala surge debido a que todas las actividades de desarrollo
de software se consideran de forma conjunta cuando se calcula la
productividad pero la mtrica utilizada slo aplica a los procesos de
programacin.

Anlisis
Diseo
Codificacin
Pruebas
Documentacin
Cdigo ensamblador
3 semanas
5 semanas
8 semanas
10 semanas

2 semanas
Lenguaje de alto nivel
3 semanas
5 semanas
8 semanas
6 semanas
2 semanas
Tamao
Esfuerzo
Productividad
Cuadro 2. Tiempos de desarrollo del sistema.
Cdigo ensamblador
5000 lneas
28 semanas
714
lneas/mes
Lenguaje de alto nivel
1500 lneas
20 semanas
300 lneas/mes

Por ejemplo, considere un sistema que podra codificarse con 5000 lneas de
cdigo ensamblador o 1500 lneas de cdigo en un lenguaje de alto nivel. En el
cuadro 2 se muestra el tiempo de desarrollo para las diversas fases. El
programador en lenguaje de alto nivel menos de la mitad de estas, 300
lneas/mes. As los costos de desarrollo para el sistema en lenguajes de alto
nivel son menores y se producen en menor tiempo.

Una alternativa a la utilizacin del tamao del cdigo como atributo estimado
del producto es utilizar alguna medida de la funcionalidad del cdigo. Esto
evitara la anterior anomala puesto que la funcionalidad del cdigo. Esto
evitar la anterior anomala puesto que la funcionalidad es independiente de la
implementacin del lenguaje. MacDonell (1994) brevemente describe y
compara varias medidas diferentes basadas en la funcin.

La ms conocida de estas medidas es el conteo de puntos de funcin. ste fue


propuesto por Albrecht (1979) y refinado por Albretch y Gaffney (1983). Los
puntos de funcin son independientes del lenguaje por lo que se puede
comparar la productividad en los diversos lenguajes de programacin. La
productividad se expresa como puntos de funcin producidos por personasmes. Los puntos de funcin son adecuados para sistemas de procesamiento de
datos que estn dominados por operaciones de entrada y salida. Un punto de
funcin no es una caracterstica simple sino que es una combinacin de
caractersticas del programa. El nmero total de puntos de funcin en un
programa se calcula midiendo o estimando las siguientes caractersticas del
programa:

Entradas y salidas externas.


Interacciones con el usuario.
Interfaces externas.
Archivos utilizados por el sistema.

Cada una de estas se evala de forma individual acorde a su complejidad y se


le asigna un valor de peso que vara desde 3 (para las entradas externas
sencillas) hasta 15 (para los archivos internos complejos). Se pueden utilizar
los valores de peso propuestos por Albretch o valores basados en la
experiencia local.

El conteo de los puntos de funcin no ajustados (UFC) se calcula multiplicando


los conteos llanos por el peso estimado y sumando todos los valores.

UFC =

Despus, este conteo inicial de puntos de funcin es modificado por factores


cuyo valor se basa en la complejidad total del proyecto. Esto toma en cuenta el
grado de procesamiento distribuido, la cantidad de reutilizacin, el desempeo,
etctera. El conteo de puntos de funcin no ajustados se multiplica por los
factores de complejidad del proyecto para producir un conteo de puntos
funcin final.

Symons (1988) observo que la naturaleza subjetiva de la complejidad de las


estimaciones implicaba que el conteo de puntos de funcin en un programa
depende de la persona que hace la estimacin. Varias personas tienen
nociones diferentes de complejidad. Existe una amplia variedad de conteos de
puntos de funcin, dependiendo del juicio del estimador. Por esta razn,
existen versiones que difieren acerca del valor de los puntos de funcin (Furey
y Kitchenham, 1997). Sin embargo, los usuarios argumentan que, a pesar de
estos defectos, son efectivos en situaciones prcticas (Kemerer, 1993)

Los puntos de objeto (Banker 1992) son una alternativa para los puntos de
funcin cuando se utilizan 4GLs o lenguajes comparables para el desarrollo de
software. Los puntos de objeto se utilizan en el modelo de estimacin
COCOMO.

Los puntos de objeto no son clases de objetos que se producen cuando se


considera un enfoque orientado a objetos para el desarrollo de software. Ms
bien, el nmero de puntos de objeto en un programa es una estimacin con
peso:

a. El nmero de pantallas independientes que se despliegan. Las pantallas


sencillas cuentan como 1 punto de objeto, las pantallas moderadamente
complejas cuentan como 2 y las pantallas muy complejas cuentan como 3
puntos de objeto.
b. El numero de informes que se producen. Para informes simples, cuentan
como 2 puntos objeto, para informes moderadamente complejos, cuentan
como 5 y para informes que son difciles de producir, cuentan como 8 puntos
objeto.

c. El numero de mdulos 3GL que deben desarrollarse para complementar el


cdigo 4GL- cada mdulo 3GL cuenta como 10 puntos de objeto.

La ventaja de utilizar puntos de objeto en lugar de puntos de funcin es que


son ms fciles de estimar a partir de la especificacin del software de alto
nivel. Los puntos de objeto solo se refieren a las pantallas, informes y mdulos
3GL.

Si se utilizaran los puntos de funcin o los puntos de objeto, entonces se


pueden estimar en las primeras etapas del proceso de desarrollo. Las
estimaciones de estos parmetros se pueden hacer tan pronto como se
diseen las interacciones externas del sistema. En esta etapa, es muy difcil
producir una estimacin precisa del tamao de un programa en lneas de
cdigo fuente. En efecto, tal vez el lenguaje de programacin a utilizar aun no
est decidido. Las primeras estimaciones son esenciales cuando se utilizan los
modelos de estimacin de costos algortmicos.

Los conteos de los puntos de funcin se pueden utilizar junto con las tcnicas
de estimacin de lneas de cdigo. El nmero de puntos de funcin se utiliza
para estimar el tamao final del cdigo, AVC, en un lenguaje particular
requerido para implementar un punto de funcin. El tamao estimado del
cdigo para una nueva aplicacin se calcula como se muestra a continuacin:

Tamao del cdigo = AVC x Nmero de puntos de funcin.

FACTOR
DESCRIPCION
Experiencia en el dominio de la aplicacin

Conocer el dominio de la aplicacin es esencial para el desarrollo efectivo de


software. Los ingenieros que ya conocen un dominio son probablemente los
ms productivos.
Calidad del proceso
El proceso de desarrollo utilizado puede tener un efecto importante en la
productividad.
Tamao del proyecto
Entre ms grande sea un proyecto, se requiere ms tiempo para las
comunicaciones del equipo. Se dispone de menos tiempo para el desarrollo por
lo que la productividad individual se reduce.
Apoyo tecnolgico
La productividad se puede mejorar si se tiene buen apoyo tecnolgico como de
la herramientas CASE, de sistemas de administracin de la configuracin,
etctera.
Ambiente de trabajo
Un entorno de trabajo silencioso con reas de trabajo privado contribuye a
mejorar la productividad.
Cuadro 3: Los factores que afectan la productividad de la ingeniera de
software.

La productividad de los ingenieros que trabajan en una organizacin se ve


afectada por varios factores. Algunos de los ms importantes se resumen en el
cuadro 3. Sin embargo, las diferencias individuales en la habilidad son ms
importantes que cualquiera de estos factores. En una primera valoracin de la
productividad encontraron que algunos programadores eran diez veces ms
productivos que otros. La experiencia seala que esto an es cierto. Los
equipos grandes tienen una mezcla de habilidades por lo que tiene una
productividad promedio. Sin embargo, en los equipos pequeos la
productividad total depende en gran medida de las aptitudes y habilidades
individuales.

No existe algo similar a un valor Promedio para la productividad que aplique


a los dominios de aplicacin y a las organizaciones. Para sistemas incrustados,
grandes y complejos, la productividad es tan baja como 900 lneas/mes.
Cuando se mide en trminos de de puntos de objeto. Bohem seala que la

productividad vara desde cuatro puntos de objeto por mes hasta 50 puntos de
objeto/mes dependiendo de la herramienta de apoyo y de la capacidad del
desarrollador.

El problema cuando estas medidas se expresan como volumen/tiempo es que


no toman en cuenta las caractersticas no funcionales del software como la
fiabilidad, el mantenimiento, etc.

1.1.2. Tcnicas de estimacin


No existe una forma simple de hacer una estimacin precisa del esfuerzo
requerido para desarrollar un sistema de software. Las estimaciones iniciales se
hacen bajo la base de la definicin de requerimientos de usuario de alto nivel.
El software tiene que ejecutarse en computadoras poco familiares o utilizar
nuevas tecnologas de desarrollo. Probablemente no se conozcan las personas
involucradas en el proyecto y sus habilidades. Todos estos factores significan
que en una primera etapa del proyecto es difcil producir una estimacin
precisa de los costos de desarrollo del sistema.

Por lo general, las estimaciones de los costos del proyecto se cumplen por su
propia naturaleza. La estimacin se utiliza para definir el presupuesto del
proyecto y el producto se ajusta par que las cifras del presupuesto se cumplan.
No se conocen informes de experimentos controlados sobre los costos de los
proyectos donde los costos estimados no se utilicen para ajustar el
experimento. Un experimento controlado no revelara la estimacin del costo al
administrador del proyecto. Los costos reales tendran que compararse con los
estimados del proyecto.

A pesar de esto, las organizaciones necesitan hacer esfuerzos de software y


estimaciones de los costos. Para hacerlo, se utilizan una o ms de las tcnicas
descritas en el siguiente cuadro.

FACTOR
DESCRIPCION
Modelado del algoritmo de costos
Se desarrolla un modelo utilizando informacin histrica de costos que
relaciona alguna mtrica de software (por lo general, su tamao) con el costo
del proyecto. Se hace una estimacin de esa mtrica y el modelo predice el
esfuerzo requerido.
Opinin de expertos
Se consultan varios expertos en las tcnicas de desarrollo de software
propuestas y en el dominio de aplicacin. Cada uno de ellos estima el costo del
proyecto. Estas estimaciones se comparan y discute. El proceso de estimacin
se itera hasta que se acuerda una estimacin.
Estimacin por analoga
Esta tcnica es aplicable cuando otros proyectos en el mismo dominio de
aplicacin se han completado. Se estima el costo de un nuevo proyecto por
analoga con estos proyectos completados Myers (1989) da una descripcin
muy clara de este enfoque.
Ley de Parkinson
La ley de Parkinson establece que el trabajo se extiende para llenar el tiempo
disponible. El costo se determina por los recursos disponibles ms que por los
objetivos logrados. Si el software se tiene que entregar en 12 meses t se
dispone de cinco personas el esfuerzo requerido se estima en 60 personas-mes
Asignar precios para ganar
El costo del software se estima independientemente de lo que el cliente est
dispuesto a pagar por el proyecto. El esfuerzo estimado depende del
presupuesto del cliente y no de la funcionalidad del software.
Cuadro 4: Tcnicas de estimacin de costos.

Cuando se estiman costos de software, los administradores deben tomar en


cuenta que existen diferencias importantes entre los proyectos anteriores y los
futuros. Una gran variedad de nuevos mtodos y tcnicas de desarrollo han
aparecido en los ltimos diez aos. Muchos administradores tienen poca
experiencia en estas tcnicas o poco conocimiento de cmo estas afectan los

costos de los proyectos. Algunos ejemplos de los cambios que afectan las
estimaciones de acuerdo con la experiencia son:

Desarrollo orientado a objetos en lugar de desarrollo orientado a funciones.


Sistemas cliente-servidor en lugar de sistemas basados en mainframes.
Utilizacin de componentes de software comerciales en lugar de desarrollo
de componentes.
Desarrollar y reutilizar en lugar de desarrollar todas las partes de un sistema.
La utilizacin de herramientas CASE y generadores de programas en lugar de
desarrollo de software sin ayuda.

Todos estos factores han difcil que los administradores produzcan estimaciones
precisas de los costos de produccin del software. Su experiencia previa no es
relevante para ayudarles a estimar los costos del proyecto de software.

1.1.3. Modelado algortmico de costos


El enfoque ms sistemtico, aunque no necesariamente el ms preciso, para la
estimacin del software es la estimacin algortmica de costos. Un modelo
algortmico de costos se construye analizando los costos y atributos de los
proyectos realizados. Se utiliza una frmula matemtica para predecir los
costos basados en estimaciones del tamao del proyecto, nmero de
programadores y otros factores de los procesos y productos Kitchenham (1990)
describe 13 modelos algortmicos de costos desarrollados a partir de
observaciones empricas.

En su forma general, una estimacin algortmica de costos para el software se


expresa como:

Esfuerzo = A x Tamao B x M

Esta frmula A es un factor constante que depende de las practicas


organizacionales locales y del tipo de software que se desarrolla. Tamao es

una valoracin del tamao del cdigo del software o una estimacin de la
funcionalidad expresada en puntos de funcin o de objetos. El valor de
exponente B por lo general se encuentra entre 1 y 1.5. Refleja el esfuerzo
requerido para proyectos grandes. M es un multiplicador generado al combinar
diferentes procesos, atributos del producto y del desarrollo.

Todos los modelos algortmicos padecen las mismas dificultades bsicas.

a. A menudo es difcil estimar Tamao en una primera etapa de un proyecto


donde solamente est disponible la especificacin. Las estimaciones de los
putos de funcin y los puntos de objeto son los ms fciles de producir que las
del tamao del cdigo pero puede ser imprecisas.
b. Las estimaciones de los factores B y M son subjetivas. Las estimaciones
varan de una persona a otra, dependiendo de su conocimiento y experiencia.

1.1.3.1. El modelo COCOMO


Se han propuesto varios modelos algortmicos como una base para estimar el
esfuerzo, la calendarizacin y los costos de un proyecto de software. stos son
similares conceptualmente pero utilizan diferentes valores en sus parmetros.
El modelo especifico que se discute aqu es el modelo COCOMO. ste es un
modelo emprico. Se obtuvo recolectando datos de varios proyecto de software
grandes y despus analizando esos datos para descubrir formulas que se
ajustaran mejor a las observaciones. Eleg COCOMO por las siguientes razones.

a. Est bien documentado, es de dominio pblico y lo apoyan el dominio


pblico y las herramientas comerciales.
b. Se ha utilizado y evaluado muy ampliamente.
c. Tienen una gran tradicin desde su primera versin en 1981 (Bohem, 1981),
pasando por un refinamiento para el desarrollo de software en ADA (Bohem y
Royce 1989) gasta su versin ms reciente publicada en 1995. (Bohem, 1995)

La primera versin del modelo COCOMO (conocida como COCOMO 81) fue un
modelo de tres niveles donde estos reflejaban el detalle del anlisis de la
estimacin del costo. El primer nivel (bsico) provee una estimacin inicial

burda, el segundo nivel modifica utilizando varios multiplicadores del proyecto


y el proceso, y el nivel ms detallado produce estimaciones para las diferentes
fases del proyecto. El siguiente cuadro muestra la formula bsica de COCOMO
para los diferentes tipos de proyectos.

Complejidad del proyecto


Frmula
Descripcin
SIMPLE
PM = 2.4 (KDSI)1.05 x M
Aplicaciones bien comprendidas desarrolladas por equipos pequeos.
MODERADA
PM = 3.0 (KDSI)1.12 x M
Proyectos ms complejos donde los miembros del equipo tienen experiencia
limitada en sistemas relacionados.
INCRUSTADA
PM = 3.6 (KDSI)1.20 x M
Proyectos complejos donde el software es parte de un complejo fuertemente
acoplado de hardware, software, reglas y procedimientos operacionales.
Cuadro 5: El modelo bsico de COCOMO 81

1.1.3.2. Modelo algortmico de costos en la planeacin del proyecto


Los administradores de proyectos pueden utilizar un modelo algortmico de
costos para comparar las diferentes formas de invertir dinero para reducir los
costos del proyecto. Esto es particularmente importante donde existen costos e
hardware/software comerciales y donde se necesita reclutar nuevo persona con
habilidades especificas para el proyecto.

Considere un sistema incrustado para controlar un experimento que se lanzar


al espacio. Los experimentos espaciales tienen que ser muy fiables y estn
sujetos a lmites de peso rigurosos. El numero de chips es una tarjeta

electrnica tiene que minimizarse. En trminos del modelo COCOMO, los


multiplicadores correspondientes a las restricciones y la fiabilidad de la
computadora son ms grandes que 1.

Existen tres componentes a ser tomados en cuenta en el costo de este


proyecto:

a. El costo del hardware objetivo que ejecuta el sistema.


b. El costo de la plataforma (computadora mas hardware) para desarrollar el
sistema.
c. El costo del esfuerzo requerido para desarrollar el software.

1.1.4. Duracin y personal del proyecto


As como es necesario estimar el esfuerzo requerido para desarrollar un
sistema de software y los costos totales del esfuerzo, los administradores de
proyectos tambin estiman cunto durara el desarrollo del software y cuanto
personal se necesita para trabaje en el proyecto. El tiempo de desarrollo del
proyecto se denomina duracin del proyecto. Cada vez ms, las organizaciones
demandan tiempos de duracin ms cortos para que sus productos salgan al
mercado antes que los de sus competidores.

La relacin entre el nmero de personas que trabajan en un proyecto, el


esfuerzo total requerido y el tiempo de desarrollo no es lineal. En cuanto crezca
el nmero de personal, se necesitara ms esfuerzo. Las personas deben
invertir ms tiempo en comunicarse. Se requiere ms de un tiempo para definir
las interfaces entre las partes del sistema. Doblar el nmero de personas (por
ejemplo) no significa que la duracin del proyecto se reducir a la mitad.

1.2. Estimacin De Costos De Proyecto


Cualquier tarea pasada por alto inadvertidamente durante el periodo de
estimacin, dar como resultado un menosprecio del proyecto en su totalidad,
este hecho, a su vez podra comprometer la planificacin del factor tiempo y de

los recursos que se deben utilizar y, lo que es peor, habr que pagar un trabajo
omitido, no en base al presupuesto, sino en base a los beneficios esperados.
Toda empresa con experiencia en la ejecucin de proyectos software debe de
elaborar unas listas de comprobacin para cotejar con las listas de trabajo del
propio proyecto para salvaguardar omisiones. Repetimos que cualquier detalle
pasado por alto en la fase del estudio del esfuerzo a aplicar puede tener
consecuencias importantes, no slo en la dimensin temporal del proyecto,
sino en la calidad del producto a obtener o en el calendario del propio proyecto.
Existen muchos estudios sobre las tcnicas de estimacin de costes, el objetivo
de la presente leccin no es presentar al alumno una descripcin de todas y
cada una de ellas, pero s de las ms utilizadas, por eso presentamos la tcnica
de los puntos funcin de Albrecht (IBM), el COCOMO (Constructive Cost
Method) de Boehm y la estimacin de Putman.
El ms utilizado es el de los puntos funcin de Albrecht cuya originalidad
proviene de estimar los costes en funcin de la complejidad de los aspectos
externos, o funciones, del propio programa. Por otra parte est bastante
extendido el mtodo COCOMO de Boehm que se describe en su libro 1
"Software Engineering Economics", y presenta una tcnica del modelo a tres
niveles segn la complejidad de los proyectos aportando herramientas para
controlar el coste, no slo del diseo y desarrollo del sistema, sino que cubre
todos los aspectos en la estimacin de todo el proyecto a lo largo de su ciclo de
vida, excepto el estudio de viabilidad, puesta en marcha y mantenimiento.
1.2.1. Modelos Empricos
Una vez asentados sus conocimientos sobre las fases en que se divide un
proyecto software desde las perspectivas de los distintos paradigmas de la
Ingeniera del Software se considera, en lneas generales, que todo proceso de
desarrollo de software est compuesto por tres fases genricas que son:
definicin, desarrollo y mantenimiento, y en todos ellos tenemos que
considerar los modelos de estimacin de costes, que si bien en Informtica no
son relativamente novedosos, ya que los primeros esbozos en estudiar este
problema comenzaron hace poco ms de dos dcadas, la implantacin real en
la industria no se ha realizado de forma masiva hasta que se ha dado el hecho
de que el software se ha convertido en el factor ms costoso de un sistema de
informacin; es ms: la desviacin producida por los costes de software en el
desarrollo de un proyecto tena poca incidencia en el coste total, cosa que no
ocurre hoy da ya que un error de estimacin del tiempo de desarrollo puede
colocar el proyecto entre el beneficio y la prdida econmica.
Los modelos de estimacin tienen aplicacin dentro de la fase de definicin de
un sistema software. En esta fase lo que se define es el qu, es decir, se
intenta identificar en ella qu informacin va a ser procesada, qu funcin y

rendimiento se desea, qu interfaces han de establecerse, qu ligaduras de


diseo existen y, por ltimo, qu criterios de validacin se requieren para
definir un sistema correcto. Dentro de la mayor parte de las organizaciones, la
estimacin de costes de un sistema software est basada en experiencias
pasadas. Los datos histricos se usan para identificar los factores de coste y
determinar la importancia relativa de los diversos factores dentro de la
organizacin. Lo anteriormente expuesto implica que los datos de coste y
productividad de los proyectos actuales deben de ser centralizados y
almacenados para su empleo posterior. La estimacin de costes puede llevarse
a cabo de forma jerrquica hacia abajo (Top-Down) o jerrquica hacia arriba
(Bottom-Up).
La estimacin jerrquica hacia abajo se enfoca primero a los costes a nivel del
sistema, adems de los costes del manejo de la configuracin, del control de
calidad, de la integracin del sistema, del entrenamiento y de la
documentacin. Los costes del personal relacionado se estiman mediante el
examen del coste de proyectos anteriores que resulten similares. En la
estimacin jerrquica hacia arriba, primero se estima el coste del desarrollo de
cada mdulo o subsistema, tales costes se integran para obtener un coste
total. La tcnica puede fallar al no considerar los costes del manejo de la
configuracin o del control de calidad, pero tiene la ventaja de enfocarse
directamente a los costes del sistema. Podemos establecer una clasificacin de
los llamados modelos empricos de estimacin de costes basados en la
experiencia:
1.2.1.1. Juicio de experto
En esta categora un experto o grupo de expertos estudia las especificaciones y
hace su estimacin (jerrquica hacia arriba o hacia abajo) en base a sus
conocimientos previos. Cuando hay un nico experto se denomina juicio
experto puro y la empresa corre el riesgo de confiar una tarea tan importante a
una nica persona. Si desaparece el experto se deja de estimar. Si es un grupo
de expertos el que estima se suele utilizar el mtodo Delphi o juicio experto.
Este mtodo consiste en que el grupo se rene para dar sus opiniones sobre la
estimacin. Las conclusiones individuales se envan al coordinador del grupo
que las compara entre s. Si los resultados son parecidos la estimacin se da
por buena, si no es as cada estimador recibe informacin sobre su estimacin,
y las ajenas pero de forma annima. Cada uno revisa su propia estimacin y la
enva de nuevo al coordinador. Se repite el proceso hasta que la estimacin
converge de forma razonable. Es posible realizar nuevas reuniones del grupo si
el coordinador lo considera oportuno segn la divergencia de las estimaciones
recibidas Tiene la ventaja de que las estimaciones de un grupo suelen ser
mejores que las individuales y que el experto nico no se convierte en un
recurso crtico imprescindible.

1.2.1.2. Analoga
Consiste en comparar las especificaciones de un proyecto, con las de otros
proyectos similares segn el tamao, complejidad, nmero y tipo de usuarios y
otros factores como sistemas operativos, hardware, personal, etc.
1.2.1.3. Distribucin de la utilizacin de los recursos durante el ciclo de vida.
Este mtodo solo se puede aplicar cuando el proyecto ya ha comenzado y se
ha desarrollado alguna de sus fases. Usualmente las organizaciones tienen una
estructura de costes similar entre las distintas fases del ciclo de vida
(especificaciones, anlisis, diseo, construccin, prueba e implantacin) de sus
proyectos. Si en un proyecto ya hemos realizado algunas fases, es de esperar
que los costes se distribuyan de manera proporcional en las fases siguientes.
1.2.1.4. Mtodo basado exclusivamente en los recursos.
En la estimacin consiste en ver de cuanto personal disponemos para el
proyecto y durante cunto tiempo se dispone de l. Estos sern los recursos a
utilizar. Se basa en la siguiente premisa El trabajo se expande hasta consumir
todos los recursos disponibles (Ley de Parkinson).
1.2.1.5. Mtodo basado exclusivamente en el mercado.
Parte de que lo ms importante es conseguir el contrato. El precio se fija en
funcin de lo que creemos que est dispuesto a pagar el cliente. La estimacin
de costes del proyecto ser el precio a pagar por el cliente menos los
beneficios econmicos que se desea obtener.
1.2.2. Puntos Funcin
Las Mtricas Orientadas a la Funcin se basan en estimar no el nmero de
lneas fuente del programa (LDC) sino su "funcionalidad". Estas mtricas,
propuestas inicialmente por Albretch en 1979 y 1983, intentan buscar un factor
de productividad del software mediante el mtodo denominado de anlisis de
los puntos funcin 2. Los puntos de funcin se obtienen como consecuencia de
haber estudiado distintos proyectos de software y haber aplicado sobre ellos
una mtrica basada en la complejidad y el tamao de la funcin realizada.
La medida del punto funcin se ha aplicado con xito en sistemas no
empotrados y concretamente en sistemas comerciales y puede no ser
relevante en otros sistemas de ingeniera.
Las mtricas orientadas al tamao son bastante polmicas y no estn
aceptadas universalmente como el mejor mtodo para medir la productividad
en el desarrollo del software ya que el nmero de lneas de cdigo escrito no
parece una buena medida. Sus defensores dicen que esta medida es fcil de

aplicar y que puede ser calculada fcilmente en base a la experiencia y que


existe una gran cantidad de informacin basada en las LDC. Sus detractores
dicen que las LDC dependen del lenguaje de programacin, que perjudica a los
programas ms cortos pero mejor diseados y que su utilizacin requiere un
nivel de detalle que puede ser difcil de conseguir.
El anlisis de los puntos funcin se basa en establecer relaciones entre los
componentes bsicos de cada tarea y el esfuerzo requerido en desarrollarlos. El
procedimiento a seguir para calcular los puntos funcin consiste en ir
rellenando los datos de una serie de tabla, basada en la experiencia, en las que
se introducen algunos datos respecto a variables del proyecto como pudieran
ser el nmero de entradas, el nmero de salidas, la cantidad de ficheros que
trata la aplicacin, el tamao de los ficheros en nmero de campos, la cantidad
de consultas que se pretenden efectuar, etc. Cada uno de estos valores se
clasifica en tres categoras respecto a la complejidad que puede ser alta, media
o baja. Igualmente se establece una segunda dimensin en cuanto al tamao
de cada elemento, clasificndolos en pequeo, medio y grande. En ambas
clasificaciones siempre ser ms importante seguir criterios de consistencia
sobre criterios de precisin; es decir deber imperar el mtodo de clasificar en
grandes grupos todos los elementos de la configuracin.
1.2.3. Distribucin Porcentual Del Esfuerzo
Un mtodo empleado por muchas compaas es el basado en la distribucin
porcentual del trabajo que se emplea en organizaciones donde el tipo de
proyectos software que realizan son muy homogneos y se basa en tener
estadsticas muy actualizadas de los tiempos medios en satisfacer cada una de
las fases del proyecto.
En nuestro caso, y segn experiencias anteriores, se sabe que la media de
nuestros ltimos trabajos ha supuesto que la fase de diseo supone un
porcentaje del tiempo total invertido en cada proyecto con independencia del
tamao, y cada una de las fases se distribuye segn el porcentaje expuesto.
Con estos criterios se puede estimar, por medio de la extrapolacin, la
duracin total del proyecto cuando se ha ejecutado alguna de sus partes.
Este mtodo tiene serios inconvenientes, sobre todo cuando los proyectos no
son del mismo tamao, ya que no es normal que se disponga de tablas
adecuadas para cada tipo de proyectos suficientemente actualizados. No
obstante se utiliza bastante como control de validez del mtodo de los Puntos
Funcin de Albretch, sobre todo cuando se comparan los porcentajes de ambos
mtodos, ya que nos puede ayudar a estudiar dnde se producen las mayores
desviaciones por si se trata de errores de clculo o si se han omitido alguna de
las fases.

Para efectuar esta comparacin se tabulan sobre una hoja de clculo los
resultados de cada fase del ciclo de vida y se decide estudiar a detalle aquellos
hitos que tengan una desviacin superior al 15%.
1.2.4. Modelo Cocomo
Es un modelo de costes, descrito por Barry W. Boehm en 1981 de tipo
algortmico que proporciona estimaciones directas tanto de la duracin como
del esfuerzo que est basado en la cantidad de lneas de cdigo fuente escritas
en la totalidad. Se trata de un modelo de estimacin emprico que est basado
en el paradigma del ciclo de vida clsico o modelo en cascada. Boehm se basa
para el desarrollo de su modelo en los diagramas de procesos establecidos en
la mayor parte de las metodologas de desarrollos de sistemas informticos
clsicas. Las fases que cubre el modelo de Boehm son todas las descritas en el
ciclo de vida de productos software con la excepcin del estudio de la
viabilidad y el anlisis de requerimientos, los cuales se estiman como un
apartado cuantitativo del software de desarrollo. Sin embargo si se incluyen
todos los costes incurridos en cada fase.
COCOMO es el modelo emprico para la estimacin de los costes de produccin
de software ms utilizado por los equipos de desarrollo de sistemas
informticos de tamao grande, sin embargo, se deben tener en cuenta los
propios comentarios de Boehm sobre COCOMO y por extensin sobre todos los
modelos: Hoy en da, un modelo de estimacin de costes est bien realizado si
puede estimar los costes de desarrollo de software dentro del 20% de los
costes reales, del 70% del tiempo y en su propio campo (o sea dentro de los
tipos de proyectos en los que ha sido calibrado). Esto no es tan preciso como
quisiramos, pero es lo suficientemente preciso para proporcionar una buena
ayuda en el anlisis econmico de la ingeniera del software y en la toma de
decisiones.
Boehm como: considera que la funcin de distribucin de Rayleight, definida

Donde td es el momento en el que se introduce un esfuerzo mximo, es un


estimador exacto para los requisitos de personal para el ciclo de vida del
desarrollo (desde el diseo arquitectnico hasta las pruebas del sistema
siempre que usemos la porcin de curva entre 0,3t y 1,7 t ).

El estimador de Rayleight

Antes de abordar el modelo propiamente dicho, es preciso enumerar una serie


de definiciones y consideraciones en las que se basa Boehm para el desarrollo
del modelo, como son:
El clculo del coste primario est basado en el nmero de instrucciones
fuentes desarrolladas en el proyecto sin incluir las lneas de comentarios,
pruebas, documentacin, etc., a no ser que se escriban con un fin expreso y
cuidado.
El periodo de desarrollo cubierto por el modelo comienza al iniciarse la fase
de diseo y termina al finalizar la fase de integracin y prueba. El coste y
calendario de otras fases se estiman por separado.
El modelo cubre nicamente las actividades indicadas dentro del equipo de
desarrollo de actividades o procesos del ciclo de vida. Por ello, incluye el
esfuerzo de organizacin y documentacin, pero excluye algunos esfuerzos
tales como la planificacin de la instalacin, esfuerzo de conversin, etc.
Las soluciones se expresan en criterios de la forma hombres-mes
refirindose a 152 horas de tiempo de trabajo al mes desarrollado por las
personas del equipo de desarrollo. Este factor se ha calculado teniendo en
cuenta la experiencia en los distintos proyectos desarrollados y considerando el
tiempo de vacaciones.
El modelo considera que el proyecto es bien dirigido tanto por el
desarrollador del mismo como por el cliente, existiendo por ello muy pocos
tiempos perdidos en el anlisis de requerimientos del producto.
Considera que la especificacin de requerimientos no tiene cambios
sustanciales despus de la fase de planificacin y requerimientos del producto.
El modelo avanzado considera que la influencia de los factores conductores
de coste del software dependen de cada fase. Los otros modelos slo hacen
diferencias entre la etapa de desarrollo y la etapa de mantenimiento.
El coste de cada fase incluye todos los costes incurridos durante la fase. Los
costes de actualizacin del plan de integracin y prueba y la aceptacin
completa de los planes de prueba estn incluidos en la fase de diseo
detallado.
Para que se cumplan los criterios de estimacin del ciclo de vida desarrollo de
software es necesario resaltar las siguientes caractersticas:
Se debe de prestar especial cuidado a la definicin y validacin de la
especificacin de los requerimientos software por un grupo de personas
relativamente pequeo con anterioridad a la entrada en la fase de diseo.

Posteriormente se debe de someter la definicin y validacin del diseo del


sistema software a un grupo de personas algo ms grande como actividad
anterior a la entrada en la fase de diseo detallado y de la codificacin.
El diseo detallado, la codificacin y las pruebas de unidades sern
desarrollados por un grupo grande de programadores trabajando en paralelo, y
siguiendo una lnea base slida que suponga un desarrollo incremental de la
planificacin.
La integracin y prueba de cada incremento en el sistema est basada en
una gran cantidad de planificacin de pruebas tempranas y en la eliminacin
de casi todas las unidades defectuosas por medio de cuidadosos y completos
recorridos de las unidades desarrolladas.
Una parte importante del esfuerzo de documentacin (por ejemplo los
borradores de los manuales de usuario) se desarrollar en fases tempranas
para proporcionar a los usuarios (y desarrolladores) informacin acerca de la
naturaleza operacional del producto.
Para ajustar mejor sus estimaciones Boehm cre tres escenarios de estimacin
clasificando su modelo de forma jerrquica y en base a la complejidad y
cantidad de informacin utilizada en la estimacin; a los que denomin
modelos COCOMO que son:
Modelo bsico
Modelo intermedio
Modelo avanzado
1.2.4.1. El modelo bsico
Es un modelo esttico, evaluado de forma nica y que calcula el esfuerzo y el
coste de desarrollo del software en funcin del tamao del programa expresado
en lneas de cdigo estimadas (DSI o LDC). Tamao
1.2.4.2. El modelo intermedio
Calcula el esfuerzo de desarrollo en funcin del programa y un conjunto de
guas de coste que incluyen una evaluacin subjetiva tanto del producto, como
del hardware, del personal y de los atributos del proyecto.
1.2.4.3. El modelo avanzado
Incorpora todas las caractersticas de la versin intermedia con una evaluacin
del impacto de las guas de coste en cada fase (anlisis, diseo, etc.) del
proceso de ingeniera del software.

1.2.5. Mtodo De Estimacin De Putman


El modelo de estimacin de Putman es un modelo multivariable dinmico que
asume una distribucin especfica del esfuerzo a lo largo del ciclo de vida de un
proyecto de desarrollo software. Las curvas mostradas en la figura toman la
forma clsica descrita por Lord Rayleight en el ao 1978 y los datos empricos
fueron recogidos por Norden.
La funcin es de la forma:

Donde C k es una constante de estado de la tecnologa y refleja las


restricciones directas que frenan el progreso del programador, K es el
esfuerzo necesario medido en personas-hombre durante todo el ciclo de vida, K
es el esfuerzo total del desarrollo en personas-ao y td es el tiempo de
desarrollo en aos y L el nmero de miles de lneas fuente del proyecto.
Algunos valores tpicos de C k pueden ser C k =2000 en entornos de desarrollo
tpicos o C k = 8000 en un buen entorno de desarrollo con buena metodologa
y herramientas.
El valor del esfuerzo se puede despejar de la ecuacin anterior resultando, la
ecuacin de la forma:

1.2.6. Herramientas Automticas De Estimacin

Una vez estudiados los distintos modelos empricos de estimacin de costos


vamos a sealar como est el estado del arte en la implementacin en
programas de usuario:
Existe un producto, denominado comercialmente ESTIMACS, que utiliza un
modelo basado en los puntos funcin de Albretch mejorado que permiten al
planificador ajustarse a distintos factores de personal a la vez que permite
llevar varios proyectos en paralelo .
El programa COSTAR es una aplicacin directa del modelo COCOMO descrito
por el Dr. Barry Boehm en su libro Software Engineering Economics en sus tres
modos, y es, seguramente el ms empleado en la industria, permite obtener

informacin estimada del esfuerzo del desarrollo del sistema, de los costes y
del personal necesario.
De este programa existen numerosas versiones, tanto para UNIX, MSDOS y
Windows; que la compaa Sunsets actualiza constantemente.

Aspecto del programa COSTAR para MS-DOS.

Algunos avances sobre el modelo se pueden ver aplicados en el programa


COSTAR II, que es una ampliacin del programa anterior que soporta una
mayor cantidad de modelos de estimacin, incluido el modelo COCOMO II, Para
facilitar la planificacin del proyecto, en esta versin del programa, Costar II
facialita el supuesto de anlisis de la forma qu pasara si? Adems de
comparar distintos planes de proyectos. La riqueza de informes y grficos
hacen que Costar II sea, actualmente, la estrella de los programas de
estimacin de esfuerzos.
La versin de evaluacin permite estimar proyectos de hasta 5000 lneas de
cdigo fuente y permite efectuar supuestos sobre la duracin partiendo de
personal dedicado al proyecto y su inversa, es decir, qu personal se debe de
dedicar en cada una de las fases de desarrollo para satisfacer un calendario
previsto segn unas especificaciones dadas.
En la versin evaluada (6.0) se ofrecen numerosas intercambiar la informacin
con otros programas de Windows, obtener informacin grfica para insertar o
adjuntar dentro de ofimticas como puede ser Microsoft Word.

Aspecto de Costar II
Otro producto interesante es el SLIM, basado en el modelo de Putnam que
permite obtener unos estudios de programacin lineal, la simulacin
estadstica y los diagramas PERT en el mismo paquete.
Muchas instituciones y casa comerciales tienen herramientas en la red, alguna
de ellas como puede ser el caso de la NASA, que presenta el aspecto de la
siguiente figura.

Pagina COCOMO de la NASA


Todos estos productos, hoy da disponible en computadoras personales,
permiten calibrar el entorno local de desarrollo y crear un modelo de
informacin del software desarrollado mediante sus caractersticas bsicas, los
atributos de personal y las consideraciones del entorno.
Si en su organizacin no se dispone de software de estimacin de proyectos, se
pueden buscar sitios de la red que disponga de software que est ms o
menos calibrado a nuestro entorno de desarrollo y a los usos y costumbres del
grupo de trabajo concertadas en forma de metodologas.
1.2.7. Discusin Final
La estimacin es una tarea difcil y errtica en la Ingeniera del Software que se
fundamenta en medir experiencias pasadas. De todos los modelos de
estimacin resulta ser COCOMO el ms universalmente aceptado si bien hay
que hacer hincapi en que cualquier mtodo de estimacin se debe de ajustar
a la organizacin. Por ello, podemos decir que: una estimacin de costes es
slo tan buena como nuestra capacidad de extrapolar al futuro las experiencias
pasadas.
Una norma de buena costumbre que se suele utilizar en muchas ocasiones es
la de comparar los resultados de ambas estimaciones en busca de
desviaciones superiores al 15% para poder analizar las diferencias entre los
componentes y as decidir si la planificacin ha sido correcta.
Debido a que la mayor parte de las estimaciones de costes estn desarrolladas
en funcin del nmero estimado de instrucciones del producto final, la
estimacin de costes del producto no ser superior a nuestra capacidad de
estimar el nmero de instrucciones finales existentes en l.
El modelo de Barry W. Boehm proporciona una base firme para desarrollar una
estimacin de costes en un sistema software, debido a su adaptabilidad a los
distintos sistemas, a su fcil aplicacin y a la consideracin por parte del
modelo de la influencia de los factores ms importantes del desarrollo de
software.
Aunque existen otros modelos de estimacin de costes, como el modelo SLIM
de Putnam, el modelo SDC (System Development Corporation) de Nelson, etc.,
se ha desarrollado el estudio ms profundo del modelo COCOMO debido a que
es uno de los ms completos de los existentes, adems de uno de los ms
utilizados por las organizaciones para la estimacin de costes en la produccin
de grandes sistemas informticos.
1.3. Estimacin de costos de Proyecto

El costo de un proyecto es de inters continuo y vital para los coparticipes. Con


el precio de produccin equivocado, incluso el producto ms fantstico puede
ser un desastre. La estimacin de costo ms sencilla es la que proporciona un
costo fijo desde el principio, sin permitir desviaciones en ninguna circunstancia.
Aunque las organizaciones muy competentes tienen suficientes aptitudes para
cambiar las variables restantes (capacidad, programa de tiempos y calidad)
para cumplir con un costo predeterminado, la rigidez absoluta en el costo no
siempre se adopta. Suponga, por ejemplo, que un proyecto que desarrolla un
producto que se vende muy bien se queda sin fondos cuando lleva el 90%. En
lugar de abandonar todo el proyecto, lo comn es que la organizacin haga
todo lo posible para encontrar fondos para ese ltimo 10%. Aun cuando el
costo del proyecto seas rgido, es necesario estimar el costo de un conjunto
dado de requisitos y/o del diseo para asegurar que cumple con el costo
acordado y, si no lo hace, cambiarlos y despus hacer la estimacin de nuevo.

El proceso de estimar los costos (esto es, para capacidades, control de calidad
y programacin fijas) con frecuencia comienza desde la concepcin del
proyecto y continua aun despus de iniciada la codificacin. Cuando se inicia
un proyecto, tal vez el equipo tenga slo una idea vaga de su costo. Si la
estimacin del costo se puede posponer hasta que el proyecto tome forma, sin
duda deben esperar, pero siempre existe la necesidad de estimar por lo menos
un intervalo burdo a partir de un resumen de requisitos. Cuando ms se sepa
de los requisitos para el producto y mas diseo se realice, ms preciso ser el
costo.

El error de estimacin tan grande que indica en la siguiente figura se debe a un


estudio reportado por Bohem. Por ejemplo, para una aplicacin que con el
tiempo costara $100 000, las estimaciones hechas despus de desarrollar el
concepto de la aplicacin pueden ser tan bajas como $25 000 y tan altas como
$400 000. Para perfeccionar la estimacin del costo de un proyecto se usan
varias tcnicas lo antes posible, lo que significa reducir la altura de las lneas
verticales de la figura.

Solo hasta el final del desarrollo se puede tener confianza completa en las
estimaciones. (Sin embargo, las estimaciones son menos tiles en ese
momento, ya que la mayor parte del dinero est gastado!) Como la precisin

es prcticamente imposible, un intervalo es una buena manera de proyectar


los costos y esto se aplica al ejemplo anterior.

Sorprende a muchas personas que podamos siquiera pensar en los costos sin
un diseo y los requisitos detallados, pero sta es una prctica comn en otros
campos. Se puede obtener una estimacin burda del costo de construir una
casa, por ejemplo, sin un diseo o los requisitos detallados. Se pueden usar
reglas cortas como las casas en esta rea cuestan alrededor de $100 por pie
cuadrado de construccin, y as una casa de 100 pies cuadrados costara
alrededor de $100 000.

Una buena manera de enfocar la estimacin de costos del proyecto durante las
primeras etapas es desarrollar estimaciones de varias maneras independientes
y despus combinar resultados. Incluso se pueden ponderar las estimaciones
obtenidas de acuerdo con el nivel de confianza personal en cada una de ellas.

Una mquina de coser o un torno es una herramienta compleja que no sirve sin
un usuario capacitado. De igual manera la primera vez se usan las medidas de
aproximacin de costos es poco probable que los resultados sean confiables. El
uso preciso de estas herramientas se aprende con el tiempo, la
retroalimentacin y la comprobacin.

1.3.1. Estimacin de lneas de cdigo sin el proceso de puntos de funcin


Esta seccin presenta la estimacin de lneas de cdigo en la etapa inicial,
mucho antes de iniciar el trabajo de diseo. Una vez realizado ste, los
mtodos se basan en las partes del diseo y se vuelven mucho ms precisos.

Varios mtodos de estimacin, como modelo de COCOMO, dependen del


nmero de lneas de cdigo (LoC).COCOMO son las siglas abreviadas de
modelo de costos constructivo en ingles (CONSTRUCTIVE COST MODELO) de
Boehm. En las primeras etapas de un proyecto es posible que COCOMO no
parezca muy til debido a que falta mucho para llegar a la codificacin. Sin
embargo, cuando un producto se puede comparar con otros, es factible estimar
las lneas.

Las organizaciones que trabajan por encima del nivel 1 en los modelos de
madurez de capacidades deben poder registrar las personas-hora y la duracin
de las partes de los trabajos. En ausencia de este tipo de datos, se tendra que
comprar, por ejemplo, nuestro videojuego Encuentro con otros juegos. La
obtencin directa de los datos de otras compaas es entre difcil e imposible.
Las publicaciones comerciales y de negocios, y los anuncios generales de la
industria, en ocasiones proporcionan datos parciales. Por ejemplo, quiz se
tenga conocimiento, por los informes pblicos, que BufEye Inc. ha trabajado
en sus nuevos juegos durante 3 aos: tal vez incluso mencione un numero de
programadores, pero debe sospecharse de estos datos, ya que algunas
compaas consideran sus conocimientos sobre desarrollo como un activo
corporativo y suelen exagerar estos nmeros o publicar nmeros menores,
segn sea el caso.

Cuando se dispone de un historial, tal vez sea necesario comparar el proyecto


con proyectos relacionados (para el videojuego pueden ser simulaciones).
Digamos que se tiene poca experiencia en la programacin de juegos y alguna
en la programacin de simulaciones y Java. La estimacin de lneas de cdigo
tal vez incluya algo como lo siguiente:

Una vez escrib una simulacin no grafica de una cola sencilla en C++, que
requiri entre 4 y 8 pginas de cdigo, con alrededor de 30 a 50 lneas que no
eran comentarios; esto es un total de 120 a 400 lneas. Suponga que Java
requiere el mismo nmero de lneas. La primera versin comercial de
Encuentro tiene de 4 a 15 colas de este tipo y de 30 a 90 componentes
adicionales de tamao comparable para hacerlo interesante, y esto da entre un
mnimo de [(120 lneas) x (34 componentes)] y mximo de [(400 lneas) x (105
componentes)] para nuestro intervalo, o entre 5 000 y 42 000 lneas de cdigo.
El uso de grficos multiplica el esfuerzo por 1.5 a 4 segn la complejidad, lo
que da un intervalo de 1.5 x 5 000 a 4 x 42 000 = 7.5 a 170 000 lneas de
cdigo.

1.4. Mtricas
El proceso de planificacin del desarrollo de cualquier sistema debe hacerse
partiendo de una estimacin del trabajo a realizar. Slo a partir de ello es
factible conocer los recursos necesarios y el tiempo necesario para su
realizacin.

Una mtrica es una medida efectuada sobre algn aspecto del sistema en
desarrollo o del proceso empleado que permite, previa comparacin con unos
valores (medidas) de referencia, obtener conclusiones sobre el aspecto medido
con el fin de adoptar las decisiones necesarias. Con esta definicin, la
definicin y aplicacin de una mtrica no es un objetivo en s mismo sino un
medio para controlar el desarrollo de un sistema de software.
1.4.1. Mtricas sobre el producto
Las mtricas sobre el producto estn orientadas a estimar las caractersticas
del mismo antes de su desarrollo. Estas estimaciones se basan en el
conocimiento que los desarrolladores adquieren a partir de datos obtenidos de
proyectos anteriores.
1.4.1.1. Tamao estimado del cdigo.
La forma ms obvia y la que se ha utilizado histricamente antes para estimar
el tamao es contar el nmero de lneas de cdigo. Con ciertas normas para
determinar qu es lo que se cuenta (lneas de comentario, cdigo incluido, etc.)
y siempre referido a un lenguaje concreto, lo que los valores nos dan es un
valor para, comparando con otros casos, poder estimar el esfuerzo necesario
en futuros desarrollos.
Los resultados obtenidos (estimaciones y valores reales) alimentan la base de
datos histricos que es el fundamento para posteriores estimaciones.
Boehm desarroll una tcnica empleando el mtodo Delphi para mejorar las
estimaciones con mltiples opiniones de expertos. La idea de emplear el
mtodo Delphi es asegurar en dos o tres pasos de convergencia que las
estimaciones son aceptadas por los expertos.
Ha sido muy criticada la tendencia en estimar el esfuerzo en base a las lneas
de cdigo. Una de las crticas se centra en que la complejidad del desarrollo no
est directamente ligada al tamao cuando nos movemos hacia el dominio de
los sistemas concurrentes, distribuidos o de tiempo real. En ellos, las medidas
deben referirse a estimaciones del mismo tipo de productos.
Otro problema surgido recientemente con la proliferacin de generadores de
cdigo es que no importa demasiado el nmero de lneas de cdigo generadas
(excepto por problemas derivados del tamao de la memoria para sistemas
embebidos) sino el nmero de lneas de especificacin que las han generado,
porque la complejidad del problema de mantenimiento depende de ello.
1.4.1.2. Complejidad estimada.

Con el fin de superar el problema de las estimaciones del tamao de cdigo, se


ha prestado recientemente atencin a medidas de complejidad no basadas en
estimaciones de nmero de lneas.
Albrecht defini en 1979 un mtodo conocido como de puntos de funcin que
est teniendo cada vez ms aceptacin. Su mtodo se basa en el empleo de
factores normalizados para juzgar la importancia relativa de varios requisitos
funcionales.
Parte de cinco funciones bsicas que suelen aparecer en muchos sistemas:
1) Entradas. Pantallas o formatos empleados para introducir datos a un
programa.
2) Salidas. Pantallas o informes empleados para utilizarlos con otros programas
o para lectura directa.
3) Consultas. Mecanismos para pedir ayuda o dar rdenes de ejecucin.
4) Ficheros de datos. Conjuntos lgicos de informacin empleados por una
aplicacin (ya sean tablas en memoria como ficheros de disco) junto con los
procedimientos de acceso a los mismos.
5) Interfaces. Ficheros compartidos con otras aplicaciones. La idea bsica del
mtodo consiste en definir unas estimaciones de complejidad para cada una de
estas funciones (en forma de pesos relativos) y estimar, dadas las
especificaciones del sistema, cuntos elementos de cada tipo van a ser
necesarios.
El problema con los puntos de funcin es que no son realmente medidas sino
valoraciones subjetivas y no tienen en cuenta diferencias en la implementacin
(al fin y al cabo, el esfuerzo del desarrollo depende tambin del lenguaje
utilizado o del dominio de aplicacin y eso no se tiene en cuenta). De nuevo, la
comparacin con sistemas similares permite calibrar las decisiones tomadas.
1.4.1.3. Robustez.
Por robustez de un programa se entiende la ausencia de fallos en su ejecucin
con diferentes datos de entrada durante intervalos de tiempo predeterminados.
La robustez de un programa est ligada a la aparicin de problemas durante su
ejecucin. Generalmente, el nmero de fallos encontrados durante la fase de
prueba y, posteriormente, durante el mantenimiento del sistema constituye
una medida de la calidad del producto de software e, indirectamente, de la
calidad del proceso de desarrollo.

La importancia de conocer el nmero de fallos encontrados en un intervalo de


tiempo no reside nicamente en obtener un valor global de la calidad del
producto sino en los beneficios derivados de su anlisis.
Las medidas estadsticas de fiabilidad (tiempo medio entre fallos encontrados
durante la ejecucin, reduccin del nmero de recopilaciones necesarias, etc.)
sirven para alimentar el proceso de desarrollo.
1.4.2. Mtricas sobre el proceso
Las mtricas mencionadas en la seccin anterior estaban orientadas a conocer
la complejidad del producto (con algn valor indirecto como el tamao) para
poder estimar los recursos necesarios para su realizacin. Hemos mencionado
tambin que, segn se vayan acumulando datos y se analicen
estadsticamente, las estimaciones sern cada vez mejores. Esto nos servir
para planificar mejor futuros desarrollos.
Existen otros tipos de datos que se pueden tomar durante el desarrollo de un
producto de software y que no estn ligados al producto sino a los procesos
implicados. El anlisis de cmo estos procesos se realizan a partir de medidas
tomadas en el desarrollo es la base para su ulterior mejora.
Algunos de los elementos a medir son:
A) Distribucin del esfuerzo en cada una de las fases con objeto de poder
estimar los recursos necesarios. Obsrvese que esta medida es
complementaria al las de tamao mencionado anteriormente; aquella nos
permita conocer los recursos globales necesarios; de lo que se trata aqu es de
obtener medidas reales y extrapolarlas a futuros proyectos.
B) Productividad medida en nmero de lneas de cdigo documentadas que es
capaz de producir una persona en una unidad de tiempo. A ttulo orientativo,
podemos decir que los valores tpicos de productividad por persona
(empleando tecnologas de desarrollo convencional) estn entre 30 y 50 lneas
de cdigo por da de trabajo.
1.5. Estimacin de costos (concepto persona)
En el principio el costo del Software dispona un pequeo porcentaje del costo
total de los sistemas basados en Computadoras. Hoy en da el Software es el
elemento ms costoso de la mayora de los sistemas informticos.

Un gran error en la estimacin del costo puede ser lo que marque la diferencia
entre beneficios y perdidas, la estimacin del costo y del esfuerzo del software
nunca ser una ciencia exacta, son demasiadas las variables: humanas,

tcnicas, de entorno, polticas, que pueden afectar el costo final del software y
el esfuerzo aplicado para desarrollarlo.

Muchas son las tcnicas o mtodos para realizar estimaciones.

Roger Pressman en su libro de Ingeniera de Software plantea que para lograr


estimaciones del tamao del proyecto confiables hay varias opciones:

Retrasar la estimacin para despus.

Basar la estimacin en proyectos simulares ya terminados.

Emplear tcnicas de descomposicin para generar estimaciones de costo y


esfuerzo.

Utilizar uno o ms modelos empricos en la estimacin de costo y esfuerzo.

De ellas las ms razonable es la de utilizar las tcnicas y modelos empricos,


siendo la ms recomendada pues es donde clasifican los mtodos para estimar
el tamao del software planteados por Bhoem y Watts que son los ms
utilizados.

Por otra parte el esfuerzo es un indicador de la cantidad de trabajo necesario


para realizar un proyecto. En productos de software se debe considerar
equivalente estimar el esfuerzo y el coste ya que existe una relacin directa
entre ambos.

Вам также может понравиться