TICB2 - Tecnicas de Estimacion de Esfuerzo

www.haztefuncionario.com Material registrado. Prohibida su reproduccin.
Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968
B2G1T04 - TCNICAS DE ESTIMACIN DE ESFUERZO DE DESARROLLO.
1. INTRODUCCIN A LAS TCNICAS DE ESTIMACIN DE ESFUERZO DE DESARROLLO ......................... 2

1.1. PROBLEMTICA DEL PROCESO DE ESTIMACIN DE ESFUERZO DE DESARROLLO ................................ 3
1.2. MARCO TEMPORAL DE LA ESTIMACIN DE ESFUERZO................................................................................. 6
1.2. SALIDAS DEL PROCESO DE ESTIMACIN........................................................................................................... 8
1.3. TCNICAS DE ESTIMACIN ................................................................................................................................... 8
1.4. REQUISITOS DE UN BUEN MTODO DE ESTIMACIN ..................................................................................... 8
1.5. MTODOS DE ESTIMACIN ................................................................................................................................... 8
2. OBJETIVOS DE LA ESTIMACIN ............................................................................................................................... 8
3. MTODO DE LA SUMA DE LAS TAREAS.................................................................................................................. 8
4. REGLA 3 VECES PROGRAMACIN ....................................................................................................................... 8
5. MODELO DE LNEAS DE CDIGO ............................................................................................................................. 8
6. MODELO DE PUNTOS FUNCIONALES ...................................................................................................................... 8
6.1. DEFINICIN DE LOS LMITES DEL SISTEMA ...................................................................................................... 8
6.2. DEFINICIN DE PARMETROS.............................................................................................................................. 8
6.3. TIPOS DE FUNCIN DE DATOS .............................................................................................................................. 8
6.3.1 FICHEROS LGICOS INTERNOS...................................................................................................................... 8
6.3.2 FICHEROS INTERFASE EXTERNOS ................................................................................................................. 8
6.4 TIPOS DE FUNCIN TRANSACCIN..................................................................................................................... 8
6.4.1 ENTRADAS EXTERNAS....................................................................................................................................... 8
6.4.2 SALIDAS EXTERNAS........................................................................................................................................... 8
6.4.3 CONSULTAS EXTERNAS .................................................................................................................................... 8
6.5 VALORACIN DE LA COMPLEJIDAD ................................................................................................................... 8
6.6. ANLISIS DE LAS CARACTERSTICAS GENERALES DEL SISTEMA .............................................................. 8
6.7. CLCULO DEL FACTOR DE COMPLEJIDAD TOTAL. ........................................................................................ 8
7. MODELO DE CICLO DE VIDA...................................................................................................................................... 8
8. MODELO COCOMO 81 ................................................................................................................................................... 8
8.1 MODELO COCOMO BSICO ................................................................................................................................... 8
8.2. MODELO COCOMO INTERMEDIO ......................................................................................................................... 8
8.2. MODELO COCOMO AVANZADO ........................................................................................................................... 8
9. MODELO COCOMO II .................................................................................................................................................... 8
9.1. LOS PUNTOS OBJETO COMO MEDIDA DEL TAMAO FUNCIONAL ............................................................. 8
9.2. PASO 1: CONTABILIZACIN DE OBJETOS. ......................................................................................................... 8
9.3. PASO 2: CLASIFICACIN DE LOS OBJETOS........................................................................................................ 8
9.4. PASO 3: ASIGNACIN DE PESOS A LOS OBJETOS DEL SISTEMA.................................................................. 8
9.5. PASO 4: CLCULO DEL NMERO TOTAL DE PUNTOS OBJETO SIN AJUSTAR........................................... 8
9.6. PASO 5: CLCULO DEL NMERO TOTAL DE PUNTOS OBJETO AJUSTADOS............................................. 8
10. CONCLUSIN ............................................................................................................................................................... 8
11. BIBLIOGRAFA ............................................................................................................................................................ 8
12. ESQUEMA RESUMEN .............................................................................................................................................. 8
TEMARIO-TICB-feb04 B2G1T04
Actualizado en febrero de 2004 Pgina 1 de 43
1. INTRODUCCIN A LAS TCNICAS DE ESTIMACIN DE ESFUERZO DE

DESARROLLO
Durante muchos aos el proceso de gestin 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 FIG-1, conforme los costes del hardware disminuyen, el coste de producir el software
tiene un mayor peso dentro del coste del proyecto.
Conforme los costes de desarrollo y mantenimiento del software crecen es necesario predecirlos y controlarlos.
Esto es algo que hasta el momento los constructores de software han encontrado muy difcil de realizar. Otro
problema existente es que no es siempre posible evitar errores en los sistemas complejos, lo cual puede producir
costes elevados, y perdidas fatales. El software controla actualmente sistemas mdicos, trfico areo, sistemas
financieros o sistemas de misiles. Los errores en estos sistemas pueden implicar serios desastres. Segn ha
crecido la experiencia en la construccin de los sistemas software, se han elaborado tcnicas para el desarrollo
de las especificaciones y el diseo. Estas disciplinas pueden, en la actualidad, ensearse y aplicarse segn
reglas muy precisas. Sin embargo, se ha puesto de manifiesto que el uso sistemtico de estas tcnicas para la
especificacin y el diseo de software no ha resuelto el problema de la produccin del software. En la industria se
sigue hablando de "crisis del software"; la cantidad de esfuerzo perdido en el desarrollo de software continua en
situacin similar a hace aos y los productos a menudo son entregados con errores significativos que producen
costes y peligros graves. El hecho es que no es suficiente avanzar a travs de las etapas tradicionales del
proceso de construccin de software y esperar un producto satisfactorio al final del mismo. El proceso de
produccin del software tiene que ser gestionado y dirigido de una manera extremadamente rigurosa y
cuantitativa. De este modo se podr verificar que el trabajo correspondiente a cada fase se ha realizado
completamente dentro de los plazos de tiempo y coste establecidos y de acuerdo con estndares especficos de
calidad.
FIG-1. Lnea base de costes
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.1. PROBLEMTICA DEL PROCESO DE ESTIMACIN DE ESFUERZO DE DESARROLLO
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:
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.
Hay muchas personas implicadas en los proyectos que precisan de estimaciones. La alta direccin de la
empresa necesita las estimaciones para tomar decisiones de negocio, sobre la viabilidad del proyecto y
su continuidad a lo largo del desarrollo. La direccin del proyecto necesita las estimaciones para hacer
sugerencias a la alta direccin, para obtener los resultados necesarios para el desarrollo del proyecto, y
para hacer una planificacin detallada y controlar el proyecto. Cada recurso del proyecto tambin necesita
estimaciones para planificar y controlar su propio trabajo.
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.
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.
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.
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,...
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.
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?
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.
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.
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. Aadir personal a un proyecto retrasado no tiene
por qu disminuir el retraso.
El estimador tiende a reducir en algn grado las estimaciones para hacer ms aceptable la oferta.
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 FIG-2.
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
El usuario/organizacin del usuario: PARA QUIN
FIG-2. Disparadores de coste
En la Tabla anterior podemos ver diversos tipos de disparadores, todos ellos influirn en la estimacin que
vayamos 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,...
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 disparador independiente de los dems. Un cambio en el disparador
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.
1.2. MARCO TEMPORAL DE LA ESTIMACIN DE ESFUERZO
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 FIG-3.
La estimacin continua nos permite el uso de un nico modelo coherente que pueda capturar y utilizar la
informacin sobre el proyecto a medida que este se conozca.
Ms precisamente, el proceso de estimacin comienza usando unas pocas variables claves para proveer las
"macro-caractersticas" de un proyecto, y evoluciona incorporando informacin de ms bajo nivel para producir las
"micro-caractersticas" del proyecto.
La naturaleza del proceso de estimacin cambia a medida que el programa progresa. Supongamos que
desarrollamos un proyecto con un ciclo de vida tradicional. Al principio, en la concepcin del sistema, slo
necesitamos estimaciones a grosso modo para determinar el tamao del proyecto y estudiar su viabilidad. Es
interesante conocer el esfuerzo total del proyecto, su duracin, riesgos, necesidades de personal, etc. A esta
primera estimacin se le denomina macro-estimacin de un proyecto. Como entrada para esta estimacin se
necesitan algunos parmetros descriptivos y genricos sobre el proyecto.
FIG-3. Grado de refinamiento de la estimacin
Una vez que los requisitos han sido definidos, se necesita una estimacin ms detallada para la siguiente fase,
diseo del producto, con el fin de utilizarla para confeccionar una planificacin para dicha fase. Tambin se
necesita una estimacin a ms alto nivel para el resto del proyecto. En este momento, los parmetros descriptivos
y genricos que se emplean para hacer la primera estimacin se conocen ms exactamente, y tambin se
dispone de informacin adicional sobre los recursos que intervendrn en el desarrollo, como por ejemplo la
experiencia de los desarrolladores.
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 FIG-4 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.
FIG-4. Estimacin de coste de un proyecto
Como puede verse en la FIG-4, cuando comenzamos a estudiar las distintas posibilidades para desarrollar un
nuevo sistema, las estimaciones pueden oscilar en un rango de cuatro veces por arriba o por abajo. Este rango
proviene de la gran incertidumbre que se tiene en este momento sobre la naturaleza real del producto. As, por
ejemplo, no se sabe qu tipo de personas (gestores, consultores, analistas,...) o qu tipos de datos (digitales o
analgicos, numricos o texto,...) soportarn el sistema. Las incgnitas anteriores se conocen cuando finaliza la
fase de viabilidad y se decide un procedimiento de operacin. En este momento, el rango de nuestra estimacin
disminuye en dos en cada direccin. Este rango es razonable porque todava no se tiene informacin sobre los
tipos de consulta que soportar el sistema, las funciones concretas, etc. Estos elementos sern conocidos en el
momento de realizar la especificacin de requisitos, en el que la estimacin software estar en un rango de 1,5 en
cada direccin.
En el momento en que hayamos completado y validado la fase de diseo del producto, tendremos informacin
sobre la estructura de datos interna del producto software, sobre las tcnicas para el manejo de buffers, etc. En
este momento la estimacin software tendr un rango de exactitud del 1,25. Existen todava incgnitas, como los
algoritmos que se usarn para la planificacin de tareas, el manejo de errores o los procedimientos de parada del
sistema. Estas sern conocidas al final de la fase de diseo detallado, pero existir todava una incertidumbre del
10% basada en la exactitud con la que los programadores entiendan las especificaciones que tienen que
codificar.
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.
1.2. SALIDAS DEL PROCESO DE ESTIMACIN
En esta seccin intentaremos dar respuesta a la siguiente pregunta.
Qu es lo que debemos estimar?
Cuando se habl de la definicin de estimacin, se vieron dos preguntas a las que este proceso deba dar
respuesta. Estas preguntas eran:
Cunto costar? Cunto tiempo llevar hacerlo?
Esta informacin constituye la informacin bsica de todo proceso de estimacin. Los distintos mtodos
existentes para realizar este proceso proporcionan informacin adicional para dar respuestas, en funcin del
mtodo, a algunas de las siguientes preguntas:
Cunta gente se necesita?

