Puntos de Funcin

La medida de punto de funcin se dise originalmente para aplicarse a aplicaciones de

sistemas de informacin de gestin. Para acomodar estas aplicaciones, se enfatiz la
dimensin de datos (los valores de dominios de informacin) para la exclusin de
dimensiones (control) funcionales y de comportamiento.
Por esta razn, la medida del punto de funcin era inadecuada para muchos sistemas de
ingeniera y sistemas empotrados (que enfatizan funcin y control). Para remediar esta
situacin se ha propuesto un nmero de extensiones a la mtrica del punto de funcin
bsica. Las mtricas del software orientadas a la funcin utilizan una medida de la
funcionalidad entregada por la aplicacin como un valor de normalizacin. Ya que
la funcionalidad>> no se puede medir directamente, se debe derivar
indirectamente mediante otras medidas directas.
Las mtricas orientadas a la funcin fueron propuestas por primera vez por Allan
Albretch. Una extensin del punto de funcin es la llamada puntos de caractersticas; es
una ampliacin de la medida del punto de funcin que se puede aplicar a sistemas y
aplicaciones de ingeniera del software. La medida de punto de caracterstica acomoda a
aplicaciones en donde la complejidad del algoritmo es alta. Las aplicaciones de software de
tiempo real, de control de procesos, y empotradas tienden a tener alta complejidad de
algoritmos y por lo tanto son adecuadas para el punto de caracterstica. Los puntos de
funcin se derivan con una relacin emprica segn las medidas contables (directas) del
dominio de informacin del software y las evaluaciones de la complejidad del software.
Los puntos de funcin se calculan completando la siguiente tabla:

Se determinan cinco caractersticas de dominios de informacin y se proporcionan las

cuentas en la posicin apropiada de la tabla. Los valores de los dominios de informacin se
definen de la forma siguiente:

Nmero de entradas de usuario. Se cuenta cada entrada de usuario que

proporciona diferentes datos orientados a la aplicacin. Las entradas se deberan
diferenciar de las peticiones, las cuales se cuentan de forma separada.
Nmero de salidas de usuario. Se cuenta cada salida que proporciona al usuario
informacin orientada a la aplicacin. En este contexto la salida se refiere a
informes, pantallas, mensajes de error, etc. Los elementos de datos particulares
dentro de un informe no se cuentan de forma separada.

Nmero de peticiones de usuario. Una peticin se define como una entrada

interactiva que produce la generacin de alguna respuesta del software inmediata en
forma de salida interactiva. Se cuenta cada peticin por separado.

Nmero de archivos. Se cuenta cada archivo maestro lgico (esto es, un grupo
lgico de datos que puede ser una parte de una gran base de datos o un archivo
independiente).

Nmero de interfaces externas. Se cuentan todas las interfaces legibles por la

mquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para
transmitir informacin a otro sistema.

Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de
complejidad. Las organizaciones que utilizan mtodos de puntos de funcin desarrollan
criterios para determinar si una entrada en particular es simple, media o compleja. [1]
Las mtricas orientadas a Puntos de Funcin se caracterizan por:
Tener un componente emprico, basado en la experiencia de muchos proyectos.
Tener en cuenta la complejidad, aunque es muy difcil de determinar en un proyecto

Ser independientes del entorno tecnolgico y de las metodologas aplicadas.

Utilizar medidas indirectas, que se caracterizan por ser subjetivas y difciles de

calcular, sin embargo el resultado obtenido es fcilmente comparable.

A continuacion podemos observar en un video como se desarolla y nos van guiando paso a
paso como lograrlo.
. Estimacin por Puntos de Funcin Grupo Sara Serrato Benigno Lozano Hernando
Camargo Leonardo Jimnez Moscovitz Bogot, Mayo de 2006 http://www.fukl.edu
FUNDACIN UNIVERSITARIA KONRAD LORENZ FACULTAD DE

