Engenharia de Software - 07 - Metricas de Software

Prévia do material em texto

Aula 07
Engenharia de Software para Concursos - Curso Regular
Professor: Diego Carvalho
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 118 
 
AULA 07 
 
 
SUMÁRIO PÁGINA 
Apresentação 01 
- Métricas de Software 03 
- Análise de Pontos de Função 23 
Lista de Exercícios Comentados 90 
Gabarito 117 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 2 de 118 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Engenharia de Software. Conceitos Básicos ou Gerais. Ciclo de vida do software. Modelos, 
Metodologias ou Processos de Desenvolvimento de Software: Modelo em Cascata. Modelo Orientado 
a Reuso. Modelo em Prototipagem, Modelo Evolucionário, Modelo Espiral, Modelo Formal, RAD, Modelo 
Iterativo e Incremental. Processo Unificado: Conceitos Básicos, Dimensões Dinâmica, Estática e 
Prática, Gráfico das Baleias, Fases (Iniciação, Elaboração, Construção e Transição), Disciplinas ou 
Fluxo de Processos (Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste, 
Implantação, Gestão de Configuração e Mudança, Gestão de Projetos, Ambiente), Artefatos, 
Atividades, Melhores Práticas, Principais Marcos, Princípios Chaves. Metodologias Ágeis de 
Desenvolvimento de Software: Scrum, eXtreme Programming (XP), Feature-driven Development 
(FDD), Test-driven Development (TDD), Acceptance Test-driven Development (ATDD), Kanban. 
Definição de Requisito, Classificação de Requisitos (Funcional, Não- Funcional, Domínio; Produto, 
Organizacional, Externo; Confiabilidade, Proteção, Desempenho, etc); Engenharia de Requisitos: 
Estudo de Viabilidade, Elicitação e Análise de Requisitos, Especificação de Requisitos, Validação de 
Requisitos, Gestão de Requisitos. Técnicas de Elicitação e Técnicas de Validação. Linguagem de 
Modelagem: Unified Modeling Language (UML) 2.x – Contexto Histórico, Conceitos Básicos, Tipos de 
Diagramas (Estruturais, Comportamentais, Interação). Diagramas de Classes, Componentes, 
Implantação, Perfil, Objetos, Estrutura Composta, Pacotes, Máquina de Estados, Casos de Uso, 
Atividades, Sequência, Comunicação, Interação Geral e Tempo. Conceitos Básicos do Paradigma 
Estruturado. Conceitos Básicos de Orientação a Objetos: Classes, Objetos, Atributos, Métodos, 
Mensagens, Abstração, Encapsulamento, Polimorfismo, Herança, Relacionamentos). Análise e 
Projeto: Conceitos Básicos, Diferenças, Modelos, Classes de Fronteira, Controle e Entidade. Análise 
de Pontos de Função: IFPUG – Definição e Contexto, Benefícios e Vantagens, Componentes de Dados 
(AIE, ALI) e Transação (EE, SE, CE), Etapas do Procedimento de Contagem: Determinar Tipo de 
Contagem, Determinar Escopo e Fronteira, Cálculo dos Pontos de Função Não-Ajustados, Cálculo do 
Fator de Ajuste, Cálculo dos Pontos de Função Ajustados. NESMA - Tipos de Contagem e Deflatores. 
Qualidade de Software: Garantia e Controle, Principais Características, Verificação & Validação, 
Erro, Falha, Falta e Defeito. Testes de Software: Conceitos Básicos, Processo de Testes, Técnicas de 
Testes (Teste Caixa Banca, Cinza e Preta), Níveis de Testes (Teste de Unidade, Módulo, Componente; 
Teste de Integração; Teste de Aceitação, Validação, Release; Teste de Sistema/Funcional). Tipos de 
Testes: Carga, Estresse, Volume, Desempenho, Usabilidade, Cenários, Regressão, Back-to-Back, 
Comparação, Recuperação, Alfa, Beta, Compatibilidade, Estático, Dinâmico). Arquitetura de 
Software. Arquitetura em Camadas (Cliente/Servidor). Arquitetura MVC. Arquitetura Distribuída. 
Arquitetura Hub. Arquitetura Microsserviços. Arquitetura Mainframe. Arquitetura Orientada a 
Serviços (SOA): Conceitos Básicos, SOAP, WSDL, UDDI. REST. WS-Security. Interoperabilidade de 
Sistemas. e- PING: Conceitos Básicos, Interoperabilidade, Escopo, Políticas Gerais, Segmentação, 
Gestão. Acessibilidade de Sistemas. e-MAG 3.1: Conceitos Básicos, Acessibilidade, Acesso, Passos 
para um Sítio Acessível, Segmentos, Recomendações. Engenharia de Usabilidade. Gerenciamento 
Eletrônico de Documentos (GED). Portais Corporativos e Colaborativos. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 3 de 118 
 MÉTRICAS DE SOFTWARE 
 
De acordo com Sommerville: “A medição de software se dedica a derivar um valor 
numérico para algum atributo de um produto de software ou de um processo de 
software. Comparando-se esses valores uns com os outros e aos padrões que se 
aplicam em uma organização, você pode ser capaz de tirar conclusões sobre a 
qualidade de software ou dos processos de software”. 
 
As medições de software podem ser usadas para realizar previsões gerais sobre um 
sistema, i.e., encontrar uma estimativa geral de algum atributo do sistema (ex: 
quantidade de defeitos) ou para identificar componentes anômalos, i.e., partes que 
possuem características que desviam de alguma regra específica. Uma métrica de 
software é uma medição que se refere a um software, processo ou documentação. 
 
Na maioria dos empreendimentos técnicos, as medidas e as métricas ajudam-nos a 
entender o processo técnico usado para desenvolver um produto. O processo é 
medido num esforço para melhorá-lo, e o produto é medido para aumentar sua 
qualidade, quantificar e administrar mais efetivamente. Vamos ver agora algumas 
métricas e grupos (observem que uma métrica pode pertencer a mais de um grupo). 
 
Métricas de Software podem ser de controle ou de predição: 
 
 Métricas de Controle/Processo: estão relacionadas a processos de software; são 
utilizadas para tomada de decisões sobre alterações no processo de 
desenvolvimento de software, por exemplo: esforço médio e tempo necessário 
para reparar os defeitos reportados. 
 
 Métricas de Predição/Produto: estão relacionadas a produtos de software; são 
utilizadas para estimar o esforço necessário para construção ou alteração de 
software e auxiliam a prever características dele, por exemplo: complexidade de 
um módulo ou a extensão média dos identificadores em um programa. 
 
Métricas de Predição/Produto podem ser internas/estáticas ou externas/dinâmicas: 
 
 Métricas Estáticas ou Internas: são aquelas coletadas em representações do 
sistema como projeto, programa ou documentação – sem a necessidade da 
execução dos programas. Ajudam a mensurar a complexidade e a facilidade de 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 4 de 118 
compreensão e manutenção de um sistema de software. Permitem medir a 
qualidade dos artefatos intermediários e prever a qualidade do produto final. 
 
 Métricas Dinâmicas ou Externas: são aquelas coletadas durante a execução de 
um programa, a partir do comportamento do sistema ou do seu efeito no 
ambiente real de operação. Elas ajudam a avaliar a eficiência e a confiabilidade 
de um programa e quase sempre estão relacionadas com atributos da qualidade 
de software. 
 
Métricas de Software podem ser diretas ou indiretas: 
 
 Métricas Diretas: também conhecidas como básicas, quantitativas ou primitivas, 
são aquelas que não dependem da medição de outros atributos, por exemplo: 
custo/esforço do desenvolvimento, linhas de código, velocidade de execução, 
quantidade de memória, número de erros, quantidade de defeitos. 
 
 Métricas Indiretas: também conhecidas como qualitativas ou derivadas, são 
aquelasque dependem da medição de outros atributos. Por exemplo: 
produtividade, qualidade e técnicas (funcionalidade, complexidade, eficiência, 
confiabilidade, manutenibilidade, modularidade, portabilidade). 
 
Métricas de Software podem ser orientadas a tamanho, função ou pessoas: 
 
 Métricas Orientadas a Tamanho são aquelas baseadas no número de linhas de 
código produzidas, também conhecidas como Lines Of Code (LOC).1 
 
 Métricas Orientadas à Função: são aquelas baseadas na funcionalidade do 
software, tais como Análise de Pontos de Função. 
 
 Métricas Orientadas a Pessoas são aquelas que indicam a forma como as 
pessoas devem desenvolver programas de computador. 
 
Métricas de Software podem ser objetivas ou subjetivas: 
 
 Métricas Objetivas são aquelas que independem do autor da medição ou 
julgamento humano, por exemplo: quantidade de defeitos. 
 
 
1 Como medir Produtividade? KLOC/Pessoa-Mês. Como medir Qualidade? Erros/KLOC. Como medir Custo? 
$/KLOC. Como medir Documentação? Páginas/KLOC. 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 5 de 118 
 Métricas Subjetivas: são aquelas que dependem do autor da medição ou 
julgamento humano, por exemplo: classificar criticidade de um defeito. 
 
Vejamos outras métricas diversas: 
 
 Métricas de Produtividade: concentram-se na saída do processo de engenharia 
