Você está na página 1de 87

Roteiro de Mtricas de Software do SISP

Verso 2.2 (No Formatado)

________________________________________________________________________________

Presidente da Repblica
Michel Miguel Elias Temer Lulia

Ministro do Ministrio do Planejamento, Desenvolvimento e Gesto


Dyogo Henrique de Oliveira

Secretrio de Logstica e Tecnologia da Informao


Marcelo Daniel Pagotti

Diretora do Departamento de Governana e Sistemas de Informao


Ana Carolina Romao Degaspari

Coordenador-Geral de Sistemas de Informaes


Orlando Batista da Silva Neto

Grupo de Mtricas de Software do SISP


Aline Gonalves dos Santos (STI/MP)
Felipe Corradi Carminati (STI/MP)
Maurcio de Alves Lacerda (STI/MP)

Equipe de Elaborao da Verso 2.2


Aline Gonalves dos Santos (STI/MP)
Felipe Corradi Carminati (STI/MP)
Maurcio de Alves Lacerda (STI/MP)
Orlando Batista da Silva Neto (STI/MP)

Roteiro de Mtricas de Software do SISP 2.2

Roteiro de Mtricas de Software do SISP


Verso 2.2 (No Formatado)

Braslia
2016

________________________________________________________________________________
Ministrio do Planejamento, Desenvolvimento e Gesto, 2016.
Qualquer parte desta publicao pode ser reproduzida, desde que citada a fonte, de
acordo com as orientaes da licena Creative Commons (CC BY-NC-SA 3.0). Impresso
no Brasil.
Disponvel em: www.sisp.gov.br.

Esta obra est licenciada por uma Licena Creative Commons - AtribuioNoComercial-CompartilhaIgual 3.0 Brasil

Normalizao Bibliogrfica: CODIN/CGPLA/DIPLA


B823r
Brasil. Ministrio do Planejamento, Desenvolvimento e Gesto.
Secretaria de
Tecnologia da Informao.
Roteiro de Mtricas de Software do SISP: verso 2.2 / Ministrio do
Planejamento, Desenvolvimento e Gesto. Secretaria de Logstica e
Tecnologia da Informao. Braslia : MP, 2016.
83 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

Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________

Sumrio
1. Introduo.........................................................................................................................................1
2. Objetivo............................................................................................................................................3
3. Contagem de Pontos de Funo.......................................................................................................3
3.1 Determinar Propsito, Tipo e Escopo da Contagem e Fronteira da Aplicao..............................4
3.2 Identificar Funes de Dados e Funes Transacionais.................................................................5
3.3 Calcular Tamanho Funcional..........................................................................................................6
3.4 Requisitos No Funcionais.............................................................................................................6
4. Clculo de Pontos de Funo para o SISP........................................................................................7
4.1 Projeto de Desenvolvimento...........................................................................................................8
4.2 Projeto de Melhoria........................................................................................................................8
4.3 Projetos de Migrao de Dados...................................................................................................11
4.4 Manuteno Corretiva..................................................................................................................11
4.5 Mudana de Plataforma................................................................................................................12
4.5.1 Mudana de Plataforma - Linguagem de Programao.............................................................13
4.5.2 Mudana de Plataforma - Banco de Dados...............................................................................13
4.6 Atualizao de Verso...................................................................................................................14
4.6.1 Atualizao de Verso Linguagem de Programao...............................................................14
4.6.2 Atualizao de Verso Browser..............................................................................................15
4.6.3 Atualizao de Verso Banco de Dados.................................................................................15
4.7 Manuteno em Interface.............................................................................................................16
4.8 Adaptao em Funcionalidades sem Alterao de Requisitos Funcionais...................................16
4.9 Apurao Especial........................................................................................................................18
4.9.1 Apurao Especial Base de Dados.........................................................................................18
4.9.2 Apurao Especial Gerao de Relatrios..............................................................................19
4.9.3 Apurao Especial Reexecuo..............................................................................................20
4.10 Atualizao de Dados.................................................................................................................20
4.11 Desenvolvimento, Manuteno e Publicao de Pginas Estticas de Intranet, Internet ou
Portal...................................................................................................................................................20
4.12 Manuteno de Documentao de Sistemas Legados................................................................21
4.13 Verificao de Erros....................................................................................................................22
4.14 Pontos de Funo de Teste..........................................................................................................22
4.15 Componente Interno Reusvel...................................................................................................23
5. Orientaes Complementares para Contagem................................................................................24
5.1 Contagem de Pontos de Funo com Mltiplas Mdias...............................................................24
5.1.1 Cenrio 1: Mesmos dados apresentados em tela e impressos...................................................26
5.1.2 Cenrio 2: Mesmos dados de sada como dados em arquivo e relatrio impresso...................26
5.1.3 Cenrio 3: Mesmos dados de entrada batch e on-line...............................................................26
5.1.4 Cenrio 4: Mltiplos canais de entrega da mesma funcionalidade...........................................26
5.1.5 Cenrio 5: Relatrio em mltiplos formatos.............................................................................27
5.2 Log, Trilha de Auditoria e Histrico.............................................................................................27
5.2.1 Log.............................................................................................................................................27
5.2.2 Trilha de Auditoria.....................................................................................................................27
5.2.2 Histrico....................................................................................................................................28
5.3 Identificao de Processo Elementar............................................................................................28
6. Consideraes Especiais para Planejamento e Acompanhamento de Projetos..............................28
6.1 Diretrizes para Planejamento: Estimativas de Projetos de Software............................................29
6.1.1 Contagem Estimativa de Pontos de Funo (CEPF).................................................................32
6.1.2 Estimativa de Esforo de Projetos de Software.........................................................................36
6.1.2.1 Distribuio de Esforo por Fase do Projeto..........................................................................37
Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________
6.1.3 Estimativa de Prazo de Projetos de Software............................................................................37
6.1.4 Alocao de Equipe ao Projeto..................................................................................................40
6.1.5 Mtodo para Estimativa de Custo..............................................................................................40
6.1.6 Estimativa de Recursos Computacionais...................................................................................40
6.2 Diretrizes para Acompanhamento de Projetos.............................................................................41
6.2.1 Consideraes sobre Mudana de Requisitos............................................................................41
6.2.2 Consideraes sobre Projetos Cancelados.................................................................................47
6.2.3 Gerenciamento de Progresso de Projetos..................................................................................47
6.2.4 Consideraes sobre Reduo de Cronograma.........................................................................48
6.2.5 Fator de Criticidade de Solicitao de Servio..........................................................................49
7. Contagem de Pontos de Funo no Desenvolvimento de Software utilizando Mtodos geis.....50
7.1 Conceitos......................................................................................................................................51
7.2. Orientaes..................................................................................................................................52
7.3 Tratamento de Mudanas em Funcionalidades no Processo gil................................................53
7.3.1 Fatores que Influenciam o Nmero de Mudanas em Funcionalidades no Processo gil........53
7.3.1.1 Exemplo de Aplicao da Proposta........................................................................................54
8. Atividades Sem Contagem de Pontos de Funo...........................................................................58
9. Processo de Reviso do Roteiro de Contagem...............................................................................59
9.1 Reviso para Correo de Inconsistncias e Situaes no Previstas..........................................59
9.2 Reviso para Adoo de Novas Verses do CPM........................................................................59
10. Concluso.....................................................................................................................................59
10. Referncias Bibliogrficas............................................................................................................60
Anexo I Portaria SLTI/MP N 31, de 29 novembro de 2010...........................................................62
Anexo II Formalizao Simples de Requisitos Projetos de Manuteno Pequenos (< 100 PF). .63
Anexo III Modelo de Documento de Contagem de Pontos de Funo Projetos de Manuteno
Pequenos (< 100 PF)..........................................................................................................................67
Anexo IV - Como Evitar Armadilhas em Contratos de Desenvolvimento e Manuteno de Sistemas
............................................................................................................................................................68
Anexo V Resumo da Tcnica EFP (Enhancement Function Points) publicada pela NESMA........74
Anexo VI Notas Tcnicas das Verses Anteriores deste Roteiro....................................................76

ndice de Figuras
Figura 1: Procedimento de Contagem de Pontos de Funo...............................................4
Figura 2: Processo de Estimativas de Projetos de Software [Hazan, 2008].......................27
Figura 3: Modelo Lgico da Anlise de Pontos de Funo.................................................30
Figura 4: Relao entre a Estimativa de Prazo e de Esforo..............................................35

ndice de Tabelas
Tabela 1: Contribuio Funcional dos Tipos Funcionais.......................................................5
Tabela 2: Identificao dos Arquivos Lgicos Internos da Aplicao..................................31
Tabela 3: Identificao dos Arquivos de Interface Externa da Aplicao............................31
Tabela 4: Identificao das Entradas Externas da Aplicao..............................................32
Tabela 5: Identificao das Consultas Externas da Aplicao............................................32
Tabela 6: Identificao das Sadas Externas da Aplicao.................................................33
Tabela 7: Distribuio de Esforo por Macroatividades do Projeto.....................................34
Tabela 8: Expoente t por tipo de Projeto..............................................................................35
Tabela 9: Estimativa de Prazo de Projetos menores que 100 PF.......................................36
Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________
Tabela 10: Percentuais definidos para a mudana de requisitos........................................39
Tabela 11: Planejamento do Backlog das Sprints da Release N........................................52
Tabela 12: Contagem Detalhada de Pontos de Funo da Release N...............................53
Tabela 13: Contagem de PF da Release N para Baseline da Aplicao............................54

Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________

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 funcional para projetos de
desenvolvimento e de melhoria (manuteno evolutiva) de software. No entanto, os
projetos de software no esto limitados a projetos de desenvolvimento e de melhoria.
Desta forma, torna-se essencial a definio de mtricas para dimensionar o tamanho de
outros tipos de projetos de manuteno, os quais so itens no mensurveis pelo CPM.
Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________
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.

Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________

2. Objetivo
Este documento tem como objetivo principal apresentar um roteiro de mtricas,
com base nas regras de contagem de pontos de funo do Manual de Prticas de
Contagem (CPM 4.3), para vrios tipos de projetos de desenvolvimento e de manuteno
de sistemas, promovendo o uso de mtricas objetivas nos contratos de prestao de
servios desses projetos. Alm da contagem de pontos de funo, este roteiro apresenta
um processo de estimativas com base na mtrica Ponto de Funo, visando apoiar as
organizaes nas estimativas de tamanho, custo, prazo e esforo de seus projetos
desenvolvidos internamente ou contratados.
A verso 2.2 apresenta uma pequena variao com relao verso anterior 2.1
especificamente para adequao s recomendao publicadas no Relatrio por rea de
Gesto n 5 da CGU que tratou da contratao de servios de desenvolvimento e
manuteno de sistemas mensurados em Pontos de Funo:

Criao da seo 5.2 com orientaes sobre a mensurao de log, trilha de


auditoria e histrico
Criao da seo 5.3 para reforar a necessidade de identificao correta de um
processo elementar.
Ajuste e incluso de itens no captulo de Atividades Sem Contagem de Pontos por
Funo (captulo 8).

A alterao do modelo de contratao de software, decorrente da implantao de


um processo de medio de software mais objetivo, requer uma mudana cultural, devido
mudana do paradigma homem-hora para a nova forma de contratao com base na
mtrica Ponto de Funo. Este roteiro tem como propsito apoiar os rgos e entidades
do SISP nessa mudana cultural. recomendvel a leitura do Anexo IV, pois apresenta
vrios tpicos importantes a serem observados pelos rgos contratantes na utilizao do
modelo de contratao de software usando a mtrica PF.
Duas premissas foram consideradas na elaborao deste roteiro:
Simplicidade: Este roteiro deve ser simples para incentivar os rgos e
entidades do SISP a utilizar a mtrica Ponto de Funo como medida padro no
estabelecimento de contratos de prestao de servios de desenvolvimento e
manuteno de sistemas.
Consistncia: Este roteiro deve definir critrios objetivos, visando prover a
consistncia no uso de mtricas em contratos de prestao de servios de
desenvolvimento e manuteno de sistemas. Deste modo, dois profissionais ao aplicarem
o roteiro no dimensionamento de um projeto de software devem obter o mesmo resultado.

3. Contagem de Pontos de Funo


A mtrica PF mede o tamanho funcional de um projeto de software, observando
as funcionalidades implementadas, considerando a viso do usurio. O tamanho funcional
definido como tamanho do software derivado pela quantificao dos requisitos
funcionais do usurio [Dekkers, 2003]. A mtrica PF independente da metodologia e
tecnologia utilizadas. A Anlise de Pontos de Funo (APF) um mtodo padro para a
medio de projetos de desenvolvimento e de manuteno de sistemas, visando
estabelecer uma medida de tamanho do software em pontos de funo, com base na
quantificao das funcionalidades solicitadas e entregues, sob o ponto de vista do
Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________
usurio. Assim, a APF tem como objetivo medir o que o software faz, por meio de uma
avaliao padronizada dos requisitos de negcio do sistema.
O Manual de Prticas de Contagem (CPM) [IFPUG, 2010b] apresenta as regras de
contagem de pontos de funo de projetos de desenvolvimento, projetos de melhoria e
aplicaes implantadas. A Figura 1 ilustra o procedimento de contagem de pontos de
funo, descrito nas sees seguintes.

