Sie sind auf Seite 1von 9

Mtodos de Estimacin de Costos de Software para Grandes Proyectos

El software ha alcanzado una mala reputacin pues ha sido considerado como una tecnologa
perturbadora. Los grandes proyectos de software han tendido a tener una muy alta frecuencia de exceso
de calendarizacin, costos, problemas de calidad e indiscutibles cancelaciones. Mientras esta mala
reputacin a menudo es merecida, es importante notar que algunos grandes proyectos de software
finalizan a tiempo y con el presupuesto estimado, adems funcionan satisfactoriamente cuando stos
son desplegados.
Los grandes proyectos exitosos difieren en muchos sentidos de los fracasos y desastres (Jones 2004).
Una diferencia importante es, cmo los proyectos exitosos concluyen a tiempo, dentro de los costos,
recursos y estimacin de calidad prevista en un primer trmino. De un anlisis de resultados de las
herramientas de estimacin usadas, publicado en Estimacin de Costos de Software (Jones 1998), el
uso de instrumentos de estimacin automatizados conduce a estimaciones ms exactas. A la inversa,
los mtodos informales o manuales de llegar en estimaciones iniciales son generalmente inexactos y a
menudo excesivamente optimistas.
Una comparacin de 50 estimaciones manuales con 50 estimaciones automatizadas para proyectos en
el rango de los 5000 puntos de funcin, mostr resultados interesantes (Jones 1998). Las estimaciones
manuales fueron creadas por administradores de proyectos quienes usaban calculadoras y hojas de
clculo. Las estimaciones automatizadas tambin fueron creadas por administradores de proyectos o
por sus asistentes de estimacin, usando varias herramientas de estimacin comercialmente diferentes.
Las comparaciones fueron hechas entre las estimaciones originales presentadas a clientes y ejecutivos
corporativos, y los resultados acumulados al final cuando las aplicaciones fueron puestas en prctica.
Solamente cuatro de las estimaciones manuales estuvieron dentro del 10% de los resultados reales.
Aproximadamente 17 estimaciones eran optimistas entre el 10% y el 30%. Una consternacin, 29
proyectos fueron optimistas por ms del 30%. Es decir, las estimaciones manuales rindieron costos
bajos y calendarios cortos que lo ocurrido verdaderamente, a veces por cantidades insignificantes. (Por
supuesto varias estimaciones revisadas fueron creadas a lo largo del camino. Pero la comparacin fue
entre la estimacin inicial y los resultados finales).
Por contraste 22 de las estimaciones generadas por herramientas de estimacin comercial estuvieron
dentro del 10% real de los resultados. Aproximadamente 24 fueron conservadoras entre 10% y 25%.
Tres fueron conservadoras por ms que 25%. nicamente una automatizada fue optimista, por cerca del
15%.
Uno de los problemas con los estudios desarrollados tal como es el hecho de muchos proyectos
grandes con estimaciones imprecisas fueron cancelados sin haber culminado. De ese modo, para que
los proyectos estuviesen incluidos en todo, ellos tendran que haber finalizado. Este criterio elimin
muchos proyectos que usaron tanto estimacin manual como automatizada.
De modo interesante, las estimaciones manuales y las automatizadas eran equitativamente cercanas en
trminos de prediccin del esfuerzo de programacin o codificacin. Pero las estimaciones fueron muy
optimistas cuando predecan el crecimiento de los requerimientos, esfuerzo del diseo, esfuerzo de
documentacin, esfuerzo de administracin, esfuerzo de evaluacin y esfuerzo de revisin y reparacin.
La conclusin de la comparacin fue que tanto las estimaciones manuales como las automatizadas eran
equivalentes para la programacin real, pero las estimaciones automatizadas eran mejores para
predecir actividades de no codificacin.