de software (Ex: KLOC/Pessoa-Mês). 
 
 Métricas de Qualidade: indicam o quanto o software atende aos requisitos 
definidos pelo usuário. 
 
 Métricas Técnicas concentram-se nas características do software (Ex: 
complexidade, modularidade, manutenibilidade, funcionalidade, etc). 
 
Geralmente, é impossível medir os atributos de qualidade de software diretamente. 
Os atributos de qualidade (como facilidade de manutenção, facilidade de 
compreensão e facilidade de uso) são atributos externos que se relacionam a como 
os desenvolvedores e os usuários veem o software. Eles são influenciados por muitos 
fatores e não existe uma maneira simples para medi-los. 
 
Em vez disso, você deve medir algum atributo interno do software (como seu 
tamanho) e presumir que há um relacionamento entre o que você pode medir e o 
que realmente quer conhecer. Professor, pode dar um exemplo? Para medir a 
confiabilidade de um sistema, eu posso medir o tamanho do programa em linhas 
de código; o número de mensagens de erro; e sua complexidade ciclomática. 
 
Outro exemplo? Para medir a facilidade de uso, eu posso medir o tamanho do 
manual do usuário do programa e a quantidade de mensagens de erro. Professor, 
isso serve para tudo? Não! Características de software como tamanho ou 
complexidade ciclomática não têm um relacionamento claro e consistente com 
atributos de qualidade, como facilidade de compreensão ou manutenção. 
 
O que fazer, então? Bem, uma alternativa seria coletar uma grande quantidade de 
dados de sistemas existentes e descobrir como os atributos de produto de software 
se relacionam com as qualidades externas. As métricas de produtos se dividem em 
duas classes: métricas dinâmicas, coletadas em um programa em execução; e 
métricas estáticas, coletadas em uma documentação, projeto, etc. 
 
Em geral, métricas dinâmicas ajudam a avaliar a eficiência e a confiabilidade de um 
programa. Já as métricas estáticas ajudam a avaliar a complexidade, facilidade de 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 6 de 118 
compreensão e facilidade de manutenção de um sistema de software. As métricas 
dinâmicas geralmente possuem uma relação mais estreita com atributos de 
qualidade de software do que as métricas estáticas. Vamos ver algumas métricas? 
 
 Fan-in/Fan-out: 
 
Fan-in é uma medida do número de funções ou métodos que chamam alguma 
outra função ou método (digamos X). Fan-out é o número de funções chamadas 
pela função X. Um valor alto para fan-in significa que X está firmemente acoplado 
com o resto do projeto, e mudanças em X terão grande impacto. 
 
 Extensão de Código: 
 
É uma medida do tamanho de um programa. Geralmente, quanto maior for o 
tamanho do código de um componente, mais complexo e propenso a erros esse 
componente será. A extensão de código foi mostrada como uma das métricas mais 
confiáveis de previsão de propensão a erros em componentes. 
 
 Complexidade Ciclomática: 
 
É uma medida da complexidade de controle de um programa. Essa complexidade 
de controle pode estar relacionada à facilidade de compreensão do programa. 
Utiliza a fórmula M = E – N + 2.P (M = Complexidade Ciclomática; E = Quantidade 
de Setas; N = Quantidade de Nós; P = Quantidade de Componentes Conectados). 
 
 Extensão de Identificadores: 
 
É uma medida da extensão média de identificadores distintos em um programa. Em 
geral, quanto maiores forem os identificadores, mais eles serão significativos e, por 
isso, mais compreensível será o programa. Vocês entendem isso? Uma variável com 
30 caracteres, em geral, possui mais significado. 
 
 Profundidade de Aninhamento de Declarações Condicionais: 
 
É uma medida da profundidade de aninhamento de declarações IF em um 
programa. As declarações IF profundamente aninhadas são difíceis de compreender 
e são potencialmente propensas a erros. Basta imaginar um IF dentro de um IF 
dentro de um IF dentro de um IF – fica complicado! 
 
 Índice de Fog 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 7 de 118 
 
É uma medida da extensão média das palavras e das sentenças em documentos. 
Quanto maior for o valor para o índice de Fog, mais difícil será a compreensão de 
documentos. Galera, vocês devem saber como é chato ler documentação e o Índice 
de Fog ajuda a medir aqueles mais difíceis de entender. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 8 de 118 
 
 
As métricas de qualidade de software são um subconjunto das métricas de software 
que se focam em aspectos de qualidade do produto, processo e projeto. As métricas 
do produto descrevem características do produto como tamanho, complexidade, 
design, performance e níveis de qualidade. Métricas de processo podem ser usadas 
para melhorar o desenvolvimento e manutenção do software. 
 
E as métricas de projeto descrevem as características do projeto em 
desenvolvimento como o número de desenvolvedores, utilização de padrões, custo, 
produtividade, entre outros. Nós iremos ver agora mais detalhadamente cada um 
desses tipos de métricas. Eles caem pouco em prova, bem menos que as métricas 
já citadas anteriormente. Comecemos pelas Métricas de Qualidade do Produto! 
 
A definição de qualidade de software consiste de dois níveis: qualidade intrínseca 
do produto e satisfação do cliente. Cobrindo ambos os níveis, temos: Tempo Médio 
entre Falhas e Densidade do Defeito. A qualidade intrínseca do produto é medida 
pelo número de bugs no software ou tempo que o software pode rodar sem falhar. 
Vamos detalhá-los melhor! 
 
O Mean Time To Failure (MTTF) é a métrica de robustez mais utilizada em sistemas 
críticos, como sistemas de controle de tráfego aéreo. Querem um exemplo? O 
Governo dos EUA exige que seu sistema de tráfego aéreo não fique indisponível por 
mais de três segundos por ano! Sinistro, não é?! Já a Densidade de Defeito, em 
contraste,é utilizada em muitos sistemas comerciais. 
 
Essas métricas são parecidas, mas a primeira mede o tempo entre falhas e a segunda 
mede os defeitos relativamente ao tamanho do software (linhas de código, pontos 
de função, etc) e o tempo. Professor, existe diferença entre falha e defeito? Sim, mas 
na prática – nesse contexto – são iguais. A Densidade de Defeitos, então, mede a 
quantidade de defeitos durante um período de tempo pelo tamanho do software. 
 
 
 
O número de defeitos pode ser relativo a um determinado período (mês, trimestre, 
ano, etc), ou a uma determinada fase do ciclo de vida do software, ou ao ciclo de 
vida de software como um todo. Sua utilização permite a identificação de 
MÉTRICAS DE QUALIDADE DE SOFTWARE 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 9 de 118 
componentes de alto risco e permite a comparação de produtos pela medição da 
qualidade de cada um. 
 
Existe também uma métrica similar ao MTTF! Qual é, professor? É a Mean Time 
Between Failure (MTBF) – trata-se do tempo médio entre falhas, i.e., tempo entre 
duas falhas sucessivas no sistema, expressa na maioria das vezes em horas, e é uma 
métrica chave para sistemas que podem ser reparados ou restaurados. Assim, é 
possível prever quando será a próxima falha do sistema2. 
 
Quanto às Métricas de Qualidade de Processo, elas são utilizadas para melhorar o 
desenvolvimento de software e sua manutenção. Estas métricas tornam-se muito 
importantes em um processo de desenvolvimento, pois medem vários parâmetros 
nas várias fases do processo. Um exemplo seria a Efetividade de Remoção de 
Defeitos, como mostra a fórmula abaixo: 
 
 
 
Um fato importante é que a utilização desta métrica em todas as fases do processo 
de desenvolvimento faz com que seja possível medir a efetividade de remoção de 
defeitos e a injeção de erros, e com isso poder rastrear as fases que mais injetam 
erros na aplicação. Outras métricas são: Índice de Manutenção de Erros, Cobertura 
de Testes, Cobertura de Testes Modulares/Funcionais, etc. 
 
Por fim, as Métricas de Qualidade de Projeto são mais voltadas às características do 
projeto e de sua execução, e geralmente são montadas a partir da combinação das 
métricas de produto e processo (Ex: Número de Desenvolvedores, Ciclo de Vida, 
Custo, Cronograma, Produtividade, etc). Pessoal, existem muito mais métricas! No 
entanto, nosso estudo tem que ser objetivo e isso cobre 95% do que cai... 
 
 
 
 
 
 
 
 
 
 
 
2 É mais utilizado com hardware, mas pode ser também utilizado com software. 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 10 de 118 
 
 
Vamos falar agora sobre Métricas de Qualidade de Código-Fonte! A crescente 
adoção de programas de código aberto e de métodos ágeis pela indústria de 
software promove o código-fonte a um dos artefatos mais importante para se medir 
a qualidade de software. Com isso, as métricas de qualidade de código-fonte são 
mecanismos fundamentais para avaliação desses sistemas. 
 
A utilização de métricas de qualidade de código-fonte como critério para a 
avaliação da qualidade de um software é motivada por estudos que indicam ser 
viável analisar algumas das principais características para a aceitação de um 
software, tais como: flexibilidade, complexidade e manutenibilidade a partir do 
código-fonte. 
 
