gestores de sistemas - sefaz.ba :: secretaria da fazenda do … · 2013-10-02 · pontuação de...

CARTILHA

Gestores de Sistemas Versão 01.00.01

Salvador (Ba), maio de 2012

SEFAZ-BA Secretaria da Fazenda do Estado da Bahia SGF Superintendência da Gestão Fazendária DTI Diretoria de Tecnologia da Informação GEDES Gerência de Administração de Dados e Desenvolvimento de Sistemas

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

Página 2 _Cartilha dos Gestores de Sistemas 2012

RESUMO

O presente documento contempla papéis e responsabilidades dos gestores de sistemas, incluindo suas atividades, autorizações e demais relacionamentos entre as áreas de negócio e a área de tecnologia.



CONTROLE DE VERSÃO

Versão Data Responsável Histórico

01.00.00 28/11/2011 Equipe AD (Padrões)

1. Liberação da primeira versão.

01.00.01 14/05/2012 Equipe AD (Padrões)

2. Ajuste da Cartilha às atualizações do Manual de Procedimentos Gerais de Sistemas.



INDICE

1. PAPÉIS, RESPONSABILIDADES E BOAS PRÁTICAS .........................................................5

2. DOCUMENTAÇÃO DOS SISTEMAS........................................................................................5

3. COMPOSIÇÃO DO NÚMERO DA VERSÃO DO SISTEMA .................................................5

4. PASSOS PARA ELABORAÇÃO DA AJUDA DO SISTEMA..................................................5

5. ELABORAÇÃO DA ESTRATÉGIA DA HOMOLOGAÇÃO E ROTEIRO D E TESTES DE HOMOLOGAÇÃO ................................................................................................................................5

5.1 DEFINIÇÃO DAS ESTRATÉGIAS E HOMOLOGAÇÃO DO SISTEMA.. ......................5

5.2 ELABORAÇÃO DO ROTEIRO DE TESTES DE HOMOLOGAÇÃO ..... .........................5



1. PAPÉIS, RESPONSABILIDADES e BOAS PRÁTICAS

PROCEDIMENTO GERAL DE SISTEMA

PAPEL E RESPONSABILIDADE DO GESTOR DE SISTEMA

BOAS PRÁTICAS

Solicitação de Sistemas Definir suas necessidades, seja de um sistema novo, ou de uma nova versão, descrevendo seu objetivo, identificando as funcionalidades, as integrações, os cadastramentos, as consultas / relatórios e o controle de acesso.

Submeter uma consulta a AGE / Corregedoria para verificar a necessidade de inclusão de algum controle específico no projeto.

Liberação de Versão – Instalação de infra-estrutura (primeira versão ou piloto)

Definir os perfis de acesso, que serão criados pelo analista no Controle de Acesso (CDA) e/ou no SEFCOM, após a criação das pastas do projeto. Associar os usuários no Controle de Acesso (CDA) e/ou no SEFCOM aos seus respectivos grupos/perfis de acesso.

Liberação de Versão – Planejamento da distribuição (primeira versão ou piloto)

Selecionar, juntamente com o analista SEFAZ, a(s) unidade(s) que será(ão) utilizada(s) como Piloto, bem como quem serão os usuários Fazer, juntamente com o líder SEFAZ, o planejamento para distribuição do sistema nas devidas unidades. Neste planejamento, deve ser definido um cronograma com responsáveis, data e local para implantação. Comunicar às unidades em questão sobre este planejamento, retornando para todos os envolvidos (GEAUS, Analista,...) uma

Planejar a melhor forma de liberar as pendências de alteração do projeto, juntando correções com melhorias ou necessidade de alterações e inclusão de funcionalidades, observando ainda se essa mudança é significativa ao ponto de alterar o nº da versão principal do sistema. Essa é uma estratégia de marketing do projeto que deve ser definida junto com o gestor. Veja melhor sobre a numeração das versões no item 3. Composição do Número da Versão do Sistema. Nesse planejamento levar em consideração os custos e benefícios de definir prazos curtos para implantação de versão, visto que para cumprir esse planejamento, podem estar sendo encurtadas ou adiadas algumas atividades podendo implicar a implantação da



confirmação com data, horário e a pessoa a ser contatada na respectiva unidade.

Liberação de Versão – Disponibilização do pacote de instalação/ atualização

Em Homologação Ser informado quando a versão estiver disponível para homologação, e/ou se ainda houver alguma pendência. Autorizar, através do correio eletrônico, a execução da liberação de versão, fora do horário estabelecido que é: até as 08:30 h, de 12:00 às 13:30 h e após as 18:00 h. Em Produção Enviar um correio dando o OK referente à homologação da versão XX.YY.ZZ. Ser informado quando a versão estiver disponível para produção, e/ou se ainda houver alguma pendência da implantação da versão. Autorizar, através do correio eletrônico, a execução da liberação de versão, fora do horário estabelecido que é: até as 08:30 h e após as 18:00 h.

versão com erros e consequentemente a necessidade de geração de sucessivas versões corretivas. Ao dar o OK da homologação de uma determinada versão é fundamental que esteja explicitado no correio que esse OK se refere a uma determinada versão XX.YY.ZZ. É importante também que não haja ressalvas na homologação. Autorizar a liberação de versão fora do horário definido pode impactar outras aplicações. Caso ocorra algum problema na atualização da versão, é preciso que haja uma janela para se tentar reverter esse problema. Existe uma probabilidade maior de existirem arquivos bloqueados ao tentar atualizar o que impossibilitaria a atualização.

