Estimativa de Projetos com Base em Casos de Uso

Edson Saraiva de Almeida1,3, Gilberto José da Cunha 2,3

1
Mestre em Engenharia de Computação pelo IPT, Faculdade Senac de Ciências Exatas e Tecnologia,
Universidade São Judas Tadeu, São Paulo - Brazil.
2
Doutorando do
Departamento de Engenharia de Computação e Sistemas Digitais/Laboratório de Automação Agrícola -
Escola Politécnica - Universidade de São Paulo, São Paulo – Brazil
3
Scopus Tecnologia SA
Av. Mutinga, 4105, São Paulo – SP - Brazil

ealmeida@scopus.com.br, gcunha@scopus.com.br

Abstract. This paper describes an Use Case based process estimation method
for software sizing and development efforts, details its application in a real life
project comparing the estimation results with the real ones achieved by the
project.

Resumo. Este artigo apresenta um método de estimativa de esforço de

desenvolvimento de projeto de software baseado em pontos de Casos de Uso e
sua aplicação num projeto piloto, comparando a estimativa obtida pela
aplicação do método com o resultado real do desenvolvimento do projeto.

1. Introdução
As pesquisas e atividades na área de métrica de software, medida da complexidade e do
esforço necessário para desenvolvimento, têm sido estudadas há mais de trinta anos.
Esse esforço é motivado pelos custos crescentes de desenvolvimento e manutenção do
software, exigindo a criação de procedimentos com rigor científico, que definam
técnicas de medida e que possam ser aplicados ao estudo da atividade de
desenvolvimento de software [Zuze, 1995].
Os benefícios práticos da utilização de técnicas de métrica de software foram
definidos, de forma clara e precisa, por Robert Grady em 1992 [Grady, 1992 apud Zuze,
1995] como uma ajuda na correta tomada de decisões, fornecendo:
1. Base para estimativas;
2. Forma para acompanhar o progresso dos projetos;
3. Forma de determinar a sua complexidade;
4. Indicação de quando conseguimos alcançar o grau de qualidade desejado;
Validar experimentalmente boas práticas
Estimativas de custo e cronograma em projetos de software são baseadas em
uma previsão do tamanho do sistema a ser desenvolvido para determinar o nível
apropriado de esforço que deverá ser alocado. De acordo com o relatório Chaos do
Standish Group [Johson, 1995], somente 26% de todos os projetos de desenvolvimento
de software terminam com sucesso e 74% terminam com graus variados de problemas.
Segundo o ISBSG [Hill, 2001] projetos que utilizam um processo formal de
estimativa dobram as chances de sucesso quando comparados com os que utilizam
métodos informais.
O objetivo deste trabalho é apresentar um processo para estimar o esforço a ser
alocado em projetos de desenvolvimento de software utilizando Casos de Uso como
base para essa previsão.

Os métodos tradicionais de métrica de software podem fornecer estimativas

preliminares do esforço necessário para o desenvolvimento, porém com muitos
elementos de insegurança devido à falta de informações detalhadas no estágio inicial de
especificação.
Casos de Uso podem ser utilizados para melhorar o entendimento dos requisitos
do sistema com objetivo de descrever o comportamento desejado. Os Casos de Uso são
escritos (modelados) e discutidos com o cliente antes de se iniciar o desenvolvimento do
software.
A modelagem dos Casos de Uso pode, então, ser utilizada para estimar o
tamanho do software num estágio inicial de desenvolvimento [Banerjee, 2001],
diminuindo o nível de insegurança nesta fase da especificação.
Deve ser observado que o estilo de descrição do Caso de Uso e seu detalhamento
tem influência direta no entendimento da sua complexidade e, portanto, no cálculo de
uma métrica baseada no seu entendimento [Smith, 2001].
O método apresentado não é novo, é de utilização menos complexa do que a
técnica tradicional de pontos de função, embora ainda não seja popular.
Por ser baseado nos Casos de Uso tem aplicabilidade direta como métrica para
desenvolvimento orientado a objeto visto que as metodologias de orientação a objeto
preconizam a especificação inicial dos Casos de Uso.
O estudo que apresentaremos foi iniciado em uma organização com cerca de 100
funcionários envolvidos na atividade de desenvolvimento de software. O esforço de
programação nesta empresa está direcionado para soluções baseadas no ambiente Web -
e-commerce para bancos e instituições financeiras. Existem pilotos para
desenvolvimento de software seguindo a metodologia RUP, ainda sem um processo
metodológico de suporte para apoiar as necessidades de estimativas de prazo e esforço.
Uma iniciativa interna sugeriu a análise das técnicas de estimativa utilizando pontos de
casos de uso como objetivo de melhoria do processo de desenvolvimento de software.
Este trabalho descreve a aplicação da técnica em um projeto piloto como base
para estudo e direcionamento futuro na organização.

