Guia de Contagem APF Versão 1.00

Transcrição

1 Versão 1.00

2 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 20/11/ Criação do Guia de Contagem APF Célio Santana / Gustavo Santos Guia de Contagem APF ATI Pág. 2 de 65

3 SUMÁRIO 1. INTRODUÇÃO Definições, Acrônimos e Abreviações OBJETIVOS DO DOCUMENTO ESTIMATIVAS DE PROJETO DE SOFTWARE DETALHAMENTO DO PROCESSO DE ESTIMATIVA PAGAMENTO BASEADO NO CICLO DE VIDA DA ENTREGA ESTIMATIVA DE PRAZO ESTIMATIVA DE CUSTO CONTAGEM DE PONTOS DE FUNÇÃO PARA PROJETOS DE MANUTENÇÃO PROJETOS DE MELHORIA PROJETOS DE MANUTENÇÃO CORRETIVA MANUTENÇÃO COSMÉTICA MANUTENÇÃO ADAPTATIVA EM REQUISITOS NÃO FUNCIONAIS REDESENVOLVIMENTO DE PROJETOS EM OUTRA PLATAFORMA ATUALIZAÇÃO DE PLATAFORMA ADEQUAÇÃO DE FUNCIONALIDADES ÀS MUDANÇAS DE NEGÓCIO APURAÇÃO ESPECIAL MANUTENÇÃO EM PÁGINAS ESTÁTICAS DE INTRANET, INTERNET OU PORTAL MANUTENÇÃO DE DOCUMENTAÇÃO DE SISTEMAS LEGADOS VERIFICAÇÃO DE ERROS FATOR DE CRITICIDADE DE SOLICITAÇÃO DE SERVIÇO PONTOS DE FUNÇÃO DE TESTE ITENS NÃO MENSURÁVEIS ASPECTOS NÃO CONSIDERADOS PELO IFPUG CONSIDERADOS PELA ATI MÚLTIPLAS MÍDIAS MÚLTIPLAS MÍDIAS MESMOS DADOS DE SAÍDA COMO DADOS EM ARQUIVOS E RELATÓRIOS IMPRESSO MESMOS DADOS DE ENTRADA BATCH E ON-LINE MÚLTIPLOS CANAIS DE ENTREGA DA MESMA FUNCIONALIDADE RELATÓRIOS EM MÚLTIPLOS FORMATOS DATA WAREHOUSE AUTOMAÇÃO DE PROCESSOS DE NEGÓCIO (BPM) FRONTEIRA DA APLICAÇÃO Situação acesso ao BPMS: Guia de Contagem APF ATI Pág. 3 de 65

4 Cadastro de usuários e grupos organizacionais: Funcionalidades da aplicação Ágiles Recebimento de dados de outras aplicações utilizando interface de integração Atualização de dados em outras aplicações utilizando interface de integração Dados de Código Processo Elementar Atividade com prazos LIÇÕES APRENDIDAS REQUISITOS GRANULARIDADE X QUANTIDADE DE REQUISITOS ATENÇÃO A REQUISITOS NÃO FUNCIONAIS ATENÇÃO A RELATÓRIOS DICAS NA DEFINIÇÃO DA FRONTEIRA DICAS NA IMPLANTAÇÃO DO PROCESSO CONSIDERAÇÕES SOBRE A CONTAGEM DE PONTOS DE FUNÇÃO CONSIDERAÇÃO SOBRE MUDANÇAS DE REQUISITOS CONSIDERAÇÃO SOBRE PROJETOS CANCELADOS CONSIDERAÇÕES SOBRE REDUÇÃO DE CRONOGRAMA CONSIDERAÇÕES SOBRE A PRECIFICAÇÃO Tamanho Funcional x Esforço de Desenvolvimento Valor do Ponto de Função Preço Ideal do Ponto de Função na APE Considerações CONSIDERAÇÕES SOBRE CICLO DE VIDA ITERATIVO INCREMENTAL COMO UMA EMPRESA PÚBLICA PODE SE FILIAR AO IFPUG CERTIFICAÇÃO CFPS PROCESSO DE REVISÃO DO GUIA DE CONTAGEM REVISÃO PARA CORREÇÃO DE INCONSISTÊNCIAS E SITUAÇÕES NÃO PREVISTAS REVISÃO PARA ADOÇÃO DE NOVAS VERSÕES DO CPM CONCLUSÃO REFERÊNCIAS BIBLIOGRAFIAS Guia de Contagem APF ATI Pág. 4 de 65

5 1. INTRODUÇÃO A Agência Estadual de Tecnologia da Informação do Estado de Pernambuco (ATI-PE) seguindo o caminho de muitas empresas governamentais brasileiras têm iniciado a utilização da métrica de Pontos de Função (PF) nas estimativas e dimensionamento de tamanho funcional de projetos de software, devido aos diversos benefícios de utilização da métrica tais como a independência da solução tecnológica utilizada e às recomendações dos órgãos de controle do governo federal brasileiro. O Manual de Práticas de Contagem de Pontos de Função ou (CPM) que hoje se apresenta na versão 4.3, publicado pela International Function Point User Group (IFPUG) em 201, define as regras de contagem de Pontos de Função. No entanto, a contagem de Pontos de Função é baseada no projeto lógico da aplicação e nas fases iniciais do ciclo de vida do software, o documento de requisitos para a estimativa e elaboração do plano do projeto é um documento inicial de requisitos, por exemplo: Documento de Visão, Formalização Simples de Requisitos ou algum outro tipo de especificação elaborada pelo analista de negócios. Assim, torna-se importante o estabelecimento de métodos para estimar o tamanho funcional dos projetos de software nas fases iniciais do ciclo de vida. Outro ponto a ser destacado é a importância da definição de métodos para geração de estimativas de prazo, esforço, custo e recursos computacionais dos projetos de software da empresa, visando melhorar o gerenciamento dos projetos. Além disso, é 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 manutenção evolutiva de software. No entanto, os projetos de software não estão limitados a projetos de desenvolvimento e projetos de manutenção evolutiva ou Melhoria (enhancement), admitindo normalmente manutenções corretivas e perfectivas, bem como os projetos com características diferentes dos sistemas de informações tradicionais, como projetos de BI, automação de processos e portais WEB, por exemplo. Assim, torna-se essencial a definição de métodos para dimensionar o tamanho de projetos manutenção (maintenance) e demais projetos cujas características não estejam cobertas pelo manual do IFPUG, baseados em Pontos de Função, para que estes projetos possam ser avaliados e gerenciados com base em uma métrica. Observe que a INSTRUÇÃO NORMATIVA Nº 4 DE 12 DE NOVEMBRO DE 2010, publicada pela SLTI/ MPOG, preconiza a utilização de métricas em contratos de software. Os Acórdãos do Tribunal de Contas da União (TCU) recomendam a utilização da métrica Pontos de Função Não Ajustados. A versão 4.3 do CPM também reconhece o PF Não Ajustado como método padrão do IFPUG Definições, Acrônimos e Abreviações APF: Análise de Pontos de Função; CMMI-Acq: Capability Maturity Model Integration for Aquisition CPM: Manual de Práticas de Contagens do IFPUG; Guia de Contagem APF ATI Pág. 5 de 65

