Estimacion

Estimacin de Proyectos Software
ESTIMACIN DE PROYECTOS
SOFTWARE
ANA M MORENO S.- CAPUCHINO
Ana M Moreno S.-Capuchino
Pg. 1
CONTENIDO
TEMA 1:
INTRODUCCIN
TEMA 2:
ESTIMACIN DE SOFTWARE
TEMA 3:
MTRICAS DE SOFTWARE
TEMA 4:
TCNICAS DE ESTIMACIN
TEMA 5:
MTODO DE ESTIMACIN
DE PUNTOS DE FUNCIN
TEMA 6:
MTODO DE ESTIMACIN COCOMO
BIBLIOGRAFA
Pg. 2
TEMA 1:
INTRODUCCIN
Pg. 3
1.1. Marco de la Gestin de Proyectos.

Durante muchos aos el proceso de desarrollo de software ha sido considerado como un arte dejado a la
improvisacin del jefe del proyecto. Los proyectos se dirigan ms bajo consideraciones tcnicas, que de
gestin. 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. Mientras los proyectos han sido de complejidad
media la euforia de la tecnologa ha dominado el mercado. 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.
El continuo incremento de la potencia de los ordenadores ha hecho posible concebir sistemas cada vez ms
complejos. El cerebro humano tiene solamente una capacidad limitada para manejar tales sistemas, y esto puede
aplicarse igualmente al desarrollo del software para tratarlos. Adems, como puede verse en la Figura 1.1,
conforme los costes del hardware disminuyen, el coste de producir el software tiene un mayor peso dentro del
coste del proyecto.
Conforme los costes de desarrollo y mantenimiento del software crecen es necesario predecirlos y controlarlos.
Esto es algo que hasta el momento los constructores de software han encontrado muy difcil de realizar.
Otro problema existente es que no es siempre posible evitar errores en los sistemas complejos, lo cual puede
producir costes elevados, y perdidas fatales. El software controla actualmente sistemas mdicos, trfico areo,
sistemas financieros o sistemas de misiles. Los errores en estos sistemas pueden implicar serios desastres. Los
ejemplos son innumerables en todos los dominios de la aplicacin de las Tecnologas de la Informacin, como se
ha visto en la Unidad de Introduccin a la Ingeniera del Software.
Segn ha crecido la experiencia en la construccin de los sistemas software, se han elaborado tcnicas para el
desarrollo de las especificaciones y el diseo. Estas disciplinas pueden, en la actualidad, ensearse y aplicarse
segn reglas muy precisas. Sin embargo, se ha puesto de manifiesto que el uso sistemtico de estas tcnicas para
la especificacin y el diseo de software no ha resuelto el problema de la produccin del software. En la industria
se sigue hablando de "crisis del software"; la cantidad de esfuerzo perdido en el desarrollo de software continua
en situacin similar a hace aos y los productos a menudo son entregados con errores significativos que producen
costes y peligros graves.
El hecho es que no es suficiente avanzar a travs de las etapas tradicionales del proceso de construccin de
software y esperar un producto satisfactorio al final del mismo. El proceso de produccin del software tiene que
ser gestionado y dirigido de una manera extremadamente rigurosa y cuantitativa. De este modo se podr verificar
que el trabajo correspondiente a cada fase se ha realizado completamente dentro de los plazos de tiempo y coste
establecidos y de acuerdo con estndares especficos de calidad.
Pg. 4
Coste
100
80
Desarrollo
60
40
Software
20
Mantenimiento
Ao
1955
1975
1995
Figura 1.1. Relacin de costes Hw/Sw
Por lo tanto, las claves del xito en la gestin del desarrollo de software son: una adecuada gestin del proyecto
de desarrollo de software y una adecuada gestin del proceso de software.
Qu entendemos por gestin del proyecto de desarrollo de software?
La gestin del proyecto consiste en la utilizacin de las tcnicas y actividades de gestin requeridas
para conseguir un producto software de alta calidad, de acuerdo con las necesidades de los usuarios,
dentro de un presupuesto y con una planificacin de tiempos establecidos previamente.
Qu es entonces, la gestin del proceso del software?
La gestin del proceso es el conjunto de tcnicas y actividades que permiten una adecuada gestin de
los procesos personales de los constructores y de los productos que participan en el proyecto.
A lo largo de esta Unidad y en las Unidades de Planificacin y Seguimiento profundizaremos en los conceptos de
la gestin de proyectos. Veremos las actividades que lo componen y cmo llevarlas a cabo eficazmente. La
gestin del proceso se ver cuando se explique el propio proceso de desarrollo.
En primer lugar daremos una definicin rigurosa de proyecto.
Un proyecto es una accin en la que recursos humanos, financieros y materiales se organizan de una
nueva forma para acometer un trabajo nico. En este trabajo, dadas unas especificaciones y dentro de
Pg. 5
unos lmites de costes y tiempo, se intenta conseguir un cambio beneficioso dirigido por unos objetivos
cualitativos y cuantitativos.
El aspecto esencial de un proyecto es el ser un trabajo nico que se realiza con una nueva organizacin para
producir un cambio beneficioso. Estos elementos implican que un proyecto lleva una incertidumbre considerable
y riesgo, y por lo tanto su xito depender en gran medida de una adecuada gestin.
1.2. Tareas Crticas en la Gestin de Proyectos.

El nmero de tareas identificables a realizar por un director de proyectos, dentro del rea de la gestin de
proyectos excede de cien. Sin embargo, hay tres que son crticas y que deben ser desarrolladas correctamente
si se desea que el proyecto termine bien.
Estas tareas son:
a) Estimacin de duracin, coste y esfuerzo necesarios para construir el producto.
b) Planificacin de tareas a realizar, asignacin de personas, tiempos, etc. para construir el producto.
c) Seguimiento, durante la realizacin del trabajo, para asegurar el cumplimiento de lo planificado en
cuanto a costes, fechas, etc. En caso de desviaciones del plan, se deben tomar las medidas
pertinentes.
1.2.1. Estimacin de Proyectos

La primera tarea en la gestin de proyectos es la estimacin.
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.
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.
1.2.2. Planificacin de Proyectos

La planificacin de un proyecto se define como el proceso de seleccin de una estrategia para la produccin
de unos productos finales dados, as como la definicin de las actividades a realizar para conseguir ese
objetivo, la concurrencia y solapamiento de dichas actividades. Tambin debe asignar recursos a las
actividades anteriores en funcin del plan establecido.
Pg. 6
La estimacin y la planificacin son actividades relacionadas pero difieren en su alcance y propsito. La

estimacin normalmente est orientada al proyecto en su conjunto, mientras que la planificacin esta dirigida
a los individuos. Obviamente, debe existir una fuerte correlacin entre la estimacin realizada y las tareas
especficas a realizar da a da por el equipo de proyecto. La estimacin la realizaremos al principio del
proyecto, precisamente para pedir presupuesto, saber cunta gente se necesita, otros recursos, etc., y la
planificacin es la etapa donde se asigna exactamente quin hace qu y en cuanto tiempo. Algo as como:
Cunto tiempo y dinero necesito para conocer Pars?, 10 das y 500.000 pesetas. Esto es una estimacin.
El primer da voy al aeropuerto a las 10 horas, cojo el avin y llego a Pars a las... es una planificacin.
Una diferencia tcnica entre las herramientas de planificacin y estimacin es que estas ltimas son
normalmente sistemas expertos, construidos a partir de las reglas derivadas de miles de proyectos. Las
herramientas para la planificacin, en cambio, no son sistemas expertos, sino herramientas para ser utilizadas
por personas expertas. La razn para esta diferencia es que las herramientas de estimacin estn basadas en
miles de proyectos y pueden llegar a alcanzar una gran exactitud, pero el trabajo da a da de las personas que
participan en el proyecto con sus conocimientos, planes de vacaciones e interrupciones requieren un director
de proyectos expertos y casi con ajustes diarios de la planificacin. Se puede sacar una conclusin y es que
las herramientas de planificacin dan los mejores resultados con los mejores directores. En cambio, las
herramientas de estimacin pueden aumentar y mejorar las capacidades de los nuevos jefes de proyecto o de
los expertos cuando tienen que planificar proyectos en los que no existe una experiencia previa.
Las herramientas de planificacin son las ms utilizadas por los jefes de proyectos.
1.2.3. Seguimiento de Proyectos
El seguimiento es la recoleccin de datos y su almacenamiento, sobre tiempos, recursos, costes, e hitos
asociados con un proyecto, para el anlisis y estudio de la evolucin real de dicho proyecto, comparando el
progreso real con el planificado.
Desafortunadamente, el seguimiento de los proyectos de desarrollo de software no ha sido todo lo correcto
que cabra esperar.
Como ya se vio en otra Unidad, muchos sistemas son inexactos y entre el 35% y el 75% de los costes reales
del software no son registrados.
Las mayores omisiones en el seguimiento son debidos a:
Tiempo extra de profesionales no registrado.

Coste de viajes y reuniones.
Esfuerzo de los directivos.
Esfuerzo de los usuarios en tareas tcnicas, como escritura de manuales, pruebas o participacin en
revisiones.
Soporte administrativo.
Desarrollos iniciales antes de comenzar el proyecto.
Existen muchas ms, pero stos son una muestra de la situacin, y de la poca exactitud del seguimiento.
Pg. 7
As mismo, adems de la omisin de datos, la descripcin de cuentas utilizadas para acumular costes no es lo
suficientemente detallada como para llevar una contabilidad seria del proyecto. Algunos costes se acumulan
solamente como gasto del proyecto, y estn ms pensados para ser utilizados por los contables, que para
servir de ayuda a los jefes de proyectos.
1.2.4. Relacin entre las Actividades Clave de la Gestin de Proyectos
Los conceptos anteriores pueden dar la falsa impresin de que cada uno de los procesos descritos es
independiente, discreto y de que se aplican una sola vez. El hecho es que ste no es el caso. Cuando tenemos
una estimacin inicial sobre el proyecto que vamos a desarrollar, debemos de definir una planificacin para
el proyecto siempre dentro del marco de esa estimacin, es decir, la salida del proceso de estimacin debe ser
una de las entradas del proceso de planificacin. Una vez realizada la planificacin comenzaremos el
seguimiento del proyecto. Por lo tanto, las entradas del proceso de seguimiento sern la estimacin y
planificacin del proyecto, adems de los datos reales recogidos mientras evoluciona el proyecto. Durante la
realizacin del proceso de seguimiento se puede producir una replanificacin si nos apartamos del plan
original. Una fuerte desviacin durante el seguimiento puede ser la consecuencia, por ejemplo, de un cambio
en la naturaleza del proyecto. En ese caso, necesitaremos una reestimacin y replanificacin en
consecuencia, como muestra la Figura 1.2.
La gestin del desarrollo del software es ineficaz a causa de que dicho desarrollo es extremadamente complejo,
disponindose de pocas medidas para guiar y evaluar el proceso. De esta manera sin una estimacin eficaz y
exacta, la planificacin y el seguimiento eficaces son prcticamente imposibles de conseguir.
ESTIMACION
PLANIFICACION
SEGUIMIENTO
DESARROLLO
Figura 1.2. Relacin entre las Tareas de Estimacin

Planificacin y Seguimiento.
A partir de este momento, esta Unidad se centra en el proceso de Estimacin de software. Existen otras unidades
que tratan la Planificacin y el Seguimiento.
Pg. 8
TEMA 2:
ESTIMACIN DE SOFTWARE
Pg. 9
2.1. 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 es su infancia. La industria del software
sigue fuera de control, con costes y tiempos desmedidos.
Para hablar de las posibilidades actuales de la estimacin, primero debemos revisar su estado actual y explorar las
necesidades de la comunidad de desarrollo de software.
Qu es la estimacin?
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?
Cunto tiempo llevar hacerlo?
La respuesta a estas dos preguntas constituye el quid del tema que aqu se contempla. Sin embargo, y como se
puede prever sta no es tan sencilla.
Qu hace que la estimacin sea tan difcil de realizar?
Las razones para esta complejidad son las siguientes:
1.
No existe un modelo de estimacin universal o una formula que pueda ser usada para todas las
organizaciones. El hecho es que se pueden definir unos principios generales, pero cada interpretacin
es particular y diferente del resto. Cada organizacin tiene sus propios recursos, procedimientos e
historia; y es necesario ajustar los procesos de estimacin a esos parmetros nicos. Adems, a medida
que estos parmetros cambien, deben cambiar los procesos de estimacin.
2.
Hay muchas personas implicadas en los proyectos que precisan de estimaciones. La alta direccin de
la empresa necesita las estimaciones para tomar decisiones de negocio, sobre la viabilidad del proyecto
y su continuidad a lo largo del desarrollo. La direccin del proyecto necesita las estimaciones para
hacer sugerencias a la alta direccin, para obtener los resultados necesarios para el desarrollo del
proyecto, y para hacer una planificacin detallada y controlar el proyecto. Cada recurso del proyecto
tambin necesita estimaciones para planificar y controlar su propio trabajo.
3.
La utilidad de una estimacin tambin depender de la etapa de desarrollo en la que nos encontremos.
Al comienzo de un proyecto, normalmente slo se necesitan estimaciones de coste y duracin
aproximadas. A medida que el proyecto madura las estimaciones que se necesitan sern ms exactas.
Con lo que una estimacin til al comienzo del proyecto puede no serlo ms tarde.
Pg. 10
4.
La estimacin, a menudo, se hace superficialmente, sin apreciar el esfuerzo requerido para hacer un
trabajo. Adems, tambin se suele dar el caso de que la estimacin sea necesaria antes de obtener las
especificaciones de requisitos del sistema. Por esta razn, una situacin tpica es que se presiona a los
estimadores para que se apresuren en escribir una estimacin anticipada del sistema que no
comprenden an.
5.
Las estimaciones claras, completas y precisas son difciles de formular, especialmente al inicio del
proyecto. Los cambios, adaptaciones y ampliaciones son ms la regla que la excepcin: como
consecuencia de ello, deben adaptarse tambin las planificaciones y los objetivos.
6.
Las caractersticas del software y de su desarrollo hacen difcil la estimacin. Por ejemplo, el nivel de
abstraccin, la complejidad, el grado de medicin del producto y del proceso, los aspectos
innovadores,...
7.
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. Por ejemplo, son difciles de
predecir la influencia de nuevos bancos de pruebas, lenguajes de cuarta y quinta generacin,
estrategias de prototipado, y de tcnicas y herramientas novedosas en general.
8.
Un estimador puede no tener mucha experiencia en estimar desarrollos, especialmente de proyectos

largos. Cuntos proyectos largos puede alguien dirigir en, por ejemplo, 10 aos?
9.
Existe una tendencia aparente de los desarrolladores hacia la subestimacin. Un estimador suele elegir
una porcin de software debera tomar para luego extrapolarlo al resto del sistema, normalmente se
ignoran los aspectos no lineales del desarrollo de software, por ejemplo, la coordinacin y la gestin.
10.
El estimador estima el tiempo que le llevara ejecutar personalmente una tarea, ignorando el hecho de
que, a menudo, una parte del trabajo la realiza personal menos experimentado, con un ndice de
productividad menor.
11.
Existen malas interpretaciones en las relaciones lineales entre la capacidad requerida por unidad de
tiempo y el tiempo disponible. Esto significa que el software desarrollado por 25 personas en dos aos
podr ser llevado a cabo por 50 personas en un ao. Esta interpretacin es errnea. Como ya se
coment en otra Unidad una mujer puede dar a luz un nio a lo largo de 9 meses, pero 9 mujeres no
dan a luz un nio en un mes. Aadir personal a un proyecto retrasado no tiene por qu disminuir el
retraso.
12.
El estimador tiende a reducir en algn grado las estimaciones para hacer ms aceptable la oferta.
13.
Influyen un gran nmero de factores en el esfuerzo y duracin de un desarrollo de software. Estos

factores se llaman drivers de coste o disparadores de coste. Ejemplos de estos disparadores son el
tamao y complejidad del software, el compromiso y participacin del usuario, la experiencia del
equipo de desarrollo. En general estos disparadores de coste son difciles de determinar.
Pg. 11
Es importante profundizar ms en el tema de los disparadores de coste. Para mostrar su importancia, estudiaremos
a continuacin algunos de ellos repartidos en cinco categoras, como se muestra en la Tabla 2.1.
el producto software que se tiene que desarrollar: QU

el significado de la produccin: CON QU
el personal de produccin: QUIN
la organizacin de produccin: CMO
usuario/organizacin del usuario: PARA QUIN
QU
producto
Tamao del
software
Calidad requerida
Volatilidad de
requisitos
Complejidad del
software
CON QU
significado
Restricciones
del ordenador
- tiempo de
ejecucin
- tiempo de
respuesta
- capacidad de
memoria
Usuarios de
herramientas
Nivel de utilizacin
Cantidad de
documentacin
Tipo de aplicacin
Uso de tcnicas
modernas de
programacin
- ocultacin de
informacin
- equipo de
programacin
principal
- programac.
estructurada
- diseo top-down
QUIN
personal
CMO
proyecto
Calidad del personal Requisitos de la

duracin del
Experiencia del
proyecto
personal
- dilatacin
- compresin
Calidad de gestin
Bases para el control
Disponibilidad para del proyecto
el proyecto
- matriz de organizacin
- organizacin del
proyecto
- prototipado
- incremental
- desarrollo lineal
PARA QUIN
usuario
Participacin
Nmero de usuarios
Estabilidad de la
organizacin del
usuario,
procedimientos,
formas de trabajo
Experiencia del
usuario con la
informtica, nivel de
conocimientos
informticos
Tabla 2.1. Disparadores de coste

En la Tabla anterior podemos ver diversos tipos de disparadores, todos ellos influirn en la estimacin que
vallamos a realizar, lo realmente difcil es determinar cules son los disparadores de coste ms importantes en
cada situacin especfica, cules son sus valores y cmo influyen en el esfuerzo y la duracin de cada proyecto.
Para resolver estas cuestiones conviene tener en cuenta varios aspectos:
Definicin
Pg. 12
Hay una falta de definiciones claras y aceptadas de los disparadores, tales como tamao,
calidad, complejidad, experiencia,... Por ejemplo, cundo se dice que un desarrollador es
experimentado y cundo no.
Cuantificacin:
La mayora de los disparadores de coste son difciles de cuantificar. A menudo, se utilizan
medidas tales como: mucho, moderado, poco,...
Objetividad:
La objetividad es un factor de riesgo potencial. Lo que puede ser complejo para el
desarrollador A, puede no serlo para el B.
Correlacin:
Es difcil considerar un driver independiente de los dems. Un cambio en el driver A, puede
tener consecuencias en los valores de otros disparadores. Esta es una dificultad tremenda
desde el punto de vista de la medibilidad.
Relacin entre disparador y esfuerzo:
Para la estimacin es importante poder predecir la relacin entre, por ejemplo, el tamao del
software y el esfuerzo requerido, el nivel de calidad especificado y el esfuerzo requerido, etc.
Calibracin:
Es imposible hablar de los disparadores de coste ms importantes de forma aislada. Una
situacin difiere mucho de otra.
Todos estos aspectos pueden proporcionar una idea de la complejidad del proceso de estimacin. Sin embargo,
tambin se han destacado las consecuencias negativas de la falta de este proceso, y la importancia de su
aplicacin.
2.2 Requisitos que debe Cumplir un Buen Estimador

Quin debe realizar el proceso de estimacin de un proyecto software?
El estimador debe se 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:
1.
Debe poseer una importante formacin y experiencia profesional que le ayuden a entender y
solucionar los problemas de la gestin de proyectos.
Pg. 13
2.
Debe tener una posicin en la organizacin que le permita adoptar un juicio independiente.
3.
Debe basarse en un mtodo que pueda ser explicado, cuestionado, discutido y auditado por otros
expertos.
4.
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.
5.
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.
6.
Debe ser capaz de documentar su estimacin, incluyendo los resultados obtenidos y cualquier
informacin necesaria para hacer el proceso de estimacin repetible y verificarle.
2.3. Marco Temporal de la Estimacin de Proyectos

Cundo se debe realizar la estimacin de un proyecto software?
A continuacin veremos en qu momento del desarrollo de un proyecto se ha de realizar el proceso de
estimacin.
La estimacin, como ya hemos anticipado, es un proceso continuo. A medida que el proyecto avanza, ms se
conoce de l, y por lo tanto ms parmetros estn disponibles para introducir en un modelo de estimacin.
El grado de informacin sobre los parmetros del sistema sigue una curva en forma de "s" tpica, como se muestra
en la Figura 2.1.
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.
Ms precisamente, 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 "micro-caractersticas" del proyecto.
La naturaleza del proceso de estimacin cambia a medida que el programa progresa. Supongamos que
desarrollamos un proyecto con un ciclo de vida tradicional. Al principio, en la concepcin del sistema, slo
necesitamos estimaciones a grosso modo para determinar el tamao del proyecto y estudiar su viabilidad. 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. Como entrada para esta estimacin se
necesitan algunos parmetros descriptivos y genricos sobre el proyecto.
Pg. 14
Informacin
100
Instalacin
Concepcin
Vida del
producto
Software
Figura 2.1. Grado de Informacin sobre 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. En este momento, los parmetros descriptivos
y genricos que se emplean para hacer la primera estimacin se conocen ms exactamente, y tambin se dispone
de informacin adicional sobre los recursos que intervendrn en el desarrollo, como por ejemplo la experiencia de
los desarrolladores.Error! Marcador no definido.
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.
La Figura 2.2 muestra la exactitud con la que las estimaciones software se pueden hacer, en funcin de las fases
del ciclo de vida tradicional, o el grado de conocimiento que tenemos sobre lo que pretende hacer el software.
Pg. 15
Exactitud
4x
tipos de personas
y datos
tipo de consultas
carga de datos, tpo. de respuesta
esttructuras de datos internas
algoritmos detallados
entendimeitno de
especificaciones
2x
1.5x
1.25x
x
0.8x
0.67x
0.5x
0.25x
Especificacin
requisitos
Iniciacin
Viabilidad
Planificacin
y requisitos
Especificacin
de diseo
Diseo
producto
Especificacin
de diseo detallado
Diseo
detallado
Software
aceptado
Desarrollo y
pruebas
Fasess del
Software
Figura 2.2. Exactitud de las Estimaciones

