Projeto Setorial - 10. Gestão da criação, armazenamento e acesso a informações sobre objetivos dos normativos de aeronavegabilidade

--- title: Projeto Setorial - 10. Gestão da criação, armazenamento e acesso a informações sobre objetivos dos normativos de aeronavegabilidade description: 00058.029038/2020-51 (SEI) authors: Gabriel Santiago Macedo; Rafael Ximenes Borges; Daniel Dias da Silva tags: 2021; ANAC; SAR; GTNI; Projeto setorial; Regulamentação; Interpretação; Processo normativo lang: pt-br --- # Projeto Setorial 10 - Gestão da criação, armazenamento e acesso a informações sobre objetivos dos normativos de aeronavegabilidade ###### tags: `2021` `ANAC` `SAR` `GTNI` `Projeto setorial` `Regulamentação` `Interpretação` `Processo normativo` [TOC] ## 1. ASSUNTO Relatório de conclusão de estudo: **Projeto Setorial 10 - Gestão da criação, armazenamento e acesso a informações sobre objetivos dos normativos de aeronavegabilidade**. ## 2. REFERÊNCIAS * 2.1 Processo de Coordenação da Gerência Técnica de Planejamento - GTPL: 00058.034091/2020-73. * 2.2 Portfólio de projetos SAR - 2020 (Projeto 12) e 2021 (Projeto 10). * 2.3 Projeto de Reestruturação da Gestão do Conhecimento na SAR - Portfólio de projetos SAR - 2020 (Projeto 8). ## 3. PROPOSTA DE ESTUDO ### 3.1 Resumo Com o intuito de aprimorar a atuação da Superintendência de Aeronavegabilidade - SAR foram identificados projetos setoriais entre suas áreas meio e finalísticas. Dentre os projetos escolhidos para o biênio 2020/2021 tem-se o Projeto em epígrafe, iniciado em 13.08.2020. Este projeto foi idealizado pela Gerência Técnica de Normas e Inovação - GTNI, visando impactar positivamente toda a SAR, principalmente no que concerne à facilitação do processo interpretativo da regulação da aeronavegabilidade, ou seja, as regras sob a competência da superintendência relacionadas a: regulamentação, fiscalização, verificação do cumprimento de requisitos e aplicação de sanções em primeira instância. Como estratégia de ação o projeto foi iniciado por uma etapa de tomada de subsídios junto a servidores e gestores da SAR, proporcionando ampliar e confirmar a percepção dos problemas existentes e, consequentemente, as possibilidades de melhorias. O resultado alcançado pelo estudo recomenda a aplicação de um conjunto de soluções, divididas entre: melhorias de processos, criação de novas rotinas de gestão de informações e adoção de ferramentas de Tecnologia de Informação - TI. Com a etapa de validação deste relatório, considerando a apreciação e análise pela superintendência, pretende-se confirmar as seguintes ações: * internalização das melhorias propostas; * atualização do cronograma e recursos referentes às próximas etapas do projeto; * disseminação das ações aos servidores e agentes impactados. ### 3.2 Fato gerador da demanda Ao longo dos últimos anos foi percebido que as áreas envolvidas no processo normativo da SAR realizam recorrentes pedidos à GTNI para auxílio no desenvolvimento de interpretações relacionadas ao macroprocesso de regulamentação, com impactos em diferentes atividades e processos da SAR. Tal situação leva a uma dependência de servidores treinados para localizar as informações. Na maioria das vezes esse trabalho de consulta envolve a localização de dados distribuídos em bases não integradas (silos) pela ANAC, seja contendo regulamentação própria ou de outras autoridades. Ainda, além das informações específicas capturadas em processos normativos, vale notar que há uma extensa cadeia de geração de conhecimentos dentro dos processos da SAR. Estes conteúdos, por sua vez, nem sempre foram mapeados, explicitados e disponibilizados para recuperação, visando enriquecer pesquisas no contexto do processo interpretativo. Outro ponto importante é que também é destacada a necessidade de alcance de fontes externas de informação, uma vez que a construção de entendimentos depende do conhecimento da prática internacional, o que inclui material desenvolvido por outras autoridades de aviação civil, associações e a própria Organização de Aviação Civil Internacional - OACI. Também há o entendimento de que o conhecimento em aeronavegabilidade não é exclusivo dos integrantes da SAR ou da ANAC, mas se encontra difundido de maneira significativa entre entes regulados, a comunidade científica e sobretudo, entre servidores já aposentados. Diante deste cenário a GTNI identificou oportunidade de melhoria ligada à facilitação do processo de interpretação de requisitos, a qual foi indicada e posteriormente selecionada para compor o portfólio de projetos setoriais da SAR para o biênio de 2020/2021, identificado como *Projeto Setorial 10*. ### 3.3 Grupo de Trabalho - GT Em virtude da restruturação da ANAC em 16/10/2020, o escopo do projeto, que inicialmente abrangia tanto atividades de certificação de produto quanto relacionadas com a aeronavegabilidade continuada, foi reduzido para conter apenas as áreas mantidas dentro do contexto de atuação da SAR, focada em Fabricantes Aeronáuticos e no Registro Aeronáutico Brasileiro - RAB. Quanto aos servidores envolvidos, o estudo contou com a participação de: 1. Daniel Dias da Silva - Gerência Técnica de Engenharia (GTEN); 2. Gabriel Santiago Macedo - Gerência Técnica de Planejamento (GTPL); 3. Rafael Ximenes Borges – Gerência Técnica de Normas e Inovação (GTNI); e 4. Marco Aurélio Bonilauri Santin (patrocinador) - Gestor da Gerência Técnica de Normas e Inovação (GTNI); 5. Seth Emanuel Couto Melo Filho – Gerência de Certificação e Vigilância Continuada (GCVC), atualmente na Superintendência de Padrões Operacionais (SPO). A coordenação do projeto foi assumida pelo servidor Rafael Ximenes Borges (GTNI), tendo como substituto o servidor Gabriel Santiago Macedo (GTPL) e patrocinador o Gerente Marco Aurélio Bonilauri Santin (GTNI). O GT dispensa um especial agradecimento ao servidor Seth Emanuel Couto Melo Filho, por sua colaboração e atuação no grupo até o momento da restruturação da ANAC, migrando na sequência para a SPO e passando a acompanhar os trabalhos como _Observador_. ### 3.4 Metodologia A estratégia de desenvolvimento do estudo proposto se dividiu em 6 etapas, listadas a seguir: 1. Tomada de subsídios por meio de questionários e entrevistas junto a servidores e gestores da SAR; 2. Estruturação de problema por meio de árvore de problemas; 3. Definição de relação de objetivos de decisão para suporte ao processo decisório voltado para a escolha de alternativas de solução; 4. Ideação e desenvolvimento de alternativas por meio de levantamento de boas práticas de gestão de informação, em termos de ferramentas utilizadas por outros órgãos, assim como, soluções de TI disponibilizadas em fóruns especializados; 5. Seleção e discussão de alternativas a serem apreciadas pela SAR; e 6. Registro do resultado do estudo em formato de relatório. ## 4. DETALHAMENTO DO ESTUDO REALIZADO ### 4.1 Etapa 1 - Tomada de subsídios #### 4.1.1 Pesquisa com servidores da SAR Por meio da plataforma de pesquisa Limesurvey foi disponibilizado questionário aos servidores da SAR com o intuito de confirmar o problema a ser tratado, identificar boas práticas já em uso, isoladamente em cada setor da SAR, e de colher sugestões de possíveis alternativas de melhoria. As questões foram separadas entre dois públicos-alvo. O primeiro para servidores sem atribuição de liderança e o segundo para gestores e pessoas-chave de áreas técnicas que foram selecionadas considerando a atuação direta na disseminação de informações de aeronavegabilidade. A Lista 01, abaixo, apresenta as perguntas feitas aos participantes da pesquisa. **Lista 01 - Relação de perguntas da pesquisa para tomada de subsídios.** **Geral** 1. Qual é o seu nome? 2. Qual é seu grupo na SAR? 3. Você possui função de liderança ou coordenação em seu grupo? **Grupo 1 - Gestores e pessoas-chave** 1. Em seu grupo de trabalho, quais iniciativas são utilizadas para a geração ou explicitação de conhecimento sobre interpretação de requisitos? 2. Há informações explicitadas em seu grupo, relacionadas com interpretação de requisitos, sensíveis e que precisam ter seu acesso restringido? 3. Quais canais são utilizados por seu grupo para explicitação de informações ligadas a interpretações de requisitos de aeronavegabilidade? 4. Considerando todas as modalidades de informação ligada a interpretações de requisitos desenvolvidas pelo seu grupo, para quem a informação já tem sido disponibilizada? 5. Para as informações geradas por seu grupo, relacionadas com interpretações de requisitos de aeronavegabilidade, em que situações é necessário envolver outro grupo e quais grupos normalmente são envolvidos? Indique os grupos. 6. Quais as principais fontes de dados para a identificação e geração de conhecimento ligada a interpretação de requisito? Cite o nome ou endereço eletrônico para acesso, se aplicável. 7. Você poderia descrever resumidamente as atividades do processo de geração e explicitação de conhecimento relativo a interpretações de requisitos desenvolvidas por seu grupo? 8. Quais as principais fontes de dados para a identificação e geração de conhecimento ligada a interpretação de requisito? Cite o nome ou endereço eletrônico para acesso, se aplicável. 9. Você poderia descrever resumidamente as atividades do processo de geração e explicitação de conhecimento relativo a interpretações de requisitos desenvolvidas por seu grupo? 10. As respostas elaboradas pelo seu grupo sobre interpretação de requisitos são mantidas em alguma base de dados? 11. Vocês possuem ou estão desenvolvendo alguma solução de TI para geração ou explicitação de conhecimento ligado à interpretação de requisitos? E se já estiver em uso, onde está disponibilizada (indique o link se aplicável)? 12. Em seu grupo, quais as principais dificuldades enfrentadas pelos envolvidos com o processo de disponibilização de conhecimento relativo à interpretação de requisitos de aeronavegabilidade? **Grupo 2 – Servidores** 1. Gostaríamos de saber se já utilizou algum canal da ANAC para sanar dúvidas quanto a interpretações de requisitos? Se sim, qual? 2. Gostaríamos de saber se você já utilizou algum canal para pesquisar interpretação de requisitos externo à ANAC? Se sim, qual? 3. Caso aplicável, quais dificuldades foram percebidas durante sua pesquisa sobre a interpretação de requisitos? 4. Já pensou em alguma solução que poderia ser adotada pela SAR para facilitar o acesso aos objetivos dos requisitos? Caso queira compartilhar conosco, poderia comentá-la? 5. Você considera oportuno abrir um canal de discussão de interpretações que envolva o público externo? Justifique sua resposta. #### 4.1.2 Entrevista com gestores e pessoas-chave da SAR Em complemento ao questionário, o GT se reuniu com os gestores e com as pessoas-chave da SAR, tomando por base as perguntas trabalhadas no Limesurvey (Grupo 1) e complementadas durante o processo de entrevista semiestruturada. A íntegra das anotações das entrevistas está contida no Documento SEI 5490936, uma vez que foram registradas pelos entrevistadores usando a mesma ferramenta. #### 4.1.3 Achados em destaque na pesquisa Como resultado - considerando o contexto no qual esse trabalho está inserido - é importante destacar alguns achados, descritos a seguir, de forma sintetizada. Tal didática visa facilitar a leitura e o entendimento dos demais colegas integrantes da SAR. Assim, informa-se que algumas respostas foram selecionadas, agrupadas e comentadas pela equipe, com esforço para não perder a ligação com os dados originais. A pesquisa na íntegra pode ser consultada por meio dos Documentos SEI 5490936 (Parte 1) e SEI 5490995 (Parte 2), sendo útil para confirmar as causas trabalhadas durante o projeto e as propostas sugeridas. Nota: A relação entre as perguntas e as respostas sintetizadas aqui pode ser identificada por meio dos códigos do questionário apresentados entre '[ ]'. ##### 4.1.3.1 Síntese das Respostas do Diagnóstico - Parte 01 (SEI 5490936) ###### Maior participação entre gerências [g1q02] - GCEN e GTAR (44% - 21 de 47 respondentes) ###### Proporção de participantes em relação à ocupação de cargos de liderança [g1q03] - Gerentes (7 participantes), Líderes de área (8 participantes), Servidores sem função de liderança direta (30 participantes) ###### Meios de explicitação (criação) de conhecimento [g1q01] | Resposta | Contagem | Percentagem | |--- | --- | --- | | Resposta a dúvidas de regulados (SQ004) | 10 | 71.43% | | Processos de elaboração ou revisão de normativos (IS, MPR, ITD, Policy File, Condição Especial, ELOS, DA, isenções). (SQ005) | 9 | 64.29% | | Resposta a dúvidas de servidores (SQ006) | 8 | 57.14% | | Guia complementar (SQ002) | 7 | 50.00% | | Outros documentos de orientação aos servidores e aos regulados | 7 | 50% | > Comentários: outros documentos com destaque para FCAR, BEA e respostas via SEAM. ###### Informações explicitadas que precisam de restrição [g1q05] Exemplos: - Monitoramento de credenciados e interpretação de requisitos - Respostas individuais aos regulados - Compêndio de Elementos de Fiscalização (CEF) - FCAR e CAI em razão de poder expor vantagens competitivas > Comentários: presença de _policy files_ como **documento que pode ser aberto**, como são a TAIL e SAIL (_issues lists_ da FAA). ###### Canais para repasse de informações [g1p07] | Resposta | Contagem | Percentagem | | --- | --- | --- | | E-mail. (SQ006) | 12 | 92.31% | | Intranet SAR. (SQ001) | 8 | 61.54% | | Site da ANAC. (SQ002) | 8 | 61.54% | | Outros | 7 | 53.85% | > Comentários: outros canais com destaque para ofícios no SEI, telefone e intranet. ###### Fontes para geração de conhecimento sobre interpretação de requisitos [g1q11] - FSIMS (FAA) - AC (FAA) - Order (FAA) - Normativos (FAA) - NPRM (FAA) - Notice (FAA) - STCS validados (FAA) - TAIL (FAA) - SAIL (FAA) - RGL (FAA) - faa.gov regulations (FAA) - AMC (EASA) - Acordo bilateral (FAA) - Normativos (EASA) - Normas ASTM - Concensus standards - Discussões no âmbito do CATA - Normativos, manuais e formulários (SRVSOP) - Orientações internas já emitidas (e-mails antigos, processos e boletins internos) - RBAC - IS - Procuradoria na ANAC quando há discussão interna à agência - Fóruns da indústria - Normas e padrões da indústria - Grupos ICAO - Pesquisas científicas - FCAR (ANAC) > Comentários: em casos concretos documentos como as IS não têm sido suficientes. Materiais da FAA são utilizados em primeiro lugar e da EASA em segundo. Sugestão de catalogação de teses acadêmicas. ###### Onde localizar informações sobre interpretação de requisitos [g1q13] > Comentários: cinco respondentes indicaram que as informações sobre interpretação de requisitos não estão em nenhuma base de dados. Outras respostas indicam a presença de dados em documentos do SEI, processos físicos (que podem ser digitalizados), pastas de e-mail, site da ANAC, Intranet SAR, Sharepoint e WikiANAC. No caso de CAI e FCAR estão em projetos de certificação e são controladas pelos coordenadores. ###### Presença de solução de TI para geração ou explicitação de conhecimento ligado à interpretação de requisitos [g1q17] - Boletins informativos - Banco de _policy_ - Intranet - Carta de serviços - Sharepoint > Comentários: diversos comentários indicam a ausência de ferramenta e direcionamento para produção de conteúdo com essa característica. Destaque ainda para sinalização da necessidade de indexação de conteúdo usando taxonomias ou palavras-chave. ###### Principais dificuldades com o processo de disponibilização de conhecimento relativo à interpretação de requisitos de aeronavegabilidade [g1q19] - Ausência de compilação de respostas já elaboradas - Retrabalho com respostas a questionamentos similares - Pacificação de decisões interpretativas - Ausência de sistemática para publicação - Cultura para estimular a gestão do conhecimento - Intepretações em processos de vigilância não registradas em bases internas > Comentários: identificação de problemas relacionados ao resgate de informações já disponibilizadas no site da ANAC, SEI e Boletins Internos. Informação de que carga de trabalho não permite a realização dessa tratativa. Comum o aproveitamento de materiais de outras autoridades, ao invés de produção "do zero". #### Síntese das Respostas do Diagnóstico - parte 02 (SEI 5490995) ###### Utilização anterior de canais da ANAC para sanar dúvidas sobre interpretação de requisitos [g01q20n] | Resposta | Contagem | Percentagem | |---------------------------------------------------------------|----------|-------------| | Consulta a colega da ANAC (SQ010) | 27 | 90.00% | | Banco de IS e MPR (SQ005) | 18 | 60.00% | | Banco de interpretações na intranet SAR (SQ004) | 16 | 53.33% | | Consulta à GTPN (SQ009) | 11 | 36.67% | | Consulta a material disponível na biblioteca da ANAC. (SQ011) | 10 | 33.33% | | Página temática no site ANAC (SQ002) | 7 | 23.33% | | Processo normativo no SEI. (SQ006) | 6 | 20.00% | | Sharepoint setorial (SQ003) | 5 | 16.67% | | Outros | 3 | 10.00% | | WikiANAC (SQ001) | 1 | 3.33% | | Processo normativo no Sigad. (SQ007) | 0 | 0.00% | | Processo normativo via processo físico. (SQ008) | 0 | 0.00% | > Comentários: ausência de utilização de sistemas antigos de gerenciamento processual, tais como SIGAD e os próprios processos físicos. Destaque ainda para a troca de informações entre os próprios servidores como prática comum. No campo “outros” apareceram: GCVC coordenação, AC do FAA no RGL, FAA e EASA. ###### Dificuldades percebidas durante sua pesquisa sobre a interpretação de requisitos [g1q24] | Resposta | Contagem | Percentagem | |-----------------------------------------------------------------------------------------------------------------------------------------------------|----------|-------------| | Não há detalhamento exaustivo para todo requisito existente. (SQ003) | 19 | 65.52% | | Não está explicitada a relação existente entre os vários normativos sob a competência da SAR (cadeia de requisitos e meios de cumprimento). (SQ004) | 17 | 58.62% | | Informação não centralizada. (SQ001) | 15 | 51.72% | | Falta de padronização da informação. (SQ005) | 12 | 41.38% | | Pesquisa não é intuitiva, exigindo treinamento ou consulta a servidor treinado. (SQ002) | 11 | 37.93% | | Outros | 5 | 17.24% | > Comentários: dificuldades sobre detalhamento de informações, rastreabilidade e buscas. No campo "outros" apareceram: > >> "Falta histórico dos requisitos; Identificar fontes confiáveis ou oficiais; Falta de definições claras de tipos aeronaves e operações que aparecem nos RBACs; Nenhuma autoridade tem isso muito organizado. O FAA tem uma tentativa disso na parte do 25 (tabela requisito - policy - ac) mas ainda é meio simples demais; Eu nunca soube exatamente ONDE pesquisar para descobrir qual a interpretação oficial da ANAC sobre algum requisito que seja polêmico ou duvidoso." ###### Contribuições sobre o que poderia ser adotado pela SAR para facilitar o acesso aos objetivos dos requisitos [g1q25] - Padronização de informações - Centralização de todas as emendas dos documentos normativos e interpretativos - Clara definição de objetivos e riscos dos processos e projetos - Associação entre documentos, exemplo: RBAC e _policys_ - Link de requisitos direto para IS ou banco de interpretações - Envolver as pessoas nos processos de mudança (inovação) via workshop interno - Atualização e revisão ampla para eliminar conflitos - Banco de dados relacionando diversos regulamentos, materiais de orientação, discussões sobre nível equivalente de segurança, meios alternativos de cumprimento, regulamentação de outros países e da ICAO - Documentar resultados de discussões para consultas futuras - Buscar interpretação nos documentos de outras autoridades (*estratégia de corregulação*), evitando fugir das práticas e padrões já recomendados por estes - Criação de conteúdo na web similar ao [Transport Standards Branch Lists of Part 25/26 Rules and Their Associated Advisory Circulars and Policy Statements](https://www.faa.gov/aircraft/air_cert/design_approvals/transport/rules_acs_policy) - Reforço de pessoal na GTNI em função do esforço de revisão de normativos e procedimentos - Histórico online de documentos da ANAC como vistos no RGL (FAA) - Rede de requisitos como protótipo desenvolvido no kumu.io, partindo da tabela da FAA - Banco de interpretações com disponibilização de exemplos - E-mail corporativo interno para dúvidas sobre requisitos, considerando respostas oficiais; não uma interpretação particular de gerente ou coordenador - Unificação de bases de dados e sistemas, de modo que as informações estivessem sempre atualizadas e sem necessidade de replicação #### 4.1.4 - Discussão do resultado da pesquisa Com base nas manifestações colhidas foi possível levantar pontos importantes para a confirmação de problemas existentes, causas percebidas e consequências indesejáveis, notadas pelo público consultado. A entrevista com gestores permitiu complementação ao que foi levantado por meio da pesquisa aplicada por questionário eletrônico, com detalhes importantes relativos aos processos já existentes na SAR, que poderão ter interface com soluções a serem consideradas neste projeto. Como resultado, a seguir tem-se a análise do problema de decisão. ### 4.2 Etapa 2 - Estruturação do problema de decisão A análise do problema foi feita com base nos seguintes passos: 1. Desenho de árvore de problemas com base em *Brainstorming* inicial feito em 2 momentos, discussão interna à GTNI e complementação + validação pelo Grupo de Trabalho - GT; 2. Complementação adicional da árvore de problemas com base em processo de tomada de subsídios junto a servidores, pessoas chave e gestores da SAR; e 3. Rediscussão de estrutura de problemas pelo GT com separação de causas pertinentes ao escopo do projeto 10. A árvore de problemas pode ser visualizada por meio do Documento SEI 5491169. Ela divide o diagnóstico em ***problema central***, ***consequências*** e ***causas***, apresentadas a seguir: 1. **Problema central**: i. Percepção de dúvidas (internas e externas) recorrentes sobre motivação de requisitos de aeronavegabilidade que são da competência da SAR. 2. **Consequências (3 grupos)**: i. Casos em que processos normativos não sejam detalhados suficientemente geram dependência de estudo de material de referência (ex. FAA). ii. Ações regulatórias têm sua produtividade prejudicada por falta de acesso rápido à motivação de normativos. iii. Risco de não ser aproveitada experiência anterior com a norma. 3. **Causas (6 grupos)**: i. Processo de registro de interpretações não é focado, de maneira efetiva, em facilitar pesquisa interpretativa. ii. As informações estão em bases de dados diversas (ex.: SIGAD, SEI, rgl.faa.gov, federal register etc.). iii. Não se consegue aproveitar metódica e rapidamente o histórico de motivações e interpretações anteriores. iv. Consulta a motivação de requisitos não dá abertura para aproveitamento de conhecimento de público externo. v. Não há IS para todos os requisitos sob competência da SAR. vi. SAR não tem fácil acesso a teses acadêmicas que poderiam contribuir em análises técnicas. Diante das causas identificadas o grupo selecionou as que estariam no escopo de atuação do *projeto 10*, visto que a intenção seria de apresentar soluções que facilitassem a conexão e disponibilização de informações já existentes, sem entrar no mérito de exigir melhorias pontuais em processos já em curso. O critério adotado para tratamento das causas identificadas também ponderou o uso de abordagens que não impusessem a reformulação imediata dos processos em curso ou o retrabalho sobre processos já concluídos. No Documento SEI 5491169, ***Árvore de Problemas***, são apresentados os agrupamentos das causas selecionadas e descartadas durante o projeto. #### 4.2.1 Causas selecionadas para direcionamento da escolha de alternativas Destaca-se que a relação de causas tratáveis foi organizada em 5 frentes de trabalho de forma a facilitar a identificação de alternativas. Com isso, optou-se por reagrupar as causas por: 1. mecanismo de busca indexada de informações já explicitadas; 2. integração de base de dados; 3. registro de discussões feitas fora de formalização processual; 4. canal de discussão com público externo; e 5. mapeamento de conexão de normativos. O Documento SEI 5491217 expõe o resultado da análise do grupo a respeito da reorganização das causas tratáveis. Com tal dinâmica foi possível notar que eventuais soluções poderiam ser desenvolvidas por meio de conjuntos de soluções de TI com tratamento de informações a serem aproveitadas. Após a constatação inicial de causas tratáveis, partiu-se para a identificação de dados e informações relacionadas com o processo interpretativo na SAR, conforme tratado na seção 4.2.2. #### 4.2.2 Fontes de informação e boas práticas para a gestão de dados na web O Quadro 01 indica as fontes de dados e informações identificadas por meio do processo de tomada de subsídios, que poderão ser interligadas/aproveitadas no intuito de facilitar a busca por registros aproveitáveis no processo de interpretação de requisitos. ***Quadro 01 – Fontes de dados e informações da SAR úteis ao processo interpretativo.*** ![01 – Fontes de dados e informações da SAR úteis ao processo interpretativo](https://i.imgur.com/2PPcRRR.png) No que tange as boas práticas de gestão de dados na web, como já mencionado inicialmente a intenção deste projeto é aproveitar a estruturação de dados já existente na SAR na aplicação do esforço de facilitação pretendido, todavia com um foco em boas práticas de gestão de dados é possível apontar desafios rumo a um cenário evolutivo. Para aproveitamento dos dados existentes, o ideal seria redesenhar o processo do fluxo de dados na SAR. Compreender, em primeiro lugar, como as informações são geradas, capturadas e como elas fluem pelo processo normativo, de modo a identificar os meios apropriados para a sua retenção e recuperação futura. Assim, a **atuação sobre a proveniência e a governança de dados é ponto central**, demandando um aprofundamento sobre modelos para gestão de dados na web, suas boas práticas e a aderência aos princípios de interoperabilidade. É importante destacar que atualmente os dados relacionados ao processo normativo da ANAC são divulgados com transparência, no entanto os conjuntos de dados são disponibilizados em formatos de dados de difícil reutilização, tais como documentos em PDF das publicações, planilhas em Excel geradas dentro dos processos do SEI! ou ainda informações em bases de dados de sistemas que não trocam dados entre si (SEAM, Pergamum e outros), ou seja, não são interoperáveis. Em um cenário de melhoria, foram identificados *temas* importantes a serem considerados, apontados abaixo: * Governança de dados[^DataUseRequirements] * Boas práticas para Dados na WEB[^DataBestPractices] * Dados Conectados (*linked data*)[^LinkedData] * Web Semântica[^W3CSW] * Grafos de Conhecimento (*knowledge graphs*)[^KnowledgeGraph][^Fensel][^CS520] * Princípios FAIR[^GoFAIR] [^DataUseRequirements]: Data on the Web Best Practices Use Cases & Requirements. W3C Working Group Note 24, 2015. Disponível em: https://www.w3.org/TR/dwbp-ucr/. Acesso em: 23/03/2021. [^DataBestPractices]: Boas Práticas para Dados na Web. Recomendação do W3C, 2017. Disponível em: https://w3c.br/traducoes/DWBP-pt-br/. Acesso em: 22/03/2021. [^W3CSW]: W3C Web Semântica. Disponível em: https://www.w3c.br/Padroes/WebSemantica. Acesso em: 22/03/2021. [^KnowledgeGraph]: Open Knowledge Graph. Mindlab, 2020. Disponível em: https://drive.google.com/file/d/1A5fTMUrHw-z8Z1JMbTVb-7egYl7ipdAB/view. Acesso em: 22/03/2021. [^Fensel]: Knowledge Graphs. Fensel et al., 2020. Disponível em: https://10.1007/978-3-030-37439-6. Acesso em: 22/03/2021. [^CS520]: How to Create a Knowledge Graph? Organizers: Vinay K. Chaudhri; Naren Chittar; Michael Genesereth. Department of Computer Science, Stanford University, 2020. Disponível em: https://web.stanford.edu/~vinayc/kg/notes/How_To_Create_A_Knowledge_Graph.html. Acesso em: 22/03/2021. A Lista 02 a seguir apresenta alguns dos desafios enfrentados quanto a publicação e ao consumo de dados na Web relacionados às suas boas práticas, sendo útil para orientar as ações a serem tomadas sobre a governança e o gerenciamento dos dados da superintendência. **Lista 02 - Desafios de Dados na Web**[^DataBestPractices] > **_METADADOS - Como eu forneço medatados para pessoas & máquinas?_** > * [_Fornecer metadados_](https://w3c.br/traducoes/DWBP-pt-br/#ProvideMetadata) > * [_Fornecer metadados descritivos_](https://w3c.br/traducoes/DWBP-pt-br/#DescriptiveMetadata) > * [_Fornecer metadados estruturais_](https://w3c.br/traducoes/DWBP-pt-br/#StructuralMetadata) > **_LICENÇA DE DADOS - Como forneço & restrinjo o acesso?_** > * [_Fornecer informações sobre a licença de dados_](https://w3c.br/traducoes/DWBP-pt-br/#DataLicense) > **_PROVENIÊNCIA & QUALIDADE - Como posso aumentar a confiança?_** > * [_Fornecer informações de proveniência dos dados_](https://w3c.br/traducoes/DWBP-pt-br/#DataProvenance) > * [_Fornecer informações de qualidade dos dados_](https://w3c.br/traducoes/DWBP-pt-br/#DataQuality) > **_VERSIONAMENTO DE DADOS - Como posso rastrear versões & histórico de versões?_** > * [_Fornecer indicador de versão_](https://w3c.br/traducoes/DWBP-pt-br/#VersioningInfo) > * [_Fornecer o histórico de versão_](https://w3c.br/traducoes/DWBP-pt-br/#VersionHistory) > **_IDENTIFICADORES DE DADOS - Como posso identificar conjuntos de dados & distribuições?_** > * [_Usar URIs persistentes como identificadores de conjuntos de dados_](https://w3c.br/traducoes/DWBP-pt-br/#UniqueIdentifiers) > * [_Usar URIs persistentes como identificadores dentro de conjuntos de dados_](https://w3c.br/traducoes/DWBP-pt-br/#identifiersWithinDatasets) > * [_Atribuir URIs para as versões dos conjuntos de dados e séries_](https://w3c.br/traducoes/DWBP-pt-br/#VersionIdentifiers) > **_FORMATO DE DADOS - Quais formatos de dados devo usar?_** > * [_Usar formatos de dados padronizados e legíveis por máquinas_](https://w3c.br/traducoes/DWBP-pt-br/#dataFormats) > * [_Usar representações de dados que sejam independentes de localidade (*locale neutral*)_](https://w3c.br/traducoes/DWBP-pt-br/#LocaleParametersMetadata) > * [_Fornecer dados em vários formatos_](https://w3c.br/traducoes/DWBP-pt-br/#MultipleFormats) > **_VOCABULÁRIO DE DADOS - Como melhorar a interoperabildiade do dado?_** > * [_Reutilizar vocabulários, dando preferência aos padronizados_](https://w3c.br/traducoes/DWBP-pt-br/#ReuseVocabularies) > * [_Escolher o nível de formalização adequado_](https://w3c.br/traducoes/DWBP-pt-br/#ChooseRightFormalizationLevel) > **_ACESSO A DADOS - Como posso fornecer acesso ao dado?_** > * [_Fornecer download em massa (bulk download)_](https://w3c.br/traducoes/DWBP-pt-br/#BulkAccess) > * [_Fornecer subconjuntos para conjuntos de dados grandes_](https://w3c.br/traducoes/DWBP-pt-br/#ProvideSubsets) > * [_Usar negociação de conteúdo para servir os dados disponíveis em vários formatos_](https://w3c.br/traducoes/DWBP-pt-br/#Conneg) > * [_Fornecer acesso em tempo real_](https://w3c.br/traducoes/DWBP-pt-br/#AccessRealTime) > * [_Fornecer dados atualizados_](https://w3c.br/traducoes/DWBP-pt-br/#AccessUptoDate) > * [_Fornecer uma explicação para os dados que não estão disponíveis_](https://w3c.br/traducoes/DWBP-pt-br/#DataUnavailabilityReference) > * [_Tornar os dados disponíveis por meio de uma API_](https://w3c.br/traducoes/DWBP-pt-br/#useanAPI) > * [_Usar padrões Web como base para construção de APIs_](https://w3c.br/traducoes/DWBP-pt-br/#APIHttpVerbs) > * [_Fornecer documentação completa para as APIs_](https://w3c.br/traducoes/DWBP-pt-br/#documentYourAPI) > * [_Evitar alterações que afetem o funcionamento de sua API_](https://w3c.br/traducoes/DWBP-pt-br/#avoidBreakingChangesAPI) > **_PRESERVAÇÃO DE DADOS - Como os dados podem ser arquivados?_** > * [_Preservar identificadores_](https://w3c.br/traducoes/DWBP-pt-br/#ResourceStatus) > * [_Avaliar a cobertura do conjunto de dados_](https://w3c.br/traducoes/DWBP-pt-br/#EvaluateCoverage) > **_FEEDBACK - Como posso engajar usuários?_**_> * [_Coletar feedback dos consumidores de dados_](https://w3c.br/traducoes/DWBP-pt-br/#GatherFeedback) > * [_Compartilhar o feedback disponível_](https://w3c.br/traducoes/DWBP-pt-br/#FeedbackInformation) > **_ENRIQUECIMENTO DE DADOS - Como posso agregar valor ao dado?_** > * [_Enriquecer dados por meio da geração de novos dados_](https://w3c.br/traducoes/DWBP-pt-br/#EnrichData) > * [_Fornecer visualizações complementares_](https://w3c.br/traducoes/DWBP-pt-br/#ProvideComplementaryPresentations) > **_REPUBLICAÇÃO DE DADOS - Como posso reutilizar dados responsavelmente?_** > * [_Fornecer feedback para o publicador original_](https://w3c.br/traducoes/DWBP-pt-br/#ProvideFeedbackToPublisher) > * [_Obedecer aos termos de licença_](https://w3c.br/traducoes/DWBP-pt-br/#FollowLicensingTerms) > * [_Citar a publicação original do conjunto de dados_](https://w3c.br/traducoes/DWBP-pt-br/#CiteOriginalPublication) Em que pese a necessidade de estudo mais aprofundado dos *temas* e dos *desafios* indicados acima, há alguns princípios basilares que devem ser levados em consideração para a publicação de conteúdo e para a construção de sistemas que funcionem na web ou, de modo mais direto, que tenham o acesso mediado por um navegador, ainda que os dados possuam alguma restrição de acesso. Estes princípios[^LinkedData] são fundamentais para garantir a identificação, vinculação e recuperação de informações, a saber: [^LinkedData]: Linked Data. Tim Berners-Lee, 2006. Disponível em: https://www.w3.org/DesignIssues/LinkedData.html. Acesso em: 22/03/2021. 1. Usar URIs para nomear (identificar) coisas. Ou seja, transformar textos (*strings*) em objetos digitais (*things*). 2. Usar URIs HTTP para que estas coisas possam ser pesquisadas (consultadas, interpretadas, “referenciadas”). 3. Fornecer informações úteis sobre o que um nome identifica quando é pesquisado, usando padrões abertos como RDF, SPARQL, e metadados descritivos. 4. Consultar outras coisas usando seus nomes HTTP baseados em URI ao publicar dados na Web. Também se faz necessário considerar os modelos de publicação de Dados Abertos Conectados (*Linked Open Data - LOD*), uma vez que estes objetivaram superar as principais dificuldades de vinculação de dados, apontando para a necessidade das informações disponibilizadas serem legíveis por máquinas, permitindo assim o reuso de maneira mais fácil. > Como forma de orientar a publicação de dados abertos na Web, nessa nova visão semântica, Tim Berners-Lee sugeriu um esquema de classificação de 5 estrelas, onde é traçado um caminho evolutivo na direção desse universo de Dados Conectados.[^CertWeb] [^CertWeb]: As 5 Estrelas. Carlos Laufer, 2015. Guia da Web Semântica. Disponível em: https://ceweb.br/guias/web-semantica/capitulo-5/#capitulo-5-sh2. Acesso em: 22/03/2021. ***Figura 01 - As 5 Estrelas dos dados abertos*** ![5 stars](https://5stardata.info/images/5-star-steps.png) Fonte: https://5stardata.info/images/5-star-steps.png Destaca-se também a emergência do uso dos princípios FAIR (***F**indable*, ***A**ccessible*, ***I**nteroperable* e ***R**eusable*) que reúnem diversos desses padrões, desenvolvidos ao longo dos anos, e que podem ser aplicados tanto para dados que tenham restrições de acesso quanto para dados que estejam disponíveis publicamente.[^FAIR][^GoFAIR] Em que pese o foco desta proposta estar direcionada ao gerenciamento e aproveitamento dos dados no âmbito da ciência, entende-se que a aplicação no ambiente regulatório é proveitosa em virtude da emergente necessidade de modelos de regulação intensivos na utilização de dados e evidências (*regulação responsiva* e *smart regulation*[^LegalLD]), além de facilitar a reutilização pelas partes interessadas que precisam participar ativamente do processo regulatório. Frisa-se que os princípios de dados FAIR não apenas descrevem os padrões básicos para dados e metadados, mas também para ferramentas, protocolos e fluxos de trabalho relacionados ao gerenciamento de dados. > Os princípios referem-se a três tipos de entidades: dados (ou qualquer objeto digital), metadados (informações sobre aquele objeto digital) e infraestrutura.[^GoFAIR] De forma resumida, seguem abaixo: [^FAIR]: Turning FAIR into Reality. Comissão Européia, 2018. Disponível em: https://ec.europa.eu/info/sites/info/files/turning_fair_into_reality_1.pdf. Acesso em: 22/03/2021. [^GoFAIR]: FAIR Principles. Disponível em: https://www.go-fair.org/fair-principles. Acesso em: 22/03/2021. [^LegalLD]: Legal Linked Data Ecosystems and the Rule of Law. Marta Poblet; Pompeu Casanovas; Víctor Rodríguez-Doncel, 2019. Disponível em:https://link.springer.com/chapter/10.1007/978-3-030-13363-4_5. Acesso em: 22/03/2021. > * **Localizável** (***F**indable*) > *O primeiro passo para (re)usar dados é encontrá-los. Os metadados e os dados devem ser fáceis de encontrar, tanto para humanos quanto para computadores. Metadados legíveis por máquina são essenciais para a descoberta automática de conjuntos de dados e serviços, portanto, este é um componente essencial do [processo de FAIRificação](https://www.go-fair.org/fair-principles/fairification-process/).* > * [F1. (Meta)dados são atribuídos a um identificador globalmente único e persistente](https://www.go-fair.org/fair-principles/fair-data-principles-explained/f1-meta-data-assigned-globally-unique-persistent-identifiers/) > * [F2. Os dados são descritos com metadados ricos (definidos por R1 abaixo)](https://www.go-fair.org/fair-principles/fair-data-principles-explained/f2-data-described-rich-metadata/) > * [F3. Os metadados incluem clara e explicitamente o identificador dos dados que descrevem](https://www.go-fair.org/fair-principles/f3-metadata-clearly-explicitly-include-identifier-data-describe/) > * [F4. (Meta)dados são registrados ou indexados em um recurso pesquisável](https://www.go-fair.org/fair-principles/f4-metadata-registered-indexed-searchable-resource/) > > * **Acessível** (***A**cessible*) > *Uma vez que o usuário encontra os dados necessários, ele precisa saber como os dados podem ser acessados, possivelmente incluindo autenticação e autorização.* > * [A1. (Meta)dados são recuperáveis por seu identificador usando um protocolo de comunicação padronizado](https://www.go-fair.org/fair-principles/542-2/) > * [A1.1 O protocolo é aberto, gratuito e universalmente implementável](https://www.go-fair.org/fair-principles/a1-1-protocol-open-free-universally-implementable/) > * [A1.2 O protocolo permite um procedimento de autenticação e autorização, quando necessário](https://www.go-fair.org/fair-principles/a1-2-protocol-allows-authentication-authorisation-required/) > * [A2. Os metadados são acessíveis, mesmo quando os dados não estão mais disponíveis](https://www.go-fair.org/fair-principles/a2-metadata-accessible-even-data-no-longer-available/) > > * **Interoperável** (***I**nteroperable*) > *Os dados geralmente precisam ser integrado com outros dados. Além disso, os dados precisam interoperar com aplicativos ou fluxos de trabalho para análise, armazenamento e processamento.* > * [I1. Os (meta)dados usam uma linguagem formal, acessível, compartilhada e amplamente aplicável para a representação do conhecimento](https://www.go-fair.org/fair-principles/i1-metadata-use-formal-accessible-shared-broadly-applicable-language-knowledge-representation/) > * [I2. (Meta)dados usam vocabulários que seguem os princípios FAIR](https://www.go-fair.org/fair-principles/i2-metadata-use-vocabularies-follow-fair-principles/) > * [I3. (Meta)dados incluem referências qualificadas a outros (meta) dados](https://www.go-fair.org/fair-principles/i3-metadata-include-qualified-references-metadata/) > > * **Reusável** (***R**eusable*) > *O objetivo final do FAIR é otimizar a reutilização de dados. Para conseguir isso, metadados e dados devem ser bem descritos para que possam ser replicados e/ou combinados em diferentes configurações.* > * [R1. (Meta)dados são ricamente descritos com uma pluralidade de atributos precisos e relevantes](https://www.go-fair.org/fair-principles/r1-1-metadata-released-clear-accessible-data-usage-license/) > * [R1.1 (Meta)dados são liberados com uma licença de uso de dados clara e acessível](https://www.go-fair.org/fair-principles/r1-1-metadata-released-clear-accessible-data-usage-license/) > * [R1.2 (Meta)dados são associados à proveniência ](https://www.go-fair.org/fair-principles/r1-2-metadata-associated-detailed-provenance/) > * [R1.3 (Meta)dados atendem aos padrões da comunidade relevantes para o domínio](https://www.go-fair.org/fair-principles/r1-3-metadata-meet-domain-relevant-community-standards/)[^GoFAIR] Assim, considerando as boas práticas indicadas de gestão de dados na web, para que a SAR siga um caminho rumo a tal melhoria, há que ser avaliada a aplicação desses modelos nos processos de publicação de normativos e de divulgação de dados da superintendência. Tal ação propõe evitar a recorrência de dificuldades que hoje impedem a integração evolutiva e sistemática das informações produzidas pela agência. ### 4.3 Etapa 3 - Objetivos de decisão e premissas do projeto #### 4.3.1 Objetivos para a tomada de decisão No intuito de orientar as ações a serem tomadas, foram elencados pelo GT alguns objetivos relevantes para a tomada de decisão sobre o processo de comparação de alternativas. ***Tabela 01 - Descrição dos objetivos relevantes para a tomada de decisão*** | Nº | Descrição | | -- | --------- | | 01 | **Agilidade** - Redução de tempo de pesquisa para localizar a informação ligada a objetivos de requisitos da SAR. | | 02 | **Nível de contribuição** - Maior estímulo a contribuições internas e externas na explicitação de conhecimento sobre objetivos de requisitos. | | 03 | **Autonomia** - Menor necessidade de manutenção de base de dados e menor esforço de validação de contribuições. | | 04 | **Custo ANAC** - Menor custo ANAC para tomada de decisão quanto a aprovações e planejamento de supervisão + Menor custo de manutenção da base de dados. | | 05 | **Custo Regulado** - Menor custo para o regulado interpretar requisitos. | | 06 | **Harmonização com métodos já comprovados** - Nível de proximidade da solução avaliada com ferramentas e processos já em uso pelo comunidade de gestão de informações. | Tais objetivos nortearam a estratégia de comparação de soluções, sendo expandidos em atributos com a intenção de permitir a diferenciação das ferramentas de TI, conforme abordado na seção de *avaliação de alternativas* deste relatório (4.5). Em sequência, chegou-se ao entendimento que seria oportuno considerar a utilização de especificações das necessidades do negócio também como referência para a *avaliação de alternativas*. #### 4.3.2 Especificação das necessidades do negócio (Premissas) Com o intuito de facilitar o processo de construção de alternativas, tendo por base uma relação de premissas, são consideradas a seguir as necessidades de negócio. Informa-se ainda que esse esforço é parte da sistemática exigida para os Estudos Técnicos Preliminares (ETP), no contexto de contratações de serviços de TI, como trata o Art. 5º da [INSTRUÇÃO NORMATIVA Nº 40, DE 22 DE MAIO DE 2020](https://www.in.gov.br/en/web/dou/-/instrucao-normativa-n-40-de-22-de-maio-de-2020-258465807), do Ministério da Economia, a saber: > _Art. 5º - Os ETP deverão **evidenciar o problema a ser resolvido** e a melhor solução dentre as possíveis, de modo a permitir a avaliação da viabilidade técnica, socioeconômica e ambiental da contratação._[^IN40] [^IN40]: INSTRUÇÃO NORMATIVA Nº 40, DE 22 DE MAIO DE 2020. Ministério da Economia. Disponível em: https://www.in.gov.br/en/web/dou/-/instrucao-normativa-n-40-de-22-de-maio-de-2020-258465807. Acesso em: 23/03/2021. As necessidades descritas abaixo orientaram os requisitos tecnológicos, o modelo de execução e a gestão entendida como desejável no contexto deste projeto. ***Tabela 02 - Descrição das Necessidades do Negócio*** | Nº | Descrição | | -- | --------- | | 01 | Melhorar continuamente a qualidade das informações relacionadas ao processo de interpretação regulatória. | | 02 | Facilitar a localização de documentos de interpretação regulatória já explicitados. | | 03 | Aprimorar a capacidade de se estabelecer relacionamentos entre temas de interesse da regulação da aviação civil e as informações que subsidiam a sua interpretação. | | 04 | Estabelecer padrões adequados de classificação de informações com vistas ao ganho de escala produtiva e a facilidade de identificação de metadados relevantes. | | 05 | Prover um canal de compartilhamento de conhecimento comum para facilitar a relação entre agentes regulados e os servidores da SAR. | 06 | Prover a SAR de capacidade de observação e acompanhamento permanente do conhecimento de aeronavegabilidade produzido pela comunidade acadêmica. | | 07 | Possibilitar o registro de informações produzidas fora da formalização processual que venham a contribuir para a qualidade do processo regulatório. | | 08 | Identificar necessidades de ajustes visando compatibilizar processos de registro de material interpretativo com mecanismos de disponibilização de informações. | Em síntese, como previsto no plano do projeto, pretende-se: 1) permitir visibilidade rápida e de maneira simplificada dos objetivos dos requisitos de aeronavegabilidade; 2) permitir visibilidade de conexões entre normativos (ex.: SARPS, RBAC, IS); facilitar análise técnica em processos de atualização de normativos, concessão de isenção, nível equivalente de segurança, meio alternativo de cumprimento, etc.; 3) prover maior segurança jurídica às ações de fiscalização e sancionamento. ### 4.4 Etapa 4 - Ideação e identificação de alternativas A partir das causas selecionadas, dos objetivos e das premissas destacadas nas seções anteriores deste relatório (4.2 e 4.3), partiu-se para o levantamento de alternativas. #### 4.4.1 Situação atual A pesquisa empenhada durante o estudo buscou identificar as características do modelo atual, sendo dividido em três partes constitutivas: criação, armazenamento e acesso a informações. E dentre os processos de ocorrência regular no escopo das competências atribuídas à SAR, que dependem e influenciam a interpretação de requisitos, tem-se cinco processos: a) Processo normativo; b) Processo de verificação de cumprimento com requisitos; c) Processo de fiscalização; d) Processo sancionatório e e) Processo de atendimento de manifestação de dúvidas de regulados. #### 4.4.2 Frentes de abordagem do projeto Como estratégia de trabalho, foram feitas duas abordagens, uma voltada para a descoberta e aplicação de ferramentas de Tecnologia de Informação - TI e outra para a identificação de melhorias de processos. ##### 4.4.2.1 Ferramentas de TI No que tange ao emprego de ferramentas de TI, o projeto usou como premissas específicas: 1) utilização de sistemas que fossem compatíveis com o ambiente institucional da ANAC; 2) sistemas em formato web; 3) *softwares* em código aberto ou de uso gratuito; 4) recursos que possuam ferramenta de busca; 5) recursos que permitam capturar comentários dos usuários, visando interação, atualização e adaptação dos conteúdos às necessidades organizacionais. Tais referências visam reduzir o custo de implementação para a SAR, possibilitando a construção de protótipos de modo a contemplar as demandas levantadas pelos usuários e apresentadas durante a fase de desenvolvimento de solução de TI a ser proposto como segunda fase deste projeto. ##### 4.4.2.2 Melhorias de processos Paralelamente, foram adotadas como premissas no contexto de melhorias de processo: 1) Recomendar melhorias e boas práticas de gestão de dados para facilitar o uso das ferramentas de TI propostas; 2) Foco na padronização de linguagem e utilização de metadados no intuito de permitir conexão com funções de busca. ###### 4.4.2.2.1 Exemplos de melhorias de processos possíveis 1) **Padronização de uso de quadros comparativos em processos de desenvolvimento/revisão de RBAC e IS:** No intuito de viabilizar mecanismo de busca que permita relacionar histórico de motivação de revisão de normativos. Nesse sentido, o processo de desenvolvimento e revisão de RBAC e IS pode adotar um padrão de registro. Assim, recomenda-se a adoção dos seguintes grupos de informação em colunas em um formato de quadro comparativo. ***Tabela 03 - Quadro comparativo para a revisão da regulamentação*** | 1: Seção do regulamento |2: Texto pré revisão |3: Texto de referência|4: Texto proposto|5: Motivação da proposta por seção| | -- | ----- |--------- |-- |-- | | Identificação numérica de seção | Texto atual da seção |Texto normalmente aproveitado de material de outra autoridade |Proposta de alteração |A redação proposta indica que xxyyzz | > Nota: Quadros de divulgação de publicação de IS também são exemplos de informação já organizada que facilmente seria aproveitada em sistema de busca aqui abordado. 2) **Padronização para a abertura de banco de *policy files* ao público externo**: Durante rodada de levantamento de subsídios junto a público interno da SAR foi percebido que seria importante a abertura do banco de interpretações da SAR ao público externo à superintendência, o que incluiria a possibilidade de disponibilização do referido material por meio do sítio eletrônico da ANAC, em um formato compilado (condensando a informação em um único documento, como por exemplo um memorando). Todavia, entendeu-se que a viabilização de tal melhoria requer um ajuste no processo de emissão de tais documentos de maneira similar ao que ocorre no contexto da Federal Aviation Administration - FAA, que utiliza como referência o ORDER IR 8100.16, cujo assunto é *Aircraft Certification Service Policy Statement, Policy Memorandum, and Deviation Memorandum Systems*. Nota-se que o aceso ao banco de policy files da FAA é disponibilizado por meio do *[Regulatory Guidance Library - RGL](https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgPolicy.nsf/MainFrame?OpenFrameSet)*. 3) **Aproveitamento de mecanismo de busca que cubra respostas já disponibilizadas a demandantes via Fale com a ANAC:** Durante as entrevistas com gestores foi informado que os sistema utilizado para registro de manifestações por meio do Serviços Especializados de Atendimento a Manifestações - SEAM da Gerência Técnica de Gestão da Informação - GTGI da Superintendência de Administração e Finanças - SAF, em resposta a solicitações via Fale com a ANAC, aparentemente não disponibilizaria visibilidade de histórico de respostas já cadastradas, o que poderia ser viabilizado junto ao administrador do sistema no intuito de facilitar o processo de construção de respostas futuras. Todavia, vale notar que dentro do Portal de serviços da ANAC já há disponível para acesso o Portal de Conhecimento que permite busca de manifestações já realizadas pelas Uorg da ANAC. Assim, caberia vinculação de tal base com eventuais ajustes que facilite a integração. Ex.: [Base de conhecimentos do portal de serviços](https://sistemas.anac.gov.br/portaldeservicos/pages/knowledgeBasePortal/knowledgeBasePortal.load#/list/730). De posse de tal informação foi feita consulta à Gerência de Planejamento - GTPL da SAR, e foi possível constatar que já existe hoje a prática de geração de relatórios periódicos da base citada e que poderia ser adaptada para alimentar uma base de dados que poderia fazer parte do conjunto de funcionalidades de busca a ser proposto no contexto deste projeto. #### 4.4.3 Estratégia de levantamento de alternativas Além dos subsídios oriundos da pesquisa feita junto ao público interno consultado, o levantamento de alternativas considerou práticas utilizadas por outros órgãos assim como em soluções desenvolvidas por grupos especializados. Como referência inicial partiu-se de um levantamento por meio de pesquisa e *Brainstorming* pelo GT, que resultou no Quadro 02, com uma lista de possibilidades por frentes de trabalho. ***Quadro 02 - Relação inicial de alternativas por frentes de trabalho*** ![](https://i.imgur.com/tQRNHmI.png) O Quadro 02 divide a relação inicial nas seguintes frentes de trabalho: 1. Frente 1 - Mecanismo de busca indexada de informações já explicitadas; 2. Frente 2 - Disponibilização de conhecimento explicitado; 3. Frente 3 - Registro de discussões feitas fora de formalização processual; 4. Frente 4 - Canal de discussão com público externo. Ex.: Fórum de discussões e 5. Frente 5 - Mapeamento de conexão de normativos. Adicionalmente, foi levantado um grupo de possíveis funcionalidades relacionadas com as frentes de trabalho consideradas, sendo complementado com sugestões de aplicação conforme [4.4.3.1](#4431-Necessidades-dos-sistemas-pretendidas). ##### 4.4.3.1 Necessidades dos sistemas pretendidas A seguir é apresentado o conjunto de necessidades selecionadas pelo GT que seria alvo de recomendação deste estudo. Para cada uma das necessidades foi construída uma matriz com iniciativas, acompanhadas de nível de **impacto X esforço** e atividade de implementação requerida. **A) Base de dados e mecanismo de busca que permita identificação de motivação de requisitos** Para viabilizar um sistema de busca, a alternativa identificada propõe a construção de uma base de dados que seja alimentada com quadros comparativos que preferencialmente já absorvam a versão final da proposta de emenda aprovada, incluindo resultado de análise de contribuições e discussões ocorridas no final do processo. Como exemplo de arquivo a ser aproveitado, mas que precisaria ser ajustado visando uma padronização da informação de maneira compatível com o mecanismo de busca, tem-se o Quadro comparativo RBAC 21 [Emenda nº 03] – Tema nº 25 da Agenda Regulatória 2017-18 da ANAC, publicado por meio da Resolução nº 495, de 14.11.2018, cuja representação é feita por meio da Figura 02. * _**Figura 02 – Exemplo de quadro comparativo oriundo de Emenda 03 ao RBAC 21.**_ ![](https://i.imgur.com/iptEnGd.png) Fonte: Processo SEI, Quadro Comparativo - RBAC 21 (EMD03) A busca propiciada por meio de cruzamento de informações oriundas de quadros comparativos pode ser complementada por relação de emendas e documentos de aprovação (Resoluções, portarias, entre outras). Como possibilidade de ferramenta de busca indexada de informações já explicitadas tem-se como *benchmarking* o modelo já em uso pela FAA, por meio do Canal RGL, abreviação para _Regulatory and Guidance Library_. O Canal RGL da FAA concentra num mesmo ambiente (endereço rgl.faa.gov), de maneira indexada na página inicial, uma livraria virtual com todos os requisitos, os seus registros, do que pode ser público, dos respectivos processos de normatização, bem como todos os tipos de documento de orientação complementar oficiais produzidos pela FAA. A *Figura 03* apresenta a tela inicial do *Regulatory and Guidance Library* da FAA. * _**Figura 03 - Regulatory and Guidance Library da FAA**_ ![](https://i.imgur.com/yF9lQ0J.png) Fonte: [RGL FAA](https://rgl.faa.gov) A base de dados deste canal não é exaustiva, em especial no que se refere a documentos de orientação (_Guidances_), pois existem documentos emitidos por outras instituições que são reconhecidos pela FAA. Contudo, a maioria dos documentos estão contidos e disponibilizados nesta livraria virtual, que representa a principal fonte de consulta para representantes da própria FAA, de outras autoridades, da própria sociedade americana, bem como outras partes interessadas. Essa biblioteca permite busca de diversas formas, tanto de documentos vigentes como de versões ultrapassadas, de modo a permitir a consulta de todo histórico de documentos, o que é de suma importância na regulamentação aeronáutica. O RGL da FAA tem gradativamente deixado de replicar o conteúdo para utilizar mais o relacionamento de *links* para conteúdos disponibilizados em outros ambientes virtuais da FAA, de modo a não haver duplicação de conteúdo pela FAA. Como caracterísitica, esta ferramenta não permite produção de conteúdo por seus usuários, sendo neste sentido uma "via de mão única", sem, portanto, incorporar características de plataforma colaborativa. Entende-se que o RGL da FAA é o melhor _benchmark_ a ser utilizado para a criação de uma biblioteca virtual correspondente da ANAC, por ser uma referência já familiar para o perfil de usuário potencial, por apresentar formas de indexação maduras, e por ser reconhecidamente amigável a qualquer usuário. Finalmente, uma ferramenta na ANAC tal qual o "RGL da FAA" pode ser desenvolvida de modo indexado ao quadro comparativo exibido na *Figura 03*, desde sua concepção. Portanto, tal esforço é facilitado se for definida a arquitetura do sistema a ser utilizada para identificar e explicitar a motivação dos requisitos, e processos para: * Processo 1 - Definir responsáveis por requisitos, ou grupos de requisitos, que pode ter como resultado uma lista de responsáveis; * Processo 2 - Migrar o resultado de seu ato normativo para este sistema, após ser concluído o processo formal. Incluir a publicação em diário oficial e incluir a motivação da alteração. Em adição, sugere-se a implantação de um ambiente de recuperação de informação mais moderno, capaz de extrair relacionamentos semânticos ricos, identificação automatizada de entidades nomeadas, buscas facetadas e integração de diferentes bases de dados. O [OpenSemanticSearch](https://opensemanticsearch.org/) é um sistema de código-aberto que apresenta essas características, como visto na tela abaixo. * _**Figura 04 - OpenSemanticSearch**_ ![OpenSemanticSearch](https://i.imgur.com/b8DWRgq.png) Fonte: [OpenSemanticSearch](https://opensemanticsearch.org/doc/admin/install/search_appliance) A tabela a seguir indica quais iniciativas seriam aplicáveis, qual a relação de esforço necessário e qual nível de impacto positivo gerado em caso de adoção pela SAR. As iniciativas são complementadas com propostas de implementação que consideram detalhes explicativos sobre as ações. ***Tabela 04 - A - Matriz Esforço X Impacto*** ```csvpreview {header="true"} Código - Iniciativa,Esforço,Impacto,Implementação A1 - Padronização da informação de maneira compatível com o sistema de busca,Baixo,Alto,Quadro de divulgação de publicação e quadro comparativo sobre alteração dos requisitos A2 - Desenvolver sistema de busca moderno com dados semânticos e facetados,Alto,Alto,"Sistema de busca que localize informações indexadas entre bases distintas (Pergamum, SEAM, Intranet SAR, Banco de Policy, WikiANAC)" A3 - Canal similar ao RGL para a ANAC,Alto,Alto,Sistema web contendo documentos normativos e requisitos relacionados disponíveis ao usuário externo e à outras autoridades - busca facetada considerando o contexto de utilização de normativos ``` **B) Relacionamento de documentos ligados a um mesmo tema** Alcance de material desenvolvido pelas áreas técnicas e disponibilizado por meio de páginas temática e pirâmide regulatória, com informação organizada por metadados relevantes para o domínio de aviação civil (ATA 100, JASC code, requisitos...). Exemplo: WikiANAC alimentado pela SAR e conexão por grafos de relacionamentos. Esse tipo de abordagem permitiria uma gama de explicitação de interfaces documentais que poderia relacionar seções de regulamentos com: IS, AC, Sarps ICAO, requisitos estrangeiros, listas de condições especiais, material acadêmico, *policy files*, entre outros. Esforços nesse sentido já foram iniciados por alguns servidores e estão disponíveis nas páginas da WikiANAC, como exemplo: - ***Figura 05 - [Sistema hidráulico - WikiANAC](https://sistemas.anac.gov.br/wiki/index.php/Sistema_hidr%C3%A1ulico)*** ![](https://i.imgur.com/1LbLPsa.png) Fonte: [WikiANAC](https://sistemas.anac.gov.br/wiki/index.php/Sistema_hidr%C3%A1ulico) Ressalta-se a importância de estabelecer instrumentos de medição e acompanhamento da relevância de assuntos, para não haver geração de conteúdo apenas de forma espontânea, por servidores proativos, e sim também por definição institucional de quais assuntos devem ser tratados, com a devida definição de responsáveis e como resultado deste processo, a geração de conteúdo relevante. Ressalta-se também a importância de definir responsáveis por assuntos, cujo endosso significa que a posição é oficial da ANAC, portanto, institucional; e talvez criar níveis inferiores de registro que explicitem a opinião dos especialistas, mesmo que por não ser oficial da ANAC, pode ser recontextualizada ou melhorada futuramente. Deve-se estabelecer um processo para distinguir estas duas situações, bem como o nível de publicidade de cada uma. Além disto, deve-se estabelecer um processo para o reconhecimento de que a posição registrada é a institucional, o que certamente passa pela definição do responsável por responder a esta questão dentro da ANAC. A *Pirâmide de validação da informação* esboçada abaixo sugere um modelo didático sobre a hierarquia da informação no âmbito regulatório (*1. Regulamentação, 2. Orientação, 3. Discussão*) e algumas das alternativas aqui discutidas. * ***Figura 06 - Pirâmide de validação da informação regulatória para o processo de interpretação normativa*** ![Pirâmide de validação da informação regulatória para o processo de interpretação normativa](https://i.imgur.com/xaRAf1H.png) Fonte: Esquematizada pelo GT Informa-se também que há processos em execução, como o de publicação de *Policy Files* pela SAR, que no caso dos seus conteúdos serem incorporados às ferramentas e métodos aqui propostos, não seriam necessárias mudanças drásticas no fluxo de trabalho já estabelecido. Para a sistematização desses esforços seria importante a **padronização de termos relevantes (vocabulário controlado)** e a **construção de modelos** **(_templates_)** a serem usados pelos criadores de conteúdo na superintendência, de modo a atender às sugestões aqui descritas. Como referência para a organização dos documentos temos o RGL da FAA e os exemplos da ANAC aqui citados. Nesse sentido, há a necessidade de estabelecer processos organizacionais para: * Processo 1 - Definir a lista de temas de maior relevância para ANAC; * Processo 2 - Definir responsáveis por temas, que pode ter como resultado uma **lista de responsáveis**; * Processo 3 - Indicar nível de interpretação (opinião de especialista X posicionamento oficial da ANAC); * Processo 4 - Definir e orientar sobre o nível de publicidade dos conteúdos (restrito X amplo - atentar às próprias restrições da LAI); e * Processo 5 - Ratificar uma posição individual de um especialista como sendo a posição institucional da ANAC. Finalmente, dentre os benefícios imediatos para gestão ANAC que se observa da lista de processos acima, pode-se citar: 1. A criação do Processo 2 permite vincular a atividade à meta setorial e individual do servidor responsável; 2. A existência do Processo 3 permite, na medida que a LAI referida no processo 4 exija a publicidade de determinado conteúdo, que fique transparente que se trata da opinião do servidor responsável, ainda não transformada em posição institucional, após ratificada pelo processo 5. A tabela a seguir indica quais iniciativas seriam aplicáveis, qual a relação de esforço necessário e qual nível de impacto positivo gerado em caso de adoção pela SAR. As iniciativas são complementadas com propostas de implementação que consideram detalhes explicativos sobre as ações. ***Tabela 05 - B - Matriz Esforço X Impacto*** ```csvpreview {header="true"} Código - Iniciativa,Esforço,Impacto,Implementação B1 - Organizar informações por metadados relevantes para o domínio de aviação civil,Alto,Alto,Utilização de vocabulário controlado para indexação de conteúdos (ATA 100 - JASC Code - Ontologias industriais) B2 - Construção de relacionamento semântico e grafo de conhecimento envolvendo metadados e documentação normativa,Baixo,Alto,"Criação de grafo de conhecimento e produção de conteúdo (Kumu.io, GraphCommons, WikiANAC, MkDocs)" B3 - Definição de grupo de curadores responsáveis por temas de relevância para a Superintendência,Baixo,Alto,Lista de curadores e critérios de qualidade B4 - Construção de instrumentos de medição e acompanhamento da relevância/validade/verificação de conteúdos criados,Alto,Baixo,Documento de políticas para o uso das ferramentas e produção de conteúdo considerando os níveis de validação e publicidade (Figura X - 1 2 3) B5 - Modelos/templates para criação de conteúdos nas diversas ferramentas de publicação,Baixo,Alto,Sistematizar bons artefatos já desenvolvidos e promover a divulgação ``` **C) Abertura de fórum de discussão** Foi entendido como oportuno o desenvolvimento de um canal de manifestações a respeito de motivação de requisitos podendo ser aberto a público externo, que incluiria funcionalidade de discussão de requisitos dentro do texto dos normativos e também o ranqueamento de manifestações de maneira a estimular participações tanto interna quanto externa. 1. Ferramenta "intra-documento" - permite comentários relacionados diretamente à um conteúdo exposto na web, comentários são vinculados ao endereço do recurso digital - Hyphotes.is 2. Ferramenta "extra-documento" - Fórum Tal abordagem não configuraria posicionamento formal da SAR sobre os temas apresentados, mas serviria como ponto de atenção em estudos interpretativos e ao mesmo tempo poderia funcionar como canal para apontamento de conclusões formais quando já existentes. Como exemplo tem-se o formato conhecido como Yahoo Respostas, com possibilidade de ranqueamento de manifestações. A evolução desse modelo de interação de fórum de perguntas e respostas conta com diversos sistemas, entre estes: [Stack Exchange](https://stackexchange.com/), [Quora](https://www.quora.com/), [Askbot](https://askbot.com/), [Question2Answer](https://www.question2answer.org/) ([tema](https://github.com/MominRaza/Mayro)), [Discourse](https://www.discourse.org/). A ferramenta mais proeminente que foi localizada é o *[Discourse](https://www.discourse.org/)*, tendo sido identificado o uso para discussões assíncronas em fóruns de organizações privadas ([ATOM](https://discuss.atom.io/), [Twitter](https://twittercommunity.com/), [Codecademy](https://discuss.codecademy.com/)), de organizações estatais ([IBICT - Instituto Brasileiro de Informação em Ciência e Tecnologia](https://forum.ibict.br/)) ou de grupos envolvidos em temas públicos ([dadosabertos.social](https://dadosabertos.social/)). * ***Figura 07 - Discourse*** ![](https://i.imgur.com/rhGeVjQ.png) Fonte: [dadosabertos.social](https://dadosabertos.social/) Portanto, há necessidade de estabelecer processos para: * Processo 1 - Definir responsáveis por fórum, que pode ter como resultado uma lista de responsáveis, e suas atribuições, que devem incluir a mediação das discussões e a eventual inserção de respostas institucionais, se for o caso, mesmo que servidores poderão escrever em seu nome; e * Processo 2 - Definir a lista de fóruns e seu relacionamento ou correspondência com os atos normativos. A tabela a seguir indica quais iniciativas seriam aplicáveis, qual a relação de esforço necessário e qual nível de impacto positivo gerado em caso de adoção pela SAR. As iniciativas são complementadas com propostas de implementação que consideram detalhes explicativos sobre as ações. ***Tabela 06 - C - Matriz Esforço X Impacto*** ```csvpreview {header="true"} Código - Iniciativa,Esforço,Impacto,Implementação C1 - Implementar ferramenta de fácil utilização para comentário de conteúdo digital divulgado,Baixo,Alto,Utilização do serviço do hyphotes.is mediante ajuste dos links (URIs) ou ferramenta específica (https://docdrop.org/) para os conteúdos publicados C2 - Implementar ferramenta de fácil utilização para fórum de perguntas e respostas,Baixo,Alto,Utilização do serviço do Discourse ou Q2A estabelecendo responsabilidades para acompanhamento. C3 - Definir organização e administração de fórum de perguntas e respostas,Alto,Alto,Definição de temas e relacionamento com atos normativos e definição de curador para redistribuição ``` **D) Canalização de discussões tratadas apenas informalmente** Geração de base de dados como opção voluntária para armazenar discussões tratadas por e-mail e por outros meios não formais (demais aplicativos de mensagens, discussões em reuniões, entre outras), que possam agregar no processo interpretativo de requisitos, de forma que seja possível aplicação de mecanismo de busca por temas. Atualmente o SEAM já funciona como mecanismo de padronização de respostas externas, mas discussões internas não necessariamente são rastreáveis. Nesse sentido também foi identificada oportunidade de abertura para pesquisa de manifestações já cadastradas no SEAM e de geração de nova plataforma visando possibilidade de armazenamento de discussões internas voluntariamente pelas áreas técnicas da SAR. - ***Figura 08 - SEAM*** ![](https://i.imgur.com/2CTEYZf.png) Fonte: [Base de conhecimentos do portal de serviços](https://sistemas.anac.gov.br/portaldeservicos/pages/knowledgeBasePortal/knowledgeBasePortal.load) No caso da criação do um sistemas equivalente ao SEAM para manifestações internas, requer-se implementar o processo de trabalho equivalente ao do SEAM também para este sistema, utilizando-o, assim, como *benchmark* interno. A tabela a seguir indica quais iniciativas seriam aplicáveis, qual a relação de esforço necessário e qual nível de impacto positivo gerado em caso de adoção pela SAR. As iniciativas são complementadas com propostas de implementação que consideram detalhes explicativos sobre as ações. ***Tabela 07 - D - Matriz Esforço X Impacto*** ```csvpreview {header="true"} Código - Iniciativa,Esforço,Impacto,Implementação D1 - Criar canal para receber discussões internas,Baixo,Alto,Estabelecimento de e-mail e/ou formulário web para capturar discussões. D2 - Construir base de dados para as respostas cadastradas,Alto,Alto, Construção de grafo de conhecimento relacionando normativos e temas D3 - Construir ambiente de consulta a respostas cadastradas,Alto,Alto, Criação de ambiente de recuperação da informação nos moldes do RGL da FAA D4 - Iniciar processo SEI para diferenciar conteúdo sensível,Baixo,Alto, Utilização de processo específico no SEI para controle do nível de acesso dos conteúdos D5 - Promover ferramenta de consulta do SEAM,Baixo,Alto, Divulgação da ferramenta de busca. ``` **E) Localizador de material acadêmico** Foi entendido como oportuna a possibilidade de criação de um mecanismo de busca de trabalhos acadêmicos úteis ao processo de interpretação de requisitos, por meio da consulta a portais disponíveis na *web*. Desse modo, foram pesquisadas ferramentas que realizam indexação automatizada de publicações científicas, em geral utilizando trabalhos acadêmicos abertos e *softwares* de mapeamento, exploração e recomendação de literatura. A relação abaixo apresenta uma relação de ferramentas: * [Citation Gecko](https://citationgecko.com/) - requer instalação do sistema * [PaperGraph](https://github.com/dennybritz/papergraph) - requer inserção de 05 trabalhos acadêmicos iniciais * [Connected Papers](https://www.connectedpapers.com/) * [Open Knowledge Map](https://openknowledgemaps.org/) * [Semantic Scholar](https://www.semanticscholar.org/) * [Google Scholar](https://scholar.google.com/) * [Microsoft Academic](https://academic.microsoft.com/) Como exemplo foi considerada a pesquisa pelo tema *Flutter* e trabalhos associados: * ***Figura 09 - Connected Papers*** ![](https://i.imgur.com/N3bPp4W.png) Fonte: [Flutter and Resonant Vibration Characteristics of Engine Blades](https://www.connectedpapers.com/main/9257197c2ca65775592ba80b4e923e4f44436bdc/Flutter-and-Resonant-Vibration-Characteristics-of-Engine-Blades/graph) * ***Figura 10 - Open Knowledge Map*** ![](https://i.imgur.com/UKACc6h.png) Fonte: [Flutter](https://openknowledgemaps.org/map/0f7fff88a984f651209c40aefd6e09fe) Adicionalmente tem-se o mesmo trabalho usado de exemplo no *Connect Papers* pesquisado no *Semantic Scholar* e no *Google Scholar*. * Semantic Scholar Fonte: [Flutter and Resonant Vibration Characteristics of Engine Blades](https://www.semanticscholar.org/paper/9257197c2ca65775592ba80b4e923e4f44436bdc) * Google Scholar Fonte: [Flutter and Resonant Vibration Characteristics of Engine Blades](https://scholar.google.com/scholar?q=Flutter%20and%20Resonant%20Vibration%20Characteristics%20of%20Engine%20Blades) * Microsoft Academic Fonte: [Flutter and Resonant Vibration Characteristics of Engine Blades](https://academic.microsoft.com/search?q=Flutter%20and%20Resonant%20Vibration%20Characteristics%20of%20Engine%20Blades&f=&orderBy=0&skip=0&take=10) A ferramenta da Microsoft não foi capaz de encontrar nenhum resultado: > SORRY WE COULDN'T FIND ANY RESULTS FOR "Flutter and Resonant Vibration Characteristics of Engine Blades" A tabela a seguir indica quais iniciativas seriam aplicáveis, qual a relação de esforço necessário e qual nível de impacto positivo gerado em caso de adoção pela SAR. As iniciativas são complementadas com propostas de implementação que consideram detalhes explicativos sobre as ações. ***Tabela 08 - E - Matriz Esforço X Impacto*** ```csvpreview {header="true"} Código - Iniciativa,Esforço,Impacto,Implementação E1 - Selecionar temas,Baixo,Baixo,Mapeamento junto às gerências E2 - Definir curadoria,Alto,Alto,Gestão de curadores E3 - Informar curadores e servidores sobre utilização de ferramentas,Baixo,Baixo,Desenvolvimento de material de orientação ``` **F) Policy file ostensivo** Adaptação de processo de policy file visando a possibilidade de torná-lo ostensivo. Especificamente sobre o processo de policy file da SAR, foi identificada a oportunidade de melhoria por meio de criação de memorando ou algo com tal funcionalidade para ajustar o nível de detalhamento que possa ser considerado público, na linha do que é feito pela FAA (vide 4.4.2.2) Além disso, conectar material gerado ao mecanismo de busca de objetivo dos requisitos. Nesse sentido a base de *policies* precisaria permitir pesquisa por uma ferramenta de busca integrada, ficando a decisão a cargo da gestão do que será aberto ao público ou não. A tabela a seguir indica quais iniciativas seriam aplicáveis, qual a relação de esforço necessário e qual nível de impacto positivo gerado em caso de adoção pela SAR. As iniciativas são complementadas com propostas de implementação que consideram detalhes explicativos sobre as ações. ***Tabela 09 - F - Matriz Esforço X Impacto*** ```csvpreview {header="true"} Código - Iniciativa,Esforço,Impacto,Implementação F1 - Avaliar base atual de policy files quanto à restrição de acesso,Alto,Alto,Distribuir policy por assunto à cada área solicitando indicação de conteúdo não ostensivo F2 - Organizar base com metadados específicos de policy,Baixo,Alto,Cadastramento de policy files de maneira indexada para permitir recuperação mais eficiente do conteúdo F3 - Evoluir processo de construção de policy files,Alto,Alto,Criação de memorando que resume policy e a torna ostensiva ``` ### 4.5 Etapa 5 - Avaliação de alternativas Considerando a estratégia adotada pelo grupo, entende-se que a continuação do projeto requer uma etapa de construção e implementação de protótipos objetivando a validação do que foi identificado no estudo realizado até o momento. A construção dos protótipos irá considerar a utilização das ferramentas identificadas anteriormente e avaliadas a seguir. De modo resumido, o conjunto de ferramentas avaliado terão enfoque sobre: - a criação e divulgação de conteúdo; - o relacionamento de documentos, temas, conceitos e interoperabilidade das informações; e - o aproveitamento de novas fontes de informação para o processo regulatório. Destaca-se que as ferramentas podem funcionar em conjunto e são complementares, adaptando-se aos casos de uso propostos e ao público alvo. A distribuição seguindo esta divisão por enfoques visa sistematizar a comparação quanto à finalidade principal das ferramentas para uso no problema a ser enfrentado. Informa-se ainda que cada uma delas possui sua própria ferramenta de busca (recuperação de informações) e classificação (organização de informações). Com isso, a depender da estrutura a ser montada na superintendência, podem ter as suas informações facilmente consumidas por outras ferramentas, por meio de API já disponível ou por consulta direta às suas bases de dados. ##### 4.5.1 - Comparações visando prototipação As ferramentas avaliadas para prototipação seguem diferentes metodologias e notações. Para uma melhor sistematização destacaremos as principais característica observadas nestas em relação às necessidades dos trabalhos na SAR. Foi considerado pelo GT que seria adequado a seleção de ferramentas com menor custo total de implementação, tomando como base alguns testes e a experiência pregressa da equipe. A seguir, apresentamos a comparação inicial das ferramentas e os modelos de construção adotados que justificam as escolhas da equipe do projeto. ##### 4.5.1.1 - Mediawiki + MKDocs (foco na criação e divulgação de conteúdo) > Nota: Como indicado acima, por exemplo, esta abordagem inclui, além da criação e sua divulgação de informações, também o relacionamento de conteúdo e a possibilidade de incorporar dados de novas fontes de informação. Como ponto central de produção de conteúdo, entendemos que a utilização do Mediawiki, disponível na WikiANAC, aliado à atualização do *software* para conter as extensões de relacionamento semântico (Semantic MediaWiki) atenderiam de forma rápida aos objetivos de prototipação, além de garantir o controle de versão, a incorporação de conteúdo externo e o natural aproveitamento das informações já disponibilizadas. Também se destaca como desnecessária a capacitação dos usuários para iniciar a produção de material de interesse da superintendência, como já ocorre em algumas gerências e coordenações. No entanto, caso se entenda por oportuno, a conversão do conteúdo do MediaWiki (escrito em wikitexto) para o MkDocs (escrito em Markdown) pode ser facilmente realizada por meio da biblioteca [Pandoc](https://pandoc.org/). Tal fluxo visa acelerar a possibilidade de contribuição dos servidores com o conteúdo, o ajuste dos metadados e a posterior publicação de uma ferramenta - mais similar ao RGL - para toda a comunidade de aviação. O processo pensado poderia utilizar apenas o MkDocs, no entanto teríamos dificuldades de gerenciamento e de cooperação ao longo do tempo. O MkDocs possui menos recursos de edição e o controle de versão seria feito no ambiente da ANAC através de arquivos estáticos e GIT. Além disso, a vinculação de metadados é feita em YAML e não conta com a mesma expressividade semântica do MediaWiki. No entanto, salienta-se que a ferramenta de busca do MkDocs apresenta uma ótima usabilidade. Nela pode ser construída uma faceta apenas para implementar o relacionamento entre normativos, de modo a facilita a consulta do público interno e externo. A seguir indicamos uma análise comparativa contendo critérios que levaram a essa escolha sobre o uso das ferramentas, de modo a beneficiar a agência da sua aplicação conjugada. ***Tabela 10 - Criação - Análise comparativa*** ```csvpreview {header="true"} Critérios,MediaWiki,MkDocs Usabilidade para prototipação,Fácil manuseio,Difícil manuseio (exige conhecimento especializado) Organização de Dados,Textual,Textual Custo de implementação,Baixo,Alto Interoperabilidade,Alto acoplamento,Médio acoplamento Performance do sistema de busca,Média ou Alta se substituído por ElasticSearch,Alta Escalabilidade,Alta,Alta Autonomia do usuário,Alta,Nula Disponibilidade,ANAC,ANAC Manutenibilidade,Fácil,Difícil Expressividade semântica,Média (hierárquico) ou alta com Semantic Mediawiki (não hierárquico),Média (hierárquico) Formato de metadados,Wikitext ou Semantic Mediawiki com formulários em linguagem natural,YAML Portabilidade,Média,Baixa Proximidade do RGL,Baixa ou Alta se substituída por skin por Medik,Alta ``` Para tanto, há que se construir o fluxo de implementação que, de forma resumida, conteria as seguintes etapas: 1. Escrita incial no Mediawiki 2. Conversão com Pandoc 3. Ajuste de Metadados 4. Publicação no MkDocs ##### 4.5.1.2 - Kumu x GraphCommons (foco no relacionamento de conteúdo e interoperabilidade) >Nota: Inclui-se também a criação de conteúdo e o aproveitamento de novas fontes de informação. Em primeiro lugar, é preciso indicar que o trato de ativos digitais de informação carregam o desafio de construir e usar modelos de descrição padronizados que possibilitem a identificação, localização, recuperação e integração dos dados. Como demonstrou a pesquisa realizada nesse projeto, os ativos trabalhados no ambiente normativo apresentam diversas especificidades que demandam ações sistemáticas e previsíveis para relacioná-los. Nesse sentido, a proposta desse projeto indica a utilização de um modelo que dispõe de uma base de dados baseada em grafos. É importante destacar que um grafo, na matemática e na ciência da computação, pode ser entendido como uma rede composta por *nós* (elementos, vértices), conectados ou não entre si, e *linhas* (caminhos, arestas, arcos, conexões) que conectam estes nós. Se as conexões têm uma direção ou fluxo específico, considera-se que o grafo é de tipo direcionado. Se nenhuma direção é especificada, o grafo é chamado de grafo não direcionado. Os grafos são um conceito importante para as bases de dados e são frequentemente usados para modelar problemas em redes complexas: redes sociais, estudos bioquímicos, estudos biológicos, mapas, sistemas de recomendação e outros problemas envolvendo um grande número de relacionamentos que dependem de grafos e da sua teoria associada[^KGMain][^KGraphs][^Bio]. Observa-se ainda a recente utilização destes, também referidos como grafos de conhecimento (*knowledge graphs*), no domínio específico da aviação, em áreas como: aeronavegabilidade[^Airworthiness], gestão de riscos[^KGRisk] e controle do espaço aéreo[^NASA]. [^KGMain]: A Brief History of Knowledge Graph's Main Ideas: A tutorial, 2019. Claudio Gutierrez; Juan F. Sequeda. Disponível em: http://knowledgegraph.today/paper.html. Acesso em: 23/03/2021. [^KGraphs]:Knowledge Graphs, 2021. Aidan Hogan, Eva Blomqvist, Michael Cochez, Claudia d'Amato, Gerard de Melo, Claudio Gutierrez, José Emilio Labra Gayo, Sabrina Kirrane, Sebastian Neumaier, Axel Polleres, Roberto Navigli, Axel-Cyrille Ngonga Ngomo, Sabbir M. Rashid, Anisa Rula, Lukas Schmelzeisen, Juan Sequeda, Steffen Staab, Antoine Zimmermann. Disponível em: https://arxiv.org/abs/2003.02320. Acesso em: 26/03/2021. [^Bio]: Using graph theory to analyze biological networks, 2011. Georgios A Pavlopoulos; Maria Secrier; Charalampos N Moschopoulos; Theodoros G Soldatos; Sophia Kossida; Jan Aerts; Reinhard Schneider; Pantelis G Bagos1. Disponível em: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3101653/. Acesso em: 25/03/2021. [^Airworthiness]:Ontology of Airworthiness Rules based on Knowledge Graph, 2020. Honggang Liu, Yong Cai and Weidong Yang. Disponível em: DOI: 10.23977/cii2019.41 ou https://www.clausiuspress.com/conference/article/artId/3645.html. Acesso em: 26/03/2021. [^NASA]:Building a Knowledge Graph for the Air Traffic Management Community, 2019. R. Keller. Disponível em: https://doi.org/10.1145/3308560.3317706. Acesso em: 23/03/2021. [^KGRisk]:Construction and application research of knowledge graph in aviation risk field, 2018. Qian Zhao, Qing Li, Jingqian Wen. Disponível em: https://doi.org/10.1051/matecconf/201815105003. Com isso, a proposta aqui sugerida visa gerenciar e centralizar **todas as informações/ relevantes relacionadas aos objetivos dos requisitos de aeronavegabilidade** (normas, projetos, áreas institucionais, indivíduos, pesquisas, etc.), a serem representadas por meio de metadados em um grafo de conhecimento. Como indicam as boas práticas para dados na web[^DataBestPractices], os *metadados descritivos* enriquecem os ativos digitais trazendo suas características e propriedades, tornando os ativos mais acessíveis e facilitando o compartilhamento das informações. O modelo a ser prototipado propõe estabelecer os requisitos necessários para um **padrão de metadados descritivos para os dados regulatórios de aeronavegabilidade**, com um tratamento informacional que possibilite a recuperação e a interoperabilidade das informações entre as áreas da SAR. Ressalta-se ainda que o cruzamento de informações é peça fundamental para a produção de estudos comparativos e a atuação regulatória baseada em dados e evidências, estando no centro de novas abordagens como *regulação responsiva* e *smart regulation*. Em adição, permite também o reaproveitamento dos dados para fins de pesquisa e de inovação por parte do setor regulado e da indústria aeronáutica, consolidando o protagonismo da superintendência na área de pesquisa e desenvolvimento. A proposição de um modelo de dados baseado em grafos pode promover a construção de padrões descritivos dos metadados relevantes de forma ampla e, em concomitância, contemplar as especificidades da área normativa, de modo a permitir uma maior integração e interoperabilidade dos dados disponíveis na superintendência. Propõe-se, assim: 1) reunir num único ambiente informacional os dados e relacionamentos sobre os normativos de aeronavegabilidade, visando a sua fácil recuperação; e 2) desenvolver um fluxo para as informações regulatórias de modo a garantir a sua interoperabilidade e preservação. Diante da adoção de desta abordagem, foram observadas diversas ferramentas para a construção de um protótipo com grafos de conhecimento, sendo selecionadas para comparação as que seguem. ***Tabela 11 - Relacionamento - Análise comparativa*** ```csvpreview {header="true"} Critérios,Kumu.io,GraphCommons Usabilidade para prototipação,Fácil manuseio,Fácil manuseio Organização de Dados,Gráfico e Textual,Gráfico e textual Custo de implementação,Baixo,Alto Interoperabilidade,Alto acoplamento,Alto acoplamento Performance do sistema de busca,Alta,? Escalabilidade,Alta,? Autonomia do usuário,Alta,? Disponibilidade,Externa ou ANAC (mediante contratação),Externa Manutenibilidade,Fácil,Difícil Expressividade semântica,Alta (não hierárquico),Alta (não hierárquico) Formato de metadados,Linguagem natural,Linguagem natural ou vocabulário controlado automatizado Portabilidade,Alta,Alta Proximidade do RGL,Baixa,Baixa ``` > Nota: os critérios marcados com `?` precisam de dados de partida para serem avaliados. Estes poderão ser compreendidos após a construção do protótipo inicial. Informa-se, por fim, que a conversão de uma base com grafos de uma ferramenta para outra é uma atividade simples, uma vez que estas compartilham de regras similares, qual seja: um conjunto de nós (*elementos*) e um conjunto de arestas (*conexões*), ambos carregados com propriedades (*metadados*). ##### 4.5.1.3 - Discourse x Q2A (foco no aproveitamento de novas fontes de informação) A possibilidade de uso de ferramenta de fórum poderá promover uma evolução do modelo de troca de informações atualmente empregado na SAR. O fórum, enquanto um recurso digital transparente de comunicação assíncrona, traz o potencial de ser uma fonte para a melhoria do processo regulatório como um todo. Durante pesquisa realizada sobre esta possibilidade foi observado o uso de fóruns por organizações públicas e privadas de diferentes portes, como indicado anteriormente na seção *[4.4.3.1 - C\) Abertura de fórum de discussão](#4431-Necessidades-dos-sistemas-pretendidas)*. Ferramentas com essas características proporcionariam: * Compreensão e identificação de temas relevantes para as organizações * Aprendizado conjunto e espaço de troca de experiências, reflexões e informações * Construção de conhecimento de forma assíncrona, por meio da interação entre os participantes * Feedback público, possibilitando o conhecimento da mesma demanda/problema por outros usuários * Informação disponível a qualquer tempo * Espaço de socialização e fortalecimento de relações das partes interessadas * Repositório para distribuição de conteúdos específicos e pesquisas * Lista de avisos e de distribuição * Coleta de dúvidas e informações dos usuários * Meio de documentação e relato sobre o relacionamento das partes com a organização É importante considerar que parte dessas necessidades já são supridas pelos processos de participação social realizados pela superintendência. No entanto, especificamente para os canais de recebimento de dúvidas e sugestões dos regulados, ainda não estão disponíveis ao público ferramentas que facilitem a recuperação de informações. Também se destaca a ausência de um canal sistematizado para a construção conjunta de conhecimento, estando essas ações restritas aos momentos de apresentação pública de propostas de normativos (consultas públicas, palestras, webinários, entre outros). Após a realização desses eventos, até mesmo o resgate organizado dos conteúdos sobre temas de interesse da superintendência não ocorre sem que haja um grande esforço dos usuários. A organização sistematizada destes conteúdos exige ainda um conhecimento prévio dos repositórios de catalogação, como o Pergamum, o Youtube, o Portal de Capacitação ou o Site da ANAC. Neste sentido, a proposta de um fórum digital poderá facilitar a organização coletiva de orientações aos usuários, podendo até mesmo contar com o auxílio do público para a identificação de desafios na compreensão das informação regulatórias mais complexas. Além disso, a adoção de fórum também abriria caminho para a exportação de respostas contidas na base de dados do SEAM, promovendo a interoperabilidade entre os sistemas, alinhada aos desafios identificados por este projeto. Assim, o uso do fórum teria um papel de complemento aos demais canais já existentes de coleta de sugestões e dúvidas. Por outro lado, considerando as características da cultura organizacional da administração pública e os processos comuns desempenhados pelas áreas da superintendência, a adoção deste tipo de ferramenta apresenta alguns desafios a serem enfrentados, por exemplo: * Estabelecimento de regras e políticas de publicação * Estimulo à interação do setor regulado, não acostumado com esse formato de relacionamento com a agência * Estabelecimento de grupo de administradores e moderadores responsáveis por desenvolver a classificação temática e as seções que reúnem assuntos de um mesmo contexto * Identificação e moderação de conteúdos ofensivos Como referência para o gerenciamento dessas necessidades, identificamos na comunidade do Github orientações que podem ser úteis, a saber: * [Gerenciando discussões para sua comunidade](https://docs.github.com/pt/discussions/managing-discussions-for-your-community)[^Github] * Gerenciar discussões no seu repositório * Gerenciar categorias para discussões no seu repositório * Moderar discussões [^Github]:Managing Discussions for your Community. Disponível em: https://docs.github.com/pt/discussions/managing-discussions-for-your-community. Acesso em: 23/03/2021. A própria ferramenta do [Github Discussions](https://docs.github.com/pt/discussions) também poderia servir de protótipo para o fórum. No entanto, dado o foco da ferramenta em desenvolvimento de software e o ambiente organizacional da ANAC, a equipe do projeto entendeu que as ferramentas abaixo são alternativas mais compatíveis: ***Tabela 12 - Fórum - Análise comparativa*** ```csvpreview {header="true"} Critérios,Discourse,Q2A Usabilidade para prototipação,Fácil,Difícil Custo de implementação,Médio,? Performance do sistema de busca,Alta,? Escalabilidade,Alta,? Autonomia do usuário,Alta,? Disponibilidade,ANAC,ANAC Necessidade de customização,Baixa,Alta ``` > Nota: os critérios marcados com `?` precisam de instalação e testes para serem avaliados. Estes poderão ser compreendidos após a construção do protótipo inicial caso o sistema escolhido não seja adequado. ### 4.6 Etapa 6 - Recomendação do Estudo Com base na discussão feita na seção 4.5 recomenda-se o início de fase de prototipação de: * Mediawiki + MKDocs; * Kumu + comparação do resultado com abordagem teórica do uso de GraphCommons; * Discourse + comparação do resultado com abordagem teórica do uso de Q2A . Além disso, entende-se como oportuno o início do desenvolvimento de: * Direcionador de busca de material acadêmico; * Revisão de processo de *policy file* visando abertura para público externo; * Criação de base de dados para captura de discussões informais; * Mapeamento de informações a serem sistematizadas entre as coordenadorias da SAR. Para tanto recomenda-se a confirmação de priorização de frentes de trabalho e o desmembramento do projeto em subprojetos com a devida alocação de recursos e planejamento a serem definidos após validação deste relatório. ## 5. CONCLUSÃO Por meio de processo de tomada de subsídios apontado na seção 4.1, foi feita uma estruturação de problema conforme seção 4.2, com o intuito de direcionar o tratamento das principais causas mapeadas. Dentre as causas identificadas entendeu-se como oportuno tratar as consideradas como principais (agrupadas em 6 categorias), também constante na seção 4.2 deste relatório. Na sequência, destaca-se em 4.2.2, a importância de serem consideradas boas práticas de gestão de dados na web, que podem ser consideradas como ponto decisivo para uma melhoria sustentável de tal prática na SAR, assim como na Agência como um todo. Além disso, em 4.3 foram selecionados os objetivos em um nível macro para balizamento do processo de análise de alternativas, incluindo uma relação de necessidades de negócios para uma efetiva gestão de dados e informações. No intuito de criar e identificar alternativas de solução, entendeu-se como adequado trabalhar com duas abordagens, conforme 4.4.2.1 e 4.4.2.2, respectivamente, *proposição de ferramentas de TI* e *melhorias de processos*. Para isso, foram identificadas frentes de trabalho (4.4.3) no intuito de direcionar de maneira organizada a identificação de alternativas de solução. Visando o atendimento das frentes de trabalho levantou-se, em 4.4.3.1, necessidades de sistemas a serem tratadas por meio de recomendação do grupo de trabalho. Para cada uma das seis necessidades de sistemas consideradas foi feita uma análise de *impacto x esforço de implementação* (tabelas 04 a 09), o que reforçou o entendimento de sua aplicabilidade. Na sequência, foi feito um agrupamento, seguido de uma etapa comparativa de alternativas, com cobertura de tais necessidades de sistemas identificadas, conforme seção 4.5. Ainda na seção 4.5, para a viabilização de implementação partiu-se para a discussão de ferramentas de TI e melhorias de processos (tabelas 10 a 12). Chegou-se à recomendação contida em 4.6 que aponta o entendimento de que seria oportuno partir para uma fase de prototipação, no que tange as abordagens mais complexas (sistemas de criação de conteúdo, grafos e fórum), seguido de uma fase já de implementação das demais ações mapeadas, o que inclui avaliação de melhorias de processos da SAR no contexto de gestão de dados e informações. Para tanto, em termos de alocação de recursos necessários, entende-se como adequado que seja avaliada a possiblidade de dividir a etapa de prototipação e implementação em projetos individualizados com novo recrutamento de equipe com base em necessidades específicas para cada entrega pretendida. Com isso, há as seguintes etapas a serem seguidas: * Teste de conjuntos recomendados em 4.6; * Validação de alternativa testada com gestores da SAR; * Descrição de produto para desenvolvimento e contratação de TI, se necessário; * Direcionamento para melhorias de processo visando integração de dados. Como resultado do estudo realizado e após a primeira fase de prototipação, pretende-se a avaliação da seguinte segmentação da iniciativa para planejamento da implementação: * Projeto A1 = Prototipação de Base de dados + Busca + interfaces; * Projeto A2 = Levantamento e padronização de fontes de dados - Projeto piloto (GTNI); * Projeto A3 = Implementação de fórum com integração das informações do SEAM (desejável); * Projeto A4 = Interface eletrônica para a promoção de busca a material acadêmico; * Projeto A5 = Repositório de discussões técnicas (informais); * Projeto A6 = Proposta de evolução do processo de *Policy File*. Considerando o contexto de facilitação do processo de interpretação de requisitos, com o prosseguimento deste projeto entende-se que há a possibilidade de mudança positiva na SAR. Nesse sentido, ao partir para uma abordagem mais integrada de gestão de dados, aumenta-se o potencial de facilitação de ações de inteligência tendo por ponto inicial o desenvolvimento de normativos, mas influenciando também os demais processos meio e finalísticos da SAR. Assim, as ações propostas ao propiciarem acesso facilitado e de qualidade às informações dos objetivos de requisitos, propicia uma maior produtividade na execução de processos da SAR, além de um maior engajamento no que tange as ações de criação de dados organizados. Diante do exposto, a Figura 11 apresenta uma esquematização do resultado pretendido. A qual indica que o processo de discussão e interpretação dos objetivos dos requisitos de aeronavegabilidade passaria a contar com uma estrutura de dados e informações de maneira organizada e com interfaces com o público interno e externo à SAR. * _**Figura 11 - Sistema teórico proposto**_ ![](https://i.imgur.com/ffnf9eM.jpg) Fonte: Esquematizada pelo GT Finalmente, sugere-se validação da conclusão deste estudo visando confirmação para o inícios dos próximos passos, que seriam: 1. internalização das melhorias propostas; 1. atualização do cronograma e recursos referentes às próximas etapas do projeto(s); 1. disseminação das ações aos servidores e agentes impactados. ## 6. BIBLIOGRAFIA CONSULTADA