manual de procedimentos v1.0 - sefaz.ba :: … · web viewmanual de anÁlise de pontos de funÇÃo...

MANUAL DE ANÁLISE DE PONTOS DE FUNÇÃO

Salvador (Ba), Abril de 2018.

CONTROLE DE VERSÃO

Versão Data Responsável Descrição

01.00.00 01/10/2016 Leila Karita - GQS Versão Inicial

01.00.01 26/12/2017 Leila Karita - GQS Alteração do item 5. Práticas de Contagem SEFAZ para:

Inclusão de regras para identificação da fronteira;

SEFAZ-BA Secretaria da Fazenda do Estado da BahiaSGF Superintendência da Gestão FazendáriaDTI Diretoria de Tecnologia da InformaçãoGEDES Gerência de Administração de Dados e Desenvolvimento de Sistemas

Secretaria da Fazenda do Estado da Bahia 12/05/23 DTI - Diretoria de Tecnologia da Informação

Inclusão de regra de contagem de Controle de Acesso pelos componentes ASLIB e ASCAS.

01.00.02 23/04/2018 Leila Karita - GQS

Alteração do “Cenário 3 – Projeto com mudanças em requisitos ou artefatos” para estar alinhado com o SISP 2.1 quanto a contagem de PF em mudança de requisitos.

Atualização do item “3.6.3 Dados de Código” para inclusão de regra de contagem de dados de código em projeto de web service.

Página 2 document.doc


ÍNDICE

1. OBJETIVO........................................................................................................................ 5

2. GERAL............................................................................................................................. 6

3. DIRETRIZES DE CONTAGEM DA SEFAZ......................................................................6

3.1. MODELO DE RELATÓRIO DE CONTAGEM (PLANILHA DE CONTAGEM).............6

3.2. NOMENCLATURA DO RELATÓRIO DE CONTAGEM...............................................6

3.3. PADRÃO DE NOMENCLATURA PARA FUNÇÕES DE DADOS E FUNÇÕES DE TRANSAÇÃO:.......................................................................................................................... 7

3.3.1. FUNÇÕES DE DADOS.............................................................................................7

3.3.2. FUNÇÕES DE TRANSAÇÃO...................................................................................8

3.4. ITENS NÃO MENSURÁVEIS.......................................................................................8

3.4.1. MANUTENÇÃO EM INTERFACE - ADICIONAL.....................................................9

3.4.2. COMPONENTE INTERNO REUSÁVEL.................................................................10

3.4.3. DADOS DE CÓDIGO (CODE DATA).....................................................................10

3.5. CONSULTA IMPLÍCITA.............................................................................................10

3.6. LOG............................................................................................................................ 10

3.7. AUDITORIA................................................................................................................11

3.8. DADO HISTÓRICO.....................................................................................................11

3.9. CONSULTAS COM FILTROS DIFERENTES E COM AS MESMAS SAÍDAS...........11

3.10. CONSULTAS COM FILTROS IGUAIS E COM SAÍDAS DIFERENTES................12

3.11. MÚLTIPLAS MÍDIAS..............................................................................................12

3.12. INTEGRAÇÃO ENTRE APLICAÇÕES...................................................................12

4. VALOR DO FATOR DE AJUSTE (VAF)........................................................................13

5. PRÁTICAS DE CONTAGEM SEFAZ.............................................................................13

5.3. SITUAÇÕES ESPECIAIS...........................................................................................16

5.1. ELEMENTOS DE INTERFACE..................................................................................17BOTÕES DE RÁDIO...........................................................................................................17CHECK LIST.......................................................................................................................17COMBO BOX...................................................................................................................... 17TREE VIEW........................................................................................................................17

5.2. SISTEMAS OU APLICATIVOS DE APOIO................................................................17



5.2.1. PROD......................................................................................................................18

6. ORIENTAÇÕES GERAIS PARA MEDIÇÃO DE PROJETOS........................................19

FATOR REDUTOR.................................................................................................................. 19CENÁRIO 1 – PROJETO COM ENTREGA ÚNICA.........................................................................19CENÁRIO 2 – PROJETO COM ENTREGAS MODULARIZADAS.......................................................19CENÁRIO 3 – PROJETO COM MUDANÇAS EM REQUISITOS OU ARTEFATOS.................................21

7. PRAZO PARA CONTAGEM...........................................................................................23

8. GLOSSÁRIO...................................................................................................................23



1.OBJETIVO

Este documento tem como principal objetivo apresentar as definições de contagem de pontos de função adotadas na SEFAZ, complementando as regras de contagem utilizadas na Análise de Pontos de Função estabelecidas no CPM 4.3.1 (Counting Practices Manual) do IFPUG e no roteiro de Métricas de Software do SISP 2.1. Esta documentação deverá ser utilizada como principal referência nas pontuações efetuadas nos sistemas da Secretaria da Fazenda do Estado da Bahia.



2.GERAL

O(s) momento(s) onde a(s) pontuação(ões) deverá(ã)o ser efetuada(s) deve(m) ser determinada(s) com base na MDMS (metodologia de Desenvolvimento e Manutenção de Sistemas).

3.DIRETRIZES DE CONTAGEM DA SEFAZ

Nessa seção, estão definidas as regras e premissas adotadas pela SEFAZ para contagem dos seus sistemas e projetos.

3.3. Modelo de Relatório de Contagem (Planilha de contagem)

As contagens devem ser evidenciadas no relatório de contagem SEFAZ que deve conter, necessariamente, as seguintes informações:

Nome do projeto Data de realização da contagem Responsável pela contagem Versão da contagem Propósito da contagem (motivação) Fase do ciclo de vida do projeto Tipo da contagem Escopo da contagem Fronteiras envolvidas Identificação da documentação e sua versão que serão usadas de base para a

medição Suposições e premissas adotadas Lista das funções de dados e transacionais identificadas Lista de itens não mensuráveis

Adicionalmente, o relatório deve:

Adequar-se à nomenclatura das funções de dados e transação da SEFAZ Conter a rastreabilidade das funções de dados com os objetos do modelo de dados Conter a rastreabilidade das funções transacionais com o documento de requisitos

ou casos de uso Conter a rastreabilidade das funções transacionais com as funções de dados Conter a rastreabilidade das funções não contempladas pela APF com a lista de

itens não mensuráveis.

3.4. Nomenclatura do relatório de contagem

O relatório de contagem deve seguir o seguinte padrão de nomenclatura:

NOTA:


SiglaProjeto_Pontuacao_Versao_SEFAZ_DD_MM_AAAA


Onde:

SiglaProjeto - Descrição da Sigla do projeto Pontuacao – Total de pontos de função da versão. Versao – Número da versão do sistema. DD – Dia de realização da contagem com dois dígitos. MM – Mês de realização da contagem com dois dígitos. AAAA – Ano de realização da contagem com quatro dígitos.

3.5. Padrão de nomenclatura para funções de dados e funções de transação:

Para facilitar o entendimento e minimizar erros por omissão ou duplicidade, essa seção estabelece boas práticas para serem adotadas no processo de contagem. De modo geral, a contagem deve contemplar:

Agrupamento lógico das funções;

Segregação das funções de dados das funções transacionais.

3.5.1. Funções de dados

Para as funções de dados identificadas, deve-se:

Segregar os ALIs dos AIEs;

Segregar as funções de conversão de dados das demais funções de dados (ALI e AIE);

O nome de uma função de dados deve:

Ser simples e o mais representativo de sua principal intenção;

Evitar usar o nome físico da tabela de banco de dados. O foco deve ser a entidade no negócio;

Exemplo: MUNICIPIO, CONTRIBUINTE (Correto)AAVCIDAT, TAB_CONTRIB (Incorreto)

Ser único, sem duplicidade com outras funções;

Usar o nome do grupo das entidades que formam o arquivo;

Exemplo: PEDIDOS E ITENS, ao invés de PEDIDOS.

Para os AIEs, informar o sistema de origem como complemento.

Exemplo: CONTRIBUINTE (do SIGAT) (Correto)SIGAT_CONTRIBUINTE (Incorreto)



3.5.2. Funções de transação

Para as funções de transação identificadas, deve-se:

Evitar agrupar as funções transacionais por tipo (EE, CE e SE), pois não tem sentido, inclusive, pode dificultar a legibilidade da medição;

O nome de uma função de dados deve:

Estar no verbo infinitivo;

Exemplo: Cadastrar contribuinte, Excluir documento.

Procurar usar nomes que facilitem o entendimento do usuário do negócio e não nomes técnicos;

Exemplo: Consultar view de contribuinte, Manipular prodecure, Subir o script (Incorreto).

Evitar usar o nome do programa;

Evitar usar o item de “manutenção” para dar nome à função transacional. A manutenção deve estar mapeada na rastreabilidade da função com a documentação base.

Exemplo: Incluir o campo CEP no cadastro de contribuinte (Incorreto)Cadastrar contribuinte (Correto)

Usar a ação “Listar” para várias ocorrências e a ação “Consultar” para o acesso ao detalhamento de um objeto;

Para funcionalidades que envolvem interface, utilizar o nome do sistema remetente ou destinatário;

Exemplo: Enviar contratos para o Cobrança Amigável, Processar pagamento do Auto-atendimento.

Evitar usar o mesmo nome da consulta explícita em uma consulta implícita.

Exemplo: Excluir cliente 2, Excluir cliente – consulta implícita (Incorreto)Consultar cliente antes de excluir (Correto)

3.6. Itens Não Mensuráveis

Esse é um conceito adotado pelo mercado para evidenciar o esforço de atividades que não são passíveis de serem pontuadas pela técnica de Análise de Pontos de Função. Itens não mensuráveis podem ser identificados em projetos de desenvolvimento e em projetos de melhoria.

Para efeito de organização e facilidade de entendimento da contagem, os itens não mensuráveis devem ser contados à parte da contagem padrão.



Para obtenção do tamanho da demanda sobre cada item não mensurável mapeado, deverá ser aplicado um percentual sobre o ponto de função da funcionalidade, caso esta fosse pontuada pelas regras do IFPUG, ou sobre a quantidade de páginas (telas) impactadas. O total de pontos de função dos itens não mensuráveis será gerado a partir da soma dos pontos de cada item pontuado.

NOTA:

NOTA:

Para os itens não mensuráveis, abaixo, os projetos da SEFAZ deverão adotar os fatores de redução definidos no Roteiro de Métricas de Software do SISP versão 2.0 ou superior.

Projetos de Migração de Dados Manutenção Corretiva Mudança de Plataforma Atualização de Versão Manutenção em Interface Adaptação em Funcionalidades sem Alteração de Requisitos Funcionais Múltiplas Mídias Apuração Especial Atualização de Dados Desenvolvimento, Manutenção e Publicação de Páginas Estáticas de Intranet,

Internet ou Portal Manutenção de Documentação de Sistemas Legados Verificação de Erros

