El documento describe varias técnicas para estimar los costos de desarrollo de software, incluyendo modelos algorítmicos, juicio de expertos, estimación por analogía, y la ley de Parkinson. También explica los métodos de estimación bottom-up y top-down, y las métricas como líneas de código, puntos de función y FFP que se pueden usar para estimar el tamaño de un proyecto de software.

1. Metodologías de Análisis Clase 5 – 4/9/2007 Christian Sifaqui

2. Técnicas de estimación de costos Modelos algorítmicos de estimación de costos Juicio experto Estimación por analogía Ley de Parkinson Pricing to win Subasta holandesa/Subasta inglesa

3. Técnicas de estimación de costos Comienza al precio más alto del objeto, el que ningún participante está dispuesto a pagar. Va descendiendo hasta que uno de los participantes anuncia su deseo de pujar. Así obtiene el objeto. Subasta Holandesa Comienza con precio cero y va subiendo. Los participantes comienzan activos deseando comprar a cero. A medida que aumenta el precio, los participantes disminuyen sus demandas. La subasta termina cuando sólo queda un participante activo. Éste es el ganador, paga el precio en el cual el resto de los participantes dejaron de pujar. Subasta Inglesa El costo del software se estima a lo que el cliente tiene disponible para gastar en el proyecto. El esfuerzo estimado depende del presupuesto que el cliente tenga y no de la funcionalidad del software. Pricing to win Esta ley establece que el trabajo se expandirá hasta completar el tiempo disponible. El costo se determina por los recursos disponibles en vez de evaluación objetiva. Si el software se entregará en 12 meses y hay 5 personas disponibles, el esfuerzo requerido se estima en 60 meses-hombre. Ley de Parkinson Esta técnica se aplica cuando otros proyectos en el mismo dominio de aplicación han sido finalizados. El costo del nuevo proyecto se esiam por analogía a estos proyectos finalziados. Estimation por analogía Se consultan algunos expertos en las técnicas de desarrollo de software y el dominio de aplicación propuesto. Ellos estiman el costo del proyecto, estas estimaciones se comparan y discuten. Se itera este proceso de estimación hasta que se logra un acuerdo. Juicio experto Se usa un modelo basado en información histórica de costos que relaciona alguna métrica de software (usualmente su tamaño) al costo del proyecto. Se hace uan estimación de esa métrica y el modelo predice el esfuerzo requerido. Modelos algorítmicos de costos

4. Estimación bottom-up y top-down En algunas de las aproximaciones anteriores se puede usar top-down o bottom-up Top-down - Iniciar a nivel de sistema y estimar la funcionalidad total del sistema y cómo esta se entrega a través de sub-sistemas Bottom-up - iniciar a nivel de componente y estimar el esfuerzo para cada componente. Sume estos esfuerzo para lograr una estimación final

5. Estimación top-down Usable sin conocimiento de la arquitectura del sistema y las componentes podrían ser parte del sistema Toma en cuenta costos como integración, administración de la configuración y documentación Puede olvidar considerar el costo de resolver difíciles problemas técnicos de bajo nivel

6. Estimación bottom-up Usable cuando la arquitectura del sistema es conocida e identificado los componentes Puede ser un método exacto si el sistema ha sido diseñado en detalle Podría olvidar considerar las actividades de costos de nivel de sistema como integración y documentación

7. Métodos de estimación Cada método tiene fortalezas y debilidades La estimación debería estar basada en varios métodos Si no entregan resultados similares, no hay suficiente información disponible para estimar

8. Juicio experto por analogía Expertos comparan el producto a realizar con productos ya realizados Estimaciones pueden guiar a costos incorrectos Expertos pueden recolectar datos inexactos Expertos humanos tienen sesgos Sin embargo, el resultado de una estimación por un grupo amplio de expertos podría ser exacto La técnica Delphi se podría requerir para lograr consenso

9. Modelos de estimación algorítmicos de costos Se usa una métrica del proyecto como entrada a un modelo para calcular costos y duración - un modelo algorítmico es no sesgado y por lo tanto superior a una opinión experta - sin embargo, las estimaciones son sólo tan buenas como las suposiciones de fondo Ejemplos - modelo SLIM - modelo Price S - COCOMO

