Determinação de Pontos de Função

Prévia do material em texto

DESCRIÇÃO
Pontos de função como medida do tamanho de um software, independente de tecnologia, com base nos requisitos
funcionais.
PROPÓSITO
Medir o tamanho funcional de um software independente de tecnologia possibilita posterior cálculo da medida de esforço e
custo para desenvolver, melhorar ou adquirir o mesmo, conhecimento relevante ao profissional de desenvolvimento de
sistemas em geral, amparando ações gerenciais de planejamento de projetos.
OBJETIVOS
MÓDULO 1
Descrever o procedimento geral de contagem de pontos de função
MÓDULO 2
Calcular o fator de ajuste em pontos de função
MÓDULO 3
Empregar o fator de ajuste na contagem dos pontos de função ajustados
MÓDULO 4
Descrever como contabilizar as funções de dados e de transações
INTRODUÇÃO
Neste conteúdo, aprenderemos a aplicar a técnica denominada Análise de Pontos de Função (APF), que mede o tamanho
funcional de um software a ser desenvolvido, melhorado ou adquirido de terceiros. Com base nos requisitos funcionais do
software, a métrica não depende da tecnologia a ser empregada, por exemplo, da linguagem de programação utilizada na
implementação. Descreveremos o procedimento do IFPUG (International Function Point Users Group) para cálculo de pontos
de função.
Introduziremos a métrica, os seus fundamentos, finalidade e demonstraremos o procedimento de contagem de pontos de
função, explicando quais funcionalidades do software devem ser consideradas e como quantificá-las, no que chamaremos de
“pontos de função não ajustados”. Em um segundo momento, aprenderemos a importância e uso do “fator de ajuste de ponto
de função”. Na sequência, aprenderemos a calcular o “ponto de função ajustado”, como sendo uma relação entre “pontos de
função não ajustados” e “fator de ajuste”, variando conforme o tipo de contagem a ser aplicada: desenvolvimento ou melhoria
de software, ou aplicativo adquirido de terceiros. Por fim, veremos regras e conceitos de como identificar e calcular os
componentes das funcionalidades de dados e transações, que interessam na contagem.
MÓDULO 1
 Descrever o procedimento geral de cálculo de pontos de função
FUNDAMENTAÇÃO
A Análise de Pontos de Função (APF) ou cálculo de pontos de função é a métrica orientada a funções mais usada. Baseia-se
nas características de domínio do problema e na complexidade do software.
É uma técnica que tem por objetivo medir o que faz um software, sob a ótica das funcionalidades oferecidas a seus
usuários. A base da medição na APF são os requisitos do sistema, o que a torna uma técnica independente das tecnologias
usadas em sua construção, por exemplo, da linguagem de programação empregada, da eficiência dos algoritmos, do sistema
gerenciador de banco de dados, dentre outras.
A APF mede o que o software faz e não como ele foi construído. Por se basear nos requisitos, a APF consegue medir o
tamanho funcional nos momentos iniciais do processo de desenvolvimento, considerando que identificar os requisitos é tarefa
base para desenvolver sistemas.
Ponto de Função (PF) é a unidade de medida usada pela APF, a qual não mede diretamente esforço, produtividade ou custo
de um sistema, e sim o seu tamanho funcional, e pode ser usada na medição de qualquer tipo ou porte de sistema.
A seguir, conheça um pouco da história acerca da APF.
1970
A APF foi idealizada como alternativa às métricas baseadas em linhas de código (LOC, do inglês Lines of Code ), que
dependiam da tecnologia e tornavam inviável comparar produtividade de sistemas desenvolvidos em diferentes linguagens
de programação. Buscavam uma técnica que fosse independente da linguagem e da tecnologia empregadas. No final dos
anos 1970, a técnica foi apresentada à comunidade e, a partir daí, houve adesões a seu uso.
1986
Foi fundado o IFPUG (International Function Point Users Group), uma entidade sem fins lucrativos, formada por profissionais
e empresas de diversos países. Segundo o site da própria instituição: “A missão do International Function Point Users Group
é ser reconhecida como líder em promover e estimular a gestão eficaz das atividades de desenvolvimento e manutenção de
software de aplicação, fornecendo padrões de dimensionamento de software e outras técnicas de medição de software.”
(IFPUG, s.d.)
1998
Foi constituído o BFPUG (Brazilian Function Point Users Group), o capítulo Brasil do IFPUG, que visa promover troca de
experiência em APF entre seus membros (estudantes, desenvolvedores, consultores, gerentes e demais interessados).
CONCEITO DE USUÁRIO NA APF
Usuário é toda pessoa ou artefato que interaja com a aplicação, enviando dados ou recebendo informação.
 EXEMPLO
Um funcionário, um sistema, um hardware (como um leitor digital), atores em casos de uso, agentes do governo,
departamentos ou setores da corporação.
CONCEITO DE FUNCIONALIDADE NA CONTAGEM DE PONTOS
DE FUNÇÃO
Um requisito funcional representa uma necessidade de um ou mais usuários que se transforma em funcionalidades do
sistema para atender a essa necessidade. Um requisito funcional pode agregar uma ou mais funcionalidades do sistema.
 EXEMPLO
Um requisito: Diretor de uma fábrica de tijolos precisa que o sistema registre os horários de entrada e saída de cada
funcionário, diariamente, na fábrica.
Duas funcionalidades:
Registrar entrada de funcionário.
Registrar saída de funcionário.
Um requisito: Investidor precisa de um gráfico, com a variação do preço de uma ação na B3, no tempo gráfico
desejado.
Uma funcionalidade:
Plotar gráfico da ação no período desejado.
 
Foto: Shutterstock.com
PROCEDIMENTO DE CONTAGEM DE PONTOS DE
FUNÇÃO
O procedimento geral de medição de um sistema por APF, definido pelo IFPUG, diz que:
APF considera como base os requisitos funcionais.
Mede o software pela quantificação das tarefas e serviços (funcionalidades) que fornece ao usuário.
O procedimento de medição funcional do IFPUG compreende seis etapas, ilustradas a seguir:
 
Imagem: VAZQUEZ et al., 2013, p.48
 Etapas da medição funcional do IFPUG
Vamos explorar cada passo desse procedimento, sabendo que a identificação do “Propósito da contagem” conduz ao
restante do procedimento.
REUNIR A DOCUMENTAÇÃO DISPONÍVEL
Implica em reunir os documentos com especificações e modelos confeccionados durante o desenvolvimento ou a
manutenção do sistema. Em geral, não haverá um documento único que abranja as necessidades de informação para APF,
devendo-se reunir um conjunto mínimo disponível. A qualidade da medição depende do levantamento da documentação,
além da clareza e qualidade na declaração dos requisitos. Alguns documentos que podem ser usados:
Descrições dos requisitos do sistema.
Modelo de entidade e relacionamento (MER); na ausência deste, modelo lógico (relacional, objeto ou objeto-relacional), e na
ausência de ambos, modelo físico de dados.
Diagramas de fluxos de dados (DFD) e dicionário de dados (DD) em sistemas legados; diagramas e especificações de casos
de uso, em sistemas orientados a objetos.
Diagramas estruturais: classes ou componentes na ausência dos anteriores, para sistemas orientado a objetos.
Descrições procedurais, como processos de um DFD.
Layout de relatórios e telas.
Formulários usados para entrada de dados no sistema.
Manuais do sistema, do usuário, de operações, dentre outros.
 ATENÇÃO
Se não houver documentação suficiente para a contagem, deve-se prover esforço adicional para criá-la, demandando custos
adicionais.
Ao final desta etapa, deve-se ter em mãos, minimamente:
Uma lista não ambígua e clara dos requisitos funcionais e respectivas funcionalidades do sistema.
Identificação das funcionalidades que interessam à APF.
IDENTIFICAR DIRETRIZES DA CONTAGEM
Compreende os quatro passos a seguir.
IDENTIFICAR O PROPÓSITO DA CONTAGEM
Passo que vai nortear todas as demais atividades, além das premissas do procedimento de contagem. Dependendo do
propósito, a contagem pode ter mais ou menos detalhes. O propósito determina o tipo de contagem, influencia a identificação
do escopo,afeta os limites (fronteira) da aplicação, define os detalhes da contagem e indica se será uma estimativa (mais
rápida) ou uma contagem.
Os possíveis propósitos para aplicar APF são:
Projeto de desenvolvimento de software novo;
Projeto de melhoria do software (manutenção);
Aquisição de software ou componente de terceiros
IDENTIFICAR O TIPO DE CONTAGEM
De acordo com o propósito, teremos três tipos de contagem:
Desenvolvimento de um novo software: Mede a funcionalidade oferecida por uma versão instalada do software.
Devem ser consideradas, na contagem, as funcionalidades de importação/conversão de dados para o novo sistema.
Medições realizadas antes da 1ª versão do sistema são estimativas, pois os requisitos ainda podem mudar.
Melhoria de um software existente: Considera as funcionalidades adicionadas, modificadas e eliminadas do sistema,
bem como as de importação/conversão de dados. A contagem ocorre ao final das melhorias, quando a versão estiver
pronta. Factível apenas para a manutenção adaptativa, considerando que as corretivas e perfectivas são imprevisíveis.
Aquisição de uma aplicação: Servindo de base para comparações entre produtos concorrentes, de prateleira, que se
intencione adquirir de terceiros.
DETERMINAR O ESCOPO DA CONTAGEM
O escopo será determinado pelo propósito da contagem e definirá:
Subconjunto do sistema a ser medido:
Conjunto de requisitos funcionais
Conjunto de funções incluídas na contagem.
Pode envolver uma ou mais aplicações.
DETERMINAR A FRONTEIRA DA APLICAÇÃO
A fronteira determina o que está dentro e fora da aplicação. Os usuários estão fora, e o que está dentro será medido. Uma
má definição da fronteira, implicará contagem errada. Se o escopo considera a existência de mais de uma aplicação, existirá
mais de uma fronteira (uma por aplicação). O IFPUG especifica as seguintes regras para definir fronteiras:
Tomar por base o ponto de vista do usuário. O foco está no entendimento e descrição da interação usuário-sistema.
A separação das funções para delimitar a fronteira deve considerar o negócio e não a implementação física do sistema.
Em projetos de melhoria, considere a fronteira do projeto original
MEDIR FUNÇÕES DE DADOS
As funções de dados são as funcionalidades para armazenamento de dados ou informações de controle, podendo ser:
ARQUIVO LÓGICO INTERNO OU ALI
São grupos de dados, logicamente relacionados, conhecidos pelos usuários e armazenados pelo sistema, por uma ou mais
transações da aplicação. Exemplo: dados dos fornecedores em um sistema de contas a pagar.
ARQUIVO DE INTERFACE EXTERNA OU AIE
São grupos de dados, logicamente relacionados, conhecidos pelos usuários e armazenados fora da fronteira do sistema, ou
seja, por outras aplicações. Exemplo: Um sistema de contas a pagar pode usar o cadastro de fornecedores mantido pelo
sistema de compras. O AIE é, obrigatoriamente, ALI em outro sistema.
 DICA
