Este documento presenta un resumen de diferentes modelos empíricos de estimación de software. En particular, describe brevemente los siguientes modelos: 1) Modelos empíricos de estimación en general, que utilizan fórmulas derivadas empíricamente de una muestra limitada de proyectos para predecir el esfuerzo. 2) El modelo COCOMO, que predice el esfuerzo y duración en función del tamaño del proyecto (LOC) y factores de ajuste. 3) El modelo de Putnam, que describe el tiempo y esfuerzo

1. REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO P.P. EDUCACIÓN UNIVERSITARIA
COLEGIO UNIVERSITARIO DE CARACAS
P. N. F. EN INFORMÁTICA
IV TRAYECTO – TRIMESTRE I
MODELOS EMPIRICOS DE ESTIMACI
IRICOS ESTIMACIÓN: LA ECUACIÓN DEL SOFTWARE
N
Integrantes:
José Zamora
Dany Mieres
Luis Pérez
Teodolinda Albarrán
Caracas, 8 de Febrero de 2012

2. Introducción
Un modelo empírico de estimación para el software de computadora
utiliza fórmulas derivadas empíricamente para predecir los datos que se
requieren en el paso de planificación del proyecto de software. Los datos
empíricos que soportan la mayoría de los modelos se obtienen de una muestra
de proyectos limitada. Por esta razón, un mismo modelo de estimación no es
adecuado para todas las clases de software ni para todos los entornos de
desarrollo. Por lo tanto, los resultados obtenidos de los modelos deben
utilizarse de forma sensata.
Los Modelos de recursos consisten en una o vanas ecuaciones
obtenidas empíricamente que predicen el esfuerzo (en personas/mes), la
duración del proyecto (en meses cronológicos) y otros datos relativos al
proyecto. Basili describe cuatro clases de modelos de recursos: modelos
univariable estáticos, modelos multivariable estáticos, modelos multivariable
dinámicos y modelos teóricos.

3. Método empírico-analítico
El método empírico es un modelo de investigación científica, que se
basa en la lógica empírica y que junto al método fenomenológico es el más
usado en el campo de las ciencias sociales y en las ciencias duras.
El término empírico deriva del griego antiguo (Aristóteles utilizaba la
reflexión analítica y el método empírico como métodos para construir el
conocimiento) de experiencia, έµπειρία, que a su vez deriva de έυ (en) y πεἳρα
(prueba): en pruebas, es decir, llevando a cabo el experimento. Por lo tanto los
datos empíricos son sacados de las pruebas acertadas y los errores, es decir,
de experiencia.
Su aporte al proceso de investigación es resultado fundamentalmente de
la experiencia. Estos métodos posibilitan revelar las relaciones esenciales y las
características fundamentales del objeto de estudio, accesibles a la detección
senso-perceptual, a través de procedimientos prácticos con el objeto y diversos
medios de estudio. Su utilidad destaca en la entrada en campos inexplorados o
en aquellos en los que destaca el estudio descriptivo.
Un modelo empírico de estimación:
• Utilizan fórmulas derivadas empíricamente de una muestra limitada de
proyectos para predecir el esfuerzo en función de LOC o PF.
• La estimación de los valores de LOC y PF se realizan utilizando las
técnicas de descomposición vistas con anterioridad.
• Los valores resultantes se aplican a la fórmula del modelo que se haya
escogido para obtener el esfuerzo en hombres-mes.
• Precisamente por venir de una muestra limitada, no son adecuados para
toda clase de software ni para todo medio ambiente de desarrollo.

4. Algunos modelos
E = 5.2 * KLOC0.91 Modelo de Walston-Felix
E = 5.5 + 0.73 * KLOC1.16 Modelo de Bailey-Basisli
E = 3.2 * KLOC1.05 Modelo simple de Boehm
E = 5.288 * KLOC1.047 Modelo Doty para KLOC > 9
E = -13.39 + 0.054 * PF Modelo de Albretch-Gaffney
E = 60.62 * 7.728 * 10-8 *
Modelo de Kemerer
PF3
Modelo de Matson-Barnett-
E = 585.7 + 15.12 * PF
Mellichamp
Metodología original de Albrecht
En los planes originales de Albrecht, esta medida servía como dato de
un estimador empírico. Hoy ya no se lo considera más así y la noción de
Puntos Funcionales se ha separado de toda metodología de estimación de
esfuerzo.
Albrecht buscaba un estimador empírico confiable.
Su metodología seguía el siguiente esquema:
Datos del proyecto
5 FUNCIONES BÁSICAS
PUNTOS FUNCIONALES SIN AJUSTAR
o 14 MODIFICADORES
PUNTOS FUNCIONALES AJUSTADOS
o ECUACIÓN EMPÍRICA
MESES-PERSONA NOMINALES

