Análise de Pontos de Função (APF)

Análise de Pontos de Função é um método para a medição de tamanho funcional de um software a partir da visão do usuário.

O que é medido?

A APF mede o software quantificando as tarefas e serviços (isto é, funcionalidade) que o software fornece ao usuário, primordialmente com base no projeto lógico. Os objetivos da análise de pontos de função são medir:

• A funcionalidade implementada no software, que o usuário solicita e recebe; 
• A funcionalidade impactada pelo desenvolvimento, melhoria e manutenção de software, independentemente da tecnologia utilizada na implementação.

Quais são as vantagens?

O processo de análise de pontos de função é:

•  Suficientemente simples para minimizar o custo adicional introduzido pelo processo de medição;
•  Uma medida consistente entre diversos projetos e organizações.

Aplicabilidade

A APF pode ser aplicado a todos os domínios funcionais. O IFPUG (International Function Point Users Group) publica constantemente artigos fornecendo orientações para a utilização do método em ambientes e domínios diferentes.

Os analistas de pontos de função do IFPUG identificaram diferentes taxas de entrega (horas para entregar um ponto de função) relacionadas à construção de aplicações em diferentes domínios funcionais, calibradas para diversos tamanhos de projeto e complexidade do software.

Existe uma organização, a ISBSG (International Software Benchmarking Standards Group), cuja missão é "manter um repositório público de métricas de projetos de software". Neste repositório existem informações de mais de 6.000 projetos de software de dezenas de países, o que possibilita a análise de produtividade, boas práticas, custos, etc., tudo organizado por domínio e tecnologias utilizadas.

Processo de Medição

Para conduzir uma contagem de pontos de função devem ser executadas as seguintes atividades, a fim de identificar e classificar os componentes funcionais básicos (ALI, AIE, EE, SE, CE):

a) Reunir a documentação disponível;

b) Determinar o escopo e a fronteira da contagem, identificando os Requisitos Funcionais do Usuário;

c) Medir as funções de dados;

d) Medir as funções de transação;

e) Calcular o tamanho funcional;

f) Documentar a contagem de pontos de função;

g) Reportar o resultado da contagem de pontos de função.

Reunir a documentação disponível

A documentação de suporte a uma contagem de pontos de função deve descrever a funcionalidade entregue pelo software ou a funcionalidade impactada pelo projeto de software medido.

Deve ser obtida documentação suficiente para conduzir a contagem de pontos de função, ou acesso a especialistas no assunto capazes de fornecer informações adicionais para suprir quaisquer falhas na documentação.

Geralmente, não há um único documento que resolva todas as necessidades de informação da medição; logo, o mais comum é que a medição seja feita com base na análise de mais de um tipo de documento.

Em geral, os itens a seguir são úteis quando se faz alguma medição de tamanho funcional:

• Documentos de requisitos

• Diagrama de entidades

• Modelos de objetos

• Modelos de dados

• Arquivo e esquemas banco de dados (com lógica, atributos necessários do usuário identificados)

• Acordos de Interface com descrições de entradas em lote/arquivos de transação e interfaces de/para outras aplicações

• Exemplos de relatórios, telas online e outras interfaces de usuário

• Demonstração da operação de aplicação

• Uma ou mais especialistas na aplicação (para a aplicação que está sendo medida)

• Um ou mais clientes/usuários de aplicação (passíveis de serem consultados durante o processo de medição)

• Guia de usuário, manual de treinamento e ajuda da aplicação

• Documentação do projeto do sistema

• Especificações funcionais

Determinar o escopo e a fronteira da contagem, identificando os Requisitos Funcionais do Usuário

Exemplo de Aplicação (Recursos Humanos):

Para determinar o escopo e fronteira da contagem e identificar os Requisitos Funcionais do Usuário, devem ser executadas as seguintes atividades:

a) Identificar o propósito da contagem

NOTA 1 Uma contagem de pontos de função é conduzida a fim de fornecer uma resposta para uma questão de negócio, sendo a questão de negócio que determina o propósito.

NOTA 2 O propósito da contagem determina o escopo da contagem.

EXEMPLO 1 O propósito da contagem poderia ser a determinação do tamanho de uma release de software específica.

EXEMPLO 2 O propósito da contagem poderia ser a determinação do tamanho de uma aplicação, como parte do esforço da organização para determinar o tamanho de seu portfolio de software.

b) Identificar o tipo de contagem, com base no propósito, como um dos seguintes:

c) Determinar o escopo da contagem, com base no propósito e tipo de contagem.

O escopo define quais funções serão incluídas na contagem, se ela abrangerá um ou mais sistemas ou apenas parte de um sistema. Por exemplo, você pode decidir se vai contar uma ou mais aplicações ou então apenas parte de uma aplicação. Além disso, pode abranger:

•  Todas as funcionalidades disponíveis;
•  Apenas as funcionalidades efetivamente utilizadas pelo usuário;
•  Apenas algumas funcionalidades específicas (relatórios, transações cadastrais, etc.).



d) Determinar a fronteira de cada aplicação contida no escopo da contagem com base na visão do usuário e não em considerações técnicas.

A fronteira é uma interface conceitual entre o software sob estudo e seus usuários. A fronteira (também chamada de fronteira da aplicação):

• Define o que é externo à aplicação;

• Indica a fronteira entre o software que está sendo medido e o usuário;

• Atua como uma ‘membrana’ através da qual os dados processados pelas transações (EEs, SEs e CEs) passam para dentro e para fora da aplicação;

• Envolve os dados lógicos mantidos pela aplicação (ALIs);

• Auxilia na identificação dos dados lógicos referenciados mas não mantidos pela aplicação (AIEs);

• Depende da visão externa do negócio do usuário da aplicação. É independente de considerações de técnicas e/ou implementação.

Um usuário é qualquer pessoa ou coisa que se comunica ou interage com o software a qualquer momento. Podem ser hardware, outras aplicações, outros sistemas, etc. Se um usuário fosse apenas uma Pessoa, não seria possível medir PFs para sistemas que não têm interface gráfica com o usuário.

A visão do usuário representa uma descrição formal das necessidades dos negócios do usuário, na linguagem do usuário. Os desenvolvedores traduzem a informação do usuário para informações em linguagem técnica a fim de prover uma solução.

• A visão do usuário:

• É uma descrição das funções do negócio;

• Pode ser feito por declaração verbal pelo usuário através de seu ponto de vista;

• É aprovada pelo usuário;

• Pode ser usada para medir o tamanho funcional;

• Pode variar na forma física (ex., catálogo de transações, propostas, documento de requisitos, especificações externas, especificações detalhadas, manuais do usuário).

EXEMPLO: Se o propósito for estimar o custo de uma melhoria nas aplicações de Recursos Humanos (RH) e Benefícios, então:

- o tipo de contagem é uma contagem de projeto de melhoria;

- o escopo deverá incluir as funções transacionais e de dados incluídas, alteradas ou excluídas referentes tanto à aplicação de RH quanto à de Benefícios, assim como quaisquer requisitos de conversão referentes a cada aplicação;

- a visão do usuário é que RH e Benefícios são áreas funcionais diferentes, por esse motivo são aplicações separadas;

- existe uma fronteira entre as aplicações de RH e de Benefícios, assim como entre cada aplicação e o usuário.

A visão do usuário pode ser materializar através de alguns artefatos ou insumos do projeto, tais como (exemplos):

• História de Usuário;

• Proposta de Projeto;

• Especificação de necessidades de negócio;

• Especificação de casos de uso;

• Protótipos de interface, etc.

e) Os requisitos do usuário podem incluir uma mistura de requisitos funcionais e não-funcionais; identificar quais requisitos são funcionais e excluir os não-funcionais.

Requisitos Funcionais são aqueles que capturam o que o software deve fazer em termos de tarefas e serviços. <<Ver o curso de Requisitos para exemplos de Requisitos Funcionais>>.

Requisitos não funcionais são restrições ou qualidades e características do sistema.

Hierarquia de classificação de requisitos segundo a norma ISO/IEC 14143:

Medir as funções de dados

Uma função de dados representa a funcionalidade fornecida ao usuário para atender suas necessidades internas e externas de armazenamento de dados.

Toda a funcionalidade de dados dentro do escopo da contagem deve ser avaliada para identificar cada grupo lógico de dados.

