Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Aliados del PMI® México

LiderDeProyecto.com es aliado estratégico del PMI® Capítulo México.
+
.
Humor del Líder

Método para contratar personal.
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
Artículos
 

Métodos de Estimación de Costos de Software para Grandes Proyectos

Por Capers Jones [ Acerca del autor ]

El software ha alcanzado una mala reputación pues ha sido considerado como una tecnología perturbadora. Los grandes proyectos de software han tendido a tener una muy alta frecuencia de exceso de calendarización, costos, problemas de calidad e indiscutibles cancelaciones. Mientras esta mala reputación a menudo es merecida, es importante notar que algunos grandes proyectos de software finalizan a tiempo y con el presupuesto estimado, además 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, cómo los proyectos exitosos concluyen a tiempo, dentro de los costos, recursos y estimación de calidad prevista en un primer término. De un análisis de resultados de las herramientas de estimación usadas, publicado en “Estimación de Costos de Software” (Jones 1998), el uso de instrumentos de estimación automatizados conduce a estimaciones más exactas. A la inversa, los métodos informales o manuales de llegar en estimaciones iniciales son generalmente inexactos y a menudo excesivamente optimistas.

Una comparación de 50 estimaciones manuales con 50 estimaciones automatizadas para proyectos en el rango de los 5000 puntos de función, mostró resultados interesantes (Jones 1998). Las estimaciones manuales fueron creadas por administradores de proyectos quienes usaban calculadoras y hojas de cálculo. Las estimaciones automatizadas también fueron creadas por administradores de proyectos o por sus asistentes de estimación, usando varias herramientas de estimación 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 práctica.

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 consternación, 29 proyectos fueron optimistas por más 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 comparación fue entre la estimación inicial y los resultados finales).

Por contraste 22 de las estimaciones generadas por herramientas de estimación comercial estuvieron dentro del 10% real de los resultados. Aproximadamente 24 fueron conservadoras entre 10% y 25%. Tres fueron conservadoras por más 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 tendrían que haber finalizado. Este criterio eliminó muchos proyectos que usaron tanto estimación manual como automatizada.

De modo interesante, las estimaciones manuales y las automatizadas eran equitativamente cercanas en términos de predicción del esfuerzo de programación o codificación. Pero las estimaciones fueron muy optimistas cuando predecían el crecimiento de los requerimientos, esfuerzo del diseño, esfuerzo de documentación, esfuerzo de administración, esfuerzo de evaluación y esfuerzo de revisión y reparación. La conclusión de la comparación fue que tanto las estimaciones manuales como las automatizadas eran equivalentes para la programación real, pero las estimaciones automatizadas eran mejores para predecir actividades de no codificación.

Este es un asunto importante para la estimación de grandes aplicaciones de software. Para proyectos de software por debajo de aproximadamente 1000 puntos de función en tamaño (equivalente a 125,000 declaraciones C), la programación es el mayor costo de manejo, la exactitud de estimación para codificación es un elemento clave. Pero para proyectos sobre los 10,000 puntos de función en tamaño (equivalente a 1,250,000 declaraciones C), tanto la eliminación de defectos como la producción de documentos son más costosas que el código por sí mismo. Por lo tanto la exactitud en la estimación de esos tópicos es un factor clave.

Las estimaciones de tiempo y costo deberían ser exactas, naturalmente. Pero si ellas difieren de los resultados reales, es más 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 estimación acertada es aquel en donde éstas deben ser defendibles. La mejor defensa es una buena colección de datos históricos de proyectos similares.

Debido a que el crecimiento de la estimación de costos es una actividad compleja, existe un crecimiento industrial de compañías dedicadas a ofrecer diferentes marcas comerciales de herramientas de estimación de costos en el mercado. A partir del 2005, algunas de esas herramientas de estimación son: COCOMO II, CoStar, CostModeler, CostXpert, KnowledgePlan®, PRICE S, SEER, SLIM y SoftCost. Algunas de las herramientas de estimación de costos más antiguas, no están activamente en el mercado pero todavía 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 utilización está en declive.

Mientras estos instrumentos de estimación fueron desarrollados por empresas diferentes y no son idénticos, ellos realmente tienden a proporcionar un núcleo de funciones comunes. Los rasgos principales de instrumentos de estimación de software comerciales en incluyen estos atributos:

• Lógica de dimensionamiento para especificaciones, código fuente y casos de evaluación
• Nivel de fase, nivel de actividad, y estimación de nivel de tarea
• Ajustes para períodos de trabajo específicos, 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 métricas de puntos de función, métricas de líneas de códigos o ambas
• Apoyo para “backfiring”, es decir, convertir líneas de códigos a puntos de función
• Apoyo tanto para nuevos proyectos como a proyectos de mejora y mantenimiento

Algunas herramientas de estimación también incluyen funciones más avanzadas como:

• Estimación de fiabilidad y calidad
• Análisis de valor y riesgo
• Retorno de Inversión
• Posibilidad de compartir datos con herramientas de administración de proyectos
• Medios de medición para reunir datos históricos
• Costo y tiempo para completar estimaciones que combinan datos históricos con datos proyectados
• Apoyo para evaluaciones de procesos de software
• Análisis estadístico de múltiples proyectos y análisis de cartera
• Conversión monetaria para acordar proyectos en el exterior

Las estimaciones para grandes proyectos de software necesitan incluir muchas más actividades que solamente codificar o programar. La Tabla 1 muestra un modelo de actividad típica para seis clases diferentes de proyectos: aplicaciones web-based, sistemas de información gerencial (MIS), software outsourced, software comercial, software de sistemas y proyectos de software militares. En este contexto los proyectos “web” son aplicaciones diseñadas para apoyar sitios web corporativos. Las letras (MIS) son las siglas en inglés 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 físicos como sistemas de telecomunicaciones o computadoras. El software militar constituye todos los proyectos los cuales son obligados para seguir varios estándares de índole militar. El software comercial se refiere a paquetes ordinarios como procesadores de palabras, hojas de cálculo y otros por el estilo.

Tabla 1:  Actividades típicas 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 Diseño inicial
8.00%
7.00%
6.00%
7.00%
6.00%
06 Diseño en detalle
7.00%
8.00%
5.00%
6.00%
7.00%
07 Revisiones de diseño
0.50%
1.50%
2.50%
1.00%
08 Codficación
30.00%
20.00%
16.00%
23.00%
20.00%
16.00%
09 Adquisición Reutilización
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 código
1.50%
1.50%
1.00%
12 Validación y verificación
1.00%
13 Administración de la configuración
3.00%
3.00%
1.00%
1.00%
1.50%
14 Integración formal
2.00%
2.00%
1.50%
2.00%
1.50%
15 Documentación 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 función
6.00%
5.00%
6.00%
5.00%
5.00%
18 Pruebas de integración
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 aceptación
5.00%
3.00%
1.00%
3.00%
22 Pruebas independientes
1.00%
23 Aseguramiento de la calidad
1.00%
2.00%
2.00%
1.00%
24 Capacitación/Instalación
2.00%
3.00%
1.00%
1.00%
25 Administración 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 números reales de actividades realizadas y los porcentajes de esfuerzo para cada actividad pueden variar. Para estimar proyectos reales, el instrumento de estimación presentaría el conjunto más probable de actividades para ser realizadas. Entonces el Project Manager o el especialista en estimación de costos ajustaría el conjunto de actividades que corresponden a la realidad del proyecto. Algunos instrumentos de estimación permiten a los usuarios añadir actividades adicionales que no son parte del conjunto de actividades originales.

Generadores de Costos para Grandes Sistemas de Software: Trabajo Administrativo y Eliminación de de Defectos

En conjunto, los grandes proyectos de software dedican más esfuerzo a la producción de documentos y a la eliminación de defectos que la producción de un código fuente. De este modo, la estimación 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 invención de métricas de puntos de función (Albrecht 1984) ha hecho de la lógica de evaluación completa para documentos un característica estándar de muchas herramientas de estimación. Una de las razones para el desarrollo de las métricas de puntos de función fue proveer un método de evaluación para documentos entregables. Para información adicional sobre puntos de función, pueden entrar al Sitio Web www.ifpug.org.

Tabla 2: Ilustra ejemplos de tamaño de documentación seleccionada a partir de sistemas, proyectos web, MIS, Outsource, Comercial, Sistemas y dominios de software militar.

Tabla 2: Páginas de documento por punto de función para seis tipos de aplicaciones
               (Datos expresados en términos de páginas por cada punto de función)
