ESTIMACIN DEL ESFUERZO BASADA EN CASOS DE USO

Mario Peralta
Centro de Ingeniera del Software e Ingeniera del Conocimiento (CAPIS)
Escuela de Postgrado. Instituto Tecnolgico de Buenos Aires
Av. Madero 399 (C1106ACD), Buenos Aires Argentina.
http://www.itba.edu.ar/capis/webcapis/planma.html
marioitba@yahoo.com.ar

Resumen: El presente artculo plantea algunas alternativas posibles para la estimacin del es-
fuerzo en proyectos basados en Casos de Uso, utilizndose el Anlisis de Puntos de Funcin y
COCOMO II, o una variante ms reciente denominada Anlisis de Puntos de Casos de Uso, la
cual es en cierta medida similar al Anlisis de Puntos de Funcin.

Palabras Clave: Estimacin del Esfuerzo. Casos de Uso. Puntos de Funcin. COCOMO II.
Anlisis de Puntos de Casos de Uso.

1. Introduccin mtricas de tamao estimado, como el Anlisis de

La especificacin de los requerimientos mediante Ca-
sos de Uso ha probado ser uno de los mtodos ms
efectivos para capturar la funcionalidad de un sistema.
Este hecho se puede apreciar en algunas metodologas
actuales ampliamente difundidas, como el Proceso
Unificado de Rational (Rational Unified Process) o
Mtrica Versin 3 (Ministerio de Administraciones
Pblicas de Espaa), en las cuales se propone especifi-
car la funcionalidad de los sistemas mediante la utiliza-
cin de Casos de Uso.
El mtodo de Casos de Uso permite documentar los
requerimientos de un sistema en trminos de Actores y
Casos de Uso. Un Actor tpicamente representa a un
usuario humano o a otro sistema que interacta con el
sistema bajo anlisis. Un Caso de Uso representa un
grnulo funcional del sistema bajo anlisis, relatado
como una secuencia de acciones que uno o ms actores
llevan a cabo en el sistema para obtener un resultado de
valor significativo.
Si bien los Casos de Uso permiten especificar la fun-
cionalidad de un sistema bajo anlisis, no permiten por
s mismos efectuar una estimacin del tamao que
tendr el sistema o del esfuerzo que tomara implemen-
tarlo.
Para la estimacin del tamao de un sistema a partir de
sus requerimientos, una de las tcnicas ms difundidas
es el Anlisis de Puntos de Funcin. sta tcnica per-
mite cuantificar el tamao de un sistema en unidades
independientes del lenguaje de programacin, las me-
todologas, plataformas y/o tecnologas utilizadas,
denominadas Puntos de Funcin.
Por otro lado, el SEI (del ingls, Software Engineering
Institute) propone desde hace algunos aos un mtodo
para la estimacin del esfuerzo llamado COCOMO II.
ste mtodo est basado en ecuaciones matemticas
que permiten calcular el esfuerzo a partir de ciertas
Puntos de Funcin y las lneas de cdigo fuente (en
ingls SLOC, Source Line Of Code).
El presente artculo plantea algunas alternativas posi-
bles para la estimacin del esfuerzo en proyectos basa-
dos en Casos de Uso, utilizndose el Anlisis de Puntos
de Funcin y COCOMO II, o una variante ms reciente
denominada Anlisis de Puntos de Casos de Uso, la
cual es en cierta medida similar al Anlisis de Puntos
de Funcin.
2. Casos de Uso y Puntos de Funcin
Existe una relacin natural entre los Puntos de Funcin
y los Casos de Uso. Los Puntos de Funcin permiten
estimar el tamao del software a partir de sus requeri-
mientos, mientras que los Casos de Uso permiten do-
cumentar los requerimientos del software. Ambos
tratan de ser independientes de las tecnologas utiliza-
das para la implementacin.
En etapas tempranas del ciclo de vida, se identifican
los Actores y los Casos de Uso del sistema, y se docu-
menta cada uno de ellos mediante una breve descrip-
cin. Aplicando el Anlisis de Puntos de Funcin a
estos Casos de Uso, se podr obtener una estimacin
grosera del tamao y a partir de ella del esfuerzo. Esta
estimacin es bastante imprecisa debido principalmen-
te a la escasa informacin que se tiene sobre el softwa-
re al principio de un proyecto, pero permitir obtener
una idea del esfuerzo necesario para llevar adelante el
mismo, y podr ser refinada a medida que se obtenga
ms informacin.
Posteriormente se ampla la documentacin de cada
Caso de Uso, describiendo los Escenarios que se pro-

Reportes Tcnicos en Ingeniera de Software Vol. 6 N 1 (2004), pg. 1-16

