FACULTAD DE INGENIERA

ESCUELA PROFESIONAL DE ING. DE

COMPUTACIN Y SISTEMAS

CURSO:
Ingeniera de Software

TEMA:
Estimaciones de Software

PROFESOR:
Crdenas Rengifo, Luis

ALUMNO:
Durn Melndez, Adrin Arturo.

CICLO:
V

Trujillo, 28 de Noviembre de 2014

INTRODUCCIN

La Ingeniera del Software es uno de las cuestiones ms olvidadas y

rechazadas entre la mayora de estudiantes de Ingeniera Informtica. Sin
embargo, es una de las temticas ms importantes en el conjunto global de
la titulacin de Ingeniera Informtica, y fundamental para el correcto
desarrollo de productos software.
Errneamente se identifica la creacin de software slo con su
programacin y prueba, dando de lado el proceso anterior de planificacin y
diseo, as como de asignacin de recursos y de esfuerzo.
La Ingeniera Software es vital para la correcta elaboracin de productos
software. Antes de comenzar la tarea puramente de programacin y
creacin del programa es necesario realizar una estimacin y una previsin
sobre la cantidad de tiempo que llevar su realizacin as como del esfuerzo
y el personal necesario para completarlo. Para llevar a cabo esta estimacin
existen una serie de modelos que actualmente son utilizados por las
empresas de desarrollo software, y cuyos resultados poseen una calidad
dependiente del entorno. Por ello este estudio intentar esclarecer cules
son los mejores modelos as como mostrar una comparativa entre ellos.
Todos estos modelos y herramientas pueden ser directamente aplicados a la
estimacin de parmetros como esfuerzo y costo de proyectos de tipo
software.
Las actividades de estimacin y de planificacin quedaban relegadas a un
mero acto protocolario al comienzo del proyecto. Posteriormente, el
seguimiento y control se realizaban sin un mnimo de rigor, dada la baja
calidad de la estimacin y la planificacin realizada. Es entonces que las
desviaciones en costos y tiempo han sido consideradas como algo natural
en un proyecto software. Algo as como si nadie estuviera obligado a saber
cundo se terminar el sistema ni cunto costar.

Por lo tanto una tarea importante dentro del proceso de desarrollos de

productos de software, es el proceso de estimacin del software, el cual nos
permitir establecer una cierta visin de los que nos espera durante el
proceso de desarrollo, no solo en costos sino tambin en esfuerzo; estando
as mejor preparados y conociendo cuales son las caractersticas a invertir
para que el proceso sea de carcter satisfactorio.

1. DEFINICIN
La estimacin se define como el proceso que proporciona un valor a un
conjunto de variables para la realizacin de un trabajo, dentro de un rango
aceptable de tolerancia. Podemos definirlo tambin como la prediccin de
personal, del esfuerzo, de los costes y de la planificacin que se requerir
para realizar todas las actividades y construir todos los productos asociados
con el proyecto. Predecir valores de entidades y sus atributos que sean
relevantes para el proyecto.
Uno de los parmetros crticos de la estimacin es determinar su exactitud.
La estimacin puede realizarse a partir de datos histricos o con
herramientas. Curiosamente, en la actualidad, est ocurriendo algo
sorprendente y es que algunas herramientas actualmente existentes
proporcionan una estimacin ms exacta que la obtenida por la empresa a
partir de sus datos histricos.
Vista desde el punto de vista de un diccionario, una estimacin es un
conjunto aproximado de valores para algo que ha de ser hecho. En el mundo
del desarrollo de software, Larry Putnam ha apuntado que la gestin del
desarrollo de software considera la estimacin como una actividad que
permite obtener, principalmente, respuestas aproximadas a las siguientes
preguntas:
Cunto costar?
hacerlo?

Cunto tiempo llevar

2. PROBLEMTICA DEL PROCESO DE ESTIMACIN DEL SOFTWARE