De qu perfiles?
Cules son los riesgos?
Cmo afectan las restricciones impuestas a las estimaciones?
Cunto esfuerzo se necesita para realizar cada fase del ciclo de vida?
Cmo impacta este proceso en el resto de los proyectos de la empresa?
Cul ser el esfuerzo para mantener este proyecto?
Cul ser el tamao del sistema? (lneas de cdigo)
Cuntos defectos tendr el producto?
Cunta documentacin ser generada?
Cul ser el esfuerzo para confeccionar dicha documentacin?
Se podra crear una lista compuesta por todas estas preguntas, para utilizarla como base para la solucin al
problema de Qu estimar?. As, se observara que existen muchos conceptos en la mente de los estimadores.
Sin embargo, dada la rpida evolucin de los mtodos de desarrollo de sistemas y la creciente diversificacin de
alternativas hardware, es correcto suponer que esta lista aumenta constantemente.
1.3. TCNICAS DE ESTIMACIN
Para la estimacin, existen cuatro tcnicas bsicas y comunes:
La opinin de los expertos; Esta tcnica se basa en la experiencia profesional de los participantes en el
proyecto de estimacin.
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.
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.
Las ecuaciones de estimacin; Son frmulas matemticas que establecen la relacin de algunas medidas
de entrada (que normalmente es la medida del tamao del producto) y determinan el esfuerzo que se
requerir.
La primera tcnica es un tanto informal y es la que se ha llevado a cabo hasta el momento, con no muy buenos
resultados como ya hemos visto, dada la complejidad del propio proceso de estimacin.
Para poder utilizar la segunda tcnica es necesario disponer de una base de datos histrica de proyectos
finalizados con la que poder realizar la comparacin. Adems todos esos proyectos tendrn que haber seguido un
proceso estndar. Es decir, el ciclo de vida utilizado y las actividades han de ser similares. Si no es as, es difcil
hacer comparaciones proyecto-proyecto. Un proyecto puede haber comenzado siguiendo unos pasos totalmente
definidos y formalizados, y otro puede que slo tenga definida formalmente la fase de codificacin y pruebas, el
resto de las fases nadie sabe como se hicieron ni si se hicieron.
Por lo tanto, a menos que los proyectos tengan un esquema de proceso similar, compararlos unos con otros es
como comparar peras con manzanas. Es necesaria una estandarizacin para usar esta tcnica. Otro aspecto a
tener en cuenta es que los datos sobre esos proyectos han de ser fiables. Esto quiere decir que las empresas
correspondientes han de tener un programa formalizado para la toma de medidas sobre sus proyectos.
Actualmente es difcil que las empresas cumplan estos dos requisitos: estandarizacin de procesos y
formalizacin de la recogida de medidas. Hay que tener en cuenta que las empresas deberan haberlos
implantado desde hace algunos aos atrs, y que en estos momentos todava existen muchas empresas que no
siguen una metodologa de desarrollo y que tampoco intentan abordar la cuestin de la confeccin de un histrico
de proyectos.
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.
1.4. 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.
1.5. MTODOS DE ESTIMACIN
Un mtodo de estimacin eficaz permitir ignorar aspectos sin inters y concentrarse en los aspectos esenciales.
Un buen modelo debera poseer capacidades predictivas, mejor que ser meramente descriptivo o explicativo.
La validez de las mtricas de software y de los modelos de estimacin debe ser establecida demostrando la
coincidencia entre los datos empricos y los experimentales. Esto requiere una cuidadosa atencin en la toma de
medidas y en el anlisis de los datos.
En general, el anlisis y la validacin de las mtricas y los modelos de estimacin requieren una slida base
estadstica y diseo de experimentos. Para obtener resultados significativos 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.
2. OBJETIVOS DE LA ESTIMACIN
Los objetivos de la estimacin de proyectos son reducir los costes e incrementar los niveles de servicio y de
calidad.
Midiendo determinados aspectos del proceso de software se puede tener una visin de alto nivel de lo
que suceder durante el desarrollo.
Las mediciones de procesos anteriores permiten realizar predicciones sobre los actuales.
Las mediciones de atributos de proceso en fases iniciales del desarrollo permiten realizar predicciones
sobre fases posteriores.
Las predicciones conducen a la toma de decisiones antes del comienzo del desarrollo, durante el
desarrollo, durante la transicin del producto al cliente y a lo largo de la fase de mantenimiento.
3. MTODO DE LA SUMA DE LAS TAREAS

Normalmente se suele confundir el esfuerzo necesario para desarrollar una tarea (meses/hombre) con el tiempo
necesario para llevar a cabo la misma.
Una tarea que tenga asignado un esfuerzo de 10 das, puede llevarse a cabo en el plazo de 5 semanas,
aplicando un esfuerzo de 2 das a la semana. Tambin nos podemos encontrar con el caso contrario en que una
tarea que necesita el esfuerzo de 10 das se lleve a cabo en una semana, empleando a dos personas a tiempo
completo en su ejecucin.
El esfuerzo aplicado puede verse afectado por interferencias externas. Por ejemplo, teniendo que realizarse un
esfuerzo de una semana - hombre, y asignando una persona a esta tarea durante una semana, puede no finalizar
a causa de las interferencias. Thomsett dice que hay muchas razones para esto y en concreto menciona algunas
como:
Es necesario repetir trabajos o corregir defectos de tareas previas, que se suponan terminadas, para
poder realizar la tarea actual.
Hay que tener en cuenta las vacaciones, fiestas, fiestas locales, puentes, etc. que puedan afectar al
proyecto tanto en los lugares de trabajo como en las zonas de clientes o usuario.
Otros equipos de la empresa pueden realizar consultas al personal del proyecto actual sobre temas
ajenos a ste.
La falta de administrativos puede implicar que los programadores tengan que realizar todos sus papeleos
que deberan haber sido delegados.
Falta de formacin y adiestramiento adecuada en el personal del proyecto.
Falta de reuniones del equipo.
Interrupciones de todo tipo como llamadas telefnicas, etc.
Tiempo de espera en reuniones.
Tiempo que tarda el personal en cambiar de tarea, no se puede esperar que sea instantneo.
Estos factores se pueden llevar entre el 30% y el 50% del esfuerzo realizado. No sera extrao que para una
reunin en otra ciudad, de dos das de duracin, a una persona dedique cuatro das de esfuerzo si no tiene
soporte administrativo y tiene que gestionarse los billetes, las reservas de hotel, etc. Otro ejemplo lo dan los
retrasos a la hora de comenzar una reunin por falta de personas.
Aunque parezca paradjico, por culpa de estos factores, las personas con mayor nivel de experiencia y
responsabilidad en la empresa son los ms afectados. Pues:
Deben ensear y adiestrar al personal del proyecto en temas no previstos

