Roteiro de Métricas de Software do SISP Versão 1.

0

Brasília, 29 de novembro de 2010.

________________________________________________________________________

Roteiro de Métricas de Software do SISP

2

________________________________________________________________________

Presidente da República
Luiz Inácio Lula da Silva

Ministério do Planejamento, Orçamento e Gestão
Paulo Bernardo Silva

Secretaria de Logística e Tecnologia da Informação – SLTI
Maria da Glória Guimarães dos Santos

Departamento de Integração de Sistemas – DSI
Nazaré Lopes Bretas

Coordenação Geral de Gestão Corporativa – CGGC
Claudio Muniz Machado Cavalcanti

Núcleo de Padronização Tecnológica
Corinto Meffe Equipe de Elaboração
Carlos Renato dos Santos Ramos (SLTI/MP) Claudia Hazan (SERPRO) Claudio Muniz Machado Cavalcanti (SLTI/MP) Emanuelle Monteiro Silva (SLTI/MP) Fátima Saldanha Cesarino (CEF) Gileno Dias dos Santos (SLTI/MP) Jose Romildo Araujo de Andrade (SLTI/MP) Lucinéia Turnes (SLTI/MP) Marcelo Paiva Fernandes (SLTI/MP) Maurício Koki Matsutani (DATAPREV) Patrícia Oliveira de Carvalho (SUSEP) Rafael Campos (SLTI/MP) Rafael Monteiro dos Santos Escolástico (MEC) Regiane Brito (BACEN) Rosa Maria da Costa Medeiros (INEP)

Roteiro de Métricas de Software do SISP

3

________________________________________________________________________

Roteiro de Métricas de Software do SISP

4

________________________________________________________________________

Sumário
1. Introdução..........................................................................................................................7 2. Objetivo..............................................................................................................................8 3. Contagem de Pontos de Função.......................................................................................8 3.1 Determinar Propósito, Tipo, Escopo e Fronteira de Contagem .................................9 3.2 Funções de Dados e Funções Transacionais...........................................................10 3.3 Cálculo de Pontos de Função....................................................................................11 4. Itens Não Mensuráveis ...................................................................................................13 4.1 Projeto de Melhoria....................................................................................................13 4.2 Projetos de Migração de Dados................................................................................17 4.3 Manutenção Corretiva...............................................................................................17 4.4 Redesenvolvimento de Projetos em outra Plataforma..............................................19 4.5 Atualização de Plataforma.........................................................................................19 4.6 Manutenção em Interface..........................................................................................20 4.7 Adaptação de Funcionalidades a Requisitos Não Funcionais..................................20 4.8 Apuração Especial.....................................................................................................21 4.8.1 Apuração Especial – Base de Dados.....................................................................21 4.8.2 Apuração Especial – Geração de Relatórios..........................................................22 4.8.3 Apuração Especial – Reexecução..........................................................................22 4.9 Atualização de Dados................................................................................................23 4.10 Manutenção em Páginas Estáticas de Intranet, Internet ou Portal.........................23 4.11 Manutenção de Documentação de Sistemas Legados...........................................23 4.12 Verificação de Erros.................................................................................................24 4.13 Pontos de Função de Teste.....................................................................................24 4.14 Manutenção de Componentes................................................................................25 5. Estimativas de Projetos de Software...............................................................................25 5.1 Contagem Estimativa de Pontos de Função (CEPF)................................................28 5.2 Estimativa de Esforço de Projetos de Software........................................................32 5.2.1 Distribuição de Esforço por Fase do Projeto..........................................................33 5.3 Estimativa de Prazo de Projetos de Software...........................................................33 5.4 Alocação de Equipe ao Projeto.................................................................................36 5.5 Método para Estimativa de Custo.............................................................................36 5.6 Estimativa de Recursos Computacionais..................................................................37 6. Considerações para Contagem de Pontos de Função....................................................37 6.1 Considerações sobre Mudança de Requisitos..........................................................37 6.2 Considerações sobre Projetos Cancelados..............................................................38 6.3 Considerações sobre Redução de Cronograma ......................................................39 6.4 Fator de Criticidade de Solicitação de Serviço..........................................................39 7. Contagem de Pontos de Função com Múltiplas Mídias e Dados de Código..................40 7.1 Cenário 1: Mesmos dados apresentados em tela e impressos................................41 7.2 Cenário 2: Mesmos dados de saída como dados em arquivo e relatório impresso. 41 7.3 Cenário 3: Mesmos dados de entrada batch e on-line.............................................42 7.4 Cenário 4: Múltiplos canais de entrega da mesma funcionalidade...........................42 7.5 Cenário 5: Relatórios em Múltiplos Formatos...........................................................42 7.6 Dimensionamento de Dados de Código....................................................................42
Roteiro de Métricas de Software do SISP 5

