Roteiro de Métricas de Software do SISP Versão 2.1

Transcrição

1

2

3 Roteiro de Métricas de Software do SISP Versão 2.1

4 Presidenta da República Dilma Vana Rousseff Ministro do Ministério do Planejamento, Orçamento e Gestão Nelson Barbosa Secretário de Logística e Tecnologia da Informação Cristiano Rocha Heckert Diretor do Departamento de Governança e Sistemas de Informação Wagner Silva de Araújo Coordenador-Geral de Sistemas de Informações Orlando Batista da Silva Neto Grupo de Métricas de Software do SISP Lucineia Turnes (SLTI/MP) Valeria Maria Siqueira Bezerra (SLTI/MP) Equipe de Elaboração da Versão 2.1 Cinthya Hiromi Seko de Oliveira SERPRO Claudia Hazan - SERPRO Daniella Elizabeth Carneiro - SERPRO George Atsushi Murakami - TCU Igor de Mesquita Barbosa - CGU Jose Romildo Araujo de Andrade DTI/SE/MP Gileno Dias dos Santos DTI/SE/MP Kátia Cristina Barbosa Loschi de Melo - SERPRO Lucineia Turnes SLTI/MP Marcia Regina Guiotti Bomfim - MPT Marcus Vinicius Borela de Castro - TCU Tadeu Rocha - CGU Valeria Maria Siqueira Bezerra SLTI/MP Roteiro de Métricas de Software do SISP 2.1

5 Roteiro de Métricas de Software do SISP Versão 2.1 Brasília 2015

6 Ministério do Planejamento, Orçamento e Gestão, Qualquer parte desta publicação pode ser reproduzida, desde que citada a fonte, de acordo com as orientações da licença Creative Commons (CC BY-NC-SA 3.0). Impresso no Brasil. Disponível em: Esta obra está licenciada por uma Licença Creative Commons - Atribuição- NãoComercial-CompartilhaIgual 3.0 Brasil Normalização Bibliográfica: CODIN/CGPLA/DIPLA B823r Brasil. Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Roteiro de Métricas de Software do SISP: versão 2.1 / Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Brasília : MP, p.: il. 1. Tecnologia da Informação. 2. Roteiro de Métrica de Software. 3. Ponto de Função. 4. Sistema de Administração dos Recursos de Tecnologia da Informação SISP. I. Título. CDU Roteiro de Métricas de Software do SISP 2.1

7 Sumário 1. Introdução Objetivo Contagem de Pontos de Função Determinar Propósito, Tipo e Escopo da Contagem e Fronteira da Aplicação Identificar Funções de Dados e Funções Transacionais Calcular Tamanho Funcional Requisitos Não Funcionais Cálculo de Pontos de Função para o SISP Projeto de Desenvolvimento Projeto de Melhoria Projetos de Migração de Dados Manutenção Corretiva Mudança de Plataforma Mudança de Plataforma - Linguagem de Programação Mudança de Plataforma - Banco de Dados Atualização de Versão Atualização de Versão Linguagem de Programação Atualização de Versão Browser Atualização de Versão Banco de Dados Manutenção em Interface Adaptação em Funcionalidades sem Alteração de Requisitos Funcionais Apuração Especial Apuração Especial Base de Dados Apuração Especial Geração de Relatórios Apuração Especial Reexecução Atualização de Dados Desenvolvimento, Manutenção e Publicação de Páginas Estáticas de Intranet, Internet ou Portal Manutenção de Documentação de Sistemas Legados Verificação de Erros Pontos de Função de Teste Componente Interno Reusável Orientações Complementares para Contagem Contagem de Pontos de Função com Múltiplas Mídias Cenário 1: Mesmos dados apresentados em tela e impressos Cenário 2: Mesmos dados de saída como dados em arquivo e relatório impresso Cenário 3: Mesmos dados de entrada batch e on-line Cenário 4: Múltiplos canais de entrega da mesma funcionalidade Cenário 5: Relatório em múltiplos formatos Considerações Especiais para Planejamento e Acompanhamento de Projetos Diretrizes para Planejamento: Estimativas de Projetos de Software Contagem Estimativa de Pontos de Função (CEPF) Estimativa de Esforço de Projetos de Software Distribuição de Esforço por Fase do Projeto Estimativa de Prazo de Projetos de Software Alocação de Equipe ao Projeto Método para Estimativa de Custo Estimativa de Recursos Computacionais Diretrizes para Acompanhamento de Projetos...38 Roteiro de Métricas de Software do SISP 2.1

8 6.2.1 Considerações sobre Mudança de Requisitos Considerações sobre Projetos Cancelados Gerenciamento de Progresso de Projetos Considerações sobre Redução de Cronograma Fator de Criticidade de Solicitação de Serviço Contagem de Pontos de Função no Desenvolvimento de Software utilizando Métodos Ágeis Conceitos Orientações Tratamento de Mudanças em Funcionalidades no Processo Ágil Fatores que Influenciam o Número de Mudanças em Funcionalidades no Processo Ágil Exemplo de Aplicação da Proposta Atividades Sem Contagem de Pontos de Função Processo de Revisão do Roteiro 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 Bibliográficas...57 Anexo I Portaria SLTI/MP Nº 31, de 29 novembro de Anexo II Formalização Simples de Requisitos Projetos de Manutenção Pequenos (< 100 PF)..60 Anexo III Modelo de Documento de Contagem de Pontos de Função Projetos de Manutenção Pequenos (< 100 PF)...64 Anexo IV - Como Evitar Armadilhas em Contratos de Desenvolvimento e Manutenção de Sistemas...65 Anexo V Resumo da Técnica EFP (Enhancement Function Points) publicada pela NESMA...71 Anexo VI Notas Técnicas das Versões Anteriores deste Roteiro...73 Índice de Figuras Figura 1: Procedimento de Contagem de Pontos de Função...4 Figura 2: Processo de Estimativas de Projetos de Software [Hazan, 2008]...27 Figura 3: Modelo Lógico da Análise de Pontos de Função...30 Figura 4: Relação entre a Estimativa de Prazo e de Esforço...35 Índice de Tabelas Tabela 1: Contribuição Funcional dos Tipos Funcionais...5 Tabela 2: Identificação dos Arquivos Lógicos Internos da Aplicação...31 Tabela 3: Identificação dos Arquivos de Interface Externa da Aplicação...31 Tabela 4: Identificação das Entradas Externas da Aplicação...32 Tabela 5: Identificação das Consultas Externas da Aplicação...32 Tabela 6: Identificação das Saídas Externas da Aplicação...33 Tabela 7: Distribuição de Esforço por Macroatividades do Projeto...34 Tabela 8: Expoente t por tipo de Projeto...35 Tabela 9: Estimativa de Prazo de Projetos menores que 100 PF...36 Tabela 10: Percentuais definidos para a mudança de requisitos...39 Tabela 11: Planejamento do Backlog das Sprints da Release N...52 Tabela 12: Contagem Detalhada de Pontos de Função da Release N...53 Tabela 13: Contagem de PF da Release N para Baseline da Aplicação...54 Roteiro de Métricas de Software do SISP 2.1

9 1. Introdução Diversas instituições públicas e privadas têm utilizado a métrica Ponto de Função (PF) nas estimativas e dimensionamento de tamanho funcional de projetos de software devido aos diversos benefícios de utilização desta métrica, destacando-se: regras de contagem objetivas, independência da solução tecnológica utilizada e facilidade de estimativa nas fases iniciais do ciclo de vida do software. É importante ressaltar que a Instrução Normativa SLTI/MP N 4, de 11 de setembro de 2014, recomenda o uso de métricas em contratos de projetos de software, restringindo o uso da métrica de esforço homem-hora. Além disso, a Portaria SLTI/MP nº 31, de 29 novembro de 2010, recomenda o uso da métrica Ponto 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 serviços de desenvolvimento e manutenção de soluções de software. O Tribunal de Contas da União (TCU) tem publicado vários acórdãos que recomendam a utilização da métrica Ponto de Função Não Ajustado em contratos de prestação de serviços de desenvolvimento e manutenção de sistemas, entre os quais podem ser citados: Acórdão nº 1.782/2007: recomenda o uso da métrica Ponto de Função como forma de pagamento dos serviços contratados de desenvolvimento e manutenção de sistemas, ao invés de se realizar a conversão dos pontos de função em horas, baseado na produtividade média da tecnologia empregada. Acórdão nº 1.910/2007: em atenção ao princípio da eficiência, faz duas recomendações: adotar a técnica de medição por ponto de função sem ajustes pelas características da aplicação (pontos de função não ajustados) e diferenciar, na fórmula de cálculo, os custos dos pontos de função para desenvolver novas funcionalidades, daqueles relativos a supressões ou alterações de funcionalidades existentes. Acórdãos n os 1.125/2009 e 1.274/2010: determinam não vincular a métrica de tamanho funcional (Ponto de Função) com a de esforço (homem-hora). Acórdãos n os 2.348/2009 e 1.647/2010: reforçam a determinação de não usar qualquer tipo de fator de ajuste na medição por pontos de função na contratação de serviços de desenvolvimento de software, para impossibilitar alterações na remuneração da funcionalidade medida, por se basear em interpretação subjetiva dos níveis das características gerais de sistemas, em desacordo com o previsto no art. 54, 1º, da Lei nº 8.666/93 e art. 2º, XXIV, da IN SLTI nº 04/2014. Além disso, o acórdão 1.647/2010 determina que não se use exclusivamente o Manual de Práticas de Contagem (CPM) do IFPUG nas contratações de serviços de desenvolvimento, e que sejam adicionadas cláusulas complementares que elucidem pontos não abordados pelo CPM; e recomenda a diferenciação, em sua fórmula de cálculo, dos custos de pontos de função para o desenvolvimento completo de uma funcionalidade (todas as fases do ciclo de desenvolvimento) daqueles necessários à execução de apenas uma fase do ciclo. O Manual de Práticas de Contagem de Pontos de Função (CPM 4.3) [IFPUG, 2010b], publicado pelo International Function Point Users Group (IFPUG), define as regras de contagem de pontos de função. É importante ressaltar que a métrica Ponto de Função foi concebida como uma medida de tamanho funcional para projetos de desenvolvimento e de melhoria (manutenção evolutiva) de software. No entanto, os projetos de software não estão limitados a projetos de desenvolvimento e de melhoria. Desta forma, torna-se essencial a definição de métricas para dimensionar o tamanho de outros tipos de projetos de manutenção, os quais são itens não mensuráveis pelo CPM. Roteiro de Métricas de Software do SISP 2.1 1

