OpenData Manager: Uma ferramenta para gerenciar o processo ...

Universidade Federal do Rio Grande do Norte Instituto Metrópole Digital

Programa de Pós-graduação em Tecnologia da Informação

Mestrado Profissional em Tecnologia da Informação

OpenData Manager: Uma ferramenta para gerenciar o processo de criação e monitoramento do Plano de

Dados Abertos

Fernando da Cruz Lopes

Natal / RN 2021



Dados Abertos

Dissertação de Mestrado apresentada ao Programa de Pós-graduação em Tecnologia da Informação da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Tecnologia da Informação.

Universidade Federal do Rio Grande do Norte – UFRN

Instituto Metrópole Digital – IMD

Programa de Pós-Graduação em Tecnologia da Informação

Orientador: Dr. Frederico Araújo da Silva Lopes Coorientador: Dr. André Gustavo Duarte de Almeida

Natal / RN

2021

Lopes, Fernando da Cruz. OpenData Manager: uma ferramenta para gerenciar o processo decriação e monitoramento do plano de dados abertos / Fernando daCruz Lopes. - 2021. 117 f.: il.

Dissertação (mestrado profissional) - Universidade Federal doRio Grande do Norte, Instituto Metrópole Digital, Programa dePós-Graduação em Tecnologia da Informação, Natal, RN, 2021. Orientador: Prof. Dr. Frederico Araújo da Silva Lopes. Coorientador: Prof. Dr. André Gustavo Duarte de Almeida.

1. Dados abertos - Dissertação. 2. Plano de dados abertos -Dissertação. 3. PDA - Dissertação. I. Lopes, Frederico Araújo daSilva. II. Almeida, André Gustavo Duarte de. III. Título.

RN/UF/BCZM CDU 004.6

Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede

Elaborado por Ana Cristina Cavalcanti Tinoco - CRB-15/262



Dados Abertos

Dissertação de Mestrado apresentada ao Programa de Pós-graduação em Tecnologia da Informação da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Tecnologia da Informação.

Dr. Frederico Araújo da Silva Lopes Orientador

Dr. André Gustavo Duarte de Almeida Coorientador

Dr. Itamir de Morais Barroca Filho

Membro Interno

Dr. Fellipe de Araújo Aleixo Membro Externo

Natal / RN 2021

Agradecimentos Começo agradecendo à Deus pelo dom da vida. Por me conceder sabedoria e me guiar durante o período do curso. Por me manter saudável e a minha família, em meio aos tempos difíceis que estamos vivendo. A minha esposa, Cristiane, pela paciência de aguentar minha inconstância de humor durante a produção deste trabalho. Pelo incentivo de sempre que foram fundamentais para que eu não perdesse o foco e seguisse em frente. Obrigado por sempre estar ao meu lado, pelo companheirismo e carinho de todo dia. Te amo. Ao meus pais, Ivone e Nilton, pelo apoio e incentivo em tudo que faço. Obrigado por serem a minha base para tudo o que busco na vida. Eu sei o sacrifício que vocês sempre fizeram para me dar a melhor educação. Obrigado por moldarem o meu caráter, para que eu pudesse ser o homem que sou hoje. Obrigado por tudo que vocês já fizeram por mim e que, eu tenho certeza, ainda irão fazer. Ao meu Irmão Christopher, ou Kité, e sua família linda. Eu sei que mesmo longe, sempre posso contar com você quando precisar. Saudades. A todos os meus colegas de trabalho do IFRN, em especial aos amigos da COSINF. Aprendi e aprendo muito com vocês todos os dias. Espero que esse tempo louco passe logo e que possamos nos reunir novamente na nossa sala para resenhar bastante. Não tenho como expressar o tamanho da minha gratidão ao meu orientador Fred. Eu estava perdido, sem saber muito bem o que fazer no final do curso e ele, com toda sua paciência soube conduzir todas as situações adversas da melhor forma possível para que eu não me perdesse na minha trajetória acadêmica. Muito obrigado. Agradeço também ao meu co-orientador André. Saiba que eu o admiro muito em seu trabalho dentro do IFRN, sempre conduzindo a TI da melhor forma possível. Apesar das inúmeras tarefas que seu cargo exige, você ainda aceito a me ajudar em meu trabalho de mestrado. Suas dicas no desenrolar da minha escrita foram sempre certeiras e me ajudaram a entender como desenvolver um texto científico. Muito obrigado. Enfim, gostaria de agradecer a todos que de uma forma ou de outra contribuíram para que meu trabalho fosse concluído.

"A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original".

Albert Einstein

Resumo

O acesso a informações públicas vem se mostrado de grande importância no estreitamento da relação sociedade e governo, possibilitando à sociedade uma maior interatividade nas ações públicas. O desenvolvimento de sistemas que utilizam esse tipo de informação a favor do bom uso dos recursos públicos é um dos vários exemplos que podemos utilizar para mostrar como é importante o acesso a esses dados. A partir do Decreto nº 8.777 que regulamentou a abertura dos dados públicos do Poder Executivo Federal, vários órgãos e entidades iniciaram suas atividades para disponibilizar seus dados. Todos os passos para a abertura desses dados são especificados no manual de implementação, da Política de Dados Abertos disponibilizado pela Controladoria Geral da União (CGU). Um dos passos para abertura dos dados é a escrita de todas as ações realizadas até a catalogação dos dados nas plataformas de dados abertos. O documento em que são registradas essas ações é chamado de Plano de Dados Abertos, ou PDA. A CGU considera que um órgão público tem seus dados abertos apenas quando o seu PDA é publicado seguindo a vários critérios de organização e qualidade. Atualmente, a CGU mantém um painel de monitoramento de dados abertos, onde é possível verificar quais entidades públicas tem seus dados disponibilizados seguindo esses critérios. Ao realizar uma consulta a esse painel, percebemos que menos da metade dos órgãos públicos tem um PDA publicado, onde, dos 223 órgãos do Poder Executivo Federal, apenas 84 tem um PDA em execução. Dos PDAs em execução, grande parte não disponibilizam um sistema de monitoramento das ações e metas definidas ao longo de sua elaboração, pois foram escritos em formato de texto simples, sem automatização alguma no processo de monitoramento, como a própria CGU sugere. Para resolver o problema de elaborar um Plano de Dados Abertos seguindo as recomendações da CGU de qualidade e monitoramento durante e posteriormente a elaboração do PDA, este trabalho tem por objetivo o desenvolvimento de uma aplicação que irá abarcar todos os passos descritos no manual de desenvolvimento de um PDA, assim como irá monitorar todas as ações que precisam ser realizadas durante e depois da catalogação dos dados abertos. A validação da aplicação será feita reescrevendo alguns PDA e verificando se os requisitos implementados são satisfatórios. Palavras-chave: Dados Abertos, Plano de Dados Abertos, PDA.

Abstract Access to public information has been shown to be of great importance in strengthening the relationship between society and government by enabling a greater interactivity in public actions by the society. The development of systems that use this type of information in favor of good use of public resources is one of several examples that can be used to show how important access to such a data is. After Decree nº 8,777, which regulated the opening of public data of Federal Executive Government, many institutions and entities started their activities to make their data available. All steps for opening the data are specified in the implementation manual of Open Data Policy made available by Office of the Comptroller General (OCG). One of the steps to open the data is the writing of all performed actions, until the cataloging of data on open data platforms. The document in which these actions are recorded is called Open Data Plan (ODP). OCG considers that a public institution has its data open only when its ODP is published accordingly to several organization and quality criteria. OCG currently maintains an open data monitoring panel, in which it is possible to check which public entities have their data made available following these criteria. By consulting this panel, it is observed that less than half of public institutions has a published ODP. Among 223 institutions of Federal Executive Government, only 84 has a published ODP. Among the published ODPs, most of them do not have an efficient system for monitoring actions and goals defined throughout its elaboration because they were written in plain text format, without any automation in the monitoring process, as suggested by OCG. To solve the problem of preparing the Open Data Plan accordingly to OCG quality and monitoring recommendations, both during and after the elaboration of the ODP, this work presents a tool that was developed to encompass all the steps described in the development manual of an ODP. The tool also allows the monitoring of all actions that need to be performed during and after cataloging the open data. Keywords: Open Data, Open Data Plan, ODP.

Lista de figuras

Figura 1 - Ilustração do processo sistêmico de um PDA ................................................ 28

Figura 2 - Ilustração da estrutura sugerida de um PDA ................................................. 31

Figura 3 - Ilustração da tabela de plano de ação de um PDA ......................................... 33

Figura 4 - Dashboard do SUAP ...................................................................................... 35

Figura 5 - Abrangência do SUAP ................................................................................... 36

Figura 6 - Diagrama de sequência para representar o padrão Message Broker ............. 38

Figura 7 – Visão macro do ODM no ambiente opendata ............................................... 65

Figura 8 - Destaque dos componentes internos do Opendata Manager ......................... 66

Figura 9 - Diagrama de classe resumindo do módulo PDA ........................................... 67

Figura 10 - Código exemplificando o agendamento de tarefas ...................................... 68

Figura 11 - Dashboard do OpenData Manager ............................................................... 72

Figura 12 - Listagem de grupo de trabalho com destaque para a opção de Finalizar Atividades. ...................................................................................................................... 73

Figura 13 - Informações cadastradas do SUAP. ............................................................. 75

Figura 14 - Listagem de inventário de dados com ênfase na ação "Selecionar Dados" . 75

Figura 15 - Lista de campos que são considerados sigilosos pelo SUAP. ..................... 76

Figura 16 - Matriz de priorização das bases de dados da CGU. ..................................... 77

Figura 17 - Formulário da matriz de priorização. ........................................................... 77

Figura 18 - Exemplo do formulário de escrita do PDA. ................................................. 79

Figura 19 - Integração ODM com ODP ......................................................................... 79

Figura 20 - Sequência de troca de mensagens entre as duas aplicações......................... 80

Figura 21 - Arquitetura stand-alone................................................................................ 81

Figura 22 - Arquitetura SaaS Single-tenant .................................................................... 82

Figura 23 - Arquitetura SaaS Multi-tenant ..................................................................... 82

Figura 24 - Ilustração da utilização de chave estrangeira ............................................... 83

Figura 25 - Ilustração da utilização de separação via schema ........................................ 84

Figura 26 - Ilustração da separação via banco de dados................................................. 84

Figura 27 – Parte do arquivo docker-compose.yml para ambiente ................................ 85

Figura 28 - Parte do arquivo docker-compose-prod.yml ................................................ 86

Figura 29 - Mapeamento das requisições no JMeter ...................................................... 89

Figura 30 - Monitoramento via ZABBIX ....................................................................... 91

Figura 31 - Monitoramento via JMeter........................................................................... 91

Figura 32 - Monitoramento do tempo de resposta .......................................................... 91

Figura 33 - Monitoramento via Zabbix .......................................................................... 92


Figura 35 - Monitoramento de tempo de resposta .......................................................... 92



Figura 38 - Monitoramento de tempo de resposta .......................................................... 93







Figura 45 - Consumo de processamento por usuários .................................................... 97

Figura 46 - Consumo de memória por usuários ............................................................. 97

Figura 47 - Tempo de resposta e percentual de erros por usuários ................................ 97

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

Lista de tabelas

Tabela 1 - Análises sobre os serviços de mensageria ..................................................... 42

Tabela 2 - Artigos selecionados na primeira pesquisa no Periódico da CAPES ............ 45

Tabela 3 - Artigos selecionados na segunda pesquisa do Periódico da CAPES ............ 46

Tabela 4 - Artigos selecionado na primeira consulta do ACM ...................................... 48

Tabela 5 - Artigos selecionados na segunda consulta do ACM ..................................... 49

Tabela 6 - Artigos selecionados na terceira consulta do ACM ...................................... 50

Tabela 7 -Primeira consulta no motor de busca IEEE Xplore ........................................ 52

Tabela 8 - Primeira consulta no motor de busca Google Scholar .................................. 53

Tabela 9 - Segunda consulta no motor de busca Google Scholar .................................. 54

Tabela 10 - Artigos sobre PDA que contribuíram para o trabalho ................................. 56

Tabela 11 – Artigos que contribuíram no entendimento sobre dados abertos governamentais ............................................................................................................... 56

Tabela 12 - Tabela de artigos que contribuíram a entender como os dados estão sendo disponibilizados para a sociedade................................................................................... 57

Tabela 13 - Tabela dos requisitos funcionais ................................................................. 60

Tabela 14 - Tabela de requisitos não funcionais ............................................................ 61

Tabela 15 - Tabela de requisitos de domínio .................................................................. 63

Tabela 16 - Tabela para levantamento de inventário das bases de dados. ...................... 74

Tabela 17 - Tabela de PDAs analisados com relação ao grupo de trabalho ................... 87

Tabela 18 - Resultado das rodadas de testes com 10 usuários ....................................... 90

Tabela 19 - Resultado das rodadas de testes com 20 usuários ....................................... 91

Tabela 20 - Resultados das rodadas de testes com 50 usuários ...................................... 92

Tabela 21 - Resultados das rodadas de testes com 100 usuários .................................... 94

Tabela 22 - Resultados das rodadas de testes com 500 usuários .................................... 95

Tabela 23 - Média dos resultados dos testes................................................................... 96

Lista de abreviaturas e siglas AMQP - Advanced Message Queuing Protocol

CAPTCHA - Completely Automated Public Turing test to tell Computers and Humans

Apart

CEAP - Cota para o Exercício da Atividade Parlamentar

CGINDA - Comitê Gestor da Infraestrutura Nacional de Dados Abertos

CGU - Controladoria Geral da União

CIGA - Comitê Interministerial Governo Aberto

CKAN - Comprehensive Knowledge Archive Network

CORBA - Common Object Request Broker Architecture

CSV - Comma-separated values

DAG - Dados Abertos Governamentais

ENAP - Escola Nacional de Administração Pública

HTML - HyperText Markup Language

IFRN - Instituto Federal de Ciência e Tecnologia do Rio Grande do Norte

INDA - Infraestrutura Nacional de Dados Abertos

ISO - International Organization for Standardization

JSON - JavaScript Object Notation

KML - Keyhole Markup Language

LAI - Lei de Acesso à Informação

LGPD - Lei Geral de Proteção de Dados Pessoais

ODM - OpenData Manager

ODP - OpenData Processor

OGP - Open Government Partnership

OKF - Open Knowledge Foundation

PDA - Plano de Dados Abertos

PDF - Portable Document Format

SIG - Sistemas Integrados de Gestão

SUAP - Sistema Unificado de Administração Pública

XML - Extensible Markup Language

Sumário

1 INTRODUÇÃO .................................................................................................................. 16 1.1 PROBLEMÁTICA E MOTIVAÇÃO ............................................................................. 18 1.2 OBJETIVOS ..................................................................................................................... 20 1.2.1 OBJETIVOS ESPECÍFICOS .................................................................................................. 20 1.3 METODOLOGIA ............................................................................................................. 21 2 REFERENCIAL TEÓRICO ............................................................................................. 22 2.1 DADOS ABERTOS .......................................................................................................... 22 2.2 DADOS ABERTOS GOVERNAMENTAIS ................................................................... 25 2.3 PLANO DE DADOS ABERTOS ..................................................................................... 26 2.3.1 PROCESSO SISTÊMICO DE UM PDA .................................................................................. 28 2.3.2 ESTRUTURA DO PDA ....................................................................................................... 30 2.4 SUAP – SISTEMA UNIFICADO DE ADMINISTRAÇÃO PÚBLICA ......................................... 34 2.5 INTEROPERABILIDADE .............................................................................................. 36 2.5.1 SERVIÇOS DE MENSAGERIA ..................................................................................... 37 2.5.1.1 Redis ............................................................................................................................. 39 2.5.1.2 RabbitMQ ..................................................................................................................... 40 2.5.1.3 Apache Kafka ............................................................................................................... 41 2.5.1.4 Análise sobre os serviços de mensageria ...................................................................... 41 2.5.2 DISCUSSÃO SOBRE AS ANÁLISES...................................................................................... 42 3 TRABALHOS RELACIONADOS ................................................................................... 44 3.1 INFORMAÇÕES GERAIS ...................................................................................................... 44 3.2 PESQUISA NOS MOTORES DE BUSCA ................................................................................. 45 3.2.1 PORTAL DE PERIÓDICOS DA CAPES (HTTPS://WWW.PERIODICOS.CAPES.GOV.BR/) ......... 45 3.2.2 ACM DIGITAL LIBRARY (HTTPS://DL.ACM.ORG) ............................................................ 47 3.2.3 IEEE XPLORE (HTTPS://IEEEXPLORE.IEEE.ORG/XPLORE/HOME.JSP) ............................... 51 3.2.4 GOOGLE SCHOLAR (HTTPS://SCHOLAR.GOOGLE.COM.BR/) ............................................. 52 3.3 OUTRAS PESQUISAS REALIZADAS .................................................................................... 55 3.4 CONCLUSÃO DA PESQUISA SOBRE TRABALHOS RELACIONADOS .................................... 56 4 PROPOSTA DE GERENCIAMENTO DO PROCESSO DE CRIAÇÃO E MONITORAMENTO DO PLANO DE DADOS ABERTOS ................................................ 60 4.1 REQUISITOS FUNCIONAIS ......................................................................................... 60 4.2 REQUISITOS NÃO FUNCIONAIS................................................................................ 61 4.3 REQUISITOS DE DOMÍNIO ......................................................................................... 63 4.4 IMPLEMENTAÇÃO DA PROPOSTA DE ELABORAÇÃO E MONITORAMENTO DO PLANO DE DADOS ABERTOS ........................................................................................ 65

5 OPENDATA MANAGER: UMA FERRAMENTA DE GERENCIAMENTO DO PROCESSO DE CRIAÇÃO E MONITORAMENTO DO PLANO DE DADOS ABERTOS................................................................................................................................... 70 5.1 FUNCIONALIDADE DO OPENDATA MANAGER ................................................... 71 5.1.1 ÁREA DE ACESSO PÚBLICO.............................................................................................. 71 5.1.2 ÁREA DE ACESSO RESTRITO ............................................................................................ 71 5.1.2.1 Grupo de Trabalho ........................................................................................................ 73 5.1.2.2 Definição do inventário de dados ................................................................................. 73 5.1.2.3 Consulta pública ........................................................................................................... 76 5.1.2.4 Elaborar a matriz de priorização ................................................................................... 76 5.1.2.5 Definir relação final das bases ...................................................................................... 78 5.1.2.6 Cronograma de abertura ............................................................................................... 78 5.1.2.7 Registro do Plano de Dados Abertos ............................................................................ 78 5.2 INTEGRAÇÃO ...................................................................................................................... 79 5.3 ARQUITETURA DO OPENDATA MANAGER ......................................................................... 80 5.3.1 ARQUITETURA STAND-ALONE ......................................................................................... 81 5.3.2 ARQUITETURA DE SOFTWARE COMO SERVICE (SAAS) ................................................... 81 5.3.2.1 Utilização de chave estrangeira .................................................................................... 83 5.3.2.2 Separação via schema ................................................................................................... 83 5.3.2.3 Separação via banco de dados ...................................................................................... 84 5.4 DEPLOY DO OPENDATA MANAGER .................................................................................. 84 5.5 AVALIAÇÃO DE PERFORMANCE........................................................................................ 86 5.5.1 OBJETIVOS .................................................................................................................... 86 5.5.2 CONFIGURAÇÕES E MÉTRICAS ............................................................................... 87 5.5.2.1 Configurações do JMeter .............................................................................................. 88 5.5.2.2 Configurações do ZABBIX .......................................................................................... 90 5.5.3 EXECUÇÃO DOS TESTES ............................................................................................ 90 5.5.3.1 Testes com 10 usuários virtuais simultâneos ................................................................ 90 5.5.3.2 Testes com 20 usuários virtuais simultâneos ................................................................ 91 5.5.3.3 Testes com 50 usuários virtuais simultâneos ................................................................ 92 5.5.3.4 Testes com 100 usuários virtuais simultâneos .............................................................. 94 5.5.3.5 Testes com 500 usuários virtuais simultâneos .............................................................. 95 5.6 ANÁLISE DA AVALIAÇÃO .................................................................................................. 97 5.7 CONCLUSÃO SOBRE A APLICAÇÃO NO GERAL ................................................................. 99 6 CONCLUSÕES ................................................................................................................. 101 6.1 LIMITAÇÕES..................................................................................................................... 101 6.2 TRABALHOS FUTUROS ............................................................................................. 102 7 REFERÊNCIAS ................................................................................................................ 104

8 APÊNDICES ..................................................................................................................... 109 8.1 APÊNDICE 1 – ROTEIRO DE TESTES DA APLICAÇÃO ..................................................... 110 8.2 APÊNDICE 2 – EXEMPLOS DE PDAS RECRIADOS A PARTIR DO OPENDATA MANAGER 116

16

1 INTRODUÇÃO

O acesso à informação, sobretudo governamental, tem sido de grande importância

na construção da relação da sociedade e governo, possibilitando a consulta e auditoria de

informações que antes não era possível. Com a disponibilidade desses dados é possível

elaborar aplicações que estreitam a relação cidadão com o governo, como é a “Operação

Serenata de Amor” (OPERAÇÃO..., 2016). A Operação Serenata de Amor é um projeto

onde se utiliza da inteligência artificial para analisar a Cota para o Exercício da Atividade

Parlamentar (CEAP). Com base em informações disponibilizadas em formato aberto, a

aplicação consegue extrair informações e, quando necessário, realizar denúncias do mau

uso dos recursos públicos.

Parte dos dados utilizados por esses tipos de aplicações são gerados por órgãos

públicos, que precisam disponibilizá-los de forma acessível a sociedade. O Decreto nº

8.777 (BRASIL, 2016), assinado pela Presidência da República em 11 de maio de 2016,

regulamentou a abertura dos dados públicos do Poder Executivo Federal, estabelecendo

as regras para essa abertura. O decreto também realiza a definição de alguns termos e,

dentre eles, define dados aberto como “dados acessíveis ao público, em meio digital,

estruturados em formato aberto, processáveis por máquina, referenciados na internet e

disponibilizados sob licença aberta que permita sua livre utilização, consumo ou

cruzamento, limitando-se a creditar a autoria ou a fonte” (BRASIL, 2016). A Open

Knowledge Foundation (OKF), uma organização sem fins lucrativos que tem como

objetivo a promoção e compartilhamento do conhecimento livre, define dados abertos

como “dados que podem ser livremente utilizados, reutilizados e redistribuídos por

qualquer pessoa, no máximo, à exigência de atribuição à fonte original e ao

compartilhamento pelas mesmas licenças em que as informações foram apresentadas”.

Nesta mesma linha de pensamento, dados abertos governamentais vem como uma

metodologia para a publicação de dados do governo, publicação esta que deve ser em um

formato reutilizável, tornando maior a transparência das informações e contribuindo para

o desenvolvimento de soluções úteis para a sociedade (DADOS..., 2019).

Na administração pública, abrir dados é uma obrigação legal. A Lei de Acesso à

Informação – LAI (BRASIL, 2011) se aplica aos órgãos públicos da administração direta

e entes da administração indireta dos Poderes Executivo, legislativo, incluindo as Cortes

17

de Contas, e Judiciário e do Ministério Público, em todas as esferas (art. 1ª, parágrafo

único). Ao abrir seus dados, os órgãos e entidades públicas e privadas devem observar

as legislações vigentes, como a Lei Geral de Proteção de Dados Pessoais (LGPD). A

LGPD foi sancionada em 14 de agosto de 2018 (Lei 13.709/2018) fazendo com que o

Brasil entrasse no rol de 120 países que possuem leis específicas para proteção de dados

pessoais. De um modo geral, “ela estabelece regras para como deve ser a coleta,

armazenamento, tratamento e compartilhamento de dados pessoais, impondo um padrão

mais elevado de proteção (NONES, 2020).”

Logo, as instituições são obrigadas a abrir seus dados, e, como descrito no Decreto

nº 8.777, um dos passos para a abertura dos dados é a criação do Plano de Dados Abertos

(PDA). O PDA é um documento orientador para as ações de implementação e promoção

de abertura de dados, obedecendo a padrões mínimos de qualidade, de forma a facilitar o

entendimento e a reutilização das informações (BRASIL, 2016). É ele quem organiza o

planejamento referente à implantação e racionalização dos processos de publicação de

dados abertos nas organizações públicas.

A Controladoria Geral da União (CGU) lançou em junho de 2017 o Painel

Monitoramento de Dados Abertos (PAINEL..., 2017), que apresenta o panorama da

abertura de dados no Poder Executivo Federal, permitindo conferir as bases de dados já

publicadas, os cronogramas de publicação e acompanhar o cumprimento da política de

dados abertos por diversos órgãos e entidades. Até o momento desta pesquisa,

conseguimos verificar no painel da CGU o acompanhamento de 223 entidades e órgãos

do Poder Público Federal. Desses, apenas 84 tem o seu PDA publicado atendendo aos

padrões mínimos de qualidade e acessibilidade previstos na Resolução nº 3 de 13 de

outubro de 2017, do Comitê Gestor da Infraestrutura Nacional de Dados Abertos –

CGINDA.

De um modo geral, o PDA é formulado manualmente, em um arquivo de texto

comum e esse documento é de difícil gerenciamento das bases contidas nele, tanto no que

diz respeito às informações de abertura, quanto a periodicidade que as informações e o

próprio PDA devem ser revisados e atualizados. Realizando pesquisas na literatura onde

foram selecionados 50 artigos para leitura, não foi possível localizar uma ferramenta que

forneça a funcionalidade de gerenciar o processo de criação do PDA, tornando possível

o monitoramento de cada item descrito deste documento. Dessa forma, o objetivo deste

trabalho é desenvolver uma ferramenta que seja capaz de auxiliar toda a criação de um

18

PDA, possibilitando também o monitoramento das bases que serão abertas e sugerir bases

para uma futura abertura.

Será desenvolvida uma aplicação web que irá gerenciar todo o processo sistêmico

de elaboração do PDA, cadastrando usuários que irão compor o grupo de trabalho,

configurando acesso a sistemas internos do órgão para obtenção de informações com

potencial de serem abertas, dentro outras funcionalidades. Buscando conhecimento sobre

o ambiente opendata e procurando por outras ferramentas com a mesma funcionalidade

de gerenciamento do PDA, realizamos uma pesquisa na literatura encontrando 50 artigos

que nos ajudaram a esclarecer como dados abertos são tratados no Brasil e no mundo e

como essas informações são disponibilizadas para os cidadãos. Com esse conhecimento,

foi possível elaborar uma aplicação seguindo as legislações vigentes e com uma maior

capacidade de se adaptar as necessidades dos diferentes órgãos públicos. Com a opção de

a aplicação funcionar como serviço, foi necessário realizar testes de performance para

avaliar como a ferramenta irá se comportar com uma quantidade elevada de usuários

simultâneos.

Sendo o idealizador deste trabalho funcionário do Instituto Federal de Ciência e

Tecnologia do Rio Grande do Norte (IFRN), conhecendo a realidade dos dados abertos

neste instituto e sendo integrante da equipe de Tecnologia da Informação, este trabalho

irá se valer de boa parte das informações e artefatos disponíveis no IFRN. O Plano de

Dados Abertos elaborado pelo instituto e atualmente em vigor será objeto de teste para

aplicação que será desenvolvida. Ainda sobre os institutos federais, a pesquisa terá um

escopo voltado a eles, mas não irá negligenciar outras instituições que fomentam a

abertura de dados.

1.1 PROBLEMÁTICA E MOTIVAÇÃO A partir do Decreto nº 8.777 assinado pela Presidência da República em 11 de

maio de 2016, decreto este que instituiu a Política de Dados Abertos do Poder Executivo

Federal, órgãos e entidades da administração pública federal direta, autárquica e

fundacional são obrigados a disponibilizarem os dados, que não estejam sob sigilo ou sob

restrição de acesso, contidos em seus bancos de dados sob a forma de dados abertos. O

Capítulo III, Artigo 5º deste mesmo Decreto, estabelece que a gestão da Política de Dados

Abertos do Poder Executivo federal será coordenada pela Controladoria-Geral da União

– CGU.

19

Dentre os Institutos Federais, a situação não é diferente, dos 38 Institutos que estão

sendo monitorados, 26 não tem PDA cadastrado ou seguindo as normas e padrões de

abertura, observação esta realizada junto ao Painel de Monitoramento de Dados Abertos

da CGU (PAINEL..., 2017). O Instituto Federal de Educação, Ciência e Tecnologia do

Rio Grande do Norte (IFRN) é um exemplo de instituto que tem o PDA publicado

seguindo os padrões definidos pelo Comitê Gestor da Infraestrutura Nacional de Dados

Abertos (CGINDA). Existe todo o processo de extração e publicação dos dados de forma

automatizada, porém, o PDA não tem nenhum tipo de monitoramento dessas bases

abertas, muito menos um monitoramento sobre o próprio documento do PDA.

Uma vez que o PDA do IFRN é publicado, os datasets que serão abertos tem que

ser cadastrados manualmente no módulo de extração das informações, o qual não tem

nenhum tipo de gerenciamento temporário de feedback para melhorar as informações

disponibilizadas. O módulo de extração trabalha independente do que está descrito no

PDA, abrindo margem para que os dados que estão descritos no PDA como dados que

estão abertos não estejam de fato.

O IFRN é um exemplo de instituto que tem seu PDA publicado e, tomando como

exemplo o processo de desenvolvimento desse PDA, não foi utilizada nenhuma solução

automatizada que gerencie o processo de criação e monitoramento. Atualmente, no

instituto federal existe uma solução que dá suporte ao processo de extração e publicação

de dados chamada Opendata Processor (VILELA, 2018), agendando períodos de extração

de algumas bases que já foram levantadas. Apesar deste PDA estar publicado em sua

plataforma de dados abertos, este não foi publicado no painel da CGU.

O Portal Brasileiro de Dados Abertos (Dados, 2020) disponibiliza atualmente em

seu site 20 aplicativos que fazem uso de dados aberto. Dentro esses aplicativos, podemos

destacar: 1) Coronavírus SUS – aplicativo criado pelo Ministério da Saúde que tem o

