Análise por Pontos de Função – Qualidade nas Estimativas

Qualidade nas Estimativas

Dimensionamento – dando tamanho ao software

Em projetos de software existem várias formas de se mensurar o “tamanho” do que será implementado.

Existe a velha (e muitas das vezes boa) opinião de especialista, que baseia-se na opinião de profissionais envolvidos, UCP – os Pontos por Caso de Uso (muito pouco utilizada),  Planning Poker – uma técnica mais utilizada em projetos ágeis, Estimativas de Três Pontos – mais focada no prazo do projeto, várias outras e FPA (ou APF) – Análise por Pontos de Função, muito utilizada em projetos de software (geralmente em projetos que rodam ciclos mais “tradicionais”, mas aplicável também a projetos ágeis).

O objetivo de se dar um “tamanho” para o software a ser entregue é ter base para planejamento/controle do projeto.

A partir do tamanho funcional é possível calcular Esforço (quantas horas serão consumidas para realizar o projeto), Prazo (quando tempo durará o projeto) e Custo (orçamento necessário a ser alocado para o projeto).

A partir destas três informações temos condições de planejar o projeto com maior coerência frente ao que realmente deverá ser entregue. A qualidade das estimativas é fator determinante para o sucesso do planejamento, e também do projeto.

Qualidade nas Estimativas - eBook sobre Requisitos de Software

Utilização de Pontos de Função

Pontos de Função são largamente utilizados em projetos de escopo fechado, onde se delimita o escopo do software a ser construído antes do projeto ser iniciado e mensura-se o tamanho funcional deste escopo. A técnica oferece condições de se ter qualidade nas estimativas.

Mas em projetos de software muitos cuidados devem ser tomados quando o assunto é métrica e estimativas, pois a volatilidade do escopo de um sistema não nos ajuda a ter precisão sobre o que será realmente feito até que seja feito. Isso é talvez o maior inimigo da qualidade nas estimativas em projetos de software.

Entenda melhor a questão da volatilidade do escopo através do Cone da Incerteza.

Um típico cenário

Vamos considerar um projeto de escopo fechado que utilizará Pontos de Função para a geração de suas estimativas.

Imaginemos: o cliente demanda o projeto e a área de software precisa metrificá-lo usando FPA para realizar o planejamento.

A métrica é realizada é chega-se à conclusão que o tamanho funcional do sistema é 1000 PF’s (Pontos de Função).

Consideremos neste exemplo que o valor de cada PF do projeto é R$ 500,00 e o indicador de produtividade (quantas horas se gasta para produzir cada ponto de função) é de 10 horas por ponto de função. Assim, temos um projeto de R$ 500.000,00 e 10.000 horas.

A métrica foi realizada, o cliente aceitou, o projeto foi contratado, é hora de agir.

Projeto iniciado, tudo bem até o momento. Mas quando o projeto atinge 20% de seu andamento verifica-se que 5000 horas já foram consumidas e R$ 250.000,00 já foi faturado.

Ainda faltam 80% de escopo para conclusão do projeto mas sobraram apenas 50% das horas e orçamento disponíveis.

Nessa hora boa parte dos profissionais sentem o frio na barriga.

Alguns (não poucos) ainda postergam uma decisão sobre, muitos pensam que “a coisa vai melhorar”, “início de projeto é assim mesmo, o projeto ganhará velocidade”, “o cliente é tranquilo, renegociaremos” e ainda tem o famoso “vamos fazer nove filhos em um mês”.

Em alguns casos existem soluções de contorno aplicáveis, em vários outros, não. Eu já presenciei projetos deste tipo estourarem e fábricas de software pagarem o dobro do orçamento inicial para concluírem o trabalho pois por força contratual desistir não é uma opção (isso é muito mais comum do que se pensa).

Dicas para uma boa métrica

E em casos como o citado acima, uma métrica bem feita pode diminuir muito o risco de se ter um dimensionamento distante da realidade no início do projeto, e assim, diminuir os problemas futuros.

Abaixo alguns pontos a serem observados que ajudam muito a realizar-se uma métrica de boa qualidade.

Definição precisa da fronteira da aplicação

Qualidade nas Estimativas - Fronteiras do Sistema

Essa parte talvez seja o ponto que demanda mais cuidado. Hoje os sistemas são mais integrados do que nunca. E muitas vezes, sob o ponto de vista do usuário, não é perceptível onde começa o escopo de um sistema e termina o de outro.

Deve-se estabelecer com o máximo de detalhe e clareza as fronteiras do sistema que está sendo metrificado, e alinhar isso com o usuário, para que qualquer esforço (adicional) do projeto pertinente a sistemas periféricos seja tratado como alteração de escopo.