Obter a
documentao
disponvel
do projeto

Identificar o Propsito
da Contagem

Identifique os

requisitos
funcionais

Identificar o Tipo de
Contagem
Determinar o Escopo
da Contagem

Contar
Funes de
Dados
Calcular
Tamanho
Funcional
Contar
Funes
Transacionais

Determinar a Fronteira
da Aplicao

Documentar
e Reportar a
Contagem

Figura 1: Procedimento de Contagem de Pontos de Funo

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


Aplicao
A contagem de pontos de funo se inicia com a anlise da documentao
disponvel do projeto em questo, visando a identificao dos requisitos funcionais. O
prximo passo o estabelecimento do propsito da contagem, o qual fornece uma
resposta para uma questo de negcio a ser resolvida, por exemplo: necessidade de
dimensionar um projeto de um novo sistema para auxiliar o processo de contratao do
mesmo. Com base no propsito da contagem so definidos o escopo da contagem e o
tipo de contagem. O escopo da contagem identifica quais funcionalidades sero includas
na contagem de pontos de funo, e o tipo de contagem identifica se o projeto de
desenvolvimento, de melhoria ou aplicao instalada. A fronteira da aplicao, que a
interface conceitual que indica o limite lgico entre o sistema sendo medido e os usurios
(tambm entre outras aplicaes), deve ser definida com base na viso do usurio,
desconsiderando questes de implementao. Deve-se ressaltar que toda contagem de
pontos de funo realizada dentro de uma fronteira estabelecida.
O estabelecimento da fronteira da aplicao pode ser subjetivo, por exemplo, em
uma aplicao com vrios mdulos, a fronteira pode ser estabelecida para cada mdulo
ou subsistema ou, ainda, pode-se considerar toda a aplicao, dependendo da viso do
usurio. De fato, a definio da fronteira depende de processos de negcios, alm disso,
o posicionamento da fronteira influencia fortemente a contagem de pontos de funo.
Desta forma, devido a essa subjetividade, em editais para contratao de projetos de
Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________
manuteno fortemente recomendado a definio das fronteiras de todas as aplicaes
a serem contratadas. Os roteiros de contagem dos rgos e entidades tambm devem
definir as fronteiras das aplicaes implantadas em um anexo, e este deve ser atualizado
sempre que for implantada uma nova aplicao. Mais informaes sobre esse assunto
podem ser encontradas no Anexo IV.

3.2 Identificar Funes de Dados e Funes Transacionais


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

Baixa

Mdia Alta

Arquivo Lgico Interno (ALI)

7 PF

10 PF

15 PF

Arquivo de Interface Externa (AIE)

5 PF

7 PF

10 PF

Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________
Entrada Externa (EE)

3 PF

4 PF

6 PF

Sada Externa (SE)

4 PF

5 PF

7 PF

Consulta Externa (CE)

3 PF

4 PF

6 PF

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

3.3 Calcular Tamanho Funcional


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

3.4 Requisitos No Funcionais


A mtrica Ponto de Funo uma mtrica de tamanho funcional, ou seja,
dimensiona projetos de software com base nos requisitos funcionais da aplicao, no
Roteiro de Mtricas de Software do SISP 2.2

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

aderente

aos

Padres

de

4. Clculo de Pontos de Funo para o SISP


Este captulo tem como propsito descrever os diversos tipos de projetos de
software e definir mtricas para seu dimensionamento baseadas nas regras de contagem
de pontos de funo do CPM.
Quanto documentao de pequenos projetos de manuteno (menores que 100
PF), deve-se registrar a solicitao e documentar os requisitos do projeto de manuteno
e da aplicao impactada pela demanda, de forma detalhada, visando apoiar a contagem
de pontos de funo da demanda. importante tambm documentar as estimativas e a
contagem de pontos de funo. O Anexo II e Anexo III apresentam, respectivamente, um
modelo de documento de requisitos e um modelo de documento de contagem de pontos
de funo para projetos de manuteno de pequeno porte (menores que 100 PF).
Cabe ressaltar que, em alguns casos, o rgo contratante pode no ter
necessidade de contratar todas as fases do ciclo de vida do software. Dessa forma, a
contratada ser remunerada pela contagem de pontos de funo considerando apenas
os percentuais das fases contratadas, conforme os nveis percentuais sugeridos na
Tabela 7 ou na metodologia do rgo (ver subseo 6.1.2.1). Exemplo: para um novo
projeto de desenvolvimento de um sistema de treinamentos, que no exista a inteno de
contratar as fases de requisitos e de testes, a contratada ser remunerada pela contagem
Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________
de pontos de funo desconsiderando os percentuais dessas fases.
Alm disso, recomenda-se que as contagens de manuteno a partir do Roteiro de
Mtricas de Software do SISP sejam reportadas conforme determinado pelo CPM, ou
seja, S FP (IFPUGISc), indicando que o resultado da contagem de pontos de funo
no mantm conformidade plena com o CPM e o padro internacional de contagem de PF
(ISO/IEC 20926:200x) e sim mantm conformidade com uma customizao, neste caso, o
Roteiro de Mtricas de Software do SISP.
Assim: S FP (IFPUGISc)
Onde:
S o resultado da contagem de pontos de funo;
FP (Function Point) a unidade de tamanho do mtodo FSM (Functional Size
Measurement) do IFPUG;
IS (International Standard) o padro internacional (ISO/IEC 20926:200x);
c representa um ou mais caracteres indicando que o resultado no mantm
conformidade plena com o padro internacional.
Exemplo: 250 PF* (IFPUGISO/IEC 20926:200xsisp)
* FP na verso em portugus

4.1 Projeto de Desenvolvimento


o projeto para desenvolver e entregar a primeira verso de uma aplicao de
software. Seu tamanho funcional a medida das funcionalidades entregues ao usurio no
final do projeto. Tambm considera-se as funcionalidades de converso de dados. Segue
a frmula de clculo utilizada no dimensionamento de projetos de desenvolvimento de
software:
PF_DESENVOLVIMENTO = PF_INCLUIDO + PF_CONVERSO
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.2 Projeto de Melhoria


O Projeto de Melhoria (enhancement), tambm denominado de projeto de melhoria
funcional ou manuteno evolutiva, est associado s mudanas em requisitos funcionais
da aplicao, ou seja, incluso de novas funcionalidades, alterao ou excluso de
funcionalidades em aplicaes implantadas.
Segundo o padro IEEE Std 1219 [IEEE, 1998], esta manuteno seria um tipo de
manuteno adaptativa, definida como: modificao de um produto de software existente
para mant-lo funcionando adequadamente em um ambiente que sofre mudanas. O
projeto de melhoria considerado um tipo de projeto de manuteno adaptativa com
mudanas em requisitos funcionais da aplicao, ou seja, com funcionalidades includas,
alteradas ou excludas na aplicao, segundo o CPM 4.3.
Este roteiro separa o projeto de melhoria (quando as mudanas so associadas
aos requisitos funcionais) do projeto de manuteno adaptativa (quando as mudanas
Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________
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
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, devese aplicar ao FI um redutor que corresponde ao percentual da fase no contratada,
conforme percentuais sugeridos na Tabela 7 ou na metodologia do rgo.
Os percentuais de multiplicao propostos so estimados, podendo ser reajustados
conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
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.
Roteiro de Mtricas de Software do SISP 2.2

________________________________________________________________________________
Uma outra forma de dimensionar projetos de melhoria usando a tcnica EFP
(Enhancement Function Points) publicada pela NESMA (Netherlands Software Metrics
Users Association) no documento "Function Point Analysis for Software Enhancement
Guidelines" [NESMA, 2009]. Essa tcnica pode ser aplicada quando a contratante j
possui uma base histrica de projetos concludos com Contagem Detalhada de Pontos de
Funo e um processo de desenvolvimento implantado com documentao das
aplicaes a serem mantidas. O Anexo V apresenta um resumo da tcnica EFP e a sua
descrio completa pode ser obtida em [NESMA, 2009].
Seguem algumas consideraes importantes para serem analisadas em projetos
de melhoria.
Observao 1: Funo Alterada
Uma funo de dados (Arquivo Lgico Interno ou Arquivo de Interface Externa)
considerada alterada quando houver incluso ou excluso de Tipos de Dados (TD). De
acordo com o glossrio do CPM 4.3, um Tipo de Dados (DET Data Element Type) um
atributo nico, reconhecido pelo usurio e no repetido. Tambm considerada alterada
se algum tipo de dado sofrer mudana de tamanho (nmero de posies) ou tipo de
campo (por exemplo: mudana de numrico ou alfanumrico), caso a mudana decorra
de alterao de regra de negcio.
Uma funo transacional (Entrada Externa, Consulta Externa e Sada Externa)
considerada alterada, quando a alterao contemplar:
Mudana de tipos de dados;
Mudana de arquivos referenciados;
Mudana de lgica de processamento.
O CPM 4.3 define lgica de processamento como requisitos especificamente
solicitados pelo usurio para completar um processo elementar. Esses requisitos devem
incluir uma ou mais das seguintes aes:
Validaes so executadas;
Frmulas matemticas e clculos so executados;
Valores equivalentes so convertidos;
Dados so filtrados e selecionados atravs da utilizao de critrios;
Condies so analisadas para verificar quais so aplicveis;
Um ou mais ALIs so atualizados;
Um ou mais ALIs ou AIEs so referenciados;
Dados ou informaes de controle so recuperados;
Dados derivados so criados atravs da transformao de dados existentes, para
criar dados adicionais;
O comportamento do sistema alterado;
Preparar e apresentar informaes para fora da fronteira;
Receber dados ou informaes de controle que entram pela fronteira da
aplicao;
Dados so reordenados.
Roteiro de Mtricas de Software do SISP 2.2

10

________________________________________________________________________________
Observao 2: Outros Tipos de Funes Alteradas
Este roteiro considera como funo alterada qualquer mudana em funcionalidades
da aplicao devido s mudanas de regras de negcio. Por exemplo, uma funcionalidade
de cadastro envolvia a incluso de um telefone do gerente. Devido a mudanas no
processo de negcio, a funcionalidade deve sofrer uma manuteno para cadastrar dois
telefones do gerente. Desta forma, o roteiro considera esta funo como uma Entrada
Externa alterada, PF_ALTERADO em um projeto de melhoria, mesmo que no existam
mudanas de lgica de processamento, de tipos de dados ou de arquivos referenciados.
Sero tratadas como manutenes adaptativas apenas as manutenes que implicarem
exclusivamente em mudanas em requisitos no funcionais. Se uma mesma
funcionalidade tiver mudanas em requisitos funcionais e no funcionais, esta deve ser
contada apenas uma vez, como funo alterada em um projeto de melhoria.

4.3 Projetos de Migrao de Dados


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

4.4 Manuteno Corretiva


Mesmo com a execuo de atividades de garantia da qualidade, pode-se
identificar defeitos na aplicao entregue. A manuteno corretiva altera o software para
correo de defeitos. Encontra-se nesta categoria, as demandas de correo de erros
(bugs) em funcionalidades de sistemas em produo.
importante destacar que as demandas de manuteno corretiva frequentemente
precisam ser atendidas com urgncia. Assim, o grau de criticidade do projeto poder
trazer impacto nas estimativas de custo e esforo. O padro IEEE Std 1219 [IEEE,1998]
define um tipo de manuteno corretiva, denominado de Manuteno Emergencial como
manuteno corretiva no programada executada para manter o sistema em estado
operacional.

Roteiro de Mtricas de Software do SISP 2.2

11

________________________________________________________________________________
Quando o sistema em produo tiver sido desenvolvido pela contratada, a
manuteno corretiva ser do tipo Garantia se estiver no perodo de cobertura e em
conformidade com as demais condies de garantia previstas em contrato. Caso no
exista clusula contratual de garantia, deve ser considerada a garantia preconizada por lei
(Cdigo do Consumidor).
Quando o sistema estiver fora da garantia ou no tenha sido desenvolvido pela
empresa contratada, dever ser estimado e calculado o tamanho do projeto de
manuteno corretiva. Nestes casos, a aferio do tamanho em pontos de funo da
funcionalidade ou das funcionalidades corrigidas deve considerar um fator de impacto
(FI) sobre o PF_ALTERADO.
PF_CORRETIVA = FI x PF_ALTERADO
Fator de Impacto (FI):

50% quando estiver fora da garantia e a correo for feita pela mesma empresa
que desenvolveu a funcionalidade.

75% quando estiver fora da garantia e a correo for feita por empresa diferente
daquela que desenvolveu a funcionalidade.

As demandas de manuteno corretiva no contemplam atualizao de


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

4.5 Mudana de Plataforma


So considerados nesta categoria, projetos que precisam ser migrados para outra
plataforma. Por exemplo, um sistema legado em COBOL que necessita ser
redesenvolvido em JAVA; o banco de dados de um sistema legado que precisa ser
migrado para o DB2.
Recomenda-se enfaticamente a realizao da anlise de impacto das mudanas
propostas, para efeito de determinao do percentual adequado para aplicao sobre o
total de pontos de funo das funcionalidades impactadas. Por exemplo, em uma anlise
de impacto pode ser identificado que no haver mudanas no cdigo-fonte ou em funo
transacional, sendo necessrio apenas testar o sistema, ento deve-se utilizar um
percentual contemplando apenas a fase de testes. No caso do teste apontar a
necessidade de atualizar alguma funo transacional, no deve ser contado o esforo do
teste, mas sim o esforo abordado nesta seo, conforme as frmulas apresentadas nos
tpicos seguintes.
Roteiro de Mtricas de Software do SISP 2.2

12

________________________________________________________________________________
As prximas subsees apresentam os tipos de projetos de mudana de
plataforma. Os projetos de mudana de plataforma que se enquadram em mais de uma
subseo, devem ser contados apenas uma vez, considerando o tipo de projeto com
maior contagem de pontos de funo. Os percentuais de multiplicao apresentados so
estimados, podendo ser reajustados conforme avaliao da base histrica dos servios
realizados no rgo ou entidade.

4.5.1 Mudana de Plataforma - Linguagem de Programao


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

4.5.2 Mudana de Plataforma - Banco de Dados


Nesta categoria encontram-se as demandas de redesenvolvimento de sistemas
para utilizar um outro sistema gerenciador de banco de dados.
Observe que caso no exista mudana nas funes de dados, ou seja, o banco de
dados da aplicao seja mantido, ento as funes de dados no devem ser contadas.
No entanto, nesse caso, deve ser realizada a contagem das funes de dados a fim de
compor a documentao da contagem final do projeto.
Em casos de mudana de banco hierrquico para relacional, em sistemas sem
documentao, devido s mudanas envolvidas, deve-se considerar como um novo
projeto de desenvolvimento, ou seja, as funes de dados e funes transacionais devem
ser contadas. Assim, ser utilizada a frmula de projeto de desenvolvimento do CPM 4.3,
conforme frmula abaixo:
PF_REDESENVOLVIMENTO_BD_HIERRQUICO = PF_INCLUDO + PF_CONVERSO
Nos projetos de redesenvolvimento de banco de dados hierrquico para relacional,
recomenda-se a supresso do PF_CONVERSO da frmula acima, conforme descrito na
seo 3.3.
Roteiro de Mtricas de Software do SISP 2.2

13

________________________________________________________________________________
Caso o projeto j possua documentao de requisitos, ento a fase de requisitos
no deve ser contratada. importante destacar que isso se aplica a qualquer fase que
no se deseja contratar. Deve-se considerar apenas os percentuais das fases
contratadas.
Caso a demanda de redesenvolvimento seja de um sistema gerenciador de banco
de dados relacional para outro relacional, deve ser utilizada a seguinte frmula:
PF_REDESENVOLVIMENTO_BD_RELACIONAL = (PF_ALTERADO X 0,30) +
PF_CONVERSO
O PF_ALTERADO deve considerar apenas as funcionalidades impactadas. As
funcionalidades que possuem apenas demandas de testes, devem ser contadas usando o
percentual da fase de testes (ver Tabela 7).
Nos projetos de redesenvolvimento de banco de dados relacional para outro
relacional, recomenda-se tratar o PF_CONVERSO dentro do mesmo projeto.
Na mudana de banco relacional para relacional, geralmente a estrutura de dados
no alterada, desta forma no contamos as funes de dados.

4.6 Atualizao de Verso


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

4.6.1 Atualizao de Verso Linguagem de Programao


Nesta categoria encontram-se as demandas de atualizao de verso de
linguagem de programao de sistemas. As funes de dados no devem ser contadas.
Estas demandas devem ser dimensionadas de acordo com a frmula abaixo.
PF_ATUALIZAO_VERSO_LINGUAGEM = PF_ALTERADO x 0,30
Roteiro de Mtricas de Software do SISP 2.2

14

________________________________________________________________________________
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).
Cabe ressaltar que o redutor depende da linguagem da programao utilizada,
considerando o grau de complexidade de implementao da mudana de verso no
sistema em questo. Desta forma, recomenda-se fortemente a anlise do percentual
redutor da frmula de contagem pelo rgo.