MATEMTICAS E INGENIERAS PROGRAMA DE ESPECIALIZACIN EN

INFORMTICA Y CIENCIAS DE LA COMPUTACIN INGENIERA Y CALIDAD
DEL SOFTWARE Profesor: Bernardo Daz
2. Contenido
Qu son los Puntos de Funcin (PF)

Procedimiento de Estimacin de los Puntos de Funcin

Obtener Informacin del Sistema

Identificar los Componentes del Sistema

Calcular No. de Elementos y su Complejidad

Obtener los PF sin Ajustar (PFSA)

Obtener los PF Ajustados (PFA)

Clculo del Esfuerzo

Clculo de la Duracin del Proyecto

Clculo del Presupuesto del Proyecto

3. Qu son los Puntos de Funcin Es una mtrica que permite traducir en un nmero el
tamao de la funcionalidad que brinda un producto de software desde el punto de vista del
usuario, a travs de una suma ponderada de las caractersticas del producto. Componentes:
EI : Procesos en los que se introducen datos y que suponen la actualizacin de cualquier
archivo interno. EO: Procesos en los que se enva datos al exterior de la aplicacin. EQ:
Procesos consistentes en la combinacin de una entrada y una salida, en el que la entrada
no produce ningn cambio en ningn archivo y la salida no contiene informacin derivada.
ILF: Grupos de datos relacionados entre s internos al sistema. EIF: Grupos de datos que se
mantienen externamente.
4. Tabla de ponderaciones para EI, EQ y EO Una vez obtenidos los diferentes
elementos del sistema se utilizan las siguientes tablas para asignar pesos en funcin del
nmero de atributos que tengan y el nmero de archivos a los que afecte. Fundacin
Universitaria Konrad Lorenz
5. Tabla de ponderaciones para ILF y EIF
6. Proceso de Estimacin Mediante PF No. Entradas al Sistema (EI) No. Salidas del
Sistema (EO) No. Consultas BD (EQ) No. Ficheros (ILF - EIF) Factor Correccin por
Complejidad: No. Atributos de Entradas x Factor Correccin por Complejidad: No.
Atributos de Salidas x Factor... x Factor Correccin por Complejidad: No. Atributos de
Ficheros x + Puntos de Funcin Sin Ajustar Puntos de Funcin Ajustados Ajuste de
Complejidad Tcnica Estimacin del Esfuerzo Estimacin del Tiempo de Desarrollo Datos

de Productividad del Equipo Escala de 14 Factores de Complejidad Estimacin del

Presupuesto
7. Clculo de los Puntos de Funcin Sin Ajustar Por tanto los PFSA (Puntos de Funcin
Sin Ajustar) se calculan como la suma de los productos de cada componente por su peso
determinado en la tabla correspondiente. PFSA = PFTe + PFTo + PFTq + PFTif + PFTef
Componente Bajo Medio Alto Total EI Eb * 3 = _ Em * 4 = _ Ea * 6 = _ PFTe EO Ob * 4 =
_ Om * 5 = _ Oa * 7 = _ PFTo EQ Qb * 3 = _ Qm * 4 = _ Qa * 6 = _ PFTq ILF IFb * 7 = _
IFm * 10 = _ IFa * 15 = _ PFTif EIF EFb * 5 = _ EFm * 7 = _ EFa * 10 = _ PFTef PFSA
8. Descripcin de Totales por componente PFTe : Total Puntos de Funcin para las
entradas del sistema. PFTo : Total Puntos de Funcin para las salidas del sistema. PFTq:
Total Puntos de Funcin para las consultas del sistema. PFTif: Total Puntos de Funcin para
los archivos internos del sistema. PFTef: Total Puntos de Funcin para los archivos
externos del sistema.
9. Descripcin del problema ejemplo Para mostrar la mtrica de Puntos de Funcin se
tom como ejemplo las condiciones de un sistema de gestin de un hotel, en el cual se
tuvieron en cuenta los subsistemas, Gestin de cocina, Gestin de mostrador, Gestin de
administracin y la Gestin de configuracin del sistema. En este sistema se consideran 8
archivos internos (platos del men, pedidos de cocina, clientes, habitaciones, reservas,
estancias, configuracin y usuarios). El diagrama de contexto y el diagrama de flujo de
datos nivel 0 se describen a continuacin.
10. Obtener Informacin del Sistema Se requiere conocimiento global del sistema y
construir un Modelo de entidades primarias. Ejemplo: 1
11. Obtener Informacin del Sistema Se requiere conocimiento global del sistema y
construir un Modelo de entidades primarias. Ejemplo: 1
12. Identificar los Componentes del Sistema Identificar los Componentes del Sistema 2
A partir de:

Diagramas de Casos de Uso (UML)

Diagramas de Contexto o DFD (P. Estructurada)

Componentes a Identificar: Salidas Entradas Consultas Ficheros Lgicos Internos Ficheros

Externos
13. Calcular No. Elementos y su Complejidad Contar los Elementos de cada
Componente y su Complejidad 3 Componentes Identificados Salidas Entradas Consultas
Ficheros Lgicos Internos Ficheros Externos Cantidad Complejidad Cantidad Complejidad
14. Definicin de los Componentes del Sistema Salidas: 9 salidas de complejidad alta y
1 de complejidad media para el subsistema mostrador, 3 salidas de complejidad alta y 1 de
complejidad baja para el subsistema cocina, 2 salidas de complejidad baja, 4 salidas de
complejidad media y 3 salidas de complejidad alta para el subsistema administracin y slo
una salida de complejidad baja para el subsistema configuracin. Entradas: 9 entradas de
complejidad alta para el subsistema mostrador, 3 entradas de complejidad alta para el
subsistema cocina, 2 entradas de complejidad baja y 4 entradas de complejidad media para
el subsistema administracin y 4 entradas de complejidad baja para el subsistema
configuracin. Consultas: 2 consultas de complejidad baja para el subsistema mostrador, 3
consultas de complejidad baja para el subsistema cocina, 1 consulta de complejidad baja y
3 de complejidad alta para el subsistema administracin y finalmente una consulta de

complejidad baja para el subsistema configuracin. Ficheros Lgicos Internos: 8 almacenes

