Estimación de costes del software

1. Estimación de costes del software

2. Objetivos • Introducir las bases del cálculo de precios y costos del software • Describir las tres métricas para la valoración de la productividad del software • Explicar porqué diferentes técnicas deberían ser usadas para la estimación del software • Describir los principios del modelo algorítmico de costos COCOMO 2

3. Contenido • Productividad de software • Técnicas de estimación • Modelado algorítmico de costes • Duración y personal del proyecto

4. Preguntas fundamentales de estimación • Cuánto esfuerzo se requiere para completar una actividad? • Cuánto tiempo, de calendario, se necesita para completar una actividad? • Cuál es el coste total de una actividad? • La estimación y creación del calendario son actividades conjuntas

5. Parámetros para cálculo de costes del software • Costes de hardware y software. • Costes de viajes y capacitación. • Costes de Esfuerzo (el factor dominante en la mayoría de los proyectos) • Salarios de los ingenieros envueltos en el proyecto • Gastos sociales y gastos de seguro. • Los costes de esfuerzo deben tomar en cuenta a los gastos generales. • Costes de provisión, aclimatación e iluminación. • Costes de redes y comunicaciones. • Coste de recursos centralizados (e.g bibliotecas, recursos recreativos, restaurantes, etc.).

6. Cálculos del coste y del precio • La estimación se realiza para que el programador pueda descubrir los costes de la producción de un sistema de software. • No hay una relación simple entre el costo de desarrollo y el precio cobrado al cliente. • El precio cobrado es influenciado por consideraciones organizacionales, económicas, políticas y de negocios.

7. Factores para el cálculo de precio del software

8. Productividad del software • Una medida de la velocidad a la cual cada ingeniero involucrado en el desarrollo de software produce software y documentación asociada. • No orientada a la calidad, aunque la garantía de calidad es un factor de la valoración de la productividad. • Básicamente, queremos medir funcionalidades útiles producidas por unidad de tiempo.

9. Medidas de Productividad • Medidas relacionadas con el tamaño basadas en la salida de un proceso de software. Ésta puede ser lineas de código fuente entregado, instrucciones de código objeto, etc. • Medidas relacionadas con la función basadas en un estimado de la funcionalidad del software entregado. Los puntos de función son las medidas más conocidas de este tipo.

10. Problemas de medición • Estimar el tamaño de la medida (e.g. cuántos puntos de función). • Estimar el número total de meses, de programador, que han transcurrido. • Estimar la productividad del contratista (e.g. equipo de documentación) e incorporar este estimado en la estimación general.

11. Líneas de código • Qué es una línea de código? • La medida fue propuesta cuando los programas eran escritos en tarjetas con una línea por tarjeta; • Cómo corresponde esto a las declaraciones, que como en Java pueden abarcar varias líneas o donde pueden existir varias declaraciones en una sola línea. • ¿Qué programas deberían contarse como parte del sistema? • Este modelo asume que hay una relación lineal entre el tamaño del sistema y el volumen de la documentación.

12. Comparaciones de Productividad • Mientras más bajo sea el lenguaje, más productivo será el programador • La misma funcionalidad toma más líneas de código en implementarse en un lenguaje de bajo nivel en comparación a uno de alto nivel. • Mientras más líneas maneje el programador, la productividad será mayor • Medidas de productividad basadas en líneas de código. Sugieren que los programadores que escriben código abundante son más productivos que los que escriben código compacto.

13. Tiempos de desarrollo de software

14. Puntos de función • Basada en una combinación de características del programa • entradas y salidas externas; • interacciones con el usuario; • interfaces externas; • archivos utilizados por el sistemas. • Un peso es asociado a cada uno de éstos y la cuenta de puntos de función es calculada multiplicando el número de elementos de un tipo por el peso y sumándolos

