PDF de programación - Estimación de proyectos de software con puntos de casos de uso

ESTIMACIÓN DE PROYECTOS DE SOFTWARE CON PUNTOS

DE CASOS DE USO

Valero Orea, Sergio*


RESUMEN

Uno de los principales problemas a los que nos enfrentamos los desarrolladores de
software al momento de planear nuestros proyectos es la estimación. Existen distintas
técnicas que nos permiten estimar proyectos de software, cada una de ellas con sus
ventajas y desventajas, pero la mayoría de ellas no ofrecen la flexibilidad de estimar
software orientado a objetos, y se basan prácticamente en la experiencia del equipo de
desarrollo. La técnica de estimación con puntos de caso de uso nos permite realizar
estimaciones a partir de modelos orientados a objetos con una precisión bastante
aceptable.

INTRODUCCIÓN

El proceso de gestión de proyectos de software comienza con un conjunto de
actividades que se denominan planificación del proyecto. La primera de estas
actividades es la estimación [1]. Estimar, o cuantificar, software no es una tarea fácil.
Las metodologías de desarrollo de sistemas han evolucionado, desde los antiguos
sistemas por lotes, la programación estructurada, hasta la orientación a objetos, pero las
técnicas de estimación no lo han hecho. Por un lado, se conocen algunas técnicas como
COCOMO, Puntos de Función y otras, pero la mayoría de ellas se basan en criterios
muy poco efectivos de aplicar como líneas de código, experiencia previa sobre sistemas
similares, etc. De esta forma, hemos podido notar un cambio en las metodologías para el
desarrollo de software y de la misma manera, existen técnicas adecuadas que nos
permiten realizar estimaciones, como la técnica de puntos de casos de uso, la cual se
basa en metodologías orientadas a objetos, específicamente en el modelo de casos de
uso. Este trabajo se enfoca en la descripción de esta técnica, la cual es muy fácil de
comprender y su aplicación no es muy difícil de llevar a cabo como podremos ver a
continuación.

DESARROLLO

Históricamente, los egresados de las Universidades, los profesionales de TI, las
empresas, y todo aquel que le han pedido cuantificar los costos y los tiempos estimados
de desarrollo de un proyecto de software han sido víctimas de una lucha para la cual no
han sido preparados. En las Universidades se les prepara a los futuros profesionistas a
programar, modelar, pero muy pocas veces a planificar. La planificación de proyectos
es una tarea esencial para poder hacer cuantificaciones y las estimaciones adecuadas.

Hoy en día, los desarrolladores de software frecuentemente se apoyan de los casos de
uso para describir procesos de negocio en proyectos orientados a objetos [2]. En el

*Universidad Tecnológica de Izúcar de Matamoros



análisis orientado a objetos, los modelos de casos de uso describen los requerimientos
funcionales de un sistema de software.

Modelo de casos de uso

El modelo de casos de uso es un artefacto que surge como producto de la fase de
requerimientos de la metodología de desarrollo y gestión de proyectos llamada Proceso
Unificado de Rational (RUP, por sus siglas en inglés). Dicha metodología, propone una
serie de prácticas para el desarrollo de proyectos de software basado en fases, a través
de una serie de disciplinas que nos permitirán ir generando artefactos en cada una de las
iteraciones. Esta metodología es cíclica, es decir, por cada ciclo se generan documentos
entregables (artefactos) que nos permitirán medir el avance de nuestros proyectos,
inclusive desde las etapas iniciales.

El modelo de casos de uso es una amplia y aceptada técnica que captura el proceso de
negocio y los requerimientos de un proyecto de desarrollo de software. Esta es la base
para las estimaciones, ya que contiene la especificación detallada de los actores y casos
de uso.


Técnicas de estimación

La estimación del costo y del esfuerzo del software nunca será una ciencia exacta. Son
demasiadas variables -humanas, técnicas, de entorno, políticas- que pueden afectar el
costo final del software y del esfuerzo aplicado para desarrollarlo. Sin embargo, la
estimación del proyecto de software puede dejar de ser un arte obscuro para convertirse
en una serie de pasos sistemáticos que proporcionen estimaciones con un grado de
riesgo aceptable [1].

