Apunte COCOMOII

Estimacin de Proyectos
COCOMO II

Prctica Profesional
2009

Estimacin de Proyectos COCOMO II

Prctica Profesional - 2009 2 de 20

INDICE

1. MTODO DE ESTIMACIN: COCOMO II
3
2. ESTIMACIN DEL ESFUERZO NOMINAL
MODELOS DISEO ANTICIPADO Y POST-ARQUITECTURA
5
2. 1. CLCULO DEL FACTOR ESCALAR B
6
2. 2. CLCULO DEL TAMAO
11
3. ESTIMACIN DEL ESFUERZO AJUSTADO
DISEO ANTICIPADO Y POST-ARQUITECTURA
12
3. 1. FACTORES DE AJUSTE DEL MODELO DE DISEO ANTICIPADO
13
3. 2. FACTORES DE AJUSTE DEL MODELO DE POST-ARQUITECTURA
15
4. ESTIMACIN DEL TIEMPO DE DESARROLLO
20
5. BIBLIOGRAFA
20



1. MTODO DE ESTIMACIN: COCOMO II

El proceso de Planificacin de un proyecto requiere hacer frente al problema de
dimensionar adecuadamente los costos, esfuerzos y tamao de una aplicacin software,
siendo sta una tarea compleja y de difcil definicin.

Se desarrollaron varias tcnicas y herramientas que facilitan la correcta dimensin del
costo, tiempo y el esfuerzo. Una de estas herramientas, fue creada por Barry Bhem y
conocida como COCOMO (Constructive Cost Model, modelo de construccin de costos).

El modelo COCOMO nace en 1981, y es el precursor de COCOMO II siendo tambin su
autor Barry Bhem en el ao 1998. En este ltimo se introdujeron mejoras considerando las
ventajas que proveen algunos entornos de desarrollo de hoy en da como son la reutilizacin
de cdigo a travs de herramientas que estandarizan y facilita la administracin de cdigo
reutilizable, modelos de desarrollo no secuenciales, desarrollos orientados a objetos, etc.

Para lograr el principal objetivo de COCOMO II, que es permitir estimaciones precisas del
costo, tiempo y esfuerzo, ste modelo se basa en tres premisas:

Primero, a diferencia del modelo COCOMO original, en el que se basa en un nico
modelo de ciclo de vida del software, considera el mejor ciclo de vida dependiendo
del tipo de proyecto y sus caractersticas as como el entorno de desarrollo.

Segundo, el grado de informacin con el que se cuenta para el modelo de estimacin
de software usado debe ser consistente con el grado de informacin disponible que
soporta al modelo. Permitiendo esto tratar al proyecto dependiendo de la etapa en
que se encuentra, es decir en las etapas tempranas del proyecto, muy poco puede
ser conocido sobre el tamao del producto final, naturaleza de la plataforma a im-
plementar, el nivel de conocimientos tcnicos y de trabajo en grupo del personal in-
volucrado, o las especificaciones detalladas de los procesos.

Tercero, considerando los dos primeros aspectos, COCOMO II permite trabajar
con los proyectos de forma que en las etapas tempranas se trabaja con informacin
de alto nivel y se conoce como etapa de diseo preliminar, mientras que a medida
que se avanza con el proyecto se baja el nivel de informacin conforme se va cono-
ciendo las caractersticas del mismo y se entra en la etapa de diseo detallado.

COCOMO II proporciona una familia de modelos de estimacin de costo de software cada
vez ms detallado y tiene en cuenta las necesidades de cada sector y el tipo de informacin
disponible para sostener la estimacin.

Esta familia de modelos est compuesta por tres submodelos cada uno de los cuales ofrece
mayor fidelidad a medida que uno avanza en la planificacin del proyecto y en el proceso de
diseo. Estos tres submodelos se denominan:



Modelo de Composicin de Aplicaciones.
Usualmente indicado para proyectos construidos con herramientas modernas de
construccin de interfaces grficos para usuario.
Las primeras fases o ciclos en espiral utilizados en proyectos software que impliquen
prototipado y utilizarn el Modelo de Composicin de Aplicaciones COCOMO II, que
soporta estas fases y cualquier otra actividad de prototipado que se realice ms
adelante en el ciclo de vida.
Este modelo se dirige a aplicaciones que estn demasiado diversificadas para crearse
rpidamente en una herramienta de dominio especfico, (como una hoja de clculo) y que
todava no se conocen suficientemente como para ser compuestas a partir de
componentes interoperables. Ejemplos de estos sistemas basados en componentes son
los creadores de interfaces grficas para usuario, bases de datos gestores de
objetos, middleware para proceso distribuido transaccional, manejadores hipermedia,
buscadores de datos pequeos y componentes de dominio especfico tales como
paquetes de control de procesos financieros, mdicos industriales.
Dado que el Modelo de Composicin de Aplicaciones incluye esfuerzos de prototipado
para resolver asuntos potenciales de alto riesgo tales como interfaces de usuario,
interaccin software/sistema, ejecucin grado de madurez tecnolgica, los costos de
este tipo de esfuerzo se estiman mejor mediante este modelo.