Son consultados por otros proyectos
Se les suele pedir que asistan a reuniones, presentaciones, etc, que en principio no tienen relacin con el
proyecto actual.
A la hora de asignar personas a cada tarea nos encontramos con un grupo de tareas y otro de personas. Los
enfoques actuales relativos a esta asignacin pasan por evaluar de cada empleado y tarea los siguientes
aspectos:
El conativo o KAS (Knowledge, Abilities, Skills), se puede ver como la capacidad tcnica. Es decir:
Los conocimientos para realizar la tarea.
La capacidad de realizarla.
La experiencia sobre la materia.
El cognitivo o MAC (Motivation, Attachment, Confidence), se puede ver como la voluntad de realizar la
tarea. Es decir:
La motivacin de la persona.
El compromiso que asumir.
La seguridad que tiene en si para realizarla.
Da la impresin, de que basndose en esto, Fergus O'Connell compara a un proyecto con un puzzle e indica que
se ha de asignar las piezas (tareas) a las personas. Dice que eres una persona con suerte si encuentras la
persona apropiada a cada pieza. Por persona hace referencia al conjunto de personalidad, habilidades,
experiencia, motivacin, metas personales, puntos fuertes y puntos dbiles que nos hacen como somos. Adems
asocia los aspectos conativos al que la persona pueda realizar la tarea desde el punto de vista tcnico. Los
aspectos cognitivos los asocia a si la persona quiere realizar la tarea.
En principio el asignar muchas personas a una tarea no quiere decir que la tarea forzosamente dure menos
tiempo. Es decir, la gente y la duracin no son intercambiables. Frederick P. Brooks en su libro The mythical
man-month ofrece cuatro tipos posibles de tareas. En cada una de ellas la relacin existente entre meses y
hombres es diferente. Las posibles situaciones son:
1) Las tareas se pueden repartir de forma perfecta, sin necesidad de comunicacin entre las personas.
Cuando ms personas se asignen a una tarea, sta tendr una duracin proporcionalmente menor FIG-5.
9
8
7
6
Duracin
5
4
3
2
1
0
0 1 2 3 4 5 6 7 8
Personas
FIG-5. Tipo de tarea 1
2) La tarea no se puede partir (Para que nazca un nio se requieren nueve meses, no importa cuantas
mujeres se asignen). ste tipo de tareas suelen darse cuando tenemos limitaciones en algn recurso. As
por ejemplo, si para realizar las pruebas me hace falta un dispositivo Hw especial, del que tan solo se
dispone de una unidad, no tendr sentido que asigne muchas personas a esta tarea FIG-6.
9
8
7
6
Duracin
5
4
3
2
1
0
0 1 2 3 4 5 6 7 8
Personas
3) La tarea se puede partir, pero se requiere comunicacin entre las personas. En principio es la situacin
ms habitual dado que de contener subtareas independientes, esto se hubiera tenido en cuenta en la
descomposicin en tareas y tendramos varias tareas bien definidas en el proyecto. Por otra parte es
habitual tener tareas grandes que son crticas requiriendo mucho esfuerzo y que necesitamos que tengan
una duracin limitada FIG-7.
9
8
7
6
Duracin
5
4
3
2
1
0
0 1 2 3 4 5 6 7 8
Pe rsonas
4) La tarea se puede partir pero las interrelaciones son tan complejas que cuesta ms tiempo realizar la tarea
con muchas personas. Son las tareas en que habitualmente alguien dice: mira prefiero hacerlo solo, por
que entre varios no terminaremos nunca FIG-8.
9
8
7
6
Duracin
5
4
3
2
1
0
0 1 2 3 4 5 6 7 8
Pe rsonas
4. REGLA 3 VECES PROGRAMACIN

La regla 3 veces programacin se puede resumir en las siguientes 3 ideas:
Consiste bsicamente en realizar la estimacin del nmero de mdulos de software o programas y su

complejidad.
Estimar el esfuerzo requerido para completar la codificacin y la compilacin de cada mdulo y el
esfuerzo total de la programacin.
Esfuerzo del proyecto total = (Esfuerzo estimado para la programacin) * 3
Incluye administracin, documentacin, diseo, etc.
5. MODELO DE 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:
donde CLOC (Comentary Lines of Code es el nmero de lneas de comentarios).

Una medida indirecta de la densidad de comentarios seria:
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:
No se tiene en cuenta el concepto de reutilizacin.

No se tiene en cuenta el concepto de costes fijos ni tareas que se desarrollan que no producen
instrucciones.
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:
Medir la longitud en trminos de nmero de bytes de almacenamiento requerido para contener el texto del
programa.
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:
6. MODELO DE PUNTOS FUNCIONALES
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:
Entrada (EI, del ingls External Input).

Salida (EO, del ingls External Output).
Consultas (EQ, del ingls External Query).
Grupos de datos lgicos internos (ILF, del ingls Internal Logic File).
Grupos de datos lgicos externos (EIF, del ingls External Interface File).
Con estos parmetros, se determinan los puntos de funcin sin ajustar. A este valor, se le aplica un Factor de
Ajuste obtenido en base a unas valoraciones subjetivas sobre la aplicacin y su entorno. Es decir las
caractersticas generales del sistema.
La aplicacin de la tcnica de los Puntos de Funcin comprende los siguientes pasos:
Definicin de los lmites del sistema.

Definicin de parmetros.
Valoracin de la complejidad.
Anlisis de las caractersticas generales del sistema.
6.1. DEFINICIN DE LOS LMITES DEL SISTEMA
El lmite es utilizado para definir el alcance del sistema y ayudar a identificar los parmetros externos.
Existen tres visiones de los lmites del sistema, dependiendo de la utilizacin que quiera realizarse de la tcnica:
La aplicacin o lmite del producto. Abarca a la totalidad de la aplicacin y se realiza la cuenta de puntos
al final del desarrollo del proyecto cuando se gestiona el grupo de mantenimiento o cuando la
organizacin inicia el uso de FPA (Anlisis de puntos de funcin). Este tipo de cuenta puede ser tambin
obtenida de un sistema en funcionamiento.
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.
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:
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:
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.
6.2. 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.
Estos componentes pueden ser clasificados como Tipos de Funciones y son de dos clases: Datos o
Transacciones.
6.3. TIPOS DE FUNCIN DE 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.
6.3.1 FICHEROS LGICOS INTERNOS
Un Fichero Lgico Interno es un grupo de datos lgicamente relacionados identificables por los usuarios o
informacin de control mantenidos y utilizados dentro de los lmites de la aplicacin.
Por un grupo de datos lgicamente relacionados e identificables por un usuario se entiende aquellos datos que un
usuario experto podra identificar cumpliendo con un requisito especfico de la aplicacin.
Correspondera al almacn de datos identificado por un nombre en un Diagrama de Flujos de Datos.
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 las que se muestran en la FIG-9:
FIG-9. Reglas de identificacin de ficheros lgicos internos
6.3.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.
Las reglas para identificar estos tipos de funcin son que se muestran en la FIG-10:
FIG-10. Reglas de identificacin de ficheros interfase externos
6.4 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.
6.4.1 ENTRADAS EXTERNAS
Las Entradas Externas son datos o informacin de control que se introducen en la aplicacin desde fuera de sus
lmites.
Estos datos mantienen un Fichero Lgico Interno. La Informacin de Control est constituida por datos utilizados
por un proceso dentro de los lmites de la aplicacin para asegurar el cumplimiento de los requisitos del negocio
definidos por los usuarios.
Esta Informacin de Control puede mantener directamente un Fichero Lgico Interno. Una Entrada Externa
debera ser considerada nica si tiene un formato distinto de las dems o el diseo lgico requiere una lgica de
procesamiento distinta de otra Entrada Externa del mismo formato. En otras palabras, una Entrada Externa se
considera nica si los datos son mantenidos en un Fichero Lgico Interno (ILF) y el formato de entrada es nico o
la lgica del proceso es nica. Para cada proceso identificado que actualiza un Fichero Lgico Interno:
Hay que considerar cada formato de entrada como un proceso distinto, si los datos utilizados por el
proceso pueden tener distintos formatos.
Hay que sumar una unidad a cada Entrada Externa por cada actividad de mantenimiento de datos
realizada (sumar, cambiar, borrar).
Las reglas para identificar estos tipos de funcin son que se muestran en la FIG-11:
FIG-11. Reglas de identificacin de entradas externas
Ejemplos de este tipo de funcin son:
Las transacciones: Datos introducidos para mantener Ficheros Lgicos Internos.