10 Além disso, a contagem de pontos de função é baseada no projeto lógico da aplicação (logical design). Nas fases iniciais do ciclo de vida do software, o insumo para a definição das estimativas do projeto é um documento inicial de requisitos, por exemplo: documento de visão 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 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 e custo dos projetos de software a partir do tamanho funcional estimado do projeto. É importante frisar também que o CPM é um documento que se destina a mensurar o tamanho funcional de projetos de software, não tendo por objetivo principal suportar contratos de prestação de serviços de desenvolvimento e manutenção de sistemas. Assim, torna-se necessário criar roteiros complementares, contemplando questões não abordadas pelo manual do IFPUG, mas vivenciadas pelos órgãos e entidades do SISP. O restante deste documento encontra-se organizado da seguinte forma: o capítulo 2 descreve os objetivos e as referências consultadas para a elaboração deste documento; o capítulo 3 apresenta algumas definições básicas para a contagem de pontos de função; o capítulo 4 define métricas baseadas em Ponto de Função para dimensionar projetos de desenvolvimento e vários tipos de projetos de manutenção de software; o capítulo 5 estabelece diretrizes para contagem de múltiplas mídias; o capitulo 6 define um processo de estimativas e recomendações para o gerenciamento de projetos contratados com base em métricas; o capítulo 7 traz uma proposta para conciliar o uso da métrica Ponto de Função em contratações de desenvolvimento de software usando métodos ágeis com o objetivo de minimizar os riscos para o tratamento de mudanças em funcionalidades; o capítulo 8 apresenta algumas atividades que não devem ser consideradas nas contagens de pontos de função; o capítulo 9 apresenta o processo de revisão deste guia de contagem; finalmente, o capítulo 10 conclui o documento, apresentando sugestões para trabalhos futuros. Roteiro de Métricas de Software do SISP 2.1 2

11 2. Objetivo Este documento tem como objetivo principal apresentar um roteiro de métricas, com base nas regras de contagem de pontos de função do Manual de Práticas de Contagem (CPM 4.3), para vários tipos de projetos de desenvolvimento e de manutenção de sistemas, promovendo o uso de métricas objetivas nos contratos de prestação de serviços desses projetos. Além da contagem de pontos de função, este roteiro apresenta um processo de estimativas com base na métrica Ponto de Função, visando apoiar as organizações nas estimativas de tamanho, custo, prazo e esforço de seus projetos desenvolvidos internamente ou contratados. A versão 2.1 apresenta uma pequena variação com relação à versão anterior 2.0: alteração no fator de impacto de 40% para 30% para as funcionalidades excluídas de um Projeto de Melhoria (seção 4.2). ajuste no tratamento e contagem em pontos de função para o item denominado Componente Interno Reusável, apresentado na seção 4.15 deste documento. correção dos percentuais da Tabela 10 referentes ao retrabalho decorrente de mudanças de requisitos durante o desenvolvimento ou manutenção do software. Consequentemente, ainda na subseção Considerações sobre Mudanças de Requisitos foram atualizados os exemplos que mostram a aplicação desses percentuais da Tabela 10. criação de um novo capítulo (Capítulo 7) que aborda o tratamento das mudanças em funcionalidades em um projeto de desenvolvimento usando métodos ágeis, principalmente, para o cenário de contratações de software usando a métrica Ponto de Função. A alteração do modelo de contratação de software, decorrente da implantação de um processo de medição de software mais objetivo, requer uma mudança cultural, devido à mudança do paradigma homem-hora para a nova forma de contratação com base na métrica Ponto de Função. Este roteiro tem como propósito apoiar os órgãos e entidades do SISP nessa mudança cultural. É recomendável a leitura do Anexo IV, pois apresenta vários tópicos importantes a serem observados pelos órgãos contratantes na utilização do modelo de contratação de software usando a métrica PF. Duas premissas foram consideradas na elaboração deste roteiro: Simplicidade: Este roteiro deve ser simples para incentivar os órgãos e entidades do SISP a utilizar a métrica Ponto de Função como medida padrão no estabelecimento de contratos de prestação de serviços de desenvolvimento e manutenção de sistemas. Consistência: Este roteiro deve definir critérios objetivos, visando prover a consistência no uso de métricas em contratos de prestação de serviços de desenvolvimento e manutenção de sistemas. Deste modo, dois profissionais ao aplicarem o roteiro no dimensionamento de um projeto de software devem obter o mesmo resultado. 3. Contagem de Pontos de Função A métrica PF mede o tamanho funcional de um projeto de software, observando as funcionalidades implementadas, considerando a visão do usuário. O tamanho funcional é definido como tamanho do software derivado pela quantificação dos requisitos funcionais do usuário [Dekkers, 2003]. A métrica PF é independente da metodologia e Roteiro de Métricas de Software do SISP 2.1 3

12 tecnologia utilizadas. A Análise de Pontos de Função (APF) é um método padrão para a medição de projetos de desenvolvimento e de manutenção de sistemas, visando estabelecer uma medida de tamanho do software em pontos de função, com base na quantificação das funcionalidades solicitadas e entregues, sob o ponto de vista do usuário. Assim, a APF tem como objetivo medir o que o software faz, por meio de uma avaliação padronizada dos requisitos de negócio do sistema. O Manual de Práticas de Contagem (CPM) [IFPUG, 2010b] apresenta as regras de contagem de pontos de função de projetos de desenvolvimento, projetos de melhoria e aplicações implantadas. A Figura 1 ilustra o procedimento de contagem de pontos de função, descrito nas seções seguintes. Obter a documentação disponível do projeto Identifique os requisitos funcionais Identificar o Propósito da Contagem Identificar o Tipo de Contagem Determinar o Escopo da Contagem Determinar a Fronteira da Aplicação Contar Funções de Dados Contar Funções Transacionais Calcular Tamanho Funcional Documentar e Reportar a Contagem Figura 1: Procedimento de Contagem de Pontos de Função 3.1 Determinar Propósito, Tipo e Escopo da Contagem e Fronteira da Aplicação A contagem de pontos de função se inicia com a análise da documentação disponível do projeto em questão, visando a identificação dos requisitos funcionais. O próximo passo é o estabelecimento do propósito da contagem, o qual fornece uma resposta para uma questão de negócio a ser resolvida, por exemplo: necessidade de dimensionar um projeto de um novo sistema para auxiliar o processo de contratação do mesmo. Com base no propósito da contagem são definidos o escopo da contagem e o tipo de contagem. O escopo da contagem identifica quais funcionalidades serão incluídas na contagem de pontos de função, e o tipo de contagem identifica se o projeto é de desenvolvimento, de melhoria ou aplicação instalada. A fronteira da aplicação, que é a interface conceitual que indica o limite lógico entre o sistema sendo medido e os usuários (também entre outras aplicações), deve ser definida com base na visão do usuário, desconsiderando questões de implementação. Deve-se ressaltar que toda contagem de pontos de função é realizada dentro de uma fronteira estabelecida. O estabelecimento da fronteira da aplicação pode ser subjetivo, por exemplo, em uma aplicação com vários módulos, a fronteira pode ser estabelecida para cada módulo Roteiro de Métricas de Software do SISP 2.1 4

13 ou subsistema ou, ainda, pode-se considerar toda a aplicação, dependendo da visão do usuário. De fato, a definição da fronteira depende de processos de negócios, além disso, o posicionamento da fronteira influencia fortemente a contagem de pontos de função. Desta forma, devido a essa subjetividade, em editais para contratação de projetos de manutenção é fortemente recomendado a definição das fronteiras de todas as aplicações a serem contratadas. Os roteiros de contagem dos órgãos e entidades também devem definir as fronteiras das aplicações implantadas em um anexo, e este deve ser atualizado sempre que for implantada uma nova aplicação. Mais informações sobre esse assunto podem ser encontradas no Anexo IV. 3.2 Identificar Funções de Dados e Funções Transacionais Uma vez estabelecida a fronteira da contagem, o próximo passo é o mapeamento dos requisitos de dados e de funções transacionais para os tipos funcionais da APF, a saber: Arquivo Lógico Interno (ALI): é um grupo de dados, logicamente relacionados, reconhecido pelo usuário, mantido por meio de um processo elementar da aplicação que está sendo contada. Arquivo de Interface Externa (AIE): é um grupo de dados, logicamente relacionados, reconhecido pelo usuário, mantido por meio de um processo elementar de uma outra aplicação e referenciado pela aplicação que está sendo contada. O AIE é obrigatoriamente um ALI de outra aplicação. Entrada Externa (EE): é um processo elementar que processa dados ou informação de controle que entram pela fronteira da aplicação. Seu objetivo principal é manter um ou mais ALI ou alterar o comportamento do sistema. Consulta Externa (CE): é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação. Seu objetivo principal é apresentar informação para o usuário através da recuperação de dados ou informação de controle de ALI ou AIE. Saída Externa (SE): é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação. Seu objetivo principal é apresentar informação para um usuário ou outra aplicação através de um processamento lógico adicional à recuperação de dados ou informação de controle. O processamento lógico deve conter cálculo, ou criar dados derivados, ou manter ALI ou alterar o comportamento do sistema. Após a identificação dos tipos funcionais para cada requisito funcional definido no documento de requisitos do sistema, deve-se avaliar a complexidade (Baixa, Média, Alta) e a contribuição funcional do mesmo para a contagem de pontos de função, observando as regras de contagem de pontos de função descritas no CPM. A identificação e a avaliação das complexidades dos tipos funcionais não podem ser realizadas de maneira subjetiva. A contagem de pontos de função deve seguir rigorosamente as regras de contagem do CPM e as definições complementares do roteiro de métricas do órgão, e deve ser realizada por profissionais capacitados do órgão. A Tabela 1 apresenta a contribuição dos tipos funcionais na contagem de pontos de função. Complexidade Tipo Funcional Baixa Média Alta Roteiro de Métricas de Software do SISP 2.1 5