Validação de documentação Validar o documento disponibilizado em: I:\Gedes_Validacao_Documentacao_Sistemas \ EQUIPE \ PROJETO \ Versao_XX_YY_ZZ \ TIPO_ARTEFATO, que nunca deve ser anexado ao chamado de validação. Os documentos de uma versão de um projeto, desde que já validados por todos os validadores, serão publicados pela AD em I:\Gedes_Documentacao_Sistemas \ EQUIPE \ PROJETO \ Versao_XX_YY_ZZ \

Nunca validar documentos anexados no correio eletrônico, em vez de disponibilizado em: I:\Gedes_Validacao_Documentacao_Sistemas \ EQUIPE \ PROJETO \ Versao_XX_YY_ZZ \ TIPO_ARTEFATO. Dessa forma, evita-se que o gestor valide um documento diferente daquele que será validado por outros validadores ou daquele que será publicado.



TIPO_ARTEFATO, sempre que a versão for colocada em produção. Veja no item 2. Documentação dos Sistemas, a relação dos artefatos gerados para um sistema e quem os elabora ou valida.

Os documentos devem ser validados de forma criteriosa, sempre verificando se consta tudo o que foi definido em reunião com o analista.

Validação de protótipos Validar o protótipo para garantir que todas as informações e funcionalidades solicitadas estejam contempladas.

Efetuar o batimento do protótipo com o que foi solicitado no Detalhamento de Requisitos. Essa validação poderá ser feita através de uma reunião, devendo envolver o analista, a Equipe AD e a GERAT quando necessário, podendo sair dessa reunião com o protótipo validado por todos os validadores.

Interação com a GERAT Não é papel do Gestor. Cabe à Administração de Dados, enquanto equipe de padrões de interface, intermediar o relacionamento dos analistas SEFAZ com a GERAT (Webdesign).

Qualquer necessidade relacionada a imagem, logomarca, criação de links deve ser sinalizada para os analistas, que irão buscar essa interação com a GERAT através da AD. Dessa forma, teremos todas as ações relacionadas à imagem da SEFAZ passando também pela área de padrões de interface que fica na GEPIN-AD.

Pontuação de sistemas Não é papel do Gestor. Cabe à Administração de Dados, juntamente com o analista do projeto, pontuar os projetos fábrica. A pontuação só ocorre para projetos fábrica pois essa é a forma de alinhar os preços dos serviços feitos na fábrica. Só ocorre a pontuação após o modelo de dados e o protótipo estarem validados.

Informativo / avaliação de impacto Responder uma Avaliação de Impacto / Informativo , sempre que consultado pelos líderes / analistas SEFAZ.

Nunca responder uma Avaliação de Impacto / Informativo , apenas a partir da mensagem original encaminhada pela AD, visto que esta



Sempre que ocorre alterações estruturais ou manipulação de dados diretamente no banco em tabelas compartilhadas, é disparada uma avaliação de impacto / informativo, para ser respondida pelos líderes SEFAZ. Cabe ao líder consultar os Gestores. O gestor sempre que achar necessário deve solicitar ao líder/analista do seu projeto maiores explicações para poder efetuar uma avaliação mais acertada.

tem uma linguagem própria para a avaliação técnica da equipe do projeto e não uma linguagem de negócio. É uma boa prática chamar o analista do projeto para uma conversa pessoalmente.

Liberação de um novo sistema/ serviço

Enviar previamente uma Rotina de Atendimento (perguntas e respostas mais freqüentes) para o Call Center.

Envolver a GEAPE desde a percepção de que o sistema será usado por usuários externos.

Sistemas mainframe Definir os níveis de acesso à nova rotina. Delegar os acessos aos respectivos usuários usando a aplicação XF74 (Atualização de Senha)

Atualização do portfólio Conferir se estão corretos os dados do projeto que estão publicados no portfólio e cobrar que sejam atualizados sempre que necessário. Informar a necessidade ou não de publicar as informações do projeto no portfólio.

Elaboração da Ajuda do Sistema Elaborar o Ajuda do sistema em substituição ao Manual do usuário, devendo ser utilizada a ferramenta Microsoft Word e podendo seguir os passos descritos no item 4. Passos para Elaboração de Help

Torna os usuários mais independentes

Execução da homologação

Planejar o processo de homologação conforme item 5. Elaboração de Estratégia de Homologação e Roteiro de Testes da Homologação Gerar os resultados da homologação, os quais

Fundamental para uma implantação de versão mais eficaz. Deve ser feita mesmo para pequenas alterações.



serão avaliados pelo Analista SEFAZ. Aprovar a versão do sistema, caso o resultado da Homologação seja OK. E nesse caso, deve-se solicitar que seja iniciada a fase de implantação em produção. Caso o projeto seja desenvolvido em fábrica esse resultado implica a aceitação do produto, e, conseqüentemente, deve ser gerado um Laudo de Inspeção: • Laudo da Homologação do Sistema

– ASSINATURA: GESTOR

Não se deve parar a homologação a cada erro encontrado, exceto se não for possível continuar. Ao final do processo de homologação devem se reportados todos os problemas.

Estratégia de limpeza de registros inativos

Definir o tempo de retenção dos dados nas tabelas, principalmente naquelas onde já se espera que terá uma grande quantidade de registros, para poder se estabelecer a estratégia de limpeza das mesmas.

Seguir orientação prevista na legislação, mas não deixar de pensar na estratégia de limpeza das mesmas. Não ocorrerá a limpeza física, os registros deixarão de ficar disponíveis. Deve-se pensar naquelas informações que não precisam estar sempre disponíveis.

Exclusão de sistemas Autorizar a exclusão de um sistema. (Pode ser substituído pelo Gerente ou Diretor da área referente ao sistema) Se gestor do PSS, deverá receber solicitação de exclusão no PSS. Autorizar as exclusões das estruturas do banco após realização de avaliação de impacto.

Antes de desativar o sistema no ASA definitivamente, ou seja, a partir do momento em que se inicia o processo de desativação do sistema, seria interessante que o gestor solicitasse que o projeto fosse suspenso no ASA.

Envio de estruturas e/ou dados para fábrica

Autorizar o envio de estruturas e de dados, caso seja necessário enviar do ambiente de homologação ou produção da SEFAZ. Nesse caso, os gestores envolvidos são aqueles gestores dos projetos proprietários das tabelas que precisarão ter estrutura e dados enviados para a fábrica.

Sempre que necessário, informar também se existe alguma restrição como por exemplo: não enviar os dados de determinados campos, mascarar os dados de alguns campos, não enviar rotinas com determinadas regras de negócio, etc.



Caso a responsabilidade pelo sistema não caiba mais ao(s) Gestor(es), será necessário obter a autorização do Gerente ou Diretor da área associada ao sistema e anexá-la ao chamado de cópia dos dados.

Sincronização de ambientes Após ser comunicado do agendamento desse processo, que ocorre de três em três meses, deve informar caso haja alguma impossibilidade para sua realização na data prevista. Se estiver homologando, é importante sinalizar a necessidade ou não de guarda e recuperação dos dados que estão sendo homologados.

Apesar da indisponibilidade temporária do ambiente de homologação e de alguns transtornos momentâneos, esse processo é importante para permitir um ambiente de homologação mais robusto e próximo do ambiente de produção.

Mudança de gestor do sistema O novo gestor deve: • Enviar um correio para o gestor do CDA

ou para _Suporte AS solicitando acesso ao CDA como usuário gestor;

• Enviar um correio para o gestor atual solicitando acesso como gestor do Sistema;

• Enviar um correio para _Atendimento ao Usuario - DTI/GEAUS solicitando a inclusão do novo gestor no grupo _Gestor Sistema e a exclusão do gestor antigo. (esse correio pode ser enviado também pelo analista).

Atualização de dados em Produção

Autorizar previamente de forma expressa e escrita através de correio eletrônico. Essa autorização deve ter o máximo de clareza e especificidade, informando todas as operações a serem executadas e o escopo dos dados a serem atualizados, para que a equipe

Deve –se evitar essas manipulações de dados executadas diretamente no banco de dados, pois elas podem trazer inconsistências para os dados do projeto além de impactar integrações com outros projetos, dentre eles o DW.



AD possa avaliar se a atualização enviada pelo analista condiz com a autorização do Gestor. Será devolvido para o analista todo chamado em que não houver clara correspondência entre a atualização e a autorização do Gestor. Essa autorização será armazenada pela equipe AD nas pastas públicas do correio eletrônico para futuras consultas. O responsável por autorizar manipulação de dados em tabelas de atualização compartilhada será o gestor do projeto proprietário do dado, mas o gestor do projeto proprietário da tabela deve ter ciência sendo copiado na solicitação: - quando forem compartilhados conjuntos de registros distintos, esse proprietário será identificado pelo campo cod_projeto. - quando existirem campos pertencentes a projetos distintos, esse proprietário será identificado através de um cadastro que será feito previamente.

Sempre que não for possível executar alguma manipulação de dados pelo sistema é desejável que se coloque como pendência de alteração para próxima versão o desenvolvimento de uma funcionalidade que venha suprir essa necessidade. Nunca autorizar uma solicitação do analista para atualizar dados em Produção que não esteja com o máximo de clareza e especificidade. Na solicitação deve ser informada todas as operações a serem executadas e o escopo dos dados a ser atualizado. Isso ajuda também a equipe AD a avaliar se a atualização solicitada pelo analista condiz com a autorização do Gestor.



2. DOCUMENTAÇÃO DOS SISTEMAS

Fase: Especificação Artefato Elaboração Validação Laudo Observação Solicitação de Sistemas

Gestor Não se aplica Não se aplica Documento inicial onde o gestor define suas necessidades.

Detalhamento de Requisitos

Analista SEFAZ • Gestor – Conteúdo

• Analista AD –

Padrão e Técnica

• Rubrica – Analista AD / Analista SEFAZ

• Assinatura – Coordenador AD / Coordenador SEFAZ

Documento Obrigatório para liberação de versão adaptativa em homologação

Relatório de Análise de Riscos


• Coordenador

SEFAZ – Conteúdo

• Analista AD –

Padrão e Técnica


• Assinatura – Coordenador AD / Coordenador SEFAZ

Documento que deve ser usado nas reuniões de acompanhamento.

Fase: Análise Artefato Elaboração Validação Laudo Observação Definição de Ambiente

Analista SEFAZ • INFRA – Conteúdo

• Rubrica – Analista AD / Analista BD / Analista

Pré-requisito para validação de qualquer outro artefato a partir da



Tecnológico • BD – Conteúdo • AS – Conteúdo • Analista AD –

Padrão e Técnica

AS / Analista INFRA • Assinatura –

Coordenador AD / Coordenador SEFAZ

fase de análise.

Protótipo Analista SEFAZ • Analista AD – Padrão e Técnica

• Gestor –

Conteúdo • GERAT –

Padrão / Imagem Externa da SEFAZ


• Assinatura –


Permite uma visão dinâmica do sistema, simulando o funcionamento de telas e relatórios, auxiliando assim a definição de requisitos pelo usuário.

Especificação Técnica de Rotinas

Analista SEFAZ • Analista AD – Padrão e Técnica


• Assinatura –


Só será gerado para contemplar regras técnicas que não devem estar presentes nos documento de Detalhamento de Requisitos.

Roteiro de Testes



• Assinatura –


Documento Obrigatório para liberação de versão adaptativa em homologação.



Fase: Projeto Artefato Elaboração Validação Laudo Observação Relatório de Integração

Analista SEFAZ • Gestor – Conteúdo do quadro resumo das integrações

• Analista

Projetos Envolvidos – Conteúdo das respectivas integrações

• Analista AD –

Padrão e Técnica


• Assinatura –


Ao gestor só interessa o quadro inicial que resume todas as integrações e quais são as informações trocadas entre os sistemas.

Plano de Conversão do Legado


• Analista do

Sistema Legado – Conteúdo

• Analista AD –

Conteúdo, Padrão e


• Assinatura –


Quando necessário e aplicável deve ser elaborado a fim de garantir a aderência dos dados legados a nova estrutura proposta. Este relatório deve conter todas as regras definidas e aplicadas para os dados legados a fim de garantir a sua migração e utilização pelo projeto. A necessidade e aplicabilidade de elaboração desse plano devem ser discutidas e alinhadas com o



Técnica Coordenador de Projeto GEDES, Gestor e equipe AD.

Diagrama de Caso de Uso / Diagrama de Contexto

Analista SEFAZ / Analista FÁBRICA

• Analista SEFAZ – Conteúdo

• Analista AD –

Padrão e Técnica


• Assinatura –


Utilizados para compreender o que sistema faz. Bons instrumentos para trocar informações entre a equipe de desenvolvimento e os usuários.

Diagrama de Classe / Diagrama de Resposta a Eventos



• Analista AD –

Padrão e Técnica


• Assinatura –


Utilizados para registrar informações mais técnicas de como as rotinas irão se comportar, quais serão suas operações, características e relacionamentos.

Diagrama de Entidade e Relacionamento



• Analista AD –

Padrão e Técnica


• Assinatura –


Utilizado para descrever os componentes de dados de um sistema. Fundamental para entender a adequação do sistema ao modelo de dados corporativo.

Dicionário de Dados



• Analista AD –

Padrão e Técnica


• Assinatura –


Utilizado para o registro das definições dos dados em um único lugar, facilitando a consulta.

Especificações Analista FÁBRICA • Analista • Rubrica – Analista AD / Obrigatório apenas para os projetos



de Classe SEFAZ – Conteúdo

• Analista AD –

Padrão e Técnica

Analista SEFAZ • Assinatura –


desenvolvidos em fábrica.

Especificações de Interface


• Analista AD –

Padrão e Técnica


• Assinatura –


Obrigatório apenas para os projetos desenvolvidos em fábrica.

Fase: Homologação Artefato Elaboração Validação Laudo Observação Manual de Sistema


• Rubrica – Analista AD • Assinatura –

Coordenador AD

É uma referência para todos os demais documentos do projeto.

Manual de Operação

Analista SEFAZ • OPERAÇÃO – Conteúdo

• Analista AD –

Padrão e Técnica (Apenas se não for do PROD)

• Rubrica – Analista AD • Assinatura –

Coordenador AD

Deve existir sempre que houver alguma rotina executando separadamente da aplicação. Se for pelo PROD, esse manual é do PROD e não do projeto.



3. COMPOSIÇÃO DO NÚMERO DA VERSÃO DO SISTEMA

O Padrão de numeração de versão é: Onde: � XX indica a versão principal – Esse número deve ser alterado após uma negociação com

o Gestor, visto que tem um cunho comercial. Deve ser mudada quando se deseja fazer um “marketing” do sistema

� YY indica a versão secundária – Esse dígito deve ser alterado nas liberações de versões

evolutivas (inclusão de funcionalidades) ou de versões adaptativas (alteração ou exclusão de funcionalidades ou alteração de estrutura demandada pelo negócio).

� ZZ indica a versão de revisão – Esse dígito deve ser alterado nas liberações de versões

corretivas (correção de erros apresentados na versão) ou de versões de ajustes que não impliquem alteração em nenhuma funcionalidade, sejam eles de tecnologia (questões de ambiente, performance, etc.) ou quaisquer outros (campos estáticos em relatórios, mudança no layout dos campos na tela, alteração de labels, etc.).

NOTA:

Quando for necessário o reenvio de um arquivo (rpt, por exemplo) após a liberação de uma versão, deve-se alterar os dígitos ZZ somente em casos de alteração nesse arquivo (inclusive em casos de mera alteração de UDL para corrigir a referência ao ambiente – desenvolvimento, homologação ou produção).

4. PASSOS PARA ELABORAÇÃO DA AJUDA DO SISTEMA

Para a elaboração da Ajuda do Sistema é necessária a execução dos passos descritos a seguir: 1º Passo: Definir a Estrutura inicial da Ajuda do Sistema, conforme o padrão abaixo:

Sistema XXXXX

o Visão Geral do Sistema o O que há de novo? o Instruções Gerais de Utilização o Funcionalidades (a ser detalhado posteriormente)

2º Passo: Definir o conteúdo do tópico “Visão Geral do Sistema”:

Os subtópicos que compõe o tópico “Visão Geral do Sistema” são:

o Visão Geral do Sistema � Descrição da Sigla do Sistema � Objetivos � Versão

XX.YY.ZZ



� Gestores

Para cada um desses subtópicos deve ser descrito um conteúdo, seguindo as orientações abaixo:

� Descrição da Sigla do Sistema

Esse item deve conter a descrição completa do nome do sistema Exemplo: SIGAT – Sistema Integrado de Gestão da Administração Tributária

� Objetivos Nesse item deve ser descrito, de forma clara e resumida, o(s) objetivo (s) do sistema.

� Versão Esse item deve conter a versão atual do sistema.

� Gestores Nesse item deve ser informado quem é (são) o(s) gestor(es) do sistema, com seu(s) respectivo(s) email(s) de contato.

3º Passo: Definir o conteúdo do tópico “O que há de novo”:

Nesse tópico deve ser descrito o que o sistema disponibiliza de novo, na versão corrente.

Esse tópico é opcional. Caso o sistema já disponibilize as novidades a partir de sua página principal, por exemplo, não é necessário repeti-lo no Help.

4º Passo: Definir o conteúdo do tópico “Instruções Gerais de Utilização”:

Os subtópicos que compõe o tópico “Instruções Gerais de Utilização” são:

o Instruções Gerais de Utilização � Como acessar o sistema � Senha

� Solicitação de senha � Alteração de senha � Esqueci a minha senha

Para cada um desses subtópicos deve ser descrito um conteúdo, seguindo as orientações abaixo:

o Como acessar o sistema

� Nesse item deve ser descrito qual (is) a (s) forma (s) de acesso ao sistema.

Exemplo: O Sistema XYZ pode ser acessado através do link “Sistema XYZ”, disponível na página principal do site da Secretaria da Fazenda do Estado da Bahia (www.sefaz.ba.gov.br). Uma outra forma de acesso ao sistema é através do endereço http://sistemas.sefaz.ba.gpv.br/sistemas/sistemaxyz.

o Senha

� Solicitação de senha Nesse item deve ser descrito como os usuários podem efetuar a solicitação de senha de acesso ao sistema.



Exemplo: Para solicitar uma senha de acesso ao Sistema XYZ deve-se enviar um email para o Gestor informando o login.

� Alteração de senha Nesse item deve ser descrito como os usuários podem efetuar a alteração da senha de acesso ao sistema. Exemplo: Para alterar a senha de acesso ao Sistema XYZ deve-se acessar a opção “Alterar Senha” disponível no Menu do sistema.

� Esqueci minha senha Nesse item deve ser explicada ao usuário a funcionalidade “Esqueci minha Senha”. Exemplo: O Sistema XYZ disponibiliza para seus usuários uma lembrança de senha, a qual funciona da seguinte forma: ao cadastrar sua senha, o usuário deve informar uma palavra que lhe permita lembrar da mesma. Dessa forma, caso o usuário esqueça sua senha corrente, o sistema lhe enviará um email com a palavra cadastrada como lembrança de senha, permitindo ao usuário recordar-se da sua senha.

5º Passo: Definir a estrutura hierárquica do tópico “Funcionalidades”:

Para elaborar a estrutura hierárquica do tópico “Funcionalidades” pode-se utilizar como base a estrutura dos itens de Menu do sistema. A hierarquia deve ser definida na ordem em que deve ser visualizada no Help, não necessariamente a mesma ordem que aparece no menu do sistema.

Exemplo: Menu do Sistema SIGAT-Arrecadação

Hierarquia das funcionalidades com base neste menu:

1. Pendências

1.1 .......... 1.2 ..........

2. Arrecadação



2.1 Agente Arrecadador 2.1.1 Banco 2.1.2 Contrato 2.1.3 Convênio de Arrecadação 2.1.4 Dados Cadastrais 2.1.5 Faturamento

2.2.4.1 Regerar Demonstrativo 2.2.4.2 Verificar Liberação

2.1.6 Movimentos/Arquivos 2.1.6.1 .............. 2.1.6.2 ..............

2.1.7 Notificação 2.1.8 Unidade de Arrecadação

2.2 Documento de Arrecadação 2.2.1 ................ 2.2.2 ................

