Apostila Curso APF Basico EaD Jul 2018

Curso Básico de
Análise de Pontos de Função
Apostila
Julho/2018
Autora: Claudia Hazan
1
Sumário
MÓDULO 1. Introdução às Métricas de Software................................................................................4
1.1. DEFINIÇÃO DE MÉTRICAS DE SOFTWARE...................................................................................4
1.2. POR QUE MEDIR .......................................................................................................................5
1.3. PROCESSO DE MEDIÇÕES E MELHORIA CONTÍNUA DO PROCESSO DE SOFTWARE .......................7
1.4. OBJETIVO DE UM PROCESSO DE MEDIÇÕES ..............................................................................8
MÓDULO 2. Análise de Pontos de Função ....................................................................................... 10
2.1. DEFINIÇÕES E HISTÓRICO DA ANÁLISE DE PONTOS DE FUNÇÃO ...............................................10
2.2 OBJETIVOS DA ANÁLISE DE PONTOS DE FUNÇÃO .....................................................................14
2.3. BENEFÍCIOS DA ANÁLISE DE PONTOS DE FUNÇÃO ...................................................................15
2.4. LIMITAÇÕES DA ANÁLISE DE PONTOS DE FUNÇÃO ...................................................................16
2.5. PROCEDIMENTO DE CONTAGEM DE PONTOS DE FUNÇÃO ........................................................ 17
2.6. VISÃO DO USUÁRIO .................................................................................................................21
MÓDULO 3. Procedimento de Contagem de Pontos de Função....................................................... 24
3.1. OBTER A DOCUMENTAÇÃO DA APLICAÇÃO OU PROJETO A SER CONTADO .................................24
3.2 DETERMINAR O PROPÓSITO DA CONTAGEM .............................................................................25
3.3 DETERMINAR T IPO DE CONTAGEM ........................................................................................... 25
3.4 DETERMINAR ESCOPO DA CONTAGEM ...................................................................................... 27
3.5 DEFINIR A FRONTEIRA DA APLICAÇÃO ...................................................................................... 27
3.6 T IPOS FUNCIONAIS DA ANÁLISE DE PONTOS DE FUNÇÃO ......................................................... 30
3.7. CONTAGEM DAS FUNÇÕES DE DADOS ..................................................................................... 34
3.7.1 Classificação de Funções de Dados ................................................................................36
3.7.2 Contribuição Funcional das Funções de Dados ............................................................... 37
3.7.3 Contagem das Funções de Dados de uma Aplicação ...................................................... 38
3.7.4 Estudo de Casos: Contagem Função de Dados............................................................... 39
3.8 CONTAGEM DAS FUNÇÕES T RANSACIONAIS .............................................................................46
3.8.1 Classificação das Funções Transacionais........................................................................52
3.8.2 Contribuição Funcional das Funções Transacionais ........................................................ 54
3.8.3 Como Identificar Funções Transacionais nas Aplicações.................................................63
3.9 CONTAGEM DE PONTOS DE FUNÇÃO DE UMA APLICAÇÃO ......................................................... 65
3.10. CÁLCULO DE PONTOS DE FUNÇÃO ........................................................................................ 80
3.11. DOCUMENTAÇÃO DA CONTAGEM DE PONTOS DE FUNÇÃO ..................................................... 83
MÓDULO 4. CONTAGEM DE PONTOS DE FUNÇÃO DE PROJETOS DE MELHORIA .......................................85
4.1. DEFINIÇÃO DE PROJETOS DE MELHORIA ................................................................................85
4.2. COMO CONTAR FUNÇÕES DE DADOS EM PROJETOS DE MELHORIA .........................................85
4.3. COMO CONTAR FUNÇÕES T RANSACIONAIS EM PROJETOS DE MELHORIA ............................ 86
4.4. FÓRMULAS DE CÁLCULO .........................................................................................................88
4.5. ESTUDO DE CASOS ................................................................................................................89
MÓDULO 5. ESTIMATIVA DE PROJETOS DE SOFTWARE ......................................................................95
5.1. INTRODUÇÃO E MOTIVAÇÃO ....................................................................................................95
5.2. ESTIMATIVAS - CONCEITOS BÁSICOS ...................................................................................... 96
5.3. PROCESSO DE ESTIMATIVAS ..................................................................................................96
5.3.1 MÉTODOS DE ESTIMATIVA DE T AMANHO EM PONTOS DE FUNÇÃO ......................................104
5.4. ESTUDO DE CASOS: ESTIMATIVA DE UM PROJETO DE DESENVOLVIMENTO DE SOFTWARE .....113
MÓDULO 6. ROTEIRO DE MÉTRICAS DE SOFTWARE DO SISP ................................................................ 132
6.1. MELHORES PRÁTICAS: USO DE MÉTRICAS EM CONTRATOS DE SOFTWARE ........................... 132
6.2 ROTEIROS DE MÉTRICAS DE SOFTWARE ................................................................................ 134
6.3 ROTEIRO DE MÉTRICAS DE SOFTWARE DO SISP...................................................................135
2
6.3.1. Projetos de Desenvolvimento....................................................................................... 135
6.3.2. Projetos de Melhoria ....................................................................................................135
6.3.3 Projetos de Migração de Dados ..................................................................................... 137
6.3.4 Manutenção Corretiva....................................................................................................137
6.3.5 Mudança de Plataforma .................................................................................................138
6.3.6 Atualização de Versão ...................................................................................................139
6.3.7 Manutenção em Interface .............................................................................................. 140
6.3.8 Adaptação em Funcionalidades sem Alteração de Requisitos Funcionais .................... 141
6.3.9 Apuração Especial - Base de Dados.............................................................................. 142
6.3.10 Apuração Especial - Geração de Relatórios.................................................................143
6.3.11 Apuração Especial - Reexecução ................................................................................ 144
6.3.12 Atualização de Dados ..................................................................................................144
6.3.13 Desenvolvimento, Manutenção e Publicação de Páginas Estáticas de Intranet,
Internet ou Portal .................................................................................................................... 145
6.3.14 Manutenção de Documentação de Sistemas Legados................................................ 145
6.3.15 Verificação de Erros.....................................................................................................145
6.3.16 Pontos de Função de Teste ......................................................................................... 146
6.3.17 Componente Interno Reusável..................................................................................... 147
6.3.18 Contagem de Pontos de Função de Mudança de Requisitos .......................................148
3
MÓDULO 1. Introdução às Métricas de Software
Objetivos do Módulo
Ao final deste módulo, o aluno deverá ser capaz de:
 Compreender os conceitos básicos de métricas de software;
 Perceber a importância da utilização das métricas para uma gestão efetiva de

projetos de software;
 Entender os principais objetivos de um Processo de Medição de Software.
1.1. DEFINIÇÃO DE MÉTRICAS DE S OFTWARE

Todos nós convivemos com várias métricas no nosso dia a dia, por exemplo: kg,
metro, graus Celsius. Uma métrica de software é uma medida de alguma propriedade de
um software ou de suas especificações.
Algumas propriedades importantes de projetos de software a serem medidas são:
 Tamanho
Podemos medir o tamanho de um projeto de software com base em algumas

características do mesmo, como as funcionalidades ou requisitos funcionais do projeto.
Também, podemos medir o tamanho dos artefatos do projeto, por exemplo, número de
páginas do manual do usuário.
 Defeitos
Cada organização necessita definir, categorizar e quantificar os defeitos de seu

processo de software, visando à melhoria da qualidade deste. Um exemplo de métrica de
defeitos é a quantidade de erros encontrados na fase de testes de um sistema, ou a
quantidade de defeitos detectados em um documento de requisitos durante um processo
de revisão.
 Esforço
Uma métrica de esforço bastante utilizada é a de horas. A medição do esforço pode

acompanhar as fases de um processo de desenvolvimento, uma tarefa específica ou o
processo como um todo. Por exemplo, o esforço para a fase de implantação do projeto é
de 200 horas.
4
 Tempo de Duração
É essencial estimar e registrar o tempo requerido para completar uma fase no

projeto, uma tarefa ou o projeto como um todo. O tempo ou prazo de um projeto
geralmente é expresso em meses ou em dias úteis.
 Custo
O orçamento de uma organização é um recurso importante. Desta forma, os custos

de um projeto de software precisam ser quantificados. Os dois principais componentes de
custos no desenvolvimento de sistemas são a utilização de recursos computacionais e a
de recursos humanos.
Neste curso o foco são as métricas de tamanho de projetos de software,

especialmente a métrica Pontos de Função.
Pontos de Função (PF) é uma métrica padrão para dimensionar o tamanho

funcional de projetos de software.
A métrica PF quantifica o tamanho de um projeto de software com base na análise

dos requisitos funcionais do projeto. Foi criada por Allan Albrecht em 1979 e é mantida
pelo International Function Point Users Group (IFPUG).
A métrica Pontos de Função é reconhecida pelo padrão ISO/IEC 20926, sendo seu
uso recomendado em Acórdãos do Tribunal de Contas da União para contratos de
software de órgãos públicos.
Desde a década de 90, Pontos de Função é a métrica de tamanho de projetos de

software mais utilizada pela indústria, em âmbito mundial.
1.2. POR QUE MEDIR

Existem várias razões para a aplicação de métodos e modelos de medição de
software. Sua adoção pelas organizações pode se transformar em uma ferramenta
estratégica, apoiando a melhoria dos processos. Entre as motivações para a adoção de
métricas, podemos destacar:
 Formar uma baseline para estimativas
Uma baseline é um banco de dados históricos de medições de projetos de software

concluídos da organização. Armazena informações quantitativas, tais como: tamanho do
5
projeto, esforço alocado ao projeto, tempo de duração do projeto; e qualitativas, tais
como: experiência da equipe de desenvolvimento, plataforma de desenvolvimento e tipo
do processo de software utilizado. A análise desses dados constitui um recurso valioso
para apoiar as estimativas dos projetos novos e melhoria do processo da organização.
 Determinar se as metas de produtividade do processo estão sendo atingidas
É fundamental o estabelecimento de metas objetivas sobre produtividade, como, por

exemplo, atingir a produtividade média de 12 horas/PF para projetos de desenvolvimento
de complexidade média, na linguagem PHP.
 Determinar se as metas de qualidade do processo estão sendo atingidas
A qualidade do processo precisa ser mensurada e avaliada de forma objetiva, por

meio de indicadores da qualidade de software, por exemplo, defeitos/PF.
 Determinar se as metas de qualidade do produto estão sendo atingidas
Em editais de licitação para contratação de fábrica de software, é fundamental o

estabelecimento de metas claras sobre a qualidade do produto a ser entregue em relação
aos acordos de níveis de serviço. É comum o estabelecimento de indicadores de defeitos
nos acordos de níveis de serviço, por exemplo, 0,2 defeitos/PF. Nesses casos, é
necessário definir o que é um defeito e estratificar os defeitos por grau de severidade.
 Avaliar os benefícios de novos métodos, treinamentos e ferramentas
As organizações ou departamentos de TI das organizações buscam investir em

métodos, ferramentas e capacitação das equipes, visando a obtenção de melhores
resultados. No entanto, é essencial avaliar o retorno dos investimentos. Além disso, é
comum surgirem questões como: qual a linguagem de desenvolvimento mais produtiva?
Como decidir qual ferramenta open source de gerência de projetos deve ser adotada pela
organização? As medições ajudam a responder estas questões.
 Melhorar o relacionamento com o cliente
As medições tornam possível as estimativas de prazo e custo de projetos de

software nas fases iniciais do ciclo de vida do projeto, possibilitando a priorização de
requisitos e negociações de orçamento e cronograma com base em dados objetivos. O
uso de processos de estimativas baseados em métricas minimiza o risco de pressão
excessiva de cronograma, que gera atritos entre clientes e fornecedores, decorrente de
prazos subestimados.
6
 Melhorar a gerência de contratos de software
A Instrução Normativa IN04 recomenda o uso de métricas objetivas em contratos de

prestação de serviços de desenvolvimento e manutenção de sistemas, visando uma
melhor utilização do orçamento público. De fato, as métricas permitem a implementação
de uma gestão efetiva de projetos.
 Melhorar a gerência de projetos de desenvolvimento e de manutenção de

sistemas
O uso de métricas possibilita um planejamento efetivo de custos e cronograma e

apoia o acompanhamento do projeto, considerando a avaliação do progresso do projeto
com base em dados quantitativos. A evolução de requisitos também pode ser avaliada de
forma objetiva com base em medições de software.
 Entender e aperfeiçoar o processo de software
As medições são fundamentais para a implantação da melhoria contínua de

processos.
1.3. PROCESSO DE MEDIÇÕES E MELHORIA CONTÍNUA DO PROCESSO DE SOFTWARE

A figura abaixo ilustra o uso do Processo de Medições como uma ferramenta
estratégica para a melhoria do processo de software.
7
As medições e os indicadores, bem como estatísticas e atributos de projetos
armazenados em um banco de dados histórico, também denominado baseline, fornecem
uma base quantitativa para os gerentes de projetos tomarem decisões, baseando-se nos
pontos fortes e oportunidades para melhoria.
As decisões normalmente resultam em ações que ao serem implementadas, por

exemplo, por meio de programas como capacitação das equipes de desenvolvimento de
software, levam a resultados. Tais resultados, avaliados com base em indicadores e
ferramentas estatísticas, constatam se houve impacto positivo ou não das ações no
processo, bem como a quantificação deste.
A análise dos resultados pode ser realizada baseando-se nas medições atuais
comparando-se com os dados históricos de projetos concluídos (Banco de Dados
Histórico ou Baseline) e por meio de Benchmarking. Os resultados serão avaliados e
incorporados à Baseline, então novas decisões podem ser tomadas, dando
prosseguimento ao ciclo de melhoria contínua do processo.
1.4. OBJETIVO DE UM PROCESSO DE MEDIÇÕES

O principal objetivo de um processo de medição de software é fornecer um conjunto
de dados, úteis e tangíveis, para apoiar a gestão de projetos desenvolvidos internamente
ou contratados. As medições de software fornecem informações objetivas para apoiar o
gerente de projetos nas atividades enumeradas a seguir.
 Comunicar eficientemente
Medições ajudam a identificar, priorizar, acompanhar e comunicar os objetivos e

questões associadas em todos os níveis da organização. Auxiliam também na
comunicação entre organizações contratantes e contratadas. As métricas são essenciais
para uma comunicação objetiva e precisa.
 Acompanhar objetivos de projetos específicos
Medições indicam o status dos processos e produtos do projeto de software,

representando objetivamente o progresso das atividades e a qualidade dos produtos de
software associados. De fato, o gerenciamento eficaz dos parâmetros quantitativos de
projeto resulta em planejamento e controle eficazes.
8
 Identificar e corrigir problemas cedo
Medições apoiam a estratégia de gerência pró-ativa. Problemas potenciais são

objetivamente identificados, conforme os riscos sejam avaliados e gerenciados. Os
problemas existentes são avaliados e priorizados.
 Tomar decisões chaves
Os projetos de software estão sujeitos a restrições tais como: custo, prazo e

qualidade, que devem ser negociadas entre si e gerenciadas juntas para atingir os
objetivos do projeto. As medições apoiam as decisões relativas à gestão.
 Apoiar decisões
Os gerentes e líderes de projetos devem ser capazes de demonstrar a base de suas

estimativas e planos com dados de desempenho históricos. Devem ser capazes de
justificar as mudanças no plano de um projeto com dados de desempenho atuais.
9
MÓDULO 2. Análise de Pontos de Função
Objetivos do módulo
Este módulo tem como objetivos:
 Apresentar uma visão geral da técnica Análise de Pontos de Função;
 Discutir os objetivos, benefícios e limitações do uso da métrica Pontos de Função

em projetos de software;
 Apresentar o procedimento de contagem de Pontos de Função.
 Definir a Visão do Usuário
2.1. DEFINIÇÕES E HISTÓRICO DA ANÁLISE DE PONTOS DE FUNÇÃO
Vejamos algumas definições para Análise de Pontos de Função (APF):
 A Análise de Pontos de Função é um método padrão para medir software em

Pontos de Função, sob o ponto de vista do usuário;
 Pontos de Função (PF) é uma Métrica de Tamanho Funcional reconhecida pelo

Padrão Internacional - norma ISO/IEC 14.143:2007;
 Pontos de Função (PF) é uma métrica baseada na quantificação dos requisitos

funcionais do usuário. Observe que os requisitos funcionais constituem um
subconjunto dos requisitos de um projeto de software. A métrica PF não leva em
consideração os requisitos não funcionais, como performance, segurança e
usabilidade;
 Pontos de Função (PF) dimensiona um projeto de software ou aplicação

implantada analisando as funcionalidades, sob o ponto de vista do usuário.
Segue um histórico da Análise de Pontos de Função:
 Década de 60 – Linhas de Código
Na década de 60, a métrica de tamanho mais utilizada na indústria de software era a

de Linhas de Código (Line of Code - LOC). No entanto, por ter um foco na
implementação, essa métrica apresentou problemas em questões de análise econômica e
de produtividade.
10
Na época, estavam surgindo novas linguagens de programação, nas quais se escrevia
menos linhas de código em um programa. Além disso, um programador poderia
solucionar um problema com um algoritmo mais eficiente, com menos linhas de código.
 Década de 70 - Criação da métrica Pontos de Função
Com o propósito de solucionar os problemas associados à métrica Linhas de

Código, foram criadas outras métricas de software. No entanto, eram voltadas para as
fases de design e de implementação, tornando dificil sua utilização.
Allan Albrecht trabalhou no desenvolvimento de uma métrica objetiva, de fácil

utilização e que pudesse apoiar na análise dos aspectos econômicos e de produtividade
de projetos de software. Neste contexto, ele criou a métrica de Pontos de Função, em
1979.
 Década de 80 - Criação do IFPUG
Com o propósito de promover a utilização da métrica Pontos de Função, evoluir o

método de contagem de Pontos de Função e reunir os especialistas em métricas, foi
criado em 1986 o IFPUG (International Function Point Users Group).
Navegue no sítio do IFPUG http://www.ifpug.org.
Atualmente, o IFPUG é responsável pela atualização das regras de Contagem de

Pontos de Função, descritas no CPM (Counting Practices Manual), que se encontra na
versão 4.3, publicada em 2010. O IFPUG também é responsável pelo exame de
certificação de especialistas em contagem de Pontos de Função, denominada CFPS
(Certified Function Point Specialist). A certificação CFPS tem como propósito reconhecer
formalmente um nível especialista na área de Análise de Pontos de Função (APF).
 Década de 90 - Uso da APF no Brasil - criação do BFPUG
Na década de 80, poucas empresas multinacionais utilizavam a métrica PF no

Brasil. Na década de 90, algumas empresas como: SERPRO, Caixa Econômica Federal e
Petrobras começaram a contratar software com base em Pontos de Função. Em 1998, foi
criado o BFPUG - Brazilian Function Point Users Group.
11
O BFPUG é um grupo constituído com o objetivo de estimular e divulgar a utilização
de métricas no desenvolvimento de sistemas, em particular a Análise de Pontos de
Função. O BFPUG é a representação brasileira oficial (Chapter) do IFPUG - International
Function Point Users Group. Navegue no sítio do BFPUG http://www.bfpug.com.br.
 APF - Século 21: Uso da métrica em contratos pelo Governo Brasileiro
O século 21 está sendo marcado pelo uso crescente da métrica Pontos de Função
pela indústria de software. Em 2001 pela primeira vez ocorreu o exame de Certificação
CFPS no Brasil. O número de profissionais certificados é crescente, sendo um dos países
com maior número de profissionais CFPS do mundo, demonstrando a expansão da
utilização da métrica.
Em 2003 a métrica Pontos de Função Não Ajustados foi reconhecida pela ISO como
métrica padrão de tamanho funcional de software.
Em 2008 foi publicada a Instrução Normativa IN04 pela SLTI/MPOG, preconizando o

uso de métricas em contratos de prestação de serviços de desenvolvimento e
manutenção de sistemas, com restrição ao uso da métrica de esforço homem-hora.
"§ 2º - A aferição de esforço por meio da métrica homens-hora apenas poderá ser
utilizada mediante justificativa e sempre vinculada à entrega de produtos de acordo com
prazos e qualidade previamente definidos."
O Tribunal de Contas da União também tem recomendado em Acórdãos o uso da
métrica Pontos de Função Não Ajustados em contratos de fábrica de software.
"Acórdão 2.024/2007 - Plenário
9.2.2.2. prever metodologias de mensuração de serviços prestados que privilegiem a

remuneração da contratada mediante a mensuração de resultados, a exemplo da análise
por Pontos de Função (método padronizado largamente utilizado no mercado nos dias de
hoje para a mensuração de serviços de desenvolvimento e manutenção de sistemas,
considerando as funcionalidades implementadas, sob o ponto de vista do usuário),
buscando eliminar a possibilidade de remunerar a contratada com base na quantidade de
horas trabalhadas ou nos postos de trabalho disponibilizados ou, caso tal caminho não se
mostre comprovadamente viável, restando como única opção a remuneração de serviços
por horas trabalhadas, cuidar para que sejam previamente definidos e especificados os
serviços a serem executados e estabelecidos, também de antemão, os valores máximos
de horas aceitáveis para cada um desses serviços, assim como explicitada a metodologia
a ser utilizada para a identificação desse quantitativo de horas;"
12
Neste contexto, os Órgãos públicos têm estabelecido contratos com base na métrica
Pontos de Função. Além dos Órgãos públicos, muitas empresas privadas também
contratam software usando Pontos de Função.
 APF - 2010 - Rumo ao Futuro - Suporte aos Órgãos no Uso de Métricas
Em 2009, a SLTI/MPOG, em parceria com a UniSerpro - Universidade Corporativa do

SERPRO, iniciou o processo de Capacitação dos Órgãos do SISP. Em 2010 foi definido
um Programa de capacitação em Pontos de Função. Foram ministradas várias turmas dos
cursos de Contagem de Pontos de Função Básico/Intermediário e Avançado.
Todos os Servidores Públicos e Funcionários de Empresas Públicas podem se

cadastrar na Comunidade SISP com seu e-mail corporativo e receber informações sobre
treinamentos e outros eventos do SISP, incluindo os treinamentos em métricas de
software. Maiores informações sobre o SISP podem ser obtidas em:
http://www.sisp.gov.br.
A SLTI, em 29 de novembro de 2010, publicou oficialmente a versão 1.0 do Roteiro de

Métricas de Software do SISP, através da Portaria SLTI/MP Nº 31, promovendo o uso de
métricas em contratos de software. A Instrução Normativa SLTI/MPNº 4, de 11 publicada
em setembro de 2014 reforça a restrição do uso da métrica de esforço homem-hora nos
contratos de serviços de desenvolvimento e manutenção de sistemas firmados entre
instituições públicas e empresas prestadoras desse tipo de serviço.
O IFPUG criou uma métrica de dimensionamento de Requisitos Não Funcionais,

denominada SNAP - Software Non Functional Assessment Process. O principal objetivo
do projeto foi a definição de um Framework para Dimensionamento de Requisitos Não
Funcionais, estabelecendo uma relação entre tamanho não funcional e o esforço para a
implementação dos requisitos não funcionais. Em 2011 foi publicada a versão 1.0 do
manual. Em 2013 foi publicada a versão 2.0 e realizado o primeiro exame de certificação
de especialistas do SNAP.
Em 2015 a SLTI disponibilizou o Guia de Contagem de Pontos de Função do SISP
para projetos Data Warehouse v 1.0 que define diretrizes e regras de contagem e
estimativa do tamanho funcional de projetos de DW, usando a métrica PF, com o objetivo
de apoiar os órgãos integrantes do SISP na contratação de serviços de desenvolvimento
e manutenção de projetos de DW.
13
Em 2015 a SLTI publicou a versão 2.1do Roteiro de Métricas do SISP contemplando
um capítulo sobre contagem de Pontos de Função de projetos de software utilizando
métodos Ágeis.
Em 2015 o CGU publicou a RAG 5 “Relatório de Avaliação por Área de Gestão No 5

Contratação de Serviços de Desenvolvimento e Manutenção de Sistemas Mensurados em
Pontos de Função” que apresenta as principais falhas em Contagem de Pontos de
Função.
Em 2016 foi publicada versão 2.2 do Roteiro de Métricas do SISP. Esta versão
apresenta orientações para contagem de Pontos de Função de Log, Trilha de Auditoria e
Histórico.
2.2 OBJETIVOS DA ANÁLISE DE PONTOS DE FUNÇÃO
Os objetivos principais da APF são os seguintes:
 Medir as funcionalidades requisitadas e recebidas pelo usuário
A contagem de Pontos de Função é realizada com base nos requisitos funcionais

validados e aprovados pelo usuário (funcionalidades requisitadas) e entregues a este por
meio da implantação do sistema (funcionalidades recebidas).
 Medir projetos de desenvolvimento e de melhoria (manutenção evolutiva)

independentemente da metodologia e tecnologia utilizadas na
implementação
A contagem de Pontos de Função independe da tecnologia utilizada na

implementação, ou seja, um mesmo projeto desenvolvido em PhP, JAVA ou COBOL terá
o mesmo tamanho funcional em Pontos de Função. O esforço e o custo de
desenvolvimento são influenciados pela tecnologia utilizada na implementação e em
outros fatores. Outro ponto importante é que a métrica Pontos de Função pode ser usada
de forma integrada a qualquer processo de desenvolvimento, inclusive processos ágeis
(XP, SCRUM) e metodologias com orientação a objeto.
Embora a métrica tenha sido concebida para dimensionar Sistemas de Informação,

qualquer tipo de projeto de software pode ser dimensionado usando Pontos de Função,
dentre eles: Software Básico, WebService, Projetos de BI, DataWarehousing e Workflow.
14
Adicionalmente, a técnica também possui os seguintes objetivos:
 Ser simples o suficiente para minimizar o trabalho adicional envolvido no

processo de contagem
Em um processo típico de desenvolvimento de sistemas, as estimativas e contagens

de Pontos de Função correspondem aproximadamente a 1% do custo do projeto. A
simplicidade é um requisito fundamental para viabilizar o uso de uma técnica.
 Medida consistente entre projetos e organizações
De fato, a métrica Pontos de Função é objetiva e o procedimento de contagem de

Pontos de Função é repetível. Ou seja, dois profissionais de métricas realizando a
contagem de Pontos de Função de um mesmo projeto obtêm os mesmos resultados. A
consistência é também um requisito essencial para o uso de uma métrica como base para
contratação de software.
2.3. BENEFÍCIOS DA ANÁLISE DE PONTOS DE FUNÇÃO
O uso da técnica Análise de Pontos de Função (APF) traz diversos benefícios para
as organizações, sob ponto de vista gerencial: gestão de projetos de desenvolvimento e
de manutenção de sistemas, gestão do processo de desenvolvimento de sistemas, gestão
de contratos de projetos de software.
Vamos destacar os benefícios apresentados no Manual de Práticas de Contagem de

Pontos de Função, a saber:
 Apoiar a análise de qualidade e produtividade
A métrica Pontos de Função possibilita a construção de indicadores de produtividade

- horas/PF e de qualidade - defeitos/PF. Esses indicadores podem ser empregados na
análise da qualidade e produtividade do processo de software. E ainda com base nessas
informações, pode-se promover a melhoria contínua do processo de software.
 Estimar o custo e os recursos de um projeto de software
O tamanho funcional de um projeto em Pontos de Função constitui uma informação

importante para os modelos de geração de estimativas de prazo, esforço e custo de
projetos de software. Com base no tamanho de um projeto em Pontos de Função e
algumas características do projeto, é possível se obter rapidamente as estimativas de
15
prazo e custo do mesmo, por meio de modelos de estimativas, Fórmula de Capers Jones
e COCOMO II.
 Fornecer um fator de normalização para a comparação de software
PF é uma métrica padrão que pode ser usada na construção de indicadores, para
comparação de tamanho funcional de projetos de software.
 Determinar o tamanho de um pacote de software adquirido, por meio do

dimensionamento funcional de todas as funções incluídas no mesmo
O tamanho funcional de um pacote de aplicação adquirido pode ser dimensionado por

meio da métrica Pontos de Função. Essa prática e apoia a análise de custos do pacote.
 Ajudar a determinar o benefício provido por um pacote de software, por meio

do dimensionamento das funções que atendem aos requisitos da
organização
Esse benefício possibilita a análise make or buy. A métrica apoia o gestor na

decisão sobre o que é menos custoso: desenvolver uma aplicação internamente, contratar
o desenvolvimento da aplicação externamente ou comprar um pacote de aplicação e
customizar. Essa análise é realizada com base no dimensionamento dos requisitos da
aplicação em Pontos de Função e o dimensionamento dos requisitos do pacote que
atendem aos requisitos da organização.
2.4. LIMITAÇÕES DA ANÁLISE DE PONTOS DE FUNÇÃO
A métrica Pontos de Função é sem dúvida uma excelente métrica, objetiva e com
maturidade em sua utilização na indústria de software e no Governo. É importante
ressaltar que a métrica foi concebida para medir o tamanho funcional de projetos de
software. Desta forma, deve-se observar as limitações do uso da métrica na gestão de
contratos de software:
 Pontos de Função não mede requisitos não funcionais