..........................................45 9.................................................................31 Tabela 6: Identificação das Saídas Externas da Aplicação.1 Revisão para Correção de Inconsistências e Situações não previstas..........................................................................47 Anexo II – Formalização Simples de Requisitos – Projetos de Manutenção Pequenos (< 100 PF) ......................35 Roteiro de Métricas de Software do SISP 6 .....................................................33 Tabela 8: Expoente t por tipo de Projeto..........35 Tabela 9: Estimativa de Prazo de Projetos menores que 100 PF.45 10................................................. 2008]....................32 Tabela 7: Distribuição de Esforço por Macro Atividades do Projeto..................... de 29 novembro de 2010................................................11 Tabela 2: Identificação dos Arquivos Lógicos Internos da Aplicação........................................................................................30 Tabela 4: Identificação das Entradas Externas da Aplicação.. Conclusão....................................................................................................46 Anexo I – Portaria SLTI/MP Nº 31..................________________________________________________________________________ 8.26 Figura 3: Modelo Lógico da Análise de Pontos de Função....................2 Revisão para Adoção de Novas Versões do CPM...................34 Índice de Tabelas Tabela 1: Contribuição Funcional dos Tipos Funcionais.................29 Figura 4: Relação entre a Estimativa de Prazo e de Esforço..........................................................................45 9.................. Atividades Sem Contagem de Pontos de Função........................................53 Índice de Figuras Figura 1: Procedimento de Contagem de Pontos de Função.................................................................9 Figura 2: Processo de Estimativas de Projetos de Software [Hazan......................................................................................... Processo de Revisão do Roteiro de Contagem.......................................................30 Tabela 3: Identificação dos Arquivos de Interface Externa da Aplicação...................48 Anexo III – Modelo de Documento de Contagem de Pontos de Função – Projetos de Manutenção Pequenos (< 100 PF)........................................................43 9....................................................................31 Tabela 5: Identificação das Consultas Externas da Aplicação.................................45 Referências Bibliográficas.............................................................

Desta forma. 2010]. o capítulo 2 mostra os objetivos aos quais este documento se propõe. Os Acórdãos do Tribunal de Contas da União (TCU) recomendam a utilização da métrica Pontos de Função Não Ajustados em contratos de prestação de serviços de desenvolvimento e manutenção de sistemas. Introdução Diversas instituições. o capítulo 6 apresenta algumas considerações importantes sobre utilização de métricas para dimensionar as mudanças de requisitos e redução de cronograma. No entanto. Este documento encontra-se organizado da seguinte maneira: o capítulo 1 apresenta a motivação para a elaboração do documento e a sua organização. capítulo 5 define um processo de estimativas de projetos de software aderente às melhores práticas do CMMI nível 2. o capítulo 3 apresenta diretrizes para a Contagem de Pontos de Função de projetos de desenvolvimento e de melhoria. contemplando questões não abordadas pelo manual do IFPUG. não tendo por objetivo principal suportar contratos de fábrica de software.3) [IFPUG. mas vivenciadas pelos órgãos e entidades do SISP. torna-se importante o estabelecimento de métodos para estimar o tamanho funcional dos projetos de software nas fases iniciais do ciclo de vida. O Manual de Práticas de Contagem de Pontos de Função (CPM 4. por exemplo: Documento de Visão ou algum outro tipo de especificação elaborada pelo analista de negócios. É importante ressaltar que a Instrução Normativa IN04 SLTI/MPOG 2010 recomenda o uso de métricas em soluções de software. Além disso. o documento de requisitos para a estimativa e elaboração do plano do projeto é um documento inicial de requisitos. os quais são itens não mensuráveis pelo manual de prática de contagem do IFPUG. É importante ressaltar que a métrica de Pontos de Função foi concebida como uma medida de tamanho funcional para projetos de desenvolvimento e de melhoria (manutenção evolutiva) de software. define as regras de contagem de Pontos de Função. os projetos de software não estão limitados a projetos de desenvolvimento e de melhoria. torna-se essencial a definição de métricas para dimensionar o tamanho de outros tipos de projetos de manutenção. assim como métricas baseadas em Pontos de Função para o dimensionamento desses itens não mensuráveis. torna-se necessário criar roteiros complementares. publicado pelo International Function Point Users Group (IFPUG). restringindo o uso da métrica de esforço homem-hora. Outro ponto a ser destacado é a importância da definição de métodos para geração de estimativas de prazo e custo dos projetos de software a partir do tamanho estimado do projeto. É importante frisar que o Manual de Práticas de Contagem (CPM) é um documento que se destina a mensurar o tamanho funcional de projetos de software. a contagem de Pontos de Função é baseada no projeto lógico da aplicação (logical design) e nas fases iniciais do ciclo de vida do software.________________________________________________________________________ 1. têm utilizado a métrica de Pontos de Função (PF) nas estimativas e dimensionamento de tamanho funcional de projetos de software devido aos diversos benefícios de utilização da métrica. destacando: regras de contagem objetivas e independência da solução tecnológica utilizada. o capítulo 4 define os tipos de projetos de manutenção de software não mensuráveis pelo Manual de Práticas de Contagem (CPM). Assim. públicas e privadas. Assim. o capítulo 7 estabelece diretrizes para contagem de Múltiplas Mídias e de Dados de Código Roteiro de Métricas de Software do SISP 7 .

Também foram consultados outros roteiros de órgãos que já utilizam a métrica Pontos de Função em contratos de software. A Análise de Pontos de Função (APF) é um método padrão para a medição de projetos de desenvolvimento e de manutenção de sistemas. Objetivo Este documento tem como objetivo principal apresentar um roteiro de métricas. apresentando sugestões para trabalhos futuros. Além da contagem de Pontos de Função. A implantação de um processo de medições de software e a mudança do modelo de contratação de software com base na métrica homem-hora para o novo paradigma de contratação com base na métrica Pontos de Função requer uma mudança cultural.________________________________________________________________________ (Code Data). A proposta inicial do Roteiro foi submetida ao Grupo de Trabalho de Métricas do SISP. para todos tipos de projetos de desenvolvimento e de manutenção de sistemas.3). aderente ao modelo CMMI. o qual contribuiu com sugestões de melhoria. sob o ponto de vista do usuário. com base nas regras de contagem de Pontos de Função do Manual de Práticas de Contagem (CPM 4. custo.0 do Roteiro. o capítulo 10 conclui o documento. Ou seja. considerando a visão do usuário. visando apoiar as organizações nas estimativas de tamanho. Contagem de Pontos de Função A métrica PF mede o tamanho funcional de um projeto de software. 2003]. Roteiro de Métricas de Software do SISP 8 . Em seguida. as propostas foram analisadas em reunião com especialistas em métricas de órgãos e entidades do SISP para a elaboração da versão 1. este roteiro apresenta um processo de estimativas com base na métrica Pontos de Função. 2. • 3. Consistência: Este Roteiro deve definir critérios objetivos visando prover a consistência no uso de métricas em contratos de fábrica de software. O documento foi construído baseando-se no “Roteiro SERPRO de Métricas para Contratos de Software”. duas premissas foram consideradas na elaboração desse Roteiro: • Simplicidade: Este Roteiro deve ser simples para incentivar os órgãos e entidades do SISP a utilizar a métrica Pontos de Função como medida padrão no estabelecimento de contratos de fábrica de software. Este Roteiro tem como propósito apoiar os órgãos e entidades do SISP nessa mudança cultural. com base na quantificação da funcionalidade solicitada e entregue. o capítulo 8 apresenta algumas atividades que não devem ser consideradas nas Contagens de Pontos de Função. Tamanho funcional é definido como “tamanho do software derivado pela quantificação dos requisitos funcionais do usuário” [Dekkers. O propósito é promover o uso de métricas objetivas em contratos de prestação de serviços de desenvolvimento e manutenção de sistemas. dois profissionais ao aplicar o Roteiro no dimensionamento de um projeto de software devem obter o mesmo resultado. Desta forma. prazo e esforço de seus projetos desenvolvidos internamente ou contratados. observando as funcionalidades implementadas. o capítulo 9 apresenta o processo de revisão deste guia de contagem. visando estabelecer uma medida de tamanho do software em Pontos de Função. finalmente.

Escopo e Fronteira de Contagem A Contagem de Pontos de Função se inicia com a análise da documentação disponível do projeto em questão. deve ser definida com base na visão do usuário. e o tipo de contagem. que pode ser projeto de desenvolvimento. Obter a documentação disponível do projeto Identifique os Identificar o Propósito da Contagem Identificar o Tipo de Contagem Determinar o Escopo da Contagem Determinar a Fronteira da Aplicação requisitos funcionais Contar Funções de Dados Calcular Tamanho Funcional Contar Funções Transacionais Documentar e Reportar a Contagem Figura 1: Procedimento de Contagem de Pontos de Função 3. desconsiderando questões de implementação. que é a interface conceitual que delimita o sistema sendo medido e os usuários e as outras aplicações. o qual fornece uma resposta para uma questão de negócio a ser resolvida. Tipo. descrito nas seções seguintes. Os Roteiros de Contagem dos órgãos e entidades também devem definir as fronteiras das aplicações implantadas em um anexo e este deve ser atualizado sempre que for implantada uma Roteiro de Métricas de Software do SISP 9 . que identifica quais funcionalidades serão incluídas na contagem de Pontos de Função. A fronteira da aplicação. Projetos de Melhoria e Aplicações Implantadas. apresenta as regras de contagem de Pontos de Função de Projetos de Desenvolvimento.________________________________________________________________________ Assim. visando a identificação dos requisitos funcionais. 2010].1 Determinar Propósito. por exemplo: necessidade de dimensionar um projeto de um novo sistema para a contratação do mesmo. O Manual de Práticas de Contagem (CPM) [IFPUG. a APF tem como objetivo medir o que o software faz. projeto de melhoria ou aplicação instalada. por meio de uma avaliação padronizada dos requisitos de negócio do sistema. Com base no propósito da contagem são definidos o escopo da contagem. Em editais para contratação de projetos de manutenção é fortemente recomendado a definição das fronteiras de todas as aplicações a serem contratadas. O próximo passo é o estabelecimento do propósito da contagem. A Figura 1 ilustra o procedimento de contagem de Pontos de Função.

mantido por meio de um processo elementar da aplicação que está sendo contada. logicamente relacionados. A Tabela 1 apresenta a contribuição dos tipos funcionais na contagem de Pontos de Função. Roteiro de Métricas de Software do SISP 10 . mantido por meio de um processo elementar de uma outra aplicação e referenciado pela aplicação que está sendo contada. Média. reconhecido pelo usuário. • Saída Externa (SE): é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação. • Consulta Externa (CE): é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação. observando as regras de contagem de Pontos de Função descritas no CPM. a saber: • Arquivo Lógico Interno (ALI): é um grupo de dados. logicamente relacionados. • Arquivo de Interface Externa (AIE): é um grupo de dados. o próximo passo é o mapeamento dos requisitos de dados e de funções transacionais para os tipos funcionais da APF. reconhecido pelo usuário. Seu objetivo principal é apresentar informação para um usuário ou outra aplicação através de um processamento lógico adicional à recuperação de dados ou informação de controle. Após a identificação do tipo funcional. deve-se avaliar a complexidade (Baixa. ou manter ALI ou alterar o comportamento do sistema. 3. ou criar dados derivados.________________________________________________________________________ nova aplicação. Seu objetivo principal é apresentar informação para o usuário através da recuperação de dados ou informação de controle de ALI ou AIE.2 Funções de Dados e Funções Transacionais Uma vez estabelecida a fronteira da contagem. O processamento lógico deve conter cálculo. • Entrada Externa (EE): é um processo elementar que processa dados ou informação de controle que entram pela fronteira da aplicação. O AIE é obrigatoriamente um ALI de outra aplicação. Alta) e a contribuição funcional do mesmo para a contagem de Pontos de Função. Seu objetivo principal é manter um ou mais ALI ou alterar o comportamento do sistema.

3 Cálculo de Pontos de Função Caso o tipo de contagem seja projeto de desenvolvimento. Exemplos de funções de conversão incluem: migração ou carga inicial de dados para popular as novas tabelas criadas e relatórios associados à migração de dados.________________________________________________________________________ Complexidade Tipo Funcional Arquivo Lógico Interno (ALI) Arquivo de Interface Externa (AIE) Entrada Externa (EE) Saída Externa (SE) Consulta Externa (CE) Baixa 7 PF 5 PF 3 PF 4 PF 3 PF Média Alta 10 PF 15 PF 7 PF 4 PF 5 PF 4 PF 10 PF 6 PF 7 PF 6 PF Tabela 1: Contribuição Funcional dos Tipos Funcionais 3. o cálculo do tamanho funcional é definido no CPM conforme a fórmula abaixo: PF_Melhoria = (PF_INCLUIDO + PF_EXCLUIDO + PF_ALTERADO + PF_CONVERSÃO) PF_INCLUÍDO = Pontos de Função associados às novas funcionalidades que farão parte da aplicação. PF_ALTERADO = Pontos de Função associados às funcionalidades existentes na aplicação que serão alteradas no projeto de manutenção. PF_CONVERSÃO = Pontos de Função associados às funcionalidades de conversão de dados. o cálculo do tamanho funcional é definido no CPM conforme a fórmula abaixo: PF_Desenvolvimento = PF_INCLUIDO + PF_CONVERSÃO PF_INCLUÍDO = Pontos de Função associados às funcionalidades que farão parte da aplicação. PF_EXCLUÍDO = Pontos de Função associados às funcionalidades existentes na aplicação que serão excluídas no projeto de manutenção. Exemplos de funções de conversão incluem: migração ou carga inicial de dados para popular as novas tabelas criadas e relatórios associados à Roteiro de Métricas de Software do SISP 11 . Caso o tipo de contagem seja projeto de melhoria. PF_CONVERSÃO = Pontos de Função associados às funcionalidades de conversão de dados dos projetos de melhoria.

Dados são filtrados e selecionados através da utilização de critérios. Consulta Externa e Saída Externa) é considerada alterada. Observação1: Função Alterada Uma função de dados (Arquivo Lógico Interno ou Arquivo de Interface Externa) é considerada alterada quando houver inclusão ou exclusão de tipo de dados. Dados derivados são criados através da transformação de dados existentes. Dados ou informações de controle são recuperados. Dados são reordenados. Mudança de lógica de processamento. Um ou mais ALIs e AIEs são referenciados. O CPM 4.________________________________________________________________________ migração de dados. mudança de Tipos de Dados e mudança de arquivos Roteiro de Métricas de Software do SISP 12 . Por exemplo. Também é considerada alterada se algum tipo de dado sofrer mudança de tamanho (número de posições) ou tipo de campo (por exemplo: mudança de numérico ou alfanumérico). Fórmulas matemáticas e cálculos são executados. PF_ALTERADO em um Projeto de Melhoria. Preparar e apresentar informações para fora da fronteira. Devido a mudanças no processo de negócio. Condições são analisadas para verificar quais são aplicáveis. o Roteiro considera esta função como uma Entrada Externa alterada. Desta forma. Mudança de arquivos referenciados. uma funcionalidade de cadastro implicava na inclusão de um telefone do gerente. Esses requisitos devem incluir as seguintes ações: • • • • • • • • • • • • • Validações são executadas. para criar dados adicionais. mesmo que não exista mudança de lógica. Observação 2: Outros Tipos de Funções Alteradas Este Roteiro considera função alterada. Um ou mais ALIs são atualizados. Receber dados ou informações de controle que entram pela fronteira da aplicação. Valores equivalentes são convertidos. qualquer mudança em funcionalidades da aplicação devido às mudanças de Regras de Negócio. quando a alteração contemplar: • • • Mudança de tipos de dados. caso a mudança decorra de alteração de regra de negócio. Uma função transacional (Entrada Externa.3 define lógica de processamento como requisitos especificamente solicitados pelo usuário para completar um processo elementar. O comportamento do sistema é alterado. a funcionalidade deve sofrer uma manutenção adaptativa para cadastrar dois telefones do gerente.

quando as mudanças são associadas aos requisitos funcionais e a manutenção adaptativa quando as mudanças Roteiro de Métricas de Software do SISP 13 . 4. apenas o de Melhoria. que será dimensionado como um novo projeto de desenvolvimento. conforme a seção 4. 4. ou seja. respectivamente.1 Projeto de Melhoria O Projeto de Melhoria (enhancement). visando apoiar a contagem de Pontos de Função da demanda. exigindo habilidades diferentes e geralmente resultando em equipes distintas para esses dois tipos de tarefas. de forma detalhada. É importante também documentar as estimativas e a contagem de Pontos de Função. também denominado de projeto de melhoria funcional ou manutenção evolutiva. Itens Não Mensuráveis O Manual de Práticas de Contagem (CPM) não contempla todos os tipos de projetos de manutenção. Serão tratadas como manutenções adaptativas apenas as manutenções que implicarem exclusivamente em mudanças em requisitos não funcionais.________________________________________________________________________ referenciados. 1998].2 deste documento. O projeto de melhoria é considerado um tipo de projeto de manutenção adaptativa com mudanças em requisitos funcionais da aplicação. Observação 3: Migração de Dados – PF_CONVERSÃO As características do esforço de desenvolvimento ou de melhoria de um sistema são bastante diferentes daquelas do esforço de migração de dados. Este documento separa o projeto de melhoria. esta manutenção seria um tipo de manutenção adaptativa. está associado às mudanças em requisitos funcionais da aplicação. um modelo de Documento de Requisitos e um modelo de Documento de Contagem de Pontos de Função para projetos de manutenção de pequeno porte (menores que 100 PF). alteração ou exclusão de funcionalidades em aplicações implantadas. este Roteiro recomenda suprimir o PF_CONVERSÃO das fórmulas de desenvolvimento e de melhoria e considerar estas funcionalidades como um projeto de migração de dados. Se uma mesma funcionalidade tiver mudanças em requisitos funcionais e não funcionais. O Anexo II e Anexo III apresentam. Segundo o padrão IEEE Std 1219 [IEEE. Devido a isso. à inclusão de novas funcionalidades. Este capítulo tem como propósito descrever os diversos projetos de manutenção e definir métricas baseadas nas regras de contagem de Pontos de Função do CPM para seu dimensionamento. Quanto à documentação de projetos de manutenção pequenos (menores que 100 PF). ou seja. esta deve ser contada apenas uma vez.3. como função alterada em um Projeto de Melhoria. com funcionalidades incluídas. segundo o CPM 4. ou seja os demais tipos de projetos de manutenção de software. deve-se registrar a solicitação e documentar os requisitos do projeto de manutenção e da aplicação impactada pela demanda. Dessa forma. O capítulo seguinte define métricas para tratar os itens não mensuráveis pelo CPM. é fortemente recomendado que os projetos de migração de dados sejam tratados como objetos separados dos projetos de desenvolvimento e de melhoria e tenham precificação própria. definida como: modificação de um produto de software concluído após a entrega para mantê-lo funcionando adequadamente em um ambiente com mudanças. alteradas ou excluídas na aplicação.

segue as fórmulas estabelecidas abaixo [NESMA. PF_ALTERADO = Pontos de Função associados às funcionalidades existentes na aplicação que serão alteradas no projeto de manutenção. PF_EXCLUÍDO = Pontos de Função associados às funcionalidades existentes na aplicação que serão excluídas no projeto de manutenção. podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. Os órgãos e entidades que já possuem base histórica de projetos concluídos com Contagem Detalhada de Pontos de Função e um processo de desenvolvimento implantado com documentação das aplicações a serem mantidas. gerando a documentação completa da mesma.40 x PF_EXCLUIDO) + (FI x PF_ALTERADO) Definições: PF_INCLUÍDO = Pontos de Função associados às novas funcionalidades que farão parte da aplicação. 2009]: Roteiro de Métricas de Software do SISP 14 . se houver uma nova demanda de projeto de melhoria na funcionalidade em questão. PF = PF_INCLUIDO + (0. Para o cálculo dos Pontos de Função Incluídos. Observe que o percentual de 100% apenas será considerado na primeira demanda de projeto de melhoria em cada funcionalidade. demandas de exclusão de funcionalidades (grupos de dados ou processos elementares) e demandas de alteração de funcionalidades (grupos de dados ou processos elementares) em aplicações implantadas em produção. 2009]. Os percentuais de multiplicação propostos são estimados. aderente ao processo de software da contratante. Alterados e Excluídos. FI = Fator de Impacto pode variar de 50% a 100% de acordo com o seguinte: • • • Funcionalidade de sistema desenvolvida ou mantida por meio de um projeto de melhoria pela empresa contratada : FI = 50% Funcionalidade de sistema não desenvolvida ou mantida por meio de um projeto de melhoria pela empresa contratada com documentação atualizada: FI = 75% Funcionalidade de sistema não desenvolvida ou mantida por meio de um projeto de melhoria pela empresa contratada sem documentação atualizada: FI =100%. A contratada deve redocumentar a funcionalidade mantida. Um projeto de melhoria consiste em demandas de criação de novas funcionalidades (grupos de dados ou processos elementares).________________________________________________________________________ estão associadas aos requisitos não funcionais da aplicação. podem utilizar o método de Contagem de Pontos de Função de Projetos de Melhoria publicado pela NESMA – Netherlands Software Metrics Users Association no documento "Function Point Analysis for Software Enhancement Guidelines" [NESMA. Segue a Fórmula de Contagem de Pontos de Função de Projetos de Melhoria. Tendo em vista que o FI equivale à inclusão de funcionalidade. será considerado que a contratada desenvolveu a funcionalidade.

PF_FT_ALTERADO = FT-QPA x FFT.25 e 1. PF_ALTERADO = PF_FD_ALTERADO + PF_FT_ALTERADO. Onde: QPI = Quantidade de Pontos de Função incluídos.5 Entre 66% e 100% 0. conforme tabela abaixo (para funções transacionais).50.________________________________________________________________________ PF_INCLUIDO = QPI. PF_EXCLUIDO = QPE x 0. FT-QPA = Quantidade de Pontos de Função alterados em funções transacionais. O cálculo dos fatores de impacto são obtidos através dos percentuais de alterações conforme abaixo: a) Funções de Dados: Percentual de alterações em funções de dados: PFD = QTDA / QTDT x 100. sendo FFD entre 0. PF_FT_ALTERADO = Pontos de Função alterados para Funções Transacionais. FFT = Fator de impacto de alterações em funções transacionais.75 Maior que 100% 1 Roteiro de Métricas de Software do SISP 15 . QTDA = Quantidade de Tipos de Dados Alterados. Com o valor obtido em PFD. sendo FFT entre 0. QPE = Quantidade de Pontos de Função excluídos.25 Entre 33% e 66% 0. PF_FD_ALTERADO = FD-QPA x FFD. PF_FD_ALTERADO = Pontos de Função alterados para Funções de Dados. conforme tabela abaixo (para funções de dados).00. procura-se na tabela qual o valor do fator de impacto: Fator de Impacto em Funções de Dados Alteradas (FFD) PFD Fator de Impacto (FFD) Entre 0 e 33% 0. FD-QPA = Quantidade de Pontos de Função alterados em funções de dados.40. QTDT = Quantidade de Tipos de Dados Totais na Função Original.25 e 1. FFD = Fator de impacto de alterações em funções de dados.

25 Maior que 100% 0. QARA = Quantidade de Arquivos Referenciados Alterados.5 Caso FFT seja maior que 1. a contagem de PF da função de dados seria a seguinte: Aplicação Implantada : AIE: Taxa – RL:1 TD:2 . Então. Então.5 PF Manutenção: inclusão do TD – Sigla PFD = QTDA / QTDT x 100 PFD = (1 / 2) X 100 = 50% FFD = 0. por exemplo uma Sigla.________________________________________________________________________ b) Funções Transacionais: Percentual alterações em funções transacionais (PFT1) = QTDA / QTDT x 100. taxa). a contagem de PF da função de dados seria a seguinte: Aplicação Implantada : AIE: Taxa – RL:1 TD:47 . considerando o método NESMA.5 PF_ALTERADO = 5 x 0.25 0. recomenda-se reconsiderar a melhoria.75 1 1.75 1 Entre 66% e 100% 0.5 PF Roteiro de Métricas de Software do SISP 16 . o usuário solicita a leitura de um novo Tipo de Dados. Na manutenção. considerando o método NESMA. QTDT = Quantidade de Tipos de Dados Totais na Função Original. por exemplo uma Sigla.25 1. Exemplo 1: Suponha uma aplicação com leitura de um Arquivo de Interface Externa com leitura de 2 Tipos de Dados (nome.5 0. o usuário solicita a leitura de um novo Tipo de Dados. Fator de Impacto em Funções Transacionais Alteradas (FFT) PFT2 / PFT1 Entre 0% e 33% Entre 33% e 66% Entre 66% e 100% Maior que 100% Entre 0% e 66% 0. Observação Importante Embora este método seja utilizado por algumas organizações.5 0. Percentual alterações em funções transacionais (PFT2) = QFTRA / QFTRT x 100. QTDA = Quantidade de Tipos de Dados Alterados.75 1 1. QART = Quantidade de Arquivos Referenciados Totais na Função Original. é importante ressaltar que em algumas simulações realizadas com base no método da NESMA os resultados ficaram inconsistentes.5 = 2. Na manutenção.5 PF Exemplo 2: Suponha uma aplicação com leitura de um Arquivo de Interface Externa com leitura de 47 Tipos de Dados.

suas dificuldades de operacionalização e o fato de que na prática é observado que o esforço para alteração de uma funcionalidade depende do conhecimento da equipe sobre a aplicação implantada e da qualidade da sua documentação e do seu código.3 Manutenção Corretiva Mesmo com a execução de atividades de garantia da qualidade. o grau de criticidade do projeto poderá trazer impacto nas estimativas de custo e esforço. a operacionalização da contagem de Pontos de Função de projetos de melhoria por esse método pode ser bastante trabalhosa.________________________________________________________________________ Manutenção: inclusão do TD – Sigla PFD = QTDA / QTDT x 100 PFD = (1 / 47) X 100 = 2.25 PFs) da contagem de PF do exemplo 1 (2.25 PF Observe que o esforço para a alteração foi o mesmo ou superior na Aplicação do exemplo 2. Entradas Externas – considerando as cargas de dados nos ALIs e caso seja solicitado pelo usuário relatórios gerenciais das cargas.1 % FFD = 0. este Roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de Pontos de Função de Projetos de Desenvolvimento e de Melhoria e o tratamento das funções de migração de dados como projetos separados de migração de dados. pode-se identificar defeitos na aplicação entregue. Assim.1998] define um tipo de manutenção corretiva. Os projetos de migração de dados devem ser contados como um novo projeto de desenvolvimento de um sistema. a contagem de PF do exemplo 2 é a metade (1. as demandas de correção de erros (bugs) em funcionalidades em sistemas em produção. nos casos de ausência de documentação atualizada da Contagem Detalhada de Pontos de Função da aplicação implantada. este Roteiro não recomenda o uso do método sem base histórica de projetos e documentação atualizada e propõe o uso dos mesmos fatores de impacto levando em conta a familiaridade com o código e a qualidade da documentação. denominado de Manutenção Emergencial como “manutenção corretiva não programada executada para manter o sistema em estado operacional”. É importante destacar que as demandas de manutenção corretiva frequentemente precisam ser atendidas com urgência.25 = 1. 4. pelo método da NESMA. Além disso. Roteiro de Métricas de Software do SISP 17 .5 PFs). O padrão IEEE [IEEE. A manutenção corretiva altera o software para correção de defeitos.25 PF_ALTERADO = 5 x 0. considerando a inconsistência do método.2 Projetos de Migração de Dados Conforme mencionado. contemplando minimamente: os ALIs mantidos pela migração. Encontra-se nesta categoria. Todas as contagens de PF devem ser realizadas com base nas funcionalidades requisitadas e recebidas pelo usuário. No entanto. 4. Assim. estes serão contados como Saídas Externas.

Deve-se destacar que além da correção das funcionalidades em questão e da documentação do projeto de manutenção corretiva realizado. PF = PF_ALTERADO x 0.70 c) Aplicação sem documentação ou com documentação desatualizada ou incompleta ou completa e com redocumentação de requisitos Nestes casos. PF = PF_ALTERADO x 0. os percentuais de multiplicação são estimados. a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades corrigidas considera 60% do PF_ALTERADO. seguindo os conceitos do CPM 4. mostrados na seção 4. preconizada por lei (Código do Consumidor). a documentação das funcionalidades deve ser atualizada pela contratada. apenas dos artefatos associados à correção do código. apresentados na seção 4. seguindo os conceitos do CPM 4. observando os conceitos do CPM 4.80 Em todos os três itens acima.1. a manutenção corretiva será do tipo Garantia.60 b) Aplicação sem documentação ou com documentação desatualizada ou documentação incompleta e sem redocumentação de requisitos Nestes casos. apresentados na seção 4. conforme prazos e demais cláusulas do contrato em questão.3. Caso não exista cláusula contratual de Garantia. podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no Roteiro de Métricas de Software do SISP 18 . A estimativa e dimensionamento de tamanho de projetos de manutenção corretiva em Pontos de Função devem levar em consideração a documentação do sistema disponível e os artefatos a serem mantidos. deverá ser estimado e calculado o tamanho do projeto de manutenção corretiva.1. Quando o sistema não tiver sido desenvolvido pela contratada.1.3. PF = PF_ALTERADO x 0.3. a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades corrigidas considera 80% do PF_ALTERADO.________________________________________________________________________ Quando o sistema em produção tiver sido desenvolvido pela contratada. a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades corrigidas considera 70% do PF_ALTERADO. Seguem as fórmulas a serem consideradas: a) Aplicação com documentação completa Nestes casos. deve ser considerada a garantia de seis meses. Deve-se ressaltar que não há necessidade de correção da documentação do sistema.

