Estimación de Esfuerzo

Neotect S.A.
Estimación
Esfuerzo
de
Análisis de las Metodologías COCOMO II y Puntos de Casos de Uso
Ángela Archila
Edison Molano
Gustavo Gutiérrez
Jesús Larrota
Wolfgand Kook
25/03/2010
Estimación de Esfuerzo 2010
Tabla de contenido
1
Proyecto Seleccionado .......................................................................................................... 3
2
COCOMO II ............................................................................................................................ 4
2.1
Aplicación de la Metodología ........................................................................................ 4
2.2
Resultados ..................................................................................................................... 6
2.3
Análisis de la Metodología ..............................................Error! Bookmark not defined.
2.3.1
Ventajas ................................................................................................................. 8
2.3.2
Desventajas ........................................................................................................... 9
Conclusiones y Recomendaciones ........................................................................................ 9
3
Puntos de Caso de Uso ........................................................................................................ 11
3.1
Aplicación de la Metodología ...................................................................................... 11
3.1.1
Actores ................................................................................................................ 11
3.1.2
Casos de Uso ....................................................................................................... 11
3.1.3
Factores de Ajuste Técnicos ................................................................................ 11
3.1.4
Factores de Ajuste de Ambiente ......................................................................... 12
3.2
Resultados ................................................................................................................... 13
3.3
Análisis de la Metodología .......................................................................................... 13
3.3.1
Factores Críticos .................................................................................................. 13
3.3.2
Ventajas ............................................................................................................... 14
3.3.3
Desventajas ......................................................................................................... 14
3.3.4
Sensibilidad a la Subjetividad .............................................................................. 14
3.3.5
Conclusiones y Recomendaciones ...................................................................... 14
2
Estimación de Esfuerzo 2010
1 Proyecto Seleccionado
El proyecto elegido para la estimación es CreditScore, un proyecto que fue solicitado para la
materia de Modelos y Estándares en Procesos de Software en el marco de la Especialización en
Construcción de Software, y que será desarrollado en Windows Form en java. Este consiste en
lo siguiente, de acuerdo al enunciado de dicho proyecto:
“El Banco de Los Alpes desea contratar con su equipo de desarrollo, la construcción de una
herramienta para calcular el riesgo crediticio (CreditScore) tanto de sus clientes actuales como
de sus potenciales clientes.
En general, el riesgo de crédito es un número generado por un algoritmo matemático basado
en información de los reportes de crédito históricos y de comparaciones con respecto a muchos
otros usuarios. El número resultado es una predicción altamente efectiva de cómo es probable
que un cliente se comportará en el pago de sus deudas.
Entre más alto sea el número, más facilidad para obtener un crédito tendrá el cliente.
Existen muchos modelos para calcular el riesgo de crédito, uno de ellos es FICO. Su escala de
valores está entre 300 y 850. La gran mayoría de personas tendrán valores entre 600 y 800. Un
valor de 720 o superior le brindará mejores condiciones de crédito (mejor tasa de interés).
Usted debe construir una herramienta que le permita a los analistas de crédito, ingresar todos
los datos requeridos de una persona para calcular su riesgo de crédito usando una versión para
Colombia basada en FCO. La fórmula para el cálculo del rango de crédito está dada por los
siguientes porcentajes:





35% Historia de pagos
30% Montos adeudados
15% Duración del crédito
10% Nuevos créditos
10% Tipo de crédito
Sin embargo, no solo la información financiera cuenta, también el nivel de estudio, el género, el
estrato socioeconómico, la profesión, el estado civil y número de hijos, etc.
Se debe construir una herramienta fácil de usar para los analistas de crédito. La tecnología
seleccionada para el desarrollo es Java / Swing”.
3
Estimación de Esfuerzo 2010
2 COCOMO II
Se utilizó USC herramienta que implementa el modelo de COCOMO II desarrollada por la
universidad del Sur de California.
2.1 Aplicación de la Metodología
El modelo a su vez presenta tres sub modelos basado en la diferentes necesidades del
software, el sub modelo seleccionado por los encargados del proyecto es el de “Diseño
Anticipado”.
El Diseño Anticipado puede utilizarse para obtener estimaciones muy aproximadas de un
proyecto aun cuando no está definida su arquitectura completamente y se conoce muy poco
sobre el tamaño del producto que se va a desarrollar, la naturaleza de la plataforma objetivo,
la naturaleza del personal involucrado en el proyecto ó especificaciones detalladas del proceso
que se va a realizar.
Para ello iniciamos con una estimación del tamaño del producto, a través del método PROBE.
Esta estimación dio lugar a una cantidad de líneas de código (LOC):
4
Estimación de Esfuerzo 2010
Clase
Descripción
LoC
Conexión
Respuesta - DAO
Pregunta – DAO
Sección – DAO
Scoring – DAO
Cuestionario – DAO
Cliente – DAO
Respuesta - TO
Pregunta – TO
Sección – TO
Scoring – TO
Cuestionario – TO
Cliente – TO
Scoring BO
PanelCuestionario
Cuestionario – BO
Cliente – BO
Secciones – BO
Preguntas – BO
Respuestas – BO
Panel Cliente
Panel Historial Pagos
Panel Montos Adeudados
Panel Duración Créditos
Panel Nuevos Créditos
Panel Tipo Crédito
Interfaz Credit Scoring
TOTAL
Clase de conexión a datos
Insertar, Buscar, Listar, Actualizar, Borrar.
Insertar, Buscar, Listar, Actualizar, Borrar.
Insertar, Buscar, Listar, Actualizar, Borrar.
Insertar, Buscar, Listar, Actualizar, Borrar.
Insertar, Buscar, Listar, Actualizar, Borrar.
Insertar, Buscar, Listar, Actualizar, Borrar.
Encapsulamiento de entidades
Encapsulamiento de entidades
Encapsulamiento de entidades
Encapsulamiento de entidades
Encapsulamiento de entidades
Encapsulamiento de entidades
Métodos de lógica de negocio
Métodos de lógica de negocio
Métodos de lógica de negocio
Métodos de lógica de negocio
Métodos de lógica de negocio
Métodos de lógica de negocio
Métodos de lógica de negocio
Paneles. Interfaz gráfica.
Paneles. Interfaz gráfica.
Paneles. Interfaz gráfica.
Paneles. Interfaz gráfica.
Paneles. Interfaz gráfica.
Paneles. Interfaz gráfica.
Frame principal. Interfaz gráfica.
150
100
100
100
100
100
100
90
90
90
90
90
90
250
230
50
50
50
50
50
100
100
100
100
100
100
150
2770
2.2 Resultados
Una vez obtenidas las líneas de código, de acuerdo a las líneas guía del Diseño Anticipado. De
acuerdo a ello pudimos obtener la siguiente información:
5
Estimación de Esfuerzo 2010
En total, la tabla nos indica entre 4 y 8,9 meses hombre (Esto es, entre 640 y 1424 horas
hombre) para el desarrollo del proyecto, con una alta probabilidad de un esfuerzo de 6 meses
hombre (960 horas hombre).
2.3 Análisis de la Metodología
Según nuestros cálculos determinamos los siguientes valores para los factores del
modelo recordando que utilizamos el diseño anticipado, estos se describen en la
siguiente tabla de color rojo. Los demás valores muestran los resultados de sus
variaciones en el modelo.
Effort
RCPX
PDIF
PERS
PREX
FCIL
6
NOM
HI
VHI
LO
HI
VHI
XHI
LO
NOM
VHI
XHI
LOW
HI
VHI
XHI
6
6.1
6.2
6
6.1
6.3
6
6.5
6.3
6
5.9
6.2
6
5.9
5.9
Sched
Prod
Cost
Inst
Staff
6.5
479.1
8937
3.1
0.9
6.5
470
9095
3.2
0.9
6.6
459
9326
3.3
0.9
6.5
479.1
8937
3.1
0.9
6.5
465
9191
3.2
0.9
6.6
450
9505
3.3
1
6.5
479.1
8937
3.1
0.9
6.7
439
9735
3.4
1
6.6
452
9432
3.3
1
6.5
479.1
8937
3.1
0.9
6.5
482.7
8871
3.1
0.9
6.5
463
9240
3.2
0.9
6.5
479.1
8937
3.1
0.9
6.5
483
8853
3.1
0.9
6.4
487
8786
3.1
0.9
Estimación de Esfuerzo 2010
Se puede notar que el cambio no es significativo en la mayoría de los resultados
excepto para el Costo, es por tal razón que vamos a tomar este como ejemplo para
visualizar su cambio con cada uno de los factores de ajuste. Cabe destacar que hace
falta RUSE pero analizando su variación determinamos que su cambio no influye
significativamente en los resultados.
Para RCPX, PDIF, PERS, PREX y FCIL su variación es notoria, se observa lo siguiente:
RCPX
9400
9300
9200
9100
Cost
9000
8900
8800
8700
NOM
HI
VHI
PDIF
9600
9400
9200
Cost
9000
8800
8600
LO
7
HI
VHI
Estimación de Esfuerzo 2010
PERS
9800
9600
9400
9200
Cost
9000
8800
8600
8400
XHI
LO
NOM
PREX
9300
9200
9100
9000
Cost
8900
8800
8700
8600
VHI
XHI
LOW
FCIL
8950
8900
8850
Cost
8800
8750
8700
HI
2.3.1




