Temos que lembrar que a subdivisão entre frontend e backend pertence ao desenho da arquitetura, interna, da aplicação em resposta aos requisitos funcionais e não funcionais que o usuário estabelece para o produto. A Análise de Pontos de Função mede os requisitos funcionais.
A codificação pertence à implementação da aplicação em resposta aos mesmos requisitos já citados e observando o desenho da arquitetura detalhada para a aplicação.
Portanto, a resposta para a pergunta sobre como medir a codificação do backend está em outra métrica como linhas de código ou complexidade ciclomática, por exemplo.
Sobre o webservice, há mais opções a considerar. Determinado requisito funcional do usuário pode ser mapeado diretamente para o projeto e implementação de um webservice.
Por exemplo, o requisito “Como Gestor de Contratos, quero tornar disponíveis o histórico dos lances do pregão para garantir a transparências nas compras governamentais” pode ser atendido especificamente por um webservice. Porque esse webservice é mapeado especificamente para um requisito funcional no nível de um objetivo do usuário, ele é medido como uma consulta ou saída externa.
No entanto, se o webservice é o resultado de um projeto de arquitetura baseada em microserviços e não responde especificamente a um requisito funcional do usuário como citamos, então caímos na mesma situação da medição na subdivisão de uma aplicação em frontend e backend.
Por exemplo, há um comportamento compartilhado por diferentes requisitos funcionais do usuário e cuja implementação repetida ofenderia regras de facilidade de manutenção e modularidade monitoradas por uma ferramenta de análise estática de código como o SonarQube. A resposta do arquiteto ao desenhar o projeto detalhado da aplicação foi criar um webservice, ainda que utilizado apenas internamente à fronteira da aplicação, observando a arquitetura de alto nível definida no início do ciclo de vida para aquela aplicação. Esse webservice não é medido em específico pela análise de pontos de função.
Mas eu tomo a liberdade de ajustar a pergunta e, ao invés de perguntar como medir a codificação de um backend ou a construção de um webservice, perguntar como estimar o esforço.
Nesse caso, deve-se medir o requisito funcional em que esses elementos da arquitetura detalhada se inserem em pontos de função e, daí, aplicar uma taxa de entrega, expressa em horas investidas para obter a funcionalidade equivalente a um ponto de função. O resultado é uma quantidade de horas.
Por exemplo, digamos que o requisito funcional seja medido em 5 PF e a taxa de entrega seja de 8 Homens-hora / PF. Isso resulta em uma estimativa global de 40 Hh. Qual a fração do esforço total do desenvolvimento corresponde ao desenvolvimento do backend? Digamos que seja de 30%. Isso resulta em uma estimativa de 12 Hh para o backend.
Mas cabe um alerta importante sobre o uso de estimativas em pontos de função. Não se deve usar esses resultados nesse pequeno nível de granularidade para fins de estimar. As estimativas em pontos de função devem ser feitas em níveis de um release ou de um projeto; nunca no nível de uma única transação.
A distribuição da taxa de entrega, expressa em pontos de função, apresenta grande dispersão. Há transações, que exigem um investimento baixo proporcionalmente à quantidade de pontos de função; por exemplo, uma consulta implementada em um dropdown, e há transações que exigem um investimento alto proporcionalmente à quantidade de pontos de função; por exemplo, uma saída que apresenta resultados derivados de vários processamentos em lote e algoritmos complexos.
Quando se utiliza um indicador como a taxa de entrega, se busca estimar por uma tendência de centro; como um média.
Ainda que em uma população em uma grande amostra seja válido usar essa média para estimar; pontualmente os erros são inaceitáveis ao usar o mesmo método para estimar uma transação em particular. Eu pessoalmente não vejo mérito em usar um modelo paramétrico para estimar a codificação de um backend de uma única transação. Melhor perguntar ao desenvolvedor; ou melhor, a uns três deles em conjunto.
Isso não tira o mérito da análise de pontos de função ser usada para estimar ou mesmo prescrever esforço ou custo em um nível de granularidade mais alto, como os citados.
