Guia de Contagem de Pontos de Função do MP

Guia de Contagem de Pontos de Funo do MP
Histrico de Reviso
Data
Verso
Descrio
04/2015
1.0
Elaborao do manual.
Autor
Mrcia Regina Guiotti Bomfim
Jos Romildo Andrade
Pgina 2 de 45
Sumrio
SUMRIO ..................................................................................................................................................... 3
1.
OBJETIVO ....................................................................................................................................... 5
2.
REFERNCIAS PRINCIPAIS ............................................................................................................... 5

2.1.
2.2.
COUNTING PRACTICES MANUAL DO IFPUG (CPM) ............................................................................... 5

ROTEIRO DE MTRICAS DE SOFTWARE DO SISP (ROTEIRO SISP)............................................................... 5
3.
INTRODUO ................................................................................................................................. 5
4.
ENTENDIMENTO DA TCNICA ......................................................................................................... 6

4.2. PROPSITO DA CONTAGEM ................................................................................................................ 6
4.3. TIPO DE CONTAGEM .......................................................................................................................... 7
4.4. ESCOPO DA APLICAO ...................................................................................................................... 7
4.5. VISO DO USURIO ........................................................................................................................... 7
4.6. FRONTEIRA DA APLICAO .................................................................................................................. 8
4.7. FUNES DE DADOS .......................................................................................................................... 9
4.7.1.
ARQUIVO LGICO INTERNO (ALI) .................................................................................................. 10
4.7.2.
ARQUIVO DE INTERFACE EXTERNA (AIE) ......................................................................................... 10
4.7.3.
REGISTRO LGICO REFERENCIADO (RLR OU TR) .............................................................................. 10
4.8. FUNES TRANSACIONAIS ................................................................................................................ 10
4.8.1.
ENTRADA EXTERNA (EE) .............................................................................................................. 10
4.8.2.
CONSULTA EXTERNA (CE)............................................................................................................. 10
4.8.3.
SADA EXTERNA (SE) ................................................................................................................... 10
4.9. NVEL DE DETALHAMENTO DE CONTAGENS .......................................................................................... 11
4.9.1.
CONTAGEM INDICATIVA ............................................................................................................... 11
4.9.2.
CONTAGEM ESTIMADA................................................................................................................. 12
4.9.3.
CONTAGEM DETALHADA .............................................................................................................. 12
4.10.
FATOR DE AJUSTE........................................................................................................................ 13
4.11.
ORIENTAES PARA AS CONTAGENS ............................................................................................... 13
4.11.1. DADO DE CDIGO ....................................................................................................................... 13
4.11.2. LOG, TRILHA DE AUDITORIA, REGISTRO DE EVENTOS E HISTRICO ....................................................... 14
4.11.2.1. HISTRICO ............................................................................................................................. 14
4.11.2.2. REGISTRO DE EVENTOS ............................................................................................................. 14
4.11.2.3. LOG ...................................................................................................................................... 15
4.11.2.4. TRILHA DE AUDITORIA .............................................................................................................. 15
4.11.3. CONSULTAS COM FILTROS DIFERENTES E COM AS MESMAS SADAS ....................................................... 15
4.11.4. CONSULTAS COM FILTROS IGUAIS E COM SADAS DIFERENTES .............................................................. 16
4.11.5. INTEGRAO ENTRE APLICAES .................................................................................................... 16
4.11.5.1. CENRIO 1 (SISTEMA A REQUISITA DADOS DO SISTEMA B) ....................................................... 16
4.11.5.2. CENRIO 2 (SISTEMA B FORNECE DADOS PARA O SISTEMA A ) ................................................. 17
4.11.5.3. CENRIO 3 (DISPONIBILIZAO E CONSUMO DE DADOS DENTRO DA MESMA FRONTEIRA) .................... 18
4.11.5.4. IDENTIFICAO DO BARRAMENTO COMO UMA FRONTEIRA ............................................................. 18
4.11.5.5. CONFIGURAO/CUSTOMIZAO DE FERRAMENTA DE BARRAMENTO .............................................. 19
4.11.6. MANUTENO DE COMPONENTE REUTILIZVEL ............................................................................... 19
4.11.7. MLTIPLAS MDIAS ..................................................................................................................... 20
4.11.8. MLTIPLOS PROCESSOS COMPONDO UM PROCESSO ELEMENTAR (SUBDIVISO DE FUNCIONALIDADES) ...... 22
4.11.9. CONSULTAS IMPLCITAS ................................................................................................................ 23
Pgina 3 de 45
4.11.10.
4.11.11.
4.11.12.
4.11.13.
4.11.13.1.
CONTAGEM DE FUNES PARA CONVERSO DE DADOS ................................................................. 23

PROJETOS DE MIGRAO DE DADOS .......................................................................................... 24
PROJETOS DE MELHORIA (MANUTENO EVOLUTIVA) .................................................................. 24
MUDANA ESTRUTURAL EM ARQUIVOS LGICOS PARA PROJETOS DE MELHORIA ............................... 25
IMPACTO DAS ALTERAES DAS CARACTERSTICAS DE ITENS DE DADOS DE UM ALI NAS FUNES
TRANSACIONAIS QUE O MANTM. .................................................................................................................. 25
4.12.
ITENS NO MENSURVEIS ............................................................................................................. 26
4.12.1. MANUTENO CORRETIVA ........................................................................................................... 26
4.12.1.1. SISTEMA SEM DOCUMENTAO, DESATUALIZADA OU INCOMPLETA .................................................. 27
4.12.1.2. SISTEMA COM DOCUMENTAO COMPLETA E ATUALIZADA ............................................................. 27
4.12.2. MANUTENO DE INTERFACE ........................................................................................................ 28
4.12.3. MANUTENO EM DADOS DE CDIGO ........................................................................................... 28
4.12.4. ATUALIZAO DE DADOS DE CDIGO ............................................................................................. 29
4.12.5. MENSAGENS .............................................................................................................................. 29
4.12.6. PROGRAMAS AUXILIARES ............................................................................................................. 30
4.13.
MUDANA DE REQUISITOS DURANTE O PROJETO DE DESENVOLVIMENTO OU MANUTENO ..................... 31
4.13.1. MUDANAS ASSOCIADAS AO DOMNIO DO NEGCIO ......................................................................... 32
4.13.2. DESISTNCIA DE INCLUIR, ALTERAR OU EXCLUIR UMA FUNO ............................................................. 35
4.14.
CONTAGEM DE PONTOS DE FUNO NO DESENVOLVIMENTO DE SOFTWARE COM MTODOS GEIS. ........... 35
5.
DICAS PARA OTIMIZAR O CUSTO DAS MANUTENES................................................................. 42
6.
ENTREGA DA CONTAGEM ............................................................................................................. 43
7.
GLOSSRIO................................................................................................................................... 43
8.
PROCESSO DE REVISO DO GUIA DE CONTAGEM ......................................................................... 44

8.1.
8.2.
9.
REVISO PARA CORREO DE INCONSISTNCIAS E SITUAES NO PREVISTAS .......................................... 44

REVISO PARA ADOO DE NOVAS VERSES DO CPM ......................................................................... 44
REFERNCIAS BIBLIOGRFICAS..................................................................................................... 44
Pgina 4 de 45
1. Objetivo
Este documento tem como propsito apresentar o Guia de Contagem de
Pontos de Funo proposto pelo Ministrio do Planejamento, Oramento e
Gesto (MP) para a aplicao no contexto de desenvolvimento e manuteno
de softwares do MP. Este guia funciona como um complemento ao Manual de
Prticas de Contagem do IFPUG (International Function Point Users GrouPwww.ifpu.com), procurando tornar mais prtico o uso dos conceitos e regras
definidos pelo IFPUG, exemplificando situaes especficas do MP e
apresentando situaes em que o IFPUG no oferece orientao prtica ou
objetiva.
2. Referncias Principais
2.1.
Counting Practices Manual do IFPUG (CPM)
O Manual de Prticas de Contagem do IFPUG, que estabelece o padro

para a contagem de pontos de funo, especifica um conjunto de definies,
regras e passos para a aplicao do mtodo de medio funcional do IFPUG.
O MP adotar como referncia a verso 4.3.1, podendo adotar no futuro novas
verses conforme descrito no tpico Processo de Reviso para Adoo de
Novas Verses do CPM.
2.2.
Roteiro de Mtricas de Software do SISP (Roteiro SISP)
O Roteiro de Mtricas de Software do SISP (Roteiro SISP) tem o objetivo de

apresentar mtricas, com base nas regras de contagens de pontos de funo
do CPM, para vrios tipos de projetos de desenvolvimento e manuteno de
software, promovendo o uso de mtricas objetivas em contratos de prestao
de servios de desenvolvimento e manuteno de sistemas.
O Roteiro SISP (verso mais atual) deve ser aplicado de forma
complementar a este guia de contagem. Ocorrendo ambiguidade entre as
informaes descritas neste guia e no Roteiro SISP, devem prevalecer as
regras estipuladas neste guia.
No caso de publicao de nova verso do Roteiro SISP, as contratadas
tero o prazo estipulado pelo MP, porm nunca inferior a 30 dias corridos para
adequarem-se nova verso.
3. Introduo
A Anlise de Pontos de Funo uma tcnica de medio das
funcionalidades de um software sob o ponto de vista do usurio, ou seja,
determina o tamanho funcional do software. Segundo o CPM, a tcnica mede o
software quantificando as tarefas e servios (isto , funcionalidade) que o
software fornece ao usurio, primordialmente com base no projeto lgico.
Os objetivos da anlise de pontos de funo so:
Medir a funcionalidade implementada no software, que o usurio solicita
e recebe e;
Pgina 5 de 45
Medir a funcionalidade impactada pelo desenvolvimento, melhoria e

manuteno de software, independentemente da tecnologia utilizada na
implementao.
O Ponto de Funo (PF) a unidade de medida que tem por objetivo tornar
a medio independente da tecnologia utilizada para a construo do software.
Essa medida est diretamente relacionada aos requisitos de negcio que o
software se destina a abordar, ou seja, busca medir o que o software faz e no
como ele foi construdo. Portanto, pode ser facilmente aplicada em uma ampla
gama de ambientes de desenvolvimento e ao longo do ciclo de um projeto de
desenvolvimento, desde a definio de requisitos at o uso operacional
completo. A tcnica fornece uma medida objetiva e comparativa que auxilia na
avaliao, planejamento, gesto e controle da produo de software.
4. Entendimento da Tcnica
A figura abaixo ilustra o procedimento de contagem de pontos de funo.
4.1.
Obter documentao disponvel do projeto
A contagem de pontos de funo se inicia com a anlise da

documentao disponvel do projeto em questo, visando identificao dos
requisitos funcionais.
4.2.
Propsito da Contagem
Uma contagem deve prover uma resposta a um problema do negcio e

o problema do negcio que determina o propsito. O objetivo, nesta etapa,
tornar claro o que se pretende atingir com a contagem que ser feita.
Exemplos de propsito so:
Pgina 6 de 45
Fornecer o tamanho funcional de um projeto como uma entrada para

o processo de estimativa a fim de determinar o esforo para desenvolver a
primeira verso de uma aplicao;
Fornecer o tamanho funcional da base instalada das aplicaes para
determinar os custos de sustentao por ponto de funo;
Fornecer o tamanho funcional de dois pacotes para permitir a
comparao de funcionalidade oferecida por cada um.
4.3.
Tipo de Contagem
O tipo de contagem estabelecido pelo responsvel da contagem,

podendo estar associada tanto a projetos quanto a aplicaes. O tipo
determinado pelo propsito da contagem.
Segundo o CPM, h trs tipos de contagem de pontos de funo, a
saber:
o Projeto de Desenvolvimento: Este tipo de contagem mede a
funcionalidade entregue ao usurio na primeira instalao do
software, quando o projeto estiver completo.
o Projeto de Melhoria (Enhancement): Este tipo de contagem mede
as modificaes em uma aplicao j existente que adicione, altere
ou exclua funes entregues ao usurio quando o projeto estiver
completo.
o Aplicao: Este tipo de contagem est relacionado aplicao
instalada. Representa a baseline da contagem de pontos de funo
de uma aplicao, ou seja, uma medida das funes atuais
providas ao usurio.
4.4.
Escopo da aplicao
Segundo o CPM, o escopo da contagem define o conjunto de requisitos

