Calculando Estimativas: o Método de Pontos de Caso de Uso1                                  Por Herval Freire (herval@cnnt...
sistema – onde seja possível diferenciar transações e interações com o usuário. Desta forma, casos de usode nível muito al...
1.   Se o caso de uso for considerado simples - isto é, conter uma interface com usuário simplificada         e utilizar a...
E2         Experiência com a Aplicação em desenvolvimento       0.5              E3         Experiência em Orientação a Ob...
alteração de requisitos, apenas refazendo alguns cálculos. Apesar dos ganhos, a técnica apresentaproblemas evidentes – com...
Próximos SlideShares
Carregando em…5
×

4484908 pontos-de-caso-de-uso

551 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
551
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
16
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

4484908 pontos-de-caso-de-uso

  1. 1. 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 tarefafácil. Na grande maioria dos casos, as estimativas costumam ser lançadas sem qualquer preocupação comuma medição formal, resultando em cronogramas imprecisos - e algumas vezes, desastrosos. Formalismos criados para embasar os cronogramas de desenvolvimento e lançar de estimativasde tempo e esforço foram desenvolvidos com o passar do tempo. Mecanismos populares, como aestimativa por Pontos de Função, tornaram-se padrões de facto, e trazem resultados reais, já demonstradospor 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 seutamanho 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 - entradaexternas, saídas externas e consultas externas. Além destes objetos lógicos, cada função tem ainda seusrecursos de dados classificados como "arquivos lógicos internos" (tabelas e arquivos pertencentes aosistema) e "interfaces externas" (tabelas ou arquivos de outros sistemas, acessados pelas funções dosistema em desenvolvimento). Para uma dada tela, é possível estimar um número de Pontos de Funçãorealizando um cálculo sobre a quantidade de arquivos lógicos (internos e externos) acessados, número deentradas e saídas externas e número de consultas. Para ajustar o resultado obtido deste somatório, sãoaplicados multiplicadores levantados a partir de uma série de outros requisitos não-funcionais - o queinclui, 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, emPontos 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 ummecanismo complexo, baseado em longas tabelas e cálculos de ajuste para se chegar a um denominadorde porte e custo do sistema. Somado a isto, a técnica exige que novos documentos para o cálculo dasestimativas sejam adicionados ao sistema, aumentando a pilha de papéis associados ao projeto – e quenecessitam 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 requisitosque 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 dosprimeiros protótipos, ou mediante uma análise detalhada junto a um cliente que consiga entender osistema em um nível funcional, com alto nível de detalhes. Na maioria dos casos, esta não é a situaçãoreal.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 partedos usuários. A técnica de análise de dimensão por Casos de Uso foi criada para permitir que sejapossível estimar o tamanho do sistema ainda na fase de levantamento de Casos de Uso, utilizando-se dospró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, daObjectory (hoje, Rational Software). Ela baseia-se em dois métodos bastante utilizados - o mecanismo dePontos de Função e uma metodologia conhecida como Mk II, uma adaptação da técnica de PFs, bastanteutilizada na Inglaterra. A forma de lançar uma estimativa é o principal diferencial da métrica por Casos deUso: o método trata de estimar o tamanho de um sistema de acordo com o modo como os usuários outilizarão, a complexidade de ações requerida por cada tipo de usuário e uma análise em alto nível dospassos necessários para a realização de cada tarefa, em um nível muito mais abstrato que a técnica dePontos 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 otamanho 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 naqualidade final da medição: deve haver a preocupação em medir somente casos de uso em nível de1 Artigo publicado na revista Developer’s Magazine número 78, Fevereiro de 2003
  2. 2. sistema – onde seja possível diferenciar transações e interações com o usuário. Desta forma, casos de usode nível muito alto (business modelling do sistema) ou muito baixo (casos de uso atômicos, descrevendoo 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 casosde uso para a aplicação da técnica. Esta é a principal falha da metodologia com relação à métrica porPontos de Função: na maioria dos casos, caberá aos analistas decidir a granularidade ideal dos Casos deUso 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 pesototal dos atores do sistema (Unadjusted Actor Weight, ou UAW) é calculado pela soma dos produtos donúmero de atores de cada tipo pelo respectivo peso. Desta forma, um sistema projetado para dois tipos deusuários (gerente e usuário comum) e que fosse acessado por um outro sistema utilizando-se de umprotocolo de comunicação, por exemplo, teria um valor de UAW de 8 (2 atores de nível “complexo” e 1ator de nível “médio”).Tipo de Ator Peso DescriçãoAtor Simples 1 Outro sistema acessado através de uma API de programaçãoAtor Médio 2 Outro sistema interagindo através de um protocolo de comunicação, como TCP/IP ou FTPAtor Complexo 3 Um usuário interagindo através de uma interface gráfica (stand-alone ou Web) Tabela 1. Pesos de Atores2. Calculando o Peso dos Casos de Uso Uma vez calculado o peso dos atores do sistema, partimos para o cálculo inicial do peso brutodos casos de uso (Unadjusted Use Case Weight, ou UUCW). Para fins de cálculo, dividimos os casos deuso em três níveis de complexidade, de acordo com o número de transações envolvidas em seuprocessamento. Por transação, entende-se como uma série de processos que devem, garantidamente, serrealizados em conjunto - ou cancelados em sua totalidade, caso não seja possível concluir oprocessamento. 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 daquantidade 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 onúmero de classes envolvidas no processo, como mostrado na tabela 3. O cálculo, neste caso, é realizadoda mesma forma que na abordagem anterior, e pode ser aplicado quando já for possível antever asentidades 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 valoressão somados para se obter o UUCW total. Esta fórmula é mais rápida e menos precisa que as duas outrasabordagens, mas apresenta resultados rapidamente:
  3. 3. 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 deatores e casos de uso: UUCP = UAW + UUCW3. 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 dosistema; e um cálculo de fatores de ambiente, requisitos não-funcionais associados ao processo dedesenvolvimento - tais como experiência da equipe, motivação e estabilidade do projeto. Estes doisfatores 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 requisitolistado 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 5indica forte influência.3.1. Fatores Técnicos Para calcular o fator de complexidade técnica do sistema (seu Technical Complexity Factor, ouTCF), 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 aT13) 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 eseus pesos associados. Fator Descrição Peso E1 Familiaridade com RUP ou outro processo formal 1.5
  4. 4. 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 cadarecurso 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 einfluencia seu desenvolvimento. Da mesma forma, atribuir um valor de influência zero (nenhumainfluê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 E3indica 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) eseu 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 Usodo sistema: isto reflete o ganho de velocidade proporcionado pelos diversos fatores ambientais descritosna 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-seda seguinte fórmula: UCP = UUCP x TCF x EF Segundo Karner, podemos estimar o tempo necessário para o desenvolvimento do projetocalculando-se uma média de 20 horas de trabalho por Ponto de Caso de Uso (UCP), sendo queexperiê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 apresença de certos atributos influencia diretamente a média de horas por ponto calculado, utilizando aseguinte 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 necessidadede treinamento de pessoal, adequação de tecnologia ou revisão de requisitos, para garantir um melhoraproveitamento 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 elademonstra resultados muito mais cedo, no ciclo de desenvolvimento. Além disso, a técnica utiliza-se deum tipo de documento essencial em metodologias dirigidas por caso de uso (Use Case Driven), como oRUP, de forma que é possível calcular prontamente mudanças nas estimativas do sistema a cada pequena
  5. 5. alteração de requisitos, apenas refazendo alguns cálculos. Apesar dos ganhos, a técnica apresentaproblemas 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écnicainteressante para equipes que carecem de uma métrica formal de lançamento de estimativas ou que nãoconseguiram bons resultados utilizando-se de outros mecanismos de estimativa. Sem dúvida, vale a penatentar.ReferênciasKarner, 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.

×