Para os itens não listados acima, deve-se seguir as regras abaixo:

3.6.1. Manutenção em Interface - adicional

Adicionalmente ao que sugere o roteiro do SISP, deve-se inserir na categoria de item não mensurável “Manutenção em Interface”, os itens, abaixo, referentes à alteração em layout de telas. Deverá ser aplicado o mesmo fator redutor adotado pelo SISP para essa categoria.

Mudança de posição de campos em telas, em relatórios ou em layout de arquivos, sem que haja alteração em elementos de dados, arquivos referenciados ou informações de controle;

Inclusão, alteração ou exclusão de imagem; Divisão de telas e/ou relatórios, sem que tenha havido mudança na

funcionalidade; Atualização de rótulos de dados sem que haja mudança de funcionalidade.


O somatório de itens não mensuráveis por funcionalidade não pode ultrapassar o tamanho funcional em pontos de função da referida funcionalidade. Caso ocorra, valerá o tamanho funcional.

A medição de itens não mensuráveis é não cumulativa dentro da mesma funcionalidade, ou seja, caso uma mesma funcionalidade possua itens mensuráveis e itens não mensuráveis (uma alteração no processo elementar e uma alteração de layout na mesma tela, por exemplo), apenas os itens mensuráveis devem ser contados.


3.6.2. Componente Interno Reusável

A aferição do tamanho em pontos de função será realizada com a aplicação de um fator de redução de modo a considerar 20% da contagem de uma função transacional de mais baixa complexidade (3 PF), ou seja 0,6 PF. Assim sendo, deve ser utilizada a seguinte fórmula de cálculo:

PF_COMPONENTE_ARQUIVO = 0,6 PF x QTD_ARQUIVOS_ALTERADOS

NOTA DA SEÇÃO:

3.6.3. Dados de código (Code Data)

A identificação das tabelas de dados de código deverá obedecer às regras descritas no Manual de Práticas de Contagem do IFPUG, versão vigente nesse manual.

Para os projetos da SEFAZ, sejam de desenvolvimento ou melhoria, a contagem dos dados de código apenas poderá fazer parte da medição se houver requisito aprovado pelo gestor para manter os dados na aplicação através de interface, o chamado CRUD (Create, Read, Update e Delete). Outra possibilidade é o desenvolvimento de consultas, via web service, para disponibilizar o acesso à dados mantidos em entidades classificadas como dados de código. Nesses casos, deve-se considerar 30% do tamanho dos pontos de função das funções de dados e/ou transacionais, caso estes fossem mensuráveis.

Na contagem de transações que implementam requisitos funcionais acessando também dados de código, só devem ser considerados como arquivos referenciados os ALIs e AIEs que implementam dados de negócio ou dados de referência e nunca, em quaqluer hipótese, dados de código.

3.7. Consulta implícita

Deve-se considerar como consulta implícita a função transacional que apresentará dados ao usuário no intuito de preceder uma outra função transacional a ser realizada opcionalmente.

Normalmente, a consulta implícita não é documentada nos requisitos, mas é facilmente identificada. As situações mais comuns são antes de efetivar uma transação de alteração ou exclusão, por exemplo, onde os dados são apresentados ao usuário e, na sequência, o usuário tem duas alternativas a seguir, ou efetua a transação ou desiste dela. A contagem de consulta implícita deve atender as regras definidas pelo CPM IFPUG para pontuar funções transacionais.

NOTA:


Qualquer situação não identificada nessa seção de itens não mensuráveis deverá ser tratada junto à Gestão de Qualidade de Software (GQS).

Quando uma consulta implícita é idêntica a uma consulta explícita, apenas uma delas deverá ser contada, de preferência a consulta explícita.


3.8. Log

O conceito de “Log” corresponde ao registro de procedimentos ou ações realizadas pela aplicação, em determinado período de tempo, com o objetivo de apoiar a auditoria do ambiente tecnológico e identificar as causas raízes de falhas em sistemas. Nesse caso, o log não deve ser mensurado, já que não armazena informações de negócio reconhecidas pelo usuário da aplicação.

3.9. Auditoria

A auditoria tem o objetivo de armazenar informações referentes às ações realizadas pelos usuários da aplicação no passado, de modo que seja possível apurar, em qualquer tempo, quais foram as ações executadas quando da utilização do sistema. Para isso, devem existir no mínimo as informações para identificar quem realizou a ação (ID de usuário), quando e o que foi realizado, além de outras informações adicionais.

Para ser contada, a auditoria deve ser explicitamente solicitada pelo gestor do negócio/aplicação. Para o processo de contagem, deve-se considerar um ALI para armazenar os dados de auditoria com apenas um RLR. Para a contagem de funções de transação, deve existir apenas a funcionalidade de consulta a tais dados. Não é correto contar processos elementares separados para incluir os dados de auditoria, pois o armazenamento desses dados é parte integrante das mesmas funcionalidades que processam os dados de negócio.

3.10. Dado histórico

Para fazer parte do tamanho funcional, o histórico deve ser explicitamente solicitado pelo gestor e deverá existir funcionalidade de consulta a tais dados. A função de consulta aos dados deverá ser contada de acordo com as regras de contagem das funções transacionais do CPM IFPUG. Nesse caso, o histórico será considerado um RLR do ALI relacionado.

Na contagem das funções transacionais, as ações para incluir, alterar e excluir as informações históricas não devem ser contadas separadamente, pois o armazenamento dessas informações é parte integrante da mesma funcionalidade que processa os dados de negócio.