objetivo de conscientizar a população com informações sobre o novo Coronavírus,

informando também a população sobre as unidades de saúde mais próximas à localização

do usuário; 2) Operação Serenata de Amor – ferramenta que fiscaliza os reembolsos

efetuados por parlamentares, como custeio de alimentação, transporte e hospedagem a

fim de encontrar irregularidades; 3) QEdu – entrega de forma rápida e fácil informações

sobre Prova Brasil, Censo Escolar, Ideb e Enam de todas as escolar do Brasil; 4)

Monitora, Brasil! – ferramenta que possibilita monitorar as atividades de deputados

federais e senadores, possibilitando verificar a assiduidade e projetos propostos; 5)

20

Ciência Aberta é Vida – reúne diversas fontes de informação científica de acesso aberto

sobre o novo Coronavírus. Entre o conjunto de aplicativos disponível no portal, não foi

possível encontrar nenhuma ferramenta que dê suporte na elaboração do Plano de Dados

Abertos.

Pelo motivo de não encontrar nenhuma ferramenta catalogada com tal

funcionalidade, resolvemos entrar em contato com o Núcleo de Dados Abertos da

Controladoria Geral da União informando que estamos trabalhando em uma ferramenta

que auxilia a elaboração do PDA. Questinamos como o PDA do órgão é elaborado,

perguntando se este é construindo com o auxílio de alguma ferramenta. Em resposta, a

CGU elogiou a iniciativa de elaborar uma ferramenta para este fim e informou que não

possuem nenhuma ferramenta auxiliar no processo de construção do Plano de Dado

Aberto.

1.2 OBJETIVOS O objetivo geral deste trabalho é facilitar o desenvolvimento completo de um PDA

e tornar possível o monitoramento de cada item elencado neste documento através de uma

aplicação que será desenvolvida seguindo os padrões descritos no manual da CGU. Além

disso, também iremos complementar o ambiente opendata com a nossa solução, que será

capaz de se integrar a outras tornando este ambiente mais completo.

1.2.1 Objetivos Específicos

Os objetivos específicos deste trabalho são:

1. Identificar as formas possíveis de integração entre os sistemas de informação já

existentes, as plataformas de dados abertos e a aplicação proposta;

2. Desenvolver uma ferramenta que gerencie todo o processo de criação do PDA e

os datasets descritos nele;

3. Realizar a validação da ferramenta desenvolvida;

4. Realizar a avaliação e comparação entre a ferramenta desenvolvida e as

ferramentas já existentes no mercado, caso encontremos alguma;

21

1.3 METODOLOGIA

Tendo em vista que a aplicação que será desenvolvida neste trabalho terá

integração com diferentes outras aplicações, tais com as plataformas de dados abertos e

sistemas integrados de gestão (SIGs), foi realizada uma pesquisa sobre o assunto,

resultando em diferentes técnicas que ajudam na integração com esses sistemas. Dentre

as técnicas estudadas, estão a base de dados compartilhada (shared database),

transferência de arquivo (file transfer) e mensageria (messaging).

Também foi necessário realizar uma revisão bibliográfica a respeito de dados

abertos, tentando especificar as buscas para dados abertos governamentais, o que nos deu

uma visão do que outras entidades pelo mundo esperam conseguir abrindo seus dados e

como o PDA é importante neste processo. A partir das leituras realizadas foi possível

identificar vários pontos monitoráveis que podem ser implementados na ferramenta

proposta, além do desenvolvimento de um PDA muito mais eficiente do ponto de vista

das instituições.

A partir da visão geral de como entidades do mundo desenvolvem o Plano de

Dados Abertos, foi possível pensarmos em uma arquitetura que dê suporte ao

desenvolvimento deste documento de forma computacional, não mais de uma forma

manual e sem um gerenciamento eficaz das informações descritas neste.

Para validar a ferramenta proposta, vamos reescrever alguns PDAs (Apêndice 2 –

ExemploS de PDAS Recriados a partir do Opendata Manager), testando cada base de

dados, itens das bases e o próprio documento, criando versões deles e gerando o

documento final. Também será necessário testar a integração que a ferramenta deve ter

com os sistemas de extração e publicação dos dados e integração com SIGs. A solução

proposta deverá integrar-se com esses sistemas ou incorporar algumas funcionalidades

que a possibilite de se tornar independente de aplicações externas. Para realizar essas

tarefas específicas, deverão ser desenvolvidos módulos que as fazem. Logo, a ferramenta

proposta deverá ser modular, podendo assim expandir sua capacidade de ações

relacionadas a dados abertos. Os módulos a serem desenvolvidos devem seguir o padrão

do Django Framework.

22

2 REFERENCIAL TEÓRICO No referencial teórico fazemos um resumo dos principais assuntos relacionados

ao trabalho.

2.1 DADOS ABERTOS

Segundo a Open Definition (Open Definition, 2014), dados abertos são dados que

podem ser livremente utilizados, reutilizados e redistribuídos por qualquer pessoa –

sujeitos, no máximo, à exigência de atribuição à fonte original e ao compartilhamento

pelas mesmas licenças em que as informações foram apresentadas. O Decreto nº 8.777 de

11 de maio de 2016, Artigo 2º, estabelece ainda que: “dados” são sequência de símbolos

ou valores, representados em qualquer meio, produzido como resultado de um

processamento natural ou artificial. Já “dados abertos” são dados que estão acessíveis ao

público, disponíveis de forma digital, estruturados em formado aberto, processáveis por

máquina, referenciados na internet e disponibilizados sob licença aberta que permita sua

livre utilização, consumo ou cruzamento, limitando-se a creditar a autoria ou a fonte.

Tanto a Open Definition quanto o Decreto nº 8.777 são claros quanto as condições

para que um dado seja considerado aberto, porém, muitos desses dados disponíveis

publicamente não estão realmente abertos, sendo estes disponibilizados em tabelas

HTML (HyperText Markup Language), em arquivo PDF (Portable Document Format)

ou em ambientes que impeçam o acesso direto aos dados com a implementação de

CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans

Apart) ou outras técnicas que não permitam múltiplas requisições.

É perceptível que a abertura dos dados está interessada em evitar um mecanismo

de controle e restrição sobre dos dados que serão publicados, permitindo que qualquer

pessoa possa explorar esses dados de forma livre. Por esta perspectiva, a definição do

termo dados abertos carrega três normas fundamentais (Open Knowledge Foundation,

2010):

x Disponibilidade e acesso: os dados devem estar disponíveis como um

todo e sob custo não maior que um custo razoável de reprodução, e

preferencialmente devem ser possíveis de ser baixados pela Internet. Os

dados devem também estar disponíveis de uma forma conveniente e

modificável.

23

x Reuso e redistribuição: os dados devem ser fornecidos sob termos que

permitam a reutilização e a redistribuição, inclusive a combinação com

outros conjuntos de dados.

x Participação universal: todos devem ser capazes de usar, reutilizar e

redistribuir – não deve haver discriminação contra áreas de atuação ou

contra pessoas ou grupos. Por exemplo, restrições de uso “não comercial”

que impediriam o uso “comercial”, ou restrições de uso para certos fins

(ex.: somente educativos) excluem determinados dados do conceito de

“abertos”.

Logo, o ativista de dados abertos David Eaves resumiu essas normas em três

“leis” da seguinte forma (PORTAL BRASILEIRO DE DADOS ABERTOS, 2019):

1. Se o dado não pode ser encontrado ou indexado na Web, ele não existe;

2. Se o dado não está disponível num formato aberto e legível por máquina,

ele não pode ser reutilizado;

3. Se dispositivos legais não permitem que ele seja compartilhado, ele não é

útil.

Além das leis, são também amplamente conhecidos, no contexto do ecossistema

de dados abertos, os "Oito Princípios de dados abertos”, elaborados em meados de 2007,

por um grupo de trabalho de cerca de 30 pessoas, que se reuniram numa cidade da

Califórnia nos Estados Unidos (PORTAL BRASILEIRO DE DADOS ABERTOS,

2019). No entendimento deles, a internet permite aos governos compreenderem melhor

as necessidades da sociedade e, dessa forma, a sociedade pode participar ativamente do

governo. O entendimento desse grupo em relação aos DAG é que eles possibilitam o

acompanhamento do uso mais eficiente dos recursos públicos e podem promover a

melhoria do bem-estar público. Os princípios de dados abertos definidos por eles são:

x Completos: os dados são considerados completos quanto o conjunto todo

é disponibilizado, e não apenas uma parte dele. Por exemplo: os conjuntos

de dados são disponibilizados em sua série histórica e não apenas algumas

vezes, ou seja, se o órgão possui um conjunto de dados de 2000 até 2014,

deve-se abrir todos, não somente de 2010 até 2014, por exemplo.

x Primários: são dados que, da mesma forma que foram coletados da fonte,

deverão ser disponibilizados, não podendo haver nenhuma transformação

das informações. Caso o órgão ou entidade ache importante a agregação

24

de informações, é recomendado a publicação das duas formas, dados

brutos e agregados.

x Atuais: os dados são disponibilizados o quão rapidamente seja necessário

para preservar o seu valor. Assim, os órgãos públicos devem oferecer

ferramentas e especificações técnicas para que os dados possam ser

publicados com qualidade e de forma rápida e segura para a sociedade.

x Acessíveis: os dados são disponibilizados para o público mais amplo

possível e para os propósitos mais variados.

x Processáveis por máquina: os dados são razoavelmente estruturados para

possibilitar o seu processamento automatizado, de forma a permitir a

análise de grandes quantidades de registros sem intervenção manual.

Então, no processo de disponibilização, devem-se considerar vários

formatos abertos, como, por exemplo: csv, xml, json, kml; pois um único

formato pode prejudicar a utilização dos dados por um grupo de pessoas

(por falta de conhecimento), e em outros casos faltaria estruturação para

manipular os arquivos.

x Acesso não discriminatório: os dados estão disponíveis a todos, sem que

seja necessária identificação, registro ou cadastro.

x Formato não proprietário: os dados estão disponíveis em um formato

sobre o qual nenhuma entidade tem controle exclusivo. A disponibilização

de conjuntos de dados em formatos de arquivos proprietários pode gerar

dependência tecnológica para o uso das informações, o que restringiria o

acesso aos dados. Com isso, os dados devem estar estruturados e

organizados para facilitar sua manipulação por softwares diversos. A título

de exemplo, documentos disponibilizados em formato PDF não permitem

nenhuma estrutura que possa ser analisada por um software.

x Livres de licenças: os dados não estão sujeitos a regulações de direitos

autorais, marcas, patentes ou segredo industrial. Restrições razoáveis de

privacidade, segurança e controle de acesso podem ser permitidas na

forma regulada por estatutos.

Uma instituição ou órgão público que inicia o processo de abertura de dados,

seguindo essas três leis fundamentais, torna possível que outras organizações consigam

25

trabalhar de forma colaborativa devido a capacidade de diferentes sistemas interoperar

sobre os dados que foram abertos.

2.2 DADOS ABERTOS GOVERNAMENTAIS Segundo o Portal de Dados Abertos do Governo Federal (DADOS..., 2019), dados

abertos governamentais são uma metodologia para a publicação de dados de governo em

formatos reutilizáveis, visando o aumento da transparência e maior participação política

por parte do cidadão no desenvolvimento/conhecimento de políticas públicas, além de

gerar diversas aplicações desenvolvidas colaborativamente pela sociedade.

Em 2009 surge a iniciativa Open Data (OPEN KNOWLEDGE FOUNDATION,

2009), como é conhecido em inglês, que movimenta comunidades em todo o mundo para

cobrar informações públicas dos governos. Dessa forma os cidadãos podem colaborar

com os processos de governo e com o controle social das políticas. No caso do Brasil,

vários órgãos da Administração Pública já publicam seus dados na web, na forma de

relatórios e balanços para que os cidadãos possam acompanhar os resultados das ações

de governo.

Embora no Brasil já existam, hoje em dia, várias iniciativas governamentais

relacionadas a dados abertos, somente no ano de 2011, em reconhecimento às iniciativas

na área de transparência pública, o Brasil foi convidado pelo Governo dos Estados Unidos

para presidir junto a ele a Open Government Partnership (OGP) e a Parceria para o

Governo Aberto. A Parceria para Governo Aberto é uma iniciativa internacional que

pretende difundir e incentivar práticas governamentais relacionadas à transparência dos

atos do governo e ao acesso às informações públicas, ao combate à corrupção, à

participação social e ao fomento de novas tecnologias, de maneira a tornar os governos

mais abertos, efetivos e responsáveis (GOVERNO ABERTO, 2012).

Em meio a essas condições, o Decreto s/nº de 15 de setembro de 2011, o governo

brasileiro instituiu o primeiro Plano de Ação sobre Dados Abertos, onde é tratado todos

os compromissos e medidas a serem tomadas na área da transparência pública. No

referido Decreto é estabelecido o Comitê Interministerial Governo Aberto (CIGA),

responsável por promover a difusão e a implementação do Plano de Ação junto a

sociedade e órgãos governamentais.

26

Os efeitos dos dados abertos governamentais sobre as políticas públicas podem

ser sentidos em diversos pontos (DADOS..., 2019):

x Inclusão: Fornecer dados em formatos padronizados abertos e acessíveis

permite que qualquer cidadão utilize qualquer ferramenta de software para

adaptá-los às suas necessidades.

x Transparência: Informações do setor público abertas e acessíveis

melhoram a transparência, pois as partes interessadas podem usá-las da

maneira mais adequada ao seu propósito.

x Responsabilidade: Os conjuntos apropriados de dados abertos,

devidamente associados, podem oferecer vários pontos de vista sobre o

desempenho dos governos no cumprimento de suas metas em políticas

públicas.

A abertura de dados não traz benefícios apenas aos cidadãos, mas também para a

própria administração pública. Os dados podem, por exemplo, aumentar a eficiência do

governo, uma vez que, ao tornar as informações públicas, a quantidade de dúvidas da

população provavelmente cairá, diminuindo a carga de trabalho de alguns funcionários,

que poderão se dedicar a outras atividades (ANTUNES, 2017). Além disso, as análises e

estudos feitos por terceiros auxiliam o governo a avaliar suas políticas públicas e serviços,

apontando ao poder público o que não está dando certo e o ajudando a descobrir como e

onde devem ser feitas melhorias. Isso também contribui para a eficiência do serviço

público e para a redução de custos.

Embora todo o dado governamental tenha uma vocação para ser dado aberto, nem

todo dado público é um dado aberto (DADOS..., 2019). Entende-se por “dado público”

qualquer dado, gerado pelo governo ou sob sua guarda, que não tenha seu acesso restrito

por legislação específica.

2.3 PLANO DE DADOS ABERTOS

O Plano de Dados Abertos (PDA) é o documento orientador, que define as ações

de implementação e promoção de abertura de dados dos órgãos e entidades públicas

(PLANO..., 2018). Os dados devem obedecer aos padrões mínimos de qualidade, de

forma a facilitar o entendimento e sua reutilização por qualquer pessoa ou sistemas. Este

documento organiza o planejamento referente à implantação e à racionalização dos

27

processos de publicação de dados abertos nas organizações públicas. Ele é um documento

de planejamento institucional que os órgãos públicos utilizam para incluir o tema Dados

Abertos Governamentais (DAG) em suas atividades (PLANO..., 2018).

De acordo com o Decreto no 8.777/2016, a publicação do PDA é obrigatória para

os órgãos da Administração Pública federal direta, autárquica e fundacional, conforme o

Artigo 5º dessa legislação. Os dispositivos específicos que tratam do plano são os

seguintes:

§ 2o A implementação da Política de Dados Abertos ocorrerá por meio da execução de Plano de Dados Abertos no âmbito de cada órgão ou entidade da administração pública federal, direta, autárquica e fundacional, o qual deverá dispor, no mínimo, sobre os seguintes tópicos: I - criação e manutenção de inventários e catálogos corporativos de dados; II - mecanismos transparentes de priorização na abertura de bases de dados, os quais obedecerão os critérios estabelecidos pela INDA e considerarão o potencial de utilização e reutilização dos dados tanto pelo Governo quanto pela sociedade civil; III - cronograma relacionado aos procedimentos de abertura das bases de dados, sua atualização e sua melhoria; IV - especificação clara sobre os papéis e responsabilidades das unidades do órgão ou entidade da administração pública federal relacionados com a publicação, a atualização, a evolução e a manutenção das bases de dados; V - criação de processos para o engajamento de cidadãos, com o objetivo de facilitar e priorizar a abertura da dados, esclarecer dúvidas de interpretação na utilização e corrigir problemas nos dados já disponibilizados; e VI - demais mecanismos para a promoção, o fomento e o uso eficiente e efetivo das bases de dados pela sociedade e pelo Governo. § 3o A INDA poderá estabelecer normas complementares relacionadas com a elaboração do Plano de Dados Abertos, bem como relacionadas à proteção de informações pessoais na publicação de bases de dados abertos nos termos deste Decreto.

A elaboração do plano vem ao encontro do disposto na Lei de Acesso à

Informação, na Instrução Normativa SLTI nº 4, de 12 de abril de 2012 (que institui a

Infraestrutura Nacional de Dados Abertos - INDA), bem como nos compromissos

assumidos pelo Brasil no âmbito da Parceria para Governo Aberto, entre outros

normativos que abordam o tema de transparência. Além disso, a construção dos PDAs

tem o potencial de gerar um aprendizado coletivo, que pode ser utilizado futuramente

para a formulação de uma proposta de política nacional, pois é desejável que os órgãos

construam seus planos de forma colaborativa.

Para a elaboração do PDA é necessário um momento anterior onde a instituição

implemente as políticas de dados abertos. Trata-se de um processo que inclui todas as