ISSN: 1668-3137. CAPIS-EPG-ITBA (http://www.itba.edu.ar/capis/rtis/index.htm).
ducen dentro del mismo. Un Escenario relata la se-
cuencia de pasos que efectan los actores y el sistema
durante la ejecucin del Caso de Uso.
Si se aplica nuevamente el Anlisis de Puntos de Fun-
cin sobre estos Casos de Uso detallados, la estimacin
del tamao y esfuerzo ser ms precisa que la anterior.
2.1. Definiciones
A continuacin se adecuar la definicin de los com-
ponentes utilizados en el Anlisis de Puntos de Fun-
cin, para su utilizacin en los Casos de Uso.
2.1.1 Transacciones
En la especificacin de un Caso de Uso, se utiliza un
escenario principal para relatar la secuencia de pasos
entre el Actor y el sistema, y escenarios alternativos
para relatar condiciones excepcionales o condiciones
que se apartan del flujo normal de eventos. A continua-
cin se muestra un ejemplo de especificacin de Caso
de Uso:
Escenario Principal
1. El usuario indica un tipo de documento y un rango
de fechas desde y hasta
2. El sistema busca los documentos dados de alta en
el rango de fechas indicado y que sean del tipo in-
dicado por el usuario, y los presenta en una lista.
3. El usuario selecciona un documento de la lista
4. El sistema muestra los datos internos del
documento
Escenario Alternativo
2. No existe ningn documento que cumpla con los
valores indicados por el usuario
2.1 El sistema le informa al usuario que no encontr
ningn documento y le da la posibilidad de reingresar
los parmetros de bsqueda.
Una Transaccin est representada por uno o ms pa-
sos del flujo de eventos principal del Caso de Uso,
pudiendo existir ms de una transaccin dentro del
mismo Caso de Uso. Los flujos de eventos alternativos
dentro del Caso de Uso, ayudan a clarificar las transac-
ciones. En el ejemplo del prrafo anterior se puede
apreciar que existen dos transacciones diferenciadas,
una vinculada a la bsqueda de documentos, y la otra
vinculada a la visualizacin de un documento en
particular.
En relacin a los Puntos de Funcin, las transacciones
se clasifican de la siguiente manera:
Entradas Externas (EI, del ingls External Inputs):
se definen como un proceso elemental mediante el cual
ciertos datos cruzan la frontera del sistema desde afue-
ra hacia adentro. El Actor del Caso de Uso provee
datos al sistema, los cuales pueden tratarse de informa-
cin para agregar, modificar o eliminar de un Archivo
2
Lgico Interno, o bien informacin de control o del
negocio.
Ejemplo: un caso de uso que documente el manteni-
miento de alguna entidad del sistema, por ejemplo el
Documento, podra llamarse Mantener Documentos
y estar constitudo por 3 escenarios: uno que relate el
alta, otro que relate la modificacin y otro que relate la
baja de documentos. Cada uno de stos escenarios
representara una Entrada Externa desde el punto de
vista de los Puntos de Funcin. De manera similar, si
en vez de un caso de uso que relate el mantenimiento
de Documentos como 3 escenarios, se tienen 3 casos de
uso distintos, uno llamado Agregar Documento, otro
Modificar Documento y otro Eliminar Documento,
desde el punto de vista de los Puntos de Funcin se
tienen 3 Entradas Externas.
Un ejemplo grfico de Entrada Externa se puede ver en
la siguiente figura:
En la misma se muestra una Entrada Externa simple
que modifica dos Archivos Lgicos Internos.
Salidas Externas (EO, del ingls External Outputs):
se definen como un proceso elemental con componen-
tes de entrada y de salida mediante el cual datos sim-
ples y datos derivados (esto es, datos que se calculan a
partir de otros datos) cruzan la frontera del sistema
desde adentro hacia afuera. Adicionalmente, las Salidas
Externas pueden actualizar un Archivo Lgico Interno.
Los datos crean reportes o archivos que se envan hacia
el Actor del Caso de Uso (que puede ser un humano u
otro sistema). Estos reportes y archivos se crean desde
uno o ms Archivos Lgicos Internos o Archivos de
Interfaz Externos.
Ejemplo: los casos de uso que documentan reportes o
estadsticas que genera el sistema para uso de los acto-
res. La informacin que sale del sistema consiste fun-
damentalmente de datos calculados a partir de Archi-
vos Lgicos Internos. Un ejemplo ms concreto podra
ser un caso de uso llamado Generar reporte de altas,
donde se documenta la generacin de un reporte de la
cantidad de documentos que se dieron de alta en un pe-
rodo de tiempo. El actor indica el rango de fechas y el
sistema genera el reporte. Este caso de uso se corres-
pondera con una Salida Externa desde el punto de
vista de los Puntos de Funcin.
Un ejemplo grfico de Salida Externa se puede ver en
la siguiente figura:

En la misma se muestra una Salida Externa compuesta
por datos simples y datos derivados extrados de 2
Archivos Lgicos Internos.
Consultas Externas (EQ, del ingls External Inqui-
rys): se definen como un proceso elemental con com-
ponentes de entrada y de salida donde un Actor del
sistema rescata datos de uno o ms Archivos Lgicos
Internos o Archivos de Interfaz Externos. Los datos de
entrada no actualizan ni mantienen ningn archivo
(lgico interno o de interfaz externo) y los datos de
salida no contienen datos derivados (es decir, los datos
de salida son bsicamente los mismos que se obtienen
de los archivos). Dentro de ste tipo de transaccin
entran los listados y las bsquedas de los sistemas.
Ejemplo: un caso de uso denominado Buscar Docu-
mentos, donde se relata la interaccin entre un Actor y
el sistema para efectuar la bsqueda de documentos.
Esta bsqueda representa una Consulta Externa desde
el punto de vista de los Puntos de Funcin.
Un ejemplo grfico de Consulta Externa se puede ver
en la siguiente figura:
En la misma se muestra una Consulta Externa com-
puesta por datos simples extrados de 2 Archivos Lgi-
cos Internos.
2.1.2 Archivos
En relacin a los Casos de Uso, los archivos estn
representados por las descripciones de almacenamiento
de datos dentro del Caso de Uso, las cuales pueden
hablar de archivos, bases de datos, u otro tipo de alma-
cenamiento.
En relacin a los Puntos de Funcin, los archivos se
3
clasifican de la siguiente manera:
Archivos Lgicos Internos (ILF, del ingls Internal
Logical Files): grupo de datos relacionados lgicamen-
te e identificables por el usuario, que residen entera-
mente dentro de los lmites del sistema y se mantienen
a travs de las Entradas Externas.
Ejemplo: los casos de uso que estn vinculados al man-
tenimiento (altas, bajas, modificaciones) de entidades
del sistema, estn indicando la presencia de Archivos
Lgicos Internos. Retomando el ejemplo del caso de
uso Mantener Documentos en el que se documenta-
ban 3 escenarios, uno para alta, otro para baja y otro
para modificacin de Documentos, se tiene que desde
el punto de vista de los Puntos de Funcin existe un
Archivo Lgico Interno que almacena la informacin
de los documentos.
Archivos de Interfaz Externos (EIF, del ingls Ex-
ternal Interface Files): grupo de datos relacionados
lgicamente e identificables por el usuario, que se
utilizan solamente para fines de referencia. Los datos
residen enteramente fuera de los lmites del sistema y
se mantienen por las Entradas Externas de otras aplica-
ciones, es decir, cada Archivo de Interfaz Externo es
un Archivo Lgico Interno de otra aplicacin.
Ejemplo: un caso de uso que como parte de alguna de
sus secuencias de pasos indique que el sistema debe
consultar informacin de alguna base de datos externa
y mantenida por otro sistema. Ese paso estara dando la
pauta de la existencia de un archivo de Interfaz Externo
desde el punto de vista de los Puntos de Funcin.
2.2. Estimacin inicial sobre los Casos de Uso
identificados
La especificacin de requerimientos mediante Casos de
Uso comienza con la identificacin de los Actores del
sistema (usuarios u otros sistemas) y contina con la
identificacin de los Casos de Uso. En sta primera
aproximacin, se tiene una breve descripcin de cada
Caso de Uso, relatando sintticamente la funcionalidad
que brinda el mismo en beneficio de los actores.
Con sta informacin, se puede efectuar una estima-
cin inicial del tamao en Puntos de Funcin, basndo-
se en el nombre y la descripcin de cada Caso de Uso.
Esta aproximacin es bastante grosera, ya que no existe
una informacin completa de los requerimientos, pero
puede dar una idea del tamao del software a desarro-
llar.
Para ilustrar sta situacin, se presenta un breve ejem-
plo de Anlisis de Puntos de Funcin a partir de un
modelo UML constitudo por un diagrama de Casos de
Uso.
La siguiente figura muestra una parte de la funcionali-
dad de un sistema de administracin de rdenes de
compra, en la cual un Usuario (Actor) mantiene las
rdenes de compra mediante cuatro Casos de Uso:

Agregar orden
Descripcin: permite que el usuario efecte el alta de
una orden de compra en el sistema
Escenario principal:
1. El usuario ingresa los datos de la orden (elementos a
incluir en la orden de compra, proveedor, forma de
pago).
2. El sistema incorpora la orden de compra en su base
de datos, asignndole un nmero, y le muestra al usua-
rio la orden resultante.
Encontrar orden
Descripcin: permite que el usuario ubique una orden
de compra en el sistema
Escenario principal:
1. El usuario indica el nmero de orden de compra
2. El sistema ubica la orden de compra y la muestra al
usuario
Modificar orden
Descripcin: permite que el usuario modifique una
orden de compra en el sistema
Escenario principal:
1. El usuario utiliza el caso de uso Encontrar orden
para ubicar la orden de compra
2. El usuario ingresa los datos que desea modificar de
la orden (elementos a incluir en la orden de compra,
proveedor, forma de pago).
3. El sistema modifica la orden de compra en su base
de datos, y le muestra al usuario la orden resultante.
Eliminar orden
Descripcin: permite que el usuario elimine una orden
de compra en el sistema
Escenario principal:
1. El usuario utiliza el caso de uso Encontrar orden
para ubicar la orden de compra
2. El usuario confirma la eliminacin de la misma.
3. El sistema elimina la orden de compra en su base de
datos.
Analizando stos casos de uso y sus descripciones, se
puede ver que Agregar orden, Modificar orden y
Eliminar orden representan 3 Entradas Externas,
mientras que Encontrar orden representa una Consul-
ta Externa.
En todos los casos de uso est implcita la presencia de
un Archivo Lgico Interno, donde se almacena la in-
formacin de las rdenes de compra.
De acuerdo al Anlisis de Puntos de Funcin, tanto las
Transacciones (Entradas Externas, Salidas Externas,
Consultas Externas) como los Archivos (Archivos
Lgicos Internos, Archivos de Interfaz Externos) deben
ser clasificados con una complejidad Baja, Media o
Alta. El Apndice A muestra un resumen de los crite-
rios que rigen a sta clasificacin.
En ste nivel de detalle es imposible determinar la
complejidad de las transacciones o los archivos utiliza-
dos para el clculo de los Puntos de Funcin, con lo
cual lo ms razonable es asumir una complejidad me-
dia.
Entonces:
- Se tienen 3 Entradas Externas de complejidad media
(valor 4, ver Apndice A)
- Se tiene 1 Consulta Externa de complejidad media
(valor 4, ver Apndice A)
- Se tiene 1 Archivo Lgico Interno de complejidad
media (valor 10, ver Apndice A)
Complejidad
Baja Media Alta Aporte
Entradas Externas 3 12
Salidas Externas
Consultas Externas 1 4
Archivos Lgicos Internos 1 10
Archivos de Interface
Externos
Total 26
Sumando los aportes de todos los elementos se obtie-
nen los Puntos de Funcin sin ajustar:
UFP (Puntos de Funcin sin ajustar) = 12 + 4 + 10 = 26
2.3. Estimacin sobre las especificaciones de los
Casos de Uso
Luego de la identificacin de los Actores y Casos de
Uso del sistema a desarrollar, se procede a especificar
en detalle cada uno de los Casos de Uso. La forma ms
aceptada para la especificacin de Casos de Uso con-
siste en la descripcin de un Escenario principal que
relata las acciones del actor y las del sistema durante
una utilizacin tpica, y un conjunto de Escenarios
alternativos que relatan las condiciones de excepcin
dentro de la utilizacin tpica, o las formas alternativas
de llevar a cabo la secuencia de sucesos.
Una vez que se han especificado los casos de uso, se
tiene un nivel de detalle ms fino para la estimacin de
los puntos de funcin. Las secuencias que componen
un escenario pueden dar lugar a una o ms transaccio-
nes de Puntos de Funcin (Entradas Externas, Salidas
Externas, Consultas Externas). Asimismo, al detallar
los datos que intervienen en los escenarios, se tiene un
4
mejor panorama para la determinacin de la compleji-
dad de los Archivos Lgicos Internos o de Interfaz
Externos.
Para esclarecer stos conceptos, se contina con el
ejemplo anterior, tomando el caso de uso 'Encontrar
orden'.
La especificacin detallada del mismo podra ser la
siguiente:
las caractersticas deseadas del sistema (comunicacin
de datos, rendimiento, facilidades de instalacin, de
operacin, frecuencia de transacciones, etc.). Los deta-
lles para el clculo del Factor de ajuste se muestran en
el Apndice B.
Continuando con el ejemplo del punto 2.2, calculamos
el Factor de Ajuste y los Puntos de Funcin Ajustados.
Clculo del Factor de Ajuste:

Escenario principal Caracterstica Descripcin Peso

1. El usuario indica el nmero de orden de compra Comunicacin de Aplicacin web
datos 3
2. El sistema ubica la orden de compra y la muestra al Procesamiento distri- No hay procesamiento distribudo, pero
usuario buido de datos hay datos distribudos 2
Rendimiento No hay requerimientos especiales de
Escenario alternativo rendimiento 0
Configuraciones No hay restricciones con respecto al
1. El usuario indica un identificador o un nombre de fuertemente utilizadas hardware 0
proveedor Frecuencia de transac- Hay un pico diario de transacciones
2. El sistema busca todas las rdenes de ese proveedor ciones 3
y muestra la lista al usuario Entrada de datos on- Todos los datos se ingresan on-line
line 5
3. El usuario selecciona un elemento de la lista Eficiencia del usuario Media
4. El sistema busca la orden seleccionada y se la mues- final 3
tra al usuario Actualizaciones on- La mayora de los archivos se actuali-
line zan on-line 3
Analizando sta especificacin, se desprende lo si- Procesamiento com- No hay procesamiento lgico ni mate-
plejo mtico complejo 0
guiente: Reusabilidad Se pretende algn grado de reutiliza-
- los pasos 1 y 2 del escenario principal definen una cin 2
Consulta Externa Facilidad de No hay restricciones
- los pasos 1 y 2 del escenario alternativo definen otra instalacin 0
Consulta Externa Facilidad de ope- Operacin desatendida
- los pasos 3 y 4 del escenario alternativo definen una racin 5
Consulta Externa que es la misma que la definida en Instalacin en No se requiere ms de una
los pasos 1 y 2 del flujo principal distintos lugares instalacin 0
Como resultado de ste anlisis se tiene que el Caso de Facilidad de cam- Media
Uso 'Encontrar orden', que inicialmente haba sido bio 3
estimado en una Consulta Externa, ahora proporciona
dos Consultas Externas. De la misma manera, se tiene Con los valores asignados a las caractersticas, se ob-
un nivel de detalle ms elevado como para poder cuan- tiene el Grado Total de Influencia como:
tificar la complejidad de las Transacciones y los Archi- TDI = 3 + 2 + 0 + 0 + 3 + 5 + 3 + 3 + 0 + 2 + 0 + 5 + 0
vos. + 3 = 29

En resumen, a medida que se van completando las y el Factor de Ajuste como:

especificaciones de los Casos de Uso, se pueden ir AF = TDI x 0.01 + 0.65 = 29 x 0.01 + 0.65 = 0.94
mejorando las estimaciones de los Puntos de Funcin.
Finalmente, los Puntos de Funcin Ajustados dan:

2.4. De la estimacin de tamao a la estimacin del FP = UFP x AF = 26 x 0.94 = 24.44

esfuerzo
Una vez que se han obtenido los Puntos de Funcin sin
ajustar del sistema a partir de los Casos de Uso, se
puede estimar el esfuerzo por dos mtodos diferentes.
2.4.1 Puntos de Funcin Ajustados y Coeficientes de
Conversin
Luego de obtener los Puntos de Funcin Ajustados, se
pueden aplicar coeficientes que conviertan se valor a
otros como el esfuerzo, el costo o el tiempo. Estos
coeficientes se obtienen fundamentalmente de la in-
formacin histrica de proyectos de la organizacin,
aunque existen algunos valores medios disponibles,
recopilados estadsticamente de la industria del softwa-
re.

El primero de ellos consiste en el clculo de los Puntos

de Funcin Ajustados, siguiendo el procedimiento 2.4.2 COCOMO II
indicado por el Anlisis de Puntos de Funcin, que
consiste en el clculo de un Factor de Ajuste en base a El segundo de los mtodos posibles es la aplicacin del
la cuantificacin de ciertos coeficientes vinculados con mtodo COCOMO II directamente sobre los Puntos de

5
Funcin sin ajustar. ste mtodo es el preferido en la
actualidad para la estimacin del esfuerzo cuando no se
tiene informacin histrica a la cual recurrir.
COCOMO II consiste bsicamente en la aplicacin de
ecuaciones matemticas sobre los Puntos de Funcin
sin ajustar o la cantidad de lneas de cdigo (SLOC,
Source Lines Of Code) estimados para un proyecto.
Estas ecuaciones se encuentran ponderadas por ciertos
factores de costo (cost drivers) que influyen en el es-
fuerzo requerido para el desarrollo del software. El
Apndice C presenta una breve introduccin al mtodo
y sus conceptos principales.
Finalmente, el esfuerzo nominal resulta:
PMnominal = A x (Size)B = 2.94 x (1.378)1.05 = 4.11
Meses-hombre
Para completar la estimacin, hay que ajustar el esfuer-
zo nominal de acuerdo a las caractersticas del proyecto
segn se indica en el punto c) del Apndice C. El ajuste
se efectua aplicando la ecuacin
PMajustado = PMnominal x (MEi)