PF é uma métrica de tamanho funcional que dimensiona projetos de software com

base apenas nos requisitos funcionais. Desta forma, a complexidade algorítmica, assim
como requisitos complexos de usabilidade, segurança e performance de um projeto não
influenciam o tamanho funcional do mesmo em Pontos de Função.
16
Conclusão: O tamanho do projeto em PF influencia o esforço e o custo de
desenvolvimento do mesmo. No entanto, dois projetos com o mesmo tamanho
funcional medido em PF podem ter esforço e custo bastante diferentes.
Em contratos de software é importante licitar preços distintos por PF em plataformas

e tipos de projetos distintos. Por exemplo, o esforço e o custo de 1 PF de um sistema de
DataWarehousing será bem maior do que de um sistema pequeno de cadastro de agenda
telefônica.
 A métrica dimensiona apenas projetos de melhoria, também denominados

projetos de melhoria funcional ou manutenção evolutiva
De fato, existem vários tipos de projetos de manutenção adaptativa que implicam

mudanças de requisitos não funcionais, por exemplo, melhorar o tempo de resposta de
um relatório ou mudar a posição de um texto estático em uma tela. Nestes projetos de
manutenção não há mudança em funcionalidades. Portanto, pela técnica Análise de
Pontos de Função, eles são dimensionados com Zero Ponto de Função.
Conclusão: Projetos de manutenção em requisitos não funcionais requerem

esforço e custo para sua implementação, no entanto não possuem tamanho
funcional, sendo dimensionados com zero Ponto de Função.
O uso da métrica de Pontos de Função em contratos de software requer algumas

adequações. Essas adequações devem ser documentadas nos Roteiros de Métricas dos
Órgãos. Este Roteiro deve ser integrado aos Editais e contratos. O Roteiro de Métricas do
SISP pode ajudar aos Órgãos na elaboração de seus Roteiros de Métricas.
2.5. PROCEDIMENTO DE CONTAGEM DE PONTOS DE FUNÇÃO
A métrica Pontos de Função de fato é uma ferramenta poderosa para apoiar a

gestão de projetos de software, fornecendo uma medida quantitativa do tamanho
funcional de projetos de desenvolvimento e de melhoria de software. Para contar Pontos
de Função de um projeto de software deve-se seguir os passos do Procedimento de
Contagem de Pontos de Função, apresentado a seguir:
17
 Obter a documentação disponível do projeto
A documentação deve ser analisada com o foco na elicitação dos requisitos

funcionais que constituem a base para a contagem de Pontos de Função.
A documentação pode incluir, dentre outros: especificação de requisitos, modelos de

dados, diagramas de classe, especificação de casos de uso, histórias de usuários, itens
de backlog, regras de negócio da aplicação, cenários de uso, descrição detalhada das
funcionalidades da demanda, layout de relatórios e telas e outros artefatos do
desenvolvimento de software. Se não há documentação suficientemente disponível, deve-
se buscar o acesso aos especialistas no negócio para cobrir as lacunas da
documentação.
 Identificar o Propósito da Contagem
O propósito da contagem fornece uma reposta para uma questão de negócio a ser
resolvida. Influencia o escopo da contagem e o tipo da contagem. Também influencia o
estabelecimento da fronteira do software a ser medido.
18
 Identificar o Tipo de Contagem
As contagens de Pontos de Função podem ser associadas a projetos ou aplicações.

Existem três tipos de contagem de Pontos por Função: Projeto de Desenvolvimento,
Projeto de Melhoria e Aplicação.
A contagem de Projeto de Desenvolvimento está associada a um novo projeto de

desenvolvimento de sistema. A Contagem de Projeto de Melhoria dimensiona as
funcionalidades incluídas, alteradas e excluídas da aplicação existente, em uma
manutenção evolutiva. A contagem de Aplicação, também denominada contagem de
baseline, refere-se a uma aplicação instalada.
 Determinar o Escopo da Contagem
O escopo da contagem identifica o conjunto de funcionalidades a ser considerado na

contagem de Pontos de Função. O escopo de uma contagem pode incluir mais de uma
aplicação.
 Determinar a Fronteira da Aplicação
A definição da fronteira da aplicação consiste no estabelecimento do limite lógico

entre o projeto que está sendo contado e o usuário. O usuário pode ser o usuário
propriamente dito ou outras aplicações que interagem com o sistema em questão.
 Contar Funções de Dados
As Funções de Dados representam a funcionalidade fornecida para o usuário

através de dados internos ou externos à aplicação. As Funções de Dados são
identificadas como: Arquivos Lógicos Internos e Arquivos de Interface Externa.
Um Arquivo Lógico Interno (ALI) é um grupo de dados logicamente relacionados,

reconhecido pelo usuário, mantido por meio de um processo elementar da aplicação que
está sendo contada.
Um Arquivo de Interface Externa (AIE) é um grupo de dados logicamente

relacionados, reconhecido pelo usuário, mantido por meio de um processo elementar de
uma outra aplicação e referenciado pela aplicação que está sendo contada. Um AIE deve
ser obrigatoriamente um ALI de outra aplicação.
19
A principal diferença entre os ALIs e AIEs é que um Arquivo de Interface Externa
não é mantido pela aplicação que está sendo contada, e um Arquivo Lógico Interno é
mantido por funcionalidades da aplicação em questão.
 Contar Funções Transacionais
As funções transacionais representam as funcionalidades de processamento de

dados providas ao usuário, sendo identificadas como Entradas Externas, Saídas Externas
e Consultas Externas.
A Entrada Externa (EE) é um processo elementar que trata dados ou informação de

controle que entram pela fronteira da aplicação. Seu objetivo principal é manter um ou
mais Arquivos Lógicos Internos e/ou alterar o comportamento do sistema.
A Saída Externa (SE) é um processo elementar que envia dados ou informação de

controle para fora da fronteira da aplicação. Seu objetivo principal é apresentar
informação para um usuário, através de um processamento lógico adicional à
recuperação de dados ou informação de controle.
O processamento lógico deve conter no mínimo uma fórmula matemática ou cálculo,

ou criar dados derivados. Uma Saída Externa pode também manter um ou mais Arquivos
Lógicos Internos ou alterar o comportamento do sistema.
A Consulta Externa (CE) é um processo elementar que envia dados ou informação

de controle para fora da fronteira da aplicação. Seu objetivo principal é apresentar
informação para o usuário através da recuperação de dados ou informação de controle de
ALIs ou AIEs.
 Calcular o Tamanho Funcional
Cada tipo funcional identificado possui uma complexidade - Baixa, Média ou Alta, definida
com base nas regras de contagem. Cada funcionalidade possui uma contribuição
funcional para a contagem de PF de acordo com a complexidade, conforme a tabela
abaixo:
20
Complexidade
Tipo Funcional
Baixa Média Alta
Arquivo Lógico Interno (ALI) 7 PF 10 PF 15 PF
Arquivo da Interface Externa (AIE) 5 PF 7 PF 10 PF
Entrada Externa (EE) 3 PF 4 PF 6 PF
Saída Externa (SE) 4 PF 5 PF 7 PF
Consulta Externa (CE) 3 PF 4 PF 6 PF
O Cálculo de Pontos de Função é realizado de acordo com os tipos de contagem:

Projetos de Desenvolvimento, Projetos de Melhoria (Manutenção Evolutiva) e Aplicações
Instaladas.
PF_Desenvolvimento = PF_Incluído + PF_Conversão
PF_Melhoria = PF_Incluído + PF_Alterado + PF_Excluído + PF_Conversão
PF_Aplicação = PF_Incluído
As fórmulas de cálculo de Pontos de Função de Projetos de Desenvolvimento e de

Melhoria contemplam as funcionalidades associadas à conversão de dados. As funções
de conversão de dados, muitas vezes denominadas pelas equipes de desenvolvimento
como migração de dados, são associadas às cargas iniciais de dados que são
executadas apenas uma vez, na implantação do sistema. A contagem de Pontos de
Função da Aplicação não contempla funções de conversão de dados.
 Documentar e Reportar a Contagem
Considerando o cenário do Governo Brasileiro de utilização da métrica Pontos de Função

como base para o estabelecimento de contratos de software, a documentação da
contagem de Pontos de Função deve ser clara o suficiente para que um revisor ou auditor
possa compreender a contagem apresentada e chegar aos mesmos resultados. A
contagem de Pontos de Função deve ser rastreável para os requisitos funcionais
analisados.
2.6. VISÃO DO USUÁRIO
A Visão do Usuário é uma descrição formal das necessidades de negócio do usuário

na linguagem do usuário, sendo entendida pelo usuário e a equipe de desenvolvimento.
21
Cabe ressaltar que o usuário deve ser capaz de definir as necessidades e funcionalidades
da aplicação e geralmente exerce o papel de Analista de Negócios.
A Visão do Usuário:
 É uma descrição das funções de negócio;
 É aprovada pelo usuário;
 Pode variar de forma física (Documento de Visão, Especificação Funcional,
Formalização Simples de Requisitos, Manual do Usuário);
 Pode ser usada na contagem de Pontos de Função.
Desta forma, a contagem de Pontos de Função deve ser realizada com base na
análise de um documento de requisitos funcionais do sistema. E, ainda, este documento
deve ser formalizado, validado e aprovado pelo cliente.
A contagem de Pontos de Função é baseada na visão do usuário, ou seja, em um

documento de requisitos funcionais consistente e completo, aprovado pelo usuário. Nas
fases iniciais do ciclo de vida, onde existem apenas requisitos de negócio, pode-se
realizar uma estimativa de Pontos de Função do projeto. Existem vários métodos para se
estimar o tamanho funcional de projetos em Pontos de Função, por exemplo: Contagem
Estimada (NESMA). O Manual de Práticas de Contagem aborda apenas o Procedimento
Contagem de Pontos de Função.
Exemplo:
A contagem de Pontos de Função de um Sistema deve ser realizada considerando o
Requisito funcional final do Sistema, que representa a visão do usuário. Este exemplo
apresenta os três estágios observados na atividade de definição da Visão do Usuário de
um Sistema.
1) Requisito Inicial do Usuário de um Sistema de RH: Consulta de dados do

empregado.
Descrição: O usuário deve entrar com o nome do empregado e o sistema deve
apresentar os dados do empregado (nome completo, matrícula, Ramal, Cargo e Setor).
Observe que este requisito não está consistente. Quando dois empregados tiverem
o mesmo nome, os dados de qual empregado devem ser apresentados?
Desta forma, este requisito inicial não traduz a visão do usuário. Não pode ser
utilizado para contar Pontos de Função.
22
Cabe ressaltar que Uma medição de tamanho funcional é realizada utilizando a
informação em uma linguagem que é comum para o usuário e desenvolvedores.
2) Requisito Técnico Inicial de um Sistema de RH: Construção de índice.
Descrição: Desenvolver um índice para acelerar a busca de um empregado

específico.
Observe que o índice é um requisito não funcional de desempenho, portanto, não

deve ser considerado em uma contagem de Pontos de Função. Lembre-se: PF é uma
métrica de tamanho funcional. Assim, os requisitos não funcionais não fazem parte da
Visão do Usuário.
3) Requisito Funcional Final de um Sistema de RH: Consulta de Dados de

empregado
Descrição: Desenvolver uma funcionalidade de pesquisa de empregados, onde o

usuário entre com o nome do empregado e seja apresentada uma lista com o nome
completo e setor com totalização de registros de empregados encontrados. Esta lista
pode ser usada para a seleção do empregado em várias partes da aplicação. Desenvolver
uma funcionalidade de Consulta para apresentar os detalhes do empregado selecionado
(nome completo, matrícula, Ramal, Cargo e Setor). Todos os dados são recuperados do
Grupo Lógico de Dados de Empregados.
Observe que são identificadas 3 funções no requisito funcional descrito acima,

sendo duas funções transacionais e uma função de dados, a saber:
Saída Externa (SE): Pesquisar Empregado
Consulta Externa (CE): Consultar Detalhes do Empregado
Arquivo Lógico Interno (ALI): Empregados
OBS: Como se trata de um sistema de RH, então os dados de Empregados são

mantidos pela aplicação, por isso foram identificados como Arquivo Lógico Interno (ALI).
Cabe ressaltar que as funções de dados e transacionais são contadas apenas uma vez,
independentemente da quantidade de telas em que elas são referenciadas na aplicação.
23
MÓDULO 3. Procedimento de Contagem de Pontos de Função
Ao final deste módulo, o aluno deverá ser capaz de entender as atividades que compõem
o procedimento de contagem (Figura 2), a saber:
 Obter a documentação da aplicação ou do projeto a ser contado;
 Identificar propósito da contagem;
 Identificar tipo de contagem;
 Determinar escopo da contagem;
 Determinar fronteira da aplicação;
 Contar funções de dados;
 Contar funções transacionais;
 Calcular tamanho funcional;
 Documentar a contagem de pontos de função.
3.1. OBTER A DOCUMENTAÇÃO DA APLICAÇÃO OU PROJETO A SER CONTADO
O primeiro passo do procedimento de contagem de Pontos de Função é obter a

documentação disponível do projeto a ser contado. A documentação deve ser analisada
com foco na elicitação dos requisitos funcionais, que constituem a base para a contagem
de Pontos de Função.
De acordo com manual CPM 4.3, uma documentação adequada pode incluir
requisitos, modelos de dados/objetos, diagramas de classe, diagramas de fluxo de dados,
casos de uso, descrições procedurais, layout de relatórios e telas, manuais de usuário e
outros artefatos do desenvolvimento de software.
Se não há documentação disponível, deve-se buscar o acesso aos especialistas no

negócio para cobrir as lacunas da documentação.
24
Uma vez obtida a documentação que subsidiará a contagem de Pontos de Função,
deve-se identificar o propósito, tipo e escopo da contagem e fronteira da aplicação,
conforme descrito nos tópicos a seguir.
3.2 DETERMINAR O PROPÓSITO DA CONTAGEM
A contagem de Pontos de Função é realizada para responder a uma questão de

negócio. É o problema de negócio que determina o propósito da contagem.
Desta forma, o propósito da contagem:
 Determina o tipo de contagem de ponto de função e o escopo da contagem;
 Influencia o posicionamento da fronteira da aplicação sendo medida.
Tomemos como exemplo uma organização que possui uma aplicação de Gestão de
Recursos Humanos (GRH) implantada em COBOL, e que deseja contratar o
desenvolvimento de um sistema de Treinamento com base na métrica Pontos de Função.
O novo Sistema de Treinamento deve levar em consideração alguns requisitos do

módulo de Treinamento do Sistema GRH e deve ser implementado na linguagem PHP.
Observe que a questão não é contar a aplicação implantada GRH, mas sim obter o
tamanho funcional do Sistema de Treinamento em Pontos de Função para contratação,
que neste contexto está sendo concebido como um novo sistema.
Desta forma, o tipo de contagem é um projeto de desenvolvimento, o escopo da

contagem são todas as funcionalidades a serem implantadas no Sistema de Treinamento
e a fronteira da contagem é o Sistema de Treinamento.
3.3 DETERMINAR TIPO DE CONTAGEM
O tipo de contagem de Pontos de Função é determinado pelo propósito da

contagem. Segundo o manual CPM, existem três tipos de contagem, descritos a seguir.
25
 Contagem de pontos de função de projeto de desenvolvimento
O tamanho funcional do projeto de desenvolvimento é uma medida de

funcionalidade, oferecida aos usuários com a primeira instalação do software. Este tipo de
contagem é utilizado para demanda de desenvolvimento de novos sistemas.
 Contagem de pontos de função de Projeto de Melhoria
O tamanho funcional do projeto de melhoria é uma medida das funcionalidades

incluídas, alteradas e excluídas pelo projeto de melhoria na aplicação. É importante
ressaltar que as manutenções em requisitos não funcionais não são contempladas na
contagem de Pontos de Função. Na literatura de Engenharia de Software, o projeto de
melhoria também é denominado projeto de melhoria funcional ou projeto de manutenção
evolutiva.
 Contagem de pontos de Função de Aplicação
O tamanho funcional de uma aplicação é uma medida de funcionalidade que uma

aplicação oferece ao usuário. É também denominada de baseline ou tamanho funcional
instalado. Este tamanho fornece uma medida das funcionalidades atuais que a aplicação
fornece aos usuários.
Neste momento, duas observações são importantes:
1) O uso da métrica Pontos de Função em contratos de software requer a criação de

novos tipos de contagem, por exemplo: contagem de Pontos de Função em manutenções
adaptativas em requisitos não funcionais. Estas adaptações do manual de práticas de
contagem devem ser documentadas claramente no Roteiro de Métricas do Órgão.
2) As contagens de Pontos de Função realizadas ao longo do ciclo de vida de um

projeto de software são estimadas. A contagem final deve ser realizada após a entrega
formal do projeto com aceite do cliente. Podem existir diferenças significativas entre as
contagens estimadas e a contagem final, devido a mudanças de requisitos durante o
desenvolvimento ou manutenção de um sistema. Essas mudanças de requisitos, bastante
comuns em projetos de software, ocorrem à medida que os usuários e a equipe de
desenvolvimento vão adquirindo maior conhecimento sobre o sistema em questão e por
mudanças em normas ou legislação. A mudança ou evolução de requisitos é denominada
pelo CPM de Scope Creep.
26
3.4 DETERMINAR ESCOPO DA CONTAGEM
O escopo da contagem define o conjunto de requisitos funcionais a ser incluído na

contagem de pontos de função.
O escopo:
 Define o (sub)conjunto do software que está sendo medido;
 É determinado pelo propósito da contagem de pontos de função;
 Identifica quais funcionalidades serão incluídas na contagem de Pontos de Função;
 Pode incluir mais de uma aplicação.
Alguns projetos de desenvolvimento ou de manutenção podem incluir mais de um

sistema; neste caso o escopo da contagem vai abranger vários sistemas. A contagem de
Pontos de Função deve ser realizada separadamente em cada fronteira de aplicação.
Observe que uma demanda de manutenção decorrente de uma mudança de

legislação pode impactar várias aplicações implantadas. Neste caso, o escopo da
contagem deve incluir as funcionalidades de todas as aplicações a serem mantidas. Cada
aplicação constitui uma fronteira de contagem.
3.5 DEFINIR A FRONTEIRA DA APLICAÇÃO
A fronteira é uma interface conceitual entre o software sendo contado e seus

usuários. O usuário de uma aplicação pode ser o usuário propriamente dito ou outras
aplicações. Na Análise de Pontos de Função, Usuário é definido como: qualquer pessoa,
aplicação, hardware, middleware ou software que interage com o sistema sendo contado.
A fronteira da aplicação:
 Define o que é externo à aplicação.
 Indica o limite entre o software que está sendo medido e o usuário (ou aplicações).
 Atua como uma "membrana" através da qual os dados processados pelas

transações passam para dentro e para fora da aplicação. Estes dados cruzam a
fronteira da aplicação.
 Agrupa os dados lógicos mantidos pela aplicação (Arquivos Lógicos Internos).

27
 Auxilia na identificação dos dados lógicos referenciados, mas não mantidos pela
aplicação (Arquivos de Interface Externa).
 Depende da visão externa do negócio, do usuário da aplicação. É independente de

considerações de técnicas de arquitetura e/ou implementação.
O posicionamento da fronteira entre o software sob análise e outra aplicação pode

ser subjetivo. É comum haver dificuldade para delinear onde uma aplicação termina e
outra se inicia. Busque identificar a fronteira sob a perspectiva de negócio em vez de se
basear em uma consideração técnica ou física.
A identificação de fronteira pode influenciar dramaticamente na contagem de Pontos de

Função de uma aplicação. Por exemplo, se um sistema de Recursos Humanos (SRH) for
concebido com duas fronteiras: SRH - Consulta e SRH - Cadastro, a soma da contagem
de PF das duas aplicações será muito maior do que a contagem do SRH como uma
aplicação única.
Desta forma, é fortemente recomendado que o roteiro de métricas da instituição

defina, claramente, quais são as fronteiras das aplicações implantadas, visando facilitar a
contagem dos projetos de manutenção.
A Figura abaixo ilustra o conceito de fronteira de aplicação.
Figura: Diagrama de Fronteira de Aplicações
28
Observe, na Figura acima, a definição da fronteira do Sistema de Recursos
Humanos e como esta interage com as funcionalidades da aplicação.
 O Sistema Monetário e os usuários estão fora da fronteira da aplicação.
 O grupo lógico de dados de Empregados é mantido dentro da fronteira do Sistema

de Recursos Humanos, sendo contado como Arquivo Lógico Interno (ALI).
 O Sistema de Recursos Humanos possui uma integração com o Sistema

Monetário, para leitura de dados de Taxa de Conversão de moedas, visando o
cálculo do salário de funcionários estrangeiros. O grupo de dados Taxa de
Conversão é contado como Arquivo de Interface Externa (AIE).
 A funcionalidade Cadastra Novo Empregado é contada como Entrada Externa

(EE). Os dados de empregados que o usuário está cadastrando entram pela
fronteira da aplicação, sendo armazenados no ALI Empregados.
 A funcionalidade Relatório com dados calculados de empregados é contada

como Saída Externa (SE). Os dados de empregados, armazenados no ALI
empregados, que são apresentados no relatório para o usuário, estão saindo pela
fronteira da aplicação.
 A funcionalidade Solicita e Recebe informação de empregado é contada como

Consulta Externa (CE). Os dados que o usuário insere como parâmetros de busca
ou filtros na solicitação de informações de empregados estão entrando pela
fronteira da aplicação e os dados recuperados do ALI de empregados e
apresentados para o usuário estão saindo pela fronteira da aplicação.
Evidentemente, os dados que entram ou saem pela fronteira da aplicação

atravessam a fronteira da aplicação.
O acórdão abaixo reproduzido trata da questão das fronteiras das aplicações:

"Acórdão 1.647/2010 - Tribunal de Contas da União"
Recomendação:
"9.2.1. ao contratar desenvolvimento de software utilizando a métrica de Análise de
Pontos de Função, evite adotar, como único guia de referência para contagens, o Manual
de Práticas de Contagem do IFPUG, adicionando ao contrato cláusulas complementares
que elucidem pontos em aberto, abordando, por exemplo, tópicos como: (...) 9.2.1.4.
29
definição das fronteiras a serem utilizadas nas contagens; 9.2.1.5. políticas para definição
de: novas fronteiras (...)"
3.6 TIPOS FUNCIONAIS DA ANÁLISE DE PONTOS DE FUNÇÃO
Anteriormente, foram definidos o Propósito, Escopo e Tipo da contagem, e a

Fronteira da Aplicação. O próximo passo é a Contagem de PF considerando a fronteira
de aplicação identificada.
A contagem de Pontos de Função consiste no mapeamento dos requisitos

funcionais da aplicação para os cinco tipos funcionais da técnica Análise de Pontos de
Função. Esses cinco tipos funcionais são divididos em dois grupos, Funções de Dados e
Funções Transacionais.
As Funções de Dados são os Arquivos Lógicos Internos (ALI) e os Arquivos de

Interface Externa (AIE).
As funções transacionais são: Entradas Externas (EE), Consultas Externas (CE) e

Saídas Externas (SE). A Figura abaixo exibe o processo, que é explicado em detalhes
logo a seguir.
30
 Fronteira da Aplicação
É a interface conceitual que delimita o sistema sendo medido (mundo interno) e os

usuários e as outras aplicações (mundo externo). A contagem de Pontos de Função leva
em consideração uma fronteira de aplicação.
 Usuário Final
Qualquer pessoa que interage com o sistema que está sendo contado.
 Outra Aplicação
Qualquer aplicação que interage com o sistema que está sendo contado.
 Arquivo Lógico Interno (ALI)
É um grupo de dados logicamente relacionados, reconhecido pelo usuário, mantido

por meio de um processo elementar da aplicação que está sendo contada. Função de
Dados que leva em consideração os dados lógicos internos da aplicação. Por exemplo,
em um Sistema de Cadastro de Treinamentos a Entidade de Cursos é um ALI mantido
pelas funcionalidades de inclusão, alteração de cursos.
 Arquivo de Interface Externa (AIE)

por meio de um processo elementar de uma outra aplicação e referenciado pela aplicação
que está sendo contada. O AIE é obrigatoriamente um ALI de outra aplicação. Função de
Dados que leva em consideração os dados lógicos externos à aplicação. Por exemplo, em
um Sistema de Cadastro de Treinamentos a Entidade de CPF é um AIE lido pela
aplicação para validação do CPF do aluno. Observe que CPF é um ALI mantido pelo
Sistema de CPF da Receita Federal.
 Entrada Externa
É um processo elementar que processa dados ou informação de controle que

entram pela fronteira da aplicação. Seu objetivo principal é manter um ou mais ALI ou
alterar o comportamento do sistema. Função Transacional que tem como objetivo o
processamento de dados que entram pela fronteira da aplicação, esses dados podem
manter Arquivo Lógico Interno ou alterar o comportamento da aplicação. Por exemplo, em
31
um Sistema de Cadastro de Treinamentos a funcionalidade de Alterar dados de um curso
é um exemplo de Entrada Externa.
Ex: Realizar inscrição no CONSEGI.
 Consulta Externa
É um processo elementar que envia dados ou informação de controle para fora da

fronteira da aplicação. Seu objetivo principal é apresentar informação para o usuário,
através da recuperação de dados ou informação de controle de ALI ou AIE. Alguns
aspectos importantes da Consulta Externa são:
 O processamento lógico da CE não contém cálculos;
 Não cria dados derivados;
 Não mantém ALI;
 Não altera o comportamento do sistema.
A consulta Externa também pode ser entendida como Função Transacional com
objetivo de apresentar informações para o usuário ou outra aplicação, por meio de
recuperação de dados de ALI ou AIE. Por exemplo, em um Sistema de Cadastro de
32
Treinamentos a funcionalidade de Consultar dados de um curso específico é um exemplo
de Consulta Externa. Observe que todos os dados são recuperados do ALI de cursos.
Ex: Consultar Oficinas do CONSEGI.
 Saída Externa
É um processo elementar que envia dados ou informação de controle para fora da

fronteira da aplicação. Seu objetivo principal é apresentar informação para um usuário ou
outra aplicação, por meio de um processamento lógico adicional à recuperação de dados
ou informação de controle. O processamento lógico deve conter cálculo, ou criar dados
derivados, ou manter ALI ou alterar o comportamento do sistema. Também pode ser
entendido como uma Função Transacional, que tem objetivo de apresentar informações
para o usuário ou outra aplicação com derivação de dados ou cálculos, ou mudança de
comportamento ou atualização de ALI.
Como exemplo, pode-se considerar um Sistema de Cadastro de Treinamentos, no

qual a funcionalidade de Consultar uma lista de cursos com totalização dos cursos
recuperados é um exemplo de Saída Externa. Essa apresentação de dados requer um
cálculo de total de registros recuperados.
33
Outro exemplo de SE é a emissão de certificado com atualização de indicador de status
de certificado emitido. A emissão de certificado apresenta os dados em papel e atualiza
um atributo de status de emissão em um ALI.
Como terceiro exemplo de Saída Externa, consideremos a emissão de uma lista final
de notas de alunos com a seguinte regra: se o aluno tiver nota igual ou superior a 70%
exibir o nome do aluno em azul; se o aluno tiver nota inferior a 70% exibir o nome do
aluno em vermelho. O procedimento deve recuperar o nome e a nota do aluno e tomar a
decisão de exibir o nome do aluno em azul ou em vermelho. Ou seja, o nome do aluno
exibido em azul ou vermelho não é um dado recuperado. A criação da informação nome
do aluno em azul ou vermelho com base em um algoritmo, atendendo a uma necessidade
de negócio do usuário, é uma lógica de derivação de dados. Portanto, a funcionalidade é
classificada como Saída Externa, devido à lógica de derivação de dados.
Ex: SE: Consultar Desembarque em Voos Nacionais
3.7. CONTAGEM DAS FUNÇÕES DE DADOS
As funções de dados representam os requisitos de dados da aplicação,

considerando a visão do usuário, ou seja requisitos de negócio. Os dados podem ser
internos à aplicação - Arquivo Lógico Interno (ALI) ou Externos à aplicação - Arquivo de
34
Interface Externa (AIE). Apresentamos abaixo explicações mais detalhadas sobre o
assunto.
 Arquivo Lógico Interno (ALI)

por meio de um processo elementar da aplicação que está sendo contada.
Observe que o ALI é um grupo independente de dados, representado em um modelo

de dados por meio de uma entidade, mantido por alguma funcionalidade da aplicação.
Assim, as tabelas estáticas mantidas manualmente pela equipe de desenvolvimento não
são contadas. As entidades dependentes fazem parte de um mesmo ALI.
Os grupos de dados não reconhecidos pelo usuário, por exemplo, arquivos