intermedios de datos de complejidad alta. Ficheros Externos: No se utilizaron almacenes
externos de datos.
15. Clculo de los Puntos de Funcin Sin Ajustar PFSA = PFTe + PFTo + PFTq + PFTif
+ PFTef PFSA = 106 + 146 + 39 + 15 + 0 = 306 PF Componente Bajo Medio Alto Total EI
6 * 3 = 18 4 * 4 = 16 12 * 6 = 72 106 EO 4 * 4 = 16 5 * 5 = 25 15 * 7 = 105 146 EQ 7 * 3
= 21 0 * 4 = 0 3 * 6 = 18 39 ILF 0 * 7 = 0 0 * 10 = 0 1 * 15 = 15 15 EIF 0 * 5 = 0 0 * 7 = 0
0 * 10 = 0 0 306
16. Obtener los PF Sin Ajustar Asignar los Puntos de Funcin a cada Componente de
acuerdo a las tablas 4 Componentes Identificados Salidas Entradas Consultas Ficheros
Lgicos Internos Ficheros Externos Cantidad Complejidad PFSA Tablas Correspondientes
a cada Componente
17. Obtener los PF Ajustados Obtener PF Ajustados 5 Componentes Identificados
Entradas PFSA = 306 PFA=PFSA* [0.65+[0.01*ACT]] Obtencin ACT Puntaje Factor de
Ajuste Min Max Comunicacin de Datos 0 5 Proceso Distribuido 0 5 Objetivos de
Rendimiento 0 5 Configuracin de Explotacin Compartida 0 4 Tasa de transacciones 0 5
Entrada de Datos en Lnea 0 5 Eficiencia con el Usuario Final 0 5 Actualizaciones en Lnea
0 5 Lgica de Proceso Interno Compleja 0 5 Reusabilidad del Cdigo 0 5 Conversin e
Instalacin contempladas 0 5 Facilidad de Operacin 0 5 Instalaciones Mltiples 0 5
Facilidad de Cambios 0 5
18. Obtener los PF Ajustados Obtener Ajuste de la Complejidad Tcnica 5 El sistema
para determinar la valoracin de uno de los Factores de Ajuste: Ej: Comunicacin de Datos:
Los datos usados en el sistema se envan o reciben por lneas de comunicaciones. La
valoracin para este factor se determina a travs de la eleccin de las siguientes
alternativas: a) 0 = Sistema Aislado del exterior (slo usuarios directos) b) 1 = Aplicacin
batch con entrada de datos remota o (exclusiva) utilizacin de perifricos de salida remotos.
c) 2 = Aplicacin batch con entrada de datos remota y utilizacin de perifricos de salida
remotos. d) 3 = Aplicacin de captura de datos En-Lnea o hay un sistema de teleproceso
que pasa los datos a la aplicacin batch o sistema de consulta. e) 4 = Varios teleprocesos
pero con el mismo protocolo de comunicaciones. (para el presente caso) f) 5 = Hay
teleproceso con varios protocolos de comunicacin. Sistema Abierto y con interfaces de
todo tipo al exterior. NOTA: (la sumatoria de las valoraciones de los 14 factores dar el
valor para el ACT N de Factor N de Factor Valor 0..5 1 Comunicacin de Datos 4 2
Proceso Distribuido 4 3 Objetivos de Rendimiento 1 4 Configuracin de Explotacin
Compartida 1 5 Tasa de transacciones 3 6 Entrada de Datos en Lnea 5 7 Eficiencia con el
Usuario Final 2 8 Actualizaciones en Lnea 3 9 Lgica de Proceso Interno Compleja 1 10
Reusabilidad del Cdigo 1 11 Conversin e Instalacin contempladas 0 12 Facilidad de
Operacin 1 13 Instalaciones Mltiples 2 14 Facilidad de Cambios 4 Ajuste de
Complejidad Tcnica (ACT) 32
19. Clculo del Esfuerzo Clculo del Esfuerzo 6 PFA = 296.82 Esfuerzo horas/persona
= PFA / [1 / 8 persona / hora)] = 296.82 / 0.125 = 2374.5 horas/persona LNEAS DE
CDIGO = PFA * (LINEAS POR PF) Cambiar horas/efectivas por horas productivas
estimadas Esfuerzo Entorno y Lenguaje Lneas de Cdigo por PF Horas por PF Lenguajes
2GL: Ensamblador, C, 300 20 a 30 Lenguajes 3GL: Cobol 100 10 a 20 Lenguajes 4GL:
VisualXX 20 5 a 10
20. Clculo de la Duracin del Proyecto Clculo de la Duracin del Proyecto 7
DURACIN DEL PROYECTO EN HORAS = 2374.5 horas/persona / 5 personas = 474.91

horas por miembro DURACIN EN MESES = 474.91 horas / 100 horas/mes = 4 meses 15
dias HORAS POR PERSONA = 2374.5 Horas/mes productivas estimadas en el proyecto
Calculadas de 20 das laborables y De 5 horas productivas estimadas de las 8 de la jornada
laboral normal diaria Se asigna la cantidad de participantes en el proyecto
21. Clculo del Presupuesto del Proyecto Clculo del Presupuesto del Proyecto 8 Costo
Total del Proyecto = sueldos 1 participante del proyecto * 5 participantes * 5 meses + Otros
costos necesarios durante la realizacin del proyecto = 2000 * 5 * 5 = 50000 DURACIN
DEL PROYECTO EN MESES = 5 meses Participante 1: Sueldo Participante 2: Sueldo
Participante n: Sueldo En la prctica se deben especificar Otros costos de operacin para
determinar el presupuesto total del proyecto
El Modelo COCOMO

