ESTIMACIN DEL ESFUERZO BASADA EN CASOS DE USOS

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 esfuerzo 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
La especificacin de los requerimientos mediante Casos 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 especificar la funcionalidad de los sistemas mediante la utilizacin 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 funcionalidad de un sistema bajo anlisis, no permiten por
s mismos efectuar una estimacin del tamao que
tendr el sistema o del esfuerzo que tomara implementarlo.
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 permite cuantificar el tamao de un sistema en unidades
independientes del lenguaje de programacin, las metodologas, 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

mtricas de tamao estimado, como el Anlisis de

Puntos de Funcin y las lneas de cdigo fuente (en
ingls SLOC, Source Line Of Code).
El presente artculo plantea algunas alternativas posibles para la estimacin del esfuerzo 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.

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 requerimientos, mientras que los Casos de Uso permiten documentar los requerimientos del software. Ambos
tratan de ser independientes de las tecnologas utilizadas para la implementacin.
En etapas tempranas del ciclo de vida, se identifican
los Actores y los Casos de Uso del sistema, y se documenta cada uno de ellos mediante una breve descripcin. 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 principalmente a la escasa informacin que se tiene sobre el software 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 secuencia 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 Funcin sobre estos Casos de Uso detallados, la estimacin
del tamao y esfuerzo ser ms precisa que la anterior.

Lgico Interno, o bien informacin de control o del

negocio.
Ejemplo: un caso de uso que documente el mantenimiento 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.

2.1. Definiciones
A continuacin se adecuar la definicin de los componentes utilizados en el Anlisis de Puntos de Funcin, 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 continuacin se muestra un ejemplo de especificacin de Caso
de Uso:

Un ejemplo grfico de Entrada Externa se puede ver en

la siguiente figura:

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 indicado 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

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 componentes de entrada y de salida mediante el cual datos simples 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.

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 pasos 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 transacciones. 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.

Ejemplo: los casos de uso que documentan reportes o

estadsticas que genera el sistema para uso de los actores. La informacin que sale del sistema consiste fundamentalmente de datos calculados a partir de Archivos 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 perodo de tiempo. El actor indica el rango de fechas y el
sistema genera el reporte. Este caso de uso se correspondera con una Salida Externa desde el punto de
vista de los Puntos de Funcin.

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 afuera hacia adentro. El Actor del Caso de Uso provee
datos al sistema, los cuales pueden tratarse de informacin para agregar, modificar o eliminar de un Archivo

Un ejemplo grfico de Salida Externa se puede ver en

la siguiente figura:

clasifican de la siguiente manera:

Archivos Lgicos Internos (ILF, del ingls Internal
Logical Files): grupo de datos relacionados lgicamente e identificables por el usuario, que residen enteramente dentro de los lmites del sistema y se mantienen
a travs de las Entradas Externas.
Ejemplo: los casos de uso que estn vinculados al mantenimiento (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 documentaban 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.

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 Inquirys): se definen como un proceso elemental con componentes 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.

Archivos de Interfaz Externos (EIF, del ingls External 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 aplicaciones, es decir, cada Archivo de Interfaz Externo es
un Archivo Lgico Interno de otra aplicacin.

Ejemplo: un caso de uso denominado Buscar Documentos, 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.

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.

Un ejemplo grfico de Consulta Externa se puede ver

en la siguiente figura:

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 estimacin inicial del tamao en Puntos de Funcin, basndose 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 desarrollar.

En la misma se muestra una Consulta Externa compuesta por datos simples extrados de 2 Archivos Lgicos Internos.
2.1.2 Archivos

Para ilustrar sta situacin, se presenta un breve ejemplo 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 funcionalidad 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:

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 almacenamiento.
En relacin a los Puntos de Funcin, los archivos se
3

En todos los casos de uso est implcita la presencia de

un Archivo Lgico Interno, donde se almacena la informacin 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 criterios que rigen a sta clasificacin.
En ste nivel de detalle es imposible determinar la
complejidad de las transacciones o los archivos utilizados para el clculo de los Puntos de Funcin, con lo
cual lo ms razonable es asumir una complejidad media.

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 usuario la orden resultante.

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)

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

Entradas Externas
Salidas Externas
Consultas Externas
Archivos Lgicos Internos
Archivos de Interface
Externos

Complejidad
Baja
Media
3

Alta

1
1

4
10
Total

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.

Aporte
12

26

Sumando los aportes de todos los elementos se obtienen 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 consiste 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.

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.

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 transacciones de Puntos de Funcin (Entradas Externas, Salidas
Externas, Consultas Externas). Asimismo, al detallar
los datos que intervienen en los escenarios, se tiene un

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 Consulta Externa.

mejor panorama para la determinacin de la complejidad de los Archivos Lgicos Internos o de Interfaz
Externos.

las caractersticas deseadas del sistema (comunicacin

de datos, rendimiento, facilidades de instalacin, de
operacin, frecuencia de transacciones, etc.). Los detalles para el clculo del Factor de ajuste se muestran en
el Apndice B.

Para esclarecer stos conceptos, se contina con el

ejemplo anterior, tomando el caso de uso 'Encontrar
orden'.

Continuando con el ejemplo del punto 2.2, calculamos

el Factor de Ajuste y los Puntos de Funcin Ajustados.

La especificacin detallada del mismo podra ser la

siguiente:

Clculo del Factor de Ajuste:

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

Caracterstica
Comunicacin de
datos
Procesamiento distribuido de datos
Rendimiento

Descripcin
Aplicacin web

No hay procesamiento distribudo, pero

hay datos distribudos
No hay requerimientos especiales de
rendimiento
Configuraciones
No hay restricciones con respecto al
fuertemente utilizadas hardware
Frecuencia de transac- Hay un pico diario de transacciones
ciones
Entrada de datos on- Todos los datos se ingresan on-line
line
Eficiencia del usuario Media
final
Actualizaciones on- La mayora de los archivos se actualiline
zan on-line
Procesamiento com- No hay procesamiento lgico ni mateplejo
mtico complejo
Reusabilidad
Se pretende algn grado de reutilizacin