Este es un asunto importante para la estimacin de grandes aplicaciones de software. Para proyectos
de software por debajo de aproximadamente 1000 puntos de funcin en tamao (equivalente a 125,000
declaraciones C), la programacin es el mayor costo de manejo, la exactitud de estimacin para
codificacin es un elemento clave. Pero para proyectos sobre los 10,000 puntos de funcin en tamao
(equivalente a 1,250,000 declaraciones C), tanto la eliminacin de defectos como la produccin de
documentos son ms costosas que el cdigo por s mismo. Por lo tanto la exactitud en la estimacin de
esos tpicos es un factor clave.
Las estimaciones de tiempo y costo deberan ser exactas, naturalmente. Pero si ellas difieren de los
resultados reales, es ms seguro ser ligeramente conservador que ser optimista. Una de las principales
quejas sobre los proyectos de software se refiere a su tendencia alarmante de exceder gastos y
calendarios planificados. Desafortunadamente, tanto clientes como ejecutivos superiores tienden a
ejercer presiones considerables en los administradores de proyectos y en el personal encargado de
realizar las estimaciones. Por consiguiente un colorario oculto de estimacin acertada es aquel en
donde stas deben ser defendibles. La mejor defensa es una buena coleccin de datos histricos de
proyectos similares.
Debido a que el crecimiento de la estimacin de costos es una actividad compleja, existe un crecimiento
industrial de compaas dedicadas a ofrecer diferentes marcas comerciales de herramientas de
estimacin de costos en el mercado. A partir del 2005, algunas de esas herramientas de estimacin son:
COCOMO II, CoStar, CostModeler, CostXpert, KnowledgePlan, PRICE S, SEER, SLIM y SoftCost.
Algunas de las herramientas de estimacin de costos ms antiguas, no estn activamente en el
mercado pero todava son utilizadas, tales como: CheckPoint, COCOMO, ESTIMACS, REVIC y
SPQR/20, ya que su uso no es apoyado por los vendedores, por lo que su utilizacin est en declive.
Mientras estos instrumentos de estimacin fueron desarrollados por empresas diferentes y no son
idnticos, ellos realmente tienden a proporcionar un ncleo de funciones comunes. Los rasgos
principales de instrumentos de estimacin de software comerciales en incluyen estos atributos:
Lgica de dimensionamiento para especificaciones, cdigo fuente y casos de evaluacin
Nivel de fase, nivel de actividad, y estimacin de nivel de tarea
Ajustes para perodos de trabajo especficos, vacaciones y horas extraordinarias
Ajustes para salarios locales e ndices de carga
Ajustes para varios proyectos de software como militares, sistemas, comerciales, etc.
Apoyo para mtricas de puntos de funcin, mtricas de lneas de cdigos o ambas
Apoyo para backfiring, es decir, convertir lneas de cdigos a puntos de funcin
Apoyo tanto para nuevos proyectos como a proyectos de mejora y mantenimiento
Algunas herramientas de estimacin tambin incluyen funciones ms avanzadas como:
Estimacin de fiabilidad y calidad
Anlisis de valor y riesgo
Retorno de Inversin
Posibilidad de compartir datos con herramientas de administracin de proyectos
Medios de medicin para reunir datos histricos
Costo y tiempo para completar estimaciones que combinan datos histricos con datos proyectados
Apoyo para evaluaciones de procesos de software
Anlisis estadstico de mltiples proyectos y anlisis de cartera
Conversin monetaria para acordar proyectos en el exterior
Las estimaciones para grandes proyectos de software necesitan incluir muchas ms actividades que
solamente codificar o programar. La Tabla 1 muestra un modelo de actividad tpica para seis clases
diferentes de proyectos: aplicaciones web-based, sistemas de informacin gerencial (MIS), software
outsourced, software comercial, software de sistemas y proyectos de software militares. En este
contexto los proyectos web son aplicaciones diseadas para apoyar sitios web corporativos. Las letras
(MIS) son las siglas en ingls para Mangement Information Systems. El Outsource en software es