Agora, quando o histórico for mantido de forma independente do registro principal e, por exemplo, o registro é excluído do ALI principal, mas o histórico mantém o registro excluído, o histórico se torna um ALI independente e não um RLR do ALI relacionado.

3.11. Consultas com filtros diferentes e com as mesmas saídas

Trata-se de consultas com diferentes critérios de filtro, mas uma única saída idêntica em termos de campos, ou seja, apenas os dados são atualizados a cada critério.

Exemplo: Em uma tela de consulta podem existir opções de filtros como pesquisa de empregados por lotação, data de admissão, data de nascimento, dentre outros, em que, quando não for especificado nenhum filtro, serão retornados todos os empregados de uma empresa, ou seja, a seleção dos filtros é opcional. Mas, caso sejam selecionados alguns filtros, poderá ser retornado nenhum ou vários empregados.

Para esse cenário, entende-se que os itens de dados e arquivos referenciados são os mesmos e o que difere são apenas os dados retornados em função dos parâmetros do filtro. Nesse caso,



considera-se que existe apenas um processo elementar de consulta, que pode ser classificado como CE ou SE.

No caso em que houver evidências de existirem diferentes requisitos funcionais referentes a critérios mutuamente exclusivos indicando que a junção em uma única consulta foi opção de projeto, deverá ser avaliado se é o caso de considerar mais de um processo elementar.

3.12. Consultas com filtros iguais e com saídas diferentes

Essas consultas constituem processos elementares distintos e, segundo as regras de unicidade de Consultas Externas e Saídas Externas do CPM IFPUG, devem ser contadas separadamente porque possuem itens de dados distintos na saída. Assim, se a aplicação tiver duas consultas com filtros iguais e saídas diferentes, devem ser contadas duas consultas separadas.

3.13. Múltiplas mídias

Para este item, devem-se adotar as premissas estabelecidas no Roteiro de Métricas de Software do SISP versão vigente.

3.14. Integração entre aplicações

Este tópico fornece uma orientação para contagem de integração entre aplicações por meio de recursos técnicos como web services, visões e stored procedures de banco de dados, arquivos de exportação/importação, etc.

Para ilustrar a integração entre aplicações serão utilizados dois sistemas: “A” e “B”, de fronteiras distintas, onde o sistema a ser contado é o “A”.

Situação: Sistema “A” requisita dados do Sistema “B”Nesse cenário, o Sistema “A” precisa obter informações mantidas pelo Sistema “B”. As regras de negócio para gerar as informações são de domínio do Sistema “B”.

Exemplo:

Requisito: O sistema “A” precisa disponibilizar uma consulta ao usuário que dentre as informações a serem exibidas está o saldo devedor do cliente que é mantido por um grupo lógico no sistema “B”. A questão requer a análise de dois cenários:

Cenário 1: O sistema “B”, por limitações tecnológicas ou por questões de segurança, não permite o acesso direto ao dado e já disponibiliza em sua fronteira o saldo devedor do cliente por meio de consulta a um web service, visão ou stored procedure no banco de dados. Nesse caso, o sistema “A” deve abstrair a existência do recurso técnico (web service, visão, stored procedure) e contar o grupo lógico que mantém o dado demandado na fronteira do sistema “B” como um AIE, pois se entende que o sistema “A” poderia obter diretamente os dados do Sistema “B”, caso não existisse a limitação tecnológica.


Sistema A Sistema B

AIEALICE

Web Service /

View / Stored Procedure


Cenário 2: O sistema “B”, por limitações tecnológicas ou por questões de segurança, não permite o acesso direto ao dado e ainda não provê uma solução para acesso. Por ser do seu domínio a regra de negócio para a geração do saldo devedor do cliente, o sistema “A” deve prever no escopo da contagem, a melhoria no sistema “B” para desenvolver uma rotina para fornecer o dado solicitado. Na contagem do sistema “B”, essa rotina deve ser contada como uma função transacional do tipo CE ou SE, de acordo com as regras do CPM. Para o sistema “A”, o grupo lógico de dados que mantém o dado deve ser contado como um AIE, pois se entende que, se não fosse a restrição técnica, a aplicação poderia obter diretamente os dados sem qualquer intervenção por parte do Sistema “B”.

NOTA DA SEÇÃO:

4.Valor do Fator de Ajuste (VAF)

O valor do fator de ajuste identificado através da análise das 14 características gerais do sistema não deve ser utilizado, pois a técnica de pontos de função foi padronizada por meio da norma ISO/IEC 14143-1:2007, como uma medida de tamanho funcional.

Dessa forma, sobre a contagem dos requisitos não funcionais, a SEFAZ estabelece que:

EM PROJETO DE DESENVOLVIMENTO:

Não devem ser contados, pois estão incorporados às características de cada projeto. O tamanho funcional medido deve representar tanto o esforço funcional quanto o esforço não funcional para o atendimento do serviço contratado, não cabendo qualquer remuneração adicional por esforços de caráter técnico/tecnológico.

EM PROJETO DE MELHORIA:

Devem ser contados, pois estão envolvidos com alterações em funcionalidades já implantadas em produção. O tamanho funcional medido deve ser calculado de acordo com as regras previstas neste documento para itens não mensuráveis.

NOTA:

5.PRÁTICAS DE CONTAGEM SEFAZ

Essa seção apresenta particularidades referentes ao ambiente SEFAZ que devem ser tratadas da seguinte maneira:

FRONTEIRA


Alterações em virtude de requisitos não funcionais não poderão ser consideradas caso a transação que é influenciada por estes já tenha manutenção prevista no mesmo processo de contagem.