O que chamamos de arquivo, no contexto da APF, não se refere a um arquivo de dados, a uma tabela de banco de dados ou
a uma entidade do modelo de dados. São dados logicamente relacionados e reconhecidos pelos usuários. Não se referem à
forma como os sistemas implementam fisicamente os dados, e sim como estão logicamente relacionados.
Na APF, os dois tipos de funções de dados, ALI e AIE, são contabilizados, e a maioria dos arquivos internos e externos estão
associados a transações de consulta, entrada e saída de dados, que serão contabilizadas à parte. ALI está dentro da
fronteira da aplicação e AIE está fora.
Identificamos as funções de dados ALI e AIE e apuramos a complexidade de cada uma, conforme dois parâmetros:
TIPO DE DADO (TD)
Um campo único, sem repetição, reconhecido pelo usuário.
javascript:void(0)
javascript:void(0)
javascript:void(0)
TIPO DE REGISTRO (TR)
São subgrupos de dados que compõem os arquivos (interno e externo).
Considere um cadastro de clientes, mantidos pelo sistema, contendo 25 campos de dados (nome, identidade, CPF,
nacionalidade...). Esse cadastro é um ALI com 25 campos e um tipo de registro. Consultando a tabela a seguir, apuramos
que tal função tem complexidade BAIXA.
Considere um arquivo, do sistema de Vendas (aplicação) com os pedidos de roupas de clientes; teremos dois tipos de
registros:
Dados gerais do pedido, com quatro campos (data, cliente, número e tipo).
Dados dos itens do pedido com três campos (nome do item, quantidade e valor unitário).
Esse arquivo é um AIE com dois tipos de registros (TR) e sete tipos de dados (TD). Consultando a tabela a seguir, apuramos
que a complexidade desse AIE é baixa.
Tipo de dados (campos ou TD)
Tipo de registro 1 a 19 20 a 50 51 ou mais
1 Baixa Baixa Média
2 a 5 Baixa Média Alta
6 ou mais Média Alta Alta
Tabela: Complexidade das funções de dados: Arquivo lógico interno (ALI) e Arquivo de interface externa (AIE).
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
MEDIR FUNÇÕES DE TRANSAÇÕES
As funções de transação correspondem às funcionalidades de processamento, fornecidas pelo sistema aos usuários,
podendo ser:
ENTRADA EXTERNA OU EE
É uma transação de entrada de dados ou informação de controle, que altera o estado interno dos dados do sistema. Tem por
objetivo manter ALIs e/ou alterar o comportamento do sistema. São transações típicas de inclusão, alteração e exclusão de
dados cadastrais, como clientes, fornecedores, dentre outros.
javascript:void(0)
javascript:void(0)
SAÍDA EXTERNA OU SE
É uma transação que remete dados ou informações de controle, para além da fronteira do sistema, ou seja, apresenta
informações ao usuário, sendo que ao menos um dado precisa ser processado ou calculado (dados derivados). Um exemplo
seria um relatório com os 10 produtos mais vendidos ou um relatório com total de vendas de cada produto.
CONSULTA EXTERNA OU CE
É uma transação que envia dados ou informações de controle para além da fronteira da aplicação. Apresenta ao usuário
dados previamente armazenados nos ALIs ou AIEs, pela simples recuperação (leitura) desses dados (sem qualquer
processamento).
Você pode estar se perguntando: qual é a diferença entre SE e CE?
A diferença entre SE e CE está na existência ou não de processamento dos dados lidos. Caso positivo, é uma SE; caso
contrário, é uma CE.
Identificamos as funções de transações EE, SE e CE, e apuramos a complexidade de cada uma, sendo a complexidade
dessas funções determinada por dois parâmetros:
TIPO DE DADO (TD)
Representa um campo único, sem repetição e reconhecido pelo usuário. Na prática, veremos que essa relação não é tão
exata.
ARQUIVOS REFERENCIADOS (AR)
Contabiliza todo ALI lido ou mantido ou AIE lido.
A tabela, a seguir, mostra como derivar a complexidade das funções de EE.
Tipo de dados (TD)
AR 1 a 4 5 a 15 16 ou mais
0 a 1 Baixa Baixa Média
2 Baixa Média Alta
3 ou mais Média Alta Alta
Tabela: Complexidade da função de transação chamada: Entrada externa (EE).
 Extraída de: IFPUG, s.d.
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
A próxima tabela mostra como derivar a complexidade para as funções de transação SE e CE.
Tipo de dados (TD)
AR 1 a 5 6 a 19 20 ou mais
0 a 1 Baixa Baixa Média
2 a 3 Baixa Média Alta
4 ou mais Média Alta Alta
Tabela: Complexidade das funções de transação chamada: Saída externa (SE) e Consulta externa (CE).
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
CALCULAR TAMANHO FUNCIONAL
A etapa 5 se desdobra em três passos:
CÁLCULO DOS PFS NÃO AJUSTADOS
Considera as complexidades das funcionalidades de dados e transações.
Cada tipo de contagem (projeto de desenvolvimento, de melhoria e aquisição de aplicação) possui uma fórmula específica
para determinar os PFs.
Depois de identificar a complexidade (baixa, média e alta) de cada função de transação e arquivo, conforme as respectivas
tabelas, pode-se obtero tamanho funcional do sistema (PF), aplicando os dados da tabela a seguir:
Complexidade e tamanho funcional (PF)
Tipo de função Baixa Média Alta
Entrada externa (EE)
Consulta externa (CE)
3 4 6
Saída externa (SE) 4 5 7
Arquivo lógico interno (ALI) 7 10 15
Arquivo de interface externa (AIE) 5 7 10
Tabela: Complexidade x Pontos de função de cada tipo de função de dado e transação.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
O número de pontos de função não ajustados do sistema será a soma de todos os pontos de função não ajustados obtido
para cada funcionalidade considerada na contagem.
FATOR DE AJUSTE (OPCIONAL, PELO IFPUG)
O fator de ajuste (FA) é um valor que será aplicado aos pontos de função não ajustados, e que objetiva avaliar 14
características gerais que se aplicam aos requisitos funcionais. Ajusta os pontos de função não ajustados na ordem de mais
ou menos 35%.
CALCULAR PONTOS DE FUNÇÃO AJUSTADOS (FATOR DE AJUSTE
DIFERENTE DE 1) 
É o resultado da aplicação do fator de ajuste sobre os pontos de função não ajustados. No módulo 2, aprenderemos a
calcular o fator de ajuste (VFA), e no módulo 3, a calcular PF ajustado, conforme o propósito da contagem.
DOCUMENTAR E REPORTAR
Ao informar a contagem em PF, é preciso apresentar dados da memória de cálculo, para que a pessoa conheça como cada
elemento contribuiu na contagem.
O nível de detalhamento da documentação pode variar e depende do propósito da contagem, do tamanho e da complexidade
do sistema. Além disso, deve ser acordado entre as partes.
 ATENÇÃO
Um ponto importante na listagem de funções é a disposição delas no documento, impactando o entendimento. É comum
haver a separação das funções de conversão na listagem, e o seu agrupamento cabe ao analista responsável pela APF,
sendo os critérios: ordem alfabética, agrupamento lógico, agrupamento por complexidade, agrupamento das funções de
dados e transações e outros critérios.
ANÁLISE DE PONTOS DE FUNÇÃO: FUNDAMENTOS E
PROCEDIMENTO GERAL DE CONTAGEM
Assista ao vídeo sobre os fundamentos da APF e o procedimento geral de cálculo, de acordo com os preceitos do IFPUG.
VERIFICANDO O APRENDIZADO
1. A APF SURGE COM A NECESSIDADE DE AVALIAR PRODUTIVIDADE EM PROGRAMAS
ESCRITOS EM DIFERENTES LINGUAGENS DE PROGRAMAÇÃO. SEU PRINCIPAL OBJETIVO É
MEDIR O TAMANHO FUNCIONAL DE UM SISTEMA, COM BASE EM SEUS REQUISITOS
FUNCIONAIS. AVALIE AS ASSERTIVAS: 
 
É DEPENDENTE DE TECNOLOGIA, ESPECIALMENTE DE LINGUAGENS DE PROGRAMAÇÃO
ESTÁ PAUTADA NA VISÃO DO USUÁRIO, COMO ELE ENXERGA AS FUNCIONALIDADES.
OS CÁLCULOS SÃO PAUTADOS EM FUNCIONALIDADES DE TRANSAÇÕES E DE
MANUTENÇÃO DOS ARQUIVOS LÓGICOS DE DADOS.
É UMA TÉCNICA SUBJETIVA.
 
COM BASE EM SUA ANÁLISE, ASSINALE A ALTERNATIVA QUE APRESENTA TODAS AS
ASSERTIVAS VERDADEIRAS:
A) I e II
B) I, II e III
C) II, III e IV
D) IV
E) II e IV
2. CONSIDERE A TABELA A SEGUIR COMO RESULTADO DA CONTAGEM DE PF DE UM SISTEMA
BANCÁRIO. 
FUNÇÃO
QUANTIDADE DE FUNCIONALIDADES
BAIXA MÉDIA ALTA
ALI 1 1 1
AIE 1 1 1
EE 1 1 1
SE 1 1 1
CE 1 1 1
TABELA: CONTAGEM DE PF
 ELABORADA POR: MARCELO VASQUES DE OLIVEIRA
 ATENÇÃO! PARA VISUALIZAÇÃO COMPLETA DA TABELA UTILIZE A ROLAGEM
HORIZONTAL
 
QUANTOS PF POSSUI ESSE SISTEMA?
A) 95
B) 99
C) 106
D) 109
E) 116
GABARITO
1. A APF surge com a necessidade de avaliar produtividade em programas escritos em diferentes linguagens de
programação. Seu principal objetivo é medir o tamanho funcional de um sistema, com base em seus requisitos
funcionais. Avalie as assertivas: 
 
É dependente de tecnologia, especialmente de linguagens de programação
Está pautada na visão do usuário, como ele enxerga as funcionalidades.
Os cálculos são pautados em funcionalidades de transações e de manutenção dos arquivos lógicos de dados.
É uma técnica subjetiva.
 
Com base em sua análise, assinale a alternativa que apresenta TODAS as assertivas VERDADEIRAS:
A alternativa "C " está correta.
 
A técnica APF independe de tecnologia, o que configura uma de suas vantagens. Baseia-se nos requisitos funcionais do
sistema, que derivam da visão e necessidades dos usuários, e considera os dados do sistema, que podem estar dentro (ALI)
ou fora (AIE) da fronteira. É considerada uma técnica subjetiva justamente por refletir a visão do usuário.
Logo estão corretas apenas II, III e IV.
2. Considere a tabela a seguir como resultado da contagem de PF de um sistema bancário. 
Função
Quantidade de funcionalidades
Baixa Média Alta
ALI 1 1 1
AIE 1 1 1
EE 1 1 1
SE 1 1 1
CE 1 1 1
Tabela: Contagem de PF
 Elaborada por: Marcelo Vasques de Oliveira
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
 