Modelo de Diseo anticipado.
Este modelo puede utilizarse para obtener estimaciones aproximadas del costo de un
proyecto antes de que est determinada por completo su arquitectura. Utiliza un
pequeo conjunto de drivers de costo nuevo y nuevas ecuaciones de estimacin. Est
basado en Punto de Funcin sin ajustar o KSLOC (Miles de Lneas de Cdigo Fuente).
Las primeras fases o ciclos en espiral se ajustan mejor al modelo de Composicin de
Aplicaciones. Las siguientes fases ciclos espirales normalmente incluirn la
exploracin de arquitecturas alternativas estratgicas de desarrollo incremental.
Para sostener estas actividades COCOMO II proporciona un modelo de estimacin
anticipado: el Modelo de Diseo Anticipado. El nivel de detalle de este modelo puede
ser consistente con el nivel general de informacin disponible y con el nivel general de
aproximacin de la estimacin requerida en esta etapa.
El Diseo Anticipado incluye la exploracin de arquitecturas de software/sistema
alternativas y conceptos de operacin. En esta fase no se sabe lo suficiente como para
dar soporte a la estimacin de grano fino. La correspondiente capacidad de COCOMO
II incluye el uso de Puntos de Funcin y un conjunto de siete drivers de costo de grano
grueso (por ejemplo, dos drivers de coste para capacidad del personal y Estimacin de
Proyectos Software experiencia del personal en lugar de los seis drivers de costo del
Modelo Post-Arquitectura que cubren varios aspectos de capacidad del personal,
continuidad y experiencia).
El modelo de Diseo Anticipado usa Puntos de Funcin No Ajustados como mtrica de
medida. Este modelo se utiliza en las primeras etapas de un proyecto software, cuando
se conoce muy poco sobre el tamao del producto que se va a desarrollar, la naturaleza



de la plataforma objetivo, la naturaleza del personal involucrado en el proyecto
especificaciones detalladas del proceso que se va a usar.

Modelo Post-Arquitectura.
Este es el modelo COCOMO II ms detallado. Se utiliza una vez que se ha desarrollado
por completo la arquitectura del proyecto. Tiene nuevos drivers de costo, nuevas reglas
para el recuento de lneas y nuevas ecuaciones.
Las primeras fases o ciclos en espiral de proyectos software se ajustan mejor al
modelo de Composicin de Aplicaciones y las siguientes fases ciclos espirales
normalmente sern sostenidas por el modelo de Diseo Anticipado. Una vez que el
proyecto est listo para desarrollar un sistema especializado, debe haber informacin
ms precisa de los drivers de costo de entradas y permita clculos de costo ms
exactos. Para apoyar esta etapa COCOMO II proporciona el Modelo Post-Arquitectura.
El Modelo Post-Arquitectura incluye el actual desarrollo y mantenimiento de un
producto software. El modelo utiliza instrucciones fuente y/ Puntos de Funcin para
medir, con modificadores para reutilizacin y objetos software; un conjunto de 17
drivers de costo multiplicativos; y un conjunto de 5 factores que determinan el
exponente de escala del proyecto.

2. ESTIMACIN DEL ESFUERZO NOMINAL
MODELOS DISEO ANTICIPADO Y POST-ARQUITECTURA

En el modelo COCOMO II el esfuerzo se expresa en personas afectadas al proyecto sobre
la cantidad de meses que estn afectadas, y la unidad de medida es PM (del ingles Person
per Month o personas por mes).

Este valor indica la cantidad de tiempo en meses que una nica persona empleara
trabajando en el desarrollo del proyecto, debindose excluir el perodo de vacaciones,
feriados y fines de semana. Es de remarcar la diferencia entre el nmero de personas por
mes que requiere el proyecto de cuanto tiempo requiere el proyecto para estar finalizado,
esto ltimo depender de la cantidad de recursos involucrados al proyecto. Por ejemplo, se
puede hablar que un proyecto lleva de esfuerzo PM=40, y tiene un plan de accin que
culmina el proyecto en 15 meses, es decir involucrar a mas de una persona para llegar a
cumplirlo en 15 meses.

La forma en que COCOMO II llega a obtener el valor del esfuerzo del proyecto es a travs
de la ecuacin abajo descripta e identificada como ecuacin E1. En la misma se pueden
diferenciar tres valores a saber:

PM
nominal
= A x (Tamao)
B
(E1)

Tamao del software a desarrollarse, que se expresa en miles de lneas de cdigo
(del ingles KSLOC), y es un valor tangible estimado que se puede hacer cada vez ms
preciso conforme avanza la codificacin del producto.



Una constante de esfuerzo A, utilizada para reflejar los efectos en cascada del
esfuerzo requerido de acuerdo al crecimiento del tamao del software.

Un factor escalar B, las dimensiones de esta variable tienen un impacto
exponencial en el resultado, y su valor esta dado por la resultante de los aspectos
positivos sobre los aspectos negativos que presenta el proyecto. El factor escalar
B tiene un fuerte impacto dado que es un valor exponencial. Dicho factor puede
tomar valores comprendidos en un rango determinado.

Si B < 1.0 el proyecto est enmarcado en la escala de aspectos positivos, donde se
refleja:
Si el tamao del producto se duplica, el esfuerzo en el proyecto ser menor
que el doble dada la sinergia que se puede obtener en el proyecto.
La productividad del proyecto se incrementa en relacin directa con el
tamao del proyecto.
Generalmente estos aspectos positivos pueden ser detectados ms fcilmente con
la ayuda de herramientas para la gestin del proyecto pero en general son muy
difciles de conciliar. En caso de proyectos de pequea envergadura, los costos de
puesta en marcha al igual que la utilizacin de estndares en el proceso de
instalacin y la cantidad de reportes administrativos requeridos son los que se
pueden utilizarse para dimensionar este factor.

Si B = 1.0 los aspectos positivos y negativos del proyecto estn balanceados,
siendo ste generalmente es el factor que se utiliza en proyectos pequeos.

Si B > 1.0 el proyecto refleja aspectos negativos, que generalmente se ven
afectaos por dos aspectos comnmente conocidos que son el crecimiento de las
comunicaciones interpersonales, y el crecimiento de la integracin de grandes
sistemas. Esto se debe a que los grandes proyectos tienen un nmero elevado de
personas involucradas, por consiguiente las comunicaciones interpersonales se ven
incrementadas consumiendo mucho tiempo y recursos. Por otro lado integrar un
proyecto pequeo como parte de un gran sistema requiere no solo el esfuerzo de
desarrollo del producto, sino el esfuerzo adicional de disear, mantener, integrar y
probar sus interfaces.

2. 1. CLCULO DEL FACTOR ESCALAR B