Web
MIS
Outsource
Comercial
Sistema
Militar
Promedio
Requerimientos
0.25
0.5
0.55
0.3
0.45
0.85
0.48
Especificaciones de función
0.1
0.55
0.55
0.6
0.8
1.75
0.73
Especificaciones de lógica
0.5
0.5
0.55
0.85
1.65
0.81
Planes de prueba
0.1
0.1
0.15
0.25
0.25
0.55
0.23
Guías 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 estimación de software puede incluso predecir el número de palabras en inglés en el conjunto de documentos y también los números de diagramas que probablemente están presentes. La estimación de documento puede también cambiar basada o empapelar el tamaño tal como el papel A4 europeo. De hecho, ahora es posible estimar los tamaños basados en texto e incluso estimar los costos de traducción de un idioma a otro para los proyectos que son desplegados internacionalmente.

Potenciales de Defecto de Software y Niveles de Eficacia de Eliminación de Defecto

Un aspecto clave de la estimación de costo de software es predecir el tiempo y el esfuerzo que será necesario para revisiones de diseño, inspecciones de código, y todas las formas de pruebas. Para estimar la eliminación los costos de eliminación de defecto y calendarios, es necesario conocer cuántos defectos son susceptibles de ser encontrados.

La secuencia típica es estimar los volúmenes de defecto por un proyecto y entonces estimar la serie de revisiones, inspecciones y pruebas que utilice el proyecto. La eficiencia en la eliminación de defecto de cada paso también serán estimada. Los costos y esfuerzo para la preparación, ejecución y reparación de defectos asociados con la actividad de eliminación también serán estimadas.

Tabla 3: Ilustra la distribución 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 diseño, errores de codificación, errores de documentación de usuario y reparaciones malas. Una mala reparación es un defecto secundario inyectado accidentalmente en un defecto reparado. En otras palabras una mala reparación es una intención 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 inyectarán un nuevo defecto, aunque la gama es de menos del 1% más que el 20% de inyecciones de mala reparación.

Los datos en la Tabla 3 y en las otras tablas en este escrito, están basadas en un total de aproximadamente 12,000 proyectos de software evaluados por el autor y sus colegas alrededor de 1984-2004. Información adicional sobre las fuentes de datos puede ser encontrada en (Jones 1996), (Jones 1998), and (Jones 2000). También pueden ver a (Kan 2003).

Tabla 3: Potenciales defectos promedios para seis tipos de aplicaciones
               (Datos expresados en términos de "defectos por puntos de función")
Web
MIS
Outsource
Comercial
Sistema
Militar
Promedio
Requisitos
1
1
1.1
1.25
1.3
1.7
1.23
Diseño
1
1.25
1.2
1.3
1.5
1.75
1.33
Código
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 reparación
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 categoría de defecto es más que 2 a 1. Por ejemplo, los proyectos de software desarrollados por compañías que están 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 compañías con varios años de experiencia con el “Six Sigma”, la calidad aproximada también tendría potenciales de defectos bajos que están mostrados en este cuadro. Varias herramientas comerciales de estimación hacen ajustes para cada factor.

Un factor clave para la estimación exacta involucra la eliminación de defectos a través de revisiones, inspecciones y evaluación. La medida de remoción 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 más del 95% de niveles de eficiencia de eliminación de defectos (Jones 1997).

Es más fácil 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 tardías de desastres en desarrollo cuando aparecen defectos inesperados. Así los proyectos realizados por compañías en los más altos niveles de CMM o por compañías con amplia experiencia en "Six Sigma" para software, frecuentemente tienen muchas más precisión que el promedio.

La Tabla 4 ilustra las variaciones en prevención de defectos típicos y métodos de remoción 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 número 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 prevención de defectos y eliminación de actividades
Web
MIS
Outsource
Comercial
Sistema
Militar
Actividades de
prevención
Prototipos
20.00%
20.00%
20.00%
20.00%
20.00%
20.00%
Cuartos limpios        
20.00%
20.00%
Sesiones JAD  
30.00%
30.00%
     
Sesiones QDF        
25.00%
 
Subtotal
20.00%
44.00%
44.00%
20.00%
52.00%
36.00%
Pre-pruebas de
eliminación
           
Revisión de
escritorio
15.00%
15.00%
15.00%
15.00%
15.00%
15.00%
Revisión de requerimiento
   