ações que o órgão ou entidade deve ter cuidado ao implementar uma política de dados

abertos. Também é neste momento em que se destaca a elaboração do Plano de Dados

28

Abertos como um documento guia, central, onde são divulgados os compromissos e

prazos para a sua execução.

2.3.1 Processo Sistêmico de um PDA

Como podemos observar na Figura 1, é no processo sistêmico onde

exemplificamos, de forma ampla, todas as ações que o órgão ou entidade deve se atentar

na implementação da política de dados abertos.

Figura 1 - Ilustração do processo sistêmico de um PDA

Fonte: Imagem retirada do site do Portal de Dados Abertos do Governo do Brasil 1

Cada uma dessas atividades tem função específica no processo de elaboração de

um plano de dados abertos, segundo explicado no portal governamental Kit para dados

abertos (Brasil, 2020) e no Manual para Elaboração do PDA (ELABORAÇÃO..., 2017):

x Apresentar a política de dados abertos

Sendo o primeiro passo do processo sistêmico, é onde serão apresentadas a

política de dados a abertos e a motivação para criação do PDA. Segundo o manual

da ENAP (ELABORAÇÃO..., 2017), é nesta etapa onde deve ser apresentado

que o Plano de Dados Abertos tem uma estreita ligação com as expectativas

1 Disponível em: <https://kit.dados.gov.br/Processo-sist%C3%AAmico/>. Acessado em: 03 ago. 2020.

29

estratégicas do órgão. Todos os outros passos do processo deverão ser produzidos

em ressonância com as diretrizes estratégicas do órgão.

x Definir ponto focal

É nesta etapa onde é definido os responsáveis pela elaboração do PDA,

responsáveis estes que deverão ter uma boa interação com as outras áreas do

órgão, assim como interagir com outras organizações, como a INDA, para troca

de experiências e alinhamento das políticas de dados abertos. Ainda segundo o

manual da ENAP, também é desejável que os responsáveis tenham conhecimento

dos sistemas e banco de dados mantidos na instituição, assim como familiaridade

com conceitos relacionados a acesso à informação.

x Identificação dos representantes das áreas do órgão

É nesta etapa onde será identificado os detentores dos conhecimentos necessários

para construção do PDA. Segundo o Portal Kit para Dados Abertos do governo

federal (Brasil, 2020), é necessário identificar as áreas ou setores da instituição

com concentram informações úteis no desenvolvimento do PDA, como: (i)

Serviço de Informação ao Cidadão - onde é concentrada as solicitações da

sociedade; (ii) Ouvidoria - onde podem ser encontradas mais solicitações

realizadas pelos cidadãos; (iii) Área de Tecnologia de Informação - para acesso

as bases de dados de onde as informações serão extraídas. Segundo o manual da

ENAP, nesta etapa do processo, cada área de negócio dos órgãos têm um papel

fundamental por conhecerem seus dados e informações.

x Realização de oficinas

A realização de oficina, segundo o Portal Kit de Dados Abertos (Brasil, 2020),

serve para a construção do PDA seguindo o Manual de elaboração do PDA. É

dividida em dois momentos: (i) alinhamento dos conceitos sobre o tema; (ii)

construção do PDA e início dos planejamentos.

x Elaboração do PDA

Segundo o manual da ENAP, é nesta etapa que se que são realizados os principais

passos para a elaboração do PDA, desde a organização do inventário de dados e

a priorização deles até a definição da estratégia de abertura, do cronograma e dos

marcos. Como podemos perceber na Figura 1 – Ilustração do processo sistêmico

30

do PDA, é recomendado que seja realizada uma reunião dos responsáveis pelo

desenvolvimento do PDA pelo menos uma vez ao ano, para revisão do

documento.

x Publicação do documento

A publicação do PDA nada mais é do que disponibilizar o documento, nos

formatos HTML e PDF na página da instituição.

x Execução do PDA

Segundo o manual da ENAP, nesta fase, as áreas selecionadas para elaborar o

PDA devem realizar reuniões periódicas para revisar as metas estabelecidas para

o desenvolvimento do PDA. Também é nesta fase a divisão das responsabilidades

de cada área, onde ficará definido o papel de cada uma no desenvolvimento do

Plano de Dados Aberto.

Agora que sabemos os passos para se produzir o PDA, precisamos entender a sua

estrutura e o que é necessário estar descrito em cada uma das áreas específicas deste

documento.

2.3.2 Estrutura do PDA

Como o próprio nome diz, a estrutura do PDA nada mais é do que a organização

dos tópicos deste documento. Segundo o manual desenvolvido pela ENAP

(ELABORAÇÃO..., 2017) e o manual de elaboração de Planos de Dados Abertos

mantido pela CGU (CGU, 2020), a estrutura é dividida em nove partes (tópicos), como

exemplificado na Figura 2:

31

Figura 2 - Ilustração da estrutura sugerida de um PDA

Fonte: Módulo de elaboração do PDA - ENAP2

Embora a estrutura de um Plano de Dados Abertos seja bem simples, é

necessário conhecer melhor o conteúdo que de cada tópico. Seguindo o exemplo

disposto no manual da ENAP, vamos adotá-lo para exemplificar cada tópico, realizando

comparação de cada tópico com o que diz no manual da CGU.

o Apresentação

Esta fase não está presente no manual da GCU, mas é introduzido no manual

elaborado pela ENAP (ELABORAÇÃO..., 2017) que descreve esta seção como

responsável por expor os propósitos do PDA da organização, e seu alinhamento com as

legislações vigentes (leis, decretos e instruções normativas).

o Introdução

Segundo a CGU (CGU, 2020), na introdução, é onde se apresenta, de forma breve,

“o conteúdo e o propósito do documento mencionando os dispositivos legais que regem

a Política de Dados Abertos (Decreto no 8.777/2016, Decreto no 9.903/2019 e Resolução

no 3/2017 do CGINDA)”. Vale ressaltar que esta definição da CGU descrita na

“Introdução” já é abarcada na seção “Apresentação” no manual da ENAP.

Também é importante frisar que a ENAP expande esta seção, atribuindo a ela

subseções como Objetivos Gerais e Objetivos Específicos. Já a CGU orienta, através de

seu manual, criar um tópico específico para os objetivos.

o Definição dos dados a serem abertos

2 Disponível em: <http://repositorio.enap.gov.br/handle/1/3153>. Acesso em: 18 mar. 2020.

32

A ENAP descreve esta etapa como sendo o momento onde é apresentado os

conjuntos de dados que estão cotados a serem abertos, e os dados com possibilidade de

serem abertos. Também são apresentados os critérios utilizados na seleção desses

conjuntos. O manual da ENAP e CGU concordam nos seguintes critérios para priorização

dos dados: (i) Grau de relevância para o cidadão (Resolução Nº 3, Art. 1º, I, § 1º); (ii)

Estímulo ao controle social (Resolução Nº 3, Art. 1º, II); (iii) Obrigatoriedade legal ou

compromisso assumido de disponibilização daquele dado (Resolução Nº 3, Art. 1º, III);

(iv) Dado se referir a projetos estratégicos do governo (Resolução Nº 3, Art. 1º, IV); (v)

Dado se referir a projetos estratégicos do governo (Resolução Nº 3, Art. 1º, IV); (vi) Sua

capacidade de fomento ao desenvolvimento sustentável (Resolução Nº 3, Art. 1º, VI);

(vii) Possibilidade de fomento a negócios na sociedade (Resolução Nº 3, Art. 1º, VII);

(viii) Dados mais solicitados em transparência passiva desde o início da vigência da Lei

nº 12.527, de 18 de novembro de2011 - Lei de Acesso à Informação (Resolução Nº 3,

Art. 1º, VIII).

No manual da CGU não há um tópico exatamente com este nome. O tópico que

se assemelha a este é o “Dados selecionados para abertura”, onde orienta a apresentação

dos dados que serão abertos e a importância de compartilhar a matriz de priorização

utilizada para selecionar os conjuntos de dados mais relevantes, conforme o Art. 1º da

Resolução nº 3/2017 do CGINDA.

o Estratégia para abertura

Para a ENAP, esta é a etapa onde se descreve todos os passos realizados para a

execução do Plano de Dados Abertos. A CGU explica da mesma forma esta etapa.

o Catalogação no Portal Brasileiro de Dados Abertos

Tanto a ENAP (ELABORAÇÃO..., 2017) quanto a CGU (CGU, 2019) definem

esta etapa como sendo o passo de registro das bases de dados no Portal Brasileiro de

Dados Abertos.

o Monitoramento e Controle

No manual da ENAP, a fase de Monitoramento e Controle é destinada a monitorar

as ações previstas no PDA. Também frisa a importância de gerar relatórios periódicos

sobre a publicação dos dados, contentos, principalmente, dados estatísticos de consulta

às bases.

33

A CGU também enfatiza a importância dos relatórios de acompanhamento

periódico, conforme orientação do Art. 5º §4º, IV do Decreto no 8.777/2016. Destaca

também a importância de acompanhar as demandas da sociedade encaminhadas ao órgão,

proveniente de reclamações sobre algum conjunto de dados abertos. Além desses pontos,

a CGU ressalta a responsabilidade sobre o conteúdo dados como sendo da área finalística,

cabendo a área de tecnologia de informação apenas o suporte na disponibilização desses

dados.

o Sustentação

A CGU não define uma seção específica para este tópico, abarcando a sustentação

juntamente com o monitoramento e controle das ações do Plano de Dados Abertos. A

ENAP esclarece que nesta etapa é preciso manter uma melhoria constante dos dados que

foram publicados e devidamente catalogados.

o Plano de Ação

A ENAP descreve esta etapa com a fase de detalhamento das atividades e os

artefatos produzidos na realização dessas atividades. Definição de prazos, metas e

gerenciamento de atualizações dos dados também fazem parte desta fase. No manual da

ENAP é exposto um exemplo de plano de ação, como pode ser visto na Figura 3.

Figura 3 - Ilustração da tabela de plano de ação de um PDA

Fonte: Módulo de elaboração de um PDA - ENAP3

3 Disponível em: <http://repositorio.enap.gov.br/handle/1/3153>. Acesso em: 18 mar. 2020.

34

O manual da CGU detalha um pouco mais esta fase, dividindo o Plano de Ação

em três cronogramas distintos:

1. Cronograma de elaboração e sustentação do PDA: onde é informadas as

etapas realizadas na construção do PDA;

2. Cronograma de abertura de bases: cronograma responsável por manter a

programação do órgão para a publicação das bases selecionadas. É

estipulado um período de 2 anos, a contar da publicação do PDA,

conforme o Art. 4º da Resolução nº 3/2017 do CGINDA;

3. Cronograma de promoção, fomento, uso e reuso das bases: onde deve ser

registrada as ações de promoção, uso e reuso das bases de dados, conforme

descrito no Art. 4º da Resolução nº 3/2017 do CGINDA.

o Glossário

Para a ENAP, é dado ênfase ao glossário, sendo um tópico isolado. Destina-se a

registrar as palavras-chaves do PDA e suas definições. Para a CGU, o glossário também

existe, sendo uma subseção do tópico “Anexos”.

o Referências

Assim como o tópico anterior, no manual da CGU a seção “Referências” é uma

subseção do Tópico “Anexos”. Está seção é onde se registra todas as referências utilizadas

na elaboração do Plano de Dados Abertos (ELABORAÇÃO..., 2017).

2.4 SUAP – SISTEMA UNIFICADO DE ADMINISTRAÇÃO PÚBLICA

O SUAP, Sistema Unificado de Administração Pública (Figura 4), é um sistema

que gerencia praticamente todo o Instituto Federal do Rio Grande do Norte (IFRN).

Desenvolvido na linguagem de programação Python e utilizando o framework Django, é

mantido pela equipe de Técnicos e Analistas do IFRN desde 2007, sendo aperfeiçoado

para atender todas as ações realizadas pela Reitoria, Diretorias Sistêmicas e Direções

Gerais dos Campi (VILELA - 2018).

35

Figura 4 - Dashboard do SUAP

Fonte: Elaborada pelo autor.

Sendo um sistema modular, já foram desenvolvidos cerca de 50 módulos para

gerenciar as mais diversas áreas do IFRN. Do cargo chefe da instituição, que é o ensino,

a gestão de documentos eletrônicos, o SUAP integra basicamente todos os setores do

instituto. Ainda conta com interfaces de comunicação e importação de dados para a

possibilidade de leitura e extração de informações de sistemas externos governamentais,

como o SIAPE4 e SIGEPE5.

Por ser responsável em gerir todo o instituto federal, o SUAP dispõe de uma base

de dados bem ampla, com informações de todo o tipo e que, com os cuidados devidos,

podem ser potencialmente conjuntos de dados aptos a serem abertos.

Em negociação com Ministério da Educação (MEC) e IFRN, foi acordado de

disponibilizar o SUAP para outras instituições de ensino em caráter experimental com o

objetivo de, no futuro, transformá-lo em Sistema de Administração padrão para a Rede

Federal. Atualmente, cerca de 30 instituições já estão utilizando o SUAP em todo o Brasil,

como podemos observar na Figura 5 (VILELA - 2018).

4 Disponível em: http://www.siapenet.gov.br/Portal/Servico/Apresentacao.asp. Acesso em: 12 ago. 2020. 5 Disponível em: https://www.gov.br/servidor/pt-br/acesso-a-informacao/gestao-de-pessoas/sigepe. Acesso em: 12 ago. 2020.

36

Figura 5 - Abrangência do SUAP

Fonte: Elaborada pelo Autor baseado no mapa do SUAP de VILELA - 2018

2.5 INTEROPERABILIDADE

A interoperabilidade é a capacidade de diversos sistemas e organizações

trabalharem em conjunto (interoperar), de modo a garantir que pessoas, organizações e

sistemas computacionais interajam para trocar informações de maneira eficaz e eficiente

(INTEROPERABILIDADE..., 2020). Segundo François B. Vernadat (VERNADAT,

1996), é importante não confundir o termo interoperabilidade e integração, que, embora

sejam utilizados comumente como sinônimo, têm conceitos distintos. VERNADAT

afirma que integração facilita o acesso a informação e, consequentemente, melhora a

comunicação, cooperação e coordenação dentro da empresa ou organização.

O governo brasileiro fundamenta seu entendimento de interoperabilidade nos

quatro conceitos apresentados abaixo (GOVERNO FEDERAL, 2019):

1. "Intercâmbio coerente de informações e serviços entre sistemas. Deve possibilitar a

substituição de qualquer componente ou produto usado nos pontos de interligação por

outro de especificação similar, sem comprometimento das funcionalidades do

sistema" (Governo do Reino Unido).

37

2. "Habilidade de transferir e utilizar informações de maneira uniforme e eficiente entre

várias organizações e sistemas de informação" (Governo da Austrália).

3. "Habilidade de dois ou mais sistemas (computadores, meios de comunicação, redes,

software e outros componentes de tecnologia da informação) de interagir e de

intercambiar dados de acordo com um método definido, de forma a obter os resultados

esperados" (ISO).

4. "Interoperabilidade define se dois componentes de um sistema, desenvolvidos com

ferramentas diferentes, de fornecedores diferentes, podem ou não atuar em conjunto".

(Lichun Wang, Instituto Europeu de Informática - CORBA Workshops).

A interoperabilidade pode contribuir para uma maior integração entre gestão,

sociedade civil e comunidade, interação que se julga essencial à implantação e

consolidação da governança pública. Os diversos benefícios que a interoperabilidade dos

sistemas de governo pode trazer podem ser divididos em dois eixos principais: Benefícios

para a Gestão Pública e Benefícios Técnicos.

Hoje em dia, integração de aplicativos é baseada em uma diversidade de

tecnologias, como mediadores de mensagens (message broker), adaptadores (adapters) e

ebXML para incorporar sistemas. Essas tecnologias alcançam integração em diferentes

níveis, isto é, dados, mensagem, objeto, interface e/ou nível de processo. No entanto, não

existe uma única tecnologia de integração que suporte eficientemente todos os níveis de

integração (S. Duke, P. Makey, N. Kiras. – 1999; T. Puschmann, R. Alt – 2001).

2.5.1 SERVIÇOS DE MENSAGERIA

Com uma necessidade cada vez mais crescente das aplicações se comunicarem

entre si, soluções tecnológicas vão surgindo para nos apoiar nessas situações. O uso de

um middleware de mensageria simplifica esses desafios e uma infraestrutura de

comunicação comum que pode facilmente ser escalável para atender as condições mais

exigentes. Essas comunicações podem acontecer das mais variadas formas, e os

middleware de mensageria dão suporte a essas diversas formas (E. S. Pramukantoro, J.

Ratna Wulandari, W. Yahya and H. Nurwarsito - 2018).

Um método de comunicação usado pelos middlewares de mensageria é um que

usa um Message Broker. Com um Message Broker, o aplicativo de origem (produtor)

envia uma mensagem para um processo do servidor que pode fornecer empacotamento,

38

roteamento, tradução de mensagens, persistência e entrega de dados para todos os

destinos apropriados (consumidores), como podemos observar na Figura 6. A

característica definidora de um Message Broker é que o próprio broker é um serviço

discreto. Produtores e consumidores se comunicam com o broker usando protocolos

padrão ou proprietários.

Figura 6 - Diagrama de sequência para representar o padrão Message Broker

Fonte: Imagem retirada do site wikipedia6.

O Message Broker normalmente fornece todo o gerenciamento e rastreamento de

estado dos clientes, para que aplicativos individuais não precisem assumir essa

responsabilidade e a complexidade da entrega de mensagens é incorporada por ele (E. S.

Pramukantoro, J. Ratna Wulandari, W. Yahya and H. Nurwarsito - 2018). Existem duas

formas básicas de comunicação com um Message Broker:

6 Disponível em: <https://en.wikipedia.org/wiki/Message_broker#/media/File:Message_Broker.png>. Acesso em: 13 Jun. 2020.

39

x Publish and Subscribe (Topics)

Em um sistema do tipo publish/subscribe, os produtores enviam mensagens sobre

um tópico. Nesse modelo, o produtor é conhecido como editor e o consumidor é

conhecido como assinante. Um ou muitos editores podem publicar no mesmo tópico, e

uma mensagem de vários editores pode ser recebida por muitos assinantes. Os assinantes

assinam tópicos, e todas as mensagens publicadas no tópico são recebidas por todos os

assinantes no tópico. Esse modelo fornece entrega simples orientada a interesses, com

base nos tópicos em que os aplicativos se inscrevem (G. Cugola, A. Margara and M.

Migliavacca - 2009).

x Point-to-Point (Queues)

As comunicações ponto a ponto, na sua forma mais simples, têm um produtor e

um consumidor. Esse estilo de mensagem geralmente usa uma fila para armazenar

mensagens enviadas pelo produtor até que sejam recebidas pelo consumidor. O produtor

da mensagem envia a mensagem para a fila; o consumidor da mensagem recupera

mensagens da fila e envia uma confirmação de que a mensagem foi recebida. Mais de um

produtor pode enviar mensagens para a mesma fila e mais de um consumidor pode

recuperar mensagens da mesma fila. Quando vários consumidores são usados, cada

consumidor geralmente recebe uma parte do fluxo de mensagens para permitir o

processamento simultâneo (Järvelä, A., & Lindmark, S. - 2019).

Portanto, foi necessária buscar na literatura os serviços de mensagerias mais

utilizados na comunidade, realizar uma análise sobre as características de cada um, para

que possamos escolher o que melhor se adequa a nossas pretensões.

2.5.1.1 Redis

O Redis é um software de código aberto de armazenamento de estrutura de dados

em memória, usado como banco de dados, cache e mediador de mensagens. Ele suporta

estruturas de dados como strings, hashes, listas, conjuntos, conjuntos classificados com

consultas de intervalo, bitmaps, hiperloglog, índices geoespaciais com consultas e fluxos

de raio. O Redis possui replicação embutida, scripts Lua, descarte de mensagens mais

antigas (less recently used - LRU), transações e diferentes níveis de persistência em disco

40

e fornece alta disponibilidade via Redis Sentinel e particionamento automático com Redis

Cluster (RedisLabs - 2017).

Ele trabalha com um conjunto de dados na memória. Dependendo do seu caso de

uso, você pode persistir um conjunto de dados no disco de vez em quando ou escrevendo

cada comando a um log. A persistência pode ser opcionalmente desabilitada, se você

precisar apenas de um cache rico em recursos, em rede, na memória.

O Redis também suporta replicação assíncrona trivial de configuração master-

slave, com primeira sincronização muito rápida, reconexão automática com

ressincronização parcial na divisão da rede.

2.5.1.2 RabbitMQ

O RabbitMQ é um software open source de mensageria. Fornece uma forma de

comunicação assíncrona de dados entre processos, aplicações ou servidores. É um dos

brokers de mensagens mais utilizados e implementa o protocolo AMQP — Advanced

Message Queueing Protocol. O AMQP nasceu da necessidade de interoperabilidade de

diferentes middlewares de mensagens assíncronas. Sendo mais específico, embora

existissem vários padrões de middleware para mensagens síncronas (por exemplo, IIOP,

RMI, SOAP, etc.), o mesmo não se aplicava ao mundo das mensagens assíncronas, além

de vários produtos proprietários usarem seus próprios protocolos fechados, por exemplo,

IBM Websphere MQ e Microsoft Message Queuing (S. Vinoski - 2006).

O RabbitMQ vai além das garantias da AMQP em vários aspectos: possui um

mecanismo de reconhecimento mais eficiente para os editores, um comportamento

transacional mais bem definido, um melhor suporte à transferência assíncrona de lotes,

um certo grau de engajamento entre produtores e consumidores (RabbitMQ - 2020).

Este sistema de mensageria é implementado em Erlang, o que implica que ele usa

o Actor Model (modelo de atores) como comunicação primária entre processos Erlang.

Portanto, ele se beneficia da infraestrutura da Open Telecom Platform (OTP) dessa

linguagem, que facilita muito a criação e o gerenciamento de arquiteturas de alta

disponibilidade. Erlang e o modelo de ator são as principais razões para os recursos de

escalabilidade do RabbitMQ em termos de número de tópicos e filas, e trazem recursos

de cluster com uma sobrecarga muito baixa (RabbitMQ - 2020).

41

2.5.1.3 Apache Kafka

O Apache Kafka é uma plataforma distribuída de transmissão de dados que é

capaz de publicar, subscrever, armazenar e processar fluxos de registro em tempo real.

Essa plataforma foi desenvolvida para processar fluxos de dados provenientes de diversas

fontes, bem como para entregá-los a vários clientes. Em resumo, o Apache Kafka

movimenta volumes imensos de dados não apenas do ponto A ao ponto B, mas também

de A a Z e para qualquer outro local que você precisar simultaneamente.

Ele é uma alternativa aos sistemas de mensageria corporativos tradicionais que,

inicialmente, foi desenvolvido pela LinkedIn para processar 1,4 trilhão de mensagens por

dia, mas agora é uma solução de transmissão de dados open source aplicável a variadas

necessidades corporativas (K. Goodhope - 2012).

Comparado aos sistemas tradicionais de publish/subscribe (pub/sub), a noção de

consumidor do Kafka é generalizada como um grupo de processos cooperativos em

execução como um cluster. Cada mensagem no tópico é entregue a um consumidor em

cada um desses grupos de consumidores. Como resultado, a partição é a unidade de

paralelismo do tópico e controla o paralelismo máximo dos consumidores. Além disso,

como cada partição possui um único consumidor em seu grupo, o processo de consumo

pode preguiçosamente registrar sua própria posição, em vez de marcar cada mensagem

imediatamente, o que é essencial para o desempenho. Se o processo travar antes que a

posição seja registrada, apenas reprocessará um pequeno número de mensagens.

2.5.1.4 Análise sobre os serviços de mensageria

Segundo Itzkovich (2019), para escolher um broker que irá trabalhar executando

tarefas assíncronas, devemos levar em consideração as seguintes características:

x Broker Scale: o número de mensagens enviadas por segundo no sistema;

x Data persistency: capacidade de recuperar mensagens;

x Consumer Capability: capacidade do broker em gerenciar mensagens um para

um e/ou um para muitos.

A Tabela 1 apresenta um comparativo das características dos brokers para

subsidiar o processo de escolha. As informações coletadas levam em consideração

42

informações de documentação oficial dos softwares em questão, e informações

comparativas realizadas por Itzkovich (2019).

Tabela 1 - Análises sobre os serviços de mensageria

Broker Broker Scale Data Persistency Consumer Capability Redis pode enviar até um

milhão de mensagens por segundo

basicamente não, é um armazenamento em memória

suporta ambos

Apache Kafka

pode enviar até milhões de mensagens por segundo

sim suporta apenas um para muitos

RabbitMQ a estimativa é de cerca de 50k de mensagens por segundo

são suportadas mensagens persistentes e transitórias

suporta ambos

Fonte: Elaborada pelo autor baseada nas informações de Itzkovich (2019).

2.5.2 Discussão sobre as análises

O Kafka se mostrou um serviço de mensageria de alto desempenho, com a

capacidade de armazenamento de uma grande quantidade de dados por um longo período.

Ele é ideal para situações em que o fluxo de mensagens é extremamente alto. Dada as

características observadas e considerando o contexto do trabalho, esse broker seria

subutilizado na solução do problema.

O Redis tem características semelhantes ao Kafka, suportando milhões de

mensagens por segundo, além de ter muitos outros recursos, como um sistema de cache

em memória. Na tabela de comparação entre as ferramentas de mensageria, podemos

observar que o Redis persiste seus dados em memória, e isso pode ser um problema,

segundo FARIA (2019). “Essa característica de manter os dados em memória é perfeita

para processamento de dados em tempo real, mas, em casos de shutdown, a chance de

perda de mensagens é muito grande”. Logo, embora o Redis possua recursos para ser uma

escolha interessante para o projeto, assim como o Kafka, seria subutilizado para o que

pretendemos. Outro ponto em desfavor é o fato da persistência em memória, onde não

podemos aceitar uma chance tão grande de perda de mensagens.

O RabbitMQ é um broker mais antigo, porém maduro e com muitos recursos. Ele

também suporta comunicação de roteamento complexo quando a taxa necessária não é

alta (mais do que algumas dezenas de milhares de mensagens por segundo). O protocolo

43

AMQP, que é implementado pelo RabbitMQ, permite a troca de mensagens assíncronas

entre diferentes aplicações e/ou serviços. Por persistir seus dados, é resiliente a falhas de

qualquer ponto do sistema. Devido a essas características, vamos utilizá-lo neste trabalho

como parte integrante do projeto.

44

3 TRABALHOS RELACIONADOS Nesta seção iremos apresentar todo o processo de seleção dos artigos estudados

neste trabalho, apontando os critérios de seleção e exclusão e como a triagem inicial se

deu para o levantamento de informações relevantes. É importante ressaltar que o trabalho

de revisão dos artigos não é sistemática, é apenas uma revisão de literatura para

entendermos como o assunto dados abertos e plano de dados abertos estão sendo

explorados no Brasil e no mundo.

3.1 INFORMAÇÕES GERAIS

Para conhecermos com mais detalhes o assunto “dados abertos” e “PDA” foi

necessário realizar um levantamento bibliográfico utilizando os mais diversos motores de

busca afim de encontrar artigos relevantes sobre o assunto. O objetivo principal deste

levantamento é encontrar e analisar artigos que explanem de alguma forma como o Plano

de Dados Abertos é tratado no Brasil e no mundo. Entender como os governos tratam

dados abertos e quais ferramentas utilizam para esta finalidade. Além disso, vamos

observar também como as informações abertas são disponibilizadas para a sociedade.

Para iniciar a nossa pesquisa, definimos alguns critérios para seleção dos artigos:

x decidimos, a princípio, não restringir por período de tempo para que

pudéssemos encontrar o maior número de artigos possíveis sobre o

assunto;

x não foi feito nenhuma restrição por idiomas, com o mesmo intuito de

conseguir abarcar o máximo de artigos possíveis;

x selecionar artigos cujo título tenha relação com o tema de interesse, e;

x excluir artigos cujo resumo mostre que o assunto abordado dentro do

artigo não tenha relação com dados abertos governamentais.

Com esses critérios, elaboramos as strings de busca sempre pensando em atendê-

los para que os artigos viessem com menos ruídos possíveis. Entende-se por ruído os

artigos cujo conteúdo não tenho relação com o assunto deste trabalho. Tentamos elaborar

uma string genérica, que fosse aceita no maior número de motores de busca possível sem

a necessidade de alterá-la.

45

Foi percebido que apenas uma string de busca não estava retornando artigos com

conteúdo relevante. Logo, foi necessário implementar 3 strings de busca para cada motor.

Também escolhemos 4 motores de buscas para realizar a nossa pesquisa, sendo eles: 1)

Portal de Periódico da Capes; 2) IEEE Xplore; 3) ACM Digital Library, e; 4) Google

Scholar.

3.2 PESQUISA NOS MOTORES DE BUSCA

Nesta seção iremos detalhar os motores utilizados em nossa pesquisa e como

ficaram as strings de buscas utilizadas.

