TCE-GO - DET- Documento de Especificação Técnica - Gestão de Estrutura Organizacional - Onda 1

Este documento de escopo tem a função de documentar as necessidades apontadas, no que diz respeito a gestão de Estrutura Organizacional do estado, que o TCE-GO precisa manter. Além disso, este documento descreverá em suas seções, as necessidades (descritas em formato de requisitos em alto nível) e as propostas de solução para tratar tais requisitos.

Atualmente, o TCE-GO mantêm um cadastro de órgãos externos e setores internos em um sistema chamado GCAD. Os setores externos, chamados de setores Gerais, são mantidos para listar os órgãos que estão sob a jurisdição do Tribunal para fins de ações na tramitação de processos, ofícios e outras atividades que são realizadas entre os órgãos do governo. Já os setores internos, que representam a estrutura organizacional do TCE-GO, é mantida para fins institucionais, como: representar a hierarquia do Tribunal, realizar destinação de processos, permissão de acesso/ações internas, utilização em outros sistemas no TCE, entre outras atividades que podem usar sua estrutura hierárquica de setores. Estes cadastros possuem, entre outras informações, dados como:

- Para o Cadastro de Setores Internos: Código identificador, Nome do setor, localização, setor subordinado, Município, status(Ativo ou Inativo), Vínculo(Tribunal ou Procuradoria), Ramal, se pertencerá a estação digital(sim ou não) e se pertencerá ao Ponto-GPON(Sim ou Não).

- Para o Cadastro de Setores Gerais/Externos: Pessoa jurídica, Código identificador, número do CNPJ, Código Seplan, Nome do Setor, Tipo de poder, Tipo de administração, Tipo de órgão e Município.

Estes cadastros podem ter seus registros alterados a qualquer momento pelos usuários com permissão de acesso e, nenhuma dessas alterações, são registradas. Por essa razão não é possível consultar as alterações históricas para se conhecer: O que, Quem, Como e Quando as alterações foram realizadas.

O que justifica a execução deste projeto são as seguintes necessidade:

1. Atualizar tecnologia; passando de um sistema que começa a apresentar problemas em estações com Sistema Operacional mais atual para um sistema desenvolvido em plataforma moderna que não possui dependências com o ambiente em que será utilizado.

2. Registrar alterações que são feitas nos setores internos e externos; mantendo o histórico de alterações para consulta posterior.

Tais necessidades levam a uma análise mais aprofundada e, com isso, uma proposta de solução que envolve o desenvolvimento de itens que serão descritos na lista de necessidades e nas histórias de usuários.

O projeto será considerado um sucesso se atender aos dois principais problemas de negócio declarados, atualmente, pelos PO's do projeto, que são:

• Atualização tecnológica: Ter um novo sistema para cadastro de setores internos e externos, em uma plataforma atual, que não apresente problemas de execução nas estações do usuário.

• Registro de alterações: Ter um sistema que registre as alterações feitas nos cadastros internos e externos; possibilitando a consulta das alterações que houveram desde sua criação.

Para estabelecer a prioridade dos requisitos, foram adotadas as denominações: essencial, importante e desejável. Abaixo temos a descrição de significado de cada uma dessas denominações:

* Essencial: É o requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente.

* Importante: É o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim.

* Desejável: É o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.

Abaixo estão os problemas de negócio, dos PO's do projeto, desmembradas em requisitos de produtos. Estes requisitos são fruto de uma análise dos problemas de negócio apresentados e, também, do estudo de melhoria do sistema de cadastro; visando evoluir este cadastro para um sistema de Gestão de Estrutura Organizacional.

Solução para 6.0-EU1: Construir e/ ou alterar Estórias de usuário que foram previstas para cada sprint.

Proposta de solução para 6.1-EU1: Desenvolver uma tela de cadastro de unidade organizacional com as seguintes informações:

GERAL: Código identificador(preenchido automaticamente), Nome da unidade, Pessoa jurídica * * *, número do CNPJ * * *, Município *, Consolida informação contábil(Sim OU Não) * * * *, Status(Ativo OU Inativo), Filiação(ver história 6.1-EU2) e campo condicional para tipo de unidade(interno/TCE OU externo). Caso a escolha neste campo condicional for:

TIPO:Interno/TCE: exibir campos para informar a: localização * *, setor subordinado * *, Vínculo * *, Ramal, se será visualizado na estação digital(sim ou não) e se será visualizado no Ponto-GPON(Sim ou Não).

TIPO:Externo: abrir campos para informar o Tipo de poder * *, Tipo de administração * * e Tipo de órgão * *.

* Proveniente do cadastro de município no GCAD.

* * DESCREVER DE ONDE VEM ESSAS INFORMAÇÕES. Se de algum outro cadastro ou se está fixo no código.