Caso o item não mensurável não esteja contemplado nesse documento, deverá haver uma reunião com a GQS para alinhamento e definição de regra de contagem e inclusão do mesmo nesse Manual.


A fronteira da aplicação deve ser definida de acordo com o escopo do projeto/sistema. Na prática, a SEFAZ estabelece que cada projeto/sistema é uma fronteira já que é responsável por manter os dados do seu negócio.Exemplo: O projeto NBP foi desmembrado em 5 novos projetos: NBPG, NBPP, NBPA, NBPI e NBPS. Cada um desses projetos possui um escopo, portanto, cada um deles será considerado como uma fronteira independente.

NOTA:

FUNÇÕES DE DADOS

A informação de CNPJ é dividida fisicamente em 3 campos: num_cnpj_base, num_cnpj_filial, dig_cnpj. Quando a aplicação tratar como um campo único, deve-se contar 1 DER apenas. Porém, se a aplicação referenciar os 3 elementos do CNPJ separadamente (para fazer filtragem de consultas, inserção, alteração, etc), deve-se contar 3 DERs.

Tabelas de histórico só devem ser contadas se solicitadas pelo usuário. Para esses casos, contar a tabela como RLR do arquivo de negócio e apenas 1 DER para o conjunto dos campos da tabela de histórico que são uma imagem (cópia) dos campos da tabela original. Para os demais campos “não-repetidos” do histórico, desde que reconhecidos pelo usuário, contar conforme as regras padrão.

Os RLRs são tipicamente representados em um DER (Diagrama de Entidade-Relacionamento) através do relacionamento pai-filho. No entanto, deve-se observar a relevância da entidade filha dentro do negócio. Caso essa entidade seja forte o suficiente (ou seja, não dependa da tabela pai para exibir), deve ser contada como ALI.

Exemplo: Contribuinte e seus Endereços (Dados de Endereço constituem um RLR p/ o DSCAD). Contribuinte e seus Responsáveis (Dados de Responsáveis compõem um novo ALI p/ o DSCAD).

Consolidados dependentes dos dados originais (ou seja, que nunca serão desvinculados dos dados originais) não devem ser considerados funções de dados. Nestes casos, considera-se que as aplicações que os utilizam estão referenciando o(s) arquivo(s) lógico(s) original(is), em vez do consolidado. Já aquele(s) consolidado(s) que se tornam independentes dos dados originais em algum momento (ou seja, que são conservados quando os dados originais são excluídos ou que não precisam ser recalculados quando os dados originais são alterados) ganham status de função de dados (ALI ou AIE);

Estruturas de dados utilizadas para armazenar fórmulas, cálculos ou estruturas de relatórios devem ser contadas como ALI/AIE, desde que reconhecidas pelo usuário e mantidas/consultadas através de processos elementares;

Exemplo: As tabelas regra_acrescimo_moratorio, regra_correcao_monetaria, regra_reducao_multa, regra_beneficio_lei e forma_parcelamento, criadas no intuito de armazenar fórmulas e regras de cálculo do projeto SIGAT, devem ser pontuadas como ALR, visto que as mesmas foram requisitadas pelos gestores.

Controle de Acesso => Independentemente do Sistema de Controle de Acesso utilizado (CDA, CDA WEB, Unifw), deve-se contar sempre um AIE de complexidade funcional


A identificação da fronteira deve ser sempre identificada segundo a visão do negócio. Nessa situação, sugere-se um entendimento com o líder do projeto/sistema.


baixa para os sistemas que efetuam controle de acesso. Além disso, se o sistema possui controle de acesso a dados, deve ser contado um novo ALI para contemplar esses dados de controle;

Exemplo: Se um determinado sistema permitir que os auditores tenham acesso apenas aos dados relacionados à sua unidade, deve-se pontuar um ALI com os dados relacionados ao controle de acesso a dados, além do AIE de complexidade baixa.

Controle de Acesso => Caso o controle de acesso seja feito através de chamada aos componentes ASLIB e ASCAS, o sistema não deve pontuar as funções transacionais de autenticação do usuário e controle de perfil, pois estas são de responsabilidade destes componentes. Da mesma forma, os arquivos lógicos também não devem ser contados.

Dados de negócio ou informações de controle que estão dentro da fronteira da aplicação, mas são mantidos por processos manuais (processos extra-sistema), como scripts SQL elaborados pelos próprios analistas de sistemas, devem ser pontuadas como ALI’s separados, até porque, a qualquer momento, pode-se disponibilizar uma interface no sistema para manter seus dados;

Exemplo: As tabelas “conversao_elemento_despesa”, “conversao_receita” e “conversao_modalidade_aplicacao” do sistema SG (Sicof Gerencial) armazenam a correspondência (de / para) entre dados provenientes de determinadas tabelas básicas deste sistema, cujos conteúdos tenham sido modificados de um exercício para o outro. As tabelas em questão são atualizadas via script pelos analistas, quando solicitado pelo gestor, podendo este consultar os dados através da aplicação. Cada uma destas tabelas deve ser contada como um ALI, totalizando três ALI’s.

Tabelas de Utilização (utilização_sistema) => Não devem ser pontuadas, pois constituem uma solução de implementação adotada pela SEFAZ. No entanto, caso o sistema passe a fornecer consultas com as informações armazenadas nas tabelas de utilização, deve-se pontuá-la como ALI (apenas se o usuário a requisitou e a utiliza para o negócio).