El factor escalar B tiene relevancia en la frmula del esfuerzo y su forma de clculo est
directamente relacionada con las caractersticas del proyecto conocidas en ste modelo
como variables escalares.

En todo proyecto de desarrollo de software se deben considerar algunos que indican las
caractersticas que ste presenta en lo que a su complejidad y entorno de desarrollo se
refieren. Estas caractersticas adoptan diferentes nombres segn el modelo utilizado, y
para el caso de COCOMO II se conocen como variables escalares, teniendo stas variables
un impacto directo en el valor que tomar el factor escalar B.



Las variables escalares en el modelo COCOMO II son conocidas como:
PREC: precedencia
FLEX: flexibilidad del desarrollo
RSEL: fortaleza de la arquitectura y mtodos de estimacin y reduccin de riesgos
TEAM: cohesin y madurez del equipo de trabajo
PMAT: madurez del proceso

La seleccin de estas variables no fue arbitraria segn los criterios del autor del modelo,
sino que se basan en los aspectos significativos de un proyecto que son claves a la hora de
determinar variaciones en el esfuerzo o productividad. Teniendo cada una de ellas un rango
de niveles que varan en: Extra Alto, Muy Alto, Alto, Nominal, Bajo y Muy Bajo. En la tabla
T1 se detallan las caractersticas de las variables escalares y los valores que pueden tomar.

Tabla T1: variables escalares para el modelo COCOMO II

Variable de Precedencia (PREC)

Variable Caracterstica del Proyecto Muy Bajo Nominal/Alto Extra
Alto
PREC Comprensin organizacional de los
objetivos del proyecto
General Considerable Profundo
Experiencia trabajando en sistemas
SW relacionados
Moderada Considerable Extensa
Desarrollos concurrentes de nuevo
HW asociados a nuevas tecnologas y
procedimientos operacionales
Extenso Moderado Algo
Necesidad de procesamiento de da-
tos, arquitecturas o algoritmos inno-
vadores
Considerable Algo Mnima

Escala de factores para los modelos Diseo Preliminar y Post Arquitectura
Factor
(W
i
)
Muy bajo

Bajo

Nominal

Alto

Muy alto

Extra alto

PREC
Sin
Precedentes
6,20
Muy pocos
precedentes
4,96
Pocos
Precedentes
3,72
Familiar
2,48
Muy
Familiar
1,24
Totalmente
familiar
0
FLEX

Riguroso
5,07
Ocasional
4,05
Algo
Flexible
3,04
Conformidad
gral.
2,03
Algo
Conforme
1,01
Metas
Generales
0
RESL

Poco (20%)
7,07
Algo (40%)
5,65
A menudo
(60%)
4,24
Usualmente
(75%)
2,83
Mayormen-
te (90%)
1,41
Totalmente
(100%)
0
TEAM

Interaccin
muy difcil
5,48
Interaccin
algo difcil
4,38
Interaccin
bsicamente
cooperativa
3,29
Bastante
cooperativa
2,19
Altamente
cooperativa
1,10
Interaccin
sin fisuras
0
7,80 6,24 4,68 3,12 1,56 0
PMAT

Promedio ponderado de "SI" en respuesta del cuestionario de madurez del CMM



Variable Flexibilidad de Desarrollo (FLEX)

Variable Caracterstica del Proyecto Muy Bajo Nominal/Alto Extra
Alto
FLEX Necesidad de aceptacin
formal del software de acuerdo
a requisitos preestablecidos
Total Considerable Bsicos
Necesidad de conformidad y
aceptacin del software con
requerimientos de interfaces
externas
Total Considerable Bsicos
Requerimientos de finalizacin
temprana de los proyectos
Alto Medio Bajo

Variable escalar de fortaleza de la arquitectura y resolucin de riesgos (RSEL)

Esta variable combina dos caractersticas de factores escalares del Fortaleza del diseo
y Eliminacin de riesgos usando Plan de Riesgos. La valorizacin de RSEL es subjetiva de
acuerdo al peso promedio de las caractersticas que se muestran en la tabla.

Caractersticas Muy
Bajo
Bajo Nominal Alto Muy Alto Extra
Alto
Plan de control de riesgo
identificando los puntos crticos,
estableciendo hitos para su
resolucin
No
existe
Poco Algo
General-
mente
A
menudo
Total
Fechas, presupuesto e hitos
internos acorde al PDR y
compatible con el plan de
gestin de riesgos
No
Existe
Poco Algo
General-
mente
A
menudo
Total
Porcentaje de horario de
desarrollo dedicado a establecer
la arquitectura, segn los
objetivos generales del producto
5 % 10 % 17 % 25 % 33 % 40 %
Porcentaje de arquitectos SE de
alto nivel requeridos, disponibles
para el proyecto
20 % 40 % 60 % 80 % 100 % 120 %
Herramientas de Soporte
disponibles para resolver tems
de riesgo, y desarrollar y verificar
las especificaciones de la
arquitectura
No
Existe
Poco Algo Bueno
Muy
Buenos
Total
Nivel de incertidumbre en puntos
clave de la arquitectura como
son la misin, interfaces de
usuarios, COTS, hardware,
tecnologa, performance
Extre-
mo
Signifi-
cante
Conside-
ra-ble
Algo Poco
Muy
Poco
Nmero y criticalidad de tems
de riesgo en el proyecto
>10
Crticos
5-10
Crticos
2-4
Crticos
1 Crtico
> 5 No
Crticos
< 5 No
Crticos



Variable de cohesin e integridad del equipo (TEAM)

La variable escalar TEAM (Cohesin del equipo) registra las fuentes de disturbios y
entropa debido a dificultades en la sincronizacin de los integrantes y afectados al
proyecto, incluyendo usuarios, clientes, desarrolladores, personal de mantenimiento,
generadores de interfaces, etc. Estas dificultades generalmente responden a alguno de los
siguientes motivos: Diferencia de objetivos y/o culturas, dificultades en reconciliar
objetivos, falta de experiencia del plantel en el trabajo en equipo. La tabla siguiente
detalla las caractersticas para definir el nivel de la variable TEAM, siendo el resultado un
valor subjetivo que depende del promedio de los pesos de las diferentes caractersticas.

Caracterstica Muy
Bajo
Alto
Consistencia en los
objetivos y culturas del
plantel
Poca Algo Bsica Considerable Fuerte Total
Habilidad y servicialidad
del plantel para acomodar
objetivos de otros grupos
Poca Algo Bsica Considerable Fuerte Total
Experiencia del plantel en
el trabajo en equipo
Nada Poca Poca Bsica Considerable Extensa
Experiencia del plantel en
lograr una visin
compartida y compromisos
Nada Poca Poca Bsica Considerable Extensa

Variable de madurez del proceso de desarrollo (PMAT)

El procedimiento para determinar la madurez del proceso (PMAT) se basa en los
lineamientos del CMM (Capability Maturity Model) del Software Engineering Institute
(SEI). El momento de medicin de sta variable es al comienzo del proyecto. Se puede
obtener PMAT de dos maneras diferentes. La primera de ellas es tomando el resultado de
una evaluacin formal basada en el CMM, y la segunda basado en las reas claves de
procesos de desarrollo.

a) Segn el Nivel de Madurez:
Nivel 1 (inferior) CMM
Nivel 1 (superior) del CMM
Nivel 2 del CMM
Nivel 3 del CMM
Nivel 4 del CMM
Nivel 5 del CMM

b) Segn las reas claves del proceso de desarrollo
Se organiza en base a 18 reas claves del proceso de desarrollo (KPA, del ingls Key
Process Areas) del modelo CMM del SEI. El procedimiento para determinar la variable
PMAT esta basado en el porcentaje de cumplimiento de cada KPA. Para la identificacin de
stos porcentajes se pueden utilizar el resultado formal de un anlisis de CMM del
proceso, o utilizando un conjunto de niveles denominado escala de Likert, el cual se refleja
en la tabla siguiente. El nivel de conformidad se determina con la media basada en el
anlisis de las metas de cada rea de proceso principal.



reas claves
de procesos
Casi
Siempre
>90%
A
Menudo
60-90%
La
mitad
40-60%
En
ocasiones
10-40%
En pocas
ocasiones
<10%
No
aplica

No
sabe
Gestin de requerimientos
Planeamiento del proyecto
de software

Seguimiento del Proyecto
de Software

Gestin del software
subcontratado

Aseguramiento de la
calidad del software (SQA)

Gestin de configuracin
del software

Foco en el proceso de la
organizacin

Definicin de procesos de
la organizacin

Programa de formacin
Gestin de la integracin
del software

Tcnicas de ingeniera de
productos de software

Coordinacin ntergrupos
Revisiones formales e
informales

Gestin para cuantificar
los procesos

Gestin de calidad del
software

Prevencin de defectos
Gestin de cambios
tecnolgicos

Gestin de cambios de
procesos

Para completar la tabla seleccione:
Casi Siempre cuando los objetivos sean firmemente alcanzados y estn bien definidos a
travs de procedimientos estndar (ms del 90% de los casos)
A menudo cuando los objetivos sean frecuentemente alcanzados, aunque en algunos
casos por diferentes motivos no sea as (aproximadamente entre el 60 al 90% de los
casos)
La mitad cuando los objetivos sean alcanzados en promedio la mitad de las veces (entre
el 40 al 60%)
En ocasiones cuando los objetivos son alcanzados de vez en cuando, no muy a menudo
(entre el 10 y el 40% de los casos)
En pocas ocasiones cuando raramente, si es que sucede alguna vez, se alcanzan los
objetivos (menos del 10% de los casos)
No aplica cuando se tenga el conocimiento adecuado sobre el rea de proceso clave
(KPA) pero sta no tenga relevancia en el proyecto
No sabe cuando no haya una certeza en la respuesta para el KPA.



Luego de completar la tabla, se puede determinar el peso de cada nivel y llegar a calcular el
valor para PMAT de acuerdo a lo expresado en la ecuacin E2.

18
PMAT= 5 [ ( KPA%
i
/ 100) x ( 5 / 18 )] (E2)
i=1

Para calcular el Factor Escalar B se utiliza la ecuacin E3. La letra W representa los
valores adoptados por cada una de las variables escalares segn el mtodo de clculo
basado en el anlisis de las KPA.

B = 0.91 + 0.01 x SUM (W
i
) (E3)

Finalmente se aplica la frmula para el clculo del esfuerzo

PM
nominal
= A x (Tamao)
B
(E1)

Por ejemplo: un proyecto que involucra 100 KSLOC (equivalente 100000 lneas de cdigo),
donde la sumatoria de las variables escalares es 10 (W=10), y consideramos la constante
de esfuerzo A con un valor nominal (A =2,45) tendremos el resultado es:

B = 0.91 + 0.01 x 10 = 1,01

PM
nominal
= 2,45 x 100
1.01
= 256,55 PM

Este resultado debe interpretarse que el proyecto lleva 256 meses y medio de una sola
persona dedicada al mismo.

2. 2. CLCULO DEL TAMAO

Para estimar el tamao de la aplicacin, COCOMO al igual que muchos otros modelos
utilizan los estndares de Lneas de Cdigo y Puntos de Funcin. La determinacin de la
cantidad de lneas de cdigo es una tarea difcil debido a las diferencias sobre lneas
ejecutables, la declaracin de datos de acuerdo a los diferentes lenguajes, etc.

No obstante, tanto para la etapa de Diseo Preliminar como la de Diseo Detallado hay
disponible informacin relacionada sobre tablas de conversin de Puntos de Funcin en
Lneas de Cdigo y as poder determinar el tamao a ser usado para el clculo del valor
nominal o ajustado el esfuerzo.