2. Processo de Estimativa utilizando Casos de Uso

Existem muitas técnicas de estimativas, cada técnica possui aspectos favoráveis e
fragilidades. Em 1993 Gustav Karner [Karner, 1993] da Objectory AB apresentou uma
pesquisa para estimativa de projetos utilizando-se de Casos de Uso. Seu trabalho estava
baseado na técnica de Pontos de Função, que foi proposta em 1979 por A. J. Albrecht,
então pesquisador da IBM [SPR, 2002].
A modelagem de Casos de Uso é uma técnica amplamente utilizada para
capturar e descrever os requisitos funcionais de um sistema, sendo a base da
metodologia RUP [Probasco, 2001]e de diversos outros métodos de desenvolvimento
orientado a objetos.
A técnica de estimativa por Pontos de Casos de Uso surgiu como a mais
interessante neste caso exatamente pelo fato da empresa estar se voltando ao
desenvolvimento de software orientado a objetos.
A primeira vantagem dessa técnica é o fato de que necessariamente teríamos os
Casos de Uso descritos e consensados antes do início do projeto.

2.1. Relevância dos Atores

A abordagem de Karner [Karner, 1993] inicia considerando o peso dos atores no Caso
de Uso. Os atores são classificados como simples, médio e complexo:
a) Atores simples - são os sistemas externos, como interface com sistemas
contábeis ou sistemas de cartões de créditos. Este tipo de ator tem uma
interface bem definida e possui uma reação previsível de entrada ou saída.
b) Atores médios - são os dispositivos de hardware. Apesar de também
possuírem uma interface bem previsível requerem mais esforço para controlar
e são geralmente mais propensos a erros.
c) Atores complexos - são as interações humanas. Este tipo de ator é mais difícil
de controlar e é totalmente imprevisível.
A Tabela 1 é usada como referência para determinar os fatores de peso para
atores.
Tabela 1. Fatores de peso para Atores
Tipo do Ator Descrição Fator
Simples Sistemas Externos 1
Médio Hardware 2
Complexo Interação Humana 3

2.2. Relevância dos Casos de Uso

Uma característica básica do Caso de Uso é o número de caminhos que ele executa.
Esse número define o fator de peso do Caso de Uso, conforme Tabela 2. Os
caminhos são determinados por cenários de sucesso, cenários de insucesso e
alternativos. Karner [Karner, 1993] sugere não considerar extensão, generalização e
inclusão de casos de uso.
Tabela 2. Fatores de peso para Casos de Uso
Tipo de Caso de Uso Descrição Fator
Simples 3 caminhos ou menos 5
Médio De 4 a 7 caminhos 10
Complexo Mais de 7 caminhos 15
 A somatória da complexidade dos atores e do peso dos Casos de Uso permite
calcular os Pontos de Casos de Uso não Ajustados.

2.3. Relevância de fatores técnicos: Complexidade e Nível de Experiência da