Escenario alternativo
1. El usuario indica un identificador o un nombre de
proveedor
2. El sistema busca todas las rdenes de ese proveedor
y muestra la lista al usuario
3. El usuario selecciona un elemento de la lista
4. El sistema busca la orden seleccionada y se la muestra al usuario
Analizando sta especificacin, se desprende lo siguiente:
- los pasos 1 y 2 del escenario principal definen una
Consulta Externa
- los pasos 1 y 2 del escenario alternativo definen otra
Consulta Externa
- los pasos 3 y 4 del escenario alternativo definen una
Consulta Externa que es la misma que la definida en
los pasos 1 y 2 del flujo principal
Como resultado de ste anlisis se tiene que el Caso de
Uso 'Encontrar orden', que inicialmente haba sido
estimado en una Consulta Externa, ahora proporciona
dos Consultas Externas. De la misma manera, se tiene
un nivel de detalle ms elevado como para poder cuantificar la complejidad de las Transacciones y los Archivos.

Facilidad de ins- No hay restricciones

talacin
Facilidad de ope- Operacin desatendida
racin
Instalacin en
No se requiere ms de una
distintos lugares instalacin
Facilidad de cam- Media
bio

Peso
3
2
0
0
3
5
3
3
0
2
0
5
0
3

Con los valores asignados a las caractersticas, se obtiene el Grado Total de Influencia como:
TDI = 3 + 2 + 0 + 0 + 3 + 5 + 3 + 3 + 0 + 2 + 0 + 5 + 0
+ 3 = 29

En resumen, a medida que se van completando las

especificaciones de los Casos de Uso, se pueden ir
mejorando las estimaciones de los Puntos de Funcin.

y el Factor de Ajuste como:

AF = TDI x 0.01 + 0.65 = 29 x 0.01 + 0.65 = 0.94
Finalmente, los Puntos de Funcin Ajustados dan:

2.4. De la estimacin de tamao a la estimacin del

esfuerzo

FP = UFP x AF = 26 x 0.94 = 24.44

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 informacin histrica de proyectos de la organizacin,
aunque existen algunos valores medios disponibles,
recopilados estadsticamente de la industria del software.

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
El primero de ellos consiste en el clculo de los Puntos
de Funcin Ajustados, siguiendo el procedimiento
indicado por el Anlisis de Puntos de Funcin, que
consiste en el clculo de un Factor de Ajuste en base a
la cuantificacin de ciertos coeficientes vinculados con

2.4.2 COCOMO II
El segundo de los mtodos posibles es la aplicacin del
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.

Finalmente, el esfuerzo nominal resulta:

PMnominal = A x (Size)B = 2.94 x (1.378)1.05 = 4.11
Meses-hombre

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 esfuerzo requerido para el desarrollo del software. El
Apndice C presenta una breve introduccin al mtodo
y sus conceptos principales.

Para completar la estimacin, hay que ajustar el esfuerzo 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

II a la estimacin inicial obtenida en el apartado 2.2.
Como resultado de la estimacin se tena:

donde los MEi (multiplicadores de esfuerzo) varan en

funcin del modelo de estimacin seleccionado (Diseo Preliminar o Post arquitectura).
En nuestro caso vamos a aplicar el modelo de Diseo
preliminar. Entonces, cuantificamos los multiplicadores de esfuerzo para ste modelo:

UFP (Puntos de Funcin sin ajustar) = 26

Para aplicar la ecuacin de clculo del esfuerzo nominal (ecuacin 1 del Apndice C), necesitamos por un
lado convertir los puntos de funcin sin ajustar a
KSLOC (Source Lines Of Code, en miles), y por otro
calcular el Factor escalar B de acuerdo a las caractersticas del proyecto. Luego:

Multiplicador
Descripcin
PERS
Se tienen analistas y programadores con alta eficiencia y
capacidad de trabajo en equipo. Dedicacin full-time.
RCPX
Las exigencias de confiabilidad, documentacin y volumen de datos son moderadas,
y la complejidad del producto
es baja.
RUSE
No se pretende reutilizar nada
PDIF
No existen restricciones en
cuando al tiempo de CPU o al
consumo de memoria, la
plataforma es muy estable.
PREX
Tanto los analistas como los
programadores tienen aproximadamente 6 meses de experiencia en la aplicacin, la
plataforma, el lenguaje y las
herramientas utilizadas.
SCED
Se requiere terminar el proyecto en el tiempo estimado.
FCIL
Se tienen herramientas CASE
simples e infraestructura de
comunicaciones bsica.

PMnominal = A x (Size)B
A: tomamos el valor por defecto del modelo, ajustado
en 2.94
Size: se calcula como el producto de los puntos de
funcin sin ajustar por un factor de conversin que
depende del lenguaje a utilizar en el desarrollo del
sistema. Supongamos que utilizamos C++ (factor de
conversin = 53 SLOC/UFP). Entonces tendremos:
Size = 53 x 26 = 1378 SLOC
B: se calcula ponderando las variables escalares de
acuerdo al punto b) del Apndice C, mediante la ecuacin

Nominal

Bajo
Bajo

0.95
0.87

Muy Bajo

1.33

Nominal

Bajo

1.10

Total

1.004

Con estos valores, el ajuste del esfuerzo resulta:

B = 0.91 + 0.01 x (W )
i
donde las Wi se muestran en la siguiente tabla:
Variable
Descripcin
PREC El sistema es muy familiar
FLEX Algo de relajacin en cuanto
a la flexibilidad del desarrollo
RESL La arquitectura es slida y
los riesgos generalmente se
mitigan
TEAM La interaccin del equipo es
altamente cooperativa
PMAT La madurez del proceso
software es baja

Ponderacin Valor
Alto
0.83

PM
= 4.11 x 1.004 = 4.13 Meses-hombre
ajustado
Expresando el mismo valor en Horas-hombre, y teniendo en cuenta que un mes es aproximadamente 160
horas, el esfuerzo resulta:

Ponderacin Valor
Muy Alto
1.24
Nominal
3.04

4.13 x 160 = 660.8 Horas-hombre

Alto

2.83

Muy Alto

1.10

Bajo

6.24

Total

1.05

3. Puntos de Casos de Uso