Quantos PF possui esse sistema?
A alternativa "A " está correta.
 
Converta cada complexidade simples, média ou baixa de cada função da tabela, na quantidade de pontos de função. Some
os PF de cada um. O resultado será a contagem de PF dessa aplicação.
Função
Pontos de função
Baixa Média Alta
ALI 7 10 15
AIE 5 7 10
EE 3 4 6
SE 3 5 7
CE 3 4 6
TOTAIS 21 30 44
Tabela: Resolução - Contagem de PF
 Elaborada por: Marcelo Vasques de Oliveira
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
A soma de todos os PF é (21 + 30 + 44) = 95 PF
MÓDULO 2
 Calcular o fator de ajuste em pontos de função
CONSIDERAÇÕES SOBRE O FATOR DE AJUSTE DE
PONTOS DE FUNÇÃO
O uso do fator de ajuste tornou-se opcional em 2002, quando o mercado aceitou o método do IFPUG como padrão. O valor
do fator e ajuste (VFA) é determinado pela avaliação de 14 características gerais de sistema (CGS), conforme descrito na
tabela a seguir:
1. Comunicação de dados 8. Atualização on-line
2. Processamento distribuído 9. Complexidade do processamento
3. Performance 10. Reusabilidade
4. Configuração altamente utilizada 11. Facilidade de instalação
5. Volume de transações 12. Facilidade de operação
6. Entrada de dados on-line 13. Múltiplos locais
7. Eficiência de usuário final 14. Facilidade de mudanças
Tabela: Características gerais de sistema.
 Extraído de IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Cada CGS afeta o sistema com maior ou menor influência, resultando numa nota de 0 a 5, conforme a próxima tabela:
Pontuação Influência exercida
0 Nenhuma
1 Mínima
2 Moderada
3 Média
4 Significativa
5 Grande
Tabela: Pontuação das características gerais de sistema.
 Extraído de IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
O cálculo do fator é subjetivo. O que seria considerada mínima? Qual é a diferença para a influência moderada?
Para minimizar essa dificuldade de classificação, o IFPUG fornece as diretrizes que estudaremos adiante.
PROCEDIMENTO PARA CALCULARMOS O VALOR DO FATOR
DE AJUSTE (VFA)
PASSO 1
Determinar os níveis de influência das 14 CGS.

PASSO 2
Calcular o fator de ajuste.
O cálculo do fator de ajuste é realizado com a fórmula:
VFA 
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Observe que TDI é a soma de todos os níveis de influência das CGS.
Analisando a fórmula de cálculo do VFA, observamos que:
Cada ponto atribuído ao nível de influência interfere 1% (0,01) no resultado.
O fator pode variar de 0,65 a 1,35, ou seja, de -35% a +35%.
APLICANDO O PROCEDIMENTO DE CÁLCULO DO VFA
Vejamos o exemplo de um sistema com 500 PFs não ajustados e as seguintes pontuações para as CGS.
CGS Pontos
Comunicação de dados 5
Processamento distribuído 3
Performance 4
Configuração altamente utilizada 2
Volume de transações 5
Entrada de dados on-line 3
Eficiência de usuário final 3
Atualização on-line 3
Complexidade do processamento 5
Reusabilidade 5
Facilidade de instalação 5
Facilidade de operação 5
Múltiplos locais 0
Facilidade de mudanças 3
Total pontos 51
Tabela: Pontos de influência das CGS em sistema.
 Elaborada por: Marcelo Vasques de Oliveira. Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Aplicando a fórmula do passo 2, temos:
VFA = (51 × 0,01) + 0,65 = 0,51 + 0,65 = 1,16
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
 