5 Atualização de Plataforma São consideradas nesta categoria. 4.2. recomenda-se tratar como um projeto separado de migração de dados. Mozila. descrito na seção 4. Por exemplo. a aferição do tamanho em Pontos de Função da aplicação ou da parte da aplicação que sofreu impacto considera 40% dos PF. conforme a seção 4. então serão considerados como novos projetos de desenvolvimento. projetos que precisam ser migrados para outra plataforma.) ou de linguagens de programação (ex: versão mais atual do JAVA ou do Banco de Dados).40 Roteiro de Métricas de Software do SISP 19 . demandas para uma aplicação existente ou parte de uma aplicação existente executar em versões mais atuais de browsers (ex: versão atual do Internet Explorer.4 Redesenvolvimento de Projetos em outra Plataforma São considerados nesta categoria.2. seguindo a fórmula de desenvolvimento do CPM 4. Nesta categoria foram observadas demandas dos seguintes tipos: a) Atualização de Plataforma com necessidade de redocumentação de requisitos Nestes casos. a documentação das funcionalidades deve ser atualizada.3. Também são consideradas nesta categoria aplicações Web desenvolvidas para executar em Internet Explorer que precisam executar também em browser em software livre. PF = PF_NÃO_AJUSTADO x 0... Caso existam funções de conversão de dados.2.3. seguindo a fórmula de projetos de desenvolvimento do CPM 4.________________________________________________________________________ órgão ou entidade. com a supressão do PF_CONVERSÃO. PF = PF_NÃO_AJUSTADO 4.3. Firefox. recomendase tratar como um projeto separado de migração de dados. será utilizada a fórmula de Projetos de Desenvolvimento do CPM 4. frequentemente.50 b) Atualização de Plataforma sem necessidade de redocumentação de requisitos Nestes casos. Assim.. Como estes projetos legados. considerando que as Migrações de Dados serão tratadas como um projeto a parte. a aferição do tamanho em Pontos de Função da aplicação ou da parte da aplicação que sofreu impacto considera 50% dos PF. Caso existam funções de conversão de dados. descrito na seção 4. um sistema legado em COBOL precisa ser redesenvolvido em JAVA. Deve-se destacar que além da adequação às funcionalidades em questão e da documentação do projeto de manutenção adaptativa realizado. PF = PF_NÃO_AJUSTADO x 0. encontram-se sem documentação.

por exemplo. Nestes casos.________________________________________________________________________ Nos dois itens acima. a aferição do tamanho em Pontos de Função das funcionalidades alteradas será realizada com a aplicação de um fator de modo a considerar 10% da contagem de uma função transacional de baixa complexidade (3 PF). a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades que sofreram impacto deve considerar 70% do PF_ALTERADO.1. PF = PF_ALTERADO_FUNÇÃO_TRANSACIONAL_COMPLEXIDADE_BAIXA x 0.3. 4. Caso seja utilizada uma mesma tela para duas ou mais funcionalidades.6 Manutenção em Interface A manutenção em Interface. aviso. alerta ou conclusão de processamento.10 O percentual de multiplicação é estimado. seguindo os conceitos do CPM 4. deve ser contada APENAS UMA função transacional de baixa complexidade.7 Adaptação de Funcionalidades a Requisitos Não Funcionais São consideradas nesta categoria as demandas de manutenção adaptativa associadas a solicitações que envolvem aspectos não funcionais. logotipos. alteração na aplicação para adaptação às alterações realizadas na interface com rotinas de integração com outros softwares (ex: alteração em sub-rotinas chamadas por este software). é associada às demandas de alterações de interface. independentemente da complexidade da funcionalidade alterada. sem alteração em requisitos funcionais. replicação de base de dados ou criação de base temporária para resolver problemas de performance ou segurança. denominada na literatura manutenção cosmética. os percentuais de multiplicação são estimados. Também se enquadram nessa categoria as mudanças de texto em mensagens de erro. mudança de botões na tela. Roteiro de Métricas de Software do SISP 20 . Não será contemplada a documentação das funcionalidades nas demandas desta categoria. podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. Não será contemplada a redocumentação das funcionalidades da aplicação impactadas pela manutenção nas demandas desta categoria. cores de telas. podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. apresentados na seção 4. 4. Nesta categoria foram observadas demandas dos seguintes tipos: a) Adaptação de funcionalidades sem necessidade de redocumentação Nestes casos. mudança de posição de campos ou texto na tela. Por exemplo: replicação de funcionalidade (chamar uma consulta existente em outra tela da aplicação). fonte de letra. validação.