Las pantallas de entrada: Hay que aadir una unidad a Entradas Externas por cada funcin que
mantiene un Fichero Lgico Interno. Por ejemplo, si los datos introducidos en esa pantalla 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.
6.4.2 SALIDAS EXTERNAS
Las Salidas Externas son datos o informacin de control que sale de los lmites de la aplicacin. Esta salida debe
ser considerada nica si tiene un formato nico o si el diseo lgico requiere un proceso lgico distinto de otras
salidas del mismo formato. Toda salida ha de requerir un proceso de clculo de la informacin que se
proporciona.
Las reglas para identificar este tipo de funciones son que se muestran en la FIG-12:
FIG-12. Reglas de identificacin de salidas externas
Deben considerarse Salidas Externas:
La transferencia de datos a otras aplicaciones: Datos que residen en un Fichero Lgico Interno que
son formateados y procesados para ser utilizados por otra aplicacin. Las salidas son identificadas
basadas en los procesos requeridos para el tratamiento de los datos. Un fichero fsico de salida, cuando
se analiza lgicamente, puede corresponder a varias salidas. De una manera similar, dos o ms ficheros
fsicos de salida pueden corresponder a una Salida Externa si el proceso lgico y los formatos son
idnticos para cada uno de ellos. Un mtodo para identificar mltiples Salidas Externas es ver cuntos
tipos de registros distintos hay en el fichero.
Los mensajes de error/configuracin: No se contaran si estn asociados a una Consulta o a una
Entrada.
Los grficos: Cada grfico distinto, solicitado por el usuario, debera ser contado como una salida. As, si
unos datos estadsticos se presentan en formato de tabla, diagrama de barras, y tarta, se contarn como
3 salidas.
Los generadores de informes: Una salida desarrollada por el usuario con un generador de informes
debera ser contada como una salida para cada tipo de informe especificado.
Si el usuario solicita una facilidad de generacin de informes como parte de la aplicacin para ser
confeccionados por l mismo, la cuenta ser la siguiente:
Debera contarse una Entrada Externa por cada parmetro para la definicin de informes o comando
(ej. select, compare, sort merge, calculate, format, etc.) utilizado por el usuario para controlar la
generacin del informe.
Debera contarse una Salida por el informe total.
Debera contarse un Fichero Lgico si se crea un nuevo fichero y ste se salva.
No se deben contar como Salidas:
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.
6.4.3 CONSULTAS EXTERNAS
Las consultas representan los requisitos de informacin a la aplicacin en una combinacin nica de
entrada/salida que se obtiene de una bsqueda de datos, no actualiza un Fichero Lgico Interno y no contiene
datos derivados. Una consulta se considera nica si tiene un formato distinto de otras consultas, ya sea en
entrada o salida, o si el diseo lgico requiere ediciones distintas a las de otras consultas.
Se entiende por datos derivados aqullos que requieren un proceso distinto a la bsqueda directa, edicin o
clasificacin de informacin de Ficheros Lgicos Internos o Ficheros Interfases Externos.
Las reglas para identificar este tipo de funcin son que se muestran en la FIG-13:
FIG-13. Reglas de identificacin de consultas externas.
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.
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:

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.
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 misma consulta.
Puede ocurrir que en una organizacin en particular surja una situacin que no est cubierta por las guas
existentes para contar Puntos de Funcin. Este mtodo refleja que sta es una tcnica en evolucin. En tales
casos el tcnico debe tomar la decisin de formular una regla, basada en su experiencia personal as como en la
de otros. Lo ms importante es documentar la regla y aplicarla consistentemente.
6.5 VALORACIN DE LA COMPLEJIDAD
Las siguientes tablas (FIG-14) muestran como clasificar los diferentes elementos de funcin y asignarles pesos.
As por ejemplo una entrada que contenga 10 atributos y que en su lgica se requiera acceder a un fichero
diremos que se clasifica de complejidad baja y tiene asociados tres puntos de funcin.
CLASIFICACIN Nmero de Campos o Atributos de la Entrada

ENTRADAS 1-4 Atributos 5-15 Atributos 16 ms
Atrib.
BAJA BAJA MEDIA
0 1 ficheros accedidos 3 3 4
BAJA MEDIA ALTA
2 ficheros accedidos 3 4 6
MEDIA ALTA ALTA
3 ms ficheros 4 6 6
accedidos
CLASIFICACIN Nmero de Campos o Atributos de la Salida

SALIDAS 1-5 Atributos 6-19 Atributos 20 ms
Atrib.
BAJA BAJA MEDIA
BAJA MEDIA ALTA
MEDIA ALTA ALTA
4 ms ficheros 5 7 7
accedidos
FIG-14. Elementos de funcin y pesos
En el caso de las consultas diferenciaremos la complejidad de lo que sera la entrada y la salida, le asignaremos
la complejidad mayor de las dos (baja, media o alta), pero solo un peso (3, 4 6), equivalente al de una entrada
de la complejidad calculada.
Los ficheros de las entradas, salidas y consultas se calculan a partir de los ficheros, lgicos internos o de interfaz
externos, que son accedidos durante el proceso asociado.
Los atributos son tipos de datos elementales reconocibles por el usuario. En las entradas se contarn tambin
aquellos datos que son almacenados en un fichero como consecuencia de la entrada. Los datos que se
almacenen en muchos campos se contarn slo una vez.
Ejemplo: DNI en la gestin de notas. En las salidas se contarn los campos calculados, por ejemplo totales. En
las salidas no se deben contar ni los literales ni los campos provenientes de variables del sistema como fecha,
nmero de pgina, opciones de prxima pgina o pgina previa. Siempre se contarn los mensajes de
verificacin y error como un campo que puede contener estos valores. Tambin se cuentan las opciones que
indican la tarea a realizar, ejemplos son: aceptar o continuar. En las siguientes figuras se muestra un ejemplo.
Complejidad Nmero de Campos o Atributos

FICHEROS
LGICOS INTERNOS 1-19 Atributos 20-50 Atributos 51 o - Atributos
BAJA BAJA MEDIA
1 Registro Lgico 7 7 10
BAJA MEDIA ALTA
2-5 Registros Lgicos 7 10 15
MEDIA ALTA ALTA
6 o ms Registros 10 15 15
Lgicos
FIG-15. Estimacin de ficheros lgicos internos
Complejidad Nmero de Campos o Atributos

FICHEROS
INTERFAZ EXTERNOS 1-19 Atributos 20-50 Atributos 51 - Atributos
BAJA BAJA MEDIA
1 Registro Lgico 5 5 7
BAJA MEDIA ALTA
2-5 Registros Lgicos 5 7 10
MEDIA ALTA ALTA
6 o ms Registros 7 10 10
Lgicos
FIG-16. Estimacin de ficheros interfaz externos
Cuando se cuenten los atributos en un fichero se tendr en cuenta:
Slo aquellos que el usuario es capaz de reconocer, aunque aparezcan de forma repetida se cuentan una
sola vez.
Se han de contar los campos que hacen falta para mantener las relaciones con otros ficheros Internos o
Externos.
Contar como un solo campo aquellos que aparecen como consecuencia de las tcnicas utilizadas en la
implementacin fsica:
Campos que aparecen ms de una vez en una agrupacin de datos por la tecnologa o
implementacin. Por ejemplo un DNI que aparezca en alumno y en una tabla de aficiones, si hemos
decidido que forman parte del mismo fichero las dos tablas.
Campos repetidos con el mismo formato pero que estn para permitir mltiples ocurrencias. Por
ejemplo nota ordinaria (Febrero) y nota extraordinaria (Junio)
Para contar los registros lgicos (tipo de registro) de una agrupacin de datos (fichero), se han de tener en cuenta
las siguientes reglas:
Todo fichero tiene un conjunto de datos bsicos (no repetitivos) ms otros registros lgicos.
Un registro lgico es un subgrupo de datos elementales de un fichero, identificables por el usuario. Hay
dos tipos de subgrupos los obligatorios y los opcionales. En el fichero de alumnos sera obligatorio sus
datos de acceso (Mayor-25, FP, COU y Otras-Carreras que contendrn datos diferentes, habr slo uno
de estos, con el que accedi a la carrera actual) y opcionales como sus aficiones deportivas, aficiones de
lectura, etc. que pueden aparecer o no.
Contar un registro lgico por cada subgrupo, opcional u obligatorio.
Si no hay subgrupos contar un registro lgico.
Con esto se puede realizar la clasificacin de los elementos de funcin. A continuacin hay que calcular los
puntos de funcin sin ajustar, para ello se puede utilizar la siguiente tabla, que adems deja documentado el
clculo del los Puntos de Funcin sin Ajustar (PFSA) FIG-17.
Tipo Elemento Dificultad Peso Cantidad Total Total Elemento

Puntos
Entradas Simple 3 E1 3 * E1
Media 4 E2 4 * E2
Compleja 6 E3 6 * E3
Total Puntos de Funcin
Entradas Peso * Ei
Salidas Simple 4 S1 4 * S1
Media 5 S2 5 * S2
Compleja 7 S3 7 * S3
Salidas Peso * Si
Consultas: Simple 3 C1 3 * C1
Mximo - Media 4 C2 4 * C2
Complejidad( Compleja 6 C3 6 * C3
Entrada, Salida ) Total Puntos de Funcin
Consultas Peso * Ci
Ficheros Internos Simple 7 F1 7 * F1
Media 10 F2 10 * F2
Compleja 15 F3 15 * F3
Ficheros Internos Peso * Fi
Ficheros de Simple 5 I1 5 * I1
Interfaz Media 7 I2 7 * I2
Compleja 10 I3 10 * I3
Ficheros de Interfaz Peso * Ii
Total Puntos de Funcin Sin Ajustar (PFSA) Peso*Xij
FIG-17. Puntos de Funcin sin Ajustar
6.6. ANLISIS DE LAS CARACTERSTICAS GENERALES DEL SISTEMA
Los Puntos de Funcin sin ajustar son una aproximacin de la complejidad del sistema, pero quedan
caractersticas externas que no hemos contemplado, as como caractersticas del proceso de desarrollo del
sistema informtico que influirn en el coste del sistema y que podemos cuantificar desde las primeras fases del
desarrollo. Estos factores adicionales segn Albrecht son catorce. Cada factor tomar un valor entre 0 y 5, de
modo que cuanta ms importancia tenga un factor mayor valor se le asignar.
La siguiente tabla indica los valores posibles de un factor y su significado:
Valor asignado Significado del valor

