1

Universidad Tcnica Federico Santa Mara

Departamento de Informtica
Gua prctica para COCOMO 2.0
I ngeniera de Software Avanzada
1 INTRODUCCIN
COCOMO 2.0 (Constructive Cost Model, COCOMO) surge como respuesta a las falencias de COCOMO
original (COCOMO 81) y a la necesidades planteadas por un nuevo escenario para el desarrollo de software
(cambios tecnolgicos, nuevos modelos del ciclo de vida, nuevas herramientas, reingeniera, generadores de
aplicaciones, enfoque orientado a objetos, etc.) proponiendo principalmente el uso de diferentes modelos de
tamao segn el avance del proyecto y el nivel de conocimiento del sistema en desarrollo.
En concreto COCOMO 2.0 provee tres modelos de estimacin secuenciales que corresponden a las siguientes
etapas:
Etapa 1 o Application Composition Model orientada a apoyar la estimacin en las etapas tempranas del
desarrollo de software, donde bsicamente se cuenta con escasa informacin sobre los requerimientos del
sistema. Este modelo adems apoya la estimacin para el desarrollo de prototipos rpidos en cualquier
etapa del ciclo de vida del software.
Etapa 2 o Early Design Model enfocada a apoyar la estimacin tras la definicin de los requerimientos y
as respaldar la toma de decisiones sobre la evaluacin de arquitecturas y conceptos de operacin
alternativos para el desarrollo de software.
Etapa 3 o Post-Architecture Model orientada a apoyar la estimacin durante el desarrollo del sistema.
2
2 ETAPA 1: THE APPLICATION COMPOSITION MODEL
2.1 Descripcin general
La etapa 1 esta enfocada a apoyar la estimacin de esfuerzo durante las fase de planificacin de un proyecto
de desarrollo de software. Esto implica que la estimacin deba realizarse sobre la base de informacin exigua
y en muchos casos insuficiente.
Dadas estas circunstancias, COCOMO 2.0 propone que es posible identificar elementos de alto nivel que
permitan estimar el tamao del producto final, base fundamental para el clculo del esfuerzo. Luego, se
sugiere estimar el tamao del producto como puntos objeto (Object Points, OP) que capturan el tamao en
trminos de generadores de esfuerzo de alto nivel: informes, ventanas, componentes de tercera generacin,
vistas y tablas de datos.
2.2 Estimacin del esfuerzo
En la etapa 1 de COCOMO 2.0 el esfuerzo se define como:
E=NOP/PROD
Donde
E: esfuerzo en personas-mes
NOP (New Object Points): nuevos puntos objeto
PROD: razn de productividad
A. Estimacin de tamao a travs de NOP
Paso 1: Identificacin de los tipos de objeto.
Lista de las ventanas, informes y componentes de tercera generacin (objetos, clases, herencia, etc.) que
abarcar la aplicacin.
Paso 2: Clasificacin de cada tipo de objeto segn su complejidad.
Identificados los objetos, es necesario para cada uno de ellos (informes y ventanas) determinar el nmero de
vistas que contiene, el nmero de tablas de datos que referencia y el tipo de fuente de dichas tablas
(servidores o clientes). Con estos datos y segn las tablas 1 y 2 se obtiene el nivel de complejidad (simple,
medio, o difcil) de cada objeto.
Observacin: Los componentes de tercera generacin son clasificados como difciles.
Ventanas
Nmero y fuentes de tablas de datos Nmero de vistas
contenidas Total < 4
(<2 srvr, <3 clnt)
Total < 8
(2/3 srvr, 3-5 clnt)
Total >8
(>3 srvr, >5 clnt)
<3 Simple Simple Media
3-7 Simple Media Difcil
>8 Media Difcil Difcil
Tabla 1
3
Informes
Nmero y fuentes de tablas de datos Nmero de vistas
Contenidas Total < 4
(<2 srvr, <3 clnt)
Total < 8
(2/3 srvr, 3-5 clnt)
Total >8
(>3 srvr, >5 clnt)
0-1 Simple Simple Media
2-3 Simple Media Difcil
>4 Media Difcil Difcil
Tabla 2
Paso 3: Clculo de los puntos objeto (Object Points, OP).
Para calcular los OP se ingresa el nmero de objetos identificados dentro de cada categora de complejidad de
acuerdo a la siguiente tabla. Luego se realiza un clculo simple cuyo resultado son los OP.
Complejidad Peso Tipo de objeto
Simple Media Difcil Subtotal
Ventana __x 1 +__x 2 +__x 3 =
Informe __x 2 +__x 5 +__x 8 =
Componente de 3GL __x 10 =
Total OP (+) =
Tabla 3. Clculo de OP.
Observacin: El factor multiplicador de cada celda refleja el esfuerzo relativo requerido para implementar
un tipo de objeto con un nivel de complejidad dado.
Paso 4: Clculo de los Nuevos Puntos Objeto (New Object Points, NOP).
El clculo de los NOP corresponde a la consideracin del reuso como un factor importante dentro de la
estimacin del tamao del producto final.
NOP= (OP)/(100-%r)/100
Donde %r corresponde a los objetos (informes, ventanas y componentes de 3GL) de proyectos previos que
sern reutilizados en el proyecto actual.
B. Estimacin de PROD
Paso 1: Determinacin de la razn de productividad PROD.
Para el clculo de la productividad, en la etapa 1 de COCOMO 2.0 se consideran dos aspectos clave: la
experiencia y la capacidad de los desarrolladores, y la madurez y la capacidad de ICASE. Cada uno de estos
factores debe ser clasificado como muy bajo, bajo, nominal, alto o muy alto, para luego y segn la siguiente
tabla establecer el valor de la razn de productividad, PROD.
Experiencia y capacidad de
los desarrolladores
Muy
Baja
Baja Nominal Alta Muy
Alta
Madurez y capacidad de
ICASE
Muy
Baja
Baja Nominal Alta Muy
Alta
PROD 4 7 13 25 50
Tabla 4. Estimacin de la razn de productividad (PROD).
Dado que el valor que tomen los factores involucrados puede ser substancialmente diferente (Por ejemplo:
Experiencia y capacidad de los desarrolladores= Alta, y Madurez y capacidad de ICASE= Muy Baja) los
autores recomiendan privilegiar el valor ms cercano al nominal.
4
3 ETAPAS 2 Y 3: THE EARLY DESIGN MODEL & THE POST-
ARCHITECTURE MODEL
3.1 Descripcin general
Una vez que la etapa de planificacin ha sido aprobada, es necesario tomar decisiones sobre las arquitecturas
y los conceptos de operacin alternativos. Luego, COCOMO 2.0 establece una segunda etapa orientada
precisamente a apoyar esta tarea.
La etapa 2 cuenta con mayor informacin sobre los requerimientos del proyecto, mas sta an es insuficiente
para una estimacin precisa. Ante ello COCOMO 2.0 propone utilizar los puntos de funcin (Function Points,
FP) como estimador de tamao, pues ofrecen una descripcin mejor que los OP para estimar la funcionalidad
capturada en los requerimientos.
COCOMO 2.0 define, adems, una tercera etapa orientada a entregar informacin (estimaciones) sobre el
estado del proyecto para facilitar el control de posibles desviaciones en relacin a la planificacin inicial
(tiempo y esfuerzo) durante el desarrollo del sistema. Esto implica que se cuenta con mayor informacin
sobre el sistema, por lo que COCOMO 2.0 sugiere la contabilizacin de las lneas de cdigo (LOC) y el uso
de cost drivers de una manera similar a COCOMO original, incorporando modelos de reuso, modelos
reingeniera, y nuevos cost drivers.
3.2 Estimacin de esfuerzo
A. Estimacin del esfuerzo nominal
Para ambas etapas el esfuerzo nominal es definido como:
PM
nominal
= A* (Tamao)
B
Donde
A: constante
B: factor de economa des-economa de escala
Tamao: KSLOC
Paso 1: Determinacin de la constante A.
El propsito de la constante es capturar el efecto multiplicador del aumento del tamao de un proyecto. Hasta
el momento ha sido establecida temporalmente como:
A= 2.45, para la etapa 2
A= 2.55, para la etapa 3.
Paso 2: Clculo del factor de economa de escala B.
El factor de B captura la economa de escala en un proyecto. Se habla de economa de escala (B<1) cuando al
aumentar el tamao del producto al doble, el esfuerzo aumenta en una cifra menor que el doble, por lo tanto
un aumento en el tamao del producto produce un aumento de la productividad. Si el esfuerzo aumenta en el
mismo factor que el tamao se habla de equilibrio (B=1), y en el caso que aumentara ms que el doble se
habla de des-economa (B>1).
En COCOMO original este factor corresponda a una constante que variaba segn el tipo o modo de
desarrollo de software (orgnico, semi-desconectado, o embebido). Sin embargo durante el desarrollo de
COCOMO 2.0 se establece que es ms adecuado determinar B segn los elementos que influyen sobre la
5
productividad del desarrollo, es decir los factores de escala que determinan una economa o des-economa de
escala. Estos son:
Precedentes (Precedentedness , PREC): experiencia de los desarrolladores en el desarrollo de
proyectos similares.
Flexibilidad (Development Flexibility, FLEX): flexibilidad del proceso de desarrollo en relacin con
los requerimientos establecidos.
Arquitctura y resolucin de los riesgos (Architecture/ Risk Resolution, RESL): gestin de los riesgos
medido como porcentaje de respuesta que es capaz de lograr la organizacin ante la ocurrencia de
algn riesgo.
Cohesin del equipo (Team Cohesion, TEAM): tipo de interaccin de los miembros de la
organizacin desarrolladora.
Madurez del proceso (Process Maturity, PMAT): nivel de madurez de la organizacin en relacin
con las reas de prcticas clave (Key Practices Areas, KPA) del CMM (Capability Maturity Model).
Cada uno de estos factores de escala es ponderado con un peso w
i
, que vara entre 0 y 5, segn los criterios de
la siguiente tabla:
Scale
Fators
Very
Low
Low Nominal High Very
High
Extra
High
w
i
5 4 3 2 1 0
PREC
thoroughly
unpreceden
ted
largely
unpreceden
ted
somewhat
unpreceden
ted
generally
familiar
largely
familiar
Throughly
familiar
FLEX
rigorous occasional
relaxation
some
relaxation
general
conformity
some
conformity
general
goals
RESL
little
(20%)
some
(40%)
often
(60%)
Generally
(75%)
mostly
(90%)
full
(100%)
TEAM
very
difficult
interactions
some
difficult
interactions
basically
cooperative
interactions
largely
cooperative
highly
cooperative
seamless
interaction
PMAT
Weighted average of Yes answers to CMM Maturity Questionnaire
Tabla 5. Ponderacin de los factores de escala.
Para calcular el PMAT se evala el porcentaje de cumplimiento de las 18 reas de prcticas clave definidas en
el CMM del Software Engineering Institute, SEI (Ver tabla 6). Luego el PMAT se calcula como:
PMAT= 5 - (((KPA%*i)/100)*5/18) ,i=1,..,18
KPA Almost
always
Often About
half
Occassion_
ally
Rarely if
ever
Does
not
apply
Dont
know
KPA% >90% 60-90% 40-60% 10-40% <10%
Requeriments Management o o o o o o o
Software Project Management o o o o o o o
Software Project Tracking and
Oversight
o o o o o o o
Software Subcontract Management o o o o o o o
Software Configuration Management o o o o o o o
Software Quality Assurance o o o o o o o
Organization Process Focus o o o o o o o
Organization Process Definition o o o o o o o
Trainning Program o o o o o o o
Integrated Software Management o o o o o o o
Software Product Engineering o o o o o o o
Intergoup Coordination o o o o o o o
Peer Reviews o o o o o o o
6
KPA Almost
always
Often About
half
Occassion_
ally
Rarely if
ever
Does
not
apply
Dont
know
KPA% >90% 60-90% 40-60% 10-40% <10%
Quantitative Process Management o o o o o o o
Software Quality Management o o o o o o o
Defect Prevention o o o o o o o
Tecnology Change Mangement o o o o o o o
Process Change Management o o o o o o o
Tabla 6. Cuestionario de madurez del CMM (continuacin).
Una vez ponderados los factores de escala es posible calcular el factor de economa de escala, B, como:
B= 0,91 + 0,01* w
i
, i=1,..,5
Donde w
i
corresponde al peso asignado a cada factor de escala.
Paso 3: Estimacin de tamao.
El mtodo para estimar el tamao en COCOMO 2.0 est fuertemente determinado por la informacin
disponible. Como se vio anteriormente en la etapa 1, dada la escasa informacin, el tamao se calcula en
trminos de OP. En la etapa 2, la situacin es diferente, la especificacin de requerimientos ya es ms slida
por lo que una estimacin por medio de puntos de funcin (Function Points, FP) y su traduccin a miles de
lneas de cdigo (KSLOC) parece ms adecuada. En la etapa 3 en cambio, ya se est en el desarrollo
propiamente tal. Luego, dependiendo del estado de avance del desarrollo se podran contabilizar las lneas de
cdigo directamente, en caso contrario se mantiene el clculo por PF.
El clculo de FP se realiza segn el procedimiento establecido por IFPUG. Sin embargo, para COCOMO 2.0
lo relevante es establecer los puntos de funcin no ajustados (Unadjusted Function Points, UFP). Es ms, el
tamao en KSLOC es calculado por tabla a travs del valor de UFP y no PF.
En relacin a las LOC la dificultad se encuentra en la definicin de qu es o no una LOC. Para establcer
consistencia al momento de contabilizar las LOC directamente se sugiere utilizar la Checklist de definicin de
LOC del SEI. Mostrado a continuacin.
7
8
Paso 4: Ajuste del tamao por reuso.
Al igual que en la etapa 1, en las presentes etapas el reuso es considerado un factor importante dentro de la
estimacin. Para ambos casos, se calculan las lneas de cdigo equivalentes (ESLOC) producto del reuso.
Este clculo requiere de la estimacin de los siguientes elementos de entrada :
ASLOC: tamao del software (en LOC) que debe ser adaptado.
DM: porcentaje de diseo que debe modificarse en el software para adaptarlo a los nuevos objetivos
y al nuevo ambiente.
CM: porcentaje de cdigo que debe modificarse en el software para adaptarlo a los nuevos objetivos
y al nuevo ambiente.
IM: porcentaje del esfuerzo de integracin original que debe ser modificado para integrar el software
reusado.
Adems, en la estimacin de las ESLOC se consideran la influencia de los siguientes elementos:
La comprensin del software (Software Understanding, SU) que ser reutilizado en trminos de su
estructura, su correspondencia con la aplicacin en desarrollo y la documentacin disponible.
El nivel de evaluacin y asimilacin (Assessment & Assimilation, AA) requerido para determinar
cundo un modulo es apropiado o no para la aplicacin y para integrar su descripcin a la
descripcin del producto.
La familiaridad del programador con el software que ser reutilizado. (Programmer`s Unfamiliarity,
UNFM)
Cada uno de estos factores es calculado por medio de las tablas 8, 9 y 10 respectivamente.
Very
Low
Low Nominal High Very High
SU (%) 50 40 30 20 10
Structure
Very low
cohesion,
high
coupling,
spaghetti
code
Moderately low
cohesion, high
coupling
Reassonably
well structured,
some weak
areas
High cohesion,
low coupling
Strong
modularity,
information
hiding in
data/control
structures
Application
Clarity
No match
between
program and
application
world views
Some
correlation
between
program and
application
Moderate
correlation
between
program and
application
Good
correlation
between
program and
application
Clear match
between
program and
application
world views
Self
Descriptive
ness
Obscure
code;
documentatio
n missing,
obscure or
obsolete
Some code
commentary
and headers;
some useful
documentation
Moderate levels
of code
commentary,
headers,
documentations
Good code
commentary
and headers,
useful
documentation;
some weak
areas
Self descriptive
code,
documentation
up to date, well
organized with
design rationale
Tabla 8. Estimacin del SU.
AA Increment Level of AA Effort
0 None
2 Basic module search and documentation
4 Some module Test and Evaluation, documentation
6 Considerable module Test and Evaluation,
documentation
8 Extensive module Test and Evaluation,
documentation
Tabla 9. Estimacin del AA.
9
UNFM Increment Level of Unfamiliarity
0,0 Completely familiar
0,2 Mostly familiar
0,4 Somewhat familiar
0,6 Considerably familiar
0,8 Mostly unfamiliar
1,0 Completely unfamiliar
Tabla 10. Estimacin del UNFM.
Una vez determinados los ASLOC, DM, CM, IM, SU, AA y UNFM es posible calcular las ESLOC como:
ESLOC=[ASLOC(AA+AAF(1+0,02(SU)(UNFM)))]/100, AAF<=0,5
ESLOC=[ASLOC(AA+AAF+(SU)(UNFM))]/100, AAF>0,5
Donde AAF= 0,4(DM) + 0,3(CM) + 0,3(IM)
Paso 5: Ajuste por reingeniera.
Otro de los aspectos considerados importantes en el momento de estimar el esfuerzo nominal es la
reingeniera, la cual se entiende como la capacidad de migrar automticamente de la aplicacin A a B. La
reingeniera es considerada mediante el siguiente ajuste:
PM
nominal
= A* (Tamao)
B
+ [ASLOC (AT/100)/ATPROD]
Donde
ASLOC: tamao del software (LOC) que debe ser adaptado (estimado subjetivamente).
AT: % del cdigo que ser reingenierado mediante traduccin automtica (Ver tabla 11).
ATPROD: razn de productividad de la traduccin automtica. (temporalmente, 2400[LOC/ Person-
month] )
Re-engineering target AT
Batch processing 96%
Batch with SORT 90%
Batch with DBMS 88%
Batch, SORT, DBMS 82%
Interactive 50%
Tabla 11. Estimacin del AT.
B. Estimacin del esfuerzo ajustado
En forma anloga a COCOMO 81, COCOMO 2.0 considera en sus etapas 2 y 3 el ajuste del esfuerzo nominal
al considerar un conjunto de cost drivers, cuyo efecto es ponderado obtenindose un mutliplicador de
esfuerzo (Effort multipliers, EM
i
) asociado a cada cost driver.
PM
ajustado
= PM
nominal
* EM
i
Los cost drivers considerados varan segn la etapa del modelo de COCOMO 2.0 que se utilice.
10
Multiplicadores de esfuerzo de Etapa 2.
La etapa 2 considera 7 cost drivers apreciables en la tabla 12. En trminos globales, cada uno de los cost
drivers pertenecientes a la etapa 2 corresponde la agrupacin de uno o ms cost drivers de la etapa 3:
Cost Driver Description Counterpart Combined
Post-Architecture
(Stage 3) Cost Driver
PERS Personnel capability ACAP, PCAP, PCON
RCPX Product reliability and
complexity
RELY, DATA, CPLX,
DOCU
RUSE Required reuse RUSE
PDIF Platform difficulty TIME, STOR, PVOL
PREX Personnel experience AEXP, PEXP,LTEX
FCIL Facilities TOOL, SITE
SCED Schedule SCED
Tabla 12. Cost Drivers de la Etapa 2.
En el caso de RUSE y de SCED sus respectivos EM son calculados directamente a partir de las tablas 13 y 14.
En el caso de los cost drivers restantes se calcula el EM para los cost drivers de la etapa 3 que lo componen y
luego se calcula el EM como el promedio de los EM de sus componentes. Por ejemplo, EM
PDIF
=[EM
PDIF
+
EM
PDIF
+ EM
PDIF
]/ 3.
Multiplicadores de esfuerzo de Etapa 3.
La etapa 3 se compone de 17 cost drivers, cada uno de los cuales es clasificado como Very Low hasta Extra
High segn la tabla 13. Una vez clasificado el cost driver se obtiene el EM respectivo por medio de la tabla
14.
11
Tabla 13. Clasificacin de los cost drivers para la etapa 3.
12
13
Very
Low
Low Nominal High Very
High
Extra
High
Factores de producto
RELY
0.75 0.88 1.00 1.15 1.39 -
DATA
- 0.93 1.00 1.09 1.19 -
CPLX
0.7 0.88 1.00 1.15 1.30 1.66
RUSE
- 0.91 1.00 1.14 1.29 1.49
DOCU
- 0.95 1.00 1.06 1.13 -
Factores de plataforma
TIME
- - 1.00 1.11 1.31 1.67
STOR
- - 1.00 1.06 1.21 1.57
PVOL
- 0.87 1.00 1.15 1.30 -
Factores de personal
ACAP
1.50 1.22 1.00 0.83 0.67 -
PCAP
1.37 1.16 1.00 0.87 0.74 -
AEXP
1.22 1.10 1.00 0.89 0.81 -
PEXP
1.25 1.12 1.00 0.88 0.81 -
LTEX
1.22 1.10 1.00 0.91 0.84 -
PCON
1.24 1.10 1.00 0.92 0.84 -
Factores del proyecto
TOOL
1.24 1.12 1.00 0.86 0.72 -
SITE
1.25 1.10 1.00 0.92 0.84 0.78
SCED
1.29 1.10 1.00 1.00 1.00 -
Tabla 14.
3.3 Estimacin de tiempo de desarrollo
Una vez calculado el esfuerzo ajustado es posible, estimar el tiempo de desarrollo:
TDEV= [3,67*(PM
x
)
(0,28+0,2*(B-1.01))
]*SCED%/100
Donde
TDEV: tiempo de desarrollo desde el establecimiento de la baselineK de requerimientos hasta la
aceptacin del producto final.
PM
x
: estimacin del esfuerzo ajustado sin considerar el cost driver SCED.
3.4 Mantencin
La aplicacin de COCOMO 2.0 a la etapa de mantencin asume el trmino del desarrollo del software y la
contabilizacin de las lneas de cdigo de ste (Tamao del Cdigo Base). Luego:
(Tamao)
M
= [(Tamao del Cdigo Base)*MCF]*MAF
Donde
(Tamao)
M
: estimacin del tamao en KSLOC asociado a la mantencin
MCF (Maintenance Change Factor): porcentaje de cambios en el cdigo base . Este factor es el
equivalente al ACT de mantencin en COCOMO 81, salvo por que el MCF puede estar asociado a
cualquier perodo (ACT impone un perodo de 12 meses).
14
MCF= (Tamao agregado + Tamao modificado)/Tamao del Cdigo Base
MAF (Maintenance Adjustment Factor): factor de ajuste de mantencin.
MAF= 1+((SU/100)*UNFM)
Luego, el esfuerzo asociado a mantencin se calcula como:
PM
M
=A*(Tamao
M
)
B
* EM
i
,i=1,..,17
Adems, si se conoce el tiempo o el personal de mantencin es posible calcular el personal o el tiempo
respectivo mediante:
PM
M=
T
M*
FSP
M