similar al MIS, pero realizado por una contratista externa. El software de sistemas es aquel que
controla los dispositivos fsicos como sistemas de telecomunicaciones o computadoras. El software
militar constituye todos los proyectos los cuales son obligados para seguir varios estndares de ndole
militar. El software comercial se refiere a paquetes ordinarios como procesadores de palabras, hojas de
clculo y otros por el estilo.

Tabla 1: Actividades tpicas de desarrollo de software de seis tipos de aplicaciones


(Los datos indican que el porcentaje de esfuerzo de trabajo por actividad)
Actividades realizadas
Web
MIS Outsource Comercial Sistema Militar
01 Requerimientos
5.00% 7.50%
9.00%
4.00%
4.00% 7.00%
02 Prototipo
10.00% 2.00%
2.50%
1.00%
2.00% 2.00%
03 Arquitectura
0.50%
1.00%
2.00%
1.50% 1.00%
04 Planes del proyecto
1.00%
1.50%
1.00%
2.00% 1.00%
05 Diseo inicial
8.00%
7.00%
6.00%
7.00% 6.00%
06 Diseo en detalle
7.00%
8.00%
5.00%
6.00% 7.00%
07 Revisiones de diseo
0.50%
1.50%
2.50% 1.00%
08 Codficacin
30.00% 20.00% 16.00%
23.00% 20.00% 16.00%
09 Adquisicin Reutilizacin
5.00%
2.00%
2.00%
2.00% 2.00%
10 Compras de paquetes
1.00%
1.00%
1.00% 1.00%
11 Inspecciones de cdigo
1.50%
1.50% 1.00%
12 Validacin y verificacin
1.00%
13 Administracin de la
3.00%
3.00%
1.00%
1.00% 1.50%
configuracin
14 Integracin formal
2.00%
2.00%
1.50%
2.00% 1.50%
15 Documentacin del usuario 10.00% 7.00%
9.00%
12.00% 10.00% 10.00%
16 Prueba de unidad
30.00% 4.00%
3.50%
2.50%
5.00% 3.00%
17 Pruebas de funcin
6.00%
5.00%
6.00%
5.00% 5.00%
18 Pruebas de integracin
5.00%
5.00%
4.00%
5.00% 5.00%
19 Pruebas de sistemas
7.00%
5.00%
7.00%
5.00% 6.00%
20 Pruebas de campo
6.00%
1.50% 3.00%
21 Pruebas de aceptacin
5.00%
3.00%
1.00% 3.00%
22 Pruebas independientes
1.00%
23 Aseguramiento de la
1.00%
2.00%
2.00% 1.00%
calidad
24 Capacitacin/Instalacin
2.00%
3.00%
1.00% 1.00%
25 Administracin de proyecto 10.00% 12.00% 12.00%
11.00% 12.00% 13.00%
Total
100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
Actividades
7
16
20
21
22
25
La Tabla 1 es simplemente ilustrativa, y los nmeros reales de actividades realizadas y los porcentajes
de esfuerzo para cada actividad pueden variar. Para estimar proyectos reales, el instrumento de
estimacin presentara el conjunto ms probable de actividades para ser realizadas. Entonces el Project
Manager o el especialista en estimacin de costos ajustara el conjunto de actividades que
corresponden a la realidad del proyecto. Algunos instrumentos de estimacin permiten a los usuarios
aadir actividades adicionales que no son parte del conjunto de actividades originales.

Generadores de Costos para Grandes Sistemas de Software: Trabajo Administrativo y