10. Métricas para el tamaño de un producto - líneas de código (LOC, KDSI, KLOC) - FFP - Puntos de función

11. Líneas de código - métrica alternativa: miles de instrucciones fuente entregadas (KDSI) - código fuente es sólo una pequeña parte del esfuerzo de software - diferentes lenguajes entregan diferentes largos de código - LOC no está definido para lenguajes no-procedurales (LISP o 4GL)

12. Líneas de código - no es claro cómo contar líneas de código - ejecutables - definiciones de datos - comentarios - sentencias de lenguaje de job control - líneas cambiadas y/o borradas - no todo lo escrito se entrega - un generador de reportes, pantallas o GUI puede generar miles de líneas de código en minutos

13. Líneas de código - LOC se conoce exactamente cuando el proyecto finaliza - estimaciones basadas en LOC por lo tanto son poco confiables para iniciar un proceso de estimación, se debe estimar las LOC del producto final y esta estimación LOC se utiliza para estimar el costo del producto (es decir, una estimación basada en una estimación)

14. Líneas de código Paradoja de las métricas de líneas de código ACTIVITY CASE A CASE B ASSEMBLER FORTRAN VERSION VERSION (10,000 LINES) (3,000 LINES) DIFFERENCE -------------- -------------- -------------- Requirements 2 Months 2 Months 0 Design 3 Months 3 Months 0 Coding 10 Months 3 Months - 7 Integration/Test 5 Months 3 Months - 2 User Documentation 2 Months 2 Months 0 Management/Support 3 Months 2 Months - 1 -------------- -------------- -------------- Total 25 Months 15 Months - 10 -------------- -------------- -------------- Total Costs $125,000 $75,000 - $50,000 Cost Per Source Line $12.50 $25.00 + $12.50 Lines Per Person Month 400 200 - 200

15. Métricas para el tamaño de un producto - se han propuesto aproximaciones alternativas para estimar el tamaño de un producto FFP (files, flows y processes) ‘83 Puntos de función ‘79

16. FFP - para estimación de costos de productos de procesamiento de datos de tamaño medio - file: colección de registros lógica o físicamente relacionados permanentemente residentes en el producto (se excluyen archivos de transacción y temporales) - flow: interfaz de datos entre el producto y el ambiente, como una pantalla o un reporte - process: manipulación de datos lógica o aritmética, definida funcionalmente

17. FFP - dado el número de files (Fi), flows (Fl) y processes (Pr) el tamaño (s) y el costo (c) se calculan: s = Fi + Fl + Pr c = d * s d: es una constante de eficiencia o productividad dentro de cada organización esta métrica no incluye bases de datos

18. Puntos de función - método para medir desarrollo de software desde el punto de vista del usuario

19. Puntos de función Entregables conteo total de Unadjusted Function Point Unadjusted Function Point (EI, EO, EQ, ILF, EIF) Value Adjustment Factor (VAF) conteo total de Adjusted Function Point reportes de validación

20. Puntos de función - UFP (unadjusted function point) - funciones de datos: - ILF: internal logical files - EIF: external interface files - funciones transaccionales: - EI: external input - EO: external output - EQ: external inquiries

21. Puntos de función Entradas: Documentación de los objetivos percibidos, problemas y deseos del usuario Documentación recolectada respecto del sistema actual, si es que tal sistema (automático o manual) existiera Cualquier objetivo y restricción refinado para el sistema propuesto Cualquier otra documentación de requerimientos completada a la fecha Formatos y diálogos de pantalla Layouts de reportes Layouts de formularios de ingreso Interfaces con otros sistemas y entre sistemas Modelos de datos lógicos y/o físicos preliminares

22. Puntos de función Paso 1: planificar el conteo de puntos de función (FP) El trabajo de contar FP debiera estar incluido en el plan general del proyecto. Contar FP se debe agendar y planificar. El primer conteo debiera usarse para estimar el tamaño. Se pueden contar FP antes de completar los requerimientos. El conteo de FP inicial debiera estar documentado, para así mantenerlo y actualizarlo. Se puede completar el conteo antes de tener el conjunto completo de requrimientos, pero el conteo de FP debiera completarse después que se hayan finalizado los requerimientos y de nuevo al finalizar la implementación. Después de haber completado el conteo de FP, éste debiera compararse con los valores previos de FP para verificar componentes nuevas o cambiadas. Cada adición al conteo de FP debiera indicar si la actualización se debe a nueva funcionalidad o a una mejora en el conteo.