14 Arquivo Lógico Interno (ALI) 7 PF 10 PF 15 PF Arquivo de Interface Externa (AIE) 5 PF 7 PF 10 PF Entrada Externa (EE) 3 PF 4 PF 6 PF Saída Externa (SE) 4 PF 5 PF 7 PF Consulta Externa (CE) 3 PF 4 PF 6 PF Tabela 1: Contribuição Funcional dos Tipos Funcionais (Fonte: CPM 4.3) 3.3 Calcular Tamanho Funcional O Manual de Práticas de Contagem do IFPUG define dois tipos de projetos de software, a saber: Projeto de Desenvolvimento: projeto para desenvolver e entregar a primeira versão de uma aplicação de software. Seu tamanho funcional é a medida das funcionalidades entregues ao usuário no final do projeto. Também considera-se as funcionalidades de conversão de dados, caso seja requisitado no projeto a migração ou carga inicial de dados para a nova aplicação. Projeto de Melhoria: projeto de manutenção evolutiva ou melhoria funcional. Seu tamanho funcional é a medida das funcionalidades incluídas, alteradas e excluídas ao final do projeto. Também considera-se as funcionalidades de conversão de dados, caso seja requisitado a migração ou carga inicial de dados no projeto de melhoria. Seguem abaixo as definições dos termos técnicos da Análise de Pontos de Função utilizados nas fórmulas de dimensionamento de projetos de software propostas neste roteiro: PF_INCLUÍDO: pontos de função associados às novas funcionalidades que farão parte da aplicação após um projeto de desenvolvimento ou de manutençã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. PF_CONVERSÃO: pontos de função associados às funcionalidades de conversão de dados dos projetos de desenvolvimento ou de manutenção. Exemplos de funções de conversão incluem: migração ou carga inicial de dados para popular as novas tabelas criadas (Entradas Externas) e relatórios associados à migração de dados, caso requisitado pelo usuário (Saídas Externas ou Consultas Externas). Observe que os dados carregados em um processo de migração não devem ser contados como Arquivos de Interface Externa. Este roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de pontos de função de projetos de desenvolvimento e de melhoria nos casos específicos onde for caracterizado um esforço relativamente maior dessa atividade. Por exemplo, os projetos que envolvem a migração de dados de banco de dados hierárquico para banco de dados relacional e o tratamento de funções complexas de migração de dados. Nesses casos, recomenda-se tratá-los como projetos separados de migração de dados, descritos na seção 4.3. Roteiro de Métricas de Software do SISP 2.1 6

15 3.4 Requisitos Não Funcionais A métrica Ponto de Função é uma métrica de tamanho funcional, ou seja, dimensiona projetos de software com base nos requisitos funcionais da aplicação, não contemplando diretamente os requisitos não funcionais do projeto. Nesse sentido, em contratos de software baseados na métrica Ponto de Função é fundamental definir claramente no edital os requisitos não funcionais do projeto a serem atendidos pela empresa contratada. Os requisitos não funcionais impactam no esforço e, consequentemente, no custo do projeto. Os requisitos não funcionais estão associados aos aspectos qualitativos de um software, considerando aspectos relacionados ao uso do software. Seguem abaixo alguns tipos de requisitos não funcionais, com exemplos, que podem ser mencionados nos editais: - Usabilidade: a solução deve atender aos requisitos dos Padrões Web em Governo Eletrônico (e-pwg) Cartilha de Usabilidade; a aplicação deve ter help on-line de sistema, tela e campo (sensível a contexto); a aplicação deve ser disponibilizada nos idiomas Português, Espanhol e Inglês. - Técnicos: a aplicação deve funcionar adequadamente nos navegadores: Internet Explorer 7.0 ou superior e Mozilla Firefox 3.0 ou superior; a solução deve ser desenvolvida em linguagem Java com banco de dados PostgreSQL; para o desenvolvimento da solução, deve ser utilizado preferencialmente um dos seguintes frameworks Java: Demoiselle, Jaguar e MDArt; a solução deve atender aos requisitos do e-pwg; deve utilizar as ferramentas AWSTATS e Google Analytics para gerar estatísticas de acesso. - Segurança: a aplicação deve realizar controle de segurança dos dados de acordo com politica de backup definida em conformidade com a norma ISO/IEC Acessibilidade: a solução deve ser aderente ao Modelo de Acessibilidade de Governo Eletrônico (e-mag). - Performance: o tempo de resposta da aplicação não deve exceder 10 segundos; a solução deve suportar até acessos simultâneos. - Interoperabilidade: a solução deve ser aderente aos Padrões de Interoperabilidade de Governo Eletrônico (e-ping). 4. Cálculo de Pontos de Função para o SISP Este capítulo tem como propósito descrever os diversos tipos de projetos de software e definir métricas para seu dimensionamento baseadas nas regras de contagem de pontos de função do CPM. Quanto à documentação de pequenos projetos de manutenção (menores que 100 PF), deve-se registrar a solicitação e documentar os requisitos do projeto de manutenção e 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. O Anexo II e Anexo III apresentam, respectivamente, um modelo de documento de requisitos e um modelo de documento de contagem de pontos de função para projetos de manutenção de pequeno porte (menores que 100 PF). Cabe ressaltar que, em alguns casos, o órgão contratante pode não ter necessidade de contratar todas as fases do ciclo de vida do software. Dessa forma, a contratada será remunerada pela contagem de pontos de função considerando apenas Roteiro de Métricas de Software do SISP 2.1 7

16 os percentuais das fases contratadas, conforme os níveis percentuais sugeridos na Tabela 7 ou na metodologia do órgão (ver subseção ). Exemplo: para um novo projeto de desenvolvimento de um sistema de treinamentos, que não exista a intenção de contratar as fases de requisitos e de testes, a contratada será remunerada pela contagem de pontos de função desconsiderando os percentuais dessas fases. Além disso, recomenda-se que as contagens de manutenção a partir do Roteiro de Métricas de Software do SISP sejam reportadas conforme determinado pelo CPM, ou seja, S FP (IFPUG IS c), indicando que o resultado da contagem de pontos de função não mantém conformidade plena com o CPM e o padrão internacional de contagem de PF (ISO/IEC 20926:200x) e sim mantém conformidade com uma customização, neste caso, o Roteiro de Métricas de Software do SISP. Assim: S FP (IFPUG IS c) Onde: S é o resultado da contagem de pontos de função; FP (Function Point) é a unidade de tamanho do método FSM (Functional Size Measurement) do IFPUG; IS (International Standard) é o padrão internacional (ISO/IEC 20926:200x); c representa um ou mais caracteres indicando que o resultado não mantém conformidade plena com o padrão internacional. Exemplo: 250 PF* (IFPUG ISO/IEC 20926:200x sisp) * FP na versão em português 4.1 Projeto de Desenvolvimento É o projeto para desenvolver e entregar a primeira versão de uma aplicação de software. Seu tamanho funcional é a medida das funcionalidades entregues ao usuário no final do projeto. Também considera-se as funcionalidades de conversão de dados. Segue a fórmula de cálculo utilizada no dimensionamento de projetos de desenvolvimento de software: PF_DESENVOLVIMENTO = PF_INCLUIDO + PF_CONVERSÃO Este roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de pontos de função de projetos de desenvolvimento quando for caracterizado um esforço relativamente maior dessa atividade, conforme descrito na seção Projeto de Melhoria 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. Segundo o padrão IEEE Std 1219 [IEEE, 1998], esta manutenção seria um tipo de manutenção adaptativa, definida como: modificação de um produto de software existente para mantê-lo funcionando adequadamente em um ambiente que sofre mudanças. O projeto de melhoria é considerado um tipo de projeto de manutenção adaptativa com Roteiro de Métricas de Software do SISP 2.1 8

