Estimativa de Projeto Por Pontos de Caso de Uso

Hoje vou falar de um assunto que estou estudando para nossa metodologia de desenvolvimento, que deve rolar como parceria entre a 3Layer Tecnologia e a Pandorga Tecnologia. O tema é Use Case Points.

Para os apressados, vão para o fim do post.

Para um texto completo sobre o assunto, os artigos Project Estimation With Use Case Points, de Roy K. Clemmons e Estimating Software Based on Use Case Points, de Edward R. Carroll, são bons guias.

Motivação
Por que Use Case Points? Porque, no nosso processo, e devido às emergumenas perguntas de custo e valores que são feitas logo no início dos projetos - quando nada ainda foi detalhado, a aplicação de técnicas como COCOMO ou FPA têm pouco efeito, visto que elas necessitam, respectivamente, de um elevado histórico de projetos, ou de um grande detalhamento de requisitos. Nem um dos dois casos se aplica aos nossos projetos. E difícil seria encontrar uma empresa disposta a arcar custos de pré-análise (às vezes, durante mais de um ano de atividades) para fechar o escopo detalhado de um sistema. Aí entra o Use Case Point.

Use Case Point

Use Case Point é uma técnica muito interessante quando a equipe tem experiência na criação de Casos de Uso (e, por elegância, UML e Orientação a Objetos e algum processo derivado do RUP, como UP, o Agile ou mesmo o XP não-agressivo) e não existem detalhamentos maiores do sistema do que...os próprios Casos de Uso!

Se sua equipe não tem experiência nessas áreas...bem, então procure outra técnica; desista de estimar (e do) o projeto ou...minta para o cliente e para si mesmo :)

Se você se sentir seguro na criação de Casos de Uso, vá em frente. Tente (hic) no mínimo você terá um argumento para preencher os documentos para o cliente :)

A Fórmula Mágica
Brincadeiras à parte, a equação de três partes diz tudo:

UCP = UUCP * TCF * ECF

Mas e aí? O que é essa sopa de letrinhas? Vamos lá...

--
UCP é Use Case Point, e é o resultado que você deseja. Ele é adimensional e só tem sentido em relação a fórmula. No final ele é usado para calcular um valor de horas do projeto; mas até lá, acostume-se com ele - nada mais :)

--
UUCP significa Unadjusted Use Case Points, e nada mais é do que a somatório da multiplicação dos casos de uso por suas complexidades. Traduzindo em miúdos:

Supomos um sistema com 7 Casos de Uso simples, 13 médios e 3 complexos; o valor de UUCP é (7 * 5) + (13 * 10) + (3 * 15) = 210. Perceba os valores: casos de uso simples valem 5; médios, 10 e complexos, 15.

Essa complexidade é fixa (não existe um caso de uso muito-muito-muito complexo - em outras palavras, esse caso de uso está errado, e deve ser quebrado conforme as regras defendidas ilustramente por Cockburn em seu livro).

Uma dica simples de complexidades é (mas notem, estou sendo singelo mesmo!):

• Simples (5 pontos) : Casos de uso para coisas como telas CRUD de uma entidade, com IU simples e sem interações externas; poucos passos no fluxo principal e pré-pós-condições baseadas em validações simples.
  
• Médio (10 pontos): Casos de uso para coisas como telas CRUD mestre-detalhe de um nível e, até umas 3 entidades envolvidas; vários passos no fluxo principal e pré-pós-condições um pouco mais complexas de validação.
  
• Complexo (15 pontos): Para coisas com mais de 3 entidades envolvidas, como mestre-detalhes de múltiplas tabs filhas ou mais de um grau de dependência. Muitos passos no fluxo principal e vários branches alternativos, com pré-pós-condições de validação complexas e possíveis chamadas de regras de negócio adicionais.
  

Na prática, converse com seu arquiteto para saber mais o que sua Infra oferece e orientar os analistas para nivelar os casos de uso.

Também, podem ser considerados os atores nas complexidades. Nesse caso, sua complexidade é dada por:

• Simples (1 ponto): O ator é um sistema externo, acesso por uma API estável, simples e documentada.
• Médio (2 pontos): O ator é um sistema externo, acessado via um protocolo de base como o FTP, SSH, WebServices ou TCP/IP; também pode ser uma pessoa que interage com o sistema através de uma IU modo caractere.
• Complexo (3 pontos): O ator é uma pessoa que interage com o sistema através de uma IU gráfica; ou o ator é um sistema externo que deve ser acesso via integração de databases ou arquivos de formato intermediário de baixa documentação.

Se considerarmos os atores (e vamos considerar para engordar nosso exemplo), imaginemos 4 pessoas interagindo com o sistema através de uma IU gráfica (atores complexos) e nada mais. Assim, temos um subtotal de (4 * 3) = 12 pontos.

Somando os 21o pontos dos casos de uso com os 12 pontos dos atores, temos UUCP = 222 pontos.

--
TCF significa Technical Complexity Factor, e indica as complexidades técnicas que podem ser encontradas no sistema a ser desenvolvido. Na literatura, é comum encontrar 13 itens, cada um com pesos diferentes. Esses pesos são fixos (embora, após muitos e muitos projetos, as empresas acabam ajustando um pouco esses valores - ou mesmo adicionando outros itens). Na prática, para os iniciantes, não mexemos nisso. O que vale, nesse caso, é a relevância do item no projeto.

Por exemplo, o TCF "Easy to Use" (que indica o quão fácil de usar deve ser o sistema final para o usuário) tem um peso padrão de 0.5. Esse valor não é mexido. O que mexemos, é a relevância dele no projeto. Em outras palavras, "no nosso projeto, a facilidade de utilizar o sistema é importante?". À essa resposta (e dos outros itens), damos pesos de 0 a 5. Por exemplo, para meus amigos R. e R. que desenvolvem jogos para celulares, com certeza, esse item tem relevância 5. Para mim, que programo coisas como o Magoo e o Merlin, eu posso colocar uma relvância 3 nesse item. Os trabalhos que mencionei acima tem as tabelas completas dos TCF (e dos ECF, abaixo).

Uma vez somadas as complexidades, a fórmula exige um ajuste do TCF, no formato:

TCF final = 0.6 + (0.01 * TCF)

Isso é importante, para estabilizar a função e termos um ponto de fuga. Os artigos explicam melhor o porquê das coisas. Na prática, o valor 0.6 é uma constante (que pode ser ajustada se a empresa tiver argumentos pra isso) entre 0.6 até 1.30.

Para a continuidade do post, vamos supor que depois de tudo isso, nosso TCF deu 19,5 pontos e, assim, o TCF final é igual a 0.6 + (0.01 * 19,5) = 0,795. Em percentuais, os fatores técnicos reduziram o esforço do projeto em 20,5%!

__
ECF significa Environmental (ou Experience) Complexity Factor, e tem as mesmas regras do TCF, embora, aqui, o objetivo é mensurar quão boa é a equipe, o cliente e o ambiente de trabalho em qu será desenvolvido o projeto. Itens como "experiência com UML", "motivação da equipe" e "requisitos estáveis" são valores ECF. Na literatura, 8 são os ECF padrões. Novamente, adições nesses items e variações em suas complexidades podem ocorrer depois que a empresa tiver expertise na área. Para os novatos (nós), vale a regra da relevância novamente.

Assim, um item como "motivação" para o projeto Merlin (no meu caso), eu colocaria 5 (os valores também são de 0 a 5 aqui). O item "dificuldade de programação" seria (novamente no Merlin) 5, visto que os algoritmos dele são bem malucos :)

Da mesma forma, o ECF precisa de um ajuste, com a fórmula:

ECF final = 1.4 + (-0.03 * ECF)

Se você for bom (e souber o que está fazendo), pode ajustar a constante 1.4 entre os valores 0.425 até 1.4 :)