temporários, arquivos de trabalho, arquivos criados para apoiar o processo de
implementação, não são contados.
 Arquivo de Interface Externa (AIE)

por meio de um processo elementar de uma outra aplicação e referenciado pela aplicação
que está sendo contada. O AIE é obrigatoriamente um ALI de outra aplicação.
Observe que o AIE é um grupo dados referenciado pela aplicação sendo contada
para apoiar validações de dados, cálculos ou apresentação de dados em consulta ou
relatórios.
Se um grupo de dados é lido e mantido deve-se contar como ALI. Por exemplo, o
Sistema da loja ABC lê os dados de clientes do Sistema Matriz (nome, endereço e
telefone) e também atualiza dados de produtos de interesse do cliente. O Sistema da loja
ABC conta a entidade de Clientes como ALI. Um grupo de dados pode ser contado como
ALI para várias aplicações.
Como o AIE é obrigatoriamente um ALI de outra aplicação, então os arquivos

temporários, arquivos de trabalho e arquivos criados para apoiar a implementação
também não são contados.
35
3.7.1 Classificação de Funções de Dados
As funções de dados são classificadas de acordo com a Complexidade: Baixa,

Média ou Alta. Essa classificação leva em consideração a quantidade de Registros
Lógicos e a quantidade de Tipos de Dados, de acordo com a Tabela abaixo:
1 a 19 20 a 50 51 ou mais
Tipos de Dados Tipos de Dados Tipos de Dados
1 Registro Lógico BAIXA BAIXA MÉDIA
2 a 5 Registros Lógicos BAIXA MÉDIA ALTA
6 ou mais Registros Lógicos MÉDIA ALTA ALTA
Registro Lógico (RL)
O Registro Lógico é um subgrupo de dados reconhecido pelo usuário. O RL faz

parte do ALI ou AIE. Em geral, os subgrupos de dados são reconhecidos em modelos de
dados como especializações ou entidades fracas.
Por exemplo, um sistema de recursos humanos mantém dados de empregadas(os)

e seus dependentes. Considerando a contagem de Função de dados tem-se: ALI:
Empregados com 2 RLs - empregados e dependentes.
Tipo de Dados (TD)
Campos únicos, não repetidos, reconhecidos pelo usuário. Em geral, são os

atributos das entidades. Como exemplo, podemos imaginar uma entidade denominada
Instrutor, mantida por um sistema de treinamento e que possui os seguintes atributos:
 cod_instrutor - (campo chave não reconhecido pelo usuário, criado para apoiar a
implementação);
 nome do instrutor;
 e-mail do instrutor;
 telefone de contato 1;
 telefone de contato 2;
 currículo resumido.
O ALI instrutor possui 4 TDs (nome do instrutor, e-mail do instrutor, telefone de

contato, currículo resumido). O cod instrutor não conta porque não é reconhecido pelo
usuário. O telefone de contato conta apenas uma vez, por se tratar de um atributo
repetitivo.
36
3.7.2 Contribuição Funcional das Funções de Dados
A contribuição funcional para a contagem de pontos de função do sistema dos

Arquivos Lógicos Internos e Arquivos de Interface Externa é definida de acordo com a
complexidade (baixa, média ou alta), conforme as tabelas abaixo.
Exemplo 1: Suponha um sistema de gestão de projetos que mantém dados dos projetos
de uma organização. A Entidade Projeto possui associação de dependência com uma
entidade Equipe do Projeto.
A Entidade Projeto possui os seguintes atributos:

 Cod Projeto (identificador sequencial não reconhecido pelo usuário)
 Nome do Projeto
 Objetivo do Projeto
 Data Início
 Data fim
 Esforço estimado
 Custo estimado
A Entidade Equipe do Projeto possui os seguintes atributos:

 Cod Projeto (identificador sequencial não reconhecido pelo usuário)
 Nome do Participante
 Tipo de participação (líder, substituto do Líder, equipe)
 Papel desempenhado no projeto
 Atividades alocadas
A contagem de PF das funções de dados apresentadas é a seguinte.
ALI: Projeto;
RL: 2 (Projeto e Equipe do Projeto);
37
TD: 10 (Nome do Projeto, Objetivo do Projeto, Data Início, Data fim, Esforço estimado,
Custo estimado, Nome do Participante, Tipo de participação, Papel desempenhado no
projeto, Atividades alocadas);
Complexidade: Baixa;
Tamanho: 7 PF.
Exemplo 2:
O Sistema de Treinamentos deve apresentar uma Lista com o nome dos Municípios
e a UF associada com dados recuperados da Tabela de Municípios do Sistema do IBGE.
Observe que considerando a visão do usuário do Sistema de Treinamentos, a Tabela de
Municípios possui apenas dois atributos (nome do município e UF) lido de uma outra
aplicação (Sistema do IBGE).
A Contagem de PF da função de dados do Sistema de Treinamento apresentada é a

seguinte:
AIE: Município;
RL: 1 (dados de municípios);
TD: 2 (nome do município, UF);
Complexidade: Baixa;
Tamanho: 5 PF.
3.7.3 Contagem das Funções de Dados de uma Aplicação
Quando estamos contando as funções de dados de um sistema, devemos analisar o

Modelo de Dados, caso ele esteja disponível, ou a especificação para identificar as
entidades lógicas de dados. Estas entidades de dados são candidatas a serem contadas
como: Arquivos Lógicos Internos (ALI) ou Arquivos de Interface Externa (AIE).
Uma vez, identificada uma Entidade de Dados, devemos verificar se esta deve ser
contada como ALI ou AIE ou Não ser contada.
Cabe ressaltar que entidades físicas não reconhecidas pelo usuário, por exemplo,
arquivos temporários, ou qualquer outro tipo de tabela criada para apoiar a construção de
código não deve ser contado como Arquivos Lógicos: ALI ou AIE.
Devemos responder as seguintes questões para verificar se a Entidade de Dados é
um ALI:
Nome do Arquivo: _____________
38
- É um grupo de dados reconhecido pelo usuário? Sim
- Arquivo é mantido por algum processo elementar? Sim
- É mantido pela aplicação que está sendo contada? Sim
O ALI é um grupo lógico de dados reconhecido pelo usuário mantido por um

processo elementar da aplicação sendo contada.
Devemos responder as seguintes questões para verificar se a Entidade de Dados é

um AIE:
Nome do Arquivo: _____________
– É um grupo de dados reconhecido pelo usuário? Sim
– Arquivo é mantido por algum processo elementar? Sim
– É mantido pela aplicação que está sendo contada? Não
– É mantido por um processo elementar de outra aplicação? Sim
O AIE é um grupo lógico de dados reconhecido pelo usuário referenciado pela

aplicação sendo contada. O AIE obrigatoriamente é um ALI de outra aplicação.
Portanto, é mantido por um processo elementar de outra aplicação. E lido por
processos elementares da aplicação sendo contada, por exemplo, para validação
de dados.
Observe que uma Entidade de Dados para ser contada como ALI ou AIE precisa ser
mantida por pelo menos um Processo Elementar, funcionalidade, da aplicação sendo
contada (ALI) ou de outra aplicação (AIE). As Entidades de dados de domínio mantidas
que não são mantidas pela aplicação não devem ser contadas. Muitas vezes, estas
tabelas são mantidas manualmente pelo programador ou DBA quando precisam ser
atualizadas.
3.7.4 Estudo de Casos: Contagem Função de Dados
Segue um Estudo de Caso para praticarmos a Contagem de Pontos de Função de

Funções de Dados: Arquivos Lógicos Internos (ALI) e Arquivos de Interface Externa (AIE).
Vamos contar as funções de dados do Sistema de Agenda de Compromissos.
39
Descrição do Sistema de Agenda de Compromissos
O Presidente da empresa Inovação solicitou o desenvolvimento de um Sistema de
Agenda de Compromissos para seus Gerentes cadastrarem os Compromissos e
Aniversário dos empregados da empresa. O sistema deve ler a tabela de Empregados do
Sistema de Recursos Humanos (SRH) para acesso ao nome, departamento, e-mail e
telefones para contato com o empregado. Segue o Modelo de Dados do Sistema.
Modelo de Dados do Sistema de Agenda de Compromissos
Segue a descrição das entidades de dados do Modelo Lógico de Dados da Aplicação.
Tabela de Compromissos
Esta tabela é utilizada para armazenar os dados de compromissos cadastrados na
aplicação.
 Identificador do Compromisso (Campo Físico)
 Nome do Compromisso
 Descrição do Compromisso
 Tipo do Compromisso
 Data do Compromisso
 Hora do Compromisso
 Nome do Local do Compromisso
 Telefone do Local
 Endereço do Local – Rua, Compl, Bairro
 Endereço do Local – Município
 Endereço do Local – UF
40
Tabela de UFs
Esta tabela é utilizada para alimentar a combobox de UFs, visando minimizar a digitação
do usuário e melhorar a consistência da entrada de dados de UF na tela de cadastro de
compromissos.
 Código da UF (Campo Físico)
 Sigla da UF
 Descrição da UF
Tabela de Tipo do Compromisso

Esta tabela é utilizada para validação do tipo de compromisso é uma tabela estática não é
mantida pela aplicação. A tabela será mantida pelo DBA da aplicação, caso seja
necessário.
 Código do Tipo de Compromisso (Campo Físico)
 Descrição do Tipo de Compromisso
Tabela de Aniversários
Esta tabela é utilizada para armazenar as datas de aniversário dos empregados da
empresa cadastrados pela aplicação.
 Matricula do empregado
 Data do Aniversário
Tabela de Empregados
Esta tabela é mantida pelo Sistema de Recursos Humanos (SRH), sendo acessada pelo
Sistema de Agenda Corporativo para leitura de dados dos empregados da empresa.
 Nome do empregado
 Telefone do empregado –DDD
 Telefone do empregado – num. Telefone
 Telefone Celular do empregado
 e-mail do empregado
 Departamento do empregado
Realize a Contagem das funções de dados do Sistema de Agenda Corporativo com

base na descrição do sistema, modelo de dados e descrição das entidades de dados
apresentados.
Acompanhe a resolução deste exercício.
1) Análise da Entidade de Dados de Compromissos
Tabela de Compromissos
 Nome do Compromisso
 Descrição do Compromisso
 Tipo do Compromisso
 Data do Compromisso
41
 Hora do Compromisso
 Nome do Local do Compromisso
 Telefone do Local
Esta entidade lógica de dados é reconhecida pelo usuário e é mantida por um

processo elementar de cadastro de dados do sistema sendo contado. Desta forma, é
contada como Arquivo Lógico Interno (ALI).
“Esta tabela é utilizada para armazenar os dados de compromissos cadastrados na

aplicação.”
Como não existem subgrupos de dados com relacionamento de dependência com

esta entidade, por exemplo, entidades fracas ou especializações. Então, contamos
apenas 1 Registro Lógico (RL) – Compromissos.
Os Tipos de Dados (TD) são os campos lógicos, únicos e não repetidos reconhecidos
pelo usuário. Desta forma:
não conta como TD por se tratar de um Campo Físico.
Os 3 Campos Físicos associados a Endereço

contam como apenas 1 TD – Endereço do Local, por se tratarem da subdivisão de um
Tipo de Dados maior.
Portanto, contamos a Entidade de Dados de Compromissos da seguinte forma:
ALI: Compromissos
RL: 1 – Compromissos
TD: 8 - Nome do Compromisso, Descrição do Compromisso, Tipo do Compromisso, Data
do Compromisso, Hora do Compromisso, Nome do Local do Compromisso, Telefone do
Local, Endereço do Local
Complexidade: Baixa
Contribuição Funcional: 7 PF
Observe que os campos de Data do Compromisso, Hora do Compromisso foram

contados como TDs independentes, considerando que na visão do usuário seja
importante consultar quantas reuniões ele terá em um dia específico.
42
2) Análise da Entidade de Dados de UF
Tabela de UFs
 Código da UF (Campo Físico)
 Sigla da UF
 Descrição da UF
Observe que esta entidade não tem como objetivo o armazenamento de dados de
negócio do usuário. A implementação desta entidade de dados está associada a
requisitos não funcionais: minimizar a digitação do usuário e melhorar a consistência da
entrada de dados.
“Esta tabela é utilizada para alimentar a combobox de UFs, visando minimizar a digitação
do usuário e melhorar a consistência da entrada de dados de UF na tela de cadastro de
compromissos.”
Além disso, observe que esta entidade de dados não é mantida por um processo
elementar da aplicação. Desta forma, esta entidade de dados não deve ser contada,
representa a implementação de dados de domínio da aplicação.
O Manual de Práticas de Contagem (CPM) denomina estas entidades que
armazenam dados de código, descrição e outros atributos descrevendo o código,
utilizadas para implementação de requisitos não funcionais, como Dados de Código
(Code Data). As entidades do tipo Dados de Código não devem contadas.
3) Análise da Entidade de Dados de Tipo do Compromisso
Tabela de Tipo do Compromisso

 Código do Tipo de Compromisso (Campo Físico)
 Descrição do Tipo de Compromisso
Observe que esta entidade não tem como objetivo o armazenamento de dados de
negócio do usuário. A implementação desta entidade de dados está associada ao
requisito não funcional de implementação da validação de dados.
“Esta tabela é utilizada para validação do tipo de compromisso é uma tabela estática não
é mantida pela aplicação. A tabela será mantida pelo DBA da aplicação, caso seja
necessário.”
Além disso, observe que esta entidade de dados não é mantida por um processo
elementar da aplicação. Desta forma, esta entidade de dados não deve ser contada,
representa a implementação de dados de domínio da aplicação.
43
O Manual de Práticas de Contagem (CPM) denomina estas entidades que
armazenam dados de código, descrição e outros atributos descrevendo o código,
utilizadas para implementação de requisitos não funcionais, como Dados de Código
(Code Data).
As entidades do tipo Dados de Código não devem contadas.
4) Análise da Entidade de Dados de Aniversários
Tabela de Aniversários
 Data do Aniversário
Esta entidade lógica de dados é reconhecida pelo usuário e é mantida por um

processo elementar de cadastro de dados do sistema sendo contado. Desta forma, é
contada como Arquivo Lógico Interno (ALI).
“Esta tabela é utilizada para armazenar as datas de aniversário dos empregados da

empresa cadastrados pela aplicação.“

apenas 1 Registro Lógico (RL) – Aniversários.
Os Tipos de Dados (TD) são campos lógicos, únicos e não repetidos reconhecidos
pelo usuário. Os campos requeridos para o relacionamento com outras entidades de
dados (chaves estrangeiras) também devem ser contados como tipo de dados.
Desta forma,
deve ser contado como Tipo de Dados (TD).
Portanto, contamos da seguinte forma:

ALI: Aniversários
RL: 1 – Aniversários
TD: 2 – Matricula do Empregado, Data do Aniversário
Complexidade: Baixa
44
5) Análise da Entidade de Dados de Empregados
Tabela de Empregados
 Nome do empregado
 Telefone Celular do empregado
 e-mail do empregado
 Departamento do empregado
Esta entidade lógica de dados é reconhecida pelo usuário e é mantida por outra
fronteira de aplicação (SRH), sendo lida pelo sistema que está sendo contado. Desta
forma, é contada como Arquivo de Interface Externa (AIE).
“Esta tabela é mantida pelo Sistema de Recursos Humanos (SRH), sendo acessada pelo
Sistema de Agenda Corporativo para leitura de dados dos empregados da empresa.”

apenas 1 Registro Lógico (RL) – Empregados.
Os Tipos de Dados (TD) são os campos lógicos, únicos e não repetidos

reconhecidos pelo usuário. As subdivisões de um tipo de dados maior, por exemplo,
dados de endereço que podem ser armazenados em vários campos (logradouro,
complemento, Bairro, CEP, Cidade, UF) devem ser contados como apenas 1 TD. Assim,
contam como apenas 1 TD – Telefone do Empregado.
Observe que na contagem dos Registros Lógicos e Tipo de Dados do AIE

consideramos apenas os campos lidos pela aplicação em questão. Ou seja, mesmo que
no Sistema de Recursos Humanos sejam mantidos outros dados de empregados, estes
não serão contados como TDs do AIE Empregados porque não são lidos pelo Sistema de
Agenda de Compromissos.
Portanto, contamos da seguinte forma:
AIE: Empregados
RL: 1 – Empregados
TD: 6 – Matricula do empregado, Nome do empregado,Telefone do empregado, Telefone
Celular do empregado,e-mail do empregado,Departamento do empregado
45
Complexidade: Baixa
Segue a Contagem das Funções de Dados do Sistema de Agenda de Compromissos.

ALI: Compromissos
RL: 1 – Compromissos
TD: 8 - Nome do Compromisso, Descrição do Compromisso, Tipo do Compromisso, Data
do Compromisso, Hora do Compromisso, Nome do Local do Compromisso, Telefone do
Local, Endereço do Local
Complexidade: Baixa
ALI: Aniversários
RL: 1 – Aniversários
TD: 2 – Matricula do Empregado, Data do Aniversário
Complexidade: Baixa
AIE: Empregados
RL: 1 – Empregados
TD: 6 – Matricula do empregado, Nome do empregado,Telefone do empregado, Telefone
Celular do empregado,e-mail do empregado,Departamento do empregado
Complexidade: Baixa
3.8 CONTAGEM DAS FUNÇÕES TRANSACIONAIS
Uma função de transação é um processo elementar que fornece funcionalidades

para processar dados. Pode ser identificada como: Entrada Externa, Saída Externa, ou
Consulta Externa. Na contagem de Pontos de Função de funções transacionais, o
primeiro passo é a identificação do Processo Elementar.
Observe que Entrada Externa, Consulta Externa e Saída Externa são processos
elementares.
46
Primeiro passo: Identificar um Processo Elementar
Um processo elementar é a menor unidade de atividade significativa para o usuário. O

processo elementar é uma transação completa em si mesma e deixa o negócio da
aplicação sendo contada em um estado consistente.
Dicas para ajudar na identificação de processos elementares:
 Identifique as funcionalidades da aplicação, um processo elementar é uma

transação completa.
 Funcionalidades sequenciais fazem parte do mesmo processo elementar.

Funcionalidades independentes devem ser contadas como processos elementares
distintos.
 Exemplo de Funcionalidades sequenciais que devem acontecer juntas: inscrever

participante para um curso e enviar um e-mail confirmando a inscrição. Observe
que o preenchimento do cadastro de participantes e o envio do e-mail fazem parte
de um mesmo processo elementar. Contar como um único processo elementar.
 Exemplo de Funcionalidades independentes: Incluir curso e Alterar curso. Mesmo

parecidas a inclusão de um curso e a alteração de dados de um curso cadastrado
ocorrem em momentos distintos, constituindo processos elementares separados.
Contar como dois processos elementares separados.
Seguem as lógicas de processamento executadas pelos processos elementares

classificadas pelos tipos funcionais.
47
Lógicas de Processamento Utilizadas por EEs, CEs e SEs
Forma de Processamento Lógico EE SE CE
Validações são realizadas P P P
Cálculos são efetuados P O* N
Valores equivalentes são convertidos P P P
Filtro e seleção de dados com base em critérios específicos para comparar grupos
P P P
de dados
Condições são analisadas para determinar quais são aplicáveis P P P
Atualização de pelo menos um ALI O* O* N
No mínimo um ALI ou AIE é referenciado P P O
Dados ou informações de controle são recuperados P P P
Dados derivados são criados P O* N
Alteração do Comportamento do Sistema O* O* N
Prepara e apresenta informações fora da fronteira da aplicação P O O
Capacidade de aceitar dados ou informações de controle que entram pela fronteira
O P P
da aplicação
Reordena ou Reorganiza um conjunto de dados P P P
Onde:
O: Obrigatório – Lógica de processamento obrigatória para a função
O*: Pelo menos uma das lógicas O* é obrigatória para o tipo de função
P: Pode – A lógica de processamento pode ser executada pela função
N: Não Pode – Não pode ser executada pela função
Algumas observações importantes:
 A lógica de processamento "Reordena ou Reorganiza um conjunto de dados" é a

única lógica que não fornece unicidade para as funções transacionais. Por
exemplo, uma Consulta de alunos ordenada por nome e uma outra Consulta de
alunos ordenada por matrícula devem ser contadas como um único processo
elementar.
 Toda Consulta Externa deve ler dados de pelo menos um Arquivo Lógico (ALI ou
AIE).
48
 Uma Entrada Externa pode ter dados calculados. Por exemplo, na função incluir
vendas, sempre que for adicionado um item, o preço do item vendido deve ser
somado ao campo de total de vendas.
 Uma Saída pode ter entrada de dados (Capacidade de aceitar dados ou

informações de controle que entram pela fronteira da aplicação). Por exemplo, o
relatório de projetos concluídos possui uma tela de filtros para o usuário selecionar
uma UF ou todas e entrar com uma data inicial e uma data final. Com base nesses
parâmetros de entrada, a funcionalidade recupera uma lista de projetos concluídos
e apresenta o total.
Segundo passo: Definir se o processo elementar identificado é uma Entrada

Externa, Consulta Externa ou Saída Externa
Seguem as definições dos tipos de função de transação.
Entrada Externa: É um processo elementar que processa dados ou informação de

controle que entram pela fronteira da aplicação. Seu objetivo principal é manter um ou
mais ALI ou alterar o comportamento do sistema. Por exemplo, em um Sistema de
Cadastro de Treinamentos a funcionalidade de Alterar dados de um curso é um exemplo
de Entrada Externa.
Exemplo: Realizar inscrição no CONSEGI
49
O usuário insere seus dados para se inscrever no CONSEGI. Observe que a
funcionalidade tem como propósito processar dados recebidos de fora da fronteira da
aplicação (dados do usuário) para atualizar o Arquivo Lógico Interno - Inscrições. Os
dados inseridos pelo usuário estão atravessando a fronteira da aplicação.
Consulta Externa: É um processo elementar que envia dados ou informação de controle

para fora da fronteira da aplicação. Seu objetivo principal é apresentar informação para o
usuário através da recuperação de dados ou informação de controle de ALI ou AIE. O
processamento lógico da CE não contém cálculo, não cria dados derivados, não mantém
ALI e não altera o comportamento do sistema.
Função Transacional com objetivo de apresentar informações para o usuário ou

outra aplicação por meio de recuperação de dados de ALI ou AIE. Por exemplo, em um
Sistema de Cadastro de Treinamentos a funcionalidade de Consultar dados de um curso
específico é um exemplo de Consulta Externa. Observe que todos os dados são
recuperados do ALI de cursos.
Exemplo: Consultar oficinas do CONSEGI.
50
A funcionalidade apresenta para o usuário uma lista com todas as Oficinas
cadastradas para o evento CONSEGI. Observe que funcionalidade tem como propósito
recuperar dados do Arquivo Lógico Interno Oficinas e apresentar para fora da fronteira da
aplicação (usuário). Os dados das oficinas apresentados para o usuário estão
atravessando a fronteira da aplicação.
Saída Externa: É um processo elementar que envia dados ou informação de controle

para fora da fronteira da aplicação. Seu objetivo principal é apresentar informação para
um usuário ou outra aplicação através de um processamento lógico adicional à
recuperação de dados ou informação de controle. O processamento lógico deve conter
cálculo, ou criar dados derivados, ou manter ALI ou alterar o comportamento do sistema.
Função Transacional com objetivo de apresentar informações para o usuário ou

outra aplicação com derivação de dados ou cálculos ou mudança de comportamento ou
atualização de ALI. Por exemplo, em um Sistema de Cadastro de Treinamentos a
funcionalidade de Consultar uma lista de cursos com totalização dos cursos recuperados
é um exemplo de Saída Externa. Observe que essa apresentação de dados requer um
cálculo de total de registros recuperados. Outro exemplo de SE é a emissão de certificado
com atualização de indicador de status de certificado emitido. Observe que a emissão de
certificado apresenta os dados em papel e atualiza um atributo de status de emissão de
um ALI.
Outro exemplo de Saída Externa é a emissão de uma lista final de notas de alunos
com a seguinte regra: se o aluno tiver nota igual ou superior a 70%, exibir o nome do
aluno em azul; se o aluno tiver nota inferior a 70%, exibir o nome do aluno em vermelho.
Observe que a funcionalidade recupera o nome e a nota do aluno e toma uma decisão de
exibir o nome do aluno em azul ou vermelho. Ou seja, o nome do aluno exibido em azul
ou vermelho não é um dado recuperado. A criação da informação nome do aluno em azul
ou vermelho com base em um algoritmo, atendendo a uma necessidade de negócio do
usuário, é uma lógica de derivação de dados. Portanto, a funcionalidade é classificada
como Saída Externa, devido à lógica de derivação de dados.
51
Exemplo: Consultar Desembarque em Voos Domésticos.
A funcionalidade apresenta para o usuário uma lista contendo informações de

desembarque em voos. Observe que a funcionalidade tem como propósito apresentar
dados de Desembarque fora da fronteira da aplicação e realizar cálculos de totalização
dos desembarques. Os dados dos desembarques e totalizadores apresentados estão
atravessando a fronteira da aplicação.
3.8.1 Classificação das Funções Transacionais
Uma vez identificada, a função transacional deve ser classificada de acordo com sua
complexidade: Baixa, Média ou Alta. Seguem as Tabelas de Classificação das Funções
Transacionais.
52
Tabelas de Complexidade Funcional - Funções Transacionais (EEs, SEs, CEs)
Algumas definições importantes:
Arquivo Referenciado (AR): Os Arquivos Referenciados levam em consideração os

ALIs e AIEs atualizados ou lidos durante o processamento de uma EE, SE ou CE.
Exemplo 1: A Entrada Externa Cadastrar projetos atualiza o ALI de projetos e lê

dados do AIE Empregados para recuperar o nome do líder do projeto. Então, a EE
Cadastrar projetos possui 2 Arquivos Referenciados.
Exemplo 2: A Saída Externa Emitir Certificado do Treinamento recupera informações

do ALI Alunos, ALI Cursos e atualiza o indicador de certificado emitido do ALI de Controle
Emissão de Certificados. Então, a SE Emitir Certificado de Treinamento possui 3 Arquivos
Referenciados.
Exemplo 3: A Consulta Externa List Box de cursos recupera os dados do ALI de

cursos. Então, a CE List Box de cursos possui 1 Arquivo Referenciado.
Tipo de Dado (TD): O número de Tipos de Dados Referenciados é o total de

atributos identificados pelo usuário que atravessam a fronteira da aplicação durante o
processamento de uma EE, SE ou CE.
53
Os dados que o usuário (usuário final ou outra aplicação) informa para a
funcionalidade em questão, entram pela fronteira da aplicação. Os dados que a
funcionalidade em questão apresenta para o usuário (usuário final ou outra aplicação) em
qualquer meio: tela, arquivo, papel... saem pela fronteira da aplicação. Os dados que
entram ou saem pela fronteira da aplicação atravessam a fronteira da aplicação.
O conceito de atravessar a fronteira significa que não devem ser contados como
TDs campos que são apenas utilizados pela função para processamento interno, mas não
entram ou saem pela fronteira da aplicação. Também não são contados números de
páginas, mesmo que a implementação destes não seja facilitada pela ferramenta de
programação (ex: pag 2/10) e data e hora de emissão de relatórios fornecidas pelo
sistema operacional.
Além dos dados que atravessam a fronteira, são contados 1 TD para ação, botões
de ação (OK, dropdown de listbox, links para chamar outras funcionalidades...) e 1 TD
para mensagem (mensagens de validação de campos, mensagens de confirmação de
processamento...).
O TD é contado pela capacidade da função de ter ação e de enviar mensagem.

Lembre-se: UM e apenas UM TD para Todas as ações e UM e apenas UM TD para
Todas as mensagens.
3.8.2 Contribuição Funcional das Funções Transacionais
A contribuição funcional para a contagem de pontos de função do sistema das

Entradas Externas, Consultas Externas e Saídas Externas é definida de acordo com a
complexidade (baixa, média ou alta), cujos parâmetros são descritos pelas tabelas abaixo.
Vejamos então alguns exemplos de medição da complexidade da função

transacional para a determinação de seus valores funcionais.
54
Exemplo 1: Consultar Oficinas do CONSEGI
Descrição: O usuário clica em um botão Consultar Oficinas em uma tela inicial de

