UNIVERSIDAD DE LOS ANDES

UNIVERSIDAD DE LOS ANDES
Análisis de sensibilización de la estimación usando COCOMO II y puntos
de casos de uso (Use Case points)
Juan Carlos Lopera
Luís Carlos Ávila
Javier Murcia
Camilo Forero
Jenny Alexandra Marín
200925616
201017972
201011331
201011271
201018091
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
TABLA DE CONTENIDO
1.
INTRODUCCIÓN .............................................................................................................................. 3
2.
PUNTOS DE CASOS DE USO (USE CASE POINTS) .................................................................... 3
3.
COCOMO II CONSTRUCTIVE COST MODEL .............................................................................. 6
4.
ANEXOS .......................................................................................................................................... 10
4.1
EJERCICIO DE ESTIMACIÓN USANDO USE CASE POINTS.................................................................. 10
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
1. Introducción
En este documento se analiza que tan sensible son los modelos de estimación
de puntos de casos de uso (Use case points) y COCOMO II, a la subjetividad
del estimador. Adicionalmente se habla sobre cuales son los factores que más
afectan los resultados de cada modelo.
Con base en el análisis realizado, se determinan cuales son las variables más
sensibles sobre las cuales se debería ejercer algún tipo de control en la
estimación, y cuáles variables no son sensibles y se podrían considerar
eliminarlas del modelo sin afectar sensiblemente el resultado de estimación.
Para el análisis se escogió trabajar con el proyecto de la aplicación de recursos
humanos en donde ya se había realizado un trabajo de especificación de casos
de uso y de estimación por puntos funcionales.
2. Puntos de casos de uso (Use Case points)
El método de estimación por puntos de casos de uso es muy sensible a la
subjetividad del estimador y esto es debido a que depende de diferentes
factores que son calificados por el estimador basado en su criterio. Al parecer
este problema nos lleva a tener estimaciones finales de puntos de casos de
uso poco precisas.
Cada factor establecido para la técnica tiene un peso por defecto asociado.
Estos factores deben ser evaluados por el estimador según su juicio. El
principal problema al evaluar cada uno de esos factores es la falta de
estandarización. Por ejemplo: Hicimos el experimento de realizar en el grupo
tres estimaciones sobre el mismo proyecto. El proyecto que se uso como base
común para cada uno de los integrantes fue la aplicación de recursos humanos
que se usó en una tarea anterior para hacer su respectiva estimación usando la
técnica de puntos funcionales. Al inicio nos pusimos de acuerdo en el número
de transacciones por cada caso de uso que en total fue 200 UUCP y 9 Actor
Weighting (Ver anexos punto Ejercicio de estimación usando Use case points).
Hasta ahí ya teníamos el punto de partida para que cada uno hiciese su
estimación de acuerdo a su criterio evaluando cada uno de los factores. Como
era de esperarse el resultado fue distinto en los tres casos.
Encontramos que para los factores ambientales se obtuvieron los siguientes
valores: 0.8, 0.77, 0.74 (Ver anexos punto Ejercicio de estimación usando Use
case points). Luego de ver los resultados se nos presentó la duda sobre cómo
cada uno de los involucrados en la prueba determino el significado de cada
criterio. Así que lo debatimos y llegamos a la conclusión de que cada uno de
nosotros tenía una perspectiva distinta sobre lo que era cada criterio. En
algunos casos acertábamos, en otros diferíamos desvirtuando la estimación
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
debido a que cada persona tenía razón en sus argumentos. Uno de los
problemas que se nos presentó fue en el factor ambiental de dificultad del
lenguaje. Uno de los argumentos para éste factor fue que la dificultad del
lenguaje de programación estaba dada en la experiencia que se tenia en este
lenguaje. Entre más experiencia, menos dificultad entonces menor la magnitud
a definir. Otro de los argumentos que se discutió para este factor fue que la
dificultad del lenguaje de programación estaba dada por la habilidad que tienen
los desarrolladores para desarrollar lo que les piden en el tiempo dado sin
importar la experiencia que tengan teniendo en cuenta que pueden existir
desarrolladores con poca experiencia y muy hábiles. En ambos casos los
argumentos son válidos, pero al momento de asignar una magnitud a ese factor
el tema se vuelve un poco ambiguo. Supongamos que tenemos un grupo de
desarrolladores con poca experiencia, pero con gran habilidad para hacer
desarrollos en poco tiempo. Bajo el primer argumento el factor se calificaría
según la experiencia, pero como los desarrolladores tienen poca experiencia
entonces la magnitud para el factor sería alta (La regla es: Entre más
experiencia en un lenguaje, menos dificultad entonces menor la magnitud a
asignar) y en ese caso no importarían las habilidades que tienen lo
desarrolladores y se podría sobreestimar el resultado final. Adicional a esto otro
argumento válido para este factor podría ser que el lenguaje de programación
seleccionado sea muy difícil de aprender, lo que dejaría a un lado la habilidad y
la experiencia del equipo de desarrollo. Si el lenguaje es difícil de aprender, y el
equipo es experto en ese lenguaje, al calificar teniendo el argumento anterior
podría estar desvirtuando la estimación final.
Otro tipo de problema que puede presentarse en la interpretación de los
factores es la magnitud a asignar. Puede no ser claro como debe asignarse la
magnitud de dicho factor: ¿Un valor mayor ó menor como afecta el resultado
final? Por ejemplo al calificar el factor ambiental de casos de uso estables se
puede llegar a pensar que entre el valor sea más alto quiere decir que se
cuentan con requerimientos más estables. Pero también se puede llegar a
pensar que entre más bajo sea el número menos cambian los requerimientos.
Ambos casos significan los mismo; los requerimientos son más estables entre
menos cambios existan en los requerimientos. En nuestro proyecto base de la
aplicación de recursos humanos se tiene una certeza muy grande de que los
requerimientos no van a cambiar mucho. Entonces para asignar la magnitud al
factor en el experimento alguien le asignó un valor bajo pensando a los
requerimientos porque esto significaba que los requerimientos iban a tener
menos cambios que al colocar un valor alto donde los requerimientos iban
tener muchos cambios y otra persona le asigno un valor alto pensando en que
los requerimientos iban a ser estables porque al colocarle un valor bajo
significaba que los requerimientos no iban a ser tan estables. En este factor en
particular el impacto en la estimación final es grande, porque es una de los
factores que más peso tiene por defecto al ser éste igual a dos. En
comparación con los otros factores esté es el valor más alto que se puede
llegar a encontrar.
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
Adicionalmente otro problema se puede presentar en que se tome muy literal
una característica del proyecto que se resuelve por una herramienta o técnica.
Eso puede suceder en el factor técnico Soporte para diferentes plataformas.
Además de que éste criterio puede presentar ambigüedad en su interpretación;
¿diferentes plataformas de SO?, ¿Hardware?, ¿Browser? ó ¿integración con
sistemas heterogéneos?; también es posible correr el riesgo de castigar
severamente éste factor sin tener en cuenta que existen herramientas que
reducen el esfuerzo. Por ejemplo la maquina virtual de java puede correr en un
gran número de plataformas hardware y software, permitiendo que el código
compilado en una plataforma pueda se ejecutada en otra. Para éste caso en
particular podríamos asignar una magnitud alta si es necesario que el sistema a
construir se pueda ejecutar en Linux, en Windows y en Mac pero si
consideramos que el lenguaje como es el caso de java nos permite la ejecución
multiplataforma pues el valor a asignar debería ser menor. El impacto de
asignar una magnitud para el peso por defecto de éste factor es alto porque su
peso es igual a dos.
Como hemos podido ver los factores que más afectan los resultados del
modelo son los que tienen un peso más alto como por ejemplo: Familiaridad
con el proyecto, Sistema distribuido requerido, Soporte de plataformas
cruzadas, requerimientos estables.
Finalmente podemos concluir que la subjetividad del estimador no va a estar
limitada siempre y cuando no exista un estándar definido para cada uno de los
factores que permitan evaluar mas acertadamente cada uno de ellos y que
dicha evaluación esté mas encaminada a satisfacer los objetivos del proyecto
en el que se este aplicando.
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
3. COCOMO II Constructive Cost Model
Para el caso de COCOMO II, basados en el ejercicio base del conteo de puntos
de casos de uso sin ajustar (Ver anexos punto Ejercicio de estimación usando
Use case points), el análisis se enfoco en analizar detalladamente por grupo de
variables la afectación sobre el estimativo inicial. Esto con el fin de poder
establecer un conocimiento de comportamiento del modelo ante una
circunstancia especifica del entorno o desarrollo de un proyecto.
Teniendo como base 200 UUCP, se realiza un cálculo preliminar evaluando
cada una de las variables de los 5 grupos de evaluación en la calificación
mínima, para poder realizar el análisis de sensibilización por cada uno de ellos;
esto con el fin de poder identificar claramente las variaciones en el estimado
final.
Resultado
del
análisis
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
Resultado Análisis Modelos.
Software Scale Drivers
Precedentedness
Development Flexibility
Architecture / Risk Resolution
Team Cohesion
Process Maturity
Software Cost Drivers
Product
Required Software Reliability
Data Base Size
Product Complexity
Developed for Reusability
Documentation Match to Lifecycle Needs
Personnel
Analyst Capability
Programmer Capability
Personnel Continuity
Application Experience
Platform Experience
Language and Toolset Experience
Project
Required Development Schedule Bajo
Multisite Development bajo
Use of Software Tools bajo
Platform
Platform Volatility baja
Storage Constraint bja (nominal es mas baja)
Time Constraint alta
bajo
alto
nominal Personas nominal tiempo nominal costo bajo Personas bajo tiempo costo
personas
39
12
59151
41
12
62718
39
12
59151
41
12
62055
39
12
59151
42
12
63238
39
12
59151
41
12
62290
39
12
59151
42
12
63673
alto
tiempo
36
36
35
36
35
11
12
11
12
11
alto
costo
54178
55055
53517
53731
52964
39
39
39
39
39
12
12
12
12
12
59151
59151
59151
59151
59151
39
35
28
38
31
11
11
11
12
11
47912
53236
43180
57968
47912
49
50
68
48
48
13
13
14
13
13
74531
75714
102924
73348
72756
39
39
39
39
39
39
12
12
12
12
12
12
59151
59151
59151
59151
59151
59151
55
52
50
48
46
47
13
13
13
13
13
13
83995
79263
76305
72165
70390
70982
27
29
31
31
33
33
11
11
11
11
11
11
41997
44955
47912
47912
50278
49687
39
39
39
12
12
12
59151
59151
59151
56
48
46
9
13
12
84586
72165
69207
39
31
30
19
11
11
59151
47321
46138
39
39
39
12
12
12
59151
59151
59151
34
39
39
11
12
12
51462
59151
59151
51
57
64
13
13
14
76897
86361
96417
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
Del análisis anterior se infiere, que COCOMO II es un modelo muy orientado al
grupo de trabajo, ya que estas variables tienen más influencia en el resultado
del estimativo de esfuerzo. Aunque COCOMO II contempla aspectos muy
relevantes de la ejecución de un proyecto que no son tenidos en cuenta en
otros métodos estimativos, se enfoca en el conocimiento detallado de los
participantes del proyecto, su experticia, su ambiente de trabajo, la distribución
geográfica, el dominio de las herramientas de soporte y la accesibilidad a
dichas herramientas. Conceptos claves ya que son estos los que pueden
generar mayor incertidumbre en la ejecución del proyecto.
Enfocándonos en el grupo de análisis del personal, que es el que demuestra
ser más sensible en razón de la producción de un estimativo, es necesario que
se realice un estudio muy detallado de cada uno de los miembros del equipo de
trabajo ya que se evidencia según el estudio anterior que una mala definición
de estas variables puede variar el estimado total en razón de un 33% aproxima
adicional de personal y un 40% adicional en costos aproximadamente cuando
se subestiman las capacidades del equipo de trabajo y en una razón de 31%
menos de personal y un 30% menos de costos cuando se sobrestiman las
capacidades del equipo de trabajo.
Con los resultados anteriores, llegamos a la conclusión que los estimativos
basados en el modelo COCOMO II, pueden tener mayor nivel de certeza en
grupos de trabajo consolidados, en los cuales se conozca con un mayor nivel
de certeza el trabajo y la experticia de cada uno de los colaboradores, ya que
se reducirá la incertidumbre de desfasar un estimación por desconocimiento del
grupo de trabajo. Adicionalmente, se recomienda el uso de información
histórica dirigida a medir información como: nivel de productividad, experiencia,
y desempeño del personal, con el fin de catalogarlos en dirección de los
parámetros del modelo de COCOMO II.
Según el análisis de sensibilidad del modelo COCOMO II, se puede llegar a la
conclusión que la variable menos afectada por un desfase (+/-) del estimativo
es la variable del tiempo, ya que en el análisis esta solo se ve afectada en
razón de 16% por encima y de 9 % por debajo del valor nominal. No quiera
esto decir que deja de ser un valor significativo pero si un valor, que no genera
un desfase demasiado proporcional en el estimativo final cuando el modelo no
se encuentra afinado. Es necesario tener en cuenta que existe un parámetro en
especial que demostró generar un desfase muy significativo y el cual se debe
tener muy en cuenta al momento de realizar su calificación en el modelo, ya
que genero un desfase de 25% menos y 58% más en el resultado final del
estimativo del tiempo. Este parámetro “Required Development Schedule”, hace
referencia a las restricciones de cronograma y debido a su naturaleza restringe
notablemente los límites temporales de la estimación.
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
Adicionalmente se puede extraer del estudio de sensibilidad que algunas
características no funcionales pueden llegar modificar el resultado final del
estimativo cuando el nivel de complejidad relacionado a mantenibilidad,
escalabilidad y reusabilidad es alto. Son estas características que al evaluar se
tienen que tener muy claras las expectativas frente a estas ya que de aumentar
su nivel de complejidad pueden significar un aumento en esfuerzo significativo
para el estimativo final, son todas estas características evaluadas en el grupo
de drivers del costo del producto software.
Enfocándonos en los grupos de plataforma, al igual que el grupo de personal
puede ser muy sensible en el momento de realizar una estimación, se debe
realizar un análisis muy detallada de la complejidad del sistema a si como
también de las restricciones a nivel de tiempo y espacio de almacenamiento, ya
que estas afectan considerablemente al esfuerzo y al costo, esto se puede ver
reflejado un estudio anterior ya que cualquiera de las variables puede llegar a
afectar al esfuerzo entre un 30% y un 60% aproximadamente esto cuando se
va a realizar un software con restricciones de plataforma elevadas, lo cual
implica que los costos se vean afectados de igual forma y en la misma tasa de
crecimiento. No se debe de ninguna manera sobrestimar la complejidad del
sistema ni tampoco subestimarla, recomendaríamos que se elaboraran criterios
de calificación para poder determinar el valor de cada una de estas variables,
estos se podrían realizar en base a la experiencia o desde el punto de vista de
los expertos.
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
4. Anexos
4.1 Ejercicio de estimación usando Use case points
Para este ejercicio se seleccionaron los casos de uso identificados en una
tarea anterior (Tarea 2 Casos de uso). Los casos de uso identificados son los
siguientes:
CU0001-Adicionar un empleado
CU0002-Actualizar la información de un empleado
CU0003-Borrar información del empleado
CU0004-Consulta sobre un empleado
CU0005-Ver una lista de los empleados
CU0006-Agregar información de un puesto de trabajo
CU0007-Actualizar la información del puesto de trabajo
CU0008-Borrar información de un puesto de trabajo.doc
CU0009-Consulta de un puesto de trabajo individual.doc
CU0010-Ver una lista de los puestos de trabajo.doc
CU0011-Asignar un empleado a un puesto de trabajo
CU0012-Transferir un empleado
CU0013-Borrar información de la asignación a un puesto de trabajo
CU0014-Consultar la asignación de un puesto de trabajo
CU0015-Ver una lista de las asignaciones de puestos de trabajo
Los actores identificados son los siguientes:
Actor Estudiantes
Actor Asignaciones
Actor Puestos de Trabajo
Para este ejercicio tres de los integrantes del grupo realizamos el ejercicio de
calificar los factores por aparte, sin discutir sobre la interpretación de los
factores a calificar. A continuación se muestran los puntos de casos de uso sin
ajustar y el actor weighting desde donde partió el ejercicio por parte de cada
uno de los integrantes
Puntos de casos de uso
Complejidad
1
2
3
4
5
6
7
8
Complejo
Complejo
Complejo
Complejo
Complejo
Complejo
Complejo
Promedio
Multiplicador
Nombre del caso de uso
15
15
15
15
15
15
15
10
CU0001-Adicionar un empleado
CU0002-Actualizar la información de un empleado
CU0003-Borrar información del empleado
CU0004-Consulta sobre un empleado
CU0005-Ver una lista de los empleados
CU0006-Agregar información de un puesto de trabajo
CU0007-Actualizar la información del puesto de trabajo
CU0008-Borrar información de un puesto de trabajo.doc
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
9
10
11
12
Complejo
Promedio
Complejo
Complejo
15
10
15
15
13
Simple
5
14
Complejo
15
15
Promedio
10
CU0009-Consulta de un puesto de trabajo individual.doc
CU0010-Ver una lista de los puestos de trabajo.doc
CU0011-Asignar un empleado a un puesto de trabajo
CU0012-Transferir un empleado
CU0013-Borrar información de la asignación a un
puesto de trabajo
CU0014-Consultar la asignación de un puesto de
trabajo
CU0015-Ver una lista de las asignaciones de puestos
de trabajo
Los puntos de casos de uso sin ajustar fueron calculados como se muestra en
la siguiente tabla:
Puntos de casos
Multilpicador
de uso sin ajustar
1
Simple
5
2
Average
10
3
Complex
15
Casos
de
uso
1
3
11
Description
Caso de uso simple- Hasta 3 transacciones.
Caso de uso promedio- 4 a 7 transacciones
Caso de uso complejo- Mas de 7
transacciones
200
Total
Casos de uso sin ajustar = 200 UUCP
Actor weighting
Complejidad
actores
1
2
3
Multiplicador
Complejo
Complejo
Complejo
3
3
3
Nombre del actor
Actor Estudiantes
Actor Asignaciones
Actor Puestos de Trabajo
El actor weighting fue calculado como se muestra en la siguiente tabla:
Actor weighting
Multiplicador
1
Simple
1
2
Promedio
2
3
Complejo
3
Total
Actor weighting = 9
Número de
actores
0
0
3
9
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
Hasta este punto la información es común para cada uno de los integrantes. De
aquí en adelante se muestran las calificaciones a los criterios ambientales y
técnicos asignados por cada uno de los participantes del ejercicio.
Integrante 1 - Camilo Forero
Factores ambientales
Factor ambiental
Multiplicador
Calificación
(0-5)
1
Familiarity With The
Project
1,5
4
2
Application Experience
0,5
5
3
OO Programming
Experience
1
5
4
Lead Analyst Capability
0,5
5
5
Motivation
1
4
6
Stable Requirements
2
2
7
Part Time Staff
-1
0
8
Difficult Programming
Language
-1
3
0,77
Total
Factores de complejidad técnica
Factor técnico
Multiplicador
Calificación
(0-5)
1
Distributed System
Required
2
3
2
Response Time Is
Important
1
3
3
End User Efficiency
1
3
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
4
Complex Internal
Processing Required
1
2
5
Reusable Code Must
Be A Focus
1
2
6
Installation Ease
0,5
7
Usability
0,5
3
3
8
Cross-Platform
Support
2
2
9
Easy To Change
1
2
10
Highly Concurrent
1
2
11
Custom Security
1
2
12
Dependence On ThirdParty Code
1
2
13
User Training
1
1
0,92
Total
Total horas de esfuerzo
Calculos
TCF
Factor de complejidad técnica
EF
Factor ambiental
UUCP
Puntos de caso de uso sin ajustar
AW
Actor Weighting
Calculo de puntos de caso de uso
UCP
Puntos de caso de uso
Calculo de esfuerzo estimado
Ratio
Horas de esfuerzo por caso de uso
Horas de esfuerzo
0,92
0,77
200
9
148,1
20
2.961
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
Integrante 2 - Alexandra Marín
Factores ambientales
Factor ambiental
Multiplicador
Calificación
(0-5)
1
Familiarity With The
Project
1,5
4
2
Application Experience
0,5
4
3
OO Programming
Experience
1
4
4
Lead Analyst Capability
0,5
4
5
Motivation
1
4
6
Stable Requirements
2
5
7
Part Time Staff
-1
1
8
Difficult Programming
Language
-1
5
0,74
Total
Factores de complejidad técnica
Factor técnico
Multiplicador
Calificación
(0-5)
1
Distributed System
Required
2
3
2
Response Time Is
Important
1
3
3
End User Efficiency
1
4
4
Complex Internal
Processing Required
1
1
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
5
Reusable Code Must
Be A Focus
1
2
6
Installation Ease
0,5
7
Usability
0,5
5
5
8
Cross-Platform
Support
2
1
9
Easy To Change
1
3
10
Highly Concurrent
1
5
11
Custom Security
1
2
12
Dependence On ThirdParty Code
1
3
13
User Training
1
1
0,97
Total
Total horas de esfuerzo
Calculos
TCF
Factor de complejidad técnica
EF
Factor ambiental
UUCP
Puntos de caso de uso sin ajustar
AW
Actor Weighting
Calculo de puntos de caso de uso
UCP
Puntos de caso de uso
Calculo de esfuerzo estimado
Ratio
Horas de esfuerzo por caso de uso
Horas de esfuerzo
0,97
0,74
200
9
150,0
20
3.000
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
Integrante 3 - Javier Murcia
Factores ambientales
Factor ambiental
Multiplicador
Calificación
(0-5)
1
Familiarity With The
Project
1,5
4
2
Application Experience
0,5
5
3
OO Programming
Experience
1
5
4
Lead Analyst Capability
0,5
5
5
Motivation
1
3
6
Stable Requirements
2
2
7
Part Time Staff
-1
3
8
Difficult Programming
Language
-1
0
0,8
Total
Factores de complejidad técnica
Factor técnico
Multiplicador
Calificación
(0-5)
1
Distributed System
Required
2
0
2
Response Time Is
Important
1
2
3
End User Efficiency
1
3
4
Complex Internal
Processing Required
1
0
Análisis de sensibilización de la
estimación usando COCOMO II y
puntos de casos de uso (Use Case
points)
5
Reusable Code Must
Be A Focus
1
3
6
Installation Ease
0,5
7
Usability
0,5
3
3
8
Cross-Platform
Support
2
3
9
Easy To Change
1
3
10
Highly Concurrent
1
2
11
Custom Security
1
4
12
Dependence On ThirdParty Code
1
3
13
User Training
1
3
0,97
Total
Total horas de esfuerzo
Calculos
TCF
Factor de complejidad técnica
EF
Factor ambiental
UUCP
Puntos de caso de uso sin ajustar
AW
Actor Weighting
Calculo de puntos de caso de uso
UCP
Puntos de caso de uso
Calculo de esfuerzo estimado
Ratio
Horas de esfuerzo por caso de uso
Horas de esfuerzo
0,92
0,8
200
9
153,8
20
3.076