Apendice I - Roteiro de Metricas de Software Do SISP - V1.0

Roteiro de Mtricas de Software do SISP Verso 1.
Braslia, 29 de novembro de 2010.
________________________________________________________________________
Roteiro de Mtricas de Software do SISP
________________________________________________________________________
Presidente da Repblica
Luiz Incio Lula da Silva
Ministrio do Planejamento, Oramento e Gesto

Paulo Bernardo Silva
Secretaria de Logstica e Tecnologia da Informao SLTI

Maria da Glria Guimares dos Santos
Departamento de Integrao de Sistemas DSI

Nazar Lopes Bretas
Coordenao Geral de Gesto Corporativa CGGC

Claudio Muniz Machado Cavalcanti
Ncleo de Padronizao Tecnolgica

Corinto Meffe Equipe de Elaborao
Carlos Renato dos Santos Ramos (SLTI/MP) Claudia Hazan (SERPRO) Claudio Muniz Machado Cavalcanti (SLTI/MP) Emanuelle Monteiro Silva (SLTI/MP) Ftima Saldanha Cesarino (CEF) Gileno Dias dos Santos (SLTI/MP) Jose Romildo Araujo de Andrade (SLTI/MP) Lucinia Turnes (SLTI/MP) Marcelo Paiva Fernandes (SLTI/MP) Maurcio Koki Matsutani (DATAPREV) Patrcia Oliveira de Carvalho (SUSEP) Rafael Campos (SLTI/MP) Rafael Monteiro dos Santos Escolstico (MEC) Regiane Brito (BACEN) Rosa Maria da Costa Medeiros (INEP)
________________________________________________________________________
________________________________________________________________________
Sumrio
1. Introduo..........................................................................................................................7 2. Objetivo..............................................................................................................................8 3. Contagem de Pontos de Funo.......................................................................................8 3.1 Determinar Propsito, Tipo, Escopo e Fronteira de Contagem .................................9 3.2 Funes de Dados e Funes Transacionais...........................................................10 3.3 Clculo de Pontos de Funo....................................................................................11 4. Itens No Mensurveis ...................................................................................................13 4.1 Projeto de Melhoria....................................................................................................13 4.2 Projetos de Migrao de Dados................................................................................17 4.3 Manuteno Corretiva...............................................................................................17 4.4 Redesenvolvimento de Projetos em outra Plataforma..............................................19 4.5 Atualizao de Plataforma.........................................................................................19 4.6 Manuteno em Interface..........................................................................................20 4.7 Adaptao de Funcionalidades a Requisitos No Funcionais..................................20 4.8 Apurao Especial.....................................................................................................21 4.8.1 Apurao Especial Base de Dados.....................................................................21 4.8.2 Apurao Especial Gerao de Relatrios..........................................................22 4.8.3 Apurao Especial Reexecuo..........................................................................22 4.9 Atualizao de Dados................................................................................................23 4.10 Manuteno em Pginas Estticas de Intranet, Internet ou Portal.........................23 4.11 Manuteno de Documentao de Sistemas Legados...........................................23 4.12 Verificao de Erros.................................................................................................24 4.13 Pontos de Funo de Teste.....................................................................................24 4.14 Manuteno de Componentes................................................................................25 5. Estimativas de Projetos de Software...............................................................................25 5.1 Contagem Estimativa de Pontos de Funo (CEPF)................................................28 5.2 Estimativa de Esforo de Projetos de Software........................................................32 5.2.1 Distribuio de Esforo por Fase do Projeto..........................................................33 5.3 Estimativa de Prazo de Projetos de Software...........................................................33 5.4 Alocao de Equipe ao Projeto.................................................................................36 5.5 Mtodo para Estimativa de Custo.............................................................................36 5.6 Estimativa de Recursos Computacionais..................................................................37 6. Consideraes para Contagem de Pontos de Funo....................................................37 6.1 Consideraes sobre Mudana de Requisitos..........................................................37 6.2 Consideraes sobre Projetos Cancelados..............................................................38 6.3 Consideraes sobre Reduo de Cronograma ......................................................39 6.4 Fator de Criticidade de Solicitao de Servio..........................................................39 7. Contagem de Pontos de Funo com Mltiplas Mdias e Dados de Cdigo..................40 7.1 Cenrio 1: Mesmos dados apresentados em tela e impressos................................41 7.2 Cenrio 2: Mesmos dados de sada como dados em arquivo e relatrio impresso. 41 7.3 Cenrio 3: Mesmos dados de entrada batch e on-line.............................................42 7.4 Cenrio 4: Mltiplos canais de entrega da mesma funcionalidade...........................42 7.5 Cenrio 5: Relatrios em Mltiplos Formatos...........................................................42 7.6 Dimensionamento de Dados de Cdigo....................................................................42
Roteiro de Mtricas de Software do SISP 5
________________________________________________________________________ 8. Atividades Sem Contagem de Pontos de Funo...........................................................43 9. Processo de Reviso do Roteiro de Contagem..............................................................45 9.1 Reviso para Correo de Inconsistncias e Situaes no previstas....................45 9.2 Reviso para Adoo de Novas Verses do CPM....................................................45 10. Concluso......................................................................................................................45 Referncias Bibliogrficas...................................................................................................46 Anexo I Portaria SLTI/MP N 31, de 29 novembro de 2010.............................................47 Anexo II Formalizao Simples de Requisitos Projetos de Manuteno Pequenos (< 100 PF) ................................................................................................................................48 Anexo III Modelo de Documento de Contagem de Pontos de Funo Projetos de Manuteno Pequenos (< 100 PF).....................................................................................53
ndice de Figuras
Figura 1: Procedimento de Contagem de Pontos de Funo...............................................9 Figura 2: Processo de Estimativas de Projetos de Software [Hazan, 2008].......................26 Figura 3: Modelo Lgico da Anlise de Pontos de Funo.................................................29 Figura 4: Relao entre a Estimativa de Prazo e de Esforo..............................................34
ndice de Tabelas
Tabela 1: Contribuio Funcional dos Tipos Funcionais......................................................11 Tabela 2: Identificao dos Arquivos Lgicos Internos da Aplicao..................................30 Tabela 3: Identificao dos Arquivos de Interface Externa da Aplicao............................30 Tabela 4: Identificao das Entradas Externas da Aplicao..............................................31 Tabela 5: Identificao das Consultas Externas da Aplicao............................................31 Tabela 6: Identificao das Sadas Externas da Aplicao.................................................32 Tabela 7: Distribuio de Esforo por Macro Atividades do Projeto....................................33 Tabela 8: Expoente t por tipo de Projeto..............................................................................35 Tabela 9: Estimativa de Prazo de Projetos menores que 100 PF.......................................35
________________________________________________________________________
1. Introduo
Diversas instituies, pblicas e privadas, tm utilizado a mtrica de Pontos de Funo (PF) nas estimativas e dimensionamento de tamanho funcional de projetos de software devido aos diversos benefcios de utilizao da mtrica, destacando: regras de contagem objetivas e independncia da soluo tecnolgica utilizada. importante ressaltar que a Instruo Normativa IN04 SLTI/MPOG 2010 recomenda o uso de mtricas em solues de software, restringindo o uso da mtrica de esforo homem-hora. Os Acrdos do Tribunal de Contas da Unio (TCU) recomendam a utilizao da mtrica Pontos de Funo No Ajustados em contratos de prestao de servios de desenvolvimento e manuteno de sistemas. O Manual de Prticas de Contagem de Pontos de Funo (CPM 4.3) [IFPUG, 2010], publicado pelo International Function Point Users Group (IFPUG), define as regras de contagem de Pontos de Funo. importante ressaltar que a mtrica de Pontos de Funo foi concebida como uma medida de tamanho funcional para projetos de desenvolvimento e de melhoria (manuteno evolutiva) de software. No entanto, os projetos de software no esto limitados a projetos de desenvolvimento e de melhoria. Desta forma, torna-se essencial a definio de mtricas para dimensionar o tamanho de outros tipos de projetos de manuteno, os quais so itens no mensurveis pelo manual de prtica de contagem do IFPUG. Alm disso, a contagem de Pontos de Funo baseada no projeto lgico da aplicao (logical design) e nas fases iniciais do ciclo de vida do software, o documento de requisitos para a estimativa e elaborao do plano do projeto um documento inicial de requisitos, por exemplo: Documento de Viso ou algum outro tipo de especificao elaborada pelo analista de negcios. Assim, torna-se importante o estabelecimento de mtodos para estimar o tamanho funcional dos projetos de software nas fases iniciais do ciclo de vida. Outro ponto a ser destacado a importncia da definio de mtodos para gerao de estimativas de prazo e custo dos projetos de software a partir do tamanho estimado do projeto. importante frisar que o Manual de Prticas de Contagem (CPM) um documento que se destina a mensurar o tamanho funcional de projetos de software, no tendo por objetivo principal suportar contratos de fbrica de software. Assim, torna-se necessrio criar roteiros complementares, contemplando questes no abordadas pelo manual do IFPUG, mas vivenciadas pelos rgos e entidades do SISP. Este documento encontra-se organizado da seguinte maneira: o captulo 1 apresenta a motivao para a elaborao do documento e a sua organizao; o captulo 2 mostra os objetivos aos quais este documento se prope; o captulo 3 apresenta diretrizes para a Contagem de Pontos de Funo de projetos de desenvolvimento e de melhoria; o captulo 4 define os tipos de projetos de manuteno de software no mensurveis pelo Manual de Prticas de Contagem (CPM), assim como mtricas baseadas em Pontos de Funo para o dimensionamento desses itens no mensurveis; captulo 5 define um processo de estimativas de projetos de software aderente s melhores prticas do CMMI nvel 2; o captulo 6 apresenta algumas consideraes importantes sobre utilizao de mtricas para dimensionar as mudanas de requisitos e reduo de cronograma; o captulo 7 estabelece diretrizes para contagem de Mltiplas Mdias e de Dados de Cdigo
________________________________________________________________________ (Code Data); o captulo 8 apresenta algumas atividades que no devem ser consideradas nas Contagens de Pontos de Funo; o captulo 9 apresenta o processo de reviso deste guia de contagem; finalmente, o captulo 10 conclui o documento, apresentando sugestes para trabalhos futuros.
2. Objetivo
Este documento tem como objetivo principal apresentar um roteiro de mtricas, com base nas regras de contagem de Pontos de Funo do Manual de Prticas de Contagem (CPM 4.3), para todos tipos de projetos de desenvolvimento e de manuteno de sistemas. O propsito promover o uso de mtricas objetivas em contratos de prestao de servios de desenvolvimento e manuteno de sistemas. Alm da contagem de Pontos de Funo, este roteiro apresenta um processo de estimativas com base na mtrica Pontos de Funo, aderente ao modelo CMMI, visando apoiar as organizaes nas estimativas de tamanho, custo, prazo e esforo de seus projetos desenvolvidos internamente ou contratados. O documento foi construdo baseando-se no Roteiro SERPRO de Mtricas para Contratos de Software. Tambm foram consultados outros roteiros de rgos que j utilizam a mtrica Pontos de Funo em contratos de software. A proposta inicial do Roteiro foi submetida ao Grupo de Trabalho de Mtricas do SISP, o qual contribuiu com sugestes de melhoria. Em seguida, as propostas foram analisadas em reunio com especialistas em mtricas de rgos e entidades do SISP para a elaborao da verso 1.0 do Roteiro. A implantao de um processo de medies de software e a mudana do modelo de contratao de software com base na mtrica homem-hora para o novo paradigma de contratao com base na mtrica Pontos de Funo requer uma mudana cultural. Este Roteiro tem como propsito apoiar os rgos e entidades do SISP nessa mudana cultural. Desta forma, duas premissas foram consideradas na elaborao desse Roteiro: Simplicidade: Este Roteiro deve ser simples para incentivar os rgos e entidades do SISP a utilizar a mtrica Pontos de Funo como medida padro no estabelecimento de contratos de fbrica de software. Consistncia: Este Roteiro deve definir critrios objetivos visando prover a consistncia no uso de mtricas em contratos de fbrica de software. Ou seja, dois profissionais ao aplicar o Roteiro no dimensionamento de um projeto de software devem obter o mesmo resultado.
3. Contagem de Pontos de Funo

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