* * * Essa informação deve ser proveniente do cadastro pessoa jurídica existente no GCAD.

* * * * Este é um campo que terá a função de “flag” para utilização no sistema de Gestão de Contas de Governo. É escopo deste projeto a inserção deste campo na tela de cadastro de unidade organizacional; no entanto, seu comportamento será manual, não terá automatização e nenhuma regra de negócio embutida.

As informações de cadastro, citadas acima, são as informações mínimas que precisam constar no cadastro visando atender as regras de negócio existente hoje.

Além disso, é preciso desenvolver as operações básicas para a tela de cadastro de informações que são: Novo, Alteração, Consulta e Inativação.

LINKAR COM O PROTÓTIPO.

Proposta de solução para 6.1-EU2: Desenvolver um campo na tela de cadastro de Unidade Organizacional que possibilita a seleção de uma outra unidade organizacional. Essa seleção deverá ser entendida como um nível superior da unidade em questão; caracterizando, assim, um estabelecimento de “filho para pai”. Em outras palavras, essa seleção de uma Unidade Organizacional deve estabelecer a unidade que será sua respectiva unidade superior, de forma direta.

Como este campo faz parte da tela de cadastro, as operações básicas, como: Novo cadastro, Alteração, Consulta e Inativação deverão estar disponíveis. Com isso, algumas regras de negócio deverão ser atendidas da seguinte forma:

- Para um novo cadastro(NOVO CADASTRO): O campo deve listar todas as unidades organizacionais cadastradas no sistema para o usuário indicar como sendo a unidade superior direta.

O resultado, é que o sistema deve considerar a unidade organizacional indicada como SUPERIOR à que indicou e formar um relacionamento hierárquico entre elas.

Ex.: Unidade Organizacional-B indicou a U.O-A como superior; logo, o sistema deve criar um relacionamento hierárquico que represente este relacionamento.

- Para editar um cadastro(ALTERAÇÃO): O campo deve listar todas as unidades organizacionais cadastradas no sistema para o usuário indicar como unidade superior.

O resultado, é que o sistema deve considerar a unidade organizacional indicada como SUPERIOR à que indicou. Neste caso, se a U.O. alterada tiver outras U.O's abaixo dela, todas deverão acompanhar a transferência.

Ex.: Unidade Organizacional-B, que tem a U.O-C como subordinada, indicou a U.O-D como superior; logo, o sistema deve criar um relacionamento hierárquico que represente este relacionamento entre a U.O-D sendo superior direto da U.O-B e superior indireto da U.O-C.

- Para consultar um cadastro(CONSULTA): A consulta de um cadastro não levará impacto de negócio à funcionalidade. O resultado, neste caso, será a consulta de informações de uma unidade organizacional que tiver sido selecionada.

- Para Inativar um cadastro(INATIVAÇÃO): A ação de exclusão não será aplicada nos cadastros de unidades organizacionais. Para isso é preciso considerar a INATIVAÇÃO, no lugar de exclusão. Assim, ao inativar uma U.O. o sistema deve inserir uma marcação no nome da U.O.; indicando que trata-se de uma U.O inativa. Ex.: Ao inativar uma Unidade Organizacional de nome: “Secretaria de Segurança Pública”. O sistema, automaticamente, altera o nome da U.O. para: “INATIVO - Secretaria de Segurança Pública”.

Além disso, o relacionamento hierárquico de uma U.O. deve ser substituído quando houver inativação. Ex.: Considerando uma estrutura organizacional, onde: U.O-A é superior direta a U.O-B e indireta a U.O-C. Ao inativar a Unidade Organizacional-B, a O.U-A passa a ser superior direta da U.O-C.

IMPORTANTE: NUNCA SERÁ POSSÍVEL UMA 'O.U.' TER MAIS DE UMA UNIDADE COMO SUPERIOR DIRETA.

Proposta de solução para 6.3-EU1: Desenvolver um recurso de sistema que registra todas as ações realizadas nos sistema de Estrutura Organizacional. Este registro deve gravar as seguintes informações:

QUEM: Usuário que realizou ações como: Novo cadastro, Alteração e Inativação no sistema. Este usuário deve ser identificado pelo seu login e o sistema deve gravar seu ID, nome de usuário, nome completo tipo de ação (novo cadastro, alteração ou inativação).

QUANDO: Data e hora em que um registro foi Criado, alterado ou Inativado. O sistema deve gravar essa informação de data e hora e vincular a QUEM realizou a ação.

PORQUE: Motivo pelo qual uma Alteração ou Inativação foi realizada. No momento que o usuário tentar efetivar uma alteração ou inativação, o sistema deve apresentar um campo texto para que ele possa explicar o motivo pelo qual aquela ação está sendo realizada. O sistema deve gravar essa informação de porque e vincular a QUEM realizou a ação e QUANDO foi feita.