23. Puntos de función Paso 2: recolectar la documentación Documentación de los objetivos, problemas y necesidades percibidas por el usuario. Documentación recolectada respecto del sistema actual, si es que tal sistema (automático o manual) existiera Cualquier objetivo y restricción refinado para el sistema propuesto Descripción y o modelo del framework general del sistema Cualquier otra documentación de requerimientos completada a la fecha

24. Puntos de función Paso 2: recolectar la documentación Se puede completar un FP más detallado después de análisis y diseño Se recomienda la siguiente documentación durante y después del completar el diseño. Fomatos y diálogos de pantalla Formatos y diálogos de pantalla Layouts de reportes Layouts de formularios de ingreso Interfaces con otros sistemas y entre sistemas Modelos de datos lógicos y/o físicos preliminares Tamaños y formatos de archivos Opciones de menús

25. Puntos de función Paso 3: determinar las 14 características generales del sistema Los grados de influencia varían en un escala de 0 a 5 (sin influencia-influencia fuerte) Fuerte influencia 5 Influencia significativa 4 Influencia promedio 3 Influencia moderada 2 Influencia incidental 1 No presente o sin influencia 0 Influencia al sistema Valor

26. Puntos de función ¿Se diseñó la aplicación para eficiencia al usuario final? End-user efficienciy ¿Qué porcentaje de la información se ingresa en línea? On-line data entry ¿Cuán frecuentemente se ejecutan las transacciones?¿ dirariamente, semanalmente, mensualmente, etc.? Transaction rate ¿Cuánta carga de uso tiene la plataforma de hardware actual donde la aplicación correrá? Heavily used configuration ¿Solicitó el usuario tiempo de respuesta o rendimiento? Performance ¿Cómo son manejados datos y funciones de procesamiento distribuidos? Distributed data processing ¿Cuántos servicios de comunicación existen para ayudar en la transferencia o intercambio de información con la aplicación o sistema? Data communications Breve descripción Característica general del sistema (CGS)

27. Puntos de función ¿Se diseñó, desarrolló y soportó específicamente para facilitar el cambio? Facilitate change ¿Se diseñó, desarrolló y soportó la aplicación para ser instalada en múltiples sitios para múltiples organizaciones? Multiple sites ¿Cuán efectivos o automáticos son los procedimientos de inicio, respaldo y recuperación? Operational ease ¿Cuán difícil es la conversión e instalación? Installation ease ¿Fue desarrollada la aplicación para solucionar las necesidades de uno o más usuarioas? Reusability ¿La aplicación tiene extensivos procesamientos lógicos o matemáticos? Complex processing ¿Cuántos ILFs se actualizan por transacciones en línea? On-line update Breve descripción Característica general del sistema (CGS)

28. Puntos de función Paso 4: inventario de transacciones y archivos External Inputs (EI) External Outputs (EO) External Inquiries (EQ) Internal Logical Files (ILF) External Interface Files (EIF)

29. Puntos de función Paso 4: inventario de transacciones y archivos External Inputs (EI): es un proceso elemental que procesa datos o control de información que proviene desde afuera de la frontera de la aplicación. La primera intención de un EI es mantener uno o más ILF y/o alterar la conducta del sistema ILF A ILF B EI

30. Puntos de función Paso 4: inventario de transacciones y archivos External Outputs (EO): es un proceso elemental que envía datos o información de control afuera de la frontera de la aplicación. La intención primaria de un EO es presentar información a un usuario mediante procesamiento lógico en vez de o adicionalmente a la recuperación de datos o control de información. La lógica de procesamiento debe contener al menos una fórmula matemática o cálculo o crear datos derivados. Un EO también puede mantener uno o más ILFs y/o alterar la conducta del sistema Datos derivados ILF A ILF B EO

