OFF - Roteiro de Metricas de Software Do SISP - V2.0

Roteiro de Mtricas de Software do SISP
Verso 2.0
________________________________________________________________________________
Presidenta da Repblica
Dilma Vana Rousseff
Ministra do Ministrio do Planejamento, Oramento e Gesto

Miriam Aparecida Belchior
Secretrio de Logstica e Tecnologia da Informao
Delfino Natal de Souza
Departamento de Sistemas de Informao
Corinto Meffe
Coordenao-Geral de Integrao e Interoperabilidade
Everson Lopes de Aguiar
Grupo de Melhoria de Processo de Software do SISP
Emanuelle Monteiro Silva
Gileno Dias dos Santos
Lucinia Turnes
Marcelo Paiva Fernandes
Equipe de Elaborao da Verso 2.0
Carlos Alberto Pires de Castro DATAPREV
Carlos Renato dos Santos Ramos Cmara dos Deputados
Claudia Hazan SERPRO
Edviges Mariza Campos de Magalhes DATAPREV
Emanuelle Monteiro Silva SLTI/MP
Gileno Dias dos Santos SLTI/MP
Inerves Jos dos Santos Filho STN
Lucinia Turnes SLTI/MP
Marcelo Paiva Fernandes SLTI/MP
Marcelo Teixeira Duarte DATAPREV
Marcus Vincius Borela de Castro TCU
Maurcio Koki Matsutani DATAPREV
Patrcia Oliveira de Carvalho SUSEP
Rafael Monteiro dos Santos Escolstico AGU
Regiane Andrade Brito BACEN
Silvia Viviane de Souza Belarmino IPHAN
Roteiro de Mtricas de Software do SISP 2.0

Verso 2.0
Braslia
2012
________________________________________________________________________________
Ministrio do Planejamento, Oramento e Gesto, 2012.
Qualquer parte desta publicao pode ser reproduzida, desde que citada a fonte, de
acordo com as orientaes da licena Creative Commons (CC BY-NC-SA 3.0). Impresso
no Brasil.
Disponvel em: www.sisp.gov.br.
Esta obra est licenciada por uma Licena Creative Commons - AtribuioNoComercial-CompartilhaIgual 3.0 Brasil
Normalizao Bibliogrfica: DIBIB/CODIN/SPOA
Brasil. Ministrio do Planejamento, Oramento e Gesto. Secretaria de

Logstica e Tecnologia da Informao.
Roteiro de Mtricas de Software do SISP: verso 2.0 / Ministrio do
Planejamento, Oramento e Gesto. Secretaria de Logstica e Tecnologia
da Informao. Braslia : MP, 2012.
65 p.: il.
1. Tecnologia da Informao. 2. Roteiro de Mtrica de Software.
3. Ponto de Funo. 4. Sistema de Administrao dos Recursos de
Tecnologia da Informao SISP. I. Ttulo.
CDU 004.4
________________________________________________________________________________
Sumrio
1. Introduo.........................................................................................................................................1
2. Objetivo............................................................................................................................................3
3. Contagem de Pontos de Funo.......................................................................................................3
3.1 Determinar Propsito, Tipo e Escopo da Contagem e Fronteira da Aplicao.............................4
3.2 Identificar Funes de Dados e Funes Transacionais.................................................................5
3.3 Calcular Tamanho Funcional..........................................................................................................6
3.4 Requisitos No Funcionais.............................................................................................................6
4. Clculo de Pontos de Funo para o SISP........................................................................................7
4.1 Projeto de Desenvolvimento...........................................................................................................8
4.2 Projeto de Melhoria........................................................................................................................8
4.3 Projetos de Migrao de Dados...................................................................................................11
4.4 Manuteno Corretiva..................................................................................................................11
4.5 Mudana de Plataforma................................................................................................................12
4.5.1 Mudana de Plataforma - Linguagem de Programao.............................................................13
4.5.2 Mudana de Plataforma - Banco de Dados..............................................................................13
4.6 Atualizao de Verso...................................................................................................................14
4.6.1 Atualizao de Verso Linguagem de Programao...............................................................14
4.6.2 Atualizao de Verso Browser............................................................................................15
4.6.3 Atualizao de Verso Banco de Dados................................................................................15
4.7 Manuteno em Interface.............................................................................................................16
4.8 Adaptao em Funcionalidades sem Alterao de Requisitos Funcionais...................................16
4.9 Apurao Especial........................................................................................................................18
4.9.1 Apurao Especial Base de Dados.........................................................................................18
4.9.2 Apurao Especial Gerao de Relatrios..............................................................................19
4.9.3 Apurao Especial Reexecuo..............................................................................................20
4.10 Atualizao de Dados.................................................................................................................20
4.11 Desenvolvimento, Manuteno e Publicao de Pginas Estticas de Intranet, Internet ou
Portal...................................................................................................................................................20
4.12 Manuteno de Documentao de Sistemas Legados................................................................21
4.13 Verificao de Erros....................................................................................................................22
4.14 Pontos de Funo de Teste..........................................................................................................22
4.15 Componente Interno Reusvel...................................................................................................23
5. Orientaes Complementares para Contagem................................................................................24
5.1 Contagem de Pontos de Funo com Mltiplas Mdias...............................................................24
5.1.1 Cenrio 1: Mesmos dados apresentados em tela e impressos...................................................25
5.1.2 Cenrio 2: Mesmos dados de sada como dados em arquivo e relatrio impresso...................25
5.1.3 Cenrio 3: Mesmos dados de entrada batch e on-line...............................................................25
5.1.4 Cenrio 4: Mltiplos canais de entrega da mesma funcionalidade...........................................25
5.1.5 Cenrio 5: Relatrio em mltiplos formatos.............................................................................26
6. Consideraes Especiais para Planejamento e Acompanhamento de Projetos..............................26
6.1 Diretrizes para Planejamento: Estimativas de Projetos de Software............................................26
6.1.1 Contagem Estimativa de Pontos de Funo (CEPF).................................................................29
6.1.2 Estimativa de Esforo de Projetos de Software.........................................................................33
6.1.2.1 Distribuio de Esforo por Fase do Projeto..........................................................................34
6.1.3 Estimativa de Prazo de Projetos de Software............................................................................34
6.1.4 Alocao de Equipe ao Projeto..................................................................................................37
6.1.5 Mtodo para Estimativa de Custo..............................................................................................37
6.1.6 Estimativa de Recursos Computacionais...................................................................................37
________________________________________________________________________________
6.2 Diretrizes para Acompanhamento de Projetos.............................................................................38
6.2.1 Consideraes sobre Mudana de Requisitos............................................................................38
6.2.2 Consideraes sobre Projetos Cancelados.................................................................................44
6.2.3 Gerenciamento de Progresso de Projetos..................................................................................44
6.2.4 Consideraes sobre Reduo de Cronograma.........................................................................45
6.2.5 Fator de Criticidade de Solicitao de Servio..........................................................................46
7. Atividades Sem Contagem de Pontos de Funo...........................................................................46
8. Processo de Reviso do Roteiro de Contagem...............................................................................48
8.1 Reviso para Correo de Inconsistncias e Situaes no Previstas..........................................48
8.2 Reviso para Adoo de Novas Verses do CPM........................................................................48
9. Concluso.......................................................................................................................................48
10. Referncias Bibliogrficas............................................................................................................49
Anexo I Portaria SLTI/MP N 31, de 29 novembro de 2010...........................................................51
Anexo II Formalizao Simples de Requisitos Projetos de Manuteno Pequenos (< 100 PF). .52
Anexo III Modelo de Documento de Contagem de Pontos de Funo Projetos de Manuteno
Pequenos (< 100 PF).........................................................................................................................56
Anexo IV - Como Evitar Armadilhas em Contratos de Desenvolvimento e Manuteno de Sistemas
............................................................................................................................................................57
Anexo V Resumo da Tcnica EFP (Enhancement Function Points) publicada pela NESMA........63
Anexo VI Notas Tcnicas das Verses Anteriores deste Roteiro....................................................65
ndice de Figuras
Figura 1: Procedimento de Contagem de Pontos de Funo...............................................4
Figura 2: Processo de Estimativas de Projetos de Software [Hazan, 2008].......................27
Figura 3: Modelo Lgico da Anlise de Pontos de Funo.................................................30
Figura 4: Relao entre a Estimativa de Prazo e de Esforo..............................................35
ndice de Tabelas
Tabela 1: Contribuio Funcional dos Tipos Funcionais.......................................................5
Tabela 2: Identificao dos Arquivos Lgicos Internos da Aplicao..................................31
Tabela 3: Identificao dos Arquivos de Interface Externa da Aplicao............................31
Tabela 4: Identificao das Entradas Externas da Aplicao..............................................32
Tabela 5: Identificao das Consultas Externas da Aplicao............................................32
Tabela 6: Identificao das Sadas Externas da Aplicao.................................................33
Tabela 7: Distribuio de Esforo por Macroatividades do Projeto.....................................34
Tabela 8: Expoente t por tipo de Projeto..............................................................................35
Tabela 9: Estimativa de Prazo de Projetos menores que 100 PF.......................................36
Tabela 10: Percentuais definidos para a mudana de requisitos........................................39
________________________________________________________________________________
1. Introduo
Diversas instituies pblicas e privadas tm utilizado a mtrica Ponto de Funo
(PF) nas estimativas e dimensionamento de tamanho funcional de projetos de software
devido aos diversos benefcios de utilizao desta mtrica, destacando-se: regras de
contagem objetivas, independncia da soluo tecnolgica utilizada e facilidade de
estimativa nas fases iniciais do ciclo de vida do software. importante ressaltar que a
Instruo Normativa SLTI n 4, de 12 de novembro de 2010, recomenda o uso de mtricas
em contratos de projetos de software, restringindo o uso da mtrica de esforo homemhora. Alm disso, a Portaria SLTI/MP n 31, de 29 novembro de 2010, recomenda o uso
da mtrica Ponto de Funo para os rgos integrantes do SISP, bem como a adoo do
Roteiro de Mtricas de Software do SISP na contratao de servios de desenvolvimento
e manuteno de solues de software. O Tribunal de Contas da Unio (TCU) tem
publicado vrios acrdos que recomendam a utilizao da mtrica Ponto de Funo No
Ajustado em contratos de prestao de servios de desenvolvimento e manuteno de
sistemas, entre os quais podem ser citados:
Acrdo n 1.782/2007: recomenda o uso da mtrica Ponto de Funo como forma

de pagamento dos servios contratados de desenvolvimento e manuteno de
sistemas, ao invs de se realizar a converso dos pontos de funo em horas,
baseado na produtividade mdia da tecnologia empregada.
Acrdo n 1.910/2007: em ateno ao princpio da eficincia, faz duas

recomendaes: adotar a tcnica de medio por ponto de funo sem ajustes
pelas caractersticas da aplicao (pontos de funo no ajustados) e diferenciar,
na frmula de clculo, os custos dos pontos de funo para desenvolver novas
funcionalidades, daqueles relativos a supresses ou alteraes de funcionalidades
existentes.
Acrdos nos 1.125/2009 e 1.274/2010: determinam no vincular a mtrica de

tamanho funcional (Ponto de Funo) com a de esforo (homem-hora).
Acrdos nos 2.348/2009 e 1.647/2010: reforam a determinao de no usar

qualquer tipo de fator de ajuste na medio por pontos de funo na contratao
de servios de desenvolvimento de software, para impossibilitar alteraes na
remunerao da funcionalidade medida, por se basear em interpretao subjetiva
dos nveis das caractersticas gerais de sistemas, em desacordo com o previsto no
art. 54, 1, da Lei n 8.666/93 e art. 2, VIII, da IN SLTI n 04/2008. Alm disso, o
acrdo 1.647/2010 determina que no se use exclusivamente o Manual de
Prticas de Contagem (CPM) do IFPUG nas contrataes de servios de
desenvolvimento, e que sejam adicionadas clusulas complementares que
elucidem pontos no abordados pelo CPM; e recomenda a diferenciao, em sua
frmula de clculo, dos custos de pontos de funo para o desenvolvimento
completo de uma funcionalidade (todas as fases do ciclo de desenvolvimento)
daqueles necessrios execuo de apenas uma fase do ciclo.
O Manual de Prticas de Contagem de Pontos de Funo (CPM 4.3) [IFPUG,

2010b], publicado pelo International Function Point Users Group (IFPUG), define as
regras de contagem de pontos de funo. importante ressaltar que a mtrica Ponto de
Funo foi concebida como uma medida de tamanho funcional para projetos de
desenvolvimento e de melhoria (manuteno evolutiva) de software. No entanto, os
projetos de software no esto limitados a projetos de desenvolvimento e de melhoria.
Desta forma, torna-se essencial a definio de mtricas para dimensionar o tamanho de
outros tipos de projetos de manuteno, os quais so itens no mensurveis pelo CPM.
________________________________________________________________________________
Alm disso, a contagem de pontos de funo baseada no projeto lgico da
aplicao (logical design). Nas fases iniciais do ciclo de vida do software, o insumo para a
definio das estimativas do projeto um documento inicial de requisitos, por exemplo:
documento de viso ou algum outro tipo de especificao elaborada pelo analista de
negcios. Assim, torna-se importante o estabelecimento de mtodos para estimar o
tamanho dos projetos de software nas fases iniciais do ciclo de vida. Outro ponto a ser
destacado a importncia da definio de mtodos para gerao de estimativas de prazo
e custo dos projetos de software a partir do tamanho funcional estimado do projeto.
importante frisar tambm que o CPM um documento que se destina a mensurar
o tamanho funcional de projetos de software, no tendo por objetivo principal suportar
contratos de prestao de servios de desenvolvimento e manuteno de sistemas.
Assim, torna-se necessrio criar roteiros complementares, contemplando questes no
abordadas pelo manual do IFPUG, mas vivenciadas pelos rgos e entidades do SISP.
O restante deste documento encontra-se organizado da seguinte forma: o captulo
2 descreve os objetivos e as referncias consultadas para a elaborao deste documento;
o captulo 3 apresenta algumas definies bsicas para a contagem de pontos de funo;
o captulo 4 define mtricas baseadas em Ponto de Funo para dimensionar projetos de
desenvolvimento e vrios tipos de projetos de manuteno de software; o captulo 5
estabelece diretrizes para contagem de mltiplas mdias; o captulo 6 define um processo
de estimativas e recomendaes para o gerenciamento de projetos contratados com base
em mtricas, tais como: tratamento de mudanas de requisitos, projetos cancelados e
reduo de cronograma; o captulo 7 apresenta algumas atividades que no devem ser
consideradas nas contagens de pontos de funo; o captulo 8 apresenta o processo de
reviso deste guia de contagem; finalmente, o captulo 9 conclui o documento,
apresentando sugestes para trabalhos futuros.
________________________________________________________________________________
2. Objetivo
Este documento tem como objetivo principal apresentar um roteiro de mtricas,
com base nas regras de contagem de pontos de funo do Manual de Prticas de
Contagem (CPM 4.3), para vrios tipos de projetos de desenvolvimento e de manuteno
de sistemas, promovendo o uso de mtricas objetivas nos contratos de prestao de
servios desses projetos. Alm da contagem de pontos de funo, este roteiro apresenta
um processo de estimativas com base na mtrica Ponto de Funo, visando apoiar as
organizaes nas estimativas de tamanho, custo, prazo e esforo de seus projetos
desenvolvidos internamente ou contratados.
A verso 2.0 foi elaborada com base em propostas de melhoria da verso 1.0 do
Roteiro de Mtricas de Software do SISP, enviadas pelos rgos, e em roteiros de
mtricas de rgos que j utilizavam a mtrica PF em contratos de software, alm de
contar com sugestes obtidas do Grupo de Trabalho de Mtricas do SISP e de discusses
com um grupo de especialistas em mtricas de rgos e entidades do SISP.
A alterao do modelo de contratao de software, decorrente da implantao de
um processo de medio de software mais objetivo, requer uma mudana cultural, devido
mudana do paradigma homem-hora para a nova forma de contratao com base na
mtrica Ponto de Funo. Este roteiro tem como propsito apoiar os rgos e entidades
do SISP nessa mudana cultural. recomendvel a leitura do Anexo IV, pois apresenta
vrios tpicos importantes a serem observados pelos rgos contratantes na utilizao do
modelo de contratao de software usando a mtrica PF.
Duas premissas foram consideradas na elaborao deste roteiro:
Simplicidade: Este roteiro deve ser simples para incentivar os rgos e
entidades do SISP a utilizar a mtrica Ponto de Funo como medida padro no
estabelecimento de contratos de prestao de servios de desenvolvimento e
manuteno de sistemas.
Consistncia: Este roteiro deve definir critrios objetivos, visando prover a
consistncia no uso de mtricas em contratos de prestao de servios de
desenvolvimento e manuteno de sistemas. Deste modo, dois profissionais ao aplicarem
o roteiro no dimensionamento de um projeto de software devem obter o mesmo resultado.
3. Contagem de Pontos de Funo

A mtrica PF mede o tamanho funcional de um projeto de software, observando
as funcionalidades implementadas, considerando a viso do usurio. O tamanho funcional
definido como tamanho do software derivado pela quantificao dos requisitos
funcionais do usurio [Dekkers, 2003]. A mtrica PF independente da metodologia e
tecnologia utilizadas. A Anlise de Pontos de Funo (APF) um mtodo padro para a
medio de projetos de desenvolvimento e de manuteno de sistemas, visando
estabelecer uma medida de tamanho do software em pontos de funo, com base na
quantificao das funcionalidades solicitadas e entregues, sob o ponto de vista do
usurio. Assim, a APF tem como objetivo medir o que o software faz, por meio de uma
avaliao padronizada dos requisitos de negcio do sistema.
O Manual de Prticas de Contagem (CPM) [IFPUG, 2010b] apresenta as regras de
contagem de pontos de funo de projetos de desenvolvimento, projetos de melhoria e
aplicaes implantadas. A Figura 1 ilustra o procedimento de contagem de pontos de
funo, descrito nas sees seguintes.
________________________________________________________________________________
Obter a
documentao
disponvel
do projeto
Identificar o Propsito
da Contagem
Identifique os
requisitos
funcionais
Identificar o Tipo de
Contagem
Determinar o Escopo
da Contagem
Contar
Funes de
Dados
Calcular
Tamanho
Funcional
Contar
Funes
Transacionais
Determinar a Fronteira
da Aplicao
Documentar
e Reportar a
Contagem
Figura 1: Procedimento de Contagem de Pontos de Funo
3.1 Determinar Propsito, Tipo e Escopo da Contagem e Fronteira da

Aplicao
A contagem de pontos de funo se inicia com a anlise da documentao
disponvel do projeto em questo, visando a identificao dos requisitos funcionais. O
prximo passo o estabelecimento do propsito da contagem, o qual fornece uma
resposta para uma questo de negcio a ser resolvida, por exemplo: necessidade de
dimensionar um projeto de um novo sistema para auxiliar o processo de contratao do
mesmo. Com base no propsito da contagem so definidos o escopo da contagem e o
tipo de contagem. O escopo da contagem identifica quais funcionalidades sero includas
na contagem de pontos de funo, e o tipo de contagem identifica se o projeto de
desenvolvimento, de melhoria ou aplicao instalada. A fronteira da aplicao, que a
interface conceitual que indica o limite lgico entre o sistema sendo medido e os usurios
(tambm entre outras aplicaes), deve ser definida com base na viso do usurio,
desconsiderando questes de implementao. Deve-se ressaltar que toda contagem de
pontos de funo realizada dentro de uma fronteira estabelecida.
O estabelecimento da fronteira da aplicao pode ser subjetivo, por exemplo, em
uma aplicao com vrios mdulos, a fronteira pode ser estabelecida para cada mdulo
ou subsistema ou, ainda, pode-se considerar toda a aplicao, dependendo da viso do
usurio. De fato, a definio da fronteira depende de processos de negcios, alm disso ,
o posicionamento da fronteira influencia fortemente a contagem de pontos de funo.
Desta forma, devido a essa subjetividade, em editais para contratao de projetos de
manuteno fortemente recomendado a definio das fronteiras de todas as aplicaes
a serem contratadas. Os roteiros de contagem dos rgos e entidades tambm devem
definir as fronteiras das aplicaes implantadas em um anexo, e este deve ser atualizado
sempre que for implantada uma nova aplicao. Mais informaes sobre esse assunto
podem ser encontradas no Anexo IV.
________________________________________________________________________________
3.2 Identificar Funes de Dados e Funes Transacionais

