Otimização da estrutura interna do sistema SISNE

1. Introdução

Lorem ipsum dolor sit amet, consectetur adipisci elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur.

2. Desenvolvimento

3.1 Remodelagem do banco de dados

O banco de dados é um importante alicerce do sistema, portanto se a modelagem não estiver otimizada, tal condição é refletida diretamente no projeto, sendo necessário usar de artifícios complexos, para resolver problemas que não existiriam, se o sistema estivesse construído em cima de uma base modelada de maneira adequada. Na prática o resultado é consultas lentas e código complexo. 

Inicialmente a ideia é otimizar a principal tabela do sistema que é a de atos. Um ato pode ser referente a uma nomeação, exoneração, retificação, designação, exoneração, dispensa (FG), cessar designação, cessar interino, tornar sem efeito (TSF). Porém atualmente o banco não refleti isso, o que existe é uma única tabela para agrupar todos esses tipos de atos listados, os quais tem finalidades destintas.  

 “Visão parcial da atual modelagem do banco de dados.” 

E então logo temos um problema, pois uma única tabela para todos os tipos de atos além de resultar em confusão no compreendimento da regra de negócio, causa também baixa performance e dificulta a manutenção do projeto.  

Algo que poderia ser feito é manter na tabela atos apenas os campos que são comuns entre os subtipos de atos, e separar os demais em tabelas diferentes (ex: nomeação, exoneração....), referenciando nestas apenas a qual ato pertencem, deixando a estrutura do banco mais organizada. 

 

“Imagem ilustrativa, desconsiderar os campos e tipos neles especificados” 

 

3.2 Unificação de códigos repetidos e otimização das regras de negócios

No decorrer do desenvolvimento do SISNE muita coisa nova foi acrescentada, retirada, muitas regras mudaram, e tudo isso sem nem mesmo o sistema ter sido lançado em produção, o que resultou em grande volume de “lixo” dentro do projeto, por exemplo anteriormente o sistema fazia comunicação direta com a base de dados da DECAANE, para consultar os decretos gerados pelo CECAANE, sistema o qual será substituído pelo SISNE, foi feita uma grande estrutura para que essa integração fosse possível, porém em determinado momento foi decidido que não seria mais necessário, e toda essa comunicação foi removida. 

Outra situação parecida, é referente aos dados pessoais, antes de existir o sistema Pentágono, o SISNE tinha uma estrutura própria para manter esses registros, porém em determinado momento foi decidido que existia a necessidade de concentrar estes dados em um único lugar, e então toda a estrutura criada no SISNE deixou de existir, e aconteceu assim a necessidade de realizar uma nova integração com esse novo sistema chamado pentágono.  

Com toda essa mudança ocorrendo é de se esperar inconsistências e falhas, principalmente se considerarmos a dimensão do projeto. (link para acessar este quadro) 

 

O exemplo abaixo é referente uma consulta de uma nomeação. Na tela do usuário e irá aparecer apenas uma informação básica, porém a consulta traz muito mais dados além do necessário, relacionando diversas outras tabelas no banco de dados, resultando em lentidão e consumo de processamento desnecessário. 

 

Outro exemplo é de situações. Atualmente existem 4 arquivos diferentes que poderiam ser unificados e dessa maneira deixar o sistema mais limpo e simples de trabalhar. 

  

 

3.3 Divisão interna de responsabilidades por perfis

Atualmente existe muita reutilização de arquivos/códigos entre os diferentes perfis do SISNE. A reutilização não é um problema, porém da maneira que foi aplicada no SISNE, percebe-se que está causando muita dificuldade na manutenção e de na novas implementação. Essa dificuldade ocorre devido ao grande excesso de regras que se fazem necessários em resultado da reutilização inadequada de códigos e arquivos. 

Por exemplo, há casos em que se está desenvolvendo código para uma história de usuário específica para um determinado perfil, e ao final é validada, pois cumpriu os requisitos exigidos. Porém pelo fato de ter sido alterado arquivos que estão sendo utilizados por outros perfis, pode acontecer inconsistências nestes outros perfis, por exemplo RH/CHEFE DA PASTA/CASA CIVIL, utilizam o mesmo arquivo responsável por exibir a análise dos documentos do candidato, logo estes se tornam sensíveis a alterações.  

A solução encontrada foi dividir as áreas por perfis, deixando as views mais simples de realizar manutenção. Ao invés de apenas uma para Análise e outra para Servidor, dividir um para cada perfil. Removendo essa área análise, que é genérica. 

 

Por exemplo esse trecho abaixo da linha 30 a 69 só para mostrar um botão, além de envolver muitas regras que não estão visíveis aqui, pois são processadas em outro momento, esse mesmo arquivo é responsável por mostrar botão de Aprovar/Reprovar/Análise da SEGEP/Deferir além de mostrar a situação da certidão/situação da analise. 

 

 

Já este outro apenas para mostrar um botão de Aprovar e Reprovar 

 

3.4 Otimização ou remoção das solicitações

Apenas os perfis ASTEC/SEGEP, DECAANE E GOVERNADOR visualizam atos individuais, os demais perfis utilizam o sistema de solicitações, ou seja, se uma solicitação com 10 atos estiver no CHEFE DA PASTA, e 9 deles estiverem assinados e 1 não estiver a CASA CIVIL não vai conseguir visualizar esta solicitação.  Essa mesma lógica se aplica nos demais perfis, salvo as exceções listadas anteriormente.  

Abaixo estão algumas soluções que poderiam ser implementadas para resolver essa questão. 

3.5 Focar no Produto Mínimo Viável – MVP 

Este é um artificio que pode ajudar a levar o SISNE para produção o mais breve possível, atualmente o foco já está sendo apenas em nomeações e exonerações, portanto a ideia é enxugar o código deixando apenas o necessário para que essas duas ações ocorram.  

Todavia seria mantido uma cópia geral do projeto contendo as regras atuais já criadas para os demais tipos de atos. Dessa maneira, dentro do projeto atual, esses arquivos referentes aos outros tipos de atos seriam apagados, pois não seriam implementados agora. E só depois quando o projeto estiver em produção e validado, então seriam adicionados estes outros tipos de Atos gradualmente, para ser possível que estes sejam validados de maneira mais assertiva. 

Um projeto limpo é mais fácil de trabalhar e manter, o SISNE logo no começo iniciou com a ideia de abranger todos as funcionalidades de uma única vez, resultado assim em um longo período de desenvolvimento, dado que não existiu um MVP naquele momento. 

Abaixo esta um resumo do fluxo completo do SISNE, partindo do perfil RH e finalizando no perfil Governador. 

 

(Fluxo do completo do SISNE) 

O processo envolve muito stakeholders, gerando uma complexibilidade imensa, que é multiplicada ainda mais quando se tem que traduzir tudo isso em código. 

3. Conclusão

O projeto SISNE possui um banco de dados/código fonte não otimizado e suscetível a erros. Portanto novas implementações na atual condição poderão custar muito tempo ainda que simples, uma vez que o código é sensível e bugs podem ser criados a partir de novas features, podendo ser percebido imediatamente ou não.