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



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

PARTICULARIDADES DO AMBIENTE SEFAZ

Particularidades referentes ao ambiente SEFAZ devem ser tratadas da seguinte maneira:




  • 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 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.




  • 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).



6.PONTUAÇÃO DAS FUNÇÕES TIPO TRANSAÇÃO


As funções do tipo Transação representam a funcionalidade fornecida ao usuário para o processamento de dados através de uma aplicação. As funções do tipo Transação estão divididas em:


    • Entradas Externas (EE);

    • Saídas Externas (SE);

    • Consultas Externas (CE).


    1. ENTRADAS EXTERNAS

Uma Entrada Externa (EE) é um processo elementar que processa dados ou informações de controle que vêm de fora da fronteira da aplicação. A intenção principal de uma EE é manter um ou mais ALIs e/ou alterar o comportamento do sistema através de processamento lógico.


REGRAS PARA A IDENTIFICAÇÃO:

Para contar o processo como único, uma das 3 seguintes afirmativas deve se aplicar:



    • O processamento lógico é único e diferente de outros processamentos lógicos executados por outras EEs existentes na aplicação;

    • O conjunto de dados identificado é diferente de outros identificados para outras EEs existentes na aplicação;

    • Os ALIs ou AIEs referenciados são diferentes de outros arquivos referenciados por outras EEs existentes na aplicação.

São exemplos de Entradas Externas:




  • Entrada de dados de negócio armazenados num ALR;

  • Entradas que provêem informações de controle com intuito de alterar o comportamento do sistema;

  • Mensagens de outras aplicações que disparam um tipo de processamento que mantém algum ALI ou altera o comportamento da aplicação pontuada;

  • Múltiplas transações de um mesmo tipo que requerem processamentos únicos e separados;

Exemplo: Vendas à vista e vendas através de cartões de crédito. Cada um desses casos deve ser pontuado como uma EE separada.

  • Funções que permitem ao usuário manter dados;

  • Entrada de dados em lote, disparada automaticamente (eventos temporais de entrada), quando  os dados que serão mantidos nos ALIs de destino atravessarem a fronteira;

Exemplo: Rotina semanal que lê os dados de um arquivo TXT fora da fronteira e atualiza-os em um ou vários ALIs. Os dados de negócio a serem mantidos atravessam a fronteira.

  • Manutenção de qualquer ALR, incluindo help e arquivos de parâmetros.

As seguintes situações não podem ser consideradas Entradas Externas:




  • Referência a dados armazenados em um ALR de uma outra aplicação;

  • Telas de Menus usadas para navegação ou seleção, que não mantenham um ALI;

  • Telas de Login;

  • Chamadas repetidas à mesma função ou transação (a funcionalidade deve ser contada uma única vez por aplicação);

  • “Refresh” ou limpeza de dados em uma tela;

  • Ordenação de dados em uma tela;

Exemplo: Clicar em uma das colunas do grid para ordenar os dados.

  • Processos que mantêm dados de código (code data);

  • Mensagens que necessitam de confirmação do usuário;

Exemplo: Mensagem “Deseja realmente efetuar a exclusão?”.

Exemplo: Dados que são armazenados temporariamente em um local (no dataset, por exemplo) e depois são atualizados em definitivo.

Exemplo: Rotina semanal que consolida dados lidos de vários ALIs e os insere em um repositório para efeito de performance na consulta aos mesmos. Nenhum dado de negócio a ser mantido atravessa a fronteira.



  • Inclusão, alteração ou exclusão de registros filho durante o processo de manutenção do registro pai.

Exemplo: Durante a inclusão de um empregado, os dependentes do mesmo podem ser incluídos, através da opção de inclusão de dependentes do empregado. Esta funcionalidade, contudo, não é um processo elementar, pois não deixa a aplicação em estado consistente após sua execução (a inclusão do empregado ainda não foi completada).

REGRAS PARA A IDENTIFICAÇÃO DE ALRs EM UMA EE:


  • Contar um ALR para cada ALI mantido por um processo elementar;

  • Contar um ALR para cada ALI ou AIE lido durante o processamento da EE;

  • Contar apenas um ALR para cada ALI mantido e lido.



REGRAS PARA A IDENTIFICAÇÃO DE DERs EM UMA EE:


  • Contar um DER para cada campo não repetido e reconhecido pelo usuário que atravessa (entra ou sai) a fronteira da aplicação e é necessário para a execução de um processo elementar;




  • Não contar campos que são recuperados ou derivados pelo processo elementar e armazenados em um ALI, mas não atravessam a fronteira da aplicação;

Exemplo: Armazenando os dados de uma nota fiscal, os valores relacionados a cada item (que aparecem na tela) devem ser contados como DER, mas o valor total calculado, caso seja armazenado, porém não exibido para o usuário, não deve ser contado.




  • Contar um DER para a capacidade de enviar mensagens de resposta para fora da fronteira da aplicação que indiquem erros ocorridos durante o processamento, confirmação de que o processo está completo ou que verifiquem se o processo deve continuar;




  • Contar um DER para a habilidade de especificar a ação a ser tomada pela EE, mesmo que existam múltiplos métodos para invocar a mesma lógica de processamento.



DICA:


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, 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.



NOTA:


A “data do sistema” (no disparo de eventos temporais ou batch) e comandos de disparo dos processos elementares (cliques de botão, mensagens entre objetos,etc.) não cruzam a fronteira da aplicação. A primeira não deve ser contada, mas os últimos, por representarem a habilidade de especificar a ação a ser tomada, devem ser contados como um DER das entradas externas.


1   2   3   4   5   6   7   8   9   10


©principo.org 2016
enviar mensagem

    Página principal