La estimacin mediante el anlisis de Puntos de Casos
de Uso es un mtodo propuesto originalmente por
Gustav Karner de Objectory AB, y posteriormente
refinado por muchos otros autores. Se trata de un m6

todo de estimacin del tiempo de desarrollo de un

proyecto mediante la asignacin de "pesos" a un cierto
nmero de factores que lo afectan, para finalmente,
contabilizar el tiempo total estimado para el proyecto a
partir de esos factores.

Tipo de Caso de
Descripcin
Uso
Simple
El Caso de Uso contiene de 1 a 3
transacciones
Medio
El Caso de Uso contiene de 4 a 7
transacciones
Complejo
El Caso de Uso contiene ms de 8
transacciones

A continuacin, se detallan los pasos a seguir para la

aplicacin de ste mtodo.

Factor de
Peso
5
10
15

Ejemplo
Para aclarar los conceptos vistos hasta el momento,
podemos retomar el sistema de administracin de rdenes de compra tratado en el ejemplo del apartado 2.2

3.1. Clculo de Puntos de Casos de Uso sin ajustar

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)

Aplicando el anlisis de Puntos de Casos de Uso sin

ajustar, se tiene:

Este valor se calcula mediante un anlisis de la cantidad de Actores presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los Actores 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 sistema. Los criterios se muestran en la siguiente tabla:
Tipo de
Actor

Descripcin

Simple Otro sistema que interacta con el sistema a desarrollar mediante una interfaz de programacin
(API, Application Programming Interface)
Medio Otro sistema que interacta con el sistema a desarrollar mediante un protocolo o una interfaz basada
en texto
Complejo Una persona que interacta con el sistema mediante
una interfaz grfica

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 resulta:

Factor
de
Peso

UAW = 1 x 3 = 3
Factor de Peso de los Casos de Uso sin ajustar
(UUCW)

1
2

Cada uno de los casos de uso Agregar orden, Modificar orden y Eliminar orden consisten de una nica
transaccin, y el caso de uso Encontrar orden consiste 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:

3.1.2 Factor de Peso de los Casos de Uso sin ajustar

(UUCW)
Este valor se calcula mediante un anlisis de la cantidad de Casos de Uso presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los
Casos de Uso se establece teniendo en cuenta la cantidad 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:

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

ecuacin:

Factor
E4
E5
E6
E7
E8

UCP = UUCP x TCF x EF

donde,
UCP: Puntos de Casos de Uso ajustados
UUCP: Puntos de Casos de Uso sin ajustar
TCF: Factor de complejidad tcnica
EF: Factor de ambiente

Este coeficiente se calcula mediante la cuantificacin

de un conjunto de factores que determinan la complejidad tcnica del sistema. Cada uno de los factores se
cuantifica con un valor de 0 a 5, donde 0 significa un
aporte irrelevante y 5 un aporte muy importante. En la
siguiente tabla se muestra el significado y el peso de
cada uno de stos factores:
Descripcin
Sistema distribudo
Objetivos de performance o tiempo de respuesta
Eficiencia del usuario final
Procesamiento interno complejo
El cdigo debe ser reutilizable
Facilidad de instalacin
Facilidad de uso
Portabilidad
Facilidad de cambio
Concurrencia
Incluye objetivos especiales de seguridad
Provee acceso directo a terceras partes
Se requieren facilidades especiales de entrenamiento
a usuarios

Peso
2
1
1
1
1
0.5
0.5
2
1
1
1
1

-1

El Factor de ambiente se calcula mediante la siguiente

ecuacin:
EF =1.4 - 0.03 x (Pesoi x Valor asignadoi)
Ejemplo
Continuando con el ejemplo del apartado 3.1, se calculan los Puntos de Casos de Uso ajustados.

Factor de complejidad tcnica (TCF)

Factor

El Factor de complejidad tcnica se calcula mediante la

siguiente ecuacin:

Descripcin

Peso Valor
asignado

T1 Sistema distribudo
2

0.5
0.5

1
3

1
1

3
0

T2 Objetivos de performance o tiempo de

respuesta

TCF = 0.6 + 0.01 x (Pesoi x Valor asignadoi )

T3 Eficiencia del usuario

final
T4 Procesamiento interno
complejo
T5 El cdigo debe ser
reutilizable
T6 Facilidad de instalacin

3.2.2 Factor de ambiente (EF)

Las habilidades y el entrenamiento del grupo involucrado en el desarrollo tienen un gran impacto en las
estimaciones de tiempo. Estos factores son los que se
contemplan en el clculo del Factor de ambiente. El
clculo del mismo es similar al clculo del Factor de
complejidad tcnica, es decir, se trata de un conjunto
de factores que se cuantifican con valores de 0 a 5.

T7 Facilidad de uso
T8 Portabilidad
T9 Facilidad de cambio

En la siguiente tabla se muestra el significado y el peso

de cada uno de stos factores.
Factor
Descripcin
E1
Familiaridad con el modelo de
proyecto utilizado
E2
Experiencia en la aplicacin
E3
Experiencia en orientacin a objetos

Peso
0.5
1
2
-1

- Para los factores E1 al E4, un valor asignado de 0

significa sin experiencia, 3 experiencia media y 5 amplia experiencia (experto).
- Para el factor E5, 0 significa sin motivacin para el
proyecto, 3 motivacin media y 5 alta motivacin.
- Para el factor E6, 0 significa requerimientos extremadamente inestables, 3 estabilidad media y 5 requerimientos estables sin posibilidad de cambios.
- Para el factor E7, 0 significa que no hay personal
part-time (es decir todos son full-time), 3 significa
mitad y mitad, y 5 significa que todo el personal es
part-time (nadie es full-time).
- Para el factor E8, 0 significa que el lenguaje de programacin es fcil de usar, 3 medio y 5 que el lenguaje
es extremadamente difcil.

3.2.1 Factor de complejidad tcnica (TCF)

Factor
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
T13

Descripcin
Capacidad del analista lder
Motivacin
Estabilidad de los requerimientos
Personal part-time
Dificultad del lenguaje de programacin

T10 Concurrencia
T11 Incluye objetivos especiales de seguridad
T12 Provee acceso directo a
terceras partes
T13 Se requieren facilidades
especiales de entrenamiento a usuarios