A Contagem de Pontos de Funo se inicia com a anlise da documentao disponvel do projeto em questo, visando a identificao dos requisitos funcionais. O prximo passo o estabelecimento do propsito da contagem, o qual fornece uma resposta para uma questo de negcio a ser resolvida, por exemplo: necessidade de dimensionar um projeto de um novo sistema para a contratao do mesmo. Com base no propsito da contagem so definidos o escopo da contagem, que identifica quais funcionalidades sero includas na contagem de Pontos de Funo, e o tipo de contagem, que pode ser projeto de desenvolvimento, projeto de melhoria ou aplicao instalada. A fronteira da aplicao, que a interface conceitual que delimita o sistema sendo medido e os usurios e as outras aplicaes, deve ser definida com base na viso do usurio, desconsiderando questes de implementao. Em editais para contratao de projetos de manuteno fortemente recomendado a definio das fronteiras de todas as aplicaes a serem contratadas. Os Roteiros de Contagem dos rgos e entidades tambm devem definir as fronteiras das aplicaes implantadas em um anexo e este deve ser atualizado sempre que for implantada uma
________________________________________________________________________ nova aplicao.
3.2 Funes de Dados e Funes Transacionais

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

Caso o tipo de contagem seja projeto de desenvolvimento, o clculo do tamanho funcional definido no CPM conforme a frmula abaixo: PF_Desenvolvimento = PF_INCLUIDO + PF_CONVERSO PF_INCLUDO = Pontos de Funo associados s funcionalidades que faro parte da aplicao. PF_CONVERSO = Pontos de Funo associados s funcionalidades de converso de dados. Exemplos de funes de converso incluem: migrao ou carga inicial de dados para popular as novas tabelas criadas e relatrios associados migrao de dados. Caso o tipo de contagem seja projeto de melhoria, o clculo do tamanho funcional definido no CPM conforme a frmula abaixo: PF_Melhoria = (PF_INCLUIDO + PF_EXCLUIDO + PF_ALTERADO + PF_CONVERSO) PF_INCLUDO = Pontos de Funo associados s novas funcionalidades que faro parte da aplicao. PF_ALTERADO = Pontos de Funo associados s funcionalidades existentes na aplicao que sero alteradas no projeto de manuteno. PF_EXCLUDO = Pontos de Funo associados s funcionalidades existentes na aplicao que sero excludas no projeto de manuteno. PF_CONVERSO = Pontos de Funo associados s funcionalidades de converso de dados dos projetos de melhoria. Exemplos de funes de converso incluem: migrao ou carga inicial de dados para popular as novas tabelas criadas e relatrios associados
________________________________________________________________________ migrao de dados. Observao1: Funo Alterada Uma funo de dados (Arquivo Lgico Interno ou Arquivo de Interface Externa) considerada alterada quando houver incluso ou excluso de tipo de dados. Tambm considerada alterada se algum tipo de dado sofrer mudana de tamanho (nmero de posies) ou tipo de campo (por exemplo: mudana de numrico ou alfanumrico), caso a mudana decorra de alterao de regra de negcio. Uma funo transacional (Entrada Externa, Consulta Externa e Sada Externa) considerada alterada, quando a alterao contemplar: Mudana de tipos de dados; Mudana de arquivos referenciados; Mudana de lgica de processamento.
O CPM 4.3 define lgica de processamento como requisitos especificamente solicitados pelo usurio para completar um processo elementar. Esses requisitos devem incluir as seguintes aes: Validaes so executadas; Frmulas matemticas e clculos so executados; Valores equivalentes so convertidos; Dados so filtrados e selecionados atravs da utilizao de critrios; Condies so analisadas para verificar quais so aplicveis; Um ou mais ALIs so atualizados; Um ou mais ALIs e AIEs so referenciados; Dados ou informaes de controle so recuperados; Dados derivados so criados atravs da transformao de dados existentes, para criar dados adicionais; O comportamento do sistema alterado; Preparar e apresentar informaes para fora da fronteira; Receber dados ou informaes de controle que entram pela fronteira da aplicao; Dados so reordenados. Observao 2: Outros Tipos de Funes Alteradas Este Roteiro considera funo alterada, qualquer mudana em funcionalidades da aplicao devido s mudanas de Regras de Negcio. Por exemplo, uma funcionalidade de cadastro implicava na incluso de um telefone do gerente. Devido a mudanas no processo de negcio, a funcionalidade deve sofrer uma manuteno adaptativa para cadastrar dois telefones do gerente. Desta forma, o Roteiro considera esta funo como uma Entrada Externa alterada, PF_ALTERADO em um Projeto de Melhoria, mesmo que no exista mudana de lgica, mudana de Tipos de Dados e mudana de arquivos
________________________________________________________________________ referenciados. Sero tratadas como manutenes adaptativas apenas as manutenes que implicarem exclusivamente em mudanas em requisitos no funcionais. Se uma mesma funcionalidade tiver mudanas em requisitos funcionais e no funcionais, esta deve ser contada apenas uma vez, como funo alterada em um Projeto de Melhoria. Observao 3: Migrao de Dados PF_CONVERSO As caractersticas do esforo de desenvolvimento ou de melhoria de um sistema so bastante diferentes daquelas do esforo de migrao de dados, exigindo habilidades diferentes e geralmente resultando em equipes distintas para esses dois tipos de tarefas. Devido a isso, fortemente recomendado que os projetos de migrao de dados sejam tratados como objetos separados dos projetos de desenvolvimento e de melhoria e tenham precificao prpria. Dessa forma, este Roteiro recomenda suprimir o PF_CONVERSO das frmulas de desenvolvimento e de melhoria e considerar estas funcionalidades como um projeto de migrao de dados, que ser dimensionado como um novo projeto de desenvolvimento, conforme a seo 4.2 deste documento. O captulo seguinte define mtricas para tratar os itens no mensurveis pelo CPM, ou seja os demais tipos de projetos de manuteno de software.
4. Itens No Mensurveis
O Manual de Prticas de Contagem (CPM) no contempla todos os tipos de projetos de manuteno, apenas o de Melhoria. Este captulo tem como propsito descrever os diversos projetos de manuteno e definir mtricas baseadas nas regras de contagem de Pontos de Funo do CPM para seu dimensionamento. Quanto documentao de projetos de manuteno pequenos (menores que 100 PF), deve-se registrar a solicitao e documentar os requisitos do projeto de manuteno e da aplicao impactada pela demanda, de forma detalhada, visando apoiar a contagem de Pontos de Funo da demanda. importante tambm documentar as estimativas e a contagem de Pontos de Funo. O Anexo II e Anexo III apresentam, respectivamente, um modelo de Documento de Requisitos e um modelo de Documento de Contagem de Pontos de Funo para projetos de manuteno de pequeno porte (menores que 100 PF).
4.1 Projeto de Melhoria

O Projeto de Melhoria (enhancement), tambm denominado de projeto de melhoria funcional ou manuteno evolutiva, est associado s mudanas em requisitos funcionais da aplicao, ou seja, incluso de novas funcionalidades, alterao ou excluso de funcionalidades em aplicaes implantadas. Segundo o padro IEEE Std 1219 [IEEE, 1998], esta manuteno seria um tipo de manuteno adaptativa, definida como: modificao de um produto de software concludo aps a entrega para mant-lo funcionando adequadamente em um ambiente com mudanas. O projeto de melhoria considerado um tipo de projeto de manuteno adaptativa com mudanas em requisitos funcionais da aplicao, ou seja, com funcionalidades includas, alteradas ou excludas na aplicao, segundo o CPM 4.3. Este documento separa o projeto de melhoria, quando as mudanas so associadas aos requisitos funcionais e a manuteno adaptativa quando as mudanas
________________________________________________________________________ esto associadas aos requisitos no funcionais da aplicao. Um projeto de melhoria consiste em demandas de criao de novas funcionalidades (grupos de dados ou processos elementares), demandas de excluso de funcionalidades (grupos de dados ou processos elementares) e demandas de alterao de funcionalidades (grupos de dados ou processos elementares) em aplicaes implantadas em produo. Segue a Frmula de Contagem de Pontos de Funo de Projetos de Melhoria. PF = PF_INCLUIDO + (0,40 x PF_EXCLUIDO) + (FI x PF_ALTERADO) Definies: PF_INCLUDO = Pontos de Funo associados s novas funcionalidades que faro parte da aplicao. PF_ALTERADO = Pontos de Funo associados s funcionalidades existentes na aplicao que sero alteradas no projeto de manuteno. PF_EXCLUDO = Pontos de Funo associados s funcionalidades existentes na aplicao que sero excludas no projeto de manuteno. 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 no desenvolvida ou mantida por meio de um projeto de melhoria pela empresa contratada com documentao atualizada: FI = 75% Funcionalidade de sistema no desenvolvida ou mantida por meio de um projeto de melhoria pela empresa contratada sem documentao atualizada: FI =100%. A contratada deve redocumentar a funcionalidade mantida, gerando a documentao completa da mesma, aderente ao processo de software da contratante. Tendo em vista que o FI equivale incluso de funcionalidade, se houver uma nova demanda de projeto de melhoria na funcionalidade em questo, ser considerado que a contratada desenvolveu a funcionalidade. Observe que o percentual de 100% apenas ser considerado na primeira demanda de projeto de melhoria em cada funcionalidade.
Os percentuais de multiplicao propostos so estimados, podendo ser reajustados conforme avaliao da base histrica dos servios realizados no rgo ou entidade. Os rgos e entidades que j possuem base histrica de projetos concludos com Contagem Detalhada de Pontos de Funo e um processo de desenvolvimento implantado com documentao das aplicaes a serem mantidas, podem utilizar o mtodo de Contagem de Pontos de Funo de Projetos de Melhoria publicado pela NESMA Netherlands Software Metrics Users Association no documento "Function Point Analysis for Software Enhancement Guidelines" [NESMA, 2009]. Para o clculo dos Pontos de Funo Includos, Alterados e Excludos, segue as frmulas estabelecidas abaixo [NESMA, 2009]:
14
________________________________________________________________________ PF_INCLUIDO = QPI; PF_EXCLUIDO = QPE x 0.40; PF_FD_ALTERADO = FD-QPA x FFD, sendo FFD entre 0,25 e 1,00, conforme tabela abaixo (para funes de dados); PF_FT_ALTERADO = FT-QPA x FFT, sendo FFT entre 0,25 e 1,50, conforme tabela abaixo (para funes transacionais); PF_ALTERADO = PF_FD_ALTERADO + PF_FT_ALTERADO. Onde: QPI = Quantidade de Pontos de Funo includos; QPE = Quantidade de Pontos de Funo excludos; PF_FD_ALTERADO = Pontos de Funo alterados para Funes de Dados; PF_FT_ALTERADO = Pontos de Funo alterados para Funes Transacionais; FD-QPA = Quantidade de Pontos de Funo alterados em funes de dados; FT-QPA = Quantidade de Pontos de Funo alterados em funes transacionais; FFD = Fator de impacto de alteraes em funes de dados; FFT = Fator de impacto de alteraes em funes transacionais. O clculo dos fatores de impacto so obtidos atravs dos percentuais de alteraes conforme abaixo: a) Funes de Dados: Percentual de alteraes em funes de dados: PFD = QTDA / QTDT x 100; QTDA = Quantidade de Tipos de Dados Alterados; QTDT = Quantidade de Tipos de Dados Totais na Funo Original. Com o valor obtido em PFD, procura-se na tabela qual o valor do fator de impacto:
Fator de Impacto em Funes de Dados Alteradas (FFD) PFD Fator de Impacto (FFD) Entre 0 e 33% 0,25 Entre 33% e 66% 0,5 Entre 66% e 100% 0,75 Maior que 100% 1
15
________________________________________________________________________ b) Funes Transacionais: Percentual alteraes em funes transacionais (PFT1) = QTDA / QTDT x 100; Percentual alteraes em funes transacionais (PFT2) = QFTRA / QFTRT x 100; QTDA = Quantidade de Tipos de Dados Alterados; QTDT = Quantidade de Tipos de Dados Totais na Funo Original; QARA = Quantidade de Arquivos Referenciados Alterados; QART = Quantidade de Arquivos Referenciados Totais na Funo Original.
Fator de Impacto em Funes Transacionais Alteradas (FFT) PFT2 / PFT1 Entre 0% e 33% Entre 33% e 66% Entre 66% e 100% Maior que 100% Entre 0% e 66% 0,25 0,5 0,75 1 Entre 66% e 100% 0,5 0,75 1 1,25 Maior que 100% 0,75 1 1,25 1,5
Caso FFT seja maior que 1, recomenda-se reconsiderar a melhoria. Observao Importante Embora este mtodo seja utilizado por algumas organizaes, importante ressaltar que em algumas simulaes realizadas com base no mtodo da NESMA os resultados ficaram inconsistentes. Exemplo 1: Suponha uma aplicao com leitura de um Arquivo de Interface Externa com leitura de 2 Tipos de Dados (nome, taxa). Na manuteno, o usurio solicita a leitura de um novo Tipo de Dados, por exemplo uma Sigla. Ento, considerando o mtodo NESMA, a contagem de PF da funo de dados seria a seguinte: Aplicao Implantada : AIE: Taxa RL:1 TD:2 - 5 PF Manuteno: incluso do TD Sigla PFD = QTDA / QTDT x 100 PFD = (1 / 2) X 100 = 50% FFD = 0,5 PF_ALTERADO = 5 x 0,5 = 2,5 PF Exemplo 2: Suponha uma aplicao com leitura de um Arquivo de Interface Externa com leitura de 47 Tipos de Dados. Na manuteno, o usurio solicita a leitura de um novo Tipo de Dados, por exemplo uma Sigla. Ento, considerando o mtodo NESMA, a contagem de PF da funo de dados seria a seguinte: Aplicao Implantada : AIE: Taxa RL:1 TD:47 - 5 PF
16
________________________________________________________________________ Manuteno: incluso do TD Sigla PFD = QTDA / QTDT x 100 PFD = (1 / 47) X 100 = 2,1 % FFD = 0,25 PF_ALTERADO = 5 x 0,25 = 1,25 PF Observe que o esforo para a alterao foi o mesmo ou superior na Aplicao do exemplo 2. No entanto, pelo mtodo da NESMA, a contagem de PF do exemplo 2 a metade (1,25 PFs) da contagem de PF do exemplo 1 (2,5 PFs). Alm disso, nos casos de ausncia de documentao atualizada da Contagem Detalhada de Pontos de Funo da aplicao implantada, a operacionalizao da contagem de Pontos de Funo de projetos de melhoria por esse mtodo pode ser bastante trabalhosa. Assim, considerando a inconsistncia do mtodo, suas dificuldades de operacionalizao e o fato de que na prtica observado que o esforo para alterao de uma funcionalidade depende do conhecimento da equipe sobre a aplicao implantada e da qualidade da sua documentao e do seu cdigo, este Roteiro no recomenda o uso do mtodo sem base histrica de projetos e documentao atualizada e prope o uso dos mesmos fatores de impacto levando em conta a familiaridade com o cdigo e a qualidade da documentao.
4.2 Projetos de Migrao de Dados