15. Puntos de función • La cuenta de puntos de función (PF) varía en función de la complejidad del proyecto • Los puntos de función pueden usarse para estimar la cantidad de líneas de código (LDC) en función del promedio de LDC por PF en un lenguaje dado • LOC = AVC * número de puntos de función; • AVC es un factor dependiente del lenguaje, variando desde 200 a 300 para lenguaje ensamblador, hasta 2 a 40 para un lenguaje de cuarta generación (4Gls); • Los PF son muy subjetivos, dependen del estimador • La cuenta automática de puntos de función es imposible.

16. Puntos objeto • Los puntos objeto (también conocidos como puntos de aplicación) son una medida de puntos de función cuando se utilizan 4Gls o lenguajes parecidos. • Los puntos objeto NO son lo mismo que las clases de un diseño orientado a objetos. • El número de puntos objeto en un programa es la estimación de: • El número de pantallas independientes que se despliegan; • El número de informes que se producen; • El número de módulos que se deben desarrollar para complementar el código de programación de la base de datos;

17. Estimación de los puntos objeto • Los puntos objeto son más fáciles de estimar desde una especificación, que los puntos de función desde que solo se relacionan con pantallas, reportes y módulos de programas. • Pueden ser estimados en un punto muy temprano del proceso de desarrollo. • En esta etapa es muy difícil estimar el número de líneas de código en un sistema.

18. Estimaciones de productividad • Sistemas embebidos de tiempo real, 40-160 LOC/mes-P. • Programas de sistemas , 150-400 LOC/mes-P. • Aplicaciones comerciales, 200-900 LOC/mes-P. • En los puntos objeto, la productividad ha sido medida entre 4 y 50 puntos objetos/mes dependiendo de las herramientas de apoyo y la capacidad del desarrollador.

19. Factores que afectan la productividad

20. Calidad y productividad • Todas las métricas basadas en volumen/tiempo son ineficaces porque no toman en cuenta a la calidad. • La productividad generalmente puede ser incrementada por el coste de la calidad. • No está claro cómo se relacionan las métricas productividad/calidad. • Si los requerimientos están cambiando constantemente, entonces una perspectiva basada en líneas continuas de código es representativa si el programa no es en sí mismo estático.

21. Técnicas de estimación • No existe una forma simple de realizar una estimación precisa del esfuerzo necesario para desarrollar un sistema de software • Las estimaciones iniciales están basadas en información no adecuada de la definición de los requerimientos del usuario; • El software puede ser ejecutado en computadoras poco familiares o usar nueva tecnología; • Los miembros del proyecto pueden no ser conocidos. • La estimación de coste del proyecto puede ser auto-cumplida • La estimación define el presupuesto y el producto se ajusta para cumplir con éste.

22. Evolución de las Tecnologías • La evolución de las tecnologías podrían significar que las experiencias antiguas de estimación no se aplica a nuevos sistemas • Sistemas orientados a objetos y distribuidos en lugar de sistemas centralizados (mainframes); • Uso de servicios web; • Uso de ERP o sistemas basados en bases de datos; • Uso de paquetes software ajenos en lugar de desarrolllar todo el software propio; • Desarrollo para reutilizar y reutilizando componentes; • Desarrollo usando lenguajes script; • El uso de herramientas CASE y generadores de programa.

23. Técnicas de estimación • Modelado algorítmico de coste. • Juicio experto. • Estimación por analogía. • Ley de Parkinson. • Pricing to win.

24. Técnicas de estimación

25. “Pricing to win” • El proyecto cuesta lo que sea que el cliente tenga para pagar por él. • Ventajas: • Obtienes el contrato. • Desventajas: • La probabilidad de que el cliente tenga lo que quiere es pequeña. Los costos no reflejan el trabajo requerido.

26. Estimación descendente y ascendente • Cualquiera de estos enfoques puede ser visto de manera ascendente o descendente • Descendente • Inicia a nivel de sistema, examina la funcionalidad total del producto y su interacción con los subsistemas. • Ascendente • Inicia al nivel de componentes, se divide en componentes. Estos costes se suman para dar el esfuerzo requerido del desarrollo del sistema completo.