Eliminacin de de Defectos
En conjunto, los grandes proyectos de software dedican ms esfuerzo a la produccin de documentos y
a la eliminacin de defectos que la produccin de un cdigo fuente. De este modo, la estimacin exacta
para grandes proyectos de software debe incluir el esfuerzo para producir documentos, y el esfuerzo
para encontrar y reparar los defectos, entre otras cosas.
La invencin de mtricas de puntos de funcin (Albrecht 1984) ha hecho de la lgica de evaluacin
completa para documentos un caracterstica estndar de muchas herramientas de estimacin. Una de
las razones para el desarrollo de las mtricas de puntos de funcin fue proveer un mtodo de evaluacin
para documentos entregables. Para informacin adicional sobre puntos de funcin, pueden entrar al
Sitio Web www.ifpug.org.
Tabla 2: Ilustra ejemplos de tamao de documentacin seleccionada a partir de sistemas, proyectos
web, MIS, Outsource, Comercial, Sistemas y dominios de software militar.
Tabla 2: Pginas de documento por punto de funcin para seis tipos de aplicaciones
(Datos expresados en trminos de pginas por cada punto de funcin)
Web MIS Outsource Comercial Sistema Militar Promedio
Requerimientos
0.25 0.5
0.55
0.3
0.45
0.85
0.48
Especificaciones
de
0.1 0.55
0.55
0.6
0.8
1.75
0.73
funcin
Especificaciones
de
0.5
0.5
0.55
0.85
1.65
0.81
lgica
Planes de prueba
0.1 0.1
0.15
0.25
0.25
0.55
0.23
Guas de usuario
0.05 0.15
0.2
0.85
0.3
0.5
0.34
Referencia
0.2
0.25
0.9
0.34
0.85
0.51
Informes
0.15 0.5
0.6
0.4
0.65
2
0.72
Total
0.65 2.5
2.8
3.85
3.64
8.15
3.6
Al menos una herramienta comercial de estimacin de software puede incluso predecir el nmero de
palabras en ingls en el conjunto de documentos y tambin los nmeros de diagramas que
probablemente estn presentes. La estimacin de documento puede tambin cambiar basada o
empapelar el tamao tal como el papel A4 europeo. De hecho, ahora es posible estimar los tamaos
basados en texto e incluso estimar los costos de traduccin de un idioma a otro para los proyectos que
son desplegados internacionalmente.
Potenciales de Defecto de Software y Niveles de Eficacia de Eliminacin de Defecto
Un aspecto clave de la estimacin de costo de software es predecir el tiempo y el esfuerzo que ser
necesario para revisiones de diseo, inspecciones de cdigo, y todas las formas de pruebas. Para
estimar la eliminacin los costos de eliminacin de defecto y calendarios, es necesario conocer cuntos
defectos son susceptibles de ser encontrados.
La secuencia tpica es estimar los volmenes de defecto por un proyecto y entonces estimar la serie de
revisiones, inspecciones y pruebas que utilice el proyecto. La eficiencia en la eliminacin de defecto de
cada paso tambin sern estimada. Los costos y esfuerzo para la preparacin, ejecucin y reparacin
de defectos asociados con la actividad de eliminacin tambin sern estimadas.
Tabla 3: Ilustra la distribucin global de errores de software entre los seis mismos tipos de proyectos
conocidos en la tabla 1. En la Tabla 3, los defectos son mostrados a partir de cinco fuentes: errores de
requerimientos, errores de diseo, errores de codificacin, errores de documentacin de usuario y

reparaciones malas. Una mala reparacin es un defecto secundario inyectado accidentalmente en un


defecto reparado. En otras palabras una mala reparacin es una intencin fallida para reparar un
defecto previo que por casualidad contiene un nuevo defecto. Por regla general, aproximadamente el
7% de las reparaciones de errores accidentalmente inyectarn un nuevo defecto, aunque la gama es de
menos del 1% ms que el 20% de inyecciones de mala reparacin.
Los datos en la Tabla 3 y en las otras tablas en este escrito, estn basadas en un total de
aproximadamente 12,000 proyectos de software evaluados por el autor y sus colegas alrededor de
1984-2004. Informacin adicional sobre las fuentes de datos puede ser encontrada en (Jones 1996),
(Jones 1998), and (Jones 2000). Tambin pueden ver a (Kan 2003).
Tabla

