Capítulo IX.
Estimación de proyectos de Software • Estructura se refiere al grado en el cual se solidificaron los requisitos, la facilidad con la que se
¿Qué es la estimación?
Estimación: “Apreciar, poner precio, evaluar algo”
Estimación de proyectos de software: “Actividad de la planificación del
proyecto de SW que intenta determinar cuánto dinero, esfuerzo, recursos y
tiempo tomará construir un sistema o producto software”.
 «Aplicación continua de técnicas basadas en las medidas de los procesos
de desarrollo del software y sus productos, para producir una información
de gestión significativa y a tiempo.  Esta información se utilizará para
mejorar esos procesos y los productos que se obtienen de ellos» (SYMONS,
C., 1998).
El proceso de estimación: Preguntas fundamentales en la estimación
• ¿Cuánto esfuerzo se requiere para completar una actividad?
• ¿Cuánto tiempo calendario se necesita para completar una actividad?
• ¿Cuál es el costo total de una actividad?
La estimación de proyecto y la creación del calendario son actividades de gestión que se llevan a cabo en
forma conjunta.
 Costos de hardware y software  Costos de viajes, capacitación y entrenamiento  Costos de esfuerzo (el
factor dominante en la mayoría de los proyectos)
• Salarios de los ingenieros involucrados en el proyecto
• Costos de seguros, beneficios sociales, otros.
 Los costos de esfuerzo deberían tomar en cuenta sobrecargas tales como:  Costos de oficina,
climatización, energía eléctrica  Costo de redes y comunicaciones  Costos administrativos varios.
Factores que afectan al precio del software
 De forma clásica, el precio es simplemente el coste más el beneficio.  Sin embargo, la relación entre coste
del proyecto y su precio no es tan simple.
Oportunidad de Mercado: Precios menores para obtener mayor cuota de mercado
Incertidumbre en la Estimación: Si no se puede asegurar la estimación del coste, se puede incrementar el
precio para cubrir contingencias.
Términos contractuales: El precio puede ser menor si el código fuente se lo entrega al cliente.
Volatilidad de Requerimientos: Los cambios de requerimientos posteriores al contrato pueden tener un alto
valor.
Salud Financiera: Si se tiene capacidad instalada fija, se puede tener precios más bajos de los normales.
1. Antecedente de las Estimaciones
 Siempre que se hacen estimaciones se mira hacia el futuro y se acepta cierto grado de incertidumbre
habitual  La estimación de recursos, costo y calendario para un esfuerzo de ingeniería de software requiere
experiencia, acceso a buena información histórica (métricas) y coraje para comprometerse con las
predicciones cuantitativas  La estimación porta un riesgo inherente, y éste conduce a incertidumbre.
 La complejidad del proyecto tiene un fuerte efecto sobre la incertidumbre inherente a la planificación.
• Sin embargo, la complejidad es una medida relativa que es afectada por la familiaridad con el esfuerzo
pasado.
• Es posible establecer valoraciones de complejidad, por ejemplo, los factores de ajuste de complejidad
de punto de función.
El tamaño del proyecto es otro factor importante que puede afectar la precisión y la eficacia de las
estimaciones.
• Conforme aumenta el tamaño, la interdependencia entre varios elementos del software crece
rápidamente.
• El aumento en el tamaño del proyecto puede tener un impacto geométrico sobre el costo y el calendario
del proyecto
El grado de incertidumbre estructural también tiene un efecto sobre el riesgo de estimación.
dividieron las funciones y la naturaleza jerárquica de la información que debe procesarse.
 El riesgo de estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas
para recursos, costo y calendario.
2. El proceso de planificación del proyecto
 El objetivo de la planificación del proyecto de software es proporcionar un marco conceptual que permita
