ANEXO II NORMAS COMPLEMENTARES AO CPM 4.3.1/IFPUG

Transcrição

1 ANEXO II NORMAS COMPLEMENTARES AO CPM 4.3.1/IFPUG Este anexo é uma complementação ao Manual de Práticas de Contagem de Pontos de Função (CPM 4.3.1) [IFPUG,2010] contendo as técnicas de contagem antecipada na NESMA (Indicativa e Estimada) e alguns tópicos baseados no Roteiro de Métricas de Software do SISP/Governo Federal versão 2.0 /2012 Aspectos legais/jurídicos A Portaria SLTI/MP nº 31 de 29/11/2010 recomenda o uso da métrica pontos de função para os órgãos integrantes do SISP, bem como a adoção do Roteiro de Métricas de Software do SISP na contratação de desenvolvimento e manutenção de software Conforme constante no tópico 2.10 do Termo de Referência - O CPM, publicado pelo International Function Point Users Group (IFPUG), define as regras de contagem de Pontos de Função. É importante ressaltar que a métrica de Pontos de Função foi concebida como uma medida de tamanho funcional para projetos de desenvolvimento e de melhoria. No que se refere a estes projetos, este documento define fatores de impacto totalmente aderentes aos conceitos e regras apresentados pelo CPM 4.3.1/IFPUG permitindo a redução dos valores calculados e aumentando a acurácia das medições. Por outro lado, o CPM /IFPUG não contempla diversos tipos de projetos de manutenção, incluindo a manutenção corretiva, as manutenções de interface (cosméticas) e as mudanças em requisitos funcionais durante os projetos de desenvolvimento, entre outras. Assim, esse documento foi elaborado com o objetivo de complementar a lacuna existente no IFPUG, conforme resumido abaixo: 1) Complementar a métrica do IFPUG através da inserção de percentuais nas fórmulas de fatores de impacto/redutores para projetos de melhoria em substituição à apresentada no CPM 4.3.1/IFPUG 2) Definir outras métricas para mensurar o dimensionamento da extensão do tamanho de outros tipos de projetos de manutenção, os quais são itens não mensuráveis pelo CPM. Obs: Os itens não mensuráveis serão tratados tendo as definições do SISP 2.0 como referência. Cabe a RESPONSÁVEL TÉCNICA elaborar a solução para os casos omissos nessa norma e/ou no SISP 2.0. Página: 1 / 6

2 1. MUDANÇA DE REQUISITOS EM PROJETOS DE DESENVOLVIMENTO 1.1 CONCEITUAÇÃO E CLASSIFICAÇÃO DOS DIFERENTES TIPOS DE MUDANÇAS Requisito original: é o requisito do projeto de desenvolvimento que pode ser incluir, alterar ou excluir funcionalidades de um aplicativo. Tipo da mudança do requisito: é a natureza da mudança de requisitos no projeto em andamento, que pode ser acrescentar um requisito, alterar um requisito definido ou desistir de um requisito (retirar do escopo do projeto). 1) Previsão de Aumento de Escopo nas estimativas iniciais (SCOPE CREEP) Scope Creep é um fenômeno comum caracterizado pelo aumento de escopo de projetos de software em função de mudança/evolução de requisitos Nas estimativas iniciais de tamanho de projetos de desenvolvimento, considerando o documento de visão inicial, deve-se aplicar um percentual de 30 % ou 40 %, dependendo do método adotado (conforme tabela 04 do Termo de Referência) para evolução de requisitos. Exemplo: Um sistema cujo tamanho em PF no documento inicial foi dimensionado através do método de contagem indicativa da NESMA em 500 PF deverá ser majorado em 40% em função da previsão de Scope Creep acima descritos. Logo, a estimativa inicial de dimensionamento do tamanho do projeto será 700 PF (acréscimo de 40% a 500 PF) 1.1) Mudanças do tipo inclusão de requisitos ao escopo nos projetos As mudanças ocorridas no decorrer do projeto caracterizadas pela inclusão de funcionalidades ao escopo do projeto devem ser contadas como PF do projeto de desenvolvimento. Essas mudanças de requisitos caracterizadas pela inclusão de um novo requisito e que geram aumento de escopo devem integrar a parcela denominada PF_DESENVOLVIMENTO. Aos PF_DESENVOLVIMENTO deverá ser aplicado o percentual das fases atual e anterior ao momento de inclusão deste novo requisito. 1.2) Mudanças do tipo alteração ou desistência de requisito Observação Importante: A contagem do projeto de desenvolvimento, incluindo a migração, se houver, deverá ser atualizada a cada demanda de mudança de requisitos, visando refletir as funcionalidades após a mudança. Fórmulas: Página: 2 / 6

