ANÁLISE DA AVALIAÇÃO

O Opendata Manager foi testado utilizando a configuração multi-tenant e separação dos dados via schema e se mostrou satisfatório com relação aos testes de benchmark. O processamento da máquina onde o ODM está rodando se manteve estável depois de 50 usuários simultâneos, com o consumo ficando em torno de 18 a 20%. Já o consumo de memória tem leves altas conforme o número de usuários vai aumentando, chegando a 40% de consumo com 500 usuários simultâneos.

Como podemos observar nos resultados obtidos, A métrica de tempo de resposta se mostrou nosso limitador, pois ficou bom com 50 usuários. Com 100 usuários o tempo de resposta atingiu a média de 4.493,70 milissegundos, um tempo considerado auto para uma requisição web, mas aceitável dependendo da operação que está sendo realizada e dentro do que foi estabelecido nos requisitos não funcionais. Já com 500 usuários, a aplicação não obteve um bom resultado, demorando 34 segundos em média para responder a uma requisição.

Outro ponto que vale ressaltar é que, com a demora no retorno das requisições com os 500 usuários simultâneos, pela primeira vez nos testes obtivemos uma porcentagem de erro das requisições. Ao final dos testes, verificamos o número de 0,02% de erro nas requisições e, ao analisar, os erros correspondem a timeout retornado pelo servidor. Como o dado obtido foi em porcentagem, precisamos analisar a quantidade de requisições enviadas durante os testes para saber a quantidade de requisições com problemas. No JMeter foram mapeadas 79 test requests que são executadas aleatoriamente por cada um dos 500 usuários virtuais. Logo, 39.500 requisições foram executadas e destas, 8 falharam (correspondente a 0,02%).

Pensando em resolver o problema do resultado insatisfatório obtido, fizemos uma breve análise na aplicação e foi possível perceber alguns pontos que podem ser melhorados. Um exemplo é a listagem de dados que é apresentada nas telas responsáveis por exibir os objetos. Ela está com a configuração padrão do framework com relação a quantidade de objetos mostrados, que é de 100 objetos por página. Com essa quantidade de objetos sendo solicitado em cada página de listagem, cria-se dois pontos de degradação da performance: 1) com relação a construção da página em si, que demora muito, aumentando o tempo de retorno da requisição; 2) com essa quantidade de objetos sendo requisitadas por 500 usuários ao mesmo tempo, cria-se uma alta taxa de consultas ao banco de dados, podendo criar outro ponto de degradação de performance. Vale salientar que a aplicação hoje está utilizando o sistema de cache simples implementado pelo próprio framework django. Com a utilização de uma biblioteca específica para cache podemos melhorar os resultados apresentados, aumentado a performance da aplicação.

Por fim, para uma primeira versão da aplicação, ela se mostrou satisfatória de um modo geral. Conseguimos de uma forma rápida e simples gerir todas as informações com relação ao PDA, sem grande consumo de processamento e memória, devendo um pouco com relação a performance com mais de 100 usuários simultâneos. Os testes de

performance foram importantes para nos mostraram que existe na aplicação pontos de gargalos e que precisam ser resolvidos caso a aplicação seja adotada como serviço por algum órgão. Também nos mostraram que a forma de implementação de separação dos inquilinos podem ser um dos fatores de abertura excessiva de sessões no banco de dados, causando assim lentidão no sistema, necessitando de uma revisão da implementação. 5.7 CONCLUSÃO SOBRE A APLICAÇÃO NO GERAL

Com as funcionalidades desenvolvidas no Opendata Manager, permitimos a qualquer órgão público o gerenciamento de todo o processo de elaboração do PDA, além de monitorar o tempo de atualização das bases, do próprio PDA e monitorar as integrações com sistemas externos.

Através da camada de serviço desenvolvida, foi possível implementar interfaces de comunicação com sistemas integrados de gestão, sistemas de extração e publicação de dados e plataforma de dados abertos. Além da comunicação através de serviços, também foi implementado uma forma de comunicação com banco de dados externos ao banco de dados configurado ao Django, tornando assim possível o acesso a base de dados dos sistemas externos sem a necessidade de uma configuração específica para isso. Apenas com informações inseridas em um formulário, conseguimos acesso as bases externas. Essa implementação suporta atualmente três tipos de SGBDs: MySQL, PostgreSQL e SQlite.