Lenguaje SLOC / PF
Ada 71
AI Shell 49
APL 32
Assembler 320
Asembler con macros 213
Turbo Basic / ANSI 64
Basic Compilador - 91
Basic Interprete - 128
C 128
C++ 29
Cobol 91
Fortran 77
Jovial 105
Lisp 64
Pascal 91
Prolog 64

3. ESTIMACIN DEL ESFUERZO AJUSTADO
DISEO ANTICIPADO Y POST-ARQUITECTURA

Se puede realizar un ajuste, donde el esfuerzo nominal es sometido a un anlisis ms
profundo para estimar un Esfuerzo Ajustado que depende de la etapa del proyecto y de
sus caractersticas, que al igual que el anterior se mide en personas afectadas al proyecto
sobre la cantidad de meses de afectacin y se expresa con la unidad PM.

La forma que COCOMO II obtiene los datos necesarios para el calculo del esfuerzo
ajustado es considerando un conjunto de multiplicadores de esfuerzos (ME), representan
las caractersticas del proyecto y expresan su impacto en el desarrollo total del producto
de software. El rango de valores puede variar desde Extra Bajo a Extra Alto.

Debido a los diferentes niveles de informacin con los que se cuenta a lo largo del
desarrollo del proyecto, el modelo COCOMO II prev la utilizacin de dos conjuntos
diferentes de multiplicadores de esfuerzo. El primero de estos grupos ms general se
aplican en la etapa inicial o el diseo preliminar, mientras que un segundo conjunto con
mayor nivel de detalle y especificaciones en las caractersticas del proyecto se usa en la
etapa de diseo detallado.

El modelo de Diseo Preliminar se usa en las etapas tempranas del proyecto de software
cuando se conoce muy poco sobre el tamao del producto a ser desarrollado, la naturaleza
de la plataforma donde residir, la naturaleza del personal involucrado en el proyecto, e
incluso detalles especficos de los procesos. El modelo de Diseo Preliminar permite
obtener el esfuerzo ajustado a partir del esfuerzo nominal (PM) sometido a la influencia
de 7 multiplicadores de esfuerzo (PERS, RCPX, RUSE, PDIF, PREX, FCIL, SCED). El
esfuerzo ajustado se calcula segn la ecuacin E4.



7
PM
ajustado
= PM
nominal
x ( PROD ME
i
) (E4)
I=1

Una vez avanzado el proyecto y con conocimiento de mayor nivel de detalles de las
caractersticas y entorno de desarrollo se puede ingresar en la segunda etapa del modelo
COCOMO II, el modelo de Diseo Detallado. Este modelo es usado cuando ya est definida
y desarrollada la arquitectura del ciclo de vida del software. Utilizndose para ajustar el
valor del esfuerzo nominal 17 multiplicadores de esfuerzo (ME) diferentes que son: RELY,
DATA, CPLX, RUSE, DOCU, TIME, STOR, PVOL, PCAP, AEXP, PEXP, LTEX, PCON, TOOL,
SITE, SCED. El esfuerzo ajustado se calcula segn la ecuacin E5.

17
PM
ajustado
= PM
nominal
x ( PROD ME
i
) (E5)
I=1

Multiplicadores de esfuerzo
Modelo de Diseo Preliminar
Multiplicadores de esfuerzo
Modelo deDiseo Detallado
RCPX RELY, DATA, CPLX, DOCU
RUSE RUSE
PDIF TIME, STOR, PVOL
PERS ACAP, PCAP, PCON
PREX AEXP, PEXP, LTEX
FCIL TOOL, SITE
SCED SCED

3. 1. FACTORES DE AJUSTE DEL MODELO DE DISEO ANTICIPADO

Siempre que la evaluacin de un driver de costo est entres dos niveles de ratio, hay que
redondear al nivel ms prximo al nominal.

RCPX: Fiabilidad y complejidad del producto

Extra Bajo Muy
Bajo
Bajo Nominal Alto Muy
Alto
Extra
Alto
nfasis en la fiabilidad
y a documentacin
Muy poco Poco Algo Bsico Fuerte
Muy
fuerte
Extremo
Complejidad del
producto
Muy
simple
Simple Algo Moderada Compleja
Muy
compleja
Extrema-
damente
compleja
Medida de la base de
datos
Pequea Pequea Pequea Moderada Grande
Muy
grande
Muy
grande

RUSE: Reutilizacin requerida

Extra bajo Muy bajo Bajo Nominal Alto Muy Alto Extra Alto
Nada Por
programa
Por
proyecto
Por lnea de
producto
Por mltiples lneas
de producto



PDIF: Dificultad de la plataforma

Bajo Nominal Alto Muy Alto Extra Alto
Restricciones de tiempo y
almacenamiento
50% 50% 65% 80% 90%
Volatilidad de la plataforma Muy estable Estable Algo voltil Voltil Muy voltil

PERS: Capacidad del personal

Extra
Bajo
Muy
Bajo
Alto
Capacidad de los analistas
y los programadores para
trabajar en equipo
20% 39% 45% 55% 65% 75% 85%
Rotacin anual del personal 45% 30% 20% 12% 9% 5% 4%

FCIL: Fiabilidad y complejidad

Ext. Bajo Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
Soporte de
herramientas
SW
Mnimo Algo
CASE
simple
Herramientas
bsicas de
ciclo de vida
Bueno,
integracin
moderada
Fuerte,
integracin
moderada
Fuerte, bien
integradas
Mltiples
lugares de
desarrollo
Soporte
dbil
desarrollo
multilugar
complejo
Algo de
soporte
desarrollo
multilugar
complejos
Algo de
soporte,
desarrollo
multilugar
moderada
complejidad
Soporte
bsico,
desarrollo
multilugar
moderada
complejidad
Fuerte
soporte
desarrollo
multilugar
moderada
complejidad
Fuerte
soporte de
desarrollo
multilinge
simple
Muy fuerte
soporte
para el
desarrollo
multilinge
simple

PREX: Experiencia del personal

