Este documento describe varias técnicas para estimar los costos de proyectos de software. Presenta métricas como líneas de código y puntos de función que pueden usarse para estimar el tamaño de un proyecto. También describe factores que afectan los costos como la capacidad de los programadores, la complejidad del producto y el tiempo disponible. Finalmente, resume técnicas como el juicio experto y Delphi para realizar estimaciones.

1. TECNICAS DE ESTIMACION DE COSTOS DE PROYECTO SOFTWAREJENNIFER ANDREA CANO GUEVARAINGENIERIA DE SISTEMAS

2. La EstimaciónNo necesita realizarse en una forma improvisada.La experiencia es una gran ayuda.La estimación implica riesgo inherente, y este conduce a la incertidumbre.El riesgo de la estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas para recursos, costos y programa de trabajo.

3. La dificiltarea de estimarLa estimación de software es difícil. Los jefes, directivos, clientes y desarrolladores no parecen entender por qué la estimación es tan difícil. No se puede estimar con precisión el costo de un programa hasta que se comprendan con detalle cada una de las funciones que realizará el sistema. La incertidumbre sobre la naturaleza del producto aporta incertidumbre a la estimación.

4. EstimaciónUn gran error en la estimación puede hacer la diferencia entre Ganancia o Perdida.

5. FACTORES QUE INFLUYEN EN EL COSTO DEL SOFTWARE La estimación de lo que costará el desarrollo de un software es una de las actividades de planeación que reviste especial importancia, ya que una de las características que debe tener un producto de software es que su costo sea adecuado, de lo contrario el proyecto puede fracasar.

6. Los factores que afectan el costo del software1. Capacidad del programador 2. Complejidad del producto 3. Tamaño del programa 4. Tiempo disponible 5. Confiabilidad requerida

7. El Proceso de Estimación 1. Estimar el tamaño del producto ( en número de líneas de código fuente o puntos de función ). 2. Estimar el esfuerzo ( personas - mes ). 3. Estimar el plan ( meses ).

8. Técnicas de DescomposiciónLa técnica de descomposición basada en el problema, se basa en la descomposición del producto en funciones y estimar el tamaño del software• Por tanto, la primera estimación que sirve de base para todas las demás, es la estimación del tamaño del software

9. Estimación Basada en el Problema

10. Técnicas de DescomposiciónTamaño del SoftwarePodemos considerar dos tamaños del software:Tamaño en LDC.Tamaño en PF.• En cualquier caso, la precisión de la estimación depende de:El grado en el que el planificador ha estimado adecuadamente el tamaño del producto a construir.

11. Técnicas de DescomposiciónTamaño del Software- La habilidad para traducir la estimación del tamaño en esfuerzo y dinero. Depende fundamentalmente de la existencia de métricas.El grado en que el plan del proyecto refleja las habilidades del equipo de software.

12. Técnicas de descomposiciónBasadas en el Problema• Dicha estimación puede basarse en:Datos históricos.Experiencia/intuición.• Con estos valores se calcula un valor esperado: VE = (Vo + 4Vm + Vp)/6• Una vez estimado el tamaño se aplican los datos históricos de productividad LDC

13. Técnicas de DescomposiciónBasadas en el Proceso• La técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar• Utilizando el proceso identificamos un conjunto pequeño de actividades de trabajo o tareas de trabajo y se estima el esfuerzo requerido para llevar a cabo cada tarea

14. METRICA“Un Método y una escala cuantitativos que pueden ser usados para determinar el valor que toma cierta característica en un producto de software concreto.”

15. Ecuaciones de los Modelos Empiricos

16. CLASIFICACION DE LAS METRICASMÉTRICAS TÉCNICAS: Se centran en las características de software.MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del software.

17. CLASIFICACION DE LAS METRICASMÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos.MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en que tiempo voy a terminar el software y cuantas personas voy a necesitar.

18. CLASIFICACION DE LAS METRICASMÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso por el cual se desarrolla.

19. Métricas del SoftwareMétricas Orientadas al tamañoMedidas directas del resultadoy del procesoMétricas Orientadas a la funciónMedidas indirectas del software y del proceso

20. Métricas orientadas al tamañoPáginas de documentaciónEsfuerzo humano (persona - mes)N° de erroresLDCN° de defectosCoste (USD)Productividad =KLDC / persona-mesCalidad =N° de errores (defectos) / KLDCCoste medio =USD / KLDCDocumentación =KLDC / persona-mes

21. METRICA LDCCalcular la productividad, calidad, coste medio y documentación de acuerdo a la información proporcionada en la tabla que se muestra a continuación:Productividad = KLDC / personas-mes