4.6.2 Atualizao de Verso Browser


Nesta categoria encontram-se as demandas de atualizao de aplicaes Web
para executar em novas verses de um mesmo browser e para suportar a execuo em
mais de um browser. importante destacar que este tipo de procedimento usualmente
realizado quando necessrio resolver algum problema de incompatibilidade. As funes
de dados no devem ser contadas. Estas demandas devem ser dimensionadas de acordo
com a frmula abaixo.
PF_ATUALIZAO_VERSO_BROWSER = PF_ALTERADO x 0,30
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).
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 citado acima. importante
ressaltar que os sistemas Web devem seguir o padro W3C, como recomendado na ePing. Caso seja necessrio fazer a adequao do sistema para atendimento ao padro
W3C, pode-se usar a frmula acima.

4.6.3 Atualizao de Verso Banco de Dados


Nesta categoria encontram-se as demandas de atualizao de verso do sistema
gerenciador de banco de dados. As funes de dados no devem ser contadas. Estas
demandas devem ser dimensionadas de acordo com a frmula abaixo.
PF_ ATUALIZAO_VERSO_BD = PF_ALTERADO x 0,30
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).

Roteiro de Mtricas de Software do SISP 2.2

15

________________________________________________________________________________

4.7 Manuteno em Interface


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

4.8 Adaptao em Funcionalidades sem Alterao de Requisitos


Funcionais
So consideradas nesta categoria as demandas de manuteno adaptativa
associadas a solicitaes que envolvem aspectos no funcionais, sem alterao em
requisitos funcionais. Seguem alguns exemplos:
Roteiro de Mtricas de Software do SISP 2.2

16

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

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


um projeto de melhoria pela empresa contratada.

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.

Roteiro de Mtricas de Software do SISP 2.2

17

________________________________________________________________________________

4.9 Apurao Especial


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

4.9.1 Apurao Especial Base de Dados


Este tipo de apurao especial um projeto que inclui a gerao de procedimentos
para atualizao da base de dados. Deve-se destacar que estas funes so executadas
apenas uma vez, no fazendo parte da aplicao, visando a correo de dados incorretos
na base de dados da aplicao ou atualizao em funo de modificao da estrutura de
dados, por exemplo incluso de valor sim ou no no campo indicador de matriz
referente ao CNPJ. Normalmente, nesse tipo de atualizao so afetados mltiplos
registros. Nestes casos, considera-se a contagem de pontos de funo das
funcionalidades desenvolvidas. Geralmente, estas funcionalidades so classificadas como
Entradas Externas. Nesse caso, como artefato de homologao da demanda, deve ser
gerado um relatrio para validao do usurio.
importante ressaltar que as funes de dados associadas aos dados atualizados
no devem ser contadas, considerando que no h mudanas nas estruturas dos
Arquivos Lgicos Internos.
Foram identificados trs tipos de Apurao Especial - Base de Dados, cujas
frmulas de clculo so apresentadas a seguir:
a) Atualizao de Dados sem Consulta Prvia
PF_APURAO_BD = PF_INCLUDO

Roteiro de Mtricas de Software do SISP 2.2

18

________________________________________________________________________________
b) Consulta Prvia sem Atualizao
Em alguns casos de Apurao Especial Base de Dados, o usurio solicita uma
consulta prvia das informaes. Deve-se ressaltar que essa consulta deve ser realizada
antes da construo da funcionalidade, no se trata de homologao. A consulta prvia
no definida pela empresa contratada, obrigatoriamente essa deve ser solicitada pelo
rgo contratante para a avaliao da viabilidade de implementar a Apurao Especial Base de Dados. De fato, uma prtica interessante para evitar informaes errneas na
base de produo dos sistemas. Esta consulta prvia, classificada como Consulta Externa
ou Sada Externa deve ser dimensionada considerando-se o tamanho da funcionalidade
em questo, conforme a frmula abaixo:
PF _CONSULTA_PRVIA = PF_INCLUDO
c) Atualizao de Dados com Consulta Prvia
Caso a Apurao Especial - Base de Dados seja solicitada aps uma demanda de
consulta prvia, deve-se aplicar um fator de 60% na frmula de contagem da Apurao
Especial - Base de Dados, seguindo a frmula abaixo.
PF_APURAO_BD_PS_CONSULTA_PRVIA = PF_INCLUDO x 0,60

4.9.2 Apurao Especial Gerao de Relatrios


Este tipo de apurao especial um projeto que inclui a gerao de relatrios em
uma ou mais mdias para o usurio. Em alguns casos, so solicitadas extraes de dados
e envio dos dados para outros sistemas. Caso, neste envio de dados, sejam requisitadas
atualizaes no sistema de origem, ento essas funes transacionais so Sadas
Externas, devido atualizao do Arquivo Lgico Interno.
Deve-se destacar que essas funes so executadas apenas uma vez, no
fazendo parte da aplicao. Nestes casos, considera-se contagem de pontos de funo
das funcionalidades desenvolvidas. Frequentemente, estas funcionalidades so
classificadas como Sadas Externas. Tambm podem ser classificadas como Consultas
Externas, caso no possuam clculos ou criao de dados derivados.
importante ressaltar que as funes de dados associadas aos dados atualizados
no devem ser contadas, considerando que no h mudanas nas estruturas dos
Arquivos Lgicos.
PF_APURAO_RELATRIOS = PF_INCLUDO

Roteiro de Mtricas de Software do SISP 2.2

19

________________________________________________________________________________

4.9.3 Apurao Especial Reexecuo


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

4.10 Atualizao de Dados


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

4.11 Desenvolvimento, Manuteno e Publicao de Pginas Estticas


de Intranet, Internet ou Portal
Nesta seo so tratados desenvolvimentos e manutenes especficas em
pginas estticas de portais, intranets ou websites. As demandas desta seo abrangem
a publicao de pginas Web com contedo esttico. Por exemplo: criao de pgina
HTML, atualizao de menu esttico, atualizao de texto ou banner estticos em pginas
HTML existentes.

Roteiro de Mtricas de Software do SISP 2.2

20

________________________________________________________________________________
Caso o desenvolvimento de pginas estticas esteja contido em um projeto de
desenvolvimento, ento elas sero contabilizadas no projeto de desenvolvimento e no
devem ser mensuradas em separado. Ou seja, esta seo 4.11 se aplica quando ocorrer
a demanda exclusivamente para o desenvolvimento ou manuteno de pginas estticas.
Estas demandas so consideradas como desenvolvimento de consultas. Nestes
casos, considera-se 20% dos pontos de funo das consultas desenvolvidas. Cada
pgina contada como uma consulta. As consultas so consideradas consultas externas
simples (3 PF). Ou seja, 0,6 PF por cada pgina desenvolvida ou mantida, de acordo com
a frmula abaixo:
PF_PUBLICAO = 0,6 PF x Quantidade de Pginas Alteradas ou Includas
As demandas de criao de logomarcas ou identidade visual, alm de outras
demandas de criao de arte, associadas rea de Comunicao Social, no so
enquadradas nessa categoria. Tais demandas no se referem a contratos de prestao de
servios de desenvolvimento e manuteno de sistemas, portanto no so consideradas
neste roteiro.
recomendada a construo de portais com ferramentas que apoiem a construo
de contedo pelo usurio, os chamados Gerenciadores de Contedo, de modo a
minimizar as demandas de criao de pginas estticas.
O percentual de multiplicao proposto acima estimado, podendo ser reajustado
conforme avaliao da base histrica dos servios realizados no rgo ou entidade.

4.12 Manuteno de Documentao de Sistemas Legados


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

Roteiro de Mtricas de Software do SISP 2.2

21

________________________________________________________________________________

4.13 Verificao de Erros


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

4.14 Pontos de Funo de Teste


Muitas vezes, em projetos de manuteno, o conjunto de funes transacionais a
serem testadas maior do que a quantidade de funes a serem implementadas, isto ,
alm das funcionalidades que so afetadas diretamente pelo projeto de manuteno,
outras precisam ser testadas [NESMA, 2009]. O tamanho das funes a serem apenas
testadas deve ser aferido em Pontos de Funo de Teste (PFT). No considerar as
funcionalidades includas, alteradas ou excludas do projeto de manuteno na contagem
de Pontos de Funo de Teste.
A contagem de PFT ser o somatrio dos tamanhos em pontos de funo das
funes transacionais envolvidas no teste:

PFT = Somatrio dos Tamanhos das Funes Transacionais Testadas

Roteiro de Mtricas de Software do SISP 2.2

22

________________________________________________________________________________
A converso do PFT em ponto de funo deve ser feita de acordo com a frmula
abaixo:
PF_TESTES = PFT x 0,15
importante ressaltar que no caso de uma funo ser testada vrias vezes, com
cenrios diferentes, a funo s pode ser contada uma vez. Outra observao que as
funes testadas, consideradas no PFT, devem ser documentadas pela contratada
considerando-se a documentao de testes definida no processo de desenvolvimento da
contratante. Observe que estas funes faro parte do escopo do projeto de manuteno.

4.15 Componente Interno Reusvel


Em alguns casos so demandadas manutenes em componentes, que
implementam regras de negcio, especficos de uma aplicao e estes so reusados por
vrias funcionalidades da aplicao. Por exemplo, uma mudana em uma rotina de
validao de um CPF usada em vrias funcionalidades de cadastro. Se considerarmos o
mtodo de contagem de projetos de melhoria do CPM, seriam contadas todas as
funcionalidades impactadas por essa mudana.
No entanto, este roteiro prope que o componente, o qual dever ser testado, seja
considerado como um processo elementar independente e 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.
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

Roteiro de Mtricas de Software do SISP 2.2

23

________________________________________________________________________________

5. Orientaes Complementares para Contagem


Este captulo tem o propsito de apresentar diretrizes complementares ao Manual
de Prticas de Contagem do IFPUG para contagens de pontos de funo e reforar
pontos sensveis nas contrataes atuais que podem impactar significativamente o
resultado de uma contagem em caso de falhas.
As diretrizes para contagens de pontos de funo envolvendo Mltiplas Mdias tm
como base o artigo Considerations for Counting with Multiple Media Release 1.1
publicado pelo IFPUG [IFPUG, 2010a].

5.1 Contagem de Pontos de Funo com Mltiplas Mdias


A contagem de PF de funcionalidades entregues em mais de uma mdia, na
aplicao das regras de contagem de pontos de funo definidas no CPM, tem levado a
duas abordagens alternativas, a saber: single instance e multiple instance.
importante enfatizar que o IFPUG reconhece ambas abordagens, single instance
e multiple instance, para a aplicao das regras definidas no CPM. A determinao da
contagem de PF seguindo a abordagem multiple instance ou single instance depende da
avaliao do Escritrio de Mtricas da instituio.
As estimativas e contagens de PF abordadas neste documento so baseadas em
multiple instance, com exceo dos casos de consultas em .pdf, .doc, .xls e consultas
idnticas em tela e papel, que sero consideradas uma nica funcionalidade.
A seguir so descritos os termos comuns definidos pelo IFPUG [IFPUG, 2010a]:
Canal: tambm refere-se a mdia. Mltiplos canais sinnimo de mltiplas
mdias.
Mdia: descreve a maneira como os dados ou informaes se movimentam
para dentro e para fora de uma fronteira de aplicao, por exemplo, apresentao
de dados em tela, impressora, arquivo, voz. Este termo utilizado para incluir,
dentre outros, diferentes plataformas tcnicas e formatos de arquivos como
diferentes mdias.
Mltiplas Mdias: quando a mesma funcionalidade entregue em mais de uma
mdia. Frequentemente, apenas uma mdia requisitada para um usurio
especfico em um determinado momento, por exemplo consulta de extrato bancrio
via Internet como oposto a consulta de extrato bancrio via terminal do banco.
Multi-Mdia: quando mais de uma mdia necessria para entregar a
funcionalidade , por exemplo, uma nova notcia publicada na Internet que
apresentada em vdeo e texto. Observe que a notcia completa s apresentada
para o usurio se ele ler o texto e assistir o vdeo.
Abordagem Single Instance: esta abordagem no reconhece que a mdia
utilizada na entrega da funo transacional uma caracterstica de diferenciao
na identificao da unicidade da funo transacional. Se duas funes entregam a
mesma funcionalidade usando mdias diferentes, elas so consideradas a mesma
funcionalidade em uma contagem de pontos de funo.
Abordagem Multiple Instance: esta abordagem especifica que o tamanho
funcional obtido no contexto do objetivo da contagem, permitindo uma funo de
Roteiro de Mtricas de Software do SISP 2.2

24

________________________________________________________________________________
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.

Roteiro de Mtricas de Software do SISP 2.2

25

________________________________________________________________________________
Os cenrios descritos nas sees seguintes no representam uma lista completa
de situaes de mltiplas mdias. O entendimento dos exemplos a seguir facilitar o
entendimento de outros cenrios envolvendo mltiplas mdias.
Este roteiro deve ser atualizado considerando a publicao de novas diretrizes do
IFPUG e novos cenrios que emergiro nas contagens de PF de projetos dos rgos e
entidades do SISP.

5.1.1 Cenrio 1: Mesmos dados apresentados em tela e impressos


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

5.1.2 Cenrio 2: Mesmos dados de sada como dados em arquivo e


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

5.1.3 Cenrio 3: Mesmos dados de entrada batch e on-line


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

5.1.4 Cenrio 4: Mltiplos canais de entrega da mesma funcionalidade


Uma funcionalidade deve ser disponibilizada em mltiplos canais, por exemplo:
consulta de dados em pgina Web e consulta de dados no telefone celular. Neste caso,
sugere-se a abordagem multiple instance, que conta duas funcionalidades: consulta de
dados na Web e consulta de dados via celular.
Roteiro de Mtricas de Software do SISP 2.2

26

________________________________________________________________________________
Considera-se que a funcionalidade desenvolvida duas vezes, uma para cada
canal de sada. Algumas vezes, so at projetos de desenvolvimento distintos, um projeto
relativo ao sistema Web e outro para o sistema via celular. Lembrando que caso o projeto
seja claro o suficiente para dizer que o desenvolvimento o mesmo, poder ser utilizada
a abordagem single instance.

5.1.5 Cenrio 5: Relatrio em mltiplos formatos


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

5.2 Log, Trilha de Auditoria e Histrico


O objetivo dessa sesso descrever orientaes sucintas a respeito de contagem
de log, trilha de auditoria e histrico.

5.2.1 Log
Conceituamos o termo Log como o registro de procedimentos ou aes
realizados pela aplicao, em determinado perodo de tempo, com o objetivo de apoiar a
auditoria do ambiente tecnolgico e a identificao das causas razes de falhas em
sistemas. Diante desse conceito, definimos que o Log no deve ser mensurado com
Pontos de Funo, j que ele no armazena informaes negociais reconhecidas pelo
usurio da aplicao.

5.2.2 Trilha de Auditoria


Conceituamos Trilha de Auditoria como a funcionalidade que tem o objetivo de
armazenar informaes referentes s aes realizadas pelos usurios da aplicao no
passado, de modo que seja possvel apurar quais foram as aes executadas quando da
utilizao do sistema.
Para isso, devem existir no mnimo as informaes para identificar quem realizou a
ao, quando e o que foi realizado, alm de outras informaes que o usurio da
aplicao defina como necessrias.
A trilha de auditoria deve ser solicitada pelo usurio da aplicao e, para a
contagem, deve existir funcionalidade de consulta a tais dados.
Caso a trilha de auditoria faa parte da poltica corporativa de segurana da
informao adotada pelo contratante para todos os sistemas do rgo, ela deve ser
considerada como um requisito no funcional e, portanto, no ser mensurvel em ponto
de funo.
Roteiro de Mtricas de Software do SISP 2.2

27

________________________________________________________________________________
Diante do exposto, a principal diferena entre o Log e a Trilha de Auditoria :
Log: apoia a coleta de informaes no mbito tecnolgico, ou seja, em problemas
decorrentes da arquitetura tecnolgica que precisam ser investigados, por meio da
anlise do conjunto de procedimentos executadas pela aplicao, como exemplo a
baixa performance no sistema, travamentos e outros comportamentos inesperados.
Trilha de Auditoria: apoia a auditoria para os dados de negcio, armazenando
informaes das aes realizadas pelo usurio na aplicao.

5.2.2 Histrico
Conceituamos Histrico como um registro de estados com informaes anteriores
de um registro em determinado momento. O usurio poder consultar a evoluo dessas
informaes em uma linha do tempo e sua existncia justificada pelo negcio. Assim,
para fazer parte do tamanho funcional, deve ser solicitado pelo gestor e dever existir
funcionalidade de consulta a tais dados.
A funo de consulta aos dados de um histrico dever ser contada de acordo com
as regras de contagem das funes transacionais do CPM.
No devem ser consideradas na contagem funes de transao separadas para
incluir, alterar e excluir as informaes histricas, pois o armazenamento dessas
informaes parte integrante das mesmas funcionalidades que processam os dados de
negcio. Apenas quando o histrico for mantido de forma independente do registro
principal, por exemplo no caso do ALI principal ter sido excludo, o histrico se torna um
ALI independente e no um registro lgico do ALI relacionado.

5.3 Identificao de Processo Elementar


Um Processo Elementar a menor unidade de atividade que significativa para
o(s) usurio(s). O Processo Elementar deve ser auto contido e deixar o negcio da
aplicao que est sendo contada em um estado consistente.
Um processo elementar com mltiplas formas de processamento lgico no deve
ser dividido em mltiplos processos elementares. Se um processo elementar
subdividido inapropriadamente, o mesmo no rene os critrios de um processo
elementar.
Ressalta-se a importncia do atendimento a todos os critrios listados no Manual
de Prticas de Contagem do IFPUG e da observao dos seus exemplos para a correta
identificao de um processo elementar.

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
Roteiro de Mtricas de Software do SISP 2.2

28

________________________________________________________________________________
projetos. Tambm so apresentadas recomendaes para o gerenciamento de: mudanas
de requisitos, projetos cancelados e progresso de projetos, e consideraes sobre
reduo de cronograma e fator de criticidade de solicitao de servios.

6.1 Diretrizes para Planejamento: Estimativas de Projetos de Software


Esta seo define mtodos para estimativas de projetos de software. A Figura 2
ilustra um processo de estimativas de projetos de software, descrito nos pargrafos
seguintes.

Coletar e Analisar
Requisitos Iniciais

Estimar Esforo
Banco de Dados
Histrico de Projetos
da organizao

Estimar Cronograma

Estimar Custo

Documentar
Estimativas e
Premissas
Documentar
Acompanhamento
Documentar
Resultados finais
e Lies Aprendidas

Reestimar,conforme
necessidade

Estimar Tamanho

Estimar Recursos
Computacionais Crticos
Analisar e Aprovar
Estimativas
Acompanhar
Estimativas
Calibrar e Melhorar
o Processo

Figura 2: Processo de Estimativas de Projetos de Software [Hazan,


2008]

O principal insumo (artefato de entrada) para um processo de estimativas o


documento de requisitos. Como as estimativas devem ser realizadas no incio do
processo de desenvolvimento de software, ento o artefato a ser utilizado um
documento inicial de requisitos, por exemplo, o documento de viso ou formalizao
simples de requisitos. O estimador deve analisar os requisitos para garantir a qualidade e
ento estimar o tamanho do projeto de software. O prximo passo a derivao das
estimativas de esforo, prazo (cronograma), custo (oramento) com base na estimativa de
tamanho e nos dados histricos de projetos concludos da organizao, assim como o
Roteiro de Mtricas de Software do SISP 2.2

29

________________________________________________________________________________
estabelecimento da estimativa de recursos computacionais crticos e dos recursos da
equipe a ser alocada ao projeto. Neste ponto, as principais estimativas foram geradas e
precisam ser documentadas. As premissas e suposies utilizadas na gerao das
estimativas, dentre as quais: complexidade do projeto, plataforma de desenvolvimento,
tipo do projeto, percentual de evoluo de requisitos, tambm devem ser documentadas
[Hazan, 2008].
A realizao das estimativas por um analista de mtricas que no atue na equipe
do projeto, constitui uma prtica recomendada. O analista de mtricas deve analisar
tambm a consistncia da documentao utilizada na estimativa. No decorrer do processo
de desenvolvimento, as estimativas devem ser acompanhadas conforme o refinamento
dos requisitos. O projeto deve ser reestimado aps a fase de requisitos, quando for
gerada a especificao de casos de uso, e sempre que ocorrerem mudanas
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
Roteiro de Mtricas de Software do SISP 2.2

30

________________________________________________________________________________
no tamanho do projeto a ser faturado (ver subseo 6.2.1). Alm disso, se estas
mudanas forem significativas, maiores que a evoluo de requisitos (scope creep)
prevista na estimativa inicial, o prazo do projeto deve ser reestimado. Toda mudana de
requisito deve passar por uma anlise de impacto entre contratante e contratada.
As subsees seguintes apresentam os mtodos de estimativas de tamanho,
prazo, custo e esforo a serem utilizados nos projetos de software em contratos.