31. Puntos de función Paso 4: inventario de transacciones y archivos External Inquiries (EQ): es un proceso elemental que envía datos o información de control afuera de la frontera de la aplicación. La intención primara de un EQ es presentar información a un usuario a través de la recuperación de datos o información de control desde un ILF o EIF. La lógica de proceso no contiene fórmulas matemáticas ni cálculos y no crea datos derivados. Ningún ILF se mantiene durante el procesamiento ni se altera la conducta del sistema ILF A ILF B EQ

32. Puntos de función Paso 4: inventario de transacciones y archivos Internal Logical Files (ILF): es un grupo de datos relacionados lógicamente o de información de control identificable por el usuario mantenida dentro de la frontera de la aplicación External Interface Files (EIF): es un grupo de datos -identificable por el usuario- relacionados lógicamente o de información de control referenciado por la aplicación, pero mantenido dentro de la frontera del sistema por otra aplicación. Esto significa que un EIF en una aplicación debe ser un ILF en otra aplicación

33. Puntos de función Paso 5: clasificación de componentes Clasificar cada función como de nivel de complejidad baja, promedio o alta, dependiendo del número de tipo de elementos de datos contenidos y el número de tipos de archivos referenciados Alto Alto Promedio 6+ Alto Promedio Bajo 2-5 Promedio Bajo Bajo 1 51+ 20-50 1-19 Elementos de datos Elementos de registro Para ILF e EIF

34. Puntos de función Paso 5: clasificación de componentes Alto Alto Promedio 4+ Alto Promedio Bajo 2-3 Promedio Alto Alto 0 ó 1 20+ 6-19 1-5 Elementos de datos Tipos de Archivos Para EO y EQ

35. Puntos de función Paso 5: clasificación de componentes Alto Alto Promedio 4+ Alto Promedio Bajo 2-3 Promedio Bajo Bajo 0 ó 1 16+ 5-15 1-4 Elementos de datos Tipos de archivos Para EI

36. Puntos de función Paso 6: determinar el value adjustment factor (VAF) - los 14 CGS se deben revisar para asegurar exactitud (a cada CGS se le asigna un valor entre 0 a 5) - sumar todos los resultados de los CSG, dividir ese número por 100 y sumarle 0,65 - es importante revisar los CSG y VAF, ya que su influencia es de ± 35% en el conteo de FP 0,65 ≤ VAF ≤ 1,35

37. Puntos de función Paso 7: tabular los resultados VAF * UFP Total Adjusted Function Points (FP) Multiplied Value Adjustement Factor (VAF) Número total de Unajusted Function Points (UFP) * 10 = * 7 = * 5 = External Interface Files (EIF) * 15 = * 10 = * 7 = Internal Logical Files (ILF) * 6 = * 4 = * 3 = External Inquiries (EQ) * 7= * 5 = * 4 = External Outputs (EO) * 6 = * 4 = * 3 = External Inputs (EI) Total Alto Promedio Bajo Complejidad de componentes Tipo de componente

38. Puntos de función Paso 8: validar los resultados Los resultados del conteo de FP deben ser revisados por el equipo entero del proyecto y validado por el coordinador de métricas. Las grandes fuentes de errores en el análisis de FP son errores de omisión. Otros errores surgen cuando construcciones físicas se sustituyen por construciones lógicas y son contadas como componentes. El equipo del proyecto debe revisar el análisis de FP por completitud y debe verificar que todos los componentes (EI, EO, EQ, ILF, and EIF) se han incluido. El coordinador de métricas debe trabajar con el contador de FP para asegurar que el proceso ha sido seguido apropiadamente y se ha seguido el proceso de validación. Los conteos de FP completados antes del diseño deben ser comparados a los conteos de FP después del diseño completo. Esto será un indicador de cuánto ha crecido la aplicación desde los requerimientos. La documentación recomendada al final del proyecto o en la implementación del proyecto debe incluir toda la documentacion mencionada o cualquier documentación adicional del sistema.

39. Puntos de función Los puntos de función son mejores que los KDSI, pero hay problemas “ Errors in excess of 800% counting KDSI, but only 200% in counting function points”, Jones ’87