Imagem: Shutterstock.com
DIRETRIZES DO IFPUG PARA DETERMINAR O NÍVEL DE
INFLUÊNCIA DAS CGS
COMUNICAÇÃO DE DADOS
Avalia o nível com que necessidades especiais de comunicação afetam o sistema. Os sistemas stand alone estão no nível
inferior do limite de variação. Já os sistemas que trocam informações, usando diferentes protocolos, estão no mais alto nível
de avaliação.
Pontos Diretrizes
0 Aplicação roda em BATCH ou estação de trabalho isolado (stand alone ).
1 Aplicação roda em BATCH, mas tem entrada ou saída remota.
2 Aplicação roda em BATCH, mas tem entrada de dados e saída remota.
3 Há coleta de dados on-line ou front-end de teleprocessamento em sistema BATCH ou de consulta.
4 A aplicação é superior a um front-end , contudo, suporta APENAS 1 de protocolo de comunicação.
5 A aplicação é superior a um front-end e suporta MAIS de 1 de protocolo de comunicação.
Tabela: CGS: Comunicação de dados.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considerações:
Poucas aplicações, atualmente, pontuariam menos de 2 ou 3 (não rodam em BATCH).
Aplicações cliente-servidor com 2 camadas pontuam 4.
Em aplicações de tempo real, servidores de aplicação tendem a pontuar 5.
PROCESSAMENTO DISTRIBUÍDO
Descreve o nível com que a aplicação usa dados distribuídos. Sistemas que armazenam dados no mesmo local ou que
precisam distribuir dados, mas não automatizam o procedimento, estão no nível inferior da avaliação. No nível máximo, estão
as aplicações que distribuem o processamento de forma dinâmica entre diferentes locais (nodos).
Pontos Diretrizes
0 A aplicação não armazena dados ou processa funções entre os componentes do sistema.
1
Os dados para processamento pelo usuário final são preparados em outro componente do sistema, por
exemplo, em planilhas.
2
A aplicação prepara previamente dados para transferência, em determinado local, que são processados
em outro componente (sem ser pelo usuário final).
3 Há, na aplicação, processamento distribuído e transferência de dados on-line e numa direção específica.
4 Há, na aplicação, processamento distribuído e transferência de dados on-line e nas 2 direções.
5 Há processamento dinâmico das funções, no componente mais indicado da aplicação.
Tabela: CGS: Processamento distribuído.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considerações:
Uma aplicação rodando em desktop isolado pontuará zero.
Uma aplicação de N camadas pontuará 4.
Uma aplicação com componentes executando em múltiplos servidores ou processadores, selecionado dinamicamente pela
disponibilidade, pontuará 5.
Aplicações cliente-servidor com 2 camadas pontuarão 4.
PERFORMANCE
Avalia o quanto itens de performance, como tempo de resposta e taxa de transações no tempo, influenciaram no projeto e no
desenvolvimento da aplicação.
Pontos Diretrizes
0 Não há especificação de qualquer requisito especial sobre performance, pelo usuário.
1 Houve definição de requisitos de performance e projeto, que não carece de uma ação especial.
2
Há criticidade no tempo de resposta e taxa de transações nos momentos de pico. Não demanda ação
específica para a utilização de CPU.
3
Há criticidade nos requisitos tempo de resposta e taxa de transações no horário comercial. Não demanda
qualquer ação específica para a utilização de CPU.
4
Requisitos especificados pelo usuário demandam que tarefas de análise de performance sejam aplicados
na fase de projeto na aplicação.
5
Ferramentas de análise de performance devem ser utilizadas nas fases de projeto, desenvolvimento e/ou
implementação, atendendo requisitos de performance do usuário.
Tabela: CGS: Performance.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
CONFIGURAÇÃO DO EQUIPAMENTO
Avalia o quanto recursos de processamento afetam o projeto do sistema.
Pontos Diretrizes
0 Os requisitos não demandam restrições operacionais.
1 Existem restrições operacionais típicas. Não demanda esforço adicional.
2 Algumas considerações de sincronismo ou segurança são especificadas.
3 Existem requisitos de processador para uma parte específica da aplicação.
4
Há restrições operacionais claras que demandam um processador dedicado ou uso intenso do
processador central.
5 Existem restrições em relação aos componentes distribuídos da aplicação.
Tabela: CGS: Configuração altamente utilizada.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considerações:
Em geral, a grande maioria dos sistemas pontua 0 ou 1.
Aplicações científicas ou de engenharia com grande exigência de processamento pontuam de 3 a 5.
VOLUME DE TRANSAÇÕES (OU TAXA DE TRANSAÇÕES)
Mede o quanto o alto volume de transações, em um período, afeta o projeto da aplicação.
Pontos Diretrizes
0 Não é antecipado nenhum período de pico de transações.
1 Existem momentos de pico de processamento (por exemplo: mensal, quinzenal, periódico, anual).
2 Picos de transação regulares (exemplo: semanais) são previstos.
3 Altos volumes de transações são previstos, impactando o projeto.
4
Altas taxas de transação nos requisitos ou os níveis de serviço acordados são altos o bastante para
demandarem tarefas de análise de performance no projeto.
5
Existem demandas de ferramentas de análise de performance no projeto, desenvolvimento e/ou
instalação da aplicação.
Tabela: CGS: Volume de transação.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
ENTRADA DE DADOS ON-LINE
Mede o nível de entrada interativa de dados, on-line, demandado pela aplicação.
Pontos Diretrizes
0 Todas as transações são processadas em lote.
1 De 1% a 7% das entradas de dados são interativas.
2 De 8% a 15% das entradas de dados são interativas.
3 De 16% a 23% das entradas de dados são interativas.
4 De 24% a 30% das entradas de dados são interativas.
5 Mais de 30% das entradas de dados são interativas.
Tabela: CGS: Entrada de dados on-line.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considerações:
A maioria das aplicações, atualmente, pontuam 5.
EFICIÊNCIA DO USUÁRIO FINAL
Mede o quanto a preocupação com facilidade de uso e demais fatores de usabilidade influenciaram o desenvolvimento da
aplicação. O projeto deve incluir os seguintes itens de eficiência: auxílio para navegação (teclas de atalho, menus dinâmicos),
menus, ajuda on-line e documentação, movimentação automática de cursor, paginação, impressão remota, interface de
mouse, janela pop-up , suporte a idiomas (conta como 4 itens), suporte a mais de 1 idioma (conta como 6 itens).
Pontos Diretrizes
0 Nenhum dos itens de eficiência mencionados se aplica.
1 De 1 a 3 itens de eficiência mencionados se aplicam.
2 De 4 a 5 itens de eficiência mencionados se aplicam.
3 6 ou mais dos itens, mas não existem requisitos específicos do usuário associados à eficiência.
4
6 ou mais dos itens se aplicam, porém foram requisitados pelos usuários que demandam tarefas de
projeto, que incluam fatores humanos na aplicação.
5
6 ou mais dos itens se aplicam, porém foram requisitados pelos usuários que demandam ferramentas e
processos especiais, demonstrando o alcance dos objetivos.
Tabela: CGS: Eficiência do usuário final.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considerações:
Algumas dessas diretrizes estão defasadas para as propriedades das aplicações atuais.
Aplicações BATCH ou servidora não possuem interação usuário-sistema e pontuam 0.
Aplicações interativas pontuam de 3 a 5.
ATUALIZAÇÃOON-LINE
Descreve o nível de atualização dos ALIs de forma on-line.
Pontos Diretrizes
0 Não há atualização on-line.
1 Atualização on-line de 1 a 3 arquivos, com baixo volume e fácil recuperação.
2 Atualização on-line de 4 ou mais arquivos, com baixo volume e fácil recuperação.
3 Atualização da maioria dos ALIs são on-line.
4
Atualização da maioria dos ALIs são on-line. Houve preocupação com a perda de dados, projetada e
programada.
5
Atualização da maioria dos ALIs são on-line. Inclusão de mecanismos automatizados de recuperação de
dados, com mínima participação do usuário.
Tabela: CGS: Atualização on-line.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considerações:
Algumas das diretrizes estão defasadas para os dias de hoje.
As aplicações atualmente pontuam, se não for BATCH, pelo menos 3. A maioria das aplicações pontuam 4 ou 5.
COMPLEXIDADE DE PROCESSAMENTO
Para que a lógica de processamento seja complexa, avalia-se os seguintes itens:
Controle sensível e/ou processamento de segurança da aplicação.
Processamento lógico extensivo, como sistemas bancários.
Processamento matemático extensivo, como sistemas de cálculos de seguros.
Muitos processamentos de exceção, que resultam em transações incompletas, que necessitam de novo
processamento, por exemplo, transações incompletas em caixas eletrônicos.
Processamento para manipular múltiplas possibilidades de entrada e saída, por exemplo, multimídia.
Pontos Diretrizes
0 Não há processamento complexo.
1 Há 1 dos itens de processamento complexo.
2 Há pelo menos 2 dos itens de processamento complexo.
3 Há pelo menos 3 dos itens de processamento complexo.
4 Há pelo menos 4 dos itens de processamento complexo.
5 Há todos os itens de processamento complexo.
Tabela: CGS: Processamento complexo.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
REUSABILIDADE
Avalia-se o quanto de planejamento e desenvolvimento houve para que o código da aplicação possa ser usado em outras
aplicações.
Pontos Diretrizes
0 A aplicação não reutiliza código nem viabiliza que outras aplicações reutilizem os seus.
1 Há reutilização de código na aplicação.
2 Menos de 10% do código foi construído para uso em outras aplicações.
3 10% ou mais do código foi construído para uso em outras aplicações.
4 Aplicação é customizável pelo usuário ao nível de código e possui fácil reutilização.
5 A aplicação é customizável pelo usuário por meio de manutenção de parâmetros.
Tabela: CGS: Reusabilidade.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considerações:
Critério subjetivo e difícil de avaliar sem documentação da aplicação ou código fonte.
FACILIDADE DE INSTALAÇÃO
Deve-se responder e avaliar, partindo da premissa: “um plano ou ferramentas de conversão e instalação foram fornecidos e
testados durante a fase de teste da aplicação”?
Pontos Diretrizes
0 Não houve preocupação com implantação e o usuário não definiu nada nesse sentido.
1 É necessário um setup para instalação, embora o usuário não tenha definido nada nesse sentido.
2
Requisitos de instalação e conversão foram definidos pelo usuário, bem como fornecidos e testados os
respectivos programas, apesar do impacto da conversão não ser relevante.
3 Requisitos de instalação e conversão foram definidos pelo usuário, bem como fornecidos e testados os
respectivos programas, e o impacto da conversão é relevante.
4
Requisitos de instalação e conversão foram definidos pelo usuário, bem como fornecidos e testados os
respectivos programas, apesar do impacto da conversão não ser relevante. As ferramentas de conversão
e instalação são automáticas.
5
Requisitos de instalação e conversão foram definidos pelo usuário, bem como fornecidos e testados os
respectivos programas, e o impacto da conversão é relevante. As ferramentas de conversão e instalação
são automáticas.
Tabela: CGS: Facilidade de manutenção.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considerações:
Atualmente, os procedimentos de conversão e instalação são automáticos e com pouca intervenção humana, pontuando de 3
a 5.
FACILIDADE DE OPERAÇÃO
Avalia em que grau a aplicação realiza procedimentos automáticos de backup, recuperação de falhas e inicialização.
Pontos Diretrizes
0 Usuário não estabeleceu nenhum procedimento, a não ser os normais de segurança.
1 a 4
Cada item abaixo vale 1 ponto. Um, alguns ou todos os itens são válidos.
Procedimentos de inicialização, salvamento e recuperação foram fornecidos, mas é necessária a
intervenção do operador.
Procedimentos de inicialização, salvamento e recuperação foram fornecidos, não é necessária a
intervenção do operador – conte como 2 itens.
A aplicação minimiza a necessidade de montagem de mídias de backup.
A aplicação minimiza a necessidade de manipulação de papel.
5 Não é necessária nenhuma intervenção do operador, a não ser inicialização e término da aplicação, que
tem recuperação automática de erros.
Tabela: CGS: Facilidade de operação.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considerações:
Para aplicações nas quais não haja operador e apenas usuário, pontua 5.
MÚLTIPLOS LOCAIS
Descreve em que nível a aplicação foi construída para operar em diferentes plataformas de hardware ou software.
Pontos Diretrizes
0 Os requisitos não definiram a necessidade de mais de um usuário e local de instalação.
1 Foi apurada a necessidade de múltiplos locais e a aplicação programada para os mesmos locais.
2 Foi apurada a necessidade de múltiplos locais e a aplicação programada para locais similares.
3 Há necessidade de a aplicação rodar em múltiplos locais (hardware e software).
4
Considere o descrito acima, referente aos pontos 1 e 2. Além deles, a aplicação forneceu planos de
suporte e documentação para aplicação em múltiplos locais.
5
Considere o descrito acima referente aos pontos do item 3. Além deles, a aplicação forneceu planos de
suporte e documentação para aplicação em múltiplos locais.
Tabela: CGS: Múltiplos locais.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considerações:
Ambientes de software similares: diferentes versões softwares da família Windows.
Ambiente de hardware similares: computadores com diferentes processadores da família Intel.
FACILIDADE DE MUDANÇAS
Descreve o nível de facilidade com que mudanças em seu código ou em suas estruturas de dados podem ser realizadas.
Avaliar:
CONSULTA FLEXÍVEL
O usuário pode montar consultas, escolhendo os dados disponíveis.
DADOS DE CONTROLE
Manutenção de parâmetros do sistema, on-line, ajustando dados contidos em tabelas.
Pontos Diretrizes
0 Aplicação não possui nenhum dos aspectos acima.
1 Aplicação contempla qualquer um dos aspectos acima.
2 Aplicação contempla 2 dos aspectos acima.
3 Aplicação contempla 3 dos aspectos acima.
4 Aplicação contempla 4 dos aspectos acima.
5 Aplicação contempla todos os 5 aspectos acima.
Tabela: CGS: Facilidade de mudanças.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Considere se a aplicação possuir os seguintes aspectos:
Consulta flexível, com manipulação de pedidos simples (lógica aplicada a único arquivo) — compute 1 item.
Consulta flexível, com manipulação de pedidos médio complexos (lógica aplicada a mais de um arquivo) — compute 2 itens.
javascript:void(0)
javascript:void(0)
Consulta flexível, com manipulação de pedidos complexos (lógica aplicada e combinada a mais de um arquivo) — compute 3
itens.
Dados de controle por processos interativos, mas o efeito das alterações acontece somente no dia seguinte — compute 1
item.
Dados de controle, por processos interativos, e o efeito das alterações é imediato — compute2 itens.
FATOR DE AJUSTE DE PONTOS DE FUNÇÃO
Assista ao vídeo sobre o significado do fator de ajuste, o porquê de não ser mais adotado pelo IFPUG e sua forma de
cálculo.
VERIFICANDO O APRENDIZADO
1. CONSIDERE A SEGUINTE PONTUAÇÃO DAS CGS (CARACTERÍSTICAS GERAIS DO SISTEMA)
QUE FORAM ADERENTES A UM SISTEMA DE CONTROLE DE PONTO DE FUNCIONÁRIOS,
PERFAZENDO UM TDI (SOMA DE TODOS OS NÍVEIS DE INFLUÊNCIA DAS CGS) DE 45 PONTOS. 
CGS PONTOS
COMUNICAÇÃO DE DADOS 5
PROCESSAMENTO DISTRIBUÍDO 4
PERFORMANCE 4
CONFIGURAÇÃO DO EQUIPAMENTO 2
VOLUME DE TRANSAÇÕES 5
ENTRADA DE DADOS ON-LINE 4
EFICIÊNCIA DE USUÁRIO FINAL 3
ATUALIZAÇÃO ON-LINE 3
COMPLEXIDADE DO PROCESSAMENTO 5
REUSABILIDADE 5
FACILIDADE DE OPERAÇÃO 5
TOTAL PONTOS 45
TABELA: NÍVEIS DE INFLUÊNCIA DAS CGS.
 ELABORADA POR: MARCELO VASQUES DE OLIVEIRA
 ATENÇÃO! PARA VISUALIZAÇÃO COMPLETA DA TABELA UTILIZE A ROLAGEM
HORIZONTAL
 
QUAL O VALOR DO FATOR DE AJUSTE (VFA)?
A) 2,1
B) 0,1
C) 1,1
D) -0,20
E) 45,65
2. AVALIE AS ASSERTIVAS A SEGUIR, NO QUE SE REFERE AO CÁLCULO DO VALOR DO FATOR
DE AJUSTE (VFA). LEMBRANDO QUE O TDI É SOMA DE TODOS OS NÍVEIS DE INFLUÊNCIA DAS
CGS (CARACTERÍSTICAS GERAIS DO SISTEMA). SABE-SE AINDA QUE: PFA = VFA * PFNA,
ONDE PFA = PONTOS DE FUNÇÃO AJUSTADO E PFNA = PONTOS DE FUNÇÃO NÃO AJUSTADO. 
 
SE TDI = 35  FATOR DE AJUSTE = 1 E NÃO INFLUENCIARÁ NA CONTAGEM DE PFS
AJUSTADOS (PFA)
SE TDI > 35, O FATOR DE AJUSTE > 1 E A CONTAGEM DOS PFS AJUSTADOS (PFA) SERÁ
SUPERIOR A CONTAGEM DOS PFS NÃO AJUSTADOS (PFNA)
SE TDI < 35 O FATOR DE AJUSTE < 1 E A CONTAGEM DOS PFS AJUSTADOS (PFA) SERÁ
SUPERIOR A CONTAGEM DOS PFS NÃO AJUSTADOS (PFNA)
 
ESTÃO CORRETAS APENAS:
A) I e II
B) I, II e III
C) I
D) II
E) I e III
GABARITO
1. Considere a seguinte pontuação das CGS (Características Gerais do Sistema) que foram aderentes a um sistema
de controle de ponto de funcionários, perfazendo um TDI (soma de todos os níveis de influência das CGS) de 45
pontos. 
CGS Pontos
Comunicação de dados 5
Processamento distribuído 4
Performance 4
Configuração do equipamento 2
Volume de transações 5
Entrada de dados on-line 4
Eficiência de usuário final 3
Atualização on-line 3
Complexidade do processamento 5
Reusabilidade 5
Facilidade de operação 5
Total pontos 45
Tabela: Níveis de influência das CGS.
 Elaborada por: Marcelo Vasques de Oliveira
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
 
