Roteirdo de Metricas SISP 2 1

ROTEIRO DE
MTRICAS DE SOFTWARE
DO SISP
VERSO 2.1
ROTEIRO DE
MTRICAS DE SOFTWARE
DO SISP
VERSO 2.1
Presidenta da Replblica
Dilma Vana Rousseff
Ministro do Planejamento, Oramento e Gesto
Nelson Barbosa
Secretria De Logstica E Tecnologia Da Informao
Cristiano Rocha Heckert
Diretor do Departamento de Governana e Sistemas de Informao
Wagner Silva de Arajo
Coordenador-Geral de Sistemas de Informaes
Orlando Batista da Silva Neto
Grupo de Mtricas de Software do SISP
Lucineia Turnes (SLTI/MP)
Valeria Maria Siqueira Bezerra (SLTI/MP)
Equipe de Elaborao da Verso 2.1
Cinthya Hiromi Seko de Oliveira SERPRO
Claudia Hazan - SERPRO
Daniella Elizabeth Carneiro - SERPRO
George Atsushi Murakami - TCU
Igor de Mesquita Barbosa - CGU
Jose Romildo Araujo de Andrade DTI/SE/MP
Gileno Dias dos Santos DTI/SE/MP
Ktia Cristina Barbosa Loschi de Melo - SERPRO
Lucineia Turnes SLTI/MP
Marcia Regina Guiotti Bomfim - MPT
Marcus Vinicius Borela de Castro - TCU
Tadeu Rocha - CGU
Valeria Maria Siqueira Bezerra SLTI/MP
Ministrio do Planejamento, Oramento e Gesto, 2015.

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 Atribuio-NoComercial-CompartilhaIgual 3.0 Brasil
Normalizao Bibliogrfica: CODIN/CGPLA/DIPLA

B823r
Brasil. Ministrio do Planejamento, Oramento e Gesto. Secretaria de
Logstica e Tecnologia da Informao.
Roteiro de Mtricas de Software do SISP: verso 2.1 / Ministrio do Planejamento, Oramento e Gesto.
Secretaria de Logstica e Tecnologia da Informao. Braslia : MP, 2015.
86 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
1Introduo............................................................................................................................................... 8
2Objetivo..................................................................................................................................................... 9
3Contagem de Pontos de Funo........................................................................................................ 10
3.1Determinar Propsito, Tipo e Escopo da Contagem e Fronteira da Aplicao..........................................................11
3.2Identificar Funes de Dados e Funes Transacionais............................................................................................12
3.3Calcular Tamanho Funcional...................................................................................................................................13
3.4Requisitos No Funcionais......................................................................................................................................14
4Clculo de Pontos de Funo para o SISP....................................................................................... 15

4.1Projeto de Desenvolvimento..................................................................................................................................16
4.2Projeto de Melhoria...............................................................................................................................................16
4.3 Projetos de Migrao de Dados.............................................................................................................................19
4.4Manuteno Corretiva............................................................................................................................................19
4.5Mudana de Plataforma.........................................................................................................................................20
4.5.1Mudana de Plataforma - Linguagem de Programao.........................................................................................21
4.5.2Mudana de Plataforma - Banco de Dados............................................................................................................21
4.6Atualizao de Verso............................................................................................................................................22
4.6.1Atualizao de Verso Linguagem de Programao............................................................................................23
4.6.2Atualizao de Verso Browser...........................................................................................................................23
4.6.3Atualizao de Verso Banco de Dados...............................................................................................................24
4.7Manuteno em Interface......................................................................................................................................24
4.8Adaptao em Funcionalidades sem Alterao de Requisitos Funcionais................................................................25
4.9Apurao Especial..................................................................................................................................................26
4.9.1Apurao Especial Base de Dados.......................................................................................................................27
4.9.2Apurao Especial Gerao de Relatrios...........................................................................................................28
4.9.3Apurao Especial Reexecuo...........................................................................................................................28
4.10Atualizao de Dados...........................................................................................................................................28
4.11Desenvolvimento, Manuteno e Publicao de Pginas Estticas de Intranet, Internet ou Portal.........................29
4.12Manuteno de Documentao de Sistemas Legados...........................................................................................30
roteiro de mtricas de software do sisp
4.13Verificao de Erros..............................................................................................................................................30
4.14Pontos de Funo de Teste....................................................................................................................................31
4.15Componente Interno Reusvel..............................................................................................................................31
5Orientaes Complementares para Contagem............................................................................. 32

5.1Contagem de Pontos de Funo com Mltiplas Mdias...........................................................................................32
5.1.1Cenrio 1: Mesmos dados apresentados em tela e impressos..............................................................................33
5.1.2Cenrio 2: Mesmos dados de sada como dados em arquivo e relatrio impresso...............................................33
5.1.3Cenrio 3: Mesmos dados de entrada batch e on-line.....................................................................................34
5.1.4Cenrio 4: Mltiplos canais de entrega da mesma funcionalidade.......................................................................34
5.1.5Cenrio 5: Relatrio em mltiplos formatos..........................................................................................................34
6Consideraes Especiais para Planejamento e Acompanhamento de Projetos................... 35

6.1Diretrizes para Planejamento: Estimativas de Projetos de Software........................................................................35
6.1.1Contagem Estimativa de Pontos de Funo (CEPF)................................................................................................38
6.1.2Estimativa de Esforo de Projetos de Software......................................................................................................42
6.1.2.1Distribuio de Esforo por Fase do Projeto......................................................................................................................... 43
6.1.3Estimativa de Prazo de Projetos de Software.........................................................................................................43

6.1.4Alocao de Equipe ao Projeto..............................................................................................................................46
6.1.5Mtodo para Estimativa de Custo..........................................................................................................................47
6.1.6Estimativa de Recursos Computacionais................................................................................................................47
6.2Diretrizes para Acompanhamento de Projetos........................................................................................................48
6.2.1Consideraes sobre Mudana de Requisitos........................................................................................................48
6.2.2Consideraes sobre Projetos Cancelados.............................................................................................................54
6.2.3Gerenciamento de Progresso de Projetos..............................................................................................................55
6.2.4Consideraes sobre Reduo de Cronograma......................................................................................................56
6.2.5Fator de Criticidade de Solicitao de Servio.......................................................................................................57
7Contagem de Pontos de Funo no Desenvolvimento de Software utilizando