Conforme mencionado, este Roteiro recomenda a supresso do PF_CONVERSO das frmulas de contagem de Pontos de Funo de Projetos de Desenvolvimento e de Melhoria e o tratamento das funes de migrao de dados como projetos separados de migrao de dados. Os projetos de migrao de dados devem ser contados como um novo projeto de desenvolvimento de um sistema, contemplando minimamente: os ALIs mantidos pela migrao, Entradas Externas considerando as cargas de dados nos ALIs e caso seja solicitado pelo usurio relatrios gerenciais das cargas, estes sero contados como Sadas Externas. Todas as contagens de PF devem ser realizadas com base nas funcionalidades requisitadas e recebidas pelo usurio.
4.3 Manuteno Corretiva

Mesmo com a execuo de atividades de garantia da qualidade, pode-se identificar defeitos na aplicao entregue. A manuteno corretiva altera o software para correo de defeitos. Encontra-se nesta categoria, as demandas de correo de erros (bugs) em funcionalidades em sistemas em produo. importante destacar que as demandas de manuteno corretiva frequentemente precisam ser atendidas com urgncia. Assim, o grau de criticidade do projeto poder trazer impacto nas estimativas de custo e esforo. O padro IEEE [IEEE,1998] define um tipo de manuteno corretiva, denominado de Manuteno Emergencial como manuteno corretiva no programada executada para manter o sistema em estado operacional.
________________________________________________________________________ Quando o sistema em produo tiver sido desenvolvido pela contratada, a manuteno corretiva ser do tipo Garantia, conforme prazos e demais clusulas do contrato em questo. Caso no exista clusula contratual de Garantia, deve ser considerada a garantia de seis meses, preconizada por lei (Cdigo do Consumidor). Quando o sistema no tiver sido desenvolvido pela contratada, dever ser estimado e calculado o tamanho do projeto de manuteno corretiva. A estimativa e dimensionamento de tamanho de projetos de manuteno corretiva em Pontos de Funo devem levar em considerao a documentao do sistema disponvel e os artefatos a serem mantidos. Seguem as frmulas a serem consideradas: a) Aplicao com documentao completa Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades corrigidas considera 60% do PF_ALTERADO, seguindo os conceitos do CPM 4.3, mostrados na seo 4.1. Deve-se ressaltar que no h necessidade de correo da documentao do sistema, apenas dos artefatos associados correo do cdigo. PF = PF_ALTERADO x 0,60
b) Aplicao sem documentao ou com documentao desatualizada ou documentao incompleta e sem redocumentao de requisitos Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades corrigidas considera 70% do PF_ALTERADO, observando os conceitos do CPM 4.3, apresentados na seo 4.1. PF = PF_ALTERADO x 0,70 c) Aplicao sem documentao ou com documentao desatualizada ou incompleta ou completa e com redocumentao de requisitos Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades corrigidas considera 80% do PF_ALTERADO, seguindo os conceitos do CPM 4.3, apresentados na seo 4.1. Deve-se destacar que alm da correo das funcionalidades em questo e da documentao do projeto de manuteno corretiva realizado, a documentao das funcionalidades deve ser atualizada pela contratada. PF = PF_ALTERADO x 0,80 Em todos os trs itens acima, os percentuais de multiplicao so estimados, podendo ser reajustados conforme avaliao da base histrica dos servios realizados no
________________________________________________________________________ rgo ou entidade.
4.4 Redesenvolvimento de Projetos em outra Plataforma

So considerados nesta categoria, projetos que precisam ser migrados para outra plataforma. Por exemplo, um sistema legado em COBOL precisa ser redesenvolvido em JAVA. Como estes projetos legados, frequentemente, encontram-se sem documentao, ento sero considerados como novos projetos de desenvolvimento. Assim, ser utilizada a frmula de Projetos de Desenvolvimento do CPM 4.3, com a supresso do PF_CONVERSO, considerando que as Migraes de Dados sero tratadas como um projeto a parte, conforme a seo 4.2. PF = PF_NO_AJUSTADO
4.5 Atualizao de Plataforma

So consideradas nesta categoria, demandas para uma aplicao existente ou parte de uma aplicao existente executar em verses mais atuais de browsers (ex: verso atual do Internet Explorer, Mozila, Firefox,...) ou de linguagens de programao (ex: verso mais atual do JAVA ou do Banco de Dados). Tambm so consideradas nesta categoria aplicaes Web desenvolvidas para executar em Internet Explorer que precisam executar tambm em browser em software livre. Nesta categoria foram observadas demandas dos seguintes tipos: a) Atualizao de Plataforma com necessidade de redocumentao de requisitos Nestes casos, a aferio do tamanho em Pontos de Funo da aplicao ou da parte da aplicao que sofreu impacto considera 50% dos PF, seguindo a frmula de projetos de desenvolvimento do CPM 4.3. Caso existam funes de converso de dados, recomenda-se tratar como um projeto separado de migrao de dados, descrito na seo 4.2. Deve-se destacar que alm da adequao s funcionalidades em questo e da documentao do projeto de manuteno adaptativa realizado, a documentao das funcionalidades deve ser atualizada. PF = PF_NO_AJUSTADO x 0,50 b) Atualizao de Plataforma sem necessidade de redocumentao de requisitos Nestes casos, a aferio do tamanho em Pontos de Funo da aplicao ou da parte da aplicao que sofreu impacto considera 40% dos PF, seguindo a frmula de desenvolvimento do CPM 4.3. Caso existam funes de converso de dados, recomendase tratar como um projeto separado de migrao de dados, descrito na seo 4.2. PF = PF_NO_AJUSTADO x 0,40
________________________________________________________________________
Nos dois itens acima, os percentuais de multiplicao so estimados, podendo ser reajustados conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
4.6 Manuteno em Interface

A manuteno em Interface, denominada na literatura manuteno cosmtica, associada s demandas de alteraes de interface, por exemplo, fonte de letra, cores de telas, logotipos, mudana de botes na tela, mudana de posio de campos ou texto na tela. Tambm se enquadram nessa categoria as mudanas de texto em mensagens de erro, validao, aviso, alerta ou concluso de processamento. Nestes casos, a aferio do tamanho em Pontos de Funo das funcionalidades alteradas ser realizada com a aplicao de um fator de modo a considerar 10% da contagem de uma funo transacional de baixa complexidade (3 PF), independentemente da complexidade da funcionalidade alterada. Caso seja utilizada uma mesma tela para duas ou mais funcionalidades, deve ser contada APENAS UMA funo transacional de baixa complexidade. No ser contemplada a redocumentao das funcionalidades da aplicao impactadas pela manuteno nas demandas desta categoria. PF = PF_ALTERADO_FUNO_TRANSACIONAL_COMPLEXIDADE_BAIXA x 0,10 O percentual de multiplicao estimado, podendo ser reajustado conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
4.7 Adaptao de Funcionalidades a Requisitos No Funcionais

So consideradas nesta categoria as demandas de manuteno adaptativa associadas a solicitaes que envolvem aspectos no funcionais, sem alterao em requisitos funcionais. Por exemplo: replicao de funcionalidade (chamar uma consulta existente em outra tela da aplicao); replicao de base de dados ou criao de base temporria para resolver problemas de performance ou segurana; alterao na aplicao para adaptao s alteraes realizadas na interface com rotinas de integrao com outros softwares (ex: alterao em sub-rotinas chamadas por este software). Nesta categoria foram observadas demandas dos seguintes tipos: a) Adaptao de funcionalidades sem necessidade de redocumentao Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades que sofreram impacto deve considerar 70% do PF_ALTERADO, seguindo os conceitos do CPM 4.3, apresentados na seo 4.1. No ser contemplada a documentao das funcionalidades nas demandas desta categoria.
20
________________________________________________________________________ PF = PF_ALTERADO x 0,70 b) Adaptao de funcionalidades com necessidade de redocumentao Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades que sofreram impacto deve considerar 80% do PF_ALTERADO, seguindo os conceitos do CPM 4.3, apresentados na seo 4.1. Deve-se destacar que alm da adequao das funcionalidades em questo e da documentao do projeto de manuteno adaptativa realizado, a documentao das funcionalidades deve ser atualizada. PF = PF_ALTERADO x 0,80 Nos dois itens acima, os percentuais de multiplicao so estimados, podendo ser reajustados conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
4.8 Apurao Especial