Qual o valor do fator de ajuste (VFA)?
A alternativa "C " está correta.
 
VFA = (TDI x 0,01) + 0,65
TDI = 45
VFA = (45 * 0,01) + 0,65 = 1,1
2. Avalie as assertivas a seguir, no que se refere ao cálculo do valor do fator de ajuste (VFA). Lembrando que o TDI é
soma de todos os níveis de influência das CGS (Características Gerais do Sistema). Sabe-se ainda que: PFA = VFA *
PFNA, onde PFA = pontos de função ajustado e PFNA = pontos de função não ajustado. 
 
Se TDI = 35  fator de ajuste = 1 e não influenciará na contagem de PFs ajustados (PFA)
Se TDI > 35, o fator de ajuste > 1 e a contagem dos PFs ajustados (PFA) será superior a contagem dos PFs não
ajustados (PFNA)
Se TDI < 35 o fator de ajuste < 1 e a contagem dos PFs ajustados (PFA) será superior a contagem dos PFs não
ajustados (PFNA)
 
Estão corretas APENAS:
A alternativa "A " está correta.
 
Vamos analisar cada assertiva a luz da fórmula de cálculo do VFA (valor do fator e ajuste), que é VFA = (TDI x 0,01) + 0,65
TDI, sendo 35, o VFA será (35 * 0,01) + 0,65 = 1 e não influenciará na contagem de pontos de função, pois PFA = VFA *
PFNA, ou seja, PFA = 1 * PFNA  VERDADEIRO
II. TDI > 35, o VFA será maior que 1 e PFA > PFNA  VERDADEIRO
TDI < 35, o VFA será menor que 1 e PFA < PFNA  FALSO
MÓDULO 3
 Empregar o fator de ajuste na contagem dos pontos de função ajustados
FUNÇÃO DE AJUSTE
Aprendemos a calcular os pontos de função não ajustados e o valor do fator de ajuste (VFA). Resta-nos aprender a calcular o
tamanho funcional final da aplicação, conforme o tipo de contagem: projeto de desenvolvimento, projeto de melhoria e
aplicação.
 DICA
As fórmulas aqui descritas usam as mesmas variáveis do procedimento do IFPUG.
Para ilustrar as fórmulas em cada tipo de contagem, vamos usar um exemplo: sistema de contas a pagar, com as seguintes
funcionalidades do sistema e de conversão. O sistema hoje é usado manualmente em planilhas, o AIE banco e os ALI
fornecedores, Caixa e pagamentos existem em planilhas Excel e serão convertidos para os arquivos do sistema, conforme as
tabelas a seguir.
A primeira tabela apresenta as funcionalidades do sistema.
Função Tipo TD AR ou TR Complexidade Contagem
Bancos AIE 5 1 Baixa 5
Pagamentos ALI 11 1 Baixa 7
Pagamentos fixos ALI 4 1 Baixa 7
Fornecedores ALI 15 1 Baixa 7
Caixa empresa ALI 6 1 Baixa 7
Login SE 4 1 Baixa 4
Incluir fornecedor EE 17 1 Baixa 3
Excluir fornecedor EE 3 1 Baixa 3
Alterar fornecedor EE 17 1 Média 4
Consulta fornecedor CE 17 1 Baixa 3
Incluir pagamentos fixos EE 4 1 Baixa 3
Alterar pagamentos fixos EE 7 1 Baixa 3
Excluir pagamentos fixos EE 4 1 Baixa 3
Incluir pagamentos EE 15 4 Alta 6
Alterar pagamentos EE 15 4 Alta 6
Excluir pagamentos EE 3 2 Baixa 3
Consultar pagamentos CE 9 2 Média 4
Relatório pagamentos SE 15 2 Média 5
Pontos de função 83
Tabela: Funcionalidades do sistema de contas a pagar
 Elaborada por: Marcelo Vasques de Oliveira.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
As funcionalidades de conversão são exibidas na próxima tabela.
Função Tipo TD AR ou TR Complexidade Contagem
Conversão bancos EE 5 1 Baixa 3
Conversão pagamentos fixos EE 4 1 Baixa 3
Conversão pagamentos EE 11 1 Baixa 3
Conversão fornecedores EE 15 1 Baixa 3
Conversão Caixa empresa EE 6 1 Baixa 3
Pontos de função 15
Tabela: Funcionalidades de conversão do sistema de contas a pagar
 Elaborada por: Marcelo Vasques de Oliveira.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Para efeito de cálculos de pontos de função, precisamos do nome das funcionalidades (obtida dos requisitos funcionais), a
fim de entendê-las e chegarmos à sua complexidade. A tabela a seguir tem o mesmo efeito que a tabela anterior.
Tipo de função Complexidade Ocorrências Peso Contagem PF
Entrada externa (EE)
 
 
Total (EE)
Baixa
Média
Alta
6
1
2
x3
x4
x6
= 18
= 4
= 12
= 34
Saída externa (SE)
 
 
Total (SE)
Baixa
Média
Alta
1
1
0
x4
x5
x7
= 4
= 5
= 0
= 9
Consulta externa (CE)
 
 
Total (SE)
Baixa
Média
Alta
1
1
0
x3
x4
x6
= 3
= 4
= 0
= 7
Arquivo lógico interno (ALI)
 
 
Total (ALI)
Baixa
Média
Alta
4
0
0
x7
x10
x15
= 28
= 0
= 0
= 28
Arquivo de interface externa (AIE) Baixa
Média
Alta
1
0
0
x5
x7
x10
= 5
= 0
= 0
= 5
Total Pontos de Função 83
Funções de conversão
Entrada externa (EE)
 
Total (EE)
Baixa
Média
Alta
5
0
0
x3
x4
x6
= 15
= 0
= 0
= 15
Tabela: Funcionalidades por complexidade do sistema de contas a pagar.
 Elaborada por: Marcelo Vasques de Oliveira.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
PROJETO DE DESENVOLVIMENTO
O projeto de desenvolvimento de um novo produto de software considera:
As funções requisitadas pelos usuários.
As funções disponíveis na instalação do sistema: a conversão de dados ou outras serão descartadas após a implantação.
A fórmula de cálculo é:
DFP = (ADD + CFP)
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Em que:
DFP
Tamanho funcional do projeto de desenvolvimento.
ADD
Tamanho das funções entregues (pontos de função não ajustados).
CFP
Tamanho das funções de conversão.
PROCEDIMENTO PARA CONTAGEM
1
Liste as funcionalidades solicitadas pelo usuário (ADD) e calcule seu tamanho em PF, com base em sua complexidade e nas
tabelas de funções de dados e transações.
Liste as funcionalidades necessárias à conversão de dados. Em geral, serão funções de dados, porém sobre ALIs ouAIEs já
computados na aplicação. Deve-se computar apenas as funcionalidades de conversão, como se fossem transações.
2
Aplicando a fórmula no exemplo do sistema de contas a pagar, teremos:
DFP = (87 + 15) = 102 PONTOS DE FUNÇÃO
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Em que:
ADD = Tamanho das funções entregues = 83.
CFP = Tamanho das funções de conversão = 15.
Ou seja, o sistema de contas a pagar tem 98 PFs não ajustados.
Supomos as seguintes pontuações, conforme tabela a seguir, após análise das CGS que afetam o sistema de conta a pagar.
CGS Pontos
Comunicação de dados 1
Processamento distribuído 3
Performance 1
Configuração do equipamento 2
Volume de transações 1
Entrada de dados on-line 5
Eficiência de usuário final 4
Atualização on-line 4
Complexidade do processamento 2
Reusabilidade 4
Facilidade de instalação 4
Facilidade de operação 3
Múltiplos locais 4
Facilidade de mudanças 5
Total pontos 43
Tabela: Funcionalidades de conversão do sistema de contas a pagar.
 Elaborada por: Marcelo Vasques de Oliveira.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Aplicando a fórmula do valor do fator de ajuste (VFA), teremos:
VFA = 0,65 + (0,01 * 43) = 0,65 + 0,43 = 1,08
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Calculando os pontos de função ajustados (PFA), teremos:
PFA = DFP * VFA
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Em que:
PFA = PFs ajustados do sistema.
DFP = Tamanho das funções entregues = 98 (PFs não ajustados).
VFA = Valor do fator de ajuste = 1,08.
PFA = 98 * 1,08 = 105,84.
O sistema de contas a pagar possui 105,84 ou 106 pontos de função ajustados.
 
Foto: Shutterstock.com
PROJETO DE MELHORIA
É aplicado para demandas de melhorias funcionais em sistema existente. O método do IFPUG não usa medição para
projetos que visem exclusivamente mudanças nos requisitos não funcionais.
Considera:
FUNCIONALIDADES REQUISITADAS PELOS USUÁRIOS
javascript:void(0)
Funções a serem adicionadas, eliminadas e alteradas.
FUNÇÕES PARA CONVERSÃO DE DADOS
Funções que serão descartadas após a implantação e, em geral, são necessárias para ajustes de ALIs e AIEs que tiveram
suas estruturas modificadas na nova versão.
 ATENÇÃO