Uma vez estabelecida a fronteira da contagem, o prximo passo o mapeamento
dos requisitos de dados e de funes transacionais para os tipos funcionais da APF, a
saber:
Arquivo Lgico Interno (ALI): um grupo de dados, logicamente relacionados,
reconhecido pelo usurio, mantido por meio de um processo elementar da aplicao que
est sendo contada.
Arquivo de Interface Externa (AIE): um grupo de dados, logicamente
relacionados, reconhecido pelo usurio, mantido por meio de um processo elementar de
uma outra aplicao e referenciado pela aplicao que est sendo contada. O AIE
obrigatoriamente um ALI de outra aplicao.
Entrada Externa (EE): um processo elementar que processa dados ou
informao de controle que entram pela fronteira da aplicao. Seu objetivo principal
manter um ou mais ALI ou alterar o comportamento do sistema.
Consulta Externa (CE): um processo elementar que envia dados ou
informao de controle para fora da fronteira da aplicao. Seu objetivo principal
apresentar informao para o usurio atravs da recuperao de dados ou informao de
controle de ALI ou AIE.
Sada Externa (SE): um processo elementar que envia dados ou informao de
controle para fora da fronteira da aplicao. Seu objetivo principal apresentar
informao para um usurio ou outra aplicao atravs de um processamento lgico
adicional recuperao de dados ou informao de controle. O processamento lgico
deve conter clculo, ou criar dados derivados, ou manter ALI ou alterar o comportamento
do sistema.
Aps a identificao dos tipos funcionais para cada requisito funcional definido no
documento de requisitos do sistema, deve-se avaliar a complexidade (Baixa, Mdia, Alta)
e a contribuio funcional do mesmo para a contagem de pontos de funo, observando
as regras de contagem de pontos de funo descritas no CPM. A identificao e a
avaliao das complexidades dos tipos funcionais no podem ser realizadas de maneira
subjetiva. A contagem de pontos de funo deve seguir rigorosamente as regras de
contagem do CPM e as definies complementares do roteiro de mtricas do rgo, e
deve ser realizada por profissionais capacitados do rgo.
A Tabela 1 apresenta a contribuio dos tipos funcionais na contagem de pontos de
funo.
Complexidade
Tipo Funcional
Baixa
Mdia Alta
Arquivo Lgico Interno (ALI)
7 PF
10 PF
15 PF
Arquivo de Interface Externa (AIE)
5 PF
7 PF
10 PF
Entrada Externa (EE)
3 PF
4 PF
6 PF
Sada Externa (SE)
4 PF
5 PF
7 PF
Consulta Externa (CE)
3 PF
4 PF
6 PF
Tabela 1: Contribuio Funcional dos Tipos Funcionais (Fonte: CPM 4.3)

________________________________________________________________________________
3.3 Calcular Tamanho Funcional

O Manual de Prticas de Contagem do IFPUG define dois tipos de projetos de
software, a saber:
Projeto de Desenvolvimento: projeto para desenvolver e entregar a primeira
verso de uma aplicao de software. Seu tamanho funcional a medida das
funcionalidades entregues ao usurio no final do projeto. Tambm considera-se as
funcionalidades de converso de dados, caso seja requisitado no projeto a migrao ou
carga inicial de dados para a nova aplicao.
Projeto de Melhoria: projeto de manuteno evolutiva ou melhoria funcional. Seu
tamanho funcional a medida das funcionalidades includas, alteradas e excludas ao
final do projeto. Tambm considera-se as funcionalidades de converso de dados, caso
seja requisitado a migrao ou carga inicial de dados no projeto de melhoria.
Seguem abaixo as definies dos termos tcnicos da Anlise de Pontos de Funo
utilizados nas frmulas de dimensionamento de projetos de software propostas neste
roteiro:
PF_INCLUDO: pontos de funo associados s novas funcionalidades que faro
parte da aplicao aps um projeto de desenvolvimento ou de manuteno.
PF_ALTERADO: pontos de funo associados s funcionalidades existentes na
aplicao que sero alteradas no projeto de manuteno.
PF_EXCLUDO: pontos de funo associados s funcionalidades existentes na
aplicao que sero excludas no projeto de manuteno.
PF_CONVERSO: pontos de funo associados s funcionalidades de
converso de dados dos projetos de desenvolvimento ou de manuteno. Exemplos de
funes de converso incluem: migrao ou carga inicial de dados para popular as novas
tabelas criadas (Entradas Externas) e relatrios associados migrao de dados, caso
requisitado pelo usurio (Sadas Externas ou Consultas Externas). Observe que os dados
carregados em um processo de migrao no devem ser contados como Arquivos de
Interface Externa.
Este roteiro recomenda a supresso do PF_CONVERSO das frmulas de
contagem de pontos de funo de projetos de desenvolvimento e de melhoria nos casos
especficos onde for caracterizado um esforo relativamente maior dessa atividade. Por
exemplo, os projetos que envolvem a migrao de dados de banco de dados hierrquico
para banco de dados relacional e o tratamento de funes complexas de migrao de
dados. Nesses casos, recomenda-se trat-los como projetos separados de migrao de
dados, descritos na seo 4.3.
3.4 Requisitos No Funcionais

A mtrica Ponto de Funo uma mtrica de tamanho funcional, ou seja,
dimensiona projetos de software com base nos requisitos funcionais da aplicao, no
contemplando diretamente os requisitos no funcionais do projeto.
Nesse sentido, em contratos de software baseados na mtrica Ponto de Funo
fundamental definir claramente no edital os requisitos no funcionais do projeto a serem
atendidos pela empresa contratada. Os requisitos no funcionais impactam no esforo e,
consequentemente, no custo do projeto.
________________________________________________________________________________
Os requisitos no funcionais esto associados aos aspectos qualitativos de um
software, considerando aspectos relacionados ao uso do software. Seguem abaixo alguns
tipos de requisitos no funcionais, com exemplos, que podem ser mencionados nos
editais:
- Usabilidade: a soluo deve atender aos requisitos dos Padres Web em
Governo Eletrnico (e-PWG) Cartilha de Usabilidade; a aplicao deve ter help on-line
de sistema, tela e campo (sensvel a contexto); a aplicao deve ser disponibilizada nos
idiomas Portugus, Espanhol e Ingls.
- Tcnicos: a aplicao deve funcionar adequadamente nos navegadores: Internet
Explorer 7.0 ou superior e Mozilla Firefox 3.0 ou superior; a soluo deve ser
desenvolvida em linguagem Java com banco de dados PostgreSQL; para o
desenvolvimento da soluo, deve ser utilizado preferencialmente um dos seguintes
frameworks Java: Demoiselle, Jaguar e MDArt; a soluo deve atender aos requisitos do
e-PWG; deve utilizar as ferramentas AWSTATS e Google Analytics para gerar estatsticas
de acesso.
- Segurana: a aplicao deve realizar controle de segurana dos dados de acordo
com politica de backup definida em conformidade com a norma ISO/IEC 27002.
- Acessibilidade: a soluo deve ser aderente ao Modelo de Acessibilidade de
Governo Eletrnico (e-MAG).
- Performance: o tempo de resposta da aplicao no deve exceder 10 segundos;
a soluo deve suportar at 1.000 acessos simultneos.
- Interoperabilidade: a soluo deve ser
Interoperabilidade de Governo Eletrnico (e-PING).
aderente
aos
Padres
de
4. Clculo de Pontos de Funo para o SISP

Este captulo tem como propsito descrever os diversos tipos de projetos de
software e definir mtricas para seu dimensionamento baseadas nas regras de contagem
de pontos de funo do CPM.
Quanto documentao de pequenos projetos de manuteno (menores que 100
PF), deve-se registrar a solicitao e documentar os requisitos do projeto de manuteno
e da aplicao impactada pela demanda, de forma detalhada, visando apoiar a contagem
de pontos de funo da demanda. importante tambm documentar as estimativas e a
contagem de pontos de funo. O Anexo II e Anexo III apresentam, respectivamente, um
modelo de documento de requisitos e um modelo de documento de contagem de pontos
de funo para projetos de manuteno de pequeno porte (menores que 100 PF).
Cabe ressaltar que, em alguns casos, o rgo contratante pode no ter
necessidade de contratar todas as fases do ciclo de vida do software. Dessa forma, a
contratada ser remunerada pela contagem de pontos de funo considerando apenas
os percentuais das fases contratadas, conforme os nveis percentuais sugeridos na
Tabela 7 ou na metodologia do rgo (ver subseo 6.1.2.1). Exemplo: para um novo
projeto de desenvolvimento de um sistema de treinamentos, que no exista a inteno de
contratar as fases de requisitos e de testes, a contratada ser remunerada pela contagem
de pontos de funo desconsiderando os percentuais dessas fases.
Alm disso, recomenda-se que as contagens de manuteno a partir do Roteiro de
Mtricas de Software do SISP sejam reportadas conforme determinado pelo CPM, ou
seja, S FP (IFPUGISc), indicando que o resultado da contagem de pontos de funo
no mantm conformidade plena com o CPM e o padro internacional de contagem de PF
________________________________________________________________________________
(ISO/IEC 20926:200x) e sim mantm conformidade com uma customizao, neste caso, o
Roteiro de Mtricas de Software do SISP.
Assim: S FP (IFPUGISc)
Onde:
S o resultado da contagem de pontos de funo;
FP (Function Point) a unidade de tamanho do mtodo FSM (Functional Size
Measurement) do IFPUG;
IS (International Standard) o padro internacional (ISO/IEC 20926:200x);
c representa um ou mais caracteres indicando que o resultado no mantm
conformidade plena com o padro internacional.
Exemplo: 250 PF* (IFPUGISO/IEC 20926:200xsisp)
* FP na verso em portugus
4.1 Projeto de Desenvolvimento

o projeto para desenvolver e entregar a primeira verso de uma aplicao de
software. Seu tamanho funcional a medida das funcionalidades entregues ao usurio no
final do projeto. Tambm considera-se as funcionalidades de converso de dados. Segue
a frmula de clculo utilizada no dimensionamento de projetos de desenvolvimento de
software:
PF_DESENVOLVIMENTO = PF_INCLUIDO + PF_CONVERSO
contagem de pontos de funo de projetos de desenvolvimento quando for caracterizado
um esforo relativamente maior dessa atividade, conforme descrito na seo 3.3.
4.2 Projeto de Melhoria

O Projeto de Melhoria (enhancement), tambm denominado de projeto de melhoria
funcional ou manuteno evolutiva, est associado s mudanas em requisitos funcionais
da aplicao, ou seja, incluso de novas funcionalidades, alterao ou excluso de
funcionalidades em aplicaes implantadas.
Segundo o padro IEEE Std 1219 [IEEE, 1998], esta manuteno seria um tipo de
manuteno adaptativa, definida como: modificao de um produto de software existente
para mant-lo funcionando adequadamente em um ambiente que sofre mudanas. O
projeto de melhoria considerado um tipo de projeto de manuteno adaptativa com
mudanas em requisitos funcionais da aplicao, ou seja, com funcionalidades includas,
alteradas ou excludas na aplicao, segundo o CPM 4.3.
Este roteiro separa o projeto de melhoria (quando as mudanas so associadas
aos requisitos funcionais) do projeto de manuteno adaptativa (quando as mudanas
esto associadas aos requisitos no funcionais da aplicao). Um projeto de melhoria
consiste em demandas de criao de novas funcionalidades (grupos de dados ou
processos elementares), demandas de excluso de funcionalidades (grupos de dados ou
processos elementares) e demandas de alterao de funcionalidades (grupos de dados
ou processos elementares) em aplicaes implantadas em produo.
________________________________________________________________________________
Segue a frmula de clculo utilizada no dimensionamento de projetos de melhoria
de software:
PF_MELHORIA = PF_INCLUIDO + (FI x PF_ALTERADO) + (0,40 x PF_EXCLUIDO) +
PF_CONVERSO
FI (Fator de Impacto) pode variar de 50% a 90% conforme condies abaixo:
FI = 50% para funcionalidade de sistema desenvolvida ou mantida por meio de

um projeto de melhoria pela empresa contratada.
FI = 75% para funcionalidade de sistema no desenvolvida ou mantida por

meio de um projeto de melhoria pela empresa contratada e sem necessidade de
redocumentao da funcionalidade.

meio de um projeto de melhoria pela empresa contratada e com necessidade de
redocumentao da funcionalidade. FI = 90% representa a adio de 15% como
fator de redocumentao ao Fator de Impacto anterior (75%). Nesse caso, a
contratada deve redocumentar a funcionalidade mantida, gerando a
documentao completa da mesma, aderente ao processo de software da
contratante. Se houver uma nova demanda de projeto de melhoria na
funcionalidade em questo, ser considerado que a contratada desenvolveu a
funcionalidade. Observe que o percentual de 90% apenas ser considerado na
primeira demanda de projeto de melhoria em cada funcionalidade.
Este roteiro prope um fator de redocumentao menor para projetos de

manuteno (melhoria, corretiva e adaptativa) do que o fator proposto em projetos
especficos de redocumentao (seo 4.12 deste roteiro). Isso porque, em projetos de
manuteno de uma funcionalidade sem documentao, necessrio realizar o
entendimento da funcionalidade para poder modific-la e test-la, ou seja, necessrio
realizar a engenharia reversa da funcionalidade para executar os testes corretamente.
Assim sendo, a redocumentao requisitada em projetos de melhoria requer um esforo
menor do que em projetos de redocumentao, descritos na seo 4.12, onde
necessrio remunerar todo o esforo de engenharia reversa e a atividade de
documentao. Em projetos de manuteno, o fator de 15% est remunerando apenas a
atividade de documentao.
Os percentuais de FI acima correspondem contratao de todas as fases do
processo de desenvolvimento de software. Caso alguma fase no seja contratada, devese aplicar ao FI um redutor que corresponde ao percentual da fase no contratada,
conforme percentuais sugeridos na Tabela 7 ou na metodologia do rgo.
Os percentuais de multiplicao propostos so estimados, podendo ser reajustados
conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
contagem de pontos de funo de projetos de melhoria quando for caracterizado um
esforo relativamente maior dessa atividade, conforme descrito na seo 3.3.
Uma outra forma de dimensionar projetos de melhoria usando a tcnica EFP
(Enhancement Function Points) publicada pela NESMA (Netherlands Software Metrics
Users Association) no documento "Function Point Analysis for Software Enhancement
Guidelines" [NESMA, 2009]. Essa tcnica pode ser aplicada quando a contratante j
possui uma base histrica de projetos concludos com Contagem Detalhada de Pontos de
________________________________________________________________________________
Funo e um processo de desenvolvimento implantado com documentao das
aplicaes a serem mantidas. O Anexo V apresenta um resumo da tcnica EFP e a sua
descrio completa pode ser obtida em [NESMA, 2009].
Seguem algumas consideraes importantes para serem analisadas em projetos
de melhoria.
Observao 1: Funo Alterada
Uma funo de dados (Arquivo Lgico Interno ou Arquivo de Interface Externa)
considerada alterada quando houver incluso ou excluso de Tipos de Dados (TD). De
acordo com o glossrio do CPM 4.3, um Tipo de Dados (DET Data Element Type) um
atributo nico, reconhecido pelo usurio e no repetido. Tambm considerada alterada
se algum tipo de dado sofrer mudana de tamanho (nmero de posies) ou tipo de
campo (por exemplo: mudana de numrico ou alfanumrico), caso a mudana decorra
de alterao de regra de negcio.
Uma funo transacional (Entrada Externa, Consulta Externa e Sada Externa)
considerada alterada, quando a alterao contemplar:
Mudana de tipos de dados;
Mudana de arquivos referenciados;
Mudana de 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 uma ou mais das seguintes aes:
Validaes so executadas;
Frmulas matemticas e clculos so executados;
Valores equivalentes so convertidos;
Dados so filtrados e selecionados atravs da utilizao de critrios;
Condies so analisadas para verificar quais so aplicveis;
Um ou mais ALIs so atualizados;
Um ou mais ALIs ou AIEs so referenciados;
Dados ou informaes de controle so recuperados;
Dados derivados so criados atravs da transformao de dados existentes, para
criar dados adicionais;
O comportamento do sistema alterado;
Preparar e apresentar informaes para fora da fronteira;
Receber dados ou informaes de controle que entram pela fronteira da
aplicao;
Dados so reordenados.
10
________________________________________________________________________________
Observao 2: Outros Tipos de Funes Alteradas
Este roteiro considera como funo alterada qualquer mudana em funcionalidades
da aplicao devido s mudanas de regras de negcio. Por exemplo, uma funcionalidade
de cadastro envolvia a incluso de um telefone do gerente. Devido a mudanas no
processo de negcio, a funcionalidade deve sofrer uma manuteno para cadastrar dois
telefones do gerente. Desta forma, o roteiro considera esta funo como uma Entrada
Externa alterada, PF_ALTERADO em um projeto de melhoria, mesmo que no existam
mudanas de lgica de processamento, de tipos de dados ou de arquivos referenciados.
Sero tratadas como manutenes adaptativas apenas as manutenes que implicarem
exclusivamente em mudanas em requisitos no funcionais. Se uma mesma
funcionalidade tiver mudanas em requisitos funcionais e no funcionais, esta deve ser
contada apenas uma vez, como funo alterada em um projeto de melhoria.
4.3 Projetos de Migrao de Dados

Conforme mencionado na seo 3.3, este roteiro recomenda a supresso do
PF_CONVERSO das frmulas de contagem de pontos de funo de projetos de
desenvolvimento e de melhoria nos casos especficos onde for caracterizado um esforo
relativamente maior dessa atividade, tais como, nos casos de migrao de dados de
banco de dados hierrquico para relacional, e no tratamento de funes complexas de
migrao de dados. Nesses casos, recomenda-se tratar esse servio como projeto
separado de migrao de dados.
Os projetos de migrao de dados devem ser contados como um novo projeto de
desenvolvimento de um sistema, seguindo a frmula abaixo:
PF_CONVERSO = PF_INCLUIDO
Um projeto de migrao deve contemplar minimamente: os ALI mantidos pela
migrao, as Entradas Externas considerando as cargas de dados nos ALI e, caso
seja solicitado pelo usurio, os relatrios gerenciais das cargas, que sero contados como
Sadas Externas. Todas as contagens de PF devem ser realizadas com base nas
funcionalidades requisitadas e recebidas pelo usurio.
4.4 Manuteno Corretiva

Mesmo com a execuo de atividades de garantia da qualidade, pode-se
identificar defeitos na aplicao entregue. A manuteno corretiva altera o software para
correo de defeitos. Encontra-se nesta categoria, as demandas de correo de erros
(bugs) em funcionalidades de sistemas em produo.
importante destacar que as demandas de manuteno corretiva frequentemente
precisam ser atendidas com urgncia. Assim, o grau de criticidade do projeto poder
trazer impacto nas estimativas de custo e esforo. O padro IEEE Std 1219 [IEEE,1998]
define um tipo de manuteno corretiva, denominado de Manuteno Emergencial como
manuteno corretiva no programada executada para manter o sistema em estado
operacional.
11
________________________________________________________________________________
Quando o sistema em produo tiver sido desenvolvido pela contratada, a
manuteno corretiva ser do tipo Garantia se estiver no perodo de cobertura e em
conformidade com as demais condies de garantia previstas em contrato. Caso no
exista clusula contratual de garantia, deve ser considerada a garantia preconizada por lei
(Cdigo do Consumidor).
Quando o sistema estiver fora da garantia ou no tenha sido desenvolvido pela
empresa contratada, dever ser estimado e calculado o tamanho do projeto de
manuteno corretiva. Nestes casos, a aferio do tamanho em pontos de funo da
funcionalidade ou das funcionalidades corrigidas deve considerar um fator de impacto
(FI) sobre o PF_ALTERADO.
PF_CORRETIVA = FI x PF_ALTERADO
Fator de Impacto (FI):
50% quando estiver fora da garantia e a correo for feita pela mesma empresa
que desenvolveu a funcionalidade.
75% quando estiver fora da garantia e a correo for feita por empresa diferente
daquela que desenvolveu a funcionalidade.
As demandas de manuteno corretiva no contemplam atualizao de

documentao da funcionalidade corrigida, pois este roteiro considera que, normalmente,
manuteno corretiva no se refere a erros de requisitos. Caso seja erro em requisitos,
essa demanda deve ser tratada como projeto de melhoria (alterao de funcionalidade),
descrito na seo 4.2. Porm, quando o erro for causado por documentao dbia ou
imprecisa (elaborada pela contratada) da funcionalidade corrigida, a manuteno corretiva
poder contemplar os ajustes na documentao, mesmo fora da garantia, mediante
negociao entre as partes.
Caso seja demandada a redocumentao da funcionalidade corrigida, porque a
documentao no existe ou est desatualizada, deve-se adicionar ao FI um fator de
redocumentao de 15%, conforme descrito na seo 4.2.
Os percentuais de multiplicao so estimados, podendo ser reajustados conforme
avaliao da base histrica dos servios realizados no rgo ou entidade.
4.5 Mudana de Plataforma