3: Potenciales defectos promedios para seis tipos de aplicaciones


(Datos expresados en trminos de "defectos por puntos de funcin")
Web MIS Outsource Comercial Sistema Militar Promedio
Requisitos
1
1
1.1
1.25
1.3
1.7
1.23
Diseo
1 1.25
1.2
1.3
1.5
1.75
1.33
Cdigo
1.25 1.75
1.7
1.75
1.8
1.75
1.67
Documentos
0.3 0.6
0.5
0.7
0.7
1.2
0.67
Mala reparacin
0.45 0.4
0.3
0.5
0.7
0.6
0.49
Total
4
5
4.8
5.5
6
7
5.38

La Tabla 3 presenta valores de promedio aproximados, pero en el rango de cada categora de defecto es
ms que 2 a 1. Por ejemplo, los proyectos de software desarrollados por compaas que estn en el
nivel cinco sobre su modelo de capacidad de madurez, pudieran tener menos de la mitad de los
defectos potenciales expuestos en la Tabla 3. Igualmente, para las compaas con varios aos de
experiencia con el Six Sigma, la calidad aproximada tambin tendra potenciales de defectos bajos que
estn mostrados en este cuadro. Varias herramientas comerciales de estimacin hacen ajustes para
cada factor.
Un factor clave para la estimacin exacta involucra la eliminacin de defectos a travs de revisiones,
inspecciones y evaluacin. La medida de remocin de defectos es de hecho bastante sencilla y muchas
empresas ahora hacen esto. El promedio de los Estados Unidos es aproximadamente 85%, pero las
empresas destacadas pueden promediar ms del 95% de niveles de eficiencia de eliminacin de
defectos (Jones 1997).
Es ms fcil estimar proyectos de software que utilizar controles de calidad sofisticados y tener altos
niveles de eliminar el defecto en el 95% de las posibilidades. Esto es porque generalmente no hay
ocurrencias tardas de desastres en desarrollo cuando aparecen defectos inesperados. As los proyectos
realizados por compaas en los ms altos niveles de CMM o por compaas con amplia experiencia en
"Six Sigma" para software, frecuentemente tienen muchas ms precisin que el promedio.
La Tabla 4 ilustra las variaciones en prevencin de defectos tpicos y mtodos de remocin de defectos
entre los seis dominios ya discutidos. Por supuesto, muchas variaciones pueden ocurrir en esos
modelos.
(Los valores de eficiencia acumulativos en la Tabla 4 son calculados as: Si el nmero de partida de
defectos es 100, y hay dos etapas de prueba consecutivas que cada una elimina el 50% de los defectos
presentes, entonces la primera prueba remover 50 defectos y la segunda prueba quitar 25 defectos.
La eficacia acumulativa de ambas pruebas es de 75%, porque 75 de los 100 defectos posibles fueron
eliminados.)
Tabla 4: Patrones de la prevencin de defectos y eliminacin de actividades

Web
Actividades
prevencin
Prototipos
20.00%
Cuartos limpios
Sesiones JAD
Sesiones QDF
Subtotal
20.00%
Pre-pruebas
de
eliminacin
Revisin
de
15.00%
escritorio
Revisin de requerimiento
Revisin
de
diseo
Revisin
documentos

de

Inspeccin
cdigo
Validacin
verificacin
Pruebas
correccin
Laboratorios
usabilidad
Subtotal
Actividades
evaluacin
Prueba
unidad
Nueva
de funcin
Pruebas
regresin
Pruebas
integracin
Pruebas
desempeo
Pruebas
sistema
Pruebas
independientes
Pruebas
campo
Pruebas
aceptacin
Subtotal
Rendimiento

de

MIS

Outsource

Comercial

Sistema

Militar
de

20.00%

20.00%

30.00%

30.00%

20.00%

20.00%
20.00%