A manera de ejemplo, se aplica el mtodo COCOMO donde los MEi (multiplicadores de esfuerzo) varan en
II a la estimacin inicial obtenida en el apartado 2.2.
Como resultado de la estimacin se tena: funcin del modelo de estimacin seleccionado (Dise-
o Preliminar o Post arquitectura).
UFP (Puntos de Funcin sin ajustar) = 26 En nuestro caso vamos a aplicar el modelo de Diseo
preliminar. Entonces, cuantificamos los multiplicado-
Para aplicar la ecuacin de clculo del esfuerzo nomi- res de esfuerzo para ste modelo:
nal (ecuacin 1 del Apndice C), necesitamos por un
lado convertir los puntos de funcin sin ajustar a Multiplicador Descripcin Ponderacin Valor
PERS Se tienen analistas y progra- Alto 0.83
KSLOC (Source Lines Of Code, en miles), y por otro madores con alta eficiencia y
calcular el Factor escalar B de acuerdo a las caracters- capacidad de trabajo en equi-
ticas del proyecto. Luego: po. Dedicacin full-time.
RCPX Las exigencias de confiabili- Nominal 1
dad, documentacin y volu-
PMnominal = A x (Size)B men de datos son moderadas,
y la complejidad del producto
es baja.
A: tomamos el valor por defecto del modelo, ajustado RUSE No se pretende reutilizar nada Bajo 0.95
en 2.94 PDIF No existen restricciones en Bajo 0.87
cuando al tiempo de CPU o al
consumo de memoria, la
Size: se calcula como el producto de los puntos de plataforma es muy estable.
funcin sin ajustar por un factor de conversin que PREX Tanto los analistas como los Muy Bajo 1.33
depende del lenguaje a utilizar en el desarrollo del programadores tienen aproxi-
madamente 6 meses de expe-
sistema. Supongamos que utilizamos C++ (factor de riencia en la aplicacin, la
conversin = 53 SLOC/UFP). Entonces tendremos: plataforma, el lenguaje y las
herramientas utilizadas.
Size = 53 x 26 = 1378 SLOC SCED Se requiere terminar el proyec- Nominal 1
to en el tiempo estimado.
FCIL Se tienen herramientas CASE Bajo 1.10
B: se calcula ponderando las variables escalares de simples e infraestructura de
acuerdo al punto b) del Apndice C, mediante la ecua- comunicaciones bsica.
cin Total 1.004

B = 0.91 + 0.01 x (W ) Con estos valores, el ajuste del esfuerzo resulta:

i

donde las Wi se muestran en la siguiente tabla:

PM = 4.11 x 1.004 = 4.13 Meses-hombre
ajustado
Expresando el mismo valor en Horas-hombre, y te-
Variable Descripcin Ponderacin Valor
PREC El sistema es muy familiar Muy Alto 1.24
niendo en cuenta que un mes es aproximadamente 160
FLEX Algo de relajacin en cuanto Nominal 3.04 horas, el esfuerzo resulta:
a la flexibilidad del desarro-
llo 4.13 x 160 = 660.8 Horas-hombre
RESL La arquitectura es slida y Alto 2.83
los riesgos generalmente se
mitigan
TEAM La interaccin del equipo es Muy Alto 1.10
3. Puntos de Casos de Uso
altamente cooperativa
PMAT La madurez del proceso Bajo 6.24 La estimacin mediante el anlisis de Puntos de Casos
software es baja de Uso es un mtodo propuesto originalmente por
Total 1.05 Gustav Karner de Objectory AB, y posteriormente
refinado por muchos otros autores. Se trata de un m-