30.00%
25.00%
20.00%
20.00%
Revisión de
diseño
   
40.00%
45.00%
45.00%
30.00%

Revisión de
documentos

     
20.00%
20.00%
20.00%
Inspección de
código
     
50.00%
60.00%
40.00%
Validación y
verificación
         
20.00%
Pruebas de
corrección
         
10.00%
Laboratorios de
usabilidad
     
25.00%
   
Subtotal
15.00%
15.00%
64.30%
89.48%
88.03%
83.55%
Actividades de
evaluación
Prueba de
unidad
30.00%
25.00%
25.00%
25.00%
25.00%
25.00%
Nueva prueba
de función
 
30.00%
30.00%
30.00%
30.00%
30.00%
Pruebas de
regresión
   
20.00%
20.00%
20.00%
20.00%
Pruebas de
integración
 
30.00%
30.00%
30.00%
30.00%
30.00%
Pruebas de
desempeño
     
15.00%
15.00%
15.00%
Pruebas del
sistema
 
35.00%
35.00%
35.00%
40.00%
35.00%
Pruebas
independientes
         
15.00%
Pruebas de
campo
     
50.00%
35.00%
30.00%
Pruebas de
aceptación
   
25.00%
 
25.00%
30.00%
Subtotal
30.00%
76.11%
80.89%
91.88%
92.69%
93.63%
Rendimiento
global
52.40%
88.63%
96.18%
99.32%
99.58%
99.33%
Número de
actividades

3

7
11
14
16
18

La Tabla 4 simplifica demasiado la situación, ya que las actividades de eliminación de defecto tienen eficiencias variables para los requerimientos, diseño, codificación, documentación, y categorías de defectos mal reparados. Del mismo modo, las malas reparaciones durante la evaluación serán colocadas detrás del conjunto de defectos no detectados.

La baja eficiencia de la mayoría de las formas de la eliminación de defectos explica por qué una larga serie de actividades de remoción de defectos son necesarias. Esto explica por qué la estimación de eliminación de defecto es crítica para la exactitud total de la estimación de costos de software para grandes sistemas. Debajo de los 1000 puntos de función las series pueden incluir más de una docena de tipos de revisión, inspección y actividad de evaluación.

Cambios de requerimientos y estimación de software

Un aspecto importante de estimación es la relación con el índice en el cual los requerimientos "se corrompen" y por consiguiente generan que los proyectos crezcan más durante el desarrollo. Por suerte, la métrica de punto de función permite la medición directa del índice en el cual este fenómeno ocurre, ya que tanto los requerimientos originales como los requerimientos modificados tendrán cuentas de puntos de función.

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 codificación. Este período 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 podría ser esperado:

Tabla 5: Indíce mensual de cambios en los requerimientos para seis tipos de                    aplicaciones
                   (Desde el final de los requerimientos hasta el inicio de las fases de                     codificación)
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 estimación pueden predecir el crecimiento probable en funciones imprevistas sobre el resto del ciclo de desarrollo. Este conocimiento entonces puede ser usado para refinar la estimación, y ajustar los costos finales en la respuesta.

Por supuesto, la mejor respuesta a una estimación con un volumen significativo de cambios de requerimientos proyectado debe mejorar la reunión de requerimientos y los métodos de análisis. Así los proyectos que usan prototipos, el Desarrollo de una Aplicación en COnjunto (JAD), inspecciones de requerimientos, y otros métodos de requerimientos sofisticados pueden reducir cambios posteriores a una pequeña fracción de los valores mostrados en la Tabla 5. Incluso, las estimaciones iniciales hechas para proyectos que usan JAD predecirán los volúmenes reducidos de exigencias que se cambian.

Factores de Ajuste para Estimaciones de Software

Cuando son usadas para verdaderos proyectos de software, las suposiciones básicas de falta de herramientas de estimación deben ser ajustadas para emparejar la realidad del proyecto que está siendo estimado. Estos factores de ajuste son una porción crítica del uso de herramientas de estimación 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 tamaño del proyecto de software
- El tamaño de los elementos entregables (documentos, casos de prueba etc.)
- Los métodos de requerimientos usados
- Inspecciones y revisión de los métodos usados
- Diseño de métodos usados
- Programación de los lenguajes usados
- Disponibilidad de materiales reutilizables
- Métodos de evaluación usados
- Sobretiempo pagado
- Sobretiempo no pagado