Equipe
O próximo passo no processo de estimativa é considerar os fatores técnicos (FT) do
projeto. Estes fatores estão relacionados com a complexidade do projeto e o nível de
experiência dos profissionais envolvidos.
Para calcular os fatores técnicos utiliza-se a Tabela 3 como referência atribuindo,
a cada fator técnico, um valor entre 0 e 5. Um valor igual a 0 significa que o fator
técnico é irrelevante para este projeto, um valor igual a 5 significa que ele é essencial.
Em seguida multiplica-se cada fator pelo peso da Tabela 3.
Tabela 3. Fatores Técnicos para Casos de Uso
Ref. Descrição Peso
T1 Sistemas distribuídos 2
T2 Objetivos de desempenho e tempo de resposta 1
T3 Eficiência do usuário final (on-line) 1
T4 Complexidade interna de processamento 1
T5 Código deve ser reutilizado 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 Inclui características especiais de segurança 1
T12 Oferece acesso direto para terceiros 1
T13 Requer treinamento especial dos usuários 1

Ao término da atribuição de valores aos fatores técnicos calcula-se a soma total.

O Fator de Complexidade Técnica é obtido com base na seguinte equação:
FCT = 0.6 + (0.01 * FT).
Em seguida deve ser considerado o nível de experiência dos profissionais
envolvidos no projeto. Esse nível é chamado de fator ambiental (FA). Para calcular o
fator ambiental, usa-se a Tabela 4 como referência e uma taxa para cada fator variando
entre 0 e 5. Para os fatores F1 a F4, 0 significa nenhuma experiência no assunto, 5
significa experiência de especialista e 3 significa uma experiência média. Para o fator
F5, 0 significa sem motivação para o projeto, 5 significa altamente motivado, 3 significa
média motivação. Para F7, 0 significa nenhum trabalhador em tempo parcial
participando do projeto, 5 significa que a equipe inteira está em tempo parcial, 3
significa média (equipe mista).
Os fatores F6 e F8 não dizem respeito à experiência dos profissionais, mas a
fatores ambientais intrínsecos ao sistema que será desenvolvido. Para F6, 0 significa
requisitos do sistema extremamente instáveis, 5 significa requisitos estáveis, 3 significa
instabilidade média de requisitos. Para F8, 0 significa linguagem de programação fácil,
5 significa uma linguagem de programação difícil, 3 significa uma linguagem com
dificuldade média.
 Tabela 4. Fator da Complexidade Ambiental
Ref. Descrição Peso
F1 Uso de um processo formal de desenvolvimento de software 1,5
F2 Experiência na aplicação 0,5
F3 Experiência em OO 1
F4 Capacidade do líder analista 0,5
F5 Motivação 1
F6 Estabilidade de requisitos 2
F7 Número de trabalhadores em tempo parcial -1
F8 Dificuldade da linguagem de programação -1

Ao término da atribuição de valores aos fatores ambientais calcula-se a soma

total. O Fator de Complexidade Ambiental é obtido com base na seguinte equação:
FCA = 1,4 + (- 0.03 * FA)

2.4. Cálculo dos Pontos de Casos de Uso

Finalmente, o total de pontos de Casos de Uso é calculado com base na seguinte
formula:
Pontos de Casos de Uso = Pontos de Casos de Uso não Ajustados * FCT * FCA.

3. Estudo de Caso – EDI

O EDI é um aplicativo que tem por finalidade a troca de informações efetuada através
da transferência de arquivos. Esta transferência pode ser feita entre as estações clientes
instaladas nas empresas e a organização receptora.
Este aplicativo utiliza o conceito de caixa postal, ou seja, para a organização
receptora e cada empresa que utiliza esta aplicação é definida uma caixa postal no
servidor, onde os arquivos a serem transferidos são armazenados. Sempre que uma
empresa transfere um arquivo, este é armazenado na caixa postal do destinatário na
organização receptora. Para o recebimento dos arquivos, as empresas acessam sua caixa
postal obtendo os arquivos que lá estiverem.
Após o processamento dos arquivos os resultados são enviados para as caixas
postais das respectivas empresas.

3.1 Cálculo dos Pontos de Casos de Uso não Ajustados