Deve-se destacar que além da adequação das funcionalidades em questão e da documentação do projeto de manutenção adaptativa realizado.8.8. a documentação das funcionalidades deve ser atualizada. gerar um relatório específico ou arquivo para o usuário por meio de recuperação de informações nas bases da aplicação.8 Apuração Especial São funcionalidades executadas apenas uma vez para: corrigir problemas de dados incorretos na base de dados das aplicações ou atualizar dados em bases de dados de aplicações. detalhado no item 4.2. seguindo os conceitos do CPM 4. Geralmente. PF = PF_NÃO_AJUSTADO Roteiro de Métricas de Software do SISP 21 .8. É importante ressaltar que as funções de dados associadas aos dados atualizados não devem ser contadas.1. considera-se a contagem de Pontos de Função das funcionalidades desenvolvidas. Caso a apuração seja de correção de dados. visando a correção de dados incorretos na base de dados da aplicação ou atualização em função de modificação da estrutura de dados. devido a erros de funcionalidades de aplicações desenvolvidas pela contratada. os percentuais de multiplicação são estimados. considerando que não há mudanças nas estruturas dos Arquivos Lógicos. podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão ou entidade.3 considera os casos de reexecução de uma apuração especial.________________________________________________________________________ PF = PF_ALTERADO x 0. por exemplo inclusão do indicador de matriz – sim ou não para um CNPJ.80 Nos dois itens acima.8.70 b) Adaptação de funcionalidades com necessidade de redocumentação Nestes casos.1 Apuração Especial – Base de Dados Uma apuração especial é um projeto que inclui a geração de procedimentos para atualização da base de dados. estas funcionalidades são classificadas como Entradas Externas. a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades que sofreram impacto deve considerar 80% do PF_ALTERADO. Deve-se destacar que estas funções são executadas apenas uma vez. não fazendo parte da aplicação. A seção 4.1.3. 4. observar as cláusulas contratuais com relação a garantias e prazos de correção. PF = PF_ALTERADO x 0. detalhado no item 4. apresentados na seção 4. Nestes casos. 4.

estas funcionalidades são classificadas como Saídas Externas. considerando que não há mudanças nas estruturas dos Arquivos Lógicos. É importante ressaltar que as funções de dados associadas aos dados atualizados não devem ser contadas. é uma prática interessante para evitar informações errôneas na base de produção dos sistemas. Em alguns casos. conforme a fórmula abaixo: PF = PF_NÃO_AJUSTADO x 0. PF = PF_NÃO_AJUSTADO 4. Deve-se destacar que estas funções são executadas apenas uma vez. o usuário solicita uma consulta prévia das informações atualizadas para validação.10 O percentual de multiplicação proposto no item acima é estimado. caso não possuam cálculos ou criação de dados derivados. considerando-se 60% do tamanho da funcionalidade em questão. da seguinte maneira: PF = PF_NÃO_AJUSTADO x 0.2 Apuração Especial – Geração de Relatórios Uma apuração especial é um projeto que inclui a geração de relatórios em uma ou mais mídias para o usuário.________________________________________________________________________ Em alguns casos de Apuração Especial – Atualização de dados.3 Apuração Especial – Reexecução Em alguns casos a empresa contratante pode ter interesse em executar uma apuração especial mais de uma vez. não fazendo parte da aplicação. então estas funções são Saídas Externas. ela deve solicitar formalmente à contratada o armazenamento do script executado.8. Frequentemente. podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. Desta forma. De fato. Roteiro de Métricas de Software do SISP 22 . se for solicitada a reexecução de uma apuração especial. Caso neste envio de dados sejam requisitadas atualizações no sistema de origem. devido à atualização do Arquivo Lógico Interno. Esta Consulta Prévia. classificada como Consulta Externa ou Saída Externa deve ser dimensionada.8. Também podem ser classificadas como Consultas Externas.60 4. Nestes casos. Nestes casos. são solicitadas extrações de dados e envio dos dados para outros sistemas. esta deve ser dimensionada com aplicação de um fator considerando 10% na contagem de Pontos de Função da apuração especial em questão. considera-se contagem de Pontos de Função das funcionalidades desenvolvidas.

de modo a minimizar as demandas de criação de páginas estáticas. Tais demandas não se referem a contratos de Fábrica de Software. os Tipos de Dados da Entrada Externa são os campos atualizados. PF = PF_NÃO_AJUSTADO x 0. atualização de menu. Por exemplo: alteração de página de estilo.11 Manutenção de Documentação de Sistemas Legados Nesta seção são tratadas demandas de documentação ou atualização de documentação de sistemas legados. atualização de texto ou banner em páginas html existentes.________________________________________________________________________ 4. 4. associadas à área de Comunicação Social não são enquadradas nessa categoria. Intranets ou Websites. Internet ou Portal Nesta seção são tratadas manutenções específicas em páginas estáticas de Portais. Observe que o desenvolvedor deve realizar uma Engenharia Reversa da aplicação para gerar a documentação. portanto não são consideradas neste Roteiro. As consultas são consideradas Consultas Externas Simples (3 PF). caso a demanda seja apenas a documentação de requisitos. podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade.10 Manutenção em Páginas Estáticas de Intranet. Nestes casos. podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. Zope/Plone. Cada página é contada como uma consulta. PF = PF_NÃO_AJUSTADO x 0. por exemplo: Joomla. criação de página html. as demandas de correção de problemas em base de dados estão associadas a atualizações em um único registro. É recomendado a construção de Portais com ferramentas que apoiem a construção de conteúdo pelo usuário.9 Atualização de Dados Em alguns casos. O percentual de multiplicação proposto acima é estimado. atualização do nome de um Fornecedor cadastrado erradamente. Para este tipo de projeto. Estas demandas são consideradas como desenvolvimento de consultas.10 O percentual de multiplicação é estimado. a aferição do tamanho em Pontos de Função deve considerar 10% do PF_ALTERADO de uma Entrada Externa. 4. Nestes casos. A demanda consiste na publicação de páginas HTML com conteúdo estático. considera-se 50% dos Pontos de Função das consultas desenvolvidas.50 As demandas de criação de Logomarcas ou identidade visual ou outras demandas de criação de Arte. Por exemplo. devem ser considerados Roteiro de Métricas de Software do SISP 23 .

uma vez não constatado o problema apontado pelo cliente ou o mesmo for decorrente de regras de negócio implementadas ou utilização incorreta das funcionalidades. isto é. O percentual de multiplicação proposto acima é estimado. Neste caso. a demanda será atendida como manutenção corretiva. Esses serviços de suporte não fazem parte do escopo desse Roteiro de métricas. Os casos de sistema fora do ar por conta de problemas em rede ou banco de dados devem ser tratados como serviços de suporte e não de Fábrica de Software. PF = PF_NÃO_AJUSTADO x 0. em projetos de manutenção o conjunto de funções de dados e funções transacionais a serem testadas é maior do que a quantidade de funções a serem implementadas. deve-se considerar um percentual mais alto de 30% a 50%.25 É importante ressaltar que a demanda de verificação de erros deve ser associada a uma funcionalidade específica. As premissas utilizadas devem ser conforme cláusulas contratuais e documentadas no documento de estimativas do projeto. Roteiro de Métricas de Software do SISP 24 . Entretanto.13 Pontos de Função de Teste Muitas vezes.________________________________________________________________________ 20% dos Pontos de Função da aplicação em questão. conforme a fórmula abaixo. 4.12 Verificação de Erros São consideradas verificações de erro ou análise e solução de problemas as demandas referentes a todo comportamento anormal ou indevido apontado pelo cliente nos sistemas aplicativos. Se for constatado erro de sistema. podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. outras precisam ser testadas [NESMA.20 Caso a demanda seja a geração de artefatos de documentação de todas as fases do processo de desenvolvimento. alteradas ou excluídas do projeto de manutenção na contagem de Pontos de Função de Teste. 2009]. podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. será realizada a aferição do tamanho em Pontos de Função das funcionalidades verificadas. Não considerar as funcionalidades incluídas. segundo a fórmula abaixo: PF = PF_NÃO_AJUSTADO x 0. além das funcionalidades que são afetadas diretamente pelo projeto de manutenção. O tamanho das funções a serem testadas deve ser aferido em Pontos de Função de Teste (PFT). a equipe de desenvolvimento da contratada se mobilizará para encontrar as causas do problema ocorrido. 4. dependendo dos artefatos a serem gerados. O percentual de multiplicação proposto acima é estimado. e será considerado 25% do tamanho funcional das funcionalidades analisadas.

seja considerado um processo elementar independente e contado como uma funcionalidade. Estimativas de Projetos de Software Este capítulo tem como propósito descrever um processo de estimativas de projetos de software aderente à área de processo de Planejamento de Projeto do CMMI.20 É importante ressaltar que as funções testadas consideradas no PFT devem ser documentadas. as funcionalidades da aplicação que necessitem de teste devem ser requisitadas pela contratante e dimensionadas por meio da métrica Pontos de Função de Testes proposta na seção 4. Observe que estas funções farão parte do escopo do projeto de manutenção. 4.14 Manutenção de Componentes Em alguns casos são demandadas manutenções em componentes específicos de uma aplicação e estes são reusados por várias funcionalidades da aplicação. seriam contadas todas as funcionalidades impactadas por esta mudança. este Roteiro propõe que o componente. Por exemplo.13. A conversão do PFT em Ponto de Função deve ser feita de acordo com a fórmula abaixo: PF = PFT x 0. Nesse contexto.________________________________________________________________________ A contagem de PFT deve considerar o seguinte [NESMA. Roteiro de Métricas de Software do SISP 25 . No entanto. o modelo simplificado de estimativas para estimar o esforço dos projetos em homem-hora (HH) e a fórmula de Capers Jones para estimar os prazos dos projetos. PF = PF_NÃO_AJUSTADO 5. o qual deverá ser testado. Se considerarmos o método de contagem de projetos de melhoria do CPM. Calcular o tamanho em Pontos de Função de todas as funções de dados ou transacionais envolvidas no teste. são apresentados: o método Contagem Estimativa de Pontos de Função (CEPF) para estimar o tamanho dos projetos de software em PF. A Figura 2 ilustra um processo de Estimativas de Projetos de Software. 2009]: • • Determinar o tamanho em Pontos de Função de cada função de dados ou transacional envolvida no teste. Além disso. suponha uma mudança em uma rotina de validação de um CPF usada em várias funcionalidades de cadastro. descrito nos parágrafos seguintes.