0 Sin influencia, factor no presente
1 Influencia insignificante, muy baja
2 Influencia moderada o baja
3 Influencia media, normal
4 Influencia alta, significativa
5 Influencia muy alta, esencial
FIG-18. Valores posibles de un factor
Con estos valores calculados, los sumaremos y obtendremos el Factor de Complejidad Total.
A continuacin describimos cada factor a modo de gua.
COMUNICACIN DE DATOS. Los datos usados en el sistema se envan o reciben por lneas de
comunicaciones.
PROCESO DISTRIBUIDO. Existen Procesos o Datos distribuidos, y el control de estos, forma parte del
sistema.
OBJETIVOS DE RENDIMIENTO. Si el rendimiento es un requisito del sistema. Es decir es crtico algn
factor como tiempo de respuesta o cantidad de operaciones por hora. Se tendr que hacer
consideraciones especiales durante el diseo, codificacin y mantenimiento.
CONFIGURACIN DE EXPLOTACIN USADA INTENSAMENTE POR OTROS SISTEMAS. El sistema
tendr que ejecutarse en un equipo en el que coexistir con otros, compitiendo por los recursos, y esta es
una caracterstica fundamental, teniendo que tenerse en cuenta en la fase de diseo.
TASA DE TRANSACCIONES. La tasa de transacciones ser elevada. Se tendr que hacer
consideraciones especiales durante el diseo, codificacin e instalacin.
ENTRADA DE DATOS EN-LNEA. La entrada de datos ser directa desde el usuario a la aplicacin, de
forma interactiva.
EFICIENCIA CON EL USUARIO FINAL. Se demanda eficiencia para el usuario en su trabajo, es decir se
tiene que disear e implementar la aplicacin con interfaces fciles de usar y con ayudas integradas. Los
tipos de elementos asociados a la eficiencia del usuario son:
ACTUALIZACIONES EN-LNEA. Los ficheros maestros y las Bases de Datos son modificados
directamente de forma interactiva.
LGICA DE PROCESO INTERNO COMPLEJA. La complejidad de los procesos es una caracterstica de
la aplicacin.
La complejidad algortmica realmente est mal resuelta en esta tcnica. Hay que tener en cuenta que se
ha desarrollado pensando en sistemas de proceso empresarial. Para sistemas complejos
algortmicamente hay tcnicas que miden la complejidad como las de McCabe.
REUSABILIDAD DEL CDIGO. Se tendr que hacer consideraciones especiales durante el diseo,
codificacin y mantenimiento para que el cdigo se reutilice en otras aplicaciones.
CONTEMPLA LA CONVERSIN E INSTALACIN. Se proveern facilidades de instalacin y conversin
en el sistema. Se desea que la conversin del sistema antiguo sea fcil de realizar durante la puesta en
marcha del sistema nuevo.
FACILIDAD DE OPERACIN. Entendemos por operacin del sistema los trabajos asignados al centro de
proceso de datos para una aplicacin dada como: arranque, parada, recuperacin ante fallos, copias de
seguridad. Aqu tendremos en cuenta la minimizacin de las actividades manuales en el CPD. As, sta
caracterstica se valora cuando se ha descrito desde las primeras fases, habiendo de dedicarse especial
atencin durante el diseo, codificacin y pruebas.
INSTALACIONES MLTIPLES. El sistema ha de incluir los requerimientos de diversas empresas o

departamentos en donde se ejecutar (incluso distintas plataformas). Estas caractersticas estarn
presentes durante el diseo, codificacin y pruebas.
FACILIDAD DE CAMBIOS. Se tendr que hacer consideraciones especiales durante el diseo,
codificacin y mantenimiento para que en el sistema sea fcil de introducir cambios y fcil de adaptar al
usuario.
6.7. CLCULO DEL FACTOR DE COMPLEJIDAD TOTAL.
La siguiente tabla documenta el clculo del factor de complejidad total (FCT).
# Factor de Complejidad Valor (0..5)

1 Comunicacin de Datos.
2 Proceso Distribuido.
3 Objetivos de Rendimiento
4 Configuracin de Explotacin compartida
5 Tasa de Transacciones
6 Entrada de Datos EN-LNEA
7 Eficiencia con el Usuario Final
8 Actualizaciones EN-LNEA
9 Lgica del Proceso Interno Compleja
10 Reusabilidad del Cdigo
11 Contempla la Conversin e Instalacin
12 Facilidad de Operacin
13 Instalaciones Mltiples
14 Facilidad de Cambios
Factor de Complejidad Total (FCT) Valori
FIG-19. Clculo del factor de complejidad total
7. MODELO DE CICLO DE VIDA

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.
El modelo asume que el esfuerzo para proyectos de desarrollo de software se distribuye de forma similar a una
coleccin de curvas de Rayleigh-Norden, pues la forma que toman estas curvas fueron descritas analticamente
por Lord Rayleigh, una para cada actividad del desarrollo, segn se muestra en la siguiente figura FIG-20:
FIG-20. Curvas de Rayleigh-Norden de esfuerzo de desarrollo
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.
8. MODELO COCOMO 81
En el ao 1981, Barry Boehm [BOEHM81] presenta el Modelo Constructivo de Coste (COCOMO), como una
jerarqua de modelos de estimacin para el software. En aquella poca, este modelo era perfectamente aplicable
a los procesos de desarrollo software del momento. Pero en casi 20 aos que han pasado desde entonces, las
cosas han cambiado bastante, y se ha hecho necesaria una readaptacin del modelo de tal forma que contemple
las caractersticas de los procesos de desarrollo software actuales. As las cosas, el modelo COCOMO se
reinvent de nuevo a principios de los aos 90, volviendo a nacer con el nombre de COCOMO II. Se trata,
entonces, de una revisin del modelo original, adaptado a los cambios acontecidos en el desarrollo profesional de
aplicaciones software, desde los aos 70 a esta parte.
Las nuevas caractersticas que introduce, su adaptacin a las nuevas metodologas de desarrollo y la posibilidad
de utilizarlo prcticamente en cualquiera de las etapas del ciclo de de vida del software (incluidas las primeras
etapas, como modelo de estimacin de la funcionalidad y el esfuerzo de desarrollo), har que el modelo
COCOMO II se convierta en uno de los ms populares y utilizados a lo largo de todo el mundo.
La jerarqua de modelos propuesta por Boehm en 1981, consta de los 3 siguientes:
El modelo COCOMO bsico. Se trata de un modelo univariable esttico que calcula el esfuerzo y el
coste del desarrollo de un proceso software, en funcin del tamao del programa expresado en lneas de
cdigo (LDC) estimadas.
El modelo COCOMO intermedio. Calcula el esfuerzo de desarrollo de una aplicacin software, en
funcin del tamao del programa y de un conjunto de conductores de costes, que incluyen la evaluacin
subjetiva del producto, del hardware, del personal y de los atributos del proyecto.
El modelo COCOMO avanzado. Incorpora todas las caractersticas del modelo intermedio y lleva a cabo
una evaluacin del impacto de los conductores de coste en cada fase del proceso de desarrollo software
(anlisis, diseo, etc).
Adems, Boehm clasifica los proyectos software en tres tipos distintos:
De tipo Orgnico, que son proyectos software relativamente pequeos y sencillos, y similares a otros ya
desarrollados anteriormente.
De tipo Semiacoplado, que son proyectos software intermedios en tamao y en complejidad.
De tipo Empotrado, que son proyectos software que debern ser desarrollados en un entorno muy
restringido de hardware, software y restricciones operativas.
Tras la jerarqua de modelos y la clasificacin de los proyectos software, Boehm formula las ecuaciones
apropiadas para la estimacin de la duracin y el tamao de las aplicaciones software, as como el conjunto de
atributos conductores de coste, necesarios para la estimacin de estos parmetros con el modelo COCOMO
intermedio.
8.1 MODELO COCOMO 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:
Modo orgnico
MM = 2.4 (KDSI) 1.05
TDEV = 2.5 (MM) 0.38
Modo semiacoplado
MM = 3.0 (KDSI) 1.12
TDEV = 2.5 (MM) 0.35
Modo empotrado
MM = 3.6 (KDSI) 1.2
TDEV = 2.5 (MM) 0.32
donde: KDSI = Kilo-instrucciones fuente suministradas
mm = Meses x hombre
TDEV = Tiempo de desarrollo en meses
Un resumen de las caractersticas comparativas de los modos orgnico, semiacoplado y empotrado se presenta
en la tabla siguiente:
FIG-21. Caractersticas comparativas de los modos orgnico, semiacoplado y empotrado
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.
Las diferencias entre los tres modos orgnico, semiacoplado y empotrado, lgicamente se traducen en diferencias
considerables en lo que respecta a la distribucin del esfuerzo y la duracin entre las diferentes fases del
proyecto. Si comparamos el modo empotrado con el orgnico, las principales diferencias son las siguientes:
En el modo empotrado se consume considerablemente mas esfuerzo en la fase de integracin y pruebas.

