Professional Documents
Culture Documents
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
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.
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:
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
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.
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.
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:
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.
mejor panorama para la determinacin de la complejidad de los Archivos Lgicos Internos o de Interfaz
Externos.
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
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.
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
2.4.2 COCOMO II
El segundo de los mtodos posibles es la aplicacin del
mtodo COCOMO II directamente sobre los Puntos de
5
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)
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
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
2.83
Muy Alto
1.10
Bajo
6.24
Total
1.05
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
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
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
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:
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
Factor
E4
E5
E6
E7
E8
Peso
2
1
1
1
1
0.5
0.5
2
1
1
1
1
-1
Descripcin
Peso Valor
asignado
T1 Sistema distribudo
2
0.5
0.5
1
3
1
1
3
0
T7 Facilidad de uso
T8 Portabilidad
T9 Facilidad de cambio
Peso
0.5
1
2
-1
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
Descripcin
Peso Valor
asignado
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
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
Todo el grupo es
full-time
Se usar lenguaje
C++
Actividad
Anlisis
Diseo
Programacin
Pruebas
Sobrecarga (otras actividades)
Porcentaje
10.00%
20.00%
40.00%
15.00%
15.00%
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.
Ejemplo
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:
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.
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
- 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
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:
Tipos de registro
1
2-5
>5
Elementos de datos
1-19
20-50
Baja
Baja
Baja
Media
Media
Alta
>50
Media
Alta
Alta
"Elementos de datos" representa la cantidad de elementos de datos bsicos (campos nicos) que componen el
Archivo.
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?
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).
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
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:
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
Bajo
Nominal
Alto
Muy
Bajo
Bajo
Nominal
Alto
Muy Alto
D/P <
10
D/P >=
1000
DATA
Operaciones de Control
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra alto
Operaciones de Clculo
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
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
Nominal Alto
De acuer- Excesiva
do a las
necesidades exactas de las
etapas del
ciclo de
vida
Muy Alto
Muy
Excesiva
Los valores que asume cada uno de stos multiplicadores en cada nivel se pueden ver en la siguiente figura:
Bajo Nominal
Alto Muy
Alto
<= 50% de uso de los 70% 85%
recursos disponibles
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.
Bajo Nominal
Alto Muy
Alto
<= 50% de uso del espacio 70% 85%
disponible
Extra
Alto
95%
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
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:
Edicin y
codificacin
con debug
Nominal
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
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
Multimedia
Nominal Alto
9
Muy Extra
Alto Alto
10,11 12,13 14,15
55%
65%
75%
85%
12%
9%
5%
4%
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
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
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
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