17 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 roteiro separa o projeto de melhoria (quando as mudanças são associadas aos requisitos funcionais) do projeto de 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. Segue a fórmula de cálculo utilizada no dimensionamento de projetos de melhoria de software: PF_MELHORIA = PF_INCLUIDO + (FI x PF_ALTERADO) + (0,30 x PF_EXCLUIDO) + PF_CONVERSÃO FI (Fator de Impacto) pode variar de 50% a 90% conforme condições abaixo: FI = 50% para funcionalidade de sistema desenvolvida ou mantida por meio de um projeto de melhoria pela empresa contratada. FI = 75% para funcionalidade de sistema não desenvolvida ou mantida por meio de um projeto de melhoria pela empresa contratada e sem necessidade de redocumentação da funcionalidade. FI = 90% para funcionalidade de sistema não desenvolvida ou mantida por meio de um projeto de melhoria pela empresa contratada e com necessidade de redocumentação da funcionalidade. FI = 90% representa a adição de 15% como fator de redocumentação ao Fator de Impacto anterior (75%). Nesse caso, a contratada deve redocumentar a funcionalidade mantida, gerando a documentação completa da mesma, aderente ao processo de software da contratante. Se houver uma nova demanda de projeto de melhoria na funcionalidade em questão, será considerado que a contratada desenvolveu a funcionalidade. Observe que o percentual de 90% apenas será considerado na primeira demanda de projeto de melhoria em cada funcionalidade. Este roteiro propõe um fator de redocumentação menor para projetos de manutenção (melhoria, corretiva e adaptativa) do que o fator proposto em projetos específicos de redocumentação (seção 4.12 deste roteiro). Isso porque, em projetos de manutenção de uma funcionalidade sem documentação, é necessário realizar o entendimento da funcionalidade para poder modificá-la e testá-la, ou seja, é necessário realizar a engenharia reversa da funcionalidade para executar os testes corretamente. Assim sendo, a redocumentação requisitada em projetos de melhoria requer um esforço menor do que em projetos de redocumentação, descritos na seção 4.12, onde é necessário remunerar todo o esforço de engenharia reversa e a atividade de documentação. Em projetos de manutenção, o fator de 15% está remunerando apenas a atividade de documentação. Os percentuais de FI acima correspondem à contratação de todas as fases do processo de desenvolvimento de software. Caso alguma fase não seja contratada, devese aplicar ao FI um redutor que corresponde ao percentual da fase não contratada, conforme percentuais sugeridos na Tabela 7 ou na metodologia do órgão. Os percentuais de multiplicação propostos são estimados, podendo ser reajustados Roteiro de Métricas de Software do SISP 2.1 9

18 conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. Este roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de pontos de função de projetos de melhoria quando for caracterizado um esforço relativamente maior dessa atividade, conforme descrito na seção 3.3. Uma outra forma de dimensionar projetos de melhoria é usando a técnica EFP (Enhancement Function Points) publicada pela NESMA (Netherlands Software Metrics Users Association) no documento "Function Point Analysis for Software Enhancement Guidelines" [NESMA, 2009]. Essa técnica pode ser aplicada quando a contratante já possui uma base histórica de projetos concluídos com Contagem Detalhada de Pontos de Função e um processo de desenvolvimento implantado com documentação das aplicações a serem mantidas. O Anexo V apresenta um resumo da técnica EFP e a sua descrição completa pode ser obtida em [NESMA, 2009]. Seguem algumas considerações importantes para serem analisadas em projetos de melhoria. Observação 1: Função Alterada Uma função de dados (Arquivo Lógico Interno ou Arquivo de Interface Externa) é considerada alterada quando houver inclusão ou exclusão de Tipos de Dados (TD). De acordo com o glossário do CPM 4.3, um Tipo de Dados (DET Data Element Type) é um atributo único, reconhecido pelo usuário e não repetido. Também é considerada alterada se algum tipo de dado sofrer mudança de tamanho (número de posições) ou tipo de campo (por exemplo: mudança de numérico ou alfanumérico), caso a mudança decorra de alteração de regra de negócio. Uma função transacional (Entrada Externa, Consulta Externa e Saída Externa) é considerada alterada, quando a alteração contemplar: Mudança de tipos de dados; Mudança de arquivos referenciados; Mudança de lógica de processamento. O CPM 4.3 define lógica de processamento como requisitos especificamente solicitados pelo usuário para completar um processo elementar. Esses requisitos devem incluir uma ou mais das 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 ou 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 Roteiro de Métricas de Software do SISP

19 aplicação; Dados são reordenados. Roteiro de Métricas de Software do SISP