1. Introduccin
El Modelo Constructivo de Costes (Constructive Cost Model) fue desarrollado por
B. W. Boehm a finales de los 70 y comienzos de los 80, exponindolo detalladamente en su
libro "Software Engineering Economics" (Prentice-Hall, 1981). COCOMO es una jerarqua
de modelos de estimacin de costes software que incluye submodelos bsico, intermedio y
detallado.
Las ecuaciones de estimacin del esfuerzo de desarrollo tienen la forma

con
S el nmero de miles de lneas de cdigo fuente
m(X) es un multiplicador que depende de 15 atributos
en la siguiente tabla se muestran los coeficientes para los diferentes modos

Modo
Orgnico
Semiencajado
Empotrado
2. Modelo Bsico

Bsico
ai
2.4
3.0
3.6

bi
1.05
1.12
1.2

Intermedio
ai
3.2
3.0
2.8

bi
1.05
1.12
1.2

Este modelo trata de estimar, de una manera rpida y ms o menos burda, la

mayora de proyectos pequeos y medianos. Se consideran tres modos de desarrollo en este
modelo: orgnico, semiencajado y empotrado.

2.1. Modo orgnico.

En este modo, un pequeo grupo de programadores experimentados desarrollan
software en un entorno familiar. El tamao del software vara de unos pocos miles de
lneas (tamao pequeo) a unas decenas de miles de lneas (medio), mientras que en los
otros dos modos el tamao vara de pequeo a muy grandes (varios cientos de miles de
lneas). En este modo, al igual que en los otros, el coste se incrementa a medida que el
tamao lo hace, y el tiempo de desarrollo se alarga.
Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de
desarrollo. El coste es
Km = 2.4 Sk1.05
donde Km se expresa en personas-mes y Sk es el tamao expresado en miles de
lneas de cdigo fuente. El tiempo de desarrollo se da por
td = 2.5 Km0.38
donde Km se obtiene de la ecuacin anterior y td es el tiempo de desarrollo en meses.
Estas ecuaciones se han obtenido por medio de ajustes de curvas realizado por Boehm en
TRW sobre 63 proyectos.

2.2. Modo Empotrado.

En este modo, el proyecto tiene unas fuertes restricciones, que pueden estar
relacionadas con el procesador y el interface hardware. El problema a resolver es nico y
es difcil basarse en la experiencia, puesto que puede no haberla.
Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el
modo orgnico, pero con diferentes constantes. As, el coste se da por
Km = 3.6 Sk1.20
y el tiempo de desarrollo por
td = 2.5 Km0.32

2.3. Modo Semiencajado.

Es un modo intermedio entre los dos anteriores. Dependiendo del problema, el
grupo puede incluir una mezcla de personas experimentadas y no experimentadas.
Las ecuaciones son
Km = 3.0 Sk1.12
y el tiempo de desarrollo por
td = 2.5 Km0.35.

2.4. Notas al Modelo Bsico

Se puede observar que a medida que aumenta la complejidad del proyecto, las
constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del
personal. Hay que utilizar con mucho cuidado el modelo bsico puesto que se obvian
muchas caractersticas del entorno.

3. Modelo Intermedio
En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno
de trabajo. Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno
real, incrementando la precisin de la estimacin.

3.1. Ecuaciones nominales de coste.

Para cada modo de desarrollo, los 15 atributos del coste intervienen como
multiplicadores en el coste nominal, Kn, para producir el coste ajustado.
Las ecuaciones nominales de coste para el modelo intermedio son
modo orgnico

Kn = 3.2 Sk1.05

modo semiencajado Kn = 3.0 Sk1.12