Roteiro de Mtricas de Software do SISP 2.2

31

________________________________________________________________________________

6.1.1 Contagem Estimativa de Pontos de Funo (CEPF)


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

Roteiro de Mtricas de Software do SISP 2.2

32

________________________________________________________________________________
Documentao
do Software

Abstrao orientada a dados


Usurios
Identificao dos itens da APF

Aplicao
Transaes
(EEs, CEs,
SEs)

Pontos de Funo
(nmeros)

Mapeando em nmeros

Dados
Internos (ALIs)

Outras
Aplicaes
Dados
Externos
(AIEs)

Figura 3: Modelo Lgico da Anlise de Pontos de Funo


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

33

________________________________________________________________________________
N ALI Baixa:

X 7 PF

N ALI Mdia:

X 10 PF

N ALI Alta:

X 15 PF

Total PF:
Tabela 2: Identificao dos Arquivos Lgicos Internos da Aplicao

Tabela 3 - Contagem de Arquivos de Interface Externa (AIE): banco de dados de


outras aplicaes, apenas referenciados pela aplicao que est sendo estimada
(tabelas e arquivos mantidos por outra aplicao).
Consideraes: Identifique os grupos de dados lgicos de outras aplicaes
referenciados pela aplicao que est sendo estimada. Frequentemente, o
referenciamento de dados ocorre para a validao de informaes em cadastros ou
consultas. Algumas vezes, relatrios ou consultas referenciam dados externos de outras
aplicaes, tambm considerados AIE. No so considerados AIE arquivos fsicos,
arquivos de ndice, arquivos de trabalho, tabelas de relacionamento sem atributos
prprios e entidades fracas.
Geralmente, os AIE dos sistemas possuem a classificao de complexidade Baixa,
porque so considerados para a determinao da complexidade funcional do AIE apenas
os atributos referenciados pela aplicao que est sendo contada.
N AIE Baixa:

X 5 PF

N AIE Mdia:

X 7 PF

N AIE Alta:

X 10 PF

Total PF:
Tabela 3: Identificao dos Arquivos de Interface Externa da Aplicao

Tabela 4 - Contagem de Entradas Externas (EE): funcionalidades que mantm os


Arquivos Lgicos Internos (ALI) ou alteram o comportamento da aplicao.
Consideraes: Identifique as funcionalidades de manuteno de dados. Conte
separadamente a incluso, alterao e excluso de dados, isto , cada funo
independente de incluso, alterao ou excluso deve ser contada separadamente. A
aplicao possui funes de entrada de dados que alteram o comportamento dela, por
exemplo: processamentos batch ou processamento de informaes de controle? Caso
positivo, estas funes tambm devem ser identificadas como Entradas Externas. Se
voc no possui conhecimento sobre o processo elementar (funcionalidade analisada),
considere as Entradas Externas identificadas com complexidade Mdia.

N EE Baixa:

X 3 PF

N EE Mdia:

X 4 PF

Roteiro de Mtricas de Software do SISP 2.2

34

________________________________________________________________________________
N EE Alta:

X 6 PF

Total PF:
Tabela 4: Identificao das Entradas Externas da Aplicao

Tabela 5 - Contagem de Consultas Externas (CE): funcionalidades que apresentam


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

X 3 PF

N CE Mdia:

X 4 PF

N CE Alta:

X 6 PF

Total PF:
Tabela 5: Identificao das Consultas Externas da Aplicao

Tabela 6 - Contagem de Sadas Externas (SE): funcionalidades que apresentam


informaes para o usurio com utilizao de clculos ou algoritmos para derivao de
dados ou atualizao de Arquivos Lgicos Internos ou mudana de comportamento da
aplicao. So as consultas ou relatrios com totalizao de dados, relatrios estatsticos,
grficos, gerao de arquivos com atualizao log, downloads com clculo de percentual,
entre outros.
Consideraes: Voc est desenvolvendo uma funcionalidade para apresentar
informaes para o usurio: uma consulta ou relatrio com totalizao de dados, etiquetas
de cdigo de barras, grficos, relatrios estatsticos, download com percentual calculado,
gerao de arquivo com atualizao de log? Caso positivo, estas funes devem ser
identificadas como Sadas Externas. Observe que esta funo deve ter clculos ou
algoritmos para processar os dados referenciados nos arquivos lgicos ou atualizar
campos (normalmente indicadores) nos arquivos ou mudar o comportamento da
aplicao. Se voc no possui conhecimento sobre o processo elementar (funcionalidade
analisada), considere as Sadas Externas com complexidade Mdia.

Roteiro de Mtricas de Software do SISP 2.2

35

________________________________________________________________________________
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.2 Estimativa de Esforo de Projetos de Software


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

Roteiro de Mtricas de Software do SISP 2.2

36

________________________________________________________________________________

6.1.2.1 Distribuio de Esforo por Fase do Projeto


O prximo passo a definio da distribuio de esforo pelas macroatividades
(fases) do projeto, visando definir o valor agregado ao projeto aps cada fase do ciclo de
vida.
A Tabela 7 uma sugesto de macroatividades e distribuio de esforo proposta
neste roteiro. Ressaltamos que o rgo pode definir outras macroatividades e subdividilas para melhor aderncia sua metodologia e aos marcos de entrega. Alm disso, os
percentuais de esforo sugeridos podem variar de acordo com o tipo de projeto e o
processo de desenvolvimento utilizado no rgo. Nesses casos, as macroatividades e
distribuio de esforo devem estar documentadas na metodologia do rgo (especificada
contratualmente) ou formalizadas diretamente no contrato.
Macroatividades do Processo de
Desenvolvimento de Software

Percentual de
esforo (%)

Engenharia de Requisitos

25%

Design / Arquitetura

10%

Implementao

40%

Testes

15%

Homologao

5%

Implantao

5%

Tabela 7: Distribuio de Esforo por Macroatividades do Projeto

6.1.3 Estimativa de Prazo de Projetos de Software


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

Td = V t
Onde:
Td: prazo de desenvolvimento
V: tamanho do projeto em pontos de funo
Roteiro de Mtricas de Software do SISP 2.2

37

________________________________________________________________________________
t: o expoente t definido de acordo com a Tabela 8

Figura 4: Relao entre a Estimativa de Prazo e de Esforo


Tipo de Sistema

Expoente t

Sistema Comum Mainframe (desenvolvimento de


sistema com alto grau de reuso ou manuteno evolutiva)

0,32 a 0,33

Sistema Comum WEB ou Cliente Servidor

0,34 a 0,35

Sistema OO (se o projeto OO no for novidade para


equipe, no tiver o desenvolvimento de componentes
reusveis, considerar sistema comum)

0,36

Sistema Cliente/Servidor (com alta complexidade


arquitetural e integrao com outros sistemas)

0,37

Sistemas Gerenciais complexos com muitas integraes,


Datawarehousing, Geoprocessamento, Workflow

0,39

Software Bsico, Frameworks, Sistemas Comerciais

0,40

Software Militar (ex: Defesa do Espao Areo)

0,45

Tabela 8: Expoente t por Tipo de Projeto

importante destacar que o mtodo s deve ser aplicado para projetos com mais
de 100 PF. Caso o rgo possua dados histricos de projetos, ento este deve trabalhar
com seus dados histricos e modelos de estimativas. Caso o projeto seja menor, o prazo
deve ser obtido por meio da definio de prazo mximo por tamanho funcional com base
em dados histricos do rgo, conforme a Tabela 9.

Roteiro de Mtricas de Software do SISP 2.2

38

________________________________________________________________________________

Prazo mximo (em dias teis)


Tamanho do Projeto

Projetos
Complexidade
Baixa

Projetos
Complexidade
Mdia

At 10 PF

9 dias

15 dias

De 11 PF a 20 PF

18 dias

30 dias

De 21 PF a 30 PF

27 dias

45 dias

De 31 PF a 40 PF

36 dias

60 dias

De 41PF a 50 PF

45 dias

75 dias

De 51 PF a 60 PF

54 dias

90 dias

De 61 PF a 70 PF

63 dias

105 dias

De 71 PF a 85 PF

70 dias

110 dias

De 86 PF a 99 PF

79 dias

110 dias

Tabela 9: Estimativa de Prazo de Projetos menores que 100 PF

Observao: Para os projetos de baixa complexidade foi considerada a produtividade de


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

Roteiro de Mtricas de Software do SISP 2.2

39

________________________________________________________________________________

6.1.4 Alocao de Equipe ao Projeto


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

6.1.5 Mtodo para Estimativa de Custo


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

6.1.6 Estimativa de Recursos Computacionais


A estimativa de recursos computacionais tambm deve ser considerada, pois
constitui um componente importante para as estimativas de custo dos projetos. Um
recurso computacional um hardware que precisa ser adquirido ou que existe mas
precisa ser configurado. Exemplos de recursos computacionais incluem, dentre outros:
espao em disco para o sistema entrar em produo, um servidor especfico para teste ou
homologao do sistema. Devem ser registradas as seguintes informaes associadas
aos recursos computacionais crticos:
Nome do Recurso Computacional: [considere exclusivamente hardware: micro,
perifrico, expanso de memria, rea em disco, banda de rede, etc]
Descrio: [definio das caractersticas do recurso necessrias ao atendimento
ao projeto]
Responsvel pela Disponibilizao: [defina quem o responsvel pela
disponibilizao do recurso para o projeto]
Data Limite: [informe a data limite para disponibilizao do recurso]
Roteiro de Mtricas de Software do SISP 2.2

40

________________________________________________________________________________
Parmetros: [caractersticas do recurso: quantidade, perfil, configurao, etc]
Tipo do Recurso: [D: recurso para ambiente de Desenvolvimento; P: recurso
para ambiente de Produo; H: recurso para ambiente de Homologao]
Custo (Opcional): [Custo do recurso computacional. No considerar custos de
processamento ou custos operacionais de produo]
Caso o projeto a ser desenvolvido no possua nenhum recurso computacional
crtico, isto deve ser registrado no documento de estimativas.

6.2 Diretrizes para Acompanhamento de Projetos


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

6.2.1 Consideraes sobre Mudana de Requisitos


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

As demandas de mudana de requisitos so contagens parte da contagem do


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

Roteiro de Mtricas de Software do SISP 2.2

41

________________________________________________________________________________

preciso aplicar o percentual das fases concludas na frmula do clculo do


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

A contagem de PF_RETRABALHO leva em conta as seguintes caractersticas:


Requisito original: o requisito do projeto de desenvolvimento ou de manuteno
original, que pode ser incluir, alterar ou excluir funcionalidades de um aplicativo.
Tipo da mudana do requisito: a natureza da mudana de requisitos no projeto
em andamento, que pode ser acrescentar um requisito, alterar um requisito
definido ou desistir de um requisito (retirar do escopo do projeto).

A Tabela 10 resume os percentuais que devem ser aplicados sobre as funes


alteradas (considerando o tamanho antes da mudana) para obteno de
PF_RETRABALHO:

Requisito Original
Fator

Incluir
Alterar Excluir
Funo Funo Funo

Acrscimo
Tipo da
Mudana de Alterao
Requisito
Desistncia

Alterao de
Requisitos

50%

50%

Alterao de
Interface

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.

Roteiro de Mtricas de Software do SISP 2.2

42

________________________________________________________________________________
Observaes Importantes:
1. Recomenda-se que o registro das demandas de alterao de requisitos seja
realizado em separado, sendo contado em uma planilha de
PF_RETRABALHO parte da contagem de PF do projeto. Apesar das
medies em separado, elas ainda devem guardar vnculo com o projeto em
andamento, fazendo parte da sua baseline de tamanho.
2. O clculo do PF_RETRABALHO deve registrar o percentual das fases
concludas do processo de desenvolvimento at o momento da mudana
de requisitos, para projetos que no tenham o gerenciamento do seu
progresso, conforme descrito na subseo 6.2.3. Nos projetos onde exista o
gerenciamento do seu progresso, o PF_RETRABALHO deve registrar o
percentual das atividades concludas das fases do processo de
desenvolvimento, no momento da mudana de requisitos, usando os
registros de acompanhamento do progresso do projeto ilustrados na
subseo 6.2.3.
A seguir so descritos os tipos de mudana nos projetos.
1. Acrscimo de funcionalidades ao escopo do projeto
As mudanas que no tragam impacto aos requisitos originais do projeto,
caracterizadas pelo acrscimo de funcionalidades ao escopo do projeto de
desenvolvimento ou de manuteno, sero acrescentadas na contagem de PF do projeto
e no geram contagem de PF_RETRABALHO, ou seja, representam um trabalho
adicional e no retrabalho. Enquadram-se nesta situao a incluso, a alterao ou a
excluso de funes que no constavam no escopo do projeto original.
2. Alterao de funo
A contagem de PF_RETRABALHO referente alterao deve considerar o
percentual de 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.