27. Estimación descendente • Se puede usar sin saber la arquitectura del sistema y los componentes que pueden ser parte del sistema. • Toma en cuenta costes como la integración, manejo de configuración y documentación. • Puede subestimar el costo resolviendo el costo de problemas técnicos de baja dificultad.

28. Estimación ascendente • Se puede usar cuando la arquitectura del sistema es conocida y los componentes están identificados. • Puede ser un método preciso si el sistema ha sido diseñado a detalle. • Puede subestimar los costes de actividades al nivel de sistemas tales como la introducción y documentación.

29. Métodos de estimación • Cada método tiene fortalezas y debilidades. • La estimación debería basarse en varios métodos. • Si éstos no devuelven el mismo resultado aproximadamente, entonces no existe suficiente información para hacer una estimación. • Algunas acciones deben ser tomadas para descubrir más y realizar estimaciones más precisas. • A veces, “Pricing to win” es el único método aplicable.

30. “Pricing to win” • Este enfoque puede parecer antiético y poco apropiada para los negocios. • Sin embargo, cuando escasea información detallada puede ser la única estrategia apropiada. • El cálculo de coste del proyecto es acordado sobre una propuesta básica y el desarrollo está restringido por ese coste. • Una especificación detallada puede ser negociada o un enfoque evolutivo puede ser usado para el desarrollo del sistema.

31. Modelado algorítmico de costes • El coste se aproxima como una función matemática de producto, proyecto y procesos. Atributos cuyos valores se estiman por los administradores del proyecto: • Esfuerzo = A ´TamañoB´M • A es una constante que depende de la organización, B refleja el esfuerzo desproporcional para proyectos grandes y M es un multiplicador que refleja a los atributos del producto, del proceso y de la gente. • El atributo de producto más usado para la estimación de coste es el tamaño de código. • Muchos modelos son similares pero usan diferentes valores para A, B and M.

32. Estimación precisa • El tamaño de un sistema de software sólo puede ser medido precisamente cuando está terminado. • Varios factores influencian el tamaño final • El uso de COTS y componentes; • Lenguaje de programación; • Distribución del sistema. • A medida de que el proceso de desarrollar avanza, la estimación del tamaño se vuelve más precisa.

33. Inseguridad Estimada

34. El modelo COCOMO • Es un modelo empírico basado en experiencia de proyectos. • Bien documentado, modelo ‘independiente’ que no está atado a un vendedor de software específico. • Larga historia desde la publicación de su versión inicial en 1981 (COCOMO-81) a través de varias instanciaciones hasta llegar a COCOMO 2. • COCOMO 2 toma en cuenta diferentes enfoques para desarrollo, reutilización, etc.

35. COCOMO 81

36. COCOMO 2 • COCOMO 81 fue desarrollado con la premisa de que el proceso cascada sería usado y que todo el software sería desarrollado desde cero.. • Desde su formulación, han habido muchos cambios en la práctica de la ingeniería de software y COCOMO 2 es diseñado para reunir los diferentes enfoques del desarrollo de software.

37. Modelos de COCOMO 2 • COCOMO 2 incorpora un rango de sub-modelos que producen estimaciones crecientemente detalladas. • Los modelos en COCOMO 2 son: • Nivel de construcción de prototipos. Usado cuando el software está compuesto por partes ya existentes. • Nivel de diseño inicial. Usado cuando los requerimientos están disponibles pero el diseño no ha empezado todavía. • Nivel de reutilización. Usado para calcular el esfuerzo de requerido para integrar componentes reutilizables. • Nivel de postarquitectura. Usado una vez que la arquitectura del sistema ha sido diseñada y se dispone de más información del sistema.

38. Uso de modelos de COCOMO 2

39. Nivel de construcción de prototipos • Soporta el prototipado de proyectos y proyectos donde existe una reutilización extensiva. • Se basa en una estimación estándar de la productividad del desarrollador utilizando puntos objeto/mes. • Toma en cuenta el uso de herramientas CASE. • La fórmula es • PM = ( NAP´(1 - %reutilización/100 ) ) / PROD • PM es el esfuerzo estimado en personas-mes, NAP es el número de puntos de aplicación y PROD es la productividad.