20 Observação 2: Outros Tipos de Funções Alteradas Este roteiro considera como função alterada qualquer mudança em funcionalidades da aplicação devido às mudanças de regras de negócio. Por exemplo, uma funcionalidade de cadastro envolvia a inclusão de um telefone do gerente. Devido a mudanças no processo de negócio, a funcionalidade deve sofrer uma manutenção para cadastrar dois telefones do gerente. Desta forma, o roteiro considera esta função como uma Entrada Externa alterada, PF_ALTERADO em um projeto de melhoria, mesmo que não existam mudanças de lógica de processamento, de tipos de dados ou de arquivos referenciados. Serão tratadas como manutenções adaptativas apenas as manutenções que implicarem exclusivamente em mudanças em requisitos não funcionais. Se uma mesma funcionalidade tiver mudanças em requisitos funcionais e não funcionais, esta deve ser contada apenas uma vez, como função alterada em um projeto de melhoria. 4.3 Projetos de Migração de Dados Conforme mencionado na seção 3.3, este roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de pontos de função de projetos de desenvolvimento e de melhoria nos casos específicos onde for caracterizado um esforço relativamente maior dessa atividade, tais como, nos casos de migração de dados de banco de dados hierárquico para relacional, e no tratamento de funções complexas de migração de dados. Nesses casos, recomenda-se tratar esse serviço como projeto separado de migração de dados. Os projetos de migração de dados devem ser contados como um novo projeto de desenvolvimento de um sistema, seguindo a fórmula abaixo: PF_CONVERSÃO = PF_INCLUIDO Um projeto de migração deve contemplar minimamente: os ALI mantidos pela migração, as Entradas Externas considerando as cargas de dados nos ALI e, caso seja solicitado pelo usuário, os relatórios gerenciais das cargas, que serão contados como Saídas Externas. Todas as contagens de PF devem ser realizadas com base nas funcionalidades requisitadas e recebidas pelo usuário. 4.4 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 de 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 frequentemente 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 Std 1219 [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. Roteiro de Métricas de Software do SISP

21 Quando o sistema em produção tiver sido desenvolvido pela contratada, a manutenção corretiva será do tipo Garantia se estiver no período de cobertura e em conformidade com as demais condições de garantia previstas em contrato. Caso não exista cláusula contratual de garantia, deve ser considerada a garantia preconizada por lei (Código do Consumidor). Quando o sistema estiver fora da garantia ou não tenha sido desenvolvido pela empresa contratada, deverá ser estimado e calculado o tamanho do projeto de manutenção corretiva. Nestes casos, a aferição do tamanho em pontos de função da funcionalidade ou das funcionalidades corrigidas deve considerar um fator de impacto (FI) sobre o PF_ALTERADO. PF_CORRETIVA = FI x PF_ALTERADO Fator de Impacto (FI): 50% quando estiver fora da garantia e a correção for feita pela mesma empresa que desenvolveu a funcionalidade. 75% quando estiver fora da garantia e a correção for feita por empresa diferente daquela que desenvolveu a funcionalidade. As demandas de manutenção corretiva não contemplam atualização de documentação da funcionalidade corrigida, pois este roteiro considera que, normalmente, manutenção corretiva não se refere a erros de requisitos. Caso seja erro em requisitos, essa demanda deve ser tratada como projeto de melhoria (alteração de funcionalidade), descrito na seção 4.2. Porém, quando o erro for causado por documentação dúbia ou imprecisa (elaborada pela contratada) da funcionalidade corrigida, a manutenção corretiva poderá contemplar os ajustes na documentação, mesmo fora da garantia, mediante negociação entre as partes. Caso seja demandada a redocumentação da funcionalidade corrigida, porque a documentação não existe ou está desatualizada, deve-se adicionar ao FI um fator de redocumentação de 15%, conforme descrito na seção 4.2. 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 ou entidade. 4.5 Mudança de Plataforma São considerados nesta categoria, projetos que precisam ser migrados para outra plataforma. Por exemplo, um sistema legado em COBOL que necessita ser redesenvolvido em JAVA; o banco de dados de um sistema legado que precisa ser migrado para o DB2. Recomenda-se enfaticamente a realização da análise de impacto das mudanças propostas, para efeito de determinação do percentual adequado para aplicação sobre o total de pontos de função das funcionalidades impactadas. Por exemplo, em uma análise de impacto pode ser identificado que não haverá mudanças no código-fonte ou em função transacional, sendo necessário apenas testar o sistema, então deve-se utilizar um percentual contemplando apenas a fase de testes. No caso do teste apontar a necessidade de atualizar alguma função transacional, não deve ser contado o esforço do teste, mas sim o esforço abordado nesta seção, conforme as fórmulas apresentadas nos tópicos seguintes. Roteiro de Métricas de Software do SISP

22 As próximas subseções apresentam os tipos de projetos de mudança de plataforma. Os projetos de mudança de plataforma que se enquadram em mais de uma subseção, devem ser contados apenas uma vez, considerando o tipo de projeto com maior contagem de pontos de função. Os percentuais de multiplicação apresentados são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão ou entidade Mudança de Plataforma - Linguagem de Programação Nesta categoria encontram-se as demandas de redesenvolvimento de sistemas em outra linguagem de programação. Como os projetos legados, frequentemente, não possuem documentação, devem ser considerados como novos projetos de desenvolvimento. Assim, será utilizada a fórmula de projetos de desenvolvimento do CPM 4.3. Observe que caso não exista mudança nas funções de dados, ou seja, o banco de dados da aplicação seja mantido, as funções de dados não devem ser contadas. No entanto, nesse caso, deve ser realizada a contagem das funções de dados a fim de compor a documentação da contagem final do projeto. Outro ponto a ser observado são as fases contratadas. Caso o projeto já possua documentação de requisitos, a fase de requisitos não será contratada. Deve-se considerar apenas os percentuais das fases contratadas. PF_REDESENVOLVIMENTO_LINGUAGEM = PF_INCLUÍDO + PF_CONVERSÃO Este roteiro recomenda a supressão do PF_CONVERSÃO da fórmula de contagem de pontos de função de projetos de redesenvolvimento quando for caracterizado um esforço relativamente maior dessa atividade, conforme descrito na seção Mudança de Plataforma - Banco de Dados Nesta categoria encontram-se as demandas de redesenvolvimento de sistemas para utilizar um outro sistema gerenciador de banco de dados. Observe que caso não exista mudança nas funções de dados, ou seja, o banco de dados da aplicação seja mantido, então as funções de dados não devem ser contadas. No entanto, nesse caso, deve ser realizada a contagem das funções de dados a fim de compor a documentação da contagem final do projeto. Em casos de mudança de banco hierárquico para relacional, em sistemas sem documentação, devido às mudanças envolvidas, deve-se considerar como um novo projeto de desenvolvimento, ou seja, as funções de dados e funções transacionais devem ser contadas. Assim, será utilizada a fórmula de projeto de desenvolvimento do CPM 4.3, conforme fórmula abaixo: PF_REDESENVOLVIMENTO_BD_HIERÁRQUICO = PF_INCLUÍDO + PF_CONVERSÃO Nos projetos de redesenvolvimento de banco de dados hierárquico para relacional, recomenda-se a supressão do PF_CONVERSÃO da fórmula acima, conforme descrito na seção 3.3. Roteiro de Métricas de Software do SISP

23 Caso o projeto já possua documentação de requisitos, então a fase de requisitos não deve ser contratada. É importante destacar que isso se aplica a qualquer fase que não se deseja contratar. Deve-se considerar apenas os percentuais das fases contratadas. Caso a demanda de redesenvolvimento seja de um sistema gerenciador de banco de dados relacional para outro relacional, deve ser utilizada a seguinte fórmula: PF_REDESENVOLVIMENTO_BD_RELACIONAL = (PF_ALTERADO X 0,30) + PF_CONVERSÃO O PF_ALTERADO deve considerar apenas as funcionalidades impactadas. As funcionalidades que possuem apenas demandas de testes, devem ser contadas usando o percentual da fase de testes (ver Tabela 7). Nos projetos de redesenvolvimento de banco de dados relacional para outro relacional, recomenda-se tratar o PF_CONVERSÃO dentro do mesmo projeto. Na mudança de banco relacional para relacional, geralmente a estrutura de dados não é alterada, desta forma não contamos as funções de dados. 4.6 Atualização de Versão São consideradas nesta categoria, demandas para uma aplicação existente - ou parte de uma aplicação existente - executar em versões diferentes de browsers (ex: Internet Explorer, Firefox, Chrome, etc) ou de linguagens de programação (ex: versão mais atual do JAVA). Também são consideradas nesta categoria atualização de versão de banco de dados. Nesta categoria foram observadas demandas de diferentes tipos de projetos, descritos nas próximas subseções. Os percentuais de multiplicação apresentados nessas subseções são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. Outro ponto a ser observado é a classificação, em alguns casos, dessas demandas como componente interno reusável (seção 4.15). Recomenda-se enfaticamente a realização da análise de impacto das mudanças propostas para efeito de determinação do percentual adequado para aplicação sobre o total de pontos de função das funcionalidades impactadas. Por exemplo, em uma análise de impacto, pode ser identificado que não haverá mudanças no código-fonte ou em função transacional, sendo necessário somente testar o sistema, então deve-se utilizar um percentual contemplando apenas a fase de testes. No caso do teste apontar a necessidade de atualizar alguma função transacional, não deve ser contado o esforço do teste, mas sim o esforço abordado nesta seção, conforme as fórmulas apresentadas nas subseções seguintes Atualização de Versão Linguagem de Programação Nesta categoria encontram-se as demandas de atualização de versão de linguagem de programação de sistemas. As funções de dados não devem ser contadas. Estas demandas devem ser dimensionadas de acordo com a fórmula abaixo. PF_ATUALIZAÇÃO_VERSÃO_LINGUAGEM = PF_ALTERADO x 0,30 Roteiro de Métricas de Software do SISP

24 O PF_ALTERADO deve considerar apenas as funcionalidades impactadas. As funcionalidades que possuem apenas demandas de testes, devem ser contadas usando o percentual da fase de testes (ver Tabela 7). Cabe ressaltar que o redutor depende da linguagem da programação utilizada, considerando o grau de complexidade de implementação da mudança de versão no sistema em questão. Desta forma, recomenda-se fortemente a análise do percentual redutor da fórmula de contagem pelo órgão Atualização de Versão Browser Nesta categoria encontram-se as demandas de atualização de aplicações Web para executar em novas versões de um mesmo browser e para suportar a execução em mais de um browser. É importante destacar que este tipo de procedimento usualmente é realizado quando é necessário resolver algum problema de incompatibilidade. As funções de dados não devem ser contadas. Estas demandas devem ser dimensionadas de acordo com a fórmula abaixo. PF_ATUALIZAÇÃO_VERSÃO_BROWSER = PF_ALTERADO x 0,30 O PF_ALTERADO deve considerar apenas as funcionalidades impactadas. As funcionalidades que possuem apenas demandas de testes, devem ser contadas usando o percentual da fase de testes (ver Tabela 7). Essas atualizações podem implicar em manutenções em componentes específicos da plataforma utilizada. Nesse caso, a demanda deve ser contada como componente interno reusável, descrita na seção 4.15 deste roteiro. Recomenda-se enfaticamente a realização da análise de impacto das mudanças propostas para efeito de determinação do percentual adequado. Por exemplo, para sistemas que já atendem ao padrão W3C (World Wide Web Consortium) o esforço é menor, podendo usar, neste caso, um percentual diferente do citado acima. É importante ressaltar que os sistemas Web devem seguir o padrão W3C, como recomendado na e- Ping. Caso seja necessário fazer a adequação do sistema para atendimento ao padrão W3C, pode-se usar a fórmula acima Atualização de Versão Banco de Dados Nesta categoria encontram-se as demandas de atualização de versão do sistema gerenciador de banco de dados. As funções de dados não devem ser contadas. Estas demandas devem ser dimensionadas de acordo com a fórmula abaixo. PF_ ATUALIZAÇÃO_VERSÃO_BD = PF_ALTERADO x 0,30 O PF_ALTERADO deve considerar apenas as funcionalidades impactadas. As funcionalidades que possuem apenas demandas de testes, devem ser contadas usando o percentual da fase de testes (ver Tabela 7). Roteiro de Métricas de Software do SISP

25 4.7 Manutenção em Interface A manutenção em interface, denominada na literatura de manutenção cosmética, é associada às demandas de 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. Também se enquadram nessa categoria as seguintes manutenções: Mudanças de texto em mensagens de erro, validação, aviso, alerta, confirmação de cadastro ou conclusão de processamento; Mudança em texto estático de enviado para o usuário em uma funcionalidade de cadastro. A demanda deve ser contada como manutenção em interface na funcionalidade de cadastro; Alteração de título de um relatório; Alteração de labels de uma tela de consulta. Nestes casos, a aferição do tamanho em pontos de função das funções transacionais impactadas será realizada com a aplicação de um fator de redução de modo a considerar 20% da contagem de uma função transacional de mais baixa complexidade (3 PF), ou seja 0,6 PF, independentemente da complexidade da funcionalidade alterada. Neste tipo de manutenção não são contadas funções de dados. PF_INTERFACE = 0,6 PF x QUANTIDADE DE FUNÇÕES TRANSACIONAIS IMPACTADAS Está contemplada a atualização da documentação das funcionalidades da aplicação impactadas pela manutenção nas demandas desta categoria. Assim, a documentação (documento de requisitos, documento de interface, protótipo, entre outros) das funcionalidades alteradas deve ser atualizada. Caso não exista documentação para as funcionalidades alteradas, não será contemplada a redocumentação das funcionalidades da aplicação impactadas pela manutenção nas demandas desta categoria. Observação 1 Help: As demandas de projetos de desenvolvimento de sistemas ou de manutenção de funcionalidades contemplam o desenvolvimento ou atualização do help da funcionalidade em questão, sendo tratada como uma atividade de documentação no processo de software. No caso de demandas específicas de desenvolvimento ou atualização de help estático de funcionalidades, estas podem ser enquadradas nesta seção e poderá ser usado um valor de multiplicação inferior a 0,6 PF conforme análise de impacto das mudanças propostas. Em caso de requisitos de usuário para o desenvolvimento de funcionalidades de manutenção de help, deve-se contar a função de dados de help e as funcionalidades de manutenção de help (por exemplo: incluir help de tela, consultar help de campo) de acordo com o CPM 4.3. O percentual de multiplicação é estimado, podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. 4.8 Adaptação em Funcionalidades sem Alteração de Requisitos Funcionais São consideradas nesta categoria as demandas de manutenção adaptativa associadas a solicitações que envolvem aspectos não funcionais, sem alteração em requisitos funcionais. Seguem alguns exemplos: Roteiro de Métricas de Software do SISP

26 Aumentar a quantidade de linhas por página em um relatório; Colocar paginação em um relatório; Limitar a quantidade de linhas por página em uma consulta existente; Permitir exclusões múltiplas em uma funcionalidade que antes só possibilitava a exclusão de um item; Adaptação de uma funcionalidade para possibilitar a chamada por um webservice ou para outro tipo de integração com outros sistemas; Replicação de funcionalidade: chamar uma consulta existente em outra tela da aplicação; Alteração na aplicação para adaptação às alterações realizadas na interface com rotinas de integração com outros softwares, por exemplo, alteração em sub-rotinas chamadas por este software; Modificar o servidor a ser acessado em uma funcionalidade de download de arquivo; Adequar mensagem do sistema que em algumas telas apresenta Usuário Não está Habilitado a ver esta Página, para que passe a enviar uma mensagem mais adequada ao fato do usuário não possuir mais uma sessão ativa e ainda estar navegando no sistema. A demanda deve ser contada como manutenção adaptativa considerando as funcionalidades impactadas. Observe que trata-se de mudança em validação com regra de negócio não funcional. Nestes casos, a aferição do tamanho em pontos de função da funcionalidade ou das funcionalidades que sofreram impacto deve considerar um fator de impacto (FI) sobre o PF_ALTERADO, seguindo os conceitos do CPM 4.3, apresentados na seção 4.2. PF_ADAPTATIVA = FI x PF_ALTERADO FI (Fator de Impacto) pode variar conforme condições abaixo: FI = 50% para funcionalidade de sistema desenvolvida ou mantida por meio de um projeto de melhoria pela empresa contratada. FI = 75% para funcionalidade de sistema não desenvolvida ou mantida por meio de um projeto de melhoria pela empresa contratada. Deve-se destacar que além da adequação das funcionalidades em questão, a documentação do projeto de manutenção adaptativa deve ser realizada. Além disso, caso exista a documentação das funcionalidades impactadas, estas deverão ser atualizadas, caso contrário, se for demandada a redocumentação dessas funcionalidades, deve-se adicionar ao FI um fator de redocumentação de 15%, conforme descrito na seção 4.2. 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 ou entidade. Roteiro de Métricas de Software do SISP

27 4.9 Apuração Especial São funcionalidades executadas apenas uma vez para: corrigir problemas de dados incorretos na base de dados das aplicações ou atualizar dados em bases de dados de aplicações, detalhados na subseção 4.9.1; 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, detalhados na subseção A subseção considera os casos de reexecução de uma apuração especial. 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. Recomenda-se fortemente ao órgão contratante sempre solicitar formalmente para a empresa contratada o armazenamento do script para permitir posterior reexecução. Cabe ressaltar que o órgão deve avaliar a complexidade das demandas típicas de apuração especial, podendo utilizar um percentual redutor nas fórmulas descritas nas subseções seguintes. Por exemplo, o redutor percentual pode ser aplicado em função da complexidade das demandas, documentação demandada e/ou do processo de desenvolvimento utilizado Apuração Especial Base de Dados Este tipo de 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 função de modificação da estrutura de dados, por exemplo inclusão de valor sim ou não no campo indicador de matriz referente ao CNPJ. Normalmente, nesse tipo de atualização são afetados múltiplos registros. Nestes casos, considera-se a contagem de pontos de função das funcionalidades desenvolvidas. Geralmente, estas funcionalidades são classificadas como Entradas Externas. Nesse caso, como artefato de homologação da demanda, deve ser gerado um relatório para validação do usuário. É importante ressaltar que as funções de dados associadas aos dados atualizados não devem ser contadas, considerando que não há mudanças nas estruturas dos Arquivos Lógicos Internos. Foram identificados três tipos de Apuração Especial - Base de Dados, cujas fórmulas de cálculo são apresentadas a seguir: a) Atualização de Dados sem Consulta Prévia PF_APURAÇÃO_BD = PF_INCLUÍDO Roteiro de Métricas de Software do SISP