Não é mandatória a existência da contagem do projeto original, pois serão medidas apenas as funcionalidades afetadas na
nova versão do sistema. Contudo, na existência da contagem da aplicação original, a medição é facilitada, pois bastará
alterar a complexidade, se for o caso, das funções alteradas.
A fórmula de cálculo é: EFP = (ADD + CHGA + CFP + DEL)
Em que:
EFP = Tamanho do projeto de melhoria.
ADD = Tamanho das funções incluídas no projeto de melhoria.
CHGA = Tamanho das funções modificadas.
CFP = Tamanho das funções de conversão.
DEL = Tamanho das funções excluídas.
CRITÉRIOS PARA IDENTIFICAR MUDANÇAS NAS FUNÇÕES DE
DADOS
Para considerarmos que foi feita alteração em uma função de dados, é preciso que haja uma mudança estrutural, com
acréscimo, alteração ou exclusão de tipos de dados (campos) ou nos tipos de registro, de forma que alterem a complexidade
da função e consequentemente a sua pontuação.
Toda a funcionalidade deve ser contabilizada e não apenas os campos afetados na mudança.
CRITÉRIOS PARA IDENTIFICAR MUDANÇAS NAS TRANSAÇÕES
Uma função de transação é considerada alterada quando um de seus elementos, descritos a seguir, são modificados:
TIPOS DE DADOS OU ARQUIVOS REFERENCIADOS
Se forem adicionados, eliminados ou alterados, de forma que altere a complexidade.
LÓGICA DE PROCESSAMENTO
javascript:void(0)
javascript:void(0)
javascript:void(0)
Caso uma consulta externa (CE) passe a ter lógica de processamento, ela deixará de ser uma CE e passará a ser uma saída
externa (SE), tendo sua complexidade alterada.
Da mesma forma que nas funções de dados, havendo alteração nas funções de transação, deve-se contar toda a
funcionalidade no projeto de melhoria, e não apenas campos ou arquivos referenciados alterados.
EXEMPLO, ALTERANDO O SISTEMA DE CONTAS A PAGAR
Consideremos o exemplo da aplicação de contas a pagar, anteriormente definida. Ela sofrerá melhorias, a saber:
ADIÇÃO DE FUNCIONALIDADES
AIE adicionado: Senha  agora os usuários poderão ter mais de 1 senha para poder associar a diferentes perfis. 
linha 1 da tabela a seguir.
SE adicionada: Relatório de contas em atraso  linha 2 da tabela a seguir.
ALTERAÇÃO DE FUNCIONALIDADES
Alteração da função LOGIN, que passa a referenciar mais 1 arquivo lógico (Senha)  linha 3 da tabela a seguir.
EXCLUSÃO DE FUNCIONALIDADES
Exclusão da funcionalidade consultar pagamentos.  linha 4 da tabela a seguir.
Não haverá a necessidade de conversão de dados para o projeto de melhoria.
A contagem vai considerar apenas o escopo pertinente ao projeto de melhorias que engloba as inclusões, alterações e
exclusões de funcionalidades, conforme tabela.
Função Tipo
Depois do projeto de melhoria Antes do projeto de melhoria
TD AR/TR Complexidade PF TD AR/TR Complexidade PF
Senha AIE 3 1 Baixa 5
Relatório
contas em
atraso
SE 8 1 Baixa 4
javascript:void(0)
javascript:void(0)
javascript:void(0)
Login SE 4 2 Baixa 4 4 1 Baixa 4
Consultar
Pagamentos
CE 9 2 Média 4
Tabela: Funcionalidades do projeto de melhorias do sistema de contas a pagar.
 Elaborada por: Marcelo Vasques de Oliveira.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Aplicando a fórmula de cálculo: EFP = (ADD + CHGA + CFP + DEL), teremos:
ADD = 5 + 4 = 9 (funções adicionadas – depois do projeto de melhorias)
CHGA = 4 (depois do projeto de melhorias)
CFP = 0 (não houve arquivo de conversão)
DEL = 4 (antes do projeto de melhorias)
Onde:
 EFP = 9 + 4 + 0 + 4 = 17 PF
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Ou seja, o projeto de melhorias do exemplo tem tamanho funcional de 17 PFs não ajustados.
Aplicando o mesmo fator de ajuste (VFA) do exemplo de projeto de desenvolvimento, no valor de 1,08 (base na tabela 25),
teremos:
PFA = EFP * VAF
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Em que:
PFA = PFs ajustados do sistema
EFP = Tamanho do projeto de melhorias = 18 (PFs não ajustados)
VFA = Valor do fator de ajuste = 1,08
PFA = 18 * 1,08 = 19,44 PFs ajustados
Ou seja, o projeto de melhorias do exemplo tem tamanho funcional de 19,44 PFs ajustados.
PROJETO DE APLICAÇÃO
Existem duas maneiras de realizar o cálculo do número de pontos de função da aplicação: Contagem inicial da aplicação e
contagem após projeto de melhoria (se for o caso). Veremos cada uma delas a seguir.
CONTAGEM INICIAL DA APLICAÇÃO
A fórmula AFP = ADD considera todas as funcionalidades solicitadas e implementadas na aplicação entregue, que pode ser:
um pacote de software adquirido de terceiros, uma aplicação recentemente construída e instalada, ou ainda um software já
instalado e que sofreu atualizações de manutenção recentemente.
 DICA
Atente que, diferentemente da contagem em projetos de desenvolvimento e melhoria, aqui não se considera as
funcionalidades de conversão de dados.
Entenda a fórmula de cálculo AFP = ADD:
AFP = Tamanho funcional da aplicação.
ADD = Tamanho das funções entregues (PFs não ajustados).
 ATENÇÃO
Atente que essa fórmula é quase igual à aplicada em projetos de desenvolvimento, exceto pelo fato de não computar funções
de conversão de dados.
CONTAGEM APÓS PROJETO DE MELHORIA DA APLICAÇÃO
Assim que o projeto de melhoria da aplicação é finalizado, é feita nova contagem de PF, sem considerar as funções de
conversão de dados (mesmo que existam). Contudo, é possível que não haja alteração no tamanho funcional da aplicação;
basta que não haja inclusões ou exclusões de funcionalidades anteriormente computadas na contagem e/ou as alterações de
funcionalidades implementadas não afetem o seu tamanho funcional.
Quais as possíveis alteraçõesna aplicação?
Veja a seguir:
INCLUSÃO DE NOVA FUNCIONALIDADE
Aumenta o tamanho funcional.
EXCLUSÃO DE FUNCIONALIDADE
Diminui o tamanho funcional.
ALTERAÇÃO EM FUNCIONALIDADE
Mantém, diminui ou aumenta o tamanho funcional.
A fórmula de cálculo é:
AFPA = (AFPB + ADD + CHGA) – (CHGB+DEL)
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Em que:
AFPA = Tamanho funcional da aplicação após melhoria.
AFPB = Tamanho funcional da aplicação antes da melhoria.
ADD = Tamanho funcional das funções incluídas no projeto de melhoria.
CHGA = Tamanho funcional das funções alteradas no projeto de melhoria depois de seu fim.
CHGB = Tamanho funcional das funções alteradas no projeto de melhoria antes de seu fim.
DEL = Tamanho funcional das funções eliminadas pelo projeto de melhoria.
Aplicando aos dados do projeto de desenvolvimento do sistema de contas a pagar (tabela: Funcionalidades do sistema de
contas a pagar) e do projeto de melhoria do sistema de contas a pagar (tabela: Funcionalidades de conversão do sistema de
contas a pagar), temos:
AFPA = (AFPB + ADD + CHGA) – (CHGB+DEL)
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Em que:
AFPB = 83 (Funcionalidades do sistema)
ADD = 9 (Funcionalidades de conversão do sistema)
CHGA = 4 (Funcionalidades de conversão do sistema)
CHGB = 4 (Funcionalidades de conversão do sistema)
DEL = 4 (Funcionalidades de conversão do sistema)
Assim, temos a fórmula:
AFPA = (83 + 9 + 4) – (4 – 4) = 96 – 0 = 95
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
O projeto de melhoria da aplicação tem 95 PFs não ajustados.
Aplicando um VFA (fator de ajuste) de 1,08, teremos:
PFS AJUSTADOS = 95 × 1,08 = 102,60 OU 103 PFS AJUSTADOS.
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
CÁLCULO DE PONTOS DE FUNÇÃO AJUSTADOS
Assista ao vídeo sobre as regras e fórmulas dos pontos de função não ajustados conforme o propósito da contagem e a
aplicação do fator de ajuste.
VERIFICANDO O APRENDIZADO
1. CONSIDERE A SEGUINTE QUANTIDADE DE OCORRÊNCIAS DAS FUNCIONALIDADES DO
PROJETO DE DESENVOLVIMENTO DE UM SISTEMA DE PONTO DE FUNCIONÁRIOS DE UMA
FÁBRICA DE MOTORES. ESSE PROJETO NÃO DEMANDA CONVERSÃO DE DADOS. 
FUNÇÃO OCORRÊNCIAS
ENTRADA EXTERNA (EE)
1
1
2
SAÍDA EXTERNA (SE)
0
0
1
CONSULTA EXTERNA (CE)
3
0
1
ARQUIVO LÓGICO INTERNO (ALI)
2
0
0
ARQUIVO DE INTERFACE EXTERNA (AIE)
1
1
0
TABELA: OCORRÊNCIAS DAS FUNCIONALIDADES.
 ELABORADA POR: MARCELO VASQUES DE OLIVEIRA
 ATENÇÃO! PARA VISUALIZAÇÃO COMPLETA DA TABELA UTILIZE A ROLAGEM
HORIZONTAL
 
QUAL A CONTAGEM DE PF CORRETA?
A) 68
B) 88
C) 67
D) 78
E) 66
2. AVALIE AS ASSERTIVAS A SEGUIR, SOBRE OS CÁLCULOS DE PF DAS FUNCIONALIDADES
ENTREGUES E DAS FUNCIONALIDADES DE CONVERSÃO DE DADOS DO SISTEMA: 
 
EM PROJETO DE MELHORIA DE SOFTWARE, NÃO COMPUTAMOS FUNCIONALIDADES DE
CONVERSÃO DE DADOS.
EM PROJETO DE APLICAÇÃO, A SER ADQUIRIDA DE TERCEIROS, CONSIDERAMOS
APENAS FUNCIONALIDADES ENTREGUES.
EM UM PROJETO DE DESENVOLVIMENTO, SÃO CONSIDERADAS AS FUNCIONALIDADES
ENTREGUES E AINDA AS DE CONVERSÃO DE DADOS.
 
ESTÃO CORRETOS APENAS:
A) II e III
B) I, II e III
C) I
D) II
E) I e II
GABARITO
1. Considere a seguinte quantidade de ocorrências das funcionalidades do projeto de desenvolvimento de um
sistema de ponto de funcionários de uma fábrica de motores. Esse projeto não demanda conversão de dados.
Função Ocorrências
Entrada externa (EE) 1
1
2
Saída externa (SE)
0
0
1
Consulta externa (CE)
3
0
1
Arquivo lógico interno (ALI)
2
0
0
Arquivo de interface externa (AIE)
1
1
0
Tabela: Ocorrências das funcionalidades.
 Elaborada por: Marcelo Vasques de Oliveira
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
 
Qual a contagem de PF correta?
A alternativa "C " está correta.
 
Tipo de função Ocorrências Pontos de função
Entrada externa (EE)
1x3
1x4
2x6
3
4
12
Saída externa (SE)
0x4
0x5
1x7
0
0
7
Consulta externa (CE) 3x3 9
0x4
1x6
0
6
Arquivo lógico interno (ALI)
2x7
0x10
0x15
14
0
0
Arquivo de interface externa (AIE)
1x5
1x7
0x10
5
7
0
TOTAL 67
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
DFP = (ADD + CFP)
DFP = 67 + 0 = 67, ou seja, o sistema tem 67 PF
2. Avalie as assertivas a seguir, sobre os cálculos de PF das funcionalidades entregues e das funcionalidades de
conversão de dados do sistema: 
 
Em projeto de melhoria de software, não computamos funcionalidades de conversão de dados.
Em projeto de aplicação, a ser adquirida de terceiros, consideramos apenas funcionalidades entregues.
Em um projeto de desenvolvimento, são consideradas as funcionalidades entregues e ainda as de conversão
de dados.
 
Estão corretos APENAS:
A alternativa "A " está correta.
 
