Estimación de costes del software

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

Estimación de costes del software


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


Contenido

l Productividad de softwarel Técnicas de estimaciónl Modelado algorítmico de costesl Duración y personal del proyecto


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


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.).


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.


Factores para el cálculo de precio del software


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


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


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


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


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


Tiempos de desarrollo de software


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


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.


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;


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.


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


Factores que afectan la productividad


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


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.


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.



l Modelado algorítmico de coste.l Juicio experto.l Estimación por analogía.l Ley de Parkinson.l Pricing to win.


“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.


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.


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.


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.


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.


“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.


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ñ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.

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.


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.


Inseguridad Estimada


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.


COCOMO 81


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.


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.


Uso de modelos de COCOMO 2


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.


Productividad punto objeto


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ñ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.


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.


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.


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.


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.


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.


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


Escala de factores del exponentes


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


Efecto de los conductores de coste

Valor del exponent 1.17 Tamaño del sistema (incluyendo factores para reutilización y la volatilidad de los requerimientos)

128, 000 DSI

Estimación inicial COCOMO sin conductores de coste

730 personas-mes

Fiabilidad Muy alto, multiplicador = 1.39 Complejidad Muy alto, multiplicador = 1.3 Restricciones de memoria Alto, multiplicador = 1.21 Utilización de herramientas Bajo, multiplicador = 1.12 Calendario Acelerado, multiplicador = 1.29 Estimación ajustada de COCOMO 2306 personas-mes

Fiabilidad Muy bajo, multiplicador = 0.75 Complejidad Muy bajo, multiplicador = 0.75 Restricciones de memoria Ninguna, multiplicador = 1 Utilización de herramientas Muy alto, multiplicador = 0.72 Calendario Normal, multiplicador = 1 Estimación ajustada de COCOMO 295 personas-mes


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


Opciones de Administración


Coste de opciones de administración

Opción RELY STOR TIME TOOLS LTEX Esfuerzo total

Coste del Software

Coste del hardware

Total coste

A 1.39 1.06 1.11 0.86 1 63 949393 100000 1049393

B 1.39 1 1 1.12 1.22 88 1313550 120000 1402025

C 1.39 1 1.11 0.86 1 60 895653 105000 1000653

D 1.39 1.06 1.11 0.86 0.84 51 769008 100000 897490

E 1.39 1 1 0.72 1.22 56 844425 220000 1044159

F 1.39 1 1 1.12 0.84 57 851180 120000 1002706


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.


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.


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.


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.


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.

Estimación de costes del software

Documents

Transcript of Estimación de costes del software