Uma função de dados pode ser um arquivo lógico interno ou um arquivo de interface externa.` O termo arquivo aqui não significa arquivo físico ou tabela. Nesse caso, arquivo se refere a um grupo de dados logicamente relacionados e não à implementação física destes grupos de dados. A chave é pensar em um modelo conceitual (entidades) e não no modelo lógico (tabelas).

Exemplo: mesmo que uma Entidade (BD) esteja distribuída entre várias tabelas devido a técnicas de normalização, o Arquivo Lógico ainda é um só.

Devem ser executadas as seguintes atividade para medir as funções de dados:

Podemos ainda mapear esses termos para a análise de pontos de função, conforme mostrado na seguinte matriz:

             Exemplos:

Medir as funções de transação

Uma função de transação é um processo elementar que fornece funcionalidade ao usuário para processamento de dados.

Toda a funcionalidade de transação dentro do escopo da contagem deve ser avaliada, a fim de identificar cada processo elementar único.

Uma função de transação pode ser uma entrada externa, saída externa ou consulta externa.

1) Identificar cada processo elementar requerido pelo usuário;

Processo elementar: menor unidade de atividade significativa para o usuário. Constitui uma transação completa, e é autocontida. Ao final de sua execução, deixa o negócio da aplicação em um estado consistente.

Por exemplo, os requisitos do usuário para adicionar um funcionário incluem informações de salário e dependentes. Um funcionário não terá sido criado se não forem incluídas todas as respectivas informações. Incluir separadamente apenas parte das informações deixará o negócio de incluir um funcionário em um estado inconsistente. Se forem incluídos tanto o salário do empregado quanto as informações do(s) dependente(s), a unidade de atividade será concluída e o negócio será deixado em um estado consistente.

EXEMPLO 1 Um Requisito Funcional do Usuário pode estabelecer que deve ser fornecida uma função para Manter Informações de Empregado. Esse requisito é decomposto em unidades de trabalho menores tais como Incluir Empregado, Alterar Empregado e consultar Empregado.

EXEMPLO 2 Os requisitos individuais podem estabelecer a necessidade de incluir diversos tipos de informações de empregado (por exemplo, endereço, salário e informações de dependentes), mas a menor unidade de atividade significativa para o usuário é Incluir Empregado.

2) Classificar cada processo elementar como uma função de transação de Entrada Externa (EE), Saída Externa (SE) ou Consulta Externa (CE);

Uma entrada externa (EE) é um processo elementar que processa dados ou informações de controle recebidas de fora da fronteira da aplicação. A intenção primária de uma EE é manter um ou mais ALIs e/ou alterar o comportamento do sistema.

O diagrama simplificado anterior mostra o processo de cadastrar um novo empregado na Aplicação de Recursos Humanos como um exemplo de uma Entrada Externa.

Um Processo Elementar deve ser classificado como Entrada Externa se o mesmo:

Em geral, o nome das transações de Entrada Externa possuem termos bem característicos, como incluir, alterar, excluir, editar, registrar, gravar, carregar, etc.

Exemplo de EE:

Uma saída externa (SE) é um processo elementar que envia dados ou informações de controle para fora da fronteira da aplicação e inclui processamento adicional além daquele existente em uma consulta externa. A intenção primária de uma saída externa é apresentar dados ao usuário através de lógica de processamento que não seja apenas recuperação de dados ou informação de controle. A lógica de processamento deve contar ao menos uma fórmula matemática ou cálculo, e/ou criar dados, e/ou manter um ou mais ALIs, e/ou alterar o comportamento do sistema.

O diagrama simplificado anterior mostra o processo de gerar um relatório que sumariza todos os empregados da Aplicação de Recursos Humanos como um exemplo de Saída Externa.

Um Processo Elementar deve ser classificado como Saída Externa se o mesmo tiver a intenção primária de apresentar informações ao usuário e incluir pelo menos uma das seguintes formas de lógica de processamento:

Exemplos de SE:

•  Relatórios com totalização de dados;
•  Relatórios que também atualizam arquivos;
•  Consultas com cálculos ou apresentação de dados derivados;
•  E outros...

Uma consulta externa (CE) é um processo elementar que envia dados ou informações de controle para fora da fronteira da aplicação. A intenção primária de uma consulta externa é apresentar dados ao usuário através de recuperação de dados ou informação de controle. A lógica de processamento não contém fórmula matemática, nem cálculo, nem cria dados derivados. Nenhum ALI é mantido durante o processamento, nem o comportamento do sistema é alterado.

O diagrama simplificado anterior mostra o processo de solicitar dados de empregado como um exemplo de Consulta Externa.

Um Processo Elementar deve ser classificado como Consulta Externa se o mesmo tiver a intenção primária de apresentar informações ao usuário e:

2) Não satisfizer os critérios para ser classificado como uma SE.

•  Drop-Downs, desde que recuperem dados de arquivos lógicos dinamicamente. Drop-Downs estáticos não são considerados.
•  Menus gerados dinamicamente de acordo com alguma configuração da aplicação.
  

A Tabela a seguir apresenta um resumo do relacionamento entre a intenção primária e o tipo de função de transação.

O tamanho funcional de cada função de transação será determinado utilizando-se o tipo e a complexidade funcional, de acordo com a tabela a seguir:

Calcular o tamanho funcional

A fórmula para calcular a contagem final de pontos de função depende do tipo de contagem.

O tamanho funcional de um projeto de desenvolvimento deverá ser calculado utilizando-se a Fórmula:

DFP = ADD + CFP*

Onde,

• DFP é a contagem de pontos de função do projeto de desenvolvimento;

• ADD é o tamanho das funções a serem entregues ao usuário pelo projeto de desenvolvimento;

• CFP é o tamanho da funcionalidade de conversão.

* São funções construídas e entregues pelo projeto (de desenvolvimento ou melhoria) para serem usadas no momento da instalação do projeto para converter dados ou fornecer outros requisitos de conversão especificados pelo usuário, como relatórios de verificação da conversão. A característica destas funções é que elas são descartadas após o seu uso, não fazendo parte da aplicação após sua instalação. Quando o sistema entra em operação, essas funções não são mais necessárias. Talvez um nome melhor para essas funções fosse "funções de transição".

Funções de conversão não são técnicas. São realizadas a partir do ponto de vista do usuário. Por exemplo, a migração de plataforma tecnológica não é contada como uma função de conversão.

Exemplo: ao instalar uma nova aplicação de RH, o usuário precisa que dados sejam migrados de uma outra aplicação legada e populados na nova aplicação.

O tamanho funcional de uma aplicação, medido após o projeto de desenvolvimento, ou a qualquer tempo no ciclo de vida da aplicação deverá ser calculado utilizando-se a fórmula a seguir:

AFP = ADD

Onde,

• AFP é a contagem de pontos de função da aplicação;

• ADD é o tamanho das funções a serem entregues ao usuário pelo projeto de desenvolvimento (excluído o tamanho de qualquer funcionalidade de conversão), ou a funcionalidade existente no momento da contagem da aplicação.

O tamanho funcional de um projeto de melhoria deverá ser calculado utilizando-se a fórmula a seguir:

EFP = ADD + CHGA + CFP + DEL

Onde,

• EFP é a contagem de pontos de função do projeto de melhoria;

• ADD é o tamanho das funções incluídas pelo projeto de melhoria;

• CHGA é o tamanho das funções alteradas pelo projeto de melhoria – conforme as mesmas estão / estarão após a implementação;

• CFP é o tamanho da funcionalidade de conversão;

• DEL é o tamanho das funções excluídas pelo projeto de melhoria.

Observações sobre o Fator de Ajuste: para adequar-se à norma ISO 14143 (medição do tamanho funcional), o IFPUG tornou o fator de ajuste opcional na aplicação da técnica de análise de pontos de função. Mesmo antes disso, vários usuários da APF já não utilizavam o fator de ajuste. O propósito do fator de ajuste é medir requisitos gerais da aplicação (não funcionais). Ele ajusta os pontos de função em + ou – 35% de acordo com a influência de 14 características gerais.

Fator de Ajuste

No cálculo de Pontos de Função brutos, ou não ajustados, NÃO são considerados aspectos técnicos ou baseados em requisitos não funcionais. Mesmo assim, é sabido que existem fatores não funcionais que afetam o "tamanho" da aplicação.

O Fator de Ajuste é uma tentativa de "compensar" ou "ajustar" alguns pontos de função na aplicação baseado em Características Gerais do Sistema que tentam refletir a complexidade do sistema. Estas características gerais afetam a aplicação como um todo e podem modificar a contagem de acordo com diversos "níveis de influência".

As 14 características gerais do sistema são:

1. Comunicação de Dados

2. Processamento Distribuído

3. Performance

4. Configuração Intensamente Utilizada

5. Volume de Transações

6. Entrada de Dados On-Line

7. Eficiência do Usuário Final

8. Atualização On-Line

9. Processamento Complexo

10. Reusabilidade

11. Facilidade de Instalação

12. Facilidade de Operação

13. Múltiplos Locais

14. Facilidade de Mudança

Com base nos requisitos estabelecidos pelo usuário, cada característica geral do sistema (CGS) deve ser avaliada em termos de seus níveis de influência (NI) em uma escala de 0 a 5.

Para diminuir a subjetividade, cada uma das descrições das características gerais do sistema seguintes inclui diretrizes para a determinação do nível de influência.

Cada diretriz contém uma definição da CGS, regras para determinação do nível de influência e, em situações nas quais a regra requer esclarecimento adicional, são fornecidas dicas para ajudar a aplicar as regras consistentemente em todas as plataformas.

Não se pretende que as dicas cubram todas as situações. Ao invés disso, a intenção é que as mesmas forneçam orientação adicional para a determinação do nível de influência apropriado.

Exemplo:

A característica Entrada de Dados On-line descreve os níveis segundo os quais os dados são informados ou recuperados através das transações interativas. Interfaces on-line com o usuário para entrada de dados, funções de controle, relatórios e consultas são fornecidos pela aplicação.

Neste caso, para a realidade das aplicações atuais, a grande maioria delas pontuará com 5. Percebe-se aqui uma grande defasagem nas diretrizes do IFPUG com a realidade atual.

Determinados os níveis de influência das 14 características gerais, o fator de ajuste é calculado com a seguinte fórmula:

VAF = (TDI x 0,01) + 0,65

Onde TDI é o somatório dos níveis de influência das características gerais (pode chegar a 70). Sendo assim, o fator de ajuste pode resultar numa variação de mais ou menos 35% na contagem de pontos de função.

Críticas ao Fator de Ajuste

Mesmo antes do Fator de Ajuste se tornar opcional, poucos usuários utilizavam-no. Algumas razões que levaram a isso: