Sefaz-ba secretaria da Fazenda do Estado da Bahia sgf superintendência da Gestão Fazendária dti



Baixar 351.96 Kb.
Página4/10
Encontro18.07.2016
Tamanho351.96 Kb.
1   2   3   4   5   6   7   8   9   10

CÁLCULO DOS PONTOS

Após o cálculo do número de DERs e de RLRs de cada arquivo deve-se determinar a complexidade funcional com base na tabela abaixo:







1 a 19 DER

20 a 50 DER

51 ou + DER

1 RLR

Baixa

Baixa

Média

2 a 5 RLR

Baixa

Média

Alta

6 ou + RLR

Média

Alta

Alta

Após a determinação da complexidade funcional, determinar a contribuição do ALI/AIE no cálculo dos pontos de acordo com a tabela abaixo:







Peso nos ALI

Peso nos AIE

Baixa

7

5

Média

10

7

Alta

15

10


    1. PRÁTICAS DE CONTAGEM



Dados de Código (Code data)
Dados de código são grupos de dados criados para satisfazer requisitos técnicos (normalização, performance, etc) e geralmente não são requisitados diretamente pelo usuário, apesar de poderem sofrer manutenção na aplicação. Eles não devem ser considerados funções de dados, assim como as funcionalidades que os mantêm não devem ser consideradas funções de transação.
Alguns exemplos são listados abaixo:


  • Dados de substituição: Tabela do tipo “código-descrição” ou de domínio, onde o código poderia ser substituído pela descrição e a tabela eliminada, sem perda de dados de negócio (ex: tipo_contribuinte, contendo cod_tipo, desc_tipo, dt_inicio_vigencia, dt_fim_vigencia, dtc_atualizacao);




  • Tabelas de registro único e/ou dados estáticos: Têm apenas um registro ou tanto o número de registros quanto seus dados raramente mudam (ex: uma tabela contendo dados sobre a SEFAZ);




  • Faixa de valores válidos ou valor padrão para um atributo de negócio (ex: uma tabela que armazena as cores do arco-íris ou a relação das unidades de medida possíveis para um insumo em uma obra).


Dados de referência (Reference Data)
Dados de referência são definidos como dados que são armazenados para suportar regras para a manutenção de dados de negócio. Têm características bastante semelhantes aos dados de código, exceto pelo fato de que não podem ter seu código substituído pela descrição. Eles devem ser considerados funções de dados, assim como as funcionalidades que os mantêm devem ser consideradas funções de transação. Seguem alguns exemplos:


  • Tabelas de domínio que contêm parâmetros de negócio associados (ex: tipo_ciencia, contendo cod_tipo_ciencia, des_tipo_ciencia, num_dias_prazo_envio, des_meio_envio, val_maximo_perc_multa, etc);




  • Tabela contendo a lista de impostos aplicáveis em uma operação comercial, com a relação das alíquotas vigentes em cada período;



Se durante a substituição do código pela descrição e eliminação da tabela houver perda de dados de negócio, então se trata de um dado de referência da aplicação.



Observações sobre a identificação de funções de dados:


  • Arquivos Lógicos Externos à aplicação sendo pontuada não podem constituir RLR de ALIs da aplicação;




  • Tabelas associativas que só contêm as FKs das tabelas relacionadas e dados não reconhecidos pelo usuário não são pontuadas. Por outro lado, se elas contiverem atributos de negócio, afora os citados, podem ser contadas como ALRs ou RLRs de acordo com os seguintes critérios:




    • Conta-se uma associativa como 1 ALR se ela for independente (mantida separadamente) das entidades associadas;




    • Conta-se uma associativa como RLR do arquivo lógico com o qual ela é mantida em conjunto no sistema.




  • No caso de entidades atributivas (entidades “fracas”):




    • Caso a relação entre as entidades seja obrigatória e 1:1, então a entidade atributiva não deve ser pontuada como RLR e seus campos devem ser contados como DERs do ALI correspondente;




    • Caso a relação entre as entidades seja obrigatória, porém 1:N, então a entidade atributiva deve ser contada como um RLR do ALI correspondente;




    • Caso a relação entre as entidades seja opcional, a entidade atributiva deve ser contada como um RLR do ALI correspondente.




      • Arquivos de Auditoria e/ou Histórico => Se não forem requisitados/reconhecidos pelo usuário (ou seja, se não houver forma de consultá-los via sistema), eles não devem ser considerados funções de dado (ALI ou AIE);