Mtodos geis.............................................................................................................................................. 57
7.1Conceitos...............................................................................................................................................................58
7.2Orientaes............................................................................................................................................................59
7.3Tratamento de Mudanas em Funcionalidades no Processo gil.............................................................................60
7.3.1Fatores que Influenciam o Nmero de Mudanas em Funcionalidades no Processo gil.....................................61
7.3.1.1Exemplo de Aplicao da Proposta...................................................................................................................................... 62
8Atividades Sem Contagem de Pontos de Funo........................................................................... 65

9Processo de Reviso do Roteiro de Contagem.............................................................................. 67
9.1Reviso para Correo de Inconsistncias e Situaes no Previstas.......................................................................67

9.2Reviso para Adoo de Novas Verses do CPM.....................................................................................................67
10Concluso............................................................................................................................................. 67
11Referncias Bibliogrficas............................................................................................................... 68
Anexo I Portaria SLTI/MP N 31, de 29 de Novembro de 2010............................................................ 70
Anexo III Modelo de Documento de Contagem de Pontos de Funo Projetos de
Manuteno Pequenos (< 100 PF)............................................................................................................. 75
Anexo IV - Como Evitar Armadilhas em Contratos de Desenvolvimento e
Manuteno de Sistemas.......................................................................................................................... 76
Anexo V Resumo da Tcnica EFP (Enhancement Function Points) publicada pela NESMA..... 82
Anexo VI Notas Tcnicas das Verses Anteriores deste Roteiro................................................. 84
ndice de Figuras
Figura 1: Procedimento de Contagem de Pontos de Funo............................................................................................ 11
Figura 2: Processo de Estimativas de Projetos de Software [Hazan, 2008] ...................................................................... 36
Figura 3: Modelo Lgico da Anlise de Pontos de Funo............................................................................................... 39
Figura 4: Relao entre a Estimativa de Prazo e de Esforo............................................................................................. 44
ndice de Tabelas
Tabela 1: Contribuio Funcional dos Tipos Funcionais................................................................................................... 13
Tabela 2: Identificao dos Arquivos Lgicos Internos da Aplicao................................................................................ 40
Tabela 3: Identificao dos Arquivos de Interface Externa da Aplicao.......................................................................... 40
Tabela 4: Identificao das Entradas Externas da Aplicao............................................................................................ 41
Tabela 5: Identificao das Consultas Externas da Aplicao........................................................................................... 41
Tabela 6: Identificao das Sadas Externas da Aplicao................................................................................................ 42
Tabela 7: Distribuio de Esforo por Macroatividades do Projeto.................................................................................. 43
Tabela 8: Expoente t por tipo de Projeto........................................................................................................................ 45
Tabela 9: Estimativa de Prazo de Projetos menores que 100 PF...................................................................................... 45
Tabela 10: Percentuais definidos para a mudana de requisitos...................................................................................... 49
Tabela 11: Planejamento do Backlog das Sprints da Release N . ..................................................................................... 62
Tabela 12: Contagem Detalhada de Pontos de Funo da Release N. ............................................................................. 65
Tabela 13: Contagem de PF da Release N para Baseline da Aplicao . ............................................................................65
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/MP N 4, de 11 de setembro de 2014, recomenda o uso de mtricas em
contratos de projetos de software, restringindo o uso da mtrica de esforo homem-hora. 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, XXIV, da IN
SLTI n 04/2014. 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 fun-
cional 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 capitulo 6 define um
processo de estimativas e recomendaes para o gerenciamento de projetos contratados com base em
mtricas; o captulo 7 traz uma proposta para conciliar o uso da mtrica Ponto de Funo em contrataes de desenvolvimento de software usando mtodos geis com o objetivo de minimizar os riscos para o
tratamento de mudanas em funcionalidades; o captulo 8 apresenta algumas atividades que no devem
ser consideradas nas contagens de pontos de funo; o captulo 9 apresenta o processo de reviso deste
guia de contagem; finalmente, o captulo 10 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 organiza-
es nas estimativas de tamanho, custo, prazo e esforo de seus projetos desenvolvidos internamente ou
contratados.
A verso 2.1 apresenta uma pequena variao com relao verso anterior 2.0:
alterao no fator de impacto de 40% para 30% para as funcionalidades excludas de um Projeto
de Melhoria (seo 4.2).
ajuste no tratamento e contagem em pontos de funo para o item denominado Componente
Interno Reusvel, apresentado na seo 4.15 deste documento.
correo dos percentuais da Tabela 10 referentes ao retrabalho decorrente de mudanas
de requisitos durante o desenvolvimento ou manuteno do software. Consequentemente,
ainda na subseo 6.2.1 Consideraes sobre Mudanas de Requisitos foram atualizados os
exemplos que mostram a aplicao desses percentuais da Tabela 10.
criao de um novo captulo (Captulo 7) que aborda o tratamento das mudanas em
funcionalidades em um projeto de desenvolvimento usando mtodos geis, principalmente,
para o cenrio de contrataes de software usando a mtrica Ponto de Funo.
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
10
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
Identique os
requisitos
funcionais
Identicar o Propsito
da Contagem
Identicar 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.1Determinar 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
11
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.2Identificar 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.
12
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.
Tipo Funcional
Complexidade
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.3Calcular 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.
13
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.4Requisitos 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.
14
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 aderente aos Padres de Interoperabilidade de Governo
Eletrnico (e-PING).
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 Tabela7 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);
15
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.1Projeto 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
Este roteiro recomenda a supresso do PF_CONVERSO das frmulas de 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.2Projeto 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,30 x PF_EXCLUIDO) + PF_CONVERSO
16
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.
FI = 90% para funcionalidade de sistema no desenvolvida ou mantida por 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, deve-se 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.
Este roteiro recomenda a supresso do PF_CONVERSO das frmulas de 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
17
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.
18
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.4Manuteno 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
19
Manuteno Emergencial como manuteno corretiva no programada executada para manter o sistema
em estado operacional.
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.5Mudana 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 funcio-
20
nalidades 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.
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.1Mudana 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 CPM4.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.2Mudana 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.
21
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.
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.6Atualizao 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).
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 funcio-
22
nalidades 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.1Atualizao 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
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.2Atualizao 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.
Recomenda-se enfaticamente a realizao da anlise de impacto das mudanas 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
23
citado acima. importante ressaltar que os sistemas Web devem seguir o padro W3C, como recomendado na e-Ping. Caso seja necessrio fazer a adequao do sistema para atendimento ao padro W3C,
pode-se usar a frmula acima.
4.6.3Atualizao 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
4.7Manuteno 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
24
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 avaliao da base histrica dos servios realizados no rgo ou entidade.
4.8Adaptao 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:
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.
25
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.
FI = 75% para funcionalidade de sistema no desenvolvida ou mantida por 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 avaliao da base
histrica dos servios realizados no rgo ou entidade.
4.9Apurao 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.
26
4.9.1Apurao 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
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
27
4.9.2Apurao 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
4.9.3Apurao 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.10Atualizao 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.
28
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 conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
4.11Desenvolvimento, 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.
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.
29
4.12Manuteno 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.
4.13Verificao 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
30
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.14Pontos 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
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.15Componente Interno Reusvel