3.2.1 Portal de Periódicos da Capes (https://www.periodicos.capes.gov.br/)

Iniciamos nosso trabalho de pesquisa buscando por artigos nos periódicos da

capes, onde desenvolvemos a seguinte string de busca em português primeiramente:

("dados abertos" OR "dados abertos governamentais" OR "dados abertos governamental") AND

("plano de dados abertos" OR "PDA" OR "plano dados abertos"). Definimos a população e

intervenção por meio de sinônimos para que pudéssemos selecionar o maior número de

artigos possíveis.

A string mencionada retornou um total de 10 artigos, que foram ordenados por

relevância. Dos 10 artigos, apenas 7 tratavam de fato sobre dados abertos e destes, 6 foram

revisados por pares. Por ser uma consulta realizada com uma string em português, todos

os 7 artigos selecionados são de autores nacionais, o que nos deu uma visão, ainda que

reduzida, do panorama de algumas instituições nacionais acerca de como estão

trabalhando com dados abertos.

Tabela 2 - Artigos selecionados na primeira pesquisa no Periódico da CAPES

Título do artigo Autores Considerações / Temática I Open Data Day Natal - 2018 - A Iniciativa do Plano de Dados Abertos do TCE/RN e o seu papel no Controle Social

Frederico Nunes do Pranto Filho

Resumo superficial sobre dados abertos, os oito princípios e as três leis. Governo aberto. Situação atual de um órgão público quanto a dados abertos.

Open Access at Embrapa: brief history, recent advances and challenges

Marcos Cezar Visoli; Patrícia Rocha Bello Bertin; Alessandra Rodrigues Silva; Cláudia Regina De Laia Machado; Luís Eduardo Gonzales; Isaque Vacari

Iniciativa de uma empresa pública quanto a dados abertos. Publicação de repositório com iniciativa de projetos internos.

46

Open Data Plan at the Federal university of Pernambuco – uFPe

Bernadette Farias Lóscio; Susimery Vila Nova

Iniciativa de desenvolvimento do Plano de Dados Abertos da Universidade de Pernambuco. Destaca as prioridades da continuidade do processo de abertura e garantida da qualidade dos dados.

Analysis of the implementation of the Open Data Policy in the Federal Executive Government

Janaina Dos Santos Melo; Maria Fernanda Mascarenhas Dos Santos Melis

Analisa as estratégias que estão sendo adotadas com relação a dados abertos governamentais.

I Congresso do Grupo de Pesquisa Democracia e Tecnologia - 2018 - A Iniciativa do Plano de Dados Abertos do TCE/RN e o seu papel no Controle Social

Frederico Nunes do Pranto Filho

Informações sobre dados abertos e situação do desenvolvimento do Plano de Dados Abertos de um órgão público.

A iniciativa da construção do Plano de Dados Abertos do Tribunal de Contas do Rio Grande do Norte através de uma parceria acadêmica com a Universidade Federal do Rio Grande do Norte

Frederico N Pranto; Renan Oliveira; Lindemberg Silva Pereira

Estratégias adotadas para elaboração e publicação de dados abertos. Planejamentos futuro com relação a dados abertos do órgão público.

Modelo de dados abertos conectados para informação legislativa

Mariana Baptista Brandt

Visão sobre dados aberto e dados abertos conectados.

Fonte: Elaborada pelo autor

Uma segunda string foi utilizada, desta fez em inglês: ("open data" OR

"government open data") AND ("plan" OR "data plan" OR "open data plan" OR

"government open data plan"). A consulta retornou 6415 artigos, dos quais 5.527 são

revisados em pares. Vários artigos foram selecionados para leitura de acordo com seu

título e abstract. Um artigo da Universidade Federal de Pernambuco chamou a atenção,

por explanar os passos de construção do seu PDA.

Tabela 3 - Artigos selecionados na segunda pesquisa do Periódico da CAPES

Título do artigo Autores Considerações / Temática Building up an Open Data Plan for a public Research and Development organization and the challenge of an Open Agricultural Science

Patrícia Rocha Bello Bertin; Claudia Delaia Machado; Marcos Cezar Visoli; Debora Pignatari Drucker; Daniela Maciel Pinto

Elaboração do Plano de Dados Abertos de uma empresa pública. Ferramentas utilizadas na implantação.

4 Tenets of a Successful Open Data Plan

Shueh, Jason; Nova visão de triagem das bases de dados que integram o inventário.

Open data value capability architecture

Zeleti, Fatemeh; Ojo, Adegboyega

Visão de como obter valor dos dados abertos. Exemplifica técnicas de mapeamento em uma arquitetura que é elaborada na pesquisa.

Open Data as a Foundation for Innovation: The Enabling Effect of Free Public Sector Information for Entrepreneurs

Lakomaa, Erik; Kallberg, Jan

Destaca a importância de dados abertos para algumas startups suecas. O texto indica ainda um crescimento dos interesses de empresas em pagar pelos dados públicos.

Smart Mobility Trends: Open Data and Other Tools

Soriano, Francisco R; Samper-Zapater, Juan Javier; Martinez-Dura, Juan Jose; Cirilo-

Detalha como dados abertos da administração pública pode auxiliar no processo de transformação das cidades europeias em Smart cities.

47

Gimeno, Ramon V; Martinez Plume, Javier

Share useful resources for research: Open dataCompartir los recursos útiles para la investigación: datos abiertos (open data)

Aleixandre-Benavent, R.; Ferrer Sapena, A.; Peset, F.

Detalha vantagens e desvantagens da abertura de dados. Detalha também a construção de um plano de gerenciamento de dados, que se assemelha com um PDA.

Applying fuzzy logic to open data for sustainable development decision-making: a case study of the planned city Amaravati

Bick, Ian; Bardhan, Ronita; Beaubois, Terry

Mostra como utilizar dados abertos no planejamento do uso da terra e risco de inundação em uma cidade da Índia.

PROPOSAL FOR THE CREATION OF AN OPEN DATA NETWORK IN BRAZILIAN RESEARCH/PROPUESTA DE CREACION DE UNA RED DE DATOS ABIERTOS DE LA INVESTIGACION BRASILENA/PROPOSTA DE CRIACAO DE UMA REDE DE DADOS ABERTOS DA PESQUISA BRASILEIRA

Pavao, Caterina Groposo; Da Rocha, Rafael Porte; Gabriel, Rene Faustino, Jr.

Necessidade de torna públicos dados de instituições de ensino e pesquisa. A pesquisa busca soluções tecnológicas para a abertura dos dados de pesquisa.

HIV Open Data Project: CMS Implementation Plan of Common Core HIV/AIDS Indicators; Archival Version

United States Department of Health and Human Services. Centers for Medicare and Medicaid Services 2013

Utiliza dados abertos de uma instituição médica para criar um CSM que ajuda na disponibilização de relatórios relacionados a pacientes com HIV, levando em consideração dados que são sigilosos, por se tratar de dados de saúde.


3.2.2 ACM Digital Library (https://dl.acm.org)

Para este motor de busca começamos a aplicar a consulta utilizando três strings

de busca diferentes para encontrar o máximo de artigos possíveis com conteúdos

relevantes.

x Consulta com a primeira string String utilizada: [[[All: "dados abertos"] OR [All: "dados abertos

governamentais"] OR [All: "dados abertos governamental"]] AND [All: (]] OR [All: (]

OR [All: "plano de dados abertos"] OR [All: "pda"] OR [All: "open data plan"] OR [All:

"plano dados abertos"].

Usando os mesmos termos da string de busca utilizada no periódico da capes,

porém, alterando a sintaxe, este motor de busca nos apresentou 9029 artigos, mesmo a

consulta sendo em sua imensa maioria composta por sentenças em português. Nesta

primeira busca, foi percebido que a palavra-chave “PDA” estava trazendo muito ruído ao

contexto da consulta e foi removido da string de busca.

48

A nova string de busca ficou da seguinte forma: [[[All: "dados abertos"] OR [All:

"dados abertos governamentais"] OR [All: "dados abertos governamental"]] AND [All:

(]] OR [All: (] OR [All: "plano de dados abertos"] OR [All: "open data plan"] OR [All:

"plano dados abertos"].

Ao remover a palavra-chave “PDA” da consulta, houve uma redução substancial

de artigos listados, trazendo agora a quantidade 45 artigos. Não por coincidência, vários

artigos foram produzidos por pesquisadores brasileiros e todos esses artigos foram

analisados. Alguns foram descartados apenas com a leitura do resumo e introdução, por

fugirem do contexto esperado, que são dados abertos governamentais e, mais

especificamente, o plano de dados abertos. Nenhum dos artigos explanam de forma direta

o PDA ou seu processo de elaboração.

Tabela 4 - Artigos selecionado na primeira consulta do ACM

Título do artigo Autores Considerações / Temática A framework for constructing open data map visualizations

Victor Santos, Pedro Camara, Flavia Bernardini, Jose Viterbo, Douglas Jorge

Abordam as dificuldades em interpretar os conjuntos de dados abertos por instituições públicas. Tem a proposta de um framework que trabalhe com visualizações de dados.

ArgumentBind - A Model for Implementing Argument Web Integrated Applications with Open and Linked Data

Roberto Niche, Sandro J. Rigo

Realiza uma abordagem sobre linked data.

Open Data Extraction, Transformation, and Loading as a Tool for Supporting 2018 Elections' Voters

Nélson R. S. Passos, Ariel F. Rodrigues, Hendrik T. Macedo, Bruno O. P. Prado, Gilton J. F. da Silva, Leonardo N. Matos

Aplica o método de extração, transformação e publicação de dados abertos a fim de dar mais clareza aos cidadãos com relação as escolhas dos processos eleitorais.

Open government data in Brazil a systematic review of its uses and issues

Emilio Feliciano de Oliveira, Milene Selbach Silveira

Visão de como o governo federal está tonando visível seus dados aos cidadãos. Explora iniciativas de abertura de dados por parte do governo federal.

Understanding and Predicting the Legislative Process in the Chamber of Deputies of Brazil

Danilo Amaral de Oliveira, João Porto de Albuquerque, Alexandre C. B. Delbem

Através de consultas a dados abertos governamentais, tentam traçar uma metodologia capaz de indicar pontos positivos e negativos na aprovação de um projeto de lei.


x Consulta com a segunda string String utilizada: ("open data" OR "government open data") AND ("plan" OR

"data plan" OR "open data plan" OR "government open data plan")

49

O próprio mecanismo de pesquisa transformou a sintaxe da string em uma sintaxe

aceita por ele, que ficou desta forma: [[All: "open data"] OR [All: "government open

data"]] AND [[All: "plan"] OR [All: "data plan"] OR [All: "open data plan"] OR [All:

"government open data plan"]].

A segunda string de busca nos apresentou um total de 1.268 artigos. Como

nenhuma restrição de tempo foi feita a priori, resolvemos restringir a nossa consulta nos

últimos 5 anos, obtendo assim artigos mais recentes. Mesmo com a restrição temporal,

um número muito grande de artigos foi encontrado, um total de 759. Logo, foi necessário

realizar uma triagem dos artigos, classificando-os pelo título e abstract que combinassem

com o esperado na pesquisa, buscando sempre alguma menção sobre dados abertos ou

plano de dados abertos.

Foram selecionados 13 artigos com menção sobre dados abertos governamentais

dos mais diferentes países, como Brasil, Taiwan, Coreia do Sul, Uruguai, China, Austrália

e Estados Unidos.

Tabela 5 - Artigos selecionados na segunda consulta do ACM

Título do artigo Autores Considerações / Temática A theoretical framework for evaluating government open data platform

Pin-Yu Chu, Hsien-Lee Tseng

Exemplifica que o sucesso dos dados aberto está na facilidade de acesso às informações. Nos mostra um panorama dos dados governamentais de Taiwan.

Open data collaborations: a snapshot of an emerging practice

Thomas Olsson, Per Runeson

Aborta o assunto da maturidade dos dados abertos colaborativos.

Open data publishing by public libraries

Nicholas Weber, Bree Norlander

Realiza um apurado sobre dados abertos das bibliotecas americana. Informa que nem a metade delas tem dados aberto publicados.

Open Data Policy Innovation Diffusion: An Analysis of Australian Federal and State Governments

Akemi Takeoka Chatfield, Christopher G. Reddick

Faz um paralelo entre a eficácia de algumas agências e departamentos Australianos com a abertura de dados abertos.

Agile production of high-quality open data

Renato De Donato, Giuseppe Ferretti, Antonio Marciano, Giuseppina Palmieri, Donato Pirozzi, Vittorio Scarano, Luca Vicidomini

Apresenta uma metodologia ágil para abertura de dados abertos.

User Acceptance of Open Data Portals in Korea: The Role of Policy Tools

Heyseoung Jo, J. Ramon Gil-Garcia

Elabora um método que consegue mensurar a aceitação de determinados conjuntos de dados por parte dos cidadãos. Panorama sobre dados Abertos da Coreia do Sul

Open Data and Open Government: From Abstract

Evgeny Styrin, Luis F. Luna-Reyes, Teresa M. Harrison

Realiza uma comparação nas implementações de políticas de dados

50

Principles to Institutionalized Practices

abertos nos países do México, Estados Unidos e Rússia.

Making Open Data Work for Civic Advocacy

Aare Puussaar, Ian G. Johnson, Kyle Montague, Philip James, Peter Wright

Explora a dificuldade de acessibilidade dos dados abertos a cidadãos comuns. Elabora uma ferramenta que ajuda os cidadãos a compreender os conjuntos de dados.

US open data policy: advances and recommendations

Luis F. Luna-Reyes Avalia o panorama atual dos dados abertos governamentais do Estados Unidos e sugere melhorias em alguns processos.

Open data and crowdsourcing perspectives for smart city in the United States and Russia

Alexander Nikiforov, Anastasija Singireja

Mostra a evolução dos processos de abertura de dados e a implementação de tecnologias de crowdsourcing na Rússia e no Estados Unidos.

The role of open data in enabling fiscal transparency and accountability in municipalities in Africa: South Africa and Nigeria case studies

Paul Kariuki, Jude A. Adeleke, Lizzy Oluwatoyin Ofusori

Mostra a importância dos dados abertos no monitoramento de orçamento, possibilitando ao cidadão opinar onde o orçamento será gasto.

Correlational Analysis Between School Performance and Municipal Indicators in Brazil Supported by Linked Open Data

Bruno Elias Penteado Utiliza-se de dados aberto conectados para traças um panorama da qualidade do ensino municipal do Brasil. Utiliza-se de indicadores específicos para a educação.

Open Data for Development: Experience of Uruguay

Victoria Köster, Gustavo Suárez

Descreve os processos adotados pelo governo uruguaio, viabilizando a implementação dos dados abertos.


Os artigos se mostraram interessantes por nos apresentar uma visão geral de como

outros países estão tratando sobre dados abertos governamentais. Embora a maioria dos

artigos encontrados com essa string de busca retratarem informações sobre dados abertos,

apenas 2 artigos nacionais mencionam o documento e sua importância, mas não pontuam

detalhes de implementação deste.

x Consulta com a terceira string String utilizada: ("open data plan" OR "open plan data" OR "data open plan" OR

"data plan open" OR "plan open data" OR "plan data open")

Esta consulta retornou apenas 4 registros, sendo que 2 foram descartados por fazer

parte das consultas anteriores. Logo, esta nova consulta adicionou mais 2 artigos a nossa

pesquisa.

Tabela 6 - Artigos selecionados na terceira consulta do ACM

Título do artigo Autores Considerações / Temática Towards an expanded and integrated open government data agenda for India

Sumandro Chattapadhyay

Análise da política de dados abertos do governo da Índia.

51

Open Budget effects for Urban development: Russia's cases

Radomir Bolgov, Marina Ermolina, Natalia Vasilyeva

Discuti sobre os reais efeitos da implementação da política de dados abertos na Rússia e os reais efeitos socioeconômico causados por essa iniciativa.


3.2.3 IEEE Xplore (https://ieeexplore.ieee.org/Xplore/home.jsp)

Seguindo o mesmo padrão de string utilizado no motor de pesquisa anterior,

realizamos 3 buscas com 3 strings diferentes.

x Consulta com a primeira string

String utilizada: ("dados abertos" OR "dados abertos governamentais" OR "dados

abertos governamental") AND ("plano de dados abertos" OR "PDA" OR "open data plan"

OR "plano dados abertos")

O motor de busca IEEE Xplore se mostrou mais restritivo com relação a busca

por artigos com a língua portuguesa, e, ao contrário dos outros motores utilizados até o

momento nesta pesquisa, não retornou nenhum registro com a primeira string de busca.

Resolvemos simplificar a string para analisar o resultado, deixando a string de busca da

seguinte forma: ("dados abertos" OR "dados abertos governamentais" OR "dados abertos

governamental”). Esse rearranjo nos retornou apenas um artigo, ainda assim, fora do

contexto pretendido desta pesquisa. Logo, a primeira string de busca se mostrou

ineficiente para este motor de busca.

x Consulta com a segunda string

String utilizada: ("open data" OR "government open data") AND ("plan" OR

"data plan" OR "open data plan" OR "government open data plan")

A segunda string de busca encontrou 23 artigos. Deste, 9 artigos foram

descartados pelo critério de repetição (já foram selecionados em buscas anteriores em

outros motores de busca). Dos 14 artigos restantes, mais 9 foram removidos pelo critério

de contexto, pois não abordam dados abertos no contexto governamental, tão pouco

explanam sobre plano de dados abertos.

Dos 5 artigos restantes, nos foi apresentados mais visões sobre como dos dados

abertos estão sendo trabalhos no governo do Estados Unidos e Tailândia.

52

Tabela 7 -Primeira consulta no motor de busca IEEE Xplore

Título do artigo Autores Considerações / Temática Open Data as a Foundation for Innovation: The Enabling Effect of Free Public Sector Information for Entrepreneurs

Erik Lakomaa; Jan Kallberg

Faz uma análise sobre as afirmações de os dados abertos serem um meio de prestação de contas do governo para o cidadão.

Systematic Mapping of Open Data Studies: Classification and Trends From a Technological Perspective

Robert Enríquez-Reyes; Susana Cadena-Vela; Andrés Fuster-Guilló; Jose-Norberto Mazón; Luis Daniel Ibáñez; Elena Simperl

Realiza uma análise sobre dados abertos ao longo de 2006 a 2019.

Open government data assessment model: An indicator development in Thailand

Chatipot Srimuang; Nagul Cooharojananone; Uthai Tanlamai; Achara Chandrachai

Avalia o grau de desenvolvimento da política de dados abertos existentes na Tailândia.

Urban Archiving for Smarter Cities: Archival Practices beyond Open Data

Elisabet M. Nilsson; Veronica Wiman

Mostra outras práticas de publicação de informações, traçando um paralelo entre a metodologia de dados abertos e essas novas práticas.

A Linked Open Data Based Approach for Trip Recommendation

Nasredine Cheniki; Marwa Boulakbech; Hamza Labbaci; Yacine Sam; Nizar Messai; Thomas Devogele

Através dos dados abertos conectados, é elaborada uma proposta a ajudar viajantes a planejar suas viagens.


x Consulta com a terceira string

String utilizada: ("open data plan" OR "open plan data" OR "data open plan" OR

"data plan open" OR "plan open data" OR "plan data open")

A consulta com a terceira string de busca não foi bem aceita por este motor de

busca, não retornando nenhum registro. Tentamos simplificar a string deixando apenas o

termo “open data plan”, e mesmo assim não foi encontrado nenhum resultado. Tentamos

ainda um novo arranjo, deixando a string de busca (“open data” AND “plan”). O

resultado foi exatamente os 17 artigos encontrados na consulta realizada pela primeira

string de busca. Essa terceira string de busca é importante por ser focada nas palavras-

chave deste trabalho, por isso a insistência em encontrar algum artigo nesta consulta.

3.2.4 Google Scholar (https://scholar.google.com.br/)

Mesmo sabendo da existência da opção de “Pesquisa Avançada” desta ferramenta

de busca, decidimos utilizar as mesmas strings de busca utilizadas nas ferramentas.

x Consulta com a primeira string

53

String utilizada: ("dados abertos" OR "dados abertos governamentais" OR "dados

abertos governamental") AND ("plano de dados abertos" OR "PDA" OR "open data plan"

OR "plano dados abertos")

Utilizando este motor de busca conseguimos um considerável número de artigos

nacionais e com muitas referências diretas ao plano de dados abertos. A consulta no

mostrou um total de 405 artigos. A consulta mostra as publicações de vários órgãos

governamentais brasileiros e suas iniciativas de abertura de dados, incluindo o

desenvolvimento do PDA. Logo, vários artigos foram selecionados e analisados desta

consulta. O que mais se mostraram relevantes foram:

Tabela 8 - Primeira consulta no motor de busca Google Scholar

Título do artigo Autores Considerações / Temática Dados Abertos: como fazer um PDA (Apresentação)

Controladoria-Geral da União (CGU) Carvalho, Paula da Rosa de Souza; Wosgrau, Antonio Carlos; Ary, Thalita Carneiro

Explana os benefícios da prática da abertura de dados. Detalha o panorama da CGU.

A iniciativa da construção do Plano de Dados Abertos do Tribunal de Contas do Rio Grande do Norte através de parceria acadêmica com a Universidade Federal do Rio Grande do Norte

Frederico N. Pranto Filho; Renan Oliveira; Lindemberg Silva Pereira; Joir Ramalho

Relata as estratégias adotadas pelo TCE/RN na implementação do Plano de Dados Abertos.

Plano de dados abertos na Universidade Federal de Pernambuco – UFPE (PDA)

Lóscio, Bernadette Farias; Vila Nova, Susimery

Mostra o Plano de Dados Abertos da UFPE.

O ecossistema de dados abertos do governo federal: composição e desafios

José Antônio de Carvalho Freitas; Remis Balaniuk; Ana Paula Bernardi da Silva; Vitória Santiago da Silveira

Apresenta os principais software do ecossistema opendata do governo federal.

A construção do Plano de Dados Abertos de uma organização pública de pesquisa e desenvolvimento e o desafio de uma ciência agropecuária aberta

Bertin, Patrícia Rocha Bello; Machado, Claudia Delaia; Visoli, Marcos Cezar; Drucker, Debora Pignatari; Pinto, Daniela Maciel

Relata as estratégias adotadas no processo de publicação de dados abertos.


Apenas com esses artigos listados, conseguimos entender a estrutura do PDA que

os órgãos e instituições adotaram como um padrão. Também pudemos observar como o

PDA evolui de uma versão para outra, como é apresentado pelo Instituto de Pesquisas

54

Jardim Botânico do Rio de Janeiro. Embora estes artigos se mostraram bem interessantes

e irão compor as referências deste trabalho, outros também foram analisados e

contribuíram para o desenvolvimento desta dissertação.

x Consulta com a segunda string

String utilizada: ("open data" OR "government open data") AND ("plan" OR "data plan" OR "open data plan" OR "government open data plan") A princípio, a consulta realizada com a segunda string nos retornou um número

muito grande de artigos, um total de 17.900. Logo foi percebido que os mesmos ruídos

das consultas em outros motores estavam acontecendo novamente, e precisamos alterar a

string de busca para minimizar este problema. Logo, alteramos a string de busca para

simplificar nossa pesquisa. A string ficou da seguinte forma: ("government open data")

AND ("plan" OR "data plan" OR "open data plan" OR "government open data plan")

Tabela 9 - Segunda consulta no motor de busca Google Scholar

Título do artigo Autores Considerações / Temática Planning and designing open government data programs: An ecosystem approach

Sharon S.Dawes; Lyudmila Vidiasova; Olga Parkhimovich

Aborda dois estudos realizados, um na Rússia e outro no Estados Unidos sobre o modelo utilizado no ecossistema opendata.

Brazilian government open data: implementation, challenges, and potential opportunities

Kellyton dos Santos Brito; Marcos Antônio da Silva Costa; Vinicius Cardoso Garcia; Silvio Romero de Lemos Meira

Analisa o estado atual das iniciativas brasileiras sobre dados abertos, seus desafios e dificuldades.

Open data ecosystems: an international comparison

Evgeny Styrin; Luis Felipe Luna-Reyes; Teresa M. Harrison

Paralelo entre os ecossistemas de dados abertos utilizados pelo governo do EUA e México.

Methodologies and Best Practices for Open Data Publication

J Kucera, D Chlapek, J Klímek, M Necaský

Referência a um documento semelhando ao Plano de Dados Abertos brasileiro.


Analisando os novos resultados, conseguimos encontrar, finalmente, referencias

ao desenvolvimento de um documento com as mesmas características de um PDA, um

artigo chamado “Methodologies and Best Practices for Open Data Publication”. Ele

demonstra como deve ser o documento de plano de publicação de dados aberto (open

data publication plan). A aplicação que será proposta neste trabalho tentará seguir as

orientações descritas neste artigo para uma maior adaptabilidade a necessidades

internacionais.

55

3.3 OUTRAS PESQUISAS REALIZADAS

Além de pesquisas sobre trabalhos relacionados a elaboração de Plano de Dados

Aberto e Dados Abertos Governamentais, realizamos também uma pesquisa sobre

aplicações que extraiam e publiquem informações nas plataformas de dados abertos.

Logo, encontramos um trabalho de dissertação de Mestrado que realiza uma avaliação

criteriosa sobre essas ferramentas e também apresenta uma solução própria. A ferramenta

OpenData Processor (Vilela, 2018), proposta no trabalho estudado, utiliza uma base

estrutural e arquitetural bem semelhante ao nosso projeto, sendo a mesma linguagem de

programação (Python.org. 2020) e o mesmo framework web (Djangoproject.com. 2020)

o que facilitaria a integração entre as duas ferramentas. As análises sobre o trabalho do

OpenData Processor nos mostraram que a ferramenta responde bem aos testes de extração

em massa de dados, sem consumir muita memória e processamento, sendo mais eficiente

do que a maioria das outras ferramentas disponíveis no mercado. Esta ferramenta que foi

desenvolvida no trabalho de Vilela se enquadra como uma ferramenta ETL (Extract,

Transform, Load), responsável por extrair, tratar e publicar os dados em uma plataforma

de dados abertos. Algumas questões não são tratadas por esta ferramenta como, por

exemplo, os critérios de seleção dos dados que foram extraídos. Pensando em completar

essas e outras questões relacionadas a dados abertos, surgiu a necessidade de criar a

aplicação Opendata Manager.

Também foi realizado uma pesquisa sobre as plataformas de publicação de dados

abertos, uma vez que a nossa aplicação queira ser independente de softwares externos,

necessitará de integração com essas plataformas. No trabalho de Vilela (2018), é realizado

uma comparação entre as ferramentas CKAN (OPEN KNOWLEDGE

INTERNATIONAL, 2017), DKAN (GRANICUS, 2017), JUNAR (JUNAR, 2017),

Socrata (SOCRATA, 2017) e OpenDataSoft (OPENDATASOFT, 2017). No

comparativo em questão, são analisadas características como: (i) gratuidade e código

aberto; (ii) API de leitura de dados; (iii) API de cadastro de dados; (iv) interface

customizável; (v) extensível, e; (vi) linguagem de programação que foi desenvolvida.

Com a comparação, as plataformas CKAN e DKAN se destacaram das demais,

apresentando características semelhantes, diferenciadas apenas na linguagem de

programação, onde CKAN é desenvolvido em Python e o DKAN em PHP. Por questões

de conformidade entre as aplicações e mesmos requisitos de infraestrutura, utilizaremos

o CKAN.

56

3.4 CONCLUSÃO DA PESQUISA SOBRE TRABALHOS

RELACIONADOS

Nesta pesquisa foi possível identificar como os diferentes países do mundo tratam

dados abertos no âmbito governamental. Percebemos que é muito mais comum a

utilização do PDA pelos órgãos nacionais que os internacionais. Este levantamento foi

importante para que possamos comparar os diferentes processos de abertura de dados

utilizados no mundo e implementar a aplicação observando os detalhes desses processos.

Conseguimos extrair informações de como os PDAs são construídos e evoluídos

pelas instituições públicas, entendendo todo o fluxo de desenvolvimento deste

documento. Na Tabela 10 relacionamos os artigos que contribuíram neste entendimento.

Tabela 10 - Artigos sobre PDA que contribuíram para o trabalho

Título do artigo Autores Open Data Plan at the Federal university of Pernambuco – uFPe

Bernadette Farias Lóscio; Susimery Vila Nova

A iniciativa da construção do Plano de Dados Abertos do Tribunal de Contas do Rio Grande do Norte através de uma parceria acadêmica com a Universidade Federal do Rio Grande do Norte

Frederico N Pranto; Renan Oliveira; Lindemberg Silva Pereira

Dados Abertos: como fazer um PDA Carvalho, Paula da Rosa de Souza; Wosgrau, Antonio Carlos; Ary, Thalita Carneiro

Methodologies and Best Practices for Open Data Publication J Kucera, D Chlapek, J Klímek, M Necaský


Praticamente todos os artigos ressaltam as informações básicas sobre dados

abertos com relação as questões dos oito princípios e das três leis, mostrando o

engajamento destes no processo de abertura de dados. A partir deste levantamento,

conseguimos identificar também quais ferramentas do ambiente opendata são mais

utilizadas por esses países. A Tabela 11 mostra os artigos que contribuíram no

entendimento de dados abertos no âmbito governamental.

Tabela 11 – Artigos que contribuíram no entendimento sobre dados abertos governamentais

Título do artigo Autores I Open Data Day Natal - 2018 - A Iniciativa do Plano de Dados Abertos do TCE/RN e o seu papel no Controle Social Frederico Nunes do Pranto Filho

Analysis of the implementation of the Open Data Policy in the Federal Executive Government

Janaina Dos Santos Melo; Maria Fernanda Mascarenhas Dos Santos Melis

57

The role of open data in enabling fiscal transparency and accountability in municipalities in Africa: South Africa and Nigeria case studies

Paul Kariuki, Jude A. Adeleke, Lizzy Oluwatoyin Ofusori

Towards an expanded and integrated open government data agenda for India

Sumandro Chattapadhyay

Open government data assessment model: An indicator development in Thailand

Chatipot Srimuang; Nagul Cooharojananone; Uthai Tanlamai; Achara Chandrachai

Open Budget effects for Urban development: Russia's cases Radomir Bolgov, Marina Ermolina, Natalia Vasilyeva

Open Data for Development: Experience of Uruguay Victoria Köster, Gustavo Suárez

Open data ecosystems: an international comparison Evgeny Styrin; Luis Felipe Luna-Reyes; Teresa M. Harrison


Outros sistemas estão sendo desenvolvido para auxiliar no trabalho interno de

instituições ou criando soluções para a sociedade. Um exemplo que auxílio interno é de

uma instituição médica que criou um CSM (Content Management System) que ajuda na

disponibilização de relatórios relacionados a pacientes com HIV. Essa solução leva em

consideração a sensibilidade das informações de saúde, consegue imprimir relatórios

relevantes para a instituição e não expõem os pacientes.

Um artigo que chamou a atenção é o “Open Data as a Foundation for Innovation: The

Enabling Effect of Free Public Sector Information for Entrepreneurs” que fala sobre o

crescente interesse de startups suecas nos informação do setor público, exemplificando

que algumas delas estão dispostas a pagar pelas informações que deveria ser

disponibilizada de forma gratuita. Isso mostra como é importante que os órgãos públicos

engajem nos processos de abertura de dados.

Através dos artigos relacionados na Tabela 12 conseguimos ter uma visão de

como os dados abertos estão sendo disponibilizados para a sociedade e se essa

disponibilização está de contribuindo de fato para estreitar o relacionamento entre

governo e sociedade. Pudemos perceber que apesar de muitos governos estarem

publicando informações em suas plataformas de dados abertos, não há uma ação de

fomento para o uso dessas informações. Dessa forma, é como se os dados basicamente

não existissem para a sociedade, pois ela não os conhece e nem sabe como acessá-los.

Tabela 12 - Tabela de artigos que contribuíram a entender como os dados estão sendo disponibilizados para a sociedade.

Título do artigo Autores Open Data as a Foundation for Innovation: The Enabling Effect of Free Public Sector Information for Entrepreneurs Lakomaa, Erik; Kallberg, Jan

PROPOSAL FOR THE CREATION OF AN OPEN DATA NETWORK IN BRAZILIAN RESEARCH/PROPUESTA DE CREACION DE UNA RED DE DATOS ABIERTOS DE LA

Pavao, Caterina Groposo; Da Rocha, Rafael Porte; Gabriel, Rene Faustino, Jr.

58

INVESTIGACION BRASILENA/PROPOSTA DE CRIACAO DE UMA REDE DE DADOS ABERTOS DA PESQUISA BRASILEIRA

Open Data Extraction, Transformation, and Loading as a Tool for Supporting 2018 Elections' Voters

Nélson R. S. Passos, Ariel F. Rodrigues, Hendrik T. Macedo, Bruno O. P. Prado, Gilton J. F. da Silva, Leonardo N. Matos

A theoretical framework for evaluating government open data platform Pin-Yu Chu, Hsien-Lee Tseng

Making Open Data Work for Civic Advocacy Aare Puussaar, Ian G. Johnson, Kyle Montague, Philip James, Peter Wright


Essa dificuldade de acesso as informações governamentais são exploradas no

artigo “Making Open Data Work for Civic Advocacy” onde, além de atacar os pontos que

dificultam o acesso a informação, é idealizada uma ferramenta para ajudar na

compreensão dos conjuntos de dados que muitas vezes não são de fácil leitura por parte

da população.

Também é explanado um método de mensurar a aceitação de determinados

conjuntos de dados por parte dos cidadãos. É interessante pensar que esse método de

mensurar conjunto de dados elaborado no artigo “User Acceptance of Open Data Portals

in Korea: The Role of Policy Tools” pode ser relacionado com a ferramenta idealizada no

artigo anteriormente citado “Making Open Data Work for Civic Advocacy” onde,

aplicando a ferramenta em um conjunto de dados com pouca aceitação, poderia melhorar

a visualização dessas informações, melhorando consequentemente sua aceitação.

Não conseguimos encontrar em nenhum dos artigos pesquisados menção a algum

software que sirva como construtor do Plano de Dados Abertos, auxiliando em seu

desenvolvimento e monitoramento. Uma hipótese para este resultado é que as instituições

focam seus esforços nos processos pós PDA, como extração e publicação dos dados. Essa

hipótese é reforçada, em âmbito nacional, analisando o portal de monitoramento da CGU,

onde apenas 30% dos órgãos federais do Brasil tem seu PDA publicado. Essa falta de um

processo informatizado que gerencie a construção, evolução e monitoramento do PDA

serviu como um incentivo para o desenvolvimento de nossa proposta que pretende atuar

justamente nesses pontos.

Por fim, este levantamento nos mostrou várias visões de como o assunto “Dados

Abertos” é tratado por diversas organizações, também apresentando uma visão sobre

grande parte do ecossistema opendata, sendo possível a identificação de plataformas de

dados abertos, ferramentas ETL, softwares para mensurar qualidade de datasets dentro

59

outras soluções que atacam várias frentes deste ambiente. Como já explanado, não

conseguimos encontrar uma solução que trate do Plano de Dados Abertos, surgindo assim

a oportunidade de elaborar uma solução que gerencie os processos deste documento e que

contribua com mais essa frente pertencendo ao ambiente opendata. Esta ferramenta

poderá ser continuada em trabalhos futuros com o desenvolvimento de módulos

complementares a fim de criar integrações com sistemas já existentes ou incorporando

funcionalidades voltadas para dados abertos.

60

4 PROPOSTA DE GERENCIAMENTO DO PROCESSO DE

CRIAÇÃO E MONITORAMENTO DO PLANO DE DADOS

ABERTOS Nesta seção iremos apresentar todo o levantamento de requisitos, funcionais e não

funcionais, que foram verificados na fase de pesquisa analisando os manuais de

elaboração do plano de dados abertos disponibilizados tanto pela CGU quanto pela

ENAP. Por se tratar de uma proposta que vai de encontro a leis, normas e decretos, é

necessário também o levantamento dos requisitos de domínio.

4.1 REQUISITOS FUNCIONAIS

Serão apresentados a seguir os requisitos funcionais (Tabela 13 - Tabela dos

requisitos funcionais) que norteiam o desenvolvimento da proposta de gerenciamento do

processo de criação e monitoramento do Plano de Dados Aberto. Os requisitos funcionais

(RF), também denominados requisitos técnicos, são aqueles que especificam as entradas

e saídas de um sistema, isto é, as ações que o sistema deve ser capaz de executar, sem

considerar restrições físicas (PARVIAINEN; TIHINEN; SOLINGEN, 2005;

ROZENFELD et al., 2006).

Tabela 13 - Tabela dos requisitos funcionais

ID Nome Descrição

RF001 Realizar login Realizar o acesso ao sistema através de cadastro previamente realizado.

RF002 Realizar logout Permitir o usuário encerrar sua sessão no sistema, não permitindo acesso até o próximo login.

RF003 Alterar senha Permitir a alteração de senha do usuário.

RF004 Gerenciar grupos de usuários Permitir o gerenciamento de grupo de permissões dos usuários.

RF005 Gerenciar usuários Permitir o gerenciamento dos usuários de acesso ao sistema.

RF006 Gerenciar PDA Permitir o gerenciamento do PDA pelos usuários logados no sistema.

61

RF007 Gerenciar provedores de dados Permitir o gerenciamento dos provedores de dados do sistema.

RF008 Gerenciar cronogramas Permitir o gerenciamento dos cronogramas estabelecidos no PDA.

RF009 Gerenciar extratores/publicadores de dados

Gerenciar configuração de acesso aos sistemas de extração e publicação de dados.

RF010 Visualizar informações resumidos no dashboard

Permitir a visualização resumida das informações de todo o processo de desenvolvimento do PDA.

RF011 Visualizar relatório Permitir a geração de relatórios

RF012 Visualizar registro de log do sistema

Permitir o acesso a registros de log do sistema para usuários administradores.

RF013 Gerenciar grupo de trabalho Permitir o gerenciamento de grupos de trabalhos.

Fonte: Elaborado pelo autor

Entende-se “gerenciar” como sendo as ações realizadas por um CRUD - Create

(Criação), Read (Consulta), Update (Atualização) e Delete (Remoção).

4.2 REQUISITOS NÃO FUNCIONAIS

Nesta seção serão apresentados os principais requisitos não funcionais (Tabela 14

- Tabela de requisitos não funcionais) que foram levantados na fase de pesquisa deste

trabalho. Os requisitos denominados não funcionais, por sua vez, definem as qualidades

e os atributos do sistema como um todo, impondo ressalvas para o produto e o processo

de desenvolvimento, como os requisitos legais, por exemplo. O fato de constituírem

restrições para o sistema faz com que esse tipo de requisitos seja de importância crítica

(KOTONYA; SOMMERVILLE, 2000; LABUSCHAGNE; BRENT; ERCK, 2005).

Tabela 14 - Tabela de requisitos não funcionais

ID Categoria Descrição

RNF001 Legal

O sistema deve estar em conformidade com o Decreto 8.777/2016 que institui a Política de Dados Aberto do Poder Executivo Federal.

Obrigatório

62

Justificativa:

Como a solução vai gerar um documento que precisa obedecer a critérios de qualidade estabelecidos pela CGU, é imprescindível seguir as normativas legais que tratam da construção deste documento.

RNF002 Segurança Apenas perfis de administradores poderão cadastrar usuários.

Obrigatório

Justificativa: O cadastro de usuário é uma tela sensível que apenas administradores podem acessá-la, pois nela é possível alterar senhas de usuários, adicionar ou remover permissões e até mesmo apagar os usuários cadastrados.

RNF003 Segurança Apenas usuário cadastrado poderá acessar o sistema. Obrigatório

Justificativa: Por se tratar de um sistema que expõe dados do órgão público através de integração com sistemas internos através de API ou acesso a base de dados, é necessário que apenas usuários autorizados possam acessar a ferramenta.

RNF004 Performance O tempo de resposta de cada tela do sistema não deve demorar mais que 10 segundos.

Desejável

Justificativa:

Segundo Nielsen (2009), 10 segundos é a média de tempo que os usuários esperam para uma resposta de uma requisição sem perder o foco com outros assuntos, desistindo assim do site que está pesquisando ou da ação que está executando. É desejável que todas as telas do sistema não demorem mais que esse tempo (10 segundos).

RNF005 Interface Todas as funções relacionadas ao PDA devem ser efetuadas em uma única janela (página).

Desejável

Justificativa: Para uma melhor usabilidade da ferramenta, é desejável que as informações de cadastro do PDA estejam em uma única tela, separadas por abas, facilitando o acesso a todos os tópicos do documento e melhorando a visibilidade do usuário com relação ao documento completo.

RNF006 Interface O layout deve ser responsivo. Desejável

63

Justificativa:

Com a popularidade de vários dispositivos e suas enumeras resoluções de telas, é desejado que a aplicação reaja dependendo desta resolução, se adequando ao tamanho da dela do dispositivo. Essa adequação deverá rearranjar os elementos da tela, melhorando o layout do sistema.

RNF007 Segurança O sistema deverá permitir que ele seja auditável com o emprego de técnicas de logs.

Obrigatório

Justificativa: A solução irá trabalhar com dados extraídos de sistemas internos de órgãos públicos, contendo também as informações de acesso a esses sistemas. Por se tratar de dados sensíveis, além de ter o controle de acesso para garantir a segurança, é necessário registrar em logs os acessos as informações para futuras verificações de segurança.

RNF008 Compatibilidade O sistema deverá funcionar de maneira igual para os principais navegadores.

Obrigatório

Justificativa: Devido ao fato de a solução ser um sistema web e com recursos como responsividade, é importante que ele funcione de maneira igual nos navegadores Chrome, Firefox e Safari.


4.3 REQUISITOS DE DOMÍNIO

Os requisitos de domínio (DM) são derivados do domínio da aplicação do sistema

que podem ser novos requisitos funcionais em si, podem restringir os requisitos

funcionais existentes ou estabelecer como devem ser executados cálculos específicos.

Muitas vezes esses requisitos refletem fundamentos do domínio da aplicação

(SOMMERVILLE, 2008). Sem uma compreensão satisfatória desses requisitos pode ser

impossível fazer o sistema operar de forma satisfatória (PRESSMAN, 2006).

Como a aplicação sugerida gira entorno do tema Dados Abertos, mais

especificamente sobre Dados Abertos Governamentais, e ainda sobre Plano de Dados

Abertos, é necessário observar todas as leis e diretrizes que regem cada um desses temas

a fim de identificar cada item obrigatório que deve compor a estrutura de um PDA. Logo,

nesta seção vamos identificar esses requisitos e expô-los na tabela abaixo.

Tabela 15 - Tabela de requisitos de domínio

ID Nome Descrição

64

DM001 Critério de priorização de abertura

O sistema deve observar os critérios listados no Art.1º da Resolução n.º 3 do CGINDA.

Obrigatório

DM002 Introdução do PDA

Apresentar o Decreto no 8.777/2016, a Resolução no3, de 13 de outubro de 2017, do CGINDA e outros normativos aplicáveis.

Obrigatório

DM003 Relatório de acompanhamento periódico

Apresentar os processos de monitoramento e controle das ações previstas no Plano, conforme orientação do Art5o §4o, IV do Decreto 8.777 de 2016.

Obrigatório

DM004 Cronograma de abertura de base de dados

Programação interna do órgão para a publicação das bases selecionadas durante o período de 2 anos a contar da publicação do PDA conforme o art. 3º da Resolução n.º 3 do CGINDA

Obrigatório

DM005

Cronograma de promoção e fomento ao uso e reuso das bases do órgão

Ações planejadas visando a promoção e fomento ao uso e reuso efetivo das bases de dados pela sociedade e/ou Governo, conforme o Art. 3º da Resolução nº 3 do CGINDA

Desejável

DM006 Inventário e catálogo corporativo

Relação de todas as bases de dados contidas no inventário e catálogo corporativo do órgão ou entidade, de acordo com o Art. 4º, III da Resolução Nº 3, de 13 de outubro de 2017.

Obrigatório

DM007 Publicação em transparência ativa

Observância das obrigações previstas na Lei no 12.527, de 18 de novembro de 2011 - Lei de Acesso à Informação (LAI) e demais normas que regem o assunto.

Obrigatório

DM008 Previsão de catalogação em dados.gov.br

As bases de dados relacionadas para abertura nos Plano de Dados Abertos deverão ser catalogadas no Portal Brasileiro de Dados Abertos

Obrigatório


65

4.4 IMPLEMENTAÇÃO DA PROPOSTA DE ELABORAÇÃO E

MONITORAMENTO DO PLANO DE DADOS ABERTOS

Durante as pesquisas e análise das informações coletadas, foi identificada a

necessidade da aplicação de acessar informações de um sistema interno dos órgãos afim

de identificar informações que irão compor o Plano de Dados Abertos. Além disso, a

aplicação deverá atender a outros critérios definidos pela CGINDA para que o PDA

atenda os requisitos de qualidade exigidos. A princípio, a aplicação não irá dispor da

funcionalidade de extração e publicação de dados, sendo necessária a integração com uma

ferramenta externa que execute esta ação, o que não impede que essa funcionalidade seja

desenvolvida futuramente, tornando a aplicação proposta independente de terceiros. Na

Figura 7 conseguimos visualizar como o Opendata Manager atua no ambiente opendata,

se comunicando com plataformas de dados abertos e ferramentas ELT.

Figura 7 – Visão macro do ODM no ambiente opendata


Na Figura 7 observamos que o Opendata Manager se comunica com o serviço de

mensageria, enviando e recebendo mensagens em um padrão específico. Tanto para o

envio quanto para o retorno das mensagens, são utilizadas filas específicas dentro do

serviço de mensageria, definidas pelo nome de “in” para filas de entrada e “out” para filas

de saída. Para que as aplicações externas consigam ler e enviar mensagens, o ODM

disponibiliza uma interface com os métodos a serem implementados, explicando como

deve ser o formato de retorno das mensagens. Sendo assim, se estabeleci um padrão de

comunicação e a troca de mensagem passa a ser possível. Atualmente, o Opendata

Manager está se comunicando apenas com a ferramenta ETL Opendata Processor, que é

responsável por extrair, tratar e publicar informações de um órgão. O Opendata Manager

66

envia quais os dados que serão extraídos e a periodicidade de atualização e o Opendata

Processor realiza essa operação. Futuramente, novos módulos podem ser implementados

dentro do ODM para que se possa extrair e publicar informações diretamente nas

plataformas de dados abertos sem a necessidade de uma ferramenta de terceiro.

Para especificar detalhes do Opendata Manager, explicando como cada requisito

funcional foi atendimento no desenvolvimento da aplicação, elaboramos na Figura 8 a

comunicação entre os componentes que compõe a ferramenta.

Figura 8 - Destaque dos componentes internos do Opendata Manager


Como explicado anteriormente, o Opendata Manager é uma ferramenta baseada

no framework django, logo, este framework já nos entrega algumas funcionalidades,

como o gerenciamento de usuários, gerenciamento de grupos de usuários do sistema e

gerenciamento de permissões. Além disso, o próprio django já oferece mecanismos de

rotas de urls, onde conseguimos facilmente implementar regras de rewrite para acesso às

nossas views. Por padrão, o django fornece implementações de middlewares voltados para

segurança da aplicação como o CorsMiddleware e SessionMiddleware, mas é

perfeitamente possível implementar seu próprio middlewares e integrá-los ao projeto. Em

nossa aplicação, foi implementado um middleware que analisa o http request passado

pelo navegador e, dependendo do subdomínio encontrado, conseguimos identificar qual

o inquilino está acessando o sistema, configurando a interface com os arquivos estáticos

adequados.

67

Sobre o framework, desenvolvemos módulos para suprir o restante dos requisitos.

Um exemplo é o módulo PDA, responsável por gerenciar todos os cadastros relacionados

a este documento. As entidades que compõem o módulo podem ser vistas na Figura 9.

Figura 9 - Diagrama de classe resumindo do módulo PDA

Fonte: Elaborado pelo autor

No diagrama de classes da Figura 9 podemos observar as seguintes entidades: 1)

PDA – onde compilamos as informações de todo o processo de desenvolvimento do

documento, além de controlar as etapas destes de desenvolvimento; 2) TarefasPDA –

onde são cadastradas as tarefas que necessitam ser realizadas para avançar nas etapas de

desenvolvimento; 3) ProvedorDados: cadastro do sistema do órgão que servirá as

informações para que a nossa aplicação possa consumi-la; 4) ConsultaPublica – uma das

etapas de desenvolvimento do PDA é realizar uma consulta pública acerca dos inventários

de dados levantados até o momento. O resultado da votação desta consulta é armazenado

nesta entidade para ajudar na priorização das bases; 5) GrupoTrabalho – é um

agrupamento de usuários que ficarão responsáveis pelo desenvolvimento do PDA; 6)

ConjuntoDados – dentro de um inventário de dados, precisamos definir quais os dados

que serão abertos, realizando uma triagem das informações a fim de não expor dados

sensíveis; 7) DadoSigiloso – podemos definir por padrão alguns dados que,

recorrentemente, são marcados como dados sensíveis. Ao cadastrar o dado “password”,

por exemplo, quando consultarmos um conjunto de dados, este será ignorado e não fará

parte dos dados que serão abertos; 8) ConfiguracaoAcesso – tela onde realizamos os

68

cadastros de parâmetros de acesso a serviços de mensageria, API ou banco de dados; 9)