chamada da consulta. A funcionalidade apresenta para o usuário uma lista com todas as
Oficinas cadastradas para o evento CONSEGI.
CE: Consultar Oficinas do CONSEGI
AR: 1 (Oficinas)
TD: 6 (Nome, Oficineiro, Local, Data Início, Data fim, Ação - botão de ação da tela inicial
da consulta)
Complexidade: Baixa
Tamanho: 3 PF
55
Exemplo 2: Alterar reservas de hotel
Descrição: A Função Alterar Reservas do Hotel ABC atualiza o ALI Reservas e valida o
Nome do Funcionário no AIE Funcionário e valida o código do cliente no ALI Clientes.
Caso o funcionário ou cliente não existam, é apresentada uma mensagem para o usuário.
EE: Alterar Reservas
AR: 3 (Reservas, Clientes, Funcionários).
TD: 11 (Número de Reserva, Matrícula do Funcionário, Código do Cliente, Data Reserva,

Período Início, Período Fim, Tipo do Apartamento, Sobrenome, Nome, Ação – botão OK e
Mensagem – são exibidas mensagens de validação).
Complexidade: Alta.
Tamanho: 6 PF.
Exemplo 3: Estimar Esforço
56
Descrição: Esta funcionalidade permite ao usuário obter uma estimativa rápida de
esforço de um projeto. O usuário entra com o tamanho funcional do projeto em PF e o
índice de produtividade em horas/PF a ser utilizado para estimar o esforço do projeto em
questão. Quando o usuário clica no botão calcular, a funcionalidade valida se os dois
parâmetros foram preenchidos, apresentando mensagem de "tamanho do projeto não
informado" ou " índice de produtividade não informado". Caso os dois campos estejam
preenchidos, a funcionalidade calcula o esforço multiplicando o tamanho do projeto pelo
índice de produtividade e apresenta o resultado.
SE: Estimar Esforço
AR: 0 (a funcionalidade não referencia Arquivo Lógico. A referência a arquivo lógico não é
uma lógica de processamento obrigatória para a SE. É uma lógica obrigatória para a CE).
TD: 5 (Tamanho, Produtividade, Esforço, ação - botão Calcular, mensagem - para as

mensagens de validação de preenchimento de campos)
Complexidade: Baixa.
Tamanho: 4 PF.
Exemplo 4: Sistema PONTUA - Consultar Projetos de uma Aplicação
Descrição: O usuário seleciona uma aplicação e clica no botão Consultar Projetos. A

funcionalidade apresenta uma lista de todos os projetos de software cadastrados para a
aplicação em questão.
CE: Consultar Projetos de uma Aplicação AR: 1 (Aplicação/Projetos).
TD: 8 (Nome da aplicação, Nome do projeto, Descrição do projeto, Data de Criação, Data
de Encerramento, Situação, Qtde PF, ação).
Complexidade: Baixa.
57
Tamanho: 3 PF.
Observação: O TD Nome da aplicação entra e sai pela fronteira da aplicação, sendo um

atributo de seleção para a consulta e sendo apresentado na tela de resultados da
consulta. Se um TD entra e sai pela fronteira da aplicação, este deve ser contado apenas
uma vez. Nesta funcionalidade não são exibidas mensagens para o usuário, visto que a
aplicação é selecionada por meio de uma lista. E ainda, toda aplicação terá pelo menos
um projeto de desenvolvimento associado.
Exemplo 5: Sistema SGI - Registrar Apropriação
Descrição: O usuário seleciona a Data para registro da apropriação, seleciona a Unidade

de Gestão do projeto cujas horas de apropriação serão registradas (UG Cliente). A check
box Lotações Superiores será utilizada apenas para a apresentação de Projeto/Serviços
na combo. O usuário então seleciona o Projeto, registra as horas a serem apropriadas no
projeto em questão, seleciona a macroatividade e o insumo. Opcionalmente, o usuário
pode informar uma Observação associada à Apropriação. A Checkbox “Exibe
apropriações do período” é uma outra funcionalidade de consulta que apresenta as
apropriações já realizadas no mês em questão pelo usuário. Ao clicar no botão "incluir" a
apropriação é cadastrada. Caso o usuário não preencha alguma informação obrigatória,
serão apresentadas mensagens de validação para o usuário.
EE: Registrar Apropriação.
AR: 3 (Apropriação, Projeto, Empregado).
58
TD: 9 (Data, UG Cliente, Projeto, horas, macroatividade, insumo, observação, ação –
botão incluir, mensagens validação).
Complexidade: Alta
Tamanho: 6 PF.
Observação: O botão limpar não tem contagem de PF, trata-se da implementação de um

requisito não funcional de usabilidade para apagar as informações digitadas pelo usuário
(não se trata de uma funcionalidade de exclusão de registros em arquivos). As combos
com dados recuperados de Arquivos Lógicos devem ser contadas à parte como Consultas
Externas. Por exemplo, a combo Projeto é uma Consulta Externa, recuperando os
projetos da UG em questão nos quais o empregado se encontra como recurso alocado.
Por outro lado, a combo data não é uma Consulta Externa, porque Data não é um Arquivo
Lógico. Ao contar os TDs da Entrada Externa devem ser contados apenas os TDs que
atravessam a fronteira da aplicação no Registro da Apropriação, por isso não foram
contadas as check boxes. Estas estão associadas às consultas e não à funcionalidade de
Registro da Apropriação.
Exemplo 6: Sistema SISCOP - Relatório de Incentivo à Instrutoria
Descrição: O usuário seleciona a opção do menu Consultas “Incentivo à Instrutoria”. A

funcionalidade apresenta o crédito em minutos associado ao incentivo à instrutoria para o
empregado em questão. Além do crédito, são realizados cálculos para a apresentação do
59
Saldo consolidado. Caso o empregado não tenha realizado atividades associadas à
instrutoria, então é apresentada a mensagem “o empregado não participou de eventos de
incentivo à instrutoria”.
SE: Relatório de Incentivo à Instrutoria.
AR: 4 (Evento Incentivo Instrutoria, Empregado, Lotação, Extrato de Horas).
TD: (Lotação, Matrícula, Nome empregado, Data Referência, Data Evento, Crédito,
Débito, Greve, Saldo, mensagem).
Complexidade: Alta.
Tamanho: 7 PF.
Observação: Os atributos Título do Relatório, Data/Hora de Emissão não são contados

como TDs. Nesta funcionalidade não há contagem de botão de ação, porque esta é
chamada diretamente do menu.
Exemplo 7: Sistema Agenda Nacional – Relatório de Eventos
Descrição – Tela de Filtro: O usuário define o período – data inicial e data final e o tipo
do evento que deseja emitir o relatório. Clica no botão “Emitir” e o sistema emite o
relatório desejado.
O usuário pode clicar no calendário para identificar a data inicial e final ou digitar. O
calendário é um recurso para atender o um requisito não funcional de usabilidade,
portanto não possui contagem de Pontos de Função.
Cabe ressaltar que esta tela de filtros é parte de dois processos elementares distintos.
“Relatório de Eventos – Videoconferências” e “Relatórios de Eventos – Não
Videoconferências”. Estes dois relatórios são considerados processos elementares
distintos porque os filtros “tipo de eventos” são mutuamente excludentes. O requisito
60
funcional é de emissão de dois relatórios independentes que não podem ser combinados.
Desta forma, para a contagem de Pontos de Função destes relatórios, torna-se
necessário observar os dados que saem pela fronteira da aplicação, ou seja, a tela de
resultados. Observe que a tela de filtro e a tela de resultados fazem parte do mesmo
processo elementar.
Segue a tela de resultado e a contagem de PF do Relatório de Eventos –

Videoconferências
Descrição – Tela de Resultado: Relatório de Eventos - Videoconferência:
Ao clicar no botão “Emitir” com o Tipo do Evento “Videoconferências” selecionado, o

sistema gera um arquivo .pdf com as informações do relatório solicitado. Observe que é
apresentado o Título do Relatório, que não é contado como TD por se tratar de um dado
estático. Também são apresentados os dados do filtro período “data inicial” e “data final”.
Estes campos entram (tela de filtros) e saem (tela de resultados) pela fronteira da
aplicação e devem ser contados apenas uma vez, considerando o processo elementar -
“Relatório de Eventos- Videoconferência”. A informação de paginação “Página 1” não
conta como TD. As informações de data e hora de emissão de relatório também não
contam como TD. A informação de “Locais de Recepção” é um campo repetitivo, conta
apenas uma vez. Este Relatório é uma Consulta Externa porque consiste em uma
recuperação de dados, sem derivação de dados, sem mudança de comportamento do
sistema, sem dados calculados, sem atualização de ALI.
CE: Relatório de Eventos - Videoconferência.
AR: 4 (Evento, Local, Usuário, Clientes).
TD: 15 (Data Início, Data Fim, Ação, Mensagem, Data, Hora Inicial, Hora Final, Tipo,
Nome do Evento, Local de Transmissão, Reservado por, Responsável, Unidade, Cliente,
Locais de Recepção).
Complexidade: Alta.
61
Tamanho: 6 PF.
Segue a tela de resultado e a contagem de PF do Relatório de Eventos – Não

Videoconferências
Descrição – Tela de Resultado: Relatório de Eventos - Videoconferência:
Ao clicar no botão “Emitir” com o Tipo do Evento “Somente Eventos que não são
videoconferências” selecionado, o sistema gera um arquivo .pdf com as informações do
relatório solicitado. Observe que é apresentado o Título do Relatório, que não é contado
como TD por se tratar de um dado estático. Também são apresentados os dados do filtro
período “data inicial” e “data final”. Estes campos entram (tela de filtros) e saem ( tela de
resultados) pela fronteira da aplicação e devem ser contados apenas uma vez,
considerando o processo elementar - “Relatório de Eventos- Não Videoconferência”. A
informação de paginação “Página 1” não conta como TD. As informações de data e hora
de emissão de relatório também não contam como TD. Este Relatório é uma Consulta
Externa porque consiste em uma recuperação de dados, sem derivação de dados, sem
mudança de comportamento do sistema, sem dados calculados, sem atualização de ALI.
A marcação das linhas com sombreado cinza não constitui uma derivação de dados e sim
um requisito não funcional de usabilidade.
CE: Relatório de Eventos - Videoconferência.
AR: 3 (Evento, Local, Usuário).
TD: 14 (Data Início, Data Fim, Ação, Mensagem, Data, Hora Inicial, Hora Final, Nome do
Evento, Local, Espaço, Reservado por, Responsável, Unidade, Situação).
Complexidade: Média
Tamanho: 4 PF.
62
3.8.3 Como Identificar Funções Transacionais nas Aplicações
Quando estamos contando as funções transacionais de um sistema, devemos iniciar

analisando os requisitos funcionais da aplicação, ou seja, as funcionalidades que a
aplicação vai entregar para os usuários (usuário final, outras aplicações, perfil gestor).
Identifique as funcionalidades que a aplicação entrega para todos os perfis de acesso.
Após identificar a funcionalidade, o primeiro passo é identificar se esta funcionalidade

é um Processo Elementar (PE), respondendo as seguintes questões:
 A funcionalidade identificada é a menor unidade de atividade significativa para o

usuário.
Sim
 A funcionalidade é auto-contida e deixa o processo de negócio do usuário

implementado via aplicação em um estado consistente?
Sim
Após identificar o Processo Elementar. O próximo passo é classificar como um tipo

de função da Análise de Pontos de Função: Entrada Externa (EE) ou Saída Externa (SE)
ou Consulta Externa (CE). Seguem as Dicas:
- Identifique o processo elementar baseando-se no entendimento dos requisitos do

usuário acordados com o desenvolvedor.
Em uma contagem de Pontos de Função, o analista de métricas deve buscar o

entendimento do requisito identificado na documentação do sistema. Nem sempre a
documentação do sistema possui uma clareza adequada. Assim, muitas vezes, o analista
de métricas, deve entrevistar os analistas de requisitos, analistas de negócios ou outro
profissional da equipe do projeto em questão para obter o entendimento correto do
requisito.
- Identifique o objetivo principal do processo elementar antes de classificá-lo como:

Entrada Externa, Consulta Externa ou Saída Externa.
Observe que as Entradas Externas podem apresentar dados para o usuário, por
exemplo, uma funcionalidade que tem como objetivo Incluir um usuário, gera um código
de acesso e apresenta para o usuário. A funcionalidade Incluir Usuário é uma EE porque
o objetivo principal é atualizar o ALI Usuário e não apresentar o Código de Acesso.
63
Observe que uma Consulta Externa pode ter entrada de dados, por exemplo, uma
funcionalidade que tem como objetivo apresentar uma lista de Alunos que tenha um filtro
de ano matricula. A funcionalidade Consulta – Lista Alunos é uma CE porque o objetivo
principal é apresentar dados de alunos por meio de recuperação no ALI Alunos e não a
entrada do ano de matrícula, utilizado como filtro para recuperação de dados.
Observe que uma Saída Externa pode atualizar Arquivo Lógico Interno, por exemplo,
uma funcionalidade que tem como objetivo gerar um Certificado de Conclusão de
Treinamento e adicionalmente atualize um ALI com indicador de Emissão de Certificado.
A funcionalidade Emitir Certificado é uma SE porque o objetivo principal é apresentar
dados do Certificado e não a atualização do ALI com dados de emissão do Certificado.
Uma vez que a função transacional foi identificada, então o próximo passo é definir
se ela conta Pontos de Função ou se ela já foi contada. Ou seja, devemos verificar a
unicidade da função identificada. A função deve ser única para ter contagem de PF.
Para a função ser contada devemos responder Sim a pelo menos uma das questões.
 O Processamento Lógico é diferente das outras formas de processamento

realizado em outras funções; ou
 O conjunto dos tipos de dados é diferente dos tipos de dados de outras funções;
ou
 Os ALI's ou AIE's referenciados são diferentes dos ALI's ou AIE's de outras

funções.
Exemplo 1: Foram identificadas duas funções “Consultar Alunos” e “Consultar

Detalhes Alunos”. Se as duas consultas tiverem a mesma lógica de processamento, os
mesmos Tipos de Dados e os mesmos Arquivos Referenciados. Então, deve-se contar
apenas uma vez, mesmo que estas sejam implementadas em telas diferentes por
implementadores distintos.
Exemplo 2: Foram identificadas duas funções “Lista de Alunos” e “Consultar Detalhes

Alunos”. As duas consultas possuem a mesma lógica de processamento e recuperam
dados do ALI Alunos. No entanto, a função “Consultar Detalhes Alunos” apresenta um
conjunto maior de Tipo de Dados que a função “Lista de Alunos”. Então, deve-se
contar duas funcionalidades, mesmo que sejam implementadas na mesma tela pelo
mesmo implementador.
64
3.9 CONTAGEM DE PONTOS DE FUNÇÃO DE UMA APLICAÇÃO
Esta seção apresenta um exemplo de contagem de pontos de função de um sistema de

Controle Acadêmico Simplificado.
As telas e o modelo de dados (arquivo "Exercício Controle Acadêmico - telas e

modelo.ppt") foram esboçados pelo analista de requisitos da sua equipe.
As regras de funcionamento das telas e dados são detalhadas a seguir:
1. O controle de acesso é feito com usuário e senha. A autenticação ocorre acessando a

entidade Controle Acesso mantida pelo Sistema Administrativo. Não existe controle de
perfil.
2. Ao entrar no sistema é apresentado um Menu. O menu é sempre o mesmo

independentemente do usuário que entrou na aplicação.
3. A entidade Sala é mantida por outra aplicação chamada Sistema Administrativo.
4. Toda tela de cadastro segue o mesmo conceito. O usuário preenche o filtro e clica no
botão Pesquisar. O sistema preenche o grid com o resultado. Caso não encontre registros
o sistema retorna a mensagem "Nenhum registro encontrado". Para detalhar, alterar um
registro ou excluir um ou mais registros, o usuário marca o checkbox da linha desejada
(ou os checkbox das linhas desejadas, no caso da exclusão) e clica no botão da função
desejada (Detalhar, Alterar ou Excluir). Na exclusão o sistema exibe a pergunta "Deseja
excluir o(s) registro(s) selecionado(s)?". Se o usuário responder que sim, o sistema exclui
os registros; se responder que não, o sistema cancela a exclusão.
5. Na tela de Matricular Aluno o usuário preenche o filtro e clica no botão Pesquisar. O

sistema preenche o grid com o resultado. Exibe o código da turma, nome do aluno, data
da matrícula e a descrição da disciplina. Caso não encontre registros o sistema retorna a
mensagem "Nenhum registro encontrado". Para excluir um ou mais registros o usuário
marca os checkbox das linhas desejadas e clica no botão Excluir. O sistema exibe a
pergunta "Deseja excluir o(s) registro(s) selecionado(s)?". Se o usuário responder que
sim, o sistema exclui os registros; se responder que não, o sistema cancela a exclusão.
Ao selecionar a opção Incluir o sistema exibe a tela de Matricular Aluno em Turma. O
65
usuário pode matricular quantos alunos quiser escolhendo o nome do aluno e o código da
turma. Ao clicar na opção Sair, o sistema retorna à tela de Matricular Aluno.
6. O campo Data da Matrícula é gerado internamente pelo sistema no Matricular Aluno e o

usuário não pode alterá-lo.
7. No protótipo, onde aparece Sala refere-se ao Número da Sala.
8. Os campos Código Turma, Matrícula e Código Disciplina são gerados automaticamente

pelo sistema (contador). O usuário não pode alterá-los nem na inclusão, nem na
alteração, porém pode visualizá-los nas respectivas telas de inclusão e alteração.
9. A entidade "Associação Turma" é mantida pela funcionalidade Matricular Aluno.
10. Só é permitido excluir Turma que não possui Aluno matriculado.
11. Só é permitido excluir Disciplina que não possui Turma cadastrada.
12. Ao excluir um aluno, todas as suas Matrículas em Turmas serão excluídas do sistema.
13. Nas telas de Emissão de Relatórios, na parte de cima temos o filtro e na parte de
baixo temos o formato e os dados que os relatórios devem possuir.
14. Toda funcionalidade possui uma ação e pelo menos uma mensagem.
O resultado esperado será a planilha abaixo exemplificada, contendo as funcionalidades

encontradas.
Memória
Complexidade
Nome da Funcionalidade Tipo de Função Tamanho
(B,M,A)
RL/AR TD
Acompanhe então a resolução deste exercício.
Resolução
1) O controle de acesso não possui perfil de acesso, logo temos uma função transacional
do tipo consulta externa. Para autenticação no sistema a transação acessa o arquivo de
Controle de Acesso que é mantido em outra fronteira chamada de Sistema Administrativo.
Esse arquivo é um arquivo de interface externa.
66
Nesta tela temos as seguintes funções:
 Controle Acesso - AIE - RL = 1 (Controle Acesso), TD = 2 (Usuário, Senha) - Baixa

= 5 PF
 Controlar Acesso - CE - AR = 1 (Controle de Acesso), TD = 4 (Usuário, Senha,

Comando e Mensagem) - Baixa = 3 PF
2) Para o cadastro de alunos temos a seguinte tela:
67
 Aluno - ALI - RL = 1 (Aluno), TD = 4 (Matrícula, Nome Aluno, Endereço, Identidade)

