Metodos Estimación Proyectos SW

Unidad Didctica: Estimacin de Proyectos Software
ESTIMACIN DE PROYECTOS
SOFTWARE
AUTORA: ANA M MORENO S.- CAPUCHINO
Pag. 1
CONTENIDO DE LA UNIDAD DIDCTICA
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
Pag. 2
TEMA 1:
INTRODUCCIN
Pag. 3
Error! Marcador no definido.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,
trafico 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
Pag. 4
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.
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?
Pag. 5
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 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.
Pag. 6
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.
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 ultimas 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
Pag. 7
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.
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
Pag. 8
acumulan solamente como gasto del proyecto, y estn mas 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 son
independientes, discretos y de que se aplican una sla 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
Pag. 9
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.
Pag. 10
TEMA 2:
ESTIMACIN DE SOFTWARE
Pag. 11
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 proyecto 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
Pag. 12
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.
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.
Pag. 13
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.
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
CON QU
significado
Restricciones
del ordenador
- tiempo de
ejecucin
QUIN
personal
CMO
proyecto
Calidad del personal Requisitos de la

duracin del
Experiencia del
proyecto
personal
- dilatacin
PARA QUIN
usuario
Participacin
Nmero de usuarios
Pag. 14
Volatilidad de
requisitos
Complejidad del
software
- 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
- compresin
Calidad de gestin
Disponibilidad para
el proyecto
Estabilidad de la
organizacin del
Bases para el
usuario,
control del proyecto procedimien-tos,
- matriz de
formas de trabajo
organiza-cin
- organiza-cin del Experiencia del
proyecto
usuario con la
- prototipado
informtica, nivel de
- incremental
conocimientos
- desarrollo lineal
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
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,...
Pag. 15
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:
Pag. 16
1.
Debe poseer una importante formacin y experiencia profesional que le ayuden a entender y
solucionar los problemas de la gestin de proyectos.
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.
Pag. 17
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.
Informacin
100
Concepcin
Instalacin
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
Pag. 18
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.
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.
Pag. 19
Exactitud
4x
tipos de personas
y datos
2x
tipo de consultas
carga de datos, tpo. de respuesta
1.5x
esttructuras de datos internas

algoritmos detallados
1.25x
entendimeitno de
especificaciones
x
0.8x
0.67x
0.5x
Especificacin
requisitos
Iniciacin
0.25x
Especificacin
de diseo
Especificacin
de diseo detallado
Software
aceptado
Fasess del
Software
Viabilidad
Planificacin
y requisitos
Diseo
producto
Diseo
detallado
Desarrollo y
pruebas
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
Pag. 20
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.
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?
Pag. 21
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.
Pag. 22
TEMA 3:
MTRICAS DE SOFTWARE
Pag. 23
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. Areas de Aplicacin

Para qu podemos utilizar las mtricas?
Pag. 24
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.
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 este 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 otro 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 otro 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 una rea de aplicacin
muy importante. CSC-Index en Europa y el Software Engineering Institute en EE.UU. ofrecen este tipo
Pag. 25
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? que 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 deberan 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:
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.
Pag. 26
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.
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
Pag. 27
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 ese
rea no sirve.
A continuacin, vamos a analizar las medidas ms utilizadas en la determinacin del tamao del software.
Pag. 28
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 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:
Pag. 29
a) No se tiene en cuenta el concepto de reutilizacin.

b) No se tiene en cuenta el concepto de costes fijos ni
producen instrucciones.
tareas que se desarrollan que no
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.
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
Pag. 30
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
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
Pag. 31
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 este 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.
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.
Pag. 32
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.
Pag. 33
TEMA 4:
TCNICAS DE ESTIMACIN
Pag. 34
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.
Pag. 35
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.
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.
Pag. 36
La validez de las mtricas de software y de los modelos de estimacin debe ser establecida demostrando
la coincidencia entre los datos empricos y los experimentales. Esto requiere una cuidadosa atencin en la
toma de medidas y en el anlisis de los datos.
En general, el anlisis y la validacin de las mtricas y los modelos de estimacin requiere una slida base
estadstica y diseo de experimentos. Para obtener resultados significativos son necesarios una definicin
precisa de las mtricas involucradas y de los procedimientos para la captura de datos.
Los 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.
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 calculo 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 = aL b, 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:
0,9l
E = 5,2 L
Pag. 37
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.
Pag. 38
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 mas 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
Pag. 39
Tausworthe, de Jet Propulsion Laboratory, intent desarrollar una estimacin de coste del software
utilizando elementos de los modelos de mas 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).
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 mas 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
calculo de esfuerzo es:
E = a + bS + cP
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.
Pag. 40
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.
Pag. 41
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 asginatura.
Pag. 42
TEMA 5:
MTODO DE ESTIMACIN DE
PUNTOS DE FUNCIN
Pag. 43
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.
Pag. 44
La aplicacin de la tcnica de los Puntos de Funcin comprende los siguientes pasos:

Definicin de los limites del sistema.
Definicin de parmetros.
Valoracin de la complejidad.
Anlisis de las caractersticas generales del sistema.
5.2. Definicin de los Limites del Sistema

El limite es utilizado para definir el alcance del sistema y ayudar a identificar los parmetros externos.
Existen tres visiones de los limites del sistema, dependiendo de la utilizacin que quiera realizarse de la
tcnica:
1 La aplicacin o limite 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 Limite 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 Limite 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:
Pag. 45
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.
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.
La definicin que vamos a considerar aqu es la realizada por IFPUG en 1994, ltima versin.
Pag. 46
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 limites 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.
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
Pag. 47
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 requsitos 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.
Consultas externas (EQ): Combinacin de una entrada (pregunta) y de una salida (respuesta).
Vamos a comentar brevemente cada una de ellas.
Pag. 48
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 limites.
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 Els de la
aplicacin.
Ejemplos de este tipo de funcin son:
Pag. 49
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 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
Pag. 50
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:
Pag. 51
Regla 1
Regla 2
Regla 3
Regla 4
Regla 5
El proceso enva datos o informacion 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
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
distinto 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.
Pag. 52
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:

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
Pag. 53
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 apliacin que est siendo coantada en un
estado consistente
El proceso no actualiza ILFs
- La lgica de proceso sobre la entrada y la salida es nia 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:

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.
Pag. 54
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 debera contarse
como un sistema distinto.
No se consideran como Consultas:
Los mensajes de Error/Confirmacin.
La utilizacin de distintos mtodos de llamada a la mismaconsulta.
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 mas importante es documentar la regla y aplicarla consistentemente.
Pag. 55
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 de el 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.
Valoracion 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 mendiante 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 implementain 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 ala
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
Pag. 56
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 :
Regla 1
Regla 2
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
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
Baja
Media
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 El identificaa 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
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 introducio porel usuario, pero que
Pag. 57
Regla 3
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 identificacn de FTRs para entradas externas

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 oEIF leido durante el proceso de una El
Contar un nico FTR por cada ILF que sea tanto mantenido como leido 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
Media
Alta
Alta
Alta
FTR
0a1
2
3 o ms
Valoracin de la complejidad de las salidas externas
Pag. 58
A cada EO identificada, asignarle una complejidad funcional basada en el nmero de tipos fichero
referenciados (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 idenfitifacin 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 fisica como un nico DET para
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

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 :
Regla 1
Contar un FTR por cada ILF o EIF ledo durante el proceso de una EO
DET
1a4
5 a 19
20 o ms
Baja
Baja
Baja
Media
Media
Alta
FTR
0a1
2a3
Pag. 59
4 o ms
Media
Alta
Alta
Valoracin de la complejidad de las conjultas 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 componenete 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 identifiacin 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 esta 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
Contar las siguientes tcnicas de implementacin fsica como un nico DET para
Contar las siguientes tcnicas de implentacin fsica como un nico DET para el
grupo completo de campos :
3.1 Campos que indican un error ocurrido durante el proceso del DET de
entrada, o confirmacion 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
Regla 4
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,
idenficacin 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 de
fecha y hora
Contar las siguientes tcnicas de implementacin fisica como un nico DET para
4.1 Un campo lgico que se almacena fisicamente en multiples 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
Pag. 60
tecnologa o tcnicas de implementacin

Reglas de identificacion de FTRs para consultas externas
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
Media
Alta
Alta
Alta
1a4
5 a 19
20 o ms
Baja
Baja
Baja
Media
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:

Parmetro
Complejidad X
Peso
Entrada
Alta
Media
Baja
X
X
X
Total
6
4
3
=
=
=
Pag. 61
Salida
Alta
Media
Baja
X
X
X
7
5
4
=
=
=
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.
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.
Pag. 62
12.
13.
14.
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
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:
Pag. 63
La aplicacin es por lotes o utilizando un ordenador personal
La aplicacin es por lotes pero existe una entrada de datos o impresin remotas
2
3
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
limite de la aplicacin.
Los valores son los mostrados en la Tabla 5.2.
0
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.
2
3
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.
4
5
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
No existen requisitos especficos de rendimiento.

Rendimiento y requisitos de diseo han sido definidos y revisados pero no requieren ninguna
Pag. 64
accin especial.
2
El tiempo de respuesta o la capacidad de proceso es critico 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 critico 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
No existen restricciones de ningn tipo.

Existen restricciones operativas, pero no requieren
un esfuerzo especial para conseguirlas.
Existen algunas restricciones de seguridad o tiempo.
3
4
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
5.5.5. Frecuencia de transacciones

La frecuencia de transacciones es alta e influye sobre el diseo, desarrollo, instalacin y soporte de la
aplicacin.
Pag. 65
Los valores a asignar son los de la Tabla 5.5.

0
No existe una definicin del periodo punta de transacciones.
1
2
Se conoce el periodo punta (mensual, trimestral, estacional, anual).

Se conoce el periodo semanal.
3
4
Se conoce el periodo punta diario.

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.
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
Todas las transacciones se procesan por lotes.
1
2
1% al 7% de las transacciones son interactivas.

3
4

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.
Pag. 66
Scrolling.
Teclas de funcin preasignadas.

Submisin 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).
Impresin remota.
Soporte multi-lengua (Contar como 6 funciones).
Los valores son los de la tabla 5.7.
Nada de lo anterior.
1
2
1-3 de las funciones anteriores.