Extra
Bajo
Muy
Bajo
Alto
Experiencia en
aplicaciones, plataforma,
lenguaje y herramientas
<= 3
meses
5 meses 9 meses 1 ao 2 aos 4 aos 6 aos

SCED: Ajustes a la planificacin

Muy Bajo Bajo Nominal Alto Muy Alto
75% del nominal 85% 100% 130% 160%

Valores de los factores de ajuste (drives de costo)

Extra Bajo Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
RCPX 0,73 0,81 0,98 1,00 1,30 1,74 2,38
RUSE - - 0,95 1,00 1,07 1,15 1,24
PDIF - - 0,87 1,00 1,29 1,81 2,61
PERS 2,12 1,62 1,26 1,00 0,83 0,63 0,50
PREX 1,59 1,33 1,12 1,00 0,87 0,71 0,62
FCIL 1,43 1,30 1,10 1,00 0,87 0,73 0,62
SCED - 1,43 1,14 1,00 1,00 1,00 -



3. 2. FACTORES DE AJUSTE DEL MODELO DE POST-ARQUITECTURA

Siempre que la evaluacin de un driver de costo est entres dos niveles de ratio, hay que
redondear al nivel ms prximo al nominal.

RELY: Confiabilidad requerida en el software
Mide hasta qu punto el software debe realizar su funcin esperado durante un perodo de
tiempo. Si el efecto de un fracaso es una molestia ligera entonces el factor RELY es bajo.
Si una falla arriesgase vidas humanas entonces RELY es muy alto.

Muy bajo Bajo Nominal Alto Muy Alto
Pequeos
inconvenientes
Bajo, prdidas
recuperables fcilmente
Moderado,
prdidas recuperables
Alta prdida
financiera
Riesgo de vidas
humanas

DATA: Medida del volumen de datos
Es importante considerar el tamao de la Base de Datos por el esfuerzo necesario en
generar los datos de prueba. Se obtiene calculando D/P. D = Tamao de la Base de Datos
(Bytes) y P = Tamao del Cdigo (SLOC). Data se valora como Bajo si D/P es menor que 10 y
Muy alto si es mayor que 1000.

Bajo Nominal Alto Muy Alto
D/P < 10 10 D/P < 100 100 D/P < 1000 D/P 1000

CPLX: Complejidad del producto (T4 PCU)
La complejidad se decide en 5 reas: Funcionamiento de control, Funcionamiento
computacional, Funcionamiento de Dispositivos dependientes, Funcionamiento del sector de
datos y Funcionamiento del Gestor de Interfaz de usuario. Se seleccionar el rea o
combinacin de reas que caracterizan al producto o a un subsistema del producto. La
medida de complejidad es la media subjetiva de estas reas.

Operaciones
de Control
Operaciones
Computacionales
Operaciones
dependientes del
dispositivo
Operaciones
de Gestin
de Datos
Operaciones
de Gestin de
Interfaz de
usuario
Muy Bajo
Lneas de cdigo con
pocos ciclos de
operaciones en
programacin
estructurada:
DOs, CASEs,
IFTHEN ELSE.
Mdulos de
composicin simple,
por llamado a
procedimiento o
simples scripts
Evaluacin de
operaciones simples
Ej. A=B+C*(D-E)
Lecturas simples,
escritura de las
declaraciones en
formatos simples.
Arrays simple en la
memoria principal.
Simples preguntas
a la base de datos
y a los updates
Simples
entradas,
formulaciones,
generadores de
reporte.
Bajo
Anidamiento sencillo
de estructuras de
programacin
estructurada.
Mayora de
predicados simples
Evaluacin de
expresiones de nivel
medios.
Ej. D=SQRT(B**2-
4.*A*C)
No hay conciencia
de la necesidad de
un procesador en
particular o de un
dispositivo
especfico de
entrada /salida.
Archivos simples
sin cambios en la
estructura de
datos, no editados,
sin archivos
intermedios.
Complejidad
media de accesos
y updates a la BD.
Uso de
construcciones
simples en
interfaces
grficas



Operaciones
de Control
Operaciones
Computacionales
Operaciones
dependientes del
dispositivo
Operaciones
de Gestin
de Datos
Operaciones
de Gestin de
Interfaz de
usuario
Nominal
Mayora de
anidamientos simples.
Algunos mdulos de
control intermedio.
Simples llamados o
pasaje de mensajes.
Incluye procesamiento
distribuido para
soportar middleware
Uso de rutinas
matemticas y
estadsticas estndar.
Operaciones bsicas
con matrices/
vectores.
La entrada/salida
incluye seleccin de
dispositivo, chequeo
de estado y
procesamiento de
errores.
Mltiples archivos
simples de entrada
y salida.
Cambio simples de
las estructuras.
Complejos
accesos y updates
a la BD.
Uso simple de
Widget.
Alto
Mucha necesidad de
anidamiento con
componentes
compuesto por muchos
predicados. Control de
pilas, colas.
Proceso homogneo y
distribuido
Anlisis numrico
bsico:
Interpolacin
multivariada,
ecuaciones
diferenciales.
Truncamientos y
redondeos bsicos.
Operaciones de E/S
a nivel fsico.
(traduccin de
direcciones de
almacenamiento
fsicas, bsqueda,
lecturas, etc.)
Optimizacin de la
superposicin de las
entradas salidas.
Encadenamientos
simples activados
por hilera de
datos. Compleja
reestructuracin
de datos.
Desarrollo y
extensiones de
widget. Simples
entradas y
salidas voz.
Multimedia.