Existen distintas técnicas de estimación, de las cuales podemos mencionar brevemente
al modelo COCOMO, los puntos de función, y por supuesto, los puntos de casos de uso.
Cada una de ellas presenta una serie de ventajas y desventajas, pero su discusión está
fuera del alcance de este trabajo y nos enfocaremos a estudiar principalmente los puntos
de casos de uso.


Puntos de 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.






El objetivo de la técnica

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.

Al inicio, el método depende de casos de uso bien estructurados y bien escritos, con un
nivel conveniente de detalle textual. Al final, se pretende obtener un número único que
caracterice completamente al sistema y que se correlacione con la productividad
observada del ingeniero.


Tabla 1. VENTAJAS Y DESVENTAJAS DE LA TÉCNICA DE PUNTOS DE CASOS DE USO
Ventajas
Trabaja bien con diferentes tipos de software

Desventajas
No existe un estándar para escribir casos de uso
lo que dificulta la aplicación del método.
Las herramientas en esta área son caras y se
enfocan en la evaluación del proyecto

Muestra buen rendimiento en proyectos
pequeños, medianos y grandes.


Vale la pena aclarar que un caso de uso por sí solo no permite efectuar una estimación
de esfuerzos ni de tiempos, solamente son una herramienta para el análisis. La idea
central es estimar el tamaño (cuantificar) del software a partir de los requerimientos de
los casos de uso.



Fig. 1. Pasos para el desarrollo de la técnica de puntos de casos de uso





Desarrollo de la técnica de puntos de casos de uso

Como se puede apreciar en la figura 2, el proceso de desarrollo de la técnica de puntos
de casos de uso esta formulado por 3 pasos bien definidos, los cuales se describen a
continuación.

1. Calcular los puntos de casos de uso no ajustados (UUCP). Para lo cual, hay que
definir un peso tanto para actores (AUW) como para casos de uso (UUCW) y
sumar el resultado de esos pesos.


a. Para determinar el peso de los actores, nos vamos a apoyar de la

siguiente tabla para determinar el tipo de actor:


Tabla 2. PESO DE LOS ACTORES
Tipo de actor
Simple
Medio

Complejo

Descripción
Otro sistema con una API definida
Otro sistema interactuando con algún protocolo
(TCP) o una persona interactuando a través de
una interfaz en modo texto
Una persona interactuando a través de una
interfaz gráfica de usuario

Factor

1
2

3


Finalmente, hay que contar el número de actores que hay en el sistema,
multiplicar cada tipo por su factor de peso y sumar esos productos para
obtener el total (AUW).

b. Para determinar el peso de los casos de uso, nos apoyaremos de la

siguiente tabla para determinar el tipo de caso de uso:

Tabla 3. PESO DE LOS CASOS DE USO
Tipo de caso de uso
Simple
Medio
Complejo

De la misma forma que con los actores, hay que contar el número de
casos de uso que hay en el sistema, determinar su factor, multiplicar cada
tipo por su factor de peso y sumar esos productos para obtener el total
(UUCW).

Descripción
3 transacciones o menos
4 a 7 transacciones
Más de 7 transacciones

Factor

5
10
15



2. Calcular los puntos de casos de uso (UCP). Para lo cual, hay que realizar el
producto del peso de los puntos de casos de uso no ajustados (UUCP), el peso de
los factores técnicos (TCF) y el peso de los factores ambientales (EF).


a. Para determinar el peso de los factores técnicos, nos apoyaremos de la
siguiente tabla, la cual nos indica aspectos relacionados con la
complejidad de los módulos a desarrollar:

Tabla 4. FACTORES TÉCNICOS

Factor

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

Descripción
Sistema distribuido
Objetivos de performance o tiempo de respuesta
Eficiencia del usuario final
Procesamiento interno complejo
El código debe ser reutilizable
Facilidad de instalación
Facilidad de uso
Portabilidad
Facilidad de cambio
Concurrencia
Objetivos especiales de seguridad
Acceso directo a terceras partes
Facilidades especiales de entrenamiento a usuarios

Peso

2
1
1
1
1
0.5
0.5
2
1
1
1
1
1


Para pesar los factores técnicos (TCF), hay que recorrer la siguiente tabla
y estimar cada factor entre cero y cinco (0 y 5), donde



Tabla 5. ESCALAS DE ESTIMACION TCF
Descripción
Irrelevante
Medio
Esencial

De 0 a 2
De 3 a 4

Valor

5


Posteriormente, hay