al gerente hacer estimaciones razonables de recursos, costo y calendario.  Además, las estimaciones deben
intentar definir los escenarios de mejor caso y peor caso, de modo que los resultados del proyecto puedan
acotarse.  Aunque hay un grado inherente de incertidumbre, el equipo de software se embarca en un plan
que se haya establecido como consecuencia de dichas tareas.  Por tanto, el plan debe adaptarse y actualizarse
conforme avanza el proyecto
5. Estimación de proyectos de SW
 Demasiadas variables (humanas, técnicas, ambientales, políticas) pueden afectar el costo final del software
y el esfuerzo aplicado para su desarrollo  Sin embargo se pueden elaborar una serie de pasos sistemáticos
que proporcionen estimaciones con riesgo aceptable.
 Algunas opciones podrían ser:
• Retrasar la estimación hasta avanzado el proyecto
• Basar las estimaciones en proyectos similares anteriores
• Usar técnicas de descomposición sencillas
• Usar modelos empíricos
 Las herramientas de estimación automatizadas implementan una o más técnicas de descomposición o
modelos empíricos y proporcionan una atractiva opción para estimar.  Cada una de las opciones de
estimación de costo del software viables sólo es tan buena como los datos históricos usados para generar la
estimación. Si no existen datos históricos, el cálculo descansa sobre un cimiento muy inseguro.
Técnicas de estimación
La opinión de los expertos
 Esta técnica se basa en la experiencia profesional de los participantes en el proyecto de estimación.
La analogía
 Se basa en la comparación directa de uno o más proyectos pasados.  Para poder utilizar esta técnica es
necesario disponer de una base de datos histórica de proyectos finalizados con la que poder realizar la
comparación.  Los proyectos deben tener muchas similitudes en cuanto a su esquema.
La descomposición
 Consiste en la descomposición de un producto en componentes más pequeños, o descomponer un proyecto
en tareas de nivel inferior.  La estimación se hace a partir del esfuerzo requerido para producir los
componentes más pequeños o para realizar las tareas de nivel inferior.
Las ecuaciones de estimación
 Son fórmulas matemáticas que establecen la relación de algunas medidas de entrada (que normalmente es
la medida del tamaño del producto) y determinan el esfuerzo que se requerirá.
Ley de Parkinson
 Establece que el trabajo se extiende para llenar el tiempo disponible. El coste se determinará por los
recursos disponibles más que por los objetivos logrados.
6. Técnica de descomposición
 Desarrollar una estimación de costo y esfuerzo para un proyecto de software es muy complejo como para
considerarse en un solo componente.  Por esta razón, debe descomponerse el problema como un conjunto
de problemas más pequeños (y, esperanzadoramente, más manejables).  Antes de hacer una estimación,
debe entenderse el ámbito del software que se va a construir y generar una estimación de su “tamaño”.
Dimensionamiento de SW
 La precisión de una estimación de proyecto de software se basa en algunas cosas:
1. el grado en el que se estimó adecuadamente el tamaño del producto que se va a construir
2. la habilidad para traducir la estimación de tamaño en esfuerzo humano, tiempo calendario y dinero
3. el grado en el que el plan del proyecto refleja las habilidades del equipo de software y
4. a estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de ingeniería de SW
 El tamaño puede medirse en líneas de código (LOC) o también se puede representar como puntos de confiables. Si, por otra parte, los resultados de dichas técnicas de descomposición muestran poca
función (PF) o basada en procesos.  Cada uno de estos enfoques se pueden combinar estadísticamente para concordancia, debe realizarse mayor investigación y análisis.
crear una estimación de tres puntos o valor esperado.  Esto se logra al desarrollar valores para tamaño Factores que afectan la Productividad en el desarrollo de SW
optimistas (bajos), más probables y pesimistas (altos):  Estas medidas no tienen en cuenta características no funcionales como fiabilidad y mantenimiento.  No
𝑆𝑜𝑝𝑡 + 4𝑆𝑚 + 𝑆𝑝es toman en cuenta la posibilidad de reutilizar el software producido, utilizar generadores de código u otras
𝑆=
6 herramientas de ingeniería.
 S = valor más probable de la estimación (probabilidad Beta). Experiencia en el dominio de aplicación: Conocer el dominio es esencial para el desarrollo efectivo del