a lo largo del Desarrollo.
Como puede verse en la Figura 2.2, cuando comenzamos a estudiar las distintas posibilidades para desarrollar un
nuevo sistema, las estimaciones pueden oscilar en un rango de cuatro veces por arriba o por abajo. Este rango
proviene de la gran incertidumbre que se tiene en este momento sobre la naturaleza real del producto. As, por
ejemplo, no se sabe qu tipo de personas (gestores, consultores, analistas,...) o qu tipos de datos (digitales o
analgicos, numricos o texto,...) soportarn el sistema.
Las incgnitas anteriores se conocen cuando finaliza la fase de viabilidad y se decide un procedimiento de
operacin. En este momento, el rango de nuestra estimacin disminuye en dos en cada direccin. Este rango es
razonable porque todava no se tiene informacin sobre los tipos de consulta que soportar el sistema, las
funciones concretas, etc. Estos elementos sern conocidos en el momento de realizar la especificacin de
requisitos, en el que la estimacin software estar en un rango de 1,5 en cada direccin.
En el momento en que hayamos completado y validado la fase de diseo del producto, tendremos informacin
sobre la estructura de datos interna del producto software, sobre las tcnicas para el manejo de buffers, etc. En
este momento la estimacin software tendr un rango de exactitud del 1,25. Existen todava incgnitas, como los
algoritmos que se usarn para la planificacin de tareas, el manejo de errores o los procedimientos de parada del
sistema. Estas sern conocidas al final de la fase de diseo detallado, pero existir todava una incertidumbre del
10% basada en la exactitud con la que los programadores entiendan las especificaciones que tienen que codificar.
Pg. 16
Para otros ciclos de vida como, prototipado o desarrollos en tiempo real, el proceso de estimacin sera muy
similar, y en todos ellos a medida que el proyecto progresa, la base de la estimacin y las salidas esperadas de este
proceso cambiarn.
2.4. Salidas del Proceso de Estimacin
En esta seccin intentaremos dar respuesta a la siguiente pregunta.
Qu es lo que debemos estimar?
Cuando se habl de la definicin de estimacin, se vieron dos preguntas a las que este proceso deba dar
respuesta. Estas preguntas eran:
Cunto costar?
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?
Cmo impacta este proceso en el resto de los proyectos de la empresa?
Cul ser el esfuerzo para mantener este proyecto?
Cul ser el tamao del sistema? (lneas de cdigo)
Cuntos defectos tendr el producto?
Cunta documentacin ser generada?
Cul ser el esfuerzo para confeccionar dicha documentacin?
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. Sin
embargo, dada la rpida evolucin de los mtodos de desarrollo de sistemas y la creciente diversificacin de
alternativas hardware, es correcto suponer que esta lista aumenta constantemente.
Todos estos parmetros que se pretenden obtener, son en realidad medidas sobre el producto software, es decir
mtricas, de las que hablaremos en el tema siguiente.
Pg. 17
TEMA 3:
MTRICAS DE SOFTWARE
Pg. 18
3.1. Definicin de Mtrica

Podemos definir las Mtricas de Software o Medidas de Software como:
La aplicacin continua de tcnicas basadas en las medidas de los procesos de
desarrollo del software y sus productos, para producir una informacin de gestin
significativa y a tiempo. Esta informacin se utilizar para mejorar esos procesos y los
productos que se obtienen de ellos.
Como se puede observar, esta definicin cubre infinidad de aspectos relacionados con el desarrollo de
software. Las mtricas de software implican medir: medir involucra nmeros; el uso de nmeros para hacer
cosas mejor. Las mtricas de software pretenden mejorar los procesos de desarrollo del software y mejorar,
por tanto, todos los aspectos de la gestin de aquellos procesos. Estas medidas son aplicables a todo el ciclo
de vida del desarrollo, desde la iniciacin, cuando debemos estimar los costes, al seguimiento y control de la
fiabilidad de los productos finales, y a la forma en que los productos cambian a travs del tiempo debido a la
aplicacin de mejoras. Las mtricas incluyen el uso de tcnicas por parte de ingenieros de software y
programadores para detectar y corregir anticipadamente los errores de los distintos componentes de los
productos, antes de llegar a la codificacin. Adems las mtricas controlan el progreso del proyecto, de tal
manera que lo que pueda ocurrir seis meses ms tarde se pueda identificar tan pronto como sea posible.
Esencialmente, las Mtricas de Software se aplican al producto software y a los procesos mediante los que se
desarrolla. El producto software debera ser visto como un objeto abstracto que evoluciona desde una
definicin inicial de necesidades hasta un sistema terminado, que incluyen codificacin, fuente y objetos, as
como los distintos documentos producidos durante el desarrollo. A menudo, estas medidas de los procesos de
desarrollo y de los productos software son estudiadas para su utilizacin en la monitorizacin de dichos
procesos.
Por tanto, las medidas del software y los modelos de medida son entonces tiles para estimar y predecir
costes y para medir la productividad y la calidad del producto.
3.2. reas de Aplicacin

Para qu podemos utilizar las mtricas?
Hay diferentes formas en las que pueden ser utilizadas las Mtricas de Software, algunas de las cuales
constituyen una especialidad por si solas.
La ms consolidada de las reas en el estudio de las mtricas es la correspondiente a las tcnicas de
estimacin de costes y tamao. Existen distintos paquetes en el mercado que proporcionan estimacin del
tamao del software a desarrollar, coste de desarrollo del sistema y duracin del proyecto de desarrollo o
mejora del software.
Pg. 19
Estos paquetes estn basado en modelos de estimacin y el ms conocido es el COCOMO, desarrollado por
Barry Boehm en 1981 aunque existen otros como son ESTIMACS, SOFTCOST, SPQR o COPMO, que se
explicarn posteriormente.
Existe una gran cantidad de investigacin sobre esta rea en EE.UU., Europa y otros lugares. Hay
organizaciones especialmente interesadas en la implantacin de mtricas en el desarrollo de software, por
ejemplo el Departamento de Defensa de EE.UU.
El control de proyectos de desarrollo de software a travs de medidas es un rea que esta generando un gran
inters tanto en Europa como en EE.UU. Este es un tema que ha alcanzado un inters relevante con el
incremento de contratos a precio fijo para desarrollar un producto software y la utilizacin de clusulas de
penalizacin en los mismos en caso de retrasos, sobrecostos, etc...
La prediccin de los niveles de calidad del software, a menudo en trminos de fiabilidad, es otra rea en que
las Mtricas de Software tienen un importante papel que jugar.
El uso de las Mtricas de Software en proporcionar una verificacin cuantitativa del diseo del software es
otra rea bien definida. Estas mtricas no se van a estudiar en esta Unidad sino en la Unidad de Diseo.
Recientemente se ha estudiado el efecto de los factores del entorno en la eficacia de los procesos de
desarrollo. Esta opcin no esta abierta para todas las organizaciones, pero existe una gran preocupacin sobre
como incrementar la productividad de los procesos de desarrollo, introduciendo cambios en el entorno en el
cual aquellos tienen lugar. Las medidas pueden ser utilizadas para identificar donde deberan concentrarse
los cambios.
La utilizacin de las Mtricas para comparar unas organizaciones con otras es un rea de aplicacin muy
importante. CSC-Index en Europa y el Software Engineering Institute en EE.UU. ofrecen este tipo de
servicios a la industria y muchas organizaciones los utilizan. Un resultado de esta aplicacin es que se puede
identificar qu se est haciendo mal y quin lo esta haciendo bien y aprender de esas empresas.
Finalmente, el uso ms comn de las medidas de software es la provisin de informacin de gestin, que
incluye datos acerca de la productividad, calidad y eficacia de los procesos. El valor de esta informacin est
en analizar los datos de las tendencias, da a da. Est mejorando o empeorando la calidad de un equipo de
desarrollo? Si es as, por qu ocurre? qu puede hacer la direccin para mejorar la situacin?
Este campo ofrece pues importantes aspectos para mejorar la calidad de los procesos de desarrollo de
software.
3.3. Caractersticas de las Mtricas de Software
La calidad de las medidas debera facilitar el desarrollo de modelos que sean capaces de predecir el
comportamiento de determinados parmetros que afectan al desarrollo de productos o de procesos.
Una medida ideal debera ser:
Pg. 20
Objetiva.
Sencilla, definible con precisin para que pueda ser evaluada.
Fcilmente obtenible (a un coste razonable).
Valida, la mtrica debera medir exactamente lo que se quiere medir y no otra cosa.
Robusta. Debera de ser relativamente insensible a cambios poco significativos en el proceso o
en el producto.
Adems, para una mejor utilizacin de estas medidas, a la hora de realizar estudios analticos o anlisis
estadsticos deberan de tener unos valores que se ajusten a una cierta escala de medida.
3.4. Clasificacin de las Mtricas del Software

Las Mtricas de Software se pueden clasificar, de una manera general, en Mtricas de producto y Mtricas de
proceso.
Las Mtricas de producto son medidas del producto software durante cualquier fase de su desarrollo, desde
los requisitos hasta la instalacin.
Las Mtricas de producto pueden medir la complejidad del diseo, el tamao del producto final (fuente u
objeto) o el nmero de pginas de documentacin producida.
Las Mtricas de proceso, son medidas del proceso de desarrollo del software tales como tiempo de desarrollo
total, esfuerzo en das/hombre o meses/hombre de desarrollo del producto, tipo de metodologa utilizada o
nivel medio de experiencia de los programadores.
Adems de esta clasificacin de las mtricas, se pueden categorizar de otras formas. Por ejemplo, por la
diferencia de las propiedades objetivas y subjetivas.
De una manera general las medidas objetivas deberan tener siempre un valor igual para una medida dada,
cuando es medida por dos o ms observadores cualificados. Para medidas subjetivas, aun observadores
cualificados pueden incluir diferentes valores para una medida dada, ya que sus juicios personales estn
involucrados en la obtencin del valor medido.
As por ejemplo, el tamao del producto medido en lneas de cdigo (LOC) es una medida objetiva del
producto, ya que cualquier observador que trabajara con la misma definicin de LOC, debera obtener el
mismo valor para un programa dado.
Un ejemplo de medidas subjetivas del producto es la clasificacin del software segn el modelo de
estimacin de costes de Boehm (COCOMO) en orgnico, semilibre o rgido.
Para medidas de procesos, el tiempo de desarrollo es una medida objetiva y el nivel de experiencia de un
programador es una medida subjetiva.
Pg. 21
Otra forma de clasificar las mtricas puede ser en mtricas primitivas o mtricas calculadas. Las mtricas
primitivas son aquellas que pueden ser observadas directamente, tales como las lneas de cdigo, nmero de
defectos observados en una prueba unitaria o el tiempo de desarrollo total de un proyecto. Mtricas
calculadas son aquellas que no pueden ser observadas directamente sino que se obtienen a partir de otras.
Ejemplos de este tipo de medidas pueden ser las utilizadas en la expresin de la productividad como lneas
de cdigo producidas por una persona durante un mes o para la calidad del producto, el nmero e errores por
cada mil lneas de cdigo. Las mtricas calculadas son combinaciones de otros valores de medidas y son
valiosas para comprender o evaluar los procesos del software.
3.5. Mtricas de Productos

Muchos de los trabajos iniciales realizados sobre las mtricas de producto estn relacionados con las
caractersticas del cdigo fuente. Conforme se ha ido ganando experiencia con las mtricas y los modelos se
ha puesto de manifiesto que la informacin disponible durante los primeros momentos del ciclo de desarrollo
puede ser de gran valor para controlar el proceso y los resultados.
Vamos a analizar, de todos los tipos de medidas utilizadas en la medicin del producto software, nicamente
aquellas que nos interesen para realizar el proceso de estimacin del software, que sern las mtricas del
tamao, y en cierto grado las de calidad.
3.5.1 Mtricas del Tamao
Existe un cierto nmero de mtricas que intentan cuantificar el tamao del software. La mtrica ms
utilizada, lneas de cdigo, tiene el inconveniente obvio de que sus valores no pueden ser medidos hasta que
el proceso de codificacin ha finalizado. Los Puntos de Funcin, y los Bang de DeMarco tienen la ventaja de
ser medibles durante los primeros pasos del desarrollo.
El estado actual en el estudio de las medidas del tamao es:
Existe un cierto consenso en cuanto a las medidas de la longitud, pero no en cuanto a las medidas de las
especificaciones o diseo.
Existen algunos trabajos de medicin de las funcionalidades de las especificaciones (que se aplican
igualmente al diseo y a los programas)
Existen muy pocos trabajos en cuanto a la medida de la complejidad del problema a resolver. Ntese que
este concepto es distinto que el de complejidad computacional, por tanto el trabajo hecho en esa rea no
sirve.
A continuacin, vamos a analizar las medidas ms utilizadas en la determinacin del tamao del software.
a) Lneas de Cdigo: La medida ms utilizada de la longitud del cdigo fuente de un programa es el
Nmero de Lneas de Cdigo (Lines of Code en ingles, abreviado LOC). Sin embargo, esta mtrica puede
Pg. 22
calcularse de muchas maneras. Estas diferencias afectan al tratamiento de las lneas en blanco y las lneas de
comentarios, las sentencias no ejecutables, las instrucciones mltiples por lnea y las mltiples lneas por
instruccin. Adems, deberan contarse las lneas reusables de cdigo.
La definicin ms comn es la siguiente:
Una lnea de cdigo es cualquier lnea de un texto de un programa que no es un
comentario o lnea en blanco, sin tener en cuenta el nmero de instrucciones o parte de
instrucciones en la lnea.
Esta definicin incluye todas las lneas que contienen cabeceras de programas, declaraciones e
instrucciones ejecutables y no ejecutables. Esta medida se suele representar por NCLOC (No
Comentary Lines of Code).
Sin embargo, en algunos casos, por ejemplo cuando deseamos conocer qu capacidad de almacenamiento
que necesitamos para el cdigo fuente o cuntas pginas vamos a imprimir, esta medida debe incluir los
comentarios.
Como puede verse no es una medida que refleje la longitud real de un programa. Su justificacin est en el
uso que se ha hecho de ella en ciertos modelos para determinar el esfuerzo desde el punto de vista de evaluar
la productividad. Sin embargo, si queremos conocer la longitud real del programa esta seria:
LOC = NCLOC + CLOC
donde CLOC (Comentary Lines of Code(es el nmero de lneas de comentarios.
Una medida indirecta de la densidad de comentarios seria:
CLOC / LOC
En general, es interesante obtener ambas medidas (NCLOC Y LOC) ya que expresan diferentes conceptos.
Cuando se intenta utilizar esta medida (lneas de cdigo) en trminos de productividad surgen dos
problemas:
a) No se tiene en cuenta el concepto de reutilizacin.
b) No se tiene en cuenta el concepto de costes fijos ni
instrucciones.
tareas que se desarrollan que no producen
Por ello, no debe ser utilizada esta medida directamente en la estimacin de esfuerzo o productividad.
Cuando se est buscando la nocin pura de longitud existen dos alternativas aceptables si se quiere utilizar
bajo el concepto de ratio:
1.
Medir la longitud en trminos de nmero de bytes de almacenamiento requerido para contener el

texto del programa.
Pg. 23
2.
Medir la longitud en trminos de nmero de caracteres en el texto del programa. (CHAR, del ingls
Character)
Si se conoce el nmero medio de caracteres por lnea de texto, NL; el nmero de lneas sera:
LOC = CHAR/NL
b) Especificaciones de diseo: La definicin de medidas anlogas a la de longitud para las especificaciones
y los documentos de diseo no es fcil. Al comienzo del ciclo de vida, tales documentos consisten en una
infinidad de texto, grafos, diagramas matemticos y smbolos. La naturaleza de aquellos depender en
particular del estilo, el mtodo o la notacin utilizada. Unas especificaciones o un diseo, estn compuestos
por textos o diagramas, los cuales parecen inmedibles con relacin a la longitud.
Una medida que se ha utilizado para permitir las comparaciones es la del Nmero de Pginas. Sin embargo,
la unidad pgina no puede ser formalmente definida si se desea incluir textos y diagramas.
Si un documento de especificaciones o de diseo est compuesto de textos y diagramas donde estos ltimos
tienen una sintaxis uniforme, entonces se podra representar la longitud del texto y la de los diagramas.
Tambin se pueden utilizar objetos o elementos atmicos representativos para los distintos tipos de
diagramas y smbolos.
As, DeMarco identifica en la fase de especificaciones tres vistas del sistema con relacin a cuatro tipos de
diagramas y seis elementos bsicos:
Visin
Diagrama
Elemento Bsico
Funcional
Diagrama de Flujo de Datos

Diccionario de Datos
Burbuja
Dato elemental
Datos
Diagrama E/R
Objetos y relaciones
Estado
Diagrama de Transicin
de estado
Estados y
transiciones
Sin embargo, no existen medidas de longitud relativas a dichas funciones primitivas. Por tanto, puede decirse
que, hoy por hoy, no existe una mtrica para comparar especificaciones ni diseos.
c) Prediccin de la longitud.
Existen una serie de modelos que veremos mas adelante para la prediccin del coste, que dependen de la
habilidad para predecir la longitud (NLOC) con exactitud en la fase de definicin de especificaciones del
sistema a implantar.
Un modo intuitivo de predecir la longitud es obteniendo una relacin entre la longitud de los distintos
productos obtenidos durante el ciclo de vida. En particular, una prediccin de longitud, se puede obtener
Pg. 24
considerando la relacin ratio de expansin entre la longitud de las especificaciones o del diseo y la
longitud del cdigo en proyectos similares de los que se mantienen datos.
Ha habido algunos intentos para establecer relaciones empricas entre la longitud del cdigo de programas y
la longitud de la documentacin.
d) Funcionalidad.
El concepto de funcionalidad de un producto se origina a partir de una nocin intuitiva de la cantidad de
funciones que proporciona.
Ha habido dos intentos serios para medir la funcionalidad de un producto software. Uno de ellos se debe a
Albrecht y corresponde a los Puntos de Funcin (FPA, del ingls Function Point Analysis)) y otro debido a
DeMarco, los Bang, que no ha tenido una gran difusin.
El objetivo ms importante es identificar una medida del tamao del software que pueda ser la variable
predominante en los sistemas de prediccin de costes y esfuerzo, as como en la evaluacin de la
productividad. Este es un objetivo encomiable, ya que una medida de la funcionalidad sera claramente
preferible a la medida del tamao exclusivamente de la longitud. En ambos casos, los productos cuya
funcionalidad est siendo medida son documentos de especificacin, pero que podan aplicarse
posteriormente a otros productos del ciclo de vida. La funcionalidad, a pesar de los problemas existentes, es
un atributo muy importante del producto y es la mejor aproximacin existente hasta la fecha.
3.5.2. Mtricas de Calidad
Se puede generar una larga lista de caractersticas de la calidad del software: correccin, eficacia,
portabilidad, mantenibilidad, fiabilidad, etc.
Desafortunadamente, las caractersticas a veces se solapan y entran en conflicto unas con otras. Por ejemplo,
incrementar la portabilidad, que es muy deseable, puede dar lugar a una eficacia menor.
Aunque se han realizado una gran cantidad de trabajos en esta rea, presenta una gran variedad en los
caminos seguidos frente a otras reas de investigacin de las mtricas, tales como el tamao de software o la
complejidad, cuyo estudio ha sido ms uniforme.
Han tenido considerable atencin tres reas:
Correccin de los programas, medida como el nmero de defectos.

Fiabilidad del software, calculada a partir del dato anterior.
Mantenibilidad del software, que se mide a partir otro conjunto de mtricas, incluidas las de
complejidad.
La calidad del software es una caracterstica que, tericamente al menos, puede ser medida en cada fase del
ciclo de desarrollo del software.
Estas mtricas de calidad se vern a lo largo del curso, en las Unidades de Calidad, Validacin, etc.
Pg. 25
3.6. Mtricas de Procesos

Estas mtricas evalan el proceso en s de fabricacin del producto correspondiente. Ejemplos de este tipo de
mtricas son el tiempo de desarrollo del producto, el esfuerzo que conlleva dicho desarrollo, el nmero y tipo
de recursos empleados (personas, mquinas,...), el coste del proceso, etc.
La obtencin de este tipo de mtricas est asociada generalmente a alguna tcnica de estimacin. En el
siguiente tema describiremos las tcnicas bsicas de estimacin, y los mtodos que se pueden aplicar.
3.7. Conclusin
Desde el punto de vista de la estimacin de software, la clasificacin ms til de mtricas es la que distingue
en mtricas del producto y del proceso.
De las mtricas del producto, las que realmente nos interesan son las de Nmero de Lneas de Cdigo y los
Puntos de Funcin de Albrecht. La primera mtrica es interesante porque sirve de punto de partida de
diversos mtodos de estimacin como el Mtodo COCOMO, que se ver en el TEMA 6 de esta Unidad
llamado Mtodo de Estimacin COCOMO. La segunda, est teniendo cada vez mayor importancia en la
estimacin de software, debido a que se ha demostrado en estos ltimos aos su utilidad para medir el
tamao de un producto software, y tambin en gran parte, debido a la labor del IFPUG que sirve de apoyo y
de soporte para todos los usuarios que apliquen la tcnica de los Puntos de Funcin.
El resto de mtricas del producto se han enunciado, simplemente para que el alumno tenga conocimiento de
ellas, sin necesidad de entrar ms en detalle.
En cuanto a las mtricas de procesos, como se ha indicado en el apartado anterior, suelen estar con alguna
tcnica de estimacin, que se estudiar en el siguiente tema.
Pg. 26
TEMA 4:
TCNICAS DE ESTIMACIN
Pg. 27
4.1. Visin General

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. Es decir, el ciclo de vida utilizado y las actividades han de ser similares. Si no es as, es difcil
hacer comparaciones proyecto-proyecto. Un proyecto puede haber comenzado siguiendo unos pasos totalmente
definidos y formalizados, y otro puede que slo tenga definida formalmente la fase de codificacin y pruebas, el
resto de las fases nadie sabe como se hicieron ni si se hicieron.
Por lo tanto, a menos que los proyectos tengan un esquema de proceso similar, compararlos unos con otros es
como comparar peras con manzanas. Es necesaria una estandarizacin para usar esta tcnica.
Otro aspecto a tener en cuenta es que los datos sobre esos proyectos han de ser fiables. Esto quiere decir que las
empresas correspondientes han de tener un programa formalizado para la toma de medidas sobre sus proyectos.
Actualmente es difcil que las empresas cumplan estos dos requisitos: estandarizacin de procesos y
formalizacin de la recogida de medidas. Hay que tener en cuenta que las empresas deberan haberlos implantado
desde hace algunos aos atrs, y que en estos momentos todava existen muchas empresas que no siguen una
metodologa de desarrollo y que tampoco intentan abordar la cuestin de la confeccin de un histrico de
proyectos.
Pg. 28
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.
4.2. Requisitos de un Buen Mtodo 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.
4.3. Mtodos 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 requieren una slida base
estadstica y diseo de experimentos. Para obtener resultados significativos es necesaria una definicin
precisa de las mtricas involucradas y de los procedimientos para la captura de datos.
Los experimentos a pequea escala deberan ser diseados cuidadosamente, y no aleatoriamente, utilizando
principios de diseo experimental.
Los experimentos muy largos son muy difciles de dirigir. Es esencial poseer una base slida de estadstica
para llevar a cabo experimentos significativos y analizar los datos resultantes. En general, si no se posee la
base estadstica suficiente debera de solicitarse la ayuda de estadsticos para evaluar seriamente el trabajo
realizado.
Pg. 29
Los modelos de estimacin existentes se pueden clasificar como Modelos Estadsticos, Modelos basados en
Teoras y Modelos Compuestos. A continuacin describiremos cada uno de ellos.
4.3.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:
E = 5,2 L0,9l
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.
Pg. 30
4.3.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:
E = L3/(C3 T4)
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.
4.3.3. Modelos Compuestos

Son modelos que utilizan una combinacin de intuicin, anlisis estadstico y juicio de expertos. A
continuacin se describen los ms importantes.
a) Modelo COCOMO de Boehm.

Es probablemente el ms conocido y slidamente documentado de todos los modelos de estimacin de
costes. En el TEMA 6. Modelo de Estimacin COCOMO se estudia en profundidad este modelo, con
aplicaciones prcticas.
b) SOFTCOST - Tausworthe
Tausworthe, de Jet Propulsion Laboratory, intent desarrollar una estimacin de coste del software utilizando
elementos de los modelos de ms xito disponibles. Este modelo requiere 68 parmetros de entrada, cuyos
valores se deducen a partir de las respuestas del usuario a 47 preguntas acerca del proyecto.
c) SPQR - Capers Jones