So funcionalidades executadas apenas uma vez para: corrigir problemas de dados incorretos na base de dados das aplicaes ou atualizar dados em bases de dados de aplicaes, detalhado no item 4.8.1; gerar um relatrio especfico ou arquivo para o usurio por meio de recuperao de informaes nas bases da aplicao, detalhado no item 4.8.2. A seo 4.8.3 considera os casos de reexecuo de uma apurao especial. Caso a apurao seja de correo de dados, devido a erros de funcionalidades de aplicaes desenvolvidas pela contratada, observar as clusulas contratuais com relao a garantias e prazos de correo. 4.8.1 Apurao Especial Base de Dados Uma apurao especial um projeto que inclui a gerao de procedimentos para atualizao da base de dados. Deve-se destacar que estas funes so executadas apenas uma vez, no fazendo parte da aplicao, visando a correo de dados incorretos na base de dados da aplicao ou atualizao em funo de modificao da estrutura de dados, por exemplo incluso do indicador de matriz sim ou no para um CNPJ. Nestes casos, considera-se a contagem de Pontos de Funo das funcionalidades desenvolvidas. Geralmente, estas funcionalidades so classificadas como Entradas Externas. importante ressaltar que as funes de dados associadas aos dados atualizados no devem ser contadas, considerando que no h mudanas nas estruturas dos Arquivos Lgicos. PF = PF_NO_AJUSTADO
21
________________________________________________________________________ Em alguns casos de Apurao Especial Atualizao de dados, o usurio solicita uma consulta prvia das informaes atualizadas para validao. De fato, uma prtica interessante para evitar informaes errneas na base de produo dos sistemas. Esta Consulta Prvia, classificada como Consulta Externa ou Sada Externa deve ser dimensionada, considerando-se 60% do tamanho da funcionalidade em questo, conforme a frmula abaixo: PF = PF_NO_AJUSTADO x 0,60 4.8.2 Apurao Especial Gerao de Relatrios Uma apurao especial um projeto que inclui a gerao de relatrios em uma ou mais mdias para o usurio. Em alguns casos, so solicitadas extraes de dados e envio dos dados para outros sistemas. Caso neste envio de dados sejam requisitadas atualizaes no sistema de origem, ento estas funes so Sadas Externas, devido atualizao do Arquivo Lgico Interno. Deve-se destacar que estas funes so executadas apenas uma vez, no fazendo parte da aplicao. Nestes casos, considera-se contagem de Pontos de Funo das funcionalidades desenvolvidas. Frequentemente, estas funcionalidades so classificadas como Sadas Externas. Tambm podem ser classificadas como Consultas Externas, caso no possuam clculos ou criao de dados derivados. importante ressaltar que as funes de dados associadas aos dados atualizados no devem ser contadas, considerando que no h mudanas nas estruturas dos Arquivos Lgicos. PF = PF_NO_AJUSTADO 4.8.3 Apurao Especial Reexecuo Em alguns casos a empresa contratante pode ter interesse em executar uma apurao especial mais de uma vez. Nestes casos, ela deve solicitar formalmente contratada o armazenamento do script executado. Desta forma, se for solicitada a reexecuo de uma apurao especial, esta deve ser dimensionada com aplicao de um fator considerando 10% na contagem de Pontos de Funo da apurao especial em questo, da seguinte maneira: PF = PF_NO_AJUSTADO x 0,10 O percentual de multiplicao proposto no item acima estimado, podendo ser reajustado conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
22
________________________________________________________________________
4.9 Atualizao de Dados

Em alguns casos, as demandas de correo de problemas em base de dados esto associadas a atualizaes em um nico registro. Por exemplo, atualizao do nome de um Fornecedor cadastrado erradamente. Nestes casos, a aferio do tamanho em Pontos de Funo deve considerar 10% do PF_ALTERADO de uma Entrada Externa, os Tipos de Dados da Entrada Externa so os campos atualizados. PF = PF_NO_AJUSTADO x 0,10 O percentual de multiplicao estimado, podendo ser reajustado conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
4.10 Manuteno em Pginas Estticas de Intranet, Internet ou Portal

Nesta seo so tratadas manutenes especficas em pginas estticas de Portais, Intranets ou Websites. A demanda consiste na publicao de pginas HTML com contedo esttico. Estas demandas so consideradas como desenvolvimento de consultas. Nestes casos, considera-se 50% dos Pontos de Funo das consultas desenvolvidas. Por exemplo: alterao de pgina de estilo, criao de pgina html, atualizao de menu, atualizao de texto ou banner em pginas html existentes. Cada pgina contada como uma consulta. As consultas so consideradas Consultas Externas Simples (3 PF). PF = PF_NO_AJUSTADO x 0,50 As demandas de criao de Logomarcas ou identidade visual ou outras demandas de criao de Arte, associadas rea de Comunicao Social no so enquadradas nessa categoria. Tais demandas no se referem a contratos de Fbrica de Software, portanto no so consideradas neste Roteiro. recomendado a construo de Portais com ferramentas que apoiem a construo de contedo pelo usurio, por exemplo: Joomla, Zope/Plone, de modo a minimizar as demandas de criao de pginas estticas. O percentual de multiplicao proposto acima estimado, podendo ser reajustado conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
4.11 Manuteno de Documentao de Sistemas Legados

Nesta seo so tratadas demandas de documentao ou atualizao de documentao de sistemas legados. Observe que o desenvolvedor deve realizar uma Engenharia Reversa da aplicao para gerar a documentao. Para este tipo de projeto, caso a demanda seja apenas a documentao de requisitos, devem ser considerados
________________________________________________________________________ 20% dos Pontos de Funo da aplicao em questo, conforme a frmula abaixo. PF = PF_NO_AJUSTADO x 0,20 Caso a demanda seja a gerao de artefatos de documentao de todas as fases do processo de desenvolvimento, deve-se considerar um percentual mais alto de 30% a 50%, dependendo dos artefatos a serem gerados. As premissas utilizadas devem ser conforme clusulas contratuais e documentadas no documento de estimativas do projeto. O percentual de multiplicao proposto acima estimado, podendo ser reajustado conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
4.12 Verificao de Erros

So consideradas verificaes de erro ou anlise e soluo de problemas as demandas referentes a todo comportamento anormal ou indevido apontado pelo cliente nos sistemas aplicativos. Neste caso, a equipe de desenvolvimento da contratada se mobilizar para encontrar as causas do problema ocorrido. Se for constatado erro de sistema, a demanda ser atendida como manuteno corretiva. Entretanto, uma vez no constatado o problema apontado pelo cliente ou o mesmo for decorrente de regras de negcio implementadas ou utilizao incorreta das funcionalidades, ser realizada a aferio do tamanho em Pontos de Funo das funcionalidades verificadas, e ser considerado 25% do tamanho funcional das funcionalidades analisadas, segundo a frmula abaixo: PF = PF_NO_AJUSTADO x 0,25 importante ressaltar que a demanda de verificao de erros deve ser associada a uma funcionalidade especfica. Os casos de sistema fora do ar por conta de problemas em rede ou banco de dados devem ser tratados como servios de suporte e no de Fbrica de Software. Esses servios de suporte no fazem parte do escopo desse Roteiro de mtricas. O percentual de multiplicao proposto acima estimado, podendo ser reajustado conforme avaliao da base histrica dos servios realizados no rgo ou entidade.
4.13 Pontos de Funo de Teste

Muitas vezes, em projetos de manuteno o conjunto de funes de dados e funes transacionais a serem testadas maior do que a quantidade de funes a serem implementadas, isto , alm das funcionalidades que so afetadas diretamente pelo projeto de manuteno, outras precisam ser testadas [NESMA, 2009]. O tamanho das funes a serem testadas deve ser aferido em Pontos de Funo de Teste (PFT). No considerar as funcionalidades includas, alteradas ou excludas do projeto de manuteno na contagem de Pontos de Funo de Teste.
________________________________________________________________________ A contagem de PFT deve considerar o seguinte [NESMA, 2009]: Determinar o tamanho em Pontos de Funo de cada funo de dados ou transacional envolvida no teste. Calcular o tamanho em Pontos de Funo de todas as funes de dados ou transacionais envolvidas no teste.
A converso do PFT em Ponto de Funo deve ser feita de acordo com a frmula abaixo: PF = PFT x 0,20 importante ressaltar que as funes testadas consideradas no PFT devem ser documentadas. Observe que estas funes faro parte do escopo do projeto de manuteno.
4.14 Manuteno de Componentes

Em alguns casos so demandadas manutenes em componentes especficos de uma aplicao e estes so reusados por vrias funcionalidades da aplicao. Por exemplo, suponha uma mudana em uma rotina de validao de um CPF usada em vrias funcionalidades de cadastro. Se considerarmos o mtodo de contagem de projetos de melhoria do CPM, seriam contadas todas as funcionalidades impactadas por esta mudana. No entanto, este Roteiro prope que o componente, o qual dever ser testado, seja considerado um processo elementar independente e contado como uma funcionalidade. Alm disso, as funcionalidades da aplicao que necessitem de teste devem ser requisitadas pela contratante e dimensionadas por meio da mtrica Pontos de Funo de Testes proposta na seo 4.13. PF = PF_NO_AJUSTADO
5. Estimativas de Projetos de Software

