Calculando Estimativas: o Método de Pontos de Caso de Uso1

Por Herval Freire (herval@cnnt.com.br)

Estimar o porte - e conseqüentemente, o custo de produção - de um sistema não é uma tarefa

fácil. Na grande maioria dos casos, as estimativas costumam ser lançadas sem qualquer preocupação com
uma medição formal, resultando em cronogramas imprecisos - e algumas vezes, desastrosos.
Formalismos criados para embasar os cronogramas de desenvolvimento e lançar de estimativas
de tempo e esforço foram desenvolvidos com o passar do tempo. Mecanismos populares, como a
estimativa por Pontos de Função, tornaram-se padrões de facto, e trazem resultados reais, já demonstrados
por diversos estudiosos no mundo todo.

Uma breve explicação sobre os Pontos de Função

A técnica de estimativa por Pontos de Função baseia-se na idéia de que um sistema pode ter seu
tamanho estimado de acordo com o número e complexidade dos requisitos funcionais que o compõem.
Para que a medida seja utilizada, cada parte do sistema deve ser decomposta em três partes - entrada
externas, saídas externas e consultas externas. Além destes objetos lógicos, cada função tem ainda seus
recursos de dados classificados como "arquivos lógicos internos" (tabelas e arquivos pertencentes ao
sistema) e "interfaces externas" (tabelas ou arquivos de outros sistemas, acessados pelas funções do
sistema em desenvolvimento). Para uma dada tela, é possível estimar um número de Pontos de Função
realizando um cálculo sobre a quantidade de arquivos lógicos (internos e externos) acessados, número de
entradas e saídas externas e número de consultas. Para ajustar o resultado obtido deste somatório, são
aplicados multiplicadores levantados a partir de uma série de outros requisitos não-funcionais - o que
inclui, por exemplo, questões relacionadas à segurança dos dados ou performance como um fator crítico.
Após somados todos os pontos não-ajustados e aplicada uma fórmula de ajuste, é obtido o valor final, em
Pontos de Função, para um dado elemento do sistema.
Apesar do bom resultado decorrente da aplicação da técnica de Pontos de Função, trata-se de um
mecanismo complexo, baseado em longas tabelas e cálculos de ajuste para se chegar a um denominador
de porte e custo do sistema. Somado a isto, a técnica exige que novos documentos para o cálculo das
estimativas sejam adicionados ao sistema, aumentando a pilha de papéis associados ao projeto – e que
necessitam de revisão a cada pequena mudança de orçamento, prazo ou requisitos.
O principal problema desta técnica de estimativa é que ela baseia-se em analisar os requisitos
que o sistema irá incorporar para determinar seu tamanho, em um nível que, na maioria dos casos, só é
perfeitamente estimável após realizado todo o levantamento de requisitos e terminada a construção dos
primeiros protótipos, ou mediante uma análise detalhada junto a um cliente que consiga entender o
sistema em um nível funcional, com alto nível de detalhes. Na maioria dos casos, esta não é a situação
real.

A Estimativa por Casos de Uso

A análise de sistemas Orientados a Objetos já utiliza, comumente, os diagramas de Casos de Uso
(Use Cases) para descrever as funcionalidades do sistema de acordo com a forma de utilização por parte
dos usuários. A técnica de análise de dimensão por Casos de Uso foi criada para permitir que seja
possível estimar o tamanho do sistema ainda na fase de levantamento de Casos de Uso, utilizando-se dos
próprios documentos gerados nesta fase de análise como subsídio para o cálculo dimensional.
A técnica de estimativa por Pontos de Caso de Uso foi proposta em 1993 por Gustav Karner, da
Objectory (hoje, Rational Software). Ela baseia-se em dois métodos bastante utilizados - o mecanismo de
Pontos de Função e uma metodologia conhecida como Mk II, uma adaptação da técnica de PFs, bastante
utilizada na Inglaterra. A forma de lançar uma estimativa é o principal diferencial da métrica por Casos de
Uso: o método trata de estimar o tamanho de um sistema de acordo com o modo como os usuários o
utilizarão, a complexidade de ações requerida por cada tipo de usuário e uma análise em alto nível dos
passos necessários para a realização de cada tarefa, em um nível muito mais abstrato que a técnica de
Pontos de Função.

