3 - PART 1 - ANALISTA DE SISTEMAS - XINGUARA_-1

Prévia do material em texto

CONCURSO PÚBLICO DA PREFEITURA MUNICIPAL DE 
XINGUARA/PA 2020 
 
 
 
 
 
CONTEÚDO ESPECÍFICO 
 
ANALISTA DE SISTEMAS 
 
PARTE 1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
AVISO IMPORTANTE 
 
 
 
 
 
A CUCA Apostilas não está vinculada as organizadoras de Concurso 
Público. A aquisição do material não garante sua inscrição ou ingresso na 
carreira pública. 
 
 
 
 
Sua Apostila aborda os tópicos do Edital de forma prática e 
Esquematizada. 
 
 
 
 
 
 
 
Dúvidas sobre matérias podem ser enviadas através do ZAP. 
 
 
 
 
PIRATARIA É CRIME: É proibida a reprodução total ou parcial desta 
apostila, de acordo com o Artigo 184 do Código Penal. 
 
 
 
 
 
 
 
 
 
 
Introdução a Engenharia de 
SoftwareSoftware
Prof. Anderson Cavalcanti
UFRN-CT-DCA
O que é Software?
O que é software?
• São programas de computadores, em suas diversas
formas, e a documentação associada.
• Um programa é um conjunto de soluções algorítmicas,
codificadas numa linguagem de programação, executado
numa máquina real.numa máquina real.
• Os produtos de software podem ser desenvolvidos para
um cliente em particular ou para o mercado geral.
– Genérico (COTS – Commercial Off-The Shelf)
– Personalizado – sob encomenda
• Software é um produto conceitual e lógico.
Características
• Invisibilidade
– Software é invisível e invisualizável
• Complexidade
– Software é mais complexo do que qualquer outro– Software é mais complexo do que qualquer outro
produto construídos por seres humanos
• Mutabilidade
– Existe sempre uma pressão para se fazer mudanças
em um software
Características
• Conformidade
– O software deve ser desenvolvido conforme o
ambiente. Não é o ambiente que deve se adaptar ao
software.
Se o software esta conforme os requisitos (o– Se o software esta conforme os requisitos (o
ambiente) todo o suporte operacional deve se adaptar
ao software.
Formas do Software
Mitos do Software
• O estabelecimento de objetivos gerais é suficiente para
se começar a escrever programas.
• Dê a uma pessoa técnica um bom livro de programação e
você terá um programador.
• Mudanças no software podem ser feitas facilmente
porque ele é "flexível".porque ele é "flexível".
• Até que o programa esteja "rodando" não é possível
verificarmos a sua qualidade.
• Uma vez que o programa esteja escrito e funcionando,
nosso trabalho está feito.
• Um projeto é bem sucedido se conseguirmos um
programa funcionando corretamente.
Histórico
• Os primeiros anos (1950 a início dos 60)
– Aplicações científicas e de engenharia
• A segunda era (1960 a meados de 80)
– Aplicações comerciais em grande-porte (sistemas de– Aplicações comerciais em grande-porte (sistemas de
informação BD)
• A terceira era (meados de 70 e década de 80)
– Aplicativos pessoais em microcomputadores
• A quarta era (meados de 80 a meados de 90)
– Aplicativos com Interfaces Gráficas
– Redes e Arquitetura Cliente-Servidor
Histórico
• A quinta era (de meados de 90 a ???)
– Software Distribuídos, Internet, Groupwares e
Intranets
• Sexta era??• Sexta era??
– Computação Pervasiva, Móvel e Ubíqua
Categorias de Tamanho de Softwares
• Win 95: teve 11 milhões de linhas e 200 programadores
• Nestscape: teve 3 milhões de linhas e 120 programadores
Contextualização da Engenharia 
de Softwarede Software
O que é a Engenharia de Software?
• É uma disciplina da engenharia dedicada a todos os 
aspectos da produção de software.
• Engenheiros de software devem adotar uma
abordagem sistemática e organizada para o seu
trabalho e usar técnicas e ferramentas apropriadas,trabalho e usar técnicas e ferramentas apropriadas,
de acordo com o problema a ser resolvido, e com as
restrições e recursos disponíveis.
Engenharia
• Desenvolvimento de um produto;
• Processo de desenvolvimento envolvendo análise,
design, implementação e avaliação;
• Baseado em teoria, princípios, modelos, métodos,• Baseado em teoria, princípios, modelos, métodos,
técnicas e ferramentas;
• Equipe de especialistas;
• Planejamento e gerenciamento de recursos, custos e
prazos.
Objetivos da Engenharia de Software
• Aplicação de teoria, modelos, formalismos, técnicas
e ferramentas da ciência da computação e áreas
afins para o desenvolvimento sistemático de
software.
• Aplicação de métodos, técnicas e ferramentas para o
gerenciamento do processo de desenvolvimento.
• Produção da documentação formal destinada a
comunicação entre os membros da equipe de
desenvolvimento bem como aos usuários.
Definições de Engenharia de Software
• O estabelecimento e uso de princípios de engenharia
para a produção economicamente viável de software de
qualidade que funcione em máquinas reais;
• A engenharia de software é a disciplina envolvida com a
produção e manutenção sistemática de software que sãoprodução e manutenção sistemática de software que são
desenvolvidos com custos e prazos estimados;
• Disciplina que aborda a construção de software
complexo com muitas partes interconectadas e
diferentes versões por uma equipe de analistas,
projetistas, programadores, gerentes, "testadores", etc.
Aspectos históricos
• 1968 Conferência da OTAN, Garmisch
• Objetivo: resolver a “Crise do Software”
• Software é entregue:
– Atrasado– Atrasado
– Com orçamento estourado
– Com falhas residuais
• Custo do hardware decrescente e custo do software
em ascensão.
Qual a diferença entre engenharia de
software e engenharia de sistemas?
• A engenharia de sistemas está interessada em todos
os aspectos de um sistema baseado em computador,
incluindo hardware, software, fatores humanos,
informação e o processo. A engenharia de software é
parte dela.parte dela.
Princípios da Engenharia de Software
• Todo engenheiro de software deve desenvolver com:
– Rigor e Formalidade
– Separação de interesses
– Modularidade– Modularidade
– Abstração
– Antecipação de mudanças
– Generalidade
– Possibilidades de evolução
Processos de Software
Como transformar necessidades em software?
• Principais Atividades Envolvidas:
– Entender as necessidades do cliente;
– Planejar uma solução;
– Implementar e testar a solução;– Implementar e testar a solução;
– Entregar a solução.
• Como essas atividades são executadas?
– De forma desordenada e informal;
– Apenas por uma pessoa.
Processo de Desenvolvimento
• O conjunto de atividades de desenvolvimento, sua
ordem temporal e a atribuição de responsabilidades
(papéis de desenvolvedores) definem um processo
de desenvolvimento de software;
• Um processo de software é a especificação do
processo de transformar necessidades em software;
• Ciclo de Vida de um Processo:
– Determina as fases do processo;
– Define atividades importantes e opcionais para cada
fase.
Modelagem
O que são modelos?
• Modelos descrevem um determinado sistema,
muitas vezes de forma simplificada;
• Modelo de um processo de desenvolvimento:
– É a especificação (documentada) de um processo de– É a especificação (documentada) de um processo de
desenvolvimento de software que servirá de
parâmetro para uso/especificação de um processo
para uma equipe/projeto.
Modelos de Software
• Na construção de sistemas de software, assim como
na construção de sistemas habitacionais, também há
uma gradação de complexidade:
– A construção desses sistemas necessita
de um planejamento inicial
Modelos de Software
• Um modelo pode ser visto como uma representação
idealizada de um sistema que se planeja construir;
• Maquetes de edifícios e de aviões e plantas de
circuitos eletrônicos são apenas alguns exemplos de
modelos.
Razão para a Construção de Modelos
• Em princípio, podemos ver a construção de modelos
como uma atividade que atrasa o desenvolvimento do
software propriamente dito;
• Mas essa atividade propicia...
– O gerenciamento da complexidade inerente ao– O gerenciamento da complexidade inerente ao
desenvolvimento de software.
– A comunicação entre as pessoas envolvidas.
– A redução dos custos no desenvolvimento.
– A predição do comportamentofuturo do sistema.
• Entretanto, note o fator complexidade como
condicionante dessas vantagens.
Diagramas e Documentação
• No contexto de desenvolvimento de software,
correspondem a desenhos gráficos que seguem
algum padrão lógico.
• Podemos também dizer que um diagrama é uma
apresentação de uma coleção de elementos gráficosapresentação de uma coleção de elementos gráficos
que possuem um significado predefinido.
• Diagramas normalmente são construídos de acordo
com regras de notação bem definidas.
– Ou seja, cada forma gráfica utilizada em um diagrama
de modelagem tem um significado específico.
Diagramas e Documentação
• Diagramas permitem a construção de uma
representação concisa de um sistema a ser
construído.
– “uma figura vale por mil palavras”
No entanto, modelos também são compostos de informações textuais
Diagramas e Documentação
• Dado um modelo de uma das perspectivas de um
sistema, diz-se que o seu diagrama, juntamente com
a informação textual associada, formam a
documentação deste modelo.
Modelagem de Software
A modelagem de sistemas de software consiste
na utilização de notações gráficas
e textuais com o objetivo de construir modelos
que representam as partes essenciais de umque representam as partes essenciais de um
sistema, considerando-se diversas perspectivas
diferentes e complementares.
Paradigmas
Paradigma?
• Um paradigma é uma forma de abordar um
problema;
• No contexto da modelagem de um sistema de
software, um paradigma tem a ver com a forma pela
qual esse sistema é entendido, projetado e
construído.
Paradigma?
• A primeira abordagem usada para modelagem de
sistemas de software foi o paradigma estruturado.
Paradigma da Orientação a Objetos
• Hoje em dia, praticamente suplantou o paradigma
anterior, o paradigma da orientação a objetos...
• O paradigma da OO surgiu no fim dos anos 60.
• Alan Kay, um dos pais desse paradigma, formulou a• Alan Kay, um dos pais desse paradigma, formulou a
chamada analogia biológica.
• “Como seria um sistema de software que funcionasse
como um ser vivo?”
Analogia Biológica
• Uma “célula” interage com outras células enviando 
mensagens para realizar um objetivo comum;
• Adicionalmente, cada célula se comportaria como 
uma unidade autônoma;
• De uma forma mais geral, Kay pensou em como
construir um sistema de software a partir de agentes
autônomos que interagem entre si.
Fundamentos da OO
• Através de sua analogia biológica, Alan Kay definiu os 
fundamentos da orientação a objetos
– Qualquer coisa é um objeto;
– Objetos realizam tarefas através da requisição de–
serviços a outros objetos;
– Cada objeto pertence a uma determinada classe. Uma
classe agrupa objetos similares;
– A classe é um repositório para comportamento
associado ao objeto;
– Classes são organizadas em hierarquias.
Sistema de Software OO: uma analogia
Resumindo
• O paradigma da orientação a objetos visualiza um
sistema de software como uma coleção de agentes
interconectados chamados objetos.
• Cada objeto é responsável por realizar tarefas
específicas. É através da interação entre objetos que umaespecíficas. É através da interação entre objetos que uma
tarefa complexa é realizada.
• Um sistema de software orientado a objetos consiste de
objetos em colaboração com o objetivo de realizar as
funcionalidades deste sistema. Cada objeto é responsável
por tarefas específicas. É através da cooperação entre
objetos que a computação do sistema se desenvolve.
Conceitos e Princípios de OO
• Conceitos:
– Classe
– Objeto
– Mensagem– Mensagem
• Princípios:
– Encapsulamento
– Polimorfismo
– Generalização (herança)
– Composição
Classes, Objetos e Mensagens
• O mundo real é formado de coisas;
• Na terminologia de orientação a objetos, estas coisas
do mundo real são denominadas objetos;
• Seres humanos costumam agrupar os objetos para• Seres humanos costumam agrupar os objetos para
entendê-los;
• A descrição de um grupo de objetos é denominada
classe de objetos, ou simplesmente de classe.
O que é uma Classe?
• Uma classe é um molde para objetos. Diz-se que um
objeto é uma instância de uma classe;
• Uma classe é uma abstração das características
relevantes de um grupo de coisas do mundo real
– Na maioria das vezes, um grupo de objetos do mundo
real é muito complexo para que todas as suas
características e comportamento sejam representados
em uma classe
Como detectar propriedades relevantes?
• Uma abstração é qualquer modelo que inclui os
aspectos relevantes de alguma coisa, ao mesmo
tempo em que ignora os menos importantes.
• Abstração depende do observador.
Abstração em OO
• A orientação a objetos faz uso intenso de abstrações
– Os princípios da OO podem ser vistos como aplicações 
da abstração
• Princípios da OO: encapsulamento, polimorfismo, • Princípios da OO: encapsulamento, polimorfismo, 
herança e composição
Objetos como Abstrações
• Uma abstração é uma representação das características e
do comportamento relevantes de um conceito do mundo
real para um determinado problema.
• Dependendo do contexto, um mesmo conceito do
mundo real pode ser representado por diferentesmundo real pode ser representado por diferentes
abstrações:
– Carro (para uma transportadora de cargas)
– Carro (para uma fábrica de automóveis)
– Carro (para um colecionador)
– Carro (para uma empresa de kart)
– Carro (para um mecânico)
Mensagens
• Para que um objeto realize alguma tarefa, deve haver
um estímulo enviado a este objeto.
• Pense em um objeto como uma entidade ativa que
representa uma abstração de algo do mundo real
– Então faz sentido dizer que tal objeto pode responder
a estímulos a ele enviados
– Assim como faz sentido dizer que seres vivos reagem a
estímulos que eles recebem.
Mensagens
• Independentemente da origem do estímulo, quando
ele ocorre, diz-se que o objeto em questão está
recebendo uma mensagem
• Uma mensagem é uma requisição enviada de um
objeto a outro para que este último realize alguma
operação
Encapsulamento
• Objetos possuem comportamento.
– O termo comportamento diz respeito a que operações
são realizadas por um objeto e também de que modo
estas operações são executadas.
Encapsulamento
• De acordo com o encapsulamento, objetos devem
“esconder” a sua complexidade...
• Esse princípio aumenta qualidade do SSOO, em
termos de:
– Legibilidade
– Clareza
– Reuso
Encapsulamento
• O encapsulamento é uma forma de restringir o
acesso ao comportamento interno de um objeto
– Um objeto que precise da colaboração de outro para
realizar alguma tarefa simplesmente envia uma
mensagem a este último;mensagem a este último;
– O método (maneira de fazer) que o objeto requisitado
usa para realizar a tarefa não é conhecido dos objetos
requisitantes.
• Na terminologia da orientação a objetos, diz-se que
um objeto possui uma interface
– A interface de um objeto é o que ele conhece e o que
ele sabe fazer, sem descrever como o objeto conhece
ou fazou faz
– A interface de um objeto define os serviços que ele
pode realizar e conseqüentemente as mensagens que
ele recebe
Encapsulamento
• Uma interface pode ter várias formas de
implementação;
• Mas, pelo princípio do encapsulamento, a
implementação utilizada por um objeto receptor de
uma mensagem não importa para um objeto
remetente da mesma.
Polimorfismo
Objeto 
Receptor
Objeto 
Receptor
Objeto Remetente (Jogo de 
Futebol?)
É a habilidade de objetos de classes
diferentes responderem a mesma mensagem
de diferentes maneiras.
Generalização (Herança)
• A herança pode ser vista como um nível de abstração
acima da encontrada entre classes e objetos;
• Na herança, classes semelhantes são agrupadas em
hierarquias:
– Cada nível de uma hierarquia pode ser visto como um
nível de abstração
– Cada classe em um nível da hierarquia herda as
características das classes nos níveis acima
Herança
• A herança facilita o compartilhamento de
comportamento entre classes semelhantes;
• As diferenças ou variações de uma classe em
particularpodem ser organizadas de forma mais
clara;
Entendido o Paradigma, como criar 
modelos?
• O rápido crescimento da capacidade computacional
das máquinas (lei de moore) resultou na demanda
por sistemas de software cada vez mais complexos;
• O surgimento de sistemas de software mais
complexos resultou na necessidade de reavaliação dacomplexos resultou na necessidade de reavaliação da
forma de desenvolver sistemas;
• Conseqüentemente as técnicas utilizadas para a
construção de sistemas computacionais têm evoluído
de forma impressionante, notavelmente no que
tange à modelagem de sistemas.
Entendido o Paradigma, como criar 
modelos?
• Na primeira metade da década de 90 surgiram várias 
propostas de técnicas para modelagem de sistemas 
segundo o paradigma orientado a objetos
• Houve uma grande proliferação de propostas para 
modelagem orientada a objetos
– diferentes notações gráficas para modelar uma
mesma perspectiva de um sistema;
– cada técnica tinha seus pontos fortes e fracos.
Entendido o Paradigma, como criar 
modelos?
• Percebeu-se a necessidade de um padrão para a
modelagem de sistemas, que fosse aceito e utilizado
amplamente;
• Alguns esforços nesse sentido de padronização, o
principal liderado pelo “três amigos”;
• Surge a UML (Unified Modeling Language) em 1996
como a melhor candidata para ser linguagem
“unificadora”.
UML
UML (Linguagem de Modelagem Unificada)
• “A UML é a linguagem padrão para visualizar,
especificar, construir e documentar os artefatos de
software de um sistema.”
• Unificação de diversas notações anteriores
• Mentores: Booch, Rumbaugh e Jacobson
– “Três Amigos”
– IBM Rational (www.rational.com)
UML (Linguagem de Modelagem Unificada)
• UML é...
– uma linguagem visual
– independente de linguagem de programação.
– independente de processo de desenvolvimento– independente de processo de desenvolvimento
• UML não é...
– uma linguagem programação (mas possui versões!)
– uma técnica de modelagem
Diagramas da UML
• Um diagrama na UML é uma apresentação de uma
coleção de elementos gráficos que possuem um
significado predefinido
– No contexto de desenvolvimento de software,
correspondem a desenhos gráficos que seguem algumcorrespondem a desenhos gráficos que seguem algum
padrão lógico
Diagramas da UML
• Um processo de desenvolvimento que utilize a UML
como linguagem de modelagem envolve a criação de
diversos documentos:
– Estes documentos, denominados artefatos de
software, podem ser textuais ou gráficossoftware, podem ser textuais ou gráficos
• Os artefatos gráficos produzidos no desenvolvimento
de um SSOO são definidos através dos diagramas da
UML.
Referências
• JACOBSON, I.; BOOCH, G. and RUMBAUGH, J. The
Unified Software Development Process. Readding,
MA.: Addison-Wesley, 1999,
• LARMAN, C. Utilizando UML e Padrões: uma
introdução á análise e ao projeto orientados a
objetos e ao Processo Unificado. 2a edição - Porto
Alegre: Bookman, 2004.
• ALLEIXO, F. Notas de aula da disciplina de Análise e
Projeto Orientado a Objeto, CEFET/RN, 2007.
• LEITE, J.C. Notas de aula da disciplina de Engenharia
de Software, UFRN, 2006.
DEPARTAMENTO DE INFORMÁTICA - DPI 
 
 
 
 
 
Guia Prático em Análise 
de Ponto de Função 
 
 
Projeto: Jhoney da Silva Lopes 
Orientador: José Luis Braga 
 
 
 
 
 
 
 
 
2 
 
 
Sumário 
1. INTRODUÇÃO ................................................................................................................ 3 
1.1 Análise de Ponto de Função ................................................................................... 3 
1.2 Objetivo .................................................................................................................. 3 
1.3 Motivação e Benefícios .......................................................................................... 4 
1.4 Pontos chave .......................................................................................................... 4 
2. COMO REALIZAR A CONTAGEM DE PONTO DE FUNÇÃO ............................................. 6 
2.1 Visão geral .............................................................................................................. 6 
2.1.1 Requisitos ........................................................................................................ 6 
2.2 Determinar o tipo de contagem ............................................................................. 7 
2.2.1 Projeto de desenvolvimento ........................................................................... 7 
2.2.2 Projeto de melhoria ......................................................................................... 7 
2.2.3 Aplicação .......................................................................................................... 8 
2.2.4 Aplicando o conhecimento .............................................................................. 8 
2.3 Identificar o escopo da contagem .......................................................................... 8 
2.3.1 Aplicando o conhecimento .............................................................................. 9 
2.4 Contar funções do tipo dado .................................................................................. 9 
2.4.1 Arquivo Lógico Interno .................................................................................. 10 
2.4.2 Arquivo de Interface Externa......................................................................... 10 
2.4.3 Determinação da complexidade e da contribuição ...................................... 10 
2.4.4 Aplicando o conhecimento ............................................................................ 12 
2.5 Contar funções do tipo transação ........................................................................ 15 
2.5.1 Entrada Externa ............................................................................................. 15 
2.5.2 Saída Externa ................................................................................................. 16 
2.5.3 Consulta Externa ............................................................................................ 16 
2.5.4 Determinação da complexidade e da contribuição ...................................... 16 
2.5.5 Aplicando o conhecimento ............................................................................ 18 
2.6 Pontos de função não ajustados .......................................................................... 22 
2.6.1 Aplicando o conhecimento ............................................................................ 23 
2.7 Determinar o fator de ajuste ................................................................................ 23 
2.7.1 Aplicando o conhecimento ............................................................................ 24 
2.8 Realizar o cálculo dos pontos de função ajustados .............................................. 24 
2.8.1 Aplicando o conhecimento ............................................................................ 25 
3. DERIVAÇÕES ............................................................................................................... 26 
3.1 Esforço .................................................................................................................. 26 
3.1.1 Aplicando o conhecimento ............................................................................ 27 
3.2 Custo ..................................................................................................................... 27 
3.2.1 Aplicando o conhecimento ............................................................................ 27 
3.3 Prazo ..................................................................................................................... 27 
3.3.1 Aplicando o conhecimento ............................................................................ 28 
4. CONSIDERAÇÕES.........................................................................................................29 
5. BIBLIOGRAFIA ............................................................................................................. 30 
 
1
. I
N
TR
O
D
U
Ç
Ã
O
 
3 
 
1. INTRODUÇÃO 
 A elaboração desse guia visa auxiliar micro e pequenas empresas na utilização 
de uma técnica para estimar os seus projetos em custo, prazo e esforço. Muitas 
empresas não utilizam de técnicas para estimar os seus projetos, a maioria possui um 
funcionário com experiência que avalia os projetos a partir do seu “feeling” sem 
utilizar nenhum padrão. 
Na fase inicial de um projeto a necessidade em obter o custo, prazo e o esforço 
é observado em todas as empresas, pois as mesmas precisam gerar um orçamento 
para os seus clientes e avaliar uma série de projeções. Este guia organiza de forma 
simples e introdutória conhecimentos sobre a análise de ponto de função. 
 O guia não tem a intenção de substituir o uso apropriado e completo da 
contagem de ponto função, mas mostrar que existem ferramentas usuais que 
solucionam problemas recorrentes de várias empresas. 
1.1 Análise de Ponto de Função 
 Análise de Ponto de Função é uma técnica de medição do tamanho funcional 
de um software. Essas funções são operações extraídas dos requisitos funcionais 
gerados a partir da visão do usuário1. A partir dessa medição é possível estimar o 
esforço para implementação do sistema utilizando Ponto de Função que é a unidade 
de medida desta técnica. 
APF tem por definição medir o que o software faz, e não como ele foi 
construído, portanto o processo de medição é fundamentado em uma avaliação 
padronizada dos requisitos lógicos do usuário. 
Sobre o estudo desse método é importante destacar que pontos de função não 
medem diretamente o esforço, produtividade, custo ou outras informações 
específicas. É exclusivamente uma medida de tamanho funcional de software que 
aliado a estimação de outras variáveis, poderá ser usado para derivar produtividade, 
custo e estimar esforço. 
Essa técnica surgiu no início da década de 70 na IBM, desenvolvida por Allan 
Albrecht (Vazquez,2009), como uma alternativa às métricas baseadas em linhas de 
código. O 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 com o uso de pontos de função e outros métodos 
(www.ifpug.org). 
1.2 Objetivo 
 Muitas micro e pequenas empresas passam pela dificuldade de orçar prazo, 
custo e esforço para os seus projetos. A elaboração desse guia não tem por objetivo 
tratar de todas as possíveis variações no processo de contagem, mas sim proporcionar 
uma visão geral sobre a metodologia e com isso auxiliar em uma aproximação do valor 
real da contagem, ou seja, uma estimativa desse valor. 
 O objetivo desse guia é auxiliar na estimativa em pontos de função na fase 
inicial do ciclo de vida de um projeto de desenvolvimento. Na fase inicial, você possui 
apenas a proposta para o projeto, por este motivo não é possível medir o tamanho 
 
1
 Em APF usuário possui um conceito mais amplo. Qualquer entidade que se relacione com o sistema ou 
produza um ônus ao mesmo. Ex: Pessoa, aplicação, leis, restrições e etc. 
http://www.ifpug.org/
 
1
. I
N
TR
O
D
U
Ç
Ã
O
 
4 
 
funcional do software, pois os requisitos não estão maduros, mas é possível realizar 
uma estimativa em pontos de função para o mesmo. 
 Essa abordagem simples e direta tem por finalidade também difundir o uso da 
técnica de análise de ponto de função, realizando uma visão geral com o intuito de 
instigar os seus utilizadores a estudos mais aprofundados sobre a metodologia. Não é 
objetivo deste guia ofender nenhuma organização ou profissional certificado e 
experiente na utilização da metodologia nem tão pouco limitar o estudo e utilização da 
mesma. 
1.3 Motivação e Benefícios 
 É necessário saber qual é a sua verdadeira motivação para a utilização da 
técnica de análise de ponto de função. O que ganhamos medindo um software? Pense 
em um terreno, esse possui uma área, você o mediria para poder vender, comprar, 
construir. Fica fácil perceber motivos pelos quais você mediria um terreno, certo? 
 Você compraria um terreno sem saber o seu tamanho? Com softwares deveria 
ser a mesma situação. 
Em uma obra você precisa saber a área a ser construída para poder comprar os 
materiais, contratar pessoas e com isso também avaliar o tempo de elaboração da 
mesma. Quando medimos softwares utilizando a técnica de análise de ponto de 
função, podemos realizar as mesmas derivações a partir do seu tamanho funcional, ou 
seja, estimar o esforço, custo e prazo. 
Com isso é possível observar uma série de benefícios enumerados por 
(VAZQUEZ,2009): 
1. Controlar o andamento da produtividade de um determinado 
software. Um sistema pode ter mais de uma equipe envolvida em 
seu desenvolvimento, é possível avaliar a produtividade de 
diferentes equipes pela quantidade de Pontos de Função 
entregados. 
2. Realizar a medição do tamanho funcional do software e com isso 
estimar, custo, esforço e prazo. Uma vez realizada a medição ou 
estimativa dos Pontos de Função totais do sistema é possível utilizar 
este número para realizar derivações. 
3. Sabendo o tamanho funcional de um software é possível realizar 
comparações. Pode ser realizada uma avaliação entre dois ou mais 
sistemas. 
4. Com a utilização da técnica é possível tomar decisões do tipo “Make 
or Buy”, seria a decisão de desenvolver um sistema ou comprar uma 
solução pronta no mercado. 
5. Utilizar a medida para fundamentar contratos de compra e venda de 
softwares ou contratar serviços. 
1.4 Pontos chave 
1. Análise de Ponto de função é uma técnica que mede o tamanho funcional de 
um software do ponto de vista do usuário; 
2. IFPUG - International Function Point Users Group é o órgão internacional 
responsável pela manutenção e evolução da técnica; 
 
1
. I
N
TR
O
D
U
Ç
Ã
O
 
5 
 
3. Medir ou estimar? Para a utilização da técnica de APF com o intuito de 
medição, é necessário que os requisitos do sistema estejam maduros. Logo a 
efetividade de uma medida só é possível após a instalação da aplicação; 
4. Análise de ponto de função não leva em consideração como o software é 
construído, mas sim o que ele faz. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
6 
 
2. COMO REALIZAR A CONTAGEM DE PONTO DE FUNÇÃO 
2.1 Visão geral 
 Este capítulo apresentará uma visão geral sobre todos os passos necessários 
para utilização da técnica de análise de ponto de função, para a realização de 
estimativas na fase inicial de um projeto de desenvolvimento, proporcionando ao 
leitor uma visão restrita da técnica, mas suficiente para estimar um projeto em sua 
fase inicial e com isso realizar derivações de acordo com a necessidade do usuário. 
 A análise em ponto de função fundamenta-se em seis passos: 
1. Determinar o tipo de contagem 
2. Identificar o escopo da contagem e a fronteira da aplicação 
3. Contar funções: 
a. Tipo dados 
b. Tipo transação 
4. Determinar a contagem de pontos de função não ajustados 
5. Determinar o valor do fator de ajuste 
6. Calcular o número dos pontos de função ajustados 
 
 
Figura 2.1: Passos para a contagem dos pontos de função 
2.1.1 Requisitos 
 São as necessidades e características que o sistema deve ter para atingir as 
expectativas do cliente. A extração dos requisitos consiste em uma parte crítica na 
elaboração de uma proposta, ela está ligada diretamente ao sucesso ou ao fracasso de 
um projeto. 
 Na aplicação da análise de ponto de função a definição destes requisitos é tão 
importante quanto para qualquer outro fim, pois você pode subestimar ou 
superestimar sua contagem e com isso afetar todas as derivações possíveis da técnica.Claro que é impossível extrair todos estes requisitos nesta fase inicial, logo uma 
melhor extração irá gerar uma melhor estimativa. 
 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
7 
 
2.2 Determinar o tipo de contagem 
O primeiro passo para a contagem: 
 
 
Figura 2.2: Determinar o tipo de contagem 
 
 Na análise de ponto de função existem três tipos de contagem: 
1. Projeto de desenvolvimento; 
2. Projeto de melhoria; 
3. Aplicação. 
O guia tem por objetivo apresentar a solução de contagem para projeto de 
desenvolvimento, mas os outros tipos também serão apresentados. 
2.2.1 Projeto de desenvolvimento 
 É caracterizado como projeto de desenvolvimento, um novo projeto desde a 
fase de extração de requisitos até a instalação do mesmo. 
 Neste tipo de projeto é contado na análise de ponto de função todas as 
funcionalidades fornecidas aos usuários até a instalação do sistema, ou seja, 
funcionalidades de conversão também são contadas. Por exemplo: Um sistema A 
possui uma lista de funcionários cadastrados, o sistema B sendo contado deverá incluir 
todos esses funcionários em sua base de dados, essa funcionalidade será disparada 
uma única vez que é durante a instalação do sistema, sendo caracterizada como 
função de conversão. 
 Nós só conseguimos todos os requisitos de um sistema após o término do 
projeto, sendo assim toda a contagem de um projeto de desenvolvimento pode ser 
entendida como estimativa e não medição. 
2.2.2 Projeto de melhoria 
 O projeto de melhoria mede todas as funcionalidades novas, modificadas e 
excluídas de um determinado sistema. Ao término de um projeto de melhoria a 
aplicação deverá ser contada com o intuito de atualizar o valor em pontos de função 
da mesma. 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
8 
 
2.2.3 Aplicação 
 Entende-se por contagem do tipo aplicação2 um software instalado, ou seja, a 
contagem após o término de um projeto de desenvolvimento. Neste caso não levamos 
em consideração as funções do tipo conversão. 
2.2.4 Aplicando o conhecimento 
 Esta etapa está pronta, o foco deste guia são as derivações dos pontos de 
função para auxiliar na elaboração da proposta do projeto para o cliente. A sua 
contagem será de um projeto de desenvolvimento. 
 Exemplo de caso: Tipo de contagem - Projeto de desenvolvimento. 
2.3 Identificar o escopo da contagem 
 O segundo passo para a contagem: 
 
 
Figura 2.3: Identificar o escopo da contagem e a fronteira da aplicação 
 
Muitas vezes a identificação do escopo e da fronteira da aplicação não são 
levados tão a sério, principalmente por empresas que não utilizam de gerência de 
projetos. 
Esta é uma etapa crucial para o andamento do projeto, a definição de um 
escopo3 errado pode acarretar em prejuízos incalculáveis para o projeto ou até a perda 
total dele, o escopo define quais funções serão incluídas na contagem, ele pode 
abranger todas as funcionalidades, apenas as utilizadas ou específicas. 
A fronteira da aplicação a ser contada seria a linha que separa uma aplicação de 
outra, dentro de um escopo de contagem podem existir mais de uma aplicação a ser 
contada, por isso é importante definir qual é a sua fronteira. 
 Uma tarefa simples para não errar nesta etapa, é seguir a regra do IFPUG que é 
determinar a fronteira da aplicação baseado no Ponto de Vista do Usuário. O usuário 
define o que ele entende sobre as atribuições do sistema e de cada aplicação. 
 
2
 Aplicação neste caso pode ser interpretada como sistema. 
3
 Escopo do projeto é o trabalho que precisa ser realizado para entregar um produto, serviço ou 
resultado com as características e funções especificadas (PMBOK, 2004), o escopo da contagem é tudo 
aquilo que deve ser contado. 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
9 
 
Exemplo: Neste caso são apresentadas três aplicações, AP01, AP02 e AP03, 
cada uma com arquivo lógico interno – ALI e referenciando arquivos de interface 
externa – AIE, serão apresentados detalhes sobre os arquivos lógicos no próximo 
tópico. 
 
 
Figura 2.4: Arquivos lógicos e fronteiras das aplicações 
2.3.1 Aplicando o conhecimento 
 Como foi visto, nesta etapa devemos definir o escopo da contagem e a 
fronteira da aplicação. 
 Exemplo de caso: Software destinado a uma empresa que realiza locação de 
automóveis, o sistema é simples e composto por uma única aplicação. 
2.4 Contar funções do tipo dado 
 O terceiro passo primeira parte: 
 
 
Figura 2.5: Contar funções do tipo dados 
 
 Nesta etapa iniciamos o processo de contagem, as funções do tipo dado são as 
funcionalidades fornecidas para o armazenamento de dados na aplicação sendo 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
1
0 
 
contada, são caracterizados como arquivos lógicos e eles podem ser mantidos pela 
aplicação ou lida de outra, como no exemplo da (figura 2.4). 
 Arquivos lógicos que estão dentro da fronteira da aplicação e mantidos pela 
mesma são chamados de Arquivos Lógicos Internos (ALI), já os arquivos lógicos lidos de 
outra aplicação são chamados de Arquivos de Interface Externa (AIE). 
2.4.1 Arquivo Lógico Interno 
 Grupo lógico de dados e persistentes mantidos dentro da fronteira da aplicação 
e alterado por meio de processos elementares4. 
Considere a (figura 2.4), a AP01 possui três arquivos lógicos internos (ALI), a 
primeira vista parecerá que cada tabela do banco de dados da sua aplicação será um 
ALI, mas é um erro realizar essa premissa, pois um grupo de tabelas pode ser 
considerado como um único arquivo lógico. 
 Exemplos: 
1. Arquivo de configuração, conexão, segurança (senhas) mantidos pela 
aplicação. 
2. Tabelas ou grupos de tabelas do banco de dados mantidas pela 
aplicação. 
Não são exemplos: 
1. Arquivos temporários ou de backup. 
2. Tabelas temporárias ou views. 
2.4.2 Arquivo de Interface Externa 
 Grupo lógico de dados e persistentes mantidos dentro da fronteira de outra 
aplicação, mas requerido ou referenciado pela aplicação que está sendo contada. 
 Considere a (figura 2.4), a AP01 referencia arquivos lógicos da AP02 e AP03, 
estes arquivos são denominados arquivos de interface externa (AIE). 
 Exemplos: 
1. Dados de segurança armazenados em arquivos lógicos e mantidos por 
aplicações específicas a este fim. 
2. Dados salariais armazenados na aplicação financeira, mas utilizados pela 
aplicação contada. 
Não são exemplos: 
1. Dados armazenados na aplicação sendo contada e utilizados por uma 
aplicação externa. Neste caso a sua aplicação possui um ALI e outra 
aplicação reconhece estes dados vindos de um AIE. 
2.4.3 Determinação da complexidade e da contribuição 
 Complexidade é o grau de influência que um arquivo lógico tem para o 
tamanho funcional do sistema. 
 A contribuição é a conversão do grau de complexidade em pontos de função. 
 Essa complexidade é calculada a partir da contagem dos tipos de dados e dos 
tipos de registro. 
 Tipos de dados (TD): 
 É um campo não recursivo de dado, único e reconhecido pelo usuário, 
em uma visão geral e limitada, seria cada atributo de uma tabela. 
 
4
 Um processo elementar é a menor unidade de atividade significativa para o usuário final 
(VAZQUEZ,2009). É a menor funcionalidade disponibilizada ao usuário. 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
1
1 
 
 Tipos de Registro (TR): 
 É um subgrupo de dados. 
Em uma análise míope, quando um agrupamento de tabelas são 
caracterizadas como um único arquivo lógico, ALI ou AIE, a tabela reconhecida 
pelo usuário é contada e as demais se tornam tipos de registro. Os campos de 
dados dos tipos de registro são atribuídos a todos os arquivos lógicos 
relacionados a estes tipos de registro. 
Exemplo: 
 
 
Figura2.6: Especialização é um tipo de registro 
 
Neste exemplo contamos funcionários como uma ALI ou AIE e incluímos 
as demais tabelas como tipo de registro e os seus tipos de dados são somados a 
Funcionários. 
Exemplo: 
 
 
Figura 2.7: Especialização na visão do usuário 
 
 Temos a seguinte definição: 
 
Descrição Tipo TD TR 
Funcionários ALI ou AIE 4 3 
Tabela 2.1: Descrição do Tipo de Registro (TR) e Tipo de Dado (TD) 
 
São contados três tipos de registro, pois todo arquivo lógico é um tipo 
de registro dele mesmo. 
É importante perceber que essa solução é tomada, uma vez que o 
usuário enxerga auxiliar e dentista como funcionário e não entidades 
separadas, ou seja, o importante é a visão do negócio. 
 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
1
2 
 
 
Figura 2.7: Visão do Negócio 
 
 Tabela de complexidade: 
 A tabela de complexidade é padronizada pelo IFPUG, todos os usuários 
da técnica de análise de pontos de função utilizam os mesmos valores. 
 
Ti
p
o
s 
d
e 
R
eg
is
tr
o
 
 Tipos de Dados 
< 20 20 – 50 > 50 
1 Baixa Baixa Média 
2 – 5 Baixa Média Alta 
> 5 Média Alta Alta 
Tabela 2.2: Complexidade ALI e AIE 
 
 Tabela de contribuição: 
A tabela de contribuição é padronizada pelo IFPUG, todos os usuários da 
técnica de análise de pontos de função utilizam os mesmos valores. 
Após identificar a complexidade de cada ALI e AIE do seu sistema, é 
possível determinar a contribuição desses para a contagem dos pontos de 
função. 
 
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 
Tabela 2.3: Tabela de contribuição 
2.4.4 Aplicando o conhecimento 
 Para facilitar a identificação dos tipos de arquivos, deve-se elaborar um modelo 
lógico. 
Uma dica geral e objetiva, mas passível de erro, é contar um arquivo lógico ALI 
ou AIE para cada tabela reconhecida pelo usuário, ou seja, se a tabela existe no ponto 
de vista do usuário ela deve ser contada, caso contrário não. Se o usuário não 
reconhece a tabela, mas reconhece os tipos de dados presentes na mesma, 
provavelmente essa tabela será um tipo de registro. 
Dica para classificar um arquivo lógico: 
 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
1
3 
 
 
Figura 2.8: Fluxo para classificação do tipo lógico 
 
Passos para uma estimativa da contagem desta etapa: 
1. Elabore um modelo lógico do seu projeto 
Exemplo: 
 
 
 Figura 2.9: Modelo lógico 
 
2. Identifique todas as tabelas reconhecidas pelo usuário, ou seja, as que 
fazem parte da visão do negócio e classifique-as como ALI ou AIE. 
Exemplo: 
 
Descrição Tipo 
Usuário ALI 
Cliente ALI 
Carro ALI 
Tabela 2.4: Classificação dos arquivos lógicos 
 
Todas as tabelas foram caracterizadas como arquivo lógico 
interno, pois elas são mantidas pelo sistema sendo contado. 
3. Faça uma análise da todas as tabelas que não estão na visão do negócio: 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
1
4 
 
a. Se a tabela não pertence à visão do negócio, mas os seus tipos 
de dados pertencem, conte-a como um tipo de registro para 
cada arquivo lógico relacionado a ela e atribua os seus tipos de 
dados a cada um deles. 
b. Se nem a tabela nem os seus tipos de dados pertencem à visão 
do negócio, descarte-a da contagem. 
Exemplo: 
Aluga foi considerada um tipo de registro, pois na visão do 
negócio os campos hora_aluguel e data_aluguel, são reconhecidos pelo 
usuário e por este motivo eles foram somados aos tipos de dados de 
Cliente e Carro. 
 
Descrição Tipo TD TR 
Usuário ALI 4 1 
Cliente ALI 7 2 
Carro ALI 8 2 
Tabela 2.5: Tipo de Dado (TD) e Tipo de Registro (TR) 
 
4. Determine a complexidade de cada arquivo lógico. 
Exemplo: 
 Para definir a complexidade basta analisar a quantidade de tipos 
de dados mais os tipos de registro e conferir (tabela 2.2): 
 
Descrição Tipo TD TR Complexidade 
Usuário ALI 4 1 Baixa 
Cliente ALI 7 2 Baixa 
Carro ALI 8 2 Baixa 
Tabela 2.6: Complexidade 
 
5. Determine a contribuição de cada arquivo lógico. 
Exemplo: 
 Para determinar a contribuição basta verificar na (tabela 2.3) o 
ponto de função referente a cada complexidade. 
 
Descrição Tipo TD TR Complexidade Contribuição 
Usuário ALI 4 1 Baixa 7 
Cliente ALI 7 2 Baixa 7 
Carro ALI 8 2 Baixa 7 
Tabela 2.7: Contribuição 
 
6. Realize a soma de todas as contribuições. 
Exemplo: 
 Para finalizar a contagem das funções do tipo dados, some as 
contribuições de todos os arquivos lógicos: 
 
Descrição Tipo TD TR Complexidade Contribuição 
Usuário ALI 4 1 Baixa 7 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
1
5 
 
Cliente ALI 7 2 Baixa 7 
Carro ALI 8 2 Baixa 7 
Total de Pontos de Função = 21 
Tabela 2.8: Contagem das funções do tipo dados 
2.5 Contar funções do tipo transação 
 Terceiro passo segunda parte: 
 
Figura 2.10: Contar funções do tipo transação 
 
 Agora que aprendemos a contar funções do tipo dados, podemos dar 
continuidade a contagem da aplicação. As funções do tipo transação são as 
funcionalidades base para o funcionamento do sistema, estas funções são chamadas 
de processos elementares e são classificadas em Entradas Externas, Saídas Externas, 
Consultas Externas. 
 Um processo elementar é a menor unidade de uma função disponível ao 
usuário. Por exemplo, consultar clientes pode ser entendido como uma função, mas o 
mesmo não pode ser entendido como um processo elementar, uma vez que podem 
ser realizadas inúmeras consultas diferentes aos clientes, consultar clientes pelo nome, 
consultar clientes em débito, consultar registro de clientes e outras, podemos 
perceber que cada consulta é uma funcionalidade única e independente, desta forma 
para determinar um processo elementar é necessário identificar todas as 
funcionalidades únicas e independentes de uma função. 
 Um processo elementar deve ser único. Por exemplo, consultas que diferem 
uma da outra pela organização dos dados gerados, não podem ser consideradas 
diferentes. 
2.5.1 Entrada Externa 
Uma entrada externa é um processo de controle, ela também realiza o 
processamento de dados do sistema e direciona o mesmo para atender os requisitos 
da aplicação. 
Definida por (VAZQUEZ,2009) como sua principal intenção manter (incluir, 
alterar ou excluir dados) um ou mais Arquivos Lógicos Internos e/ou alterar a forma 
como o sistema se comporta. 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
1
6 
 
 Exemplos: 
1. Transações destinadas a manter Arquivos Lógicos Internos. 
2. Processos destinados a realizar registros. 
Não são exemplos: 
1. Telas de filtro. 
2. Preenchimento de campos de dados. 
3. Telas de login. 
4. Gerar relatórios. 
2.5.2 Saída Externa 
Processo elementar destinado a apresentação de informação ao usuário ou a 
outra aplicação externa que utiliza de cálculos para processar essas informações. 
Definida por (VAZQUEZ,2009) como sua principal intenção apresentar 
informação a partir de lógica de processamento que não seja uma simples recuperação 
de dado ou informação de controle, podendo manter Arquivos Lógicos Internos e 
alterar o comportamento do sistema. 
 Exemplos: 
1. Tela de login (com criptografia). 
2. Relatórios financeiros, supondo estes gerados por cálculos. 
3. Consultas complexas com processamento de dados a partir de cálculos. 
4. Apresentação de gráficos com dados processados a partir de cálculos. 
Não são exemplos: 
1. Telas de filtro. 
2. Consultas simples, sem processamento de dados utilizando cálculos. 
2.5.3 Consulta Externa 
Processo elementar que apresenta informação ao usuário ou a outra aplicação 
externa por meio de recuperação simples. 
Definida por (VAZQUEZ,2009) como sua principal intenção apresentar 
informações ao usuário por meiode uma simples recuperação de dados ou 
informações de controle de ALIs e/ou AIEs, sendo que a lógica de processamento não 
deve conter cálculos ou fórmulas matemáticas e não deve alterar o comportamento do 
sistema. 
Exemplos: 
1. Consultar clientes pelo nome. 
2. Apresentar dados em formato gráfico a partir de recuperação simples. 
Não são exemplos: 
1. Relatórios financeiros, gerados a partir de cálculos. 
2. Telas de filtro. 
2.5.4 Determinação da complexidade e da contribuição 
 Complexidade é o grau de influência que um processo elementar tem para o 
tamanho funcional do sistema. 
 A contribuição é a conversão do grau de complexidade em pontos de função. 
 Essa complexidade é calculada a partir da contagem dos tipos de dados e dos 
arquivos referenciados. 
 Tipos de dados: 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
1
7 
 
É um campo não recursivo de dado, único e reconhecido pelo usuário, 
ou seja, é cada campo preenchido ou apresentado ao usuário. Por exemplo, em 
um formulário os campos nome, CPF, endereço, o botão de confirmação, uma 
janela de mensagem de erro entre outros são tipos de dados, já em um 
relatório, o código do produto, o nome, a descrição, o valor, em um gráfico o 
raciocínio é o mesmo: 
 
 
Figura 2.11: Apresentação de relatório gráfico 
 
 Contamos um tipo de dado para o nome do produto, um para a 
quantidade e um para o valor. No total temos três tipos de dados neste 
relatório. 
 Arquivo Referenciado: 
Um arquivo referenciado é todo arquivo lógico lido, pode ser um ALI ou 
AIE, ou todo arquivo lógico mantido, neste caso só pode ser um ALI. Um tipo de 
registro não é um arquivo lógico, ele pertence a um. Não devemos contar tipos 
de registro e arquivos lógicos lidos várias vezes, são contados apenas uma única 
vez. 
 Tabela de complexidade: 
A tabela de complexidade é padronizada pelo IFPUG, todos os usuários 
da técnica de análise de pontos de função utilizam os mesmos valores. 
 
A
rq
u
iv
o
s 
R
ef
e
re
n
ci
ad
o
s Tipos de Dados 
< 5 5 – 15 > 15 
< 2 Baixa Baixa Média 
2 Baixa Média Alta 
> 2 Média Alta Alta 
Tabela 2.9: Complexidade Entrada Externa (EE) 
 
A
rq
u
iv
o
s 
R
ef
e
re
n
ci
ad
o
s Tipos de Dados 
< 6 6 – 19 > 19 
< 2 Baixa Baixa Média 
2 – 3 Baixa Média Alta 
> 3 Média Alta Alta 
Tabela 2.10: Complexidade Saída Externa (SE) e Consulta Externa (CE) 
 
 Tabela de contribuição: 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
1
8 
 
A tabela de contribuição é padronizada pelo IFPUG, todos os usuários da 
técnica de análise de pontos de função utilizam os mesmos valores. 
Após identificar a complexidade de cada processo elementar do seu 
sistema, é possível determinar a contribuição desses para a contagem dos 
pontos de funçã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 
Tabela 2.11: Tabela de Contribuição 
2.5.5 Aplicando o conhecimento 
 Para finalizar o terceiro passo nós devemos determinar a contagem das funções 
do tipo transação. 
 O fluxo a seguir auxilia na determinação do tipo do processo elementar: 
 
 
Figura 2.12: Fluxo para classificação do processo elementar 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
1
9 
 
Esta é uma visão geral, o importante é saber o que o seu processo 
elementar tem por finalidade. Por exemplo, um cadastro é uma EE o mesmo 
pode apresentar informações ao final do processamento que não o torna uma 
CE ou SE, pois sua finalidade era cadastrar. 
Outra dica, quando você não reconhece a classificação de uma função 
de transação, pode ser que esta ainda não é um processo elementar, cabe 
então reconhecer todos os processos elementares no interior desta função 
antes de verificar a classificação em Entrada Externa (EE), Consulta Externa (CE) 
ou Saída Externa (SE). 
 
1. Identifique todos os processos elementares 
Exemplo: 
 
Descrição 
Incluir Cliente 
Excluir Cliente 
Alterar Cliente 
Incluir Usuário 
Excluir Usuário 
Alterar Usuário 
Incluir Automóveis 
Excluir Automóveis 
Alterar Automóveis 
Registrar Locação 
Finalizar Locação 
Login (com criptografia) 
Consulta clientes por nome 
Consulta carros alugados 
Consulta data do aluguel 
Consulta clientes com carro alugado 
Consulta carro mais alugado 
Consulta cliente que mais aluga 
Tabela 2.12: Identificação dos processos elementares 
 
2. Classifique o processo elementar quanto ao seu tipo 
Para facilitar a identificação utilize o fluxo (figura 2.12). 
Exemplo: 
 
Descrição Tipo 
Incluir Cliente EE 
Excluir Cliente EE 
Alterar Cliente EE 
Incluir Usuário EE 
Excluir Usuário EE 
Alterar Usuário EE 
Incluir Automóveis EE 
Excluir Automóveis EE 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
2
0 
 
Alterar Automóveis EE 
Registrar Locação EE 
Finalizar Locação EE 
Login (com criptografia) SE 
Consulta clientes por nome CE 
Consulta carros alugados CE 
Consulta data do aluguel CE 
Consulta clientes com carro alugado CE 
Consulta carro mais alugado CE 
Consulta cliente que mais aluga CE 
Tabela 2.13: Tipos dos processos elementares 
 
3. Determine os tipos de dados e os arquivos referenciados 
Neste passo é necessário analisar cada processo elementar e definir 
seus tipos de dados e os arquivos aos quais referencia. 
Este passo é mais relevante quando os tipos de dados ou os arquivos 
referenciados estão na fronteira da mudança da complexidade. Longe da 
fronteira, erros neste ponto não irão influenciar na contagem. 
Exemplo: 
 
Descrição Tipo TD AR 
Incluir Cliente EE 6 1 
Excluir Cliente EE 3 1 
Alterar Cliente EE 6 1 
Incluir Usuário EE 3 2 
Excluir Usuário EE 3 2 
Alterar Usuário EE 3 1 
Incluir Automóveis EE 7 2 
Excluir Automóveis EE 3 2 
Alterar Automóveis EE 7 1 
Registrar Locação EE 3 2 
Finalizar Locação EE 4 2 
Login (com criptografia) SE 4 1 
Consulta clientes por nome CE 3 2 
Consulta carros alugados CE 3 2 
Consulta data do aluguel CE 3 2 
Consulta clientes com carro alugado CE 3 3 
Consulta carro mais alugado CE 3 3 
Consulta cliente que mais aluga CE 3 2 
Tabela 2.14: Tipos de Dados (TD) e Arquivos Referenciados (AR) 
 
4. Verifique a complexidade 
Após definir os tipos de dados e os arquivos referenciados, determine à 
complexidade de cada processo elementar consultando a (tabela 2.9 ou 
tabela 2.10). 
Exemplo: 
Descrição Tipo TD AR Complexidade 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
2
1 
 
Incluir Cliente EE 6 1 Baixa 
Excluir Cliente EE 3 1 Baixa 
Alterar Cliente EE 6 1 Baixa 
Incluir Usuário EE 3 2 Baixa 
Excluir Usuário EE 3 2 Baixa 
Alterar Usuário EE 3 1 Baixa 
Incluir Automóveis EE 7 2 Média 
Excluir Automóveis EE 3 2 Baixa 
Alterar Automóveis EE 7 1 Baixa 
Registrar Locação EE 3 2 Baixa 
Finalizar Locação EE 4 2 Baixa 
Login (com criptografia) SE 4 1 Baixa 
Consulta clientes por nome CE 3 2 Baixa 
Consulta carros alugados CE 3 2 Baixa 
Consulta data do aluguel CE 3 2 Baixa 
Consulta clientes com carro alugado CE 6 3 Média 
Consulta carro mais alugado CE 3 3 Baixa 
Consulta cliente que mais aluga CE 3 2 Baixa 
Tabela 2.15: Complexidade 
 
5. Determine a contribuição de cada processo elementar 
 Para determinar a contribuição basta verificar na (tabela 2.11) o ponto 
de função referente a cada complexidade. 
Exemplo: 
Descrição Tipo TD AR Complexidade Contribuição 
Incluir Cliente EE 6 1 Baixa 3 
Excluir Cliente EE 3 1 Baixa 3 
Alterar Cliente EE 6 1 Baixa 3 
Incluir Usuário EE 3 2 Baixa 3 
Excluir Usuário EE 3 2 Baixa 3 
Alterar Usuário EE 3 1 Baixa 3 
Incluir Automóveis EE 7 2 Média 4 
Excluir Automóveis EE 3 2 Baixa 3 
Alterar Automóveis EE 7 1 Baixa 3 
Registrar Locação EE 3 2 Baixa 3 
Finalizar Locação EE 4 2 Baixa 3 
Login (comcriptografia) SE 4 1 Baixa 4 
Consulta clientes por nome CE 3 2 Baixa 3 
Consulta carros alugados CE 3 2 Baixa 3 
Consulta data do aluguel CE 3 2 Baixa 3 
Consulta clientes com carro alugado CE 6 3 Média 4 
Consulta carro mais alugado CE 3 3 Baixa 3 
Consulta cliente que mais aluga CE 3 2 Baixa 3 
Tabela 2.15: Contribuição 
 
6. Determine a contribuição total 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
2
2 
 
 Para finalizar a contagem das funções do tipo dados, some as 
contribuições de todos os processos elementares. 
Exemplo: 
Descrição Tipo TD AR Complexidade Contribuição 
Incluir Cliente EE 6 1 Baixa 3 
Excluir Cliente EE 3 1 Baixa 3 
Alterar Cliente EE 6 1 Baixa 3 
Incluir Usuário EE 3 2 Baixa 3 
Excluir Usuário EE 3 2 Baixa 3 
Alterar Usuário EE 3 1 Baixa 3 
Incluir Automóveis EE 7 2 Média 4 
Excluir Automóveis EE 3 2 Baixa 3 
Alterar Automóveis EE 7 1 Baixa 3 
Registrar Locação EE 3 2 Baixa 3 
Finalizar Locação EE 4 2 Baixa 3 
Login (com criptografia) SE 4 1 Baixa 4 
Consulta clientes por nome CE 3 2 Baixa 3 
Consulta carros alugados CE 3 2 Baixa 3 
Consulta data do aluguel CE 3 2 Baixa 3 
Consulta clientes com carro alugado CE 6 3 Média 4 
Consulta carro mais alugado CE 3 3 Baixa 3 
Consulta cliente que mais aluga CE 3 2 Baixa 3 
Total de Pontos de Função = 57 
Tabela 2.16: Contagem das funções do tipo transação 
2.6 Pontos de função não ajustados 
 O quarto passo é determinar a contagem dos pontos de função não ajustados: 
 
 
Figura 2.13: Determinar pontos de função não ajustados 
 
 Neste ponto nós entendemos a relação de um arquivo lógico com um processo 
elementar: 
 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
2
3 
 
 
Figura 2.14: Relação arquivo lógico e processo elementar 
 
 Neste exemplo temos uma aplicação AP01 com um arquivo lógico interno e 
uma série de processos elementares, a mesma realiza uma leitura de um arquivo 
lógico da aplicação AP02, este arquivo lógico localiza-se fora da fronteira da aplicação 
AP01 e deve ser classificado como um arquivo de interface externa. 
Agora nós devemos realizar a contagem dos pontos de função não ajustados, 
esta análise é simples. Devemos apenas somar as contribuições das funções do tipo 
dado com as contribuições das funções do tipo transação. 
2.6.1 Aplicando o conhecimento 
 Devemos somar as contribuições de todas as funções do tipo dado e do tipo 
transação. 
 Exemplo: 
 
Descrição Contribuição 
Funções do tipo dado 21 PF 
Funções do tipo transação 57 PF 
Total de Pontos de Função Não Ajustados = 78 PF 
Tabela 2.17: Pontos de função não ajustados 
2.7 Determinar o fator de ajuste 
 O quinto passo é determinar o fator de ajuste: 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
2
4 
 
 
Figura 2.15: Determinar o fator de ajuste 
 
 Para o quinto passo devemos determinar o fator de ajuste, mas nós não iremos 
realizar esta análise e atribuiremos o valor do fator de ajuste como um. 
O fator de ajuste pelo seu caráter subjetivo e o impacto gerado na contagem, 
podendo ser de +35% a -35%, fez com que vários utilizadores da técnica de análise de 
ponto de função ignorassem esta etapa antes mesmo do IFPUG adotá-la como 
opcional em 2002. 
Este guia tem por objetivo estimar pontos de função, a inclusão de análises 
subjetivas afetará a contagem e aumentará o erro. 
2.7.1 Aplicando o conhecimento 
 Não será feita análise para esta etapa, uma vez que a mesma é instituída 
opcional pelo IFPUG e pode aumentar o erro na estimativa. 
 Exemplo: 
 Valor de ponto de função não ajustado (VAF) = 1 
 O VAF sendo um não irá interferir na contagem. 
2.8 Realizar o cálculo dos pontos de função ajustados 
 Este é o sexto e último passo para a contagem: 
 
2
. C
O
M
O
 R
EA
LI
ZA
R
 A
 C
O
N
TA
G
EM
 D
E 
P
O
N
TO
 D
E 
FU
N
Ç
Ã
O
 
2
5 
 
 
Figura 2.15: Calcular os pontos de função ajustados 
 
 Esta é a etapa final para obter o tamanho funcional do seu projeto. Existem três 
tipos de contagem, como já foi dito: 
1. Projeto de Desenvolvimento 
2. Projeto de Melhoria 
3. Aplicação 
Como este guia visa à contagem de projeto de desenvolvimento não 
entraremos em detalhes dos demais tipos de contagem. 
Para determinar os pontos de função ajustados para projeto de 
desenvolvimento é necessário aplicar a seguinte fórmula: 
 
DFP = (UFP + CFP) x VAF 
 Sendo: 
 DFP: O número de pontos de função do projeto de desenvolvimento. 
 UFP: Número de pontos de função não ajustados das funções disponíveis 
aos usuários após a instalação 
 CFP: Número de pontos de função não ajustados das funções de conversão, 
ou seja, as funções transitórias que são inutilizadas após a instalação. 
 VAF: Valor do fator de ajuste. 
2.8.1 Aplicando o conhecimento 
 Todos os valores estimados até este ponto serão utilizados para determinar os 
pontos de função ajustados. 
 Exemplo: 
Para terminar a contagem do projeto de desenvolvimento, substitua os 
valores estimados até aqui na fórmula. 
 
DFP = (78 + 0) x 1 
 
A minha aplicação não possui funções de conversão, por este motivo 
somei zero as funções disponíveis após a instalação. 
 
3
. D
ER
IV
A
Ç
Õ
ES
 
2
6 
 
A minha aplicação contada possui um tamanho funcional estimado em 
78 pontos de função. 
3. DERIVAÇÕES 
 Neste ponto já possuímos o tamanho funcional da nossa aplicação, agora será 
apresentado as derivações que podem ser realizadas com ele. 
 Até aqui utilizamos a análise de pontos de função na perspectiva de produto, 
agora iremos fazer uma análise na perspectiva de processo (esforço, custo e prazo). 
 Independente da derivação o importante é possuir um histórico de projeto, só 
assim será possível estimar esforço, custo e prazo. Na primeira vez que aplicar estas 
estimativas o erro será grande, mas conforme for ampliando a sua base de históricos 
de projeto tenderá a diminuir este erro. 
 
3.1 Esforço 
 Para calcular o esforço é necessário conhecer quantos pontos de função são 
produzidos em uma hora e saber quantas horas de trabalho são consideradas em um 
mês na sua empresa. 
 A estimativa de esforço pode ser: 
 Pontos de Função por Homem Mês (PF/HM) 
 Pontos de Função por Hora (PF/H) 
Temos por base que a taxa de produtividade é media em hora por ponto de 
função (H/PF). 
Cada linguagem ou tecnologia demandam um esforço diferente, essas 
características não influenciam nos pontos de função, mas sim no esforço que 
demanda produzir cada ponto de função. 
Existem vários editais para licitação que incluem tabelas de produtividade 
mínima no desenvolvimento de projetos. 
 
Desenvolvimento e manutenção de sistemas 
Tecnologia Produtividade Mínima 
Java 15 h/PF 
ASP (Vbscript e Javascript) 10 h/PF 
PHP 11 h/PF 
JSP 13 h/PF 
HTML 7 h/PF 
Cold Fusion 11 h/PF 
Delphi 9 h/PF 
Crystal reports 9 h/PF 
PL/SQL 9 h/PF 
Visual Basic 9 h/PF 
Tabela 3.1: Tabela de produtividade mínima ACINE 
 
Utilizar bases de editais (sem o conhecimento sobre o projeto) ou de outras 
empresas, se constitui um risco muito grande, pois a produtividade é intrínseca de 
cada empresa, pois essas possuem funcionários e processos diferenciados. 
 
3
. D
ER
IV
A
Ç
Õ
ES
 
2
7 
 
3.1.1 Aplicando o conhecimento 
 Exemplo: 
A nossa aplicação foi estimada em 78 pontos de função. Considere uma 
empresa que possui uma taxa de produtividade mínima em Java de 5 H/PF e 
com uma carga de trabalho de 130 horas por homem mês: 
 
Esforço = (5 x 78) 
 
Esta empresa gastaria 390 horas pra produzir o sistema ou três meses. 
3.2 Custo 
 A estimativa do custo de um projeto é a informação primordial na hora de 
elaborar uma proposta, este não pode exceder as expectativas do cliente e nem tão 
pouco ter um valor inferior ao necessário para o funcionamento da empresa. 
 Como na determinação do esforço o custo também é estimado a partir de 
dados da empresa, neste casoé necessário ter o conhecimento do custo da hora da 
equipe de desenvolvimento ou o valor de um ponto de função para sua empresa. 
 O custo é dado por: 
 Custo por hora vezes hora por ponto de função (C/H x H/PF). 
Assim nós obtemos o custo por ponto de função. 
3.2.1 Aplicando o conhecimento 
 Exemplo: 
Suponha que a hora de trabalho custa R$ 21,00 e como é produzido um 
ponto de função a cada cinco horas o valor do ponto de função é de R$ 105,00. 
Estimamos que os esforços necessários para produzir nossa aplicação 
são de 390 horas e a mesma possui 78 pontos de função. 
 
Custo = (78 x 100,00) 
 
Podemos assim inferir que a aplicação tem um custo de 
aproximadamente R$ 7800,00. 
3.3 Prazo 
 O prazo é um fator crítico a ser determinado, pois para estimativas nós 
supomos ele sendo uma função linear com o recurso, o que é uma suposição muito 
falha. Por exemplo, se um projeto desenvolvido por dois desenvolvedores gasta um 
prazo de dois meses, alocar mais dois desenvolvedores para o projeto não 
necessariamente implica que o mesmo irá durar apenas um mês. 
 A análise empírica mostra que essa linearidade não existe, uma mulher demora 
nove meses para gerar um bebê, nove mulheres não geram um bebê em um mês 
(VAZQUEZ,2009). 
 Quanto maior o tamanho funcional de um projeto, maior será o prazo e maior 
será o erro. Para projetos pequenos o erro é aceitável, mas novamente voltamos ao 
ponto de que a melhor maneira de evitar estes erros é possuindo uma base histórica 
dos projetos desenvolvidos. 
 Implicamos o prazo da seguinte forma: 
 Prazo é a relação de esforço por recurso. 
 
3
. D
ER
IV
A
Ç
Õ
ES
 
2
8 
 
 
 Prazo = 
 
3.3.1 Aplicando o conhecimento 
 Exemplo: 
Foi definido que o esforço necessário para produzir a aplicação é de 390 
horas ou três meses. Suponha que esta empresa possua dois funcionários 
habilitados a desenvolver o projeto na tecnologia estabelecida. 
 
Prazo = (3 / 2) 
 
Utilizando dessas informações concluímos que o prazo para a entrega 
do sistema será de um mês e meio. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Esforço 
Recurso 
 
4
. C
O
N
SI
D
ER
A
Ç
Õ
ES
 
2
9 
 
4. CONSIDERAÇÕES 
 Durante a elaboração deste guia tive contato com outras técnicas de 
estimativas de software, contagem por linha de código, contagem de telas, pontos por 
caso de uso e outras, foi possível perceber que das soluções usuais encontradas a 
Análise de Ponto de Função – APF é uma ótima solução e consegue atender de forma 
satisfatória as necessidades do mercado. 
 Para elaboração deste guia foi utilizado artigos, livros e vídeos-aula. Atribuo 
grande parte do meu conhecimento ao livro Análise de Pontos de Função 
(VAZQUEZ,2009) que sem o qual eu teria grande dificuldade em terminar o meu 
projeto. Outra fonte de conhecimento que me foi de grande ajuda, não pela estrutura 
formal, mas pelos conhecimentos gerados diariamente a partir de dúvidas dos usuários 
da técnica, foi o grupo de leitores de APF, disponível em: 
<http://groups.yahoo.com/group/livro-apf/>. 
 Finalizando as considerações, agradeço ao José Luis Braga meu orientador por 
me possibilitar o conhecimento nesta área e estar sempre à disposição para ajudar e 
indicar materiais surpreendentes sobre os mais variados conhecimentos desde 
engenharia de software, gerência de projetos a conhecimentos do mundo e fora dele. 
 Não se limite a este guia, pois ele apresenta uma visão superficial da técnica de 
análise de pontos de função e que ele te instigue a buscar mais conhecimentos sobre 
essa área. 
 
“Um conhecimento nunca é mantido constante, ou ele é perdido ou é enriquecido.” 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
http://groups.yahoo.com/group/livro-apf/
 
5
. B
IB
LI
O
G
R
A
FI
A
 
3
0 
 
5. BIBLIOGRAFIA 
VAZQUEZ,C.E. , SIMÕES,G.S. , ALBERT,R.M. Análise de ponto de função 
medição, estimativa e gerenciamento de projetos de software. São Paulo, Editora 
Érica, 2009. 
Softex. MPS.BR - Melhoria de processo do software brasileiro - Guia geral, 
2009. 
IFPUG(International Function Point Users Group). Disponível em: 
<http://www.ifpug.org>. Acesso em: 01 nov 2010. 
BFPUG(Brazilian Function Point Users Group). Disponível em: 
<http://www.bfpug.com.br>. Acesso em: 01 nov 2010. 
PMI (Project Management Institute). Um Guia do Conjunto de Conhecimentos 
em Gerenciamentos de Projetos (PMBOK). Estados Unidos: PMI Publications, 2004. 
DEKKERS, C. Pontos de Função e Medidas - O Que é um Ponto de Função?. QAI 
Journal, dez. 1998 
DEKKERS, C. Desmistificando Pontos de Função: Entendendo a Terminologia. IT 
Metrics Strategies, out. 1998. 
ACINE. Anexo XVIII – Tabelas de produtividade mínima, 2008. Disponível em: 
<http://www.ancine.gov.br/media/concorrencia0012008/AnexoXVIII.pdf>. Acesso em: 
19 jun 2011. 
 
 
 
http://www.bfpug.com.br/Artigos/Dekkers-PontosDeFuncaoEMedidas.htm
http://www.ancine.gov.br/media/concorrencia0012008/AnexoXVIII.pdf
Projeto e Desenvolvimento de Sistemas de Informação
Prof. Flávio de Oliveira Silva, Ph.D.
1
Projeto e Desenvolvimento de 
Sistemas de Informação
Prof. Flávio de Oliveira Silva, Ph.D.
flavio@ufu.br
Projeto e Desenvolvimento de Sistemas de Informação
Prof. Flávio de Oliveira Silva, Ph.D.
Objetivos
 Identificar problemas do mundo real implementáveis computacionalmente;
 Realizar a análise e projeto de soluções em software de forma padronizada e 
eficiente
2
Projeto e Desenvolvimento de Sistemas de Informação
Prof. Flávio de Oliveira Silva, Ph.D.
Ementa
 Apresentação de um problema a ser solucionado através do computador
 Especificação do software a ser implementado
 Implementação do software especificado
 Problemas e práticas recomendadas no desenvolvimento de software
 Visão geral do processo de desenvolvimento 
 Planejamento e Elaboração; análise e projeto; implementação
3
Projeto e Desenvolvimento de Sistemas de Informação
Prof. Flávio de Oliveira Silva, Ph.D.
Programa
 Identificação de um problema
 Análise
 Problemas e práticas recomendadas
 Levantamento de requisitos
 Custos relacionados
 Metodologias de Análise
 Modelagem de Banco de Dados
 Diagramas para análise
 Visão geral das ferramentas de análise
 Projeto
 Técnicas de projeto
 Projeto de Telas e Banco de Dados
 Escolha de Ferramentas de desenvolvimento
 Modelos de construção de software
 Camadas de software
 Componentes e reutilização de software
 Criação de Protótipos
4
Projeto e Desenvolvimento de Sistemas de Informação
Prof. Flávio de Oliveira Silva, Ph.D.
Bibliografia
 Básica
 Blaha, Rumbaugh. Modelagem e projetos baseados em objetos com UML 2. Elsevier: 
Campus. 2006
 Maldonado, Delamaro, Jino. Introdução ao Teste de Software. Campus, 2007.
 Guedes. UML 2 – Uma abordagem prática. Novatec. 2009
 Lowe, Pressman. Engenharia Web; LTC, 2009.
 Complementar
 FURLAN, José Davi. Modelagem de Objetos através UML. Makron Books, 1998.
 LAIRMAN, Craig. Utilizando UML e Padrões. Ed. Bookman, 2007.
 OESTEREICH, Bernd; Weilkiens, Tim. UML 2 Certification Guide. MORGAN 
KAUFMANN, 2006.
 PENDER, Tom, UML – A Bíblia. Elsevier: Campus. 2004.
 Pressman. Engenharia de Software, 7ª. Edição.
 Sommerville. Engenharia de Software, 9ª. Edição
 SOMMERVILLE, Ian. Engenharia de Software. Editora Pearson / Addison Wesley, 
2003
 BOOCH, Grady; Jacobson, Ivar; Rumbauch,James. UML: Guia do Usuário. Campus, 
2006.
5
Projeto e Desenvolvimento de Sistemas de Informação
Prof. Flávio de Oliveira Silva, Ph.D.
Avaliação
 Trabalho em Grupo
 Foco Trabalho
 Cooperação / Colaboração
 Coordenação
 Responsabilidade
 Gestão
 Ferramentas: 
 Gerenciamento de Projeto
 Gerenciamento de versões (svn, github, google code, etc.)
 Issue Tracker (bugzilla, github, etc.)
 Cada fase terá como foco uma Disciplina
 Modelagem de Negócios
 Requisitos
 Análise e Projeto
 Implementação e Implantação
6
Projeto e Desenvolvimento de Sistemas de Informação
Prof. Flávio de Oliveira Silva, Ph.D.
RUP
Projetoe Desenvolvimento de Sistemas de Informação
Prof. Flávio de Oliveira Silva, Ph.D.
Avaliação
Disciplinas x Artefatos
 Modelagem de Negócios
 Documento de Visão
 Diagrama Caso de Uso
 Contexto do Sistema com todas as funcionalidades
 Requisitos
 Especificação de Casos de Uso
 Modelo de Domínio
 Análise e Projeto
 Diagramas com Visões da Arquitetura
 Protótipo de telas
 Persistência
 Integrações
 Implementação e Implantação
8
Projeto e Desenvolvimento de Sistemas de Informação
Prof. Flávio de Oliveira Silva, Ph.D.
Disciplinas x Nota
2019/01
 Modelagem de Negócios (20 pontos)
 Documento de Visão
 Diagrama de Contexto (Diagrama de Caso de Uso)
 Data final – 08/04/19
 Requisitos (30 pontos)
 Especificação dos Casos de Uso
 Modelo de Domínio (Diagrama de Classes)
 Data final – 06/05/19
 Análise e Projeto (35 pontos)
 Documento de Arquitetura
 Data final – 17/06/19
 Implementação (10 pontos) e Implantação (5 pontos)
 Protótipos
 Data final – 13/07/19
9
 
 
 
1 
 
Amanda Meincke Melo 
Lara Schibelsky Godoy Piccolo 
Ismael Mattos Andrade Ávila 
Cláudia de Andrade Tambascia 
(organizadores) 
 
Usabilidade, Acessibilidade e 
Inteligibilidade Aplicadas em Interfaces 
para Analfabetos, Idosos e Pessoas 
com Deficiência 
 
Resultados do Workshop 
IHC 2008 - VIII Simpósio Brasileiro sobre Fatores Humanos em 
Sistemas Computacionais 
 
 
 
 
 
 
1ª Edição 
CPqD 
Campinas, SP 
2009 
 
 
 
 
 
 
 
CPqD – Centro de Pesquisa e Desenvolvimento em Telecomunicações 
Rodovia Campinas/Mogi-Mirim, km 118,5 – 13086-902 
Campinas – SP – Brasil 
Tel.: 0800-7022773 
1ª edição – abril de 2009 
 
 
 
 
Editores 
Amanda Meincke Melo 
Lara Schibelsky Godoy Piccolo 
Ismael Mattos Andrade Ávila 
Cláudia de Andrade Tambascia 
 
 
 
 
 
Reprodução autorizada, desde que citada a fonte de referência da 
publicação e os autores dos artigos. 
 
Distribuição gratuita. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1 
Apresentação 
É com grande satisfação que compartilhamos esta compilação de artigos apresentados e 
discutidos durante o workshop “Usabilidade, Acessibilidade e Inteligibilidade aplicadas em 
interfaces para analfabetos, idosos e pessoas com deficiência”. O evento ocorreu em 
outubro de 2008, em Porto Alegre - RS, integrado ao IHC'2008 – Simpósio Brasileiro sobre 
Fatores Humanos em Sistemas Computacionais. 
O primeiro capítulo desta publicação apresenta os objetivos e os resultados alcançados com 
o workshop, sumarizando as principais contribuições de cada trabalho. Os capítulos 
subseqüentes trazem os artigos na forma em que foram submetidos pelos autores. 
Desejamos profundamente que este material possa contribuir à reflexão sobre 
acessibilidade, usabilidade e inteligibilidade visando à promoção da qualidade da 
experiência do cidadão brasileiro no acesso indiscriminado ao conhecimento e à 
participação na sociedade mediados por Tecnologias de Informação e Comunicação. 
 
Os organizadores. 
 
 2 
 
 
Sumário 
Usabilidade, Acessibilidade e Inteligibilidade aplicadas em interfaces para 
analfabetos, idosos e pessoas com deficiência – Resultados do Workshop..................3 
Amanda Meincke Melo, Lara Piccolo, Ismael Ávila, Claudia de Andrade Tambascia 
Personas para Caracterização da Experiência de Uso de Tecnologia pela População 
Digitalmente Excluída........................................................................................................ 15 
Lucia Filgueiras, Stefan Martins, Danilo Correa, Alexandre Osorio 
XLupa – Um Ampliador de Tela com Interface Adaptativa para Pessoas com Baixa 
Visão................................................................................................................................... 23 
Jorge Bidarra, Clodis Boscarioli, Claudia Brandelero Rizzi 
O Selo Não Garante a Acessibilidade............................................................................... 31 
Horácio Pastor Soares, Simone Bacellar Leal Ferreira, Luiz Carlos Monte 
Tornando os Requisitos de Usabilidade mais Aderentes às Diretrizes de 
Acessibilidade.................................................................................................................... 43 
Simone Bacellar Leal Ferreira, Ricardo Rodrigues Nunes, Denis S. Silveira, Horácio Pastor Soares 
Avaliando a Qualidade Afetiva de Sistemas Computacionais Interativos no Cenário 
Brasileiro ............................................................................................................................ 55 
Elaine Hayashi, Vânia Neris, Cecília Baranauskas, Maria Cecília Martins, Lara Piccolo, Rosely Costa 
Sumarização Automática para Simplificação de Textos: Experimentos e Lições 
Aprendidas ......................................................................................................................... 63 
Paulo R. A. Margarido, Thiago A. S. Pardo, Sandra M. Aluísio 
 
 
 
 
 
 
 
 
 
 
www.cpqd.com.br 
3 
Usabilidade, Acessibilidade e Inteligibilidade 
aplicadas em interfaces para analfabetos, idosos e 
pessoas com deficiência – Resultados do Workshop 
Amanda Meincke Melo1 
ammelobr@gmail.com 
Lara S. G. Piccolo2 
lpiccolo@cpqd.com.br 
Ismael Ávila2 
avila_an@cpqd.com.br 
Claudia de Andrade Tambascia2 
claudiat@cpqd.com.br 
1 Faculdade Comunitária de Campinas – 
Unidade 3 
2 Fundação CPqD – Centro de Pesquisa e 
Desenvolvimento em Telecomunicações 
Palavras-chave 
Usabilidade, Acessibilidade, 
Inteligibilidade, Inclusão digital 
Resumo 
O workshop “Usabilidade, Acessibilidade e 
Inteligibilidade aplicadas em interfaces 
para analfabetos, idosos e pessoas com 
deficiência”, integrado ao IHC'2008 – 
Simpósio Brasileiro sobre Fatores 
Humanos em Sistemas Computacionais 
teve como objetivo promover o debate 
acerca de desafios que permeiam o 
desenvolvimento de interfaces que 
incluam pessoas social e digitalmente 
excluídas no Brasil. Este artigo sumariza 
os resultados do workshop, refletindo 
sobre as contribuições dos trabalhos 
apresentados durante o evento. 
 
U
sa
b
ili
d
ad
e,
 In
te
lig
ib
ili
d
ad
e 
e 
A
ce
ss
ib
ili
d
ad
e 
- 
R
es
u
lt
ad
o
s 
d
o
 W
o
rk
sh
o
p
 
 4 
 
www.cpqd.com.br 
Introdução 
Conforme enunciado pela Sociedade Brasileira de Computação, propor soluções que 
permitam o “Acesso participativo e universal do cidadão brasileiro ao conhecimento” 
(BARANAUSKAS e DE SOUZA, 2006) é um grande desafio a pesquisas em computação do 
Brasil. Conceber soluções inclusivas mediadas por Tecnologias de Informação e 
Comunicação (TICs) no contexto brasileiro passa pela compreensão das necessidades do 
cidadão no uso de sistemas de informação interativos, nos mais variados cenários. 
Além das barreiras em decorrência das deficiências sensoriais, física e mental, o baixo nível 
de escolaridade representa também uma grande barreira eminente ao uso pleno de 
computadores no Brasil. Cerca de metade da população tem alfabetização insuficiente para 
uma utilização autônoma e desenvolta de grande parte dos conteúdos e das interfaces 
computacionais hoje existentes. 
A construção de ambientes, produtos e serviços inclusivos, que considerem as 
necessidades de toda a população, na maior extensão possível, é urgente na sociedade 
contemporânea (BRASIL, 2004; BRASIL, 2006; MANTOAN e BARANAUSKAS, 2006; 
MELO, 2007; PICCOLO et al, 2007). Diante disso, é pertinente investigar aspectos de 
usabilidade, acessibilidade e inteligibilidade em soluções de interface que tragam melhores 
resultados em termos de facilidade no uso de computadores por um público analfabeto ou 
com baixo letramento, idoso e/ou com algum tipo de deficiência, tirando proveito das 
habilidades e capacidades que este já possui e que utiliza em seu dia-a-dia. Assim, 
barreiras iniciais ao uso de computadores podem ser transpostas, além de visar a uma 
crescente autonomia na interação humano-computador. O trato com um público tão rico em 
diferenças exige reflexões sobre métodos e técnicas de IHC – Interação Humano-