Capers Jones ha desarrollado un modelo de estimacin de costes llamado Software Productivity, Quality and
Reliability (SPQR).
Pg. 31
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:
E = a + bS + cPd
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.
Pg. 32
e) ESTIMACS - Rubin
Rubin ha desarrollado un modelo de estimacin que utiliza especificaciones del negocio para sus clculos. El
modelo proporciona estimacin del esfuerzo total, requisitos de personal, coste, riesgo y efecto sobre la
cartera de proyectos.
ESTIMACS ser analizado en la prctica de la asignatura.
Pg. 33
TEMA 5:
MTODO DE ESTIMACIN DE
PUNTOS DE FUNCIN
Pg. 34
5.1. Desarrollo de la tcnica de Puntos de Funcin

Los Puntos de Funcin miden el software cualificando la funcionalidad que proporciona externamente,
basndose en el diseo lgico del sistema. Por lo tanto, en el caso de subsistemas diseados
independientemente los Puntos de Funcin se calcularn para cada una de ellas, y luego se sumarn. Por
ejemplo, cuando un sistema que proporcione por un lado una funcionalidad on-line y por otro lado una
funcionalidad batch, y por tanto, se han diseado independientemente los dos subsistemas que proporcionan
cada funcionalidad.
Los objetivos de los Puntos de Funcin son:
Medir lo que el usuario pide y lo que el usuario recibe.

Medir independientemente de la tecnologa utilizada en la implantacin del sistema.
Proporcionar una mtrica de tamao que d soporte al anlisis de la calidad y la productividad.
Proporcionar un medio para la estimacin del software.
Proporcionar un factor de normalizacin para la comparacin de distintos software.
Adems de estos objetivos, el proceso de contabilizar los Puntos de Funcin debera ser:
Suficientemente simple como para minimizar la carga de trabajo de los procesos de medida.
Conciso en sus resultados.
El anlisis de los Puntos de Funcin se desarrolla considerando cinco parmetros bsicos externos del
Sistema:
1.
2.
3.
4.
5.
Entrada (EI, del ingls External Input).

Salida (EO, del ingls External Output).
Consultas (EQ, del ingls External Query).
Grupos de datos lgicos internos (ILF, del ingls Internal Logic File).
Grupos de datos lgicos externos (EIF, del ingls External Interface File).
Con estos parmetros, se determinan los puntos de funcin sin ajustar.

A este valor, se le aplica un Factor de Ajuste obtenido en base a unas valoraciones subjetivas sobre la
aplicacin y su entorno. Es decir las caractersticas generales del sistema.
La aplicacin de la tcnica de los Puntos de Funcin comprende los siguientes pasos:
Definicin de los lmites del sistema.
Definicin de parmetros.
Valoracin de la complejidad.
Anlisis de las caractersticas generales del sistema.
Pg. 35
5.2. Definicin de los Lmites del Sistema

El lmite es utilizado para definir el alcance del sistema y ayudar a identificar los parmetros externos.
Existen tres visiones de los lmites del sistema, dependiendo de la utilizacin que quiera realizarse de la
tcnica:
1 La aplicacin o lmite del producto.
Abarca a la totalidad de la aplicacin y se realiza la cuenta de puntos al final del desarrollo del
proyecto cuando se gestiona el grupo de mantenimiento o cuando la organizacin inicia el uso de
FPA. Este tipo de cuenta puede ser tambin obtenida de un sistema en funcionamiento.
2 Lmite inicial del proyecto a desarrollar.
Es un tipo de conteo similar al anterior, la diferencia est en que se deriva de los requisitos de un
sistema que no existe aun.
3 Lmite del proyecto de mejora.
Esta situacin surge cuando ya existe el sistema y se trata de obtener nuevas versiones del mismo.
La utilizacin de FPA en proyectos de mejora difiere de las anteriores en que se consideran
adiciones, modificaciones o anulaciones de funcionalidades, en lugar de la totalidad del sistema.
No se puede caer en la trampa de calcular los puntos del sistema total antes y despus de las
mejoras y luego substraer uno de otro.
Existe un elemento subjetivo en la determinacin de los lmites del sistema y obviamente un cambio en ellos
cambiar el total de Puntos de Funcin. Aunque esto podra parecer una aproximacin poco cientfica, en la
prctica la orientacin que el analista debera seguir es considerar el problema como un todo discreto.
La formula que permite calcular los Puntos de Funcin de un nuevo desarrollo es la siguiente:
FPA = FP X AF
Donde:
FP es el nmero de Puntos de Funcin sin ajustar de la aplicacin
AF es el Factor de Ajuste de la aplicacin
El clculo de los Puntos de Funcin de un proyecto de mejora se puede obtener mediante la formula:
(ADD+CHGA) * VAFA + (DEL * VAFB) = EFP
donde:
EFP es el nmero de Puntos de Funcin del Proyecto de Mejora.
Pg. 36
VAFB es el Factor de Ajuste de la aplicacin antes del proyecto de mejora.

ADD es el nmero de Puntos de Funcin de aquellas funciones que se aadirn al proyecto como
consecuencia de la mejora.
CHGA es el nmero de Puntos de Funcin sin ajustar de aquellas funciones que sern modificadas por el
proyecto de mejora. Este nmero refleja las funciones despus de la modificacin.
DEL es el nmero de Puntos de Funcin sin aquellas funciones que sern eliminadas en el proceso de
mejora.
VAFA es el Factor de Ajuste de la aplicacin despus del proyecto de mejora.
5.3. Definicin de Parmetros
Para poder determinar la existencia de los componentes que contribuirn al total final, hay que definirlos
previamente.
Estos componentes pueden ser clasificados como Tipos de Funciones y son de dos clases: Datos o
Transacciones.
5.3.1. Tipos de Funcin Datos

Representan la funcionalidad proporcionada a los usuarios para cumplir con sus requisitos de datos internos
y externos.
Son de dos tipos: Ficheros Lgicos Internos y Ficheros de Interface Externos.
5.3.1.1. Ficheros Lgicos Internos
Un Fichero Lgico Interno es un grupo de datos lgicamente relacionados identificables por los usuarios o
informacin de control mantenidos y utilizados dentro de los lmites de la aplicacin.
Por un grupo de datos lgicamente relacionados e identificables por un usuario se entiende aquellos datos
que un usuario experto podra identificar cumpliendo con un requisito especfico de la aplicacin.
Correspondera al almacn de datos identificado por un nombre en un Diagrama de Flujos de Datos. El
significado de almacn u Diagrama de Flujo de Datos se ver en las Unidades de Anlisis y Diseo.
Informacin de control corresponde a datos utilizados por la aplicacin cumpliendo con requisitos del
negocio.
Mantenidos es la habilidad para aadir, cambiar o borrar datos mediante procedimientos estandarizados a
travs de la aplicacin.
Pg. 37
Las reglas para identificar estos tipos de funcin son:

Regla 1
Regla 2
Regla 3
Regla 4
El grupo de datos o informacin de control es un grupo de datos lgico

identificable por el usuario que cubre de manera completa requisitos especfico
de ste
El grupo de datos es mantenido dentro de los lmites de la aplicacin
El grupo de datos es mantenido o modificado por medio de un proceso
elemental de la aplicacin
El grupo de datos identificado no se ha contado como un fichero interfase
externo de la aplicacin
Ejemplos de ILF son:

Ficheros maestros
Aplicaciones de Seguridad de Datos
Datos de Auditora Actualizados por la aplicacin
Mensajes Help Actualizados por la aplicacin
Mensajes de Error Actualizados por la aplicacin
Datos de Back-up, si el usuario lo requiere
Ficheros Internos Lgicos mantenidos por ms de una aplicacin
5.3.1.2. Ficheros Interfase Externos

Representan un grupo de datos relacionados lgicamente identificables por el usuario o informacin de
control utilizada por la aplicacin, pero mantenida por otra aplicacin.
Regla 1
Regla 2
Regla 3
Regla 4
Regla 5
El grupo de datos o informacin de control es un grupo e datos lgico

identificable por el usuario que cubre de manera completa requisitos especficos
de ste
El grupo de datos es referenciado y es externo a la aplicacin que est siendo
contada
El grupo de datos no es mantenido por la aplicacin que est siendo contada
El grupo de datos se ha contado como un ILF por, al menos, otra aplicacin
El grupo de datos identificado no ha sido contado como un ILF para la
aplicacin
5.3.2. Tipos de Funcin Transaccin

Comprende tres tipos de funcin:
Entradas externas (EI): mantiene datos almacenados internamente.

Salidas externas (EO): datos de salida de la aplicacin.
Pg. 38
Consultas externas (EQ): Combinacin de una entrada (pregunta) y de una salida (respuesta).
Vamos a comentar brevemente cada una de ellas.

5.3.2.1. Entradas Externas
Las Entradas Externas son datos o informacin de control que se introducen en la aplicacin desde fuera de
sus lmites.
Estos datos mantienen un Fichero Lgico Interno. La Informacin de Control est constituida por datos
utilizados por un proceso dentro de los lmites de la aplicacin para asegurar el cumplimiento de los
requisitos del negocio definidos por los usuarios.
Esta Informacin de Control puede mantener directamente un Fichero Lgico Interno. Una Entrada Externa
debera ser considerada nica si tiene un formato distinto de las dems o el diseo lgico requiere una lgica
de procesamiento distinta de otra Entrada Externa del mismo formato. En otras palabras, una Entrada
Externa se considera nica si los datos son mantenidos en un Fichero Lgico Interno (ILF) y el formato de
entrada es nico o la lgica del proceso es nica.
Para cada proceso identificado que actualiza un Fichero Lgico Interno:
Hay que considerar cada formato de entrada como un proceso distinto, si los datos utilizados por el
proceso pueden tener distintos formatos.
Hay que sumar una unidad a cada Entrada Externa por cada actividad de mantenimiento de datos
realizada (sumar, cambiar, borrar).
Regla 1
Regla 2
Regla 3
Regla 4
Regla 5
Los datos se reciben desde fuera de los lmites de la aplicacin

Los datos mantienen un ILF a travs de un proceso elemental de la aplicacin
El proceso es la unidad ms pequea de actividad que es significativa para el
negocio del usuario final
El proceso es autocontenido y deja a la aplicacin que est siendo contada en
un estado consistente
El proceso identificado debe verificar alguna de estas dos reglas :
- Su lgica de proceso es nica respecto otras entradas externas de la
aplicacin.
- Los elementos de datos identificados son distintos a los de las otras EIs de la
aplicacin.
Ejemplos de este tipo de funcin son:

Las transacciones: Datos introducidos para mantener Ficheros Lgicos Internos.
Las pantallas de entrada: Hay que aadir una unidad a Entradas Externas por cada funcin
que mantiene un Fichero Lgico Interno. Por ejemplo, si los datos introducidos en esa pantalla
Pg. 39
pueden aadir, cambiar y borrar informacin en un Fichero Lgico Interno, se contaran tres
Entradas Externas.
Las entradas por lotes: Por cada proceso nico que mantiene un Fichero Interno Lgico se
debe aadir una Entrada Externa por cada adicin, modificacin o borrado de datos.
Un fichero fsico de entrada, cuando se analiza lgicamente, corresponde a una Entrada Externa
o varias, dependiendo de los tipos de registros contenidos y del proceso requerido para su
tratamiento.
As mismo dos o ms ficheros fsicos de entrada pueden corresponder a una Entrada Externa si
el proceso lgico y el formato son idnticos para cada uno de los ficheros.
Las entradas externas duplicadas: Si distintos procesos de entrada solicitados expresamente
por el usuario duplican una Entrada Externa, son contados independientemente cada uno.
Un ejemplo puede ser un ingreso en una cuenta bancaria que se puede hacer por un Cajero
Automtico o a travs de una operacin normal, siendo el mismo tipo de entrada.
En cambio, no son Entradas Externas:
Los datos referenciados utilizados por la aplicacin pero no mantenidos como Ficheros
Lgicos Internos.
Las entrada de una Consulta
Los generadores de Informes
Las pantallas de Conexin que no mantengan un Fichero Lgico Interno.
5.3.2.2. Salidas Externas

Las Salidas Externas son datos o informacin de control que sale de los lmites de la aplicacin. Esta salida
debe ser considerada nica si tiene un formato nico o si el diseo lgico requiere un proceso lgico distinto
de otras salidas del mismo formato. Toda salida ha de requerir un proceso de clculo de la informacin que
se proporciona.
Las reglas para identificar este tipo de funciones son:
Pg. 40
El proceso enva datos o informacin de control

Los datos o informacin de control se envan a travs de un proceso elemental
de la aplicacin
El proceso es la unidad ms pequea de actividad que es significativa para el
negocio del usuario final
El proceso es autocontenido y deja a la aplicacin en un estado consistente
- Su lgica de proceso es nica respecto otras salidas externas de la aplicacin
- Los elementos de datos identificados son distintos a la los de otras EOs de la
aplicacin
Regla 1
Regla 2
Regla 3
Regla 4
Regla 5
Deben considerarse Salidas Externas:

La transferencia de datos a otras aplicaciones: Datos que residen en un Fichero Lgico
Interno que son formateados y procesados para ser utilizados por otra aplicacin.
Las salidas son identificadas basadas en los procesos requeridos para el tratamiento de los datos.
Un fichero fsico de salida, cuando se analiza lgicamente, puede corresponder a varias salidas.
De una manera similar, dos o ms ficheros fsicos de salida pueden corresponder a una Salida
Externa si el proceso lgico y los formatos son idnticos para cada uno de ellos.
Un mtodo para identificar mltiples Salidas Externas es ver cuntos tipos de registros distintos
hay en el fichero.
Los mensajes de error/configuracin: No se contaran si estn asociados a una Consulta o a

una Entrada.
Los grficos: Cada grfico distinto, solicitado por el usuario, debera ser contado como una
salida. As, si unos datos estadsticos se presentan en formato de tabla, diagrama de barras, y
tarta, se contarn como 3 salidas.
Los generadores de informes: Una salida desarrollada por el usuario con un generador de
informes debera ser contada como una salida para cada tipo de informe especificado.
Si el usuario solicita una facilidad de generacin de informes como parte de la aplicacin para
ser confeccionados por l mismo, la cuenta ser la siguiente:
Debera contarse una Entrada Externa por cada parmetro para la definicin de informes o
comando (ej. select, compare, sort merge, calculate, format, etc.) utilizado por el usuario
para controlar la generacin del informe.
Debera contarse una Salida por el informe total.
Debera contarse un Fichero Lgico si se crea un nuevo fichero y ste se salva.
No se deben contar como Salidas:
Pg. 41
Las ayudas
Las distintas formas de invocar la misma salida lgica
Los mensajes de error/confirmacin asociados con tipos de funcin distintos de Entradas
Externas
Por ejemplo, no se contabilizara como salida los mensajes de error/confirmacin asociados a
una Consulta Externa.
Los informes mltiples/valores nicos de datos: Informes idnticos con el mismo formato y la
misma lgica de proceso, pero que existen debido a distintos valores de datos, no se cuentan
como salidas distintas. Por ejemplo, dos informes idnticos en formato y construccin, el
primero de los cuales contiene nombres comenzando desde la A a la L y el segundo desde la M
a la Z se cuenta como una nica salida.
Los informes Ad Hoc: Cuando el usuario dirige y es responsable de la creacin mediante la
utilizacin de lenguajes como FOCUS o SQL de un nmero indefinido de informes, no se
cuentan como salidas.
5.3.2.3. Consultas Externas

Las consultas representan los requisitos de informacin a la aplicacin en una combinacin nica de
entrada/salida que se obtiene de una bsqueda de datos, no actualiza un Fichero Lgico Interno y no contiene
datos derivados. Una consulta se considera nica si tiene un formato distinto de otras consultas, ya sea en
entrada o salida, o si el diseo lgico requiere ediciones distintas a las de otras consultas.
Se entiende por datos derivados aqullos que requieren un proceso distinto a la bsqueda directa, edicin o
clasificacin de informacin de Ficheros Lgicos Internos o Ficheros Interfases Externos.
Las reglas para identificar este tipo de funcin son:
Regla 1
Regla 2
Regla 3
Regla 4
Regla 5
Regla 6
Regla 7
Regla 8
Una peticin entra dentro del lmite de la aplicacin

Un resultado sale del lmite de la aplicacin
Hay recuperacin de datos
Los datos recuperados no contiene datos derivados
la peticin de entrada y el resultado de salida juntos, hacen del proceso la unidad
de actividad ms pequea que es significativa para el negocio del usuario final
El proceso es autocontenido y deja a la aplicacin que est siendo contada en un
estado consistente
El proceso no actualiza ILFs
- La lgica de proceso sobre la entrada y la salida es nica respecto a otras EQs
de la aplicacin
- Los elementos de datos (DETs) que forman la entrada y la salida son distintos a
los de las otras EQs de la aplicacin
Ejemplos de Consultas son:

Pg. 42
La bsqueda inmediata de datos

Las consultas no explcitas: Las pantallas de modificacin/borrado que proporcionan
capacidad de bsqueda de datos antes de la funcionalidad de cambio/borrado se consideran
como consultas slo si la informacin que proporcionan se muestra al usuario.
Si la entrada y salida de la consulta son idnticas en las funciones de modificacin y borrado, se
contar una sola consulta.
Los mens con consultas implcitas: Las pantallas de men que proporcionan una seleccin de
pantallas y entradas para la bsqueda de datos para la pantalla llamada, se cuenta como una
Consulta.
Pantallas de conexin: Las pantallas de logon que proporcionaran seguridad se cuentan como
una consulta.
Las ayudas: Son una consulta donde la entrada y la salida (texto) son nicas. Un texto que
puede ser accedido o mostrado en pantalla mediante distintas peticiones o diferentes reas de
una aplicacin se cuenta como una consulta.
Se pueden distinguir dos categoras de Ayudas como son consultas tpicas:
a) Ayudas a plena pantalla: Es una facilidad que proporciona una salida a pantalla como
consecuencia de una llamada, tambin a travs de una pantalla. Se cuenta como una consulta de
baja complejidad por aplicacin, sin tener en cuenta el nmero de pantallas devueltas.
b) Ayudas por campos: Es una facilidad que se proporciona dependiendo de la posicin del
cursor o algn otro mtodo de identificacin, mostrndose documentacin especifica a dicho
campo. Se cuenta como una consulta de baja complejidad por aplicacin.
Las salidas duplicadas: Consultas iguales que producen una salida en diferentes soportes,
como consecuencia de especificaciones del usuario, se cuentan como consultas distintas.
Tutoriales: Los sistemas de software relativos a la formacin de usuarios deberan contarse
como un sistema distinto.
No se consideran como Consultas:
Los mensajes de Error/Confirmacin.
La utilizacin de distintos mtodos de llamada a la misma consulta.
Puede ocurrir que en una organizacin en particular surja una situacin que no est cubierta por las guas
existentes para contar Puntos de Funcin. Este mtodo refleja que sta es una tcnica en evolucin. En tales
casos el tcnico debe tomar la decisin de formular una regla, basada en su experiencia personal as como en
la de otros. Lo ms importante es documentar la regla y aplicarla consistentemente.
Pg. 43
5.4. Valoracin de la Complejidad

Para cada uno de los parmetros externos se ha de indicar su complejidad como Baja, Media o Alta. Para las
entradas, salidas y consultas, se puede evaluar su complejidad en funcin del nmero de campos que
contengan y del nmero de ficheros a los que hagan referencia. Para los ficheros, por el contrario, su
complejidad vendr dada en funcin del nmero de registros y de campos que tengan.
Valoracin de la complejidad de los tipos de funcin datos
A cada ILF y EIF identificado se le asigna una complejidad funcional que es funcin del nmero de
tipos de elementos datos (DETs) y el nmero de tipos de elementos registros (RETs) de los que estn
compuestos, y que vienen expresada mediante las tablas de contribucin y complejidad del apndice 2.
Reglas de identificacin de DETs para tipo de funcin datos
Un tipo de elemento dato es un campo nico y no recursivo sobre un tipo de funcin datos y que es
reconocible por el usuario. Normalmente se corresponden con los atributos de las entidades lgicas de
usuario. Para que un campo sea reconocido como DET de un tipo de funcin datos, debe verificar, al menos,
una de las siguientes reglas:
Regla 1
Regla 2
Regla 3
Contar cada campo nico y no recursivo sobre los ILFs o EIFs que sean
reconocibles por el usuario
Contar un DET por cada dato que exista sobre un ILF o un EIF porque el
usuario requiere mantener una relacin de stos con otro ILFF (claves ajenas)
Contar las siguientes tcnicas de implementacin fsica como un nico DET
para el grupo completo de campos :
3.1 campo que aparecen ms de una vez en un ILF o EIF debido a la tecnologa
o tcnicas de implementacin
3.2 campos repetitivos que tiene el mismo formato y que existen para permitir
mltiples ocurrencias del valor de un dato
Reglas de identificacin de RETs

Un tipo de elemento registro es un subgrupo de datos elementales reconocibles por el usuario dentro
de un tipo de funcin datos.
Los subgrupos son de dos tipos; opcionales y mandatorios. Los grupos opcionales son aquellos que
usuario tiene la opcin de incluir o no mediante un proceso elemental que aada o cree una instancia dentro
un tipo de funcin datos. Los grupos mandatorios son aquellos en los que el usuario debe incluir cuando se
crea o aade una instancia.
Para que un subgrupo de datos sea reconocido como RET debe verificar, alumnos, una de las
siguientes reglas:
Pg. 44
Contar un RET por cada subgrupo opcional o mandatorio de un tipo de funcin

datos
Si no hay subgrupos, contar el ILF o EIF como un nico RET
Regla 1
Regla 2
Una vez identificados el nmero de RET y DET se ha de acudir a la siguiente tabla para determinar la
complejidad del ILF o EIF.
DET
1 a 19
20 a 50
51 o ms
Baja
Baja
Media
Baja
Media
Alta
Media
Alta
Alta
RET
1
2a5
6 o ms
Valoracin de la complejidad de los tipos de funcin transaccin

Valoracin de la complejidad de las entradas externas
A cada EI identificada se le asigna una complejidad funcional que es funcin del nmero de tipos de
elementos datos (DETs) que procese el procedimiento elemental, y el nmero de tipos fichero referenciados
(FTRs) a los que acceda tal proceso. Viene expresada mediante las tablas de contribucin y complejidad del
apndice 2.
Reglas de identificacin de DETs para entradas externas
UN DET es un campo no recursivo y nico, reconocible por el usuario y mantenido sobre un ILF
durante el proceso de una El. Para que un campo sea reconocido como DET de un tipo de funcin
transaccin debe verificar, al menos, una de las siguientes reglas:
Regla 1
Regla 2
Regla 3
Contar un DET por cada campo no recursivo y nico, reconocible por el

usuario y mantenido sobre un ILF durante el proceso la El
Contar un DET por cada campo que no es introducido por el usuario, pero
que es mantenido sobre un ILF por medio de una El
Contar las siguientes tcnicas de implementacin fsica como un nico DET
para el grupo completo de campos :
3.1 Un campo lgico que es almacenado fsicamente en mltiples campos,
pero que es requerido por el usuario como una nica pieza de informacin
3.2 Campos que aparecen ms de una vez en un ILF debido a exigencias de
implementacin o tecnologa
3.3 Campos que indican un error ocurrido durante el proceso o
confirmaciones de que ste ha finalizado con xito. Todos los mensajes se
cuentan como un nico DET
3.4 Contar un nico DET para la capacidad de especificar una accin que
debe ser tomada para una El
Reglas de identificacin de FTRs para entradas externas
Pg. 45
Un tipo fichero referenciado es:

Un fichero lgico interno ledo o mantenido por un tipo funcin transaccin
Un fichero interfase externo ledo por un tipo funcin transaccin
Para que un conjunto de datos sea reconocido como FTR para entradas externas, debe verificar, al
menos, una de las siguientes reglas:
Reglas 1
Reglas 2
Reglas 3
Contar un FTR por cada ILF mantenido durante el proceso de una El