- Baixa = 7 PF
 Pesquisar Aluno - CE - AR = 1 (Aluno), TD = 5 (Matrícula, Nome Aluno, Identidade,

 Excluir Aluno - EE - AR = 2 (Aluno, Turma), TD = 3 (Matrícula, Comando e

Mensagem) - Baixa = 3 PF
Ao clicar no botão Detalhar temos a seguinte tela:
68
Nesta tela temos a seguinte função:
 Consulta Detalhada Aluno – CE – AR = 1 (Aluno), TD = 6 (Matrícula, Nome Aluno,

Identidade, Endereço, Comando e Mensagem) – Baixa = 3 PF
Ao clicar nos botões Incluir ou Alterar temos a seguinte tela:
 Incluir Aluno – EE – AR = 1 (Aluno), TD = 6 (Matrícula, Nome Aluno, Identidade,

Endereço, Comando e Mensagem) Baixa = 3 PF
 Alterar Aluno – EE – AR = 1 (Aluno), TD = 6 (Matrícula, Nome Aluno, Identidade,

Endereço, Comando e Mensagem) – Baixa = 3 PF
69
3) Para o cadastro de disciplinas temos a seguinte tela:
 Disciplina - ALI - RL = 1 (Disciplina), TD = 4 (Código Disciplina, Descrição, Ementa,

Crédito) - Baixa = 7 PF
 Pesquisar Disciplina - CE - AR = 1 (Disciplina), TD = 5 (Código Disciplina,

Descrição, Crédito, Comando e Mensagem) - Baixa = 3 PF
 Excluir Disciplina - EE - AR = 2 (Disciplina, Turma), TD = 3 (Código Disciplina,

70
 Consulta Detalhada Disciplina - CE - AR = 1 (Disciplina), TD = 6 (Código Disciplina,

Descrição, Crédito, Ementa, Comando e Mensagem) - Baixa = 3 PF
71
 Incluir Disciplina - EE - AR = 1 (Disciplina), TD = 6 (Código Disciplina, Descrição,

Crédito, Ementa, Comando e Mensagem) - Baixa = 3 PF
 Alterar Disciplina - EE - AR = 1 (Disciplina), TD = 6 (Código Disciplina, Descrição,

Crédito, Ementa, Comando e Mensagem) - Baixa = 3 PF
4) Para o cadastro de turmas temos a seguinte tela:
72
 Turma - ALI - RL = 2 (Turma e Associação Turma), TD = 7 (Código Turma, Horário

Início, Horário Fim, Dias da Semana, Número (Sala), Código Disciplina (FK), Data
Matrícula) - Baixa = 7 PF
 Sala - AIE - RL = 1 (Sala), TD = 2 (Número, Endereço) - Baixa = 5 PF
 Combo Sala - CE - AR = 1 (Sala), TD = 4 (Número, Endereço, Comando e

 Combo Código Disciplina - CE - AR = 1 (Disciplina), TD = 4 (Código Disciplina,

Descrição, Comando e Mensagem) - Baixa = 3 PF
73
 Pesquisar Turma - CE - AR = 2 (Turma, Disciplina), TD = 6 (Código Turma,
Número da Sala, Código Disciplina, Descrição, Comando e Mensagem) - Média = 4
PF
 Excluir Turma - EE - AR = 2 (Turma, Aluno), TD = 3 (Código Turma, Comando e

 Consulta Detalhada Turma - CE - AR = 2 (Turma, Disciplina), TD = 8 (Código

Turma, Número da Sala, Descrição Disciplina, Dias da Semana, Horário Início,
Horário Fim, Comando e Mensagem) - Média = 4 PF
74
 Incluir Turma - EE - AR = 1 (Turma), TD = 9 (Código Turma, Número da Sala,

Código Disciplina, Descrição Disciplina, Dias da Semana, Horário Início, Horário
Fim, Comando e Mensagem) - Baixa = 3 PF
 Alterar Turma - EE - AR = 1 (Turma), TD = 9 (Código Turma, Número da Sala,

Código Disciplina, Descrição Disciplina, Dias da Semana, Horário Início, Horário
Fim, Comando e Mensagem) - Baixa = 3 PF
5) Para matricular um aluno em turma temos a seguinte tela:
75
 Combo Nome Aluno - CE - AR = 1 (Aluno), TD = 3 (Nome Aluno, Comando e

 Combo Código Turma - CE - AR = 1 (Turma), TD = 3 (Código Turma, Comando e

 Pesquisar Matrícula de Aluno - CE - AR = 3 (Turma, Disciplina, Aluno), TD = 6

(Código Turma, Nome Aluno, Data Matrícula, Descrição Disciplina, Comando e
Mensagem) - Média = 4 PF
 Excluir Matrícula de Aluno - EE - AR = 2 (Turma, Aluno), TD = 4 (Código Turma,

Nome do Aluno, Comando e Mensagem) - Baixa = 3 PF
Ao clicar no botão Incluir temos a seguinte tela:
76
- Matricular Aluno - EE - AR = 2 (Turma, Aluno), TD = 4 (Nome Aluno, Código Turma,

6) Para emitir relação de alunos em uma turma temos a seguinte tela:
 Emitir Relação de Alunos em Turma - SE - AR = 3 (Turma, Aluno, Disciplina), TD =

9 (Código Turma, Dias da Semana, Horário Início, Horário Fim, Descrição da
Disciplina, Nome Aluno, Total de Alunos, Comando e Mensagem) - Média = 5 PF
7) Para emitir grade de horário temos a seguinte tela:
77
 Emitir Grade de Horário - CE - AR = 2 (Turma, Disciplina), TD = 7 (Código Turma,

Dias da Semana, Horário Início, Horário Fim, Descrição da Disciplina, Comando e
Mensagem) - Média = 4 PF
A seguir temos a planilha com a contagem.
Nome da Tipo de Memória Compl.

Tamanho
Funcionalidade Função RL/AL TD (B,M,A)
Matrícula, Nome, Aluno, Endereço,

Aluno ALI Aluno B 7
Identidade
Turma e Código Turma, Horário Início, Horário
Turma ALI Associação Fim, Dias da Semana, Número (Sala), B 7
Turma Código Disciplina (FK), Data Matrícula
Código Disciplina, Descrição, Ementa,
Disciplina ALI Disciplina B 7
Crédito
Sala AIE Sala Número, Endereço B 5
Controle Acesso AIE Controle Usuário, Senha B 5
78
Acesso
Controle Usuário, Senha, Comando,
Controlar Acesso CE B 3
Acesso Mansagem
Matrícula, Nome Aluno, Identidade,
Pesquisar Aluno CE Aluno B 3
Comando e Mensagem
Incluir Aluno EE Aluno B 3
Endereço, Comando e Mensagem
Alterar Aluno EE Aluno B 3
Endereço, Comando e Mensagem
Excluir Aluno EE Aluno, Turma Matrícula, Comando e Mensagem B 3
Consulta Detalhada Matrícula, Nome Aluno, Identidade,
CE Aluno B 3
Aluno Endereço, Comando e Mensagem
Código Disciplina, Descrição, Crédito,
Pesquisar Disciplina CE Disciplina B 3
Comando e Mensagem
Incluir Disciplina EE Disciplina B 3
Ementa, Comando e Mensagem
Alterar Disciplina EE Disciplina B 3
Ementa, Comando e Mensagem
Disciplina, Código Disciplina, Comando e
Excluir Disciplina EE B 3
Turma Mensagem
Consulta Detalhada Código Disciplina, Descrição, Crédito,
CE Disciplina B 3
Disciplina Ementa, Comando e Mensagem
Número, Endereço, Comando e
Combo Sala CE Sala B 3
Mensagem
Combo Código Código Disciplina, Descrição,
CE Disciplina B 3
Disciplina Comando e Mensagem
Código Turma, Número da Sala,
Pesquisar Turma Turma,
CE Código Disciplina, Descrição, M 4
(turma e disciplina) Disciplina
Comando e Mensagem
Código Disciplina, Descrição
Incluir Turma EE Turma Disciplina, Dias da Semana, Horário B 3
Início, Horário Fim, Comando e
Mensagem
Código Disciplina, Descrição
Alterar Turma EE Turma Disciplina, Dias da Semana, Horário B 3
Início, Horário Fim, Comando e
Mensagem
Código Turma, Comando e
Excluir Turma EE Turma, Aluno B 3
Mensagem
Consulta Detalhada
Turma, Descrição Disciplina, Dias da
Turma (turma e CE M 4
Disciplina Semana, Horário Início, Horário Fim,
disciplina)
Comando e Mensagem
Combo Nome Aluno CE Aluno Nome Aluno, Comando e Mensagem B 3
79
Código Turma, Comando e
Combo Código Turma CE Turma B 3
Mensagem
Turma, Código Turma, Nome Aluno, Data
Pesquisar Matrícula
CE Disciplina, Matrícula, Descrição Disciplina, M 4
de Aluno
Aluno Comando e Mensagem
Nome Aluno, Código Turma,
Matricular Aluno EE Turma, Aluno B 3
Comando e Mensagem
Excluir Matrícula de Código Turma, Nome do Aluno,
EE Turma, Aluno B 3
Aluno Comando e Mensagem
Código Turma, Dias da Semana,
Emitir Relação de Turma, Aluno, Horário Início, Horário Fim, Descrição
SE M 5
Alunos em Turma Disciplina da Disciplina, Nome Aluno, Total de
Alunos, Comando e Mensagem
Código Turma, Dias da Semana,
Emitir Grade de Turma
CE Horário Início, Horário Fim, Descrição M 4
Horário Disciplina
da Disciplina, Comando e Mensagem
Total de pontos de função é de 112 PF
3.10. CÁLCULO DE PONTOS DE FUNÇÃO
O cálculo de Pontos de Função deve ser realizado de acordo com o tipo de

contagem. Conforme mencionado, o manual de práticas de contagem considera três tipos
de contagem - Projeto de Desenvolvimento, Projeto de Melhoria e Aplicação. Existem
duas fórmulas de cálculo associadas à aplicação: aplicação após um projeto de
desenvolvimento e aplicação após um projeto de melhoria. Seguem as fórmulas de
cálculo.
 Projeto de Desenvolvimento
Projeto para desenvolver e entregar a primeira versão de uma aplicação de

software. Seu tamanho funcional é a medida das funcionalidades entregues aos usuários
pela aplicação. Considera funções de conversão de dados (migração). Segue a fórmula:
PF_DESENVOLVIMENTO = PF_INCLUÍDO + PF_CONVERSÃO
PF_INCLUÍDO: Pontos de Função associados às funcionalidades incluídas na aplicação

por meio do projeto de desenvolvimento.
PF_CONVERSÃO: Pontos de Função associados às funcionalidades de conversão de

dados dos projetos. Exemplos de funções de conversão incluem: migração ou carga
inicial de dados para inserção nas novas tabelas criadas no sistema e relatórios
80
associados à migração de dados. Essas funcionalidades são executadas apenas uma
vez, no momento de implantação do projeto. Por isso, elas são contempladas na
contagem de Pontos de Função de Projetos de Desenvolvimento e em Projetos de
Melhoria, mas não são contempladas na Contagem de Pontos de Função da Aplicação.
 Projeto de Melhoria
O Projeto de Melhoria (enhancement), também denominado, na literatura de

Engenharia de Software, de Projeto de Melhoria Funcional, ou Manutenção Evolutiva,
está associado às mudanças em requisitos funcionais da aplicação, ou seja, a inclusão de
novas funcionalidades, alteração ou exclusão de funcionalidades em aplicações
implantadas. Sua fórmula de cálculo é:
PF_MELHORIA = (PF_INCLUÍDO + PF ALTERADO + PF_EXCLUÍDO+ PF_CONVERSÃO)

por meio do projeto de melhoria.
PF_ALTERADO = Pontos de Função associados às funcionalidades alteradas no projeto

de melhoria.
PF_EXCLUÍDO = Pontos de Função associados às funcionalidades existentes na

aplicação que serão excluídas no projeto de melhoria.
PF_CONVERSÃO: Contagem de Pontos de Função associada às funcionalidades de

conversão de dados dos projetos. Exemplos de funções de conversão incluem: migração
ou carga inicial de dados para popular as novas tabelas criadas no sistema e relatórios
associados à migração de dados. Essas funcionalidades são executadas apenas uma
vez, no momento de implantação do projeto. Por isso, elas são contempladas na
contagem de Pontos de Função de Projetos de Desenvolvimento e em Projetos de
Melhoria, mas não são contempladas na Contagem de Pontos de Função de Aplicações.
 Aplicação após Projeto de Desenvolvimento
Seu tamanho funcional é uma medida das funcionalidades que a aplicação atual fornece
ao usuário. Também é chamada de contagem de aplicação instalada ou de Baseline. Não
considera funções de conversão de dados (migração de dados).
PF_APLICAÇÃO = PF_INCLUÍDO
81
por meio do projeto de desenvolvimento.
 Aplicação após Projeto de Melhoria
Seu tamanho funcional é uma medida das funcionalidades que a aplicação atual
fornece ao usuário. Também é chamada de contagem de aplicação instalada ou de
Baseline. Não considera funções de conversão de dados (migração de dados). A
contagem de Baseline deve ser atualizada após um projeto de melhoria, de acordo com a
fórmula abaixo:
PF_APLICAÇÃO_PÓS-MELHORIA = (PF_APLICAÇÃO + PF_INCLUÍDO +

PF_ALTERADO_ATUAL - PF_ALTERADO_ANTERIOR - PF_EXCLUÍDO)
PF_APLICAÇÃO: Pontos de Função associados às funcionalidades da aplicação

instalada.

PF_ALTERADO_ATUAL: Pontos de Função associados às funcionalidades alteradas no

projeto de melhoria. É o PF_ALTERADO do Projeto de Melhoria.
PF_ALTERADO_ANTERIOR: Pontos de Função associados às funcionalidades

existentes na aplicação alteradas pelo projeto de melhoria. Deve-se considerar os Pontos
de Função dessas funcionalidades antes da alteração.
PF_EXCLUÍDO = Pontos de Função associados às funcionalidades existentes na

aplicação que foram excluídas pelo projeto de melhoria.
Algumas observações importantes:
 Para efeito de faturamento de contratos e de estimativas, as contagens realizadas

são as de projetos: Projeto de Desenvolvimento ou Projeto de Melhoria.
 Os Roteiros de Métricas dos Órgãos podem contemplar outros tipos de contagem

para tratar projetos de manutenção não considerados no manual.
 Os Roteiros de Métricas dos Órgãos podem considerar a fórmula de Projeto de

Melhoria com redutores para a contagem de PF de funcionalidades alteradas
82
(PF_Alterado) e funcionalidades excluídas (PF_Excluído). Essa prática tem sido
comum visando aderência às recomendações do Tribunal de Contas da União
(TCU). Esses assuntos serão discutidos no Módulo 4, no item "Roteiros de
Métricas".
3.11. DOCUMENTAÇÃO DA CONTAGEM DE PONTOS DE FUNÇÃO
Neste ponto, a contagem de Pontos de Função foi realizada. Agora, precisamos

compartilhar os resultados da contagem com os interessados.
Considerando o cenário do Governo Brasileiro de utilização da métrica Pontos de

Função como base para o estabelecimento de contratos de software, a documentação da
contagem de Pontos de Função deve ser clara o suficiente para que um revisor ou auditor
possa compreender a contagem apresentada e chegar aos mesmos resultados. A
contagem de pontos de função deve ser rastreável para os requisitos funcionais
analisados. Seguem algumas diretrizes para apoiar a documentação da contagem de
Pontos de Função:
 a data da contagem, a versão da contagem, o responsável pela contagem;
 o resultado da contagem;
 documentar o propósito e o escopo da contagem;
 documentar o tipo de contagem de acordo com o Roteiro de métricas do Órgão que

deve fazer parte do Contrato e Edital;
 a fase do processo de desenvolvimento em que foi realizada a contagem. Por

exemplo, contagem estimativa, realizada na fase de negócios; contagem de
referência, realizada no final da fase de requisitos; contagem final, realizada após a
implantação da aplicação.
 documentar as premissas consideradas na contagem de acordo com o Roteiro de

métricas do Órgão que deve fazer parte do Contrato e Edital. Por exemplo,
decisões sobre contagem de múltiplas mídias;
 definir a fronteira da aplicação. Para projetos de manutenção é importante

documentar as fronteiras no Roteiro de métricas do Órgão que deve fazer parte do
Contrato e Edital;
83
 os documentos utilizados como base para a realização da contagem de Pontos de
Função;
 uma lista de todas as funções de dados e de transação, incluindo o respectivo tipo

e complexidade, bem como o número de pontos de função atribuído a cada uma.
Em caso de uma contagem detalhada documentar para cada função de dados o
número de Registros Lógicos e Tipos de Dados e para cada função transacional o
número de Arquivos Referenciados e Tipos de Dados. Recomenda-se identificar
quais são os Arquivos Referenciados e Registros Lógicos. Em alguns casos,
documentar também quais são os Tipos de Dados;
 em projetos de manutenção definir se a funcionalidade foi adicionada, alterada ou

excluída da aplicação existente, ou ainda se é uma função de conversão de dados;
 rastrear cada função de dados e função transacional documentada para o

documento utilizado como base para a contagem de Pontos de Função. Por
exemplo: Caso de Uso 1: Gráfico de Cursos Ministrados por período - SE - AR: 1
(Curso); TD: 6 (data início, data fim, nome do curso, quantidade de turmas, ação,
mensagem) - Baixa - 4 PF.
A clareza na nomenclatura dos tipos funcionais é fundamental. Por exemplo,

suponha a seguinte funcionalidade Curso - CE - AR:1 TD:2 - Baixa - 3 PF. Um revisor
pode pensar que o ALI curso está sendo contado duas vezes como ALI e como CE. Mas
a intenção do responsável pela contagem foi de contar a List Box de Cursos. De fato, a
list box de cursos que recupera todos os cursos cadastrados no ALI cursos e apresenta
para o usuário deve ser contada. List box Curso - CE - AR:1 (Curso) TD:2 (nome do
curso, ação drop down) - Baixa - 3 PF.
Uma Contagem de Pontos de Função documentada com clareza facilitará a

rastreabilidade, usabilidade e manutenibilidade.
Referência:
IFPUG. "Practical Guide for Documenting the Function Point Count", Version 1, May 2010
84
MÓDULO 4. CONTAGEM DE PONTOS DE FUNÇÃO DE PROJETOS DE MELHORIA
Este módulo tem como objetivo descrever o método de contagem de Pontos de

Função de projetos de manutenção evolutiva. Estes projetos são denominados Projetos
de Melhoria pelo Manual de Práticas de Contagem (CPM). Cabe ressaltar que os demais
tipos de projetos de manutenção com alteração de requisitos não funcionais não são
contados seguindo as diretrizes do CPM. Os Roteiros de Métricas apresentam métricas
complementares para o dimensionamento dos projetos de manutenção em requisitos não
funcionais.
4.1. DEFINIÇÃO DE PROJETOS DE MELHORIA
O Projeto de Melhoria, também denominado na literatura de Engenharia de

Software como projeto de melhoria funcional, ou manutenção evolutiva, está associado às
mudanças em requisitos funcionais da aplicação, ou seja, a inclusão de novas
funcionalidades, alteração ou exclusão de funcionalidades em aplicações implantadas.
Um projeto de melhoria consiste em demandas de criação de novas

funcionalidades (grupos de dados ou processos elementares), demandas de exclusão de
funcionalidades (grupos de dados ou processos elementares) e demandas de alteração
de funcionalidades (grupos de dados ou processos elementares) em aplicações
implantadas em produção.
4.2. COMO CONTAR FUNÇÕES DE DADOS EM PROJETOS DE MELHORIA
Contamos funções de dados (Arquivo Lógico Interno ou Arquivo de Interface

Externa) incluídas em um projeto de melhoria quando for identificado um novo grupo de
dados mantido pela aplicação (ALI incluído) ou quando for identificado um novo grupo de
dados lido pela aplicação (AIE incluído).
Uma função de dados (Arquivo Lógico Interno ou Arquivo de Interface Externa) é

considerada alterada, quando a alteração contemplar mudanças de tipos de dados,
85
inclusão ou exclusão de tipos de dados em uma função de dados existente. Ou mudança
de tamanho (número de posições) ou tipo de campo (por exemplo: mudança de numérico
ou alfanumérico), sendo que esta ocorre por mudança de regra de negócio do usuário e
não por motivos técnicos.
Observação Importante:
Quando uma função de dados é alterada, a contagem de Pontos de Função da

função alterada deve observar a função que a aplicação entrega para o usuário após a
alteração.
Por exemplo, suponha um Sistema de RH com um ALI de Empregados com 2 RLs

e 60 TDs. Este ALI possui complexidade Alta e conta 15 PFs. O projeto de melhoria
consiste na inclusão do TD – e-mail pessoal no ALI.
A Contagem do PF_Alterado será a função de dados entregue para o usuário com

o Projeto de Melhoria, a saber:
ALI: Empregados – RL: 2 – TD: 61 – Alta – 15 PF
PF_Alterado: 15 PF
Uma função de dados (Arquivo Lógico Interno ou Arquivo de Interface Externa) é

considerada excluída quando uma aplicação deixar de ler um grupo de dados de outra
aplicação (AIE excluído) ou quando a aplicação deixar de manter um grupo de dados da
aplicação (ALI excluído).
4.3. COMO CONTAR FUNÇÕES TRANSACIONAIS EM PROJETOS DE MELHORIA

Contamos funções transacionais (Entrada Externa, Consulta Externa e Saída
Externa) incluídas em um projeto de melhoria quando for identificada a necessidade de
construção de novas funcionalidades na aplicação existente. Por exemplo, necessidade
de construção de: um Relatório com dados calculados (SE Incluída); uma Combobox com
nome dos Líderes de Projetos (CE Incluída); uma tela de atualização de taxa de câmbio
(EE Incluída).
Uma função transacional (Entrada Externa, Consulta Externa e Saída Externa) é

considerada alterada, quando a alteração contemplar:
 Mudança de tipos de dados em uma função existente; ou

 Mudança de arquivos referenciados; ou
86
 Mudança de lógica de processamento, segundo as ações das lógicas de
processamento descritas a seguir.
A Lógica de Processamento é definida como requisitos especificamente
solicitados pelo usuário para completar um processo elementar. Esses requisitos devem
incluir as seguintes ações:
 Validações são executadas;

 Fórmulas matemáticas e cálculos são executados;
 Valores equivalentes são convertidos;
 Dados são filtrados e selecionados através da utilização d critérios;
 Condições são analisadas para verificar quais são aplicáveis;
 Um ou mais ALIs são atualizados;
 Um ou mais ALIs e AIEs são referenciados;
 Dados ou informações de controle são recuperados;
 Dados derivados são criados através da transformação de dados existentes, para
criar dados adicionais;
 O comportamento do sistema é alterado;
 Preparar e apresentar informações para fora da fronteira;
 Receber dados ou informações de controle que entram pela fronteira da aplicação;
 Dados são reordenados;
Observação Importante:
Quando uma função transacional é alterada, a contagem de Pontos de Função da

função alterada deve observar a função que a aplicação entrega para o usuário após a
alteração.
Por exemplo, suponha um Sistema de RH com uma SE: Relatório de Empregados

com Total Geral com 2 ARs e 30 TDs. Esta SE possui complexidade Alta e conta 7 PFs.
O projeto de melhoria consiste na inclusão de um novo campo calculado – Total de
Empregados por Setor.
A Contagem do PF_Alterado será a função de transacional entregue para o usuário

com o Projeto de Melhoria, a saber:
SE: Relatório de Empregados com Total Geral – AR: 2 – TD: 31 – Alta – 7 PF
PF_Alterado: 7 PF
87
Uma função transacional (Entrada Externa, Consulta Externa e Saída Externa) é
considerada excluída quando o usuário solicitar a exclusão de uma funcionalidade
existente na aplicação em questão.
4.4. FÓRMULAS DE CÁLCULO
Segue a Fórmula de Cálculo de Pontos de Função de um Projeto de Melhoria em

aderência ao CPM 4.3.1.
PF_MELHORIA = PF_INCLUIDO + PF_ALTERADO + PF_EXCLUIDO +

PF_CONVERSÃO
Onde:
PF_INCLUÍDO: Pontos de Função associados às novas funcionalidades que farão parte

da aplicação.
PF_ALTERADO: Pontos de Função associados às funcionalidades existentes na
aplicação que serão alteradas no Projeto de Melhoria.
PF_EXCLUÍDO: Pontos de Função associados às funcionalidades existentes na
aplicação que serão excluídas no Projeto de Melhoria.
PF_CONVERSÃO: Pontos de Função associados às funcionalidades de conversão de
dados dos projetos de melhoria. As funções de migração e conversão de dados são
processos elementares contidos em um Projeto de Melhoria necessários para a sua
implantação, que têm por objetivo: migração de dados oriundos de outros sistemas ou
tabelas, com ou sem transformação; carga inicial de dados para popular as novas tabelas
ou novos campos em tabelas já existentes; atualização de dados legados para manter
consistência com o projeto de melhoria; relatórios de exceção, erros, conversão ou de
controle necessários para garantir a integridade dos dados que estão sendo convertidos.
Exemplos de funções de conversão incluem: carga inicial de dados para popular as novas
tabelas criadas e relatórios associados à migração de dados.
A contagem da aplicação, ou contagem de Baseline deve ser atualizada após um projeto

de melhoria, de acordo com a fórmula abaixo:

Onde:
PF_APLICAÇÃO: Pontos de Função associados às funcionalidades da aplicação

instalada.
88
PF_ALTERADO_ATUAL: Pontos de Função associados às funcionalidades alteradas no
projeto de melhoria. É o PF_ALTERADO do Projeto de Melhoria.
PF_ALTERADO_ANTERIOR: Pontos de Função associados às funcionalidades
existentes na aplicação alteradas pelo projeto de melhoria. Deve-se considerar os Pontos
de Função dessas funcionalidades antes da alteração.
PF_EXCLUÍDO: Pontos de Função associados às funcionalidades existentes na
aplicação que foram excluídas pelo projeto de melhoria.
4.5. ESTUDO DE CASOS
Vamos praticar a aplicação das fórmulas de cálculo dos projetos de melhoria.

Suponha uma Aplicação Implantada – o Sistema de Gerenciamento de Projetos (SGP)
com uma contagem de Baseline 200 PFs.
O Cliente solicitou um Projeto de Melhoria com as seguintes necessidades:
1) Retirar da Aplicação o Gráfico de Acompanhamento de Projetos
2)Incluir o Filtro Gestor na Consulta de Projetos (Lista).
89
Observação: A Consulta de Projetos (Lista) já existe na aplicação sem o filtro Gestor. A
Combo Gestor já existe na aplicação em outras telas. O usuário pode ordenar a consulta
clicando na coluna “Nome do Projeto”; “Gestor” ou “Status”. O usuário terá a opção de
marcar “Todos” na combo Gestor.
3) Implementar o Envio mensagem para o Gestor
Na tela de consulta de detalhes do projeto, a aplicação deverá disponibilizar um link

“Enviar Mensagem para o Gestor”. Ao clicar nesse botão será exibida uma tela para o
usuário inserir as seguintes informações: assunto, mensagem e um botão “enviar”. A
aplicação deve recuperar o e-mail do gestor, nome e e-mail do usuário e enviar a
mensagem para o e-mail do gestor com o assunto, mensagem, nome e e-mail do usuário.
As mensagens serão armazenadas pela aplicação na Tabela de Caixa de Mensagens.
Em versões futuras serão implementadas funcionalidades de consulta e exclusão de
mensagens da Caixa de Mensagens do Gestor.
Acompanhe a solução do Estudo de Casos.
Quando estamos realizando uma contagem de PF de um projeto de melhoria devemos

contar: funcionalidades incluídas, funcionalidades alteradas, funcionalidades excluídas e
funcionalidades de conversão de dados, caso aplicável. Neste estudo de casos não há
funções de conversão de dados para serem contadas.
1) Retirar da Aplicação o Gráfico de Acompanhamento de Projetos
90
Trata-se de uma funcionalidade excluída da aplicação existente.
SE: Gráfico de Acompanhamento de Projetos
AR 1 – Projetos
TD: 2 – Status do Projeto e Quantitativo
Complexidade: Baixa - 4 PF
PF_Excluído: 4 PF
2) Incluir o Filtro Gestor na Consulta de Projetos (Lista).
Observação: A Consulta de Projetos (Lista) já existe na aplicação sem o filtro

Gestor. A Combo Gestor já existe na aplicação em outras telas. O usuário pode
ordenar a consulta clicando na coluna “Nome do Projeto”; “Gestor” ou “Status”. O
usuário terá a opção de marcar “Todos” na combo Gestor.
Trata-se de uma funcionalidade alterada da aplicação existente.
91
CE: Consulta de Projetos (Lista)
AR: 2 – Projetos, Gestores
TD: 6 – Gestor, Nome do Projeto, Status, Opção de como Ordenar, ação,

mensagem
Complexidade: Média - 4 PF
PF_Alterado: 4 PF
Observações:
 Como a Combobox de Gestor, que consiste em uma CE, existente na aplicação,

então esta não deve ser contada no projeto de Melhoria. Esta não foi incluída e
nem alterada, considerando-se a aplicação em questão.
 O PF_Alterado é a funcionalidade entregue para o usuário com o projeto de

melhoria. Portanto, contamos toda a funcionalidade alterada e não apenas a
alteração na funcionalidade.
 O PF_Alterado_Atual da fórmula de contagem de Aplicação após o projeto de

Melhoria é o PF_Alterado.
PF_Alterado_Atual: 4 PF
 O PF_Alterado Anterior é a contagem de PF da funcionalidade alterada na

aplicação implantada, antes da realização do projeto de melhoria.
CE: Consulta de Projetos (Lista)
AR: 2 – Projetos, Gestores
TD: 6 – Gestor, Nome do Projeto, Status, Opção de como Ordenar, ação,

mensagem
PF_Alterado_Anterior: 4 PF
Neste caso, a alteração da funcionalidade foi em lógica de processamento, inclusão de

filtro. Assim, a função não mudou a complexidade.
3) Implementar o Envio mensagem para o Gestor
Na tela de consulta de detalhes do projeto, a aplicação deverá disponibilizar um link

“Enviar Mensagem para o Gestor”. Ao clicar nesse botão será exibida uma tela para o
92
usuário inserir as seguintes informações: assunto, mensagem e um botão “enviar”. A
aplicação deve recuperar o e-mail do gestor, nome e e-mail do usuário e enviar a
mensagem para o e-mail do gestor com o assunto, mensagem, nome e e-mail do usuário.
As mensagens serão armazenadas pela aplicação na Tabela de Caixa de Mensagens.
Em versões futuras serão implementadas funcionalidades de consulta e exclusão de
mensagens da Caixa de Mensagens do Gestor.
Trata-se de funções incluídas
SE: Enviar Mensagem para o Gestor
AR: 2 – Usuário, Caixa de Mensagem
TD: 7 - e-mail do gestor, nome, e-mail do usuário, assunto, mensagem, ação,

mensagem
ALI: Caixa de Mensagens
RL: 1 - Caixa de Mensagens
TD: 4 - id gestor, id usuário, assunto, mensagem
Complexidade: Baixa - 7 PF
PF_Incluído: 12 PF
Observações:
 A função foi contada como SE porque além de apresentar informações para o

usuário, é atualizado um ALI de Caixa de Mensagens.
 A consulta detalhes de projeto não foi contada porque não foi alterada. Mesmo que
na implementação exista um esforço para a inclusão do link para a nova
funcionalidade de envio de mensagem, na visão do usuário o link para chamada de
Enviar Mensagem para o Gestor faz parte da funcionalidade em questão.
Agora, vamos aplicar as fórmulas e concluir a contagem de PF do projeto de Melhoria.
PF_MELHORIA = PF_INCLUIDO + PF_ALTERADO + PF_EXCLUIDO +

PF_CONVERSÃO
PF_Melhoria = 12 PF + 4 PF + 4 PF + 0 PF= 24 PF
93
A Contagem de PF da aplicação implantada antes do projeto de melhoria era de 200PF.
Para realizarmos a contagem de Baseline após a implantação do projeto de melhoria,
vamos seguir a fórmula abaixo:

PF_Aplicação = 200 PF + 12 PF + 4 PF – 4 PF – 4PF = 208 PF
Após o projeto de melhoria a aplicação que tinha o tamanho funcional de 200 PF passou
a ter o tamanho funcional de 208 PF.
Observe que as funções incluídas aumentam o escopo da aplicação, as funções

excluídas reduzem o escopo da aplicação. As funções alteradas podem aumentar, reduzir
ou manter o escopo da aplicação.
94
MÓDULO 5. ESTIMATIVA DE PROJETOS DE SOFTWARE
Este módulo tem como propósito descrever um Processo de Estimativas de Projetos

de Software baseado na métrica Pontos de Função. Desta forma, são apresentados
métodos para estimativa de: Tamanho, Prazo, Esforço, Custo e Recursos Computacionais
Críticos. Ao final do módulo é apresentado um Estudo de Casos demonstrando a
aplicação dos conceitos apresentados na estimativa de um sistema.
5.1. INTRODUÇÃO E MOTIVAÇÃO
Quando pensamos em projetos de software desenvolvidos internamente ou

contratados sempre surgem as questões: Quando vai ficar pronto? Quanto vai custar?
O método de Estimativas de Opinião de Especialistas, no qual um especialista no

projeto ou domínio do projeto em questão estima o prazo, esforço e custo com base em
sua experiência, é bastante utilizado na indústria de software. No entanto, este método
apresenta algumas limitações: a empresa precisa de um ou mais especialistas no projeto
em questão; projetos grandes e complexos são difíceis de estimar sem a utilização de
métodos; a estimativa precisa ser justificada para as partes interessadas no projeto.
Analisando-se as estatísticas da indústria de software, podemos constatar que o

cenário se apresenta em estado caótico. Segundo os dados do Gartner Group, apenas
32% dos projetos de software são bem-sucedidos, ou seja, terminam dentro do custo e do
prazo previsto.
Os principais problemas identificados nos projetos de software estão associados à

especificação de requisitos inadequada, problemas na gestão das mudanças de requisitos
e ausência de métodos para estimativas dos projetos. O uso da métrica Pontos de
Função promove uma melhoria na documentação de requisitos, porque a especificação
de requisitos constitui a base para a contagem de Pontos de Função e estes devem estar
documentados com clareza e com detalhamento adequado.
A gestão das mudanças de requisitos também é suportada pelo uso de métricas. Em

contratos ou gestão de projetos internos com base em métricas, as mudanças de
requisitos precisam ser registradas e dimensionadas.
95
O uso de métodos de estimativas com base em métricas também é fundamental
para a gestão de contratos de fábrica de software e de projetos internos, especialmente
para se determinar o prazo de entrega do sistema para os usuários e para se avaliar se
há orçamento disponível para o desenvolvimento ou manutenção do sistema.
5.2. ESTIMATIVAS - CONCEITOS BÁSICOS
A estimativa deve ser realizada no início do projeto durante a etapa de

planejamento. As estimativas e as premissas utilizadas devem ser documentadas e
analisadas no acompanhamento do projeto. Exemplos de premissas utilizadas incluem o
seguinte: Projeto desenvolvido em JAVA, o módulo de relatórios encontra-se em
definição, a equipe de desenvolvimento é experiente na plataforma de desenvolvimento,
etc.
 Estimativa X Meta X Compromisso
Estimativa: Obtida por meio de uma atividade técnica. Não deve sofrer
interferências. Por exemplo, de acordo com a fórmula de Capers Jones o prazo estimado
para o sistema é de 7 meses.
Meta: Objetivo a ser atingido, sendo definida em função de necessidades de

negócio. Por exemplo, o sistema precisa ser implantado em 4 meses.
Compromisso: É um acordo da gerência com as equipes técnicas para alcançar

uma meta. Por exemplo, de acordo com a análise das estimativas é possível priorizar o
módulo 1 para que este seja entregue em 4 meses. O módulo 2 será entregue em 7
meses.
5.3. PROCESSO DE ESTIMATIVAS
Como definir quando o projeto vai ficar pronto? Por onde começar?
Para melhorar a acurácia das estimativas dos projetos devemos implantar um

processo de Estimativas com base em métricas de software. A Figura abaixo ilustra um
processo de estimativas. As atividades são descritas a seguir.
96
Figura: Processo de Estimativas de Projetos de Software
Fonte: HAZAN, Claudia. Análise de Pontos de Função: uma aplicação nas estimativas de tamanho
de projetos de software. Engenharia de Software Magazine, Edição 2, Devmedia, pp.25-31.
 Coletar e Analisar Requisitos Iniciais
As melhores práticas da Qualidade de Software preconizam que as estimativas

devem ser geradas no início do projeto para apoiar na elaboração do Plano do Projeto.
Nas fases iniciais do projeto de software, só temos disponíveis os requisitos de negócio,
que podem ser documentados em um Documento de Visão do Projeto ou outro tipo de
documento inicial de requisitos, que identifique as funcionalidades do sistema a ser
desenvolvido ou mantido.
Este primeiro passo consiste na obtenção e análise de toda documentação de

requisitos disponível do projeto. Quanto mais informações do projeto forem obtidas melhor
a acurácia das estimativas.
97
 Estimar Tamanho
A métrica Pontos de Função pode ser usada como unidade de medida para as
estimativas de tamanho funcional de projetos de desenvolvimento e de melhoria de
sistemas. O manual de Práticas de Contagem (CPM) ressalta que a contagem de Pontos
de Função é baseada no Projeto Lógico (logical design) do sistema. No início o que temos
disponível é um documento inicial de requisitos, assim deve utilizado um método de
estimativa de Pontos de Função para identificar o tamanho funcional do projeto em
questão por meio da análise da documentação disponível. A seguir são apresentados os
métodos: Contagem Indicativa (NESMA), Contagem Indicativa Inteligente, Contagem
Estimada de Pontos de Função (NESMA), Contagem Detalhada de Pontos de Função
(NESMA) e Contagem Estimativa de Pontos de Função. A Contagem Detalhada (NESMA)
segue o padrão IFPUG, sendo utilizada para estimar projetos com requisitos mais
detalhados.
Boa Prática: Considerar a evolução de requisitos (Scope Creep) como premissa nas
estimativas de tamanho.
Em uma estimativa, o Sistema encontra-se em fase inicial de requisitos, sendo

recomendado considerar um percentual para evolução de requisitos de 30% a 50%
[Roeczheim, 2005]. De fato, a evolução ou mudança de requisitos é um fenômeno
bastante comum nos projetos de desenvolvimento de software [Sommerville, 2007]. Em
geral, sistemas estimados com um documento inicial de requisitos, por exemplo,
Documento de Visão, considera-se um Scope Creep de 30% a 40%. Em sistemas em
fase final de requisitos, por exemplo, com especificação de casos de uso, considera-se
um Scope Creep de 20% a 30%.
Se a Contagem Estimativa de PF de um Sistema realizada com Base no Documento

de Visão for 100 PF, então o sistema pode ser estimado com 135 PF, com base na
premissa de uma evolução de requisitos de 35%.
Estimativas e Contagens de Pontos de Função
As contagens de Pontos de Função devem ser realizadas minimamente em três

marcos do processo de desenvolvimento de software, a saber:
98
 Estimativa inicial: realizada após o fechamento do escopo do projeto. Geralmente