Caso sejam requisitos do usuário, devem:



    • Ser contados como RLRs do arquivo original se forem dependentes do mesmo (se seus dados forem excluídos junto com os dados do arquivo correspondente, por exemplo);




    • Ser contados como ALRs se forem independentes do arquivo original (ou seja, caso, ao excluir os dados do arquivo original, ainda assim seja necessário ao negócio conservar os dados do histórico/auditoria).




  • Sobre pontuação de Supertipos e Subtipos (generalização e especialização de entidades):

    • Se os subtipos tiverem força suficiente para serem subgrupos de dados (existem dados de negócio sobre eles), serão contados no ALI/AIE tantos RLRs quantos forem seus subtipos. Exemplo: A entidade “Empregado” possui as seguintes especializações: “Permanente” e “Contratado”. Existem dados de negócios específicos de ambos. Temos então 1 ALI Empregado com 2 RLRs;




    • Se os subtipos não tiverem força para serem subgrupos (só existe uma informação sobre cada um deles), os subgrupos não serão considerados RLRs. Exemplo: Um empregado pode ser “Solteiro” ou “Casado”. Se não houver mais dados específicos sobre cada um dos possíveis estados civis, não há dois subgrupos de dados, e sim apenas um dado sobre o estado civil de um empregado. Portanto, o ALI Empregado teria 1 RLR.




  • Tabelas que representam apenas um domínio de dados (código, descrição e demais atributos de cunho meramente técnico) não devem ser consideradas ALI/AIE (mas sim code data). Porém, se o usuário requisitar “parametrizar” este domínio, associando a ele atributos de negócio, então estas tabelas tornam-se dados de referência, devendo ser contadas como ALI/AIE;




  • Tabelas criadas para armazenar mensagens ou dados técnicos referentes a erros do sistema não devem ser consideradas funções de dado (mas sim code data);




  • Tabelas que armazenam faixas de valores válidos para os atributos de negócio(ex: tabela de UF), tabelas que contêm apenas 1 registro ou valores padrão de atributos de negócio não devem ser consideradas funções de dado (mas sim code data);




  • Consolidados dependentes dos dados originais (ou seja, que nunca serão desvinculados dos dados originais) não devem ser considerados funções de dado. 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á aqueles consolidados 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 dado (ALI ou AIE);




  • Mesmo que uma aplicação que estiver sendo pontuada utilize apenas código e descrição de uma entidade que seja externa à sua fronteira e que contenha dados adicionais (de negócio ou referência), esta entidade será considerada AIE para a aplicação em foco.

Exemplo: O ALI atendente_campanha do PA relaciona-se com a entidade servidor do SERV, mas só utiliza o nome do servidor em suas telas. Mesmo assim, servidor é um AIE para o PA (e não um code data), pois contém outros dados de negócio ou referência no SERV, revelando sua importância como grupo de dados reconhecido pelo seu usuário.




  • Por outro lado, se um arquivo de uma aplicação que estiver sendo pontuada se relacionar com uma entidade que seja externa à sua fronteira e que contenha apenas código e descrição (isto é, seja code data), então esta entidade também será considerada code data para a aplicação em foco.

Exemplo: O ALI solicitacao_senha_contrb_nao_inscrito do PA relaciona-se com a entidade tipo_logradouro (cod_tipo_logradouro e des_tipo_logradouro) do DSCAD. Tipo_logradouro é um mero dado de substituição (ou code data) para o DSCAD, pois não contém nenhum dado de negócio ou referência. Por conseguinte, é também um code data para o PA.





  • Campos de status ou data de desativação (timestamp):

    • Caso o usuário requisite que os dados da aplicação não sejam excluídos fisicamente, mas sim logicamente, o campo de status ou de data de desativação utilizado para “desativar logicamente” os dados deve ser contado como DER dos ALRs e das funções de transação, mesmo que não atravesse a fronteira;




    • Caso o campo de status ou de data de desativação seja criado pela equipe de implementação, por motivo de segurança de dados, sem o conhecimento e requisição do usuário, não deve ser contado como DER, mesmo que atravesse a fronteira.

A tabela a seguir ilustra um sumário para as regras de contagem de arquivos lógicos:




Tipo de relacionamento entre duas entidades A e B

Quando esta condição existir

Conte os ALRs com seus RLRs e DERs conforme abaixo:

(1):(N)

A e B são independentes

2 ALRs e os RLRs e DERs de cada um

1:N

B é dependente de A

1 ALR, 2 RLRs e os DERs

B é independente de A

2 ALRs e os RLRs e DERs de cada um

1:(N)

B é dependente de A

1 ALR, 2 RLRs e os DERs

B é independente de A

2 ALRs e os RLRs e DERs de cada um

(1):N

A é dependente de B

1 ALR, 2 RLRs e os DERs

A é independente de B

2 ALRs e os RLRs e DERs de cada um

(1) : (1)

A e B são independentes

2 ALRs e os RLRs e DERs de cada um

1:1

A e B são dependentes

1 ALR, 1 RLR e os DERs

1: (1)

B é dependente de A

1 ALR, 1 ou 2 RLRs e os DERs

B é independente de A

2 ALRs e os RLRs e DERs de cada um

(N) : (M)

A e B são independentes

2 ALRs e os RLRs e DERs de cada um

N:M

B é dependente de A

1 ALR, 2 RLRs e os DERs

B é independente de A

2 ALRs e os RLRs e DERs de cada um

N : (M)

B é dependente de A

1 ALR, 2 RLRs e os DERs

B é independente de A

2 ALRs e os RLRs e DERs de cada um


() = relacionamento opcional

1   2   3   4   5   6   7   8   9   10


©principo.org 2016
enviar mensagem

    Página principal