4-5 de las funciones anteriores.
3
4
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
Ninguno.
Actualizacin on-line de 1 a 3 ficheros. El volumen de actualizacin es bajo y la recuperacin
Pag. 67
fcil.
2
3
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

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
Nada de lo anterior.
Uno de los anteriores.
2
3
Dos de los anteriores.

Tres de los anteriores.
Cuatro de los anteriores.
Todos los anteriores.

Tabla 5.9. Procesos Complejos
5.5.10. Reutilizacin
Pag. 68
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
No reusable.
Se utiliza cdigo reusable dentro de la aplicacin.
Menos del 10% de la aplicacin tiene en cuenta las necesidades de mas de un usuario.
3
4
El 10% ms de la aplicacin tiene en cuenta las necesidades de mas 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
Pag. 69
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.
0
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 probados.
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.
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
No se definieron por parte del usuario necesidades especiales de operacin o respaldo de

distintas de las normales.
1-4
Seleccionar, valorando como uno, cada una de las siguientes solicitudes realizadas a la
aplicacin:
Procesos eficaces de arranque, respaldo y recuperacin pero con
Pag. 70
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 mas 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

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.
Pag. 71
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.
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
= puntos funcin/persona-mes
Calidad
= errores/punto funcin
Pag. 72
Coste
= pesetas/punto funcin
Documentacin
= pginas/punto funcin
Lneas de Cdigo
= 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.
Pag. 73
TEMA 6:
MTODO DE ESTIMACIN
COCOMO
Pag. 74
6.1. Aplicacion del Modelo COCOMO

Este modelo se aplica a los desarrollos que siguen el ciclo de vida en cascada (en nueve etapas), y
corresponde a las siguientes fases:
Planificacin y Definicin de Requisitos.

Diseo de Producto.
Diseo detallado.
Codificacin y pruebas unitarias.
Integracin y Pruebas.
Implantacin.
Explotacin y Mantenimiento.
Incorpora dentro del proceso:
Verificacin y Validacin.
Gestin de Configuracin.
Existen tres modos de desarrollo de software segn COCOMO: orgnico, semilibre y rgido, segn las
caractersticas de la aplicacin y del entorno de desarrollo. A cada uno de estos modelos se le puede
aplicar tres mtodos de estimacin distintos : bsico, intermedio y detallado.
Cuando un ingeniero de software est ante un proyecto a estimar, lo primero que debe hacer para aplicar
el COCOMO es situar su proyecto en el espacio de dos dimensiones (modo, modelo) de la Figura 6.1.
En la Figura 6.1, Px es un proyecto que va a ser desarrollado segn un modelo Semilibre, dado e tipo de
aplicacin y el equipo del que se dispone, y se va estimar segn COCOMO Detallado, dada la exactitud
que se requiere de la estimacin.
Pag. 75
modos de desarrollo
del software
Rgido
Px
Semirgido
Orgnico
modelos de
aplicacin
Bsico
Intermedio
Detallado
Figura 6.1. Espacio para situar un proyecto

