Estimación de software basada en puntos de casos de uso. Ejemplo práctico

Resumen

Aunque la estimación es más un arte que una
ciencia no es aconsejable embarcarse sin ella. En el mundo actual
de la informática y las comunicaciones muchos proyectos
fracasan por no llevar a cabo de manera correcta esta actividad.
Para un proyecto de software es necesario conocer el esfuerzo y
el costo que tiene implicado. Para ello son muchos los
métodos de estimación que existen en la actualidad:
SLIM, COCOMO II, Juicio Experto, Analogía, algunos basados
en técnicas estadísticas e Inteligencia Artificial
que se basan en datos históricos para inferir el esfuerzo
de nuevos proyectos. Algunos de los métodos antes
mencionados se basan en paradigmas de programación
antiguos. Por la importancia del paradigma Orientado a Objetos y
la metodología RUP, este trabajo se encarga de describir
el método de estimación basado en Puntos de Casos
de Uso a través de un caso práctico, un sistema Web
para la gestión de la actividad telefónica en un
Centro de Educación Superior, y mostrar las ventajas y
desventajas del mismo.

Introducción

Aunque la estimación es más un arte que una
ciencia, es una actividad importante que no debe llevarse a cabo
de forma descuidada. Existen técnicas útiles para
la estimación de costes y de tiempos. Y dado que la
estimación es la base de todas las demás
actividades de planificación del proyecto y sirve como una
guía para una buena ingeniería del software, no es
en absoluto aconsejable embarcarse sin ella. [1]

El objetivo de la Estimación es predecir las variables
involucradas en el proyecto con cierto grado de certeza. Se trata
de aportar una predicción de algún indicador
importante para la gestión de proyectos de software:
tiempo, esfuerzo, cantidad de defectos esperados, entre otros,
sin dejar de tener en cuenta que la incertidumbre y el riesgo son
elementos inherentes.

En la actualidad son muchos los proyectos que fracasan e
incumplen sus plazos de entrega. Según el The Standish
Group en su publicación Chaos Report 2009,
determinó que el 24% de los proyectos informáticos
fueron cancelados, solo el 32 % terminaron a tiempo y dentro del
presupuesto y el 44% de los proyectos de software fueron
concluidos después de la fecha estimada.

Son muchos los métodos de estimación del
esfuerzo que existen en la actualidad: SLIM, COCOMO II, Juicio
Experto, Analogía, algunos basados en técnicas
estadísticas e Inteligencia Artificial que se basan en
datos históricos para inferir el esfuerzo de nuevos
proyectos.

El objetivo de este trabajo es describir el método de
estimación basado en Puntos de Casos de Uso a
través de un caso práctico y mostrar las ventajas y
desventajas del mismo.

El método escogido se acopla con la metodología
más usada hasta nuestros días, la
metodología RUP (Proceso Unificado de Rational), esta
metodología se basa en la identificación de los
casos de uso, encargados de dirigir el proceso y la
técnica escogida toma como punto de partida estos
elementos.

DESARROLLO

Planificación
basada en casos de uso

Este método de estimación de proyectos de
software fue desarrollado en 1993 por Gustav Karner de Rational
Software y está basado en una metodología orientada
a objetos, dándole el nombre de "estimación de
esfuerzos con casos de uso". Surgió como una mejora al
método de puntos de función pero basando las
estimaciones en el modelo de casos de uso, producto del
análisis de requerimientos. Según su autor, la
funcionalidad vista por el usuario (modelo de casos de uso) es la
base para estimar el tamaño del software. [2]

Un caso de uso por sí solo no permite efectuar una
estimación de esfuerzos ni de tiempos, los casos de uso
son solamente herramientas para el análisis. La idea
fundamental es predecir el tamaño del software a partir de
los requerimientos de los casos de uso.