Contar un FTR por cada ILF o EIF ledo durante el proceso de una El
Contar un nico FTR por cada ILF que sea tanto mantenido como ledo sobre
un ILF durante el proceso de una El
Una vez identificados el nmero de FTR y DET se ha de acudir a la siguiente tabla para determinar la
complejidad de la EI
DET
1a4
5 a 15
16 o ms
Baja
Baja
Media
Baja
Media
Alta
Media
Alta
Alta
FTR
0a1
2
3 o ms
Valoracin de la complejidad de las salidas externas

A cada EO identificada, asignarle una complejidad funcional basada en el nmero de tipos fichero
referenciado (FTRs) por el proceso elemental de dicha EO y el nmero de tipos elemento de datos (DETs)
que la forman. Viene expresada mediante las tablas de contribucin y complejidad del apndice 2.
Reglas de identificacin de DETs para salidas externas
UN DET es un campo no recursivo y nico, reconocible por el usuario y que aparece durante el
proceso de una EO. Para que tal campo sea reconocido como DET debe verificar alguna de estas reglas:
Regla 1
Regla 2
Regla 3
Regla 4
Contar un DET por cada campo no recursivo y nico, reconocible por el usuario
y que aparece durante el proceso una la EO
No contar literales como DETs, como ttulos de informes, pantallas o paneles de
identificacin, cabeceras de columnas y ttulos de campos
No contar las variables de paginado ni las marcas generadas por el sistema
Contar las siguientes tcnicas de implementacin fsica como un nico DET para
el grupo completo de campos :
4.1 Un campo lgico que es almacenado fsicamente en mltiples campos, pero
que es requerido por el usuario como una nica pieza de informacin
4.2 Cada tipo de etiqueta y cada tipo de equivalente numrico en un grfico de
salida
4.3 Informacin de texto, que puede ser una nica palabra, una sentencia o una
frase
Reglas de identificacin de FTRs para salidas externas
Pg. 46
Un tipo fichero referenciado es un fichero que es ledo cuando se procesa la salida externa. Para que
un conjunto de datos sea reconocido como FTR para salidas externas, debe verificar la regla siguiente:
Contar un FTR por cada ILF o EIF ledo durante el proceso de una EO
Regla 1
DET
1a4
5 a 19
20 o ms
Baja
Baja
Media
Baja
Media
Alta
Media
Alta
Alta
FTR
0a1
2a3
4 o ms
Valoracin de la complejidad de las consultas externas

A cada EQ que ha sido identificada, asignarle una complejidad funcional basada en el nmero de
tipos fichero referenciados (FTRs) y de tipos elemento de datos (DETS) que intervienen en el proceso de la
componente de entrada y de la componente de salida respectivamente. Una vez calculada ambas
complejidades, escoger la ms alta entre la de la entrada y la de la salida, y traducirla a nmero de puntos de
funcin sin ajustar segn las tablas de contribucin y complejidad del apndice 2.
Reglas de identificacin de DETs para consultas externas
Un DET es un campo no recursivo y reconocible por el usuario que aparece en el proceso de una
EQ. Para que tal campo sea reconocido como DET de tal EQ, debe verificar alguna de estas reglas:
REGLAS DE IDENTIFICACIN PARA LA ENTRADA DE LA EQ
Regla 1
Regla 2
Regla 3
Contar un DET por cada campo no recursivo, reconocible por el usuario que
aparezca en la parte de entrada de una consulta
3.1 Campos que indican un error ocurrido durante el proceso del DET de
entrada, o confirmacin del que el proceso ha terminado de manera correcta.
Todos los mensajes se cuentan como un nico DET.
3.2 Campos que especifican que la EQ debe ser procesada
REGLAS DE IDENTIFICACIN PARA LA SALIDA DE LA EQ
Regla 1
Regla 2
Regla 3
Contar un DET por cada campo no recursivo y reconocible por el usuario que
aparezca en la parte de salida de una consulta
No contar como DETs literales como por ejemplo, ttulos de informes,
identificacin de pantallas o paneles, cabeceras de columnas, y ttulos de
campos.
No contar variables o marcas generadas por el sistema o marcas, como son los
nmeros de pgina, informacin de posicin, comandos de paginado o campos
Pg. 47
de fecha y hora
4.1 Un campo lgico que se almacena fsicamente en mltiples campos pero
que es requerido por el usuario como una unidad de informacin
4.2 Campos que aparecen ms de una vez en un ILF debido a exigencias de la
tecnologa o tcnicas de implementacin
Reglas de identificacin de FTRs para consultas externas
Regla 4
Un tipo fichero referenciado es un fichero que es ledo cuando se procesa la consulta externa. Para
que un conjunto de datos sea reconocido como FTR para consultas externas, debe verificar alguna de las
reglas siguientes:
Contar un FTR por cada ILF o EIF ledo durante el proceso de

la EQ
Contar un FTR por cada ILF o EIF ledo durante el proceso de
la EQ
Regla 1 (ENTRADA)
Reglas 2 (SALIDA)
Para la parte de entrada
DET
1a4
5 a 15
16 o ms
Baja
Baja
Media
Baja
Media
Alta
Media
Alta
Alta
1a4
5 a 19
20 o ms
Baja
Baja
Media
Baja
Media
Alta
Media
Alta
Alta
FTR
0a1
2
3 o ms
Para la parte de salida:
DET
FTR
0a1
2a3
4 o ms
Una vez definida la complejidad de cada parmetro se aplica el siguiente clculo:

Complejidad X
Peso
Total
Parmetro
Entrada
Alta
Baja
X
4
X
Alta
Media
X
X
7
5
=
=
Media
Salida
=
=
Pg. 48
Baja
Fichero Lgico
Interno
Alta
Media
Baja
X
X
X
15
10
7
=
=
=
Fichero Lgico
Externo
Alta
Media
Baja
X
X
X
10
7
5
=
=
=
Consultas
Alta
Media
Baja
X
X
X
6
4
3
=
=
=
La suma total da los Puntos de Funcin Sin Ajustar del Sistema.
5.5. Anlisis de las caractersticas generales del sistema

Una vez obtenidos el total de Puntos de Funcin sin ajustar, debe realizarse un ajuste del mismo en funcin
de las caractersticas generales del sistema.
Estas caractersticas son:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Comunicacin de datos.
Funciones distribuidas.
Rendimiento.
Configuraciones fuertemente utilizadas.
Frecuencia de transacciones.
Entrada on-line de datos.
Diseo para la eficiencia del usuario final.
Actualizacin on-line.
Procesos complejos.
Utilizacin en otros sistemas.
Facilidad de instalacin.
Facilidad de operacin.
Instalacin de Mltiples sitios.
Facilidad de cambio.
En funcin de estas catorce caractersticas se calcula el grado de influencia, del modo que se mostrar a
continuacin.
Una vez calculado el grado de influencia, TDI (del ingls Total Degree of Influence), de las caractersticas,
se puede llegar al valor del factor de ajuste mediante la frmula:
AF = (TDI x O.O1) + 0.65

Pg. 49
El valor final de Puntos de Funcin ajustados ser:
FPA = FP X AF
Existe un debate general sobre las caractersticas generales del sistema, ya que en gran parte su evaluacin
es subjetiva, y por otro lado su valor como multiplicador es muy bajo. Sin embargo, forma parte de la tcnica
y en el futuro se prev que sea uno de los aspectos ms importantes en la evolucin de la misma.
Vamos a estudiar la valoracin que hace de estas caractersticas el IFPUG. Cada una de ellas se evaluar de 0
a 5, segn las guas que se indican a continuacin, el TDI se obtendr como suma de los valores de cada una
de ellas.
5.5.1. Comunicacin de datos
Los datos e informacin de control utilizados en la aplicacin, se reciben o son enviados a travs de medios
de telecomunicacin.
Los terminales conectados localmente a la unidad de control, son considerados como medios de
comunicacin.
Los valores utilizados son los que se muestran en la Tabla 5.1:
0
1
2
3
4
5
La aplicacin es por lotes o utilizando un ordenador personal

La aplicacin es por lotes pero existe una entrada de datos o impresin remotas
La aplicacin es por lotes pero son remotas la entrada de datos o la impresin.
Entrada on-line de datos a un proceso por lotes o sistema de consultas.
Ms de un ordenador front-end, pero la aplicacin soporta un solo tipo de protocolo de
comunicaciones.
Ms de un ordenador front-end, pero la aplicacin soporta mas de un tipo de protocolo de
comunicaciones
Tabla 5.1. Comunicacin de Datos
5.5.2. Funciones distribuidas

Son caractersticas de la aplicacin que permiten la existencia de datos o procesos distribuidos dentro del
lmite de la aplicacin.
Los valores son los mostrados en la Tabla 5.2.
0
1
No existe este tipo de funciones en la aplicacin.

La aplicacin prepara datos para que el usuario final los procese en otro componente del
sistema. Por ejemplo, en una hoja electrnica en un ordenador personal.
Pg. 50
2
3
4
5
Los datos son preparados para ser transferidos. Se transfieren y procesan en otro componente
del sistema, pero no por el usuario final.
El proceso distribuido y la transferencia de datos son on-line y slo en una direccin.
El proceso distribuido y la transferencia de datos son on-line en ambas direcciones.
Los procesos se desarrollan dinmicamente en el componente ms apropiado del sistema.
Tabla 5.2. Funciones Distribuidas
5.5.3. Rendimiento
Los objetivos de rendimiento del sistema, definidos o aprobados por el usuario, tanto en tiempo de respuesta
como en volumen de datos a procesar, se vern influenciados por el diseo, desarrollo, instalacin y soporte
de la aplicacin. La Tabla 5.3. muestra la valoracin del rendimiento.
0
1
2
3
4
5
No existen requisitos especficos de rendimiento.

Rendimiento y requisitos de diseo han sido definidos y revisados pero no requieren ninguna
accin especial.
El tiempo de respuesta o la capacidad de proceso es crtico durante las horas punta. No se
requiere ningn diseo especial para la utilizacin de la Unidad Central de Proceso (UCP)
del ordenador. Los procesos demorados se ejecutan al siguiente da.
El tiempo de respuesta o la capacidad de proceso es crtico durante todas las horas de
operacin. No se requiere un diseo especial para la utilizacin de la UCP.
Los requisitos de rendimiento por parte de los usuarios son suficientemente estrictos como
para requerir un anlisis de rendimiento en la fase de diseo.
Adems, hay que utilizar herramientas para el anlisis de rendimiento durante el diseo,
desarrollo y/o fase de implantacin para verificar los requisitos de rendimiento.
Tabla 5.3. Rendimiento
5.5.4. Configuraciones fuertemente utilizadas

Es una caracterstica de la aplicacin que requiere consideraciones especiales de diseo debido a las
limitaciones de los equipos a utilizar.
Los valores se muestran en la Tabla 5.4.
0
1
2
3
4
5
No existen restricciones de ningn tipo.

Existen restricciones operativas, pero no requieren un esfuerzo especial para conseguirlas.
Existen algunas restricciones de seguridad o tiempo.
Existen requisitos especficos de procesador para algunas partes de la aplicacin.
Las restricciones definidas en el ordenador central o procesador dedicado obligan a
limitaciones en la aplicacin.
Adems de las caractersticas del punto 4, existen limitaciones en los componentes
distribuidos del sistema.
Tabla 5.4. Configuraciones fuertemente utilizadas
Pg. 51
5.5.5. Frecuencia de transacciones

La frecuencia de transacciones es alta e influye sobre el diseo, desarrollo, instalacin y soporte de la
aplicacin.
Los valores a asignar son los de la Tabla 5.5.
0
No existe una definicin del periodo punta de transacciones.
1
Se conoce el periodo punta (mensual, trimestral, estacional, anual).
2
Se conoce el periodo semanal.
3
Se conoce el periodo punta diario.
4
La frecuencia de transacciones definida por el usuario en los requisitos de la aplicacin o
acuerdos de nivel de servicio son suficientemente altos como para requerir anlisis de
rendimiento de tareas durante la fase de diseo.
5
La frecuencia de transacciones definida por el usuario en los requisitos de la aplicacin o
acuerdos de nivel de servicio son suficientemente altos como para requerir el uso de anlisis
de rendimiento de tareas y de herramientas de medida del rendimiento en el diseo,
desarrollo y/o fase de instalacin.
Tabla 5.5. Frecuencia de Transacciones
5.5.6. Entrada de datos on-line
Los valores son los de la Tabla 5.6.
0
1
2
3
4
5
Todas las transacciones se procesan por lotes.

1% al 7% de las transacciones son interactivas.
24% al 30% de las transacciones son interactivas
Ms del 30% de las transacciones son interactivas.
Tabla 5.6. Entradas on-line
5.5.7. Eficiencia del usuario final

Las funciones on-line proporcionadas ponen nfasis en un diseo que incremente la eficiencia del usuario
final. Estas funciones pueden ser:
Ayudas a la navegacin.
Mens
Ayudas/Documentacin on-line
Movimiento automtico del cursor.
Scrolling.
Impresin remota.
Teclas de funcin preasignadas.
Pg. 52
Emisin de trabajos por lotes a travs de transacciones on-line.

Seleccin mediante cursor de datos en pantalla.
Uso amplio de facilidades de vdeo.
Interfase de ratn.
Ventanas.
Racionalizacin del uso de pantallas para realizar una funcin de negocio.
Soporte de dos lenguas (Contar como 4 funciones).
Soporte multi-lengua (Contar como 6 funciones).
Los valores son los de la tabla 5.7.
0
1
2
3
4
Nada de lo anterior.
1-3 de las funciones anteriores.
4-5 de las funciones anteriores.
6 o ms, pero no existen requisitos del usuario respecto a la eficiencia.
6 o ms, pero estn definidos los requisitos de eficiencia del usuario que obligan a disear
tareas que tienen en cuenta factores humanos; por ejemplo, minimizar el nmero de tecleos,
uso de mascaras, etc.
6 o ms, y hay requisitos del usuario sobre eficiencia que obligan a utilizar herramientas
especiales y procesos para demostrar que los objetivos se han alcanzado.
Tabla 5.7. Eficiencia del usuario final.
5.5.8. Actualizacin on-line

La aplicacin proporciona actualizacin on-line de los Ficheros Lgicos Internos.
Los valores se muestran en la Tabla 5.8.
0
1
2
3
4
5
Ninguno.
Actualizacin on-line de 1 a 3 ficheros. El volumen de actualizacin es bajo y la
recuperacin fcil.
Actualizacin on-line de 4 ms ficheros. El volumen de actualizacin es bajo y la
recuperacin es baja.
Actualizacin importante de los Ficheros Lgicos Internos.
Adems de la proteccin contra la perdida de datos es esencial y ha sido especialmente
diseada y programada en el sistema.
Adems del punto 4, los altos volmenes de transacciones requieren que sea considerado el
coste de los procesos de recuperacin. Los procedimientos de recuperacin estn altamente
automatizados con intervencin mnima del operador.
Tabla 5.8. Actualizacin on-line
5.5.9. Procesos complejos
Pg. 53
Es una caracterstica de la aplicacin. Las categoras existentes son:

Controles especiales (procesos de auditora) y/o aplicaciones de seguridad.
Proceso lgico complejo.
Procesos matemticos complejos.
Excesivas excepciones de proceso dando lugar a transacciones incompletas que deben ser
procesadas de nuevo; por ejemplo, transacciones incompletas en cajeros automticos, falta de datos
obligatorios, etc.
Manejo de dispositivos complejos; por ejemplo, multi-media, independencia de dispositivos, etc.
0
1
2
3
4
5
Nada de lo anterior.
Uno de los anteriores.
Dos de los anteriores.
Tres de los anteriores.
Cuatro de los anteriores.
Todos los anteriores.
Tabla 5.9. Procesos Complejos
5.5.10. Reutilizacin
La aplicacin y el cdigo han sido diseados especficamente, desarrollados y soportados para ser utilizados
en otras aplicaciones.
Los valores aparecen en la Tabla 5.10.
0
1
2
3
4
5
No reusable.
Se utiliza cdigo reusable dentro de la aplicacin.
Menos del 10% de la aplicacin tiene en cuenta las necesidades de ms de un usuario.
El 10% ms de la aplicacin tiene en cuenta las necesidades de ms de un usuario.
La aplicacin fue empaquetada expresamente y/o documentada para ser fcilmente reusable.
La aplicacin es adaptada por el usuario a nivel de cdigo fuente.
La aplicacin fue empaquetada expresamente y/o documentada para ser fcilmente reusable.
La aplicacin es adaptada por el usuario por medio de parmetros de mantenimiento.
Tabla 5.10. Reutilizacin
5.5.11. Facilidad de instalacin

La facilidad de conversin e instalacin son caractersticas de la aplicacin. Durante la fase de pruebas del
sistema se proporcionarn y probarn un plan de conversin e instalacin as como herramientas para la
conversin.
Pg. 54
No se realizaron consideraciones ni se requirieron desarrollos especiales para la instalacin

por parte del usuario.
No se realizaron consideraciones especiales por el usuario pero se requirieron desarrollos

especiales instalacin.
Los requisitos de conversin e instalacin fueron definidos por el usuario y las guas para la
conversin e instalacin fueron desarrolladas y probadas. El impacto de la conversin en el
proyecto no se considera importante.
Los requisitos de conversin e instalacin fueron definidos por el usuario y las guas para la
conversin e instalacin fueron proporcionadas y probadas.
Adems del punto 2, se proporcionaran y probaran la conversin automtica y herramientas
para la instalacin.
Adems del punto 3, se proporcionaran y probaran la revisin automtica y las herramientas
para la instalacin.
3
4
5
Tabla 5.11. Facilidad de instalacin

5.5.12. Facilidad de operacin
La facilidad de operacin es una caracterstica de la aplicacin. Se proporcionarn y probarn durante la fase
de pruebas del sistema, un arranque eficaz, procedimientos de respaldo y recuperacin. La aplicacin
minimiza la necesidad de actividades manuales tales como montaje de cintas, manejo de papel o intervencin
manual durante la operacin del sistema. Los valores aparecen en la Tabla 5.12.
0
1-4
No se definieron por parte del usuario necesidades especiales de operacin o respaldo de

distintas de las normales.
Seleccionar, valorando como uno, cada una de las siguientes solicitudes realizadas a la
aplicacin:
Procesos eficaces de arranque, respaldo y recuperacin pero con
intervencin del operador. (Contar como 2)
La aplicacin minimiza la necesidad de montajes de cintas.
La aplicacin minimiza la necesidad de manejo de papel.
La aplicacin debe disearse sin intervencin de operadores; es decir el operador no debe
intervenir ms que para arrancar y parar la aplicacin. Uno de los elementos de la aplicacin
es la recuperacin automtica de errores.
Tabla 5.12. Facilidad de operacin
5.5.13. Instalacin en distintos lugares

La aplicacin se disear y desarrollar para ser instalada y mantenida en distintos lugares por distintas
organizaciones. Los valores los que se muestran en la Tabla 5.13.
0
No existen requisitos del usuario para considerar la necesidad de ms de un usuario lugar
Pg. 55
1
2
3
4
de instalacin.
Se necesita disear la aplicacin para ser utilizada en mltiples lugares pero funcionar bajo
entornos idnticos de hardware y software.
Se necesita disear la aplicacin para ser utilizada en mltiples lugares y funcionar bajo un
entorno de hardware y software similares.
Se necesita disear la aplicacin para ser utilizada en distintos lugares y funcionar bajo
entornos distintos de hardware y software.
Debern ser proporcionados y probados la documentacin y los planes de soporte de la
aplicacin para ser utilizados en distintos lugares, en el modo que se indic en los apartados
(1) y (2).
Debern ser proporcionados y probados la documentacin y los planes de soporte de la
aplicacin para ser utilizada en distintos lugares, en el modo que se indic en el apartado (3).
Tabla 5.13. Instalacin en distintos lugares
5.5.14. Facilidad de cambios

La aplicacin debe ser especficamente diseada, desarrollada y mantenida para facilitar el cambio.
Los siguientes son ejemplos de facilidades de cambios:
Capacidad para proporcionar flexibilidad en las consultas y obtencin de informes.
Los datos de la aplicacin relativos al negocio se mantienen en tablas por parte de los usuarios.
Los valores son:
0
No existe ninguna especificacin por parte de los usuarios en este sentido.
1-5 Se seleccionar alguna de estas opciones:
Facilidad para realizar consultas o informes simples tales como la utilizacin de operadores
lgicos AND/OR sobre un Fichero Lgico Interno (se contar como 1).
Facilidad para realizar consultas o informes de complejidad media tales como la utilizacin
de operadores lgicos AND/OR sobre mas de un Fichero Lgico Interno (se contara como 2).
Facilidad para realizar consultas/informes complejos. (Se contaran como 3).
Se mantendrn datos de control en tablas que sern mantenidas por los usuarios a travs de
procesos interactivos on-line, pero los cambios no sern efectivos hasta el siguiente da de
funcionamiento de la aplicacin. (Se contar como 1)
Igual que el caso anterior, pero los cambios sern efectivos inmediatamente (se contar
como 2).
Para usar eficientemente los Puntos de Funcin, se emplean unos ratios relativos a las siguientes mtricas:
Productividad; Indica el nmero de Puntos de Funcin que puede desarrollar una persona en un
mes.
Calidad; Indica el nmero de errores que supuestamente se cometern por Punto de Funcin.
Coste; Indica las pesetas que costar a la empresa el desarrollo de un Punto de Funcin.
Pg. 56
Documentacin; Indica el nmero de pginas de documentacin que se generar por Punto de

Funcin.
Lneas de Cdigo; Indica el nmero de lneas de un determinado lenguaje de Programacin, que se
escribirn por Punto de Funcin.
Estos ratios vendrn medidos en:
Productividad
Calidad
Coste
Documentacin
Lneas de Cdigo
= puntos funcin/persona-mes
= errores/punto funcin
= pesetas/punto funcin
= pginas/punto funcin
= lneas/punto funcin
La clave de la utilizacin de esta tcnica radica en la obtencin de estos ratios, que sern especficos de cada
organizacin, y que nos darn informacin sobre el tamao de la aplicacin. Estos ratios se obtendrn de
proyectos anteriores que se hayan desarrollado en la organizacin.
Pg. 57
TEMA 6:
COCOMO II
Pg. 58
7.1. Antecedentes de COCOMO II.