a estimar por COCOMO
6.2. Modos de Desarrollo de Software

Este modelo considera tres modos distintos de desarrollo de software:
6.2.1. Modo Orgnico
Este modo se caracteriza por lo siguiente:
El proyecto se desarrolla en equipos relativamente pequeos en un entorno familiar, en la propia

empresa.
Muchas personas relacionadas con el proyecto tienen amplia experiencia trabajando en sistemas
similares dentro de la propia organizacin y tienen un buen conocimiento de cmo el sistema que
se est desarrollando contribuir a los objetivos de la Organizacin.
Esto significa que muchas personas podrn contribuir al proyecto desde las primeras etapas, sin
generar una sobrecarga de comunicacin importante.
Pag. 76
El proyecto se desarrolla en un entorno relativamente relajado en cuanto a exigencia por parte

de los usuarios para que el software cumpla las especificaciones y pueda ser desarrollado ms
fcilmente. Esta es otra razn para una mayor productividad.
Se desarrolla en un entorno generalmente estable, con muy pequea probabilidad de

coincidencia en el desarrollo de un nuevo hardware u operaciones desconocidas.
Mnima motivacin para terminar el proyecto antes de lo previsto.
Proyectos de tamao relativamente pequeo. Como mximo 50 KDSI (miles de instrucciones).
6.2.2. Modo Semilibre

Este modelo se caracteriza por lo siguiente:
El equipo del proyecto tiene un nivel medio de experiencia en proyectos similares.
El equipo es una combinacin de personal experto e inexperto.
Algunos miembros del proyecto tienen alguna experiencia en aspectos del proyecto y otros no.
El tipo de proyectos representativo podra ser un sistema de proceso de transacciones con

interfases muy poco rigurosas en algunos casos y muy rgidas en otros.
El tamao del producto llega a las 300 KDSI.
6.2.3. Modo Rgido

Los elementos caractersticos de este modo de desarrollo son:
Proyectos que deben desarrollarse dentro de unas limitaciones muy estrictas.
El producto debe explotarse dentro de un entorno muy acoplado de hardware, software,

normativa y procedimientos operativos, tales como sistemas de transferencia electrnica de
fondos o control de trafico areo.
Pag. 77
Los costes de cambiar algo en este complejo entramado son tan altos, que sus caractersticas se
consideran inmodificables, asi que el software debe realizarse estrictamente conforme a las
especificaciones.
Como resultado, estos proyectos no admiten negociar cambios en el software modificando los
requisitos e interfases del usuario, por lo que el esfuerzo en verificaciones y validacin asi como
la gestin de configuraciones, es muy alto.
Estos proyectos se desarrollan en reas generalmente desconocidas, lo cual lleva inicialmente a

equipos pequeos de analistas y a una sobrecarga de comunicacin importante durante el
desarrollo.
Una vez que el proyecto ha terminado la fase de diseo, la mejor estrategia para continuar el
desarrollo es constituir un equipo grande de programacin para realizar el diseo detallado,
codificacin y pruebas en paralelo. Esta estrategia conduce a puntas en cuanto a personal y a
un mayor consumo de esfuerzo mayor que en los restantes niveles.
Se aplica a proyectos de cualquier tamao.
6.3. Modelos COCOMO

Pueden aplicarse a los tres modos de desarrollo de proyectos y son:
6.3.1. Modelo Bsico
Se suele aplicar en los desarrollos de productos pequeos/medios, desarrollados por personal de la propia
empresa en modo orgnico. Aunque tambin puede aplicarse al resto de los modos.
Las ecuaciones de estimacin de esfuerzo y tiempo de desarrollo para cada modo de desarrollo:
Orgnico:
Semilibre:
MM
1,05
= 2,4 (KDSI)
0,38
TDEV = 2,5 (MM)
MM = 3,0 (KDSI)
1,12
Pag. 78
TDEV = 2,5 (MM) 0,35