El objetivo fundamental de esta técnica es: Estimar las
horas necesarias para ejecutar un conjunto de casos de uso. Es
decir, necesitamos predecir cuánto tiempo llevará
el desarrollo de software y cuántas personas se requieren
para realizarlo. Para ello, es necesario cuantificar la
complejidad del sistema y el tiempo necesario para producir una
unidad de complejidad.

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 descripción. Aplicando el
Análisis de Puntos de Función a estos Casos de Uso,
se podrá obtener una estimación grosera del
tamaño y a partir de ella del esfuerzo. Esta
estimación es bastante imprecisa debido principalmente a
la escasa información 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
más.

El ejemplo práctico a través del cual se
describirá el método consiste en una
aplicación Web para la gestión de
información telefónica, de reportes de
averías, y de estadísticas de los estados de los
teléfonos de un Centro de Educación Superior (CES).
Actualmente este proceso se realiza manualmente, provocando
dificultades en la organización y control de la
información referente a los equipos telefónicos y a
sus respectivos usuarios. La aplicación es desarrollada en
la plataforma .Net, con lenguaje C#. A continuación se
presentan los actores y casos de uso identificados.

Cálculo de Puntos de Casos de Uso sin Ajustar
(UUCP)

Para la estimación el primer paso que se lleva a
cabo es el cálculo de los Puntos de Casos de Uso sin
ajustar. Este valor se calcula a partir de la siguiente
ecuación:

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

Determinación del factor de peso de los
actores sin ajustar (UAW).

Este valor se calcula mediante un análisis 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 que el actor
interactúa con el sistema .

Factores de peso de los actores.

UAW = 9

Determinación del factor de peso en los
casos de uso sin ajustar (UUCW).

Este valor se calcula mediante un análisis 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
establecen teniendo en cuenta la cantidad de transacciones
efectuadas en el mismo, donde una transacción se entiende
como una secuencia de actividades atómicas.

Factores de peso de los casos de uso.

UUCW = 160

Calculando

UUCP = UAW + UUCW

UUCP = 9 + 160

UUCP = 169

5.2.2 Cálculo de Puntos de Casos de Uso
ajustados

Seguidamente de calcular los Puntos de Casos de Uso sin
ajustar, se debe ajustar este valor mediante la siguiente
ecuación:

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 técnica

EF: Factor de ambiente

5.2.2.1 Determinación del factor de
complejidad técnica (TCF)

Este coeficiente se calcula mediante la
cuantificación de un conjunto de factores que determinan
la complejidad técnica 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.
[21]

Tabla 17. Factores de complejidad técnica.

El Factor de complejidad técnica se calcula
mediante la siguiente ecuación:

Determinación del factor 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
cálculo del Factor de ambiente.

Factores de ambiente.

El factor de ambiente se calcula mediante la siguiente
ecuación:

Cálculo de los Puntos de de Casos de Uso
Ajustados:

UCP = UUCP * TCF * EF

UCP = 169 * 1.02 * 0.74

UCP = 127.56

5.2.3 Cálculo del esfuerzo

El esfuerzo en horas-hombre viene dado por:

E = UCP * CF donde:

E: esfuerzo estimado en horas-hombre.

UCP: Puntos de casos de uso ajustados.

CF: Factor de conversión (20 horas-hombre por
defecto).

E = 127.56 * 20

E = 2551.2 Horas-hombres

Se debe tener en cuenta que éste método
proporciona una estimación del esfuerzo en horas-hombre
contemplando sólo el desarrollo de la funcionalidad
especificada en los casos de uso.

Para la obtención de una estimación
más exacta de la duración del proyecto, se hace
necesario agregar a la estimación del esfuerzo obtenida
por los Puntos de Casos de Uso, las estimaciones de esfuerzo de
las restantes actividades que se llevaron a cabo durante el
desarrollo del software; así se la distribución del
esfuerzo entre dichas actividades está dada por la
siguiente aproximación:

Distribución genérica del esfuerzo.

Con este criterio y tomando como entrada la
estimación de tiempo calculada a partir de los Puntos de
Casos de Uso, se pueden calcular las demás estimaciones
para obtener la duración total del proyecto.

Distribución real del esfuerzo.

Cálculo del esfuerzo total:

ETotal = 6378 horas /hombre