é baseada em um documento inicial de requisitos, por exemplo, Documento de
Visão.
 Contagem de Pontos de Função de Referência: geralmente, realizada no

momento da aprovação dos requisitos pelo cliente. Esta Contagem de Pontos de
Função é gerada com base no documento de requisitos do sistema e modelo de
dados, caso este esteja disponível. O documento de requisitos pode ter um formato
variável, conforme preconizado pelo manual de Práticas de Contagem de Pontos
de Função (CPM), por exemplo, pode ser uma Formalização Simples de
Requisitos, Descrição Detalhada da Demanda, História de Usuário, Descrição de
Itens de Backlog, Especificação de Caso de Uso, Regras de Negócio da Aplicação,
Cenários de Uso, dentre outros.
 Contagem de Pontos de Função Final: realizada após a homologação da

aplicação. Esta contagem leva em consideração as funcionalidades efetivamente
entregues para o usuário pela aplicação.
Referências.
ROETZHEIM, W. Estimating and Managing Project Scope for New Development.

CrossTalk, Vol. April, 2005.
SOMMERVILLE, I. Software Engineering. Pearson Education Limited, 8th Edition, 2007.
 Estimar Esforço
O esforço pode ser estimado por meio do modelo simplificado de estimativas, o qual
consiste em obter um índice de produtividade em horas/PF para o projeto específico em
questão, e então multiplicar o tamanho em PF do projeto pelo índice de produtividade,
conforme a fórmula [Vazquez,2012]:
Esforço (horas) = Tamanho (PF) x Índice de Produtividade (HH/PF)
O índice de produtividade depende de diversos atributos dos projetos, dentre outros:

plataforma tecnológica, complexidade do domínio, segurança, desempenho, usabilidade,
tamanho do projeto, tipo de manutenção, desenvolvimento de componentes.
99
Por exemplo, suponha que o índice médio de produtividade da organização para
projetos de médio porte desenvolvidos em PHP seja de 12 horas/PF. Assim, se o projeto
de desenvolvimento do sistema de Gestão de projetos possui 400 PF, o esforço estimado
para a construção deste é de 400 x 12 = 4800 horas.
Referência Bibliográfica
[Vazquez, 2012] VAZQUEZ, C. et al. Análise de Pontos de Função: Medição,

Estimativas e Gerenciamento de Projetos de Software. 12ª Edição, Editora Érica Ltda,
São Paulo, 2012.
 Estimar Cronograma
Projetos muito pequenos (<100PF)
O prazo de um projeto menor que 100 PFs pode ser estimado por meio da estimativa
de esforço considerando o tamanho da equipe. Desta forma:
 Prazo em dias = Esforço / (Tam Equipe X Produtividade diária)
 Prazo em meses = Esforço/(Tam Equipe X Produtividade diária x 22 dias)
Observações importantes:
1) Produtividade diária = 6 ou 7 horas trabalho/dia – considerando uma jornada de

trabalho de 8 horas
2) Para esses projetos muito pequenos utiliza-se a alocação de apenas um recurso.
3) Há recomendações de considerar um mês com 21 dias úteis, em vez de 22 dias.
Exemplo
Suponha um projeto de 20 PF com esforço estimado em 160 horas. Alocando-se um

recurso ao projeto, tem-se o prazo estimado em 23 dias úteis, considerando-se a
produtividade de 7 horas/dia).
Então:
Prazo em dias = Esforço / (Tam Equipe X Produtividade diária)
Resulta:
Prazo em dias = 160/(1x 7) = 23 dias úteis.
100
O Roteiro de Métricas de Software do SISP v2.2 propõe a seguinte tabela de prazo
para projetos menores que 100 PF.
Fonte: Roteiro de Métricas de Software do SISP Versão 2.2
Projetos pequenos, médios e grandes (>100 PFs)
Existem vários métodos para estimar prazo de projetos utilizando como insumo o
tamanho funcional em Pontos de Função. Neste curso, é apresentada a fórmula de
Capers Jones [Jones, 2007]. A fórmula de Capers Jones estima o prazo, baseando-se no
tamanho do projeto em Pontos de Função, nos seguintes termos:
Td = V t
Onde:
Td: prazo de desenvolvimento
V: tamanho do projeto em Pontos de Função
t: o expoente t é definido de acordo com a Tabela abaixo.

101
Tipo de Sistema Expoente t
Sistema Comum – Mainframe (desenvolvimento de sistema com alto grau de reuso

0,32 a 0,33
ou manutenção evolutiva)
Sistema Comum – WEB, Mobile, Cliente Servidor 0,34 a 0,35
Sistema OO (se o projeto OO não for novidade para a equipe, não tiver o
0,36
desenvolvimento de componentes reusáveis, considerar sistema comum)
Sistema Cliente/Servidor (com alta complexidade arquitetural e integração com

0,37
outros sistemas)
Sistemas Gerenciais complexos com muitas integrações, Datawarehousing,

0,39
Geoprocessamento, Workflow
Software Básico, Frameworks, Sistemas Comerciais 0,4
Software Militar (ex: Defesa do Espaço Aéreo) 0,45
Exemplo
Um portal de complexidade baixa com 300 PF possui o prazo de desenvolvimento

estimado em 7 meses, considerando a utilização do expoente t =0,34.
Td = V t
Td = 300 0,34
Td=7 meses.
Observação: O prazo de desenvolvimento de um projeto pode ser reduzido em até

25%, mas o esforço e o custo ficam exponenciamente maiores. Deve-se avaliar o custo x
benefício de uma redução de cronograma. O Roteiro de Métricas do SISP apresenta o
seguinte:
• Redução de prazo de 10%: aumento de esforço de 20% (projetos urgentes)
• Redução de prazo de 20%: aumento de esforço de 50% (projetos críticos)
• Redução de prazo de 25%: aumento de esforço de 70% (projetos de alta

criticidade) Uma redução de cronograma maior que 25% coloca o projeto em uma região
impossível, onde o projeto não será concluído, mesmo adicionando mais recursos ao
mesmo. Recomendação: Antes de pensar em redução de cronograma, busque priorizar
os requisitos, trabalhar com processo de desenvolvimento ágil ou incremental.
102
Referências
[Jones, 2007] JONES, C. Estimating Software Costs. Second Edition, Mc Graw Hill,2007.
 Estimar Custo
Em caso de desenvolvimento interno, deve-se aferir o custo do PF calculando-se o

custo da mão de obra, considerando o esforço para entregar um PF (hora/PF) e adicionar
outros custos (impostos, ambiente...).
Em caso de projetos contratados por meio da métrica Pontos de Função, deve-se

realizar um benchmarking de preço do PF em outros contratos de projetos similares. A
estimativa de custo do projeto contratado deve levar em consideração o custo de um
ponto de função. Este custo deve abranger o custo da hora de todos os profissionais
envolvidos no desenvolvimento da solução de software. O cálculo do custo do projeto
(CP) será então da seguinte forma:
CP = QPF x CPF
Onde:
QPF = Tamanho do projeto em PF
CPF = Custo para implementar um ponto de função na plataforma em questão
 Estimar Recursos Computacionais Críticos
Estimativa de Recursos Computacionais também deve ser considerada, sendo um

componente importante para as estimativas de custos dos projetos. Um recurso
computacional é um hardware que se precisa adquirir; ou que se possui, mas precisa-se
configurar. Exemplos de recursos computacionais incluem, dentre outros: espaço em
disco para o sistema entrar em produção, um servidor específico para teste ou
homologação do sistema. Caso o projeto a ser desenvolvido não possua nenhum recurso
computacional crítico, deve ser registrado no documento de estimativas que o projeto não
possui nenhum recurso computacional crítico.
 Analisar e Aprovar Estimativas
103
As estimativas do projeto de software devem ser documentadas juntamente com as
premissas utilizadas na geração destas. As estimativas constituem a base para o Plano
do Projeto. A análise da estimativa consiste na análise das premissas consideradas,
negociação de redução de prazo, considerando a redução de escopo do projeto ou
priorização de requisitos. O Documento de estimativas deve ser aprovado pelo cliente, já
que este constitui um acordo entre a fábrica de software e o requisitante ou analista de
negócios do projeto em questão.
 Acompanhar Estimativas
No decorrer do processo de desenvolvimento, as estimativas devem ser

acompanhadas conforme o refinamento dos requisitos. O projeto deve ser reestimado
após a fase de requisitos, quando for gerada a especificação de casos de uso, e sempre
que ocorrerem mudanças significativas nos requisitos funcionais ou não funcionais.
 Calibrar e Melhorar Processo
Quando o projeto é concluído, deve-se aferir e documentar o tamanho, prazo, custo,

esforço e recursos realizados, assim como outros atributos relevantes do projeto, visando
a coleta de dados para a melhoria do processo de estimativas. As lições aprendidas
também devem ser documentadas. Periodicamente, os resultados das estimativas e as
lições aprendidas devem ser analisados visando a melhoria do processo de estimativas
da organização.
5.3.1 MÉTODOS DE ESTIMATIVA DE TAMANHO EM PONTOS DE FUNÇÃO
Seguem alguns métodos para estimativa de tamanho funcional de projetos de

software em Pontos de Função.
104
5.3.1.1 Método Contagem Estimativa de Pontos de Função (CEPF)
O método CEPF, ilustrado na figura abaixo, visa aferir o tamanho em PF de maneira

simplificada, com base no conhecimento dos requisitos iniciais do projeto. Inicialmente, os
requisitos funcionais iniciais documentados nas propostas comerciais, nos documentos de
visão, formalização simples de requisitos ou em qualquer especificação inicial do sistema
do usuário são mapeados nos tipos funcionais da Análise de Pontos de Função: Arquivo
Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta
Externa (CE) e Saída Externa (SE). Posteriormente, os Pontos de Função são associados
a cada função identificada, baseando-se nas tabelas de complexidade e de contribuição
funcional do CPM .
Figura: Contagem Estimativa de Pontos de Função (CEPF)
O estimador deve realizar uma leitura no documento inicial de requisitos, buscando

informações relevantes para a identificação de processos elementares. O processo
elementar é definido como a menor unidade de atividade significativa para o usuário. O
processo elementar deve ser completo em si mesmo, independente e deixar a aplicação
em um estado consistente. Em outras palavras, os processos elementares são funções
transacionais independentes, isto é, funções sequenciais pertencem a um mesmo
processo elementar e funções independentes constituem processos elementares
diferentes.
Uma vez identificado o processo elementar, o estimador deve buscar o

entendimento deste para classificá-lo em Entrada Externa, Consulta Externa ou Saída
105
Externa. Adicionalmente, o estimador deve descobrir os dados associados ao processo
elementar, visando a determinação da complexidade funcional da função identificada.
Caso não seja possível a identificação da complexidade da funcionalidade em questão,
recomenda-se a utilização da complexidade Média. Na análise do processo elementar
também são identificados os grupos de dados lógicos da aplicação, que são classificados
como Arquivos Lógicos Internos ou Arquivos de Interface Externa. Caso não seja possível
a identificação da complexidade da função de dados em questão, recomenda-se a
utilização da complexidade Baixa. É importante ressaltar que se o estimador identificar
mais de um Registro Lógico no Arquivo Lógico Interno, recomenda-se utilizar a
complexidade Média.
A seguir são apresentadas dicas para ajudar no mapeamento dos requisitos

funcionais da aplicação nos tipos funcionais da APF. As necessidades e funcionalidades
especificadas para o projeto, contidas no documento inicial de requisitos, devem ser
enquadradas em uma das seguintes tabelas:
Tabela 1 - Contagem dos Arquivos Lógicos Internos (ALIs): Banco de Dados Lógico
da Aplicação (tabelas e arquivos mantidos pela aplicação).
Considerações: Identifique os grupos de dados lógicos de aplicação nos modelos

de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos
documentos de requisitos (Documento de Visão, Relação de Casos de Uso, etc.). Não
considere arquivos físicos, arquivos de índices, arquivos de trabalho e tabelas de
relacionamento sem atributos próprios (tabelas que existem para quebrar o
relacionamento m x n e apenas transportam as chaves estrangeiras). As entidades fracas
também não são consideradas um ALI. Se possível, tente descobrir os atributos lógicos,
campos reconhecidos pelo usuário, e subgrupos de dados existentes para obter a
complexidade funcional, segundo as regras de contagem do CPM. Caso não seja
possível, a experiência tem mostrado que a maioria dos ALIs dos sistemas são de
complexidade Baixa.
N° ALIs Baixa: X 7 PF
N° ALIs Média: X 10 PF
N° ALIs Alta: X 15 PF
Total PF:
Tabela 1: Identificação dos Arquivos Lógicos Internos da Aplicação
106
Tabela 2 - Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de
outras Aplicações, apenas referenciados pela aplicação que está sendo estimada
(tabelas e arquivos mantidos por outra aplicação).
Considerações: Identifique os grupos de dados lógicos de outras aplicações

referenciados pela aplicação que está sendo estimada. Frequentemente, o
referenciamento de dados ocorre para a validação de informações em cadastros ou
consultas. Algumas vezes, relatórios ou consultas referenciam dados externos de outras
aplicações, também considerados AIEs. Não são considerados arquivos físicos, arquivos
de índice, arquivos de trabalho, tabelas de relacionamento sem atributos próprios e
entidades fracas.
Geralmente, os AIEs dos sistemas possuem a classificação de complexidade Baixa,

porque são considerados para a determinação da complexidade funcional do AIE apenas
os atributos referenciados pela aplicação que está sendo contada.
N° AIEs Baixa: X 5 PF
N° AIEs Média: X 7 PF
N° AIEs Alta: X 10 PF
Total PF:
Tabela 2: Identificação dos Arquivos de Interface Externa da Aplicação
Tabela 3 - Contagem de Entradas Externas (EEs): Funcionalidades que mantêm os

Arquivos Lógicos Internos (ALIs) ou alteram o comportamento da aplicação.
Considerações: Identifique as funcionalidades de manutenção de dados. Conte

separadamente a inclusão, alteração e exclusão de dados, isto é, cada função
independente de inclusão ou alteração ou exclusão deve ser contada separadamente. A
aplicação possui funções de entrada de dados que alteram o comportamento dela, por
exemplo: processamentos batch, ou processamento de informações de controle? Caso
positivo, estas funções também devem ser identificadas como Entradas Externas.
Se você não possui conhecimento sobre o processo elementar (funcionalidade

analisada), considere as Entradas Externas identificadas com complexidade Média.
107
N° EEs Baixa: X 3 PF
N° EEs Média: X 4 PF
N° EEs Alta: X 6 PF
Total PF:
Tabela 3: Identificação das Entradas Externas da Aplicação
Tabela 4 - Contagem de Consultas Externas (CEs): funcionalidades que apresentam

informações para o usuário sem a utilização de cálculos ou algoritmos. São os processos
elementares do tipo "lê - imprime", "lê - apresenta dados", incluindo consultas, relatórios,
geração de arquivos pdf, xls, downloads, entre outros.
Considerações: Você está desenvolvendo uma função para apresentar informações

para o usuário: uma consulta, relatório, listbox, download, geração de um arquivo,
geração de arquivo pdf, xls? Esta função não possui cálculos ou algoritmos para
derivação dos dados referenciados nem altera um Arquivo Lógico Interno, nem muda o
comportamento do sistema? Caso positivo, estas funções devem ser identificadas como
Consultas Externas. Se você não possui conhecimento sobre o processo elementar
(funcionalidade analisada), considere as Consultas Externas com complexidade Média.
N° CEs Baixa: X 3 PF
N° CEs Média: X 4 PF
N° CEs Alta: X 6 PF
Total PF:
Tabela 4: Identificação das Consultas Externas da Aplicação
Tabela 5 - Contagem de Saídas Externas (SEs): Funcionalidades que apresentam

informações para o usuário com utilização de cálculos ou algoritmos para derivação de
dados ou atualização de Arquivos Lógicos Internos ou mudança de comportamento da
aplicação. São as consultas ou relatórios com totalização de dados, relatórios estatísticos,
gráficos, geração de arquivos com atualização log, downloads com cálculo de percentual,
entre outros.
Considerações: Você está desenvolvendo uma funcionalidade para apresentar

informações para o usuário: uma consulta ou relatório com totalização de dados, etiquetas
de código de barras, gráficos, relatórios estatísticos, download com percentual calculado,
geração de arquivo com atualização de log? Caso positivo, estas funções devem ser
identificadas como Saídas Externas. Observe que esta função deve ter cálculos ou
108
algoritmos para processar os dados referenciados nos arquivos lógicos ou atualizar
campos (normalmente indicadores) nos arquivos ou mudar o comportamento da
aplicação. Caso não haja conhecimento da aplicação de APF ou sobre o processo
elementar (funcionalidade analisada), considere as Saídas Externas com complexidade
Média.
N° SEs Baixa: X 4 PF
N° SEs Média: X 5 PF
N° SEs Alta: X 7 PF
Total PF:
Tabela 5: Identificação das Saídas Externas da Aplicação
A Estimativa de tamanho do projeto em PF deve ser gerada totalizando-se os PF

obtidos nas Tabelas 1, 2, 3, 4 e 5.
A fórmula de contagem ou de estimativa de Pontos de Função para Projetos de

Desenvolvimento é a seguinte:
PF_DESENVOLVIMENTO = PF_INCLUIDO + PF_CONVERSÃO
5.1.1.2 MÉTODO CONTAGEM ESTIMADA DE P ONTOS DE FUNÇÃO (NESMA)
A contagem estimada de Pontos de Função é realizada da seguinte forma:
 determina-se todas as funções de todos os tipos (ALI, AIE, EE, SE, CE)
 toda função de dados (ALI, AIE) tem sua complexidade funcional classificada
como Baixa, e toda função transacional (EE, SE, CE) é classificada com
complexidade Média.
 calcula-se o total de Pontos de Função do projeto
A única diferença em relação à contagem de Pontos de Função IFPUG é que a

complexidade funcional não é determinada individualmente para cada função, mas
pré-definida para todas elas.
Fonte: https://nesma.org/themes/sizing/function-point-analysis/early-function-point-counting/
109
5.1.1.3 Método Contagem Detalhada de Pontos de Função
A contagem detalhada é a Contagem de Pontos de Função e é realizada da
seguinte forma:
 determina-se todas as funções de todos os tipos (ALI, AIE, EE, SE, CE)
 determina-se a complexidade de cada função (Baixa, Média, Alta)
 calcula-se o total de Pontos de Função do projeto
Observe que a aplicação deste método pressupõe um detalhamento dos requisitos, o

que nem sempre ocorre nas fases iniciais do ciclo de vida de projetos de software.
Fonte: https://nesma.org/themes/sizing/function-point-analysis/early-function-point-counting/
5.1.1.4 Método Contagem Indicativa de Pontos de Função (NESMA)
O Método denominado Contagem Indicativa é baseado nos estudos

desenvolvidos pela NESMA (Netherlands Software Metrics Users Association) [NESMA,
2005]. A Estimativa de tamanho é obtida, por meio da seguinte fórmula:
PF = 35 * Nº ALI + 15 * Nº AIE
Na qual:
PF: Tamanho estimado do projeto de software em Pontos de Função
Nº ALI: Número estimado de Arquivos Lógicos Internos
Nº AIE: Número Estimado de Arquivos de Interface Externa
Um Arquivo Lógico Interno (ALI) é definido como um grupo de dados logicamente

relacionados ou de informação de controle2, identificado pelo usuário, mantidos dentro da
fronteira da aplicação. Um Arquivo de Interface Externa (AIE) é definido como um grupo
de dados logicamente relacionados ou informações de controle, identificado pelo usuário,
referenciados pela aplicação, mantidos dentro da fronteira de outra aplicação.
Para obtenção das constantes “35” e “15” utilizados na fórmula acima, o método leva
em consideração as seguintes premissas [NESMA, 2005]:
 A contagem é baseada no número de Arquivos Lógicos Internos e de Arquivos de

Interface Externas.
110
 A contagem considera a complexidade média para Entradas Externas, Consultas
Externas e Saídas Externas;
 Cada Arquivo Lógico Interno – 10 PF possui 3 Entradas Externas (inclusão,

alteração, exclusão) – 12 PF, 2 Consultas Externas (consultas aos dados da
tabela) – 8 PF e 1 Saída Externa (1 relatório contendo totalizações) – 5 PF;
totalizando 35 PFs;
 Cada Arquivo de Interface Externa – 7 PF possui 2 Consultas Externas (consulta e

relatório com os dados da tabela) – 8 PF; totalizando 15 PFs.
Observe que o Método Contagem Indicativa leva em consideração somente a

quantidade de arquivos lógicos existentes (ALIs e AIEs).
Segue um exemplo de aplicação do método:
O usuário deseja manter dados de Cliente e Produto e referenciar dados de

Fornecedor.
Desta forma, este projeto possui 2 ALIs (Cliente e Produto) e 1 AIE (Fornecedor).
Portanto o tamanho estimado do projeto pelo Método Contagem Indicativa é 85 PF.
PF = 2 x 35 + 1 x 15 = 85 PF
[NESMA, 2005] NESMA - Netherlands Software Metrics Association. IndicativeFunction

Point Count: www.nesma.org.nl
5.1.1.5 Método Contagem Indicativa Inteligente
A diretriz utilizada na criação do método é a seguinte: Quanto maior o

conhecimento dos requisitos do projeto, maior deve ser a acurácia das estimativas.
A ideia é integrar ao método Contagem Indicativa o conhecimento dos requisitos do
projeto, gerando premissas que influenciarão nas constantes “35” e “15” do método
Contagem Indicativa de Pontos de Função, visando a obtenção de uma estimativa de
tamanho com maior acurácia. Note que muitos sistemas, especialmente aqueles em
versões iniciais não apresentarão as funcionalidades de relatório e exclusão para todos
ALIs. E ainda, a prática tem demonstrado que a maioria dos ALIs e AIEs são de
complexidade Simples, e não Média, conforme preconizado pelo método Indicativa de
Pontos de Função [Hazan, 2005]
111
Assim, é fundamental que as fórmulas de estimativas considerem as
características de complexidade funcional específicas de cada projeto em questão. As
premissas ou suposições utilizadas na geração das estimativas devem ser
documentadas.
Por exemplo, suponha que um sistema hipotético XPTO a ser desenvolvido, tenha
quatro tabelas pequenas (menos de 20 campos) mantidas por meio das funções de
inclusão, alteração e consulta (usada para a edição dos dados na alteração). Assim,
considera- se que o sistema possui 4 ALIs Simples. O sistema também utiliza uma
tabela de usuário do Sistema de Controle de Acesso, apenas para validação dos dados
de acesso. Assim, considera-se que o sistema possui um AIE Simples. Note que o
usuário não especificou relatórios nem funções de exclusão para esta release. Se
utilizarmos o método contagem indicativa, a contagem seria de 155 Pontos de Função,
obtidos segundo a fórmula abaixo:
PF = 4 ALIs x 35 + 1 AIE x 15
O tamanho está superestimado, o sistema XPTO é muito simples e não atende as
premissas utilizadas na concepção do método Contagem Indicativa, descritas na seção
anterior. Então para maior acurácia da estimativa, utiliza-se o conhecimento inicial do
projeto para aplicar o método “Contagem Indicativa Inteligente”. Tem-se o seguinte:
Cada ALI Simples (Tabelas pequenas) - 7 PFs possui duas Entradas Externas
(inclusão e alteração) de complexidade desconhecida, considera-se médias - 8 PFs (4
x 2) e uma Consulta Externa (recuperação de dados para alteração) de complexidade
desconhecida, considera-se média 4 PFs. Note que o índice multiplicador dos ALIs não
é mais 35 PF e sim 19 PF (8 +7 + 4).
O AIE Simples (dados de acesso - logon e senha) - 5 PFs com uma Consulta
Externa Simples (controle de acesso) com 3 PFs. Note que o índice multiplicador dos
AIEs não é mais 15 PF e sim 8 PF (5 + 3).Então, aplicando o método com novos
índices, tem-se a estimativa de 84 Pontos de Função:
PF = 4 ALIs x 19 + 1 AIE x 8
[Hazan, 2005] Hazan, Claudia. Monografia: Análise e Melhoria de um Processo de

Estimativas de Tamanho de Projetos de Software – Departamento de Informática PUC-
Rio, Fevereiro/2005
112
5.4. ESTUDO DE CASOS: ESTIMATIVA DE UM PROJETO DE DESENVOLVIMENTO DE SOFTWARE
Estudo de Casos: Realizar a Estimativa de Tamanho, Esforço e Prazo do projeto de

desenvolvimento do Sistema Gerencial da Locadora Filme Feliz (SGL). Seguem as
Premissas a serem adotadas:
1) Para a estimativa de tamanho deve ser adotado o método Contagem Estimativa de

Pontos de Função. Neste caso: a memória de cálculo, assim como a rastreabilidade das
funcionalidades deve ser preenchida.
2) Como o sistema se encontra em fase inicial de definição de requisitos, deve ser

considerado um percentual de Scope Creep de 35%.
3) O prazo deve ser estimado por meio da fórmula de Capers Jones. O sistema é comum,
de complexidade baixa, desenvolvido em PHP para Web.
4) O esforço deve ser calculado utilizando o modelo simplificado de estimativas. O

sistema será desenvolvido em PHP com a produtividade média de 10 hh/PF.
Seguem as funcionalidades identificadas para o projeto de desenvolvimento do SGL

(Sistema Gerencial da Locadora):
F1: Manter Cadastro de Usuários do Sistema (Incluir, Alterar, Excluir, Consultar) com as
seguintes informações: Matrícula, Nome, Senha, Função (atendente ou supervisor), e-
mail
OBS: Os Supervisores do sistema serão pré cadastrados com senha padrão. Esta
funcionalidade somente poderá ser executada por supervisores.
F2: Controle de Acesso: O usuário entra com a matrícula e a senha, as funcionalidades

são habilitadas de acordo com o perfil de acesso do usuário.
F3: Alterar Senha: o usuário entra com a matrícula – senha atual e nova senha. A senha
deve conter no mínimo 5 caracteres.
F4: Esqueceu senha: o usuário digita a matricula, o sistema gera uma nova senha e envia
para o e-mail do usuário em questão.
F5: Manter Cadastro de Clientes (Incluir, Alterar, Excluir e Consultar Detalhes) com as
seguintes informações: CPF, nome, endereço, telefone, celular e e-mail.
113
F6: Manter Cadastro de filmes (Incluir, Alterar, Excluir, e Consultar Detalhes) com as
seguintes informações: código, título, categoria, diretor, atores, sinopse, ano de produção,
gênero, estúdio, distribuidora e país de produção.
OBS: Esta função somente poderá ser executada pelos Supervisores.
F7: Atualizar preço de locação por categoria de filmes com as informações: categoria
filme, preço locação, data atualização.
F8: Registrar locação de filme a cliente com as seguintes informações: CPF, código filme,
data de locação, data devolução prevista, valor locação.
OBS: A data devolução prevista é gerada automaticamente pelo sistema, no entanto, o

atendente pode alterar a data de devolução em caso de alguma promoção da Locadora
e/ou acordo com o cliente. O preço de locação é recuperado e apresentado, no entanto
pode ser alterado em caso de alguma promoção da Locadora e/ou acordo com o cliente.
F9: Registrar devolução de filme com cobrança de multa se devolvido fora do prazo (uma
locação por dia de atraso), com as seguintes informações: CPF, Código filme, data
devolução realizada, multa calculada, se aplicável.
F10: Pesquisar Filmes Emprestados para o cliente com devolução pendente, entrando
com o CPF do cliente. A lista deve ser ordenada por data de devolução prevista e conter o
CPF do Cliente, Nome do Cliente, data de locação, data de devolução prevista, Código do
Filme e Título do Filme.
F11: Pesquisar Filme – deve ser apresentada uma lista com todos os filmes que atendem
o critério de busca com total de registros encontrados. O critério de busca é o título do
filme (total ou parcial) combinado com gênero, categoria e situação (disponível,
emprestado, todos). A lista deve apresentar o código do filme, título, gênero, categoria,
ano e situação. A lista deve ser ordenada dinamicamente de acordo com a coluna
escolhida pelo usuário.
F12: Pesquisar Cliente – a função traz uma lista ordenada pelo nome dos clientes com
todos os clientes que atendem o critério de busca com total de registros encontrados. O
critério de busca é o nome ou parte do nome do cliente. A lista contém as seguintes
informações: nome, telefone, celular.
114
F13: Relatório de filmes por cliente (quais filmes cada cliente realizou locação e devolveu,
ordenado por data). Este relatório deve apresentar a lista de clientes em ordem alfabética
e ter como filtro o período (data início e data fim) e apresentar CPF Cliente, Nome Cliente,
Código Filme, Nome Filme, data locação, data devolução realizada. Este relatório deve
conter também os valores pagos pelo cliente, considerando os dados de multa. E
totalizando os resultados.
F14: Relatório de empréstimos por filme (quantas vezes cada filme foi emprestado em
cada mês). Este relatório deve ter como filtro o mês e apresentar o código do filme, nome
do filme e quantas vezes o filme foi emprestado. O usuário pode escolher como ordenar o
relatório por nome do filme ou por totalização de empréstimos.
F15: Envio de requisição de compra para o sistema de compras (externo) cada vez que
um filme for emprestado mais de 15 vezes no mesmo mês. Esse relatório é enviado
automaticamente no fim de cada mês com a lista dos filmes (código, título e distribuidora)
informando os filmes locados mais de 15 vezes no mês corrente. O relatório deve ser
agrupado por distribuidora e enviado na forma de um arquivo xml.
Segue a solução do Estudo de Casos:

A primeira estimativa a ser gerada é a de tamanho. Como os requisitos possuem um
detalhamento dos grupos de dados a serem processados pelas funcionalidades descritas,
então deve ser utilizado o método Contagem Estimativa de Pontos de Função, visando
garantir uma melhor acurácia para a estimativa de tamanho a ser gerada.
Segue a estimativa de tamanho do Sistema Gerencial da Locadora Filme Feliz (SGL).
Propósito: Estimar o tamanho funcional do projeto de desenvolvimento do Sistema

Gerencial da Locadora Filme Feliz (SGL).
Escopo: O escopo da contagem são as funções descritas na especificação do projeto de

desenvolvimento do Sistema Gerencial da Locadora Filme Feliz (SGL).
Tipo de Contagem: Projeto de Desenvolvimento
Fronteira: Sistema Gerencial da Locadora Filme Feliz (SGL)
115
F1: Manter Cadastro de Usuários do Sistema (Incluir, Alterar, Excluir, Consultar) com as
seguintes informações: Matricula, Nome, Senha, Função (atendente ou supervisor), e-mail
OBS: Os Supervisores do sistema serão pré cadastrados com senha padrão. Esta
funcionalidade somente poderá ser executada por supervisores.
A descrição da F1 demonstra a necessidade da criação de um grupo lógico de dados de

Usuários mantido por processos elementares da aplicação, contado como Arquivo Lógico
Interno. Além disso, são identificados os seguintes processos elementares: Incluir
Usuário, Alterar Usuário, Excluir Usuário, contados como Entradas Externas e Consultar
Usuário contado como Consulta Externa.
ALI: Usuário
RL: 1 - Usuário
TD: 5 - Matrícula, Nome, Senha, Função, e-mail
Complexidade: Baixa
PF: 7 PF
EE: Incluir Usuário
AR:1 – Usuário
TD: 7 - Matrícula, Nome, Senha, Função, e-mail, ação, mensagem
Complexidade: Baixa
PF: 3 PF
EE: Alterar Usuário
AR:1 – Usuário
Complexidade: Baixa
PF: 3 PF
EE: Excluir Usuário

116
AR:1 – Usuário
TD: 3 - Matrícula, ação, mensagem
Complexidade: Baixa
PF: 3 PF
CE: Consultar Usuário
AR:1 – Usuário
Complexidade: Baixa
PF: 3 PF
F2: Controle de Acesso: O usuário entra com a matricula e a senha, as funcionalidades

são habilitadas de acordo com o perfil de acesso do usuário.
A F2 descreve o processo elementar de Controle de Acesso da aplicação. Este processo

é contado como Saída Externa porque cria dados derivados na habilitação/desabilitação
de funções de acordo com o perfil de acesso.
SE: Controle de Acesso
AR:1 – Usuário
TD: 4 – Matrícula, Senha, ação, mensagem
Complexidade: Baixa
PF: 4 PF
F3: Alterar Senha: o usuário entra com a matrícula – senha atual e nova senha. A senha
deve conter no mínimo 5 caracteres.
A F3 descreve o processo elementar Alterar Senha contado como Entrada Externa.
EE: Alterar Senha
117
AR: 1 – Usuário
TD: 5 - Matrícula, Senha atual, Nova senha, ação, mensagem
Complexidade: Baixa
PF: 3 PF
F4: Esqueceu senha: o usuário digita a matricula, o sistema gera uma nova senha e envia
para o e-mail do usuário em questão.
A F4 descreve o Processo Elementar Esqueceu Senha. Observe que a intenção primária

da funcionalidade é a apresentação de senha para o usuário, enviando por e-mail. No
entanto, não se trata apenas de uma recuperação de senha. Como o sistema gera uma
nova senha para o envio por e-mail, então é mantido o ALI Usuário. Portanto, a
funcionalidade é contada como Saída Externa.
SE: Esqueceu Senha
AR:1 – Usuário
TD: 5 – Matricula, Senha, e-mail, ação, mensagem
Complexidade: Baixa
PF: 4 PF
F5: Manter Cadastro de Clientes (Incluir, Alterar, Excluir e Consultar Detalhes) com as
seguintes informações: CPF, nome, endereço, telefone, celular e e-mail.

Clientes mantido por processos elementares da aplicação, contado como Arquivo Lógico
Interno. Além disso, são identificados os seguintes processos elementares: Incluir Cliente,
Alterar Cliente, Excluir Cliente, contados como Entradas Externas e Consultar Detalhes
Cliente contado como Consulta Externa.
ALI: Cliente
118
RL: 1 - Cliente
TD: 6 - CPF, nome, endereço, telefone, celular, e-mail
Complexidade: Baixa
PF: 7 PF
EE: Incluir Cliente
AR:1 – Cliente
TD: 8 - CPF, nome, endereço, telefone, celular, e-mail, ação, mensagem
Complexidade: Baixa
PF: 3 PF
EE: Alterar Cliente
AR:1 – Cliente
Complexidade: Baixa
PF: 3 PF
EE: Excluir Cliente
AR:1 – Cliente
TD: 3 - CPF, ação, mensagem
Complexidade: Baixa
PF: 3 PF
CE: Consultar Detalhes Cliente
AR:1 – Cliente
119
Complexidade: Baixa
PF: 3 PF
F6: Manter Cadastro de filmes (Incluir, Alterar, Excluir, e Consultar Detalhes) com as
seguintes informações: código, título, categoria, diretor, atores, sinopse, ano de produção,
gênero, estúdio, distribuidora e país de produção.

Filmes mantido por processos elementares da aplicação, contado como Arquivo Lógico
Interno. Além disso, são identificados os seguintes processos elementares: Incluir Filme,
Alterar Filme, Excluir Filme, contados como Entradas Externas e Consultar Detalhes Filme
contado como Consulta Externa.
ALI: Filme
RL: 1 - Filme
TD: 11 - código, título, categoria, diretor, atores, sinopse, ano de produção, gênero,
estúdio, distribuidora, país de produção
Complexidade: Baixa
PF: 7 PF
EE: Incluir Filme
AR:1 – Filme
estúdio, distribuidora, país de produção, ação, mensagem
Complexidade: Baixa
PF: 3 PF
EE: Alterar Filme
AR:1 – Filme
120
Complexidade: Baixa
PF: 3 PF
EE: Excluir Filme
AR:1 – Filme
TD: 3 - Código, ação, mensagem
Complexidade: Baixa
PF: 3 PF
CE: Consultar Detalhes Filme
AR:1 – Filme
Complexidade: Baixa
PF: 3 PF
F7: Atualizar preço de locação por categoria de filmes com as informações: categoria
filme, preço locação e data atualização.

controle de preço de locação mantido por processo elementar da aplicação, contado
como Arquivo Lógico Interno. Além disso, são identificados os seguintes processos
elementares: Atualizar Preço de Locação contado como Entrada Externa e a Consulta
Implícita – Atualizar Preço de Locação contado como Consulta Externa.
ALI: Preço de Locação
RL: 1 – Preço de Locação
121
TD: 3 - categoria filme, preço locação, data atualização
Complexidade: Baixa
PF: 7 PF
EE: Atualizar Preço de Locação
AR:1 – Preço de Locação
TD: 5 - categoria filme, preço locação, data atualização,ação, mensagem
Complexidade: Baixa
PF: 3 PF
CE: Consulta Implícita - Atualizar Preço de Locação
AR:1 – Preço de Locação
TD: 4 - categoria filme, preço locação, data atualização,ação
Complexidade: Baixa
PF: 3 PF
F8: Registrar locação de filme a cliente com as seguintes informações: CPF, código filme,
data de locação, data devolução prevista, preço locação.
OBS: A data devolução prevista é gerada automaticamente pelo sistema, no entanto, o

atendente pode alterar a data de devolução em caso de alguma promoção da Locadora
e/ou acordo com o cliente. O preço de locação é recuperado e apresentado, no entanto
pode ser alterado em caso de alguma promoção da Locadora e/ou acordo com o cliente.

Locação mantido por processo elementar da aplicação, contado como Arquivo Lógico
Interno. Além disso, deve ser considerado o processo elementar Registrar Locação de
filme contado como Entrada Externa.
122
ALI: Locação
RL: 1 – Locação
TD: 7 - CPF, código filme, data devolução prevista, data de locação, data devolução
realizada, multa calculada, preço locação
Complexidade: Baixa
PF: 7 PF
Observação: Os TDs data devolução realizada, multa calculada estão descritos na F9.
EE: Registrar Locação
AR: 4 – Locação, Cliente, Filme, Preço de Locação
TD: 6 - CPF, código filme, data devolução prevista, preço locação, ação, mensagem
Complexidade: Alta
PF: 6 PF
Observação: Os TDs nome do cliente e nome do filme podem ser contados caso a
funcionalidade apresente estas informações para o usuário.
F9: Registrar devolução de filme com cobrança de multa se devolvido fora do prazo (uma
locação por dia de atraso), com as seguintes informações: CPF, Código filme, data
devolução realizada, multa calculada, se aplicável.
A F9 descreve o processo elementar Registrar devolução de filme contado como Entrada

Externa.
EE: Registrar devolução de filme
AR: 3 – Locação, Cliente, Filme
TD: 5 - CPF, Código Filme, multa calculada, ação, mensagem
Complexidade: Alta
PF: 6 PF
123
Observação: Os TDs nome do cliente e nome do filme podem ser contados caso a
funcionalidade apresente estas informações para o usuário. Observe que o preço da
locação e a data de prevista de devolução, utilizados para o cálculo da multa não são
contados como TD porque não atravessam a fronteira da aplicação.
F10: Pesquisar Filmes Emprestados para o cliente com devolução pendente, entrando
com o CPF do cliente. A lista deve ser ordenada por data de devolução prevista e conter o
CPF do Cliente, Nome do Cliente, data de locação, data de devolução prevista, Código do
Filme e Título do Filme.
A F10 descreve o processo elementar Pesquisar Filmes Emprestados contado como

Consulta Externa. Observe que não há dados calculados ou derivados. Existe apenas
uma comparação da data de locação prevista com a data atual. A data atual não é
contada como TD porque não atravessa a fronteira da aplicação.
CE: Pesquisar Filmes Emprestados
AR: 3 – Locação, Cliente, Filme
TD: 8 - CPF do Cliente, Nome do Cliente, data de locação, data de devolução prevista,
Código do Filme, Título do Filme, ação, mensagem
PF: 4 PF
F11: Pesquisar Filme – deve ser apresentada uma lista com todos os filmes que atendem
o critério de busca com total de registros encontrados. O critério de busca é o título do
filme (total ou parcial) combinado com gênero, categoria e situação (disponível,
emprestado, todos). A lista deve apresentar o código do filme, título, gênero, categoria,
ano e situação. A lista deve ser ordenada dinamicamente de acordo com a coluna
escolhida pelo usuário.
A F11 descreve o processo elementar Pesquisar Filmes contado como Saída Externa.
Porque a funcionalidade deve apresentar o total de registros encontrados, ou seja, um
dado calculado.
SE: Pesquisar Filmes
AR: 2 - Filme, Locação
124
TD: 11 – critério de busca (título ou parte título filme), título do filme, gênero, categoria,
situação, código do filme, ano, total de registros, como ordenar, ação, mensagem
PF: 5 PF
F12: Pesquisar Cliente – a função traz uma lista ordenada pelo nome dos clientes com
todos os clientes que atendem o critério de busca com total de registros encontrados. O
critério de busca é o nome ou parte do nome do cliente. A lista contém as seguintes
informações: nome, telefone, celular.
A F12 descreve o processo elementar Pesquisar Clientes contado como Saída Externa.
Porque a funcionalidade deve apresentar o total de registros encontrados, ou seja, um
dado calculado.
SE: Pesquisar Clientes
AR: 1 - Cliente
TD: 6 - critério de busca (nome ou parte do nome do cliente), nome do cliente, telefone,
celular, total de registros, ação, mensagem
Complexidade: Baixa
PF: 4 PF
F13: Relatório de filmes por cliente (quais filmes cada cliente realizou locação e devolveu,
ordenado por data). Este relatório deve apresentar a lista de clientes em ordem alfabética
e ter como filtro o período (data início e data fim) e apresentar CPF Cliente, Nome Cliente,
Código Filme, Nome Filme, data locação, data devolução realizada. Este relatório deve
conter também os valores pagos pelo cliente, considerando os dados de multa. E
totalizando os resultados.
A F13 descreve o processo elementar Relatório de filmes por cliente contado como Saída
Externa. Porque a funcionalidade deve apresentar uma totalização dos valores pagos pelo
cliente.
SE: Relatório de filmes por cliente

125
AR: 3 - Cliente, Locação, Filme
TD: 12 - data início, data fim, CPF Cliente, Nome Cliente, Código Filme, Nome Filme, data
locação, data devolução realizada, valor pago, total pago, ação, mensagem
PF: 5 PF
F14: Relatório de empréstimos por filme (quantas vezes cada filme foi emprestado em
cada mês). Este relatório deve ter como filtro o mês e apresentar o código do filme, nome
do filme e quantas vezes foi emprestado. O usuário pode escolher como ordenar o
relatório por nome do filme ou por totalização de empréstimos.
A F14 descreve o processo elementar Relatório de empréstimos por filme contado como
Saída Externa. Porque a funcionalidade deve apresentar a totalização de quantas vezes o
filme foi emprestado, dado calculado.
SE: Relatório de empréstimos por filme
AR: 2 - Locação, Filme
TD: 7 – mês, código do filme, nome do filme, total empréstimos, como ordenar, ação,
mensagem
PF: 5 PF
F15: Envio de requisição de compra para o sistema de compras (externo) cada vez que
um filme for emprestado mais de 15 vezes no mesmo mês. Esse relatório é enviado
automaticamente no fim de cada mês com a lista dos filmes (código, título e distribuidora)
informando os filmes locados mais de 15 vezes no mês corrente. O relatório deve ser
agrupado por distribuidora e enviado na forma de um arquivo xml.
A F15 descreve o processo elementar Enviar requisição de compra contado como Saída
Externa. Porque a funcionalidade deve realizar um cálculo para identificar os filmes
emprestados mais de 15 vezes.
126
SE: Enviar Requisição de Compra
AR: 2 – Locação, Filme
TD: 4 – data, código, título, distribuidora
Complexidade: Baixa
PF: 4 PF
Observe que os campos acessados que não atravessam a fronteira da aplicação não
devem ser contados como Tipo de Dados (TD). A data é o atributo de entrada para
disparar o processo elementar.
Segue a Contagem Estimativa de Pontos de Função do Sistema Gerencial da Locadora

Filme Feliz (SGL).
Memória de Cálculo
Nome da Tipo de Compl. Tamanho

Funcionalidade Função (B,M,A)
AR/RL TD
[F1] Usuário ALI 1 - Usuário 5 - Matrícula, Nome, Senha, B 7 PF
Função, e-mail
[F1] Incluir Usuário EE 1 - Usuário 7 - Matricula, Nome, Senha, B 3 PF
Função, e-mail, ação, mensagem
[F1] Alterar Usuário EE 1 - Usuário 7 - Matrícula, Nome, Senha, B 3 PF

Função, e-mail, ação, mensagem
[F1] Excluir Usuário EE 1 - Usuário 3 - Matricula, ação, mensagem B 3 PF
[F1] Consultar Usuário CE 1 - Usuário 7 - Matrícula, ação, mensagem B 3 PF
127
[F2] Controle de Acesso SE 1 - Usuário 4 – Matricula, Senha, ação, B 4 PF
mensagem
[F3] Alterar Senha EE 1 - Usuário 5 - Matricula, senha atual, nova B 3 PF

senha, ação, mensagem
[F4] Esqueceu Senha SE 1 - Usuário 5 – Matrícula, Senha, e-mail, B 4 PF

ação, mensagem
[F5] Cliente ALI 1 - Cliente 6 - CPF, nome, endereço, B 7 PF

telefone, celular, e-mail
[F5] Incluir Cliente EE 1 - Cliente 8 - CPF, nome, endereço, B 3 PF

telefone, celular, e-mail, ação,
mensagem
[F5] Alterar Cliente EE 1 - Cliente 8 - CPF, nome, endereço, B 3 PF
telefone, celular, e-mail, ação,
mensagem
[F5] Excluir Cliente EE 1 - Cliente 3 - CPF, ação, mensagem B 3 PF
[F5] Consultar Detalhes CE 1 - Cliente 8 - CPF, nome, endereço, B 3 PF

Cliente telefone, celular, e-mail, ação,
mensagem
[F6] Filme ALI 1 - Filme 11 - código, título, categoria, B 7 PF

diretor, atores, sinopse, ano de
produção, gênero, estúdio,
distribuidora, país de produção
[F6] Incluir Filme EE 1 - Filme 13 - código, título, categoria, B 3 PF

distribuidora, país de produção,
ação, mensagem
[F6] Alterar Filme EE 1 - Filme 13 - código, título, categoria, B 3 PF
ação, mensagem
[F6] Excluir Filme EE 1 - Filme 3 – código, ação, mensagem B 3 PF
[F6] Consultar Detalhes CE 1 - Filme 13 - código, título, categoria, B 3 PF

Filme diretor, atores, sinopse, ano de
ação, mensagem
[F7] Preço de Locação ALI 1 – Preço de 3 - categoria filme, preço locação, B 7 PF
Locação data atualização
128
[F7] Atualizar Preço de EE 1 – Preço de 5 - categoria filme, preço locação, B 3 PF
Locação Locação data atualização,ação, mensagem
[F7] Consulta Implícita - CE 1 – Preço de 4 - categoria filme, preço locação, B 3 PF

Atualizar Preço de Locação data atualização,ação
Locação
[F8] Locação ALI 1 – Locação 7 - CPF, código filme, data B 7 PF
devolução prevista, data de
locação, data devolução
realizada, multa calculada, preço
locação
[F8] Registrar Locação EE 4 – Locação, 6 - CPF, código filme, data A 6 PF
Cliente, Filme, devolução prevista, preço
Preço de locação, ação, mensagem
Locação
[F9] Registrar devolução EE 3 – Locação, 5 - CPF, Código Filme, multa A 6 PF
de filme Cliente, Filme calculada,ação, mensagem
[F10] Pesquisar Filmes CE 3 – Locação, 8 - CPF do Cliente, Nome do M 4 PF

Emprestados Cliente, Filme Cliente, data de empréstimo, data
de devolução prevista, Código do
Filme, Título do Filme, ação,
mensagem
[F11] Pesquisar Filmes SE 2 - Filme, 11 – critério de busca (título ou M 5 PF
Locação parte título filme), título do filme,
gênero, categoria, situação,
código do filme, ano, total de
registros, como ordenar, ação,
mensagem
[F12] Pesquisar Clientes SE 1 - Cliente 6 - critério de busca (nome ou B 4 PF

parte do nome do cliente), nome
do cliente, telefone, celular, total
de registros, ação, mensagem
[F13] Relatório de filmes SE 3 - Cliente, 12 - data início, data fim, CPF M 5 PF
por cliente Locação, Filme Cliente, Nome Cliente, Código
Filme, Nome Filme, data locação,
data devolução realizada, valor
pago, total pago, ação,
mensagem
[F14] Relatório de SE 2 – Locação, 7 – mês, código do filme, nome M 5 PF
empréstimos por filme Filme do filme, total empréstimos, como
ordenar, ação, mensagem
[F15] Enviar Requisição SE 2 – Locação, 4 – data, código, título, B 4 PF

de Compra Filme distribuidora
Total: 127 PF
129
Estimativa de Tamanho Funcional:
Considerando o Fator de Scope Creep de 35%, conforme descrito no Estudo de Casos:
Tamanho Estimado = 127 x 1,35 = 171,45 PF ou 172 PF
Estimativa de Prazo:
Conforme descrito no Estudo de Casos, o sistema é Web de complexidade baixa. Desta
forma, deve ser aplicado o expoente t = 0,34 da fórmula de Capers Jones.
0,34
Prazo Estimado = 172 = 5,8 meses
Observação: Análise da Região Impossível (RI)
RI = 5,8 – 25% = 4,4 meses

A região impossível desse projeto é de 0 a 4,4 meses. Ou seja, não é recomendado o
comprometimento com um prazo inferior a 4,4 meses. E ainda, um prazo de
desenvolvimento inferior a 5,8 pode representar alocação de esforço e custo do projeto
relativamente alto.
Estimativa de Esforço:
Conforme descrito no Estudo de Casos, o sistema será desenvolvido em PHP e a
produtividade média da equipe é de 10 hh/PF.
Esforço Estimado = 172 x 10 = 1720 horas
Estimativa de Equipe:
Considerando a dedicação de desenvolvimento do projeto de 7 horas/dia e o mês com 22
dias úteis.
Equipe = 1720 / (7 x 22 x 5,8) = 2 recursos
130
131
MÓDULO 6. ROTEIRO DE MÉTRICAS DE SOFTWARE DO SISP
Este módulo tem como objetivo:
 Apresentar as Melhores Práticas associadas ao Uso de Métricas em Contratos de

Fábrica de Software.
 Discutir a Utilização de Roteiros de Métricas de forma complementar o Manual de

Práticas de Contagem (CPM).
 Descrever o Roteiro de Métricas de Software do SISP versão 2.2
6.1. MELHORES PRÁTICAS: USO DE MÉTRICAS EM CONTRATOS DE SOFTWARE
A Instrução Normativa IN04 da SLTI/MPOG recomenda o uso de métricas em

soluções de software, restringindo o uso da métrica de esforço homem-hora. Os Acórdãos
do Tribunal de Contas da União (TCU) recomendam a utilização da métrica Pontos de
Função Não Ajustados em contratos de prestação de serviços de desenvolvimento e
manutenção de sistemas.
O uso de métricas em contratos de software requer alguns cuidados. Seguem

algumas práticas recomendadas.
 Obter um Documento de Requisitos com Qualidade
O Documento de Requisitos constitui: um acordo comum entre cliente e fornecedor;

a base para a construção do projeto de software; a base para as estimativas dos projetos
de software. Desta forma, é fundamental garantir a qualidade do documento de requisitos.
Uma boa prática é analisar os requisitos durante a Contagem Estimativa de Pontos de
Função.
Importante: A métrica PF considera o que foi requisitado e recebido pelo usuário.

Portanto, o documento de requisitos constitui a base para a contagem de PF e deve ser
assinado pelo contratante.
132
 Estabelecer Regras para tratar as mudanças de requisitos
Os requisitos iniciais do projeto provavelmente não permanecerão "congelados" até o

final do projeto. As mudanças de requisitos são bastante comuns em projetos de software,
à medida que o usuário e a equipe de desenvolvimento vão conhecendo melhor o projeto.
Assim, é importante definir como tratar tais mudanças de requisitos com métricas de
software.
Importante: Para evitar muitas mudanças de requisitos não solicite à fábrica de

software a construção de requisitos que ainda estão em definição.
 Considerar a Garantia da Qualidade
A qualidade de qualquer produto é fundamental. Neste contexto, deve-se evitar

defeitos em projetos de software por meio do estabelecimento de indicadores da
qualidade em acordos de níveis de serviço. Um indicador bastante usado é o defeitos/PF.
Importante: Defina o que é um defeito, os tipos de defeitos e as severidades.

Estabeleça metas para o indicador, por exemplo 0,3 defeitos/PF.
 Estabelecer Cronograma e Taxa de Entrega Mensal
É comum o atraso de projetos de software. Muitas vezes esses atrasos ocorrem

devido à ausência de métodos de estimativas. Assim, é fundamental o estabelecimento
de métodos de estimativas de prazo em contratos de software, por exemplo Fórmula de
Capers Jones. Outro ponto é o estabelecimento de taxa de entrega mínima mensal, por
exemplo 200 PF/mês.
Importante: Em projetos menores que 100 PF onde não se aplica o uso da fórmula
de Capers Jones, é comum o estabelecimento de prazo por faixa de tamanho do projeto
com base na produtividade.
133
Prazo máximo (em dias úteis)
Tamanho do Projeto
Projetos Complexidade Baixa Projetos Complexidade Média
Até 10 PF 9 dias 15 dias
De 11 PF a 20 PF 18 dias 30 dias
Estimativa de prazos de projetos menores que 100 PF
Fonte: Roteiro de Métricas de Software do SISP v2.2
 Estabelecer Métricas para Projetos de Manutenção não contemplados pelo

CPM
O Manual de Práticas de Contagem de Pontos de Função (CPM 4.3) define as

regras de contagem de Pontos de Função. É importante ressaltar que a métrica de Pontos
de Função foi concebida como uma medida de tamanho funcional para projetos de
desenvolvimento e de melhoria (manutenção evolutiva) de software. No entanto, os
projetos de software não estão limitados a projetos de desenvolvimento e de melhoria.
Desta forma, torna-se essencial a definição de métricas para dimensionar o tamanho de
outros tipos projetos de manutenção, os quais são itens não mensuráveis pelo CPM.
Estas métricas devem ser definidas no Roteiro de Métricas da organização.
6.2 ROTEIROS DE MÉTRICAS DE S OFTWARE
O Manual de Práticas de Contagem de Pontos de Função (CPM 4.3.1) define as

regras de contagem de pontos de função. É importante ressaltar que a métrica Ponto de
Função foi concebida como uma medida de tamanho funcional para projetos de
desenvolvimento e de melhoria de software. No entanto, os projetos de software não
estão limitados a projetos de desenvolvimento e de melhoria. Desta forma, torna-se
134
essencial a definição de métricas para dimensionar o tamanho de outros tipos de projetos
de manutenção, os quais são itens não mensuráveis pelo CPM.
Além disso, o CPM não tem como objetivo suportar contratos de prestação de
serviços de desenvolvimento e manutenção de sistemas. Assim, torna-se necessário criar
roteiros complementares, contemplando questões não abordadas pelo manual.
6.3 ROTEIRO DE MÉTRICAS DE SOFTWARE DO SISP
Vamos apresentar os tipos de projetos de software e um método para contagem de

Pontos de Função das mudanças de requisitos que ocorrem no decorrer dos projetos de
software, descritos no Roteiro de Métricas de Software do SISP v2.2.
6.3.1. Projetos de Desenvolvimento

Um projeto de desenvolvimento está associado a uma demanda para desenvolver
um novo sistema. Segue a fórmula de contagem de Projetos de Desenvolvimento,
seguindo o CPM.
PF_Desenvolvimento = PF_ INCLUÍDO + PF_CONVERSÃO
onde:
PF_INCLUÍDO: Pontos de Função associados às funcionalidades que farão parte da

aplicação.
PF_CONVERSÃO: Pontos de Função associados às funcionalidades de conversão

de dados. Exemplos de funções de conversão incluem: migração ou carga inicial de
dados para preenchimento das novas tabelas criadas e relatórios associados à migração
de dados.
6.3.2. Projetos de Melhoria
O Projeto de Melhoria (enhancement), também denominado de projeto de melhoria

funcional ou manutenção evolutiva, está associado às mudanças em requisitos funcionais
da aplicação, ou seja, à inclusão de novas funcionalidades, alteração ou exclusão de
funcionalidades em aplicações implantadas. O Roteiro de Métricas SISP utiliza um Fator
135
de Impacto para o cálculo de PF das funcionalidades alteradas e excluídas. Segue a
fórmula de cálculo utilizada no dimensionamento de projetos de melhoria:
PF_MELHORIA = PF_INCLUÍDO + (FI x PF_ALTERADO) + (0,30 x PF_EXCLUÍDO) +

PF_CONVERSÃO
 PF_INCLUÍDO: Pontos de Função associados às novas funcionalidades que farão
parte da aplicação.
 PF_ALTERADO: Pontos de Função associados às funcionalidades existentes na

aplicação que serão alteradas no projeto de manutenção.
 PF_EXCLUÍDO: Pontos de Função associados às funcionalidades existentes na

aplicação que serão excluídas no projeto de manutenção.
 PF_CONVERSÃO: Pontos de Função associados às funcionalidades de conversão

de dados dos projetos de melhoria. Exemplos de funções de conversão incluem:
migração ou carga inicial de dados para preenchimento das novas tabelas criadas
e relatórios associados à migração de dados.
FI ( Fator de Impacto) pode variar de 50% a 90% conforme condições abaixo:
 FI = 50% para funcionalidade de sistema desenvolvida ou mantida por meio de um