6 MPS.BR: Melhoria de Processo do Software Brasileiro IFPUG: International Function Points Group User ( PF: Pontos de Função. 2. OBJETIVOS DO DOCUMENTO Este documento tem como propósito apresentar um roteiro contagem de Pontos de Função aderente ao Manual de Práticas de Contagem (CPM 4.3) e definir os tipos de projetos de manutenção e uma sistemática para dimensionar o tamanho de tais projetos, utilizando a métrica Pontos de Função. Além da contagem de Pontos de Função, este roteiro apresenta um processo de estimativas com base na métrica Pontos de Função, proposto por Cláudia Hazan (2008). Além disto, estará contido neste manual um conjunto de práticas de contagens que são institucionalizadas pela ATI. Outra seção deste mesmo manual será destinada a documentar as lições aprendidas da ATI durante o contínuo aprendizado da utilização da técnica. Alem destas seções introdutórias, este documento encontra-se organizado da seguinte maneira: A Seção 3 define o processo de estimativas de projetos de software integrado ao processo de acompanhamento de contratos de fornecedores da ATI, indicando o momento de realização das estimativas e as análises a serem realizadas; A Seção 4 apresenta diretrizes para a estimativa e a contagem de Pontos de Função de todos os tipos de projetos de manutenção de software; A Seção 5 descreve as atividades associadas ao processo de contratação cujos itens não são mensuráveis pela IFPUG em Pontos de Função; A Seção 6 apresenta alguns aspectos que não estão presentes no Manual de Práticas de Contagem do IFPUG e como a ATI considera tais aspectos; A Seção 7 apresenta as lições aprendidas pela ATI na utilização de pontos por função. Estas lições podem ser dirigidas as práticas de contagens ou até mesmo a forma de escrever os requisitos; A Seção 8 apresenta algumas considerações importantes sobre a utilização de métricas para dimensionar as mudanças de requisitos, redução de cronograma e atividades de negócio. Também apresenta considerações sobre o preço do ponto de função, certificação CTFP e filiação ao IFPUG; A Seção 9 apresenta o processo de revisão deste guia de contagem; Finalmente, a Seção 10 conclui o documento apresentando sugestões para trabalhos futuros. 3. ESTIMATIVAS DE PROJETO DE SOFTWARE Este Capítulo tem como propósito descrever um processo de estimativas de projetos de software aderente ao modelo Capability Maturity Model Integration for Aquisition (CMMI-Acq), ao modelo de Melhoria de Processo do Software Brasileiro (MPS.BR) e baseado no modelo proposto por Hazan (2008). Neste contexto, são apresentados os sete níveis de métodos Contagem de Pontos de Função e quando cada um deles deve ser utilizado para estimar o tamanho dos projetos de software em PF, alguns modelos simplificados de estimativas para estimar o esforço dos projetos em homem_hora (HH), a fórmula de Capers Guia de Contagem APF ATI Pág. 6 de 65

7 Jones para estimar os prazos dos projetos. Será apresentada também nesta seção a integração do modelo de contagem da ATI ao seu processo de desenvolvimento. A Figura 1 ilustra um processo de Estimativas de Projetos de Software aderente à área de processo de Planejamento do Projeto de Aquisição do nível 2 do CMMI-ACq. Este processo é baseado no modelo da Cláudia Hazan (2008) e será descrito em linhas gerais nos parágrafos seguintes. Legenda Identificar a necessidade de contagem para contrato em APF Identificar usuários, reunir documentação e levantar requisitos iniciais da solução. Determinar escopo da contagem, fronteiras e identificar requisitos funcionais do usuário Etapas antes do inicio da Sprint. Etapas Durante a Sprint Identificar demandas que serão implementadas na Sprint Agrupar demandas ligadas ao mesmo requisito funcional. Realizar contagem estimativa de tamanho funcional da Sprint Etapas Após Recebimento da Sprint Etapas durante a transação entre Sprints Derivar Custo e Prazo da entrega baseado no tamanho funcional. Realizar contagem funcional da entrega realizada pelo fornecedor Reavaliar Custo e Prazo da entrega realizada pelo fornecedor Base Histórica Atualizar Base Histórica do Projeto baseado na diferenças entre a estimativa e a Medição Base Histórica Figura 1: Processo de Estimativas de Projetos de Software Este processo está inserido no contexto do processo Scrum da ATI. As três primeiras etapas acontecem no momento de planejar a contratação. Neste momento em que são verificadas soluções existentes no mercado, busca por propostas e levantamento das principais características da solução, é o momento de se dimensionar uma contagem estimativa (o processo de contagem estimativa será detalhado mais a frente). As etapas na Sprint (vermelho) tem como principal insumo (artefato de entrada) um documento de requisitos. Como as estimativas devem ser realizadas no início do processo de desenvolvimento de software, ou mesmo da Sprint então, o artefato utilizado é um documento inicial de requisitos, por exemplo: Documento de Visão ou Formalização Simples de Requisitos utilizados no Mantis da própria ATI. Guia de Contagem APF ATI Pág. 7 de 65

8 O estimador deve analisar os requisitos para garantir a qualidade bem como agrupar as demandas no mesmo requisito para evitar a contagens múltiplas da mesma função para só assim estimar o tamanho do projeto de software. Embora nas etapas iniciais possa existir a contagem estimada do sistema, a mesma só serve para dimensionamento do contrato e não para acompanhamento de projeto. Assim, o próximo passo é a derivação das estimativas de prazo (cronograma) e (orçamento) da demanda com base na estimativa de tamanho e nos dados históricos de projetos concluídos da organização. Neste ponto, as principais estimativas foram geradas e precisam ser documentadas. As premissas e suposições utilizadas na geração das estimativas, dentre outras: complexidade do projeto, plataforma de desenvolvimento, tipo do projeto, percentual de evolução de requisitos, também devem ser documentadas. A realização das estimativas por um analista de métricas que não atue na equipe do projeto constitui uma prática recomendada. O analista de métricas deve analisar também a consistência da documentação utilizada na estimativa. No decorrer do processo de desenvolvimento, as estimativas devem ser acompanhadas conforme o refinamento dos requisitos. O projeto deve ser reestimado após a fase de requisitos, quando for gerada a especificação de casos de uso, e sempre que ocorrerem mudanças significativas nos requisitos funcionais ou não funcionais. Quando o projeto ou Sprint for concluído, deve-se novamente aferir e documentar o tamanho, prazo e custo, assim como outros atributos relevantes do projeto, visando a coleta de dados para a melhoria do processo de estimativas. As lições aprendidas também devem ser documentadas e incorporadas a este guia, bem como a base histórica. A alimentação contínua desta base histórica (Última atividade) é que irá garantir a ATI uma melhoria das estimativas ao longo do projeto. Desta forma, para os contratos de projetos de software baseados na métrica Pontos de Função as estimativas devem ser realizadas em três marcos do processo de desenvolvimento, a saber: Estimativa inicial: Realizada após o fechamento do escopo do projeto. Geralmente, é baseada em um documento inicial de requisitos, por exemplo: o Documento de Visão. Constitui uma boa prática a previsão de evolução de requisitos, especialmente em projetos de desenvolvimento de médio ou grande porte. Seu objetivo é quantificar uma ordem de grandeza para o total de pontos por função que serão empregados para construir determinada solução. Nessa etapa é importante destacar os seguintes conceitos na área de estimativas: Uma Estimativa é obtida por meio de uma atividade técnica, utilizando métodos de estimativas. Não deve sofrer interferências políticas. A Meta é um desejo, em função de necessidades de negócio, estabelecida politicamente. Guia de Contagem APF ATI Pág. 8 de 65

9 Em um cenário ideal os resultados da estimativa atendem as metas de negócio. Quando este cenário não é real, é fundamental a redução de escopo do projeto, de modo que a meta se adapte aos resultados da estimativa. Neste momento, dependendo do detalhe da documentação, serão permitidos 04 (quatro) níveis de detalhamento de contagem dos 06 (seis) apresentados pela totalmetrics (2004). O Nível menos detalhado é conhecido por se basear apenas na base histórica. Considere a Figura 2 como um exemplo hipotético de base histórica. Figura 2: Base histórica do ISBSG e do Meu projeto O sexto nível de contagem é dado pela estimativa mais estável desta base histórica. Suponha que o elemento que menos varia nas contagens históricas da ATI seja a pontuação dos ALIs em relação ao projeto todo. Considerando o projeto acima, os ALIs representam cerca de 27% da pontuação total do projeto. Então neste caso é apenas desejado se calcular a pontuação de todos os ALIS e aplicar a regra de três. Vale ressaltar que é importante escolher a estrutura que menos varia no processo. Suponha que para o caso anterior as saídas externas, que representam em média 12% do total de pontuação dos projetos da ATI, variem entre 0% e 40%, então, não é um elemento confiável para a escolha da regra de três. Guia de Contagem APF ATI Pág. 9 de 65

10 O quinto nível é conhecido como contagem indicativa, onde é necessário apenas identificar os ALIs e AIEs da aplicação. Não é necessário detalhar as funções de dados, nem identificar as funções de transação. Uma vez identificadas as funções de dados é utilizada a fórmula a seguir: PF = 35*N de ALIs + 15*N de AIEs Estes números de 35 e 15 podem ser calibrados para melhor representar as necessidades da organização e devem ser guiados pela base histórica da mesma. O quarto nível é conhecido como contagem estimativa da NESMA. Nesta contagem é necessário identificar todas as funções de dados e todas as funções de transação. Para realizar esta contagem é necessário considerar todas as funções de dados simples e todas as funções transacionais médias. Vale ressaltar que estas contagens não devem ser utilizadas em conjunto com o fornecedor, estas contagens são apenas para dimensionar um valor de pontos de função que um contrato pode precisar. O segundo marco de contagem é a contagem intermediária que deve ser realizada antes da execução de cada demanda. Neste marco já deve existir documentação dos requisitos suficientes para a realização de uma contagem detalhada que é o 3 Nível de detalhamento proposto pela totalmetrics (2004) e que coincide com a contagem IFPUG considerando as faixas de contagem. Neste momento também pode ser realizada a contagem interligada e anotada (1 Nível) que tem toda rastreabilidade da contagem bem como o detalhamento dos itens de dados. O terceiro marco de contagem é a contagem final que deve ser realizada ao final da execução. Este marco deve ser utilizado para emissão de fatura e pagamento ao fornecedor. Para tal deve-se utilizar os níveis de detalhamento de contagem do 3 até o 1. Para fins de faturamento, que é realizado durante o desenvolvimento, deve-se considerar a Contagem de Referência e posteriormente considerar os ajustes no faturamento após a Contagem Final. É importante ressaltar que as mudanças de requisitos também serão consideradas no tamanho projeto a ser faturado. Além disso, se estas mudanças forem significativas, maiores que a evolução de requisitos prevista na estimativa inicial, o prazo do projeto deve ser reestimado. Toda mudança de requisito deve passar por uma análise de impacto da ATI e ser aprovada pelo cliente DETALHAMENTO DO PROCESSO DE ESTIMATIVA O processo de estimativa utilizado visa aferir o tamanho em PF podendo ser de maneira simplificada para os níveis de detalhamento 4, 5 e 6. Estas contagens simplificadas são baseadas no conhecimento dos requisitos iniciais do projeto e na documentação do contrato. Inicialmente, os requisitos funcionais iniciais documentados nas propostas comerciais, nos documentos de visão, formalização simples de requisitos ou em qualquer especificação inicial do sistema do usuário são mapeados nos tipos funcionais Guia de Contagem APF ATI Pág. 10 de 65

11 da Análise de Pontos de Função: Arquivo Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE) e Saída Externa (SE). Posteriormente, os Pontos de Função são associados a cada função identificada, baseando-se nas tabelas de complexidade e de contribuição funcional do CPM (Figura 3). Figura 3: Modelo Lógico da Análise de Pontos de Função [SERPRO 2010] O estimador deve realizar uma leitura no documento inicial de requisitos, buscando informações relevantes para a identificação de processos elementares. O processo elementar é definido como a menor unidade de atividade significativa para o usuário. O processo elementar deve ser completo em si mesmo, independente e deixar a aplicação em um estado consistente [IFPUG, 2010]. Em outras palavras, os processos elementares são funções transacionais independentes, isto é, funções seqüenciais pertencem a um mesmo processo elementar e funções independentes constituem processos elementares diferentes. Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para classificá-lo em Entrada Externa (EE), Consulta Externa (CE) ou Saída Externa (SE). Adicionalmente, o estimador deve descobrir os dados associados ao processo elementar, visando a determinação da complexidade funcional da função identificada. Na análise do processo elementar também são identificados os grupos de dados lógicos da aplicação, que são classificados como Arquivos Lógicos Internos (ALI) ou Arquivos de Interface Externa (AIE). Guia de Contagem APF ATI Pág. 11 de 65

