Software - Pontos de função

Pontos de Função?

Caros leitores, ultimamente tenho atuado em muitos projetos de software, e cada vez mais tem me chamado a atenção a falta de conhecimento que alguns profissionais de informática demonstram quanto ao conceito PF. O texto abaixo não é meu (ainda estou sem tempo de escrever) achei bastante didático e por isso compartilho aqui com vocês.

Um abraço!

"Pontos de função" medida funcional de tamanho de software, introduzida em 1979 por Alan Albrecht da IBM.

Medida funcional de tamanho de software é um conceito definido pelo padrão ISO/IEC 14143-1:1998 e refere-se à medição do tamanho do software considerando-se apenas a funcionalidade solicitada e recebida pelos respectivos usuários. Nesse sentido, uma medida funcional de tamanho é uma medida externa, pois mede somente aquilo que é percebido pelos usuários do produto de software, independentemente da forma de implementação escolhida.

A contagem dos pontos de função é regulamentada pelo International Function Point Users Group (IFPUG), organização internacional sem fins lucrativos sediada nos Estados Unidos da América. O IFPUG publica o Counting Practices Manual (Manual de Práticas de Contagem), atualmente em sua versão 4.2.1, que estabelece os padrões para o cálculo dos pontos de função. Para garantir a padronização dos procedimentos de contagem, o IFPUG oferece certificação na técnica e divulga os profissionais certificados através de seu site na Internet – www.ifpug.org.

O método do IFPUG foi oficializado através do padrão internacional ISO/IEC 20926 de 2002.

A contagem dos pontos de função é realizada com base em cinco tipos de componentes de software: arquivos internos, arquivos externos, entradas, saídas e consultas. Esses termos possuem um sentido específico na FPA - Function Point Analysis (Análise de Pontos de Função) e a identificação e classificação dos componentes exige conhecimento especializado.

Os pontos de função são utilizados como fator normalizador do tamanho do software, permitindo o estabelecimento de métricas tais como produtividade (pontos de função produzidos por pessoa-mês), taxa de entrega (homens-hora para a produção de um ponto de função), densidade de defeitos (defeitos encontrados por ponto de função) e outras. A taxa de entrega também pode ser denominada produtividade, o que pode causar confusão. A melhor opção é deixar clara a nomenclatura utilizada em cada caso.

Vem crescendo a utilização, pelas empresas brasileiras, dos pontos de função nos contratos de fornecimento de software, seja através da cotação de preços por ponto de função, ou através da quantificação dos serviços através de medições de pontos de função.

No mundo, os pontos de função do IFPUG são utilizados pela grande maioria das organizações que realizam algum tipo de medição funcional de tamanho de software.

Embora exista uma forte relação entre o tamanho funcional de um software (medido em Pontos de Função) e o esforço gasto no seu desenvolvimento (medido em pessoas-hora), os Pontos de Função não medem diretamente o esforço de desenvolvimento. Nesse sentido, os Pontos de Função são semelhantes ao metro quadrado na construção civil: embora o metro quadrado influa consideravelmente no esforço de construção e no custo de um imóvel, outros fatores poderão contribuir tanto ou mais quanto o metro quadrado. Exemplos de fatores são a localização do imóvel, a idade, o material utilizado na construcão e acabamento, o prestígio do arquiteto, etc. Da mesma forma, dois sistemas podem ter a mesma medida em Pontos de Função e preços totalmente diferentes. Por exemplo, um sistema pode ser monousuário, implementado em uma ferramenta como o Access; o outro pode ser uma aplicação web com várias camadas, envolvendo um mainframe e sofisticados dispositivos de segurança. Neste caso, certamente a quantidade de horas e o preço de cada um desses sistemas será completamente diferente. A conclusão é que o tamanho em Pontos de Função é apenas um dos fatores que influem sobre o esforço de desenvolvimento e sobre o custo de um sistema. Outros importantes fatores são a confiabilidade desejada para o software, a metodologia de desenvolvimento utilizada, o nível de testes requerido, a complexidade dos algoritmos, a dificuldade da plataforma computacional, o estilo de interface com o usuário, o grau de reutilização desejado, a capacidade e experiência da equipe, a disponibilidade de ferramentas de software adequadas e outros.

No passado a empresa SPR - Software Productivity Research - disponibilizava gratuitamente uma tabela de linguagens de programação na internet. Essa tabela atribuía a cada linguagem um nível, sendo fornecidos intervalos de produtividade estimados para cada nível de linguagem. Além disso, a chamada "Tabela da SPR" fornecia estimativas para a razão Linhas de Código Fonte / Ponto de Função, para cada linguagem (também chamada Fator de Backfiring). Essa tabela, embora contivesse dados estatísticos interessantes para pesquisas, foi muitas vezes indevidamente utilizada como base em relacionamentos comerciais. A própria SPR optou por primeiro retirar a tabela do ar e depois traze-la de volta, desta vez como um serviço pago. Convém ler a mensagem de Doug Brindley, vice-presidente da SPR, sobre o assunto.

É bom lembrar que a linguagem de programação é apenas um dos fatores que afetam a produtividade. Conforme explicado em outra pergunta, também são fatores importantes: a confiabilidade desejada para o software, a metodologia de desenvolvimento utilizada, o nível de testes requerido, a complexidade dos algoritmos, a dificuldade da plataforma computacional, o estilo de interface com o usuário, o grau de reutilização desejado, a capacidade e experiência da equipe, a disponibilidade de ferramentas de software adequadas e outros.

A quantidade de linhas de código por PF varia bastante e com diversos fatores, além da linguagem de programação utilizada. Por exemplo, a antiga Tabela da SPR registrava a média de 53 SLOC/PF para a linguagem JAVA. A Tabela da QSM registra 63 SLOC/PF para o JAVA e o David Consulting Group sinaliza com 80 SLOC/PF. Em uma pesquisa realizada com 8 projetos JAVA em um banco brasileiro, a mediana encontrada foi 33 SLOC/PF. Nossa recomendação é que sejam medidos alguns projetos, para poder determinar o valor médio da razão SLOC/PF em cada caso específico.

RESUMINDO:

Análise de Pontos de Função (APF) é uma técnica para a medição de projetos de desenvolvimento de software, visando estabelecer uma medida de tamanho, em Pontos de Função (PF), considerando a funcionalidade implementada, sob o ponto de vista do usuário. A medida é independente da linguagem de programação ou da tecnologia que será usada para implementação.

Sob esse contexto, os objetivos da APF são:

* medir a funcionalidade solicitada pelo usuário, antes do projeto de software, de forma a estimar seu tamanho e seu custo;

* medir projetos de desenvolvimento e manutenção de software, independentemente da tecnologia utilizada na implementação, de forma a acompanhar sua evolução;

* medir a funcionalidade recebida pelo usuário, após o projeto de software, de forma verificar seu tamanho e seu custo, comparando-os com o que foi originalmente estimado;

As organizações podem aplicar a Análise de Pontos por Função como:

* uma ferramenta para determinar o tamanho de pacotes de software adquiridos, através da contagem de todos os Pontos por Função incluídos no pacote;

* uma ferramenta para apoiar a análise da qualidade e da produtividade;

* um mecanismo para estimar custos e recursos envolvidos em projetos de desenvolvimento e manutenção de software;

* um fator de normalização para comparação de software.

Para saber mais: flavio.falcao@gmail.com