Estimación basada en problema (LOC, PF) SW; quienes lo tienen son más productivos.
 Las estimaciones LOC y PF son técnicas de estimación distintas, aunque ambas tienen algunas Calidad del proceso: El proceso de desarrollo utilizado puede tener un efecto importante en la productividad.
características en común.  Comienzan con un enunciado acotado del ámbito del software y a partir Tamaño del proyecto: En un proyecto más grande, se requiere más tiempo de interacción y se dispone de
de este enunciado se descompone en funciones problema que puedan estimarse cada una de manera menos tiempo de desarrollo.
individual.  Las métricas de productividad de referencia (por ejemplo, LOC/pm o PF/pm) se Apoyo tecnológico: La productividad puede mejorar con herramientas tipo CASE, sistemas de gestión de
aplican entonces a la variable de estimación adecuada y se infiere su costo o esfuerzo. configuración, etc.
 Una vez determinado el valor esperado para la variable de estimación se aplican datos de productividad Entorno de trabajo: Un entorno adecuado contribuye a mejorar la productividad
históricos LOC o PF.  ¿Las estimaciones son correctas? La única respuesta razonable a esta pregunta es “no Método de estimación COCOMO
puede estar seguro”. Cualquier técnica de estimación, sin importar su sofisticación, debe verificarse con otro Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COst MOdel)
enfoque. Incluso así, deben prevalecer el sentido común y la experiencia  Es un modelo empírico que se obtuvo recopilando datos de varios proyectos grandes, estos datos fueron
Ej. LOC para el SW Calculadora analizados para descubrir las fórmulas que mejor se ajustaban.  Estas fórmulas vinculan el tamaño del
 Datos históricos de productividad: 520 sistema y del producto, factores del proyecto y del equipo con el esfuerzo necesario para desarrollar el
LOC/pm Tarifa de mano de obra con sistema.
sobrecargas es de 1,500 USD por mes; por Método de estimación COCOMO II
tanto, el costo por línea de código es  Este modelo permite realizar estimaciones en función del tamaño del software, y de un conjunto de factores
aproximadamente 2,89 USD / línea.  Con de costo y de escala.  Los factores de costo describen aspectos relacionados con la naturaleza del producto,
base en la estimación LOC y los datos de hardware utilizado, personal involucrado, y características propias del proyecto.  El conjunto de factores
productividad históricos, el costo de proyecto de escala explica las economías y deseconomías de escala producidas a medida que un proyecto de software
total estimado es 3,795 USD y un esfuerzo estimado de 2.4 persona-mes. incrementa su tamaño.
Ej. PF para el SW Calculadora
 Datos históricos de productividad: 20 PF/pm 
Tarifa de mano de obra con sobrecargas es de 1,500
USD por mes; por tanto, el costo por PF es de
75USD.  Con base en la estimación de PF y los
datos de productividad históricos, el costo de
proyecto total estimado es 7,350 USD y un
esfuerzo estimado de 5 persona-meses.

Estimación basada en proceso

 La técnica más común para estimar un proyecto es basar la estimación sobre el proceso que se usará
(puede ser el ciclo de desarrollo del producto). Es decir, el proceso se descompone en un conjunto
relativamente pequeño de tareas conceptuales y se estima el esfuerzo requerido para lograr cada tarea.
 A esto se combina un delineado de las funciones de software obtenidas del ámbito del proyecto.
 Una vez fusionadas las funciones del problema y las actividades de proceso, se estima el esfuerzo (por
ejemplo, persona-mes) que se requerirá para lograr cada actividad de proceso de software para cada función. Nivel de construcción de prototipos
Ej. Estimación basada en Procesos (meses)  Fue introducido para dar soporte a la estimación del esfuerzo requerido para el prototipado de proyectos y
 Tarifa de mano de obra para proyectos en que el software se desarrolla utilizando componentes existentes.  En este nivel la