Peso
1.5
0.5
1
8

Comentario
El sistema es centralizado
La velocidad es limitada por las entradas
provistas por el usuario
Escasas restricciones
de eficiencia
No hay clculos
complejos
No se requiere que el
cdigo sea reutilizable
Escasos requerimientos de facilidad de
instalacin
Normal
No se requiere que el
sistema sea portable
Se requiere un costo
moderado de mantenimiento
No hay concurrencia
Seguridad normal
Los usuarios web
tienen acceso directo
Pocos usuarios internos, sistema fcil de
usar

El Factor de complejidad tcnica resulta:

donde,
E: esfuerzo estimado en horas-hombre
UCP: Puntos de Casos de Uso ajustados
CF: factor de conversin

TCF = 0.6 + 0.01 x 17 = 0.77

Factor de ambiente (EF)
Factor

Descripcin

Peso Valor
asignado

E1 Familiaridad con el modelo

de proyecto utilizado
1.5

0.5

0.5

-1

-1

E2 Experiencia en la aplicacin
E3 Experiencia en orientacin
a objetos
E4 Capacidad del analista lder
E5 Motivacin
E6 Estabilidad de los requerimientos
E7 Personal part-time
E8 Dificultad del lenguaje de
programacin

Se debe tener en cuenta que ste mtodo proporciona

una estimacin del esfuerzo en horas-hombre contemplando slo el desarrollo de la funcionalidad especificada en los casos de uso.

Comentario
El grupo est
bastante familiarizado con el modelo
La mayora del
grupo ha trabajado
mucho tiempo en
sta aplicacin
La mayora del
grupo programa en
objetos
Se contrat a un
especialista
El grupo est
altamente motivado
Se esperan cambios

Finalmente, para una estimacin ms completa de la

duracin total del proyecto, hay que agregar a la estimacin del esfuerzo obtenida por los Puntos de Casos
de Uso, las estimaciones de esfuerzo de las dems
actividades relacionadas con el desarrollo de software.
Para ello se puede tener en cuenta el siguiente criterio,
que estadsticamente se considera aceptable. El criterio
plantea la distribucin del esfuerzo entre las diferentes
actividades de un proyecto, segn la siguiente aproximacin:

Todo el grupo es
full-time
Se usar lenguaje
C++

Actividad
Anlisis
Diseo
Programacin
Pruebas
Sobrecarga (otras actividades)

El Factor de ambiente resulta:

EF = 1.4 - 0.03 x 19.5 = 0.82

Porcentaje
10.00%
20.00%
40.00%
15.00%
15.00%

Obviamente, stos valores no son absolutos sino que

pueden variar de acuerdo a las caractersticas de la
organizacin y del proyecto.

Finalmente, los Puntos de Casos de Uso ajustados

resultan:
UCP = 23 * 0.77 * 0.82 = 14.52

Con ste criterio, y tomando como entrada la estimacin de tiempo calculada a partir de los Puntos de Casos de Uso, se pueden calcular las dems estimaciones
para obtener la duracin total del proyecto.

3.3. De los Puntos de Casos de Uso a la estimacin

del esfuerzo

Ejemplo

Karner originalmente sugiri que cada Punto de Casos

de Uso requiere 20 horas-hombre. Posteriormente,
surgieron otros refinamientos que proponen una
granularidad algo ms fina, segn el siguiente criterio:

Aplicando stos criterios al ejemplo que se vena desarrollando 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

Factor de ambiente estn por debajo del valor medio
(3), para los factores E1 a E6.

E = 14.52 * 20 = 290.4 Horas-Hombre

Si adems se considera que este esfuerzo representa un
porcentaje del esfuerzo total del proyecto, de acuerdo a
los valores porcentuales de la tabla anterior, se obtiene:

- Se contabilizan cuntos factores de los que afectan al

Factor de ambiente estn por encima del valor medio
(3), para los factores E7 y E8.
- Si el total es 2 o menos, se utiliza el factor de conversin 20 horas-hombre/Punto de Casos de Uso, es decir,
un Punto de Caso de Uso toma 20 horas-hombre.
- Si el total es 3 o 4, se utiliza el factor de conversin
28 horas-hombre/Punto de Casos de Uso, es decir, un
Punto de Caso de Uso toma 28 horas-hombre.
- Si el total es mayor o igual que 5, se recomienda
efectuar cambios en el proyecto, ya que se considera
que el riesgo de fracaso del mismo es demasiado alto.

Actividad
Anlisis
Diseo
Programacin
Pruebas
Sobrecarga (otras
actividades)
Total

Porcentaje
10.00%
20.00%
40.00%
15.00%

Horas-Hombre
72.6
145.2
290.4
108.9

15.00%
100.00%

108.9
726

Comparando ste resultado con el obtenido en el prrafo 2.4.2 (estimacin por COCOMO II) vemos que
resultan similares.

El esfuerzo en horas-hombre viene dado por:

E = UCP x CF
9

Transacciones
a) Clasificacin de las Entradas Externas
Para las Entradas Externas, la clasificacin est dada
por la siguiente tabla:

4. Conclusiones
Se ha aplicado los mtodos presentados a lo largo del
artculo para estimar el esfuerzo en algunos proyectos
de su mbito laboral, obteniendo resultados satisfactorios en su mayora, en cuanto a la precisin de las estimaciones con respecto a la cantidad de informacin
disponible.

Archivos
referenciados
0-1
2
3 o ms

Elementos de datos
1-4
5-15
Baja
Baja
Baja
Media
Media
Alta

>15
Media
Alta
Alta

En la experiencia del mismo, se pueden destacar las

siguientes apreciaciones:
En la misma, "Archivos referenciados" representa el
nmero de Archivos Lgicos Internos mantenidos por
la Entrada Externa, y "Elementos de datos" representa
la cantidad de elementos que componen la Entrada
Externa.

- La estimacin a partir de Puntos de Funcin ajustados

y Coeficientes de Conversin es difcil de realizar si no
se cuenta con una base histrica de proyectos que provea los coeficientes de conversin. Los valores estadsticos son difciles de encontrar.

b) Clasificacin de las Salidas Externas y Consultas