Quando as mudanças estruturais em uma função de dados não implicarem mudança de lógica de processamento nas funções transacionais, estas não devem ser consideradas como alteradas na contagem da manutenção evolutiva.

Exemplo: Foi solicitada a mudança do formato do número do telefone de sete para oito dígitos e do CEP de cinco para oito dígitos. As funções transacionais que exibem esses dados conforme os mesmos são mantidos no grupo lógico. Nesse caso, apenas deve ser contada a mudança na função de dados.

NOTA:

FUNÇÕES DE TRANSAÇÃO

Deve-se considerar um processo elementar para a inserção, outro para a alteração e um terceiro para a exclusão de dados. Nos processos elementares de inserção e alteração dos dados, deve-se contar como DER cada campo que atravessa (entra e sai) a fronteira da aplicação. No processo elementar de exclusão, deve-se apenas considerar um DER para cada elemento de dado que compuser a chave de identificação (PK) do registro excluído,


A “data do sistema” (no disparo de eventos temporais ou batch) não cruza a fronteira da aplicação da aplicação e não deve ser contada.


mais um DER para a capacidade de envio de mensagens e outro para a capacidade de disparar o processo. Caso sejam mostrados dados na tela durante ou após a confirmação da exclusão, estes serão também contados como DER desta.

No caso de relatórios e listagens com montagem dinâmica, ou seja, em que o usuário escolhe em tempo de execução os campos que serão apresentados, a rigor, dever-se-ia pontuar uma SE/CE distinta para cada uma das combinações possíveis entre os campos disponíveis para a montagem. Porém, esta forma de interpretação pode distorcer o tamanho funcional da aplicação e até inviabilizar a pontuação da funcionalidade. A Sefaz determina que a pontuação deste tipo de funcionalidade seja negociada caso a caso.

5.3. SITUAÇÕES ESPECIAIS

Situação 1 – Processos Elementares (PEs) Separados (Ex.: Consultas Externas) Participando de Outros PEs:

Para cálculo da complexidade de qualquer tipo de funcionalidade, seja EE, CE ou SE, valem as seguintes afirmações:

Não serão contados ALRs nem DERs referentes a PEs separados (CEs correspondentes a combo boxes ou list boxes);

Serão contados os DER’s referentes aos campos que existem por causa da necessidade de relacionamento com outro ALR.

Caso I (Combo Box ou List Box):

Um ALR associado a um combo box ou list box só deve ser contado em uma funcionalidade se, durante o PE, for atualizado ou houver consulta a algum dado seu que não seja exibido pelo combo ou list.

Se o combo ou list for usado apenas para listar os elementos do domínio de um campo, o ALR associado e o dado exibido pelo combo ou list não devem ser contados na funcionalidade. Entretanto, deve-se contar o campo-chave desse ALR, caso este seja requerido pelo usuário para estabelecer um relacionamento com outro ALR.

Ex: Numa funcionalidade de cadastro de municípios, havendo um combo box que exibe os nomes das UFs (Unidades da Federação), deve-se contar o código de UF (campo-chave do ALR associado ao combo de UF), pelo fato deste ser necessário para relacionar o município com sua respectiva UF). Já o ALR de UF e seu nome exibido no combo não serão contados por fazerem parte de um PE separado (CE).

Caso II (Label ou Text Box):

Por outro lado, caso se utilize, em lugar de um combo box, um label ou text box para exibir o dado, deve-se contar o ALR envolvido e, como DER, o dado exibido, pois, neste caso, a própria funcionalidade sendo pontuada terá que buscar o dado no ALR e exibi-lo para o usuário.



Ex: Numa funcionalidade de cadastro de ordens de serviço, havendo um label ou text box para exibir o nome da unidade à qual a ordem de serviço está ligada, deve-se contar o campo de nome da unidade e o ALR unidade.

Situação 2 - Exclusão Múltipla de Registros com Consulta Prévia:

O processo de exclusão múltipla não será contado numa situação em que um sistema ofereça o recurso de exclusão múltipla de registros selecionados em um grid de dados e exiba previamente uma tela de consulta dos registros a serem excluídos, desde que esta tela de consulta seja igual à tela de busca para carga do grid, pois, na verdade, o processo configuraria uma combinação de dois outros processos pontuados separadamente: a consulta prévia dos dados a serem excluídos e a execução repetida de exclusões individuais (de um só registro).

Ex: Na tela abaixo, é possível excluir vários registros do grid de uma vez. Se antes da exclusão uma tela de consulta com informações idênticas for exibida, o processo de exclusão múltipla não é contado.

Situação 3 - ALRs Usados para Garantia de Integridade Referencial:

ALRs usados para tratar integridades referenciais (via trigger ou FK) serão contados como parte do PE pontuado. Sendo assim, numa inclusão, contar-se-á os ALRs que necessariamente precisam ser lidos para garantir a consistência da informação alimentada pelo usuário; numa exclusão, contar-se-á aqueles ALRs acessados para impedir a exclusão de registros com informações relacionadas.

8.1. ELEMENTOS DE INTERFACE

BOTÕES DE RÁDIO

Caso representem dados lógicos, devem ser considerados DER. Deve ser considerado um DER por conjunto, considerando o processo elementar.

CHECK LIST

Deve ser contado UM DER para cada caixa, considerando o processo elementar, desde que as caixas representem informações distintas. Caso o conjunto represente ocorrências da mesma informação, apenas um DER deve ser contado.

Exemplo: Se numa tela existe um campo que indica o mês e 31 check boxes que podem ser selecionados (um para cada dia do mês), apenas um DER é contado.