6
todo de estimacin del tiempo de desarrollo de un Tipo de Caso de Descripcin Factor de
proyecto mediante la asignacin de "pesos" a un cierto Uso Peso
Simple El Caso de Uso contiene de 1 a 3
nmero de factores que lo afectan, para finalmente, transacciones 5
contabilizar el tiempo total estimado para el proyecto a Medio El Caso de Uso contiene de 4 a 7
partir de esos factores. transacciones 10
Complejo El Caso de Uso contiene ms de 8
transacciones 15
A continuacin, se detallan los pasos a seguir para la
aplicacin de ste mtodo.
Ejemplo

Para aclarar los conceptos vistos hasta el momento,

3.1. Clculo de Puntos de Casos de Uso sin ajustar
podemos retomar el sistema de administracin de r-
denes de compra tratado en el ejemplo del apartado 2.2
El primer paso para la estimacin consiste en el clculo
de los Puntos de Casos de Uso sin ajustar. Este valor,
se calcula a partir de la siguiente ecuacin:

UUCP = UAW + UUCW

donde,
UUCP: Puntos de Casos de Uso sin ajustar
UAW: Factor de Peso de los Actores sin ajustar
UUCW: Factor de Peso de los Casos de Uso sin
ajustar

3.1.1 Factor de Peso de los Actores sin ajustar

(UAW)
Este valor se calcula mediante un anlisis de la canti-
dad de Actores presentes en el sistema y la compleji-
dad de cada uno de ellos. La complejidad de los Acto-
res se establece teniendo en cuenta en primer lugar si
se trata de una persona o de otro sistema, y en segundo
lugar, la forma en la que el actor interacta con el sis-
tema. Los criterios se muestran en la siguiente tabla:
Tipo de Descripcin
Actor
Simple Otro sistema que interacta con el sistema a des-
arrollar mediante una interfaz de programacin
(API, Application Programming Interface)
Medio Otro sistema que interacta con el sistema a des-
arrollar mediante un protocolo o una interfaz basada
en texto
Complejo Una persona que interacta con el sistema mediante
una interfaz grfica
3.1.2 Factor de Peso de los Casos de Uso sin ajustar
(UUCW)
Este valor se calcula mediante un anlisis de la canti-
dad de Casos de Uso presentes en el sistema y la com-
plejidad de cada uno de ellos. La complejidad de los
Casos de Uso se establece teniendo en cuenta la canti-
dad de transacciones efectuadas en el mismo, donde
una transaccin se entiende como una secuencia de
actividades atmica, es decir, se efecta la secuencia de
actividades completa, o no se efecta ninguna de las
actividades de la secuencia. Los criterios se muestran
en la siguiente tabla:
Aplicando el anlisis de Puntos de Casos de Uso sin
ajustar, se tiene:
Factor de Peso de los Actores sin ajustar (UAW)
El Usuario constituye un actor de tipo complejo, ya que
se trata de una persona utilizando el sistema mediante
una interfaz grfica, al cual se le asigna un peso 3.
Luego, el factor de peso de los actores sin ajustar resul-
Factor ta:
de
Peso UAW = 1 x 3 = 3
1 Factor de Peso de los Casos de Uso sin ajustar
(UUCW)
2 Cada uno de los casos de uso Agregar orden, Modi-
3 ficar orden y Eliminar orden consisten de una nica
transaccin, y el caso de uso Encontrar orden consis-
te de dos transacciones (como se vi en el ejemplo del
apartado 2.3). Se tienen entonces 4 casos de uso tipo
simple (peso 5), con lo cual el factor de peso de los
casos de uso sin ajustar resulta:
UUCW = 4 x 5 = 20
Finalmente, los Puntos de Casos de Uso sin ajustar
resultan
UUCP = UAW + UUCW = 3 + 20 = 23
3.2. Clculo de Puntos de Casos de Uso ajustados

Una vez que se tienen los Puntos de Casos de Uso sin

7
ajustar, se debe ajustar ste valor mediante la siguiente Factor Descripcin Peso
ecuacin: E4 Capacidad del analista lder 0.5
E5 Motivacin 1
UCP = UUCP x TCF x EF E6 Estabilidad de los requerimientos 2
E7 Personal part-time -1
donde, E8 Dificultad del lenguaje de progra-
UCP: Puntos de Casos de Uso ajustados macin -1
UUCP: Puntos de Casos de Uso sin ajustar
TCF: Factor de complejidad tcnica - Para los factores E1 al E4, un valor asignado de 0
EF: Factor de ambiente significa sin experiencia, 3 experiencia media y 5 am-
plia experiencia (experto).
- Para el factor E5, 0 significa sin motivacin para el
3.2.1 Factor de complejidad tcnica (TCF) proyecto, 3 motivacin media y 5 alta motivacin.
- Para el factor E6, 0 significa requerimientos extrema-
Este coeficiente se calcula mediante la cuantificacin damente inestables, 3 estabilidad media y 5 requeri-
de un conjunto de factores que determinan la compleji- mientos estables sin posibilidad de cambios.
dad tcnica del sistema. Cada uno de los factores se - Para el factor E7, 0 significa que no hay personal
cuantifica con un valor de 0 a 5, donde 0 significa un part-time (es decir todos son full-time), 3 significa
aporte irrelevante y 5 un aporte muy importante. En la mitad y mitad, y 5 significa que todo el personal es
siguiente tabla se muestra el significado y el peso de part-time (nadie es full-time).
cada uno de stos factores: - Para el factor E8, 0 significa que el lenguaje de pro-
gramacin es fcil de usar, 3 medio y 5 que el lenguaje
Factor Descripcin Peso es extremadamente difcil.
T1 Sistema distribudo 2
T2 Objetivos de performance o tiempo de respuesta 1
T3 Eficiencia del usuario final 1 El Factor de ambiente se calcula mediante la siguiente
T4 Procesamiento interno complejo 1 ecuacin:
T5 El cdigo debe ser reutilizable 1
T6 Facilidad de instalacin 0.5
T7 Facilidad de uso 0.5
EF =1.4 - 0.03 x (Pesoi x Valor asignadoi)
T8 Portabilidad 2 Ejemplo
T9 Facilidad de cambio 1
T10 Concurrencia 1
T11 Incluye objetivos especiales de seguridad 1 Continuando con el ejemplo del apartado 3.1, se calcu-
T12 Provee acceso directo a terceras partes 1 lan los Puntos de Casos de Uso ajustados.
T13 Se requieren facilidades especiales de entrenamiento
a usuarios 1 Factor de complejidad tcnica (TCF)

Factor Descripcin Peso Valor Comentario

El Factor de complejidad tcnica se calcula mediante la asignado
siguiente ecuacin: T1 Sistema distribudo El sistema es centrali-
2 0 zado
T2 Objetivos de perfor- La velocidad es limi-
TCF = 0.6 + 0.01 x (Pesoi x Valor asignadoi ) mance o tiempo de tada por las entradas
respuesta provistas por el usua-
1 1 rio
T3 Eficiencia del usuario Escasas restricciones
3.2.2 Factor de ambiente (EF) final 1 1 de eficiencia
T4 Procesamiento interno No hay clculos
complejo 1 1 complejos
Las habilidades y el entrenamiento del grupo involu- T5 El cdigo debe ser No se requiere que el
crado en el desarrollo tienen un gran impacto en las reutilizable 1 0 cdigo sea reutilizable
estimaciones de tiempo. Estos factores son los que se T6 Facilidad de instalacin Escasos requerimien-
contemplan en el clculo del Factor de ambiente. El tos de facilidad de
0.5 1 instalacin
clculo del mismo es similar al clculo del Factor de T7 Facilidad de uso 0.5 3 Normal
complejidad tcnica, es decir, se trata de un conjunto T8 Portabilidad No se requiere que el
de factores que se cuantifican con valores de 0 a 5. 2 0 sistema sea portable
T9 Facilidad de cambio Se requiere un costo
moderado de mante-
En la siguiente tabla se muestra el significado y el peso 1 3 nimiento
de cada uno de stos factores. T10 Concurrencia 1 0 No hay concurrencia
T11 Incluye objetivos espe- Seguridad normal
ciales de seguridad 1 3
T12 Provee acceso directo a Los usuarios web
Factor Descripcin Peso terceras partes 1 5 tienen acceso directo
E1 Familiaridad con el modelo de T13 Se requieren facilidades Pocos usuarios inter-
proyecto utilizado 1.5 especiales de entrena- nos, sistema fcil de
E2 Experiencia en la aplicacin 0.5 miento a usuarios 1 1 usar
E3 Experiencia en orientacin a obje-
tos 1