Externas
Para las Salidas Externas y las Consultas Externas, la
clasificacin est dada por la siguiente tabla:

- La estimacin por COCOMO II (con Puntos de Funcin sin ajustar como entrada), resulta muy til para
estimar un proyecto en forma global, cuando se tiene
un conjunto de Casos de Uso bastante amplio (del
orden de 50) y con escaso nivel de detalle. Utilizando
la herramienta del SEI (Software Engineering Institute), se puede refinar la estimacin a medida que se va
adquiriendo ms informacin sobre el proyecto. Cabe
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.

Archivos
referenciados
0-1
2-3
>3

Elementos de datos
1-5
6-19
Baja
Baja
Baja
Media
Media
Alta

>19
Media
Alta
Alta

En la misma, "Archivos referenciados" representa el

nmero de Archivos Lgicos Internos o Archivos de
Interfaz Externos vinculados con la Salida Externa o la
Consulta Externa, y "Elementos de datos" representa la
cantidad combinada de elementos de datos de entrada y
de salida que componen la Salida Externa o Consulta
Externa.

- La estimacin por Puntos de Caso de Uso resulta muy

efectiva para estimar el esfuerzo requerido en el desarrollo de los primeros Casos de Uso de un sistema, si se
sigue una aproximacin iterativa como el Proceso
Unificado de Rational. En ste tipo de aproximacin,
los primeros Casos de Uso a desarrollar son los que
ejercitan la mayor parte de la arquitectura del software
y los que a su vez ayudan a mitigar los riesgos ms
significativos (iteraciones de Elaboracin en el Proceso
Unificado). Fuera de ste contexto, el mtodo tiende a
sobredimensionar el esfuerzo requerido por lo cual el
autor no lo recomienda para estimar el esfuerzo global
de un proyecto.

c) Asignacin de valores numricos

Los valores numricos que se asignan a cada complejidad (Baja, Media o Alta), se muestran en la siguiente
tabla, para cada uno de los tipos de transaccin (Entrada Externa, Salida Externa, Consulta Externa):
Clasificacin

Si bien ninguno de stos mtodos es la panacea, todos

ellos aportan a la formacin del Ingeniero de Software,
y la aplicacin sistemtica de los mismos permite obtener mediciones y puntos de comparacin que ayudan a
ampliar la experiencia profesional en la estimacin de
proyectos de software.

Baja
Media
Alta

Valores
Salidas Externas
4
5
7

Consultas
Externas
3
4
6

Entradas
Externas
3
4
6

Archivos
a) Clasificacin de los Archivos Lgicos Internos y
Archivos de Interfaz Externos
Para los Archivos Lgicos Externos y los Archivos de
Interfaz Externos, la clasificacin est dada por la
siguiente tabla:

Apndice A: Clasificacin de Transacciones y Archivos en Anlisis de Puntos de

Funcin.

Tipos de registro

La complejidad de las Transacciones y los Archivos en

el Anlisis de Puntos de Funcin, se puede clasificar y
cuantificar de acuerdo con los criterios que se muestran
a continuacin:

1
2-5
>5

Elementos de datos
1-19
20-50
Baja
Baja
Baja
Media
Media
Alta

>50
Media
Alta
Alta

donde "Tipos de registro" representa un subgrupo de

elementos de datos reconocibles por el usuario, y
10

"Elementos de datos" representa la cantidad de elementos de datos bsicos (campos nicos) que componen el
Archivo.

La siguiente tabla muestra las caractersticas a tener en

cuenta:

El concepto de "Tipos de registro" se puede ver mejor

mediante un ejemplo:

Caracterstica
Comunicacin de
datos

Descripcin
Cuntas facilidades de comunicacin hay
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 plataforfuertemente utilizadas ma de hardware donde se ejecutar la aplicacin o el sistema?
Frecuencia de transac- Que tan frecuentemente se ejecutan las tranciones
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 actualiline
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 convercin
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 instalatos lugares
cin en mltiples sitios y organizaciones?
Facilidad de cambio La aplicacin fue concebida para facilitar los
cambios sobre la misma?

Supongamos que se almacena la informacin de un CD

de msica en un Archivo Lgico Interno. La informacin 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 informacin 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 complejidad (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 InterInterno
face Externo
Baja
4
3
Media
5
4
Alta
7
6

Cada una de stas caractersticas aporta un valor entre

0 y 5, de acuerdo a la importancia que tenga en el sistema. 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 calcula el Factor de Ajuste como:

Sntesis del Apndice:

El conteo de Puntos de Funcin comienza con la identificacin 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 Funcin.

AF = (TDI x 0.01) + 0.65

Finalmente, los Puntos de Funcin Ajustados se obtienen como el producto de los Puntos de Funcin sin
ajustar por el Factor de Ajuste:
FP = UFP x AF

Apndice B: Clculo del Factor de Ajuste

en Anlisis de Puntos de Funcin.

Sntesis del Apndice:

El Anlisis de Puntos de Funcin plantea el ajuste de

los Puntos de Funcin calculados a partir de las Transacciones 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 caracterstica para el sistema bajo anlisis. El significado del
valor asignado a cada caracterstica es el siguiente:
0
1
2
3
4
5

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 caractersticas del sistema no contempladas en el conteo de las
Transacciones y los Archivos.
Las caractersticas (que forman un total de 14) se ponderan 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 ajustados.

No presente o sin influencia

Influencia incidental
Influencia moderada
Influencia media
Influencia significativa
Fuerte influencia
11

proyecto presenta en lo que a su complejidad y entorno

de desarrollo se refiere. Las Variables escalares de
COCOMO II son las siguientes:

Apndice C: Introduccin al modelo de

estimacin COCOMO II.

- PREC, variable de precedencia u orden secuencial del

desarrollo
- FLEX, variable de flexibilidad del desarrollo
- RSEL, indica la fortaleza de la arquitectura y mtodos
de
estimacin
y
reduccin
de
riesgos
- TEAM, esta variable refleja la cohesin y madurez
del equipo de trabajo
- PMAT, relaciona el proceso de madurez del software

a) Descripcin general
El mtodo de estimacin COCOMO II est basado dos
modelos: uno aplicable al comienzo de los proyectos
(Diseo preliminar, en ingls Early Design) y otro
aplicable luego del establecimiento de la arquitectura
del sistema (Post arquitectura, en ingls Post Architecture).
El modelo de Diseo preliminar (Early Design) contempla la exploracin de las arquitecturas alternativas
del sistema y los conceptos de operacin. En esta etapa
no se sabe lo suficiente del proyecto como para hacer
una estimacin fina. Ante sta situacin, el modelo
propone la utilizacin de Puntos de Funcin como
medida de tamao y un conjunto de 7 factores (cost
drivers) que afectan al esfuerzo del proyecto. Estos 7
factores son agrupaciones de los factores que se utilizan en la otra variante del modelo (Post Arquitectura).