Este captulo tem como propsito descrever um processo de estimativas de projetos de software aderente rea de processo de Planejamento de Projeto do CMMI. Nesse contexto, so apresentados: o mtodo Contagem Estimativa de Pontos de Funo (CEPF) para estimar o tamanho dos projetos de software em PF, o modelo simplificado de estimativas para estimar o esforo dos projetos em homem-hora (HH) e a frmula de Capers Jones para estimar os prazos dos projetos. A Figura 2 ilustra um processo de Estimativas de Projetos de Software, descrito nos pargrafos seguintes.
25
________________________________________________________________________
Coletar e Analisar Requisitos Iniciais
Estimar Tamanho
Banco de Dados Histrico de Projetos da organizao
Estimar Cronograma
Estimar Custo Estimar Recursos Computacionais Crticos Analisar e Aprovar Estimativas Acompanhar Estimativas Calibrar e Melhorar o Processo
Documentar Estimativas e Premissas Documentar Acompanhamento Documentar Resultados finais e Lies Aprendidas
Figura 2: Processo de Estimativas de Projetos de Software [Hazan, 2008] O principal insumo (artefato de entrada) para um processo de estimativas o documento de requisitos. Como as estimativas devem ser realizadas no incio do processo de desenvolvimento de software, ento, o artefato utilizado um documento inicial de requisitos, por exemplo: Documento de Viso ou Formalizao Simples de Requisitos. O estimador deve analisar os requisitos para garantir a qualidade e ento estimar o tamanho do projeto de software. O prximo passo a derivao das estimativas de esforo, prazo (cronograma), custo (oramento) com base na estimativa de tamanho e nos dados histricos de projetos concludos da organizao, assim como o estabelecimento da estimativa de recursos computacionais crticos e dos recursos da equipe a ser alocada ao projeto. Neste ponto, as principais estimativas foram geradas e precisam ser documentadas. As premissas e suposies utilizadas na gerao das estimativas, dentre outras: complexidade do projeto, plataforma de desenvolvimento, tipo do projeto, percentual de evoluo de requisitos, tambm devem ser documentadas [Hazan, 2008]. A realizao das estimativas por um analista de mtricas que no atue na equipe
Reestimar ,conforme necessidade
Estimar Esforo
________________________________________________________________________ do projeto, constitui uma prtica recomendada. O analista de mtricas deve analisar tambm a consistncia da documentao utilizada na estimativa. No decorrer do processo de desenvolvimento, as estimativas devem ser acompanhadas conforme o refinamento dos requisitos. O projeto deve ser reestimado aps a fase de requisitos, quando for gerada a especificao de casos de uso, e sempre que ocorrerem mudanas significativas nos requisitos funcionais ou no funcionais. Quando o projeto concludo, deve-se aferir e documentar o tamanho, prazo, custo, esforo e recursos realizados, assim como outros atributos relevantes do projeto, visando a coleta de dados para a melhoria do processo de estimativas. As lies aprendidas tambm devem ser documentadas [Hazan, 2008]. Portanto, para os contratos de projetos de software, baseados na mtrica Pontos de Funo, as estimativas devem ser realizadas em trs marcos do processo de desenvolvimento de software, a saber:
Estimativa inicial: realizada aps o fechamento do escopo do projeto. Geralmente baseada em um documento inicial de requisitos, por exemplo Documento de Viso. Constitui uma boa prtica a previso de evoluo de requisitos, especialmente em projetos de desenvolvimento de mdio ou grande porte. Nessa etapa importante destacar os seguintes conceitos na rea de estimativas: Uma Estimativa obtida por meio de uma atividade tcnica, utilizando mtodos de estimativas. No deve sofrer interferncias polticas. A Meta um desejo, em funo de necessidades de negcio, estabelecida politicamente. Um Compromisso um acordo da gerncia com as equipes tcnicas para alcanar uma meta [Parthasarathy,2007]. Em um cenrio ideal os resultados da estimativa atendem as metas de negcio. Quando este cenrio no real, fundamental a reduo de escopo do projeto, de modo que a meta se adapte aos resultados da estimativa. Contagem de Pontos de Funo de Referncia: realizada aps o aceite dos requisitos. Geralmente, leva em considerao a Especificao dos Casos de Uso e Regras de Negcio da aplicao. Contagem de Pontos de Funo Final: realizada aps a homologao da aplicao. Esta contagem leva em considerao as funcionalidades efetivamente entregues para o usurio pela aplicao.
Para fins de faturamento, que realizado durante o desenvolvimento, deve-se considerar a Contagem de Referncia e posteriormente considerar os ajustes no faturamento aps a Contagem Final. importante ressaltar que as mudanas de requisitos tambm sero consideradas no tamanho projeto a ser faturado, conforme descrito no captulo 6. Alm disso, se estas mudanas forem significativas, maiores que a evoluo de requisitos (scope creep) prevista na estimativa inicial, o prazo do projeto deve ser reestimado. Toda mudana de requisito deve passar por uma anlise de impacto entre contratante e contratada. As sees seguintes apresentam os mtodos de estimativas de tamanho, prazo, custo e esforo a serem utilizados nos projetos de software em contratos.
27
________________________________________________________________________
5.1 Contagem Estimativa de Pontos de Funo (CEPF)

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

Usurios
Identificao dos itens da APF
Aplicao Transaes (EEs, CEs, SEs) Dados Internos (ALIs)
Pontos de Funo (nmeros)
Mapeando em nmeros
Outras Aplicaes Dados Externos (AIEs)
Figura 3: Modelo Lgico da Anlise de Pontos de Funo Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para classific-lo em Entrada Externa, Consulta Externa ou Sada Externa. Adicionalmente, o estimador deve descobrir os dados associados ao processo elementar, visando a determinao da complexidade funcional da funo identificada. Caso no seja possvel a identificao da complexidade da funcionalidade em questo, recomenda-se a utilizao da complexidade Mdia. Na anlise do processo elementar tambm so identificados os grupos de dados lgicos da aplicao, que so classificados como Arquivos Lgicos Internos ou Arquivos de Interface Externa. Caso no seja possvel a identificao da complexidade da funo de dados em questo, recomenda-se a utilizao da complexidade Simples. importante ressaltar que se o estimador identificar mais de um Registro Lgico no Arquivo Lgico Interno, recomenda-se utilizar a complexidade Mdia. A seguir so apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicao nos tipos funcionais da APF. As necessidades e funcionalidades especificadas para o projeto, contidas no documento inicial de requisitos, devem ser enquadradas em uma das seguintes tabelas: Tabela 2 - Contagem dos Arquivos Lgicos Internos (ALIs): Banco de Dados Lgico da Aplicao (tabelas e arquivos mantidos pela aplicao). Consideraes: Identifique os grupos de dados lgicos de aplicao nos modelos de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos documentos de requisitos (Documento de Viso, Relao de Casos de Uso, etc.). No considere arquivos fsicos, arquivos de ndices, arquivos de trabalho e tabelas de relacionamento sem atributos prprios (tabelas que existem para quebrar o relacionamento m x n e apenas transportam as chaves estrangeiras). As entidades fracas tambm no so consideradas um ALI. Se possvel, tente descobrir os atributos lgicos, campos reconhecidos pelo usurio, e subgrupos de dados existentes para obter a
________________________________________________________________________ complexidade funcional, segundo as regras de contagem do CPM. Caso no seja possvel, a experincia tem mostrado que a maioria dos ALIs dos sistemas so de complexidade Simples. N ALIs Simples: N ALIs Mdio: N ALIs Complexo: Total PF: Tabela 2: Identificao dos Arquivos Lgicos Internos da Aplicao Tabela 3 - Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de outras Aplicaes, apenas referenciados pela aplicao que est sendo estimada (tabelas e arquivos mantidos por outra aplicao). Consideraes: Identifique os grupos de dados lgicos de outras aplicaes referenciados pela aplicao que est sendo estimada. Frequentemente, o referenciamento de dados ocorre para a validao de informaes em cadastros ou consultas. Algumas vezes, relatrios ou consultas referenciam dados externos de outras aplicaes, tambm considerados AIEs. No so considerados arquivos fsicos, arquivos de ndice, arquivos de trabalho, tabelas de relacionamento sem atributos prprios e entidades fracas. Geralmente, os AIEs dos sistemas possuem a classificao de complexidade Simples, porque so considerados para a determinao da complexidade funcional do AIE apenas os atributos referenciados pela aplicao que est sendo contada. N AIEs Simples: N AIEs Mdio: N AIEs Complexo: Total PF: Tabela 3: Identificao dos Arquivos de Interface Externa da Aplicao Tabela 4 - Contagem de Entradas Externas (EEs): Funcionalidades que mantm os Arquivos Lgicos Internos (ALIs) ou alteram o comportamento da aplicao. Consideraes: Identifique as funcionalidades de manuteno de dados. Conte separadamente a incluso, alterao e excluso de dados, isto , cada funo independente de incluso ou alterao ou excluso deve ser contada separadamente. A aplicao possui funes de entrada de dados que alteram o comportamento dela, por exemplo: processamentos batch, ou processamento de informaes de controle? Caso positivo, estas funes tambm devem ser identificadas como Entradas Externas. Se voc no possui conhecimento sobre o processo elementar (funcionalidade
X 7 PF X 10 PF X 15 PF
________________________________________________________________________ analisada), considere as Entradas Externas identificadas com complexidade Mdia. N EEs Simples: N EEs Mdia: N EEs Complexa: Total PF: Tabela 4: Identificao das Entradas Externas da Aplicao Tabela 5 - Contagem de Consultas Externas (CEs): funcionalidades que apresentam informaes para o usurio sem a utilizao de clculos ou algoritmos. So os processos elementares do tipo l - imprime, l - apresenta dados, incluindo consultas, relatrios, gerao de arquivos pdf, xls, downloads, entre outros. Consideraes: Voc est desenvolvendo uma funo para apresentar informaes para o usurio: uma consulta, relatrio, listbox, download, gerao de um arquivo, gerao de arquivo pdf, xls? Esta funo no possui clculos ou algoritmos para derivao dos dados referenciados nem altera um Arquivo Lgico Interno, nem muda o comportamento do sistema? Caso positivo, estas funes devem ser identificadas como Consultas Externas. Se voc no possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Consultas Externas com complexidade Mdia. N CEs Simples: N CEs Mdia: N CEs Complexa: Total PF: Tabela 5: Identificao das Consultas Externas da Aplicao Tabela 6 - Contagem de Sadas Externas (SEs): Funcionalidades que apresentam informaes para o usurio com utilizao de clculos ou algoritmos para derivao de dados ou atualizao de Arquivos Lgicos Internos ou mudana de comportamento da aplicao. So as consultas ou relatrios com totalizao de dados, relatrios estatsticos, grficos, gerao de arquivos com atualizao log, downloads com clculo de percentual, entre outros. Consideraes: Voc est desenvolvendo uma funcionalidade para apresentar informaes para o usurio: uma consulta ou relatrio com totalizao de dados, etiquetas de cdigo de barras, grficos, relatrios estatsticos, download com percentual calculado, gerao de arquivo com atualizao de log? Caso positivo, estas funes devem ser identificadas como Sadas Externas. Observe que esta funo deve ter clculos ou algoritmos para processar os dados referenciados nos arquivos lgicos ou atualizar campos (normalmente indicadores) nos arquivos ou mudar o comportamento da aplicao. Caso no haja conhecimento da aplicao de APF ou sobre o processo
________________________________________________________________________ elementar (funcionalidade analisada), considere as Sadas Externas com complexidade Mdia. N SEs Simples: N SEs Mdia: N SEs Complexa: Total PF: Tabela 6: Identificao das Sadas Externas da Aplicao A Estimativa de tamanho do projeto em PF deve ser gerada totalizando-se os PF obtidos nas Tabelas 2, 3, 4, 5 e 6. A frmula de contagem ou de estimativa de Pontos de Funo para Projetos de Desenvolvimento a seguinte: PF_DESENVOLVIMENTO = PF_NO_AJUSTADO Observao: O PF_CONVERSO foi suprimido da frmula. Nesse Roteiro recomendado que o projeto de migrao seja tratado como um novo projeto de desenvolvimento. Portanto, este deve ser estimado separadamente. X 4 PF X 5 PF X 7 PF
5.2 Estimativa de Esforo de Projetos de Software

Uma vez que o tamanho do projeto est estimado em Pontos de Funo, o prximo passo estimar o esforo de desenvolvimento do projeto, bem como sua distribuio pelas fases do ciclo de vida do desenvolvimento do software. A Engenharia de Software possui vrios modelos para estimar esforo de projetos de software, baseados em Pontos de Funo, sendo o Modelo Simplificado de Estimativas [Vazquez, 2010] e o Modelo COCOMO II [Boehm, 2009] os mais utilizados. Neste Roteiro adotado o modelo Simplificado de Estimativas. O Modelo Simplificado de Estimativas consiste em obter um ndice de produtividade em horas/PF para o projeto especfico em questo, e ento multiplicar o tamanho em PF do Projeto pelo ndice de produtividade, conforme a frmula [Vazquez, 2010]: Esforo (horas) = Tamanho (PF) x ndice de Produtividade (HH/PF) O ndice de produtividade depende de diversos atributos dos projetos, dentre outros: plataforma tecnolgica, complexidade do domnio, segurana, desempenho, usabilidade, tamanho do projeto, tipo de manuteno, desenvolvimento de componentes.
32
________________________________________________________________________ Cada rgo ou entidade dever possuir sua prpria tabela de produtividade para cada linguagem, considerando-se sempre dados histricos dos projetos j realizados. 5.2.1 Distribuio de Esforo por Fase do Projeto O prximo passo a definio da distribuio de esforo pelas macro atividades do projeto, visando definir o valor agregado ao projeto aps cada fase do ciclo de vida (Tabela 7).
Macro Atividades do Processo de Desenvolvimento de Software Engenharia de Requisitos Design, Arquitetura Implementao Testes Homologao Implantao Percentual de esforo (%) 25% 15% 40% 10% 5% 5%
Tabela 7: Distribuio de Esforo por Macro Atividades do Projeto A Tabela 7 uma sugesto de distribuio de esforo em projetos tpicos, no entanto, em se tratando de um projeto com caractersticas especficas, estes percentuais devem ser alterados para o projeto em questo. Nesses casos, o estimador deve justificar, com observaes no documento de estimativas, as premissas utilizadas para a alterao dos percentuais. Os contratos estabelecidos devem determinar o processo de desenvolvimento a ser seguido com percentual de esforo por fases.
5.3 Estimativa de Prazo de Projetos de Software

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