20.00%
20.00%

36.00%

44.00%

44.00%

20.00%

25.00%
52.00%

15.00%

15.00%

15.00%

15.00%

15.00%

30.00%

25.00%

20.00%

20.00%

40.00%

45.00%

45.00%

30.00%

20.00%

20.00%

20.00%

50.00%

60.00%

40.00%

20.00%

de

10.00%

de

25.00%
15.00% 15.00%

64.30%

89.48%

88.03%

83.55%
de

de
prueba

30.00% 25.00%

25.00%

25.00%

25.00%

25.00%

30.00%

30.00%

30.00%

30.00%

30.00%

20.00%

20.00%

20.00%

20.00%

30.00%

30.00%

30.00%

30.00%

15.00%

15.00%

15.00%

35.00%

40.00%

35.00%

de
de

30.00%

de
del

35.00%

35.00%

15.00%
de

50.00%

de

25.00%
30.00% 76.11%
52.40% 88.63%

80.89%
96.18%

91.88%
99.32%

35.00%

30.00%

25.00%

30.00%

92.69%
99.58%

93.63%
99.33%

global
Nmero
actividades

de

11

14

16

18

La Tabla 4 simplifica demasiado la situacin, ya que las actividades de eliminacin de defecto tienen
eficiencias variables para los requerimientos, diseo, codificacin, documentacin, y categoras de
defectos mal reparados. Del mismo modo, las malas reparaciones durante la evaluacin sern
colocadas detrs del conjunto de defectos no detectados.
La baja eficiencia de la mayora de las formas de la eliminacin de defectos explica por qu una larga
serie de actividades de remocin de defectos son necesarias. Esto explica por qu la estimacin de
eliminacin de defecto es crtica para la exactitud total de la estimacin de costos de software para
grandes sistemas. Debajo de los 1000 puntos de funcin las series pueden incluir ms de una docena
de tipos de revisin, inspeccin y actividad de evaluacin.
Cambios de requerimientos y estimacin de software
Un aspecto importante de estimacin es la relacin con el ndice en el cual los requerimientos "se
corrompen" y por consiguiente generan que los proyectos crezcan ms durante el desarrollo. Por suerte,
la mtrica de punto de funcin permite la medicin directa del ndice en el cual este fenmeno ocurre, ya
que tanto los requerimientos originales como los requerimientos modificados tendrn cuentas de puntos
de funcin.
El cambio de requerimientos puede ocurrir en cualquier momento, pero los datos en la Tabla 5 van
desde del final de la fase de requerimientos al inicio de la fase de codificacin. Este perodo de tiempo
por lo general refleja aproximadamente la mitad de del calendario de desarrollo total. La Tabla 5
presenta el pago mensual aproximado de requerimientos que se corrompen para seis clases de
software, y el volumen total de cambio que podra ser esperado:
Tabla 5: Indce mensual de cambios en los requerimientos para seis tipos de
aplicaciones
(Desde el final de los requerimientos hasta el inicio de las fases de
codificacin)
Web MIS
Outsource Comercial Sistema Militar Promedio
ndice mensual
4.00% 2.50%
1.50%
3.50%
2.00% 2.00%
2.58%
Meses
6
12
14
10
18
24
14
Total
24.00% 30.00%
21.00%
35.00%
36.00% 48.00% 32.33%
Para estimaciones hechas tempranamente en el ciclo de vida, varias herramientas de estimacin
pueden predecir el crecimiento probable en funciones imprevistas sobre el resto del ciclo de desarrollo.
Este conocimiento entonces puede ser usado para refinar la estimacin, y ajustar los costos finales en la
respuesta.
Por supuesto, la mejor respuesta a una estimacin con un volumen significativo de cambios de
requerimientos proyectado debe mejorar la reunin de requerimientos y los mtodos de anlisis. As los
proyectos que usan prototipos, el Desarrollo de una Aplicacin en COnjunto (JAD), inspecciones de
requerimientos, y otros mtodos de requerimientos sofisticados pueden reducir cambios posteriores a
una pequea fraccin de los valores mostrados en la Tabla 5. Incluso, las estimaciones iniciales hechas
para proyectos que usan JAD predecirn los volmenes reducidos de exigencias que se cambian.
Factores de Ajuste para Estimaciones de Software