Você para e pergunta: o que tem um código-fonte de qualidade? Ora, um código-
fonte será muito mais lido do que escrito no decorrer de seu ciclo de vida 
(manutenção, reúso, etc). Dessa forma, nós podemos afirmar que um código-fonte 
de qualidade é Legibilidade, Testabilidade, Flexibilidade, Compatibilidade e 
Economicidade. 
 
 Legibilidade: o código (comentário, não) deve claramente declarar sua intenção. 
Se o leitor não consegue ver sentido no código, todos os outros esforços para 
melhorar a qualidade do software estão fadados ao fracasso. 
 
 Testabilidade: o código deve ser organizado de uma forma que facilite o teste 
de unidade. Isso apoia todos os esforços subsequentes (refatoração, correção de 
defeitos, revisão devido a alteração de especificações, etc). 
 
 Flexibilidade: dependência em relação a outros códigos devem ser minimizadas. 
Construir implementações hard-coded (i.e., fixas) sobre tamanhos e estruturas 
de dados, classes concretas, etc tornam o código difícil de reusar e adaptar. 
 
 Compatibilidade: o código deve cumprir com seus requisitos, funcionais ou não. 
Notem que uma discussão sobre se os requisitos implementados são os 
requisitos corretos não cabe aqui. 
 
 Economicidade: o código deve fazer uso razoável dos recursos do sistema: 
memória, processamento, etc. Devemos pensar sobre o retorno sobre 
investimento e requer uma reflexão sobre todos os recursos investidos. 
 
MÉTRICAS DE QUALIDADE DE CÓDIGO 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 11 de 118 
 
 
 (FCC - 2012 - - - Analista Judiciário - Análise de Sistemas) Métricas de 
software são formas de quantificar o esforço necessário para a construção de 
um sistema de software. 
 
Sobre métricas de software é correto afirmar que: 
 
a) um indicador é parte de uma métrica. 
b) custo, funcionalidade e número de erros são métricas indiretas. 
c) a métrica de pontos de função só pode ser calculada com o código terminado. 
d) linhas de código, esforço e memória são métricas diretas. 
e) métricas de produtividade indicam o quanto o software atende aos requisitos. 
 
Comentários: 
 
a) Na verdade, métricas são parte de um indicador; b) Não, são métricas diretas; c) 
Não, podem ser calculadas antes, durante e depois; d) Sim, são métricas diretas; e) 
Não, essas são métricas de qualidade. 
 
Gabarito: D 
 
 (FCC - 2011 - TCE-PR - Analista de Controle - Informática) Métricas de software 
podem ser divididas em medidas diretas e indiretas, sob o ponto de vista de 
medição, e em métricas de produtividade e de qualidade, sob o ponto de vista 
de aplicação. Nesse contexto, as métricas que se concentram na saída do 
processo de engenharia de software e as métricas que indicam o quanto o 
software atende aos requisitos definidos pelo usuário, podem ser classificadas, 
respectivamente, como métricas de: 
 
a) custo e de complexidade, em medidas indiretas. 
b) esforço e de confiabilidade, em medidas diretas. 
c) produtividade e de qualidade, em medidas indiretas. 
d) qualidade e de eficiência, em medidas diretas. 
e) velocidade de execução e técnica, em medidas diretas. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 12 de 118 
Comentários: 
 
Tratam-se das Métricas de Produtividade e Qualidade – ambas são medidas 
indiretas. 
 
Gabarito: C 
 
 (FCC - – TRF/5 - Analista de Controle - Informática) Medidas diretas e 
indiretas podem definir: 
 
a) qualidade e produtividade para o processo de engenharia de software, bem 
como para o próprio software. 
b) produtividade para o processo de engenharia de software e qualidade para o 
software. 
c) produtividade para o software e qualidade para o processo de engenharia de 
software, respectivamente. 
d) qualidade para o processo de engenharia de software e produtividade para o 
software. 
e) qualidade para o software e produtividade para o processo de engenharia de 
software, respectivamente. 
 
Comentários: 
 
 MétricasDiretas: também conhecidas como métricas básicas ou quantitativas, são 
aquelas que não dependem da medição de outros atributos, por exemplo: 
custo/esforço do desenvolvimento, linhas de código, velocidade de execução, 
quantidade de memória, número de erros, quantidade de defeitos. 
 
 Métricas Indiretas: também conhecidas como métricas derivadas ou qualitativas, 
são aquelas que dependem da medição de outros atributos. Por exemplo: 
produtividade, qualidade e técnicas (funcionalidade, complexidade, eficiência, 
confiabilidade, manutenibilidade, modularidade, portabilidade). 
 
Elas podem definir qualidade e produtividade para o processo de engenharia de 
software, bem como para o próprio software. 
 
Gabarito: A 
 
 (FCC - 2010 – MPE/RN - Analista de Controle - Informática) Considere: 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 13 de 118 
I. Métrica de confiabilidade. 
II. Atributo de usabilidade. 
 
Associe correta e respectivamente com as lacunas: 
 
1 - Probabilidade de falha sob demanda × ...... . 
2 - Velocidade de operação × ...... . 
3 - Facilidade de aprendizado × ...... . 
4 - Disponibilidade x ..... . 
 
 a) 1 2 3 4 
 I I I II 
 b) 1 2 3 4 
 I II II I 
 c) 1 2 3 4 
 I I II II 
 d) 1 2 3 4 
 II I I I 
 e) 1 2 3 4 
 II I II I 
 
Comentários: 
 
Probabilidade de falha sob demanda é uma métrica de confiabilidade; velocidade 
de operação é um atributo de usabilidade; facilidade de aprendizado é um atributo 
de usabilidade; disponibilidade é uma métrica de confiabilidade. 
 
Gabarito: B 
 
 (CESPE - 2013 - SERPRO - Analista - Desenvolvimento de Sistemas) As métricas 
externas fornecem aos usuários a possibilidade de medir a qualidade dos 
artefatos intermediários e de prever a qualidade do produto final. 
 
Comentários: 
 
 Métricas Estáticas ou Internas: são aquelas coletadas em representações do 
sistema como projeto, programa ou documentação – sem a necessidade da 
execução dos programas. Ajudam a mensurar a complexidade e a facilidade de 
compreensão e manutenção de um sistema de software. Permitem medir a 
qualidade dos artefatos intermediários e prever a qualidade do produto final. 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 14 de 118 
 
 Métricas Dinâmicas ou Externas: são aquelas coletadas durante a execução de um 
programa, a partir do comportamento do sistema ou do seu efeito no ambiente 
real de operação. Elas ajudam a avaliar a eficiência e a confiabilidade de um 
programa e quase sempre estão relacionadas com atributos da qualidade de 
software. 
 
Conforme vimos em aula, a questão está invertida. Para medir a qualidade dos 
artefatos intermediários, basta utilizar métricas internas e, não, externas. 
 
Gabarito: E 
 
 (CESPE - 2013 - SERPRO - Analista - Desenvolvimento de Sistemas) Métricas 
internas devem ser usadas para avaliar o comportamento do software, quando 
usado em situações específicas; predizer a qualidade real no uso; e avaliar e 
indicar se o produto satisfaz às verdadeiras necessidades durante a operação 
real pelo usuário. 
 
Comentários: 
 
 Métricas Estáticas ou Internas: são aquelas coletadas em representações do 
sistema como projeto, programa ou documentação – sem a necessidade da 
execução dos programas. Ajudam a mensurar a complexidade e a facilidade de 
compreensão e manutenção de um sistema de software. Permitem medir a 
qualidade dos artefatos intermediários e prever a qualidade do produto final. 
 
 Métricas Dinâmicas ou Externas: são aquelas coletadas durante a execução de um 
programa, a partir do comportamento do sistema ou do seu efeito no ambiente 
real de operação. Elas ajudam a avaliar a eficiência e a confiabilidade de um 
programa e quase sempre estão relacionadas com atributos da qualidade de 
software. 
 
Conforme vimos em aula, essa é uma função das métricas externas. 
 
Gabarito: E 
 
 (CESPE - 2013 – TRT/10ª - Analista Judiciário - Tecnologia da Informação) As 
métricas de software podem ser classificadas em medidas diretas ou 
quantitativas e medidas indiretas ou qualitativas. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 15 de 118 
Comentários: 
 
 Métricas Diretas: também conhecidas como métricas básicas ou quantitativas, são 
aquelas que não dependem da medição de outros atributos, por exemplo: 
custo/esforço do desenvolvimento, linhas de código, velocidade de execução, 
quantidade de memória, número de erros, quantidade de defeitos. 
 
 Métricas Indiretas: também conhecidas como métricas derivadas ou qualitativas, 
são aquelas que dependem da medição de outros atributos. Por exemplo: 
produtividade, qualidade e técnicas (funcionalidade, complexidade, eficiência, 
confiabilidade, manutenibilidade, modularidade, portabilidade). 
 
Conforme vimos em aula, a questão está perfeita! 
 
Gabarito: C 
 
 (CESPE - 2013 – TRT/10ª - Analista Judiciário - Tecnologia da Informação) 
Métricas quantitativas, normalmente, exigem análise e estão relacionadas com a 
funcionalidade, a qualidade, a complexidade e a manutenção do software. 
 
Comentários: 
 
 Métricas Diretas também conhecidas como métricas básicas ou quantitativas, são 