Rgido:
1,20
MM = 3,6 (KDSI)
TDEV = 2,5 (MM)0,32
Donde,
KDSI significa nmero de instrucciones de cdigo en miles.
MM significa esfuerzo medido en Meses/Hombre.
TDEV significa duracin en Meses.
Ejemplo:
Supongamos que queremos desarrollar un programa que se ha estimado tendr 32.000
instrucciones; y en base a las caractersticas de la aplicacin decidimos tratarlo en el modo
orgnico.
Cules sern el esfuerzo, tiempo y recursos requeridos para desarrollar dicha aplicacin?
Esfuerzo: MM = 2,4 (32)1,05 = 91 Meses/Hombre
0,38
Tiempo:
TDEV = 2,5(91) = 14 Meses
NMedio de Empleados: 91 / 14 = 6,5 Personas
La mayor limitacin del modelo bsico es que no incorpora el efecto de los factores, como la experiencia
de los recursos por ejemplo; que influyen sobre el coste ni el mantenimiento del producto.
6.3.2. Modelo Intermedio

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

RELY : Fiabilidad requerida del software.
Podemos definir la fiabilidad como la probabilidad de que el software realice sus funciones
satisfactoriamente en su prxima ejecucin durante un periodo dado de tiempo. La influencia se
clasifica en: Muy Alto, Alto, Nominal, Bajo y Muy Bajo, en funcin del efecto que tenga un fallo
del producto. Un rango Muy bajo, se usa cuando el defecto tenga que ser eliminado por los
desarrolladores pero sin ninguna otra consecuencia; cuando haya posibles prdidas de vidas
humanas indicaremos un rango Muy Alto.
DATA : Tamao de la base de datos.
Seala el tamao y complejidad de la base de datos. Se expresa mediante la proporcin:
Tamao de la base de datos en caracteres
Data =
Tamao del programa en DSI
Este parmetro puede tomar los valores Bajo, Nominal, Alto y Muy alto, en funcin de cuatro
segmentos determinados por los ratios: 10-100-1000.
CPLX : Complejidad del Producto.

Mide la complejidad en funcin de las funciones de control, clculos, gestin de datos y
operaciones dependientes de dispositivos.
El rango de este parmetro puede variar desde Muy bajo si el mdulo utiliza expresiones
matemticas simples a Extra Alto si se emplean varios mdulos con ejecucin dinmica.
6.3.2.2. Atributos del Ordenador

TIME : Limitaciones en el Tiempo de Ejecucin.
Pag. 80
Se refiere a las limitaciones de uso de maquina del producto considerado. Se expresa en

trminos del porcentaje de tiempo de ejecucin disponible que se espera sea usado por el
sistema o subsistema. Es Nominal cuando se usa menos del 50% del tiempo y Extra alto cuando
se consume el 95%.
STOR : Limitaciones de Memoria Principal.
Se expresa en trminos de las restricciones de almacenamiento principal.
El rango vara desde Nominal si se espera una restriccin de memoria de menos del 50% hasta
Extra alto si la reduccin es del 95%.
VIRT : Volatilidad de la Maquina Virtual.
Se entiende por maquina virtual el conjunto de hardware y software que el producto utiliza para
realizar su tarea. Durante el desarrollo esta mquina puede sufrir cambios. El rango de su
variabilidad va desde Bajo hasta Muy Alto, en funcin de estos cambios.
TURN : Frecuencia de cambio en el modelo de explotacin del ordenador.
Seala el nivel del tiempo de respuesta experimentado por el equipo que desarrolla el proyecto.
Se define por el tiempo medio de respuesta en horas desde que el desarrollador introduce un
trabajo en el ordenador hasta que obtiene los resultados del proceso.
Estos factores han perdido parte de su importancia en los entornos actuales de desarrollo y
explotacin ya que estas limitaciones se producen slo en el desarrollo de productos en que no
es posible utilizar herramientas de productividad o desarrollos en entornos batch.
El rango vara desde Bajo para un sistema interactivo hasta Muy Alto cuando el tiempo de
respuesta es mayor de 12 horas.
6.3.2.3. Atributos de Personal

ACAP : Capacitacin de los Analistas.
Expresa en trminos de percentiles con relacin al conjunto de analistas los siguientes atributos:
. Habilidad para el anlisis.
. Eficiencia y calidad en el trabajo.
. Habilidad para comunicarse y cooperar.
Pag. 81
Se evala su eficiencia trabajando en equipo. Cuanto ms capaz sea el equipo de analistas,