7.1.1. Qu es COCOMO II?
7.1.1.1. Introduccin.
El modelo original COCOMO se pblico por primera vez en 1981 por Barry Boehm y reflejaba las prcticas
en desarrollo de software de aquel momento. En la dcada y media siguiente las tcnicas de desarrollo
software cambiaron drsticamente. Estos cambios incluyen el gasto de tanto esfuerzo en disear y gestionar
el proceso de desarrollo software como en la creacin del producto software, un giro total desde los
mainframe que trabajan con procesos batch nocturnos hacia los sistemas en tiempo real y un nfasis creciente
en la reutilizacin de software ya existente y en la construccin de nuevos sistemas que utilizan componentes
software a medida.
Estos y otros cambios hicieron que la aplicacin del modelo COCOMO original empezara a resultar
problemtica. La solucin al problema era reinventar el modelo para aplicarlo a los 90. Despus de muchos
aos de esfuerzo combinado entre USC-CSE1, IRUS y UC Irvine22 y las Organizaciones Afiliadas al
Proyecto COCOMO II, el resultado es COCOMO II, un modelo de estimacin de coste que refleja los
cambios en la prctica de desarrollo de software profesional que ha surgido a partir de los aos 70. Este
nuevo y mejorado COCOMO resultar de gran ayuda para los estimadores profesionales de coste software.
Por tanto, COCOMO II es un modelo que permite estimar el coste, esfuerzo y tiempo cuando se planifica una
nueva actividad de desarrollo software. Est asociado a los ciclos de vida modernos. El modelo original
COCOMO ha tenido mucho xito pero no puede emplearse con las prcticas de desarrollo software ms
recientes tan bien como con las prcticas tradicionales. COCOMO II apunta hacia los proyectos software de
los 90 y de la primera dcada del 2000, y continuar evolucionando durante los prximos aos.
En resumen, los objetivos a la hora de la creacin del modelo COCOMO II fueron:
Desarrollar un modelo de estimacin de tiempo y de coste del software de acuerdo con los ciclos de vida
utilizados en los 90 y en la primera dcada del 2000.
Desarrollar bases de datos con costes de software y herramientas de soporte para la mejora continua del
modelo.
Proporcionar un marco analtico cuantitativo y un conjunto de herramientas y tcnicas para la evaluacin
de los efectos de la mejora tecnolgica del software en costes y tiempo del ciclo de vida software.
Estos objetivos apoyan las necesidades primarias expresadas por los usuarios de la estimacin de costes del
software. En orden de prioridades, estas necesidades eran: el apoyo de la planificacin de proyectos, la
previsin de personal del proyecto, la preparacin del proyecto, la replanificacin, el seguimiento del
Universidad del sur de California. Centro para la Ingeniera del Software

Unidad de investigacin de software Irvine. Universidad Irvine de California
Pg. 59
proyecto, la negociacin del contrato, la evaluacin de la propuesta, la nivelacin de recursos, exploracin de

conceptos, la evaluacin del diseo y decisiones referentes a la oferta/demanda. Para cada una de estas
necesidades COCOMO II proporcionar un apoyo ms moderno que sus predecesores, el COCOMO original
y Ada COCOMO.
Los cuatro elementos principales de la estrategia que ha seguido COCOMO II son:
Preservar la apertura del COCOMO original.

Desarrollar COCOMO II de forma que sea compatible con el futuro mercado del software
Ajustar las entradas y salidas de los submodelos de COCOMO II al nivel de informacin disponible.
Permitir que los submodelos de COCOMO II se ajusten a las estrategias de proceso particulares de cada
proyecto.
COCOMO II sigue los principios de apertura usados en el COCOMO original. De esta manera todos sus
algoritmos y relaciones estn disponibles pblicamente.
Tambin todos sus interfaces estn diseadas para ser pblicas, bien definidas y parametrizadas para que los
preprocesos complementarios (modelos de analoga basados en casos de otras medidas de estimacin), postprocesos (planificacin de proyectos y herramientas de control, modelos dinmicos de proyectos,
analizadores de riesgo) y paquetes de alto nivel (paquetes de gestin de proyectos, ayudas de negociacin de
producto) puedan combinarse estrechamente con COCOMO II.
Para apoyar a los distintos sectores del mercado software, COCOMO II proporciona una familia de modelos
de estimacin de coste software cada vez ms detallado y tiene en cuenta las necesidades de cada sector y el
tipo de informacin disponible para sostener la estimacin del coste software. Esta familia de modelos est
compuesta por tres submodelos cada uno de los cuales ofrece mayor fidelidad a medida que uno avanza en la
planificacin del proyecto y en el proceso de diseo. Estos tres submodelos se denominan:
El modelo de Composicin de Aplicaciones.

Indicado para proyectos construidos con herramientas modernas de construccin de interfaces grficos
para usuario.
El modelo de Diseo anticipado.
Este modelo puede utilizarse para obtener estimaciones aproximadas del coste de un proyecto antes de
que est determinada por completo su arquitectura. Utiliza un pequeo conjunto de drivers de coste
nuevo y nuevas ecuaciones de estimacin. Est basado en Punto de Funcin sin ajustar o KSLOC (Miles
de Lneas de Cdigo Fuente).
El modelo Post-Arquitectura.
Este es el modelo COCOMO II ms detallado. Se utiliza una vez que se ha desarrollado por completo la
arquitectura del proyecto. Tiene nuevos drivers de coste, nuevas reglas para el recuento de lneas y
nuevas ecuaciones.
La primera implementacin de COCOMO II se present al pblico general a mediados de 1997. USC

COCOMOII.1997 se calibr con 83 puntos de datos (proyectos de desarrollo software histricos), utilizando
un enfoque de media ponderada del 10% para combinar datos empricos con la opinin del experto y calibrar
Pg. 60
los parmetros del modelo. USC COCOMOII.1998.0 beta se cre en Octubre de 1998. Esta versin se
calibr con 161 puntos de datos y utilizando por primera vez un enfoque bayesiano para realizar la
calibracin del modelo. USC COCOMO II.1999.0 se ha publicado a mediados de 1999 y USC-COCOMO
II.2000.0 ser presentado en el ao 2000. Mientras cada versin nueva de la herramienta USC COCOMO II
fue mejorando en cuanto a amigabilidad con el usuario, las calibraciones del modelo de los aos 1998, 1999
y 2000 son la misma. Es decir, no se han aadido nuevos puntos de datos a la base de datos utilizada para
calibrar las versiones de la herramienta del ao 1999 y del ao 2000 aparte de aquellos que aparecieron en la
calibracin de la base de datos del ao 1998. En las tres implementaciones aparecen los mismos 161 puntos
de datos a los que hacamos referencia anteriormente Se prev que la versin USC-COCOMO II.2001.0 ya
incluir una nueva calibracin.
Por ltimo, la experiencia ha demostrado que si una organizacin calibra la constante multiplicativa en
COCOMO II para sus propios datos empricos, la precisin del modelo puede aumentar significativamente
por encima de los resultados de calibracin genricos obtenidos con las versiones mencionadas
anteriormente.
7.1.2. Predecesores de COCOMO II.
7.1.2.1. Evolucin de COCOMO 81 a COCOMO II y comparativa con sus predecesores.
Es importante recalcar los cambios experimentados por COCOMO II con respecto a COCOMO 81 ya que
reflejan cmo ha madurado la tecnologa de la Ingeniera del software durante las dos dcadas pasadas. Por
ejemplo, cuando se public el primer modelo COCOMO 81 los programadores estaban sometidos a tareas
batch. El giro total que se experiment afect a su productividad. Por lo tanto un parmetro como TURN que
reflejaba la espera media de un programador para recibir de vuelta su trabajo ahora no tiene sentido porque la
mayora de los programadores tienen acceso instantneo a los recursos computacionales a travs de su
estacin de trabajo. Este parmetro ha desaparecido en el nuevo modelo.
Las tablas 7.1 y 7.2 recalcan los principales cambios hechos a la versin original COCOMO 81 cuando se
desarroll COCOMO II y un resumen de las principales diferencias entre ambos. La tabla 7.2 presenta una
comparativa por modelos ms detallada de COCOMO II y adems incluye el modelo AdaCOCOMO. De
ambas tablas podemos deducir:
COCOMO II se dirige a las siguientes tres fases del ciclo de vida en espiral: desarrollo de
aplicaciones, diseo anticipado y Post-Arquitectura.
Los tres modos del exponente se han reemplazado por cinco factores de escala.
Se han aadido los siguientes drivers de coste a COCOMO II: DOCU, RUSE, PVOL, PEXP, LTEX,
PCON y SITE.
Se han eliminado los siguientes drivers de coste del modelo original: VIRT, TURN, VEXP, LEXP,
Y MODP.
Los valores de aquellos drivers de coste que se han conservado del modelo original fueron
modificados considerablemente para reflejar las calibraciones actualizadas.
Pg. 61
Las otras diferencias principales se refieren a efectos relacionados con el tamao, que incluyen reutilizacin,
reingeniera y cambios en efectos de escala.
Pg. 62
COCOMO 81
ESTRUCTURA DEL MODELO

FORMA MATEMTICA DE LA
ECUACIN DEL ESFUERZO
EXPONENTE
MEDIDA
DRIVERS DE COSTE (ci)
OTRAS DIFERENCIAS DEL MODELO
COCOMO II
Tres modelos que asumen que se progresa
Un modelo nico que asume que se ha a lo largo de un desarrollo de tipo espiral
comenzado con unos requisitos asignados para consolidar los requisitos y la
para el software
arquitectura, y reducir el riesgo.
Esfuerzo = A (cI) (SIZE)Exponenente
Esfuerzo = A (cI) (SIZE)Exponenente
Constante fija seleccionada como una Variable establecida en funcin de una
funcin de modo:
medida de cinco factores de escala:
Orgnico = 1.05
PREC Precedencia
Semi-libre = 1.12
FLEX Flexibilidad de desarrollo
Rgido = 1.20
RESL Resolucin de Arquitectura /

Riesgos
TEAM Cohesin del equipo
PMAT Madurez del proceso

Lneas de cdigo fuente (con extensiones Puntos objeto, Puntos de funcin lneas
para puntos de funcin)
de cdigo fuente.
15 drivers, cada uno de los cuales debe ser 17 drivers, cada uno de los cuales debe ser
estimado:
estimado:
RELY Fiabilidad
RELY Fiabilidad
DATA Tamao Base de datos
DATA Tamao Base de datos
CPLX Complejidad
CPLX Complejidad
RUSE Reutilizacin requerida
TIME Restriccin tiempo de

ejecucin
DOCU Documentacin
STOR
Restriccin
de
TIME Restriccin tiempo de
almacenamiento principal
ejecucin
VIRT Volatilidad mquina virtual
STOR
Restriccin
de
almacenamiento principal
TURN Tiempo de respuesta
PVOL Volatilidad plataforma
ACAP Capacidad del analista
PCAP Capacidad programador
ACAP Capacidad del analista
AEXP Experiencia aplicaciones
PCAP Capacidad programador
VEXP Experiencia mquina virtual
AEXP Experiencia aplicaciones
LEXP Experiencia lenguaje
PEXP Experiencia plataforma
TOOL Uso de herramientas

LTEX Experiencia lenguaje y
software
herramienta
MODP Uso de Tcnicas modernas

PCON Continuidad del personal
de programacin
TOOL Uso de herramientas
SCED Planificacin requerida

software
SITE Desarrollo Multi-lugar
SCED Planificacin requerida

Modelo basado en:
Tiene muchas otras mejoras que incluyen:
Frmula de reutilizacin lineal
Frmula de reutilizacin No-lineal
Asuncin
de
requisitos
Modelo de reutilizacin que
razonablemente estables
considera esfuerzo necesario para
entender y asimilar
Medidas de rotura que se usan para

abordar la volatilidad de requisitos
Caractersticas de autocalibracin
Tabla 7.1. Comparativa entre COCOMO 81 Y COCOMO II
Pg. 63
7.1.2.2. COMPARATIVA CON SUS PREDECESORES
COCOMO 81
MEDIDA
AdaCOCOMO
Instrucciones fuente entregadas (DSI)
DSI SLOC
COCOMO II
COCOMO II
COCOMO II
Modelo Composicin de aplicaciones
Modelo Diseo Anticipado
Modelo Post-Arquitectura
Puntos de funcin (FP) y lenguaje
Puntos de funcin (FP) y lenguaje
SLOC
SLOC
Puntos Objeto
Lneas de Cdigo fuente (SLOC)

REUTILIZACIN
SLOC Equivalente= lineal f(DM,CM,IM)
SLOC Equivalente= lineal f(DM,CM,IM)
Implcito en el modelo
%reutilizacin
%reutilizacin
sin
modificar:
modificada:
no
SR
lineal
SLOC
equivalente=
no
lineal
f(AA,SU,DM,CM,IM)
f(AA,SU,DM,CM,IM)
ROTURA
Medida de Volatilidad de los requisitos
Medida RVOL
Implcito en el modelo
Rotura % (BRAK)
Rotura % (BRAK)
ACT
Modelo de reutilizacin de Puntos Objeto
Modelo de reutilizacin
Modelo de reutilizacin
1.0
1.01-1.21 dependiendo del grado de:
1.01-1.21 dependiendo del grado de:
(RVOL)
MANTENIMIENTO
Trfico
anual
de
cambio
(ACT)
=%aadido + %modificado
Factor B en
Orgnico = 1.05
Rgido: 1.04-1.24 dependiendo del grado
MNnom== A (Size)B
Semi-libre = 1.12
de :
Rgido = 1.20
DRIVERS DE COSTE DE PRODUCTO
Precedencia
Precedencia
Eliminacin anticipada del riesgo
Conformidad
Conformidad
Arquitectura slida
Arquitectura
Arquitectura
Requisitos estables
Madurez del proceso Ada
RELY, DATA, CPLX
RELY*, DATA*, CPLX*
TIME, STOR, VIRT, TURN
TIME, STOR, VMVH, VMVT, TURN
anticipada,
resolucin de riesgos.
anticipada,
resolucin de riesgos.
Cohesin del equipo
Cohesin del equipo
Madurez del proceso
Madurez del proceso
Ninguno
RCPX*T, RUSE*T
RELY, DATA, DOCU*T,, CPLX*T, RUSE*T
Ninguno
Dificultad de la plataforma:
TIME, STOR, PVOL(=VIRT)
RUSE
DRIVERS
DE
COSTE
DE
LA
PLATAFORMA
DRIVERS DE COSTE DEL PERSONAL
DRIVERS DE COSTE DEL PROYECTO
PDIF*T
ACAP, AEXP, PCAP, VEXP, LEXP
MODP, TOOL, SCED
ACAP*, AEXP, PCAP*, VEXP, LEXP*
MODP*, TOOL*, SCED, SECU
Ninguno
Ninguno
Capacidad y experiencia del personal:
ACAP*, AEXPT, PCAP*, PEXP*T, LTEX*T,
PERS*T, PREX*T
PCON*T
SCED*T, FCIL*T
TOOL*T, SCED, SITE*T
Tabla 7.2. Comparativa entre COCOMO II y sus predecesores.

* Multiplicadores diferentes
T
Medida de escala diferente
Pag. 64
7.2. CONTEXTO DE UTILIZACIN DE LOS MODELOS DE COSTE DE COCOMO II.

7.2.1. SITUACIN DEL SW EN EL MERCADO FUTURO
Nos estamos convirtiendo en una compaa de software, es una frase cada vez ms repetida en
organizaciones tan diversas como las finanzas, transporte, aeroespacial, electrnica y las empresas
industriales. La ventaja competitiva depende cada vez ms del desarrollo de productos inteligentes y a
medida, y de la habilidad de desarrollar y adaptar ms rpidamente que los competidores estos productos y
servicios.
La notable reduccin de los costes del hardware y la comodidad de las soluciones software han influido
indirectamente en los costes del desarrollo de sistemas. Esta situacin hace que sean an ms importantes los
clculos coste-beneficio, la seleccin de los componentes adecuados para la construccin y evolucin del
ciclo de vida de un sistema y el convencimiento de la escptica direccin financiera de la ventaja comercial
de las inversiones en software. Tambin resalta la necesidad de productos coexistentes, la determinacin del
proceso y la habilidad de dirigir anlisis trazados entre el software y los costes del ciclo de vida del sistema,
tiempos de ciclo, funciones y calidades.
Al mismo tiempo, una nueva generacin de procesos software y productos estn cambiando la manera en que
las organizaciones desarrollan software: Enfoque evolutivo, riesgo controlado, procesos software
colaborativos, enfoque de desarrollo software de trayectoria rpida, lenguajes de 4 generacin, enfoque
dirigido a la reutilizacin software. Todas estas prcticas mejoran la calidad del software y reducen el riesgo,
el coste y el tiempo de ciclo.
Sin embargo, aunque alguno de los ya existentes modelos de coste tiene iniciativas que se dirigen a aspectos
de estos problemas, estos nuevos acercamientos no se han emparejado lo suficiente a los nuevos modelos
complementarios para estimacin de software y planificacin. Esto dificulta a las organizaciones la
realizacin de planes efectivos, anlisis y control de proyectos usando los nuevos enfoques.
Estas preocupaciones han llevado a la formulacin de una nueva versin del modelo de coste constructivo
COCOMO para la estimacin del esfuerzo, del tiempo y del coste software. El COCOMO original y su
especializado sucesor Ada COCOMO fueron razonablemente bien equiparados con los tipos de proyectos
software que ellos modelizaban: Gran extensin de clientes, software construido para la especificacin.
Aunque Ada COCOMO aadi la capacidad de estimar costes y tiempos para el desarrollo incremental de
software, COCOMO encontr una creciente dificultad para estimar los costes de software comercial, de
software orientado a objetos, de software desarrollado mediante modelos en espiral modelos de desarrollo
evolutivo, de software desarrollado en gran parte mediante utilidades de composicin de aplicaciones
comerciales a medida.
La figura 7.1 resume el modelo de mercado de las futuras prcticas de software que usamos para guiar el
desarrollo de COCOMO II. Incluye en la plataforma superior un sector dedicado a la programacin para
usuarios finales a la que pertenecern alrededor de 55 millones de personas en Estados Unidos cerca del ao
2005. A un nivel ms bajo, un sector de infraestructura, al que pertenecern aproximadamente 0.75 millones
Pg. 65 .
de personas y 3 sectores intermedios que incluyen el desarrollo de generadores de aplicaciones y ayudas para
la composicin (0.6 millones), desarrollo de sistemas mediante la composicin de aplicaciones (0.7 millones)
y sistemas de integracin a gran escala y/o sistemas de software embebidos (0.7 millones).
Programacin de usuario final
(55,000,000)
Generador de Aplicaciones y Ayudas

a la Composicin
Composicin de Aplicacin
Integracin de Sistema
(700,000)
(700,000)
(600,000)
Infraestructura
(750,000)
Figura 7.1. Modelo de mercado de futuras prcticas de software.
La programacin para usuarios finales estar dirigida por la creciente capacidad de la computadora de leer y
escribir y por la presin competitiva para la creacin de soluciones de proceso de informacin rpidas,
flexibles y manejables por el usuario. Estas tendencias empujarn al mercado del software a tener usuarios
que desarrollen ellos mismos la mayora de aplicaciones que procesan informacin mediante generadores de
aplicaciones.
Algunos ejemplos de generadores de aplicaciones son las hojas de clculo, los sistemas de querys extendidas
y los sistemas de inventarios de planificacin especializados. Ellos facilitarn el que los usuarios sean
capaces de determinar la aplicacin que procese la informacin que ellos deseen mediante la opcin de
dominios familiares reglas simples. Cada empresa de las compaas Fortune100 para pequeos negocios y
el departamento de defensa de Estados Unidos estarn involucrados en este sector.
Los productos tpicos del sector de la infraestructura estarn en las reas de Sistemas Operativos, Sistemas
gestores de bases de datos, Sistemas de gestin de interfaz con el usuario y Sistemas de redes. Cada vez ms,
el sector de la infraestructura se dirigir hacia soluciones middleware para problemas genricos tales como
el proceso distribuido y el proceso transaccional. Empresas representativas del sector de la infraestructura
son Microsoft, NeXT, Oracle, SyBase, Novell y los principales vendedores de computadoras.
En contraste con los programadores para usuarios finales que suelen conocer bien el dominio de sus
aplicaciones y relativamente poca informtica, los desarrolladores de infraestructura saben mucho de
informtica y relativamente poco de aplicaciones. La lnea de sus productos tendr muchos componentes
reutilizables pero el avance de la tecnologa (nuevos procesadores, memoria, comunicaciones, displays y
tecnologa multimedia) les exigir que construyan muchos componentes y utilidades desde el principio.
Pg. 66 .
Las personas que pertenecen a los tres sectores intermedios de la figura 5.2, necesitarn conocer una buena
parte de informtica y de software especializado para infraestructura, y tambin uno ms dominios de
aplicacin. Esto supondr un gran reto.
El sector de los Generadores de Aplicaciones crear numerosos paquetes de utilidades para la programacin
de usuarios. Firmas tpicas que operan en este sector son Microsoft, Lotus, Novell, Borland y vendedores de
sistemas para la ingeniera, la manufacturacin y la planificacin asistida por ordenador. Su lnea de
productos tendr muchos componentes reutilizables, pero requerir en gran parte el desarrollo de utilidades a
partir de cero. El sector de la Composicin de aplicaciones trata con aplicaciones demasiado diversificadas
como para ser utilizadas en soluciones empaquetadas, pero que son lo suficientemente sencillas como para
ser rpidamente compuestas a partir de componentes interoperables. Componentes tpicos sern
Desarrolladores de interfaces grficos para usuarios, Bases de datos Gestores de objetos, middleware para
procesos distribuidos procesos transaccionales, manejadores hipermedia, Buscadores de datos sencillos y
Componentes de dominio especfico tales como paquetes de procesos de control mdico, financiero
industriales.
La mayora de las grandes empresas tendrn grupos para la creacin de aplicaciones como estas pero muchas
de las empresas especializadas en software se comprometern a proporcionar aplicaciones compuestas.
Dichas empresas van desde las grandes y verstiles como Andersen Consulting y EDP hasta pequeas
empresas especializadas en reas tales como el soporte a la decisin proceso transaccional, en dominios
de aplicaciones tales como las finanzas la manufacturacin.
El sector de la Integracin de sistemas trata con sistemas a gran escala, altamente embebidos sistemas sin
precedentes. Parte de estos sistemas pueden desarrollarse utilizando utilidades de composicin de
aplicaciones, pero su demanda requiere una significativa cantidad de sistemas de ingeniera up-front y de
desarrollo tradicional de software. Las empresas aeroespaciales trabajan dentro de este sector, as como
empresas de integracin de sistemas especializados tales como EDS y Andersen Consulting, importantes
empresas en desarrollo de productos software-intensivos y servicios, empresas de telecomunicaciones,
automocin, finanzas y productos electrnicos, y empresas que desarrollan sistemas de informacin
corporativa a gran escala sistemas de soporte a la fabricacin.
7.2.2. COCOMO II. MODELOS PARA LOS SECTORES DEL MERCADO DEL SW.
Pg. 67 .

Generador de
Composicin de
Aplicaciones y
Aplicacin
Ayudas a la
Integracin de
Sistema
Composicin
Infraestructura
Figura 7.2. Modelo de mercado de futuras prcticas de software
El sector de la programacin de usuarios finales de la figura 7.2 no necesita un modelo COCOMO II. El
desarrollo de sus aplicaciones lleva de das a horas, as pues, una estimacin simple basada en actividad, ser
suficiente.
Generador de
Composicin de
Aplicaciones y
Aplicacin
Ayudas a la
Integracin de
Sistema
Composicin
Infraestructura
Figura 7.3.
Modelo de mercado de futuras prcticas de software
El modelo COCOMO II para el sector de la composicin de aplicaciones (figura 7.3) est basado en Puntos
Objeto. Los Puntos Objeto son un conjunto de pantallas, informes y mdulos de lenguajes de 3 generacin
desarrollados en la aplicacin, cada uno ponderado mediante un factor de complejidad de tres niveles
(simple, medio y complejo). Esto se corresponde con el nivel de informacin que normalmente se conoce de
un producto de Composicin de aplicaciones durante sus fases de planificacin y el nivel correspondiente de
exactitud que se necesita para estimar el coste software (dichas aplicaciones se desarrollan usualmente por un
equipo pequeo en semanas meses).
Pg. 68 .

Generador de
Composicin de
Aplicaciones y
Aplicacin
Ayudas a la
Integracin de
Sistema
Composicin
Infraestructura
Figura 7.4.
Modelo de mercado de futuras prcticas de software
La capacidad de COCOMO II para la estimacin del desarrollo de un Generador de Aplicacin, Integracin