Para o exemplo continuar, assumimos que o ECF dos 8 itens de ambiente deu 26, logo, o ECF final é 1.4 + (-0.03 * 26) = 0,62. Em outras palavras, os fatores ambientais resultaram na redução de 38% de esforço no projeto!

Observem duas coisas:

1. Para equipes grandes e/ou dispersas e/ou multidisciplinares, é interessante calcular o valor ECF final para cada integrante da equipe, visto que, cada programador (ou analista, projetista, etc.) pode der uma motivação, um entendimento da linguagem de programação, experiência com o processo de desenvolvimento (...) diferentes. Nesse caso, calcular vários ECF e obter uma média acaba trazendo mais accuracy para método.
2. Devido os valores das constantes (0.6 e 1.4, respectivamente), observa-se que o ECF (o fator equipe) tem uma taxa de importância maior no sucesso ou fracasso do projeto do que os fatores técnicos (TCF). Assim, muito mais vale ter uma equipe boa do que uma solução tecnológica maravilhosa :)
   

Após tudo isso (ufa), podemos calcular o UCP, sendo ele igual a 222 * 0.795 * 0.62 = 109 pontos, aproximadamente.

Traduzindo os pontos
De nada adianta um valor 109! Precisamos saber quantas horas de projeto isso dá!

Assim, entra o Fator de Produtividade (PF) da equipe. Para computá-lo, é importante um histórico, pelo menos parcial de projetos. Isso poderia ser feito olhando o último projeto feito pela equipe. Por exemplo, se no último desenvolvimento tivemos um projeto de 2200 horas para 120 UCPs, poderíamos ter, aproximadamente, um PF = 18 (ou seja, 2200/120).

Esse valor, 18, significa que, cada UCP demora 18 horas por pessoa para ser desenvolvida. E não adianta usar a regra do Dilbert (ah, se tem um projeto de 500 horas, vou mandar um mail pros meus amigos no Gmail e convocar 50 pessoas pra trabalhar das 12:00 às 22:00 do sábado e fazer o projeto em 10 horas corridas...).

Para quem não tem um histórico, duas alternativas:

1. Mapeie cada tipo de Caso de Uso que você espera ter no sistema e fale com a equipe inteira. Pergunte sobre quanto tempo, usando as tecnologias e conhecimento da equipe seria gasto para programar esse caso de uso. Mas atente para o seguinte: o caso de uso envolve todo o ciclo de desenvolvimento, desde a análise, até a homologação (ou mesmo os planos da retirada). Assim, provavelmente você terá que fazer uma planilha para mensurar quanto cada etapa do ciclo consome do caso de uso (requisitos, reuniões, análise, projeto, modelagem, testes unitários, integrados, funcionais, homologação, docuementação, enfim; tudo).
2. Use o valor FP = 20 (um chute no escuro, mas a literatura sugere isso mesmo para equipes iniciantes)

Juntando tudo, ou, Estimando as Horas do Projeto
Com os valores da UCP e FP, você pode calcular quantas horas deve (note, não é vai!) consumir o projeto:

Estimativa de horas = UCP * FP = 109 * 18 = 1962 horas

Realimentando o Sistema (eu adoro isso)
OK, você estimou. Mas para ter graça a coisa, você deve monitorar o projeto. Não faça ajustes nessa estimativa (ou, pelo menos, mantenha a versão original das coisas). Messa o tempo que o projeto levou e as discrepâncias nas complexidades dos casos de uso, atores e fatores técnicos e ambientais. Assim, você vai afinando a coisa.

Depois do projeto acabado, digamos, ele consumiu somente 990 horas (uhu, você entregou antes do prazo!), você pode calcular um novo FP, ou seja FP = 990 / 109 UCP = 9,08.

Utilize esse FP para os próximos projetos e faça a roda girar!


Para os Apressados (como eu)
Falei, falei e falei. E enfim, como colocar em prática isso? Usem o Enterprise Architect. Ele faz a mão de tudo isso automaticamente :)