Método de cálculo utilizando Pontos de Caso de Uso

Uma vez que os casos de uso principais do sistema sejam levantados, é possível estimar-se o
tamanho do software como um todo baseando-se em um conjunto simples de métricas e modificadores,
similar à técnica de Pontos de Função.
É importante frisar que o grau de detalhe dos Casos de Uso analisados influencia diretamente na
qualidade final da medição: deve haver a preocupação em medir somente casos de uso em nível de

1
Artigo publicado na revista Developer’s Magazine número 78, Fevereiro de 2003
sistema – onde seja possível diferenciar transações e interações com o usuário. Desta forma, casos de uso
de nível muito alto (business modelling do sistema) ou muito baixo (casos de uso atômicos, descrevendo
o sistema a nível de interações do usuário com a interface) não demonstram-se adequados para a medição.
Diversos artigos têm sido escritos, nos últimos anos, discutindo o nível de decomposição ideal dos casos
de uso para a aplicação da técnica. Esta é a principal falha da metodologia com relação à métrica por
Pontos de Função: na maioria dos casos, caberá aos analistas decidir a granularidade ideal dos Casos de
Uso utilizados para a medição.
Os passos necessários para a geração da estimativa são descritos a seguir.

1. Calculando o peso dos Atores do sistema

O primeiro passo no cálculo do sistema é classificar os atores envolvidos em cada caso de uso,
de forma a obter um somatório de pontos não-ajustado. A classificação de atores utiliza a tabela 1: o peso
total dos atores do sistema (Unadjusted Actor Weight, ou UAW) é calculado pela soma dos produtos do
número de atores de cada tipo pelo respectivo peso. Desta forma, um sistema projetado para dois tipos de
usuários (gerente e usuário comum) e que fosse acessado por um outro sistema utilizando-se de um
protocolo de comunicação, por exemplo, teria um valor de UAW de 8 (2 atores de nível “complexo” e 1
ator de nível “médio”).

Tipo de Ator Peso Descrição

Ator Simples 1 Outro sistema acessado através de uma API de programação
Ator Médio 2 Outro sistema interagindo através de um protocolo de comunicação, como
TCP/IP ou FTP
Ator Complexo 3 Um usuário interagindo através de uma interface gráfica (stand-alone ou
Web)
Tabela 1. Pesos de Atores

2. Calculando o Peso dos Casos de Uso

Uma vez calculado o peso dos atores do sistema, partimos para o cálculo inicial do peso bruto
dos casos de uso (Unadjusted Use Case Weight, ou UUCW). Para fins de cálculo, dividimos os casos de
uso em três níveis de complexidade, de acordo com o número de transações envolvidas em seu
processamento. Por transação, entende-se como uma série de processos que devem, garantidamente, ser
realizados em conjunto - ou cancelados em sua totalidade, caso não seja possível concluir o
processamento. A tabela 2 mostra o peso para cada um dos tipos de Caso de Uso classificados.

Tipo de Caso de Uso Número de Transações Peso

Simples Até 3 1
Médio 4a7 2
Complexo 7 ou mais 3
Tabela 2. Peso de Casos de Uso por numero de transações

O cálculo do UUCW é realizado como no cálculo de peso dos atores: somam-se os produtos da
quantidade de casos de uso classificados em cada tipo pelo peso nominal do tipo em questão.
Uma outra maneira de se calcular o peso dos casos de uso do sistema é levar em consideração o
número de classes envolvidas no processo, como mostrado na tabela 3. O cálculo, neste caso, é realizado
da mesma forma que na abordagem anterior, e pode ser aplicado quando já for possível antever as
entidades envolvidas em um dado processo.

Tipo de Caso de Uso Número de Entidades Peso

Simples 5 ou menos 1
Médio 5 a 10 2
Complexo Mais de 10 3
Tabela 3. Peso de Casos de Uso por número de entidades