funcionais de usurios para ser includos na contagem. O escopo:
Define o (sub)conjunto do software que est sendo medido;
determinado pelo propsito para a realizao da contagem de
pontos de funo;
Identifica quais funes sero includas na medida de tamanho
funcional assim como fornecer respostas relevantes para o
propsito da contagem;
Pode incluir mais de uma aplicao.
4.5.
Viso do Usurio
Segundo o CPM, um usurio qualquer pessoa ou coisa que se

comunica ou interage com o software a qualquer momento.
A viso do usurio o Requisito Funcional do Usurio como percebido
pelo usurio.
Pgina 7 de 45
Requisitos Funcionais do Usurio so um subconjunto dos requisitos do

usurio que descrevem o que o software dever fazer em termos de tarefas e
servios.
A viso do usurio representa uma descrio formal das necessidades
dos negcios do usurio, na linguagem do usurio. Os desenvolvedores
traduzem a informao do usurio para informaes em linguagem tcnica a
fim de prover uma soluo.
No contexto da anlise de pontos de funo, o termo usurio tem um
conceito mais amplo do que o usual. Com isso, durante uma contagem de
pontos de funo, convm buscar dentro de um conjunto de usurios possveis
aquele cuja viso represente melhor as funes que a aplicao fornece. Por
exemplo, uma aplicao de autoatendimento de um banco tem como usurios
o cliente do banco, o funcionrio da agncia, o gestor do departamento
responsvel. Basear a contagem dessa aplicao somente na viso do cliente
final do banco e usurio do autoatendimento seria considerar uma viso
limitada da aplicao. fundamental levar em considerao tambm a viso do
usurio que especifica os requisitos e regras de negcio, neste caso, o gestor
do departamento.
4.6.
Fronteira da aplicao
De acordo com o CPM, a fronteira uma interface conceitual entre o

software sob estudo e seus usurios.
A fronteira da aplicao:
Define o que externo aplicao;
Indica a fronteira entre o software que est sendo medido e o
usurio;
Atua como uma membrana atravs da qual os dados
processados pelas transaes (EEs, SEs e CEs) passam para
dentro e para fora da aplicao
Envolve os dados lgicos mantidos pela aplicao (ALIs);
Auxilia na identificao dos dados lgicos referenciados, mas no
mantidos pela aplicao (AIEs);
Depende da viso externa do negcio do usurio da aplicao,
independente de questes tcnicas e/ou implementao.
Assim, a fronteira deve ser definida com base na perspectiva de
negcio, nas reas funcionais separadas como pode ser visto pelo usurio, no
em consideraes tcnicas (por exemplo, arquitetura do sistema).
A fronteira inicial j estabelecida para a aplicao ou aplicaes que
estejam sendo modificadas no influenciada pelo escopo da contagem.
Uma das dicas que o CPM descreve para a identificao da fronteira
obter uma documentao do fluxo de dados no sistema e traar uma linha
imaginria ao redor para destacar quais partes so internas e externas
Pgina 8 de 45
aplicao. Um artefato que bem representa esse fluxo o diagrama de

contexto, pois representa todo o sistema como um nico processo e
composto por fluxos de dados que mostram as interfaces entre o sistema e as
entidades externas, permitindo, com isso, identificar os limites dos processos,
as reas envolvidas com o processo e os relacionamentos com outros
processos e elementos externos empresa (ex.: clientes, fornecedores).
Quando houver mais de uma aplicao includa no escopo da contagem.
Nesse caso, mltiplas fronteiras da aplicao devero ser identificadas.
Para o MP, perfis de usurio que vo utilizar o sistema, distribuio das
equipes de desenvolvimento e definies arquiteturais e/ou tecnolgicas no
so insumos para a definio da fronteira.
Quanto ao uso do documento de viso, o objetivo principal dele
fornecer uma viso completa, em alto nvel, do sistema de software em
desenvolvimento. Devido ao fato de este documento poder contemplar
requisitos funcionais e no funcionais, ainda que nele constem descritas as
necessidades requisitadas e entregues ao usurio, a APF se prope a medir
apenas os requisitos funcionais (ou de negcio).
Com base nisso, o MP entende e define que esse documento pode no
ser um insumo suficiente para a definio da fronteira, devendo existir uma
avaliao mais abrangente sob a perspectiva de negcio, conforme definido
neste tpico.
Diante de algum impasse na definio da fronteira, deve prevalecer a
viso de negcio do usurio de acordo com o entendimento do MP, uma vez
que cabe ao cliente ser o detentor do conhecimento do negcio e, como a
fronteira impacta diretamente no resultado da contagem e consequentemente
em custos, podem ser gerados conflitos de interesses.
Como o conceito de fronteira muito importante, o MP reconhece que
deve ser estabelecido um inventrio das aplicaes juntamente com a definio
de suas fronteiras para que nas diversas medies tenha-se como base a
mesma viso das fronteiras. Enquanto esse trabalho no estiver concludo, as
definies da fronteira das aplicaes sero definidas pontualmente.
Em projetos de melhoria, a fronteira estabelecida no incio do projeto
deve estar de acordo com a fronteira j estabelecida para a aplicao que est
sendo modificada.
4.7.
Funes de Dados
As funes de dados representam a funcionalidade oferecida ao usurio

para satisfazer requisitos de armazenamento de dados internos e externos.
Uma funo de dado pode ser um arquivo lgico interno ou um arquivo de
interface externo.
O termo arquivo aqui no significa arquivo fsico ou tabela. Nesse caso,
arquivo se refere a um grupo de dados logicamente relacionados e no
implementao fsica destes grupos de dados.
Pgina 9 de 45
4.7.1. Arquivo Lgico Interno (ALI)

Grupo de dados ou informaes de controle logicamente relacionados,
identificvel pelo usurio, mantido dentro da fronteira da aplicao. A inteno
primria de um ALI armazenar dados mantidos atravs de um ou mais
processos elementares da aplicao sendo contada.
4.7.2. Arquivo de Interface Externa (AIE)
Grupo de dados logicamente relacionados ou informao de controle,
reconhecido pelo usurio, referenciado pela aplicao sendo medida, mas que
mantido dentro da fronteira de outra aplicao. A inteno primria de um AIE
armazenar dados referenciados por um ou mais processos elementares
dentro da fronteira da aplicao medida. Isto significa que um AIE contado por
uma aplicao deve ser um ALI em outra aplicao. Devero ser considerados
na complexidade de um AIE apenas os itens de dados e os registros lgicos
referenciados pela aplicao que est sendo contada.
4.7.3. Registro Lgico Referenciado (RLR ou TR)
Um tipo de registro lgico referenciado um subgrupo de dados
reconhecido pelo usurio dentro de uma funo de dados (ALI ou AIE). Para a
contagem dos RLRs de uma funo de dados, devem ser aplicadas as regras
estabelecidas no CPM.
4.8.
Funes Transacionais
Uma funo de transao um processo elementar que oferece

funcionalidade ao usurio para processar dados. Uma funo de transao
uma entrada externa, sada externa, ou consulta externa.
4.8.1. Entrada Externa (EE)
Processo elementar que processa dado (ou informaes de controle)
vindo de fora da fronteira da aplicao. A principal inteno de uma EE
manter um ou mais ALI e/ou alterar o comportamento do sistema.
4.8.2. Consulta Externa (CE)
Processo elementar que envia dados ou informaes de controle para
fora da fronteira da aplicao. A principal inteno de uma CE apresentar
informao ao usurio por meio de uma simples recuperao de dados ou
informaes de controle de um ALI ou AIE. A lgica de processamento no
deve conter frmula matemtica ou clculo, criar dados derivados, manter um
ou mais ALI e/ou alterar o comportamento do sistema.
4.8.3. Sada Externa (SE)
Processo elementar que gera dados ou informaes de controle que
saem pela fronteira da aplicao. A principal inteno de uma SE apresentar
Pgina 10 de 45
dados ao usurio atravs de outra lgica de processamento que no apenas a

recuperao de dados ou informaes de controle. A lgica de processamento
deve conter frmula matemtica ou clculo, criar dados derivados, manter um
ou mais ALI e/ou alterar o comportamento do sistema.
4.9.
Nvel de Detalhamento de Contagens
A contagem de pontos de funo pode ser realizada com diferentes