40. Productividad punto objeto

41. Nivel de diseño inicial • Las estimaciones pueden realizarse luego de que los requerimientos han sido acordados. • Está basado en la fórmula estándar para modelos algorítmicos • Esfuerzo = A´TamañoB´M donde • M = PERS ´ RCPX ´ RUSE ´ PDIF ´ PREX ´ FCIL ´ SCED; • A = 2.94 en calibración inicial, Tamaño en KLOC, B varía de 1.1 a 1.24 dependiendo de la novedad del proyecto, desarrollo flexible, enfoques de manejo de riesgos y la madurez del proceso.

42. Multiplicadores • Los multiplicadores reflejan la capacidad de los desarrolladores, los requerimientos no funcionales, la familiaridad con la plataforma de desarrollo, etc. • RCPX – confiabilidad y complejidad del producto; • RUSE –reutilización requerida; • PDIF – dificultad de la plataforma; • PREX – experiencia del personal; • PERS – capacidad del personal; • SCED – agenda requerida; • FCIL – facilidades de apoyo del equipo.

43. Nivel de reutilización • Toma en cuenta el código de ‘caja negra’ que se reutiliza sin cambios y el código que tiene que ser adaptado para integrarse con el nuevo código. • Existen dos versiones: • Reutilización de código de caja negra donde el código no es modificado. Se calcula una estimación de esfuerzo (PM). • Reutilización de código de caja blanca donde el código es modificado. Se calcula una estimación de tamaño equivalente al número de líneas del nuevo código fuente. Luego se ajusta al tamaño estimado de código nuevo.

44. Estimación de nivel de reutilización 1 • Para código generado: • PM = (ASLOC * AT/100)/ATPROD • ASLOC es el número de líneas de código generado. • AT es el porcentaje de código automáticamente generado. • ATPROD es la productividad de los ingenieros al integrar éste código.

45. Estimación de nivel de reutilización 2 • Cuando el código debe ser entendido e integrado: • ESLOC = ASLOC * (1-AT/100) * AAM. • ASLOC y AT como se definieron previamente. • AAM es el multiplicador de ajuste de la adaptación calculado desde los costes de cambio de código reutilizado, los costes de entender cómo integrar el código los costes de la toma de decisiones de reutilización.

46. Nivel de postarquitectura • Usa la misma fórmula que el nivel de diseño inicial pero con 17 multiplicadores asociados en lugar de 7. • El tamaño del código se estima como: • Número de líneas del nuevo código a ser desarrollado; • Estimación del número equivalente de líneas del nuevo código calculado usando el nivel de reutilización; • Un estimado del número de líneas de código que deben ser modificadas de a cuerdo a los cambios dentro de los requerimientos.

47. El término exponencial • Depende de una escala de 5 factores (ver siguiente diapositiva). Su suma/100 se añade a 1.01 • Una compañía enfrenta un proyecto con un nuevo dominio. El cliente no ha definido el proceso que se usará y no ha dado tiempo para un análisis de riesgo. La compañía tiene un nivel 2 de CMM. • Precedentes – nuevo proyecto(4) • Flexibilidad de desarrollo – no involucramiento del cliente- muy alto (1) • Arquitectura/resolución de riesgos – No análisis de riesgos- Muy bajo. (5) • Cohesión del equipo – Nuevo equipo - Nominal (3) • Madurez de proceso – Algo de control - Nominal (3) • Entonces el factor de escala es 1.17.

48. Escala de factores del exponentes

49. Multiplicadores • Atributos de Producto • Relacionados con las características requeridas del producto de software que está siendo desarrollado. • Atributos de la computadora • Restricciones impuestas al software por la plataforma hardware. • Atributos personales • Multiplicadores que toman la experiencia y capacidad de las personas que trabajan en el programa tomado en cuenta. • Atributos del proyecto • Relacionados con las características particulares del desarrollo del proyecto de software

50. Efecto de los conductores de coste