ResponsavelPDA – detalhamento de cada membro do grupo de trabalho.

Outro módulo importante da aplicação é o Tasks Manager, responsável por

gerenciar as tarefas que serão armazenadas no sistema. É ele que gerencia os prazos e cria

alertas para avisar aos usuários do sistema sobre o término de uma ação. Neste módulo

utilizamos a biblioteca APScheduler para agendar todas as tarefas de todos os módulos

desenvolvidos. Na Figura 10 - Código exemplificando o agendamento de tarefas podemos

observar que o método checa_prazos da classe TarefasPDA será invocado todos os dias

a zero horas. Este método verifica a situação de todas as tarefas cadastradas e emite os

alertas quando necessário.

Figura 10 - Código exemplificando o agendamento de tarefas


O módulo Dashboard é responsável por compilar as informações de outros

módulos a fim de criar gráficos e estatísticas que serão apresentadas tanto na tela

dashboard da área restrita, quanto na área pública, ficando disponível também para a

população.

Com relação ao módulo integrador, este é responsável por configurar o serviço de

mensageria que será utilizado na integração com outros sistemas. Nesta configuração é

possível definir o nome da queue de entrada e saída de mensagens, definir o exchange

utilizado na comunicação, a porta e host onde o serviço está rodando. De acordo com o

que foi concluído na discussão sobre os serviços de mensageria, levando em consideração

a capacidade de envio de mensagens por segundo, persistência de dados e a capacidade

de consumo dos três brokers analisados, ficou definido que vamos utilizar o RabbitMQ

para ser o nosso intermediador entre as aplicações.

69

Além destes, foi necessário implementar uma camada se serviço para implementar

consultas a sistemas que não consegue integração com serviços de mensageria. Essa

camada criada pode ser implementada com consultas REST ou SOAP, dependendo da

necessidade.

70

5 OPENDATA MANAGER: UMA FERRAMENTA DE

GERENCIAMENTO DO PROCESSO DE CRIAÇÃO E

MONITORAMENTO DO PLANO DE DADOS ABERTOS

O OpenData Manager (ODM) surge a partir da necessidade de uma sistematização

na construção e monitoramento de um Plano de Dados Abertos. O ODM segue os padrões

definidos pela Infraestrutura Nacional de Dados Abertos (INDA) do Ministério do

Planejamento, Desenvolvimento e Gestão (MPDG).

O ODM funciona registrando todas as entradas que são previamente necessárias

na criação do PDA. Um exemplo é o registro de Grupos de Usuários que, dentro do ODM,

são como o Grupo de Trabalho (GT) responsáveis pela elaboração do PDA. Também é

possível com a ferramenta gerenciar as interfaces de integração com sistemas externos.

Essa integração acontece via um serviço de mensagens (RabbitMQ) onde, nas

configurações de integração, é possível configurar em que fila de será postada as

informações que os sistemas externos irão consumir.

A ferramenta também gerencia todas as atividades cadastradas no plano de ação

do PDA, alertando aos usuários responsáveis quando a atividades está perto do prazo

final. Como a elaboração do PDA é um processo que pode demorar meses, a ferramenta

dispõe de um dashboard que orienta aos usuários quais os passos devem ser tomados para

a evolução do documento. O processo de desenvolvimento do PDA conta com pelo menos

sete etapas: 1) definição do grupo de trabalho; 2) definição dos inventários; 3) consulta

pública; 4) priorização das bases de dados; 5) relação final de bases; 6) cronograma de

abertura, e; 7) registro do PDA. Para cada uma das etapas existem tarefas a serem

cumpridas. O ODM verifica se todas as tarefas de uma etapa foram concluídas e

automaticamente avança para a próxima etapa com mais tarefas a serem cumpridas. Este

ciclo se repete até que cheguemos na última etapa que finalizamos o PDA.

Após a finalização do PDA, este ficará com algumas funções incapazes de serem

alteradas, porém, é possível atualizar o PDA com novas bases de dados que possam vir a

surgir durante a vigência do documento. Após um período de tempo definido por

parâmetros dentro da aplicação, ficará disponível uma ação de clonagem do PDA vigente.

Essa clonagem é interessante para que possamos aproveitar boa parte dos cadastros que

71

já foram realizados sem alterar a versão anterior do PDA que já está finalizados, dando

assim início ao desenvolvimento da segunda versão do PDA para uma nova vigência.

5.1 FUNCIONALIDADE DO OPENDATA MANAGER

As funcionalidades desenvolvidas no OpenData Manager foram pensadas em dar

suporte todos os processos de elaboração de um PDA, desde a identificação dos

responsáveis pelo documento a até a conclusão do PDA, onde é fechada uma versão do

documento para a publicação nas plataformas de dados aberto, e é monitorado cada item,

base e atividades que foram descritos neste documento. A aplicação foi desenvolvida

utilizando a linguagem de programação Python e o framework web Django, além do

banco de dados PostgreSQL (POSTGRESQL..., 2019). Ela contará com duas áreas de

acessos.

5.1.1 Área de Acesso Público

Nesta área pode acessar uma interface que disponibilizará o PDA construído pela

instituição. Este PDA estará disponível nos formatos HTML, estruturado na própria

página, e outra versão em PDF, com um link disponível para download do documento.

A área de acesso pública muda a sua interface de acordo com o estado do processo

de construção do PDA. Um exemplo é o fato de a interface disponibilizar uma enquete

com as bases de dados que foram selecionadas a serem abertas. Essa enquete está

relacionada com um dos processos de construção do PDA, onde um dos critérios de

priorização das bases é “Grau de relevância para o cidadão (Resolução Nº 3, Art. 1º, I, §

1º)”. Desta forma, o próprio cidadão poderá participar na priorização das bases, atribuindo

valor de relevância a elas. A enquete ficará disponível apenas no período de priorização

das bases, dando espaço a outras informações do andamento da construção do PDA.

5.1.2 Área de Acesso Restrito

Esta área destina-se aos usuários do sistema, que deverão ser cadastrados

previamente, sendo-lhes atribuídos um login de acesso e uma senha. É nesta área onde o

72

PDA será construído e todos os cadastros que irão dar suporte a esta construção são

disponibilizados.

Ao realizar o login no sistema, o usuário é direcionando para a administração do

ODM (Figura 11), acessando inicialmente ao dashboard do sistema que irá mostrar ao

usuário um panorama geral do sistema, tanto em relação a evolução do PDA, como em

relação as integrações existentes com outros sistemas.

Figura 11 - Dashboard do OpenData Manager


Como podemos observar na Figura 11 - Dashboard do OpenData Manager, temos

integração com o Broker, CKAN e SIG Service off-line, ou seja, esses serviços estão

inalcançáveis por alguns motivos, como o serviço não está ativo, a configuração de

conexão não está cadastra ou está cadastrada, mas com parâmetros incorretos. Também

podemos observar os passos de construção do PDA, aonde vai desde o cadastro do

“Grupo de Trabalho” a até “Registrar o PDA”. Em cada um desses passos existem tarefas

que precisam ser executadas e que, ao ser concluídas, são taxadas e marcadas no campo

checkbox. A cada tarefa realizada de cada passo da construção do PDA, um gráfico aponta

a porcentagem de evolução da construção do documento. Entende-se que o PDA está

concluído quando todas as tarefas forem realizadas e o status do PDA for marcado para

“Concluído”.

Para cada passo mostrado no dashboard, foi necessário implementar as

funcionalidades que dão suporte às ações. Elas serão descritas nas subseções seguintes.

73

5.1.2.1 Grupo de Trabalho

Como vimos nos manuais citados anteriormente neste trabalho (ENAP e CGU), o

primeiro passo para iniciar os trabalhos é realizar reuniões com as áreas finalísticas do

órgão a fim de esclarecer pontos relativos à Política de Dados Abertos e traçar estratégias

para a elaboração do PDA. É orientado nos manuais a criação do um Grupo de Trabalho

(GT) para melhor conduzir o trabalho de construção do documento.

Para dar suporte a esta orientação, criamos o cadastro do GT, onde é possível

identificar os responsáveis pela elaboração do PDA, assim com as áreas (setores) de cada

um.

Para iniciar o segundo passo de elaboração do PDA, é necessário que exista pelo

menos um Grupo de Trabalho cadastrado com pelo menos um responsável de uma área.

Com esse registro realizado, é possível realizar os cadastros das atividades realizadas pelo

GT e, assim que concluídos, podemos finalizar as atividades do GT clicando na opção

finalizar atividades, como mostra a imagem abaixo.

Figura 12 - Listagem de grupo de trabalho com destaque para a opção de Finalizar Atividades.


Ao finalizar as atividades do GT, o OpenData Manager entende que a próxima

etapa está habilitada, podendo então o usuário seguinte para o próximo passo de

elaboração do PDA.

5.1.2.2 Definição do inventário de dados

O próximo passo é definido como o levantamento geral das fontes de dados, onde

as bases de dados do órgão, por secretaria/departamento, serão ser exposta e discutidas a

fim de definir algumas ações: (i) quem será o responsável por gerenciar as informações

de determinadas bases; (ii) período de atualização dessas bases, e; (iii) verificar se essas

bases contêm dados sigilosos.

74

Segundo o Artigo 4º, III, a, b, c e d da Resolução nº 3/2017 do CGINDA, essa

relação das bases de dados de órgãos e entidades devem identificar os seguintes pontos:

a) as bases de dados já abertas e catalogadas no Portal Brasileiro de Dados

Abertos;

b) as bases de dados já abertas e não catalogadas no Portal Brasileiro de

Dados Abertos;

c) as bases de dados ainda não disponibilizadas em formato aberto na data de

publicação do PDA; e

d) as políticas públicas às quais as bases estão relacionadas, quando

aplicável;

O manual da CGU (CGU, 2020), que foi desenvolvido segundo as resoluções da

CGINDA, disponibiliza um modelo (Tabela 16) que pode ser adotado para o

levantamento do inventário das bases.

Tabela 16 - Tabela para levantamento de inventário das bases de dados.

Fonte: Tabela retirada do manual da CGU

Com base nessa tabela, elaboramos o cadastro de inventário dentro do OpenData

Manager que dará suporte na relação desse inventário.

A partir deste momento, precisamos ter o cadastro dos sistemas que irão prover

os dados. A primeira configuração que precisamos cadastrar são as informações dos

provedores de dados, ou seja, os sistemas que irão nos prover as informações do órgão.

Após o cadastro, as informações ficaram disponíveis na tela representada na Figura 13:

75

Figura 13 - Informações cadastradas do SUAP.


Observando a Figura 13 - Informações cadastradas do SUAP. do cadastro do

SUAP, percebemos que ele dispõe de dois tipos de configuração de acesso, uma via

serviço, e outra via banco de dados. Também podemos observar na coluna “Status” que

a conexão via serviço está apresentando um erro de conexão. Isso se deve ao fato de o

SUAP não estar com uma instância rodando na porta especificada na url do serviço. Já a

conexão com o banco de dados está funcionando perfeitamente.

As configurações de acesso são importantes para que o OpenData Manager seja

capaz de popular informações da instituição no cadastro de inventário. Ao acessarmos a

listagem de inventários cadastrados no ODM, podemos observar uma coluna com uma

ação chamada “Seleciona Dados”.

Figura 14 - Listagem de inventário de dados com ênfase na ação "Selecionar Dados"


76

Ao clicar nessa ação (selecionar dados), o usuário será direcionado para um

formulário onde poderá listar os provedores de dados e selecionar qual tipo de

configuração de dados irá utilizar para acessar as informações.

Outro ponto que vale destacar neste momento, é o cadastro de dados sigilosos.

Para ter um registro mais genérico de informações sigilosas, foi criado no ODM um

cadastro dessas informações atrelado ao provedor de dados. Por exemplo, o SUAP terá

um cadastro onde será indicado os campos de sua base de dados que não podem ser

extraídos.

Figura 15 - Lista de campos que são considerados sigilosos pelo SUAP.


Na implementação desta funcionalidade, pensamos em dois tipos de níveis de

dados sigilosos, onde podemos simplesmente omitir o campo quando ele for consultado,

ou mascará-lo, quando o campo pode ser informado, mas não a sua informação completa.

Com o tratamento desses dados, o OpenData Manager atende parcialmente a LGPD.

5.1.2.3 Consulta pública

Todos os inventários cadastrados serão disponibilizados na área pública do ODM

em forma de enquete, para possibilitar a participação social na escolha dos dados. O

manual da CGU sugere que a votação dos inventários tenha uma duração de 15 dias.

5.1.2.4 Elaborar a matriz de priorização

Com o intuito de direcionar os esforços de abertura de cada base da instituição,

foi criado o formulário de matriz de priorização, seguindo o modelo disponível no manual

da CGU (CGU, 2020). A Figura 16 - Matriz de priorização das bases de dados da CGU.

mostra como é a matriz de priorização elaborada e exposta no manual da GCU.

77

Figura 16 - Matriz de priorização das bases de dados da CGU.

Fonte: Imagem retirada do manual da CGU

O formulário criado (Figura 17) permite ao grupo de trabalho analisar cada base

de dados de acordo com os critérios definidos na Resolução nº 3/2017 do CGINDA.

Figura 17 - Formulário da matriz de priorização.

Fonte: Elaborado pelo autor.

78

As pontuações 0, 1, 2 e 3 foram substituídas pelas descrições “Não se aplica”,

“Baixo”, “Médio” e “Alto”, respectivamente. Ao finalizar os registros das notas de cada

base em cada critério, é possível executar a ação “Finalizar Avaliação”. Ao executá-la,

será criada uma média das notas (score) para aquela base que servirá de referência para

os esforços de abertura.

5.1.2.5 Definir relação final das bases

Para abarcar este passo do processo de elaboração do PDA, utilizamos a lista de

inventários já existente, adicionando a ação “Relaciona Base para PDA”, onde marcamos

as bases que ficarão disponíveis para compor o PDA. Apenas as bases relacionadas

poderão ser selecionadas na confecção do Plano de Dados Abertos.

5.1.2.6 Cronograma de abertura

Este passo para definição de cronogramas de abertura das bases deverá levar em

consideração o score atingido na matriz de priorização. Toda a parte de cronograma ainda

está em fase de desenvolvimento.

5.1.2.7 Registro do Plano de Dados Abertos

Chegando ao passo final, esta é a etapa onde serão descritas todas as ações e

estratégias definidas de todos os passos anteriores (CGU, 2020). É onde o documento de

Plano de Dados Abertos será realmente criado, seguindo a estrutura definida nos manuais

da CGU. Para que todas as ações fossem registradas de uma forma simples, criamos um

formulário (Figura 18) dividido em abas, que contempla todos os tópicos sugeridos para

a estrutura do documento.

79

Figura 18 - Exemplo do formulário de escrita do PDA.


Com componentes que nos auxiliam na escrita de textos como se estivéssemos em

um software próprio para edição de texto, conseguimos reescrever todo o PDA do IFRN.

O PDA reescrito está disponibilizado na seção de anexos a este trabalho.

5.2 INTEGRAÇÃO

Com o intuito de expandir as ações com relação ao ambiente opendata, o Opendata

Manager possui um módulo integrador (Figura 19) que fornece uma interface que interage

com o serviço de mensageria. O objetivo principal é a comunicação com algum software

externo que realize as operações de extração e publicação de dados. Como explicado na

seção 3.3, vamos utilizar o Opendata Processor (ODP) para realizar essas tarefas.

Figura 19 - Integração ODM com ODP


80

O Opendata Processor precisará implementar a interface de comunicação com o

serviço de mensageria (RabbitMQ) e, ao iniciar uma instância da aplicação, será

necessário também chamar o método que inicia a escuta desse serviço. Sendo assim, as

duas aplicações conseguirão se conectar ao broker e trocar mensagens através dele.

Também é importante que as duas aplicações conheçam as chaves de submissão e

consumo de mensagem. Com tudo configurado, a troca de mensagem acontecerá como

mostrado no diagrama de sequência da Figura 20.

Figura 20 - Sequência de troca de mensagens entre as duas aplicações

Fonte: Elaboração do autor

Com essa troca de mensagem, conseguimos executar ações dentro do ODP,

inclusive solicitar a extração dos dados e a publicação deste na plataforma de dados

abertos que estiver configura nele.

5.3 ARQUITETURA DO OPENDATA MANAGER

Nesta seção, vamos detalhar as duas arquiteturas em que o Opendata Manager

pode ser implantado dentro de um órgão ou instituição pública.

81

5.3.1 Arquitetura stand-alone

Neste tipo de arquitetura, a aplicação fica independente de outras aplicações,

sendo feito o deploy em um servidor dedicado a ela. Embora o Opendata Manager tenha

um resultado satisfatório nos testes de performance (seção 5.5), é interessante isolar sua

execução para que outras aplicações não sejam prejudicadas por um eventual pico de

acesso. Na imagem a seguir é detalhada a arquitetura descrita.

Figura 21 - Arquitetura stand-alone


5.3.2 Arquitetura de Software como Service (SaaS)