menor ser el esfuerzo necesario. El rango de este parmetro puede variar entre Muy Bajo y
Muy Alto.
AEXP : Experiencia en Aplicaciones.
Indica el nivel de experiencia en aplicaciones del equipo de desarrollo de proyectos.
El rango vara desde Muy Bajo (menos de cuatro meses de experiencia) y Muy Alto (ms de 12
aos).
PCAP : Capacitacin de los Programadores.
Expresa similares atributos que el parmetro ACAP pero para los programadores.
VEXP : Experiencia en la Maquina Virtual.
Es el tiempo de experiencia en el entorno Hardware y Software del equipo que desarrolla el
software. No se considera el lenguaje de programacin.
Este parmetro puede tomar los valores desde muy bajo (si la experiencia en la mquina es
menor de un mes) hasta alto (si es mayor de tres aos).
LEXP : Experiencia en el Lenguaje de Programacin.
Un equipo de programadores con amplia experiencia en un lenguaje determinado, programar
de una forma ms segura, disminuyendo incluso el nmero de errores.
El rango de este parmetro puede variar desde Muy Bajo hasta Alto para un equipo con un mes
hasta tres aos de experiencia.
6.3.2.4. Atributos del Proyecto

MODP : Prcticas Modernas de Programacin.
Seala el grado de utilizacin de practicas modernas de programacin entendiendo por tal:
Anlisis de Requisitos y Diseo Top-Down
Diseo Estructurado.
Desarrollo Incremental.
Pag. 82
Revisiones o Inspecciones de Diseo y Cdigo.
Libreras de Programas.
Programacin Estructurada.
Se valorar el grado de utilizacin de estas prcticas desde Muy Bajo hasta Muy Alto.
TOOL : Uso de herramientas para el Desarrollo de Software.
Seala el grado de utilizacin de herramientas en el desarrollo al software.
Se identifican cinco niveles de herramientas:
Herramientas bsicas de microprocesador.
Herramientas bsicas de microcomputador.
Herramientas potentes de microcomputador.

Herramientas potentes de ordenador central.
Herramientas avanzadas.
El rango de este parmetro vara entre Muy Bajo cuando slo se usan herramientas bsicas,
hasta Muy Alto cuando se usan herramientas de propsito especial como CASE (Computer
Aided Software Engineering).
SCED : Limitaciones en la planificacin.
Se define mediante el porcentaje de retraso o aceleracin con respecto a la planificacin
nominal impuesta al equipo de desarrollo.
Cualquier aceleracin (Muy Bajo) o retraso (Muy Alto) requerir mayor esfuerzo.
6.3.2.5. Clculo de la Estimacin con el Modelo Intermedio

Estas 15 variables van a influir sobre la estimacin de esfuerzo calculada. El esfuerzo calculado se ajusta
multiplicndolo por el resultado de multiplicar entre s los valores obtenidos de las tablas de atributos en
funcin de los valores identificados en la definicin del proyecto.
La Tabla 6.1. muestra los multiplicadores de esfuerzos, donde la primera columna muestra las variables y
las restantes el multiplicador a considerar para cada rango de valores desde Muy Bajo hasta Extra Alto.
Pag. 83
VARIABL
E
Muy Bajo
Bajo
RELY
DATA
CPLX
TIME
STOR
VIRT
TURN
ACAP
AEXP
PCAP
VEXP
LEXP
MODP
TOOL
SCED
0.75
0.70
0.88
0.94
0.85
1.46
1.29
1.42
1.21
1.14
1.24
1.24
1.23
0.87
0.87
1.19
1.13
1.17
1.10
1.07
1.10
1.10
1.08
VALORES
Nominal
Alto
Muy Alto
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.15
1.08
1.15
1.11
1.06
1.15
1.07
0.86
0.91
0.86
0.90
0.95
0.91
0.91
1.04
1.40
1.16
1.30
1.30
1.21
1.30
1.15
0.71
0.82
0.70
Extra alto
1.65
1.66
1.56
0.82
0.83
1.10
Tabla 6.1. Multiplicadores de esfuerzo

La estimacin de esfuerzo aplicando este modelo es:
1,05
Modo Orgnico:
Modo Semilibre:
MM= 3.2. (KDSI)