3 PF_RETRABALHO = PF_ALTERADO x 0,5 Onde: PF_RETRABALHO = Tamanho da função/componente a ser alterado em pontos de função com a utilização de um fator de impacto de natureza redutora de 50% (cinqüenta) que deverá ser aplicado nas fases de elaboração, construção e transição desde que autorizado pelo gestor e devidamente justificado e documentado pela empresa contratada. PF_ALTERADO = Tamanho do processo elementar (Entrada Externa EE, Consulta Externa CE e Saída Externa SE) ou função de dados (Arquivo Lógico Interno ALI e Arquivo de Interface Externa AIE) em pontos de função antes da alteração. Exemplo: 1) Em um componente do tipo CE (consulta externa) de complexidade alta com tamanho de 6 PF, que sofra quaisquer alterações geradas por solicitação do gestor ( change request ) deverá receber o valor de ponto de função de retrabalho (PF_RETRABALHO) igual a 3 PF (50% de 6 PF (tamanho original)) FÓRMULA A SER APLICADA NOS PROJETOS DE DESENVOLVIMENTO Para fins de pagamento, a quantidade total de pontos de função será obtido da seguinte formula: Onde: PF_TOTAL = PF_DESENVOLVIMENTO + PF_RETRABALHO PF_TOTAL = Quantidade de Pontos de Função da OES de TIC que contemplam o somatório das parcelas desenvolvimento e retrabalho. PF_DESENVOLVIMENTO = Somatório de Pontos de Função do projeto de desenvolvimento, incluindo a migração, se houver. PF_RETRABALHO = Somatório de todos os pontos de função de retrabalho IMPORTANTE : As mudanças relativas a alteração/exclusão de requisitos que gerem PF_retrabalho, conforme definido neste anexo, e que ocorram na fase de concepção não serão consideradas para fins de pagamento. Assim, só serão remuneradas, as solicitações de mudanças relativas a alteração/exclusão de requisitos que ocorram nas fases de elaboração, construção e transição. Página: 3 / 6

4 A remuneração do PF de retrabalho deve considerar o percentual das fases somente concluídas do processo de desenvolvimento anteriores ao momento da mudança de requisitos. 2. CONCEITOS E REGRAS PARA DIVERSOS TIPOS DE PROJETOS DE MANUTENÇÃO Uma vez que o Manual de Práticas de Contagem CPM 4.3.1/IFPUG não contempla todos os tipos de projetos de manutenção, apenas os projetos de melhoria, este tópico tem como propósito descrever outras naturezas de projetos de manutenção definindo métricas aderentes às regras e conceitos contidos no referido manual PROJETO DE MELHORIA DEFINIÇÃO DO PROJETO DE MELHORIA NO CONTEXTO CPM 4.3.1/IFPUG O Projeto de Melhoria (enhancement), também denominado de projeto de melhoria funcional ou manutenção evolutiva, está associado às mudanças em requisitos funcionais da aplicação, ou seja, à inclusão de novas funcionalidades, alteração ou exclusão de funcionalidades em aplicações implantadas. Este documento separa o projeto de melhoria, quando as mudanças são associadas aos requisitos funcionais e a manutenção adaptativa quando as mudanças estão associadas aos requisitos não funcionais da aplicação. Um projeto de melhoria consiste em demandas de criação de novas funcionalidades (grupos de dados ou processos elementares), demandas de exclusão de funcionalidades (grupos de dados ou processos elementares) e demandas de alteração de funcionalidades (grupos de dados ou processos elementares) em aplicações implantadas em produção. Fórmula para a Contagem de Pontos de Função de Projetos de Melhoria. PF_MELHORIA = PF_INCLUIDO + (0,40 x PF_EXCLUIDO) + (FI x PF_ALTERADO) Definições: PF_INCLUÍDO = Pontos de Função associados às novas funcionalidades que farão parte da aplicação. PF_ALTERADO = Pontos de Função associados às funcionalidades existentes na aplicação que serão alteradas no projeto de manutenção. PF_EXCLUÍDO = Pontos de Função associados às funcionalidades existentes na aplicação que serão excluídas no projeto de manutenção. FI = Fator de Impacto (Será de 50 % se a funcionalidade vier a ser mantida pela empresa que originalmente a desenvolveu OU será de 75 % se a funcionalidade vier a ser mantida por meio de empresa que não a desenvolveu) Página: 4 / 6

5 A contratada deve redocumentar a funcionalidade mantida, gerando a documentação completa da mesma, aderente ao PDSA PROJETO DE MANUTENÇÃO CORRETIVA APÓS A GARANTIA A manutenção CORRETIVA altera componentes de software para correção de defeitos em funcionalidades de sistemas em produção. Fórmula: Onde: PF_CORRETIVA = PF_COMPONENTE x 0,6 PF_CORRETIVA = Tamanho do processo elementar (Entrada Externa EE, Consulta Externa CE e Saída Externa SE) ou função de dados (Arquivo Lógico Interno ALI e Arquivo de Interface Externa AIE) corrigidos, em pontos de função. PF_COMPONENTE = Tamanho do processo elementar (Entrada Externa EE, Consulta Externa CE e Saída Externa SE) ou função de dados (Arquivo Lógico Interno ALI e Arquivo de Interface Externa AIE) em pontos de função 2 MÉTODOS NESMA PARA CONTAGEM ANTECIPADAS 2.1 ) A contagem indicativa da NESMA de pontos de função A contagem indicativa é realizada da seguinte forma: determina-se a quantidade das funções do tipo dado (ALIs e AIEs) calcula-se o total de pontos de função não ajustados da aplicação da seguinte forma: tamanho indicativo (pf) = 35 x número de ALIs + 15 x número de AIEs Portanto esta estimativa é baseada somente na quantidade de arquivos lógicos existentes (ALIs e AIEs) A contagem indicativa é baseada na premissa de que existem aproximadamente três EEs (para adicionar, alterar, e excluir dados do ALI), duas SEs, e uma CE na média para cada ALI, e aproximadamente uma SE e uma CE para cada AIE. 2.2 ) A contagem estimada da NESMA de pontos de função A contagem estimativa é realizada da seguinte forma: determina-se todas as funções de todos os tipos (ALI, AIE, EE, SE, CE) Página: 5 / 6

6 toda função do tipo dado (ALI, AIE) tem sua complexidade funcional avaliada como BAIXA, e toda função transacional (EE, SE, CE) é avaliada como de complexidade MÉDIA Calcula-se o total de pontos de função não ajustados Logo, a única diferença em relação à contagem usual de pontos de função é que a complexidade funcional não é determinada individualmente para cada componente. Página: 6 / 6