Академический Документы
Профессиональный Документы
Культура Документы
http://ingenieroduqueescobar.blogspot.com/2010/06/estimacion-de-costos-deproyectos-de_19.html
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
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.
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
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.
UFC =
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 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:
FACTOR
DESCRIPCION
Experiencia en el dominio de la aplicacin
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.
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.
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.
costos de los proyectos. Algunos ejemplos de los cambios que afectan las
estimaciones de acuerdo con la experiencia son:
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.
Esfuerzo = A x Tamao B x M
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.
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
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
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
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
El estimador de Rayleight
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 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.
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.
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
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.
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.
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.
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.