MM = 3.0 (KDSI) 1,12
Modo Rgido:
MM = 2.8 (KDSI)
1,20
El tiempo de desarrollo TDEV se calcula como en el Modelo Bsico.
Ejemplo:
Se negocia con la empresa Compaa de Comunicaciones Megabit el precio para desarrollar un
software complejo de 10 KDSI para un microprocesador comercial.
Pag. 84
El software de comunicaciones genera necesidades de codificacin de complejidad muy alta, pero

planeamos utilizar personal muy capacitado, el cual debera equilibrar la tendencia a incrementar
los costes debidos a la complejidad.
Determinar el esfuerzo y el coste de desarrollo si el precio medio es de 250.000 pesetas
hombre/mes. (Los valores de las variables de ajuste se darn en funcin del campo Situacin de la
tabla que aparece en la solucin.
El esfuerzo lo calcularemos aplicando el Modo Orgnico, puesto que el nmero de lneas de cdigo no
excede las 50 KDSI. As el esfuerzo original ser:
MM = 3,2 X (10)1,05 = 36 MM
Los factores de ajuste los calculamos de la siguiente forma:
Factor
Situacin
Ratio
Multiplic.
RELY
DATA
CPLX
TIME
STOR
VIRT
TURN
ACAP
AEXP
PCAP
VEXP
LEXP
MODP
TOOL
SCED
USO LOCAL
20.000 BYTES
COMUNICACIONES
SE USAR EL 70%
45K/84K
BASADO EN HW
COMERCIAL
DOS HORAS MEDIA
BUENOS ANALISTAS
TRES AOS
BUENOS PROGRAMAD.
SEIS MESES
DOCE MESES
MUCHAS TCNICAS
A NIVEL MICRO
NUEVE MESES
NOMINAL
BAJO
MUY
ALTO
ALTO
ALTO
NOMINAL
NOMINAL
ALTO
NOMINAL
ALTO
BAJO
NOMINAL
ALTO
BAJO
NOMINAL
1.0
0.94
1.30
1.11
1.06
1.0
1.0
0.86
1.0
0.86
1.10
1.0
0.91
1.10
1.0
El factor de ajuste se calcula multiplicando todos los valores de los parmetros. En este caso resulta 1,17.
Pag. 85
El esfuerzo final entonces es el siguientes:

MM final = (36MM)(1,17) = 42.12 MM = 42 MM
El coste de la aplicacin ser:
Pesetas = (42MM) (250.000 pts/MM) = 10.500.000
Para reducir este coste podramos ajustar los valores de los parmetros. Por ejemplo, aumentar la
potencia de los equipos, usar personal ms experimentado, etc.
6.3.3. Modelo Detallado

El Modelo Intermedio tiene dos limitaciones que pueden ser significativas en la estimacin detallada de
coste en grandes proyectos de software:
La distribucin de esfuerzo por fases puede ser inadecuada.
Puede ser muy engorroso utilizarlo en un producto con muchos componentes.
El modelo detallado presenta dos funcionalidades que resuelven las limitaciones de COCOMO
Intermedio:
l. Multiplicadores de esfuerzo por fases:
En el modelo COCOMO Intermedio, la distribucin de esfuerzo por fase se determina nicamente por el
tamao del producto.
En la prctica, factores como la fiabilidad requerida, la experiencia en aplicaciones y desarrollos
interactivos afectan a unas fases ms que a otras.
El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo en cada
fase. Estos multiplicadores determinan el esfuerzo requerido para completar cada fase.
2. Descomposicin jerrquica del producto a tres niveles.
Pag. 86
En el COCOMO Intermedio, los factores de ajuste del coste se calculaban para distintos componentes del
producto. Este proceso puede ser muy tedioso e innecesariamente repetitivo si ciertos componentes son
agrupados en subsistemas con prcticamente el mismo factor de ajuste.
El COCOMO Detallado evita este problema proporcionando una jerarquizaron del producto a tres niveles:
- Nivel mdulo.
- Nivel subsistema.
- Nivel sistema.
El Nivel modulo se describe por el nmero de instrucciones (DSI) producidas y por aquellos
factores que tienden a modificar dicho nivel: Complejidad del mdulo y adaptacin a partir del
software existente y de la capacidad y experiencia de los programadores que desarrollarn el
mdulo en el lenguaje y en la mquina virtual.
El Nivel subsistema queda descrito por los restantes factores (limitaciones en tiempo y
memoria, capacidad de los analistas, herramientas, planificacin etc.) que tienden a variar de un
subsistema a otro, pero que son iguales para todos los mdulos dentro de un subsistema.
El Nivel sistema se define mediante los factores correspondientes al conjunto del proyecto,
como son el esfuerzo nominal y la planificacin de tiempos.
No se desarrolla este modelo dado que su aplicacin queda reservada a grandes proyectos no
muy frecuentes. El desarrollo completo de este modelo puede estudiarse en el libro "Software
Engineering Economics" de B. Boehm, editorial Prentice Hall, 1981.
Pag. 87

Metodos Estimación Proyectos SW

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Metodos Estimación Proyectos SW

Caricato da

Copyright:

Formati disponibili

Unidad Didctica: Estimacin de Proyectos Software

AUTORA: ANA M MORENO S.- CAPUCHINO

Unidad Didctica: Estimacin de Proyectos Software

CONTENIDO DE LA UNIDAD DIDCTICA

MTODO DE ESTIMACIN COCOMO

Unidad Didctica: Estimacin de Proyectos Software

Unidad Didctica: Estimacin de Proyectos Software

Error! Marcador no definido.1.1. Marco de la Gestin de Proyectos.

Unidad Didctica: Estimacin de Proyectos Software

Figura 1.1. Relacin de costes Hw/Sw

Unidad Didctica: Estimacin de Proyectos Software

1.2. Tareas Crticas en la Gestin de Proyectos.

Unidad Didctica: Estimacin de Proyectos Software

1.2.1. Estimacin de Proyectos

1.2.2. Planificacin de Proyectos

Unidad Didctica: Estimacin de Proyectos Software

Tiempo extra de profesionales no registrado.

Esfuerzo de los directivos.

Unidad Didctica: Estimacin de Proyectos Software

1.2.4. Relacin entre las Actividades Clave de la Gestin de Proyectos

Unidad Didctica: Estimacin de Proyectos Software

Figura 1.2. Relacin entre las Tareas de Estimacin

Unidad Didctica: Estimacin de Proyectos Software

Unidad Didctica: Estimacin de Proyectos Software

2.1. Problemtica del Proceso de Estimacin del Software

Unidad Didctica: Estimacin de Proyectos Software

La utilidad de una estimacin tambin depender de la etapa de desarrollo en la que nos

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

Unidad Didctica: Estimacin de Proyectos Software

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

Es importante profundizar ms en el tema de los disparadores de coste. Para mostrar su importancia,

Calidad del personal Requisitos de la

Unidad Didctica: Estimacin de Proyectos Software

Tabla 2.1. Disparadores de coste

Unidad Didctica: Estimacin de Proyectos Software

2.2 Requisitos que debe Cumplir un Buen Estimador

Unidad Didctica: Estimacin de Proyectos Software

2.3. Marco Temporal de la Estimacin de Proyectos

Unidad Didctica: Estimacin de Proyectos Software

Figura 2.1. Grado de Informacin sobre un Proyecto

Unidad Didctica: Estimacin de Proyectos Software

Unidad Didctica: Estimacin de Proyectos Software

esttructuras de datos internas

Figura 2.2. Exactitud de las Estimaciones

Unidad Didctica: Estimacin de Proyectos Software

2.4. Salidas del Proceso de Estimacin

Unidad Didctica: Estimacin de Proyectos Software

Cunta documentacin ser generada?

Unidad Didctica: Estimacin de Proyectos Software

Unidad Didctica: Estimacin de Proyectos Software

3.1. Definicin de Mtrica

3.2. Areas de Aplicacin

Unidad Didctica: Estimacin de Proyectos Software

Unidad Didctica: Estimacin de Proyectos Software

3.4. Clasificacin de las Mtricas del Software

Unidad Didctica: Estimacin de Proyectos Software

Unidad Didctica: Estimacin de Proyectos Software

3.5. Mtricas de Productos

Unidad Didctica: Estimacin de Proyectos Software

a) Lneas de Cdigo: La medida ms utilizada de la longitud del cdigo fuente de un programa es el

Unidad Didctica: Estimacin de Proyectos Software

a) No se tiene en cuenta el concepto de reutilizacin.

tareas que se desarrollan que no