Uma terceira forma, sugerida por Banerjee para substituir as duas técnicas citadas anteriormente,
utiliza uma regra de comparação simples. A regra é aplicada a cada Caso de Uso do sistema, e os valores
são somados para se obter o UUCW total. Esta fórmula é mais rápida e menos precisa que as duas outras
abordagens, mas apresenta resultados rapidamente:
 1. Se o caso de uso for considerado simples - isto é, conter uma interface com usuário simplificada
e utilizar apenas uma entidade em um banco de dados - caso de uso é considerado fácil e tem
peso 5.
2. Se o caso de uso envolve uma interface mais trabalhada e utiliza-se de duas ou mais entidades de
banco de dados, ele é definido como médio e recebe um peso 10.
3. Se o caso de uso envolver 3 ou mais entidades em um banco de dados e contiver uma interface
mais complexa, este recebe um peso de 15.

O peso total não ajustado (Unadjusted Use Case Points) é calculado pelo somatório entre os pesos de
atores e casos de uso:

UUCP = UAW + UUCW

3. Calculando Fatores de Ajuste

O método de ajuste é bastante similar ao adotado pela técnica de Pontos de Função, e é
constituído de duas partes - um cálculo de fatores técnicos, cobrindo uma série de requisitos funcionais do
sistema; e um cálculo de fatores de ambiente, requisitos não-funcionais associados ao processo de
desenvolvimento - tais como experiência da equipe, motivação e estabilidade do projeto. Estes dois
fatores geram multiplicadores distintos, que devem ser aplicados ao peso total não-ajustado (UUCP),
calculado anteriormente.
Os dois modificadores utilizam-se de um mesmo mecanismo de pesos: para cada requisito
listado em suas tabelas, deve ser atribuído um valor que determina a influência do requisito no sistema,
variando entre 0 e 5 - sendo que o valor 0 indica nenhuma influência, 3 indica influência moderada e 5
indica forte influência.

3.1. Fatores Técnicos

Para calcular o fator de complexidade técnica do sistema (seu Technical Complexity Factor, ou
TCF), utilizamos a tabela 4.

Fator Requisito Peso

T1 Sistema distribuído 2
T2 Tempo de Resposta 2
T3 Eficiência 1
T4 Processamento complexo 1
T5 Código reusável 1
T6 Facilidade de instalação 0.5
T7 Facilidade de uso 0.5
T8 Portabilidade 2
T9 Facilidade de mudança 1
T10 Concorrência 1
T11 Recursos de segurança 1
T12 Acessível por terceiros 1
T13 Requer treinamento especial 1
Tabela 4. Peso de Fatores Técnicos

O cálculo do TCF é feito pela seguinte fórmula:

TCF = 0.6 + (0.01 x TFactor)

O valor TFactor é obtido pelo somatório dos níveis de influência atribuídos a cada fator (T1 a
T13) multiplicados pelo seu peso correspondente.

3.2. Fatores Ambientais

A tabela 5 mostra os fatores ambientais previstos pela metodologia de Pontos de Caso de Uso e
seus pesos associados.

Fator Descrição Peso

E1 Familiaridade com RUP ou outro processo formal 1.5
 E2 Experiência com a Aplicação em desenvolvimento 0.5
E3 Experiência em Orientação a Objetos 1
E4 Presença de analista experiente 0.5
E5 Motivação 1
E6 Requisitos estáveis 2
E7 Desenvolvedores em meio-expediente -1
E8 Linguagem de programação difícil 2
Tabela 5. Pesos de Fatores Ambientais

No caso dos Fatores Ambientais, o nível de influência indica o nível de disponibilidade de cada
recurso no decorrer do projeto: desta forma, determinar que um dado fator tem nível de influência alta
(isto é, atribuir a ele o valor 5) significa dizer que este fator está presente no projeto como um todo e
influencia seu desenvolvimento. Da mesma forma, atribuir um valor de influência zero (nenhuma
influência) a um fator indica que o mesmo não está presente no processo de desenvolvimento.
A título de ilustração podemos dizer que, um grau de influência mínimo (0) atribuído ao fator E3
indica uma equipe com total desconhecimento de Orientação a Objetos - enquanto que o grau máximo (5)
indica a disponibilidade de uma equipe experiente neste paradigma de desenvolvimento.