O Opendata Manager também pode ser executado como um serviço, onde um

órgão público ficará responsável pelo sistema e também pela infraestrutura onde o ODM

irá rodar, tirando essa responsabilidade dos órgãos clientes. Essa arquitetura facilita a

aceitação do software, uma vez que não é necessário dispor de nenhum recurso de

hardware e software por parte dos clientes, sendo apenas necessário a criação da instância

do serviço. Pereira (2019) exemplifica dois tipos de arquitetura SaaS: i) modelo single-

tenant, e; ii) modelo multi-tenant.

82

Figura 22 - Arquitetura SaaS Single-tenant


Na arquitetura single-tenant, cada inquilino tem sua instância do Opendata

Manager e um banco de dados dedicados, compartilhando apenas os recursos de

hardware. Embora essa arquitetura tenha como finalidade uma melhor performance da

aplicação, sua manutenção não é tão simples, pois, uma vez que uma versão nova do

ODM é lançada, seria necessário atualizar em todas as instâncias existentes. Já na

arquitetura multi-tenant isso não seria um problema, uma vez que a aplicação é única para

todos os inquilinos.

Figura 23 - Arquitetura SaaS Multi-tenant


83

Nessa arquitetura, todos os inquilinos compartilham uma única instância do

Opendata Manager e fazem acesso a estratégia adotada para separação dos dados.

Devemos também ter atenção com relação a estratégia de separação dos dados de

cada inquilino, pensado em não degradar a performance da aplicação devido ao banco de

dados. Na arquitetura SaaS, segundo Campomori (2019), podemos dividir os dados de

três formas: i) utilização de chave estrangeira; ii) separação via schema, e; iii) separação

via banco de dados. A seguir, vamos detalhar cada uma das estratégias apresentadas.

5.3.2.1 Utilização de chave estrangeira

Para utilizar um único banco de dados para todos os inquilinos da instância (Figura

24), seria necessário separa os registros de cada inquilino utilizando uma chave

estrangeira. Assim, quando um “inquilino A” se logar no sistema, será aplicado um filtro

nos resultados da consulta, mostrando apenas os registros pertencentes a ele.

Figura 24 - Ilustração da utilização de chave estrangeira


A vantagem desta abordagem é que a sua implementação é bem simples, pois é

necessário apenas a adição da chave estrangeira e a realização de filtros na consulta das

tuplas. Porém, a desvantagem pode ser crítica, pois existindo apenas um único banco para

todas as instâncias, se apenas uma instância executar uma operação muito pesada no

banco, todas as outras instâncias sofrerão com problema de performance. Essa estratégia

não é recomendada para sistemas com um volume de dados muito grande.

5.3.2.2 Separação via schema

Esta estratégia consiste em separar conjuntos de tabelas da aplicação isolados para

cada um dos inquilinos, mantendo ainda uma única instância do banco de dados. Esta

estratégia é exemplificada na Figura 25.

84

Figura 25 - Ilustração da utilização de separação via schema


O isolamento lógico dos conjuntos de tabelas é uma clara vantagem, garantindo

que alterações ou remoções indevidas fiquem restritas àquele schema apenas. Porém,

como ainda estamos utilizando uma instância única do banco de dados, ainda pode não

ser uma boa estratégia quando vamos trabalhar com uma grande quantidade de dados.

5.3.2.3 Separação via banco de dados

Neste tipo de estratégia, cada inquilino terá sua instância de banco dedicada, onde

o isolamento agora é físico. Com isso, teremos um ganho de performance e isola

definitivamente o problema de um inquilino prejudicar a performance de outra instância,

isso, claro, a nível de banco de dados. Figura 26 - Ilustração da separação via banco de dados


5.4 DEPLOY DO OPENDATA MANAGER

Para facilitar o processo de deploy da aplicação em qualquer um dos ambientes

escolhido pelo cliente, procuramos técnicas e ferramentas que nos auxiliassem neste

processo. Utilizamos o Docker por ser uma ferramenta que faz exatamente o que

pretendemos: “empacota” a aplicação e todas as suas dependências dentro de um

container (WILLIANS, 2019). Além disso, o docker também permite instalar outras

85

aplicações dentro de uma mesma rede virtual, o que facilita a conectividade entre o

Opendata Manager e essas aplicações, como banco de dados e o serviço de mensageria.

Utilizando o docker-compose, que é o orquestrador dos containers criados pelo

docker (WILLIANS, 2019), conseguimos facilmente subir um ambiente completo com a

aplicação rodando e todas as suas dependências instaladas. Para o Opendata Manager

criamos dois ambientes no projeto: 1) ambiente de desenvolvimento, e; 2) ambiente de

produção. Com a utilização do docker-compose.yml, configuramos os dois ambientes de

forma bem simples. Podemos observar na Figura 27 a configuração do arquivo docker-

compose.yml para o ambiente de desenvolvimento. Figura 27 – Parte do arquivo docker-compose.yml para ambiente

de desenvolvimento

1: Elaborada pelo autor

Com poucas linhas de configuração, é possível instalar uma versão do banco de

dados, configurar as constantes de acesso e subir nossa aplicação. Para o ambiente de

produção, é necessário realizar configurações adicionais, utilizando mais tecnologias para

suportar a demanda que este ambiente possa apresentar. Logo, criamos e configuramos o

arquivo docker-compose-prod.yml (Figura 28) com a utilização do Unicorn para atuar

como servidor de aplicação e o Nginx para atuar como proxy reverso.

86

Figura 28 - Parte do arquivo docker-compose-prod.yml com as configurações adicionais do gunicorn e nginx


5.5 AVALIAÇÃO DE PERFORMANCE

Nesta seção vamos avaliar a aplicação desenvolvida com relação a sua

performance, simulando alguns cenários que poderemos encontrar em ambiente de

produção.

5.5.1 OBJETIVOS

Esta avaliação de performance tem por objetivo verificar como a aplicação se

comporta com uma quantidade variada de usuários, observando o seu comportamento na

medida em que a quantidade de usuários aumenta. Além de verificar a aplicação, também

vamos avaliar a porcentagem de consumo de processamento e memória quando a

aplicação é posta em condições de estresse.

A avaliação de performance foi necessária pois a aplicação poderá funcionar em

uma arquitetura SaaS, onde o número de usuários simultâneos vai variar de acordo com

o número de inquilinos interessados na ferramenta. Logo, é importante realizar um teste

de performance com quantidade variadas de usuários simultâneos para detectarmos com

antecedência os pontos de gargalo existentes na aplicação e corrigi-los antes da

ferramenta entrar em ambiente de produção.

87

5.5.2 CONFIGURAÇÕES E MÉTRICAS

Realizando uma pesquisa na literatura, identificamos que as métricas utilizadas

para testes de performance são os testes de consumo de recursos de hardware

(benchmark) [J. Dilley., R. Friedrich., T. Jin e J. Rolia - 1998] e testes de tempo de

resposta (response time) [Zhang, L; Zhu, Q. - 2014].

Para realizar o teste de performance, vamos utilizar o software Apache JMeter

(APACHE..., 2020) para gerar carga de tráfego com cenários de usuários virtuais

diferentes. Os testes serão rodados até nas informações obtidas se manterem estáveis, sem

grandes alterações. Também vamos utilizar o Zabbix (ZABBIX..., 2020) para monitorar

os recursos de hardware utilizados durante os testes.

O Opendata Manager está rodando em um servidor Linux Ubuntu 20.04 LTS, que

dispõem de um processador Intel Core i7 – 2600K de 3.40GHz e 8GB de memória ram.

O JMeter e Zabbix estão rodando em máquinas separadas para não interferir no resultado

dos testes. No JMeter, foram realizadas várias configurações de monitoramento de

execução, assim como o mapeamento das ações que são executadas dentro do Opendata

Manager. Desta forma, todas as urls mapeadas no sistema foram abarcadas neste

mapeamento a fim de testá-las com acessos simultâneos de usuários virtuais.

Executamos 20 rodadas de testes para um quantitativo diferente de usuários

virtuais simulando a utilização da aplicação. Analisamos a estabilidade de curva de

monitoramento do tempo de resposta das requisições para verificar se o quantitativo de

teste é o suficiente. A quantidade de usuários que iremos utilizar nas simulações foram

inferidas de acordo com a quantidade de pessoas que integram os grupos de trabalhos no

desenvolvimento de um PDA. Analisamos 10 Planos de Dados Aberto (Tabela 17 -

Tabela de PDAs analisados com relação ao grupo de trabalho) para extrairmos essa

informação e chegamos a uma média de 4,7 integrantes. Essa média ignorou os PDAs na

UNIFESSPA e TRT 18ª Região por serem considerados outliers. Como o Opendata

Manager é destinado para esse público-alvo, essa foi a forma adotada para estipular a

quantidade de usuários virtuais.

Tabela 17 - Tabela de PDAs analisados com relação ao grupo de trabalho

Instituição PDA/Vigência Qtd. membros 1 IBAMA PDA/2020 - 2021 10 2 UFGD PDA/2020 - 2022 6 3 UNIFESSPA PDA/2020 - 2021 2

88

4 Ministério do Meio Ambiente PDA/2017 - 2018 5 5 TRT 18ª Região PDA/2019 - 2020 17

6 Jardim Botânico do Rio de Janeiro PDA/2019 - 2020 8

7 Jardim Botânico do Rio de Janeiro PDA/2017 - 2018 7

8 CGU PDA/2018 - 2020 7 9 IFBA PDA/2021 - 2022 7 10 UFMA PDA/2017 - 2019 5


O ODM terá a opção de ser utilizado como serviço, atendendo a mais de um órgão

ao mesmo tempo, por isso, realizamos os testes com a configuração de multi-tenant e com

os quantitativos de usuários: a) 10 usuários virtuais; b) 20 usuários virtuais; c) 50 usuários

virtuais; d) 100 usuários virtuais; e) 500 usuários virtuais. Para cada quantitativo de

usuários, rodamos os testes 20 vezes e analisamos a curva de estabilidade das métricas

adotadas (response time e benchmark).

5.5.2.1 Configurações do JMeter

O Apache JMeter é uma ferramenta escrita em Java que permite realizar teste de

estresse em aplicações web e medir o seu desempenho. Suporta vários tipos de protocolos

diferentes, como HTTP, HTTPS, SOAP, REST, FTP, LDAP, Middleware orientado a

mensagens, dentro outros. Para monitorar a execução dos testes realizamos as

configurações de alguns parâmetros:

x Gráfico agregado: mostra um gráfico em linhas com todas as requisições

agregadas para termos uma ideia do tempo de resposta geral;

x Relatório de sumário: mostra a quantidade que uma requisição foi feita,

retornando a porcentagem de erro, vazão por minuto e quantidade de KB

por segundo, dentro outros indicadores;

x Relatório agregado: mesmas informações do relatório de sumário, mas

agregando as requisições dos vários usuários virtuais simultâneos;

x PerfMom Metrics: plugin que se conecta ao servidor onde a aplicação

está rodando através de um serviço rodando em uma portar específica e

mede o consumo de processamento, memória, disco e rede;

x Response Time Graph: mostra todas as requisições mapeadas e seu

tempo de responsa ao logo da execução dos testes.

89

Feita a configuração dos listeners da execução dos testes, vamos implementar os

scripts de testes de cada funcionalidade da aplicação. As configurações de requisição

utilizam o mesmo padrão de requisições que os browsers, simulando fielmente um ou

mais usuários na utilização da aplicação. Todas as urls mapeadas nos arquivos urls.py

dentro da aplicação foram mapeadas também no JMeter, abarcando todas as requisições

da aplicação.

Para testar apenas uma funcionalidade da aplicação, foi necessário implementar

duas requisições testes, por exemplo: para testar a funcionalidade de “Cadastrar Grupo

de Trabalho” foi necessário mapear a requisição “Acessar Formulário de Cadastro de

Grupo de Trabalho” e a requisição “Cadastrar Grupo de Trabalho”. Nota-se que o fluxo

de cadastro é semelhando a um usuário acessando o sistema, uma vez que ele necessita

acessar a página que tem o formulário, preencher o formulário e enviá-lo. Na Figura 29 é

possível ver as primeiras configurações de requisição configuradas no JMeter.

Figura 29 - Mapeamento das requisições no JMeter


O fluxo de acessar primeiramente a tela do formulário e depois cadastrar a

informação é necessário por um motivo. Todos os formulários do django utilizam a

proteção CSRF Token, que é um campo oculto no formulário com um valor de hash que

também está salvo na sessão do usuário. Em todas as submissões de formulário, esse

campo precisa ser checado e caso a informação vinda do formulário não bater com a

informação salva em sessão, a submissão é negada. Logo, para que fosse possível que

nossos scripts de cadastro e edição funcionassem, foi preciso acessar o formulário de

cadastro, obter o csrf_token e salvá-lo no contexto do nosso teste para, posteriormente,

realizar as submissões.

90

5.5.2.2 Configurações do ZABBIX

Rodando o Zabbix em um servidor Linux Ubuntu 18.04 com processador Intel

Core i7 – 6500U 2,5GHz com 16GB de memória ram. Foi instalado o serviço do Zabbix

na máquina onde está rodando o Opendata Manager para monitoramento dos recursos de

máquina. Sendo assim, foi configurado no Zabbix o monitoramento de consumo de CPU

e Memória durando o período de teste.

5.5.3 EXECUÇÃO DOS TESTES

Nesta seção, vamos rodar os testes com as quantidades de usuários que foram

estipuladas na seção 5.5.2. Nas 20 rodadas de testes realizadas para cada quantidade de

usuários, obtivemos uma estabilidade com relação ao tempo de resposta durante toda a

execução. Vamos analisar cada situação isoladamente, verificando cada informação

coletada.

5.5.3.1 Testes com 10 usuários virtuais simultâneos

Tabela 18 - Resultado das rodadas de testes com 10 usuários

Rodadas Zabbix Jmeter Response time (ms) Percent error proc mem proc mem 1 2,50 21,30 5,90 18,60 487 0,00 2 2,30 21,25 3,60 18,90 203 0,00 3 2,30 21,75 3,10 19,80 246 0,00 4 2,40 21,72 2,60 19,60 221 0,00 5 2,50 21,83 2,90 19,70 148 0,00 6 2,06 21,85 2,48 19,87 252 0,00 7 2,20 22,10 2,46 19,30 244 0,00 8 3,27 21,50 3,51 18,20 277 0,00 9 2,35 21,50 3,86 18,60 188 0,00 10 3,77 21,80 3,65 18,80 292 0,00 11 2,39 22,50 2,15 19,20 298 0,00 12 3,59 21,40 3,13 19,60 260 0,00 13 2,70 22,30 2,13 18,10 187 0,00 14 2,76 22,60 3,83 19,00 249 0,00 15 3,86 21,50 2,47 19,40 201 0,00 16 3,45 21,40 2,27 18,90 230 0,00 17 2,94 22,10 3,80 19,30 231 0,00 18 3,19 22,60 2,63 18,50 257 0,00 19 2,97 21,50 3,04 19,80 210 0,00 20 2,70 21,60 2,43 19,50 192 0,00


91

Figura 30 - Monitoramento via ZABBIX


Figura 31 - Monitoramento via JMeter


Figura 32 - Monitoramento do tempo de resposta



Tabela 19 - Resultado das rodadas de testes com 20 usuários

Rodadas Zabbix jmeter Response time (ms)

Percent error proc mem proc mem

1 6,85 21,71 10,70 19,90 403 0,00 2 7,75 22,03 11,90 20,50 496 0,00 3 8,01 22,29 12,30 20,80 363 0,00 4 9,93 22,59 11,00 20,30 571 0,00 5 9,74 22,26 13,80 20,40 564 0,00 6 5,49 22,27 11,30 20,70 521 0,00 7 6,35 22,20 12,80 20,40 486 0,00 8 8,98 22,01 11,40 20,00 495 0,00 9 9,04 22,08 13,20 20,60 507 0,00 10 6,96 23,21 13,10 20,70 496 0,00 11 8,14 22,24 13,70 20,30 481 0,00 12 6,28 21,99 11,00 20,80 485 0,00 13 5,36 22,83 12,00 20,70 500 0,00 14 6,66 22,88 13,40 20,80 518 0,00 15 6,54 23,21 11,20 20,50 484 0,00

92

16 7,06 22,52 10,90 20,60 481 0,00 17 6,20 21,96 12,90 19,90 517 0,00 18 8,37 21,95 12,30 20,20 483 0,00 19 7,74 22,40 10,90 19,90 510 0,00 20 7,06 23,10 11,60 20,00 505 0,00


Figura 33 - Monitoramento via Zabbix




Figura 35 - Monitoramento de tempo de resposta



Tabela 20 - Resultados das rodadas de testes com 50 usuários

Rodadas Zabbix jmeter Response time (ms)

Percent error proc mem proc mem

1 17,83 25,86 21,60 23,70 2.334 0,00 2 15,70 25,77 20,70 23,60 1.085 0,00 3 15,84 25,71 19,50 23,20 2.007 0,00 4 17,07 32,93 23,10 31,30 2.300 0,00 5 16,93 34,74 17,40 32,90 1.838 0,00 6 17,20 33,14 21,16 32,78 1.995 0,00

93

7 16,50 31,85 17,87 32,58 1.840 0,00 8 15,90 32,60 22,04 33,09 1.981 0,00 9 17,90 31,19 18,07 33,07 1.928 0,00 10 16,60 33,17 19,55 32,01 1.884 0,00 11 17,60 33,19 20,92 31,55 1.838 0,00 12 17,80 31,32 20,21 32,02 1.843 0,00 13 16,50 32,34 22,50 31,56 1.913 0,00 14 17,10 31,55 21,17 32,38 1.947 0,00 15 17,70 33,19 18,25 33,38 1.965 0,00 16 15,70 33,81 22,47 31,14 1.939 0,00 17 17,50 31,92 21,41 31,75 1.959 0,00 18 16,00 32,40 20,60 32,34 1.923 0,00 19 17,10 31,71 23,53 33,16 1.969 0,00 20 16,50 32,51 20,43 32,15 1.853 0,00






Figura 38 - Monitoramento de tempo de resposta


94


Tabela 21 - Resultados das rodadas de testes com 100 usuários Rodadas Zabbix JMeter Response time (ms) Percent error proc mem proc mem

1 17,59 35,87 20,40 33,70 5.578 0,00 2 17,33 36,30 19,90 34,60 6.191 0,00 3 18,09 36,96 19,30 34,80 6.822 0,00 4 18,56 39,81 19,90 38,60 4.554 0,00 5 18,05 33,81 21,20 31,60 4.543 0,00 6 17,70 33,14 20,40 31,20 4.757 0,00 7 18,14 34,05 21,32 32,64 4.040 0,00 8 19,02 35,02 20,08 37,64 4.095 0,00 9 18,92 33,09 20,19 36,75 3.803 0,00 10 18,00 36,88 20,00 34,32 4.507 0,00 11 18,43 34,82 21,67 31,92 4.187 0,00 12 17,02 35,43 21,04 32,19 4.156 0,00 13 18,31 36,19 20,77 37,49 4.264 0,00 14 17,39 34,21 20,24 36,80 4.558 0,00 15 17,86 33,17 20,54 32,52 4.150 0,00 16 18,37 34,41 21,08 33,94 3.786 0,00 17 18,03 34,73 20,38 36,92 3.704 0,00 18 17,26 34,86 21,97 31,02 3.896 0,00 19 18,85 36,19 20,56 35,80 4.288 0,00 20 18,64 35,76 20,40 36,62 3.995 0,00






95




Tabela 22 - Resultados das rodadas de testes com 500 usuários

Rodadas Zabbix jmeter Response time (ms) Percent error proc mem proc mem 1 27,57 39,65 24,70 37,70 12.987 0,00 2 20,79 39,03 22,20 36,50 36.109 0,00 3 18,65 39,91 21,40 41,40 35.762 0,36 4 20,63 38,97 18,60 40,50 34.987 0,00 5 19,74 39,73 19,50 40,90 35.640 0,03 6 20,48 39,77 21,10 39,31 36.629 0,00 7 19,89 39,89 19,70 40,21 35.663 0,00 8 20,89 39,14 20,40 40,60 35.249 0,00 9 21,07 39,79 19,30 41,01 34.279 0,00 10 21,88 38,91 20,70 39,16 35.264 0,00 11 20,47 38,80 21,20 41,17 35.648 0,00 12 20,20 39,79 21,30 41,63 34.818 0,00 13 19,88 39,43 21,60 40,82 34.597 0,00 14 21,69 38,86 21,50 39,74 35.465 0,03 15 20,74 39,83 20,60 40,94 35.636 0,00 16 19,34 39,50 21,70 41,86 34.026 0,00 17 19,80 38,82 21,50 41,84 33.749 0,00 18 20,30 39,74 19,90 40,03 34.252 0,00 19 21,56 38,95 21,30 41,86 34.894 0,00 20 20,48 39,11 21,00 41,23 34.406 0,00




96




Após todas as rodadas de testes e análise dos resultados, realizamos um compilado

das informações, demonstrando de forma resumida os resultados obtidos.

Tabela 23 - Média dos resultados dos testes

Rodadas Usuários ZABBIX JMeter Response Time (ms)

Porcentagem de Erro proc. mem. proc. mem.

20 10 2,81 21,81 3,10 19,13 243,65 0% 20 20 7,43 22,39 12,07 20,40 493,30 0% 20 50 16,85 31,55 20,62 30,98 1.917,05 0% 20 100 18,08 35,24 20,57 34,55 4.493,70 0% 20 500 20,80 39,38 20,96 40,42 34.003,00 0,02%


Com as médias apresentadas na tabela Tabela 23 - Média dos resultados dos testes

elaboramos os gráficos que nos mostram de forma visual os resultados obtidos.

97

Figura 45 - Consumo de processamento por usuários


Figura 46 - Consumo de memória por usuários


Figura 47 - Tempo de resposta e percentual de erros por usuários


5.6 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.

98

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

99

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.

100

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


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.

101

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.

102

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.

6.2 TRABALHOS FUTUROS

Como explanado no tópico 6.1, o ODM não executa as tarefas de extração e

publicação de dados abertos, dependendo de aplicações externas para isso. É pretendido

implementar um módulo dentro do ODM com essas funcionalidades, englobando assim

todo o ambiente opendata.

Também é necessário a implementação da utilização de arquivos (txt, csv ou json)

como fonte de informação do órgão público, caso o mesmo não possua um sistema

integrado de gestão.

É necessário apresentar a aplicação para uma instituição pública e colocá-la em

produção de fato. Esse passo será de fundamental importância para consolidá-la e corrigir

possíveis falhas que, no nosso processo de desenvolvimento, não encontramos. Este passo

também será importante para que outros setores do órgão possam interagir no processo

de desenvolvimento do PDA, não deixando apenas esse trabalho a cargo da área de TI,

103

como é recomendado pela CGU. O Instituto Federal do Rio Grande do Norte será o

primeiro órgão público a testar as funcionalidades do Opendata Manager. O ODM já está

rodando em um ambiente de teste faltando apenas alguns pequenos ajustes para que

convoquemos alguns usuários para a realização dos testes.

Também foi pensado em expandir a camada de serviço para integrar com algumas

funcionalidades específicas de aplicações mobile, facilitando o trabalho de integração

para órgãos e instituições que possuem apps mobile.

104

7 REFERÊNCIAS ANTUNES, Bruna Fabio. O que são dados abertos e como eles impactam a sua vida?. [S. l.], 24 fev. 2017. Disponível em: https://www.politize.com.br/dados-abertos-o-que-sao/. Acesso em: 18 jun. 2020. APACHE JMeter™. [S. l.], 2020. Disponível em: https://jmeter.apache.org/. Acesso em: 9 fev. 2021. ARY, Thalita Carneiro. Plano de Dados Abertos. [S. l.], 22 jul. 2020. Disponível em: http://wiki.dados.gov.br/Plano-de-Dados-Abertos.ashx. Acesso em: 3 ago. 2020. ARY, Thalita Carneiro. Política de Dados Abertos do Poder Executivo Federal. [S. l.], 22 jul. 2020. Disponível em: http://wiki.dados.gov.br/Politica-de-Dados-Abertos.ashx. Acesso em: 1 ago. 2020. BRASIL, CONGRESSO NACIONAL. Lei 12.527/2011. Disponível em http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2011/lei/l12527.htm. Acesso em: 27 jul. 2020

