Tema 3 - Aplicação de pontos de função

Prévia do material em texto

Aplicação de pontos de função
Prof. Marcelo Vasques de Oliveira
Descrição
Aplicação da contagem de pontos de função, a partir da especificação de um pequeno sistema de
informações e derivação de métricas, segundo a contagem ou estimativa de pontos de função.
Propósito
Aplicar contagem de pontos de função bem como estimar métricas como o esforço (mão de obra), tempo,
custo e produtividade, conhecimento relevante ao profissional de desenvolvimento de software para
sustentar ações de planejamento, organização e controle do projeto de desenvolvimento, manutenção ou
aquisição de um software.
Objetivos
Módulo 1
Contagem de pontos de função
Aplicar a contagem de pontos de função.
Módulo 2
ódu o
Métricas e estimativas
Definir métricas e estimativas com base nos pontos de função.
Neste conteúdo, aplicaremos a contagem de pontos de função, por meio de exemplos e um estudo
de caso. Partindo de artefatos da documentação de um pequeno sistema, tais como modelo
conceitual de dados, descrição de suas funcionalidades e especificações (layout) de telas, relatórios
(consultas), demonstraremos o procedimento de contagem de pontos de função, medindo
funcionalmente o tamanho de software.
A partir da contagem detalhada dos pontos de função (ajustados), derivaremos um conjunto de
métricas que serão úteis para o planejamento, organização e controle do ciclo de vida do sistema,
seja em seu processo de desenvolvimento, manutenção ou aquisição e customização.
Introdução
1 - Contagem de pontos de função
Ao �nal deste módulo, você será capaz de aplicar a contagem de pontos de função.
Tabelas da contagem em pontos de função (PF)
As tabelas para contagem de pontos de função estão publicadas no Manual de Práticas de Contagem –
Counting Practices Manual (CPM), do International Function Point Users Group (IFPUG), em seu método de
contagem oficial.
Saiba mais
O manual de Práticas de Contagem está disponível para especialistas certificados e registrados no site do
IFPUG, mediante pagamento.
A contagem usa um conjunto de quatro tabelas básicas para avaliação das funções de dados e transações,
que estão transcritas a seguir para facilitar seu estudo e a compreensão do estudo de caso, definido
adiante.
Complexidade das funções de dados: Arquivo Lógico Interno (ALI) e
Arquivo de Interface Externa (AIE)
A tabela a seguir mostra como avaliar a complexidade das funções de dados, com base nas quantidades de
tipos de dados e tipos de registros.
Tipo de Dados (campos ou TD)
Tipo de registro 1 a 19 20 a 50 51 ou mais
1 Baixa Baixa Média
Tipo de Dados (campos ou TD)
2 a 5 Baixa Média Alta
6 ou mais Média Alta Alta
Tabela: Complexidade das funções de dados: ALI e AIE.
Extraída de: Vasquez, Simões, Albert, 2013.
Complexidade da função de transação chamada Entrada Externa (EE)
A próxima tabela mostra como derivar a complexidade com base na quantidade de Tipos de Dados (TD) e
Arquivos Referenciados (AR), para as funções de transação de Entradas Externas (EE).
Tipos de Dados (TD)
Arquivos Referenciados
(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: Vasquez, Simões, Albert, 2013.
Complexidade das funções de transação chamadas Saídas Externas
(SE) e Consultas Externas (CE)
A tabela seguinte mostra como derivar a complexidade com base na quantidade de Tipos de Dados (TD) e
Arquivos Referenciados (AR), para as funções de transação de Saídas Externas (SE) e Consultas Externas
(CE).
Tipos de Dados (TD)
Tipos de Dados (TD)
Arquivos Referenciados
(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 chamadas SE e CE.
Extraída de: Vasquez, Simões, Albert, 2013.
Complexidade x Pontos de Função
A próxima tabela mostra a quantidade de pontos de função de cada tipo de transação, a partir de sua
complexidade.
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
Complexidade x Pontos de Função de cada tipo de função de dado e transação.
Extraída de: Vasquez, Simões, Albert, 2013.
Exemplo de contagem de arquivos lógicos com um
modelo de dados
Ao usarmos um modelo de dados como referência para a contagem de pontos de função, devemos priorizar
um modelo conceitual ou, na sua ausência, um modelo lógico de dados, uma vez que todos os conceitos
aplicados fazem alusão à visão que o usuário tem do sistema, ou seja, um modelo de negócio ou conceitual.
Os modelos de dados são úteis para calcularmos pontos de função dos arquivos lógicos, sejam:
ALI
Arquivo Lógico Interno
AIE
Arquivo de Interface Externa
O MER (Modelo de Entidade e Relacionamento), apresentado na imagem
a seguir, mostra uma parte de um modelo de dados de um sistema
acadêmico, em que podemos considerar todas as tabelas derivadas do
modelo como arquivos lógicos internos, ou seja, arquivos lógicos
mantidos pelo sistema. O modelo mostra, para cada entidade, os
atributos que representam campos de dados, assim como as
cardinalidades dos relacionamentos entre entidades.
Parte do MER de um Sistema Acadêmico.
Podemos considerar, ainda, que o sistema consulta um arquivo de interface externa (fora da fronteira e
alimentado por outro sistema, por isso não está no MER da imagem), que seria a entidade Instituições, que
indica a instituição de ensino que oferece o curso. Tal arquivo possui 51 campos de dados (TD) e 1 Tipo de
Registro (TR), o que leva a uma complexidade média e 7 pontos de função. A nova tabela de arquivos
lógicos, ficaria conforme tabela a seguir.
Consultando a tabela Complexidade das funções de dados: ALI e AIE, derivamos a complexidade e usando
a tabela Complexidade x Pontos de Função de cada tipo de função de dado e transação, atribuímos a
quantidade de pontos de função de um ALI e AIE, conforme a complexidade.
Arquivo Lógico TD TR Complexidade P
Aluno (ALI) 18 1 Baixa 7
Curso (ALI) 4 1 Baixa 7
Disciplinas (ALI) 5 1 Baixa 7
Instituição (AIE) 51 1 Média 7
Tabela: Exemplo de contagem de ALI e AIE com base no MER.
Elaborada por: Marcelo Vasques de Oliveira
Observe que os três ALI e o AIE, contribuem com 28 pontos de função.
Contagem de função de transação com layout de tela ou
relatório/consulta do sistema
Antes de apresentarmos o enunciado do estudo de caso que usaremos para detalhar a exemplificação de
contagem de pontos de função, faremos outro pequeno exemplo, para demonstrar a contagem de funções
de transações, com base em uma janela do sistema.
Considere a janela a seguir para a funcionalidade INCLUIR ALUNOS, função de Entrada Externa (EE) para
alimentar o ALI ALUNO.
Layout da tela de Inclusão de Aluno.
A janela contém 20 tipos de dados (TD) e • 1 arquivo referenciado (AR), sendo os tipos de dados (TD):
17 Campos de dados digitados + 1 dado, de nome ATIVO, que será registrado como “SIM” ao ser incluído
= 18 campos de dados. Existe um campo, oculto na tela, mas definido no modelo de dados, que é o
campo ATIVO, que indica se o aluno está ativo (SIM) ou não ativo (NÃO);
Comando (botão confirmar);
Mensagem, em caso de erro.
Consultando a tabela Complexidade da função de transação chamada Entrada Externa, teremos que nessa
EE (Entrada Externa) são 20 TD e 1 AR, que levam a uma complexidade MÉDIA. Consultando a tabela
Complexidade x Pontos de Função de cada tipo de função de dado e transação, temos que tal
complexidade de EE, são 4 pontos de função.
Exemplo com relatórios
Vejamos um exemplo com um relatório, que exibe todos os campos (19 tipos de dados) dos alunos
cadastrados em um curso. O relatório exige que seja selecionado o curso desejado e, ao fim, mostra a
quantidade de alunos do curso ativos e quantidade de alunos do curso inativos. Por apresentar totais de
alunosativos e inativos (processamento), a função é classificada como Saída Externa (SE).
• Tipos de dados = 24 TD;
Curso selecionado (1) + Botão Confirmar (1);
18 campos de dados;
Total de ativos e total de inativos (2);
Botão Imprimir;
Mensagem de erro ao usuário;
• Arquivos referenciados (AR) = 1 = ALI ALUNO.
Consultando a tabela Complexidade das funções de transação chamadas SE e CE, temos que: 24 TD + 1 AR
= complexidade média. Na tabela Complexidade x Pontos de Função de cada tipo de função de dado e
transação, vemos que SE, com complexidade MÉDIA, computa 5 pontos de função.
Aplicação em estudo de caso: sistema acadêmico
Vamos, agora, aplicar a contagem no projeto de desenvolvimento de um novo sistema. Consideremos os
seguintes documentos, elaborados nas fases de análise e projeto de um sistema. O sistema chama-se
ACADEMICO e tem como objetivo geral controlar dados de alunos matriculados, cursos oferecidos e
períodos letivos, de modo a permitir a avaliação de cada aluno.
Atenção!
Os dados usados para a contagem advêm da documentação realizada pela equipe que desenvolve o
software, ou, na ausência de documentação, a equipe de contagem de PF deve providenciar, por meio de
modelagem dos artefatos de desenvolvimento. Minimamente, devemos ter de início um modelo de
requisitos e um modelo de dados.
Modelos de requisitos
Um modelo de requisitos, ou a sua tradução em um diagrama de casos de uso, são os documentos mais
comuns que podem ser encontrados nas empresas, hoje em dia. No estudo de caso, vamos partir da
declaração de requisitos funcionais (RF) do sistema, conforme tabela a seguir.
RF Descrição
RF01 Registrar período letivo
RF02 Registrar novo curso
RF03 Registrar turmas ofertadas
RF04 Matricular aluno no curso
RF05 Avaliar aluno
RF06 Emitir relatório de avaliação
Tabela: Requisitos Funcionais do Sistema Acadêmico.
Elaborada por: Marcelo Vasques de Oliveira.
Modelo de dados
É importante que tenhamos um modelo conceitual de dados para apurarmos a contagem dos ALI ou AIE
(Arquivo Lógico Interno e Arquivo de Interface Externa). A imagem, a seguir, mostra o modelo de entidades e
relacionamentos (MER) dos dados do sistema ACADEMICO. Devemos destacar que a aplicação exemplo
não possui nenhum AIE (Arquivo de Interface Externa), sendo todos os arquivos do tipo ALI (Arquivo Lógico
Interno) e, portanto, alimentados pelo sistema.
MER do Sistema Acadêmico.
Layout de telas e relatórios do sistema
A obtenção dos layouts das telas de entrada de dados, relatórios e consultas do sistema são importantes
para podermos apurar com mais propriedade as funções de dados e transação. Contudo, tais documentos
somente são elaborados pela equipe de desenvolvimento na fase de projeto ou de análise, caso a equipe
use prototipação ou derive, de imediato, telas (entradas) e relatórios (saídas) diretamente dos casos de uso.
Layout de telas.
A contagem
O processo de contagem se divide em 6 passos que veremos a seguir.
Passo 1
Vamos apurar a contagem de PF das funções de dados (ALI e AIE), com base no modelo de dados
apresentado na imagem MER do Sistema Acadêmico. Conforme descrito, o sistema tem apenas ALI. Na
contagem de TD, computamos em cada arquivo lógico, os campos que relacionam um arquivo a outro. A
seguir, vamos montar a tabela contando os campos TD e TR pelo MER. No caso, todos os arquivos internos
possuem TR (Tipos de Registro) = 1.
Feita a apuração descrita, consultamos a tabela Complexidade das funções de dados: ALI e AIE e
identificamos a complexidade de cada ALI e depois pela tabela Complexidade x Pontos de Função de cada
tipo de função de dado e transação, transformamos a complexidade em pontos de função.
Arquivo Lógico TD TR Complexidade PArquivo Lógico TD TR Complexidade P
Curso (ALI) 2 1 Baixa 7
Turma (ALI) 4 1 Baixa 7
Curso (ALI) 4 1 Baixa 7
Período (ALI) 3 1 Baixa 7
Matrícula (ALI) 4 1 Baixa 7
Aluno (ALI) 17 1 Baixa 7
Matrícula_Avaliada 4 1 Baixa 7
Apuração da pontuação em PF dos Arquivos Lógicos do Sistema Acadêmico.
Elaborada por: Marcelo Vasques de Oliveira.
Os arquivos internos, que nesse sistema se resumem
a ALI, computam 7 x 7 = 49 PF.
Passo 2
Vamos apurar as funções de transação, com base inicialmente na lista de requisitos e, na sequência,
avaliando o layout das telas, apresentados com a contagem de cada transação.
Essa função registra (inclui) os dados do período letivo no sistema.
Tipo de função: ENTRADA EXTERNA (EE) - 3 PF
Tipos de dados: 0 + 3 + 1 + 1 = 5 TD
Nenhum parâmetro precisa ser digitado para acesso a tela de cadastro de período: 0
RF01 - Registrar período letivo 
Campos de dados a serem digitados pelo usuário (MER): 3
Botão Confirmar: 1
Mensagem de erro ao usuário: 1
Arquivos referenciados: ALI PERIODO: 1 AR
A seguir, a imagem ilustra o layout da tela de entrada de dados para registro do período. Consultando
a tabela Complexidade da função de transação chamada Entrada Externa (EE), de EE, temos que
uma EE com 5 TD e 1 AR nos leva a uma pequena complexidade BAIXA, que é traduzida (na tabela
Complexidade x Pontos de Função de cada tipo de função de dado e transação) em 3 PF.
Tela da transação Registrar Período Letivo.
Essa função registra (inclui) os dados do período letivo no sistema.
Tipo de função: ENTRADA EXTERNA (EE) - 3 PF
Tipos de dados: 0 + 2 + 1 + 1 = 4 TD
Nenhum parâmetro precisa ser digitado para acesso a tela de cadastro de período: 0
Campos de dados a serem digitados pelo usuário (MER): 2
Botão Confirmar: 1
Mensagem de erro ao usuário: 1
Arquivos referenciados: ALI CURSO: 1 AR
A seguir, a imagem ilustra o layout da tela de entrada de dados para registro do novo curso.
Consultando a tabela Complexidade da função de transação chamada Entrada Externa (EE), temos
que uma EE com 4 TD e 1 AR nos leva a uma pequena complexidade BAIXA, que é traduzida (na
tabela Complexidade x Pontos de Função de cada tipo de função de dado e transação) em 3 PF.
RF02 - Registrar novo curso 
Tela da transação Registrar Novo Curso.
Essa função registra (inclui) os dados do período letivo no sistema.
Tipo de função: ENTRADA EXTERNA (EE) - 6 PF
Tipos de dados: 0 + 4 + 1 + 1 = 6 TD
Nenhum parâmetro precisa ser digitado para acesso a tela de cadastro de período: 0
Campos de dados a serem digitados pelo usuário (MER): 4
Botão Confirmar: 1
Mensagem de erro ao usuário: 1
Arquivos referenciados: ALI CURSO (selecionar o curso), ALI PERIODO (selecionar Período), ALI
TURMA (registrar a oferta de turma): 3 AR
A seguir, a imagem ilustra o layout da tela de entrada de dados para registro das turmas ofertadas.
Consultando a tabela Complexidade da função de transação chamada Entrada Externa (EE), temos
que uma EE com 6 TD e 3 AR nos leva a uma pequena complexidade ALTA, que é traduzida (na tabela
Complexidade x Pontos de Função de cada tipo de função de dado e transação) em 6 PF.
Tela da transação Registrar Turmas Ofertadas.
RF03 - Registrar Turmas ofertadas 
Essa função registra (inclui) os dados do período letivo no sistema.
Tipo de função: ENTRADA EXTERNA (EE) - 6 PF
Tipos de dados: 0 + 4 + 1 + 1 = 6 TD
Nenhum parâmetro precisa ser digitado para acesso a tela de cadastro de período: 0
Campos de dados a serem digitados pelo usuário (MER): 4
Botão Confirmar: 1
Mensagem de erro ao usuário: 1
Arquivos referenciados: ALI CURSO (selecionar o curso), ALI PERIODO (selecionar Período), ALI
TURMA (selecionar a turma) e ALI MATRICULA (registrar a matrícula do aluno): 4 AR
A seguir, a imagem ilustra o layout da tela de entrada de dados para registro da matrícula do aluno no
curso. Consultando a tabela Complexidade da função de transação chamada Entrada Externa (EE),
temos que uma EE com 6 TD e 4 AR nos leva a uma pequena complexidade ALTA, que é traduzida (na
tabela Complexidade x Pontos de Função de cada tipo de função de dado e transação) em 6 PF.
Tela da transação Registrar Aluno no curso.
Essa função registra (inclui) os dados do período letivo no sistema.
Tipo de função: ENTRADA EXTERNA(EE) - 4 PF
Tipos de dados: 0 + 4 + 1 + 1 = 6 TD
Nenhum parâmetro precisa ser digitado para acesso a tela de cadastro de período: 0
RF04 - Matricular Aluno no curso 
RF05 - Avaliar Aluno 
Campos de dados a serem digitados pelo usuário (MER): 4
Botão Confirmar: 1
Mensagem de erro ao usuário: 1
Arquivos referenciados: ALI MATRICULA (registrar a matrícula do aluno) e ALI
MATRICULA_AVALIADA (registrar a avaliação – nota final do aluno): 2 AR
A imagem, a seguir, ilustra o layout da tela de entrada de dados para registro da Avaliação do aluno
no curso. Consultando a tabela Complexidade da função de transação chamada Entrada Externa
(EE), temos que uma EE com 6 TD e 2 AR nos leva a uma pequena complexidade MÉDIA, que é
traduzida (na tabela Complexidade x Pontos de Função de cada tipo de função de dado e transação)
em 4 PF.
Tela da transação Avaliar Aluno.
Esse relatório mostra dados do aluno (Matrícula, Nome, Código do curso, Nome do curso, Período e
Nota final), por curso, que será selecionado inicialmente. Ao final, o relatório apresenta: média dos
alunos, maior nota, menor nota e desvio padrão.
Essa função de transação é uma Saída Externa, pois existe processamento dos cálculos ao final do
relatório (média dos alunos, maior nota, menor nota e desvio padrão). Essa função obtém os dados
do período letivo no sistema.
Tipo de função: ENTRADA EXTERNA (EE) - 4 PF
Tipos de dados: 1 + 1 + 6 + 1 + 1 = 10 TD
Parâmetro do relatório: usuário vai selecionar o curso cujos dados de alunos serão exibidos:
1
Campos de dados a serem exibidos: Matric, Nome Aluno, Código do curso, Nome do Curso,
Período e Nota final do aluno: 6
RF06 - Emitir relatório de avaliação 
Botão Confirmar: 1
Mensagem de erro ao usuário: 1
Totais: média, maior nota, menor nota e desvio padrão: 4
Arquivos referenciados: ALI CURSO (selecionar o curso e extrair nome do curso), ALI ALUNO
(extrair o nome do aluno) e ALI MATRICULA AVALIADA (extrair MatricAluno e Nota Final): 3
A imagem, a seguir, ilustra o layout do relatório de avaliação. Consultando a tabela Complexidade da
função de transação chamada Entrada Externa (EE), temos que uma SE com 10 TD e 3 AR nos leva a
uma pequena complexidade MÉDIA, que é traduzida (na tabela Complexidade x Pontos de Função de
cada tipo de função de dado e transação) em 5 PF.
Layout do Relatório de Avaliação.
Passo 3
Agora, vamos agrupar todas as funções de dados e transações e somar o PF individual de cada uma,
perfazendo o total de PF não ajustados do sistema.
Na tabela a seguir, temos a apuração da pontuação dos arquivos lógicos do Sistema Acadêmico.
Arquivo Lógico TD TR-AR Complexidade P
Curso (ALI) 2 1 Baixa 7
Turma (ALI) 4 1 Baixa 7
Curso (ALI) 4 1 Baixa 7
Período (ALI) 3 1 Baixa 7
Matrícula (ALI) 4 1 Baixa 7
Arquivo Lógico TD TR-AR Complexidade P
Aluno (ALI) 17 1 Baixa 7
Matrícula_Avaliada 4 1 Baixa 7
TOTAL 4
Tabela: Apuração da pontuação em PF dos arquivos lógicos do Sistema Acadêmico.
Elaborada por: Marcelo Vasques de Oliveira.
Na próxima tabela, temos a apuração da pontuação das funções de transação Sistema Acadêmico.
Função Transação TD AR Complexidade P
Registrar período
letivo (EE)
5 1 Baixa 3
Registrar novo
curso (EE)
4 1 Baixa 3
Registrar Turmas
ofertadas (EE)
6 3 Alta 6
Matricular Aluno no
curso (EE)
6 4 Alta 6
Avaliar Aluno (EE) 6 2 Média 4
Emitir relatório de
avaliação (EE)
10 3 Média 5
TOTAL 2
Tabela: Apuração da pontuação em PF das funções de transação Sistema Acadêmico.
Elaborada por: Marcelo Vasques de Oliveira.
A partir das duas tabelas anteriores, verificamos que:
O sistema tem 49 + 27 = 76 pontos de função não
ajustados (PFNA).
Passo 4
Vamos determinar o fator de ajuste, com base na avaliação das características gerais do sistema, conforme
classificação de cada item, na tabela Apuração da pontuação das Características Gerais do Sistema
Acadêmico, a seguir.
CGS Pontos
Comunicação de dados 1
Processamento distribuído 1
Performance 5
Configuração altamente utilizada 1
Volume de transações 3
Entrada de dados on-line 5
Eficiência de usuário final 1
Atualização on-line 1
Complexidade do processamento 1
Reusabilidade 1
Facilidade de instalação 1
Facilidade de operação 5
Múltiplos locais 1
CGS Pontos
Facilidade de mudanças 5
Total pontos 32
Tabela: Apuração da pontuação das Características Gerais do Sistema Acadêmico.
Elaborada por: Marcelo Vasques de Oliveira.
A base dessa classificação é a declaração de requisitos não funcionais, constantes da documentação do
sistema, por exemplo, para esse estudo de caso:
Passo 5
Agora, iremos calcular o Fator de Ajuste (VFA):
VFA = (TDI * 0,01) + 0,65,
VFA = (32 * 0,01) + 0,65 = 0,32 + 0,65 = 0,97
Observe que TDI é igual a 32, pois corresponde ao somatório de todos os níveis de influência das 14
características gerais do sistema (Coluna Pontos da tabela Apuração da pontuação das Características
Gerais do Sistema Acadêmico).
O fator de ajuste é 0,97.
Passo 6
Sistema deve ter alta
performance, prezado pelo
processamento rápido.
Sistema com médio volume
de transações.
Sistema deve ser dotado de
alta usabilidade, com poucos
cliques a cada ação.
Nosso último passo é calcular os pontos de função ajustados do sistema (PFA):
PFA = PFNA * VFA
PNFA corresponde aos pontos de função não ajustados, ou seja, a soma dos pontos de função das funções
entregues. Assim, de acordo com o passo 3, PNFA = 76 PF.
VFA = 0,97
PFA = 76 * 0,97 = 73,72
Atenção!
Se arredondarmos, podemos dizer que o Sistema Acadêmico computou 74 pontos de função ajustados.
Pontos relevantes na contagem de PF
Os pontos relevantes e de atenção na realização de uma contagem de Pontos de Função, usando a
metodologia do IFPUG, são apresentados no vídeo a seguir.
Vem que eu te explico!
Os vídeos a seguir abordam os assuntos mais relevantes do conteúdo que você acabou de estudar.


Módulo 1 - Vem que eu te explico!
Tabelas da contagem em Pontos de Função (PF)
Por que usar APF para medir tamanho do software?
Módulo 1 - Vem que eu te explico!
Exemplo de contagem de Arquivos Lógicos com um modelo de dados
Por que medir funções de dados na APF?
Módulo 1 - Vem que eu te explico!
Exemplo de contagem de função de transação com layout de uma tela ou relatório/consulta do sistema
Por que medir funções de transações na APF?
Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
Considere o layout de um relatório e respectivas informações pertinentes a seguir.
Relatório de pedido do cliente Pessoa física
Relatório de pedido do cliente Pessoa física
Nome do cliente:______________ Período __/__/__ a __/__/__
Data Pedido Status Pedido Num Pedido Itens Pedido T
...... ...... ...... ...... ..
...... ...... ...... ...... ..
- - - - -
TOTAL 9
Relatório de pedidos do cliente PF.
Antes de gerar o relatório, o cliente seleciona CLIENTE e PERÍODO para o qual deseja o relatório. Para gerar
o relatório mostrado, deve-se consultar o ALI CLIENTE para obter o nome do cliente, o ALI PEDIDOS para
obter, diretamente, os campos Data Pedido, Status Pedido e Num Pedido, assim como calcular os campos
(Itens no Pedido e Total Pedido). Quantos pontos de função terá a funcionalidade de transação que gera o
relatório?
A 4
B 6
C 5
D 7
E 3
Parabéns! A alternativa C está correta.
Contagem de tipos de dados (TD) = Cliente + Data Inicial + Data Final + comando (do botão
confirmar) + Mensagem para usuário + 3 campos diretos e 2 campos calculados + Total Pedidos
= 11 TD.
Contagem de arquivos referenciados = ALI CLIENTES e ALI PEDIDOS = 2.
Consultando a tabela de Saídas Externas, pois há processamento e totais, temos complexidade
MÉDIA, que pontua 5 PF.
Questão 2
2016 - CESPE – FUNPRESP-EXE – Especialista – Tecnologia da Informação. Adaptada por Marcelo
Vasques. Observe a imagem a seguir:
Aplicação X Aplicação 
Qualidade
Complexidade
funcional
Qualidade
Arquivo de
Interface Externa
(AIE)
3 Baixa 3
Arquivo Lógico
Interno (ALI)
1 Baixa 1
EntradaExterna
(EE)
2 Alta 1
Saida Externa (SE) 3 Média 2
Consulta
Externa(CE)
1 Alta 1
Pontos de função das aplicações X e Y.
Assinale a única alternativa que apresenta corretamente e na ordem, o número de pontos de função das
aplicações X e Y.
A 61 e 55
B 55 e 61
C 54 e 62
D 62 e 54
E 55 e 55
Parabéns! A alternativa A está correta.
Aplicação X
Tipo de
Função
Quantidade Complexidade PF
Total
PF
AIE 3 Baixa 5 15
ALI 1 Baixa 7 7
EE 3 Alta 6 18
SE 3 Média 5 15
CE 1 Alta 6 6
Total 61
Aplicação Y
Tipo de
Função
Quantidade Complexidade PF
Total
PF
2 - Métricas e estimativas
Ao �nal deste módulo, você será capaz de de�nir métricas e estimativas com base nos pontos
de função.
Tipo de
Função
Quantidade Complexidade PF
Total
PF
AIE 3 Média 7 21
ALI 1 Alta 15 15
EE 1 Baixa 3 3
SE 2 Média 5 10
CE 1 Alta 6 6
Total 55

Métricas e estimativas
Métricas e estimativas estão intimamente relacionadas.
Métricas
São medidas que podem ser quantificadas. A técnica de pontos de função resulta em uma métrica
indireta: o tamanho funcional do software.
Estimativas
São cálculos aproximados; contudo, uma vez comprovadas consistentes e positivas, as estimativas de
ontem podem ser as métricas de amanhã.
Métricas são estimativas que deram certo, por isso,
temos que guardar o histórico.
Para se ter estimativas, precisamos de métricas que as balizem. Para estimarmos o esforço de
desenvolvimento de um software, podemos usar a quantidades de pontos de função (métricas). Se
repetidas vezes, de forma consistente, essas estimativas de esforço vão se confirmando, podemos criar
novas métricas baseadas nessas estimativas que deram certo.
E estimativas podem gerar métricas futuras. Após a conclusão e entrega de um software, os históricos de
estimativas são úteis para gerar métricas que ajudem nos próximos desenvolvimentos.
Exemplo
No início do projeto, a medida do esforço para desenvolver o software pode ser estimada com base em seu
tamanho funcional. Ao final do projeto, tais estimativas podem gerar novas métricas, visando à construção
de benchmarking da própria empresa. Explicando melhor, no início, não temos dados reais desse projeto que
será desenvolvido, mas podemos ter dados históricos de projetos de softwares anteriores. Então,

inicialmente, estimamos o esforço, com base na métrica de pontos de função. Contudo, ao final do projeto,
podemos medir, por exemplo, as taxas de erros das estimativas, gerando uma nova métrica que possa ser
útil no futuro.
Para termos estimativas consistentes, precisamos do histórico de dados mantidos pela organização ou
benchmarking de mercado. Por exemplo, através de dados históricos, podemos obter uma tabela de
benchmarking que mostre a produtividade com base em escalas de pontos de função.
A empresa pode calcular, com base em seu histórico, o valor em reais do ponto de função, que seria uma
métrica; contudo, deve considerar a experiência da equipe, complexidade do software e outros fatores. Indo
além, podemos calcular o valor em reais do ponto de função para determinada plataforma tecnológica (rede
cliente servidor, rede distribuída) ou para a linguagem de programação.
As estimativas possuem certo grau de incerteza e valem-se de premissas, como “a capacidade de
desenvolvimento do time é constante”, mas sabemos que existem variações da produtividade da mesma
pessoa em momentos distintos e de diferentes pessoas.
Curiosidade
O governo federal brasileiro aplicava, até pouco tempo, pontos de função em contratos para
desenvolvimento e manutenção de seus sistemas, para pagamento e aferição do serviço prestado,
estabelecendo em seus editais tabelas com escalas de valores em reais por ponto de função, por exemplo,
R$100,00 por PF.
Estimativas
As estimativas são necessárias desde o primeiro momento
A preocupação do gestor com custo e tempo de projeto de software para o desenvolvimento de um novo
sistema, ou para a manutenção de um existente, ou aquisição e customização de um sistema pronto, são as
primeiras e principais questões que aparecem, tão logo haja a confirmação da necessidade do sistema.
No passado, era comum arguir os clientes sobre as reais necessidades dos usuários do sistema a ser
desenvolvido e sobre o escopo dele, antes da definição do custo e do prazo do projeto. Considerando o
contexto atual, em que as empresas desenvolvem software internamente ou contratam fábricas de
software, tais questionamentos são desdobrados para os gestores de nível médio, que imediatamente
questionam:

Quantas pessoas do time teremos que deslocar para o projeto?


Teremos que contratar?

Nosso histórico de estimativas tem sido realizado para balizar novos
desenvolvimentos ou aquisição de software?

Qual foi o último projeto semelhante que desenvolvemos? Temos os
registros das estimativas e dados reais?
As estimativas x incertezas
Conforme ilustrado na imagem a seguir, os momentos iniciais do processo de desenvolvimento,
manutenção ou aquisição de um software são os mais incertos, na medida em que conhecemos pouco ou
quase nada dos verdadeiros requisitos desse sistema. Determinar com exatidão o custo final e a data de
conclusão do projeto de software apenas é possível ao seu término, quando for entregue. Antes disso, tudo
será estimativa, por mais complexos e rigorosos que sejam os cálculos.
As incertezas nos projetos de desenvolvimento de software.
Geralmente, as estimativas nos momentos iniciais do projeto envolvem mais incertezas. Contudo, as
empresas podem criar mecanismos que possam amentar a probabilidade de acerto, considerando, por
exemplo, o registro histórico de estimativas e dados reais do projeto, permitindo a análise previsto x
realizado e concluir com as lições aprendidas. Ou seja, a partir de uma base de dados histórica, de
estimativas e realizados, a empresa pode tornar-se mais assertiva, e suas estimativas, cada vez mais
próximas da realidade. Consequentemente:

As estimativas podem ser realizadas o mais cedo possível, com
maior segurança.

O desenvolvimento conta com melhores planejamento, organização e
controle.

As decisões podem ser tomadas com mais rapidez.

O desenvolvimento é menos oneroso para a organização.
O processo de estimativas de um projeto de software
O processo de estimativa, em geral, considera as seguintes medidas relevantes para os gestores e equipe de
desenvolvimento:

Tamanho do produto

Esforço (mão de obra x tempo)

Tempo e o cronograma

Custo
Em nosso conteúdo, a base para as quatro estimativas citadas é a contagem ou estimativa de pontos de
função. Uma alternativa para a base das estimativas é a técnica LOC. Vejamos mais detalhes dessas duas
técnicas:
LOC (considera Linhas do Código fonte, do inglês Lines of Code) somente começa a tornar-se
confiável em pontos avançados da fase de projeto de software, retardando a geração de indicadores
de gerenciamento. Para usar LOC, é crucial que se saiba logo a linguagem de programação a ser
usada, o que nem sempre é possível no início da fase de projeto. LOC nem sempre orienta
corretamente quanto ao tamanho, pois a reutilização de código e o uso de componentes têm seus
indicadores prejudicados, se baseados em LOC.
Os PF não dependem da tecnologia, como LOC, mas do conhecimento da funcionalidade requerida
para o software. Estimativas com pontos de função podem, portanto, ser usadas mais cedo no
processo de desenvolvimento de software, tão logo tenhamos a lista de requisitos e funcionalidades
do sistema.
Atenção!
A técnica de pontos de função é considerada mais versátil, porque colhe estimativas mais cedo no processo
de desenvolvimento e, portanto, mais adequada.
Decidida a técnica a ser usada para obtenção do tamanho do software, seja em LOC ou pontos de função,
pode-se usar o processo de estimativas, conforme imagem a seguir.
Processo de estimativas.
LOC 
Pontos de função 
O processo de estimativas começa nos momentos iniciais do desenvolvimento do projeto. Deve consideraros dados necessários a contagem ou estimativa de pontos de função, registro dos dados históricos dos
projetos anteriores, os recursos disponíveis na organização (dentro e fora), e os fatores de risco inerentes ao
projeto. A cada etapa, as estimativas geradas devem ser aprovadas e registradas, servindo de input para as
fases seguintes. A cada fase, deve-se reestimar o que for necessário. Ao final do processo, com o produto
de software construído, deve-se registrar na base histórica os dados reais do tamanho, do esforço, da
duração e do custo.
Estimativa do tamanho do produto
Esse é o primeiro passo e requer inicialmente a definição da forma de estimativa, que pode ser obtida de
várias formas; dentre elas, destaca-se a contagem indicativa, publicada em um trabalho pela NESMA.
A NESMA reconhece três tipos de contagem de pontos de função: detalhada, estimativa e indicativa.
Veremos cada tipo a partir de agora.
NESMA
Netherlands Software Metrics Association (NESMA), em português, Associação de Métricas de Software da
Holanda, uma instituição sediada na Holanda que fornece um manual de contagem similar ao Counting
Pratices Manual (CPM), fornecido pelo IFPUG. As regras são bem próximas às aplicadas pelo IFPUG, com
algumas diretrizes diferenciadas.
Contagem Detalhada
É a contagem usual de pontos de função, conforme determina o IFPUG, que aplicamos no estudo de caso.
Em linhas gerais:
Determina as funções de dados (ALI e AIE) e transações (EE, SE e CE).
Determina a complexidade de cada função.
Transforma a complexidade em pontos de função.
A tabela a seguir apresenta um exemplo de contagem detalhada.
Tipo Qtde Complexidade PF não ajustado
Pedidos ALI Média 10
Clientes ALI Baixa 7
Produtos AIE Baixa 5
Fornecedores AIE Baixa 5
Incluir Pedidos EE Alta 6
Alterar Pedidos EE Média 4
Excluir Pedidos EE Baixa 3
Consultar Pedidos CE Baixa 3
Relatório Tipo 1
Pedidos
SE Baixa 4
Relatório Tipo 2
Pedidos
SE Média 5
Relatório Tipo 3
Pedidos
SE Baixa 4
Relatório dos 10
melhores clientes
SE Alta 7
Calcula o total de pontos de função não ajustados.
Tipo Qtde Complexidade PF não ajustado
Incluir Cliente EE Média 4
Alterar Cliente EE Baixa 3
Excluir Cliente EE Baixa 3
Consultar Cliente CE Baixa 3
Consultar Fornecedor CE Baixa 3
Relatório 10 produtos
mais vendidos
SE Média 5
Total de PF 84
Tabela: PF por funcionalidade – Detalhada.
Elaborada por: Marcelo Vasques de Oliveira
Contagem Estimativa
Como o nome sugere, essa contagem estima a complexidade de funções de dados e transações, da
seguinte maneira:
Determina as funções de dados (ALI e AIE) e transações (EE, SE e CE).
Toda função de dado (ALI ou AIE) tem complexidade baixa e toda função de transação (EE, SE e CE)
tem complexidade média.
Transforma a complexidade em pontos de função.
É similar à contagem detalhada, exceto pelo fato de agrupar a complexidade de funções de dados e funções
e não determinar igualmente a complexidade de cada função. Pode ser realizada desde as especificações
iniciais, com declarações de requisitos com mais detalhes, por exemplo:
A tabela a seguir apresenta um exemplo de contagem estimativa.
Tipo Qtde Complexidade PF não ajustado
Pedidos ALI Baixa 7
Clientes ALI Baixa 7
Produtos AIE Baixa 5
Fornecedores AIE Baixa 5
Incluir Pedidos EE Média 4
Alterar Pedidos EE Média 4
Excluir Pedidos EE Média 4
Consultar Pedidos CE Média 4
Relatório Tipo 1
Pedidos
SE Média 5
Calcula o total de pontos de função não ajustados.
“O sistema precisa incluir,
alterar, excluir e consultar
dados de Pedidos”.
“O sistema precisa de três
diferentes tipos de relatórios
de Pedidos, contendo campos
calculados”.
“O sistema precisa de um
relatório com os dez melhores
clientes”.
Tipo Qtde Complexidade PF não ajustado
Relatório Tipo 2
Pedidos
SE Média 5
Relatório Tipo 3
Pedidos
SE Média 5
Relatório dos 10
melhores clientes
SE Média 5
Incluir Cliente EE Média 4
Alterar Cliente EE Média 4
Excluir Cliente EE Média 4
Consultar Cliente CE Média 4
Consultar Fornecedor CE Média 4
Relatório 10 produtos
mais vendidos
SE Média 5
Total de PF 85
Tabela: PF por funcionalidade – Estimativa.
Elaborada por: Marcelo Vasques de Oliveira
Observe que o resultado foi PF = 85 PF. Na verdade, bastava que estimássemos a quantidade de cada tipo
de função, conforme a próxima tabela.
Tipo de função Quantidade Complexidade PF T
ALI 2 Baixa 7 1
AIE 2 Baixa 5 1
EE 6 Média 4 2
Tipo de função Quantidade Complexidade PF T
CE 3 Média 4 1
SE 5 Média 5 2
Total de PF 8
Tabela: PF por totais de tipo de funcionalidade.
Elaborada por: Marcelo Vasques de Oliveira
Contagem Indicativa
Conta arquivos lógicos (ALI e AIE), arbitra pesos para cada um e estima de forma indicativa cada quantidade
de função de transação, da seguinte maneira:
Essa contagem parte de duas premissas:
Existem aproximadamente três EE (incluir, alterar e excluir), duas CE e uma SE, com complexidade
média para cada ALI.
Determina a quantidade de funções de dados (ALI e AIE).
Calcula o total de pontos de função não ajustados, usando: PF = (35 * quantidade de ALI) + (15 *
quantidade de AIE).
Estimativa baseada na quantidade de arquivos lógicos (ALI e AIE).
Premissa 1 
• 3 EE médios = 3 x 4 PF = 12 PF
• 2 CE médios = 2 x 4 PF = 8 PF
• 1 SE médio = 1 x 5 PF = 5 PF
• 1 ALI médio = 1 x 10 PF = 10 PF
• Temos então: 12 + 8 + 5 + 10 = 35 PF
Existem aproximadamente uma SE e uma CE, com complexidade média para cada AIE.
• 1 CE média = 1 x 4 PF = 4 PF
• 1 SE média = 1 x 5 PF = 5 PF
• 1 AIE médio = 1 x 7 PF = 7 PF
• Temos então: 4 + 5 + 7 = 16
A Contagem Indicativa pode ser realizada desde as especificações iniciais, com declarações de requisitos
de forma resumida ou superficial, como: “O sistema precisa manter os dados dos pedidos e dos clientes e
usar os dados dos produtos”. Sendo a conclusão desse requisito:
ALI
Pedidos e Clientes
AIE
Produtos e fornecedores
Então, vamos ao cálculo:
PF = (35 * 2) + (16 *2) = 70 + 32 = 102 PF
Premissa 2 
Conclusões
Observe que as três contagens apresentam resultados próximos:
84 PF
Contagem detalhada
85 PF
Contagem estimativa
102 PF
Texto do terceiro card.
A escolha da contagem a ser usada vai depender de:

Quantidade de tempo disponível para realizar especificações mais ou menos detalhadas.
_out
Nível de informações e documentações das fases de análise e projeto do sistema.
Além disso, cada tipo de contagem pode ser usado em diferentes fases:
Pode ser realizada nas fases iniciais, quando já se tem o escopo definido e uma primeira versão dos
requisitos do sistema (sem detalhes). Precisa de um modelo de dados.
Contagem indicativa 
Pode ser usada, por exemplo, ao final da fase análise, quando já teremos uma noção dos requisitos.
Pode ser usada ao final ou no meio da fase de projeto, dependendo das demandas da equipe. Carece
de ter disponível o projeto de interface, com layout das telas, consultas, relatórios e eventuais
gráficos do sistema.
Medidas
Abordaremos agora as medidas (estimativas) necessárias ao processo de estimativas, anteriormente
descrito.
Medida de Esforço (E)
A fórmula para calcular o esforço é apresentada a seguir:
Esforço = PF * IP
Em que:
PF
Pontos de função do sistema.
IP
Produtividade da equipe, medida em P.H/PF (Pessoa.Hora/PF) - quantas horas uma pessoa gasta por ponto
de função.
Contagem estimativa 
Contagem detalhada 
O índice de produtividade varia em função de características dos projetos e da equipe envolvida, como
aderência à tecnologia, desempenho pessoal, expertise do profissional, complexidade do domínio do
problema, tamanho do projeto, tipo de manutenção, entre outros aspectos. Cada empresa deverá possuir
sua própria tabela de produtividade, pautando-se, sempre, pelos dados de projetos anteriores.
Para calcular o esforço é necessário conhecer o IP (produtividade da equipe), que varia em função do
ambiente de trabalho, expertise da equipe, fatores de produtividade (reuso de software, de componentes, de
rotinas)e outros fatores.
Exemplo
Considere:
• Uma empresa que possui uma taxa de produtividade mínima de 5 P.H/PF;
• Carga de trabalho de 130 horas por pessoa.mês.
Assim, temos:
Esforço = 85 * 5 = 425 pessoas.horas para produzir o sistema
Considerando a carga de 130 horas por pessoa mês, temos:
425 / 130 = 3,27 meses
Em geral, o esforço é calculado em Pessoa.Hora, pois dessa unidade obtém-se outros indicadores
desejados para acompanhamento do projeto, dependendo da jornada de trabalho da equipe em número de
horas por dia ou por semana, por exemplo.
Medida de duração (Tempo)
A duração do projeto ou prazo será a razão entre o esforço previsto e a quantidade de pessoas alocadas,
como apresentado a seguir.
Prazo = Esforço / Pessoas
Exemplo
Considere:
• Esforço já calculado de 425 pessoas.hora
• A jornada de trabalho é de 6 horas/dia (média usada pelas empresas)
• A equipe possui 3 pessoas.
Assim, a duração em horas será:
425 pessoas.hora / 3 pessoas = 141,67 horas
E, finalmente, o prazo em dias será:
141,67 horas / 6 horas/dia = 23,61 = 24 dias
Com base na duração e na disponibilidade de recursos, elabora-se o cronograma, que deixará claro quando
tem início e fim cada atividade do projeto e quais e quantos recursos (humanos e materiais) estarão
alocados a cada atividade do projeto.
Comentário
A duração (tempo) de um projeto não é proporcional ao número de pessoas que trabalham nele. A adição de
mais pessoas a um projeto atrasado pode aumentar o tempo para finalizá-lo, pois há o tempo de inércia
dessa nova pessoa para se adaptar e conhecer o contexto.
Medida de custo
O custo estimado do projeto será a multiplicação do esforço necessário, em horas, pelo custo da hora da
equipe, como apresentado a seguir:
Custo = Esforço * Custo / hora
Para calcular o custo é necessário conhecer o custo da hora da equipe de desenvolvimento, ou o valor do
ponto de função para a empresa.
Exemplo
Considere:
• Esforço já calculado de 425 pessoas.hora
• Valor da hora de trabalho de uma pessoa = R$ 25,00
Assim:
Esforço * (Valor da hora de uma pessoa)
Custo = 425,00 * 25,00 = R$ 10.625,00
Métricas e estimativas derivadas de Pontos de Função
Abordaremos agora as diferenças entre métricas e estimativas e destacaremos as métricas e estimativas
que podem ser derivadas a partir da contagem (ou estimativa) de pontos de função.
Vem que eu te explico!
Os vídeos a seguir abordam os assuntos mais relevantes do conteúdo que você acabou de estudar.
Módulo 2 - Vem que eu te explico!
Métricas e estimativas
Motivação e resumo sobre métricas e estimativas
Módulo 2 - Vem que eu te explico!
O processo de estimativas de um projeto de software
Contagem e estimativas de PF
Módulo 2 - Vem que eu te explico!
Medidas
Medidas de esforço, tempo e custo


Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
Um sistema de controle de elevadores foi estimado com 1.100 PF (pontos de função). De acordo com os
dados históricos da empresa, registrados por 10 anos, os desenvolvedores conseguem desenvolver 0,8 PF
por hora. Qual o esforço necessário a esse sistema?
A 8.000
B 1.000
C 1.375
D 800
E 375
Parabéns! A alternativa C está correta.
Dados: Sistema com 1.100 PF; equipe produz 0,8 PF por hora. Aplicando regra de três:
1h = 0,8 PF
Xh = 1.100 PF
0,8 X = 1.100
X = 1.100 / 0,8
X = 1.375, ou seja, o esforço é de 1.375 horas.
Questão 2
Um sistema de controle de elevadores foi estimado com 1.100 PF (pontos de função). De acordo com os
dados históricos da empresa, registrados por 10 anos, os desenvolvedores conseguem desenvolver 0,8 PF
por hora. A hora de desenvolvimento é de R$100,00 por pessoa. No projeto, são alocadas 4 pessoas e são
necessárias 1.375 horas. Qual o custo do sistema?
A 137.500,00
B 550.000,00
C 13.750,00
D 1.375.000,00
E 34.375,00
Parabéns! A alternativa A está correta.
Custo = Esforço * Custo / hora
Dados de entrada: Esforço = 1.375 horas; Custo/hora = 100,00
Custo = 1.375 * 100,00
Custo = R$137.500,00.

Considerações �nais
Como vimos, na análise de ponto de função (APF), a contagem detalhada requer um conjunto de
documentos elaborados durante o processo de desenvolvimento. Mas tais documentos vão sendo
elaborados à medida que o projeto avança em suas fases. Nas fases iniciais, em que temos pouca
informação sobre o sistema e seus requisitos, devemos usar contagens estimadas. Estudamos dois tipos
de contagens estimativas, reconhecidas pelo mercado: a contagem estimativa e a contagem indicativa. A
indicativa, a mais simples, requer que saibamos, apenas, as quantidades de arquivos lógicos do sistema
(tanto ALI como AIE) e, com base em premissas, pressupomos as funções de transações, aplicando a
fórmula que aloca pesos para os ALI e para os AIE. Esse procedimento pode ser realizado nos momentos
iniciais, quando já tivermos noção dos dados a serem armazenados. Em um segundo momento, poderemos
usar a contagem estimativa, que requer conhecimento de funções de transações, além das de dados.
Aprendemos também que, a partir do tamanho funcional do sistema (contada ou estimada), podemos
derivar importantes métricas que vão nortear o processo de desenvolvimento, como esforço, tempo e custo,
com base em um processo que pode ser aplicado em todo processo de desenvolvimento.
Podcast
Ouça um resumo com questões importantes sobre os pontos de função.

Referências
INTERNATIONAL FUNCTION POINT USERS GROUP. Manual de Práticas de Contagem. Nova Jersey: IFPUG,
2009.
SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Pearson Education do Brasil. 2018.
VASQUEZ, C. E.; SIMÕES, G. S.; ALBERT R. M. Análise de pontos de função: medição, estimativas e
gerenciamento de projeto. 13. ed. ampliada e revisada. São Paulo: Érica, 2013.
VETTORAZZO, A. S. Engenharia de Software. Porto Alegre: SAGAH; 2018, p. 28-34.
WAZLAWICK, R. S. Engenharia de Software: conceitos e práticas. Rio de Janeiro: Elsevier, 2013, p. 129-178.
Explore +
Veja mais detalhes sobre a análise de pontos de função e estimativas derivadas no site da DevMedia.
Conheça o International Software BenchMark Standards Group (ISBSG), que é ligado ao IFPUG.
Conheça a NESMA, organização que reconhece três métodos de análise de pontos de função.
 Baixar conteúdo
javascript:CriaPDF()