Ya en los aos 70 se comenz a hablar del proceso de estimacin del
software. Sin embargo, y desafortunadamente, el arte y la ciencia de la
estimacin estn hoy en da en sus inicios. La industria del software sigue
fuera de control, con costes y tiempos desmedidos. Pero, Qu hace que
la estimacin sea tan difcil de realizar? Entre las razones para esta
complejidad estn las siguientes:

No existe un modelo de estimacin universal o una frmula que

pueda ser usada para todas las organizaciones.
Hay muchas personas implicadas en los proyectos que precisan de
estimaciones.
La utilidad de una estimacin tambin depender de la etapa de
desarrollo en la que nos encontremos.
Las caractersticas del software y de su desarrollo hacen difcil la
estimacin.

Existen malas interpretaciones en las relaciones lineales entre la

capacidad requerida por unidad de tiempo y el tiempo disponible.
El estimador tiende a reducir en algn grado las estimaciones para
hacer ms aceptable la oferta.
Existe una tendencia aparente de los desarrolladores hacia la
subestimacin.
La rapidez con la que cambia la tecnologa de la informacin y las
metodologas de desarrollo de software son problemas para la
estabilizacin del proceso de estimacin.

3. PROCESO DE ESTIMACIN
En la industria en general, es necesario calcular y estimar el esfuerzo y el
tamao del proyecto en etapas muy tempranas del desarrollo del mismo.
Sin embargo, si en el mbito software se hacen las estimaciones en estas
fases iniciales, dichas previsiones pueden estar basadas en unos
requerimientos errneos o incompletos, por lo que disminuye mucho su
fiabilidad.
El proceso de estimacin del coste y esfuerzo de un producto software est
formado por un conjunto de tcnicas y procedimientos que se usan en la
organizacin para poder llegar a una prediccin fiable. ste es un proceso
continuo, que debe ser usado y consultado a lo largo de todo el ciclo de vida
del proyecto. Se divide en los siguientes pasos:

Estimacin del tamao.

Estimacin del costo y del esfuerzo.
Estimacin de la programacin temporal.
Estimacin de la cantidad de recursos computacionales.
Asuncin de riesgos.
Inspeccin y aprobacin.
Redaccin de informes de estimacin.
Medicin y perfeccionamiento del proceso.

Todas estas estimaciones necesarias estn basadas en probabilidades

debido a la influencia de factores externos de difcil control. De una manera
general podemos afirmar que existen dos maneras diferentes de estimar el
presupuesto y el tiempo para un proyecto software: usando modelos de
costo y usando razonamiento basado en similitud. En ambas opciones es
necesario recurrir a informacin histrica y de proyectos anteriores
previamente almacenados en bases de datos.

Existen cuatro puntos fundamentales sobre los que se apoya la estimacin:

Las consideraciones y opiniones de los profesionales de la materia.

La participacin de expertos.
La utilizacin de factores estndar de tiempos, calculados y
establecidos a partir de proyectos anteriores.
Por ltimo el empleo de frmulas y funciones.

4. REQUISITOS QUE DEBE CUMPLIR UN BUEN ESTIMADOR

El estimador debe ser un profesional, que no tenga ningn inters, directo o

indirecto, en los resultados del proceso de estimacin y que est
nicamente guiado por su profesionalidad.
El principal objetivo de un estimador es obtener unas estimaciones de
calidad, las cuales no tienen siempre por qu coincidir con las expectativas
de la direccin en trminos de coste y tiempo.
Un buen estimador debera cumplir los siguientes requisitos:

Debe poseer una importante formacin y experiencia profesional que

le ayuden a entender y solucionar los problemas de la gestin de
proyectos.
Debe tener una posicin en la organizacin que le permita adoptar un
juicio independiente.
Debe basarse en un mtodo que pueda ser explicado, cuestionado,
discutido y auditado por otros expertos.

Siempre que use una herramienta de estimacin, sta debe ajustarse

a su propsito de estimacin y debe soportar el mtodo. La
herramienta tambin debe estar documentada y controlada.
Debe ser capaz de describir su experiencia en cada estimacin. Es
decir, describir los problemas a los que ha tenido que enfrentarse, las
soluciones, etc.
Debe ser capaz de documentar su estimacin, incluyendo los
resultados obtenidos y cualquier informacin necesaria para hacer el
proceso de estimacin repetible y verificarle.

5. MARCO TEMPORAL DE LA ESTIMACIN DE PROYECTOS

La estimacin, es un proceso continuo. La estimacin continua nos permite
el uso de un nico modelo coherente que pueda capturar y utilizar la
informacin sobre el proyecto a medida que este se conozca. Siendo ms
precisos, el proceso de estimacin comienza usando unas pocas variables
claves para proveer las "macro-caractersticas" de un proyecto, y evoluciona
incorporando informacin de ms bajo nivel para producir las "microcaractersticas" del proyecto. De esta forma es interesante conocer el
esfuerzo total del proyecto, su duracin, riesgos, necesidades de personal,
etc. A esta primera estimacin se le denomina macro-estimacin de un
proyecto.

Una vez que los requisitos han sido definidos, se necesita una estimacin
ms detallada para la siguiente fase, diseo del producto, con el fin de
utilizarla para confeccionar una planificacin para dicha fase. Tambin se
necesita una estimacin a ms alto nivel para el resto del proyecto.
Despus de que el diseo del producto ha finalizado, puede ser incluso que
la base de la estimacin haya cambiado, es decir, se puede pasar de utilizar
parmetros descriptivos a emplear otros ms detallados como el nmero de
mdulos esperados, o el nmero de lneas de cdigo. Tambin podran
conocerse consideraciones tecnolgicas a un nivel de detalle razonable.
Al final de la fase de diseo detallado, la informacin sobre el nmero de
mdulos y lneas de cdigo, por ejemplo, puede ser refinada para la mejora
de las estimaciones de las restantes fases.
Cuando la codificacin, las pruebas y la instalacin han finalizado podemos
obtener datos sobre el rendimiento y la calidad del sistema que,
cuantificados adecuadamente, pueden constituir la base para la estimacin
de defectos. Estos datos, junto con el conocimiento sobre el entorno del
desarrollo, permitirn realizar estimaciones para la fase de mantenimiento.

6. SALIDAS DEL PROCESO DE ESTIMACIN

Dentro de esta etapa nace la pregunta: Qu es lo que debemos estimar?

Al comienzo de este informe sobre la definicin de estimacin se
mencionaron dos preguntas a las que este proceso deba dar respuesta.
Estas preguntas eran: Cunto costar? Y Cunto tiempo llevar hacerlo?
Esta informacin constituye la informacin bsica de todo proceso de
estimacin. Los distintos mtodos existentes para realizar este proceso
proporcionan informacin adicional para dar respuestas, en funcin del
mtodo a algunas de las siguientes preguntas:

Cunta gente se necesita? De qu perfiles?

Cules son los riesgos? Cmo afectan las restricciones impuestas a
las estimaciones?
Cunto esfuerzo se necesita para realizar cada fase del ciclo de
vida? Cul ser el esfuerzo para mantener este proyecto?
Cmo impacta este proceso en el resto de los proyectos de la
empresa?
Cul ser el tamao del sistema?
Cuntos defectos tendr el producto?

Se podra crear una lista compuesta por todas estas preguntas, para
utilizarla como base para la solucin al problema de Qu estimar. As, se
observara que existen muchos conceptos en la mente de los estimadores.
Todos estos parmetros que se pretenden obtener, son en realidad medidas
sobre el producto software, es decir mtricas, tema que no se tocara en el
presente informe.