Sistema Comum Mainframe (desenvolvimento de sistema com alto grau de reuso ou manuteno evolutiva) Sistema Comum WEB ou Cliente Servidor Sistema OO (se o projeto OO no for novidade para equipe, no tiver o desenvolvimento de componentes reusveis, considerar sistema comum) Sistema Cliente/Servidor (com alta complexidade arquitetural e integrao com outros sistemas) Sistemas Gerenciais complexos com muitas integraes, Datawarehousing, Geoprocessamento, Workflow Software Bsico, Frameworks, Sistemas Comerciais
Expoente t
0,32 a 0,33 0,34 a 0,35 0,36
0,37 0,39 0,40
Tabela 8: Expoente t por tipo de Projeto importante destacar que o mtodo s funciona para projetos com mais de 100 PF. Caso o projeto seja menor, o prazo deve ser obtido por meio da definio de prazo mximo por tamanho funcional com base em dados histricos do rgo, conforme a Tabela 9. 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 mximo (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, desde a fase de requisitos at a implantao. Assim, caso a estimativa tenha sido realizada ao final da fase de requisitos, descontar do prazo restante o tempo gasto com a fase de requisitos. Caso seja necessrio receber o projeto em um prazo menor que o calculado, recomenda-se propor um processo de desenvolvimento incremental, priorizando funcionalidades em cada iterao de acordo com a necessidade dele. Caso, ainda assim, a estimativa no atenda s necessidades do cliente, ento pode-se reduzir o Td em at 25%, observando-se a Regio Impossvel. No entanto, quanto mais perto da Regio
________________________________________________________________________ Impossvel, o esforo e o custo do projeto aumentam de maneira exponencial. Assim, de um modo geral, a reduo de prazo de 10% implica no aumento de esforo de 20%; a reduo de prazo de 20% implica no aumento de esforo de 50%; a reduo de prazo de 25% implica em um aumento de esforo de 70%. No recomendada a reduo de prazo em mais de 20%. Os percentuais de aumento de esforo so estimados, podendo ser reajustados conforme avaliao da base histrica dos servios realizados no rgo ou entidade. Na seo seguinte abordada a questo da distribuio de esforo e alocao de pessoas ao projeto em questo.
5.4 Alocao de Equipe ao Projeto

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

A estimativa de custo do projeto deve levar em considerao o custo de um ponto de funo. A contratada j dever considerar o custo da hora de todos os profissionais envolvidos no desenvolvimento da soluo de software. O clculo do custo do projeto (CP) ser ento da seguinte forma: CP = QPF x CPF Onde: QPF = Tamanho do Projeto em PF CPF = Custo para implementar um Ponto de Funo na plataforma em questo
36
________________________________________________________________________
5.6 Estimativa de Recursos Computacionais

A Estimativa de Recursos Computacionais tambm deve ser considerada, esta constitui um componente importante para as estimativas de custos dos projetos. Um recurso computacional um hardware que se precisa adquirir; ou que se possui, mas precisa-se configurar. Exemplos de recursos computacionais incluem, dentre outros: espao em disco para o sistema entrar em produo, um servidor especfico para teste ou homologao do sistema. Devem ser registradas as seguintes informaes associadas aos recursos computacionais crticos:

Nome do Recurso Computacional: [considere exclusivamente hardware: micro, perifrico, expanso de memria, rea em disco, banda de rede, etc] Descrio: Responsvel pela Disponibilizao: Data Limite: Parmetros: [caractersticas do recurso: quantidade, perfil, configurao, etc] Tipo do Recurso: [D: recurso para ambiente de Desenvolvimento; P: recurso para ambiente de Produo; H: recurso para ambiente de Homologao] Custo (Opcional): [Custo do recurso computacional. No considerar custos de processamento ou custos operacionais de produo.]
Caso o projeto a ser desenvolvido no possua nenhum recurso computacional crtico, deve ser registrado no documento de estimativas que o projeto no possui nenhum recurso computacional crtico.
6. Consideraes para Contagem de Pontos de Funo

Esta seo apresenta consideraes especiais sobre o dimensionamento em Pontos de Funo de mudana de requisitos, projetos cancelados, reduo de cronograma e fator criticidade.
6.1 Consideraes sobre Mudana de Requisitos

Em projetos de desenvolvimento e manuteno de software bastante comum as mudanas de requisitos no decorrer do projeto, conforme o usurio e o desenvolvedor adquirem mais conhecimento sobre o negcio [Sommerville, 2007]. O CPM denomina este fenmeno de Scope Creep. Como os requisitos no podem ser congelados, ento temos que gerenci-los de forma efetiva. Nas estimativas iniciais de tamanho de projetos de desenvolvimento, aps a fase de especificao, considerando-se o documento de viso inicial do projeto, recomenda-se utilizar um percentual para evoluo de requisitos de 30% a 40%. Este percentual sugerido, ficando a critrio da instituio estabelec-lo contratualmente. Nas estimativas, aps a fase de requisitos, utilizando-se como insumo as especificaes de casos de uso, deve-se considerar um percentual de 20% a 30%. Por exemplo, suponha que aps a anlise do Documento de Viso de um Projeto,
________________________________________________________________________ aplicando-se a CEPF, foi obtido o tamanho de 200 PF, ento o tamanho estimado do projeto considerado de 270 PF (200 + 35%), utilizando-se a premissa de evoluo de requisitos em 35%. Esta premissa deve ser documentada. Uma mudana de requisito gera retrabalho da equipe de desenvolvimento, aumentando assim o esforo e o custo do projeto. Por exemplo, suponha um relatrio de clientes em que no final da fase de implementao foi solicitada a exibio de uma nova informao. A equipe de desenvolvimento ter um retrabalho de vrias fases do ciclo de vida. Para tratar o dimensionamento das mudanas de requisitos torna-se importante definir a distribuio de esforo pelas macroatividades do projeto, visando definir o valor agregado ao projeto aps cada fase do ciclo de vida. A Tabela 7 estabelece os percentuais por atividade de forma a permitir a contagem de mudana conforme o estgio do projeto. Esta distribuio percentual de esforo deve ser definida no contrato de software. Por exemplo, suponha um relatrio de clientes em que no final da fase de implementao foi solicitada a exibio de uma nova informao. A equipe de desenvolvimento ter um retrabalho de vrias fases do ciclo de vida. Assim, o tamanho dessa mudana deve ser calculado da seguinte maneira: -Tamanho do relatrio de clientes (original) SE M 5 PF -Tamanho do relatrio de clientes (alterado) SE M 5 PF O requisito alterado ser considerado 100% do PF, supondo que este ser entregue ao cliente sem passar por novas alteraes. Para o requisito original ser considerado o seguinte: Engenharia de Requisitos 25% Design, Arquitetura 15% Implementao 40% Assim, o tamanho da mudana de 4 PF (5 PF x 80% = 4 PF).
6.2 Consideraes sobre Projetos Cancelados

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

As estimativas de prazo no so lineares com o tamanho do projeto, assim pretende-se pesquisar mais sobre o melhor tempo de desenvolvimento (onde h uma melhor relao custo x benefcio de alocao de recursos e menor prazo de desenvolvimento), dado o tamanho de um projeto especfico. Jones [Jones, 2007] prope uma frmula para o clculo do melhor tempo de desenvolvimento, descrita na seo 5.3. Alguns projetos devido legislao e a outros fatores externos j se iniciam com um prazo imposto. Se este prazo for igual ou superior ao prazo calculado pela Frmula de Capers Jones (expoente t) ou em caso de projetos pequenos (menores que 100 PF) a um prazo calculado considerando o trabalho da equipe de 8 horas/dia nos dias teis, ento este tratado como um projeto normal. No entanto, se o projeto tiver um prazo imposto inferior ao prazo calculado, ento deve-se considerar o seguinte: Reduo de prazo de 10%: aumento de esforo de 20% (projetos urgentes) Reduo de prazo de 20%: aumento de esforo de 50% (projetos crticos) Reduo de prazo de 25%: aumento de esforo de 70% (projetos de alta criticidade)
Deve-se ressaltar que no possvel uma reduo de prazo maior que 25%, devido aos clculos de Regio Impossvel e ainda, conforme nos aproximamos da Regio Impossvel, o esforo e o custo do projeto aumentam de maneira exponencial. Como os riscos da reduo de cronograma tambm so altos, no recomendada a reduo de cronograma. Deve-se tentar priorizar funcionalidades trabalhando com o ciclo de vida incremental. Caso o contrato seja baseado em preo por Pontos de Funo, este aumento de esforo ser refletido na contagem de PF. Assim, um aumento de esforo de 20% implica em aumento de 20% no custo de PF; aumento de esforo de 50% implica em aumento de 50% no custo de PF; o aumento de esforo de 70% implica em aumento de 70% no custo de PF.
6.4 Fator de Criticidade de Solicitao de Servio

Em funo da criticidade e da necessidade de alocao de recursos extras para atendimento da demanda no prazo estipulado pelo cliente, ser adotado um Fator de Criticidade de 1,35 (um vrgula trinta e cinco), que dever ser multiplicado pelo tamanho funcional da demanda considerada crtica, de modo a remunerar adequadamente o aumento do esforo de atendimento. Este fator considerado para demandas que devem ser atendidas em finais de semana, feriados e fora do horrio comercial. Entende-se como horrio comercial o horrio de 08:00 s 18:00 h, horrio de Braslia.
39
________________________________________________________________________
7. Contagem de Pontos de Funo com Mltiplas Mdias e Dados de

Cdigo
Este captulo tem como propsito apresentar as diretrizes de Contagem de Pontos de Funo em relao ao tema Mltiplas Mdias. Esta abordagem reconhecida pelo IFPUG. As definies apresentadas tm como base o artigo Considerations for Counting with Multiple Midia Release 1.0 publicado pelo IFPUG [IFPUG, 2009]. Tambm abordado neste captulo algumas diretrizes para a mensurao de Dados de Cdigo ou Code Data. Considerando-se a contagem de PF de funcionalidades entregues em mais de uma midia, a aplicao das regras de contagem de Pontos de Funo definidas no CPM tem levado a duas abordagens alternativas, a saber: single instance e multiple instance. A abordagem single instance considera que a entrega de uma funo transacional em mltiplas mdias no deve ser utilizada na identificao da unicidade da funo. A abordagem multiple instance leva em considerao que a mdia utilizada na entrega da funcionalidade uma caracterstica de identificao da unicidade da funo. Assim, funcionalidades nicas so reconhecidas no contexto da mdia na qual elas so requisitadas para operar. importante enfatizar que o IFPUG reconhece ambas abordagens, single instance e multiple instance, para a aplicao das regras definidas no CPM. A determinao da contagem de PF seguindo a abordagem multiple instance ou single instance depende da avaliao da Coordenao de Mtricas da organizao. As estimativas e contagens de PF abordadas neste documento sero baseadas em multiple instance, com exceo dos casos de consultas em .pdf, .doc, .xls e consultas idnticas em tela e papel, que sero consideradas uma nica funcionalidade. A seguir so descritos os termos comuns definidos pelo IFPUG [IFPUG, 2009]:

Canal: tambm refere-se a mdia. Mltiplos canais sinnimo de mltiplas midias. Mdia: descreve a maneira que os dados ou informaes se movimentam para dentro e para fora de uma fronteira de aplicao, por exemplo, apresentao de dados em tela, impressora, arquivo, voz. Este termo utilizado para incluir, dentre outros: diferentes plataformas tcnicas e formatos de arquivos como diferentes mdias. Mltiplas Mdias: quando a mesma funcionalidade entregue em mais de uma mdia. Frequentemente, somente uma mdia requisitada para um usurio especfico em um determinado momento, por exemplo consulta de extrato bancrio via internet como oposto a consulta de extrato bancrio via terminal do banco. Multi-Mdia: quando mais de uma mdia necessria para entregar a funo, por exemplo, uma nova notcia publicada na Internet que apresentada em vdeo e texto. Observe que a notcia completa s apresentada para o usurio se ele ler o texto e assistir o vdeo. Abordagem Single Instance: esta abordagem no reconhece que a mdia utilizada na entrega da funo transacional uma caracterstica de diferenciao na identificao da unicidade da funo transacional. Se duas funes entregam a mesma funcionalidade usando mdias diferentes, elas so consideradas a mesma
40
________________________________________________________________________ funcionalidade em uma contagem de Pontos de Funo.
Abordagem Multiple Instance: esta abordagem especifica que o tamanho funcional obtido no contexto do objetivo da contagem, permitindo uma funo de negcio ser reconhecida no contexto das mdias que so requisitadas para a funcionalidade ser entregue. A abordagem multiple instance reconhece que a mdia para entrega constitui uma caracterstica de diferenciao na identificao da unicidade da funo transacional.
Os cenrios descritos nas sees seguintes no representam uma lista completa de situaes de mltiplas mdias. O entendimento destes exemplos facilitar o entendimento de outros cenrios envolvendo mltiplas mdias. Este Roteiro deve ser atualizado considerando a publicao de novas diretrizes do IFPUG e novos cenrios que emergiro nas contagens de PF dos projetos dos rgos e entidades do SISP.
7.1 Cenrio 1: Mesmos dados apresentados em tela e impressos

Neste cenrio, uma aplicao apresenta uma informao em uma consulta em tela. A mesma informao pode ser impressa caso requisitado pelo usurio na tela em questo. Nesses casos, sugere-se a abordagem single instance, considerando que dados idnticos sendo apresentados em tela e relatrio impresso devem ser contados como uma nica funo. Caso as lgicas de processamento da consulta em tela e do relatrio em papel sejam distintas, o processo elementar no nico e portanto a funcionalidade ser contada duas vezes. Observe que a abordagem multiple instance considera que a contagem de PF de dados idnticos sendo apresentados usando mais de um tipo de mdia deve incluir toda instncia da funo em cada tipo de mdia. Neste exemplo, duas funes so contadas apresentao de dados em tela; apresentao de dados impressos.
7.2 Cenrio 2: Mesmos dados de sada como dados em arquivo e relatrio impresso
Uma aplicao grava dados em um arquivo de sada e imprime um relatrio com informaes idnticas s gravadas no arquivo. Nesses casos, sugere-se que se utilize a abordagem single instance considerando que os dados impressos e os dados apresentados no arquivo de sada sejam idnticos e que a ferramenta de desenvolvimento apoie a gerao dessas mltiplas sadas. Assim, apenas uma funcionalidade ser includa na contagem de Pontos de Funo. Caso as lgicas de processamento da gerao do arquivo de sada e do relatrio em papel sejam distintas, o processo elementar no nico e portanto a funcionalidade ser contada duas vezes. E ainda, se a gerao das mltiplas sadas no seguirem o padro da ferramenta de desenvolvimento e tiverem que ser customizadas para o cliente, ento ser utilizada a abordagem multiple instance. Observe que a abordagem multiple instance considera que dados idnticos esto sendo entregues em mais de um tipo de mdia e a contagem de PF incluir todas as instncias de tipos de mdia. Neste cenrio, duas funes so contadas gerao de
________________________________________________________________________ arquivo e apresentao dos dados impressos.
7.3 Cenrio 3: Mesmos dados de entrada batch e on-line

Uma informao pode ser carregada na aplicao por meio de dois mtodos: arquivo batch e entrada on-line. O processamento do arquivo batch executa validaes durante o processamento. O processamento on-line tambm executa validaes das informaes. A abordagem single instance conta apenas uma funcionalidade. 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. Geralmente, a lgica de processamento utilizada nas validaes em modo batch diferente da lgica de processamento das validaes nas entradas de dados on-line.
7.4 Cenrio 4: Mltiplos canais de entrega da mesma funcionalidade

Uma funcionalidade deve ser disponibilizada em mltiplos canais, por exemplo consulta de dados em pgina Web e consulta de dados no telefone celular. A abordagem single instance conta apenas uma funcionalidade. Geralmente se utiliza a abordagem multiple instance que conta duas funcionalidades: a consulta de dados na Web e a consulta de dados via celular. Considera-se que a funcionalidade desenvolvida duas vezes para os dois canais. Algumas vezes, so at projetos de desenvolvimento distintos, um projeto relativo ao sistema Web e outro para o sistema via celular. Lembrando que caso o projeto claro o suficiente para dizer que o desenvolvimento o mesmo, poder ser utilizada a abordagem single instance.
7.5 Cenrio 5: Relatrios em Mltiplos Formatos

Um relatrio deve ser entregue em diferentes formatos, por exemplo em um arquivo html e um formato de valores separados por vrgula. Nestes casos, conforme sugerido na abordagem multiple instance, considera-se a ferramenta utilizada na gerao dos relatrios. Se a equipe de desenvolvimento precisar desenvolver o relatrio nos dois formatos na ferramenta em questo, sero contadas duas funcionalidades, porque a lgica de processamento de anlise de condies para verificar quais so aplicveis identificada. No entanto, se a ferramenta de desenvolvimento suportar um gerador de relatrios que o usurio visualize o relatrio em tela e o gerador permita ao usurio imprimir o relatrio, salvar em html ou salvar no formato de valores separados por vrgula, ento se contar apenas uma vez, observando que a funcionalidade ser da ferramenta e no da aplicao.
7.6 Dimensionamento de Dados de Cdigo

As Tabelas com atributos de Cdigo e Descrio devem ser analisadas com muito cuidado. Caso estas tabelas no sejam mantidas pela aplicao, o que geralmente
________________________________________________________________________ acontece, elas no sero contadas. Entretanto, caso seja justificadamente necessrio manter estas informaes, elas sero consideradas requisitos funcionais do usurio. Assim, caso sejam requisitados Casos de Uso e a implementao de funcionalidades para manter tais tabelas, elas sero contadas como dados de negcio (Arquivo Lgico Interno).
8. Atividades Sem Contagem de Pontos de Funo

Deve-se ressaltar que o processo de desenvolvimento de solues possui vrias atividades que devem ser consideradas como um projeto separado, levando-se em conta as horas realizadas, dentre outras: Treinamentos em Tecnologia, Metodologias, Mtricas, etc.: encontram-se nesta categoria as demandas de treinamentos em linguagens de programao, ferramentas de gesto, processos, modelos da qualidade, mtricas, etc. Estes servios so executados por consultores da contratada, especialistas no assunto em questo. Assim, devem ser consideradas as horas de consultoria para preparao e execuo do curso e o custo do deslocamento do instrutor, se for o caso. Desenvolvimento de Cursos para EaD: encontram-se nesta categoria as demandas de desenvolvimento de um curso na modalidade de Ensino a Distncia (EaD). Estas demandas devem ser remuneradas em horas. Mapeamento de Processos de Negcio: encontram-se nesta categoria as demandas de elaborao de documentao contendo o mapeamento de processos de negcio de uma organizao ou de parte de uma organizao. Estes servios so executados por consultores da contratada, especialistas em BPM (Business Process Modeling). Elaborao de Plano Diretor de Tecnologia da Informao (PDTI): encontram-se nesta categoria demandas para elaborao de PDTIs para clientes. Estes servios so executados por consultores da contratada, especialistas nas atividades associadas elaborao de um PDTI. Definio de Processo de Desenvolvimento de Solues: encontram-se nesta categoria demandas para definio de Processos de Software, aderentes s melhores prticas do CMMI e IN04. Estes servios so executados por consultores da contratada, especialistas nas atividades de processos de software e na customizao da ferramenta para criao do site do processo. Outros servios prestados que tambm no possuem Pontos de Funo associados so os seguintes: Administrao de Dados: este servio requer uma equipe de administradores de dados (ADs) com um nmero de profissionais definido junto a contratante, dedicada para atender as demandas associadas definio e manuteno do modelo de dados de negcio do cliente. Esta equipe fica disponvel em horrio
________________________________________________________________________ comercial para atendimento das demandas. Assim, estes servios no possuem contagem de PF associada. importante ressaltar que as atividades de banco de dados associadas ao projeto de desenvolvimento ou de manuteno, por exemplo, preparao de ambiente (testes, homologao, implantao), desempenhadas pelos DBAs da equipe de desenvolvimento, j esto consideradas dentro do projeto de software, no cabendo cobrana adicional. Anlise de Soluo: Servio de apoio destinado anlise de regras de negcio implementadas em solues de TI. Estas demandas no possuem contagem de PF associada. Consultoria: Servio de apoio destinado anlise de regras de negcio a serem implementadas em solues de TI realizado por consultores especialistas da contratada. As demais modalidades de consultoria tambm podem ser enquadradas neste item, por exemplo, Consultoria em Mtricas. Estas demandas no possuem contagem de PF associada. Outras atividades contidas em um processo de software devem ser gerenciadas dentro do projeto de desenvolvimento ou de manuteno, no entanto o esforo deve ser considerado separadamente da estimativa de esforo derivado da contagem de Pontos de Funo. Estas atividades tambm devem ser precificadas a parte. So elas: Treinamento para Implantao: so demandas de treinamentos sobre utilizao do sistema a ser implantado para os gestores de soluo do cliente e usurios. O esforo deste servio deve ser considerado separadamente da estimativa de esforo derivada da contagem de PF. O preo deste servio deve ser calculado, levando-se em conta o preo da hora dos consultores da contratada que estaro realizando atividades de preparao de treinamento e de instrutoria. Em alguns casos, pode ocorrer tambm o deslocamento do instrutor, que tambm deve ser cobrado do contratante. Deve-se ressaltar que este treinamento para implantao pode ser definido na modalidade de EaD, sendo tratado como um projeto de treinamento a parte. O esforo deste considerado dentro do projeto de EaD que no faz parte do projeto de desenvolvimento ou manuteno em questo. Especificao de Negcio: esta atividade a primeira atividade a ser executada em uma demanda de projeto de desenvolvimento e/ou de manuteno. O objetivo desta atividade gerar a Especificao da demanda. O principal produto gerado nesta atividade o artefato: Documento de Viso do Projeto (DV), que deve ser validado pelo contratante, por meio da assinatura do termo de aceite. Alm do DV podem ser gerados outros documentos, tais como: atas de reunio, documento de requisitos no funcionais e glossrio da especificao de negcio. O esforo desta atividade deve ser considerado separadamente da estimativa de esforo derivada da contagem de PF. importante ressaltar que esta atividade de responsabilidade dos Analistas de Negcios da empresa contratante, de acordo com a Instruo Normativa (IN 04). No entanto, por falta de pessoal, alguns rgos e entidades tm contratado estas atividades, que antecedem a fase de requisitos primeira fase do processo de software e devem ser faturadas em horas de consultoria.
________________________________________________________________________ Nesta atividade, deve ser gerado um Documento de Viso (DV) ou outro documento de requisitos de negcios, Documento de Requisitos no funcionais e Glossrio (opcional). O DV o artefato utilizado como insumo para o Planejamento do Projeto - estimativa de tamanho funcional (em Pontos de Funo) do projeto e para o processo de desenvolvimento - atividade de Engenharia de Requisitos do processo de desenvolvimento de software.
9. Processo de Reviso do Roteiro de Contagem

9.1 Reviso para Correo de Inconsistncias e Situaes no previstas
A reviso deste Roteiro ser feita sempre que se verificarem inconsistncias entre uma definio do CPM e uma regra constante deste documento e situaes no previstas neste Roteiro. Para situaes no previstas neste Roteiro, dever-se- documentar a novidade em documentos posteriores, gerando novas verses deste Roteiro.
9.2 Reviso para Adoo de Novas Verses do CPM

A adoo de nova verso do CPM como referncia para este Roteiro de Contagem no ser imediata sua publicao. Nesse caso dever haver uma avaliao da nova verso para se decidir sobre a atualizao do Roteiro. Em caso de utilizao de Roteiro de Mtricas em contratos de software, a atualizao do Roteiro deve ser negociada entre rgo contratante e a empresa contratada.
10. Concluso
Este documento apresentou um Roteiro para o dimensionamento de tamanho de todos os tipos de projetos de software da contratante, visando a aderncia de todos os projetos desenvolvidos na instituio ao processo de Planejamento de Projetos de nvel 2 do CMMI e s diretrizes da Instruo Normativa IN04. A estimativa de tamanho utiliza a mtrica de Pontos de Funo No Ajustados como unidade de medida, conforme recomendado nos Acrdos do Tribunal de Contas da Unio (TCU). importante ressaltar que o uso de mtricas em contrato de software uma excelente prtica, visando proporcionar uma gesto efetiva dos contratos com base em dados quantitativos e objetivos. A implantao desta modalidade de contrato implica na definio de processos de gesto de requisitos e de gesto de projetos baseados nas melhores prticas dos modelos de Qualidade de Software. Outro ponto a ser destacado a implantao de um Escritrio de Mtricas com Servidores capacitados para realizar contagens de Pontos de Funo e Estimativas. Estes Servidores sero responsveis pela reviso das contagens de Pontos de Funo e Estimativas realizadas pelo Escritrio de Mtricas da empresa contratada e pela manuteno do Roteiro de Mtricas do rgo. Como trabalho futuro recomenda-se a reviso e atualizao deste roteiro sempre que se verificar inconsistncia entre alguma definio do IFPUG, seja publicada em verses futuras do CPM ou em White Paper, ou quando for detectado um novo tipo de servio associado ao desenvolvimento de software no previsto neste trabalho.
________________________________________________________________________
Referncias Bibliogrficas
[Boehm, 2009] BOEHM, B.W. Software Cost Estimation With COCOMO II. Prentice Hall, New Jersey, 2009. [Dekkers, 2003] DEKKERS, C. Measuring the logical or functional Size of Software Projects and Software Application. Spotlight Software, ISO Bulletin May 2003, pp10-13. [Hazan, 2008] HAZAN, C. Anlise de Pontos de Funo: Uma Aplicao nas Estimativas de Tamanho de Projetos de Software. Engenharia de Software Magazine, Edio 2, Devmedia, pp.25-31. [IEEE,1998] IEEE Computer Society. IEEE Standard for Software Maintenance. IEEE Std 1219, 1998. [Meli, 1999] MELI, R.; SANTILLO, L. Function Point Estimation Methods: A Comparative Overview. Proceedings of FESMA 99, Amsterdam, Netherlands, October 1999, pp. 271-286. [IFPUG,2009] IFPUG. Considerations for Counting with Multiple Media. Release 1.0, September, 2009. [IFPUG,2010] IFPUG. Counting Practices Manual. Version 4.3, January, 2010. [Jones, 2007] JONES, C. Estimating Software Costs. Second Edition, Mc Graw Hill, 2007. [NESMA, 2009] NESMA. Function Point Analysis for Software Enhancement Guidelines. Version 2.2.1, 2009 [Parthasarathy,2007] PARTHASARATHY, M. A. Practical Software Estimation: function point methods for insourced and outsourced projects. Addison Wesley, New York, 2007. [Roetzheim, 2005] ROETZHEIM, W. Estimating and Managing Project Scope for New Development. CrossTalk, Vol. April, 2005. [SERPRO, 2008] SERPRO. Mtodos para Estimativa de Projetos de Software Baseado em Pontos de Funo. Relatrio do Grupo de Trabalho para Definio da Utilizao de Pontos de Funo nos Servios de Desenvolvimento e Manuteno de Sistemas. 2008. [Sommerville, 2007] SOMMERVILLE, I. Software Engineering. Pearson Education Limited, 8th Edition, 2007. [Vazquez, 2010] VAZQUEZ, C. E.; SIMES, G. S.; ALBERT, R. M. Anlise de Pontos de Funo: Medio, Estimativas e Gerenciamento de Projetos de Software. 9 Edio. Editora rica, So Paulo.
46
________________________________________________________________________
Anexo I Portaria SLTI/MP N 31, de 29 novembro de 2010

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

Requisito 1. Detalhamento 1.1 1.2... 2. 2.1 2.2...
48
________________________________________________________________________
Identificao da Manuteno
Tipo Melhoria Criao de Novas Funcionalidades Melhoria Alterao de Funcionalidades Melhoria Excluso de Funcionalidades Migrao de Dados Corretiva Funcionalidade no Prazo de Garantia (sem custo) Corretiva Funcionalidade No Desenvolvida pela Contratada ou fora do prazo de garantia Redesenvolvimento de Projeto em outra plataforma Atualizao de Plataforma Manuteno em Interface (Cosmtica) Adaptao de Funcionalidades a Requisitos No Funcionais Apurao Especial Base de Dados Apurao Especial Base de Dados Consulta Prvia Apurao Especial Emisso de Relatrio Apurao Especial Reexecuo Atualizao de Dados Manuteno de Pginas Estticas em Intranet / Portal / Internet Manuteno de Documentao de Sistemas Legados Verificao de erros (Anlise e Soluo de Problemas) Pontos de Funo de Testes (Execuo de Testes em funcionalidades no mantidas) Manuteno em Componentes Foi demandada a redocumentao da funcionalidade mantida? Sim No
Aplicar Fator Criticidade? Sim No

49
________________________________________________________________________ Observaes relevantes quanto ao tipo de manuteno:
Descrio dos Requisitos de Manuteno (para cada funcionalidade alterada, utilizar um quadro) a) Tabelas Modificadas pela Manuteno
Nome da Tabela A Tabela atualizada por alguma funcionalidade da aplicao: Sim A Tabela atualizada por outra aplicao: Sim A Tabela foi: Includa Alterada No Excluda No
Total de Campos da Tabela aps a Manuteno = Campos Includos/Alterados/Excludos
A funcionalidade ser apenas testada? Sim No
b) Entradas de Dados Afetadas pela Manuteno (telas ou arquivos de carga)

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