As premissas e suposições utilizadas na geração das estimativas. as principais estimativas foram geradas e precisam ser documentadas.conforme necessidade Estimar Esforço . O estimador deve analisar os requisitos para garantir a qualidade e então estimar o tamanho do projeto de software. também devem ser documentadas [Hazan. 2008]. 2008] O principal insumo (artefato de entrada) para um processo de estimativas é o documento de requisitos. assim como o estabelecimento da estimativa de recursos computacionais críticos e dos recursos da equipe a ser alocada ao projeto. custo (orçamento) com base na estimativa de tamanho e nos dados históricos de projetos concluídos da organização. O próximo passo é a derivação das estimativas de esforço. dentre outras: complexidade do projeto. Neste ponto.________________________________________________________________________ Coletar e Analisar Requisitos Iniciais Estimar Tamanho Banco de Dados Histórico de Projetos da organização Estimar Cronograma Estimar Custo Estimar Recursos Computacionais Críticos Analisar e Aprovar Estimativas Acompanhar Estimativas Calibrar e Melhorar o Processo Documentar Estimativas e Premissas Documentar Acompanhamento Documentar Resultados finais e Lições Aprendidas Figura 2: Processo de Estimativas de Projetos de Software [Hazan. então. A realização das estimativas por um analista de métricas que não atue na equipe Roteiro de Métricas de Software do SISP 26 Reestimar . Como as estimativas devem ser realizadas no início do processo de desenvolvimento de software. percentual de evolução de requisitos. plataforma de desenvolvimento. prazo (cronograma). o artefato utilizado é um documento inicial de requisitos. tipo do projeto. por exemplo: Documento de Visão ou Formalização Simples de Requisitos.

Quando este cenário não é real. as estimativas devem ser acompanhadas conforme o refinamento dos requisitos. Esta contagem leva em consideração as funcionalidades efetivamente entregues para o usuário pela aplicação. por exemplo Documento de Visão.2007]. Contagem de Pontos de Função Final: realizada após a homologação da aplicação. quando for gerada a especificação de casos de uso. estabelecida politicamente. o prazo do projeto deve ser reestimado. se estas mudanças forem significativas. maiores que a evolução de requisitos (scope creep) prevista na estimativa inicial. que é realizado durante o desenvolvimento. para os contratos de projetos de software. prazo. É importante ressaltar que as mudanças de requisitos também serão consideradas no tamanho projeto a ser faturado. Contagem de Pontos de Função de Referência: realizada após o aceite dos requisitos. Além disso. baseados na métrica Pontos de Função. em função de necessidades de negócio. prazo. constitui uma prática recomendada. O analista de métricas deve analisar também a consistência da documentação utilizada na estimativa. Toda mudança de requisito deve passar por uma análise de impacto entre contratante e contratada. No decorrer do processo de desenvolvimento. 2008]. Portanto. O projeto deve ser reestimado após a fase de requisitos. de modo que a meta se adapte aos resultados da estimativa. visando a coleta de dados para a melhoria do processo de estimativas. • • • Para fins de faturamento. é fundamental a redução de escopo do projeto. Geralmente é baseada em um documento inicial de requisitos. e sempre que ocorrerem mudanças significativas nos requisitos funcionais ou não funcionais. As seções seguintes apresentam os métodos de estimativas de tamanho. Geralmente. especialmente em projetos de desenvolvimento de médio ou grande porte. Constitui uma boa prática a previsão de evolução de requisitos. as estimativas devem ser realizadas em três marcos do processo de desenvolvimento de software.________________________________________________________________________ do projeto. Um Compromisso é um acordo da gerência com as equipes técnicas para alcançar uma meta [Parthasarathy. leva em consideração a Especificação dos Casos de Uso e Regras de Negócio da aplicação. custo e esforço a serem utilizados nos projetos de software em contratos. esforço e recursos realizados. conforme descrito no capítulo 6. deve-se considerar a Contagem de Referência e posteriormente considerar os ajustes no faturamento após a Contagem Final. Nessa etapa é importante destacar os seguintes conceitos na área de estimativas: Uma Estimativa é obtida por meio de uma atividade técnica. As lições aprendidas também devem ser documentadas [Hazan. assim como outros atributos relevantes do projeto. Em um cenário ideal os resultados da estimativa atendem as metas de negócio. utilizando métodos de estimativas. custo. Não deve sofrer interferências políticas. Roteiro de Métricas de Software do SISP 27 . a saber: • Estimativa inicial: realizada após o fechamento do escopo do projeto. A Meta é um desejo. deve-se aferir e documentar o tamanho. Quando o projeto é concluído.

os processos elementares são funções transacionais independentes. • • Contagem de Pontos de Função: significa medir o tamanho do software por meio do uso das regras de contagem do IFPUG [IFPUG. é importante destacar que “estimar significa utilizar o mínimo de tempo e esforço para se obter um valor aproximado dos Pontos de Função do projeto de software investigado” [Meli. Consulta Externa (CE) e Saída Externa (SE) (Figura 1). funções sequenciais pertencem a um mesmo processo elementar e funções independentes constituem processos elementares diferentes. O processo elementar é definido como a menor unidade de atividade significativa para o usuário. é recomendável sempre fazer uma distinção entre os termos e conceitos: Contagem de Pontos de Função e Estimativa de Pontos de Função. Assim. 2010]. Inicialmente. independente e deixar a aplicação em um estado consistente [IFPUG. Em outras palavras. Posteriormente. 2010]. os requisitos funcionais iniciais documentados nas propostas comerciais. os Pontos de Função são associados a cada função identificada. O estimador deve realizar uma leitura no documento inicial de requisitos. baseando-se nas tabelas de complexidade e de contribuição funcional do CPM (Tabela 1). O processo elementar deve ser completo em si mesmo. 1999].1 Contagem Estimativa de Pontos de Função (CEPF) Antes de definir o método de estimativas – Contagem Estimativa de Pontos de Função (CEPF).________________________________________________________________________ 5. Roteiro de Métricas de Software do SISP 28 . com base no conhecimento dos requisitos iniciais do projeto. isto é. formalização simples de requisitos ou em qualquer especificação inicial do sistema do usuário são mapeados nos tipos funcionais da Análise de Pontos de Função: Arquivo Lógico Interno (ALI). Entrada Externa (EE). Arquivo de Interface Externa (AIE). O método CEPF visa aferir o tamanho em PF de maneira simplificada. nos documentos de visão. Estimativa de Pontos de Função: significa fornecer uma avaliação aproximada do tamanho de um software utilizando métodos diferentes da Contagem de Pontos de Função do IFPUG. buscando informações relevantes para a identificação de processos elementares.

devem ser enquadradas em uma das seguintes tabelas: Tabela 2 . o estimador deve descobrir os dados associados ao processo elementar. recomenda-se a utilização da complexidade Média. As necessidades e funcionalidades especificadas para o projeto. É importante ressaltar que se o estimador identificar mais de um Registro Lógico no Arquivo Lógico Interno. recomenda-se utilizar a complexidade Média. arquivos de índices. As entidades fracas também não são consideradas um ALI. arquivos de trabalho e tabelas de relacionamento sem atributos próprios (tabelas que existem para quebrar o relacionamento m x n e apenas transportam as chaves estrangeiras). o estimador deve buscar o entendimento deste para classificá-lo em Entrada Externa. A seguir são apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicação nos tipos funcionais da APF. Na análise do processo elementar também são identificados os grupos de dados lógicos da aplicação. Considerações: Identifique os grupos de dados lógicos de aplicação nos modelos de dados ou diagrama de classes ou a partir dos requisitos funcionais. recomenda-se a utilização da complexidade Simples. Não considere arquivos físicos. CEs. Relação de Casos de Uso. Caso não seja possível a identificação da complexidade da funcionalidade em questão. visando a determinação da complexidade funcional da função identificada.________________________________________________________________________ Documentação do Software Abstração orientada a dados Usuários Identificação dos itens da APF Aplicação Transações (EEs. descritos nos documentos de requisitos (Documento de Visão.Contagem dos Arquivos Lógicos Internos (ALIs): Banco de Dados Lógico da Aplicação (tabelas e arquivos mantidos pela aplicação). Caso não seja possível a identificação da complexidade da função de dados em questão. Adicionalmente. e subgrupos de dados existentes para obter a Roteiro de Métricas de Software do SISP 29 . que são classificados como Arquivos Lógicos Internos ou Arquivos de Interface Externa.). etc. SEs) Dados Internos (ALIs) Pontos de Função (números) Mapeando em números Outras Aplicações Dados Externos (AIEs) Figura 3: Modelo Lógico da Análise de Pontos de Função Uma vez identificado o processo elementar. Consulta Externa ou Saída Externa. tente descobrir os atributos lógicos. Se possível. contidas no documento inicial de requisitos. campos reconhecidos pelo usuário.

N° AIEs Simples: N° AIEs Médio: N° AIEs Complexo: Total PF: Tabela 3: Identificação dos Arquivos de Interface Externa da Aplicação Tabela 4 .Contagem de Entradas Externas (EEs): Funcionalidades que mantêm os Arquivos Lógicos Internos (ALIs) ou alteram o comportamento da aplicação.Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de outras Aplicações. alteração e exclusão de dados. arquivos de trabalho. a experiência tem mostrado que a maioria dos ALIs dos sistemas são de complexidade Simples. os AIEs dos sistemas possuem a classificação de complexidade Simples. relatórios ou consultas referenciam dados externos de outras aplicações. Geralmente. arquivos de índice. Se você não possui conhecimento sobre o processo elementar (funcionalidade Roteiro de Métricas de Software do SISP 30 X 7 PF X 10 PF X 15 PF X 5 PF X 7 PF X 10 PF . segundo as regras de contagem do CPM. tabelas de relacionamento sem atributos próprios e entidades fracas. estas funções também devem ser identificadas como Entradas Externas. Conte separadamente a inclusão. por exemplo: processamentos batch. Caso não seja possível. cada função independente de inclusão ou alteração ou exclusão deve ser contada separadamente. Frequentemente. N° ALIs Simples: N° ALIs Médio: N° ALIs Complexo: Total PF: Tabela 2: Identificação dos Arquivos Lógicos Internos da Aplicação Tabela 3 . Não são considerados arquivos físicos.________________________________________________________________________ complexidade funcional. Considerações: Identifique os grupos de dados lógicos de outras aplicações referenciados pela aplicação que está sendo estimada. também considerados AIEs. Considerações: Identifique as funcionalidades de manutenção de dados. apenas referenciados pela aplicação que está sendo estimada (tabelas e arquivos mantidos por outra aplicação). Algumas vezes. porque são considerados para a determinação da complexidade funcional do AIE apenas os atributos referenciados pela aplicação que está sendo contada. o referenciamento de dados ocorre para a validação de informações em cadastros ou consultas. isto é. A aplicação possui funções de entrada de dados que alteram o comportamento dela. ou processamento de informações de controle? Caso positivo.

Caso não haja conhecimento da aplicação de APF ou sobre o processo Roteiro de Métricas de Software do SISP 31 X 3 PF X 4 PF X 6 PF X 3 PF X 4 PF X 6 PF . incluindo consultas. etiquetas de código de barras. relatórios estatísticos. São os processos elementares do tipo “lê . geração de um arquivo. geração de arquivos com atualização log. considere as Consultas Externas com complexidade Média. download.________________________________________________________________________ analisada). geração de arquivo com atualização de log? Caso positivo. entre outros. download com percentual calculado. xls? Esta função não possui cálculos ou algoritmos para derivação dos dados referenciados nem altera um Arquivo Lógico Interno. Considerações: Você está desenvolvendo uma funcionalidade para apresentar informações para o usuário: uma consulta ou relatório com totalização de dados. “lê . xls.Contagem de Saídas Externas (SEs): Funcionalidades que apresentam informações para o usuário com utilização de cálculos ou algoritmos para derivação de dados ou atualização de Arquivos Lógicos Internos ou mudança de comportamento da aplicação. downloads. estas funções devem ser identificadas como Consultas Externas. N° CEs Simples: N° CEs Média: N° CEs Complexa: Total PF: Tabela 5: Identificação das Consultas Externas da Aplicação Tabela 6 . São as consultas ou relatórios com totalização de dados. Observe que esta função deve ter cálculos ou algoritmos para processar os dados referenciados nos arquivos lógicos ou atualizar campos (normalmente indicadores) nos arquivos ou mudar o comportamento da aplicação.imprime”. relatórios. geração de arquivo pdf. geração de arquivos pdf. nem muda o comportamento do sistema? Caso positivo. gráficos. estas funções devem ser identificadas como Saídas Externas. Se você não possui conhecimento sobre o processo elementar (funcionalidade analisada).apresenta dados”. relatório. entre outros. N° EEs Simples: N° EEs Média: N° EEs Complexa: Total PF: Tabela 4: Identificação das Entradas Externas da Aplicação Tabela 5 . gráficos. downloads com cálculo de percentual. considere as Entradas Externas identificadas com complexidade Média. relatórios estatísticos.Contagem de Consultas Externas (CEs): funcionalidades que apresentam informações para o usuário sem a utilização de cálculos ou algoritmos. Considerações: Você está desenvolvendo uma função para apresentar informações para o usuário: uma consulta. listbox.

usabilidade. baseados em Pontos de Função. dentre outros: plataforma tecnológica. X 4 PF X 5 PF X 7 PF 5. 4. 3. Roteiro de Métricas de Software do SISP 32 . conforme a fórmula [Vazquez. N° SEs Simples: N° SEs Média: N° SEs Complexa: Total PF: Tabela 6: Identificação das Saídas Externas da Aplicação A Estimativa de tamanho do projeto em PF deve ser gerada totalizando-se os PF obtidos nas Tabelas 2. 2010]: Esforço (horas) = Tamanho (PF) x Índice de Produtividade (HH/PF) O índice de produtividade depende de diversos atributos dos projetos. desenvolvimento de componentes. Nesse Roteiro é recomendado que o projeto de migração seja tratado como um novo projeto de desenvolvimento. bem como sua distribuição pelas fases do ciclo de vida do desenvolvimento do software. tipo de manutenção. A fórmula de contagem ou de estimativa de Pontos de Função para Projetos de Desenvolvimento é a seguinte: PF_DESENVOLVIMENTO = PF_NÃO_AJUSTADO Observação: O PF_CONVERSÃO foi suprimido da fórmula. A Engenharia de Software possui vários modelos para estimar esforço de projetos de software.________________________________________________________________________ elementar (funcionalidade analisada).2 Estimativa de Esforço de Projetos de Software Uma vez que o tamanho do projeto está estimado em Pontos de Função. 2010] e o Modelo COCOMO II [Boehm. sendo o Modelo Simplificado de Estimativas [Vazquez. 2009] os mais utilizados. tamanho do projeto. complexidade do domínio. considere as Saídas Externas com complexidade Média. segurança. Neste Roteiro é adotado o modelo Simplificado de Estimativas. Portanto. O Modelo Simplificado de Estimativas consiste em obter um índice de produtividade em horas/PF para o projeto específico em questão. desempenho. 5 e 6. o próximo passo é estimar o esforço de desenvolvimento do projeto. este deve ser estimado separadamente. e então multiplicar o tamanho em PF do Projeto pelo índice de produtividade.

1 Distribuição de Esforço por Fase do Projeto O próximo passo é a definição da distribuição de esforço pelas macro atividades do projeto. O melhor tempo de desenvolvimento. no qual há uma melhor relação custo x benefício de alocação de recursos e menor prazo de desenvolvimento. Os contratos estabelecidos devem determinar o processo de desenvolvimento a ser seguido com percentual de esforço por fases. Na Região Impossível (RI). visando definir o valor agregado ao projeto após cada fase do ciclo de vida (Tabela 7). em se tratando de um projeto com características específicas. 5. 2007] propõe uma fórmula para o cálculo do melhor tempo de desenvolvimento. estes percentuais devem ser alterados para o projeto em questão. como demonstra a região impossível da Figura 4. Note que a curva (Figura 4) mostra que quanto menor o prazo almejado para a conclusão do projeto. Macro Atividades do Processo de Desenvolvimento de Software Engenharia de Requisitos Design. é sugerido e utilizado nas estimativas de prazo deste manual. dado o tamanho de um projeto específico. a redução de prazo tem um limite. No entanto. Arquitetura Implementação Testes Homologação Implantação Percentual de esforço (%) 25% 15% 40% 10% 5% 5% Tabela 7: Distribuição de Esforço por Macro Atividades do Projeto A Tabela 7 é uma sugestão de distribuição de esforço em projetos típicos.3 Estimativa de Prazo de Projetos de Software As estimativas de prazo não são lineares com o tamanho do projeto. Roteiro de Métricas de Software do SISP 33 . as premissas utilizadas para a alteração dos percentuais. Jones [Jones. Nesses casos. considerando-se sempre dados históricos dos projetos já realizados. 5. O aumento do esforço para reduzir o prazo acontece através da realização de horas extras e da inclusão de pessoal adicional. a adição de mais recursos ao projeto não implicará em redução no prazo.________________________________________________________________________ Cada órgão ou entidade deverá possuir sua própria tabela de produtividade para cada linguagem. maior será o esforço requerido e consequentemente maior o custo do projeto. o estimador deve justificar. no entanto. com observações no documento de estimativas. gerando retrabalho.2. denominado Td e de Região Impossível (RI) de desenvolvimento (Figura 4).

baseando-se no tamanho do projeto em Pontos de Função.________________________________________________________________________ Figura 4: Relação entre a Estimativa de Prazo e de Esforço O método utilizado para estimar o prazo dos projetos (Td) é baseado na fórmula de Capers Jones [Jones. da seguinte maneira: Td = V t Onde: Td: prazo de desenvolvimento V: tamanho do projeto em Pontos de Função t: o expoente t é definido de acordo com a Tabela 8 Roteiro de Métricas de Software do SISP 34 . A fórmula de Capers Jones estima o prazo. 2007].

priorizando funcionalidades em cada iteração de acordo com a necessidade dele. então pode-se reduzir o Td em até 25%. a estimativa não atenda às necessidades do cliente. o prazo deve ser obtido por meio da definição de prazo máximo por tamanho funcional com base em dados históricos do órgão.40 Tabela 8: Expoente t por tipo de Projeto É importante destacar que o método só funciona para projetos com mais de 100 PF. quanto mais perto da Região Roteiro de Métricas de Software do SISP 35 . considerar sistema comum) Sistema Cliente/Servidor (com alta complexidade arquitetural e integração com outros sistemas) Sistemas Gerenciais complexos com muitas integrações. Geoprocessamento. observando-se a Região Impossível. Assim. ainda assim. descontar do prazo restante o tempo gasto com a fase de requisitos. Caso seja necessário receber o projeto em um prazo menor que o calculado. caso a estimativa tenha sido realizada ao final da fase de requisitos. Tamanho do Projeto Até 10 PF De 11 PF a 20 PF De 21 PF a 30 PF De 31 PF a 40 PF De 41PF a 50 PF De 51 PF a 60 PF De 61 PF a 70 PF De 71 PF a 85 PF De 86 PF a 99 PF Prazo máximo (em dias úteis) 10 dias 20 dias 30 dias 40 dias 50 dias 60 dias 70 dias 88 dias 104 dias Tabela 9: Estimativa de Prazo de Projetos menores que 100 PF O prazo calculado considera todo o ciclo de vida do projeto. Datawarehousing. Workflow Software Básico.37 0.32 a 0. Sistemas Comerciais Expoente t 0.33 0. Frameworks. Caso.39 0. No entanto.________________________________________________________________________ Tipo de Sistema Sistema Comum – Mainframe (desenvolvimento de sistema com alto grau de reuso ou manutenção evolutiva) Sistema Comum – WEB ou Cliente Servidor Sistema OO (se o projeto OO não for novidade para equipe. recomenda-se propor um processo de desenvolvimento incremental.35 0.36 0. desde a fase de requisitos até a implantação. não tiver o desenvolvimento de componentes reusáveis.34 a 0. conforme a Tabela 9. Caso o projeto seja menor.

a redução de prazo de 25% implica em um aumento de esforço de 70%.2 recursos. A contratada já deverá considerar o custo da hora de todos os profissionais envolvidos no desenvolvimento da solução de software. Não é recomendada a redução de prazo em mais de 20%.5 Método para Estimativa de Custo A estimativa de custo do projeto deve levar em consideração o custo de um ponto de função. Na seção seguinte é abordada a questão da distribuição de esforço e alocação de pessoas ao projeto em questão. o esforço e o custo do projeto aumentam de maneira exponencial. 5.4 Alocação de Equipe ao Projeto Na alocação de equipe. deve ser considerada a estimativa de prazo e a de esforço. de um modo geral. Por exemplo. Sugere-se utilizar a fórmula seguinte: Equipe = Esforço (HH) / (21 x prod. a redução de prazo de 20% implica no aumento de esforço de 50%. Os percentuais de aumento de esforço são estimados. sendo que 4 pessoas com 50% de alocação e um líder de projeto com 20% de alocação ao projeto. a redução de prazo de 10% implica no aumento de esforço de 20%. podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. suponha uma Equipe de 2. 5. Diária = 6h/dia ou 7h/dia (recomenda-se considerar 6 horas/dia) 21 = dias úteis contidos em 1 mês O tamanho da equipe é obtido em quantidade de recursos para o desenvolvimento do projeto. deve-se considerar percentuais de alocação.________________________________________________________________________ Impossível. O cálculo do custo do projeto (CP) será então da seguinte forma: CP = QPF x CPF Onde: QPF = Tamanho do Projeto em PF CPF = Custo para implementar um Ponto de Função na plataforma em questão Roteiro de Métricas de Software do SISP 36 . diária x Prazo) Onde: Prazo = Td em meses Prod. Assim. Esta equipe pode conter 5 pessoas.

banda de rede. expansão de memória. considerando-se o documento de visão inicial do projeto. deve-se considerar um percentual de 20% a 30%. Devem ser registradas as seguintes informações associadas aos recursos computacionais críticos: • • • • • • • Nome do Recurso Computacional: [considere exclusivamente hardware: micro. 6. após a fase de especificação. etc] Descrição: Responsável pela Disponibilização: Data Limite: Parâmetros: [características do recurso: quantidade. Nas estimativas iniciais de tamanho de projetos de desenvolvimento. então temos que gerenciá-los de forma efetiva. área em disco. perfil. configuração. mas precisa-se configurar.6 Estimativa de Recursos Computacionais A Estimativa de Recursos Computacionais também deve ser considerada. ficando a critério da instituição estabelecê-lo contratualmente. Por exemplo. Considerações para Contagem de Pontos de Função Esta seção apresenta considerações especiais sobre o dimensionamento em Pontos de Função de mudança de requisitos. Roteiro de Métricas de Software do SISP 37 . Este percentual é sugerido. conforme o usuário e o desenvolvedor adquirem mais conhecimento sobre o negócio [Sommerville. 6. Nas estimativas. 2007].1 Considerações sobre Mudança de Requisitos Em projetos de desenvolvimento e manutenção de software é bastante comum as mudanças de requisitos no decorrer do projeto. esta constitui um componente importante para as estimativas de custos dos projetos. suponha que após a análise do Documento de Visão de um Projeto. O CPM denomina este fenômeno de Scope Creep.] Caso o projeto a ser desenvolvido não possua nenhum recurso computacional crítico.________________________________________________________________________ 5. um servidor específico para teste ou homologação do sistema. P: recurso para ambiente de Produção. deve ser registrado no documento de estimativas que o projeto não possui nenhum recurso computacional crítico. redução de cronograma e fator criticidade. dentre outros: espaço em disco para o sistema entrar em produção. H: recurso para ambiente de Homologação] Custo (Opcional): [Custo do recurso computacional. Como os requisitos não podem ser congelados. utilizando-se como insumo as especificações de casos de uso. etc] Tipo do Recurso: [D: recurso para ambiente de Desenvolvimento. Um recurso computacional é um hardware que se precisa adquirir. Não considerar custos de processamento ou custos operacionais de produção. recomenda-se utilizar um percentual para evolução de requisitos de 30% a 40%. Exemplos de recursos computacionais incluem. ou que se possui. periférico. projetos cancelados. após a fase de requisitos.

então o tamanho estimado do projeto considerado é de 270 PF (200 + 35%). Arquitetura 15% Implementação 40% Assim. Esta distribuição percentual de esforço deve ser definida no contrato de software. Nestes casos. A equipe de desenvolvimento terá um retrabalho de várias fases do ciclo de vida. supondo que este será entregue ao cliente sem passar por novas alterações. suponha um relatório de clientes em que no final da fase de implementação foi solicitada a exibição de uma nova informação. Uma mudança de requisito gera retrabalho da equipe de desenvolvimento. 6. o tamanho da mudança é de 4 PF (5 PF x 80% = 4 PF). O progresso das atividades executadas em cada funcionalidade do projeto deve ser obtido por meio do acompanhamento do plano do projeto. Por exemplo.________________________________________________________________________ aplicando-se a CEPF. Assim. Por exemplo. foi obtido o tamanho de 200 PF. estar em fase de requisitos e de testes.1 ou alguma diretriz específica de distribuição de esforço do contrato em questão. aumentando assim o esforço e o custo do projeto. o tamanho funcional das funcionalidades canceladas será aferido por meio da contagem de Pontos de Função das funcionalidades canceladas e um Fator de Impacto. utilizando-se a premissa de evolução de requisitos em 35%. O Fator de Impacto é definido com base no percentual de esforço alocado à construção da funcionalidade em questão.2. Esta premissa deve ser documentada. visando definir o valor agregado ao projeto após cada fase do ciclo de vida. Para tratar o dimensionamento das mudanças de requisitos torna-se importante definir a distribuição de esforço pelas macroatividades do projeto. suponha um relatório de clientes em que no final da fase de implementação foi solicitada a exibição de uma nova informação. por exemplo. A equipe de desenvolvimento terá um retrabalho de várias fases do ciclo de vida. porque o plano de testes é construído na fase de requisitos. devido a mudanças no ambiente da contratante. A Tabela 7 estabelece os percentuais por atividade de forma a permitir a contagem de mudança conforme o estágio do projeto. Para o requisito original será considerado o seguinte: Engenharia de Requisitos 25% Design. É importante ressaltar que em um processo de desenvolvimento incremental uma funcionalidade pode. O Fator de Impacto deve ser aplicado na contagem de Pontos de Função das funcionalidades em questão. Roteiro de Métricas de Software do SISP 38 . o tamanho dessa mudança deve ser calculado da seguinte maneira: -Tamanho do relatório de clientes (original) – SE – M – 5 PF -Tamanho do relatório de clientes (alterado) – SE – M – 5 PF O requisito alterado será considerado 100% do PF. uma demanda ou parte de um projeto de desenvolvimento ou manutenção pode ser cancelado a critério da contratante.2 Considerações sobre Projetos Cancelados Em alguns casos. observando a Tabela 7 de distribuição de esforço contida na seção 5.

assim pretende-se pesquisar mais sobre o melhor tempo de desenvolvimento (onde há uma melhor relação custo x benefício de alocação de recursos e menor prazo de desenvolvimento). feriados e fora do horário comercial. devido aos cálculos de Região Impossível e ainda. então deve-se considerar o seguinte: • • • Redução de prazo de 10%: aumento de esforço de 20% (projetos urgentes) Redução de prazo de 20%: aumento de esforço de 50% (projetos críticos) Redução de prazo de 25%: aumento de esforço de 70% (projetos de alta criticidade) Deve-se ressaltar que não é possível uma redução de prazo maior que 25%. um aumento de esforço de 20% implica em aumento de 20% no custo de PF. então este é tratado como um projeto normal. 6. que deverá ser multiplicado pelo tamanho funcional da demanda considerada crítica. No entanto.4 Fator de Criticidade de Solicitação de Serviço Em função da criticidade e da necessidade de alocação de recursos extras para atendimento da demanda no prazo estipulado pelo cliente. dado o tamanho de um projeto específico. Assim. de modo a remunerar adequadamente o aumento do esforço de atendimento.35 (um vírgula trinta e cinco). não é recomendada a redução de cronograma. Se este prazo for igual ou superior ao prazo calculado pela Fórmula de Capers Jones (expoente t) ou em caso de projetos pequenos (menores que 100 PF) a um prazo calculado considerando o trabalho da equipe de 8 horas/dia nos dias úteis.3 Considerações sobre Redução de Cronograma As estimativas de prazo não são lineares com o tamanho do projeto. este aumento de esforço será refletido na contagem de PF. Este fator é considerado para demandas que devem ser atendidas em finais de semana. o aumento de esforço de 70% implica em aumento de 70% no custo de PF. Jones [Jones. Caso o contrato seja baseado em preço por Pontos de Função. Alguns projetos devido à legislação e a outros fatores externos já se iniciam com um prazo imposto. Entende-se como horário comercial o horário de 08:00 às 18:00 h. se o projeto tiver um prazo imposto inferior ao prazo calculado. descrita na seção 5. será adotado um Fator de Criticidade de 1. aumento de esforço de 50% implica em aumento de 50% no custo de PF. 2007] propõe uma fórmula para o cálculo do melhor tempo de desenvolvimento.________________________________________________________________________ 6. Deve-se tentar priorizar funcionalidades trabalhando com o ciclo de vida incremental. conforme nos aproximamos da Região Impossível. o esforço e o custo do projeto aumentam de maneira exponencial. Roteiro de Métricas de Software do SISP 39 . horário de Brasília. Como os riscos da redução de cronograma também são altos.3.

As definições apresentadas têm como base o artigo “Considerations for Counting with Multiple Midia” Release 1.doc. Multi-Mídia: quando mais de uma mídia é necessária para entregar a função. Também é abordado neste capítulo algumas diretrizes para a mensuração de Dados de Código ou Code Data. Este termo é utilizado para incluir. A determinação da contagem de PF seguindo a abordagem multiple instance ou single instance depende da avaliação da Coordenação de Métricas da organização. para a aplicação das regras definidas no CPM.xls e consultas idênticas em tela e papel.0 publicado pelo IFPUG [IFPUG. Abordagem Single Instance: esta abordagem não reconhece que a mídia utilizada na entrega da função transacional é uma característica de diferenciação na identificação da unicidade da função transacional. que serão consideradas uma única funcionalidade. A seguir são descritos os termos comuns definidos pelo IFPUG [IFPUG. com exceção dos casos de consultas em . . Assim. Considerando-se a contagem de PF de funcionalidades entregues em mais de uma midia.pdf. Mídia: descreve a maneira que os dados ou informações se movimentam para dentro e para fora de uma fronteira de aplicação. Múltiplas Mídias: quando a mesma funcionalidade é entregue em mais de uma mídia. Se duas funções entregam a mesma funcionalidade usando mídias diferentes. Múltiplos canais é sinônimo de múltiplas midias. impressora. 2009]: • • Canal: também refere-se a mídia. As estimativas e contagens de PF abordadas neste documento serão baseadas em multiple instance. Esta abordagem é reconhecida pelo IFPUG. funcionalidades únicas são reconhecidas no contexto da mídia na qual elas são requisitadas para operar. dentre outros: diferentes plataformas técnicas e formatos de arquivos como diferentes mídias. arquivo. por exemplo. É importante enfatizar que o IFPUG reconhece ambas abordagens. a aplicação das regras de contagem de Pontos de Função definidas no CPM tem levado a duas abordagens alternativas. 2009]. uma nova notícia publicada na Internet que é apresentada em vídeo e texto. somente uma mídia é requisitada para um usuário específico em um determinado momento. . por exemplo consulta de extrato bancário via internet como oposto a consulta de extrato bancário via terminal do banco. por exemplo. apresentação de dados em tela. voz. elas são consideradas a mesma 40 • • • Roteiro de Métricas de Software do SISP . Frequentemente. A abordagem single instance considera que a entrega de uma função transacional em múltiplas mídias não deve ser utilizada na identificação da unicidade da função. Observe que a notícia completa só é apresentada para o usuário se ele ler o texto e assistir o vídeo. A abordagem multiple instance leva em consideração que a mídia utilizada na entrega da funcionalidade é uma característica de identificação da unicidade da função.________________________________________________________________________ 7. Contagem de Pontos de Função com Múltiplas Mídias e Dados de Código Este capítulo tem como propósito apresentar as diretrizes de Contagem de Pontos de Função em relação ao tema Múltiplas Mídias. single instance e multiple instance. a saber: single instance e multiple instance.

Neste cenário. permitindo uma função de negócio ser reconhecida no contexto das mídias que são requisitadas para a funcionalidade ser entregue. A mesma informação pode ser impressa caso requisitado pelo usuário na tela em questão. Nesses casos. o processo elementar não é único e portanto a funcionalidade será contada duas vezes. Observe que a abordagem multiple instance considera que a contagem de PF de dados idênticos sendo apresentados usando mais de um tipo de mídia deve incluir toda instância da função em cada tipo de mídia. 7. considerando que dados idênticos sendo apresentados em tela e relatório impresso devem ser contados como uma única função. A abordagem multiple instance reconhece que a mídia para entrega constitui uma característica de diferenciação na identificação da unicidade da função transacional.________________________________________________________________________ funcionalidade em uma contagem de Pontos de Função. então será utilizada a abordagem multiple instance. duas funções são contadas – apresentação de dados em tela. Assim. uma aplicação apresenta uma informação em uma consulta em tela.1 Cenário 1: Mesmos dados apresentados em tela e impressos Neste cenário. Este Roteiro deve ser atualizado considerando a publicação de novas diretrizes do IFPUG e novos cenários que emergirão nas contagens de PF dos projetos dos órgãos e entidades do SISP. duas funções são contadas – geração de Roteiro de Métricas de Software do SISP 41 . sugere-se a abordagem single instance. E ainda. Neste exemplo. 7. apresentação de dados impressos. Os cenários descritos nas seções seguintes não representam uma lista completa de situações de múltiplas mídias. Observe que a abordagem multiple instance considera que dados idênticos estão sendo entregues em mais de um tipo de mídia e a contagem de PF incluirá todas as instâncias de tipos de mídia. o processo elementar não é único e portanto a funcionalidade será contada duas vezes. apenas uma funcionalidade será incluída na contagem de Pontos de Função. se a geração das múltiplas saídas não seguirem o padrão da ferramenta de desenvolvimento e tiverem que ser customizadas para o cliente. sugere-se que se utilize a abordagem single instance considerando que os dados impressos e os dados apresentados no arquivo de saída sejam idênticos e que a ferramenta de desenvolvimento apoie a geração dessas múltiplas saídas.2 Cenário 2: Mesmos dados de saída como dados em arquivo e relatório impresso Uma aplicação grava dados em um arquivo de saída e imprime um relatório com informações idênticas às gravadas no arquivo. • Abordagem Multiple Instance: esta abordagem especifica que o tamanho funcional é obtido no contexto do objetivo da contagem. Caso as lógicas de processamento da geração do arquivo de saída e do relatório em papel sejam distintas. O entendimento destes exemplos facilitará o entendimento de outros cenários envolvendo múltiplas mídias. Nesses casos. Caso as lógicas de processamento da consulta em tela e do relatório em papel sejam distintas.

A abordagem single instance conta apenas uma funcionalidade. por exemplo em um arquivo html e um formato de valores separados por vírgula. poderá ser utilizada a abordagem single instance. Se a equipe de desenvolvimento precisar desenvolver o relatório nos dois formatos na ferramenta em questão. são até projetos de desenvolvimento distintos.6 Dimensionamento de Dados de Código As Tabelas com atributos de Código e Descrição devem ser analisadas com muito cuidado. O processamento on-line também executa validações das informações. Algumas vezes. a lógica de processamento utilizada nas validações em modo batch é diferente da lógica de processamento das validações nas entradas de dados on-line. No entanto. observando que a funcionalidade será da ferramenta e não da aplicação. então se contará apenas uma vez. salvar em html ou salvar no formato de valores separados por vírgula. Geralmente. por exemplo consulta de dados em página Web e consulta de dados no telefone celular. O processamento do arquivo batch executa validações durante o processamento. se a ferramenta de desenvolvimento suportar um gerador de relatórios que o usuário visualize o relatório em tela e o gerador permita ao usuário imprimir o relatório. porque a lógica de processamento de análise de condições para verificar quais são aplicáveis é identificada. Sugere-se que seja utilizada a abordagem multiple instance que conta duas funcionalidades: a entrada de dados batch e a entrada de dados on-line. Caso estas tabelas não sejam mantidas pela aplicação. Lembrando que caso o projeto é claro o suficiente para dizer que o desenvolvimento é o mesmo. 7. Geralmente se utiliza a abordagem multiple instance que conta duas funcionalidades: a consulta de dados na Web e a consulta de dados via celular.3 Cenário 3: Mesmos dados de entrada batch e on-line Uma informação pode ser carregada na aplicação por meio de dois métodos: arquivo batch e entrada on-line. serão contadas duas funcionalidades. o que geralmente Roteiro de Métricas de Software do SISP 42 . 7. 7.________________________________________________________________________ arquivo e apresentação dos dados impressos.5 Cenário 5: Relatórios em Múltiplos Formatos Um relatório deve ser entregue em diferentes formatos. A abordagem single instance conta apenas uma funcionalidade. conforme sugerido na abordagem multiple instance.4 Cenário 4: Múltiplos canais de entrega da mesma funcionalidade Uma funcionalidade deve ser disponibilizada em múltiplos canais. um projeto relativo ao sistema Web e outro para o sistema via celular. Nestes casos. Considera-se que a funcionalidade é desenvolvida duas vezes para os dois canais. 7. considera-se a ferramenta utilizada na geração dos relatórios.

especialistas nas atividades de processos de software e na customização da ferramenta para criação do site do processo. Estes serviços são executados por consultores da contratada. especialistas em BPM (Business Process Modeling). Esta equipe fica disponível em horário Roteiro de Métricas de Software do SISP 43 . devem ser consideradas as horas de consultoria para preparação e execução do curso e o custo do deslocamento do instrutor. etc. etc. especialistas nas atividades associadas à elaboração de um PDTI. Estes serviços são executados por consultores da contratada. •Desenvolvimento de Cursos para EaD: encontram-se nesta categoria as demandas de desenvolvimento de um curso na modalidade de Ensino a Distância (EaD). Atividades Sem Contagem de Pontos de Função Deve-se ressaltar que o processo de desenvolvimento de soluções possui várias atividades que devem ser consideradas como um projeto separado. especialistas no assunto em questão.: encontram-se nesta categoria as demandas de treinamentos em linguagens de programação. 8. • Elaboração de Plano Diretor de Tecnologia da Informação (PDTI): encontram-se nesta categoria demandas para elaboração de PDTIs para clientes. processos. Estas demandas devem ser remuneradas em horas. Outros serviços prestados que também não possuem Pontos de Função associados são os seguintes: •Administração de Dados: este serviço requer uma equipe de administradores de dados (ADs) com um número de profissionais definido junto a contratante. elas serão contadas como dados de negócio (Arquivo Lógico Interno). caso sejam requisitados Casos de Uso e a implementação de funcionalidades para manter tais tabelas. Estes serviços são executados por consultores da contratada. Assim. levando-se em conta as horas realizadas. • Mapeamento de Processos de Negócio: encontram-se nesta categoria as demandas de elaboração de documentação contendo o mapeamento de processos de negócio de uma organização ou de parte de uma organização. modelos da qualidade. Estes serviços são executados por consultores da contratada. aderentes às melhores práticas do CMMI e IN04.________________________________________________________________________ acontece. dedicada para atender as demandas associadas à definição e manutenção do modelo de dados de negócio do cliente. dentre outras: •Treinamentos em Tecnologia. • Definição de Processo de Desenvolvimento de Soluções: encontram-se nesta categoria demandas para definição de Processos de Software. elas não serão contadas. ferramentas de gestão. se for o caso. caso seja justificadamente necessário manter estas informações. Assim. Metodologias. métricas. elas serão consideradas requisitos funcionais do usuário. Métricas. Entretanto.

As demais modalidades de consultoria também podem ser enquadradas neste item. que antecedem a fase de requisitos – primeira fase do processo de software – e devem ser faturadas em horas de consultoria. Estas atividades também devem ser precificadas a parte. Consultoria em Métricas. O esforço deste serviço deve ser considerado separadamente da estimativa de esforço derivada da contagem de PF. desempenhadas pelos DBAs da equipe de desenvolvimento. Em alguns casos. que também deve ser cobrado do contratante. tais como: atas de reunião. O esforço deste é considerado dentro do projeto de EaD que não faz parte do projeto de desenvolvimento ou manutenção em questão. por falta de pessoal. não cabendo cobrança adicional. que deve ser validado pelo contratante. O principal produto gerado nesta atividade é o artefato: Documento de Visão do Projeto (DV). alguns órgãos e entidades têm contratado estas atividades. • Especificação de Negócio: esta atividade é a primeira atividade a ser executada em uma demanda de projeto de desenvolvimento e/ou de manutenção. pode ocorrer também o deslocamento do instrutor. O preço deste serviço deve ser calculado. documento de requisitos não funcionais e glossário da especificação de negócio. preparação de ambiente (testes. Estas demandas não possuem contagem de PF associada. Além do DV podem ser gerados outros documentos. levando-se em conta o preço da hora dos consultores da contratada que estarão realizando atividades de preparação de treinamento e de instrutoria. sendo tratado como um projeto de treinamento a parte. •Análise de Solução: Serviço de apoio destinado à análise de regras de negócio implementadas em soluções de TI. O esforço desta atividade deve ser considerado separadamente da estimativa de esforço derivada da contagem de PF. É importante ressaltar que esta atividade é de responsabilidade dos Analistas de Negócios da empresa contratante. É importante ressaltar que as atividades de banco de dados associadas ao projeto de desenvolvimento ou de manutenção. já estão consideradas dentro do projeto de software. No entanto. estes serviços não possuem contagem de PF associada. por meio da assinatura do termo de aceite. Estas demandas não possuem contagem de PF associada. homologação. •Consultoria: Serviço de apoio destinado à análise de regras de negócio a serem implementadas em soluções de TI realizado por consultores especialistas da contratada. de acordo com a Instrução Normativa (IN 04). por exemplo. no entanto o esforço deve ser considerado separadamente da estimativa de esforço derivado da contagem de Pontos de Função. Outras atividades contidas em um processo de software devem ser gerenciadas dentro do projeto de desenvolvimento ou de manutenção. Assim. por exemplo. Roteiro de Métricas de Software do SISP 44 . São elas: • Treinamento para Implantação: são demandas de treinamentos sobre utilização do sistema a ser implantado para os gestores de solução do cliente e usuários.________________________________________________________________________ comercial para atendimento das demandas. O objetivo desta atividade é gerar a Especificação da demanda. implantação). Deve-se ressaltar que este treinamento para implantação pode ser definido na modalidade de EaD.

gerando novas versões deste Roteiro. 10. O DV é o artefato utilizado como insumo para o Planejamento do Projeto . Em caso de utilização de Roteiro de Métricas em contratos de software.1 Revisão para Correção de Inconsistências e Situações não previstas A revisão deste Roteiro será feita sempre que se verificarem inconsistências entre uma definição do CPM e uma regra constante deste documento e situações não previstas neste Roteiro. A estimativa de tamanho utiliza a métrica de Pontos de Função Não Ajustados como unidade de medida. Documento de Requisitos não funcionais e Glossário (opcional). É importante ressaltar que o uso de métricas em contrato de software é uma excelente prática. 9. seja publicada em versões futuras do CPM ou em White Paper. ou quando for detectado um novo tipo de serviço associado ao desenvolvimento de software não previsto neste trabalho. conforme recomendado nos Acórdãos do Tribunal de Contas da União (TCU). visando a aderência de todos os projetos desenvolvidos na instituição ao processo de Planejamento de Projetos de nível 2 do CMMI e às diretrizes da Instrução Normativa – IN04. Conclusão Este documento apresentou um Roteiro para o dimensionamento de tamanho de todos os tipos de projetos de software da contratante. Processo de Revisão do Roteiro de Contagem 9. Como trabalho futuro recomenda-se a revisão e atualização deste roteiro sempre que se verificar inconsistência entre alguma definição do IFPUG. dever-se-á documentar a novidade em documentos posteriores. 9. deve ser gerado um Documento de Visão (DV) ou outro documento de requisitos de negócios.________________________________________________________________________ Nesta atividade. Outro ponto a ser destacado é a implantação de um Escritório de Métricas com Servidores capacitados para realizar contagens de Pontos de Função e Estimativas.estimativa de tamanho funcional (em Pontos de Função) do projeto e para o processo de desenvolvimento . a atualização do Roteiro deve ser negociada entre órgão contratante e a empresa contratada. visando proporcionar uma gestão efetiva dos contratos com base em dados quantitativos e objetivos. Nesse caso deverá haver uma avaliação da nova versão para se decidir sobre a atualização do Roteiro. A implantação desta modalidade de contrato implica na definição de processos de gestão de requisitos e de gestão de projetos baseados nas melhores práticas dos modelos de Qualidade de Software. Estes Servidores serão responsáveis pela revisão das contagens de Pontos de Função e Estimativas realizadas pelo Escritório de Métricas da empresa contratada e pela manutenção do Roteiro de Métricas do Órgão.atividade de Engenharia de Requisitos do processo de desenvolvimento de software. Roteiro de Métricas de Software do SISP 45 . Para situações não previstas neste Roteiro.2 Revisão para Adoção de Novas Versões do CPM A adoção de nova versão do CPM como referência para este Roteiro de Contagem não será imediata à sua publicação.

3. S. 1999] MELI. ISO Bulletin May 2003. Software Engineering. Estimativas e Gerenciamento de Projetos de Software. 2008. Version 4. 2007. C. Prentice Hall. Devmedia. E. pp.. Version 2. [IFPUG. Considerations for Counting with Multiple Media. September. C. “Measuring the logical or functional” Size of Software Projects and Software Application”. Engenharia de Software Magazine. [IEEE.2007] PARTHASARATHY. SANTILLO. R.0. Relatório do Grupo de Trabalho para Definição da Utilização de Pontos de Função nos Serviços de Desenvolvimento e Manutenção de Sistemas. 2005. [SERPRO. 2007] SOMMERVILLE. R. W. I. January.2. IEEE Std 1219. [Jones. IEEE Standard for Software Maintenance. April. 9ª Edição. G. [Hazan. São Paulo.W. Software Cost Estimation With COCOMO II.2009] IFPUG. [NESMA. Vol.1998] IEEE Computer Society.. Editora Érica. Roteiro de Métricas de Software do SISP 46 . pp10-13. Spotlight Software. B. New Jersey. M. C. 2003] DEKKERS. Métodos para Estimativa de Projetos de Software Baseado em Pontos de Função. Netherlands. Function Point Analysis for Software Enhancement Guidelines. Análise de Pontos de Função: Medição. 2009 [Parthasarathy. L.. 2010] VAZQUEZ. 8th Edition. ALBERT. [Vazquez. 2005] ROETZHEIM. 271-286. pp. [IFPUG. [Roetzheim. Release 1. October 1999. Edição 2. Análise de Pontos de Função: Uma Aplicação nas Estimativas de Tamanho de Projetos de Software.________________________________________________________________________ Referências Bibliográficas [Boehm. 2009] BOEHM. Estimating and Managing Project Scope for New Development. Mc Graw Hill. Amsterdam. 2009. Addison Wesley. Counting Practices Manual. 2008] SERPRO. 2010. Practical Software Estimation: function point methods for insourced and outsourced projects. [Dekkers. Second Edition. 1998. Pearson Education Limited. Function Point Estimation Methods: A Comparative Overview. SIMÕES. 2009] NESMA. [Sommerville. M.1. C. [Meli. 2008] HAZAN. A. CrossTalk. New York. 2009. 2007. 2007. Proceedings of FESMA 99.25-31.2010] IFPUG. Estimating Software Costs. 2007] JONES.

Art. no uso de suas atribuições que lhe conferem o Decreto nº 7. o Decreto nº 1. harmonizar entendimento e abordar assuntos relativos à contratação de soluções de software não contempladas pelo manual de contagem do IFPUG. também há necessidade de medir projetos de manutenção adaptativa de software. de 21 de janeiro de 1994.063. MARIA DA GLÓRIA GUIMARÃES DOS SANTOS Roteiro de Métricas de Software do SISP 47 . Art.________________________________________________________________________ Anexo I – Portaria SLTI/MP Nº 31. 2º O Roteiro de Métricas de Software do SISP é um documento técnico complementar que visa esclarecer questões técnicas. 4º Esta Portaria entra em vigor na data de sua assinatura. torna-se relevante a definição de procedimentos complementares de medição para dimensionar projetos de manutenção adaptativa de software cuja mensuração não são abordadas pelo manual de prática de contagem do IFPUG. de 29 novembro de 2010 Dispõe sobre recomendações técnicas para a utilização da métrica Análise de Ponto de Função no âmbito da Administração Pública Federal direta. Além dos projetos de desenvolvimento de novas soluções de software e de melhoria de software. 3º Recomenda-se que os órgãos integrantes do Sistema de Administração dos Recursos de Informação e Informática (SISP) adotem o roteiro de contagem nas suas contratações de serviços de desenvolvimento e manutenção de soluções de software. ORÇAMENTO E GESTÃO. Art. de 23 de março de 1994.094. de 13 de janeiro de 2010. resolve: Art. A SECRETÁRIA DE LOGÍSTICA E TECNOLOGIA DA INFORMAÇÃO DO MINISTÉRIO DO PLANEJAMENTO. Assim. § 1º A métrica Ponto de Função é definida pelo organismo International Function Point Users Group (IFPUG). sua utilização é uma boa prática na contratação de serviços e está aderente ao estabelecido na Instrução Normativa SLTI nº 4 de 12 de novembro de 2010. Parágrafo Único.048. § 2º O manual de práticas de contagem de Pontos de Função publicado pelo IFPUG define as regras básicas orientativas de contagem de Pontos de Função para projetos de desenvolvimento e melhoria de soluções de software. § 3º Por permitir a medição objetiva de serviços de desenvolvimento de soluções de software.e o Decreto nº 1. autárquica e fundacional e dá outras providências. 1º A métrica de Pontos de Função foi concebida como uma medida de tamanho funcional para projetos de desenvolvimento e de melhoria (manutenção evolutiva) de software.

.1 1. 2. 2.________________________________________________________________________ Anexo II – Formalização Simples de Requisitos – Projetos de Manutenção Pequenos (< 100 PF) Dados Gerais Número da OS Nome do Sistema Mantido Tecnologia Adotada Data do Início do Serviço DD/MM/AAAA Data do Término do Serviço DD/MM/AAAA Descrição da Solicitação Descrição do Serviço Executado Requisito 1.. Roteiro de Métricas de Software do SISP 48 .2. Detalhamento 1.2..1 2..

________________________________________________________________________ Identificação da Manutenção Tipo Melhoria – Criação de Novas Funcionalidades Melhoria – Alteração de Funcionalidades Melhoria – Exclusão de Funcionalidades Migração de Dados Corretiva – Funcionalidade no Prazo de Garantia (sem custo) Corretiva – Funcionalidade Não Desenvolvida pela Contratada ou fora do prazo de garantia Redesenvolvimento de Projeto em outra plataforma Atualização de Plataforma Manutenção em Interface (Cosmética) Adaptação de Funcionalidades a Requisitos Não Funcionais Apuração Especial – Base de Dados Apuração Especial – Base de Dados – Consulta Prévia Apuração Especial – Emissão de Relatório Apuração Especial – Reexecução Atualização de Dados Manutenção de Páginas Estáticas em Intranet / Portal / Internet Manutenção de Documentação de Sistemas Legados Verificação de erros (Análise e Solução de Problemas) Pontos de Função de Testes (Execução de Testes em funcionalidades não mantidas) Manutenção em Componentes Foi demandada a redocumentação da funcionalidade mantida?  Sim  Não Aplicar Fator Criticidade?  Sim  Não 49 Roteiro de Métricas de Software do SISP .

________________________________________________________________________ Observações relevantes quanto ao tipo de manutenção: Descrição dos Requisitos de Manutenção (para cada funcionalidade alterada. utilizar um quadro) a) Tabelas Modificadas pela Manutenção Nome da Tabela A Tabela é atualizada por alguma funcionalidade da aplicação:  Sim A Tabela é atualizada por outra aplicação:  Sim A Tabela foi:  Incluída  Alterada  Não  Excluída  Não Total de Campos da Tabela após a Manutenção = Campos Incluídos/Alterados/Excluídos A funcionalidade será apenas testada?  Sim  Não b) Entradas de Dados Afetadas pela Manutenção (telas ou arquivos de carga) Nome da Entrada Total de Campos na Entrada = Nome das Tabelas Acessadas (Lidas e Gravadas) = Campos Incluídos/Alterados/Excluídos Roteiro de Métricas de Software do SISP 50 .