28 b) Consulta Prévia sem Atualização Em alguns casos de Apuração Especial Base de Dados, o usuário solicita uma consulta prévia das informações. Deve-se ressaltar que essa consulta deve ser realizada antes da construção da funcionalidade, não se trata de homologação. A consulta prévia não é definida pela empresa contratada, obrigatoriamente essa deve ser solicitada pelo órgão contratante para a avaliação da viabilidade de implementar a Apuração Especial - Base de Dados. 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 o tamanho da funcionalidade em questão, conforme a fórmula abaixo: PF _CONSULTA_PRÉVIA = PF_INCLUÍDO c) Atualização de Dados com Consulta Prévia Caso a Apuração Especial - Base de Dados seja solicitada após uma demanda de consulta prévia, deve-se aplicar um fator de 60% na fórmula de contagem da Apuração Especial - Base de Dados, seguindo a fórmula abaixo. PF_APURAÇÃO_BD_PÓS_CONSULTA_PRÉVIA = PF_INCLUÍDO x 0, Apuração Especial Geração de Relatórios Este tipo de 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 essas funções transacionais são Saídas Externas, devido à atualização do Arquivo Lógico Interno. Deve-se destacar que essas 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. Frequentemente, 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. É importante ressaltar que as funções de dados associadas aos dados atualizados não devem ser contadas, considerando que não há mudanças nas estruturas dos Arquivos Lógicos. PF_APURAÇÃO_RELATÓRIOS = PF_INCLUÍDO Roteiro de Métricas de Software do SISP

29 4.9.3 Apuração Especial Reexecução Em alguns casos, a empresa contratante pode ter interesse em executar uma apuração especial mais de uma vez. Nestes casos, ela deve solicitar formalmente à contratada o armazenamento do script executado. Desta forma, se for solicitada a reexecução de uma apuração especial, esta deve ser dimensionada com a aplicação de um fator redutor de 10% na contagem de pontos de função da apuração especial em questão, da seguinte maneira: PF_REEXECUÇÃO_APURAÇÃO = PF_NÃO_AJUSTADO x 0,10 O percentual de multiplicação proposto no item acima é estimado, podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade Atualização de Dados Em alguns casos, as demandas de correção de problemas em base de dados estão associadas a atualizações manuais (de forma interativa), diretamente no banco de dados em um único registro, e que não envolvem cálculos ou procedimentos complexos. São exemplos desse tipo de demanda, a atualização do valor de um campo de uma tabela cadastrado erroneamente ou a exclusão de um registro de uma tabela. Nestes casos, a aferição do tamanho em Pontos de Função deve considerar 10% do PF de uma Entrada Externa e os Tipos de Dados da Entrada Externa são todos os TD considerados na funcionalidade campos atualizados e campos utilizados para a seleção do registro. PF_ATUALIZAÇÃO_BD = PF_INCLUÍDO x 0,10 Deve-se ressaltar que neste tipo de demanda não há gestão de configuração (armazenamento de script, versionamento, etc) das atualizações. Caso a contratante identifique a necessidade de realização de gestão de configuração das atualizações no banco de dados, então a demanda será classificada como Apuração Especial - Base de Dados (subseção 4.9.1). O percentual de multiplicação proposto acima é estimado, podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade Desenvolvimento, Manutenção e Publicação de Páginas Estáticas de Intranet, Internet ou Portal Nesta seção são tratados desenvolvimentos e manutenções específicas em páginas estáticas de portais, intranets ou websites. As demandas desta seção abrangem a publicação de páginas Web com conteúdo estático. Por exemplo: criação de página HTML, atualização de menu estático, atualização de texto ou banner estáticos em páginas HTML existentes. Roteiro de Métricas de Software do SISP

30 Caso o desenvolvimento de páginas estáticas esteja contido em um projeto de desenvolvimento, então elas serão contabilizadas no projeto de desenvolvimento e não devem ser mensuradas em separado. Ou seja, esta seção 4.11 se aplica quando ocorrer a demanda exclusivamente para o desenvolvimento ou manutenção de páginas estáticas. Estas demandas são consideradas como desenvolvimento de consultas. Nestes casos, considera-se 20% 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). Ou seja, 0,6 PF por cada página desenvolvida ou mantida, de acordo com a fórmula abaixo: PF_PUBLICAÇÃO = 0,6 PF x Quantidade de Páginas Alteradas ou Incluídas As demandas de criação de logomarcas ou identidade visual, além de outras demandas de criação de arte, associadas à área de Comunicação Social, não são enquadradas nessa categoria. Tais demandas não se referem a contratos de prestação de serviços de desenvolvimento e manutenção de sistemas, portanto não são consideradas neste roteiro. É recomendada a construção de portais com ferramentas que apoiem a construção de conteúdo pelo usuário, os chamados Gerenciadores de Conteúdo, de modo a minimizar as demandas de criação de páginas estáticas. O percentual de multiplicação proposto acima é estimado, podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade 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 foi definido o fator de impacto de 25% dos pontos de função da aplicação em questão, considerando a fase de requisitos e a geração de artefatos associados a requisitos, conforme a fórmula abaixo. PF_DOCUMENTAÇÃO = PF_NÃO_AJUSTADO x 0,25 Caso a demanda seja a geração de artefatos de documentação de outras fases do processo de desenvolvimento, deve-se considerar um outro fator de impacto, considerando as fases do ciclo de vida e os demais artefatos a serem gerados. As premissas utilizadas devem ser definidas nas cláusulas contratuais e documentadas no documento de estimativas do projeto. O percentual de multiplicação proposto acima é estimado, podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade. Roteiro de Métricas de Software do SISP

31 4.13 Verificação de Erros As verificações de erro ou análise e solução de problemas são as demandas referentes a todo comportamento anormal ou indevido apontado pelo cliente nos sistemas aplicativos. Neste caso, a equipe de desenvolvimento da contratada se mobilizará para encontrar as causas do problema ocorrido. Se for constatado algum erro de sistema, a demanda será atendida como manutenção corretiva (seção 4.4). 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 que o cliente reportou erro. Caso não exista documentação de testes disponível dessas funcionalidades verificadas, será considerado 20% do tamanho funcional dessas funcionalidades com solicitação de análise pelo órgão contratante, segundo a fórmula abaixo: PF_VERIFICAÇÃO = PF_Funcionalidade_Reportada_Com_Erro x 0,20 Caso exista documentação de testes das funcionalidades verificadas, então será considerado 15% (mesmo percentual da fase de Testes, conforme Tabela 7) do tamanho funcional das funcionalidades analisadas, segundo a fórmula abaixo: PF_VERIFICAÇÃO = PF_Funcionalidade_Reportada_Com_Erro x 0,15 É importante ressaltar que a demanda de verificação de erros deve ser associada a uma funcionalidade específica. Os casos de sistema fora do ar por conta de problemas de rede ou banco de dados devem ser tratados como serviços de suporte e não serviços de desenvolvimento e manutenção de sistemas. Esses serviços de suporte não fazem parte do escopo desse roteiro de métricas, não se aplicando verificação de erros nestes casos. O percentual de multiplicação proposto acima é estimado, podendo ser reajustado conforme avaliação da base histórica dos serviços realizados no órgão ou entidade Pontos de Função de Teste Muitas vezes, em projetos de manutenção, o conjunto de funções transacionais a serem testadas é maior do que a quantidade de funções a serem implementadas, isto é, 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 apenas 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 será o somatório dos tamanhos em pontos de função das funções transacionais envolvidas no teste: PFT = Somatório dos Tamanhos das Funções Transacionais Testadas Roteiro de Métricas de Software do SISP