8
El Factor de complejidad tcnica resulta:
donde,
TCF = 0.6 + 0.01 x 17 = 0.77 E: esfuerzo estimado en horas-hombre
UCP: Puntos de Casos de Uso ajustados
Factor de ambiente (EF) CF: factor de conversin

Factor Descripcin Peso Valor Comentario Se debe tener en cuenta que ste mtodo proporciona
asignado una estimacin del esfuerzo en horas-hombre contem-
E1 Familiaridad con el modelo El grupo est
de proyecto utilizado bastante familiari- plando slo el desarrollo de la funcionalidad especifi-
1.5 4 zado con el modelo cada en los casos de uso.
E2 Experiencia en la aplica- La mayora del
cin grupo ha trabajado Finalmente, para una estimacin ms completa de la
mucho tiempo en
0.5 4 sta aplicacin duracin total del proyecto, hay que agregar a la esti-
E3 Experiencia en orientacin La mayora del macin del esfuerzo obtenida por los Puntos de Casos
a objetos grupo programa en de Uso, las estimaciones de esfuerzo de las dems
1 4 objetos actividades relacionadas con el desarrollo de software.
E4 Capacidad del analista lder Se contrat a un
0.5 5 especialista
Para ello se puede tener en cuenta el siguiente criterio,
E5 Motivacin El grupo est que estadsticamente se considera aceptable. El criterio
1 5 altamente motivado plantea la distribucin del esfuerzo entre las diferentes
E6 Estabilidad de los requeri- Se esperan cambios actividades de un proyecto, segn la siguiente aproxi-
mientos 2 2
E7 Personal part-time Todo el grupo es
macin:
-1 0 full-time
E8 Dificultad del lenguaje de Se usar lenguaje Actividad Porcentaje
programacin -1 3 C++ Anlisis 10.00%
Diseo 20.00%
Programacin 40.00%
El Factor de ambiente resulta: Pruebas 15.00%
Sobrecarga (otras actividades) 15.00%
EF = 1.4 - 0.03 x 19.5 = 0.82
Obviamente, stos valores no son absolutos sino que
Finalmente, los Puntos de Casos de Uso ajustados pueden variar de acuerdo a las caractersticas de la
resultan: organizacin y del proyecto.

UCP = 23 * 0.77 * 0.82 = 14.52
3.3. De los Puntos de Casos de Uso a la estimacin
del esfuerzo
Karner originalmente sugiri que cada Punto de Casos
de Uso requiere 20 horas-hombre. Posteriormente,
surgieron otros refinamientos que proponen una granu-
laridad algo ms fina, segn el siguiente criterio:
Con ste criterio, y tomando como entrada la estima-
cin de tiempo calculada a partir de los Puntos de Ca-
sos de Uso, se pueden calcular las dems estimaciones
para obtener la duracin total del proyecto.
Ejemplo
Aplicando stos criterios al ejemplo que se vena des-
arrollando en ste apartado, se obtiene el esfuerzo
necesario para el desarrollo de los casos de uso como:

- Se contabilizan cuntos factores de los que afectan al E = 14.52 * 20 = 290.4 Horas-Hombre

Factor de ambiente estn por debajo del valor medio
(3), para los factores E1 a E6. Si adems se considera que este esfuerzo representa un
porcentaje del esfuerzo total del proyecto, de acuerdo a
- Se contabilizan cuntos factores de los que afectan al los valores porcentuales de la tabla anterior, se obtiene:
Factor de ambiente estn por encima del valor medio
(3), para los factores E7 y E8. Actividad Porcentaje Horas-Hombre
- Si el total es 2 o menos, se utiliza el factor de conver- Anlisis 10.00% 72.6
sin 20 horas-hombre/Punto de Casos de Uso, es decir, Diseo 20.00% 145.2
un Punto de Caso de Uso toma 20 horas-hombre. Programacin 40.00% 290.4
- Si el total es 3 o 4, se utiliza el factor de conversin Pruebas 15.00% 108.9
28 horas-hombre/Punto de Casos de Uso, es decir, un Sobrecarga (otras
Punto de Caso de Uso toma 28 horas-hombre. actividades) 15.00% 108.9
- Si el total es mayor o igual que 5, se recomienda Total 100.00% 726
efectuar cambios en el proyecto, ya que se considera
que el riesgo de fracaso del mismo es demasiado alto.
Comparando ste resultado con el obtenido en el prra-
El esfuerzo en horas-hombre viene dado por: fo 2.4.2 (estimacin por COCOMO II) vemos que
resultan similares.
E = UCP x CF

9
4. Conclusiones Transacciones
a) Clasificacin de las Entradas Externas
Se ha aplicado los mtodos presentados a lo largo del Para las Entradas Externas, la clasificacin est dada
artculo para estimar el esfuerzo en algunos proyectos por la siguiente tabla:
de su mbito laboral, obteniendo resultados satisfacto-
rios en su mayora, en cuanto a la precisin de las esti- Archivos Elementos de datos
referenciados 1-4 5-15 >15
maciones con respecto a la cantidad de informacin 0-1 Baja Baja Media
disponible. 2 Baja Media Alta
3 o ms Media Alta Alta
En la experiencia del mismo, se pueden destacar las
siguientes apreciaciones:
En la misma, "Archivos referenciados" representa el
- La estimacin a partir de Puntos de Funcin ajustados nmero de Archivos Lgicos Internos mantenidos por
y Coeficientes de Conversin es difcil de realizar si no la Entrada Externa, y "Elementos de datos" representa
se cuenta con una base histrica de proyectos que pro- la cantidad de elementos que componen la Entrada
vea los coeficientes de conversin. Los valores estads- Externa.
ticos son difciles de encontrar.
b) Clasificacin de las Salidas Externas y Consultas
- La estimacin por COCOMO II (con Puntos de Fun- Externas
cin sin ajustar como entrada), resulta muy til para Para las Salidas Externas y las Consultas Externas, la
estimar un proyecto en forma global, cuando se tiene clasificacin est dada por la siguiente tabla:
un conjunto de Casos de Uso bastante amplio (del
orden de 50) y con escaso nivel de detalle. Utilizando Archivos Elementos de datos
la herramienta del SEI (Software Engineering Institu- referenciados 1-5 6-19 >19
0-1 Baja Baja Media
te), se puede refinar la estimacin a medida que se va
2-3 Baja Media Alta
adquiriendo ms informacin sobre el proyecto. Cabe >3 Media Alta Alta
aclarar la herramienta mencionada no est calibrada
para proyectos menores a 2000 lneas de cdigo, con lo
cual no es aplicable a proyectos muy pequeos. En la misma, "Archivos referenciados" representa el
nmero de Archivos Lgicos Internos o Archivos de
- La estimacin por Puntos de Caso de Uso resulta muy Interfaz Externos vinculados con la Salida Externa o la
efectiva para estimar el esfuerzo requerido en el desa- Consulta Externa, y "Elementos de datos" representa la
rrollo de los primeros Casos de Uso de un sistema, si se cantidad combinada de elementos de datos de entrada y
sigue una aproximacin iterativa como el Proceso de salida que componen la Salida Externa o Consulta
Unificado de Rational. En ste tipo de aproximacin, Externa.
los primeros Casos de Uso a desarrollar son los que
ejercitan la mayor parte de la arquitectura del software c) Asignacin de valores numricos
y los que a su vez ayudan a mitigar los riesgos ms Los valores numricos que se asignan a cada compleji-
significativos (iteraciones de Elaboracin en el Proceso dad (Baja, Media o Alta), se muestran en la siguiente
Unificado). Fuera de ste contexto, el mtodo tiende a tabla, para cada uno de los tipos de transaccin (Entra-
sobredimensionar el esfuerzo requerido por lo cual el da Externa, Salida Externa, Consulta Externa):
autor no lo recomienda para estimar el esfuerzo global
de un proyecto. Clasificacin Valores
Salidas Exter- Consultas Entradas
Si bien ninguno de stos mtodos es la panacea, todos nas Externas Externas
ellos aportan a la formacin del Ingeniero de Software, Baja 4 3 3
Media 5 4 4
y la aplicacin sistemtica de los mismos permite obte- Alta 7 6 6
ner mediciones y puntos de comparacin que ayudan a
ampliar la experiencia profesional en la estimacin de Archivos
proyectos de software. a) Clasificacin de los Archivos Lgicos Internos y
Archivos de Interfaz Externos
Para los Archivos Lgicos Externos y los Archivos de
Apndice A: Clasificacin de Transaccio- Interfaz Externos, la clasificacin est dada por la
nes y Archivos en Anlisis de Puntos de siguiente tabla:
Funcin. Tipos de registro Elementos de datos
1-19 20-50 >50
La complejidad de las Transacciones y los Archivos en 1 Baja Baja Media
el Anlisis de Puntos de Funcin, se puede clasificar y 2-5 Baja Media Alta
>5 Media Alta Alta
cuantificar de acuerdo con los criterios que se muestran
a continuacin:
donde "Tipos de registro" representa un subgrupo de
elementos de datos reconocibles por el usuario, y