Saber onde começa e onde termina o escopo é premissa (deveria estar em todos as declarações de escopo existentes).

É muito comum no meio do projeto – depois do contrato fechado – “descobrir-se” integrações das mais complicadas que precisam ser implementadas, mas é tarde, tem que fazer pois já foi assinado.

Senioridade do profissional de métrica

Muitos profissionais, da gestão e da operação, subestimam a complexidade da técnica FPA. A técnica é teoricamente simples, mas sua subjetividade (ponto de função é muito subjetivo em alguns pontos) demanda senioridade do profissional na aplicação da técnica.

Alguns pensam que basta o profissional realizar um curso bom que estará pronto para metrificar projetos complexos e gigantes. Não é bem assim.

A FPA possui um nível de subjetividade que incomoda, mas que torna-se menos subjetivo à medida que o profissional envolvido metrifica mais e mais, ou seja, adquire “rodagem”.

Além disso, profissionais que não possuem bagagem em desenvolvimento e análise de sistemas (principalmente nesta ordem) não perceberão coisas que aquele que já construiu/projetou software consegue perceber (a senioridade à qual me refiro não é somente em metrificação, mas também em produção de software).

Base Histórica

Quando realiza-se uma contagem de Pontos de Função obtêm-se um número final – o tamanho funcional do software – que é a quantidade de pontos de função.

Mas este número isoladamente nada representa, é apenas uma medida. Como já citado anteriormente, utiliza-se este número para estimar prazo/esforço/custo de um projeto.

Mas para chegar-se a estas estimativas o indicador de produtividade é obrigatório, senão não tem como fazer a conta. Mas qual a produtividade factível de uma equipe?

Com menor margem de erro, apenas gerando base histórica e fazendo análise para saber.

Isso pode ser entendido melhor neste post sobre o valor de um Ponto de Função.

Gerar base histórica, para quem não tem uma, significa olhar para trás e fazer contagem de Pontos de Função de Aplicação, que gera uma espécie de inventário do tamanho funcional, e então cruzar isso com o que foi gasto no projeto inventariado em termos de prazo/esforço/custo.

Quanto mais projetos forem analisados e incluídos em base histórica, mais preciso será o indicador de produtividade da equipe.

Qualidade minimamente aceitável dos requisitos

A acuracidade da métrica é proporcional à qualidade dos requisitos. Metrificar um escopo com requisitos ruins é apostar num quantitativo de pontos de função irreal.

E os profissionais de software tendem a subestimar a fase de Requisitos. Mas esta é a principal fase de um projeto de software, onde ocorre a modelagem conceitual do sistema.

É muito comum encontrarmos RFP’s (Requisições de Propostas) e Editais com requisitos macro tipo “Calcular imposto de renda de pessoa física”, “Calcular retenção de ISS”, “Emitir nota fiscal avulsa sem ICMS” etc. Requisitos como este precisam ser decompostos antes/durante a metrificação, do contrário a métrica ficará garantidamente subdimensionada.

Alinhamento sobre itens não mensuráveis

Muitos “tipos” de Funcionalidade não são mensuráveis por ponto de função. FPA possui uma série de contextos onde não é permitido medir o tamanho funcional da aplicação e negociar como cobrar isso é fundamental pois do contrário realiza-se parte do projeto gratuitamente, o que não é desejável.

E no decorrer do projeto, várias coisas que precisam ser implementadas não foram metrificadas (pois não são mensuráveis com a técnica FPA), gerando prejuízo para o projeto. O principal exemplo são os Requisitos Não Funcionais.

Concluindo

Eu realmente acho FPA uma opção muito pertinente para definir tamanho de software, porém nem sempre é bem interpretada e aplicada. E para se ter qualidade nas estimativas, a interpretação e aplicação da técnica deve ser a melhor possível.

Todavia, espero que o post ajude aqueles que estão em contexto semelhante ao apresentado a observar melhor a realidade das métricas e estimativas no seu dia a dia, pois quanto mais próximo da realidade é um planejamento, menos problemas todos os envolvidos no projeto terão.

E métricas e estimativas são coisas totalmente ligadas ao escopo do projeto, aos requisitos.

Se você quiser tornar-se um Expert em Engenharia de Requisitos e sair na frente no mercado, conheça nosso curso on-line super diferenciado, vamos abrir uma nova turma em breve (neste curso falamos muito sobre métricas e estimativas também).

Ponto de Função - Curso de Engenharia de Requisitos

Abraços!

qualidade nas estimativas