So considerados nesta categoria, projetos que precisam ser migrados para outra
plataforma. Por exemplo, um sistema legado em COBOL que necessita ser
redesenvolvido em JAVA; o banco de dados de um sistema legado que precisa ser
migrado para o DB2.
Recomenda-se enfaticamente a realizao da anlise de impacto das mudanas
propostas, para efeito de determinao do percentual adequado para aplicao sobre o
total de pontos de funo das funcionalidades impactadas. Por exemplo, em uma anlise
de impacto pode ser identificado que no haver mudanas no cdigo-fonte ou em funo
transacional, sendo necessrio apenas testar o sistema, ento deve-se utilizar um
percentual contemplando apenas a fase de testes. No caso do teste apontar a
necessidade de atualizar alguma funo transacional, no deve ser contado o esforo do
teste, mas sim o esforo abordado nesta seo, conforme as frmulas apresentadas nos
tpicos seguintes.
12
________________________________________________________________________________
As prximas subsees apresentam os tipos de projetos de mudana de
plataforma. Os projetos de mudana de plataforma que se enquadram em mais de uma
subseo, devem ser contados apenas uma vez, considerando o tipo de projeto com
maior contagem de pontos de funo. Os percentuais de multiplicao apresentados so
estimados, podendo ser reajustados conforme avaliao da base histrica dos servios
realizados no rgo ou entidade.
4.5.1 Mudana de Plataforma - Linguagem de Programao

Nesta categoria encontram-se as demandas de redesenvolvimento de sistemas em
outra linguagem de programao. Como os projetos legados, frequentemente, no
possuem documentao, devem ser considerados como novos projetos de
desenvolvimento. Assim, ser utilizada a frmula de projetos de desenvolvimento do
CPM 4.3.
Observe que caso no exista mudana nas funes de dados, ou seja, o banco de
dados da aplicao seja mantido, as funes de dados no devem ser contadas. No
entanto, nesse caso, deve ser realizada a contagem das funes de dados a fim de
compor a documentao da contagem final do projeto.
Outro ponto a ser observado so as fases contratadas. Caso o projeto j possua
documentao de requisitos, a fase de requisitos no ser contratada. Deve-se considerar
apenas os percentuais das fases contratadas.
PF_REDESENVOLVIMENTO_LINGUAGEM = PF_INCLUDO + PF_CONVERSO
Este roteiro recomenda a supresso do PF_CONVERSO da frmula de contagem
de pontos de funo de projetos de redesenvolvimento quando for caracterizado um
esforo relativamente maior dessa atividade, conforme descrito na seo 3.3.
4.5.2 Mudana de Plataforma - Banco de Dados

Nesta categoria encontram-se as demandas de redesenvolvimento de sistemas
para utilizar um outro sistema gerenciador de banco de dados.
Observe que caso no exista mudana nas funes de dados, ou seja, o banco de
dados da aplicao seja mantido, ento as funes de dados no devem ser contadas.
No entanto, nesse caso, deve ser realizada a contagem das funes de dados a fim de
compor a documentao da contagem final do projeto.
Em casos de mudana de banco hierrquico para relacional, em sistemas sem
documentao, devido s mudanas envolvidas, deve-se considerar como um novo
projeto de desenvolvimento, ou seja, as funes de dados e funes transacionais devem
ser contadas. Assim, ser utilizada a frmula de projeto de desenvolvimento do CPM 4.3,
conforme frmula abaixo:
PF_REDESENVOLVIMENTO_BD_HIERRQUICO = PF_INCLUDO + PF_CONVERSO
Nos projetos de redesenvolvimento de banco de dados hierrquico para relacional,
recomenda-se a supresso do PF_CONVERSO da frmula acima, conforme descrito na
seo 3.3.
13
________________________________________________________________________________
Caso o projeto j possua documentao de requisitos, ento a fase de requisitos
no deve ser contratada. importante destacar que isso se aplica a qualquer fase que
no se deseja contratar. Deve-se considerar apenas os percentuais das fases
contratadas.
Caso a demanda de redesenvolvimento seja de um sistema gerenciador de banco
de dados relacional para outro relacional, deve ser utilizada a seguinte frmula:
PF_REDESENVOLVIMENTO_BD_RELACIONAL = (PF_ALTERADO X 0,30) +
PF_CONVERSO
O PF_ALTERADO deve considerar apenas as funcionalidades impactadas. As
funcionalidades que possuem apenas demandas de testes, devem ser contadas usando o
percentual da fase de testes (ver Tabela 7).
Nos projetos de redesenvolvimento de banco de dados relacional para outro
relacional, recomenda-se tratar o PF_CONVERSO dentro do mesmo projeto.
Na mudana de banco relacional para relacional, geralmente a estrutura de dados
no alterada, desta forma no contamos as funes de dados.
4.6 Atualizao de Verso

So consideradas nesta categoria, demandas para uma aplicao existente - ou
parte de uma aplicao existente - executar em verses diferentes de browsers (ex:
Internet Explorer, Firefox, Chrome, etc) ou de linguagens de programao (ex: verso
mais atual do JAVA). Tambm so consideradas nesta categoria atualizao de verso de
banco de dados.
Nesta categoria foram observadas demandas de diferentes tipos de projetos,
descritos nas prximas subsees. Os percentuais de multiplicao apresentados nessas
subsees so estimados, podendo ser reajustados conforme avaliao da base histrica
dos servios realizados no rgo ou entidade.
Outro ponto a ser observado a classificao, em alguns casos, dessas demandas
como componente interno reusvel (seo 4.15).
propostas para efeito de determinao do percentual adequado para aplicao sobre o
total de pontos de funo das funcionalidades impactadas. Por exemplo, em uma anlise
de impacto, pode ser identificado que no haver mudanas no cdigo-fonte ou em
funo transacional, sendo necessrio somente testar o sistema, ento deve-se utilizar
um percentual contemplando apenas a fase de testes. No caso do teste apontar a
necessidade de atualizar alguma funo transacional, no deve ser contado o esforo do
teste, mas sim o esforo abordado nesta seo, conforme as frmulas apresentadas nas
subsees seguintes.
4.6.1 Atualizao de Verso Linguagem de Programao

Nesta categoria encontram-se as demandas de atualizao de verso de
linguagem de programao de sistemas. As funes de dados no devem ser contadas.
Estas demandas devem ser dimensionadas de acordo com a frmula abaixo.
PF_ATUALIZAO_VERSO_LINGUAGEM = PF_ALTERADO x 0,30
14
________________________________________________________________________________
Cabe ressaltar que o redutor depende da linguagem da programao utilizada,
considerando o grau de complexidade de implementao da mudana de verso no
sistema em questo. Desta forma, recomenda-se fortemente a anlise do percentual
redutor da frmula de contagem pelo rgo.
4.6.2 Atualizao de Verso Browser

Nesta categoria encontram-se as demandas de atualizao de aplicaes Web
para executar em novas verses de um mesmo browser e para suportar a execuo em
mais de um browser. importante destacar que este tipo de procedimento usualmente
realizado quando necessrio resolver algum problema de incompatibilidade. As funes
de dados no devem ser contadas. Estas demandas devem ser dimensionadas de acordo
com a frmula abaixo.
PF_ATUALIZAO_VERSO_BROWSER = PF_ALTERADO x 0,30
Essas atualizaes podem implicar em manutenes em componentes especficos
da plataforma utilizada. Nesse caso, a demanda deve ser contada como componente
interno reusvel, descrita na seo 4.15 deste roteiro.
propostas para efeito de determinao do percentual adequado. Por exemplo, para
sistemas que j atendem ao padro W3C (World Wide Web Consortium) o esforo
menor, podendo usar, neste caso, um percentual diferente do citado acima. importante
ressaltar que os sistemas Web devem seguir o padro W3C, como recomendado na ePing. Caso seja necessrio fazer a adequao do sistema para atendimento ao padro
W3C, pode-se usar a frmula acima.
4.6.3 Atualizao de Verso Banco de Dados

Nesta categoria encontram-se as demandas de atualizao de verso do sistema
gerenciador de banco de dados. As funes de dados no devem ser contadas. Estas
demandas devem ser dimensionadas de acordo com a frmula abaixo.
PF_ ATUALIZAO_VERSO_BD = PF_ALTERADO x 0,30
15
________________________________________________________________________________
4.7 Manuteno em Interface

A manuteno em interface, denominada na literatura de manuteno cosmtica,
associada s demandas de alteraes de interface, por exemplo: fonte de letra, cores de
telas, logotipos, mudana de botes na tela, mudana de posio de campos ou texto na
tela. Tambm se enquadram nessa categoria as seguintes manutenes:
Mudanas de texto em mensagens de erro, validao, aviso, alerta, confirmao de
cadastro ou concluso de processamento;
Mudana em texto esttico de e-mail enviado para o usurio em uma
funcionalidade de cadastro. A demanda deve ser contada como manuteno em
interface na funcionalidade de cadastro;
Alterao de ttulo de um relatrio;
Alterao de labels de uma tela de consulta.
Nestes casos, a aferio do tamanho em pontos de funo das funes
transacionais impactadas ser realizada com a aplicao de um fator de reduo de modo
a considerar 20% da contagem de uma funo transacional de mais baixa complexidade
(3 PF), ou seja 0,6 PF, independentemente da complexidade da funcionalidade alterada.
Neste tipo de manuteno no so contadas funes de dados.
PF_INTERFACE = 0,6 PF x QUANTIDADE DE FUNES TRANSACIONAIS
IMPACTADAS
Est contemplada a atualizao da documentao das funcionalidades da
aplicao impactadas pela manuteno nas demandas desta categoria. Assim, a
documentao (documento de requisitos, documento de interface, prottipo, entre outros)
das funcionalidades alteradas deve ser atualizada. 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 1 Help: As demandas de projetos de desenvolvimento de sistemas
ou de manuteno de funcionalidades contemplam o desenvolvimento ou atualizao do
help da funcionalidade em questo, sendo tratada como uma atividade de documentao
no processo de software. No caso de demandas especficas de desenvolvimento ou
atualizao de help esttico de funcionalidades, estas podem ser enquadradas nesta
seo e poder ser usado um valor de multiplicao inferior a 0,6 PF conforme anlise de
impacto das mudanas propostas. Em caso de requisitos de usurio para o
desenvolvimento de funcionalidades de manuteno de help, deve-se contar a funo de
dados de help e as funcionalidades de manuteno de help (por exemplo: incluir help de
tela, consultar help de campo) de acordo com o CPM 4.3.
O percentual de multiplicao estimado, podendo ser reajustado conforme
4.8 Adaptao em Funcionalidades sem Alterao de Requisitos

Funcionais
So consideradas nesta categoria as demandas de manuteno adaptativa
associadas a solicitaes que envolvem aspectos no funcionais, sem alterao em
requisitos funcionais. Seguem alguns exemplos:
16
________________________________________________________________________________
Aumentar a quantidade de linhas por pgina em um relatrio;
Colocar paginao em um relatrio;
Limitar a quantidade de linhas por pgina em uma consulta existente;
Permitir excluses mltiplas em uma funcionalidade que antes s possibilitava a
excluso de um item;
Adaptao de uma funcionalidade para possibilitar a chamada por um webservice
ou para outro tipo de integrao com outros sistemas;
Replicao de funcionalidade: chamar uma consulta existente em outra tela da
aplicao;
Alterao na aplicao para adaptao s alteraes realizadas na interface com
rotinas de integrao com outros softwares, por exemplo, alterao em sub-rotinas
chamadas por este software;
Modificar o servidor a ser acessado em uma funcionalidade de download de
arquivo;
Adequar mensagem do sistema que em algumas telas apresenta Usurio No
est Habilitado a ver esta Pgina, para que passe a enviar uma mensagem mais
adequada ao fato do usurio no possuir mais uma sesso ativa e ainda estar
navegando no sistema. A demanda deve ser contada como manuteno adaptativa
considerando as funcionalidades impactadas. Observe que trata-se de mudana
em validao com regra de negcio no funcional.
Nestes casos, a aferio do tamanho em pontos de funo da funcionalidade ou
das funcionalidades que sofreram impacto deve considerar um fator de impacto (FI) sobre
o PF_ALTERADO, seguindo os conceitos do CPM 4.3, apresentados na seo 4.2.
PF_ADAPTATIVA = FI x PF_ALTERADO
FI (Fator de Impacto) pode variar conforme condies abaixo:
FI = 50% para funcionalidade de sistema desenvolvida ou mantida por meio de

um projeto de melhoria pela empresa contratada.

meio de um projeto de melhoria pela empresa contratada.
Deve-se destacar que alm da adequao das funcionalidades em questo, a

documentao do projeto de manuteno adaptativa deve ser realizada. Alm disso, caso
exista a documentao das funcionalidades impactadas, estas devero ser atualizadas,
caso contrrio, se for demandada a redocumentao dessas funcionalidades, deve-se
adicionar ao FI um fator de redocumentao de 15%, conforme descrito na seo 4.2.
Os percentuais de multiplicao so estimados, podendo ser reajustados conforme
17
________________________________________________________________________________
4.9 Apurao Especial

So funcionalidades executadas apenas uma vez para: corrigir problemas de
dados incorretos na base de dados das aplicaes ou atualizar dados em bases de dados
de aplicaes, detalhados na subseo 4.9.1; gerar um relatrio especfico ou arquivo
para o usurio por meio de recuperao de informaes nas bases da aplicao,
detalhados na subseo 4.9.2. A subseo 4.9.3 considera os casos de reexecuo de
uma apurao especial.
Caso a apurao seja de correo de dados devido a erros de funcionalidades de
aplicaes desenvolvidas pela contratada, observar as clusulas contratuais com relao
a garantias e prazos de correo.
Recomenda-se fortemente ao rgo contratante sempre solicitar formalmente para
a empresa contratada o armazenamento do script para permitir posterior reexecuo.
Cabe ressaltar que o rgo deve avaliar a complexidade das demandas tpicas de
apurao especial, podendo utilizar um percentual redutor nas frmulas descritas nas
subsees seguintes. Por exemplo, o redutor percentual pode ser aplicado em funo da
complexidade das demandas, documentao demandada e/ou do processo de
desenvolvimento utilizado.
4.9.1 Apurao Especial Base de Dados

Este tipo de apurao especial um projeto que inclui a gerao de procedimentos
para atualizao da base de dados. Deve-se destacar que estas funes so executadas
apenas uma vez, no fazendo parte da aplicao, visando a correo de dados incorretos
na base de dados da aplicao ou atualizao em funo de modificao da estrutura de
dados, por exemplo incluso de valor sim ou no no campo indicador de matriz
referente ao CNPJ. Normalmente, nesse tipo de atualizao so afetados mltiplos
registros. Nestes casos, considera-se a contagem de pontos de funo das
funcionalidades desenvolvidas. Geralmente, estas funcionalidades so classificadas como
Entradas Externas. Nesse caso, como artefato de homologao da demanda, deve ser
gerado um relatrio para validao do usurio.
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 Internos.
Foram identificados trs tipos de Apurao Especial - Base de Dados, cujas
frmulas de clculo so apresentadas a seguir:
a) Atualizao de Dados sem Consulta Prvia
PF_APURAO_BD = PF_INCLUDO
18
________________________________________________________________________________
b) Consulta Prvia sem Atualizao
Em alguns casos de Apurao Especial Base de Dados, o usurio solicita uma
consulta prvia das informaes. Deve-se ressaltar que essa consulta deve ser realizada
antes da construo da funcionalidade, no se trata de homologao. A consulta prvia
no definida pela empresa contratada, obrigatoriamente essa deve ser solicitada pelo
rgo contratante para a avaliao da viabilidade de implementar a Apurao Especial Base de Dados. De fato, uma prtica interessante para evitar informaes errneas na
base de produo dos sistemas. Esta consulta prvia, classificada como Consulta Externa
ou Sada Externa deve ser dimensionada considerando-se o tamanho da funcionalidade
em questo, conforme a frmula abaixo:
PF _CONSULTA_PRVIA = PF_INCLUDO
c) Atualizao de Dados com Consulta Prvia
Caso a Apurao Especial - Base de Dados seja solicitada aps uma demanda de
consulta prvia, deve-se aplicar um fator de 60% na frmula de contagem da Apurao
Especial - Base de Dados, seguindo a frmula abaixo.
PF_APURAO_BD_PS_CONSULTA_PRVIA = PF_INCLUDO x 0,60
4.9.2 Apurao Especial Gerao de Relatrios

Este tipo de apurao especial um projeto que inclui a gerao de relatrios em
uma ou mais mdias para o usurio. Em alguns casos, so solicitadas extraes de dados
e envio dos dados para outros sistemas. Caso, neste envio de dados, sejam requisitadas
atualizaes no sistema de origem, ento essas funes transacionais so Sadas
Externas, devido atualizao do Arquivo Lgico Interno.
Deve-se destacar que essas funes so executadas apenas uma vez, no
fazendo parte da aplicao. Nestes casos, considera-se contagem de pontos de funo
das funcionalidades desenvolvidas. Frequentemente, estas funcionalidades so
classificadas como Sadas Externas. Tambm podem ser classificadas como Consultas
Externas, caso no possuam clculos ou criao de dados derivados.
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.
PF_APURAO_RELATRIOS = PF_INCLUDO
19
________________________________________________________________________________
4.9.3 Apurao Especial Reexecuo

Em alguns casos, a empresa contratante pode ter interesse em executar uma
apurao especial mais de uma vez. Nestes casos, ela deve solicitar formalmente
contratada o armazenamento do script executado. Desta forma, se for solicitada a
reexecuo de uma apurao especial, esta deve ser dimensionada com a aplicao de
um fator redutor de 10% na contagem de pontos de funo da apurao especial em
questo, da seguinte maneira:
PF_REEXECUO_APURAO = PF_NO_AJUSTADO x 0,10
O percentual de multiplicao proposto no item acima estimado, podendo ser
reajustado conforme avaliao da base histrica dos servios realizados no rgo ou
entidade.
4.10 Atualizao de Dados

Em alguns casos, as demandas de correo de problemas em base de dados
esto associadas a atualizaes manuais (de forma interativa), diretamente no banco de
dados em um nico registro, e que no envolvem clculos ou procedimentos complexos.
So exemplos desse tipo de demanda, a atualizao do valor de um campo de uma
tabela cadastrado erroneamente ou a excluso de um registro de uma tabela.
Nestes casos, a aferio do tamanho em Pontos de Funo deve considerar 10%
do PF de uma Entrada Externa e os Tipos de Dados da Entrada Externa so todos os TD
considerados na funcionalidade campos atualizados e campos utilizados para a seleo
do registro.
PF_ATUALIZAO_BD = PF_INCLUDO x 0,10
Deve-se ressaltar que neste tipo de demanda no h gesto de configurao
(armazenamento de script, versionamento, etc) das atualizaes. Caso a contratante
identifique a necessidade de realizao de gesto de configurao das atualizaes no
banco de dados, ento a demanda ser classificada como Apurao Especial - Base de
Dados (subseo 4.9.1).
O percentual de multiplicao proposto acima estimado, podendo ser reajustado
4.11 Desenvolvimento, Manuteno e Publicao de Pginas Estticas

de Intranet, Internet ou Portal
Nesta seo so tratados desenvolvimentos e manutenes especficas em
pginas estticas de portais, intranets ou websites. As demandas desta seo abrangem
a publicao de pginas Web com contedo esttico. Por exemplo: criao de pgina
HTML, atualizao de menu esttico, atualizao de texto ou banner estticos em pginas
HTML existentes.
20
________________________________________________________________________________
Caso o desenvolvimento de pginas estticas esteja contido em um projeto de
desenvolvimento, ento elas sero contabilizadas no projeto de desenvolvimento e no
devem ser mensuradas em separado. Ou seja, esta seo 4.11 se aplica quando ocorrer
a demanda exclusivamente para o desenvolvimento ou manuteno de pginas estticas.
Estas demandas so consideradas como desenvolvimento de consultas. Nestes
casos, considera-se 20% dos pontos de funo das consultas desenvolvidas. Cada
pgina contada como uma consulta. As consultas so consideradas consultas externas
simples (3 PF). Ou seja, 0,6 PF por cada pgina desenvolvida ou mantida, de acordo com
a frmula abaixo:
PF_PUBLICAO = 0,6 PF x Quantidade de Pginas Alteradas ou Includas
As demandas de criao de logomarcas ou identidade visual, alm de outras
demandas de criao de arte, associadas rea de Comunicao Social, no so
enquadradas nessa categoria. Tais demandas no se referem a contratos de prestao de
servios de desenvolvimento e manuteno de sistemas, portanto no so consideradas
neste roteiro.
recomendada a construo de portais com ferramentas que apoiem a construo
de contedo pelo usurio, os chamados Gerenciadores de Contedo, de modo a
minimizar as demandas de criao de pginas estticas.
4.12 Manuteno de Documentao de Sistemas Legados