10
"Elementos de datos" representa la cantidad de elemen-
tos de datos bsicos (campos nicos) que componen el
Archivo.
El concepto de "Tipos de registro" se puede ver mejor
mediante un ejemplo:
Supongamos que se almacena la informacin de un CD
de msica en un Archivo Lgico Interno. La informa-
cin asociada al CD es el Cantante, el Productor, el
Ttulo, la Fecha y las Canciones. Cada cancin a su vez
tiene como informacin asociada un Nombre, un Autor
y una Duracin.
En este caso se tienen 2 "Tipos de registro", la infor-
macin del CD y la informacin de la cancin. A su
vez, hay 4 "Elementos de datos" para la informacin
del CD (Cantante, Productor, Ttulo y Fecha), y 3
"Elementos de datos" para la informacin de la cancin
(Nombre, Autor y Duracin).
b) Asignacin de valores numricos
Los valores numricos que se asignan a cada compleji-
dad (Baja, Media o Alta), se muestran en la siguiente
tabla, para cada uno de los tipos de archivo (Archivo
Lgico Externo, Archivo de Interfaz Externo):
Clasificacin Valores
Archivo Lgico Archivo de Inter-
Interno face Externo
Baja 7 5
Media 10 7
Alta 15 10
Sntesis del Apndice:
El conteo de Puntos de Funcin comienza con la iden-
tificacin de las Transacciones (Entradas Externas,
Salidas Externas, Consultas Externas) y los Archivos
(Lgicos Internos o de Interface Externos).
Una vez identificados stos elementos, se utilizan los
criterios mostrados de manera de cuantificar el aporte
de cada uno de ellos a la suma total de Puntos de Fun-
cin.
Apndice B: Clculo del Factor de Ajuste
en Anlisis de Puntos de Funcin.
El Anlisis de Puntos de Funcin plantea el ajuste de
los Puntos de Funcin calculados a partir de las Tran-
sacciones y Archivos, mediante la evaluacin de 14
caractersticas generales del sistema. A cada una de
estas caractersticas se le asigna un factor de peso (un
valor entre 0 y 5) que indica la importancia de la carac-
terstica para el sistema bajo anlisis. El significado del
valor asignado a cada caracterstica es el siguiente:
0 No presente o sin influencia
1 Influencia incidental
2 Influencia moderada
3 Influencia media
4 Influencia significativa
5 Fuerte influencia
11
La siguiente tabla muestra las caractersticas a tener en
cuenta:
Caracterstica Descripcin
Comunicacin de Cuntas facilidades de comunicacin hay
datos disponibles para ayudar en el intercambio de
informacincon la aplicacin o el sistema?
Procesamiento distri- Cmo se manejan los datos y las funciones de
buido de datos procesamiento distribudo?
Rendimiento Existen requerimientos de velocidad o tiempo
de respuesta?
Configuraciones Qu tan intensivamente se utiliza la platafor-
fuertemente utilizadas ma de hardware donde se ejecutar la aplica-
cin o el sistema?
Frecuencia de transac- Que tan frecuentemente se ejecutan las tran-
ciones sacciones? Diariamente, semanalmente,
mensualmente?
Entrada de datos on- Qu porcentaje de la informacin se ingresa
line on-line?
Eficiencia del usuario Se designa la aplicacin para maximizar la
final eficiencia del usuario final?
Actualizaciones on- Cuntos Archivos Lgicos Internos se actuali-
line zan por una transaccin on-line?
Procesamiento com- Hay procesamientos lgicos o matemticos
plejo intensivos en la aplicacin?
Reusabilidad La aplicacin se desarrolla para suplir una o
muchas de las necesidades de los usuarios?
Facilidad de instala- Qu tan difcil es la instalacin y la conver-
cin sin al nuevo sistema?
Facilidad de operacin Que tan efectivos o automatizados son los
procedimientos de arranque, parada, backup y
restore del sistema?
Instalacin en distin- La aplicacin fue concebida para su instala-
tos lugares cin en mltiples sitios y organizaciones?
Facilidad de cambio La aplicacin fue concebida para facilitar los
cambios sobre la misma?
Cada una de stas caractersticas aporta un valor entre
0 y 5, de acuerdo a la importancia que tenga en el sis-
tema. Luego se suman los aportes de cada una de las
caractersticas, obteniendo el grado total de influencia
(TDI, del ingls Total Degree of Influence), y se calcu-
la el Factor de Ajuste como:
AF = (TDI x 0.01) + 0.65
Finalmente, los Puntos de Funcin Ajustados se obtie-
nen como el producto de los Puntos de Funcin sin
ajustar por el Factor de Ajuste:
FP = UFP x AF
Sntesis del Apndice:
El Anlisis de Puntos de Funcin plantea que luego de
la contabilizacin de los Puntos de Funcin sin ajustar,
se puede realizar un ajuste sobre el valor obtenido.
Este ajuste tiene en cuenta un conjunto de caractersti-
cas del sistema no contempladas en el conteo de las
Transacciones y los Archivos.
Las caractersticas (que forman un total de 14) se pon-
deran con un valor entre 0 y 5, y permiten obtener un
factor de ajuste que se aplica a los Puntos de Funcin
sin ajustar para obtener los Puntos de Funcin ajusta-
dos.
 proyecto presenta en lo que a su complejidad y entorno
Apndice C: Introduccin al modelo de de desarrollo se refiere. Las Variables escalares de
COCOMO II son las siguientes:
estimacin COCOMO II.
- PREC, variable de precedencia u orden secuencial del
a) Descripcin general desarrollo
El mtodo de estimacin COCOMO II est basado dos - FLEX, variable de flexibilidad del desarrollo
modelos: uno aplicable al comienzo de los proyectos - RSEL, indica la fortaleza de la arquitectura y mtodos
(Diseo preliminar, en ingls Early Design) y otro de estimacin y reduccin de riesgos
aplicable luego del establecimiento de la arquitectura - TEAM, esta variable refleja la cohesin y madurez
del sistema (Post arquitectura, en ingls Post Architec- del equipo de trabajo
ture). - PMAT, relaciona el proceso de madurez del software
El modelo de Diseo preliminar (Early Design) con- Cada una de estas variables se cuantifica con un valor
templa la exploracin de las arquitecturas alternativas desde Muy Bajo hasta Extra Alto.
del sistema y los conceptos de operacin. En esta etapa
no se sabe lo suficiente del proyecto como para hacer La siguiente tabla muestra los criterios y niveles de
una estimacin fina. Ante sta situacin, el modelo cuantificacin para cada una de stas variables:
propone la utilizacin de Puntos de Funcin como
medida de tamao y un conjunto de 7 factores (cost Factor Muy Bajo Nominal Alto Muy Extra
drivers) que afectan al esfuerzo del proyecto. Estos 7 Escalar Bajo Alto Alto
factores son agrupaciones de los factores que se utili- (W )
i
zan en la otra variante del modelo (Post Arquitectura). PREC Completa Completa Algo Familiar Muy Absolu-
Familiar tamente
El modelo Post arquitectura (Post Architecture) Familiar
contempla el desarrollo y el mantenimiento de un pro- FLEX Riguroso Ocasio- Algo de Gene- Algo de Objetivos
nal relaja- ralmente confor- generales
ducto software. Esta estrategia es ms precisa si se ha cin conforme midad
desarrollado una arquitectura del sistema, la cual haya RESL Poco Algo A menu- Gene- Mayor- Total-
sido validada y establecida como base para la evolu- (20%) (40%) do (60%) ralmente mente mente
cin del producto. Ante sta situacin, el modelo pro- (75%) (90%) (100%)
pone la utilizacin de Lneas de cdigo fuente y/o TEAM Interac- Algo de Bsicame Coopera- Altamen- Interac-
cin muy dificultad nte hay tiva te coope- cin total
Puntos de Funcin como medidores del tamao, modi- difcil de inter- interac- rativa
ficadores para indicar el grado de reutilizacin y des- accin cin
carte del software, un conjunto de 17 estimadores de coopera-
costo, y un conjunto de 5 factores que afectan de mane- tiva
ra exponencial en el esfuerzo del proyecto. PMAT Promedio Promedio Promedio Promedio Promedio Promedio
de res- de res- de res- de res- de res- de res-
En ambos modelos, la estimacin del esfuerzo se reali- puestas puestas puestas puestas puestas puestas
za tomando como base la siguiente ecuacin: afirmati- afirmati- afirmati- afirmati- afirmati- afirmati-
vas en el vas en el vas en el vas en el vas en el vas en el
cuestio- cuestio- cuestio- cuestio- cuestio- cuestio-
PMnominal = A x (Size)B (1) nario de nario de nario de nario de nario de nario de
CMM CMM CMM CMM CMM CMM