12 A determinação do nível de detalhamento da contagem depende da documentação obtida. Caso seja possível identificar todas as funções de AIE e ALI o ideal é utilizar o 5 Nível de detalhamento (AIE * 35 + AIE * 15). Quando não existe detalhamento suficiente sobre alguma das informações como ALI, AIE é mais difícil encontrar EE, SE e CE nestas condições, pois elas dependem do ALI e AIE. Neste caso, devese utilizar o 6º nível de detalhamento. Caso não seja possível a identificação da complexidade das funcionalidades é melhor usar o método da Nesma, ou 4 nível de detalhe em questão, recomenda-se a utilização da complexidade Média. Na análise do processo elementar também são identificados, os grupos de dados lógicos da aplicação, que são classificados como Arquivos Lógicos Internos ou Arquivos de Interface Externa. Caso não seja possível a identificação da complexidade da função de dados em questão, recomenda-se a utilização da complexidade Simples. É importante ressaltar que se o estimador identificar mais de um Registro Lógico no Arquivo Lógico Interno,recomenda-se utilizar a complexidade Média. A seguir são apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicação 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 categorias: Arquivos Lógicos Internos (ALI): Banco de Dados Lógico da Aplicação (tabelas e arquivos mantidos pela aplicação). Considerações: Identifique os grupos de dados lógicos de aplicação nos modelos de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos documentos de requisitos (Documento de Visão, Relação de Casos de Uso, etc.). Não considere arquivos físicos, arquivos de índices, arquivos de trabalho e tabelas de relacionamento sem atributos próprios (tabelas que existem para quebrar o relacionamento nxn e apenas transportam as chaves estrangeiras). As entidades fracas também não são consideradas um ALI. Se possível, tente descobrir os atributos lógicos, campos reconhecidos pelo usuário, e subgrupos de dados existentes para obter a complexidade funcional, segundo as regras de contagem do CPM. Caso não seja possível, a experiência tem mostrado que a maioria dos ALIs dos sistemas são de complexidade Simples. A pontuação destes elementos segundo o IFPUG está descrita na Tabela 1 Tabela 1: Pontuação dos Arquivos Lógicos Internos [IFPUG 2010] Guia de Contagem APF ATI Pág. 12 de 65

13 Arquivos de Interface Externa (AIE): Banco de Dados de outras Aplicações, apenas referenciados pela aplicação que está sendo estimada (tabelas e arquivos mantidos por outra aplicação). Considerações: Identifique os grupos de dados lógicos de outras aplicações referenciados pela aplicação que está sendo estimada. Freqüentemente, a referência de dados ocorre para a validação de informações em cadastros ou consultas. Algumas vezes, relatórios ou consultas referenciam dados externos de outras aplicações, também considerados AIEs. Não são considerados arquivos físicos, arquivos de índice, arquivos de trabalho, tabelas de relacionamento sem atributos próprios e entidades fracas. Geralmente, os AIEs dos sistemas possuem a classificação de complexidade Simples. Porque, são considerados para a determinação da complexidade funcional do AIE apenas os atributos referenciados pela aplicação que está sendo contada. A pontuação destes elementos segundo o IFPUG está descrita na Tabela 2 Tabela 2: Pontuação dos Arquivos de Interface Externa [IFPUG 2010] Entradas Externas (EE): Funcionalidades que mantêm os Arquivos Lógicos Internos (ALIs) ou alteram o comportamento da aplicação. Considerações: Identifique as funcionalidades de manutenção de dados. Conte separadamente a inclusão, alteração e exclusão de dados, isto é, cada função independente de inclusão ou alteração ou exclusão deve ser contada separadamente. A aplicação possui funções de entrada de dados que alteram o comportamento dela, por exemplo: processamentos batch, ou processamento de informações de controle? Caso positivo, estas funções também devem ser identificadas como Entradas Externas. Se você não possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Entrada Externa identificada com complexidade Média. A pontuação destes elementos segundo o IFPUG está descrita na Tabela 3 Tabela 3: Pontuação das Entradas Externas [IFPUG 2010] Guia de Contagem APF ATI Pág. 13 de 65

14 Consultas Externas (CE): funcionalidades que apresentam informações para o usuário sem a utilização de cálculos ou algoritmos. São os processos elementares do tipo lê - imprime, lê - apresenta dados, incluindo consultas, relatórios, geração de arquivos pdf, xls, downloads, entre outros. Considerações: Uma funcionalidade é desenvolvida para apresentar informações para o usuário: uma consulta, relatório, browse, listbox, download, geração de um arquivo, geração de arquivo psd, xls? Esta função não possui cálculos ou algoritmos para derivação dos dados referenciados nem altera um Arquivo Lógico Interno, nem muda o comportamento do sistema? Caso positivo, estas funções devem ser identificadas como Consultas Externas. Se você não possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Consultas Externas com complexidade Média. A pontuação destes elementos segundo o IFPUG está descrita na Tabela 4 Tabela 4: Pontuação das Consultas Externas [IFPUG 2010] Saídas Externas (SE): Funcionalidades que apresentam informações para o usuário com utilização de cálculos ou algoritmos para derivação de dados ou atualização de Arquivos Lógicos Internos ou mudança de comportamento da aplicação. São as consultas ou relatórios com totalização de dados, relatórios estatísticos, gráficos, geração de arquivos com atualização log, downloads com cálculo de percentual, entre outros. Considerações: Uma funcionalidade é desenvolvida para apresentar informações para o usuário: uma consulta ou relatório com totalização de dados, etiquetas de código de barras, gráficos, relatórios estatísticos, download com percentual calculado, geração de arquivo com atualização de log? Caso positivo, estas funções devem ser identificadas como Saídas Externas. Observe que esta função deve ter cálculos ou algoritmos para processar os dados referenciados nos arquivos lógicos ou atualizar campos (normalmente indicadores) nos arquivos ou mudar o comportamento da aplicação. Guia de Contagem APF ATI Pág. 14 de 65

15 Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Saídas Externas com complexidade Média. A pontuação destes elementos segundo o IFPUG está descrita na Tabela 5 Tabela 5: Pontuação das Consultas Externas [IFPUG 2010] A Estimativa de tamanho do projeto em PFs deve ser gerada totalizando-se os PFs obtidos nas Tabelas 1, 2, 3, 4, e 5. a seguinte: A fórmula de contagem ou de estimativa de Pontos de Função para Projetos de Desenvolvimento é Quadro 1: Totalização da Pontuação em Desenvolvimento de Software [IFPUG 2010] A fórmula de contagem ou de estimativa de Pontos de Função para Softwares Prontos é a seguinte: Guia de Contagem APF ATI Pág. 15 de 65