22. Calidad = Nº errores (defectos) / KLDC

23. Coste medio = Dólares / KLDC

24. Documentación = Páginas de documentación / KLDCMETRICAS LDCCon los datos contenidos en la tabla se puede obtener un conjunto de métricas simples adicionales: No. De Errores por LDC 134 / 12,100 0.01 Errores / LDC No. De Defectos por LDC 29/12,100 0.002 Defectos / LDC Costo por LDC 168,000 / 12,100 $ 13.88 / LDC LDC por persona-mes 12,100 / 24 904 LDC/p-m

25. METRICA LDCVentajas: - Es una métrica fácil de comprender. - Muchos modelos, herramientas automáticas y literatura de estimación se basan en LDC.

26. METRICA LDCDesventajas: Las LDC son dependientes del lenguaje. Escribir el mismo programa en lenguajes diferentes puede arrojar una diferencia en LCF bastante grande. Resulta difícil que el planificador estime las LCF a producirse mucho antes de que se complete el análisis y el diseño, más aún si no tiene datos históricos.

27. -25-Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el sistema CAD por medio de una interfaz que debe tener un diseño de buena calidad. Una base de datos CAD contiene todos los datos geométricos y la información de soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a visualizar en varios dispositivos gráficos.El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.Funciones identificadas:interfaz de usuario y facilidades de control (IUFC)análisis geométrico de dos dimensiones (AG2D)análisis geométrico de tres dimensiones (AG3D)gestión de base de datos (GBD)facilidades de la interfaz gráfica (FIG)control periféricos (CP)módulos de análisis del diseño (MAD)Estimación en LDC de AG3D:optimista: 4600más probable: 6900pesimista: 8600descomposiciónde funcionesVE = (Sopt + 4Sm + Spes)/6Datos históricos:productividad media de la organización en proyectos similares: 620 LDC/pmTarifa laboral: 8000 $ /mesCoste LDC:$ 13 ($12.90)Función LDC estimadaIUFC 2300AG2D 5300AG3D 6800GBD 3350FIG 4950CP 2100MAD 8400 Total33200métricas deproyectos anterioresCoste total proyecto:$431.600Esfuerzo estimado: 54 personas-mes

28. Métricas orientadas a la funciónconsultassalidasFicheros logicos internosPFentradasFicheros de interfaz

29. EstimaciónUna mejor estimación viene dada por:S = (Sopt + 4Smed + Spes)/6cálculo de la desviación de las estimaciones

30. EntradasInformaciones que llegan a la aplicación desde el exterior.Tienen una sola dirección (Exterior à Interior)Siempre actualizan algún fichero interno. 4. Apendice, Métrica de los puntos de función.28

31. Clasificación de las salidas

32. SalidasInformaciones elaboradas por la aplicación que son transmitidas al usuario.Tienen una sola dirección (Interior a Exterior)4. Apendice, Métrica de los puntos de función.30

33. ConsultasEntradas que producen inmediatamente una salidaNo modifica los datos del sistema4. Apendice, Métrica de los puntos de función.31

34. 4. Apendice, Métrica de los puntos de función.32Clasificación de las consultasCalculamos la complejidad de la parte de entradaCalculamos la complejidad de la parte de salidaNos quedamos sólo con la complejidad mayor de las dos.

35. Ficheros Lógicos o Internos4. Apendice, Métrica de los puntos de función.33Agrupaciones de datos, tal y como los percibe el usuarioEs diferente de:Entidades y RelacionesTablas o archivos resultantes del diseño físicoLos grupos de datos serán accedidos y actualizados por la aplicación

36. Clasificación de los Ficheros Lógicos o Internos

37. Ficheros de InterfazFicheros a los que accede la aplicación con el único objetivo de obtener información.Son mantenidos por otras aplicacionesNunca los actualiza la aplicación.4. Apendice, Métrica de los puntos de función.35DIAGRAMA DE CONTEXTO

38. Clasificación de los Ficheros de Interfaz

39. TABLA PARA CALCULAR PUNTOS DED FUNCION

40. FACTORES DE COMPLEJIDADSon catorce factores que completan la visión externa de la aplicación.No están recogidos en la funcionalidad de la aplicación.Toman un valor entre 0 y 5