7. TCNICAS DE ESTIMACIN
Para la estimacin, existen cuatro tcnicas bsicas y comunes:
1. La opinin de los expertos. Esta tcnica se basa en la experiencia
profesional de los participantes en el proyecto de estimacin.
2. La analoga. Es una aproximacin ms formal que la experiencia de los
expertos y se basa en la comparacin directa de uno o ms proyectos
pasados. La estimacin inicial se ajusta dependiendo de las diferencias
entre el proyecto pasado y el nuevo.
3. La descomposicin. Consiste en la descomposicin de un producto en
componentes ms pequeos, o descomponer un proyecto en tareas de nivel
inferior. La estimacin se hace a partir del esfuerzo requerido para producir
los componentes ms pequeos o para realizar las tareas de nivel inferior.
La estimacin global del proyecto resultar de sumar las estimaciones de
los componentes.

4. Las ecuaciones de estimacin. Son frmulas matemticas que establecen

la relacin de algunas medidas de entrada (que normalmente es la medida
del tamao del producto) y determinan el esfuerzo que se requerir.
La primera tcnica es un tanto informal y es la que se ha llevado a cabo
hasta el momento, con no muy buenos resultados como ya hemos visto,
dada la complejidad del propio proceso de estimacin. Para poder utilizar la
segunda tcnica es necesario disponer de una base de datos histrica de
proyectos finalizados con la que poder realizar la comparacin. Adems
todos esos proyectos tendrn que haber seguido un proceso estndar.
Para aplicar la tercera tcnica hay que disponer tambin de una base de
datos histrica para poder identificar el esfuerzo de las distintas actividades
de bajo nivel, y sta no est normalmente definida por las razones que
anteriormente hemos indicado.
Por todo ello, cuando se comienza a realizar el proceso de estimacin en
una organizacin se utiliza algn mtodo o modelo establecido, es decir, se
emplea la cuarta tcnica.
7.2. Requisitos de una buena tcnica de estimacin
Un mtodo de estimacin tendr xito si:

La estimacin inicial est dentro del 30% de desviacin del coste final
real.
El mtodo permite el refinamiento de la estimacin durante el ciclo
de vida del producto software.
El mtodo es fcil de usar por el estimador. Esto permite una rpida
re-estimacin cuando sea necesario; por ejemplo, para evaluar
distintas alternativas.
Las reglas de la estimacin son entendidas por todas las personas a
las que afectan los resultados de la misma. Los directivos se sienten
ms seguros cuando el proceso de estimacin es fcilmente
comprensible.

El mtodo es soportado por herramientas y est documentado. La

disponibilidad de herramientas aumenta la eficacia de cualquier
mtodo. Esto es debido, principalmente, a que los resultados pueden
ser obtenidos ms rpidamente y de una forma estndar.

8. MODELOS MTODOS DE ESTIMACIN

8.1 CLASIFICACION DE LOS MODELOS DE ESTIMACIN
Los diferentes modelos de estimacin para proyectos pueden ser
clasificados de diversas maneras, de entre las cuales se deben destacar las
aportadas por dos autores principales:

Segn Basili, existen tres modelos:

Modelos con una o varias variables estticas, que se basan en aplicar

funciones y constantes a algunas propiedades del proyecto, por
ejemplo el LOC (Lines Of Code).
Modelos con varias variables dinmicas, que miden el tiempo del
proyecto frente a su costo, usando una distribucin obtenida de
manera emprica.
Modelos tericos con algoritmos prediseados, que se basan en una
hiptesis para realizar una prediccin a travs de una funcin
obtenida teniendo en cuenta informacin histrica.

Segn Kitchenham
Kitchenham propone una clasificacin ms simple para estos modelos,
basada en distinguir entre aquellos que especifican la relacin entre varios
parmetros de costo, llamados modelos de restriccin, y los que predicen el
valor de un parmetro de costo, llamado modelos de factor emprico.
Otras clasificaciones
Otras maneras ms simples de clasificar los modelos de estimacin
distinguen tres categoras bsicas:

Juicio experto: aunque no es un mtodo en el sentido estricto de

