Av.

das Nações Unidas, 7221, 1º Andar, Setor B

Pinheiros – São Paulo – SP – CEP: 05425-902

SAC 0800-0117875
De 2ª a 6ª, das 8h às 18h
www.editorasaraiva.com.br/contato

Vice-presidente Claudio Lensing

Coordenadora editorial Rosiane Ap. Marinho Botelho
Editora de aquisições Rosana Ap. Alves dos Santos
Assistente de aquisições Mônica Gonçalves Dias
Editores AMárcia da Cruz Nóboa Leme / Silvia Campos Ferreira

Assistente editorial Paula Hercy Cardoso Craveiro / Raquel F. Abranches

Editor de arte Kleber Monteiro de Messas
Assistente de produção Fabio Augusto Ramos / Katia Regina Pereira
Produção gráfica Sergio Luiz P. Lopes
Edição Rosana Arruda da Silva
Preparação Olívia Yumi
Revisão Ana Paula Felippe
Diagramação Villa d’Artes Soluções Gráficas
Imagens e esquemas Arivelto Bustamente Fialho
Projeto gráfico de capa M10
815.770.005.001

Dados Internacionais de Catalogação na Publicação (CIP)

Angélica Ilacqua CRB-8/7057

Baddini, Francisco Carlos

Implantação e gerenciamento de redes com Microsoft
Windows 10 Pro / Francisco Baddini, Reinaldo do Valle Junior. –
São Paulo : Érica, 2016.
224 p.
Bibliografia
ISBN 978-85-365-2872-8
1. Redes de computadores 2. Arquitetura de rede de computador
3. Windows (Sistema operacional de computador)
I. Título II. Valle Junior, Reinaldo do
16-0499

Índices para catálogo sistemático:

1. Redes de computadores – Gerência – Windows 10 Pro

Copyright © 2018 Saraiva Educação
Todos os direitos reservados.

1ª edição

2018

Autores e Editora acreditam que todas as informações aqui apresentadas estão corretas e podem ser utilizadas
para qualquer fim legal. Entretanto, não existe qualquer garantia, explícita ou implícita, de que o uso de tais
informações conduzirá sempre ao resultado desejado. Os nomes de sites e empresas, porventura
mencionados, foram utilizados apenas para ilustrar os exemplos, não tendo vínculo nenhum com o livro, não
garantindo a sua existência nem divulgação. A Ilustração de capa e algumas imagens de miolo foram retiradas
de www.shutterstock.com, empresa com a qual se mantém contrato ativo na data de publicação do livro. Outras
foram obtidas da Coleção MasterClips/MasterPhotos© da IMSI, 100 Rowland Way, 3rd floor Novato, CA 94945,
USA, e do CorelDRAW X6 e X7, Corel Gallery e Corel Corporation Samples. Corel Corporation e seus
licenciadores. Todos os direitos reservados.

Todos os esforços foram feitos para creditar devidamente os detentores dos direitos das imagens utilizadas
neste livro. Eventuais omissões de crédito e copyright não são intencionais e serão devidamente solucionadas
nas próximas edições, bastando que seus proprietários contatem os editores.

Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem a prévia autorização
da Saraiva Educação. A violação dos direitos autorais é crime estabelecido na lei nº 9.610/98 e punido pelo
artigo 184 do Código Penal.
Dedicatória
A Andréa Guimarães Meira.
Carlos Vazquez
A Deus;
Aos meus pais Simões ( in memoriam ) e Lurdinha;
Aos meus irmãos Gustavo e Julia;
À minha filhota Clara.
Guilherme Simões
Aos meus pais pela solidez da educação e formação moral;
Ao meu irmão, causador da minha existência;
À minha esposa pela companhia salutar;
Aos meus amigos sócios, referências seguras;
Ao Pai, sempre iluminando meus caminhos.
Renato Albert
Agradecimentos
Agradecemos aos milhares de profissionais que já participaram de
nossos treinamentos, cuja troca de ideias e experiências favoreceu a
elaboração deste material, proporcionando um conteúdo objetivo, prático e
voltado à realidade da comunidade de software.
Agradecemos também:
• Aos mais de 3.000 membros do grupo
br.groups.yahoo.com/group/livro-apf (Grupo de Leitores
do Livro de APF) pela manutenção de discussões do
mais alto nível, que fazem com que esse fórum seja um
dos grupos de discussão mais ativos do mundo e nos
apoiam na evolução do conteúdo deste livro há cerca de
dez anos, e aos colegas dos fóruns do IFPUG e BFPUG.
• Ao Márcio Silveira e Mauricio Aguiar por manterem o
BFPUG e representarem a comunidade brasileira no
IFPUG.
• Ao IFPUG pela manutenção e evolução da técnica da
análise de pontos de função, e cujo manual foi a base da
elaboração deste livro.
• A Antonio Braga, um dos responsáveis pela difusão
inicial da técnica de pontos de função no Brasil, e
também autor do primeiro livro em português publicado
sobre o assunto.
• A todos os nossos clientes, sem os quais não teríamos a
oportunidade de praticar e aplicar a técnica de pontos de
função.
• Aos leitores das edições anteriores do livro que nos
forneceram sugestões e críticas para que pudéssemos
aperfeiçoar o material.
• Aos diversos estudantes, professores e pesquisadores que
usaram o livro como fonte de pesquisa nos seus
trabalhos acadêmicos (monografias, artigos, teses,
aulas). Para nós, autores, é muito gratificante saber que o
livro foi citado em mais de 100 trabalhos acadêmicos,
conforme nossa compilação, disponível em
http://www.fattocs.com.br/citacao-livro-apf.asp.
Sumário
Capítulo 1 - Por que Medir Software?
Motivação
Contexto
Dilema
Recursos
Gerência de Projetos
Visibilidade
Planejamento
Controle
A Curva do Pânico
O Adiamento do Projeto
Escolha de uma Abordagem Alternativa
O Problema não é só o Erro, é a Demora em Identificá-lo
Foco
Terceirização e Gestão de Contratos
Análise Make-Or-Buy
Seleção do Tipo de Contrato
Distribuição de Riscos
Algumas Medidas Preventivas
Iniciativas de Melhoria de Processo de Software (SPI)
O Que Medir?
Qual Medida Melhor Representa o Tamanho?
O que é a Análise de Pontos de Função? E o que é Ponto de Função?
Questões para Fixação
Bibliografia
Capítulo 2 - O Mundo das Métricas Funcionais
Objetivo
Breve Histórico
IFPUG
Pontos de Função no Brasil e BFPUG
NESMA
Mark II
 COSMIC
Padrão ISO de Medição Funcional
ISBSG
Pontos por Caso de Uso (Use Case Points)
Bibliografia
Capítulo 3 - O Processo de Medição Funcional
Introdução
Os Requisitos e a Contagem de Pontos de Função
A Visão do Usuário e a Dinâmica da Evolução dos Requisitos
Ciclo de Vida do Software e a Medição
Orientação Prática ao Segregar Requisitos Funcionais de não Funcionais
Distinção de Requisitos de Usabilidade
Distinção de Requisitos de Desempenho
Distinção de Requisitos de Confiabilidade
A Análise de Pontos de Função
Objetivos da APF
Objetivos do Processo de Medição
Conceito de Usuário
Benefícios
Propósito da Contagem de Pontos de Função
Reunir a Documentação Disponível
Determinação do Tipo de Contagem
Projeto de Desenvolvimento
Projeto de Melhoria
Aplicação
A Fronteira da Aplicação e o Escopo da Contagem
Fronteira da Aplicação
Escopo da Contagem
Funções do Tipo Dado
Funções do Tipo Transação
Cálculo do Tamanho Funcional
Fator de Ajuste
Documentar e Reportar
Estudo de Caso - Sistema de Controle de Ponto
Descrição do Sistema
Lista de Atores
Casos de Uso Identificados
 Especificação do Caso de Uso 1 - Registrar Presença
Especificação do Caso de Uso 2 - Registrar Justificativa
Especificação do Caso de Uso 3 - Acompanhar Presença
Especificação do Caso de Uso 4 - Emitir Relatório de Presença
Especificação do Caso de Uso 5 - Efetuar Login
Diagrama de Classes
Modelo de Entidades e Relacionamentos
Detalhamento dos Campos e Arquivos Referenciados
Identificação e Classificação das Funcionalidades
Questões para Fixação
Bibliografia
Capítulo 4 - Funções do Tipo Dado
Introdução
O que é um Arquivo de Interface Externa (AIE)?
Diferença entre ALI e AIE
Exemplos de Arquivos Lógicos
Não Exemplos de Arquivos Lógicos
Definição dos Termos Utilizados
Quantos PFs valem um ALI e um AIE?
Definição de Tipo de Dado (TD)
Definição de Tipo de Registro (TR)
Regras de Contagem de Tipos de Registro
Determinação da Contribuição
Dados de Código
Outras Entidades não Contadas como Arquivos Lógicos
O que Fazer com as Entidades que Sobraram?
Compartilhamento de Dados
Sistema de Controle de Ponto
Questões de Fixação
Bibliografia
Capítulo 5 - Funções do Tipo Transação
Introdução
Definição de Entrada Externa (EE)
Exemplos de EE
Não Exemplos de EE
Definição de Saída Externa (SE)
 Exemplos de SE
Não Exemplos de SE
Definição de Consulta Externa (CE)
Exemplos de CE
Não Exemplos de CE
Definição de Termos Utilizados
Processo Elementar
Para que Serve o Conceito de Processo Elementar?
Informações de Controle
Dado Derivado
Modificar o Comportamento do Sistema
Lógica de Processamento
Regras para Determinar se um Processo Elementar é Único
Variações do Mesmo Processo Elementar
Proposta de Diretrizes para Identificar Processos Elementares e Determinar
a Sua Unicidade
Requisito Funcional
“Completo”
Determinação da Complexidade
Definição de Arquivo Referenciado (AR)
Regras de Contagem para Arquivo Referenciado
Definição de Tipo de Dado (TD)
Regras de Contagem de Tipos de Dados
Determinação da Contribuição
Questões de Fixação
Bibliografia
Capítulo 6 - Fator de Ajuste
Considerações
Diretrizes para Determinação do Nível de Influência
1. Comunicação de Dados
2. Processamento Distribuído
3. Performance
4. Configuração Altamente Utilizada
5. Volume de Transações
6. Entrada de Dados On-Line
7. Eficiência do Usuário Final
8. Atualização On-Line
 9. Complexidade de Processamento
10. Reusabilidade
11. Facilidade de Instalação
12. Facilidade de Operação
13. Múltiplos Locais
14. Facilidade de Mudanças
Questões para Fixação
Bibliografia
Capítulo 7 - Cálculo do Tamanho Funcional e Documentar e Reportar
Projeto de Desenvolvimento
Fórmula do Projeto de Desenvolvimento
Exemplo 1
Projeto de Melhoria - IFPUG
Critérios para Avaliar Mudança em Arquivos Lógicos
Critérios para Avaliar Mudança em Transações
Fórmula do Projeto de Melhoria - IFPUG
Exemplo 2
Aplicação
Fórmula da Contagem Inicial da Aplicação
Fórmula da Aplicação após Projeto de Melhoria
Projeto de Melhoria - NESMA
Fórmula do Projeto de Melhoria - NESMA
Considerações sobre o Fator de Impacto
Manutenções “Cosméticas”
Custo x Benefício da Adoção do Método NESMA para Melhorias
Pontos de Função de Teste
Estimativa de Esforço da Melhoria
Documentar e Reportar a Medição
Organização das Funções
Nomenclatura das Funções
Questões para Fixação
Bibliografia
Capítulo 8 - Estudos de Caso
Introdução
Contagem de Aplicação
Características da Aplicação
 Diagrama Entidade-Relacionamento
Dicionário de Dados
Transações
Requisitos de Transição
Projeto de Melhoria
Capítulo 9 - Estimativa
Estimativa de Tamanho Funcional
Contagem Dedutiva
Complexidade Média
Backfiring
A Escolha do Tipo de Contagem
Fator de Crescimento
Estimativa de Esforço
Como Começar?
Produtividade e Taxa de Entrega
Cuidado com as Relações Lineares!
Estimativa de Duração
Curva de Rayleigh-Putnam
A Região Impossível
Cuidados com a Utilização de Indicadores de Mercado
Geração de Indicadores Internos
Conclusão
Questões de Fixação
Bibliografia
Capítulo 10 - Aplicações em Contratos de Desenvolvimento de Software
Introdução
Desafios na Contratação de Software
Modalidade de Contratação Homem-Hora
Modalidade de Contratação Preço Global Fixo
Modalidade de Contratação Preço Unitário
Pontos de Função como Unidade Padrão
Pontos de Função que Facilitam a Comunicação
O Cliente é o Dono do Escopo
Manutenção Corretiva
Itens não Mensuráveis
Uso de Deflatores na Manutenção
 Guia de Contagem (ou Guia de Métricas)
Decomposição do Custo (ou Esforço) por Atividade do Ciclo de Vida
Qual o Preço de um Ponto de Função?
Como Estimar o Preço de um Ponto de Função?
Dicas para Otimizar o Custo do Contrato
Contratação de Serviços de Medição
Seleção de Fornecedores de Serviços de Medição
Acompanhamento do Contrato de Serviços de Medição
Questões de Fixação
Bibliografia
Capítulo 11 - Certificação em Pontos de Função (CFPS)
Programa de Certificação
O Exame
Dicas e Comentários
Exame Simulado
Parte 1 - Definições
Parte 2 - Aplicação das Regras
Parte 3 - Estudos de Caso
Glossário
Prefácio
A análise de pontos de função é atualmente um instrumento utilizado
por profissionais da área de sistemas e em empresas de todos os portes e
segmentos da economia brasileira. Inicialmente o foco principal de sua
aplicação era em estimativas. Ainda continua sendo uma ferramenta
importante em estimativas, mas também tem sido aplicada cada vez com
mais sucesso como unidade de medição de contratos de desenvolvimento de
software e como ferramenta na gerência de projetos.
Este livro é o resultado de vinte anos de experiência prática dos autores
em projetos de desenvolvimento de sistema, manutenção de sistemas,
gerência de projetos, treinamento e consultoria em análise de pontos de
função. Seu objetivo é transmitir essa experiência aos profissionais que já
conhecem a técnica e permitir àqueles que ainda não a dominam iniciarem-
se no assunto. Ele aborda aspectos da aplicação de pontos de função em
estimativas e contratação de software, além do processo de certificação de
especialistas em pontos de função (CFPS); uma das certificações
profissionais de TI mais valorizadas atualmente no Brasil.
A seguir, veja uma breve descrição de cada capítulo.
O capítulo 1 - Por Que Medir Software? fornece a perspectiva do
contexto em que as métricas funcionais, em particular a análise de pontos
de função, podem ser aplicadas nas organizações que contratam e
desenvolvem softwares. Explora aplicações em gerência de projetos,
terceirização, gestão de contratos e em iniciativas de melhoria de processos
de software. Traz também os conceitos e fundamentos básicos para a
determinação dos aspectos do processo de desenvolvimento e manutenção
de sistemas que devem ser dimensionados.
O capítulo 2 - O Mundo das Métricas Funcionais apresenta um breve
histórico da análise de pontos de função no mundo e no Brasil, comenta o
papel de importantes organizações de métricas no mundo, entre elas o
International Function Point Users Group (IFPUG), e mostra outros
métodos de medição funcional existentes.
 O capítulo 3 - O Processo de Medição Funcional apresenta uma visão
geral do processo de medição e a estreita relação existente entre esse
processo de medição e a devida identificação dos requisitos funcionais de
um software. Os termos básicos para a aplicação da técnica são definidos e
a medição de um caso de uso é feita para ilustrar os aspectos teóricos de
forma prática e objetiva.
Os capítulos 4 e 5, respectivamente, Funções do Tipo Dado e Funções
do Tipo Transação ensinam a identificar os elementos-chave definidos pela
técnica. Todos os conceitos apresentados são seguidos de exemplos e casos
práticos que permitem uma melhor assimilação do conteúdo.
O capítulo 6 - Fator de Ajuste aborda os cálculos envolvidos e as
descrições das 14 características gerais de sistema que influenciam a
medição dos pontos de função ajustados.
O capítulo 7 - Cálculo do Tamanho Funcional e Documentar e Reportar
mostra as fórmulas utilizadas para cálculo dos pontos de função dos três
tipos de contagem, sendo projetos de desenvolvimento, de melhoria e de
aplicação. Traz também a abordagem de medição do projeto de melhoria de
acordo com o IFPUG e com a NESMA. Na seção Documentar e Reportar
são discutidos aspectos relevantes para a documentação da contagem para
que esta tenha valor. O interesse da contagem nem sempre está restrito ao
número final calculado.
O capítulo 8 - Estudos de Caso contém exercícios de medição funcional
para os três tipos de contagem de pontos de função: aplicação, projeto de
desenvolvimento e projeto de melhoria.
O capítulo 9 - Estimativa apresenta um modelo geral para o processo de
estimativas de projetos e ensina como utilizar pontos de função para
produzir estimativas com razoável confiabilidade em fases iniciais do
projeto. São feitas diversas considerações para o uso correto dessa
importante ferramenta.
O capítulo 10 - Aplicações em Contratos de Desenvolvimento de
Software estuda as três principais modalidades de medição adotadas em
contratos de software e ilustra as aplicações da análise de pontos de função
em cada uma dessas modalidades. Apresenta um roteiro para que tanto
empresas que contratam quanto aquelas que são contratadas possam
estabelecer políticas que permitam um relacionamento positivo entre as
partes.
O capítulo 11 - Certificação em Pontos de Função (CFPS) comenta o
processo de certificação de especialistas em pontos de função promovido
pelo IFPUG e apresenta uma série de dicas úteis ao candidato à certificação,
inclusive com um exame simulado da prova.
Finaliza com um glossário dos termos mais utilizados pela técnica de
pontos de função com o significado das siglas comumente utilizadas.
Os autores
Sobre os Autores
Os dois primeiros autores são sócios-diretores da empresa FATTO
Consultoria e Sistemas (www.fattoCS.com.br), na qual atuam como
consultores em métricas de software, estimativas de projetos e instrutores
dos cursos oferecidos pela empresa.
Carlos Eduardo Vazquez é um profissional de TI com mais de 20 anos
de experiência no desenvolvimento, manutenção e gestão em software de
aplicação e de sistemas, direcionando a tecnologia às necessidades das
pessoas. Ele tem a visão de que tecnologias de medição de software e a
medição do tamanho funcional em particular, tais quais os pontos de função
como definidos pelo IFPUG, NESMA ou COSMIC, sejam ferramentas
fundamentais para alcançar esse objetivo. Desde 1991, é um usuário da
análise de pontos de função do IFPUG; treina turmas no assunto desde
1993. Em 1996, foi um dos primeiros brasileiros a ser certificado
especialista em pontos de função (CFPS) pelo IFPUG, organização da qual
é membro com direito a voto. Repete o feito em 2012, sendo um pioneiro
como detentor da certificação COSMIC. Em 1998, lecionou como professor
substituto na Universidade Federal do Espírito Santo (UFES); fundou a
FATTO neste mesmo ano. Em 2001, escreveu o livro “Análise de Pontos de
Função: Medição, Estimativas e Gerenciamento de Projetos de Software”,
hoje em sua 13 ª edição, com mais de 12.000 exemplares vendidos e uma
das principais referências no assunto no Brasil. Coordena a pesquisa e
desenvolvimento do conteúdo para os serviços educacionais na FATTO;
atua como um instrutor e facilitador em turmas abertas ao público e in-
company. Atua também como responsável pela consultoria gerencial em TI,
liderando um time de especialistas em métricas de software. Perfil no
linkedin disponível em br.linkedin.com/in/cvazquezbr.
Guilherme Siqueira Simões é sócio da FATTO Consultoria e Sistemas,
onde atua como consultor e instrutor em serviços de medição, estimativas e
requisitos de software. Atuou no desenvolvimento de toda a linha de
serviços da FATTO e treinou centenas de profissionais do Brasil em APF.
Participou da equipe de tradução para o português das versões 4.2.1 e 4.3 do
Manual de Práticas de Contagem do IFPUG. Tem mais de 20 anos de
experiên- cia em desenvolvimento de sistemas (oito deles em projetos de
software para automação bancária). Graduado em Ciência da Computação
pela UFES, pós-graduado em gestão empresarial pelo IEL/UFES e
certificado como especialista em pontos de função pelo IFPUG desde 2002.
Veja currículo completo em http://br.linkedin.com/in/guilhermesimoes.
Renato Machado Albert é gestor público e atua na formulação e
execução de políticas públicas na área de TI no estado do ES. Possui MBA
em Gerenciamento de Projetos pela FGV, com experiência no assunto em
empreendimentos da área de software e de produção de petróleo e gás. É
graduado em Ciência da Computação e pós-graduado em Marketing e TI
pela UFES. Éspecialista em análise de pontos de função, atuou por mais de
dez anos como desenvolvedor, analista e coordenador de equipe em projetos
de sistemas nas áreas industrial, de serviços e bancária.
Sobre o Material Disponível na Internet
O material disponível no site da Editora Érica contém as respostas dos
exercícios do livro, do simulado do capítulo 11 e a planilha eletrônica dos
estudos de casos do capítulo 8.
Para utilizar os arquivos, você precisa ter instalados em sua máquina o
Acrobat 8, Word 2003 e o Excel 2003, ou versões mais recentes.
Exercícios_13ED.EXE - 499KB
Procedimentos para Download
Acesse o site da Editora Érica Ltda. (www.editoraerica.com.br). A
transferência do arquivo disponível pode ser feita de duas formas:

• Por meio do módulo de pesquisa: localize o livro

desejado, digitando palavras-chave (nome do livro ou do
autor). Aparecem os dados do livro e o arquivo para
download . Com um clique o arquivo executável é
transferido.
• Por meio do botão “Download ”: na página principal do
site, clique no item “Download ”. É exibido um campo
no qual devem ser digitadas palavras-chave (nome do
livro ou do autor). Aparecem o nome do livro e o
arquivo para download . Com um clique o arquivo
executável é transferido.
Procedimentos para Descompactação
Primeiro passo: após ter transferido o arquivo, verifique o diretório em
que se encontra e dê um duplo clique nele. Aparece uma tela do programa
WINZIP SELF- EXTRACTOR que conduz ao processo de
descompactação. Abaixo do Unzip To Folder há um campo que indica o
destino do arquivo que será copiado para o disco rígido do seu computador:
 C:\Análise de Pontos de Função - 13 a
Segundo passo: prossiga a instalação, clicando no botão Unzip , o qual
se encarrega de descompactar o arquivo. Logo abaixo dessa tela aparece a
barra de status que monitora o processo para que você acompanhe. Após o
término, outra tela de informação surge, indicando que o arquivo foi
descompactado com sucesso e está no diretório criado. Para sair dessa tela,
clique no botão OK. Para finalizar o programa WINZIP SELF
EXTRACTOR, clique no botão Close .
 1

Por que Medir Software?

Motivação
A primeira pergunta que deve ser respondida ao apresentar a técnica da
análise de pontos de função é: qual a motivação para sua utilização? É
fundamental levar em consideração três principais aspectos que devem ser
avaliados para respondê-la:

• O contexto de sua aplicação nas organizações que

mantêm projetos e operações voltados à contratação,
desenvolvimento e manutenção de sistemas.
• A análise do dilema presente nesse contexto.
• O entendimento de como a técnica pode ajudar essas
organizações a identificar e equacionar o conjunto de
questões envolvidas na solução das dificuldades
inerentes a esses empreendimentos.

Contexto
 O contexto citado anteriormente é influenciado por duas forças que,
apesar de antagônicas, são mutuamente complementares. Por um lado
existem os requisitos do sistema que tendem a aumentar com o tempo,
como qualidade, funcionalidade e performance. Todos aqueles que
vivenciaram essa situação sabem que mesmo após o fechamento da fase de
levantamento de requisitos, quando todas as especificações funcionais e não
funcionais foram concluídas, à medida que o produto vai tomando forma,
seus futuros usuários já idealizam novas características inicialmente não
percebidas. Independentemente do projeto atender a essas necessidades
nessa versão ou em alguma próxima, tal fato só vem por ratificar a natureza
expansiva dos requisitos. Muitas vezes, com a utilização do produto,
aqueles requisitos que eram desejáveis passam a ser necessários, e muitos
outros, até então inexistentes, são percebidos.

Dilema
Por outro lado, atender a esses requisitos implica em trabalho. Para
realizá-lo, é necessário mobilizar o esforço tanto de profissionais
qualificados no projeto e construção dos produtos do sistema quanto de seus
futuros clientes, disponibilizar ferramentas de hardware e software e
providenciar a infraestrutura logística, compreendendo instalações físicas,
hospedagem, passagens, secretariado, entre outros recursos, para acomodar
e fornecer as condições apropriadas ao trabalho. Todos esses recursos:
humanos, materiais e financeiros são limitados, inclusive o próprio tempo.
Desta forma, satisfazer os requisitos que tendem à expansão envolve a
disputa pelos recursos que tendem à escassez. Então, para responder por
que medir, deve-se antes avaliar os mecanismos para manter essa situação
sob controle, a fim de obter o melhor resultado - atender ao máximo às
expectativas dos clientes com a utilização do mínimo de recursos.

Recursos
Os primeiros recursos utilizados na solução dessa equação foram os de
natureza tecnológica: ferramentas CASE, linguagens de quarta geração,
tecnologias orientadas a objetos, ambientes integrados de desenvolvimento,
arquitetura cliente-servidor, entre outros. Em seguida, como consequência
da manutenção do cenário apresentado, o foco passou a ser direcionado ao
estudo de métodos que permitissem uma maior organização, disposição e
ordem dos elementos que compõem os sistemas. Isoladamente ou em
conjunto com as novas tecnologias, a aplicação desses métodos não foi
capaz de fornecer as respostas desejadas.
Recentemente, em maior ou menor escala, quatro são as principais
alternativas utilizadas para tentar equilibrar a balança que mede as
demandas por sistemas e os recursos disponíveis: enfoque de gerência de
projetos, a terceirização e gestão de contratos, iniciativas de melhoria de
processos e o uso intensivo de pacotes de software, em especial, os ERPs.

Gerência de Projetos
Gerência é uma palavra que deriva de gerir, originária do latim, gerere
que significa trazer, produzir, criar, executar e administrar. Em resumo,
gerir é planejar, executar e controlar. De acordo com o Project Management
Institute 1 (PMI) um projeto é um empreendimento temporário posto em
execução para criar um único produto ou serviço. Na condução desse
empreendimento, existem vários processos que visam permitir sua gerência.
Esses processos são agrupados em alguns passos básicos, dos quais
destacam-se três:

• Planejamento: os objetivos são definidos e refinados e o

melhor curso de ação é selecionado;
• Execução: coordenação de pessoas e outros recursos
para executar o plano;
• Controle: garantia de que os objetivos são alcançados,
por meio do monitoramento e medição regular do
progresso, identificando as variações no plano e tomando
as ações corretivas conforme a necessidade.
A utilização desse enfoque no desenvolvimento e manutenção de
sistemas busca a definição e a implementação de processos, por intermédio
dos quais seja possível controlar sua execução pelo conhecimento prévio do
efeito das suas respostas. Aliado ao uso de tecnologias e metodologias mais
produtivas, é um dos melhores instrumentos para alcançar uma melhor
relação entre custo e benefício no desenvolvimento de sistemas.

Visibilidade
O mecanismo descrito anteriormente é chamado retroalimentação e a
palavra-chave que define seu principal benefício é visibilidade. Com ela
tanto é possível saber para onde ir antes de iniciar a caminhada quanto saber
se o caminho em curso é o correto. Ou seja, permite definir objetivos
realistas e a adoção de medidas necessárias à prevenção e correção dos
desvios que causam impacto negativo no cumprimento desses objetivos.
Essas medidas são um dos objetos dos processos de planejamento e controle
do projeto.

Planejamento
Nas fases iniciais do projeto, como por exemplo, durante o
levantamento de requisitos, ainda não há o conhecimento completo das
características do produto que permita a apuração de sua futura dimensão.
Nesse caso é necessário estimar. Vários modelos de estimativa foram
criados para fornecer métricas que permitam atender com menor margem de
erro às necessidades de comunicação e informação do projeto.
A análise de pontos de função permite não só medir o tamanho do
sistema em termos da funcionalidade fornecida ao usuário, mas também
estimar seu tamanho em qualquer fase do seu ciclo de vida (mesmo que os
requisitos ainda não tenham sido detalhados). A manutenção de registros de
outros projetos semelhantes, com a evolução das estimativas iniciais até a
medição final, permite um acompanhamento da relação entre a quantidade
de pontos de função estimados ou calculados nos vários estágios de
conhecimento do produto.
Na Figura 1.1, a área em destaque indica que, durante a especificação de
requisitos, projeto de alto nível, projeto detalhado e implementação, toda
medição funcional realizada ainda é uma projeção do que de fato será
entregue. Ao final do projeto detalhado já é possível realizar uma medição
dos pontos de função do projeto, não do produto final. O resultado dessa
medição em termos práticos ainda será uma estimativa do que realmente
será entregue, pois normalmente entre o final do projeto detalhado e a
conclusão do projeto ainda pode haver mudanças no escopo por mudanças
nos requisitos e necessidades que originaram o projeto.

Figura 1.1: Pontos de medição e estimativa ao longo do ciclo de

vida do projeto.

As métricas obtidas nos diversos momentos do projeto não só têm valor

quando avaliadas isoladamente, mas também quando relacionadas entre si.
Ao comparar a evolução do tamanho funcional durante a evolução de
projetos passados, pode ser obtido um fator que indique o percentual de
crescimento funcional entre essas diversas etapas. Ao identificar projetos
passados com características semelhantes ao que se está planejando, é
possível ajustar as estimativas realizadas em fases iniciais, como descrito na
Figura 1.2.

Figura 1.2: Variação de tamanho do projeto ao longo do seu ciclo

de vida.
 Contudo, o tamanho em si tem pouco valor analisado de forma isolada.
Ele passa a ser relevante quando serve de base para responder às perguntas
referentes a outros aspectos. O planejamento de projetos de sistemas
envolve equacionar um conjunto complexo de elementos, entre eles:
• Quais produtos devem ser desenvolvidos
(especificações, manuais, programas, módulos, base de
dados, planos de implantação e conversão etc.);
• Por meio de que atividades (identificação de classes de
objetos, preparação de cenários de interações típicas,
construção de modelo funcional, validação de
documentação técnica etc.);
• Envolvendo quanto esforço (horas/homem, homem/mês
etc.);
• De que profissionais (analistas, implementadores,
documentadores, usuários etc.);
• Durante quanto tempo (semanas, meses, anos etc.);
• Quais os riscos devem ser identificados e
contingenciados.
Neste aspecto a experiência do profissional contribui em muito para a
elaboração de planos realistas. Na área de Tecnologia da Informação,
contudo, parte dessa experiência é perdida com a velocidade do avanço
tecnológico e da rotatividade de pessoal. A falta de unidades de medição
desses processos dificulta a transformação da experiência dos indivíduos
em experiência coletiva.
Esforço, prazo e custo são algumas das informações normalmente
selecionadas como objeto de medição e estimativa. Essas métricas, ou
outras métricas secundárias que as originaram enquanto estimativa durante
a condução do projeto, são coletadas e distribuídas na forma de relatórios
com a situação do projeto, seu progresso atual e as expectativas quanto à
sua situação futura.
 Contudo, a equipe envolvida no planejamento do projeto, antes de seu
início, normalmente possui apenas duas principais fontes de informação
para ponderar essas variáveis:
• A data limite, estabelecida por fatores e pressões
externas, o orçamento e o tempo disponível dos
profissionais da empresa.
• A experiência adquirida individualmente pelos analistas
e gerentes responsáveis pelo planejamento do projeto.

Controle
Nesse cenário, é de suma importância que a definição de meios para a
comparação do progresso real com o planejado seja parte do planejamento
do projeto. O controle é uma das principais atividades envolvidas na
gerência de projetos. Trazendo estes conceitos para o contexto de um
projeto de desenvolvimento de sistemas, é possível ter algumas ideias
interessantes na busca da resposta de por que medir. Afinal, não se
consegue controlar o que não se consegue medir.

A Curva do Pânico
O resultado da medição tem o papel de permitir a comunicação efetiva
não só entre os vários indivíduos e organizações envolvidos no projeto, mas
também com os que possam ser afetados por ele. A penalidade pela falta
desses mecanismos de apuração ou pela sua não utilização frequente é
enfrentar a dinâmica representada na Figura 1.3, dinâmica dos 99%
concluídos.
 Figura 1.3: A dinâmica do pânico.

O Adiamento do Projeto
Entre os resultados dessa dinâmica está o adiamento da conclusão do
projeto, e até chegar a essa decisão, a equipe do projeto teve seu ânimo
abatido, suas expectativas frustadas e passa a se sentir impotente diante do
inevitável. A qualidade interna do produto é prejudicada e como
consequência quase certa, sua qualidade externa também será afetada,
mesmo após o adiamento. E a pergunta que se deve fazer é se será o último
adiamento, visto que, se as mesmas premissas forem adotadas com o novo
prazo, não existirão garantias da visibilidade do problema, a não ser quando
já for tarde demais para adotar alguma ação.
 Figura 1.4: Adiamento. Será o último?

A falta de métricas de projeto prejudica de forma geral seu

acompanhamento, uma vez que, apesar de o problema estar lá, ele não é
percebido por aqueles que podem direcionar esforços na sua solução. O
papel das métricas é permitir uma rápida identificação e correção de pro‐
blemas.

Escolha de uma Abordagem Alternativa

Um dos problemas no gerenciamento de projetos é o desvio da situação
atual em relação ao caminho projetado. Para que esse desvio seja percebido,
é necessário analisar as métricas definidas e coletadas, assim como os
indicadores gerados pelo inter-relacionamento delas. Essa análise permite
que as várias dimensões de aspectos, como cronograma, custos, qualidade,
riscos ou escopo, sejam monitoradas.
Identificado o desvio, itens de ação podem ser analisados, selecionados
e postos em execução. Essas escolhas são fundamentadas em informações
objetivas coletadas durante o processo. Por exemplo, até determinado
momento foi apurada uma produtividade de 20 PF/HM (em 160 horas são
produzidos 20 pontos de função, ou seja, em 8 horas um técnico produz 1
ponto de função). Não é razoável supor que, em se mantendo as mesmas
condições, sua produção dobrará apenas pela percepção de um atraso do
cronograma. Dessa forma, têm-se algumas escolhas não necessariamente
exclusivas entre si: atualizar o plano em função da constatação de um
otimismo exagerado nas estimativas, aumentar a motivação da equipe,
procurar eliminar fatores que afetam negativamente a produtividade ou
negociar por mais recursos e um escopo menor.

Figura 1.5: Uma abordagem alternativa.

O Problema não é só o Erro, é a Demora

em Identificá-lo
É importante lembrar que o problema não é só o erro, mas a dificuldade
em prevenir, identificar ou corrigir seus efeitos. Quanto à opção de
aumentar os recursos, nem sempre é a solução; principalmente por não
haver uma relação linear entre o prazo, o esforço e a quantidade de recursos
disponíveis. Ou seja, deve-se evitar a simplificação de chegar à conclusão
que nove mulheres geram um filho em um mês.
 Com a utilização de métricas, justificar e defender as decisões tomadas
fica mais fácil. Primeiramente em função do menor impacto desses desvios.
Eles foram identificados e gerenciados com antecedência, suas
consequências tendem a ser menos graves. O gestor se decidiu não apenas
com base na sua experiência individual, mas também com a avaliação de
indicadores que refletem uma tendência do comportamento futuro. Esta
tendência deve ser derivada não só das experiências passadas no projeto,
mas também de experiências semelhantes de outros projetos de dentro e
fora da organização.
Com a aplicação sistemática desta abordagem, é possível acompanhar
objetivos específicos. Para cada um dos objetivos que se deseja acompanhar
é possível estabelecer um conjunto de perguntas que verifique o seu
cumprimento. Para muitas dessas perguntas é possível identificar uma
métrica que possa quantificar a resposta.
Também é importante destacar que quando se fala em métricas de
projeto não está se referindo exclusivamente à utilização de técnicas de
medição de sistemas, mas também a uma série de técnicas para ponderar o
efeito de outros fatores como a análise de riscos e a determinação de marcos
do projeto (milestones).
 Figura 1.6: Fundamentos para melhoria contínua.

Foco
Com o exposto procurou-se sensibilizar o leitor para o papel que a
utilização de métricas exerce no suporte ao empreendimento de atividades
de desenvolvimento ou manutenção de sistemas com um enfoque de
projeto.
É cada vez mais frequente a concentração do foco das organizações nas
suas atividades principais. Como consequência, é crescente a quantidade de
projetos de sistemas que deixa de ser empreendida internamente para ter sua
execução contratada. Tal fato não invalida os pontos já destacados, visto
que em algum momento alguém deverá se preocupar com os assuntos
tratados.
Terceirização e Gestão de Contratos
O fato de parte ou todo trabalho envolvido no desenvolvimento e
manutenção de sistemas estar terceirizado não elimina a necessidade de
medição, muito pelo contrário. Tanto no corpo de conhecimento em
gerência de projetos (PMBOK) do Project Management Institute (PMI)
quanto no Capability Maturity Model (CMM) do Software Engineering
Institute 2 (SEI) a aplicação de métricas é um aspecto determinante no
relacionamento entre a empresa que contrata e a empresa contratada.
O PMI dedica toda uma área de conhecimento, denominada gerência
das aquisições do projeto, aos processos envolvidos na obtenção de bens e
serviços externos à organização. O planejamento das contratações é o
primeiro dos processos compreendido por essa área de conhecimento. Ele
objetiva identificar as necessidades do projeto que podem ser melhor
atendidas através da contratação de produtos ou serviços no mercado.

Análise Make-Or-Buy
Assim como todos os processos componentes das diversas áreas do
corpo de conhecimento organizado pelo PMI, o planejamento das
contratações é descrito em termos de suas entradas, das ferramentas e
técnicas utilizadas e de suas saídas. A análise de make-or-buy é uma das
técnicas introduzidas nesse processo. Ela visa determinar se é mais
vantajosa a contratação de um produto específico no mercado ou o seu
desenvolvimento interno.
Este tipo de avaliação está baseado na comparação dos níveis de
performance da organização contra os níveis oferecidos pelo mercado.
Alguns componentes representativos desses níveis de performance são
quantificáveis e podem ser objeto de uma análise objetiva. A utilização de
indicadores é o principal insumo para essa comparação de alternativas
disponíveis. Os indicadores, considerados métricas secundárias, são
derivados do inter-relacionamento de outras métricas. Agem como a “cola”
que relaciona custo, prazo, esforço e dimensão, métricas primárias
envolvidas na análise.
 Quando uma série de valores históricos é utilizada na determinação da
evolução desses indicadores, seu conjunto passa a representar uma
tendência de comportamento que permite estabelecer premissas de
produtividade e qualidade. Se a organização possui esses indicadores
internos segmentados de forma que o objeto da análise possa ser
enquadrado em função dos fatores básicos que afetam essas variáveis, como
o ambiente tecnológico, a quantidade de usuários, a experiência da equipe
com o domínio do problema, um dos lados da equação já está bem
encaminhado - quanto custa, em quanto tempo, com que qualidade o
trabalho é realizado internamente.
Por exemplo, é realizada uma análise cujo objetivo é determinar se:
a) A organização deve empreender internamente o
desenvolvimento de um novo sistema.
b) Deve ser contratada uma empresa externa para o
desenvolvimento completo do novo sistema.
c) Deve ser realizado internamente o trabalho de
especificação de requisitos e implantação, enquanto a
codificação e os testes serão contratados no mercado.
d) É conveniente a aquisição de um pacote (COTS -
Commercial Off-The-Shelf ) com sua parametrização e
adequações tanto no parque de sistemas quanto na
organização.
O conhecimento dos aspectos que influenciam a decisão sobre qual
dessas opções é a mais vantajosa permite estruturar a metodologia para
seleção. Nem todas as respostas necessárias ao processo têm o mesmo nível
de dificuldade ou mesmo a viabilidade de obtenção. Com a análise de
pontos de função é possível medir a funcionalidade solicitada pela
organização. Com base na quantidade de pontos de função e em indicadores
como a produtividade (PF/HM), o custo ($/PF) e indicadores de qualidade
(Defeitos/PF), é possível extrapolar essas informações de outra forma
inacessíveis ou de difícil apuração ou justificativa.
 Com base nesses indicadores, é possível avaliar a performance interna
em termos de quanto se pode produzir por unidade de tempo ou custo.
Simplificando, se é sabido o QUANTO deve ser produzido, pode-se
extrapolar quais serão o custo, prazo e esforço envolvidos nesse trabalho.
Como já foi discutido, o ponto de função objetiva medir esse QUANTO
em termos da funcionalidade solicitada e fornecida ao usuário do sistema.
Com base na aplicação da análise de pontos de função pode-se responder a
essa outra parte da equação. Agora, com o QUANTO se deve produzir
pode-se chegar à quantidade de unidades de tempo e custo necessárias à
comparação com o mercado.

Seleção do Tipo de Contrato

A terceirização e a gestão de contratos podem ficar mais simples,
dependendo do resultado da Seleção do Tipo de Contrato, outra técnica
utilizada durante o planejamento de aquisição. Apesar do crescimento da
abordagem de fábrica de software, no ramo de desenvolvimento e
manutenção de sistemas atualmente ainda são bastante difundidos dois
modelos de contratação: Preço Global Fixo e Homem-Hora.
O primeiro modelo consiste em um preço total fixo por um produto bem
definido. Nas fases iniciais da concepção ou mesmo após a conclusão da
especificação de requisitos, ainda existem características ocultas somente
percebidas posteriormente. Dessa forma, a probabilidade de haver um
aumento no escopo originalmente previsto é alta. Como consequência, o
contratante pode não receber o produto desejado ou o contratado. Por ter
que arcar com custos adicionais que não são de sua direta responsabilidade,
muitas vezes sacrifica outros aspectos de maior dificuldade de medição.
Já no segundo modelo, baseado em homem-hora, o risco é outro. Hora
não é um bem ou serviço prestado, é uma unidade de tempo ou mesmo de
custo. Ela não mede o QUANTO está sendo produzido. Daí a grande
distorção evidenciada em projetos de desenvolvimento ou melhoria de
sistemas. Quanto menos a empresa contratada produz em uma hora, mais
ela será remunerada. Ou seja, é a antítese do culto à produtividade. A
administração da produtividade do contratado fica por conta de quem
contrata, incorrendo em custos adicionais de controle. A materialização de
um risco, a perda de produtividade, afeta o contratante, e não o contratado,
que em última instância é aquele que deveria ser o responsável pela sua
manutenção.
Nessa modalidade de contratação baseada em homem-hora não é
incomum ouvir comentários como: “... hoje eu vou ficar aqui até as 21
horas. Você sabe, estou precisando trocar de carro...”. O mecanismo
gerencial para a solução deste tipo de problema envolve inicialmente a
criação de controles que tornem as consequências deste tipo de atitude
visíveis para a administração. O acompanhamento da produtividade da
equipe permite a criação de um sistema que forneça indicadores
representativos de situações que necessitam de ação gerencial. Para
acompanhar a produtividade da equipe, no mínimo, duas medidas são
necessárias: o esforço utilizado (horas) e o resultado obtido. A obtenção
deste último é o objetivo deste livro.
Outra situação, também nada incomum, é quando o principal prestador
de serviços de sistemas, no início do contrato, coloca à disposição da
organização contratante profissionais altamente qualificados. Com o passar
do tempo ele vai gradualmente substituindo esses profissionais, mais caros
para a empresa, por profissionais menos experientes e com menor custo.
De forma análoga ao caso anterior, é necessária a criação de
mecanismos gerenciais que permitam à administração quantificar o
problema. Uma análise progressiva de indicadores de produtividade e
qualidade fornece números que facilitam a solução do problema. Por
exemplo, no primeiro trimestre do contrato foram realizadas 30 ordens de
serviço de manutenção, utilizando 1.600 horas, totalizando 1.200 pontos de
função. Nesse período a produtividade média alcançada foi de 40 pontos de
função por homem/mês, Figura 1.7.
Uma análise exclusiva do número de horas não é conclusiva quanto à
produtividade da equipe, porém, quando se analisam os dois fatores em
conjunto, pode-se derivar o seguinte gráfico, Figura 1.8:
 Figura 1.7: Evolução da relação esforço x produção.

Figura 1.8: Evolução da produtividade.

Neste gráfico pode-se claramente avaliar o período de acomodação da

equipe ao novo ambiente durante os três primeiros meses. A partir do
quarto mês a produtividade foi diminuindo até se estabilizar em um novo
patamar. É evidente que alguma coisa está errada!
Além dos indicadores de produtividade, vários outros podem ser
definidos para o acompanhamento dos mais diversos fatores que afetam os
serviços do departamento de tecnologia da informação.

Distribuição de Riscos
Com a análise de pontos de função é possível melhorar o modelo
homem-hora, só que utilizando uma unidade que quantifique um produto, e
não a passagem do tempo. O próprio Sistema de Pagamentos utilizado na
administração dos contratos pode realizar o faturamento dos serviços não
com base em horas, mas com base na funcionalidade solicitada e recebida -
o ponto de função.
O IFPUG 3 , International Function Point Users Group , organismo
internacional responsável pela manutenção e evolução do padrão de
medição de pontos de função, empreende através de comitês específicos
ações no sentido de garantir a consistência da técnica, requisito básico para
utilização do ponto de função como unidade de medição contratual. As duas
principais ações neste sentido são o Manual de Práticas de Contagem e os
programas de certificação de cursos e de profissionais. O capítulo 2 discute
um pouco mais o IFPUG.

Algumas Medidas Preventivas

A organização deve tomar uma série de medidas antes de iniciar este
tipo de relacionamento baseado em pontos de função. A principal delas é o
estabelecimento de um adendo ao contrato, esclarecendo sua perspectiva
quanto a alguns aspectos da técnica que podem causar diferenças nas
interpretações do contratado e do contratante.
Outro aspecto que deve ser definido pela organização ao contratar
pontos de função é a forma de remuneração. O processo de medição possui
uma variação sistêmica entre a produtividade apurada no desenvolvimento e
na manutenção. Daí haver alguns modelos de contratação em que é
praticado um valor para pontos de função para o acréscimo de
funcionalidades e outro valor, normalmente mais baixo, praticado para a
modificação ou exclusão de funcionalidades já existentes.
As variáveis não relacionadas à funcionalidade, mas que afetam o
esforço do desenvolvimento e manutenção de sistemas, também devem ser
consideradas na avaliação do valor do ponto de função. O preço de um
ponto de função utilizando determinada tecnologia pode, e normalmente
será diferente, quando outra tecnologia é utilizada, por exemplo.
Como foi exposto, a análise de pontos de função pode ser utilizada tanto
como base para comparação de alternativas em situações que envolvem
decisão de compra, contratação ou desenvolvimento interno, quanto como
uma opção de unidade de contratação com foco na funcionalidade entregue.
Uma consequência da intensificação do processo de especialização das
organizações é a busca incessante por mecanismos que permitam o aumento
dos níveis de qualidade de seus processos e produtos. No ramo de
desenvolvimento e manutenção de sistemas, essa urgência se materializa no
crescente número de empresas interessadas na obtenção de certificados de
qualidade ISO/CMM ou melhorar seus processos pelo empreendimento de
iniciativas de SPI ( Software Process Improvement ).

Iniciativas de Melhoria de Processo de

Software (SPI)
Pode-se definir SPI como o procedimento sistemático para melhorar a
performance de um sistema composto por um conjunto de processos
existentes, pela modificação desses processos existentes ou a atualização
com novos processos, objetivando corrigir ou evitar problemas
identificados no sistema anterior através de um assessment . Assessment é
definido como o procedimento sistemático de investigar a existência,
adequação e performance de um modelo real contra um modelo, padrão ou
benchmark .
Existem vários modelos que visam orientar a condução dessas ações,
como por exemplo:
• SEI CMMI - Capability Maturity Model Integration
• SPICE - Software Process Improvement and Capability
Determination (ISO 15504) 4
• TickIT 5
Independentemente do modelo, todos procuram tornar a atividade de
desenvolvimento e manutenção de sistemas mais previsíveis, ou seja, que as
estimativas sobre o comportamento das principais variáveis envolvidas,
custo, tempo e qualidade, tenham maior probabilidade de se confirmar nas
suas respectivas medições. Além disso, eles também buscam fornecer um
ambiente mais propício a uma ação gerencial efetiva que torne menos
prováveis desvios do plano. E ainda, através da sistemática melhoria nos
processos, permita que se alcancem melhores resultados com a utilização de
menos recursos.
O modelo da SEI é um dos mais difundidos no mundo, sendo
atualmente o que representa a maior tendência em termos de iniciativas de
SPI. Ele é estruturado em cinco níveis de maturidade. Cada um desses
níveis indica:
• A capacidade dos processos em materializar as
expectativas da organização através de sua utilização.
Processos estes que servem de base para o
estabelecimento de premissas para a obtenção de novos
resultados no futuro.
• A performance dos processos em medir os resultados
obtidos pela sua execução.
• O grau em que determinado processo está explicitamente
definido, gerenciado, medido, controlado e atinge seus
objetivos, ou seja, sua maturidade.
Esses níveis são estruturados em termos de um conjunto de atividades
relacionadas, que quando executadas atingem objetivos considerados
relevantes para a melhoria da capacidade dos processos. Esse conjunto de
atividades é chamado Process Area (anteriormente era conhecido como Key
Process Area - KPA ). Para fins de ilustração são apresentadas em seguida
as PA do segundo nível de maturidade - Managed (chamado Repeatable na
versão 1.1 do CMM de 1993). Seu foco está nos processos de gerência de
projetos:
• Gerência de requisitos;
• Planejamento de projeto;
• Monitoramento e controle de projeto;
• Gerenciamento de acordos com fornecedor;
• Medição e análise;
• Garantia de qualidade de produto e processo;
• Gerência de configuração.
O propósito da PA Medição e Análise é desenvolver e manter a
capacidade de medição que suporta as necessidades de informação
gerencial. O conjunto de objetivos específicos e gerais dessa PA é o
seguinte:

• Nivelar a atividade de medição e análise (específico);

• Fornecer resultados de medição (específico);
• Institucionalizar um processo gerenciado (geral);
• Institucionalizar um processo definido (geral).
Cada um destes objetivos específicos e gerais está relacionado pelo
modelo às práticas específicas e gerais. Os últimos são organizados com
base em quatro características comuns:
• Compromisso em executar;
• Capacidade de executar;
• Direcionando a implementação;
• Verificando a implementação.
As práticas específicas relacionadas aos objetivos específicos dessa PA
são: estabelecer objetivos da medição, especificar medidas, especificar
procedimentos de coleta de dados e armazenamento, especificar
procedimentos de análise, coletar dados de medição, analisar dados de
medição, armazenar dados e resultados e comunicar resultados.
Em termos práticos, a aplicação da análise de pontos de função pode
integrar-se de forma bastante útil às atividades compreendidas em várias
Process Areas do CMMI. A técnica de pontos de função é baseada nos
requisitos funcionais do sistema. O processo de medição pode trazer
benefícios similares a uma revisão em pares da especificação de requisitos.
Além do tamanho medido, um subproduto do processo é a avaliação do
quão sólida e completa está a especificação de requisitos. Esse instrumento
pode ser uma ferramenta complementar na gerência dos requisitos.
Neste capítulo, ao tratar das aplicações da análise de pontos de função
na gerência de projetos, foram apresentados vários exemplos de aplicações
da técnica no planejamento, controle e monitoramento de projetos. Da
mesma forma, tratou-se das aplicações da técnica e de seus produtos no
estabelecimento de relacionamento com fornecedores externos à
organização.
Contudo, é preciso explorar em mais detalhes as aplicações da análise
de pontos de função em questões de garantia de qualidade de produto e
processo. Com base no tamanho funcional é possível monitorar uma série
de fatores relacionados a uma grandeza significativa para os clientes dos
sistemas e, consequentemente, também para aqueles que os desenvolvem e
os mantêm. Como exemplos podem-se destacar a evolução no tempo do
crescimento funcional de cada aplicação e a quantidade de recursos
alocados à manutenção por ponto de função.
Neste breve resumo sobre os principais modelos utilizados em
iniciativas de melhoria de processos de software, é possível verificar o
papel relevante da aplicação de métricas. E como não poderia deixar de ser,
a medição de tamanho, em pontos de função, pode suportar todo o processo.

O Que Medir?
Uma vez estabelecido por que medir, a próxima pergunta que se deve
responder é: o que medir? Medida é, por definição, a quantificação de uma
característica. No caso da área de sistemas devem ser avaliadas não só suas
características de produto final, mas também as características dos
processos envolvidos em sua concepção e construção. Dessa forma primeiro
é preciso identificar as características relevantes para análise.
No artigo intitulado “Software modeling and measurement: The
Goal/Question/ Metric paradigm” , publicado pelo Departamento de
Ciência da Computação da Universidade de Maryland, Victor R. Basili
apresentou um modelo bastante ilustrativo e útil no processo de
identificação dessas características:
“Para cada um dos objetivos que deseja acompanhar é possível
estabelecer um conjunto de perguntas que verifique o seu cumprimento;
para muitas dessas perguntas é possível identificar uma métrica que possa
quantificar a resposta.”
De forma bastante resumida e objetiva, em um único parágrafo, é
possível construir as bases para a seleção das características cuja medição
seja relevante. A chave está na identificação dos objetivos estabelecidos
tanto para o processo de desenvolvimento e manutenção de sistemas quanto
para o produto gerado em si.
Uma determinada organização estabeleceu que o lançamento do novo
serviço de captação de pedidos on-line estaria disponível dois meses antes
do Natal. Nessa empreitada a administração da empresa reservou um
orçamento de $ 500.000,00. Esses objetivos foram traçados com base nas
estimativas do departamento de tecnologia que, com base nos requisitos, na
funcionalidade fornecida pelo novo sistema e em outros aspectos
tecnológicos, optou por especificá-lo internamente e contratar sua
construção por uma empresa. Para resguardar os interesses da empresa,
cláusulas de garantia de nível de serviço foram incluídas no contrato.
Do parágrafo anterior é possível extrair alguns aspectos que são
relevantes para a organização, como, por exemplo, recursos e custos,
tamanho do produto, qualidade do produto, cronograma e progresso.
Contudo, neste nível a abrangência é muito ampla e de difícil
acompanhamento. A criação de categorias que agrupem conjuntos de
métricas afins é uma solução para diminuir a complexidade envolvida e
permitir um maior foco em itens mais específicos. Por exemplo, ao avaliar
Recursos e Custos, é possível definir as informações sobre Equipe como
uma categoria em particular. Nessa categoria são incluídas informações que
caracterizam a quantidade de esforço planejado e consumido por atividades
ou produtos de interesse, a quantidade e experiência da equipe alocada ao
projeto, assim como a taxa de rotatividade dessas pessoas. Essas métricas
podem ser usadas para avaliar a adequação do esforço previsto e analisar a
situação atual do esforço despendido, sendo essenciais para avaliar a
produtividade.
O Tamanho e a Estabilidade do Produto consiste em outro aspecto
relevante que também pode ser extraído da situação hipotética apresentada.
Esse aspecto por um lado considera o tamanho ou volume do objeto da
análise, enquanto por outro lado pondera mudanças em seu escopo ou
quantidade. O aumento do tamanho ou a diminuição de sua estabilidade
normalmente requer mais recursos ou uma dilatação de seu prazo. Da
mesma forma que na avaliação dos recursos e custos é útil criar categorias
que tornem mais simples o monitoramento, na avaliação do Tamanho e
Estabilidade do Produto também podem ser criadas algumas categorias
como Tamanho Funcional e Tamanho Físico. Na primeira, Tamanho
Funcional, três são as medidas mais utilizadas: Pontos de Função, Carga de
Trabalho com Mudanças Funcionais e Quantidade de Requisitos.
A sistemática apresentada anteriormente é baseada no modelo definido
pelo PSM ( Practical Software and Systems Measurement ). Esse modelo
define um processo prático para avaliação dos diversos aspectos, riscos e
considerações envolvidos em projetos de software. Ele fornece informações
objetivas não só para suporte a decisões coerentes, mas também para que se
alcancem os objetivos técnicos e gerenciais definidos. Ele está baseado em
experiências reais do departamento de defesa, do governo e do mercado
americano, representando as melhores práticas utilizadas por esses grupos.
O núcleo do PSM é a definição do mapeamento entre aspectos gerais e
específicos ao projeto ou organização e as diversas métricas envolvidas,
agrupadas em categorias. A esse mapeamento é dada a designação de “I-C-
M List”. Uma das grandes vantagens do PSM é a disponibilidade de
modelos que refletem padrões adequados para a grande maioria dos casos.
Independentemente do modelo utilizado para implementar um programa
de métricas, a coleta de métricas é apenas um dos requisitos envolvidos. A
combinação dessas medidas coletadas é o que gera visibilidade quanto a
algum aspecto ou conceito relevante ao desenvolvimento ou manutenção de
sistemas. Esses indicadores, baseados em medidas diversas, permitem o
monitoramento dos vários processos envolvidos.
Então, respondendo à pergunta original sobre o que medir: devem ser
medidos características, propriedades e eventos, cuja quantificação seja
relevante para responder a objetivos definidos.
Uma destas propriedades que certamente se enquadra na proposição
referida é o tamanho. Ele tem o papel de ser um fator normalizador dos
dados coletados e deve ser representativo dos bens ou serviços produzidos.

Qual Medida Melhor Representa o

Tamanho?
Ao explorar a motivação para medir e os objetos de medição, chega-se à
conclusão que o tamanho é uma das propriedades que deve ser medida.
Agora, é necessário avaliar a melhor unidade para medir o tamanho de
sistemas.
A unidade mais intuitiva é o número de linhas de código. Os estudantes
da área, ao iniciarem na prática de programação, ao compararem entre si os
programas desenvolvidos para resolver um problema específico, já utilizam
o número de linhas de código como parâmetro de comparação.
A aparente facilidade o uso de linhas de código (LOC) é perigosa. Pode-
se incorrer no risco de usar dois pesos e duas medidas, se alguns pontos não
forem esclarecidos ao exprimir uma determinada quantidade de LOC,
como, por exemplo:
• A inclusão na contagem da quantidade de linhas de
comentários, linhas em branco ou comandos nulos;
• A inclusão na contagem de diretrizes de compilação;
• A contagem de múltiplos comandos ou declarações em
uma única linha como várias linhas, uma para cada
comando ou declaração;
• A contagem de uma única linha nos casos em que um
único comando ou declaração é expresso em múltiplas
 linhas;
• A inclusão na contagem de delimitadores de blocos de
comandos nos casos em que de fato haja mais de um
comando;
• A desconsideração de delimitadores de blocos de
comandos nos casos em que sua utilização seja opcional.
Como pode ser percebido, apesar de aparentemente intuitiva, a
contagem de linhas de código pode envolver uma série de regras para ser
realizada. E não há um padrão de fato para essa contagem.
Outro aspecto fundamental é a falta de significado para o cliente da
quantidade de linhas de código. Para o cliente de um sistema saber que ele
possui 1.000.000 LOC é o mesmo que dizer que ele possui 4530 bitstuffs .
Como foi discutido anteriormente, a medição não só deve ser feita, mas
também pode ser estimada. Em 1981, Dr. Barry Boehm publicou o primeiro
modelo COCOMO, COnstructive COst MOdel. Esse modelo utiliza LOC
como subsídio para a geração de estimativas de esforço, prazo e custo.
Mesmo por critérios de similaridade entre sistemas e projetos, é difícil
estimar quantas linhas de código serão necessárias para atender a um
determinado conjunto de requisitos funcionais. Além do mais, existem
tecnologias atualmente para as quais mesmo o conceito de quantidade de
LOC é de difícil abstração. O COCOMO II contempla esse aspecto da
tendência crescente de componentização e programação visual.
Em resumo, devem-se destacar alguns reveses na utilização de LOC
como unidade para medir o tamanho de sistemas:
• Falta de padronização;
• Falta de significado para os clientes usuários do objeto
de medição;
• Dificuldade de aplicação nas fases iniciais do ciclo de
vida;
• Dependência da linguagem de programação utilizada.
 Exatamente pela urgência na solução desses reveses através de uma
nova métrica complementar à contagem das Linhas de Código, em 1975,
Allan Albrecht definiu os conceitos que serviram de base para a métrica dos
pontos de função.
A técnica de análise de pontos de função é um método padrão para
medir sistemas do ponto de vista de seus usuários pela quantificação da
funcionalidade solicitada e fornecida.

O que é a Análise de Pontos de Função?

E o que é Ponto de Função?
A Análise de Pontos de Função (APF) é uma técnica de medição das
funcionalidades fornecidas por um software do ponto de vista de seu
usuário. Ponto de função é a unidade de medida desta técnica que tem por
objetivo tornar a medição independente da tecnologia utilizada para a
construção do software. Ou seja, a APF busca medir o que o software faz, e
não como ele foi construído.
O processo de medição, ou a contagem de pontos de função, baseia-se
em uma avaliação padronizada dos requisitos lógicos do usuário.
Empiricamente as principais técnicas de estimativa de projetos de
desenvolvimento de software assumem que o tamanho de um software é um
vetor importante para a determinação do esforço para sua construção. Logo,
saber o seu tamanho é um dos primeiros passos do processo de estimativa
de esforço, prazo e custo.
É importante destacar que pontos de função não medem diretamente
esforço, produtividade ou custo. É exclusivamente uma medida de tamanho
funcional do software. Este tamanho em conjunto com outras variáveis é
que pode ser usado para derivar produtividade, estimar esforço e custo.

Questões para Fixação

1. Estabeleça as diferenças entre os conceitos de medida,

indicador e métrica.
2. Na área de desenvolvimento de software, qual a
principal equação a ser resolvida para garantir o máximo
de satisfação aos clientes?
3. Atualmente, quais os principais recursos utilizados para
solucionar essa equação?
4. De que forma a análise de pontos de função pode
contribuir para o processo de gerenciamento de projetos
nas fases de planejamento e controle?
5. Como a medição funcional e seus indicadores derivados
podem influenciar uma análise de make-or-buy em um
processo de gestão de contratos?
6. Quais as desvantagens dos modelos de contratação a
Preço Global Fixo e a Homem-Hora sob os pontos de
vista tanto do contratante quanto do contratado?
7. De que forma a análise de pontos de função pode ser
utilizada para melhor distribuir os riscos de projeto entre
contratante e contratado num processo de terceirização
de serviços de desenvolvimento?
8. Cite algumas medidas preventivas que devem ser
adotadas pela organização que deseja contratar serviços
de desenvolvimento de sistemas baseados em pontos de
função.
9. De modo geral, quais são as utilidades da análise de
pontos de função para o processo de terceirização e
gestão de contratos?
10. Qual o papel da aplicação de métricas nas iniciativas
de melhoria de processos de software?
11. De acordo com o paradigma de Basili,
Goal/Question/Metric , o que deve ser medido num
processo de medição funcional?
12. Quais os fatores contrários à utilização de LOC como
unidade para medir o tamanho de sistemas?
Bibliografia

1. BASILI, V. R. Software Modeling and Measurement:

The Goal/Question/Metric Paradigm. Universidade de
Maryland, 1992. (Relatório Técnico CS-TR-2956).
2. BOEHM, B. A. Spiral Model for Software
Development and Enhancement. IEEE Computer , v.
21, n. 5, mai. 1988.
3. ______. Software Engineering Economics . Nova
Jersey: Prentice Hall, 1982.
4. BROOKS, F. The Mythical Man-Month: Essays on
Software Engineering. Addison-Wesley, 1995.
(Anniversary Edition).
5. DEKKERS, C. Function Points and Measurement:
What’s a Function Point? QAI Journal , dez. 1998.
6. DEKKERS, C.; AGUIAR, M. Using Function Point
Analysis to Check the Completeness (Fullness) of
Functional User Requirements. Cutter IT Journal , abr.
2000.
7. DEKKERS, C.; EMMONS, B. How Function Points
Support the Capability Maturity Model Integration.
CrossTalk , fev. 2002.
8. GARMUS, D.; HERRON, D. Function Point
Analysis: Measurement Practices for Sucessful Software
Projects. Addison-Wesley, 2000.
9. IFPUG. Function Point Counting Practices Manual:
Release 4.3. International Function Point Users Group,
2010.
10. JONES, C. Applied Software Measurement . 2. ed.
Nova York: McGraw-Hill, 1996.
11. PAULK, M. et al. Capability Maturity Model for
Software: Version 1.1. Software Engineering Institute,
1993. (Relatório Técnico CMU/SEI-93-TR-024).
12. PAULK, M. et al. Key Practices of the Capability
Maturity Model: Version 1.1. Software Engineering
Institute, 1993. (Relatório Técnico CMU/SEI-93-TR-
025).
13. PMI. A Guide to The Project Management Body of
Knowledge . Project Management Institute, 2000.
14. WANG, Y.; KING, G. Software Engineering
Processes: Principles and Application. CRC Press, 2000.
 2

O Mundo das Métricas Funcionais

Objetivo
O objetivo deste capítulo é apresentar um breve histórico da análise de
pontos de função e citar outros métodos de medição funcional
desenvolvidos e utilizados atualmente com alguma relevância em outras
partes do mundo. São destacadas também várias organizações que realizam
um importante trabalho de divulgação da importância da medição de
software e de suporte ao desenvolvimento de pesquisas sobre os métodos de
medição e suas aplicações. A página na Internet de cada uma dessas
organizações citadas ao longo deste capítulo é uma interessante fonte de
informações e vale a visita.

Breve Histórico
A técnica da análise de pontos de função surgiu na IBM, no início da
década de 1970, como alternativa às métricas baseadas em linhas de
programa (código-fonte). Na época, Allan Albrecht foi encarregado de
estudar a produtividade dos projetos de software desenvolvidos por uma
unidade da IBM. Alguns desses projetos tinham sido desenvolvidos em
linguagens de programação distintas, tornando inviável uma análise
conjunta de produtividade usando a métrica de linhas de código. Isso
motivou a busca por uma medida que fosse independente da linguagem de
programação utilizada.
Após a apresentação da técnica à comunidade, no final da década de
1970, e dos sucessivos trabalhos efetuados por Capers Jones, destacando
sua importância, houve um crescimento acelerado do número de usuários de
pontos de função, culminando, em 1986, na fundação do International
Function Point Users Group (IFPUG). Em 1988 o IFPUG publicou a
versão 2.0 do seu Manual de Práticas de Contagem (ou CPM - Counting
Practices Manual ), com o objetivo de padronização da técnica. Juntamente
com a aceitação crescente do mercado da técnica de pontos de função
surgiram também diversas variações da proposta apresentada por Allan
Albrecht. Em 1990, o IFPUG publicou a versão 3.0 do seu manual que foi a
primeira versão considerada madura. Desde então este é o padrão mais
difundido no mercado para pontos de função.
Atualmente a versão mais recente do CPM é a 4.3.1. Embora
posteriormente à publicação original tenham surgido outras técnicas de
medição funcional, como Mark II e COSMIC, nenhuma delas possui ainda
a aceitação tão ampla pelo mercado quanto os pontos de função do IFPUG.

IFPUG
O IFPUG 6 é uma entidade sem fins lucrativos, composta por pessoas e
empre- sas de diversos países, cuja finalidade é promover um melhor
gerenciamento dos processos de desenvolvimento e manutenção de
software com o uso de pontos de função e outras técnicas de medição. É
movido pelo trabalho voluntário de seus membros e promove uma série de
ações:
• Conferência anual: especialistas renomados apresentam
o estado da arte na área de métricas de software e os
usuários têm a oportunidade de trocar experiências.
• Seminários e workshops educacionais: abrangem uma
série de tópicos como práticas de contagem de pontos de
 função, técnicas de gerenciamento de projeto e melhoria
de processos.
• Certificação profissional: programa que envolve a
certificação dos usuários da técnica como especialistas
em pontos de função (CFPS), de materiais de
treinamento de fornecedores e de ferramentas de
software para apoio ao processo de contagem.
• Comitês e grupos de trabalho: são o centro das
atividades do IFPUG. O comitê de certificação é
responsável por desenvolver e manter o programa de
certificação. O comitê de comunicação e marketing é
responsável por estabelecer e manter os canais de
comunicação entre o IFPUG e seus membros. O comitê
de conferência planeja e promove a conferência anual. O
comitê de padrões de medição funcional é responsável
por manter o CPM e solucionar questões ligadas à
técnica, além de desenvolver conteúdo com diretrizes
para a aplicação de pontos de função em novos
ambientes. O comitê de educação promove os seminários
e workshops . O comitê de performance de TI tem a
missão de ajudar os membros a planejar, gerenciar e
melhorar as práticas e processos de engenharia de
software.
Além dessas ações, o IFPUG tem uma diretoria que possui como um
dos objetivos estimular a criação de associações locais ( chapters ) para
trocar experiências e estabelecer uma rede de contatos entre pessoas com
objetivos comuns, como a análise de pontos de função e métricas de
software.
 O manual de práticas de contagem está disponível gratuitamente para os
membros do IFPUG e para os não membros somente mediante aquisição.
Isso dificulta um pouco a difusão da técnica. É uma filosofia diferente da
adotada pelas organizações responsáveis pelo Mark-II e COSMIC que
disponibilizam acesso gratuito aos seus manuais.

Pontos de Função no Brasil e BFPUG

O uso da técnica da análise de pontos de função no Brasil começou
significativamente no início da década de 1990. No período de 1991 a 1996,
foram realizados seis ENUPF (Encontro Nacional de Usuários de Pontos de
Função), inclusive com a participação de palestrantes internacionais.
Porém, o interesse do mercado consolidou-se apenas quando grandes
contratos públicos de desenvolvimento e manutenção de sistemas
começaram a ser baseados em pontos de função. Em paralelo, o interesse
crescente das organizações ligadas ao desenvolvimento de software por
modelos de qualidade e maturidade (ISO e CMM à época) contribuiu para o
aumento de interesse no assunto. A criação do BFPUG foi também um
importante marco para essa consolidação.
O BFPUG 7 ( Brazilian Function Point Users Group ) é o chapter do
IFPUG no Brasil. Esse grupo é a evolução de um grupo de usuários do Rio
de Janeiro, o FPUG-Rio. Foi constituído em 1998 e possui centenas de
associados, entre eles estudantes, desenvolvedores, consultores e gerentes
de sistemas. Sua página na Internet fornece diversos recursos como agenda
de eventos, oportunidades profissionais, artigos, apresentações e também
um fórum de discussão 8 gratuito e bem ativo. Além do fórum, o BFPUG
promove a troca de experiências entre os usuários da APF através de
encontros, palestras e conferências.

NESMA
A NESMA 9 ( Netherlands Software Metrics Users Association ), uma
associação de usuários de métricas de software da Holanda, foi fundada em
maio de 1989, inicialmente com o nome NEFPUG ( Netherlands Function
Point Users Group ). Suas ações e objetivos são semelhantes aos do
IFPUG, inclusive com uma colaboração muito próxima entre as duas
organizações. A NESMA mantém seu próprio manual de contagem (com
distribuição paga), atualmente na versão 2.1, cuja primeira versão de 1990
foi baseada no manual do IFPUG. Ambos os manuais utilizam a mesma
filosofia, conceitos, termos e regras, com algumas diretrizes diferentes, o
que permite que uma contagem de pontos de função de um projeto de
desenvolvimento ou de uma aplicação utilizando as duas abordagens
alcance resultados bem próximos.
Ambas as organizações possuem abordagens distintas para a aplicação
da análise de pontos de função em projetos de melhoria de software,
abordadas no capítulo 7. Atualmente a NESMA é um dos maiores grupos
de usuários de pontos de função da Europa. Algumas propostas
apresentadas pela NESMA são bastante utilizadas pelos usuários de pontos
de função do IFPUG, por exemplo, as técnicas de estimativa de tamanho
(contagem indicativa e estimativa, descritas no capítulo 9).

Mark II
O Mark II ou Mk II foi publicado em 1991 no artigo “Software Sizing
and Estimating: Mk II FPA” por Charles Symons após desenvolvimento
interno da KPMG entre 1985 e 1986, inspirado na proposta de Albrecht.
Seu trabalho tornou-se mais conhecido somente em 1988, após uma
publicação na revista IEEE - Transactions on Software Engineering . A
disseminação da técnica foi dificultada inicialmente pelo fato de o método
ter a situação de método proprietário da consultoria KPMG por vários anos.
Atualmente é de domínio público e a organização responsável por manter o
padrão da técnica é a associação de métricas do Reino Unido - UKSMA 10 ,
que também possui ações e objetivos similares ao IFPUG. Porém, continua
sendo um método de aplicação restrita ao Reino Unido. O manual do MK-II
pode ser obtido gratuitamente por download do site da UKSMA.

COSMIC
 Em 1997, um grupo de pesquisadores (Denis St-Pierre, Marcela Maya,
Alain Abran, Jean Marc Desharnais e Pierre Bourque) da Universidade de
Quebec desenvolveu um novo método de medição funcional para sistemas
de tempo real, denominado Full Function Points (FFP). Posteriormente os
experimentos de campo mostraram que esse método poderia ser aplicado
também em sistemas de informação tradicionais, o que motivou os
pesquisadores a trabalhar em uma versão melhorada do método.
Em 1998, um grupo de especialistas em medição de software, liderados
por Alain Abran e Charles Symons, constituiu o COSMIC 11 ( Common
Software Measurement International Consortium ) com o objetivo de
desenvolver um novo método de medição de tamanho funcional baseado
nas melhores características dos métodos existentes e que incorporasse
novas ideias. Esse novo método proposto em 2000, batizado de COSMIC-
FFP (posteriormente simplificado para apenas COSMIC), na prática foi um
refinamento do método FFP.
Atualmente a difusão desse método é maior na Europa e Canadá.
Embora o método do IFPUG seja o de uso mais difundido no mundo, a
produção de trabalhos acadêmicos sobre o COSMIC tem sido maior. O
manual do COSMIC (atualmente na versão 3.0.1) pode ser obtido
gratuitamente por download do site do COSMIC.

Padrão ISO de Medição Funcional

A medição funcional é um termo geral para métodos de
dimensionamento de software baseados nas funções solicitadas pelos
usuários. Já no final de 1992, podiam ser reconhecidos diversos métodos de
medição de tamanho funcional ( Functional Size Measurement - FSM),
surgidos a partir de diferentes interpretações do método original da Análise
de Pontos de Função proposto por Allan Albrecht. Com o objetivo de
resolver as inconsistências existentes entre tais métodos e estabelecer um
método mais rigoroso de medição funcional, os grupos de usuários de
métricas de software da Austrália, Reino Unido, Holanda e Estados Unidos
formaram o grupo de trabalho denominado WG12 ( Working Group 12 ),
subordinado ao SC7 12 ( Sub-Committee Seven ) do JTC1 ( Joint Technical
Committee One ) estabelecido pela ISO ( International Organization for
Standardization ) em conjunto com o IEC ( International Engineering
Consortium ).
Como resultado dos trabalhos do WG12 foi estabelecido um conjunto de
padrões internacionais chamado de norma 14143, dividida nas seguintes
partes:
• 14143-1: Definição de Conceitos;
• 14143-2: Avaliação da Conformidade de Métodos de
Medição de Software com Relação ao Padrão ISO/IEC
14143-1;
• 14143-3: Verificação de um Método de Medição de
Tamanho Funcional;
• 14143-4: Modelo de Referência para Medição de
Tamanho Funcional;
• 14143-5: Determinação de Domínios Funcionais para
Uso com Medição de Tamanho Funcional;
• 14143-6: Guia de Uso da Série ISO/IEC 14143 e
Padrões Internacionais Relacionados.
A norma ISO/IEC 14143 foi desenvolvida para garantir que todos os
métodos de medição de tamanho funcional sejam baseados em conceitos
similares e possam ser testados para assegurar que eles se comportam de
maneira similar e da forma esperada por um método de medição,
dependendo dos domínios funcionais a que se aplicam.
A fim de ser considerada uma técnica de Medição Funcional de
Tamanho no padrão ISO-14143, a técnica de análise de pontos de função,
conforme definida na versão 4.1 do manual do IFPUG, foi submetida a um
PAS ( Publicly Available Specification ) para a ISO e ao final do ano de
2002, foi aprovada sob a denominação ISO/IEC 20926:2002.
Atualmente são cinco os métodos padrão de medição de tamanho
funcional de software:
• IFPUG CPM 4.3 (ISO/IEC 20926);
• NESMA CPM 2.1 (ISO/IEC 24570);
• Mark II (ou MK II) CPM 1.3.1 (ISO/IEC 20968);
• COSMIC Measurement Manual 3.0.1 (ISO/IEC 19761);
• FISMA 1.1 (ISO/IEC 29881).

ISBSG
O ISBSG 13 ( International Software Benchmarking Standards Group ) é
uma organização sem fins lucrativos, resultado de uma iniciativa conjunta
de diversas organizações de métricas de software do mundo (Austrália,
Estados Unidos, Índia, Espanha, Alemanha, Itália, Japão, Holanda, Reino
Unido etc.), cuja missão é “manter um repositório público de métricas de
projetos de software que possa ajudar na gestão dos recursos de TI pela
melhoria das estimativas de projeto e produtividade, análise de riscos e
benchmarking ”.
As ações do ISBSG nesse sentido são fornecimento de um modelo
padrão para o registro e a coleta de dados de projetos de software,
fornecimento de uma ferramenta de auxílio à coleta de dados,
gerenciamento do repositório de dados de projeto, coordenação de um
programa de pesquisa baseada em seu repositório e publicação de livros e
relatórios.
Seu repositório de dados, contendo informações de mais de 6.000
projetos de software de dezenas de países, constitui-se em uma valiosa
ferramenta de benchmarking . Além disso, possibilita que sejam feitas
diversas análises e pesquisas abordando questões como estimativa,
produtividade, boas práticas etc. Periodicamente o próprio ISBSG publica
diversos relatórios oferecendo análises detalhadas do seu repositório em
diversos aspectos.
 Figura 2.1: Produtividade (H/PF) por linguagem de programação
primária dos projetos do repositório do ISBSG. Fonte: The Software
Metrics Compendium, 2002.

Esse repositório é alimentado continuamente por organizações de todo o

mundo e de diferentes áreas de negócio. Esses projetos, de tamanhos
variados, abrangem diversas plataformas tecnológicas, linguagens de
programação, metodologias e técnicas. Qualquer organização pode
contribuir com informações de seus projetos para o repositório. O ISBSG
garante a confidencialidade dos dados fornecidos e o anonimato da
organização que submeteu os dados. Os atributos coletados para os projetos
incluem:
• Tamanho funcional do projeto (medido por qualquer um
dos seguintes métodos de medição funcional: IFPUG,
NESMA, MARK II ou COSMIC);
• Esforço, custo, duração e qualidade do produto final;
• Contexto do projeto, ambiente de desenvolvimento,
ferramentas e técnicas empregadas.
Como benefício àqueles que contribuem com dados de projetos para o
repositório, o ISBSG oferece:

• Submetendo de um a quatro projetos: um relatório de

benchmarking para cada projeto;
• Submetendo mais de cinco projetos: um exemplar de
qualquer livro publicado pelo ISBSG, além dos
relatórios de benchmarking ;
• Submetendo mais de 50 projetos: além dos relatórios
para cada projeto, assinatura anual do ISBSG e a última
versão dos dados publicados do repositório de projetos.

Pontos por Caso de Uso (Use Case

Points)
Até o início da década de 1990 havia a falsa noção de que a APF não era
adequada para medir sistemas orientados a objetos. Aqueles que
compartilhavam desta noção, na prática desconheciam a APF.
Com a disseminação da construção e projeto de sistemas orientados a
objetos, houve também uma mudança na forma de especificar e modelar os
sistemas. A UML e os casos de uso rapidamente se tornaram padrão na
indústria de software.
Dentro deste contexto, em 1993 Gustav Karner propôs em um trabalho
acadêmico a metodologia dos Pontos por Caso de Uso (inspirado na Análise
de Pontos de Função) com o intuito de estimar recursos para projetos de
software orientados a objeto desenvolvidos com o processo Objectory (um
antecessor do RUP).
 O processo de medição do PCU consiste resumidamente em:
1. Contar os atores e identificar sua complexidade.
2. Contar os casos de uso e identificar sua complexidade.
3. Calcular os PCUs não ajustados.
4. Determinar o fator de complexidade técnica.
5. Determinar o fator de complexidade ambiental.
6. Calcular os PCUs ajustados.
Com o resultado dessa medição e sabendo-se a produtividade média da
organização para produzir um PCU, pode-se então estimar o esforço total
para o projeto.
A princípio, o método é bastante parecido com a APF; porém na prática
há diferenças significativas. A APF mede duas dimensões do software,
sendo dados e transações, enquanto o PCU mede atores e casos de uso. A
diferença mais significativa é que a APF pode ser aplicada a qualquer tipo
de software, independente de como este será desenvolvido. Já o PCU só
pode ser aplicado a projetos de software que especifiquem requisitos através
de casos de uso; o que nem sempre é o caso. Como medir ou estimar
aplicações legadas que via de regra não possuem documentação atualizada?
Definir os seus casos de uso para depois poder aplicar o PCU torna o seu
uso inviável nesta situação. É um erro achar que o PCU será um método
melhor que a APF se o projeto for especificado via casos de uso. A APF
pode ser (e é) aplicada a casos de uso, sem nenhuma dificuldade adicional.
Devido ao processo de medição do PCU ser baseado em casos de uso, o
método não pode ser empregado antes de concluída a análise de requisitos
do projeto. Na maioria das vezes há a necessidade de obter uma estimativa
antes da finalização desta etapa. O processo de medição da APF também só
pode ser empregado após o levantamento dos requisitos do projeto. Existem
técnicas estimativas de tamanho em pontos de função que podem ser
aplicadas com sucesso antes de a análise de requisitos ser concluída. Um
exemplo são as contagens indicativa e estimativa propostas pela NESMA
(veja capítulo de Estimativa).
Outra dificuldade com o PCU é conseguir uma medida padronizada,
consistente e isenta de subjetividade. Não existe um padrão único para a
escrita do caso de uso. Diferentes estilos na escrita dos caso de uso ou na
sua granularidade podem levar a resultados diferentes na medição por PCU.
A medição pela APF dos casos de uso de um sistema sempre chegará ao
mesmo resultado, independente do estilo de escrita dos casos de uso ou de
sua granularidade, pois a APF “quebra” o requisito no nível adequado para
a medição usando o conceito de Processo Elementar (veja capítulo Funções
do Tipo Transação).
A determinação dos fatores técnico e ambiental do PCU está sujeita a
um certo grau de subjetividade que dificulta a consistência da aplicação do
método em diferentes organizações. O fator de ajuste (VAF) da APF
também possui o mesmo problema, embora o IFPUG possua diretrizes
específicas que ajudam a minimizar (mas não eliminar) esse impacto
(capítulo Fator de Ajuste). Na prática o uso do VAF é opcional e está em
desuso; é provável que essa parte do método seja eliminada pelo IFPUG em
um futuro breve.
Dentre as desvantagens citadas do PCU em relação à APF, algumas
poderiam ser superadas com alguns ajustes simples. Não existe um grupo de
usuários ou organização responsável pela padronização ou evolução do
método PCU; e a bibliografia sobre o assunto é escassa. Não há um corpo
de conhecimento único oficial sobre PCU. O que se publicou até hoje sobre
o assunto foram artigos acadêmicos com propostas de adequações e
melhorias à ideia original. Para a APF existe o IFPUG que é o responsável
por manter o Manual de Práticas de Contagem - o corpo de conhecimento
da APF, que é evoluído continuamente. E também há diversos fóruns de
discussão sobre APF para a troca de experiências.
Em suma, não há benefício adicional do PCU em relação à APF. Usar
ambos os métodos também não compensaria o custo adicional de medição e
o esforço para treinar a equipe nos dois métodos. Converter o resultado da
medição por um dos métodos em outro também não faz muito sentido,
tendo em vista que a base da medição de ambos é distinta (dados e
transações na APF e atores e casos de uso no PCU).

Bibliografia
1. ALBRECHT, A. J. Measuring Application
Development Productivity: Proceedings of Joint
SHARE/GUIDE/IBM Application Development
Symposium. Disponível em:
<http://www.fattocs.com.br/artigos/MeasuringAplication
DevelopmentProductivity.pdf>. Versão traduzida para o
português disponível em:
<http://www.fattocs.com.br/artigos/MedindoaProdutivid
adedoDesenvolvimentodeAplicativos.pdf>. Acesso em:
9 jun. 2010.
2. BRAGA, A. Análise de Pontos de Função . Rio de
Janeiro: IBPI Press, 1996.
3. COSMIC. COSMIC Measurement Manual: Versão
3.0.1. Common Software Measurement International
Consortium, 2009.
4. GARMUS, D.; HERRON, D. Function Point
Analysis: Measurement Practices for Sucessful Software
Projects. Addison-Wesley, 2000.
5. IFPUG. Framework for Functional Sizing: Versão
1.0. International Function Point Users Group, 2003.
6. IFPUG. Function Point Counting Practices Manual:
Versão 4.3. International Function Point Users Group,
2010.
7. ISBSG. The Software Metrics Compendium .
International Software Benchmarking Standards Group,
2002.
8. JONES, C. Applied Software Measurement . 2. ed.
Nova York: McGraw-Hill, 1996.
9. KARNER, G. Use Case Points: Resource Estimation
for Objectory Projects. Objective Systems, 1993.
10. SYMONS, C.R. Function Point Analysis: Difficulties
and Improvements. IEEE Transactions on Software
Engineering , v. 14, n. 1, jan. 1988.
11. UKSMA. Mk II Function Point Analysis Counting
Practices Manual: Versão 1.3.1. United Kingdom
Software Metrics Association, 1998.
 3

O Processo de Medição
Funcional

Introdução
Este capítulo apresenta a visão geral da medição de software em pontos
de função de acordo com o IFPUG e destaca os princípios fundamentais
para a correta aplicação do método tanto em software pronto (produto)
quanto naquele em desenvolvimento ou melhoria (projeto).
Os métodos de medição permitem expressar quantitativamente
qualidades de um objeto ou fenômeno. Quando se mede um objeto físico, as
dimensões de interesse mais populares costumam ser sua altura, volume,
área ou peso. De maneira análoga, software também tem uma diversidade
de dimensões. A análise de pontos de função mede especificamente os
requisitos funcionais do usuário e essa dimensão recebe o nome de
tamanho funcional .
O processo de medição funcional é representado pelo diagrama da
Figura 3.1, que mostra suas etapas, bem como as relações de
interdependência entre seus passos. Cada passo será explicado ainda neste
capítulo, e alguns serão mais detalhados em capítulos seguintes.
 Figura 3.1: Visão geral do processo de medição funcional do
IFPUG.

Basicamente a medição consiste em decompor o projeto ou a aplicação

em elementos denominados componentes funcionais básicos (ou funções).
O método conceitua abstrações, os tipos de função, nos quais os
componentes funcionais básicos são classificados. Dois tipos principais de
função são medidos, sendo funções de armazenamento e funções de
transação. Veja a Figura 3.2 em seguida.

Figura 3.2: Classificação dos tipos de função.

O método define referências para a identificação de cada componente

funcional básico, sua classificação quanto ao tipo de função e à
complexidade funcional e a determinação de sua contribuição individual. A
esses componentes funcionais básicos são dados os nomes de funções ou
funcionalidades.
 O diagrama da Figura 3.3 apresenta os tipos de função e o principal
referencial na identificação das funções que é a fronteira da aplicação. Ela
define o que é interno e externo ao sistema.

Figura 3.3: Elementos da contagem de pontos de função.

Podemos resumir, portanto, que a análise de pontos de função é um

método padrão do IFPUG para medir o tamanho de software do ponto de
vista do usuário, pela quantificação da funcionalidade a ele fornecida, ou
seja, medir o tamanho funcional do software.

Os Requisitos e a Contagem de Pontos

de Função
O modelo de referência observado pelo IFPUG na definição da análise
de pontos de função como um método de medição funcional é o ISO/IEC
14143 (veja o capítulo 2). Ele estabelece que os requisitos funcionais do
usuário são um subconjunto dos requisitos do usuário, que também incluem
os requisitos não funcionais.
Os requisitos funcionais são aqueles que capturam o que o software
deve fazer em termos de tarefas e serviços. Eles são requisitos relativos às
práticas e procedimentos do negócio do usuário, particulares de
determinada tarefa, de determinado serviço. Eles incluem, mas não estão
limitados a:
• Transferência de dados (por exemplo, entrada de dados
do cliente, envio de sinal de controle).
• Transformação de dados (por exemplo, cálculo de juros
bancários, derivação da temperatura média).
• Armazenamento de dados (por exemplo, armazenar
pedido do cliente, registrar temperatura ambiente ao
longo do tempo).
• Recuperação de dados (por exemplo, lista de
empregados atual, recuperar posição da aeronave).
Apesar de o modelo de referência da ISO/IEC deixar em aberto a
definição formal de requisito não funcional, ele estabelece que eles estão
associados a limitações de ordem geral à aplicação como um todo (em
contraste a uma função em particular) e dá alguns exemplos como:

• Restrições de qualidade (por exemplo, usabilidade,

confiabilidade, eficiência e portabilidade).
• Restrições organizacionais (por exemplo, locais para
operação, equipamento alvo e padrões de conformidade).
• Restrições ambientais (por exemplo, interoperabilidade,
proteção de danos acidentais ou intencionais e
privacidade).
• Restrições de implementação (por exemplo, linguagem
de desenvolvimento e prazo do cronograma).
A Figura 3.4 ilustra a hierarquia de classificação de requisitos utilizada
pela ISO/IEC na medição de tamanho funcional de software.
Versões antigas da análise de pontos de função também incluíam na
medição os requisitos não funcionais com um fator de ajuste (veja o
capítulo 6). No seu cálculo, alguns requisitos não funcionais são
contemplados com a avaliação de 14 Características Gerais de Sistema.
Neste caso o resultado da medição é expresso em termos de pontos de
função ajustados.

Figura 3.4: Categorias de requisitos do usuário, destacando

exemplos de limitações de ordem gerais consideradas como não
funcionais.

A Visão do Usuário e a Dinâmica da

Evolução dos Requisitos
A visão do usuário, base da contagem de pontos de função, é o requisito
funcional como percebido pelo usuário. Ela é uma descrição formal das
necessidades de negócio do usuário na sua linguagem; é uma descrição das
funções de negócio aprovada pelo usuário. Ela se materializa em artefatos
como os seguintes, mas não limitada a eles:

• Estória de usuário;
• Proposta de projeto;
• Especificação de necessidades de negócio;
• Documento de visão;
• Modelo conceitual de entidades e relacionamentos;
• Diagrama de fluxo de dados;
• Diagrama de casos de uso;
• Especificação de caso de uso;
• Protótipo de interface etc.
A Figura 3.5 a seguir representa, de maneira geral, a dinâmica até a
formação de um requisito de software, segundo os pontos de vista dos
usuários e dos responsáveis pelo desenvolvimento do projeto.
Em um estágio inicial do processo, a necessidade do negócio do usuário
pode ser o único documento disponível para a análise de pontos de função,
o que não invalida sua aplicação. Nesse momento, devido ao baixo grau de
maturidade das informações, algumas premissas quanto a funcionalidades
desconhecidas e suas complexidades são assumidas, viabilizando a
realização de uma estimativa.

Figura 3.5: Da necessidade de negócio ao requisito de software.

As medições são viabilizadas à medida que o projeto evolui e novas

características e detalhamentos acerca dos requisitos são identificados.
Ainda assim, a precisão alcançada com a análise depende da qualidade e
maturidade dos requisitos identificados.
 Enquanto os requisitos forem expressos apenas como necessidades de
negócio ou mesmo características de sistema na visão dos usuários, eles
apresentarão as seguintes características:
• Muito genéricos;
• Às vezes ambíguos;
• Incompletos;
• Impossíveis de implementar;
• Altamente instáveis, sujeitos a mudanças.
Por essas e outras características, a utilização de requisitos neste nível
de maturidade em uma contagem de pontos de função dificilmente levará a
resultados precisos. A qualidade da medição está diretamente
relacionada à qualidade dos requisitos usados na análise . Porém, o
próprio processo de contagem de pontos de função ajuda a expor essa
imaturidade dos requisitos.
A partir do momento em que a visão do usuário é interpretada e
complementada com a visão do analista, os requisitos de software começam
a adquirir outras características:
• São mais específicos e sem ambiguidades.
• Fornecem descrição integrada de todas as necessidades
do usuário, inclusive com a normalização das
necessidades de vários usuários.
• Suas terminologias podem ser entendidas por ambos.
• Apresentam tendência à estabilidade.
Com essas características os requisitos trazem maior precisão para a
análise de pontos de função. Contudo, dependendo de fatores como
propósito da contagem, qualidade da documentação e mesmo o tempo
disponível, a análise pode ser conduzida com diferentes níveis de
detalhamento e, consequentemente, pode haver algumas diferenças em sua
precisão.
 Independente de ser uma estimativa ou uma medição, todas as premissas
assumidas e os resultados obtidos devem ser documentados como forma de
manter um histórico de cada etapa da análise, para que possam ser
consultados e auditados futuramente.

Ciclo de Vida do Software e a Medição

Pelo que foi apresentado até o momento sobre a importância dos
requisitos para a APF, conclui-se que não é possível medir o tamanho de um
software antes de sua especificação de requisitos estar completa (os
capítulos seguintes que detalham o processo de medição deixam isso bem
claro). Levando em conta que o momento em que as estimativas de projetos
de software são mais demandadas é justamente antes de a especificação de
requisitos estar completa, significa dizer que a APF tem pouco valor para as
estimativas de esforço, custo, prazo? Definitivamente não! A Figura 3.6 a
seguir ilustra como acontece essa dinâmica.

Figura 3.6: Evolução do escopo ao longo do projeto.

Embora o projeto ainda esteja em um estágio de concepção ou análise

de viabilidade (chamada de fase de Proposta na Tabela 3.1), alguns
requisitos são conhecidos de maneira mais ou menos parcial. Com base
nessas informações é possível estimar o tamanho em PF a partir de várias
técnicas (algumas são apresentadas no capítulo 9), então é possível derivar
as estimativas de esforço, custo, prazo.
Tabela 3.1: Fases do ciclo de vida do software em que é possível
realizar uma medição ou estimativa do tamanho do projeto em
pontos de função.
 Tamanho pode ser Tamanho
Fases de um ciclo de vida do software (hipotético) aproximado/estimad pode ser
o medido
Proposta: usuário expressa suas necessidades Sim Não
Requisitos: analistas e usuários reveem e acordam
quanto à expressão das necessidades e intenções do Sim Sim
usuário
Projeto: desenvolvedores podem incluir elementos
Sim Sim
para implementação que não são utilizados pela APF
Construção: implementação da solução de software
Sim Sim
projetada
Implantação: disponibilização do software para o
Sim Sim
usuário
Manutenção: modificações no software para atender
Sim Sim
novas demandas dos usuários

A estimativa do tamanho funcional é uma aproximação do tamanho real

do software, que pode ser mais ou menos precisa, conforme a qualidade dos
requisitos e o método usado para essa estimativa. A vantagem em estimar o
tamanho em vez de medir é que o tempo necessário para a estimativa é
menor, assim como a necessidade de informação sobre os requisitos.
Quando o problema que motiva a busca pelo tamanho funcional exige uma
resposta precisa, deve-se optar pela medição. Quando não há a necessidade
de uma precisão tão grande na resposta, ou o tempo disponível para
encontrar o tamanho funcional é escasso, ou os requisitos à disposição não
estão completos, a escolha por estimar o tamanho funcional acaba sendo a
melhor opção.
Após a implantação do software, entra-se na fase de manutenção do seu
ciclo de vida. Observe que a Tabela 3.1 não se refere às atividades de
manutenção, mas a uma fase de acompanhamento gerencial do software
produto. É possível aplicar a análise de pontos de função nessa fase,
contudo nem todas as atividades de manutenção são passíveis de medição
pela técnica.
Um software pode sofrer diversos tipos de manutenção. Anteriormente à
versão 4.3 do CPM, as definições do IEEE eram utilizadas para nortear a
medição funcional. Com a adoção desta versão, o IFPUG passa a adotar as
definições da ISO/IEC 14764:2006 que (assim como o IEEE) classifica as
manutenções de software em três tipos:
• Manutenção adaptativa: a modificação de um software
produto, executada após a entrega, para manter um
software produto passível de uso em um ambiente
modificado ou em modificação. A manutenção
adaptativa fornece melhorias necessárias para acomodar
mudanças no ambiente no qual o software deve operar.
Essas mudanças são aquelas que devem ser feitas para
que acompanhem as mudanças no ambiente. Por
exemplo, o sistema operacional pode ser atualizado e
algumas mudanças podem ser feitas para acomodar o
novo sistema operacional.
• Manutenção corretiva: a modificação reativa de um
software produto executada após a entrega de um
software produto para corrigir problemas identificados.
A modificação repara o software produto para satisfazer
os requisitos.
• Manutenção perfectiva: modificação em um software
produto após a entrega para detectar e corrigir falhas
latentes no software produto antes que se materializem
como falhas. A manutenção perfectiva fornece melhorias
para os usuários, na documentação de programas e
recodificação para melhorar a performance, facilidade de
manutenção ou outro atributo do software.
A APF propõe-se a medir apenas as manutenções que alteram os
requisitos funcionais , no caso, parte das manutenções adaptativas.
Orientação Prática ao Segregar
Requisitos Funcionais de não Funcionais
Um dos maiores desafios para quem começa a usar a análise de pontos
de função, senão o maior, é segregar os requisitos funcionais dos requisitos
não funcionais. Visando auxiliar o analista de pontos de função nessa tarefa,
algumas orientações práticas são apresentadas a seguir.

Distinção de Requisitos de Usabilidade

É comum encontrar sistemas com telas estruturadas em várias abas, ou
operações sendo realizadas por uma sequência de telas como em assistentes
( wizards ), ou quadros em um formulário maior, ou telas separadas de
dados funcionalmente dependentes entre si. A Figura 3.7 a seguir mostra
um exemplo.

Figura 3.7: Tela com várias abas: uma ou várias transações?

Ao analisar situações como esta que tenham indícios de representar

partes de um processo de negócio maior e incompleto se apenas cada parte
for realizada isoladamente, faça a seguinte pergunta ao especialista no
assunto:
 Pergunta-Chave: “Fossem esses passos realizados todos de uma vez,
por um mesmo usuário ou diferentes usuários desempenhando um mesmo
papel, a necessidade de negócio está atendida independente da maior
dificuldade de entrar os dados ou mesmo da aparência pior do
formulário?”.
Em caso positivo, há um forte indício de haver uma única transação
englobando as várias telas ou abas. Cabe ainda confirmar com outra
pergunta:
Pergunta de Confirmação: “Do ponto de vista de negócio, faz sentido
executar a ação em apenas uma das abas (ou telas) e o processo ser
considerado completo?”.
Se não há sentido do ponto de vista de negócio a ação apenas em parte
das abas, então temos uma única transação.
Quando há uma infraestrutura que provê a possibilidade de controlar
acesso do usuário até o nível de campo da tela, essa análise torna-se um
pouco mais difícil, porque todo pequeno passo que compõe um processo
(em potencial) pode ser alocado a um perfil de usuário em particular. Essa
característica geral do sistema não deve ser considerada na análise. O que
deve ser considerado são os requisitos particulares e específicos de uma
transação. Procure avaliar o processo de negócio, abstraindo do que foi
implementado no software.

Distinção de Requisitos de Desempenho

Ao identificar arquivos responsáveis por manter dados consolidados,
deve-se avaliar se esse requisito visa maior desempenho (requisito não
funcional) ou é relativo às práticas e procedimentos do negócio. Para
identificar isso, faça a seguinte pergunta ao especialista no assunto:
Pergunta-Chave: “Se esses dados consolidados não fossem mantidos
pelo sistema, ainda assim ele funcionaria? Não importa se demorasse uma
eternidade para que uma resposta fosse fornecida pelo sistema... usando os
dados analíticos que subsidiaram a criação desses dados consolidados, os
resultados atenderiam às suas necessidades?”.
 Em caso positivo, cabe confirmar a veracidade da resposta com outra
pergunta de:
Pergunta de Confirmação: “Sempre que um dado analítico, utilizado na
geração desse dado consolidado em análise, é atualizado (alterado ou
excluído), isso se reflete no dado consolidado? Eles sempre são mantidos
em sincronia? Quando os dados analíticos são expurgados, os dados
consolidados refletem isso?”.
Se a resposta for positiva, está confirmado que a única razão para
manter esses dados consolidados é o atendimento de requisitos de
desempenho e, portanto, não é um requisito funcional.

Distinção de Requisitos de
Confiabilidade
De maneira similar à orientação “Distinção de Requisitos de
Usabilidade”, quando avaliar, por exemplo, telas estruturadas em abas e
onde em cada passo do processo os dados sejam salvos , faça a seguinte
pergunta ao especialista no assunto:
Pergunta-Chave: “O motivo pelo qual esses dados são salvos em cada
etapa é relativo à instabilidade do ambiente? Por exemplo, em sistemas
Web é comum ao cadastrar um pedido, a cada produto incluído, alterado
ou excluído no pedido, haver a salva da operação para evitar uma nova
digitação, caso a conexão caia. Não fosse essa instabilidade, haveria a
preparação de todo o pedido e apenas ao final da edição desse pedido, ele
seria salvo como um todo, caracterizando o final de um processo de
negócio completo e indivisível. É este o caso nessa situação em análise?”.
Em caso positivo, cabe confirmar a veracidade da resposta com outra
pergunta:
Pergunta de Confirmação: “Outros usuários terem acesso aos dados
salvos nos passos intermediários é um problema violando as regras que
governam o seu sistema? No caso do pedido, antes de se concluir a
montagem do pedido existem mecanismos que impedem que esses dados
sejam publicados para outros usuários. É este o seu caso?”.
 Se a resposta for positiva, está confirmado que a única razão para as
salvas intermediárias são os requisitos de confiabilidade do sistema. A
pergunta de confirmação, muitas vezes apresenta um “falso negativo”, na
medida em que a sua implementação requer um trabalho adicional de
desenvolvimento. Muitas vezes nem é dada essa opção ao usuário que não
se apercebe do impacto negativo do atendimento desse requisito não
funcional nas suas práticas e procedimentos (funcional).

A Análise de Pontos de Função

Objetivos da APF
O IFPUG define como objetivos primários da análise de pontos de
função:
• Medir a funcionalidade que o usuário solicita e recebe.
• Medir o desenvolvimento e a manutenção de software de
forma independente da tecnologia utilizada para sua
implementação.

Objetivos do Processo de Medição

Para que a APF seja uma ferramenta útil, o processo de medição deve
ser:

• Simples o suficiente para minimizar o trabalho adicional

envolvido no processo de medição. Como o processo de
medição não pode ser completamente automatizado, há
necessidade do envolvimento de um analista de métricas
para a correta interpretação e análise dos requisitos do
usuário. Essa atividade demanda esforço, o que implica
 em onerar o esforço total do projeto. No entanto, o que
se busca é manter o esforço de medição em um patamar
que seja uma fração pequena do esforço total do projeto
e que esse esforço despendido possa gerar benefícios que
o compensem; por exemplo, melhor planejamento e
acompanhamento do projeto.
• Uma medida consistente entre vários projetos e
organizações. Ou seja, pessoas diferentes medindo o
mesmo projeto devem encontrar resultados similares.
Como a medição atua nos requisitos do software, que
dificilmente são documentados de maneira perfeita, há a
possibilidade de que existam interpretações distintas
sobre um mesmo requisito. Isso certamente afetará o
resultado da medição. Portanto, a qualidade dos
requisitos do software afeta diretamente a qualidade da
medição. Logo, a melhor alternativa para buscar
resultados consistentes nas medições é elevar a
qualidade dos requisitos produzidos.
• Outro fator que também pode prejudicar a obtenção de
medidas consistentes são os erros cometidos na medição.
Infelizmente há muitas pessoas que se engajam nas
medições de software sem a devida capacitação (estudo,
treinamento etc.). Portanto, a organização que pretende
usar a APF deve elaborar um plano de treinamento
adequado para capacitar as pessoas que serão
responsáveis pelas medições. O programa de certificação
CFPS do IFPUG (veja capítulo 11) é uma iniciativa para
garantir que os profissionais certificados responsáveis
 pela medição possuem o conhecimento necessário sobre
o processo de medição para sua correta aplicação.

Conceito de Usuário
É importante ressaltar que o termo usuário tem um significado mais
amplo para a análise de pontos de função do que o usual. O conceito não
está restrito apenas à pessoa física que usa o software. Usuário é qualquer
pessoa ou coisa que interaja (envia ou receba dados) com a aplicação .
Exemplos de usuário: pessoa física, outra aplicação, um hardware, um ator
em um caso de uso, agentes governamentais (exigências regulatórias do
governo normalmente abrangem boa parte dos requisitos de um software),
gestores do negócio que o software vai atender (na medida em que quem
especifica os requisitos do software, com ele também interage ).
Se a contagem de pontos de função fosse baseada apenas no conceito de
usuário como sendo uma pessoa, não seria possível medir sistemas que não
têm interface com o usuário final. No entanto, a APF pode ser usada para
medir qualquer tipo de software . Todo software existe para fornecer
serviços a alguém (seja uma pessoa ou uma coisa), portanto todo software
tem funções e usuários dessas funções.
Levando-se em consideração essa amplitude do conceito de usuário ,
durante uma contagem de pontos de função convém buscar no conjunto de
usuários possíveis aquele cuja visão melhor representa as funções que a
aplicação fornece. Por exemplo, a aplicação de autoatendimento de um
banco tem como usuários o cliente do banco, o funcionário da agência, o
gestor do departamento responsável. Basear a medição dessa aplicação
somente na visão do cliente final do banco e usuário do autoatendimento é
ter uma visão limitada da aplicação. É fundamental levar em consideração
também a visão do usuário que especifica os requisitos e regras de negócio,
neste caso, o gestor do departamento.

Benefícios
 É possível destacar vários benefícios da aplicação da análise de pontos
de função nas organizações:
• Uma ferramenta para determinar o tamanho de um
pacote adquirido pela contagem de todas as funções
incluídas .
• Provê auxílio aos usuários na determinação dos
benefícios de um pacote para sua organização, através da
contagem das funções que especificamente
correspondem aos seus requisitos . Ao avaliar o custo
do pacote, o tamanho das funções que serão
efetivamente utilizadas, a produtividade e o custo da
própria equipe, é possível realizar uma análise do tipo
make or buy .
• Suporta a análise de produtividade e qualidade , seja
diretamente ou em conjunto com outras métricas como
esforço, defeitos e custo. Indicadores de produtividade
(Horas/PF) e qualidade (Defeitos/PF) exercem um papel
fundamental em muitas iniciativas de melhoria de
processo de software.
• Apoia o gerenciamento de escopo de projetos. Um
desafio de todo gerente de projetos é controlar a variação
do escopo (ou scope creep ). Ao realizar estimativas e
medições dos pontos de função do projeto em cada fase
do seu ciclo de vida, é possível determinar se os
requisitos funcionais cresceram ou diminuíram, e se essa
variação corresponde a novos requisitos ou a requisitos
já existentes e que foram apenas mais detalhados.
 Portanto, a APF permite quantificar qualquer mudança
de escopo.
• Complementa o gerenciamento dos requisitos ao
auxiliar na verificação da solidez e completeza dos
requisitos especificados. O processo de contagem de
pontos de função favorece uma análise sistemática e
estruturada da especificação de requisitos e traz
benefícios semelhantes ao de uma revisão em pares. A
medição ajuda a expor falhas na documentação de
requisitos. Quando não se consegue medir algum aspecto
do projeto, em geral isso está relacionado às deficiências
nos requisitos.
• Um meio de estimar custo e recursos para o
desenvolvimento e manutenção de software. Por meio da
realização de uma contagem ou estimativa de pontos de
função no início do ciclo de vida de um projeto de
software, é possível determinar seu tamanho funcional.
Essa medida pode ser então utilizada como entrada para
diversos modelos de estimativa de esforço, prazo e custo.
O capítulo 9 é dedicado inteiramente a este assunto.
• Uma ferramenta para fundamentar a negociação de
contratos . É possível utilizar pontos de função para
gerar diversos acordos de níveis de serviço (SLA -
Service Level Agreement ) em contratos de
desenvolvimento e manutenção de sistemas. Além disso,
permite o estabelecimento de contratos a preço unitário -
pontos de função - em que a unidade representa um bem
tangível para o cliente. Essa modalidade possibilita uma
 melhor distribuição de riscos entre o cliente e o
fornecedor. O capítulo 10 discute essa abordagem em
detalhes.
• Um fator de normalização para comparação de
software ou para a comparação da produtividade na
utilização de diferentes técnicas. Diversas organizações,
como o ISBSG, disponibilizam um repositório de dados
de projetos de software que permitem a realização de
benchmarking com projetos similares do mercado.

Propósito da Contagem de Pontos de

Função

Figura 3.8: O propósito da contagem: norteia todas as demais

atividades.

Uma contagem de pontos de função não é um fim em si mesmo; ela é

feita para ajudar a solucionar algum problema de negócio. Por exemplo:
contagem com o propósito de medir o serviço entregue por um fornecedor
para sua posterior remuneração. Ou ainda, contagem com o propósito de
fornecer elementos para uma estimativa de custo de um projeto de software.
De acordo com essa motivação é possível assumir algumas premissas que
podem agilizar o processo. Logo, é possível efetuar contagens com níveis
diferenciados de detalhe e também de precisão. Sendo mais objetivo, o
propósito da contagem de pontos de função é fornecer uma resposta a um
problema de negócio. O propósito:
• Determina algumas premissas para o processo de
contagem.
• Determina o tipo de contagem como projeto de
desenvolvimento, projeto de melhoria aplicação.
• Estabelece o escopo da contagem, ou seja, se ela
abrangerá uma ou mais aplicações ou então apenas parte
de uma aplicação.
• Afeta o posicionamento da fronteira da aplicação
(fronteira é o conceito que define os limites da aplicação,
que será abordada mais à frente). Por exemplo, a
organização decide comparar um pacote de mercado com
um módulo de seu sistema corporativo. Nesse caso, o
módulo seria considerado uma aplicação em separado do
sistema corporativo, com uma fronteira própria.
• Define o nível de detalhe da contagem. Por exemplo, se
uma contagem está sujeita a uma auditoria posterior, é
necessário que cada etapa do processo esteja bem
documentada para facilitar a tarefa.
• Indica se o que melhor responde ao problema de negócio
é uma estimativa ou medição de tamanho funcional.

Reunir a Documentação Disponível

 O primeiro passo da medição consiste em buscar a documentação
disponível sobre o sistema e/ou projeto que será medido.
O propósito da contagem ajuda a definir que documentos são mais
interessantes para o trabalho de medição. Em essência, a documentação
ideal deve:
• descrever a funcionalidade entregue pelo software; ou
• descrever a funcionalidade que é impactada pelo projeto
de software medido.
Exemplos de documentos que podem ser usados na medição: modelos
de dados/objetos, diagramas de classe, diagramas de fluxo de dados, casos
de uso, descrições procedurais, layout de relatórios e telas, manuais de
usuário.
Geralmente não há um documento único que resolva todas as
necessidades de informação da medição; logo, o mais comum é que a
medição seja feita com base na análise de mais de um tipo de documento.
Se o analista de métricas tem à sua disposição um conjunto de
documentos já devidamente organizados do projeto e suficiente para o
trabalho de medição, esta etapa do processo acontece quase de forma
instantânea.

Figura 3.9: O processo de contagem: reunir a documentação

disponível.

Se não há documentação suficientemente disponível, é preciso buscar o

acesso aos especialistas no negócio para complementar essas lacunas. Isso
implica em planejar o agendamento de reuniões, entrevistas, pesquisa de
outros documentos; enfim vai envolver boa parte do trabalho inerente a um
analista de requisitos. Isso, é claro, implica esforço adicional na medição.

Determinação do Tipo de Contagem

Em Determinar o Tipo de Contagem os responsáveis pela medição
estabelecem o tipo de contagem que será utilizado para medir o software. A
contagem de pontos de função pode estar associada tanto a projetos quanto
a aplicações.

Figura 3.10: O processo de contagem: determinar o tipo de

contagem.

Os três tipos de contagem são os seguintes:

• Contagem de um projeto de desenvolvimento;

• Contagem de um projeto de melhoria;
• Contagem de uma aplicação.

Projeto de Desenvolvimento
O tamanho funcional de um projeto de desenvolvimento mede a
funcionalidade fornecida aos usuários finais do software quando da sua
primeira instalação, e abrange também as eventuais funções de conversão
de dados necessárias à implantação do sistema. Por exemplo, uma
organização empreende um projeto de desenvolvimento de um sistema A
que substituirá um sistema B em uso, e alguns dados desse sistema devem
ser importados para o novo sistema. A contagem desse projeto envolve
todas as funções do sistema A e também todas essas funções que
converterão os dados do sistema B no sistema A.
É importante destacar que qualquer medição realizada antes do término
de um projeto é na verdade uma estimativa das funcionalidades que serão
entregues ao seu final. Conforme os requisitos vão ficando mais claros
durante o projeto, é bastante natural identificar funcionalidades que não
haviam sido especificadas inicialmente e isso impactar no tamanho
originalmente medido.

Projeto de Melhoria
O número de pontos de função de um projeto de melhoria mede as
funções adicionadas, modificadas ou excluídas do sistema pelo projeto, e
também as eventuais funções de conversão de dados.
Quando o projeto de melhoria é concluído e seus produtos instalados, o
número de pontos de função da aplicação deve ser atualizado para refletir as
alterações na funcionalidade da aplicação.

Aplicação
O número de pontos de função de uma aplicação mede a funcionalidade
fornecida aos usuários por uma aplicação instalada. Também é chamado de
número de pontos de função instalados ou baseline . Esse número fornece
uma medida da atual funcionalidade obtida pelo usuário da aplicação. Ele é
inicializado ao final da contagem do número de pontos de função do projeto
de desenvolvimento, sendo atualizado no término de todo projeto de
melhoria que altera a funcionalidade da aplicação.
Na área da tecnologia da informação, o termo “aplicação” possui vários
significados. Na definição do IFPUG, “uma aplicação é um conjunto coeso
de dados e procedimentos automatizados que suportam um objetivo de
negócio, podendo consistir de um ou mais componentes, módulos ou
subsistemas. Frequentemente, o termo “aplicação” é utilizado como
sinônimo para sistema, sistema aplicativo ou sistema de informação”. A
aplicação deve ser definida segundo a visão do usuário e de acordo com
considerações de negócio e não com base em questões técnicas como
arquitetura do software ou plataforma tecnológica.

Figura 3.11: Relacionamento entre os tipos de contagem.

A Fronteira da Aplicação e o Escopo da

Contagem
Após a definição do tipo de contagem, o próximo passo do processo é a
identificação da fronteira da aplicação e o escopo da contagem.
 Figura 3.12: Identificar a fronteira da aplicação e o escopo da
contagem.

Fronteira da Aplicação
A fronteira da aplicação é a interface conceitual que delimita o software
que será medido e o mundo exterior (seus usuários). Embora muitas vezes o
conceito da fronteira esteja bem explícito para o sistema que está sendo
contado e não se gaste muito tempo com sua análise, esta etapa é uma das
mais importantes do processo de contagem, pois serve de premissa para os
passos seguintes. Se a definição da fronteira não estiver muito clara, há um
risco muito grande de que todo trabalho de contagem posterior seja
invalidado, pois várias funções serão indevidamente medidas ou deixadas
de fora da medição.
Fazendo uma analogia com o mundo real, a fronteira da aplicação seria
a cerca que delimita uma fazenda. Da mesma forma que seria difícil medir
corretamente a área da fazenda se não houvesse a cerca estabelecendo seus
limites, não é possível medir o tamanho funcional de um sistema sem que
antes tenha se estabelecido claramente a sua fronteira.
Quando há mais de uma aplicação incluída no escopo de uma contagem,
várias fronteiras devem ser identificadas. O IFPUG especifica as seguintes
regras para determinação da fronteira da aplicação:
1. Sua determinação deve ser feita com base no Ponto de
Vista do Usuário . O foco deve estar no que ele pode
entender e descrever.
2. A fronteira entre aplicações deve ser baseada na
separação das funções conforme estabelecido pelos
processos do negócio, não em considerações
tecnológicas.
3. Em projetos de melhoria, a fronteira estabelecida no
início do projeto deve estar de acordo com a fronteira já
estabelecida para a aplicação sendo modificada.
As seguintes dicas ajudam a identificar a fronteira da aplicação:
1. Obter uma documentação do fluxo de dados no sistema
e desenhar uma fronteira em volta para destacar quais
partes são internas e externas à aplicação.
2. Verificar como os grupos de dados são mantidos.
3. Identificar áreas funcionais pela atribuição de
propriedade de certos objetos de análise, como entidades
e processos.
4. Comparar os critérios utilizados em outras métricas,
como esforço, duração, custo e defeitos. As fronteiras
para efeito da análise de pontos de função e as outras
métricas devem ser as mesmas.
5. Verificar como a aplicação é gerenciada; se é
desenvolvida ou mantida na sua totalidade por uma
equipe distinta.
6. Verificar se o software possui Ordens de Serviço
específicas e independentes.
7. Olhe o organograma da empresa e observe qual a
relação entre as áreas e seus sistemas.
A identificação da fronteira da aplicação é um passo essencial para a
medição funcional. Pode ser difícil delinear onde uma aplicação termina e
outra começa. Procure sempre delinear a fronteira de uma perspectiva de
negócio, em vez de se basear em considerações técnicas. O posicionamento
incorreto da fronteira pode alterar a perspectiva da contagem de uma visão
lógica (princípio da APF) para uma visão física. As principais
consequências disso são as seguintes:
1. Contagem duplicada da mesma transação por várias
“aplicações”, uma vez que cada uma delas contribui com
um subprocessamento para a transação do negócio.
2. Contagem de funções de transferência de dados entre
plataformas/aplicações. Por exemplo, a carga diária de
uma tabela do servidor para uma aplicação cliente
poderia ser contada como uma transação de saída para o
servidor e uma transação de entrada para o cliente, além
de dois arquivos (a versão servidor e cliente da tabela).
No entanto, o requisito poderia ser simplesmente o de
validar as transações contra essa tabela.
3. Dificuldade na determinação do tipo de transação.
Como uma “aplicação” provê somente parte do
processamento de uma transação do negócio, esse
processamento pode não satisfazer as regras do IFPUG
para determinação do tipo da transação.
4. Duplicidade na contagem de arquivos. Por exemplo, um
mesmo arquivo poderia ser contado como um requisito
de armazenamento interno para uma “aplicação” e um
 requisito de armazenamento externo para outra
“aplicação”.
Dica Prática: Para evitar os problemas citados, uma das primeiras
iniciativas que uma organização interessada em usar a APF deve tomar,
antes de fazer qualquer medição, é mapear todas as suas aplicações (sob a
ótica da APF), identificando suas fronteiras. É muito comum encontrar
elementos que são denominados “sistema”, que não atendem aos princípios
da APF. Geralmente são pedaços de aplicações maiores, que foram tratadas
separadamente talvez por questões técnicas (diferentes plataformas,
linguagens etc.). A tabela seguinte ilustra como uma organização mapeou
suas aplicações, explicitando todos os seus componentes (técnicos ou
módulos), para que todas as medições usem sempre a mesma referência de
fronteira.
Tabela 3.2: Lista de aplicações de uma organização, mapeando os
componentes técnicos e módulos.

Aplicação Uso Módulos Gestor/Usuário

Autoatendimento
1. Autoatendimento Auto_atd_serv_cash GECEL
agência
2. Monitor Monitora rede de Concentrador, GECEL/GEN
autoatendimento autoatendimento processador, monitor UC
Extratos de conta- Host REE, Host EXT,
3. Extrato C/C GECOD
corrente Sun REE e EXT
Transações - interação
4. Autorizador SIP RAA39 GESIP
com SIP
Integrador de
5. Integrador SPB SUN RPB GECOD
transações SPB
Transferência tef24, tef10, tef95, rbk
6. TEF GECEL
eletrônica de fundos (host)
7. Estatísticas Estatísticas de GECEL/GEM
Host, RES
automação transações AK
8. Arrecadação Recebimentos com DBR, DAC, MTO -
GEARC
concessionárias códigos de barras Host, Sun
9. Arrecadação
DUA, DUA-DETRAN DUA, DET GEARC
estadual
10. Arrecadação
DARF, GPS DAF, DPS GEARC
federal
 Aplicação Uso Módulos Gestor/Usuário
Pagamento de
11. INSS MPB GEARC
benefícios INSS
DCO, DCG, DCI, DCF,
12. Conta-corrente Conta-corrente GECOD
DCR, DCX
13. Depósito a CDB, RDB, LH, LCI e
AFB GECOD
prazo DI
Sistema Integrado de
14. SIP SIP (DPI, DPE) GECOD
Pagamentos
GCM, GCC, GCI, GTB,
15. Cartão Sistema de Cartões GECAR
GCE

Quando a fronteira da aplicação é posicionada de forma incorreta, além

dos problemas destacados anteriormente, às vezes é possível perceber que a
própria medição fica “estranha”. Por exemplo, uma aplicação com
quantidade grande de ALIs ou AIEs compartilhados com uma mesma
aplicação, muitas vezes é indício de alto grau de acoplamento entre essas
aplicações, uma pista forte de que pode se tratar na prática de uma única
fronteira para ambas.

Escopo da Contagem
O escopo define quais funções serão incluídas na contagem, se ela
abrangerá um ou mais sistemas ou apenas parte de um sistema. Por
exemplo, o escopo da contagem de uma aplicação pode abranger:

• Todas as funcionalidades disponíveis;

• Apenas as funcionalidades efetivamente utilizadas pelo
usuário;
• Apenas algumas funcionalidades específicas (relatórios,
transações cadastrais etc.).
O conceito do escopo é mais exercitado durante a contagem de um
projeto de melhoria, que geralmente é onde muitos erram, incluindo funções
da aplicação na contagem sem que elas tenham sido afetadas pela melhoria.
O capítulo 7 aborda este assunto melhor e o capítulo 8 contém um estudo de
caso de projeto de melhoria.

Funções do Tipo Dado

O capítulo 4 detalha o processo de identificação e classificação das
funções do tipo dado com diversas regras e exemplos. No entanto, para
continuar a visão geral do processo de contagem, são apresentadas em
seguida algumas definições.

Figura 3.13: O processo de contagem: contar as funções do tipo

dado.

As funções do tipo dado representam as funcionalidades fornecidas pelo

sistema ao usuário para atender a suas necessidades de armazenamento de
dados. São classificadas em:

• Arquivo Lógico Interno (ALI): um grupo logicamente

relacionado de dados, reconhecido pelo usuário, mantido
dentro da fronteira da aplicação sendo contada. Sua
principal intenção é armazenar dados mantidos através
de uma ou mais transações da aplicação sendo contada.
Exemplo: dados de apontamento de entrada e saída do
trabalhador, do sistema de controle de ponto apresentado
no final deste capítulo. Em geral encontramos os ALIs
 implementados fisicamente como tabelas de banco de
dados atualizadas pela aplicação. Porém, não há regra
que estabeleça o mapeamento de tabelas do banco de
dados para arquivos lógicos.
• Arquivo de Interface Externa (AIE): um grupo
logicamente relacionado de dados, reconhecido pelo
usuário, mantidos fora da fronteira da aplicação sendo
contada. Sua principal intenção é armazenar dados
referenciados através de uma ou mais transações da
aplicação sendo contada. Exemplo: dados de pessoa no
sistema de controle de ponto apresentado no final deste
capítulo.

Funções do Tipo Transação

O capítulo 5 detalha o processo de identificação e classificação das
funções do tipo transação com diversas regras e exemplos. No entanto, para
continuar a abordagem do processo de contagem, são apresentadas em
seguida algumas definições.
 Figura 3.14: O processo de contagem: contar as funções do tipo
transação.

As funções do tipo transação representam os requisitos de

processamento fornecidos pelo sistema ao usuário. São classificadas em:

• Entrada Externa (EE): é uma transação que processa

dados ou informações de controle originados de fora da
fronteira da aplicação. Sua principal intenção é manter
um ou mais arquivos lógicos internos e/ou alterar o
comportamento do sistema. Exemplo: incluir cliente,
alterar cliente, excluir cliente.
• Saída Externa (SE): é uma transação que envia dados
ou informações de controle para fora da fronteira da
aplicação. Sua principal intenção é apresentar
informação ao usuário através de lógica de
processamento que não seja apenas uma simples
recuperação de dados ou informações de controle. Seu
processamento deve conter cálculo, ou criar dados
derivados, ou manter um arquivo lógico interno, ou
alterar o comportamento do sistema. Exemplo: relatório
de totais de faturamento por cliente.
• Consulta Externa (CE): é uma transação que envia
dados ou informações de controle para fora da fronteira
da aplicação. Sua principal intenção é apresentar
informações ao usuário pela simples recuperação de
dados ou informações de controle de ALIs e/ou AIEs.
Exemplo: consulta ao cadastro de clientes.
Cálculo do Tamanho Funcional
 Cada função do tipo dado e transação possui um peso em PF, que é
determinado pela complexidade da função que pode ser baixa, média ou
alta. A complexidade das funções do tipo dado é determinada por dois
parâmetros: quantidade de tipos de dados (campos) e quantidade de tipos de
registro (subgrupos de dados dentro do arquivo). As funções do tipo
transação têm sua complexidade determinada por outros dois parâmetros,
sendo quantidade de tipos de dados e quantidade de arquivos referenciados.
Os capítulos 4 e 5 apresentam as regras para a determinação da
complexidade das funções. Após a identificação e classificação de todas
essas funções na contagem, o número de pontos de função será
simplesmente a soma do peso de cada uma dessas funções.

Figura 3.15: O processo de medição: calcular o tamanho funcional.

Cada tipo de contagem (projeto de desenvolvimento, projeto de

melhoria e aplicação) possui uma fórmula específica para a determinação
dos pontos de função. O capítulo 7 apresenta cada uma das fórmulas, que
são bem simples.
Os pontos de função medem os requisitos específicos do usuário. O
termo “específico” é no sentido de que é possível apontar um requisito (um
relatório, um gráfico, uma transação de entrada de dados etc.) e dizer o seu
valor em PF. É um contraponto ao fator de ajuste (veja a seção seguinte)
que mede requisitos gerais da aplicação.

Fator de Ajuste
 Para adequar-se ao modelo de referência 14143 da ISO/IEC de medição
do tamanho funcional, o IFPUG tornou o fator de ajuste opcional na
aplicação da técnica da análise de pontos de função. Mesmo antes disso,
vários usuários da APF já não usavam o fator de ajuste. O propósito do
fator de ajuste é medir requisitos gerais da aplicação (não funcionais). Ele
ajusta os pontos de função em ± 35% de acordo com a influência de 14
características gerais. O capítulo 6 aborda o fator de ajuste em detalhes,
discutindo as razões pelas quais este passo do processo tem sido ignorado
por muitos usuários da APF.

Documentar e Reportar
A etapa final da medição consiste em documentar e reportar o resultado
da medição.
O nível de documentação da medição pode variar bastante (implicando
também em mais ou menos esforço na medição). Esse nível de
detalhamento da documentação deve estar alinhado ao propósito da
contagem. Por exemplo, se o propósito for estimar uma ordem de grandeza
de custo para o projeto, qual o sentido de detalhar ao máximo a medição?
Uma vez que a própria medição não necessita de grande precisão para este
caso, o nível de documentação também não deveria ser tão minucioso.
O nível de documentação deve estar previamente acordado entre as
partes interessadas na medição, ponderando-se os custos e benefícios
envolvidos. Um nível de documentação alto na medição implica mais
tempo e custo para essa atividade, porém uma medição bem documentada
facilita:
• Realizar a auditoria da medição;
• Rastrear as funções identificadas até os artefatos do
projeto usados na medição;
• Usar os resultados da medição;
• Manter e evoluir a medição.
 Cada organização pode estabelecer os seus padrões de documentação da
medição. A seguir destacamos alguns itens relevantes para documentação.
O capítulo 7 discute esta etapa com mais detalhes.
• As datas de medição e revisão;
• Todas as suposições feitas e questões resolvidas;
• Identificação da documentação de origem na qual a
medição foi baseada;
• Identificação dos participantes, seus papéis e
qualificações;
• Breve descritivo de cada função;
• Referência cruzada de todas as funções de dados para as
funções de transação;
• Referência cruzada de todas as funções para a
documentação de origem.

Figura 3.16: O processo de medição: documentar e reportar o

resultado da medição.

Estudo de Caso - Sistema de Controle

de Ponto
 Após a apresentação do processo de contagem, vamos mostrar um
exemplo prático de sua aplicação. Com este intuito será utilizado um
pequeno sistema que tem por objetivo registrar a entrada e a saída de
funcionários de uma determinada organização. Deve ser observado que o
exemplo é uma simplificação da realidade, portanto não cabe entrar no
mérito da análise do sistema ou do negócio.
Embora as regras de contagem das funções de dados e transações sejam
apresentadas apenas nos capítulos seguintes, o exemplo serve para ilustrar
como funciona de forma geral o processo de medição. As dúvidas que
eventualmente surgirem serão solucionadas também nos capítulos
seguintes.
A documentação é composta de:

• Descrição do sistema;
• Lista de atores;
• Lista de casos de uso;
• Especificação dos casos de uso;
• Diagrama de classes;
• Diagrama de entidades e relacionamentos;
• Identificação e classificação das funcionalidades;
• Sumário da contagem dos pontos de função.

Descrição do Sistema
Em um Sistema de Controle de Horário, um trabalhador registra suas
entradas e saídas do ambiente de trabalho. Nos casos em que se esquece de
fazê-lo, ele justifica tal ocorrência. Além disso, ele pode acompanhar a sua
presença com os totais de horas trabalhadas em um determinado período.
Cada trabalhador pode ter acesso apenas às suas informações. Por outro
lado, o gerente pode emitir um relatório com as informações de presença de
todos os funcionários.
Lista de Atores
• Trabalhador
• Gerente

Casos de Uso Identificados

1. Registrar presença (caso de uso base)
2. Registrar justificativa (caso de uso de extensão)
3. Acompanhar presença (caso de uso base)
4. Emitir relatório de presenças (caso de uso base)
5. Efetuar login (caso de uso base)

Figura 3.17: Diagrama de caso de uso do sistema de controle de

ponto.

Especificação do Caso de Uso 1 -

Registrar Presença
Ator Relacionado
Trabalhador.
Objetivo
Este caso de uso permite ao trabalhador inserir, excluir ou alterar as
informações de entrada ou saída em uma determinada data.
Sempre que o trabalhador chega ou sai do ambiente de trabalho ele deve
registrar a sua entrada e saída. Nas ocasiões em que ele se esquecer de fazer
o registro, ele pode fazer posteriormente, registrando nesses casos também
uma justificativa.
Precondição
O trabalhador deve ter efetuado login no sistema.
Fluxo de Eventos Principal
• Passo 1: o trabalhador escolhe a opção “Registrar
Presença” na tela principal do sistema e a tela de registro
de presença é apresentada.
• Passo 2: o trabalhador escolhe uma das opções na tela:
“Data Atual”, “Data Passada” ou “Cancelar”. Ao
escolher “Data Passada”, o trabalhador deve informar
uma data válida.
• Passo 3: o sistema recupera todos os registros de entrada
e saída que já foram feitos na data escolhida e os
apresenta numa lista na tela juntamente com a data
informada (E1). Caso nenhum registro exista na data, o
sistema apenas passa para o próximo passo.
• Passo 4: o trabalhador escolhe uma das opções na tela:
“Entrada”, “Saída” ou “Cancelar”.
• Passo 5: se o trabalhador escolher “Cancelar”, o caso de
uso é encerrado e volta à tela principal, senão segue para
o próximo passo.
• Passo 6: o trabalhador escolhe uma das opções na tela:
“Incluir”, “Excluir”, “Alterar” ou “Cancelar”.
a) Incluir (para data atual): caso o trabalhador tenha
escolhido a data atual, o sistema verifica se é possível
inserir (E3) a entrada/saída desejada e, caso seja
possível, ele insere automaticamente um registro de
entrada/saída para o trabalhador, com a data e horário
atuais (do sistema). Em seguida o sistema emite uma
mensagem de inclusão efetuada com sucesso (E2).
b) Incluir (para data passada): caso o trabalhador tenha
escolhido uma data passada, ele informa também o
horário e uma justificativa ( extend : Registrar
justificativa) (E6). O sistema verifica se é possível
inserir (E3) a entrada/saída desejada e, caso seja
possível, ele insere o registro de entrada/saída para o
trabalhador, com a data e horário desejados e a
justificativa. Em seguida o sistema emite uma
mensagem de inclusão efetuada com sucesso (E2).
c) Excluir: nesse caso o sistema exclui todos os registros
de apontamento e justificativa da data informada. Antes
verifica se é possível excluir (E4) os registros desejados
e, caso seja possível, solicita a confirmação de
exclusão. Se o trabalhador não confirmar a exclusão, o
sistema volta ao passo 7; senão, ele exclui os registros e
emite uma mensagem de exclusão efetuada com
sucesso (E2).
d) Alterar: nesse caso o trabalhador informa um horário
de entrada ou saída existente e em seguida informa o
 novo horário desejado e uma justificativa ( extend :
Registrar justificativa) (E6). O sistema verifica se é
possível alterar (E5) o horário atual para o horário
desejado e, caso seja possível, ele solicita uma
confirmação de alteração. Se o trabalhador não
confirmar a alteração, o sistema volta ao passo 7; senão,
ele grava o novo horário e a justificativa, e emite uma
mensagem de alteração efetuada com sucesso (E2).
e) Cancelar: nessa opção o caso de uso é encerrado e o
sistema volta à tela principal.
• Passo 7: o sistema questiona se o trabalhador deseja
registrar nova presença ou encerrar. Se o trabalhador
escolher “Registrar Nova Presença”, o sistema volta ao
passo 3; senão, o caso de uso é encerrado e o sistema
retorna à tela principal.
Fluxos de Exceção
• E1: caso não seja possível recuperar os registros, o
sistema emite uma mensagem de erro explicando o
problema e retorna ao passo 3.
• E2: caso a operação em questão não seja bem-sucedida,
o sistema emite uma mensagem de erro explicando o
problema e retorna ao passo 7.
• E3: o sistema não deve permitir inserir uma entrada sem
que exista uma saída anterior (a menos que seja este o
primeiro registro de entrada no sistema para o
trabalhador em questão); da mesma forma o sistema não
deve permitir inserir uma saída sem que exista uma
 entrada anterior. Caso isso ocorra, o sistema deve emitir
uma mensagem de alerta explicando o problema e
retornar ao passo 7.
• E4: o sistema não deve permitir excluir uma entrada que
possua uma saída cadastrada em sequência, sem que essa
saída também seja excluída (nesse caso o trabalhador
deve escolher excluir também a saída em sequência). Da
mesma forma o sistema não deve permitir excluir uma
saída que possua uma entrada cadastrada em sequência,
sem que essa entrada também seja excluída (nesse caso o
trabalhador deve escolher excluir também a entrada em
sequência). Caso isso ocorra, o sistema deve emitir uma
mensagem de alerta explicando o problema e retornar ao
passo 7.
• E5: o sistema não deve permitir que uma entrada seja
registrada entre uma entrada e saída já registradas
anteriormente. Da mesma forma, o sistema não deve
permitir que uma saída seja registrada entre uma entrada
e saída já registradas anteriormente. Caso isso ocorra, o
sistema deve emitir uma mensagem de alerta explicando
o problema e retornar ao passo 7.
• E6: caso uma justificativa não tenha sido escolhida, o
sistema deve emitir uma mensagem de alerta explicando
o problema e retornar ao passo 7.

Especificação do Caso de Uso 2 -

Registrar Justificativa
Ator Relacionado
Trabalhador (através do caso de uso Registrar Presença).
Objetivo
Este caso de uso permite ao trabalhador inserir uma justificativa para
um horário de entrada e saída e é iniciado a partir dos pontos de extensão no
caso de uso Registrar Presença.
Fluxo de Eventos Principal
• Passo 1: o sistema abre uma tela para que o trabalhador
possa digitar livremente um texto para a justificativa.
• Passo 2: após fechar a janela o sistema volta ao passo de
onde esse caso de uso foi chamado.

Especificação do Caso de Uso 3 -

Acompanhar Presença
Ator Relacionado
Trabalhador.
Objetivo
Este caso de uso permite ao trabalhador acompanhar seus registros de
presença em um determinado período escolhido.
Precondição
O trabalhador deve ter efetuado login no sistema.
Fluxo de Eventos Principal
• Passo 1: o trabalhador escolhe a opção “Acompanhar
Presença” na tela principal do sistema e a tela de
acompanhamento de presença é apresentada.
• Passo 2: o trabalhador escolhe uma data inicial e uma
data final para o período que deseja consultar.
• Passo 3: o sistema recupera todos os dados de
 apontamento e de justificativas que foram feitos entre as
datas escolhidas, junto com o total de horas do período e
o nome do trabalhador, e os apresenta na tela (E1). Caso
nenhum registro exista entre as datas, o sistema emite
uma mensagem ao trabalhador informando este fato.
• Passo 4: o trabalhador escolhe uma das opções na tela:
“Acompanhar Novo Período” ou “Cancelar”.
• Passo 5: se o trabalhador escolher “Cancelar”, o caso de
uso é encerrado e volta à tela principal; senão, vai para o
passo 3.
Fluxos de Exceção
• E1: caso não seja possível recuperar os registros, o
sistema emite uma mensagem de erro explicando o
problema e retorna ao passo 3.

Especificação do Caso de Uso 4 - Emitir

Relatório de Presença
Ator Relacionado
Gerente.
Objetivo
Este caso de uso permite ao gerente acompanhar o registro de presença
dos trabalhadores em um determinado período escolhido.
Precondição
O gerente deve ter efetuado login no sistema.
Fluxo de Eventos Principal
• Passo 1: o gerente escolhe a opção “Emitir Relatório de
Presença” na tela principal do sistema e a tela de emissão
 do relatório de presença é apresentada.
• Passo 2: o gerente escolhe uma data inicial e uma data
final para o período que deseja consultar.
• Passo 3: o sistema recupera os dados de apontamento e
justificativa que foram feitos entre as datas escolhidas
para todos os trabalhadores e os apresenta na tela (E1) da
seguinte forma: matrícula, nome, total de horas e número
de justificativas. Ao final do relatório é exibido o total de
horas para todos os trabalhadores. Caso nenhum registro
exista entre as datas, o sistema emite uma mensagem ao
gerente informando este fato.
• Passo 4: o gerente escolhe uma das opções na tela:
“Imprimir Relatório”, “Acompanhar Novo Período” ou
“Cancelar”.
• Passo 5: se o gerente escolher “Cancelar”, o caso de uso
é encerrado e volta à tela principal; se ele escolher
“Imprimir Relatório”, o relatório é impresso (E2); senão,
vai para o passo 3.
Fluxos de Exceção
• E1: caso não seja possível recuperar os registros, o
sistema emite uma mensagem de erro explicando o
problema e retorna ao passo 3.
• E2: caso não seja possível imprimir o relatório, o
sistema emite uma mensagem de erro explicando o
problema e retorna ao passo 3.
Especificação do Caso de Uso 5 -
Efetuar Login
Ator Relacionado
Trabalhador e Gerente, ambos chamados de usuário para facilitar a
especificação deste caso de uso.
Objetivo
Este caso de uso permite ao usuário efetuar o seu login no sistema e, a
partir daí, escolher as opções disponíveis para ele: Registrar Presença,
Acompanhar Presença ou Emitir Relatório de Presença, dependendo do tipo
de usuário.
Fluxo de Eventos Principal
• Passo 1: o sistema apresenta a tela de login ao usuário.
• Passo 2: o usuário informa sua matrícula e senha.
• Passo 3: o sistema verifica se esse usuário está
cadastrado (E1).
• Passo 4: o sistema verifica se a senha para esse usuário
está correta (E2).
• Passo 5: o sistema apresenta a tela principal do sistema
com as opções habilitadas para cada tipo de usuário que
efetuar login .
a) Se o usuário é do tipo trabalhador, o sistema habilita
as opções “Registrar Presença”, “Acompanhar
Presença” e “Cancelar”.
b) Se o usuário é do tipo gerente, o sistema habilita as
opções “Emitir Relatório de Presenças” e “Cancelar”.
• Passo 6: se o usuário escolher “Cancelar”, o sistema
volta ao passo 1; senão, o sistema vai para o caso de uso
 correspondente à escolha do usuário.
Fluxos de Exceção
• E1: se o usuário não estiver cadastrado, o sistema emite
uma mensagem de erro explicando o problema e volta ao
passo 1.
• E2: se a senha não estiver correta, o sistema emite uma
mensagem de erro explicando o problema e retorna ao
passo 1.

Diagrama de Classes
O diagrama de classes seguinte, Figura 3.18, apresenta uma modelagem
do caso de uso descrito anteriormente. Observe que a classe Pessoa faz
parte de outra aplicação (controle de segurança) e a aplicação de controle de
ponto apenas faz referência a ela.

Figura 3.18: Diagrama de classes do sistema de controle de ponto.

Modelo de Entidades e Relacionamentos

 O modelo físico de dados apresentado em seguida na Figura 3.19 é o
que será utilizado para a implementação do banco de dados do sistema.
Observe que a classe Justificativa do modelo de classes foi mapeada para
duas tabelas: Justificativa e Linhas. Essa decisão de projeto foi motivada
pelo fato de o sistema gerenciador de banco de dados utilizado não suportar
campos do tipo memo (texto de tamanho indefinido) e ser um requisito de o
usuário poder escrever uma justificativa de tamanho arbitrário.

Figura 3.19: Modelo de entidades e relacionamentos do sistema de

controle de ponto.

Detalhamento dos Campos e Arquivos

Referenciados
Login:
• Matrícula, Senha, Mensagens, Comando
• Pessoa
Registro de Ponto:
• Indicador de entrada ou saída, Mensagens, Comando
• Apontamento
Consulta Apontamento Diário:

• Data do Ponto, Horário de Entrada, Horário de Saída,

Mensagens, Comando
• Apontamento
Apontamento com Justificativa:
• Indicador de entrada ou saída, Data, Horário,
Justificativa, Mensagens, Comando
• Apontamento, Justificativa
Exclusão de Apontamento:

• Mensagens, Comando
• Apontamento, Justificativa
Alteração de Apontamento:

• Horário Anterior, Horário Novo, Justificativa,

Mensagens, Comando
• Apontamento, Justificativa
Acompanhar Presença:
• Data Inicial, Data Final, Total de Horas do Período,
Nome do Trabalhador, Data do Ponto, Horário do Ponto,
Indicador de Entrada ou Saída, Justificativa, Mensagens,
Comando
• Apontamento, Justificativa, Pessoa
Emitir Relatório de Presença:

• Data Inicial, Data Final, Matrícula, Nome, Total de

Horas do Trabalhador, Número de Justificativas, Total de
Horas Geral, Mensagens, Comando
• Apontamento, Justificativa, Pessoa

Identificação e Classificação das

Funcionalidades
A partir dos requisitos apresentados é possível realizar uma contagem de
pontos de função do sistema de controle de ponto.
Tabela 3.3: Planilha de contagem de pontos de função do sistema
de controle de ponto.

Tip T P
Nome da função AR/TR Complexidade Origem
o D F
A Caso de
Pessoa (do controle de segurança) 4 1 BAIXA 5
IE Uso 5
A Caso de
Apontamento 4 1 BAIXA 7
LI Uso 1
A Caso de
Justificativa 3 1 BAIXA 7
LI Uso 2
S Caso de
Login 4 1 BAIXA 4
E Uso 5
E Caso de
Registro de ponto 3 1 BAIXA 3
E Uso 1
C Caso de
Consulta apontamento diário 5 1 BAIXA 3
E Uso 1
E Caso de
Apontamento com justificativa 6 2 MÉDIA 4
E Uso 2
E Caso de
Exclusão de apontamento 2 2 BAIXA 3
E Uso 1
E Caso de
Alteração de apontamento 5 2 MÉDIA 4
E Uso 1
S 1 Caso de
Acompanhar presença 3 MÉDIA 5
E 0 Uso 3
S Caso de
Emitir relatório de presença 9 3 MÉDIA 5
E Uso 4
5
Total de Pontos de Função
0
 Legenda
(Tipo) - Classificação da funcionalidade (ALI, AIE, EE, SE ou CE)
(TD) - Quantidade de Tipos de Dado
(AR) - Quantidade de Arquivos Referenciados
(TR) - Quantidade de Tipos de Registro

Questões para Fixação

1. Quais são os objetivos da análise de pontos de função?

2. Cite dois benefícios da análise de pontos de função.
3. Uma aplicação desenvolvida em C++ utilizando análise
e projeto estruturado foi dimensionada em 1232 PF.
Quantos pontos de função terá a mesma aplicação
desenvolvida em VB 6.0 com banco de dados Oracle e
utilizando a metodologia RUP? Por quê?
4. Para efeito da contagem de pontos de função, defina
visão do usuário.
5. Dê dois exemplos de documentos em sua organização
que representem a visão do usuário.
6. Qual a diferença entre estimativa e medição? A partir de
que momento é possível fazer uma medição?
7. Qual a importância dos requisitos para a APF? Qual o
papel do desenvolvedor na definição dos requisitos?
8. Quais são os três tipos de contagem em que a análise de
pontos de função pode ser aplicada? Quais são as
diferenças entre eles?
9. Defina escopo da contagem e fronteira da aplicação.
10. Conceitue e exemplifique os três tipos de manutenção
de software definidos pelo IFPUG. Para quais deles é
 possível aplicar a APF?
11. Um sistema pode ser considerado usuário de outro
sistema? Por quê?
12. Em sua opinião, a produtividade (pf/homem-mês) de
projetos de melhoria é maior ou menor que a de
desenvolvimento? Por quê?
13. Conceitue e exemplifique os dois tipos de requisitos de
software (funcional e não funcional). Quais deles a APF
se propõe a medir?
14. Qual o papel da fronteira da aplicação na identificação
das funcionalidades do sistema?
15. A fronteira da aplicação de um software foi definida e
durante algum tempo foi utilizada em várias contagens.
O que justificaria mudar essa perspectiva?

Bibliografia

1. DEKKERS, C. Demystifying Function Points: Let’s

Understand Some Terminology. IT Metrics Strategies,
1998.
2. ______. Function Points and Measurement: What’s a
Function Point? QAI Journal , dez. 1998.
3. DEKKERS, C.; AGUIAR, M. Using Function Point
Analysis to Check the Completeness (Fullness) of
Functional User Requirements. Cutter IT Journal , abr.
2000.
4. GARMUS, D.; HERRON, D. Function Point
Analysis: Measurement Practices for Sucessful Software
Projects. Addison-Wesley, 2000.
5. GRADY, R. Practical Software Metrics for Project
Management and Process Improvement. Prentice
Hall, 1992.
6. IFPUG. Function Point Counting Practices Manual:
Release 4.3. International Function Point Users Group,
2010.
7. KRUCHTEN, P. The Rational Unified Process.
Addison-Wesley, 1999.
8. LONGSTREET, D. Using Function Points .
Disponível em:
<http://www.SoftwareMetrics.com/Articles/using.htm>.
Acesso em: 19 fev. 2013.
9. ______. Function Point Training and Analysis
Manual . Disponível em:
<http://www.SoftwareMetrics.com/freemanual.htm>.
Acesso em: 19 fev. 2013.
10. THE STANDISH GROUP. CHAOS Report. 1994,
2001.
11. TOTAL METRICS. FPA Counting FAQs:
Positioning of Application Boundaries Total Metrics.
Disponível em: <http://www.TotalMetrics.com>. Acesso
em: 19 fev. 2013.
 4

Funções do Tipo Dado

Introdução
Este capítulo explica o processo e as regras de medição das funções do
tipo dado. Elas representam a funcionalidade fornecida pela aplicação ao
usuário para atender à sua necessidade de dados internos e externos à
aplicação, ou seja, representam os seus requisitos de armazenamento de
dados. São classificadas em Arquivos Lógicos Internos (ALI) e Arquivos de
Interface Externa (AIE). Em resumo, um ALI representa dados centrais de
negócio ou suas referências, mantidos pela aplicação analisada, e um AIE
representa dados referenciados pela aplicação analisada, classificados como
ALI por alguma outra aplicação.

Figura 4.1: Processo de contagem de ALI e AIE.

 O termo Arquivo não significa um arquivo do sistema operacional, tabela
de banco de dados ou entidade no modelo de dados; refere-se a um grupo de
dados logicamente relacionados e reconhecido pelo usuário. Eventualmente
um arquivo no sentido da APF pode estar mapeado em um ou mais desses
itens. Ao identificar um grupo de dados como um ALI, o foco deve estar em
como o negócio manipula e armazena esse grupo em um plano conceitual
(observando a lógica do negócio) e não na forma como a aplicação o
implementa; isso não é relevante na APF.
No exemplo da Figura 4.2, o usuário tem o requisito de armazenar
compromissos financeiros. Esse conceito envolve também informações de
seu parcelamento e de seu rateio entre as áreas de negócio, porém a sua
implementação é feita por meio de três tabelas. Sob a ótica do negócio, não
faz sentido (não é lógico) que um compromisso esteja subdividido em vários
diferentes arquivos. Logo, há um único ALI.
Uma dica para entender melhor a visão de negócio para a medição pode
ser imaginar a operação do negócio sem o uso de softwares, apenas com
processos manuais e papel. Neste caso, fica mais fácil abstrair da
implementação do sistema e visualizar corretamente o requisito funcional.

Figura 4.2: ALI Compromisso, implementado em três tabelas.

O que seriam o ALI e o AIE neste contexto? Seriam “armários” (ou

arquivos) nos quais o usuário guarda os seus documentos. Cada tipo de
documento possui um armário específico. As fichas de cliente são guardadas
em um armário próprio e distinto das fichas de pedido. Quando isso é
informatizado, os armários viram diferentes tabelas num banco de dados,
porém para a APF o que interessa são os armários do usuário e não as tabelas
do banco de dados.
Embora o capítulo descreva todas as definições, regras, exemplos e não
exemplos de arquivos lógicos, uma dica simples para identificá-los é olhar
(ou esboçar um, caso não exista) o modelo conceitual de dados. Neste caso,
cada entidade do modelo conceitual corresponderia a um ALI ou AIE .
O diagrama da Figura 4.3 resume as duas atividades principais na
medição dos Arquivos Lógicos Internos e dos Arquivos de Interface Externa.
Os conceitos para o entendimento do processo são apresentados neste
capítulo.

Figura 4.3: Identificação e Classificação - as principais atividades na

medição de ALI e AIE.
O que é Arquivo Lógico Interno (ALI)?
Um Arquivo Lógico Interno (ALI) é:
1. Um grupo de dados ou informações de controle;
2. Identificável pelo usuário;
3. Logicamente relacionado;
4. Mantido na fronteira da aplicação.
A principal intenção de um ALI é armazenar dados mantidos
(adicionados, modificados ou excluídos) por meio de uma ou mais
transações da aplicação sendo contada.

O que é um Arquivo de Interface Externa

(AIE)?
Um Arquivo de Interface Externa (AIE) é:
1. Um grupo de dados ou informações de controle;
2. Identificável pelo usuário;
3. Logicamente relacionado;
4. Referenciado (lido) pela aplicação.
A principal intenção de um AIE é armazenar dados referenciados por
meio de uma ou mais transações dentro da fronteira da aplicação sendo
contada. Isto é, o AIE deve obrigatoriamente ser um ALI de outra aplicação.

Diferença entre ALI e AIE

A diferença básica entre um Arquivo Lógico Interno e um Arquivo de
Interface Externa é que um Arquivo de Interface Externa não é mantido pela
aplicação sendo contada.
O Arquivo de Interface Externa está conceitualmente fora da fronteira da
aplica- ção, enquanto o Arquivo Lógico Interno está dentro da fronteira.
Exemplos de Arquivos Lógicos
• Tabelas que armazenam dados mantidos pela aplicação
(ALIs) ou referenciados por ela e mantidos por outra
aplicação (AIEs);
• Arquivos de parâmetros de negócio mantidos pela
aplicação (ALIs);
• Arquivos mantidos não só pela aplicação, mas também
por outra aplicação (ALIs).

Não Exemplos de Arquivos Lógicos

• Arquivos de movimento recebidos de outra aplicação para
manter um ALI (exemplos: arquivos de remessa e de
retorno), no entanto os processos de carga e de geração
desses arquivos podem ser funções do tipo transação. O
arquivo de movimento é simplesmente um relatório
gerado em formato de arquivo do sistema operacional;
• Dados estáticos;
• Dados temporários (cujo tempo de vida é o
processamento de uma transação);
• Arquivos introduzidos exclusivamente em função da
tecnologia utilizada ou por decisão de projeto do
software.

Definição dos Termos Utilizados

 São apresentadas em seguida explicações dos termos utilizados nas
definições de ALI e AIE.
• Informações de controle são dados que influenciam uma
transação da aplicação sendo contada. Eles especificam o
que, quando ou como os dados devem ser processados.
Em resumo, são parâmetros. No caso das funções do tipo
dado, esses parâmetros são armazenados e mantidos em
conjunto com a aplicação. Exemplo: as telas de
configuração de preferências de usuário, na maioria dos
softwares, contêm várias informações de controle. Essas
informações ficam armazenadas em arquivos de
configuração e nesse caso podem ser classificados como
ALIs. No caso do Internet Explorer são exemplos de
informações de controle, como página inicial, quantidade
de dias que as páginas ficam no histórico, nível de
privacidade etc. Em termos práticos a distinção entre
dados e informação de controle é irrelevante para a
contagem. Talvez o IFPUG use essa abordagem apenas
para ressaltar que a informação de controle deve ter o
mesmo tratamento que um dado durante a contagem.
• Uma transação é a menor unidade de atividade
significativa para o usuário final. Ela deve ainda ser
completa em si mesmo e deixar a aplicação em estado
consistente. Esta definição será novamente apresentada no
capítulo 5 e é fundamental para a identificação das
funções do tipo transação. Exemplo 1: o agendamento de
um recebimento, indicando como será o parcelamento da
receita e o rateio desta entre as unidades organizacionais,
é a menor unidade de atividade do usuário de contas a
 receber. Exemplo 2: ao final do agendamento de um
recebimento, ele deixa o sistema em estado íntegro. O
agendamento da receita sem o devido registro do
parcelamento não é considerado um processo completo
para o usuário.

Quantos PFs valem um ALI e um AIE?

Para calcular os PFs dos ALIs e AIEs, primeiramente é preciso avaliar
sua complexidade funcional (que pode ser baixa, média ou alta), definida
com base em dois parâmetros:
• Número de Tipos de Dados (TD)
• Número de Tipos de Registros (TR)
Determinadas as quantidades de tipos de dados e de registros, a
classificação com relação à complexidade é fornecida pela seguinte tabela:
Tabela 4.1: Complexidade funcional dos ALI e AIE.

Tipos de dados
< 20 20 - 50 > 50
Tipos de registros 1 Baixa Baixa 1. Média
2- 5 Baixa 2. Média Alta
>5 3. Média Alta Alta

Assim, um ALI com 45 tipos de dados e um tipo de registro é de

complexidade baixa e outro AIE com 55 tipos de dados e um tipo de registro
é de complexidade média.

Definição de Tipo de Dado (TD)

Um tipo de dado é um campo único, reconhecido pelo usuário, não
repetido.
 Cabe destacar que a tabela de complexidade funcional dos arquivos
lógicos mostra que não há necessidade de que os tipos de dados sejam
identificados de maneira exata. Basta identificar em que faixa de quantidades
cada ALI ou AIE se enquadra.
Em termos práticos, pode-se considerar um tipo de dado como um campo
do arquivo, embora essa relação não seja perfeita, como ilustra o exemplo na
Figura 4.4.

Figura 4.4: Diferença entre tipo de dado e campo de um arquivo.

Regras de Contagem de Tipos de

Dados
Todas as regras de contagem apresentadas em seguida devem ser válidas
para que um determinado campo seja contado como um tipo de dado.
1. Conte um tipo de dado para cada campo único
reconhecido pelo usuário e não repetido, mantido ou
 recuperado de um ALI ou AIE por meio da execução de
uma transação. Exemplos:
• No agendamento de um recebimento, a data de
vencimento poderia estar armazenada em múltiplos
campos (dia, mês e ano), mas continuaria a ser contada
como um único tipo de dado.

Figura 4.5: Caso em que vários campos implementam apenas um

TD.

• Uma imagem anterior a uma atualização de um grupo de

dez campos mantidos para propósitos de auditoria é
contada como um tipo de dado da imagem anterior (todos
os dez campos).

Figura 4.6: O conteúdo salvo nos campos em Histórico conta como

um único TD.

• Campos calculados e armazenados em um ALI também

devem ser contados como tipos de dados.
• Campos do tipo timestamps , se reconhecidos pelo
usuário, devem ser contados como tipos de dados.
 Figura 4.7: O “Total de Clientes” calculado e armazenado em
Funcionário é contado como um TD.

Figura 4.8: Timestamp contado como um TD.

• Arquivo com várias ocorrências do mesmo campo: valor

janeiro, valor fevereiro, ... e valor dezembro; devem ser
contados dois tipos de dados: um para o mês em questão e
outro para o valor.

Figura 4.9: Doze campos repetidos mapeados como dois TDs

únicos.

2. Quando duas aplicações mantêm ou referenciam o

mesmo ALI/AIE, conte apenas os campos utilizados pela
aplicação em análise. Exemplos:
• Uma aplicação mantém ou referencia os seguintes campos
de um arquivo: CPF e nome. Outra aplicação mantém ou
 referencia os seguintes campos do mesmo arquivo: nome,
logradouro, cidade, estado e CEP. Para a primeira
aplicação devem ser contados dois tipos de dados
referentes ao arquivo e para a segunda aplicação devem
ser contados cinco tipos de dados para o mesmo arquivo.
• Para uma aplicação é necessário identificar cada parte do
endereço do clien- te, como logradouro, cidade, estado e
CEP. Para outra aplicação, o mesmo endereço é relevante
apenas no conjunto. A primeira aplicação deve contar
quatro tipos de dados para o endereço e a segunda
aplicação apenas um.

Figura 4.10: Visões diferentes entre aplicações.

3. Conte um tipo de dado para cada campo solicitado pelo

usuário para estabe- lecer um relacionamento com outro
arquivo lógico (ALI ou AIE). Exemplos:
• Na aplicação de Controle de Ponto do capítulo 3 as
informações de entrada e saída são mantidas no ALI
Apontamento. A identificação da pessoa é parte das
informações do Apontamento; ela serve para estabelecer
um relacionamento entre o ALI Apontamento e o AIE
Pessoa. Assim, são contados quatro tipos de dados no ALI
Apontamento, sendo identificação da pessoa (chave
estrangeira), data, horário de entrada e horário de saída.
• Caso a chave estrangeira seja composta por vários
campos, todos eles devem ser contados como tipos de
dados, Figura 4.11.
• Quando um único arquivo lógico é composto por mais de
uma tabela no banco de dados, a chave estrangeira usada
para estabelecer o relaciona- mento entre essas tabelas
não deve ser contada mais de uma vez como tipo de dado.
Por exemplo, o ALI Ordem de Serviço é representado
pelas tabelas OS e Item OS. Neste caso há uma repetição
da chave primária da tabela OS na tabela Item OS, como
chave estrangeira, para estabelecer o relacionamento entre
elas. As duas tabelas constituem um único ALI, portanto a
chave da OS deve ser contada como um tipo de dado uma
única vez, Figura 4.12.

Figura 4.11: Tipos de dados relacionando dois arquivos lógicos.

Figura 4.12: Campos relacionando duas tabelas compondo um

arquivo lógico.

Importante
 Na prática, a avaliação dessas considerações é mais relevante
quando a quantidade de tipos de dados está nos limites das
faixas da tabela de complexidade. Não é necessário ser
rigoroso na contagem dos tipos de dados se já se sabe de
antemão que esse número está longe dos limites de mudança
de complexidade. Além disso, uma eventual classificação
incorreta da complexidade da função afeta de forma bem
limitada o resultado final da medição. Um rigor maior deve ser
dedicado à correta identificação da quantidade de funções,
pois isso produz um impacto muito mais significativo para o
resultado final da medição.

Definição de Tipo de Registro (TR)

Um tipo de registro é um subgrupo de dados, reconhecido pelo usuário,
componente de um Arquivo Lógico Interno ou Arquivo de Interface Externa.
Ele pode ser opcional (quando o usuário tem a opção de não informar esses
dados na transação que cria ou adiciona dados ao arquivo) ou obrigatório
(quando o usuário requer que os dados sejam sempre utilizados pela
transação que cria ou adiciona dados ao arquivo).

Figura 4.13: Exemplos de tipos de registro.

Para quem tem facilidade com os conceitos de modelagem de dados, na

prática, os tipos de registro são as tabelas na terceira forma normal que
compõem o arquivo.
Regras de Contagem de Tipos de
Registro
As seguintes regras devem ser utilizadas para determinar o número de
tipos de registro de um Arquivo Lógico Interno ou Arquivo de Interface
Externa.

• Conte um TR para cada função de dados (isto é, por

padrão, cada função de dados tem um subgrupo de TD a
ser contado com um TR).
• Conte um TR adicional para cada um dos seguintes
subgrupos lógicos de TDs (compreendido na função de
dados) que contêm mais de um TD:
• Entidade associativa com atributos não chave;
• Subtipo (outro que não o primeiro subtipo); e
• Entidade atributiva em um relacionamento que não seja
mandatório.

Determinação da Contribuição
Após a determinação da complexidade dos arquivos, deve-se calcular sua
contribuição utilizando a seguinte tabela:
Tabela 4.2: Contribuição dos pontos de função das funções do tipo
dado.

Tipo de função Baixa Média Alta

Arquivo Lógico Interno 7 PF 10 PF 15 PF
Arquivo de Interface Externa 5 PF 7 PF 10 PF

Exemplos: um ALI de complexidade alta contribui com 15 pontos de

função e um AIE também de complexidade alta contribui com 10 pontos de
função.

Dados de Código
Os requisitos de armazenamento, funcionais e não funcionais, de uma
aplicação são classificados em dados de negócio, dados de referência e dados
de código. Aqueles enquadrados como dados de código, apesar de poderem
representar até metade das entidades em um modelo de dados em terceira
forma normal, não devem ser considerados arquivos lógicos. Eles são uma
implementação de requisitos técnicos e não devem influenciar o tamanho
funcional da aplicação. As operações que existem exclusivamente para a
manutenção de dados de código não devem ser consideradas funções, assim
como os dados de código não devem ser considerados durante a análise da
complexidade das transações (veja capítulo 5).
Em resumo, o IFPUG reconhece que o tamanho de um software possui
dois componentes, sendo técnico e funcional, e apenas o tamanho funcional
pode não ser capaz de responder a todos os problemas relacionados a
estimativas. Uma alternativa apontada é o uso do fator de ajuste. No capítulo
6 são discutidas as várias deficiências existentes nesta abordagem.
Os dados de código, também chamados metadados, em geral não são
especificados pelo próprio usuário, sendo identificados pelo desenvolvedor
em resposta a um ou mais requisitos técnicos. A codificação de atributos
descritivos em objetos de negócio, sua descrição, nome ou outros dados que
também o descrevam, como a data de início e término de sua vigência, são os
atributos típicos desses arquivos. Um arquivo armazenando a sigla e o nome
das unidades da federação se enquadra neste caso. Essa função de
substituição, descrição pelo código, é condição suficiente para que
determinado arquivo em análise seja considerado um metadado, contudo não
é uma condição necessária. Outros casos que devem ser considerados como
dados de código são os seguintes arquivos:
• Que sempre armazenam apenas uma ocorrência e cujo
conteúdo de seus atributos raramente mude. Exemplo: um
sistema projetado para atender a várias organizações deve
permitir que os dados de cada empresa usuária, como
 razão social, logomarca, endereço e outras informações
afins, sejam configurados. Essas informações são
utilizadas no cabeçalho de todos os relatórios. O arquivo
que contém esses dados é um exemplo de arquivo de uma
ocorrência e dados de código, não devendo ser
considerado na contagem de pontos de função. A exceção
a esta regra é quando esse arquivo com apenas um
registro armazernar informações de controle do negócio
(parâmetros). Exemplo: a aplicação de automação
bancária possui uma tabela de parâmetros globais com
uma única linha (um único registro). Nela estão
armazenados os seguintes parâmetros: valor limite diário
para saque em conta-corrente no autoatendimento, horário
limite para autodepósito e número de erros permitidos
para a senha. Como esses dados são parâmetros ligados
diretamente ao negócio que o sistema atende, esse arquivo
(mesmo com uma única ocorrência) será considerado um
arquivo lógico (ALI ou AIE).
• Em que tanto a quantidade de ocorrências quanto seu
respectivo conteúdo raramente mudam.
• Templates que armazenam valores padrão para alguns
atributos de uma nova ocorrência de um objeto de
negócio. Uma tabela em que cada ocorrência corresponda
a um objeto de negócio e relacionada a ela uma lista de
campos, indicando em cada um o valor que deve ser
apresentado como default quando da criação de um
registro do respectivo objeto de negócio, é um exemplo de
template.
• Com apenas um atributo. Cada ocorrência representa um
valor válido para o preenchimento do respectivo atributo
em uma ocorrência de um ou mais objetos de negócio. A
relação das unidades (m2 , l, Kg, PF) para cadastramento
de insumos é um exemplo de valores válidos.
• Com dados que raramente mudem e que representam uma
faixa de valores válidos. A mão de obra alocada a um
serviço, em situações normais, apenas pode apropriar
horas em determinado período do dia. A tabela que
armazena essas informações é um exemplo de faixa de
valores válidos.
Os dados de referência são definidos como requisitos de armazenamento
que suportam regras de negócio na manutenção de dados de negócio. É
importante que os dados de referência, incluídos na medição dos pontos de
função, não sejam confundidos com os dados de código, estes não incluídos.
Os dados de código podem ter o código substituído pela respectiva descrição
nos objetos de negócio em que são utilizados sem que o significado destes
últimos seja alterado, enquanto o mesmo não pode ser feito com os dados de
referência.
As informações contendo os impostos aplicáveis em uma operação
comercial, com a sua descrição, codificação e a relação das alíquotas
vigentes em cada período, é um exemplo de dado de referência. A alíquota
aplicável a determinada operação não é substituída pelo código. O código
não é passível de substituição pelo código do imposto.
Os dados de código têm impacto na contagem de projetos medidos e
remunerados em pontos de função. Considere os casos a seguir:
a) O desenvolvedor dimensiona uma tabela e as funções
que a mantêm em 1.000 pontos de função. Algumas
poucas entidades armazenadas lá são dados de
referência, outras, a maioria, são dados de substituição
ou mesmo listas de domínios de valores válidos. Ele
 considera cada uma dessas entidades, 40, como ALI, e a
inclusão, alteração, exclusão, consulta detalhada,
consulta em lista e, por fim, lista de seleção (“ drop-
down list box ”) como transações. Antes do CPM 4.2, o
usuário teria alguma dificuldade em questionar tal
medição, apesar de já haver publicações do IFPUG que
ratificassem a sua perspectiva. Com a inclusão das
práticas de contagem no CPM 4.2 e sua manutenção nas
versões subsequentes fica mais fácil questionar tal
medição.
b) O desenvolvedor é remunerado pela medição dos
projetos de melhoria em termos de pontos de função.
Como remunerar uma manutenção especificamente em
uma tabela que implementa dados de código? O estado
da prática é incluir esse tipo de entrega em uma lista de
Itens não Mensuráveis em que se atribui uma medição
específica nessa situação.
Dados O que são? Função de substituição, descrição pelo código.
de Dados de
código substituiçã Condição suficiente para considerar dado de código.
o
Não é condição necessária.
Tanto a quantidade de ocorrências...
Dados
Quanto seu respectivo conteúdo...
estáticos
Raramente mudam.
“Domínios”.
Valores Relação com os valores válidos para preenchimento de atributos de um ou mais
válidos objetos de negócio.

A relação das unidades (m 2 , l, kg, PF) para cadastramento de insumos.

Sempre armazenam apenas uma ocorrência e cujo conteúdo de seus atributos
Uma raramente muda.
ocorrência Sistema usado em várias organizações, permite que os dados da empresa usuária
como razão social e outras informações afins sejam configurados.
Templates Valores padrão, default , para alguns atributos de uma nova ocorrência de um objeto
de negócio.
Uma ocorrência da tabela corresponde a um objeto de negócio, possui uma lista de
campos com seus conteúdos padrão.
 Faixa de Dados que raramente mudam.
valores
válidos Que representam uma faixa de valores válidos.
Ser mantidos pelo usuário.
Podem... Atender seus requisitos.
Estar dentro de seu domínio.

Chamados “ Metadados ”.
Não são especificados pelo próprio usuário.

Identificados pelo desenvolvedor .

Normalme
nte... Resposta a um ou mais requisitos técnicos .
Codificação de atributos descritivos em objetos de negócio.

Representa até 50% das entidades em um modelo de dados em terceira forma normal.

Não são Arquivos Lógicos (AL).

O que
fazer? Operações que só os mantêm NÃO são transações.

Não devem ser contados como Arquivos Referenciados nas transações que os leem ou mantêm.

Figura 4.14: Contagem de dados de código.

Outras Entidades não Contadas como

Arquivos Lógicos
Esta seção dá apoio à identificação de outros tipos de entidade também
não contadas como arquivos lógicos. Na análise de pontos de função, arquivo
lógico é definido como um grupo lógico de dados, podendo cada um ser
composto por uma ou mais entidades de dados. Esse agrupamento lógico é
baseado na perspectiva do usuário, ou seja, do negócio. Entidades que não
contêm atributos necessários e reconhecidos pelo usuário, mas contêm
apenas atributos técnicos, resultantes de considerações de projeto ou
implementação, como arquivos de índice criados para melhorar o tempo de
resposta, não devem ser contadas como arquivos lógicos ou mesmo tipos de
registro.
Arquivos de Índice
Arquivos de índice, utilizados para melhorar a performance na
recuperação de dados, implementam requisitos não funcionais. Também não
possuem funcionalidade de armazenar dados ou informações de controle,
portanto não podem ser ALIs ou AIEs.
Arquivos com Dados Consolidados
Arquivos com dados consolidados, cujo único fim é agilizar o
processamento, não representam requisitos funcionais, mas sim um requisito
de performance. Não podem ser ALIs ou AIEs. Existem casos em que os
requisitos funcionais de armazenamento do usuário levam o desenvolvedor a
implementar arquivos que mantêm dados consolidados. É fundamental
destacar que para esse tipo de armazenamento ser efetivamente considerado
um arquivo lógico, as informações armazenadas não devem poder ser
reconstruídas a partir dos dados originais. Muitas vezes os dados detalhados
são expurgados, outras vezes eles não estão mais em sincronia com a
informação consolidada. Nesses casos os arquivos com dados consolidados
serão arquivos lógicos.
Arquivos Temporários e de Passagem de Movimento
Sistemas cujo processamento é realizado em lotes ( batch ) em geral
possuem várias fases envolvendo determinada tarefa. O produto de cada uma
dessas fases é subsídio para a próxima. Esses produtos muitas vezes
assumem a forma de arquivos do sistema operacional, mas sua principal
intenção é transportar dados; são de fato mensagens. Neste caso o arquivo
original não representa um requisito funcional de armazenamento, como
também todos os outros arquivos envolvidos no processo.
Arquivo com a remessa de transações recebido por uma instituição
financeira, criticado, ordenado, tem o resultado do seu processamento
passando por um filtro que transforma seu layout original no layout padrão
da instituição, para ser submetido ao processamento final das transações.
Todos esses arquivos são temporários e não devem ser considerados ALIs ou
AIEs.
Distribuição de Dados
A distribuição de dados de um mesmo grupo lógico de dados em vários
arquivos físicos mantidos em localidades diferentes não é um requisito
funcional. Cada um desses arquivos, apenas por conter dados de determinada
localidade ou pela manutenção de réplicas de dados mantidos de forma
centralizada, não deve ser considerado isoladamente como um ALI ou AIE.
Existem redundâncias eventualmente distribuídas em diversas
localidades, que representam requisitos funcionais. Exemplo: após a
aprovação do cadastro de um novo cliente, ele fica disponível para o registro
de pedidos. Quando da aprovação, um arquivo contendo apenas a
identificação e o nome do cliente é atualizado e diariamente enviado a todos
os centros de distribuição da empresa para diversas consultas. O usuário
reconhece nessa lista um requisito de armazenamento que remonta ao tempo
em que o processo era manual. Não há motivo para não considerar essa lista
de clientes aprovados como um requisito funcional de armazenamento da
aplicação.
Dados Consumidos de Visões e Serviços Web
É muito comum haver dúvidas quanto à contagem de dados obtidos a
partir de visões de bancos de dados ou serviços web. Afinal, podem agregar e
filtrar dados de diversas tabelas, com lógica de processamento muitas vezes
complexa, e que agilizam o desenvolvimento de transações. Contudo, não
podem ser consideradas automaticamente como arquivos lógicos, pois não
representam requisitos funcionais de armazenamento do usuário.
Os conceitos cujas propriedades são obtidas ou atualizadas por meio de
visões ou serviços web são aqueles que devem ser investigados como ALI ou
AIE. A avaliação deve ser feita a partir dos requisitos funcionais do usuário e
não da forma como essa necessidade de dados foi implementada em uma
visão ou serviço web. Apesar disso é possível fazer algumas generalizações.
Quando uma dessas implementações existe como fonte de dados apenas
para processos da própria aplicação, não deve ser contada como função do
tipo transação. Ela pode afetar a contagem de pontos de função, uma vez que
talvez aumente a contribuição aos pontos de função das transações que
consultam dados a partir de um deles. Relacionar para cada visão ou serviço
web na aplicação os arquivos lógicos que eles representam agiliza a
contagem dos arquivos referenciados nesses processos. Veja o exemplo a
seguir.
Uma visão gera um sumário com o total de horas apropriadas por
funcionário. As entidades “Funcionário” e “Apropriação”, ambas arquivos
lógicos, são lidas para tal fim. Ao avaliar cada processo que lê essa visão,
acrescente “Funcionário” à respectiva lista de arquivos referenciados se ele já
não estiver sendo diretamente lido e/ou mantido pela transação sendo
avaliada. O mesmo é válido para “Apropriação”. O número de arquivos
referenciados aumentará em dois nos processos em que tanto “Funcionário”
quanto “Apropriação” não sejam lidos e/ou mantidos. Como consequência a
complexidade e a contribuição desses processos podem ser aumentadas.
Verifique se, apesar de ler a visão, o processo em análise de fato necessita
dos dados presentes em ambos os arquivos lógicos, “Funcionário” e
“Apropriação”. Por um descuido de projeto ou programação, em vez de ler
“Funcionário”, o sistema lê a visão. O requisito do usuário envolve obter
dados de “Funcionário” e apenas ele deve ser contado como arquivo
referenciado.
Quando uma visão ou um serviço web existe como resposta a um
requisito de fornecimento de dados ao usuário, ele está implementando uma
função do tipo transação que tem esta intenção (SE ou CE) e deve ser
contada. Esta situação é mais comum quando uma aplicação é usuária de
outra. Exemplo: a aplicação conta-corrente de um banco deve fornecer o
saldo disponível para saque de um correntista para outras aplicações da
organização, uma vez que elas não estão cientes das regras de negócio para o
cálculo desse saldo. Dentre as várias formas de implementar este requisito, a
visão é uma delas. Outro exemplo: em uma aplicação corporativa que obtém
dados de diversas outras aplicações, a organização tem como política que
todas as aplicações que fornecem dados para essa aplicação devem fazê-lo de
maneira padronizada. Uma forma de garantir isso é exigindo que cada
aplicação que fornece dados implemente a mesma visão.
Entidades de Ligação
As entidades com apenas as chaves de duas ou mais outras entidades
como atributos, definindo com isso a intersecção entre elas, representam a
implementação de um relacionamento em um modelo de dados normalizado.
Nesse relacionamento cada ocorrência da entidade “A” pode estar ligada a
muitas (N) ocorrências da entidade “B” e cada ocorrência dessa entidade
pode estar ligada a muitas (M) ocorrências da entidade “A”. Por isso é
chamado de “N:M” - lê-se relacionamento N para M - independentemente de
apenas as chaves estarem presentes.
Se excluirmos uma ocorrência da entidade A, todas as correspondentes
ocorrências armazenadas em R deixam de ter sentido para o negócio. A
mesma perda de significado acontece com as ocorrências armazenadas em R
relativas à determinada ocorrência de B quando de sua exclusão. Na
perspectiva do usuário as entidades A e B são percebidas como exposto no
diagrama:
 Figura 4.15: Diversas visões das entidades A, B e R. Onde está R?

A entidade R é criada na modelagem e projeto de banco de dados e não

existe como um requisito de armazenamento do usuário. Entidades como esta
não devem ser consideradas na contagem dos pontos de função nem como
arquivos lógicos nem como tipos de registro, conceito que será apresentado
em seguida. As chaves necessárias ao estabelecimento do relacionamento
devem ter os respectivos tipos de dados contados em todas as entidades
conectadas por essa entidade associativa, se já não o forem.
Entidades não Mantidas por Transações
Entidades não mantidas por transações da aplicação não são contadas
como ALIs ou AIEs.
Arquivos que Arquivos temporários , de trabalho , ou de classificação .
atendem requisitos de
armazenamento não Principal intenção não é armazenar dados , mas sim,
funcional Arquivos com transações transportar dados.
recebidas / enviadas para
São transações em arquivos de lotes.
atualizar ALI do sistema/outro
sistema As transações que geram ou processam o arquivo devem ser
contadas.

Visões de banco de dados Podem agregar e filtrar dados de diversas entidades ou

relacionais tabelas .

Condições muitas vezes complexas que agilizam o

desenvolvimento de transações.

Não armazenam dados em si.

Quando sua finalidade é atender requisitos de fornecimento
de dados para outras aplicações, será uma CE ou SE; caso
contrário, não será contada como uma função.
Pode aumentar a contribuição aos pontos de função das
transações que usam a visão.
 Relacionar para cada visão quais são os AL que ela lê agiliza
a contagem dos AR nessas transações.
Único fim é agilizar o processamento.
Informações
armazenadas não são
reconstruídas a partir
dos dados originais.
Dados Atenção!
Requisitos de armazenamento consolida Contar como Muitas vezes os dados
dos Arquivo detalhados são
para performance expurgados.
Lógico
quando: Outras vezes eles não
estão mais em sincronia
com a informação
consolidada.

Arquivos de índice , operações de junção e projeção.

Dados de código
Distribuição de dados de um mesmo grupo lógico de dados em vários
Distribui arquivos físicos mantidos em localidades diferentes.
ção de Atende um requisito técnico de disponibilização dos dados.
Arquivos que atendem requisitos de
dados
armazenamento não funcional
Eventualmente, podem atender requisitos funcionais.
Entidades de ligação.

Dados não mantidos por PE de qualquer aplicação.

Figura 4.16: Arquivos que não devem ser considerados na

contagem.

O que Fazer com as Entidades que

Sobraram?
Após analisar a aplicabilidade dessas considerações às entidades da
aplicação, as restantes serão potenciais arquivos lógicos, ou seja, cada uma
avaliada de maneira isolada pode ou não ser um arquivo lógico. É preciso
avaliar como é utilizada pelas transações e a sua independência ou
dependência em relação às outras entidades.
Avaliação Inclusão e exclusão conjunta de determinado grupo de entidades.
de entidades
Alteração de uma entidade normalmente não é uma orientação efetiva
Como as transações manipulam
para agrupar entidades.
os grupos de dados
Identifique os PE que consultam essas entidades e verifique se também
são consultadas em conjunto.
Relação de interdependência Obrigatoriedade de ligação entre entidades.
entre as entidades
Interdependência entre entidades.
 Entidades atributivas.
Generalização, subtipos e supertipos.
Entidades associativas.

Figura 4.17: Dicas para identificar arquivos lógicos.

Observe como as Transações Operam com os Dados
A perspectiva de negócio do usuário quanto aos dados é refletida em
como as transações os consultam e/ou atualizam. Verifique como as
transações da aplicação mantêm essas entidades. A inclusão e exclusão
conjunta de determinado grupo de entidades é um forte indicador que esse
grupo deve ser considerado um único arquivo lógico. A alteração de dados
normalmente está direcionada apenas a uma única entidade;
consequentemente, ela não é uma orientação efetiva para agrupar entidades.
Identifique as transações de extração que consultam essas entidades e
verifique se elas também são consultadas conjuntamente.
Uma ordem de serviço (OS) deve ter as informações que identificam qual
cliente a solicitou, a data de entrada, seu prazo estimado, seu responsável e os
vários itens envolvidos em sua execução. Durante a modelagem de dados
foram especificadas as entidades Ordem de Serviço e Itens da OS para
atender a esse requisito de armazenamento. Os processos “OS - Incluir” e
“OS - Excluir” sempre operam nas duas entidades. Não é possível incluir
uma OS sem que seus itens não possam ser informados e quando se exclui
uma OS, todos os seus itens também são excluídos.
Entidades Dependentes
A entidade com significado para o negócio sem a presença de outras é
chamada “Entidade Independente”. A entidade que apenas tem significado
em conjunto com outra é chamada “Entidade Dependente”. A Figura 4.18
ilustra a Item da OS como uma entidade dependente da Ordem de Serviço.
 Figura 4.18: Entidades dependentes.

Uma ordem de serviço excluída não tem seus itens remanejados para
outra. Eles são parte integrante daquela ordem de serviço. Sem os dados da
ordem de serviço seus itens não têm significado para o negócio. Ou seja, a
“Itens” é uma entidade dependente. O diagrama seguinte ilustra o
mapeamento da visão do usuário, do negócio, para uma visão de
implementação, técnica.
A entidade independente analisada de forma isolada não é um arquivo
lógico quando tem uma ou mais entidades dependentes. O mesmo se dá com
as entidades dela dependentes. Isoladamente também não são arquivos
lógicos. Um arquivo lógico é identificado pela análise da entidade
independente em conjunto com todas as suas entidades dependentes. Cada
uma das entidades, dependentes ou não, pode ser um tipo de registro
considerado na determinação da complexidade desse arquivo lógico. Por
exemplo, tanto a entidade Ordem de Serviço quanto a entidade Itens da OS
isoladamente não são arquivos lógicos, contudo em conjunto é um arquivo
lógico.
É importante não confundir o conceito de dependente/independente com
a obrigatoriedade de ligação entre duas entidades. Quando a ocorrência do
gerente responsável por determinado conjunto de clientes é excluída da
entidade “ F ”, as ocorrências desse conjunto de clientes na
entidade “ C ” continuam tendo significado para o negócio. No
máximo, a referência ao gerente desses clientes será atualizada com o novo
responsável ou mesmo deixada sem preenchimento - Caso 1. Uma vez
atualizados, esses dados não perderiam seu significado mesmo que o
preenchimento do gerente responsável pelo cliente fosse obrigatório - Caso 2.
A obrigatoriedade de cada cliente ter um gerente responsável é condição
necessária, mas não suficiente para considerar a entidade “ C ”
dependente da entidade “ F ”.
Cada funcionário é responsável por vários clientes.

Quando o F é excluído, os dados de seus clientes ainda

Obrigatoriedade de têm significado para o negócio.
ligação entre entidades
A eventual obrigatoriedade da ligação entre C e
F não muda a independência entre eles.
Com o significado para o negócio sem a
Entidades presença de outras entidades.
independentes (EI) Isoladamente não é um AL se tiver um ou
mais dependentes.
Apenas tem significado em conjunto com
outra entidade.
Relação de Isoladamente não são AL.
interdependência das
entidades

Entidades
Interdependência entre dependentes (ED)
entidades

Análise da EI em O conjunto é contado como um AL.

conjunto com suas Pode-se contar um TR para cada entidade,
EDs dependente ou não.
NÃO confundir dependência/independência com obrigatoriedade de
ligação entre duas entidades.

Figura 4.19: Relacionamento Obrigatório/Opcional x

Dependência/Independência.

Entidade Atributiva
É a entidade dependente que estende conceitualmente outra entidade, a
entidade principal, descrevendo uma ou mais de suas características e cujas
ocorrências podem substituir a repetição de um mesmo subgrupo de dados
em uma única ocorrência da principal. Por exemplo, as entidades
dependentes “ I OS” e “ E C
OS”.
 Como exposto, a entidade independente, principal, em conjunto com
todas as entidades dependentes que a descrevem são contadas como um
único arquivo lógico. A entidade atributiva, ou melhor, o grupo lógico com
os tipos de dados que ela compreende afeta a complexidade desse arquivo
lógico pela contagem de novos tipos de registro, ou apenas pela contagem de
novos tipos de dados.
O CPM, ao avaliar as práticas de contagem dessas entidades, considera
que para cada ocorrência da entidade principal deve corresponder no máximo
uma ocorrência da entidade dependente. Neste sentido, quando uma
ocorrência da entidade principal puder existir sem o respectivo par na
entidade dependente, deve-se contar dois tipos de registro, sendo a entidade
principal e a entidade dependente. Quando obrigatoriamente para cada
ocorrência da entidade principal houver necessidade de uma ocorrência da
entidade dependente, ou seja, uma só tem sentido para o negócio
acompanhada do preenchimento da outra, deve-se contar apenas um tipo de
registro, compreendendo os tipos de dados de ambas as entidades.
Existem entidades atributivas que compreendem grupos de dados
repetidos para uma mesma ocorrência da entidade principal. Neste caso,
conta-se um tipo de registro para cada entidade. Mesmo que não haja uma
entidade dependente para tal fim, mas ainda assim existam grupos de dados
repetidos em uma mesma ocorrência de uma entidade, esses grupos também
são contados como um novo tipo de registro. Por exemplo, a entidade “
C ” possui doze campos para armazenar o montante pedido em cada
mês durante o ano. Essa situação deve ser contada como se houvesse uma
entidade “ P M ” com um tipo de dados com o montante pedido e
outro indicando o mês. Ou seja, um tipo de registro deve ser contado com
dois tipos de dados.
Entidade dependente que estende conceitualmente outra entidade.
Defini Descreve uma ou mais características de outra entidade.
ção
Ocorrências podem substituir a repetição de um mesmo subgrupo de dados em
uma única ocorrência de outra entidade.
Entidad Conta-se 1AL em conjunto com a outra entidade.
Relação de
es
interdepen-dência Se uma ocorrência da outra entidade existe sem seu par,
Atributi CPM só
das entidades deve-se contar 2 TR [1:(1) ou (1):1]
vas considera
Conta Se cada ocorrência da outra entidade requer um par, deve-
relacionamento
gem se contar apenas um 1 TR com os TD de ambas as
s 1:1
entidades [1:1]
Entidades atributivas podem compreender grupos de dados repetidos para uma
mesma ocorrência da outra entidade. Conta-se 1 TR para cada entidade.
 Figura 4.20: Contagem de entidades atributivas.

Generalização, Subtipos e Supertipos

A relação entre um elemento mais geral - o pai - e um elemento mais
específico que agrega informação adicional e é totalmente consistente com o
primeiro elemento - o filho - é chamada “Generalização”. Este conceito é
aplicado em vários tipos de artefato, como casos de uso, pacotes e classes.
Estas últimas, mais especificamente as classes persistentes, são objeto de
interesse para efeito do dimensionamento dos requisitos de armazenamento.
Ao modelar os dados a partir do diagrama de classes, as classes mais gerais
costumam gerar “Entidades Supertipo”, enquanto as mais específicas,
“Entidades Subtipo”.
Essas entidades compreendem tipos de dados especializados e
complementares aos da entidade pai. A entidade supertipo em conjunto com
suas entidades dependentes subtipo formam um único arquivo lógico. Nesse
arquivo lógico, cada entidade é contada como um tipo de registro. Por
exemplo, os tipos de dado da entidade “ F ” podem ser
complementados com tipos de dados específicos dos funcionários
remunerados por mês e por hora trabalhada. As entidades “ H ” e “
M ”, subtipos, possuem tipos de dados específicos exigidos pelo
negócio para armazenar as particularidades de cada tipo de funcionário. Um
único arquivo lógico “Funcionário” é contado com três tipos de registro -
“Funcionário”, grupo de dados obrigatório, “Mensalista” e “ H ”,
grupos de dados opcionais.
 Figura 4.21: Diversos modelos utilizando o conceito de
generalização.

Em alguns casos pode haver dúvida quanto à contagem do conjunto como

um único arquivo lógico. Sua eliminação se dá pela aplicação da verificação
de dependência entre as entidades subtipo e supertipo. Se a entidade subtipo
for dependente do supertipo, como é de se esperar, a contagem anterior se
aplica; caso contrário, é conveniente revisar a modelagem procurando
verificar se de fato se trata de uma situação de generalização descrita nesta
seção.
Relação de Generalização, Relação entre um elemento mais geral - o pai
interdependência das subtipos e - e outro mais específico.
entidades supertipos
Definição Agrega informação adicional.
Totalmente consistente com o primeiro
elemento - o filho.
Casos de uso.
Pacotes.
Requisitos de
Aplicado em vários
Persiste armazenamento.
tipos de artefatos Cla
sse ntes Mapeada em entidades
s supertipo e subtipos.
Não persistentes.
 Contagem Apenas pode formar um AL o supertipo com
todos os seus subtipos.
A entidade subtipo deve ser dependente da
supertipo.
Conta-se 1 TR para cada entidade.

Figura 4.22: Contagem de Generalização, supertipos e subtipos.

Entidades Associativas
As entidades que relacionam duas ou mais outras entidades entre si são
chamadas “Entidades Associativas”. No exemplo seguinte, a entidade
“Trabalho” relaciona as entidades “Ordem de Serviço” e “Funcionário”. Com
a informação disponível no diagrama não podemos concluir se ela pode
apenas relacionar em quais ordens de serviço um funcionário trabalha, se ela
registra dados de negócio relativos ao trabalho ou registra um fato que deve
ser armazenado mesmo quando o trabalho de cada funcionário terminar.

Figura 4.23: “Trabalho” como entidade associativa de “OS” e

“Funcionário”.

A análise dessas entidades envolve a avaliação de um conjunto ordenado

de casos. Não é necessário prosseguir a análise quando a entidade associativa
se enquadrar em um deles:
1. Regras do negócio requerem que as ocorrências da
entidade associativa em análise continuem sendo
armazenadas, mesmo quando a relação entre as entidades
envolvidas não mais existir ou que haja transações
específicas na sua manutenção. Além da entidade em
análise relacionar duas ou mais entidades, ela tem
significado próprio, é uma entidade independente e é
contada como um arquivo lógico.

Figura 4.24: Entidade Associativa como um Arquivo Lógico.

2. Requisitos do negócio estabelecem que informações

específicas relativas ao fato que relaciona as entidades
associadas sejam armazenadas. A entidade associativa é
também uma entidade dependente. Ela só tem significado
em conjunto com as entidades que relaciona, não sendo,
portanto, um arquivo lógico isolado. Contudo, o grupo de
dados lógico compreendido por ela é um tipo de registro
de cada arquivo lógico composto pela entidade
relacionada e a entidade associativa. Cabe destacar que
não necessariamente todos os campos desse grupo de
dados serão contados como tipos de dados de todas as
entidades relacionadas e pode haver o caso em que haja
 entidade relacionada que não tenha nenhum deles contado
como tipos de dados, portanto também não terá nenhum
novo tipo de registro contado. O critério para determinar
qual desses cenários deve ser o utilizado numa contagem
em particular é a visão do usuário. Por exemplo, considere
que a entidade Item do Pedido estabelece a associação
entre as entidades Pedido e Produto.
Ao avaliar os processos de manutenção de produto,
verifica-se que existe muito pouca informação referente
aos dados armazenados nos itens do pedido, contudo, ao
avaliar os processos de manutenção de pedidos, todos os
dados de item de pedido são tratados em conjunto com os
dados do pedido. Na verdade, a ligação é tão forte que na
perspectiva do negócio é correto afirmar que todos os
dados sejam do pedido.
3. A entidade associativa existe com o único fim de
relacionar entidades, e seus atributos, se houver, não são
originados de requisitos do negócio. Essas entidades não
são identificadas como arquivos lógicos e não contribuem
como um novo tipo de registro nos arquivos lógicos que
relacionam “Entidades de Ligação (Key-to-Key)”.
 Figura 4.25: Entidade Associativa como Tipos de Registro.

Figura 4.26: Entidade Associativa de Ligação.

Relacionam duas ou mais outras entidades entre si.

É uma entidade INDEPENDENTE, além de

relacionar duas ou mais entidades, ela tem
As ocorrências da associação são significado próprio.
armazenadas mesmo se a relação Conta-se 1AL.
entre as entidades não mais existir.

É uma entidade DEPENDENTE, só tem

Relação de Entidade significado em conjunto com as entidades que
interdependênc s relaciona.
ia das Associati NÃO contada AL.
entidades vas
O grupo de dados lógico compreendido por ela
Informações específicas relativas ao
conta 1 TR para cada AL composto pela entidade
fato que relaciona as entidades são
relacionada e a associativa.
armazenadas.

Entidades de Ligação (Key-to-Key).

NÃO contada como AL nem como TR.
Único fim de relacionar entidades e
seus eventuais atributos que não são
originados do negócio.

Figura 4.27: Contagem de Entidades Associativas.

Compartilhamento de Dados
Quando duas ou mais aplicações interagem e trocam informações entre si,
é comum surgirem dúvidas na contagem. É apresentado um conjunto de
cenários como geralmente são encontrados na medição de projetos e
aplicações e que com sua análise provê orientação quanto à contagem. Para
dar apoio a esse processo, algumas definições e padronização de
terminologia são necessárias.
A interação, pela troca de dados, entre duas ou mais aplicações pode ter
como propósito a leitura de dados externos no processamento de transações
ou a manutenção de arquivos lógicos dentro da fronteira do sistema com base
tanto na recepção de dados enviados ao sistema quanto pelo acesso direto aos
dados. Ela pode se dar, por exemplo, pelo acesso às transações de outra
aplicação, pelo acesso direto aos seus arquivos, pela transferência de
arquivos, pela solicitação direta de serviços em tempo real ou com aplicações
web.
O mapa seguinte resume as definições e apresenta a terminologia
utilizada na avaliação da contagem de arquivos compartilhados.
Dados Duas ou mais aplicações.
Compartilhados
Interação Trocam dados entre si.
Prover orientação na contagem.
Acesso
Transações referenciam ou utilizam dados direto.
externos. Dados
Propósito de dados recebidos.
compartilhados Acesso
Defini
ções direto.
Manter um ALI com dados externos.
Dados
recebidos.
Acesso a transações de outra aplicação.
Acesso direto a arquivos de outra aplicação.
Formas de compartilhar Transferência de arquivos entre aplicações.
Solicitação on-line e direta de informação em tempo real.
Aplicações web.
Termo Dados são lidos de uma fonte de dados.
s
“Copy” Cópia Não são alterados na fonte.
São gravados em outro local.
Conjunto de registros afins.
“File” Arquivo
Tratados como uma unidade.
“Image” Imagem Cópia exata de outro objeto.

“Load” Carga
“Merge” Consolidação
“Refresh” Sincronização
de dados
Normalmente criada por um utilitário.
Dados.
Copiar.
Instruções.
De: armazenamento interno.
Para: armazenamento externo.
Vários arquivos.
Mesmos elementos de dados.
Consolidados em um novo arquivo.
Criar novamente um conjunto de dados.
Atualizá-lo em relação à sua fonte.

Figura 4.28: Definições e terminologia para avaliação de

compartilhamento de dados.

Os cenários utilizados para avaliar a contagem de arquivos

compartilhados podem ser classificados em três tipos. As letras A, B e C são
utilizadas para denominar três aplicações distintas utilizadas nos casos
compreendidos por estes tipos:
(1) B lê dados mantidos em A atendendo requisitos do negócio.
Cenários e seus tipos (2) B lê dados mantidos em A por motivos técnicos.
(3) B mantém seus dados em arquivos mantidos também por A.

Figura 4.29: Tipos de cenário avaliados.

O tipo de cenário (1) - B lê dados mantidos em A, atendendo a requisitos

do negócio - compreende dois cenários, ambos contando como 1 ALI para a
aplicação A e um AIE para a aplicação B.
B lê dados mantidos em A atendendo a requisitos de
negócio
(Cenário 1) A: 1ALI
B: Lê diretamente dados de ALI em A, por exemplo, uma query. B: 1 AIE
A: Apenas 1
ALI
(1) B lê dados mantidos em A
(Cenário 2) Apenas um
atendendo requisitos do negócio
A: Extrai imagem de uma fonte dados. Reflete determinado “instantâneo”
momento e permanece em sua fronteira.
B: Lê diretamente esses dados de A, por exemplo, uma query. Também não
é um TR
B: 1 AIE
 Figura 4.30: Tipos de cenário (1).

• Cenário 1: o sistema B lê fisicamente um arquivo

mantido pelo sistema A. Este é o caso padrão de
contagem de AIE no sistema B referente aos dados lidos
do arquivo mantido em A. Este fato em si não implica na
identificação de nenhum objeto de contagem adicional em
A, em que o arquivo em questão já é contado como um
ALI.
• Cenário 2: o sistema A gera uma imagem de um ALI. Ela
reflete a posição atual de seus dados em determinado
momento para sua utilização por outras aplicações e se
mantém dentro da fronteira da aplicação, ou seja, não é
mantido por nenhuma outra aplicação ou mesmo a
aplicação que o gerou. A contagem é análoga ao cenário
anterior. O sistema A conta um ALI para ambos os
arquivos físicos e a cópia espelho não contribui nem
como um tipo de registro, enquanto é contado um AIE
para o sistema B e as transações que leem esse arquivo
devem computar mais um arquivo referenciado.
 Figura 4.31: Cenário 1.

Figura 4.32: Cenário 2.

B lê dados mantidos em A por motivos técnicos

(Cenário 3) A: ALI, 0 SE
A: Extrai imagem total sem LP adicional e envia a B.
B: Carrega imagem recebida de A sem LP adicional. B: AIE, 0 EE
(Cenário 4) A: 1 ALI, 0 SE
A: Extrai imagem com subconjunto dos dados sem LP
adicional e envia a B.
B: 1 AIE, 0 EE
B: Carrega imagem recebida de A sem LP adicional.
A: 1 ALI, 0 SE
B: 1 ALI, 0 SE
C: AIE, 0 EE
(2) B lê dados mantidos Não há lógica de
em A por motivos técnicos (Cenário 5) Cópia e Consolidação processamento de negócio
A: Extrai imagem para arquivo com alguns TD. envolvida.
B: Extrai imagem para arquivo com os mesmos TD.
Apenas para fins de
C: Consolida os dois arquivos e carrega. validação e referência.
Sincronização de dados
diária.
Tipicamente uma solução
técnica.
(Cenário 6) Telas A: 1 ALI
A: Transação de A é usada para obter e/ou referenciar dados
usados no processamento de transação de B. B: 1 AIE

Figura 4.33: Tipos de cenário (2).

• Cenário 3 e 4: em ambos os cenários, o sistema A gera

 uma cópia de determinado arquivo. A cópia é transferida
para o sistema B, em que é carregada em um arquivo local
apenas para validação e referência. A diferença entre eles
é que no cenário 3 todo o arquivo lógico é copiado
independentemente de quantos arquivos físicos estejam
envolvidos, enquanto no cenário 4 apenas um arquivo
físico é copiado.
Os dados mantidos no sistema B são periodicamente sincronizados
com os dados mantidos em A. Os dados permanecem dentro da fronteira
do sistema A do ponto de vista funcional. A principal intenção do
sistema B é ler dados desse arquivo. Esta situação deve ser contada como
se o sistema B lesse diretamente os dados do arquivo mantido em A, ou
seja, é contado um AIE para o sistema B e um ALI para o sistema A.

Figura 4.34: Cenários 3 e 4.

• Cenário 5: para evitar o custo de processamento

adicional envolvido em o sistema C ler dados em arquivos
mantidos nos sistemas A e B, é projetado um processo de
consolidação desses dois arquivos de A e B. O arquivo
resultante dessa consolidação é transferido para o sistema
C, no qual é carregado para uma base de dados local. Os
dados são sincronizados periodicamente com relação às
bases originais mantidas pelos sistemas A e B. Nesse
processo, não há lógica de processamento de negócio e os
 dados são utilizados em C apenas para fins de validação e
referência.
Apesar do processo de consolidação, desconsiderando os aspectos de
armazenamento físico em arquivos distintos, como exatamente os
mesmos dados são requeridos, existe apenas um arquivo lógico na
perspectiva do sistema C. Desta forma, é contado um AIE para o sistema
C e um ALI para cada sistema A e B, Figura 4.35.
• Cenário 6: o sistema B, para complementar as
necessidades de dados de suas transações, extrai e/ou
recebe dados presentes na interface com o usuário de
outro sistema A (telas, janelas, diálogos etc.). Apesar de o
sistema B não acessar diretamente esses dados mantidos
em fronteira da aplicação A, eles são trazidos desse
sistema e representam requisitos de armazenamento do
sistema B. Os arquivos que compreendem esses dados
devem ser contados como AIE do sistema B, Figura 4.36.
 Figura 4.35: Cenários 5.

Figura 4.36: Cenários 6.

B lê dados mantidos em A atendendo a requisitos de

negócio
(Cenário 7) A: 1 ALI
A: Mantém todo ou parte de um arquivo.
B: Mantém todo ou parte do mesmo arquivo. B: 1 ALI

(3) B mantém seus dados em arquivos A: 1 ALI, 1 SE

(Cenário 8)
mantidos também por A A: Gera e envia arquivo de transações para atualização B: 1 ALI, várias EE
de B. A: 1 ALI, 1 SE
B: Atualiza seus próprios arquivos com o
1 EE para cada tipo
processamento do arquivo de transações.
de atualização

Figura 4.37: Tipos de cenário (1).

• Cenário 7: tanto o sistema A quanto o sistema B mantêm

um mesmo arquivo que atende aos requisitos para
considerá-lo um arquivo lógico. Ele deve ser contado
como um ALI em ambas as aplicações, respeitando a
perspectiva que cada uma delas tem em termos de tipos de
dados e tipos de registro, Figura 4.38.
• Cenário 8: o sistema A envia ao sistema B um arquivo de
transações. Esse arquivo, ao ser processado no sistema B,
atualiza um arquivo lógico interno desse sistema
colocando-o em sincronia com o arquivo mantido no
sistema A e que deu origem ao arquivo de transações.
Ambos os sistemas têm requisitos de acessar dados do
arquivo ora em atualização. Os tipos de dados, contudo,
são diferentes. Esse processamento é um requisito de
negócio. São contados dois ALI, um para a versão do
arquivo de cada sistema, é contada uma entrada externa
referente a cada tipo de movimento de atualização contido
no arquivo de transações e uma saída externa referente à
geração desse arquivo, Figura 4.39.

Figura 4.38: Cenário 7.

 Figura 4.39: Cenário 8.

Sistema de Controle de Ponto

Assim, voltando ao exemplo do sistema de Controle de Ponto do capítulo
3, tem-se que:
Tabela 4.2: Formulário de contagem das funções do tipo dado do
sistema de controle de ponto.

Nome da função Tipo TD TR Complexidade PFs

AI
Pessoa (do Controle de Segurança) 4 1 BAIXA 5
E
AL
Apontamento 4 1 BAIXA 7
I
AL
Justificativa 3 1 BAIXA 7
I
Total de pontos de função dos arquivos 21
Legenda:
(Tipo) - Classificação da Funcionalidade (ALI, AIE)
(TD) - Quantidade de Tipos de Dados
(TR) - Quantidade de Tipos de Registros

O arquivo Pessoa é um AIE, pois não é mantido pelo Sistema de Controle

de Ponto e sim pela aplicação Controle de Segurança.
 Todos os arquivos possuem um único tipo de registro e os tipos de dados
identificados para cada um deles são:
• Pessoa (AIE): matrícula, nome, senha criptografada e
tipo (gerente ou trabalhador). Esse arquivo pode ter
muitos outros campos utilizados pelo sistema de Controle
de Segurança, mas são contados apenas aqueles utilizados
pela aplicação Controle de Ponto.
• Apontamento (ALI): matrícula, data, horário entrada,
horário saída.
• Justificativa (ALI): matrícula, data, texto.

Questões de Fixação

1. Qual a diferença fundamental entre um Arquivo Lógico

Interno e um Arquivo de Interface Externa?
2. Quais são os critérios para a determinação da
complexidade de um Arquivo Lógico Interno ou Arquivo
de Interface Externa?
3. Um Arquivo Lógico Interno só pode ser classificado
como tal para uma única aplicação? Por quê?
4. Por que motivo um arquivo de movimento recebido de
outra aplicação não é contado como um Arquivo de
Interface Externa?
5. Dê um exemplo de uma situação em que existam duas
tabelas, mas se conte apenas um Arquivo Lógico Interno.
Justifique (procure identificar divisão por motivos afins à
implementação).
6. Em um projeto de melhoria será acrescentado um campo
a um Arquivo Lógico Interno. Esse arquivo possui um
tipo de registro e 50 campos anteriormente à manutenção,
sendo classificado como de complexidade baixa e
contribuindo em 7 PF. Qual a contribuição desse Arquivo
Lógico Interno para o tamanho do projeto de melhoria?
7. Durante o desenvolvimento de um novo sistema, foi
identificada a necessidade de obter dados de um arquivo
lógico até então não utilizado pela aplicação. Esse arquivo
possui três tipos de registros com mais de 65 campos. A
aplicação que está sendo desenvolvida utilizará apenas
dois campos. Com quantos PF esse arquivo contribui para
o projeto de desenvolvimento?
8. Um Arquivo Lógico Interno é composto por três tipos de
registro, sendo Informações de Compromisso,
Parcelamento do Pagamento e Rateio de Despesas. O
primeiro grupo contém 20 campos, o segundo 20 e o
terceiro 11. Para efeito de relacionamento desses grupos
entre si, todos os grupos compartilham o código do
compromisso. Com quantos PF esse ALI contribui para a
aplicação?
9. Quais as diretrizes fornecidas pelo IFPUG para
determinar se duas entidades com relacionamento entre si
devem ser contadas como um único grupo de dados (um
ALI/AIE com dois tipos de registro) ou como dois grupos
de dados distintos (dois ALIs/AIEs com um tipo de
registro cada)?
10. Conceitue e exemplifique as três categorias de
entidades de dados definidas pelo IFPUG. Quais delas
podem ser consideradas arquivos lógicos?
11. Considerando que a aplicação A mantenha um grupo
lógico de dados com 51 tipos de dados em três tipos de
registros e que a aplicação B referencie apenas 19 desses
tipos de dados e altere o valor de um outro tipo de dado.
Na perspectiva de ambas as aplicações existem três tipos
de registro. Com quantos pontos de função esse grupo
lógico de dados contribui para a aplicação A e para a
aplicação B?
12. O esquema seguinte ilustra um relacionamento entre
Produto e Fornecedor, em que as duas entidades são
mutuamente independentes. Além disso, mostra um
relacionamento entre Fornecedor e Contato por meio de
entidades reciprocamente dependentes. Tomando como
base a descrição dada e o modelo seguinte, quantos
arquivos lógicos (ALIs ou AIEs) devem ser contados?
13.Quais das seguintes entidades devem ser consideradas como
Dados de Código?

Entidade 1 - Situação do aluno Entidade 2 - Cores de fundo

1 Aprovado 1 Amarelo
2 Recuperação 2 Vermelho
3 Reprovado 3 Preto

Entidade 3 - Conversão moeda estrangeira/real

Dólar 2,84
Euro 3,14
Peso 10,66

Bibliografia

1. DEKKERS, C. Demistifying Function Points: Clarifying

Commom Terminology . IT Metrics Strategies , v. VII,
n. 3, mar. 2001. Cutter Consortium. Disponível em:
<http://www.qsma.com/pdfs/ITMSVol_VII3.pdf>. Acesso
em: 9 abr. 2012.
2. GARMUS, D.; HERRON, D. Function Point Analysis:
Measurement Practices for Sucessful Software Projects .
Addison-Wesley, 2000.
3. IFPUG. Function Point Counting Practices Manual:
Release 4.3 . International Function Point Users Group,
2010.
4. ______. Framework for Functional Sizing: Release 1.0
. International Function Point Users Group, 2003.
5. LONGSTREET, D. Function Point Training and
Analysis Manual . Disponível em:
 <http://www.SoftwareMetrics.com/freemanual.htm>.
Acesso em: 19 fev. 2013.
6. ______. Improved Function Point Definitions.
Disponível em:
<http://www.softwaremetrics.com/trainingcourse/definitio
ns.htm>. Acesso em: 8 mar. 2002.
7. NESMA. Function Point Analysis for Software
Enhancement: versão 2.2.1. Disponível em:
<http://www.nesma.nl/>. Versão traduzida para o
português disponível em: <
http://www.fattocs.com.br/artigos/APF-Melhoria-
NESMA.pdf >. Acesso em: 9 abr. 2012.
 5

Funções do Tipo Transação

Introdução
Este capítulo apresenta as definições para as funções do tipo transação e
explica o processo e as regras de contagem relacionadas, exemplificando
sempre que possível.

Figura 5.1: Contar funções do tipo transação.

A Figura 5.2 em seguida apresenta o resumo do processo de contagem

das funções do tipo transação.
 Figura 5.2: Resumo do processo de contagem de funções do tipo
transação.

As funções do tipo transação representam a funcionalidade fornecida ao

usuário para atender às suas necessidades de processamento de dados pela
aplicação. São classificadas em Entradas Externas, Saídas Externas ou
Consultas Externas.
Tabela 5.1: Funções do tipo transação.

Função de transação
Atividade de entrada Atividade de saída
Entrada Externa (EE) Saída Externa (SE) Consulta Externa (CE)

Definição de Entrada Externa (EE)

Uma entrada externa (EE):
1. É um processo elementar (é uma transação, mas veja
definição de termos mais à frente).
2. Processa dados ou informações de controle recebidos
de fora da fronteira da aplicação.
3. Tem como principal intenção manter (incluir, alterar ou
excluir dados de) um ou mais arquivos lógicos internos
e/ou modificar o comportamento do sistema .

Exemplos de EE
São exemplos de entradas externas:
• Transações que recebem dados externos utilizados na
manutenção de arquivos lógicos internos.
• Janela que permite adicionar, excluir e alterar registros
em arquivos lógicos internos contribui com três entradas
externas.
• Processamento em lotes de atualização de bases
cadastrais a partir de arquivos de movimento.
Em geral o nome das transações possui termos bem característicos de
uma entrada externa, como incluir, alterar, excluir, editar, registrar,
importar, gravar, carregar.

Não Exemplos de EE
Não são exemplos de entradas externas:
• Telas de filtro de relatórios e consultas, pois são parte do
relatório ou consulta. Isoladamente não cumprem uma
função para o usuário.
• Menus, que são apenas meios de agrupar e acionar
transações (estas é que são medidas).
• Telas de login cuja sua principal intenção é dizer se o
usuário tem ou não acesso, sendo classificadas como CE
ou SE.

Definição de Saída Externa (SE)

Uma saída externa (SE):
1. É um processo elementar .
2. Envia dados ou informações de controle para fora da
fronteira da aplicação.
3. Tem como principal intenção apresentar informação ao
usuário por meio de lógica de processamento que não
seja apenas a recuperação de dados ou informações de
controle. A lógica de processamento deve
obrigatoriamente conter ao menos uma fórmula
matemática ou cálculo, e/ou criar dados derivados (não
é necessário que esses dados ou cálculos sejam
apresentados ao usuário), e/ou manter (incluir, alterar ou
excluir dados de) um ou mais arquivos lógicos internos
e/ou alterar o comportamento do sistema.

Exemplos de SE
São exemplos de saídas externas:
• Relatórios que possuem totalização de dados.
• Relatórios que também atualizam arquivos.
• Consultas que apresentam cálculos ou dados derivados.
• Arquivo de movimento (exemplo: arquivo de remessa ou
retorno) que foi gerado para outra aplicação.
• Informações que têm formato gráfico (em geral possuem
cálculo, totalização).
• Telas de login que em geral contemplam cálculo, por
exemplo criptografia, ou atualização de dados.

Não Exemplos de SE
Não são exemplos de saídas externas:
• Telas de help , pois normalmente a capacidade de ajuda
on-line é requisito não funcional.
• Listagens de dados que em geral são classificadas como
CEs, pois consistem apenas em recuperação e
apresentação de dados.
• Consultas e relatórios sem nenhum totalizador, que não
atualizam arquivos, não têm dados derivados ou
modificam o comportamento do sistema.
Definição de Consulta Externa (CE)
Uma consulta externa (CE):
1. É um processo elementar .
2. Envia dados ou informações de controle para fora da
fronteira da aplicação.
3. Tem como principal intenção apresentar informação ao
usuário por meio de uma simples recuperação de dados
ou informações de controle de ALIs e/ou AIEs. A lógica
de processamento não deve conter fórmula matemática
ou cálculo, tampouco criar dados derivados. Nenhum
ALI é mantido durante seu processamento, nem o
comportamento do sistema é alterado.

Exemplos de CE
São exemplos de consultas externas:

• Informações que possuem formato gráfico.

• Listagem de dados, desde que recuperem dados de
arquivos lógicos (ALIs e/ou AIEs). As listas de dados
estáticos, com os valores codificados diretamente no
programa-fonte, não são contadas.
• Telas de login , caso estejam restritas a recuperação e a
comparação de valores de login e senha de usuário.
• Menus gerados dinamicamente que sejam baseados em
configuração da aplicação.

Não Exemplos de CE
Não são exemplos de consultas externas:

• Menus que sejam estáticos.

• Relatórios e consultas que contenham cálculo ou gerem
dados derivados (pois são SEs).
Definição de Termos Utilizados
São apresentadas em seguida as definições dos termos utilizados em EE,
SE e CE. Alguns já foram definidos no capítulo anterior, mas são
apresentados devido à sua importância neste contexto.

Processo Elementar
Um processo elementar é a menor unidade de atividade que satisfaz
todas as seguintes regras:
a) Tem significado para o usuário.
b) Constitui uma transação completa.
c) É autocontido.
d) Deixa o negócio da aplicação sendo contada em um
estado consistente.
Exemplo: o agendamento de um compromisso, indicando como será o
parcelamento da despesa e o rateio desta entre as unidades organizacionais
é a menor unidade de atividade do usuário de contas a receber.
Exemplo: ao final do agendamento de um compromisso, ele deixa o
sistema em estado íntegro. O agendamento do compromisso sem o devido
registro do parcelamento não é considerado um processo completo para o
usuário.
Na tela seguinte de manutenção de compromisso não se pode dizer que
há uma única transação de Manter Compromisso, pois há unidades de
atividade com significado para o usuário menores que ela: Incluir (novo)
Compromisso (EE), Alterar Compromisso (EE), Consultar Compromisso
(implícita, precedendo a alteração, classificada como SE se interpretarmos
que ela possui cálculos) e Excluir Compromisso (EE). Estas quatro
transações também são completas do ponto de vista do usuário,
independentes entre si e deixam a aplicação num estado consistente.
Por outro lado, se tentarmos quebrar demais a tela, o conceito de
processo elementar deixa de ser atendido. É o caso paralisa os campos de
Plano de Pagamento da mesma tela. Embora eles tenham uma barra de
ferramentas própria, permitindo inclusão, alteração e exclusão de dados, do
ponto de vista de negócio a manutenção do Plano de Pagamento só tem
sentido quando se inclui ou se altera um compromisso. Ou seja,
isoladamente a manutenção de Plano de Pagamento não é algo completo,
portanto não haverá transações adicionais.

Figura 5.3: Tela de manutenção de compromisso com quatro

processos elementares.

Para que Serve o Conceito de Processo

Elementar?
 O conceito de processo elementar é o mais importante para a medição
das funções do tipo transação. Se por um lado ele evita que vários processos
elementares sejam contados como um único, por outro lado impede que
subprocessos componentes de processos elementares também sejam
contados. Em termos práticos, a validação de CPF na inclusão de um cliente
não pode ser considerada um processo elementar. De forma análoga, uma
tela de cadastro que permite incluir, alterar e excluir deve ser contada como
três processos elementares, e não apenas um único.
Os exemplos de processos elementares que incluem, alteram, excluem e
consultam dados são os mais triviais, no entanto é importante destacar que
pode haver vários processos de negócio que alteram um registro. Neste
caso, é preciso ter o cuidado de não considerar apenas um único processo
elementar “alterar dados”, mas sim contemplar os vários processos de
negócio existentes.
Vejamos um exemplo da liberação de crédito: existe um usuário que está
autorizado a manter os dados sobre uma liberação de crédito. Ele pode
incluir, alterar, excluir, consultar e concluir o cadastramento desse registro.
A conclusão do cadastramento, apesar de também ser uma alteração no
registro em termos técnicos, do ponto de vista do negócio é outra atividade
diferente.
Quando o usuário está alterando (corrigindo, atualizando ou
complementando) dados no registro, ele está executando o processo de
“liberação de crédito - alterar”. Do ponto de vista do negócio, quando ele
informa ao sistema que o seu trabalho acabou, ele está executando o
processo de “liberação de crédito - concluir preenchimento”.
Muito provavelmente deve haver um caso de uso específico ou um fluxo
alternativo que descreva essa conclusão. Existe uma consulta que permite
ao supervisor consultar as liberações de crédito que estejam pendentes de
aprovação. Ao executá-la, o supervisor está executando o processo
“liberação de crédito - consultar pendentes de aprovação”. Após a sua
análise ele pode editar os dados e adicionalmente emitir o seu deferimento.
Este é um processo “liberação - deferir operacional”. Para liberações de
crédito acima de determinado valor, um procedimento semelhante é
executado por um gerente que utiliza os processos “liberação de crédito -
consultar pendentes de aprovação gerencial” e “liberação de crédito -
registrar apreciação do gerente”.
 Neste exemplo há vários processos de negócio que alteram o registro de
crédito, mas seria incorreto considerar um único processo elementar “alterar
registro de crédito”. Do ponto de vista do usuário cada processo de negócio
(liberação de crédito - alterar, liberação de crédito - concluir, liberação de
crédito - deferir operacional, liberação de crédito - registrar apreciação do
gerente) é também um processo elementar.

Informações de Controle
Informações de Controle são dados que influenciam um processo
elementar da aplicação sendo contada. Elas especificam o quê, quando ou
como os dados devem ser processados. Em resumo, são parâmetros.
Exemplos
O quê: determinado campo especifica que o cálculo da parcela deve
contemplar somente o valor vencido ou o valor corrigido com juros e multa.
Quando: uma enquete pode ter um fechamento automático (votações
finalizadas) definido pela data do seu encerramento.
Como: durante a compra de uma passagem aérea, o cliente informa em
um campo como deseja receber a confirmação da compra: por e-mail,
torpedo (SMS) ou fax.
Exemplo: as telas de configuração de preferências de usuário, na
maioria dos softwares, contêm várias informações de controle. No caso do
Internet Explorer são exemplos de informação de controle: página inicial,
quantidade de dias que as páginas ficam no histórico de visitas, nível de
privacidade.
Exemplo: em uma loja de comércio eletrônico, a operação de compra
possui uma informação de controle - forma de pagamento - que determina
como o processo ocorrerá (se vai emitir um boleto, se fará débito na conta,
se vai usar cartão de crédito). Cada forma de pagamento possui um
tratamento diferenciado.
 Figura 5.4: Exemplo de informações de controle do Internet
Explorer 7.0.

Dado Derivado
Informação criada a partir da transformação de dados existentes. Requer
outro processamento além da recuperação, conversão e edição direta de
dados de um arquivo lógico interno e/ou arquivo de interface externa. Ou
seja, é um dado apresentado pelo sistema, mas não está armazenado em um
arquivo lógico. Ele é criado através de uma lógica de processamento
(cálculo, por exemplo). Exemplos de dados derivados podem ser todos os
campos apresentados pela transação que sejam resultados de cálculos: total
de faturamento, tempo médio entre falhas, porcentagem de participação do
produto X nas vendas.
Modificar o Comportamento do Sistema
Modificar o comportamento do sistema significa alterar um parâmetro
de negócio (através de alguma transação). O efeito causado por essa
mudança no parâmetro tem reflexo no comportamento de outras transações.
Exemplo: o sistema de compras dá autonomia para que cada comprador
possa efetuar compras de até R$10.000,00 no mês sem autorização da
chefia. Este valor é um parâmetro do sistema e quando for alterado, afetará
as transações de compra, ou seja, alterará o comportamento do sistema.

Lógica de Processamento
Lógica de Processamento é definida como qualquer um dos requisitos
apresentados em seguida especificamente solicitados pelo usuário para
completar um processo elementar. A tabela seguinte resume as lógicas de
processamento que podem ser executadas por cada tipo de transação. A
diferença fundamental entre elas está na sua principal intenção . Em cada
uma delas é necessário que seja executada determinada lógica de
processamento para que sua principal intenção seja alcançada.
Tabela 5.2: Resumo das lógicas de processamento.

Tipo de lógica de processamento EE SE CE

1. Realização de validações. P
Po Po
Exemplo: ao adicionar um novo cliente, deve-se validar se o endereço de od
de de
e-mail informado atende às regras de formação de um endereço de e-mail. e
2. Realização de cálculos e fórmulas matemáticas. De
Po N
Exemplo: ao listar todos os clientes, calculam-se o número total de ve
de ão
clientes do sexo masculino, do sexo feminino e o total geral. *
3. Conversão de equivalência entre montantes.
P
Exemplo: uma transação referencia taxas de conversão de câmbio Po Po
od
monetário. Isso é feito pela recuperação de valores de tabelas, de maneira de de
e
que não há necessidade de cálculos.
4. Dados são filtrados e selecionados utilizando determinados critérios
para comparar múltiplos conjuntos de dados. P
Po Po
Exemplo: para listar clientes com parcelas que vencem no mês, a od
de de
transação compara as datas de vencimento das parcelas com o final do mês e
para selecionar e listar as parcelas apropriadas.
 Tipo de lógica de processamento EE SE CE
5. Condições são analisadas para determinação de qual se deve aplicar. P
Po Po
Exemplo: para conceder um crédito, a transação analisa se o valor od
de de
solicitado é inferior a 20% da renda declarada pelo cliente. e
6. Um ou mais ALI são atualizados. De De
N
Exemplo: ao adicionar um cliente, o processo elementar atualiza o ALI de ve ve
ão
clientes para manter os seus dados. * *
7. Um ou mais ALI ou AIE são referenciados. D
Po Po
Exemplo: ao incluir um cliente e informar seu CEP, o AIE de CEPs é ev
de de
referenciado para buscar o endereço completo. e
8. Dados ou informações de controle são recuperados. D
Po Po
Exemplo: para poder visualizar uma lista de clientes, as informações de ev
de de
clientes são recuperadas do cadastro de clientes existente. e
9. Dados derivados são criados pela transformação dos dados existentes
em novos dados. De
Po N
Exemplo: após a inclusão de um usuário, a identificação de login é gerada ve
de ão
automaticamente pelo sistema por meio da concatenação de algumas letras *
do seu nome e sobrenome.
10. O comportamento do sistema é alterado. De De
N
Exemplo: ao mudar o parâmetro da quantidade de dias que se armazena a ve ve
ão
lista de sites visitados, o browser muda de comportamento. * *
D
11. Preparar e apresentar informação para fora da fronteira da aplicação. Po De
ev
Exemplo: uma lista de clientes é apresentada ao usuário. de ve
e
12. Capacidade de aceitar dados ou informação de controle que entra na
P
fronteira da aplicação. De Po
od
Exemplo: o usuário entra com várias informações para incluir um ve de
e
agendamento de recebimento.
13. Dados são ordenados ou organizados. P
Po Po
Exemplo: o usuário solicita uma lista de clientes ordenados od
de de
alfabeticamente pelo sobrenome. e
* Ao menos uma das lógicas de processamento deve estar presente.

Regras para Determinar se um Processo

Elementar é Único
Para que seja possível diferenciar uma transação de outra, são
necessárias regras claras, senão o que impediria que uma mesma função
fosse contada mais de uma vez? Diferenciar duas funções apenas pelo nome
seria um critério muito frágil. Por exemplo: um sistema de recursos
humanos possui várias consultas de funcionário. Qual a justificativa para
que a APF considere a “consulta de funcionários em férias” diferente da
“consulta de funcionários em licença médica”? Afinal, são todas consultas
de funcionário!
Para determinar um processo elementar é distinto quando comparado a
um processo elementar já identificado, verifique se eles requerem o mesmo
conjunto de:
• Tipos de dado; e
• Lógicas de Processamento para completar o processo
elementar.

Variações do Mesmo Processo

Elementar
Um processo elementar pode incluir variações nos tipos de dados ou
arquivos referenciados, assim como múltipas alternativas, variações ou
ocorrências de lógicas de processamento. Não divida um processo
elementar com múltiplas formas de lógicas de processamento em
múltiplos processos elementares , com base na regra da unicidade. A
identificação de processos elementares é sempre feita com base na sua
definição aplicada aos requisitos funcionais do usuário.
Exemplos
a) Uma interface com o usuário apresenta uma lista de
elementos. Ao escolher nessa lista um elemento, são
apresentados os mesmos campos de um único elemento
em outra interface.
b) Uma interface com o usuário permite consultar dados
a partir de um painel no qual o usuário especifica os
mais diversos critérios de seleção. Definidos esses
 critérios, uma lista com os registros que atendem a eles
é apresentada com os mesmos dados.
c) A exclusão de um registro pode ser realizada a partir
de uma lista na qual o usuário escolhe uma série de
itens a excluir; uma interface com o usuário em que os
dados de um item são apresentados em um painel.
d) Haver uma interface com o usuário para incluir uma
localidade e haver a possibilidade de incluir uma
localidade no contexto de outra função. Existe uma
interface com o usuário especificamente para incluir
uma localidade; em outra interface que tem por objetivo
incluir uma ocorrência, também é possível incluir uma
localidade visando tornar mais ágil a utilização do
sistema por seus usuários.
e) Ao cadastrar uma pessoa, ela pode ser classificada
como pessoa física ou jurídica. Ambos compartilham a
maioria dos atributos e regras. A pessoa física tem
alguns outros atributos específicos de seu tipo,
enquanto a pessoa jurídica, outros atributos específicos.
Há um mesmo ator que em um mesmo passo do fluxo
de trabalho realiza essa função; um único caso de uso
descreve adequadamente o processo em questão
independentemente de se tratar de uma pessoa física ou
jurídica 14 .

Proposta de Diretrizes para Identificar

Processos Elementares e Determinar a
Sua Unicidade
Observe que existem nas regras e definições apresentadas alguns termos
que permitem mais de uma interpretação, como “completo” e “variações de
menor importância”. Em situações em que a Análise de Pontos de Função é
usada para fins de estimativas ou melhoria de processos internamente em
uma organização, os princípios e exemplos que compõem a regra costumam
ser suficientes para que aqueles que a aplicam o façam de maneira
uniforme. Contudo, quando a técnica é usada para fins de medição de
contratos, os autores já presenciaram situações que beiram o absurdo
quando comparadas ao estado da prática e que mesmo assim consomem
horas para demonstrar o óbvio. Por exemplo:
a) Um caso de uso em uma função de consulta que, ao
ser medido, resultou em 28.000 PF.
b) Uma tela que lista uma relação de itens, ao ser
invocada, apresenta todos os itens disponíveis. Ao
usuário, é permitido estabelecer critérios para filtrar
alguns itens dessa lista. Em vez de um único processo
elementar ser identificado, dois foram. Considerando
que esse expediente foi usado em uma diversidade de
casos, o impacto seria considerável.
Nesta seção é estabelecida a interpretação quanto a alguns conceitos e
regras que compõem o padrão de medição funcional do IFPUG. São
fornecidas diretrizes para tomada de decisão na medição.

Requisito Funcional
Definição: os requisitos funcionais do usuário são um subconjunto dos
requisitos do usuário; descrevem o que o software deve fazer em termos de
tarefas e serviços.
Diretriz: requisitos funcionais são aqueles requisitos particulares e
específicos de uma tarefa ou serviço; contrasta com aqueles requisitos já
atendidos de maneira geral por infraestrutura que fornece serviços
genéricos, independentes de uma tarefa em particular.
Cenário (a) - Requisito não Funcional: todos os relatórios do sistema
devem, por força de uma política de TI, ser passíveis de geração nos
formatos Portable Document Format (.pdf); Microsoft Word (.doc);
Microsoft Excel (.xls) e texto (.txt).
Os usuários do ambiente Java são informados quanto a essa política
geral e orientados a não solicitar essa característica como um requisito ao
expor as suas necessidades em função de ela já ser uma limitação do
projeto. Trata-se de um requisito não funcional.
Cenário (b) - Requisito Funcional: um determinado relatório em
particular deve poder ser gerado em papel e em um leiaute específico para
envio para um órgão regulador. Ambos os produtos são idênticos em termos
de conteúdo e em boa parte de sua lógica de processamento. Diferem na
apresentação dos dados que é feita de uma forma específica em cada caso.
Trata-se de um requisito funcional.

“Completo”
Definição
i. Estado consistente: ponto onde o processamento foi
totalmente executado; o requisito funcional do usuário
foi satisfeito e não há nada mais a fazer.
ii. Autocontido: não há passos de processamento
anteriores ou posteriores necessários para iniciar ou
completar o requisito funcional do usuário.
Diretriz
1) Considerar a ótica do negócio e não a ótica do sistema
para julgar um estado como consistente e um
processamento como autocontido.
 Cenário (1.a): é muito comum em ambiente Web haver gravações de
quadros em um formulário que o compreende e representando um único
documento alvo como uma transação completa em nível de sistema.
Trata-se do mesmo ator realizando uma mesma função em um único
passo do fluxo de trabalho . Por motivações não funcionais (restrições em
função da instabilidade do ambiente) o trabalho realizado no quadro é
gravado antes de terminar todo esse passo para atender limitações de ordem
geral quanto à qualidade e à organização.
Os conceitos de completo e autocontido aplicam-se ao preenchimento
do documento alvo em termos dos dados definidos naquele passo do fluxo
de trabalho por um mesmo ator, incluindo eventuais conjuntos de dados que
tenham várias possíveis ocorrências informadas e apresentadas em quadros.
Cenário (1.b): antes de prosseguir para um próximo passo em um fluxo
de trabalho automatizado, o documento pode ser salvo como um rascunho
ou então como uma versão final. Haverá uma série de consequências em
termos dos próximos passos. Se salvo como um rascunho, o usuário pode
realizar alterações ou mesmo excluir o documento informado no sistema. Se
salvo como uma versão final, o documento não pode ser mais alterado por
esse usuário e se torna disponível para processamento em outros passos do
fluxo de trabalho. Mesmo que salvar como um rascunho ou como uma
versão final sejam duas ações em um formulário, trata-se de um campo
sendo informado pelo usuário durante um processo de inclusão e alteração.
O que é completo é informar os dados do formulário; informar a sua
condição (rascunho ou versão final) é salvar os dados.
2) Se atores diferentes ou eventualmente o mesmo ator,
desde que em diferentes passos do fluxo de trabalho,
realizam atualizações em um mesmo documento
referentes às informações que são criadas e devem ser
registradas nos diferentes passos, vários processos
diferentes são considerados completos e não
simplesmente as funções de inclusão e alteração do
documento são contadas.
Cenário (2.a): antes de prosseguir para um próximo passo em um fluxo
de trabalho automatizado, o documento deve ser caracterizado como uma
versão final. Sempre ao salvar o documento nas funções de inclusão ou
alteração, ele é guardado na condição de rascunho. Existe um passo no
fluxo de trabalho em que nenhum dado é alterado e o usuário indica, após a
revisão dele, que ele agora está na condição de versão final. Neste cenário,
promover documento à condição de versão final é completo e independente
da alteração ou inclusão (observe o contraste deste exemplo com o exemplo
(1.4.1.b) anteriormente apresentado).
3) O critério para identificar um processo completo é de
que o requisito do usuário possa ser atendido com apenas
uma interface com o usuário em vez de utilizar diversas,
ainda que dessa forma funcione mal (pouca usabilidade e
desempenho sofrível, por exemplo) e ofereça maior
complexidade técnica.
Cenário (3.a): todos os atores habilitados a incluir ou alterar uma
solicitação de serviço podem também registrar um complemento a ela ou
incluir um novo participante. Existem três interfaces com o usuário para
esse fim, contudo não há nada em termos das práticas e procedimentos do
usuário que impeça de isso ser entregue como uma única interface com o
usuário.

Determinação da Complexidade
Cada Entrada Externa, Saída Externa e Consulta Externa deve ser
classificada com relação à sua complexidade funcional (baixa, média ou
alta) baseado em:
• Número de Arquivos Referenciados (AR);
• Número de Tipos de Dado (TD).
Determinadas as quantidades de arquivos referenciados e de tipos de
dados, a classificação com relação à complexidade é fornecida pelas
seguintes tabelas:
Tabela 5.3: Tabela de complexidade para entradas externas (EEs).
 Tipos de dados (TDs)
<5 5 - 15 > 15
<
Baixa Baixa Média
Arquivos referenciados (ARs) 2
2 Baixa Média Alta
>
Média Alta Alta
2

Tabela 5.4: Tabela de complexidade para saídas externas (SEs) e

consultas externas (CEs).

Tipos de dados (TDs)

<6 6 - 19 > 19
Arquivos referenciados (ARs) <2 Baixa Baixa Média
2- 3 Baixa Média Alta
>3 Média Alta Alta

Assim, uma EE com dezesseis tipos de dados e dois arquivos

referenciados é de complexidade alta. Uma SE com dezesseis tipos de
dados e dois arquivos referenciados é de complexidade média. E uma CE
com dezenove tipos de dados e um arquivo referenciado é de complexidade
baixa.

Importante
Das tabelas de complexidade percebe-se que tanto EEs
quanto SEs podem não ter arquivos referenciados, no entanto
uma CE, pela própria definição, deve referenciar ao menos
um arquivo lógico (ALI/AIE).

Definição de Arquivo Referenciado (AR)

Um arquivo referenciado é:

• Um arquivo lógico interno lido ou mantido pela função

 do tipo transação;
ou
• Um arquivo de interface externa lido pela função do tipo
transação.

Regras de Contagem para Arquivo

Referenciado
As seguintes regras são válidas para a contagem de um arquivo
referenciado. As duas primeiras, que tratam de atualização de arquivos, não
são aplicáveis para consultas externas.
• Conte um arquivo referenciado para cada ALI mantido.

Figura 5.5: Identificação do AR Compromisso na transação Incluir

Compromisso (da Figura 5.2).

• Conte apenas um arquivo referenciado para cada ALI

que seja tanto mantido quanto lido.
Exemplo: no caso da inclusão do compromisso, o sistema verifica antes
de efetivar a inclusão se há algum compromisso vencido do mesmo
fornecedor. Logo o ALI Compromisso deve ser lido antes de ser atualizado,
porém conta-se o AR Compromisso uma única vez.
• Conte um arquivo referenciado para cada ALI ou AIE
lido durante o processamento.

Figura 5.6: Identificação dos ARs Unidade Organizacional e

Favorecido na transação Incluir Compromisso (da Figura 5.2).

Mesmo que o ALI/AIE tenha vários tipos de registro, não deve contá-lo
mais de uma vez.
NÃO conte arquivos que não são classificados como ALI ou AIE. Veja
exemplo para dados de Tipo de Documento, Figura 5.7, destacada da
transação Incluir Compromisso, Figura 5.2. Assumindo que Tipo de
Documento fosse classificado como Dados de Código e que a transação de
inclusão do compromisso tivesse de ler dados dessa entidade, ainda assim
esta não seria contada como AR da transação.
 Figura 5.7: Tipo de Documento (dados de código), lido pela
transação, mas não contado como AR.

Quando a transação manipula dados que não são arquivos lógicos, não
há AR a ser contabilizado para esses dados.
NÃO conte o mesmo arquivo mais de uma vez, mesmo que a transação
faça várias leituras ou atualizações nele.

Definição de Tipo de Dado (TD)

Um tipo de dado é um campo único, reconhecido pelo usuário, não
repetido.

Regras de Contagem de Tipos de Dados

As seguintes regras devem ser válidas para a contagem de tipos de
dados:
• Conte um único tipo de dado para cada atributo que
atravessa a fronteira da aplicação (entrando e/ou saindo),
reconhecido pelo usuário, único, não repetido.
Exemplos
a) Ao adicionar um cliente, o usuário fornece o nome do
cliente e seu endereço.
b) Um gráfico do tipo pizza pode ter uma legenda e um
número equivalente à apresentação gráfica. Conte dois
tipos de dados, um referente à legenda e outro referente
ao valor numérico. Na Figura 5.6 o gráfico de pizza
possui três tipos de dados: nome do produto, valor
faturado, porcentagem de participação no faturamento.
 Figura 5.8: Tipos de dados do gráfico de faturamento: nome do
produto, valor faturado e porcentagem de participação no
faturamento.

c) Se um campo tanto entra quanto sai pela fronteira da

aplicação, deve ser contado uma única vez. Na tela de
filtro de um relatório de pedidos o usuário pode
informar por qual cliente deseja filtrar. O relatório exibe
todos os dados de pedidos, inclusive o código do cliente
informado na tela de filtro. Ao contar os tipos de dados
desse processo elementar, o código do cliente deve ser
contado uma única vez.
• Conte um único tipo de dado para a capacidade de envio
para fora da fronteira da aplicação de uma mensagem de
resposta do sistema, indicando um erro verificado
durante o processamento, a confirmação da sua
conclusão ou a verificação de seu prosseguimento.
Reforçando, conta-se um TD para a capacidade da
 transação de emitir mensagem, não para a quantidade de
mensagens que a transação pode emitir.
Exemplo: ao registrar um compromisso em que o prazo entre a data de
emissão e a data de vencimento seja inferior ao negociado com o
fornecedor, ou ao tentar registrar um compromisso com valor zero, o
sistema emite uma mensagem de erro. Deve-se contar um único tipo de
dado para todas essas mensagens.
• Conte um único tipo de dado para a capacidade de
especificar uma ação a ser tomada. Mesmo que haja
múltiplos meios de ativar o mesmo processo, deve ser
contado apenas um tipo de dado.
Exemplos
a) A seleção de uma parcela para recebimento pode ser
feita pela barra de espaço ou utilizando um check box .
b) Para salvar os dados da tela, o usuário pode clicar no
botão Salvar, usar a tecla de atalho CTRL+S ou usar a
opção “Arquivo>Salvar” do menu. Deve-se contar um
único tipo de dado para esses comandos.
Não conte com Tipos de Dados
a) Literais como títulos de relatórios, identificadores de
telas ou painéis, cabeçalhos de colunas, nomes de
campos e títulos de atributos.
Exemplo: na Figura 5.9 em seguida há vários literais: “compre aqui”,
“2 a 11 anos”, “0 a 23 meses”, porém o que deve ser considerado para
contagem de tipos de dados são apenas os campos que o usuário informa e
aqueles campos apresentados ao usuário.
 Figura 5.9 : Tipos de dados da tela de filtro de pesquisa de voos:
tipo de viagem (ida ou ida e volta), origem, destino, data de ida, data
de volta, quantidade de passageiros adultos, quantidade de
passageiros crianças (2 a 11 anos), quantidade de passageiros
crianças (0 a 23 meses).

b) Marcas geradas pala aplicação como atributos de data

e hora.
c) Variáveis de paginação, números de página e
informação de posicionamento.
d) Auxílios de navegação como a habilidade de navegar
em uma lista usando “anterior”, “próximo”, “primeiro”,
“último” e os seus equivalentes gráficos.
Exemplos: número de página, informações de posicionamento (linha 25
de 102), comandos de paginação como anterior, próximo ou setas de
rolagem em aplicações com interface gráfica, campos de data e hora do
sistema.
 Figura 5.10: Nesta tela de resultado de pesquisa de uma livraria
virtual, os campos “Resultados 1-10” e “Itens por página” não devem
ser considerados na contagem de tipos de dados desta consulta.

e) Atributos gerados dentro da fronteira da aplicação por

uma função transacional e salvos em um ALI sem sair
pela fronteira.
Exemplos: quando o usuário agenda um novo recebimento, o sistema
calcula um identificador único para esse registro. Esse campo não é
apresentado ao usuário, apesar de ser atualizado no respectivo ALI. O
código do recebimento não é contado como um tipo de dado para essa
entrada externa, uma vez que não atravessa a fronteira da aplicação.
Ao emitir uma nota fiscal, o sistema automaticamente atualiza no
estoque a nova quantidade de itens do produto. Esse tipo de dado não deve
ser contado.
Quando um cheque é impresso, um campo de situação no arquivo de
compromissos é atualizado. Esse campo não deve ser contado, uma vez que
não atravessou a fronteira da aplicação.
f) Atributos recuperados de um AIE ou ALI para
participar no processamento sem sair pela fronteira.
Na tela anterior, observe que a inclusão pode ser acionada pelo botão
Salvar ou OK, mas conta-se um único tipo de dado para a ação. Há campos
que o usuário não informa, mas que o sistema exibe (tipos de dados 2 a 9).
Há também campos que o usuário informa e o sistema também exibe (tipos
de dados 14 e 15) e que não são contados repetidos. Caso essa tela emita
alguma mensagem para o usuário, contar-se-á um tipo de dados a mais,
totalizando 25 TDs.

Figura 5.11: Identificação dos TDs na transação de inclusão de

compromisso.

Importante
Na prática, a avaliação dessas considerações é mais relevante
quando a quantidade de tipos de dados está nos limites das
faixas da tabela de complexidade. Não é necessário ser
rigoroso na contagem dos tipos de dados se já se sabe de
antemão que esse número está longe dos limites de mudança
de complexidade. Além disso, uma eventual classificação
incorreta da complexidade da função afeta de forma bem
limitada o resultado final da medição. Um rigor maior deve
ser dedicado à correta identificação da quantidade de funções,
pois isso produz um impacto muito mais significativo para o
resultado final da medição.

Determinação da Contribuição
 Após a determinação da complexidade das funções do tipo transação,
deve-se calcular sua contribuição utilizando a seguinte tabela:
Tabela 5.5: Contribuição dos pontos de função das funções do tipo
transação.

Tipo de função Baixa Média Alta

Entrada externa 3 PF 4 PF 6 PF
Saída externa 4 PF 5 PF 7 PF
Consulta externa 3 PF 4 PF 6 PF

Exemplos: uma EE de complexidade alta contribui com 6 pontos de

função, uma SE também de complexidade alta contribui com 7 pontos de
função e uma CE também de complexidade alta contribui com 6 pontos de
função.

Figura 5.12: Medição da entrada externa Incluir compromisso.

Sistema de Controle de Ponto.

Assim, voltando ao exemplo do sistema Controle de Ponto do capítulo

3, tem-se:
Tabela 5.6: Formulário de contagem das transações do sistema de
controle de ponto.

Descrição Tipo TD AR Complexidade Contribuição

Login SE 4 1 BAIXA 4
Registro de ponto EE 3 1 BAIXA 3
C
Consulta apontamento diário 5 1 BAIXA 3
E
Apontamento com justificativa EE 5 2 MÉDIA 4
Exclusão de apontamento EE 2 2 BAIXA 3
Alteração de apontamento EE 5 2 MÉDIA 4
1
Acompanhar presença SE 3 MÉDIA 5
0
Emitir relatório de presença SE 9 3 MÉDIA 5
Total de pontos de função das transações: 31
Legenda: (Tipo) - Classificação da funcionalidade (EE, SE ou CE)
(TD) - Quantidade de Tipos de Dados
(AR) - Quantidade de Arquivos Referenciados

Detalhando os processos elementares identificados, tem-se o seguinte:

• Login (SE)
Principal intenção: apresentar informação para o usuário (acesso
concedido ou acesso negado). Assumiu-se que há criptografia de senha,
logo a lógica de processamento de cálculos e fórmulas matemáticas está
presente.
Tipos de dados: comando (tecla Enter ou botão OK), mensagem
para o usuário, matrícula e senha.
Arquivos referenciados: pessoa.
• Registro de Ponto (EE)
Principal intenção: atualizar o ALI apontamento.
Tipos de dados: comando (tecla Enter ou botão OK), mensagem
para o usuário, indicador de entrada ou saída.
Arquivos referenciados: apontamento.
• Apontamento com Justificativa (EE)
Principal intenção: atualizar os ALI apontamento e justificativa.
Tipos de dados: comando (tecla Enter ou botão OK), mensagem
para o usuário, indicador de entrada ou saída, hora e justificativa.
Arquivos referenciados: apontamento e justificativa.

• Exclusão de Apontamento (EE)

Principal intenção: atualizar os ALI apontamento e justificativa.
Tipos de dados: comando (tecla Enter ou botão OK) e mensagem
para o usuário.
Arquivos referenciados: apontamento e justificativa.

• Alteração de Apontamento (EE)

Principal intenção: atualizar os ALI apontamento e justificativa.
Tipos de dados: comando (tecla Enter ou botão OK), mensagem
para o usuário, horário anterior, horário novo e justificativa.
Arquivos referenciados: apontamento e justificativa.

• Consulta Apontamento Diário (CE)

Principal intenção: apresentar dados do ALI apontamento.
Tipos de dados: comando (tecla Enter ou botão OK), mensagem
para o usuário, data, horário de entrada, horário de saída.
Arquivos referenciados: apontamento.
• Acompanhar Presença (SE)
Principal intenção: apresentar dados dos ALI apontamento,
justificativa e pessoa, com totalização.
Tipos de dados: comando (tecla Enter ou botão OK), mensagem
para o usuário, data inicial, data final, nome, data, horário de entrada,
horário de saída, justificativa, total de horas.
Arquivos referenciados: pessoa, apontamento e justificativa.
• Emitir Relatório de Presença (SE)
 Principal intenção: apresentar dados dos ALI apontamento,
justificativa e pessoa, com totalização.
Tipos de dados: comando (tecla Enter ou botão OK), mensagem
para o usuário, data inicial, data final, matrícula, nome, total de horas
do trabalhador, número de justificativas e total de horas do período.
Arquivos referenciados: pessoa, apontamento e justificativa.

Questões de Fixação

1. Qual o primeiro passo no processo de medição em

pontos de função das funções do tipo transação? Quais as
regras que devem ser utilizadas nesse primeiro passo?
2. Qual a principal intenção de cada função do tipo
transação?
3. Dê um exemplo prático de uma informação de controle
contada como um tipo de dados em uma tela de inclusão
de dados.
4. Quais os critérios para considerar um processo
elementar distinto de outro?
5. “Um saque é um saque, seja ele feito em um terminal de
autoatendimento ou na boca do caixa, mas o
procedimento é totalmente diferente”. Como você
classificaria uma transação de saque (saída de recursos)?
Quantas funções você identificaria? Por quê? Assuma
que temos neste contexto uma única fronteira de
aplicação.
6. Um depósito pode ser feito na boca do caixa, no
terminal de autoatendimento ou pelo processamento de
arquivos com relação de cheques. Como você
 classificaria uma transação de depósito (entrada de
recursos)? Quantas funções você identificaria? Por quê?
7. Quantos pontos de função têm a seguinte configuração:
tela com opções de consulta, inclusão, alteração e
exclusão? Todas as opções operam sobre um arquivo de
clientes com 19 campos e um tipo de registro. Em todas
as operações é informado o código do cliente. Na
inclusão e na alteração, todos os campos são informados,
a exceção da data da última alteração que é apenas
apresentada após a conclusão da operação de alteração.
As operações podem ser acionadas pelo menu ou pelos
botões na barra de ferramentas. Mensagens de erro e de
confirmação podem ser emitidas durante o
processamento.
8. Quantos tipos de dados devem ser contados na situação
em que, após uma alteração de dez campos, é atualizada
uma tabela de auditoria espelho com a versão anterior à
alteração de cada um dos dez campos? Se o registro
solicitado à alteração não for encontrado, é emitida uma
mensagem de erro.
9. É gerado um arquivo de movimento do sistema XSA
para processamento pelo sistema BCT. Esse arquivo é
composto por oito campos nos registros de detalhe. Ao
final do arquivo é inserido um rodapé com o total de
registros. Como você classificaria esse processo sob a
ótica dos dois sistemas?
10. O sistema de tesouraria permite a impressão de um
cheque. Nesse processo é atualizado um campo
 indicando que o cheque foi impresso. Como você
classificaria esse processo? Por quê?
11. Na realidade do sistema que você mantém/utiliza, se
fosse estimar a complexidade de uma entrada externa,
como o faria? Por quê? Considere que ainda não há
informação disponível relativa aos tipos de dados e
arquivos referenciados. Dica: imagine o número médio
de TDs e ARs para as demais entradas externas.
12. A tela seguinte de uma aplicação permite o registro de
venda de produtos. Ao informar o código, durante o
processamento da entrada de dados o respectivo nome do
cliente é apresentado juntamente com o total vendido por
mês para o cliente. Conforme se informa o código do
item, sua descrição e valor unitário são apresentados. Ao
informar a quantidade de itens, o sistema calcula e
apresenta o valor total. Quando o último item é
informado, o total da venda também é calculado e
apresentado. Durante o processamento mensagens de
erro podem ser apresentadas. Ao final da digitação o
usuário pode clicar em um botão de OK, pressionar F12
ou Enter. Para mudar de campos pode ser utilizado o
mouse ou a tecla de tab. O sistema emite uma mensagem
de confirmação solicitando a informação ao usuário.
Quantos pontos de função possui esse processo
elementar?
13. Por que a tela de parâmetro que existe unicamente com
o objetivo de disparar um relatório não é contada como
uma entrada externa? Como ela é contada?
14. A rotina de apropriação de crédito é responsável pelo
cálculo dos encargos a apropriar na contabilidade e pela
efetiva contabilização desses valores. Qual a diferença na
contagem desse processo se na abordagem de
implementação cada passo for implementado numa
rotina diferente? E no caso de haver um usuário que
especifica requisitos para o cálculo - Controles
Financeiros - e outro para a contabilização -
Contabilidade?

Bibliografia

1. DEKKERS, C. Demistifying Function Points:

Clarifying Commom Terminology . IT Metrics
Strategies , v. VII, n. 3, mar. 2001. Cutter Consortium.
Disponível em:
 <http://www.qsma.com/pdfs/ITMSVol_VII3.pdf>.
Acesso em: 9 abr. 2012.
2. GARMUS, D.; HERRON, D. Function Point
Analysis: Measurement Practices for Sucessful Software
Projects. Addison-Wesley, 2000.
3. IFPUG. Function Point Counting Practices Manual:
Release 4.3. International Function Point Users Group,
2010.
4. LONGSTREET, D. Function Point Training and
Analysis Manual. Disponível em:
<http://www.SoftwareMetrics.com/freemanual.htm>.
Acesso em: 19 fev. 2013.
5. ______. Improved Function Point Definitions.
Disponível em: <http://www.softwaremetrics.com/
trainingcourse/definitions.htm>. Acesso em: 8 mar.
2002.
6. NESMA. Function Point Analysis for Software
Enhancement: Versão 2.2.1. Disponível em:
<http://www.nesma.nl/>. Versão traduzida para o
português disponível em:
<http://www.fattocs.com.br/artigos/APF-Melhoria-
NESMA.pdf> Acesso em: 9 abr. 2012.
 6

Fator de Ajuste
O fator de ajuste não faz mais parte do processo de medição funcional
aderente à ISO/IEC 14133, contudo ainda é parte do Manual de Práticas de
Contagem como um apêndice, para manter a compatibilidade com aqueles
usuários que usam pontos de função com o fator de ajuste. Embora seja um
apêndice do manual, as suas regras e definições são objeto de questões na
prova de certificação como especialista em pontos de função (CFPS, veja
capítulo 11). Apenas por este motivo ainda mantemos no livro este assunto,
pois ele está obsoleto e na prática quase ninguém mais se interessa por ele.
O Valor do Fator de Ajuste (VAF) é baseado em 14 Características
Gerais de Sistema (CGS), listadas a seguir.
Tabela 6.1: Características Gerais de Sistema que determinam o
Fator de Ajuste.

1. Comunicação de Dados 8. Atualização On-Line

2. Processamento Distribuído
3. Performance
4. Configuração Altamente Utilizada
5. Volume de Transações
6. Entrada de Dados On-Line
7. Eficiência do Usuário Final
9. Complexidade de Processamento
10. Reutilização
11. Facilidade de Instalação
12. Facilidade de Operação
13. Múltiplos Locais
14. Facilidade de Mudanças

Enquanto as funções do tipo dado refletem requisitos específicos de

armazenamento e as funções do tipo transação requisitos específicos de
processamento, as características gerais refletem funções que afetam a
aplicação de maneira geral. Cada uma dessas características possui um nível
de influência sobre a aplicação que pode variar em um intervalo discreto de
zero a cinco.
Para diminuir a subjetividade na determinação do nível de influência de
uma característica geral, o IFPUG fornece diretrizes, apresentadas à frente,
que ajudam nessa tarefa.
Determinados os níveis de influência das 14 características gerais, o
fator de ajuste é calculado com a seguinte fórmula: VAF = (TDI × 0,01) +
0,65, sendo TDI o somatório dos níveis de influência (NI) das
características gerais.
Tabela 6.2: Níveis de influência das Características Gerais de
Sistema.

0. Nenhuma Influência
1. Influência Mínima
2. Influência Moderada
3. Influência Média
4. Influência Significativa
5. Grande Influência

O fator de ajuste, quando aplicado aos pontos de função, pode produzir

uma variação de ±35%, resultando na contagem final dos pontos de função.
Se o leitor prestar atenção à fórmula, perceberá que cada CGS influencia
em até 5% o valor final da contagem. E cada ponto atribuído ao nível de
influência afeta o resultado final em 1%.
Exemplo: Em um determinado sistema com 1.000 PFs, apurou-se que o
nível de influência de cada uma das características gerais é o seguinte:

N N
CGS CGS
I I
Comunicação de Dados 5 5
Processamento Distribuído 2 Atualização On-Line 2
Performance 2 Complexidade de Processamento 0
Configuração Altamente Utilizada 2 Reusabilidade Facilidade de Instalação 1
Volume de Transações 2 Facilidade de Operação 2
Entrada de Dados On-Line 5 Múltiplos Locais Facilidade de Mudanças 2
Eficiência do Usuário Final 2 2

Logo, o nível total de influência será TDI = 34.

 E o fator de ajuste será VAF = (34 × 0,01) + 0,65 = 0,99.
Consequentemente o tamanho em pontos de função ajustados do sistema
é 1.000 × 0,99, ou seja, 990 pontos de função ajustados.

Considerações
Quando a técnica de pontos de função foi apresentada por Allan
Albrecht, em 1979, não havia as 14 CGSs. O fator de ajuste era
determinado de forma totalmente subjetiva, o qual poderia produzir uma
variação de ± 25% nos pontos de função. Na revisão da técnica, em 1984,
foram introduzidas as atuais 14 CGSs e o fator de ajuste foi alterado para
produzir a variação de ± 35%.
O uso do fator de ajuste tornou-se opcional ao final do ano de 2002,
como uma medida para aceitação dos pontos de função do IFPUG como um
método padrão de medição funcional aderente à norma ISO/IEC 14143,
pois várias das CGSs contemplam requisitos não funcionais.
Antes mesmo do uso do fator de ajuste tornar-se opcional, uma
pesquisa(8) apoiada pelo IFPUG demonstrou que vários usuários já não o
utilizavam. Por exemplo, um dos modelos de estimativa para software mais
comuns, o COCOMO II, utiliza apenas os pontos de função como entrada
do processo; o fator de ajuste é ignorado.
Este é um ponto tão criticado da técnica que um grupo de trabalho do
comitê de práticas de contagem do IFPUG foi composto para se dedicar ao
assunto. Duas razões para a criação desse grupo foram: a grande variação
na interpretação das CGSs e a constatação de que algumas delas estão
desatualizadas. O resultado produzido pelo grupo foi a alteração de algumas
diretrizes para a pontuação das CGSs e a inclusão de dicas e exemplos.
Embora isso tenha melhorado um pouco a questão da subjetividade na
determinação do nível de influência das CGSs, na essência os problemas
originais permanecem.
Pesquisas realizadas (LOKAN, 1999) apontam várias críticas ao VAF e
às CGSs tanto do ponto de vista teórico quanto prático:

• Algumas CGSs são inter-relacionadas ou de natureza

 similar. Exemplo: Performance e Volume de Transações,
Entrada de Dados On-Line e Atualização On-Line . Ou
seja, quando o nível de influência de uma é alto, o da
outra também tende a ser alto e vice-versa.
• Existem requisitos importantes que não são
contemplados por nenhuma das 14 CGSs.
• Não é apropriado que todas as CGSs possuam o mesmo
peso para o nível de influência nem que o limite máximo
de influência de uma característica seja 5%. Por
exemplo, os autores do COCOMO II destacam neste
aspecto que reusabilidade pode ter um impacto muito
maior que esse limite.
• A variação de ± 35% é insuficiente para representar as
funcionalidades gerais da aplicação.
• O uso do fator de ajuste não traz nenhum benefício
adicional aos pontos de função para a estimativa de
esforço.
• É o ponto mais subjetivo da técnica e justamente onde
uma pequena diferença de interpretação pode provocar
uma diferença significativa na contagem final. Basta
lembrar que cada mudança no nível de influência afeta o
tamanho final em 1%!
Ainda que tenha todas essas deficiências, as orientações para
determinação do VAF são úteis para ajudar a diferenciar o que é requisito
funcional do que é requisito não funcional. O erro mais comum de quem
conta pontos de função é deixar requisitos não funcionais influenciarem na
contagem.
Diretrizes para Determinação do Nível
de Influência
A seguir, são apresentadas as diretrizes do IFPUG para a determinação
do nível de influência para cada característica geral de sistema. Se nenhuma
dessas orientações aplicar-se exatamente ao sistema, um julgamento deve
ser feito para determinar o nível de influência mais aproximado.
Após a apresentação das diretrizes para cada característica geral do
sistema, serão feitas algumas considerações e apresentados exemplos.

1. Comunicação de Dados
Descreve o nível em que a aplicação comunica-se diretamente com o
processador. Os dados ou informações de controle utilizados pela aplicação
são enviados ou recebidos por meio de recursos de comunicação. Terminais
conectados localmente à unidade de controle são considerados recursos de
comunicação. Protocolo é um conjunto de convenções que permite a
transferência ou intercâmbio de informações entre dois sistemas ou
dispositivos. Todos os links de comunicação necessitam de algum tipo de
protocolo.
Pontue de acordo com as seguintes orientações:
0 A aplicação é puramente batch ou uma estação de
trabalho isolada.
1 A aplicação é puramente batch , mas possui entrada de
dados ou impressão remota.
2 A aplicação é batch , mas possui entrada de dados e
impressão remota.
3 A aplicação possui entrada de dados on-line , front-end
de teleprocessamento para um processamento batch ou
sistema de consulta.
4 A aplicação é mais que um front-end , mas suporta
apenas um tipo de protocolo de comunicação.
5 A aplicação é mais que um front-end , e suporta mais de
um tipo de protocolo de comunicação.
Considerações e Exemplos
Pelo perfil atual das aplicações, sistemas batch são cada vez mais raros,
por isso poucas aplicações hoje pontuariam com menos de 2 ou 3. Segundo
um estudo realizado por Lokan(5), de uma amostra de 235 projetos de
software do repositório do ISBSG, 56% dos projetos pontuavam com 4 ou
5. Em geral, uma aplicação cliente x servidor em duas camadas pontuará
com 4. Aplicações de tempo real, servidores de aplicação e middlewares
pontuarão com 5.

2. Processamento Distribuído
Descreve o nível em que a aplicação transfere dados entre seus
componentes. Funções ou dados distribuídos dentro da fronteira são
características da aplicação.
Pontue de acordo com as seguintes orientações:
0 A aplicação não participa da transferência de dados ou
processamento de funções entre os componentes do
sistema.
1 A aplicação prepara dados para processamento pelo
usuário final em outro componente do sistema, como
planilhas eletrônicas ou banco de dados.
2 Dados são preparados para transferência, então são
processados em outro componente do sistema (não para
processamento pelo usuário final).
3 Processamento distribuído e transferência de dados são
feitos on-line e em apenas uma direção.
4 Processamento distribuído e transferência de dados são
feitos on-line e em ambas as direções.
5 O processamento de funções é executado dinamicamente
no componente mais apropriado do sistema.
Considerações e Exemplos
Segundo o estudo de Lokan (5) , esta é uma característica mais presente
em sistemas transacionais do que em sistemas de informação gerencial e
suporte à decisão. Um sistema de desktop isolado (aplicação e banco de
dados local) pontuará com 0. Um sistema de n camadas pontuará com 4.
Para pontuar como 5, o sistema deveria ter componentes executando em
múltiplos servidores ou processadores, sendo cada um deles selecionado
dinamicamente de acordo com sua disponibilidade.

3. Performance
Descreve o nível em que considerações sobre tempo de resposta e taxa
de transações influenciam o desenvolvimento da aplicação. Os objetivos
estabelecidos ou aprovados pelo usuário, em termos de tempo de resposta
ou taxa de transações, influenciam (ou influenciarão) o projeto,
desenvolvimento, instalação e suporte da aplicação. A questão que deve ser
avaliada para essa CGS é “Quão rápida deve ser a aplicação e o quanto isso
influencia o projeto?”
Pontue de acordo com as seguintes orientações:
0 O usuário não estabeleceu nenhum requisito especial
sobre performance.
1 Requisitos de performance e projeto foram estabelecidos
e revisados, mas nenhuma ação em especial foi tomada.
2 Tempo de resposta ou taxa de transações são críticos
durante as horas de pico. Não é necessário nenhum
projeto especial para a utilização de CPU. O limite para o
processamento é o dia seguinte.
3 Tempo de resposta ou taxa de transações são críticos
durante todas as horas de trabalho. Não foi necessário
nenhum projeto especial para a utilização de CPU. O
limite de processamento é crítico.
4 Adicionalmente, requisitos especificados pelo usuário
são exigentes o bastante para que tarefas de análise de
performance sejam necessárias na fase de projeto.
5 Adicionalmente, ferramentas de análise de performance
devem ser utilizadas nas fases de projeto,
desenvolvimento e/ou implementação para que os
requisitos de performance do usuário sejam atendidos.
Considerações e Exemplos
Esta característica tem uma forte relação com a CGS 5 - Volume de
Transações. Como exemplo de um sistema que pontuaria como 5, pode-se
citar um presenciado pelos autores. Um novo sistema de automação de
agências bancárias seria desenvolvido para substituir o existente. Havia um
requisito de performance: o tempo para autenticação de um documento pelo
caixa do banco não poderia ser superior ao do sistema atual. Uma diferença
de um segundo já era considerada inaceitável, portanto tarefas de análise de
performance tiveram que ser executadas e uma forma de demonstrar ao
cliente que o objetivo estava sendo atingido foi implementada.

4. Configuração Altamente Utilizada

Descreve o nível em que restrições de recursos computacionais
influenciam no desenvolvimento da aplicação. Uma configuração
operacional altamente utilizada, necessitando de considerações especiais de
projeto, é uma característica da aplicação. Por exemplo, o usuário deseja
executar a aplicação em um equipamento já existente ou comprado e que
será altamente utilizado. A questão que deve ser avaliada para essa CGS é
“O quanto a infraestrutura influencia o projeto?”
Pontue de acordo com as seguintes orientações:
0 Não existem restrições operacionais implícitas ou
explícitas nos requisitos.
1 Existem restrições operacionais, mas são menos
restritivas que uma aplicação típica. Não há esforço
especial necessário ao atendimento dessas restrições.
2 Existem restrições operacionais, mas são típicas da
aplicação. Há esforço especial necessário ao atendimento
dessas restrições.
3 Existem requisitos específicos de processador para uma
parte específica da aplicação.
4 Restrições operacionais explícitas necessitam de um
processador dedicado ou utilização pesada do
processador central.
5 Adicionalmente, existem limitações nos componentes
distribuídos da aplicação.
Considerações e Exemplos
Em geral, a grande maioria dos sistemas pontuará com 0 ou 1.
Aplicações científicas ou de engenharia com grandes exigências de
processamento pontuariam de 3 a 5.

5. Volume de Transações
Descreve em que nível o alto volume de transações influencia o projeto,
desenvolvimento, instalação e suporte da aplicação. A questão que deve ser
avaliada para essa CGS é “O quanto o volume de transações que a aplicação
deve processar em um determinado período de tempo afeta o projeto?”
Pontue de acordo com as seguintes orientações:
0 Não é previsto nenhum período de pico de transações.
1 São previstos períodos de pico de processamento (por
exemplo: mensal, quinzenal, periódico, anual), mas o
impacto no esforço do projeto é mínimo.
2 Volumes de transação regulares (por exemplo: picos
semanais) são previstos. Há algum impacto no esforço do
projeto.
3 Altos volumes de transação (por exemplo: picos diários)
são previstos, consequentemente com impacto
significativo no esforço do projeto.
4 Altas taxas de transação definidas pelo usuário nos
requisitos ou os níveis de serviço acordados são altos o
bastante para requererem tarefas de análise de
performance na fase de projeto.
5 Adicionalmente, existem requisitos de ferramentas de
análise de performance nas fases de projeto,
desenvolvimento e/ou instalação.
Considerações e Exemplos
Esta característica tem uma forte relação com a CGS 3 - Performance.
Um exemplo de aplicação com picos diários de transação é o registro de
pontos de funcionários.

6. Entrada de Dados On-Line

Descreve em que nível são efetuadas entradas de dados na aplicação por
meio de transações interativas.
Pontue de acordo com as seguintes orientações:
0 Todas as transações são processadas em lote.
1 De 1% a 7% das transações são entradas de dados on-
line .
2 De 8% a 15% das transações são entradas de dados on-
line .
3 De 16% a 23% das transações são entradas de dados on-
line .
4 De 24% a 30% das transações são entradas de dados on-
li ne.
5 Mais de 30% das transações são entradas de dados on-
line .
Considerações e Exemplos
Para a realidade das aplicações atuais, a maioria pontuará com 5. Nesse
caso claramente há uma defasagem nas diretrizes do IFPUG com a
realidade atual.

7. Eficiência do Usuário Final

Descreve em que nível considerações sobre fatores humanos e
facilidade de uso pelo usuário final influenciam o desenvolvimento da
aplicação. As funções interativas fornecidas pela aplicação enfatizam um
projeto para o aumento da eficiência do usuário final. O projeto inclui:

• Auxílio para navegação, como, por exemplo, teclas de

função, saltos, menus gerados dinamicamente;
• Menus;
• Ajuda on-line e documentação;
• Movimentação automática de cursor;
• Paginação;
• Impressão remota por meio de transações on-line ;
• Teclas de função predefinidas;
• Tarefas em lote submetidas a transações on-line ;
• Seleção feita por posicionamento de cursor em tela de
dados;
• Uso intenso de vídeo reverso, brilho, cores e outros
indicadores;
• Documentação impressa das transações;
• Interface de mouse;
• Janelas pop-up ;
• Utilização de número mínimo de telas para executar uma
função do negócio;
• Suporte a dois idiomas (conte como quatro itens);
• Suporte a mais de dois idiomas (conte como seis itens).
Pontue de acordo com as seguintes orientações:
0 Nenhum dos itens anteriores.
1 De um a três dos itens anteriores.
2 De quatro a cinco dos itens anteriores.
3 Seis ou mais dos itens anteriores, mas não existem
requisitos específicos do usuário associados à eficiência.
4 Seis ou mais dos itens anteriores e requisitos explícitos
sobre a eficiência para o usuário final são fortes o
bastante para necessitarem de tarefas de projeto que
incluam fatores humanos, como, por exemplo, minimizar
o número de toques no teclado, maximizar padrões de
campo e uso de modelos.
5 Seis ou mais dos itens anteriores e requisitos explícitos
sobre a eficiência para o usuário final são fortes o
bastante para necessitarem do uso de ferramentas e
 processos especiais para demonstrar que os objetivos
foram alcançados.
Considerações e Exemplos
Algumas dessas diretrizes também estão defasadas, uma vez que a
interface gráfica dos sistemas operacionais atuais já provê automaticamente
várias destas características (antigamente era a própria aplicação que tinha
que implementá-las). Aplicações batch ou aplicações servidoras que não
possuem interação com usuário final pontuarão com 0. Aplicações
tipicamente Windows pontuarão de 3 a 5.

8. Atualização On-Line
Descreve em que nível os arquivos lógicos internos da aplicação são
atualizados de forma on-line .
Pontue de acordo com as seguintes orientações:
0 Não há nenhuma atualização on-line .
1 Existe a atualização on-line de um a três arquivos.
Volume de atualização é pequeno e a recuperação é fácil.
2 Existe a atualização on-line de quatro ou mais arquivos.
Volume de atualização é pequeno e a recuperação é fácil.
3 A atualização da maioria dos arquivos internos é on-line
.
4 Adicionalmente, a proteção contra a perda de dados é
essencial e foi especialmente projetada e programada no
sistema.
5 Adicionalmente, o alto volume de processamento torna
necessária a análise do custo do processo de recuperação.
São incluídos procedimentos altamente automatizados
com um mínimo de intervenção do operador.
Considerações e Exemplos
Nesse caso também algumas das diretrizes estão defasadas. À exceção
de aplicações batch , a pontuação será de no mínimo 3.

9. Complexidade de Processamento
Descreve em que nível o processamento lógico ou matemático
influencia o desenvolvimento da aplicação. Os seguintes componentes estão
presentes:

• Controle sensível e/ou processamento específico de

segurança da aplicação. Exemplo: processamento
especial de auditoria.
• Processamento lógico extensivo. Exemplo: sistema de
gestão de crédito.
• Processamento matemático extensivo. Exemplo: sistema
de otimização de corte de tecidos.
• Muito processamento de exceção resultando em
transações incompletas que devem ser processadas
novamente. Exemplo: transações incompletas em ATM
em função de problemas de teleprocessamento, falta de
dados ou de edição.
• Processamento complexo para manipular múltiplas
possibilidades de entrada e saída, como, por exemplo,
multimídia, ou independência de dispositivo. Exemplo:
sistema de extrato de conta-corrente que emite via
terminal de retaguarda, autoatendimento, web , e-mail ,
telefone celular.
Pontue de acordo com as seguintes orientações:
0 Nenhum dos itens anteriores.
1 Qualquer um dos itens anteriores.
2 Quaisquer dois itens anteriores.
3 Quaisquer três itens anteriores.
4 Quaisquer quatro itens anteriores.
5 Todos os cinco itens anteriores.
Considerações e Exemplos
Como nas outras características gerais de sistemas, deve-se avaliar não
apenas uma funcionalidade específica, mas o geral da aplicação. O fato de
haver uma funcionalidade com grande processamento matemático
extensivo, como uma apropriação financeira de encargos ou o levantamento
de um saldo devedor, deve ser considerado no contexto do sistema como
um todo. Nesse caso, onde uma parte considerável do processamento
envolve esse tipo de lógica, deve-se considerar esse componente como
presente. Agora, caso seja uma aplicação em que esses processamentos
sejam periféricos e constituam uma pequena parte do conjunto total, deve-
se ponderar para menos o impacto na aplicação como um todo.

10. Reusabilidade
Descreve em que nível a aplicação e seu código foram especificamente
projetados, desenvolvidos e suportados para serem utilizados em outras
aplicações.
Pontue de acordo com as seguintes orientações:
0 Não há código reutilizável.
1 Código reutilizável é utilizado na aplicação.
2 Menos de dez por cento do código-fonte da aplicação foi
construído levando em consideração o uso em mais de
uma aplicação.
3 Dez por cento ou mais do código-fonte da aplicação foi
construído levando em consideração o uso em mais de
 uma aplicação.
4 A aplicação foi especificamente empacotada e/ou
documentada para fácil reutilização. Ela é customizada
pelo usuário no nível de código.
5 A aplicação foi especificamente empacotada e/ou
documentada para fácil reutilização. Ela é customizada
pelo usuário por meio de manutenção de parâmetros.
Considerações e Exemplos
Essa CGS é um requisito de qualidade do software, não um requisito
funcional. É difícil (senão impossível) de ser avaliada para uma aplicação
em que não estão disponíveis documentos do projeto ou o código-fonte.
Além disso, possui considerações técnicas que contrariam o objetivo
principal da técnica que é medir o software do ponto de vista do usuário
pela funcionalidade fornecida.

11. Facilidade de Instalação

Descreve em que nível a conversão de ambientes preexistentes
influencia o desenvolvimento da aplicação. Um plano e/ou ferramentas de
conversão e instalação foram fornecidos e testados durante a fase de teste
do sistema.
Pontue de acordo com as seguintes orientações:
0 O usuário não definiu considerações especiais, assim
como não é requerido nenhum setup para a instalação.
1 O usuário não definiu considerações especiais, mas é
necessário setup para a instalação.
2 Requisitos de instalação e conversão foram definidos
pelo usuário, e guias de conversão e instalação foram
fornecidas e testadas. Não é considerado importante o
impacto da conversão.
3 Requisitos de instalação e conversão foram definidos
pelo usuário, e guias de conversão e instalação foram
fornecidas e testadas. É considerado importante o
impacto da conversão.
4 Além do item 2, ferramentas de instalação e conversão
automáticas foram fornecidas e testadas.
5 Além do item 3, ferramentas de instalação e conversão
automáticas foram fornecidas e testadas.
Considerações e Exemplos
Esta é uma característica importante em projetos de sistemas que irão
substituir aplicações existentes, pontuando de 3 a 5 nesse caso.

12. Facilidade de Operação

Descreve em que nível a aplicação atende a alguns aspectos
operacionais, como inicialização, segurança e recuperação. A aplicação
minimiza a necessidade de atividades manuais, como montagem de fitas,
manipulação de papel e intervenção manual pelo operador.
Pontue de acordo com as seguintes orientações:
0 Não foi estabelecida pelo usuário outra consideração que
não os procedimentos de segurança normais.
1-4 Um, alguns ou todos os seguintes itens são válidos
para a aplicação. Selecione todos aqueles que sejam
válidos. Cada item tem um valor de um ponto, a exceção
de onde seja citado o contrário.
• 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, e não é necessária a
intervenção do operador (conte como dois itens).
• A aplicação minimiza a necessidade de montagem de
fitas.
• A aplicação minimiza a necessidade de manipulação de
papel.
5 Aplicação projetada para operação não assistida. Isto é,
não é necessário nenhuma intervenção do operador para
operar o sistema, que não seja a inicialização e término
da aplicação. A recuperação automática de erros é uma
característica da aplicação.
Considerações e Exemplos
Este também é um caso de defasagem nas diretrizes do IFPUG. Para
aplicações em que não há necessidade da figura do operador, mas apenas a
figura do usuário, a pontuação será 5.

13. Múltiplos Locais

Descreve em que nível a aplicação foi especificamente projetada,
desenvolvida e suportada para diferentes ambientes de hardware e de
software.
Pontue de acordo com as seguintes orientações:
0 Os requisitos do usuário não consideram a necessidade
de mais de um usuário/local de instalação.
1 Necessidade de múltiplos locais foi considerada no
projeto, e a aplicação foi projetada para operar apenas
nos mesmos ambientes de hardware e de software.
2 Necessidade de múltiplos locais foi considerada no
projeto, e a aplicação foi projetada para operar em apenas
 ambientes de hardware e de software similares .
3 Necessidade de múltiplos locais foi considerada no
projeto, e a aplicação foi projetada para operar em
ambientes diferentes de hardware e de software.
4 Adicionalmente aos itens 1 ou 2, plano de suporte e
documentação são fornecidos e testados para suportar a
aplicação em múltiplos locais.
5 Adicionalmente ao item 3, plano de suporte e
documentação são fornecidos e testados para suportar a
aplicação em múltiplos locais.
Considerações e Exemplos
Exemplos de ambientes de software similares: Windows 95, Windows
Me, Windows XP. Exemplos de ambientes de hardware similares: PC/486
Intel, PC/Pentium Intel, PC/Intel Celeron.

14. Facilidade de Mudanças

Descreve em que nível a aplicação foi especificamente desenvolvida
para facilitar a mudança de sua lógica de processamento ou estrutura de
dados.
As seguintes características podem ser válidas para a aplicação:

• São fornecidos mecanismos de consulta flexível, que

permitem a manipulação de pedidos simples; por
exemplo, lógica de e/ou aplicada a apenas um arquivo
lógico (conte como um item).
• São fornecidos mecanismos de consulta flexível, que
permitem a manipulação de pedidos de média
complexidade; por exemplo, lógica de e/ou aplicada a
mais de um arquivo lógico (conte como dois itens).
• São fornecidos mecanismos de consulta flexível, que
permitem a manipulação de pedidos complexos; por
exemplo, lógica de e/ou combinadas em um ou mais
arquivos lógicos (conte como três itens).
• Dados de controle do negócio são mantidos pelo usuário
por meio de processos interativos, mas as alterações só
têm efeito no próximo dia útil.
• Dados de controle do negócio são mantidos pelo usuário
por meio de processos interativos, e as alterações têm
efeito imediato (conte como dois itens).
Pontue de acordo com as seguintes orientações:
0 Nenhum dos itens anteriores.
1 Qualquer um dos itens anteriores.
2 Quaisquer dois itens anteriores.
3 Quaisquer três itens anteriores.
4 Quaisquer quatro itens anteriores.
5 Todos os cinco itens anteriores.
Considerações e Exemplos
Existem dois tipos de componente que estão avaliados nesta
característica geral do sistema: mecanismos de consulta flexível e
manutenção de dados de controle do sistema. O primeiro reflete consultas
em que o próprio usuário monta relatórios a partir dos dados disponíveis no
sistema. O segundo é referente à manutenção de parâmetros de forma on-
line por meio de manutenções de tabelas, por exemplo.

Questões para Fixação

1. Cite as características gerais de sistema.

2. Qual a fórmula do fator de ajuste?
3. Qual o impacto do fator de ajuste nos pontos de função?
4. Calcule o fator de ajuste para a seguinte configuração:
Pes Pes
CGS CGS
o o
Comunicação de Dados 3 5
Atualização On-Line
Processamento Distribuído 3 1
Complexidade de Processamento
Performance 3 3
Reusabilidade
Configuração Altamente Utilizada 3 2
Facilidade de Instalação
Volume de Transações 4 2
Facilidade de Operação
Entrada de Dados On-Line 5 2
Múltiplos Locais Facilidade de Mudanças
Eficiência do Usuário Final 3 2

5. Qual o menor e o maior valores que o fator de ajuste

pode assumir?

Bibliografia

1. BOEHM, B. et al. Software Cost Estimation with

COCOMO II . Prentice Hall, 2000.
2. GARMUS, D.; HERRON, D. Function Point
Analysis: Measurement Practices for Sucessful Software
Projects. Addison-Wesley, 2000.
3. IFPUG. Function Point Counting Practices Manual:
Release 4.3.1. International Function Point Users Group,
2005.
4. JONES, C. Applied Software Measurement. 2. ed.
Nova York: McGraw-Hill, 1996.
5. LOKAN, C. J. An Empirical Analysis of Function
Point Adjustment Factors . Australian Defence Force
 Academy, 1998. (Relatório Técnico CS03/98).
6. LOKAN, C. J.; ABRAN, A. Multiple View Points in
Functional Size Measurement . International Workshop
on Software Measurement, 1999.
7. LONGSTREET, D. Function Point Training and
Analysis Manual. Disponível em:
<http://www.SoftwareMetrics.com/freemanual.htm>.
Acesso em: 19 fev. 2013.
8. PRATER, M. D.; WILLOUGHBY, J. C. The Adequacy
of the Fourteen General Systems Characteristics as
Function Point Adjustment Factors . 1999. Tese -
School of Logistics and Acquisition Management of the
Air Force Institute of Technology, 1999.
9. VAZQUEZ, C. E. Cuidados na Aplicação da Análise de
Pontos de Função. Engenharia de Software Magazine ,
ano I, n. 5. Disponível em:
<http://www.fattocs.com.br/download/cuidados-
apf.pdf>. Acesso em: 10 out. 2008.
 7

Cálculo do Tamanho Funcional e

Documentar e Reportar

Figura 7.1: Cálculo do tamanho funcional.

Este passo da contagem de pontos de função envolve o cálculo final

para os três tipos de contagem, sendo projeto de desenvolvimento, projeto
de melhoria e aplicação. As fórmulas presentes neste capítulo são
apresentadas exatamente como descritas no manual do IFPUG, com os
mesmos nomes de variáveis. Mas não se preocupe com elas, exceto se
estiver pretendendo obter a certificação CFPS. No uso cotidiano da APF
esta etapa do processo é automatizada caso o analista use uma ferramenta
ou planilha de apoio à contagem dos pontos de função. Então, cabe à
ferramenta aplicar a fórmula correta e calcular os pontos de função das
funções identificadas pelo analista.

Projeto de Desenvolvimento
Componentes para o cálculo do número de pontos de função de um
projeto de desenvolvimento:

• Funcionalidade da aplicação requisitada pelo usuário

para o projeto: funções utilizadas após a instalação do
software para satisfazer as necessidades correntes do
negócio do usuário.
• Funcionalidade de conversão requisitada pelo usuário
para o projeto: funções disponíveis no momento da
instalação da aplicação para converter dados ou fornecer
outros requisitos de conversão especificados pelo
usuário, como relatórios de verificação de conversão.
Após a instalação essas funções são descartadas por não
serem mais necessárias.

Fórmula do Projeto de Desenvolvimento

DFP = (ADD + CFP)
Em que:
• DFP: tamanho do projeto de desenvolvimento.
• ADD: tamanho das funções entregues.
• CFP: tamanho das funções de conversão.
Exemplo 1
Como exemplo de aplicação das fórmulas deste capítulo será utilizado
um sistema de controle de ponto bem simplificado, similar ao do capítulo 3.
Todas as funções identificadas para o projeto de desenvolvimento estão
listadas no formulário de contagem apresentado em seguida. As funções de
conversão de dados também estão identificadas. Ele vai substituir um
sistema já existente, e as funções de conversão de dados importarão dados
do sistema que será substituído para o sistema novo.
Tabela 7.1: Planilha de contagem de pontos de função do projeto de
desenvolvimento do sistema de controle de ponto.

Tip T AR/T Complexidad Contribuiçã

Nome da função
o1 D2 R e o
AI
Pessoa (do controle de segurança) 3 1 Baixa 5
E
C
Login 4 1 Baixa 3
E
A
Apontamento 4 1 Baixa 7
LI
Apontamento - importação (conversão de E
4 1 Baixa 3
dados) E
E
Registro de ponto 4 2 Baixa 3
E
A
Justificativa 3 1 Baixa 7
LI
Justificativa - importação (conversão de E
3 1 Baixa 3
dados) E
C
Justificativa - seleção 6 2 Média 4
E
E
Justificativa - inclusão 5 2 Média 4
E
E
Justificativa - alteração 5 2 Média 4
E
E
Justificativa - exclusão 3 1 Baixa 3
E
C
Justificativa - consulta 5 2 Baixa 3
E
 Tip T AR/T Complexidad Contribuiçã
Nome da função
o1 D2 R e o
A
Horário padrão 3 1 Baixa 7
LI
Horário padrão - importação (conversão de E
3 1 Baixa 3
dados) E
E
Horário padrão - inclusão 4 2 Baixa 3
E
E
Horário padrão - alteração 4 2 Baixa 3
E
C
Horário padrão - consulta 4 2 Baixa 3
E
S 1
Relatório de horas 4 Alta 7
E 0
S
Relatório de justificativas 8 4 Alta 7
E
1 Total de pontos de função 82
1 Tipo: ALI, AIE, EE, SE e CE
2 TD: Número de tipos de dados
3 AR/TR: Número de arquivos referenciados/tipos de registro

Aplicando então a fórmula do projeto de desenvolvimento, tem-se:

DFP = ADD + CFP = 73 + 9 = 82 pontos de função

Projeto de Melhoria - IFPUG

O conceito de projeto de melhoria do IFPUG envolve apenas mudanças
em requisitos funcionais. Ou seja, funções novas, funções alteradas ou
funções excluídas da aplicação pelo projeto. O método do IFPUG não
contempla a medição de projetos que abranjam exclusivamente a mudança
de aspectos não funcionais do software. Vale destacar que a Análise de
Pontos de Função pode ser usada em cenários como a migração de
plataformas computacionais (por exemplo, downsizing ), em que a
contagem do projeto de desenvolvimento pode ser utilizada. O cuidado que
se deve observar nestes casos é quanto à taxa de entrega adequada (HH/PF),
afinal trata-se de outro processo produtivo diferente do desenvolvimento de
um novo sistema a partir do zero.
Componentes do cálculo dos pontos de função de um projeto de
melhoria:
• Funcionalidade da aplicação requisitada pelo usuário
para o projeto: funções adicionadas, alteradas ou
excluídas da aplicação pelo projeto de melhoria.
• Funcionalidade de conversão: funções disponíveis no
momento da instalação da aplicação para converter
dados ou fornecer outros requisitos de conversão
especificados pelo usuário, como relatórios de
verificação de conversão. Após a instalação essas
funções são descartadas por não serem mais necessárias.
Observe que não é necessário saber o número de pontos de função da
aplicação para determinar o tamanho do projeto de melhoria. Neste caso,
medem-se apenas as funções que serão afetadas pela manutenção. Caso a
contagem da aplicação já esteja disponível, a medição do projeto de
melhoria é facilitada, pois para as funções alteradas, basta trazê-las da
contagem da aplicação, ajustando uma eventual mudança de complexidade.
Para as funções excluídas é mais simples ainda, pois do mesmo jeito que
foram contadas na aplicação, serão contadas na melhoria.
As funções excluídas certamente reduzem o tamanho da aplicação, mas
também contribuem para aumentar o tamanho do projeto de melhoria.

Critérios para Avaliar Mudança em

Arquivos Lógicos
A diretriz básica para considerar que uma função do tipo dado (ALI ou
AIE) foi alterada é que ela seja modificada em sua estrutura, ou seja,
campos devem ser acrescentados, excluídos ou terem algum atributo
alterado para atender a um requisito de negócio. Neste caso deve-se contar
a funcionalidade toda no projeto de melhoria , não somente os campos
que foram afetados pela manutenção.
A seguir, são apresentados os procedimentos corretos para algumas
situações bem comuns.
• Se a mudança envolve apenas a alteração dos dados
armazenados em um arquivo, ou do domínio de valores
que um campo pode assumir, não se pode considerar que
o arquivo foi alterado.
• Se um campo foi adicionado ao arquivo lógico e ele não
é mantido ou referenciado na aplicação sendo contada,
então não houve alteração nessa aplicação. Para
confirmar se o campo é utilizado na aplicação ou não,
procure alguma transação que tenha sido criada ou
alterada para manipular esse campo.
• Se uma aplicação passa a manter ou referenciar um
campo já existente e que antes não era utilizado, então
considera-se que o arquivo lógico foi alterado para essa
aplicação (mesmo que não haja nenhuma alteração física
no arquivo).
• Se a aplicação passa a manter dados em um arquivo
lógico que antes era apenas referenciado de outra
aplicação, tem-se a mudança de tipo do arquivo lógico,
de AIE para ALI e este deve ser contado como alterado
no projeto de melhoria. O inverso (mudança de ALI para
AIE) também é válido. Estas situações não são tão
comuns.
• Se um campo é adicionado, alterado ou excluído de um
ALI ou AIE pertencente a várias aplicações e elas
 referenciam ou mantêm o campo, essa alteração de
funcionalidade é contada para cada uma das aplicações.
• Se um arquivo físico ou tabela foi criada pelo projeto de
melhoria, não necessariamente resultará em um novo
ALI ou AIE. Essa tabela pode ser também um novo tipo
de registro em um ALI ou AIE existente. Ou também
pode não representar um requisito funcional. Revise
sempre as regras de identificação das funções do tipo
dado.

Critérios para Avaliar Mudança em

Transações
Uma função do tipo transação é considerada modificada quando há
alteração em alguns dos seguintes itens:
• Tipos de dados: se eles foram adicionados, excluídos ou
alterados na função. Se houve a alteração apenas de
elementos visuais (manutenção cosmética), como
literais, cores e formatos, não se considera que a função
foi alterada.
• Arquivos referenciados: se eles foram alterados na
função, adicionados ou excluídos.
• Lógica de processamento: uma transação pode ter
várias lógicas de processamento. Basta que uma delas
seja alterada, excluída ou adicionada para que se
considere a função modificada. Embora a ordenação seja
a única lógica de processamento que não é suficiente
 para determinar a unicidade de uma transação, sua
alteração também determina uma alteração na função.
O mesmo alerta feito nas considerações para as funções do tipo dado
vale para as funções do tipo transação. Quando a função é alterada, conta-se
toda ela no projeto de melhoria, e não apenas os campos ou arquivos
referenciados que mudaram.
É muito comum que uma alteração em uma única rotina do sistema afete
várias transações. Não importa, por exemplo, se não houve alteração do
código-fonte da rotina específica da transação. Se ela utiliza uma rotina
compartilhada por várias transações e foi alterada, considera-se que todas as
transações foram modificadas. O que deve prevalecer é a visão lógica da
função, ou seja, a visão do usuário. Uma indicação das transações alteradas
são os conjuntos de casos de testes para o projeto de melhoria.
Como exemplo prático do caso anterior, imaginemos um sistema de
autoatendimento bancário que permite a realização de diversas transações
bancárias pelo cliente, e que em todas elas é feita a validação do cartão
inserido e da senha informada. Portanto, seja uma transação de saque,
transferência, pagamento ou investimento, haverá essa validação. A
validação, seguindo boas práticas de desenvolvimento de software, foi
codificada em um único ponto do código-fonte e é utilizada em todas as
transações. Suponha que o banco determine uma nova forma de validação
de cartão e senha. Neste caso a manutenção ocorrerá em um único ponto do
código-fonte e vai se refletir automaticamente em todas as transações.
Embora a alteração do código- -fonte do sistema seja em um único ponto, o
projeto de melhoria da aplicação irá contemplar todas as funções que
possuem essa validação de cartão e senha, pois conceitualmente todas
foram mudadas (e deveriam ser testadas).

Fórmula do Projeto de Melhoria - IFPUG

EFP = (ADD + CHGA + CFP + DEL)
Em que:

• EFP: número de pontos de função do projeto de

 melhoria.
• ADD: tamanho das funções incluídas pelo projeto de
melhoria.
• CHGA: tamanho das funções modificadas. Reflete as
funções depois das modificações.
• CFP: tamanho das funções de conversão.
• DEL: tamanho das funções excluídas pelo projeto de
melhoria.

Exemplo 2
Após a implantação do sistema de controle de ponto do exemplo 1, ele
sofrerá manutenção. O projeto de melhoria vai excluir funções da aplicação,
adicionar e alterar. Não há funções de conversão de dados envolvidas no
projeto.

• Funções adicionadas: AIE - Senha, SE - Relatório de

Ponto
• Funções alteradas: CE - Login
• Funções excluídas: SE - Relatório de Horas, SE -
Relatório de Justificativas
O formulário de contagem seguinte lista todas as funções que fazem
parte do escopo do projeto de melhoria.
Tabela 7.2: Contagem de pontos de função do projeto de melhoria
do sistema de controle de ponto segundo o IFPUG.

Depois do projeto de
Antes do projeto de melhoria
Tip melhoria
Descrição da função
o1 T AR/TR Complexidad P T AR/TR Complexidad P
D2 3 e F D2 3 e F
AI
Senha 2 1 Baixa 5
E
 Depois do projeto de
Antes do projeto de melhoria
Tip melhoria
Descrição da função
o1 T AR/TR Complexidad P T AR/TR Complexidad P
D2 3 e F D2 3 e F
S 1
Relatório de ponto 4 Alta 7
E 2
C
Login 4 1 Baixa 3 4 2 Baixa 3
E
Relatório de S
8 4 Alta 7
justificativas E
S 1
Relatório de horas 4 Alta 7
E 0
1 Tipo: EE, EI, CE, ALI e AIE
2 TD: Número de tipos de dados
3 AR/TR: Número de arquivos referenciados/tipos de registro

Aplicando a fórmula para determinação do tamanho do projeto de

melhoria, tem-se:
EFP = (ADD + CHGA + CFP + DEL = (12 + 3 + 0 + 14)
EFP = 29 pontos de função
Para o conceito de tamanho do projeto de melhoria segundo o IFPUG,
as funções excluídas, alteradas e adicionadas contribuem na mesma
proporção para o tamanho. Logo, se o projeto criar um relatório que vale 6
PF, contam-se 6 PF no projeto de melhoria. Se o projeto adicionar um
campo a um relatório existente que também vale 6 PF, contam-se 6 PF para
o projeto de melhoria. E finalmente, se o projeto excluir um relatório (que
vale 6 PF) da aplicação, contam-se também 6 PF no projeto de melhoria.
Analisando individualmente as transações contadas no projeto de
melhoria, soa estranho dar o mesmo peso no projeto para as funções
adicionadas, alteradas e excluídas, quando intuitivamente vê-se que, em
geral, há diferença significativa no esforço para criar, alterar ou excluir uma
função. Se levarmos em conta que o tamanho em PF será usado para
estimar o esforço (horas) do projeto, há a sensação de que a estimativa de
esforço da melhoria pelo tamanho medido conforme o IFPUG não
produzirá um resultado útil. Mas isso não é necessariamente uma verdade.
A questão é que o método do IFPUG para a melhoria não possui uma
granularidade tão fina em sua medição a ponto de dar um peso adequado à
extensão da manutenção que se faz em uma função. O que ele mede é se a
função foi alterada ou não. Não importa o quanto a função tenha sido
alterada .
Se o método é utilizado para estimar esforço, com uma taxa de entrega
(h/pf) definida por meio de uma análise rigorosa de um conjunto de projetos
passados e que contemple os vários tipos de demanda por melhoria que
costumam ocorrer na organização, é possível obter estimativas úteis. Porém,
quanto menor for o projeto de melhoria, mais chances de as estimativas
obtidas por esse método gerarem distorções (sub ou superestimar).
Para organizações que trabalham em um cenário de pouco
planejamento, de manutenções constantes, recorrentes e pequenas, fica
difícil obter uma boa estimativa de esforço a partir da medição da melhoria
pelo IFPUG. Porém, para organizações que trabalham sob o conceito de
planejamento de versões do produto de software a ser entregue, que
aglutinam várias solicitações de manutenção para serem atendidas numa
única versão, essas dificuldades citadas para trabalhar com a medição da
melhoria do IFPUG são minimizadas.
Uma forma de refinar o método é trabalhar na estimativa com
indicadores apropriados de taxa de entrega para cada parcela do projeto
(ADD, CHGA, DEL) em vez de utilizar uma única taxa de entrega para o
tamanho total do projeto. Este é um refinamento inspirado na abordagem da
NESMA para o projeto de melhoria (veja seção Projeto de Melhoria -
NESMA neste capítulo).

Aplicação
Existem duas fórmulas para calcular o número de pontos de função da
aplicação. Uma para a primeira contagem dos pontos de função da
aplicação e outra para recalcular seu tamanho após um projeto de melhoria
ter alterado sua funcionalidade.
Fórmula da Contagem Inicial da
Aplicação
AFP = ADD
Em que:

• AFP: tamanho da aplicação.

• ADD: tamanho das funções entregues.
Esta fórmula representa todas as funcionalidades requisitadas pelo
usuário de uma aplicação instalada. Essa aplicação pode ser um pacote de
software, um software recentemente desenvolvido e instalado ou um
software instalado há algum tempo e que já sofreu diversas manutenções.
Funções de conversão de dados não fazem parte da aplicação. Observe que
pela fórmula do projeto de desenvolvimento, se não houve conversão de
dados, o tamanho do projeto de desenvolvimento será igual ao da aplicação.
Exemplo 3
Aplicando então a fórmula da contagem inicial da aplicação à aplicação
instalada pelo projeto de desenvolvimento do exemplo 1, tem-se:
AFP = ADD = 73 pontos de função

Fórmula da Aplicação após Projeto de

Melhoria
AFPA = (AFPB + ADD + CHGA) - (CHGB + DEL)
Em que:

• AFPA: tamanho da aplicação após a melhoria.

• AFPB: tamanho da aplicação antes da melhoria.
• ADD: tamanho das funções incluídas pelo projeto de
melhoria.
• CHGA: tamanho das funções alteradas pelo projeto de
 melhoria depois de seu término.
• CHGB: tamanho das funções alteradas pelo projeto de
melhoria antes de seu término.
• DEL: tamanho das funções excluídas pelo projeto de
melhoria.
Quando um projeto de melhoria é concluído, o número de pontos de
função da aplicação deve ser atualizado para refletir as modificações na
aplicação. Deve-se destacar novamente que, mesmo que o projeto de
melhoria tenha funções de conversão de dados, elas não fazem parte da
aplicação. A funcionalidade da aplicação pode ser alterada das seguintes
formas:
• Nova funcionalidade adicionada aumenta o tamanho da
aplicação.
• Funcionalidade modificada aumenta, diminui ou não
afeta o tamanho da aplicação.
• Funcionalidade excluída diminui o tamanho da
aplicação.
Deve-se destacar que é possível que após um projeto de melhoria o
tamanho da aplicação continue o mesmo.
Exemplo 4
Usando a fórmula na aplicação alterada pelo projeto de melhoria do
exemplo 2, tem-se:
AFPA = (AFPB + ADD + CHGA) - (CHGB + DEL)
AFPA = (73 + 12 + 3) - (3 + 14) = 71 pontos de função

Projeto de Melhoria - NESMA

O método proposto pela NESMA é uma extensão refinada do método
apresentado pelo IFPUG. Ela introduz um fator de impacto (calculado de
acordo com a extensão da manutenção na função) que deve ser multiplicado
pela contribuição dos PFs de cada função no escopo da melhoria.

Fórmula do Projeto de Melhoria -

NESMA
EFP = Σ EFP ADDED + Σ EFP CHANGED + Σ EFP DELETED
Em que:

• EFP: número de pontos de função do projeto de

melhoria da NESMA.
• Σ EFP ADDED : número de pontos de função das funções
incluídas (incluindo conversão de dados) pelo projeto de
melhoria. O mesmo que o ADD + CFP na fórmula do
IFPUG. O fator de impacto neste caso é neutro (1,00).
• Σ EFP CHANGED : número de pontos de função (após a
melhoria) das funções modificadas, com o fator de
impacto aplicado a cada função.
• Σ EFP DELETED : número de pontos de função das funções
excluídas pelo projeto de melhoria, com o fator de
impacto aplicado a cada função.
Fator de Impacto de Funções
Excluídas/Reclassificadas
Quando se trata de uma função excluída, o valor do fator de impacto é
de 0,40. Por exemplo: se uma entrada externa de complexidade alta for
excluída pelo projeto, o método do IFPUG considera uma contribuição de 6
PF. Para a NESMA, deve-se aplicar o fator de impacto de 0,40 a este
tamanho, obtendo 2,4 EFP.
 O mesmo valor para o fator de impacto é utilizado quando uma função é
reclassificada (muda de tipo). Por exemplo, um AIE para uma aplicação que
passa a ser atualizado, virando um ALI. Ou uma função classificada como
uma CE, que deve efetuar cálculos, passando a ser classificada como SE.
Fator de Impacto para Arquivos Lógicos Alterados
Os arquivos lógicos (ALI/AIE) alterados têm o fator de impacto
ponderado pela relação entre a quantidade de TD antes e depois da
modificação na função e é descrito pela fórmula:

Determinado esse percentual de mudança, o fator de impacto é obtido

pela seguinte tabela:
Tabela 7.3: Fator de impacto para ALI/AIE.

≤100 >100
(%) Mudança de TDs ≤ 1/3 (x 100%) ≤ 2/3 (x 100%)
% %
Fator de impacto 0,25 0,50 0,75 1,00

Para ilustrar a aplicação do fator de impacto nos arquivos lógicos vamos

usar um ALI Produto (com 15 TDs e 1 TR). De acordo com o IFPUG este
ALI possui 7 PFs. Caso o usuário solicite a adição de mais um atributo a
este ALI, ele passará a ter 16 TDs e 1 TR e serão contabilizados 7 PFs para
a melhoria IFPUG. Mas seguindo a abordagem da NESMA, calcula-se o
fator de impacto a ser aplicado ao arquivo que está sendo alterado. A
porcentagem de mudança de TDs é 1/15 × 100, que resulta em 6,67%. Para
esta porcentagem de mudança a Tabela 7.3 aponta um fator de impacto de
0,25. Consequentemente para o projeto de melhoria NESMA serão
contabilizados 7 PFs × 0,25 (o fator de impacto calculado), resultando em
1,75 EFPs.
Fator de Impacto para Transações Alteradas
As transações (EE/SE/CE) alteradas têm o grau de mudança ponderado
pela relação entre a quantidade de TD/AR antes e depois da modificação na
função, conforme as seguintes fórmulas:

De maneira análoga aos arquivos, com base nesses dois percentuais o

fator de impacto é determinado pelo enquadramento na seguinte tabela:
Tabela 7.4: Fator de impacto para EE/SE/CE.

% Mudança de TDs
% Mudança de ARs ≤ 2/3 (× 100%) ≤ 100% > 100%
≤ 1/3 ( × 100%) 0,25 0,50 0,75
≤ 2/3 ( × 100%) 0,50 0,75 1,00
≤ 100% 0,75 1,00 1,25
> 100% 1,00 1,25 1,50

Para ilustrar a aplicação do fator de impacto nas transações, vamos usar

uma EE Incluir Produto (com 17 TDs e 1 AR). De acordo com o IFPUG,
essa EE possui 4 PFs. Caso o usuário solicite a adição de mais um campo a
essa EE e uma nova validação que implique acessar outro arquivo lógico,
esta passará a ter 18 TDs e 2 TR e serão contabilizados 6 PFs para a
melhoria IFPUG. Mas seguindo a abordagem da NESMA, calcula-se o fator
de impacto a ser aplicado à transação que está sendo alterada. A
porcentagem de mudança de TDs é 1/17 × 100, que resulta em 5,88%. A
porcentagem de mudança de ARs é 1/1 × 100, que resulta em 100%.
Para estes percentuais de mudança (%TD = 5,88% e %AR = 100%) a
Tabela 7.4 aponta um fator de impacto de 0,75. Consequentemente para o
projeto de melhoria NESMA serão contabilizados 6 PFs × 0,75 (o fator de
impacto calculado), resultando em 4,5 EFPs.

Considerações sobre o Fator de Impacto

Embora a ideia do fator de impacto tenha méritos e seja de fato um
refinamento em relação ao método do IFPUG, o modelo ainda não é
perfeito. O fator de impacto oscila apenas em função de mudanças de tipos
de dados e arquivos referenciados. Quando as manutenções envolvem
apenas alteração de lógica de processamento nas transações, o fator de
impacto fica fixo em 25%, independente do tamanho dessa manutenção.
Para muitas organizações, esse tipo de manutenção costuma ser muito
frequente (senão a maioria). Então, deve-se estar atento que, nestas
situações, o fator de impacto de fato não esteja medindo fielmente o
impacto da manutenção.
Outra questão é que, embora em tese o fator de impacto possa oscilar de
0,25 a 1,50, na prática esta variação costuma ser menor. O perfil das
manutenções costuma ser mais constante nas organizações; por exemplo, a
realidade de muitas organizações é de manutenções contínuas e pontuais,
sem muito planejamento. Logo, o fator de impacto acaba oscilando num
intervalo mais estreito: 0,25 a 0,50 ou 0,75.

Manutenções “Cosméticas”
Outra diferença entre o método da NESMA e o do IFPUG é com relação
a alterações “cosméticas” nas transações. Para o método da NESMA isso
entra no escopo da contagem, ao contrário do IFPUG que considera uma
manutenção perfectiva e, portanto, não ponderado pela APF.
A manutenção cosmética é caracterizada por mudança apenas na
apresentação da função ao usuário ou na forma como a entrada de dados é
realizada, sem nenhuma alteração na lógica de processamento. Exemplos:
mudança de ordem (posicionamento ou tabulação) dos campos, formatação
de rótulos ou campos (cores, fontes, tamanho etc.). Para essa manutenção
não há alteração em TDs e ARs, portanto o fator de impacto é 0,25.

Custo x Benefício da Adoção do Método

NESMA para Melhorias
Embora o método entregue uma medida de granularidade mais fina que
o método do IFPUG, isso não se obtém de graça. O tempo gasto para fazer
a medição pelo método da NESMA é maior, podendo chegar ao dobro do
tempo quando comparado ao método do IFPUG. Além disso, há a exigência
de se ter uma documentação de requisitos mais detalhada para conseguir
aplicá-lo.

Pontos de Função de Teste

O cálculo dos pontos de função da melhoria visa derivar o esforço
relativo às atividades de especificação, construção, teste e outras
relacionadas especificamente às funções incluídas nesse escopo. O escopo
dos testes pode ser bem maior que o escopo da melhoria. Por exemplo, pode
se decidir testar algumas funções, ainda que elas não tenham sido
modificadas. Sendo assim, a NESMA abre a possibilidade de incluir na
medição funções que não foram modificadas, mas que devem ser testadas,
proporcionando, em tese, uma estimativa mais real do esforço total do
projeto.
O tamanho das funções a serem testadas é medido em pontos de função
de teste (TFP). Para a determinação do número de TFPs o fator de impacto
por função não é considerado na contagem. Também não há distinção se
uma função foi adicionada ou modificada. Funções excluídas não são
consideradas no tamanho dos pontos de função de teste (TFP).

Estimativa de Esforço da Melhoria

A estimativa do esforço das atividades de testes e melhoria é feita pela
utilização de indicadores de taxa de entrega (h/pf) específicos para as
funções incluídas no escopo e ponderadas pelas regras do ponto de função
de melhoria (EFP) e aquelas incluídas e ponderadas pelas regras do ponto
de função de teste (TFP). A fórmula seguinte descreve esse processo:
Esforço (HH) = (EFP × HH/EFP) + (TFP × HH/TFP)

Documentar e Reportar a Medição

 Figura 7.2: O processo de medição: documentar e reportar o
resultado da medição.

Imagine que você leve o seu carro para fazer uma revisão na oficina.
Após avaliação da oficina você é informado de que o orçamento total da
revisão ficou em R$2.000,00. Qual a sua decisão, autorizar ou não o
serviço? Na prática não é possível tomar uma boa decisão sem conhecer
todos os itens que farão parte da revisão e que computaram neste valor total.
Se você é informado de que a revisão será apenas a troca de óleo
provavelmente, você não aprovará o orçamento, pois este valor é caro,
considerando apenas esse serviço. Porém, se você é informado que tem de
ser trocado o óleo, os quatro pneus, correia dentada, filtro de combustível,
escapamento, catalisador, talvez julgue o valor do orçamento adequado e
autorize o serviço.
O ponto que queremos destacar é que nem sempre o que interessa na
contagem de pontos de função é apenas o número final que reflete o
tamanho medido. Não basta entregar ao cliente o número final da medição
(ou estimativa); é preciso que junto seja entregue também toda a memória
de cálculo do processo de análise que resultou naquele número. Caso
contrário, quem recebe a informação da medição não tem como se certificar
de que o número final apresentado é correto ou não. O mais comum é que a
medição seja entregue com a planilha de contagem final, permitindo que
todo processo de análise seja verificado se necessário por quem usará o
resultado daquela medição.
 A documentação da contagem tem o propósito de agregar valor à
medição que será feita, facilitando um eventual processo de auditoria e
também minimizando erros do analista responsável pela medição. O nível
de documentação da medição pode variar bastante (implicando também em
mais ou menos esforço na medição). Esse nível de detalhamento da
documentação deve estar alinhado ao propósito da contagem. Por exemplo,
se o propósito for estimar uma ordem de grandeza de custo para o projeto,
qual o sentido de detalhar ao máximo a medição? Uma vez que a própria
medição não necessita de grande precisão para este caso, o nível de
documentação também não deveria ser tão minucioso.
É importante lembrar que um dos objetivos principais do processo de
medição é ser simples. Logo, o nível de documentação deve ser bem dosado
para que equilibre o esforço que se gastará na medição e a necessidade de
informação que agregue valor a esta.
O nível de documentação deve estar previamente acordado entre as
partes interessadas na medição, ponderando-se os custos e benefícios
envolvidos. Um nível de documentação alto na medição implica mais
tempo e custo para essa atividade. Cada organização deve estabelecer os
seus padrões de documentação da medição.

Organização das Funções

A forma de organizar as funções em uma contagem de pontos de função
é um elemento crucial para a sua legibilidade. Quanto mais fácil for a
leitura da contagem, menor a chance de se cometer erros durante a medição
(seja por omissão ou por duplicidade de funções) e mais fácil é o seu
processo de auditoria. O princípio básico é agrupar as funções de forma
lógica (do ponto de vista de negócio). E em geral o analista não precisa ter o
trabalho de definir essa organização, pois normalmente a documentação que
serve de base para a medição já organiza as funções de acordo com este
princípio.
Vários critérios de organização costumam estar disponíveis na
documentação para que o analista possa aproveitá-los:

• Manual do Usuário: o índice, com seus capítulos,

 seções e subseções seguem uma organização lógica que
pode servir para organizar as funções na contagem.
• Menu do Sistema: para sistemas prontos e com
interface com usuário final, o menu é o critério mais
óbvio e direto para organização de funções na contagem.
• Diagrama de Casos de Uso: os casos de uso também
fornecem uma boa ideia de como organizar as funções na
contagem.
As dicas anteriores são sugestões de organização, mas que não se
aplicam a todos os casos. Existem sistemas sem interface com usuário final;
logo, sem menu. Então cabe ao analista definir um critério de organização.
Veja a seguir um exemplo de organização para o Sistema de Controle de
Ponto.
 Figura 7.3: Contagem do sistema de controle de ponto organizada
de forma alfabética.

No exemplo anterior tem-se uma contagem organizada, mas não no

princípio básico que citamos: organização lógica do ponto de vista de
negócio. A organização do exemplo anterior não favorece facilidade de
leitura para quem precisar entender a contagem. A seguir listamos algumas
diretrizes para a organização de funções:

• Segregar as funções de dados e de transações é uma boa

prática: assim como já é feito na análise de requisitos e
de sistemas, que trabalha documentos e modelos
específicos para os dados e processos do sistema. É
comum usar um modelo de dados (se disponível) para
apoiar a identificação de arquivos lógicos. Tê-los
organizados em uma seção específica da contagem (e
não espalhados junto com as transações) facilita a leitura
da contagem.
• Segregar ALIs de AIEs também pode ser uma boa
alternativa: quando a quantidade de arquivos na
contagem for grande (maior que dez), organizar os ALIs
e AIEs em seções diferentes melhora a organização da
contagem. É normal que as interfaces com outras
aplicações sejam especificadas separadamente em
documentos diferentes ou seção específica do documento
de requisitos do projeto. Segregar ALIs de AIEs apenas
segue esta abordagem de organização dos requisitos.
• Segregar funções de conversão das demais: os requisitos
de transição costumam também ter uma especificação
em separado. Como as funções de conversão não fazem
 parte do tamanho da aplicação, tê-las segregadas na
medição do projeto facilita a atualização do tamanho do
sistema.
• Agrupar transações por tipo (EE, SE, CE) não tem
sentido do ponto de vista de negócio, inclusive pode
dificultar a legibilidade da medição.
Vejamos a mesma contagem do exemplo anterior, agora organizada de
forma diferente.
 Figura 7.4: Contagem do sistema de controle de ponto organizada
de forma lógica.

Sem necessariamente que o analista tenha mais trabalho, pode-se

produzir uma contagem que seja mais fácil de entender. Neste pequeno
exemplo talvez o leitor não veja grandes diferenças. Contagens pequenas
(até 100 PF, ou que não ocupe mais que uma página) são mais fáceis de
entender, ainda que estejam com organização ruim. Mas a preocupação com
a organização das funções torna-se mais crítica quanto maior for a
contagem.

Nomenclatura das Funções

A nomenclatura adotada para as funções exerce também um papel
importante na documentação da contagem. Bons nomes para as funções
também facilitam a leitura da contagem e minimizam a chance de erros.
Vejamos um exemplo.
 Figura 7.5: Contagem do sistema de controle de ponto usando
nomes físicos.

O exemplo anterior é a mesma contagem do sistema de controle de

ponto, com o mesmo resultado final, porém usando nomes físicos de tabelas
e programas para as funções. Este tipo de padrão de nomenclatura fere a
filosofia da APF, que é abstrair da implementação do software. Neste
exemplo, apenas aqueles que conhecem aspectos internos do sistema
conseguirão entender o que significam as funções contadas. Esta não é uma
boa abordagem de nomenclatura.
O princípio básico para nomear funções é que o nome seja mais
representativo do que a realização da função e que seja único. Não pode
haver duas funções com o mesmo nome em um mesmo sistema ou projeto.
A documentação usada para a contagem costuma fornecer boas sugestões
de nomes para as funções, o que poupa parte do trabalho da contagem.
Modelos de dados (lógicos ou conceituais) ou modelos de classe já trazem
boas sugestões de nomes para os arquivos lógicos. As opções de menu,
títulos de telas e relatórios ou nomes dos casos de uso são também boas
opções de nomes para as transações. Quando não for o caso, cabe ao
analista fornecer os nomes mais adequados.
Uma sugestão para nomear os arquivos lógicos é usar substantivos,
numa abordagem parecida com os nomes de entidades em um modelo de
dados (para aqueles que são familiarizados com modelagem de dados). Não
use verbos no nome do arquivo lógico para não confundi-lo com uma
transação. Por exemplo, é melhor ter um ALI de nome Cliente do que
Armazenar Cliente. A última opção pode levar alguém a pensar que se trata
da função que cadastra um novo cliente, o que não é o caso. Jamais use
nomes físicos de tabelas para nomear os arquivos lógicos. O que é
melhor de entender: CDTB01 ou Contrato de Desconto?
Quando o arquivo lógico tiver mais de um subgrupo, avalie usar um
nome composto de tal forma a deixar explícito no nome os subgrupos que
compõem o arquivo. Por exemplo, Pedido e Itens, em vez de apenas Pedido.
Se o arquivo lógico tiver muitos subgrupos, essa abordagem do nome
composto ficará pouco prática, pois o nome do arquivo ficará muito grande.
Então use um nome simples ou uma composição dos subgrupos mais
relevantes.
Para os AIEs, além das orientações anteriores, adicione ao seu nome um
complemento informando o sistema de origem que mantém esses dados.
Exemplos: Imposto e Alíquota (da Aplicação Contábil) e Cadastro Pessoa
Física (da Receita Federal do Brasil). Se um sistema possui integração com
diversos outros, é provável que ele tenha vários AIEs em sua contagem, e
ao nomear desta forma os AIEs, você deixa explícito para qualquer um que
vá olhar a contagem qual é a origem daqueles dados. Caso contrário, a
pessoa teria de procurar cada AIE em todas as integrações para verificar se
a contagem está correta neste aspecto.
Não use o nome do sistema origem para nomear o AIE, pois se houver a
necessidade de acesso a vários grupos de dados, vários AIEs deverão ser
contados e não poderão ter o mesmo nome. Use sim o nome que o arquivo
teria na contagem daquele sistema origem. Por exemplo, um AIE chamado
RH apenas diz que há uma integração com o sistema de RH, mas um AIE
chamado Funcionário (do RH) torna tudo mais claro.
 Uma sugestão para nomear as transações, caso a documentação
disponível não forneça boas opções, é usar verbos padronizados no
infinitivo associado a um objeto relacionado à ação que esteja ocorrendo.
Para muitos casos o próprio verbo já define o tipo da transação. Por
exemplo, Cliente - Incluir (EE), Cliente - Alterar (EE), Cliente - Listar
(CE), Cliente - Excluir (EE), Cliente - Consultar (CE), Cliente - Exportar
(CE/SE). Jamais use nome de programa para nomear transações. Qual
nome melhor define um processo: KCB57 ou Baixar Títulos?

Questões para Fixação

1. O tamanho da aplicação afeta diretamente o tamanho de

um projeto de melhoria? Por quê?
2. Por que é possível que o tamanho de uma aplicação não
se altere após um projeto de melhoria?
3. Quantos pontos de função possui uma aplicação com
três arquivos lógicos internos de complexidade baixa,
doze entradas externas de complexidade alta, quatro
consultas externas de complexidade baixa e duas saídas
externas de complexidade alta?
4. Supondo que a aplicação do caso anterior sofra uma
manutenção na qual são adicionadas uma saída externa
de complexidade média e uma consulta externa de
complexidade alta, duas entradas externas são excluídas,
uma consulta externa tem sua complexidade alterada para
alta e os arquivos lógicos internos são também alterados,
mas sem que sua complexidade se altere. Qual o tamanho
desse projeto de melhoria IFPUG?
5. Qual o tamanho da aplicação do caso anterior após o
projeto de melhoria?

Bibliografia

1. GARMUS, D.; HERRON, D. Function Point

Analysis: Measurement Practices for Sucessful Software
Projects . Addison-Wesley, 2000.
2. IFPUG. Function Point Counting Practices Manual:
Release 4.3.1. International Function Point Users Group,
2010.
3. LONGSTREET, D. Function Point Training and
Analysis Manual . Disponível em:
<http://www.SoftwareMetrics.com/freemanual.htm>.
Acesso em: 19 fev. 2013.
4. NESMA. Function Point Analysis for Software
Enhancement: Versão 2.2.1. Disponível em:
<http://www.nesma.n l>. Versão traduzida para o
português disponível em
<http://www.fattocs.com.br/artigos/APF-Melhoria-
NESMA.pdf>. Acesso em: 9 abr. 2012.
 8

Estudos de Caso

Introdução
Este capítulo fornece estudos de caso para que sejam exercitados os
tipos de contagem da análise de pontos de função. Como regra geral,
abstraia da análise e da modelagem do sistema apresentado, concentrando-
se apenas nas funcionalidades descritas nos enunciados.
O tipo de contagem, o propósito, o escopo e a fronteira da aplicação
estão definidos no enunciado de cada exercício. É preciso identificar as
funções dos tipos dado e transação, classificá-las, calcular o tamanho
funcional e, opcionalmente, o fator de ajuste e os pontos de função
ajustados.
São quatro estudos de caso: contagem de aplicação, contagem de projeto
de desenvolvimento, contagem de projeto de melhoria e estimativa. Você
pode utilizar uma planilha eletrônica para auxiliá-lo na tarefa, a qual pode
ser obtida gratuitamente no site da Editora Érica.

Dica
Para a identifi cação das funções do tipo dado, não se
restrinja ao modelo de entidades e ao dicionário de dados;
leia todos os requisitos da aplicação. O modo como as
 transações operam os dados traz informações relevantes à
correta identifi cação e classifi cação dos arquivos lógicos.

Contagem de Aplicação
Neste estudo o objetivo é contar os pontos de função de uma pequena
aplicação de faturamento de uma empresa de serviços, a ACME, e
consolidar todos os conceitos teóricos abordados no curso por meio de um
estudo de caso simples.
Lembre-se de que esta é uma aplicação em uso pela empresa e não se
deve entrar no mérito da análise e modelagem do sistema ou do negócio.
Sua função é apenas medir o tamanho funcional. Não se preocupe em
avaliar se os requisitos estabelecidos fornecem a melhor solução ao usuário,
pois isso é papel do analista de negócios.

Características da Aplicação
O sistema é uma aplicação típica do Windows. Foi desenvolvida
internamente na empresa em linguagem de quarta geração e utiliza banco de
dados relacional (MS-Access). É uma aplicação monousuário e não
funciona em rede.
Para a implantação e operação da aplicação um novo computador seria
adquirido. Nessa época, o gerente de informática da ACME alertou os
usuários de que poderiam existir problemas de performance quando a base
de dados ficasse muito volumosa. Os usuários alegaram que isso não seria
crítico e o custo para utilizar um outro gerenciador de banco de dados não
compensaria, pois o volume de faturamento da empresa era pequeno,
portanto tal situação demoraria demais a ocorrer.
Para reduzir o custo, a aplicação foi desenvolvida sem o uso de ajuda
on-line e instalador ( setup ). O fato de a ACME possuir uma biblioteca
para telas de cadastro genéricas também ajudou a baratear o custo e a
padronizar as telas. O backup é feito pelo usuário fora da aplicação - o
banco de dados é copiado para outra mídia por meio do sistema
operacional.
Diagrama Entidade-Relacionamento

Figura 8.1: Modelo de Dados Físico da Aplicação de Faturamento

da ACME.

Dicionário de Dados
UF

CIDADE

CLIENTE
CONTATO CLIENTE

IMPOSTO (Mantido pela aplicação contábil)

ALÍQUOTA IMPOSTO (Mantido pela aplicação contábil)

NOTA FISCAL
ITEM NOTA FISCAL

IMPOSTO NOTA FISCAL

Transações
CADASTRO DE CIDADES (TR0306)
 Figura 8.2: Tela do cadastro de cidades.

• Opções da barra de ferramentas: inclusão, alteração,

exclusão, ordenação (código ou nome) e busca direta
pelo campo da ordenação (o nome pode ser informado
parcialmente e é emitida uma mensagem quando o valor
não é encontrado).
• O nome e o estado são de preenchimento obrigatório,
sendo o estado preenchido através da escolha de uma
opção na caixa de seleção.
• O identificador da cidade é gerado automaticamente e
exibido após o botão Novo ser pressionado.
• O campo ISS (alíquota de retenção na fonte), quando
preenchido, indica que o valor relativo ao imposto sobre
serviços será retido na cidade do cliente e não na cidade
sede do prestador de serviços.
• Não é permitido excluir uma cidade se houver um cliente
 ou contato relacionado a essa cidade.
CADASTRO DE CLIENTES (TR0303)

Figura 8.3: Aba 1 da tela do cadastro de clientes.

• A barra de ferramentas possui opções para inclusão,

alteração, exclusão, navegação entre registros (primeiro,
próximo, anterior e último), consulta rápida e pesquisa
de clientes, trn 0310 da Figura 8.7. Na navegação entre
registros é emitida uma mensagem quando o primeiro ou
o último registro é atingido.
• Os campos obrigatórios são razão social, CNPJ e
endereço.
• O identificador do cliente é gerado automaticamente
 pelo sistema.
• Há uma barra de ferramentas específica para inclusão,
alteração, exclusão, navegação (primeiro, próximo,
anterior e último) das pessoas de contato do cliente,
entretanto as alterações na aba de contatos somente são
efetivadas em conjunto com os dados do cliente.
• O cadastramento de contatos para o cliente é opcional.
• Dois clientes não podem ter o mesmo CNPJ, tampouco a
mesma razão social.
• Os campos CNPJ, Inscrição Municipal e Inscrição
Estadual possuem validações de dígito verificador para
garantir a entrada de dados válidos.

Figura 8.4: Aba 2 da tela do cadastro de clientes.

 Figura 8.5: Aba 3 da tela (campo Observações) do cadastro de
clientes com a tela de consulta rápida sobreposta.

• Os campos data possuem a opção de escolha por meio de

um calendário.
• Os campos Cidade (na aba de cliente e contato) são
editados por meio da escolha em uma lista (que exibe o
nome da cidade e a UF), conforme a Figura 8.6.
 Figura 8.6: Lista de cidades.

• Os campos UF das abas de cliente e contato não são

editáveis. São preenchidos automaticamente após a
escolha da cidade.
• Antes da exclusão do cliente é solicitada uma
confirmação da operação.
• Não é permitido excluir um cliente se houver notas
fiscais associadas a ele.
• Se o cliente for excluído, todos os contatos do cliente
também serão excluídos.
• A consulta rápida só estara disponível quando o cadastro
não estiver em modo de edição. Ela permite reordenar o
cadastro ou pelo campo nome ou pelo campo código e
também pesquisar pelo campo corrente da ordenação (o
valor do campo pode ser parcialmente informado). Se
não houver registros, é emitida uma mensagem.
• Ao clicar em uma linha da lista de resultados da consulta
rápida, abre-se a tela do cadastro de clientes posicionada
no registro corrente da pesquisa.
PESQUISA DE CLIENTE (TR 0310)
Figura 8.7: Tela de filtro da pesquisa de clientes.
 Figura 8.8: Tela de resultados da pesquisa de clientes.

• A barra de ferramentas possui opções para aplicar e

limpar (fecha a tela de resultados e limpa os campos) o
filtro de seleção e uma opção Detalhes que remete à tela
do cadastro de clientes posicionada no registro corrente
da pesquisa.
• Não existem campos obrigatórios para preenchimento do
filtro.
• O campo nome do cliente na tela de filtro pode aceitar
parte do nome para a pesquisa.
• O campo Cidade na tela de filtro é editado por meio da
seleção da cidade na lista (que exibe o nome da cidade e
 a UF).
• Ao aplicar o filtro, abre-se uma segunda tela com os
registros apresentados no formato de uma grade. Se não
houver registros, é emitida uma mensagem.
NOTA FISCAL (TR0319)

Figura 8.9: Aba 1 da tela do cadastro de notas fiscais.

 Figura 8.10: Aba 2 da tela do cadastro de notas fiscais.

• A barra de ferramentas possui opções para inclusão,

alteração, exclusão, navegação entre registros (primeiro,
próximo, anterior e último) e impressão da nota fiscal.
Na navegação entre registros é emitida uma mensagem
quando o primeiro ou o último registro é atingido.
• O cliente é informado por meio da seleção de uma lista
que exibe o seu nome fantasia, conforme a Figura 8.11.
 Figura 8.11: Lista de clientes.

• Após a seleção do cliente, o sistema busca os dados de

endereço e o faturamento total realizado para aquele
cliente nos últimos 12 meses e exibe esses dados em um
campo abaixo do nome do cliente . Também pergunta se
deseja repetir nessa nova nota fiscal os dados
cadastrados na última nota, permitindo sua alteração.
• Todos os campos são obrigatórios. O campo motivo do
cancelamento só é habilitado para edição quando a nota
for cancelada.
• Quando a nota é cadastrada, sua situação fica
automaticamente em “edição”. Após ser impressa, sua
situação muda para “faturada”. Quando em situação
“faturada”, a nota fiscal pode ser alterada para
“cancelada”.
• À medida que os itens da nota são informados na aba 1,
o sistema recupera os impostos incidentes na nota (com
as alíquotas vigentes) e calcula os valores a serem
aplicados. A aba 2 exibe o nome do imposto, suas
alíquotas e o valor incidente.
• A nota fiscal pode ser cadastrada e impressa (faturada)
em momentos distintos.
• Os campos identificador da nota, número da nota, valor
da nota, valor total do item, valor do imposto são
calculados pelo sistema.
• Os campos data possuem a opção de escolha por meio de
um calendário.
• Antes da exclusão da nota fiscal é solicitada uma
confirmação da operação.
• Se a nota fiscal for excluída, todos os seus itens e
impostos incidentes também devem ser excluídos. Uma
mensagem é emitida ao final da exclusão.
• Há uma barra de ferramentas específica para inclusão,
alteração, exclusão, navegação (primeiro, próximo,
anterior e último) dos itens da nota fiscal, entretanto as
alterações nos itens somente são efetivadas em conjunto
com o cabeçalho da nota fiscal.
• O número da nota fiscal é gerado automaticamente (e
exibido) pelo sistema somente após a impressão da nota.
• Após a nota fiscal ser impressa o sistema pergunta se a
impressão foi OK. Se OK, a situação da nota fiscal é
alterada para “faturada”; caso contrário, é alterada para
“cancelada”.
• A nota fiscal é impressa em quatro vias, conforme layout
apresentado em seguida.
 Figura 8.12: Formulário para impressão da nota fiscal (os campos
com valores já estão pré-impressos no formulário, não são
impressos pelo sistema).

• Adicionalmente, os impostos marcados como “Imprimir”

na aba 2 têm os campos descrição para impressão e valor
impressos no corpo da nota.
Projeto de Desenvolvimento
O banco JDK decidiu modernizar o seu serviço de fornecimento de
vale-alimentação. O carnê de tickets em papel será substituído por cartão
magnético. As compras em supermercados devem ser pagas agora com o
cartão magnético em vez de tickets. Atualmente existe um sistema
responsável por gerenciar toda a retaguarda do serviço (convênio com
estabelecimentos comerciais, contratos com empresas cliente, emissão de
cartões para usuários do benefício etc.). Será construído um novo sistema
para a autorização dos pagamentos das compras efetuadas agora
somente de forma on-line, com os cartões emitidos pelo sistema de
retaguarda. Esse novo sistema utiliza algumas informações do sistema
existente e deve processar transações originadas no sistema de retaguarda,
nos estabelecimentos comerciais conveniados e na Internet. Não haverá
interação direta de um usuário final com o sistema. As funções que esse
sistema vai desempenhar são:

Consulta de saldo Troca de senha

Extrato Reinicialização de senha
Crédito Bloqueio de cartão pelo beneficiário
Saque Bloqueio de cartão pelo banco
Estorno de saque Desbloqueio de cartão

Requisitos de Dados
As tabelas sinalizadas com * já existem no sistema de retaguarda e
apenas os atributos usados pelo sistema autorizador foram listados (sendo
alguns campos criados para serem usados exclusivamente pelo sistema
autorizador). Assuma que a tabela de cartões é um subgrupo de dados da
tabela de beneficiários. A tabela Transação foi criada com a previsão de ser
usada em algumas consultas que serão construídas posteriormente no
sistema de retaguarda.

Tabela Campo
Id. do estabelecimento
*Estabelecimento Comercial Nome do estabelecimento
Situação
Id. da empresa
*Empresa Cliente
Situação
Id. do beneficiário (CPF)
Id. da empresa
*Empregado Beneficiário Nome do empregado
Senha
Saldo
Id. do beneficiário
Número do cartão
Cartão
Data de validade
Situação
 Tabela Campo
Data
Código da transação
Número sequencial da transação
Situação da transação
Movimento de Transações
Id. do estabelecimento de origem
Número do terminal
Valor da transação
Identificador do beneficiário
Código da transação
Transação
Nome da transação

Detalhamento das Funções

Consulta de Saldo: essa transação, proveniente de um supermercado ou
da Internet, verifica se o estabelecimento comercial de origem, o
beneficiário e o cartão existem. Verifica também a senha, a situação e a data
de validade do cartão. Se número do terminal for maior que 99, recusa a
transação. Se todas as validações estiverem corretas, o nome do beneficiário
e o saldo são devolvidos nos dados de saída. Um registro também é criado
na tabela de movimento de transações (com a situação “ativa”); caso
contrário, um código de resposta de erro é devolvido.

Dados de entrada Dados de saída

Código da transação - constante “SLD” Código da transação - constante “SLD”
Estabelecimento comercial de origem Código de resposta
Número do terminal de origem Nome do beneficiário
Identificador do beneficiário Saldo disponível
Número do cartão
Senha

Extrato: essa transação, proveniente da Internet, verifica se o

estabelecimento comercial de origem, o beneficiário e o cartão existem.
Verifica também a senha, a situação e a data de validade do cartão. Se
número do terminal for maior que 99, recusa a transação. Se todas as
validações estiverem corretas, é montado um texto de extrato com o saldo
atual, obtido da tabela de beneficiários, e seus últimos lançamentos, obtidos
da tabela de movimento de transações. A tabela de transações é usada para
decodificar os lançamentos na tabela de movimento para impressão do
nome da transação no extrato. Um registro também é criado na tabela de
movimento (com a situação “ativa”). Caso haja algum problema que impeça
o processamento, um código de resposta indicando o erro é devolvido.

Dados de entrada Dados de saída

Código da transação - constante “EXT” Código da transação - constante “EXT”
Estabelecimento comercial de origem Código de resposta
Número do terminal de origem Texto para impressão
Identificador do beneficiário
Número do cartão
Senha

Saque: essa transação, proveniente de um supermercado, verifica se o

estabelecimento comercial de origem, o beneficiário e o cartão existem.
Valida se a situação do estabelecimento comercial de origem e da empresa
cliente do beneficiário está correta. Verifica também a senha, a situação, a
data de validade do cartão e se há saldo disponível para realizar a transação.
Se todas as validações estiverem corretas, o saldo do beneficiário é
subtraído do valor da transação, um registro é criado na tabela de
movimento (com a situação “ativa”) e o número da transação é devolvido
nos dados de saída; caso contrário, um código de resposta de erro é
devolvido nos dados de saída.

Dados de entrada Dados de saída

Código da transação - constante “SAQ” Código da transação - constante “SAQ”
Estabelecimento comercial de origem Código de resposta
Número do terminal de origem Número sequencial da transação
Identificador do beneficiário
Número do cartão
Senha
Valor

Crédito: essa transação, proveniente do sistema de retaguarda, verifica

se o beneficiário existe. Se todas as validações estiverem corretas, o valor
da transação é adicionado ao saldo, um registro é criado na tabela de
movimento (com a situação “ativa”) e o número da transação é devolvido
nos dados de saída; caso contrário, um código de resposta de erro é
devolvido nos dados de saída.

Dados de entrada Dados de saída

Código da transação - constante “CRD” Código da transação - constante “CRD”
Identificador do beneficiário Código de resposta
Valor Número sequencial da transação

Estorno de Saque: essa transação, proveniente de um supermercado,

verifica se o estabelecimento comercial de origem existe. Verifica também
se a transação informada existe na tabela de movimento, se é uma transação
de saque e se sua situação é ativa. Se todas as validações estiverem corretas,
o saldo do beneficiário é adicionado do valor da transação informada, a
transação informada tem sua situação alterada de “ativa” para “estornada”,
um registro é criado na tabela de movimento (com a situação “ativa”) e o
número da transação é devolvido nos dados de saída; caso contrário, um
código de resposta de erro é devolvido nos dados de saída.

Dados de entrada Dados de saída

Código da transação - constante “EST”
Estabelecimento comercial de origem
Número do terminal de origem
Número sequencial da transação de saque
Data da transação
Código da transação - constante “EST”
Código de resposta
Número sequencial da transação de estorno

Troca de Senha: essa transação, proveniente da Internet, verifica se o

beneficiário e o cartão existem e se a senha atual informada é válida. Se
todas as validações estiverem corretas, a senha do beneficiário é alterada
para a senha nova. Um registro também é criado na tabela de movimento;
caso contrário, um código de resposta de erro é devolvido nos dados de
saída.

Dados de entrada Dados de saída

Código da transação - constante “SNH” Código da transação - constante “SNH”
Estabelecimento comercial de origem Código de resposta
Identificador do beneficiário
Número do cartão
 Dados de entrada Dados de saída
Senha Atual
Senha Nova

Reinicialização de Senha: essa transação, proveniente do sistema de

retaguarda, verifica se apenas o beneficiário existe. Se a validação estiver
correta, a senha do beneficiário é alterada. Um registro também é criado na
tabela de movimento; caso contrário, um código de resposta de erro é
devolvido nos dados de saída.

Dados de entrada Dados de saída

Código da transação - constante “RSN” Código da transação - constante “RSN”
Identificador do beneficiário Código de resposta
Senha Nova

Bloqueio de Cartão pelo Beneficiário: essa transação, proveniente da

Internet, valida o estabelecimento comercial de origem, o beneficiário, a
senha e a situação do cartão. Se todas as validações estiverem corretas, a
situação do cartão é alterada para “bloqueado”. Um registro também é
criado na tabela de movimento; caso contrário, um código de resposta de
erro é devolvido nos dados de saída.

Dados de entrada Dados de saída

Código da transação - constante “BL1” Código da transação - constante “BL1”
Estabelecimento comercial de origem Código de resposta
Identificador do beneficiário
Senha

Bloqueio de Cartão pelo Banco: essa transação, proveniente do

sistema de retaguarda, valida o beneficiário e a situação do cartão. Se todas
as validações estiverem corretas, a situação do cartão é alterada para
“bloqueado”. Um registro também é criado na tabela de movimento; caso
contrário, um código de resposta de erro é devolvido nos dados de saída.

Dados de entrada Dados de saída

Código da transação - constante “BL2” Código da transação - constante “BL2”
Identificador do beneficiário Código de resposta
 Desbloqueio de Cartão: essa transação, proveniente do sistema de
retaguarda, valida o beneficiário e a situação do cartão. Se todas as
validações estiverem corretas, a situação do cartão é alterada para “ativo”.
Um registro também é criado na tabela de movimento; caso contrário, um
código de resposta de erro é devolvido nos dados de saída.

Dados de entrada Dados de saída

Código da transação - constante “BL3” Código da transação - constante “BL3”
Identificador do beneficiário Código de resposta

Requisitos de Transição
Para a instalação do sistema, o banco JDK decidiu que inicialmente o
serviço estará disponível apenas para seus próprios funcionários (que
também serão beneficiados pelo vale-alimentação por cartão). Os
funcionários do banco JDK já estão cadastrados na base de dados
Empregado Beneficiário, pois já recebem o benefício via ticket em papel,
porém a base de dados de cartões deve ser preenchida com dados. Sendo
assim, decidiu-se que provisoriamente os funcionários vão usar esse
benefício através do cartão de movimentação de conta-corrente, porém com
uma senha específica (diferente da senha de movimentação da conta-
corrente).
Logo, deve ser desenvolvida uma funcionalidade que pesquisa na base
de funcionários do banco JDK (mantidos pelo sistema de RH) os
funcionários ativos e recupera a sua respectiva conta-corrente e CPF.
Através da conta-corrente deve-se pesquisar os dados de cartão de conta-
corrente do funcionário na base de cartões de conta-corrente (mantidos no
sistema de contas-correntes) e gravar os dados de número do cartão, data de
validade e situação na base de cartões do sistema autorizador de compras. A
senha do cartão para uso do benefício vale-alimentação será a senha da
conta-corrente, mas com os dígitos na ordem inversa.

Projeto de Melhoria
 Neste estudo o objetivo é contar os pontos de função do projeto de
melhoria da aplicação de faturamento do primeiro estudo de caso, o sistema
de faturamento da ACME. Ao final da medição dessa melhoria
(“Adequação ao faturamento internacional”), recalcule os pontos de função
da aplicação.
Um aspecto do projeto de desenvolvimento do sistema ficou falho.
Mesmo sabendo que em breve a ACME atuaria fora do país, seu cadastro de
clientes não previu um campo para o país de origem do cliente. Assim,
foram solicitados os seguintes requisitos de melhoria (RM):
• RM1: criar uma tabela de países, que irá armazenar a
cotação do câmbio do dia da moeda usada no país. A
tabela terá os campos identificador, nome, moeda e
cotação em R$.
• RM2: criar uma tela de cadastro de países (consulta,
inclusão, alteração e exclusão) nos moldes do cadastro
de cidades. Acompanhe o esboço de tela na Figura 8.13
em seguida.

Figura 8.13: Tela do cadastro de países e cotação do câmbio.

• RM3: alterar a tabela Cidade para relacioná-la com País.
• RM4: incluir o campo nome do país na tela do cadastro
de Cidades, usando uma lista de países similar à lista de
UFs. Veja esboço na Figura 8.14.

Figura 8.14: Alteração na tela do cadastro de cidades.

• RM5: incluir o campo nome do país em todas as listas

de Cidade/UF do sistema, conforme a Figura 8.15.

Figura 8.15: Alteração na lista de cidades.

• RM6: incluir o campo nome do país (somente leitura) na
tela do cadastro de Clientes, na aba de cliente e contato.
• RM7: incluir uma coluna para País na aba de resultados
da pesquisa de Clientes, como indica a Figura 8.16.

Figura 8.16: Alteração na tela de resultados da pesquisa de

clientes.

• RM8: incluir nome do país, moeda e cotação no campo

que contém os dados de cliente da Nota Fiscal (na tela
do cadastro e no formulário da impressão).
• RM9: na tela de cadastro de cliente, verificar a
existência do CEP informado para o cliente ou contato
(quando ele for do Brasil) na tabela de CEPs dos
Correios. Essa tabela é fornecida com 55 campos.
• RM10: criar uma pesquisa de nota fiscal, um gráfico de
faturamento diário e um gráfico de faturamento mensal,
conforme protótipos de telas seguintes. Embora o
desenvolvedor tenha optado por desenhar uma única tela
de filtro que aciona a pesquisa e os dois gráficos, assuma
 que foram solicitadas pelo usuário três transações
distintas.
Assuma que as características gerais da aplicação não serão alteradas.

Figura 8.17: Tela de filtro da pesquisa de notas fiscais e gráficos de

faturamento.

Figura 8.18: Tela de resultados da pesquisa de notas fiscais.

Figura 8.19: Tela de resultados do gráfico de faturamento diário.
Figura 8.20: Tela de resultados do gráfico de faturamento mensal.
 9

Estimativa
Ao identificar a necessidade de desenvolvimento, manutenção ou
mesmo aquisição e customização de um software para atender a novas
demandas de uma organização, dois questionamentos sempre presentes são
os seguintes:
1. Quanto tempo será necessário para concluir o projeto?
2. Quanto o projeto vai custar para a organização?
As particularidades dos requisitos de um projeto de software, bem como
da equipe responsável e da tecnologia empregada, são fatores que
dificultam a obtenção de respostas confiáveis a estas perguntas. Tais
dificuldades podem ser evidenciadas ao tentar analisar questões como:
• Os requisitos traduzem com fidelidade as necessidades
do negócio dos usuários? Já se encontram
suficientemente estabilizados? Refletem características
de software transacionais de baixa complexidade ou
possuem atributos que exigem conhecimentos
específicos, tais como alta performance, matemática
complexa, processamento distribuído etc.?
• A equipe de desenvolvimento possui conhecimento na
área de negócio que será atendida pelo projeto de
software? Possui experiência na utilização das fer‐
 ramentas necessárias à conclusão do projeto? Possui
todos os perfis necessários impostos pelas características
do projeto? Existem conflitos internos à equipe que
precisam ser solucionados? É possível identificar uma
liderança entre os integrantes da equipe? Qual o grau de
motivação da equipe mediante o projeto?
• A tecnologia já faz parte da cultura da organização?
Pode ser facilmente absorvida por novos integrantes da
equipe de projeto? Existe material de apoio suficiente
para o aprendizado da tecnologia? Sua aplicação exige
pessoal com algum tipo de especialização? Suporta a
implementação de todas as características do software?
Atende inclusive aos requisitos não funcionais do
projeto?
Devido a estas e outras particularidades inerentes a cada projeto,
determinar com exatidão seu custo final e a data de sua conclusão é uma
tarefa que só pode ser realizada quando ele já está finalizado. Antes disso,
tudo o que pode ser feito, até os cálculos mais rigorosos, são estimativas.
Seja qual for o método empregado, o que muda é a precisão e a acurácia dos
resultados obtidos quando comparados aos dados reais.
Mesmo quando tais questionamentos são realizados na área da
engenharia civil, na produção de algo bem mais tangível que um software,
como uma casa ou uma ponte, características específicas que diferenciam
um novo projeto dos anteriores adicionam um certo grau de incerteza às
respostas.
Obter dados baseados em estimativas não muda a importância deles.
Muito pelo contrário. A partir da manutenção de uma base de dados
históricos estimados e realizados dos projetos, a organização pode avaliar a
adequação de seu processo de desenvolvimento e extrair indicadores de
produtividade e qualidade cada vez mais próximos de sua realidade e,
portanto, cada vez mais confiáveis. Com esses indicadores as estimativas
dos futuros projetos de software podem ser realizadas com segurança o
mais cedo possível durante o seu ciclo de vida de desenvolvimento,
ocasionando decisões mais rápidas e com menor custo para a organização.
O processo de estimativa de um projeto de software envolve,
basicamente, quatro atividades:
1. Estimar o tamanho do produto a ser gerado.
2. Estimar o esforço empregado na execução do projeto.
3. Estimar a duração do projeto.
4. Estimar o custo do projeto.
Para obter as respostas aos questionamentos iniciais de tempo e custo a
partir da aplicação de um processo de estimativa, antes de qualquer coisa, é
necessário decidir a unidade utilizada para medir o tamanho do produto.
Na construção civil, por exemplo, a unidade padrão de medida de
tamanho utilizada é o metro quadrado (m 2 ), que também serve como
unidade básica de definição de custo dos projetos. Na engenharia de
software são duas as unidades mais comuns, sendo linhas de código (LOC -
Lines of Code ) e pontos de função (PF).
Devido ao propósito principal de um processo de estimativa ser o de
fornecer informações que beneficiem o planejamento e o controle dos
projetos de software o mais cedo possível durante seu ciclo de vida, a
utilização de pontos de função como unidade padrão de medida de tamanho
é a mais acertada. Isso se dá por uma série de motivos.
Em primeiro lugar, para que uma estimativa de tamanho baseada em
LOC seja confiável, é necessário que se esteja em um adiantado estado da
fase de projeto do software, atrasando a geração de indicadores úteis para o
seu gerenciamento. A própria definição da linguagem de programação a ser
utilizada no desenvolvimento do projeto, fundamental para o processo de
contagem de linhas de código, nem sempre é realizada na fase inicial de seu
ciclo de vida, já que algumas características funcionais e até não funcionais
do software devem ser exploradas antes de se tomar alguma decisão. Por
outro lado, como a obtenção de pontos de função depende unicamente do
conhecimento da funcionalidade requerida para o software e não da
tecnologia empregada em seu desenvolvimento, uma estimativa de tamanho
pode ser realizada desde a fase inicial do levantamento de requisitos e ser
refinada à medida que se avança no entendimento do projeto.
 Além disso, é fato que softwares bem projetados ou com alto índice de
componentização ou de reutilização de código têm seus indicadores
baseados em LOC penalizados. Por exemplo, um sistema com 50.000 LOC,
mas que exigiu um alto esforço para a definição de uma arquitetura bem
elaborada, irá apresentar uma produtividade final média inferior à de outro
projeto similar e de funcionalidade equivalente, porém com arquitetura
menos trabalhada, com 60.000 LOC e que exigiu o mesmo esforço total de
desenvolvimento que o projeto anterior. Utilizando pontos de função, essa
distorção não seria observada, uma vez que não existiria diferença relevante
no tamanho estimado de ambos os projetos.
Após a decisão da unidade de tamanho empregada, pode-se utilizar um
modelo de processo de estimativa como o apresentado na Figura 9.1.

Figura 9.1: Processo de estimativa de projeto de software.

O processo de estimativa inicia-se a partir dos primeiros níveis de

abstração dos requisitos do projeto. Para ser completo e eficiente, deve
levar em consideração as experiências e os dados históricos de projetos
passados, os recursos disponíveis dentro ou fora da organização, os dados
de custo e os fatores de risco que cercam os projetos. A cada etapa
realizada, as estimativas obtidas devem passar por um processo de
aprovação antes de serem registradas na base histórica. Além de poderem
ser utilizadas como fonte de informação para projetos futuros, servirão
como insumo para as estimativas das etapas seguintes. Reestimar deve ser
uma atividade constante durante todo o ciclo de vida do desenvolvimento
do software. Na etapa final do processo, com o produto concluído, as
medidas reais de tamanho, esforço, duração e custo também devem ser
devidamente registradas na base histórica, servindo também para a
validação e o aprimoramento de todo o processo de estimativa.
Independente da etapa em que se esteja no processo, existem várias
técnicas de estimativas que podem ser utilizadas. Basicamente, essas
técnicas são classificadas em duas categorias: métodos diretos ou métodos
derivados.
Os métodos diretos são aqueles baseados na opinião de especialistas. O
procedimento padrão consiste em reunir a opinião de um ou mais
especialistas, que fornecem uma suposição direta da estimativa, baseando-
se principalmente em suas intuições e experiências passadas.
Os métodos derivados, também conhecidos como métodos de modelo
algorítmico ou métodos paramétricos, fornecem um ou mais algoritmos de
transformação que produzem a estimativa desejada em função de variáveis
que se relacionam com alguns atributos de software. Por exemplo, uma
estimativa de tamanho não é realizada diretamente em valores de pontos de
função, mas sim em diferentes atributos de software que podem ser
correlacionados a eles.

Estimativa de Tamanho Funcional

O primeiro passo para alcançar estimativas efetivas do projeto de
software é estimar o seu tamanho.
Uma técnica simples e rápida para alcançar uma estimativa de tamanho,
classificada como um método direto, é a analogia simples. A técnica de
analogia é aplicada comparando o projeto atual com dados de projetos
similares passados, obtidos de uma base histórica. A partir do conhecimento
do tamanho de um projeto similar, estima-se o tamanho do novo projeto
como um percentual do tamanho daquele, podendo até subdividir o projeto
em módulos menores (de mais fácil compreensão) e estimar o percentual do
tamanho de cada módulo em relação ao projeto passado.
O tamanho total do projeto é obtido pela soma dos tamanhos estimados
para cada módulo separadamente. Logicamente, a eficácia desse método irá
depender de dois fatores, sendo a acurácia do valor do tamanho do projeto
recuperado da base histórica e o grau de similaridade entre o novo projeto e
seu antecessor.
As técnicas mais utilizadas para a estimativa de tamanho são
encontradas na categoria dos métodos derivados. Algumas delas são
tratadas em seguida.

Contagem Dedutiva
Essa técnica considera a possibilidade de contagem de um único
componente da análise de pontos de função para a aplicação, geralmente o
número de Arquivos Lógicos Internos, derivando o resto da contagem de
bases estatísticas.
No trabalho Early Function Point Counting , publicado pela NESMA 16
, encontra-se descrita uma abordagem para esse método. Trata-se da
Contagem Indicativa, na qual apenas é necessária a identificação dos
Arquivos de Interface Externa (AIE) e Arquivos Lógicos Internos (ALI).
Considera-se 35 PF para cada ALI e 15 PF para cada AIE identificado.
Os números 35 e 15 representam as médias de pontos de função
identificadas para cada um dos tipos de arquivo, considerando projetos que,
em média, possuam três Entradas Externas (EE), duas Saídas Externas (SE)
e uma Consulta Externa (CE) para cada ALI e uma Saída Externa e uma
Consulta Externa para cada AIE.

Complexidade Média
A versão 5 do ISBSG Benchmark apresenta uma média de
complexidades para os projetos de desenvolvimento, distribuídas por tipos
de funções, conforme a Tabela 9.1.
Tabela 9.1: Média de PFs, por tipo de função, do ISBSG comparado
na tabela de complexidade do IFPUG.

Tipo de função Média de PF IFPUG (baixa) IFPUG (média) IFPUG (alta)

ALI 7,4 7 10 15
AIE 5,5 5 7 10
EE 4,3 3 4 6
SE 5,4 4 5 7
CE 3,8 3 4 6

Para o processo de estimativa, após a identificação do número de todos

os componentes funcionais (ALI, AIE, EE, SE e CE), basta que sejam
associadas suas respectivas complexidades. O número estimado para o
tamanho funcional é alcançado pela fórmula:

A NESMA simplificou esta abordagem com sua Contagem Estimativa.

Após a identificação de todas as funcionalidades do software, utiliza-se a
classificação de complexidades do IFPUG e aplica-se a complexidade baixa
para cada Arquivo Lógico Interno e Arquivo de Interface Externa e média
para cada Entrada Externa, Saída Externa ou Consulta Externa. A
estimativa do tamanho é então obtida pela fórmula:

Backfiring
Esse método consiste em derivar o número de pontos de função da
aplicação a partir de seu tamanho físico, medido em linhas de código,
utilizando um fator de conversão constante dependente da linguagem de
programação. A ideia em si possui bastante apelo, uma vez que a contagem
de linhas de código pode ser feita por meio de ferramentas automáticas e,
consequentemente, o número de pontos de função poderia ser derivado de
imediato. Por exemplo, utilizando um fator de conversão de 80 LOC/PF
para C ++ e tendo uma aplicação escrita em C ++ com 8.000 linhas de
código, chega-se a 1.000 pontos de função para essa mesma aplicação.
 Entretanto, não raro, essa técnica apresenta erros consideráveis quando
confrontada com uma contagem manual dos pontos de função de uma
aplicação. Isso porque assume uma relação linear entre o tamanho funcional
e o tamanho físico, que são grandezas distintas. Alguns autores sugerem
que se houvesse essa relação entre pontos de função e linhas de código, uma
das seguintes assertivas deveria ser verdadeira:
• LOC não é uma medida técnica, mas funcional.
• FP não é uma medida funcional, mas técnica.
• Medidas técnicas também são medidas funcionais.
Além disso, as variações encontradas nos próprios fatores de conversão
publicados por várias organizações no mercado podem chegar a 100%! A
Tabela 9.2 apresenta um exemplo dessas variações para a linguagem
COBOL.
Tabela 9.2: De fatores de conversão obtidos do mercado para
backfiring em aplicações COBOL.

Fonte Fator de conversão (COBOL)

Quantitative Software Management 77 LOC/PF
Capers Jones 107 LOC/PF
David Consulting Group 177 LOC/PF

Algumas das razões para explicar essa variação tão grande são
premissas distintas na definição do que é uma linha de código e bases de
projetos com características muito distintas. Daí a necessidade de calibrar
esse fator de conversão para a realidade dos projetos desenvolvidos pela
própria organização. Para efetuar essa calibração, deve haver uma amostra
representativa de projetos desenvolvidos pela organização em determinada
linguagem e um profissional experiente e capacitado para saber interpretar
os resultados e entender as razões de possíveis distorções para esse fator de
conversão.
Devido a esses fatores, aplicar backfiring para obter um tamanho em
pontos de função a partir de linhas de código é uma técnica arriscada e
sujeita a uma grande margem de erro. Daí, o próprio IFPUG ressalta no
FAQ, em sua página na Internet, que ela até pode ser usada (com muita
cautela) em sistemas legados, em que uma contagem manual de pontos é
inviável na prática e a precisão não seja um fator crítico.
Alguns profissionais advogam que backfiring é uma maneira rápida e
barata de obter o tamanho em pontos de função do portfolio de aplicações
de uma organização. Outros argumentam que o barato sai caro; é melhor
investir na contagem manual dos pontos de função e ter confiabilidade
desses dados, com compensação no longo prazo.
Por outro lado, muitos modelos de estimativa de software, como o
COCOMO II, utilizam como dado primário de entrada de seu processo o
tamanho em linhas de código. Nesses casos é muito comum realizar o
inverso: obter o número de linhas de código a partir do tamanho em pontos
de função. Isso porque nas fases iniciais de um projeto de software é mais
fácil estimar ou medir o seu tamanho em pontos de função do que em linhas
de código. Mesmo nesse caso, as considerações anteriores sobre backfiring
continuam válidas.

A Escolha do Tipo de Contagem

Logicamente, a contagem detalhada de pontos de função é muito mais
precisa que os demais tipos de contagem na determinação do tamanho de
um projeto. Esse tipo de contagem também requer maior tempo para ser
realizado e depende de especificações mais detalhadas a respeito dos
requisitos do projeto. Ao contrário, uma contagem indicativa, por exemplo,
pode ser realizada já nas fases iniciais do desenvolvimento, quando existe
apenas uma visão superficial do projeto, com um bom grau de fidelidade de
resultado.
A NESMA realizou uma pesquisa em uma base de dados com mais de
100 projetos. Os gráficos representados pelas Figuras 9.2 e 9.3 mostram os
resultados obtidos na comparação entre a contagem estimativa e indicativa
contra a contagem detalhada.
 Figura 9.2: Contagem estimativa x contagem detalhada.

Pode-se notar que a contagem indicativa apresenta maior dispersão de

resultados em relação à contagem detalhada, se comparada à contagem
estimativa.
 Figura 9.3: Contagem indicativa x contagem detalhada.

A rigor, o que vai determinar o tipo de contagem e o mais adequado

para ser utilizado por uma organização em um projeto é o nível de
informações que se tem sobre ele, dependendo da fase do ciclo de vida de
desenvolvimento em que ele se encontra, além do esforço e do tempo
requeridos para a execução de um tipo de contagem ou outro.
Vale ressaltar os cuidados que devem ser tomados com a utilização de
indicadores de mercado. A partir da estratificação de seus projetos de
acordo com critérios bem definidos, uma organização pode gerar seus
próprios modelos de contagem.
Por exemplo, a partir de uma análise histórica, uma organização
identifica que a maioria de seus projetos transacionais de pequeno porte não
realiza nenhum tipo de integração com dados de outros sistemas e, além
disso, apresenta as seguintes características principais para cada entidade de
armazenamento identificada:
1. A complexidade da entidade de armazenamento é
considerada baixa (7 PF).
2. Existe uma Entrada Externa (exclusão) de
complexidade baixa (3 PF).
3. Existem duas Entradas Externas (inclusão e alteração)
de complexidade média (8 PF).
4. Existe uma Saída Externa de complexidade média (5
PF).
5. Existe uma Consulta Externa de complexidade baixa (3
PF).
Com essas informações, a organização poderia estimar o tamanho de
seus projetos futuros a partir de um modelo de contagem indicativa próprio,
em que seria necessária apenas a identificação dos Arquivos Lógicos
Internos. Para cada ALI identificado seriam contados 26 PF.
É claro que este número só poderia ser aplicado nos projetos de mesmas
características que aqueles historicamente analisados, sob pena de resultar
em uma estimativa de tamanho distorcido.
Fator de Crescimento
Para fins de simplificação da discussão até o momento, consideramos
que não há variação entre o momento da estimativa e da medição do
tamanho do projeto. Na prática, contudo, essa simplificação é falsa. É regra,
ao final dos projetos, serem apuradas mais funcionalidades que a estimada
originalmente. A Figura 9.4 ilustra tal situação. O Fator de Crescimento
representa a variação no tamanho funcional entre o início e término de uma
fase do projeto.
Com a sistematização do dimensionamento de projetos nas várias fases
do ciclo de vida de desenvolvimento e manutenção de sistemas, a
organização passa a poder se beneficiar de outro indicador muito importante
no processo de estimativa: a variação no tamanho funcional ao longo do
projeto . O tamanho varia porque os requisitos mudam. Esse fenômeno é
conhecido como scope creep . As técnicas de estimativa de tamanho
descritas anteriormente não abordam esse fenômeno. Portanto, ao estimar o
tamanho por uma dessas técnicas, deve-se levar o scope creep em
consideração.
O scope creep é provocado basicamente por duas razões, sendo
solicitações de mudança por parte do cliente e descobertas no refinamento
dos requisitos. Cada organização vivencia realidades distintas nestes
aspectos; logo, usar um fator padrão para representar o scope creep
dificilmente dará bons resultados. A medição do tamanho ao longo dos seus
próprios projetos é que lhe dará informação valiosa a respeito da
intensidade desse fenômeno dos projetos da sua organização.
Ao conhecer o fator de crescimento do escopo que historicamente
ocorre nos projetos de sua organização, consegue-se melhorar
sensivelmente a qualidade das estimativas. E mais, isso também pode
contribuir para a melhoria contínua do processo de desenvolvimento
utilizado na organização, identificando fatores inerentes ao processo que
contribuem para esse aumento de tamanho.
 Figura 9.4: Exemplo da variação do tamanho de um projeto.

Estimativa de Esforço
No geral, o dimensionamento ou a estimativa da quantidade de pontos
de função nos vários estágios do projeto, isoladamente, são relevantes como
base para a remuneração de contratos, assunto tratado especificamente neste
livro. Os pontos de função passam a ter maior significado quando utilizados
como parâmetros na obtenção de estimativas de outras variáveis relevantes
para a gerência de projetos, entre elas o esforço.
Ao utilizar a quantidade de pontos de função como base para a obtenção
do esforço, considera-se a existência de alguma função que relacione essas
duas dimensões. Dentre as dificuldades para sua identificação, a principal
delas é a falta de um processo de desenvolvimento bem definido, em que as
particularidades de todas as etapas do ciclo de vida do desenvolvimento são
conhecidas, bem como todos os subprodutos gerados em cada uma dessas
etapas. Este assunto é bastante abrangente e foge do escopo deste texto
abordá-lo. Outra dificuldade é a falta de cultura e experiência prática na
aplicação de pontos de função, aliada a uma mitologia simplista que
promete com uma simples multiplicação de alguns números mágicos
fornecer resultados próximos à realidade.
Por estes motivos geralmente se estima o esforço total de um projeto
pela soma das estimativas de esforço de cada atividade. O principal insumo
nesse processo é a experiência individual dos responsáveis pela estimativa.
Uma prática comum observada nas organizações para alcançar uma
estimativa de esforço é a utilização da WBS ( Work Breakdown Structure ),
em que o projeto de software é decomposto em suas funções e uma
estimativa de esforço é fornecida para cada uma delas. Também é comum a
utilização de métodos diretos, como as técnicas Delphi e Three-Point .
A Delphi pode ser descrita como uma técnica de grupo iterativa que
permite que um participante melhore suas estimativas individuais a partir da
colaboração dos diferentes pontos de vista dos demais especialistas. São
executados ciclos iterativos de estimativas anônimas realizadas por cada
especialista do grupo, até que os valores convirjam para uma faixa
aceitável. O resultado é uma estimativa obtida pelo consenso de todo o
grupo, alcançando valores melhores que qualquer previsão individual.
Já a técnica Three-Point é utilizada para melhorar a estimativa direta,
quando mais valores são fornecidos pelos responsáveis pela execução das
estimativas. Dados os valores mínimos, mais comuns e máximos para o
tamanho, aplica-se a fórmula:

com o desvio padrão:

Ao procurar uma alternativa ou um complemento para essas abordagens,

muitos profissionais procuram indicadores de mercado que permitam
utilizar estimativas de tamanho funcional como base para determinar o
esforço. A melhor utilização desses números é para comparar o
desempenho interno às melhores práticas de mercado, ou seja, para realizar
benchmarking .

Como Começar?
A melhor forma de chegar à estimativa de esforço a partir da estimativa
de tamanho do projeto é utilizar dados internos à própria organização, como
o número de horas apropriadas em projetos passados, juntamente com a
quantidade de pontos de função dimensionados nas diversas fases dos
respectivos projetos.
 Atualmente já é bastante comum a manutenção de dados de apropriação
de horas alocadas não só a um projeto, mas, muitas vezes, também aos tipos
de atividade. Mesmo quando essa informação não está disponível, pelo
menos a apropriação de custos costuma estar. Ainda assim, poucas são as
organizações que possuem o baseline de suas aplicações. Menor ainda é o
número daquelas que mantêm informações sobre o dimensionamento do
projeto em suas diversas fases. Sem essas informações como começar a
estimar?
A primeira consideração envolve a criação de classes de projetos, as
quais devem procurar compreender projetos que tenham características
semelhantes quanto a fatores que afetem a relação entre tamanho e esforço.
Antes de dar prosseguimento a este assunto, é preciso definir melhor alguns
conceitos. O primeiro deles diz respeito a um dos indicadores que descreve
a relação entre tamanho e esforço: a produtividade.

Produtividade e Taxa de Entrega

Para que se possa estimar o esforço ou custo de forma menos empírica,
deve-se voltar à definição de produtividade (P): a razão de bens ou serviços
produzidos (F) por unidades de trabalho e custo (E).

Por exemplo, um carro percorre um determinado trecho de 120 Km (F)

com um custo médio de R$ 10,00 (E) e em um período de duas horas (E).
Assim, sua produtividade pode ser apurada em 12 quilômetros rodados para
cada real gasto com combustível e sua velocidade em 60 Km/h.
O valor desta informação para fins de estimativa está na extrapolação
desse comportamento histórico aplicado em novas situações, cujas
condições são semelhantes ao do contexto original.
 Para percorrer um trecho de 135 Km (F) em condições semelhantes ao
do trecho utilizado anteriormente, estima-se (E) gastar R$ 11,25.

em 2:15 horas
Pelo momento, será considerado que a quantidade de bens ou serviços
produzidos (F) não é estimada, mas calculada. Até agora a principal
heurística é a produtividade (P). É bom lembrar que, apesar das
semelhanças existentes entre os dois trechos, eles são diferentes. Para que
as previsões quanto ao esforço (E) sejam as mais aproximadas do que vier a
ser efetivamente realizado, tais diferenças devem ser identificadas e o
impacto que elas causam na produtividade deve ser avaliado.
No desenvolvimento de sistemas, essas diferenças podem ser
classificadas como inerentes ao projeto, à equipe ou ao cliente (usuário). As
combinações mais comuns dos atributos dessas dimensões devem ser
determinadas para fins de melhor estratificação no fornecimento e
utilização de indicadores.
As unidades utilizadas nos exemplos anteriores são cotidianas e nem se
nota que o consumo e a velocidade do carro são invertidos para obter uma
estimativa de quantos litros serão gastos ou quanto tempo durará a viagem.
Muitas vezes, um outro indicador é utilizado indistintamente como um
medidor de produtividade. Tal indicador é denominado pelo mercado de
taxa de entrega e medido numa razão inversa àquela da produtividade.
A fim de esclarecer a diferença básica entre estes dois indicadores,
pode-se utilizar o exemplo da linha de montagem de uma fábrica de
automóveis. A produção da linha de montagem pode ser observada sob duas
perspectivas. Por um lado encontra-se a capacidade de produção ou
produtividade, que corresponde à quantidade de automóveis fabricados por
unidade de tempo. Por outro lado encontra-se o custo, em unidades de
tempo, para se fabricar um automóvel, ou seja, quanto tempo é necessário
para a produção de um único automóvel. Desta forma, observa-se que
quanto maior a taxa de entrega, ou seja, quanto maior o tempo necessário
para a produção de um bem, menor a produtividade anotada em
determinado período de tempo e vice-versa.
 Mais uma vez, o conceito de produtividade no desenvolvimento de
software depende, principalmente, da determinação da medida de tamanho
a ser utilizada. No Brasil, os pontos de função (PF) têm sido a medida
adotada pela maioria das empresas que aplicam algum processo sistemático
de medição de tamanho de software. A partir daí, pode-se definir a
produtividade (P), como, por exemplo, a razão entre o tamanho do projeto
em PF e a quantidade total de horas (H) ou de Homem x Mês (HM) gastos
no seu desenvolvimento, na unidade PF / H ou PF / HM respectivamente. A
taxa de entrega, geralmente é medida em H / PF. Assim, uma taxa de
entrega de 4 H / PF corresponde a uma produtividade de 0,25 PF / H, da
mesma forma que uma produtividade de 0,5 PF / H equivale a uma taxa de
entrega de 2 H / PF.
Enfim, ambos os indicadores representam o mesmo fato: a relação entre
o tamanho funcional e o esforço.
Voltando à questão inicial da extrapolação do conhecimento do histórico
de produtividade para fins de estimativa de esforço, para o caso do
desenvolvimento de software pode-se adotar a mesma relação:

,
em que F é uma medida de tamanho em PF.
Para efeito de estimativa de esforço, o que parece ser mais natural é a
utilização da taxa de entrega ( T ):
,
em que é possível obter uma relação direta entre o aumento da taxa de
entrega e o aumento do esforço. Nesse sentido, a utilização da
produtividade conforme definida seria mais natural para efeito de
monitoramento do desenvolvimento de software, a partir do conhecimento
do tamanho e esforço realizados em cada fase de seu ciclo de vida, em que
um aumento desse indicador teria uma relação direta com o aumento da
maturidade e qualidade do processo de desenvolvimento.
Exemplificando, para estimar o custo de um projeto de software a partir
do conhecimento da produtividade ou da taxa de entrega alcançada em
projetos de mesmo contexto ou plataforma, basta realizar as seguintes
operações:
1. Estimar a quantidade de horas necessárias para a
conclusão do projeto, dividindo seu tamanho estimado
em PF pela produtividade em PF / H ou multiplicando-o
pela taxa de entrega em H / PF. O resultado será o
esforço em horas estimado para o projeto.
2. Multiplicar a quantidade de horas obtida no passo
anterior pelo custo médio da hora da equipe. O resultado
será a estimativa de custo para o projeto.

Cuidado com as Relações Lineares!

Parece bastante simples. Todas as fórmulas apresentadas são lineares.
Elas envolvem uma constante (Produtividade ou Taxa de Entrega) e uma
variável (Tamanho Funcional). Para que essa aproximação represente de
fato a relação entre as dimensões envolvidas, é necessário que os fatores
externos a esses componentes sejam uniformizados.
Em termos práticos e utilizando uma situação extrema para ilustrar o
que são “fatores externos” neste contexto, imagine dois sistemas, ambos
compostos por apenas uma saída externa de complexidade alta. O primeiro
simplesmente recupera dados de um arquivo, totaliza a quantidade de
registros e apresenta o resultado na tela, enquanto o segundo realiza
inúmeros cálculos financeiros, envolvendo a comparação dos resultados da
aplicação da taxa de juros do contrato e da taxa ANBID pelos vários
períodos de atraso de uma parcela para o cálculo de juros de mora, além de
uma série de outros cálculos extremamente complexos.
Ambos os projetos são dimensionados em 7 PF. Como a taxa de entrega
da organização é de 4 Horas / Pontos de Função, tem-se uma estimativa de
28 horas. É claro que se este número for utilizado como base para o resto do
processo de planejamento, é certo que o primeiro projeto estará
superestimado, enquanto o segundo estará subestimado.
 Essa situação não implica na inutilidade prática de aplicar pontos de
função para este fim. Deve-se, sim, evitar comparar sistemas com perfis
muito distintos quanto a estes aspectos. Ou seja, um sistema basicamente
cadastral, em que o foco do processamento esteja na manutenção de
arquivos e geração de relatórios, não deve ser estimado utilizando os
mesmos números que um sistema cuja maioria do processamento esteja em
cálculos ou outro fator que aumente sua complexidade algorítmica. Da
mesma forma, existem características não funcionais que afetam a
produtividade. O fator de ajuste da análise de pontos de função não reflete
devidamente o impacto dessas características na produtividade.
Ao identificar as classes de sistemas e projetos que devem ter os seus
dados futuros ou passados coletados, deve-se ter em mente essas
particularidades da técnica. A mesma consideração é válida quanto à
utilização da análise de pontos de função para estimar projetos de
manutenção. Quanto menor o escopo do projeto, mais serão sentidos os
impactos da abstração dos detalhes na mensuração da quantidade de pontos
de função. Atividades que não são empreendidas como projetos, pela sua
quantidade ou pequeno tamanho, não são boas candidatas a utilizar pontos
de função como base para estimativas de esforço. Por “pequeno tamanho”
podem-se considerar projetos com até 50 pontos de função. Nesses casos,
operações de manutenção, a análise de pontos de função pode ter outras
aplicações não menos nobres, como acompanhamento da evolução da
produtividade e qualidade. Afinal, mil pequenas coisas são uma grande
coisa.
Uma vez realizada essa classificação, o próximo passo envolve algumas
habilidades “arqueológicas”. O que se observa nos profissionais e
organizações, que têm intenção de iniciar a utilização da análise de pontos
de função para estimativas, é a busca pelo conhecimento da técnica por
autoestudo ou participando de algum treinamento. Em seguida, procuram
indicadores de mercado para a produtividade. Por fim, chegam à conclusão
de que os resultados obtidos são tão díspares da sua realidade que acabam
por abandonar a iniciativa. O principal argumento para a não utilização de
indicadores gerados internamente é exatamente a falta de dados básicos
para sua geração.
Mesmo nos casos de não haver disponibilidade dessas informações,
ainda assim a técnica pode ser aplicada de maneira conveniente. São três as
etapas envolvidas:
1. Identificar projetos já empreendidos e classificados
conforme os critérios expostos anteriormente.
Dimensioná-los em suas diversas etapas conforme o
conhecimento disponível em cada uma dessas etapas.
Solicitações de proposta, atas, especificações e o próprio
sistema em si são instrumentos importantes nesse
processo. Levantar dados de esforço e custo. Com seu
inter- -relacionamento, gerar sementes de indicadores
internos de produtividade.
2. Realizar as estimativas utilizando as práticas em uso e
os indicadores obtidos para dar apoio ao processo. A
equipe técnica tende a ser otimista e os resultados de
experiências passadas, traduzidas pelos indicadores
obtidos, têm valor na avaliação desse otimismo.
3. Medir durante a execução dos projetos não só o esforço
ou custo apropriados, mas também a dimensão funcional
conforme o conhecimento sobre o projeto se consolida.
Ajustar as “sementes” de indicadores à medida que
novos dados são coletados e analisados.
Este é um processo contínuo e a cada iteração o papel dos indicadores
passa a ter maior relevância no processo de planejamento. Inicialmente
sendo apenas um apoio, quase uma curiosidade para o processo individual
de estimativa, para passar a ser um instrumento fundamental na
determinação das variáveis de projeto.
Com estas considerações, é possível iniciar a utilização da técnica da
análise de pontos de função como subsídio ao processo de estimativa de
esforço. Com base nessa estimativa, pode-se estimar a duração do projeto,
estudado em seguida.
Estimativa de Duração
O terceiro passo da estimativa de um projeto de software é determinar o
cronograma do projeto a partir do esforço estimado. Entre o planejamento
do desenvolvimento ou manutenção de sistemas, a estimativa de sua
duração é uma das atividades que exigem maior experiência e
conhecimento dos aspectos envolvidos em sua execução. Pela utilização
intensiva de trabalho humano, ela é principalmente avaliada como a relação
entre a estimativa de trabalho envolvido e os recursos disponíveis para sua
execução. Uma vez determinado o esforço em horas, necessário para a
realização de uma determinada atividade, para obter sua estimativa de
duração, basta dividir esse valor pelo número de horas trabalhadas pela
equipe alocada.

Ou seja, o prazo previsto será a razão entre o esforço previsto e a

quantidade de recursos alocada na execução do projeto. Tal proposição, que
implica em uma relação linear entre as variáveis, é uma simplificação. Uma
análise mais profunda sobre o assunto pode ser explorada no clássico livro
The Mythical Man Month .
A experiência comprova que essa relação linear entre prazo e
quantidade de recursos não existe, assim como não é verdade a afirmação
de que “nove mulheres geram um bebê em um mês”. Para viabilizar a
diminuição do prazo, também é adicionado esforço novo ao projeto. Esse
trabalho é consequência de novas atividades que suprem as necessidades de
comunicação, integração e sequenciamento geradas pela maior distribuição
das tarefas.

Curva de Rayleigh-Putnam
Com base em análise estatística, Lawrence Putnam relacionou o
comportamento entre o prazo e o esforço com a distribuição de Rayleigh .
Esse modelo utiliza como métrica para quantificar o tamanho, linhas de
código, o prazo em anos e o esforço em homens-ano. Outra característica
importante é que ele também representa o impacto do ambiente no
comportamento dessa relação, para tanto utiliza uma constante C. Os
valores utilizados para esta constante podem variar de 2000 a 11000.

A Região Impossível
O gráfico seguinte ilustra a trajetória descrita pela curva de Rayleigh-
Putnam . Os pontos destacados representam a quantidade de recursos

necessária para concluir no prazo definido no

eixo x.
Apesar de algumas das mudanças ocorridas desde a elaboração deste
modelo, como, por exemplo, a gradual migração na utilização de
metodologias em cascata para as metodologias evolucionárias e a aplicação
de novas tecnologias, ele ainda é bastante ilustrativo quanto à existência de
uma região em que é impossível a entrega no prazo.
 Figura 9.5: Quantidade de recursos x prazo - a região impossível.

Cuidados com a Utilização de

Indicadores de Mercado
Uma mesma equipe que trabalha com um mesmo tipo de aplicação e
usuários tende a ser um bom critério para geração de indicadores. Por outro
lado, como já mencionado anteriormente, deve-se tomar cuidado com
indicadores de mercado. Por exemplo:
“A produtividade do desenvolvimento em COBOL é de 0,125 PF/H. Foi
realizada uma contagem estimativa do projeto do novo sistema em 2.350
PF. Desta forma a estimativa de esforço será de 18.800 horas.”
Antes de adotar qualquer indicador obtido no mercado, é necessário
responder a uma série de perguntas na tentativa de explorar o nível de
adequação do indicador a um determinado projeto ou ambiente. Perguntas
como:
a) Os critérios de coleta de horas utilizados na elaboração
desses indicadores são compatíveis com os utilizados
por você?
 Por exemplo: quantas horas são consideradas em um mês
de trabalho (126, 160, 168 etc.)? Qual a carga horária
diária de trabalho (4, 6, 8 etc.)?
b) As atividades envolvidas, os produtos gerados, a
metodologia adotada abrangem a mesma utilização de
recursos que o seu contexto exige?
Por exemplo: quais modelos de projeto e diagramas são
utilizados? Existem papéis definidos para cada
atividade realizada, inclusive para implementar o
controle de qualidade dos projetos?
c) Mesmo sendo diferentes, o risco dessa variabilidade é
aceitável?
Para garantir a eficácia na aplicação de métodos de estimativa baseados
na utilização de indicadores disponíveis no mercado, além da base histórica
utilizada como referência, os gerentes responsáveis pelo garimpo das
informações devem conhecer as particularidades do processo de
desenvolvimento de software adotado pela organização, bem como as
características de sistema e as necessidades de cada novo projeto.
Tomando como exemplo os indicadores de produtividade obtidos a
partir de análises dos projetos cadastrados na base de dados da DATAMAX
(17) , é possível verificar como tais indicadores se comportam mediante
diferentes situações. Em 1999, essa base de dados contava com informações
de 206 projetos de 26 companhias europeias, sendo 38 projetos do setor de
manufatura, 79 do setor bancário, 56 do setor de seguros, 14 do setor de
administração pública e 19 dos setores atacadista e varejista.
Deve-se ressaltar que o tamanho dos projetos dessa base de dados foi
medido utilizando uma variação da técnica de pontos de função, o
Experience 2.0, que é similar aos pontos de função da versão 4.0 do IFPUG.
Os valores apresentados servem apenas para ilustrar as questões levantadas
nesta seção. A média de produtividade dos projetos, estratificada por setor
de negócios, encontrava-se distribuída conforme a Tabela 9.3 em seguida.
 Tabela 9.3: De produtividade no desenvolvimento de software por
setor de negócios em 1999. (Fonte: Datamax )

Setor de negócios Produtividade (Pontos de função / hora)

Manufatura 0,34
Bancário 0,12
Seguros 0,12
Administração Pública 0,23
Atacadista / Varejista 0,25

Pode-se imaginar o resultado desastroso que poderia ser obtido se

uma indústria utilizasse o indicador de produtividade de 0,34 PF/H
da tabela anterior para as estimativas de esforço e custo do
desenvolvimento de um novo sistema internamente, utilizando uma
linguagem de quarta geração, se tal indicador fosse gerado por uma
base de projetos desenvolvidos em COBOL, por exemplo.
Analisando em separado os projetos do setor bancário da base de dados
da DATAMAX, é possível simular o comportamento do indicador de
produtividade, variando a complexidade de outros três indicadores:
habilidade da equipe com as ferramentas, volatilidade dos requisitos e os
requisitos de eficiência. Considerando projetos com 1.000 pontos de função
de tamanho desenvolvidos com interface gráfica e utilizando as
complexidades baixa, média e alta para cada um dos três indicadores,
obtêm-se as produtividades da Tabela 9.4.
Tabela 9.4: De distribuição de produtividade de projetos do setor
bancário.

Habilidade com as ferramentas Baixa Média Alta

A A A
Bai Mé Bai Mé Bai Mé
Volatilidade dos requisitos lt lt lt
xa dia xa dia xa dia
a a a
Requisitos 0, 0,
0,5 0,6 0,4 0,6 0,
de eficiência Baixa 0,4 3 3 0,5
6 3 6 9 4
2 6
Média 0,3 0,2 0, 0,4 0,3 0, 0,4 0,35 0,
 9 8 2 5 2 2 9 2
3 6 8
0, 0,
0,3 0,2 0,3 0,2 0, 0,3
Alta 1 0,28 2
1 2 5 5 2 8
8 2

Uma análise realizada com os dados da tabela anterior pode demonstrar

mais claramente o cuidado que deve ser tomado com a utilização de
indicadores externos à organização. Muitas vezes, até as características
mais subjetivas dos projetos ou do processo de desenvolvimento podem
influenciar no cálculo dos indicadores e nas estimativas futuras dos novos
projetos.

Geração de Indicadores Internos

Pela dificuldade de responder às perguntas iniciais a respeito do tempo e
do custo do desenvolvimento de um projeto de software, recomenda-se a
utilização de indicadores gerados internamente. Mesmo nos casos em que
eles ainda não estejam disponíveis na organização, se houver registro de
esforço previsto e realizado em projetos passados, já se tem uma parte da
equação. O dimensionamento do projeto, mesmo não tendo sido realizado
na época, pode ser realizado posteriormente.
Aplicando esse procedimento em alguns projetos passados, é possível a
obtenção de indicadores com uma representatividade suficiente para dar
início à sua utilização, objetivando, no mínimo, validar as estimativas
realizadas apenas pelo critério anterior.
Como já foi visto, para a estimativa da duração das atividades, além da
quantidade de recursos utilizados e do esforço estimado, o tamanho também
deve ser considerado. Já para estimar esse esforço, deve-se avaliar a
produtividade esperada.
Vale ressaltar que existem diferenças entre os indicadores úteis para as
organizações produtoras de softwares e as organizações contratantes. Para
as primeiras, são mais importantes aqueles indicadores relacionados ao
gerenciamento dos projetos e de seus riscos. Já para as organizações
contratantes, são mais relevantes aqueles indicadores utilizados no
gerenciamento do relacionamento com os fornecedores e dos custos
envolvidos no processo de produção de software.

Conclusão
O objetivo principal deste capítulo é apresentar as várias técnicas de
estimativa de tamanho de projetos de software, realçando a sua importância
em meio ao modelo geral de processo de estimativa. Por este modelo, pode-
se observar que o tamanho é o dado inicial que irá permitir a geração das
estimativas dos demais indicadores, como produtividade, esforço, duração e
custo. Além disso, vários modelos de estimativa do mercado também
utilizam o tamanho como dado de entrada para a obtenção das demais
estimativas. É o caso dos modelos paramétricos COCOMO II, SLiM e
KnowledgePlan.
Outro objetivo é destacar os benefícios alcançados com a utilização dos
pontos de função como unidade de estimativa de tamanho, servindo de base
para a definição dos indicadores de produtividade e esforço.
O comportamento geral que pode ser observado em um processo de
estimativa de métricas e de demais indicadores de produtividade e
qualidade dos projetos de software tem relação direta com o tamanho dos
projetos, conforme representado na Figura 9.6. O gráfico ilustra a alta
precisão das estimativas realizadas em projetos pequenos seguida pela
diminuição da precisão das mesmas estimativas à medida que os projetos
crescem no tamanho. Em contrapartida, a precisão exigida para as
estimativas é mais alta quanto maior o tamanho dos projetos. Isso se deve
ao fato de que os impactos negativos nos prazos e custos dos projetos,
causados pelas distorções entre a situação prevista e realizada, são baixos
em projetos pequenos, aumentando de acordo com o seu crescimento.
 Figura 9.6: Precisão das estimativas x tamanho dos projetos.

A situação ideal a ser alcançada por um processo de estimativa é a

máxima aproximação entre a previsão e a realidade dos projetos. Para isso,
é fundamental que as métricas e os indicadores obtidos sejam revisados
durante todo o ciclo de vida de seu desenvolvimento, aprimorando seus
valores a partir de limites inferiores e superiores inicialmente estabelecidos.
A Figura 9.7 ao lado ilustra tal situação.
 Figura 9.7: Revisões das estimativas durante o ciclo de vida do
desenvolvimento.

Antes de partir para a aplicação de um processo elaborado de

estimativas indistintamente para todo projeto ou atividade do
desenvolvimento de um software, cabe analisar se o custo adicional relativo
à sua aplicação é compensado pelos resultados efetivamente obtidos. Às
vezes, dependendo do tamanho do projeto (principalmente em projetos de
manutenção), pode ser mais razoável utilizar um método de estimativa
direta simples que produza um resultado satisfatório, com uma margem de
erro aceitável, a utilizar outro que exija maior quantidade de recursos para
sua execução e a utilização de algum software complexo para a realização
de uma garimpagem de dados históricos a partir de uma fonte externa
obtida no mercado. Algumas organizações ponderam que a atividade de
estimativa deve corresponder a 2% do esforço do projeto, 1% para as
estimativas iniciais e 1% para os demais refinamentos das estimativas ao
longo do projeto.

Questões de Fixação
1. A manutenção de uma base de dados históricos
estimados e realizados sobre os projetos de software
pode trazer uma série de benefícios para as organizações.
Cite alguns desses benefícios sob os pontos de vista de
uma empresa fornecedora e de uma empresa
consumidora de produtos de software.
2. Qual a primeira atividade a ser realizada em um
processo de estimativa de um projeto de software?
3. Qual o propósito principal da execução de um processo
de estimativa?
4. Cite alguns fatores que causam a contraindicação do uso
de LOC para as estimativas de tamanho dos projetos.
5. Que são os métodos diretos de estimativas? Cite
exemplos.
6. Que são os métodos derivados de estimativas? Cite
exemplos.
7. Por que a técnica de Backfiring apresenta diferenças
significativas em seus resultados se comparados aos
valores reais obtidos em PF?
8. Quais são as vantagens obtidas ao utilizar uma técnica
de estimativa como a contagem indicativa, se comparada
à contagem detalhada dos pontos de função? Em que
casos essa técnica é mais indicada?
9. Quais são os benefícios que o indicador de fator de
crescimento pode trazer para a organização?
10. Como a estimativa de tamanho pode auxiliar na
obtenção da estimativa de esforço?
11. Como a estimativa de duração pode ser derivada a
partir da estimativa de esforço?
12. Por que não existe uma relação linear entre o prazo
para a conclusão de um projeto e a quantidade de
recursos alocados?
13. Por que é preciso tomar cuidado ao utilizar indicadores
obtidos do mercado?
14. Quais são os tipos de indicadores úteis para cada tipo
de organização, fornecedora e consumidora de produtos
de software?
15. Qual a importância da relação entre a contribuição de
cada tipo de função (ALI, AIE, EE, SE, CE) e o tamanho
total do sistema?
16. Efetue a contagem indicativa e estimativa do primeiro
estudo de caso do capítulo 8 e compare os valores com a
contagem detalhada.

Bibliografia

1. AGUIAR, M. A Produtividade dos Projetos de

Desenvolvimento. Developers Magazine , fev. 2003.
2. BOEHM, B. et al. Software Cost Estimation With
COCOMO II . Prentice Hall, 2000.
3. BROOKS, F. The Mythical Man-Month: Essays on
Software Engineering. Addison-Wesley, 1995.
(Anniversary Edition).
4. DEKKERS, C.; GUNTER, I. Using “Backfiring” to
Accurately Size Software: More Wishful Thinking Than
Science? IT Metrics Strategies , v. VI, n. 11, nov. 2000.
Cutter Consortium. Disponível em:
<http://www.qsma.com/pdfs/ITMSVol_VI11.pdf>.
Acesso em: 10 nov. 2000.
5. GARMUS, D.; HERRON, D. Function Point
Analysis: Measurement Practices for Sucessful Software
Projects. Addison-Wesley, 2000.
6. IFPUG. Frequently Asked Questions . Disponível em:
<http://www.ifpug.org/about/faqs.htm>. Acesso em: 19
fev. 2013.
7. ______. Guidelines to Software Measurement:
Release 1.1. International Function Point Users Group,
1996.
8. JONES, C. Applied Software Measurement . 2. ed.
Nova York: McGraw-Hill, 1996.
9. LAWRIE, R.; RADFORD, P. Using Functional Sizing
in Software Project Estimating: Charismatek Software
Metrics. Disponível em:
<http://www.charismatek.com.au/_public1/pdf/estim.pdf
>.
10. LONGSTREET, D. Estimating Software
Development Effort . Disponível em:
<http://www.SoftwareMetrics.com/Articles/estimating.ht
m>. Acesso em: 19 fev. 2013.
11. MAXWELL, K. Collecting Data for Comparability:
Benchmarking Software Development Productivity.
 IEEE Software . Disponível em: <http://www.datamax-
france.com/ieee01.pdf>. Acesso em: 10 set. 2001.
12. MAXWELL, K.; FORSELIUS, P. Benchmarking
Software Development Productivity. IEEE Software .
Disponível em: <http://www.datamax-
france.com/ieee00.pdf>. Acesso em: 15 jan. 2000.
13. MELI, R.; SANTILLO, L. Function Point
Estimation Methods: A Comparative Overview.
Disponível em:
<http://www.dpo.it/english/resources/papers/ 1999-
fesma-fpestmet-en.pdf>. Acesso em: 8 mar. 1999.
14. NESMA. Early Function Point Counting.
Disponível em:
<http://www.nesma.nl/english/earlyfpa.htm>. Versão
traduzida para o português disponível em:
<http://www.fattocs.com.br/traduzido/earlyfpa.asp>.
Acesso em: 27 dez. 2006.
15. PETERS, K. Software Project Estimation . Software
Productivity Center Inc., 1999. Disponível em:
<http://spc.ca/downloads/resources/estimate/estbasics.pd
f>. Acesso em: 15 jan. 1999.
16. PUTNAM, L.; MYERS, W. Measures for Excellence:
Reliable Software on Time, Within Budget. Yourdon
Press, 1992.
17. SILVEIRA, M.; AGUIAR, M. Backfiring: Um Atalho
ou uma Estrada que não Leva a Lugar Algum? Brazilian
Function Point Users Group, 2001. Disponível em:
<http://www.bfpug.com.br/Artigos/Backfiring_Marcio_
Mauricio.htm>. Acesso em: 20 fev. 2002.
 10

Aplicações em Contratos de
Desenvolvimento de Software

Introdução
A Análise de Pontos de Função (APF), quando de sua concepção, teve o
principal propósito de servir como insumo para quantificar a produção de
software em estudos de produtividade. Da medição da produção passou a
ser aplicada em seu planejamento, na estimativa de unidades de tamanho, a
partir das quais se estima o esforço ou custo.
Dentre os vários usos da APF, essa ligada à estimativa tornou-se tão
popular que o método é quase sinônimo de estimativa. Mesmo em situações
onde o que cabe é uma medição, ainda hoje não é incomum chamar de
“estimar” a contagem de pontos de função (ou medição do tamanho
funcional).
Uma situação como esta é quando a medição do tamanho funcional é
usada para medir os resultados entregues por uma fábrica de software para
determinar o valor a ser pago a ela. Em um contexto como este, o objetivo
do método não é estimar custo ou esforço, mas prescrever o valor das
entregas independentemente de quanto custo ou esforço efetivamente
tenham sido empregados.
 Atualmente esta é uma das principais aplicações do método em
contratos para o desenvolvimento, manutenção e migração de software. O
objetivo deste capítulo é explorar esses diferentes usos do tamanho
funcional em contratos, começando pelos principais desafios na contratação
de software.

Desafios na Contratação de Software

Todos aqueles que contratam ou são contratados no empreendimento de
projetos de software podem relatar pelo menos uma experiência cujo
relacionamento entre as partes foi prejudicado em função de o projeto
exceder as expectativas iniciais de custo, escopo ou prazo e quem seriam os
onerados por isso.
Quando é feita uma análise mais detalhada desses problemas, é possível
identificar alguns aspectos em comum que contribuem para a
materialização de tais situações, como:
• A ambiguidade, falta de clareza ou de entendimento dos
requisitos. Com a correta aplicação das técnicas atuais de
levantamento, análise e gerenciamento de requisitos esse
ponto pode ser superado. Neste aspecto a contagem de
pontos de função pode ajudar, pois traz como benefício
adicional a validação e o correto entendimento dos
requisitos do usuário.
• A inabilidade para realizar estimativas confiáveis. A
indústria de software é famosa desde o seu surgimento
pela sua deficiência na realização de estimativas.
Entretanto, desde então houve um grande avanço nos
métodos de estimativa e este deveria ser um problema
solucionado. Porém, ainda é necessário que esses
métodos sejam disseminados entre os profissionais e
 também que haja uma mudança de cultura. Não há
nenhum método mágico; sem os dados adequados, a
estimativa fornecida também será inadequada. Essa
habilidade deve estar presente tanto no cliente (para
elaboração de previsões orçamentárias e validação de
propostas) quanto no fornecedor (para a elaboração da
sua proposta).
• Domínio de problema não muito bem compreendido ou
sujeito a uma dinâmica intensa. Nesse caso o risco do
projeto é maior. Para que as expectativas não sejam
frustradas, elas devem ser antes de tudo realistas. Uma
mudança significativa de requisitos acarretará alterações
no custo ou no prazo. Deve haver um gerenciamento
muito eficaz do escopo para que esses desvios não
comprometam o projeto. A forma de contratação
também deve ser flexível para acomodar essas
mudanças.
• Pressões externas não gerenciadas: muitos projetos têm
seu prazo ou custo definidos (ou impostos) por pressões
externas. Do lado do cliente, por exemplo, há a
necessidade de disponibilizar um produto ao mercado
em um prazo determinado. Esse prazo representa uma
janela de oportunidade que, se for perdida, inviabilizará
o produto. Se o fornecedor aceita essa pressão (com
receio de perder o negócio) sem analisar se o projeto é
exequível naquele prazo e escopo, um problema está
criado.
 Certamente, além destes aspectos, existem inúmeros outros fatores que
podem levar a divergências entre cliente e fornecedor, entretanto os que
foram destacados são os mais comuns. O erro na escolha da melhor forma
de contratação do fornecedor pode agravar a situação.
A seguir, são apresentadas três modalidades de contratação de
desenvolvimento de software mais comuns: homem/hora, preço global fixo
e preço unitário; com suas vantagens e desvantagens do ponto de vista do
cliente e como o tamanho funcional pode ser utilizado para obter benefícios
em cada caso.

Modalidade de Contratação Homem-

Hora
Esta é uma modalidade de contratação cuja remuneração do fornecedor
é orientada ao processo “interno” à produção de software. O preço final é
determinado a partir de considerações como: quanto trabalho ele envolve,
qual o perfil e a quantidade de profissionais mobilizados em sua execução e
a sua complexidade de gestão. O controle do preço está nas mãos do
fornecedor, que tem maior competência quanto a esses aspectos técnicos do
projeto (ou pelo menos isso é o esperado) em relação ao cliente, cujo
negócio costuma ser outro que não o desenvolvimento ou manutenção de
software.
Na contratação de homem/hora, também conhecida como body
shopping ou time and material , o cliente contrata profissionais para
alocação no desenvolvimento do software, muitas vezes em conjunto com
sua equipe própria, nem sempre com apenas um fornecedor de mão de obra,
e uso de sua própria infraestrutura. A remuneração do fornecedor é
calculada com base no nível de qualificação e experiência dos profissionais
alocados, nas horas realizadas e em outras eventuais despesas. Na prática, o
profissional contratado atua como um funcionário dedicado à empresa,
contudo sem o vínculo empregatício formal.
Esse modelo é de simples gestão e apresenta uma grande flexibilidade
tanto para o cliente quanto para o fornecedor. Uma vez que a relação
comercial foi estabelecida, a empresa contratante tem a possibilidade de ser
mais ágil no atendimento aos picos de demanda de serviço. No caso da
mudança dos requisitos, não é necessária uma nova renegociação de
contrato com o prestador de serviço, todavia um aumento de escopo
acarreta um aumento de esforço (horas) e também de preço. E é justo que o
prestador de serviço seja remunerado por esse esforço adicional, pois a
gerência do escopo e dos requisitos é responsabilidade direta do cliente.
Essa flexibilidade, porém, tem seu preço. Normalmente em um
relacionamento desse tipo, há a garantia da contratação de uma quantidade
mínima de horas por um determinado período, em geral mês ou ano.
Quando a demanda dos serviços diminui, pode haver uma subutilização dos
profissionais contratados, ou seja, desperdício de recursos.
O aspecto mais crítico dessa modalidade de contratação é que o
cliente é responsável por gerenciar todo o serviço, inclusive a
produtividade do fornecedor . Isso exige um nível de competência que
pode não estar disponível internamente. Além disso, a remuneração do
prestador de serviço não está vinculada aos resultados produzidos, mas
apenas à quantidade de horas realizadas. Não há nenhum estímulo ao
fornecedor para a manutenção ou o aumento dos níveis de produtividade e
qualidade; o que deveria ser uma responsabilidade exclusiva sua.
Outro obstáculo é com relação às garantias do serviço prestado. Caso a
execução do serviço envolva mais de uma empresa, é muito difícil isolar as
responsabilidades de cada empresa e exigir a garantia.
Pode-se aplicar a APF para monitorar a produtividade da equipe. Para
tanto, são necessários dois dados: esforço (horas) e resultados (pontos de
função). Por exemplo: uma empresa terceiriza sua equipe de
desenvolvimento. A equipe do fornecedor tem como função exclusiva
atender às várias ordens de serviço. Analisando ao longo do tempo os
indicadores, apurou-se que no primeiro trimestre do contrato foram
realizadas 30 ordens de serviço de manutenção, utilizando 1.512 horas,
totalizando 120 pontos de função. Nesse período a produtividade média
alcançada foi de 40 pontos de função por Homem- Mês. Veja os gráficos em
seguida.
Uma análise exclusiva do número de horas não é conclusiva quanto à
produtividade da equipe, porém quando se analisam os dois fatores em
conjunto, encontra-se o gráfico mostrado na Figura 10.2.
 Figura 10.1: Evolução da relação esforço x produção.

Figura 10.2: Evolução da produtividade no tempo.

Neste gráfico é possível avaliar claramente o período de acomodação da

equipe ao novo ambiente durante os três primeiros meses. A partir do
quarto mês a produtividade foi diminuindo até se estabilizar em um novo
patamar. Evidentemente alguma coisa está errada!
Além do uso do tamanho funcional na obtenção de indicadores de
produtividade, indicadores de qualidade também podem ser definidos para o
acompanhamento de dimensões como quantidade de defeitos por ponto de
função entregue, ou mesmo a quantidade de pessoal envolvido com
manutenção por ponto de função.
O uso do tamanho funcional em contratos de homem-hora é um
instrumento para trazer visibilidade de problemas, como a queda na
produtividade. Quando esse cenário é identificado, normalmente há o
direcionamento para a contratação de projetos a preço fechado, assunto que
será abordado em seguida.
Em termos práticos, as organizações têm buscado elevar seu nível de
governança corporativa com relação à TI. A contratação de serviços de
software por homem-hora é cada vez menos aceita pelos clientes, no
máximo tolerada como um meio de transição. O uso da APF no cenário
descrito nesta seção cumpre também o papel de tornar a transição mais
suave.
Tabela 10.1: Vantagens e desvantagens da modalidade de
contratação de homem-hora para o desenvolvimento de software.

Vantagens
Visibilidade do Trabalho - geralmente o
desenvolvimento do projeto é feito internamente,
facilitando sua supervisão. Contudo, esse trabalho
acaba por deslocar profissionais internos à
organização de atividades fim de seu negócio.
Simplicidade - pouca tramitação burocrática e
esforço na negociação da alocação de recursos no
caso de mudanças de requisitos ou outros aspectos
conjunturais.
Desvantagens
Controle da Produtividade - o
contratante é responsável pelo
acompanhamento da produtividade do
serviço.
Problemas Trabalhistas - a questão de
haver ou não a caracterização do
vínculo empregatício pode ser
levantada em eventuais litígios.
Ausência de Garantia - dificuldade de
identificar a responsabilidade e, como
consequência, exigir a garantia do
serviço quando ele é realizado por
equipes mistas de várias empresas.
Modalidade de Contratação Preço
Global Fixo
Essa modalidade privilegia a abordagem de projeto com um início e fim
bem definidos (além, é claro, do escopo). Exige maior nível de organização
tanto do cliente quanto do fornecedor. Quanto melhor definidos estiverem
os requisitos, menor a chance de atritos entre as partes.
Em geral, o fornecedor não dispõe de muita informação sobre o domínio
do problema ou não dispõe de tempo para a análise detalhada dos requisitos
para a elaboração da proposta comercial. Como consequência, haverá um
subdimensionamento ou superdimensionamento do orçamento proposto.
Quando a concorrência é intensa, é mais provável que o primeiro caso
ocorra.
Ambos os casos anteriores são indesejáveis. No primeiro, o fornecedor
terá dificuldades em atender ao cliente. Se os requisitos não foram bem
definidos, é provável que haja um impasse e uma nova negociação
comercial tenha de ser conduzida, quase sempre com desgaste para ambos
os lados. Ainda que os requisitos tenham sido bem definidos, o orçamento
proposto pelo fornecedor pode ter sido tão subdimensionado que a
qualidade do produto seja seriamente afetada ou o projeto sequer seja
concluído.
Em projetos de longa duração, é necessário estabelecer pontos de
controle por meio dos quais a empresa contratante possa acompanhar o
progresso do projeto. A definição desses pontos deve ser realizada antes
mesmo da contratação efetiva do serviço, visto que o contratado deve estar
ciente desses pontos e preparar-se para apre- sentar os resultados previstos.
Muitas empresas erram ao não planejar esse acompa- nhamento. A
consequência mais leve é a sensação de perda de controle. A mais grave é
só perceber a inabilidade do contratado para realizar o serviço tarde demais.
Nessa modalidade o quanto se paga também está sob o controle do
fornecedor. É muito comum que o racional de formação do preço esteja
fundamentado na estrutura analítica de projeto e na quantidade horas e
perfil do profissional alocado à realização da atividade. O mesmo acontece
nas mudanças (ou alegadas mudanças) que ocorrem durante o projeto. Na
medida em que a estrutura de preços é feita dessa forma, tal qual na
contratação em homens-hora, o controle está com aquele que detém o
conhecimento técnico da engenharia de software e aplicação das suas
disciplinas.
Um benefício do tamanho funcional nesses casos é seu uso como um
fator de normalização, que muda o paradigma da estruturação do racional
de preços de uma perspectiva “interna” à engenharia de software para uma
perspectiva “externa” à contratante.
A contratante estabelece acordos de nível de serviço quanto a prazo e
qualidade, exigindo que seja apresentada uma planilha com a análise de
pontos de função aplicada na estimativa de escopo do projeto, e solicitando
que seja informada a contingência técnica referente ao nível de informação
disponível quando da solicitação de proposta. Com isso ela pode comparar
as propostas de diferentes fornecedores não em termos de perfil e
quantidade de profissionais, mas em termos de sua produtividade.
Uma experiência que pode se revelar interessante não só para fins do
processo de contratação, mas para o próprio desenho da solicitação de
proposta, é a própria contratante realizar a estimativa de escopo, aplicando a
análise de pontos de função e, com isso, avaliar se realmente a contratação
de um projeto cotado a preço global fixo é a melhor opção. Ao realizar a
estimativa, é possível perceber que o nível de informação é tão baixo que,
ao transferir o risco do escopo para o fornecedor, ou se inclui um custo
muito alto de contingência para esse risco ou se corre o risco de não receber
o produto esperado.
Outra aplicação da APF no contexto de contratos de preço global fixo é
a valoração das solicitações de mudança. A contratante pode estimar o
escopo do projeto original e, com base no resultado da análise, pode
calcular o valor unitário cobrado pelo fornecedor. O serviço adicional para o
qual se solicitou uma proposta pode também ser dimensionado em pontos
de função e aplicado o valor unitário calculado para o projeto original. Se o
preço resultante for significativamente diferente do valor cobrado pelo
fornecedor, a empresa contratante pode questionar as causas para essa
discrepância.
Um fator que complica o uso desta abordagem é assumir que os
requisitos não mudam após o início do projeto. Assim como o mundo é
dinâmico, os requisitos também o são. Quanto maior a duração do projeto,
mais provável que haja alteração nos requisitos. E é difícil estimar quanto
essas alterações afetam o orçamento proposto originalmente pelo
fornecedor. Segundo [Jones C., 2001], mais de 2% dos requisitos mudam
mensalmente após a fase de requisitos. Neste caso, é quase certo que seja
necessário uma nova negociação. Se este for o caso, dificilmente o cliente
irá obter as mesmas condições originais, pois dependendo do momento em
que o projeto esteja, não haverá concorrência e tampouco uma unidade para
comparar o preço originalmente cobrado com o preço cobrado pelas novas
características solicitadas.
Tabela 10.2: Vantagens e desvantagens da contratação do
desenvolvimento de software a preço global fixo.

Vantagens
Transferência de Riscos - variações na produtividade
e escopo durante a execução do projeto são de
responsabilidade do fornecedor.
Previsibilidade de Custos - se os requisitos foram
definidos de forma adequada e as mudanças forem
pequenas, o orçamento será cumprido.
Garantia - após a entrega do produto, a
responsabilidade de garantia sobre eventuais problemas
de conformidade à especificação é bem definida e pode
ser cobrada, inclusive, se necessário, com amparo
legal. Tal fato faz com que seja interesse mútuo a
qualidade do produto.
Desvantagens
Preço Contingenciado - para
absorver os riscos de requisitos
mal definidos ou de um
crescimento de escopo, o
fornecedor acrescenta margens de
segurança à proposta comercial.
Desgaste com o Fornecedor - se
os requisitos forem nebulosos ou o
fornecedor subestimar o custo,
haverá um desgaste em
renegociações contratuais.
Dependência - se não houver a
transferência adequada de
conhecimento do projeto, o cliente
pode ficar “refém” do fornecedor.

Modalidade de Contratação Preço

Unitário
Para organizações que demandam rotineiramente projetos de software,
contratar a preço global fixo implica negociar projeto a projeto. Isso pode
ser oneroso demais quanto mais burocrático for o seu processo de aquisição.
Grandes empresas e organizações públicas costumam vivenciar esta
situação. Neste caso a opção preferencial é estabelecer uma negociação
única que possa valer para os diversos projetos que serão demandados ao
longo do contrato. A contratação a preço unitário alcança este aspecto.
Dado um volume de entregas desejado no período, por exemplo, 10.000
PFs/ano, negocia-se o preço da unidade para que ao longo do contrato os
projetos possam ser demandados, e no conjunto respeitem o limite deste
volume.
Nesse modelo é definida uma remuneração para o fornecedor sobre
elementos do projeto. Esse elemento pode assumir várias formas, como tela,
relatório, tabela, caso de uso, linha de código, stored procedure ou ponto de
função. Em tese é um modelo que procura equilibrar os riscos da
contratação por homem-hora e por preço global fixo. Nesse caso, a
produtividade passa a ser atribuição do fornecedor, pois há o risco de
prejuízo caso haja atraso na produção dos elementos. Por outro lado, no
caso de um aumento de escopo dos requisitos, mais elementos devem ser
construídos para o projeto e o fornecedor será remunerado por isso.
O grande desafio dessa abordagem é encontrar um elemento que possa
ser reconhecido de maneira inequívoca, uniforme e consistente por ambos,
cliente e fornecedor, e que também possua uma natureza não
excessivamente técnica.
Por exemplo, o gerente de projetos de uma organização tem a seguinte
situação: um fornecedor foi contratado para desenvolver um sistema e o
escopo foi definido apenas superficialmente. Em tese, tal situação não é um
problema, visto que a remuneração do contrato não é a preço global fixo
nem em apropriação de horas. Sua remuneração é baseada na quantidade de
telas, arquivos e relatórios do sistema. Contudo, o principal problema
enfrentado é a inflação verificada nesses objetos de contagem. Por outro
lado, é provável que o fornecedor tenha problemas da mesma natureza.
Muitas vezes, por diversos motivos, pode ser mais adequado utilizar dois
arquivos em lugar de um. Ou dividir uma tela em várias. Sempre que uma
destas situações ocorrer, será necessário gastar mais energia com
negociação do que normalmente o seria.
O caso apresentado leva à percepção de uma busca por dois principais
objetivos: encontrar uma alternativa à apropriação de horas como unidade
de remuneração de contratos e utilizar uma unidade que elimine as
tecnicidades que tanto dificultam a comunicação entre os profissionais de
tecnologia da informação e seus clientes externos e internos na organização.
A aplicação do tamanho funcional como solução alternativa aos casos
expostos apresenta uma série de vantagens. Seu uso é bastante semelhante
ao caso em que telas, arquivos e relatórios são utilizados como base para a
medição do serviço. Contudo, em pelo menos dois aspectos, ela facilita o
relacionamento entre as partes.

Pontos de Função como Unidade

Padrão
A APF é um método padrão de medição funcional. Centenas de
empresas e profissionais de todo o mundo participam das ações do IFPUG,
que é a organização responsável pela manutenção e evolução da técnica.
Essas ações procuram garantir a consistência e a uniformidade da aplicação
do método. Experiências de governos e empresas de todo o mundo relatam
casos de sucesso em sua aplicação. Embora a ênfase neste livro seja a APF
no padrão IFPUG, quaisquer dos outros métodos de medição funcional
citados no capítulo 2 podem cumprir os mesmos objetivos.

Pontos de Função que Facilitam a

Comunicação
O vocabulário da APF utiliza terminologia e define objetos de contagem
que independem da tecnologia utilizada para o desenvolvimento do
software. A eliminação dessas tecnicidades facilita a compreensão entre as
partes e é um importante fator de alavancagem da comunicação entre elas.
Não é relevante para a APF se determinado grupamento lógico de dados foi
implementado em dois, três ou quantos arquivos forem convenientes. Não é
relevante se no espaço de uma tela não couberam todos os campos
necessários para a conclusão de um processo elementar do negócio. O
relevante é a perspectiva do negócio como entendido e validado pelo
usuário.
O Cliente é o Dono do Escopo
Como a medição funcional é realizada com base na visão externa do
usuário, em contraste com uma visão interna da engenharia de software, a
contratante passa a ter o efetivo controle e a gestão do escopo. Não se entra
no mérito (a cada momento) quanto à complexidade do trabalho, o perfil
dos profissionais mobilizados ou a sua quantidade. É um modelo em que o
tamanho funcional não cumpre o papel de estimar esforço ou custo, mas de
prescrever o quanto se pagará independentemente de seu custo ou do
esforço efetivos.
Como nos contratos de preço global fixo, é um negócio de risco,
contudo melhor distribuído. As considerações sobre a complexidade do
trabalho em suas mais diversas dimensões (exceto escopo das funções
solicitadas e entregues pelo usuário), quanto ao perfil e à quantidade dos
profissionais alocados, devem ser feitas em um momento preliminar:
quando da apresentação do preço unitário.
Uma vez determinado o preço unitário, ele, juntamente com a
quantidade de pontos de função medidos, prescreve o quanto será pago ao
fornecedor para cada entrega. Esse valor pode ser pontualmente superior ou
inferior àquele efetivamente realizado, pois o modelo se justifica em termos
de um cenário onde há uma grande quantidade de funções sendo entregues.
A análise econômica não deve ser feita pontualmente a cada demanda, mas
considerando um lote em um período que permita avaliar aquilo que se
recebeu a menor do realizado com aquilo que se recebeu à maior.
Tabela 10.3: Vantagens e desvantagens da contratação do
desenvolvimento de software a preço unitário - Pontos de Função.

Vantagens
Melhor distribuição de
responsabilidades - atribuição da
responsabilidade pelas variações
da produtividade e escopo àqueles
que efetivamente as causam. Paga-
se pelo que se recebe.
As vantagens apresentadas para os
projetos a preço fixo aplicam-se
também aos contratados por
pontos de função.
Desvantagens
Necessidade de pessoal qualificado na técnica de
APF - nessa abordagem há a necessidade de pessoal
qualificado na técnica (preferencialmente especialistas
certificados) tanto no cliente quanto no fornecedor.
Tamanho mínimo de projeto - para projetos
pequenos, por exemplo, 50 pontos de função, não
costuma haver uma boa relação entre o tamanho
funcional e o esforço envolvido. Contudo, se a análise
 for feita em um conjunto de projetos pequenos, as
distorções tendem a se anular.

Manutenção Corretiva
A medição funcional representa uma quantificação dos requisitos
funcionais do usuário para o software. Não existe ponto de função
“defeituoso” . Se entendermos defeito como uma falha no atendimento aos
requisitos estabelecidos pelo usuário, conclui-se que toda manutenção
corretiva não é motivada por mudança de requisito do usuário. Ela existe
para reparar defeitos inseridos no software durante a sua construção.
Portanto, se não há mudança de requisitos funcionais, não há o que se medir
em pontos de função para essa manutenção.
Cabe considerar que só é possível caracterizar um defeito de forma clara
e inequívoca se houver uma boa especificação de requisitos. Se a
especificação de requisitos estiver ruim (como muitas vezes ocorre), ou
seja, incompleta, ambígua, genérica, o fornecedor pode alegar (e muitas
vezes com razão) que a questão apontada pelo cliente não é um defeito de
construção, pois foi construída conforme o seu entendimento daquele
requisito, que dava margem a múltiplas interpretações.
Como remunerar uma manutenção corretiva em um contrato por pontos
de função, uma vez que ela não é medida? Simples; não se paga!
Considerando que a correção é de defeitos resultantes de serviços
previamente executados pelo fornecedor, o cliente já o remunerou para que
o serviço fosse feito corretamente. Além disso, há que se considerar que
parte das manutenções corretivas adicionam novos defeitos ao software.
Não há sentido em pagar para corrigir o que já deveria ter sido entregue
correto originalmente. Isso é um estímulo para que o fornecedor entregue
software com baixa qualidade. No âmbito de contratos públicos,
remunerar para corrigir defeitos na execução de serviços contratados é
ilegal (artigo 69 da Lei 8.666/1993).
Mas e se a manutenção corretiva é sobre um software legado
desenvolvido por outro fornecedor que não o atual, este deve executar o
serviço sem remuneração? Não necessariamente. O cliente deve prever no
seu contrato como deseja que isso seja tratado. São três alternativas
possíveis:
• Não remunerar qualquer manutenção corretiva. Esta
abordagem é simples e prática para o cliente. E também
pode ser justa para o fornecedor, desde que esta regra
esteja clara no início da negociação e que o cliente
consiga demonstrar qual tem sido a incidência histórica
de defeitos nos seus sistemas. Neste caso o fornecedor
irá formular o seu preço sabendo que terá que absorver
esse custo eventual. Se a incidência de defeitos for baixa,
isso na prática terá impacto pequeno na formulação de
preços. Porém se o cliente não possui uma visão clara do
nível de incidência de defeitos, ou se essa incidência for
alta, significa transferir um risco alto para o fornecedor,
que vai embutir esse risco no seu preço. Neste caso não
será bom negócio para nenhuma das partes.
• Remunerar para corrigir defeitos preexistentes. A
princípio parece uma abordagem mais justa. Defeitos
que não foram causados pelo fornecedor provocam
manutenções corretivas que serão remuneradas. Defeitos
causados pelo próprio fornecedor não têm a manutenção
remunerada, pois estão na garantia do serviço prestado
por ele previamente. A dificuldade nesta questão é de
ordem mais prática. Como o cliente identifica se o
defeito é novo ou preexistente ao contrato? Para que isso
seja possível, é necessário que alguém no cliente
conheça tão bem tecnicamente todo o software quanto o
próprio fornecedor. Assim ele conseguirá verificar se o
que o fornecedor apontou como defeito preexistente
procede ou não. Isso implica em saber quais pontos do
 código-fonte terão de ser alterados, se as alterações estão
corretas e se o problema no código-fonte existia na
versão desse código-fonte antes de o contrato ser
iniciado. Ou seja, o cliente está na mesma situação que
muitos vivenciam quando levam seu carro para uma
oficina. Se ele entende de mecânica, saberá evitar pagar
por manutenções desnecessárias; caso contrário, resta
apenas confiar no que a oficina disser. Enfim, adotar esta
abordagem significa transferir o controle da situação
para o fornecedor; algo indesejável para a maioria dos
clientes.
• Remunerar para corrigir funções. Esta abordagem é mais
pragmática. Consiste em identificar em quais funções o
defeito se manifestou (isso é algo fácil de o próprio
cliente verificar). Identificadas as funções “defeituosas”,
o cliente verifica se essas funções foram criadas ou
alteradas pelo fornecedor durante o contrato. Se sim, a
manutenção corretiva deve ser feita sem remuneração,
pois a ideia é de que todo pedaço de software que o
fornecedor mexa entre automaticamente em garantia.
Caso o fornecedor não tenha criado ou alterado as
funções durante o contrato, remunera-se pela
manutenção corretiva (por exemplo, da mesma forma
que uma alteração funcional) e daí em diante essas
funções passam a compor o conjunto das funções do
software que estão sob a sua garantia. E como o cliente
irá verificar quais funções foram criadas ou alteradas
pelo fornecedor durante o contrato para exigir a
 garantia? Simples, mantendo a contagem de pontos de
função das suas aplicações. À medida que o fornecedor
executar os projetos no contrato, as medições finais
desses projetos devem atualizar a contagem das
aplicações, permitindo o controle fácil de quais funções
estão em garantia.

Itens não Mensuráveis

Sabendo que a APF mede apenas requisitos funcionais do usuário para o
software, deve-se prever na contratação de serviços de desenvolvimento e
manutenção de software, como remunerar as eventuais atividades que serão
demandadas ao fornecedor e que não possuem relação direta com a entrega
de requisitos funcionais.
Casos desta situação são manutenções que afetam apenas aspectos não
funcionais do software. Por exemplo, adequação do software para executar
em um novo navegador web. Esse tipo de manutenção não vai mudar a
funcionalidade do software. Na visão do usuário todas as tarefas e os
serviços que o sistema desempenhava continuarão a ser desempenhados
igualmente, apenas agora com a opção de usar mais um navegador web.
Como não houve mudança de requisitos funcionais, essa manutenção não
será mensurável pela APF. O fornecedor deve ser remunerado por esse
serviço. Logo, conclui-se que a medição do contrato não pode ficar restrita
apenas ao que diz o manual do IFPUG.
Embora a maioria das demandas de um contrato de desenvolvimento e
manutenção de software seja mensurável pela APF, ainda assim deve-se
prever alternativas para medir o serviço que o fornecedor tiver de executar e
que não possa ser medido pela APF. Idealmente deve-se buscar métricas
também objetivas para a medição desses serviços; mas como pode ser
difícil antecipar todas essas situações, é razoável deixar abertura para a
medição por homem-hora quando não houver métrica mais objetiva para a
medição disponível.
 O Roteiro de Métricas do SISP [SLTI-MPOG/2012] consolidou um
conjunto de situações usadas em algumas organizações para remunerar
demandas não mensuráveis por PF.

Uso de Deflatores na Manutenção

Em geral, a produtividade alcançada na execução de alteração e
exclusão de funcionalidades é superior à obtida para construção de novas
funcionalidades. A exceção a essa observação é o período de aculturamento
e acomodação verificado na transição entre duas equipes responsáveis pela
manutenção de determinado sistema. No processo de análise e avaliação de
impacto de uma manutenção, a equipe já conhecedora do domínio do
problema certamente leva grande vantagem em relação a uma equipe
recém-chegada. Muitas vezes uma empresa que deseja conquistar novos
mercados deve provisionar-se para esse período, considerando os ganhos de
produtividade futuros.
Para tornar o relacionamento mais claro e permitir maior linearidade
entre a quantidade de pontos de função e o esforço envolvido, algumas
organizações optam por usar a abordagem de melhoria da NESMA
(explicada no capítulo 7), pois ela possui uma granularidade de medição
mais fina do que a melhoria do IFPUG. Mas a abordagem mais comum é
uma simplificação do método da NESMA, em que o fator de impacto (ou
deflator) é fixo, em vez de variar conforme o tamanho da manutenção na
função. Embora essa simplificação seja uma medida menos refinada que a
abordagem da NESMA, é mais simples de aplicar e ainda contorna os
problemas da pouca granularidade do método IFPUG.
Exemplificando, em [Caixa, 2006], usa-se um deflator de 50% para as
funções que serão modificadas e um deflator de 25% para as funções que
serão excluídas da aplicação pelo projeto de melhoria. Ou seja, assim evita-
se que o cliente tenha de pagar o mesmo valor para uma função nova,
alterada ou excluída. Cabe destacar que não existe um padrão de mercado
para o valor desses deflatores. Idealmente é necessário desenvolver um
estudo para chegar a esses parâmetros de produtividade e da relação entre
os pontos de função incluídos (ADD) com os excluídos (DEL) e alterados
(CHG) em projetos realizados pela própria organização.
 A produtividade deve ser considerada não apenas para fins
orçamentários, mas também para avaliação de outros aspectos do
fornecedor. O cliente deve se preocupar com a garantia da capacidade dos
fornecedores em atender à sua futura demanda ao empreender essa
modalidade de contratação. A quantificação dessa demanda é parte
integrante da preparação das aquisições. Mesmo nos casos em que a
organização ainda não trabalhe com pontos de função, ela pode ser estimada
com base no dimensionamento das ordens de serviços passadas por um
período considerado representativo.
Deve ser ajustada com base nas expectativas de crescimento da
demanda e outros fatores que a administração considere relevantes quanto
ao cenário futuro - quando o serviço vier a ser executado. A apresentação de
documentos, atestando uma capacidade compatível com a estimativa da
demanda em termos de pontos de função, deve ser incluída durante o
processo de preparação de aquisições como um dos requisitos para a
proponente habilitar-se tecnicamente.
Outra preocupação menos frequente, mas que tem aumentado em
importância recentemente, é o estabelecimento de metas de desempenho
para outros aspectos, como qualidade e prazo.

Guia de Contagem (ou Guia de Métricas)

A técnica de análise de pontos de função é norteada pela visão do
usuário, que é uma definição formal das necessidades de negócio do cliente
em sua própria linguagem. Os desenvolvedores traduzem a informação do
usuário para o vocabulário da tecnologia da informação, objetivando
fornecer uma solução. A contagem dos pontos de função é alcançada
através da utilização da informação em uma linguagem que seja comum a
ambos, usuários e desenvolvedores.
Essa “visão do negócio” pode assumir as mais diversas formas.
Recomenda-se que alguns aspectos dessa visão sejam apresentados o
quanto antes ao fornecedor e que a organização contratante estabeleça sua
perspectiva sobre os casos em que possa haver múltiplas interpretações do
manual de práticas de contagem.
 Por exemplo, tanto na solicitação de propostas quanto no contrato pode
ser acrescentado um adendo com o padrão de interfaces com o usuário
(telas e relatórios). Para cada tipo de interface padrão são apresentadas as
diretrizes para a contagem dos pontos de função, conforme o manual de
práticas de contagem e a perspectiva da organização contratante. Esta
sugestão simplifica a contagem futura das transações do sistema e reduz a
probabilidade de contagens discrepantes entre o cliente e o forne- cedor.
Nesse documento também pode ser conveniente estabelecer exemplos para
a identificação e contagem dos grupos de dados e informações de controle
mantidos ou referenciados pelo sistema, caso haja situações que possam
suscitar várias interpretações.
Esse documento que citamos costuma ser chamado de Guia de
Contagem (ou de Métricas). É um documento de uso interno e específico a
uma organização, que orienta as medições feitas em pontos de função em
projetos de software. Sua característica é ter um enfoque bem específico das
situações que a organização vivencia nas suas contagens de pontos de
função. Ele contém um conjunto de lições aprendidas em questões relativas
às medições em PF. É um repositório de conhecimento das práticas de
contagem, fruto de discussão e análise dos profissionais da organização.
Embora exista o Manual de Práticas de Contagem do IFPUG que
contém todas as definições e regras para o processo de contagem de pontos
de função, as orientações contidas nele são apresentadas de maneira bem
geral. Isso é benéfico no sentido de fazer com que a APF seja aplicada em
uma variedade ampla de situações. Por outro lado, dificulta para alguns a
aplicação desses conceitos em situações específicas, especialmente quando
elas apresentam características distintas dos exemplos do manual do
IFPUG. O Guia de Contagem vem cumprir o papel de trazer os conceitos
gerais do manual do IFPUG para situações específicas de uma organização.
Também para as situações em que as regras do IFPUG não estão
suficientemente claras ou objetivas (existem ainda pontos da APF que são
alvo de trabalho do IFPUG), o Guia de Contagem irá tratar a situação de
forma objetiva e clara. E por fim, há situações em que uma organização
pode decidir tratar de forma diferente do IFPUG uma medição. Neste caso
isso deve estar explícito para todos os envolvidos, e o Guia é o local
apropriado para tanto.
O Guia de Contagem proporciona os seguintes benefícios:
• Aumenta a consistência entre contagens feitas por
diferentes profissionais: uma vez que as situações mais
comuns nas medições da organização estarão
exemplificadas no Guia, menor a chance de profissionais
diferentes usarem interpretações distintas nas medições.
• Centraliza a experiência da contagem envolvendo
diferentes tecnologias e domínios de problema (por
exemplo, sistemas em mainframe, múltiplas camadas,
workflow, business inteligence, batch etc.): mesmo para
profissionais experientes no uso da APF, quando estes se
deparam com situações não usuais, é comum o
surgimento de dúvidas. Com o Guia centralizando esse
conhecimento, um profissional experiente na APF, mas
acostumado a medir somente sistemas de determinado
tipo (por exemplo, mainframe), será capaz de medir
facilmente sistemas de natureza distinta (por exemplo,
business inteligence).
• Evita o retrabalho com a análise de questões recorrentes:
uma vez que determinada situação tenha gerado dúvida
na medição, esta é analisada e decide-se a melhor forma
de abordá-la. Esta dúvida e a abordagem adotada são
documentadas no Guia para que todos os envolvidos em
medições não precisem gastar tempo analisando
situações parecidas nem correndo o risco de decidirem
por uma abordagem diferente da adotada previamente.
As medições passam a ocorrer de forma mais rápida.
• Facilita o aculturamento de novos profissionais
responsáveis por contar pontos de função: o Guia acelera
 o aprendizado de novos profissionais da organização que
venham a se envolver com as medições, pois já traz a
resposta da maioria das dúvidas que um iniciante terá ao
aplicar a técnica.
• Maior convergência entre contagens e melhor
comunicação entre cliente e fornecedor: num contrato de
desenvolvimento e manutenção de software remunerado
por PF, o Guia ajuda a evitar muitas situações de
divergência nas medições de ambas as partes, ajudando
assim a melhorar a relação entre cliente e fornecedor.
O Guia de Contagem tem mais valor quanto mais específico for para
uma organização. Abordar situações genéricas já é papel do manual do
IFPUG. Portanto, copiar ou referenciar o Guia de outra organização limita o
potencial de benefícios que ele poderia proporcionar. Mas é extremamente
válido consultar outros guias para orientar a redação de um documento
próprio. Nas referências bibliográficas ao final deste capítulo destacamos
alguns editais de licitações que publicaram o Guia de Contagem adotado
por essas organizações, que é uma fonte de consulta interessante. Também
indicamos a leitura do Roteiro de Métricas de Software do SISP.

Decomposição do Custo (ou Esforço)

por Atividade do Ciclo de Vida
É desejável que a organização tenha a liberdade de substituir a qualquer
momento seu fornecedor ou contratar fornecedores distintos em diferentes
fases do ciclo de vida do projeto. Quando a contratação é baseada em
pontos de função, surge a seguinte questão: o ponto de função mede a
funcionalidade solicitada e fornecida pelo sistema ao usuário. Ele não mede
o trabalho de análise, projeto, codificação ou testes. Sendo assim, como é
possível remunerar o fornecedor por uma atividade específica do projeto?
Para permitir essa flexibilidade, é necessário “estratificar” o ponto de
função. Isso pode ser feito por meio do esforço médio empregado em cada
fase. Portanto, associa-se essa distribuição de esforço (que é variável de
acordo com o contexto de cada organização) ao ponto de função. As
Tabelas 10.4 e 10.5, apresentadas em seguida, mostram editais públicos em
que tal providência foi adotada.
Tabela 10.4: Fases e distribuição de esforço da Metodologia de
Desenvolvimento de Sistemas Estruturada para fins de
remuneração [Caixa, Concorrência 1/2006].

Fases da metodologia de desenvolvimento de software (%) de distribuição

Anteprojeto 3%
Planejamento 14 %
Análise da área de negócio 7%
Projeto do sistema de negócio 16 %
Projeto técnico e construção - análise 11 %
Projeto técnico e construção - programação 22 %
Homologação 16 %
Implantação 4%
Atividades exclusivas da CAIXA 7%

Tabela 10.5: Distribuição da remuneração do projeto de acordo com

a atividade do ciclo de vida [FNDE, Pregão 25/2011].

Fase do projeto (%) de distribuição

Iniciação 10%
Elaboração 15%
Construção 35%
Transição 40%

Exemplificando a tabela anterior, suponha que a organização contratou

um fornecedor para desenvolver um projeto de 1.000 PF a R$ 500,00/PF -
valor total do projeto R$ 500.000,00 (assumindo que não haverá mudanças
nos requisitos). Ao final do levantamento de dados ele deve ser remunerado
em R$ 50.000,00.
Em vez de utilizar as disciplinas da engenharia de software para
adiantamentos antes da entrega final do software, uma tendência é o uso das
fases do ciclo de vida, sendo o modelo da IBM RUP bastante observado
(Iniciação / Elaboração / Construção / Transição). Ao contrário daqueles
ilustrados neste capítulo até agora, há exercício concomitante de diferentes
disciplinas em cada fase. Em projetos longos, eventualmente de mais de um
ano, deve-se tomar muito cuidado com a sua gestão para evitar que, apesar
do uso de uma estratégia iterativa e incremental, não acabe por cair em uma
“quase cascata” em que cada disciplina acontece praticamente em
sequência. Uma boa estratégia é usar o plano de iteração e os artefatos
entregues e aceitos como base para o cálculo do valor agregado pelo projeto
até o momento do cálculo do adiantamento.
Em projetos ágeis, o que não deve ser feito é medir uma mesma função
mais de uma vez no cômputo do valor do projeto, como se tratasse de uma
solicitação de mudança. A tese dos entusiastas do modelo ágil é de que o
retrabalho seja pago por outros fatores de produtividade. Se incluirmos esse
retrabalho na medição, como confirmar isso? Para fins de pagamentos de
adiantamentos antes da entrega final do projeto, cabe a mesma sugestão:
usar o plano de iteração (que recebe diferentes nomes conforme as
diferentes abordagens ágeis que se adota) para esse fim.

Qual o Preço de um Ponto de Função?

Quando a organização decide contratar serviços de desenvolvimento de
sistemas, uma métrica fundamental é o preço por ponto de função. A
decisão de passar a trabalhar com pontos de função deve trazer benefícios
na relação entre o custo total, incluídos não só o preço pago ao fornecedor,
mas todas as despesas acessórias envolvidas, como a utilização de recursos
internos e as despesas administrativas, e a qualidade dos produtos
entregues. Um dos objetivos que a administração determina é que, ao
comparar os resultados entre a contratação com base em pontos de função e
a contratação do mesmo projeto a preço global fixo, a primeira deve trazer
melhores resultados que a segunda.
Os responsáveis pela condução desse processo devem determinar
métricas que possam, se não responder esta pergunta, pelo menos dar
indícios quanto às expectativas de preço e outros indicadores que possam
ser colocados em acordos de nível de serviço.
 A determinação do preço por pontos de função, se não a mais
importante, é certamente muito relevante ao processo. Atualmente, já existe
um acúmulo de experiência no mercado para consultar preços
comparativos, principalmente no setor governamental (veja o site
www.fattocs.com.br/editais.asp). Contudo, esses valores podem não ser
compatíveis com a realidade de sua organização e do contexto em que se
pretende contratar o serviço.
Um exercício recomendado é a “engenharia reversa” do preço do ponto
de função. Contratar projetos a preço global fixo é um caso geral da
organização que tem a intenção de contratar pontos de função. Uma
informação certamente disponível é o quanto se pagou ao fornecedor por
um projeto passado e quais atividades ele compreendia. Provavelmente não
haverá disponível o tamanho funcional do sistema produto desse projeto.
Essa informação pode ser obtida de uma contagem ou estimativa do
tamanho funcional a partir da documentação de requisitos do projeto. Com
a realização desse exercício em sistemas e projetos semelhantes ao que se
pretende contratar, é possível ter a noção do preço por ponto de função que
os fornecedores da organização costumam praticar. A mesma consideração
é certamente válida para o fornecedor que ainda não tem história na
utilização de pontos de função como unidade de medição de seus serviços.
Afinal, sua utilização visa facilitar um relacionamento benéfico para ambos.
Quando o cliente pergunta para um fornecedor o seu preço por ponto de
função, antes de qualquer resposta, o fornecedor deve estar ciente do
contexto em que será realizado o serviço. Uma analogia muito comum de
ponto de função é com o metro quadrado da construção civil. Ao perguntar
o preço do metro quadrado a um corretor de imóveis, certamente ele
fornecerá não um, mas vários preços: de acordo com a região, tipo de
acabamento, infraestrutura adicional do imóvel etc.
Com ponto de função a situação é bem parecida. O preço vai variar de
acordo com o trabalho requerido para a construção de um ponto de função e
dos subprodutos a serem também entregues.
Exemplo 1: ao contratar uma empresa apenas para o trabalho de
codificação e testes de unidade de um sistema, espera-se que o preço do
ponto de função seja inferior ao caso da contratação da mesma empresa
para a realização de todo o ciclo de desenvolvimento do sistema, desde o
levantamento de requisitos até a implantação do sistema.
 Exemplo 2: o preço do ponto de função para a entrega apenas do
software certamente é inferior ao preço do ponto de função em que, além do
software, devem ser entregues vários documentos (subprodutos) como:
modelos da UML, manual de usuário, ajuda on-line , especificações de caso
de uso, protótipos, manual de usuário e outros.
Exemplo 3: atualmente a gama de tecnologias disponíveis para
desenvolvimento de sistemas é enorme, cada uma delas podendo influenciar
diretamente na produtividade (tanto positivamente quanto negativamente)
do trabalho a ser realizado. Sendo assim, é também bastante comum no
mercado a diferenciação do preço do ponto de função de acordo com a
plataforma tecnológica ( mainframe , web, cliente-servidor etc.) e/ou
linguagem de programação (Cobol, C, Java, .Net etc.).
Exemplo 4: a APF, segundo o padrão IFPUG, mede manutenções
desconsiderando o tamanho da manutenção que a função sofrerá.
Geralmente o esforço para manter uma função costuma ser inferior ao de
desenvolvê-la. Sendo assim, pode haver diferenciação de preço do ponto de
função em projetos de melhoria para funcionalidades novas, para
funcionalidades alteradas e para funcionalidades excluídas.
Em resumo, não existe um preço único para ponto de função. Deve-se
avaliar o conjunto de atividades relativas à disponibilização das
funcionalidades medidas em pontos de função, o modelo de contrato que
ditará a remuneração de um ponto de função e também os aspectos não
funcionais que são desconsiderados na medição dos pontos de função.
A melhor alternativa para obter essa referência é analisar os projetos já
realizados. Para projetos já concluídos uma informação certamente
disponível é o quanto se pagou ou se cobrou por cada projeto e quais
atividades estavam compreendidas. Caso o tamanho funcional (PF) dos
projetos não esteja disponível, pode-se obtê-lo rapidamente através de uma
medição ou de uma estimativa; basta analisar seus requisitos. Tendo o preço
do projeto e o seu tamanho em pontos de função, obtém-se o seu preço por
ponto de função (R$/PF), no entanto é provável que sua organização
empreenda projetos de diferentes tipos. Neste caso deve-se proceder à
análise do R$/PF para cada categoria de projetos, pois dificilmente um
preço único será representativo para projetos de tipos distintos.
É possível obter informações de preço do PF dos contratos
governamentais, pois são dados públicos. Na Tabela 10.6 seguinte, extraída
de http://www.fattocs.com.br/editais.asp, apresentamos algumas referências
para ilustração. Pode-se observar que a variação dos números é muito
significativa, com valores orbitando de R$ 100/PF a R$ 1.000/PF. Para
entender parte destas discrepâncias, é necessário olhar com atenção o objeto
de contratação do serviço para identificar as diferenças técnicas e de
complexidade de cada contrato.
Tabela 10.6: Contratos públicos para desenvolvimento de software
por ponto de função.

An Volume Preço
Organização Referência
o (PF/ano) (R$/PF)
2
0 Concorrência
ANCINE 5.000 552,08
0 1/2008
8
2
0
ANEEL Pregão 71/2008 10.000 297,50
0
9
2
0
ANTAQ Pregão 02/2009 4.180 421,05
0
9
2
0
ANTT Pregão 77/2009 9.300 359,81
0
9
2
0
CNJ Pregão 17/2009 18.000 400,00
0
9
2
0
Eletrobras Pregão 39/2009 12.000 542,29
0
9
2
0
INCRA Pregão 60/2009 10.000 348,00
0
9
INEP 2 Pregão 11/2010 20.000 349,23
0
 0
9
2
0
IPLANRIO Pregão 63/2011 30.000 308,00
1
1
2
0
Ministério da Agricultura Pregão 15/2009 15.000 676,67
0
9
2
0
Ministério da Educação Pregão 26/2010 31.200 352,49
1
0
2
0
Ministério da Fazenda Pregão 28/2010 14.500 217,00
1
0
2
0
Mininistério da Justiça Pregão 005/2009 21.400 476,55
0
9
2
Mininistério das Relações 0
Pregão 001/2011 9.000 297,88
Exteriores 1
1
2
0
Ministério da Saúde Pregão 154/2010 30.000 609,83
1
0
2
0
Policia Federal Pregão 11/2009 10.000 415,00
1
0
2
0
Prodemge Pregão 8/2009 2.500 182,54
0
9
2
0
STF Pregão 167/2009 11.000 398,00
0
9
TRT 2 2 Pregão 114/2009 7.200 268,23
 0
1
0
2
0
TST Pregão 124/2009 15.000 263,89
0
9

Como Estimar o Preço de um Ponto de

Função?
No edital para contratação de serviços de Fábrica de Software [MME,
2012], desenvolveu-se todo o raciocínio de cálculo do que seria razoável
pagar no preço do ponto de função, considerando as particularidades do
serviço contratado, comentado a seguir.
A contratação deve prever que as atividades do ciclo de vida de um
projeto de software devem ser executadas pelo fornecedor. Considerando
uma organização com o nível de maturidade equivalente ao nível 2 do
CMMI, é esperado que diversas disciplinas tenham de ser exercidas ao
longo do projeto, a exemplo das presentes na Tabela 10.7. Se há registro do
esforço gasto em cada disciplina ao longo dos projetos, é possível estimar
quanto cada disciplina consome, em termos percentuais, do esforço total do
projeto.
Considerando que cada disciplina exige um tipo de profissional
especializado para sua execução, é possível estimar o custo médio da mão
de obra do projeto, conjugando quanto de esforço cada perfil profissional
será demandado e o salário de cada um desses perfis.
Foi este o raciocínio usado na Tabela 10.7. A partir de uma pesquisa
salarial no mercado de Brasília, o MME, calculou o custo médio da mão de
obra de uma equipe para desenvolver software seguindo seu padrão de
metodologia, que exige as disciplinas destacadas na tabela. Não vamos
questionar os valores de salário dessa pesquisa de mercado, pois as
variações salariais costumam ser significativas. Também não vamos julgar
as disciplinas listadas na tabela ou seu percentual de esforço, que também
costuma variar entre as organizações. O objetivo é ilustrar um raciocínio
usado para calcular o R$/PF.
 Tabela 10.7: Contratos públicos para desenvolvimento de software
por ponto de função.

Esforço do projeto por disciplina

Salário
Valor proporcional ao
Disciplinas % mercado Cargo
esforço
(Brasília)
Modelagem de 7 Analista de
R$ 5.535,00 R$ 387,45
negócio % negócios
13 Analista de
Requisitos R$ 5.671,00 R$ 737,23
% requisitos
16 Arquiteto de
Análise e design R$ 7.499,00 R$ 1.199,84
% sistemas
30
Implementação R$ 3.099,00 R$ 929,70 Programador
%
15 Analista de
Teste R$ 3.382,00 R$ 507,30
% testes
6 Analista de
Imaplantação R$ 5.693,00 R$ 341,58
% sistemas
Configuração e 3 Analista de
R$ 5.693,00 R$ 170,79
mudança % sistemas
5 Gerente de
Gerência de projeto R$ 9.199,00 R$ 459,95
% projetos
1 Analista de
Ambiente R$ 2.410,00 R$ 24,10
% suporte
Garantia de 1 Analista de
R$ 5.693,00 R$ 56,93
qualidade % sistemas
Métricas de 3 Especialista
R$ 9.000,00 R$ 270,00
software % CFPS (*)
10
Salário
Total 0 R$ 5.084,87
Médio
%

Considerando que sobre o salário há a incidência de encargos que em

alguns casos implica em um custo dobrado para a empresa, para o cálculo
do preço do ponto de função deve-se usar este custo final de mão de obra e
não apenas o salário nominal. Neste exemplo do MME, o custo da mão de
obra foi calculado com aproximadamente 70% de encargos, e que, com a
incidência ainda dos tributos a serem recolhidos pela empresa do serviço
prestado mais a margem de lucro, implicam que o valor de venda da mão de
obra seja quase o dobro do salário nominal, neste caso R$ 10.426,26.
Quanto à produtividade, o MME assumiu que no seu contexto a menor
taxa de entrega possível de esperar seria de 10 horas/ponto de função
(também não vamos questionar este número). Considerando ainda uma
carga mensal de trabalho de 168 horas para cada pessoa da equipe, há uma
estimativa de entrega de aproximadamente 16,8 PFs/mês. Dividindo o valor
de venda mensal da mão de obra pela quantidade de PFs entregues no mês,
tem-se que o valor mínimo estimado para o ponto de função no contrato do
MME é de R$ 620,49.
Tabela 10.8: Preço mínimo estimado do ponto de função para o
MME.

Valor do ponto por função

Parâmetros
Produtividade mínima (H/PF) 10
Horas mês 168
Custo médio mensal (por profissional) R$ 10.424,26
PF/mês 16,8
Valor mínimo do ponto por função R$ 620,49

Dicas para Otimizar o Custo do Contrato

A mudança da modalidade de contratação de homem-hora para pontos
de função não é apenas uma mudança na unidade de faturamento do
contrato, mas antes de tudo de mentalidade e cultura por parte do cliente.
Este deve pensar agora em termos de projeto, não mais de atividades a
serem cumpridas por um profissional, como é o caso de homem-hora. Partir
para um contrato em pontos de função sem essa mudança de mentalidade
significa um aumento significativo nos custos de contratação de serviços de
software.
A ausência de planejamento nas demandas a serem repassadas ao
fornecedor, implica no acionamento de outras ordens de serviço para
conseguir ter o software funcionando plenamente a contento. O retrabalho
em um contrato por preço unitário (ou preço global fixo) é muito mais
visível que em um contrato em homem-hora e também geralmente mais
caro. Quanto melhor o planejamento, menor o retrabalho. Se toda demanda
de manutenção que chegar for despachada diretamente para execução pelo
fornecedor, a tendência é que as manutenções sejam mais caras do que
poderiam ser. Por isso é fundamental que o cliente saiba pedir certo.
Algumas dicas podem ajudar a melhorar este cenário:
• Consolidar algumas manutenções na mesma função em
uma única demanda é a maneira mais fácil de
racionalizar o custo de manutenção. Já que o método do
IFPUG não mede a extensão da manutenção na função,
fazer uma manutenção para atender a um único requisito
ou para atender a vários requisitos de manutenção na
mesma função terá o mesmo custo para o cliente, se elas
forem solicitadas para o fornecedor no mesmo momento.
Se isso for solicitado em momentos distintos, o cliente
pagará várias vezes pela mesma função. Nem sempre é
possível represar uma demanda do usuário para que ela
seja empacotada com outras; às vezes há demandas com
prazos críticos. Ainda assim o cliente pode atuar,
filtrando para a execução imediata somente as funções
essenciais para o atendimento do requisito e deixar as
manutenções em outras funções que não têm criticidade,
para serem feitas juntamente com outras demandas. Em
suma, basta planejar versões do produto nas quais
diversas solicitações de mudança sejam atendidas em
conjunto .
• Reutilizar funções existentes em outros sistemas. Muitas
vezes algumas funções já existem em outros sistemas da
organização e mesmo assim ocorre a replicação dessas
 funcionalidades em diversas outras aplicações. Por
exemplo, imagine que em um banco cada aplicação que
gerencia um produto diferente (conta-corrente, cartão de
crédito, crédito imobiliário, leasing de automóveis etc.)
tivesse o seu cadastro de clientes. Para cada aplicação
destas haveria um cadastro e diversas consultas sobre os
seus clientes. Se existisse uma aplicação única para a
gestão de todos os clientes de forma integrada, todas as
demais aplicações poderiam ser mais enxutas, apenas
usando esse cadastro centralizado. Neste caso, um bom
planejamento da arquitetura de aplicações
corporativas traz ganhos fantásticos . O controle de
acesso de usuários é outro exemplo bastante típico. Não
faz sentido uma organização ter esse controle dentro de
suas aplicações; é desperdício. O ideal é ter uma
aplicação única com esse papel e que atenda todas as
demais.
• Análise crítica dos requisitos . Em muitas situações é
possível ter uma única função que faça o papel de duas
(ou mais) existentes. Isso é muito comum para consultas
e relatórios, em que várias delas são muito parecidas,
com a diferença apenas de alguns atributos. Uma
transação mais completa poderia ser elaborada para
substituir a essas várias similares. Ou também criar um
relatório com opções de filtro que possam substituir os
relatórios existentes e que são menos flexíveis ao
usuário. Por exemplo, um software que faz uso de
componentes de relatórios e consultas dinâmicas oferece
 muito mais flexibilidade ao usuário, contabilizando
menos PFs, do que se oferecesse dezenas de relatórios e
consultas rígidas. Às vezes pode ser mais barato pagar
uma função nova do que pagar a alteração de duas ou
mais funções existentes.

Contratação de Serviços de Medição

Com a adoção cada vez mais ampla de pontos de função como unidade
de medição de contratos de desenvolvimento e manutenção de software,
percebe-se que algumas empresas têm optado por terceirizar a atividade de
medição de seus projetos. A decisão de optar por terceirizar essa atividade
pode ser motivada por várias razões; desde falta de disponibilidade de
pessoal interno para realizar mais uma atividade, quanto o interesse em
focar a atenção do pessoal interno nas atividades fim do negócio, em
detrimento de atividades meio.
O que pretendemos destacar nesta seção é que critérios e precauções
devem ser observados quando da seleção da empresa fornecedora dos
serviços de medição e que itens devem ser monitorados no desempenho do
fornecedor durante a execução do contrato para que a terceirização tenha
mais chance de sucesso.
O modelo de contrato deve privilegiar a contratação de serviços sob
demanda através de ordens de serviço, podendo a execução ocorrer nas
instalações do cliente ou do fornecedor. Também deve prever um acordo de
nível de serviço com relação à qualidade, de tal forma que erros acima de
determinada tolerância (10%, por exemplo) na medição dos projetos gerem
penalidades para o fornecedor.
A contratação de serviços de medição pode ser com o interesse em um
projeto específico ou para atender uma necessidade constante da
organização para um dado volume de projetos. Quando o interesse for
contratar a medição pontual para um projeto específico, a abordagem mais
recomendada é solicitar uma proposta do fornecedor a preço global fixo,
fornecendo os artefatos de requisitos disponíveis do projeto para análise do
fornecedor para sua composição de preços. Para a contratação de serviços
de medição recorrentes, orçar projeto a projeto é oneroso. Nos parágrafos
seguintes são descritos outros modelos possíveis de contratação.
Uma primeira alternativa possível é a contratação de mão de obra
especializada para alocação dentro do próprio cliente para a medição dos
serviços, mas não costuma ser uma boa abordagem. Em primeiro lugar
porque volta-se aos mesmos problemas da contratação dos serviços de
desenvolvimento e manutenção de software por homem-hora, agora apenas
numa escala menor. E em segundo lugar, há grande chance de a equipe
contratada ficar parte do tempo ociosa, pois as medições ocorrem em geral
ao final das fases do projeto. Durante a execução das fases do projeto,
dificilmente a equipe de medição será acionada, a não ser que o cliente
execute um número significativo de projetos em paralelo, de tal forma que a
fase de um deles esteja sempre finalizando para que a equipe de medição
esteja continuamente sendo acionada.
Uma outra alternativa adotada por algumas organizações é a contratação
de serviços de medição sob demanda, usando como unidade de
remuneração o PF medido ou homem-hora vinculado a uma produtividade
de medição (PF/dia) preestabelecida em contrato. Ou seja, neste segundo
caso estamos falando não de apropriação de horas para fins de remuneração,
mas da conversão dos pontos de função medidos em um quantitativo de
horas conforme a produtividade estabelecida (por exemplo, 100 PF/dia).
Optar por remunerar por R$/PF medido ou por R$/hora com produtividade
fixada dá no mesmo resultado. Uma vantagem da segunda opção é poder ter
a mesma unidade (hora) para acionar serviços do fornecedor além da
própria medição, como, por exemplo, serviços de consultoria; caso haja
necessidade.
Tendo em vista que o fornecedor dos serviços de medição será
remunerado por PF medido, não seria o caso de imaginar que ele terá
interesse em inflar as medições para receber remuneração maior? Esta
questão é bastante pertinente e de fato cria um conflito de interesse em
potencial. O ideal seria que a unidade de remuneração do fornecedor
estivesse completamente desvinculada do resultado da medição por ele
produzido. Mas o mercado ainda não consolidou uma alternativa madura
para resolver esta questão. Qual unidade alternativa poderia ser usada?
Talvez o número de páginas da documentação analisada do projeto, mas
isso demanda ainda desenvolver melhor os critérios de medição dessa
unidade e encontrar valores de referência para ela de forma a possibilitar a
contratação.
Ainda sobre o modelo de contratação, também deve-se evitar contratar
o fornecedor para auditar ou validar as medições entregues pela
fábrica de software contratada . O ideal é que a medição feita pela fábrica
de software sequer seja um artefato entregável. O motivo é reduzir riscos.
Um deles é de que o responsável pela validação da medição seja induzido a
um erro que a fábrica tenha cometido na medição. Outro risco é o do
responsável pela validação acatar a medição da fábrica sem a devida
análise, para economizar seu esforço, por exemplo. O fornecedor do serviço
de medição deve sempre realizar a medição baseado nos artefatos de
requisitos entregues pelo projeto.
Quando se contrata um fornecedor para fazer as medições em vez de
validar medições feitas pela fábrica de software, elimina-se a possibilidade
de ela não fazer o trabalho de análise, pois ela deve produzir um artefato
entregável: a planilha de contagem de pontos de função. E também se
elimina a chance de o responsável pela medição ser induzido a um erro que
um terceiro cometeu, pois ele deve efetuar a medição exclusivamente com
base na documentação de requisitos do projeto, sem ter ciência do que a
fábrica de software mediu. Se a documentação do projeto estiver adequada
e ambos aplicarem a APF corretamente, as duas medições devem ser
convergentes.
Outro aspecto importante deste modelo, e talvez óbvio, é que a empresa
a ser contratada para as medições seja diferente da empresa que presta
serviços de fábrica de software. A ideia é segregar as funções entre os
fornecedores de tal forma que não haja potencial conflito de interesse.
Uma vez que se estabelece um contrato de fábrica de software
remunerado por ponto de função, o PF equivale a dinheiro, portanto a
seleção de um fornecedor competente e confiável é crucial.

Seleção de Fornecedores de Serviços

de Medição
 Uma seleção benfeita do fornecedor a ser contratado aumenta bastante
as chances de sucesso do contrato. Logo, ao selecionar um fornecedor,
procure analisar o histórico de serviços que ele já realizou e a satisfação dos
clientes aos quais ele prestou serviços. No mercado privado, o processo de
seleção costuma ser mais ágil e menos burocrático, e às vezes até subjetivo.
No mercado de governo, a seleção é através de licitação, normalmente na
modalidade pregão eletrônico para esse tipo de serviço, em que é
selecionado aquele que apresenta o menor preço, atendendo às habilitações
exigidas. A habilitação técnica é a forma que o governo tem de garantir a
seleção de uma empresa tecnicamente competente. Isso se dá pela exigência
da apresentação de atestados de capacidade técnica.
A proposta dessa seção é listar alguns critérios que podem ser levados
em consideração na seleção de um fornecedor de serviços de medição. São
estas as sugestões de exigências:
• Comprovação de execução de serviço similar e em
volume compatível com o que será contratado.
Normalmente essa comprovação é feita pela
apresentação de atestados de capacidade técnica emitidos
pelo cliente do candidato a fornecedor. E é fundamental
que o responsável pela seleção do fornecedor faça a
diligência do atestado, buscando evidências da execução
do serviço declarado e nos parâmetros de qualidade a
serem exigidos na contratação.
• Essa comprovação de experiência deve ser compatível
com o volume e o período a ser contratado de tal forma a
demonstrar que o fornecedor tem capacidade logística e
operacional (além da competência técnica) para executar
o serviço a ser contratado. Por exemplo, uma exigência
de comprovação de execução de serviços de medição
para um volume de 30.ooo PFs em um período
consecutivo de 12 meses. Isso evita que um candidato a
 fornecedor se habilite ao processo, reunindo
comprovação de serviços dos últimos cinco anos.
• Nos atestados que comprovam a execução dos serviços
devem constar o nome dos profissionais CFPS
responsáveis pelas medições. O uso de profissionais
CFPS nas medições garante que a pessoa conhece
profundamente todas as regras e conceitos do manual do
IFPUG, o que reduz (mas não elimina) a chance de erros.
O mínimo que se espera de um fornecedor candidato a
prestar esse tipo de serviço é que use equipe
devidamente qualificada e com pessoal próprio.
Verifique se os profissionais CFPS apresentados são de
fato funcionários do fornecedor. Algumas empresas que
se candidatam a prestar esse tipo de serviço sequer têm
equipe própria, recorrendo ao uso de profissionais free
lancers . Ocorre que é possível (e infelizmente já nos
deparamos com isso) que o mesmo profissional free
lancer que atua para essa empresa pode também atuar
para a fábrica de software, o que por si só já configura
conflito de interesse e ético.
• Não aceitar atestados de capacidade técnica cujo teor
evidencie que o serviço de medição foi prestado como
atividade meio de outros serviços, como, por exemplo,
desenvolvimento de sistemas. A ideia é filtrar no
processo empresas que não atuam especificamente nesse
tipo de serviço, mas que queiram usar essa oportunidade
do serviço de medição como porta de acesso ao cliente.
Há que se considerar também que o serviço feito como
 atividade meio é candidato a ser terceirizado (e várias
empresas de TI fazem isso). Então há o risco de o objeto
do atestado ter sido executado por um terceiro. A busca é
aferir a capacidade organizacional do candidato a
fornecedor, que não se resume à capacidade técnica de
seus profissionais.
• Por mais rigor que se estabeleça nessa comprovação de
experiência do candidato a forncedor, ainda há chance de
não representar a realidade atual. Então, se necessário, é
possível também realizar uma prova de conceito do
serviço com o fornecedor em potencial com um projeto
piloto.
• Filiação corporativa ao IFPUG. Se a empresa de fato tem
como foco de atuação a medição de software, certamente
deve estar filiada ao IFPUG, seja por conta da
manutenção da certificação CFPS de sua equipe, quanto
pelo interesse em participar das atividades desenvolvidas
pelo IFPUG, que afinal regula de certa forma o trabalho
que ela desempenha.

Acompanhamento do Contrato de
Serviços de Medição
Após a seleção do fornecedor, deve-se promover o acompanhamento da
execução dos seus serviços para que a contratação seja bem-sucedida. E a
forma mais objetiva de fazer isso é definir previamente Acordos de Nível de
Serviço (ANS) que vão balizar o desempenho esperado pelo fornecedor.
Esses ANSs devem envolver critérios para avaliação da qualidade do
serviço (por exemplo, as medições estão sendo feitas corretamente?) no
tempo adequado e no volume esperado.

Questões de Fixação

1. O que é a modalidade de contratação homem/hora?

2. Cite algumas vantagens e desvantagens na utilização de
um modelo de contratação de desenvolvimento de
software baseado em homem/hora do ponto de vista do
contratante.
3. Como a técnica da análise de pontos de função pode ser
utilizada para trazer benefícios ao modelo de contratação
baseado em homem/hora?
4. O que é a modalidade de contratação preço global fixo?
5. Qual a maior causa de problemas de relacionamento
com o fornecedor quando a contratante adota a
modalidade de contratação a preço global fixo?
6. Como a técnica da análise de pontos de função pode ser
utilizada para trazer benefícios ao modelo de contratação
baseado em preço global fixo?
7. Como é realizada a remuneração do fornecedor na
modalidade de contratação chamada de preço unitário?
8. Por que a modalidade preço unitário é considerada um
modelo que procura equi- librar as deficiências da
contratação por homem/hora e por preço global fixo?
9. Por que o ponto de função é considerado a unidade mais
indicada para medir a remuneração do fornecedor na
 modalidade baseada em preço unitário?
10. Cite algumas providências que uma organização deve
tomar para simplificar a utilização da análise de pontos
de função como instrumento de medição e remuneração
de projetos.
11. Como é possível utilizar o ponto de função para
remunerar o fornecedor por uma atividade específica do
projeto, como a análise ou a sua construção?
12. Explique como aplicar a técnica da “engenharia
reversa” do preço para compor o valor do ponto de
função.
13. Qual o preço de um ponto de função?

Bibliografia

1. AGUIAR, M. A Produtividade dos Projetos de

Desenvolvimento. Developers Magazine , fev. 2003.
2. AGUIAR, M.; BAKLIZK, D. Modelos de Negócio
Baseados em Pontos de Função . ISMA Cinco -
International Software Measurement & Analsys
Conference, set. 2010. Disponível em: <
http://www.metricas.com.br/downloads/Aguiar-
Baklizky-Modelos_de_Negocio_Baseados_em_PF.pd f>.
Acesso em: 1 out. 2010.
3. CAIXA ECONÔMICA FEDERAL. Concorrência
1/2006 . Disponível em:
 <http://www.fattocs.com.br/editais/caixa/concorrencia00
12006230407.zip>. Acesso em: 19 ago. 2007.
4. CARDOSO, M. Gerenciamento de Subcontratações
com o Rational Unified Process . Rational Software
White Paper, versão 1.2, 2001.
5. DEKKERS, C.; AGUIAR, M. Using Function Point
Analysis to Check the Completeness (Fullness) of
Functional User Requirements. Cutter IT Journal , abr,
2000.
6. FUNDO NACIONAL DO DESENVOLVIMENTO DA
EDUCAÇÃO. Pregão Eletrônico 25/2011. Disponível
em:
<http://www.fattocs.com.br/editais/fnde/1531730500025
2011002.doc>. Acesso em: 31 mai. 2011.
7. GARMUS, D.; HERRON, D. Function Point
Analysis: Measurement Practices for Sucessful Software
Projects. Addison-Wesley, 2000.
8. HAZAN, C. Análise de Pontos de Função: Uma
Aplicação na Gerência de Subcontratação de Software.
In: PALESTRA SUCESU-RJ, 2002.
9. INSTITUTO NACIONAL DE ESTUDOS E
PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA.
Pregão 11/2010 . Disponível em:
<http://www.fattocs.com.br/editais/inep/11_2010_INEP.
PDF>. Acesso em: 26 mai. 2011.
10. JONES, C. Conflict and Litigation Between
Software Clients and Developers: Software
Productivity Research, Versão 10, 2001.
11. MINISTÉRIO DA EDUCAÇÃO. Pregão Eletrônico
26/2010 . Disponível em: <
http://www.fattocs.com.br/editais/MEC/1500020500026
2010001.zip >. Acesso em: 9 ago. 2010.
12. PRODEMGE. Pregão 8/2009. Disponível em:
<http://www.fattocs.com.br/editais/prodemge/Edital_Pro
cessoDeCompra.zip>. Acesso em: 13 jul. 2009.
13. RADFORD, P.; LAWRIE, R. The Role of Function
Points in Software Development Contracts .
Australian Conference on Software Measurement, 1996.
14. SECRETARIA DE LOGÍSTICA E TECNOLOGIA
DA INFORMAÇÃO. Roteiro de Métricas de Software
do SISP Versão 2.0 . Disponível em:
<http://www.sisp.gov.br/roteirometricas>. Acesso em: 10
abr. 2012.
15. SUPERIOR TRIBUNAL FEDERAL. Pregão
167/2009 . Disponível em: <
http://www.fattocs.com.br/editais/stf/167-2009.pdf >.
Acesso em: 18 jan. 2010.
16. MINISTÉRIO DAS MINAS E ENERGIA. Pregão
Eletrônico 28/2012 . Disponível em:
<http://www.fattocs.com.br/editais/MME/MME-28-
2012.pdf>. Acesso em: 25 jan. 2013.
 11

Certificação em Pontos de Função

(CFPS)

Programa de Certificação
Uma das missões do IFPUG é normatizar e disseminar o uso da técnica da Análise
de Pontos de Função como a métrica funcional padrão para software. Além de manter o
Manual de Práticas de Contagem, o IFPUG, entre outras ações, possui o programa de
certificação CFPS ( Certified Function Point Specialist ) e CFPP ( Certified Function
Point Practioner ) cujo objetivo é reconhecer formalmente os profissionais capazes de
realizar contagens de pontos de função precisas e consistentes e que também conheçam
as práticas de contagem mais recentes. Esse programa de certificação existe desde 1993.
O IFPUG disponibiliza uma consulta pública dos especialistas certificados em seu
portal na Internet (www.ifpug.org/), na qual é possível pesquisar se alguém é
certificado, a versão do Manual de Práticas de Contagem na qual o profissional se
certificou e a data da expiração do certificado.
O prazo de validade da certificação é de três anos, após o qual o profissional deve
submeter-se novamente ao exame para renovar sua certificação ou participar do
programa de extensão de certificação. Esse programa permite que o profissional
prorrogue a validade da sua certificação com algumas atividades, como realizar
contagens de pontos de função, participar das conferências do IFPUG ou de um de seus
capítulos, ministrar cursos, escrever artigos ou livros, participar como voluntário de
algum dos comitês do IFPUG.
No Brasil a primeira realização do exame foi em São Paulo durante o Congresso
Internacional de FPA & VIII Encontro Nacional de Usuários de Pontos de Função
promovido pela UNISYS e o IBPI em 1996. Dos seis profissionais participantes, três
foram certificados.
 A partir de 2001 o BFPUG ( Brazilian Function Point Users Group ) passou a
promover regularmente o exame no Brasil até 2008, quando ele passou a ser
automatizado (prova eletrônica). A partir de então o próprio candidato passou a escolher
o local (nas cidades com centros autorizados), idioma (além de inglês e português há
outras opções) e data para prestar o exame.

O Exame
A prova é dividida em três seções:
1. Definições (questões conceituais);
2. Aplicação de regras (questões práticas);
3. Estudos de caso.
As duas primeiras destas seções são compostas de 50 questões de múltipla escolha.
A seção 3 apresenta dez estudos de caso (aproximadamente com uma página de
enunciado), com uma média de 74 questões (há uma ligeira variação nesta quantidade a
cada exame).
Todas as questões são elaboradas de forma bem objetiva. Não haverá questão na
qual o participante tenha que interpretar a visão do usuário para poder responder. A
visão do usuário sempre estará bem explícita; diferente do que ocorre muitas vezes em
situações reais.
A taxa de acerto para aprovação como CFPS deve ser de pelo menos 90% de
aproveitamento geral com ao menos 80% em cada uma das seções. Ou seja,
considerando a seção 3 com 50 questões:

• No máximo cinco questões de cada seção podem estar erradas; ou

• No máximo dez questões de cada seção podem estar erradas desde
que das 150, não mais que 15 estejam erradas.
• Caso o candidato obtenha nota geral inferior a 90%, porém igual
ou superior a 80% (com notas mínimas de 70% em cada seção),
ele recebe a designação CFPP (Certified Function Point
Practioner ).
O exame tem três horas de duração e é com consulta exclusiva ao manual de
práticas de contagem e ao cartão de referência fornecido pelo IFPUG em formato PDF.
No ambiente automatizado do exame, o candidato não pode levar nada. Para
finalidade de rascunho são fornecidas uma folha e uma caneta. Uma calculadora fica
disponível a todo momento que o candidato desejar acioná-la. O candidato pode
também deixar um comentário em cada questão quando sentir necessidade de explicar o
seu ponto de vista referente à resposta dada. Esses comentários são avaliados pelo
IFPUG e, se bem fundamentados, podem fazer com que o candidato ganhe o ponto na
questão mesmo que eventualmente com uma resposta diferente do gabarito.
O resultado é fornecido ao candidato imediatamente após o término da prova, com
sua nota em cada seção do exame. Em caso de não aprovação, é possível pedir ao
IFPUG a revisão da correção do exame (mediante o pagamento de uma taxa quando a
nota é igual ou superior a 88%). Nessa revisão a análise dos comentários é levada em
consideração. Para notas abaixo de 80% dificilmente a revisão mudará o resultado do
exame.

Dicas e Comentários
Para submeter-se à prova, é preciso boa preparação. Embora os critérios de
aprovação sejam elevados, não existe prova difícil para quem está bem preparado. Uma
das primeiras dúvidas do candidato à certificação é com relação ao tempo de preparação
ideal para a prova. Não há um prazo de preparação igual para todos; a variação é muito
grande de acordo com o conhecimento de cada um.
Se em seu dia a dia o profissional trabalha aplicando a técnica da APF, certamente
precisará de menos tempo que outro que o faz apenas de forma esporádica. Logo,
quanto mais contagens de pontos de função o candidato fizer, mais consolidados estarão
os conceitos da técnica. A experiência de contagem não é essencial para poder prestar o
exame com sucesso; basta que o participante estude adequadamente.
Para aqueles que utilizam softwares ou planilhas de apoio à contagem, atenção para
a memorização das fórmulas e tabelas de complexidade e contribuição. Embora os
softwares facilitem o trabalho no dia a dia, durante a prova o candidato deve realizar a
contagem manualmente.
O texto de referência mais importante de preparação para a prova é o próprio
Manual de Práticas de Contagem, no qual a prova está toda baseada. Não é preciso
chegar ao exagero de decorá-lo. Mesmo para aqueles que estejam utilizando outras
fontes de preparação, é importante que ele seja lido atentamente ao menos uma vez e
que não fiquem dúvidas. Algumas questões de prova são baseadas nos vários exemplos
do manual.
É fundamental que sejam praticados exercícios simulados da prova. Assim o
candidato possuirá uma noção exata de quanto tempo terá à sua disposição em cada
parte e questão da prova e também será capaz de aferir seu grau de preparação e pontos
fracos a reforçar.
Outra dica muito interessante (e gratuita) é aproveitar os fóruns de discussão do
assunto, como os do BFPUG (http://br.groups.yahoo.com/group/forum-bfpug) e o do
grupo de leitores deste livro (http://br.groups.yahoo.com/group/livro-apf/) para ouvir as
dicas e experiências de quem já se submeteu à prova para manter o assunto “vivo” no
seu dia a dia. Há também uma versão de demonstração (gratuita) do curso da Fatto de
Preparação para a Certificação CFPS com um microssimulado da prova. O link é
http://www.fattocs.com.br/demo_cfps.asp.
O tempo disponível para a prova é muito escasso, portanto não convém demorar
muito na análise para resposta das questões. Uma sugestão é usar meia hora na primeira
seção da prova, uma hora na segunda seção e o restante do tempo para estudo de caso e
revisão (se sobrar tempo). Embora o manual esteja disponível para consulta, convém
não perder tempo consultando-o. O ideal é usar durante a preparação para a prova um
cartão de referência com as definições mais importantes, as tabelas, as fórmulas e as
características gerais. A simples memorização das tabelas de complexidade e
contribuição economiza um tempo precioso. É possível obter gratuitamente um cartão
de referência, solicitando na página da Fatto Consultoria e Sistemas
(http://www.fattocs.com.br/cartao.asp).
Há possibilidade de ser aprovado sem conseguir terminar todas as questões; logo,
deve-se manter a calma e a concentração mesmo que o tempo da prova esteja
terminando. Deve-se evitar pular questões; o ideal é responder todas e deixar para voltar
depois àquelas em que houver dúvidas, se sobrar tempo para revisão.

Exame Simulado

Parte 1 - Definições
1. O Valor do Fator de Ajuste:
a) Reflete a dificuldade em dar manutenção a um sistema existente.
b) Ajusta em +/– 35% os pontos de função.
c) Sempre aumenta em até 35% a contagem dos pontos de função.
d) Possui uma faixa de valores que varia de 0 a 5.
2. Um processo elementar é definido como:
a) Toda atividade que o sistema deve realizar.
b) Um requisito do negócio do usuário.
c) A menor unidade de atividade significativa para o usuário.
d) Um agrupamento lógico de dados.
3. Qual dos seguintes passos não faz parte do procedimento de contagem de pontos de
função?
a) Identificar a fronteira da aplicação.
b) Determinar o tipo de contagem.
c) Calcular o valor do fator de ajuste.
 d) Classificar as características gerais do sistema em simples, médias e complexas.
4. Um dos objetivos da Análise de Pontos de Função é:
a) Medir a funcionalidade que o usuário solicita e recebe.
b) Calcular quantas tabelas um sistema terá.
c) Estimar o tamanho de uma equipe de desenvolvimento.
d) Ajudar no processo de depuração de um software.
5. Quais os tipos de contagem de pontos de função?
a) Dados, transações e fator de ajuste.
b) Corretiva, adaptativa e evolutiva.
c) Projeto de desenvolvimento, projeto de melhoria e aplicação.
d) Contagem prévia, contagem não ajustada e contagem ajustada.
6. Um dos benefícios da Análise de Pontos de Função é:
a) Identificar os requisitos não funcionais do sistema.
b) Ser um meio de estimar custos e recursos para o desenvolvimento e manutenção de
software.
c) Ajudar o desenvolvedor na programação de um sistema.
d) Identificar as entidades que devem ser normalizadas em um modelo de dados.
7. As funções do tipo transação existentes são:
a) Saída externa, consulta externa e entrada externa.
b) Entrada externa, saída externa e arquivo de interface externa.
c) Fator de ajuste, escopo da contagem e fronteira da aplicação.
d) Projeto de desenvolvimento, projeto de melhoria e aplicação.
8. As funções do tipo dado existentes são:
a) Arquivos simples e complexos.
b) Entradas externas, saídas externas e consultas externas.
c) Todas as tabelas lidas e mantidas pelo sistema.
d) Arquivos lógicos internos e arquivos de interface externa.
9. Assinale o que melhor representa a visão do usuário:
a) Depende do seu nível de conhecimento sobre sistemas.
b) É implementada em um diagrama de classes.
c) É uma descrição das funções do negócio, que pode variar em sua forma física.
d) É somente aquilo que o usuário final entende.
10. Quantas são as características gerais do sistema?
a) 14.
b) 21.
c) 17.
 d) Depende dos requisitos do negócio.
11. O propósito da contagem de pontos de função:
a) É garantir a qualidade do sistema que será comprado.
b) É fornecer uma resposta a um problema de negócio.
c) É identificar todos os requisitos do usuário para o sistema.
d) Nenhuma das alternativas anteriores está correta.
12. A fronteira da aplicação deve ser determinada com base:
a) Nas diferentes plataformas em que a aplicação é executada.
b) Nas diferentes equipes envolvidas.
c) No ponto de vista do usuário.
d) Nenhuma das alternativas anteriores está correta.
13. A fronteira da aplicação:
a) Define o que é externo à aplicação.
b) Age como uma membrana por meio da qual os dados processados pelas transações
entram e saem da aplicação.
c) Varia em função da tecnologia empregada.
d) Ambas A e B estão corretas.
14. O escopo da contagem:
a) Define um subconjunto do software medido e/ou pode incluir mais de uma
aplicação.
b) Deve abranger apenas uma aplicação.
c) Afeta a complexidade dos arquivos identificados.
d) Ambas A e C estão corretas.
15. As seguintes regras são aplicáveis à fronteira da aplicação:
a) A fronteira entre aplicações relacionadas deve ser baseada na separação funcional
das áreas conforme a visão do usuário, não em considerações técnicas.
b) Deve ser determinada com base na visão do usuário. O foco deve estar no que ele
pode entender e descrever.
c) A fronteira inicial estabelecida para a aplicação ou aplicações sendo modificadas
não é influenciada pelo escopo da contagem.
d) Todas as alternativas anteriores estão corretas.
16. Um arquivo é definido como:
a) Um requisito de persistência de dados.
b) Um grupo de dados logicamente relacionados.
c) Uma tabela do banco de dados do sistema.
d) Nenhuma das alternativas anteriores está correta.
17. A principal diferença entre um arquivo lógico interno e um arquivo de interface
externa é que:
a) Um AIE é lido, mas não é mantido pela aplicação sendo contada.
b) Um AIE envia dados para fora da fronteira da aplicação.
c) Um ALI possui tipos de registro enquanto o AIE não.
d) Os tipos de dados de um ALI são diferentes de um AIE.
18. Para classificar um arquivo lógico interno, deve-se:
a) Determinar os processos elementares que operam sobre o arquivo.
b) Contar seus tipos de dados e tipos de registro.
c) Contar seus tipos de dados e arquivos referenciados.
d) Contar seus tipos de registro e arquivos referenciados.
19. Para classificar um arquivo de interface externa, deve-se:
a) Determinar os processos elementares que operam sobre o arquivo.
b) Contar todos os campos do arquivo.
c) Contar apenas os campos usados pela aplicação sendo contada.
d) Contar seus tipos de dados e arquivos referenciados.
20. Um tipo de dado é:
a) Um campo único, não repetido e reconhecido pelo usuário.
b) Um subgrupo de dados dentro de um arquivo.
c) Qualquer elemento visual em um relatório ou tela de entrada de dados.
d) Um dado derivado de um processo elementar que não atravessa a fronteira da
aplicação.
21. Um tipo de registro:
a) É um subgrupo de dados dentro de um ALI ou AIE reconhecido pelo usuário.
b) Pode ser opcional ou obrigatório.
c) Depende do tipo da contagem.
d) Ambas A e B estão corretas.
22. Identifique qual das alternativas seguintes não é uma regra de contagem para tipos
de dados em um arquivo lógico.
a) Quando duas aplicações mantêm ou referenciam o mesmo ALI/AIE, mas mantêm
ou referenciam tipos de dados diferentes, conte somente os tipos de dados utilizados
por cada aplicação para determinar a complexidade do arquivo.
b) Conte um tipo de dado para cada campo não repetido e reconhecido pelo usuário
que seja lido ou mantido de um arquivo por meio de um processo elementar.
c) Conte um tipo de dado para cada campo não repetido e reconhecido pelo usuário
que seja necessário a um processo elementar, desde que ele não atravesse a fronteira
da aplicação.
 d) Conte um tipo de dado para cada fração de dados solicitada pelo usuário para
estabelecer um relacionamento com outro arquivo.
23. Quantos tipos de dados um ALI ou AIE pode ter?
a) Indeterminado.
b) 0.
c) No máximo 50.
d) 1.
24. Qual a principal intenção de uma entrada externa?
a) Atualizar um arquivo lógico interno ou um arquivo de interface externa.
b) Atualizar um arquivo lógico interno.
c) Atualizar um arquivo de interface externa.
d) Nenhuma das alternativas anteriores está correta.
25. Qual das afirmativas seguintes está correta?
a) Um arquivo de interface externa de uma aplicação deve ser necessariamente um
arquivo lógico interno em uma outra aplicação.
b) Para cada entidade em um modelo de dados existe um arquivo lógico interno
associado.
c) Uma aplicação pode possuir arquivos que não possuem nenhum tipo de registro.
d) Todas as afirmativas anteriores estão incorretas.
26. Identifique qual das alternativas seguintes não é uma regra de contagem para
arquivos referenciados.
a) Conte apenas um arquivo referenciado para cada ALI que seja tanto lido quanto
mantido.
b) Conte um arquivo referenciado para cada ALI mantido.
c) Conte um arquivo referenciado para cada ALI ou AIE lido.
d) Conte um arquivo referenciado para cada alteração no comportamento do sistema.
27. Qual a principal intenção de uma consulta externa?
a) Alterar o comportamento do sistema.
b) Atualizar arquivos lógicos internos.
c) Enviar dados para fora da fronteira da aplicação por meio da simples recuperação
de dados de um arquivo.
d) Gerar dados derivados.
28. Qual a principal diferença entre uma saída externa e uma consulta externa?
a) A saída externa permite diferentes ordenações dos dados.
b) A consulta externa permite diferentes ordenações dos dados.
c) Quantidade de tipos de dados e arquivos referenciados.
d) Nenhuma das alternativas anteriores está correta.
29. Identifique a afirmativa que não se aplica a uma informação de controle:
a) Influencia um processo elementar da aplicação sendo contada.
b) É um subgrupo de dados reconhecido pelo usuário.
c) Especifica o que, quando ou como os dados devem ser processados.
d) Pode ser uma tecla de atalho ou um botão que afeta o processamento da transação.
30. Usuário, na definição do IFPUG, é:
a) Qualquer pessoa que usa ou opera o sistema.
b) Qualquer pessoa ou “coisa” que interage com o sistema a qualquer momento e/ou
que especifica requisitos funcionais.
c) Qualquer pessoa responsável pela contratação de sistemas na organização.
d) Nenhuma das alternativas anteriores está correta.
31. Uma saída externa pode:
a) Gerar dados derivados.
b) Alterar o comportamento do sistema.
c) Atualizar um arquivo lógico interno.
d) Todas as afirmativas anteriores estão corretas.
32. Uma consulta externa deve:
a) Referenciar pelo menos um arquivo.
b) Gerar dados derivados.
c) Alterar o comportamento do sistema.
d) Atualizar um arquivo lógico interno.
33. A complexidade de uma entrada externa é determinada:
a) Pelo número de arquivos referenciados.
b) Pelo número de arquivos referenciados e tipos de dados.
c) Pelo número de arquivos referenciados e tipos de registros.
d) Pelo número de tipos de dados e tipos de registros.
34. Identifique qual das alternativas não faz parte das regras de identificação de
entradas externas.
a) Dados são enviados para fora da fronteira da aplicação.
b) Dados ou informações de controle são recebidos de fora da fronteira da aplicação.
c) Um arquivo lógico interno é atualizado.
d) O comportamento do sistema é alterado.
35. Um arquivo referenciado:
a) São dados de referência mantidos pelo sistema e solicitados pelo usuário.
b) É um ALI lido ou mantido por um processo elementar ou um AIE lido por um
processo elementar.
 c) É um AIE lido ou mantido por um processo elementar da aplicação sendo contada.
d) É uma tabela do sistema.
36. Qual o número mínimo de arquivos referenciados para uma consulta externa?
a) 0.
b) 1.
c) 2.
d) 3.
37. Qual o número mínimo de arquivos referenciados para uma saída externa?
a) 0.
b) 1.
c) 2.
d) 3.
38. Que faixa de valores pode assumir o nível de influência de uma característica geral
da aplicação?
a) –35% a +35%.
b) 1 a 14.
c) 0 a 5.
d) Baixa, média e alta.
39. Identifique a fórmula correta para determinação do valor do fator de ajuste:
a) VAF = (NI * 0,01) + 0,65.
b) VAF = (TDI * 0,01) + 0,35.
c) VAF = (TDI * 0,01) + 0,65.
d) VAF = (TDI * 0,01) – 0,65.
40. O valor do fator de ajuste:
a) Reflete a funcionalidade específica da aplicação.
b) Pode variar de 0 a 5.
c) Influencia na contagem dos pontos de função.
d) Nenhuma das alternativas anteriores está correta.
41. Qual característica geral contempla uma aplicação que deve rodar em ambientes de
hardware e de software similares?
a) Facilidade de instalação.
b) Múltiplos locais.
c) Configuração altamente utilizada.
d) Processamento distribuído.
42. No caso anterior, qual o nível de influência dessa característica geral?
a) 2.
 b) 0.
c) 5.
d) 1.
43. O suporte a várias línguas é contemplado por qual característica geral?
a) Modificação facilitada.
b) Facilidade de operação.
c) Eficiência do usuário final.
d) Facilidade de instalação.
44. Qual é a fórmula correta para o cálculo dos pontos de função ajustados de um
projeto de desenvolvimento?
a) DFP = UFP + CFP + VAF.
b) DFP = UFP * CFP * VAF.
c) DFP = UFP + (CFP * VAF).
d) DFP = (UFP + CFP) * VAF.
45. Na fórmula para calcular a contagem inicial da aplicação, o que representam suas
variáveis?
a) AFP representa os pontos de função alterados, ADD representa o nível de
influência total.
b) AFP representa os pontos de função alterados, ADD representa os pontos de
função adicionados à instalação da aplicação.
c) AFP representa os pontos de função ajustados da aplicação, ADD representa os
pontos de função na instalação da aplicação.
d) Nenhuma das alternativas anteriores está correta.
46. Qual das afirmativas seguintes está correta?
a) Literais como variáveis de paginação devem ser consideradas na contagem dos
tipos de dado de uma saída externa.
b) As funcionalidades excluídas de um sistema não devem ser consideradas em um
projeto de melhoria.
c) Um arquivo com apenas um tipo de registro nunca poderá ser de complexidade
alta.
d) Para a determinação da complexidade de um arquivo deve-se determinar quantos
processos elementares o referenciam.
47. Para que uma saída externa seja de complexidade média, a seguinte situação deve
ocorrer:
a) Um processo elementar com mais de 20 tipos de dados.
b) Um processo elementar com menos de três arquivos referenciados.
c) Um processo elementar com três tipos de dados e quatro arquivos referenciados.
 d) Um processo elementar com 19 tipos de dados e 0 arquivo referenciado.
48. Não é um exemplo de uma característica geral de sistema:
a) Portabilidade.
b) Atualização on-line.
c) Performance.
d) Volume de transações.
49. O projeto de melhoria:
a) Corrige defeitos na aplicação.
b) Reflete as funcionalidades adicionadas, alteradas e excluídas de um sistema, além
da conversão de dados.
c) Representa os pontos de função antes da instalação da aplicação.
d) Contempla o fator de ajuste da aplicação existente.
50. Um processo elementar emite três mensagens distintas para o usuário: “Deseja
excluir o registro (S/N)?”, “Não é permitida a exclusão do registro!” e “Registro
excluído com sucesso”. Como estas mensagens devem ser consideradas no contexto
da Análise de Pontos de Função?
a) Novas consultas ou saídas externas.
b) Três tipos de dados do processo elementar.
c) Um tipo de dados do processo elementar.
d) Não são relevantes para o processo de contagem.

Parte 2 - Aplicação das Regras

1. Quantos tipos de dados possui um processo elementar que permite aon usuário alterar
cinco campos na tela e que, após a tecla OK ser pressionada, atualiza esses campos
em um arquivo e emite uma mensagem ao final da operação?
a) 0.
b) 3.
c) 5.
d) 7.
2. Como é classificado o processo elementar do caso anterior?
a) Saída externa.
b) Entrada externa.
c) Consulta externa.
d) Alteração externa.
3. Quantos pontos de função o processo elementar anterior possui, assumindo que
apenas um arquivo é referenciado?
a) 3.
b) 4.
c) 5.
d) 6.
4. Qual das funções seguintes possui o maior número de pontos de função?
a) Uma saída externa com 18 tipos de dados e dois arquivos referenciados.
b) Um arquivo de interface externa com 30 tipos de dados e um tipo de registro.
c) Um arquivo lógico interno cuja complexidade ainda será calculada.
d) Uma consulta externa com 20 tipos de dados e três arquivos referenciados.
5. Quantas entradas externas existem em uma tela de cadastro de uma aplicação, na
qual é possível incluir, alterar, excluir, consultar e imprimir clientes?
a) 0.
b) 2.
c) 3.
d) 5.
6. No caso anterior, qual número máximo de consultas externas poderia existir?
a) 0.
b) 2.
c) 1.
d) 5.
7. Uma aplicação com três arquivos lógicos internos, nove entradas externas e três
saídas externas possui quantos pontos de função?
a) 81, no mínimo.
b) 84, no mínimo.
c) 60, no mínimo.
d) 57, no mínimo.
8. Em um sistema bancário, há um relatório que lista nome do cliente, número da conta
e saldo. Adicionalmente, o relatório exibe no cabeçalho a página atual, o total de
páginas, o nome do relatório e a data da impressão. No final do relatório é calculado e
exibido o total de clientes listados. Identifique o processo elementar que melhor
caracteriza esse relatório:
a) Saída externa.
b) Consulta externa.
c) Entrada externa.
d) Nenhuma das alternativas anteriores está correta.
9. No caso anterior, qual alternativa melhor ajuda na identificação do processo
elementar?
a) A principal intenção, que é enviar dados para fora da fronteira da aplicação e
adicionalmente a atualização de um arquivo.
b) A principal intenção, que é enviar dados para fora da fronteira da aplicação e
adicionalmente a realização de cálculos matemáticos.
c) A principal intenção, que é atualizar um arquivo lógico interno.
d) A principal intenção, que é enviar dados para fora da fronteira da aplicação através
da simples recuperação de dados.
10. Ainda referente ao relatório do sistema bancário, quantos tipos de dados devem ser
considerados? Considere adicionalmente um tipo de dado para o comando e outro
para a mensagem.
a) 8.
b) 10.
c) 5.
d) 6.
11. Qual alternativa possui o maior número de pontos de função ajustados?
a) 180 pontos de função e um fator de ajuste de 1,05.
b) 300 pontos de função e um fator de ajuste ainda a ser calculado.
c) 100 pontos de função e um fator de ajuste de 0,70.
d) 120 pontos de função e um fator de ajuste de 1,35.
12. Qual o nível de influência total de uma aplicação com as seguintes características:
Comunicação de Dados 3
Atualização On-Line 5
Processamento Distribuído 3
Processamento Complexo 1
Performance 3
Reusabilidade 3
Configuração Altamente Utilizada 3
Facilidade de Instalação 2
Volume de Transações 4
Facilidade de Operação 2
Entrada de Dados On-Line 5
Múltiplos Locais 2
Eficiência do Usuário Final 3
Modificação Facilitada 2
a) 41.
 b) 6%.
c) 1,06.
d) Nenhuma das alternativas anteriores está correta.
13. Um arquivo lógico interno com 51 tipos de dados e três tipos de registro possui
quantos pontos de função?
a) 5.
b) 7.
c) 10.
d) 15.
14. Em um projeto de desenvolvimento foram contados 560 pontos de função, e 30
deles eram referentes à funcionalidades de conversão de dados. Qual o tamanho da
aplicação ao final desse projeto de desenvolvimento? Assuma que o fator de ajuste é
1.
a) 560.
b) 590.
c) 530.
d) Nenhuma das alternativas anteriores está correta.
15. Uma aplicação possui 840 pontos de função. Um projeto de melhoria altera um
arquivo lógico interno, que de 40 campos e um tipo de registro passa a ter 55 campos
e um tipo de registro. Uma entrada externa de complexidade baixa é excluída. Qual o
tamanho do projeto de melhoria?
a) 13.
b) 840.
c) 850.
d) 853.
16. No caso anterior, qual o tamanho da aplicação após o projeto de melhoria?
a) 13.
b) 840.
c) 850.
d) 853.
17. Em um sistema de contas-correntes em um banco, dois tipos de transações
atualizam o saldo do cliente. O saque diminui o saldo por meio da saída de dinheiro
da conta-corrente e o depósito aumenta o saldo por meio da entrada de dinheiro na
conta-corrente do cliente. Como devem ser classificadas, respectivamente, essas duas
transações?
a) Saída externa e saída externa.
b) Saída externa e entrada externa.
 c) Entrada externa e saída externa.
d) Entrada externa e entrada externa.
18. Dois sistemas A e B leem o mesmo arquivo de interface externa, que possui 40
campos. O sistema A lê apenas dez campos e o sistema B lê 30 campos do mesmo
arquivo. Quantos tipos de dados devem ser computados para o arquivo de interface
externa nos sistemas A e B respectivamente?
a) 40 e 40.
b) 10 e 30.
c) 10 e 10.
d) 30 e 30.
19. Dois sistemas A e B leem e atualizam o mesmo arquivo lógico interno, que possui
20 campos. O sistema A lê cinco campos, e apenas dois deles são atualizados. O
sistema B lê oito campos do mesmo arquivo e apenas quatro deles são atualizados.
Quantos tipos de dados devem ser computados para o arquivo lógico interno nos
sistemas A e B respectivamente?
a) 20 e 20.
b) 2 e 4.
c) 5 e 8.
d) Nenhuma das alternativas anteriores está correta.
20. Um relatório lê o arquivo de vendedores e o arquivo de vendas diárias para fornecer
como resultado o nome dos vendedores com melhor desempenho (volume de vendas)
no mês. Apenas o nome do vendedor é listado no relatório, decrescentemente por
volume de vendas. Como deve ser classificada a funcionalidade?
a) Saída externa.
b) Consulta externa.
c) Entrada externa.
d) Nenhuma das alternativas anteriores está correta.
21. Qual a contribuição mais provável das seguintes funções do tipo dado para o
número de pontos de função de uma aplicação com três ALI com mais de 60 tipos de
dados e um AIE com 15 tipos de dados?
a) 37.
b) 26.
c) 55.
d) 60.
22. Qual o número de pontos de função ajustados da seguinte aplicação: cinco arquivos
lógicos internos de baixa complexidade, um arquivo de interface externa de baixa
complexidade, seis entradas externas de complexidade média, nove entradas externas
 de complexidade alta, duas consultas externas de complexidade baixa e sete saídas
externas de complexidade média e com as seguintes características gerais:
Comunicação de Dados 3
Atualização On-line 5
Processamento Distribuído 2
Processamento Complexo 0
Performance 3
Reusabilidade 4
Configuração Altamente Utilizada 2
Facilidade de Instalação 2
Volume de Transações 3
Facilidade de Operação 5
Entrada de Dados On-line 5
Múltiplos Locais 2
Eficiência do Usuário Final 4
Modificação Facilitada 2
a) 155,40.
b) 159,00.
c) 160,85.
d) 170,13.
23. De uma tela do cadastro de clientes de um sistema é possível excluir um cliente.
Entretanto, a exclusão somente é permitida se não existirem pedidos pendentes para o
cliente. Suponha que os arquivos identificados para o sistema são Cliente, Produto,
Pedido e Vendedor. Quantos são os arquivos referenciados para esse processo de
exclusão?
a) 1.
b) 2.
c) 3.
d) 4.
24. Diariamente o sistema financeiro de uma empresa processa o arquivo texto de
extrato em meio magnético fornecido pelo seu banco para a conciliação do saldo das
contas da empresa no sistema com o saldo das contas no banco. Como esse arquivo
texto é classificado para o sistema financeiro?
a) Arquivo lógico interno.
b) Arquivo de interface externa.
c) Arquivo lógico interno ou arquivo de interface externa.
d) Não é considerado um arquivo.
25. Em uma tabela de um sistema existem os seguintes campos: código do item (chave
estrangeira), valor de janeiro, valor de fevereiro, valor de março, valor de abril, valor
de maio, valor de junho, valor de julho, valor de agosto, valor de setembro, valor de
outubro, valor de novembro e valor de dezembro. Assumindo que essa tabela seja um
arquivo lógico interno, quantos tipos de dados possui?
a) 13.
b) 12.
c) 3.
d) Nenhuma das alternativas anteriores está correta.
26. Em uma tabela de um sistema existem os seguintes campos: código (chave
primária), número da conta (chave estrangeira), descrição, data da entrada, data da
saída, e existe um índice para o número da conta e um outro para a data da entrada.
Assumindo que essa tabela seja um arquivo lógico interno, quantos tipos de dados
possui?
a) 5.
b) 6.
c) 7.
d) 4.
27. Em um sistema existem duas tabelas: Titular e Dependente. A tabela Titular possui
os seguintes campos: código do titular (chave primária), nome, sexo, data de admissão
e observação. A tabela Dependente possui os seguintes campos: código do
dependente (chave primária), código do titular (chave estrangeira), nome do
dependente e data de nascimento. Assumindo que essas tabelas sejam identificadas
como um único arquivo lógico interno, quantos tipos de dados ele possui?
a) 9.
b) 10.
c) 6.
d) 8.
28. No caso anterior, quantos tipos de registros o arquivo possui?
a) 0.
b) 1.
c) 2.
d) 3.
29. Em um sistema existe uma tela que permite alterar dados de um cliente. Os campos
existentes na tela são: nome, CPF, data de nascimento e limite de crédito. As
seguintes mensagens são emitidas para o usuário: “campo de preenchimento
obrigatório”, “CPF inválido”, “data inválida” e “limite de crédito não permitido”. A
 validação do limite de crédito consiste em não permitir que ele seja superior ao dobro
do valor das compras efetuadas no mês anterior (a tabela Pedidos é lida e o campo
valor do pedido é totalizado). Adicionalmente, o usuário pode concluir a operação
pressionando CTRL+S ou clicando no botão Salvar. Quantos tipos de dados devem
ser considerados para esse processo elementar?
a) 4.
b) 6.
c) 10.
d) 11.
30. Qual o valor máximo que pode assumir o nível de influência total de uma
aplicação?
a) 100.
b) 70.
c) 35.
d) 135.
31. Um projeto de melhoria altera uma aplicação de 900 pontos de função. Um arquivo
lógico interno tem sua complexidade alterada de baixa para média. Um arquivo de
interface externa de baixa complexidade é acrescentado. Uma consulta externa de
complexidade alta é excluída. Duas entradas externas têm sua complexidade alterada
de média para alta e três saídas externas de alta complexidade são alteradas, mas sem
que sua complexidade mude. Qual o tamanho em pontos de função do projeto de
melhoria?
a) 900.
b) 27.
c) 18.
d) 54.
32. Qual o tamanho em pontos de função da aplicação do caso anterior após o projeto
de melhoria?
a) 906.
b) 900.
c) 954.
d) 927.
33. Um relatório solicitado pelo usuário foi considerado muito trabalhoso pelo
desenvolvedor. Para facilitar a solução do problema e geração do relatório, o
desenvolvedor criou uma tabela temporária no sistema para guardar dados transitórios
para a conclusão do processo. Como é classificada essa tabela na Análise de Pontos
de Função?
 a) Arquivo lógico interno.
b) Arquivo de interface externa.
c) Saída externa.
d) O arquivo não é contado.
34. Uma empresa decidiu fazer o downsizing de seu sistema de vendas que roda no
mainframe . Para tanto, contratou (baseada em pontos de função) outra empresa para
fazer a sua migração. Decidiu-se que o novo sistema deveria ser uma cópia fiel do
atual para os usuários. A contratada sugeriu reescrever o sistema utilizando uma
abordagem em três camadas: banco de dados, aplicação e apresentação. Após o
levantamento de requisitos, a contratada apresentou, anexa à proposta, a contagem de
pontos de função do projeto de desenvolvimento. O escopo dessa contagem
estabelecia três aplicações, uma para cada camada da solução proposta. A contratante
ficou em dúvida se o escopo da contagem e as fronteiras das aplicações estavam
corretamente definidas. Quantas aplicações deveriam ser identificadas?
a) 1.
b) 2
c) 3.
d) Depende, se as três camadas estarão em máquinas diferentes ou não.
35. A transação de login de um sistema possui a seguinte característica: após o usuário
informar sua identificação e senha, o arquivo de usuários é consultado para verificar
se ele existe e a senha informada é criptografada para comparação com a senha
criptografada gravada no arquivo. Como a transação de login pode ser contada?
a) Entrada externa.
b) Consulta externa.
c) Saída externa.
d) A transação de login não é contada.
36. Uma tela permite visualizar o mesmo relatório com quatro tipos de ordenação
diferentes. O rodapé do relatório sempre traz o total de registros listados. Como essa
funcionalidade pode ser contada?
a) Uma saída externa.
b) Uma consulta externa
c) Quatro saídas externas.
d) Quatro consultas externas.
37. Um projeto de desenvolvimento com 700 pontos de função contempla cinco
entradas externas de complexidade média como funcionalidades de conversão de
dados. Qual o tamanho do projeto de desenvolvimento?
a) 700.
 b) 20.
c) 680.
d) 720.
38. Qual o tamanho da aplicação após a conclusão do projeto de desenvolvimento do
caso anterior?
a) 700.
b) 20.
c) 680.
d) 720.
39. Após determinado tempo, a aplicação do caso anterior sofre uma manutenção cujo
projeto de melhoria possui 100 pontos de função. Sabendo que esse projeto apenas
acrescentou funcionalidades à aplicação e que 12 pontos de função do projeto eram
referentes à funcionalidade de conversão, determine o novo tamanho da aplicação
após a conclusão desse projeto.
a) 700.
b) 800.
c) 692.
d) 768.
40. Um software foi desenvolvido com uma opção para habilitação da geração de um
arquivo de rastreamento da execução. A finalidade exclusiva desse arquivo é ajudar
na depuração do programa. Assim, sempre que o cliente relatar um problema, ele será
instruído a habilitar a opção de rastreamento no programa, repetir a operação que
ocasionou o problema e enviar o arquivo gerado para a análise da empresa
desenvolvedora. Como esse arquivo é contado na Análise de Pontos de Função?
a) O arquivo de rastreamento não é contado.
b) Saída externa.
c) Arquivo lógico interno.
d) Arquivo de interface externa.
41. Os passos de todas as transações de uma aplicação de autoatendimento de um banco
são rastreados em um arquivo. A finalidade desse arquivo é ajudar o banco a resolver
divergências alegadas por clientes em transações realizadas no autoatendimento.
Como esse arquivo é contado na Análise de Pontos de Função?
a) O arquivo de rastreamento não é contado.
b) Consulta externa.
c) Arquivo lógico interno.
d) Arquivo de interface externa.
42. Uma aplicação foi desenvolvida de tal forma que todas as mensagens emitidas para
o usuário são lidas de uma tabela criada pelo programador. Sempre que o usuário
solicita a mudança de uma mensagem, o programador apenas altera o texto na tabela,
sem a necessidade de alteração e recompilação do programa. Como essa tabela é
contada na Análise de Pontos de Função?
a) A tabela de mensagens não é contada.
b) Saída externa.
c) Arquivo lógico interno.
d) Arquivo de interface externa.
43. O usuário da aplicação do caso anterior solicitou que fosse construída uma tela no
sistema para que alguns usuários com acesso privilegiado pudessem alterar eles
próprios o texto das mensagens do sistema. Como essa tela é contada?
a) Entrada externa, pois o comportamento da aplicação é alterado.
b) A tela não é contada, pois o arquivo é Dados de Código.
c) Arquivo lógico interno ou arquivo de interface externa.
d) Saída externa ou consulta externa.
44. O projeto de melhoria citado no caso anterior afeta o tamanho funcional da
aplicação?
a) Não, uma vez que a tela não é contada.
b) Sim, o tamanho pode aumentar em até 6 pontos de função.
c) Não é possível responder à questão com as informações disponíveis.
d) Sim, o tamanho aumenta no mínimo em 10 pontos de função.
45. Sabe-se que um relatório necessita buscar dados em quatro tabelas (que também são
arquivos lógicos internos). Quantos pontos de função possui esse relatório?
a) 3 ou 4 ou 5 ou 6 ou 7 pontos de função.
b) 3 ou 4 ou 6 pontos de função.
c) 4 ou 5 ou 7 pontos de função.
d) 4 ou 5 ou 6 ou 7 pontos de função.
46. Para manter a integridade referencial dos dados de uma aplicação, a opção de
exclusão de um cliente consulta os arquivos de pedidos, notas fiscais e cobranças.
Supondo que existam três tipos de dados, quantos pontos de função possui esse
processo elementar?
a) 6.
b) 5.
c) 4.
d) 3.
47. Supondo que o processo elementar do caso anterior passasse a referenciar mais um
arquivo, quantos pontos de função possuiria?
a) 6.
b) 5.
c) 4.
d) 3.
48. Uma consultoria foi contratada para identificar problemas de performance no banco
de dados de uma aplicação. Após análise concluiu-se que uma tabela importante do
sistema deveria ser particionada em duas. Supondo que essa tabela fosse um arquivo
lógico interno, qual o impacto no tamanho funcional da aplicação?
a) Deve-se contar mais um novo arquivo lógico interno.
b) Deve-se contar mais um arquivo referenciado nas transações que utilizavam a
tabela que foi particionada.
c) Ambos A e B.
d) Nenhum.
49. Em um projeto de desenvolvimento, o cliente inicialmente afirmou que o pico do
volume de transações a serem processadas pela aplicação seria esporádico; ocorreria
apenas em vésperas de feriado. Após análise mais aprofundada verificou-se que a
aplicação deveria suportar picos de transação diários. Qual o impacto dessa nova
análise no tamanho funcional da aplicação?
a) 1%.
b) 2%.
c) 3%.
d) Nenhum.
50. Em um outro projeto de desenvolvimento com 500 pontos de função, contratou-se
uma empresa para construir uma aplicação para rodar no telefone celular modelo A.
Posteriormente, o cliente decidiu criar outros modelos de aparelho, entretanto
similares ao modelo A. Foi decidido que o projeto já contratado deveria também
contemplar esses novos aparelhos. Qual o tamanho do projeto de desenvolvimento
após esta decisão?
a) 500.
b) 505.
c) 501.
d) 570.

Parte 3 - Estudos de Caso

 Caso 1. Assinale o tipo das funções do seguinte sistema para controlar a
contratação do aluguel de veículos. Alguns dos requisitos do usuário são:
Cliente: todo cliente deve fazer um cadastro para poder efetuar a locação do veí‐
culo. Será possível incluir, alterar, excluir e consultar os clientes cadastrados. Os dados
dos clientes que devem constar no cadastro são Código do Cliente, Tipo de Cliente,
nome, endereço, número, complemento, bairro, cidade, UF, CEP, telefone e CPF/CNPJ.
O sistema efetua validações, devendo emitir mensagens de erro. Os campos são os
mesmos para inclusão, alteração e consulta. Para a exclusão é solicitado somente o
código do cliente. Apenas o campo código do cliente não será habilitado na alteração. O
sistema deve impedir a exclusão de clientes que possuam contratação de veículo. Os
dados referentes ao Estado são estáticos e, quando necessário, alterados pela área de TI
diretamente no banco de dados.

Função ALI AIE EE SE CE N/A

1. Cliente
2. Incluir cliente
3. Alterar cliente
4. Solicitar código do cliente
5. Consultar cliente
6. Validar CPF/CNPJ cliente
7. Consultar clientes com locação
8. Lista de estados
9. Excluir cliente

Caso 2. No aparelho de telefone celular da ACME, modelo XYZ, existem diversas

funcionalidades (manutenção de agenda, configuração do aparelho, gerenciamento de
mensagens SMS e fotos). Os requisitos de dados que suportam as transações são:
 Grupos de Dados Campos
Nome
Agenda Telefônica
Telefone
Tipo de Toque
Configuração Volume de Toque
(uma ocorrência) Código de Segurança
Ligação (bloqueada/desbloqueada)
Tipo de Toque Código do Tipo de Toque
(cinco ocorrências) Descrição do Tipo de Toque
Data e hora do recebimento
Texto
Mensagem (torpedo)
Número do telefone remetente
Situação (lida/não lida)
Imagem
Foto
Data/hora

Assinale a complexidade dos arquivos lógicos.

Arquivo Baixa Média Alta N/A

1. Agenda
2. Configuração
3. Tipo de Toque
4. Mensagem
5. Foto

Caso 3. Assinale a complexidade das funções do seguinte sistema de controle de

compras e estoque. Todas as telas exibem uma mensagem ao usuário informando-o da
situação da operação solicitada. Para comandar a ação o usuário pressiona sempre um
botão, que representa a operação desejada. O usuário ainda pode cancelar a operação
pelo botão “Cancelar”. Neste caso o sistema limpa os dados da tela, mas permanece na
mesma tela. Toda tela deve possuir a funcionalidade de poder voltar ao menu anterior
pelo botão “Voltar”. A tela de manutenção dos produtos que a empresa comercializa
tem as funcionalidades de incluir, excluir e alterar. Oferece também a possibilidade de
consultar os produtos com a opção de impressão. Além disso:
• Os produtos são armazenados no arquivo “Produto”.
• A linha de produtos também é mantida nesse sistema em um outro
módulo do sistema. Segmento e tipo de produto são dados
estáticos.
• Os dados de fornecedor são mantidos em outro sistema, e no
sistema de controle de compras e estoques usam-se apenas código,
nome, telefone, e-mail, CNPJ/CPF do fornecedor.
• Todo produto deve ser comprado de um fornecedor cadastrado.
• Na Inclusão o usuário deve fornecer as seguintes informações:
Nome do Produto, Código do Fornecedor, Código do Segmento,
Código do Tipo Produto, Código da Linha do Produto e Código de
Referência. Para a inclusão de um produto é obrigatório já existir
o Fornecedor, o Segmento, o Tipo Produto e a Linha do Produto.
• Na Alteração o usuário deve, obrigatoriamente, fornecer o Código
do Produto. É permitido alterar as seguintes informações: Nome
do Produto, Código do Fornecedor, Código do Segmento, Código
do Tipo Produto, Código da Linha Produto e Código de
Referência. Para todas as alterações no depósito “Produto”, o
sistema deve gerar um LOG no depósito “LOG Produto”, com a
as informações anteriores à alteração.
• Na Exclusão deve ser fornecido o Código do Produto. As mesmas
informações utilizadas na inclusão/alteração devem ser
apresentadas para o usuário poder excluir o produto.
• O sistema deve possibilitar ao usuário solicitar a Relação dos
Produtos ativos ou cancelados (obrigatório um dos dois) e com os
seguintes filtros e na respectiva ordem: Código do Fornecedor,
Código do Segmento, Código do Tipo do Produto e Código da
Linha do Produto. Todas as informações de entrada são opcionais.
As seguintes informações devem aparecer: Código do Produto,
Nome do Produto, Nome do Fornecedor, Nome do Segmento,
Nome do Tipo do Produto e Nome da Linha do Produto. Todas as
informações são opcionais. A relação dos Produtos pode ser
ordenada pelo código ou nome.
• Para informar o Fornecedor, Segmento, Tipo do Produto e Linha
do Produto, o usuário pode fornecer a informação ou selecioná-la
a partir de um drop-down list box com a descrição e o respectivo
código.
 Função Baixa Média Alta N/A
1. Produto - Incluir
2. Produto - Alterar
3. Produto - Excluir
4. Produto - Consultar
5. Produto - Relação
6. Arquivo de Produtos
7. Arquivo de Fornecedor
8. Fornecedor - drop-down
9. Arquivo de Linha de Produtos
10. Linha de Produtos - drop-down

Caso 4. Assinale o tipo das transações do aparelho de telefone celular da ACME,

modelo XYZ. Os requisitos de dados que suportam as transações são:

Grupos de Dados Campos

Nome
Agenda Telefônica
Telefone
Tipo de Toque
Configuração Volume de Toque
(uma ocorrência) Código de Segurança
Ligação (bloqueada/desbloqueada)
Tipo de Toque Código do Tipo de Toque
(cinco ocorrências) Descrição do Tipo de Toque
Mensagem (torpedo) Data e hora do recebimento
 Texto
Número do telefone remetente
Situação (lida/não lida)
Foto Imagem

Inclusão na agenda: o usuário informa o nome e o telefone e os dados são

gravados. Não são permitidos nomes duplicados. Se houver um nome já existente, a
aplicação pergunta se deseja sobrescrever os dados existentes.
Busca na agenda: o usuário pode informar parte de um nome para busca direta ou
pode navegar entre os registros existentes até encontrar o que deseja. São exibidos o
nome e o telefone.
Alteração na agenda: após a busca de um nome na agenda, o usuário pode alterar
o nome e o telefone do registro corrente.
Exclusão de registro da agenda: após a busca de um nome na agenda, o usuário
pode excluir o registro corrente.
Exclusão de todos os registros da agenda: nessa opção o usuário apaga todos os
registros da agenda de uma única vez.
Alteração de tipos de toque: o usuário pode selecionar, dentre as opções de toque
disponíveis, qual será utilizada pelo aparelho.
Alteração de volume: o usuário pode selecionar, dentre os cinco níveis de volume
disponíveis, qual será utilizado pelo aparelho.
Bloqueio/desbloqueio do teclado: com a mesma combinação de teclas, o usuário
pode bloquear ou desbloquear o uso do teclado.
Consulta Caixa de Mensagens: o usuário pode visualizar todas as mensagens
recebidas, sendo destacadas as que já foram lidas. Em função da limitação do visor,
apenas os primeiros 15 caracteres do texto da mensagem são apresentados.
Leitura de mensagens: durante a consulta da caixa de mensagens, o usuário pode
optar por ler determinada mensagem. Essa opção apresenta o texto completo, a data e
hora da recepção e o telefone do remetente e muda a situação da mensagem para “lida”.

Função EE SE CE N/A
1. Inclusão na agenda
2. Busca na agenda
3. Alteração na agenda
4. Exclusão de registro da agenda
5. Exclusão de todos os registros da agenda
6. Alteração de tipos de toque
7. Alteração de volume
8. Bloqueio/desbloqueio do teclado
9. Consulta caixa de mensagens
 10. Leitura de mensagens

Caso 5. Assinale a complexidade dos arquivos do seguinte sistema de faturamento.

O menu tem as seguintes opções:

Cidades Clientes Notas fiscais

Inclusão de Cidade Inclusão de Cliente Inclusão de Nota Fiscal
Alteração de Cidade Alteração de Cliente Alteração de Nota Fiscal
Exclusão de Cidade Exclusão de Cliente Exclusão de Nota Fiscal
Consulta de Cidade Consulta de Cliente Consulta de Nota Fiscal
Impressão de Nota Fiscal

Os requisitos de dados do sistema estão descritos na tabela seguinte. Os campos

marcados com “PK” são chaves primárias e os com “FK” são chaves estrangeiras.
Assuma que a tabela Contato Cliente constitui-se em um subgrupo de dados da tabela
Cliente e que as tabelas Item Nota Fiscal e Imposto Incidente Nota Fiscal também sejam
subgrupos de dados da tabela Nota Fiscal. A tabela Imposto é mantida por outra
aplicação, sendo apenas referenciada pela aplicação de faturamento.

Tabela Campo
Sigla do Estado (PK)
Estado
Nome do Estado
Identificador da cidade (PK)
Nome da cidade
Cidade
Sigla do Estado (FK)
Isenta ISS? (S/N)
Identificador do cliente (PK)
Razão Social
Logradouro
Número
Bairro
CEP
Cliente
Identificador da cidade (FK)
Telefone
CNPJ
Inscrição Estadual
Inscrição Municipal
Observação
Identificador do cliente (PK, FK)
Identificador do contato (PK)
Nome
Sexo
Contato Cliente
Data de Nascimento
Cargo
Telefone
Observação
 Tabela Campo
Identificador do imposto (PK)
Nome
Imposto
Descrição para impressão
Alíquota
Identificador da nota fiscal (PK)
Número da nota fiscal
Identificador do cliente (FK)
Data de emissão
Nota Fiscal
Data de vencimento
Valor
Situação
Motivo do cancelamento
Identificador da nota fiscal (PK, FK)
Identificador do item (PK)
Unidade
Item Nota Fiscal Quantidade
Descrição
Valor unitário
Valor total
Identificador da nota fiscal (PK,FK)
Identificador do imposto (PK, FK)
Imposto Incidente Nota Fiscal Valor incidente
Situação de impressão
Situação de dedução

Arquivo Baixa Média Alta N/A

1. Cidade
2. Estado
3. Cliente
4. Contato
5. Imposto
6. Nota fiscal
7. Item nota fiscal
8. Imposto incidente nota fiscal
9. Cargo
10. Motivos de cancelamento

Caso 6. Assinale o tipo das funções que farão parte do escopo da contagem do
projeto de melhoria do sistema apresentado em seguida. O banco ACME possui um
sistema para o fornecimento de vale-alimentação, que autoriza de forma on-line as
compras em supermercados (pagas agora com o cartão magnético em vez de tickets).
Antes da implantação desse sistema já existia um sistema responsável por gerenciar
toda a retaguarda do serviço de vale-alimentação, com o qual o sistema autorizador de
compras interage. Esse sistema autorizador de compras processa transações originadas
no sistema de retaguarda, nos PDVs dos estabelecimentos comerciais e na Internet. Não
há interação direta de um usuário final com o sistema. As funções que esse sistema
possui atualmente são:

Consulta de Saldo Troca de Senha

Extrato Reinicialização de Senha
Crédito Bloqueio de Cartão pelo Beneficiário
Saque Bloqueio de Cartão pelo Banco
Estorno de Saque Desbloqueio de Cartão

As únicas transações que não necessitam de validação de senha do cartão do cliente

são crédito, reinicialização de senha, bloqueio de cartão (pelo beneficiário e pelo banco)
e desbloqueio de cartão.
Requisitos de Dados

Estabelecimento Comercial Cartões

Empresa Cliente Log de Transações
Empregado Beneficiário

Requisitos de Melhorias
• Será criada uma tabela chamada Controle Geral com um único
registro (uma ocorrência) que armazena os seguintes parâmetros:
valor limite de compras por dia, valor máximo de compra, número
máximo de tentativas incorretas de senha.
• À tabela Empregado Beneficiário serão acrescentados os seguintes
campos: número de tentativas incorretas de senha e valor de
compras no dia. A senha, que antes era armazenada de forma
natural, será armazenada criptografada.
• Todas as transações que validam senha continuarão recebendo a
senha no formato natural até que os sistemas com as quais
interagem também sejam alterados. A senha recebida deve ser
criptografada para comparação com a senha armazenada. Caso a
validação de senha falhe, o campo número de tentativas incorretas
de senha deve ser atualizado na tabela de Beneficiário. Se o
 número de tentativas incorretas exceder o valor definido na tabela
Controle Geral, o cartão deve ser bloqueado e uma transação de
bloqueio deve ser gravada no log de transações. Caso a validação
de senha tenha sucesso, o campo número de tentativas incorretas
na tabela de Beneficiário deve ser zerado.
• Será criada uma transação para possibilitar a alteração de
parâmetros na tabela Controle Geral.
Dados de entrada Dados de saída
Código da transação - constante “PAR” Código da transação - constante “PAR”
Limite de compras por dia Código de resposta
Valor máximo de compra
Número máximo de tentativas incorretas de senha

• Toda transação de saque efetuada com sucesso deve incrementar o

campo valor de compras no dia da tabela Beneficiário. Haverá
também duas novas validações: o valor da compra não pode
exceder o valor máximo definido na tabela Controle Geral e o
valor limite de compras no dia também deve ser respeitado.
Função ALI AIE EE SE CE N/A
1. Estabelecimento comercial
2. Empresa cliente
3. Empregado beneficiário
4. Cartões
5. Controle geral
6. Alteração de parâmetros
7. Crédito
8. Saque
9. Estorno de saque

Caso 7. Assinale a complexidade das funções de dados do seguinte sistema. Em

todas as tabelas são gravados campos para auditoria de manutenção dos dados (DT
Inclusão, DT Alteração, DT Cancelamento, Flag Ativo, ID Usuário). As tabelas Estado
e Linha de PRD são mantidas pelo desenvolvedor através de utilitário do sistema
gerenciador do banco de dados.

Produto Fornecedor Funcionário LOG Produto

 CD Produto (PK) CD Fornecedor (PK) CD Funcionário (PK) CD Produto (PK)
NM Produto NM Fornecedor NM Funcionário Timestamp (PK)
CD Fornecedor (FK) Endereço Endereço NM Produto
CD Segmento (FK) Cidade Cidade CD Fornecedor (FK)
CD Tipo PRD (FK) SG Estado (FK) SG Estado (FK) CD Segmento (FK)
CD Linha PRD (FK) Telefone Telefone CD Tipo PRD (FK)
CD Referencia DT Inclusão DT Inclusão CD Linha PRD (FK)
DT Inclusão DT Alteração DT Alteração CD Referencia
DT Alteração DT Cancelamento DT Cancelamento DT Inclusão
DT Cancelamento Flag Ativo Flag Ativo DT Alteração
Flag Ativo ID Usuário ID Usuário DT Cancelamento
ID Usuário Login Flag Ativo
Senha ID Usuário
Segmento Tipo de PRD Linha de PRD Estado
CD Segmento (PK) CD Tipo PRD (PK) CD Linha PRD (PK) CD Estado (PK)
DE Segmento DE Tipo PRD DE Linha PRD NM Estado
DT Inclusão DT Inclusão DT Inclusão DT Inclusão
DT Alteração DT Alteração DT Alteração DT Alteração
DT Cancelamento DT Cancelamento DT Cancelamento DT Cancelamento
Flag Ativo Flag Ativo Flag Ativo Flag Ativo
ID Usuário ID Usuário ID Usuário ID Usuário

Produto arquivo Baixa Média Alta N/A

Fornecedor
Funcionário
Estado
Linha de PRD

Caso 8 . Assinale a complexidade das transações do seguinte sistema de autorização

de compras.
Extrato: verifica se o estabelecimento comercial de origem, o beneficiário e o
cartão existem. Verifica também a senha, a situação e a data de validade do cartão. Se
todas as validações estiverem corretas, é montado um texto de extrato com o saldo
atual, obtido a partir da tabela de beneficiários, e seus últimos lançamentos, obtidos a
partir da tabela de log de transações. Um registro de tarifa é criado na tabela de log
(com a situação “ativa”).
Saque: verifica se o estabelecimento comercial de origem, o beneficiário e o cartão
existem. Valida se a situação do estabelecimento comercial de origem e da empresa
cliente do beneficiário está correta. Verifica também a senha, a situação, a data de
validade do cartão e se há saldo disponível para realizar a transação. Se todas as
validações estiverem corretas, o saldo do beneficiário é subtraído do valor da transação,
um registro é criado na tabela de log (com a situação “ativa”) e o número da transação é
devolvido nos dados de saída.
Crédito: confere se o beneficiário existe. Adiciona o valor da transação ao saldo do
cartão e cria um registro na tabela de log (com a situação “ativa”). O número da
transação é devolvido nos dados de saída.
Estorno de saque: verifica se o estabelecimento comercial de origem existe e se a
transação informada existe na tabela de log, se é uma transação de saque e se sua
situação é ativa. Se todas as validações estiverem corretas, o saldo do beneficiário é
adicionado do valor da transação informada, a transação informada tem sua situação
alterada de “ativa” para “estornada”, um registro é criado na tabela de log (com a
situação “ativa”) e o número da transação é devolvido nos dados de saída.
Troca de senha : confere se o estabelecimento comercial de origem, o beneficiário
e o cartão existem. Verifica também a senha. Se todas as validações estiverem corretas,
a senha do beneficiário é alterada. Um registro também é criado na tabela de log.

Função EE SE CE N/A
1. Extrato
2. Saque
3. Crédito
4. Estorno de saque
5. Troca de senha

Caso 9. Assinale o tipo das funções do seguinte sistema de locação de veículos.

Contratação de Veículos: para efetuar a contratação dos seguintes campos devem
ser informados pelo usuário na tela de contratação: Código do Cliente ou CPF/CNPJ do
cliente (o nome do cliente é exibido automaticamente), data da retirada, data de
devolução (não será habilitado), data de entrega, código do veículo (ou a sua seleção na
lista de veículos disponíveis para locação que apresenta os seguintes dados somente dos
veículos que não estão locados: código do veículo, tipo, descrição, fabricante e ano
modelo), valor da diária, valor total e emissor (arquivo também estático contendo a lista
de funcionários autorizados a efetuar emissão de veículos, alterado pela área de TI
quando necessário). Ao informar/selecionar o veículo para locação, o número do chassi
e o valor da franquia são exibidos automaticamente na tela. O sistema vai verificar se o
veículo pode ser alugado, o seguro e a data da última inspeção. Caso haja algum
problema, uma mensagem de aviso é enviada ao usuário. A lista de veículos disponíveis
exibe os veículos que não estão contratados (código, tipo do veículo, descrição, ano
modelo).
 Devolução de Veículos: para devolver um veículo o usuário informa na tela de
contratação o código da contratação. Os dados da contratação são exibidos e após clicar
em alterar, informa-se a data da devolução e ajusta-se o valor total da contratação, se
necessário.
Mensalmente o sistema deve emitir um relatório de clientes, calculando e exibindo
o total de contratações por cada cliente naquele mês. Devem ser apresentados os
campos Mês, Código do Cliente, CPF/CNPJ, Nome do Cliente ou Razão Social,
Quantidade de Locações no Mês, Valor Contratado no Mês e Total Geral.
Relatório Mensal de Locações Efetuadas - Mês de XXXXXXX
CÓD
CPF/CNPJ NOME / RAZÃO SOCIAL QTD LOCAÇÕES VALOR CONTRATADO NO MÊS
CLIENTE
XXXXX NN.NNN.NNN/NNNN-XX XXXXXXXXXXXXXXXXXXXXXXXXXXXX NNNN NNN.NNN.NNN,NN
XXXXX NN.NNN.NNN/NNNN-XX XXXXXXXXXXXXXXXXXXXXXXXXXXXX NNNN NNN.NNN.NNN,NN
XXXXX NN.NNN.NNN/NNNN-XX XXXXXXXXXXXXXXXXXXXXXXXXXXXX NNNN NNN.NNN.NNN,NN
XXXXX NN.NNN.NNN/NNNN-XX XXXXXXXXXXXXXXXXXXXXXXXXXXXX NNNN NNN.NNN.NNN,NN
XXXXX NN.NNN.NNN/NNNN-XX XXXXXXXXXXXXXXXXXXXXXXXXXXXX NNNN NNN.NNN.NNN,NN
XXXXX NN.NNN.NNN/NNNN-XX XXXXXXXXXXXXXXXXXXXXXXXXXXXX NNNN NNN.NNN.NNN,NN
XXXXX NN.NNN.NNN/NNNN-XX XXXXXXXXXXXXXXXXXXXXXXXXXXXX NNNN NNN.NNN.NNN,NN
XXXXX NN.NNN.NNN/NNNN-XX XXXXXXXXXXXXXXXXXXXXXXXXXXXX NNNN NNN.NNN.NNN,NN
TOTAL GERAL: R$ NNN.NNN.NNN,NN

Função EE SE CE N/A
1. Consulta nome cliente
2. Autoriza contratação
3. Contratação - inclusão
4. Contratação - alteração
5. Ajusta valor da contratação
6. Contratação - consulta
7. Contratação - exclusão
8. Relatório mensal locações efetuadas
9. Lista veículos disponíveis
 Função EE SE CE N/A
10. Verifica inspeção

Caso 10. Assinale o tipo das funções que farão parte do escopo da contagem do
projeto de melhoria do sistema seguinte.
Cadastro de Clientes: permite incluir, alterar, excluir, consultar e emitir um
arquivo mensal de aniversariantes. Para efetuar a inclusão de um cliente os seguintes
campos são preenchidos: Nome do Cliente, CPF, Endereço (Rua/Av., número,
complemento, bairro, cidade, estado e CEP), Data de Nascimento, e-mail. O campo
Código do Cliente é gerado automaticamente pelo sistema. Ao informar o CEP, o
sistema traz todas as informações de endereço das tabelas de CEPs dos correios para o
endereço do cliente, e o usuário pode alterar os dados se desejar. Ao alterar o CEP do
Cliente, o sistema pergunta se deseja sobrescrever os dados de endereço do cliente com
os dados dos correios. Os campos são os mesmos para a alteração, porém o Nome do
Cliente, a Data de Nascimento, o CPF e o Código do Cliente não podem ser alterados.
Para a exclusão é necessário informar o CPF ou o Código do Cliente. Na consulta, todos
os campos da inclusão são apresentados.
Mensalmente é gerado um arquivo para o sistema de mala direta que contém os
aniversariantes do mês. Os campos constantes no arquivo são Código do Cliente, Nome
do Cliente, Endereço, Data de Aniversário (somente o dia) e idade atual.
Requisitos da melhoria:
• Não permitir cadastrar um cliente com CPF duplicado.
• Incluir o e-mail na relação de aniversariantes.
• Montar um relatório de clientes inadimplentes, consultando no
sistema de contas a receber as contas em atraso a mais de 30 dias.
O relatório deve exibir nome do cliente, data do vencimento, valor
da conta, telefone de contato e o total a receber de todos os
clientes no rodapé.
 Glossário
A seguir, são definidos os termos utilizados na técnica da Análise de
Pontos de Função. Alguns deles também estão em inglês por ser comum sua
utilização na versão original pela comunidade APF do Brasil.

A
AIE: Arquivo de Interface Externa.
ALI: Arquivo Lógico Interno.
ALR: Arquivos Lógicos Referenciados. Nomenclatura obsoleta para arquivos
referenciados.
Alteração do Comportamento do Sistema: Modificar o comportamento do sistema
significa alterar um parâmetro de negócio (através de alguma transação). O efeito causado
por essa mudança no parâmetro tem reflexo no comportamento de outras transações.
Exemplo: o sistema de compras dá autonomia para que cada comprador possa efetuar
compras de até R$ 10.000,00 no mês sem autorização da chefia. Este valor é um parâmetro
do sistema e quando for alterado, afetará as transações de compra, ou seja, vai alterar o
comportamento do sistema.
Análise de Pontos de Função: Método padrão para medir as funcionalidades de um
software sob a perspectiva do usuário. Objetivos da técnica: medir a funcionalidade que o
usuário solicita e recebe; medir o desenvolvimento e a manutenção de software de forma
independente da tecnologia utilizada para sua implementação.
Objetivos do Processo de Contagem: Ser simples o suficiente para minimizar o
esforço adicional envolvido no processo de medição; uma medida consistente entre vários
projetos e organizações.
Benefícios da APF: Determinar o tamanho de um pacote adquirido; ajudar usuários a
determinar os benefícios de um pacote para sua organização; suportar a análise de
produtividade e qualidade; estimar custos e recursos para desenvolvimento e manutenção
de software; fator de normalização para comparação de software.
APF: Análise de Pontos de Função.
Aplicação: Conjunto coeso e automatizado de funções, procedimentos e dados que
dão sustentação a um objetivo de negócio. Também chamado de sistema ou sistema de
informação.
 AR: Arquivo Referenciado.
Arquivo: No contexto da APF este termo não significa arquivo no sentido tradicional
de processamento de dados. Nesse caso, arquivo refere-se a um grupo lógico de dados ou
informações de controle, e não à implementação física destes. É classificado em ALI ou
AIE.
Arquivo de Interface Externa: Grupo de dados ou informações de controle,
logicamente relacionados, referenciados pela aplicação, mas mantidos na fronteira de outra
aplicação. Sua principal intenção é armazenar dados referenciados através de um ou mais
processos elementares da aplicação sendo contada. Um AIE contado para uma aplicação
deve ser um ALI para outra aplicação.
Arquivo Lógico Interno: Grupo de dados ou informações de controle, logicamente
relacionados, mantidos na fronteira da aplicação. Sua principal intenção é armazenar dados
mantidos através de um ou mais processos elementares da aplicação sendo contada.
Arquivo Referenciado: É um ALI lido ou mantido pela função do tipo transação, ou
um AIE lido pela função do tipo transação. A complexidade funcional de cada EE, SE e
CE é atribuída com base no número de arquivos referenciados e tipos de dados.

B
Baseline : Base instalada; o mesmo que contagem de aplicação.
Benchmarking : É a busca das melhores práticas na indústria que conduzem ao
desempenho superior.
BFPUG: Brazilian Function Point Users Group . É a representação oficial do IFPUG
no Brasil.
Bug: Defeito de um software.

C
Caso de Uso: O caso de uso é um documento que representa uma unidade discreta de
interação entre o usuário e o sistema, ou seja, um conjunto de operações que produz um
resultado concreto. Ele descreve uma funcionalidade que o sistema possui do ponto de
vista da interação usuário (ou ator) e o sistema. Não deve conter termos técnicos da área de
desenvolvimento, apenas a linguagem do usuário. Também não deve descrever como o
sistema será construído. Tipicamente um sistema terá vários casos de uso, cada um
abordando uma parte do que o sistema irá fornecer ao seu usuário.
 Características Gerais do Sistema: Refletem as funcionalidades gerais fornecidas
pela aplicação ao usuário. São elas: Comunicação de Dados, Processamento Distribuído,
Performance, Configuração Intensamente Utilizada, Volume de Transações, Entrada de
Dados On-Line, Eficiência do Usuário Final, Atualização On-Line, Processamento
Complexo, Reusabilidade, Facilidade de Instalação, Facilidade de Operação, Múltiplos
Locais e Facilidade de Mudança.
CE: Consulta Externa.
CFPS: Certified Function Point Specialist .
Chave Estrangeira: Campo em um arquivo, reconhecido e solicitado pelo usuário,
que existe para estabelecer um relacionamento com outro arquivo. A chave estrangeira
aponta para a chave primária do outro arquivo relacionado.
CPM: Counting Practices Manual.
COCOMO II: COnstructive COst MOdel é um modelo de estimativa paramétrico que
envolve o uso de equações matemáticas para fazer estimativas de esforço, prazo e tamanho
da equipe em projetos de software. Suas equações são baseadas em pesquisa e dados
históricos e utilizam como entrada a quantidade de linhas de código (ou pontos de função)
e a avaliação de outros aspectos relevantes para a estimativa chamados de cost drivers .
Complexidade Funcional: É a classificação de um tipo de função em particular.
Assume os seguintes valores: baixa, média e alta. Para as funções tipo dados, a
complexidade é determinada pelo número de tipos de registro (Registros Lógicos
Referenciados - RLR - ou Record Element Types - RET) e tipos de dado (Dados
Elementares Referenciados - DER - ou Data Element Types - DET). Para as funções de
tipo transacional, a complexidade é determinada pelo número de arquivos referenciados
(Arquivos Lógicos Referenciados - ALR - ou File Type Referenced - FTR) e tipos de
dados.
Contagem de Aplicação: Mede a aplicação instalada. Também chamada de baseline .
Reflete a funcionalidade atualmente fornecida pela aplicação. É inicializada ao término do
projeto de desenvolvimento e atualizada ao término de cada projeto de melhoria que altera
a funcionalidade da aplicação.
Contagem de Projeto de Desenvolvimento: Mede as funcionalidades fornecidas ao
usuário na primeira instalação da aplicação. Inclui também toda a funcionalidade
necessária à conversão de dados.
Contagem de Projeto de Melhoria: Mede modificações que incluem, excluem ou
alteram funcionalidades em aplicações existentes. Inclui também toda a funcionalidade
necessária à conversão de dados.
Contagem Estimativa: Técnica proposta pela NESMA para estimar o tamanho em
pontos de função de um sistema baseado apenas na identificação de todas as suas funções,
sem a necessidade de identificar a complexidade delas. Neste caso a complexidade para os
arquivos é tratada como baixa e para as transações, tratada como média.
Contagem Indicativa: Técnica proposta pela NESMA para estimar o tamanho em
pontos de função de um sistema baseado apenas na identificação de seus arquivos lógicos e
aplicação do peso de 35 PF para cada ALI e 15 PF para cada AIE.
Consulta Externa: Processo elementar que envia dados ou informações de controle
além da fronteira da aplicação. Sua principal intenção é apresentar informação ao usuário
através da recuperação de dados ou informações de controle de um ALI ou AIE. A lógica
de processamento não deve conter fórmula matemática ou cálculo, não deve criar dados
derivados, nem manter um ou mais ALI, nem alterar o comportamento do sistema.
Conversão de Dados: São funções construídas e entregues pelo projeto (de
desenvolvimento ou melhoria) para serem usadas no momento da instalação do projeto
para converter dados ou fornecer outros requisitos de conversão especificados pelo usuário,
como relatórios de verificação da conversão. A característica dessas funções é que elas são
descartadas após o seu uso, não fazendo parte das funções da aplicação após sua instalação.
Quando o sistema entra em operação, essas funções não são mais necessárias.
Counting Practices Manual : O mesmo que manual de práticas de contagem do
IFPUG.
Custo: Soma dos dispêndios em que se incorre no processo de produção de uma
mercadoria ou serviço.

D
Dados de Código: Também chamados de dados de lista ou dados de tradução. O
usuário nem sempre os especifica diretamente. Em outros casos, eles são identificados pelo
desenvolvedor em resposta a um ou mais requisitos técnicos do usuário. Eles proveem uma
lista de valores válidos que um atributo descritivo pode assumir. Tipicamente seus atributos
são código, descrição e/ou outros atributos “padrão” descrevendo o código; por exemplo,
abreviação padrão, datas de início e término de vigência, dados de auditoria etc.
Dados de Negócio: Esse tipo de dados reflete a informação cujo armazenamento e
recuperação pela área funcional que a aplicação atende são necessários. Geralmente
representam um percentual significativo das entidades identificadas. Também chamados de
core user data ou objetos de negócio.
Dados de Referência: Dados desse tipo são armazenados para suportar regras de
negócio para a manutenção de dados de negócio. Existem para suportar regras de negócio
para a manutenção de dados de negócio. Representam um pequeno percentual das
entidades identificadas. Possuem poucos atributos e são dados pouco dinâmicos. Devem
ser contados como ALIs ou AIEs. Por exemplo, em uma aplicação de folha de pagamento
ele seria o dado armazenado sobre as alíquotas de imposto do governo para cada faixa
salarial e a data em que vigoram. Geralmente representam um pequeno percentual das
entidades identificadas.
Dado Derivado: Informação criada a partir da transformação de dados existentes.
Requer outro proces- samento além da recuperação, conversão e edição direta de dados de
um arquivo lógico interno e/ou arquivo de interface externa. Ou seja, é um dado
apresentado pelo sistema, mas que não está armazenado em um arquivo lógico. Ele é
criado através de uma lógica de processamento (cálculo, por exemplo). Exemplos de dados
derivados podem ser todos os campos apresentados pela transação que sejam resultados de
cálculos: total de faturamento, tempo médio entre falhas, porcentagem de participação do
produto X nas vendas etc.
Data Element Type : Tipo de dado.
Data Function Type : Função do tipo dado.
Defeito: Um problema em uma aplicação que, se não corrigido, pode provocar sua
falha ou a geração de resultados incorretos. A ausência de funcionalidade que foi
especificada e solicitada também é considerada um defeito.
Desenvolvimento: Especificação, análise, projeto, construção, teste e implantação de
um novo sistema de informação.
DET: Data Element Type.
DER: Dado Elementar Referenciado. Nomenclatura obsoleta para tipo de dado.
Degree of Influence : É o mesmo que Nível de Influência.
DI: Degree of Influence .
Diagrama de Contexto: Representa todo o sistema como um único processo e é
composto por fluxos de dados que mostram as interfaces entre o sistema e as entidades
externas. O diagrama é uma forma de representar o objeto do estudo, o projeto e sua
relação com o ambiente. Permite identificar os limites dos processos, as áreas envolvidas
com o processo e os relacionamentos com outros processos e elementos externos à empresa
(por exemplo, clientes, fornecedores).
Documento de Visão: Contém a visão que os envolvidos têm do sistema a ser
desenvolvido, em termos das necessidades e características mais importantes. Por conter
uma descrição dos requisitos centrais pretendidos, ela proporciona a base para requisitos
mais detalhados. Também pode conter uma especificação de requisitos formal. O
documento de visão captura restrições de design e requisitos de alto nível para que o
usuário possa compreender o sistema que será desenvolvido.

E
EE: Entrada Externa.
 EI: External Input.
EIF: External Interface File.
Elicitação: É a atividade de obtenção, pesquisa, descoberta ou e/ou identificação dos
requisitos que os usuários possuem para um projeto ou sistema.
Entidade: Uma coisa fundamental ou de relevância para o usuário, sobre a qual uma
coleção de fatos é mantida. Uma associação entre entidades que contenha atributos é, por si
só, uma entidade.
Entidade Associativa: É um tipo de entidade que contém atributos que completam a
descrição de um relacionamento de muitos-para-muitos entre duas outras entidades. É
usada para associar duas ou mais entidades como uma forma de definir o relacionamento
de muitos-para-muitos. Entidades desse tipo são geralmente criadas por quem modela os
dados para resolver algumas das regras de negócio necessárias à associação entre duas
entidades distintas.
Entidade Atributiva: É um tipo de entidade que descreve complementarmente uma
ou mais características de uma outra entidade. Por definição, é uma extensão lógica de uma
outra entidade. Normalmente os dados em entidades desse tipo são contados como um tipo
de registro da entidade que descreve.
Entidade Dependente: Uma entidade que não tem significado sem a presença de
outra entidade associada a ela por um relacionamento.
Entidade Independente: Uma entidade que é significativa por si própria, sem a
presença de outra entidade associada a ela por um relacionamento.
Entidade Subtipo: Uma subdivisão de uma entidade. Um subtipo herda todos os
atributos e relacionamentos de sua entidade pai e pode ter atributos e relacionamentos
únicos adicionais.
Entrada Externa: Processo elementar que processa dados ou informações de controle
vindos de fora da fronteira da aplicação. Os dados processados mantêm um ou mais ALI,
enquanto as informações de controle podem ou não manter um ALI. A principal intenção
de uma EE é manter um ou mais ALI e/ou alterar o comportamento do sistema.
Escopo da Contagem: Define a funcionalidade que será incluída em determinada
contagem de pontos de função.
Esforço: Mobilização de forças físicas, intelectuais ou morais, para vencer uma
resistência ou dificuldade, para atingir algum fim.
External Input : Entrada externa.
External Output : Saída externa.
External Interface File : Arquivo de interface externa.
F
Fator de Ajuste: Ou valor do fator de ajuste.
Fator de Crescimento: Indicador que representa o crescimento ou diminuição na
quantidade de pontos de função entre o início e término de uma fase do projeto de
desenvolvimento do sistema.
File Types Referenced : Arquivos referenciados.
FPA: Function Point Analysis.
FP: Function Point.
Fronteira: É a interface conceitual que delimita o software sendo medido e o usuário.
Pode haver mais de uma aplicação incluída no escopo da contagem. Nesse caso, múltiplas
fronteiras da aplicação deverão ser identificadas. Quando a fronteira não está bem definida
(como no início da análise), ela deverá ser posicionada da forma mais exata possível.
FTR: File Types Referenced.
Função: As características ou capacidades de uma aplicação como vistas pelo usuário.
Também chamada de funcionalidade. Unidade que representa as suas práticas e
procedimentos.
Funcionalidade de Conversão: São aquelas funções (do projeto de desenvolvimento
ou de melhoria) fornecidas para conversão de dados e/ou provimento de outros requisitos
específicos da conversão estabelecidos pelo usuário, como relatórios específicos para
conversão.
Funções Tipo Dado: Representam as funcionalidades fornecidas pelo sistema ao
usuário, para atender a suas necessidades de dados. Classificadas em ALI e AIE.
Funções Tipo Transação: Representam as funcionalidades de processamento de
dados fornecidas pelo sistema ao usuário. Classificadas em EE, CE e SE.

G
General System Characteristics : Características Gerais do Sistema.
GSC: General System Characteristics.
Guia de Contagem: É um documento de uso interno a uma organização que orienta as
medições feitas em pontos de função em projetos de software. Sua característica é ter um
enfoque bem específico das situações que uma organização vivencia nas suas contagens de
pontos de função. Seu papel é traduzir os conceitos gerais do manual de práticas de
contagem do IFPUG para as situações específicas de uma organização.
I
Identificável pelo Usuário: Requisitos definidos para processos e/ou grupos de dados
acordados e entendidos por ambos, usuário e desenvolvedor.
IEEE: É uma organização sem fins lucrativos de profissionais interessados no avanço
da tecnologia. Originalmente o seu nome vem do acrônimo de Institute of Electrical and
Electronics Engineers (www.ieee.org), porém o seu escopo de interesse e atuação se
expandiu para muito além da área original.
IFPUG: International Function Point Users Group . É uma entidade sem fins
lucrativos, composta por pessoas e empresas de diversos países, cuja finalidade é promover
um melhor gerenciamento dos processos de desenvolvimento e manutenção de software
através do uso da APF.
ILF: Internal Logical File .
Imagem: Conjunto de registros afins tratados como uma unidade. Uma réplica exata
de um outro objeto, arquivo ou tabela geralmente criada pelo uso de um utilitário. Por
exemplo, um arquivo poderia consistir de um conjunto de registros de faturamento.
Informações de Controle: Dados que influenciam um processo elementar. Comandos
de ação, parâmetros de consulta, enfim, informação que especifica o que, quando, ou como
os dados devem ser processados. Em resumo, parâmetros.
Exemplos:
“O que” - determinado campo especifica que o cálculo da parcela deve contemplar
somente o valor vencido ou o valor corrigido com juros e multa.
“Quando” - uma enquete pode ter um fechamento automático (votações finalizadas)
definido pela data de seu encerramento.
“Como” - durante a compra de uma passagem aérea, o cliente informa em um campo
como deseja receber a confirmação da compra: por e-mail, torpedo (SMS) ou fax.
Internal Logical File: Arquivo lógico interno.
Intenção Primária : Intenção que é a primeira em importância.
ISBSG: International Software Benchmarking Standards Group (www.isbsg.org) é
uma organização sem fins lucrativos responsável por criar e manter um repositório de
dados históricos de projetos de TI com o intuito de ajudar a melhorar a gestão de TI no
mundo.

L
 LOC: Linhas de código-fonte (SLOC (em inglês)) é uma medida de software usada
para medir o tamanho de um programa de software, através da contagem do número de
linhas em texto do código-fonte do programa.
Lógica de Processamento: Qualquer um dos seguintes requisitos solicitados pelo
usuário para completar um processo elementar: realização de validações, realização de
cálculos matemáticos, conversão de equivalência, filtragem e seleção de dados, análise de
condições, atualização de ALIs, referência a ALIs/AIEs, recuperação de dados, criação de
dados derivados, alteração no comportamento do sistema, apresentação de dados além da
fronteira da aplicação, aceitação de dados que entram pela fronteira da aplicação,
ordenação de dados.

M
Manter: O termo manter refere-se à habilidade de incluir, modificar ou excluir dados
a partir de um processo elementar. Exemplos incluem, mas não estão limitados a inclusão,
modificação, exclusão, carga inicial, revisão, atualização, atribuição e criação.
Manual de Práticas de Contagem: Documento editado pelo comitê de práticas de
contagem do IFPUG que tem como objetivos: fornecer uma descrição clara e detalhada de
como contar pontos de função; promover a consistência nas contagens realizadas pelos
membros do IFPUG; fornecer orientação de como realizar contagens de pontos de função
baseadas em artefatos das técnicas e metodologias mais populares de desenvolvimento de
software e prover um entendimento comum que permita o desenvolvimento de ferramentas
que forneçam suporte automático à contagem de pontos de função.
Manutenção: Esforço para manter uma aplicação executando conforme suas
especificações, geralmente sem modificar sua funcionalidade (ou contagem de pontos de
função). Inclui reparo, melhorias menores, conversão, atividade de suporte ao usuário e
manutenção preventiva. Atividades incluem remoção de defeitos (veja reparo), atualização
de hardware ou software (veja conversão), otimização ou melhoria de qualidade (veja
manutenção preventiva) e suporte ao usuário.
Manutenção Adaptativa: Inclui modificações para atender novos requisitos de
negócio, requisitos de negócio em processo de mudança, ou para adicionar funcionalidade
não presente em uma versão anterior. Pode também incluir modificações necessárias ao
atendimento de requisitos técnicos. É iniciada por solicitações de negócio para adicionar,
modificar e/ou excluir funcionalidades de negócio. É sinônimo do conceito de uma
“melhoria” como definido pelo IFPUG.
Manutenção Corretiva: Modificação reativa de um produto de software executada
depois da entrega para corrigir problemas identificados. A modificação corrige os produtos
de software para satisfazer os requisitos. (ISO/IEC 14764:2006)
 Manutenção Perfectiva (ou preventiva): Modificação de um produto de software
depois da entrega para detectar e corrigir falhas latentes no produto de software antes que
ele manifeste essas falhas. Manutenção perfectiva fornece melhorias para usuários,
melhorias de documentação de programas e recodificação para melhorar a performance do
software, manutenibilidade e outros atributos do software. Contrastar com: manutenção
adaptativa e manutenção corretiva. (ISO/IEC 14764:2006).
Medição: Uso de uma métrica para atribuir um valor (o qual pode ser um número ou
categoria), obtido a partir de uma escala, a um atributo de uma entidade [ISO/IEC 9126-1].
Geralmente, no processo de melhoria, medidas obtidas nessa atividade são combinadas
para gerar métricas.
Modelos de Dados: É um subconjunto do modelo de implementação que descreve a
representação lógica e física dos dados persistentes no sistema.

N
NESMA: Netherland Software Metrics Association . Associação de métricas de
software da Holanda. Mantém um manual próprio para a contagem de pontos de função,
com os mesmos conceitos e definições que o manual do IFPUG. Para a contagem de
projetos de desenvolvimento e aplicação, as diferenças são pequenas entre a NESMA e o
IFPUG. Para a contagem de projetos de melhoria, a abordagem das duas organizações é
bem diferente.
Nível de Influência: Peso que cada uma das características gerais do sistema possui
(variando de 0 a 5) na determinação do valor do fator de ajuste da aplicação.
Nível Total de Influência: Somatório dos níveis de influência das 14 características
gerais do sistema.
Normalização: O processo pelo qual qualquer estrutura de dados pode ser
transformada por um projetista de banco de dados em um conjunto de relações
normalizadas que não têm grupos repetidos.

P
PE: Processo Elementar.
PF: Pontos de Função.
Processo Elementar: Menor unidade de atividade significativa para o usuário. Deve
ser completo e deixar o negócio da aplicação sendo contada em estado consistente. Pode
ser classificado em entrada externa, saída externa ou consulta externa.
 Produtividade: Indicador que mede a razão de bens ou serviços produzidos por
unidades de trabalho e custo.
Propósito da Contagem: Fornece uma resposta a um problema do negócio.
Determina o tipo da contagem e seu escopo. Influencia o posicionamento da fronteira da
aplicação.
Protótipo: É um produto que ainda não foi comercializado, mas está em fase de testes
ou de planejamento. Para a engenharia de software, protótipo é um sistema/modelo sem as
funcionalidades inteligentes (acesso a banco de dados, sistemas legados, regras de negócio
etc.), apenas com as funcionalidades gráficas, e algumas funcionalidades básicas para o
funcionamento do próprio protótipo. Utilizado geralmente para obter aprovação de quem
solicita o sistema.

R
Reconhecido pelo Usuário: O termo reconhecido pelo usuário refere-se a requisitos
definidos para processos e/ou grupos de dados que foram acordados e entendidos tanto
pelo(s) usuário(s) quanto pelo(s) desenvolvedor(es) de software. Por exemplo, usuários e
desenvolvedores concordam que uma Aplicação de Recursos Humanos terá funcionalidade
para manter e guardar informações do funcionário na aplicação.
Requisito: Um requisito é algo (ou a especificação de algo) que um produto deve
fazer, ou uma qualidade que deve ter.
Requisito Funcional: Representa as práticas e os procedimentos que o software deve
executar para atender às necessidades do usuário. Ele exclui requisitos de qualidade ou
qualquer requisito técnico.
Requisitos Funcionais Finais: São os requisitos originados de sessões conjuntas entre
usuários e desenvolvedores. São a versão final dos requisitos e apresentam as seguintes
características: linguagem comum aos usuários e desenvolvedores, completos, consistentes,
viáveis e aprovados pelo usuário.
Requisitos Iniciais do Usuário: Representam os requisitos dos usuários antes das
sessões entre os usuários e os desenvolvedores. Eles podem ter as seguintes características:
incompletos, inviáveis de implementar, muito genéricos, expressos na linguagem familiar
ao negócio do usuário.
Requisitos não Funcionais: Os requisitos não funcionais lidam com aspectos não
ligados diretamente ao negócio do usuário ao qual o sistema deve atender. Alguns
requisitos não funcionais estão ligados diretamente à implementação do software. E a APF
independe da implementação. Logo, tudo aquilo num projeto de software que demanda
esforço ou custo e que não é medido diretamente em PFs acaba afetando o preço do PF
(R$/PF).
 Requisitos Técnicos Iniciais: Representam a visão dos desenvolvedores de software
dos requisitos criados a partir do estudo de viabilidade. Um trabalho dos desenvolvedores
de software, dentre outros, é organizar os requisitos dentro das aplicações existentes, se
existirem. Os requisitos técnicos iniciais podem incluir elementos necessários para a
implementação, mas não são utilizados na contagem de pontos de função. Por isso podem
ter as seguintes características: dependência tecnológica, linguagem não familiar ao
usuário, nem sempre aderente às necessidades do usuário.
RET: Record Element Type .
RLR: Registro Lógico Referenciado. Nomenclatura obsoleta para tipo de registro.

S
Saída Externa: É um processo elementar cuja principal intenção é enviar dados ou
informação de controle além da fronteira da aplicação. Sua lógica de proces- samento deve
conter pelo menos uma fórmula matemática ou cálculo ou criar dado derivado. Pode
também manter um ou mais arquivos lógicos internos (ALI) e/ou alterar o comportamento
do sistema.
Scope Creep: Aumento do escopo de um projeto de desenvolvimento de software pelo
acréscimo de funcionalidades não especificadas no documento original de requisitos.
Significativo: Reconhecido pelo usuário e satisfazendo um requisito funcional do
usuário.
Subgrupo Obrigatório: Um dos dois tipos de subgrupos para um tipo de registro
(Registro Lógico Referenciado - RLR - ou Record Element Type - RET). Subgrupo
obrigatório significa que o usuário deve usar um dos subgrupos durante um processo
elementar que crie uma instância dos dados.
Subgrupo Opcional: É aquele que o usuário tem a opção de não usar durante um
processo elementar que inclui ou cria uma instância dos dados.

T
Tamanho Funcional: É a medida das funcionalidades de uma aplicação que o usuário
solicita recebe, tendo como base a visão do usuário.
TD: Tipo de Dado.
Tipo de Contagem: São três os tipos de contagem de pontos de função: projeto de
desenvolvimento, projeto de melhoria e aplicação.
Tipo de Dado: Campo único, reconhecido pelo usuário, não repetido.
 Tipo de Registro: Um tipo de registro elementar é um subgrupo de dados reconhecido
pelo usuário dentro de uma função de dados. Pode ser um subgrupo opcional ou subgrupo
obrigatório. A complexidade funcional de cada arquivo lógico é definida com base no
número de tipos de dado (DET) e tipos de registro (RET) associados a ele.
Total Degree of Influence: Nível total de influência.
TR: Tipo de Registro.
Transactional Function Type : Função do tipo transação.

U
UML: A Unified Modeling Language (UML) é uma linguagem de modelagem aberta
que permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas
padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto
é, semântica. É uma notação independente de processos, embora o RUP ( Rational Unified
Process ) tenha sido especificamente desenvolvido utilizando a UML. A UML não é uma
metodologia de desenvolvimento, o que significa que ela não diz o que fazer primeiro e em
seguida ou como projetar um sistema, mas ela auxilia a visualizar seu desenho e a
comunicação entre objetos.
Usuário: Qualquer pessoa que especifica requisitos funcionais e/ou pessoa ou “coisa”
que interage ou comunica com o sistema a qualquer momento.

V
VAF: Value Adjustment Factor ou valor do fator de ajuste.
Valor do Fator de Ajuste: Indica a funcionalidade geral fornecida pela aplicação ao
usuário. É um valor percentual calculado a partir do nível de influência de cada uma das 14
características gerais do sistema. Pode produzir uma variação de + / - 35% no tamanho do
sistema.
Visão do Usuário: Representa uma descrição formal das necessidades de negócio do
usuário em sua própria linguagem. Desenvolvedores traduzem a informação do usuário em
linguagem de tecnologia da informação para fornecer uma solução.

W
WBS: Work Breakdown Structure .
1 http:// www.pmi.org
2 http://www.sei.cmu.edu
3 http://www.ifpug.org
4 http://www.sqi.gu.edu.au/spice/
5 http://www.tickit.org/
6 http://www.ifpug.org
7 http://www.bfpug.com.br

8 http://br.groups.yahoo.com/group/forum-bfpug
9 http://www.nesma.nl
10 http://www.uksma.co.uk
11 http://www.cosmicon.com
12 http://www.jtc1-sc7.org
13 http://www.isbsg.org
14 4 Na disciplina de Engenharia de Requisitos, deve estar previsto um
mecanismo para validar a necessidade de haver mais de um caso de uso
ou mesmo casos de uso de inclusão ou extensão em situação como a
descrita neste item.