5. La ecuación empírica de Albrecht solamente valía para sistemas
realizados en COBOL. No cabe duda que sus ecuaciones continúan siendo
válidas hoy (excepto por algunas objeciones que analizaremos más adelante),
pero el éxito de la métrica sobrepasó por mucho a su ecuación empírica. Hoy,
la metodología de los Puntos Funcionales tiene gran vigencia y se procura que
no se mezcle con ecuaciones empíricas de estimación de esfuerzo.
El Modelo COCOMO
Creado por Barry Boehm en 1981. Su nombre significa COnstructive
COst MOdel (Modelo constructivo de costo) y se puede dividir en tres modelos.
• COCOMO básico. Calcula el esfuerzo y el costo del desarrollo en
función del tamaño del programa estimado en LOC.
• COCOMO intermedio. Calcula el esfuerzo del desarrollo en función del
tamaño del programa y un conjunto de conductores de costo que
incluyen la evaluación subjetiva del producto, del hardware, del personal
y de los atributos del proyecto.
• COCOMO detallado. Incorpora las características de la versión
intermedia y lleva a cabo una evaluación del impacto de los conductores
de costo en cada fase (análisis, desarrollo, etc.) del proceso.
Los modelos COCOMO están definidos para tres tipos de proyectos de
software:
• Orgánicos.
o Proyectos pequeños y sencillos.
o Equipos pequeños con experiencia en la aplicación.
o Requisitos poco rígidos.
• Semiacoplados.
o Proyectos de tamaño y complejidad intermedia.
o Equipos con variado niveles de experiencia.
o Requisitos poco o medio rígidos.
• Empotrados.

6. o Proyectos que deben ser desarrollados con un conjunto de
requisitos (hardware y software) muy restringidos.
COCOMO básico
Las ecuaciones del modelo COCOMO básico son de la forma:
E = a * KLOCb
D = c * Ed
Donde E es el esfuerzo aplicado en hombre-mes, D es el tiempo de
desarrollo en meses y KLOC es el número de miles de líneas de código
estimado para el proyecto. Los coeficientes a y c y los exponentes b y d se
obtienen de la siguiente tabla:
Tipo de proyecto a b c d
Orgánico 2.4 1.05 2.5 0.38
Semiacoplado 3.0 1.12 2.5 0.35
Empotrado 3.6 1.20 2.5 0.32
Aplicando el modelo COCOMO básico al ejemplo anterior y usando un
tipo de proyecto orgánico obtenemos una estimación para el esfuerzo:
E = 2.4 * KLOC1.05
= 2.4 * 7.41.05
= 20 hombre-mes
Para calcular la duración del proyecto usamos la estimación de esfuerzo:
D = 2.5 * E0.38
= 2.5 * 200.38
= 8 meses

7. El valor de la duración del proyecto permite al planificador recomendar
un número de personas N para el proyecto.
N=E/D
= 20 / 8
= 3 personas
Por supuesto que el planificador puede decidir emplear sólo una o dos
personas y ampliar por tanto la duración del proyecto.
COCOMO intermedio
En el COCOMO intermedio, la ecuación para calcular el tiempo de
desarrollo es la misma que la del COCOMO básico. La ecuación para calcular
el esfuerzo es:
E = a * KLOCb * EAF
Donde E es el esfuerzo en hombre-mes, KLOC es el número estimado
de miles de líneas de código. El coeficiente a y el exponente b están dados por
la tabla:
Tipo de proyecto a b
Orgánico 3.2 1.05
Semiacoplado 3.0 1.12
Empotrado 2.8 1.20
EAF es un factor de ajuste del esfuerzo que se calcula valorando en una
escala de muy bajo, bajo, nominal, alto y muy alto cada uno de los siguientes
15 atributos, agrupados en 4 categorías
• Atributos del producto. Son restricciones y requerimientos del proyecto
que va a ser desarrollado.
o Confiabilidad requerida.