16 Quadro 2: Totalização da Pontuação para Aplicações Prontas [IFPUG 2010] seguinte: A fórmula de contagem ou de estimativa de Pontos de Função para Projetos de Melhoria é a Quadro 3: Totalização da Pontuação para Aplicações Prontas [IFPUG 2010] 3.2. PAGAMENTO BASEADO NO CICLO DE VIDA DA ENTREGA O próximo passo é a definição da forma de pagamento baseado pelas entregas, visando remunerar o fornecedor pelos produtos liberados em cada entrega, tornando o processo menos oneroso para o mesmo e incentivando a cumprir resultados. Está facultado a ATI decidir se irá utilizar este tipo de pagamento e em qualquer granularidade, tais como editais ou contratos. Assim a ATI pode inclusive pagar apenas uma porcentagem do valor cheio de uma determinada demanda se partes das entregas não forem necessárias naquele contrato. Atualmente a ATI utiliza a seguinte distribuição (Tabela 6). Tabela 6: Remuneração da ATI por fase de Ciclo de Vida Guia de Contagem APF ATI Pág. 16 de 65

17 3.3. ESTIMATIVA DE PRAZO As estimativas de prazo não são lineares com o tamanho do projeto. O melhor tempo de desenvolvimento, no qual há uma melhor relação custo x benefício de alocação de recursos e menor prazo de desenvolvimento, dado o tamanho de um projeto específico, é sugerido e utilizado nas estimativas de prazo deste manual. Jones [Jones, 2007] propõe uma fórmula para o cálculo do melhor tempo de desenvolvimento, denominado Td e de Região Impossível (RI) de desenvolvimento (Figura 4). Na Região Impossível (RI), a adição de mais recursos ao projeto não implicará em redução no prazo. Note que a curva mostra que quanto menor o prazo almejado para a conclusão do projeto, maior será o esforço requerido e consequentemente maior o custo do projeto. O aumento do esforço para reduzir o prazo acontece através da realização de horas extras e da inclusão de pessoal adicional, gerando retrabalho. No entanto, a redução de prazo tem um limite, como demonstra a região impossível. O método utilizado para estimar o prazo dos projetos (Td) é baseado na fórmula de Capers Jones [Jones, 2007]. A fórmula de Capers Jones estima o prazo, baseando-se no tamanho do projeto em Pontos de Função, da seguinte maneira: Td: prazo de desenvolvimento V: tamanho do projeto em Pontos de Função t: o expoente t é definido de acordo com a Tabela 7 Td = V t Guia de Contagem APF ATI Pág. 17 de 65

18 Figura 4: Relação entre a Estimativa de Prazo e de Esforço [Jones 2007] Tabela 7: Expoente t por tipo de Projeto Tipo de Sistema Expoente t Sistema Comum Mainframe (desenvolvimento de 0,32 a 0,33 sistema com alto grau de reuso ou manutenção evolutiva) Sistema Comum Web ou Cliente Servidor 0,34 a 0,35 Sistema OO (se o projeto OO não for novidade para 0,36 equipe, não tiver o desenvolvimento de componentes reusáveis, considerar sistema comum) Sistema Cliente/Servidor (com alta complexidade 0,37 arquitetural e integração com outros sistemas) Sistemas Gerenciais complexos com muitas integrações, 0,39 Datawarehousing, Geoprocessamento, Workflow Software Básico, Frameworks, Sistemas Comerciais 0,40 É importante destacar que o método só funciona para projetos com mais de 100 PFs. Caso o projeto seja menor, o prazo deve ser obtido por meio de WBS. O prazo calculado considera todo o ciclo de vida do projeto, desde a fase de requisitos até a implantação. 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 necessário receber o projeto em um prazo menor que o tudo calculado, recomenda-se propor um processo de desenvolvimento incremental, priorizando funcionalidades em cada iteração de acordo com a necessidade dele. Caso, ainda assim, a estimativa não atenda às necessidades do cliente, então pode-se reduzir o Td em até 25%, observando-se a Região Impossível. No entanto, quanto mais perto da Região Impossível, o esforço e o custo do projeto aumentam de maneira exponencial. Assim, de um Guia de Contagem APF ATI Pág. 18 de 65

19 modo geral, a redução de prazo de 10 % implica no aumento de esforço de 25%; a redução de prazo de 20% implica no aumento de esforço de 50% ; a redução de prazo de 25% implica em um aumento de esforço de 60%. Não é recomendada a redução de prazo em mais de 20%. Os percentuais de aumento de esforço são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão ESTIMATIVA DE CUSTO A estimativa de custo do projeto deve levar em consideração o custo de um ponto de função. A contratada já deverá considerar o custo da hora de todos os profissionais envolvidos no desenvolvimento da solução de software. O cálculo do custo do projeto (CP) será então da seguinte forma: CP = QPF x CPF Onde: QPF: Tamanho do Projeto em PF CPF: Custo para implementar um Ponto de Função na plataforma em questão 4. CONTAGEM DE PONTOS DE FUNÇÃO PARA PROJETOS DE MANUTENÇÃO Esta seção tem como propósito descrever os diversos tipos de projetos de manutenção e mostrar uma solução para o seu dimensionamento em Pontos de Função, visto que o manual de práticas de contagem CPM não contempla projetos de manutenção (maintenance) apenas o de Melhoria (enhancement). Quanto à documentação de projetos de manutenção pequenos (menores que 100 PF), deve-se registrar a solicitação e documentar os requisitos da aplicação impactada pela demanda, de forma detalhada, visando apoiar a contagem de Pontos de Função da demanda. É importante também documentar as estimativas e a contagem de Pontos de Função PROJETOS DE MELHORIA O Projeto de Melhoria (enhancement), também denominada de projeto de melhoria funcional, ou manutenção evolutiva, está associado às mudanças em requisitos funcionais da aplicação, ou seja, a inclusão de novas funcionalidades, alteração ou exclusão de funcionalidades em aplicações implantadas. Guia de Contagem APF ATI Pág. 19 de 65

20 Segundo o padrão IEEE Std 1229 [IEEE 1998], esta manutenção seria um tipo de manutenção adaptativa, definida como: modificação de um produto de software concluído após a entrega para mantê-lo funcionando adequadamente em um ambiente com mudanças. O projeto de melhoria é considerado um tipo de projeto de manutenção adaptativa com mudanças em requisitos funcionais da aplicação, ou seja, com funcionalidades incluídas, alteradas ou excluídas na aplicação, segundo o CPM 4.3. 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. Uma função de dados (Arquivo Lógico Interno ou Arquivo de Interface Externa) é considerada alterada, quando a alteração contemplar mudanças de item de dados, inclusão ou exclusão de item de dados. Ou mudança de tamanho (número de posições) ou tipo de campo (por exemplo: mudança de numérico ou alfanumérico), sendo que esta ocorre por mudança de regra de negócio do usuário. Uma função transacional (Entrada Externa, Consulta Externa e Saída Externa) é considerada alterada, quando a alteração contemplar: Mudança de itens de dados em uma função existente; Mudança de arquivos referenciados; Mudança de lógica de processamento, segundo as ações das lógicas e processamento do CPM 4.3 A Lógica de Processamento é definida como requisitos especificamente solicitados pelo usuário para completar um processo elementar. Esses requisitos devem incluir as seguintes ações: Validações são executadas Fórmulas matemáticas e cálculos são executados Valores equivalentes são convertidos Dados são filtrados e selecionados através da utilização de critérios Condições são analisadas para verificar quais são aplicáveis Um ou mais ALIs são atualizados Um ou mais ALIs e AIEs são referenciados Dados ou informações de controle são recuperados Dados derivados são criados através da transformação de dados existentes, para criar dados adicionais O comportamento do sistema é alterado Preparar e apresentar informações para fora da fronteira Receber dados ou informações de controle que entram pela fronteira da aplicação Guia de Contagem APF ATI Pág. 20 de 65