Ello es consecuencia de la necesidad de seguir y comprobar los requisitos del logical y las
especificaciones de interfaz ms cuidadosamente en los modos empotrado y semiacoplado.
En el modo empotrado se consumen proporcionalmente menos esfuerzos en la fase de codificacin y
pruebas unitarias. Esto resulta de la necesidad de dedicar ms esfuerzo en trminos proporcionales a las
otras fases.
En el modo empotrado se consume notablemente ms plazo en las fases de planificacin y requisitos y
de diseo del sistema, a causa de la necesidad de unos requisitos y especificaciones de diseo ms
completos y validados, y de hacer esto con un nmero relativamente reducido de personas.
En el modo empotrado se consume considerablemente menos plazo en la fase de programacin, a
consecuencia de la estrategia que se adopta de tener a muchos programadores trabajando en paralelo
para reducir la duracin total del proyecto.
En las tablas siguientes se presenta la distribucin por fases del esfuerzo y la duracin para los tres modos, y
segn el tamao del proyecto.
FIG-22. Distribucin por fases del esfuerzo y la duracin - Modo orgnico.
FIG-23. Distribucin por fases del esfuerzo y la duracin - Modo semiacoplado.
FIG-24. Distribucin por fases del esfuerzo y la duracin - Modo empotrado.
8.2. MODELO COCOMO 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.
Estas 15 variables explicativas son las que se relacionan a continuacin agrupadas por categoras.
Atributos del Producto

Fiabilidad requerida del logical (RELY)
Tamao de la base de datos (DATA)
Complejidad del producto
Atributos del Ordenador
Restricciones de tiempo de ejecucin (TIME)
Restricciones de Memoria principal (STOR)
Volatilidad de la mquina virtual (VIRT)
Tiempo de respuesta del ordenador (TURN)
Atributos del personal
Capacidad de anlisis (ACAP)
Experiencia en la aplicacin (AEXP)
Capacidad de programacin (PCAP)
Experiencia en la mquina virtual (VEXP)
Experiencia en el lenguaje de programcin (LEXP)
Atributos del proyecto
Prcticas de programacin modernas (MODP)

Uso de herramientas software (TOOL)
Planificacin temporal del desarrollo exigido (SCED)
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 siguiente tabla 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.
FIG-25. Multiplicadores de esfuerzos
La estimacin de esfuerzo aplicando este modelo es:
Modo Orgnico:
MM= 3.2. (KDSI)1,05
Modo Semilibre:
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.
8.2. MODELO COCOMO AVANZADO
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 avanzado presenta dos funcionalidades que resuelven las limitaciones de COCOMO intermedio:
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 avanzado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo en cada
fase. Estos multiplicadores determinan el esfuerzo requerido para completar cada fase.
Descomposicin jerrquica del producto a tres niveles. 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 avanzado evita este problema proporcionando una jerarquizaron del
producto a tres niveles:
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.
9. MODELO COCOMO II
Boehm, Clark, Horowitz, Westland, Madachy, and Selby [BOEHMN et al, 1995] reconocieron las limitaciones del
modelo COCOMO 81, los beneficios de la utilizacin del anlisis FPA y la importancia de poder realizar
estimaciones precisas sobre las nuevas metodologas de desarrollo que existen hoy en da. Debido a ello
apareci el nuevo modelo COCOMO II, resultado de la adaptacin del modelo original de Boehm a las
caractersticas y necesidades de los procesos de desarrollo software actuales.
Al igual que el modelo COCOMO 81 comentado antes, COCOMO II est dividido en otros tres modelos distintos:
El modelo de Composicin de la Aplicacin. Contempla las caractersticas de los proyectos software en

los que se han utilizado las nuevas herramientas de desarrollo (sobre todo las orientadas a la
construccin de interfaces grficos). Se basa en lo que se ha dado en llamar Puntos Objeto.
El modelo de Diseo Preliminar. Permitir la estimacin de costes y duracin de proyectos antes de
haber determinado completamente su estructura (es decir, es de aplicacin en las primeras etapas del
ciclo de desarrollo). Utiliza un nuevo conjunto de atributos conductores de costes, y para l se definen
nuevas ecuaciones para estimacin. Se basa en las mtricas de Puntos Funcin no Ajustados y en las
Kilolneas de cdigo fuente (KSLOC).
El modelo de Post-Arquitectura. Se trata del modelo ms detallado de COCOMO II. Es de aplicacin
una vez que la arquitectura del sistema empieza a tomar forma (durante las fases de diseo). Incorpora
nuevas ecuaciones y nuevos atributos conductores de costes.
Los objetivos de este modelo son:
Desarrollar un modelo de estimacin de costes y tiempos en consonancia con las prcticas actuales de
ciclo de vida del software.
Construir una base de datos y una herramienta de costes del software que incluya capacidades para la
mejora continua del modelo.
Proveer un marco analtico cuantitativo, y un conjunto de herramientas y tcnicas para evaluar los efectos
de las mejoras en la tecnologa software sobre los costes y tiempos del ciclo de vida del software.
Estos objetivos intentan satisfacer las necesidades de los ingenieros del software:
Soportar planificacin de proyectos, previsin de personal, estimaciones a la conclusin, preparacin de

proyectos, replanificacin, rastreo de proyectos, negociacin de contratos, evaluacin de propuestas, nivelacin
de recursos, evaluacin de diseos, etc.
9.1. LOS PUNTOS OBJETO COMO MEDIDA DEL TAMAO FUNCIONAL
La estimacin con Puntos Objeto es una tcnica relativamente nueva, cuyo campo de aplicacin es doble:
Por una parte, es til en aquellas aplicaciones que puede desarrollarse con un alto componente de
reutilizacin de software, es decir, como si se tratara de tomar componentes ya desarrollados y, al estilo
de un puzzle, ensamblarlos y adaptarlos hasta conformar la nueva aplicacin. Es lo que se ha dado en
llamar Composicin o Ensamblaje de Aplicaciones.
Por otra parte, es til tambin en aplicaciones desarrolladas por herramientas RAD (Rapad Application
Development), las cuales generan automticamente (y con el mnimo esfuerzo), todo tipo de
componentes software para el sistema que se est desarrollando (interfaces grficos, prototipos
operativos, etc...).
Segn esto, los Puntos Objeto sern una mtrica del tamao funcional de una aplicacin software, en funcin del
nmero de pantallas generadas, informes producidos y, en general, cualquier mdulo generado por sistemas
automticos de desarrollo (RAD) que haya sido integrado en la aplicacin. Al igual que suceda con los Puntos
Funcin, los Puntos Objeto podrn utilizarse tambin para estimar el esfuerzo de desarrollo de una aplicacin
concreta, perteneciente al mbito de la Composicin o Ensamblaje de Aplicaciones.
El proceso a seguir para la estimacin en Puntos Objeto tiene cierta similitud con el proceso de conteo de Puntos
Funcin, slo que se tiene en cuenta un factor adicional: el % de componentes reutilizados que integrarn la
aplicacin, es decir, qu % de los componentes sern tomados de aplicaciones previamente desarrolladas. Este
ser el factor de ajuste para el conteo de Puntos Objeto, de igual manera que lo era el VAF para el conteo de
Puntos Funcin.
Antes de comentar los cinco pasos de que consta el proceso de conteo de Puntos Objeto, mostraremos el
significado de la terminologa utilizada:
NOP: (New Object Points). Es el nmero total de Puntos Objeto Ajustados.

