COCOMO v2

Modelo de Estimación de Costes

para proyectos software

ANTONIO DE LA FUENTE MOYA

PROFESOR: Francisco Ruiz González Cuarto Curso
ASIGNATURA: Planificación y Gestión de Escuela Superior de Informática
Sistemas de Información Universidad de Castilla-La Mancha
MAYO 1999 Campus de Ciudad Real
Notas del Profesor sobre este trabajo

- El apéndice B (Calibración del modelo post-arquitectura no está incluida en este

documento.
- Algunas fórmulas tienen coeficientes que no coinciden con los utilizados en la
actualidad para el modelo COCOMO.

Consultar la página siguiente para información actualizada sobre los dos aspectos
anteriores:
http://sunset.usc.edu/research/COCOMOII/cocomo_main.html
 ÍNDICE

Página

ANOTACIONES 1

INTRODUCCIÓN

SITUACIÓN 2

INTRODUCCIÓN A LAS TÉCNICAS DE ESTIMACIÓN DE COSTES 3

+ PUNTOS FUNCIÓN 5
+ MODELO COCOMO 81 8
- Modelo Básico 9
- Modelo Intermedio 10
- Modelo Detallado 11
- Calibración del modelo 11
- Situación a principios de los 90 13

COCOMO v.2.0

INTRODUCCIÓN 14

COCOMO 2.0: FUNDAMENTOS Y ESTRATEGIA 15

+ ESTIMACIÓN DEL ESFUERZO DE DESARROLLO 17
- Número medio de Personas Mes 17
- Breakage 17
- Ajustando la Reusabilidad 17
- Ajustando la Conversión o Reingeniería 20
+ ESTIMACIÓN DE LA PLANIFICACIÓN TEMPORAL DE DESARROLLO 20
- Rangos de salida 21

ESCALA DE PRODUCTIVIDAD DEL SOFTWARE 22

+ ESCALANDO LOS PARÁMETROS 22
- Precedentes (PREC) y Flexibilidad de Desarrollo (FLEX) 23
- Resolución de Arquitectura/Riesgos 24
- Cohesión del Equipo de Trabajo 24
- Madured del Proceso (PMAT) 24

MODELO DE COMPOSICIÓN DE APLICACIÓN 26

+ PROCEDIMIENTO PARA CONTAR PUNTOS OBJETO 26

MODELO DE DISEÑO INICIAL 28

+ CUENTA DE PUNTOS FUNCIÓN 28
+ PROCEDIMIENTO DE CUENTA DE PUNTOS FUNCIÓN DESAJUSTADOS 29
+ CONVERSIÓN DE PUNTOS FUNCIÓN A LÍNEAS DE CÓDIGO 29
+ PARÁMETROS DE COSTE (COST DRIVERS) 30
- Aproximación global: Ejemplo de Capacidad Personal (PERS) 30
- Complejidad y Confianza del Producto 31
- Reutilización Requerida (RUSE) 32
- Inconvenientes de la plataforma (PDIF) 32
- Experiencia Personal (PREX) 32
- Facilidades (FCIL) 33
- Planificación (SCED) 33

i
 Página

MODELO POST-ARQUITECTURA 34
+ NORMAS PARA CONTAR LAS LÍNEAS DE CÓDIGO 34
+ PUNTOS FUNCIÓN 36
+ PARÁMETROS DE COSTE 36
- Factores del Producto 36
- Factores de la Plataforma 39
- Factores Personales 39
- Factores del Proyecto 40

GLOSARIO 42

Apéndice A: ECUACIONES 45
+ COMPOSICIÓN DE APLICACIONES 45
+ DISEÑO INICIAL 46
+ POST-ARQUITECTURA 47
+ ESTIMACIÓN DE LA PLANIFICACION 48

Apéndice B: Calibración del Modelo Post-Arquitectura 49

+ RESUMEN DEL MODELO POST-ARQUITECTURA 49
+ CALIBRACIÓN DEL MODELO 51
- Resultados de la Calibración del Esfuerzo 52
- Resultados de la Calibración de Planificación 54

ESTADO ACTUAL 55

BIBLIOGRAFIA 56

ii
ANOTACIONES

1. Se pretende dar una introducción suficiente, pero no abusiva (aunque esta

consideración siempre resulte subjetiva), para situar a quien lea este trabajo dentro
del significado y del mundo donde se utiliza el modelo COCOMO, recordándole
algunos conceptos y dejándolo al final de la introducción en condiciones suficientes
para comprender lo que significa y la utilidad de COCOMO.

2. Se ha perseguido que después de leer este documento, se comprenda el modelo

COCOMO 2.0, y se tenga la suficiente información para poder utilizar el software
que acompaña a este documento, y que no es sino una herramienta desarrollada
por la Universidad del Sur de California, para aplicar este modelo.

3. Más documentación, sobre manuales, métodos específicos de calibración del

modelo, etc podrá encontrarse en las referencias bibliográficas, al final de este
documento.

1
 SITUACIÓN

COCOMO (COnstructive COnst MOdel) es una herramienta utilizada para la

estimación de algunos parámetros (costes en personas, tiempo, ...) en el diseño y
construcción de programas y de la documentación asociada requerida para
desarrollarlos, operarlos y mantenerlos (Boehm), es decir, en la aplicación práctica de
la Ingeniería del Software.

Este desarrollo de software, y ante los problemas que se encuentran en él, hizo que
desde la década de los 70 creciera un interés en el estudio de los problemas que lleva
consigo el software, surgiendo conceptos como control de calidad (SQA),
metodologías de análisis y diseño, ingeniería del software, etc...

¿Cuáles son algunos de estos problemas que se encuentran en el desarrollo de

aplicaciones?:

- Incremento de la complejidad de los sistemas (mecanizar áreas más

amplias y complejas)

- Los proyectos nunca terminan en el plazo previsto. Las estimaciones se

realizan en un momento en el que no se tiene suficiente información o ésta
no se usa correctamente para poder determinar plazos.

- Los problemas más costosos se producen en las fases más tempranas del
desarrollo del software.

- Los costes de mantenimiento actualmente son muy elevados debido a la

continua evolución de los sistemas y a los errores en su concepción.

- Distinto vocabulario incluso dentro de los integrantes del propio equipo de

desarrollo informático.

- Cada diseñador utiliza una "forma de hacer" diferente para definir un

sistema de información.

- Riesgo inherente a que la definición de los sistemas la realicen técnicos

provisionales.

- Escasa implicación del usuario en las tareas de desarrollo de los nuevos

sistemas.

2
INTRODUCCIÓN A LAS TÉCNICAS
TÉCNICAS DE ESTIMACIÓN DE
COSTES

Debido a lo que se conoce como "crisis del software", con problemas como los
anteriormente descritos, comienza una preocupación por controlar los costes de
desarrollo, así como la distorsión de este desarrollo respecto a la planificación
establecida.

"Para llevar a cabo un buen proyecto de desarrollo de software, debemos

comprender el ámbito del trabajo a realizar, los recursos requeridos, las tareas a
ejecutar, las referencias a tener en cuenta, el esfuerzo (COSTE) a emplear y la
agenda a seguir." (R. Pressman)

Para intentar dar solución a estos problemas se han introducido en la Ingeniería del
Software una serie de técnicas, utilizadas dentro de las tareas de planificación, que
ayudan a planificar y controlar el esfuerzo y el tiempo necesario de desarrollo:

- Técnicas de estimación del esfuerzo (coste) de desarrollo. Dentro de las

cuales se sitúa COCOMO.

- Técnicas de planificación y seguimiento de proyectos.

El problema de realizar estimaciones es que en el instante en que se requiere dicha

estimación no se tiene suficiente información para que ésta tenga la exactitud
requerida.

No obstante, el desarrollo de software presenta un comportamiento característico

que puede ser analizado y empleado para planificar adecuadamente su desarrollo
dentro de unos límites de tiempo y coste razonables. Se necesita por tanto conocer:

- cómo se comportan los trabajos de desarrollo.

- qué factores pueden ser controlados.

- cuáles de éstos son determinantes para el proceso de desarrollo de un

proyecto.

Existen algunos trabajos que intentan desde un estudio estadístico de una muestra,
elegida de manera representativa, de un conjunto de casos reales, establecer modelos
básicamente empíricos, que ayuden a realizar dichas estimaciones con un mayor
grado de fiabilidad.

Tradicionalmente existían dos premisas básicas:

• los recursos humanos y el tiempo son variables intercambiables.

• el nivel de productividad, dentro de una organización, es relativamente

constante para todos los proyectos.

3
 Hoy en día ambas afirmaciones pueden considerarse erróneas o al menos
inexactas, ya que:

- el incremento del número de personas si aumenta su productividad, pero

también añade otras tareas como la integración de esas personas dentro
del grupo de trabajo que aumentan el global necesario.

- a su vez si el aumento de personas se realiza no al principio del proyecto,

sino durante la realización del mismo, hay que añadir el tiempo necesario
para poner al día a los nuevos integrantes del equipo.

- por último se ha demostrado que la productividad es, entre otros factores,

una función compleja del nivel de dificultad intrínseca de cada proyecto.

Por tanto la relación siguiente solamente es aplicable a proyectos de muy pequeño

tamaño.

Esfuerzo = Número de líneas de código / Productividad

Existen dos grandes orientaciones de medida del software:

- Función: Tipo de problema que resuelve.

- Tamaño: Volumen del software.

Dentro de la primera se sitúa la técnica de los Puntos de Función, de A. Albrecht

(1979) y de la segunda el modelo COCOMO (Constructive Const Model) de Barry
Boehm (1981).

La utilización de LDC (líneas de código) o DSI (delivered source instructions) es

discutida por algunos autores pues la consideran una medida poco consistente, la cual
presenta variaciones difícilmente ponderables:
- longitud
- dificultad
- cantidad de información y
- funcionalidad
- etc.
más aún si se trata de líneas escritas en distintos lenguajes.

Así, algunos investigadores de estos temas han llegado a decir, por ejemplo, que la
funcionalidad de una LDC PL1 es casi el doble que la de una COBOL, y que una de un
4GL proporciona entre dos y cuatro veces más funcionalidad que la de un lenguaje de
programación convencional.

El modelo COCOMO, aún basándose en una estimación de LDC, ha sido

ampliamente aceptado por:

• ser un modelo público bien documentado.

• debido a que los datos de entrada que solicita el modelo y sus resultados
son mucho más claros y precisos que en otros modelos.

• admite la posibilidad de calibrarse para entornos específicos.

4
PUNTOS FUNCIÓN.

Realizada por Allan Albercht en 1979 y revisada a continuación en 1983, esta

técnica está basada (orientada) en la teoría de la "ciencia del software" desarrollada
por Halstead, la cual está orientada al análisis del proceso de construcción de
programas y se basa en la medida del número de "unidades sintácticas básicas"
(operadores y operandos).

No se fija en el número de LDC sino en su funcionalidad.

La finalidad de la técnica de los puntos función es estimar el tamaño de un producto

software y el esfuerzo asociado a su desarrollo, expresado éste en horas trabajadas
por punto función, en las etapas previas a su desarrollo.

Los estudios realizados sobre la utilización de este método reflejan la bondad del
mismo y la existencia de un elevado grado de correlación entre el número de líneas de
código (LDC) y la estimación total de los puntos función.

Etapas del método:

1. Contar las funciones de usuario.

2. Ajustar el modelo en función de la complejidad del proceso.

1. Contar las funciones de usuario. En la etapa primera, se definen cinco tipos de

funciones de usuario:

• Entradas (al slstema): entradas de usuario que proporcionan al sistema

diferentes datos orientados a la aplicación.

• Salidas: salidas de usuario que le proporcionan a éste información sobre la

aplicación.
• Consultas: peticiones de usuario que como resultado obtienen algún tipo de
respuesta en forma de salida.

• Ficheros lógicos internos o archivos maestros: número de archivos lógicos

maestros (agrupación lógica de datos).

• Ficheros o interfaces externos: interfaces legibles (archivos de datos en

cinta o disco) utilizados para transmitir información a otros sistemas .

2. Ajustar el modelo en función de la complejidad del proceso. El recuento de las

funciones de usuario se realiza tras una clasificación previa de éstas en tres
niveles de complejidad:

• Simple
• Medio
• Complejo

Tras esta división de las funciones de usuario según su tipo y complejidad se les
aplica un peso, como aparece reflejado en la tabla adjunta, obteniendo el total de los
puntos función sin ajustar:

5
 Nivel de complejidad
Tipo de función Simple Medio Complejo Total
Entradas ___ x3= ___ ___ x4= ___ ___ x6= ___ _____
Salidas ___ x4= ___ ___ x5= ___ ___ x7= ___ _____
Ficheros lógicos internos ___ x7= ___ ___ x10= ___ ___ x15= ___ _____
Ficheros externos ___ x5= ___ ___ x7= ___ ___ x10= ___ _____
Consultas ___ x3= ___ ___ x4= ___ ___ x6= ___ _____

Total Puntos función sin ajustar CF=________

Valoraciones según el nivel de complejidad

La estimación del contador de puntos de función (CF) debe ajustarse valorando la

"complejidad del proceso", la cual puede variar dependiendo del entorno de desarrollo
y de las características propias de la aplicación.

Esta complejidad puede verse afectada según este método por catorce
características, las cuales se evalúan de conformidad a una escala de "grados de
influencia" que toma valores enteros comprendidos entre 0 (sin influencia alguna) y 5
(grado de influencia más elevado). Es decir:

Características GI
C1 Transmisión de datos ____
C2 Proceso distribuido ____
C3 Rendimiento, respuesta ____
C4 Configuración ____
C5 Indice de transacciones ____
C6 Entrada de datos on-line ____
C7 Eficiencia de usuario ____
C8 Actualización on-line ____
C9 Complejidad del proceso ____
C10 Reusabilidad ____
C11 Facilidad de instalación ____
C12 Sencillez en operación ____
C13 Adaptabilidad ____
C14 Flexibilidad
Total Grados de Influencia GI = ____
Características de la aplicación

Como resultado obtenemos los puntos de función ajustados.

PF = CF x (0,65 + (0,01 x GI)) PF: Puntos función ajustados

CF: Puntos función sin ajustar GI: Grados de influencia.

6
Ejemplo:

APLICACIÓN: ____________________________________ APL ID: _______________

PREPARADO POR: ___________ __/__/__ REVISADO POR: ___________ __/__/__
NOTAS:

RECUENTO DE FUNCIONES

Nivel de complejidad
Tipo de función Simple Medio Complejo Total
Entradas . x3= . . x4= . . 4 x6= 24 . . 24 .
Salidas . x4= . . 4 x5= 20 . . x7= . . 20 .
Ficheros lógicos internos . x7= . . x10= . . 6 x15= 70 . . 90 .
Ficheros externos . x5= . . x7= . . x10= . . .
Consultas . x3= . . 5 x4= 20 . . x6= . . 20 .
Total Puntos función sin ajustar CF = 154

COMPLEJIDAD DEL PROCESO

Características GI Características GI
C1 Transmisión de datos . . C8 Actualización on-line . .
C2 Proceso distribuido . . C9 Complejidad del proceso . .
C3 Rendimiento, respuesta . 4 . C10 Reusabilidad . .
C4 Configuración . . C11 Facilidad de instalación . .
C5 Indice de transacciones . 4 . C12 Sencillez de operación . .
C6 Entrada de datos on-line . . C13 Adaptabilidad . .
C7 Eficiencia de usuario . . C14 Flexibilidad . 5 .
Total Grados de Influencia GI 13 .

ESCALA DE GRADOS DE INFLUENCIA:

No influye = 0 Media = 3
Insignificante = 1 Significativa = 4
Moderada = 2 Fuerte = 5

FACTOR DE AJUSTE CP = 0,65 + (0,01) x GI = 0,78

TOTAL PUNTOS FUNCIÓN PF = CF x CP = 120
Nº LINEAS CODIGO I = 66 x PF = 7.920=8k

esto será para un lenguaje concreto

7
MODELO COCOMO'81 (Constructive Cost Model, versión de 1981)

Este fue presentado por Barry Boehm en 1981 y se convirtió en el más conocido y
referenciado, además del más documentado de todos los modelos de estimación de
esfuerzo de las actividades de diseño, codificación, pruebas y mantenimiento.

La versión inicial de COCOMO se obtuvo a partir de la revisión de los modelos de

costes existentes, en la cual participaron varios expertos en dirección de proyectos, los
cuales poseían además cierta experiencia en la utilización de diferentes modelos de
estimación.

Inicialmente se creó un modelo con un único modo de desarrollo, pero

posteriormente se vio que la aplicación del modelo a una amplia variedad de entornos
implicaba la creación de los tres modos de desarrollo:

• Orgánico. Proyectos de no más de 50 KLDC (50.000 LDC), sobre áreas

muy específicas y bien conocidas por el equipo participante.
• Semiempotrado (semilibre). El nivel de experiencia del equipo de
desarrollo se sitúa en niveles intermedios y suelen ser sistemas con
interfaces con otros sistemas, siendo su tamaño menor a 300 KLDC.
• Empotrado (restringido). Proyectos de gran envergadura, con una
exigencia de altos niveles de fiabilidad y en los que participan muchas
personas.

Por otra parte Boehm presenta una jerarquía de modelos de estimación según el
nivel de detalle empleado en su utilización:

• Básico. Modelo que calcula el esfuerzo de desarrollo como función del

tamaño estimado del software en LDC. Adecuado para realizar
estimaciones de forma rápida, aunque sin gran precisión.
• Intermedio. En éste el esfuerzo se calcula como función del tamaño del
producto, modificado por la valoración de los atributos directores del coste,
los cuales incluyen una valoración subjetiva del producto, del hardware, del
personal, etc. Los valores de los diferentes atributos se consideran como
términos de impacto agregado al coste total del proyecto.
• Detallado. En él la valoración de los atributos tiene en cuenta su influencia
en cada una de las fases de desarrollo del proyecto.

Las estimaciones relacionadas con el coste (esfuerzo) se expresan en meses-

hombre (tiempo que requeriría una sola persona para desarrollar el sistema),
considerando que la dedicación de una persona es de 152 horas al mes.

8
1. Modelo Básico.

Orgánico Semiempotrado Empotrado

1,05 1,12 1,20

Esfuerzo estimado ED=2,4(KLDC) h-m ED=3,0(KLDC) h-m ED=3,6(KLDC) h-m

0,38 0,35 0,32

Tiempo de desarrollo TD=2,5(ED) m TD=2,5(ED) m TD=2,5(ED) m

Productividad PR = LDC / ED
FSP (Full-Time equivalent Software Personel)
Nº medio de personas PE = ED / TD h
TCA (Tráfico de cambio anual): porción de instrucciones fuente que
sufren algún cambio durante un año, bien sea por adición o por
Esfuerzo modificación.
De EM = TCA x ED
Mantenimiento Y por tanto el valor medio del número de personas a tiempo completo,
dedicadas a mantenimiento durante 12 meses sería:
(PE)M = EM / 12
h=hombre, m=mes, h-m=hombres-mes

Ejemplo.
Un estudio inicial determina que el tamaño del producto estará alrededor de 32.000
LDC, a partir de las anteriores ecuaciones obtendríamos que las características del
proyecto serían:

Por el tamaño del producto a desarrollar vemos que debemos aplicar las ecuaciones
asociadas al modo orgánico, obteniendo lo siguiente:

ED = 2,4 (32)1,05 = 91 hombre-mes

TD = 2,5 (91)0,38 = 14 meses
PR = 32.000 / 91 = 352 líneas/hombre-mes
PE = 91 / 14 = 6,5 hombres

Tamaño Esfuerzo Productividad Tiempo PE

(líneas) (hombre-mes) (líneas/hombre-mes) (meses) (hombres)
Pequeño 2KS 5,0 400 4,6 1,1
Intermedio 8KS 21,3 376 8,0 2,7
Medio 32KS 91,0 352 14,0 6,5
Grande 128KS 392,0 327 24,0 16,0
Perfiles de proyectos estándares: Modo orgánico.

9
2. Modelo Intermedio.

Este modelo es una versión ampliada del modelo Básico, en la que se presenta
una mayor precisión en las estimaciones, manteniendo prácticamente la misma
sencillez del anterior modelo. Esta mayor precisión viene dada por la incorporación de
15 factores que reflejan la influencia de ciertos elementos sobre el coste del software.

El criterio para la elección de estos factores es generalidad e independencia. Es

decir, se eliminaron aquellos factores que solamente eran significativos de un pequeño
número de situaciones, así como aquellos otros que mostraban una fuerte correlación
con aspectos puntuales del desarrollo del software.

Finalmente estos 15 factores se agruparon en cuatro grandes grupos: Atributos del

Producto, del Computador, del Personal y del Proyecto.

Cada uno de estos 15 atributos tiene asociado un factor multiplicador para estimar
el efecto de éste sobre el esfuerzo nominal.

Orgánico Semiempotrado Empotrado

1,05 1,12 1,20

Ecuaciones del EN=3,2(KLDC) EN=3,0(KLDC) EN=2,8(KLDC)
esfuerzo nominal

Valor
Atributos Muy Bajo Nominal Alto Muy Extra
bajo alto alto
Atributos del producto
Fiabilidad ,75 ,88 1,00 1,15 1,40
Tamaño base de datos ,94 1,00 1,08 1,16
Complejidad ,70 ,85 1,00 1,15 1,30 1,65
Atributos del computador
Restricciones de tiempo de ejecución 1,00 1,11 1,30 1,66
Restricciones de memoria virtual 1,00 1,06 1,21 1,56
Volatilidad de la máquina virtual ,87 1,00 1,15 1,30
Tiempo de respuesta ,87 1,00 1,07 1,15
Atributos del personal
Capacidad de análisis 1,46 1,19 1,00 ,86 ,71
Experiencia en la aplicación 1,29 1,13 1,00 ,91 ,82
Calidad de los programadores 1,42 1,17 1,00 ,86 ,70
Experiencia en la máquina virtual 1,21 1,10 1,00 ,90
Experiencia en el lenguaje 1,14 1,07 1,00 ,95
Atributos del proyecto
Técnicas actualizadas de programación 1,24 1,10 1,00 ,91 ,82
Utilización de herramientas software 1,24 1,10 1,00 ,91 ,83
Restricciones de tiempo de desarrollo 1,23 1,08 1,00 1,04 1,10
Factores multiplicadores del esfuerzo de desarrollo de software

Esfuerzo total: ED = EN * ϑfi

donde fi se corresponde con los quince factores descritos
anteriormente.

10
 Si se observan los valores para el modelo Intermedio, se puede ver que los
coeficientes escalares (3'2, 3'0, 2'8) decrecen a medida que se incrementa la
complejidad del modo de desarrollo, al contrario que en el modelo Básico.

Esta diferencia indujo a Conte y otros a presentar un conjunto de ecuaciones

alternativas, cuyo comportamiento, según sus autores, mejora el de las ecuaciones
originales del modelo Intermedio:

Orgánico Semiempotrado Empotrado

1,08 1,12 1,20

Ecuaciones del EN=2,6(KLDC) EN=2,9(KLDC) EN=2,9(KLDC)
esfuerzo nominal

3. Modelo Detallado.

Este modelo presenta principalmente dos mejoras respecto al anterior modelo:

+ Los factores correspondientes a los atributos son sensibles a la fase sobre la

que se realizan las estimaciones, puesto que aspectos tales como experiencia
en la aplicación, utilización de herramientas software, etc, tienen mayor
influencia en unas fases que en otras.

+ Establece una jerarquía de tres niveles de productos, de forma que:

- los aspectos que presentan gran variación a bajo nivel, se
consideran a nivel módulo.
- los que presentan pocas variaciones a nivel de subsistema
- los restantes se consideran a nivel sistema.

Calibración del modelo.

El modelo puede ajustarse para mejorar la precisión de sus estimaciones, por las
características propias de una instalación particular.

Este proceso puede realizarse por diversos procedimientos, no excluyentes:

- calibrar las ecuaciones del esfuerzo nominal de acuerdo al comportamiento

del proyectos finalizados.

- consolidar o eliminar algunos de los atributos directores del coste.

- añadir otros atributos que pueden ser más significativos en la instalación en

particular.

Veamos cómo podría ser una posible calibración de las ecuaciones propuestas por
el modelo Intermedio para su modo orgánico:

11
1. Calibración de una constante:

ED = c (KLDC)1,05 * ϑ

Supongamos que en una instalación se han finalizado n proyectos cuyos tamaños

finales fueron KLDC1, ... KLDCn, los factores de ajustes empleados ϑ1, ... ϑn, y el
esfuerzo dedicado a cada uno de ellos E1, ... En. En este caso calcular la constante c
consiste en resolver el sistema de ecuaciones tal que la suma de cuadrados de esas
diferencias sea lo más pequeña posible.

E1 = c (KLDC1)1,05 ϑ1
E2 = c (KLDC2)1,05 ϑ2
............
En = c (KLDCn)1,05 ϑn

Así pues, planteamos la suma de cuadrados de las diferencias como:

15
E = 3 (c (KLDCi)1,05 ϑi - Ei)2
i=1

Haciendo

Qi = (KLDCi)1,05 ϑi

y sustituyendo
15
E = 3 (c Qi - Ei)2
i=1

para minimizar E calculamos su derivada e igualamos a cero:

0 = dE/dc = 2 3(cQi - Ei) Qi

de ahí puede despejarse la constante c como:

c = 3 E i Q i / 3 Q i2

2. Calibración de dos constantes:

Para realizar esta calibración puede aplicarse la misma técnica de aproximación

por mínimos cuadrados, teniendo en cuenta que ahora se desea determinar el término
multiplicador c y el factor de escala b de la ecuación de esfuerzo:

ED = c (KLDC)b * ϑ

Comencemos reescribiendo la ecuación tomando logaritmos:

ln(c) + b ln(KLDC) = ln(ED/ϑ)

12
 En este caso nos interesa minimizar

E = 3 ( ln(c) + b ln(KLDCi) - ln(Ei/ϑi) )2

Los valores óptimos de ln(c) y b pueden determinarse resolviendo el siguiente

sistema:

a0 ln(c) + a1b = d0
a1 ln(c) + a2b = d1

donde

a0 = n (número de proyectos)
a1 = 3 ln(KLDCi)
a2 = 3 ( ln(KLDCi) )2
d0 = 3 ln(Ei/ϑi)
d1 = 3 ln(Ei/ϑi) ln(KLDCi)

resolviendo obtenemos:

ln(c) = a2d0 - a1d0 / a0a2 - a12

b = a0d1 - a1d0 / a0a2 - a12

Situación a principios de los 90

Al inicial modelo de estimación de costes COCOMO 81, le siguió una actualización

para el lenguaje Ada en 1987, que recibió el nombre de Ada COCOMO. Desde
entonces el desarrollo de nuevos ciclos de vida, ocasionados por la evolución del
desarrollo del software, ha incrementado la dificultad de estas estimaciones. Y
estamos hablando de términos como desarrollo rápido de aplicaciones, aplicaciones
no secuenciales, reusabilidad del software, reingeniería, programación orientada a
objetos, etc.

13
 COCOMO 2.0

INTRODUCCIÓN .

Actualmente una nueva generación de procesos y productos software está

cambiando la forma en que las organizaciones desarrollan software, intentando ser
más competitivas. Estas nuevas aproximaciones -procesos software colaborativos,
evolucionarios, y centrados en los riesgos; generadores de aplicaciones y lenguajes de
cuarta generación; "comercial off-the-shelf" (COTS) y dependientes de la reutilización
que se deba hacer del software- llevan a significativos beneficios en términos de
calidad software y reducción de coste que supone su desarrollo, reducción de riesgos
y del tiempo de ciclo.

De cualquier forma, si bien alguno de los modelos de estimación de coste software

existentes poseen iniciativas que tienen en cuenta algunos de estos aspectos, estas
nuevas aproximaciones no han sido tenidas en cuenta suficientemente hasta hace
pocos años por los nuevos modelos de estimación de costes y planificación. Esto hace
que sea difícil a las organizaciones realizar una planificación, análisis y control de
proyectos de manera efectiva y utilizando las nuevas aproximaciones.

Estos argumentos han llevado a realizar una nueva formulación del modelo
COCOMO, sucesor de los anteriores COCOMO 81 de Boehm (1981) y el COCOMO
Ada de Royce (1989).

OBJETIVOS:

Los principales objetivos de COCOMO 2.0 son:

1. El desarrollo de un modelo de estimación de costes y planificación que pudiera ser

utilizado en el ciclo de vida de la década de los 90 y posterior al 2000.

2. Desarrollar una base de datos indicativa del coste del software y un soporte de
herramientas con la capacidad suficiente para el continuo progreso y
perfeccionamiento del modelo.

3. Proporcionar un cuantioso y analítico marco de trabajo, y un conjunto de

herramientas y técnicas para la evaluación de los efectos que la tecnología
software tiene sobre el coste de los ciclos de vida software y de planificación.

Las principales capacidades de COCOMO 2.0 son los ajustes a medida

dependiendo del software a desarrollar, involucrando en la estimación del coste a los
puntos objeto (object points), puntos función (function points) y líneas de código
fuente; utilizando modelizaciones no lineales para atender a la reingeniería y
reusabilidad del software, ... y todo esto sobre la base del anterior COCOMO.

14
COCOMO 2.0 : FUNDAMENTOS Y ESTRATEGIA .

Los cuatro elementos principales de la estrategia de COCOMO 2.0 son:

1. Preservar las habilidades y apertura del modelo original, para que continúe siendo
un modelo abierto y público (algoritmos, parametrizaciones, etc...)

2. Adaptar la estructura de COCOMO 2.0 a los futuros sectores del mercado software
descritos antes.

3. Adaptar las entradas y salidas de los submodelos de COCOMO 2.0 al nivel de

información disponible en cada etapa.

4. Permitir a los submodelos de COCOMO 2.0 ajustarse a la medida dependiendo de

la estrategia utilizada en cada proyecto particular (atender a las distintas
calibraciones de los submodelos que se utilicen para obtener mayor fiabilidad en la
estimación global).

Un fundamento importante es el considerar la granularidad del modelo de

estimación de coste, teniendo en cuenta la información disponible que sirve de soporte
al modelo, entendiendo que en las primeras etapas del proyecto software se conocen
muy pocas cosas sobre el tamaño del producto a ser desarrollado, la naturaleza de la
plataforma objetivo, la naturaleza del personal involucrado en el proyecto, o los
detalles específicos del proceso que se utilizará.

La siguiente figura indica el efecto de las incertidumbres del proyecto tienen sobre
la precisión del tamaño del software y la estimación del coste. En los primeros
estados, al comienzo, no puede conocerse la naturaleza específica del producto a
desarrollar con una aproximación mayor de un factor 4. Según el ciclo de vida avanza,
y se realizan decisiones sobre el producto, la naturaleza del producto y su
consecuente tamaño son mejor conocidos, y la naturaleza del proceso y sus
consecuentes parámetros de coste son mejor conocidos:

Figura 2. Precisión de tamaño y coste software dependiendo de la fase en que se encuentre el proceso.

15
 COCOMO 2.0 permite a los proyectos suministrar a los parámetros de coste una
información rudamente granulada en los primeros estados del proyecto, para ir
incrementandola más detalladamente granulada según se avanza en los estados.

Resumiendo, el modelo COCOMO 2.0 proporciona los siguientes 3 estados (series

de modelos) para la estimación de Generadores de Aplicaciones, Integración de
Sistemas, e infraestructura de proyectos software:

1. En las primeras fases o ciclos espirales que generalmente incluirán prototipado, se

hacen uso de las capacidades del Modelo de Composición de Aplicaciones.
Este modelo soporta estas fases, y cualquiera otras actividades de prototipado que
suceden con posterioridad en el ciclo de vida.

Incluye pues tareas de prototipado para resolver cuestiones como el diseño de

los inferfaces de usuario, la interacción del software con el sistema, el rendimiento
o la madured de la tecnología empleada. Asi, los costes de este tipo de esfuerzo
son mejor estimados por un modelo de composición de aplicaciones..

Nos encontramos pues en una situación donde existen aplicaciones muy

diversas, tanto que no se manejan como paquetes integrados de soluciones, pero
que son lo suficientemente simples para ser rápidamente acopladas y de
interoperar sus componentes.

Como veremos posteriormente, el modelo COCOMO se basa en Puntos Objeto

para modelizar la Composición de Aplicaciones, y es una cuenta de las pantallas,
informes y módulos desarrollados con lenguajes de tercera generación, cada uno
con un peso según la complejidad del parámetro (mínimo, medio, alto). Esto
mantiene una equivalencia con el nivel de información de la que generalmente se
dispone, sobre esta composición de aplicaciones, durante sus estados de
planificación temporal, y el correspondiente nivel de precisión necesaria para
estimar el coste software.

2. Las siguientes fases o ciclos espirales que generalmente incluyen la exploración

de arquitecturas alternativas o estrategias de desarrollo incrementales. Para
soportar estas actividades, COCOMO 2.0 proporciona un temprano modelo
llamado Modelo de Diseño Inicial. Este nivel de detalle en este modelo es
consistente con el nivel general de información disponible y con el nivel general de
estimación detallada que es necesaria en esta etapa.

Se utilizan, como veremos, puntos función y/o instrucciones fuente, y un

pequeño número de parámetros de coste (cost drivers).

3. Una vez que el proyecto esta listo para ser desarrollado se debería tener una
arquitectura de ciclo de vida, la cual proporcionase más información detallada
sobre las entradas de los parámetros de coste, y permitieses mayor precisión en la
estimación del coste. Para soportar esta etapa, COCOMO 2.0 proporciona el
Modelo Post-Arquitectura.

Incluye este modelo el desarrollo y mantenimiento último del producto software.

Se utilizan, como veremos, instrucciones fuente y/o puntos función para la
estimación, existiendo modificadores que los operan; un conjunto de 17 factores
multiplicativos de evaluación de coste, y un total de 5 modos para dimensionar el
proyecto, que sustituyen a los anteriores modos Orgánico, Semiempotrado y
Empotrado del COCOMO original.

16
 Un análisis de los datos debería permitir también la calibración de las relaciones
entre puntos objeto, puntos función, y líneas de código fuente para varios lenguajes y
composición de sistemas, permitiendo mayor flexibilidad al elegir los parámetros que
influyen en la clasificación del tamaño.

ESTIMACIÓN DEL ESFUERZO DE DESARROLLO.

COCOMO 2.0 expresa el esfuerzo en terminos de Personas Mes (PM). Todas las
ecuaciones del esfuerzo están representadas en el apéndice A. Una persona mes es
la cantidad de tiempo que una persona dedica a trabajar sobre el proyecto de
desarrollo software durante un mes. El número de personas mes es diferente del
tiempo que tomará el proyecto para ser completado; a esto se le llama planificación de
desarrollo. Por ejemplo, un proyecto puede estimarse en requerir 50 PM de esfuerzo,
pero tener una planificación temporal de 11 meses.

Número nominal de Personas Mes.

La siguiente ecuación es la base de los modelos de Diseño Inicial y Post-

Arquitectura. Las entradas son el tamaño del desarrollo software, una constante A, y
un factor de escala B. El tamaño se dan en miles de líneas de código fuente (KSLOC).
Pudiéndose estimar también utilizando Puntos Función Desajustados (UFP), y
convertirlos a SLOC dividiendo por mil.

El factor de escala (o exponencial) B, cuenta la relativa economía, positiva o

negativa, de la escala encontrada en proyectos software según cambie el tamaño de
éste.

La constante A es usada para capturar los efectos multiplicativos sobre el esfuerzo

con proyectos que incrementan su tamaño.

PMnominal = A x (Size)B Ecuación 1

Breakage.

El Modelo COCOMO 2.0 utiliza un porcentaje del código "breakage" (BRAK) para
ajustar el tamaño efectivo del producto. El término Breakage hace referencia a la
volatilidad de los requerimientos de un proyecto. Esto es, el porcentaje de código que
se desecha. Por ejemplo, un proyecto formado finalmente por 100.000 instrucciones
de las que se han descartado otras 20.000 instrucciones adicionales, entonces BRAK
tendrá un valor de 20. Esto debería usarse para ajustar el tamaño efectivo del proyecto
a 120.000 instrucciones. Ese factor BRAK no se utiliza en el modelo de Composición
de Aplicaciones, donde se espera un cierto grado de interacción del producto, incluida
una calibración de los datos.

Ajustando la reusabilidad.

Efectos no lineales: Selby realiza un análisis sobre cerca de 3000 módulos

reutilizables, en el Laboratorio de Ingeniería Sofware de la NASA, de cómo influye la

17
reutilización del código, y como resultado indica que este coste queda expresado por
una función no lineal, debido a dos razones principales:

• No se comienza desde el principio. Existe un coste alrededor del 5% debido

a la valoración, selección y asimilación que debe hacerse del componente
reutilizable.

• Pequeñas modificaciones producen desproporcionadas reacciones en el

coste. Esto es debido principalmente a dos factores: el coste de
comprender el software que va a ser modificado, y el relativo coste
asociado a testear el interface.

Estudios realizados determinan que el 47% del esfuerzo de mantenimiento del

software está directamente relacionado con la comprensión del software que se
modifica. También se demuestra que si se modifican k de m módulos, el número N que
indica los interfaces de módulos que son chequeadas es N = k * (m-k) + k *x (k-1) / 2.
Relación que se muestra la Figura 4, donde la curva demuestra la mencionada
relación no lineal.

Siempre teniendo en cuenta que el tamaño que supone este tiempo de comprensión
del software y de chequeo del interface puede ser reducido mediante una buena
estructura sofware.

18
Un modelo para tener en cuenta la reusabilidad: el modelo COCOMO 2.0 trata esta
reutilización del software usando un modelo de estimación no lineal. Esto incluye una
estimación de la cantidad de software a ser adaptado, ASLOC, y tres parámetros
según el grado de modificación: porcentaje de diseño modificado (DM), porcentaje de
código modificado (CM), y porcentaje del esfuerzo original que supone integrar el
software reutilizable (IM).

El incremento que supone la comprensión del software (SU) se obtiene de la

siquiente tabla; y expresado cuantitativamente como un porcentaje.

Muy Bajo Bajo Nominal Alto Muy Alto

Estructura Muy baja Moderada baja Razonablement Alta cohesión, Enormemente
cohesión, alto cohesión, alto e bien bajo modular,
acoplamiento, acoplamiento. estructurado; acoplamiento. Información
definición poco algunas áreas ocultada
clara del resultan mediante
código. débiles. estrucuras de
datos y control.
Claridad de la No existe una Existe alguna Moderada Buena Existe una clara
Aplicación clara identidad correlación correlación correlación relación entre
entre las entre el entre el entre ambos. las visiones
visiones del programa y la programa y la globales de
programa y de aplicación. aplicación. ambos
la aplicación. (programa y
aplicación).
Descripción Código obtuso; Existen algunos Un moderado Bien Código
implícita la comentarios en nivel de comentado el autodescriptivo,
documentación el código y comentarios en código, documentación
o no existe o alguna el código, y documentación actualizada,
resulta oscura u documentación documentación. útil, aunque bien organizada
obsoleta. útil. débilmente en y con un diseño
algunas áreas. racional.
Incremento de 50 40 30 20 10
SU en ESLOC
Tabla 1: Escala según se Incrementa la Compresión del Software (SU).

El otro incremento no lineal sobre la reusabilidad tiene que ver con el grado de
Valoración y Asimilación (AA) necesarias para determinar si un cierto módulo software
completamente reutilizable es apropiado para la aplicación, e integrar su descripción
dentro de la descripción global del producto. La Tabla 2 siguiente proporciona una
escala para este porcentaje:

Incremento de AA Nivel de esfuerzo AA

0 Ninguno.
2 Una básica búsqueda modular y de documentación.
4 Alguna Evaluación y Chequeo modular, documentación.
6 Una considerable Evaluación y Chequeo modular, documentación.
8 Una gran Evaluación y Chequeo modular, documentación.
Tabla 2: Escala según el incremento de Valoración y Asimilación (AA).

Finalmente la ecuación usada para determinar esta reusabilidad es:

Ecuación 2

19
Ajustando la Conversión o Reingeniería.

El modelo COCOMO 2.0 necesita de un refinamiento adicional para estimar el

coste de la reingeniería software y conversión. La mayor diferencia viene por la
eficiencia de las herramientas automatizadas para la reestructuración del software,
que permiten que a un alto porcentaje de código modificado le corresponda un
pequeño esfuerzo.

Para realizar esta estimación se incluye un parámetro adicional, AT, que indica el
porcentaje de código que es tratado en esta reingeniería mediante translación
automática:

Ecuación 3

Ajustando Personas Mes.

Los parámetros de coste (cost drivers) son utilizados para capturar características
del desarrollo del software que afectan al esfuerzo para completar el proyecto. Estos
parámetros de coeste expresan el impacto del parámetro sobre el esfuerzo de
desarrollo, en Personas Mes (PM). Este rango va de Muy Bajo a Extra Alto, y tiene un
peso asociado según el rango al que pertenezca cada parámetro. Este peso es
llamado multiplicador de esfuerzo (EM), siendo la media asignada a cada uno de 1'0
(rango medio o nominal). Este valor será mayor que 1'0 si influye incrementando el
esfuerzo, y menor que 1'0 si lo disminuye.

Existen 7 de estos multiplicadores de esfuerzo en el modelo de Diseño Inicial, y 17

en el modelo Post-Arquitectura.

Ecuación 4

ESTIMACIÓN DE LA PLANIFICACIÓN TEMPORAL DE DESARROLLO.

La ecuación base inicial para mostrar la planificación para los tres estados de
COCOMO 2.0 es:

Ecuación 5

20
donde TDEV es un calendario temporal expresado en meses, utilizado para determinar
que los requerimientos del producto se han completado y que quedan certificados. PM
"negado" indica la estimación Personas-Mes excluyendo el multiplicador de esfuerzo
SCED. B es la suma de los factores exponentes de escala.

Rangos de salida.

Los tres estados del modelo COCOMO 2.0 permiten que la estimación sea
expresada dentro de un rango de valores, que teniendo en cuenta la Figura 2 de
"Precisión de tamaño y coste de software según la fase en que se encuentra el
proyecto" expresa el resultado E (esfuerzo estimado) como un conjunto de
estimaciones pesimitas y optimistas.

Estado Estimación Optimista Estimación Pesimista

1 050 E 2'00 E
2 0'67 E 1'50 E
3 0'80 E 1'25 E
Tabla 4.Rangos de salida.

21
ESCALA DE PRODUCTIVIDAD DEL SOFTWARE.

Los modelos de estimación de coste software a menudo poseen un factor

exponencial que cuenta lo favorable o desfavorable que es económicamente un
proyecto dependiendo de cómo varie su tamaño. El exponente B de la Ecuación 1 se
utiliza para capturar estos efectos.

Si B < 1'0 el proyecto muestra una escala positiva, económicamente favorable, de

tal forma que si el tamaño del producto se duplicase, el esfuerzo resultante seria
menor del doble. Es decir, la productividad del proyecto se incrementa conforme el
tamaño del producto aumenta.

Si B = 1'0, el proyecto está economicamente equilibrado. Este modelo lineal es

usado frecuentemente para realizar estimaciones en pequeños proyectos. Usado en el
modelo de Composición de Aplicaciones.

Si B > 1'0 el proyecto muestra una escala negativa, economicamente desfavorable,

debido generalmente a dos razones principales: crecimiento de las comunicaciones
interpersonales que lo desbordan, y crecimiento de la integración de sistemas
grandes, que igualmente desborda. En el sentido de que proyectos grandes
necesitarán de más personal, y a más personal mayor comunicación que se requiere,
no olvidando que incluso aunque un proyecto grande se organiza en pequeños
subproyectos que necesitan un esfuerzo menor, se requiere un esfuerzo adicional para
diseñar, mantener, integrar y testear todos estos productos por separado y luego
globalmente.

Ya el análisis de datos del COCOMO original indicaba que los proyectos mostraban
una escala desfavorable económicamente, así existian ya tres clases de modelos de
desarrollo software (Orgánico, Semiempotrado, y Empotrado), cada uno con un
exponente distinto (B=1'05, B=1'12, B=1'20 respectivamente).

La distinción entre los factores de estos modelos básicamente concierne al entorno:

proyectos en modo empotrado tuvieron menos precedentes, requiriendo mayor
saturación de comunicaciones así como una integración compleja, son menos
flexibles, ...

ESCALANDO LOS PARÁMETROS.

La Ecuación 6 define el cálculo de este exponente B, utilizado ya en la Ecuación 1.

La Tabla 19 proporciona una valoración por niveles para estos parámetros de escala
del COCOMO 2.0. Cada uno de estos parámetros se divide en un rango según el
nivel, que va desde Muy Bajo a Extra Alto. Cada uno de estos rangos tiene un peso
(W). Los factores de escala de un proyecto se suman para determinar el exponente de
escala B, mediante la siguiente fórmula

B = 1'01 + 0'01 * Σ W i Ecuación 6

Por ejemplo si a la escala Extra Alta le asignamos el peso cero, entonces un

proyecto con 100KSLOC con todos sus factores de escala en el rango "Extra Alto"
tendrán W i=0, y B=1'01, y un esfuerzo relativo E=1001'01 =105 PM. Si por el contrario
los factores, todos, están en el rango "Muy Bajo", asignamos un peso de 5 a cada uno,
teniendo W i=25 y B=1'26, y un esfuerzo relativo E=331 PM. Aunque esto representa

22
una gran variación, el incremento provocado por un cambio en un único parámetro
representa tan sólo el 4'7%.

Factor de Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
Escala (Wi) (5) (4) (3) (3) (1) (0)
PREC Mínima Poca Algo Medianamente Muy familiar Altamente
familiar familiar
FLEX Poca o Ocasional Alguna alta Muy alta Tendiendo a
ninguna (muy optima (metas
riguroso) generales)
RESLa Reducción del Idem 40% Idem 60% Idem 75% Idem 90% Idem 100%
riesgo entorno
al 20%
TEAM Interacciones Algunas Interacciones Muy Altamente Cooperación
muy dificiles interacciones para una cooperativo cooperativo óptima
dificiles cooperación
básica
PMAT
peso medio de las respuestas afirmativas en el cuestionario Madured CMM
Tabla 5. Escala de Factores para los modelos de Diseño Inicial y Post-Arquitectura.

Precedentes (PREC) y Flexibilidad de Desarrollo (FLEX).

Estos dos escalas de factores capturan en gran medida las diferencias entre los
modos, del COCOMO original, Orgánico, Semiempotrado y Empotrado. La Tabla 6
reorganiza las características de un proyecto en estos términos. Esta tabla puede ser
usada para más de una profundidad de exploración para los factores PREC y FLEX
dados por la Tabla 19.

Característica Muy Baja Nominal / Alta Extra Alta

Precedencias
Objetivos del producto y
comprensión General Considerable Profundo
organizacional
Experiencia trabajando
con sistemas software Moderada Considerable Extensiva
relacionados
Desarrollo concurrente
asociado a nuevo
hardware y nuevos Extensivo Moderado Alguno
procedimientos
operacionales
Necesidad para la
innovación en Considerable Alguno Minimo
arquitecturas de proceso
de datos , algoritmos
Flexibilidad de desarrollo
Necesidad de que el
sofware se ajuste a los Completo Considerable Básico
requerimientos
preestablecidos
Necesidad de que el
sofware se ajuste a las Completo Considerable Básico
especificaciones de
interface externos
Prima para un desarrollo
completo inicial Alto Medio Bajo

Tabla 6: escala de Factores relacionados con los modos de desarrollo de COCOMO

23
Resolución de Arquitectura/Riesgos (RESL).

Este factor combina a dos de los factores de escala del modelo Ada COCOMO:
"Diseo minucioso mediante examen del Diseño del Producto (PDR)", y "Eliminación de
riesgos mediante PDR". La Tabla 7 consolida estos factores del modelo Ada
COCOMO para formar una definición más comprensiva de los niveles de valores
RESL en COCOMO 2.0. Esta valoración del RESL es una medida de los pesos
subjetiva.

Cohesión del Equipo de Trabajo (TEAM).

El factor de escala de Cohesión del Equipo cuenta las fuentes que originan
turbulencias y entropia en el proyecto debido a las dificultades de sincronización:
usuarios, clientes, desarrolladores, personal encargado del mantenimiento, interfaces,
otros. Estas diferencias pueden deberse a diferencias culturales, dificultades para
reconocer objetivos, hasta familiaridad para trabajar en equipo. La Tabla 8 proporciona
una definición detallada para el conjunto completo de niveles TEAM. La valoración
final es la media subjetiva de los pesos.

Madured del Proceso (PMAT)

El procedimiento para determinar PMAT se organiza mediante 18 claves e área de

proceso (KPAs) por el Modelo de Capacidad de Madured, del SEI. Este procedimiento
que determina PMAT decide el porcentaje de conformidad para cada uno de los KPAs.

24
 • Casi siempre: cuando los objetivos son consistentemente alcanzables y bien establecidos en
procedimientos operativos estándar.
• Frecuentemente: cuando los objetivos son alcanzables con relativa frecuencia, pero en
algunas ocasiones son emitidas bajo circunstancias difíciles (entre el 60% y 90% de las
veces).
• Sobre la mitad: cuando los objetivos son alcanzables sobre la mitad de las veces (entre el
405 y 60% de las veces).
• Ocasionalmente: cuando los objetivos son alcanzados algunas veces, pero poco frecuentes
(entre el 10% y 40% de las veces).
• Raramente (si acaso): cuando los objetivos raramente son alcanzados (menos del 10% de
las veces).
• No se aplica: cuando se tiene el conocimiento requerido sobre el proyecto u organización y
el KPA, pero se tiene un sentimiento de que los KPAs circunstancialmente no se pueden
aplicar.
• Se desconoce: cuando no se tiene certeza de cómo responderán los KPAs.

Después de que el nivel de KPA es determinado, a cada nivel de conformidad se le

asigna un peso o valor y el factor PMAT queda calculado:

Ecuación 7

25
MODELO DE COMPOSICIÓN DE APLICACIÓN.

Este modelo está dirigido a aplicaciones que están demasiado diversificadas como
para crear rápidamente una herramienta específica dentro de un dominio. Ejemplos de
estos sistemas basados en componentes son los generadores de interfaces de usuario
(GUI), gestores de objetos o bases de datos, procesamiento distribuido o de
transacciones, manejadores hipermedia, pequeños buscadores de datos, y
componentes de un dominio específico tales como domínios financieros, médicos, o
paquetes de control de procesos industriales.

Objeto de este estudio son estos sistemas que se caracterizan por llevar asociados
esfuerzos de prototipado, uso de ICASE (CASE integrado) para obtener una
composición rápida asistida por la computadora, que proporcionan generadores de
interfaces gráficos de usuario, herramientas de desarrollo software, y un largo número
de componentes de aplicaciones e infraestructuras. En estas áreas se ha demostrado
el buen funcionamiento de los Puntos Función para realizar estimaciones sobre un
conjunto no trivial de aplicaciones.

Estudios experimentales realizados demuestran que tanto el uso de Puntos

Función como de Puntos Objeto dan unas estimaciones muy próximas, si bien el
método de los Puntos Objeto resulta más fácil de utilizar.

PROCEDIMIENTO PARA CONTAR PUNTOS OBJETO

Definición de términos:

• NOP: Nuevos Puntos Objeto (cuenta de los Puntos Objeto ajustados para
su reutilización).
• srvr: número de servidores de datos (mainframes o equivalentes).
• clnt: número de clientes de datos (estaciones de trabajo personales).
• %reutilización: porcentaje de pantallas, informes y módulos 3GL
reutilizados por aplicaciones previas, según su grado de reutilización.

Pasos:

1. Estimar el número de pantallas, informes, y componentes 3GL que comprenderán

la aplicación. Asumiendo las definiciones estandar de estos objetos en el entorno
ICASE utilizado.

2. Clasificar cada instancia de cada objeto en niveles de complejidad simple, media o

alta, dependiendo de los valores según la dimensión. Utilizar el siguiente esquema:

Pantallas Informes
Número Total < 4 Total < 8 Total 8+ Número Total < 4 Total < 8 Total 8+
de de
vistas ( <2 srvr ( 2-3 ( >3srvr seccion ( <2 srvr ( 2-3 ( >3 srvr
que <3 clnt ) srvr >5 clnt ) es que <3 clnt ) srvr >5 clnt )
contiene 3-5 clnt ) contiene 3-5 clnt )
<3 Simple Simple Medio 0o1 Simple Simple Medio
3-7 Simple Medio Alto 2o3 Simple Medio Alto
>8 Medio Alto Alto 4+ Medio Alto Alto

26
3. Valorar con un peso (número) como los mostrados en la siguiente tabla, ue
reflejan el esfuerzo relativo requerido para implementar una instancia de
ese objeto dependiendo del nivel de complejidad:

Complejidad
Tipo de Objeto Simple Media Alta
Pantalla 1 2 3
Informe 2 5 8
Componente 3GL 10

4. Sumar todos los pesos de los objetos instanciados para obtener un único
número, que será la cuenta de Puntos Objeto.

5. Estimar el porcentaje de reutilización esperado para realizar el proyecto.

Calcular los nuevos Puntos Objeto a ser desarrollados.

Ecuación 8

6. Determinar un ratio de productividad PROD=NOP/Personas-mes utilizando

el siguiente esquema:

Capacidad y experiencia
de los desarrolladores Muy Baja Baja Nominal Alta Muy Alta
Capacida y madured de
ICASE Muy Baja Baja Nominal Alta Muy Alta
PROD 4 7 13 25 50

7. Calcular la estimación de personas-mes:

Ecuación 9

27
MODELO DE DISEÑO INICIAL (ANTICIPADO).

Se utilizarán Puntos Función Desajustados como medida de tamaño. Este modelo

es usado en los primeros estados de un proyecto software, cuando pocas cosas
podemos conocer sobre el tamaño del producto a desarrollar, la naturaleza de la
plataforma objetivo, la naturaleza del personal involucrado en el proyecto, o los
detalles específicos del proceso que se utilizará. Este modelo podría ser empleado en
Generadores de Aplicaciones, Integración de Sistemas, o sectores de desarrollo de
infraestructuras.

CUENTA DE PUNTOS FUNCIÓN

La aproximación de la estimación del coste mediante Puntos Función está basada

en la cantidad de funcionalidades de un proyecto software y en un conjunto de factores
individuales del proyecto. Los Puntos Función son estimaciones valiosas ya que están
basadas en la información que está disponible al inicio del ciclo de vida del proyecto.

Los Puntos Función miden un proyecto software cuantificando la información

asociada a los principales datos externos o control de entrada, salida, o tipos de
ficheros.

Pueden identificarse cinco tipos de funciones de usuario según la Tabla 9:

Entrada Externa Cuenta cada dato de usuario o tipo de entrada de control del usuario que
(Entradas) (1) se introduce desde el exterior del sistema y (2) que añade o modifica
datos en un fichero lógico interno.
Salida Externa Cuenta cada dato de usuario o tipo de entrada de control que abandona el
(Salidas) sistema hacia el exterior.
Ficheros Lógicos Internos Ficheros pasados o compartidos entre sistemas software que deberían
(Ficheros) contarse como tipos de ficheros de interface externos que están dentro del
sistema.
Consultas Externas Cuenta cada combinación de entrada-salida única, donde una entrada
(Informes) causa y genera una salida inmediata, como un tipo de consulta externa.
Tabla 9: Tipos de Funciones de Usuario.

Cada instancia de estos tipos de funciones es clasificado según su nivel de

complejidad. Los niveles de complejidad determinan un conjunto de pesos o valores,
los cuales son aplicados a su correspondiente cuenta de tipo de función para
determinar la cantidad de Puntos Función Desajustados. Esta es la función de medida
del tamaño empleada por COCOMO 2.0. El procedimiento usual de Puntos Función
incluye una valoración del grado de influencia (DI) de catorce características de la
aplicación del proyecto software de acuerdo a una escala, que va desde 0'0 a 0'05
para cada característica. Los 14 ratios son sumados juntos, y añadidos a un nivel base
de 0'65 para producir un factor de ajuste de las características generales con un rango
que va desde 0'65 hasta 1'35.

Cada una de estas 14 características, como son las funciones distribuidas,

rendimiento, y reusabilidad, contribuyen hasta un máximo del 5% sobre el esfuerzo
estimado. Esto resulta inconsistente para la experiencia de COCOMO; es por ello que
COCOMO 2.0 utiliza Puntos Función Desajustados para realizar una medida del
tamaño, y aplica factores de reutilización, parámetros de coste multiplicativos del
esfuerzo, y factores de escala que son exponenciales.

28
PROCEDIMIENTO DE CUENTA DE PUNTOS FUNCIÓN DESAJUSTADOS

El procedimiento usado en COCOMO 2.0 para determinar los Puntos Función

Desajustados es el siguiente:

1. Contar las funciones según su tipo: la cuenta de funciones desajustadas debería

ser realizada por un técnico basándose en la información recopilada en los
documentos de requerimientos y diseño del software. El número de cada uno de
los cinco tipos de funciones de usuario (Ficheros Lógicos Internos (ILF), Ficheros
de Interface Externos (EIF), Entrada Externa (EI), Salida Externa (EO), y Consultas
Externas (EQ)) debe de ser obtenido.

2. Contar las funciones atendiendo al nivel de complejidad: contar y clasificar cada

función dentro de los niveles (Bajo, Medio, o Alto) de complejidad dependiendo de
los tipos de datos y el número de tipos de ficheros referenciados. Utilizar para ello
el siguiente esquema:

Para ILF y EIF Para EO y EQ Para EI

Elementos Elementos Dato Tipos de Elementos Dato Tipos de Elementos Dato
Registro 1-19 20-50 51+ Ficheros 1-5 6-19 20+ Ficheros 1-4 5-15 16+
1 Bajo Bajo Med 0o1 Bajo Bajo Med 0o1 Bajo Bajo Med
2-5 Bajo Med Alto 2-3 Bajo Med Alto 2-3 Bajo Med Alto
6+ Med Alto Alto 4+ Med Alto Alto 3+ Med Alto Alto

3. Aplicar los pesos asignados a cada nivel de complejidad: utilizar los pesos del
siguiente esquema (los pesos reflejan el valor relativo de cada función para el
usuario):

Complejidad-Peso
Tipos de Función Bajo Medio Alto
Ficheros Lógicos Internos 7 10 15
Ficheros de Interface Externos 5 7 10
Entradas Externas 3 4 6
Salidas Externas 4 5 7
Consultas Externas 3 4 6

4. Calcular los Puntos Función Desajustados: sumar todos los pesos contados para
obtener un único número, número que determina el valor de los Puntos Función
Desajustados.

CONVERSIÓN DE PUNTOS FUNCIÓN A LÍNEAS DE CÓDIGO

Para determinar el número nominal de personas mes que nos da la Ecuación 1

para el Modelo de Diseño Inicial, los Puntos Función Desajustados han de convertirse
a líneas de código fuente que implementen el lenguaje (ensamblador, lenguaje de alto
nivel, lenguaje de cuarta generación, etc).

COCOMO 2.0 realiza esto para los modelos de Diseño Inicial y Post-Arquitectura
mediante el uso de tablas para poder transladar estos Puntos Función Desajustados
en el equivalente a SLOC:

Lenguaje SLOC/FP
Ada 71
AI Shell 49
APL 32
Ensamblador 320
Ensamblador (Macro) 213

29
 Lenguaje SLOC/FP
ANSI/Quick/Turbo Basic 64
Basic-Compilado 91
Basic-Interpretado 128
C 128
C++ 29
ANSI Cobol 85 91
Fortran 77 105
Forth 64
Jovial 105
Lisp 64
Modula 2 80
Pascal 91
Prolog 64
Generador de Informes 80
Hoja de Cálculo 6
Tabla 10: Conversión de Puntos Función a Líneas de Código.

PARÁMETROS DE COSTE (COST DRIVERS)

El modelo de Diseño Inicial utiliza KSLOC para valorar el tamaño. Los Puntos
Función Desajustados son convertidos a su equivalente en SLOC y luego a KSLOC.
La aplicación de los factores de escala del proyecto es igual en el modelo de Diseño
Inicial y en el modelo Post-Arquitectura. En el modelo de Diseño Inicial un reducido
conjunto de parámetros de coste es utilizado. Los parámetros de coste del modelo de
Diseño Inicial se obtienen por combinación de los parámetros de coste del modelo
Post-Arquitectura de la Tabla 19. La ecuación de esfuerzo es la misma que la dada por
la Ecuación 4.

Aproximación global: Ejemplo de Capacidad Personal (PERS).

La siguiente aproximación es utilizada para "mapear" un conjunto completo de

parámetros de coste y escalas de ratios de los participantes en el modelo de Diseño
Inicial. Esto incluye el uso y combinación de equivalentes numéricos a los niveles de
ratio. Más específicamente, a un parámetro de coste del modelo Post-Arquitectura con
un ratio de "Muy Bajo" le corresponde un valor numérico de 1, 2 para "Bajo", 3 para
"Nominal o medio", 4 para "Alto", 5 para "Muy Alto" y 6 para "Extra Alto". Para los
parámetros de coste combinados del modelo de Diseño Inicial, los valores numéricos
de los parámetros de coste del modelo Post-Arquitectura, Tabla 11, son sumados y el
resultado total es asignado a un ratio de escala (desde Extra Bajo a Extra Alto) del
modelo de Diseño Inicial.

Parámetro de Coste Combinación Equivalente

Diseño Inicial Post-Arquitectura
RCPX RELY, DATA, CPLX, DOCU
RUSE RUSE
PDIF TIME, STOR, PVOL
PERS ACAP, PCAP, PCON
PREX AEXP, PEXP, LTEX
FCIL TOOL, SITE
SCED SCED
Tabla 11: Multiplicadores de esfuezo Diseño Inicial y Post-Arquitectura.

La escala de ratios del modelo de Diseño Inicial siempre tiene un total nominal
igual a la suma de los ratios nominales de los elementos del modelo Post-Arquitectura
con los que se han formado.

30
 El siguiente ejemplo ilustrará esta aproximación. El parámetro de coste PERS del
Diseño Inicial combina los parámetros de coste Post-Arquitectura de capacidad del
analista (ACAP), capacidad del programador (PCAP), y continuidad del personal
(PCON). Cada uno de estos tiene una escala de ratios desde Muy Bajo (=1) a Muy
Alto (=5). Sumando estos ratios numéricos se produce un rango de valores entre 3 y
15. Estos son diseñados sobre una escala, y los niveles de ratio PERS del Diseño
Inicial son asignados a ellos, tal y como muestra la Tabla 19.

Extra Bajo Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
Suma de
rangos ACAP, 3, 4 5, 6 7, 8 9 10, 11 12, 13 14, 15
PCAP, PCON
Combinación
porcentajes 20% 39% 45% 55% 65% 75% 85%
ACAP y PCAP
Personal que
anualmente 45% 30% 20% 12% 9% 5% 4%
regresa
Tabla 12: Niveles de ratio PERS

El ratio personal PERS con valor 9 corresponde a la suma (3+3+3) de los ratios
nominales para ACAP, PCAP y PCON, y su multiplicador de esfuerzo correspondiente
es 1'0. Tener en cuenta que de todas formas el ratio nominal PERS de 9 resulta de
poder haber sumado otras combinaciones, por ejemplo 1+3+5=9 para ACAP=Muy
Bajo, PCAP=Nominal, y PCON=Muy Alto.

Las escalas de ratio y los multiplicadores de esfuerzo para PCAP y los otros
parámetros de coste de Diseño Inicial mantienen la consistencia relacional con sus
equivalentes en el modelo Post-Arquitectura. Por ejemplo, los niveles de ratio Extra
Bajo de PERS (20% combinando ACAP y PCAP, y el 25% de movimiento de personal)
representan niveles de ratio medios de ACAP, PCAP, y PCON por encima del 3 o 4.

Manteniendo estas relaciones de consistencia entre los niveles de ratio del Diseño
Inicial y Post-Arquitectura se asegura la consistencia en las estimaciones de coste de
estos dos modelos (de Diseño Inicial y Post-Arquitectura).

Complejidad y Confianza del Producto.

Estos parámetros de coste del Diseño Inicial combinan los cuatro parámetros de
coste Post-Arquitectura (Confianza Software Requerida (RELY), tamaño de la base de
datos (DATA), Complejidad del Producto (CPLX), y Documentación asociada a las
necesiddes del ciclo de vida (DOCU)). A diferencia de los componentes PERS, los
componentes RCPX tienen escalas de ratio con diferente margen. Los rangos de
RELY y DOCU van desde Muy Bajo a Muy Alto; los rangos de DATA van desde Bajo a
Muy Alto; y los rangos de CPLX van desde Muy Bajo a Extra Alto. Y con un valor
numérico entre 5 (Muy Bajo, Bajo, Muy Bajo, Muy Bajo) y 21 (Muy Alto, Muy Alto, Extra
Alto, Muy Alto).

La Tabla 19 asigna los ratios RCPX a través de este rango, y asocia escalas de
ratio apropiadas a cada uno de los ratios RCPX (desde Extra Bajo a Extra Alto).

Extra Muy Bajo Nominal Alto Muy Extra

Bajo Bajo Alto Alto
Suma de ratios RELY, 5, 6 7, 8 9 -11 12 13 - 15 16 - 18 19 - 21
DATA, CPLX, DOCU
Enfasis sobre confiana, Muy Poco Algo Basico Fuerte Muy Extremo
documentación poco fuerte
Complejidad del producto Muy Simple Algo Moderado Compl Muy Extrema

31
 Extra Muy Bajo Nominal Alto Muy Extra
Bajo Bajo Alto Alto
Simple ejo complejo damente
complejo
Tamaño de la base da datos Pequeño Pequeño Pequeño Moderado grande Muy Muy
grande grande
Tabla 13: Niveles de ratio de RCPX

Reutilización Requerida (RUSE).

Este parámetro de coste del Diseño Inicial es el mismo a su homónimo en el

modelo Post-Arquitectura. Un resumen de estos niveles de ratio se ofrece aquí, y en la
Tabla 19:

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

ninguno A través del A través del A través de la A través de
RUSE proyecto programa línea de múltiples
producto líneas de
producto
Tabla 14: Resumen del nivel de ratio de RUSE

Inconvenientes de la Plataforma (PDIF).

Este parámetro de coste del Diseño Inicial combina los tres parámetros de coste
Post-Arquitectura (tiempo de ejecución (TIME), almacenamiento principal (STOR), y
volatilidad de la plataforma (PVOL)). TIME y STOR tienen rangos desde Nominal a
Extra Alto; PVOL rangos desde Bajo a Muy Alto. Y con un valor numérico entre 8
(Nominal, Nominal, Bajo) y 17 (Extra Alto, Extra Alto, Muy Alto).

Bajo Nominal Alto Muy Alto Extra Alto

Suma de TIME, 8 9 10 - 12 13 - 15 16, 17
STOR, y PVOL
Restricción de #50% #50%
almacenamiento y 65% 80% 90%
Tiempo
Volatilidad de la Muy estable estable Algo volatil volatil Altamente
plataforma volatil
Tabla 15: Niveles de ratio de PDIF

Experiencia Personal (PREX).

Este parámetro de coste del Diseño Inicial combina los tres parámetros de coste
Post-Arquitectura (experiencia en la aplicación (AEXP), experiencia en la plataforma
(PEXP), y experiencia en las herramientas y lenguajes (LTEX)). Cada uno de estos
con un rango desde Muy Bajo a Muy Alto. Y con un valor numérico entre 3 y 15.

Extra Muy Bajo Bajo Nominal Alto Muy Alto Extra

Bajo Alto
Suma de ratios de
AEXP, PEXP, y
LTEX 3, 4 5, 6 7, 8 9 10, 11 12, 13 14, 15
Experiencia en
Aplicaciones, #3 meses
Plataforma, 5 meses 9 meses 1 año 2 años 4 años 6 años
Lenguaje y
Herramientas
Tabla 16: Niveles de ratio PREX

32
Facilidades (FCIL).

Este parámetro de coste del Diseño Inicial combina dos parámetros de coste
Post-Arquitectura: uso de herramientas software (TOOL) y desarrollo multisitio o
distribuido (SITE). TOOL tiene un rango desde Muy Bajo a Muy Alto; el rango de SITE
va desde Muy Bajo a Extra Alto. El valor numérico suma de estos ratios está entre 2
(Muy Bajo, Muy Bajo) y 11 (Muy Alto, Extra Alto).

Planificación (SCED).

Este parámetro de coste de Diseño Inicial es el mismo que su homómino en el

modelo Post-Arquitectura. Ver Tabla 19.

Extra Muy Bajo Bajo Nominal Alto Muy Alto Extra

Bajo Alto
Suma ratios de TOOL 2 3 4, 5 6 7, 8 9, 10 11
y SITE
Soporte TOOL Minima Alguna Simple Herramie Buena; Fuerte; Fuerte;
colección ntas de moderada moderada muy
de ciclo de mente mente integrada
herramien vida integrada integrada
tas CASE básicas
Condiciones Multisitio Escaso Algún Algún Soporte Fuerte Fuerte Muy
soporte soporte soporte básico de soporte soporte fuerte de
de de de moderado de de simple ordenado
complejo complejo moderado desarrollo moderado desarrollo o simple
desarrollo desarrollo desarrollo multisitio desarrollo multisitio desarrollo
multisitio multisitio multisitio multisitio multisitio
Tabla 17: niveles de ratio FCIL.

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

SCED 75% del 85% 100% 130% 160%
nominal
Tabla 18: Resumen de nivel de ratio SCED.

33
MODELO POST-ARQUITECTURA.

Este modelo es el más detallado y es utilizado cuando la arquitectura del ciclo de

vida del software ha sido desarrollada. Este modelo es usado en el desarrollo y
mantenimiento de productos software como Generadores de Aplicaciones, Integración
de Sistemas e Infraestructura.

NOMAS PARA CONTAR LAS LÍNEAS DE CÓDIGO

En COCOMO 2.0 las sentencias lógicas fuente han sido elegidas como el estándar
para determinar la línea de código. Definir el concepto de línea de código es una difícil
tarea debido a las diferencias conceptuales que suponen para diferentes lenguajes las
sentencias ejecutables y declaraciones de datos. El objetivo es medir la cantidad de
trabajo intelectual puesto en el desarrollo del programa, pero surgen dificultades
cuando intentamos definir medidas consistentes para lenguajes diferentes. Para
minimizar estos problemas, la definición que da el Instituto de Ingeniería del Software
(SEI) de sentencia lógica fuente es utilizada para definir la medida de líneas de
códigos.

La figura 5 de la página siguiente muestra cómo una parte de esta definición es

aplicada para soportar el desarrollo del modelo COCOMO 2.0. Cada marca en la
columna "Incluye" identifica un tipo de sentencia particular o atributo incluido en la
definición, y viceversa para la columna "Exclude". Otras secciones en la definición
clarifican los atributos de las sentencias para su uso, reparto, funcionalidad, replicación
y estudio de desarrollo. Hay también aclaraciones para sentencias específicas de
lenguajes como ADA, C, C++, CMS-2, COBOL, FORTRAN, JOVIAL y Pascal.

Algunos cambios fueron realizados para definir línea de código para apartarse de
la definición por defecto. Estos cambios eliminan categorías de software las cuales
resultan ser generalmente pequeñas fuentes de esfuerzo del proyecto. El código
generado con generadores de código fuente no está incluido, aunque sin embargo
será tenido en cuenta para soportar el análisis.

La definición de línea de código de COCOMO 2.0 está calculada directamente por

la colección de herramientas métricas automatizadas Amadeus, las cuales son usadas
para asegurar la uniformidad de la colección de datos dentro de los datos recopilados
y del análisis del proyecto de COCOMO 2.0.

Para soportar mejor el análisis de datos, Amadeus tomará automáticamente

medidas adicionales que incluyen las líneas fuente totales, comentarios, sentencias
ejecutables, declaraciones, estructura, componentes de interfaz, y otros. La
herramienta proporcionará varias medidas del tamaño.

34
Figura 5

35
PUNTOS FUNCIÓN

Para la estimación de puntos función del modelo Post-Arquitectura, son válidos los
cálculos utilizados para convertir los Puntos Función Desajustados a KSLOC que se
utilizan en el modelo de Diseño Inicial. COCOMO 2.0 permite que algunos
componentes sean evaluados utilizando puntos función, y otros (en los cuales los
punto función no los describen correctamente, tales como cálculos científicos o en
tiempo real) en SLOC. Toda medida es expresada en KSLOC y usada en la Ecuación
4. El Apéndice A muestra la ecuación para el modelo Post-Arquitectura.

PARÁMETROS DE COSTE

Existen 17 multiplicadores de esfuerzo utilizados en el modelo Post-Arquitectura

para ajustar el esfuerzo nominal, Persona mes, para poder reflejar el producto
software bajo desarrollo. Estos multiplicadores son agrupados en cuatro categorias:
del producto, de la plataforma, personales, y del proyecto. La figura 19 muestra los
diferentes parámetros de coste junto a sus criterios para establecer los rangos.
Siempre que una valoración de un parámetro de coste está entre un rango de valores
cercanos al valor medio, por ejemplo si un parámetro de coste está entre Alto y Muy
Alto, entonces seleccionaremos Alto. Una parte de estos multiplicadores del esfuerzo
han sido tratados ya en el modelo de Diseño Inicial.

Factores del Producto:

• Confianza Software Requerida (RELY). Esta es una medida hasta el punto

de lo que el software debe realizar mediante las funciones construidas y
durante un periodo de tiempo. Si el efecto de un fallo software es
únicamente producir pequeños inconvenientes, entonces RELY tienen un
valor bajo. Si un fallo llegase a arriesgar la vida humana entonces RELY
tomaría un valor muy alto.

• Tamaño de Base de Datos (DATA). Esta medida pretende capturar los

efectos que tienen requerimientos de gran cantidad de datos sobre el
desarrollo del producto. El porcentaje está determinado por cálculo D/P. El
tamaño de la base de datos es una consideración importante debido al
esfuerzo requerido para generar todos los test de datos.

Ecuación 10

DATA toma un valor bajo si D/P es menor de 10, y toma un valor muy alto si
es mayor de 100.

• Complejidad del Producto (CPLX). La Tabla 20 proporciona la nueva escala

de ratios de CPLX en el modelo COCOMO 2.0. La complejidad es dividida
en cinco áreas: operaciones de control, operaciones computacionales (de
cálculo), operaciones que son dependientes de los dispositivos,
operaciones de manejo de datos, y operaciones de gestión del interfaz de
usuario. Una selección de estás áreas o combinación de ellas caracterizará

36
 el producto, o a un subsistema o parte del producto. La escala de
complejidad es una valoración subjetiva media de estas áreas.

• Reutilización Requerida (RUSE). Este parámetro de coste mide el esfuerzo

adicional necesario para la construcción de componentes que puedan
reutilizarse en el actual o en futuros proyectos. Este esfuerzo es consumido
durante la creación de un diseño software más genérico, una
documentación más elaborada, y un chequeo más exhaustivo para
asegurarse de que los componentes quedan listos para ser utilizados en
otras aplicaciones.

Muy bajo Bajo Nominal Alta Muy alta Extra Alta

RELY Inconvenientes Poco Moderado Alta Riesgos
sin importancia
DATA DB bytes/Pgm 10#D/P<100 100#D/P<1000 D/P ô 1000
SLOC<10
CPLX Mirar tabla sobre la valoración de complejidad según el tipo de modulo
RUSE None Determinado Determinado en Determinado Determinado
en el proyecto el programa en línea en multiples
líneas
DOCU A penas Algo necesario Tamaño Excesivo a las Muy
necesarios ajustado a las necesidades del excesivas
necesidades ciclo devida para las
del ciclo de necesidades
vida del ciclo de
vida
TIME #50% del 70% 85% 95%
tiempo usado
para la
ejecución
STOR #50% del 70% 85% 95%
almacenamient
o disponible
PVOL Grandes Grandes: 6 Grandes: 2 Grandes: 2
cambios cada meses. meses. semanas.
12 meses, y Pequeños: 2 Pequeños: 1 Pequeños: 2
cambios semanas. semana. días.
pequeños
cada mes
ACAP 15% 35% 55% 75% 90%
PCAP 15% 35% 55% 75% 90%
PCON 45%/año 24%/año 12%año 6%/año 3%/año
AEXP #2meses 6 meses 1 año 3 años 6 años
PEXP #2meses 6 meses 1 año 3 años 6 años
LTEX #2meses 6 meses 1 año 3 años 6 años
TOOL Editor, CASE hacia Herramientas Madured en la Idem,
codificar, delante, hacia básicas delutilización de integración
depurar atrás y simple, ciclo de vida, herramientas del de procesos,
pequeña moderada ciclo de vida, metodos,
integración integración integración reutilización
moderada
SITE: Internacional Varias Varias Misma ciudad o Mismo Completament
Distribución ciudades y ciudades o misma zona edificio o e junto
varias varias complejo
compañias compañias
SITE: Telefono y Correo Correo Cominicación Idem, Interactivo
Comunicació correo indivicual y fax electrónico en electrónica ocasional Multimedia
n un canal utilizando un video
angosto canal ancho conferencia
SCED 75% del 85% 100% 130% 160%
nominal
Tabla 19. Parámetros de coste multiplicadores del esfuerzo, para el Modelo Post-Arquitectura.

37
 Muy baja Baja Nominal Alta Muy alta Extra alta
Operaciones Lineas simples Uso anidado Mayoría de los Programación Codigo Múltiple
de control de código con de operadores
anidamientos altamente reentrante y planificación
poco codigo y de de operadores anidada con recursivo. de recursos
sin estructuras programaciónson simples. mucha Manejo de con prioridades
anidadas: estructuradaAlgún control composición interrupciones que cambian
DOs, CASEs, de forma
entre modulos. de predicados. con prioridad. dinamicamente
IFTHENELSs. directa. Tablas de Procesos Sincronización . Control a
Llamadas a Mayoritariame
decisión. Paso distribuidos. de tareas, nivel de
procedimientos nte uso de de mensajes, Control en control en microcódigo.
simples. predicados incluyendo tiempo real tiempo real Control
simples. proceso simple. complejo. distribuido en
distribuido a tiempo real.
medio nivel
Operaciones Evaluación Evaluación de Uso de rutinas Analisis Dificil y Analisis
de computo simple de expresiones a estandar, numérico estructurado numérico dificil
expresiones: nivel medio: matemáticas y básico: análisis y no
A=B+C*(D-E) SQRT(B2- estadísticas. multivariable, numérico: estructurado:
4*A*C) Operaciones interpolacion, ecuaciones análisis
básicas sobre ecuaciones matriciales, altamente
matrices o diferenciales ecuaciones preciso de
vectores. de primer diferenciales ruido, datos
orden. parciales. estocásticos.
Paralelización Paralelización
simple. compleja.
Operaciones Lecturas No es El proceso de Operaciones Rutinas para Codificación
dependientes simples, necesario I/O incluye de I/O a nivel diagnóstico, de con control de
de escritura de conocimiento selección de fisico servicio, de tiempos de
dispositivos declaraciones sobre dispositivos, (traducción de enmascaramie dispositivos,
con formas procesadores comprobación direcciones nto de operaciones
simples. I/O de estado, y físicas, interrupciones. de
particulares. La proceso de los posicionamient Manejo de lina microprograma
I/O se realiza a errores. os en de ción. Sistemas
niivel de memoria, comunicacione de proceso
GET/PUT. lecturas, ...). s. Sistemas de crítico.
proceso
intensivo.
Operaciones Arrays Tramtamiento Entrada desde Simples Coordinación Altamente
de manejo de sencillos en de ficheros de varios ficheros, señales de de bases de acoplados,
datos memoria forma simple, y salida única. activación datos relacionados
principal. sin cambios en Cambios flujos de distribuidas. dinámicamente
Consultas y la estrucutra simples en la datos. Señales de y con
actualizaciones de datos, sin estructura. Reestructuraci activación estructura de
simples de la ficheros Consultas y ón de datos complejas. objetos.
base de datos. intermedios, ... actualizaciones compleja. Optimización Manejo de
Consultas y complejas. de búsquedas. lenguaje
actualizaciones natural de
moderadas de datos.
la base de
datos.
Operaciones Formularios de Uso de GUIs Uso simple de Desarrollo de Moderadament Multimedia
para gestión entrada simples. elementos de elementos de e complejo, compleja,
del interfaz de simples. interfaz. interfaz. 2D/3D, realidad virtual.
usuario Generador de Multimedia y gráficos
listados. I/O simple con dinámicos.
voz.
Tabla 20. Valoración de complejidad según el tipo de modulo

• Documentación relacionada con las necesidades del ciclo de vida (DOCU).

Distintos modelos de coste software poseen un parámetro de coste para
valorar el nivel de documentación requerida. En COCOMO 2.0, la escala de
ratio para el parámetro de coste DOCU es evaluada en términos de la
adecuada documentación del proyecto que necesita el ciclo de vida. Esta
escala va desde Muy Bajo (se observan algunas necesidades del ciclo de
vida) hasta Muy Alto (muchas y grandes necesidades del ciclo de vida).

38
Factores de la Plataforma:

La plataforma se refiere al complejo formado por el hardware e infraestructura

software (antes conocido como máquina virtual) de la máquina objetivo. Los factores
han sido revisados para reflejar estos parámetros tal y como se describen. Algunos
factores adicionales de la plataforma fueron considerados, tal como distribución,
paralelismo, sistemas empotrados, y operaciones en tiempo real. Estas
consideraciones han sido acomodadas mediante la expansión de los porcentajes del
Modulo de Complejidad en la Ecuación 20.

• Tiempo de Ejecución Necesitado (TIME). Esta es una medida del tiempo

de ejecución que es impuesto, por necesidad, por el sistema software. El
porcentaje es expresado en términos del tanto por ciento del tiempo de
ejecución disponible que se espera que ea consumido por el sistema o
subsistema, del total del recurso formado por el tiempo de ejecución. Los
rangos van desde Nominal, menos del 50% usado de este recurso, hasta el
Extra Alto, 95% de este tiempo.

• Volatilidad de la plataforma (PVOL). El término "plataforma" es utilizado

para comprender el complejo conjunto formado por el hardware y software
(OS, DBMS, etc) que el producto software utiliza, llama, para realizar sus
tareas. Si el software a desarrollar es un sistema operativo entonces la
plataforma es el hardware de la computadora. Si es un sistema gestor de
bases de datos lo que va a desarrollarse, entonces la plataforma es el
hardware y el sistema operativo. Si es un navegador texto de red el objetivo
del desarrollo, entonces la plataforma es la red, el hardware de la
computadora, el sistema operativo, y los lugares distribuidos donde se
localiza la información. La plataforma incluye cualquier compilador o
ensamblador utilizado para desarrollar el sistema software. Este rango va
desde Bajo, donde existen cambios importantes en la plataforma cada 12
meses, hasta Muy Alta, con cambios importantes cada dos semanas
aproximadamente.

Factores Personales:

• Capacidad de los Analistas (ACAP). Los analistas son personas que

trabajan sobre los requerimientos, diseñan a un alto nivel y lo detallan. Los
principales atributos que deberían de ser considerados en esta categoría
son la habilidad y eficiencia, y la habilidad de comunicación y cooperación.
Esta escala no debería de expresar el nivel de experiencia del analista, que
ya es valorado con AEXP.

• Capacidad del Programador (PCAP). La tendencia actual enfatiza la

importancia de analistas altamente capaces, sin embargo el papel creciente
de los complejos paquetes COTS, y la influencia de una significativa
productividad asociada con la habilidad de los programadores para tratar
con estos paquetes COTS, indica una buena tendencia que da mayor
importancia a las capacidades del programador.

La evaluación debería de basase en la capacidad de los programadores

para formar grupos más que en su individualidad. Los principales factores
que deberían ser considerados para establecer estos niveles son pues la
habilidad y eficiencia, y la habilidad de comunicación y cooperación. La

39
 experiencia de los programadores no debería de ser considerada aquí, ya
que es valorada con AEXP.

• Experiencia en las Aplicaciones (AEXP). Esta valoración es dependiente

del nivel de experiencia que se posee en las aplicaciones por el equipo de
desarrollo. Los ratios son definidos en términos de equipos de proyecto
equivalentes al nivel de experiencia con ese tipo de aplicación. Un rango de
Muy Bajo para una experiencia menor de 2 meses, y Muy Alto si se posee
una experiencia igual o superior a 6 años.

• Experiencia en la Plataforma (PEXP). El modelo Post-Arquitectura amplia la

influencia que sobre la productividad tiene este parámetro PEXP,
reconociendo la importancia de comprender el uso de más plataformas
potentes, incluyendo interfaces de usuario gráficos, bases de datos, trabajo
con redes, etc...

• Experiencia con Herramientas y Lenguajes (LTEX). Esta es una medida del

nivel de experiencia con lenguajes de programación y utilidades software
que posee el equipo de desarrollo del sistema o subsistema. El desarrollo
del software incluye el uso de herramientas para realizar los requerimientos,
y el análisis y diseño de la representación, manejo de la configuración,
extracción de la documentación, gestión de librerias, formateo y estilo de
programa, chequeo de consistencia, etc... Adicionalmente a la experiencia
en programación con un lenguaje específico, el soporte de un conjunto de
utilidades o herramientas tiene efectos sobre el tiempo de desarrollo. Un
ratio Bajo se da para una experiencia menor de 2 meses, y de Muy Alto
para experiencias iguales o mayores a 6 años.

• Continuidad del Personal (PCON). El ratio de la escala para PCON se da

en términos del personal que retorna anualmente al proyecto: desde 3%,
Muy Alto, al 48%, Muy Bajo.

Factores del Proyecto:

• Uso de herramientas software ITOOL). Las herramientas software han

mejorado significativamente desde los años 70, que sirvieron para calibrar
el COCOMO. El ratio de rangos van desde las simples herramientas de
edición y coficicación, a las que se les asigna un valor asociado de Muy
Bajo, hasta las herramientas integradas de gestión del ciclo de vida,
asignándoles un valor de Muy Alto.

• Desarrollo Multisitio (SITE). Dan la creciente frecuencia de desarrollos

realizados en distintos lugares, e indican como este desarrollo multisitio
tiene unos efectos significativos, es por ello que estas características fueron
añadidas al COCOMO 2.0. La determinación de estos parámetros de coste
incluyen la valoración y un promedio de dos factores: la situación (dentro
de una distribución mundial) y el soporte de comuncicaciones (desde el
correo y teléfono, hasta los completos medios interactivos de carácter
multimedia).

• Planificación de Desarrollo Requerida (SCED). Este ratio mide la

planificación temporal a establecer, obligada e impuesta por el equipo de
desarrollo del proyecto del software. Los ratios son definidos en términos

40
del porcentaje de planificación que se alarga o acelera con respecto a la
planificación media para un proyecto que necesita una cantidad de
esfuerzo determinado. Planificaciones temporales aceleradas tienden a
producir más esfuerzo en las últimas fases de desarrollo debido a que más
asuntos son dejados para ser determinados posteriormente. Una
planificación comprimida un 74% es valorada como un porcentaje Muy
Bajo, y un alargamiento del 160% es valorada como un porcentaje Muy
Alto.

41
 GLOSARIO

3GL Lenguaje de Tercera Generación

AA Porcentaje de esfuerzo de reusabilidad que es debido a la Valoración y

Asimilación de ese código reutilizable.
ACAP Capacidad del Analista

AEXP Experiencia en la Aplicación

ASLOC Adaptación de Línea de Código Fuente

BRAK Breakage. Cantidad de cambios controlados que se permiten en un

desarrollo software antes del "cierre" de los requerimientos.
CASE Ingeniería del Software Asistida por Computador

CM Porcentaje de código modificado persiguiendo la reutilización

CMM Modelo de Capacidad de Madured

Cost Párametro que influye en el coste del software. Es una característica

Drivers particular de un desarrollo software que tiene efectos sobre la cantidad del
esfuerzo de desarrollo, incrementandolo o decrementandolo.
COTS "Commercial Off The Shelf"

CPLX Complejidad del Producto

DATA Tamaño de la Base de Datos.

DBMS Sistema Gestor de Bases de Datos.

DI Grado de Influencia.

DM Porcentaje del diseño que es modificado debido a la reusabilidad.

DOCU Documentación asociada con las necesidades del ciclo de vida.

ESLOC Equivalente en Líneas de Código Fuente.

FCIL Facilidades.

FP Puntos Función

GUI Interface Gráfico de Usuario

42
ICASE Entorno Software Integrado Asistido por Computador

IM Porcentaje de integración que se vuelve a hacer persiguiendo la

reutilización de código
KSLOC Miles de Líneas de Código Fuentes

LTEX Experiencia en Lenguajes y Herramientas

NOP Nuevos Puntos Objeto

OS Sistemas Operativos

PCAP Capacidad del Programador

PCON Continuidad del Personal

PDIF Dificultad de la Platadorma

PERS Capacidad del Personal

PEXP Experiencia en la Plataforma

PL Linea de Producto

PM Persona Mes. Es la cantidad de tiempo que dedica durante un mes una

sóla pesona que trabaja sobre un proyecto de desarrollo software
PREX Experiencia Personal

PROD Porcentaje de Productividad

PVOL Volatilidad de la Plataforma

RCPX Complejidad y Fiabilidad del Producto

RELY Fiabilidad Software Requerida

RUSE Reusabilidad Requerida

SCED Planificación de Desarrollo Requerida

SEI Instituto de Ingeniería del Software

SITE Desarrollo Multisitio

SLOC Líneas de Código Fuente

43
STOR Restricción de Almacenamiento Principal

SU Porcentaje de esfuerzo requerido en la reutilización del código, y que es

debido a la comprensión del software
TIME Restricción de Tiempo de Ejecución

TOOL Uso de Herramientas Software

44
 Apéndice A: ECUACIONES

COMPOSICIÓN DE APLICACIONES .

Los Puntos Objeto Nuevos son determinados por:

Ecuación 11

El porcentaje de productividad, PROD, es estimado mediante una media subjetiva de

experiencia del desarrollador y la capacidad y madured de la herramienta ICASE:

Capacidad y Experiencia del Muy Bajo Bajo Medio Alto Muy Alto
desarrollador
Capacidad y Madured de la Muy Bajo Bajo Medio Alto Muy Alto
herramienta ICASE
PROD 4 7 13 25 50

Y el esfuerzo estimado resulta:

Ecuación 12

45
DISEÑO INICIAL .

El esfuerzo estimado resulta:

Ecuación 13

donde

Símbolo Descripción
A Constante, provisionalmente con un valor 3'0
ADAPT Porcentaje de componentes adaptados (representa el esfuerzo requerido para
comprender el software)
AT Porcentaje de componentes que son automáticamente transladados
EM Multiplicadores del esfuerzo: RCPX, RUSE, PDIF, PERS, PREX, FCIL, SCDE
KASLOC Tamaño del componente adaptado expresado en miles de líneas de código fuente
adaptadas
KNSLOC Tamaño del componente expresado en miles de nuevas líneas de código fuente
PM Estimación de esfuerzo dada en Personas Mes
SF Factores de escala: PREC, FLEX, RESL, TEAM, PMAT
SLOC Tamaño de un componente expresado in líneas de código fuente
UFP Puntos Función Desajustados
UFP Count Tamaño del componente expresado en Puntos Función Desajustados

46
POST-ARQUITECTURA .

El esfuerzo estimado resulta:

Ecuación 14

donde

Símbolo Descripción
A Constante, provisionalmente con un valor de 3'0
AA Evaluación y Asimilación
ADAPT Porcenta de componentes adaptados (representa el esfuerzo requerido en comprender el
software)
AT Porcentaje de componentes que son automáticamente transladados
ATPROD Productividad de la translación automática
BRAK Breakage: porcentaje de código "tirado" debido a la volatilidad de los requerimientos
CM Porcentaje de código modificado
DM Porcentaje de diseño modificado
EM Multiplicadores del esfuerzo: RELY, DATA, CPLX, RUSE, DOCU, TIME, STOR, PVOL,
ACAP, PCAP, PCON, AEXP, PEXP, LTEX, TOOL, SITE, SCED
IM Porcentaje de integración y testeo del código modificado
KASLOC Tamaño del componente adaptado expresado en miles de líneas de código fuente
adaptadas
KNSLOC Tamaño del componente expresado en miles de nuevas líneas de código fuente
PM Estimación de esfuerzo dada en Personas Mes
SF Factores de escala: PREC, FLEX, RESL, TEAM, PMAT
SU Comprensión del software (cero si DM=0 y CM=0)

47
ESTIMACIÓN DE LA PLANIFICACIÓN .

Determina el tiempo de desarrollo (TDEV) con un esfuerzo estimado, PM "negado",

que excluye el efecto del multiplicador de esfuerzo SCED:

Ecuación 15

donde

Símbolo Descripción
SCED% Porcentaje de compresión/expansión del multiplicador de esfuerzo SCED
PM "negado" Personas Mes de esfuerzo estimado para los modelos de Diseño Inicial y
Post-Arquitectura (excluyendo el efecto del multiplicador de esfuerzo SCED)
SF Factores de escala: PREC, FLEX, RESL, TEAM, PMAT
TDEV Tiempo de desarrollo

48
ESTADO ACTUAL DEL MODELO .

COCOMO 2.O es actualmente una colección de datos, calibraciones y

experiencias, donde se aportan datos de distintos proyectos que posteriormente se
validan para determinar la consistencia con el modelo.

Han sido desarrolladas algunas herramientas, tanto experimentales para uso de

investigadores del modelo, como comerciales.

55
 BIBLIOGRAFÍA

• “Ingeniería del software”

R. Fairley. Ed. McGraw-Hill

• “Ingeniería del software. Un enfoque práctico”

R. Pressman. Ed. McGraw-Hill

• Documentos y notas de Pascual Gonzalez, Escuela Superior de Informática,

Universidad de Castilla-La Mancha, Campus de Albacete.

• Direcciones URLs:

+ Universidad del Sur de California

http://sunset.use.edu/COCOMOII/cocomo.html
http://sunset.use.edu/techRpts/Reports.html

+ Softstars Systems
http://www.softsartsystem.com

+Varios
http://si.di.fc.ul.pt/pbd/Transparentes
http://www.geocities.com/ResearchTriangle/Facility/2917

56