con sobrecargas es de reutilización es común.
1,500 USD por mes.  Por
tanto, el costo del proyecto
total estimado es de 13,875
USD.  Si la estimación
basada en proceso se realiza independientemente de la estimación LOC o PF, entonces se tienen dos o tres
estimaciones para costo y esfuerzo que pueden compararse y reconciliarse.  Si ambos conjuntos de
estimaciones muestran concordancia razonable, hay buenas razones para creer que las estimaciones son

Proporciones de productividad para puntos objeto
Nivel de diseño inicial
 Este nivel se utiliza cuando hemos acordado los requerimientos de usuario y se han iniciado las primeras
etapas del proceso de diseño.  La meta de este nivel es hacer una estimación aproximada con un esfuerzo
mensurable.  Se asume que el esfuerzo en integrar código reutilizable es cero.
Nivel de postarquitectura
 Se utiliza una vez que conocemos el diseño arquitectónico del sistema, es decir, cuando conocemos la
estructura de subsistemas.  Las estimaciones producidas en este nivel deben de ser más precisas y utiliza un
conjunto de atributos más extenso para refinar el cálculo de esfuerzo inicial.
Factores de escala
 Factores de escala utilizados en el cálculo del exponente
Precedentes: Refleja la experiencia previa con este tipo de proyectos.
Flexibilidad del desarrollo: Refleja el grado de flexibilidad en el proceso de desarrollo.
Resolución de la arquitectura / riesgo: Refleja la amplitud del análisis de riesgo que se lleva a cabo.
Cohesión del equipo: Refleja cómo de bien se conocen entre sí los miembros del equipo y cómo de bien
trabajan juntos.
Madurez del proceso: Refleja la madurez del proceso de organización.

 El coeficiente A se define como 2,94 (según datos históricos).  Tamaño (KSLOC) es el número de miles
de líneas de código fuente.
• Existe una tabla que relaciona el número de puntos de función y lo convierte a KSLOC, dependiendo
del lenguaje de programación.
 El exponente B es el esfuerzo creciente requerido al incrementarse el tamaño del proyecto.
• Varía de 1,1 hasta 1,24. Depende de la madurez del equipo y de los procesos de desarrollo de la
organización.
 El multiplicador M está basado en un conjunto simplificado de siete características de proyecto y proceso
que influyen en la estimación.
Nivel de diseño inicial
 El multiplicador M está determinado por las siguientes características:
• RCPX: fiabilidad y complejidad del producto
• RUSE: reutilización requerida
• PDIF: dificultad de la plataforma
• PERS: capacidad del personal
• PREX: experiencia del personal
• SCED: cronograma
• FCIL: facilidades de apoyo
 Estos factores se pueden estimar directamente sobre una escala de seis puntos donde 1 corresponde a
valores muy bajos de los multiplicadores y 6 corresponde a valores muy altos. Consideraciones importantes
 El modelo COCOMO II es un modelo bien desarrollado que tiene en cuenta el proyecto, el producto, el
hardware y los atributos del personal.  Uno de los principales factores que afectan la productividad incluyen
Nivel de reutilización la aptitud personal, la experiencia, el proceso de desarrollo, el tamaño del proyecto, la herramienta de apoyo
 Es muy común reutilizar software, los sistemas grandes tienen un porcentaje significativo de código y el entorno de trabajo.  No hay una relación sencilla entre el precio de un sistema y los costes de desarrollo.
reutilizado de otros proyectos anteriores  Este nivel de reutilización se emplea para estimar el esfuerzo  El tiempo requerido para completar un proyecto no es proporcional al número de personas que trabajan en
requerido para integrar código reutilizable y código generado. él.
 Tipo de código reutilizable:
• Código de caja negra.- Puede ser reutilizado sin entender el código ni tener que hacer cambios en él.
• Código de caja blanca.-Ha de ser adaptado para integrarlo con el código nuevo.
 El nivel de reutilización incluye una parte específica para estimar los costes asociados a este código
generado automáticamente

 El modelo de reutilización no es lineal por lo que se necesitará esfuerzo si la reutilización se considera,

como además de una valoración para saber si es posible.