Em alguns casos so demandadas manutenes em componentes, que implementam regras de negcio, especficos de uma 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 sua alterao seja contada aplicando-se um fator de impacto (FI)
sobre o PF_ALTERADO, seguindo os conceitos do CPM 4.3, apresentados na seo 4.2 - Projeto de Melhoria. 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.
31
PF_COMPONENTE = FI X PF_ALTERADO
Exemplo de manuteno de componentes:
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.
Alm disso, existem casos onde so realizadas manutenes de valores de elementos internos
de configurao que afetam 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 e arquivos de internacionalizao. Nestes casos, a aferio
do tamanho em pontos de funo 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. Assim sendo, deve ser utilizada a seguinte frmula de clculo:
PF_COMPONENTE_ARQUIVO = 0,6 PF x QTD_ARQUIVOS_ALTERADOS
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.1Contagem 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
32
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.
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.1Cenrio 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.2Cenrio 2: Mesmos dados de sada como dados em arquivo e relatrio impresso
33
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.3Cenrio 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.4Cenrio 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.
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.5Cenrio 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 desen-
34
volvimento 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.1Diretrizes 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.
35
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 nais
e Lies Aprendidas
Estimar Recursos
Computacionais Crticos
Reestimar , conforme
necessidade
Estimar Tamanho
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].
36
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 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.
37
As subsees seguintes apresentam os mtodos de estimativas de tamanho, prazo, custo e esforo a

serem utilizados nos projetos de software em contratos.
6.1.1Contagem 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.
38
Documentao do
Software
Abstrao orientada a dados

