Pontos de Função: Cuidados na sua Utilização
Todos sabemos que a contagem de pontos de função (PF) visa trazer um valor que nos dê a idéia de tamanho de um sistema, baseado nas transações de dados que o mesmo possui, bem como nos seus agrupamentos de dados. Mas até onde devemos utilizá-lo e que cuidados devemos ter na sua utilização?
Os resultados derivados da aplicação direta ou indireta da técnica de contagem podem nos dar muitas informações sobre um sistema além da estimativa de tamanho do mesmo, seu principal propósito. Já se utilizam PF como base para cálculo de produtividade da equipe, bem como para base de estimativa de esforço e prazo para desenvolvimento de um sistema. Pode-se também utilizar PF para desenvolver um orçamento de um projeto de desenvolvimento de sistema ou até como moeda base de preço e pagamento de um sistema, o que, aliás, já ocorre em muitas licitações públicas aqui no Brasil.
Ora, se a contagem de PF reflete o tamanho de um sistema, é possível você definir uma produtividade para sua equipe (por exemplo, em horas por ponto de função – H/PF), desde que você utilize métricas de acompanhamento com o seu pessoal (por exemplo, prazo ou esforço para executar uma determinada tarefa – tarefa esta que você pode medir em PF).
A partir daí, o céu é o limite: pode calcular a sua produtividade por fase de projeto, também em H/PF; estimar a produtividade por tipo de profissional (analista, programador, testador) ou até pela experiência dele (profissional júnior, pleno ou sênior); estimar prazos também por fase de projeto ou do sistema como um todo; e com tudo isso conseguir ter o seu custo por ponto de função (R$/PF) o que já serve de uma boa base para um orçamento. Maravilha, não? Acabou-se e subjetividade nesta área. Projeto de desenvolvimento de sistemas agora é uma ciência exata. Todos já conseguem estimar prazos e custos sem maiores problemas. Será?
Bem, não é bem assim. A técnica de contagem de PF possui muitos critérios de caráter subjetivo, o que pode trazer diferenças em seus resultados. Ou seja, dois especialistas em PF podem medir o mesmo sistema e achar valores diferentes. Inclusive existe uma linha de pensamento que diz que essa diferença pode chegar até a 15% (!!!?).
Além disso, por mais que você tenha uma base histórica confiável da sua equipe com esses números, ao converter um tamanho de sistema para estimativa de esforço e/ou prazo e/ou custo deve-se levar em conta muito das características do seu projeto de desenvolvimento. Por exemplo, é java? .NET? Delphi? É cliente/servidor? Web? Mobile? Possui muitas tabelas simples de descrição, as chamadas code tables? As interfaces são complexas e trabalhosas de se fazer na plataforma que se escolheu? É um sistema tipicamente transacional? Muitos dos números que a sua contagem vai gerar, podem (e devem) variar em função dessas respostas.
Particularmente, as duas últimas perguntas refletem muitos dos problemas de senso comum encontrados entre clientes e empresas desenvolvedoras, que já presenciei ao longo da minha carreira: interfaces complexas e sistemas tipicamente transacionais.
Existem interfaces que são extraordinariamente complexas e a técnica de contagem de PF nivela muito por baixo este dimensionamento. Por exemplo, fazer telas em um dispositivo mobile (ou até mesmo em um sistema web tradicional) que possuam comportamento de um sistema cliente/servidor rodando dentro de uma rede local, não é nada simples e demanda um esforço bem maior do que se fizéssemos utilizando uma ferramenta/IDE típica de cliente/servidor.
E se o sistema não for tipicamente transacional? Se a contagem de PF é baseada em transações (entradas e alterações de dados; consulta e saídas de dados), imagine dimensionar ou estimar esforço e prazo de desenvolvimento de, por exemplo, um sistema especialista ou de redes neurais ou sistemas que utilizem data mining, pela técnica de contagem de PF? Bem, não é por aí. Eles não são tipicamente transacionais e essa contagem de PF muito dificilmente irá refletir a realidade do esforço no seu desenvolvimento.
Bem vindo, técnicas de PF! Há muito tempo que vieram para ficar, sem dúvida. Mas devemos utilizá-las sabiamente, estando atento às suas limitações, seus objetivos e seus fundamentos básicos.
Deixe seu Recado
Acredito que a técnica de medição usada em pontos de função é bem vinda como um auxiliar, mas o mais importante pra mim são os dados históricos de projetos anteriores, pois esses, quando bem documentados expressão a realidade do projeto expondo suas principais dificuldades.
Werther, muito interessante os pontos colocados que mostram claramente a forma e os cuidados que os PF devem ser ser utilizados.
Werther, concordo contigo em tudo, só gostaria de acrescentar o seguinte: Precisamos separar bem a técnica de contagem de ponto por função e produtividade. A técnica mede o tamanho das funcionalidades, a produtividade é resultado da relação tipo de profissional com o tipo de tecnologia adotada para desenvolver uma funcionalidade. Como o mercado utiliza o PF para orçar software, quando não atinge suas metas com muita precisão, então a técnica APF é crucificada, quando isso acontec tentam até mudar a técnica ao invés de ajustar a produtividade. Com respeito a técnica, acredito que ela vai evoluir para uma padronização maior, ou seja, uniformidade na aplicação da técnica bem como na atualização da técnica para novos paradigmas de softwares. Inclusive gostaria de saber sua sugestão de como medir webservices?
Olá, Emerson! Obrigado pelos comentários inteligentes. São realmente coisas distintas (produtividade x PF), mas como PF mede (e bem) o tamanho do sistema, sua utilização para obtenção da produtividade é uma consequencia quase natural para os gerentes de projetos.
Mas mesmo assim, no meu entender, as técnicas de contagem precisam de um maior aprimoramento para se tornarem mais objetivas, evitando as costumeiras divergências de medições feitas por dois profissionais qualificados. Uma coisa que tem que, certamente, ser melhorada é o cálculo do fator de ajuste, que tenta levar em conta o fator tecnológico e outras características do projeto/sistema.
Emerson, voce perguntou sobre como medir webservices. Este é um dos exemplos que realmente o esforço não acompanha o tamanho do sistema, a depender da ferramenta que voce estiver utilizando.
Como PF só considera, para efeito de transação, o que apenas atravessa a fronteira e também atua em cima dos arquivos de dados (ALIs/AIEs) – as duas condições – para efeito de medição penso que devemos considerar SE ou EE todas as solicitações feitas externamente ao webservices e somente isso devemos considerar. Em webservices típicos, não existe transação que não seja originada por uma solicitação externa.
Uma solicitação externa pode gerar uma ou mais consultas (o que aumenta a complexidade) ou até uma manutenção nos arquivos de dados. E sempre ocorre uma transformação na resposta, o que descaracteriza um CE. Poderia ser um EE apenas no caso de uma solicitação externa que tivesse fins de manutenção e sem nenhum retorno.
O que você acha?
Werther, deixa ver se eu entendi, apenas medirá EE e SE, exceto CE. Em relação as transações, concordo. Mas para medir a complexidade precisamos considerar os arquivos de dados (ALI/AIE). Poderíamos tomar como base o seguinte princípio: O tão citado usuário em APF pode corresponder ao consumidor do webservice. Sendo assim a visão do usuário corresponderia a interpretação da função explícita no webservice. Exemplo, se um webservice fornece o nome da rua tendo como parâmetro de entrada o CEP. Quem vai consumir, “enxerga” uma base de ruas codificadas por um CEP. Sendo assim considero um ALI chamado rua ou endereço com dois TDs, CEP e RUA. Para função de transação consideramos uma SE com uma TD, o nome da rua que é visível para a aplicação comsumidora.
Fazendo assim, estou transgredindo algum princípio da APF?
Acredito que não, Emerson, seu raciocínio está correto. Apenas uma observação: O número de TDs do ALI (apenas se houver manutenção) ou AIE (quando consulta, aliás a maioria dos casos em um webservice) não é o que o usuário enxerga na transação e sim o que ele realmente possui. Então, no caso de endereço, certamente será mais de dois TDs. E na transação existem dois TDs, pois ambos (RUA e CEP) atravessam a fornteira da aplicação, em sentidos opostos.
Como Werther bem colocou o que não falta são limitações. Existem situações em que a técnica nem mesmo se aplica (mudar a plataforma tecnológica de um determinado sistema, por exemplo, é ponto de função zero; nem por isso o esforço é zero…). Outro aspecto é que a FPA orienta enxergar o sistema com os olhos do usuário; e diferentes usuários podem enxergar o mesmo sistema de forma diversa. Já tive alguns embates em contagem que no final não havia jeito: “Nem eu, nem vc, tiremos a média…”. Mas não tenho dúvida que a técnica veio para ficar (pelo menos até inventarem algo melhor). Basta ver o número de organizações que trabalha com a métrica e sua aplicação em fábricas de software.
Difereças de PF e PFI. grato
Boa tarde!
Pessoal,
Devemos considerar as mensagens de retorno do webservice como parte integrante da SE contada ou contamos outra SE para as mensagens?
Oi Michael, desculpe a demora. É que esse tópico era bem velho. Para os WebServices, supondo que meu sistema estivesse fazendo requisições para um webservice externo, eu contaria apenas um SE para cada nova requisição, já contemplando a requisição e a resposta à mesma. Era essa a sua dúvida?