modo empotrado

Kn = 2.8 Sk1.20

Notemos que:
los exponentes son los mismos que los del modelo bsico, confirmando el papel
que representa el tamao;
los coeficientes de los modos orgnico y empotrado han cambiado, para mantener
el equilibrio alrededor del semiencajado con respecto al efecto multiplicador de los
atributos de coste.

3.2. Atributos de coste.

Estos atributos tratan de capturar el impacto del entorno del proyecto en el coste de
desarrollo. De un anlisis estadstico de ms de 100 factores que influencian el coste,
Boehm retuvo 15 de ellos para COCOMO.
Estos atributos se agrupan en cuatro categoras: atributos del producto, atributos del
ordenador, atributos del personal y atributos del proyecto.
(1) Atributos del producto
RELY: garanta de funcionamiento requerida al software
DATA: tamao de la base de datos
CPLX: complejidad del producto
(2) Atributos del ordenador
TIME: restriccin de tiempo de ejecucin
STOR: restriccin del almacenamiento principal
VIRT: volatilidad de la mquina virtual
TURN: tiempo de respuesta del ordenador
(3) Atributos del personal
ACAP: capacidad del analista
AEXP: experiencia en la aplicacin
PCAP: capacidad del programador

 VEXP: experiencia en mquina virtual

LEXP: experiencia en lenguaje de programacin
(4) Atributos del proyecto
MODP: prcticas de programacin modernas
TOOL: utilizacin de herramientas software
SCED: plan de desarrollo requerido.
Cada atributo se cuantifica para un entorno de proyecto. La escala es
muy bajo -- bajo -- nominal -- alto -- muy alto -- extremadamente alto.
En la tabla se muestran los valores del multiplicador para cada uno de los 15
atributos. Estos 15 valores se multiplican al Kn, y nos proporciona el esfuerzo ajustado al
entorno.

3.3. Significado de los atributos.

A. RELY
Indica las posibles consecuencias para el usuario en el caso que todava existan
defectos en el producto. Una puntuacin 'muy baja' indica que solamente hace falta
eliminar los defectos sin ninguna otra consecuencia.
"very low": el efecto de un fallo del software simplemente trae como consecuencia
la inconveniencia de corregir el fallo
"low": el efecto de un fallo software es una prdida fcilmente recuperable para los
usuarios
"nominal": el efecto es una moderada prdida para los usuarios, pero es una
situacin de la que se puede salir sin excesiva dificultad
"high": el efecto es una gran prdida financiera o una inconveniencia masiva
humana
"very high": el efecto es una prdida de vidas humanas.
B. DATA

Indica el tamao de la base de datos a desarrollar en relacin con el tamao del

programa. Tenemos cuatro segmentos con la razn 10-100-1000, que determinan las
puntuaciones de 'bajo' a 'muy alto'.
Se define por el cociente

donde D es la cantidad de datos a ser articulada y almacenada en memoria secundaria

(cintas, discos, etc.) hasta el tiempo de entrega del producto software.
C. CPLX
Indica la complejidad de cada mdulo y se utiliza para determinar la complejidad
compuesta del sistema. Entonces la puntuacin puede variar de 'muy bajo' si el mdulo est
compuesto de expresiones matemticas simples a 'extremadamente alto' para mdulos que
utilizan muchos recursos de planificacin.
D. TIME
Siempre ser ms exigente para un programador escribir un programa que tiene una
restriccin en el tiempo de ejecucin. Esta puntuacin se expresa en el porcentaje de
tiempo de ejecucin disponible. Es 'nominal' cuando el porcentaje es el 50%, y
'extremadamente alto' cuando la restriccin es del 95%.
E. STOR
Se espera que un cierto porcentaje del almacenamiento principal sea utilizado por el
programa. El esfuerzo de programacin se incremente si el programa tiene que correr en un
volumen menor del almacenamiento principal. STOR captura este esfuerzo extra de
'nominal' cuando la reduccin del almacenamiento principal es del 50% a 'extremadamente
alto' cuando la reduccin es del 95%.
F. VIRT
Durante el desarrollo del software la mquina (hard y soft) en la que el programa se
va a desarrollar puede sufrir algunos cambios. VIRT lo refleja desde 'bajo' a 'muy alto'.
G. TURN
Cuantifica el tiempo de respuesta del ordenador desde el punto de vista del
programador. Cuanto mayor sea el tiempo de respuesta, ms alto ser el esfuerzo humano.
TURN puede variar desde 'bajo' para un sistema interactivo a 'muy alto', cuando el tiempo
medio de respuesta es de ms de 12 horas.