8. o Tamaño de la base de datos.
o Complejidad del producto.
• Atributos de computadora. Son limitaciones puestas por el hardware y el
sistema operativo donde el proyecto va a correr.
o Restricciones de tiempo de ejecución.
o Restricciones de memoria principal.
o Volatilidad de la máquina virtual.
o Tiempo de respuesta de la computadora.
• Atributos de personal. Nivel de habilidades que tiene el personal. Son
habilidades profesionales generales, habilidad de programación,
experiencia con el medio ambiente de desarrollo y familiaridad con el
dominio del proyecto.
o Capacidad del analista.
o Experiencia en aplicaciones.
o Capacidad del programador.
o Experiencia con la máquina virtual.
o Experiencia con el lenguaje de programación.
• Atributos del proyecto. Restricciones y condiciones bajo las cuales el
proyecto se desarrolla.
o Prácticas modernas de programación
o Uso de herramientas de software.
o Calendario de desarrollo requerido.
A cada atributo se le asigna un número real de acuerdo a la tabla
siguiente:
Escala Número
muy bajo 0.75
bajo 0.88
nominal 1
alto 1.15
muy alto 1.40

9. El número indica el grado con el que cada factor puede influenciar la
productividad. Un valor menor que 1 indica que el factor puede decrementar el
calendario y el esfuerzo. Un valor mayor que 1 denota un factor que extiende el
calendario y el esfuerzo. Finalmente, un valor igual a 1 no extiende ni
decrementa el calendario y el esfuerzo (esta clase de factor se llama nominal).
Para obtener el EAF se multiplican cada uno de los 15 factores.
Se puede simplificar el cálculo del EAF porque hay una tendencia a
considerar los atributos marcados en negritas, como los más relevantes y que
deberían ser tomados más en cuenta.
Modelo COCOMO Avanzado
El modelo COCOMO avanzado incorpora todas las características de la
versión intermedia y lleva a cabo una evaluación
del impacto de los conductores de costo en cada fase (análisis, diseño,
etc.) del transcurso de ingeniería del software.
Las ecuaciones del COCOMO básico tienen la siguiente forma: [Norman
E. Fenton‘91] E = ab KLDCbb D = Cb Edb ) donde E es el esfuerzo aplicado en
personas-mes, D es el tiempo de desarrollo en meses cronológicos y KLDC es
el número estimado de líneas de código distribuidas (en miles) para el
proyecto. Los coeficientes a b y Cb y los exponentes db y bb , con valores
constantes.
La ecuación del modelo COCOMO intermedio toma la forma: E =
aiKLDCbi * FAE (5.11) donde E es el esfuerzo aplicado en personas-mes y
LDC es el número estimado de líneas de código distribuidas para el proyecto.
El coeficiente a i y el exponente b i.

10. Modelo de Putnam
Modelo de Putnam es un modelo empírico de la valoración del esfuerzo
del software. Como grupo, los modelos empíricos trabajan recogiendo datos del
proyecto del software (por ejemplo, esfuerzo y tamaño) y caber una curva a los
datos. Las estimaciones futuras del esfuerzo son hechas proporcionando
tamaño y calculando el esfuerzo asociado usando la ecuación que caben los
datos originales (generalmente con alguno error).
Creado por Lorenzo Putnam, Sr. Modelo de Putnam describe tiempo y
esfuerzo requerido para acabar un proyecto del software de especificado
tamaño. DELGADO (gerencia del ciclo de vida del software) es el nombre dado
por Putnam a la habitación propietaria de herramientas su compañía QSM, Inc.
se ha convertido basado en su modelo. Es uno del más temprana de estos
tipos de modelos desarrollados, y está entre el más ampliamente utilizado. Los
modelos de cerca relacionados son modelo constructivo del coste (COCOMO),
revisión paramétrica de la información para costar y evaluación - software
(PRECIOS), y evaluación del software y valoración de recursos - software que
estima el modelo (SEER-SEM).
Mientras que el manejo del R&D proyecta para el ejército y más adelante
en GE, Putnam notó que el software que proveía de personal perfiles siguió el
bien conocido Distribución de Rayleigh.
Putnam utilizó sus observaciones sobre niveles de la productividad para
derivar la ecuación del software, donde:
El tamaño es el tamaño del producto (cualquier estimación del tamaño es
utilizada por su organización es apropiada). Putnam utiliza ESLOC (eficaz
Líneas fuente del código) a través de sus libros.
• El β del término es un término del escalamiento y es una función del
tamaño del proyecto.