Usurios
Identicao dos itens da APF
Aplicao
Transaes
(EEs, CEs, SEs)
Pontos de Funo
(nmeros)
Mapeamento 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
39
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 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
40
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.
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
41
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.
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
Este roteiro recomenda a supresso do PF_CONVERSO das frmulas de contagem de pontos de funo de projetos de desenvolvimento, conforme descrito na seo 3.3.
6.1.2Estimativa 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.
42
Cada rgo ou entidade dever possuir sua prpria tabela de produtividade para cada linguagem,
considerando-se sempre dados histricos dos projetos j realizados.
6.1.2.1Distribuio 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 subdividi-las 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.3Estimativa 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
43
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
Custo do Esforo
t: o expoente t definido de acordo com a Tabela 8
Regio Impossvel
(75% de Td)
Td
Tempo de Desenvolvimento
Observaes:
1) Td o tempo timo de desenvolvimento.
2) To o tempo que acarreta o menor custo.
3) To = 2 Td.
4) impossvel terminar em menos que 0,75*Td.
Figura 4 - Relao entre a Estimativa de Prazo e de Esforo
44
To
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.
Prazo mximo (em dias teis)
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
Tamanho do Projeto
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
45
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 conforme avaliao
da base histrica dos servios realizados no rgo ou entidade.
Na seo seguinte abordada a questo da distribuio de esforo e alocao de pessoas ao projeto.
6.1.4Alocao 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.
46
6.1.5Mtodo 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.6Estimativa 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]
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.
47
6.2Diretrizes 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.1Consideraes 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, utilizando-se 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, 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
48
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:
Fator
Acrscimo
Tipo da Mudana
de Requisito
Alterao de
Requisitos
Alterao
Alterao de
Interface
Desistncia
Incluir
Funo
Requisito Original
Alterar
Funo
Excluir
Funo
50%
50%
0,6 PF
0,6 PF
130%
80%
30%
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.
Observaes Importantes:
49
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 50% 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.
50
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 * 50% = 3 PF
PF_MELHORIA v1 = 10 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 50%Nota 1 = 4,5 PF
PF_RETRABALHO = 4,5 PF x 90%Nota 2
PF_RETRABALHO = 4,05 PF
Nota 1: 50% 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: 4,5 PF * 90% = 4,05 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 * 50% = 3 PF
PF_MELHORIA v2: 11 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:
51
SE original: 4 PF
PF_RETRABALHO = 0,6 PF Nota 3
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.
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. Enquadram-se nesta situao somente as desistncias de incluir, de alterar ou de excluir funcionalidades que constavam no escopo do projeto.
Quando a mudana no projeto for deixar de incluir uma funo, aplica-se o percentual de 130% ao
tamanho da funo original. Esse valor resultado da soma do percentual de 100% da incluso (escopo
original) com os 30% correspondentes excluso dessa mesma funo.
Quando a mudana no projeto for deixar de alterar uma funo, aplica-se o percentual de 80% ao
tamanho da funo original. Esse valor o resultado da soma do percentual de 50% da alterao (escopo
original) com os 30% referentes excluso dessa mesma funo.
Quando a mudana no projeto for deixar de excluir uma funo, aplica-se apenas o percentual de 30%
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, con-
52
forme 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.
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 130%Nota 5 = 6,5 PF
Nota 5: 130% o percentual a ser aplicado sobre o tamanho da funo original antes da desistncia
da sua incluso, conforme apresentado na Tabela 10.
de mudana) registra progresso de 35%. Assim, para fins de gesto e faturamento, o valor do PF_RETRABALHO seria o correspondente a: 6,5 PF * 35% = 2,275 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 80% Nota 7= 4 PF
PF_RETRABALHO = 4 PF x 35%Nota 8
53
Nota 7: 80% o percentual a ser aplicado sobre o tamanho da funo original antes da desistncia da
sua alterao, conforme apresentado na Tabela 10.
de mudana) registra progresso de 35%. Assim, para fins de gesto e faturamento, o valor do PF_RETRABALHO seria o correspondente a: 4 PF * 35% = 1,4 PF cheios.
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 * 50% = 2,5 PF
PF_ MELHORIA v2 = PF_ MELHORIA v1 (Alterao de SE)
PF_ MELHORIA v2 = PF_ MELHORIA v1 (2,5 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 exclu0m 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.2Consideraes 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.
54
6.2.3Gerenciamento 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.
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
Engenharia de
Requisitos
Design,
Arquitetura
Implementao
Testes
Homologao
Implantao
Caso de Uso 1
Atividade
Incluir Ativ.
Alterar Ativ
Excluir Ativ
Consultar Ativ
19 PF
50,00%
20%
0%
10%
0%
0%
Caso de Uso 2
Relatrio de
Projetos
5 PF
100 %
100%
50%
20%
0%
0%
....
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
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
Macroatividades
Total: 2,9 PF
55
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 50% na contagem
de PF. Portanto, a contagem do PF_RETRABALHO 2,9 x 0,50 = 1,45 PF.
6.2.4Consideraes 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 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.
56
6.2.5Fator 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 Contagem de Pontos de Funo no Desenvolvimento de Software

utilizando Mtodos geis
Este captulo descreve orientaes sobre o uso da mtrica Ponto de Funo na medio e remunerao de servios de desenvolvimento de software com mtodos geis, a fim de subsidiar as contrataes
desses servios na Administrao Pblica Federal (APF).
Uma das principais dificuldades e desafios na adoo de mtodos geis em contratao de desenvolvimento de software definir um modelo de remunerao que seja equilibrado, remunerando de forma
justa o esforo da contratada para atender o volume de refinamentos e mudanas em funcionalidades e,
ao mesmo tempo, no onerando de forma excessiva a contratante (instituies pblicas), ou seja, o valor
pago deve corresponder aos servios recebidos e o ciclo do processo gil de desenvolvimento de software
no deve influenciar negativamente o ciclo de faturamento do projeto. Devido s caractersticas inerentes
ao processo gil, entende-se que os refinamentos e as mudanas em funcionalidades so mais constantes
e recorrentes nesse cenrio de desenvolvimento de software, pois pressupe-se um escopo mais aberto.
Entretanto, o processo gil de desenvolvimento de software em contrataes no deve comprometer os
princpios de economicidade e efetividade dos resultados previstos e entregues com a garantia da exequibilidade do projeto.
importante observar que, conforme a Smula TCU 269, a remunerao nas contrataes de servios
de Tecnologia da Informao deve estar vinculada entrega de resultados ou ao atendimento de nveis
de servio. Portanto, relevante que o modelo de remunerao, nveis de servio e critrios de qualidade
para a aceitao dos resultados entregues ao final das iteraes (sprints) do processo gil estejam claramente definidos no instrumento convocatrio e sejam observados e aferidos durante a gesto do contrato.
O propsito deste trabalho possibilitar a adoo de um modelo de faturamento baseado na mtrica
Ponto de Funo, capaz de medir a entrega de resultados do projeto, em contrataes de desenvolvimento de software usando mtodos geis. Os objetivos e premissas considerados neste trabalho foram:
57
Buscar a simplicidade na medio do desenvolvimento de software com mtodos geis para

viabilizar o seu uso em contrataes com responsabilidade e garantir o alcance dos benefcios
do processo gil ao negcio;
Fortalecer a necessidade e importncia de registro das mudanas em funcionalidades para
promover a criao de uma base histrica de projetos com desenvolvimento gil, alm de
permitir a rastreabilidade e o atendimento de auditorias nos projetos;
Minimizar o nus na gesto de projeto advindo da utilizao do processo gil em contrataes
de software, tanto para a contratante (gestor de TI) quanto para a contratada;
Simplificar o nus de gesto e controle de mudanas de forma a minimizar impactos sobre a
agilidade do processo de desenvolvimento;
Prever, medir e remunerar o esforo e o volume de mudanas em funcionalidades em um
projeto com desenvolvimento gil;
Promover a oferta de preos exequveis para a realizao de contratos de prestao de servios
de desenvolvimento de software com mtodos geis, a partir da publicidade de caractersticas
do projeto e da equipe de desenvolvimento previamente especificadas no edital de contratao;
Incentivar o uso de desenvolvimento gil no governo com o aprimoramento da maturidade
e competncia da equipe envolvida, buscando a eficincia do processo e dos resultados
esperados.
Nesse sentido, so apresentadas recomendaes de medio em Ponto de Funo, que podem ser
adotadas nas contrataes de desenvolvimento de software com mtodos geis, para o tratamento dos
refinamentos e mudanas em funcionalidades durante o projeto. Essas recomendaes foram definidas
aps o levantamento e avaliao da literatura e de guias de contagem de rgos do governo que utilizam alguma abordagem de medio para o cenrio de desenvolvimento de software com mtodos geis
[CAIXA, 2012], [Castro e Hernandes, 2013], [Horvath, 2012], [Keote, 2010], [NESMA, 2009] e [PROCERGS, 2013]. Realizou-se, ainda, um benchmarking em rgos do governo que j implementam contratos
de desenvolvimento de software com mtodos geis e, por fim, foram realizadas reunies tcnicas com
especialistas em desenvolvimento gil e na mtrica Ponto de Funo para discutir e refinar a proposta
apresentada neste documento.
7.1Conceitos
No cenrio de desenvolvimento de software com mtodos geis e dentro do contexto deste roteiro,
importante alinhar os seguintes conceitos:
Release: um ciclo que perpassa pelas fases do processo de desenvolvimento de software com o
objetivo de entregar, ao final do ciclo, um produto pronto a ser colocado em produo para uso.
A durao de cada release ser definida pela contratante na fase de planejamento do projeto conforme seu backlog priorizado de forma a garantir uma entrega de valor antecipada aos usurios.
58
Sprint: uma unidade de perodo de tempo fixo (time box) dentro da release, com datas de incio
e fim pr-definidas, dentro da qual executado um conjunto de atividades de desenvolvimento do
projeto previamente estabelecidas, gerando ao final um incremento do produto aceito e potencialmente implantvel.
Ciclo de Pagamento: perodo definido para fins de pagamento e apurao dos resultados entregues, podendo consistir de uma iterao (sprint), de um conjunto de iteraes, ou de uma release.
Considerando os critrios adotados para o projeto, como o tamanho da iterao (sprint), o tamanho da release, a produtividade da equipe do projeto e a expectativa de fluxo de caixa da contratada para manter seu equilbrio econmico-financeiro no atendimento do contrato, deve-se realizar
o faturamento por iterao (sprint), por grupo de iteraes, ou por release, desde que sempre
devidamente associado aos produtos entregues e aceitos de uma ordem de servio.
Produto Pronto: Visando a remunerao da contratada a partir da medio de resultados gerados
em um ciclo de pagamento, entende-se que um produto est pronto se foi entregue e aceito.
Cabe observar que o desenvolvimento de uma funcionalidade pode perpassar mais de uma sprint
e conter vrias histrias de usurios prontas e validadas em sprints diferentes. Nesse caso, a funcionalidade s ser considerada para fins de pagamento ao final do ciclo de pagamento em que
estiver com todas as suas histrias componentes prontas.
Refinamentos: so quaisquer mudanas ocorridas sobre uma funo transacional ou de dados j
previamente trabalhada(s) na release corrente (seja por meio de uma incluso, alterao ou excluso), provocadas pelo aprofundamento, detalhamento e complementao de requisitos durante o
processo de desenvolvimento.
7.2Orientaes
O desenvolvimento de software utilizando mtodos geis deve respeitar uma abordagem especfica
que considere as caractersticas dos mtodos geis, tanto no desenvolvimento quanto na gesto do projeto. Entretanto, essas caractersticas podem requerer adaptaes para o contexto de contrataes de
software na APF, no sentido de atender o cumprimento da legislao e dos princpios de economicidade
e eficincia. Nesse cenrio, algumas consideraes e sugestes so propostas para o desenvolvimento de
software utilizando mtodos geis na APF:
Remunerao baseada nos resultados entregues e aceitos (Produto Pronto);
Remunerao sempre atrelada a uma ordem de servio;
Promover o fluxo de demandas do projeto e o equilbrio econmico-financeiro da contratada;
Diviso do projeto de desenvolvimento ou manuteno em releases;
Ciclo da sprint (iterao) de 2 at 4 semanas;
Ciclo da release no deve ser igual ao ciclo da sprint, ou seja, release formada por apenas uma
sprint no permite a adoo das orientaes trazidas neste documento;
59
Ciclo da release deve, sempre, promover o aumento do percentual de completude do sistema

(entrega de valor agregado ao negcio);
Para as funcionalidades que precisem de mais de uma sprint para serem desenvolvidas,
recomenda-se que sejam contadas somente na sprint em que forem entregues e aceitas;
Realizar a contagem estimativa do projeto, a fim de definir o tamanho estimado ao final de um
ciclo de pagamento para efeito de planejamento do projeto e gerao das ordens de servio
de desenvolvimento ou manuteno de software.
Para efeito de gesto das mudanas e gerao de indicadores, recomenda-se que as mudanas em
funcionalidades sejam registradas em planilha separada da contagem do projeto de desenvolvimento.
Nessa planilha de mudanas devem ser registradas todas as funcionalidades includas, alteradas e excludas, porm, para efeito de faturamento, sugere-se que as funcionalidades includas sejam remuneradas
somente na contagem final do ciclo de pagamento, conforme modelo de remunerao adotado para o
projeto, a fim de no existir duplicidade de remunerao.
Caso o ciclo de pagamento seja por sprint, sugere-se adotar, como critrio de remunerao para a
sprint, um valor percentual do tamanho total planejado da release ou uma medida que reflita o valor agregado dos produtos prontos da sprint dentro da release. Essa sugesto visa no onerar as partes envolvidas
com a medio, controle e gesto de mudanas a cada sprint, principalmente, quando a durao dessas
iteraes so muito curtas. Caso a remunerao seja realizada por sprint, sugere-se reter um percentual
do total da remunerao da iterao (sprint) para o final da release, principalmente, quando a concluso
da implantao do produto pronto da sprint ocorrer no final da release.
O A seo 6.2 - Diretrizes para Acompanhamento de Projetos deste Roteiro no deve ser aplicado para
projetos de desenvolvimento de software com mtodos geis, em virtude da adoo das orientaes contidas neste captulo especfico para projetos dessa natureza.
7.3Tratamento de Mudanas em Funcionalidades no Processo gil

Esta seo apresenta orientaes sobre o tratamento de mudanas em funcionalidades para contratos de desenvolvimento de software com mtodos geis usando a mtrica Ponto de Funo.
As mudanas em funcionalidades podem ser decorrentes de mudanas no domnio do negcio - como
alterao de escopo, de regras de negcio - ou mudanas legais/regulamentares ou, ainda, refinamentos
de requisitos. Considerando os aspectos do desenvolvimento gil, as mudanas em funcionalidades que
ocorrerem aps o trmino da release em que essas funcionalidades ficaram prontas, devem ser tratadas
de acordo com o item Projeto de Melhoria deste Roteiro, uma vez que este guia considera que, no desenvolvimento de software com mtodos geis, o ciclo de trabalho evolutivo em funcionalidades desenvolvidas em uma release encerra-se ao final da release. Assim, como prtica comum existirem mudanas
em uma funcionalidade ainda durante a execuo das sprints de uma release, este guia sugere que as
mudanas em funcionalidades ocorridas dentro dessas caractersticas no sejam contadas e, consequen-
60
temente, no sejam remuneradas durante a release (ou seja, nos ciclos de pagamento do projeto), mas
que j estejam absorvidas pela contratada como parte inerente do processo gil de desenvolvimento
adotado para o projeto.
Nesse sentido, fundamental que o instrumento convocatrio de licitao especifique o mximo de
fatores, caractersticas e aspectos relevantes do projeto que podem influenciar no volume de mudanas
em funcionalidades em um projeto de desenvolvimento com mtodos geis para que as empresas candidatas ao certame avaliem adequadamente as possibilidades de atendimento do contrato, fornecendo profissionais qualificados e preo de ponto de funo exequvel para o contrato. Dessa forma, importante
destacar a necessidade do rgo contratante avaliar e controlar a sua gesto de riscos pela adoo de um
contrato de desenvolvimento de software com mtodos geis. O risco poder se mostrar inversamente
proporcional ao detalhamento dos fatores, caractersticas e aspectos do projeto expostos no edital de
contratao que possam interferir no desenvolvimento e no sucesso do projeto.
7.3.1Fatores que Influenciam o Nmero de Mudanas em Funcionalidades no Processo gil

Nesta subseo apresentamos alguns fatores que influenciam o nmero de mudanas em funcionalidades no projeto de desenvolvimento de software com mtodos geis. Esses fatores podem ser levantados, por exemplo, de uma base histrica de projetos similares do rgo, experincias registradas de
projetos com desenvolvimento gil j realizados pelo rgo e entrevistas com prestadores de servios de
desenvolvimento de software com mtodos geis.
Como foi dito na seo anterior, dentro de uma release, as mudanas em funcionalidades desenvolvidas previamente na mesma release no so contadas e remuneradas durante o projeto, pois so absorvidas pela contratada como parte do processo de desenvolvimento gil. Entretanto, caso essas mudanas
ocorram em releases diferentes, sugere-se remunerar conforme os itens de manuteno abordados neste
Roteiro, tal como, a manuteno evolutiva aplicando-se o fator de impacto sobre o tamanho da funcionalidade impactada, conforme sugerido no item Projeto de Melhoria deste Roteiro.
Apesar de no serem contadas em ponto de funo, essas mudanas em funcionalidades j desenvolvidas dentro da mesma release devem ser registradas e atendidas pelo contrato, mas sem remunerao
adicional ao total de pontos de funo da contagem detalhada final da release, pois se entende que so
relativas evoluo de requisitos do processo de desenvolvimento adotado no projeto. Portanto, na contagem detalhada final da release no deve haver nem acrscimo de ponto de funo nem de qualquer
outra natureza.
Alguns fatores devem ser considerados e avaliados para a estimativa do volume de mudanas em funcionalidades em um projeto de desenvolvimento com mtodos geis:
maturidade dos requisitos do projeto;
conhecimento do negcio pelo product owner;
maturidade do processo gil implantado no rgo (nvel de aderncia s prticas);
disponibilidade e experincia com mtodos geis da rea de negcio (product owner);
61
nvel de experincia com mtodos geis da equipe da contratante (principalmente do product

owner);
nvel de experincia com mtodos geis requerido para a equipe de desenvolvimento da
contratada;
tamanho da sprint e da release;
volume de mudanas em funcionalidades de projetos similares j executados.
7.3.1.1Exemplo de Aplicao da Proposta

Para exemplificar a aplicao dessa proposta de tratamento das mudanas em funcionalidades em um
projeto de desenvolvimento com mtodos geis, suponha o planejamento das iteraes (sprints) de uma
release (Release N) com quatro funcionalidades a serem desenvolvidas (includas) e duas funcionalidades
prontas em releases anteriores para serem alteradas, conforme apresentado na Tabela 11. O tamanho
estimado do backlog da Release N de 21 PF. Considere que, ao final da Release N, as funcionalidades
includas devem estar prontas para serem remuneradas para a contratada.
Release N
(composta de 3
Sprints)
Processo
Elementar (PE)
Categoria (Inc,
Alt, Exc, Refin)
Tipo
(ALI, AIE, EE,
CE, SE)
Complex.
PF
Incluir
Aluno
Inc
EE
Baixa
Aluno
Inc
ALI
Baixa
Sprint 1
Sprint 2
Sprint 3
Incluir
Disciplina
Alt
EE
Baixa
1,5
Alterar
Aluno
Inc
EE
Baixa
Alterar
Disciplina
Alt
EE
Baixa
1,5
Emitir
Relatrio de
Alunos por
Disciplina
Inc
SE
Mdia
Total de PF da release
Observao
Alterao caracterizada
como Projeto de Melhoria
(PE Incluir Disciplina
desenvolvido e pronto na
Release N-1). Aplicado o
fator de impacto de 50%
(3PF*0,5=1,5PF).
Alterao caracterizada
como Projeto de Melhoria
(PE Alterar Disciplina
desenvolvido e pronto na
Release N-1). Aplicado o
fator de impacto de 50%
(3PF*0,5=1,5PF).
21
Tabela 11 Planejamento do Backlog das Sprints da Release N

62
A contagem detalhada de pontos de funo da Release N est apresentada na Tabela 12. Observa-se
que no existe medio para as mudanas em funcionalidades desenvolvidas na mesma Release N. Mas,
o objetivo principal mostrar a necessidade de registrar as funcionalidades includas, alteradas, excludas
e refinamentos (mudanas em funcionalidades desenvolvidas na mesma release) durante a release, independente do registro e da identificao da iterao (sprint) onde elas ocorreram. Nesse sentido, facultativo o registro das contagens por sprint desde que a contagem da release registre as novas funcionalidades
desenvolvidas, bem como, as mudanas em funcionalidades.
A Tabela 12 apresenta a contagem de pontos de funo e o detalhamento dos servios realizados na
execuo da Release N e suas sprints, incluindo os processos elementares planejados (incluso e alterao
em funcionalidades) e as mudanas em funcionalidades previamente desenvolvidas na mesma release,
essas categorizadas como Refinamento, que foram identificadas durante o desenvolvimento da Release
N. Destaca-se, por exemplo, que o processo elementar Alterar Disciplina foi alterado na sprint 2, sendo
essa mudana categorizada como Alterao do Projeto de Melhoria. Em seguida, na sprint 3 houve
uma nova mudana no mesmo processo elementar Alterar Disciplina, sendo essa mudana categorizada
como Refinamento pois trata-se de uma mudana em funcionalidade j trabalhada na mesma release.
Alm disso, observe que houve a necessidade de alterar o processo elementar Emitir Relatrio de Disciplinas identificada durante o desenvolvimento da funcionalidade planejada Emitir Relatrio de Alunos
por Disciplina. Essa alterao foi classificada como Alterao do Projeto de Melhoria, pois a funcionalidade Emitir Relatrio de Disciplinas j estava pronta (ou seja, foi desenvolvida em release anterior).
Portanto, no desenvolvimento de projetos com mtodos geis, uma mudana em funcionalidade poder
ser classificada em Refinamento ou Alterao, a depender se a funcionalidade foi desenvolvida na
mesma release ou no.
Na Tabela 12, as mudanas em funcionalidades do tipo Refinamento foram absorvidas pela contratada e, portanto, no houve remunerao adicional ao total de pontos de funo da Release N. Assim
sendo, conforme apresentado na Tabela 12, a contagem final da Release N foi de 22,5 PF, que representa
o valor a ser remunerado contratada e corresponde s funcionalidades includas (18 PF) e alteradas (4,5
PF alteraes caracterizadas como Projeto de Melhoria) na Release N. Portanto, considerando o ciclo
de pagamento adotado, a remunerao da contratada para a release corresponder ao tamanho em
pontos de funo das funcionalidades includas acrescida do valor em pontos de funo das mudanas
(alteraes e excluses caracterizadas como Projeto de Melhoria) em funcionalidades ocorridas durante
a mesma release, excluindo-se os refinamentos (mudanas em funcionalidades desenvolvidas na mesma
release) que no so contados e remunerados durante o projeto.
Sugere-se que o registro das mudanas em funcionalidades seja feito em uma planilha de contagem
separada aplicando-se as regras de medio sugeridas neste Roteiro. O campo Categoria nas Tabelas 11
e 12 mostra, alm dos tipos Inc (incluso), Alt (alterao) e Exc (excluso) de funcionalidades, o tipo Refin
(Refinamento) para representar as mudanas em funcionalidades desenvolvidas na mesma release.
63
Release N
(composta de 3
Sprints)
Tipo
Categoria
(Inc, Alt,
Exc, Refin)
(ALI, AIE,
EE, CE, SE)
Complex.
PF
Incluir Aluno
Inc
EE
Baixa
Aluno
Inc
ALI
Baixa
Processo Elementar
(PE)
Sprint 1
Incluir Disciplina
Alt
EE
Baixa
1,5
Alterar Aluno
Inc
EE
Baixa
Aluno
Refin
ALI
Baixa
Alterao caracterizada como

Projeto de Melhoria (PE Alterar
Disciplina desenvolvido e
pronto na Release N-1). Aplicado
o fator de impacto de 50%
(3PF*0,5=1,5PF).
Alterar Disciplina
Alt
EE
Baixa
1,5
Emitir Relatrio
de Alunos por
Disciplina
Inc
SE
Mdia
Incluir Disciplina
Refin
Refin
EE
EE
Baixa
Baixa
Mudana caracterizada como

refinamento de funcionalidade
para atender o PE Emitir Relatrio
de Alunos por Disciplina. Sem
custo PF.

custo PF.

custo PF.
1,5

Projeto de Melhoria (PE Emitir
Relatrio de Disciplinas
desenvolvido e pronto na Release
N-1). Aplicado o fator de impacto
de 50% (3PF*0,5=1,5PF).
Sprint 3
Alterar
Disciplina
Emitir Relatrio
de Disciplinas
64
Refin
Alt
EE
EE
Baixa
Baixa

Projeto de Melhoria (PE Incluir
Disciplina desenvolvido e
pronto na Release N-1). Aplicado
o fator de impacto de 50%
(3PF*0,5=1,5PF).
para atender o PE Alterar Aluno.
Sem custo PF.
Sprint 2
Incluir Aluno
Observao
22,5
Total de PF da release
Tabela 12 Contagem Detalhada de Pontos de Funo da Release N
A Tabela 13 apresenta a contagem de pontos de funo da Release N para a baseline da aplicao.

Observe que nessa contagem aparecem apenas as funcionalidades includas e no devem constar as funcionalidades alteradas, excludas e refinamentos durante a Release N, a menos que tais mudanas tenham
impactado na complexidade da funo de dados ou transacional. O total de pontos de funo da Release
N para a baseline da aplicao de 18 PF.
Processo
Elementar (PE)
Tipo (ALI, AIE, EE,

CE, SE)
Complex.
PF
ALI
Baixa
Incluir Aluno
EE
Baixa
Alterar Aluno
EE
Baixa
Emitir Relatrio
de Alunos por
Disciplina
SE
Mdia
Aluno
Contagem
da
Release N
Total de PFs da Release
Observao
Na contagem da release
para a baseline da aplicao,
no devem constar as
funcionalidades alteradas,
excludas e refinamentos.
18
Tabela 13 Contagem de PF da Release N para Baseline da Aplicao
8 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 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).
65
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/MP N 4, de 11 de setembro de 2014. 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 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
66
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/MP N 4, de 11 de setembro de 2014.
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.
9 Processo de Reviso do Roteiro de Contagem

