©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 1 Estimación de costes del software.

Presentación del tema: "©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 1 Estimación de costes del software."— Transcripción de la presentación:

1 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 1 Estimación de costes del software

2 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 2 Objetivos l Introducir las bases del cálculo de precios y costos del software l Describir las tres métricas para la valoración de la productividad del software l Explicar porqué diferentes técnicas deberían ser usadas para la estimación del software l Describir los principios del modelo algorítmico de costos COCOMO 2

3 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 3 Contenido l Productividad de software l Técnicas de estimación l Modelado algorítmico de costes l Duración y personal del proyecto

4 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 4 Preguntas fundamentales de estimación l Cuánto esfuerzo se requiere para completar una actividad? l Cuánto tiempo, de calendario, se necesita para completar una actividad? l Cuál es el coste total de una actividad? l La estimación y creación del calendario son actividades conjuntas

5 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 5 Parámetros para cálculo de costes del software l Costes de hardware y software. l Costes de viajes y capacitación. l 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. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 6 Cálculos del coste y del precio l La estimación se realiza para que el programador pueda descubrir los costes de la producción de un sistema de software. l No hay una relación simple entre el costo de desarrollo y el precio cobrado al cliente. l El precio cobrado es influenciado por consideraciones organizacionales, económicas, políticas y de negocios.

7 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 7 Factores para el cálculo de precio del software

8 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 8 l Una medida de la velocidad a la cual cada ingeniero involucrado en el desarrollo de software produce software y documentación asociada. l No orientada a la calidad, aunque la garantía de calidad es un factor de la valoración de la productividad. l Básicamente, queremos medir funcionalidades útiles producidas por unidad de tiempo. Productividad del software

9 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 9 l 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. l 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. Medidas de Productividad

10 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 10 l Estimar el tamaño de la medida (e.g. cuántos puntos de función). l Estimar el número total de meses, de programador, que han transcurrido. l Estimar la productividad del contratista (e.g. equipo de documentación) e incorporar este estimado en la estimación general. Problemas de medición

11 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 11 l 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. l ¿Qué programas deberían contarse como parte del sistema? l Este modelo asume que hay una relación lineal entre el tamaño del sistema y el volumen de la documentación. Líneas de código

12 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 12 l 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. l 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. Comparaciones de Productividad

13 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 13 Tiempos de desarrollo de software

14 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 14 Puntos de función l 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. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 15 Puntos de función l La cuenta de puntos de función (PF) varía en función de la complejidad del proyecto l 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); l Los PF son muy subjetivos, dependen del estimador La cuenta automática de puntos de función es imposible.

16 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 16 Puntos objeto l 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. l Los puntos objeto NO son lo mismo que las clases de un diseño orientado a objetos. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 17 Estimación de los puntos objeto l 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. l Pueden ser estimados en un punto muy temprano del proceso de desarrollo. l En esta etapa es muy difícil estimar el número de líneas de código en un sistema.

18 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 18 l Sistemas embebidos de tiempo real, 40-160 LOC/mes-P. l Programas de sistemas, 150-400 LOC/mes- P. l Aplicaciones comerciales, 200-900 LOC/mes-P. l 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. Estimaciones de productividad

19 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 19 Factores que afectan la productividad

20 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 20 l Todas las métricas basadas en volumen/tiempo son ineficaces porque no toman en cuenta a la calidad. l La productividad generalmente puede ser incrementada por el coste de la calidad. l No está claro cómo se relacionan las métricas productividad/calidad. l 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. Calidad y productividad

21 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 21 Técnicas de estimación l 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. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 22 Evolución de las Tecnologías l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 23 Técnicas de estimación l Modelado algorítmico de coste. l Juicio experto. l Estimación por analogía. l Ley de Parkinson. l Pricing to win.

24 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 24 Técnicas de estimación

25 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 25 “Pricing to win” l El proyecto cuesta lo que sea que el cliente tenga para pagar por él. l Ventajas: Obtienes el contrato. l Desventajas: La probabilidad de que el cliente tenga lo que quiere es pequeña. Los costos no reflejan el trabajo requerido.

26 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 26 Estimación descendente y ascendente l Cualquiera de estos enfoques puede ser visto de manera ascendente o descendente l Descendente Inicia a nivel de sistema, examina la funcionalidad total del producto y su interacción con los subsistemas. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 27 Estimación descendente l Se puede usar sin saber la arquitectura del sistema y los componentes que pueden ser parte del sistema. l Toma en cuenta costes como la integración, manejo de configuración y documentación. l Puede subestimar el costo resolviendo el costo de problemas técnicos de baja dificultad.

28 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 28 Estimación ascendente l Se puede usar cuando la arquitectura del sistema es conocida y los componentes están identificados. l Puede ser un método preciso si el sistema ha sido diseñado a detalle. l Puede subestimar los costes de actividades al nivel de sistemas tales como la introducción y documentación.

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

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

31 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 31 Modelado algorítmico de costes l 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ño B  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. l El atributo de producto más usado para la estimación de coste es el tamaño de código. l Muchos modelos son similares pero usan diferentes valores para A, B and M.