VHI
XHI
Ventajas
Las herramientas computacionales disponibles simplifican su uso e interpretación.
Tiene pocas variables
Se acerca a la realidad en la mayoría de casos
COCOMO es una herramienta basada en la líneas de código la cual le hace muy
poderoso para la estimación de costos.
8
Estimación de Esfuerzo 2010
2.3.2
Desventajas


No es fácil de realizar ni de interpretar
No saca resultados fiables en proyectos pequeños
Existen muchos datos de ajuste donde se introducen valores de calificación subjetiva
que pueden sesgar la estimación si son ingresados por un estimador inexperto
Es necesario conocer cuál va a ser el equipo de desarrolladores, equipo informático,
entorno. Es engorroso de utilizar en empresas de software donde no tienen personal
asignado exclusivamente a desarrollo.
La selección del modo de desarrollo es extremadamente importante.
Fuertemente dependiente de los datos históricos de la organización, que no siempre
están disponibles.




Utilizando el modelo COCOMO nos podemos dar cuenta que es bastante sensible a la
subjetividad del estimador: Existe una cantidad importante de factores que dependen de la
experiencia de la persona que los determina su capacidad y experiencia con el personal
involucrado en el proyecto, obteniendo así valores imprecisos de estimación, debido a que los
parámetros pueden ser vistos de distinta manera por distintos analistas que usan el método.
Muchos de los factores de ajuste utilizados, como RELY (fiabilidad), son difícilmente
aprehensibles para un estimador inexperto, mientras que otros, como APEX (experiencia de los
analistas), son de difícil estimación a partir de datos objetivos. Esto hace que el análisis pueda
ser impreciso o desviarse de la realidad si se indica mal el número de líneas de código fuente.
Conclusiones y Recomendaciones
Se debe tener en cuenta que la persona que realice la estimación debe conocer claramente el
alcance del proyecto, el grupo de desarrollo, las capacidades del recurso humano, y a la vez
contar con un grado de experiencia aceptable; de lo contrario, la estimación no será muy
exacta y no se ajustará a la realidad.
Se requiere tener experiencia en estimación en LOC pues es necesario partir de un número de
líneas de código base, para ello es importante la historia de proyectos anteriores, pueden
usarse métodos como PROBE donde es necesario tener las LOC planeadas y las reales para
distintos proyectos.
Es necesario tener en cuenta que COCOMO II no se ajusta a pequeños proyectos, muestra
mayor eficiencia y confiabilidad en proyectos medianos y grandes.
Es importante tener un modelo a seguir para la estimación de tamaño de proyectos
Una parte importante de la toma de decisiones al comenzar un nuevo proyecto de desarrollo
de software está dada por el costo que éste tendrá. La estimación de estos costos es una de las
grandes preocupaciones antes de comenzar, para ello es necesario tener una visión del alcance
del proyecto y una técnica o método que ayude a ser más acertados, COCOMO II brinda una
facilidad grande en estas etapas iniciales, y además cuenta con otras opciones para el
mantenimiento del proyecto, su uso es sencillo ya que se encuentran muchas herramientas
libres que facilitan su manejo.
9
Estimación de Esfuerzo 2010
10
Estimación de Esfuerzo 2010
3 Puntos de Caso de Uso
Se utilizó una herramienta en Excel construída anteriormente por uno de los miembros del
grupo para la estimación de diferentes proyectos de Software. La herramienta utilizada se
basa en estadísticas en el manejo de la metodología RUP para realizar un estimado de tiempos
por cada una de las disciplinas y de las fases, y determinar así un estimado de los recursos
requeridos en cada etapa. Finalmente, este estimado de recursos y de tiempos da lugar a un
estimativo final de costos.
3.1 Aplicación de la Metodología
3.1.1 Actores
Se identificó un único actor. Sin embargo, se determinó que la complejidad del mismo era
alta.
Actors Weight Factors
Description
Simple_Actor
Program interface
Interactive or protocol
driven interface
Graphical interface
Average_Actor
Complex_Actor
Enter
Count
Weighted Value
Comment
1
0
0
0
2
0
0
0
3
1
3
0
Weight
3
Total Actor Weight
3.1.2 Casos de Uso
El número de casos de uso es relativamente pequeño, se encontró únicamente un caso de uso
complejo.
Use Cases Weight Factors
(Bases on the number of
transactions in a use case)
Enter
Count
Weight
Weighted Value
Comment
Simple_Use_Case
3 or fewer transactions
5
1
5
0
Average_Use_Case
4 to 7 transactions
10
3
30
0
Complex_Use_Case
more than 7 transactions
15
1
15
0
50
Transaction Based Factors
En total, se hallaron 53 puntos de caso de uso, antes de hacer el ajuste de los mismos.
3.1.3
Factores de Ajuste Técnicos
Technical
Weight
Factors
T1
Distributed
System
T2
Response or
throughput
performance
objectives
T3
End-user
efficiency (online)
Rating Scale is 0
to 5
0 =not important
2,00
5 =essential
Enter
Rating
Weighted
Value
Reason
0
0 Es una aplicación cliente servidor
0 =not important
1,00
5 =essential
4
4
La aplicación debe tener tiempos
rendimiento eficientes
de
0 =not important
1,00
5 =essential
4
4
La aplicación debe tener tiempos
rendimiento eficientes
de
T4 Complex internal 0 =not important
1,00
processing
5 =essential
4,5
El sistema utilizara objetos externos de
4,5 procesamiento para el calculo FICO a traves
de redes neurales
T5 Code must be 0 =not important
1,00
reusable
5 =essential
3
El codigo de los modulos identifcados para
3 realizar la captura de preguntas debe ser
reusable
11
Estimación de Esfuerzo 2010
T6 Easy to install
0 =not important
0,50
5 =essential
1
0,5
No se cuentra dentro de los requerimientos no
funcionales del sistema
T7 Easy to use
0 =not important
0,50
5 =essential
5
2,5
El sistema estará orientado al facil ingreso de
información del usuario final
T8 Portable
0 =not important
2,00
5 =essential
0
0
No se cuentra dentro de los requerimientos no
funcionales del sistema
T9 Easy to change
0 =not important
1,00
5 =essential
2
2
T10 Concurrent
0 =not important
1,00
5 =essential
3
3
T11 Includes special 0 =not important
1,00
security features
5 =essential
1
No se cuentra dentro de los requerimientos no
funcionales del sistema. La aplicación
1
permitie el ingreso sin solicitud especial de
seguridad
T12 Provides direct
0 =not important
access
for
third
1,00
5 =essential
parties
0
0 No requerido
T13 Special user
0 =not important
training facilities are
1,00
5 =essential
required
0
0
No requiere especial entrenamiento, los datos
de captura son intuitivos al usuario final
24,5
Technical Factors
.6
Technical Complexity
(.01*Technical
Factor (TCF)
Factor)
3.1.4
Por ser aplicación cliente servidor, la
aplicación no tiene caracteristicas fuertes de
concurrencia. La concurrencia se dara a nivel
de base de datos
+
0,845
Factores de Ajuste de Ambiente
Environmental
Factors for Team Rating Scale is 0 to 5 Weight
and Weights
F1 Faimilar with the
0 = no experience,
Rational
Unified
1,50
3=average, 5=expert
Process
Enter
Rating
Weighted
Value
4
6
Reason
F2
Application 0 = no experience,
experience
3=average, 5=expert
0,50
0
No contamos con experiencia en la
construcción de este tipo de sistemas.
0 No contamos con experiencia en la
construcción
de
sistemas
que
implementen redes neuronales
F3 Object-Oriented 0 = no experience,
Experience
3=average, 5=expert
1
4
4
0,50
3
1,5
1
5
5 100% motivados
2
3
Se
han
introducido
nuevas
6 funcionalidades recientemente a los
requerimientos iniciales
0=no part time , 5=all
part time
-1,00
5
-5
0=easy
language,
3=average,5=difficult
-1,00
3
-3
F4 Lead
capability
analyst 0 = no experience,
3=average, 5=expert
0=no
motivation,
F5 Motivation
3=average, 5=high
F6
Stable 0=extremly
unstable,
requirements
5=unchanging
F7
Part-time
workers
F8
Difficult
programming
language
Environmental
Factors
EFactor
12
14,5
0,965
Alto conocimiento del equipo
programación orientada a objetos
en
Todos tenemos tiempo compartido con
el proyecto
Estimación de Esfuerzo 2010
3.2 Resultados
Puntos de Caso de Uso sin Ajustar
Factor de Complejidad Técnica
Factor de Ambiente
Puntos de Caso de Uso Ajustados
Horas Hombre por Caso de Uso
Porcentaje Estimado de Desviación
Tiempo Estimado (Horas Hombre)
53
0,845
0,965
43,217525
201
20%
1037,22
Es evidente que el número de horas hombre estimado (1037,22) está dentro del rango dado
de COCOMO II, y efectivamente se acerca al resultado arrojado como más probable (960 Horas
Hombre).
A causa de las características específicas de la herramienta utilizada, basada en estadísticas en
el uso de RUP en proyectos a nivel mundial, estas horas pudieron ser distribuidas a cada una
de las etapas de desarrollo, de acuerdo, de acuerdo al siguiente gráfico. Cabe anotar que esta
proyección no es parte de la metodología de Puntos de Caso de Uso:
Horas proyecto
Iniciación
%
5,0%
Elaboración Construcción
22,5%
61,3%
Administración del Proyecto
5,0%
3
16
Modelamiento del Negocio
2,5%
18
Requerimientos
2,5%
5
Análisis y Diseño
20,0%
Implementación
Pruebas
Transición
11,3%
26
8
51,86
8
0
0
25,93
8
13
0
25,93
10
104
62
31 207,44
45,0%
0
21
415
31 466,75
10,0%
5
31
52
16 103,72
Despliegue
5,0%
3
16
26
8
51,86
Configuración y Control de Cambios
5,0%
3
16
26
8
51,86
Ambiente
5,0%
51,86
3.3
5
16
16
16
51,86
233,37
635,30
116,69
Análisis de la Metodología
3.3.1 Factores Críticos
El modelo de puntos de caso de uso depende mucho de la especificación de los mismos, riesgo
que se reduce en parte si determinamos claramente en qué consiste una transacción, y si
tenemos en cuenta que en gran parte la especificación de los mismos depende de qué se
considere como precondición y postcondición de cada uno de ellos, y por lo tanto al realizar
una especificación completa unos casos de uso terminan complementando las falencias en la
especificación de los otros.
Es importante asimismo ser muy crítico con la asignación de los factores de ajuste, pues estos
en combinación pueden desde reducir el tamaño del proyecto a la cuarta parte (0,255) hasta
duplicarlo (2,25).
1
Se estimaron 20 de acuerdo a las recomendaciones, puesto que no se cuenta con datos anteriores.
13
Estimación de Esfuerzo 2010
No se considera que ninguno de los factores tenidos en cuenta dentro de la metodología sean
innecesarios para la misma, si bien es claro que el aporte que tienen los actores sobre los casos
de uso no ajustados tiende a ser mucho menor que el aporte que tienen las transacciones.
3.3.2