Nesta seo so tratadas demandas de documentao ou atualizao de
documentao de sistemas legados. Observe que o desenvolvedor deve realizar uma
engenharia reversa da aplicao para gerar a documentao. Para este tipo de projeto foi
definido o fator de impacto de 25% dos pontos de funo da aplicao em questo,
considerando a fase de requisitos e a gerao de artefatos associados a requisitos,
conforme a frmula abaixo.
PF_DOCUMENTAO = PF_NO_AJUSTADO x 0,25
Caso a demanda seja a gerao de artefatos de documentao de outras fases do
processo de desenvolvimento, deve-se considerar um outro fator de impacto,
considerando as fases do ciclo de vida e os demais artefatos a serem gerados. As
premissas utilizadas devem ser definidas nas clusulas contratuais e documentadas no
documento de estimativas do projeto.
21
________________________________________________________________________________
4.13 Verificao de Erros

As verificaes de erro ou anlise e soluo de problemas so as demandas
referentes a todo comportamento anormal ou indevido apontado pelo cliente nos sistemas
aplicativos. Neste caso, a equipe de desenvolvimento da contratada se mobilizar para
encontrar as causas do problema ocorrido. Se for constatado algum erro de sistema, a
demanda ser atendida como manuteno corretiva (seo 4.4).
Entretanto, uma vez no constatado o problema apontado pelo cliente ou o mesmo
for decorrente de regras de negcio implementadas ou utilizao incorreta das
funcionalidades, ser realizada a aferio do tamanho em pontos de funo das
funcionalidades verificadas que o cliente reportou erro. Caso no exista documentao de
testes disponvel dessas funcionalidades verificadas, ser considerado 20% do tamanho
funcional dessas funcionalidades com solicitao de anlise pelo rgo contratante,
segundo a frmula abaixo:
PF_VERIFICAO = PF_Funcionalidade_Reportada_Com_Erro x 0,20
Caso exista documentao de testes das funcionalidades verificadas, ento ser
considerado 15% (mesmo percentual da fase de Testes, conforme Tabela 7) do tamanho
funcional das funcionalidades analisadas, segundo a frmula abaixo:
PF_VERIFICAO = PF_Funcionalidade_Reportada_Com_Erro x 0,15
importante ressaltar que a demanda de verificao de erros deve ser associada a
uma funcionalidade especfica. Os casos de sistema fora do ar por conta de problemas de
rede ou banco de dados devem ser tratados como servios de suporte e no servios de
desenvolvimento e manuteno de sistemas. Esses servios de suporte no fazem parte
do escopo desse roteiro de mtricas, no se aplicando verificao de erros nestes casos.
4.14 Pontos de Funo de Teste

Muitas vezes, em projetos de manuteno, o conjunto de funes transacionais a
serem testadas maior do que a quantidade de funes a serem implementadas, isto ,
alm das funcionalidades que so afetadas diretamente pelo projeto de manuteno,
outras precisam ser testadas [NESMA, 2009]. O tamanho das funes a serem apenas
testadas deve ser aferido em Pontos de Funo de Teste (PFT). No considerar as
funcionalidades includas, alteradas ou excludas do projeto de manuteno na contagem
de Pontos de Funo de Teste.
A contagem de PFT ser o somatrio dos tamanhos em pontos de funo das
funes transacionais envolvidas no teste:
PFT = Somatrio dos Tamanhos das Funes Transacionais Testadas
22
________________________________________________________________________________
A converso do PFT em ponto de funo deve ser feita de acordo com a frmula
abaixo:
PF_TESTES = PFT x 0,15
importante ressaltar que no caso de uma funo ser testada vrias vezes, com
cenrios diferentes, a funo s pode ser contada uma vez. Outra observao que as
funes testadas, consideradas no PFT, devem ser documentadas pela contratada
considerando-se a documentao de testes definida no processo de desenvolvimento da
contratante. Observe que estas funes faro parte do escopo do projeto de manuteno.
4.15 Componente Interno Reusvel

Em alguns casos so demandadas manutenes em componentes especficos de
uma aplicao e estes so reusados por vrias funcionalidades da aplicao. Por
exemplo, uma mudana em uma rotina de validao de um CPF usada em vrias
funcionalidades de cadastro. Se considerarmos o mtodo de contagem de projetos de
melhoria do CPM, seriam contadas todas as funcionalidades impactadas por essa
mudana.
No entanto, este roteiro prope que o componente, o qual dever ser testado, seja
considerado como um processo elementar independente e contado como uma
funcionalidade. Alm disso, as funcionalidades da aplicao que necessitem de teste
devem ser requisitadas pela contratante e dimensionadas por meio da mtrica Pontos de
Funo de Teste proposta na seo 4.14.
PF_COMPONENTE = PF_NO_AJUSTADO
Seguem alguns exemplos de manuteno de componentes:
Alterao de valores de elementos internos de configurao que afetem o
comportamento ou a apresentao do sistema de forma geral, tais como pginas de
estilos (arquivos CSS de sistemas Web), arquivos com mensagens de erro, arquivos de
configurao de sistema, arquivos de internacionalizao;
Mudana em tpico de um menu de um sistema em PHP que aparece em todas
as telas da aplicao. A contagem pode ser realizada considerando o componente
Apresentar Menu.
23
________________________________________________________________________________
5. Orientaes Complementares para Contagem

Este captulo tem como propsito apresentar as diretrizes de contagem de pontos
de funo em relao ao tema Mltiplas Mdias, cuja abordagem reconhecida pelo
IFPUG. As definies apresentadas tm como base o artigo Considerations for Counting
with Multiple Media Release 1.1 publicado pelo IFPUG [IFPUG, 2010a].
5.1 Contagem de Pontos de Funo com Mltiplas Mdias

A contagem de PF de funcionalidades entregues em mais de uma mdia, na
aplicao das regras de contagem de pontos de funo definidas no CPM, tem levado a
duas abordagens alternativas, a saber: single instance e multiple instance.
importante enfatizar que o IFPUG reconhece ambas abordagens, single instance
e multiple instance, para a aplicao das regras definidas no CPM. A determinao da
contagem de PF seguindo a abordagem multiple instance ou single instance depende da
avaliao do Escritrio de Mtricas da instituio.
As estimativas e contagens de PF abordadas neste documento so baseadas em
multiple instance, com exceo dos casos de consultas em .pdf, .doc, .xls e consultas
idnticas em tela e papel, que sero consideradas uma nica funcionalidade.
A seguir so descritos os termos comuns definidos pelo IFPUG [IFPUG, 2010a]:
Canal: tambm refere-se a mdia. Mltiplos canais sinnimo de mltiplas
mdias.
Mdia: descreve a maneira como os dados ou informaes se movimentam
para dentro e para fora de uma fronteira de 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.
Mltiplas Mdias: quando a mesma funcionalidade entregue em mais de uma
mdia. Frequentemente, apenas uma mdia requisitada para um usurio
especfico em um determinado momento, por exemplo consulta de extrato bancrio
via Internet como oposto a consulta de extrato bancrio via terminal do banco.
Multi-Mdia: quando mais de uma mdia necessria para entregar a
funcionalidade , 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 o vdeo.
Abordagem Single Instance: esta abordagem no reconhece que a mdia
utilizada na entrega da funo transacional uma caracterstica de diferenciao
na identificao da unicidade da funo transacional. Se duas funes entregam a
mesma funcionalidade usando mdias diferentes, elas so consideradas a mesma
funcionalidade em uma contagem de pontos de funo.
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.
24
________________________________________________________________________________
Os cenrios descritos nas sees seguintes no representam uma lista completa
de situaes de mltiplas mdias. O entendimento dos exemplos a seguir facilitar o
entendimento de outros cenrios envolvendo mltiplas mdias.
Este roteiro deve ser atualizado considerando a publicao de novas diretrizes do
IFPUG e novos cenrios que emergiro nas contagens de PF de projetos dos rgos e
entidades do SISP.
5.1.1 Cenrio 1: Mesmos dados apresentados em tela e impressos

Neste cenrio, uma aplicao apresenta uma informao em uma consulta em tela.
A mesma informao pode ser impressa, caso requisitado pelo usurio, na tela em
questo.
Nesses casos, sugere-se a abordagem single instance, considerando que dados
idnticos sendo apresentados em tela e em relatrio impresso devem ser contados como
uma nica funo. Caso as lgicas de processamento da consulta em tela e do relatrio
em papel sejam distintas, o processo elementar no nico e, portanto, a funcionalidade
ser contada duas vezes (multiple instance). Neste caso, duas funes so contadas:
apresentao de dados em tela e apresentao de dados impressos.
5.1.2 Cenrio 2: Mesmos dados de sada como dados em arquivo e

relatrio impresso
Uma aplicao grava dados em um arquivo de sada e imprime um relatrio com
informaes idnticas s gravadas no arquivo.
Nesses casos, sugere-se a utilizao da abordagem single instance considerando
que os dados impressos e os dados apresentados no arquivo de sada sejam idnticos e
que a ferramenta de desenvolvimento apoie a gerao dessas mltiplas sadas. Assim,
apenas uma funcionalidade ser includa na contagem de pontos de funo. Caso as
lgicas de processamento da gerao do arquivo de sada e do relatrio em papel sejam
distintas, o processo elementar no nico e, portanto, a funcionalidade ser contada
duas vezes. Alm disso, se a gerao das mltiplas sadas no seguirem o padro da
ferramenta de desenvolvimento e tiverem que ser customizadas para o cliente, ento ser
utilizada a abordagem multiple instance.
5.1.3 Cenrio 3: Mesmos dados de entrada batch e on-line

Uma informao pode ser carregada na aplicao por meio de dois mtodos:
arquivo batch e entrada on-line. O processamento do arquivo batch executa validaes
durante o processamento, da mesma forma que o processamento da entrada on-line
tambm executa validaes das informaes. Neste caso, sugere-se a utilizao da
abordagem multiple instance, que conta duas funcionalidades: a entrada de dados batch e
a entrada de dados on-line. Geralmente, a lgica de processamento utilizada nas
validaes em modo batch diferente da lgica de processamento das validaes nas
entradas de dados on-line.
5.1.4 Cenrio 4: Mltiplos canais de entrega da mesma funcionalidade

Uma funcionalidade deve ser disponibilizada em mltiplos canais, por exemplo:
consulta de dados em pgina Web e consulta de dados no telefone celular. Neste caso,
sugere-se a abordagem multiple instance, que conta duas funcionalidades: consulta de
dados na Web e consulta de dados via celular.
25
________________________________________________________________________________
Considera-se que a funcionalidade desenvolvida duas vezes, uma para cada
canal de sada. Algumas vezes, so at projetos de desenvolvimento distintos, um projeto
relativo ao sistema Web e outro para o sistema via celular. Lembrando que caso o projeto
seja claro o suficiente para dizer que o desenvolvimento o mesmo, poder ser utilizada
a abordagem single instance.
5.1.5 Cenrio 5: Relatrio em mltiplos formatos

Um relatrio deve ser entregue em diferentes formatos, por exemplo: um arquivo
html e um arquivo com valores separados por vrgula (.csv).
Nestes casos, conforme sugerido na abordagem multiple instance, considera-se a
ferramenta utilizada na gerao dos relatrios. Se a equipe de desenvolvimento precisar
desenvolver o relatrio nos dois formatos na ferramenta em questo, sero contadas duas
funcionalidades. No entanto, se a ferramenta de desenvolvimento suportar um gerador de
relatrios que o usurio visualize o relatrio em tela e o gerador permita ao usurio
imprimir o relatrio, salvar em html ou salvar no formato de valores separados por vrgula,
ento se contar apenas uma vez, observando que a funcionalidade ser da ferramenta e
no da aplicao.
6. Consideraes Especiais para Planejamento e Acompanhamento de

Projetos
Este captulo tem como propsito apresentar diretrizes para o planejamento e
acompanhamento de projetos com o auxlio da mtrica Ponto de Funo e de tcnicas
relacionadas. Com base nesta finalidade descrito um processo de estimativas de
projetos de software aderente rea de processo de Planejamento de Projeto do CMMI
(Capability Maturity Model Integration). Nesse contexto, so apresentados: o mtodo
Contagem Estimativa de Pontos de Funo (CEPF) para estimar o tamanho dos projetos
de software em PF, o modelo simplificado de estimativas para estimar o esforo dos
projetos em homem-hora (HH) e a frmula de Capers Jones para estimar os prazos dos
projetos. Tambm so apresentadas recomendaes para o gerenciamento de: mudanas
de requisitos, projetos cancelados e progresso de projetos, e consideraes sobre
reduo de cronograma e fator de criticidade de solicitao de servios.
6.1 Diretrizes para Planejamento: Estimativas de Projetos de Software

Esta seo define mtodos para estimativas de projetos de software. A Figura 2
ilustra um processo de estimativas de projetos de software, descrito nos pargrafos
seguintes.
26
________________________________________________________________________________
Coletar e Analisar
Requisitos Iniciais
Estimar Esforo
Banco de Dados
Histrico de Projetos
da organizao
Estimar Cronograma
Estimar Custo
Documentar
Estimativas e
Premissas
Documentar
Acompanhamento
Documentar
Resultados finais
e Lies Aprendidas
Reestimar,conforme
necessidade
Estimar Tamanho
Estimar Recursos
Computacionais Crticos
Analisar e Aprovar
Estimativas
Acompanhar
Estimativas
Calibrar e Melhorar
o Processo
Figura 2: Processo de Estimativas de Projetos de Software [Hazan, 2008]
O principal insumo (artefato de entrada) para um processo de estimativas o

documento de requisitos. Como as estimativas devem ser realizadas no incio do
processo de desenvolvimento de software, ento o artefato a ser utilizado um
documento inicial de requisitos, por exemplo, o documento de viso ou formalizao
simples de requisitos. O estimador deve analisar os requisitos para garantir a qualidade e
ento estimar o tamanho do projeto de software. O prximo passo a derivao das
estimativas de esforo, prazo (cronograma), custo (oramento) com base na estimativa de
tamanho e nos dados histricos de projetos concludos da organizao, assim como o
estabelecimento da estimativa de recursos computacionais crticos e dos recursos da
equipe a ser alocada ao projeto. Neste ponto, as principais estimativas foram geradas e
precisam ser documentadas. As premissas e suposies utilizadas na gerao das
estimativas, dentre as quais: complexidade do projeto, plataforma de desenvolvimento,
tipo do projeto, percentual de evoluo de requisitos, tambm devem ser documentadas
[Hazan, 2008].
A realizao das estimativas por um analista de mtricas que no atue na equipe
do projeto, constitui uma prtica recomendada. O analista de mtricas deve analisar
tambm a consistncia da documentao utilizada na estimativa. No decorrer do processo
de desenvolvimento, as estimativas devem ser acompanhadas conforme o refinamento
dos requisitos. O projeto deve ser reestimado aps a fase de requisitos, quando for
gerada a especificao de casos de uso, e sempre que ocorrerem mudanas
27
________________________________________________________________________________
significativas nos requisitos funcionais ou no funcionais. Quando o projeto concludo,
deve-se aferir e documentar o tamanho, prazo, custo, esforo e recursos realizados,
assim como outros atributos relevantes do projeto, visando a coleta de dados para a
melhoria do processo de estimativas. As lies aprendidas tambm devem ser
documentadas [Hazan, 2008].
Portanto, para os contratos de projetos de software, baseados na mtrica Ponto de
Funo, as estimativas devem ser realizadas em, no mnimo, trs marcos do processo de
desenvolvimento de software, a saber:
Estimativa inicial: realizada aps o fechamento do escopo do projeto.
Geralmente baseada em um documento inicial de requisitos como, por exemplo,
o documento de viso. Constitui uma boa prtica a previso de evoluo de
requisitos, especialmente em projetos de desenvolvimento de mdio ou grande
porte. Nessa etapa importante destacar os seguintes conceitos na rea de
estimativas:
- Uma Estimativa obtida por meio de uma atividade tcnica, utilizando
mtodos de estimativas. No deve sofrer interferncias polticas;
- A Meta um desejo, em funo de necessidades de negcio, estabelecida
politicamente;
- Um Compromisso um acordo da gerncia com as equipes tcnicas para
alcanar uma meta [Parthasarathy, 2007].
Em um cenrio ideal, os resultados da estimativa atendem s metas de
negcio. Quando este cenrio no real, fundamental a reduo de escopo do
projeto, de modo que a meta se adapte aos resultados da estimativa.
Contagem de Pontos de Funo de Referncia: realizada aps o aceite dos
requisitos. Geralmente, leva em considerao a especificao dos casos de uso e
regras de negcio da aplicao. Pode ser aplicada a contagem estimada ou a
detalhada.
Contagem de Pontos de Funo Final: realizada aps a homologao da
aplicao. Esta contagem considera as funcionalidades efetivamente entregues
para o usurio pela aplicao. Neste caso, deve ser aplicada a contagem
detalhada.
Para fins de faturamento, realizado durante o desenvolvimento, deve-se considerar
a Contagem de Referncia e posteriormente realizar os ajustes no faturamento aps a
Contagem Final.
importante ressaltar que as mudanas de requisitos tambm sero consideradas
no tamanho do projeto a ser faturado (ver subseo 6.2.1). Alm disso, se estas
mudanas forem significativas, maiores que a evoluo de requisitos (scope creep)
prevista na estimativa inicial, o prazo do projeto deve ser reestimado. Toda mudana de
requisito deve passar por uma anlise de impacto entre contratante e contratada.
As subsees seguintes apresentam os mtodos de estimativas de tamanho,
prazo, custo e esforo a serem utilizados nos projetos de software em contratos.
28
________________________________________________________________________________
6.1.1 Contagem Estimativa de Pontos de Funo (CEPF)

Antes de definir o mtodo de estimativas Contagem Estimativa de Pontos de
Funo (CEPF), importante destacar que estimar significa utilizar o mnimo de tempo e
esforo para se obter um valor aproximado dos pontos de funo do projeto de software
investigado [Meli, 1999]. Assim, recomendvel sempre fazer uma distino entre os
termos e conceitos: contagem de pontos de funo e estimativa de pontos de funo.
Contagem de Pontos de Funo: significa medir o tamanho do software por
meio do uso das regras de contagem do IFPUG [IFPUG, 2010b];
Estimativa de Pontos de Funo: significa fornecer uma avaliao aproximada
do tamanho de um software utilizando mtodos diferentes da contagem de pontos de
funo do IFPUG.
O mtodo CEPF visa aferir o tamanho em PF de maneira simplificada, com base
no conhecimento dos requisitos iniciais do projeto [Hazan, 2005]. A CEPF foi definida com
base nas diretrizes adotadas no mtodo Contagem Estimada de Pontos de Funo da
NESMA [NESMA, 2005]. A diferena que o mtodo da NESMA no recomenda a anlise
das funes identificadas, considerando todas as funes de dados identificadas com
complexidade Baixa e as funes transacionais com complexidade Mdia. A CEPF prope
a anlise das funcionalidades identificadas, e caso no seja possvel determinar a
complexidade, ento so adotadas as diretrizes do mtodo Contagem Estimada da
NESMA. A CEPF tambm apresenta algumas dicas para ajudar um estimador no
mapeamento dos requisitos iniciais nos tipos funcionais da Anlise de Pontos de Funo.
Segue a descrio da CEPF [Hazan, 2005].
Primeiramente, os requisitos funcionais iniciais documentados nas propostas
comerciais, nos documentos de viso, formalizao simples de requisitos ou em qualquer
especificao inicial do sistema do usurio so mapeados nos tipos funcionais da Anlise
de Pontos de Funo: Arquivo Lgico Interno (ALI), Arquivo de Interface Externa (AIE),
Entrada Externa (EE), Consulta Externa (CE) e Sada Externa (SE) (Figura 3).
Posteriormente, os pontos de funo so associados a cada funo identificada,
baseando-se nas tabelas de complexidade e de contribuio funcional do CPM (Tabela 1).
O estimador deve realizar uma leitura do documento inicial de requisitos, buscando
informaes relevantes para a identificao de processos elementares. O processo
elementar definido como a menor unidade de atividade significativa para o usurio. O
processo elementar deve ser completo em si mesmo, independente e deixar a aplicao
em um estado consistente [IFPUG, 2010b]. Em outras palavras, os processos
elementares so funes transacionais independentes, isto , funes sequenciais
pertencem a um mesmo processo elementar e funes independentes constituem
processos elementares diferentes.
29
________________________________________________________________________________
Documentao
do Software
Abstrao orientada a dados

Usurios
Identificao dos itens da APF
Aplicao
Transaes
(EEs, CEs,
SEs)
Pontos de Funo
(nmeros)
Mapeando em nmeros
Dados
Internos (ALIs)
Outras
Aplicaes
Dados
Externos
(AIEs)
Figura 3: Modelo Lgico da Anlise de Pontos de Funo
Uma vez identificado o processo elementar, o estimador deve buscar o

entendimento deste para classific-lo em Entrada Externa, Consulta Externa ou Sada
Externa. Adicionalmente, o estimador deve descobrir os dados associados ao processo
elementar, visando a determinao da complexidade funcional da funo identificada.
Caso no seja possvel a identificao da complexidade da funcionalidade em questo,
recomenda-se a utilizao da complexidade Mdia. Na anlise do processo elementar
tambm so identificados os grupos de dados lgicos da aplicao, que so classificados
como Arquivos Lgicos Internos ou Arquivos de Interface Externa. Caso no seja possvel
a identificao da complexidade da funo de dados em questo, recomenda-se a
utilizao da complexidade Baixa. importante ressaltar que se o estimador identificar
mais de um Registro Lgico no Arquivo Lgico Interno, recomenda-se utilizar a
complexidade Mdia.
A seguir so apresentadas dicas para ajudar no mapeamento dos requisitos
funcionais da aplicao nos tipos funcionais da APF. As necessidades e funcionalidades
especificadas para o projeto, contidas no documento inicial de requisitos, devem ser
enquadradas em uma das seguintes tabelas:
Tabela 2 - Contagem dos Arquivos Lgicos Internos (ALI): banco de dados lgico
da aplicao (tabelas e arquivos mantidos pela aplicao).
Consideraes: Identifique os grupos de dados lgicos de aplicao nos modelos
de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos
documentos de requisitos (documento de viso, relao de casos de uso, etc). No
considere arquivos fsicos, arquivos de ndices, arquivos de trabalho e tabelas de
relacionamento sem atributos prprios (tabelas que existem para quebrar o
relacionamento m x n e apenas transportam as chaves estrangeiras). As entidades fracas
tambm no so consideradas um ALI. Se possvel, tente descobrir os atributos lgicos,
campos reconhecidos pelo usurio, e subgrupos de dados existentes para obter a
complexidade funcional, segundo as regras de contagem do CPM. Caso no seja
30
________________________________________________________________________________
possvel, a experincia tem mostrado que a maioria dos ALI dos sistemas so de
complexidade Baixa.
N ALI Baixa:
X 7 PF
N ALI Mdia:
X 10 PF
N ALI Alta:
X 15 PF
Total PF:
Tabela 2: Identificao dos Arquivos Lgicos Internos da Aplicao
Tabela 3 - Contagem de Arquivos de Interface Externa (AIE): banco de dados de

outras aplicaes, apenas referenciados pela aplicao que est sendo estimada
(tabelas e arquivos mantidos por outra aplicao).
Consideraes: Identifique os grupos de dados lgicos de outras aplicaes
referenciados pela aplicao que est sendo estimada. Frequentemente, o
referenciamento de dados ocorre para a validao de informaes em cadastros ou
consultas. Algumas vezes, relatrios ou consultas referenciam dados externos de outras
aplicaes, tambm considerados AIE. No so considerados AIE arquivos fsicos,
arquivos de ndice, arquivos de trabalho, tabelas de relacionamento sem atributos
prprios e entidades fracas.
Geralmente, os AIE dos sistemas possuem a classificao de complexidade Baixa,
porque so considerados para a determinao da complexidade funcional do AIE apenas
os atributos referenciados pela aplicao que est sendo contada.
N AIE Baixa:
X 5 PF
N AIE Mdia:
X 7 PF
N AIE Alta:
X 10 PF
Total PF:
Tabela 3: Identificao dos Arquivos de Interface Externa da Aplicao
Tabela 4 - Contagem de Entradas Externas (EE): funcionalidades que mantm os

Arquivos Lgicos Internos (ALI) ou alteram o comportamento da aplicao.
Consideraes: Identifique as funcionalidades de manuteno de dados. Conte
separadamente a incluso, alterao e excluso de dados, isto , cada funo
independente de incluso, alterao ou excluso deve ser contada separadamente. A
aplicao possui funes de entrada de dados que alteram o comportamento dela, por
exemplo: processamentos batch ou processamento de informaes de controle? Caso
positivo, estas funes tambm devem ser identificadas como Entradas Externas. Se
voc no possui conhecimento sobre o processo elementar (funcionalidade analisada),
considere as Entradas Externas identificadas com complexidade Mdia.
31
________________________________________________________________________________
N EE Baixa:
X 3 PF
N EE Mdia:
X 4 PF
N EE Alta:
X 6 PF
Total PF:
Tabela 4: Identificao das Entradas Externas da Aplicao
Tabela 5 - Contagem de Consultas Externas (CE): funcionalidades que apresentam

informaes para o usurio sem a utilizao de clculos ou algoritmos. So os processos
elementares do tipo l - imprime, l - apresenta dados, incluindo consultas, relatrios,
gerao de arquivos pdf, xls, downloads, entre outros.
Consideraes: Voc est desenvolvendo uma funo para apresentar
informaes para o usurio: uma consulta, relatrio, listbox, download, gerao de um
arquivo, gerao de arquivo pdf, xls? Esta funo no possui clculos ou algoritmos para
derivao dos dados referenciados nem altera um Arquivo Lgico Interno e nem muda o
comportamento do sistema? Caso positivo, estas funes devem ser identificadas como
Consultas Externas. Se voc no possui conhecimento sobre o processo elementar
(funcionalidade analisada), considere as Consultas Externas com complexidade Mdia.
N CE Baixa:
X 3 PF
N CE Mdia:
X 4 PF
N CE Alta:
X 6 PF
Total PF:
Tabela 5: Identificao das Consultas Externas da Aplicao
Tabela 6 - Contagem de Sadas Externas (SE): funcionalidades que apresentam

informaes para o usurio com utilizao de clculos ou algoritmos para derivao de
dados ou atualizao de Arquivos Lgicos Internos ou mudana de comportamento da
aplicao. So as consultas ou relatrios com totalizao de dados, relatrios estatsticos,
grficos, gerao de arquivos com atualizao log, downloads com clculo de percentual,
entre outros.
Consideraes: Voc est desenvolvendo uma funcionalidade para apresentar
informaes para o usurio: uma consulta ou relatrio com totalizao de dados, etiquetas
de cdigo de barras, grficos, relatrios estatsticos, download com percentual calculado,
gerao de arquivo com atualizao de log? Caso positivo, estas funes devem ser
identificadas como Sadas Externas. Observe que esta funo deve ter clculos ou
algoritmos para processar os dados referenciados nos arquivos lgicos ou atualizar
campos (normalmente indicadores) nos arquivos ou mudar o comportamento da
aplicao. Se voc no possui conhecimento sobre o processo elementar (funcionalidade
analisada), considere as Sadas Externas com complexidade Mdia.
32
________________________________________________________________________________
N SE Baixa:
X 4 PF
N SE Mdia:
X 5 PF
N SE Alta:
X 7 PF
Total PF:
Tabela 6: Identificao das Sadas Externas da Aplicao
A estimativa de tamanho do projeto em PF deve ser gerada com a totalizao dos

PF obtidos nas Tabelas 2, 3, 4, 5 e 6.
A frmula de contagem ou de estimativa de pontos de funo para projetos de
desenvolvimento a seguinte:
PF_DESENVOLVIMENTO = PF_INCLUIDO + PF_CONVERSO
contagem de pontos de funo de projetos de desenvolvimento, conforme descrito na
seo 3.3.
6.1.2 Estimativa de Esforo de Projetos de Software

Uma vez que o tamanho do projeto foi estimado em pontos de funo, o prximo
passo estimar o esforo de desenvolvimento do projeto, bem como sua distribuio
pelas fases do ciclo de vida do desenvolvimento do software. A Engenharia de
Software possui vrios modelos para estimar esforo de projetos de software, baseados
em pontos de funo, sendo o Modelo Simplificado de Estimativas [Vazquez, 2012] e o
Modelo COCOMO II [Boehm, 2009] os mais utilizados. Neste roteiro adotado o Modelo
Simplificado de Estimativas.
O Modelo Simplificado de Estimativas consiste em obter um ndice de
produtividade em horas/PF para o projeto especfico em questo, e ento multiplicar o
tamanho em PF do projeto pelo ndice de produtividade, conforme a frmula [Vazquez,
2012]:
Esforo (horas) = Tamanho (PF) x ndice de Produtividade (HH/PF)
O ndice de produtividade depende de diversos atributos dos projetos, dentre
outros: plataforma tecnolgica, complexidade do domnio, segurana, desempenho,
usabilidade, tamanho do projeto, tipo de manuteno, desenvolvimento de componentes.
Cada rgo ou entidade dever possuir sua prpria tabela de produtividade para
cada linguagem, considerando-se sempre dados histricos dos projetos j realizados.
33
________________________________________________________________________________
6.1.2.1 Distribuio de Esforo por Fase do Projeto

O prximo passo a definio da distribuio de esforo pelas macroatividades
(fases) do projeto, visando definir o valor agregado ao projeto aps cada fase do ciclo de
vida.
A Tabela 7 uma sugesto de macroatividades e distribuio de esforo proposta
neste roteiro. Ressaltamos que o rgo pode definir outras macroatividades e subdividilas para melhor aderncia sua metodologia e aos marcos de entrega. Alm disso, os
percentuais de esforo sugeridos podem variar de acordo com o tipo de projeto e o
processo de desenvolvimento utilizado no rgo. Nesses casos, as macroatividades e
distribuio de esforo devem estar documentadas na metodologia do rgo (especificada
contratualmente) ou formalizadas diretamente no contrato.
Macroatividades do Processo de
Desenvolvimento de Software
Percentual de
esforo (%)
Engenharia de Requisitos
25%
Design / Arquitetura
10%
Implementao
40%
Testes
15%
Homologao
5%
Implantao
5%
Tabela 7: Distribuio de Esforo por Macroatividades do Projeto
6.1.3 Estimativa de Prazo de Projetos de Software

As estimativas de prazo no so lineares com o tamanho do projeto. O melhor
tempo de desenvolvimento (onde h uma melhor relao custo x benefcio de alocao de
recursos e menor prazo de desenvolvimento, dado o tamanho de um projeto especfico),
conforme frmula descrita abaixo, sugerido e utilizado nas estimativas de prazo deste
roteiro.
Jones [Jones, 2007] prope uma frmula para o clculo do melhor tempo de
desenvolvimento, denominado Td e de Regio Impossvel (RI) de desenvolvimento
(Figura 4). Na Regio Impossvel (RI), a adio de mais recursos ao projeto no implicar
em reduo no prazo. Note que a curva mostra que quanto menor o prazo almejado para
a concluso do projeto, maior ser o esforo requerido e, consequentemente, maior o
custo do projeto. O aumento do esforo para reduzir o prazo acontece atravs da
realizao de horas extras e da incluso de pessoal adicional, gerando retrabalho. No
entanto, a reduo de prazo tem um limite, como demonstra a Regio Impossvel da
Figura 4.
O mtodo utilizado para estimar o prazo dos projetos (Td) baseado na frmula de Capers Jones
[Jones, 2007]. Esta estima o prazo, baseando-se no tamanho do projeto em pontos de funo, da seguinte
maneira:
Td = V t
Onde:
Td: prazo de desenvolvimento
V: tamanho do projeto em pontos de funo
t: o expoente t definido de acordo com a Tabela 8
34
________________________________________________________________________________
Figura 4: Relao entre a Estimativa de Prazo e de Esforo
Tipo de Sistema
Expoente t
Sistema Comum Mainframe (desenvolvimento de

sistema com alto grau de reuso ou manuteno evolutiva)
0,32 a 0,33
Sistema Comum WEB ou Cliente Servidor
0,34 a 0,35
Sistema OO (se o projeto OO no for novidade para

equipe, no tiver o desenvolvimento de componentes
reusveis, considerar sistema comum)
0,36
Sistema Cliente/Servidor (com alta complexidade

arquitetural e integrao com outros sistemas)
0,37
Sistemas Gerenciais complexos com muitas integraes,

Datawarehousing, Geoprocessamento, Workflow
0,39
Software Bsico, Frameworks, Sistemas Comerciais
0,40
Software Militar (ex: Defesa do Espao Areo)
0,45
Tabela 8: Expoente t por Tipo de Projeto
importante destacar que o mtodo s deve ser aplicado para projetos com mais
de 100 PF. Caso o rgo possua dados histricos de projetos, ento este deve trabalhar
com seus dados histricos e modelos de estimativas. Caso o projeto seja menor, o prazo
deve ser obtido por meio da definio de prazo mximo por tamanho funcional com base
em dados histricos do rgo, conforme a Tabela 9.
35
________________________________________________________________________________
Prazo mximo (em dias teis)

Tamanho do Projeto
Projetos
Complexidade
Baixa
Projetos
Complexidade
Mdia
At 10 PF
9 dias
15 dias
De 11 PF a 20 PF
18 dias
30 dias
De 21 PF a 30 PF
27 dias
45 dias
De 31 PF a 40 PF
36 dias
60 dias
De 41PF a 50 PF
45 dias
75 dias
De 51 PF a 60 PF
54 dias
90 dias
De 61 PF a 70 PF
63 dias
105 dias
De 71 PF a 85 PF
70 dias
110 dias
De 86 PF a 99 PF
79 dias
110 dias
Tabela 9: Estimativa de Prazo de Projetos menores que 100 PF
Observao: Para os projetos de baixa complexidade foi considerada a produtividade de

7 hh/PF. Para projetos de mdia complexidade foi considerada a produtividade de 12
hh/PF, sendo o limite 110 dias teis, equivalentes a 5 meses,que o resultado da frmula
de Capers Jones para projetos de 100 PF - Td = 100 0,35 = 5 meses. No caso de sistemas
com complexidade alta, deve haver uma avaliao do rgo.
O prazo calculado considera todo o ciclo de vida do projeto, desde a fase de
requisitos at a implantao. Assim, caso a estimativa tenha sido realizada ao final da
fase de requisitos, descontar do prazo restante o tempo gasto com a fase de requisitos.
Caso seja necessrio receber o projeto em um prazo menor que o calculado,
recomenda-se propor um processo de desenvolvimento incremental, priorizando
funcionalidades em cada iterao de acordo com a necessidade dele. Caso, ainda assim,
a estimativa no atenda s necessidades do cliente, pode-se reduzir o Td em at 25%,
observando-se a Regio Impossvel. No entanto, quanto mais perto da Regio Impossvel,
o esforo e o custo do projeto aumentam de maneira exponencial. Assim, a reduo de
prazo de 10% implica no aumento de esforo de 20%; a reduo de prazo de 20% implica
no aumento de esforo de 50%; a reduo de prazo de 25% implica em um aumento de
esforo de 70%. No recomendada a reduo de prazo em mais de 20%.
Os percentuais de aumento de esforo so estimados, podendo ser reajustados
Na seo seguinte abordada a questo da distribuio de esforo e alocao de
pessoas ao projeto.
36
________________________________________________________________________________
6.1.4 Alocao de Equipe ao Projeto

Na alocao de equipe, deve-se considerar a estimativa de prazo e de esforo.
Sugere-se utilizar a frmula seguinte:
Equipe = Esforo (HH) / (21 x ProdDiria x Prazo)
Onde:
Prazo = Td em meses
ProdDiria = 6h/dia ou 7h/dia (recomenda-se considerar 6 horas/dia)
21 = dias teis contidos em 1 ms
O tamanho da equipe obtido em quantidade de recursos para o desenvolvimento
do projeto e deve-se considerar percentuais de alocao. Por exemplo, suponha uma
equipe de projeto de 2,2 recursos. Esta equipe pode conter 5 pessoas, sendo que 4
pessoas com 50% de alocao e um lder de projeto com 20% de alocao ao projeto.
6.1.5 Mtodo para Estimativa de Custo

A estimativa de custo do projeto deve levar em considerao o custo de um ponto
de funo. Este custo deve abranger o custo da hora de todos os profissionais envolvidos
no desenvolvimento da soluo de software. O clculo do custo do projeto (CP) ser
ento da seguinte forma:
CP = QPF x CPF
Onde:
QPF = Tamanho do projeto em PF
CPF = Custo para implementar um ponto de funo na plataforma em questo
6.1.6 Estimativa de Recursos Computacionais

A estimativa de recursos computacionais tambm deve ser considerada, pois
constitui um componente importante para as estimativas de custo dos projetos. Um
recurso computacional um hardware que precisa ser adquirido ou que existe mas
precisa ser configurado. Exemplos de recursos computacionais incluem, dentre outros:
espao em disco para o sistema entrar em produo, um servidor especfico para teste ou
homologao do sistema. Devem ser registradas as seguintes informaes associadas
aos recursos computacionais crticos:
Nome do Recurso Computacional: [considere exclusivamente hardware: micro,
perifrico, expanso de memria, rea em disco, banda de rede, etc]
Descrio: [definio das caractersticas do recurso necessrias ao atendimento
ao projeto]
Responsvel pela Disponibilizao: [defina quem o responsvel pela
disponibilizao do recurso para o projeto]
Data Limite: [informe a data limite para disponibilizao do recurso]
37
________________________________________________________________________________
Parmetros: [caractersticas do recurso: quantidade, perfil, configurao, etc]
Tipo do Recurso: [D: recurso para ambiente de Desenvolvimento; P: recurso
para ambiente de Produo; H: recurso para ambiente de Homologao]
Custo (Opcional): [Custo do recurso computacional. No considerar custos de
processamento ou custos operacionais de produo]
Caso o projeto a ser desenvolvido no possua nenhum recurso computacional
crtico, isto deve ser registrado no documento de estimativas.
6.2 Diretrizes para Acompanhamento de Projetos

Esta seo apresenta consideraes especiais sobre o gerenciamento de
mudana de requisitos, projetos cancelados, progresso de projetos, assim como o
tratamento de reduo de cronograma e fator criticidade.
6.2.1 Consideraes sobre Mudana de Requisitos

Em projetos de desenvolvimento e de manuteno de software bastante
observada a mudana de requisitos anterior implantao do projeto, conforme o usurio
e o desenvolvedor adquirem mais conhecimento sobre as necessidades e funcionalidades
de negcio [Sommerville, 2007]. O CPM denomina este fenmeno de Scope Creep.
Nas estimativas iniciais de tamanho de projetos de desenvolvimento, aps a fase
de especificao, considerando-se o documento de viso inicial do projeto, recomenda-se
utilizar um percentual de 30% a 40% para evoluo de requisitos. Este percentual
sugerido, ficando a critrio da instituio estabelec-lo contratualmente. Por exemplo,
suponha que aps a anlise do documento de viso de um projeto, aplicando-se a CEPF,
foi obtido o tamanho de 200 PF, ento o tamanho estimado desse projeto de 270 PF
(200 + 35%), utilizando-se a premissa de evoluo de requisitos em 35%. Esta premissa
do projeto deve ser documentada. Nas estimativas, aps a fase de requisitos, utilizandose como insumo as especificaes de casos de uso, deve-se considerar um percentual de
20% a 30% para evoluo de requisitos.
Uma mudana de requisito anterior implantao do projeto gera retrabalho para a
equipe de desenvolvimento, aumentando assim o esforo e o custo do projeto. Neste
roteiro, as demandas de mudana de requisitos sero dimensionadas como
PF_RETRABALHO, contadas parte do projeto de desenvolvimento ou de manuteno.
Cabe ressaltar que para evitar as solicitaes de mudana de requisitos devido a
falhas na execuo da fase de engenharia de requisitos, importante que seja dada
ateno especial atividade de validao e aceitao dos requisitos.
O mtodo de contagem de mudana de requisitos descrito neste roteiro tem os
seguintes pressupostos:
As demandas de mudana de requisitos so contagens parte da contagem do

projeto de desenvolvimento ou de manuteno e devem considerar as
funcionalidades antes da mudana;
A quantidade de PF_RETRABALHO apurada leva em conta o esforo j realizado
no processo de desenvolvimento da funcionalidade at o momento da solicitao
de mudana de requisitos. Nos projetos onde exista o gerenciamento e o
acompanhamento do seu progresso (subseo 6.2.3), preciso aplicar o
percentual das atividades concludas das fases do processo de
desenvolvimento at o momento da mudana de requisitos na frmula do clculo
do PF_RETRABALHO. Nos projetos sem gerenciamento do seu progresso,
38
________________________________________________________________________________
preciso aplicar o percentual das fases concludas na frmula do clculo do

PF_RETRABALHO. A distribuio de esforo sugerida na Tabela 7 estabelece os
percentuais por fase, de forma a permitir a contagem de mudana de requisito
conforme o estgio do projeto. Ressaltamos que os percentuais de esforo
sugeridos podem variar de acordo com o tipo de projeto e o processo de
desenvolvimento utilizado no rgo. Essa distribuio de esforo deve ser definida
no contrato de software.
A contagem do projeto de desenvolvimento ou de manuteno dever ser
atualizada a cada demanda de mudana de requisitos, visando refletir as
funcionalidades aps a mudana.
Para fins de planejamento ou de faturamento, a quantidade total de pontos de
funo ser obtido da seguinte forma:
PF_TOTAL = PF_PROJETO + PF_RETRABALHO
Onde: PF_PROJETO a ltima verso da contagem do escopo do projeto
(PF_DESENVOLVIMENTO, PF_MELHORIA, PF_ADAPTATIVA, etc).
A contagem de PF_RETRABALHO leva em conta as seguintes caractersticas:

Requisito original: o requisito do projeto de desenvolvimento ou de manuteno
original, que pode ser incluir, alterar ou excluir funcionalidades de um aplicativo.
Tipo da mudana do requisito : a natureza da mudana de requisitos no projeto
em andamento, que pode ser acrescentar um requisito, alterar um requisito
definido ou desistir de um requisito (retirar do escopo do projeto).
A Tabela 10 resume os percentuais que devem ser aplicados sobre as funes

alteradas (considerando o tamanho antes da mudana) para obteno de
PF_RETRABALHO:
Requisito Original
Fator
Incluir
Alterar Excluir
Funo Funo Funo
Acrscimo
Tipo da
Mudana de Alterao
Requisito
Desistncia
Alterao de
Requisitos
75%
75%
Alterao de
Interface
0,6 PF
0,6 PF
140%
115%
40%
Tabela 10 Percentuais definidos para a mudana de requisitos
Cabe ressaltar que a quantidade de PF_RETRABALHO obtida, para fins de

planejamento, gesto e faturamento, usa na sua frmula o percentual das fases ou
atividades concludas at o momento da solicitao da mudana de requisitos, conforme
descrito acima.
39
________________________________________________________________________________
Observaes Importantes:
1. Recomenda-se que o registro das demandas de alterao de requisitos seja
realizado em separado, sendo contado em uma planilha de
PF_RETRABALHO parte da contagem de PF do projeto. Apesar das
medies em separado, elas ainda devem guardar vnculo com o projeto em
andamento, fazendo parte da sua baseline de tamanho.
2. O clculo do PF_RETRABALHO deve registrar o percentual das fases
concludas do processo de desenvolvimento at o momento da mudana
de requisitos, para projetos que no tenham o gerenciamento do seu
progresso, conforme descrito na subseo 6.2.3. Nos projetos onde exista o
gerenciamento do seu progresso, o PF_RETRABALHO deve registrar o
percentual das atividades concludas das fases do processo de
desenvolvimento, no momento da mudana de requisitos, usando os
registros de acompanhamento do progresso do projeto ilustrados na
subseo 6.2.3.
A seguir so descritos os tipos de mudana nos projetos.
1. Acrscimo de funcionalidades ao escopo do projeto
As mudanas que no tragam impacto aos requisitos originais do projeto,
caracterizadas pelo acrscimo de funcionalidades ao escopo do projeto de
desenvolvimento ou de manuteno, sero acrescentadas na contagem de PF do projeto
e no geram contagem de PF_RETRABALHO, ou seja, representam um trabalho
adicional e no retrabalho. Enquadram-se nesta situao a incluso, a alterao ou a
excluso de funes que no constavam no escopo do projeto original.
2. Alterao de funo
A contagem de PF_RETRABALHO referente alterao deve considerar o
percentual de 75% sobre o tamanho da funo antes da alterao, independentemente do
requisito original. Este item se refere somente alterao de requisitos de funcionalidades
que estavam sendo criadas ou alteradas no projeto original (Caso 1).
Em caso de mudanas em interface (cosmticas), conforme apresentado na seo
4.7, considerar o percentual de 20% da contagem de uma funo transacional de mais
baixa complexidade (3 PF), ou seja 0,6 PF, independentemente da complexidade da
funo antes da alterao (Caso 2).
Sobre a quantidade de PF_RETRABALHO obtida, para fins de gesto e
faturamento, dever ser aplicado o percentual das fases concludas at o momento da
solicitao de mudana de requisitos, para projetos que no tenham o gerenciamento do
seu progresso, conforme descrito na subseo 6.2.3, e o percentual das atividades
concludas, para projetos que tenham o gerenciamento do seu progresso, conforme os
registros de acompanhamento do progresso do projeto, ilustrados na subseo 6.2.3.
A contagem de PF do projeto deve ser atualizada para refletir o novo grau de
complexidade da funo aps a mudana.
40
________________________________________________________________________________
Exemplo:
Considerando-se que um projeto de melhoria tinha como escopo a alterao de
uma EE (complexidade alta - 6 PF) e a criao de uma CE (complexidade baixa - 3 PF) e
uma SE (complexidade baixa - 4 PF). Alm disso, no feito o gerenciamento do
progresso desse projeto. A contagem de PF_MELHORIA :
Incluso de CE e SE: 3 PF + 4 PF = 7 PF
Alterao de EE: 6 PF * 75% = 4,5 PF
PF_MELHORIA v1 = 11,5 PF
Caso 1: Alterao de requisitos

No incio da homologao foram solicitadas mudanas nos requisitos da EE e da
CE, sendo que a complexidade da CE passou a ser mdia (4 PF) aps a mudana. Nesta
situao hipottica, a contagem de PF_RETRABALHO ser a seguinte:
EE original: 6 PF
CE original: 3 PF
PF_RETRABALHO = (6 PF + 3 PF) x 75% Nota 1 = 6,75 PF
PF_RETRABALHO = 6,75 PF x 90%Nota 2
PF_RETRABALHO = 6,075 PF
Nota 1: 75% o percentual a ser aplicado sobre o tamanho da funo original antes da
sua alterao, conforme apresentado na Tabela 10.
Nota 2: No contexto do exemplo e usando a distribuio de esforo da Tabela 7, o projeto
na fase de testes (a ltima fase concluda antes da fase de homologao) registra
progresso de 90%. Assim, para fins de gesto e faturamento, o valor do
PF_RETRABALHO seria o correspondente a: 6,75 PF * 90% = 6,075 PF cheios.
A contagem de PF_MELHORIA dever ser atualizada para refletir o aumento da
complexidade da CE alterada:
Incluso de CE alterada e SE: 4 PF + 4 PF = 8 PF

Alterao de EE alterada: 6 PF * 75% = 4,5 PF
PF_MELHORIA v2: 12,5 PF
Caso 2: Alterao de interface

Durante a fase de implementao foi solicitada uma alterao na funo SE, que
um relatrio. A demanda para alterar o tipo de fonte do ttulo do relatrio (alterao de
interface - cosmtica). A complexidade da funo SE se mantm a mesma (complexidade
baixa - 4 PF) aps a mudana. Nesta situao hipottica, a contagem de
PF_RETRABALHO ser a seguinte:
SE original: 4 PF
PF_RETRABALHO = 0,6 PF Nota 3
41
________________________________________________________________________________
Nota 3: 0,6 PF corresponde a 20% de uma funo de baixa complexidade (3PF),
independente do tamanho da funo original antes da sua alterao, conforme
apresentado na Tabela 10.
na fase de Design/Arquitetura (a ltima fase concluda antes da fase de implementao,
onde ocorreu a solicitao de mudana) registra progresso de 35%. Assim, para fins de
gesto e faturamento, o valor do PF_RETRABALHO seria o correspondente a: 0,6 PF *
35% = 0,21 PF cheios.
Nesse caso de mudana de requisitos com alterao de interface (cosmtica), a
contagem de PF_MELHORIA do projeto original no sofre alterao, visto que a
complexidade da funo SE no alterada.
3. Desistncia de incluir, alterar ou excluir uma funo
Em caso de desistncia de incluir, alterar ou excluir uma funo, deve-se verificar
qual era o requisito original, pois o percentual a ser utilizado na contagem de
PF_RETRABALHO varia para cada situao, conforme apresentado na Tabela 10. Alm
do trabalho de retirar o que foi requisitado (percentuais definidos na Tabela 10), deve-se
considerar tambm em PF_RETRABALHO, o trabalho realizado (fases ou atividades
concludas do processo de desenvolvimento) at o momento da desistncia desse
requisito. Por fim, o requisito original deve ser removido do PF_MELHORIA. Enquadramse nesta situao somente as desistncias de incluir, de alterar ou de excluir
funcionalidades que constavam no escopo do projeto.
Quando a mudana no projeto deixar de incluir uma funo, aplica-se o
percentual de 140% ao tamanho da funo original. Esse valor resultado da soma do
percentual de 100% da incluso (escopo original) com os 40% correspondentes
excluso dessa mesma funo.
Quando a mudana no projeto deixar de alterar uma funo, aplica-se o
percentual de 115% ao tamanho da funo original. Esse valor o resultado da soma do
percentual de 75% da alterao (escopo original) com os 40% referentes excluso
dessa mesma funo.
Quando a mudana no projeto deixar de excluir uma funo, aplica-se apenas o
percentual de 40% referente excluso da funo original.
Em todos os casos, a contagem de PF_MELHORIA deve ser atualizada
removendo-se as funes que no fazem mais parte do escopo do projeto.
Da mesma forma que no item 2 (Alterao de funo), para fins de gesto e
faturamento, sobre a quantidade de PF_RETRABALHO aplicado o percentual das fases
concludas at o momento da solicitao de mudana de requisitos, para projetos que
no tenham o gerenciamento do seu progresso, conforme descrito na subseo 6.2.3, e o
percentual das atividades concludas, para projetos que tenham o gerenciamento do
seu progresso, conforme os registros de acompanhamento do progresso do projeto,
ilustrados na subseo 6.2.3.
42
________________________________________________________________________________
Exemplos:
Desistncia de incluir funo
Suponha que um projeto de melhoria para a criao do relatrio XPTO, contado
como uma SE de complexidade mdia com 5 PF, teve uma demanda de excluso do
projeto de melhoria durante a fase de implementao (ou seja, o relatrio no ser mais
construdo). Suponha, tambm, que no feito o gerenciamento do progresso desse
projeto. Desta forma a contagem de PF_RETRABALHO ser a seguinte:
SE original: 5 PF
PF_RETRABALHO = 5 PF x 140%Nota 5 = 7 PF
PF_RETRABALHO = 7 PF x 35%Nota 6
desistncia da sua incluso, conforme apresentado na Tabela 10.
gesto e faturamento, o valor do PF_RETRABALHO seria o correspondente a: 7 PF *
35% = 2,45 PF cheios.
A contagem de PF_MELHORIA do projeto deve ser atualizada para que o relatrio
XPTO deixe de constar na medio, conforme frmula abaixo:
Incluso de SE: 5 PF
PF_MELHORIA v2 = PF_MELHORIA v1 (Incluso de SE)
PF_MELHORIA v2 = PF_MELHORIA v1 5 PF
Desistncia de alterar funo

Se, no exemplo anterior, o relatrio XPTO estivesse sendo originalmente alterado
(ao invs de includo), a nica diferena seria no percentual aplicado em
PF_RETRABALHO:
SE original: 5 PF
PF_RETRABALHO = 5 PF x 115%
Nota 7
= 5,75 PF
desistncia da sua alterao, conforme apresentado na Tabela 10.
gesto e faturamento, o valor do PF_RETRABALHO seria o correspondente a: 5,75 PF *
35% = 2,0125 PF cheios.
43
________________________________________________________________________________
A contagem de PF_MELHORIA do projeto deve ser atualizada para que o requisito
original (alterao do relatrio XPTO, contado como uma SE de complexidade mdia com
5 PF) deixe de constar na medio.
Alterao de SE: 5 PF * 75% = 3,75 PF

PF_FUNCIONAL v2 = PF_FUNCIONAL v1 (Alterao de SE)
PF_FUNCIONAL v2 = PF_FUNCIONAL v1 (3,75 PF)
4. Desistncia de alterar uma funo seguida de excluso da funo

Quando a solicitao de mudana seja no s deixar de fazer o que estava no
projeto original, mas tambm excluir a funo da aplicao, deve-se considerar esses dois
aspectos separadamente, como se fossem duas mudanas consecutivas:
A) Conta-se a desistncia de alterar a funo conforme descrito no item 3
(Desistncia de incluir, alterar ou excluir uma funo), apurando a quantidade
de PF_RETRABALHO correspondente e a atualizao do PF_MELHORIA;
B) Conta-se o acrscimo ao escopo do projeto (excluir a funo da aplicao)
conforme descrito no item 1 (Acrscimo ao escopo do projeto), atualizando-se
PF_MELHORIA.
6.2.2 Consideraes sobre Projetos Cancelados

Em alguns casos, devido a mudanas no ambiente da contratante, uma demanda
ou parte de um projeto de desenvolvimento ou manuteno pode ser cancelado a critrio
da contratante. Nestes casos, o tamanho funcional das funcionalidades canceladas ser
aferido por meio da contagem de pontos de funo das funcionalidades canceladas e um
fator de impacto.
O fator de impacto definido com base no percentual de esforo alocado
construo da funcionalidade em questo, observando a Tabela 7 de distribuio de
esforo contida na subseo 6.1.2.1 ou alguma diretriz especfica de distribuio de
esforo do contrato em questo. O fator de impacto deve ser aplicado na contagem de
pontos de funo das funcionalidades em questo. importante ressaltar que em um
processo de desenvolvimento incremental uma funcionalidade pode, por exemplo, estar
em fase de requisitos e de testes, porque o plano de testes construdo na fase de
requisitos. O progresso das atividades executadas em cada funcionalidade do projeto
deve ser obtido por meio do acompanhamento do plano do projeto descrito na subseo
seguinte.
6.2.3 Gerenciamento de Progresso de Projetos

O acompanhamento do projeto deve identificar o progresso de cada requisito do
projeto, ou seja, o percentual de concluso de cada fase do processo de software para o
requisito em questo.
A apurao do percentual concludo em cada fase deve ser definido em comum
acordo entre o rgo contratante e a empresa contratada, de acordo com os artefatos
entregues em cada fase. Os artefatos que esto na fbrica, mas no foram entregues,
no devem ser considerados nessa apurao.
44
________________________________________________________________________________
Segue um exemplo de acompanhamento do progresso do desenvolvimento de um
Sistema de Gesto de Projetos, que mostra para cada um dos requisitos o percentual
concludo de cada fase:
Requisito
Tamanho
Caso de Uso 1
19 PF
Engenharia de
Requisitos
Design,
Arquitetura
50,00%
Implementao
Testes
Homologao
Implantao
20%
0%
10%
0%
0%
100%
50%
20%
0%
0%
Atividade
Incluir Ativ.
Alterar Ativ
Excluir Ativ
Consultar Ativ
Caso de Uso 2
5 PF
100 %
- Relatrio de
Projetos
....
Supondo a mudana de requisitos no Caso de Uso 2 do exemplo acima, para

incluso de uma nova informao a ser apresentada no Relatrio, a contagem de PF do
requisito original a seguinte:
Caso de Uso 2 Relatrio de Projetos 5 PF
Macroatividades
Esforo da Fase
Tamanho
Esforo
realizado
Tamanho
realizado
Engenharia de
Requisitos
25%
1,25 PF
100%
1,25 PF
Design, Arquitetura
10%
0,5 PF
100%
0,5 PF
Implementao
40%
2 PF
50%
1 PF
Testes
15%
0,75 PF
20%
0,15 PF
Homologao
5%
0,25 PF
0%
0 PF
Implantao
5%
0,25 PF
0%
0 PF
Total: 2,9 PF
O tamanho realizado do requisito original de 2,9 PF. Conforme descrito na
subseo 6.2.1, para o clculo do PF_RETRABALHO do requisito alterado ser
considerado o fator de impacto de 75% na contagem de PF. Portanto, a contagem do
PF_RETRABALHO 2,9 x 0,75 = 2,175 PF.
6.2.4 Consideraes sobre Reduo de Cronograma

Como apresentado anteriormente, as estimativas de prazo no so lineares com o
tamanho do projeto. Jones [Jones, 2007] prope uma frmula, descrita na subseo 6.1.3,
para o clculo do melhor tempo de desenvolvimento (onde h uma melhor relao custo x
benefcio de alocao de recursos e menor prazo de desenvolvimento), dado o tamanho
de um projeto especfico.
Alguns projetos, devido legislao e a outros fatores externos, j se iniciam com
um prazo imposto. Se este prazo for igual ou superior ao prazo calculado pela frmula de
Capers Jones (expoente t) ou, em caso de projetos pequenos (menores que 100 PF),
igual ou superior a um prazo calculado considerando o trabalho da equipe de 7 horas/dia
45
________________________________________________________________________________
nos dias teis (conforme sugerido na subseo 6.1.3), ento o projeto tratado como
normal.
No entanto, se o projeto tiver um prazo imposto inferior ao prazo calculado, ento
pode-se considerar a seguinte proposta como uma sugesto de valores:
Reduo de prazo de 10%: aumento de esforo de 20% (projetos urgentes);
Reduo de prazo de 20%: aumento de esforo de 50% (projetos crticos);
Reduo de prazo de 25%: aumento de esforo de 70% (projetos de alta
criticidade).
Os valores acima devem ser avaliados e definidos a critrio do rgo, caso esse
cenrio possa ocorrer durante o contrato.
Deve-se ressaltar que no possvel uma reduo de prazo maior que 25%,
devido aos clculos de Regio Impossvel e ainda, conforme nos aproximamos da Regio
Impossvel, o esforo e o custo do projeto aumentam de maneira exponencial.
Como os riscos da reduo de cronograma tambm so altos, no recomendada
a reduo de cronograma. Deve-se tentar priorizar funcionalidades trabalhando com o
processo incremental.
Caso o contrato seja baseado em preo por pontos de funo, este aumento de
esforo ser refletido na contagem de PF. Assim, um aumento de esforo de 20% implica
em aumento de 20% no custo de PF; aumento de esforo de 50% implica em aumento de
50% no custo de PF; e o aumento de esforo de 70% implica em aumento de 70% no
custo de PF.
No recomendado o uso de reduo de cronograma, pode-se utilizar processos
incrementais de desenvolvimento e trabalhar com definio de prioridades. importante
ressaltar que estas questes devem ser definidas em clusulas contratuais e devem ser
consideradas no oramento do contratante.
6.2.5 Fator de Criticidade de Solicitao de Servio

Em funo da criticidade e da necessidade de alocao de recursos extras para
atendimento da demanda no prazo estipulado pelo cliente, sugere-se adotar um fator de
criticidade de 1,35 (um vrgula trinta e cinco), que dever ser multiplicado pelo tamanho
funcional da demanda considerada crtica, de modo a remunerar adequadamente o
aumento do esforo de atendimento. Este fator considerado para demandas que devem
ser atendidas em finais de semana, feriados e fora do horrio comercial. Entende-se
como horrio comercial o horrio de 08:00 s 18:00.
importante ressaltar que estas questes devem ser definidas em clusulas
contratuais e devem ser consideradas no oramento do contratante.
7. Atividades Sem Contagem de Pontos de Funo

Deve-se ressaltar que o processo de desenvolvimento de solues possui vrias
atividades que precisam ser consideradas como um projeto separado, levando-se em
conta as horas realizadas e que devem estar associadas a produtos contratados e
entregveis. So atividades categorizadas nessa condio:
Treinamentos em Tecnologia da Informao: so as demandas de treinamentos
em linguagens de programao, ferramentas de gesto, processos, modelos da
qualidade, mtricas, etc. Estes servios so executados por consultores da
46
________________________________________________________________________________
contratada, especialistas no assunto em questo. Assim, devem ser consideradas
as horas de consultoria para preparao e execuo do curso e o custo do
deslocamento do instrutor, se for o caso.
Desenvolvimento de Cursos para EaD: so as demandas de desenvolvimento de
um curso na modalidade de Ensino a Distncia (EaD). Estas demandas devem ser
remuneradas em horas.
Mapeamento de Processos de Negcio: so as demandas de elaborao de
documentao contendo o mapeamento de processos de negcio de uma
organizao ou de parte de uma organizao. Estes servios so executados por
consultores da contratada, especialistas em BPM (Business Process Modeling).
Elaborao de Plano Diretor de Tecnologia da Informao (PDTI): so as
demandas para elaborao de PDTI para clientes. Estes servios so executados
por consultores da contratada, especialistas nas atividades associadas
elaborao de um PDTI.
Definio de Processo de Desenvolvimento de Solues: so as demandas para
definio de Processos de Software, aderentes s melhores prticas do CMMI e
Instruo Normativa SLTI n 4, de 12 de novembro de 2010. Estes servios so
executados por consultores da contratada, especialistas nas atividades de
processos de software e na customizao da ferramenta para criao do site do
processo.
Outros servios prestados que tambm no possuem contagem de PF associada
so os seguintes:
Administrao de Dados: este servio requer uma equipe de administradores de
dados (AD) com um nmero de profissionais definido junto contratante, dedicada para
atender as demandas associadas definio e manuteno do modelo de dados de
negcio do cliente. Esta equipe fica disponvel em horrio comercial ou horrio especfico
estabelecido no contrato para atendimento das demandas. Assim, estes servios no
possuem contagem de PF associada. importante ressaltar que as atividades de
banco de dados associadas ao projeto de desenvolvimento ou de manuteno, por
exemplo, preparao de ambiente (testes, homologao, implantao),
desempenhadas pelos DBA da equipe de desenvolvimento, j esto consideradas
dentro do projeto de software, no cabendo cobrana adicional.
Consultoria: Servio de apoio destinado anlise de regras de negcio a serem
implementadas em solues de TI, realizado por consultores especialistas da contratada.
As demais modalidades de consultoria tambm podem ser enquadradas neste item, por
exemplo, consultoria em mtricas. Estas demandas no possuem contagem de PF
associada.
Outras atividades contidas em um processo de software devem ser gerenciadas
dentro do projeto de desenvolvimento ou de manuteno. No entanto, o esforo deve ser
considerado separadamente da estimativa de esforo derivado da contagem de pontos de
funo. Estas atividades tambm devem ser precificadas a parte. So elas:
Treinamento para Implantao: so demandas de treinamentos sobre utilizao
do sistema a ser implantado, para os gestores de soluo do cliente e usurios. O esforo
deste servio deve ser considerado separadamente da estimativa de esforo derivada da
contagem de PF. A remunerao deste servio deve ser calculada, levando-se em conta o
preo da hora de consultoria desse tipo de servio, incluindo atividades de preparao de
treinamento e de instrutoria. As responsabilidades, condies e premissas que envolvem
as necessidades de servios de treinamento devem estar descritas no contrato. Deve-se
47
________________________________________________________________________________
ressaltar que este treinamento para implantao pode ser definido na modalidade de
EaD, sendo tratado como um projeto de treinamento a parte. O esforo deste
considerado dentro do projeto de EaD, que no faz parte do projeto de desenvolvimento
ou manuteno em questo.
Especificao de Negcio: esta a primeira atividade a ser executada em uma
demanda de projeto de desenvolvimento e/ou de manuteno. O objetivo dessa atividade
gerar a especificao da demanda (por exemplo, um documento de viso do projeto ou
qualquer outro documento inicial de requisitos definido no processo de desenvolvimento
do rgo contratante), que deve ser validada pelo rgo contratante. O esforo dessa
atividade deve ser considerado separadamente da estimativa de esforo derivada da
contagem de PF. importante ressaltar que essa atividade de responsabilidade dos
analistas de negcio da empresa contratante, de acordo com a Instruo Normativa SLTI
n 4, de 12 de novembro de 2010. No entanto, por falta de pessoal, alguns rgos e
entidades tm contratado estas atividades, que antecedem a fase de requisitos primeira
fase do processo de software e devem ser faturadas em horas de consultoria. O
documento inicial de requisitos gerado nessa atividade o artefato utilizado como insumo
para o planejamento do projeto (estimativa de tamanho funcional em pontos de funo) e
para o processo de desenvolvimento de software.
8. Processo de Reviso do Roteiro de Contagem

8.1 Reviso para Correo de Inconsistncias e Situaes no Previstas
A reviso deste roteiro ser feita sempre que se verificarem inconsistncias entre
uma definio do CPM e uma regra constante deste documento, e situaes no
previstas neste roteiro. Essas situaes, sempre que necessrio, sero documentadas,
gerando novas verses deste roteiro.
8.2 Reviso para Adoo de Novas Verses do CPM

A adoo de nova verso do CPM como referncia para este roteiro de contagem
no ser imediata sua publicao. Nesse caso, dever haver uma avaliao da nova
verso para se decidir sobre a atualizao deste documento. Em caso de utilizao de
roteiro de mtricas em contratos de software, a atualizao do roteiro deve ser negociada
entre rgo contratante e a empresa contratada.
9. Concluso
Este documento apresentou um roteiro para o dimensionamento de tamanho de
vrios tipos de projetos de software da contratante, visando a aderncia desses tipos de
projetos desenvolvidos na instituio s diretrizes da Instruo Normativa SLTI n 4 ,de 12
de novembro de 2010. A estimativa de tamanho utiliza a mtrica Ponto de Funo No
Ajustado como unidade de medida, conforme recomendado nos Acrdos 1.910/2007,
2.348/2009 e 1.647/2010 do Tribunal de Contas da Unio (TCU) e na Portaria SLTI/MP N
31, de 29 novembro de 2010.
importante ressaltar que o uso de mtricas em contrato de software uma boa
prtica, visando proporcionar uma gesto efetiva dos contratos com base em dados
quantitativos e objetivos. A implantao desta modalidade de contrato implica na definio
de processos de gesto de requisitos e de gesto de projetos baseados nas melhores
prticas. Outro ponto a ser destacado a implantao de um Escritrio de Mtricas com
48
________________________________________________________________________________
servidores capacitados para realizar contagens e estimativas em pontos de funo. Estes
servidores sero responsveis pela reviso das contagens de pontos de funo e
estimativas realizadas pelo Escritrio de Mtricas da empresa contratada e pela
manuteno do roteiro de mtricas do rgo.
Como trabalho futuro, recomenda-se a reviso e atualizao deste roteiro sempre
que for verificada inconsistncia entre alguma definio do IFPUG publicada em verses
futuras do CPM ou em White Paper, ou quando for detectado um novo tipo de servio
associado ao desenvolvimento de software no previsto neste roteiro. Neste sentido,
como trabalho futuro est programada a elaborao de um modelo de mensurao para
servios de desenvolvimento e manuteno referentes a projetos de DW,
Geoprocessamento, Workflow e Portais utilizando Gerenciadores de Contedo, que
representam cenrios existentes em alguns rgos do SISP.
10. Referncias Bibliogrficas

[Boehm, 2009] BOEHM, B.W. Software Cost Estimation With COCOMO II. Prentice
Hall, New Jersey, 2009.
[Dekkers, 2003] DEKKERS, C. Measuring the logical or functional Size of Software
Projects and Software Application. Spotlight Software, ISO Bulletin May 2003, pp10-13.
[Hazan, 2005]
HAZAN C.; STAA, A.v. Anlise e Melhoria de um Processo de
Estimativas de Tamanho de Projetos de Software. Monografias em Cincias da
Computao n 04/05, Departamento de Informtica PUC-Rio, ISSN 0103-9741, Fevereiro
2005.
[Hazan, 2008] HAZAN, C. Anlise de Pontos de Funo: Uma Aplicao nas
Estimativas de Tamanho de Projetos de Software. Engenharia de Software Magazine,
Edio 2, Devmedia, pp.25-31.
[IEEE,1998] IEEE Computer Society. IEEE Standard for Software Maintenance. IEEE
Std 1219, 1998.
[IFPUG,2010a] IFPUG. Considerations for Counting with Multiple Media. Release 1.1,
April, 2010.
[IFPUG,2010b] IFPUG. Counting Practices Manual. Version 4.3, January, 2010.
[Jones, 2007] JONES, C. Estimating Software Costs. Second Edition, Mc Graw Hill,
2007.
[Meli, 1999] MELI, R.; SANTILLO, L. Function Point Estimation Methods: A
Comparative Overview. Proceedings of FESMA 99, Amsterdam, Netherlands, October
1999, pp. 271-286.
[NESMA, 2005] NESMA. Neetherlands Software Metric Association. The application of
Function Point Analysis in the early phases of the application life cycle. A Practical
Manual: Theory and case study, 2005.
[NESMA, 2009] NESMA. Function Point Analysis for Software Enhancement
Guidelines. Version 2.2.1, 2009
[Parthasarathy,2007] PARTHASARATHY, M. A. Practical Software Estimation: function
point methods for insourced and outsourced projects. Addison Wesley, New York,
2007.
[Roetzheim, 2005] ROETZHEIM, W. Estimating and Managing Project Scope for New
Development. CrossTalk, Vol. April, 2005.
49
________________________________________________________________________________
[SERPRO, 2008] SERPRO. Mtodos para Estimativa de Projetos de Software
Baseado em Pontos de Funo. Relatrio do Grupo de Trabalho para Definio da
Utilizao de Pontos de Funo nos Servios de Desenvolvimento e Manuteno de
Sistemas. 2008.
[Sommerville, 2007] SOMMERVILLE, I. Software Engineering. Pearson Education
Limited, 8th Edition, 2007.
[Vazquez, 2012] VAZQUEZ, C. et al. Anlise de Pontos de Funo: Medio,
Estimativas e Gerenciamento de Projetos de Software. 12 Edio, Editora rica Ltda,
So Paulo, 2012.
50
________________________________________________________________________________
Anexo I Portaria SLTI/MP N 31, de 29 novembro de 2010

Dispe sobre recomendaes tcnicas para a utilizao da mtrica
Anlise de Ponto de Funo no mbito da Administrao Pblica
Federal direta, autrquica e fundacional e d outras providncias.
A SECRETRIA DE LOGSTICA E TECNOLOGIA DA INFORMAO DO
MINISTRIO DO PLANEJAMENTO, ORAMENTO E GESTO, no uso de suas
atribuies que lhe conferem o Decreto n 7.063, de 13 de janeiro de 2010, o Decreto n
1.048, de 21 de janeiro de 1994,e o Decreto n 1.094, de 23 de maro de 1994, resolve:
Art. 1 A mtrica de Pontos de Funo foi concebida como uma medida de tamanho
funcional para projetos de desenvolvimento e de melhoria (manuteno evolutiva) de
software.
1 A mtrica Ponto de Funo definida pelo organismo International Function
Point Users Group (IFPUG).
2 O manual de prticas de contagem de Pontos de Funo publicado pelo
IFPUG define as regras bsicas orientativas de contagem de Pontos de Funo para
projetos de desenvolvimento e melhoria de solues de software.
3 Por permitir a medio objetiva de servios de desenvolvimento de solues
de software, sua utilizao uma boa prtica na contratao de servios e est aderente
ao estabelecido na Instruo Normativa SLTI n 4 de 12 de novembro de 2010.
Art. 2 O Roteiro de Mtricas de Software do SISP um documento tcnico
complementar que visa esclarecer questes tcnicas, harmonizar entendimento e abordar
assuntos relativos contratao de solues de software no contempladas pelo manual
de contagem do IFPUG.
Pargrafo nico. Alm dos projetos de desenvolvimento de novas solues de
software e de melhoria de software, tambm h necessidade de medir projetos de
manuteno adaptativa de software. Assim, torna-se relevante a definio de
procedimentos complementares de medio para dimensionar projetos de manuteno
adaptativa de software cuja mensurao no so abordadas pelo manual de prtica de
contagem do IFPUG.
Art. 3 Recomenda-se que os rgos integrantes do Sistema de Administrao dos
Recursos de Informao e Informtica (SISP) adotem o roteiro de contagem nas suas
contrataes de servios de desenvolvimento e manuteno de solues de software.
Art. 4 Esta Portaria entra em vigor na data de sua assinatura.
MARIA DA GLRIA GUIMARES DOS SANTOS
51
________________________________________________________________________________
Anexo II Formalizao Simples de Requisitos Projetos de

Manuteno Pequenos (< 100 PF)
Dados Gerais
Nmero da OS
Nome do Sistema Mantido
Tecnologia Adotada
Data do Incio do Servio
DD/MM/AAAA
Data do Trmino do Servio DD/MM/AAAA

Descrio da Solicitao
Descrio do Servio Executado

Requisito
Detalhamento
1.
1.1
1.2...
2.
2.1
2.2...
52
________________________________________________________________________________
Identificao da Manuteno
Tipo
Melhoria
Migrao de Dados
Corretiva
Mudana de Plataforma - Linguagem de Programao
Mudana de Plataforma - Banco de Dados
Atualizao de Verso Linguagem de Programao
Atualizao de Verso Browser
Atualizao de Verso Banco de Dados
Manuteno em Interface (Cosmtica)
Adaptao em Funcionalidades sem Alterao de Requisitos Funcionais
Apurao Especial Base de Dados
Apurao Especial Gerao de Relatrios
Apurao Especial Reexecuo
Atualizao de Dados
Desenvolvimento, Manuteno e Publicao de Pginas Estticas de Intranet, Internet
ou Portal
Manuteno de Documentao de Sistemas Legados
Verificao de Erros
Pontos de Funo de Teste (Execuo de Testes em funcionalidades no mantidas)
Componente Interno Reusvel
Foi demandada a redocumentao da funcionalidade mantida? Sim

Aplicar Fator Criticidade? Sim
No
No
Observaes relevantes quanto ao tipo de manuteno:
53
________________________________________________________________________________
Descrio dos Requisitos de Manuteno (para cada funcionalidade alterada, utilizar um
quadro)
a) Tabelas Modificadas pela Manuteno
Nome da Tabela
A Tabela atualizada por alguma funcionalidade da aplicao: Sim
A Tabela atualizada por outra aplicao: Sim
A Tabela foi:
Includa
No
No
Alterada
Excluda
Total de Campos da Tabela aps a Manuteno =

Campos Includos/Alterados/Excludos
A funcionalidade ser apenas testada?

Sim
No
b) Entradas de Dados Afetadas pela Manuteno (telas ou arquivos de carga)

Nome da Entrada
Total de Campos na Entrada =
Nome das Tabelas Acessadas (Lidas e Gravadas) =
Houve mudana na regra de negcio (validaes, lgica de processamento, regras de

clculo)?
Sim
No

Sim
No
c) Consultas Afetadas pela Manuteno

Considere a tela de parmetros e a de resultados da consulta como apenas uma nica
Consulta. Caso a consulta seja do tipo lista e consulta detalhes, considere como funes
independentes e preencha quadros diferentes.
54
________________________________________________________________________________
Nome da Consulta
Total de Campos da
Consulta
Tabelas Acessadas
Total de Campos Afetados =
Total de Campos Calculados ou Totalizadores =
Existe atualizao de dados (log, indicador...) Sim
No

clculo, campos de filtro)?
Sim
No

Sim
No
d) Relatrios Afetados pela Manuteno

Considere a tela de parmetros e a de resultados do relatrio como apenas um nico
Relatrio.
Nome do Relatrio
Total de Campos no
Relatrio
Tabelas Acessadas
Total de Campos Afetados =
Total de Campos Calculados ou Totalizadores =
Existe atualizao de dados (log, indicador...) Sim
No

clculo, campos de filtro)?
Sim
No

Sim
No
55
________________________________________________________________________________
Anexo III Modelo de Documento de Contagem de Pontos de Funo

Projetos de Manuteno Pequenos (< 100 PF)
Documento de Contagem de Pontos de Funo de Projetos de Manuteno Pequenos
Cliente:
Histrico da Reviso
Data
Verso Descrio
Autor
Aprovador
Nome Projeto:
Nmero da OS:
Responsvel pela Contagem:
Descrio da Solicitao de Mudana:
Descrio da Atividade
Contagem PF
Tipo de Manuteno / Total PF
Observaes Relevantes:
Conforme a tabela de atividades acima, o total de pontos de funo realizados no Projeto
_____ na OS _________ de _____ PF.
56
________________________________________________________________________________
Anexo IV - Como Evitar Armadilhas em Contratos de Desenvolvimento e

