bfpug_new.jpg (7052 bytes)Brazilian Function Point Users Group
Backfiring: um Atalho ou uma Estrada Que Não Leva a Lugar Algum?
por Márcio Silveira, EDS e Mauricio Aguiar, ti MÉTRICAS

Uma prática que vem se tornando comum no mercado, em relação à técnica de pontos de função, é a adoção do chamado "backfiring". O backfiring é um método desenvolvido para estimar o tamanho do software em pontos de função, através da aplicação, ao tamanho real do mesmo em linhas de código (SLOC), de um fator de conversão (gearing factor) constante para cada linguagem. O atrativo do backfiring é que o mesmo pode ser realizado rapidamente e com pouco esforço ou custo, já que existem ferramentas no mercado que conseguem contar as linhas de código de uma aplicação.

Um gearing factor é uma razão estabelecida entre linhas de código e pontos de função. Um gearing factor pode ser baseado em dados da indústria para uma ampla faixa de projetos e aplicações, utilizando-se o correspondente tamanho em pontos de função e SLOC. A amostragem seguida de extrapolação constitui outro método para o estabelecimento de um gearing factor. Através da medição de uma parte representativa de uma aplicação em SLOC e pontos de função, um estatístico treinado pode estabelecer uma razão (gearing factor) utilizável no resto da aplicação.

Esta técnica, apesar de aparentemente fornecer um tamanho em pontos de função e, desta forma, uma maneira fácil de fazer a contagem, pode e vai gerar, na maioria dos casos, erros consideráveis na mesma.

A natureza do backfiring ignora as características específicas de um projeto e assume um modelo linear entre o tamanho funcional e o lógico, i.e., todos os projetos e aplicações apresentam desempenho exatamente igual ao da média. "A verdade simples a respeito de PFs obtidos de SLOC através de backfiring é que a técnica produz um número de PF apenas nominal, refletindo uma única linguagem de programação, representando a implementação do software, ao invés dos requisitos funcionais." ("Using "Backfiring" to Accurately Size Software – More Wishful Thinking than Science?", Carol Dekkers e Ian Gunther, copyright 2000, Quality Plus Technologies, Inc. e Numerical Science). Um outro aspecto é que o numero de SLOC varia com a complexidade do desenho, que é peculiar, e diferente, em cada organização e mesmo em cada realidade de cada aplicação de uma organização, dependendo de fatores tais como idade do software, distribuição de processamento, complexidade dos dados e até mesmo a qualidade do modelo físico de banco de dados implementado, i.e., se temos muita desnormalização a tendência é que tenhamos desenhos mais complexos, exigindo então mais SLOCs para implementar a mesma funcionalidade ou a mesma quantidade de pontos de função.

Os resultados de um backfiring baseado em razões médias da indústria, ou a partir do método "amostragem e extrapolação" NÃO são pontos de função – são Linhas de Código. O backfiring considera uma visão física dos sistemas de software, ao invés de uma visão lógica da aplicação. A correlação entre linhas de código para uma linguagem específica e pontos de função é fraca e pode levar a resultados inconsistentes, variando por ordens de grandeza. Para citar Capers Jones, que publica uma tabela de gearing factors amplamente utilizada, "A relação entre comandos do código fonte e Pontos de Função foi pesquisada apenas durante alguns anos, de modo que a margem de erro [nos gearing factors] pode ser bastante alta." A utilização de "pontos de função backfired" em situações contratuais pode levar a resultados inesperados e possivelmente desastrosos.

Os gearing factors publicados pela indústria também variam amplamente. Utilizando COBOL, por exemplo, a QSM sugere um gearing factor padrão de 77 linhas de código COBOL por ponto de função, Capers Jones 107 linhas de código COBOL por ponto de função e o David Consulting Group 177 linhas de código COBOL por ponto de função – uma variação de mais de 100% do menor para o maior gearing factor. Mesmo considerando-se apenas os números publicados pela QSM, a amplitude dos dados amostrados resulta em uma variância nos gearing factors que vai desde –50% até +144% para Access e C++, assim como –81% até +280% para COBOL.

Juntamente com a tabela de Níveis de Linguagens de Programação e Faixas de Comandos-Fonte por Ponto de Função (Programming Language Levels and Ranges of Source Code Statements per Function Point) em seu livro Applied Software Measurement, Capers Jones afirma, "Os dados são apresentados para ilustrar tendências gerais, possuindo uma grande margem de erro... É perfeitamente possível que os projetos se comportem de uma forma muito diferente dos resultados apresentados aqui."

Ao medir o tamanho de uma aplicação ou projeto utilizando Linhas de Código Fonte (Source Lines of Code - SLOC), sempre declare que a medição foi realizada com a utilização de SLOC; utilize o tamanho em SLOC como entrada para estimativas com SLiM e em outras utilizações possíveis para o tamanho medido. Não coloque os SLOC em uma fórmula para derivar pontos de função. De acordo com o Comitê de Certificação do IFPUG (IFPUG Certification Committee), nenhuma ferramenta automatizada mede o tamanho acuradamente em pontos de função. Na medição da funcionalidade de negócio de uma aplicação, os pontos de função devem ser determinados através da aplicação das regras de contagem definidas na versão corrente do Manual de Práticas de Contagem do IFPUG (IFPUG Counting Practices Manual).

Se um portfolio de software for mantido através da contagem dos pontos de função do baseline, ao invés de backfiring, a determinação dos pontos de função correspondentes a um projeto de melhoria torna-se uma tarefa bastante direta. Embora haja um investimento inicial substancial no estabelecimento da contagem baseline da aplicação, há compensação no longo prazo.

O tamanho funcional de um projeto pode ser determinado de forma razoavelmente acurada (dentro de 10%), com a utilização da análise de pontos de função, sendo conhecidos os requisitos do negócio. Tipicamente, as linhas de códigos não podem ser estimadas até o design técnico, ainda assim envolvendo variabilidade na vizinhança de +/-20%.

Tendo em vista as considerações acima, a contagem de pontos de função deve ser conduzida através da aplicação das regras definidas no IFPUG CPM aos requisitos funcionais dos usuários de uma aplicação.