21 Dados são reordenados A contagem ou estimativa de Pontos de Função de projetos de manutenção evolutiva (projetos de melhoria) seguirá conforme preconizada pela publicação "Function Point Analysis for Software Enhancement Guidelines" da Nesma Netherlands Software Metrics Users Association [NESMA, 2009], entidade que aprofunda o tema e apresenta alternativas técnicas à proposta original do IFPUG. Contudo é recomendado que para contratações sejam apenas definidas o padrões do IFPUG e que caso sejam necessárias a adoção da NESMA (2009) como boas práticas de projetos de melhoria, que ela seja escrita no edital e não citada como NESMA para que não haja confusão do fornecedor sobre quando usar NESMA ou quando usar o IFPUG. Pela NESMA temos: TAMANHO EM PF = (PF INCLUIDO + PF EXCLUIDO + PF ALTERADO + PF CONVERSÃO) Definições: aplicação. PF_INCLUÍDO = Pontos de Função associados às novas funcionalidades que farão parte da PF_ALTERADO = Pontos de Função associados às funcionalidades existentes na aplicação que serão alteradas no projeto de manutenção, incluso o fator de impacto conforme preconizada pela [NESMA, 2009]. PF_EXCLUÍDO = Pontos de Função associados às funcionalidades existentes na aplicação que serão excluídas no projeto de manutenção, incluso o fator de impacto conforme preconizada pela [NESMA, 2009]. PF_CONVERSÃO = Pontos de Função associados às funcionalidades de conversão de dados dos projetos de melhoria. Exemplos de funções de conversão incluem: migração ou carga inicial de dados para popular as novas tabelas criadas e relatórios associados à migração de dados. Importante ressaltar que a contagem dos PF_Conversão são efetuadas de forma separada da contagem dos PF_Não_Ajustados, por serem de produtividades diferentes, ou seja, ao contar os PF_Conversão utilizar produtividade própria, quando for o caso. Na maioria casos, as operações de alteração e inclusão possuem um tratamento diferenciado em relação à inclusão, alguns pesos podem ser atribuídos a tais tarefas como forma de compensar o esforço e custo associado a tais tarefas. Esta prática é comum no mercado e conhecida como Deflator. A sugestão da NESMA para tal aplicação e a que será seguida pela ATI é: Guia de Contagem APF ATI Pág. 21 de 65

22 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 7 (para funções de dados); PF_FT_ALTERADO = FT-QPA x FFT, sendo FFT entre 0,25 e 1,50, conforme Tabela 8 (para funções transacionais); PF_ALTERADO = PF_FD_ALTERADO + PF_FT_ALTERADO. Onde: QPI = Quantidade de Pontos de Função incluídos; QPE = Quantidade de Pontos de Função excluídos; PF_FD_ALTERADO = Pontos de Função alterados para Funções de Dados; PF_FT_ALTERADO = Pontos de Função alterados para Funções Transacionais; FD-QPA = Quantidade de Pontos de Função alterados em funções de dados; FT-QPA = Quantidade de Pontos de Função alterados em funções transacionais; FFD = Fator de impacto de alterações em funções de dados; FFT = Fator de impacto de alterações em funções transacionais O cálculo dos fatores de impacto é obtido através dos percentuais de alterações conforme abaixo: Funções de Dados: Percentual de alterações em funções de dados (PFD) = QTDEA / (QTDET x 100) QTDEA = Quantidade de Tipos de Dados Elementares Alterados QTDET = Quantidade de Tipos de Dados Elementares Totais Com o valor obtido em PFD, procura-se na tabela qual o valor do fator de impacto: Tabela 7: Calculo do PFD para função de Dados [NESMA 2009] Fator de Impacto em Funções de Dados Alteradas (FFD) Entre 33% e Entre 66% e 66% 100% PFD Entre 0 e 33% Fator de Impacto (FFD) Maior que 100% 0,25 0,5 0,75 1 Funções Transacionais: Percentual de alterações em funções transacionais (PFT1) = QTDEA / QTDET x 100 Guia de Contagem APF ATI Pág. 22 de 65

23 Percentual de alterações em funções transacionais (PFT2) = QFDLA / QFDLT x 100 QTDEA = Quantidade de Tipos de Dados Elementares Alterados QTDET = Quantidade de Tipos de Dados Elementares Totais QFDLA = Quantidade de Funções de Dados Lógicos Alterados QFDLT = Quantidade de Funções de Dados Lógicos Totais Tabela 8: Calculo do FFT para função de Dados [NESMA 2009] Fator de Impacto em Funções Transacionais Alteradas (FFT) PFT2 / PFT1 Entre 0 e 66% Entre 66% e Maior que 100% 100% Entre 0% e 33% 0,25 0,5 0,75 Entre 33% e 66% 0,5 0,75 1 Entre 66% e 100% 0,75 1 1,25 Maior que 100% 1 1,25 1,5 Caso FFT seja maior que 1, recomenda-se reconsiderar a melhoria PROJETOS DE MANUTENÇÃO CORRETIVA Mesmo com a execução de atividades de garantia da qualidade, pode-se identificar defeitos na aplicação entregue. A manutenção corretiva altera o software para correção dos defeitos. Encontra-se nesta categoria, as demandas de correção de erros (bugs) em funcionalidades de sistemas em produção. É importante destacar que as demandas de manutenção corretiva freqüentemente precisam ser atendidas com urgência. Assim, o grau de criticidade do projeto poderá trazer impacto nas estimativas de custo e esforço. O padrão IEEE [IEEE,1998] define um tipo de manutenção corretiva, denominado de Manutenção Emergencial como manutenção corretiva não programada executada para manter o sistema em estado operacional. Quando o sistema em produção tiver sido desenvolvido pela contratada, a manutenção corretiva será do tipo Garantia, conforme prazos e demais cláusulas do contrato em questão. Quando o sistema não tiver sido desenvolvido pela contratada, deverá ser estimado e calculado o tamanho do projeto de manutenção corretiva. A estimativa e dimensionamento de tamanho de projetos de manutenção corretiva em Pontos de Função devem levar em consideração a documentação do sistema disponível e os artefatos a serem mantidos sendo aplicados alguns deflatores. Seguem as fórmulas a serem consideradas: Guia de Contagem APF ATI Pág. 23 de 65

24 a) Aplicação sem documentação ou com documentação desatualizada ou documentação incompleta e sem redocumentação de requisitos Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades corrigidas considera 70% do PF_Alterado, observando os conceitos do CPM 4.3, apresentados na seção 4.1. PF = PF_ALTERADO x 0,70 b) Aplicação sem documentação ou com documentação desatualizada ou incompleta ou completa e com redocumentação de requisitos Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades corrigidas considera 80% do PF_Alterado, seguindo os conceitos do CPM 4.3, apresentados na seção 4.1. Deve-se destacar que além da correção as funcionalidades em questão e da documentação do projeto de manutenção corretiva realizado, a documentação das funcionalidades deve ser atualizada pela contratada. PF = PF_ALTERADO x 0,80 c) Aplicação com documentação completa Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades corrigidas considera 60% do PF_Alterado, seguindo os conceitos do CPM 4.3, mostrados na seção 4.1. Deve-se ressaltar que não há necessidade de correção da documentação do sistema, apenas dos artefatos associados à correção do código. PF = PF_ALTERADO x 0,60 Em todos os três itens acima, os percentuais de multiplicação são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão MANUTENÇÃO COSMÉTICA São consideradas manutenções cosméticas ou Adaptativas Mudança de Interface, as demandas associadas à alterações de interface, por exemplo, fonte de letra, cores de telas, logotipos, mudança de botões na tela, mudança de posição de campos ou texto na tela. Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades corrigidas considera 10% do PF_Alterado, seguindo os conceitos do CPM 4.3. Não será Guia de Contagem APF ATI Pág. 24 de 65