________________________________________________________________________ Houve mudança na regra de negócio (validações. regras de cálculo)?  Sim  Não A funcionalidade será apenas testada?  Sim  Não c) Consultas Afetadas pela Manutenção Considere a tela de parâmetros e a de resultados da consulta como apenas uma única Consulta.)  Sim Campos Incluídos/Alterados/Excluídos  Não Houve mudança na regra de negócio (validações.. lógica de processamento.. Caso a consulta seja do tipo lista e consulta detalhes. indicador. regras de cálculo. lógica de processamento. considere como funções independentes e preencha quadros diferentes. Nome da Consulta Total de Campos da Consulta Tabelas Acessadas Total de Campos Afetados = Total de Campos Calculados ou Totalizadores = Existe atualização de dados (log. campos de filtro)?  Sim  Não A funcionalidade será apenas testada?  Sim  Não 51 Roteiro de Métricas de Software do SISP .

regras de cálculo.. indicador. lógica de processamento.. campos de filtro)?  Sim  Não A funcionalidade será apenas testada?  Sim  Não Roteiro de Métricas de Software do SISP 52 .)  Sim Campos Incluídos/Alterados/Excluídos  Não Houve mudança na regra de negócio (validações.________________________________________________________________________ d) Relatórios Afetados pela Manutenção Considere a tela de parâmetros e a de resultados do relatório como apenas um único Relatório. Nome do Relatório Total de Campos no Relatório Tabelas Acessadas Total de Campos Afetados = Total de Campos Calculados ou Totalizadores = Existe atualização de dados (log.

Roteiro de Métricas de Software do SISP 53 . o total de Pontos de Função realizados no Projeto _____ na OS _________ é de _____ PF Não Ajustados.________________________________________________________________________ Anexo III – Modelo de Documento de Contagem de Pontos de Função – Projetos de Manutenção Pequenos (< 100 PF) Documento de Contagem de Pontos de Função de Projetos de Manutenção Pequenos Cliente: Histórico da Revisão Data Versão Descrição Autor Aprovador Nome Projeto: Número da OS: Responsável pela Contagem: Descrição da Solicitação de Mudança: Descrição da Atividade Contagem PF Tipo de Manutenção / Total PF Observações Relevantes: Conforme a tabela de atividades acima.

Sign up to vote on this title
UsefulNot useful