BRASIL. Decreto nº 8.777, de 11 de maio de 2016. Institui a Política de Dados Abertos do Poder Executivo Federal. [S. l.], 11 maio 2016. Disponível em: http://www.planalto.gov.br/ccivil_03/_Ato2015-2018/2016/Decreto/D8777.htm. Acesso em: 23 ago. 2019.

BRASIL. Kit para dados abertos. Processo sistêmico de um Plano de Dados Abertos - PDA: Implementando uma política de dados abertos. [S. l.], 2020. Disponível em: https://kit.dados.gov.br/Processo-sist%C3%AAmico/. Acesso em: 3 ago. 2020. BRASIL. Portal Siapenet. [S. l.], 1989. Disponível em: http://www.siapenet.gov.br/Portal/Servico/Apresentacao.asp. Acesso em: 12 ago. 2020. CAMPOMORI, Cleber. O que é uma aplicação multitenant?: Mas, afinal, o que é multitenancy?. [S. l.], 15 jul. 2019. Disponível em: https://www.treinaweb.com.br/blog/o-que-e-uma-aplicacao-multitenant/. Acesso em: 11 fev. 2021. CGU. Manual de Elaboração de Planos de Dados Abertos (PDAs): UMA PUBLICAÇÃO DA SECRETARIA DE TRANSPARÊNCIA E PREVENÇÃO DA CORRUPÇÃO | CGU. [S. l.]: CGU, 2020. Disponível em: https://www.gov.br/cgu/pt-br/centrais-de-conteudo/publicacoes/transparencia-publica/arquivos/manual-pda.pdf. Acesso em: 30 jul. 2020. CONTROLADORIA-GERAL DA UNIÃO. Governo Federal. Ecossistema de Dados Abertos - Monitoramento e Execução. [S. l.], 29 out. 2018. Disponível em: https://www.gov.br/cgu/pt-br/governo-aberto/a-ogp/planos-de-acao/4o-plano-de-acao-brasileiro/compromisso-2-docs/ecossistema-de-dados-abertos-monitoramento-e-execucao. Acesso em: 1 ago. 2020.

105

DADOS Abertos Governamentais. [S. l.], 26 nov. 2019. Disponível em: https://www.gov.br/governodigital/pt-br/dados-abertos/dados-abertos-governamentais. Acesso em: 11 fev. 2020. Djangoproject.com. 2020. The Web Framework For Perfectionists With Deadlines | Django. Disponível em: https://www.djangoproject.com. Acesso em: 9 abr. 2020.

ELABORAÇÃO do Plano de Dados Abertos (PDA). [S. l.]: Enap, 2017. Disponível em: http://repositorio.enap.gov.br/handle/1/3153. Acesso em: 18 mar. 2020. E. S. Pramukantoro, J. Ratna Wulandari, W. Yahya and H. Nurwarsito, "A Cluster Message Broker in IoT Middleware using Ioredis," 2018 International Conference on Sustainable Information Engineering and Technology (SIET), Malang, Indonesia, 2018, pp. 247-251.

FARIA, Luiz Carlos. Redis, um Message Broker? [S. l.], 2019. Disponível em: https://gago.io/blog/rabbitmq-amqp-8-redis. Acesso em: 6 abr. 2020.

G. Cugola, A. Margara and M. Migliavacca, "Context-aware publish-subscribe: Model, implementation, and evaluation," 2009 IEEE Symposium on Computers and Communications, Sousse, 2009, pp. 875-881.

GOVERNO ABERTO. O que é a iniciativa?. [S. l.], 2012. Disponível em: https://governoaberto.cgu.gov.br/a-ogp/o-que-e-a-iniciativa. Acesso em: 4 dez. 2019.

GOVERNO FEDERAL. Portal do Servidor. Sigepe - Sistema de Gestão de Pessoas. [S. l.], 3 jun. 2016. Disponível em: https://www.gov.br/servidor/pt-br/acesso-a-informacao/gestao-de-pessoas/sigepe. Acesso em: 12 ago. 2020. GOVERNO FEDERAL. Ministério do Meio Ambiente. O que é Interoperabilidade?. [S. l.], 2019. Disponível em: https://www.mma.gov.br/informma/item/869-interoperabilidade-o-que-%C3%A9. Acesso em: 13 maio 2020. GRANICUS. DKAN: Features. 2017. Disponível em: <http://getdkan.com/features/>. IFRN - Instituto Federal do Rio Grande do Norte. [S. l.], 2019. Disponível em: https://portal.ifrn.edu.br. Acesso em: 3 dez. 2019. INTEROPERABILIDADE: Interoperabilidade, e-PING, padrões de interoperabilidade. [S. l.], 26 maio 2020. Disponível em: https://www.gov.br/governodigital/pt-br/governanca-de-dados/interoperabilidade. Acesso em: 8 jun. 2020. ITZKOVICH, Sefi. Redis, Kafka or RabbitMQ: Which MicroServices Message Broker To Choose?. [S. l.], 20 maio 2019. Disponível em: https://otonomo.io/blog/redis-kafka-or-rabbitmq-which-microservices-message-broker-to-choose. Acesso em: 12 mar. 2020. Jay Kreps, Neha Narkhede, Jun Rao, "Kafka: A Distributed Messaging System for Log Processing", at NetDB workshop, 2011

106

Järvelä, A., & Lindmark, S. (2019). Evaluation and comparison of a RabbitMQ broker solution on Amazon Web Services and Microsoft Azure (Dissertation). Retrieved from http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-158242

J. Dilley., R. Friedrich., T. Jin e J. Rolia. “Web server performance measurement and modeling techniques”. Hewlett-Packard Laboratories, 1998.

J. Yamamoto, H. Nakagawa, K. Nakayama, Y. Tahara and A. Ohsuga, "A Context Sharing Message Broker Architecture to Enhance Interoperability in Changeable Environments," 2009 Third International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies, Sliema, 2009, pp. 31-39.

K. Goodhope et al. Building LinkedIn’s Real-time Activity Data Pipeline. IEEE Data Eng. Bull., 35(2):33–45, 2012.

KOTONYA, G.; SOMMERVILLE, I. Requirements engineering: process and techniques. Chichester: John Wiley & Sons, 2000. LABUSCHAGNE, A. C.; BRENT, A. C.; ERCK, R. P. G. van. Assessing the sustainability performances of industries. Journal of Cleaner Production, v. 13, n. 4, p. 373-385, 2005. http://dx.doi.org/10.1016/j.jclepro.2003.10.007

NIELSEN, Jakob. Powers of 10: Time Scales in User Experience: From 0.1 seconds to 10 years or more, user interface design has many different timeframes, and each has its own particular usability issues.. [S. l.], 4 out. 2009. Disponível em: https://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/. Acesso em: 5 abr. 2021. NONES, Fernanda. LGPD: o que diz a nova lei brasileira de proteção de dados e como ela pode impactar a estratégia de marketing de sua empresa. [S. l.], 16 jun. 2020. Disponível em: https://resultadosdigitais.com.br/blog/o-que-e-lgpd/. Acesso em: 18 nov. 2020. MARCONDES, C.H.; SAYÃO, L.F. Integração e interoperabilidade no acesso a recursos informacionais eletrônicos em C&T: a proposta da Biblioteca Digital Brasileira. Ciência da Informação, v.30, n.3, p.24-33, 2001. Disponível em: http://www.scielo.br/pdf/ci/v30n3/7283.pdf. Acesso em: 11 fev. 2020.

MILLER, P. Interoperability. What is it and why should I want it? Ariadne, n.24, 2000. Disponível em: http://www.ariadne.ac.uk/issue24/interoperability. Acesso em: 18 mar. 2020.

O QUE são Dados Abertos?. [S. l.], 19 out. 2016. Disponível em: https://opendatahandbook.org/guide/pt_BR/what-is-open-data/. Acesso em: 7 nov. 2019.

OPENDATASOFT. Features. 2017. Disponível em: https://www.opendatasoft.com/ features/. Acesso em: 2 ago. 2020.

OPEN KNOWLEDGE FOUNDATION. What is open? [S. l.], 2009. Disponível em: https://okfn.org/opendata/. Acesso em: 2 ago. 2020.

107

OPEN KNOWLEDGE INTERNATIONAL. CKAN. 2017. Disponível em: http: //ckan.org/about/. Acesso em: 10 ago. 2020.

OPERAÇÃO Serenata de Amor. [S. l.], 2016. Disponível em: https://serenata.ai/. Acesso em: 22 jul. 2020. PAINEL de Monitoramento de Dados Abertos. [S. l.], 2017. Disponível em: http://paineis.cgu.gov.br/dadosabertos/index.htm. Acesso em: 22 jul. 2020. PARVIAINEN, P.; TIHINEN, M.; SOLINGEN, R. Requirements engineering: dealing with the complexity of Sociotechnical Systems Development. In: MATÉ, J. L.; SILVA, A. Requirements engineering for sociotechnical systems. Hershey: Information Science, 2005.

PEREIRA, Edytarcio. Arquitetura Multi-Tenancy: Já ouviu falar no termo multi-tenant ou multi-tenancy?. [S. l.], 20 dez. 2019. Disponível em: https://medium.com/@edytarcio/arquitetura-multi-tenancy-bb7b47d7ba. Acesso em: 18 fev. 2021. PLANO de Dados Abertos do Ministério do Planejamento. 3.0.1. [S. l.], 2018. Disponível em: https://plano.dados.planejamento.gov.br/. Acesso em: 12 mar. 2020. PRESSMAN, Roger S. Engenharia de Software: 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

PORTAL BRASILEIRO DE DADOS ABERTOS. O que são dados abertos?. [S. l.], 2019. Disponível em: http://dados.gov.br/pagina/dados-abertos. Acesso em: 7 abr. 2020. POSTGRESQL: The World‘s Most Advanced Open Source Relational Database. [S. l.], 2019. Disponível em: https://www.postgresql.org/. Acesso em: 17 out. 2019. POSSAMI, Ana Júlia. Dados abertos do Governo Federal brasileiro: desafio de transparência e interoperabilidade / Ana Julia Possamai. -- 2016. 313 f.

Python.org. 2020. Welcome To Python.Org. Disponível em: https://www.python.org/. Acesso em: 9 jan. 2020.

REDISLABS. Introduction to Redis. [S. l.], 2017. Disponível em: https://redis.io/topics/introduction. Acesso em: 2 abr. 2020.

ROZENFELD, H. et al. Gestão de desenvolvimento de produtos: uma referência para a melhoria do processo. São Paulo: Saraiva, 2006.

S. Duke, P. Makey, N. Kiras. Application Integration Management Guide: Strategies and Technologies, Butler Group Ltd, Hull, 1999.

S. Vinoski. Advanced Message Queuing Protocol. IEEE Internet Computing, 10 (6), 2006.

SILVA, Rafael Ferreira. A importância da interoperabilidade. Disponível em: http://phpbrasil.com/articles/article.php/id/851, Acesso em: 29 maio 2020.

108

SOCRATA. Socrata solutions cloud-based data democratization solutions for government. 2017. Disponível em: https://www.opendatasoft.com/features/. Acesso em: 02 jun. 2020.

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

T. Puschmann, R. Alt, Enterprise application integration - The case of the Robert Bosch Group, in: CD Proceedings of the 34th Hawaii International Conference on System Sciences, Maui, HI, 2001.

TICO SOFTWARE INC. What is a Message Broker?. [S. l.], 2017. Disponível em: https://www.tibco.com/reference-center/what-is-a-message-broker. Acesso em: 11 mar. 2020.

UKOLN. Interoperability focus: looking at interoperability. 2005. Disponível em: http://www.ukoln.ac.uk/interop-focus/about/leaflet.html. Acesso em: 18 jan. 2020.

VERNADAT, F. B, Enterprise modelling and integration: principles and applications, 1996, London, Chapman & Hall.

VILELA, Allyson Bruno Campos Barros. OpenData Processor: uma ferramenta para a automatização do processo de extração e publicação de Dados Abertos / Allyson Bruno Campos Barros Vilela. - 2018. 97f.: il.

WILLIANS, Wesley. Docker e Docker Composer na Prática – Criando um Ambiente Laravel. [S. l.], 15 ago. 2019. Disponível em: https://fullcycle.com.br/docker-e-docker-composer-na-pratica-criando-ambiente-laravel/. Acesso em: 2 jan. 2021. ZABBIX. Zabbix - The Enterprise-class Monitoring Solution for Everyone. 2020. Disponível em: http://www.zabbix.com/. Acesso em: 18 fev. 2021.

Zhang, L; Zhu, Q. “The Overtime Waiting Model for web server performance evaluation”, International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery, 2014.

109

8 APÊNDICES

110

8.1 APÊNDICE 1 – ROTEIRO DE TESTES DA APLICAÇÃO

1º) Acessar ao sistema URL (área pública): http://<DOMINIO_CLIENTE>:8000/ URL (área privada): http://<DOMINIO_CLIENTE>:8000/admin/login/ Login (default): [email protected] Senha (default): [email protected] 2º) Iniciar o PDA Ao acessar o ODM, a página principal é o dashboard. Como ainda não existe um PDA criado, nesta tela irá mostrar uma mensagem informando a necessidade de criar algumas configurações iniciais. Para criar essas configurações, basta clicar no botão “Clique aqui para iniciar o seu Plano de Dados Aberto”.

3º) Cadastrar de área dos responsáveis do Grupo de Trabalho URL: http://<DOMINIO_CLIENTE>:8000/admin/pda/areagrupotrabalho/ Menu: Grupo de Trabalho > Área Ao acessar a página, clique no botão “Adicionar Área – Grupo de Trabalho” e preencher o(s) campo(s): - Descrição: <campo texto> Este campo informa a área de atuação dentro do órgão dos responsáveis pelo PDA. 4º) Cadastrar o Grupo de Trabalho URL: http://<DOMINIO_CLIENTE>:8000/admin/pda/grupotrabalho/ Menu: Grupo de Trabalho > Grupo de Trabalho Ao acessar esta página, basta clicar no botão “Adicionar grupo trabalho” e preenche os campos: Formulário 1 (Grupo de Trablho) - Descrição: <campo texto> - Situação: <campo selecionável> (OBS: deixe marcado a opção “Em Execução”) Formulário 2 (Responsáveis) (duplicável) - Nome: <campo texto> - E-mail: <campo texto> - Área: <campo de seleção> - Usuário?: <campo checkbox> (OBS: ao marcar esta opção, o responsável pelo PDA será incluído como usuário do sistema e poderá acessar o ODM)

mailto:[email protected]

mailto:[email protected]

111

Concluído todos esses passos, as tarefas que foram cadastradas automaticamente pelo sistema e que são relacionadas ao grupo de trabalho serão concluídas também automaticamente. 5º) Cadastrar Provedor de Dados URL: http://<DOMINIO_CLIENTE>:8000/admin/pda/provedordados/ Menu: Provedor de Dados > Provedores Ao acessar esta página, basta clicar no botão “Adicionar Provedor de Dados” e preencher os seguintes campos: Formulário 1 (Provedor de Dados) - Nome: <campo texto> - Sigla: <campo texto> - Ativo: <campo checkbox> Formulário 2 (Configurações de Acesso) (duplicável) - Tipo de Acesso: <campo selecionável com duas opções disponíveis> Database - neste caso, é necessário preencher os seguintes campos: - SGBD: <campo selecionável com as opções: mysql, postgresql e sqlite> - Host: <campo texto> - User: <campo texto> - Password: <campo texto> - Port: <campo numérico> - Database: <campo texto> - Schema: <campo texto> Service – neste caso, é necessário preencher os seguintes campos: - URL: <campo texto> Ao cadastrar o provedor de dados com a configuração de acesso, é possível testar a configuração clicando no ícone de visualizar dados ( ) na listagem de provedores de dados.

6º) Cadastrar Dados Sigilosos URL: http://<DOMINIO_CLIENTE>:8000/admin/pda/dadosigiloso/ Menu: Provedor de Dados > Dados Sigilosos Ao acessar está página, basta clicar no botão “Adicionar Dado Sigiloso” e preencher os seguntes campos:

112

- Provedor: <campo selecionável> - Campo sigiloso: <campo texto> - Omitir?: <campo checkbox> - Mascarar?: <campo checkbox> Essas informações serão passadas a qualquer software de extração para que sejam tratadas. 7º) Cadastrar Inventário URL: http://<DOMINIO_CLIENTE>:8000/admin/pda/inventario/ Menu: Provedor de Dados > Inventário Ao acessar essa página, basta clicar no botão “Adicionar Inventário” e preencher os seguintes campos: - Provedor: <campo selecionável> - Nome da Base de Dados: <campo texto> - Slug: <campo texto> - Descrição: <campo texto não obrigatório> - Unidade Responsável: <campo texto não obrigatório> (geralmente, o setor do órgão) - Área Institucional: <campo texto> - Periodicidade de Atualização: <campo selecionável> - Relacionada: <campo selecionável> (OBS: deixe marcado com a opção “não”) 8º) Selecionar Dados URL: http://<DOMINIO_CLIENTE>:8000/admin/pda/inventario/ Menu: Provedor de Dados > Inventário Depois de cadastrar as informações o inventário de dados, é necessário selecionar as informações que irão compor o inventário. Para isso, encontre o registro de inventário que você deseja selecionar os dados. Ex.:

Clicando no botão “Selecionar Dados” você será direcionado ao formulário para popular o inventário. Para isso, selecione as informações: - Provedor de Dados: <campo selecionável> - Tipo de Conexão: <campo selecionável> - Tabelas: <campo selecionável> (OBS: selecione a tabela responsável pelo conjunto de dados do inventário. No nosso exemplo, a nossa base tem o nome de “Servidores do INFR”, logo, irei selecionar a tabela que corresponda a esse nome.) - Colunas: <campo selecionável> (OBS: selecione apenas os campos que serão abertos ao público, dando preferência a campos com informações úteis) 9º) Cadastrar Consulta Pública URL: http://<DOMINIO_CLIENTE>:8000/admin/pda/consultapublica/

113

Menu: Consulta Pública > Consulta Ao acessar essa página, basta clicar no botão “Adicionar Consulta Pública” e preencher os seguintes campos: Formulário 1 – Consulta Pública - Data de Início da Consulta: <campo data e hora> - Data de Fim da Consulta: <campo data e hora> Formulário 2 – Resultado da Consulta Pública (duplicável) - Base: <campo selecionável> (OBS: selecione as bases que serão colocadas para consulta pública) IMPORTANTE: A progressão do PDA só irá ser retomada quando a data fim da consulta pública for atingida. Até lá, as bases selecionadas deverão estar disponíveis na área pública para que os cidadãos possam votá-las. Essa votação será um termômetro para o próximo passo, que é a priorização das bases. 10º) Avaliar Bases URL: http://<DOMINIO_CLIENTE>:8000/pda/priorizacaobases/ Menu: Matriz de Priorização > Avaliar Bases Ao acessar essa página, você deverá atribuir um valor para cada critério de cada base disponível. Ex.: Para uma base “Base XYZ” e critério “Critério ABC” você deverá atribuir um valor que varia de 0 a 3: 0 – Não se aplica 1 – Baixo 2 – Médio 3 – Alto Este formulário simula a matriz de priorização disponível no manual da CGU. Essa priorização é importante, pois será com base nela que iremos empreender esforços nas principais bases. 11º) Relacionar bases finais URL: http://<DOMINIO_CLIENTE>:8000/admin/pda/inventario/ Menu: Provedor de Dados > Inventário Ao acessar essa página você vai encontrar todos os inventários de base de dados do provedor. Nesta lista, você pode marcar o checkbox do lado esquerdo da lista e selecionar a ação “Relacionar Base para PDA” e clicar no botão “Ir”.

114

Ao realizar esta ação, toda as bases que foram marcadas no checkbox deverão estar com a coluna “Relacionar” com um ícone verde ( ) indicando que a base está relacionada para o PDA vigente. 12º) Cadastrar Plano de Ação URL: http://<DOMINIO_CLIENTE>:8000/admin/pda/planoacao/ Menu: Plano de Ação > Plano de Ação Ao acessar essa página, basta clicar no botão “Adicionar Plano de Ação” e preencher os seguintes campos: Formulário 1 – Inventário - Inventário: <campo selecionável> - Descrição Detalhada: <campo texto> - Meta/Prazo: <campo data> - Concluído <campo checkbox> Formulário 2 – Atividades do Plano de Ação (duplicável) - Descrição: <campo texto> - Prazo: <campo data> Formulário 3 – Produtos do Plano de Ação (duplicável) - Descrição: <campo texto> IMPORTANTE: Todas as atividades dos planos de ações serão monitoráveis pelo ODM através do dashboard da aplicação. Todo o plano de ação ficará disponível no PDA, portanto, é importante que ele tenha seus campos bem descritos. 13º) Cadastrar o PDA Menu: PDA Ao acessar o menu PDA, o usuário irá encontrar todos os tópicos que formam a estrutura formal de um Plano de Dados Abertos (PDA). São eles: - Capa: apresenta um campo de texto rico, onde o usuário poderá confeccionar a capa do PDA. Também existe um campo de upload de imagem, onde o usuário pode fazer a arte em uma imagem e realizar o upload apenas;

- Cabeçalho e Rodapé: formulário com dois campos de texto rico para confecção do cabeçalho e rodapé do PDA;

- Apresentação: campo de texto rico para digitação do texto relacionado a apresentação.

- Introdução: campo de texto rico para digitação do texto relacionado a introdução.

- Cenário Institucional: campo de texto rico para digitação do texto relacionado ao cenário institucional.

- Objetivos (Gerais e Específicos): campo de texto rico para digitação do texto relacionado aos objetivos.

115

- Dados para Abertura: campo de texto rico para digitação do texto relacionado a dados para abertura.

- Estratégia de Abertura: campo de texto rico para digitação do texto relacionado a estratégia de abertura.

- Catalogação: campo de texto rico para digitação do texto relacionado a catalogação.

- Sustentação: campo de texto rico para digitação do texto relacionado a sustentação.

- Monitoramento: campo de texto rico para digitação do texto relacionado a monitoramento.

- Plano de Ação: campo de texto rico para digitação do texto relacionado ao plano de ação.

- Referências: campo de texto rico para digitação do texto relacionado a referências.

- Glossário: campo de texto rico para digitação do texto relacionado ao glossário.

IMPORTANTE: Ao gerar o PDA, se for detectado que algum tópico não foi preenchido, este será omitido do documento.

13º) Finalizar o PDA URL: http://<DOMINIO_CLIENTE>:8000/admin/pda/pda/ Menu: PDA > Geral Ao acessar essa página, basta o usuário localizar o botão “Finalizar” e clicar para que o PDA possa ser finalizado. Caso o botão “Finalizar” esteja desabilitado, é porque ainda existe tarefas a serem concluídas no dashboard. Ao finalizar o PDA, o dashboard irá mudar, mostrando alguns gráficos e desaparecendo a parte de progressão do PDA. A partir deste momento, o PDA está criado e disponível na área pública da aplicação, tanto em arquivo PDF quanto em HTML.

116

8.2 APÊNDICE 2 – EXEMPLOS DE PDAS RECRIADOS A PARTIR DO

OPENDATA MANAGER

PDA do IFRN

PDA do IBAMA

117

PDA do Ministério do Meio Ambiente

PDA do TRT da 18ª Região

OpenData Manager: Uma ferramenta para gerenciar o processo ...

Documents

Transcript of OpenData Manager: Uma ferramenta para gerenciar o processo ...