Скачать презентацию Estimación de costes del software Ian Sommerville 2004 Скачать презентацию Estimación de costes del software Ian Sommerville 2004

acd2a39dd2bf2fe070a52d17343f30dd.ppt

  • Количество слайдов: 58

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

Objetivos l l Introducir las bases del cálculo de precios y costos del software Objetivos l l 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 ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

Preguntas fundamentales de estimación l l Cuánto esfuerzo se requiere para completar una actividad? Preguntas fundamentales de estimación l l 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 ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Parámetros para cálculo de costes del software l l l Costes de hardware y Parámetros para cálculo de costes del software l l l Costes de hardware y software. Costes de viajes y capacitación. Costes de Esfuerzo (el factor dominante en la mayoría de los proyectos) • • l 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. ). ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Cálculos del coste y del precio l l l La estimación se realiza para Cálculos del coste y del precio l l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

Productividad del software l l l Una medida de la velocidad a la cual Productividad del software l l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Medidas de Productividad l l Medidas relacionadas con el tamaño basadas en la salida Medidas de Productividad l 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. 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Problemas de medición l l l Estimar el tamaño de la medida (e. g. Problemas de medición l l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Líneas de código l Qué es una línea de código? • • l l Líneas de código l Qué es una línea de código? • • l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Comparaciones de Productividad l Mientras más bajo sea el lenguaje, más productivo será el Comparaciones de Productividad l Mientras más bajo sea el lenguaje, más productivo será el programador • l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

Puntos de función l Basada en una combinación de características del programa • • Puntos de función l Basada en una combinación de características del programa • • l 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 ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

Puntos objeto l l l Los puntos objeto (también conocidos como puntos de aplicación) Puntos objeto l l l Los puntos objeto (también conocidos como puntos de aplicación) son una medida de puntos de función cuando se utilizan 4 Gls 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; ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Estimación de los puntos objeto l l l Los puntos objeto son más fáciles Estimación de los puntos objeto l l 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. 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

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

Calidad y productividad l l Todas las métricas basadas en volumen/tiempo son ineficaces porque Calidad y productividad l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Técnicas de estimación l No existe una forma simple de realizar una estimación precisa 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 • • • l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Evolución de las Tecnologías l La evolución de las tecnologías podrían significar que las 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Técnicas de estimación l l l Modelado algorítmico de coste. Juicio experto. Estimación por Técnicas de estimación l l l Modelado algorítmico de coste. Juicio experto. Estimación por analogía. Ley de Parkinson. Pricing to win. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

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

Estimación descendente y ascendente l l Cualquiera de estos enfoques puede ser visto de Estimación descendente y ascendente l l Cualquiera de estos enfoques puede ser visto de manera ascendente o descendente Descendente • l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Estimación descendente l l l Se puede usar sin saber la arquitectura del sistema Estimación descendente l l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Estimación ascendente l l l Se puede usar cuando la arquitectura del sistema es Estimación ascendente l l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Métodos de estimación l l l Cada método tiene fortalezas y debilidades. La estimación Métodos de estimación l l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

“Pricing to win” l l Este enfoque puede parecer antiético y poco apropiada para “Pricing to win” l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Modelado algorítmico de costes l El coste se aproxima como una función matemática de 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: • • l l 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. 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Estimación precisa l l El tamaño de un sistema de software sólo puede ser Estimación precisa l l El tamaño de un sistema de software sólo puede ser medido precisamente cuando está terminado. Varios factores influencian el tamaño final • • • l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

El modelo COCOMO l l Es un modelo empírico basado en experiencia de proyectos. El modelo COCOMO l l 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 toma en cuenta diferentes enfoques para desarrollo, reutilización, etc. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

COCOMO 2 l l COCOMO 81 fue desarrollado con la premisa de que el COCOMO 2 l 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. . 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

Uso de modelos de COCOMO 2 ©Ian Sommerville 2004 Software Engineering, 7 th edition. Uso de modelos de COCOMO 2 ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Nivel de construcción de prototipos l l Soporta el prototipado de proyectos y proyectos Nivel de construcción de prototipos l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Productividad punto objeto ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide Productividad punto objeto ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Nivel de diseño inicial l l Las estimaciones pueden realizarse luego de que los Nivel de diseño inicial l l 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ño. B ´ M • 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. • ©Ian Sommerville 2004 donde Software Engineering, 7 th edition. Chapter 26 Slide

Multiplicadores l Los multiplicadores reflejan la capacidad de los desarrolladores, los requerimientos no funcionales, 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Nivel de reutilización l l Toma en cuenta el código de ‘caja negra’ que Nivel de reutilización l 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. 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Estimación de nivel de reutilización 1 l Para código generado: • • PM = 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Estimación de nivel de reutilización 2 l Cuando el código debe ser entendido e 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Nivel de postarquitectura l l Usa la misma fórmula que el nivel de diseño Nivel de postarquitectura l l 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

El término exponencial l l Depende de una escala de 5 factores (ver siguiente El término exponencial l l 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. • • • l Precedentes – nuevo proyecto(4) Flexibilidad de desarrollo – no involucramiento del clientemuy 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

Multiplicadores l Atributos de Producto • l Atributos de la computadora • l Restricciones Multiplicadores l Atributos de Producto • l Atributos de la computadora • l Restricciones impuestas al software por la plataforma hardware. Atributos personales • l Relacionados con las características requeridas del producto de software que está siendo desarrollado. 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 ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

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

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

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

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

Duración del proyecto y reclutamiento l l A parte de la estimación de esfuerzo, Duración del proyecto y reclutamiento l 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. El tiempo calendario puede estimarse usando la fórmula de COCOMO 2 • • l 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. El tiempo requerido es independiente del número de personas trabajando en el proyecto. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

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

Puntos clave l l l No existe una relación simple entre el precio asignado Puntos clave l l l No existe una relación simple entre el precio asignado a un sistema y su costo de desarrollo. 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. El software puede recibir precio para lograr el contrato y la funcionalidad se adecua al precio. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide

Puntos clave l l Se deben usar diferentes técnicas de estimación de costos para Puntos clave l l Se deben usar diferentes técnicas de estimación de costos para estimar un valor adecuado. 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. Los modelos algorítmicos de costo soportan análisis cuantitativos de opción para ser comparados. El tiempo que se necesita para completar el proyecto no es proporcional al número de personas que trabajan en él. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 26 Slide