41. Factores de Ajuste de Complejidad: evaluar cada factor de 0 a 50- Sin influencia 3- Medio 1- Incidental 4- Significativo 2- Moderado 5- Esencial¿Requiere el sistema copias de seguridad fiables?¿Se requieren comunicaciones de datos?¿Existen funciones de procesamiento distribuido?¿Es crítico el rendimiento?¿Será ejecutado el sistema en un entorno operativo existente y utilizado?¿Se requiere entrada de datos interactiva?¿Requiere la entrada interactiva que las transacciones de entrada se hagan sobre múltiples pantallas o variadas operaciones?¿Se actualizan los archivos maestros de forma interactiva?¿Son complejas las entradas, las salidas, los archivos o las peticiones?¿Es complejo el procesamiento interno?¿Se ha diseñado el código para ser reutilizable?¿Están incluidas en el diseño la conversión y la instalación?¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?¿Se ha diseñado la aplicación para facilitar los cambios y ser fácilmente utilizada por el usuario?

42. Métricas orientadas a la funciónPF = cuentatotalX [0,65 + 0,01 * Sumatoria (Fi) ]Punto de funciónSumatoria total resultante de la ejecutar las operaciones en la tabla siguienteEn función de un cuestionario de 14 preguntas Valores de ajuste de complejidad

43. Para el ejemplo descrito se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente: PF = 50 x (0,65 + 0,01 x 46) = 55.5 ≈ 56Donde cuenta-total es la suma de todas las entradas PF obtenidas de la figura 9.2 y Fi (i=1 a 14) son los "valores de ajuste de complejidad".

44. -42-Copia de seguridad y recuperación 4Comunicaciones 2Proceso distribuido 0Rendimiento crítico 4Entorno operativo existente 3Entrada de datos online 4Transacciones entrada en varias pant. 5Archivos maestros actualizados online 3Complejidad valores dominio información 5Complejidad procesamiento interno 5Código diseñado para reutilización 4Conversión en diseño 3Instalaciones múltiples 5Aplicación diseñada para cambios 5PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)PF estimado = 372Coste total proyecto:$ 457.843Esfuerzo estimado: 58 personas-mesDatos históricos:productividad media de la organización en proyectos similares: 6,5 PF/pmTarifa laboral:8000 $ /mesCoste por PF:$ 1.230 ($1230,76)métricas deproyectos anteriores

45. 4. Apendice, Métrica de los puntos de función.43UTILIDADES DE LOS PUNTOS DE FUNCIÓN.Comparar lo que solicitó el cliente con lo que recibió.Comparar la productividad de los diferentes entornos de desarrollo.Comparar la calidad que se obtiene mediante las diferentes técnicas de desarrollo.

46. TECNICAS DE ESTIMACION DE COSTOS JUICIO EXPERTO La técnica más utilizada para la estimación de costos es el uso del juicio experto. El juicio experto se basa en la experiencia, en el conocimiento anterior y en el sentido comercial de uno o mas individuos dentro de la organización.

47. JUICIO EXPERTO El experto, por ejemplo, puede hacer una estimación de costos razonando de la siguiente manera: - El sistema que se va a desarrollar es muy similar a uno que se desarrollo anteriormente y que costó $ 8,000.00 y tardó 4 meses. - Se puede reutilizar la base del proyecto anterior. - Se utilizará el mismo equipo de cómputo y a muchos de los programadores que participaron en el proyecto anterior, por lo que la estimación se puede reducir en un 20 %.

48. JUICIO EXPERTO - Mucho código y rutinas comunes se podrán reutilizar por lo que el esfuerzo se reduce otro 20%. - Por lo tanto el nuevo proyecto puede ser un 20% más económico que el anterior.

49. JUICIO EXPERTOVentajas Se obtiene una estimación en corto tiempo.Desventajas 1. El experto puede confiarse y olvidar algunos factores importantes del Nuevo proyecto, creyendo que es casi igual al anterior. 2. El experto puede no tener familiaridad con el área del proyecto.

50. TECNICAS DE ESTIMACION DE COSTOS TECNICA DELFI Se desarrollo en la corporación Rand en 1948, con el fin de lograr un acuerdo de un grupo de expertos sin contar con los efectos negativos de las reuniones de grupos. La técnica se lleva a cabo de la siguiente manera:

51. TECNICA DELFI 1. Un coordinador proporciona a cada experto la documentación con la Definición del Sistema y una papeleta para que escriba su estimación.2. Cada experto estudia la definición y determina su estimación en forma anónima; los expertos pueden consultar al coordinador, pero no entre ellos.

52. DELFI3. El coordinador prepara y distribuye un resumen de las estimaciones efectuadas, incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos. 4. Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente, utilizando los resultados de la estimación anterior. En los casos en que una estimación difiera mucho de las demás, se podrá solicitar que también en forma anónima el experto justifique su estimación.

53. TECNICA DELFI 5. El proceso se repite tantas veces como se juzgue necesario, impidiendo una discusión grupal durante el proceso.