32 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 32 Estimación precisa l El tamaño de un sistema de software sólo puede ser medido precisamente cuando está terminado. l Varios factores influencian el tamaño final El uso de COTS y componentes; Lenguaje de programación; Distribución del sistema. l A medida de que el proceso de desarrollar avanza, la estimación del tamaño se vuelve más precisa.

33 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 33 Inseguridad Estimada

34 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 34 El modelo COCOMO l Es un modelo empírico basado en experiencia de proyectos. l Bien documentado, modelo ‘independiente’ que no está atado a un vendedor de software específico. l 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. l COCOMO 2 toma en cuenta diferentes enfoques para desarrollo, reutilización, etc.

35 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 35 COCOMO 81

36 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 36 COCOMO 2 l 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.. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 37 Modelos de COCOMO 2 l COCOMO 2 incorpora un rango de sub-modelos que producen estimaciones crecientemente detalladas. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 38 Uso de modelos de COCOMO 2

39 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 39 Nivel de construcción de prototipos l Soporta el prototipado de proyectos y proyectos donde existe una reutilización extensiva. l Se basa en una estimación estándar de la productividad del desarrollador utilizando puntos objeto/mes. l Toma en cuenta el uso de herramientas CASE. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 40 Productividad punto objeto

41 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 41 Nivel de diseño inicial l Las estimaciones pueden realizarse luego de que los requerimientos han sido acordados. l Está basado en la fórmula estándar para modelos algorítmicos Esfuerzo = A  Tamaño B  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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 42 Multiplicadores l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 43 Nivel de reutilización l 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. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 44 Estimación de nivel de reutilización 1 l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 45 Estimación de nivel de reutilización 2 l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 46 Nivel de postarquitectura l Usa la misma fórmula que el nivel de diseño inicial pero con 17 multiplicadores asociados en lugar de 7. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 47 l Depende de una escala de 5 factores (ver siguiente diapositiva). Su suma/100 se añade a 1.01 l 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) l Entonces el factor de escala es 1.17. El término exponencial

48 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 48 Escala de factores del exponentes

49 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 49 l Atributos de Producto Relacionados con las características requeridas del producto de software que está siendo desarrollado. l Atributos de la computadora Restricciones impuestas al software por la plataforma hardware. l Atributos personales Multiplicadores que toman la experiencia y capacidad de las personas que trabajan en el programa tomado en cuenta. l Atributos del proyecto Relacionados con las características particulares del desarrollo del proyecto de software Multiplicadores

50 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 50 Efecto de los conductores de coste

51 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 51 l Modelos algorítmicos de coste proveen bases para la planeación de proyectos al permitir la comparación de estrategias alternativas l Sistema embebido de una nave espacial Debe ser fiable; Debe minimizar peso (número de chips); La restricción de los multiplicadores de confiabilidad y computadora debe ser > 1. l Componentes de coste Hardware objetivo; Plataforma de desarrollo; Esfuerzo de desarrollo. Planeación de Proyecto

52 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 52 Opciones de Administración

53 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 53 Coste de opciones de administración

54 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 54 Selección de opción l Opción D (usar personal con más experiencia) parece ser la mejor alternativa. Sin embargo, tiene un riesgo asociado alto que representa la dificultad de encontrarlo. l Opción C (actualizar la memoria) tiene un ahorro de costo más bajo, pero también un bajo riesgo. l En general, el modelo muestra la importancia de la experiencia del personal en el desarrollo de software.

55 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 55 Duración del proyecto y reclutamiento l A parte de la estimación de esfuerzo, los administradores deben estimar el tiempo calendario requerido para completar el proyecto y cuándo se necesitará al personal. l El tiempo calendario puede estimarse usando la fórmula de COCOMO 2 TDEV = 3  (PM) (0.33+0.2*(B-1.01)) PM es el cálculo de esfuerzo y B es el exponente calculado como se explicó anteriormente (B es 1 para el nivel de diseño inicial). Este cálculo predice el calendario nominal para el proyecto. l El tiempo requerido es independiente del número de personas trabajando en el proyecto.

56 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 56 Requerimientos para la selección de personal l El personal requerido no puede ser calculado dividiendo el tiempo de desarrollo entre el tiempo requerido en el calendario. l El número de personas trabajando en un proyecto varía dependiendo de la fase del proyecto. l Mientras más gente trabaje en el proyecto, más esfuerzo será requerido normalmente. l Una rápida acumulación de personal se correlaciona con la ralentización del horario.

57 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 57 Puntos clave l No existe una relación simple entre el precio asignado a un sistema y su costo de desarrollo. l Los factores que afectan a la productividad incluyen aptitud individual, experiencia en el dominio, el desarrollo del proyecto, el tamaño del proyecto, las herramientas de soporte y el ambiente de trabajo. l El software puede recibir precio para lograr el contrato y la funcionalidad se adecua al precio.

58 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 58 Puntos clave l Se deben usar diferentes técnicas de estimación de costos para estimar un valor adecuado. l El modelo de COCOMO toma en cuenta a los atributos del proyecto, del producto, del personal y del hardware al momento de predecir el esfuerzo necesario. l Los modelos algorítmicos de costo soportan análisis cuantitativos de opción para ser comparados. l El tiempo que se necesita para completar el proyecto no es proporcional al número de personas que trabajan en él.