obtener resultados de una manera explcita y repetitiva, es una de las
prcticas ms extendidas, en las que se combinan las opiniones de
varios expertos para obtener estimaciones, como por ejemplo el
mtodo Delphi.
Modelos algortmicos: se basan en frmulas y parmetros con los que
realizan las estimaciones. Son tambin muy conocidos y empleados
en la actualidad, encontrndose en este grupo el modelo COCOMO o
puntos de funcin.
Analoga: puede ser tomada como una variante del juicio experto, ya
que tambin intervienen las opiniones de los estimadores, pero a
diferencia de este tipo, necesita caracterizar claramente el proyecto
que se va a estimar y almacenar los proyectos previos para buscar
entre ellos el ms parecido al actual.

8.2 METODOS DE ESTIMACIN

Un mtodo de estimacin eficaz permitir ignorar aspectos sin inters y
concentrare en los aspectos esenciales. Un buen modelo debera poseer
capacidades predictivas, mejor que ser meramente descriptivo o explicativo.
La validez de las mtricas de software y de los modelos de estimacin debe
ser establecida demostrando la coincidencia entre los datos empricos y los

experimentales. Esto requiere una cuidadosa atencin en la toma de

medidas y en el anlisis de los datos.
En general, el anlisis y la validacin de las mtricas y los modelos de
estimacin requiere una slida base estadstica y diseo de experimentos.
Para obtener resultados significativos son necesarios una definicin precisa
de las mtricas involucradas y de los procedimientos para la captura de
datos
Los modelos de estimacin existentes se pueden clasificar como Modelos
Estadsticos, Modelos basados en Teoras y Modelos Compuestos.
8.2.1 MODELOS ESTADSTICOS
C.E. Walston y P.C. Felix, de IBM utilizaron datos de 60 proyectos terminados
completamente para desarrollar un modelo simple de clculo del esfuerzo
de desarrollo de software.
El principal determinante del esfuerzo de desarrollo fue la mtrica LOC.
Se asumi una relacin de la forma: E = aLb, donde L es el nmero de lneas
de cdigo, en miles y E es el esfuerzo total requerido en meses/personas.
Mediante un anlisis de regresin se encontraron los valores apropiados
para a y b.
La ecuacin resultante fue:

La productividad nominal de programacin en LOC por persona/mes, puede

ser calculada como L/E. Walston y Felix tambin intentaron desarrollar un
ndice de productividad, I, que podra hacer incrementar o disminuir la
productividad, dependiendo de la naturaleza del proyecto.
8.2.2 MODELOS BASADOS EN TEORAS: MODELO DE PUTNAM.
Pocos modelos propuestos tienen una base tcnica substancial. El modelo
ms importante es el de Putnam. Este modelo asume una distribucin
especfica del esfuerzo a lo largo de la vida de un proyecto de desarrollo de
software. El modelo se ha obtenido a partir de distribuciones de mano de
obra en grandes proyectos. Sin embargo, se puede extrapolar a proyectos
ms pequeos.

Putnam desarroll la siguiente relacin entre el tamao del producto

software y el tiempo de desarrollo:

donde L = el nmero de instrucciones fuente producidas.