25 contemplada a redocumentação das funcionalidades da aplicação impactadas pela manutenção nas demandas desta categoria. PF = PF_ALTERADO x 0, MANUTENÇÃO ADAPTATIVA EM REQUISITOS NÃO FUNCIONAIS Seguindo os conceitos da IEEE, existem vários tipos de Manutenção Adaptativa. Quando há mudança em requisitos funcionais, estes projetos são denominados de projetos de Melhoria, descritos na seção 4.1. Quando há mudança em requisitos não funcionais de interface, estes projetos são denominados de Manutenção Cosmética ou Manutenção Adaptativa Mudança de Interface. Esta seção visa apresentar alguns tipos de manutenções adaptativas associadas às mudanças em requisitos não funcionais da aplicação, a saber: Redesenvolvimento de projetos em outra plataforma, Atualização de plataforma, Adequação de funcionalidades às mudanças de negócio. Caso sejam identificados outros tipos de projetos de manutenção adaptativa em requisitos não funcionais, estes devem ser definidos e incorporados nesse Manual de Contagem REDESENVOLVIMENTO DE PROJETOS EM OUTRA PLATAFORMA São 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, freqüentemente, encontram-se sem documentação, então serão considerados como novos projetos de desenvolvimento. Assim, será utilizada a fórmula de Projetos de Desenvolvimento do CPM 4.3. PF = PF_NÃO_AJUSTADO + PF_CONVERSÃO PF_CONVERSÃO = Pontos de Função associados às funcionalidades de conversão de dados dos projetos de desenvolvimento. Exemplos de funções de conversão incluem: migração ou carga inicial de dados para popular as novas tabelas criadas e relatórios associados à migração de dados. Importante ressaltar que a contagem dos PF_Conversão são efetuadas de forma separada da contagem dos PF_Não_Ajustado, por serem de produtividades diferentes, ou seja, ao contar os PF_Conversão utilizar produtividade própria, quando for o caso. Neste caso, poderá ser criado um multiplicador conforme avaliação da base histórica dos serviços realizados no órgão ATUALIZAÇÃO DE PLATAFORMA São consideradas nesta categoria, demandas para uma aplicação existente ou parte de uma aplicação existente executar em versões mais atuais de browsers (ex: versão atual do Internet Explorer, Guia de Contagem APF ATI Pág. 25 de 65

26 Mozila, Firefox,...) ou de linguagens de programação (ex: versão mais atual do JAVA ou do Banco de Dados). Também são consideradas nesta categoria aplicações Web desenvolvidas para executar em Internet Explorer que precisam executar também em browser em software livre. Nesta categoria foram observadas demandas dos seguintes tipos: a) Atualização de Plataforma com necessidade de redocumentação de requisitos Nestes casos, a aferição do tamanho em Pontos de Função da aplicação ou da parte da aplicação que sofreu impacto considera 50% dos PFs, seguindo a fórmula de projetos de desenvolvimento do CPM 4.3 e as funções de conversão de dados, se aplicável. Deve-se destacar que além da adequação as funcionalidades em questão e da documentação do projeto de manutenção adaptativa realizado, a documentação das funcionalidades deve ser atualizada. PF = (PF_NÃO_AJUSTADO x 0,50) + PF_CONVERSÃO b) Atualização de Plataforma sem necessidade de redocumentação de requisitos Nestes casos, a aferição do tamanho em Pontos de Função da aplicação ou da parte da aplicação que sofreu impacto considera 40% dos PFs, seguindo a fórmula de desenvolvimento do CPM 4.3 e as funções de conversão de dados, se aplicável. PF = (PF_NÃO_AJUSTADO x 0,40) + PF_CONVERSÃO Nos dois itens acima, os percentuais de multiplicação são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão ADEQUAÇÃO DE FUNCIONALIDADES ÀS MUDANÇAS DE NEGÓCIO São consideradas nesta categoria as demandas de manutenção adaptativa associadas à adequação de funcionalidades às mudanças de regras de negócio ou de Legislação ou requisitos de usabilidade que não se enquadram nas funções alteradas do Projeto de Melhoria, seguindo as regras de contagem do CPM. Observe que tais solicitações envolvem aspectos não funcionais, sem alteração em requisitos funcionais. Por exemplo: replicação de funcionalidade (chamar uma consulta existente na aplicação de outra tela, por demanda do usuário); replicação de base de dados ou criação de base temporária para resolver problemas de performance ou segurança; Alteração no software para adaptação às alterações realizadas em rotinas de integração com outros software (ex: alteração em sub-rotinas chamadas por este software). Nesta categoria foram observadas demandas dos seguintes tipos: a) Adequação de funcionalidades com necessidade de redocumentação Guia de Contagem APF ATI Pág. 26 de 65

27 Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades que sofreram impacto deve considerar 80% do PF_Alterado, seguindo os conceitos do CPM 4.3, apresentados na seção 4.1. Deve-se destacar que além da adequação das funcionalidades em questão e da documentação do projeto de manutenção adaptativa realizado, a documentação das funcionalidades deve ser atualizada. PF = PF_ALTERADO x 0,80 b) Adequação de funcionalidades sem necessidade de redocumentação de requisitos Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades que sofreram impacto deve considerar 70% do PF_Alterado, seguindo os conceitos do CPM 4.3, apresentados na seção 4.1. Não será contemplada a documentação das funcionalidades nas demandas desta categoria. PF = PF_ALTERADO x 0,70 Nos dois itens acima, os percentuais de multiplicação são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão. Para outros tipos de projetos de manutenção adaptativa não definidos neste documento, considerar um percentual do PF_Alterado, variando de 30% a 80%, de acordo com as características do requisito não funcional alterado. Versões futuras deste Manual devem contemplar os novos tipos não definidos neste documento APURAÇÃO ESPECIAL São funcionalidades executadas apenas uma vez para: corrigir problemas de dados incorretos na base dados das aplicações ou atualizar dados em bases de dados de aplicações, detalhado no item ; gerar um relatório específico ou arquivo para o usuário por meio de recuperação de informações nas bases da aplicação. Caso a apuração seja de correção de dados, devido a erros de funcionalidades de aplicações desenvolvidas pela contratada, observar as cláusulas contratuais com relação a garantias e prazos de correção APURAÇÃO ESPECIAL BASE DE DADOS Uma apuração especial é um projeto que inclui a geração de procedimentos para atualização da base de dados. Deve-se destacar que estas funções são executadas apenas uma vez, não fazendo parte da aplicação, visando a correção de dados incorretos na base de dados da aplicação ou atualização em Guia de Contagem APF ATI Pág. 27 de 65

28 função de modificação da estrutura de dados, por exemplo inclusão do indicador de matriz sim ou não para um CNPJ. Nestes casos, a contagem de Pontos de Função das funcionalidades desenvolvidas. Geralmente, estas funcionalidades são classificadas como Entradas Externas. PF = PF_NÃO_AJUSTADO Deve-se ressaltar que as funções de conversão de dados (carga inicial de dados que ocorre na implantação de projetos de desenvolvimento ou de melhoria) não são apurações especiais. Estas funções fazem parte do projeto de desenvolvimento ou de melhoria em questão, portanto devem ser contadas junto com estes projetos e não como apuração especial. Assim, nestes casos, considera-se as fórmulas de contagem de Pontos de Função dos projetos em questão. Em alguns casos de Apuração Especial Atualização de dados, o usuário solicita uma consulta prévia das informações atualizadas para validação. De fato, é uma prática interessante para evitar informações errôneas na base de produção dos sistemas. Esta Consulta Prévia, classificada como Consulta Externa ou Saída Externa deve ser dimensionada, considerando-se 60% do tamanho da funcionalidade em questão, conforme a fórmula abaixo: PF = PF_NÃO_AJUSTADO x 0, APURAÇÃO ESPECIAL GERAÇÃO DE RELATÓRIOS Uma apuração especial é um projeto que inclui a geração de relatórios em uma ou mais mídias para o usuário. Em alguns casos, são solicitadas extrações de dados e envio dos dados para outros sistemas. Caso neste envio de dados sejam requisitadas atualizações no sistema de origem, então estas funções são Saídas Externas, devido à atualização do Arquivo Lógico Interno. Deve-se destacar que estas funções são executadas apenas uma vez, não fazendo parte da aplicação. Nestes casos, considera-se contagem de Pontos de Função das funcionalidades desenvolvidas. Freqüentemente, estas funcionalidades são classificadas como Saídas Externas. Também podem ser classificadas como Consultas Externas, caso não possuam cálculos ou criação de dados derivados. PF = PF_NÃO_AJUSTADO MANUTENÇÃO EM PÁGINAS ESTÁTICAS DE INTRANET, INTERNET OU PORTAL Nesta seção são tratadas manutenções específicas em páginas estáticas de Portais, Intranets ou Websites. A demanda consiste na publicação de páginas HTML. Estas demandas são consideradas como desenvolvimento de consultas com a utilização de ferramentas para apoiar a publicação. Nestes casos, Guia de Contagem APF ATI Pág. 28 de 65

29 considera-se 50% dos Pontos de Função das consultas desenvolvidas. Cada página é contada como uma consulta. As consultas são consideradas Consultas Externas Simples (3 PF). QTD_SIMPLES: Quantidade de Páginas com complexidade Simples PF_SIMPLES: QTD_SIMPLES X 0,5 QTD_INTERMEDIARIA: Quantidade de Páginas com complexidade Intermediária PF_ INTERMEDIARIA: QTD_ INTERMEDIARIA X 0,8 QTD_COMPLEXAS: Quantidade de Páginas com complexidade Complexa PF_ COMPLEXAS: QTD_ COMPLEXAS X 1,2 PF_TOTAL = PF_SIMPLES + PF_INTERMEDIARIA + PF_ COMPLEXAS * Deve ser definido de forma clara como classificar cada página em uma das categorias. Exemplo: O Portal XXX será desenvolvido e foi verificado que o mesmo é composto de: 50 páginas simples 20 páginas intermediárias 10 páginas complexas PF_SIMPLES = 50 * 0,5 = 25 PF_INTERMEDIARIA = 20 * 0,8 = 16 PF_COMPLEXA = 10 * 1,2 = 12 PF_TOTAL = = MANUTENÇÃO DE DOCUMENTAÇÃO DE SISTEMAS LEGADOS Nesta seção são tratadas demandas de documentação ou atualização de documentação de sistemas legados. Observe que o desenvolvedor deve realizar uma Engenharia Reversa da aplicação para gerar a documentação. Para este tipo de projeto, caso a demanda seja apenas a documentação de requisitos, devem ser considerados 20% dos Pontos de Função da aplicação em questão, conforme a fórmula abaixo. Guia de Contagem APF ATI Pág. 29 de 65