nveis de detalhe: indicativa, estimada e detalhada. O nvel de detalhamento a
ser escolhido depende de alguns fatores como a finalidade da contagem, as
informaes disponveis para subsidiar a contagem, a etapa do ciclo de vida do
desenvolvimento, dentre outros.
A contagem indicativa e estimada dar-se- conforme definies da
Netherlands Software Metrics Association NESMA.
A orientao que a contagem estimada seja utilizada para embasar a
formalizao (abertura) da Ordem de Servio nos projetos de desenvolvimento
e manuteno e para embasar a autorizao para execuo da mudana nos
projetos de manuteno. Cabe ressaltar que, eventualmente, pode ser
necessrio o uso da contagem indicativa para a mesma finalidade quando
houver pouco conhecimento do sistema que se precisa estimar.
Quanto contagem detalhada, a orientao que seja utilizada aps a
homologao e o aceite dos produtos gerados na Ordem de Servio de
desenvolvimento e manuteno para embasar o processo de pagamento.
Entretanto, em caso de projetos grandes de longa durao, pode-se identificar
a necessidade de realizar contagem detalhada de referncia, com base nos
requisitos detalhados, para gerar o equilbrio financeiro do projeto.
importante destacar que, quanto mais exata se quer uma contagem de
pontos de funo, mais detalhados devem ser os requisitos do usurio. Dessa
forma, as contagens estimadas e indicativas, por no se tratarem de uma
medio exata, podem apresentar desvios do tamanho obtido com a contagem
detalhada. Um cuidado maior deve-se ter com o uso da contagem indicativa,
pois os desvios podem chegar a at 50% na comparao de uma contagem
indicativa e uma detalhada para o mesmo sistema, conforme demonstra o
resultado
de
um
projeto
de
pesquisa
pela
NESMA
(http://fattocs.com/pt/contagem-antecipada).
4.9.1. Contagem Indicativa
A contagem indicativa utilizada para estimar de forma rpida o
tamanho de projetos de desenvolvimento de novas aplicaes. Devido ao
pouco conhecimento do sistema que se precisa estimar, ela baseada
somente na identificao de quantos arquivos lgicos (ALIs e AIEs) existiro na
aplicao. A contagem indicativa realizada da seguinte forma:
determina-se a quantidade das funes do tipo dado (ALIs e AIEs);

Pgina 11 de 45
calcula-se o total de pontos de funo no ajustados da aplicao da

seguinte forma:
tamanho indicativo (pf) = 35 x nmero de ALIs + 15 x nmero de AIEs

importante explicar que a contagem indicativa baseada na premissa
de que existem aproximadamente trs EEs (para adicionar, alterar, e excluir
dados do ALI), duas SEs, e uma CE na mdia para cada ALI, e
aproximadamente uma SE e uma CE para cada AIE.
Dessa forma, obtm-se uma estimativa gil do tamanho do sistema,
porm no muito precisa.
4.9.2. Contagem Estimada
A contagem estimada utilizada quando possvel identificar as
funes do sistema, porm no se define a complexidade (tipos de dados, tipos
de registros e arquivos referenciados).
Dessa forma, assume-se uma complexidade padro para as funes,
sendo as funes de dados (ALIs e AIEs) classificadas como de baixa
complexidade, enquanto as funes transacionais (EEs, CEs e SEs) so
classificadas como de mdia complexidade.
A contagem estimada realizada da seguinte forma:
determina-se todas as funes de todos os tipos (ALI, AIE, EE, SE,
CE);
toda funo do tipo dado (ALI, AIE) tem sua complexidade funcional
avaliada como Baixa;
toda funo transacional (EE, SE, CE) avaliada como de
complexidade mdia;
calcula-se o total de pontos de funo no ajustados.
4.9.3. Contagem Detalhada
A contagem detalhada dar-se- pela aplicao da tcnica de contagem
seguindo as regras estabelecidas no Manual de Prticas de Contagem (CPM)
verso 4.3.1 (ou superior) do IFPUG, acrescidas das definies deste Guia de
Contagem do MP (verso mais atual) e do Roteiro de Mtricas de Software do
SISP na verso 2.0 (ou superior).
A contagem detalhada a contagem usual de pontos de funo e
realizada da seguinte forma:
determina-se todas as funes de todos os tipos (ALI, AIE, EE,
determina-se a complexidade de cada funo (Baixa, Mdia, Alta);

calcula-se o total de pontos de funo no ajustados.
SE, CE);
Pgina 12 de 45
4.10. Fator de Ajuste

O Ministrio do Planejamento no utiliza a avaliao do valor do fator de
ajuste (VAF) em suas medies, sendo este fixado no valor 1,00. Isso significa
que as caractersticas gerais do sistema, apresentadas no manual de prticas
de contagem do IFPUG, no afetam o tamanho dos Pontos de Funo obtidos
em suas contagens.
Assim sendo, toda contagem dever resultar em pontos por funo
brutos PFB ou no ajustados.
4.11. Orientaes para as contagens
4.11.1.
Dado de Cdigo
Segundo o CPM, os dados de cdigo, s vezes chamados de dados de

lista ou dados de traduo, fornecem uma lista de valores vlidos que um
atributo descritivo pode ter. Normalmente os atributos de dados de cdigo so
cdigo, descrio e/ou outros atributos padro descrevendo o cdigo; por
exemplo, abreviao padro, data de incio de vigncia, data de expirao,
dados de trilha de auditoria, etc. Ao utilizar cdigos em dados de negcio,
necessrio ter meios de traduo para converter de cdigo para algo mais
reconhecvel pelo usurio. Exemplos so valores vlidos, descries de
cdigos ou tabelas de traduo.
Alguns dados de cdigo so desenvolvidos para atender requisitos
especficos do usurio e contm dados que esto dentro do domnio do
usurio. Outros dados de cdigo podem ser derivados a partir dos requisitos do
usurio para restringir os valores permitidos e tambm podem ser criados em
uma tentativa de reduzir requisitos de espao em disco. Os requisitos podem
tambm incluir a habilidade de manter dados de cdigo, mas todos esses so
requisitos no-funcionais do usurio.
Portanto, mesmo que os requisitos do usurio incluam a habilidade de
manter dados de cdigo, isso no os transforma em requisitos funcionais, pois
sua natureza no funcional, conforme definio no CPM, os dados de cdigo
so uma implementao de requisitos no-funcionais do usurio. Dado de
cdigo implementao de requisitos tcnicos e no influencia o seu tamanho
funcional.
Para o MP, o desenvolvimento de funcionalidades consideradas dados
de cdigo, durante o projeto de desenvolvimento de software, no ser
considerado na contagem. Entretanto, devido a questes de contrataes, para
projetos de manuteno evolutiva, que implique manuteno nas
funcionalidades consideradas dados de cdigo, deve-se aplicar a orientao
descrita no tpico Itens no Mensurveis -Manuteno em Dados de Cdigo.
Na contagem de transaes que implementam requisitos funcionais e
que acessam tambm dados de cdigo, s devem ser considerados como
Pgina 13 de 45
arquivos referenciados os ALIs e AIEs que implementam dados de negcio ou

dados de referncia e nunca dados de cdigo.
4.11.2.
Log, Trilha de Auditoria, Registro de Eventos e Histrico
O objetivo deste tpico descrever o tratamento que o MP dar a respeito

de Log, Trilha de Auditoria, Registro de Eventos e Histrico.
4.11.2.1.
Histrico
Para o MP, o histrico um registro de informaes passadas em

determinado momento, o que possibilita ao usurio consultar a evoluo da
informao na linha do tempo. Essas informaes tornam-se necessrias para
a prestao de contas (a rgos externos, superiores ou processos internos)
ou por exigncia do prprio cenrio de negcio. Sua existncia justificada
pelo negcio, que sofre os impactos e consequncias em caso de ausncia de
histrico. Para fazer parte do tamanho funcional, deve ser solicitado pelo gestor
e dever existir funcionalidade de consulta a tais dados. A funo de consulta
aos dados dever ser contada de acordo com as regras de contagem das
funes transacionais do CPM.
Nesse caso, o histrico ser considerado um registro lgico do ALI
relacionado.
No devem ser consideradas na contagem funes de transao
separadas para incluir, alterar e excluir as informaes histricas, pois o
armazenamento dessas informaes parte integrante das mesmas
funcionalidades que processam os dados de negcio.
Observao: Quando o histrico for mantido de forma independente do
registro principal e, por exemplo, o registro excludo do ALI principal, mas o
histrico manter o registro excludo, o histrico se torna um ALI independente
e no um registro lgico do ALI relacionado. Lembrando que, para fazer parte
do tamanho funcional, deve ser solicitado pelo gestor e dever existir
funcionalidade de consulta a tais dados.
4.11.2.2.
Registro de eventos
Para o MP, o registro de eventos tem o objetivo de armazenar os

eventos associados navegao e/ou ao acesso s funcionalidades do
sistema para fins de monitoramento estatsticos ou criao de indicadores de
uso do aplicativo.
O registro de eventos deve ser solicitado pelo gestor da aplicao e,
para a contagem, deve ser considerado como um ALI, devendo existir
funcionalidade de consulta a tais dados.
As informaes de registro de eventos so consideradas como parte
integrante da mesma funcionalidade que processa os dados de negcio. Dessa
forma, no devem ser consideradas na contagem funes de transao
separadas para incluir, alterar e excluir os dados de registro de eventos.
Pgina 14 de 45
4.11.2.3.
Log
O MP utilizar o termo Log como o registro de procedimentos ou aes

realizados pela aplicao, em determinado perodo de tempo, com o objetivo
de apoiar a auditoria do ambiente tecnolgico e a identificao das causas
razes de falhas em sistemas.
Nesse caso, o log no deve ser mensurado, j que no armazena
informaes negociais reconhecidas pelo usurio da aplicao.
A principal diferena entre log e trilha de auditoria :
Log: apoia a auditoria no mbito tecnolgico (problemas
decorrentes da tecnologia que precisam sem investigados, por
meio da anlise do conjunto de procedimentos executadas pela
aplicao como por exemplo: baixa performance no sistema).
Trilha de Auditoria: apoia a auditoria para os dados de negcio.
4.11.2.4.
Trilha de auditoria
Para o MP, a trilha de auditoria tem o objetivo de armazenar informaes

referentes s aes realizadas pelos usurios da aplicao no passado, de
modo que seja possvel apurar quais foram as aes executadas quando da
utilizao do sistema. Para isso, devem existir no mnimo as informaes para
identificar quem realizou a ao (ID de usurio), quando e o que foi realizado,
alm de outras informaes se necessrio.
A trilha de auditoria deve ser solicitada pelo gestor da aplicao e, para
a contagem, considera um registro lgico referenciado do ALI relacionado,
devendo existir funcionalidade de consulta a tais dados.
No devem ser consideradas na contagem funes de transao
separadas para incluir, alterar e excluir os dados de trilha de auditoria, pois o
armazenamento desses dados parte integrante das mesmas funcionalidades
que processam os dados de negcio.
4.11.3.
Consultas com filtros diferentes e com as mesmas sadas
Trata-se de consultas com diferentes critrios de filtro, mas uma nica

sada idntica em termos de campos.
Por exemplo, numa tela de consulta podem existir opes de filtros como
pesquisa de empregados por lotao, data de admisso, data de nascimento,
dentre outros, em que, quando no for especificado nenhum filtro, sero
retornados todos os empregados de uma empresa, ou seja, a seleo dos
filtros opcional. Mas, caso sejam selecionados alguns filtros, poder ser
retornado nenhum ou vrios empregados.
Para esse cenrio, entende-se que os itens de dados e arquivos
referenciados so os mesmos e o que difere so apenas os dados retornados
em funo dos parmetros do filtro.
Pgina 15 de 45
Nesse caso, considera-se que existe apenas um processo elementar de

consulta, que pode ser classificado como CE ou SE.
No caso em que haja evidncias de haver diferentes requisitos
funcionais referentes a critrios mutuamente exclusivos indicando que a juno
em uma nica consulta foi opo de projeto, dever ser avaliado se o caso de
considerar mais de um processo elementar.
4.11.4.
Consultas com filtros iguais e com sadas diferentes
Essas consultas constituem processos elementares distintos e, segundo

as regras de unicidade de Consultas Externas e Sadas Externas do CPM,
devem ser contadas separadamente porque possuem itens de dados distintos
na sada. Assim, se a aplicao tiver duas consultas com filtros iguais e sadas
diferentes, devem ser contadas consultas separadas.
4.11.5.
Integrao entre aplicaes
Este tpico descreve uma orientao de contagem a respeito de

integrao entre aplicaes sem entrar no mrito de como ser o projeto e a
implementao dos requisitos. Tipicamente, esses cenrios usam webservices,
vises de banco de dados, stored procedures de banco de dados, sub-rotinas
exportadas para utilizao externa ao sistema (essas formas de implementao
fazem parte de uma lista exemplificativa), podendo ser utilizados outros meios
a depender de cada especificidade da tecnologia/plataforma utilizada na
soluo.
Esta orientao tambm ajuda extrapolar os requisitos funcionais a partir
do projeto quando a especificao dos requisitos funcionais no fornece as
informaes suficientes para a identificao do fluxo de informao por meio da
aplicao.
Para a explicao dos cenrios 1 e 2, considera-se que os sistemas A
e B sejam de fronteiras distintas.
4.11.5.1. Cenrio 1 (Sistema A requisita dados do Sistema B)

Este cenrio se aplica quando o Sistema A precisa ler/consultar um
conjunto de informaes mantidas por uma aplicao externa denominada
Sistema B.
Exemplo:
Existe um requisito no sistema A do tipo Obter o saldo devedor do
cliente no sistema de controle de contratos. Avaliando o requisito, trata-se da
referncia a um grupo de dados logicamente relacionado (AIE), ainda que no
sistema B no exista esse campo saldo devedor armazenado, j que pode
ser calculado a partir de dados de vrios arquivos. Nesse caso, na viso do
sistema A, trata-se de um campo a ser recuperado do sistema B e, portanto,
considera-se na contagem apenas um AIE independente da quantidade de
arquivos lgicos que originaram os dados.
Pgina 16 de 45
Diante deste cenrio, importante destacar que, para a contagem do

AIE, o CPM define que um AIE deve ser um ALI em outro sistema, mas ele no
estabelece que seja um, apenas um ou pelo menos um ALI. Com isso, este
guia determina que seja utilizada a Viso do Usurio da aplicao em anlise
e, portanto, no exemplo acima, se o usurio considera que se trata de
recuperar um campo, que assim seja medido independentemente de como isso
implementado em outro sistema.
4.11.5.2. Cenrio 2 (Sistema B fornece dados para o Sistema A )

Este cenrio se aplica quando o Sistema B disponibiliza informaes
para serem consumidas pelo Sistema A, sendo que as regras de negcio
para gerar as informaes para o Sistema A de conhecimento do Sistema
B.
Exemplo:
O sistema B precisa disponibilizar o saldo devedor do cliente para o
sistema A utilizar numa transao qualquer.
Na viso do Sistema B, por ser de conhecimento dele a definio ou
especificao das regras de negcio para a gerao do saldo devedor do
cliente, considera na contagem a funo transacional do tipo Sada Externa
para a disponibilizao da informao.
Nesse caso, conta-se uma CE ou SE de acordo com as regras do CPM.
Pgina 17 de 45
Caso haja necessidade de o Sistema B disponibilizar dados para fins

de validao e referncia, provendo esses dados, por exemplo, por meio de um
webservice, mas no exista qualquer regra de negcio associada a essa
construo, sendo que o motivo pelo qual a implementao dos requisitos de
A se d desta forma em B por requisitos tcnicos, no caberia a contagem
de uma CE/SE na perspectiva do Sistema B. Nesse caso, entende-se que, se
no fosse essa restrio, a aplicao poderia obter diretamente os dados sem
qualquer interveno por parte do Sistema B.
4.11.5.3. Cenrio 3 (Disponibilizao e consumo de dados dentro da
mesma fronteira)
Neste cenrio, existem dados sendo disponibilizados por meio de
webservices, vises de banco de dados, stored de procedures de banco de
dados, sub-rotinas, dentre outras implementaes, para serem consumidos por
funes transacionais dentro da mesma fronteira.
Diretriz de Contagem:
Nesse caso, as formas de disponibilizar os dados internamente
aplicao exercem o papel de componente interno ao software sendo medido
e, portanto, a construo de componentes de cdigo reutilizveis no ser
contada em pontos de funo.
As funes transacionais e os arquivos referenciados que utilizam os
dados do webservice, por exemplo, seguem as orientaes de contagem do
CPM.
Apenas em casos de manuteno unicamente no componente, deve
ser aplicada a regra descrita no tpico Manuteno de Componente
Reutilizvel.
4.11.5.4. Identificao do barramento como uma fronteira
Neste cenrio, necessrio o desenvolvimento de funcionalidades no
barramento para atender a uma necessidade negocial. Essas funcionalidades
no so fornecidas pela ferramenta de barramento, ou seja, para atender a
uma demanda negocial do gestor, ser desenvolvida no barramento uma
funcionalidade que identificada como um processo elementar.
No que diz respeito contagem, considera-se:
Pgina 18 de 45
Como usurios as aplicaes que interagem com o barramento;
Na fronteira do barramento, contam-se:

o
Os arquivos lgicos identificados;
o As funes transacionais que sero desenvolvidas (CE, SE

ou EE).
Na fronteira dos outros sistemas, aplica-se o definido pelo CPM.
4.11.5.5. Configurao/Customizao de ferramenta de barramento

Este cenrio identificado quando est sendo utilizada uma
ferramenta de mercado com a funo de barramento para fazer, por exemplo,
orquestrao de servios entre dois ou mais sistemas.
Para este cenrio so identificadas duas situaes distintas:
Configurao da ferramenta de barramento para possibilitar a
comunicao;
Customizao da ferramenta de barramento para atender a uma
necessidade especfica de negcio.
Para efeito deste Guia de Contagem, essas duas situaes no sero
objeto de contagem por meio da tcnica de Anlise de Pontos de Funo e,
portanto, cabe ao MP definir a forma de mensurar e remunerar servios que
caem nessas situaes.
4.11.6.
Manuteno de Componente Reutilizvel
Para projetos de desenvolvimento de novos sistemas, a construo de

componentes de cdigo reutilizveis no afetar o tamanho da aplicao e nem
a remunerao do servio. Entretanto, a reutilizao de componentes
considerada uma boa prtica e deve, sempre que possvel, ser utilizada, uma
vez que o reuso proporcionar melhor produtividade, padronizao e facilidade
de manuteno.
Para projetos de manuteno/melhoria em um componente que
utilizado por vrias funcionalidades da aplicao, esse componente ser
contado como uma funcionalidade e, por se tratar de manuteno, ser
aplicado o fator de impacto equivalente ao tipo de manuteno. Para efeito de
teste da utilizao deste componente pelas funcionalidades que dependem
dele, cabe ao MP, aps apresentada a lista de dependncias deste
componente, definir o escopo de teste indicando quais funcionalidades devem
ser testadas. Para dimensionar o teste deste conjunto de funcionalidades,
deve-se fazer uso da contribuio, em pontos de funo, das funcionalidades a
serem testadas em conjunto com o percentual da disciplina de teste constante
da tabela Percentual de esforo por disciplina no ciclo de vida.
Exemplo: No sistema de Folha de Pagamento, o componente que valida
o cdigo do funcionrio utilizado por 25 processos elementares. Esse
componente precisa ser alterado para considerar um novo departamento da
Pgina 19 de 45
empresa que possuir uma validao diferenciada. O Analista de Sistemas

definiu que, para validar essa alterao, devem ser testados os seguintes
processos: Incluir Funcionrio, Alterar Funcionrio, Selecionar Funcionrio e
Pesquisar Funcionrio por cdigo. Na contagem, ser considerado: a contagem
do componente que valida o cdigo do funcionrio como uma funcionalidade
alterada; a contagem dos 4 processos elementares que sero testados,
devendo ser dimensionados a partir da contribuio dessas funcionalidades de
acordo com o percentual da disciplina de teste constante na tabela Distribuio
em percentual do esforo por disciplina no ciclo de vida.
4.11.7.
Mltiplas Mdias
Ao abordar o tema mltiplas mdias, o IFPUG definiu alguns termos

comuns, a saber:
o Canal: tambm refere-se mdia. Mltiplos canais sinnimo de
mltiplas mdias.
o Mdia: descreve a forma com que os dados ou informaes se
movimentam para dentro e para fora da fronteira de uma aplicao.
Por exemplo, apresentao de dados em tela, impressora, arquivo,
voz. Este termo utilizado para incluir, dentre outros: diferentes
plataformas tcnicas e formatos de arquivos como diferentes mdias.
o Mltiplas Mdias: quando a mesma funcionalidade entregue em

mais de uma mdia. Frequentemente, somente uma mdia
requisitada para um usurio especfico em um determinado
momento. Por exemplo, consulta de extrato bancrio via internet
como oposto consulta de extrato bancrio via terminal do banco.
o Multimdia: quando mais de uma mdia necessria para entregar a
funo. Por exemplo, uma nova notcia publicada na Internet que
apresentada em vdeo e texto. Observe que a notcia completa s
apresentada para o usurio se ele ler o texto e assistir ao vdeo.
o Abordagem Single Instance: esta abordagem no reconhece que a
mdia utilizada na entrega de uma funo transacional uma
caracterstica de diferenciao na identificao da unicidade daquela
funo. Se duas funes entregam a mesma funcionalidade usando
mdias diferentes, elas so consideradas como a mesma
funcionalidade para propsitos de medio.
o Abordagem Multiple Instance: esta abordagem especifica que o
tamanho funcional obtido no contexto do objetivo da contagem,
permitindo uma funo de negcio ser reconhecida no contexto das
mdias que so requisitadas para que a funcionalidade seja entregue.
A abordagem multiple instance reconhece que a mdia para entrega
constitui uma caracterstica de diferenciao na identificao da
unicidade da funo transacional.
Para a aplicao das regras definidas no CPM, o IFPUG reconhece
como vlidas tanto a abordagem single instance quanto a abordagem multiple
instance. A determinao da abordagem a ser seguida em uma contagem de
Pgina 20 de 45
PF depende da avaliao da equipe de mtricas da organizao. As

estimativas e contagens de pontos de funo do MP devero considerar a
abordagem mais adequada situao, conforme os cenrios descritos nas
sees seguintes.
importante enfatizar que tais cenrios no representam uma lista
completa de situaes de mltiplas mdias, mas o entendimento destes
exemplos facilitar a compreenso de outros cenrios envolvendo mltiplas
mdias. Este guia de contagem ser atualizado para considerar as novas
diretrizes que forem publicadas pelo IFPUG e os novos cenrios que
emergirem das contagens de PF dos projetos do MP.
Cenrio 1: Mesmos dados preparados para apresentao em tela,
em arquivo formato texto e impressos
Neste cenrio, uma aplicao apresenta uma informao em uma
consulta em tela. Por requisio do usurio, a mesma informao pode ser
impressa a partir da tela em questo ou disponibilizada em arquivo formato
texto.
Nesses casos, deve ser utilizada a abordagem single instance,
considerando que dados idnticos sendo apresentados em tela, em relatrio
impresso e em arquivo devem ser contados como uma nica funo. Portanto,
apenas uma transao dever ser includa na contagem de pontos de funo.
Cenrio 2: Mesmos dados para entradas em lote (batch) e online
Neste cenrio, uma aplicao pode receber informaes por meio de
dois mtodos: arquivo batch e entrada de dados online. Tanto o arquivo batch
quanto a entrada online executam validaes durante o processamento. Se a
lgica de processamento utilizada nas validaes em modo batch for a mesma
daquela utilizada em modo online, deve ser utilizada a abordagem single
instance, e uma nica transao deve ser includa na contagem de pontos de
funo. Porm, se a lgica de processamento for diferente, deve-se utilizar a
abordagem multiple instance, e duas transaes distintas devem ser includas
na contagem de pontos de funo.
Cenrio 3: Mltiplos canais de entrega da mesma funcionalidade
Neste cenrio, uma funcionalidade deve ser disponibilizada em mltiplos
canais. Por exemplo: consulta de dados em pgina web e consulta de dados
em smartphone. Nesses casos, deve ser utilizada a abordagem multiple
instance, tendo em vista que h necessidade de que sejam desenvolvidas duas
verses da mesma funcionalidade: uma para rodar em navegador web e outra
para rodar em plataforma mvel. Portanto, duas transaes distintas devem ser
includas na contagem de pontos de funo.
Porm, se as verses forem geradas por uma ferramenta de apoio,
sem necessidade de customizao, deve ser utilizada a abordagem single
Pgina 21 de 45
instance e somente uma transao deve ser includa na contagem de pontos

de funo.
importante destacar a existncia de sites responsivos (ou sites
flexveis), que quando o site desenvolvido para que de forma automtica se
encaixe no dispositivo do usurio (PC, celular, tablete, etc.), ou seja, um site
responsivo muda a aparncia e disposio com base no tamanho da tela em
que o site exibido. Nesse caso, entende-se que deve ser utilizada a
abordagem single instance.
Cenrio 4: Relatrios em mltiplos formatos
Neste cenrio, um relatrio deve ser entregue em diferentes formatos.
Por exemplo: em formato HTML, DOC, XLS, XML, HTML, DOC, CSV, JSON,
dentre outros. O usurio ter a oportunidade de escolher em qual formato
deseja que os dados sejam apresentados.
Nesses casos, deve ser considerada a ferramenta de desenvolvimento
utilizada na gerao dos relatrios. Se tiver sido necessria a construo do
relatrio nos dois formatos, deve ser utilizada a abordagem multiple instance,
devido ocorrncia da lgica de processamento de anlise de condies para
verificar quais so aplicveis, e, portanto, duas transaes distintas devem ser
includas na contagem de pontos de funo. Porm, se a ferramenta de
desenvolvimento suportar um gerador de relatrios que permita ao usurio
visualizar o relatrio em tela, imprimi-lo e tambm salv-lo em mltiplos
formatos, dever ser utilizada a abordagem single instance, tendo em vista que
o tal relatrio ser construdo apenas uma vez. Logo, apenas uma transao
deve ser includa na contagem.
Observao 1: Para que uma transao possa ser contada em termos
de mltiplas mdias, o requisito funcional deve deixar claro que a funcionalidade
deve ser entregue em mltiplas mdias.
Observao 2: Quando existir um requisito dizendo que todo relatrio
deve ser emitido em PDF e DOC, por exemplo, pelo fato de ser um requisito
generalista, ou seja, para todos os relatrios, deve ser avaliado se no se trata
de um requisito no funcional.
4.11.8.
Mltiplos processos compondo um processo elementar
(Subdiviso de Funcionalidades)
Para correta quebra de uma funcionalidade em diversos processos
elementares, importante avali-las a partir de uma perspectiva do negcio,
verificando quais funcionalidades so completas e reconhecidas pelos usurios
do negcio. Por exemplo, um processo elementar com telas encadeadas, em
que, quando no concludo o processo, deve ser reiniciado desde a primeira
tela, errado considerar cada tela (ou aba) como um processo elementar.
Cenrio: Um nico Processo Elementar identificado para a
funcionalidade
Pgina 22 de 45
Por exemplo, se uma funcionalidade dividida em abas, necessrio

avaliar se cada uma das telas constitui um processo elementar, atendendo
principalmente ao requisito de ser autocontido. Nesse caso, a primeira coisa a
se fazer a de tentar identificar a razo que levou a diviso da funcionalidade
em diversas telas, pois comum que formulrios de cadastro sejam quebrados
em etapas com o objetivo apenas de tornar a atividade de cadastro mais
intuitiva e organizada, ou seja, apenas para atender a requisitos no funcionais
de usabilidade. Dessa forma, apenas um nico processo elementar pode ser
identificado.
Caso contrrio, se a funcionalidade tiver sido subdividida em diversas
telas para atender a uma necessidade do negcio (Ex: Um departamento
possui a competncia para o preenchimento de uma das telas enquanto que
outro departamento para as demais), isso indcio de que pode se tratar mais
de um processo elementar.
Seguem algumas orientaes para auxiliar o analista de mtricas em
cenrios semelhantes:
Verificar se, caso a funcionalidade no fosse fragmentada e houvesse
uma nica tela, a necessidade de negcio seria atendida independente
de a funcionalidade ser menos usual.
Avaliar se h usurios de reas de negcio distintas responsveis por
preencher telas especficas da funcionalidade, no tendo competncia
(mesmo que munidos de todas as informaes necessrias) para o
preenchimento completo do formulrio.
4.11.9. Consultas Implcitas
So consultas que apresentam dados para o usurio (geralmente
precedendo outra transao a ser realizada), mas que no esto claramente
explcitas nos requisitos ou no prprio sistema. Podem ser classificadas como
CE ou SE.
Geralmente so comuns em telas de alterao ou excluso de registros
de um arquivo, pois, antes de alterar ou excluir o registro, os dados so
apresentados ao usurio e na sequncia o usurio efetua a alterao ou
excluso. Cabe ressaltar que, quando essa consulta idntica a uma consulta
explcita, apenas um processo elementar deve ser contado.
4.11.10.
Contagem de Funes para Converso de Dados
Conforme consta no CPM, a funcionalidade de converso de dados

existe quando h requisitos para migrar ou converter dados durante um novo
projeto de desenvolvimento, projeto de melhoria. Assim, essas funcionalidades
de converso de dados devero ser contadas como Entrada Externa para a
funcionalidade de migrao ou carga inicial dos dados e Consultas ou Sadas
Externas quando forem requisitados pelo usurio relatrios associados
funcionalidade de migrao de dados. Os arquivos do antigo sistema que est
sendo substitudo no devem ser contados como Arquivos de Interface Externa
Pgina 23 de 45
(AIEs) da nova aplicao e as extraes dos dados do sistema antigo, se for o

caso, no sero contadas como CEs ou SEs.
4.11.11.
Projetos de Migrao de Dados
A critrio do MP, quando for identificada complexidade no processo de

migrao de dados, os pontos de funo de converso (PF_CONVERSO)
podero ser suprimidos das frmulas de contagem de pontos de funo de
Projetos de Desenvolvimento e de Melhoria e as funcionalidades de migrao
de dados podem ser tratadas de forma separadas como projetos de migrao
de dados, mas aplicando integralmente os conceitos do IFPUG.
4.11.12.
Projetos de Melhoria (Manuteno Evolutiva)
Trata-se de projeto de manuteno evolutiva ou melhoria funcional. Seu

tamanho funcional a medida das funcionalidades includas, alteradas e
excludas em aplicaes em produo. O tamanho funcional de um projeto de
melhoria pode incluir o tamanho da funcionalidade de converso de dados.
As regras de como contar as funes de dados e de transao em um
projeto de melhoria so as mesmas apresentadas no Manual de Prticas de
Contagem (CPM), porm devem ser consideradas as orientaes descritas
neste tpico, pois, para calcular o tamanho funcional do projeto de melhoria,
devem ser aplicados os fatores de impacto definidos nas funes alteradas e
excludas, conforme frmula abaixo.
Segue a Frmula:
PF_MELHORIA = PF_INCLUIDO + (FI x PF_ALTERADO) + (0,3 x
PF_EXCLUIDO) + PF_CONVERSO
Definies:
PF_INCLUDO = pontos de funo das funes que esto sendo
adicionadas pelo projeto de melhoria.
PF_ALTERADO = pontos de funo das funes que sendo alteradas
pelo projeto de melhoria (como elas so ou sero aps a
implementao).
PF_EXCLUDO = pontos de funo das funes sendo excludas pelo
projeto de melhoria.
PF_CONVERSO = pontos de funo das funcionalidades de converso
de dados quando existirem.
O Fator de Impacto (FI) pode variar conforme condies abaixo:
o FI = 50% para
documentao.
funcionalidade
de
sistema
que
possua
Pgina 24 de 45
o FI = 60% para funcionalidade de sistema que no possua

documentao.
Observao 1: Destaca-se que deve haver correo e/ou atualizao da
documentao das funcionalidades da aplicao impactadas pela
manuteno evolutiva quando a funcionalidade possuir documentao
atualizada.
Observao 2: Quando a funcionalidade impactada pela manuteno
evolutiva no possuir documentao ou a documentao estiver
desatualizada, dever ser contemplada a redocumentao ou
atualizao da documentao das funcionalidades.
Observao 3: Se durante o atendimento de uma demanda de projeto
de melhoria for detectada a manuteno evolutiva e corretiva na mesma
funcionalidade, para efeito de contagem, deve ser avaliado se as duas
manutenes podem ser disponibilizadas juntas no ambiente produtivo.
Confirmada a disponibilizao em conjunto, o MP entende que deve ser
contada apenas a manuteno evolutiva. Caso contrrio, a contagem da
manuteno corretiva deve ser feita separada da manuteno evolutiva,
desde que a correo no esteja coberta pela garantia. Para a contagem
da correo, devem ser seguidas as regras descritas no tpico de
Manuteno Corretiva deste guia.
4.11.13.
Melhoria
Mudana estrutural em Arquivos Lgicos para Projetos de
Segundo o CPM, para que uma funo de dado seja contada como uma
funo alterada, obrigatrio que a funo seja estruturalmente alterada.
Mudana estrutural toda incluso ou excluso de atributo em um
arquivo lgico ou alterao de suas caractersticas (alterao de tamanho, tipo
numrico para alfanumrico, etc.), desde que a mudana decorra de
alterao de regra de negcio. Simples alteraes de valores vlidos em um
ALI no sero consideradas mudanas estruturais.
4.11.13.1. Impacto das alteraes das caractersticas de itens de dados
de um ALI nas funes transacionais que o mantm.
Quando as mudanas estruturais em uma funo de dados implicarem
mudana de lgica de processamento nas funes transacionais como, por
exemplo, mudana em validaes, as funes transacionais impactadas devem
ser consideradas alteradas em um projeto de melhoria.
Exemplo: Numa aplicao, o gestor solicitou que o campo de nmero do
telefone residencial do cliente passe a suportar at oito dgitos. Alm disso, foi
solicitado que, nas funcionalidades de incluso e alterao de clientes, caso o
cliente resida no Distrito Federal, seja obrigatrio que seu telefone residencial
tenha oito dgitos, sendo que o primeiro dgito esquerda seja igual a trs.
Pgina 25 de 45
Nesse caso, observa-se alterao na lgica de processamento das entradas

externas de incluso e alterao de clientes e, portanto, ambas seriam
pontuadas na manuteno evolutiva como alteradas. As funcionalidades que
no sofreram alterao em decorrncia da mudana do DER no so
pontuadas.
Quando as mudanas estruturais em uma funo de dados no
implicarem mudana de lgica de processamento nas funes transacionais, o
simples fato de o DER alterado cruzar a fronteira da aplicao nas transaes
que o mantm ou referenciam no suficiente para que essas transaes
sejam consideradas como alteradas na contagem da manuteno evolutiva.
Exemplo: Suponha que deva ser feita uma mudana do nmero do
telefone de sete para oito dgitos e do CEP de cinco para oito dgitos. Se
somente for aplicada a alterao na funo de dados, no sendo identificada a
necessidade de alterar qualquer lgica de processamento nas transaes que
utilizam essa funo, s deve ser considerada no projeto de melhoria a
mudana na funo de dados.
4.12. Itens no mensurveis
Algumas manutenes em softwares no so passveis de medio
segunda a tcnica Anlise de Pontos de Funo, mas, devido existncia
dessas demandas e aos contratos de prestao de servios, para calcular o
esforo das atividades envolvidas nesses tipos de manuteno, houve uma
equiparao do esforo ao ponto de funo e, portanto, seguem as orientaes
descritas abaixo. Os percentuais so estimados, podendo ser reajustados
conforme avaliao da base histrica dos servios realizados no MP.
Os exemplos descritos neste tpico no so exaustivos, ou seja,
identificando-se novos itens no mensurveis, eles devem ser adicionados a
essa lista em verses posteriores deste guia.
Caso seja identificado algum item no contemplado neste tpico, dever
ser encaminhada solicitao fundamentada ao MP, que analisar a pertinncia
da incluso de um novo item no mensurvel.
Importante:
A medio no cumulativa dentro da mesma funcionalidade, ou seja,
caso uma funcionalidade possua itens mensurveis e itens no mensurveis
(uma alterao
no processo elementar e uma alterao de layout na
mesma tela, por exemplo), apenas os itens mensurveis devem ser contados.
4.12.1. Manuteno Corretiva
A manuteno corretiva consiste na correo e alterao de requisitos,
projeto, cdigo, conjunto de testes e documentao para correo de defeitos.
Encontram-se nesta categoria as demandas de correo de erros (bugs) de
Pgina 26 de 45
funcionalidades em sistemas, comportamentos inadequados que causem

problemas de uso.
A estimativa e dimensionamento de tamanho de manutenes corretivas
em pontos de funo devem levar em considerao a documentao do
sistema disponvel e os artefatos a serem mantidos.
Observao 1: Destaca-se que deve haver correo e/ou atualizao da
documentao do sistema. Caso no exista documentao para as
funcionalidades alteradas, no ser contemplada a redocumentao das
funcionalidades da aplicao impactadas pela manuteno corretiva.
Observao 2: Se durante a investigao do problema for constatado
que no h erro no sistema, a demanda dever ser atendida de acordo com o
tpico Verificao de Erros do Roteiro SISP.
Observao 3: Quando o sistema em produo estiver dentro da
garantia da qualidade, a manuteno corretiva ser do tipo Garantia, conforme
prazos e demais clusulas do contrato em questo e no incorrero em nus
financeiro para o MP.
Os deflatores so definidos de acordo com os cenrios abaixo.
4.12.1.1. Sistema sem documentao, desatualizada ou incompleta
Neste caso, deve-se aferir o tamanho em pontos de funo das
funcionalidades impactadas e considera 60%.
Segue a Frmula:
PF_INM = PFfi *0,60
Onde:
PF_INM: valor em pontos de funo do item no mensurvel
PFfi: total de pontos de funo das funcionalidades impactadas
4.12.1.2. Sistema com documentao completa e atualizada
Neste caso, deve-se aferir o tamanho em pontos de funo das
funcionalidades impactadas e considera 50%.
Segue a Frmula:
PF_INM = PFfi *0,50
Onde:
Pgina 27 de 45

4.12.2. Manuteno de Interface
Contemplam as alteraes de interface, por exemplo: layouts de telas,
fonte de letra, cores de telas, logotipos, mudana de botes na tela, mudana
de posio de campos ou texto na tela, mscaras, layout de relatrios ou de
arquivos, diviso de telas e/ou relatrios, sem que haja alterao em elementos
de dados, arquivos referenciados ou informaes de controle.
Nestes casos, deve-se aferir o tamanho em Pontos de Funo da
funcionalidade ou das funcionalidades impactadas e considera 20% da
contagem de uma funo transacional de mais baixa complexidade (3 PF), ou
seja 0,6 PF.
Caso seja utilizada uma mesma tela para duas ou mais funcionalidades,
deve ser contada apenas uma funo transacional.
Observao 1: Destaca-se que deve haver correo e/ou atualizao
da documentao do sistema. Caso no exista documentao para as
funcionalidades alteradas, no ser contemplada a redocumentao das
funcionalidades da aplicao impactadas pela manuteno nas demandas
desta categoria.
Observao 2: Este percentual no cumulativo, ou seja, caso duas ou
mais alteraes de layout sejam realizadas na mesma tela, o percentual ser
aplicado apenas uma vez.
Segue a Frmula:
PF_INM = PFfi *0,6 PF
Onde:
PFfi: quantidade de funes transacionais impactadas
4.12.3. Manuteno em Dados de Cdigo
Contempla a necessidade de criar ou alterar funcionalidades de
cadastro, alterao, excluso e consulta de dados de cdigo, desde que sejam
mantidas e solicitadas pelo usurio.
Nesses casos, para as funes transacionais, aplica-se 50% da funo
de mais baixa complexidade (3 PF) e, para as funes de dados, aplica-se 50%
do ALI de mais baixa complexidade (7 PF).
Segue a frmula:
PF_INM = PFfi * FI
Pgina 28 de 45
Onde:
PFfi: quantidade de funcionalidades impactadas
FI: 1,5 PF para funes de transao e 3,5 PF para funes de dados.
Observao 1: Esse tpico no se aplica para atividades de incluso,
alterao e excluso de dados de domnio em tabelas classificadas como
dados de cdigo, o qual tratado pelo tpico Atualizao de Dados de Cdigo.
Observao 2: Conforme consta no tpico Dados de Cdigo, durante o
projeto de desenvolvimento de software, no ser mensurado em pontos de
funo o desenvolvimento de funcionalidades consideradas dados de cdigo.
Este tpico aplica-se somente para manutenes.
4.12.4. Atualizao de Dados de Cdigo
Contemplam a necessidade de incluso, alterao ou excluso de dados
pertencentes a listas (combo box) ou tabelas fsicas.
Neste caso, considera-se 50% da contagem de pontos de funo de
uma Entrada Externa de complexidade baixa, ou seja, 1,5 PF por lista ou tabela
fsica alterada, includa ou excluda.
Segue a frmula:
PF_INM = PFfi * 1,5 PF
Onde:
PFfi: quantidade de listas ou tabelas fsicas impactadas
4.12.5. Mensagens
Contemplam a necessidade de alteraes de mensagens de retorno ao
usurio, desde que no acessem ALI ou AIE.
Nesses casos, deve-se aferir o tamanho em pontos de funo das
funcionalidades impactadas e aplicar um redutor de 10%.
Segue a Frmula:
PF_INM = PFfi * 0,10
Onde:
Pgina 29 de 45

Observao: Est contemplada a atualizao da documentao das
funcionalidades impactadas.
4.12.6. Programas Auxiliares
So programas compostos de procedimentos de atualizao da base de
dados, que podem ser desenvolvidos por meio de scripts ou no, a serem
executados apenas uma vez para corrigir dados incorretos ou para atualizar
dados em bases de dados de aplicaes; ou ainda para gerar um relatrio
especfico ou um arquivo para o usurio por meio de recuperao de
informaes armazenadas na aplicao.
Deve-se destacar que esses programas no fazem parte da aplicao e
so executados apenas uma vez, podendo ser descartados em seguida.
Para serem considerados em uma contagem de pontos de funo, os
programas auxiliares devem figurar claramente nos requisitos do usurio.
Se, para atender necessidade do usurio for necessrio escrever um
script para consultar o banco de dados, uma CE ou SE dever ser considerada
na contagem. Se for necessrio atualizar, deletar ou incluir dados no banco,
uma EE dever ser considerada na contagem de pontos de funo, em que as
tabelas envolvidas sero ALR e os atributos envolvidos sero DER para o
processo elementar EE.
importante ressaltar que as funes de dados associadas aos dados
atualizados no devem ser contadas, considerando que no h mudanas
nas estruturas dos arquivos lgicos.
Nesses casos, deve-se medir o tamanho funcional do programa auxiliar
construdo.
Por exemplo, se para atender a uma necessidade do usurio for criado
um programa que realize procedimentos (insero, consulta, atualizao ou
excluso) em registros de vrias tabelas, no ser considerado na contagem
um programa separado para o procedimento realizado em cada tabela do
banco de dados envolvida, mas sim ser contado um nico programa auxiliar
criado para atender a necessidade do usurio.
Este tpico substitui o conceito de Apurao Especial, utilizado no
Roteiro SISP.
Consideraes sobre Programas Auxiliares:
Pgina 30 de 45
1. Todo programa auxiliar deve ser documentado, devendo a

documentao conter, minimamente, um objetivo, requisitante, data
de requisio, descritivo funcional, data de descarte (nunca inferior a
18 meses);
2. Os Programas Auxiliares devem ser armazenados, pelo perodo
mnimo descrito em sua documentao, de forma a estarem
disponveis para re-execues quando solicitado;
3. Quando houver reexecuo de Programas Auxiliares, deve ser
aplicado um deflator de 5% sobre o programa construdo. A
reexecuo ser considerada quando:
For reexecutado o mesmo programa (idntico ao original);
Forem aplicados ajustes no script para a troca de parmetros,
por exemplo, nos campos de incluso/alterao, nas chaves
de pesquisa, dentre outros. Entende-se que esses tipos de
ajustes no so caracterizados alteraes de estrutura do
script original.
Segue a frmula:
PF_INM = PFfi * 0,05
Onde:
PFfi: total de pontos de funo do script construdo
4. Quando houver reexecuo de Programas Auxiliares que sofreram

alteraes na estrutura do script original, de forma anloga a um
projeto de melhoria numa funcionalidade, deve ser aplicado um
deflator de 50% sobre o programa construdo.
Segue a frmula:
PF_INM = PFfi * 0,5
Onde:
PFfi: total de pontos de funo do programa construdo
4.13. Mudana de requisitos durante o projeto de desenvolvimento ou
manuteno
Em um processo de desenvolvimento de software, comum mudanas
de requisitos durante o andamento do projeto ou da manuteno.
Quando essas alteraes ocorrerem, primeiramente necessrio
identificar se as mudanas de requisito esto relacionadas a:
Pgina 31 de 45
Alteraes em funcionalidades que ocorreram em virtude de

mudanas no domnio do negcio, como alterao de escopo, regras de
negcio ou mudanas legais/regulamentares durante a execuo da
release ou;
Alteraes referentes evoluo natural dos requisitos, provocada,
neste ltimo caso, pelo aprofundamento, detalhamento e
complementao de requisitos durante o processo de desenvolvimento
gil.
O segundo caso (alteraes inerentes ao desenvolvimento gil) tratado
no tpico Contagem de pontos de funo no desenvolvimento de
software com mtodos geis.
Quanto ao primeiro caso, seguem as orientaes.
4.13.1. Mudanas associadas ao domnio do negcio
Para tratar o dimensionamento das mudanas de requisitos, decorridas
do domnio do negcio, deve-se levar em considerao o trabalho executado
at o momento da solicitao de mudana a fim de apurar o retrabalho gerado
pela mudana. Nesse caso, sugere-se a utilizao de percentual por disciplina
do ciclo de desenvolvimento, conforme os valores definidos na Tabela 1.
Ressalta-se que esses valores so apenas uma referncia, podendo ser
ajustados e redefinidos em contratos.
Disciplina
Engenharia
Requisitos
Anlise e Design
Percentual
esforo
de
25%
de
10%
Implementao
40%
Teste
15%
Homologao
5%
Implantao
5%
Tabela 1 Distribuio em percentual do esforo por disciplina no ciclo

de vida.
Para realizar o clculo dos percentuais das disciplinas executadas,
devem-se considerar somente as disciplinas que tiveram seus produtos
reconhecidos pelo MP como concludos.
Quando for utilizado um processo de desenvolvimento incremental, gil,
deve ser avaliada a viabilidade pelo MP sobre a adoo de percentuais por
Pgina 32 de 45
disciplina, pois, em determinados cenrios, pode ser invivel calcular o

percentual de participao de cada disciplina.
A Tabela 2 resume os percentuais que devem ser aplicados sobre as
funes alteradas (considerando o tamanho antes da mudana) para a
obteno do PF_RETRABALHO.
Natureza da Mudana
Acrscimo (%)
Incluso de Requisito
0%
Alterao de Requisito
50%
Excluso de Requisito
30%
Tabela 2 Percentuais definidos para a mudana de requisitos

O processo de clculo do retrabalho, considerando o percentual das
disciplinas executadas, ocorre da seguinte forma:
Calcula-se o total de pontos de funo das funcionalidades que sofreram
mudana nos requisitos, baseando-se no requisito antes da mudana, e aplicase o percentual do fator de impacto referente ao tipo de mudana de requisito.
Em seguida, multiplica-se pelo percentual das disciplinas executadas at o
momento da solicitao da mudana, conforme os percentuais referenciados
na Tabela 1.
Segue a frmula:
PF_Retrabalho = (PFfi * FI) * P
Onde:
PFfi: pontos de funo da funcionalidade impactada antes da alterao.
FI: Fator de Impacto referente ao tipo de mudana, conforme
percentuais da Tabela 2.
P: Somatrio do percentual das disciplinas executadas.
Para exemplificar a aplicao dos clculos descritos acima, o cenrio
abaixo apresentado.
Suponha que, ao final da etapa de implementao de um novo relatrio
de clientes, seja solicitada uma alterao para acrescentar a exibio de uma
nova informao. A equipe de desenvolvimento ter um retrabalho de algumas
disciplinas do ciclo de vida. Assim, o tamanho dessa mudana deve ser
calculado da seguinte maneira:
Pgina 33 de 45
Tamanho do relatrio de clientes (Antes da Alterao)

Funo: Sada Externa
Complexidade: Mdia
Contribuio: 5PF
Tamanho do relatrio de clientes (Aps a Alterao)
Funo: Sada Externa
Complexidade: Mdia
Contribuio: 5PF
O clculo do tamanho da funcionalidade relatrio de clientes ser
definido conforme Tabela 3:
Disciplina executadas
Engenharia de Requisitos
Percentual
esforo
25%
Anlise e Design
10%
Implementao
40%
Total
de
executadas
disciplinas
de
75%
Tabela 3 - Disciplinas executadas para a confeco do relatrio antes da

mudana
Assim, aplicando a frmula para o exemplo, tem-se o seguinte resultado:
PF_Retrabalho = (5PF*50%) * 0,75 = 1,875 PF
Ao final do projeto, o pagamento referente ao desenvolvimento dessa
funcionalidade de Relatrio de Clientes seria considerado conforme expresso
na Tabela 4.
Descrio
Tamanho
faturvel
1,875 PF
Relatrio
de
Clientes
PF_Retrabalho
Relatrio de Clientes (Requisitos 5 PF
Alterados)
Total de PF para pagamento:
6,875 PF
Tabela 4 - Demonstrativo de PF para pagamento

Para efeito de gesto das mudanas e gerao de indicadores,
recomenda-se que as demandas de mudanas, de acordo com as
caractersticas descritas neste tpico, sejam contadas em planilha separada da
contagem do projeto de desenvolvimento ou da manuteno.
Pgina 34 de 45
4.13.2. Desistncia de incluir, alterar ou excluir uma funo

Quando a mudana no projeto ou demanda for referente desistncia
de incluir, alterar ou excluir funcionalidades, a diretriz :
Para o clculo do PF_Retrabalho neste tipo de mudana, deve-se
considerar o requisito original e aplicar os percentuais que constam na Tabela
2 de acordo com o tipo de mudana de desistncia.
Entretanto, antes de aplicar os percentuais relacionados ao tipo de
mudana, o MP deve avaliar junto contratada o esforo efetivamente aplicado
na execuo desse tipo de mudana para negociar a remunerao somente do
esforo gasto.
Por exemplo, numa requisio de mudana que solicite a excluso de
uma funcionalidade, talvez o retrabalho seja apenas de descarte de algum
artefato que compe a documentao do sistema e, neste caso, pode ser que o
esforo no justifique a utilizao do percentual para excluir a funcionalidade.
Dessa forma, a aplicao desses percentuais depender de uma
deciso do MP, aps a devida anlise tcnica da situao e a comprovao
pela contratada de todo o retrabalho referente desistncia do requisito.
A Tabela 5 resume os percentuais que devem ser aplicados quando a
mudana se referir desistncia de incluir, alterar ou excluir uma funo
(considerando o tamanho antes da mudana) para a obteno do
PF_RETRABALHO.
Requisito Original
Fator
Incluir
Funo
Alterar
Funo
Excluir
Funo
Mudana de requisito de
desistncia
130%
80%
30%
Tabela 5 Percentual para mudana de requisitos de desistncia

importante destacar que cabe ao MP decidir pela adoo do
percentual por disciplina do ciclo de desenvolvimento durante o clculo do
PF_RETRABALHO nesta situao de mudanas referentes desistncia de
incluir, alterar ou de excluir funcionalidades que constavam no escopo do
projeto desde que as regras estabelecidas em contrato no sejam infringidas.
4.14. Contagem de pontos de funo no desenvolvimento de software
com mtodos geis.
O objetivo deste tpico descrever orientaes sobre a aplicao da
Anlise de Pontos de Funo em projetos de desenvolvimento de software com
mtodos geis para subsidiar os processos de contratao de desenvolvimento
e manuteno de software no MP.
Pgina 35 de 45
Este tpico foi elaborado por meio de um estudo preliminar que

considerou o seguinte cenrio:
Processo de desenvolvimento de software orientado a metodologias

geis;
Diviso do projeto de desenvolvimento ou manuteno em releases;
Utilizao de contagem estimativa do projeto definindo o tamanho

estimado de cada uma das releases para efeito de planejamento do
projeto e gerao das Ordens de Servio de desenvolvimento ou
manuteno de software;
Utilizao dos conceitos de release, Sprint, produto pronto, Delta, que

constam abaixo.
Release: Definida como um ciclo que perpassa sequencialmente pelas

fases do processo de desenvolvimento de software com o objetivo de
entregar, ao final do ciclo, um produto pronto. Com base nessa
definio, entende-se que um produto pronto est associado aos
produtos entregues e aceitos ao final de cada release. Recomenda-se
definir um tempo no muito longo para a release, uma vez que o
conceito de produto pronto estaria associado a seu trmino. Logo,
sugere-se um tempo entre 2 e 4 meses.
Produto Pronto: Com base na definio de release, entende-se que o
produto pronto est associado aos produtos entregues e aceitos com a
aprovao do dono do produto ao final de cada release.
Sprint: Uma unidade de perodo, com datas de incio e fim pr-definidas,
dentro da qual executado um conjunto de atividades previamente
estabelecidas.
Delta%: Valor percentual definido pela instituio ou rgo, utilizado
para comparar o volume das alteraes inerentes ao processo gil e a
contagem detalhada final da release.
Considerando os aspectos do desenvolvimento gil, prtica comum a
existncia de evolues em uma funcionalidade durante a execuo das sprints
de uma release. Assim, este guia orienta que as alteraes ocorridas dentro
dessas caractersticas at o valor de Delta% em relao ao tamanho da
release no sejam remuneradas de forma adicional ao total de pontos de
funo da contagem detalhada final da release, pois se entende que so
relativas evoluo natural de requisitos, o que uma caracterstica inerente
ao processo gil e deve ser considerado na definio do valor do ponto de
funo.
O clculo do quantitativo de pontos de funo de cada uma das sprints
de uma release de deciso e responsabilidade da empresa contratada, pois,
para reivindicar e fazer jus ao recebimento do volume de alterao que
Pgina 36 de 45
ultrapassar o Delta% previsto, a contratada dever apresentar memrias de

clculos e evidncias dos produtos gerados antes e depois das evolues.
O Ministrio do Planejamento Oramento e Gesto (MP), atravs de sua
Diretoria de Tecnologia da Informao (DTI), com base em experincias dos
projetos com desenvolvimento gil, calculou seu fator DELTA em 30%.
Considera-se que o ciclo de trabalho evolutivo inerente ao
desenvolvimento gil encerra-se a cada release. Dessa forma, as alteraes
que ocorrerem em funcionalidades existentes aps o trmino da release devem
ser tratadas como projeto de melhoria.
Com relao s alteraes em funcionalidades ocorridas em virtude de
mudanas no domnio do negcio, devem ser aplicadas as regras descritas no
tpico Mudanas associadas ao domnio do negcio.
Na planilha onde ser registrada a contagem referente requisio de
mudana, devem ser consideradas todas as funcionalidades includas,
alteradas e excludas, porm, para efeito de faturamento, as funcionalidades
includas sero remuneradas somente na contagem da release a fim de no
existir duplicidade de remunerao.
Clculo do Fator Evolutivo gil
Para o clculo do volume de evolues inerentes ao processo gil (Fator
Evolutivo gil) de uma release, devem ser aplicados os seguintes passos:
1. Ao final de cada sprint, deve ser efetuada, pela contratada, uma
contagem das funcionalidades solicitadas e entregues;
2. Realizar, ao final da release, uma contagem final detalhada da
release;
3. Somar a contagem de todas as sprints executadas na release;
4. Calcular o Fator Evolutivo gil, que o volume das alteraes
realizadas ao longo do ciclo da release de acordo com a frmula
abaixo:
Onde:
= somatrio das contagens de pontos de funo das
sprints.
= contagem final detalhada da release.
Observao:
Pgina 37 de 45
Na contagem das sprints, so consideradas as funes

desenvolvidas e as alteraes decorrentes da evoluo dos
requisitos.
Na contagem final da release, so consideradas apenas as funes
desenvolvidas na release.
Com relao s alteraes referentes evoluo de requisitos
ocorridas entre as sprints da release, devem ser aplicadas as regras
descritas no tpico Projeto de Melhoria, levando em considerao o
fator de impacto de 50% para funcionalidades alteradas e 30% para
as excludas.
5. Aps o clculo do Fator Evolutivo gil, compara-se o resultado com o

Delta% e verifica-se:
Se o Fator Evolutivo gil for menor ou igual ao Delta%, ento
no haver remunerao adicional contratada alm do valor
referente contagem da release.
Se o Fator Evolutivo gil for maior que o Delta%, ento deve ser
calculado o quantitativo de pontos de funo excedentes a Delta%
(PF Excedente) a fim de fazer a remunerao adicional. O clculo
ocorre da seguinte forma:
Onde:
FP Excedente = Quantidade de pontos de funo excedentes ao
Delta %.
= somatrio das contagens de pontos de funo das
sprints.
PF Release = contagem final detalhada da release.
Delta% = Fator Delta definido pela instituio ou rgo.
Para exemplificar a aplicao dos clculos descritos acima, so
apresentados dois cenrios. Nesses cenrios, as funcionalidades alteradas que
constam na contagem das sprints, registradas na planilha de contagem, so
consideradas como evoluo dos requisitos inerente ao processo de
desenvolvimento gil.
Cenrio 1 Cenrio em que o volume das evolues no ultrapassa o Delta%
definido com o valor de 30%.
Release 1
(composta
de 3
Sprints)
Observao
Nome da Funo
Tipo
Complexidade
PF
Pgina 38 de 45
Contagem
da Sprint 1
Contagem
da Sprint 2
Incluir Empregado
EE
Baixa
Alterar Empregado
EE
Baixa
Empregado
ALI
Baixa
Excluir Empregado
EE
Baixa
Empregado (alterao)
ALI
Baixa
3,5
Consultar Empregado
CE
Baixa
Relatrio XPTO
CE
Baixa
Contagem
da Sprint 3
Incluir Empregado
(alterao)
EE
Baixa
1,5
Total de PF das Sprints
Contagem da
Release 1
Alterao
caracterizada como
evoluo de requisitos.
Aplicado o fator de
impacto de 50%.
Alterao
caracterizada como
Aplicado o fator de
impacto de 50%.
27
Nome da
Funo
Tipo
Complexidade
PF
Incluir
Empregado
EE
Baixa
Alterar
Empregado
EE
Baixa
Excluir
Empregado
EE
Baixa
Consultar
Empregado
CE
Baixa
Relatrio XPTO
CE
Baixa
Empregado
ALI
Baixa
Total de PF da Release
22
Os clculos aplicados para este Cenrio 2 so:
Calcular o Fator Evolutivo gil, de acordo com a frmula;
Fator Evolutivo gil = ((27 PFs / 22 PFs) -1 )*100 = 22,72%

Pgina 39 de 45
Verificar se o resultado do Fator Evolutivo gil maior ou igual a 30%

(Delta%). No caso deste cenrio, 22,72% menor que 30% e, portanto,
no haver remunerao adicional ao total de pontos de funo da
release. A remunerao ser referente quantidade de 22 PFs (PF
Release).
Observao: Cabe destacar que a diferena de 5 PFs, identificada entre
o somatrio de PF das sprints (no caso 27 PFs) e o tamanho da release
(no caso 22 PF), deve ser absorvida pela contratada, pois de acordo
com os conceitos utilizados neste guia, refere-se evoluo de
requisitos, inerente ao processo de desenvolvimento gil.
Cenrio 2 Cenrio em que o volume das evolues ultrapassa o Delta%

definido com o valor de 30%.
Nesse caso, a contagem das sprints deve ser feita em planilha separada
da contagem da release.
Release 1
(composta de 3
Sprints)
Contagem da
Sprint 1
Contagem da
Sprint 2
Contagem da
Sprint 3
Observao
Nome da
Funo
Tipo
Complexidade
PF
Incluir
Empregado
EE
Baixa
Alterar
Empregado
EE
Baixa
Empregado
ALI
Baixa
Excluir
Empregado
EE
Baixa
Empregado
(alterao)
ALI
Baixa
3,5
Consultar
Empregado
CE
Baixa
Relatrio XPTO
CE
Baixa
Incluir
Empregado
(alterao)
Empregado
(alterao)
EE
ALI
Total de PF das Sprints
Baixa
Baixa
Alterao caracterizada como

Aplicado o fator de impacto
de 50%.
1,5

de 50%.
3,5

de 50%.
30,5
Pgina 40 de 45
Contagem da
Release 1
Nome da
Funo
Tipo
Complexidade
PF
Incluir
Empregado
EE
Baixa
Alterar
Empregado
EE
Baixa
Excluir
Empregado
EE
Baixa
Consultar
Empregado
CE
Baixa
Relatrio XPTO
CE
Baixa
Empregado
ALI
Baixa
Total de PF da Release
22
Os clculos aplicados para este Cenrio 2 so:

o
Calcular o Fator Evolutivo gil, de acordo com a frmula;
Fator Evolutivo gil = ((30,5 PFs / 22 PFs) -1)*100 = 38,63%
Verificar se o resultado do Fator Evolutivo gil maior ou igual a 30%

(Delta%). No caso deste cenrio, 38,63% maior que 30% e, portanto,
deve ser calculado o quantitativo de pontos de funo excedentes a fim
de fazer a remunerao adicional. O clculo se d da seguinte forma:
o Calcular os pontos de funo excedentes, aplicando a frmula:
o
PF Excedente = (30,5 PFs 22 PFs) (22 PFs * 30 / 100) = 1,9 PFs

A contratada ser remunerada em 22 PF (PF da Release) + 1,9 PF (pontos
de funo excedentes ao Delta%). Neste caso, a remunerao da contratada
ser de 23,9 PF.
Diante disso, no caso de desenvolvimento com mtodos geis, no sero
remuneradas as evolues inerentes ao processo gil ocorridas durante a
Pgina 41 de 45
execuo da release at 30% (DELTA). Somente haver remunerao do valor

que exceder esse percentual.
5. Dicas para Otimizar o Custo das Manutenes

fundamental aprimorar a gesto sobre as demandas de manuteno de
sistemas. Se as demandas de manuteno em uma mesma funcionalidade
forem executadas individualmente, a tendncia que o custo destas
manutenes ao final sejam superiores ao que poderiam ser, caso houvesse
um agrupamento de pequenas solicitaes em uma nica demanda Fbrica
de Software.
Seguem algumas dicas que podem ajudar a melhorar o cenrio.
5.1.
Consolidao de manutenes
Consolidar manutenes na mesma funcionalidade em uma nica demanda

a maneira mais fcil de racionalizar o custo, pois fazer uma manuteno para
atender um nico requisito ou para atender a vrios requisitos de manuteno
na mesma funcionalidade ter o mesmo tamanho funcional quando solicitadas
ao mesmo momento. Se solicitadas em momentos distintos, as mesmas
funcionalidades sero pagas vrias vezes, uma vez para cada um dos projetos
de melhoria/manuteno.
No entanto, nem sempre possvel represar uma necessidade do usurio
para que esta seja agrupada com outras, j que h demandas com prazos
crticos. O importante tentar avaliar ao mximo quais ajustes realmente so
crticos e quais no so, visando minimizar o fracionamento das solicitaes.
5.2.
Anlise crtica dos requisitos
Em muitas situaes possvel ter uma nica funcionalidade que faa o

papel de duas existentes. Isto muito comum no caso de consultas e relatrios
com diferena apenas de alguns atributos apresentados. Ou seja, uma
transao mais completa poderia ser elaborada para evitar a criao de vrias
funcionalidades distintas, porm semelhantes.
mais barato pagar pela criao de uma funcionalidade nova do que
por uma manuteno em duas ou mais funcionalidades, principalmente a longo
prazo.
O mesmo acontece na definio dos requisitos quanto s regras de
ordenao em relatrios e consultas. Sempre que possvel, deve-se prever as
possveis opes de ordenao durante o desenvolvimento da funcionalidade,
pois isso reduzir a necessidade de manuteno para atender a novos critrios
de ordenao.
5.3.
Programas Auxiliares
Pgina 42 de 45
Para evitar o custo de realizao de sucessivos Programas Auxiliares,

deve-se ponderar o custo/benefcio de se elaborar a criao de novas
funcionalidades para manter dados que precisam ser atualizados com uma
certa frequncia.
6. Entrega da contagem
Todas as contagens apresentadas ao MP devero ser feitas utilizando o
modelo de planilha adotado pelo rgo.
Para o preenchimento
estabelecidas pelo MP.
da
planilha,
devem-se
seguir
as
regras
7. Glossrio
Para a uniformizao do entendimento do contedo deste guia, sero
listadas definies e premissas utilizadas pelo MP na contagem dos pontos de
funo:
Anlise de Pontos de Funo (APF)
Mtodo para a medio de tamanho funcional de um software. A tcnica
mede as funcionalidades de um software sob o ponto de vista do
usurio.
Counting Pratices Manual (CPM)
Manual de Prticas de Contagem de pontos de funo, mantido pelo
IFPUG.
International Function Point Users Group (IFPUG)
Grupo Internacional de Usurios de Pontos de Funo.
Processo Elementar (PE)
a menor unidade de atividade significativa para o usurio. Deve ser
completo em si mesmo, independente, e deixar o negcio da aplicao
em estado consistente.
Lgica de Processamento
O CPM 4.3 define lgica de processamento como requisitos
especificamente solicitados pelo usurio para completar um processo
elementar. Esses requisitos devem incluir as seguintes aes:
o Validaes so executadas;
o Frmulas matemticas e clculos so executados;
o Valores equivalentes so convertidos;
o Dados so filtrados e selecionados atravs da utilizao de
critrios;
o Condies so analisadas para verificar quais so aplicveis;
o Um ou mais ALIs so atualizados;
o Um ou mais ALIs e AIEs so referenciados;
o Dados ou informaes de controle so recuperados;
Pgina 43 de 45
o Dados derivados so criados atravs da transformao de dados

existentes, para criar dados adicionais;
o O comportamento do sistema alterado;
o Preparar e apresentar informaes para fora da fronteira;
o Receber dados ou informaes de controle que entram pela
fronteira da aplicao;
o Dados so reordenados.
o A determinao do tipo e da unicidade de um processo elementar
ocorre pela lgica de processamento vinculada a tal processo, e
cada processo elementar pode incluir mltiplas alternativas ou
ocorrncias das aes acima.
Registro Lgico Referenciado (RLR ou TR)
Um tipo de registro lgico referenciado um subgrupo de dados
reconhecido pelo usurio dentro de uma funo de dados (ALI ou AIE).
Arquivo Lgico Referenciado (ALR ou AR)
Funo de dados lida e/ou mantida por uma funo transacional.
Dado Elementar Referenciado (DER ou TD)
Atributo nico, reconhecido pelo usurio e no repetido.
8. Processo de Reviso do Guia de Contagem

8.1. Reviso para Correo de Inconsistncias e Situaes No
Previstas
As adequaes a este guia podero ser realizadas pelo Ministrio do
Planejamento, Oramento e Gesto para atender normas vigentes, situaes
no previstas, recomendaes de rgo de controle, bem como ajuste de texto
para evitar duplicidade no entendimento.
8.2.
Reviso para Adoo de Novas Verses do CPM
Com o lanamento de novas verses do manual (CPM), sua adoo

como referncia para este guia de contagem dever ser acordada entre o MP e
a contratada.
9. Referncias Bibliogrficas
1. Manual de Prticas de Contagem de Pontos de Funo, Verso 4.3.1,
International Function Point Users Group (IFPUG), janeiro/2010;
2. Roteiro de Mtricas de Software do SISP, Verso 2.0, disponvel em
http://www.sisp.gov.br/ctgcie/download/file/Roteiro_de_Metricas_de_Software_do_SISP_-_v2.0.pdf.
Acessado em: novembro de 2014;
3. Vazquez, C. E. ; Simes, G. S. ; Albert, R. M. Anlise de Pontos de
Funo, Medio, Estimativas e Gerenciamento de Projetos de Software.
10.ed. So Paulo: Editora rica, 2010;
Pgina 44 de 45
4. Anlise de pontos de funo para melhoria de software, verso 2.2.1,

Associao Holandesa dos Usurios de Mtricas de Software (NESMA);
5. http://fattocs.com/pt/blog-pt, site acessado em novembro e dezembro de
2014;
6. Artigo sobre Diferentes aplicaes, diferentes vises dos dados, elaborado
por Carlos Eduardo Vazquez da FATTO Consultoria e Sistemas.
7. Encarte IX Guia de Contagem e Estimativa, Lote 02, Prego Eletrnico
SRP N 28/2012-MME;
8. Guia de Contagem de Pontos de Funo do INEP, verso 7.3, 2012;
9. Guia de Contagem de Pontos de Funo STN SERPRO, verso 2.0,
2013;
10. Guia de Contagem de Pontos de Funo da Infraero, verso 6.0.1, 2014;
11. Guia de Contagem do PROCERGS, verso 2.0, 2013;
12. Guia de Contagem do Ministrio da Justia, verso 2.0, 2013.
13. http://fattocs.com/pt/contagem-antecipada, site acessado em fevereiro de
2015.
Pgina 45 de 45

Guia de Contagem de Pontos de Função do MP

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Guia de Contagem de Pontos de Função do MP

Diunggah oleh

Hak Cipta:

Format Tersedia

Guia de Contagem de Pontos de Funo do MP

Guia de Contagem de Pontos de Funo do MP

REFERNCIAS PRINCIPAIS ............................................................................................................... 5

COUNTING PRACTICES MANUAL DO IFPUG (CPM) ............................................................................... 5

ENTENDIMENTO DA TCNICA ......................................................................................................... 6

Guia de Contagem de Pontos de Funo do MP

CONTAGEM DE FUNES PARA CONVERSO DE DADOS ................................................................. 23

DICAS PARA OTIMIZAR O CUSTO DAS MANUTENES................................................................. 42

ENTREGA DA CONTAGEM ............................................................................................................. 43

PROCESSO DE REVISO DO GUIA DE CONTAGEM ......................................................................... 44

REVISO PARA CORREO DE INCONSISTNCIAS E SITUAES NO PREVISTAS .......................................... 44

Guia de Contagem de Pontos de Funo do MP

Counting Practices Manual do IFPUG (CPM)

O Manual de Prticas de Contagem do IFPUG, que estabelece o padro

Roteiro de Mtricas de Software do SISP (Roteiro SISP)

O Roteiro de Mtricas de Software do SISP (Roteiro SISP) tem o objetivo de

Guia de Contagem de Pontos de Funo do MP

Medir a funcionalidade impactada pelo desenvolvimento, melhoria e

Obter documentao disponvel do projeto

A contagem de pontos de funo se inicia com a anlise da

Uma contagem deve prover uma resposta a um problema do negcio e

Guia de Contagem de Pontos de Funo do MP

Fornecer o tamanho funcional de um projeto como uma entrada para

O tipo de contagem estabelecido pelo responsvel da contagem,

Segundo o CPM, o escopo da contagem define o conjunto de requisitos

Segundo o CPM, um usurio qualquer pessoa ou coisa que se

Guia de Contagem de Pontos de Funo do MP

Requisitos Funcionais do Usurio so um subconjunto dos requisitos do

De acordo com o CPM, a fronteira uma interface conceitual entre o

Guia de Contagem de Pontos de Funo do MP

aplicao. Um artefato que bem representa esse fluxo o diagrama de

As funes de dados representam a funcionalidade oferecida ao usurio

Guia de Contagem de Pontos de Funo do MP

4.7.1. Arquivo Lgico Interno (ALI)

Uma funo de transao um processo elementar que oferece

Guia de Contagem de Pontos de Funo do MP

dados ao usurio atravs de outra lgica de processamento que no apenas a

Nvel de Detalhamento de Contagens

A contagem de pontos de funo pode ser realizada com diferentes

determina-se a quantidade das funes do tipo dado (ALIs e AIEs);

Guia de Contagem de Pontos de Funo do MP

calcula-se o total de pontos de funo no ajustados da aplicao da

tamanho indicativo (pf) = 35 x nmero de ALIs + 15 x nmero de AIEs

determina-se todas as funes de todos os tipos (ALI, AIE, EE, SE,

determina-se todas as funes de todos os tipos (ALI, AIE, EE,

determina-se a complexidade de cada funo (Baixa, Mdia, Alta);

Guia de Contagem de Pontos de Funo do MP

4.10. Fator de Ajuste

Segundo o CPM, os dados de cdigo, s vezes chamados de dados de

Guia de Contagem de Pontos de Funo do MP

arquivos referenciados os ALIs e AIEs que implementam dados de negcio ou

Log, Trilha de Auditoria, Registro de Eventos e Histrico

O objetivo deste tpico descrever o tratamento que o MP dar a respeito

Para o MP, o histrico um registro de informaes passadas em

Para o MP, o registro de eventos tem o objetivo de armazenar os

Guia de Contagem de Pontos de Funo do MP

O MP utilizar o termo Log como o registro de procedimentos ou aes

Para o MP, a trilha de auditoria tem o objetivo de armazenar informaes

Consultas com filtros diferentes e com as mesmas sadas

Trata-se de consultas com diferentes critrios de filtro, mas uma nica

Guia de Contagem de Pontos de Funo do MP

Nesse caso, considera-se que existe apenas um processo elementar de

Consultas com filtros iguais e com sadas diferentes