E = el esfuerzo durante todo el ciclo de vida en aos/persona
C = una constante dependiente de la tecnologa.
T = el tiempo de desarrollo en aos.
Los valores tpicos de C pueden ser: C = 2.000 para un entorno pobre de
desarrollo de software (sin metodologa, con una documentacin y unas
revisiones pobres); C = 8.000 para un buen entorno de desarrollo de
software (con una buena metodologa, adecuadas documentacin y
revisiones); C = 11.000 para un entorno excelente (con herramientas y
tcnicas automticas). Se puede obtener la constante C correspondiente al
entorno propio a partir de datos histricos recopilados sobre anteriores
esfuerzos de desarrollo.
8.2.3 MODELOS COMPUESTOS
Son modelos que utilizan una combinacin de intuicin, anlisis estadstico
y juicio de expertos. Entre los ms importantes estn:
a) Modelo COCOMO de Boehm.
Es probablemente el ms conocido y slidamente documentado de todos los
modelos de estimacin de costes. Por lo que desarrollaremos este modelo a
ms detalle.
Este modelo se aplica a los desarrollos que siguen el ciclo de vida en
cascada, e incorpora dentro de esas etapas procesos como: Verificacin y
Validacin, Gestin de Configuracin.
Existen tres modos de desarrollo de software segn COCOMO: orgnico,
semilibre y rgido, segn las caractersticas de la aplicacin y del entorno de
desarrollo. A cada uno de estos modelos se le puede aplicar tres mtodos de
estimacin distintos: bsico, intermedio y detallado.
Cuando un ingeniero de software est ante un proyecto a estimar, lo
primero que debe hacer para aplicar el COCOMO es situar su proyecto en el
espacio de dos dimensiones (modo, modelo) de la Figura 6.1.
En la Figura 6.1, Px es un proyecto que va a ser desarrollado segn un
modelo Semilibre, dado el tipo de aplicacin y el equipo del que se dispone,
y se va estimar segn COCOMO Detallado, dada la exactitud que se requiere
de la estimacin.

6.2.

Modos
de
Desarrollo
Software

de

Este modelo considera tres modos distintos de desarrollo de software:

6.2.1. Modo Orgnico
Este modo se caracteriza por lo siguiente:

El proyecto se desarrolla en equipos relativamente pequeos en un

entorno familiar, en la propia empresa.
Muchas personas relacionadas con el proyecto tienen amplia
experiencia trabajando en sistemas similares dentro de la propia
organizacin y tienen un buen conocimiento de cmo el sistema que
se est desarrollando contribuir a los objetivos de la Organizacin.
Esto significa que muchas personas podrn contribuir al proyecto
desde las primeras etapas, sin generar una sobrecarga de
comunicacin importante.
Se desarrolla en un entorno generalmente estable, con muy pequea
probabilidad de coincidencia en el desarrollo de un nuevo hardware u
operaciones desconocidas.
Mnima motivacin para terminar el proyecto antes de lo previsto.

6.2.2. Modo Semilibre

Este modelo se caracteriza por lo siguiente:

El equipo del proyecto tiene un nivel medio de experiencia en

proyectos similares.
El equipo es una combinacin de personal experto e inexperto.
Algunos miembros del proyecto tienen alguna experiencia en
aspectos del proyecto y otros no.
El tipo de proyectos representativo podra ser un sistema de proceso
de transacciones con interfaces muy poco rigurosas en algunos casos
y muy rgidas en otros.

6.2.3. Modo Rgido

Los elementos caractersticos de este modo de desarrollo son:

Proyectos que deben desarrollarse dentro de unas limitaciones muy

estrictas.
El producto debe explotarse dentro de un entorno muy acoplado de
hardware, software, normativa y procedimientos operativos.
Los costes de cambiar algo en este complejo entramado son tan
altos, que sus caractersticas se consideran inmodificables, as que el
software
debe
realizarse
estrictamente
conforme
a
las
especificaciones.
Estos proyectos se desarrollan en reas generalmente desconocidas,
lo cual lleva inicialmente a equipos pequeos de analistas y a una
sobrecarga de comunicacin importante durante el desarrollo. Se
aplica a proyectos de cualquier tamao

6.3.1. Modelo Bsico

Se suele aplicar en los desarrollos de productos pequeos/medios,
desarrollados por personal de la propia empresa en modo orgnico. Aunque
tambin puede aplicarse al resto de los modos. Las ecuaciones de
estimacin de esfuerzo y tiempo de desarrollo para cada modo de
desarrollo:

Donde,
KDSI
de instrucciones de cdigo en miles.
MM significa esfuerzo medido en Meses/Hombre.
TDEV significa duracin en Meses.

significa

nmero

6.3.2. Modelo Intermedio