Ventajas
Es muy fácil de realizar e interpretar, más aún que COCOMO
Tiene pocas variables, menos aún que COCOMO
Proporciona una medida comparativa del tamaño de un proyecto
3.3.3


Desventajas
La metodología de desarrollo debe incluir especificación de caso de uso
Los casos de uso deben estar especificados. Esto implica que la estimación no se
puede hacer al principio del proyecto, y que varía rápidamente ante cambios en los
requerimientos. Por otro lado, es importante que la especificación de los casos de uso
se realice tan pronto como sea posible, lo que no es cierto en todos los proyectos.
Depende de la forma en que se especificaron los casos de uso (Ver abajo)
La estimación de esfuerzo depende de variables externas a la metodología (Ver abajo)
No hay una guía clara para la estimación de los valores en los factores de ajuste.



3.3.4 Sensibilidad a la Subjetividad
Como indicamos anteriormente, los factores de ajuste dependen igualmente de la subjetividad
del estimador, si bien unas políticas claras de determinación del valor que se debería dar a
cada uno de estos factores (Basadas probablemente en las establecidas para puntos de
Función) podrían mitigar este riesgo.
La estimación de esfuerzo, por otra parte, depende bastante de un factor de Horas Hombre
por Caso de Uso, que es diferente de acuerdo a la organización o al equipo. A causa de ello, si
bien la estimación de tamaño puede ser bastante confiable (Ver más adelante), el esfuerzo
estimado depende únicamente del criterio del estimador. Para mitigar este riesgo, sin
embargo, es útil tener un registro de datos históricos para el equipo en cuestión.
3.3.5 Conclusiones y Recomendaciones
El modelo de puntos de caso de uso tiene una granularidad muy alta dependiendo del número
de transacciones, sobre todo cuando se tienen definiciones de casos de uso con números de
transacciones entre 4 y 7 (Complejidad media), o mayores de 10 (Que en ningún caso, y sin
importar el número de transacciones, supera los 15 PCUs). Se podría hacer un ajuste sencillo a
la metodología creando una fórmula continua que retorne los PCUs a partir del número de
transacciones. A primera vista, la fórmula que estaríamos buscando sería muy similar a la
siguiente:
PCU = 5 * √TRANS
Donde TRANS es el número de transacciones de cada Caso de Uso. Esto permite disminuir la
granularidad y hacer una estimación más realista.
14
Estimación de Esfuerzo 2010
Para la implantación en una empresa, es crítico tener unas políticas muy claras para la
especificación de los casos de uso y para la determinación de los factores de ajuste tanto
técnicos como de ambiente.
Finalmente, es crítico llevar un histórico del esfuerzo (En Horas Hombre) realizado por punto
de caso de uso en proyectos anteriores. Generalmente esto depende mucho del equipo en
particular, pero se puede llevar el histórico para la organización en general, asumiendo que se
va a proporcionar un estimado medianamente cercano a la realidad.
15