H. ACAP
La capacidad del grupo de analistas, en trminos de habilidad de anlisis, eficiencia
y capacidad para cooperar tiene un impacto significativo en el esfuerzo humano. Cuanto
ms capaz sea el grupo, menos esfuerzo ser necesario. ACAP puede variar desde 'muy
bajo' a 'muy alto'.
I. AEXP
La experiencia del grupo en una aplicacin similar tiene una gran influencia en el
esfuerzo. Puede variar desde 'muy bajo' (menos de cuatro meses de experiencia) a 'muy
alto' (mayor de 12 aos de experiencia).
"very low": < 4 meses experiencia media
"low": 1 ao de experiencia media
"nominal": 3 aos de experiencia media
"high": 6 aos de experiencia media
"very high": > 12 aos, o reimplementacin de un subsistema
J. PCAP
La cuantificacin es similar a la de ACAP, pero en este caso relacionado con los
programadores. Se aplica a los programadores como grupo, pero no a los programadores
individuales.
K. VEXP
Cuanto mayor sea la experiencia del grupo de programacin con el procesador,
menor ser el esfuerzo necesario. VEXP puede variar desde 'muy bajo', cuando la
experiencia es menor de un mes, a 'alto' cuando esta experiencia es mayor de 3 aos.
"very low": < 1 mes experiencia media
"low": 4 meses
"nominal": 1 ao
"high": > 3 aos
L. LEXP

Un grupo de programadores con amplia experiencia en un lenguaje determinado

programar de una manera mucho ms segura, generando un menor nmero de defectos y
de requerimientos humanos. Puede variar desde 'muy bajo' a 'alto' para un grupo de un mes
a tres aos de experiencia, respectivamente.
"very low": < 1 mes experiencia media
"low": 4 meses de experiencia media
"nominal": 1 ao de experiencia media
"high": > 3 aos
M. MODP
Utilizacin de modernas prcticas de programacin. Vara de 'muy bajo' a 'muy
alto'. Estas prcticas incluyen, por ejemplo, programacin estructurada y desarrollo 'topdown'.
"very low": no se utilizan prcticas modernas de programacin -PMP-.
"low": uso experimental de algunas PMP
"nominal": experiencia razonable en el uso de algunas PMP
"high": experiencia razonable en gran parte de PMP
"very high": uso habitual de PMP

N. TOOL
El uso adecuado de herramientas software es un multiplicador de la productividad.
La puntuacin de TOOL vara desde 'muy bajo' cuando slo se utilizan herramientas
bsicas, a 'muy alto' cuando se utilizan herramientas especficas.
O. SCED
El tiempo nominal de desarrollo, tal como se define en el modo bsico, es el plazo
que requiere menor esfuerzo humano. Cualquier apresuramiento ('muy bajo') o retraso
('muy alto') demandarn ms esfuerzo.

3.4. Notas al modelo Intermedio.

Este modelo proporciona una manera potente de capturar la influencia del entorno
en el proyecto.

