PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Medição e Análise Orientação – Contagem de Pontos de Função Versão 2.7 ori_Contagem_Pontos_Funcao.odt Modelo 1.2 1 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Histórico de Revisões Data Versão Descrição 12/05/2014 2.7 Adequação ao novo padrão visual da DATAPREV. Dicas de contagens de sistemas analíticos Mauricio Koki Matsutani COAM 07/01/2014 2.6 Alteração na forma de cálculo de pontos de função de mudanças Mauricio Koki Matsutani COAM 22/11/2013 2.5 Alteração do texto, inclusão de exemplo e resumo no item 3. Alteração no layout do documento. Luiz Flávio Santos Ribeiro – COAM 20/08/2013 2.4 Alteração na Parte 3 - Contagem de Projetos de Sistemas Analíticos Luiz Flávio Santos Ribeiro COAM 08/08/2012 2.3 Alteração na figura do mapeamento BI/DW Bianca Thimóteo Rangel de Oliveira – COAM Cláudia Valéria Firmo Simões Gularte - DISN Michel El Chaer Saddock de Sá - DISP 04/07/2012 2.2 Padronização de acordo com PD-Dataprev Bianca Thimóteo Rangel de Oliveira – COAM Cláudia Valéria Firmo Simões Gularte - DISN Michel El Chaer Saddock de Sá - DISP 24/10/2011 2.1 Fusão do guia com o roteiro interno de contagem Carlos Alberto Pires de Castro – UDSC Edviges Mariza Campos de Magalhães - UDPB Maria do Socorro Bastos de Alencar Viana - UDCE Mauricio Koki Matsutani CGPS 17/08/2011 2.0 Adequação à release 4.3.1 do CPM e às orientações internas de contagem de pontos de função Carlos Alberto Pires de Castro – UDSC Edviges Mariza Campos de Magalhães - UDPB Mauricio Koki Matsutani – CGPS 29/11/2007 1.2 Adequação para os padrões PD-DATAPREV Carlos Alberto Pires de Castro – UDSC 22/11/2005 1.1 Inclusão de controle de versão e atualização para release 4.2.1 do CPM Carlos Alberto Pires de Castro – DEQS 01/12/2003 1.0 Documento Original David Samuel Abramowicz DEQS ori_Contagem_Pontos_Funcao.odt Modelo 1.2 Autor 2 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Índice 1.Processo de contagem de pontos de função ............................................................................... 7 1.1.Reunir a documentação disponível........................................................................................ 7 1.2Determinar o propósito da contagem ...................................................................................... 8 1.2.1Escopo da contagem ........................................................................................................... 8 1.2.2Fronteira da aplicação ......................................................................................................... 9 1.3Contar as funções de dados ................................................................................................... 9 1.3.1Arquivo lógico interno (ALI) ................................................................................................. 9 1.3.1.1Determinar a complexidade funcional ............................................................................. 11 1.3.1.1.1Registros lógicos ......................................................................................................... 11 1.3.1.1.2Tipos de dados ............................................................................................................ 13 1.3.2Arquivo de interface externa (AIE) ..................................................................................... 15 1.3.2.1Determinar a complexidade funcional ............................................................................. 16 1.3.2.1.1Registros lógicos ......................................................................................................... 16 1.3.2.1.2Tipos de dados ............................................................................................................ 16 1.4Contar as funções de transação ........................................................................................... 18 1.4.1Processo elementar........................................................................................................... 19 1.4.2Entrada externa (EE) ......................................................................................................... 19 1.4.2.1Determinar a complexidade funcional ............................................................................. 21 1.4.2.1.1Arquivos referenciados e mantidos .............................................................................. 21 1.4.2.1.2Tipos de dados referenciados e mantidos ................................................................... 22 1.4.3Saídas externas (SE) ........................................................................................................ 23 1.4.3.1Determinar a complexidade funcional ............................................................................. 25 1.4.3.1.1Arquivos referenciados ................................................................................................ 25 1.4.3.1.2Tipos de dados referenciados ...................................................................................... 26 1.4.4Consultas externas (CE) ................................................................................................... 27 1.4.4.1Determinar a complexidade funcional ............................................................................. 29 ori_Contagem_Pontos_Funcao.odt Modelo 1.2 3 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 1.4.4.1.1Arquivos referenciados ................................................................................................ 29 1.4.4.1.2Tipos de dados referenciados ...................................................................................... 29 1.5Sumário das lógicas de processamento usadas por EE, SE e CE........................................ 30 1.6Intenção primária da função de transação ............................................................................ 31 1.7Calcular o tamanho funcional ............................................................................................... 32 1.8Aplicação de fator de ajuste ................................................................................................. 32 1.9Documentar e relatar ............................................................................................................ 32 1.10Termos que criam confusão................................................................................................ 33 1.11Usando a APF para a verificação da completeza dos requisitos ......................................... 38 1.12Referências ........................................................................................................................ 40 2.Tratamento de itens não mensuráveis ....................................................................................... 41 2.1Finalidade............................................................................................................................. 41 2.2Diretrizes .............................................................................................................................. 41 2.2.1Controle de acesso corporativo ......................................................................................... 41 2.2.2Alterações de escopo de demandas.................................................................................. 41 2.2.3Demandas canceladas ou suspensas ............................................................................... 43 2.2.4Execução de demandas que usam desenvolvimento iterativo e incremental ..................... 43 2.2.5Serviços e componentes ................................................................................................... 44 2.2.6Conversão de dados ......................................................................................................... 44 2.2.7Múltiplas mídias ................................................................................................................. 45 2.2.8Atividades sem contagem de pontos de função................................................................. 46 3.Contagens de projetos de sistemas analíticos ........................................................................... 47 3.1Escopo e fronteira ................................................................................................................ 47 3.2Data staging area (DAS) ...................................................................................................... 47 3.3Entradas externas em projetos de data warehouse .............................................................. 48 3.4Consultas em projetos de DW .............................................................................................. 49 3.5Contagem de funções de dados em projetos de DW ............................................................ 50 3.6Funcionalidades de controle do DW ..................................................................................... 52 ori_Contagem_Pontos_Funcao.odt Modelo 1.2 4 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 3.7Demandas típicas em projetos de DW ................................................................................. 53 3.7.1Alteração de Dados de Dimensões Estáticas .................................................................... 53 3.7.2Massa de dados para homologação em DW ..................................................................... 53 3.8Demandas típicas de manutenção evolutiva em DW ............................................................ 53 3.8.1Alteração de campos em tabelas fato e dimensão ............................................................ 53 3.8.2Criação, configuração e disponibilização de um filtro ........................................................ 54 3.9Referências .......................................................................................................................... 54 ori_Contagem_Pontos_Funcao.odt Modelo 1.2 5 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Finalidade Este documento tem como objetivo descrever a técnica de Análise de Pontos de Função (APF) e sua aplicação na determinação do tamanho funcional dos serviços de desenvolvimento de software na DATAPREV e foi estruturado em três partes. A primeira parte é um guia de referência para a aplicação da APF no processo de desenvolvimento e manutenção de software na DATAPREV, apresentando um resumo dos métodos de contagem, de acordo com as diretrizes e orientações do Manual de Práticas de Contagem, versão 4.3.1 (CPM 4.3.1) publicado e mantido pelo International Function Point Users Group (IFPUG). A segunda parte apresenta um conjunto de atividades vivenciadas pelas equipes de desenvolvimento da DATAPREV não contempladas no CPM 4.3.1 ou no Roteiro de Métricas de Software do SISP. Em geral são considerados como itens não mensuráveis pelo CPM e desta forma, tem como objetivo definir como os mesmos são pontuados para fins de faturamento comercial junto aos clientes da DATAPREV. Na terceira parte são apresentados os procedimentos e orientações para a contagem de desenvolvimento de sistemas analíticos (business intelligence / data warehouse). O conteúdo gerado contou com a participação de analistas das áreas de serviços responsáveis pelo desenvolvimento de sistemas de informações gerenciais da DATAPREV. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 6 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 1. Processo de contagem de pontos de função Para se determinar o tamanho do software de acordo com a AFP devem ser seguidos os procedimentos de contagem composto pelas seis etapas mostradas a seguir. 1.1. Reunir a documentação disponível A documentação a ser utilizada na contagem deve ser aquela que descreve as funcionalidades entregues pelo software, assim como aquelas impactadas pelo desenvolvimento do software medido. A documentação adequada pode incluir requisitos, modelos de dados/objetos, diagramas de classe, diagramas de fluxo de dados, casos de uso, layout de telas e relatórios, manuais de usuários e outros artefatos de desenvolvimento de software. Eventuais falhas em documentação poderão ser sanadas com base na opinião de especialistas no objeto da contagem. Nesta etapa, o processo de definição de requisitos tem papel fundamental não somente para a aferição mais precisa do tamanho funcional, mas também com a delimitação correta do escopo do projeto a ser desenvolvido. No estágio inicial do processo de desenvolvimento a documentação disponível não invalida o processo de contagem, mas compromete a precisão das estimativas. Isto porque os requisitos são expressos como necessidades de negócios ou até mesmo como características de sistemas na visão do usuário e podem apresentar as seguintes características: Genéricos e ambíguos; ori_Contagem_Pontos_Funcao.odt Modelo 1.2 7 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Incompletos; Impossíveis de implementar; Altamente instáveis e sujeitos a mudanças. Os requisitos então devem ser desenvolvidos usando para tanto os artefatos e orientações definidos na disciplina Requisitos do PD-DATAPREV, caso ainda não tenha sido feito. Visão do usuário. O termo usuário deve ser entendido como qualquer pessoa ou coisa (por exemplo, outra aplicação, equipamento etc.) que interaja com a aplicação, recebendo ou enviando dados. A visão do usuário é o requisito funcional do usuário como percebido pelo mesmo. Representa uma descrição formal das necessidades dos negócios do usuário, na linguagem do usuário. Na seção 1.10 é apresentado um checklist que usa a APF para a completeza de requisitos. 1.2 Determinar o propósito da contagem Uma contagem de tamanho funcional não é um fim em si mesmo. É feita para fornecer uma resposta a um problema de negócio e é o problema de negócio que determina o propósito da contagem. O propósito: Determina o tipo de contagem e o escopo da contagem. Afeta o posicionamento da fronteira da aplicação entre o software sob análise e o software vizinho. Por exemplo, se o Módulo de Pessoal do Sistema de RH está para se substituído por um pacote de mercado. Neste caso, o módulo será considerado uma aplicação em separado do sistema corporativo, com uma fronteira própria. 1.2.1 Escopo da contagem O escopo define as funcionalidades que serão contadas de acordo com a visão do usuário. Um projeto pode envolver funcionalidades de uma ou mais aplicações, incluindo aquelas que possuem arquivos que apenas vão ser consultados. Portanto, se o escopo da contagem for um projeto, pode envolver mais que uma aplicação. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 8 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função O escopo da contagem pode ser uma parte de uma aplicação ou projeto, ou até mesmo algumas funcionalidades selecionadas. 1.2.2 Fronteira da aplicação A fronteira da aplicação que está sendo contada estabelece seus limites e das demais externas envolvidas na contagem. É uma interface conceitual entre o software sob estudo e seus usuários. A determinação das fronteiras das aplicações deve se baseada no ponto de vista dos usuários e nas funcionalidades dos negócios e não nas implementações tecnológicas. A fronteira: Define o que é externo à aplicação. Atua como uma ‘membrana’ através da qual os dados processados pelas transações (EE, SE e CE) passam para dentro e para fora da aplicação. 1.3 Envolve os ALI Contar as funções de dados Funções de dados representam as funcionalidades oferecidas ao usuário para satisfazer os requisitos de dados internos e externos. Fazem parte destas funções as seguintes funcionalidades: Arquivos Lógicos Internos (ALI) Arquivos de Interface Externa (AIE) 1.3.1 Arquivo lógico interno (ALI) É um grupo lógico de dados ou informações de controle sob o ponto de vista do usuário, cuja manutenção é feita internamente pela aplicação. Um ALI é uma entidade lógica e persistente, a respeito da qual, dados serão mantidos. Os ALI ori_Contagem_Pontos_Funcao.odt Modelo 1.2 9 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função baseiam-se em requisitos lógicos dos usuários e são independentes da implementação ou meios de armazenamento, tais como tabelas ou bancos de dados. Os dados devem ser agrupados logicamente com base na visão do usuário em um nível de detalhe que possa satisfazer um requisito específico da aplicação visualizando os arquivos lógicos. Um ALI é contado com base em uma avaliação do número de campos de dados não recursivos do usuário e do número de tipos de elementos de registros lógicos nele contidos. Para identificar um ALI, devem ser observadas as seguintes regras: Se o grupo de dados ou informações de controle é armazenado e mantido através de um ou mais processos elementares dentro da fronteira da aplicação a ser contada. Se o grupo de dados ou informações de controle mesmo sendo armazenado em um ALI de outra aplicação é mantido pela aplicação referente à contagem, para esta também será considerado um ALI. No caso a manutenção será feita (os dados serão gravados) diretamente, não sujeitos às regras de negócio da outra aplicação, mesmo utilizando-se artifícios técnicos (ex: componentes para gravação). Se o grupo de dados ou informações de controle é lógico e identificável pelo usuário. Exemplos de ALI: Dados de negócio ou de controle da aplicação mantidos e processados por suas transações. Segurança da aplicação. Dados de controle de acesso, incluindo passwords, mantidos dentro da aplicação. Dados de auditoria mantidos dentro da aplicação. Arquivos de erros mantidos dentro da aplicação. Dados de histórico mantidos dentro da aplicação. Não são exemplos de ALI: Arquivos temporários ou várias interações adicionais de um mesmo arquivo Arquivos de trabalho Arquivos de view os quais contém dados extraídos de outros arquivos Arquivos introduzidos devido à tecnologia (não são informações de negócio) Arquivos mantidos por outra aplicação e somente referenciados ori_Contagem_Pontos_Funcao.odt Modelo 1.2 10 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 1.3.1.1 Determinar a complexidade funcional A complexidade dos ALI é identificada por meio do número de registros lógicos e de tipos de dados. 1.3.1.1.1 Registros lógicos Registros lógicos são subgrupos de dados reconhecidos pelo usuário dentro de um ALI. Subgrupos são tipicamente representados em um DER/Modelo de dados como entidades e subtipos. A seguir serão ilustradas várias regras para identificação de registros lógicos, utilizando a representação e notação do Oracle Designer. a. Entidade associativa sem atributos próprios Estudante é ALI com um tipo de registro lógico. Curso é ALI com um tipo de registro lógico. Curso Estudante não é ALI nem é tipo de registro lógico de Estudante ou de Curso, pois não possui atributos próprios além das chaves. b. Entidade associativa dependente com atributos próprios Estudante é ALI com dois tipos de registros lógicos (Estudante e Curso Estudante) e Curso é outro ALI com dois tipos de registros lógicos (Curso e Curso Estudante). Curso Estudante não é ALI, pois sua existência depende da permanência do Estudante e do Curso, mas é registro lógico de ambos. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 11 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função c. Entidade associativa permanente, conforme definido pelo usuário, com atributos próprios. Aluno e Curso são ALI com um tipo de registro lógico cada um. Curso Estudante também é ALI, pois sua existência é permanente e não depende da permanência do Estudante e do Curso, conforme definição do usuário. d. Entidade fraca dependente Funcionário é ALI com dois tipos de registros lógicos. Plano Benefício Funcionário não é ALI e sim registro lógico de Funcionário, quando sua existência não é obrigatória (opcional) e quando existe, depende da existência ou permanência do Funcionário. e. Entidade atributiva obrigatória Produto é ALI com um tipo de registro lógico. Preço Produto não é ALI e nem registro lógico de Produto, quando a existência de pelo menos uma ocorrência é obrigatória, conforme definido pelo usuário. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 12 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função f. Entidade com subtipos Uma entidade subtipo é uma subdivisão de tipo de entidade. Um subtipo herda todos os atributos e relacionamentos da entidade pai, e pode ter atributos e relacionamentos adicionais próprios. As regras de modelagem de dados determinam que uma entidade possa ter qualquer número de grupos de subtipos independentes associados a ela, os quais podem ser opcionais ou obrigatórios. Cada subtipo pode ter apenas um pai. Na modelagem de dados, embora o pai e o subtipo sejam representados como entidades diferentes, eles são logicamente parte da mesma entidade. Funcionário é ALI com dois tipos de registros lógicos, um do funcionário Mestre e outro do funcionário Médico. Outra representação seria: 1.3.1.1.2 Tipos de dados São reconhecidos pelo usuário como únicos, não recursivos, campos/atributos incluindo atributos de chave estrangeira, mantidos no arquivo. Tipo de dados representa um segmento de um registro do ALI que tem significado único e é identificado pelo usuário. São os campos da tabela e deve-se contabilizar um tipo de dado para cada campo. Para identificar os tipos de dados, seguir as seguintes regras: Contar um tipo de dados para cada campo do arquivo reconhecido pelo usuário como único, não repetido, mantido e referenciados em um ALI, incluindo todos seus registros ori_Contagem_Pontos_Funcao.odt Modelo 1.2 13 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função lógicos. Quando duas aplicações mantêm e ou referenciam o mesmo ALI, mas cada uma mantém e referencia tipos de dados separados, conte apenas os tipos de dados utilizados em cada aplicação para avaliar a complexidade dos ALI. Contar um tipo de dado para cada campo requerido pelo usuário para estabelecer um relacionamento com outro ALI ou AIE que, no caso, é considerada chave estrangeira. Campos que aparecem mais de uma vez por causa da tecnologia de implementação contam-se como um único item. Dependendo da necessidade de negócio tipos de dados originários da subdivisão de um tipo de dados maior poderão ser contabilizados como tipos únicos. Campos repetitivos que são idênticos no formato existem para permitir múltiplas ocorrências de um valor de dado são contabilizados como um item. Arquivos de outras aplicações que sofrem manutenção direta pela aplicação analisada também serão considerados ALI (não serão AIE) e serão contados todos os tipos de dados dos registros lógicos que esta aplicação reconhece. Tabela para classificação de um ALI quanto à sua complexidade Tipos de dados relacionados Número de registros lógicos De 1 a 19 De 20 a 50 51 ou mais Apenas 1 Baixa Baixa Média De 2 a 5 Baixa Média Alta 6 ou mais Média Alta Alta Nas contagens do tipo projeto de desenvolvimento (sistemas novos), para todos os ALI deverão ser pontuadas as funcionalidades para a sua manutenção. Para as contagens do tipo projeto de melhoria/manutenção evolutiva, só podem ser pontuados os ALI novos. Os ALI que já existiam só serão pontuados se sofreram alterações com inclusão de novos registros lógicos, inclusão e/ou exclusão de campos, alterações de tamanhos de campos existentes ou das características de algum campo (por exemplo, campo que era alfanumérico passa a ser numérico). Em todos os casos os ALI devem ser pontuados integralmente, como se fossem novos, incluindo todos os registros lógicos, mesmo os que não tenham sido alterados. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 14 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Também nas contagens do tipo projeto de melhoria/manutenção evolutiva, verificar quais as funções de transação (EE, SE e CE) serão afetadas pelos ALI novos e alterados, conforme item acima. 1.3.2 Arquivo de interface externa (AIE) É um grupo lógico de dados ou informações de controle, referenciados na aplicação, cuja responsabilidade pela manutenção é de outra aplicação, ou seja, não é mantido pela aplicação que está sendo contada. O armazenamento e a manutenção são realizados fora da fronteira da aplicação. Um AIE de uma aplicação sempre será contado como um ALI na aplicação de origem. Um AIE é uma entidade lógica e persistente, que é requerida para referência ou validação pela aplicação referente à contagem. De forma semelhante a um ALI, um AIE é avaliado com base no número de campos de dados não recursivos do usuário e no número de tipos de elementos de registros lógicos. AIE também são partes dos requisitos dos usuários. Para identificar um AIE, devem ser observadas as seguintes regras: O grupo de dados ou informação de controle é lógico e identificável pelo usuário como sendo um requisito da aplicação O grupo de dados é referenciado pela aplicação a ser contada, mas pertence à outra aplicação fora da fronteira da aplicação. O grupo de dados não é mantido pela aplicação referente à contagem. O grupo de dados é mantido em um Arquivo Lógico Interno de outra aplicação Exemplos de AIE: Dados da aplicação extraídos e lidos de outra aplicação. Segurança da aplicação: Dados de controle de acesso, incluindo passwords, mantidos fora da aplicação (Por exemplo, logins corporativos). Dados de auditoria mantidos FORA da aplicação. Dados de help mantidos FORA da aplicação. Dados de parâmetros mantidos FORA da aplicação. Arquivos de erros mantidos FORA da aplicação. Dados de histórico, mantidos FORA da aplicação. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 15 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Não são exemplos de AIE: Arquivos temporários ou várias interações do mesmo arquivo. Arquivos de trabalho. Arquivos de sort (classificação). Arquivos de view os quais contém dados extraídos de outros arquivos externos previamente contados para display ou imprimir. Arquivos introduzidos devido à tecnologia. Dados recebidos de outras aplicações utilizados para adicionar, alterar ou remover dados de um ALI, sujeito às regras de negócio da aplicação (Estes dados externos são considerados dados de transação e, portanto, esta funcionalidade é considerada EE). Dados cuja manutenção é feita pela aplicação que está sendo avaliada, mas que são acessados e utilizados por outra aplicação. Dados processados e formatados para uso por outra aplicação (Esta funcionalidade deve ser considerada SE). 1.3.2.1 Determinar a complexidade funcional De forma semelhante a um ALI, um AIE é avaliado com base no número no número de registros lógicos e de campos de dados não recursivos do usuário, reconhecidos pela aplicação relativa à contagem. 1.3.2.1.1 Registros lógicos Registros lógicos são subgrupos de dados reconhecidos pelo usuário dentro de um AIE. Subgrupos são tipicamente representados em um DER / Modelo de Dados como entidades e Subtipos. Exemplo: Nota Fiscal e Itens da Nota fiscal. Para identificar o número de registros lógicos, seguir as mesmas regras exemplificadas para os ALI, baseando-se no DER / Modelo de Dados, considerando apenas os registros lógicos reconhecidos pela aplicação relativa à contagem. 1.3.2.1.2 Tipos de dados São reconhecidos pelo usuário como únicos, não recursivos, campos/atributos, incluindo atributos de chave estrangeira, contidos no AIE, reconhecidos pela aplicação relativa à contagem. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 16 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Tipo de dados representa um segmento de um registro do AIE que tem significado único e é identificado pelo usuário. São os campos da tabela e deve-se contabilizar um tipo de dado para cada campo reconhecido pela aplicação relativa à contagem. Para identificar os tipos de dados, seguir as seguintes regras: Contar um tipo de dados para cada campo do arquivo reconhecido pelo usuário e pela aplicação relativa à contagem como único, não repetido, referenciado em um AIE, incluindo todos seus registros lógicos reconhecidos pela aplicação relativa à contagem. Quando duas aplicações referenciam o mesmo AIE, mas cada uma referencia tipos de dados diferentes, conte apenas os tipos de dados utilizados em cada aplicação para avaliar a complexidade do AIE. Contar um tipo de dado para cada campo requerido pelo usuário para estabelecer um relacionamento com outro ALI ou AIE que, no caso, é considerada chave estrangeira. Campos que aparecem mais de uma vez por causa da tecnologia de implementação contam-se como um único item. Dependendo da necessidade de negócio tipos de dados originários da subdivisão de um tipo de dados maior poderão ser contabilizados como tipos únicos. Campos repetitivos que são idênticos no formato existem para permitir múltiplas ocorrências de um valor de dado são contabilizados como um item. Tabela para classificação de um AIE quanto à sua complexidade Tipos de dados referenciados Número de registros lógicos De 1 a 19 De 20 a 50 51 ou mais Apenas 1 Simples Simples Média De 2 a 5 Simples Média Alta 6 ou mais Média Alta Alta Os campos das tabelas referenciadas pelo sistema, as quais foram identificadas como AIE, só devem ser contados como tipos de dados se estiverem sendo referenciados pela aplicação que está sendo pontuada. Para contagens do tipo projeto de desenvolvimento de sistemas novos, todos os AIE deverão ser referenciados por pelo menos uma função de transação (EE, SE ori_Contagem_Pontos_Funcao.odt Modelo 1.2 17 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função e CE), pontuada. Para as contagens do tipo projeto de melhoria/manutenção evolutiva, só deverão ser pontuados os AIE novos, AIE que já existiam e sofreram alterações com inclusão de novos registro lógicos que passam a ser reconhecidos pela aplicação, com inclusão de novos campos reconhecidos pela aplicação e/ou exclusão de campos anteriormente reconhecidos, alterações de tamanhos de campos já existentes e alterações das características de algum(s) campo(s) (por exemplo, campo que era alfanumérico passa a ser numérico). Em todos os casos os AIE devem ser pontuados integralmente, como se fossem novos, incluindo todos os registros lógicos, mesmo os que não tenham sido alterados. Também nas contagens do tipo projeto de melhoria/manutenção evolutiva, verificar quais as funções de transação (EE, SE e CE) serão afetadas pelos AIE novos e alterados, conforme item acima. 1.4 Contar as funções de transação Funções de transação permitem o armazenamento de informações nos arquivos, bem como recuperá-los da própria ou de outras aplicações. Fazem parte destas funções as seguintes funcionalidades: Entradas Externas (EE). Saídas Externas (SE). Consultas Externas (CE). Funções de transação representam as funcionalidades providas para o usuário para o processamento dos dados da aplicação. As funções de transação são em geral dos seguintes tipos: Inclusão de registros Alteração de registros Exclusão de registros Consulta a registros Emissão de relatórios Envio de dados ori_Contagem_Pontos_Funcao.odt Modelo 1.2 18 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função As funções de transação têm como principal objetivo manter ALI e apresentar ou recuperar dados ou informações de controle dos ALI e AIE. 1.4.1 Processo elementar As funções de transação são consideradas a partir de um processo elementar, que é a menor unidade de atividade que tem significado para o usuário da aplicação e é auto contido, este processo deixa o negócio da aplicação que está sendo contada em um estágio consistente. 1.4.2 Entrada externa (EE) Entradas externas são transações (processos elementares) recebidas de fora da fronteira da aplicação que têm como objetivo manter os ALI e ou alterar o comportamento do sistema. Os dados destas aplicações podem ser recebidos de telas de entrada de dados ou diretamente de outros aplicativos. Estes dados podem ser informações de negócios ou informações de controle que direcionam o software para atender os requisitos de negócio do usuário. Uma entrada externa é contada com base no número de campos de dados do usuário envolvidos e na soma dos ALI e AIE participantes do processo. Um exemplo de EE seria “Incluir empregado” em um aplicativo de recursos humanos. Informações de controle podem ou não atualizar diretamente um ALI. Para identificar uma EE, devem ser observadas as seguintes regras: Identificar todos os processos elementares que recebem dados de fora da aplicação e que atualizam (inclusões, alterações e exclusões de dados) um ou mais ALI. As Entradas externas devem ser consideradas pelo usuário como uma função do negócio ou como um requisito da aplicação Identificar os processos que permitem a entrada de informações de controle dentro da fronteira da aplicação, com o objetivo de atender aos requisitos do usuário. As informações de controle podem ou não manter arquivos lógicos internos diretamente e devem ser recebidos de fora da fronteira da aplicação No mínimo, um ALI é mantido, se a entrada de dados pela fronteira não for informação de controle que altera o comportamento do sistema. São consideradas EE: Cada atividade de manutenção (adição, alteração e remoção) deve ser considerada como uma EE. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 19 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Dados de transações utilizados na manutenção dos arquivos lógicos internos, também podem ser alimentados por meio de arquivos (processamento batch). As EE duplicadas (realizam a mesma função do negócio) serão computadas individualmente se utilizarem meios distintos para sua realização (ex: online x batch). Não são consideradas EE: Dados de referência. Dados externos utilizados pela aplicação e que não são atualizados nos ALI. Parâmetros de entrada que direcionam a recuperação de dados em uma CE ou SE (Parte da entrada de uma CE ou SE). Telas de controle de acesso à aplicação que não atualizam os ALI. Tela que fornecem funcionalidade de seleção ou navegação e não atualizam ALI. Múltiplos métodos para executar uma mesma lógica de EE (deve ser contada uma única vez). Exemplos de EE: Telas de entrada de dados que mantém um ALI ou fornecem informação de controle. Mensagem de outras aplicações que requerem processamento de manutenção de ALI. Arquivos de transação de outras aplicações, os quais requerem processamento separado e único. Entrada batch que mantém um ALI ou fornecem informação de controle. Dados físicos que iniciam processamento de manutenção de ALI (ex: hora) Manutenção de qualquer ALI, incluindo help, qualquer arquivo de mensagem, parâmetros etc. Funções do usuário que iniciam processamento de informações de controle ou entrada de dados (EE disparada por outra funcionalidade qualquer). Arquivos de dados de uma aplicação anterior mantidos, os quais devem ser processados por um esforço de conversão para dentro de um novo ALI desenvolvido quando ocorre migração de dados como parte de um projeto de desenvolvimento ou melhoria funcional. Isto seria incluído dentro da contagem do projeto, mas fora da contagem da aplicação. Não são exemplos de EE: Dados referenciados, armazenados em outra aplicação, os quais são lidos pela aplicação, mas não são usados para manter um ALI na aplicação que está sendo dimensionada ori_Contagem_Pontos_Funcao.odt Modelo 1.2 20 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função (consultas de AIE). Os lados de entrada de SE ou CE. Telas de menu usadas para navegação ou seleção, as quais não mantém um ALI. Telas de login que facilitam a entrada do usuário dentro da aplicação, mas não mantém um ALI. Dados de telas de refresh ou cancel. Respostas para mensagens que pedem uma confirmação do usuário para confirmar uma transação. Elas fazem parte do próprio processo elementar da transação. Múltiplos métodos de execução da mesma lógica, por exemplo, a mesma funcionalidade de EE chamada de múltiplas telas. Devem ser contadas apenas uma vez. Dados passados entre on-line e batch dentro da mesma aplicação. Estes não cruzam a fronteira da aplicação. Dados passados entre clientes e servidor dentro da mesma aplicação. Estes não cruzam a fronteira da aplicação. 1.4.2.1 Determinar a complexidade funcional Identificar do número de arquivos referenciados e mantidos Identificar do número de tipos de dados referenciados e mantidos 1.4.2.1.1 Arquivos referenciados e mantidos O número de arquivos é o somatório do número de ALI e de AIE atualizados e/ou consultados na EE. Regras para contagem de arquivos referenciados: Conte apenas um arquivo referenciado para cada ALI, seja ele apenas lido ou apenas lido, ou ambos os casos. Conte apenas um arquivo referenciado para cada AIE lido. Tanto ALI como AIE devem ser contados como apenas um arquivo, independente de quantos registros lógicos possui. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 21 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 1.4.2.1.2 Tipos de dados referenciados e mantidos O número de tipos de dados referenciados é o total de campos identificados pelo usuário que cruzam a fronteira da aplicação, seja para atualizar um ALI ou apenas para serem exibidos como referência. Ex: Normalmente quando um ALI é atualizado não só as informações originais e possíveis de atualização são exibidas previamente, mas várias outras também o são como referência. Neste caso devem-se contar todas as informações, não só as alteradas. Regras para contagem de tipos de dados (elementos/campos/atributos): Cada tipo de dados atualizado em um ALI deve ser contabilizado dentro dos seguintes critérios: Os tipos de dados de acordo com a visão do usuário. Contar os tipos de dados, que aparecem mais de uma vez em um arquivo por causa da tecnologia ou técnica de implementação apenas uma vez. Campos repetitivos que são idênticos no formato e existem para permitir múltiplas ocorrências de um determinado tipo de dado, serão contabilizados uma única vez. Os tipos de dados originários da subdivisão de um tipo de dado maior que é o reconhecido pelo usuário não devem ser contabilizados (contabiliza-se apenas o tipo de dado maior). Ex: Endereço completo. Caso rua, bairro, cidade etc. tenham significado de negócio, o campo endereço deve ser subdividido. Tipos de dados adicionais devem ser contabilizados para uma EE nos seguintes casos: Linhas de comandos, teclas de funções ou campos que fornecem ao usuário a capacidade de especificar a AÇÃO a ser tomada pela EE (Contabilizar apenas um item adicional no caso de existência desta capacidade não importando quantos botões existam na tela). Campos não informados pelo usuário, mas que são gerados automaticamente pela aplicação e atualizam um ALI. Mensagem de erro e/ou confirmação associadas a um processo de validação de dados de EE deve ser contabilizados como um tipo de dados. Tabela para classificação de um EE quanto à sua complexidade De 1 a 4 De 5 a 15 16 ou mais Apenas 1 Baixa Baixa Média 2 Baixa Média Alta ori_Contagem_Pontos_Funcao.odt Modelo 1.2 Tipos de dados referenciados Número de arquivos referenciados 22 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 3 ou mais Média Alta Alta 1.4.3 Saídas externas (SE) É um processo elementar da aplicação, o qual gera dados ou informações de controle que saem da fronteira da aplicação. Ou seja, a SE envia dados para fora da fronteira da aplicação. Representam as atividades da aplicação que têm como resultado a saída de dados. SE são as transações que geram dados e os enviam para fora da fronteira da aplicação. Têm que apresentar informação para o usuário através de processamento lógico diferente ou adicional à recuperação de dados ou informação de controle dos arquivos. Ex: dados transferidos para outra aplicação (dados contidos em um ALI e ou AIE, que são formatados e processados para uso em outra aplicação); relatórios (se suas saídas usam processamento ou cálculos distintos); dados derivados (dados que resultam de cálculos, fórmulas, ou outras operações sobre dados originais); formatos gráficos. Uma SE é um processo lógico do negócio que gera dados para um usuário ou para outro aplicativo externo ao software. Exemplos típicos de SE incluem relatórios de usuários, disquetes ou fitas para a DATAPREV. As saídas externas também fazem parte dos requisitos lógicos dos usuários. Para identificar uma SE, devem ser observadas as seguintes regras: Identificar processos que enviam dados para fora da fronteira da aplicação. Identificar processos que enviam informações de controle para fora da fronteira da aplicação. Devem ser identificadas pelo usuário como uma função do negócio ou como um requisito da aplicação. Verificar o processamento lógico do processo elementar de acordo com as seguintes regras: Se contem no mínimo, uma fórmula matemática ou cálculo. Se cria dados derivados. Se mantém no mínimo, um ALI. Se altera o comportamento do sistema. Processamento lógico deve ser único e diferente de outras saídas externas dentro da aplicação. Como por exemplo, relatórios com totais podem estar disponíveis com classificação por mês, produto, e departamento. Se os campos do relatório são os ori_Contagem_Pontos_Funcao.odt Modelo 1.2 23 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função mesmos (mesmo que estes sejam mostrados em formatos diferentes), os totais são por colunas, e os processamentos dos cálculos não são únicos, contaríamos uma SE para cada processamento. Três SE seriam contadas se os totais são sumarizados diferentemente e os cálculos são únicos para cada tipo de sort. Os elementos de dados identificados são diferentes de outras SE da aplicação. Note que estes são elementos de dados diferentes e não dados diferentes nos mesmos campos. Dois relatórios produzidos separadamente nos níveis de detalhes e sumários seriam contados como duas SE, devido à lógica de processamento e os cálculos serem únicos. Satisfeitas as condições anteriores, são consideradas SE: Dados transferidos para outra aplicação. Dados armazenados nos ALI, que são processados e formatados para o uso por outra aplicação. Relatórios. Cada relatório produzido pela aplicação é considerado uma SE. Relatórios Duplicados. Relatórios idênticos, produzidos em diferentes meios, para atender necessidades específicas do usuário, devem ser considerados SE distintas desde que a multiplicidade de meios seja provida pela aplicação. Relatórios on-line. Saída de dados on-line, que não seja parte de saída de uma CE, caracteriza-se como uma SE. Exemplos de SE: Relatórios que requerem o uso de algoritmos ou cálculos. Por exemplo, relatórios de vendas semanais. Transferências de dados, arquivos e/ou mensagens enviadas para outras aplicações. Arquivos de dados múltiplos, cada produzido através de um processo elementar separado e distinto, enviado para outra aplicação. Um relatório de conversão que mostra os resultados do esforço de conversão quando a migração de dados faz parte do projeto de desenvolvimento ou de melhoria funcional, isto seria incluído como parte da contagem do projeto, mas não como parte da contagem da aplicação. Informações derivadas e calculadas mostradas na tela. Gráficos exibidos (gráficos de barra, pie graph etc.). Etiquetas de código de barras. Emissão de cheques. Relatórios duplicados produzidos em meios distintos. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 24 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Não são exemplos de SE: Relatórios com valores de dados diferentes, mas com a mesma lógica (contados apenas uma vez) Ex: Relatório de Departamentos. Help (contato como CE). Logoff; Múltiplos métodos de execução do mesmo processo de saída (contados apenas uma vez). Mensagens de confirmação de que os dados foram processados. Mensagens que pedem uma confirmação do usuário para exclusão ou qualquer outra transação. Dados idênticos enviados para mais de uma aplicação (contados apenas uma vez). Relatórios genéricos controlados pelo usuário através de uma linguagem SQL ou Focus. Dados passados entre batch e on-line dentro da mesma aplicação. Estes não cruzam a fronteira da aplicação. Dados passados entre cliente e servidor dentro da mesma aplicação. Estes não cruzam a fronteira da aplicação. Dados de referencia que são lidos por outra aplicação dos dados armazenados pela aplicação sendo contada (os dados não são processados como uma saída pela aplicação sendo contada). 1.4.3.1 Determinar a complexidade funcional A complexidade da SE é verificada através do número de arquivos e elementos de dados referenciados. Deve-se contar um arquivo referenciado para cada ALI mantido ou lido ou um AIE lido durante o processamento da SE. Identificar o número de arquivos referenciados Identificar o número de tipos de dados referenciado 1.4.3.1.1 Arquivos referenciados O número de arquivos referenciados é o somatório do número de ALI e de AIE lidos ou referenciados pela SE. Conte um arquivo um arquivo referenciado para cada ALI ou AIE, lido durante o processamento da SE. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 25 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 1.4.3.1.2 Tipos de dados referenciados O número de tipos de dados referenciados é o total de campos identificados pelo usuário que aparecem na SE (elementos/campos/atributos). Cada tipo de dados referenciado deve ser contabilizado dentro dos seguintes critérios: Os tipos de dados originários da subdivisão de um tipo de dado maior não devem ser contabilizados (contabiliza-se apenas o tipo de dado maior). Os tipos de dados que sejam exibidos de forma repetitiva em mais de um campo da SE serão contabilizados apenas uma vez. Campos repetitivos que são idênticos no formato e existem para permitir múltiplas ocorrências de um determinado tipo de dado, serão contabilizados uma única vez. Contar um tipo de dado quando a aplicação enviar mensagens de resposta para fora da fronteira, indicar um erro ocorrido durante o processamento, confirmar o processamento completo ou verificar se o processamento deva continuar. Contar um tipo de dado para cada campo reconhecido pelo usuário, não repetido, que entre pela fronteira da aplicação e seja requerido para especificar quando, qual e/ou como o dado será recuperado ou gerado pelo processo elementar ou que saia da fronteira da aplicação. Se um tipo de dado entra e sai pela fronteira da aplicação, contá-lo apenas uma vez. Contar um tipo de dado para a habilidade de especificar uma ação a ser tomada, quando existem múltiplos métodos para chamar o mesmo processo lógico. Não contar os campos que são recuperados ou derivados pelo sistema e armazenados em um ALI durante o processo elementar se esses campos não cruzam a fronteira da aplicação. Liberais não são contados como tipos de dados. Exemplo: cabeçalho, rodapé. Variáveis, data, hora, controles de paginação ou selos gerados pelo sistema não deverão ser contabilizados como tipos de dados. Tabela para classificação de um SE quanto à sua complexidade: De 1 a 5 De 6 a 19 20 ou mais Apenas1 Baixa Baixa Média De 2 a 3 Baixa Média Alta 4 ou mais Média Alta Alta ori_Contagem_Pontos_Funcao.odt Modelo 1.2 Tipos de dados referenciados Número de arquivos referenciados 26 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 1.4.4 Consultas externas (CE) Uma CE é um processo elementar da aplicação que envia dados ou informações de controle para fora da fronteira da aplicação a partir da recuperação de dados armazenados em ALI ou AIE. O objetivo principal é apresentar dados para o usuário, sem que ocorra atualização de ALI, cálculos ou procedimentos para obtenção de dados derivados, nem mudança no comportamento do sistema. Para identificar uma CE, devem ser observadas as seguintes regras: Recupera dados ou informação de controle de um ALI ou AIE. Não contém fórmulas matemáticas ou cálculos. Não cria dados derivados. Não mantém ALI. Não altera o comportamento do sistema. Exemplos de CE: Dados transacionais que são recuperados, de um ou mais ALI e/ou AIE, e apresentados baseados em um critério de entrada. Funções do usuário como views, browses. Recuperação de e-mail de uma mailbox. Listas que o usuário clica ou aponta em uma tela para recuperação de dados. Consultas implícitas: Telas de alteração ou remoção de dados, que mostram o que será alterado ou removido antes de sua ação efetiva, devem ser consideradas como CE. Caso as telas de alteração e remoção sejam idênticas, considerar apenas uma CE e, no caso destas serem iguais à tela de consulta propriamente dita deve-se considerar apenas a função de consulta como uma CE. Telas de help. Telas contendo texto de apoio ao uso da aplicação, que possam ser acessadas ou exibidas por meio de diferentes técnicas de seleção, ou a partir de diferentes locais da aplicação, devem ser contadas uma única vez, por nível (sistema, tela e campo). As telas de help são identificadas como CE. Se o sistema possuir help serão contadas no máximo 3 CE (1 por nível). Pela técnica APF, o sistema pode ter três níveis de help, a saber: ori_Contagem_Pontos_Funcao.odt Modelo 1.2 27 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função • Help do sistema. Se a aplicação possuir a função de help em nível de sistema, a mesma será pontuada como uma CE Simples. • Help de tela. Também chamado de full screen help, trata-se de um recurso de ajuda que mostra um texto de help relacionado à tela da aplicação, deve ser considerado como uma CE Simples, independentemente do número de telas de texto de help apresentados. • Help de campos (itens da tela). Também chamado de field sensitive help, trata-se de um recurso de ajuda dependente da localização do cursor, ou de algum outro método de identificação, para exibição de documentação específica para aquele tipo de dado. Devem ser consideradas como uma CE, computando-se um tipo de dado para a parte da entrada para cada campo sensível a esta função. Normalmente é pontuada como CE Média, pois, provavelmente existirão mais de 16 tipos de dados distintos afetados por este nível de help. Não são exemplos de CE: Múltiplos métodos para executar uma mesma lógica de CE. Por exemplo, duas teclas de ação, as quais executam a mesma função ou a mesma transação em múltiplas telas (devem ser contadas apenas uma vez). Consultas que podem ser acessadas de múltiplas telas de uma aplicação (conte uma vez). Consultas com dados que não são recuperados de dados mantidos, por exemplos: dados codificados. Consultas com reordenação de um conjunto de dados sem qualquer processamento lógico (conte uma vez). Respostas a mensagens que requerem confirmação do usuário. Mensagens de erros. Dados que são passados entre cliente e servidor em uma mesma aplicação, não cruzam a fronteira. Dados passados entre on-line e batch na mesma aplicação, não cruzam a fronteira. Mensagens de erros ou de confirmação associadas às EE, SE ou CE. Subsistema de ajuda (help). Recurso de ajuda que pode ser manuseado ou acessado independentemente da aplicação. Telas de controle de acesso à aplicação e que não fornecem funcionalidade de segurança. Telas de menu que fornecem apenas funcionalidade de seleção ou navegação entre as ori_Contagem_Pontos_Funcao.odt Modelo 1.2 28 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função funções da aplicação e não recuperam dados mantidos. Dados derivados: Dados derivados de dados contidos nos ALI e/ou nos AIE devem ser tratados como uma SE. 1.4.4.1 Determinar a complexidade funcional Identificar do número de arquivos referenciados Identificar do número de tipos de dados referenciados 1.4.4.1.1 Arquivos referenciados O número de arquivos referenciados é o somatório de todos os ALI e AIE acessados. 1.4.4.1.2 Tipos de dados referenciados O número de tipos de dados referenciados é o total de campos identificados pelo usuário que aparecem na CE. Estes devem ser contabilizados com as seguintes exceções: Os tipos de dados originários da subdivisão de um tipo de dado maior não devem ser contabilizados (contabiliza-se apenas o tipo de dado maior). Os tipos de dados que sejam exibidos de forma repetitiva em mais de um campo da CE serão contabilizados apenas uma vez. Campos repetitivos que são idênticos no formato e existem para permitir múltiplas ocorrências de um determinado tipo de dado serão contabilizados uma única vez; Literais não são contados como tipos de dados. Data, hora e controles de paginação não deverão ser contabilizados como tipos de dados; Devem ser contabilizados como tipos de dado todos os campos de sumário ou de total que aparecem na CE. Conte um único tipo de dado para cobrir todas as respostas do sistema que indicam um erro ocorrido durante o processamento ou confirmação que o processamento está completo. Conte um único tipo de dado para a capacidade de especificar qual é a consulta externa a ser executada. Conte um único tipo de dado para linhas de comando ou teclas (PF) de função / ação que fornecem a capacidade de especificar a ação a ser tomada. Não conte este por comando ou por tecla PF. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 29 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Tabela para classificação de uma SE quanto à sua complexidade Tipos de dados referenciados 1.5 Número de arquivos referenciados De 1 a 5 De 6 a 19 20 ou mais Apenas1 Baixa Baixa Média De 2 a 3 Baixa Média Alta 4 ou mais Média Alta Alta Sumário das lógicas de processamento usadas por EE, SE e CE Tipo de Lógica de Processamento EE SE CE Validações Pode Pode Pode Cálculos e fórmulas matemáticas Pode Deve* não Conversão em valores equivalentes Pode Pode Pode Filtro e seleção de dados com base em critérios específicos na comparação de vários conjuntos de dados Pode Pode Pode Análise de condições para que se determine quais se aplicam Pode Pode Pode Atualização de pelo menos um ALI Deve* Deve* não Referência pelo menos um ALI ou AIE Pode Pode Deve Recuperação de dados ou informações de controle Pode Pode Deve Criação de dados derivados Pode Deve* Não Alteração do comportamento do sistema Deve* Deve* Não Preparação e apresentação de informação para fora da fronteira Pode Deve Deve Capacidade de aceitar dados ou informação de controle que entra pela fronteira Deve Pode Pode Mudança da ordenação ou organização de um conjunto de dados Pode Pode Pode Legenda Deve A transação deve obrigatoriamente executar este tipo de lógica de processamento Deve* A transação deve executar pelo menos uma das lógicas de processamento classificadas como deve* Pode A transação pode executar este tipo de lógica de processamento, mas não é obrigatório Não A transação não pode executar este tipo de lógica de processamento ori_Contagem_Pontos_Funcao.odt Modelo 1.2 30 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 1.6 Intenção primária da função de transação Função EE SE CE Alterar o comportamento da aplicação IP F N/A Manter um ou mais ALI IP F N/A Apresentar informações ao usuário F IP IP Legenda IP Intenção primária do tipo de transação F É uma função do tipo de função de transação, mas não é a intenção primária e está presente algumas vezes N/A A função não é permitida para o tipo de função de transação Para contagens do tipo projeto de desenvolvimento de sistemas novos, todos os arquivos referenciados deverão constar na lista de ALI e AIE pontuados. Para contagens do tipo projeto de melhoria/manutenção evolutiva, os arquivos referenciados que já existiam e não sofreram mudanças não deverão constar na lista de ALI e AIE pontuados, apenas os arquivos novos e modificados. Arquivos referenciados serão sempre um para cada, não importando quantos registros lógicos tenham, ou seja, registro lógico não é arquivo referenciado, e sim sua entidade a que pertence. Para as contagens do tipo projeto de melhoria/manutenção evolutiva, só deverão ser pontuadas as funcionalidades novas, as funcionalidades que já existiam e sofreram alterações com inclusão ou exclusão de tipos de dados, alterações de tamanhos ou características de tipos de dados existentes e modificações nas regras de negócio da transação (ex: alterar uma lógica, incluir uma nova consistência, novo processo de seleção, novo arquivo referenciado etc.). Em todos os casos as funcionalidades devem ser pontuadas integralmente, como se fossem novas, inclusive arquivos referenciados, mesmo que permaneçam os mesmos. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 31 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 1.7 Calcular o tamanho funcional Após identificar as funções de dados e transacionais, multiplicar o total de ALI, AIE, EE, SE e CE pelos respectivos pesos de suas complexidades para determinar o valor de PF. De acordo com a complexidade, cada uma das funções de dados e transacionais dentro da respectiva complexidade, contribui com um determinado número de PF. Este trabalho é apoiado pelo artefato tpl_Contagem_PF_nome_<roteiro>.ods, disponível na disciplina Medição e Análise do PD-DATAPREV. <roteiro> identifica o roteiro de métricas complementar ao CPM 4.3.1 e varia de acordo com o cliente e contrato, podendo assumir os seguintes valores: SISP 10: Roteiro de Métricas de Software do SISP, versão 1.0 SISP 20: Roteiro de Métricas de Software do SISP, versão 2.0 RFB: Roteiro de Métricas de Software RFB 4.7 e SIGEPE: usado no desenvolvimento do SIGEPE pelo Consórcio SERPRO x DATAPREV. 1.8 Aplicação de fator de ajuste O fator de ajuste a ser usado é 1, ou seja, serão considerados pontos de função não ajustados1 (pontos de função brutos). 1.9 Documentar e relatar A documentação da contagem de pontos de função deve ser feita diretamente na própria planilha de contagem de pontos de função, especificamente nas abas Apresentação e Sumário. A documentação da contagem de pontos de função também deve incluir a identificação da documentação de origem na qual a contagem foi baseada e citada na coluna Fonte da planilha de contagem. 1 Acórdão TCU 2348/2009 ori_Contagem_Pontos_Funcao.odt Modelo 1.2 32 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 1.10 Termos que criam confusão Os termos a seguir são usados tanto na metodologia de pontos de função, quanto na tecnologia da informação. A confusão surge porque sua utilização genérica na tecnologia da informação frequentemente possui um significado diferente daquele utilizado na contagem de PF. Lógico. O termo "lógico" em tecnologia da informação é normalmente associado a layouts de bases de dados ou modelos lógicos de dados. Contudo, em muitas situações, algumas considerações físicas se insinuam até nos mais lógicos dos modelos de dados. Quando o termo "lógico" é utilizado na contagem de pontos de função, refere-se aos requisitos ‘conceituais’ ou ‘funcionais’ dos usuários, excluindo a implementação física ou os requisitos de projeto. Os requisitos lógicos dos usuários são aqueles que um usuário experiente no assunto identificaria como requisitos do software. Os requisitos lógicos ou funcionais dos usuários descrevem o que o software deve fazer, sem dizer como o software executará as funções. Os pontos de função medem o tamanho desses requisitos funcionais dos usuários, apenas. Considerações sobre o projeto e a qualidade, embora importantes para a construção do software, não são parte do tamanho lógico do software, não sendo, portanto, contados em pontos de função. Esta situação é semelhante à medição do tamanho de uma casa através do número de metros quadrados contidos em uma planta baixa, que não muda independentemente de como a casa venha a ser construída. Na mensuração funcional de tamanho, a contagem de pontos de função reflete apenas o que o aplicativo deve fazer e não a forma como irá fazê-lo. A confusão pode surgir quando a palavra "lógico" é utilizada em conjunto com palavras que sugerem um conteúdo físico, tais como tela ou relatório. Uma "tela lógica" pode consistir de uma ou mais telas físicas de entrada de dados conectadas, dando suporte a uma única função. Todas as contagens de pontos de função são efetuadas a partir da perspectiva lógica do usuário, e os contadores iniciantes precisam pensar "logicamente" ao contar pontos de função. Usuário. O termo usuário, conforme tipicamente utilizado em tecnologia da informação, refere-se a uma pessoa "física" que interage com ou que utiliza o software. Na terminologia de pontos de função, a palavra "usuário" tem um significado mais amplo. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 33 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função O CPM define usuário como: A pessoa ou organização que usa o aplicativo sendo medido. Isto inclui o autor dos requisitos, usuários finais, usuários gerenciais, auditores e operadores. Os seres humanos que usam o aplicativo. Os requisitos funcionais de usuários podem incluir ‘usuários’ tais como pessoas, aplicativos e participantes externos - resumindo, qualquer coisa que solicite ou forneça dados para o software. Os requisitos funcionais de "usuários" incluem os processos lógicos de negócio de "usuários" tais como: outros aplicativos, pessoas físicas, organismos governamentais externos, animais (se eles puderem disparar um processo no aplicativo, como em sistemas de segurança) e coisas (como a pressão em um sistema de tubulação), etc. Essa diferença no significado pode fazer com que algumas funções contáveis sejam esquecidas pelos desenvolvedores, por não parecem requisitos definidos por ou para um "usuário físico". Aplicativo (sistema). Os termos 'aplicativo' e 'sistema' são frequentemente utilizados de forma intercambiável em processamento de dados e ligados à segmentação física do software. Seguem-se alguns exemplos de como os aplicativos ou sistemas podem ser divididos pelos desenvolvedores: a. Com base nas funções executadas em modo batch ou on-line. Às vezes, cada modalidade de implementação física de um único conjunto de funções cooperativas pode considerada um “sistema” separado pelos desenvolvedores: por exemplo, o sistema batch de contas a receber e o sistema on-line de contas a receber; b. Com base na plataforma física na qual um subconjunto das funções (ou subfunções) reside: por exemplo, o sistema de folha de pagamento mainframe e o sistema de folha de pagamento PC; c. Com base nos pacotes físicos que compreendem um conjunto de funções: por exemplo, o aplicativo de banco de dados Access, o aplicativo de relatórios InfoMaker e o aplicativo de entrada de dados. Há muitas outras formas semelhantes. O termo 'aplicativo', no contexto da contagem de pontos de função, está definido no Manual de Práticas de Contagem como: ori_Contagem_Pontos_Funcao.odt Modelo 1.2 34 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função “Uma coleção coesa de procedimentos e dados automatizados, suportando um objetivo do negócio. Consiste de um ou mais componentes, módulos ou subsistemas. É frequentemente utilizado como sinônimo para sistema”. Isto quer dizer que um “aplicativo” em termos de pontos de função é um agrupamento de funções de usuário inter-relacionadas, independentes de plataforma, modo de operação e subdivisão física em termos de TI. Nos exemplos acima, os “sistemas” batch e on-line seriam um “aplicativo” para efeito de contagem de pontos de função. O segundo exemplo resultaria em um "aplicativo" de pagamentos, da perspectiva do usuário (o qual por acaso está implementado em múltiplas plataformas). O terceiro exemplo provavelmente também seria um aplicativo, com vários componentes empacotados utilizados como parte de como o software foi produzido. Estas diferenças na definição e utilização da palavra 'aplicativo’ podem resultar em excesso de contagem (por exemplo, se um aplicativo teve seus PF contados como dois, como no caso de uma contagem on-line e outra batch, ao invés de corretamente como um único aplicativo), ou sub-contagem (por exemplo, se todos os aplicativos em um computador forem contados como um só.) É importante lembrar que, na contagem de pontos de função, um aplicativo representa a forma segundo a qual um usuário vê logicamente o sistema, enquanto na tecnologia da informação um aplicativo geralmente representa como o sistema é fisicamente implementado. Projeto. O termo ‘projeto’ é outro termo que frequentemente possui significado diferente na TI e em pontos de função. Quando utilizado no desenvolvimento de sistemas, ‘projeto’ pode receber diversos significados, mesmo em uma única organização. Pode ser usado para descrever: a. O escopo de trabalho que inclui a melhoria ou o desenvolvimento de vários aplicativos de software. b. O escopo de trabalho incluindo consertos / manutenção de funções existentes, além da melhoria de outras funções em um único aplicativo de software. c. Acertos no software em operação ou upgrades no software existente. d. Qualquer combinação dos itens acima. Na contagem de pontos de função, a palavra "projeto" refere-se ao produto do trabalho associado ao desenvolvimento ou melhoria de um único aplicativo (sistema). As definições de projeto de desenvolvimento e de melhoria constantes do glossário do CPM (Manual de Práticas de Contagem) mostram: ori_Contagem_Pontos_Funcao.odt Modelo 1.2 35 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função a. Desenvolvimento: A especificação, construção, teste e entrega de um novo sis- tema de informações. b. Melhoria: A modificação de um aplicativo existente. O que isto significa para os contadores de PF e desenvolvedores é que ‘projeto’ em termos de TI pode de fato conter diversos ‘projetos de pontos de função’ e, dessa forma, necessitar de diversas contagens de PF. Por exemplo, se um ‘projeto’ de TI incluir o desenvolvimento de um novo “Sistema de Faturamento Hospitalar”, bem como melhorias em um “Sistema de Admissão Hospitalar” existente, o tamanho total do projeto de TI envolveria dois “projetos” de contagem de pontos de função: a. Uma contagem de PF de desenvolvimento do novo Sistema de Faturamento Hospitalar. b. Uma contagem de PF de melhorias no Sistema de Admissão Hospitalar. c. Também é útil notar que um projeto de melhoria, cujo tamanho total compreenda a funcionalidade incluída, alterada e eliminada, modificará o tamanho do aplicativo pela quantidade de funcionalidade acrescentada, sem considerar aquela excluída. Uma vez que seja compreendida esta diferença no uso do termo 'projeto’, resta apenas comunicar as contagens de PF no contexto correto. Arquivo. O termo ‘arquivo’, conforme usado pelos desenvolvedores de sistemas, geralmente lembra o processamento de mainframe, orientado a transações, sendo o termo usado como sinônimo de dataset. Termos relacionados, tais como 'arquivos de pesquisa’, 'arquivos de saída’, 'arquivos batch', 'arquivos Excel' e 'arquivos de transação' ainda são muito usados hoje em dia. Na contagem de pontos de função, o termo 'arquivo' é utilizado para representar um grupamento lógico de dados requerido pelos usuários. O CPM define arquivo como: “Para os tipos de funções de dados, um grupo de dados logicamente relacionados, não a implementação física desse grupo de dados.”. A confusão surge porque um ALI e um AIE em termos de pontos de função referem-se a uma entidade persistente de dados, não um arquivo físico ou dataset. A seguir, alguns exemplos de arquivos físicos / datasets em TI que não seriam arquivos (entidades) em pontos de função: a. Um dataset de entrada poderia conter transações que causariam atualizações em cadastros no aplicativo. (Em PF isto seria contado como uma ou mais Entradas ori_Contagem_Pontos_Funcao.odt Modelo 1.2 36 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Externas, uma vez que é esse o requisito lógico do usuário. O local físico de armazenamento desses processos por acaso é um dataset). b. Um arquivo de saída poderia conter a versão eletrônica de diversos relatórios ou grupos de dados (por exemplo, vários formulários diferentes de imposto de renda poderiam estar todos gravados em uma única fita física de saída). Em PF isto seria contado com várias Saídas Externas (uma para cada um dos requisitos funcionais distintos do usuário). Para os usuários, não importa se há uma ou várias fitas físicas - desde que eles recebam a funcionalidade. c. Um arquivo físico de restart poderia conter resultados intermediários incompletos e ser usado como entrada em um job step intermediário. Isto seria parte da implementação física e não um requisito lógico do usuário, portanto não seria contado. d. Uma tabela de dados mantidos pelo usuário, sobre regiões. Um arquivo lógico interno se for parte dos requisitos do usuário. A chave é lembrar que a palavra 'arquivo' em pontos de função refere-se a um agrupamento lógico de dados relacionados. Esta definição NÃO equivale à de ‘arquivo’ ou dataset físico em termos de TI. A presente lista de palavras frequentemente mal compreendidas não é exaustiva, podendo outras palavras e siglas dificultar o entendimento de pontos de função. A tabela resume os termos cobertos. Termo Significado em TI Significado em Pontos de Função Lógico Normalmente inclui tanto considerações conceituais quanto de projeto. Modelos lógicos de dados às vezes contem componentes físicos. Sob a perspectiva do negócio. Não inclui considerações de projeto ou qualidade. Reflete o que o software deve fazer, não como. Usuário Pessoa que 'utiliza' o software. Pessoa, coisa, outro aplicativo, departamento etc. que provê requisitos funcionais de usuário para o software. Aplicativo (sistema) Implementação física do software. A fronteira do aplicativo ou sistema frequentemente coincide com a do hardware ou software. Uma coleção coesa de procedimentos e dados automatizados, dando suporte a um objetivo do negócio. Projeto Dependendo da organização pode incluir novos desenvolvimentos, alterações ou melhorias em diversos aplicativos. Diz respeito ao trabalho efetuado sobre um único aplicativo: Desenvolvimento: A especificação, construção, teste e entrega de um novo sistema de informações. Melhoria: A modificação de um apli- ori_Contagem_Pontos_Funcao.odt Modelo 1.2 37 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função cativo existente. Arquivo Dataset, ou conjunto físico de dados, Um grupo de dados logicamente relacionacomo em arquivo de entrada, arquivo dos e não a implementação física desse de dados etc. grupo de dados. 1.11 Usando a APF para a verificação da completeza dos requisitos Esta seção tem como objetivo apresentar um checklist para a verificação da completeza dos requisitos de software, que é a transcrição dos itens sugeridos por Dekkers e Aguiar (2000), acrescida ainda de situações vivenciadas no processo de desenvolvimento da DATAPREV. São elas: a. Ao identificar e classificar as entidades lógicas persistentes como internas (mantidas), externas (apenas referenciadas), é útil desenhar círculos ao redor das entidades e respectivas subentidades em um modelo de dados ou diagrama de entidades e relacionamentos. b. Na análise das entidades no modelo de dados, atentar se são entidades internas à fronteira da aplicação (são mantidas pelo software) e externas (são apenas referenciadas). As perguntas respondidas pela revisão podem ser do tipo: “Por que esta entidade é externa? Pensei que fosse necessário atualizá-la”. Este tipo de situação levará a uma discussão que confirmará os requisitos originais, ou revelará uma inconsistência no entendimento e a uma mudança no diagrama. Quando esta revisão é combinada com as transações, a maioria das inconsistências (potenciais) nos requisitos é identificada. c. Se uma entidade lógica persistente foi identificada como um Arquivo Lógico Interno (ALI), isto é, mantida por uma função padrão de manutenção da aplicação, mas não existirem processos de Entrada Externa (EE) a ela associados, haverá um ou mais requisitos com problemas: Ou a entidade é apenas uma entidade de referência (caso em que poderia ser um Arquivo de Interface Externa), ou Há pelo menos um requisito faltando para manter a entidade do tipo, incluir entidade, alterar entidade ou excluir entidade. a. Se existirem funções de manutenção de dados (ou de administração de dados) identificadas para os dados, mas não existir uma entidade lógica persistente para armazenar os dados (ALI), o modelo de dados pode estar incompleto. Isto indicaria a necessidade de revisar os requisitos de dados da aplicação. b. Se houver uma função de atualização de dados presente para uma entidade identificada ori_Contagem_Pontos_Funcao.odt Modelo 1.2 38 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função como apenas de referência (AIE), isto poderia indicar que a mesma na verdade é um ALI. Os requisitos de dados estariam inconsistentes e mereceriam revisão. c. Se existirem entidades de dados que precisam ser referenciadas por uma ou mais funções de entrada, saída ou consulta, e não existir a correspondente fonte de dados no modelo de dados, diagrama de entidades-relacionamentos ou diagrama de contexto, os requisitos de dados estarão incompletos e precisarão ser revistos. d. Se existirem funções de saída ou consulta que especifiquem campos de dados que precisem ser exibidos ou transferidos para a saída para os quais não existam fontes de dados (i.e., nem ALI nem AIE), não estando os dados incluídos no código dos programas, haverá uma incongruência entre o modelo de dados e as funções dos usuários. Isto indicaria necessidade de revisão dos requisitos de dados. e. A maioria das entidades mantidas segue a convenção AUDIO (Add, Update, Delete, Inquiry, Output); cada entidade lógica persistente normalmente terá associado a si um conjunto padrão de funções. Nem todas as entidades seguirão este padrão, mas AUDIO é um bom checklist para utilizar com os ALI. f. Cautela em relação a verbos com significados amplos, tal como ‘manter’, que no caso específico poderá subentender que o usuário necessita das funcionalidades de inclusão, exclusão e de alteração. g. Verificar e registrar: A necessidade de log de transações e históricos. Caso se verifique que uma dada consulta externa (CE) seja logada, então a mesma passa a ser saída externa (SE) visto que há a necessidade de gravação de log no ALI correspondente. Se existem funcionalidades executadas com criptografia de dados. Esta necessidade faz com que uma CE seja considerada uma SE. Se o controle de acesso será da própria aplicação ou será usada solução corporativa. A existência de dados derivados nas SE. Nas entidades dependentes. Qual a regra de deleção de registros? Se apagar o titular, o dependente também é apagado? a. Requisitos não funcionais podem motivar o desenvolvimento de itens não mensuráveis e, portanto estarem sujeitos a contagens específicas para fins de faturamento comercial, além da estimativa de esforço. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 39 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 1.12 Referências IFPUG. Manual de práticas de contagem de pontos de função. Versão 4.3.1. 2010. Vasquez, C. E.; Simões, G. S.; Albert, R. M. Análise de pontos de função: medição, estimativas e gerenciamento de projetos de software. 3ª edição. Editora Ética. 2003. Dekkers, C; Aguiar, M. Applying function point analysis to requirements completeness. Cutter IT Journal, abr. 2000. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 40 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 2. Tratamento de itens não mensuráveis 2.1 Finalidade Nesta seção são apresentados orientações e procedimentos a serem aplicados em atividades de desenvolvimento de software que não estão contemplados no CPM 4.3.1 e nos roteiro de métricas de software complementares adotados nos contratos com clientes da DATAPREV. Vale destacar que o principal objetivo desta seção é fornecer elementos para viabilizar o faturamento comercial em pontos de função de serviços considerados não mensuráveis. 2.2 Diretrizes 2.2.1 Controle de acesso corporativo Caso a aplicação em desenvolvimento não possua controle de acesso próprio e use uma solução corporativa, a contagem do mesmo será feita conforme as seguintes situações: Validação simples de usuário, tal como login de rede – Não conta; A aplicação monta dinamicamente um menu de opções de acordo com o perfil do usuário – Conta como uma consulta simples. 2.2.2 Alterações de escopo de demandas O CPM 4.3.1 não contempla a contagem da alteração de escopo de uma demanda, propriamente dita, mas a recontagem do desenvolvimento como um todo. Uma alteração de escopo ocorre durante a execução de uma demanda (desenvolvimento ou manutenção) e poderá contemplar: inclusão, alteração e exclusão de funcionalidades. Uma mudança poderá também contemplar situações sem que necessariamente altere a lógica de processamento ou regras de negócios do usuário. Exemplos destes casos são manutenções de interface, páginas estáticas, verificação de erros, pontos de função de testes etc. Neste caso, os mesmo são contados conforme definido no Roteiro de Métricas do SISP. O cálculo do tamanho funcional do retrabalho de solicitação de mudança do cliente será proporcional ao esforço acumulado no momento da solicitação. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 41 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Como não há informações históricas da distribuição de esforço segundo as fases do ciclo de vida de desenvolvimento de software da Dataprev, será utilizada uma adaptação da distribuição de esforço sugerida pelo Roteiro de Métricas de Software do SISP, versão 2.0 conforme segue. Esforço (%) Fase Fase Acumulado (ea) Evidência Iniciação 5 5 DV aprovado Especificação 20 25 Caso de uso aprovado Homologação 70 95 Relatório de homologação Transição 5 100 Termo de aceite assinado Para cada uma destas fases são definidos os artefatos que são reconhecidos como evidências para caracterizar mudanças. Por exemplo, uma alteração de um caso de uso será considerada mudança se for solicitada após a sua aprovação. Ou seja, o retrabalho é caracterizado quando promovido em artefato já aprovado pelo cliente. Desta forma, o tamanho funcional da mudança para fins de faturamento comercial será calculado por meio da seguinte fórmula: , onde: é o tamanho funcional da função de dado ou de transação alterada; é o tamanho funcional da função de dado ou de transação excluída; é o tamanho funcional da função de dado ou de transação incluída; é o esforço acumulado por fase, que pode assumir os seguintes valores: = 0,05 para as funções afetadas na fase de iniciação; = 0,25 para as funções afetadas na fase de especificação; = 0,95 para as funções afetadas na fase de homologação; = 1 para as funções afetadas na fase de transição. As funções de dados ou de transações incluídas são contadas integralmente. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 42 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Exemplo Suponha uma solicitação de mudança com a seguinte característica: inclusão de uma EE simples, alteração de uma CE simples na fase de homologação e exclusão de uma SE complexa na fase de especificação. O tamanho funcional da mudança será dado por: PF = 3 + (0,5 X 3 X 0,95) + (0,4 X 7 X 0,25) = 3 + 1,425 + 0,7 = 5,125 2.2.3 Demandas canceladas ou suspensas O cálculo do tamanho funcional em pontos de função de demandas canceladas ou suspensas utilizará procedimentos semelhantes ao cálculo de mudança. Nestes casos, para as funcionalidades incluídas também são aplicados os fatores de impactos dos esforços acumulados. Exemplo Suponha que no momento do cancelamento, o desenvolvimento de uma demanda apresente o seguinte progresso: inclusão de uma EE simples na fase de especificação, alteração de uma CE simples na fase de homologação e exclusão de uma SE complexa na fase de transição. O tamanho funcional do cancelamento será dado por: PF = (3 X 0,25) + (0,5 X 3 X 0,95) + (0,4 X 7 X 1) = 0,75 + 1,425 + 2,8 = 4,975 2.2.4 Execução de demandas que usam desenvolvimento iterativo e incremental Em demandas que adotam ciclos de desenvolvimento iterativo e incremental podem ocorrer incrementos em funções de dados ou de transações. Se numa iteração qualquer uma função de dado ou de transação que já foi contada anteriormente é alterada, então ela não poderá ser recontada. Neste caso deve-se ter atenção quanto ao escopo da contagem, pois a contagem é do desenvolvimento da demanda e não de uma dada iteração geral ou ciclo de desenvolvimento. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 43 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 2.2.5 Serviços e componentes No caso de desenvolvimento de demandas cujos produtos sejam componentes de software a serem utilizados em outros desenvolvimentos ou então uma ou mais camadas de uma arquitetura em 2, 3 ou n camadas, deverá ser feita a contagem do sistema ao qual pertencem os componentes/camadas como um todo, respeitando a fronteira de negócio reconhecida pelo usuário. Um exemplo clássico é a validação do dígito verificador (DV) de CPF. Normalmente, as aplicações reusam ou acionam rotinas pertencentes a bibliotecas corporativas para esta finalidade. Neste caso, a rotina de validação de CPF não é um processo elementar. Merecem destaque os seguintes casos frequentemente aplicados nos desenvolvimentos de software na DATAPREV. Interface com o SDC. O Sistema de Dados Corporativos (SDC) possui uma camada de serviços usada pelas aplicações que necessitam acessar suas tabelas. Sua arquitetura foi projetada para impedir que usuários externos executem comandos SQL diretamente no seu banco de dados. Para exemplificar, suponha que uma aplicação deseja validar um CEP e até mesmo retornar a descrição do logradouro correspondente. O CEP é enviado ao SDC, que por sua vez dispara um dos seus serviços e devolve o logradouro ao sistema de origem. Neste caso, a funcionalidade completa é composta pela concatenação entre o serviço do SDC e o trecho da transação da aplicação. Temos uma única transação candidata a processo elementar da aplicação. A tabela de CEP também pode ser candidata a AIE da aplicação. ExtratoCNIS. É o componente mais complexo e comumente usado principalmente pelos sistemas do INSS e MTE. Sua finalidade é fornecer o extrato consolidado da vida laborativa do segurado com dados sobre vínculos, remunerações, contribuições e períodos de benefícios, obtidos por meio de serviços específicos tanto na plataforma baixa quanto na alta. Além disso, faz tratamentos de consolidação destas diversas fontes baseado em regras de negócios do CNIS e os entrega os em forma de objeto para os sistemas do NMG e em forma de string com layout compatível para os sistemas legados. As tabelas lidas são candidatas a AIE e tal como no caso do SDC, existe uma única transação candidata a processo elementar da aplicação. 2.2.6 Conversão de dados Alguns projetos de migrações de dados na DATAPREV adotam a estratégia de espelhamento de banco de dados, recurso no qual as estruturas de dados instaladas numa determinada tecnologia de banco de dados é replicada em outra tecnologia, onde são mantidas para fins históricos, audi- ori_Contagem_Pontos_Funcao.odt Modelo 1.2 44 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função toria ou validação de transformação e são reconhecidas pelo cliente. Nesta situação, estas estruturas de dados não são consideradas temporárias (requisito técnico) e sim requisito de negócio. Devem então ser contabilizados os ALI, as respectivas cargas (EE) e demais funcionalidades solicitadas pelo cliente. Deve-se observar ainda que as cargas (iniciais e incrementais) são análogas aos processos de ETL típicos de projetos de BI/DW. 2.2.7 Múltiplas mídias De acordo com as regras definidas no CPM 4.3.1 e também referendadas no Roteiro de Métricas de Software do SISP da SLTI, são reconhecidos dois tipos de abordagens em múltiplas mídias: Single Instance: considera que embora a mesma função de transação (SE ou CE) possa utilizar ou ser entregue em mídias diferentes, deve-se considerar a funcionalidade como única, ou seja, pontuada uma só vez. Multiple Instance: considera que, embora a funcionalidade seja a mesma, será pontuada tantas vezes quanto o número de mídias utilizadas. As contagens a serem feitas na DATAPREV, onde os dados podem ser apresentados em mais de uma mídia, por exemplo, tela, PDF, algum meio de gravação eletrônica etc, obedecerão as seguintes orientações: Caso as informações de negócio sejam as mesmas, a funcionalidade deverá ser contada apenas uma vez: Single instance. Caso as informações de negócio apresentem qualquer diferença (novas, alteradas, etc.) ou mesmo sendo as mesmas, mas as mídias utilizam regras de negócio diferentes, uma funcionalidade para cada uma dessas mídias deverá ser contada: Multiple instance. Caso a mesma funcionalidade possa ser executada em plataformas diferentes, por exemplo, Internet, Intranet, batch etc., a funcionalidade deverá ser contada uma vez para cada mídia utilizada: Multiple instance. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 45 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 2.2.8 Atividades sem contagem de pontos de função Nesta seção são listados os tipos de serviços normalmente ofertados pela DATAPREV, os quais não são itens mensuráveis em pontos de função. Manutenções preventivas. Encontram-se nesta categoria as modificações realizadas em um produto de software, após a entrega, visando identificar e corrigir erros latentes antes dos mesmos efetivamente ocorrerem; Desenvolvimento de cursos para EaD. Encontram–se nesta categoria as demandas de desenvolvimento de um curso na modalidade de Ensino a Distância (EaD); Mapeamento de processos de negócios. Encontram–se nesta categoria as demandas de elaboração de documentação contendo o mapeamento de processos de negócio de uma organização ou de parte de uma organização; Consultoria. Compreende serviço de apoio destinado à análise de regras de negócio a serem implementadas em soluções de TI; Treinamentos. Compreendendo as demandas de treinamentos em linguagens de programação, ferramentas de gestão, processos, modelos da qualidade, métricas etc. Caso os serviços de mapeamento de processos de negócios, consultoria e treinamentos estejam vinculados diretamente ao desenvolvimento de um determinado sistema, não serão considerados insumos para fins de faturamento comercial. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 46 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 3. Contagens de projetos de sistemas analíticos Existem diferenças substanciais entre a construção de um software transacional e a construção de um produto de data warehouse / data mart (software analítico). Além do processo de construção ser bastante diferenciado, o resultado, o tratamento dos dados e a visão do usuário possuem características muito diferentes quando comparados a um sistema tradicional. 3.1 Escopo e fronteira O escopo da contagem define quais são as funcionalidades objeto de determinada contagem. O escopo da contagem é determinado pelo propósito da contagem e identifica os sistemas, as aplicações ou seus componentes que serão dimensionados. Um escopo de contagem pode conter mais de uma aplicação. No entanto, a contagem de pontos de função é realizada separadamente considerando cada fronteira de aplicação. No contexto de contagem de PF de DW, o escopo da contagem abrange: o projeto de desenvolvimento ou manutenção do DW e o projeto de melhoria nas aplicações que irão fornecer os dados para o DW, ou seja, o DW é uma fronteira única e as aplicações de origem são outras fronteiras. 3.2 Data staging area (DAS) Geralmente, os dados do DW provenientes de outras aplicações, denominadas de aplicações de origem dos dados, são armazenados em uma base de dados temporária, denominada data staging area (DSA). Assim, os dados são importados da aplicação de origem para a DSA e então, em outro processo de integração, importa os dados da DSA para as tabelas fato e dimensão do ori_Contagem_Pontos_Funcao.odt Modelo 1.2 47 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função DW. Observe que a utilização da DSA é uma solução técnica, portanto não tem contagem de pontos de função. No entanto, é importante ressaltar que em alguns casos, o usuário deseja realizar consultas e emitir relatórios diretamente dos dados da DSA. Nesses casos, as funcionalidades da DSA serão consideradas na contagem de pontos de função, ou seja, os dados da DSA serão contados como ALI, as cargas de dados serão contadas como EE e as consultas e relatórios serão contados como CE ou SE. Contar todas as funcionalidades (dados e transação) se houver requisito de acesso aos dados do DSA. 3.3 Entradas externas em projetos de data warehouse Em projetos de DW geralmente existem funcionalidades de cargas de dados nas tabelas. Estas tabelas são denominadas de tabelas fato e tabelas dimensão em um modelo multidimensional em um diagrama estrela. As funcionalidades de carga de dados são classificadas como EE. As funcionalidades associadas às cargas de dados inicial e incremental, são contadas como EE distintas. Caso exista uma funcionalidade para exclusão de dados, esta será contada como EE. Conta-se uma EE (inicial) e uma EE (incremental) para cada registro lógico (RL) da tabela dimensão, onde os processos de manter os dados do RL e da respectiva dimensão, são distintos e independentes. Algumas vezes, as tabelas dimensão não são mantidas por carga, possuindo dados estáticos. Nesses casos, a dimensão não deve ser contada como ALI, nem como RL. Essas tabelas são classificadas como dados de código (no exemplo, Tipo de Benefício). O DW pode ter como fonte de dados vários sistemas. Assim, os dados de uma tabela fato ou de uma tabela dimensão podem ser carregados de vários sistemas de origem. Geralmente, o processamento dos dados provenientes desses sistemas é diferente dos demais e a carga das tabelas ocorre em momentos distintos. Para esses casos, conta-se um ALI para a tabela fato ou tabela dimensão e uma EE para cada carga destes dados. Deve ser observado o critério de unicidade das EE do CPM 4.3.1. Desta forma, se as EE tiverem os mesmos arquivos referenciados, os mesmos tipos de dados e a mesma lógica de processamento, então deve-se contar apenas uma vez. Contar 1 EE (Full) para a carga inicial e 1 EE (Incremental) para as atualizações periódicas, nas situações que se seguem: Para cada tabela fato ori_Contagem_Pontos_Funcao.odt Modelo 1.2 48 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Para as tabelas dimensão identificadas como ALI Para as agregações identificadas como ALI Para carga de dados proveniente de cada sistema de origem distinto. Para carga de registro lógico da dimensão (mantido independentemente desta dimensão) Contar 1 EE havendo funcionalidade requisitada para exclusão de dados no DW. 3.4 Consultas em projetos de DW Frequentemente, em projetos de DW existem funcionalidades que geram arquivos de dados consolidados nas aplicações de origem (aplicações que fornecem os dados para o DW). Essas funcionalidades de extração de dados da aplicação de origem serão contadas como saídas externas ou consultas externas na fronteira da aplicação de origem. Em alguns casos, o DW acessa diretamente o banco de dados das aplicações de origem, por meio de alguma ferramenta. Observe que nesses casos não há transferência de dados para o banco de dados do DW. Assim, os dados do sistema de origem são contados como AIE e as consultas como CE ou SE. Em aplicações de data warehouse existem requisitos para geração de relatórios (ou consulta de relatórios pré-definidos) ou gráficos (painéis, dashboards) usando as ferramentas. Cada relatório ou gráfico requisitado pelo usuário e implementado pela equipe de desenvolvimento será contado como CE ou SE, devendo-se ainda verificar se atendem os critérios de determinação da unicidade do CPM 4.3.1. Os relatórios gerados pelo usuário por meio da funcionalidade de consultas ad-hoc ou personalizadas disponível na ferramenta OLAP não são contados, porque não constituem um requisito do usuário para a equipe de desenvolvimento. A geração do cubo também deve ser contada como SE. Esse tipo de tabela normalmente é utilizada para consumo por outras aplicações ou pelo próprio datamart. A geração do cubo deve ser contada como uma SE por tabela fato, considerando a estrela, ou seja, a tabela fato e as dimensões. Os arquivos referenciados serão as tabela fato e cada tabela dimensão, identificada como ALI, e os tipos de dados serão os atributos de todos os arquivos referenciados (tabela fato e dimensão) e as métricas associadas. As dimensões de outros DW referenciadas na geração do cubo, contadas como arquivos de interface externa, também devem ser consideradas como arquivos referenciados da SE. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 49 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Contar 1 CE/SE para a extração de dados na fronteira do sistema de origem Contar 1 CE/SE para cada relatório implementado pela equipe de desenvolvimento Contar 1 SE para a geração de um cubo Contar 1 CE/SE para a consulta a um ALI de outra aplicação (AIE), onde os dados não são transferidos para o DW. 3.5 Contagem de funções de dados em projetos de DW Em um modelo de dados multidimensional, esquema estrela, são reconhecidos dois tipos de entidades: tabelas fato e tabelas dimensão. As tabelas dimensão mantidas por um ou mais processos de ETL devem ser contadas como um ALI (no exemplo – dimensão Cidadão). Deve-se observar a quantidade de níveis hierárquicos na dimensão e contar um RL para cada nível hierárquico. No exemplo, o Estado Civil do Cidadão (Histórico), pode ocorrer várias vezes. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 50 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função Caso exista leitura de dados de outras aplicações para validação de informações durante as cargas de dados, essas tabelas que são ALI de outras aplicações e são apenas lidas pelo DW, serão contadas como AIE. As dimensões de outros DW referenciadas na geração do cubo também são consideradas como AIE. Algumas vezes, o usuário requer a combinação de tabelas fatos gerando uma outra tabela fato ou uma estrutura de agregação, visando apoiar a geração de consultas. Em alguns casos, a estrutura de agregação pode ser formada por uma tabela fato e tabelas dimensão. A estrutura de agregação é contada como ALI e a carga de dados é contada como uma EE. O exemplo mostra a agregação da tabela fato “Arrecadação” com a dimensão “Cidadão”, resultando na tabela “Arrecadação do Cidadão”, que deve ser contada como ALI. A carga de dados é contada como uma EE. Uma estrutura de agregação pode acontecer também entre tabelas dimensão. Contar 1 ALI para cada tabela fato; Contar 1 ALI para a tabela dimensão mantida por 1 ou mais processos de ETL. Contar 1 RL (registro lógico) para cada nível hierárquico desta dimensão. Contar 1 AIE para o acesso a ALI de outra aplicação, onde os dados não são transferidos para o DW; Contar 1 ALI para uma estrutura de agregação (entre dimensões e/ou fato). Roteiro Prático para Contagem Função de Dados em DW Este roteiro prático descreve as etapas do processo de contagem de função de dados em DW, utilizando exemplos para um melhor entendimento e dando dicas sobre o a técnica. i) Identificar as tabelas Fato (Ex: Benefício). ii) Identificar as Dimensões através das chaves estrangeiras, contidas nas tabelas Fato. Cada chave estrangeira da tabela Fato liga a uma Dimensão. (Ex: Tipo_Benefício e Cidadão) iii) Classificar estas Dimensões: a) Dimensão Estática (Code Data): não são mantidas e geralmente expressas por Código e Descrição. Devem ser desconsideradas e não serão contadas (Ex: Tipo_Benefício) b) Dimensão Hierárquica, as que são mantidas (Ex: Cidadão). Identificar as Chaves Estrangeiras destas Dimensões Hierárquicas. Cada chave estrangeira desta Dimensão liga a uma ori_Contagem_Pontos_Funcao.odt Modelo 1.2 51 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função outra Dimensão hierarquicamente inferior: Classificar estas Dimensões; - Desconsiderar as Dimensões Estáticas (Ex: Sexo); - Considerar as Dimensões que forem mantidas nesta hierarquia inferior (Ex: Historico_Estado_Civil), serão consideradas 1 Registro Lógico (RL) da Dimensão hierárquica superior (Ex: Cidadão terá 2 RL). iv) Identificação das Estruturas de Agregação que serão consideradas ALI (Ex: Arrecadação_Cidadão). Dicas: 3.6 Os Arquivos Externos (AIE) serão contados somente quando os seus dados transitarem no DW sem serem armazenados. Por exemplo, quando fizerem validações (batimentos) nas gerações de Cubos ou dentro dos processos de ETL. Devem ser contadas as EE (inicial e incremental) das tabelas Fato, Agregações e das tabelas Dimensão identificadas como ALI. Devem ser contadas as EE (inicial e incremental) das tabelas Dimensão que foram identificadas como RL (registro lógico) de outra Dimensão. Cada Dimensão hierárquica é mais facilmente identificada no modelo dimensional normalizado Snow Flake. Funcionalidades de controle do DW Como um dos propósitos do DW é o de disponibilizar dados históricos, as funções de limpeza de dados são usualmente incorporadas na área de controle do DW, por exemplo guardar 60 meses de dados históricos. Esta função de limpeza é contada como uma EE. Os dados utilizados para gerenciar o DW podem ser, por exemplo, datas nas quais uma funcionalidade inclui dados em uma tabela fato a partir dos dados de um sistema de origem, a quantidade de registros adicionados, a quantidade de registros rejeitados, ou parâmetros utilizados para o processamento. Os processos elementares da aplicação devem ler e editar esses metadados. Essas funções não são identificadas pelo usuário final, no entanto, esses mecanismos de controle devem ser criados para o DW, sendo considerados pelo perfil administrador. Assim, essas funcionalidades devem ser contadas. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 52 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função 3.7 Demandas típicas em projetos de DW 3.7.1 Alteração de Dados de Dimensões Estáticas A inclusão ou alteração de dados nas dimensões estáticas, em projetos de manutenção, serão contadas da seguinte forma: PF_Dimensão_Estática = 0,3 PF x Qtd dimensões alteradas 3.7.2 Massa de dados para homologação em DW Em alguns projetos de DW podem ocorrer demandas de geração de massa de testes para homologação. Estas atividades consistem em carga de dados no banco de dados do ambiente de homologação. A contagem de pontos de função deve ser realizada da seguinte maneira: Contar uma EE para cada tabela fato, dimensão ou agregação carregada. A EE terá sempre apenas um arquivo referenciado (o ALI carregado) e os tipos de dados (TD) serão os campos das tabelas carregados. Segue a fórmula de cálculo: PF_Massa_Testes = PF_incluído_carga_dados 3.8 Demandas típicas de manutenção evolutiva em DW Esta seção apresenta demandas típicas de projetos de manutenção evolutiva para DW. 3.8.1 Alteração de campos em tabelas fato e dimensão É importante ressaltar que caso seja solicitada alteração em campos ou criação de campos em tabelas fato, a contagem deve considerar o PF_ALTERADO, e aplicar o fator de impacto (FI) conforme especificado em contrato, das seguintes funções: CE/SE: Extração de dados do sistema de origem ALI: Tabela fato EE: Atualização de dados da tabela fato EE: Carga de dados na tabela fato SE: Geração de cubo É importante ressaltar que caso seja solicitada alteração em campos ou criação de campos em tabelas dimensão, a contagem deve considerar o PF_ALTERADO, e aplicar o FI conforme especificado em contrato, das seguintes funções: CE/SE: Extração de dados do sistema de origem ori_Contagem_Pontos_Funcao.odt Modelo 1.2 53 de 54 PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Contagem de Pontos de Função ALI: Tabela dimensão EE: Atualização de dados da tabela dimensão EE: Carga de dados na tabela dimensão SE: Geração de cubo Devem ser contadas todas as gerações de cubo que referenciem a tabela dimensão alterada. 3.8.2 Criação, configuração e disponibilização de um filtro Havendo requisito para a criação de novo filtro de segurança para um DW, não serão recontados os relatórios pré-definidos. A demanda será contada como se segue: PF_Filtro de Segurança = 0,3 PF por demanda 3.9 Referências NESMA. FPA applied to DATA WAREHOUSING. Version 1.1.0. 2008 RFB. Guia de Contagem de Ponto de Função. Versão 4.7. 2013. ori_Contagem_Pontos_Funcao.odt Modelo 1.2 54 de 54
Download