11. • La productividad es Productividad de proceso, la capacidad de una
organización particular del software al software del producto de un
tamaño dado en una tarifa particular del defecto.
• El esfuerzo es el esfuerzo total aplicado al proyecto en person-years.
• Tiempo es el horario total del proyecto en años.
En uso práctico, cuando la fabricación una estimación para una tarea del
software de la ecuación del software se soluciona para esfuerzo:
Un tamaño estimado del software en la terminación del proyecto y la
productividad de proceso de organización se utiliza. El trazar esfuerzo en
función de tiempo rinde Curva del Tiempo-Esfuerzo. Los puntos a lo largo de la
curva representan el esfuerzo total estimado de terminar el proyecto en alguno
tiempo. Una de las características que distinguen del modelo de Putnam es que
el esfuerzo total disminuye mientras que la época de terminar el proyecto es
extendida. Esto se representa normalmente en otros modelos paramétricos con
un parámetro de la relajación del horario.
Este método que estima es bastante sensible a la incertidumbre en
ambos tamaño y productividad de proceso. Abogados de Putnam que obtienen
productividad de proceso por la calibración:
Putnam hace una distinción aguda entre la “productividad convencional”:
tamaño / esfuerzo y productividad de proceso (cinco métricas de la base,
página 97).
Una de las ventajas dominantes a este modelo es la simplicidad con la
cual está calibrado. La mayoría de las organizaciones del software, sin importar
el nivel de la madurez puede recoger fácilmente tamaño, esfuerzo y duración
(tiempo) para los últimos proyectos. Productividad de proceso, siendo
exponencial en naturaleza se convierte típicamente a un linear índice de la
productividad una organización puede utilizar seguir sus propios cambios en
productividad y aplicarse en las estimaciones futuras del esfuerzo.

12. Método del punto de función
Es una medida sintética del tamaño del programa que se suele utilizar
en la definición del proyecto "1984 IBM Method" es la base del método actual
de IBM y de International Function Point Users Group (IFPUG).El número de
puntos de función se basa en el número y complejidad de cada uno de los
elementos siguientes:
o Entradas: Pantallas formularios, cuadros de diálogo, controles,
mensajes, a través de los cuales se pueden cambiar los datos del
programa
o Salidas: Pantalla, informes, gráficos, o mensajes que genera el
programa
o Consultas: Combinaciones de entrada/salida generalmente
contra BB.DD.
o Archivos lógicos internos: un archivo plano o una tabla de
BB.DD.
o Archivos de interfaz externos: archivos controlados por otros
programas con los que se interactúa
En la siguiente imagen se puede ver la valoración de la complejidad de
un proyecto.

13. La ecuación del software
La ecuación del software es un modelo multivariable que asume una
distribución específica del esfuerzo a lo largo de la vida de un proyecto de
desarrollo de software. El modelo se ha obtenido a partir de los datos de
productividad para unos 4,000 proyectos actuales de software. Un modelo de
estimación tiene esta forma:
E = (LOC * B0.333 / P)3 * (1 / t4)
donde E = esfuerzo en hombres-año.
t = duración del proyecto en años.
B = factor especial de estrezas. Para programas pequeños B vale 0.16,
para programas intermedios vale 0.28, para programas mayores vale
0.39.
P = parámetro de productividad, para un software de tiempo real, P vale
2,000, para comunicaciones vale 10,000, para software científico vale
12,000 y para aplicaciones comerciales de sistemas vale 28,000.
Para simplificar el proceso de estimación se sugiere un conjunto de
ecuaciones obtenidas de la ecuación del software.
Un tiempo mínimo de desarrollo de software se define como:
tmin = 8.14 * (LOC / P)0.43 para tmin > 6 meses.
E = 180 * B * t3 en hombres-mes para E >= 20 hombres-mes y t
representado en años
Aplicando las ecuaciones al ejemplo anterior, obtenemos:
tmin = 8.14 * (7,400 / 12,000)0.43
= 7 meses
E = 180 * 0.28 * 0.753
= 21 hombres-mes