aquelas que não dependem da medição de outros atributos, por exemplo: 
custo/esforço do desenvolvimento, linhas de código, velocidade de execução, 
quantidade de memória, número de erros, quantidade de defeitos. 
 
 Métricas Indiretas: também conhecidas como métricas derivadas ou qualitativas, 
são aquelas que dependem da medição de outros atributos. Por exemplo: 
produtividade, qualidade e técnicas (funcionalidade, complexidade, eficiência, 
confiabilidade, manutenibilidade, modularidade, portabilidade). 
 
Conforme vimos em aula, a questão trata das métricas qualitativas. 
 
Gabarito: E 
 
 (CESPE - 2011 – TER/ES - Programação de Sistemas) As métricas orientadas a 
tamanho medem a funcionalidade entregue pela aplicação ao usuário como 
valor de normalização. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 16 de 118 
Comentários: 
 
 Métricas Orientadas a Tamanho: são aquelas baseadas no número de linhas de 
código produzidas, também conhecidas como Lines Of Code (LOC).3 
 
 Métricas Orientadas à Função: são aquelas baseadas na funcionalidade do 
software, tais como Análise de Pontos de Função. 
 
 Métricas Orientadas a Pessoas: são aquelas que indicam a forma como as pessoas 
devem desenvolver programas de computador. 
 
Conforme vimos em aula, a questão trata das métricas orientadas à função. 
 
Gabarito: E 
 
10. (CESPE - 2009 - ANTAQ - Analista Administrativo - Informática) Métricas de 
produto dinâmicas são coletadas por meio de medições realizadas em 
representações do sistema, como projeto, programa ou documentação, ao 
passo que métricas de produto estáticas são coletadas em programas em 
execução. 
 
Comentários: 
 
 Métricas Estáticas ou Internas: são aquelas coletadas em representações do 
sistema como projeto, programa ou documentação – sem a necessidade da 
execução dos programas. Ajudam a mensurar a complexidade e a facilidade de 
compreensão e manutenção de um sistema de software. Permitem medir a 
qualidade dos artefatos intermediários e prever a qualidade do produto final. 
 
 Métricas Dinâmicas ouExternas: são aquelas coletadas durante a execução de um 
programa, a partir do comportamento do sistema ou do seu efeito no ambiente 
real de operação. Elas ajudam a avaliar a eficiência e a confiabilidade de um 
programa e quase sempre estão relacionadas com atributos da qualidade de 
software. 
 
Conforme vimos em aula, a questão inverteu os conceitos. 
 
Gabarito: E 
 
3 Como medir Produtividade? KLOC/Pessoa-Mês. Como medir Qualidade? Erros/KLOC. Como medir Custo? 
$/KLOC. Como medir Documentação? Páginas/KLOC. 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 17 de 118 
 
11. (CESPE - - ANTAQ - Analista Administrativo - Informática) Dois tipos de 
métricas têm sido usados para estimativas de produtividade do desenvolvimento 
de software: as relacionadas a tamanho de algum resultado de uma atividade, 
como, por exemplo, linhas de código fonte entregues, número de instruções de 
código objeto, número de páginas de documentação, e as relacionadas a 
funções - funcionalidade geral do software entregue. A produtividade é expressa 
em termos de quantidade de funcionalidade útil produzida em um dado tempo, 
como, por exemplo, pontos por função, pontos por objeto. 
 
Comentários: 
 
 Métricas Orientadas a Tamanho: são aquelas baseadas no número de linhas de 
código produzidas, também conhecidas como Lines Of Code (LOC). 
 
 Métricas Orientadas à Função: são aquelas baseadas na funcionalidade do 
software, tais como Análise de Pontos de Função. 
 
 Métricas Orientadas a Pessoas: são aquelas que indicam a forma como as pessoas 
devem desenvolver programas de computador. 
 
Conforme vimos em aula, a questão está perfeita! 
 
Gabarito: C 
 
12. (CESPE - – TJDFT - Programação de Sistemas – D) As métricas de qualidade 
são, em geral, subjetivas, o que impossibilita a avaliação de um sistema por 
equipes diferentes. 
 
Comentários: 
 
Em geral, elas são objetivas (vimos várias fórmulas, inclusive). 
 
Gabarito: E 
 
13. (IADES - 2013 - EBSERH - Analista de Tecnologia da Informação - Teste e 
Qualidade) As métricas de software são parâmetros utilizados, para mensurar ou 
medir algo que se queira estimar, do ponto de vista da produção de software. 
Em relação às métricas de qualidade de software, assinale a alternativa correta. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 18 de 118 
a) É uma abordagem utilizada para definir o tempo gasto, em cada ponto de 
função. 
 
b) Oferece meios de mensurar o tempo gasto, para o desenvolvimento do 
software. 
 
c) Fornece informações sobre a quantidade de linhas de código. 
 
d) É uma abordagem utilizada, para reforçar os testes de aceitação. 
 
e) Oferece uma estimativa de quanto o software se adequa às exigências 
implícitas e explícitas do cliente. 
 
Comentários: 
 
a) Não, tempo gasto por ponto de função está mais para medição de produtividade 
do que de qualidade; b) Não, isso é para estimar o tempo gasto para desenvolver 
o software; c) Não, quantidade de linhas de código não servem para medir a 
qualidade de um software e vice-versa; d) Não existe essa relação; e) Perfeito, 
permite estimar a aderência aos requisitos do usuário. 
 
Gabarito: E 
 
14. (IADES - 2013 - EBSERH - Analista de Tecnologia da Informação - Teste e 
Qualidade) À qual modalidade de métrica pertencem a funcionalidade, a 
modularidade e a manutenibilidade? 
 
a) De qualidade. 
b) Técnicas. 
c) Produtividade. 
d) De estabilidade 
e) De vulnerabilidade. 
 
Comentários: 
 
Existem muitas classificações para métricas. Uma delas organiza as classes em 
Métricas de Produtividade (resultado do processo de desenvolvimento), Qualidade 
(Nível de Exigência/Satisfação) ou Técnicas (Funcionalidade, Manutenibilidade, 
Modularidade, etc). 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 19 de 118 
Gabarito: B 
 
15. (FUNCAB - 2010 - SEJUS-RO - Analista de Sistemas) É um exemplo de métrica 
de controle de software: 
 
a) a complexidade ciclomática de um módulo. 
b) o comprimento médio de identificadores em um programa. 
c) o número de atributos e operações associadas com objetos em um projeto. 
d) o tempo médio requerido para reparar defeitos relatados. 
e) o número de mensagens de erro. 
 
Comentários: 
 
Complexidade Ciclomática, comprimento médio de identificadores, número de 
atributos e operações associadas com objetos e número de mensagens de erro são 
todas métricas de predição, porque estão todas diretamente relacionadas com o 
produto de software. Já o tempo médio requerido para reparar defeitos é métrica 
de controle, porque estão diretamente relacionados com o processo de software. 
 
Alguns podem se confundir com a Complexidade Ciclomática! Ela auxilia a estimar 
o esforço necessário para construir um software ou fazer alterações nele, certo? Ela 
mostra todos os caminhos independentes de um código-fonte como em um fluxo 
de controle (mas não confundam com Métrica de Controle). É puramente uma 
Métrica de Produto. 
 
Gabarito: D 
 
16. (FEPESE - 2010 - UDESC - Analista de Sistemas) Considere as seguintes 
afirmativas relacionadas a métricas de software: 
 
1. A contagem de linhas de código (LOC) constitui um exemplo de métrica direta. 
 
2. A medida de qualidade expressa em erros/KLOC constitui um exemplo de 
métrica orientada a tamanho (KLOC = 1000.LOC). 
 
3. A medida de qualidade expressa em erros/KLOC constitui um exemplo de 
métrica indireta (KLOC = 1000.LOC). 
 
Assinale a alternativa que indica todas as afirmativas corretas. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 20 de 118 
a) É correta apenas a afirmativa 1. 
b) É correta apenas a afirmativa 3. 
c) São corretas apenas as afirmativas 1 e 2. 
d) São corretas apenas as afirmativas 2 e 3. 
e) São corretas as afirmativas 1, 2 e 3. 
 
Comentários: 
 
(1) Perfeito, é uma métrica direta; (2) Perfeito, deriva do tamanho (KLOC); (3) Perfeito, 
deriva de uma métrica de tamanho, logo é uma métrica indireta. 
 
Gabarito: E 
 
17. (CESPE - – MPOG/ATI - Analista de Sistemas) A aplicação de métricas 
estáticas de produto é comumente usada para se avaliar a complexidade de um 
software. 
 
Comentários: 
 
Métricas de Predição/Produto podem ser internas/estáticas ou externas/dinâmicas: 
 
 Métricas Estáticas ou Internas: são aquelas coletadas em representações do 
sistema como projeto, programa ou documentação – sem a necessidade da 
execução dos programas. Ajudam a mensurar a complexidade e a facilidade de 
compreensão e manutenção de um sistema de software. Permitem medir a 
qualidade dos artefatos intermediários e prever a qualidade do produto final. 
 
 Métricas Dinâmicas ou Externas: são aquelas coletadas durante a execução de um 
