Análise por Pontos de Função, APF

Pontos de Função são uma medida funcional de tamanho de software. A técnica foi introduzida em 1979 por Alan Albrecht, da IBM, e aberta à comunidade em 1984.

Uma medida funcional considera a funcionalidade solicitada e recebida pelos usuários. Nesse sentido, é uma medida externa, pois avalia o que é percebido pelos usuários do produto de software, independentemente da forma de implementação.

FPA significa Function Point Analysis. Em português, o termo pode ser traduzido como Análise por Pontos de Função ou Análise de Pontos de Função.

A contagem dos Pontos de Função é regulamentada pelo IFPUG, International Function Point Users Group, organização internacional sem fins lucrativos sediada nos Estados Unidos.

O IFPUG publica o Counting Practices Manual, CPM, que estabelece padrões para o cálculo dos Pontos de Função e mantém a certificação profissional na técnica.

O BFPUG, Brazilian Function Point Users Group, é a representação oficial do IFPUG no Brasil.

O CPM é fornecido pelo IFPUG. Filiados ao IFPUG podem fazer download conforme as regras da entidade. Não filiados podem adquiri-lo junto ao IFPUG.

A versão original do manual está em inglês. Há versões em outros idiomas, incluindo português.

A APF é usada na área de desenvolvimento de software como método para medir tamanho funcional. Ela não é, por si só, uma técnica de gerenciamento de projetos.

Mesmo assim, pode ser uma ferramenta útil para gerentes de projetos de software, pois a medição ajuda a dar visibilidade a requisitos, escopo, produtividade, qualidade, custo, esforço e estimativas.

A contagem considera cinco tipos de componentes de software: arquivos internos, arquivos externos, entradas, saídas e consultas. Esses termos têm significado específico na FPA, e sua identificação exige conhecimento especializado.

Os Pontos de Função são usados como fator normalizador do tamanho do software, permitindo métricas como produtividade, taxa de entrega, densidade de defeitos e outras.

Também é comum seu uso em contratos de fornecimento de software, seja por preço por ponto de função, seja por quantificação de serviços mediante medições.

Não. Embora exista relação entre o tamanho funcional de um software e o esforço de desenvolvimento, Pontos de Função não medem diretamente o esforço.

O tamanho em Pontos de Função é apenas um dos fatores que influenciam esforço e custo. Também influenciam plataforma, arquitetura, metodologia, testes, complexidade, reutilização, experiência da equipe, ferramentas e grau de confiabilidade requerido.

A contagem é feita com base na especificação do sistema, complementada por informações dos usuários e analistas.

Componentes considerados

• Arquivos Lógicos Internos: arquivos mantidos e utilizados pelo sistema contado.
• Arquivos de Interface Externa: arquivos utilizados pelo sistema contado, mas mantidos por outros sistemas.
• Entradas Externas: transações cujo objetivo é manter arquivos ou alterar o comportamento do sistema.
• Consultas Externas: transações que apresentam informações sem gerar dados derivados, atualizar arquivos ou usar cálculos.
• Saídas Externas: transações que apresentam informações, podendo gerar dados derivados, atualizar arquivos ou usar cálculos.

Etapas do processo

• Identificação: os componentes são identificados a partir de regras específicas.
• Complexidade e contribuição: cada componente recebe complexidade baixa, média ou alta e uma contribuição em Pontos de Função.
• Pontos de Função não ajustados: soma das contribuições dos componentes identificados.
• Pontos de Função ajustados: resultado após aplicação das Características Gerais dos Sistemas, quando aplicável.

A contagem pode medir diferentes situações, usando a mesma técnica, mas variando o que é considerado:

• Projeto de sistema: inclui o sistema entregue, modificações realizadas ao longo do projeto e programas necessários à implantação.
• Alteração em sistema: inclui componentes incluídos, alterados e removidos.
• Sistema: mede o tamanho funcional do sistema entregue aos usuários.

No passado, a SPR, Software Productivity Research, disponibilizava uma tabela de linguagens de programação com níveis e intervalos de produtividade estimados. A própria SPR retirou a tabela do ar e depois voltou a oferecê-la como serviço pago.

A linguagem de programação é apenas um dos fatores que afetam a produtividade. Também influenciam a confiabilidade requerida, metodologia, testes, complexidade dos algoritmos, plataforma, interface, reutilização, experiência da equipe, disponibilidade de ferramentas e outros fatores.

A quantidade de linhas de código por Ponto de Função varia bastante, inclusive dentro de uma mesma linguagem. Há tabelas históricas, como SPR e QSM, mas seus valores devem ser tratados apenas como referência.

A recomendação é medir alguns projetos da própria organização para determinar uma razão média SLOC/PF adequada ao contexto real.