Cada una de estas variables se cuantifica con un valor

desde Muy Bajo hasta Extra Alto.
La siguiente tabla muestra los criterios y niveles de
cuantificacin para cada una de stas variables:
Factor Muy
Bajo
Nominal Alto
Muy
Escalar Bajo
Alto
(W )
i
Familiar Muy
PREC Completa Completa Algo
Familiar

El modelo Post arquitectura (Post Architecture)

contempla el desarrollo y el mantenimiento de un producto software. Esta estrategia es ms precisa si se ha
desarrollado una arquitectura del sistema, la cual haya
sido validada y establecida como base para la evolucin del producto. Ante sta situacin, el modelo propone la utilizacin de Lneas de cdigo fuente y/o
Puntos de Funcin como medidores del tamao, modificadores para indicar el grado de reutilizacin y descarte del software, un conjunto de 17 estimadores de
costo, y un conjunto de 5 factores que afectan de manera exponencial en el esfuerzo del proyecto.

FLEX
RESL
TEAM

PMAT

En ambos modelos, la estimacin del esfuerzo se realiza tomando como base la siguiente ecuacin:
PMnominal = A x (Size)B (1)
donde
PMnominal: es el esfuerzo nominal requerido en me-

Extra
Alto

Absolutamente
Familiar
Riguroso Ocasio- Algo de GeneAlgo de Objetivos
nal
relajaralmente confor- generales
cin
conforme midad
Poco
Algo
A menu- GeneMayor- Total(20%)
(40%)
do (60%) ralmente mente
mente
(75%)
(90%)
(100%)
Interac- Algo de Bsica- Coopera- Altamen- Interaccin muy dificultad mente
tiva te coope- cin total
difcil
de inter- hay
rativa
accin interaccin
cooperativa
Promedio Promedio Promedio Promedio Promedio Promedio
de res- de res- de res- de res- de res- de respuestas puestas puestas puestas puestas puestas
afirmati- afirmati- afirmati- afirmati- afirmati- afirmativas en el vas en el vas en el vas en el vas en el vas en el
cuestio- cuestio- cuestio- cuestio- cuestio- cuestionario de nario de nario de nario de nario de nario de
CMM
CMM
CMM
CMM
CMM
CMM

Los valores que asumen cada uno de stos factores en

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 positivos sobre los negativos que presenta el proyecto.
Luego de la ponderacin de stas variables, el Factor
escalar se calcula mediante la siguiente ecuacin:

b) Valoracin del Factor escalar B

El factor escalar B se calcula a partir de la sumatoria de
los aportes de distintas Variables escalares, las cuales
son variables que indican las caractersticas que el

B = 0.91 + 0.01 x (Wi) (2)

12

c) Ajuste del esfuerzo nominal

El esfuerzo calculado en la ecuacin (1) es un valor
nominal y debe ser ajustado en base a las caractersticas del proyecto. COCOMO II obtiene los datos necesarios para el ajuste del esfuerzo nominal considerando
un conjunto de Multiplicadores de Esfuerzo (ME),
los cuales representan las caractersticas del proyecto y
expresan su impacto en el desarrollo total del producto
de software.

personal y proyecto. A continuacin se muestran los

multiplicadores, con una breve descripcin de su significado.
Multiplicadores que afectan al producto:
RELY: Confiabilidad requerida del software. Mide el
impacto que tiene una falla en el software.
Muy Bajo

Muy
Alto
RELY Inconvenientes Bajo, y con Moderado, Altas
Riesgo
imperceptibles perdidas
con perdidas prdidas para
la
fcilmente de
fcil financieras vida
recuperables recuperacin
humana

Los Multiplicadores de esfuerzo se cuantifican con una

escala que va desde Extra Bajo a Extra Alto, y cada
multiplicador tiene un valor asociado a cada nivel de la
escala.
Cada uno de los modelos de estimacin (Diseo preliminar y Post arquitectura) tiene un conjunto de Multiplicadores de esfuerzo, los cuales son acordes con la
informacin que se maneja en cada uno de estos modelos.

Bajo

Nominal

Alto

DATA: Tamao de la base de datos. Se mide como el

tamao de la base en bytes sobre el tamao del programa en LOC. Se utiliza para dimensionar el esfuerzo
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

Bajo

Nominal

Alto

Muy Alto

D/P <
10

10 <= D/P <

100

100 <= D/P <

1000

D/P >=
1000

PMajustado = PMnominal x (MEi) (3)

DATA

d) Multiplicadores de esfuerzo en el modelo Post

arquitectura
Para este modelo, los multiplicadores son 17, agrupados en las siguientes categoras: producto, plataforma,

CPLX: Complejidad del producto. La complejidad se

divide en cinco reas: Operaciones de Control, Operaciones de Clculo, Dependencia de Dispositivos, Manejo de Datos e Interfaces de Usuario.

Operaciones de Control
Muy Bajo

Bajo

Nominal

Alto

Muy Alto

Extra alto

Operaciones de Clculo

Programacin lineal, con muy Evaluaciones de expresiones

pocas estructuras no anidadas: simples.
DO, IF, CASE. Composicin
de mdulos simples a travs de
procedimientos y funciones
Estructuras bien anidadas
Evaluaciones moderadas de
clculos. Ej. Raz cuadrada,
exponentes

La mayora de las estructuras