40. Puntos de función La validez económica de la métrica de punto de función ACTIVITY CASE A CASE B ASSEMBLER FORTRAN VERSION VERSION (30 F.P.) (30 F.P.) DIFFERENCE -------------- -------------- -------------- Requirements 2 Months 2 Months 0 Design 3 Months 3 Months 0 Coding 10 Months 3 Months - 7 Integration/Test 5 Months 3 Months - 2 User Documentation 2 Months 2 Months 0 Management/Support 3 Months 2 Months - 1 -------------- -------------- -------------- Total 25 Months 15 Months - 10 -------------- -------------- -------------- Total Costs $125,000 $75,000 - $50,000 Cost Per F.P. $4,166.67 $2,500.00 - $1,666.67 F.P. Per Person Month 1.2 2.0 + 0.8

41. Análisis de puntos de función Como FFP, la mantención puede medirse en forma inexacta Es posible hacer cambios grandes sin cambiar el número de archivos, flujos y processes el número de EI, EO, EQ, ILF, EIF En teoría, es posible cambiar cada línea de código sin cambiar el número de líneas de código

42. Otros MkII FPA, ISO/IEC 20968:2002(E) COSMIC-FFP, ISO/IEC 19761:2003

43. Modelos algorítmicos de costos Costo se estima como una función matemática de atributos del producto, proyecto y proceso Esfuerzo = A * Tamaño B * M A es una constante dependiente de la organización, B refleja el esfuerzo desproporcionado para proyecto grandes y M es un multiplicador que refleja atributos del producto, proceso y personas El atributo más usado para estimación de costos es tamaño del código

44. Modelos de estimación de costos Clasificación de V. R. Basili (‘80s) Modelo Dinámico Estático Una variable Multivariable Guiado por tabla ajustada Línea base ajustada

45. Modelos estáticos: una variable Modelo SEL, Universidad de Maryland (‘80) Esfuerzo = 1,4 L 0,93 [H-M] Documentación = 30,4 L 0,90 [página] Duración = 4,6 L 0,26 [mes] L = número de líneas de código fuente (en miles)

46. Modelos estáticos: multivariable Walston-Felix, IBM (‘77) Esfuerzo = 5,2 L 0,91 [H-M] Duración = 4,1 L 0,36 [mes] L = KLOC entregadas A estas ecuaciones se les asocia un método para estimar la productividad, este índice usa 29 variables

47. Modelos estáticos: multivariable I = índice productividad W i = peso para la variable X i X i = {-1,0,1} si decrementa, no tiene efecto o incrementa la productividad. Esto se aplica a la ecuación de esfuerzo y refina la estimación

48. Modelos estáticos: multivariable Otros COCOMO Dot y Associates Model GRC …

49. Modelos dinámicos, multivariable Putnam’78: relaciona tamaño, tiempo y costo en la ecuación de software Parr’80

50. El modelo COCOMO Boehm’s COnstructive COst MOdel es un modelo empírico basado en experiencia de proyectos tiene una larga historia desde la versión publicada en 1981 (COCOMO 81) hasta COCOMO II. COCOMO II toma en cuenta diferentes aproximaciones respecto del desarrollo de software, reuso, etc.

51. COCOMO 81 Es un modelo que apoya en la planificación de presupuesto y cronograma, antes de iniciar el trabajo Es un modelo no lineal de una variable esfuerzo = a * TAMAÑO b tiempo = c * esfuerzo d

52. COCOMO 81 Esfuerzo se entrega en unidades [H-M], es decir el número de meses que una persona necesitaría para desarrollar el proyecto Tipos: Básico Intermedio Detallado

53. COCOMO 81 básico Estima rápida y burdamente proyectos pequeños a medianos 3 modos: orgánico semi-desconectado empotrado

54. COCOMO 81 básico orgánico programadores expertos desarrollan software en ambiente familiar E m = 2,4 L k 1,05 [H-M] t d = 2,5 E m 0,38 [mes] L k = miles de líneas fuente entregadas

55. COCOMO 81 básico semi-desconectado mezcla de gente experta e inexperta E m = 3,0 L k 1,12 [H-M] t d = 2,5 E m 0,35 [mes]