Cálculo del tiempo de desarrollo:

TDesarrollo = ETotal/CHTotal CHTotal: Cantidad de
hombres

TDesarrollo = 6378/2

TDesarrollo = 3189 horas

Considerando que se trabajan 8 horas diarias:

TDesarrollo = TDesarrollo/8 horas/día

TDesarrollo = 3189 horas/8 horas/día

TDesarrollo = 399 días aproximadamente

Cálculo del costo:

CostoTotal = ETotal * 2 * TH TH: Tarifa horaria(=
1.031)

CostoTotal = 6378 * 2 * 1.031

CostoTotal = 13151.45

Considerando los resultados arrojados respecto a la
factibilidad del software después del estudio realizado en
este capítulo, se concluye que brinda suficientes
beneficios para cubrir sus costos, o sea, que se aconseja la
realización del sistema en el CES, ya que es factible y
económico; el mismo implicará un esfuerzo total de
6378 horas /hombre, para un tiempo de desarrollo de 399
días aproximadamente, se contarán con 2 hombres
para su realización, lo que implica un costo de $13151.45
para una tarifa horaria de $1.031.

Entre las cosas buenas del método se puede citar
que trabaja bien con diferentes tipos de software, siempre que
sigan un paradigma orientado a objetos, muestra buen rendimiento
en proyectos pequeños, medianos y grandes. Es una nueva
métrica que se adapta mejor a paradigmas más
avanzados de programación e Ingeniería de Software.
El método no está exento de problemas que hacen que
no se haya consolidado, entre estos problemas destacan la no
existencia de un estándar para describir casos de uso, eso
hace que aplicar la métrica sea más engorroso, hay
un alto grado de subjetividad a la hora de calcular los factores
técnicos y ambientales que hacen que el cálculo no
sea del todo realista. Se puede observar que entre los autores
que han usado los UCP no se distingue un criterio único
aplicado para el cálculo de la complejidad de un caso de
uso: por ejemplo, Anda (Anda et al., 2005) y Diev (Diev, 2006) no
tienen en cuenta los objetos de análisis. Además,
también existen diferentes criterios para identificar una
transacción. Unos definen la transacción como un
conjunto atómico de actividades entre el actor y el
sistema, que debe ser realizado en forma completa (Anda et al.,
2001; Anda et al., 2002; Anda et al., 2005; Carroll, 2005; Diev,
2006). Otros claramente definen las diferencias entre
transacciones y escenarios (Diev, 2006), mientras otros no hacen
ninguna diferencia entre ellos (Anda et al. 2005). Hay otro que
define el número de transacciones como el número de
transacciones dentro de los escenarios de un caso de uso (Issa,
2006).

Conclusiones

En el presente artículo se ha descrito el método
de estimación por puntos de casos de uso, a través
del caso práctico de una aplicación Web
diseñada e implementada para un centro de educación
superior. Se arribaron a conclusiones acerca de la viabilidad del
proyecto usando dicho método. Por otra parte se
desprendieron algunas de las ventajas y desventajas que presentan
los puntos de casos de uso

La estimación 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
aproximación iterativa como el Proceso Unificado de
Rational. En éste tipo de aproximación, 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 más significativos
(iteraciones de Elaboración en el Proceso Unificado).
Fuera de éste contexto, el método tiende a
sobredimensionar el esfuerzo requerido.

Bibliografía

[1] Roger S. Pressman. (1998).
Ingeniería del software, un enfoque
práctico, España, Ed. McGraw-Hill.

[2]Valero Orea, Sergio .ESTIMACIÓN DE PROYECTOS DE
SOFTWARE CON PUNTOS DE CASOS DE USO.

Roy K. Clemmons. (2006). Project
estimation with Use Case Points. EEUU, Crosstalk: The
Journal of Defense Software Engineering.

Reportes Técnicos en Ingeniería de Software Vol.
6 N° 1 (2004), pág. 1-16. ESTIMACIÓN DEL
ESFUERZO BASADA EN CASOS DE USO. Mario Peralta

Autor:

Lianny O'Farrill Fernández