de un Sistema Infraestructura (figura 7.4) est basada en una mezcla hecha a medida del modelo de
Composicin de Aplicaciones (para tiempos de prototipados tempranos anticipados) y dos modelos de
estimacin cada vez ms detallados para porciones del ciclo de vida, Diseo Anticipado y Post-Arquitectura.
Con respecto a la estrategia de proceso, los proyectos de Generador de Aplicaciones, Integracin de Software
e Infraestructura involucrarn a una mezcla de los tres principales Modelos de proceso. Los drivers
apropiados dependern de los drivers del mercado del proyecto y del grado de conocimiento del producto.
La razn para proporcionar esta mezcla hecha a medida se basa en tres premisas fundamentales:
1. A diferencia de la situacin del COCOMO inicial a finales de los 70, en los que haba un nico y
preferido modelo de ciclo software, los proyectos de software actuales y futuros ajustan sus procesos
a los particulares drivers de proceso. Estos drivers de proceso incluyen COTS disponibilidad de
software reutilizable, grados de composicin de arquitecturas y requisitos, ventana de mercado, y
fiabilidad necesaria.
2. La granularidad que usa el modelo de estimacin de coste software debe ser consistente con la
informacin disponible para dar soporte a la estimacin del coste software. En las primeras fases de
un proyecto software se conoce muy poco del tamao del producto que se desarrolla, la naturaleza de
la plataforma designada, la naturaleza del personal involucrado en el proyecto los datos concretos
del proceso que se utilizar.
3. Dada la situacin de las premisas 1 y 2, COCOMO II permite que los proyectos proporcionen
informacin sobre los drivers de coste, de grano grueso en las primeras etapas del proyecto y
progresivamente informacin de grano fino en las etapas posteriores. As pues COCOMO II no
produce valores de puntos de coste y esfuerzo software, sino un rango de valores asociado al grado
de definicin de las entradas estimadas.
Pg. 69 .
7.2.3. CUNDO UTILIZAR CADA MODELO DE COSTE COCOMO II?
7.2.3.1. UTILIZACIN DEL MODELO DE COMPOSICIN DE APLICACIONES
Las primeras fases o ciclos en espiral utilizados en proyectos software de Generador de Aplicaciones,
Integracin de Sistema e Infraestructura implicarn generalmente prototipado y utilizarn las utilidades del
Mdulo de Composicin de Aplicaciones. El Modulo de Composicin de Aplicaciones COCOMO II,
soporta estas fases y cualquier otra actividad de prototipado que se realice ms adelante en el ciclo de vida.
Este modelo se dirige a aplicaciones que estn demasiado diversificadas para crearse rpidamente en una
herramienta de dominio especfico, (como una hoja de clculo) y que todava no se conocen suficientemente
como para ser compuestas a partir de componentes interoperables. Ejemplos de estos sistemas basados en
componentes son los creadores de interfaces grficas para usuario, bases de datos gestores de objetos,
middleware para proceso distribuido transaccional, manejadores hipermedia, buscadores de datos pequeos
y componentes de dominio especfico tales como paquetes de control de procesos financieros, mdicos
industriales.
Dado que el Modelo de Composicin de Aplicaciones incluye esfuerzos de prototipado para resolver asuntos
potenciales de alto riesgo tales como interfaces de usuario, interaccin software/sistema, ejecucin grado
de madurez tecnolgica, los costes de este tipo de esfuerzo se estiman mejor mediante dicho modelo.
7.2.3.2. UTILIZACIN DEL MODELO DE DISEO ANTICIPADO
Hemos visto que las primeras fases o ciclos en espiral utilizados en proyectos software de Generador de
Aplicaciones, Integracin de Sistema e Infraestructura se ajustaban mejor al modelo de Composicin de
Aplicaciones.
Las siguientes fases ciclos espirales normalmente incluirn la exploracin de arquitecturas alternativas
estratgicas de desarrollo incremental. Para sostener estas actividades COCOMO II proporciona un modelo
de estimacin anticipado: el Modelo de Diseo Anticipado. El nivel de detalle de este modelo puede ser
consistente con el nivel general de informacin disponible y con el nivel general de aproximacin de la
estimacin requerida en esta etapa.
El Diseo Anticipado incluye la exploracin de arquitecturas de software/sistema alternativas y conceptos de
operacin. En esta fase no se sabe lo suficiente como para dar soporte a la estimacin de grano fino.
La correspondiente capacidad de COCOMO II incluye el uso de Puntos de Funcin y un conjunto de siete
drivers de coste de grano grueso (por ejemplo, dos drivers de coste para capacidad del personal y experiencia
del personal en lugar de los seis drivers de coste del Modelo Post-Arquitectura que cubren varios aspectos de
capacidad del personal, continuidad y experiencia).
El modelo de Diseo Anticipado usa Puntos de Funcin No Ajustados como mtrica de medida. Este modelo
se utiliza en las primeras etapas de un proyecto software, cuando se conoce muy poco sobre el tamao del
Pg. 70 .
producto que se va a desarrollar, la naturaleza de la plataforma objetivo, la naturaleza del personal

involucrado en el proyecto especificaciones detalladas del proceso que se va a usar. Este modelo puede
aplicarse a cada uno de los sectores de desarrollo de Generador de Aplicaciones, Integracin de sistemas
Infraestructura. (ver apartado 5.2.1, Situacin del software en el mercado futuro).
7.2.3.3. UTILIZACIN DEL MODELO POST-ARQUITECTURA
Hemos visto que las primeras fases o ciclos en espiral usados en proyectos software de Generador de
Aplicaciones, Integracin de Sistema e Infraestructura se ajustaban mejor al modelo de Composicin de
Aplicaciones y que las siguientes fases ciclos espirales normalmente sern sostenidas por el modelo de
Diseo Anticipado. Una vez que el proyecto est listo para desarrollar y sostener un sistema especializado,
debe haber una arquitectura de ciclo de vida que proporcione informacin ms precisa de los drivers de coste
de entradas y permita clculos de coste ms exactos. Para apoyar esta etapa COCOMO II proporciona el
Modelo Post-Arquitectura.
El Modelo Post-Arquitectura incluye el actual desarrollo y mantenimiento de un producto software. Esta fase
avanza rentablemente si se desarrolla una arquitectura de ciclo de vida software vlida con respecto a la
misin del sistema, al concepto de operacin y al riesgo, y establecido como marca de trabajo del producto.
El modelo correspondiente de COCOMO II tiene aproximadamente la misma granularidad que los anteriores
modelos COCOMO y AdaCOCOMO. Utiliza instrucciones fuente y/ Puntos de Funcin para medir, con
modificadores para reutilizacin y objetos software; un conjunto de 17 drivers de coste multiplicativos; y un
conjunto de 5 factores que determinan el exponente de escala del proyecto. Estos factores sustituyen los
modos de desarrollo (Orgnico, Semilibre y Rgido) del modelo original COCOMO y refina los 4 factores de
exponente-escala en Ada COCOMO.
7.3. MODELO DE COSTE DE COMPOSICIN DE APLICACIONES

7.3.1. INTRODUCCIN A LOS PUNTOS OBJETO
Los Puntos Objeto son el recuento de pantallas, informes y mdulos de lenguajes de 3 generacin
desarrollados en la aplicacin, cada uno ponderado mediante un factor de complejidad de tres niveles
(simple, medio y complejo).
La estimacin de Puntos Objeto es un enfoque relativamente nuevo de medida del software, pero encaja bien
en las prcticas del sector de la Composicin de Aplicaciones. Tambin encaja muy bien en los esfuerzos de
prototipado asociados, basados en el uso de herramientas ICASE que proporcionan constructores de
interfaces grficos de usuario, herramientas de desarrollo software; y en general, infraestructura que puede
componerse y componentes de aplicacin. En estas reas se ha comparado bien con la estimacin de Puntos
de Funcin en un conjunto de aplicaciones no triviales (pero todava limitadas).
Pg. 71 .
Uno de los estudios comparativos entre la estimacin de Puntos de Funcin y Puntos Objeto analiz una
muestra de 19 proyectos software sobre inversin bancaria de una misma organizacin, desarrollado
utilizando las utilidades de Composicin de Aplicaciones ICASE y con un rango de esfuerzo de 4.7 a 71.9
MM (Meses-Persona). El estudio descubri que el enfoque de Puntos Objeto justific un 73% de la varianza
(R2) en meses-persona ajustados por la reutilizacin, comparada con el 76% para los Puntos de Funcin.
Un experimento posterior diseado estadsticamente incluy cuatro gestores de proyecto experimentados
utilizando Puntos de Funcin y Puntos Objeto para estimar el esfuerzo requerido en dos proyectos completos
(3.5 y 6 Meses-persona actuales), basado en las descripciones del proyecto disponibles al principio para
dichos proyectos. El experimento descubri que los Puntos de Funcin y los Puntos Objeto dan resultados
comparablemente precisos (un poco ms precisos con Puntos Objeto pero estadsticamente insignificantes).
Desde el punto de vista de la utilizacin, el tiempo medio para producir un valor de Punto Objeto era de
alrededor del 47% del correspondiente tiempo medio para producir un valor de Puntos de Funcin. Tambin
los gestores consideraron el mtodo de Puntos Objeto ms fcil de usar (ambos resultados fueron
estadsticamente significantes).
De esta manera aunque estos resultados no estn todava extendidos, su ajuste al desarrollo software de
Composicin de Aplicaciones parece justificar la seleccin de Puntos Objeto como el punto de partida para
el modelo de estimacin de Composicin de Aplicaciones.
7.3.2. PROCEDIMIENTO DE OBTENCIN DE PUNTOS OBJETO
La definicin de los trminos utilizados en los Puntos de Objetos es la siguiente:

NOP: Nuevos Puntos Objeto. (Cantidad de Puntos Objeto ajustados por
la reutilizacin).
Srvr:
Nmero
de
tablas
de
datos
del
servidor
(mainframe
equivalente) usadas junto con la pantalla o el informe.