54. ECUACION DE PRIMER ORDEN DE JONES Carpes Jones propone una ecuación derivada del análisis de su base de datos de cientos de proyectos. Este es también un modelo empírico de estimación. Con la suma total de puntos de función , se puede realizar a partir de ellos un cálculo aproximado de la planificación.

55. ECUACION DE JONESLa ecuación de Jones tiene la forma: TDEV = #PF n Donde TDEV = Tiempo de planificación ( meses ) #PF = No. de Puntos de Función n = Exponente según la tabla siguiente

56. ECUACION DE JONES

57. TECNICA ITERATIVA Se basa en la entrega evolutiva del software ( por etapas o iteraciones ). En cada etapa se construye un pequeño conjunto de funciones del software ( miniproyecto ), que implica análisis, diseño, codificación, pruebas, documentación y evaluación del cliente. La técnica permite determinar el número de iteraciones y su longitud necesaria para desarrollar el proyecto completo.NOTA: Las estimaciones son de los desarrolladores, no de los gerentes.

58. TECNICA ITERATIVA1.- Estimar el esfuerzo de cada función del software. Asegurarse de que quien haga la estimación sea el desarrollador que posea el mayor conocimiento de la función dada.

59. TECNICA ITERATIVA2.- Determine el número de programadores. Utilizando los registros de proyectos anteriores, busque una aproximación con el Esfuerzo del proyecto actual y deduzca el número de programadores que convendría utilizar. Ejemplo: Si en un proyecto anterior de 38 semanas-programador requirió 4 programadores, puede ser razonable que el nuevo proyecto requiera de 5.

60. TECNICA ITERATIVA3.- Determine el factor de eficiencia de los programadores ( productividad ). Aunque los desarrolladores sean de tiempo completo, no dedicarán el 100% de la jornada en trabajo productivo. Investigaciones de cómo usan su tiempo los programadores indican QUE:Ejemplo: Suponga una productividad del 50% para este ejemplo.

61. TECNICA ITERATIVA4.- Determine la longitud de la iteración. Se busca una longitud de iteración fija para todo el proyecto, de modo que se pueda lograr un ritmo regular de entrega del proyecto. Cada iteración debe ser lo suficientemente larga para realizar varias funciones del software. Puede considerar longitudes de iteración de 2 a 8 semanas. Ejemplo: Suponer para este ejemplo que se implementará en un lenguaje conocido, por lo que una longitud de iteración de 3 semanas permitirá implementar de 2 a 4 funciones del software por iteración

62. TECNICA ITERATIVA5.- Calcular el esfuerzo por iteración. Esfuerzo por iteración ( semanas-programador ) = No. Programadores * Long. Iteración * Factor de Productividad Ejemplo: Esfuerzo por iteración = 5 * 3 * 0.5 = 7.5 semanas-programador

63. TECNICA ITERATIVA6.- Calcular el número de iteraciones. No. Iteraciones = ( Esfuerzo Total / Esfuerzo por Iteración ) + 1 Ejemplo: No. Iteraciones = ( 50 / 7.5 ) + 1 = 7.6 aprox. 8 iteraciones

64. 7.- Calcular el tiempo de desarrollo. Teniendo la longitud y el número de iteraciones es fácil determinar el tiempo de desarrollo Tdev = Long. Iteración * No. Iteraciones Ejemplo: Tdev = 3 * 8 = 24 semanas = 6 meses.

65. 8.- Considerar un factor de contingencia. Agregue un factor del 10% al 20% del tiempo de construcción, dependiendo de lo arriesgada que parezca la situación. Ejemplo: Considerando el factor 40-20-40, es decir, el 40% de esfuerzo es Analisis-Diseño, 20% Codificación y 40% Pruebas, calculamos que el tiempo posible de construcción ( codificación ) es el 20% de las 24 semanas totales. Tcodif = 0.2 * 24 = 4.8 aprox. 5 semanas

66. Suponiendo que nuestro factor de contingencia es del 15% entonces el tiempo de contingencia será Tconting = 0.15 * 5 = 0.75 semanas o aprox. 4 dias. Por lo tanto el plan debe ser formulado para desarrollar el producto en 24 semanas, pero el compromiso de entrega final sería para 24.75 semanas, 4 días más.

67. TECNICAS DE ESTIMACION DE COSTOS METODO HISTORICO Este método se basa en registros cuidadosos que se mantienen de esfuerzos de desarrollo previos. MODELO DE COSTOS COCOMO El modelo de costos COCOMO ( Modelo Constructivo de Costos ), se basa en el uso de ecuaciones que se utilizan de acuerdo a la complejidad del sistema a desarrollar:

68. CocomoEl Modelo Constructivo de Costos (COnstructiveCOstModel) es una jerarquía de modelos de estimación para el software.

69. Las ecuaciones del modelo COCOMO básico tienen la siguiente forma:

70. E = ab (KLDC) exp (bb)

71. D = cb (E) exp (db)

72. Las ecuaciones del modelo COCOMO intermedio toma la forma:

73. E = ai (KLDC) exp (bi) x FAE

74. donde E es el esfuerzo aplicado en personas-mes, KLDC es el número estimado de Líneas de Código distribuídas para el proyecto.Jerarquías de CocomoEl modelo COCOMO básico es un modelo univariable estático que calcula el esfuerzo (y el costo) del desarrollo de software en función del tamaño del programa expresando en líneas de código (LDC) estimadas.COCOMOEl modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de “conductores de costo”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.

75. cocomoEl modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación de impacto de los conductores de costo en cada fase (análisis, diseño, etc.) del proceso de ingeniería de software.

76. Cocomo Orientado a los Tipos de proyecto de software Modelo Orgánico. Proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre el conjunto de requisitos poco rígidos (por ejemplo, un programa de análisis termal desarrollado para un grupo calórico).Cocomo Orientado a los Tipos de proyecto de software Modelo Semiacoplado. Proyectos de software intermedios (en tamaño y complejidad) en los que los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos (por ejemplo, un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de base de datos).

77. Cocomo Orientado a los Tipos de proyecto de software Modelo Empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas (por ejemplo, software de control de navegación para un avión).

79. COCOMOLas ecuaciones son de la forma: PM = a * ( KDSI ) b ; TDEV = c * ( PM ) d Programas de Aplicación: PM = 2.4 * ( KDSI ) 1.05; TDEV = 2.5 * ( PM ) 0.38 Programas de Apoyo: PM = 3.0 * ( KDSI ) 1.12; TDEV = 2.5 * ( PM ) 0.35 Programas de Sistemas: PM = 3.6 * ( KDSI ) 1.20; TDEV = 2.5 * ( PM ) 0.32

80. Calendarización FundamentosLa realidad de un proyecto técnico, tal como uno de software, es que hay que realizar cientos de tareas pequeñas en un orden determinado antes de poder alcanzar la meta final. Las tareas están interrelacionadas en una secuencia lógica en el sentido de que algunas de ellas no pueden empezar hasta que otras se hayan terminado.

81. -76-CalendarioDividir el proyecto en actividades o tareasEstimar el tiempo necesario para realizarlas (algunas se harán en paralelo)Los administradores Coordinan las actividades Organizan el trabajo para optimizar la mano de obraAsignan y planifican recursos (personal, hardware, software, presupuesto para viajes,...)Duración aconsejable de una actividad: entre 1 y 8 semanas

82. -77-Calendario (cont.) Importante tener en cuenta posibles problemas (personal, hardware, software,...) que provocan retrasos.Problemas previstos: incrementar un 30% la estimación inicial.Problemas no previstos: incrementar un 20%.Utilización de diagramas de Gantty redes de actividades

83. Herramientas Automáticas de Calendarización

84. CONSEJOS SOBRE ESTIMACIONES 1. Evite estimaciones improvisadas ( ojo de buen cubero ). 2. Use datos de proyectos anteriores ( método histórico ). 3. Las estimaciones las debe hacer el desarrollador, no el directivo. 4. Estime por concenso ( técnica delfi ). 5. Evite estimar el proyecto como un todo. 6. Estime por descomposición, es decir, estime cada función o requisito del software individualmente. Luego la suma de ellos será la estimación del proyecto total. 7. Utilice diferentes técnicas de estimación, compare los resultados y resuelva las diferencias. 8. Si es posible use una herramienta automática de estimación. Con esto tendrá otro punto de comparación. 9. Refine sus estimaciones a medida que conozca más detalles del proyecto.

85. 10. Emita una estimación preliminar después de revisar la Definición del Sistema. Refinela durante el Análisis y de una estimación definitiva después de revisar el Diseño. Si esto no es posible, trate de emitir su estimación definitiva al terminar el Análisis. Si aún esto no es posible, deberá formularla solo con la Definición del Sistema pero considere un factor de seguridad adecuado. 11. Presente sus estimaciones usando rangos o casos ( mejor, más probable, peor ). 12. Defienda sus estimaciones. Finalmente Ud. y su equipo son los que conocen el proyecto y lo desarrollarán. En lo posible evite que un directivo le imponga una estimación que no esté justificada, para esto debe prepararse para defender sus estimaciones. 13. Negocíe con el cliente.

86. ¿Preguntas?