2.3 Repasse Financeiro 2.3.1 ................ 2.3.2 ................ 2.3.3 ................

2.4 Restituição 2.4.1 ................

2.5 Administração do Sistema 2.5.1 ..............

2.6 Consultas/Relatórios Operacionais 2.6.1 ................ 2.6.2 ................ 2.6.3 ................ 2.6.4 ................

Caso algum desses tópicos da hierarquia não tenha conteúdo definido no help quando o usuário clicar neste tópico vai aparecer o conteúdo do tópico hierarquicamente superior. Exemplo:

Se não for definido o conteúdo no help para o tópico “Contrato” quando o usuário selecionar esta opção no help vai aparecer para ele o conteúdo do tópico “Agente Arrecadador” porque este é o tópico hierarquicamente superior a “Contrato”.

Com base nos exemplos utilizados neste documento o Help completo do sistema ficaria com a seguinte estrutura: Sistema SIGAT-Arrecadação

• Visão Geral do Sistema • O que há de novo? • Instruções Gerais de Utilização • Funcionalidades

1. Pendências 1.1.......... 1.2..........

2. Arrecadação 2.1 Agente Arrecadador



2.1.1 Banco 2.1.2 Contrato 2.1.3 Convênio de Arrecadação 2.1.4 Dados Cadastrais 2.1.5 Faturamento

2.1.5.1 Regerar Demonstrativo 2.1.5.2 Verificar Liberação

2.1.6 Movimentos/Arquivos 2.1.6.1.............. 2.1.6.2..............

2.1.7 Notificação 2.1.8 Unidade de Arrecadação 2.2 Documento de Arrecadação

2.2.1................ 2.2.2................

2.3 Repasse Financeiro 2.3.1................ 2.3.2................ 2.3.3................

2.4 Restituição 2.4.1................

2.5 Administração do Sistema 2.5.1..............

2.6 Consultas/Relatórios Operacionais 2.6.1................ 2.6.2................ 2.6.3................ 2.6.4................

6º Passo: Definir o conteúdo da Ajuda do Sistema para cada item da hierarquia definida para o tópico “Funcionalidades”:

Descrever o conteúdo da Ajuda do Sistema das funcionalidades de forma clara, contemplando todas as informações necessárias para tornar a utilização de cada funcionalidade o mais amigável possível para todos os usuários do sistema.

5. ELABORAÇÃO DA ESTRATÉGIA DA HOMOLOGAÇÃO E ROTEIRO DE TESTES DE HOMOLOGAÇÃO

Este procedimento tem como objetivo servir como um guia para que a equipe do sistema e área gestora possam: � Definir as ESTRATÉGIAS de HOMOLOGAÇÃO do projeto

A definição das estratégias de homologação de um projeto tem como objetivo assegurar que todas as questões referentes a ambiente, infra-estrutura, pessoal e sistema estarão resolvidas e alinhadas para garantir a realização com qualidade do trabalho de homologação a ser desenvolvido. As estratégias devem ser definidas de forma antecipada para que as equipes envolvidas possam tomar as ações necessárias em tempo hábil para a homologação.



� Elaborar o ROTEIRO de TESTES de HOMOLOGAÇÃO do projeto O Roteiro de Testes de Homologação tem como finalidade apoiar a equipe homologadora durante a realização das suas atividades, contemplando de forma clara e detalhada todos os testes necessários e importantes a serem feitos no projeto.

5.1 DEFINIÇÃO DAS ESTRATÉGIAS E HOMOLOGAÇÃO DO SISTEMA

Os itens que devem compor a Estratégia de Homologação do sistema devem ser definidos para todo o sistema antes de iniciar o processo de homologação. Para a elaboração da Estratégia de Homologação, a equipe responsável deverá adotar as etapas descritas a seguir. ITENS GERAIS – COMUNS A TODOS OS CASOS DE USO DO SISTEMA 1º. Estabelecer Plano de trabalho para a Homologação do sistema:

• Definir o Cronograma de homologação – deve ser contemplada uma pré-homologação feita pela equipe que desenvolveu o sistema no mesmo ambiente de homologação antes de entregá-lo para a equipe homologadora.

• Definir a Equipe - Sefaz e Empresa Contratada - envolvida no processo de homologação.

• Definir as responsabilidades das pessoas envolvidas. 2º. Definir os documentos do sistema que serão utilizados para a homologação.

Estabelecer os documentos que serão utilizados pelo homologador para a realização dos testes no sistema, como por exemplo: Roteiro de Homologação (por caso de uso), Detalhamento dos requisitos definidos para o sistema, Roteiro de Testes, algum relatório comparativo, massa de dados, etc.

3º. Definir e criar o Ambiente e Infra-estrutura necessária. A equipe do sistema deverá previamente discutir e detalhar junto com a equipe de tecnologia todos os itens referentes ao ambiente e à infra-estrutura imprescindíveis para o funcionamento adequado do sistema no ambiente de homologação. As equipes envolvidas deverão tomar todas as providencias necessárias para atender aos requisitos estabelecidos antes do início do processo de homologação. Entre outros pontos, devem ser considerados: • Estruturas de Dados