Campos Includos/Alterados/Excludos
50
________________________________________________________________________ Houve mudana na regra de negcio (validaes, lgica de processamento, regras de clculo)? Sim No
c) Consultas Afetadas pela Manuteno Considere a tela de parmetros e a de resultados da consulta como apenas uma nica Consulta. Caso a consulta seja do tipo lista e consulta detalhes, considere como funes independentes e preencha quadros diferentes.
Nome da Consulta Total de Campos da Consulta Tabelas Acessadas Total de Campos Afetados = Total de Campos Calculados ou Totalizadores = Existe atualizao de dados (log, indicador...) Sim Campos Includos/Alterados/Excludos No
Houve mudana na regra de negcio (validaes, lgica de processamento, regras de clculo, campos de filtro)? Sim No

51
________________________________________________________________________ d) Relatrios Afetados pela Manuteno Considere a tela de parmetros e a de resultados do relatrio como apenas um nico Relatrio.
Nome do Relatrio Total de Campos no Relatrio Tabelas Acessadas Total de Campos Afetados = Total de Campos Calculados ou Totalizadores = Existe atualizao de dados (log, indicador...) Sim Campos Includos/Alterados/Excludos No
Houve mudana na regra de negcio (validaes, lgica de processamento, regras de clculo, campos de filtro)? Sim No
52
________________________________________________________________________
Anexo III Modelo de Documento de Contagem de Pontos de Funo Projetos de Manuteno Pequenos (< 100 PF) Documento de Contagem de Pontos de Funo de Projetos de Manuteno Pequenos
Cliente:
Histrico da Reviso
Data Verso Descrio Autor Aprovador
Nome Projeto: Nmero da OS: Responsvel pela Contagem: Descrio da Solicitao de Mudana: Descrio da Atividade Contagem PF Tipo de Manuteno / Total PF
Observaes Relevantes: Conforme a tabela de atividades acima, o total de Pontos de Funo realizados no Projeto _____ na OS _________ de _____ PF No Ajustados.
53