srvr: Es el nmero de tablas de datos del servidor (mainframe o equivalente) utilizadas por las pantallas
de interfaz o por los informes (reports) generados por la aplicacin.
clnt: Es el nmero de tablas de datos del cliente (ordenador personal o estacin de trabajo) utilizadas por
las pantallas de interfaz o por los informes (reports) generados por la aplicacin.
%r: Es el porcentaje de pantallas, informes y mdulos 3GL7 que han sido reutilizados, es decir, que
provienen de otras aplicaciones previamente desarrolladas.
Los cinco pasos para el conteo de Puntos Objeto son los siguientes:
9.2. PASO 1: CONTABILIZACIN DE OBJETOS.
En este primer paso de debern contar los objetos del sistema que resultan de inters para la estimacin, es
decir, pantallas de interfaz, informes (reports) y mdulos desarrollados en lenguajes 3GL.
Por lo tanto, el concepto de objeto en el modelo COCOMO II no tiene porqu estar necesariamente relacionado
con el concepto de objeto de la Programacin Orientada a Objetos.
9.3. PASO 2: CLASIFICACIN DE LOS OBJETOS.
Los objetos identificados en el Paso 1 debern clasificarse en cuanto a su nivel de complejidad.
Existen 3 niveles posibles: complejidad baja, media y alta en funcin, principalmente, de los atributos srvr y clnt
comentados anteriormente. La siguiente tabla indica cmo han de clasificarse los objetos:
FIG-26. Clasificacin de los objetos del sistema (pantallas de interfaz e informes).
Como vemos, la tabla anterior slo clasifica a las pantallas de interfaz y a los informes (reports),
Los mdulos desarrollados en lenguajes 3GL se considerarn siempre de complejidad Alta.
9.4. PASO 3: ASIGNACIN DE PESOS A LOS OBJETOS DEL SISTEMA.
A cada objeto del sistema, una vez clasificado, hay que asignarle un valor concreto en Puntos Objeto (peso) que
representar el esfuerzo requerido para su implementacin. Los valores propuestos por el modelo COCOMO II
son los que se muestran en la tabla siguiente:
FIG-27. Pesos (en Puntos Objeto), en funcin de la complejidad de los objetos del sistema.
9.5. PASO 4: CLCULO DEL NMERO TOTAL DE PUNTOS OBJETO SIN AJUSTAR.
El nmero total de Puntos Objeto sin Ajustar (POsA) ser la suma de todos los Puntos Objeto asignados a cada
uno de los componentes del sistema (POi), es decir:
9.6. PASO 5: CLCULO DEL NMERO TOTAL DE PUNTOS OBJETO AJUSTADOS
Para calcular el nmero total de Puntos Objeto Ajustados (POA), deberemos multiplicar el nmero total de Puntos
Objeto sin Ajustar (POsA) por el % de componentes reutilizados que se espera incorporar al sistema (%r). El
resultado obtendio (POA) tambin se conoce con el nombre de NOP (New Object Points), y representa el tamao
funcional de la aplicacin en estudio.
Una extensin del modelo COCOMO II nos permitir, incluso, determinar ratios de productividad tomando en
consideracin tanto las posibilidades de la aplicacin RAD utilizada, como la experiencia y capacidades del
equipo de desarrollo de la aplicacin. Se utiliza la siguiente ecuacin:
...obtenindose el esfuerzo de desarrollo en Personas-Mes. PROD representa la productividad del equipo de

desarrollo y del entorno, y se obtiene la siguiente tabla:
FIG-28. Ratios de productividad segn equipo y entorno de desarrollo.
10. CONCLUSIN
La estimacin de los parmetros del software es una tarea fundamental en la gestin del proyecto, aunque
histricamente no se ha tratado as y hemos aceptado como algo natural las desviaciones y atrasos en los
proyectos. El aumento de los costes de desarrollo ha obligado a los gestores a poner ms atencin en las tareas
de estimacin. Sobre todo la estimacin de los parmetros econmicamente sensibles, tales como el tamao del
cdigo, el nmero de personas que componen el equipo de desarrollo y el tiempo necesario para finalizar el
proyecto.
La estimacin de proyectos lleva consigo una problemtica asociada a su propia definicin. Llamamos estimacin
al conjunto de valores para algo que vamos a hacer. De esto surgen las preguntas bsicas Cunto costar y
cunto tardaremos?
El proceso de estimacin es algo vivo durante todo el proyecto, al principio se cuenta con pocos valores que
permitan una estimacin fiable, conforme avanza el proyecto el nmero de factores aumenta progresivamente, lo
que nos permitir afinar la estimacin.
Al realizar la estimacin tenemos que tener en cuenta lo que pretendemos conseguir, es decir, no solamente el
nmero de horas que necesitaremos para realizar el proyecto, es necesario conocer tambin muchos otros
valores, como por ejemplo nmero de recursos, perfiles de los mismos, etc. Toda esta informacin formar parte
de la documentacin que genera el proceso de estimacin.
Existen varias tcnicas de estimacin, algunas basadas simplemente en la opinin y conocimientos de una serie
de personas, otras basadas en la historicidad y otras, las ms fiables, basadas en algoritmos matemticos y
anlisis del propio proyecto, que nos darn una idea ms certera del coste del mismo.
Depende del mtodo de estimacin que escojamos tendremos un resultado ms o menos fiable. Al momento de
elegir el mtodo, es importante tener en cuenta una serie de consideraciones que definen la calidad del mtodo
de estimacin. Es importante que el mtodo est implantado de forma correcta y completa en la organizacin y
forme parte de la metodologa de desarrollo de Sw.
El objetivo principal de la estimacin es tener claro el dimensionamiento del proyecto, conocer el mayor nmero
de valores posibles que afectan a dicha dimensin, esto nos permitir tener un buen mecanismo de toma de
decisiones relativas al mismo.
Los mtodos de estimacin estn evolucionando continuamente. Aqu se han abordado algunos de los ms
conocidos, que son los mtodos algortmicos. Sin embargo se est trabajando mucho actualmente en los
mtodos del tipo no-algortmicos, basados en tcnicas de inteligencia artificial y ms concretamente de
aprendizaje mquina. De este modo aparecen mtodos que emplean lgica difusa, razonamiento basado en
casos o redes neuronales, por citar algunos. Y todos persiguen un nico fin comn: la calidad de la estimacin.
11. BIBLIOGRAFA
Connell, S. Desarrollo y Gestin de Proyectos Informticos. McGraw-Hill Interamericana. Espaa 1997.

Pressman, R.S., Ingeniera del Software. Un enfoque prctico, Mc Graw Hill, 2001.
Fergus O'Connell. "How to run successful projects". Prentice Hall, 1994. (Biblioteca UPV)
Metzger, P. Boddie, J. Managing a programming project: people and processes 3 ed. Prentice Hall,
1996.
Thomsett, R. Third Wave Project Management. Prentice Hall, 1993. (Biblioteca UPV)
Yourdon, Edward. Anlisis Estructurado Moderno. Prentice Hall, 1993. (Biblioteca UPV)
Dreger, J.B. "Function Point Analysis", Prentice Hall, 1989. (Biblioteca UPV).
12. ESQUEMA RESUMEN

Como hemos podido ver 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.
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?
Por otra parte existe una problemtica bastante fuerte en el proceso de estimacin de software debido a diversos
factores.
Cundo se debe realizar la estimacin de un proyecto software?
La estimacin, como ya hemos dicho, 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. La estimacin
continua nos permite el uso de un nico modelo coherente que pueda capturar y utilizar la informacin sobre el
proyecto a medida que este se conozca.
Ms precisamente, el proceso de estimacin comienza usando unas pocas variables claves para proveer las
"macro-caractersticas" de un proyecto, y evoluciona incorporando informacin de ms bajo nivel para producir las
"micro-caractersticas" del proyecto.
Para la estimacin, existen cuatro tcnicas bsicas y comunes:
La opinin de los expertos; Esta tcnica se basa en la experiencia profesional de los participantes en el
proyecto de estimacin.
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.
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.
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.
Los objetivos de la estimacin de proyectos son reducir los costes e incrementar los niveles de servicio y de
calidad.
Midiendo determinados aspectos del proceso de software se puede tener una visin de alto nivel de lo
que suceder durante el desarrollo.
Las mediciones de procesos anteriores permiten realizar predicciones sobre los actuales.
Las mediciones de atributos de proceso en fases iniciales del desarrollo permiten realizar predicciones
sobre fases posteriores.
Las predicciones de proceso conducen la toma de decisiones antes del comienzo del desarrollo, durante
el
proceso de desarrollo, durante la transicin del producto al cliente y a lo largo de la fase de
mantenimiento.
Un mtodo de estimacin eficaz permitir ignorar aspectos sin inters y concentrare en los aspectos esenciales.
Un buen modelo debera poseer capacidades predictivas, mejor que ser meramente descriptivo o explicativo.
La validez de las mtricas de software y de los modelos de estimacin debe ser establecida demostrando la
coincidencia entre los datos empricos y los experimentales. Esto requiere una cuidadosa atencin en la toma de
medidas y en el anlisis de los datos. Veamos algunos de estos mtodos de estimacin:
Mtodo de la suma de las tareas.