Muy Alto
Cdigo recursivo y
reutilizable.
Manejo de
interrupciones con
prioridades fijadas.
Tareas de
sincronizacin.
Llamadas complejas,
procesos distribuidos
heterogneos.
Control en Tiempo Real
de un nico
procesador.
Anlisis numrico
difcil pero
estructurado.
Matrices de
ecuaciones simples,
ecuaciones
diferenciales.
Rutinas para
diagnstico de
interrupciones.
Enmascaramiento.
Manejo on-line de
las comunicaciones
Sistemas embebidos
de rendimiento
intensivo.
Coordinacin de
BD distribuidas.
Triggers
complejos.
Optimizacin de la
bsqueda .
Grficos
dinmicos de 2D
3D
medianamente
complejo.
Multimedia.
Extra Alto
Mltiples recursos de
planificacin con
cambios de prioridades
dinmicos. Control a
nivel del microcdigo.
Control distribuido en
tiempo real.
Anlisis numrico
difcil y sin estructurar.
Anlisis de ruido,
datos, datos
estocsticos.
Paralelizacin
compleja
Dispositivos
dependientes
temporalmente de la
codificacin.
Operaciones
microprogramadas.
Alto acoplamiento
dinmico.
Estructuras
relaciones y de
objeto. Lenguaje
natural en la
gestin de datos.
Multimedia
compleja.
Realidad virtual.

RUSE: Reutilizacin requerida (T5 PCU)
Este driver de costo representa el esfuerzo adicional necesario para construir
componentes pensados para ser reutilizados en proyectos presentes o futuros. Este
esfuerzo implica crear un diseo ms genrico, documentacin ms detallada y pruebas ms
extensas para asegurar que los componentes estn listos para otras aplicaciones.

Bajo Nominal Alto Muy Alto Extra Alto
Nada En el programa En el proyecto En lneas
de producto
En mltiples lneas
de producto

DOCU: Documentacin requerida de acuerdo al ciclo de vida
Este factor se evala en trminos de la adecuacin de la documentacin del proyecto a las
necesidades de su ciclo de vida. La escala de valores va desde Muy bajo (muchas
necesidades del ciclo de vida sin cubrir) hasta Muy alto (excesiva para las necesidades del
ciclo de vida).



Muchas
necesidades del
CV sin cubrir.
Algunas
necesidades del
CV sin cubrir.
Necesidades
adecuadas al CV.
Excesivas
necesidades para
el CV.
Necesidades muy
elevadas para
el CV.

TIME: Restricciones en el tiempo de ejecucin
Restricciones en el tiempo de ejecucin impuestas en un sistema software. Se expresa en
trminos de % de tiempo de ejecucin utilizado por la aplicacin versus los recursos
disponibles. Los valores van desde Nominal (menos del 50% del tiempo de ejecucin
utilizados) hasta Extra Algo, (95% del recurso de tiempo de ejecucin consumido).

Nominal Alto Muy Alto Extra Alto
< 50% de uso de tiempo
de ejecucin disponible.
70% 85% 95%

STOR: Restricciones en el almacenamiento principal
Esta medida representa el grado de restriccin de almacenamiento principal impuesta a la
aplicacin. Dado el notable aumento en el tiempo de ejecucin disponible del procesador y
de almacenamiento principal, se puede cuestionar si estas variables de restriccin son
todava pertinentes, pero en aquellas aplicaciones que consumen todo el recurso disponible
no es as. Los valores van desde Nominal (menos del 50%) a Extra Alto (95%).

Nominal Alto Muy Alto Extra Alto
<50% del uso del
almacenamiento disponible
70% 85% 95%

PVOL: Volatilidad de la plataforma
Plataforma significa la complejidad del HW y SW (OS, DBMS) que la aplicacin software
necesita para realizar sus tareas. Si el software a desarrollar es un sistema operativo
entonces la plataforma es el hardware del ordenador. Si se desarrolla un Gestor de Base
de Datos entonces la plataforma es el hardware y el sistema operativo. Si se desarrolla un
browser de texto de red, entonces la plataforma es la red, el hardware del computador, el
sistema operativo y los repositorios de informacin distribuidos. La plataforma incluye
cualquier compilador o ensamblador que soporta el desarrollo de la aplicacin. Los valores
van desde Bajo (donde cada 12 meses hay un cambio importante) hasta Muy Alto (donde
hay un cambio importante cada 2 semanas).

Bajo Nominal Alto Muy Alto
Grandes cambios cada
12 meses.
Cambios menores cada
1 mes.
6 meses.
2 semanas.
2 meses.
1 semana.
2 semanas.
2 das.

ACAP: Capacidad de los analistas
Se refiere al personal que trabaja en los requisitos de diseo de alto nivel y diseo
detallado. Los atributos principales que se consideran en este factor son la habilidad de
anlisis y diseo, la eficiencia y minuciosidad y la habilidad para comunicar y cooperar. La
medida no debe considerar el nivel de experiencia del analista, eso se mide en AEXP.

15% 35% 55% 75% 90%



PCAP: Capacidad de los programadores
La evaluacin debe basarse en la capacidad de los programadores como un equipo, ms que
individualmente, siendo relevante la habilidad, capacidad en la comunicacin, trabajo en
equipo y la eficiencia.. La habilidad del programador se mide en AEXP no en este factor

15% 35% 55% 75% 90%

AEXP: Experiencia en las aplicaciones
Los valores se definen en trminos del nivel de experiencia del equipo de analistas en
aplicaciones similares o equivalentes.

2 meses 6 meses 1 ao 3 aos 6 aos

PEXP: Experiencia en la plataforma
Experiencia de los programadores en el manejo productivo de herramientas de desarrollo,
plataformas potentes, interfaces grficas de usuario, bases de datos, redes y capacidades
de middleware distribuido.


LTEX: Experiencia en lenguaje y herramientas
Es una medida del nivel de experiencia en el lenguaje de programacin y en la herramienta
software del equipo de proyecto. El desarrollo de software incluye el uso de herramientas
para manejar los requisitos, anlisis, diseo, gestin de la configuracin, origen de los
documentos, gestin de libreras, estilo de programacin y estructura, verificacin de
consistencia, etc. Adems de la experiencia del programador en un lenguaje especfico, las
herramientas que dan soporte tambin influyen en el tiempo de desarrollo.


PCON: Continuidad del personal
Expresa la rotacin anual del personal afectado al proyecto en trminos de porcentaje.