30 PF = PF_NÃO_AJUSTADO x 0,20 Caso a demanda seja a geração de artefatos de documentação 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 cláusulas contratuais e documentadas no documento de estimativas do projeto VERIFICAÇÃO DE ERROS São consideradas verificações de erro ou análise e solução de problemas as demandas referentes a todo comportamento anormal ou indevido apontado pelo cliente nos sistemas aplicativos. Neste caso, a equipe de desenvolvimento da ATI se mobilizará para encontrar a(s) causa(s) do problema ocorrido. Se for constatado erro de sistema, a demanda será atendida como manutenção corretiva. Entretanto, uma vez não constatado o problema apontado pelo cliente ou o mesmo for decorrente de regras de negócio implementadas ou utilização incorreta das funcionalidades, será realizada a aferição do tamanho em Pontos de Função das funcionalidades verificadas, e será considerado 25%. PF = PF_NÃO_AJUSTADO x 0, FATOR DE CRITICIDADE DE SOLICITAÇÃO DE SERVIÇO Em função da criticidade e da necessidade de alocação de recursos extras para atendimento da demanda no prazo estipulado pelo cliente, poderá ser adotado um Fator de Criticidade de 1,35 (um vírgula trinta e cinco), que deverá ser multiplicado pelo tamanho funcional da demanda considerada crítica, de modo a remunerar adequadamente o aumento do esforço de atendimento. Este fator é considerado para demandas que devem ser atendidas em finais de semana, feriados e fora do horário comercial. Entende-se como horário comercial o horário local PONTOS DE FUNÇÃO DE TESTE Muitas vezes, em projetos de manutenção o conjunto de funções de dados e funções transacionais a serem testadas é maior do que a quantidade de funções a serem implementadas, i.e., além das funcionalidades que são afetadas diretamente pelo projeto de manutenção, outras precisam ser testadas [NESMA, 2009]. O tamanho das funções a serem testadas deve ser aferido em Pontos de Função de Teste (PFT). Não considerar as funcionalidades incluídas, alteradas ou excluídas do projeto de manutenção na contagem de Pontos de Função de Teste. A contagem de PFT deve considerar o seguinte [NESMA, 2009]: Guia de Contagem APF ATI Pág. 30 de 65

31 Determinar o tamanho em Pontos de Função de cada função de dados ou transacional envolvida no teste. Calcular o tamanho em Pontos de Função de todas as funções de dados ou transacionais envolvidas no teste. A conversão do PFT em Ponto de Função deve ser feita de acordo com a fórmula abaixo: PF = PFT x 0,20 É importante ressaltar que as funções testadas consideradas no PFT devem estar documentadas. Observe que estas funções farão parte do escopo do projeto de manutenção. Nos itens da seção 4 acima, os percentuais são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão. Em casos onde não há percentuais, pode-se aplicar algum percentual, também conforme avaliação da base histórica dos serviços realizados no órgão. 5. ITENS NÃO MENSURÁVEIS Deve-se ressaltar que o processo de desenvolvimento de soluções possui várias atividades que devem ser consideradas como um projeto separado, levando-se em conta as horas realizadas, dentre outras: Treinamentos em Tecnologia, Metodologias, Métricas, etc. encontram-se nesta categoria as demandas de treinamentos em linguagens de programação, ferramentas de gestão, processos, modelos da qualidade, métricas, etc. Estes serviços são executados por consultores de terceiros, especialistas no assunto em questão. Assim, devem ser consideradas as horas de consultoria para preparação e execução do curso e o custo do deslocamento do instrutor, se for o caso. Mapeamento de Processos de Negócio: Encontram se nesta categoria as demandas de elaboração e levantamento de documentação contendo o mapeamento de processos de negócio de uma organização ou de parte de uma organização. Estes serviços são executados por consultores da ATI ou terceiros, especialistas em BPM (Business Process Modeling). Elaboração de Plano Diretor de Tecnologia da Informação (PDTI): encontram-se nesta categoria demandas para elaboração de PDTIs para clientes. Estes serviços são executados por consultores do ATI ou terceiros com o apoio dos funcionários da ATI especialistas nas atividades associadas à elaboração de um PDTI. Definição de Processo de Desenvolvimento de Soluções: Encontram-se nesta categoria demandas para definição de Processos de Software aderentes às necessidades da ATI e observando as boas práticas de modelos como CMMI, Scrum ou normas como a IN 04. Estes serviços são executados por Guia de Contagem APF ATI Pág. 31 de 65

32 consultores da ATI ou terceiros, especialistas nas atividades de processos de software e na customização de ferramentas para facilitação do processo. seguintes: Outros serviços prestados que também não possuem Pontos de Função associados são os Administração de Dados: Este serviço requer uma equipe de ADs com um número de profissionais definido junto ao Cliente/Fornecedor, dedicada para atender as demandas associadas à definição e manutenção do modelo de dados de negócio. Esta equipe fica disponível em horário comercial para atendimento das demandas. Assim, estes serviços não possuem contagem de PF associada. É importante ressaltar que as atividades de banco de dados associadas ao projeto de desenvolvimento ou de manutenção, por exemplo, preparação de ambiente (testes, homologação, implantação), desempenhadas pelos DBAs da equipe de desenvolvimento, já estão consideradas dentro do projeto de software, não cabendo cobrança adicional. Análise de Solução: Serviço de apoio destinado à análise de regras de negócio implementadas em soluções de TI. Estas demandas não possuem contagem de PF associada. Consultoria: Serviço de apoio destinado à análise de regras de negócio a serem implementadas em soluções de TI realizado por consultores especialistas da ATI. As demais modalidades de consultoria também podem ser enquadradas neste item, por exemplo, Consultoria em Métricas. Estas demandas não possuem contagem de PF associada. Outras atividades contidas em um processo de software devem ser gerenciadas dentro do projeto de desenvolvimento ou de manutenção, no entanto o esforço deve ser considerado separadamente da estimativa de esforço derivado da contagem de Pontos de Função. Estas atividades também devem ser precificadas a parte. São elas: Treinamento para Implantação: São demandas de treinamentos sobre utilização do sistema a ser implantado para os gestores de solução do cliente e usuários. O esforço deste serviço deve ser considerado separadamente da estimativa de esforço derivada da contagem de PF. O preço deste serviço deve ser calculado, levando-se em conta o preço da hora dos consultores de terceiros que estarão realizando atividades de preparação de treinamento e de instrutoria. Em alguns casos, pode ocorrer também o deslocamento do instrutor, que também deve ser cobrado do cliente. Especificação de Negócio: Esta atividade é a primeira atividade a ser executada em uma demanda de projeto de desenvolvimento e/ou de manutenção. O objetivo desta atividade é gerar a Especificação da demanda. O principal produto gerado nesta atividade é o artefato: Documento de Visão do Projeto (DV), que deve ser validado pelo cliente, por meio da assinatura do termo de aceite. Além do DV podem ser gerados outros documentos, tais como: atas de reunião, documento de requisitos não funcionais e glossário da especificação de negócio. O esforço desta atividade deve ser considerado separadamente da Guia de Contagem APF ATI Pág. 32 de 65

33 estimativa de esforço derivada da contagem de PF. É importante ressaltar que esta atividade é de responsabilidade dos Analistas de Negócios da empresa contratante, de acordo com as legislações em vigor da ATI. Portanto. Caso o cliente demande para terceiros a realização desta atividade, esta deve ser cobrada em horas de consultoria. Observe que o Documento de Visão gerado nessa atividade é o insumo para o planejamento (estimativas) e a atividade de Engenharia de Requisitos do processo de desenvolvimento de software. Suporte: Esta atividade é realizada sob demanda para solucionar diversos tipos de problemas que em sua maioria são com infra-estrutura ou de apoio a informação (suporte a usuário). A natureza destes serviços não é o desenvolvimento de software não cabendo de forma alguma a aferição por ponto de função. Help Desk: Esta atividade é realizada com a alocação de pessoas cujo objetivo é atender seja por telefone, internet ou presencialmente informações a respeito de determinados serviços da ATI. A forma mais comum de pagamento por este serviço é por profissional contratado. E mesmo assim, a natureza desse serviço também não é de desenvolvimento de software assim não cabendo pontos por função. 6. ASPECTOS NÃO CONSIDERADOS PELO IFPUG CONSIDERADOS PELA ATI Algumas atividades que não estão presentes no Manual de Práticas de Contagem (CPM 4.3.1) do IFPUG já estão resolvidas dentro do âmbito da ATI. Nesta seção iremos apresentar como a ATI considera tais aspectos MÚLTIPLAS MÍDIAS Esta subseção tem como propósito apresentar as diretrizes de Contagem de Pontos de Função utilizadas na ATI em relação ao tema Múltiplas Mídias. Esta abordagem é reconhecida pelo IFPUG. As definições apresentadas têm como base o artigo Considerations for Counting with Multiple Midia Release 1.0 publicado pelo IFPUG [IFPUG, 2009] e pelo Serpro (2010). Considerando-se a contagem de PF de funcionalidades entregues em mais de uma mídia, a aplicação das regras de contagem de Pontos de Função 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 função transacional em múltiplas mídias não deve ser utilizada na identificação da unicidade da função. A abordagem multiple instance leva em consideração que a mídia utilizada na entrega da funcionalidade é uma característica de identificação da unicidade da função. Assim, funcionalidades únicas são reconhecidas no contexto da mídia na qual elas são requisitadas para operar. Guia de Contagem APF ATI Pág. 33 de 65