COMBO BOX

Devem ser considerados como CE os combos que recuperam dados de arquivos lógicos do sistema.

TREE VIEW

Devem ser consideradas como CE as tree views que recuperam dados de arquivos lógicos do sistema. Para casos em que existam diversas folhas, deve ser considerada uma CE para cada nível da árvore.



8.2. SISTEMAS OU APLICATIVOS DE APOIO

8.2.1. PROD

O PROD é a composição de funcionalidades de diversos sistemas. Assim, cada sistema que possuir funcionalidades existentes no PROD deverá considerá-las como parte integrante da contagem.



6.ORIENTAÇÕES GERAIS PARA MEDIÇÃO DE PROJETOS

Essa seção estabelece regras e premissas para contagem de projetos tendo como base três possíveis cenários de desenvolvimento de projetos de sistemas na SEFAZ: Projeto com entrega única, projeto com entregas modularizadas e projeto com mudanças em requisitos ou artefatos.

Fator Redutor

Em qualquer dos cenários previstos, seja para projetos de desenvolvimento ou para projetos de melhoria, as alterações em requisitos ou artefatos já aprovados e entregues devem ser cobertas por um conjunto de redutores que serão aplicados sobre as funções já construídas e que foram alteradas ou excluídas, conforme a tabela a seguir:

Tipo de Ação RedutorFunções incluídas (novas) 100%Funções alteradas 50%Funções excluídas 25%

Cenário 1 – Projeto com entrega única

O primeiro cenário a ser analisado aborda um projeto de desenvolvimento/manutenção de sistema com escopo pré-definido e entrega única, ou seja, todos os requisitos solicitados e aprovados deverão ser entregues em conjunto, ao final do projeto. Entende-se que nessa situação não haverá registros de solicitação de mudança ao longo do projeto.

Como pode ser visualizado na tabela abaixo, todo o projeto foi estimado em 20 PF e foi concluído com a mesma quantidade de pontos, ratificando que não houve mudanças.

Tabela de contagem de entrega única

Nessa situação, o processo de contagem adotado é o padrão IFPUG, sem ressalvas. Caso haja identificação de itens não mensuráveis, estes devem ser medidos conforme a seção Itens não mensuráveis deste manual.

Cenário 2 – Projeto com entregas modularizadas

Devido ao seu tamanho e complexidade, um projeto pode ser negociado para ser especificado e entregue em módulos/pacotes. Nesse caso, surgem dúvidas quando a contagem das funções de dados (ALIs e AIEs). A principal questão a ser esclarecida é que apesar de o projeto ser



especificado por módulos/pacotes, a fronteira do sistema permanece a mesma. Dessa forma, as seguintes regras devem ser atendidas na contagem:

Um ALI ou AIE que foi identificado e contado em um dado módulo, não deve ser contado novamente no módulo seguinte, salvo se a função de dados sofrer alguma alteração;

Caso a função de dados tenha sofrido alguma das alterações, abaixo, deve-se contar a função de dados pelo padrão IFPUG e, em seguida, aplicar o fator redutor.

o Inclusão de novo campo;o Exclusão de campo;o Alteração das características de um campo, como: nulidade, tamanho e tipo.

Um ALI que foi contado em determinado módulo não deve ser considerado um AIE no módulo seguinte.

Tabela de contagem de entrega em módulos

Como exemplo, a tabela acima apresenta um projeto estimado em 42 PF e planejado para ser executado em 3 módulos. O módulo 1 é o primeiro a contemplar a função de dados Disciplina, pontuada como um ALI com 7 PF. O módulo 2, por sua vez, também pontua a função de dados Disciplina porque já havia sido previsto no planejamento do projeto a necessidade de incluir 3 novos DER nessa fase. A alteração gerou uma mudança na complexidade da função de dados de Baixa para Média. Logo, o ALI Disciplina passou a ter 10 PF. Diante desse cenário, entende-se que não é correto aplicar o PF “cheio” do arquivo modificado já que o esforço para sua criação já foi considerado no módulo 1. Nesse caso, o que deve ser levando em consideração é o esforço de manutenção que é menor que o esforço de criação. Por consequência, deve-se aplicar o fator redutor de alteração de 50% sobre o PF total da função de dados, ou seja:

PF = 10 PF x 50% Nota 1 = 5,0 PF

Nota 1: 50% é o percentual a ser aplicado sobre o tamanho da função alterada, conforme fator redutor.

Quanto às funções transacionais, as mesmas regras aplicadas às funções de dados deverão ser aplicadas quando estas forem criadas em um dado módulo e precisarem ser modificadas em módulos subsequentes.



Cenário 3 – Projeto com mudanças em requisitos ou artefatos

A princípio, um projeto pode sofrer, ao longo do seu desenvolvimento, mudanças nos seus requisitos ou nos artefatos já aprovados e entregues. Por esse motivo, são identificadas três possíveis justificativas para essas alterações:

1. Necessidade de alteração de artefato na fase em execução;2. Necessidade de alteração de artefato já aprovado em fases anteriores por causa de

baixa qualidade;3. Necessidade de alteração de artefato aprovado em fases anteriores em virtude de

mudança de requisitos.

A primeira situação, apesar de gerar uma alteração em um artefato, não deve ser considerada como uma mudança, já que a fase já deve prever o esforço necessário para qualquer alteração em artefatos produzidos nela mesma.

A segunda situação deve ser tratada como um Refinamento, por corresponder a uma alteração em um artefato já aprovado em fases anteriores, mas que por motivos de necessidade de ajuste para melhorar a qualidade, precisará ser novamente manipulado.

