SlideShare ist ein Scribd-Unternehmen logo
1 von 5
Downloaden Sie, um offline zu lesen
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.

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ha Offices Capão Raso
Ha Offices Capão RasoHa Offices Capão Raso
Ha Offices Capão Raso
 
Lisset
LissetLisset
Lisset
 
Limites
LimitesLimites
Limites
 
Unidade 3 servicos
Unidade 3   servicosUnidade 3   servicos
Unidade 3 servicos
 
Actividad2 equipo1
Actividad2 equipo1Actividad2 equipo1
Actividad2 equipo1
 
Catálogo Unibind 2014
Catálogo Unibind 2014Catálogo Unibind 2014
Catálogo Unibind 2014
 
EMPECEMOS CON LOS FRENOS
EMPECEMOS CON LOS FRENOS EMPECEMOS CON LOS FRENOS
EMPECEMOS CON LOS FRENOS
 
Comunicação corporativa e redes sociais puc
Comunicação corporativa e redes sociais   pucComunicação corporativa e redes sociais   puc
Comunicação corporativa e redes sociais puc
 
Falhas nos projetos é culpa da Cultura da Empresa e não das metodologias ágeis
Falhas nos projetos é culpa da Cultura da Empresa e não das metodologias ágeisFalhas nos projetos é culpa da Cultura da Empresa e não das metodologias ágeis
Falhas nos projetos é culpa da Cultura da Empresa e não das metodologias ágeis
 
Ch5 access point
Ch5  access pointCh5  access point
Ch5 access point
 
Laptop
LaptopLaptop
Laptop
 
Unidade3 seg perimetral-proxy
Unidade3 seg perimetral-proxyUnidade3 seg perimetral-proxy
Unidade3 seg perimetral-proxy
 
Huerto en-casa-web
Huerto en-casa-webHuerto en-casa-web
Huerto en-casa-web
 
Draagvlak voor al je plannen
Draagvlak voor al je plannenDraagvlak voor al je plannen
Draagvlak voor al je plannen
 
Exp.ciencias
Exp.cienciasExp.ciencias
Exp.ciencias
 
VIII Encuentro participacion ciudadana_2014
 VIII Encuentro participacion ciudadana_2014 VIII Encuentro participacion ciudadana_2014
VIII Encuentro participacion ciudadana_2014
 
Actividad de proucto2
Actividad de proucto2Actividad de proucto2
Actividad de proucto2
 
G 050
G 050G 050
G 050
 
Presentacion excel3
Presentacion excel3Presentacion excel3
Presentacion excel3
 
Adm sop-unidade12
Adm sop-unidade12Adm sop-unidade12
Adm sop-unidade12
 

Ähnlich wie 4484908 pontos-de-caso-de-uso

UML - Criando Diagramas Eficientes
UML - Criando Diagramas EficientesUML - Criando Diagramas Eficientes
UML - Criando Diagramas EficientesRodrigo Cascarrolho
 
Um Injetor de Falhas para a Avaliação de Aplicações Distribuídas Baseadas no ...
Um Injetor de Falhas para a Avaliação de Aplicações Distribuídas Baseadas no ...Um Injetor de Falhas para a Avaliação de Aplicações Distribuídas Baseadas no ...
Um Injetor de Falhas para a Avaliação de Aplicações Distribuídas Baseadas no ...Dalton Valadares
 
Gerencia e Administração de Redes
Gerencia e Administração de RedesGerencia e Administração de Redes
Gerencia e Administração de RedesAllan Piter Pressi
 
Apostila de analise
Apostila de analiseApostila de analise
Apostila de analiseOseas_Lima
 
Algoritmos de Estimação de Distribuição Aplicados à Estimativa de Software
Algoritmos de Estimação de Distribuição Aplicados à Estimativa de SoftwareAlgoritmos de Estimação de Distribuição Aplicados à Estimativa de Software
Algoritmos de Estimação de Distribuição Aplicados à Estimativa de SoftwareJosé Corrêa Viana
 
REA- Diagramas de Casos de Uso da UML
REA- Diagramas de Casos de Uso da UMLREA- Diagramas de Casos de Uso da UML
REA- Diagramas de Casos de Uso da UMLIFFar - SVS
 
Aula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfAula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfGreiceSilva21
 
Aula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfAula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfGreiceSilva21
 
Aula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfAula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfGreiceSilva21
 
Analise de desempenho_compactadores_asti_2011
Analise de desempenho_compactadores_asti_2011Analise de desempenho_compactadores_asti_2011
Analise de desempenho_compactadores_asti_2011Saulo Marques
 
Apostila de algoritimos
Apostila de algoritimosApostila de algoritimos
Apostila de algoritimosCleide Soares
 

Ähnlich wie 4484908 pontos-de-caso-de-uso (20)

Artigo
ArtigoArtigo
Artigo
 
UML - Criando Diagramas Eficientes
UML - Criando Diagramas EficientesUML - Criando Diagramas Eficientes
UML - Criando Diagramas Eficientes
 
Computacao
ComputacaoComputacao
Computacao
 
Um Injetor de Falhas para a Avaliação de Aplicações Distribuídas Baseadas no ...
Um Injetor de Falhas para a Avaliação de Aplicações Distribuídas Baseadas no ...Um Injetor de Falhas para a Avaliação de Aplicações Distribuídas Baseadas no ...
Um Injetor de Falhas para a Avaliação de Aplicações Distribuídas Baseadas no ...
 
Gerencia e Administração de Redes
Gerencia e Administração de RedesGerencia e Administração de Redes
Gerencia e Administração de Redes
 
Aula-04-UML.pptx
Aula-04-UML.pptxAula-04-UML.pptx
Aula-04-UML.pptx
 
Apostila de analise
Apostila de analiseApostila de analise
Apostila de analise
 
Parte6 casos de uso
Parte6   casos de usoParte6   casos de uso
Parte6 casos de uso
 
Algoritmos de Estimação de Distribuição Aplicados à Estimativa de Software
Algoritmos de Estimação de Distribuição Aplicados à Estimativa de SoftwareAlgoritmos de Estimação de Distribuição Aplicados à Estimativa de Software
Algoritmos de Estimação de Distribuição Aplicados à Estimativa de Software
 
REA- Diagramas de Casos de Uso da UML
REA- Diagramas de Casos de Uso da UMLREA- Diagramas de Casos de Uso da UML
REA- Diagramas de Casos de Uso da UML
 
Lamport
LamportLamport
Lamport
 
Aula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfAula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdf
 
Aula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfAula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdf
 
Aula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfAula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdf
 
Aula 05 .pdf
Aula 05 .pdfAula 05 .pdf
Aula 05 .pdf
 
UMLAulaI.pdf
UMLAulaI.pdfUMLAulaI.pdf
UMLAulaI.pdf
 
ava facul uva unijorge (81).pdf
ava facul uva unijorge (81).pdfava facul uva unijorge (81).pdf
ava facul uva unijorge (81).pdf
 
Analise de desempenho_compactadores_asti_2011
Analise de desempenho_compactadores_asti_2011Analise de desempenho_compactadores_asti_2011
Analise de desempenho_compactadores_asti_2011
 
Apostila de algoritimos
Apostila de algoritimosApostila de algoritimos
Apostila de algoritimos
 
Aula3 casos de uso
Aula3 casos de usoAula3 casos de uso
Aula3 casos de uso
 

4484908 pontos-de-caso-de-uso

  • 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 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
  • 2. 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:
  • 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 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
  • 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 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
  • 5. 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.