O fator ambiental (EF) é calculado pela seguinte fórmula:

EF = 1.4 + (-0.03 x EFactor)

Onde o valor de EFactor é dado pela soma dos produtos entre o peso de cada fator (E1 a E8) e
seu grau de influência atribuído, como no cálculo da variável TFactor, abordada anteriormente.
Note que a maioria dos fatores ambientais tendem a diminuir o valor em Pontos de Caso de Uso
do sistema: isto reflete o ganho de velocidade proporcionado pelos diversos fatores ambientais descritos
na tabela, quando os mesmos encontram-se disponíveis.

4. Calculando o Porte do Sistema

Finalmente, podemos calcular o valor total do sistema em Use Case Points (UCP) utilizando-se
da seguinte fórmula:
UCP = UUCP x TCF x EF

Segundo Karner, podemos estimar o tempo necessário para o desenvolvimento do projeto

calculando-se uma média de 20 horas de trabalho por Ponto de Caso de Uso (UCP), sendo que
experiências demonstram uma variação entre 15 e 30 horas por ponto.
Schneider e Winters sugerem um refinamento na técnica de Karner: a técnica sugere que a
presença de certos atributos influencia diretamente a média de horas por ponto calculado, utilizando a
seguinte lógica:
1. Conta-se a quantidade de fatores técnicos entre T1 e T6 que receberam nível de influência maior
que 3;
2. Soma-se o valor obtido à quantidade de fatores ambientais entre E7 e E8 que receberam valor de
influência menor que 3.

O somatório indica a quantidade sugerida de horas por ponto de caso de uso a ser adotada no projeto,
sendo a média sugerida de:

• 20 horas por ponto para um resultado de 2 ou menor;

• 28 horas por ponto caso o somatório resulte em 3 ou 4;
• 36 horas por ponto para valores maiores que 4.

Neste último caso, os autores da técnica sugerem que o projeto seja revisto: talvez haja a necessidade
de treinamento de pessoal, adequação de tecnologia ou revisão de requisitos, para garantir um melhor
aproveitamento de recursos e redução no cronograma previsto.

Conclusões
Uma vantagem evidente da métrica por Casos de Uso sobre a técnica de Pontos de Função é que ela
demonstra resultados muito mais cedo, no ciclo de desenvolvimento. Além disso, a técnica utiliza-se de
um tipo de documento essencial em metodologias dirigidas por caso de uso (Use Case Driven), como o
RUP, de forma que é possível calcular prontamente mudanças nas estimativas do sistema a cada pequena
alteração de requisitos, apenas refazendo alguns cálculos. Apesar dos ganhos, a técnica apresenta
problemas evidentes – como as diferenças visíveis de estimativa lançadas por analistas diferentes,
baseando-se na visão pessoal de cada um quanto ao nível de granularidade dos Casos de Uso analisados.
De uma forma ou de outra, a metodologia de medição por Pontos de Caso de Uso é uma técnica
interessante para equipes que carecem de uma métrica formal de lançamento de estimativas ou que não
conseguiram bons resultados utilizando-se de outros mecanismos de estimativa. Sem dúvida, vale a pena
tentar.

Referências
Karner, G. Metrics for Objectory. Diploma thesis, University of Linköping, Suécia. Dezembro, 1993.

Karner, G. Resource Estimation for Objectory Projects. Objectory Systems, 1993.

Smith, John. The Estimation of Effort Based on Use Cases. Rational Software. Cupertino, Outubro,
1999.

Schneider, Geri, Winters, Jason. Applying Use Cases: A Practical Guide, 2/e, Addison Wesley
Professional, 2001.

Banerjee, Gautam. Use Case Points - An Estimation Approach, 2001.

Longstreet, David. Use Cases and Function Points, 2001.