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 SOFTWARE JENNIFER ANDREA CANO GUEVARA INGENIERIA DE SISTEMAS

2. La Estimación No 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 estimar La 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ón Un 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 software 1. 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ón La 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 Software Podemos 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 METRICAS MÉ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 METRICAS MÉ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 METRICAS MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso por el cual se desarrolla.

19. Métricas del Software Métricas Orientadas al tamaño Medidas directas del resultado y del proceso Métricas Orientadas a la función Medidas indirectas del software y del proceso

20. Métricas orientadas al tamaño Páginas de documentación Esfuerzo humano (persona - mes) N° de errores LDC N° de defectos Coste (USD) Productividad =KLDC / persona-mes Calidad =N° de errores (defectos) / KLDC Coste medio =USD / KLDC Documentación =KLDC / persona-mes

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

23. Coste medio = Dólares / KLDC

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

26. METRICA LDC Desventajas: 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: 4600 más probable: 6900 pesimista: 8600 descomposición de funciones VE = (Sopt + 4Sm + Spes)/6 Datos históricos: productividad media de la organización en proyectos similares: 620 LDC/pm Tarifa laboral: 8000 $ /mes Coste LDC:$ 13 ($12.90) Función LDC estimada IUFC 2300 AG2D 5300 AG3D 6800 GBD 3350 FIG 4950 CP 2100 MAD 8400 Total33200 métricas de proyectos anteriores Coste total proyecto:$431.600 Esfuerzo estimado: 54 personas-mes

28. Métricas orientadas a la función consultas salidas Ficheros logicos internos PF entradas Ficheros de interfaz

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

30. Entradas Informaciones 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. Salidas Informaciones 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. Consultas Entradas que producen inmediatamente una salida No modifica los datos del sistema 4. Apendice, Métrica de los puntos de función. 31

34. 4. Apendice, Métrica de los puntos de función. 32 Clasificación de las consultas Calculamos la complejidad de la parte de entrada Calculamos la complejidad de la parte de salida Nos quedamos sólo con la complejidad mayor de las dos.

35. Ficheros Lógicos o Internos 4. Apendice, Métrica de los puntos de función. 33 Agrupaciones de datos, tal y como los percibe el usuario Es diferente de: Entidades y Relaciones Tablas o archivos resultantes del diseño físico Los 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 Interfaz Ficheros a los que accede la aplicación con el único objetivo de obtener información. Son mantenidos por otras aplicaciones Nunca los actualiza la aplicación. 4. Apendice, Métrica de los puntos de función. 35 DIAGRAMA DE CONTEXTO

38. Clasificación de los Ficheros de Interfaz

39. TABLA PARA CALCULAR PUNTOS DED FUNCION

40. FACTORES DE COMPLEJIDAD Son 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 5 0- 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ón PF = cuentatotalX [0,65 + 0,01 * Sumatoria (Fi) ] Punto de función Sumatoria total resultante de la ejecutar las operaciones en la tabla siguiente En 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 ≈ 56 Donde 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 4 Comunicaciones 2 Proceso distribuido 0 Rendimiento crítico 4 Entorno operativo existente 3 Entrada de datos online 4 Transacciones entrada en varias pant. 5 Archivos maestros actualizados online 3 Complejidad valores dominio información 5 Complejidad procesamiento interno 5 Código diseñado para reutilización 4 Conversión en diseño 3 Instalaciones múltiples 5 Aplicación diseñada para cambios 5 PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi) PF estimado = 372 Coste total proyecto:$ 457.843 Esfuerzo estimado: 58 personas-mes Datos históricos: productividad media de la organización en proyectos similares: 6,5 PF/pm Tarifa laboral:8000 $ /mes Coste por PF:$ 1.230 ($1230,76) métricas de proyectos anteriores

45. 4. Apendice, Métrica de los puntos de función. 43 UTILIDADES 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 EXPERTO Ventajas 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. DELFI 3. 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 JONES La 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 ITERATIVA 1.- 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 ITERATIVA 2.- 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 ITERATIVA 3.- 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 ITERATIVA 4.- 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 ITERATIVA 5.- 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 ITERATIVA 6.- 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:

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

75. cocomo El 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.

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. COCOMO Las 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 Fundamentos La 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- Calendario Dividir el proyecto en actividades o tareas Estimar el tiempo necesario para realizarlas (algunas se harán en paralelo) Los administradores Coordinan las actividades Organizan el trabajo para optimizar la mano de obra Asignan 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?