Apendice I - Roteiro de Metricas de Software Do SISP - V1.0

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apendice I - Roteiro de Metricas de Software Do SISP - V1.0

Enviado por

Direitos autorais:

Formatos disponíveis

Roteiro de Mtricas de Software do SISP Verso 1.

Braslia, 29 de novembro de 2010.

Roteiro de Mtricas de Software do SISP

Ministrio do Planejamento, Oramento e Gesto

Secretaria de Logstica e Tecnologia da Informao SLTI

Departamento de Integrao de Sistemas DSI

Coordenao Geral de Gesto Corporativa CGGC

Ncleo de Padronizao Tecnolgica

Roteiro de Mtricas de Software do SISP

Roteiro de Mtricas de Software do SISP

Roteiro de Mtricas de Software do SISP

3. Contagem de Pontos de Funo

Obter a documentao disponvel do projeto Identifique os

Figura 1: Procedimento de Contagem de Pontos de Funo

3.1 Determinar Propsito, Tipo, Escopo e Fronteira de Contagem

________________________________________________________________________ nova aplicao.

3.2 Funes de Dados e Funes Transacionais

Roteiro de Mtricas de Software do SISP

Tabela 1: Contribuio Funcional dos Tipos Funcionais

3.3 Clculo de Pontos de Funo

4.1 Projeto de Melhoria

Roteiro de Mtricas de Software do SISP

Roteiro de Mtricas de Software do SISP

Roteiro de Mtricas de Software do SISP

4.2 Projetos de Migrao de Dados

4.3 Manuteno Corretiva

________________________________________________________________________ rgo ou entidade.

4.4 Redesenvolvimento de Projetos em outra Plataforma

4.5 Atualizao de Plataforma

4.6 Manuteno em Interface

4.7 Adaptao de Funcionalidades a Requisitos No Funcionais

Roteiro de Mtricas de Software do SISP

4.8 Apurao Especial

Roteiro de Mtricas de Software do SISP

Roteiro de Mtricas de Software do SISP

4.9 Atualizao de Dados

4.10 Manuteno em Pginas Estticas de Intranet, Internet ou Portal

4.11 Manuteno de Documentao de Sistemas Legados

4.12 Verificao de Erros

4.13 Pontos de Funo de Teste

4.14 Manuteno de Componentes

5. Estimativas de Projetos de Software

Roteiro de Mtricas de Software do SISP

Coletar e Analisar Requisitos Iniciais

Banco de Dados Histrico de Projetos da organizao

Reestimar ,conforme necessidade

Roteiro de Mtricas de Software do SISP

5.1 Contagem Estimativa de Pontos de Funo (CEPF)

Roteiro de Mtricas de Software do SISP

Abstrao orientada a dados

Aplicao Transaes (EEs, CEs, SEs) Dados Internos (ALIs)

Pontos de Funo (nmeros)

Outras Aplicaes Dados Externos (AIEs)

5.2 Estimativa de Esforo de Projetos de Software

Roteiro de Mtricas de Software do SISP

5.3 Estimativa de Prazo de Projetos de Software

Roteiro de Mtricas de Software do SISP

Roteiro de Mtricas de Software do SISP

________________________________________________________________________ Tipo de Sistema

0,37 0,39 0,40

5.4 Alocao de Equipe ao Projeto

5.5 Mtodo para Estimativa de Custo

Roteiro de Mtricas de Software do SISP

5.6 Estimativa de Recursos Computacionais