o Definir como serão criadas as estruturas de dados do sistema, qual o procedimento adotado para o envio e execução dessas alterações, quais os bancos de dados envolvidos, qual será o servidor utilizado, qual o escopo de dados deve estar contido no ambiente de homologação do sistema, etc.

• Aplicação o Definir estrutura e ambiente necessário para que a aplicação possa ser

disponibilizada para homologação. • Controle de Versão

o Definir a estratégia a ser adotada para a disponibilização e controle de novas versões do sistema durante o processo de homologação.

• Segurança o Definir os itens de segurança envolvidos no processo e as ações que precisam

ser tomadas para garantir que estes itens estarão disponibilizados e utilizados durante o processo de homologação.

• Configuração UniFW – Trilha de auditoria, Serviços, etc. o Definir os itens de configuração do UniFW que precisam ser providenciados

para a realização da homologação do sistema.



ITENS ESPECÍFICOS – A SEREM TRATADOS PARA CADA CASO DE USO DO SISTEMA 1º. Definir ferramentas e/ou instrumentos necessários para viabilizar os testes de algumas

funcionalidades específicas. Avaliar e tomar as providências necessárias para obter ou disponibilizar ferramentas/instrumentos para possibilitar que a homologação seja realizada de forma completa e com qualidade para todas as funcionalidades que não possam ser avaliadas apenas com a utilização do sistema que está sendo homologado. Por exemplo:

• Instrumento para que o homologador possa validar o conteúdo de arquivos gerados “por” e/ou “para” órgãos externos, como bancos. Por exemplo: geração de relatório ou uma consulta específica para verificação dos dados gravados no arquivo.

• Uso de Leitora de código de barras para validação dos DAE emitidos pelos sistemas

• Ferramenta para possibilitar a validação da consistência dos dados gerados através de cálculos ou consolidações aplicados no sistema.

• Utilização de sistemas legados para apoiar a homologação de algumas funcionalidades do novo sistema.

• etc. 2º. Identificar necessidade e Planejar o envolvimento de outras áreas gestoras e/ou órgãos

externos. Identificar e estabelecer compromisso com todos os envolvidos – interno ou externo à Sefaz – a fim de garantir total consistência e qualidade na Homologação do sistema.

• Avaliar todas as áreas da Sefaz e/ou Órgãos externos que precisam ser envolvidos no processo de homologação do sistema. Esta avaliação deverá ser feita com base no relatório de integração do sistema, onde estão detalhados todos os sistemas e órgãos integrados e que precisam ser envolvidos no processo de testes e homologação.

• Definir as responsabilidades das pessoas envolvidas neste processo de homologação.

• Detalhar os procedimentos necessários para a realização das atividades de homologação.

3º. Definir a solução para Migração e Carga dos Dados Definir a estratégia de migração e execução de carga dos dados.

4º. Planejar a elaboração da Ajuda do Sistema para cada Caso de Uso Definir o responsável e planejar a elaboração Ajuda do Sistema para cada caso de uso.

5º. Realizar treinamento da equipe Definir a equipe que precisará ser treinada pois irá participar da equipe que irá efetuar a homologação.

5.2 ELABORAÇÃO DO ROTEIRO DE TESTES DE HOMOLOGAÇÃO

A homologação do sistema tem como objetivo garantir que:

� O comportamento do sistema atenda às expectativas e necessidades da organização;



� O sistema esteja funcionando em conformidade com todas as condições de regras e requisitos estabelecidos no documento de Detalhamento de Requisitos;

� O padrão adotado, a navegação entre as telas do sistema e a utilização estejam conformes e amigável;

� O tempo de execução das funcionalidades atenda aos requisitos de performance esperados para o sistema.

Para o gestor elaborar o Roteiro de Teste de Homologação é necessário seguir os seguintes passos:

1º. Relacionar para o Caso de Uso todas as funcionalidades a serem testadas. 2º. Identificar as integrações contempladas que serão homologadas neste Caso de

Uso. 3º. Relacionar para cada funcionalidade todos os requisitos importantes para serem

homologados. Devem ser considerados os requisitos de: � negócio, � segurança (Controle de Acesso), � performance, � etc.

4º. Mapear, para o Caso de Uso, o escopo de dados, filtros, etc., necessário para atender a homologação das funcionalidades/requisitos relacionados no item anterior.

Para detalhar o Roteiro de Teste de Homologação de um caso de uso, cada funcionalidade a ser homologada deverá ser avaliada com base nos itens a seguir:

1. Geração de histórico de informações e trilhas de auditoria. Por exemplo: As ocorrências de histórico e trilha de auditoria definidas para algumas funcionalidades estão sendo geradas? O conteúdo do dado que está sendo gravado pelo sistema está consistente?

2. Reconstituição de dados após falha de operação e/ou transmissão de dados. Por exemplo:

� Houve perda de conexão que impossibilitou a execução completa de alguma funcionalidade? O comportamento do sistema neste momento foi adequado?

� Foi identificada alguma falha de operação durante a transmissão de dados para Bancos ou outros órgãos externos? Houve perda de dados?

3. Resultados obtidos em operações simultâneas executadas por usuários diferentes, com relação ao comportamento e conteúdo da informação disponibilizada - verificar como se comporta uma mesma funcionalidade sendo executada por mais de um usuário ao mesmo tempo. Por exemplo:

� Como o sistema se comporta com a geração de DAE feita por mais de um usuário? Deve ser observando o comportamento do sistema na geração de ocorrência de DAE emitido (geração do seqüencial do DAE).

� Como o sistema se comporta quando mais de uma pessoa tenta ao mesmo tempo fazer uma alteração em um mesmo registro do sistema?

4. Comportamento da funcionalidade a partir de diferentes meios/locais de onde poderá ser disparada, inclusive nos casos de precisar funcionar on-line e off-line. Por exemplo:

� Verificar como uma mesma funcionalidade do sistema se comporta sendo acessada de casa, de um Posto Fiscal, de uma Inspetoria e da sede Sefaz.

� Quando aplicável, verificar como uma mesma funcionalidade do sistema se comporta sendo executada de forma on-line e off-line.

5. Comportamento quando forem consultados o primeiro e último registro da base de dados e quando não existirem registros a serem manipulados.



Por exemplo: As consultas existentes para todos os registros de uma determinada tabela do sistema estão tratando de forma adequada o “primeiro” e “último” registro cadastrado na tabela? Quando não existir registro cadastrado para uma tabela, como a consulta a esta tabela se comporta?

6. Comportamento quanto às regras de segurança (controle de acesso) estabelecidas para cada funcionalidade - permissões de usuários a funções e a dados. Por exemplo:

� A disponibilização das funcionalidades do sistema está de acordo com os perfis dos usuários definidos para o SIGAT (Gestor, Atendimento, etc.)?

� Cada usuário está realmente visualizando o conjunto de dados definidos para seu perfil?

� Os perfis dos usuários estão definidos no controle de acesso de forma correta?

7. Ações tomadas pelo sistema após ocorrências de erros. Por exemplo: Você identificou algum erro que não está sendo tratado pelo sistema de forma adequada (apresentando mensagem consistente, executando a ação correta, etc.) ou que está comprometendo a continuidade da utilização do sistema?

8. Mensagens apresentadas quanto à clareza e consistência. Por exemplo: O conteúdo das mensagens apresentadas no sistema está claro e compatível com a funcionalidade executada?

9. Consistência de filtros de seleção de dados, classificações, quebras, seleções e ordenações. Por exemplo:

� Os dados disponibilizados nas consultas do sistema estão compatíveis com os dados informados no filtro de seleção?

� A quebra de página está compatível com o número de linhas estabelecido para o preenchimento do grid?

� A ordenação dos campos do relatório está compatível com a ordenação aplicada nas colunas do grid?

� As opções de seleção de apenas um campo ou de vários campos nas consultas estão de acordo com o definido para a funcionalidade?

� A quebra de página do relatório está comprometendo seu entendimento e dificultando a sua utilização?

10. Layout de relatórios (cabeçalho, corpo, rodapé) e de arquivos. Por exemplo:

� O formato, conteúdo e distribuição das informações nos relatórios estão adequados?

� O formato utilizado para a geração dos arquivos (para os Bancos, por exemplo) está correto – compatível com o layout estabelecido na especificação?

� A impressão do relatório está de acordo com a visualização na tela? � O filtro informado está sendo impresso no relatório?

11. Conformidade de dados recebidos e enviados nas integrações existentes. Por exemplo: O DAE emitido está compatível com a Receita e Valores enviados pelo sistema solicitante?

12. Tratamento de campos editáveis. Por exemplo:

� A máscara de edição está sendo aplicada da forma correta, de acordo com o tipo de dado (data, valor, etc.), formato (CNPJ, CPF, etc.) e tamanho?

� Os campos que devem ser preenchidos automaticamente, com base em regras estabelecidas, estão adequados?

� Os campos definidos como obrigatórios são validados e exigidos pelo sistema?

13. Integridade e consistência dos dados apresentados, assim como a conformidade de cálculos.



Por exemplo: � O cálculo do saldo credor gerado pelo sistema está correto? � Os valores consolidados das consultas gerenciais do sistema estão

consistentes? 14. Comportamento quanto ao tamanho máximo e mínimo de campo e quanto a valores

inválidos, extremos, vigências, etc. Por exemplo:

� Como o sistema se comporta quando é utilizado o limite máximo para preenchimento de campo?

� Como o sistema se comporta quando é utilizada uma data ou qualquer outra informação inválida no preenchimento dos campos?

� Como o sistema se comporta quando é utilizada uma data de vigência superior ao permitido/possível para a funcionalidade específica?

15. Posicionamento e alinhamento dos campos Por exemplo: As informações disponibilizadas nas consultas e relatórios estão bem posicionadas na tela e no papel? Estão alinhadas de forma adequada?

16. Qualidade de impressão e do conteúdo, visualizando os relatórios em mais de uma impressora. Por exemplo: A impressão do DAE foi feita em mais de uma impressora, inclusive de tipos diferentes, e o resultado da impressão foi adequado?

17. Conformidade do uso dos menus, botões e links. Por exemplo:

� O uso do menu do sistema está adequado e amigável ao usuário? � Está claro para o usuário o que será executado quando ele utiliza os botões e

links disponibilizados nas funcionalidades do sistema?

gestores de sistemas - sefaz.ba :: secretaria da fazenda do … · 2013-10-02 · pontuação de...

Documents