programa, a partir do comportamento do sistema ou do seu efeito no ambiente 
real de operação. Elas ajudam a avaliar a eficiência e a confiabilidade de um 
programa e quase sempre estão relacionadas com atributos da qualidade de 
software. 
 
Conforme vimos em aula, as métricas dinâmicas são aquelas coletadas durante a 
execução de um programa; as métricas estáticas são aquelas coletadas de 
representações do sistema como projeto, programa ou documentação. De fato, é 
comum utilizar métricas estáticas para avaliar a complexidade e manutenção de um 
software, por meio –por exemplo – de um Modelo de Design. 
 
Gabarito: C 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 21 de 118 
 
18. (CESPE - – MPOG/ATI - Analista de Sistemas) A métrica conhecida como 
resposta para uma classe relaciona o nível de complexidade de uma determinada 
classe com a quantidade de interações que ela faz com objetos de outras classes. 
 
Comentários: 
 
A banca foi muito, mas muito profunda nesse item! Eu confesso que nunca havia 
ouvido falar nessa métrica. Trata-se de uma métrica orientada a objetos, criada em 
1994, chamada Response for a Class (Resposta para uma Classe) e mede a 
complexidade de uma classe por meio da quantidade de métodos diferentes que 
potencialmente podem ser executados em resposta a uma mensagem recebida por 
um objeto dessa classe. 
 
Dessa forma, não se trata da quantidade de interações que ela faz com objetos – é 
mais específico: é a quantidade de métodos que podem ser executados em uma 
classe, em resposta a uma solicitação (invocação de um método). Quanto maior, 
mais difícil será de manter e testar a classe. Logo, se o objeto de uma Classe X 
recebe uma mensagem e ele pode potencialmente executar cinco métodos dentro 
dessa classe, então RFC = 5. 
 
Gabarito: E 
 
19. (CESPE - 2016 – ANAC - Analista de Sistemas) As métricas de software podem 
ser divididas em duas categorias: medidas diretas e indiretas. Podemos 
considerar como medidas diretas do processo de engenharia de software o 
esforço aplicado ao desenvolvimento e à manutenção do software, bem como 
a (o): 
 
a) eficiência. 
b) qualidade. 
c) confiabilidade. 
d) manutenibilidade. 
e) custo. 
 
Comentários: 
 
 Métricas Diretas: também conhecidas como básicas, quantitativas ou primitivas, 
são aquelas que não dependem da medição de outros atributos, por exemplo: 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 22 de 118 
custo/esforço do desenvolvimento, linhas de código, velocidade de execução, 
quantidade de memória, número de erros, quantidade de defeitos. 
 
 Métricas Indiretas: também conhecidas como qualitativas ou derivadas, são 
aquelas que dependem da medição de outros atributos. Por exemplo: 
produtividade, qualidade e técnicas (funcionalidade, complexidade, eficiência, 
confiabilidade, manutenibilidade, modularidade, portabilidade). 
 
Conforme vimos em aula, a medida direta é o custo de desenvolvimento. 
 
Gabarito: E 
 
ACERTEI ERREI 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 23 de 118 
 ANÁLISE DE PONTOS DE FUNÇÃO 
 
Uma pequena introdução: no ano de 1979, Allan Albrecht – pesquisador da IBM – 
estudava a produtividade para projetos de software desenvolvidos por uma unidade 
de serviços da IBM. Como nem todos os projetos usavam a mesma linguagem de 
programação, ele buscou elaborar uma medida que observasse apenas aspectos 
externos do software, i.e., suas funcionalidades. 
 
A esta medida baseada na visão do usuário e independente da linguagem de 
programação ou de qualquer outro aspecto relacionado à implementação do 
software, ele chamou de Pontos de Função. Ao fim do ano, ele publicou o resultado 
desse estudo, despertando o interesse de outras empresas e o seu uso começou a 
se difundir nos anos seguintes por todo o mundo. 
 
Com a popularização da técnica, criou-se o International Function Point Users Group 
(IFPUG), com o objetivo de promover o uso da técnica de pontos de função 
mundialmente e manter o Counting Practices Manual (CPM), que é o manual que 
orienta como se faz a contagem de pontos de função e que serve como uma 
bibliografia recomendadíssima para vocês. 
 
Portanto, a Análise de Pontos de Função (APF) é uma técnica que permite medir as 
funcionalidades ou tamanho funcional de um software, independente de tecnologia 
e sob o ponto de vista dos requisitos funcionais do usuário. Pessoal, essa definição 
é importantíssima! Guardem-na, pois ela é a base de tudo que veremos daqui em 
diante e pode, eventualmente, ser útil na prova discursiva. 
 
Vamos analisar essa definição: ele diz que a APF mede as funcionalidades! Mas, 
professor, o que é uma funcionalidade? É qualquer coisa que o usuário deseja que 
seu aplicativo execute, por exemplo: dadas diversas medidas corporais, calcular a 
porcentagem de gordura. Ok, e como se mede o tamanho de uma funcionalidade 
como essa? Veremos! 
 
De fato, não é possível medir uma funcionalidade diretamente! Ou vocês conhecem 
alguma unidade de medida de funcionalidade? Portanto, ela deve ser derivada 
indiretamente de outras medidas diretas realizadas empiricamente. Ahn? Viajei 
agora, professor! Vamos supor que alguém diga que essa funcionalidade equivale a 
15 pontos de função. O que isso significa, professor? 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 24 de 118 
Diversos especialistas escolheram algumas características do aplicativo e 
quantificaram-nas a partir de suas experiências de vida com outros projetos de 
software. Portanto, a partir desses valores que foram dados às características, criou-
se uma unidade de medida – chamada Ponto de Função (PF) – e pôde-se medir as 
funcionalidades. Vou dar mais um exemplo para deixar isso bem claro! 
 
Vamos supor que o Governo Federal deseje comprar um carro para um 
determinado órgão. Existe alguma medida de carro? Por exemplo: Pálio vale 50 ou 
Gol vale 100? Não! Portanto, o governo poderia criar uma unidade de medida 
chamada Pontos de Carros (PC) por meio de outras medidas indiretas: valor, 
quantidade de cavalos de potência, quantidade de válvulas, consumo médio, etc. 
 
Assim, através da experiência de pessoas qualificadas, poder-se-ia atribuir valores a 
essas outras medidas. Ex: se o carro custar mais de 50 mil reais, equivale a 10 PCs, 
caso contrário equivale a 7 PCs; se tiver mais de 200 cavalos-vapor, equivale a 10 
PCs, caso contrário equivale a 5 PCs. Faz-se isso para cada característica escolhida, 
soma-se tudo e chega-se ao total de “pontos de carros”. 
 
Com software, acontece coisa parecida. Foram escolhidas cinco características (que 
veremos mais à frente) e diversos especialistas, baseados em suas vastas 
experiências com outros projetos, quantificaram-nas de acordo com sua 
complexidade (do software e, não, do desenvolvimento). Assim, hoje em dia, pode-
se medir a funcionalidade de um aplicativo. 
 
Em seguida, a definição diz que a APF é independente de tecnologia, linguagem de 
programação, ambiente de desenvolvimento, entre outros. Portanto, ele busca 
medir o que software faz e, não, como ele foi construído. Por fim, a definição diz 
que ele mede as funcionalidades requisitadas pelo usuário. Não caiam em nenhuma 
pegadinha: é sempre sob o ponto de vista do usuário. 
 
Na Análise de Pontos de Função, a produtividade é expressa como o número de 
pontos de função implementados por pessoa-mês. Galera, entendam que um Ponto 
de Função não é uma característica única, tanto que ele pode ser calculado por 
meio da combinação de várias medições ou estimativas diferentes – não esquentem, 
nós veremos tudo isso mais à frente. 
 
Symons observa que a natureza subjetiva da estimativa de complexidade significa 
que a contagem de pontos de função de um programa depende do estimador. 
Pessoas diferentes podem ter noções diferentes decomplexidade. Existem, 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 25 de 118 
portanto, grandes variações na contagem de pontos de função dependendo do 
julgamento do estimador e do tipo do sistema a ser desenvolvido. 
 
Além disso, os pontos de função são voltados aos sistemas de processamento de 
dados dominados por operações de entrada e saída. É mais difícil estimar a 
contagem de pontos de função para sistemas orientados a eventos. Por essa razão, 
algumas pessoas pensam que a contagem de pontos de função não é uma maneira 
útil para medir a produtividade de software. 
 
Contudo, os usuários de pontos de função argumentam que, apesar de suas 
imperfeições, eles são eficazes em situações práticas. Galera, esse é um assunto 
muito polêmico! Infelizmente, não há uma unanimidade... há quem diga que a 
estimativa do tamanho do software é subjetiva por conta do julgamento da 
complexidade, no entanto há quem diga que é uma estimativa objetiva! 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 26 de 118 
 
 
As organizações usam pontos de função com diferentes propósitos. Podem-se 
destacar vários benefícios da aplicação da APF nas organizações: 
 
 Funciona como uma ferramenta para determinar o tamanho de um pacote 
adquirido, através da contagem de todas as funções incluídas (pode auxiliar no 
momento da venda de um sistema de software) e suporta a análise de 
produtividade e qualidade, seja diretamente ou em conjunto com outras 
métricas como esforço, defeitos e custo. 
 
 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 utilizadas, a produtividade e o custo da própria equipe, 
