SEFAZ-BA
SGF
DTI
GEDES
Secretaria da Fazenda do Estado da Bahia
Superintendência da Gestão Fazendária
Diretoria de Tecnologia da Informação
Gerência de Administração de Dados e Desenvolvimento de Sistemas
CARTILHA
Gestores de Sistemas
Versão 01.00.01
Salvador (Ba), maio de 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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.
Página 2
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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.
Página 3
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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 DE 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
Página 4
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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.
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.
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
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)
Liberação de Versão –
Planejamento da distribuição
(primeira versão ou piloto)
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
Página 5
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
Liberação de Versão –
Disponibilização do pacote
de instalação/ atualização
Validação de documentação
01/06/12
confirmação com data, horário e a pessoa a
ser contatada na respectiva unidade.
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.
versão com erros e consequentemente a
necessidade de geração de sucessivas versões
corretivas.
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.
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 \
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.
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.
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.
Página 6
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
Validação de protótipos
Interação com a GERAT
Pontuação de sistemas
Informativo / avaliação de impacto
01/06/12
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.
Validar o protótipo para garantir que todas as
informações e funcionalidades solicitadas
estejam contempladas.
Os documentos devem ser validados de forma
criteriosa, sempre verificando se consta tudo
o que foi definido em reunião com o analista.
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.
Não é papel do Gestor.
Qualquer necessidade relacionada a imagem,
criação de links deve ser
Cabe à Administração de Dados, enquanto logomarca,
equipe de padrões de interface, intermediar o sinalizada para os analistas, que irão buscar
relacionamento dos analistas SEFAZ com a essa interação com a GERAT através da AD.
GERAT (Webdesign).
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.
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.
Responder uma Avaliação de Impacto / Nunca responder uma Avaliação de Impacto
Informativo, sempre que consultado pelos / Informativo, apenas a partir da mensagem
líderes / analistas SEFAZ.
original encaminhada pela AD, visto que esta
Página 7
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
Liberação de um novo sistema/
serviço
Sistemas mainframe
Atualização do portfólio
Elaboração da Ajuda do Sistema
Execução da homologação
01/06/12
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.
Enviar previamente uma Rotina de
Atendimento (perguntas e respostas mais
freqüentes) para o Call Center.
Definir os níveis de acesso à nova rotina.
Delegar os acessos aos respectivos usuários
usando a aplicação XF74
(Atualização de Senha)
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.
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
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
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.
Envolver a GEAPE desde a percepção de que
o sistema será usado por usuários externos.
Torna os usuários mais independentes
Fundamental para uma implantação de versão
mais eficaz.
Deve ser
alterações.
feita
mesmo
Página 8
para
pequenas
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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
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.
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.
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.
Envio de estruturas e/ou dados
para fábrica
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.
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.
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.
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.
Página 9
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
Sincronização de ambientes
Mudança de gestor do sistema
Atualização de dados em Produção
01/06/12
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.
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.
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).
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
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.
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.
Página 10
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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.
Página 11
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
2. DOCUMENTAÇÃO DOS SISTEMAS
Fase: Especificação
Artefato
Elaboração
Solicitação de
Sistemas
Detalhamento
de Requisitos
Relatório de
Análise de
Riscos
Validação
Laudo
Observação
Gestor
Não se aplica
Não se aplica
Analista SEFAZ
•
Gestor –
Conteúdo
•
Documento inicial onde o gestor
define suas necessidades.
Documento Obrigatório para
liberação de versão adaptativa em
homologação
•
Analista AD –
Padrão e
Técnica
Gestor –
Conteúdo
Analista SEFAZ
Fase: Análise
Artefato
Elaboração
Definição de
Ambiente
Analista SEFAZ
•
•
Coordenador
SEFAZ –
Conteúdo
•
Analista AD –
Padrão e
Técnica
•
•
•
Rubrica – Analista AD /
Analista SEFAZ
Assinatura –
Coordenador AD /
Coordenador SEFAZ
Rubrica – Analista AD /
Analista SEFAZ
Assinatura –
Coordenador AD /
Coordenador SEFAZ
Documento que deve ser usado nas
reuniões de acompanhamento.
Validação
Laudo
Observação
•
•
Pré-requisito para validação de
qualquer outro artefato a partir da
INFRA –
Conteúdo
Rubrica – Analista AD /
Analista BD / Analista
Página 12
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
Tecnológico
Protótipo
Especificação
Técnica de
Rotinas
Roteiro de
Testes
Analista SEFAZ
Analista SEFAZ
Analista SEFAZ
01/06/12
AS / Analista INFRA
•
BD – Conteúdo
•
AS – Conteúdo
•
Analista AD –
Padrão e
Técnica
Analista AD –
Padrão e
Técnica
•
•
Gestor –
Conteúdo
•
GERAT –
Padrão /
Imagem
Externa da
SEFAZ
Analista AD –
Padrão e
Técnica
•
•
Analista AD –
Padrão e
Técnica
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
•
Rubrica – Analista AD /
Analista SEFAZ
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
•
Rubrica – Analista AD /
Analista SEFAZ
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
Rubrica – Analista AD /
Analista SEFAZ
•
•
fase de análise.
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.
Só será gerado para contemplar
regras técnicas que não devem estar
presentes nos documento de
Detalhamento de Requisitos.
Documento Obrigatório para
liberação de versão adaptativa em
homologação.
Assinatura –
Coordenador AD /
Coordenador SEFAZ
Página 13
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
Fase: Projeto
Artefato
Elaboração
Relatório de
Integração
Plano de
Conversão do
Legado
Analista SEFAZ
Analista SEFAZ
01/06/12
Validação
Laudo
Observação
•
•
Rubrica – Analista AD /
Analista SEFAZ
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
Ao gestor só interessa o quadro
inicial que resume todas as
integrações e quais são as
informações trocadas entre os
sistemas.
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
•
Gestor –
Conteúdo
•
Rubrica – Analista AD /
Analista SEFAZ
•
Analista do
Sistema
Legado –
Conteúdo
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
•
Analista AD –
Conteúdo,
Padrão e
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
Página 14
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
Técnica
Diagrama de
Caso de Uso /
Diagrama de
Contexto
Analista SEFAZ /
Analista FÁBRICA
Diagrama de
Classe /
Diagrama de
Resposta a
Eventos
Analista SEFAZ /
Analista FÁBRICA
Diagrama de
Entidade e
Relacionamento
Analista SEFAZ /
Analista FÁBRICA
•
Analista
SEFAZ –
Conteúdo
•
Analista AD –
Padrão e
Técnica
•
Analista
SEFAZ –
Conteúdo
•
Analista AD –
Padrão e
Técnica
Analista
SEFAZ –
Conteúdo
•
•
Dicionário de
Dados
Analista SEFAZ /
Analista FÁBRICA
•
•
Especificações
Analista FÁBRICA
•
Analista AD –
Padrão e
Técnica
Analista
SEFAZ –
Conteúdo
Analista AD –
Padrão e
Técnica
Analista
•
Rubrica – Analista AD /
Analista SEFAZ
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
•
Rubrica – Analista AD /
Analista SEFAZ
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
•
Rubrica – Analista AD /
Analista SEFAZ
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
•
Rubrica – Analista AD /
Analista SEFAZ
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
•
Rubrica – Analista AD /
Coordenador de Projeto GEDES,
Gestor e equipe AD.
Utilizados para compreender o que
sistema faz.
Bons instrumentos para trocar
informações entre a equipe de
desenvolvimento e os usuários.
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.
Utilizado para descrever os
componentes de dados de um
sistema. Fundamental para entender
a adequação do sistema ao modelo
de dados corporativo.
Utilizado para o registro das
definições dos dados em um único
lugar, facilitando a consulta.
Obrigatório apenas para os projetos
Página 15
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
SEFAZ –
Conteúdo
de Classe
•
•
Especificações
de Interface
•
Fase: Homologação
Artefato
Elaboração
Manual de
Sistema
Manual de
Operação
Analista SEFAZ
Analista SEFAZ
Analista AD –
Padrão e
Técnica
Analista
SEFAZ –
Conteúdo
Analista SEFAZ
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
•
Rubrica – Analista AD /
Analista SEFAZ
•
Assinatura –
Coordenador AD /
Coordenador SEFAZ
Analista AD –
Padrão e
Técnica
desenvolvidos em fábrica.
Obrigatório apenas para os projetos
desenvolvidos em fábrica.
Validação
Laudo
Observação
•
•
Rubrica – Analista AD
É uma referência para todos os
demais documentos do projeto.
•
Assinatura –
Coordenador AD
Rubrica – Analista AD
Analista AD –
Padrão e
Técnica
•
OPERAÇÃO –
Conteúdo
•
Analista AD –
Padrão e
Técnica
(Apenas se não
for do PROD)
•
•
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.
Página 16
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
3. COMPOSIÇÃO DO NÚMERO DA VERSÃO DO
SISTEMA
O Padrão de numeração de versão é:
XX.YY.ZZ
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
o
o
o
Visão Geral do Sistema
O que há de novo?
Instruções Gerais de Utilizaçã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
Página 17
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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.
Página 18
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
Exemplo: Para solicitar uma senha de acesso ao Sistema XYZ devese 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
Página 19
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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
Página 20
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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.
Página 21
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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.
Página 22
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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
HOMOLOGAÇÃO
ROTEIRO
DE
TESTES
DE
A homologação do sistema tem como objetivo garantir que:
O comportamento do sistema atenda às expectativas e necessidades da organização;
Página 23
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
01/06/12
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.
Página 24
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
6.
7.
8.
9.
10.
11.
12.
13.
01/06/12
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?
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?
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?
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?
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?
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?
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?
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?
Integridade e consistência dos dados apresentados, assim como a conformidade de
cálculos.
Página 25
_Cartilha dos Gestores de Sistemas 2012
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
14.
15.
16.
17.
01/06/12
Por exemplo:
O cálculo do saldo credor gerado pelo sistema está correto?
Os valores consolidados das consultas gerenciais do sistema estão
consistentes?
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?
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?
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?
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?
Página 26
_Cartilha dos Gestores de Sistemas 2012