©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 1
Estimación de costes del software
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 3
Contenido
l Productividad de softwarel Técnicas de estimaciónl Modelado algorítmico de costesl Duración y personal del proyecto
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software 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.).
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 7
Factores para el cálculo de precio del software
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 13
Tiempos de desarrollo de software
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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;
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 19
Factores que afectan la productividad
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 24
Técnicas de estimación
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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ñ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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 33
Inseguridad Estimada
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 35
COCOMO 81
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 38
Uso de modelos de COCOMO 2
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 40
Productividad punto objeto
©Ian Sommerville 2004 Software 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ñ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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 48
Escala de factores del exponentes
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 50
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
©Ian Sommerville 2004 Software 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
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 52
Opciones de Administración
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 53
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
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.
©Ian Sommerville 2004 Software 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.