Para a especificação do sistema EDI foram definidos 10 Casos de Uso que foram
analisados para calcular o total de pontos de Casos de Uso não ajustados. Para este
sistema foram identificados os seguintes atores: Cliente, Gerente, Operador e o Sistema
Mainframe. Portanto o cálculo de peso dos atores de acordo com a Tabela 1 será:
• 3 Complexos x 3 = 9
• 1 Simples x 1 = 1
O resultado do peso dos atores é 10.
Em seguida deve ser considerado o peso dos Casos de Uso de acordo com a Tabela 5.
 Tabela 5. Peso dos Casos de Uso para o sistema EDI
# Descrição Peso do Caso de Uso
1 Validar sessão do usuário 5
2 Consultar arquivos disponíveis para recepção 10
3 Receber arquivos 15
4 Enviar arquivos 15
5 Consultar arquivos enviados para processamento 10
6 Consultar registros de envio rejeitados 10
7 Consultar arquivos de envio não processados 10
8 Cancelar arquivo de envio 10
9 Recusa de arquivo de envio 10
10 Consulta de arquivos recusados 10
Total 105
Finalmente é calculado os Pontos de Casos de Uso não Ajustados = Peso dos Atores +
Peso dos Casos de Uso 10 + 105 = 115.

3.2 Cálculo da Complexidade Técnica

Para a determinação da complexidade técnica foi conduzida uma entrevista com a
equipe de desenvolvimento e os seguintes dados foram obtidos:
Tabela 6. Fator Técnico
# Descrição Peso Valor Fator Razão
T1 Sistema distribuído 2 3 6 O sistema possui uma arquitet. distribuída.
T2 Objet. de desempenho/tempo de resposta 1 4 4 Tempo de reposta para processar arquivo.
T3 Eficiência do usuário final (on-line) 1 3 3 Nenhum requisito especial de eficiência.
T4 Complexidade interna de processamento 1 2 2 Alta complexidade de processamento.
T5 Código deve ser reutilizado 1 0 0 Nenhum requisito de reutilização.
T6 Facilidade de instalação 0.5 0 0 Nenhum requisito especial.
T7 Facilidade de uso 0.5 4 2 Necessita para pessoal não técnico.
T8 Portabilidade 2 0 0 Nenhum requisito especial.
T9 Facilidade de mudança 1 3 3 Deve possuir facilidades p/alterações
T10 Concorrência 1 0 0 O sistema não é concorrente.
T11 Inclui característ. especiais de segurança. 1 2 2 Requisitos básicos de segurança.
T12 Oferece acesso direto para terceiros 1 3 3 Acesso por clientes.
T13 Requer treinamento especial dos usuários 1 0 0 Nenhum requisito especial.
Total 25

Calculando o Fator de Complexidade Técnica:

FCT = 0.6 + (0.01 * FT)
FCT = 0.6 + (0.01 * 25)
FCT = 0.85
 3.3 Cálculo da Complexidade Ambiental
Para a determinação da Complexidade Ambiental também foi conduzida uma entrevista
com a equipe de desenvolvimento e os seguintes dados foram obtidos:
Tabela 7. Fator Ambiental
# Descrição Peso Valor Fator Razão
F1 Uso de um processo formal de desenv. de software 1,5 3 4,5 Média sinergia na utilização de processos
F2 Experiência na aplicação 0,5 5 2,5 Equipe experiente
F3 Experiência em OO 1 4 4 Equipe com bom conhecimento em OO
F4 Capacidade do líder analista 0.5 5 2.5 Líder muito competente
F5 Motivação 1 3 3 A equipe estava medianamente motivada
F6 Estabilidade de requisitos 2 5 10 Expectativa de poucas mudanças
F7 Número de Trabalhadores em tempo parcial -1 0 0 Sem participação de trab. em tempo parcial
F8 Dificuldade da linguagem de programação -1 0 0 Os programadores tinham bastante experiência
Total 26,5
Calculando o Fator de Complexidade Ambiental:
FCA = 1,4 + (- 0.03 * FA)
FCA = 0,605

3.4 Pontos de Casos de Uso