O QUE: Determina qual foi a ação realizada pelo usuário. O sistema deve gravar a informação do que foi feito, como por exemplo: Cadastrou novo registro 123, ou Alterou Registro 456, ou Inativou registro 789; com isso, o sistema deve vincular a QUEM realizou a ação, QUANDO ela foi feita e PORQUE foi feita.

Solução para 6.3-EU2: Desenvolver um recurso de sistema que cria e registra a rastreabilidade das alterações que ocorreram nas unidades organizacionais. Este registro deve utilizar as informações de QUEM, QUANDO, PORQUE e O QUE para formar a rastreabilidade. Ex.: Unidade Organizacional-A, tem o nome de “Secretaria de Segurança Pública” em 2017. Em 2018, teve seu nome alterado para “Secretaria Geral de Segurança Pública”. Logo, o sistema deve gravar essa alteração em ordem cronológica.

Essa premissa vale para a alteração do nome de uma U.O. e, vale também, para as alterações hierárquicas que ocorrerem. Ex.: Considere duas Estruturas Organizacionais:

1º - Unidade Organizacional-A, que é superior direta da U.O-B e indireta da U.O-C.

2º - Unidade Organizacional-1, que é superior direta da U.O-2 e indireta da U.O-3.

Em 2017, a primeira estrutura incorporou a segunda e ficou da seguinte forma:

Unidade Organizacional-A, que é superior direto da U.O-B e U.O-1 e indireto da U.O-C, U.O-2 e O.O-3.

Em 2018, a incorporação foi desfeita e voltou a ficar como era em 2017.

Dado o exemplo acima, o sistema deve gravar essas alterações em ordem cronológica para que sua rastreabilidade seja registrada.

Solução para 6.4-EU1: Para tratar esta história, é preciso considerar o desenvolvimento do sistema de Gestão de Estrutura Organizacional utilizando a base de dados, de cadastro de setores internos/externos, do sistema atual. Esta proposta de solução foi elaborada dessa forma a atender um requisito de projeto que é ACELERAR a entrega do produto final e impactar minimamente as aplicações satélite.

Em outras palavras, o cadastro de unidades organizacionais deverá continuar utilizando as tabelas: GER_SETORGERAL e GER_SETORINTERNO, do GCAD, para as informações mantidas atualmente. Para as novas informações, previstas neste escopo, como: informações históricas/de rastreabilidade, informações de hierarquia, entre outras deverão utilizar uma nova tabela. Essa nova tabela deve ser o espelho da original, de cadastro de setores, acrescida de novas colunas para registro das novas informações.

Solução para 6.5-EU1: Desenvolver um recurso de geração de dados visando sua emissão em tela e impressão. No que diz respeito a emissão em tela, o sistema deve possibilitar a visualização do relatório em uma tela própria do sistema; já no que diz respeito a impressão, no momento em que o relatório estiver sendo exibido em tela, o sistema deve possibilitar sua emissão nos formatos .XLS e .PDF, de acordo com o que for mais apropriado para seu conteúdo.

Os dados que precisam ser gerados em formato de relatório são:

Consultar Unidades Organizacionais: Para gerar este relatório, o sistema deve permitir a seleção de alguns parâmetros, como: Nome da Unidade Organizacional OU Município OU Tipo de Poder OU Inativas OU Inativas OU Todos * as O.U's. Selecionado ao menos um destes parâmetros, será possível gerar o relatório que deverá apresentar as informações de Unidades Organizacionais categorizadas em ordem crescente pelo ID.

As regras que incidem na seleção deste parâmetro e emissão/geração deste relatório, são:

- Obrigatoriedade na seleção de um dos parâmetros;

- Seleção de um de cada parâmetro por geração de relatório;

- Uma vez que o parâmetro “Todos” for marado, os demais ficam desabilitados;

- Com exceção do parâmetro “Todos”, os parâmetros podem ter apenas uma seleção;

- A ordem dos parâmetros deve ser: Unidade Organizacional, Município, Inativas/Inativas e Tipo de Poder. Na medida em que o usuário seleciona o primeiro parâmetro, o segundo é filtrado tendo o primeiro parâmetro como base.

* A marcação da opção Todos, indica que todas as unidades organizacionais cadastradas devem ser apresentadas no relatório.

Solução para 6.5-EU2: Desenvolver um recurso de geração de dados visando sua emissão em tela e impressão. No que diz respeito a emissão em tela, o sistema deve possibilitar a visualização do relatório em uma tela própria do sistema; já no que diz respeito a impressão, no momento em que o relatório estiver sendo exibido em tela, o sistema deve possibilitar sua emissão nos formatos .XLS e .PDF, de acordo com o que for mais apropriado para seu conteúdo.

Os dados que precisam ser gerados em formato de relatório são:

Consultar histórico de Unidades Organizacionais: Para gerar este relatório, o sistema deve permitir a seleção de dois parâmetros: Nome da Unidade Organizacional E Data de recuperação(MM/AAAA). Ao gerar o relatório, o sistema deverá apresentar as informações de históricas de Unidades Organizacionais categorizadas em ordem cronológica à que foi informada no parâmetro.

As informações históricas, que devem ser apresentadas neste relatório, são:

- Alterações de nome que a U.O. sofreu desde a data informada no parâmetro;

- Alterações na hierarquia que a U.O. sofreu desde a data informada no parâmetro;

- Alterações de status(Ativa e Inativa) que a U.O. sofreu desde a data informada no parâmetro;

- Motivos das alterações que estiverem cadastrados que a U.O. sofreu desde a data informada no parâmetro;

As regras que incidem na seleção deste parâmetro e emissão/geração deste relatório, são:

- Obrigatoriedade na seleção dos dois parâmetros;

- Seleção de apenas uma U.O. e uma data por geração de relatório;

- Caso não haja dados a serem exibidos para os parâmetros informados, uma mensagem deverá ser exibida ao usuário.

Solução para 6.5-EU3: Desenvolver um recurso de geração de dados visando sua emissão em tela e impressão. No que diz respeito a emissão em tela, o sistema deve possibilitar a visualização do relatório em uma tela própria do sistema; já no que diz respeito a impressão, no momento em que o relatório estiver sendo exibido em tela, o sistema deve possibilitar sua emissão nos formatos .XLS e .PDF, de acordo com o que for mais apropriado para seu conteúdo.

Os dados que precisam ser gerados em formato de relatório são:

Consultar hierarquia de Unidades Organizacionais: Para gerar este relatório, o sistema deve permitir a seleção do seguinte parâmetro: Nome da Unidade Organizacional. Selecionado este parâmetro, o sistema deve gerar o desenho da estrutura organizacional daquela unidade informada no parâmetro.

As regras que incidem na seleção deste parâmetro e emissão/geração deste relatório, são:

- Obrigatoriedade na seleção do parâmetro;

- Seleção de apenas uma U.O. por geração de relatório;

- Seleção, apenas, de Unidade Organizacional que não tenha indicação de unidade superior;

- Seleção de Unidades Organizacionais com status de ativo ou inativo.

- A emissão em tela deste relatório deve possibilitar sua visualização completa e, também, parcial por aplicação de zoom;

- A impressão deste relatório deve ser em formato de papel A4 e com toda a Estrutura Hierárquica impressa.

7.1. RNF01-Utilização de Sistema Anterior

7.2. RNF02-Tempo de Resposta

7.3. RNF03-Usabilidade

7.4. RNF04-Sistema de Ajuda

7.5. RNF05-Usuários Simultâneos

7.6. RNF06-Uso do Teclado

7.7. RNF07-Interoperabilidade

7.8. RNF08-Escalabilidade

7.9. RNF09-Layout

7.10. RNF10-Tecnologia Web

Requisito de Desempenho: As páginas do sistema precisam ser acessadas com rapidez, mesmo com utilização de uma banda de internet considerada “lenta”. Ex.: 3G ou internet com velocidade de acesso igual ou inferior a 128 Kpbs.

Requisito de Segurança: O sistema de Gestão de Estrutura Organizacional deve utilizar o sistema atual de autenticação usado no TCE-GO para as aplicações Web.

Testes: Haverá sequencia de testes na entrega do produto nas fases programadas no projeto, de acordo com as regras descritas na GCS do TCE-GO.

Escopo: Toda alteração do escopo deve ser documentada através de solicitação de mudança e seu impacto deve ser avaliado nas atividades do projeto, conforme rege da GCS do TCE-GO.

Geral:

• É preciso considerar o desenvolvimento do sistema de Gestão de Estrutura Organizacional, no que diz respeito a dados históricos, a avaliação da atual tabela de histórico; chamada: GER_HISTORICOTABELA.

Abaixo estão os desenhos feitos para compor o wireframe, de acordo com o que foi coletado nos requisitos até o momento. É importante ressaltar que estes protótipos são sugestões e não definições; portanto, o resultado final pode receber modificações para atender melhor cada um dos requisitos solicitados.

Aplicação do wireframe	Clique na imagem para ver em tamanho original	Aplicação do wireframe	Clique na imagem para ver em tamanho original	Aplicação do wireframe	Clique na imagem para ver em tamanho original
Cidadão		Servidor	Deve seguir a mesma estrutura do layout para o cidadão e alterar e ter seu conteúdo voltado para o Servidor	Jurisdicionado	Deve seguir a mesma estrutura do layout para o cidadão e alterar e ter seu conteúdo voltado para o Jurisdicionado

Não se aplica.