Roteiro de Mtricas de Software do SISP 2.2

43

________________________________________________________________________________
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:

SE original: 4 PF

PF_RETRABALHO = 0,6 PF Nota 3

PF_RETRABALHO = 0,6 PF x 35%Nota 4

PF_RETRABALHO = 0,21 PF

Roteiro de Mtricas de Software do SISP 2.2

44

________________________________________________________________________________
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.
Nota 4: No contexto do exemplo e usando a distribuio de esforo da Tabela 7, o projeto
na fase de Design/Arquitetura (a ltima fase concluda antes da fase de implementao,
onde ocorreu a solicitao de mudana) registra progresso de 35%. Assim, para fins de
gesto e faturamento, o valor do PF_RETRABALHO seria o correspondente a: 0,6 PF *
35% = 0,21 PF cheios.
Nesse caso de mudana de requisitos com alterao de interface (cosmtica), a
contagem de PF_MELHORIA do projeto original no sofre alterao, visto que a
complexidade da funo SE no alterada.
3. Desistncia de incluir, alterar ou excluir uma funo
Em caso de desistncia de incluir, alterar ou excluir uma funo, deve-se verificar
qual era o requisito original, pois o percentual a ser utilizado na contagem de
PF_RETRABALHO varia para cada situao, conforme apresentado na Tabela 10. Alm
do trabalho de retirar o que foi requisitado (percentuais definidos na Tabela 10), deve-se
considerar tambm em PF_RETRABALHO, o trabalho realizado (fases ou atividades
concludas do processo de desenvolvimento) at o momento da desistncia desse
requisito. Por fim, o requisito original deve ser removido do PF_MELHORIA. Enquadramse nesta situao somente as desistncias de incluir, de alterar ou de excluir
funcionalidades que constavam no escopo do projeto.
Quando a mudana no projeto 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, 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.

Roteiro de Mtricas de Software do SISP 2.2

45

________________________________________________________________________________
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

PF_RETRABALHO = 6,5 PF x 35%Nota 6

PF_RETRABALHO = 2,275 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.
Nota 6: No contexto do exemplo e usando a distribuio de esforo da Tabela 7, o projeto
na fase de Design/Arquitetura (a ltima fase concluda antes da fase de implementao,
onde ocorreu a solicitao de mudana) registra progresso de 35%. Assim, para fins de
gesto e faturamento, o valor do PF_RETRABALHO seria o correspondente a: 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

PF_RETRABALHO = 1,4 PF

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.
Nota 8: No contexto do exemplo e usando a distribuio de esforo da Tabela 7, o projeto
na fase de Design/Arquitetura (a ltima fase concluda antes da fase de implementao,
onde ocorreu a solicitao de mudana) registra progresso de 35%. Assim, para fins de
gesto e faturamento, o valor do PF_RETRABALHO seria o correspondente a: 4 PF *
35% = 1,4 PF cheios.
Roteiro de Mtricas de Software do SISP 2.2

46

________________________________________________________________________________
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 excluir a funo da aplicao, deve-se considerar esses dois
aspectos separadamente, como se fossem duas mudanas consecutivas:
A) Conta-se a desistncia de alterar a funo conforme descrito no item 3
(Desistncia de incluir, alterar ou excluir uma funo), apurando a quantidade
de PF_RETRABALHO correspondente e a atualizao do PF_MELHORIA;
B) Conta-se o acrscimo ao escopo do projeto (excluir a funo da aplicao)
conforme descrito no item 1 (Acrscimo ao escopo do projeto), atualizando-se
PF_MELHORIA.

6.2.2 Consideraes sobre Projetos Cancelados


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

6.2.3 Gerenciamento de Progresso de Projetos


O acompanhamento do projeto deve identificar o progresso de cada requisito do
projeto, ou seja, o percentual de concluso de cada fase do processo de software para o
requisito em questo.
A apurao do percentual concludo em cada fase deve ser definido em comum
acordo entre o rgo contratante e a empresa contratada, de acordo com os artefatos
entregues em cada fase. Os artefatos que esto na fbrica, mas no foram entregues,
no devem ser considerados nessa apurao.

Roteiro de Mtricas de Software do SISP 2.2

47

________________________________________________________________________________
Segue um exemplo de acompanhamento do progresso do desenvolvimento de um
Sistema de Gesto de Projetos, que mostra para cada um dos requisitos o percentual
concludo de cada fase:
Requisito

Tamanho

Caso de Uso 1

19 PF

Engenharia de
Requisitos

Design,
Arquitetura

50,00%

Implementao

Testes

Homologao

Implantao

20%

0%

10%

0%

0%

100%

50%

20%

0%

0%

Atividade
Incluir Ativ.
Alterar Ativ
Excluir Ativ
Consultar Ativ
Caso de Uso 2

5 PF

100 %

- Relatrio de
Projetos
....

Supondo a mudana de requisitos no Caso de Uso 2 do exemplo acima, para


incluso de uma nova informao a ser apresentada no Relatrio, a contagem de PF do
requisito original a seguinte:
Caso de Uso 2 Relatrio de Projetos 5 PF
Macroatividades

Esforo da Fase

Tamanho

Esforo
realizado

Tamanho
realizado

Engenharia de
Requisitos

25%

1,25 PF

100%

1,25 PF

Design, Arquitetura

10%

0,5 PF

100%

0,5 PF

Implementao

40%

2 PF

50%

1 PF

Testes

15%

0,75 PF

20%

0,15 PF

Homologao

5%

0,25 PF

0%

0 PF

Implantao

5%

0,25 PF

0%

0 PF

Total: 2,9 PF
O tamanho realizado do requisito original de 2,9 PF. Conforme descrito na
subseo 6.2.1, para o clculo do PF_RETRABALHO do requisito alterado ser
considerado o fator de impacto de 50% na contagem de PF. Portanto, a contagem do
PF_RETRABALHO 2,9 x 0,50 = 1,45 PF.

6.2.4 Consideraes sobre Reduo de Cronograma


Como apresentado anteriormente, as estimativas de prazo no so lineares com o
tamanho do projeto. Jones [Jones, 2007] prope uma frmula, descrita na subseo 6.1.3,
para o clculo do melhor tempo de desenvolvimento (onde h uma melhor relao custo x
benefcio de alocao de recursos e menor prazo de desenvolvimento), dado o tamanho
de um projeto especfico.
Alguns projetos, devido legislao e a outros fatores externos, j se iniciam com
um prazo imposto. Se este prazo for igual ou superior ao prazo calculado pela frmula de
Capers Jones (expoente t) ou, em caso de projetos pequenos (menores que 100 PF),
igual ou superior a um prazo calculado considerando o trabalho da equipe de 7 horas/dia
Roteiro de Mtricas de Software do SISP 2.2

48

________________________________________________________________________________
nos dias teis (conforme sugerido na subseo 6.1.3), ento o projeto tratado como
normal.
No entanto, se o projeto tiver um prazo imposto inferior ao prazo calculado, ento
pode-se considerar a seguinte proposta como uma sugesto de valores:
Reduo de prazo de 10%: aumento de esforo de 20% (projetos urgentes);
Reduo de prazo de 20%: aumento de esforo de 50% (projetos crticos);
Reduo de prazo de 25%: aumento de esforo de 70% (projetos de alta
criticidade).
Os valores acima devem ser avaliados e definidos a critrio do rgo, caso esse
cenrio possa ocorrer durante o contrato.
Deve-se ressaltar que no possvel uma reduo de prazo maior que 25%,
devido aos clculos de Regio Impossvel e ainda, conforme nos aproximamos da Regio
Impossvel, o esforo e o custo do projeto aumentam de maneira exponencial.
Como os riscos da reduo de cronograma tambm so altos, no recomendada
a reduo de cronograma. Deve-se tentar priorizar funcionalidades trabalhando com o
processo incremental.
Caso o contrato seja baseado em preo por pontos de funo, este aumento de
esforo ser refletido na contagem de PF. Assim, um aumento de esforo de 20% implica
em aumento de 20% no custo de PF; aumento de esforo de 50% implica em aumento de
50% no custo de PF; e o aumento de esforo de 70% implica em aumento de 70% no
custo de PF.
No recomendado o uso de reduo de cronograma, pode-se utilizar processos
incrementais de desenvolvimento e trabalhar com definio de prioridades. importante
ressaltar que estas questes devem ser definidas em clusulas contratuais e devem ser
consideradas no oramento do contratante.

6.2.5 Fator de Criticidade de Solicitao de Servio


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

Roteiro de Mtricas de Software do SISP 2.2

49

________________________________________________________________________________

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:

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

Roteiro de Mtricas de Software do SISP 2.2

50

________________________________________________________________________________
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, 2014], [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.1 Conceitos
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.
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, devese 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. Ness 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,
Roteiro de Mtricas de Software do SISP 2.2

51

________________________________________________________________________________
detalhamento e complementao
desenvolvimento.

de

requisitos

durante

processo

de

7.2. Orientaes
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 econmicofinanceiro 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;

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 item Diretrizes para Acompanhamento de Projetos deste Roteiro no deve ser
Roteiro de Mtricas de Software do SISP 2.2

52

________________________________________________________________________________
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.3 Tratamento 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,
consequentemente, 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.1 Fatores que Influenciam


Funcionalidades no Processo gil

Nmero

de

Mudanas

em

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.
Roteiro de Mtricas de Software do SISP 2.2

53

________________________________________________________________________________
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);
- 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.1 Exemplo 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.

Roteiro de Mtricas de Software do SISP 2.2

54

________________________________________________________________________________

Release N
(composta de
3 Sprints)

Tipo

Observao

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

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

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
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


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
Roteiro de Mtricas de Software do SISP 2.2

55

________________________________________________________________________________
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.
Release N
(composta de
3 Sprints)

Processo Elementar
(PE)

Categoria
(Inc, Alt, Exc,
Refin)

Tipo

Observao

(ALI, AIE,
EE, CE, SE)

Complex.

PF

Incluir Aluno

Inc

EE

Baixa

Aluno

Inc

ALI

Baixa

Sprint 1

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).

Incluir Disciplina

Alt

EE

Baixa

1,5

Alterar Aluno

Inc

EE

Baixa

Refin

ALI

Baixa

Mudana caracterizada como


refinamento de funcionalidade
para atender o PE Alterar
Aluno. Sem custo PF.
Alterao caracterizada como
Projeto de Melhoria (PE
desenvolvido e pronto na
Release N-1). Aplicado o fator
de impacto de 50%
(3PF*0,5=1,5PF).

Aluno
Sprint 2

Alterar Disciplina

Alt

EE

Baixa

1,5

Emitir Relatrio de
Alunos por Disciplina

Inc

SE

Mdia

Incluir Aluno

Refin

EE

Baixa

Mudana caracterizada como


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

Incluir Disciplina

Refin

EE

Baixa

Mudana caracterizada como


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

Alterar Disciplina

Refin

EE

Baixa

Mudana caracterizada como


refinamento de funcionalidade
para atender o PE Alterar
Disciplina. Sem custo PF.

1,5

Alterao caracterizada como


Projeto de Melhoria (PE
desenvolvido e pronto na
Release N-1). Aplicado o fator
de impacto de 50%
(3PF*0,5=1,5PF).

Sprint 3

Emitir Relatrio de
Disciplinas

Alt

Total de PF da release

EE

Baixa

22,5

Tabela 12 Contagem Detalhada de Pontos de Funo da Release N


Roteiro de Mtricas de Software do SISP 2.2

56

________________________________________________________________________________
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.
Tipo
Processo Elementar (PE)

(ALI, AIE, EE,


CE, SE)

Complex.

PF

Aluno

ALI

Baixa

Incluir Aluno

EE

Baixa

Alterar Aluno

EE

Baixa

Emitir Relatrio de Alunos por


Disciplina

SE

Mdia

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

Roteiro de Mtricas de Software do SISP 2.2

57

________________________________________________________________________________

8. Atividades Sem Contagem de Pontos de Funo