Finalmente calcula-se os pontos de Casos de Uso:
Pontos de Casos de Uso = Pontos de Casos de Uso Não Ajustados * FCT * FCA
Pontos de Casos de Uso = 115 * 0,85 * 0,605
Pontos de Casos de Uso = 59,13
Karner [Karner, 1993] sugere usar um fator de 20 homens/hora para cada Ponto
de Caso de Uso para estimativa de esforço alocado ao projeto.
Schneider [Schneider, 2001], sugere um refinamento baseado em algumas
experiências práticas. Para os fatores ambientais de F1 a F6 contar quantos estão abaixo
3 e quantos de F7 a F8 estão acima de 3. Se o total for 2 ou menos, usar 20 homens/hora
por Ponto de Caso de Uso. Se o total for 3 ou 4 usar 28 homens/hora. Se o total for 5 ou
mais deve-se procurar alterar o projeto de forma a ajustar os números obtidos, caso
contrário o risco de falha no projeto será alto.
Aplicando o critério proposto por [Schneider, 2001], utilizaremos 20
homens/hora por Ponto de Caso de Uso, o que nos indica uma estimativa de 7 meses
para o desenvolvimento do sistema.
Os dados históricos registrados para esse projeto nos fornecem um esforço
consumido de 8 meses, o que significa que a previsão foi de cerca de 12,5% inferior ao
tempo efetivamente gasto.
4. Conclusões
Uma primeira constatação é que o método de previsão do esforço utilizando Pontos de
Casos de Uso mostrou-se menos complexo do que a utilização do método de previsão
por Pontos de Função.
Identificou-se a necessidade da especificação de critérios menos subjetivos para
a análise dos Fatores Técnicos e Ambientais.
Na experiência acima foram definidos critérios para a análise desses fatores,
permitindo a convergência dos números quando a estimativa é feita por pessoas
diferentes e que possuem as mesmas diretrizes em relação aos fatores técnicos e a
complexidade do projeto.
A discrepância identificada entre o previsto e o realizado indica a necessidade de
mais análises e refinamento nos ajustes dos fatores definidos para o cálculo, visto que
esta foi a primeira experiência de utilização da técnica de Pontos de Casos de Uso
vivenciada pela organização.
Outro aspecto bastante promissor é o fato de se estabelecer um processo formal
para medição das estimativas que junto com procedimentos de registro histórico
permitirão ajustes para estabelecer um fator de produtividade por Casos de Uso
adequados a cultura da organização.
É importante adotar um estilo na descrição e detalhamento dos Casos de Uso
visando obter um bom nível de padronização, conseqüentemente melhorando as
estimativas e facilitando as etapas posteriores do ciclo de desenvolvimento do software
que serão beneficiadas por esse maior detalhamento inicial.
O método descrito se mostra promissor na atividade de previsão do esforço
necessário para o desenvolvimento de software com as observações acima, e pretende-se
aplicá-lo em outros projetos, como mais uma ferramenta para a previsão do esforço a ser
dispendido no desenvolvimento dos projetos de software.

Referências
BANERJEE, Gautam, Use case Points – An Estimation Approach, 2001, disponível em
http://isavix.net/whitepapers/1035194512861.pdf;
HILL, Peter R. Practical Project Estimation, ISBSG, 2001;
JOHNSON, Jim “Standish Group Chaos Report”, Americam Programmer, 1995;
KARNER, G. Metrics for Objectory. Diploma thesis, Universitu of Linkoping,
Sweden. No. LiTH-IDA-Ex-9344:21, December 1993;
PROBASCO, L The Ten Essentials of RUP, The Rational Edge, 2001, disponível em
http://www.therationaledge.com/content/dec_00/f_rup.htm;
SCHNEIDER, G., Winters, J.P. Applying Use Cases: A Practical Guide, Addison
Wesley, 2001;
SMITH, John The Estimation of Effort Based on Use Cases, Rational Software, 2001,
disponível em: http://www.rational.com/media/whitepapers/finalTP171.PDF;
SPR Software Productivity Research, 2002, disponível em:
http://www.spr.com/products/function.htm.
ZUZE, H. History of Software Measurement, 1995, disponível em
http://irb.cs.tu-berlin.de/~zuze/metrics/3-hist.html