Normalmente se suele confundir el esfuerzo necesario para desarrollar una tarea (meses/hombre) con el
tiempo necesario para llevar a cabo la misma.
Una tarea que tenga asignado un esfuerzo de 10 das, puede llevarse a cabo en el plazo de 5 semanas,
aplicando un esfuerzo de 2 das a la semana. Tambin nos podemos encontrar con el caso contrario en
que una tarea que necesita el esfuerzo de 10 das se lleve a cabo en una semana, empleando a dos
personas a tiempo completo en su ejecucin. El esfuerzo aplicado puede verse afectado por
interferencias externas.
Regla 3 Veces Programacin.
Consiste bsicamente en realizar la estimacin del nmero de mdulos de software o programas y su
complejidad. Estimar el esfuerzo requerido para completar la codificacin y la compilacin de cada
mdulo y el esfuerzo total de la programacin y multiplicarlo por 3
Modelo de 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.
Modelo de puntos Funcionales.

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.
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:
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).
La aplicacin de la tcnica de los Puntos de Funcin comprende los siguientes pasos:
Definicin de los lmites del sistema. El lmite es utilizado para definir el alcance del sistema y ayudar
a identificar los parmetros externos.
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. Estos componentes pueden ser clasificados como Tipos de
Funciones y son de dos clases: Datos o Transacciones.
Valoracin de la complejidad. Se deben clasificar los diferentes elementos de funcin y asignarles
pesos. As por ejemplo una entrada que contenga 10 atributos y que en su lgica se requiera acceder
a un fichero diremos que se clasifica de complejidad baja y tiene asociados tres puntos de funcin.
Anlisis de las caractersticas generales del sistema. Existen caractersticas externas que no hemos
contemplado, as como caractersticas del proceso de desarrollo del sistema informtico que influirn
en el coste del sistema y que podemos cuantificar desde las primeras fases del desarrollo. Estos
factores adicionales segn Albrecht son catorce. Cada factor tomar un valor entre 0 y 5, de modo
que cuanta ms importancia tenga un factor mayor valor se le asignar.
Comunicacin de Datos.
Proceso Distribuido.
Objetivos de Rendimiento.
Configuracin de Explotacin Usada intensamente por Otros Sistemas.
Tasa de Transacciones.
Entrada de Datos EN-LNEA.
Eficiencia con el Usuario Final.
Actualizaciones EN-LNEA.
Lgica de Proceso Interno Compleja.
Reusabilidad del Cdigo.
Contempla la Conversin e Instalacin.
Facilidad de Operacin.
Instalaciones Mltiples
Facilidad de Cambios
MODELO COCOMO 81
Modelo Constructivo de Coste (COCOMO), se define como una jerarqua de modelos de estimacin para el
software. Su adaptacin a las nuevas metodologas de desarrollo y la posibilidad de utilizarlo prcticamente en
cualquiera de las etapas del ciclo de de vida del software (incluidas las primeras etapas, como modelo de
estimacin de la funcionalidad y el esfuerzo de desarrollo), har que el modelo COCOMO se convierta en uno de
los ms populares y utilizados a lo largo de todo el mundo.
La jerarqua de modelos propuesta por Boehm en 1981, consta de los 3 siguientes:
El modelo COCOMO bsico.

El modelo COCOMO intermedio.
El modelo COCOMO avanzado.
Adems, Boehm clasifica los proyectos software en tres tipos distintos:
De tipo Orgnico, que son proyectos software relativamente pequeos y sencillos, y similares a otros ya
desarrollados anteriormente.
De tipo Semi-Acoplado, que son proyectos software intermedios en tamao y en complejidad.
De tipo Empotrado, que son proyectos software que debern ser desarrollados en un entorno muy
restringido de hardware, software y restricciones operativas.
EL MODELO COCOMO 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:
Modo orgnico
MM = 2.4 (KDSI) 1.05
TDEV = 2.5 (MM) 0.38
Modo semiacoplado
MM = 3.0 (KDSI) 1.12
TDEV = 2.5 (MM) 0.35
Modo empotrado
MM = 3.6 (KDSI) 1.2
TDEV = 2.5 (MM) 0.32
donde: KDSI = Kilo-instrucciones fuente suministradas
mm = Meses x hombre
TDEV = Tiempo de desarrollo en meses
EL MODELO COCOMO 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.
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 estimacin de esfuerzo aplicando este modelo es:
Modo Orgnico:
MM= 3.2. (KDSI)1,05
Modo Semilibre:
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.
EL MODELO COCOMO AVANZADO
El modelo avanzado presenta dos funcionalidades que resuelven las limitaciones de COCOMO intermedio:
Multiplicadores de esfuerzo por fases

Descomposicin jerrquica del producto a tres niveles.
El Nivel modulo.
El Nivel subsistema
El Nivel sistema
MODELO COCOMO II.
Es el resultado de la adaptacin del modelo original de Boehm (COCOMO 81) a las caractersticas y necesidades
de los procesos de desarrollo software actuales.
Al igual que el modelo COCOMO 81 comentado antes, COCOMO II est dividido en otros tres modelos distintos:
El modelo de Composicin de la Aplicacin.

El modelo de Diseo Preliminar.
El modelo de Post-Arquitectura.
La estimacin con Puntos Objeto es una tcnica relativamente nueva, cuyo campo de aplicacin es doble:
Por una parte, es til en aquellas aplicaciones que puede desarrollarse con un alto componente de
reutilizacin de software, es decir, como si se tratara de tomar componentes ya desarrollados y, al estilo
de un puzzle, ensamblarlos y adaptarlos hasta conformar la nueva aplicacin. Es lo que se ha dado en
llamar Composicin o Ensamblaje de Aplicaciones.
Por otra parte, es til tambin en aplicaciones desarrolladas por herramientas RAD (Rapad Application
Development), las cuales generan automticamente (y con el mnimo esfuerzo), todo tipo de
componentes software para el sistema que se est desarrollando (interfaces grficos, prototipos
operativos, etc...).
Los cinco pasos para el conteo de Puntos Objeto son los siguientes:
Paso 1: Contabilizacin de objetos.

Paso 2: Clasificacin de los objetos.
Paso 3: Asignacin de pesos a los objetos del sistema.
Paso 4: Clculo del nmero total de Puntos Objeto sin Ajustar.

Paso 5: Clculo del nmero total de Puntos Objeto Ajustados

TICB2 - Tecnicas de Estimacion de Esfuerzo

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TICB2 - Tecnicas de Estimacion de Esfuerzo

Cargado por

Copyright:

Formatos disponibles

www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

B2G1T04 - TCNICAS DE ESTIMACIN DE ESFUERZO DE DESARROLLO.

1. INTRODUCCIN A LAS TCNICAS DE ESTIMACIN DE ESFUERZO DE DESARROLLO ......................... 2

1. INTRODUCCIN A LAS TCNICAS DE ESTIMACIN DE ESFUERZO DE

FIG-1. Lnea base de costes

1.1. PROBLEMTICA DEL PROCESO DE ESTIMACIN DE ESFUERZO DE DESARROLLO

Cunto costar?, cunto tiempo llevar hacerlo?

Qu hace que la estimacin sea tan difcil de realizar?

Las razones para esta complejidad son las siguientes:

El producto software que se tiene que desarrollar: QU

FIG-2. Disparadores de coste

1.2. MARCO TEMPORAL DE LA ESTIMACIN DE ESFUERZO

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

FIG-3. Grado de refinamiento de la estimacin

FIG-4. Estimacin de coste de un proyecto

1.2. SALIDAS DEL PROCESO DE ESTIMACIN

En esta seccin intentaremos dar respuesta a la siguiente pregunta.

Qu es lo que debemos estimar?

Cunto costar? Cunto tiempo llevar hacerlo?

Cunta gente se necesita?

1.3. TCNICAS DE ESTIMACIN

Para la estimacin, existen cuatro tcnicas bsicas y comunes:

1.4. REQUISITOS DE UN BUEN MTODO DE ESTIMACIN

Un mtodo de estimacin tendr xito si:

1.5. MTODOS DE ESTIMACIN

3. MTODO DE LA SUMA DE LAS TAREAS

Deben ensear y adiestrar al personal del proyecto en temas no previstos

FIG-5. Tipo de tarea 1

FIG-6. Tipo de tarea 2

FIG-7. Tipo de tarea 3

FIG-8. Tipo de tarea 4

4. REGLA 3 VECES PROGRAMACIN

Consiste bsicamente en realizar la estimacin del nmero de mdulos de software o programas y su

Incluye administracin, documentacin, diseo, etc.

5. MODELO DE LNEAS DE CDIGO

La definicin ms comn es la siguiente:

donde CLOC (Comentary Lines of Code es el nmero de lneas de comentarios).

No se tiene en cuenta el concepto de reutilizacin.

6. MODELO DE PUNTOS FUNCIONALES

Los objetivos de los Puntos de Funcin son:

Medir lo que el usuario pide y lo que el usuario recibe.

Entrada (EI, del ingls External Input).

La aplicacin de la tcnica de los Puntos de Funcin comprende los siguientes pasos:

Definicin de los lmites del sistema.

6.1. DEFINICIN DE LOS LMITES DEL SISTEMA

FP es el nmero de Puntos de Funcin sin ajustar de la aplicacin

EFP es el nmero de Puntos de Funcin del Proyecto de Mejora.

6.2. DEFINICIN DE PARMETROS

6.3. TIPOS DE FUNCIN DE DATOS

Son de dos tipos: Ficheros Lgicos Internos y Ficheros de Interface Externos.

6.3.1 FICHEROS LGICOS INTERNOS

Correspondera al almacn de datos identificado por un nombre en un Diagrama de Flujos de Datos.

FIG-9. Reglas de identificacin de ficheros lgicos internos

6.3.2 FICHEROS INTERFASE EXTERNOS

FIG-10. Reglas de identificacin de ficheros interfase externos

6.4 TIPOS DE FUNCIN TRANSACCIN

Comprende tres tipos de funcin:

Entradas externas (EI): mantiene datos almacenados internamente.

Vamos a comentar brevemente cada una de ellas.

6.4.1 ENTRADAS EXTERNAS

FIG-11. Reglas de identificacin de entradas externas

Ejemplos de este tipo de funcin son:

Las transacciones: Datos introducidos para mantener Ficheros Lgicos Internos.