possível analisar se vale a pena comprar ou fabricar. 
 
 Apoia o gerenciamento de escopo de projetos. Um desafio de todo gerente de 
projetos é controlar o aumento do escopo. Ao realizar estimativas e medições 
em cada fase do seu ciclo de vida, é possível determinar se os requisitos 
funcionais cresceram ou diminuíram; e se esta variação corresponde a novos 
requisitos ou aos existentes e que foram apenas mais detalhados. 
 
 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 – basta lembrar que a contagem é baseada em requisitos do usuário. 
 
 Um meio de estimar custo e recursos para o desenvolvimento e manutenção de 
software. Através da realização de uma contagem ou estimativa de pontos de 
função no início do ciclo de vida de um projeto, é possível determinar seu 
tamanho funcional. Esta medida pode ser então utilizada como entrada para 
diversos modelos de estimativa de esforço, prazo e custo. 
 
 Uma ferramenta para fundamentar a negociação de contratos. Pode-se utilizar 
pontos de função para gerar diversos indicadores de níveis de serviço em 
contratos de desenvolvimento e manutenção de sistemas. Além disso, permite o 
estabelecimento de contratos a preço unitário, onde a unidade representa um 
bem tangível para o cliente – reduzindo riscos. 
BENEFÍCIOS DA ANÁLISE DE PONTOS DE FUNÇÃO 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 27 de 118 
 
 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 imenso repositório de dados de projetos de 
software que permitem a realização de benchmarking com projetos similares do 
mercado e uma boa base de comparação. 
 
 
 
 
 
 
 
 
Pessoal, a APF pode ser aplicada em diversos domínios funcionais ou domínio de 
informação. O que é isso? É uma área de interesse (Ex: sistema de uma universidade, 
hospital, banco, etc). Ademais, a produtividade – diferente da funcionalidade – é 
dependente de tecnologia. Basta pensar que programar em Delphi é mais produtivo 
do que em Java que é mais produtivo do que em C. 
 
Professor, como uma organização consegue saber qual deve ser a produtividade 
esperada para um projeto que ainda irá se iniciar? Bem, isso pode ocorrer de duas 
maneiras: ela pode manter um repositório privado com dados sobre seus projetos 
anteriores ou ela pode utilizar um repositório público com dados de diversos 
projetos para realizar essas estimativas. 
 
O repositório público mais conhecido se chama International Software 
Benchmarking Standards Group (ISBSG). Ele contém mais de 6.000 projetos de 
diferentes tamanhos, complexidades, linguagens de programação, domínios de 
informação, entre outros. No entanto, deve-se considerar o contexto de como os 
números foram obtidos e compa -los com os da organização. 
 
 
 
 
 
 
 
 
 
IMPORTANTE 
 
A Análise de Pontos de Função não mede diretamente esforço, produtividade, custo, qualidade, 
escopo, etc. No entanto, ela pode ser usada em conjunto com outras grandezas e dados 
históricos da organização para medir essas variáveis. Por exemplo: determinado 
programador desenvolve uma funcionalidade específica em 10 Horas/PF. 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 28 de 118 
 
 
Pronto, vamos avançar nosso estudo! Anteriormente, eu disse que, para medir uma 
funcionalidade, era necessário quantificar algumas características do aplicativo de 
acordo com sua complexidade. Quais são essas características? Elas são: Arquivo 
Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Saída 
Externa (SE) e Consulta Externa (CE). Vamos detalhá-los: 
 
- Arquivo Lógico Interno (ALI): grupo de dados logicamente relacionados ou 
informações de controle cuja manutenção é feita pela própria aplicação. Sua função 
é armazenar dados mantidos dentro da fronteira da aplicação através dos processos 
da aplicação. Os ALI contribuem para o cálculo de pontos de função com base na 
quantidade e complexidade funcional relativa. Baseia-se em requisitos lógicos dos 
usuários e são independentes da implementação ou meios de armazenamento. 
 