34 É importante enfatizar que o IFPUG reconhece ambas abordagens single instance e multiple instance para a aplicação das regras definidas no CPM. A determinação da contagem de PF seguindo a abordagem multiple instance ou single instance depende do gestor do contrato ou gestor do produto que está relacionado com aquela contagem. As estimativas e contagens de PF realizadas pelo ATI serão baseadas na abordagem multiple instance, com exceção dos casos de consultas em.pdf,.doc,.xls e consultas idênticas em tela e papel, que serão consideradas uma única funcionalidade. A seguir são descritos os termos comuns definidos pelo IFPUG [IFPUG, 2009]: Canal: também refere-se a mídia. Múltiplos canais é sinônimo de múltiplas mídias. Mídia: descreve a maneira que os dados ou informações se movimentam para dentro e para fora de uma fronteira de aplicação, por exemplo, apresentação de dados em tela, impressora, arquivo, voz. Este termo é utilizado para incluir, dentre outros: diferentes plataformas técnicas e formatos de arquivos como diferentes mídias. Múltiplas Mídias: quando a mesma funcionalidade é entregue em mais de uma mídia. Freqüentemente, somente uma mídia é requisitada para um usuário específico em um determinado momento, por exemplo consulta de extrato bancário via internet como oposto a consulta de extrato bancário via terminal do banco. Multi-Midia: quando mais de uma mídia é necessária para entregar a função, por exemplo, uma nova notícia publicada na Internet que é apresentada em vídeo e texto. Observe que a notícia completa só é apresentada para o usuário se ele ler o texto e assistir o vídeo. Abordagem Single Instance: esta abordagem não reconhece que a mídia utilizada na entrega da função transacional é uma característica de diferenciação na identificação da unicidade da função transacional. Se duas funções entregam a mesma funcionalidade usando mídias diferentes, elas são consideradas a mesma funcionalidade em uma contagem de Pontos de Função. Abordagem Multiple Instance: esta abordagem especifica que o tamanho funcional é obtido no contexto de objetivo da contagem, permitindo uma função de negócio ser reconhecida no contexto das mídias que são requisitadas para a funcionalidade ser entregue. A abordagem multiple instance reconhece que a mídia para entrega constitui uma característica de diferenciação na identificação da unicidade da função transacional. Os cenários descritos nas seções seguintes não representam uma lista completa de situações de múltiplas mídias. O entendimento destes exemplos facilitará o entendimento de outros cenários envolvendo Guia de Contagem APF ATI Pág. 34 de 65

35 múltiplas mídias. Este Roteiro deve ser atualizado considerando a publicação de novas diretrizes do IFPUG e novos cenários que emergirão nas contagens de PFs dos projetos dos clientes do ATI. Os cenários descritos nas seções seguintes não representam uma lista completa de situações de múltiplas mídias. O entendimento destes exemplos facilitará o entendimento de outros cenários envolvendo múltiplas mídias. Este Roteiro deve ser atualizado considerando a publicação de novas diretrizes do IFPUG e novos cenários que emergirão nas contagens de PFs dos projetos dos clientes do ATI MÚLTIPLAS MÍDIAS Neste cenário, uma aplicação apresenta uma informação em uma consulta em tela. A mesma informação pode ser impressa caso requisitado pelo usuário na tela em questão. Nesses casos, a ATI utiliza a abordagem single instance, considerando que dados idênticos sendo apresentados em tela e relatório impresso devem ser contados como uma única função. Caso as lógicas de processamento da consulta em tela e do relatório em papel sejam distintas, o processo elementar não é único e, portanto, a funcionalidade será contada duas vezes. Observe que a abordagem multiple instance considera que a contagem de PF de dados idênticos sendo apresentados usando mais de um tipo de mídia deve incluir toda instância da função em cada tipo de mídia. Neste exemplo, duas funções são contadas apresentação de dados em tela; apresentação de dados impressos MESMOS DADOS DE SAÍDA COMO DADOS EM ARQUIVOS E RELATÓRIOS IMPRESSO Uma aplicação grava dados em um arquivo de saída e imprime um relatório com informações idênticas as gravadas no arquivo. Nesses casos, a ATI utiliza a abordagem single instance considerando que os dados impressos e os dados apresentados no arquivo de saída sejam idênticos. Assim, apenas uma funcionalidade será incluída na contagem de Pontos de Função. Caso as lógicas de processamento da geração do arquivo de saída e do relatório em papel sejam distintas, o processo elementar não é único e, portanto a funcionalidade será contada duas vezes. Observe que a abordagem multiple instance considera que dados idênticos estão sendo entregues em mais de um tipo de mídia e a contagem de PF incluirá todas as instâncias de tipos de mídia. Neste cenário, duas funções são contadas geração arquivo e apresentação dos dados impressos MESMOS DADOS DE ENTRADA BATCH E ON-LINE Uma informação pode ser carregada na aplicação por meio de dois métodos: arquivo batch e entrada on-line. O processamento do arquivo batch executa validações durante o processamento. O processamento on-line também executa validações das informações. Guia de Contagem APF ATI Pág. 35 de 65

36 A abordagem utilizada pela ATI é a single instance conta apenas uma funcionalidade. Na ATI, porém pode ser considerada a abordagem multiple instance que conta duas funcionalidades: a entrada de dados batch e a entrada de dados on-line quando a lógica de processamento utilizada nas validações em modo batch é diferente da lógica de processamento das validações nas entradas de dados on-line. Portanto, fica a cargo do gestor de contrato ou produto da ATI definir se será uma ou duas funcionalidades MÚLTIPLOS CANAIS DE ENTREGA DA MESMA FUNCIONALIDADE Uma funcionalidade deve ser disponibilizada em múltiplos canais, por exemplo, consulta de dados em página Web e consulta de dados no telefone celular. A abordagem single instance conta apenas uma funcionalidade. Na ATI novamente pode ser utilizada a abordagem multiple instance que conta duas funcionalidades: a consulta de dados na Web e a consulta de dados via celular. Considera-se que esta solução é justa quando a funcionalidade é desenvolvida duas vezes para os dois canais. Algumas vezes, são até projetos de desenvolvimento distintos, um projeto relativo ao sistema Web e outro para o sistema via celular. Portanto, nestes casos a ATI contará duas funcionalidades RELATÓRIOS EM MÚLTIPLOS FORMATOS Um relatório deve ser entregue em diferentes formatos, por exemplo, em um arquivo html e um formato de valores separados por vírgula. Nestes casos, conforme sugerido na abordagem multiple instance, a ATI considera a ferramenta utilizada na geração dos relatórios. Se a equipe de desenvolvimento precisar desenvolver o relatório nos dois formatos na ferramenta em questão, serão contadas duas funcionalidades. Isso porque a lógica de processamento de análise de condições para verificar quais são aplicáveis é identificada. No entanto, se a ferramenta de desenvolvimento suportar um gerador de relatórios que o usuário visualize o relatório em tela e o gerador permita ao usuário imprimir o relatório, salvar em html ou salvar no formado de valores separados por vírgula, então a ATI contará apenas uma vez, observando que a funcionalidade será da ferramenta e não da aplicação DATA WAREHOUSE Esta subseção tem como propósito apresentar as diretrizes de Contagem de Pontos de Função utilizadas na ATI em relação ao tema Data Warehouse. Esta abordagem é reconhecida pelo IFPUG. As definições apresentadas têm como base o artigo Function Points & Counting Enterprise Data Warehouses Release 1.0 publicado pelo IFPUG [IFPUG, 2007]. Um aspecto crucial da contagem de Data Warehouses que apresentou desafios significativos dos contadores de ponto de função está em definir a fronteira da aplicação. Uma fronteira impropriamente definida pode distorcer de forma considerável os resultados da análise de ponto de função. Com base nessas regras de definição de fronteira, o que segue abaixo deve ser excluído dos limites da aplicação: Guia de Contagem APF ATI Pág. 36 de 65

37 Arquivos lógicos mantidos pelo(s) sistema(s) de origem, exceto se eles são referenciados durante o processamento dos arquivos de chegada com os dados. Tabelas Temporárias, Staging Areas, Tabelas de códigos Data Marts. Estes podem ser contados como fronteiras de aplicações separadas. Algumas considerações incluem: O propósito da contagem, Os usuários são um grupo distinto; ex.: um departamento específico como marketing, diferente grupo de usuários do Data Warehouse e; A existência de dados externos além daquele disponível dentro do Data Warehouse. Figura 5 é uma representação gráfica de como a fronteira de um Data Warehouse pode ser definida. Figura 5: Figura Ilustrativa de um Fronteira de DW A Figura 5 esta mostrando um limite em volta das Staging Areas/Depósito de Dados Operacionais/Data Warehouses e limites em torno de Data Marts específicos. É uma representação gráfica Guia de Contagem APF ATI Pág. 37 de 65