48% / ao 24% / ao 12% / ao 6% / ao 3% / ao

TOOL: Uso de herramientas de software
Las herramientas software (CASE) han mejorado significativamente desde sus inicios. El
valor va desde una simple herramienta de edicin y codificacin hasta una herramienta de
manejo integral de todo el ciclo de vida.

Edicin,
codificacin,
debug
Simple frontend,
CASE backend,
poca integracin
Herramientas para
ciclos de vida
bsicos.
Limitada integracin.
Herramientas para el
manejo de ciclos de
vida fuertes.
Moderada
integracin.
Herramientas maduras,
manejo de CV proactivos
Bien integrado con
procesos, reuso y ,
mtodos.



SITE: Desarrollo en sitios mltiples (T1 PCU)
Dada la creciente dispersin del grupo de desarrollo se puede considerar relevante este
factor. La medida incluye el clculo de 2 factores: Localizacin del lugar (desde totalmente
localizado hasta distribucin internacional) y soporte de comunicacin (desde correo de
superficie y algn acceso telefnico hasta multimedia totalmente interactivo).

Muy bajo Bajo Nominal Alto Muy Alto Extra Alto
Localizacin
Internacional
Mlti ciudad y
multicompaa
Mlti ciudad o
multicompaa
Misma ciudad
o rea
metropolitana.
Mismo edificio
o complejo.
Totalmente
localizado
Comunica-
ciones
Algo de
telfono,
mails.
Telfonos
individuales,
FAX
Email con
banda
angosta.
Comunicacin
electrnicas
con banda
ancha.
Comunicacin
electrnicas
con banda
ancha.
Ocasionales
videos
conferencias.
Multimedia
interactiva

SCED: Plan para el desarrollo requerido
Mide las restricciones de calendario impuestas al equipo de proyecto que desarrolla la
aplicacin. Los valores se definen en trminos de porcentaje de aceleracin o alargamiento
sobre el cronograma respecto de un cronograma nominal de un proyecto que requiere una
cantidad de esfuerzo dada. Los calendarios acelerados tienden a producir ms esfuerzo en
las fases ms tardas de desarrollo porque se dejan por solucionar ms problemas debido a
la falta de tiempo para resolverlos ms pronto. Un alargamiento del calendario produce ms
esfuerzo en las fases ms tempranas del desarrollo, dnde hay ms tiempo para planificar,
hacer especificaciones y validar minuciosamente.

75% del nominal 85% 100% 130% 160%

Valores de los factores de ajuste (drives de costo)

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
RELY 0,82 0,92 1,00 1,10 1,26 -
DATA - 0,90 1,00 1,14 1,28 -
CPLX 0,73 0,87 1,00 1,17 1,34 1,74
RUSE - 0,95 1,00 1,07 1,15 1,24
DOCU 0,81 0,91 1,00 1,11 1,23 -
TIME - - 1,00 1,11 1,29 1,63
STOR - - 1,00 1,05 1,17 1,46
PVOL - 0,87 1,00 1,15 1,30 -
ACAP 1,42 1,19 1,00 0,85 0,71 -
PCAP 1,34 1,15 1,00 0,88 0,76 -
PCON 1,29 1,12 1,00 0,90 0,81 -
AEXP 1,22 1,10 1,00 0,88 0,81 -
PEXP 1,19 1,09 0,91 0,85 -
LTEX 1,20 1,09 1,00 0,91 0,84 -
TOOL 1,17 1,09 1,00 0,90 0,78 -
SITE 1,22 1,09 1,00 0,93 0,86 0,80
SCED 1,43 1,14 1,00 1,00 1,00 -



4. ESTIMACIN DEL TIEMPO DE DESARROLLO

COCOMO II provee, para lograr la estimacin de tiempos involucrados con el desarrollo,
una forma simple de clculo que se refleja en la ecuacin E6.

TDEV = (3.67 x PM
(0.28 + 0.2 x (B 1.01))
) x (SCED% / 100) (E6)

TDEV es el tiempo calendario en meses desde la determinacin de los requerimientos
del producto hasta la finalizacin y certificacin que el producto cumple los
requerimientos solicitados.
PM es el tiempo estimado en Personas por Mes excluyendo el multiplicador de esfuerzo
SCED,
B es el factor escalar del proyecto
SCED% es el porcentaje de comprensin/expansin del multiplicador de esfuerzos
SCED

Aplicando sta formula llegamos a obtener un estimado de tiempos de desarrollo del
proyecto de acuerdo a las caractersticas propias del mismo, as como del entorno de
desarrollo.

5. BIBLIOGRAFA

Bhem, B. Software Engineering Economics. Prentice Hal. 1981.

Burril, C.W. Modern Project Management. Burril-Ellsworth Associates. 1980.

International Function Point Users Group. Function Point Counting Practices Manual.
Release 4.0. 1994. Fecha de consulta 02/2001. www.ifpug.com,

Londeix, B. Cost Estimation for Software Development. Addison-Wesley Publishers
Company. 1987.

Peralta, Mario; Rossi, Bibiana y Britos, Paola. Estimacin del esfuerzo basada en Casos
de Uso. Taller de Estimacin de Proyectos. 2002.

Rivero Bianchi, Carlos; Rossi, Bibiana. Modelo de Estimacin COCOMO II. Revista del
Instituto Tecnolgico de Buenos Aires, 2001. Vol 24, pp 42-71.

Sanchez Capuchino, Ana Mara. Estimacin de Proyectos Software. Maestra en
Ingeniera de Software. Unidad 4. Universidad Politcnica de Madrid. 2004.

SEI. Estimating Capabilities of Software Organizations. CMU/SEI-95-SR-005. Enero
1995.

Pressman, R. S. Ingeniera del Software. Un Enfoque Prctico. Mc Graw Hill. 1994.

Apunte COCOMOII

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apunte COCOMOII

Transféré par

Droits d'auteur :

Formats disponibles

Estimacin de Proyectos

Vous aimerez peut-être aussi