El modelo intermedio incorpora 15 variables de prediccin que influyen en el
coste del proyecto. Estas variables se agrupan en cuatro categoras:
atributos del producto software, atributos del ordenador, atributos de
personal y atributos del proyecto.
6.3.2.1. Atributos del Producto Software

RELY : Fiabilidad requerida del software.

DATA : Tamao de la base de datos.
CPLX : Complejidad del Producto.

6.3.2.2. Atributos del Ordenador

TIME : Limitaciones en el Tiempo de Ejecucin.

STOR : Limitaciones de Memoria Principal
VIRT : Volatilidad de la Mquina Virtual.
TURN : Frecuencia de cambio en el modelo de explotacin del
ordenador.

6.3.2.3. Atributos de Personal

ACAP : Capacitacin de los Analistas.

AEXP : Experiencia en Aplicaciones.
PCAP : Capacitacin de los Programadores.
VEXP : Experiencia en la Maquina Virtual.
LEXP : Experiencia en el Lenguaje de Programacin.
6.3.2.4. Atributos del Proyecto
MODP : Prcticas Modernas de Programacin
TOOL : Uso de herramientas para el Desarrollo de Software
SCED : Limitaciones en la planificacin.

La estimacin de esfuerzo aplicando este modelo es:

El tiempo de desarrollo TDEV se calcula como en el Modelo Bsico.

6.3.3. Modelo Detallado

El Modelo Intermedio tiene dos limitaciones que pueden ser significativas en
la estimacin detallada de coste en grandes proyectos de software:

La distribucin de esfuerzo por fases puede ser inadecuada.

Puede ser muy engorroso utilizarlo en un producto con muchos
componentes.

El modelo detallado presenta dos funcionalidades que resuelven las

limitaciones de COCOMO
Intermedio:

l. Multiplicadores de esfuerzo por fases:

El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo
para cada atributo en cada fase. Estos multiplicadores determinan el
esfuerzo requerido para completar cada fase.

2. Descomposicin jerrquica del producto a tres niveles.

El COCOMO detallado evita este problema proporcionando una jerarquizaron
del producto a tres niveles:

Nivel mdulo.
Nivel subsistema.
Nivel sistema.

No se desarrolla este modelo dado que su aplicacin queda reservada a

grandes proyectos no muy frecuentes.
c) SPQR - Capers Jones
Capers Jones ha desarrollado un modelo de estimacin de costes llamado
Software Productivity, Quality and Reliability (SPQR).
El enfoque del problema es similar al de Boehm en su modelo COCOMO.
Est basado en 20 factores que influyen razonablemente en el coste y
productividad del desarrollo de software y que estn bien definidos y otros
25 factores que no estn tan bien definidos.
SPQR es un producto comercial, pero no est tan bien documentado como
otros modelos. Requiere responder a ms de 100 preguntas relacionadas
con el proyecto para formular los parmetros de entrada necesarios en el
clculo de los costes y los planes. Jones seala que con este modelo es
posible proporcionar estimaciones de coste que estarn el 90% de las veces
dentro del valor real con una desviacin del 15%.

d) COPMO - Thebaut
Thebaut propone un modelo de desarrollo de software que intenta
contabilizar el esfuerzo requerido cuando los equipos de programacin
estn involucrados en grandes proyectos. La ecuacin general de clculo de
esfuerzo es:

donde
a, b, c y d son constantes para ser determinadas a partir de datos empricos
mediante anlisis de regresin:

S es el tamao del programa en miles de LOC

P es el nivel medio de personal durante el ciclo de vida del proyecto.

Desafortunadamente, este modelo requiere no uno sino dos parmetros

cuyos valores no son conocidos hasta la terminacin del proyecto. Adems,
las constantes b y c dependientes de la complejidad del software no son
fcilmente determinables.
Este modelo presenta una formula interesante, pero necesita un mayor
desarrollo y ajuste para que sea de inters general.