14. El Parámetro de productividad
Se obtiene calibrando sistemas terminados. Por ejemplo, dado un
sistema de 30.000 líneas de Cobol, finalizado en 17 meses con un gasto de
recursos de 146 personas-mes, tenemos
Parámetro de productividad = (SLOC)/(Esfuerzo/B)(1/3) · Tiempo(4/3) =
= 30.000 /(12.17/0.28)(1/3) (1.42)(4/3).
El índice de productividad.
El índice de productividad (PI) es una escala de enteros asociada a los
valores del PP obtenidos para la base de datos QSM (Tabla 2.3). Este PI se
comporta exponencialmente (ver figura 2.2) siendo el valor factor multiplicador
de un índice al siguiente de 1.3.
Rango del índice.
El PI y el PP constituyen una macromedida del entorno general de
desarrollo. Valores bajos se asocian a entornos elementales y herramientas
inadecuadas, o a un alto grado de la complejidad del producto (como
microcódigo o firmware). Valores altos se asocian a buenos entornos, personal
experimentado o a productos de baja complejidad que se comprenden bien. El
PI medio se extiende desde 2 a 16 (para los 11 tipos de aplicación).
Valoración económica.
Dado que el PI representa el PP exponencial, una pequeña mejora en
este índice tiene gran importancia económica, como se muestra en la tabla 2.4
para el anterior sistema en Cobol. Otro ejemplo se muestra en la tabla 2.5.

15. Productividad convencional.
El PP tiene un significado más complejo que la medida de productividad
en SLOC (personas-mes) puesto que es la medida de la efectividad en el
desarrollo de software en una organización o proyecto.
Utilización de la Ecuación para Estimación.
La utilización básica es la de estimar tiempo y esfuerzo al comienzo de
un nuevo proyecto software. Se deben conocer el PI (y el PP) a través de
proyectos anteriores. Quedan dos incógnitas en la ecuación. Se puede resolver
como
• solución determinista
• simulación
• programación lineal
Solución determinista
Consisten en poner la ecuación como sigue
(esfuerzo/B)1/3 · tiempo4/3 = SLOC/PP
Y añadir una segunda ecuación basada en la "tasa de acumulación de esfuerzo
humano", y se expresa como el parámetro de acumulación del esfuerzo":
Esfuerzo total acumulado/tiempo3 = parámetro MBP.
Para un proyecto ya acabado es fácil obtener este parámetro calibrado.
El MBP (con su MBI asociado) permite establecer un "tiempo mínimo de
desarrollo"

16. Conclusión
La planificación de un proyecto se basa en una buena estimación del
esfuerzo requerido para realizarlo, y para apoyar esta difícil tarea, se han
desarrollado varios métodos que han encontrado aceptación comercial en
forma creciente en la planificación del desarrollo de software.
La mayoría de estos métodos incluyen modelos empíricos de estimación
y poseen como variable manejadora del costo principal el tamaño de la
aplicación a desarrollar, lo que es suficientemente difícil de estimar como para
que se justifique pensar en automatizar o apoyar fuertemente esta tarea con la
generación de un método fácil de usar.
Por otro lado, aquellos modelos que fueron desarrollados con base
empírica, pueden carecer de validez en ambientes de desarrollo distintos a
aquel del que se obtuvieron los datos.
Para el caso de los modelos basados en líneas de código, se puede
observar que en la actualidad, las herramientas de desarrollo proveen la
capacidad de disminuir substancialmente el esfuerzo de codificación, pues la
tendencia actual ya no es codificar, sino generar código. Por el lado de las
técnicas basadas en el enfoque de puntos de función, el problema radica en
que la estimación sólo puede realizarse con un diseño externo acabado de la
aplicación, y si consideramos la utilización de herramientas de generación de
código a la altura en que por fin se puede realizar la estimación ya se ha
consumido la mayor cantidad del esfuerzo del desarrollo (es decir, si antes el
esfuerzo se centraba en la fase de construcción vía codificación en algún
lenguaje de programación, hoy el esfuerzo se centra en las fases de diseño, ya
que la codificación se ve fuertemente asistida por herramientas automatizadas),
por lo que la estimación ya no es tan útil.
Todos los puntos mencionados anteriormente, dificultan que la utilización
de modelos de gestión sea una práctica generalizada en los administradores de
proyectos de desarrollo de software.

17. Bibliografía
http://eclases.tripod.com/id15.html
http://www.multilingualarchive.com/ma/enwiki/es/Putnam_model
http://trabajodeestimaciondeproyectos.wikispaces.com/
http://www.it.uc3m.es/~labtproy/asignapedia-
IT92/index.php/T%C3%A9cnicas_de_planificaci%C3%B3n_de_proyectos-II