9.1Reviso 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.
9.2Reviso 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.
10 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/MP N 4, de 11 de setembro de 2014. 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
67
projetos baseados nas melhores prticas. Outro ponto a ser destacado a implantao de um Escritrio
de Mtricas com 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.
11 Referncias Bibliogrficas
[Boehm, 2009] BOEHM, B.W. Software Cost Estimation With COCOMO II. Prentice Hall, New Jersey, 2009.
[CAIXA, 2012] CAIXA. Guia de Orientao - Mtricas, verso 10, 2012.
[Castro e Hernandes, 2013] CASTRO, M. V. B. de; HERNANDES, C. A. M. A Metric of Software Size as a Tool for IT
Governance. Procedings in: SBES, 2013.
[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 01039741, 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.
[Horvath, 2012] HORVATH, D.. Function Point Analysis and Agile Methodology. Q/P Management Group, Inc. 2012.
[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.
[Keote, 2010] KEOTE, A. K.. Function Points and Agile Hand in Hand. Accenture, 2010.
[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
68
[Parthasarathy, 2007] PARTHASARATHY, M. A. Practical Software Estimation: function point methods for insourced
and outsourced projects. Addison Wesley, New York, 2007.
[PROCERGS, 2013] PROCERGS. Guia de contagem da PROCERGS. Verso 2.0 Alteraes referentes ao Edital de
Fbrica de Software de Sistemas, Atualizado em 13/06/2013.
[Roetzheim, 2005] ROETZHEIM, W. Estimating and Managing Project Scope for New Development. CrossTalk, Vol.
April, 2005.
[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.
69
Anexo I Portaria SLTI/MP N 31, de 29 de 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 abordada 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
70
Anexo II Formalizao Simples de Requisitos Projetos de Manuteno

Pequenos (< 100 PF)
Dados Gerais
Nmero da O.S.
Nome do Sistema Mantido
Tecnologia Adotada
Data do Incio do Servio
Data do Trmino do Servio
Descrio da Solicitao
DD/MM/AAAA
DD/MM/AAAA
Descrio do Servio Executado

Requisito
Detalhamento
1.1
1.
1.2...
2.1
2.
2.2...
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
71
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 No

Aplicar Fator Criticidade? Sim No
Observaes relevantes quanto ao tipo de manuteno:
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 No
A Tabela atualizada por outra aplicao: Sim No
A Tabela foi: Includa Alterada Excluda
Total de Campos da Tabela aps a Manuteno =
Campos Includos/Alterados/Excludos
A funcionalidade ser apenas testada?

Sim No
72
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.
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
Houve mudana na regra de negcio (validaes, lgica de processamento, regras de clculo, campos
de filtro)?
Sim No
73
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
Houve mudana na regra de negcio (validaes, lgica de processamento, regras de clculo, campos
de filtro)?
Sim No
Sim No
74
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 do 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.
75
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 geren-
76
ciamento 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.
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 contra-
77
tado, 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.
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].
78
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.
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 fron-
79
teiras: 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 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
80
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.
[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.
81
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:
82
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.
83
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.
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
84
Nota Tcnica da Verso 2.0

A verso 2.0 do Roteiro de Mtricas de Software do SISP foi elaborada com base em propostas de
melhoria da sua verso anterior (verso 1.0), enviadas pelos rgos do SISP, e em roteiros de mtricas de
rgos que j utilizavam a mtrica PF em contratos de desenvolvimento e manuteno 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 publicao da verso 2.0 do roteiro ocorreu em setembro de 2012.
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
85
G O V E R N O
86
Secretaria de
Logstica e Tecnologia
da Informao
F E D E R A L

Roteirdo de Metricas SISP 2 1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Roteirdo de Metricas SISP 2 1

Enviado por

Direitos autorais:

Formatos disponíveis

ROTEIRO DE

Ministrio do Planejamento, Oramento e Gesto, 2015.

Normalizao Bibliogrfica: CODIN/CGPLA/DIPLA

4Clculo de Pontos de Funo para o SISP....................................................................................... 15

roteiro de mtricas de software do sisp

5Orientaes Complementares para Contagem............................................................................. 32

6Consideraes Especiais para Planejamento e Acompanhamento de Projetos................... 35

6.1.3Estimativa de Prazo de Projetos de Software.........................................................................................................43

7Contagem de Pontos de Funo no Desenvolvimento de Software utilizando

8Atividades Sem Contagem de Pontos de Funo........................................................................... 65

roteiro de mtricas de software do sisp

9.1Reviso para Correo de Inconsistncias e Situaes no Previstas.......................................................................67

roteiro de mtricas de software do sisp

roteiro de mtricas de software do sisp

cional para projetos de desenvolvimento e de melhoria (manuteno evolutiva) de software. No entanto,

roteiro de mtricas de software do sisp

3 Contagem de Pontos de Funo

roteiro de mtricas de software do sisp

Figura 1 - Procedimento de Contagem de Pontos de Funo

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

roteiro de mtricas de software do sisp

3.2Identificar Funes de Dados e Funes Transacionais

roteiro de mtricas de software do sisp

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.3Calcular Tamanho Funcional

roteiro de mtricas de software do sisp

PF_EXCLUDO: pontos de funo associados s funcionalidades existentes na aplicao que

roteiro de mtricas de software do sisp

Acessibilidade: a soluo deve ser aderente ao Modelo de Acessibilidade de Governo Eletrnico

4 Clculo de Pontos de Funo para o SISP

roteiro de mtricas de software do sisp

roteiro de mtricas de software do sisp

FI (Fator de Impacto) pode variar de 50% a 90% conforme condies abaixo:

roteiro de mtricas de software do sisp

de Funo e um processo de desenvolvimento implantado com documentao das aplicaes a serem

roteiro de mtricas de software do sisp

Observao 2: Outros Tipos de Funes Alteradas

4.3 Projetos de Migrao de Dados

roteiro de mtricas de software do sisp

roteiro de mtricas de software do sisp

4.5.1Mudana de Plataforma - Linguagem de Programao

4.5.2Mudana de Plataforma - Banco de Dados

roteiro de mtricas de software do sisp

roteiro de mtricas de software do sisp

4.6.1Atualizao de Verso Linguagem de Programao

4.6.2Atualizao de Verso Browser

roteiro de mtricas de software do sisp

4.6.3Atualizao de Verso Banco de Dados

roteiro de mtricas de software do sisp

4.8Adaptao em Funcionalidades sem Alterao de Requisitos Funcionais

roteiro de mtricas de software do sisp

Nestes casos, a aferio do tamanho em pontos de funo da funcionalidade ou das funcionalidades

roteiro de mtricas de software do sisp

4.9.1Apurao Especial Base de Dados

roteiro de mtricas de software do sisp

4.9.2Apurao Especial Gerao de Relatrios

4.9.3Apurao Especial Reexecuo

roteiro de mtricas de software do sisp