Clnt: Nmero de tablas de datos del cliente (estacin de trabajo
personal) usadas junto con la pantalla o el informe.
%reuse:
Porcentaje
de
reutilizados a partir de
pantallas,
informes
mdulos
3GL
aplicaciones anteriores prorrateadas por
grado de reutilizacin.
Los ratios de productividad se basan en los datos del proyecto del ao 1 y ao 2. En el ao 1 la herramienta
CASE estaba construyndose y los desarrolladores no la conocan. La productividad media de NOP/Mespersona en los 12 proyectos del ao 1 se asocia con los niveles bajos de desarrollador y madurez y capacidad
ICASE. En los siete proyectos del ao 2, ambos, herramientas CASE y capacidades de los desarrolladores se
consideran ms maduras. La productividad media era 25 NOP/Meses-persona, que se corresponde con los
niveles altos de madurez ICASE y del desarrollador.
Pg. 72 .
Hemos de destacar que el uso del trmino objeto en Puntos Objeto define pantallas, informes y mdulos
3GL como objetos. Esto puede tener relacin no con otras definiciones de objetos como aquellas
caractersticas de posesin tales como, por ejemplo, pertenencia a una clase, herencia, encapsulacin, paso de
mensajes y as sucesivamente. Las reglas de recuento para objetos de esa naturaleza, cuando se usan en
lenguajes como C++, se discutirn en el Captulo del Modelo Post-Arquitectura.
1. Hacer el recuento de objetos: Estimar el nmero de pantallas, informes y componentes de las que
consta esta aplicacin. Suponer las definiciones estndar de estos objetos en el entorno ICASE
correspondiente.
2. Clasificar cada instancia de objeto dentro de niveles de complejidad simple, media y difcil
dependiendo de los valores de las dimensiones de la caracterstica. Usar la tabla 7.3:
Para Pantallas
Para Informes
# y fuente de tablas de datos
N de
vistas que
contiene
Total<4
(<2 srvr
<3 clnt)
Simple
Total<8
(2/3 srvr
3-5 clnt)
Simple
Total 8+
(>3 srvr
>5 clnt)
Medio
3 7
Simple
Medio
>8
Medio
Difcil
<3
# y fuente de tablas de datos
N de
secciones
que
contiene
01
Total<4
(<2 srvr
<3 clnt)
Simple
Total<8
(2/3 srvr
3-5 clnt)
Simple
Total 8+
(>3 srvr
>5 clnt)
Medio
Difcil
23
Simple
Medio
Difcil
Difcil
4+
Medio
Difcil
Difcil
Tabla 7.3. Complejidad asociada a las instancias de objetos
3. Pesar el nmero de cada celda usando la tabla 7.4. El peso refleja el esfuerzo relativo que se requiere
para implementar una instancia de ese nivel de complejidad:
Tipo de Objeto
Complejidad-Peso
Simple
Medio
Difcil
Pantalla
Informe
Componente 3 GL
10
Pg. 73 .
Tabla 7.4.
Pesos asociados a los niveles de complejidad
4. Determinar Puntos Objeto: Suma todas las instancias de objeto pesadas para conseguir un
nmero. El recuento de Puntos Objeto.
5. Estimar el porcentaje de reutilizacin que se espera lograr en este proyecto. Calcular los nuevos
Puntos Objeto a desarrollar.
(Object
Points)
(100
NOP =
100
6. Determinar un ratio de productividad PROD = NOP/Meses-persona a partir de la tabla 7.5:
Experiencia y
capacidad de los
desarrolladores
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
ICASE madurez y
capacidad
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
13
25
50
PROD
Tabla 7.5
Ratio de productividad PROD
7. Calcular el valor Meses-persona estimado segn la ecuacin:
NOP
MM =
PROD
7.4. EL MODELO DE DISEO ANTICIPADO Y POST-ARQUITECTURA.

Los modelos de Diseo Anticipado y Post-Arquitectura se basan en la misma filosofa a la hora de
proporcionar una estimacin. Como hemos indicado ya su principal diferencia se produce en la cantidad y
Pg. 74 .
detalle de la informacin que se utiliza para obtener la estimacin en cada uno de ellos. La frmula bsica
para obtener una estimacin de esfuerzo con ambos modelos es:
MM
NOMINAL
= A X
(Size)B
Esta ecuacin calcula el esfuerzo nominal para un proyecto de un tamao dado expresado en Meses-persona
(MM).
Las entradas son la medida del desarrollo del software, una constante, A, y un factor de escala, B. La medida
est en unidades de lneas de cdigo fuente (KSLOC). Esto se deriva de la medida de mdulos software que
constituirn el programa de aplicacin, puede estimarse tambin a partir de Puntos de Funcin sin ajustar
convirtiendo a SLOC y luego dividiendo por 1000.
El factor de escala (exponencial B), explica el ahorro gasto relativo de escala encontrado en proyectos
software de distintos tamaos. La constante A, se usa para cortar los efectos multiplicativos de esfuerzo en
proyectos de tamao incremental.
A continuacin desarrollamos la frmula completa del modelo de Diseo Anticipado y se describen sus
componentes.
7.4.1. CONSTANTE A.
Como ya hemos visto anteriormente la constante A, se usa para capturar los efectos multiplicativos de
esfuerzo en proyectos de tamao incremental. Provisionalmente se le ha estimado un valor de 2.45.
7.4.2. VARIABLE SIZE.
Dnde:
BRAK
Size
= Size
100
1
COCOMO II utiliza un porcentaje de Rotura BRAK para ajustar el tamao eficaz del producto. La rotura
refleja la volatilidad de los requisitos en un proyecto. Es el porcentaje de cdigo desperdiciado debido a la
volatilidad de los requisitos. El factor BRAK no se usa en el Modelo de Composicin de Aplicaciones donde
se espera un cierto grado de iteracin en el producto y se incluye en la calibracin de datos.
Pg. 75 .
Por ejemplo, un proyecto que parte de 100.000 instrucciones (Size = 100.000) pero desecha el equivalente a
20.000 instrucciones tiene un valor de BRAK de 20. Esto debe usarse para ajustar el tamao efectivo del
proyecto a 120.000 instrucciones para una estimacin COCOMO II. (Size = 100.000 x [1 + (20/100)])
El tamao de una aplicacin se mide en unidades de lneas de cdigo fuente (KSLOC). Al igual que en la
versin inicial del COCOMO, este valor se deriva de la medida de mdulos software que constituirn el
programa de aplicacin, sin embargo, en la nueva versin COCOMO II puede estimarse tambin a partir de
Puntos de Funcin sin ajustar convirtiendo a SLOC y luego dividiendo por 1000.
Si se opta por utilizar directamente el valor del nmero de lneas de cdigo, la meta es medir la cantidad de
trabajo intelectual que se emplea en el desarrollo del programa, pero las dificultades aparecen al intentar
definir medidas consistentes en diferentes lenguajes.
Si se opta por utilizar los Puntos de Funcin sin Ajustar para determinar el tamao del proyecto, stos deben
convertirse en lneas de cdigo fuente en el lenguaje de implementacin (ensamblador, lenguajes de alto
nivel, lenguajes de cuarta generacin, etc...) para evaluar la relativamente concisa implementacin por
Puntos de Funcin (ver tabla 7.6). COCOMO II realiza esto tanto en el Modelo de Diseo Anticipado como
en el de Post-Arquitectura usando tablas que traducen Puntos de Funcin sin ajustar al equivalente SLOC.
Pg. 76 .
Lenguaje
Tabla 7.6.
SLOC / UFP
Ada
71
Al Shell
49
APL
32
Assembly
320
Assembly (Macro)
213
ANSI/Quick/Turbo Basic
64
Basic Compiled
91
Basic Interpreted
128
128
C++
29
Visual Basic
32
ANSI Cobol 85
91
Fortran 77
105
Forth
64
Jovial
105
Lisp
64
Modula 2
80
Pascal
91
Prolog
64
Report Generator
80
Spreadsheet
Conversin de Puntos de Funcin a Lneas de cdigo
A continuacin slo nos quedara por hacer la conversin a KSLOC mediante la operacin
SLOC/1000.
Por ejemplo, si al aplicar el procedimiento de clculo para puntos de

funcin sin ajustar se obtiene un resultado de 165 UNFP (Puntos de
Funcin sin Ajustar) y el proyecto va a desarrollarse en el lenguaje de
programacin C++:
165 UNFP x 29 = 4785 SLOC (Lneas de Cdigo Fuente)
Haciendo la conversin mencionada anteriormente:
4785/1000= 4.785 KSLOC (Miles de Lneas de Cdigo Fuente).
Pg. 77 .
7.4.3. Variable B (ahorro y gasto software de escala).
B = 0.91+ 0.01 x
SFj
Los modelos de estimacin de coste del software a menudo tienen un factor exponencial para considerar los
gastos y ahorros relativos de escala encontrados en proyectos software de distinto tamao. El exponente B se
usa para capturar estos efectos. El valor de B es calculado en la ecuacin anterior.
Si B < 1.0. El proyecto presenta ahorros de escala. Si el tamao
del producto se dobla, el esfuerzo del proyecto es menor que el
doble. La productividad del proyecto aumenta a medida que aumenta
el tamao del producto. Pueden lograrse algunos ahorros de escala
del proyecto con herramientas de proyecto especficas (por ejemplo,
simulaciones, testbeds) pero normalmente es difcil lograrlo. Para
proyectos pequeos, fijar costes de salida tales como herramientas
a medida y normas de montaje, e informes administrativos, son a
menudo una fuente de ahorro de escala.
Si B = 1.0. Los ahorros y gastos de escala estn equilibrados. Este

modelo lineal se usa a menudo
para la estimacin de coste de
proyectos pequeos. Se usa para el modelo COCOMO II: Composicin de
Aplicaciones.
Si B > 1.0. El proyecto presenta gastos de escala. Esto se debe

normalmente a dos factores principales: El crecimiento del gasto en
comunicaciones y el gasto en crecimiento de la integracin de un
gran sistema. Los proyectos ms grandes tendrn ms personal y por
lo tanto ms vas de comunicacin interpersonales produciendo
gasto. Integrar un producto pequeo como parte de uno ms grande
requiere no slo el esfuerzo de desarrollar el producto pequeo sino
tambin el gasto adicional en esfuerzo para disear, mantener, integrar y probar sus
interfaces con el resto del producto.
El exponente B se obtiene mediante los denominados drivers de escala. La seleccin de drivers de escala se
basa en la razn de que ellos son un recurso significante de variacin exponencial en un esfuerzo variacin
de la productividad del proyecto. Cada driver de escala tiene un rango de niveles de valores desde Muy Bajo
hasta Extra Alto (tabla 7.7). Cada nivel de valores tiene un peso, SF, y el valor especfico del peso se llama
Pg. 78 .
factor de escala. Un factor de escala de un proyecto, SFj (ver tabla 7.8), se calcula sumando todos los
factores y se usa para determinar el exponente de escala, B.
Factores de
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
Escala (SFj)
PREC
Prcticamen-
Completa-
FLEX
RESL*
TEAM
sin Algo familiar Muy familiar
sin precedentes
sin te
mente
Casi
Completamente
familiar
precedentes
precedentes
Riguroso
Relajacin
Algo
ocasional
relajacin
general
conformidad
Algo (40%)
A menudo
Generalmen-
En su mayor Por completo
(60%)
te (75%)
parte (90%)
(100%)
Bastante
Altamente
Completas
cooperativo
cooperativo
interacciones
Poco (20%)
de Conformidad Algo
de Interacciones
Interacciones
Algo
muy difciles
dificultad en bsicamente
de Metas
generales
cooperativas
las
interacciones
PMAT
Peso medio de respuestas S para el cuestionario de Madurez CMM
Tabla 7.7. Factores de escala para el Modelo de COCOMO II de Diseo Anticipado.

*
% de mdulos de interfaz significativos especificados, % de riesgos

significativos eliminados.
Factores de
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
PREC
6.20
4.96
3.72
2.48
1.24
0.00
FLEX
5.07
4.05
3.04
2.03
1.01
0.00
RESL*
7.07
5.65
4.24
2.83
1.41
0.00
TEAM
5.48
4.38
3.29
2.19
1.10
0.00
PMAT
7.80
6.24
4.68
3.12
1.56
0.00
Escala (Wi)
Tabla 7.8. Valores de los Factores de escala para el Modelo de COCOMO II de Diseo
Anticipado pertenecientes a la versin USC-COCOMOII.1999.0
Pg. 79 .
Por ejemplo, si tenemos factores de escala con valores Muy Bajo,

entonces un proyecto 100 KSLOC
esfuerzo relativo E= E=100
tendr
SFj = 31,62, B=1.2325 y un
1.2325
=291 PM.
Los valores actuales de los factores de escala estn reflejados en

la tabla 7.8.
(PREC) (FLEX). Precedencia y Flexibilidad de desarrollo.

Estos dos factores de escala capturan en gran parte las diferencias entre los modos Orgnico, Semilibre y
Rgido del modelo original COCOMO. La tabla 7.9 se organiza para trazar su rango de proyecto dentro de
las escalas de Precedencia y Flexibilidad de desarrollo.
Caractersticas
Muy Bajo
Nominal/Alto
Extra Alto
General
Considerable
Profundo
Moderado
Considerable
Extenso
Extenso
Moderado
Algo
Considerable
Algo
Mnimo
Completo
Considerable
Bsico
Completo
Considerable
Bsico
Alto
Medio
Bajo
Precedencia
Comprensin
organizacional
Experiencia en trabajo con
sistemas Sw relacionados
Desarrollo concurrente de
nuevo Hw asociado y
procedimientos
operacionales
Necesidad de arquitecturas
de proceso de datos
innovativas, algoritmos
Flexibilidad de Desarrollo
Necesidad de conformidad
del Sw con requisitos
preestablecidos
Necesidad de conformidad
del Sw con especificaciones
de interfaz externas
Prioridad en finalizacin
anticipada
Tabla 7.9. Factores de escala relacionados con Modos de desarrollo COCOMO
Pg. 80 .
(RESL) Arquitectura/Resolucin de Riesgos

Este factor combina dos factores de medida de AdaCOCOMO Minuciosidad del diseo por revisin del
diseo del producto (PDR) y Eliminacin de riesgos por PDR. La tabla 7.10 consolida las medidas de
AdaCOCOMO para formar una definicin ms comprensiva de los niveles de medida RESL de COCOMO
II. La medida de RESL es la media pesada subjetiva de las caractersticas de la lista.
Pg. 81 .
Caractersticas
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
El plan de gestin de riesgos

identifica todos los tems de
riesgos crticos, establece
hitos para resolverlos
mediante PDR
Horario, presupuesto e hitos
internos con PDR
compatible con el Plan de
gestin de riesgos
Tanto por ciento de horario
desarrollado dedicado a
establecer la arquitectura
dados los objetivos
generales del producto
Porcentaje de arquitectos Sw
de alto nivel requeridos,
disponibles para el proyecto
Ninguno
Poco
Algo
Generalmente
A menudo
Completamente
Ninguno
Poco
Algo
Generalmente
A menudo
Completamente
10
17
25
33
40
20
40
60
80
100
120
Herramientas de soporte
disponibles para resolver
tems de riesgo, desarrollar y
verificar garantas de la
arquitectura
Nivel de incertidumbre en
drivers de arquitectura
claves: misin ,interfaz de
usuario, COTS, Hw,
tecnologa, ejecucin
Ninguno
Poco
Algo
Bueno
Fuerte
Completo
Algo
Poco
Muy Poco
1
Crtico
>5 No
Crtico
<5 No Crtico
Nmero y criticidad de tems

de riesgo
Extremo
>10
Crtico
Significativo Considerable
5-10
Crtico
2-4 Crtico
Tabla 7.10. RESL Componentes de medida

(TEAM). Cohesin del Equipo
El factor de escala de Cohesin del Equipo explica los recursos de turbulencia y entropa del proyecto debido
a dificultades en la sincronizacin de los implicados en el proyecto, usuarios, clientes, desarrolladores, los
que lo mantienen, etc... Estas dificultades pueden aparecer por las diferentes culturas y objetivos de los
implicados; dificultades en conciliar objetivos y la falta de experiencia y de familiaridad de los implicados en
trabajar como un equipo. La tabla 7.11 proporciona una informacin detallada para los niveles de medida
completos TEAM. La medida final es la media pesada subjetiva de las caractersticas de la lista.
Pg. 82 .
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
Poco
Algo
Bsico
Considerable
Fuerte
Completo
Poco
Algo
Bsico
Considerable
Fuerte
Completo
Nada
Poco
Poco
Bsico
Considerable
Extensa
Nada
Poco
Poco
Bsico
Considerable
Extensa
Caractersticas
Consistencia de
objetivos y culturas
Habilidad y
servicialidad
para acomodar
objetivos de otros
grupos
Experiencia de los
Desarrollados
en operar como un
equipo
Para lograr visin
compartida y
compromisos
Tabla 7.11.
TEAM Componentes de medida
(PMAT). Madurez del proceso

El procedimiento para determinar PMAT se obtiene a travs del Modelo de Madurez de Capacidad del
Instituto de Ingeniera del Software (CMM). El periodo de tiempo para medir la madurez del proceso es el
momento en el que el proyecto comienza. Hay dos formas de medir la madurez del proceso. La primera toma
el resultado de una evaluacin organizada basada en el CMM.
Nivel de Madurez Global
Nivel
Nivel
Nivel
Nivel
Nivel
Nivel
1
1
2
3
4
5
CMM (Mitad inferior)

CMM (Mitad superior)
CMM
CMM
CMM
CMM
reas de Proceso Principales
La segunda est organizada en base a 18 reas de proceso principales (KPAs) en el modelo de Madurez de
Capacidad SEI. El procedimiento para determinar PMAT es decidir el porcentaje de conformidad para cada
uno de los KPAs. Si el proyecto ha sufrido una valoracin CMM reciente entonces se usa el porcentaje de
Pg. 83 .
conformidad para la KPA global (basada en datos de valoracin de la conformidad prctica principal). Si no
se ha hecho una valoracin entonces se usan los niveles de conformidad para las metas de los KPAs (con la
escala Likert de abajo) para poner el nivel de conformidad. El nivel basado en meta (objetivo) de
conformidad se determina haciendo una media basada en juicio de las metas de cada rea de proceso
principal (ver tabla 7.12.).
reas de Proceso
Clave
Frecuente-
En la Mitad
Ocasional-
En Pocas
Casi siempre
mente
(40-60%)
mente
Ocasiones
(10-40%)
(<10%)
No se Aplica
No se Conoce
(>90%)
(60-90%)
de
2 Planificacin de
de
Aseguramiento
de
del
de
de
Gestin
requisitos
proyectos
Software
3 Seguimiento de
proyecto Software
4
Gestin
subcontrato
Software
5
de
la
calidad
Software
6 Gestin de la
configuracin
Software
7 Focos de proceso
de organizacin
8
Definicin
proceso
de
de
organizacin
9
Programa
formacin
10
Gestin
Software integrado
11 Ingeniera de
producto Software
12
Coordinacin
intergrupos
13
Informes
detallados
14
Gestin
proceso
cuantitativo
15
Gestin
calidad Software
16 Prevencin de
defectos
17
Gestin
cambio
de
de
tecnologa
Pg. 84 .

18
Gestin
de
cambio de proceso
Tabla 7.12.
Porcentaje de conformidad para las reas de

proceso principales.
Verificar casi siempre, cuando las metas se logran de forma consistente y se establecen bien en
procedimientos que operan bajo la norma (alrededor del 90% del tiempo).
Verificar frecuentemente, cuando las metas se logran relativamente a menudo pero algunas veces se
pasan por alto bajo circunstancias difciles (alrededor del 60% al 90% del tiempo).
Verificar sobre la metas, cuando las metas se logran alrededor de la mitad del tiempo (alrededor del
40% al 60% del tiempo).
Verificar ocasionalmente, cuando las metas se logran a veces pero menos a menudo (entre el 10% y
3l 40% del tiempo).
Casi nunca verificar, si las metas no se alcanzan casi nunca (menos del 10% del tiempo).
No aplicar verificacin, cuando se tiene conocimiento requerido para tu proyecto u organizacin y el
KPA pero siente que el KPA no se adapta a tus circunstancias.
No sabe verificar cuando no sabes cmo responder para el KPA.
Despus de que el nivel de conformidad del KPA se determina, se pesa cada nivel de conformidad y se
calcula un factor PMAT. Inicialmente todos los KPAs tendrn el mismo peso.
18
5 -
KPA%i
100
Por ejemplo, el valor del factor PMAT para un caso en el que aplicando la
tabla de reas de Proceso Clave: (Tabla 7.12.), obtengamos los siguientes
resultados:
1. Gestin de requisitos: 90%
2. Planificacin de Proyectos Software: 50%
Pg. 85 .
3. Seguimiento del proyecto software: 60%

4. Gestin de subcontrato software: 30%
5. Aseguramiento de la calidad software: 60%
6. Gestin de la configuracin software: 80%
7. Focos de proceso de organizacin: 50%
8. Definicin de proceso de organizacin: 45%
9. Programa de formacin: 80%
10. Gestin del software integrado: 60%
11. Ingeniera de producto software: 40%
12. Coordinacin intergrupos: 60%
13. Informes detallados: 80%
14. Gestin de proceso cuantitativo: 10%
15. Gestin de calidad software: 25%
16. Prevencin de defectos: 20%
17. Gestin de cambio de tecnologa: 60%
18. Gestin de cambio de proceso: 45%
ser:
PMAT= 5- (9.45 X (5/18)) = 2.375
7.4.4. AJUSTE MEDIANTE DRIVERS DE COSTE
Los drivers de coste se usan para capturar caractersticas del desarrollo del software que afectan al esfuerzo
para completar el proyecto. Los drivers de coste tienen un nivel de medida que expresa el impacto del driver
en el esfuerzo de desarrollo. Estos valores pueden ir desde Extra Bajo hasta Extra Alto. Para el propsito del
anlisis cuantitativo, cada nivel de medida de cada driver de coste tiene un peso asociado. El peso se llama
multiplicador de esfuerzo (EM). La medida asignada a un driver de coste es 1.0 y el nivel de medida
asociado con ese peso se llama nominal. Si un nivel de medida produce ms esfuerzo de desarrollo de
software, entonces su correspondiente EM est por encima de 1.0. Recprocamente si el nivel de medida
reduce el esfuerzo entonces el correspondiente EM es menor que 1.0. La seleccin de multiplicadores de
esfuerzo se basa en una fuerte razn que explicara una fuente significativa de esfuerzo de proyecto
variacin de la productividad independientemente.
Los EM se usan para ajustar el esfuerzo Meses-persona nominal. Hay 7 multiplicadores de esfuerzo para el
Modelo de Diseo Anticipado y 17 para el modelo de Post-Arquitectura.
MM = A x (Size)B x
EMi
Pg. 86 .
Los drivers de coste del Diseo Anticipado se obtienen combinando los drivers de coste del modelo PostArquitectura de la tabla 7.13. Siempre que una evaluacin de un driver de coste est entre niveles de ratio,
hay que redondear al valor ms prximo al nominal. Por ejemplo, si un valor de un driver de coste est entre
Muy Bajo y Bajo, entonces seleccionar Bajo.
Drivers de coste del Diseo
Drivers de coste combinados,
Anticipado
homlogos del Post-Arquitectura
RCPX
RELY, DATA, CPLX, DOCU
RUSE
RUSE
PDIF
TIME, STOR, PVOL
PERS
ACAP, PCAP, PCON
PREX
AEXP, PEXP, LTEX
FCIL
TOOL, SITE
SCED
SCED
Tabla 7.13.
Multiplicadores de esfuerzo del Diseo Anticipado

y Post-Arquitectura
7.4.4.1. OBTENCIN DE DRIVERS DE COSTE PARA MODELO DE DISEO ANTICIPADO

(RCPX). Fiabilidad del Producto y Complejidad
Este driver de coste del Diseo Anticipado combina los 4 drivers de coste: Fiabilidad Software (RELY);
Tamao de la Base de Datos (DATA), Complejidad del Producto (CPLX), y Documentos que necesita el
Ciclo de Vida (DOCU).
La tabla 7.14 proporciona los niveles de medida de RCPX
nfasis
en
fiabilidad,
Extra Bajo
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
Muy Poco
Poco
Algo
Bsico
Fuerte
Muy Fuerte
Extremo
la
documentacin
Pg. 87 .
Complejidad
del
producto
ExtremadaMuy Simple
Simple
Algo
Moderado
Complejo
Muy Complejo
mente
Complejo
Medida de la Base
Pequeo
de Datos
Pequeo
Pequeo
Tabla 7.14.
Moderado
Grande
Muy Grande
Muy Grande
Niveles de medida RCPX
(RUSE) Reutilizacin Requerida

Este driver de coste del modelo de Diseo Anticipado (tabla 7.15) es el mismo que su homlogo de PostArquitectura.
Muy Bajo
Bajo
RUSE
Nada
Nominal
Alto
A lo largo del
A lo largo del
programa
proyecto
Muy Alto
Extra Alto
A lo largo de la
A lo largo de
lnea de
mltiples lneas
producto
de producto
Tabla 7.15. Resumen del nivel de medida RUSE
(PDIF) Dificultad de la Plataforma

Este driver de coste del Diseo Anticipado combina los 3 drivers de coste de Post-Arquitectura siguientes:
Tiempo de Ejecucin (TIME), Restricciones de Almacenamiento (STOR) y Volatilidad de la Plataforma
(PVOL). La tabla 7.16 proporciona una ayuda para obtener los niveles de medida PDIF.
Restricciones
de
tiempo
de
Bajo
Nominal
Alto
Muy Alto
Extra Alto
50%
>50%
65%
80%
90%
Muy Estable
Estable
Voltil
Voltil
Voltil
almacenamiento
Volatilidad
Plataforma
de
la
Tabla 7.16. Niveles de medida PDIF
(PREX) Experiencia Personal

Pg. 88 .
Este driver de coste de Diseo Anticipado combina los 3 drivers de coste de Post-Arquitectura siguientes:
Experiencia (AEXP), Experiencia en la Plataforma (PEXP) y Experiencia en el Lenguaje y Herramientas
(LTEX). La tabla 7.17 asigna valores PREX en el rango correspondiente.
Extra Bajo
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
3 Meses
5 Meses
9 Meses
1 Ao
2 Aos
4 Aos
6 Aos
Experiencia en
aplicaciones,
plataforma,
lenguaje
herramienta
Tabla 7.17. Niveles de medida PREX
(FCIL) Facilidades
Este driver de coste de Diseo Anticipado combina los 2 drivers de coste de Post-Arquitectura siguientes:
Uso de Herramienta Software (TOOL) y Desarrollo MultiLugar (SITE). La tabla 7.18 de la asigna valores
FCIL.
Extra Bajo
Soporte
de
TOOL
Condiciones
Multilugar
Mnimo
Muy Bajo
Algo
Bajo
Herramienta
CASE simple
Nominal
Herramientas de
ciclo de vida
bsicas
Alto
Muy Alto
Extra Alto
Bueno;
Fuerte;
Fuerte; Bien
moderado
moderado
integrado
Soporte
Algo de
Algo de soporte de
Soporte bsico de
Fuerte soporte de
dbil de
soporte de
desarrollo
desarrollo
desarrollo
desarrollo
desarrollo
multilugar
multilugar
multilugar
multilugar
multilugar
moderadamente
moderadamente
moderadamente
complejo
complejo
complejo
complejo
complejo
Fuerte soporte
de desarrollo
multilingue
simple
Soporte muy
fuerte de
desarrollo
multilingue
simple
Tabla 7.18. Niveles de medida FCIL

(SCED) Planificacin Temporal
El driver de coste de Diseo Anticipado (tabla 7.19.) es el mismo que su homlogo de Post-Arquitectura.
Pg. 89 .
Muy Bajo
SCED
75% del
Nominal
Bajo
Nominal
Alto
Muy Alto
85%
100%
130%
160%
Extra Alto
Tabla 7.19. Resumen de nivel de medida SCED

En la tabla 7.20. se reflejan los valores actualizados que toman los drivers de coste para el modelo de Diseo
Anticipado:
Extra Bajo
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra
Alto
RCPX
0.73
0.81
0.98
1.00
1.30
1.74
2.38
RUSE
--
--
0.95
1.00
1.07
1.15
1.24
PDIF
--
--
0.87
1.00
1.29
1.81
2.61
PERS
2.12
1.62
1.26
1.00
0.83
0.63
0.50
PREX
1.59
1.33
1.12
1.00
0.87
0.71
0.62
FCIL
1.43
1.30
1.10
1.00
0.87
0.73
0.62
SCED
--
1.43
1.14
1.00
1.00
1.00
--
Tabla 7.20. Multiplicadores de esfuerzo actualizados para el modelo de Diseo Anticipado

pertenecientes a la versin USC-COCOMOII.1999.0.
Por ejemplo, si al analizar los drivers de coste para nuestro proyecto obtenemos los siguientes resultados:
EMB
RCPX
A
x
MA EA
EB=Extra Bajo
MB=Muy Bajo
RUSE
PDIF
PERS
B=Bajo
N=Nominal
A=Alto
MA=Muy Alto
Pg. 90 .
EMB
PREX
FCIL
SCED
MA EA
Aplicando los valores de la tabla 7.20 obtendremos:

7
EMi = 1.30 x 1 x 1 x 1 x 0.87 x 0.87 x 1.0 = 0.984

i =1
En los drivers de coste como por ejemplo FCIL (ver tabla 7.18) se evalan varias caractersticas, en este
caso Soporte de TOOL y Condiciones multilugar. El resultado Alto se ha obtenido de hacer la media
subjetiva entre Soporte de TOOL= Alto y Condiciones Multilugar = Muy Alto. Esta media es Alto porque
como hemos visto anteriormente siempre que una evaluacin de un driver de coste est entre dos niveles de
ratio, hay que redondear al nivel ms prximo al nominal. Si la evaluacin hubiese estado entre Extra Bajo
y Bajo la media subjetiva hubiese sido Muy Bajo.
7.4.4.2. OBTENCIN DE DRIVERS DE COSTE PARA MODELO DE DISEO POSTARQUITECTURA

(RELY). Fiabilidad Requerida de Software
Esta es la medida de hasta qu punto el software debe realizar su funcin esperada durante un periodo de
tiempo. Si el efecto de un fracaso es slo una molestia ligera entonces RELY es Bajo. Si un fallo arriesgase
vidas humanas entonces RELY es Muy Alto. (tabla 7.21)
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra
Alto
RELY
Inconveniente
Bajo, prdidas
Moderado,
Alta prdida
Riesgo de vidas
ligero
fcilmente
prdidas
financiera
humanas
recuperables
recuperables
Tabla 7.21. Niveles de medida RELY
(DATA). Medida del Volumen de Datos
Pg. 91 .
Esta medida intenta capturar lo que afecta en el desarrollo del producto unos requerimientos de datos
grandes. La medida se determina calculando D/P. La razn por la que es importante considerar el tamao de
la Base de Datos es por el esfuerzo necesario para generar datos de prueba que se usarn para ejecutar el
programa.
D
=
DataBaseSize (Bytes)
DATA se valora como Bajo si D/P es menor que 10 y Muy Alto si es mayor que 1000 (tabla 7.22).
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
DB bytes/
10 D/P <
100 D/P <
D/P 1000
Pgm SLOC <
100
1000
DATA
Extra Alto
10
Tabla 7.23. Niveles de medida DATA

(CPLX). Complejidad del Producto
La Tabla 7.24 proporciona la nueva escala de valores CPLX de COCOMO II. La complejidad se decide en 5
reas: Funcionamiento de control, Funcionamiento computacional, Funcionamiento de Dispositivos
dependientes, Funcionamiento del sector de datos y Funcionamiento del Gestor de Interfaz de Usuario. Se
seleccionar el rea combinacin de reas que caracterizan al producto a un subsistema del producto. La
medida de complejidad es la media subjetiva de estas reas.
Pg. 92 .
Operaciones de control
Muy Bajo
Operaciones
Operaciones dependientes
Operaciones de gestin de
computacionales
del dispositivo
datos
Operaciones de gestin de
interfaz de usuario
Cdigo straight line con
Evaluacin de expresiones
Declaraciones simples de
Arrays simples en memoria
Forma de entrada simple,
unos pocos operadores
simples:
lectura, escritura con
principal. Actualizaciones,
generadores de informes
estructurados de de
p.e.
formatos simples
COTS-DB queries simples.
programacin no
A=B+C*(D-E)
anidados: DOs, CASESs,

IFTHENELSESs.
Composicin de mdulos
simple va llamadas a
procedimientos simples
scripts
Bajo
Anidamiento sencillo de
Evaluacin de expresiones
No necesario conocimiento
Ficheros nicos sin cambio
Uso de constructores
operadores de
de nivel moderad0: p.e.
de caractersticas del
en la estructura de datos,
simples de interfaces
programacin
D=SQRT(B**2-4.*A*C)
procesador particular del
sin ediciones, sin ficheros
grficos de usuarios
estructurados. Mayora de
dispositivo de I/O. I/O
intermedios. COTS- DB
predicados simples
hecha a nivel GET/PUT.
moderadamente complejos,
queries, actualizaciones.
Nominal
Mayora de anidamiento
Uso de rutinas matemticas
El procesamiento de I/O
Entrada de mltiples
Uso simple de conjunto
simple. Llamadas paso de
y estadsticas estndar.
incluye seleccin de
ficheros y salida de un
widget
mensajes simples que
Operaciones de
dispositivo, estado de
nico fichero. Cambios
incluye procesamiento
matriz/vector bsicas
validacin y procesamiento
estructurales simples,
de errores.
ediciones simples. Queries,
distribuido para soportar

middleware
actualizaciones y COTS-DB
complejas.
Alto
Operadores de
Anlisis numrico bsico;
Operaciones de I/O a nivel
Encadenamientos simples
programacin
Interpolacin multivariada,
fsico (traducciones de
activados por contenidos
conjunto widget. Voz
estructurados altamente
ecuaciones diferenciales
direcciones de
de hileras de datos.
simple de I/O, multimedia.
anidados compuesto de
ordinarias. Truncamiento
almacenamiento fsicas;
. Reestructuracin de datos
muchos predicados.
bsico,
bsquedas, lecturas, etc.)
compleja
Control de pilas y colas.
Overlap de I/O
Proceso homogneo y
optimizada.
Extensin y desarrollo de
distribuido.
Muy Alto
Codificacin reentrante y
Anlisis numrico difcil
Rutinas para diagnstico
Coordinacin de bases de
Moderadamente complejo
recursiva. Manejo de
pero estructurado:
de interrupciones, dar
datos distribuidas.
2D/3D, grficos dinmicos

multimedia
interrupciones con
ecuaciones de matrices ,
servicio enmascaramiento.
Encadenamientos
prioridades fijadas.
ecuaciones diferenciales
Manejo de lnea de
complejos. Optimizacin de
Sincronizacin de tareas,
parciales. Paralelizacin
comunicacin. Sistemas
la bsqueda.
retornos de llamadas
simple.
embebidos de rendimiento
intensivo.
complejas, proceso
distribuido heterogneo.
Control en tiempo real de
un nico procesador
Extra Alto
Mltiples recursos de
Anlisis numrico difcil y
Dispositivo dependiente
Fuerte acoplamiento,
Multimedia compleja,
planificacin con cambio
sin estructurar: anlisis de
temporalmente de la
estructuras de objetos y
realidad virtual
dinmico de prioridades.
ruido altamente
codificacin, operaciones
relacionales dinmicas.
microprogramadas.
Gestin de datos del
Control a nivel de
aproximado, datos
microcdigo. Control
estocsticos. Paralelizacin
distribuido en tiempo real.
compleja.
Tabla 7.24.
lenguaje natural.
Medidas de complejidad del mdulo versus Tipo de

mdulo
(RUSE). Reutilizacin Requerida

Pg. 93 .
Este driver de coste explica el esfuerzo adicional necesario para construir componentes pensados para ser
reutilizados en proyectos presentes futuros (tabla 7.25). Este esfuerzo se consume en crear un diseo ms
genrico del software, documentacin ms detallada y pruebas ms extensas, para asegurar que los
componentes estn listos para utilizar en otras aplicaciones.
Muy Bajo
RUSE
Bajo
Nominal
Alto
Muy Alto
Extra Alto
Nada
A lo largo del
A lo largo del
A lo largo de
A lo largo de
programa
proyecto
la lnea de
las lneas de
producto
producto
mltiples
Tabla 7.25. Niveles de medida RUSE

(DOCU). Documentacin Asociada a las Necesidades del Ciclo de Vida
Varios modelos de coste software tienen un driver de coste para el nivel de documentacin requerida. En
COCOMO II la escala de medida para el driver de coste se evala en trminos de la adecuacin de la
documentacin del proyecto a las necesidades de su ciclo de vida (tabla 7.26). La escala de valores va desde
Muy Bajo (muchas necesidades del ciclo de vida sin cubrir) hasta Muy Alto (excesiva para las necesidades
del ciclo de vida).
DOCU
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Muchas
Algunas
Necesidades
Excesivas
Necesidades muy
necesidades
elevadas para el
para el ciclo de
ciclo de vida
necesidades del necesidades del correctas al ciclo

ciclo de vida
ciclo de vida
sin cubrir
sin cubrir
de vida
Extra Alto
vida
Tabla 7.26. Niveles de medida DOCU

Factores de Plataforma
La plataforma se refiere a la complejidad del objetivo-mquina del hardware y la infraestructura software
(anteriormente llamada mquina virtual). Los factores deben ser revisados para reflejar esto tal y como se
describe en esta seccin. Se consideraron algunos factores de la plataforma adicionales, tales como,
distribucin, paralelismo, rigidez y operaciones en tiempo real.
(TIME). Restriccin del Tiempo de Ejecucin
Pg. 94 .
Esta es una medida de la restriccin del tiempo de ejecucin impuesta en un sistema software. Las medidas
se expresan en trminos de porcentaje de tiempo de ejecucin disponible que se espera que sea usado por el
subsistema sistema que consume el recurso de tiempo de ejecucin. Los valores van desde nominal, menos
del 50% de recursos de tiempo de ejecucin utilizados, hasta Extra Alto, 95% del recurso de tiempo de
ejecucin consumido (tabla 7.27).
Muy Bajo
Bajo
TIME
Nominal
Alto
Muy Alto
Extra Alto
50% del uso de
70%
85%
95%
tiempo de
ejecucin
disponible
Tabla 7.27. Niveles de medida TIME

(STOR). Restriccin de Almacenamiento Principal
Esta medida representa el grado de restriccin de almacenamiento principal impuesto a un sistema
subsistema software. Dado el notable aumento en el tiempo de ejecucin disponible del procesador y de
almacenamiento principal, uno puede cuestionar si estas variables de restriccin son todava pertinentes. Los
valores van desde nominal, menos que el 50%, a Extra Alto, 95% (tabla 7.28).
Muy Bajo
Bajo
STOR
Nominal
Alto
Muy Alto
Extra Alto
50% del uso
70%
85%
95%
del almacenamiento
disponible
Tabla 7.28. Niveles de medida STOR

(PVOL). Volatilidad de la Plataforma
Plataforma se usa aqu para significar la complejidad del Hardware y Software (OS, DBMS, etc.) que el
producto software necesita para realizar sus tareas. Si el software a desarrollar es un sistema operativo,
entonces la plataforma es el hardware del ordenador. Si se desarrolla un Gestor de Base de Datos, entonces la
plataforma es el hardware y el sistema operativo. Si se desarrolla un browser de texto de red, entonces la
plataforma es la red, el hardware del ordenador, el sistema operativo y los repositorios de informacin
distribuidos. La plataforma incluye cualquier compilador ensamblador que soporta el desarrollo del sistema
Pg. 95 .
software. Los valores van desde Bajo donde cada 12 meses hay un cambio importante, hasta Muy Alto,
donde hay un cambio importante cada 2 semanas (tabla 7.29).
Muy
Bajo
Nominal
Alto
Muy Alto
Bajo
Alto
Mayor
PVOL
Extra
cambio Mayor: 6 meses
cada 12 meses
Menor
Menor: 2 semanas
Mayor: 2 meses
Mayor: 2 semanas
Menor: 1 semana
Menor: 2 das
cambio
cada mes
Tabla 7.29. Niveles de medida PVOL

Factores de Personal
(ACAP). Habilidad del Analista
Los analistas son personal que trabaja en los requisitos de diseo de alto nivel y en diseo detallado. Los
atributos principales que deben considerarse en esta medida son la habilidad de anlisis y diseo, la
eficiencia y minuciosidad y la habilidad para comunicar y cooperar. La medida no debe considerar el nivel
de experiencia del analista, eso se mide con AEXP. Los analistas que caen en el 90vo percentil se evalan
como Muy Alto (tabla 7.30.).
ACAP
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
15 percentil
35 percentil
55 percentil
75 percentil
90 percentil
Extra Alto
Tabla 7.30. Niveles de medida ACAP

(PCAP). Habilidad del Programador
Las tendencias actuales continan dando nfasis a la capacidad de los analistas. Sin embargo el creciente
papel de los paquetes complejos COTS y la relevante influencia asociada a la capacidad de los
programadores para tratar con esos paquetes COTS, indica una tendencia tambin a darle mayor importancia
a la capacidad del programador.
La evaluacin debe basarse en la capacidad de los programadores como un equipo, ms que individualmente.
La habilidad del programador no debe considerarse aqu, eso se mide con AEXP. Unos valores Muy Bajos
del equipo de programadores es el 15avo percentil y Muy Alto en el 90vo percentil (tabla 7.31).
Pg. 96 .
PCAP
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
15 percentil
35 percentil
55 percentil
75 percentil
90 percentil
Extra Alto
Tabla 7.31. Niveles de medida PCAP

(AEXP). Experiencia en las Aplicaciones
Esta medida depende del nivel de experiencia en aplicaciones del equipo de proyecto al desarrollar sistemas
subsistemas software. Los valores se definen en trminos de nivel de experiencia del equipo de proyecto en
este tipo de aplicaciones. Un valor muy bajo para experiencia en aplicaciones es menor que 2 meses. Un
valor muy alto es por experiencia de 6 aos ms (tabla 7.32).
AEXP
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
2 meses
6 meses
1 ao
3 aos
6 aos
Extra Alto
Tabla 7.32. Niveles de medida AEXP
(PEXP). Experiencia en la Plataforma

El modelo post-Arquitectura ampla la influencia en productividad de PEXP, reconociendo la importancia
de entender el uso de plataformas ms poderosas, incluyendo ms interfaces grficos de usuario, redes y
capacidades de middleware distribuido (tabla 7.33).
PEXP
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
2 meses
6 meses
1 ao
3 aos
6 aos
Extra Alto
Tabla 7.33. Niveles de medida PEXP
(LTEX). Experiencia en la Herramienta y en el Lenguaje
Pg. 97 .
Esta es una medida del nivel de experiencia en el lenguaje de programacin y en la herramienta software del
equipo de proyecto que desarrolla el sistema subsistema software. El desarrollo de software incluye el uso
de herramientas que realizan representacin de requisitos y diseo, anlisis, gestin de la configuracin,
origen de los documentos, gestin de librera, estilo de programa y estructura, verificacin de consistencia,
etc...Adems de la experiencia programando en un lenguaje especfico, las herramientas que dan soporte
tambin influyen en el tiempo de desarrollo. Tener una experiencia de menos de 2 meses da un valor Bajo. Si
es de 6 ms aos el valor es Muy Alto (tabla 7.34).
LTE
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
2 meses
6 meses
1 ao
3 aos
6 aos
Extra Alto
Tabla 7.35. Niveles de medida LTEX
(PCON). Continuidad del Personal

La escala de valores de PCON se mide en trminos del movimiento de personal del proyecto anualmente:
desde 3%, Muy Ato, hasta el 48%, Muy Bajo (tabla 7.36).
PCON
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
48% /ao
24% /ao
12% /ao
6% /ao
3% /ao
Extra Alto
Tabla 7.36. Niveles de medida PCON
Factores del Proyecto

(TOOL). Uso de Herramientas Software
Las herramientas software han mejorado significativamente desde los proyectos de los 70 usados para
calibrar COCOMO. Los valores para la herramienta van desde edicin y cdigo simple, Muy Bajo, hasta
herramientas integradas de gestin del ciclo de vida, Muy Alto (tabla 7.37).
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra
Alto
Pg. 98 .
TOOL
Editar,
Simple,
Herramientas
Fuerte,
Fuerte, maduro,
Cdigo,
frontend,
de ciclo de
herramientas de
herramientas de ciclo de
Depuracin
backend
vida bsicas
ciclo de vida
vida proactivas, bien
CASE,
maduras,
integrado con los
integracin
moderada-mente
procesos, mtodos,
pequea
integrada
reutilizacin

(SITE). Desarrollo Multilugar
Dada la frecuencia creciente de desarrollos multilugar e indicaciones de que los efectos del desarrollo
multilugar son significantes. Se ha aadido en COCOMO II el driver de coste SITE. Determinar la medida
del driver de coste incluye el clculo y la medida de 2 factores: Localizacin del lugar (desde totalmente
localizado hasta distribucin internacional) y soporte de comunicacin (desde correo de superficie y algn
acceso telefnico hasta multimedia totalmente interactivo) (tabla 7.38).
SITE:
Localizacin
Muy Bajo
Bajo
Nominal
Internacion
Multi-
Multi-
al
ciudad y
ciudad o
Multi-
Multi-
compaa
compaa
Alto
Muy Alto
Extra Alto
Misma ciudad Mismo edificio Completamenrea metrop.
complejo
te localizado
SITE:
Algo de
Telfono
Banda
Comunicacin
Comunicacin
Multimedia
Comunicaciones
telfono,
individual
estrecha,
electrnica de
electrnica de
interactiva
mail
FAX
mail
banda ancha
banda ancha,
video
conferencia
ocasional
Tabla 7.38. Niveles de medida SITE

(SCED). Calendario de Desarrollo Requerido
Este valor mide las restricciones de horario impuestas al equipo de proyecto que desarrolla el software. Los
valores se definen en trminos de porcentaje de aceleracin alargamiento sobre el calendario respecto de un
calendario nominal para un proyecto que requiere una cantidad de esfuerzo dada. Los calendarios acelerados
tienden a producir ms esfuerzo en las fases ms tardas de desarrollo porque se dejan por solucionar ms
problemas debido a la falta de tiempo para resolverlos ms pronto. Una compresin del calendario del 74%
se evala como Muy Bajo. Un alargamiento del calendario produce ms esfuerzo en las fases ms tempranas
Pg. 99 .
del desarrollo, donde hay ms tiempo para planificar, hacer especificaciones y validar minuciosamente. Un
alargamiento del 160% se valora como Muy Alto (tabla 7.39).
SCED
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
75% del
85%
100%
130%
160%
Extra Alto
nominal
La tabla 7.40 muestra un resumen de los valores correspondientes a los drivers de coste estudiados para el
modelo Post-Arquitectura. La tabla 7.41 muestra el valor de los multiplicadores para los drivers
correspondientes.
Pg. 100 .
RELY
DATA
Bajo
Nominal
Alto
Muy Alto
Bajo, prdidas
fcilmente
recuperables
DB bytes/
Pgm SLOC < 10
Moderado, prdidas
recuperables
Alta prdida financiera
Riesgo de vidas
humanas
10 D/P < 100
100 D/P < 1000
D/P 1000
CPLX
Extra Alto
Ver Tabla 7.24.
RUSE
Nada
A lo largo del proyecto
A lo largo del
programa
A lo largo de la lnea
de producto
DOCU
Algunas
necesidades del
ciclo de vida sin
cubrir
Necesidades correctas
al ciclo de vida
Excesivas necesidades
para el ciclo de vida
Necesidades muy
elevadas para el ciclo
de vida
70%
85%
95%
70%
85%
95%
TIME
STOR
PVOL
ACAP
50% del uso de

tiempo de ejecucin
disponible
50% del uso del
almacenamiento
disponible
Mayor cambio cada Mayor: 6 meses
Menor: 2 semanas
12 meses
Menor cambio cada
mes
35 percentil
55 percentil
Mayor: 2 meses
Menor: 1 semana
Mayor: 2 semanas
Menor: 2 das
75 percentil
90 percentil
PCAP
35 percentil
55 percentil
75 percentil
90 percentil
PCON
24% /ao
12% /ao
6% /ao
3% /ao
AEXP
6 meses
1 ao
3 aos
6 aos
PEXP
6 meses
1 ao
3 aos
6 aos
LTEX
6 meses
1 ao
3 aos
6 aos
TOOL
Simple, frontend,
backend CASE,
integracin
pequea
Herramientas de ciclo
de vida bsicas
moderadamente
integradas
Fuerte, herramientas
de ciclo de vida
maduras, moderadamente integrada
SITE:
Localizacin
Multi-ciudad y
Multi-compaa
Multi-ciudad o Multicompaa
Misma ciudad rea

metrop.
Fuerte, maduro,
herramientas de ciclo
de vida proactivas,
bien integrado con los
procesos, mtodos,
reutilizacin
Mismo edificio
complejo
SITE:
Comunicaciones
Telfono
individual, FAX
Banda estrecha, mail
Comunicacin
electrnica de banda
ancha
85%
100%
130%
SCED
A lo largo de
las lneas de
producto
mltiples
Comunicacin
electrnica de banda
ancha, video
conferencia ocasional
160%
Completament
e localizado
Multimedia
interactiva
Tabla 7.40. Resumen del nivel de medida de los drivers de coste Post-Arquitectura
Pg. 101 .
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
RELY
0.82
0.92
1.00
1.10
1.26
--
DATA
--
0.90
1.00
1.14
1.28
--
CPLX
0.73
0.87
1.00
1.17
1.34
1.74
RUSE
--
0.95
1.00
1.07
1.15
1.24
DOCU
0.81
0.91
1.00
1.11
1.23
--
TIME
--
1.00
1.11
1.29
1.63
STOR
--
--
1.00
1.05
1.17
1.46
PVOL
--
0.87
1.00
1.15
1.30
--
ACAP
1.42
1.19
1.00
0.85
0.71
--
PCAP
1.34
1.15
1.00
0.88
0.76
--
PCON
1.29
1.12
1.00
0.90
0.81
--
AEXP
1.22
1.10
1.00
0.88
0.81
--
PEXP
1.19
1.09
1.00
0.91
0.85
--
LTEX
1.20
1.09
1.00
0.91
0.84
--
TOOL
1.17
1.09
1.00
0.90
0.78
--
SITE
1.22
1.09
1.00
0.93
0.86
0.80
SCED
1.43
1.14
1.00
1.00
1.00
--
Tabla 7.41. Multiplicadores de esfuerzo actualizados para el modelo Post-Arquitectura

pertenecientes a la versin USC-COCOMOII.1999.0
Por ejemplo, si al analizar los drivers de coste para nuestro proyecto obtenemos los siguientes resultados:
Pg. 102 .
E MB
RELY
MA
EA EB=Extra Bajo
MB=Muy Bajo
DATA
B=Bajo
N=Nominal
A=Alto
CPLX
RUSE
DOCU
TIME
STOR
PVOL
ACAP
PCAP
PCON
AEXP
PEXP
LTEX
TOOL
SITE
SCED
17
MA=Muy Alto
Aplicando los valores de la tabla 7.41 obtendremos:
EMi = 1x 1.14 x 1 x 1 x 1 x 1.05x 1 X 1.19 x 1 x 1 x 1 x 1 x 0.91 x 0.90 x 1.09 x 0.93 x 1 = 1.085

i=1
Nota: En los drivers de coste como por ejemplo CPLX o SITE se evalan varias caractersticas, en este
ltimo caso Comunicaciones y Localizacin (ver tabla 7.38). El resultado Alto se ha obtenido de hacer la
media subjetiva entre Comunicaciones = Alto y Localizacin = Muy Alto. Esta media es Alto porque como
hemos visto anteriormente siempre que una evaluacin de un driver de coste est entre dos niveles de ratio,
hay que redondear al nivel nominal. Si la evaluacin hubiese estado entre Extra Bajo y Bajo la media
subjetiva hubiese sido Muy Bajo.
7.4.5. VALORES DE TIEMPO DE DESARROLLO.

La versin inicial de COCOMO II proporciona una capacidad de estimacin de tiempo simplemente similar a
las de COCOMO. La ecuacin siguiente es la ecuacin inicial de tiempos base para las tres etapas de
COCOMO II es:
Pg. 103 .
TDEV
[3.67
(0 28+0 2X(B 1 01))
SCED%
PM
100
Donde TDEV es el tiempo en meses desde la determinacin de una lnea base de requisitos del producto
hasta que se completa una actividad de aceptacin que certifica que el producto satisface los requisitos. PM,
es la estimacin de meses-persona, excluyendo el estimador de esfuerzo SCED, B, es la suma de los factores
de escala del proyecto y SCED % es el porcentaje de compresin/expansin en el multiplicador de esfuerzo
SCED, (ver tabla 7.39).
A medida que COCOMO II evoluciona tendremos un modelo de estimacin del tiempo ms extenso que
refleja las diferentes clases de modelo de proceso que puede usar un proyecto; los efectos de software COTS
y reutilizable, y los efectos de las capacidades de composicin de las aplicaciones.
Por ejemplo, si tomamos un proyecto en el que hemos obtenido un resultado de 26 MM, B=0.75 y no existen
restricciones de tiempo, al aplicar la ecuacin anterior obtenemos:
TDEV = [3.67 x 26 (0.28+0.2 x (0.75-1.01))]
RANGOS DE SALIDA
Varios usuarios de COCOMO han expresado una preferencia por los rangos de estimacin en lugar de
clculo de puntos como salidas de COCOMO. Las tres etapas del modelo COCOMO II permiten la
estimacin de rangos probables de valores de salida usando distintas relaciones de exactitud de coste y
medida. Una vez que se calcula el valor de esfuerzo ms probable, E, del modelo elegido: Composicin de
Aplicaciones, Diseo anticipado o Post-Arquitectura, se calculan un conjunto de estimaciones optimistas y
pesimistas que representan una desviacin estndar alrededor del valor ms probable, de la siguiente forma:
Pg. 104 .
Estimacin Optimista
Estimacin Pesimista
Composicin de Aplicaciones
0.50E
2.0 E
Diseo Anticipado
0.67 E
1.5 E
Post-Arquitectura
0.80 E
1.25 E
Tabla 7.42. Rango de salida estimado

El rango de valores de esfuerzo puede utilizarse en la ecuacin de tiempo para determinar un rango de
valores de tiempo.
Basndonos en el ejemplo anterior en el que calculamos el tiempo de desarrollo, si queremos estimar los
rangos probables de valores de salida:
MM = [0.80 (26) + 1.25 (26)] y los rangos de TDEV se obtendrn sustituyendo ambos valores en la
ecuacin de tiempo correspondiente.
Veamos un ejemplo aadiendo una restriccin de tiempo:

Supongamos que en un proyecto hemos aplicado la frmula del clculo del tiempo (con SCED=1 por ser la
primera estimacin) y hemos obtenido que el tiempo estimado de duracin del proyecto es de 4 meses. Se
nos ha impuesto una restriccin de tiempo, de forma que debemos ajustarnos a 3 meses que es el tiempo
mximo que tenemos. Esto representa un 25% menos de tiempo del que obtenemos en la primera estimacin,
es decir un 75% del nominal, lo que se corresponde con un valor de SCED= Muy Bajo segn la tabla 7.47.
Ahora tenemos que volver a aplicar la frmula del esfuerzo ajustado, modificando el valor de SCED que
sera 1.43. (tabla 7.41) para obtener un nuevo valor del esfuerzo, que ser mayor que el inicial.
Una vez estimado el esfuerzo y la duracin total de un proyecto, se puede calcular el esfuerzo y duracin
distribuido por fases y subfases del proyecto con las tablas del modelo COCOMO 81, el cual supone un
modelo de proceso en cascada (secuencial y progresivo). Si el modelo de proceso no es en cascada, no
pueden aplicarse estas distribuciones de fases.
7.4.6. TRATAMIENTO DE LA REUTILZACIN EN LA ESTIMACIN
En los modelos de Diseo Anticipado y Post-Arquitectura se pueden incluir consideraciones especiales
cuando se prev reutilizacin del cdigo que compondr la aplicacin que estamos estimando.
La inclusin de caractersticas de reutilizacin conlleva describir el parmetro Size como sigue:
100
Size
= KSLOC + KASLOC
100
X (AAM)
Pg. 105 .
Dnde la variable KSLOC ha sido explicada anteriormente, y representa el nmero de lneas de cdigo a
desarrollar desde cero; la variable KASLOC representa miles de lneas de cdigo fuente adaptadas; el valor
AT representa el porcentaje de traduccin automatizada y por ltimo la variable AAM representa un
Multiplicador de Ajuste para la Adaptacin:
ASLOC [ AA+AAF(1+0.02(SU)(UNFM))]
AAM [ESLOC] =
AAF<=0.5
100
ASLOC [ AA+AAF+(SU)(UNFM)]
AAF>0.5
AAM [ESLOC] =
100
AAF=0.4(DM)+0.3(CM)+0.3(IM)
El tratamiento que hace COCOMO II del software reutilizado utiliza un modelo de estimacin no lineal. Esto
implica que hay que estimar la cantidad de software que se va a adaptar, ASLOC y tres parmetros de grado
de modificacin: El porcentaje de diseo modificado (DM), el porcentaje de cdigo modificado (CM) y el
porcentaje de esfuerzo inicial de integracin requerido para la integracin del software reutilizado (IM).
El clculo de ESLOC se basa en una cantidad intermedia, el Factor de Ajuste de Adaptacin (AAF). Las
cantidades de adaptacin DM, CM, IM se usan para calcular AAF, donde:
DM: Porcentaje de diseo modificado. El porcentaje de diseo de software que es modificado para
adaptarlo a los nuevos objetivos y al entorno. (Esto es necesariamente una cantidad subjetiva).
CM: Porcentaje de cdigo modificado. El porcentaje de cdigo software adaptado que es modificado
para adaptarlo a los nuevos objetivos y al entorno.
IM: Porcentaje de integracin requerida para software modificado. El porcentaje de esfuerzo
requerido para integrar el software adaptado dentro de la totalidad del producto y comprobar el
producto resultante comparado con la cantidad de esfuerzo normal de integracin y pruebas para
software de un tamao similar.
Si no hay DM CM (el componente se usa sin modificaciones) entonces no es necesario SU. Se aplica SU si
el cdigo es modificado.
Pg. 106 .
El incremento de comprensin del software (SU) se obtiene de la tabla 7.43. SU se expresa cuantitativamente
como un porcentaje. Si el software se tasa muy alto en estructura, claridad y descriptividad del mismo, la
comprensin del software y la penalizacin por comprobar el interfaz es del 10%. Si el software se tasa
muy bajo en estos factores, es del 50%. SU se determina tomando el promedio subjetivo de las tres
categoras.
Pg. 107 .

Estimacion

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estimacion

Cargado por

Copyright:

Formatos disponibles

Estimacin de Proyectos Software

ANA M MORENO S.- CAPUCHINO

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

MTODO DE ESTIMACIN COCOMO

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

1.1. Marco de la Gestin de Proyectos.

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Figura 1.1. Relacin de costes Hw/Sw

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

1.2. Tareas Crticas en la Gestin de Proyectos.

1.2.1. Estimacin de Proyectos

1.2.2. Planificacin de Proyectos

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

La estimacin y la planificacin son actividades relacionadas pero difieren en su alcance y propsito. La

Tiempo extra de profesionales no registrado.

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Figura 1.2. Relacin entre las Tareas de Estimacin

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

2.1. Problemtica del Proceso de Estimacin del Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

La rapidez con la que cambia la tecnologa de la informacin y las metodologas de desarrollo de

Un estimador puede no tener mucha experiencia en estimar desarrollos, especialmente de proyectos

Influyen un gran nmero de factores en el esfuerzo y duracin de un desarrollo de software. Estos

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

el producto software que se tiene que desarrollar: QU

Calidad del personal Requisitos de la

Tabla 2.1. Disparadores de coste

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

2.2 Requisitos que debe Cumplir un Buen Estimador

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

2.3. Marco Temporal de la Estimacin de Proyectos

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Figura 2.1. Grado de Informacin sobre un Proyecto

Estimacin de Proyectos Software

Figura 2.2. Exactitud de las Estimaciones

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

3.1. Definicin de Mtrica

3.2. reas de Aplicacin

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software