4. Modelo Detallado
Este modelo puede procesar todas las caractersticas del proyecto para construir una
estimacin. Introduce dos caractersticas principales
(1) Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se ven ms
afectadas que otras por los atributos. El modelo detallado proporciona un conjunto de
multiplicadores de esfuerzo para cada atributo. Esto ayuda a determinar la asignacin del
personal para cada fase del proyecto.
(2) Jerarqua del producto a tres niveles. Se definen tres niveles de producto. Estos
son mdulo, subsistema y sistema. La cuantificacin se realiza al nivel apropiado, esto es,
al nivel al que es ms susceptible la variacin.

4.1. Estimacin del esfuerzo.

A. Fases de desarrollo
El desarrollo del software se lleva a cabo a travs de cuatro fases consecutivas:
requerimientos/planes, diseo del producto, programacin y prueba/integracin.
Requerimientos/planes. Esta es la primera fase del ciclo de desarrollo. Se analiza el
requerimiento, se muestra un Plan de Producto y se general una especificacin completa
del producto. Esta fase consume del 6% al 8% del esfuerzo nominal Kn, y dura del 10% al
40% del tiempo nominal de desarrollo td. Estos porcentajes dependen del modo y del
tamao (de 2000 LOC a 512000 LOC).
Diseo del producto. La segunda fase del ciclo de desarrollo COCOMO se preocupa de la
determinacin de la arquitectura del producto y de las especificaciones de los subsistemas.
Esta fase requiere del 16% al 18% del esfuerzo nominal K n, y puede durar del 19% al 38%
del tiempo nominal de desarrollo td.
Programacin. La tercera fase del ciclo de desarrollo COCOMO se subdivide en dos
subfases: diseo detallado y prueba del cdigo. Esta fase requiere del 48% al 68% del
esfuerzo nominal Kn, y dura del 24% Al 64% del tiempo nominal de desarrollo.
Prueba/Integracin. Esta ltima fase consiste principalmente en unir las diferentes
unidades ya probadas. Se utiliza del 16% al 34% del coste nominal K n y dura del 18% al
34% del td.

B. Principio de estimacin del esfuerzo.

B.1. Tamao equivalente. Como parte del software puede haber sido ya
desarrollado, no se requiere entonces un desarrollo completo. En tales casos se estiman las
partes de diseo (D%), cdigo (C%) e integracin (I%) a ser modificadas. Se calcula un
factor de ajuste A
A = 0.4 D + 0.3 C + 0.3 I
El tamao equivalente, Sequ es
Sequ = (S A) / 100.
B.2. Clculo del esfuerzo. El tamao equivalente se calcula para cada mdulo. El
esfuerzo asignado al desarrollo de cada mdulo se obtiene entonces a travs de:
(1) seleccionar los valores apropiados de los atributos de coste para cada fase
(2) multiplicar los atributos de coste para cada mdulo y fase, obteniendo un
conjunto de 4 multiplicadores globales
(3) multiplicar los atributos globales por el esfuerzo nominal en cada fase y
sumarlos para obtener el esfuerzo total estimado.

5. Conclusiones sobre COCOMO.

Es uno de los modelos ms documentados en la actualidad y es muy fcil de
utilizar. Es correcto con referencia a los 63 proyectos utilizados, aunque de ello no se debe
desprender que deba ser vlido siempre. Una preocupacin es la adaptacin de las
ecuaciones exponenciales a organizaciones especficas, cosa que no parece inmediatamente
fcil.

6. Validacin independiente del modelo COCOMO (Conte et al.)

El rendimiento de COCOMO en su propia base de datos se indica en la tabla 6.13.
El COCOMO Bsico no funciona bien en su propia base de datos. El Intermedio lo hace
bastante mejor.
Es muy difcil evaluar COCOMO Intermedio en otras bases de datos debido a que
hay que proporcionar muchos parmetros. El modelo Bsico ha sido evaluado segn indica
la tabla 6.15, dando unos resultados pobres (quiz debido a la falta de datos). A
continuacin se indican unas frmulas mejoradas sobre las originales