32 A conversão do PFT em ponto de função deve ser feita de acordo com a fórmula abaixo: PF_TESTES = PFT x 0,15 É importante ressaltar que no caso de uma função ser testada várias vezes, com cenários diferentes, a função só pode ser contada uma vez. Outra observação é que as funções testadas, consideradas no PFT, devem ser documentadas pela contratada considerando-se a documentação de testes definida no processo de desenvolvimento da contratante. Observe que estas funções farão parte do escopo do projeto de manutenção Componente Interno Reusável Em alguns casos são demandadas manutenções em componentes, que implementam regras de negócio, específicos de uma aplicação e estes são reusados por várias funcionalidades da aplicação. Por exemplo, uma mudança em uma rotina de validação de um CPF usada em várias funcionalidades de cadastro. Se considerarmos o método de contagem de projetos de melhoria do CPM, seriam contadas todas as funcionalidades impactadas por essa mudança. No entanto, este roteiro propõe que o componente, o qual deverá ser testado, seja considerado como um processo elementar independente e sua alteração seja contada aplicando-se um fator de impacto (FI) sobre o PF_ALTERADO, seguindo os conceitos do CPM 4.3, apresentados na seção Projeto de Melhoria. Além disso, as funcionalidades da aplicação que necessitem de teste devem ser requisitadas pela contratante e dimensionadas por meio da métrica Pontos de Função de Teste proposta na seção PF_COMPONENTE = FI x PF_ALTERADO Exemplo de manutenção de componentes: Mudança em tópico de um menu de um sistema em PHP que aparece em todas as telas da aplicação. A contagem pode ser realizada considerando o componente Apresentar Menu. Além disso, existem casos onde são realizadas manutenções de valores de elementos internos de configuração que afetam o comportamento ou a apresentação do sistema de forma geral, tais como páginas de estilos (arquivos CSS de sistemas Web), arquivos com mensagens de erro, arquivos de configuração de sistema e arquivos de internacionalização. Nestes casos, a aferição do tamanho em pontos de função será realizada com a aplicação de um fator de redução de modo a considerar 20% da contagem de uma função transacional de mais baixa complexidade (3 PF), ou seja 0,6 PF. Assim sendo, deve ser utilizada a seguinte fórmula de cálculo: PF_COMPONENTE_ARQUIVO = 0,6 PF x QTD_ARQUIVOS_ALTERADOS Roteiro de Métricas de Software do SISP

33 5. Orientações Complementares para Contagem Este capítulo tem como propósito apresentar as diretrizes de contagem de pontos de função em relação ao tema Múltiplas Mídias, cuja abordagem é reconhecida pelo IFPUG. As definições apresentadas têm como base o artigo Considerations for Counting with Multiple Media Release 1.1 publicado pelo IFPUG [IFPUG, 2010a]. 5.1 Contagem de Pontos de Função com Múltiplas Mídias A contagem de PF de funcionalidades entregues em mais de uma mídia, na 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. É 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 da avaliação do Escritório de Métricas da instituição. As estimativas e contagens de PF abordadas neste documento são baseadas em 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, 2010a]: Canal: também refere-se a mídia. Múltiplos canais é sinônimo de múltiplas mídias. Mídia: descreve a maneira como 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. Frequentemente, apenas 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-Mídia: quando mais de uma mídia é necessária para entregar a funcionalidade, 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 do objetivo da contagem, permitindo uma função de negócio ser reconhecida no contexto das mídias que são requisitadas para que a funcionalidade seja 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. Roteiro de Métricas de Software do SISP

34 Os cenários descritos nas seções seguintes não representam uma lista completa de situações de múltiplas mídias. O entendimento dos exemplos a seguir 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 PF de projetos dos órgãos e entidades do SISP Cenário 1: Mesmos dados apresentados em tela e impressos 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, sugere-se a abordagem single instance, considerando que dados idênticos sendo apresentados em tela e em 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 (multiple instance). Neste caso, duas funções são contadas: apresentação de dados em tela e apresentação de dados impressos Cenário 2: Mesmos dados de saída como dados em arquivo e relatório impresso Uma aplicação grava dados em um arquivo de saída e imprime um relatório com informações idênticas às gravadas no arquivo. Nesses casos, sugere-se a utilização da abordagem single instance considerando que os dados impressos e os dados apresentados no arquivo de saída sejam idênticos e que a ferramenta de desenvolvimento apoie a geração dessas múltiplas saídas. 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. Além disso, se a geração das múltiplas saídas não seguirem o padrão da ferramenta de desenvolvimento e tiverem que ser customizadas para o cliente, então será utilizada a abordagem multiple instance Cenário 3: Mesmos dados de entrada batch e on-line Uma informação pode ser carregada na aplicação por meio de dois métodos: arquivo batch e entrada on-line. O processamento do arquivo batch executa validações durante o processamento, da mesma forma que o processamento da entrada on-line também executa validações das informações. Neste caso, sugere-se a utilização da abordagem multiple instance, que conta duas funcionalidades: a entrada de dados batch e a entrada de dados on-line. Geralmente, 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 Cenário 4: 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. Neste caso, sugere-se a abordagem multiple instance, que conta duas funcionalidades: consulta de dados na Web e consulta de dados via celular. Roteiro de Métricas de Software do SISP

35 Considera-se que a funcionalidade é desenvolvida duas vezes, uma para cada canal de saída. Algumas vezes, são até projetos de desenvolvimento distintos, um projeto relativo ao sistema Web e outro para o sistema via celular. Lembrando que caso o projeto seja claro o suficiente para dizer que o desenvolvimento é o mesmo, poderá ser utilizada a abordagem single instance Cenário 5: Relatório em múltiplos formatos Um relatório deve ser entregue em diferentes formatos, por exemplo: um arquivo html e um arquivo com valores separados por vírgula (.csv). Nestes casos, conforme sugerido na abordagem multiple instance, considera-se 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. 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 formato de valores separados por vírgula, então se contará apenas uma vez, observando que a funcionalidade será da ferramenta e não da aplicação. 6. Considerações Especiais para Planejamento e Acompanhamento de Projetos Este capítulo tem como propósito apresentar diretrizes para o planejamento e acompanhamento de projetos com o auxílio da métrica Ponto de Função e de técnicas relacionadas. Com base nesta finalidade é descrito um processo de estimativas de projetos de software aderente à área de processo de Planejamento de Projeto do CMMI (Capability Maturity Model Integration). Nesse contexto, são apresentados: o método Contagem Estimativa de Pontos de Função (CEPF) para estimar o tamanho dos projetos de software em PF, o modelo simplificado de estimativas para estimar o esforço dos projetos em homem-hora (HH) e a fórmula de Capers Jones para estimar os prazos dos projetos. Também são apresentadas recomendações para o gerenciamento de: mudanças de requisitos, projetos cancelados e progresso de projetos, e considerações sobre redução de cronograma e fator de criticidade de solicitação de serviços. 6.1 Diretrizes para Planejamento: Estimativas de Projetos de Software Esta seção define métodos para estimativas de projetos de software. A Figura 2 ilustra um processo de estimativas de projetos de software, descrito nos parágrafos seguintes. Roteiro de Métricas de Software do SISP

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

37 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 é concluído, deve-se aferir e documentar o tamanho, prazo, custo, esforço e recursos realizados, 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 [Hazan, 2008]. Portanto, para os contratos de projetos de software, baseados na métrica Ponto de Função, as estimativas devem ser realizadas em, no mínimo, três marcos do processo de desenvolvimento de software, a saber: Estimativa inicial: realizada após o fechamento do escopo do projeto. Geralmente é baseada em um documento inicial de requisitos como, 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. 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; - Um Compromisso é um acordo da gerência com as equipes técnicas para alcançar uma meta [Parthasarathy, 2007]. Em um cenário ideal, os resultados da estimativa atendem às 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. Contagem de Pontos de Função de Referência: realizada após o aceite dos requisitos. Geralmente, leva em consideração a especificação dos casos de uso e regras de negócio da aplicação. Pode ser aplicada a contagem estimada ou a detalhada. Contagem de Pontos de Função Final: realizada após a homologação da aplicação. Esta contagem considera as funcionalidades efetivamente entregues para o usuário pela aplicação. Neste caso, deve ser aplicada a contagem detalhada. Para fins de faturamento, realizado durante o desenvolvimento, deve-se considerar a Contagem de Referência e posteriormente realizar os ajustes no faturamento após a Contagem Final. É importante ressaltar que as mudanças de requisitos também serão consideradas no tamanho do projeto a ser faturado (ver subseção 6.2.1). Além disso, se estas mudanças forem significativas, maiores que a evolução de requisitos (scope creep) prevista na estimativa inicial, o prazo do projeto deve ser reestimado. Toda mudança de requisito deve passar por uma análise de impacto entre contratante e contratada. As subseções seguintes apresentam os métodos de estimativas de tamanho, prazo, custo e esforço a serem utilizados nos projetos de software em contratos. Roteiro de Métricas de Software do SISP