Exemplos de ALI: dados da aplicação (arquivos mestres, como cadastro de clientes); 
arquivos de dados de segurança da aplicação; arquivos de dados de auditoria; 
arquivos de mensagem de auxílio; arquivos de mensagens de erro; arquivo de cópia 
de segurança (só se para atender requisitos da aplicação; arquivo que sofra 
manutenção por mais de uma aplicação. 
 
Não-Exemplos de ALI: arquivos temporários; Arquivos de trabalho; arquivos de 
classificação; arquivos de cópia de segurança requerido pelo CPD; arquivos 
introduzidos somente por causa da tecnologia usada (Ex: arquivos de parâmetro 
para um software WFL, JCL, entre outros); operações de junção e projeção; arquivos 
de índices alternativos. 
 
- Arquivo de Interface Externa (AIE): grupo de dados logicamente relacionados ou 
informações de controle, referenciados na aplicação para fins de recuperação de 
dados cuja manutenção é feita por outra aplicação. Os dados são armazenados fora 
da fronteira da aplicação. Um AIE de uma aplicação sempre serácontado como um 
ALI na aplicação de origem. Cada AIE é classificado por sua complexidade funcional 
relativa, que é baseada no número de registros lógicos e de itens de dados. 
 
Exemplos de AIE: arquivos de mensagens de auxílio; arquivos de mensagens de erro. 
Não-Exemplos de AIE: dados recebidos de outra aplicação usados para adicionar, 
alterar ou remover dados em um ALI; dados cuja manutenção é feita pela aplicação 
que está sendo avaliada, mas que são acessados e utilizados por outra aplicação; 
dados formatados e processados para uso por outra aplicação. 
 
COMPONENTES DOS PONTOS DE FUNÇÃO 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 29 de 118 
- Entrada Externa (EE): processo elementar que processa dados ou informações de 
controle recebidos de fora da fronteira da aplicação e cujo objetivo é manter um ou 
mais ALIs e/ou alterar o comportamento do sistema. Assim, uma Entrada Externa 
provoca uma inclusão, exclusão e/ou alteração nos dados do ALI. Cada Entrada 
Externa se origina de um usuário ou é transmitida de outra aplicação e fornece 
dados distintos orientados à aplicação do software ou informação de controle. 
 
Exemplos de Entrada Externa: operações de inclusões e alterações de registros em 
arquivos da aplicação, janelas que permitem adicionar, excluir e alterar registros em 
arquivos de dados. Não-Exemplos de Entrada Externa: menus, telas de login, telas 
de filtro de relatórios e consultas, múltiplos métodos de se executar uma mesma 
lógica de entrada, entre outros. 
 
- Saída Externa (SE): processo elementar que envia dados ou informações de 
controle para fora da fronteira da aplicação. Seu objetivo é exibir informações 
recuperadas através de processamento lógico, i.e., que envolva cálculos ou criação 
de dados derivados e não apenas uma simples recuperação de dados. Uma Saída 
Externa pode manter um ALI ou alterar o comportamento do sistema. Representam 
atividades do sistema que transforma dados dos ALI e geram resultados ao usuário. 
 
Exemplos de Saída Externa: Dados transferidos para outra aplicação; relatórios; 
relatórios online; formatos gráficos; gerador de relatórios. Não-Exemplos de Saída 
Externa: telas de ajuda; literais; data, hora, controles de paginação, etc; relatórios 
múltiplos com a mesma lógica e formato; relatórios criados pelo usuário de forma 
dinâmica pelo usuário usando uma linguagem como SQL. 
 
- Consulta Externa (CE): representa a necessidade de processamento de consultas 
da aplicação sendo uma combinação de entrada/saída de dados onde uma entrada 
de dados causa uma recuperação e uma saída correspondente. A lógica de 
processamento não deve conter cálculo matemático ou criar dados derivados ou 
atualizar nenhum ALI. Pode ser definida como uma entrada online que resulta na 
geração de alguma resposta imediata do software sob a forma de uma saída online. 
 
Exemplos de Consulta Externa: telas de logon, telas de help, telas de 
alteração/remoção que mostram o que será alterado ou removido antes de sua 
efetivação; tela de menus que permitem informar parâmetros para a consulta na 
tela escolhida. Não-Exemplos de Consulta Externa: dados derivados; documentação 
online; sistema de teste; sistemas tutoriais; relatórios e consultas (c/ cálculo). 
 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 30 de 118 
 
 
 
 
 
 
 
 
Eu gostaria de fazer algumas observações sobre o que vimos acima. Primeiro, 
gostaria de destacar mais uma vez que os Arquivos de Interface Externa (AIE) de 
uma aplicação são sempre contados como um Arquivo Lógico Interno (ALI) na 
aplicação de origem. Em outras palavras, se um ALI é um AIE de outra aplicação, 
cont - os Dados Elementares Referenciados apenas uma vez. 
 
Além disso, precisamos ver alguns conceitos importantes! Quando se fala acima em 
“informações de controle”, trata-se dos dados que influenciam um processo 
elementar da aplicação sendo contada. Especifica o que, quando ou como os dados 
devem ser processados, e são utilizados pela aplicação para garantir aderência com 
os requisitos funcionais especificados pelo usuário. 
 
Quando se fala em “identificável pelo usuário”, trata-se de requisitos definidos para 
processos e/ou grupos de dados que foram acordados e entendidos tanto pelos 
usuários quanto pelos desenvolvedores de software (Ex: 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). 
 
Por fim, quando se fala em “mantido”, trata-se da habilidade de incluir, modificar ou 
excluir dados a partir de um processo elementar (Ex: Inclusão, Modificação, Exclusão, 
Carga Inicial, Revisão, Atualização, Atribuição, Criação, etc). Um processo elementar 
pode ser conceituado como a menor atividade capaz de produzir resultados 
significativos para o usuário. 
 
Ele deve ser completo em si mesmo, independente e deixar a aplicação em um 
estado consistente. Bem, podemos dividir essas cinco funções em dois grupos: 
 
IMPORTANTE 
 
Os exemplos citados foram retirados do próprio IFPUG. Evidentemente, eles dependem - antes 
de tudo - da visão do usuário. Além disso, eles estão sujeitos ao contexto em que estão 
inseridos. Não os encarem como uma certeza absoluta. 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 31 de 118 
Funções do Tipo Dado: representam requisitos de 
armazenamento do usuário. 
o ALI e AIE. 
 
Funções do Tipo Transação: representam 
requisitos de processamento do usuário. 
o EE, CE e SE. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 32 de 118 
 
 
O procedimento de contagem de pontos de função segue cinco etapas, 
apresentadas a seguir: 
 
 
 
 Determinar o Tipo de Contagem 
 
O procedimento de contagem de pontos de função de um aplicativo que ainda será 
desenvolvido é diferente do procedimento de contagem de um aplicativo pronto. 
Bem como o procedimento de contagem de um aplicativo pronto difere do 
procedimento de contagem de manutenção de outro aplicativo. Galera, existem três 
tipos de contagem: 
 
 Projeto de Desenvolvimento: mede a funcionalidade fornecida aos usuários finais 
do software para a primeira instalação da aplicação. Inclui as funcionalidades da 
contagem inicial da aplicação e as funcionalidades requeridas para conversão de 
dados (além do fator de ajuste). Pessoal, isso é uma estimativa, na medida em 
que pode haver mudanças no decorrer do projeto. 
 
 Projeto de Melhoria4: mede as modificações realizadas para aplicações 
existentes. É também referenciada como Projeto de Manutenção e inclui as 
funcionalidades fornecidas aos usuários através de adições, alterações, exclusões 
e conversões de funções na aplicação. As manutenções podem ser somente 
evolutivas e, não, corretivas e preventivas. 
 
 Projeto de Aplicação: mede uma aplicação instalada e em pleno funcionamento. 
É também referenciada como contagem de baseline ou contagem instalada e 
avalia as funcionalidades correntes providas aos usuários finais da aplicação. Ela 
não é estimativa, é bastante precisa, na medida em que o aplicativo já está 
pronto e em funcionamento. 
 
 Determinar o Escopo e Fronteira 
 
4 Nem todas as manutenções em um softwaresão passíveis de serem medidas com a APF ʹ apenas as 
manutenções que alteram os requisitos funcionais de um software. Neste caso, o IFPUG usa o termo "melhoria" 
em vez de "manutenção", exatamente para deixar destacada que a melhoria não é qualquer manutenção. No 
conceito do IFPUG a melhoria mede todas as funções que serão adicionadas, alteradas ou excluídas da aplicação, 
bem como as eventuais funções de conversão de dados. 
Determinar o 
Tipo de 
Contagem
Determinar 
Escopo e 
Fronteira
Calcular Pontos 
de Função Não-
ajustados
Calcular Fator 
de Ajuste
Calcular Pontos 
de Função 
Ajustados
ETAPAS DO PROCEDIMENTO DE CONTAGEM 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 33 de 118 
 
Após determinar o tipo de contagem, deve-se determinar a fronteira da aplicação. 
Ela indica a separação entre o projeto que está sendo medido e as aplicações 
externas ao domínio do usuário. É através dela que se torna possível definir quais 
funcionalidades serão incluídas no processo de contagem dos pontos de função, 
isto é, o escopo do sistema. 
 
Pessoal, quem decide o que incluir na contagem é o usuário, sempre o usuário, 
completamente baseada no usuário. Ele pode escolher todas as funcionalidades 
disponíveis ou apenas parte delas. Lembremos que a fronteira é independente de 
implementações tecnológicas e que só serão considerados no escopo os requisitos 
funcionais do usuário. Requisitos não-funcionais serão ignorados. 
 
 
 
 
 
 
 Calcular Pontos de Função Não-ajustados 
 
 
 
No cálculo de pontos de função não-ajustados, medem-se as funções de dados e 
as funções de transação. O Arquivo Lógico Interno armazena dados mantidos pela 
IMPORTANTE 
 
Essa fase é bastante importante, tendo em vista que – caso haja um erro conceitual de 
fronteira da aplicação – pode-se confundir uma AIE/ALI e vice-versa. Portanto, cuidado! 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 34 de 118 
aplicação que está sendo medida, já o Arquivo de Interface Externa armazena dados 
referenciados pela aplicação que está sendo medida. Lembrem-se de que um AIE 
de uma aplicação é sempre ALI de outra aplicação! 
 
No exemplo da imagem acima, tem-se um usuário (Preto) interagindo com um 
sistema (Verde) e esse sistema interagindo com outro sistema (Cinza). A Entrada 
Externa ocorre quando um usuário inclui uma nota fiscal e o sistema processa a 
informação – alterando o comportamento da aplicação ou atualizando, editando, 
modificando, excluindo dados de um Arquivo Lógico Interno. 
 
A Consulta Externa ocorre quando um usuário requisita uma lista de notas fiscais, o 
sistema apenas recupera os dados sem fazer qualquer tipo de processamento ou 
cálculos matemáticos. A Saída Externa ocorre quando um usuário requisita um 
relatório sumarizado de notas fiscais, o sistema processa uma informação – fazendo 
algum tipo de cálculo matemático – e retorna para o usuário. 
 
Agora eu preciso da atenção de vocês, porque essa parte é meio chatinha de 
entender! Vejam bem: Todos os ALI/AIE são igualmente complexos? Não. Então, 
como se mede sua complexidade? Pela quantidade de Dados Elementares 
Referenciados (DER) e Registros Lógicos Referenciados (RLR). O que diabos é isso, 
professor? Calma, porque eu vou explicar :-) 
 
DER é um atributo único, reconhecido pelo usuário e não repetido. Em outras 
palavras, são campos de uma tabela ou atributos de um objeto. Por exemplo: na 
modelagem orientada a objetos, pode-se modelar um objeto Pessoa com diversos 
atributos (Ex: Nome, Idade, Endereço, Telefone, e-mail). Cada atributo desses é um 
Dado Elementar Referenciado! Simples, não? 
 
E o que é o RLR? É um subgrupo de dados elementares referenciados, reconhecido 
pelos usuários dentro de um ALI/AIE. Pode traduzir, professor? Sim. Utilizando o 
exemplo anterior: nós consideramos o atributo Endereço como elementar, mas nós 
poderíamos ter considerado como um subgrupo de dados que pode ser dividido 
em Rua, Número, Cidade e CEP. 
 
Nesse caso, o atributo Endereço deixa de ser um DER para se tornar um RLR. E 
quem decide isso, professor? Ora, o usuário, é sempre o usuário! De todo modo, 
vocês percebem que há um subgrupo de dados bastante óbvio no exemplo? Quem 
é? Ora, o próprio objeto Pessoa é um subgrupo de dados. Portanto, toda função de 
dados tem pelo menos um RLR – ela mesma. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 35 de 118 
As regras de contagem de um Arquivo Lógico Referenciado (RLR) são: (1) caso não 
haja subgrupo de informações (referentes a outro ALI), contar um RLR para cada 
ALI/AIE; (2) contar um RLR para cada subgrupo de dados de um ALI/AIE 
independentemente de ser o subgrupo opcional ou mandatório. Professor, o que 
seria um subgrupo opcional ou mandatório? Vamos ver... 
 
 Mandatórios: são subgrupos de dados que o usuário deve usar pelo menos uma 
vez durante o processo elementar de criação de um item num AIE. 
 Opcionais: são subgrupos de dados que o usuário tema opção de usar ou não 
durante o processo elementar de criação de um item em um AIE. 
 
Agora alguns sinônimos: há provas que chamam Registro Lógico Referenciado de 
Item de Registro. Há, também, provas que chamam Dados Elementares 
Referenciados de Item de Dados. Portanto, fiquem atentos! Eu disse para vocês que 
o ALI/AIE são medidos por meio do DER/RLR. A complexidade de cada função de 
dados é determinada de acordo com a tabela: 
 
 DER 
 1 – 19 20 – 50 > 50 
 
RLR 
1 Baixa Baixa Média 
2 – 5 Baixa Média Alta 
> 5 Média Alta Alta 
 
Como se interpreta essa tabela? Caso seu arquivo lógico tenha 3 RLRs e 80 DERs, ele 
terá complexidade alta. Ok, mas para que eu quero saber qual a complexidade dele, 
professor? Porque você usará esse resultado em outra tabela, que vai te dizer qual 
o tamanho funcional do seu ALI/AIE por meio dessa complexidade, como pode ser 
visto na tabela abaixo: 
 
 TIPO DADOS 
 ALI AIE 