Vamos avaliar, cada uma das assertivas.
Falsa, computamos sim, pois as melhorias podem demandar conversões de dados.
Verdadeira, não consideramos conversões de dados.
Verdadeira, consideramos as funcionalidades entregues no software e computamos as funcionalidades de conversão
de dados.
MÓDULO 4
 Descrever como contabilizar as funções de dados e transações
MEDINDO FUNÇÕES DE DADOS
ALI (ARQUIVO LÓGICO INTERNO)
Um ALI é um grupo de dados ou informações de controle logicamente relacionados, que o usuário identifica e é mantido pela
aplicação que está sendo contada. O ALI está dentro da fronteira da aplicação.
A finalidade de um ALI é alimentar, por uma ou mais transações, os dados a serem mantidos (inclusão, alterações, exclusão)
pela aplicação.
São ALIs: repositório de dados e arquivos de parâmetros (informações de controle) mantidos pela aplicação.
AIE (ARQUIVO DE INTERFACE INTERNA)
Um AIE é um grupo de dados ou informações de controle logicamente relacionados, que o usuário identifica e é referenciado
(consultados os dados) pela aplicação em contagem. Está fora da fronteira da aplicação.
O AIE sempre será o ALI de uma ou mais aplicações, mas referenciados pela aplicação em contagem.
Não são considerados arquivos lógicos e, portanto, não são ALI nem AIE:
Dados estáticos.
Dados temporários.
Arquivos usados em função de determinada tecnologia ou decisão de projeto.
A pontuação de ALI e AIE varia em função de sua complexidade, determinada pelos tipos de dado (TD) e dos tipos de
registro (TE). Reveja a tabela:
Tipo de dados (campos ou TD)
Tipo de registro 1 a 19 20 a 50 51 ou mais
1 Baixa Baixa Média
2 a 5 Baixa Média Alta
6 ou mais Média Alta Alta
Tabela: Tabela: Complexidade das funções de dados: Arquivo lógico interno (ALI) e Arquivo de interface externa (AIE).
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
TIPO DE DADO (TD)
Um tipo de dado (TD) é um campo único, reconhecido pelo usuário e não repetido, mantido ou recuperado por um ALI ou
AIE. Pode ser considerado como um campo do repositório, mas a relação não é tão precisa assim.
Como identificar um TD? Veja algumas dicas:
a. Uma data, mesmo que armazenada com 3 campos (dia, mês e ano), é contabilizada como 1 TD.
b. Campos calculados, em um ALI, são TD.
c. Para um ALI ou AIE que seja mantido ou referenciado por 2 ou mais aplicações, conte apenas os campos usados pela
aplicação em contagem.
d. Campo endereço segmentado: rua, número, complemento, cidade e CEP. Conta-se 5 TD.
e. O(s) campo(s) usado(s) para relacionar diferentes ALIs ou AIEs são computados como TD. Se for 1 campo, conta 1 TD, se
forem 2 campos (identificação composta), serão 2 TDs, e assim sucessivamente.
f. Suponha uma nota fiscal (NF), no modelo conceitual. Fisicamente, podem ser 2 tabelas implementadas (NF e Itens_NF),
contudo representam um único ALI (conforme está no modelo conceitual). Nesse caso, o(s) campo(s) usado(s) como
relacionamento entre NF e Itens_NF deve(m) ser computado(s) apenas 1 vez, pois estará(ão) nas 2 tabelas.
 ATENÇÃO
Não há necessidadede que os tipos de dados (TD) sejam reconhecidos na quantidade exata, pois nas tabelas de ALI e AIE
temos intervalos de valores. Logo, basta identificar o intervalo.
TIPO DE REGISTRO (TR)
Um tipo de registro (TR) é um subgrupo de dados, reconhecido pelo usuário de um ALI ou AIE. Deve ser contabilizado 1 TR
para cada função de dados. Além disso, contabiliza-se 1 TR adicional nas seguintes situações:
ENTIDADE ASSOCIATIVA
Associativas são as entidades que servem de elo entre duas ou mais entidades. São dependentes da entidade principal, ou
seja, fazem sentido em conjunto com seus pares.  Se a entidade possuir dados que não sejam exclusivamente as chaves
de relacionamento, contabiliza-se 1 ALI e 1 TR e os atributos não chaves são TDs.
SUBTIPO E SUPERTIPO (EM GENERALIZAÇÃO-ESPECIALIZAÇÃO, POR
EXEMPLO)
A entidade geral e suas especializações (exemplo: Imposto — entidade geral e IR, PIS, Cofins — especializações): cada
entidade especializada contabiliza como 1 TR.
ENTIDADE ATRIBUTIVA
Atributos multivalorados, que fisicamente seriam 2 tabelas, computa 1 ALI de 2 TR, como por exemplo pedido (cabeçalho) e
Itens_pedido (detalhes do pedido).
Não devem ser contabilizado como tipo de registro (TR):
Metadados não são dados reconhecidos pelo usuário, mas um artifício de implementação.
METADADOS
Imagine um sistema de pedidos que pode estar em diferentes status; muitas implementações usam arquivos de dados
para associar um código ao nome do status do pedido. Esse é um exemplo clássico, que não deve ser considerado.
Outro exemplo seria reunir nos arquivos os estados da federação. Abaixo outros exemplos de metadados.
Arquivos de dados com apenas 1 atributo.
Arquivos que raramente mudam e representam faixa de valores considerados válidos em um contexto.
Arquivos de dados que, em geral, possuem poucas ocorrências e cujo conteúdo raramente sofra alteração. Por
exemplo, arquivo contendo dados da versão do sistema (nome do sistema, versão do sistema e data da versão).
Arquivos com dados de totalização, visando aumentar performance.
Entidades (em modelos de dados) que contenham apenas chaves como atributos, representativas dos relacionamentos N:M.
As chamadas entidades de ligação.
Arquivos temporários, auxiliares de algum tipo de processamento do sistema.
Arquivos de índice, usados em banco de dados para aumentar a performance das consultas e que não armazenam nem
dados nem informações de controle.
Visões de banco de dados.
COMPLEXIDADE X PONTO DE FUNÇÃO
Uma vez identificada a complexidade de cada ALI ou AIE, a sua conversão em PF é feita com base na tabela a seguir.
Complexidade e tamanho funcional (PF)
Tipo de função Baixa Média Alta
javascript:void(0)
Entrada externa (EE)
Consulta externa (CE)
3 4 6
Saída externa (SE) 4 5 7
Arquivo lógico interno (ALI) 7 10 15
Arquivo de interface externa (AIE) 5 7 10
Tabela: Complexidade x Pontos de função de cada tipo de função de dado e transação.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
MEDINDO FUNÇÕES DE TRANSAÇÃO
São as funcionalidades do sistema que respondem aos requisitos dos usuários. São elas:
ENTRADA EXTERNA (EE)
É uma transação que processa dados ou informações de controle, vindos do ambiente externo ao sistema (fora de sua
fronteira), com a finalidade de manter um ALI ou alterar o comportamento do sistema. São transações de entrada de dados
do usuário para o sistema.
SAÍDA EXTERNA (SE)
É uma transação que envia dados ou informações de controle para o ambiente externo ao sistema (fora de sua fronteira),
com a finalidade de apresentar informação ao usuário, desde que haja processamento dos dados (não apenas ler dados e
apresentar ao usuário). O processamento requer um cálculo e/ou derivar dados e/ou manter ALIs, e/ou alterar o
comportamento do sistema.
CONSULTA EXTERNA (CE)
É uma transação que envia dados ou informações de controle para o ambiente externo ao sistema (fora de sua fronteira),
com a finalidade de apresentar informações ao usuário, que sejam simplesmente a leitura (sem processamento) de dados
contidos em ALI ou AIE. Não há cálculos, e ALIs não são mantidos nas CEs.
As SE e as CE são transações de envio de dados para fora da fronteira da aplicação. A principal diferença entre SE e CE é a
existência de lógica de processamento (como totalizações, maior elemento da lista, dentre outros) nas transações de SE.
A classificação correta das transações requer avaliar:
Se a finalidade da transação for manter um ALI ou modificar o comportamento do sistema, tende a ser uma EE, após
validadas as suas regras.
Se a transação não calcula nada, não atualiza dados de ALI e não altera o comportamento do sistema, tende a ser uma CE.
Se a transação calcula algo, faz derivação de dados, atualiza ALI ou altera o comportamento do sistema, tende a ser uma
SE.
PROCESSOS ELEMENTARES
Um processo elementar tem significado para o usuário e é uma transação completa. Sua correta identificação é a chave para
uma contagem de transação correta. A alimentação de um ALI, com as operações de inclusão, alteração e exclusão, pode
ser implementada de diferentes formas. Pode haver uma tela para cada uma dessas três funcionalidades, como pode haver
uma tela única (com 3 botões, por exemplo) que contemple as três funcionalidades.
Em qualquer caso, serão três transações, pois são três processos elementares e distintos: incluir, alterar e excluir. E repare
ainda que há uma transação implícita, que é a consulta, que sempre vai preceder a uma alteração ou exclusão, podendo ser
considerada uma SE, se nela houver processamento ou CE na ausência deste.
 ATENÇÃO
Uma função de “validar o CPF de um cliente”, durante sua inclusão, não é um processo elementar, já que faz parte da
inclusão, alteração (se permitir alterar CPF).
INFORMAÇÕES DE CONTROLE
São dados de parâmetros da aplicação. As preferências de usuários são informações de controle. Em cadastramento de
clientes, o tipo de cliente (física ou jurídica) é informação de controle, pois a partir daí os dados solicitados variam: se física
(CPF, identidade, data de nascimento etc.); se jurídica (CNPJ, inscrição municipal e data de abertura). Outro exemplo: campo
Forma de Pagamento, em uma venda, determina a execução de diferentes procedimentos, conforme o pagamento (cartão,
cheque, pix, transferência etc.).
ALTERAR O COMPORTAMENTO DO SISTEMA
É o mesmo que alterar um parâmetro do negócio.
 EXEMPLO
Imagine que a partir de uma venda de R$ 500,00, o pagamento poderá ser parcelado em até 10 x sem juros. A empresa
deseja aumentar o valor de venda base para parcelamento de R$ 500,00 para R$ 1.000,00, o que afeta o comportamento do
sistema.
COMPLEXIDADE DA FUNÇÃO DE TRANSAÇÃO
Cada EE, SE e CE deve ser classificada em sua complexidade com base nos parâmetros:
Número de arquivos referenciados (AR)
Número de tipo de dado (TD)
 RELEMBRANDO