donde Los valores que asumen cada uno de stos factores en

PMnominal: es el esfuerzo nominal requerido en me- cada nivel se pueden ver en la siguiente figura:
ses-hombre
Size: es el tamao estimado del software, en miles de
lneas de cdigo (KSLOC) o en Puntos de Funcin sin
ajustar (convertibles a KSLOC mediante un factor de
conversin que depende del lenguaje y la tecnologa).
A: es una constante que se utiliza para capturar los
efectos multiplicativos en el esfuerzo requerido de
acuerdo al crecimiento del tamao del software. El
modelo la calibra inicialmente con un valor de 2.94
B: es una constante denominada Factor escalar, la
cual tiene un impacto exponencial en el esfuerzo y su
valor est dado por la resultante de los aspectos positi-
vos sobre los negativos que presenta el proyecto.
Luego de la ponderacin de stas variables, el Factor
b) Valoracin del Factor escalar B escalar se calcula mediante la siguiente ecuacin:
El factor escalar B se calcula a partir de la sumatoria de
los aportes de distintas Variables escalares, las cuales B = 0.91 + 0.01 x (Wi) (2)
son variables que indican las caractersticas que el

12
c) Ajuste del esfuerzo nominal personal y proyecto. A continuacin se muestran los
El esfuerzo calculado en la ecuacin (1) es un valor multiplicadores, con una breve descripcin de su signi-
nominal y debe ser ajustado en base a las caractersti- ficado.
cas del proyecto. COCOMO II obtiene los datos nece-
sarios para el ajuste del esfuerzo nominal considerando Multiplicadores que afectan al producto:
un conjunto de Multiplicadores de Esfuerzo (ME),
los cuales representan las caractersticas del proyecto y RELY: Confiabilidad requerida del software. Mide el
expresan su impacto en el desarrollo total del producto impacto que tiene una falla en el software.
de software.
Muy Bajo Bajo Nominal Alto
Muy
Los Multiplicadores de esfuerzo se cuantifican con una Alto
RELY Inconvenientes Bajo, y con Moderado, Altas Riesgo
escala que va desde Extra Bajo a Extra Alto, y cada imperceptibles perdidas con perdidas prdidas para la
multiplicador tiene un valor asociado a cada nivel de la fcilmente de fcil financieras vida
escala. recuperables recuperacin humana
Cada uno de los modelos de estimacin (Diseo preli-
minar y Post arquitectura) tiene un conjunto de Multi- DATA: Tamao de la base de datos. Se mide como el
plicadores de esfuerzo, los cuales son acordes con la tamao de la base en bytes sobre el tamao del pro-
informacin que se maneja en cada uno de estos mode- grama en LOC. Se utiliza para dimensionar el esfuerzo
los. requerido para el control y la generacin de datos de
prueba.
En ambos modelos, el esfuerzo ajustado se calcula
mediante la siguiente ecuacin: Muy Bajo Nominal Alto Muy Alto
Bajo
DATA D/P < 10 <= D/P < 100 <= D/P < D/P >=
PMajustado = PMnominal x (MEi) (3) 10 100 1000 1000

d) Multiplicadores de esfuerzo en el modelo Post CPLX: Complejidad del producto. La complejidad se

arquitectura divide en cinco reas: Operaciones de Control, Opera-
Para este modelo, los multiplicadores son 17, agrupa- ciones de Clculo, Dependencia de Dispositivos, Ma-
dos en las siguientes categoras: producto, plataforma, nejo de Datos e Interfaces de Usuario.

Operaciones de Control Operaciones de Clculo Dependencia de Dispo- Manejo de Datos Interfaces de Usuarios
sitivos
Muy Bajo Programacin lineal, con muy Evaluaciones de expresiones Escrituras y grabaciones Manejo de vectores simples en Formularios de ingreso sencillos.
pocas estructuras no anidadas: simples. con formatos simples. memoria. Manejo de consultas Generacin de reportes simples.
DO, IF, CASE. Composicin y accesos a la base de datos en
de mdulos simples a travs de forma sencilla.
procedimientos y funciones
Bajo Estructuras bien anidadas Evaluaciones moderadas de Sin particularidades o Manejo de datos sin archivos Uso de GUI (grafic user interface,
clculos. Ej. Raz cuadrada, dependencias del intermedios, sin edicin. interfaces graficas de usuario)
exponentes procesador de E/S. Se COTS-DB, consultas y actua- simples
manejan a travs de lizaciones moderadas
GET y PUT de conjun-
tos de datos
Nominal La mayora de las estructuras Uso de rutinas bsicas y Operaciones de E/S que Ingreso con formatos mltiples Uso simple de un conjunto de
son anidadas. Con controles de estndar. Manejo bsico de permiten seleccionar el de datos, pero conservando un parmetros de definicin de interfaz
intercambio simple de datos vectores y matrices dispositivo, haciendo un nico formato de salida. del usuario.
entre mdulos a travs de control del estado de los Cambios estructurales simples
parmetros, tablas de decisio- mismos y procesando con ediciones. Uso de consul-
nes, soporte para procesamien- errores tas y COTS-DB complejos
to distribuido de baja comple-
jidad
Alto Total uso de estructuras Anlisis numrico sencillo: Operaciones de E/S a Activacin de disparadores a Uso de parmetros de definicin de
anidadas. Manejo de pilas y interpolacin, ecuaciones niveles fsicos usando travs de datos de la DB. interfaces. Uso simple de caracters-
colas. Desarrollos para un diferenciales. Uso de redondeo
direccionamiento para la Reestructuraciones complejas ticas multimediales (entrada a travs
nico procesador y trunc. lectura y bsqueda. de datos. de la voz)
Overlap optimizado para
stas operaciones
Muy Alto Cdigo recursivo. Manejo de Clculos numricos difciles Rutinas para el diagns- Uso complejo de disparadores. Uso moderado de 2 y 3 dimensiones.
interrupciones, y sincroniza- pero estructurados: ecuaciones tico de interrupciones. Optimizacin de consultas. Habilidades grficas complejas y
cin de tareas complejas. matriciales, diferenciales Manejo de la lnea de Coordinacin de bases de multimediales.
Procesamiento distribuido comunicacin entre datos distribuidas
heterogneo. Un nico proce- dispositivos. Uso
sador controlado en tiempo intensivo del manejo de
real performance
Extra alto Operaciones de control mlti- Anlisis numrico complejo y Codificacin de disposi- Uso de lenguajes de manejo de Uso complejo de multimedia y
ples con cambios dinmicos de no estructurado. Clculos tivos asincrnica, con datos, y tcnicas de objetos as realidad virtual
prioridades. Control a nivel complejos en paralelo control crtico de como relacionales
microcdigo. Control en performance y procesos.
tiempo real del hardware
distribuido.

13
RUSE: Reusabilidad del cdigo. Mide el costo adicio- Muy Bajo Nominal Alto Muy Alto
nal requerido para disear componentes ms genricos, Bajo
PVOL Cambios Mayores : 6 Mayores : 2 Mayores : 2
mejor documentados y ms confiables, de manera de mayores cada meses, meses, semanas,
reutilizarlos en otros proyectos. 12 meses, y Menores : 2 Menores : 1 Menores : 2
cambios meno- semanas semana das
Muy Bajo Nominal Alto Muy Alto Extra Alto res cada mes
Bajo
RUSE Nada Por Por Por lnea de Por mltiples Los valores que asume cada uno de stos multiplicado-
Proyecto Progra- Producto lneas de produc-
ma tos res en cada nivel se pueden ver en la siguiente figura:

DOCU: Documentacin. Evala los requerimientos de

documentacin a lo largo del ciclo de vida del proyec-
to.

Muy Bajo Bajo Nominal Alto Muy Alto

DOCU Muchas etapas Algunas De acuer- Excesiva Muy
del ciclo de do a las Excesiva
vida estn sin necesida-
documentacin des exac-
tas de las
etapas del Multiplicadores que afectan al personal:
ciclo de
vida
ACAP: Capacidad de los analistas. Se considera la
capacidad de anlisis y diseo, eficiencia, habilidad
Los valores que asume cada uno de stos multiplicado- para comunicarse y trabajar en equipo. No se considera
res en cada nivel se pueden ver en la siguiente figura: el nivel de experiencia.

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

ACAP 15% 35% 55% 75% 90%

PCAP: Capacidad de los programadores. Se considera