Cuando son usadas para verdaderos proyectos de software, las suposiciones bsicas de falta de
herramientas de estimacin deben ser ajustadas para emparejar la realidad del proyecto que est
siendo estimado. Estos factores de ajuste son una porcin crtica del uso de herramientas de estimacin
de software. Algunos de los factores de ajustes disponibles incluyen:
- La experiencia de personal con proyectos similares
- La experiencia de cliente con proyectos similares
- El tipo de software para ser producido
- El tamao del proyecto de software
- El tamao de los elementos entregables (documentos, casos de prueba etc.)
- Los mtodos de requerimientos usados
- Inspecciones y revisin de los mtodos usados
- Diseo de mtodos usados
- Programacin de los lenguajes usados
- Disponibilidad de materiales reutilizables
- Mtodos de evaluacin usados
- Sobretiempo pagado
- Sobretiempo no pagado
Las herramientas de estimacin automatizadas proporcionan a los usuarios con habilidades para afinar
los parmetros de la estimacin para emparejar las condiciones locales. Efectivamente, sin tal afinacin
la exactitud de la estimacin automatizada es reducida significativamente. El conocimiento de cmo
ajustar las herramientas de estimacin en respuesta a varios factores es el verdadero corazn de la
estimacin de software. Este tipo de conocimiento puede ser mejor determinado por mediciones
acertadas y regresin mltiple de anlisis de verdaderos proyectos de software.
Resumen y Conclusiones
La estimacin de software es simple en teora, pero difcil y compleja en realidad. Mientras ms grande
el proyecto, ms factores habrn que deben ser evaluados. La dificultad y la complejidad requerida para
las estimaciones acertadas de proyectos de software grandes exceden las capacidades de la mayora
de los project managers de software para producir estimaciones manuales efectivas. En particular, la
estimacin acertada de proyectos grandes tiene que abarcar el trabajo de no codificacin.
Las herramientas comerciales de estimacin de software estn lejos de ser perfectas y ellas tambin
pueden equivocarse. Pero la estimacin automatizada frecuentemente supera a las estimaciones
humanas en trminos de exactitud y siempre en trminos de velocidad y rentabilidad. Sin embargo,
ningn mtodo de estimacin est completamente libre de error. La actual mejor prctica para la
estimacin de costos de software debe usar una combinacin de herramientas de estimacin de costos
de software acoplados con las herramientas de administracin de proyectos de software, bajo la
direccin cuidadosa de project managers de software experimentados y especialista en estimacin.
El presente escrito titulado Mtodos de Estimacin de Costos de Software para Grandes Proyectos fue traducido al
espaol a partir del artculo Software Cost Estimating Methods For Large Projects con autorizacin expresa de su
autor para fines instructivos.

Referencias sobre estimacin de costos de software

Albrecht, Allan; AD/M Productivity Measurement and Estimate Validation; IBM Corporation,
Purchase, NY; May 1984.
Jones, Capers; Applied Software Measurement; McGraw Hill, 2nd edition 1996; ISBN 0-07032826-9; 618 pages.
Jones, Capers; Software Quality Analysis and Guidelines for Success; International Thomson
Computer Press, Boston, MA; ISBN 1-85032-876-6; 1997; 492 pages.
Jones, Capers; Estimating Software Costs; McGraw Hill, New York; 1998; 724 pages; ISBN 007-913094-1.