56. COCOMO 81 básico empotrado hay fuertes restricciones (procesador y hardware) y no han habido proyectos anteriores comparables E m = 3,6 L k 1,20 [H-M] t d = 2,5 E m 0,32 [mes]

57. COCOMO 81 básico promedio de personas E m / t d

58. COCOMO 81 intermedio E n , esfuerzo nominal Orgánico E n = 3,2 L k 1,05 [H-M] Semi-desconectado E n = 3,0 L k 1,12 [H-M] Empotrado E n = 2,8 L k 1,20 [H-M] 15 multiplicadores de esfuerzo afectan E n entregando E t t d = 2,5 E t 0,32

59. COCOMO 81 intermedio Ejemplo Un sistema de comunicaciones hecho en microprocesadores en red y como requerimientos de desarrollo, rendimiento e interfaces  modo empotrado 10000 líneas de código fuente entregadas  10 KDSI Esfuerzo nominal: E n = 2,8 (10) 1,20 = 44 [H-M] E t = E n * (multiplicadores de esfuerzo)

60. COCOMO 81 intermedio multiplicadores de esfuerzo Atributos del producto: restricciones y requerimientos para el proyecto confiabilidad requerida del software (RELY) tamaño de la base de datos (DATA) complejidad del producto (CPLX)

61. COCOMO 81 intermedio multiplicadores de esfuerzo Atributos del computador: limitaciones del hardware y sistema operativo restricción del tiempo de ejecución (TIME) restricción de almacenamiento principal (STOR) volatilidad de la máquina virtual (VIRT) tiempo turnaround del computador (TURN)

62. COCOMO 81 intermedio multiplicadores de esfuerzo Atributos del personal: nivel de habilidad capacidades de analista (ACAP) experiencia en aplicaciones (AEXP) capacidades de programador (PCAP) experiencia en máquina virtual (VEXP) experiencia en lenguaje de programación (LEXP)

63. COCOMO 81 intermedio multiplicadores de esfuerzo Atributos del proyecto: restricciones y condiciones respecto del desarrollo del proyecto prácticas modernas de programación (MODP) uso de herramientas de software (TOOL) cronograma de desarrollo requerido (SCED)

64. COCOMO 81 intermedio Estos 15 multiplicadores se clasifican como muy bajo, bajo, nominal, alto, muy alto y extra alto. Una valor menor que 1 puede decrementar el cronograma y esfuerzo, un valor mayor que 1 extiende el cronograma o esfuerzo.

65. COCOMO 81 intermedio multiplicadores de esfuerzo 1.10 1.04 1.00 1.08 1.23 SCED 0.83 0.91 1.00 1.10 1.24 TOOL 0.82 0.91 1.00 1.10 1.24 MODP 0.95 1.00 1.07 1.14 LEXP 0.90 1.00 1.10 1.21 VEXP 0.70 0.86 1.00 1.17 1.42 PCAP 0.82 0.91 1.00 1.13 1.29 AEXP 0.71 0.86 1.00 1.19 1.46 ACAP 1.15 1.07 1.00 0.87 TURN 1.30 1.15 1.00 0.87 VIRT 1.56 1.21 1.06 1.00 STOR 1.66 1.30 1.11 1.00 TIME 1.65 1.30 1.15 1.00 0.85 0.70 CPLX 1.16 1.08 1.00 0.94 DATA 1.40 1.15 1.00 0.88 0.75 RELY Extra alto Muy alto Alto Nominal Bajo Muy bajo

66. COCOMO 81 intermedio Ejemplo Esfuerzo nominal: E n = 2,8 (10) 1,20 = 44 [H-M] E t = E n * multiplicadores E t = 44 * 1,35 = 59 [H-M] t d = 2,5 E t 0,32 = 9,21 [M] Multiplicador Rating Situación Costo 1,35 TOTAL . . . . . . . . . . . . 1,30 muy alto Procesamiento de comunicaciones Complejidad producto 0,94 bajo 20.000 bytes Tamaño de la base de datos 1,15 Alto Serias consecuencias financieras o fallas de software Configuración del software requerido

67. COCOMO 81 detallado No se verá