38 6.1.1 Contagem Estimativa de Pontos de Função (CEPF) Antes de definir o método de estimativas Contagem Estimativa de Pontos de Função (CEPF), é importante destacar que estimar significa utilizar o mínimo de tempo e esforço para se obter um valor aproximado dos pontos de função do projeto de software investigado [Meli, 1999]. Assim, é recomendável sempre fazer uma distinção entre os termos e conceitos: contagem de pontos de função e estimativa de pontos de função. Contagem de Pontos de Função: significa medir o tamanho do software por meio do uso das regras de contagem do IFPUG [IFPUG, 2010b]; Estimativa de Pontos de Função: significa fornecer uma avaliação aproximada do tamanho de um software utilizando métodos diferentes da contagem de pontos de função do IFPUG. O método CEPF visa aferir o tamanho em PF de maneira simplificada, com base no conhecimento dos requisitos iniciais do projeto [Hazan, 2005]. A CEPF foi definida com base nas diretrizes adotadas no método Contagem Estimada de Pontos de Função da NESMA [NESMA, 2005]. A diferença é que o método da NESMA não recomenda a análise das funções identificadas, considerando todas as funções de dados identificadas com complexidade Baixa e as funções transacionais com complexidade Média. A CEPF propõe a análise das funcionalidades identificadas, e caso não seja possível determinar a complexidade, então são adotadas as diretrizes do método Contagem Estimada da NESMA. A CEPF também apresenta algumas dicas para ajudar um estimador no mapeamento dos requisitos iniciais nos tipos funcionais da Análise de Pontos de Função. Segue a descrição da CEPF [Hazan, 2005]. Primeiramente, 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 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) (Figura 3). 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 (Tabela 1). O estimador deve realizar uma leitura do 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, 2010b]. Em outras palavras, os processos elementares são funções transacionais independentes, isto é, funções sequenciais pertencem a um mesmo processo elementar e funções independentes constituem processos elementares diferentes. Roteiro de Métricas de Software do SISP

39 Documentação do Software Abstração orientada a dados Usuários Identificação dos itens da APF Aplicação Pontos de Função (números) Mapeando em números Outras Aplicações Transações (EEs, CEs, SEs) Dados Internos (ALIs) Dados Externos (AIEs) Figura 3: Modelo Lógico da Análise de Pontos de Função Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para classificá-lo em Entrada Externa, Consulta Externa ou Saída Externa. Adicionalmente, o estimador deve descobrir os dados associados ao processo elementar, visando a determinação da complexidade funcional da função identificada. Caso não seja possível a identificação da complexidade da funcionalidade 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 Baixa. É 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 tabelas: Tabela 2 - Contagem dos 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 m x n 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 ALI dos sistemas são de complexidade Baixa. Roteiro de Métricas de Software do SISP

40 N ALI Baixa: X 7 PF N ALI Média: X 10 PF N ALI Alta: X 15 PF Total PF: Tabela 2: Identificação dos Arquivos Lógicos Internos da Aplicação Tabela 3 - Contagem de 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. Frequentemente, o referenciamento 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 AIE. Não são considerados AIE arquivos físicos, arquivos de índice, arquivos de trabalho, tabelas de relacionamento sem atributos próprios e entidades fracas. Geralmente, os AIE dos sistemas possuem a classificação de complexidade Baixa, porque são considerados para a determinação da complexidade funcional do AIE apenas os atributos referenciados pela aplicação que está sendo contada. N AIE Baixa: X 5 PF N AIE Média: X 7 PF N AIE Alta: X 10 PF Total PF: Tabela 3: Identificação dos Arquivos de Interface Externa da Aplicação Tabela 4 - Contagem de Entradas Externas (EE): funcionalidades que mantêm os Arquivos Lógicos Internos (ALI) 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, 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 Entradas Externas identificadas com complexidade Média. N EE Baixa: X 3 PF N EE Média: X 4 PF Roteiro de Métricas de Software do SISP

41 N EE Alta: X 6 PF Total PF: Tabela 4: Identificação das Entradas Externas da Aplicação Tabela 5 - Contagem de 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: Você está desenvolvendo uma função para apresentar informações para o usuário: uma consulta, relatório, listbox, download, geração de um arquivo, geração de arquivo pdf, xls? Esta função não possui cálculos ou algoritmos para derivação dos dados referenciados nem altera um Arquivo Lógico Interno e 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. N CE Baixa: X 3 PF N CE Média: X 4 PF N CE Alta: X 6 PF Total PF: Tabela 5: Identificação das Consultas Externas da Aplicação Tabela 6 - Contagem de 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: Você está desenvolvendo uma funcionalidade 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. Se você não possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Saídas Externas com complexidade Média. Roteiro de Métricas de Software do SISP

42 N SE Baixa: X 4 PF N SE Média: X 5 PF N SE Alta: X 7 PF Total PF: Tabela 6: Identificação das Saídas Externas da Aplicação A estimativa de tamanho do projeto em PF deve ser gerada com a totalização dos PF obtidos nas Tabelas 2, 3, 4, 5 e 6. A fórmula de contagem ou de estimativa de pontos de função para projetos de desenvolvimento é a seguinte: PF_DESENVOLVIMENTO = PF_INCLUIDO + PF_CONVERSÃO Este roteiro recomenda a supressão do PF_CONVERSÃO das fórmulas de contagem de pontos de função de projetos de desenvolvimento, conforme descrito na seção Estimativa de Esforço de Projetos de Software Uma vez que o tamanho do projeto foi estimado em pontos de função, o próximo passo é estimar o esforço de desenvolvimento do projeto, bem como sua distribuição pelas fases do ciclo de vida do desenvolvimento do software. A Engenharia de Software possui vários modelos para estimar esforço de projetos de software, baseados em pontos de função, sendo o Modelo Simplificado de Estimativas [Vazquez, 2012] e o Modelo COCOMO II [Boehm, 2009] os mais utilizados. Neste roteiro é adotado o Modelo Simplificado de Estimativas. O Modelo Simplificado de Estimativas consiste em obter um índice de produtividade em horas/pf para o projeto específico em questão, e então multiplicar o tamanho em PF do projeto pelo índice de produtividade, conforme a fórmula [Vazquez, 2012]: Esforço (horas) = Tamanho (PF) x Índice de Produtividade (HH/PF) O índice de produtividade depende de diversos atributos dos projetos, dentre outros: plataforma tecnológica, complexidade do domínio, segurança, desempenho, usabilidade, tamanho do projeto, tipo de manutenção, desenvolvimento de componentes. Cada órgão ou entidade deverá possuir sua própria tabela de produtividade para cada linguagem, considerando-se sempre dados históricos dos projetos já realizados. Roteiro de Métricas de Software do SISP

43 Distribuição de Esforço por Fase do Projeto O próximo passo é a definição da distribuição de esforço pelas macroatividades (fases) do projeto, visando definir o valor agregado ao projeto após cada fase do ciclo de vida. A Tabela 7 é uma sugestão de macroatividades e distribuição de esforço proposta neste roteiro. Ressaltamos que o órgão pode definir outras macroatividades e subdividilas para melhor aderência à sua metodologia e aos marcos de entrega. Além disso, os percentuais de esforço sugeridos podem variar de acordo com o tipo de projeto e o processo de desenvolvimento utilizado no órgão. Nesses casos, as macroatividades e distribuição de esforço devem estar documentadas na metodologia do órgão (especificada contratualmente) ou formalizadas diretamente no contrato. Macroatividades do Processo de Desenvolvimento de Software Percentual de esforço (%) Engenharia de Requisitos 25% Design / Arquitetura 10% Implementação 40% Testes 15% Homologação 5% Implantação 5% Tabela 7: Distribuição de Esforço por Macroatividades do Projeto Estimativa de Prazo de Projetos de Software As estimativas de prazo não são lineares com o tamanho do projeto. O melhor tempo de desenvolvimento (onde há uma melhor relação custo x benefício de alocação de recursos e menor prazo de desenvolvimento, dado o tamanho de um projeto específico), conforme fórmula descrita abaixo, é sugerido e utilizado nas estimativas de prazo deste roteiro. 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 da Figura 4. O método utilizado para estimar o prazo dos projetos (Td) é baseado na fórmula de Capers Jones [Jones, 2007]. Esta estima o prazo, baseando-se no tamanho do projeto em pontos de função, da seguinte maneira: Onde: Td: prazo de desenvolvimento Td = V t V: tamanho do projeto em pontos de função Roteiro de Métricas de Software do SISP

44 t: o expoente t é definido de acordo com a Tabela 8 Figura 4: Relação entre a Estimativa de Prazo e de Esforço Tipo de Sistema Sistema Comum Mainframe (desenvolvimento de sistema com alto grau de reuso ou manutenção evolutiva) Expoente t 0,32 a 0,33 Sistema Comum WEB ou Cliente Servidor 0,34 a 0,35 Sistema OO (se o projeto OO não for novidade para equipe, não tiver o desenvolvimento de componentes reusáveis, considerar sistema comum) Sistema Cliente/Servidor (com alta complexidade arquitetural e integração com outros sistemas) Sistemas Gerenciais complexos com muitas integrações, Datawarehousing, Geoprocessamento, Workflow 0,36 0,37 0,39 Software Básico, Frameworks, Sistemas Comerciais 0,40 Software Militar (ex: Defesa do Espaço Aéreo) 0,45 Tabela 8: Expoente t por Tipo de Projeto É importante destacar que o método só deve ser aplicado para projetos com mais de 100 PF. Caso o órgão possua dados históricos de projetos, então este deve trabalhar com seus dados históricos e modelos de estimativas. Caso o projeto seja menor, o prazo deve ser obtido por meio da definição de prazo máximo por tamanho funcional com base em dados históricos do órgão, conforme a Tabela 9. Roteiro de Métricas de Software do SISP