Jones, Capers; Software Assessments, Benchmarks, and Best Practices; Addison Wesley
Longman, Boston, MA, 2000; 659 pages.
Jones, Capers; Software Project Management Practices: Failure Versus Success; Crosstalk,
October 2004.
Kan, Stephen H.; Metrics and Models in Software Quality Engineering, 2nd edition; Addison
Wesley Longman, Boston, MA; ISBN 0-201-72915-6; 2003; 528 pages.
Lecturas sobre estimacin de costos de software
Barrow, Dean, Nilson, Susan, and Timberlake, Dawn; Software Estimation Technology Report;
Air Force Software Technology Support Center; Hill Air Force Base, Utah; 1993.
Boehm, Barry Dr.; Software Engineering Economics; Prentice Hall, Englewood Cliffs, NJ; 1981;
900 pages.
Brown, Norm (Editor); The Program Managers Guide to Software Acquisition Best Practices;
Version 1.0; July 1995; U.S. Department of Defense, Washington, DC; 142 pages.
Garmus, David & Herron, David; Measuring the Software Process: A Practical Guide to
Functional Measurement; Prentice Hall, Englewood Cliffs, NJ; 1995.
Garmus, David & Herron, David; Function Point Analysis; Addison Wesley Longman, Boston,
MA.
Garmus, David; Accurate Estimation; Software Development; July 1996; pp 57-65.
IFPUG Counting Practices Manual, Release 4, International Function Point Users Group,
Westerville, OH; April 1995; 83 pages.
IFPUG; IT Measurement; Practical Advice from the Experts; Addison Wesley Longman, Boston,
MA; 2002; 759 pages.
Jones, Capers; Sizing Up Software; Scientific American, New York, NY, December 1998; Vol.
279 No. 6; pp 104-109.
Jones, Capers; Conflict and Litigation Between Software Clients and Developers; Software
Productivity Research, Burlington, MA; 2004; 54 pages.
Kemerer, Chris F.; An Empirical Validation of Software Cost Estimation Models;
Communications of the ACM; 30; May 1987; pp. 416-429.
Kemerer, C.F.; Reliability of Function Point Measurement - A Field Experiment;
Communications of the ACM; Vol. 36; pp 85-97; 1993.
Mertes, Karen R.; Calibration of the CHECKPOINT Model to the Space and Missile Systems
Center (SMC) Software Database (SWDB); Thesis AFIT/GCA/LAS/96S-11, Air Force Institute of
Technology (AFIT), Wright Patterson AFB, Ohio; September 1996; 119 pages.
Park, Robert E. et al; Software Cost and Schedule Estimating - A Process Improvement
Initiative; Technical Report CMU/SEI 94-SR-03; Software Engineering Institute, Pittsburgh, PA;
May 1994.
Park, Robert E. et al; Checklists and Criteria for Evaluating the Costs and Schedule Estimating
Capabilities of Software Organizations; Technical Report CMU/SEI 95-SR-005; Software
Engineering Institute, Pittsburgh, PA; January 1995.
Putnam, Lawrence H.; Measures for Excellence -- Reliable Software On Time, Within Budget;
Yourdon Press - Prentice Hall, Englewood Cliffs, NJ; ISBN 0-13-567694-0; 1992; 336 pages.
Putnam, Lawrence H and Myers, Ware.; Industrial Strength Software - Effective Management
Using Measurement; IEEE Press, Los Alamitos, CA; ISBN 0-8186-7532-2; 1997; 320 pages.
Roetzheim, William H. and Beasley, Reyna A.; Best Practices in Software Cost and Schedule
Estimation; Prentice Hall PTR, Saddle River, NJ; 1998.
Stukes, Sherry, Deshoretz, Jason, Apgar, Henry and Macias, Ilona; Air Force Cost Analysis
Agency Software Estimating Model Analysis ; TR-9545/008-2; Contract F04701-95-D-0003, Task
008; Management Consulting & Research, Inc.; Thousand Oaks, CA 91362; September 30
1996.

Das könnte Ihnen auch gefallen