Estimación

• Al principio, el coste del software constituía un pequeño

porcentaje del coste total de los sistemas informáticos.

• Hoy el software es el elemento más caro de la mayoría de los

sistemas.

• Un error en la estimación puede marcar la diferencia entre

beneficios y pérdidas.

• En un proyecto se estiman fundamentalmente tres elementos:

– Costes
– Recursos
– Agendas

• Estimar no es una ciencia exacta y por tanto implica un asumir

riesgos. Los factores que aumentan el riesgo son:
– La complejidad del proyecto
– El tamaño del proyecto
– Estructuración del proyecto

• Los factores que permiten reducir el riesgo son:

– Una buena base histórica
– Experiencia
– Uso de medidas cuantitativas

• Es necesario realizar estimaciones con un grado de riesgo

aceptable. I-3-1
 Diferentes opciones de estimación

• Existen varias posibilidades para estimar:

– Dejar la estimación para más adelante.
– Utilizar técnicas de descomposición.
– Desarrollar métodos empíricos.
– Adquirir una o varias herramientas automáticas de
estimación.

• Desde un punto de vista ideal se deberían aplicar las tres últimas

opciones conjuntamente.

• La técnica de descomposición utiliza un enfoque divide y

vencerás, descomponiendo el proyecto en sus funciones y
estimando estas.

• Todos los modelos empíricos se basan en la experiencia (datos

históricos) y toman como base:
d = f(vi)
– Donde d es el valor estimado y vi son parámetros
independientes.

• Las herramientas automáticas implementan una o varias técnicas

de descomposición o modelo empíricos.

• Cada una de las opciones viables para la estimación sólo será

buena si los datos históricos que se utilizan son buenos.

I-3-2
 Técnicas de descomposición

• Consiste en dividir el problema en subproblemas más pequeños

y abordables.

• Tanto las líneas de código (LDC) como los puntos de función

(PF) son datos básicos a partir de los cuales se pueden obtener
métricas de productividad.

• Los datos de LDC y PF se emplean de dos formas en la

estimación:
– Como variables de estimación.
– Como métricas de base recogidas de anteriores proyectos.

1. A partir de una declaración restringida del ámbito del software,

descomponer el software en funciones, que puedan ser estimadas
individualmente.
2. Estimar LDC o PF para cada una de las funciones.
3. Aplicar métricas de productividad a la variable de estimación
apropiada y derivar el coste y el esfuerzo.
4. Proporcionar tres valores para cada valor a estimar: optimista, más
probable y pesimista usando datos históricos.
5. Calcular el valor esperado de LDC o PF como

E = ( pesimista + 4 probable + pesimista ) / 6

I-3-3
 Técnicas de descomposición

6. Calcular los valores estimados a partir del valor esperado de LDC

o PF
– Multiplicar el valor total de la variable de estimación para
todas las funciones por la métrica de productividad media
correspondiente a la variable de estimación.
• Si en total se han estimado 310 PF y la productividad
media de PF de acuerdo con anteriores proyectos es
5,5 PF/personas-mes, entonces el esfuerzo total del
proyecto es 56 personas-mes.

– Multiplicar el valor de la variable de estimación obtenida

para cada función por el valor de productividad
compensado, que se basa en el nivel de complejidad
percibido par la función. Para funciones de complejidad
media se utiliza una métrica de productividad media. Sin
embargo, para funciones de complejidad alta o baja se
compensa la métrica de productividad hacia abajo o hacia
arriba.
• Si la productividad media fuera 490 LDC/persona-
mes, se podría estimar la productividad para una
función más compleja que la media en 300
LDC/persona-mes y para la funciones simple en 650
LDC/persona-mes.

• ¿Serán correctas las estimaciones?

– No se puede asegurar.
– Cualquier técnica de estimación tiene que ser comprobada
utilizando otro método. Incluso entonces, deberá prevalecer
la experiencia y el sentido común. I-3-4
 Ejemplo

• Desarrollo de un paquete de software para una aplicación de

diseño asistido por computadora (CAD). Revisando la
especificación del sistema, vemos que el software va a
ejecutarse en una estación de trabajo a la que estarán conectados
varios periféricos gráficos: un ratón, un digitalizador, una
pantalla en color de alta resolución y una impresora láser.

• Con la especificación del sistema, se puede desarrollar una

declaración preliminar el ámbito del software:
– El software de CAD aceptará del ingeniero datos de
geometría bi- y tri-dimensional. El ingeniero controlará e
interactuará con el sistema CAD a través de una interfaz
hombre-máquina. Todos los datos geométricos y cualquier
información adicional se mantendrán en una base de datos
de CAD. Los módulos de análisis de diseño se desarrollarán
de forma que produzcan la salida requerida en una forma
que pueda ser mostrada en una gran variedad de
dispositivos gráficos. El software estará diseñado para
poder controlar e interactuar con dispositivos periféricos
tales como un ratón, un digitalizador, una impresora láser y
un trazador.

• Se identifican las siguientes funciones:

– Interfaz de usuario y facilidades de control (IUFC)
– Análisis geométrico bidimensional (AG2D)
– Análisis geométrico tridimensional (AG3D)
– Gestión de la base de datos (GBD)
– Facilidad de visualización de gráficos (FVG)
– Control de periféricos (CP) I-3-5
– Módulo de análisis de diseño (MAD)
 Ejemplo

• Utilizaremos LDC como variable de estimación.

• Siguiendo la técnica de descomposición, se desarrolla la tabla de
estimación que se muestra:

I-3-6
 Estimación del esfuerzo

• La estimación del esfuerzo es la técnica más utilizada para

calcular el coste de un proyecto de ingeniería del software.

• En la resolución de cada tarea del proyecto se aplica un número

determinado de personas/día, /mes o /año. Se asocia un coste a
cada unidad de esfuerzo y se deriva el coste total estimado.

• Al igual que las técnicas LDC y PF, la estimación de esfuerzo

comienza con una delimitación de las funciones del software,
obtenidas del ámbito del proyecto.

• Para cada función debe realizarse una serie de tareas de

ingeniería del software (análisis de requisitos, diseño,
implementación y pruebas). Se pueden representar las funciones
con sus tareas de ingeniería del software asociadas en la tabla:

I-3-7
 Estimación del esfuerzo

• El planificador estima el esfuerzo (p. ej.: en personas(mes) de

acometer cada tarea de ingeniería del software de cada función
del software. Estos datos constituyen la matriz central de la
tabla.

• Se aplican las tarifas laborales (a cada una de las tareas de

ingeniería del software. Lo más normal es que la tarifa laboral
sea distinta para cada tarea.

– El personal senior: análisis de requisitos y en las primeras

etapas del diseño.

– El personal junior: etapas del diseño, implementación y

pruebas iniciales.

• En un último paso, se calculan los costes y el esfuerzo para cada

función y cada tarea de ingeniería del software. Si se ha hecho la
estimación del esfuerzo independientemente de la estimación
LDC o PF ahora tendremos dos estimaciones de coste y de
esfuerzo que se pueden compara y unificar.

• Si ambos conjuntos de estimaciones muestran concordancias

razonables, existirá una buena razón para creer que las
estimaciones son fiables.

• Si, por otro lado, los resultados de ambas técnicas de

descomposición no tienen mucho en común, deberá realizarse
otra investigación y otro análisis.
I-3-8
 Ejemplo de estimación del esfuerzo

• Retomando el software de CAD, con la misma definición de

ámbito y de funciones.

• En la tabla de estimaciones de esfuerzo aparecen las

estimaciones de esfuerzo para cada tarea de ingeniería del
software de cada función de software CAD.

– Análisis de requisitos y diseño utilizan 75 personas-mes

– El coste total estimado es de 708.000 $
– El esfuerzo total estimado es de 153 personas-mes

• Comparando estos resultados con los obtenidos mediante la

técnica de líneas de código, se encuentra una variación en:
– El coste del 7 por 100
– El esfuerzo del 5 por 100
I-3-9
 No concordancia entre estimaciones

• ¿Que ocurre cuando la concordancia entre las estimaciones es

pobre?

• Debemos reevaluar la información utilizada para hacer las

estimaciones.

• Muchas divergencias entre estimaciones se deben a esta dos

causas:

– No se entiende adecuadamente el ámbito del proyecto o ha

sido malinterpretado por el planificador.

– Los datos de productividad utilizados en las técnicas LDC o

PF son inadecuados, obsoletos o se han aplicado mal.

I-3-10
 Modelos empíricos de estimación

• Utilizan formulas derivadas empíricamente para predecir los

datos que se requieren en el paso de planificación del proyecto.

• Los datos empíricos que soportan la mayoría de modelos se

obtienen de una muestra de proyectos limitada.

• Por esto un mismo modelo de estimación no es adecuado para

todas las clases de proyectos de software ni para todos los
entornos de desarrollo.

• Los modelos de recursos consisten en una o varias ecuaciones

obtenidas empíricamente que predicen el esfuerzo, la duración
del proyecto y otros datos.

• Basili describe cuatro clases de modelos de recursos:

– Modelos univariable estáticos

– Modelos multivariable estáticos

– Modelos multivariable dinámicos

– Modelos teóricos

I-3-11
Clasificación de los modelos empíricos

• Modelos univariable estáticos. Toma la forma:

Variable a calcular = C1 ( característica estimada)C2
– Variable a calcular: recursos, esfuerzo, duración del
proyecto, cantidad de personal, líneas de documentación,
etc.
– Característica estimada: LDC, esfuerzo, etc.
– C1 y C2: constantes empíricas.
• Modelos multivariable estáticos.
Variable a calcular = C11 E1C12 + C21 E2C22 + ...
– Ei es la característica i-ésima del software.
– Ci1, Ci2 son ctes. empíricas para la característica i-ésima.
• Modelos multivariable dinámicos.
– Proyecta los requisitos de recursos como una función del
tiempo. Si se obtiene empíricamente el modelo, los
recursos se definen en una serie de pasos consecutivos en el
tiempo que asignan cierto porcentaje de esfuerzo a cada
etapa del proceso de ingeniería del software. Cada paso
puede ser subdividido en tareas. El enfoque teórico de la
modelización multivariable dinámica incluye una “curva
continua de utilización del recurso” como hipótesis y, a
partir de ella, obtiene ecuaciones que modelizan el
comportamiento del recurso (modelo de estimación de
Putnam).
• Modelos teóricos.
– Al contrario que los anteriores examina el software desde el
punto de vista microscópico, es decir, las características del
código fuente (p.e. número de operadores y de operandos).
I-3-12
COCOMO. COnstructive COst MOdel

• El modelo constructivo de coste (COCOMO) es una jerarquía de

modelos de estimación.

– Modelo 1. El modelo básico es univariable estático que

calcula el esfuerzo del desarrollo del software en función
del tamaño del programa, expresado en LDC estimadas.

– Modelo 2. El modelo intermedio calcula el esfuerzo de

desarrollo en función del tamaño del programa y de un
conjunto de “conductores de coste”, que incluye la
evaluación subjetiva del producto, del hardware, del
personal y de los atributos del proyecto.

– Modelo 3. El modelo avanzado incorpora todas las

características de la versión intermedia y lleva a cabo una
evaluación del impacto de los “conductores de coste” en
cada fase (análisis, diseño, etc.) del proceso de ingeniería
del software.

I-3-13
 COCOMO. Tipo de proyectos

• Los modelos anteriores están definidos para tres tipos de

proyectos, definidos por Boehm:

– Modo orgánico. Proyectos de software relativamente

pequeños y sencillos en los que trabajan pequeños equipos,
con buena experiencia en las aplicaciones, sobre un
conjunto de requisitos poco rígidos.

– Modo semiacoplado. Proyectos de software intermedios

(en tamaño y complejidad) en los que los equipos, con
variados niveles de experiencia deben satisfacer los
requisitos poco o medio-rígidos (p.e. Un sistema de
procesamiento de transacciones con requisitos fijos para un
hardware de terminal o un software de gestión de base de
datos).

– Modo empotrado. Proyectos de software que deben ser

desarrollados en un conjunto de hardware, software y
restricciones operativas muy restringido (p.e. software de
control de navegación para un avión).

I-3-14
 COCOMO. Modelo básico.

• Las ecuaciones del modelo básico son las siguientes:

– E = a (KLDC)b

– D = c (E)d

• E es el esfuerzo aplicado en persona-mes.

• D es el tiempo de desarrollo en meses.

• KLDC es el número estimado de líneas de código.

• a, b, c y d se muestran en la siguiente tabla:

I-3-15
 COCOMO. Modelo Intermedio

• El modelo básico se amplia para considerar un conjunto de

atributos conductores de coste:

1. Atributos del producto

a. Fiabilidad del software requerida.
b. Tamaño de la base de datos de la aplicación.
c. Complejidad del proyecto.

2. Atributos del hardware

a. Restricciones de rendimiento en tiempo de ejecución.
b. Restricciones de memoria.
c. Volatilidad del entorno de la máquina virtual.
d. Tiempo de espera requerido.

3. Atributo del personal

a. Capacidad de análisis.
b. Capacidad del ingeniero de software.
c. Experiencia en aplicaciones.
d. Experiencia con la máquina virtual.
e. Experiencia con el lenguaje de programación.

4. Atributos del proyecto

a. Utilización de herramientas de software.
b. Aplicaciones de métodos de ingeniería del software.
c. Planificación temporal del desarrollo requerida.
I-3-16
 COCOMO. Modelo Intermedio

• Cada uno de los atributos es valorado de 0 a 6 puntos.

• De acuerdo con la evaluación se determina un multiplicador de
esfuerzo a partir de las tablas calculadas por Boehm.
• Con el producto de todos los multiplicadores de esfuerzo se
obtiene un factor de ajuste del esfuerzo (FAE), que toma
valores típicos entre 0,9 y 1,4.

• La ecuación del modelo COCOMO intermedio es:

– E = a (KLDC)b FAE
• E es el esfuerzo en personas-mes.
• LDC es el número estimado de líneas de código.
• a y b se obtienen de la tabla:

• COCOMO es el modelo empírico más completo para la

estimación del software publicado hasta la fecha.

• Deben tenerse en cuenta los propios comentarios de Boehm

sobre COCOMO y sobre todos los modelos:
Un modelo de estimación de costes del software está bien
construido si puede estimar los costes del desarrollo de
software en torno al 20 por 100 de los costes reales, y el 70
por 100 del tiempo y ello en su propio terreno.
I-3-17
COCOMO. Ejemplo del modelo básico

• Aplicando el modelo COCOMO al ejemplo de software CAD.

• Las LDC estimadas son 33360.

• Coeficientes de la tabla COCOMO básico para el modelo

semiacoplado

– E = 3,0 (33,33)1,12 = 1523 personas-mes

– D = 2,5 (152)0,35 = 14,5 meses

• El valor de la duración del proyecto permite al planificador

recomendar un número de N personas para el proyecto:

– N = E / D = 11 personas

I-3-18
 Putnam

• Modelo multivariable dinámico que asume una distribución

específica del esfuerzo a lo largo de la vida de un proyecto de
desarrollo del software.

• El modelo se ha obtenido a partir de distribuciones de mano de

obra en grandes proyectos (30 personas-año o más). Sin
embargo, se puede extrapolar a proyectos más pequeños.

• La distribución del esfuerzo en grandes proyectos de software

puede ser caracterizada como se muestra:

I-3-19
 Putnam

• Se puede utilizar la curva de Rayleigh-Nordem para obtener una

ecuación del software que relaciona el número de líneas de
código esperadas con el esfuerzo y el tiempo de desarrollo:

– L = Ck K1/3 td4/3

– Ck es una constante del estado de la tecnología:

• Ck= 2000 para un entorno de desarrollo pobre.
• Ck= 8000 para un buen entorno de desarrollo (buena
tecnología, adecuada documentación, modo de
ejecución interactivo)
• Ck= 11000 para un entorno excelente con herramientas
y técnicas automáticas.
• td = Tiempo de desarrollo en años.

– Reorganizando la ecuación anterior podemos obtener el

esfuerzo K
L3
K
Ck3td4

– Dadas las potencias de alto orden que aparecen en la

ecuación del software, se puede demostrar que, postergando
ligeramente la fecha de entrega, se puede obtener un
sustancial ahorro en el esfuerzo humano aplicado al
proyecto.

I-3-20
I-3-21