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.
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
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étricas
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.
Abraços!