Deve-se ressaltar que, no processo de desenvolvimento de um projeto de software,
h atividades que devem ser consideradas como complementares ou pr-requisitos ao
processo de desenvolvimento, de modo que os esforos e produtos entregues devem ser
contratados e remunerados em itens distintos do desenvolvimento por no se tratarem de
atividades de desenvolvimento do software ou inerentes ao processo desenvolvimento do
software. So atividades categorizadas nessa condio:
Definio de Processo de Desenvolvimento de Solues: so as demandas para
definio de Processos de Software, aderentes s melhores prticas do CMMI e
Instruo Normativa SLTI n 4, de 12 de novembro de 2010 que devem estar
definidos antes da contratao de servios de desenvolvimento de software.
Desenvolvimento de Cursos para EaD: so as demandas de elaborao de
contedo e montagem de material para um curso na modalidade de Ensino a
Distncia (EaD). Se enquadram no mesmo caso dos Treinamentos citado
anteriormente.
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. Essa uma atividade que deve ser
realizada antes da abertura do projeto de desenvolvimento de software.
importante ressaltar que essa atividade de responsabilidade dos analistas de
negcio da empresa contratante, de acordo com a Instruo Normativa SLTI n 4,
de 12 de novembro de 2010. No entanto, por falta de pessoal, alguns rgos e
entidades tm contratado estas atividades, que antecedem a fase de requisitos
primeira fase do processo de software.
Treinamentos em Tecnologia da Informao em geral: so as demandas de
treinamentos em linguagens de programao, ferramentas de gesto, processos,
modelos da qualidade, mtricas, etc.
Outras atividades contidas em um processo de software devem ser gerenciadas
dentro do projeto de desenvolvimento e so inerentes ao processo de desenvolvimento de
software, no devendo ser mensuradas separadamente . So elas:
Acompanhamento de Projetos: a atividade que a contratada faz internamente de
modo a se organizar e planejar o atendimento dos cronogramas e outras
demandas recebidas da contratante, cuja natureza intrnseca ao desenvolvimento
e manuteno de sistemas. Ou seja, ao desenvolver e manter sistemas, a tarefa de
acompanhar e gerir o projeto por parte da contratada figuram como seus deveres
contratuais, no cabendo pagamento por atividades que dizem respeito sua
prpria gesto interna;
Correo de erros: erros e bugs que venham a se manifestar em ambiente de
produo dentro do perodo de garantia contratado.
Especificao de Requisitos: em metodologias geis, o levantamento de requisitos
inerente ao processo de desenvolvimento de software, no devendo ser
mensurado e remunerado separadamente. Em outras metodologias, caso o rgo
opte por realizar o levantamento de requisitos separadamente do processo de
desenvolvimento de software, esse deve ser remunerado por horas de consultoria.
Roteiro de Mtricas de Software do SISP 2.2

58

________________________________________________________________________________
Projeto e desenvolvimento de Banco de Dados: as atividades de banco de dados
associadas ao projeto de desenvolvimento, modelagem dos bancos seguindo as
polticas de dados da contratante, preparao de ambiente (testes, homologao,
implantao), desempenhadas pela contratada j devem ser consideradas dentro
do projeto de software, no cabendo cobrana adicional.
Treinamento para Implantao: so demandas de treinamentos sobre utilizao do
sistema desenvolvido pela contratada a ser implantado, para os gestores de
soluo do cliente e usurios e devem ser tratadas no escopo da fase de
transferncia do conhecimento para a contratante.
Finalmente, tendo em vista que j foram identificados casos concretos do uso
incorreto do Ponto de Funo, cabe reforar que atividades cuja a natureza difere
totalmente do objeto contratado (servios de desenvolvimento de software) no podem
ser remuneradas por pontos por funo, so exemplos:
Deslocamentos e viagens de integrantes da contratada para prestao dos
servios em diferentes localidades;
Suporte ao Usurio e Rede no uso do software desenvolvido, principalmente
quando englobando atividades como instalao de microcomputadores e demais
perifricos.

9. Processo de Reviso do Roteiro de Contagem


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

9.2 Reviso para Adoo de Novas Verses do CPM


A adoo de nova verso do CPM como referncia para este roteiro de contagem
no ser imediata sua publicao. Nesse caso, dever haver uma avaliao da nova
verso para se decidir sobre a atualizao deste documento. Em caso de utilizao de
roteiro de mtricas em contratos de software, a atualizao do roteiro deve ser negociada
entre rgo contratante e a empresa contratada.

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.
Roteiro de Mtricas de Software do SISP 2.2

59

________________________________________________________________________________
importante ressaltar que o uso de mtricas em contrato de software uma boa
prtica, visando proporcionar uma gesto efetiva dos contratos com base em dados
quantitativos e objetivos. A implantao desta modalidade de contrato implica na definio
de processos de gesto de requisitos e de gesto de projetos baseados nas melhores
prticas. Outro ponto a ser destacado a implantao de um Escritrio de Mtricas com
servidores capacitados para realizar contagens e estimativas em pontos de funo. Estes
servidores sero responsveis pela reviso das contagens de pontos de funo e
estimativas realizadas pelo Escritrio de Mtricas da empresa contratada e pela
manuteno do roteiro de mtricas do rgo.
Como trabalho futuro, recomenda-se a reviso e atualizao deste roteiro sempre
que for verificada inconsistncia entre alguma definio do IFPUG publicada em verses
futuras do CPM ou em White Paper, ou quando for detectado um novo tipo de servio
associado ao desenvolvimento de software no previsto neste roteiro. Neste sentido,
como trabalho futuro est programada a elaborao de um modelo de mensurao para
servios de desenvolvimento e manuteno referentes a projetos de DW,
Geoprocessamento, Workflow e Portais utilizando Gerenciadores de Contedo, que
representam cenrios existentes em alguns rgos do SISP.

10. Referncias Bibliogrficas