As tabelas a seguir mostram como chegar à complexidade com base nos dois parâmetros.
Tipo de dados (campos ou TD)
Tipo de registro 1 a 19 20 a 50 51 ou mais
1 Baixa Baixa Média
2 a 5 Baixa Média Alta
6 ou mais Média Alta Alta
Tabela: Complexidade das funções de dados: Arquivo lógico interno (ALI) e Arquivo de interface externa (AIE).
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Tipo de dados (TD)
AR 1 a 4 5 a 15 16 ou mais
0 a 1 Baixa Baixa Média
2 Baixa Média Alta
3 ou mais Média Alta Alta
Tabela: Complexidade da função de transação chamada: Entrada externa (EE).
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Uma CE deve possuir, minimamente, 1 arquivo referenciado (ALI ou AIE).
COMO CONTABILIZAR ARQUIVOS REFERENCIADOS (AR)
Arquivo referenciado (AR) é um ALI lido ou mantido pela aplicação ou um AIE lido pela aplicação.
No que tange à atualização de arquivos:
Para cada ALI mantido ou lido, teremos 1 arquivo referenciado.
Para cada AIElido durante o processamento, teremos 1 arquivo referenciado.
Cada ALI ou AIE deve ser contado apenas 1 vez.
Como contabilizar tipo de dado (TD)?
1 TD = 1 atributo que entre ou saia do sistema.
Se o campo entrar e sair, conta apenas 1 vez.
1 TD para cada capacidade de envio de mensagem pelo sistema (mensagem de erro, de conclusão e de verificação de
procedimento). Não contar cada mensagem em si, mas o tipo de mensagem.
 ATENÇÃO
Não contabilize como TD: títulos de relatórios, identificadores de telas, cabeçalho de colunas, nomes de campos e títulos de
atributos, data e hora, número de página, auxílios de navegação (anterior, próximo, primeiro, último). Também não contabilize
atributos gerados por uma transação e armazenado em ALI. Exemplo: a quantidade de itens de uma nota fiscal ou a
informação de que um cheque foi cancelado.
CONTRIBUIÇÃO DAS TRANSAÇÕES EM PF
Após classificar a complexidade, as transações são convertidas na contagem em PF. Observe as linhas Entrada externa,
Consulta externa e Saída externa da tabela.
Complexidade e tamanho funcional (PF)
Tipo de função Baixa Média Alta
Entrada externa (EE)
Consulta externa (CE)
3 4 6
Saída externa (SE) 4 5 7
Arquivo lógico interno (ALI) 7 10 15
Arquivo de interface externa (AIE) 5 7 10
Tabela: Complexidade x Pontos de função de cada tipo de função de dado e transação.
 Extraída de: IFPUG, s.d.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
EXEMPLIFICANDO A CONTAGEM COM O SISTEMA DE CONTAS
A PAGAR
Usaremos o sistema de contas a pagar, apresentado no módulo anterior (tabela: Funcionalidades do sistema de contas a
pagar), considerando as funcionalidades de transações abaixo.
Função Tipo TD AR ou TR Complexidade Contagem
Login SE 4 1 Baixa 4
Incluir fornecedor EE 17 1 Baixa 3
Excluir fornecedor EE 3 1 Baixa 3
Alterar fornecedor EE 17 1 Média 4
Incluir pagamentos EE 15 4 Alta 6
Alterar pagamentos EE 15 4 Alta 6
Excluir pagamentos EE 3 2 Baixa 3
Consultar pagamentos CE 9 2 Média 4
Relatório pagamentos SE 15 2 Média 5
Tabela: Funções de transação do sistema de contas a pagar.
 Elaborada por: Marcelo Vasques de Oliveira.
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Agora, vamos detalhar as funcionalidades da tabela.
LOGIN
A finalidade é apresentar ao usuário a informação de que seu acesso foi concedido ou não (quando uma mensagem de erro
é enviada). Há criptografia de senha, estando presente a lógica de processamento com fórmulas, logo uma SE. O usuário
informa seu login e senha e clica no botão OK (Saída externa).
Contagem de tipos de dados (TD) = identificação do usuário e senha (2) + botão OK + mensagem em caso de erro = 4.
Contagem de arquivos referenciados (AR) = ALI Usuários = 1.
4 TD e 1 AR = complexidade baixa = 4 PF
INCLUIR FORNECEDOR
A finalidade é alimentar o ALI fornecedor, com dados digitados pelo usuário (EE).
Contagem de tipos de dados (TD) = 15 campos únicos do fornecedor + comando (botão OK) + mensagem para usuário = 17.
Contagem de arquivos referenciados (AR) = ALI fornecedor = 1.
17 TD e 1 AR = complexidade baixa = 3 PF
EXCLUIR FORNECEDOR
A finalidade é excluir dados do ALI fornecedor (EE).
Contagem de tipos de dados (TD) = Identificação fornecedor + comando (botão OK) + mensagem para usuário = 3.
Contagem de arquivos referenciados (AR) = ALI fornecedor = 1.
3 TD + 1 AR = complexidade baixa = 3 PF
ALTERAR FORNECEDOR
A finalidade é atualizar dados do ALI fornecedor (EE).
Contagem de tipos de dados (TD) = 15 campos únicos do fornecedor + comando (botão OK) + mensagem para usuário = 17.
Contagem de arquivos referenciados (AR) = ALI fornecedor = 1.
17 TD e 1 AR = complexidade média = 4 PF
INCLUIR PAGAMENTOS
A finalidade é alimentar o ALI pagamentos (EE).
Contagem de tipos de dados (TD) = 13 campos únicos do pagamento + comando (botão OK) + mensagem para usuário = 15.
Contagem de arquivos referenciados (AR) = fornecedor (lido), pagamentos fixos (lido), Caixa da empresa (lido e gravado) e
pagamentos (gravado) = 4.
15 TD + 4 AR = complexidade = alta = 6 PF
ALTERAR PAGAMENTOS
A finalidade é atualizar o ALI pagamentos (EE).
Contagem de tipos de dados (TD) = 13 campos únicos do pagamento + comando (botão OK) + mensagem para usuário = 15.
Contagem de arquivos referenciados (AR) = fornecedor (lido), pagamentos fixos (lido), Caixa da empresa (lido e gravado) e
pagamentos (gravado) = 4.
15 TD + 4 AR = complexidade = alta = 6 PF
EXCLUIR PAGAMENTOS
A finalidade é atualizar o ALI pagamentos (EE).
Contagem de tipos de dados (TD) = Identificação pagamento + comando (botão OK) + mensagem para usuário = 3.
Contagem de arquivos referenciados (AR) = ALI pagamentos (gravado) e Caixa da empresa (gravado) = 2.
3 TD + 2 AR = complexidade baixa = 3 PF
CONSULTAR PAGAMENTOS
Informar ao usuário os pagamentos de um período (CE).
Contagem de tipos de dados (TD) = Data inicial, data final (dados de entrada) + comando (botão OK) + mensagem para
usuário + 5 dados exibidos do pagamento = 9.
Contagem de arquivos referenciados (AR) = ALI pagamentos, fornecedor (buscar nome do fornecedor e exibir) = 2.
9 TD + 2 AR = complexidade média = 5 PF
RELATÓRIO PAGAMENTOS
Informar ao usuário os pagamentos de um período com totais de pagamentos e de despesas fixas, maior despesa e sua
representação % (SE).
Contagem de tipos de dados (TD) = Data inicial, data final + comando (botão OK) + mensagem para usuário + 7 dados a
serem exibidos + total pagamentos + total despesas fixas + maior despesa + representação % maior despesa = 15.
Contagem de arquivos referenciados (AR) = ALI pagamentos, fornecedor (buscar nome do fornecedor e exibir) = 2.
15 TD + 2 AR = complexidade Média = 5 PF
CONTABILIZAR ADEQUADAMENTE FUNÇÕES DE DADOS
E CONTROLE
Assista ao vídeo sobre a classificação adequada das funções de dados e transação.
VERIFICANDO O APRENDIZADO
1. AVALIE AS ASSERTIVAS A SEGUIR, SOBRE OS CÁLCULOS DE PF DAS FUNCIONALIDADES
ENTREGUES E AINDA DAS FUNCIONALIDADES DE CONVERSÃO DE DADOS DE UM SISTEMA: 
 
A DIFERENÇA ENTRE CE E SE É A EXISTÊNCIA DE PROCESSAMENTO (CÁLCULO OU
ALTERAÇÃO DO ESTADO DO SISTEMA) NAS SE.
PARA CLASSIFICAR A COMPLEXIDADE DE UMA TRANSAÇÃO, PRECISAMOS SABER O TD
(TOTAL DE CAMPOS ÚNICOS, SEM REPETIÇÃO E RECONHECIDO PELO USUÁRIO) E OS
ARS (ARQUIVOS REFERENCIADOS). UM AR SERÁ SEMPRE UM ALI QUE A TRANSAÇÃO
CONSULTA.
QUANDO TEMOS NA MODELAGEM DE DADOS UMA ENTIDADE NOTA FISCAL, QUE
CONTÉM O CABEÇALHO E OS ITENS DA NOTA FISCAL COM OS DETALHES DA NOTA,
DEVE-SE CONSIDERAR APENAS 1 ALI.
IV. É NECESSÁRIO RIGOR NA IDENTIFICAÇÃO DA QUANTIDADE DE TIPOS DE DADOS (TD)
DE UMA TRANSAÇÃO, PODENDO INTERFERIR NO RESULTADO FINAL DA CONTAGEM.
 
ESTÃO CORRETAS APENAS:
A) I e III
B) I, II e III
C) II e IV
D) II
E) I e II e IV
2. EM UM SISTEMA DE FOLHA DE PAGAMENTO, O AIE PESSOAS É COMPARTILHADO POR
OUTROS 3 SISTEMAS. CONSIDERE AS PREMISSAS P1, P2 E P3: 
 
P1: O AIE PESSOAS TEM 40 TD E 4 TR, OU SEJA, CAMPOS ÚNICOS, NÃO REPETIDOS E
RECONHECIDOS PELO USUÁRIO. 
P2: O SISTEMA DE FOLHA DE PAGAMENTO, USA 10 TD E 2 TR DO AIE PESSOAS. 
P3: A TRANSAÇÃO RELATÓRIO DE FOLHA DE PAGAMENTO, TEM 16 TD E 3 AR. 
 
PEDE-SE: 
 
QUANTOS PFS POSSUEM O AIE PESSOAS, CONSIDERANDO O USO EM FOLHA DE
PAGAMENTO?
QUANTOS PFS POSSUEM A TRANSAÇÃO RELATÓRIO DE FOLHA DE PAGAMENTO,
TOTALIZANDO O VALOR, MAIOR E MENOR SALÁRIOS?
 
ASSINALE A ALTERNATIVA COM AS CORRETAS RESPOSTAS AOS ITENS A) E B), ACIMA:
A) 5 e 5
B) 10 e 5
C) 5 e 10
D) 15 e 5
E) 5 e 15
GABARITO
1. Avalie as assertivas a seguir, sobre os cálculos de PF das funcionalidades entregues e ainda das funcionalidades
de conversão de dados de um sistema: 
 
A diferença entre CE e SE é a existência de processamento (cálculo ou alteração do estado do sistema) nas SE.
Para classificar a complexidade de uma transação, precisamos saber o TD (total de campos únicos, sem
repetição e reconhecido pelo usuário) e os ARs (arquivos referenciados). Um AR será sempre um ALI que a
transação consulta.