Las herramientas de estimación automatizadas proporcionan a los usuarios con habilidades para “afinar” los parámetros de la estimación para emparejar las condiciones locales. Efectivamente, sin tal afinación la exactitud de la estimación automatizada es reducida significativamente. El conocimiento de cómo ajustar las herramientas de estimación en respuesta a varios factores es el verdadero corazón de la estimación de software. Este tipo de conocimiento puede ser mejor determinado por mediciones acertadas y regresión múltiple de análisis de verdaderos proyectos de software.

Resumen y Conclusiones

La estimación de software es simple en teoría, pero difícil y compleja en realidad. Mientras más grande el proyecto, más factores habrán que deben ser evaluados. La dificultad y la complejidad requerida para las estimaciones acertadas de proyectos de software grandes exceden las capacidades de la mayoría de los project managers de software para producir estimaciones manuales efectivas. En particular, la estimación acertada de proyectos grandes tiene que abarcar el trabajo de no codificación.

Las herramientas comerciales de estimación de software están lejos de ser perfectas y ellas también pueden equivocarse. Pero la estimación automatizada frecuentemente supera a las estimaciones humanas en términos de exactitud y siempre en términos de velocidad y rentabilidad. Sin embargo, ningún método de estimación está completamente libre de error. La actual “mejor práctica” para la estimación de costos de software debe usar una combinación de herramientas de estimación de costos de software acoplados con las herramientas de administración de proyectos de software, bajo la dirección cuidadosa de project managers de software experimentados y especialista en estimación.

El presente escrito titulado “Métodos de Estimación de Costos de Software para Grandes Proyectos” fue traducido al español a partir del artículo “Software Cost Estimating Methods For Large Projects” con autorización expresa de su autor para fines instructivos.

Referencias sobre estimación 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-07-032826-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 0-07-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 estimación 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 Manager’s 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.


Esta página ha sido calificada como:
Califica esta página:   

Temas relacionados:
Certificación en Administración de Proyectos de Software
 Entrevista a Capers Jones
Estimación de costos y administración de proyectos de software (libro recomendados)
+

Comparte

Qué opinan nuestros lectores… ( Comparte también tu opinión )

 

Editor dijo el 04 Octubre de 2013:
Hola Liliana, muy amable por tus comentarios, por favor cualquier duda que tengas sobre el tema estamos para servirte. Saludos.

Liliana dijo el 04 Octubre de 2013:
Que chévere esta publicación, es justo lo que estaba buscando. No sabes lo difícil que fue conseguir información de este tipo, sobre todo porque los demás sitios se dedican a repetir lo mismo y no dicen lo que realmente interesa. Muy bueno.

tahonet dijo el 01 Agosto de 2012:
muy bueno, muy bien explicado


Manuel dijo el 11 Diciembre de 2011:
Muy buen documento, mucha gracias!!

Editor dijo el 29 Agosto de 2011:
Cesia

Que bueno que te haya gustado el artículo, sobre todo porque fue desarrollado por un gran gurú como lo es Capers Jones.

Gracias por visitar LiderDeProyecto.com

cesia dijo el 27 Agosto de 2011:
buen articulo

Orlando dijo el 27 Junio de 2011:
Muchas gracias por brindarme la oportunidad de inscribirme a esta página, apenas la estoy conociendo y la verdad el articulo sobre costos me parece magnifico, es la información que estaba necesitando.

maguiz dijo el 02 Febrero de 2011:
:)

Julio dijo el 02 Noviembre de 2010:
Hola querido Osvaldo

Al igual que tú me gusta este sitio porque me ayuda a mantenerme actualizado y siempre ando siguiendo sus últimas publicaciones. Revisando un poco pude ver que los videos 10 y 11 de la sección videoboletín, se habla sobre estimación, de repente te podrá funciona.

osvaldo dijo el 02 Noviembre de 2010:
saludos

tendrán un video de como hacer una medición de software por medio de puntos de función? muchas gracias, y felicidades por su sitio.



Comparte tu opinión
Los campos marcados con * son obligatorios.


*Nombre:
Correo:
Esconder mi dirección
*Texto:
 


Gestión de cambios organizacionales (Cassio Dreyfuss)
+
.
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. PMI®, PMBOK® Guide, OPM3®, CAPM® y PMP® son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.