[Boehm, 2009] BOEHM, B.W. Software Cost Estimation With COCOMO II. Prentice
Hall, New Jersey, 2009.
[CAIXA, 2012] CAIXA. Guia de Orientao - Mtricas, verso 10, 2012.
[Castro e Hernandes, 2014] CASTRO, M. V. B. de; HERNANDES, C. A. M.. A Metric of
Software Size as a Tool for IT Governance. Procedings in: SBES, 2014.
[Dekkers, 2003] DEKKERS, C. Measuring the logical or functional Size of Software
Projects and Software Application. Spotlight Software, ISO Bulletin May 2003, pp10-13.
[Hazan, 2005]
HAZAN C.; STAA, A.v. Anlise e Melhoria de um Processo de
Estimativas de Tamanho de Projetos de Software. Monografias em Cincias da
Computao n 04/05, Departamento de Informtica PUC-Rio, ISSN 0103-9741, Fevereiro
2005.
[Hazan, 2008] HAZAN, C. Anlise de Pontos de Funo: Uma Aplicao nas
Estimativas de Tamanho de Projetos de Software. Engenharia de Software Magazine,
Edio 2, Devmedia, pp.25-31.
[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
Roteiro de Mtricas de Software do SISP 2.2

60

________________________________________________________________________________
Comparative Overview. Proceedings of FESMA 99, Amsterdam, Netherlands, October
1999, pp. 271-286.
[NESMA, 2005] NESMA. Neetherlands Software Metric Association. The application of
Function Point Analysis in the early phases of the application life cycle. A Practical
Manual: Theory and case study, 2005.
[NESMA, 2009] NESMA. Function Point Analysis for Software Enhancement
Guidelines. Version 2.2.1, 2009
[Parthasarathy,2007] PARTHASARATHY, M. A. Practical Software Estimation: function
point methods for insourced and outsourced projects. Addison Wesley, New York,
2007.
[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.

Roteiro de Mtricas de Software do SISP 2.2

61

________________________________________________________________________________

Anexo I Portaria SLTI/MP N 31, de 29 novembro de 2010


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

Roteiro de Mtricas de Software do SISP 2.2

62

________________________________________________________________________________

Anexo II Formalizao Simples de Requisitos Projetos de


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

DD/MM/AAAA

Data do Trmino do Servio DD/MM/AAAA


Descrio da Solicitao

Descrio do Servio Executado


Requisito

Detalhamento

1.

1.1
1.2...

2.

2.1
2.2...

Roteiro de Mtricas de Software do SISP 2.2

63

________________________________________________________________________________

Identificao da Manuteno
Tipo
Melhoria
Migrao de Dados
Corretiva
Mudana de Plataforma - Linguagem de Programao
Mudana de Plataforma - Banco de Dados
Atualizao de Verso Linguagem de Programao
Atualizao de Verso Browser
Atualizao de Verso Banco de Dados
Manuteno em Interface (Cosmtica)
Adaptao em Funcionalidades sem Alterao de Requisitos Funcionais
Apurao Especial Base de Dados
Apurao Especial Gerao de Relatrios
Apurao Especial Reexecuo
Atualizao de Dados
Desenvolvimento, Manuteno e Publicao de Pginas Estticas de Intranet, Internet
ou Portal
Manuteno de Documentao de Sistemas Legados
Verificao de Erros
Pontos de Funo de Teste (Execuo de Testes em funcionalidades no mantidas)
Componente Interno Reusvel

Foi demandada a redocumentao da funcionalidade mantida? Sim


Aplicar Fator Criticidade? Sim

No

No

Observaes relevantes quanto ao tipo de manuteno:

Roteiro de Mtricas de Software do SISP 2.2

64

________________________________________________________________________________
Descrio dos Requisitos de Manuteno (para cada funcionalidade alterada, utilizar um
quadro)
a) Tabelas Modificadas pela Manuteno
Nome da Tabela
A Tabela atualizada por alguma funcionalidade da aplicao: Sim
A Tabela atualizada por outra aplicao: Sim
A Tabela foi:

Includa

No

No

Alterada

Excluda

Total de Campos da Tabela aps a Manuteno =


Campos Includos/Alterados/Excludos

A funcionalidade ser apenas testada?


Sim

No

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


Nome da Entrada
Total de Campos na Entrada =
Nome das Tabelas Acessadas (Lidas e Gravadas) =
Campos Includos/Alterados/Excludos

Houve mudana na regra de negcio (validaes, lgica de processamento, regras de


clculo)?
Sim

No

A funcionalidade ser apenas testada?


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.

Roteiro de Mtricas de Software do SISP 2.2

65

________________________________________________________________________________
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

Campos Includos/Alterados/Excludos

Houve mudana na regra de negcio (validaes, lgica de processamento, regras de


clculo, campos de filtro)?
Sim

No

A funcionalidade ser apenas testada?


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

Campos Includos/Alterados/Excludos

Houve mudana na regra de negcio (validaes, lgica de processamento, regras de


clculo, campos de filtro)?
Sim

No

A funcionalidade ser apenas testada?


Sim

No

Roteiro de Mtricas de Software do SISP 2.2

66

________________________________________________________________________________

Anexo III Modelo de Documento de Contagem de Pontos de Funo


Projetos de Manuteno Pequenos (< 100 PF)
Documento de Contagem de Pontos de Funo de Projetos de Manuteno Pequenos
Cliente:

Histrico da Reviso
Data

Verso Descrio

Autor

Aprovador

Nome Projeto:
Nmero da OS:
Responsvel pela Contagem:
Descrio da Solicitao de Mudana:
Descrio da Atividade

Contagem PF

Tipo de Manuteno / Total PF

Observaes Relevantes:
Conforme a tabela de atividades acima, o total de pontos de funo realizados no Projeto
_____ na OS _________ de _____ PF.

Roteiro de Mtricas de Software do SISP 2.2

67

________________________________________________________________________________

Anexo IV - Como Evitar Armadilhas em Contratos de Desenvolvimento e


Manuteno de Sistemas
Claudia Hazan
claudia.hazan@serpro.gov.br
Servio Federal de Processamento de Dados (SERPRO)

Este anexo tem como propsito apresentar algumas dicas para as organizaes
contratantes evitarem armadilhas em contratos de desenvolvimento e manuteno de
software baseados em preo fixo por pontos de funo.
Obtenha um Documento de Requisitos de Qualidade
Conforme mencionado, a mtrica PF mede a funcionalidade requisitada e recebida
pelo usurio. O documento de requisitos constitui um acordo comum entre os rgos
contratantes e empresas contratadas. Assim, fundamental a existncia de um Termo de
Aceite associado aos documentos de requisitos, assinado pelo gestor do sistema ou
gestor do contrato do rgo contratante. Alm disso, o contratante deve garantir a
qualidade do documento de requisitos encaminhado para a contratada. Observe que se o
contratante fornece um documento de requisitos com um requisito incompleto, a empresa
contratada entregar o produto sem a funcionalidade esperada e a organizao
contratante ter que pagar por isso.
A Engenharia de Requisitos apresenta vrias tcnicas para suportar as atividades de
verificao e validao de Documentos de Requisitos, no entanto, estas tcnicas so
muito custosas. Sugere-se a utilizao do mtodo Contagem Estimativa de Pontos de
Funo, alm de apoiar nas estimativas do projeto, o mtodo suporta a deteco de
defeitos em documentos de requisitos pelo estimador, enquanto ele est estimando o
projeto, sem custo ou esforo adicional, conforme demonstrado por Hazan [Hazan, 2005].
Considerando as revises e auditorias em contagem de pontos de funo dos projetos
contratados, importante que o documento de requisitos e o documento de contagem de
PF ou estimativas estejam consistentes.
Estabelea Regras para o Tratamento das Mudanas de Requisitos
A Engenharia de Requisitos e a indstria reconhecem que os requisitos no
permanecem congelados at a concluso do projeto de software. Os requisitos evoluem
desde a sua concepo at mesmo aps o sistema entrar em produo, devido a diversos
fatores descritos por Kotonya [Kotonya, 1998]. Assim, fundamental que o contrato de
software estabelea clusulas para tratamento das mudanas de requisitos. importante
ressaltar que o gestor do contrato deve evitar encaminhar para a contratada os requisitos
de negcio que estejam em fase de definio, seno podero emergir muitas mudanas
em requisitos elevando o custo do projeto em questo. Recomenda-se a implantao de
processos de gerenciamento de projetos e gerenciamento de requisitos pelos
contratantes, aderentes s melhores prticas de modelos da Qualidade de Software,
visando uma gesto efetiva dos projetos contratados.

Roteiro de Mtricas de Software do SISP

68

________________________________________________________________________________
Estabelea Clusulas de Garantia da Qualidade
Conforme mencionado, a mtrica PF considera a funcionalidade requisitada e
recebida pelo usurio. Portanto, a remunerao da empresa contratada deve considerar
as funcionalidades entregues, somente se estas no apresentarem defeitos. Contudo, o
seguinte cenrio pode ocorrer: a empresa contratada entrega as funcionalidades
requisitadas com defeitos; o gestor do contrato reclama, a empresa contratada corrige os
erros da funcionalidade em questo; a contratante recebe o sistema de volta com outros
defeitos que surgiram com a correo do erro relatado. Esse tipo de problema comum
em fbricas de software com um processo de testes inexistente ou inadequado. Observe
que essa situao pode gerar um grande atraso no recebimento do sistema, podendo
gerar atritos entre a rea de TI do rgo contratante e os gestores do sistema que esto
aguardando a entrega do sistema funcionando. Assim, recomenda-se o estabelecimento
de clusulas contratuais para garantir a entrega de um projeto de desenvolvimento ou
manuteno de sistemas com qualidade. Sugere-se incluir no contrato uma clusula de
multa associada qualidade do produto entregue, considerando o indicador defeitos/PF.
Por exemplo, pode-se estabelecer que no aceitvel a entrega de mais de 0,3
defeitos/PF. importante definir no contrato os tipos de defeitos, a saber: bugs, defeitos
na documentao, cdigo fonte no estruturado, etc. Pode-se estabelecer tambm nveis
de severidade de defeitos.
Estabelea Clusulas Contratuais de Prazo e Taxa de Entrega
Algumas organizaes contratantes estabelecem clusulas contratuais associadas
produtividade. Por exemplo, a empresa contratada deve ter uma produtividade de 15
HH/PF em JAVA. Em alguns casos, o rgo contratante pede para a contratada relatar a
taxa de produtividade. Esta prtica no adequada. A produtividade uma informao
estratgica de uma empresa e ela no pode ser obrigada a divulgar estas informaes.
Alm disso, deve-se ressaltar que em um contrato baseado em PF, o controle da
produtividade da empresa contratada no faz sentido. De fato, os rgos contratantes
empregam esta prtica para resolver o problema de demandas recebidas com atraso de
cronograma. A soluo estabelecer no contrato o mtodo de estimativa de prazo a ser
utilizado. Recomenda-se que este mtodo utilize o tamanho em PF estimado do sistema
na derivao da estimativa de prazo. Alm disso, deve-se incluir clusulas de multa
considerando o atraso da entrega do projeto. Para as organizaes que no possuem um
processo de estimativas definido, sugere-se a utilizao da frmula de Capers Jones
descrita em [Jones, 2007]. importante ressaltar que a frmula adequada apenas para
projetos maiores que 100 PF. Em relao aos projetos pequenos, o contrato deve fixar
prazos de acordo com o tamanho do projeto. Por exemplo, para projetos com at 5 PF o
prazo de entrega de 8 dias teis.
Outro cenrio a ser considerado o seguinte: a empresa contratada ganha um
prego fornecendo um preo muito baixo por PF e ao ganhar o contrato ela busca forar o
aumento do preo do PF contratado, definindo regras prprias para a contagem de PF.
Como os rgos pblicos esto se capacitando em contagem de pontos de funo, o
gestor do contrato no aceita a contagem de PF majorada. Ento, a empresa contratada
aloca apenas um recurso para atendimento daquele contrato, ressaltando que os demais
recursos esto trabalhando em contratos mais lucrativos. E as demandas de manuteno
crticas do contratante ficam pendentes no atendimento. Portanto, visando evitar este
problema, importante definir clusulas contratuais estabelecendo uma taxa de entrega
mnima de PF/ms, por exemplo, 200 PF/ms. Deve-se incluir uma clusula de multa
tratando essa questo. O estabelecimento de uma taxa de entrega mensal mxima e
mnima tambm importante para a empresa contratada dimensionar suas equipes para
um melhor atendimento ao contrato.
Roteiro de Mtricas de Software do SISP

69

________________________________________________________________________________
Estabelea o CPM como a Base para as Contagens de PF ao invs de
Converses
Alguns rgos contratantes estabelecem seus contratos com base na mtrica Ponto
de Funo, no entanto no possuem capacitao adequada em contagem de pontos de
funo. Em alguns casos, estes rgos delegam a contagem para a empresa contratada,
que estabelece roteiros de contagem com regras que podem majorar a contagem de PF.
Algumas vezes, o dimensionamento do tamanho do projeto em PF realizado por meio
de converses de horas alocadas em pontos de funo. Assim, estabelecido com a
empresa contratada um ndice de converso, por exemplo, 8 horas de trabalho
corresponde a 1 PF, e ento o pagamento da empresa contratada feito por meio das
horas alocadas ao projeto em questo convertidas em PF. Observe que se o recurso de
desenvolvimento est em uma empresa contratada externa ao rgo contratante, este
no pode gerenciar a quantidade de horas alocada ao projeto. Se o analista da empresa
contratada est realizando seu trabalho nas instalaes do contratante, isto um tipo de
terceirizao de mo de obra. E ainda, se a contratada alocar um recurso com baixa
produtividade, o custo do projeto ser muito alto. A prtica de converso de horas para PF
simples, no entanto inadequada. Se o contrato baseado em pontos de funo, a
empresa deve realizar as contagens seguindo as regras de contagem do manual CPM.
Deve-se ressaltar que uma contagem de PF errnea pode levar a conseqncias
desastrosas, tais como: pagamento incorreto do projeto contratado por PF, gerao de
dados para indicadores de qualidade defeitos/PF e produtividade horas/PF incorretos,
gerao de estimativas incorretas. fundamental que as organizaes que desejam
estabelecer contratos de prestao de servios de desenvolvimento e manuteno de
sistemas com base em pontos de funo criem seu Escritrio de Mtricas com
profissionais especialistas em contagem de pontos de funo. recomendado que estes
profissionais possuam certificao CFPS (Certified Function Point Specialist) e possuam
experincia prtica em contagem de PF e mtodos de estimativas de projetos de
software. As empresas contratadas tambm devem ter seu escritrio de mtricas para
revisar a contagem de PF do rgo contratante. Seguindo estas recomendaes
possvel evitar ou diminuir a incidncia de erros de contagem como os relatados em
Hazan [Hazan, 2008].
Estabelecer Regras para Dimensionar Projetos de Manuteno
Muitas organizaes estabelecem em seus contratos de prestao de servios de
desenvolvimento e manuteno de sistemas a prestao de servios de desenvolvimento
e manuteno de sistemas com base na mtrica Ponto de Funo. No entanto, o Manual
de Prticas de Contagem (CPM) trata apenas os projetos de desenvolvimento e de
manuteno evolutiva. Assim, torna-se importante a definio de mtricas para os demais
projetos de manuteno. Pode-se contratar tais projetos em homem/hora, no entanto,
conforme mencionado a IN 04 preconiza evitar a contratao de servios de
desenvolvimento e manuteno de sistemas por meio da mtrica homem_hora. Assim,
recomenda-se a utilizao de mtricas baseadas nas regras de contagem de pontos de
funo para dimensionar os projetos de manuteno no contemplados no manual CPM.
O primeiro passo a identificao de todos os tipos de projetos de manuteno que
podem ser contratados pela organizao. Posteriormente, deve-se definir mtricas para
dimensionar tais projetos. O Roteiro de Mtricas do SISP sugere frmulas de clculo.

Roteiro de Mtricas de Software do SISP

70

________________________________________________________________________________
Estabelecer detalhes do processo de prestao de servios no Edital
importante ressaltar que em um processo de contratao de servios de
desenvolvimento e manuteno de sistemas, alm da estimativa de tamanho do projeto
em pontos de funo, outros aspectos devem ser considerados, a saber: definio do
processo de desenvolvimento a ser seguido pela contratada com detalhamento dos
artefatos a serem entregues, cronograma do projeto, definio dos acordos de nvel de
servio, definio com clareza do objeto a ser contratado, considerando os requisitos
funcionais e os requisitos no funcionais do projeto. Observe que os requisitos no
funcionais (performance, segurana, padro de interface, etc) no contam pontos de
funo, no entanto, impactam nas estimativas de esforo, custo e prazo do projeto.
MELHORES PRTICAS EM CONTAGEM DE PONTOS DE FUNO
Em contratos baseados em mtricas fundamental garantir a qualidade da
documentao das contagens de pontos de funo dos projetos. Seguem algumas
melhores prticas a serem consideradas na documentao das contagens e estimativas
de pontos de funo:
-

Documentao da Fronteira da Aplicao

Toda contagem ou estimativa de pontos de funo realizada em uma fronteira da


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

Documentao dos Requisitos de Projetos de Manuteno

A grande maioria dos projetos de software das organizaes de manuteno de


sistemas existentes. Em geral, comum observarmos documentao de desenvolvimento
de novos sistemas. No entanto, a documentao dos projetos de manuteno, muitas
vezes, consiste na atualizao da documentao da aplicao implantada. Cabe ressaltar
que essa prtica no adequada para a contagem de pontos de funo, porque na
contagem de projetos de manuteno necessria a identificao das funcionalidades
impactadas (includas, alteradas ou excludas). Por exemplo, o envio de uma tela como
funcionalidade alterada em um projeto de manuteno, no permite a contagem de PF do
projeto, porque esta tela pode trazer funcionalidades de incluso, alterao, consulta,
excluso e combo boxes. Se a mudana for na lgica de validao de um campo,
provavelmente, as funcionalidades impactas so apenas a incluso e a alterao. Ento,
a consulta, a excluso e as combo boxes no devem ser contadas. fundamental a
elaborao de um documento de requisitos especfico, mesmo que simplificado, para o
Roteiro de Mtricas de Software do SISP

71

________________________________________________________________________________
projeto de manuteno. Este documento ser a base para a contagem de pontos de
funo do projeto de manuteno. De fato, os documentos de requisitos da aplicao
implantada tambm devero ser atualizados.
-

Documentao da Contagem com Rastreabilidade para Requisitos

Em contratos baseados em pontos de funo, as contagens e estimativas de pontos


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

Identificao da Funo

Tipo

....

requisito/observaes/justificativa

Relatrio de Treinamentos
Ministrados por perodo

SE

...

Caso de Uso 5 Foi contado como SE por


conta da totalizao dos cursos.

....

....

....

....

Documentao das Funcionalidades Identificadas

Algumas padronizaes na nomenclatura das funes identificadas podem ser


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

DEKKERS, C. Measuring the logical or functional Size of Software


Projects and Software Application. Spotlight Software, ISO Bulletin
May 2003 pp10-13.

Roteiro de Mtricas de Software do SISP

72

________________________________________________________________________________
[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.

Roteiro de Mtricas de Software do SISP

73

________________________________________________________________________________

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:

Roteiro de Mtricas de Software do SISP

74

________________________________________________________________________________
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.

Roteiro de Mtricas de Software do SISP

75

________________________________________________________________________________

Anexo VI Notas Tcnicas das Verses Anteriores deste Roteiro


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

Roteiro de Mtricas de Software do SISP

76

________________________________________________________________________________

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.
Equipe de Elaborao da Verso 2.0
Carlos Alberto Pires de Castro DATAPREV
Carlos Renato dos Santos Ramos Cmara dos Deputados
Claudia Hazan SERPRO
Edviges Mariza Campos de Magalhes DATAPREV
Emanuelle Monteiro Silva SLTI/MP
Gileno Dias dos Santos SLTI/MP
Inerves Jos dos Santos Filho STN
Lucinia Turnes SLTI/MP
Marcelo Paiva Fernandes SLTI/MP
Marcelo Teixeira Duarte DATAPREV
Marcus Vincius Borela de Castro TCU
Maurcio Koki Matsutani DATAPREV
Patrcia Oliveira de Carvalho SUSEP
Rafael Monteiro dos Santos Escolstico AGU
Regiane Andrade Brito BACEN
Silvia Viviane de Souza Belarmino IPHAN

Nota Tcnica da Verso 2.1


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

Roteiro de Mtricas de Software do SISP

77

________________________________________________________________________________
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.
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

Roteiro de Mtricas de Software do SISP

78