Manual de Métricas de Software do <SISP> – Análise de
Pontos de Função
Histórico de Versões
Data Versão Descrição Autor Revisor Aprovado por
11/07/10 1 Manual para auxílio na contagem de pontos de função Rafael Campos / Carlos Renato Ramos
Sumário
1. Introdução...3
2. Objetivo...3
3. Estimativas de Projetos de Software...4
4. Contagem de Pontos de Função de Projetos de Manutenção...14
5. Itens não-mensuráveis...23
6. Considerações para Contagem de Pontos de Função...37
7. Contagem de Pontos de Função com Múltiplas Mídias...40
8. Processo de Revisão do Guia de Contagem...42
9. Conclusão...43
1. Introdução
Diversas instituições, públicas e privadas, têm utilizado a métrica de Pontos de Função (PF) nas estimativas e dimensionamento de tamanho funcional de projetos de software, devido aos diversos benefícios de utilização da métrica (independência da solução tecnológica utilizada) e às recomendações dos órgãos de controle do governo brasileiro.
O manual de práticas de contagem de Pontos de Função (CPM 4.3) [IFPUG, 2010] publicado pelo International Function Point Users Group (IFPUG) define as regras de contagem de Pontos de Função. No entanto, a contagem de Pontos de Função é baseada no projeto lógico da aplicação (logical design) e nas fases iniciais do ciclo de vida do software, o documento de requisitos para a estimativa e elaboração do plano do projeto é um documento inicial de requisitos, por exemplo: Documento de Visão, Formalização Simples de Requisitos ou algum outro tipo de especificação elaborada pelo analista de negócios. Assim, torna-se importante o estabelecimento de métodos para estimar o tamanho funcional dos projetos de software nas fases iniciais do ciclo de vida.
Outro ponto a ser destacado é a importância da definição de métodos para geração de estimativas de prazo, esforço, custo e recursos computacionais dos projetos de software da empresa, visando melhorar o gerenciamento dos projetos.
Além disso, é importante ressaltar que a métrica de Pontos de Função foi concebida como uma medida de tamanho funcional para projetos de desenvolvimento e de manutenção evolutiva de software. No entanto, os projetos de software não estão limitados a projetos de desenvolvimento e projetos de manutenção evolutiva ou Melhoria (enhancement). Assim, torna-se essencial a definição de métodos para dimensionar o tamanho de projetos de manutenção (maintenance) baseados em Pontos de Função para que estes projetos possam ser avaliados e gerenciados com base em uma métrica.
É importante frisar que o Manual de Práticas de Contagem (CPM) é um documento que se destina a mensurar software, não tendo por objetivo principal suportar contratos de desenvolvimento de software. Assim, torna-se necessário criar manuais complementares, como este apresentado, que deverá contemplar os pontos não cobertos pelo manual do IFPUG, mas vivenciados pelos órgãos e entidades do SISP.
Observe que a Instrução Normativa 04, publicada pela SLTI/ MPOG, preconiza a utilização de métricas em contratos de software. Os Acórdãos do Tribunal de Contas da
União (TCU) recomendam a utilização da métrica Pontos de Função Não Ajustados. A versão 4.3 do CPM também reconhece o PF Não Ajustado como método padrão do IFPUG.
2. Objetivo
Este documento tem como propósito apresentar um roteiro contagem de Pontos de Função aderente ao Manual de Práticas de Contagem (CPM 4.3) e definir os tipos de projetos de manutenção e uma sistemática para dimensionar o tamanho de tais projetos, utilizando a métrica Pontos de Função, inclusive abrangendo os itens não-mensuráveis, que não são cobertos pelo manual do IFPUG. Além da contagem de Pontos de Função, este roteiro apresenta um processo de estimativas com base na métrica Pontos de Função, aderente ao modelo CMMI.
O documento foi construído baseando-se no “Roteiro SERPRO de Métricas para Contratos de Software”. Em todos os capítulos foram realizadas alterações, em alguns sendo mais significativas do que em outros, visando a contemplar as realidades vivenciadas nos diversos órgãos da Administração Pública Federal. Também foram consultados outros roteiros já utilizados em órgãos que utilizam a métricas de pontos de função em contratos de software, tendo como exemplo os itens não-mensuráveis obtido de editais de contratação do Ministério da Educação.
Este documento encontra-se organizado da seguinte maneira: O Capítulo 1 apresenta a motivação para a elaboração do documento; O Capítulo 2 mostra os objetivos aos quais este documento se propõe e a organização deste documento; O Capítulo 3 define o processo de estimativas de projetos de software integrado ao processo, indicando o momento de realização das estimativas e as análises a serem realizadas; O Capítulo 4 apresenta diretrizes para a estimativa e a contagem de Pontos de Função de todos os tipos de projetos de manutenção de software; O Capítulo 5 descreve a medição de itens não-mensuráveis; O Capítulo 6 apresenta algumas considerações importantes sobre utilização de métricas para dimensionar as mudanças de requisitos e redução de cronograma; O Capítulo 7 define um Guia para contagem de Múltiplas Mídias; O Capítulo 8 apresenta o processo de revisão deste guia de contagem; Finalmente, o Capítulo 9 conclui o documento apresentando sugestões para trabalhos futuros.
3. Estimativas de Projetos de Software
Este Capítulo tem como propósito descrever um processo de estimativas de projetos de software aderente ao CMMI. 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), a fórmula de Capers Jones para estimar os prazos dos projetos.
A Figura 1 ilustra um processo de Estimativas de Projetos de Software aderente à área de processo de Planejamento do Projeto do nível 2 do CMMI. Este processo é descrito em linhas gerais nos parágrafos seguintes.
Figura 1: 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 utilizado é um documento inicial de requisitos, por exemplo: 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 outras: 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 gerada a especificação de casos de uso, e sempre 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 Pontos de Função, as estimativas devem ser realizadas em 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, por exemplo 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 as metas de negócio. Quando este cenário não é real, é fundamental a redução de escopo do projeto, de modo que a meta se adapte aos resultados da estimativa.
• 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.
• Contagem de Pontos de Função Final: realizada após a homologação da
aplicação. Esta contagem leva em consideração as funcionalidades efetivamente entregues para o usuário pela aplicação.
Para fins de faturamento, que é realizado durante o desenvolvimento, deve-se considerar a Contagem de Referência e posteriormente considerar os ajustes no faturamento após a Contagem Final. É importante ressaltar que as mudanças de requisitos também serão consideradas no tamanho projeto a ser faturado, conforme descrito no capítulo 6. 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 seções seguintes apresentam os métodos de estimativas de tamanho prazo, custo e esforço a serem utilizados nos projetos de software em contratos efetuados com a <instituição>.
3.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, para evitar confusão, é 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, 2010];
• 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. Inicialmente, os requisitos funcionais iniciais documentados nas propostas comerciais, nos documentos de visão, formalização simples de requisitos ou em qualquer especificação inicial do sistema do usuário são mapeados nos tipos funcionais da Análise de Pontos de Função: Arquivo Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE) e Saída Externa (SE). Posteriormente, os Pontos de Função são associados a cada função identificada, baseando-se nas tabelas de complexidade e de contribuição funcional do CPM (Figura 2).
O estimador deve realizar uma leitura no documento inicial de requisitos, buscando informações relevantes para a identificação de processos elementares. O processo elementar é definido como a menor unidade de atividade significativa para o usuário. O processo elementar deve ser completo em si mesmo, independente e deixar a aplicação em um estado consistente [IFPUG, 2010]. Em outras palavras, os processos elementares são funções transacionais independentes, isto é, funções seqüenciais pertencem a um mesmo processo elementar e funções independentes constituem processos elementares diferentes.
Figura 2: 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 Simples. É importante ressaltar que se o estimador identificar mais de um Registro Lógico no Arquivo Lógico Interno, recomenda-se utilizar a complexidade Média. A seguir são apresentadas dicas para ajudar no mapeamento dos
requisitos funcionais da aplicação nos tipos funcionais da APF. As necessidades e funcionalidades especificadas para o projeto, contidas no documento inicial de requisitos, devem ser enquadradas em uma das seguintes tabelas:
Tabela 1 - Contagem dos Arquivos Lógicos Internos (ALIs): Banco de Dados Lógico
da Aplicação (tabelas e arquivos mantidos pela aplicação).
Considerações: Identifique os grupos de dados lógicos de aplicação nos modelos
de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos documentos de requisitos (Documento de Visão, Relação de Casos de Uso, etc.). Não considere arquivos físicos, arquivos de índices, arquivos de trabalho e tabelas de relacionamento sem atributos próprios (tabelas que existem para quebrar o relacionamento nxn e apenas transportam as chaves estrangeiras). As entidades fracas também não são consideradas um ALI. Se possível, tente descobrir os atributos lógicos, campos reconhecidos pelo usuário, e subgrupos de dados existentes para obter a complexidade funcional, segundo as regras de contagem do CPM. Caso não seja possível, a experiência tem mostrado que a maioria dos ALIs dos sistemas são de complexidade Simples.
Tabela 1: Identificação dos Arquivos Lógicos Internos da Aplicação
Tabela 2 - Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de
outras Aplicações, apenas referenciados pela aplicação que está sendo estimada (tabelas e arquivos mantidos por outra aplicação).
Considerações: Identifique os grupos de dados lógicos de outras aplicações
referenciados pela aplicação que está sendo estimada. Freqüentemente, 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 AIEs. Não são considerados arquivos físicos, arquivos de índice, arquivos de trabalho, tabelas de relacionamento sem atributos próprios e entidades fracas.
Geralmente, os AIEs dos sistemas possuem a classificação de complexidade
Simples. Porque, são considerados para a determinação da complexidade funcional do
AIE apenas os atributos referenciados pela aplicação que está sendo contada.
Tabela 3 - Contagem de Entradas Externas (EEs): Funcionalidades que mantêm os
Arquivos Lógicos Internos (ALIs) ou alteram o comportamento da aplicação.
Considerações: Identifique as funcionalidades de manutenção de dados. Conte
separadamente a inclusão, alteração e exclusão de dados, isto é, cada função independente de inclusão ou alteração ou exclusão deve ser contada separadamente. A aplicação possui funções de entrada de dados que alteram o comportamento dela, por exemplo: processamentos batch, ou processamento de informações de controle? Caso positivo, estas funções também devem ser identificadas como Entradas Externas.
Se você não possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Entrada Externa identificada com complexidade Média.
Tabela 3: Identificação das Entradas Externas da Aplicação
Tabela 4 - Contagem de Consultas Externas (CEs): 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, browse, listbox, download, geração de um arquivo, geração de arquivo psd, xls? Esta função não possui cálculos ou algoritmos para derivação dos dados referenciados nem altera um Arquivo Lógico Interno, nem muda o comportamento do sistema? Caso positivo, estas funções devem ser identificadas como Consultas Externas. Se você não possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Consultas Externas com complexidade Média.
Tabela 4: Identificação das Consultas Externas da Aplicação
Tabela 5 - Contagem de Saídas Externas (SEs): Funcionalidades que apresentam
informações para o usuário com utilização de cálculos ou algoritmos para derivação de dados ou atualização de Arquivos Lógicos Internos ou mudança de comportamento da aplicação. 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.
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. Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Saídas Externas com complexidade
Média.
Tabela 5: Identificação dos Saídas Externas da Aplicação
A Estimativa de tamanho do projeto em PFs deve ser gerada totalizando-se os PFs obtidos nas Tabelas 1, 2, 3, 4, e 5.
A fórmula de contagem ou de estimativa de Pontos de Função para Projetos de Desenvolvimento é a seguinte:
PF_Desenvolvimento = PF_Não_Ajustado + PF_Conversão
Observação: PF_Conversão: Pontos de Função associados às funcionalidades de
conversão de dados dos projetos. Exemplos de funções de conversão incluem: migração ou carga inicial de dados para popular as novas tabelas criadas no sistema e relatórios associados à migração de dados. Importante ressaltar que a contagem dos PF_Conversão são efetuadas de forma separada da contagem dos PF_Não_Ajustado, por serem de produtividades diferentes, ou seja, ao contar os PF_Conversão utilizar produtividade própria, quando for o caso.
3.2 Estimativa de Esforço de Projetos de Software
Uma vez que o tamanho do projeto está estimado em Pontos de Função, o próximo passo é estimar o esforço de desenvolvimento 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, 2010] e o Modelo COCOMO II [Boehm, 2000] os mais utilizados. Neste manual é adotado o modelo Simplificado de Estimativas. Futuramente, pretende-se utilizar também o COCOMO II.
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, 2010]:
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 instituição deverá possuir sua própria tabela de produtividade para cada linguagem, considerando-se sempre dados históricos dos projetos já realizados na instituição.
3.2.1 Distribuição de Esforço por Fase do Projeto
O próximo passo é a definição da distribuição de esforço pelas macro atividades do projeto, visando definir o valor agregado ao projeto após cada fase do ciclo de vida (Tabela 5).
Tabela 5: Distribuição de Esforço por Macro atividades do Projeto
A Tabela 5 é uma sugestão de distribuição de esforço em projetos típicos, no entanto, em se tratando um projeto com características específicas, estes percentuais devem ser alterados para o projeto em questão. Nesses casos, o estimador deve justificar, com observações no documento de estimativas, as premissas utilizadas para a alteração dos percentuais.
Os contratos estabelecidos devem determinar o processo de desenvolvimento a ser seguido com percentual de esforço por fases.
3.3 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, no qual há uma melhor relação custo x benefício de alocação de recursos e menor prazo de desenvolvimento, dado o tamanho de um projeto específico, é sugerido e utilizado nas estimativas de prazo deste manual. Jones [Jones, 2007] propõe uma fórmula para o cálculo do melhor tempo de desenvolvimento, denominado Td e de Região Impossível (RI) de desenvolvimento (Figura 3). 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 (Figura 3) 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 3 .
Figura 3: Relação entre a Estimativa de Prazo e de Esforço
O método utilizado para estimar o prazo dos projetos (Td) é baseado na fórmula de Capers Jones [Jones, 2007]. A fórmula de Capers Jones estima o prazo, baseando-se no tamanho do projeto em Pontos de Função, da seguinte maneira:
Td = V
tOnde:
Td: prazo de desenvolvimento
V: tamanho do projeto em Pontos de Função
Tabela 6: Expoente t por tipo de Projeto
É importante destacar que o método só funciona para projetos com mais de 100 PFs. Caso o projeto seja menor, o prazo deve ser obtido por meio de WBS. O prazo calculado considera todo o ciclo de vida do projeto, desde a fase de requisitos até a implantação. Assim, caso a estimativa tenha sido realizada ao final da fase de requisitos, descontar do prazo restante, o tempo gasto com a fase de requisitos.
Caso seja necessário receber o projeto em um prazo menor que o tudo calculado, recomenda-se propor um processo de desenvolvimento incremental, priorizando funcionalidades em cada iteração de acordo com a necessidade dele. Caso, ainda assim, a estimativa não atenda às necessidades do cliente, então pode-se reduzir o Td em até 25%, observando-se a Região Impossível. No entanto, quanto mais perto da Região Impossível, o esforço e o custo do projeto aumentam de maneira exponencial. Assim, de um modo geral, a redução de prazo de 10 % implica no aumento de esforço de 25%; a redução de prazo de 20% implica no aumento de esforço de 50% ; a redução de prazo de 25% implica em um aumento de esforço de 60%.
Não é recomendada a redução de prazo em mais de 20%.
Os percentuais de aumento de esforço são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão.
Na seção seguinte é abordada a questão da distribuição de esforço e alocação de pessoas ao projeto em questão.
3.3.1 Alocação de Equipe ao Projeto
Na alocação de equipe, deve ser considerada a estimativa de prazo e a de esforço. Sugere-se utilizar a fórmula seguinte:
Equipe = Esforço (HH) / (21 x prod. diária x Prazo )
Onde:
prazo = Td em meses
Prod. Diária = 6h/dia ou 7h/dia (recomenda-se considerar 6 horas/dia) 21 = dias úteis contidos em 1 mês
O tamanho da equipe é obtido em quantidade de recursos para o desenvolvimento do projeto, deve-se considerar percentuais de alocação. Por exemplo, suponha uma Equipe de 2,2 recursos. Esta equipe pode conter 5 pessoas, sendo que 4 pessoas com 50% de alocação e um líder de projeto com 20% de alocação ao projeto.
3.4. Método para Estimativa de Custo
A estimativa de custo do projeto deve levar em consideração o custo de um ponto de função. A contratada já deverá considerar o custo da hora de todos os profissionais envolvidos no desenvolvimento da solução de software. O cálculo do custo do projeto (CP) será então da seguinte forma:
CP = QPF x CPF
QPF = Tamanho do Projeto em PF
CPF = Custo para implementar um Ponto de Função na plataforma em questão
3.5 Estimativa de Recursos Computacionais
A Estimativa de Recursos Computacionais também deve ser considerada, esta constitui um componente importante para as estimativas de custos dos projetos. Um recurso computacional é um hardware que se precisa adquirir; ou que se possui, mas precisa-se configurar. Exemplos de recursos computacionais incluem, dentre outros: espaço em disco para o sistema entrar em produção, um servidor específico para teste ou homologação do sistema. Devem ser registradas as seguintes informações associadas aos recursos computacionais críticos:
• Nome do Recurso Computacional: [considere exclusivamente hardware: micro, periférico, expansão de memória, área em disco, banda de rede, etc]
• Descrição:
• Responsável pela Disponibilização:
• Data Limite:
• Parâmetros: [características do recurso: quantidade, perfil, configuração, etc]
• Tipo do Recurso: [D: recurso para ambiente de Desenvolvimento; P: recurso para
ambiente de Produção; H: recurso para ambiente de Homologação]
• Custo (Opcional): [Custo do recurso computacional. Não considerar custos de
processamento ou custos operacionais de produção.]
Caso o projeto a ser desenvolvido não possua nenhum recurso computacional crítico, deve ser registrado no documento de estimativas que o projeto não possui nenhum recurso computacional crítico.
4. Contagem de Pontos de Função de Projetos de Manutenção
Esta seção tem como propósito descrever os diversos tipos de projetos de manutenção e mostrar uma solução para o seu dimensionamento em Pontos de Função, visto que o manual de práticas de contagem – CPM não contempla projetos de manutenção (maintenance) apenas o de Melhoria (enhancement).
Quanto à documentação de projetos de manutenção pequenos (menores que 100 PF), deve-se registrar a solicitação e documentar os requisitos da aplicação impactada pela demanda, de forma detalhada, visando apoiar a contagem de Pontos de Função da demanda. É importante também documentar as estimativas e a contagem de Pontos de Função.
4.1 Projeto de Melhoria
O Projeto de Melhoria (enhancement), também denominada de projeto de melhoria funcional, ou manutenção evolutiva, está associado às mudanças em requisitos funcionais da aplicação, ou seja, a inclusão de novas funcionalidades, alteração ou exclusão de funcionalidades em aplicações implantadas.
Segundo o padrão IEEE Std 1229 [IEEE 1229], esta manutenção seria um tipo de manutenção adaptativa, definida como: modificação de um produto de software concluído após a entrega para mantê-lo funcionando adequadamente em um ambiente com
mudanças. O projeto de melhoria é considerado um tipo de projeto de manutenção adaptativa com mudanças em requisitos funcionais da aplicação, ou seja com funcionalidades incluídas, alteradas ou excluídas na aplicação, segundo o CPM 4.3.
Este documento separa o projeto de melhoria, quando as mudanças são associadas aos requisitos funcionais e a manutenção adaptativa quando as mudanças estão associadas aos requisitos não funcionais da aplicação.
Um projeto de melhoria consiste em demandas de criação de novas funcionalidades (grupos de dados ou processos elementares), demandas de exclusão de funcionalidades (grupos de dados ou processos elementares) e demandas de alteração de funcionalidades (grupos de dados ou processos elementares) em aplicações implantadas em produção.
Uma função de dados (Arquivo Lógico Interno ou Arquivo de Interface Externa) é considerada alterada, quando a alteração contemplar mudanças de item de dados, inclusão ou exclusão de item de dados. Ou mudança de tamanho (número de posições) ou tipo de campo (por exemplo: mudança de numérico ou alfanumérico), sendo que esta ocorre por mudança de regra de negócio do usuário.
Uma função transacional (Entrada Externa, Consulta Externa e Saída Externa) é considerada alterada, quando a alteração contemplar:
• Mudança de itens de dados em uma função existente; • Mudança de arquivos referenciados;
• Mudança de lógica de processamento, segundo as ações das lógicas e processamento do CPM 4.3
A Lógica de Processamento é definida como requisitos especificamente solicitados pelo usuário para completar um processo elementar. Esses requisitos devem incluir as seguintes ações:
• Validações são executadas
• Fórmulas matemáticas e cálculos são executados • Valores equivalentes são convertidos
• Dados são filtrados e selecionados através da utilização de critérios • Condições são analisadas para verificar quais são aplicáveis
• Um ou mais ALIs são atualizados
• Um ou mais ALIs e AIEs são referenciados
• Dados ou informações de controle são recuperados
• Dados derivados são criados através da transformação de dados existentes, para criar dados adicionais
• O comportamento do sistema é alterado
• Preparar e apresentar informações para fora da fronteira
• Receber dados ou informações de controle que entram pela fronteira da aplicação • Dados são reordenados
A contagem ou estimativa de Pontos de Função de projetos de manutenção evolutiva (projetos de melhoria) seguirá conforme preconizada pela publicação "Function Point Analysis for Software Enhancement Guidelines" da Nesma – Netherlands Software Metrics Users Association [NESMA, 2009], entidade que aprofunda o tema e apresenta alternativas técnicas à proposta original do IFPUG:
PF = (PF INCLUIDO + PF EXCLUIDO + PF ALTERADO + PF_CONVERSÃO )
PF_INCLUÍDO = Pontos de Função associados às novas funcionalidades que farão parte
da aplicação.
PF_ALTERADO = Pontos de Função associados às funcionalidades existentes na
aplicação que serão alteradas no projeto de manutenção, incluso o fator de impacto conforme preconizada pela [NESMA, 2009].
PF_EXCLUÍDO = Pontos de Função associados às funcionalidades existentes na
aplicação que serão excluídas no projeto de manutenção, incluso o fator de impacto conforme preconizada pela [NESMA, 2009].
PF_CONVERSÃO = Pontos de Função associados às funcionalidades de conversão de
dados dos projetos de melhoria. Exemplos de funções de conversão incluem: migração ou carga inicial de dados para popular as novas tabelas criadas e relatórios associados à migração de dados. Importante ressaltar que a contagem dos PF_Conversão são efetuadas de forma separada da contagem dos PF_Não_Ajustado, por serem de produtividades diferentes, ou seja, ao contar os PF_Conversão utilizar produtividade própria, quando for o caso.
Para o cálculo dos Pontos de Função Incluídos, Alterados e Excluídos, segue-se conforme as fórmulas estabelecidas em [NESMA, 2009]:
PF_INCLUIDO = QPI;
PF_EXCLUIDO = QPE x 0.40;
PF_FD_ALTERADO = FD-QPA x FFD, sendo FFD entre 0,25 e 1,00, conforme tabela abaixo (para funções de dados);
PF_FT_ALTERADO = FT-QPA x FFT, sendo FFT entre 0,25 e 1,50, conforme tabela abaixo (para funções transacionais);
PF_ALTERADO = PF_FD_ALTERADO + PF_FT_ALTERADO.
Onde:
QPI = Quantidade de Pontos de Função incluídos; QPE = Quantidade de Pontos de Função excluídos;
PF_FD_ALTERADO = Pontos de Função alterados para Funções de Dados; PF_FT_ALTERADO = Pontos de Função alterados para Funções Transacionais; FD-QPA = Quantidade de Pontos de Função alterados em funções de dados; FT-QPA = Quantidade de Pontos de Função alterados em funções transacionais; FFD = Fator de impacto de alterações em funções de dados;
FFT = Fator de impacto de alterações em funções transacionais
O cálculo dos fatores de impacto são obtidos através dos percentuais de alterações conforme abaixo:
a) Funções de Dados:
Percentual de alterações em funções de dados (PFD) = QTDEA / QTDET x 100 QTDEA = Quantidade de Tipos de Dados Elementares Alterados
QTDET = Quantidade de Tipos de Dados Elementares Totais
Com o valor obtido em PFD, procura-se na tabela qual o valor do fator de impacto:
Fator de Impacto em Funções de Dados Alteradas (FFD)
PFD Entre 0 e 33% Entre 33% e 66% Entre 66% e 100% Maior que 100% Fator de Impacto
(FFD)
0,25 0,5 0,75 1
b) Funções Transacionais:
Percentual alterações em funções transacionais (PFT1) = QTDEA / QTDET x 100 Percentual alterações em funções transacionais (PFT2) = QFDLA / QFDLT x 100 QTDEA = Quantidade de Tipos de Dados Elementares Alterados
QTDET = Quantidade de Tipos de Dados Elementares Totais QFDLA = Quantidade de Funções de Dados Lógicos Alterados QFDLT = Quantidade de Funções de Dados Lógicos Totais
Fator de Impacto em Funções Transacionais Alteradas (FFT)
PFT2 / PFT1 Entre 0% e 66% Entre 66% e 100% Maior que 100%
Entre 0% e 33% 0,25 0,5 0,75
Entre 33% e 66% 0,5 0,75 1
Entre 66% e 100% 0,75 1 1,25
Maior que 100% 1 1,25 1,5
Caso FFT seja maior que 1, recomenda-se reconsiderar a melhoria.
4.2 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 em sistemas em produção.
É importante destacar que as demandas de manutenção corretiva freqüentemente precisam ser atendidas com urgência. Assim, o grau de criticidade do projeto poderá trazer impacto nas estimativas de custo e esforço. O padrão IEEE [IEEE,1998] define um tipo de manutenção corretiva, denominado de Manutenção Emergencial como “manutenção corretiva não programada executada para manter o sistema em estado operacional”.
Quando o sistema em produção tiver sido desenvolvido pela contratada , a manutenção corretiva será do tipo Garantia, conforme prazos e demais cláusulas do contrato em questão.
Quando o sistema não tiver sido desenvolvido pela contratada , deverá ser estimado e calculado o tamanho do projeto de manutenção corretiva.. A estimativa e dimensionamento de tamanho de projetos de manutenção corretiva em Pontos de Função devem levar em consideração a documentação do sistema disponível e os artefatos a serem mantidos. Seguem as fórmulas a serem consideradas:
a) Aplicação sem documentação ou com documentação desatualizada ou documentação incompleta e sem redocumentação de requisitos
Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades corrigidas considera 70% do PF_Alterado, observando os conceitos do CPM 4.3, apresentados na seção 4.1.
PF = PF_ALTERADO x 0,70
b) Aplicação sem documentação ou com documentação desatualizada ou incompleta ou completa e com redocumentação de requisitos
Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades corrigidas considera 80% do PF_Alterado, seguindo os conceitos do CPM 4.3, apresentados na seção 4.1.
Deve-se destacar que além da correção as funcionalidades em questão e da documentação do projeto de manutenção corretiva realizado, a documentação das funcionalidades deve ser atualizada pela contratada.
PF = PF_ALTERADO x 0,80
c) Aplicação com documentação completa
Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades corrigidas considera 60% do PF_Alterado, seguindo os conceitos do CPM 4.3, mostrados na seção 4.1. Deve-se ressaltar que não há necessidade de correção da documentação do sistema, apenas dos artefatos associados à correção do código.
PF = PF_ALTERADO x 0,60
Em todos os três itens acima, os percentuais de multiplicação são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão.
4.3 Manutenção Adaptativa em Requisitos Não Funcionais
Seguindo os conceitos da IEEE, existem vários tipos de Manutenção Adaptativa. Quando há mudança em requisitos funcionais, estes projetos são denominados de projetos de Melhoria, descritos na seção 4.1. Quando há mudança em requisitos não funcionais de interface, estes projetos são denominados de Manutenção Cosmética ou Manutenção Adaptativa – Mudança de Interface.
Esta seção visa apresentar alguns tipos manutenções adaptativas associadas às mudanças em requisitos não funcionais da aplicação, a saber: Redesenvolvimento de projetos em outra plataforma, Atualização de plataforma, Adequação de funcionalidades
às mudanças de negócio. Caso sejam identificados outros tipos de projetos de manutenção adaptativa em requisitos não funcionais, estes devem ser definidos e incorporados nesse Manual de Contagem.
4.3.1 Redesenvolvimento de Projetos em outra Plataforma
São considerados nesta categoria, projetos que precisam ser migrados para outra plataforma. Por exemplo, um sistema legado em COBOL precisa ser redesenvolvido em JAVA.
Como estes projetos legados, freqüentemente, encontram-se sem documentação, então serão considerados como novos projetos de desenvolvimento. Assim, será utilizada a fórmula de Projetos de Desenvolvimento do CPM 4.3.
PF = PF_NÃO_AJUSTADO + PF_CONVERSÃO
PF_CONVERSÃO = Pontos de Função associados às funcionalidades de conversão de dados dos projetos de desenvolvimento. Exemplos de funções de conversão incluem: migração ou carga inicial de dados para popular as novas tabelas criadas e relatórios associados à migração de dados. Importante ressaltar que a contagem dos PF_Conversão são efetuadas de forma separada da contagem dos PF_Não_Ajustado, por serem de produtividades diferentes, ou seja, ao contar os PF_Conversão utilizar produtividade própria, quando for o caso.
Neste caso, poderá ser criado um multiplicador conforme avaliação da base histórica dos serviços realizados no órgão.
4.3.2 Atualização de Plataforma
São consideradas nesta categoria, demandas para uma aplicação existente ou parte de uma aplicação existente executar em versões mais atuais de browsers (ex: versão atual do Internet Explorer, Mozila, Firefox,...) ou de linguagens de programação (ex: versão mais atual do JAVA ou do Banco de Dados). Também são consideradas nesta categoria aplicações Web desenvolvidas para executar em Internet Explorer que precisam executar também em browser em software livre. Nesta categoria foram observadas demandas dos seguintes tipos:
A)Atualização de Plataforma com necessidade de redocumentação de requisitos
Nestes casos, a aferição do tamanho em Pontos de Função da aplicação ou da parte da aplicação que sofreu impacto considera 50% dos PFs, seguindo a fórmula de projetos de desenvolvimento do CPM 4.3 e as funções de conversão de dados, se aplicável. Deve-se destacar que além da adequação as funcionalidades em questão e da documentação do projeto de manutenção adaptativa realizado, a documentação das funcionalidades deve ser atualizada.
PF = (PF_NÃO_AJUSTADO x 0,50) + PF_CONVERSÃO
B)Atualização de Plataforma sem necessidade de redocumentação de requisitos
aplicação ou da parte da aplicação que sofreu impacto considera 40% dos PFs, seguindo a fórmula de desenvolvimento do CPM 4.3 e as funções de conversão de dados, se aplicável.
PF = (PF_NÃO_AJUSTADO x 0,40) + PF_CONVERSÃO
Nos dois itens acima, os percentuais de multiplicação são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão.
4.3.3 Adequação de Funcionalidades às Mudanças de Negócio
São consideradas nesta categoria as demandas de manutenção adaptativa associadas à adequação de funcionalidades às mudanças de regras de negócio ou de Legislação ou requisitos de usabilidade que não se enquadram nas funções alteradas
do Projeto de Melhoria, seguindo as regras de contagem do CPM. Observe que tais
solicitações envolvem aspectos não funcionais, sem alteração em requisitos funcionais. Por exemplo: replicação de funcionalidade (chamar uma consulta existente na aplicação de outra tela, por demanda do usuário); replicação de base de dados ou criação de base temporária para resolver problemas de performance ou segurança; Alteração no software para adaptação às alterações realizadas em rotinas de integração com outros software (ex: alteração em subrotinas chamadas por este software). Nesta categoria foram observadas demandas dos seguintes tipos:
A)Adequação de funcionalidades com necessidade de redocumentação
Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades que sofreram impacto deve considerar 80% do PF_Alterado, seguindo os conceitos do CPM 4.3, apresentados na seção 4.1. Deve-se destacar que além da adequação das funcionalidades em questão e da documentação do projeto de manutenção adaptativa realizado, a documentação das funcionalidades deve ser atualizada.
PF = PF_ALTERADO x 0,80
B)Adequação de funcionalidades sem necessidade de redocumentação de requisitos
Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das funcionalidades que sofreram impacto deve considerar 70% do PF_Alterado, seguindo os conceitos do CPM 4.3, apresentados na seção 4.1. Não será contemplada a documentação das funcionalidades nas demandas desta categoria.
PF = PF_ALTERADO x 0,70
Nos dois itens acima, os percentuais de multiplicação são estimados,
podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão.
Para outros tipos de projetos de manutenção adaptativa não definidos neste documento, considerar um percentual do PF_Alterado, variando de 30% a 80%, de acordo com as características do requisito não funcional alterado. Versões futuras deste
Manual devem contemplar os novos tipos não definidos neste documento.
4.4 Apuração Especial
São funcionalidades executadas apenas uma vez para: corrigir problemas de dados incorretos na base dados das aplicações ou atualizar dados em bases de dados de aplicações, detalhado no item 4.5.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, detalhado no item 4.5.2.
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.
4.4.1 Apuração Especial – Base de Dados
Uma apuração especial é um projeto que inclui a geração de procedimentos para atualização da base de dados. 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 do indicador de matriz – sim ou não para um CNPJ. Nestes casos, a contagem de Pontos de Função das funcionalidades desenvolvidas. Geralmente, estas funcionalidades são classificadas como Entradas Externas.
PF = PF_NÃO_AJUSTADO
Deve-se ressaltar que as funções de conversão de dados (carga inicial de dados que ocorre na implantação de projetos de desenvolvimento ou de melhoria) não são apurações especiais. Estas funções fazem parte do projeto de desenvolvimento ou de melhoria em questão, portanto devem ser contadas junto com estes projetos e não como apuração especial. Assim, nestes casos, considera-se as fórmulas de contagem de Pontos de Função dos projetos em questão. Em alguns casos de Apuração Especial – Atualização de dados, o usuário solicita uma consulta prévia das informações atualizadas para validação. De fato, é uma prática interessante para evitar informações errôneas na base de produção dos sistemas. Esta Consulta Prévia, classificada como Consulta Externa ou Saída Externa deve ser dimensionada, considerando-se 60% do tamanho da funcionalidade em questão, conforme a fórmula abaixo:
PF = PF_NÃO_AJUSTADO x 0,60
4.4.2 Apuração Especial – Geração de Relatórios
Uma apuração especial é um projeto que inclui a geração de relatórios em uma ou mais mídias para o usuário. Em alguns casos, são solicitadas extrações de dados e envio dos dados para outros sistemas. Caso neste envio de dados sejam requisitadas atualizações no sistema de origem, então estas funções são Saídas Externas, devido à atualização do Arquivo Lógico Interno.
Deve-se destacar que estas funções são executadas apenas uma vez, não fazendo parte da aplicação. Nestes casos, considera-se contagem de Pontos de Função das funcionalidades desenvolvidas. Freqüentemente, estas funcionalidades são classificadas como Saídas Externas. Também podem ser classificadas como Consultas Externas, caso não possuam cálculos ou criação de dados derivados.
PF = PF_NÃO_AJUSTADO
4.5 Manutenção em Páginas Estáticas de Intranet, Internet ou Portal
Nesta seção são tratadas manutenções específicas em páginas estáticas de Portais, Intranets ou Websites. A demanda consiste na publicação de páginas HTML. Estas demandas são consideradas como desenvolvimento de consultas com a utilização de ferramentas para apoiar a publicação. Nestes casos, considera-se 50% dos Pontos de Função das consultas desenvolvidas. Cada página é contada como uma consulta. As consultas são consideradas Consultas Externas Simples (3 PF).
PF = PF_NÃO_AJUSTADO x 0,50
4.6 Manutenção de Documentação de Sistemas Legados
Nesta seção são tratadas demandas de documentação ou atualização de documentação de sistemas legados. Observe que o desenvolvedor deve realizar uma Engenharia Reversa da aplicação para gerar a documentação. Para este tipo de projeto, caso a demanda seja apenas a documentação de requisitos, devem ser considerados 20% dos Pontos de Função da aplicação em questão, conforme a fórmula abaixo.
PF = PF_NÃO_AJUSTADO x 0,20
Caso a demanda seja a geração de artefatos de documentação de todas as fases do processo de desenvolvimento, deve-se considerar um percentual mais alto de 30% a 50%, dependendo dos artefatos a serem gerados. As premissas utilizadas devem ser conforme cláusulas contratuais e documentadas no documento de estimativas do projeto.
4.7 Pontos de Função de Teste
Muitas vezes, em projetos de manutenção o conjunto de funções de dados e funções transacionais a serem testadas é maior do que a quantidade de funções a serem implementadas, i.e., além das funcionalidades que são afetadas diretamente pelo projeto de manutenção, outras precisam ser testadas [NESMA, 2009]. O tamanho das funções a serem testadas deve ser aferido em Pontos de Função de Teste (PFT). Não considerar as funcionalidades incluídas, alteradas ou excluídas do projeto de manutenção na contagem de Pontos de Função de Teste.
A contagem de PFT deve considerar o seguinte [NESMA, 2009]:
• Determinar o tamanho em Pontos de Função de cada função de dados ou transacional envolvida no teste.
• Calcular o tamanho em Pontos de Função de todas as funções de dados ou transacionais envolvidas no teste.
A conversão do PFT em Ponto de Função deve ser feita de acordo com a fórmula abaixo: PF = PFT x 0,20
É importante ressaltar que as funções testadas consideradas no PFT devem estar documentadas. Observe que estas funções farão parte do escopo do projeto de manutenção.
Nos itens da seção 4 acima, os percentuais são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão. Em casos onde não há percentuais, pode-se aplicar algum percentual, também conforme avaliação da base histórica dos serviços realizados no órgão.
5. Itens não-mensuráveis
Para calcular o esforço de atividades que não são passíveis de serem pontuadas pela técnica de Análise de Pontos de Função será adotada a tabela de itens não
mensuráveis conforme abaixo.
Os itens não mensuráveis devem ser convertidos em pontos de função para obtenção do tamanho do serviço, conforme validação da equipe interna do órgão. A medição é não cumulativa dentro da mesma funcionalidade, ou seja, caso uma funcionalidade possua itens mensuráveis e itens não mensuráveis (uma alteração no processo elementar e uma alteração de layout na mesma tela, por exemplo), apenas os itens mensuráveis devem ser contados.
Os percentuais são estimados, podendo ser reajustados conforme avaliação da base histórica dos serviços realizados no órgão.
Nome Descrição Pontuação
EST
TELAS - ESTILO - contemplam as alterações exclusivamente nos layouts de telas, no que se refere ao estilo, como por exemplo: mudança de cor, fonte ou alteração da logomarca da empresa, sem que haja alteração em elementos de dados, arquivos referenciados ou informações de controle.
Serão considerados 10% de 1 ponto de função por tela alterada.
10% de 1 PF
LAY
TELAS – LAYOUT – contemplam as alterações referentes exclusivamente aos
layouts de telas, mudança de posição de campos em telas, relatórios ou layout de
arquivos, divisão de telas e/ou relatórios, sem que haja alteração em elementos de dados, arquivos referenciados ou informações de controle.
Serão considerados 5% do total de pontos de função do processo elementar principal da tela. Este percentual é não cumulativo, ou seja, caso duas ou mais alterações de layout sejam realizadas na mesma tela, o percentual será aplicado apenas uma vez.
Além disso, caso haja alteração no tamanho funcional do processo elementar, será considerado somente este para pontuação.
5% de 1 PF do processo elementar
principal
CBD
CAMPOS DE BANCO DE DADOS – contemplam a inclusão, alteração ou exclusão de campos em tabelas, sem que tenha havido mudança na funcionalidade (não sendo necessidade de negócio e não tendo impacto na lógica de processamento). Contempla também mudança nas características do campo (tamanho, tipo, nomenclatura).
Serão considerados 5% do total de PF da função de dados.
5% de 1 PF da função de dados.
VAR
VARIÁVEIS EM PROGRAMAS – contemplam a inclusão, alteração ou exclusão de variáveis em programas, sem que tenha havido mudança na funcionalidade (não sendo necessidade de negócio e não tendo impacto na lógica de processamento). Contempla também mudança nas características da variável (tamanho, tipo, nomenclatura).
Serão considerados 5% do total de PF da função transacional.
5% de 1 PF da função transacional
MSG
MENSAGENS – contemplam a necessidade de alterações de mensagens de retorno ao usuário, desde que não acessem ALI ou AIE.
Será considerado 10% de 1 ponto de função, por grupo de mensagens de um mesmo processo elementar.
10% de 1 PF por grupo de mensagens.
MNU
MENUS - contemplam a necessidade de adição ou reestruturação de menus de navegação estáticos.
Serão considerados 10% de 1 ponto de função por página alterada, incluída ou excluída.
10% de 1 PF
HCD
DADOS HARD CODED - contemplam a necessidade de inclusão, alteração ou exclusão de dados pertencentes a listas (combo box) ou tabelas físicas.
Serão considerados 10% de 1 ponto de função por lista ou tabela física alterada, incluída ou excluída.
10% de 1 PF
PPR
PARÂMETROS DE PROCESSAMENTO - contemplam a necessidade de alteração dos valores dos parâmetros, sem que a lógica de processamento tenha sido alterada.
(Exemplo: ajustar filtro para recuperar dados entre 0 e 50 ao invés de valores entre 10 e 50).
Serão considerados 5% do total de pontos de função do processo elementar principal da tela. 5% de 1 PF do processo elementar principal FOR
FORMA DE ORDENAÇÃO – contempla a mudança de ordenação de crescente para decrescente, ou vice-versa.
Serão considerados 5% do total de pontos de função do processo elementar alterado. 5% de 1 PF do processo elementar alterado CDT
CODE DATA – contempla a necessidade de criação, alteração e exclusão de tabelas CODE DATA e respectivas funcionalidades na aplicação, ou seja, mantida pelo usuário.
Serão consideradas 20% do valor das funções de dados e/ou transacionais, caso fossem mensuráveis no tamanho funcional do projeto.
20% de 1 PF da função de dados ou transacional NMU
TABELAS NÃO MANTIDAS PELO USUÁRIO – contemplam tabelas que não são considerados arquivos lógicos, arquivos de interface ou registros lógicos, não sendo mantidos pelo usuário. Por exemplo, tabelas temporárias, code tables não mantidas pelo usuário, tabelas de log não reconhecidas pelo usuário, dados de controle não reconhecidos pelo usuário, tabelas utilizadas para auxílio da tecnologia (sumários ou resumos).
Serão considerados 10% de 1 ponto de função por tabela alterada, incluída ou excluída.
10% de 1 PF
AUX
PROGRAMAS AUXILIARES – contemplam dois conceitos:
• rotinas auxiliares desenvolvidas pelos técnicos para alterar campos em determinados registros de tabelas do sistema a pedido do gestor (deve ser ressaltado que não se trata de um caso de defeito, e sim, uma alteração pontual, geralmente em registros apontados pelo Gestor).
• geração de relatórios solicitados e/ou arquivos para identificar determinados registros na base para posterior acerto ou geração de arquivos para popular massa de teste (que serão utilizados uma única vez).
Serão considerados 50% de 1 ponto de função por programa auxiliar.
50% de 1 PF
EST
PÁGINAS ESTÁTICAS – contemplam a alteração, inclusão ou exclusão de páginas estáticas na aplicação, ou seja, que não possuem dados que atravessam a fronteira da aplicação.
Serão considerados 10% de 1 ponto de função por página alterada, incluída ou excluída.
10% de 1 PF
ENG
MANUTENÇÃO ADAPTATIVA – contempla a adequação do sistema às mudanças de ambiente operacional, compreendendo hardware e software básico, mudanças de versão, linguagem e SGBD, que não impliquem em inserção, alteração ou exclusão de funcionalidades. Estes casos serão tratados como manutenção adaptativa.
Serão considerados 40% do valor das funções transacionais e/ou de dados afetadas pela manutenção.
40% de 1 PF da função de dados e/ou transacional SAT
SERVIÇOS DE ATENDIMENTO - contempla a necessidade de execução de tarefas temporárias, não passíveis de serem pontuadas, como por exemplo: análise de demandas, execução de teste a pedido do usuário/Gestor, rotina de limpeza dentre outros.
Deverá ser considerado 1(um) recurso por dia, sendo 8 (oito) horas o esforço diário gasto
80% de 1 PF
Os trabalhos impressos e as atividades WEB serão contadas conforme a tabela abaixo.
Convém lembrar que as tabelas não são exaustivas, ou seja, identificando-se novos itens não-mensuráveis, eles devem ser adicionados à estas tabelas em versões
posteriores deste manual.
Nº /
Nome Descrição
Pontuação
1 LAYOUT, IMAGEM, e RELACIONADOS - contemplam itens diversos de design, relacionados ou não a mídia web. Necessitam de cuidado visual especializado e planejamento específico. Mensuração de horas estimada. Serão pontuados conforme atividade:
1.1 AJUSTES ou CORREÇÕES em FIGURAS, FOTOS, LOGOMARCAS: Unidade de ajuste/correção de imagem em bitmap ou vetor, para utilização dentro de arte de banner, selo, botão, animação, ou mesmo layout completo.
1.1.1 W111
Complexidade 1: Será utilizado como unidade cumulativa para mensuração de intervenção em imagem.
Exemplo: um ajuste em fotografia pode levar 1 unidade enquanto ajustes em logomarca bitmap podem levar 3 unidades de ajuste
20% de 1 PF por unidade
1.2
PESQUISA e SELEÇÃO de IMAGENS (FIGURAS, FOTOS, ÍCONES, etc.): Considera-se pesquisa e seleção de imagens o trabalho de pesquisa, identificação e seleção de fotos para utilização em composições de trabalhos de design de qualquer natureza, conforme identificados abaixo. Os ajustes e correções necessárias são tratados dentro das unidades de ajuste/correção previamente citadas. Número de horas não acumulativo para uma mesma peça de layout, e acumulativo para peças em diferentes formatos ou que necessitem de conceito diferenciado. Não inclui pagamento de direitos autorais para as fotografias/ícones/figuras selecionadas, que deverá ser tratado a parte entre o órgão solicitante e a Pessoa Jurídica executora do trabalho.
Esta atividade especifica informações para pesquisas de imagens incluídas no escopo de complexidade de outras atividades.
Quando o tempo previsto para pesquisa de imagens, nas atividades que já prevejam esta atividade, não for suficiente devido a solicitações de novas pesquisas pelo solicitante da atividade, ou outro motivo justificável, uma unidade ou mais unidades desta atividade serão contabilizados, somando-se ao prazo da atividade original.
1.2.1 W121
Complexidade 1: Pesquisa e seleção de imagens/fotos/ícones disponíveis em bancos de imagens já existentes e disponíveis para utilização pelo órgão, para fins de utilização em mídia online e offline.
15% de 1 PF por pesquisa e seleção 1.2.2
W122
Complexidade 2: Pesquisa e seleção de imagens/fotos/ícones fora de bancos de imagens do órgão ou nos casos em que estes não estejam disponíveis, para utilização em MÍDIA ONLINE.
40% de 1 PF por pesquisa e seleção 1.2.3
W123
Complexidade 3: Pesquisa e seleção de imagens/fotos/ícones fora de bancos de imagens do órgão ou nos casos em que estes não estejam disponíveis, para utilização em MÍDIA OFF LINE.
80% de 1 PF por pesquisa e seleção
1.3 CRIAÇÃO - ARTE PARA BANNER, SELO ou BOTÃO: Criação/Reformulação de arte única e personalizada para banner. Pressupõe a existência de roteiro já aprovado e revisado.
1.3.1 W131
Complexidade 1: Banner, selo ou botão estático com dimensões inferiores ou iguais a 150 por 150 pixels
15% de 1 PF por banner, selo ou botão
1.3.2 W132
Complexidade 2: Banner estático ou "animado" com dimensões superiores a 150 x 150 pixels, utilizando formatos de saída GIF, JPG ou PNG
25% de 1 PF por banner estático e 5% de 1 PF por keyframe do banner, no caso de animações. 1.3.3 W133
Complexidade 3: Banner com animação utilizando formato de saída SWF, sem limitações de dimensão
25 % de 1 PF a cada 10 segundos e animação do banner criado 1.4 APLICAÇÃO - ARTE PARA BANNER: Aplicação de arte e texto já existentes de um banner original para um novo banner, com dimensões diferentes do original.
1.4.1 W141
Complexidade 1: Reaplicação de conteúdo de banner já desenvolvido para novo formato. Utilizando formatos de saída GIF, JPG ou PNG. Não depende da posse dos arquivos fonte originais, desde que sejam consideradas as perdas de qualidade implicadas.
15% de 1 PF por banner estático e 5% de 1 PF por keyframe do banner, no caso de animações. 1.4.2 W142
Complexidade 2: Reaplicação de conteúdo de banner já desenvolvido para novo formato. Utilizando formato de saída SWF. Pressupõe a posse dos arquivos fonte originais, incluindo fontes tipográficas utilizadas
25% de 1 PF a cada 20 segundos de duração da animação do banner 1.4.3 W143
Complexidade 3: Reaplicação de conteúdo de banner já desenvolvido para novo formato. Utilizando formato de saída SWF, sem posse dos arquivos fonte. Considera possíveis perdas de qualidade implicadas
25% de 1 PF a cada 10 segundos de duração da animação do banner 1.5
CRIAÇÃO - ARTE PARA E-MAIL MARKETING: É tratado como e-mail marketing a arte criada para montagem e envio em massa para uma lista de emails pré-cadastrados e com autorização de envio. A não existência de imagens previamente escolhidas ou em que a qualidade das mesmas não possibilite sua aplicação, implica na execução de uma atividade do tipo PESQUISA e SELEÇÃO de IMAGENS, antes da realização desta atividade. Pressupõe a existência de conteúdo em texto previamente aprovado e revisado.
1.5.1 W151
Complexidade 1: Criação de e-mail marketing para programa governamental / sistema / atividade que já possua linha visual bem definida, incluindo logomarca
30% de 1 PF por e_mail marketing 1.5.2
W152
Complexidade 2: Criação de e-mail marketing para programa governamental / sistema / atividade que não possua linha visual definida, ou pretende-se a criação de linha visual diferenciada daquela já existente.
60% de 1 PF por e_mail marketing
1.6 CRIAÇÃO - ARTE DE LOGOMARCA / IDENTIDADE VISUAL: Criação/Reformulação de arte única e personalizada de logomarca em vetor. Formatos de entrega: Adobe Ilustrator e Corel Draw
1.6.1 W161
Complexidade 1: - Aplicação para web
- Reformulação de logomarca já existente OU - Aplicação para web
- Existe briefing e/ou conceito visual bem documentado
1,6 PF por arte de logomarca 1.6.2
W162
Complexidade 2: Nova logomarca, sem briefing ou conceito já definidos, com documentação incompleta. Aplicação limitada a mídia web
2,4 PF por arte de logomarca 1.6.3
W163
Complexidade 3: - Necessidade de criação de manual de aplicação
- Logomarca com possibilidades de utilização em múltiplas mídias
4 PF por arte de logomarca
1.7
CRIAÇÃO - INFOGRÁFICO para EXIBIÇÃO em TELA: Considera-se como infográfico para exibição em tela a arte caracterizada pela combinação de trabalhos de ilustração/tratamento de imagens com a exibição de informações organizadas e detalhadas, a fim de expor o funcionamento de um determinado mecanismo tangível (uma máquina, por exemplo), intangível (um programa governamental, por exemplo), ou exibição geográfica (mapas)
1.7.1
W171 Complexidade 1: Infográfico estático para aplicação web
2 PF por infográfico
1.7.2 W172
Complexidade 2: Infográfico combinado com keyframes de animação. Não inclui montagem. Concepção inicial: 2 PF por infográfico, mais 40% de 1 PF a cada keyframe da animação do infográfico 1.7.3 W173
Complexidade 3: Infográfico combinado com requisições dinâmicas de dados ao servidor 2.8 PF por infográfico, mais 40% de 1 PF a cada keyframe da animação do infográfico 1.8 CRIAÇÃO – LAYOUT: Criação de proposta de layout para hotsite, site ou portal. Número de propostas não acumulativo. Não considera implementação, somente proposta em formato
PSD e exportações como imagem a título de aprovação.
1.8.1 W181
Complexidade 1: Criação de hotsite - sítio promocional com objetivo de lançamento de informação relevante, programa governamental ou outras informações. Em geral, valoriza mais elementos de design do que a informação. Possui conteúdo limitado e sem atualização constante.
Em geral, possui entre 5 e 8 páginas internas estáticas.
1 página principal e 2 telas tipo de páginas internas: 2 PF por este conjunto Telas tipo adicionais - 20% de 1 PF para cada tela 1.8.2 W182
Complexidade 2: Criação de sítio - entra em produção de forma permanente ou permanece em período superior a 6 meses.
Pressupõe utilização de Gerenciadores de Conteúdo.
1 página principal e 2 telas tipo de páginas internas: 2,8 PF por este conjunto Telas tipo adicionais -25% de 1 PF para cada tela. 1.8.3 W183
Complexidade 3: Criação de layout para Portal de Informações. Características:
- Diagramação de conteúdo refinada, com duas ou mais colunas de contéudo para a página inicial
- 3 ou mais menus de navegação - 6 ou mais áreas funcionais
- Páginas internas que comportem outros sites
- Possibilidades de interação com usuário, planejadas desde o layout
- Páginas internas funcionando como capas de seção OU páginas internas com estrutura de navegação diferente da estrutura da página principal
1 página principal e 3 telas tipo de páginas internas: 4 PF por este conjunto. Telas tipo adicionais - 35% de 1 PF para cada tela. 1.9
ILUSTRAÇÃO: Trabalhos de ilustração que podem ser utilizados em diferentes mídias. Estilo da animação e mídia para a qual será voltada são elementos que definem a complexidade. Número de horas considera arte. O valor de horas é estimado.
1.9.1 W191
Complexidade 1: ilustração para mídia online ou offline, em estilo infantil,
cartoon ou caricatura, utilizando imagens em vetor. 2 PF por ilustração 1.9.2
W192
Complexidade 2: ilustração para mídia online em estilos realismo,