projeto de melhoria pela empresa contratada.
 FI = 75% para funcionalidade de sistema não desenvolvida ou mantida por meio de

um projeto de melhoria pela empresa contratada e sem necessidade de
redocumentação da funcionalidade.
 FI = 90% para funcionalidade de sistema não desenvolvida ou mantida por meio de

um projeto de melhoria pela empresa contratada e com necessidade de
redocumentação da funcionalidade. FI = 90% representa a adição de 15% como
fator de redocumentação ao Fator de Impacto anterior (75%).
Nesse caso, a contratada deve redocumentar a funcionalidade mantida, gerando a

documentação completa da mesma, aderente ao processo de software da contratante. Se
houver uma nova demanda de projeto de melhoria na funcionalidade em questão, será
considerado que a contratada desenvolveu a funcionalidade. Observe que o percentual de
90% apenas será considerado na primeira demanda de projeto de melhoria em cada
funcionalidade.
136
6.3.3 Projetos de Migração de Dados
O roteiro SISP recomenda a supressão do PF_CONVERSÃO das fórmulas de

contagem de pontos de função de projetos de desenvolvimento e de melhoria nos
casos específicos onde for caracterizado um esforço relativamente maior dessa
atividade, tais como nos casos específicos de migração de dados de banco de
dados hierárquico para banco de dados relacionais, e no tratamento de funções
complexas de migração de dados. Nesses casos, recomendamos tratar esse serviço
como projeto separado de migração de dados.
Os projetos de migração de dados devem ser contados como um novo projeto

de desenvolvimento de um sistema, seguindo a fórmula abaixo:
PF_CONVERSÃO = PF_INCLUÍDO
Um projeto de migração deve contemplar minimamente: os ALI mantidos pela

migração, Entradas Externas - considerando as cargas de dados nos ALI e, caso
sejam solicitados pelo usuário relatórios gerenciais das cargas, estes serão
contados como Saídas Externas. Todas as contagens de PF devem ser realizadas
com base nas funcionalidades requisitadas e recebidas pelo usuário.
6.3.4 Manutenção Corretiva
Mesmo com a execução de atividades de garantia da qualidade, pode-se

identificar defeitos na aplicação entregue. A manutenção corretiva altera o software
para correção de defeitos. Encontram-se nesta categoria as demandas de correção
de erros (bugs) em funcionalidades de sistemas em produção.
Quando o sistema em produção tiver sido desenvolvido pela contratada, a

manutenção corretiva será do tipo Garantia se estiver no período de cobertura e em
conformidade com as demais condições de garantia previstas em contrato. Caso
não exista cláusula contratual de garantia, deve ser considerada a garantia
preconizada por lei (Código do Consumidor).
Quando o sistema estiver fora da garantia ou não tiver sido desenvolvido pela
empresa contratada, deverá ser estimado e calculado o tamanho do projeto de
137
manutenção corretiva. Nestes casos, a aferição do tamanho em pontos de função da
funcionalidade ou das funcionalidades corrigidas deve considerar um fator de
impacto (FI) sobre o PF_ALTERADO.
PF_CORRETIVA = FI x PF_ALTERADO
Fator de Impacto (FI):
 50% quando estiver fora da garantia e a correção for feita pela mesma
empresa que desenvolveu a funcionalidade.
 75% quando estiver fora da garantia e a correção for feita por empresa
diferente daquela que desenvolveu a funcionalidade.
Deve-se destacar que, além da correção das funcionalidades em questão, a

documentação do projeto de manutenção corretiva deve ser realizada. Além disso,
caso exista a documentação das funcionalidades impactadas, estas deverão ser
atualizadas, caso contrário, se for demandada a redocumentação dessas
funcionalidades, deve-se adicionar ao FI um fator de redocumentação de 15%,
conforme descrito em Projeto de melhoria.
6.3.5 Mudança de Plataforma
São considerados nesta categoria projetos que precisam ser migrados para
outra plataforma. Por exemplo, um sistema legado em COBOL precisa ser
redesenvolvido em JAVA; o banco de dados de um sistema legado precisa ser
migrado para o DB2.
Os projetos de mudança de plataforma que se enquadrem em mais de um dos

tipos, descritos a seguir, devem ser contados apenas uma vez, considerando o tipo
de projeto com maior contagem de pontos de função. Seguem os tipos de projetos
de Mudança de Plataforma.
 Mudança de Plataforma - Linguagem de Programação
As demandas de redesenvolvimento de sistemas em outra linguagem de

programação devem ser consideradas como novos projetos de desenvolvimento.
138
Segue a fórmula de cálculo:
PF_REDESENVOLVIMENTO_LINGUAGEM = PF_INCLUÍDO + PF_CONVERSÃO
 Mudança de Plataforma - Banco de Dados
As demandas de redesenvolvimento de sistemas para utilizar um outro sistema

gerenciador de banco de dados podem ser de dois tipos: mudança de banco de
dados hierárquico para relacional e mudança de banco de dados relacional para
relacional. Seguem as fórmulas de cálculo:
PF_REDESENVOLVIMENTO_BD_HIERÁRQUICO = PF_INCLUÍDO + PF_CONVERSÃO
PF_REDESENVOLVIMENTO_BD_RELACIONAL = (PF_ALTERADO x 0,30) +

PF_CONVERSÃO
6.3.6 Atualização de Versão
São consideradas nesta categoria demandas para uma aplicação existente ou

parte de uma aplicação existente executar em versões diferentes de browsers (ex:
Internet Explorer, Firefox, Chrome, etc) ou de linguagens de programação (ex:
versão mais atual do JAVA). Também são consideradas nesta categoria atualização
de versão de banco de dados. Seguem os tipos de Atualização de Plataforma.
 Atualização de Versão - Linguagem de Programação
As demandas de atualização de versão de linguagem de programação, por

exemplo, atualização da versão do JAVA de um sistema. As funções de dados não
devem ser contadas. Devem ser contadas apenas as funcionalidades impactadas.
Estas demandas devem ser dimensionadas de acordo com a fórmula abaixo.
PF_ATUALIZAÇÃO_VERSÃO_LINGUAGEM = PF_ALTERADO X 0,30
 Atualização de Versão - Browser
Nesta categoria encontram-se as demandas de atualização de aplicações Web

para executar em novas versões de um mesmo browser e para suportar a execução
em mais de um browser. É importante destacar que este tipo de procedimento
139
usualmente é realizado quando é necessário resolver algum problema de
incompatibilidade. As funções de dados não devem ser contadas. Estas demandas
devem ser dimensionadas de acordo com a fórmula abaixo.
PF_ATUALIZAÇÃO_VERSÃO_BROWSER = PF_ALTERADO x 0,30
 Atualização de Versão - Banco de Dados
Nesta categoria encontram-se as demandas de atualização de versão do

sistema gerenciador de banco de dados. As funções de dados não devem ser
contadas. Devem ser contadas apenas as funcionalidades impactadas. Estas
demandas devem ser dimensionadas de acordo com a fórmula abaixo.
PF_ ATUALIZAÇÃO_VERSÃO_BD = PF_ALTERADO x 0,30
6.3.7 Manutenção em Interface
A manutenção em Interface, denominada na literatura de manutenção

cosmética, é associada às demandas de alterações de interface, por exemplo: fonte
de letra, cores de telas, logotipos, mudança de botões na tela, mudança de posição
de campos ou texto na tela. Também se enquadram nessa categoria as seguintes
manutenções:
 Mudanças de texto em mensagens de erro, validação, aviso, alerta,

confirmação de cadastro ou conclusão de processamento;
 Mudança em texto estático de e-mail enviado para o usuário em uma

funcionalidade de cadastro. A demanda deve ser contada como manutenção
em interface na funcionalidade de cadastro;
 Alteração de título de um relatório;
 Alteração de labels de uma tela de consulta.
Nestes casos, a aferição do tamanho em pontos de função das funções

transacionais impactadas será realizada com a aplicação de um fator de redução de
modo a considerar 20% da contagem de uma função transacional de mais baixa
140
complexidade (3PF), ou seja, 0,6 PF, independentemente da complexidade da
funcionalidade alterada. Segue a fórmula de cálculo:
PF_INTERFACE = 0,6 PF x QUANTIDADE DE FUNÇÕES TRANSACIONAIS

IMPACTADAS
6.3.8 Adaptação em Funcionalidades sem Alteração de Requisitos Funcionais
São consideradas nesta categoria as demandas de manutenção adaptativa

associadas a solicitações que envolvem aspectos não funcionais, sem alteração em
requisitos funcionais. Seguem alguns exemplos:
 Aumentar a quantidade de linhas por página em um relatório;
 Colocar paginação em um relatório;
 Limitar a quantidade de linhas por página em uma consulta existente;
 Permitir exclusões múltiplas em uma funcionalidade que antes só possibilitava

a exclusão de um item de cada vez;
 Adaptação de uma funcionalidade para possibilitar a chamada por um

webservice ou para outro tipo de integração com outros sistemas;
 Replicação de funcionalidade: chamar uma consulta existente em outra tela

da aplicação;
 Alteração na aplicação para adaptação às alterações realizadas na interface

com rotinas de integração com outros softwares, por exemplo, alteração em
sub-rotinas chamadas por este software;
 Modificar o servidor a ser acessado em uma funcionalidade de download de

arquivo;
 Adequar mensagens do sistema que em algumas telas apresenta "Usuário

Não está Habilitado a ver esta Página", para que passe a enviar uma
mensagem mais adequada ao fato de o usuário não possuir mais uma sessão
ativa e ainda estar navegando no sistema. A demanda deve ser contada
como manutenção adaptativa considerando as funcionalidades impactadas.
141
Observe que se trata de mudança em validação com regra de negócio não
funcional.
A aferição do tamanho em pontos de função da funcionalidade ou das

funcionalidades que sofreram impacto deve considerar um fator de impacto (FI)
sobre o PF_ALTERADO.
PF_ADAPTATIVA = FI x PF_ALTERADO
FI (Fator de Impacto) pode variar conforme condições abaixo:
 FI = 50% para funcionalidade de sistema desenvolvida ou mantida por meio

de um projeto de melhoria pela empresa contratada.
 FI = 75% para funcionalidade de sistema não desenvolvida ou mantida por

meio de um projeto de melhoria pela empresa contratada.
Deve-se destacar que, além da adequação das funcionalidades em questão, a

documentação do projeto de manutenção adaptativa deve ser realizada. Além disso,
caso exista a documentação das funcionalidades impactadas, estas deverão ser
atualizadas, caso contrário, se for demandada a redocumentação dessas
funcionalidades, deve-se adicionar ao FI um fator de redocumentação de 15%,
conforme descrito em Projeto de melhoria.
6.3.9 Apuração Especial - Base de Dados
Este tipo de apuração especial é um projeto que inclui a geração de

procedimentos para atualização da base de dados. Deve-se destacar que estas
funções são executadas apenas uma vez, não fazendo parte da aplicação, visando a
correção de dados incorretos na base de dados da aplicação ou atualização em
função de modificação da estrutura de dados, por exemplo, inclusão de valor "sim"
ou "não" no campo "indicador de matriz" referente ao CNPJ. Normalmente, nesse
tipo de atualização são afetados múltiplos registros. Nestes casos, considera-se a
contagem de pontos de função das funcionalidades desenvolvidas. Geralmente,
estas funcionalidades são classificadas como Entradas Externas.
142
É importante ressaltar que as funções de dados associadas aos dados
atualizados não devem ser contadas, considerando que não há mudanças nas
estruturas dos Arquivos Lógicos Internos.
Segue a fórmula de cálculo.
a) Atualização de Dados sem Consulta Prévia
PF_APURAÇÃO_BD = PF_INCLUÍDO
b) Consulta Prévia sem Atualização
Em alguns casos de Apuração Especial - Base de Dados, o usuário solicita

uma consulta prévia das informações. Deve-se ressaltar que esta consulta deve ser
realizada antes da construção da funcionalidade, não é homologação. Esta consulta
prévia, classificada como Consulta Externa ou Saída Externa, deve ser
dimensionada considerando-se o tamanho da funcionalidade em questão, conforme
a fórmula abaixo:
PF _CONSULTA_PRÉVIA = PF_INCLUÍDO
c) Atualização de Dados com Consulta Prévia
Caso a Apuração Especial - Base de Dados seja solicitada após uma demanda de
consulta prévia, deve-se aplicar um fator de 60% na fórmula de contagem da
Apuração Especial - Base de Dados, seguindo a fórmula abaixo.
PF_APURAÇÃO_BD_PÓS_CONSULTA_PRÉVIA = PF_INCLUÍDO x 0,60
6.3.10 Apuração Especial - Geração de Relatórios
Este tipo de apuração especial é um projeto que inclui a geração de relatórios

em uma ou mais mídias para o usuário. Em alguns casos, são solicitadas extrações
de dados e envio dos dados para outros sistemas. Caso neste envio de dados sejam
requisitadas atualizações no sistema de origem, então estas funções são Saídas
Externas, devido à atualização do Arquivo Lógico Interno.
143
Deve-se destacar que estas funções são executadas apenas uma vez, não
fazendo parte da aplicação. Nestes casos, considera-se contagem de pontos de
função das funcionalidades desenvolvidas. Frequentemente, estas funcionalidades
são classificadas como Saídas Externas. Também podem ser classificadas como
Consultas Externas, caso não possuam cálculos ou criação de dados derivados.
PF_APURAÇÃO_RELATÓRIOS = PF_INCLUÍDO
6.3.11 Apuração Especial - Reexecução
Em alguns casos, a empresa contratante pode ter interesse em executar uma

apuração especial mais de uma vez. Nestes casos, ela deve solicitar formalmente à
contratada o armazenamento do script executado. Desta forma, se for solicitada a
reexecução de uma apuração especial, esta deve ser dimensionada com a aplicação
de um fator redutor de 10% na contagem de pontos de função da apuração especial
em questão, da seguinte maneira:
PF_REEXECUÇÃO_APURAÇÃO = PF_INCLUÍDO x 0,10
6.3.12 Atualização de Dados
Em alguns casos, as demandas de correção de problemas em base de dados

estão associadas a atualizações manuais (de forma interativa) diretamente no banco
de dados em um único registro e que não envolvam cálculos ou procedimentos
complexos.São exemplos desse tipo de demanda a atualização do valor de um
campo de uma tabela cadastrado erroneamente ou a exclusão de um registro de
uma tabela.
Nestes casos, a aferição do tamanho em Pontos de Função deve considerar

10% do PF de uma Entrada Externa e os Tipos de Dados da EE são todos os TD
considerados na funcionalidade - campos atualizados e campos utilizados para a
seleção do registro.
PF_ATUALIZAÇÃO_BD = PF_INCLUÍDO x 0,10

144
6.3.13 Desenvolvimento, Manutenção e Publicação de Páginas Estáticas de
Intranet, Internet ou Portal
A demanda consiste na publicação de páginas Web com conteúdo estático. Por

exemplo: criação de página HTML, atualização de menu estático, atualização de
texto ou banner estáticos em páginas HTML existentes.
Estas demandas são consideradas como desenvolvimento de consultas. Nestes

casos, considera-se 20% dos pontos de função das consultas desenvolvidas. Cada
página é contada como uma consulta. As consultas são consideradas Consultas
Externas de complexidade baixa (3 PF). Ou seja, 0,6 PF por página desenvolvida ou
mantida, de acordo com a fórmula abaixo:
PF_PUBLICAÇÃO = 0,6 PF x Quantidade de Páginas Alteradas ou Incluídas
6.3.14 Manutenção de Documentação de Sistemas Legados
Nesta seção são tratadas demandas de documentação ou atualização de

documentação de sistemas legados. Observe que o desenvolvedor deve realizar
uma engenharia reversa da aplicação para gerar a documentação. Para este tipo de
projeto foi definido o fator de impacto de 25% dos pontos de função da aplicação em
questão, considerando a fase de requisitos e a geração de artefatos associados a
requisitos, conforme a fórmula abaixo.
PF_DOCUMENTAÇÃO = PF_NÃO_AJUSTADO x 0,25
6.3.15 Verificação de Erros
São consideradas verificações de erro ou análise e solução de problemas as

demandas referentes a todo comportamento anormal ou indevido apontado pelo
cliente nos sistemas aplicativos. Neste caso, a equipe de desenvolvimento da
contratada se mobilizará para encontrar as causas do problema ocorrido. Se for
constatado erro de sistema, a demanda será atendida como manutenção corretiva.
145
Entretanto, uma vez não constatado o problema apontado pelo cliente ou o mesmo
for decorrente de regras de negócio implementadas ou utilização incorreta das
funcionalidades, será realizada a aferição do tamanho em pontos de função das
funcionalidades verificadas sobre as quais o cliente reportou erro, sendo
considerado 20% do tamanho funcional das funcionalidades com solicitação de
análise pelo órgão contratante, caso não exista documentação de testes disponíveis
dessas funcionalidades, segundo a fórmula abaixo:
PF_VERIFICAÇÃO = PF_Funcionalidade_Reportada_Com_Erro x 0,20
Caso exista documentação de testes das funcionalidades verificadas, então

será considerado 15% do tamanho funcional das funcionalidades analisadas,
segundo a fórmula abaixo:
PF_VERIFICAÇÃO = PF_Funcionalidade_Reportada_Com_Erro x 0,15
É importante ressaltar que a demanda de verificação de erros deve ser

associada a uma funcionalidade específica. Os casos de sistema fora do ar por
conta de problemas em rede ou banco de dados devem ser tratados como serviços
de suporte e não de serviços de desenvolvimento e manutenção de sistemas. Esses
serviços de suporte não fazem parte do escopo deste roteiro de métricas, não se
aplicando verificação de erros nestes casos.
6.3.16 Pontos de Função de Teste
Muitas vezes, em projetos de manutenção, o conjunto de funções transacionais

a serem testadas é maior do que a quantidade de funções a serem implementadas,
isto é, além das funcionalidades que são afetadas diretamente pelo projeto de
manutenção, outras precisam ser testadas. O tamanho das funções a serem apenas
testadas deve ser aferido em Pontos de Função de Teste (PFT). Não considerar as
funcionalidades incluídas, alteradas ou excluídas do projeto de manutenção na
contagem de Pontos de Função de Teste. A contagem de PFT será o somatório dos
tamanhos em pontos de função das funções transacionais envolvidas no teste:
146
PF_Testes = Somatório dos Tamanhos das Funções Transacionais Testadas x
0,15
6.3.17 Componente Interno Reusável
Em alguns casos são demandadas manutenções em componentes específicos

de uma aplicação e estes são reusados por várias funcionalidades da aplicação. Por
exemplo, suponha uma mudança em uma rotina de validação de um CPF usada em
várias funcionalidades de cadastro. Se considerarmos o método de contagem de
projetos de melhoria do CPM, seriam contadas todas as funcionalidades impactadas
por esta mudança.
O Roteiro de Métricas propõe que o componente interno seja considerado

como um processo elementar independente e contado como uma funcionalidade. A
alteração do componente deve ser contada aplicando-se um fator de impacto (FI)
sobre o PF_ALTERADO. Segue a fórmula de cálculo:
PF_COMPONENTE = FI x PF_ALTERADO
 FI = 50% para componente de sistema desenvolvido ou mantido pela

empresa contratada.
 FI = 75% para componente de sistema não desenvolvido ou mantido pela

empresa contratada e sem necessidade de redocumentação.
 FI = 90% para componente de sistema não desenvolvida ou mantida pela

empresa contratada e com necessidade de redocumentação.
Além disso, as funcionalidades da aplicação que necessitem de teste devem ser

requisitadas pela contratante e dimensionadas por meio da métrica Pontos de
Função de Teste:
147
Segue um exemplo de manutenção de componentes:
 Mudança em tópico de um menu de um sistema em PHP que aparece em

todas as telas da aplicação. A contagem pode ser realizada considerando o
componente "Apresentar Menu".
Além disso, existem casos onde são realizadas manutenções de valores de

elementos internos de configuração que afetam o comportamento ou a apresentação
do sistema de forma geral, tais como páginas de estilos (arquivos CSS de sistemas
Web), arquivos com mensagens de erro, arquivos de configuração de sistema e
arquivos de internacionalização. Nestes casos, a aferição do tamanho em pontos de
função será realizada com a aplicação de um fator de redução de modo a considerar
20% da contagem de uma função transacional de mais baixa complexidade (3 PF),
ou seja 0,6 PF. Assim sendo, deve ser utilizada a seguinte fórmula de cálculo:
PF_COMPONENTE_ARQUIVO = 0,6 PF x Quantidade de Arquivos Alterados
6.3.18 Contagem de Pontos de Função de Mudança de Requisitos
Em projetos de desenvolvimento e de manutenção de software é bastante

observada a mudança de requisitos anterior à implantação do projeto. O Manual de
Práticas de Contagem (CPM) denomina este fenômeno de Scope Creep.
Uma mudança de requisito anterior à implantação do projeto gera retrabalho para a

equipe de desenvolvimento, aumentando assim o esforço e o custo do projeto.
Recomenda-se que as demandas de mudança de requisitos sejam dimensionadas
como PF_RETRABALHO.
PF_Retrabalho = PF_Alterado x Fator Impacto Retrabalho x Fator Impacto Fases

Concluídas
O método de contagem de mudança de requisitos (PF_Retrabalho) considera o

seguinte:
 As demandas de mudança de requisitos são contagens à parte da contagem

do projeto de desenvolvimento;
148
 A contagem do PF_RETRABALHO leva em conta o esforço já realizado no
processo de desenvolvimento da funcionalidade até o momento da solicitação
de mudança de requisitos;
 A contagem do PF Alterado deve considerar os requisitos originais, ou seja,

as funcionalidades antes da mudança;
 O Fator de Impacto Retrabalho deve ser tratado de acordo com o requisito

original e o tipo de mudança, conforme ilustrado na tabela abaixo. Cabe
ressaltar que estes fatores podem ser customizados pela organização.
Requisito Original
Fator Incluir Alterar Excluir
Função Função Função
Acréscimo - - -
Alteração de
75% 75% -
Tipo da Mudança Requisitos
Alteração
de Requisito Alteração de
0,6 PF 0,6 PF -
Interface
Desistência 130% 105% 30%
 O Fator de Impacto Fases Concluídas é associado ao percentual das atividades

concluídas das fases do processo de desenvolvimento até o momento da
mudança de requisitos. A tabela abaixo ilustra as fases típicas de um processo
de software.
Macroatividades do Processo de Desenvolvimento de Software Percentual de esforço (%)

Engenharia de Requisitos 25
Design / Arquitetura 10
Implementação 40
Testes 15
Homologação 5
Implantação 5
149
Para fins de planejamento ou de faturamento, a quantidade total de pontos de
função será obtida da seguinte forma:
PF_TOTAL = PF_PROJETO + Σ PF_RETRABALHO
Onde: PF_PROJETO é a última versão da contagem do escopo do projeto

(PF_DESENVOLVIMENTO, PF_MELHORIA, PF_ADAPTATIVA, etc).
Exemplo: Projeto de Melhoria para Criação da Funcionalidade - Relatório de

Alunos Aprovados.
SE: Relatório de Alunos Aprovados

AR: 2 (Alunos, Curso)
TDs: 7 (Nome do Curso, Nome do Aluno, Matricula do Aluno, Média Final, Total
alunos aprovados, mensagem, ação)
Média - 5 PF
Na fase de homologação, foi solicitada a inclusão da informação de nome do

Instrutor. Esta informação é obtida na Tabela de Cursos.
Desta forma, o PF_Retrabalho deve ser aferido da seguinte forma:
PF_Retrabalho = PF_Alterado x Fator Impacto Retrabalho x Fator Impacto Fases

Concluídas
Onde:
PF_Alterado: requisito original a ser alterado.
SE: Relatório de Alunos
AR: 2 TD:7 - M - 5 PF
Fator Impacto Retrabalho: Alteração - 75%
Fator Impacto Fases Concluídas: Considerar todas as fases até a fase em que
ocorreu a mudança - Homologação - 90%
PF_Retrabalho = 5 x 0,75 x 0,90 = 3,375 PFs
PF_Projeto_ Melhoria = PF_Incluído

150
Onde:
PF_Incluído:
SE: Relatório de Alunos Aprovados
AR: 2 (Alunos, Curso)
TDs: 8 (Nome do Curso, Nome do Aluno, Matricula do Aluno, Média Final, Total
alunos aprovados, nome do Instrutor, mensagem, ação)
Média - 5 PF
PF_Projeto_ Melhoria = 5 PF
O cálculo de PF total da demanda é o seguinte:
PF_TOTAL = PF_PROJETO + Σ PF_RETRABALHO
PF_TOTAL = 5 + 3,375 = 8,375 PFs
151

Apostila Curso APF Basico EaD Jul 2018

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apostila Curso APF Basico EaD Jul 2018

Transféré par

Droits d'auteur :

Formats disponibles

Curso Básico de

Análise de Pontos de Função

Autora: Claudia Hazan

 Compreender os conceitos básicos de métricas de software;

 Perceber a importância da utilização das métricas para uma gestão efetiva de

 Entender os principais objetivos de um Processo de Medição de Software.

1.1. DEFINIÇÃO DE MÉTRICAS DE S OFTWARE

Algumas propriedades importantes de projetos de software a serem medidas são:

Podemos medir o tamanho de um projeto de software com base em algumas

Cada organização necessita definir, categorizar e quantificar os defeitos de seu

Uma métrica de esforço bastante utilizada é a de horas. A medição do esforço pode

É essencial estimar e registrar o tempo requerido para completar uma fase no

O orçamento de uma organização é um recurso importante. Desta forma, os custos

Neste curso o foco são as métricas de tamanho de projetos de software,

Pontos de Função (PF) é uma métrica padrão para dimensionar o tamanho

A métrica PF quantifica o tamanho de um projeto de software com base na análise

Desde a década de 90, Pontos de Função é a métrica de tamanho de projetos de

1.2. POR QUE MEDIR

 Formar uma baseline para estimativas

Uma baseline é um banco de dados históricos de medições de projetos de software

 Determinar se as metas de produtividade do processo estão sendo atingidas

É fundamental o estabelecimento de metas objetivas sobre produtividade, como, por

 Determinar se as metas de qualidade do processo estão sendo atingidas

A qualidade do processo precisa ser mensurada e avaliada de forma objetiva, por

 Determinar se as metas de qualidade do produto estão sendo atingidas

Em editais de licitação para contratação de fábrica de software, é fundamental o

 Avaliar os benefícios de novos métodos, treinamentos e ferramentas

As organizações ou departamentos de TI das organizações buscam investir em

 Melhorar o relacionamento com o cliente

As medições tornam possível as estimativas de prazo e custo de projetos de

A Instrução Normativa IN04 recomenda o uso de métricas objetivas em contratos de

 Melhorar a gerência de projetos de desenvolvimento e de manutenção de

O uso de métricas possibilita um planejamento efetivo de custos e cronograma e

 Entender e aperfeiçoar o processo de software

As medições são fundamentais para a implantação da melhoria contínua de

1.3. PROCESSO DE MEDIÇÕES E MELHORIA CONTÍNUA DO PROCESSO DE SOFTWARE

As decisões normalmente resultam em ações que ao serem implementadas, por

1.4. OBJETIVO DE UM PROCESSO DE MEDIÇÕES

Medições ajudam a identificar, priorizar, acompanhar e comunicar os objetivos e

 Acompanhar objetivos de projetos específicos

Medições indicam o status dos processos e produtos do projeto de software,

Medições apoiam a estratégia de gerência pró-ativa. Problemas potenciais são

 Tomar decisões chaves

Os projetos de software estão sujeitos a restrições tais como: custo, prazo e

Os gerentes e líderes de projetos devem ser capazes de demonstrar a base de suas

 Apresentar uma visão geral da técnica Análise de Pontos de Função;

 Discutir os objetivos, benefícios e limitações do uso da métrica Pontos de Função

 Apresentar o procedimento de contagem de Pontos de Função.

 Definir a Visão do Usuário

2.1. DEFINIÇÕES E HISTÓRICO DA ANÁLISE DE PONTOS DE FUNÇÃO

Vejamos algumas definições para Análise de Pontos de Função (APF):

 A Análise de Pontos de Função é um método padrão para medir software em

 Pontos de Função (PF) é uma Métrica de Tamanho Funcional reconhecida pelo

 Pontos de Função (PF) é uma métrica baseada na quantificação dos requisitos

 Pontos de Função (PF) dimensiona um projeto de software ou aplicação

Segue um histórico da Análise de Pontos de Função:

 Década de 60 – Linhas de Código

Na década de 60, a métrica de tamanho mais utilizada na indústria de software era a

 Década de 70 - Criação da métrica Pontos de Função

Com o propósito de solucionar os problemas associados à métrica Linhas de

Allan Albrecht trabalhou no desenvolvimento de uma métrica objetiva, de fácil

 Década de 80 - Criação do IFPUG

Com o propósito de promover a utilização da métrica Pontos de Função, evoluir o

Navegue no sítio do IFPUG http://www.ifpug.org.