son anidadas. Con controles de
intercambio simple de datos
entre mdulos a travs de
parmetros, tablas de decisiones, soporte para procesamiento distribuido de baja complejidad
Total uso de estructuras
anidadas. Manejo de pilas y
colas. Desarrollos para un
nico procesador

Uso de rutinas bsicas y

estndar. Manejo bsico de
vectores y matrices

Dependencia de Dispo- Manejo de Datos

Interfaces de Usuarios
sitivos
Escrituras y grabaciones Manejo de vectores simples en Formularios de ingreso sencillos.
con formatos simples. memoria. Manejo de consultas Generacin de reportes simples.
y accesos a la base de datos en
forma sencilla.
Sin particularidades o
dependencias del
procesador de E/S. Se
manejan a travs de
GET y PUT de conjuntos de datos
Operaciones de E/S que
permiten seleccionar el
dispositivo, haciendo un
control del estado de los
mismos y procesando
errores

Anlisis numrico sencillo:

interpolacin, ecuaciones
diferenciales. Uso de redondeo
y trunc.

Manejo de datos sin archivos Uso de GUI (grafic user interface,

intermedios, sin edicin.
interfaces graficas de usuario)
COTS-DB, consultas y actua- simples
lizaciones moderadas
Ingreso con formatos mltiples Uso simple de un conjunto de
de datos, pero conservando un parmetros de definicin de interfaz
nico formato de salida.
del usuario.
Cambios estructurales simples
con ediciones. Uso de consultas y COTS-DB complejos

Operaciones de E/S a
Activacin de disparadores a
niveles fsicos usando travs de datos de la DB.
direccionamiento para la Reestructuraciones complejas
lectura y bsqueda.
de datos.
Overlap optimizado para
stas operaciones
Cdigo recursivo. Manejo de Clculos numricos difciles Rutinas para el diagns- Uso complejo de disparadores.
interrupciones, y sincroniza- pero estructurados: ecuaciones tico de interrupciones. Optimizacin de consultas.
cin de tareas complejas.
matriciales, diferenciales
Manejo de la lnea de
Coordinacin de bases de
Procesamiento distribuido
comunicacin entre
datos distribuidas
heterogneo. Un nico procedispositivos. Uso
sador controlado en tiempo
intensivo del manejo de
real
performance
Operaciones de control mlti- Anlisis numrico complejo y Codificacin de disposi- Uso de lenguajes de manejo de
ples con cambios dinmicos de no estructurado. Clculos
tivos asincrnica, con datos, y tcnicas de objetos as
prioridades. Control a nivel
complejos en paralelo
control crtico de
como relacionales
microcdigo. Control en
performance y procesos.
tiempo real del hardware
distribuido.

13

Uso de parmetros de definicin de

interfaces. Uso simple de caractersticas multimediales (entrada a travs
de la voz)
Uso moderado de 2 y 3 dimensiones.
Habilidades grficas complejas y
multimediales.

Uso complejo de multimedia y

realidad virtual

RUSE: Reusabilidad del cdigo. Mide el costo adicional requerido para disear componentes ms genricos,
mejor documentados y ms confiables, de manera de
reutilizarlos en otros proyectos.
Muy Bajo Nominal Alto
Muy Alto
Bajo
RUSE
Nada Por
Por
Por lnea de
Proyecto Progra- Producto
ma

Extra Alto

Muy Bajo
Nominal
Bajo
PVOL
Cambios
Mayores :
mayores cada meses,
12 meses, y Menores :
cambios meno- semanas
res cada mes

Alto

Muy Alto

Por mltiples
lneas de productos

Los valores que asume cada uno de stos multiplicadores en cada nivel se pueden ver en la siguiente figura:

6 Mayores : 2 Mayores : 2
meses,
semanas,
2 Menores : 1 Menores : 2
semana
das

DOCU: Documentacin. Evala los requerimientos de

documentacin a lo largo del ciclo de vida del proyecto.
Muy Bajo
Bajo
DOCU Muchas etapas Algunas
del ciclo de
vida estn sin
documentacin

Nominal Alto
De acuer- Excesiva
do a las
necesidades exactas de las
etapas del
ciclo de
vida

Muy Alto
Muy
Excesiva

Multiplicadores que afectan al personal:

ACAP: Capacidad de los analistas. Se considera la
capacidad de anlisis y diseo, eficiencia, habilidad
para comunicarse y trabajar en equipo. No se considera
el nivel de experiencia.

Los valores que asume cada uno de stos multiplicadores en cada nivel se pueden ver en la siguiente figura:

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 habilidad 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

nivel de experiencia del grupo de desarrollo (principalmente analistas) en aplicaciones equivalentes.

Multiplicadores que afectan a la plataforma:

TIME: Restricciones de tiempo de ejecucin. Se expresa en trminos de porcentaje de disponibilidad de tiempo de ejecucin que ser usado por el sistema, versus
los recursos disponibles.
Muy
Bajo
TIME

Bajo Nominal

Alto Muy
Alto
<= 50% de uso de los 70% 85%
recursos disponibles

Muy Bajo Bajo

Nominal Alto Muy Alto Extra Alto
AEXP 2 meses 6 meses 1 ao
3 aos 6 aos

Extra
Alto
95%

PEXP: Experiencia en la plataforma. Refleja la experiencia del grupo de desarrollo (principalmente programadores) en el uso de herramientas de software y
hardware utilizado como plataforma.

STOR: Restricciones de almacenamiento principal.

Similar al multiplicador anterior, pero relacionadas con
el espacio principal de almacenamiento.
Muy
Bajo
STOR

Bajo Nominal

Alto Muy
Alto
<= 50% de uso del espacio 70% 85%
disponible

Muy Bajo Bajo

Nominal Alto Muy Alto Extra Alto
PEXP 2 meses 6 meses 1 ao
3 aos 6 aos

LTEX: Experiencia en el lenguaje y herramientas de

desarrollo. Refleja la experiencia del grupo de desarrollo en el lenguaje de programacin y las herramientas
de desarrollo utilizadas.

Extra
Alto
95%

Muy Bajo Bajo

Nominal Alto Muy Alto Extra Alto
LTEX 2 meses 6 meses 1 ao
3 aos 6 aos

PVOL: Volatilidad de la plataforma. Expresa la velocidad de cambio del hardware y el software usados como
plataforma.