Manuteno de Sistemas
Claudia Hazan
claudia.hazan@serpro.gov.br
Servio Federal de Processamento de Dados (SERPRO)
Este anexo tem como propsito apresentar algumas dicas para as organizaes
contratantes evitarem armadilhas em contratos de desenvolvimento e manuteno de
software baseados em preo fixo por pontos de funo.
Obtenha um Documento de Requisitos de Qualidade
Conforme mencionado, a mtrica PF mede a funcionalidade requisitada e recebida
pelo usurio. O documento de requisitos constitui um acordo comum entre os rgos
contratantes e empresas contratadas. Assim, fundamental a existncia de um Termo de
Aceite associado aos documentos de requisitos, assinado pelo gestor do sistema ou
gestor do contrato do rgo contratante. Alm disso, o contratante deve garantir a
qualidade do documento de requisitos encaminhado para a contratada. Observe que se o
contratante fornece um documento de requisitos com um requisito incompleto, a empresa
contratada entregar o produto sem a funcionalidade esperada e a organizao
contratante ter que pagar por isso.
A Engenharia de Requisitos apresenta vrias tcnicas para suportar as atividades de
verificao e validao de Documentos de Requisitos, no entanto, estas tcnicas so
muito custosas. Sugere-se a utilizao do mtodo Contagem Estimativa de Pontos de
Funo, alm de apoiar nas estimativas do projeto, o mtodo suporta a deteco de
defeitos em documentos de requisitos pelo estimador, enquanto ele est estimando o
projeto, sem custo ou esforo adicional, conforme demonstrado por Hazan [Hazan, 2005].
Considerando as revises e auditorias em contagem de pontos de funo dos projetos
contratados, importante que o documento de requisitos e o documento de contagem de
PF ou estimativas estejam consistentes.
Estabelea Regras para o Tratamento das Mudanas de Requisitos
A Engenharia de Requisitos e a indstria reconhecem que os requisitos no
permanecem congelados at a concluso do projeto de software. Os requisitos evoluem
desde a sua concepo at mesmo aps o sistema entrar em produo, devido a diversos
fatores descritos por Kotonya [Kotonya, 1998]. Assim, fundamental que o contrato de
software estabelea clusulas para tratamento das mudanas de requisitos. importante
ressaltar que o gestor do contrato deve evitar encaminhar para a contratada os requisitos
de negcio que estejam em fase de definio, seno podero emergir muitas mudanas
em requisitos elevando o custo do projeto em questo. Recomenda-se a implantao de
processos de gerenciamento de projetos e gerenciamento de requisitos pelos
contratantes, aderentes s melhores prticas de modelos da Qualidade de Software,
visando uma gesto efetiva dos projetos contratados.
57
________________________________________________________________________________
Estabelea Clusulas de Garantia da Qualidade
Conforme mencionado, a mtrica PF considera a funcionalidade requisitada e
recebida pelo usurio. Portanto, a remunerao da empresa contratada deve considerar
as funcionalidades entregues, somente se estas no apresentarem defeitos. Contudo, o
seguinte cenrio pode ocorrer: a empresa contratada entrega as funcionalidades
requisitadas com defeitos; o gestor do contrato reclama, a empresa contratada corrige os
erros da funcionalidade em questo; a contratante recebe o sistema de volta com outros
defeitos que surgiram com a correo do erro relatado. Esse tipo de problema comum
em fbricas de software com um processo de testes inexistente ou inadequado. Observe
que essa situao pode gerar um grande atraso no recebimento do sistema, podendo
gerar atritos entre a rea de TI do rgo contratante e os gestores do sistema que esto
aguardando a entrega do sistema funcionando. Assim, recomenda-se o estabelecimento
de clusulas contratuais para garantir a entrega de um projeto de desenvolvimento ou
manuteno de sistemas com qualidade. Sugere-se incluir no contrato uma clusula de
multa associada qualidade do produto entregue, considerando o indicador defeitos/PF.
Por exemplo, pode-se estabelecer que no aceitvel a entrega de mais de 0,3
defeitos/PF. importante definir no contrato os tipos de defeitos, a saber: bugs, defeitos
na documentao, cdigo fonte no estruturado, etc. Pode-se estabelecer tambm nveis
de severidade de defeitos.
Estabelea Clusulas Contratuais de Prazo e Taxa de Entrega
Algumas organizaes contratantes estabelecem clusulas contratuais associadas
produtividade. Por exemplo, a empresa contratada deve ter uma produtividade de 15
HH/PF em JAVA. Em alguns casos, o rgo contratante pede para a contratada relatar a
taxa de produtividade. Esta prtica no adequada. A produtividade uma informao
estratgica de uma empresa e ela no pode ser obrigada a divulgar estas informaes.
Alm disso, deve-se ressaltar que em um contrato baseado em PF, o controle da
produtividade da empresa contratada no faz sentido. De fato, os rgos contratantes
empregam esta prtica para resolver o problema de demandas recebidas com atraso de
cronograma. A soluo estabelecer no contrato o mtodo de estimativa de prazo a ser
utilizado. Recomenda-se que este mtodo utilize o tamanho em PF estimado do sistema
na derivao da estimativa de prazo. Alm disso, deve-se incluir clusulas de multa
considerando o atraso da entrega do projeto. Para as organizaes que no possuem um
processo de estimativas definido, sugere-se a utilizao da frmula de Capers Jones
descrita em [Jones, 2007]. importante ressaltar que a frmula adequada apenas para
projetos maiores que 100 PF. Em relao aos projetos pequenos, o contrato deve fixar
prazos de acordo com o tamanho do projeto. Por exemplo, para projetos com at 5 PF o
prazo de entrega de 8 dias teis.
Outro cenrio a ser considerado o seguinte: a empresa contratada ganha um
prego fornecendo um preo muito baixo por PF e ao ganhar o contrato ela busca forar o
aumento do preo do PF contratado, definindo regras prprias para a contagem de PF.
Como os rgos pblicos esto se capacitando em contagem de pontos de funo, o
gestor do contrato no aceita a contagem de PF majorada. Ento, a empresa contratada
aloca apenas um recurso para atendimento daquele contrato, ressaltando que os demais
recursos esto trabalhando em contratos mais lucrativos. E as demandas de manuteno
crticas do contratante ficam pendentes no atendimento. Portanto, visando evitar este
problema, importante definir clusulas contratuais estabelecendo uma taxa de entrega
mnima de PF/ms, por exemplo, 200 PF/ms. Deve-se incluir uma clusula de multa
tratando essa questo. O estabelecimento de uma taxa de entrega mensal mxima e
mnima tambm importante para a empresa contratada dimensionar suas equipes para
um melhor atendimento ao contrato.
58
________________________________________________________________________________
Estabelea o CPM como a Base para as Contagens de PF ao invs de
Converses
Alguns rgos contratantes estabelecem seus contratos com base na mtrica Ponto
de Funo, no entanto no possuem capacitao adequada em contagem de pontos de
funo. Em alguns casos, estes rgos delegam a contagem para a empresa contratada,
que estabelece roteiros de contagem com regras que podem majorar a contagem de PF.
Algumas vezes, o dimensionamento do tamanho do projeto em PF realizado por meio
de converses de horas alocadas em pontos de funo. Assim, estabelecido com a
empresa contratada um ndice de converso, por exemplo, 8 horas de trabalho
corresponde a 1 PF, e ento o pagamento da empresa contratada feito por meio das
horas alocadas ao projeto em questo convertidas em PF. Observe que se o recurso de
desenvolvimento est em uma empresa contratada externa ao rgo contratante, este
no pode gerenciar a quantidade de horas alocada ao projeto. Se o analista da empresa
contratada est realizando seu trabalho nas instalaes do contratante, isto um tipo de
terceirizao de mo de obra. E ainda, se a contratada alocar um recurso com baixa
produtividade, o custo do projeto ser muito alto. A prtica de converso de horas para PF
simples, no entanto inadequada. Se o contrato baseado em pontos de funo, a
empresa deve realizar as contagens seguindo as regras de contagem do manual CPM.
Deve-se ressaltar que uma contagem de PF errnea pode levar a conseqncias
desastrosas, tais como: pagamento incorreto do projeto contratado por PF, gerao de
dados para indicadores de qualidade defeitos/PF e produtividade horas/PF incorretos,
gerao de estimativas incorretas. fundamental que as organizaes que desejam
estabelecer contratos de prestao de servios de desenvolvimento e manuteno de
sistemas com base em pontos de funo criem seu Escritrio de Mtricas com
profissionais especialistas em contagem de pontos de funo. recomendado que estes
profissionais possuam certificao CFPS (Certified Function Point Specialist) e possuam
experincia prtica em contagem de PF e mtodos de estimativas de projetos de
software. As empresas contratadas tambm devem ter seu escritrio de mtricas para
revisar a contagem de PF do rgo contratante. Seguindo estas recomendaes
possvel evitar ou diminuir a incidncia de erros de contagem como os relatados em
Hazan [Hazan, 2008].
Estabelecer Regras para Dimensionar Projetos de Manuteno
Muitas organizaes estabelecem em seus contratos de prestao de servios de
desenvolvimento e manuteno de sistemas a prestao de servios de desenvolvimento
e manuteno de sistemas com base na mtrica Ponto de Funo. No entanto, o Manual
de Prticas de Contagem (CPM) trata apenas os projetos de desenvolvimento e de
manuteno evolutiva. Assim, torna-se importante a definio de mtricas para os demais
projetos de manuteno. Pode-se contratar tais projetos em homem/hora, no entanto,
conforme mencionado a IN 04 preconiza evitar a contratao de servios de
desenvolvimento e manuteno de sistemas por meio da mtrica homem_hora. Assim,
recomenda-se a utilizao de mtricas baseadas nas regras de contagem de pontos de
funo para dimensionar os projetos de manuteno no contemplados no manual CPM.
O primeiro passo a identificao de todos os tipos de projetos de manuteno que
podem ser contratados pela organizao. Posteriormente, deve-se definir mtricas para
dimensionar tais projetos. O Roteiro de Mtricas do SISP sugere frmulas de clculo.
59
________________________________________________________________________________
Estabelecer detalhes do processo de prestao de servios no Edital
importante ressaltar que em um processo de contratao de servios de
desenvolvimento e manuteno de sistemas, alm da estimativa de tamanho do projeto
em pontos de funo, outros aspectos devem ser considerados, a saber: definio do
processo de desenvolvimento a ser seguido pela contratada com detalhamento dos
artefatos a serem entregues, cronograma do projeto, definio dos acordos de nvel de
servio, definio com clareza do objeto a ser contratado, considerando os requisitos
funcionais e os requisitos no funcionais do projeto. Observe que os requisitos no
funcionais (performance, segurana, padro de interface, etc) no contam pontos de
funo, no entanto, impactam nas estimativas de esforo, custo e prazo do projeto.
MELHORES PRTICAS EM CONTAGEM DE PONTOS DE FUNO
Em contratos baseados em mtricas fundamental garantir a qualidade da
documentao das contagens de pontos de funo dos projetos. Seguem algumas
melhores prticas a serem consideradas na documentao das contagens e estimativas
de pontos de funo:
-
Documentao da Fronteira da Aplicao
Toda contagem ou estimativa de pontos de funo realizada em uma fronteira da

aplicao. Como a definio de fronteira de aplicao baseada em processos de
negcio, esta pode ser subjetiva. Por exemplo, um sistema de capacitao de
empregados faz parte ou no da fronteira de um sistema de recursos humanos? Em
algumas organizaes, um sistema de capacitao pode ser visto como parte do
processo de negcio de gesto recursos humanos. Neste caso, trata-se de uma fronteira
nica de aplicao de recursos humanos, abrangendo o mdulo de capacitao. Em
outras organizaes, a capacitao de empregados pode ser tratada como um processo
de negcio independente. Neste caso, tem-se duas fronteiras: sistema de recursos
humanos e sistema de capacitao. Desta forma, fundamental estabelecer e
documentar as fronteiras das aplicaes. Recomenda-se que as fronteiras dos sistemas a
serem mantidas estejam documentadas no edital de contratao, tambm pode ser
documentada no roteiro de mtricas do rgo. importante definir tambm quais sero as
fronteiras das novas aplicaes a serem contratadas, que devem estar em conformidade
com o Plano Diretor de TI do rgo contratante.
-
Documentao dos Requisitos de Projetos de Manuteno
A grande maioria dos projetos de software das organizaes de manuteno de

sistemas existentes. Em geral, comum observarmos documentao de desenvolvimento
de novos sistemas. No entanto, a documentao dos projetos de manuteno, muitas
vezes, consiste na atualizao da documentao da aplicao implantada. Cabe ressaltar
que essa prtica no adequada para a contagem de pontos de funo, porque na
contagem de projetos de manuteno necessria a identificao das funcionalidades
impactadas (includas, alteradas ou excludas). Por exemplo, o envio de uma tela como
funcionalidade alterada em um projeto de manuteno, no permite a contagem de PF do
projeto, porque esta tela pode trazer funcionalidades de incluso, alterao, consulta,
excluso e combo boxes. Se a mudana for na lgica de validao de um campo,
provavelmente, as funcionalidades impactas so apenas a incluso e a alterao. Ento,
a consulta, a excluso e as combo boxes no devem ser contadas. fundamental a
elaborao de um documento de requisitos especfico, mesmo que simplificado, para o
60
________________________________________________________________________________
projeto de manuteno. Este documento ser a base para a contagem de pontos de
funo do projeto de manuteno. De fato, os documentos de requisitos da aplicao
implantada tambm devero ser atualizados.
-
Documentao da Contagem com Rastreabilidade para Requisitos
Em contratos baseados em pontos de funo, as contagens e estimativas de pontos

de funo devem ser auditveis. Assim, alm de um documento de requisitos com
qualidade, importante que a contagem de pontos de funo seja rastrevel para os
requisitos utilizados como base para a contagem. Desta forma, recomenda-se que as
planilhas
de
contagem
possuam
uma
coluna
denominada
requisito/observaes/justificativa. Ao lado de cada tipo funcional identificado deve-se
documentar qual o requisito de origem e, caso necessrio, as observaes e justificativas
da contagem, por exemplo:
Identificao da Funo
Tipo
....
requisito/observaes/justificativa
Relatrio de Treinamentos
Ministrados por perodo
SE
...
Caso de Uso 5 Foi contado como SE por

conta da totalizao dos cursos.
....
....
....
....
Documentao das Funcionalidades Identificadas
Algumas padronizaes na nomenclatura das funes identificadas podem ser

adotadas para apoiar as revises das contagens. Por exemplo: para as funes de dados,
utilizar o nome das entidades do modelo de dados e no campo observao pode ser
colocado o nome do arquivo fsico implementado; para as funes transacionais, colocar
o nome da funcionalidade considerando o documento de requisitos utilizado na contagem.
Alm disso, tambm recomendvel a documentao dos Registros Lgicos e
Arquivos Referenciados, a documentao pode ser registrada como comentrio na coluna
correspondente da planilha de contagem. A documentao dos Tipos de Dados pode ser
muito trabalhosa, no entanto esta tambm influencia na complexidade do tipo funcional.
Ento cabe o bem senso, deve-se documentar os Tipos de Dados at a complexidade
mxima do tipo funcional. Por exemplo, suponha que a funcionalidade - EE: Vender
Produto possua 3 Arquivos Referenciados Vendas, Produto e Vendedor. Esta EE com 5
Tipos de Dados j ser contada como EE de complexidade alta. Ento, basta documentar
at 5 TD.
Cada rgo deve definir o modelo do seu documento de contagem de pontos de
funo, assim como as instrues para documentao das funcionalidades, visando
tornar as contagens auditveis.
REFERNCIAS BIBLIOGRFICAS
[Dekkers, 2003]
DEKKERS, C. Measuring the logical or functional Size of Software

Projects and Software Application. Spotlight Software, ISO Bulletin
May 2003 pp10-13.
61
________________________________________________________________________________
[Hazan, 2005]
HAZAN, C.; BERRY, D.M.; LEITE, J.S.P. possvel substituir

processos de Engenharia de Requisitos por Contagem de Pontos de
Funo? 8th International Workshop on Requirements Engineering
(WER2005), Porto, Portugal, June 2005, pp. 197-208.
[Hazan, 2008]
HAZAN, C. How to Avoid Traps in Contracts for Software Factory

Based on Function Point Metric. 3rd International Software
Measurement & Analysis Conference, Washington, United States,
2008.
[IFPUG, 2010]
IFPUG. Counting Practices Manual. Version 4.3, January, 2010.
[Jones, 2007]
JONES,C. Estimating Software Costs Bringing Realism to

Estimating. 2nd Edition, Mc Graw Hill, New York, 2007. New York.
[Kotonya, 1998]
KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering:

Processes and Techniques. John Willey & Sons Ltd, 1998.
62
________________________________________________________________________________
Anexo V Resumo da Tcnica EFP (Enhancement Function Points)

publicada pela NESMA
Este anexo apresenta um resumo das frmulas para o clculo em projetos de

melhoria, dos pontos de funo includos, alterados e excludos, segundo a tcnica EFP
estabelecida em [NESMA, 2009]:
PF_INCLUIDO = QPI;
PF_EXCLUIDO = QPE x 0.40;
PF_FD_ALTERADO = FD-QPA x FFD, sendo FFD entre 0,25 e 1,00, conforme tabela
abaixo (para funes de dados);
PF_FT_ALTERADO = FT-QPA x FFT, sendo FFT entre 0,25 e 1,50, conforme tabela
abaixo (para funes transacionais);
PF_ALTERADO = PF_FD_ALTERADO + PF_FT_ALTERADO.
Onde:
QPI = Quantidade de Pontos de Funo includos;
QPE = Quantidade de Pontos de Funo excludos;
PF_FD_ALTERADO = Pontos de Funo alterados para Funes de Dados;
PF_FT_ALTERADO = Pontos de Funo alterados para Funes Transacionais;
FD-QPA = Quantidade de Pontos de Funo alterados em funes de dados;
FT-QPA = Quantidade de Pontos de Funo alterados em funes transacionais;
FFD = Fator de impacto de alteraes em funes de dados;
FFT = Fator de impacto de alteraes em funes transacionais.
O clculo dos fatores de impacto so obtidos atravs dos percentuais de alteraes
conforme abaixo:
a) Funes de Dados:
Percentual de alteraes em funes de dados: PFD = QTDA / QTDT x 100;
QTDA = Quantidade de Tipos de Dados Alterados;
QTDT = Quantidade de Tipos de Dados Totais na Funo Original.
Com o valor obtido em PFD, procura-se na tabela qual o valor do fator de impacto:
63
________________________________________________________________________________
Fator de Impacto em Funes de Dados Alteradas (FFD)
PFD
Entre 0 e 33%
Entre 33% e 66%
Entre 66% e 100%
Maior que 100%
Fator de Impacto
(FFD)
0,25
0,5
0,75
b) Funes Transacionais:
Percentual alteraes em funes transacionais (PFT1) = QTDA / QTDT x 100;
Percentual alteraes em funes transacionais (PFT2) = QFTRA / QFTRT x 100;
QTDA = Quantidade de Tipos de Dados Alterados;
QTDT = Quantidade de Tipos de Dados Totais na Funo Original;
QARA = Quantidade de Arquivos Referenciados Alterados;
QART = Quantidade de Arquivos Referenciados Totais na Funo Original.
Fator de Impacto em Funes Transacionais Alteradas (FFT)
PFT2 / PFT1
Entre 0% e 66%
Entre 66% e 100%
Maior que 100%
Entre 0% e 33%
0,25
0,5
0,75
Entre 33% e 66%
0,5
0,75
Entre 66% e 100%
0,75
1,25
Maior que 100%
1,25
1,5
Caso FFT seja maior que 1, recomenda-se reconsiderar a melhoria.
64
________________________________________________________________________________
Anexo VI Notas Tcnicas das Verses Anteriores deste Roteiro

Nota Tcnica da Verso 1.0
A verso 1.0 do documento foi construda baseando-se no Roteiro SERPRO de
Mtricas para Contratos de Software, no Manual de Prticas de Contagem (CPM); nas
publicaes do International Function Point Users Group (IFPUG) e da Netherlands
Software Metrics Association (NESMA); e na literatura de mtricas e de engenharia de
software. Tambm foram consultados outros roteiros de rgos pblicos que j utilizavam
a mtrica Ponto de Funo em contratos de software.
A proposta inicial do roteiro foi submetida ao Grupo de Trabalho de Mtricas do
SISP, o qual contribuiu com sugestes de melhoria. Em seguida, as propostas foram
analisadas em reunio com especialistas em mtricas de rgos e entidades do SISP
para o fechamento e publicao da verso 1.0 do roteiro em novembro de 2010.
Equipe de Elaborao da Verso 1.0
Carlos Renato dos Santos Ramos SLTI/MP
Claudia Hazan SERPRO
Claudio Muniz Machado Cavalcanti SLTI/MP
Emanuelle Monteiro Silva SLTI/MP
Ftima Saldanha Cesarino CEF
Gileno Dias dos Santos SLTI/MP
Jose Romildo Araujo de Andrade SLTI/MP
Lucinia Turnes SLTI/MP
Marcelo Paiva Fernandes SLTI/MP
Maurcio Koki Matsutani DATAPREV
Patrcia Oliveira de Carvalho SUSEP
Rafael Campos SLTI/MP
Rafael Monteiro dos Santos Escolstico MEC
Regiane Andrade Brito BACEN
Rosa Maria da Costa Medeiros INEP
65

OFF - Roteiro de Metricas de Software Do SISP - V2.0

Diunggah oleh

Informasi Dokumen

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

OFF - Roteiro de Metricas de Software Do SISP - V2.0

Diunggah oleh

Hak Cipta:

Format Tersedia

Roteiro de Mtricas de Software do SISP

Ministra do Ministrio do Planejamento, Oramento e Gesto

Roteiro de Mtricas de Software do SISP 2.0

Roteiro de Mtricas de Software do SISP

Normalizao Bibliogrfica: DIBIB/CODIN/SPOA

Brasil. Ministrio do Planejamento, Oramento e Gesto. Secretaria de

Roteiro de Mtricas de Software do SISP 2.0

Roteiro de Mtricas de Software do SISP 2.0

Acrdo n 1.782/2007: recomenda o uso da mtrica Ponto de Funo como forma

Acrdo n 1.910/2007: em ateno ao princpio da eficincia, faz duas

Acrdos nos 1.125/2009 e 1.274/2010: determinam no vincular a mtrica de

Acrdos nos 2.348/2009 e 1.647/2010: reforam a determinao de no usar

O Manual de Prticas de Contagem de Pontos de Funo (CPM 4.3) [IFPUG,

Roteiro de Mtricas de Software do SISP 2.0

3. Contagem de Pontos de Funo

Figura 1: Procedimento de Contagem de Pontos de Funo

3.1 Determinar Propsito, Tipo e Escopo da Contagem e Fronteira da

Roteiro de Mtricas de Software do SISP 2.0

3.2 Identificar Funes de Dados e Funes Transacionais

Arquivo Lgico Interno (ALI)

Arquivo de Interface Externa (AIE)

Entrada Externa (EE)

Sada Externa (SE)

Consulta Externa (CE)

Tabela 1: Contribuio Funcional dos Tipos Funcionais (Fonte: CPM 4.3)

3.3 Calcular Tamanho Funcional

3.4 Requisitos No Funcionais

Roteiro de Mtricas de Software do SISP 2.0

4. Clculo de Pontos de Funo para o SISP

4.1 Projeto de Desenvolvimento

4.2 Projeto de Melhoria

FI = 50% para funcionalidade de sistema desenvolvida ou mantida por meio de

FI = 75% para funcionalidade de sistema no desenvolvida ou mantida por

FI = 90% para funcionalidade de sistema no desenvolvida ou mantida por

Este roteiro prope um fator de redocumentao menor para projetos de

Roteiro de Mtricas de Software do SISP 2.0

4.3 Projetos de Migrao de Dados

4.4 Manuteno Corretiva

Roteiro de Mtricas de Software do SISP 2.0

As demandas de manuteno corretiva no contemplam atualizao de

4.5 Mudana de Plataforma

4.5.1 Mudana de Plataforma - Linguagem de Programao

4.5.2 Mudana de Plataforma - Banco de Dados

4.6 Atualizao de Verso

4.6.1 Atualizao de Verso Linguagem de Programao

4.6.2 Atualizao de Verso Browser

4.6.3 Atualizao de Verso Banco de Dados

Roteiro de Mtricas de Software do SISP 2.0

4.7 Manuteno em Interface

4.8 Adaptao em Funcionalidades sem Alterao de Requisitos

FI = 50% para funcionalidade de sistema desenvolvida ou mantida por meio de

FI = 75% para funcionalidade de sistema no desenvolvida ou mantida por

Deve-se destacar que alm da adequao das funcionalidades em questo, a

Roteiro de Mtricas de Software do SISP 2.0

4.9 Apurao Especial

4.9.1 Apurao Especial Base de Dados

Roteiro de Mtricas de Software do SISP 2.0

4.9.2 Apurao Especial Gerao de Relatrios

Roteiro de Mtricas de Software do SISP 2.0

4.9.3 Apurao Especial Reexecuo

4.10 Atualizao de Dados

4.11 Desenvolvimento, Manuteno e Publicao de Pginas Estticas

Roteiro de Mtricas de Software do SISP 2.0

4.12 Manuteno de Documentao de Sistemas Legados