Durante a pesquisa e elaboração do ODM, surgiu a necessidade de não apenas criar um admin , uma área restrita onde apenas os responsáveis pelo PDA teriam acesso, mas também criar uma área pública (Figura 48 - Layout da área pública do ODM) onde poderíamos disponibilizar informações sobre dados abertos e sobre o próprio PDA das instituições. Esta área pública também foi necessária para atender a um dos quesitos da CGU (Grau de relevância para o cidadão (Resolução Nº 3, Art. 1º, I, § 1º)), onde o próprio cidadão pode ter acesso por um período ao inventário de dados e indicar quais são os mais relevantes para ele. Nesta área também é disponibilizado o PDA integral em formato PDF para download, ou em HTML visualmente.

Figura 48 - Layout da área pública do ODM

Fonte: Elaborada pelo autor

Como é recomendado pela própria CGU, o PDA dever ser revisado a cada 2 anos. Esse é um período longo e que pode cair no esquecimento facilmente dos responsáveis das instituições. Um dos módulos mais importantes que foram desenvolvidos é o módulo de monitoramento do PDA, que não só monitora diariamente o PDA, como também os inventários de dados e todas as tarefas que foram cadastradas no sistema. Os limites de prazos são configuráveis, e existem três níveis de alertas para os usuários do sistema: 1. No prazo; 2. Esgotando prazo, e; 3. Prazo esgotado. Para os níveis 2 e 3, são disparadas mensagens por e-mail aos responsáveis pelo sistema. Além disse, todos os níveis de alerta são mostrados no dashboard para todos os usuários.

6 CONCLUSÕES

Nesta pesquisa, foram estudados por volta de 50 a 60 artigos nacionais e internacionais e em nenhum deles foi possível identificar a existência de um software que realize as tarefas descritas no manual da CGU responsáveis pelo processo sistêmico de desenvolvimento do PDA. Entretanto, o estudo destes vários artigos nos mostrou como seria possível o desenvolvimento um software para realizar essa tarefa, nos fornecendo informações suficientes para o levantamento de requisitos.

A ferramenta foi testada reescrevendo 8 PDAs (Tabela 17 - Tabela de PDAs analisados com relação ao grupo de trabalho) das mais diferentes instituições e órgãos públicos nacionais. Essa reescrita foi realizada pelo desenvolvedor do projeto a fim de verificar se todas as necessidades estavam de fato sendo atendidas ou se a aplicação necessitava de algum ajuste. Em todos os casos a reescrita foi bem simples, pudemos gerar os PDAs finais praticamente idênticos aos PDAs confeccionados pelos próprios órgãos responsáveis. Também foi possível criar um monitoramento bem eficiente de todos os artefatos gerados (inventário de dados, documento PDA e prazos de tarefas) nesta construção.

O intuito inicial do projeto foi de construir um software que gerenciasse o processo de construção do PDA, mas ao longo do desenvolvimento foi necessário implementar um módulo para entendermos como se daria a modularização da aplicação. Escolhemos implementar o módulo de extração e publicação de dados para ampliar a capacidade a aplicação de atual na área de dados abertos, aproveitando também algumas funções que foram desenvolvidas a princípio para outros propósitos.

Por fim, realizamos também um contato com os responsáveis pelo Núcleo de Dados Abertos da CGU explicamos sobre o desenvolvimento da ferramenta e indagando se a CGU utiliza algum software no processo de elaboração do PDA. A resposta foi que não utilizam nenhum tipo de software para gerenciar a elaboração do PDA, tão pouco para o seu monitoramento e se mostraram interessados em conhecer a ferramenta desenvolvida neste trabalho.

6.1 LIMITAÇÕES

Atualmente o Opendata Manager gerencia todos o ciclo de desenvolvimento do Plano de Dados Aberto, gerando o PDA e monitorando os artefatos criados ao logo do processo, mas a aplicação se limita, hoje, a essa gerência do PDA, não executando tarefas complementares como a extração ou publicação de dados nas plataformas de dados abertos. Para executar essas ações, o ODM necessita do auxílio de aplicações externas.

Outro ponto é que a aplicação desenvolvida não trabalha ainda com a importação de arquivos para dar carga no modelo inventário de dados. Se um órgão público utiliza um SIG que não oferece nenhum tipo de integração com outro sistema, apenas exportando informações para arquivos, hoje, não conseguiremos trabalhar com esses arquivos. Tomando com exemplo uma prefeitura pequena que não tem um SIG instalado, trabalhando apenas com planilhas e documentos texto, é um exemplo de impedimento na utilização do Opendata Manager.

Por fim, os testes de performance mostraram que a aplicação tem um limite de usuários simultâneos, gerando lentidão no sistema ou até mesmo falha de requisições em alguns casos. Se a aplicação for utilizada como serviço, isso pode ser um problema futuramente.