la capacidad de trabajo en equipo, eficiencia y habili-
dad para comunicarse. No se considera el nivel de
experiencia.

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

PCAP 15% 35% 55% 75% 90%

AEXP: Experiencia en aplicaciones. Contempla el

Multiplicadores que afectan a la plataforma: nivel de experiencia del grupo de desarrollo (princi-
palmente analistas) en aplicaciones equivalentes.
TIME: Restricciones de tiempo de ejecucin. Se expre-
sa en trminos de porcentaje de disponibilidad de tiem-
po de ejecucin que ser usado por el sistema, versus Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
los recursos disponibles. AEXP 2 meses 6 meses 1 ao 3 aos 6 aos

Muy Bajo Nominal Alto Muy Extra PEXP: Experiencia en la plataforma. Refleja la expe-
Bajo Alto Alto
riencia del grupo de desarrollo (principalmente pro-
TIME <= 50% de uso de los 70% 85% 95%
recursos disponibles gramadores) en el uso de herramientas de software y
hardware utilizado como plataforma.
STOR: Restricciones de almacenamiento principal.
Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
Similar al multiplicador anterior, pero relacionadas con
PEXP 2 meses 6 meses 1 ao 3 aos 6 aos
el espacio principal de almacenamiento.
LTEX: Experiencia en el lenguaje y herramientas de
Muy Bajo Nominal Alto Muy Extra
desarrollo. Refleja la experiencia del grupo de desarro-
Bajo Alto Alto llo en el lenguaje de programacin y las herramientas
STOR <= 50% de uso del espacio 70% 85% 95% de desarrollo utilizadas.
disponible
Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
PVOL: Volatilidad de la plataforma. Expresa la veloci- LTEX 2 meses 6 meses 1 ao 3 aos 6 aos
dad de cambio del hardware y el software usados como
plataforma.

14
 de video
conferencias
PCON: Continuidad del personal. Expresa el porcenta- ocasionales.

je de rotacin anual del personal afectado al proyecto.

Muy Bajo Nominal Alto Muy Extra SCED: Requerimientos de calendario de desarrollo.
Bajo Alto Alto Refleja las restricciones impuestas al grupo de desarro-
PCON 48% al 24% al 12% al 6% al 3% al llo sobre la agenda nominal estimada del proyecto.
ao ao ao ao ao

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

Los valores que asume cada uno de stos multiplicado- SCED 75% del nomi- 85% 100% 130% 160%
res en cada nivel se pueden ver en la siguiente figura: nal

Los valores que asume cada uno de stos multiplicado-

res en cada nivel se pueden ver en la siguiente figura:

e) Multiplicadores de esfuerzo en el modelo de Diseo

preliminar
Multiplicadores que afectan al proyecto:
Para este modelo, los multiplicadores son 7, y se obtie-
TOOL: Uso de herramientas de software. Contempla el nen como combinaciones de los multiplicadores del
uso de herramientas, desde la edicin hasta el manejo modelo Post arquitectura.
de todo el ciclo de vida. Estos multiplicadores son:

Muy Bajo Bajo Nominal Alto Muy Alto PERS: Capacidad del personal. Est dado por la suma
TOOL Edicin y CASE simple y Herramientas Potentes Herramientas
codificacin de poca bsicas para herramientas a potentes y o la combinacin porcentual de los multiplicadores
con debug integracin todo el ciclo de ser usadas en proactivas, muy ACAP, PCAP y PCON.
vida con todo el ciclo de bien integradas
moderada vida con con el proceso,
integracin integracin los mtodos y la
moderada reusabilidad
Extra Muy Bajo Nominal Alto Muy Extra
Bajo Bajo Alto Alto
Suma de 3,4 5,6 7,8 9 10,11 12,13 14,15
SITE: Desarrollo en mltiples ubicaciones. Involucra ACAP, PCAP,
la ubicacin fsica y el soporte de comunicaciones. PCON
Combinacin 20% 39% 45% 55% 65% 75% 85%
Muy Bajo Nominal Alto Muy Alto Extra de ACAP y
Bajo Alto PCAP
SITE Algo de Fax y Red de Comunica- Comunica- Multimedia Rotacin anual 45% 30% 20% 12% 9% 5% 4%
telfono y telfonos correo ciones ciones del personal
mail individuales electrnico electrnicas electrnicas
interno que cubren que cubren
todas las todas las
ubicaciones ubicaciones
RCPX: Complejidad del producto. Est dado por la
con la combinacin de los multiplicadores RELY, DATA,
posibilidad
CPLX y DOCU.

Extra Bajo Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
Suma de RELY, 5,6 7,8 9-11 12 13-15 16-18 19-21
DATA, CPLX y
DOCU
nfasis en la Muy poca Poca Algo Bsica Fuerte Muy fuerte Extrema
documentacin
Complejidad del Muy simple Simple Algo Moderada Compleja Muy comple- Extremadamente compleja
Producto ja
Tamao de la base Pequea Pequea Pequea Moderada Grande Muy grande Muy grande
de datos

15
RUSE: Reusabilidad. Est dado por el mismo multiplicador RUSE del modelo Post arquite
ctura.

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

RUSE Nada Por Proyecto Por Programa Por lnea de Producto Por mltiples lneas de productos

PDIF: Dificultad de la plataforma. Est dado por la combinacin de los multiplicadores TIME, STOR y PVOL.

Bajo Nominal Alto Muy Alto Extra Alto

Suma de TIME, STOR y PVOL 8 9 10-12 13-15 16,17
Restricciones de TIME & 50% 50% 65% 80% 90%
STOR
Volatilidad de la plataforma Muy estable Estable Algo voltil Voltil Muy voltil

PREX: Experiencia del personal. Est dado por la combinacin de los multiplicadores AEXP, PEXP y LTEX

Extra Bajo Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
Suma AEXP, PEXP y 3,4 5,6 7,8 9 10,11 12,13 14
LTEX
Experiencia en la <= 3 meses 5 meses 9 meses 1 ao 2 aos 4 aos 6 aos
aplicacin, plataforma,
lenguaje y herramientas
utilizadas

SCED: Calendario. Est dado por el mismo multiplicador SCED del modelo Post arquitectura.

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

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

FCIL: Facilidades. Est dado por la combinacin de los multiplicadores TOOL y SITE.

Extra Bajo Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
Suma de TOOL y 2 3 4,5 6 7,8 9,10 11
SITE
Soporte de herra- Mnimo Algo CASE Simples Herramientas Buenas, mode- Muy buenas, Muy buenas totalmente
mientas de software bsicas segn el rada-mente moderadamente integradas
ciclo de vida integradas integradas
Mltiples lugares de Soporte dbil Algo de soporte Algo de soporte Soporte bsico Fuerte soporte Fuerte soporte Muy fuerte soporte para el
desarrollo para el para desarrollos para desarrollos para desarrollos para el desarro- de desarrollos desarrollo de procesos
desarrollo complejos moderados complejos llo de procesos de procesos complejos
complejo moderados simples

Los valores que asume cada uno de stos multiplicado-
res en cada nivel se pueden ver en la siguiente figura:
Referencias bibliogrficas
- Mtrica Versin 3, Ministerio de Administraciones Pbilcas Espa-
ol, http://www.map.es/csi/metrica3/index.html
- Use Cases and Function Points, artculo disponible en el site de
Longstreet Consulting, http://www.softwaremetrics.com/Articles/
usecases.htm
- Estimacin de esfuerzo, Unidad 3 del Mster en Ingeniera del
Software, ITBA.
- COCOMO II Model Manual, disponible en el CSE Center for
Software Engineering, http://sunset.usc.edu/research/COCOMOII/
cocomo_main.html#downloads
- USC COCOMO II User's Manual, disponible en el CSE Center for
Software Engineering, http://sunset.usc.edu/research/COCOMOII/
cocomo_main.html#downloads
- Artculo Modelo COCOMO II, Magistrando Carlos G. Rivero
Bianchi, publicado en julio del 2001 en la revista del Instituto Tecno-
lgico de Buenos Aires (ITBA).
- Function Point Traninig Manual, disponible en el site de Longstreet
Consulting, http://www.softwaremetrics.com/freemanual.htm
- Rational Unified Process, documentacin online disponible con los
productos de Rational.
- Time estimation in software development projects, Thomas
Fihlman, disponible en http://www.callista.se/ITPartner/timeart.htm
- Test Effort Estimation Using Use Case Points, Suresh Nageswaran,
Quality Week 2001, San Francisco, California, USA, June 2001,
disponible en http://www.cts-corp.com/cogcommunity/
presentations/Test%20Effort%20Estimation%20Using%20Use%20C
ase%20Points.pdf
- Understanding RET's, artculo disponible en el site de Lognstreet
Consulting, http://www.softwaremetrics.com/ Articles/ret.htm

16