Complexidade 
Funcional 
Baixa 7 5 
Média 10 7 
Alta 15 10 
 
Pronto, expliquei para vocês como funciona com o cálculo de complexidade das 
funções de dados. Agora vamos entender como funciona o de funções de 
transação. Vocês acham que CE/EE/SE são igualmente complexos? Não. Então, como 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 36 de 118 
se mede sua complexidade? Pela quantidade de Dados Elementares Referenciados 
(DER) e a novidade: Arquivos Lógicos Referenciados (ALR). 
 
Nós já vimos o DER! No entanto, aqui ele tem outro contexto: considera-se como o 
dado que atravessa a fronteira durante o processamento da transação. Já o ALR é 
um ALI/AIE que foi acessado por uma função de transação. Em outras palavras, 
quanto mais ALI/AIE acessados por uma função de transação, maior a complexidade 
do ALR. A complexidade da EE/SE/CE é determinada a seguir: 
 
EE DER 
 1 – 4 5 – 15 > 15 
 
ALR 
0 – 1 Baixa Baixa Média 
2 Baixa Média Alta 
> 2 Média Alta Alta 
 
SE / CE DER 
 1 – 5 6 – 19 > 19 
 
ALR 
0 – 1 Baixa Baixa Média 
2 – 3 Baixa Média Alta 
> 3 Média Alta Alta 
 
Como interpreta essa tabela? Caso seu arquivo lógico acesse 1 ALRs e tenha 4 DERs, 
ele terá complexidade baixa. Ok, mas para que eu quero saber qual a complexidade 
dele, professor? Porque você usará esse resultado em outra tabela, que vai dizer qual 
o tamanho funcional do seu CE/SE/EE por meio dessa complexidade, como podeser visto na tabela abaixo: 
 
 TIPO TRANSAÇÃO 
 EE SE CE 
Complexidade 
Funcional 
Baixa 3 4 3 
Média 4 5 4 
Alta 6 7 6 
 
Pessoal, vamos juntar tudo isso em uma única tabela? Lá vai: 
 
 Complexidade Funcional 
 
 
 Simples Média Complexa 
CE 3 4 6 
EE 3 4 6 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 37 de 118 
Funções de 
Dados/Transação 
SE 4 5 7 
AIE 5 7 10 
ALI 7 10 15 
 
Pessoal, nenhuma das outras tabelas precisa ser decorada, exceto essa última! Essa 
realmente não dá para fugir! Para facilitar, basta pensar que a Consulta Externa é, 
de fato, a mais simples! Por que? Porque ela é não realiza nenhum tipo de 
processamento, assim como a Entrada Externa! Já a Saída Externa faz cálculos 
matemáticos, portanto é mais complexa. 
 
Galeeeeeeeera, vocês têm que decorar isso! Ora, isso 
é realmente importante para o entendimento geral de 
vocês sobre esse assunto? Claro que não! Isso é apenas 
um detalhe – vocês têm que decorar isso pelo simples 
fato de que isso cai muito em prova! Eu sei, é ridículo 
cobrar um decoreba desse! Mas o que eu posso fazer? 
Infelizmente isso cai demais – principalmente na FCC, 
apesar de ter visto isso em diversas bancas. Por favor, 
não deixem isso passar! É apenas uma tabela, ok?! 
 
Vamos falar de alguns detalhes que eu nunca havia visto cair em provas até esse 
ano! Após todos esses cálculos, temos que considerar algumas coisas. Imaginem 
que o Governo Federal contratou uma empresa para fabricar um aplicativo e 
estimou que ele teria 1000 PFs. Porém, no momento de implantar o software, seria 
necessário fazer algumas conversões de dados. 
 
Como assim, professor? Bem, pode ser que tenha que se fazer alguma integração 
com sistemas existentes, sistemas legados ou outras adaptações. E isso tem um 
custo para a empresa fabricante do sistema, mesmo que não seja algo efetivamente 
para o software encomendado. Essas funções tem o nome de Funções de 
Conversão e são descartadas logo após a implantação. 
 
O que eu quero dizer com isso tudo? Bem, esse custo é repassado para o Governo 
Federal. Então, em Projetos de Desenvolvimento, há uma fórmula para calcular o 
total de pontos de função: P = ADD + CFP. DPF é o tamanho das funções de 
desenvolvimento; ADD é o tamanho das funções a serem entregues pelo projeto de 
desenvolvimento; e CFP é o tamanho das funções de conversão5. 
 
5 Funções de conversão são aquelas funcionalidades providas apenas na instalação do sistema para converter 
dados ou proporcionar outros requisitos estabelecidos pelo usuário e necessários à conversão. 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 38 de 118 
 
Nos casos de Projeto de Aplicação, não há o que se discutir: AFP = ADD. Em outras 
palavras, o tamanho total das funções de aplicação é equivalente a quantidade 
existente no momento da contagem, sem nenhuma função de conversão, porque 
o aplicativo já está implantado. Por fim, em Projetos de Melhoria, a fórmula é um 
pouco mais complicada: EFP = ADD + CHGA + CFP + DEL. 
 
Pontos de Função de Melhoria é equivalente ao tamanho das funções adicionadas, 
mais o tamanho das funções alteradas, mais o tamanho das funções de conversão, 
mais o tamanho das funções excluídas. Bem pessoal... não é tão complicado, certo?! 
;) Vamos agora para a penúltima fase do processo de contagem de pontos de 
função: Cálculo do Fator de Ajuste! 
 
SIGLAS SIGNIFICADO 
DFP Development Function Points 
CFP Convertion Function Points 
AFP Application Function Points 
EFP Enhancement Function Points 
ADD Additional (Function Point) 
DEL Deleted (Function Points) 
CHGA Changed (Function Points) After Enhancements 
 
 Calcular Fator de Ajuste 
 
Nesta etapa, calculamos o fator de ajuste. O que é isso? Ora, há certas características 
em um software que devem ser consideradas para se obter maior precisão sobre o 
cálculo do tamanho funcional de um software. Essas características são quantificadas 
de modo a obter um número chamado Fator de Ajuste (FA), que tornará o tamanho 
funcional do sistema mais exato. 
 
Até a Etapa 3, nós calculamos o tamanho funcional do software sem considerar 
absolutamente nenhum aspecto tecnológico, gerando distorções graves. No 
entanto, sabe-se que eles influenciam bastante no cálculo do tamanho funcional de 
um aplicati . Ok, professor! Mas que características são essas que influenciam tanto? 
São 14 características gerais do sistema: 
 
1. COMUNICAÇÃO DE DADOS 8. ATUALIZAÇÃO ONLINE 
2. PROCESSAMENTO DISTRIBUÍDO 9. PROCESSAMENTO COMPLEXO 
3. PERFORMANCE 10. REUSABILIDADE 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 39 de 118 
4. CONFIGURAÇÃO DO EQUIPAMENTO 11. FACILIDADE DE IMPLANTAÇÃO 
5. VOLUME DE TRANSAÇÕES 12. FACILIDADE OPERACIONAL 
6. ENTRADA DE DADOS ONLINE 13. MÚLTIPLOS LOCAIS 
7. INTERFACE COM O USUÁRIO 14. FACILIDADE DE MUDANÇAS 
 
Vamos ver agora o que significa cada uma dessas características: 
 
COMUNICAÇÃO 
DE DADOS 
Descreve o grau pelo qual 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. 
 
PROCESSAMENTO 
DISTRIBUÍDO 
Descreve o grau pelo qual a aplicação transfere dados entre seus 
componentes. 
 
 
 
PERFORMANCE 
Descreve o grau pelo qual considerações de tempo de resposta e 
performance de throughput 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 o projeto, 
desenvolvimento, instalação e suporte da aplicação. 
CONFIGURAÇÃO 
DO 
EQUIPAMENTO 
Descreve o grau pelo qual as restrições de recursos computacionais 
influenciam o desenvolvimento da aplicação. Uma configuração 
operacional altamente utilizada, necessitando de considerações 
especiais de projeto, é uma característica da aplicação. Exemplo: usuário 
deseja executar a aplicação em um equipamento já existente e que será 
altamente utilizado. 
VOLUME DE 
TRANSAÇÕES 
Descreve em que nível o alto volume de transações de negócio influencia 
o projeto, desenvolvimento, instalação e suporte da aplicação. 
 
 
 
ENTRADA DE 
DADOS ONLINE 
Descreve o grau pelo qual dados são informados pela execução de 
transações interativas. 
 
 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 07 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 40 de 118 
INTERFACE COM 
O USUÁRIO 
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. 
 
ATUALIZAÇÃO 
ONLINE 
Descreve o grau pelo qual arquivos lógicos internos são atualizados de 
forma on-line. 
 
 
 
PROCESSAMENTO 
COMPLEXO 
Descreve em que nível o processamento lógico ou matemático influencia 
o desenvolvimento da aplicação. 
 
 
 
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. 
 
 
FACILIDADE DE 
IMPLANTAÇÃO 
Descreve em que nível a conversão de ambientes preexistentes 
influencia o desenvolvimento da aplicação. Um plano e/ou ferramentas