Por premissa, a SEFAZ entende que o conceito de Refinamento se encaixa, mas não se limita às situações abaixo:

Necessidade de compatibilizar a estrutura de algum artefato do projeto com os modelos pré-definidos pela GQS, por omissão ou esquecimento do fornecedor;

Necessidade de atualizar o conteúdo de algum artefato para aplicar ou eliminar referências a requisitos, regras de negócio, diagramas, interfaces, modelos de dados, tabelas ou atributos inexistentes ou faltantes, quando isso poderia ter sido facilmente detectado na fase de criação do referido documento;

Necessidade de compatibilizar regras de negócio, tipo, tamanho ou obrigatoriedade dos dados entre as interfaces, diagramas, modelos de dados e o esquema do banco de dados a cada fase avançada quando estes poderiam ter sido facilmente detectados na fase anterior;

Necessidade de eliminar inconsistências nas regras de validação de atributos (especialmente validação cruzada do tipo "o atributo "x" é obrigatório se...") nos casos em que a análise da especificação (regras de negócio) permita determinar a existência de um erro ou incompatibilidade entre os requisitos fornecidos, por omissão ou esquecimento do fornecedor.

Como regra geral para identificação de mudanças para Refinamento, os problemas encontrados devem ser reportados o mais cedo possível e deve-se evitar iniciar a implementação antes de elucidar e corrigir os erros que surjam como contradição ou omissão na especificação e que impeçam a implementação correta da funcionalidade na ausência da informação faltante.

A terceira situação trata a necessidade da alteração de artefatos já aprovados em virtude de um requisito modificado após a finalização de uma fase. Esse caso deve ser tratado como um Retrabalho, pois se entende que um esforço adicional torna-se necessário para atender uma mudança em um escopo já definido e aprovado.

Em resumo, a SEFAZ adota a prerrogativa de que: Mudanças de natureza Refinamento não devem ser pontuadas. Mudanças de natureza Retrabalho devem ser pontuadas conforme as regras definidas

nesse manual.



A pontuação será realizada segundo as regras do IFPUG e regras definidas nesse documento:

As demandas de mudança de requisitos devem ser contadas à parte da contagem do projeto de desenvolvimento ou de manutenção e devem considerar as funcionalidades antes da mudança;

A quantidade de PF apurada deve levar em conta o esforço já realizado no processo de desenvolvimento da funcionalidade até o momento da solicitação de mudança. Nos projetos onde exista o gerenciamento e o acompanhamento do seu progresso, é preciso aplicar, na fórmula do cálculo do PF, o percentual das atividades concluídas das fases do processo de desenvolvimento até o momento da identificação da mudança. Nos projetos sem gerenciamento do seu progresso, é preciso aplicar o percentual das fases concluídas, segundo a distribuição de esforço definida em contrato.

As mudanças que não tragam impacto aos requisitos originais do projeto, caracterizadas pelo acréscimo de funcionalidades ao escopo do projeto de desenvolvimento ou de manutenção, serão acrescentadas na contagem de PF do projeto e não geram contagem de PF de mudança, ou seja, representam um trabalho adicional e não retrabalho.

Exemplo: Alteração de requisitos

No início da homologação foram solicitadas mudanças nos requisitos da EE e da CE, sendo que a complexidade da CE passou a ser média (4 PF) após a mudança. Nesta situação hipotética, a contagem de PF_SM será a seguinte:

• EE original: 6 PF• CE original: 3 PF• PF_SM = (6 PF + 3 PF) x 50%Nota 1 = 4,5 PF• PF_SM = 4,5 PF x 90%Nota 2

• PF_SM = 4,05 PF

Nota 1: 50% é o percentual a ser aplicado sobre o tamanho da função original antes da sua alteração, conforme apresentado na Tabela 10.

Nota 2: No contexto do exemplo e usando a distribuição de esforço da Tabela 7, o projetona fase de testes (a última fase concluída antes da fase de homologação) registraprogresso de 90%. Assim, para fins de gestão e faturamento, o valor doPF_SM seria o correspondente a: 4,5 PF * 90% = 4,05 PF “cheios”.

NOTA:


O PF da Solicitação de Mudança apenas irá refletir no PF total do projeto nos próximos momentos de contagem.


7.PRAZO PARA CONTAGEM

Para realização das contagens, estima-se 1,5 dias para cada 100 PF:

Exemplo:Total de PF Prazo (em dias úteis)Até 100 1,5Até 200 3Até 300 4,5Até 400 6,0Até 500 7,5

8.GLOSSÁRIO

Fator redutorCorresponde a um valor percentual a ser aplicado sobre o valor do ponto de função com a intenção de adequar o esforço necessário para a realização de uma melhoria. A aplicação do fator redutor deve sempre estar associada à existência de uma solicitação de mudança.

RefinamentoSituação de alteração em artefatos, em qualquer fase do desenvolvimento/manutenção, que não deve gerar remuneração adicional ao total de pontos de função.

Exemplo: Erros (falha), requisitos mal especificados, etc.

RetrabalhoSituação de alteração em artefatos, em fases do desenvolvimento/manutenção já aprovadas, que deve gerar remuneração adicional ao total de pontos de função através da aplicação do fator redutor.

Exemplo: Melhorias não previstas anteriormente, Alterações do escopo/requisito (mensurável ou não mensurável) etc.


manual de procedimentos v1.0 - sefaz.ba :: … · web viewmanual de anÁlise de pontos de funÇÃo...

Documents