Medição e Análise. Orientação Contagem de Pontos de Função Versão 2.7. PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev

Transcrição

1 Medição e Análise Versão 2.7 ori_contagem_pontos_funcao.odt 1 de 54

2 Histórico de Revisões Data Versão Descrição Autor 12/05/ Adequação ao novo padrão visual da DATA- PREV. Dicas de contagens de sistemas analíticos 07/01/ Alteração na forma de cálculo de pontos de função de mudanças 22/11/ Alteração do texto, inclusão de exemplo e resumo no item 3. Alteração no layout do documento. 20/08/ Alteração na Parte 3 - Contagem de Projetos de Sistemas Analíticos Mauricio Koki Matsutani - COAM Mauricio Koki Matsutani - COAM Luiz Flávio Santos Ribeiro COAM Luiz Flávio Santos Ribeiro - COAM 08/08/ 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/ 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/ Fusão do guia com o roteiro interno de contagem 17/08/ Adequação à release 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 Maria do Socorro Bastos de Alencar Viana - UDCE Mauricio Koki Matsutani - CGPS Carlos Alberto Pires de Castro UDSC Edviges Mariza Campos de Magalhães - UDPB Mauricio Koki Matsutani CGPS 29/11/ Adequação para os padrões PD-DATAPREV Carlos Alberto Pires de Castro UDSC 22/11/ Inclusão de controle de versão e atualização para release do CPM Carlos Alberto Pires de Castro DEQS 01/12/ Documento Original David Samuel Abramowicz - DEQS ori_contagem_pontos_funcao.odt 2 de 54

3 Índice 1.Processo de contagem de pontos de função Reunir a documentação disponível Determinar o propósito da contagem Escopo da contagem Fronteira da aplicação Contar as funções de dados Arquivo lógico interno (ALI) Determinar a complexidade funcional Registros lógicos Tipos de dados Arquivo de interface externa (AIE) Determinar a complexidade funcional Registros lógicos Tipos de dados Contar as funções de transação Processo elementar Entrada externa (EE) Determinar a complexidade funcional Arquivos referenciados e mantidos Tipos de dados referenciados e mantidos Saídas externas (SE) Determinar a complexidade funcional Arquivos referenciados Tipos de dados referenciados Consultas externas (CE) Determinar a complexidade funcional ori_contagem_pontos_funcao.odt 3 de 54

4 Arquivos referenciados Tipos de dados referenciados Sumário das lógicas de processamento usadas por EE, SE e CE Intenção primária da função de transação Calcular o tamanho funcional Aplicação de fator de ajuste Documentar e relatar Termos que criam confusão Usando a APF para a verificação da completeza dos requisitos Referências Tratamento de itens não mensuráveis Finalidade Diretrizes Controle de acesso corporativo Alterações de escopo de demandas Demandas canceladas ou suspensas Execução de demandas que usam desenvolvimento iterativo e incremental Serviços e componentes Conversão de dados Múltiplas mídias Atividades sem contagem de pontos de função Contagens de projetos de sistemas analíticos Escopo e fronteira Data staging area (DAS) Entradas externas em projetos de data warehouse Consultas em projetos de DW Contagem de funções de dados em projetos de DW Funcionalidades de controle do DW ori_contagem_pontos_funcao.odt 4 de 54

5 3.7Demandas típicas em projetos de DW Alteração de Dados de Dimensões Estáticas Massa de dados para homologação em DW Demandas típicas de manutenção evolutiva em DW Alteração de campos em tabelas fato e dimensão Criação, configuração e disponibilização de um filtro Referências ori_contagem_pontos_funcao.odt 5 de 54

6 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 (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 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 6 de 54

7 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 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 7 de 54

8 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 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 8 de 54

9 O escopo da contagem pode ser uma parte de uma aplicação ou projeto, ou até mesmo algumas funcionalidades selecionadas 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. Envolve os ALI 1.3 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) 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 9 de 54

10 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 10 de 54

11 Determinar a complexidade funcional A complexidade dos ALI é identificada por meio do número de registros lógicos e de tipos de dados 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 11 de 54

12 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 12 de 54

13 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: 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 13 de 54

14 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 Número de registros lógicos Tipos de dados relacionados De 1 a 19 De 20 a 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 14 de 54

15 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 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 15 de 54

16 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) 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 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 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 16 de 54

17 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 Número de registros lógicos Tipos de dados referenciados De 1 a 19 De 20 a 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 17 de 54

18 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 18 de 54

19 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 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 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 19 de 54

20 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 20 de 54

21 (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 Determinar a complexidade funcional Identificar do número de arquivos referenciados e mantidos Identificar do número de tipos de dados referenciados e mantidos 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 21 de 54

22 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 Número de arquivos referenciados Tipos de dados referenciados De 1 a 4 De 5 a ou mais Apenas 1 Baixa Baixa Média 2 Baixa Média Alta ori_contagem_pontos_funcao.odt 22 de 54

23 3 ou mais Média Alta Alta 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 23 de 54

24 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 24 de 54

25 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) 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 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 25 de 54

26 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: Número de arquivos referenciados Tipos de dados referenciados De 1 a 5 De 6 a 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 26 de 54

27 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 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 27 de 54

28 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 28 de 54

29 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 Determinar a complexidade funcional Identificar do número de arquivos referenciados Identificar do número de tipos de dados referenciados Arquivos referenciados O número de arquivos referenciados é o somatório de todos os ALI e AIE acessados 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 29 de 54

30 Tabela para classificação de uma SE quanto à sua complexidade Número de arquivos referenciados Tipos de dados referenciados De 1 a 5 De 6 a ou mais Apenas1 Baixa Baixa Média De 2 a 3 Baixa Média Alta 4 ou mais Média Alta Alta 1.5 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 30 de 54

31 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 F N/A Intenção primária do tipo de transação É uma função do tipo de função de transação, mas não é a intenção primária e está presente algumas vezes 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 31 de 54

32 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 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 ajustados 1 (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 32 de 54