14

de video
conferencias
ocasionales.

PCON: Continuidad del personal. Expresa el porcentaje de rotacin anual del personal afectado al proyecto.
Muy
Bajo
PCON 48%
ao

Bajo
al 24%
ao

Nominal Alto
al 12%
ao

Muy
Alto
al 3%
ao

al 6%
ao

SCED: Requerimientos de calendario de desarrollo.

Refleja las restricciones impuestas al grupo de desarrollo sobre la agenda nominal estimada del proyecto.

Extra
Alto
al

Muy Bajo
Bajo Nominal Alto Muy Alto Extra Alto
SCED 75% del nomi- 85% 100%
130% 160%
nal

Los valores que asume cada uno de stos multiplicadores en cada nivel se pueden ver en la siguiente figura:

Los valores que asume cada uno de stos multiplicadores 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 obtienen como combinaciones de los multiplicadores del
modelo Post arquitectura.
Estos multiplicadores son:

TOOL: Uso de herramientas de software. Contempla el

uso de herramientas, desde la edicin hasta el manejo
de todo el ciclo de vida.
Muy Bajo Bajo
TOOL

Edicin y
codificacin
con debug

Nominal

CASE simple y Herramientas

bsicas para
de poca
todo el ciclo de
integracin
vida con
moderada
integracin

Alto

Muy Alto

Potentes
herramientas a
ser usadas en
todo el ciclo de
vida con
integracin
moderada

Herramientas
potentes y
proactivas, muy
bien integradas
con el proceso,
los mtodos y la
reusabilidad

PERS: Capacidad del personal. Est dado por la suma

o la combinacin porcentual de los multiplicadores
ACAP, PCAP y PCON.
Extra Muy Bajo
Bajo Bajo
Suma
de 3,4
5,6 7,8
ACAP, PCAP,
PCON
Combinacin 20% 39% 45%
de ACAP y
PCAP
Rotacin anual 45% 30% 20%
del personal

SITE: Desarrollo en mltiples ubicaciones. Involucra

la ubicacin fsica y el soporte de comunicaciones.

SITE

Muy
Bajo

Bajo

Nominal Alto

Algo de
telfono y
mail

Red de
Fax y
correo
telfonos
individuales electrnico
interno

Extra Bajo
Suma de RELY, 5,6
DATA, CPLX y
DOCU
nfasis en
la Muy poca
documentacin
Complejidad del Muy simple
Producto
Tamao de la base Pequea
de datos

Comunicaciones
electrnicas
que cubren
todas las
ubicaciones

Muy Alto Extra

Alto
Comunicaciones
electrnicas
que cubren
todas las
ubicaciones
con la
posibilidad

Multimedia

Nominal Alto
9

Muy Extra
Alto Alto
10,11 12,13 14,15

55%

65%

75%

85%

12%

9%

5%

4%

RCPX: Complejidad del producto. Est dado por la

combinacin de los multiplicadores RELY, DATA,
CPLX y DOCU.

Muy Bajo
7,8

Bajo
9-11

Nominal
12

Alto
13-15

Muy Alto
16-18

Extra Alto
19-21

Poca

Algo

Bsica

Fuerte

Muy fuerte

Extrema

Simple

Algo

Moderada

Compleja

Pequea

Pequea

Moderada

Grande

Muy comple- Extremadamente compleja

ja
Muy grande Muy grande

15

RUSE:
ctura.

Reusabilidad.
Muy Bajo

RUSE

Est

Bajo
Nada

dado

por

Nominal
Por Proyecto

el

mismo

Alto
Por Programa

multiplicador

RUSE

Muy Alto
Por lnea de Producto

del

modelo

Post

arquite

Extra Alto
Por mltiples lneas de productos

PDIF: Dificultad de la plataforma. Est dado por la combinacin de los multiplicadores TIME, STOR y PVOL.
Bajo
Suma de TIME, STOR y PVOL 8
Restricciones de TIME &
50%
STOR
Volatilidad de la plataforma
Muy estable

Nominal
9
50%

Alto
10-12
65%

Muy Alto
13-15
80%

Extra Alto
16,17
90%

Estable

Algo voltil

Voltil

Muy voltil

PREX: Experiencia del personal. Est dado por la combinacin de los multiplicadores AEXP, PEXP y LTEX
Extra Bajo
Suma AEXP, PEXP y 3,4
LTEX
Experiencia
en
la <= 3 meses
aplicacin, plataforma,
lenguaje y herramientas
utilizadas

Muy Bajo
5,6

Bajo
7,8

Nominal
9

Alto
10,11

Muy Alto
12,13

Extra Alto
14

5 meses

9 meses

1 ao

2 aos

4 aos

6 aos

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

Muy Bajo
75% del nominal

Bajo
85%

Nominal
100%

Alto
130%

Muy Alto
160%

Extra Alto

FCIL: Facilidades. Est dado por la combinacin de los multiplicadores TOOL y SITE.
Extra Bajo
Suma de TOOL y 2
SITE
Soporte de herra- Mnimo
mientas de software

Muy Bajo
3

Bajo
4,5

Nominal
6

Algo

CASE Simples Herramientas

bsicas segn el
ciclo de vida
Mltiples lugares de Soporte dbil Algo de soporte Algo de soporte Soporte bsico
desarrollo
para el desa- para desarrollos para desarrollos para desarrollos
rrollo comple- complejos
moderados
complejos
jo

Alto
7,8

Muy Alto
9,10

Extra Alto
11

Buenas, moderada-mente
integradas
Fuerte soporte
para el desarrollo de procesos
moderados

Muy buenas,
moderadamente
integradas
Fuerte soporte
de desarrollos
de procesos
simples

Muy buenas totalmente

integradas
Muy fuerte soporte para el
desarrollo de procesos
complejos

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 Tecnolgico 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

Los valores que asume cada uno de stos multiplicadores en cada nivel se pueden ver en la siguiente figura:

Referencias bibliogrficas
- Mtrica Versin 3, Ministerio de Administraciones Pbilcas Espaol, http://www.map.es/csi/metrica3/index.html
- Use Cases and Function Points, artculo disponible en el site de

16