sexta-feira, 17 de novembro de 2017

Modelagem de processos além da BPMN

No último post falei sobre processos de negócio que não se enquadram no modelo mais conhecido da “Cadeia de Valor”, proposto pelo Michael Porter. Apresentei como umas das alternativas o modelo “Escritório de Valor”, o qual descreve organizações que criam valor resolvendo problemas de seus clientes através da promoção de mudanças que levam o cliente de um “estado atual” para um “estado futuro” desejado.

Neste modelo, considera-se que os processos são mais flexíveis e a sequência de execução de suas atividades não está pré-determinada. Esse tipo de processo é frequentemente chamado de “Gestão de Casos” e será o assunto deste post.

Para facilitar o entendimento, usarei como exemplo um processo administrativo genérico simplificado cujo modelo convencional é mostrado na figura a seguir:

Considerem as atividades marcadas “Verificar conteúdo” e “Completar conteúdo”. Na primeira, o executante analisa o conteúdo da documentação apresentada e identifica se existem falhas e inconsistências que impeçam a continuação normal do processo. Caso existam, executam-se na segunda atividade as ações necessárias para reparar os problemas identificados e permitir o prosseguimento do processo ou decidir por sua rejeição.

Dependendo da complexidade do processo e da documentação envolvida, as atividades não são executadas na forma simplificada, mostrada no diagrama, mas através da realização de uma série de ações pontuais interdependentes que são acionadas na medida em que vão sendo identificados os problemas. A identificação e acionamento dessas ações corretivas pode acontecer de forma concorrente com a verificação, ou seja, o executante não espera finalizar a verificação, mas a cada falha identificada, decide pela execução imediata de uma ou mais ações corretivas. Assim, a decisão de executar algumas ações acontece somente no momento do seu acionamento. Os responsáveis por estas atividades não tem apenas um papel de executar atividades previamente ordenadas, eles assumem a responsabilidade por alcançar o objetivo do processo e tem autonomia para decidir como e quando utilizar os recursos disponíveis e possíveis.

Resumindo, no exemplo as ações a serem executadas e a sequência em que são executadas não estão completamente definidas previamente. Nessa situação, a modelagem usando uma notação convencional (ex.: UML, EPC, BPMN, etc.), que definem como deve ser executado o processo com base em diagramas de sequenciamento de atividades, tende a produzir modelos que são exageradamente simplificados ou complexos, dado que o conjunto de ações efetivamente executadas e seu sequenciamento somente será completamente definido quando da execução de cada caso.

Esse tipo de situação é melhor tratada por modelos baseados no conceito de Gestão de Casos”, onde o foco de modelagem está no que pode ser feito, ou seja, na identificação das atividades que podem ser realizadas para resolver o caso e das informações que devem ser produzidas ou estar disponíveis para uso pelos executantes. E foi para contemplar de forma mais adequada essas características que a OMG (Object Management Group) propôs o padrão de notação gráfica CMMN (Case Management Model and Notation).

No padrão CMMN o fluxo do processo não está definido completamente no modelo. O controle do fluxo é exercido pelos executantes do caso, que podem tomar decisões que não foram explicitadas previamente no modelo. O modelo CMMN é do tipo declarativo, define o que pode ser aplicado ao caso, mas não impõem o como deve ser feito. E regras podem ser declaradas definindo o que pode ou não pode ser feito dependendo do estado do caso.

Seguindo nosso exemplo, mostramos na figura abaixo uma versão de modelo CMMN para as atividades “Verificar conteúdo” e “Completar conteúdo”:

No diagrama CMMN, o principal elemento é a Pasta do Caso, que contém tudo sobre o caso, ou seja, que atividades podem ser executadas e todas as informações disponíveis sobre o caso. Esse conteúdo é representado através de diversos elementos gráficos: atividades, etapas, marcos, eventos, etc.

No nosso exemplo, identificamos a Pasta do Caso como “Verificar documentos” e incluímos um conjunto de 5 atividades que representam as diversas ações que podem ser executadas: “Verificar validade”, “Receber complemento”, “Solicitar parecer”, “Rejeitar documentos” e “Comunicar necessidade de complemento”.

As atividades marcadas com uma figura humana identificam atividades simples a serem executadas por pessoas. O símbolo da “Mão” identifica uma delegação, um tipo de atividade que não bloqueia o Caso, ou seja, o Caso pode ser encerrado mesmo que esta atividade ainda não tenha sido executada. A borda tracejada identifica que “Rejeitar documentos” é uma atividade opcional, prevista no modelo, mas acionada por decisão do responsável pela Pasta do Caso.

Não cabe aqui uma descrição detalhada dos artefatos e opções de modelagem da notação CMMN, vamos apenas destacar algumas de suas características e diferenças mais relevantes em relação às notações mais conhecidas:
  • Nem tudo que pode ser feito precisa ser previamente especificado no modelo. Por exemplo, a interação dos executantes com os dados do caso geralmente não é modelada em detalhe, mas considera-se que dados e documentos podem ser inseridos e atualizados a qualquer momento durante a execução do caso;
  • Na notação CMMN a execução das atividades não segue uma ordem pré-definida, ou seja, não existe um fluxo de execução pré-definido. O responsável pelo Caso define qual a próxima atividade a ser executada. Mas é possível definir regras que condicionam quando que uma atividade está disponível para execução.
  • Todas as informações do Caso podem ser atualizadas a cada momento, não apenas aquelas diretamente associadas à atividade sendo executada. Ou seja, qualquer informação do processo pode ser registrada assim que disponível, não apenas em atividades específicas;
  • O modelo CMMN pode parecer menos intuitivo que um modelo convencional, pois não dá para seguir visualmente o fluxo de execução;
  • A maior liberdade na execução das atividades implica em uma maior responsabilidade dos participantes do Caso que, em geral, precisam ter maior conhecimento e iniciativa do que os participantes de processos mais controlados;
  • Existem diversos artefatos que podem ser incluídos como itens adicionais na Pasta do Caso, como por exemplo:
    • Marco - representa uma realização relevante alcançada durante a execução do caso e que facilita a identificação de progresso do caso. No diagrama é representado por uma elipse achatada;
    • Etapa - representa um subconjunto do caso, similar ao subprocesso da notação convencional. Geralmente é usada para controlar a complexidade do modelo facilitando sua decomposição em conjuntos menores. No diagrama é representado por um retângulo envolvendo os itens contidos;
    • Dados - representa itens de informação que podem ser manipulados na execução do caso. Pode ser uma base de dados, um documento, arquivos de vídeo ou aúdio, etc. No diagrama é representado por um ícone de documento;
    • Condições - permitem definir quando um item da Pasta deve estar disponível para uso, servindo como um critério de entrada, ou quando o item deve ser encerrado (critério de saída). No diagrama são representadas como losangos afixados na borda do item;
  • Como exemplo, mostramos na figura abaixo uma versão do nosso exemplo enriquecido com alguns artefatos adicionais:
    • A atividade “Comunicar necessidade de complemento” somente estará disponível para execução se for atendida determinada condição definida na atividade “Verificar validade”;
    • A atividade “Verificar validade” produz dois marcos do caso: “Documentos analisados” e “Verificação encerrada”, sendo que este último é condição para o encerramento do Caso;

Finalmente, tendo sido definida mais recentemente, a notação CMMN prevê a possibilidade de integração com modelos nas notações BPMN e DMN, possibilitando a modelagem de processos que combinam as características dessas três notações. Mas este é assunto para um próximo post.

Para quem interessar, seguem duas referências relevantes:


quinta-feira, 16 de novembro de 2017

As nove Visões do FACIN – Parte 5 – Aplicações

 Por: Alexandre Coutinho

Olá!

No artigo anterior abordamos a Visão de Negócios do Framework de Arquitetura Corporativa para Interoperabilidade no Apoio à Governança (FACIN). Neste 5º artigo dessa série trataremos da Visão de Aplicações.

Esta Visão do FACIN descreve o conjunto de elementos de software que permitam a produção, armazenamento, transmissão, acesso, segurança e o uso e intercâmbio das informações dentro do contexto de execução dos processos de negócios das organizações governamentais. No nível do Governo como um todo, esta Visão estabelece modelos, artefatos e guias comuns como forma de promover uma uniformização do conhecimento e fortalecer o compartilhamento, consolidação e reuso de aplicações que suportam os serviços de TIC. No nível das organizações governamentais, esta Visão descreve os ativos de aplicações de apoio à gestão interna e ao portfólio de serviços de TIC entregues.

Estes elementos, a relação entre eles e os artefatos, diretrizes, políticas e padrões associados, devem ser utilizados como base para todas as organizações governamentais desenvolverem e gerirem sua arquitetura de aplicações e serviços de TIC.

O estabelecimento dessa Visão provê uma visão unificada e Inter organizacional das aplicações e serviços de TIC e das oportunidades de compartilhamento destes ativos, fortalecendo a adoção dos padrões ePing que visam promover a padronização da comunicação e interoperabilidade entre as organizações governamentais através do uso de TIC. Dessa forma, apoia as organizações governamentais a gerirem aspectos de eficiência, eficácia e evolução contínua das suas aplicações e serviços de TIC tanto em nível global, como também servindo como base para guiar as iniciativas individuais de cada uma, orientadas ao desempenho na prestação de serviços à sociedade.

O Modelo Conceitual de Referência de Aplicações provê uma apresentação dos conceitos necessários à representação das aplicações de uma organização governamental. Quando associado às outras visões, provê também a rastreabilidade do alinhamento das ações de investimentos em aplicações em relação aos objetivos estratégicos e consequentes demandas por processos, serviços e gestão de dados e informações. Os principais conceitos envolvidos na Visão de Aplicações são apresentados na figura abaixo e descritos na sequência.

  • Componente de Aplicação: Representa uma unidade independente e implantável de software que encapsula um comportamento bem definido através de suas funções e os expõe através de um conjunto de serviços para suportar um processo de negócio. Ex.: Aplicação Financeira, ERP, CRM.
  • Função da Aplicação: Representa um comportamento automatizado que é realizado por um componente de aplicação. Ex.: Realizar Faturamento, Cobrar multa, Analisar CPF.
  • Serviço de aplicação: Representa um comportamento explicitamente exposto ou consumido por uma função de aplicação para o ambiente externo (usuários ou outros componentes de aplicação). Ex.: Recupera nota fiscal, Calcula valor a pagar, Consulta CPF.
Para a entrega dos produtos e serviços baseados em Aplicações de TI, com a maior eficiência e eficácia, é necessário que a Visão de Aplicações esteja totalmente alinhada às demais visões definidas na arquitetura corporativa da organização ou mesmo com a de outros órgãos. O diagrama abaixo mostra os principais fluxos de requisitos que são consumidos e gerados por esta Visão.



A figura não mostra todas as relações permitidas: cada elemento pode ter relações de composição, agregação e especialização com elementos do mesmo tipo. Além disso, há relações indiretas que podem ser derivadas.

A fim de operacionalizar e gerir a Visão de Aplicações, o FACIN sugere, mas não limita, que as organizações devam adotar ao menos os seguintes papéis:
  • Alta Administração/Direção da organização governamental: Responsáveis pela governança da organização;
  • Alta Gestão da organização governamental: Responsáveis por definir os objetivos e serviços aplicáveis ao seu contexto, com base nas metas estabelecidas dentro do planejamento do Governo como um todo e do papel exercido por sua organização em particular;
  • Gestores intermediários da organização governamental: Responsáveis diretamente por metas específicas definidas dentro da Visão de Dados de sua Organização;
  • Arquitetos de aplicações e serviços da organização governamental: Responsáveis pela definição e evolução da Arquitetura de Aplicações estabelecida na Organização. Devem apresentar aos gestores intermediários da organização os planos de mudança da arquitetura para a incorporação de novos serviços e melhorias dos serviços a seus usuários;
  • Equipes de operação e suporte: Responsáveis pela operação contínua e ininterrupta dos serviços oferecidos pela arquitetura e sua monitoração. Devem reportar aos arquitetos de aplicações as necessidades de modificações necessárias para a performance adequada do ambiente;
  • Usuários de serviços de TI: Pessoas ou organizações que são o objeto final para a definição adequada dos elementos de arquitetura que permitam oferecer os serviços, da melhor forma possível.
Um importante ponto a ser considerado na Visão de Aplicações, principalmente para permitir a interoperabilidade, o reuso e o consumo de aplicações de maneira mais eficiente, diz respeito ao estabelecimento de uma taxonomia para a categorização de aplicações. A padronização através de uma taxonomia unificada provê uma forma para que todas as organizações governamentais descrevam os seus ativos de aplicações.

A ilustração abaixo demonstra os principais componentes da Taxonomia de Referência para Aplicações. As camadas são descritas a seguir:


  • Domínio de Aplicações: Representam os domínios de aplicações em alto nível. Exemplos de domínios são:
    • Aplicações Corporativas: São as soluções de software que proveem funcionalidades que suportam os processos e as necessidades de negócio das organizações governamentais;
    • Aplicações de TIC: Proveem os pacotes de software básicos necessários para a adequada execução das Aplicações Corporativas ou de Negócio , bem como a interação com as demais Visões do FACIN.
  • Categoria de Aplicações: Representam as categorias de cada Domínio. Exemplos de categorias são: 
    • Para o Domínio Aplicações Corporativas:
      • Sistema de colaboração;
      • Sistema de gestão de relacionamento com clientes;
      • Sistema de gestão de relacionamento com fornecedores;
      • Sistema de gestão de recursos humanos.
    • Para o Domínio Aplicações de TIC:
      • Sistemas de provimento de serviços WEB;
      • Sistemas de provimento de serviços de desenvolvimento;
      • Sistema de gerenciamento de Aplicações;
      • Sistemas de serviços de email.
  • Tipo de Aplicações: Representam os tipos específicos de aplicações que podem existir em cada categoria. Exemplos de tipos de aplicações são:
    • Para Sistemas de serviços de BI:
      • Data Warehouse;
      • Gestão de conhecimento.
    • Para Sistemas de provimento de serviços de desenvolvimento:
      • Frameworks de desenvolvimento; 
      • Gestão de configuração;
      • Ferramentas CASE.
    • Para Sistemas de segurança:
      • SSL, SSH, Controle de acesso em rede.
A seguir são apresentados os referenciais de métodos e melhores práticas utilizados para a construção da Visão de Aplicações do FACIN, pelas Organizações:
  • ISO/IEC 38500 Information Technology - Governance of IT - for the Organization (http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=62816) 
  • The Open Group TOGAF (https://www.opengroup.org/togaf/) 
  • ISO/IEC/IEEE 42010:2011 Systems and software engineering -- Architecture description (http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=50508) 
  • Guia de PDTIC do SISP (www.sisp.gov.br/guiapctid/wiki/Documento ).
Quer fazer parte da construção desse Framework e ajudar a melhorar a disponibilização de produtos e serviços de governo para a sociedade? Deixe aqui as suas percepções!

No próximo artigo apresentaremos a Visão de Dados. Aguarde!

quinta-feira, 9 de novembro de 2017

O FACIN na prática com o Projeto GEO - Parte 8

No post anterior abordamos o detalhamento da visão Infraestrutura com a aplicação da dinâmica de Análise de Cenário utilizada na Oficina ABEP-FACIN, realizada pelo Serpro em parceria com a Associação Brasileira de Entidades Estaduais de Tecnologia da Informação e Comunicação (ABEP).
A dinâmica compreende as atividades de identificação do problema, modelagem, análise e construção dos cenários atual e proposto (solução do problema).
Na PRODEMGE o cenário utilizado foi a implantação de uma solução corporativa de geoprocessamento no Estado de Minas Gerais, aqui identificada apenas como Projeto GEO.
Nesta postagem abordaremos o detalhamento da visão Segurança do Projeto GEO utilizando o Framework de Arquitetura Corporativa para Interoperabilidade no Apoio à Governança (FACIN), conforme figura 1.

Figura 1: Detalhamento da visão Segurança do Projeto GEO

A Política de Segurança - Risco está plenamente alinhada ao The Open Group Standard for Risk Taxonomy (O-RT), versão 2.0. É uma versão atualizada do Padrão de Taxonomia de Risco (Doc. No. C081) que foi publicado em janeiro de 2009, figura 2.

O documento fornece a seguinte definição padrão de taxonomia para o risco de segurança da informação:

Este Padrão de Taxonomia de Risco deve ser usado como uma referência fundamental do espaço do problema que a profissão é encarregada de ajudar a gerenciar; isto é, risco. Com base nesta base, métodos para análise, cálculo, comunicação e gerenciamento de risco podem ser desenvolvidos.

Os analistas de risco podem escolher fazer suas medidas e/ou estimativas em qualquer nível de abstração dentro da taxonomia. Por exemplo, ao invés de medir a Frequência de Contato (CF), o analista poderia subir uma camada de abstração e, em vez disso, medir a Frequência do Evento de Ameaça (TEF). Essa escolha pode ser conduzida pela natureza ou volume de dados disponíveis, ou o tempo disponível para realizar a análise (ou seja, as análises em camadas mais profundas de abstração demoram).

Embora os termos "risco" e "gerenciamento de riscos" signifiquem coisas diferentes para pessoas diferentes, este Padrão pretende ser aplicado ao problema de gerenciar a frequência e a magnitude da perda que decorrem de uma ameaça (seja humano, animal ou evento natural). Em outras palavras, gerenciar "a frequência com que as coisas ruins acontecem e o quão ruim elas são quando ocorrem".

Figura 2: Política de Segurança ORT- visão Segurança

No contexto geral da gestão de riscos, é importante reconhecer que o objetivo do negócio em realizar avaliações de risco é identificar e estimar níveis de exposição à probabilidade de perda, de modo que os gerentes de negócios possam tomar decisões sobre como gerenciar esses riscos de perda - aceitando cada risco ou mitigando-o - investindo em medidas de proteção interna apropriadas julgadas suficientes para reduzir a perda potencial a um nível aceitável ou investindo em indenização externa. Crítico para permitir uma boa tomada de decisões empresariais é, portanto, usar métodos de avaliação de risco que ofereçam resultados objetivos, significativos e consistentes.

Um desses métodos pode ser obtido através da norma ISO/IEC 38500:2009, ilustrado na figura 3, que é reconhecido pelo mercado e considerado como uma das melhores práticas da Gestão de Riscos.
Figura 3: Gestão de Risco

O Processo de Gestão de Riscos é composto pelos seguintes Subprocessos:

·    Estabelecimento do contexto - Captura os objetivos da organização, o ambiente em que ela persegue esses objetivos, suas partes interessadas e a diversidade de critérios de risco.

·      Identificação de riscos - Gera uma lista abrangente de riscos baseada nos eventos que possam criar, aumentar, evitar, reduzir, acelerar ou atrasar a realização dos objetivos;

·      Análise de riscos e Oportunidades - Envolve a apreciação das causas e das fontes de risco, suas consequências positivas e negativas, e a probabilidade de que essas consequências possam ocorrer.

·     Avaliação de risco - A finalidade da avaliação de riscos é auxiliar na tomada de decisões com base nos resultados da análise de riscos, sobre quais riscos necessitam de tratamento e a prioridade para a implementação do tratamento.

·      Tratamento de Risco - Envolve a seleção de uma ou mais opções para mitigar os riscos e a implementação dessas opções. Uma vez implementado, o tratamento fornece novos controles ou modifica os existentes.

A análise de riscos envolve desenvolver a compreensão dos riscos, como no Mapeamento dos Riscos do Ambiente do Produto IDE (Infraestrutura de Dados Espaciais) Corporativa da figura 4.


Figura 4: Mapeamento do Risco do Ambiente do Produto IDE GEO

O mapeamento fornece uma entrada para a avaliação de riscos e para as decisões sobre a necessidade dos riscos serem tratados, e sobre as estratégias e métodos mais adequados de tratamento de riscos.

A análise de riscos envolve a apreciação das causas e as fontes de risco, suas consequências positivas e negativas, e a probabilidade de que essas consequências possam ocorrer. Um evento pode ter várias consequências e pode afetar vários objetivos.

É preciso que os controles existentes e sua eficácia e eficiência também sejam levados em consideração. A forma em que as consequências e a probabilidade são expressas e o modo com que elas são combinadas para determinar um nível de risco refletem o tipo de risco, as informações disponíveis e a finalidade para a qual a saída do processo de avaliação de riscos será utilizada.

Convém que isso tudo seja compatível com os critérios de risco. É também importante considerar a interdependência dos diferentes riscos e suas fontes.

O modelo proposto utiliza-se de dois componentes: elementos e relacionamentos, descritos na tabela 1. As cores dos elementos representam as camadas do ArchiMate e sua respectiva correspondência com o TOGAF.

Tabela 1: Elementos e Relacionamentos da visão Segurança 


Fonte: ArchiMate 3.0 – Um Guia de Bolso

Acesse aqui o detalhamento completo da aplicação da dinâmica de Análise de Cenário, apresentada na Oficina ABEP-FACIN e utilizada pela PRODEMGE, para implantar uma solução corporativa de geoprocessamento no Estado de Minas Gerais, utilizando o FACIN.

No próximo artigo abordaremos o detalhamento das visões Programas e Projetos e Sociedade do Projeto GEO utilizando o FACIN, não percam!


Autores: Ademilson Monteiro, Antonio Plais, Guttenberg Ferreira Passos, Ivanise Cence Lopes, Leonardo Grandinetti Chaves e Sandro Laudares

segunda-feira, 6 de novembro de 2017

Seleção de dados para a publicação de Dados Abertos (Conectados) – parte 2


Por Thiago Ávila*

Dando continuidade à nossa série de artigos sobre Dados Abertos (conectados), vamos continuar apresentando a segunda melhor prática para a publicação de Dados Abertos Conectados, aplicando-os no contexto Governamental. Estes artigos têm como fundamentação a dissertação de mestrado, Uma Proposta de Modelo de Processo para Publicação de Dados Abertos Conectados Governamentais[1], onde desenvolvi uma revisão de literatura que identificou 70 recomendações para a publicação de Dados Abertos Conectados Governamentais, distribuído entre as 10 melhores práticas estabelecidas pelo W3C[12], que estão sendo exploradas em continuidade a esta série de artigos aqui no blog, cuja metodologia apresentei no artigo anterior.

Para identificar recomendações voltadas a implementar a segunda melhor prática, “2. Seleção de Conjuntos de Dados”, foi estabelecida a seguinte questão de pesquisa: “O que os processos de publicação de dados abertos (conectados) recomendam a ser feito para contemplar a melhor prática de Selecionar Conjuntos de Dados?"

Na sequência continuaremos apresentando as recomendações identificadas nos processos que poderão auxiliar a incorporação desta melhor prática em atividades de publicação de dados. Cumpre destacar que no artigo anterior já apresentamos cinco recomendações e neste artigo apresentaremos outras seis, totalizando onze recomendações para esta melhor prática.

A segunda melhor prática (BPLD) estabelecida consiste na seleção dos conjuntos de dados que serão publicados. Segundo o W3C (2014) [12], devem ser selecionados apenas os dados que são catalogados ou criados pela instituição que está implementando o processo de abertura. Preferencialmente, devem ser priorizados dados que, ao serem combinados com outros dados, produzam grande valor.  

2.6. Analisar o nível de sigilo dos dados e informações
É importante ressaltar que, apesar das leis vigentes nas nações recomendarem que o acesso à informação deva ser regra e o sigilo ser aplicado somente em casos excepcionais, há de se considerar que alguns dados governamentais não podem ser abertos por questões como ameaça a defesa nacional, ao desenvolvimento científico e tecnológico, dentre outros. Assim sendo, outra recomendação identificada consiste na análise do nível de sigilo dos dados e informações que podem ser considerados como objeto de abertura e publicação.






O processo da Colômbia (Colombia, 2012) sugere que as organizações estabeleçam os níveis de sigilo dos dados e informações, classificando em: 

  • Dados e informações publicáveis: Aquelas que devem estar à disposição de qualquer pessoa e que o governo é obrigado a disponibilizar, considerando que não há obrigação legal para mantê-las como sigilosa;
  •  Dados e informações não publicáveis: Aquelas que se enquadram como reservadas ou sigilosas conforme os parâmetros legais vigentes;
  • Dados e informações pessoais (semiprivadas): Dados e informações pessoais que não são de domínio público, mas foram obtidas por ordem de uma autoridade administrativa no exercício das suas funções ou no âmbito dos princípios de gestão de dados pessoais. Esta informação pode ou não pode estar sujeito ao sigilo, dependendo do caso.
O processo do Brasil tem como base legal a Lei Brasileira de Acesso a Informação (Lei Federal 12.527/2011) (Brasil:2011) [4] que aborda com clareza os casos e procedimentos para a adoção do sigilo das informações. Segundo o artigo 24 desta lei, a informação pública poderá ser classificada como reservada, secreta ou ultrassecreta e os respectivos prazos para se tornarem públicas são de 5 (cinco), 15 (quinze) e 25 (anos). O artigo 23 da lei estabelece os casos em que as informações devem ser classificadas como sigilosas.

 2.7. Analisar relatórios anuais e documentação existente
O entendimento do contexto organizacional é fator crítico de sucesso num processo de abertura de dados e por este motivo, o processo COMSODE sugere que devem ser localizados e analisados os relatórios anuais (balanços financeiros, relatórios de gestão, avaliação de desempenho e de projetos, etc.) e ainda outros documentos relevantes, incluindo o portal Web, que informem sobre as atividades e principais resultados alcançados da organização publicadora. Devem ser identificadas tabelas e gráficos nestes documentos que orientem sobre potenciais conjuntos de dados para serem abertos e conectados e ainda, deve se identificar quais unidades organizacionais são responsáveis pela sua preparação. Tais informações devem ser devidamente registradas numa relação de dados possíveis para serem abertos e conectados (COMSODE, 2014) [7]. 

Complementarmente, o processo “Methodological Guidelines” sugere que devem ser identificados ainda a documentação e os esquemas dos dados que serão objetos de publicação (quando houverem), bem como suas propriedades, relações, sistemas de informação geradores destes dados e arquiteturas Web (Villazon-Terrazas, 2011) [11]. 

2.8. Analisar o esforço para abertura de dados
Ademais, para que a publicação de dados seja exitosa e factível, o processo P14 ainda sugere que seja analisado o esforço de abertura de cada conjunto de dados. A análise de esforço deverá ser realizada a partir da priorização dos dados a serem publicados podendo, inclusive, resultar numa nova priorização, caso os dados inicialmente destacados para iniciarem o projeto de abertura tenham complexidade e demandem esforço muito alto (COMSODE, 2014) [7].
 
2.9. Fazer e validar mapa de responsabilidades entre conjuntos de dados e unidades de negócio responsáveis
Outra recomendação destacada pelo processo COMSODE consiste na criação de um mapa de responsabilidades entre os conjuntos de dados a serem publicados e respectivas unidades de negócio responsáveis, sendo este mapa graficamente representado. Especialmente, caso a unidade de negócio dependa do apoio de outra unidade, deve ficar explicitado às responsabilidades. Por exemplo, uma unidade de negócio que realiza e publica informações tabulares sobre o desempenho escolar pode depender de outra unidade de negócio para georreferenciar estes dados. Ademais, a relação de conjuntos de dados e o mapa de responsabilidades deve ser discutido e validado com pessoas que tenham poder de decisão sobre a publicação de dados (COMSODE, 2014) [7].

 2.10. Identificar e analisar sistemas de informação que poderão ser objeto da abertura de dados
A análise e identificação dos principais sistemas de informação da organização e os principais conjuntos de dados gerenciados por estes sistemas representa outra recomendação relevante, de acordo com o processo COMSODE (COMSODE, 2014) [7]. O processo do Brasil complementa sugerindo que seja estabelecida uma arquitetura para abertura de dados a partir de cada sistema de informação identificado (Brasil, 2014) [3].

Outro item sugerido consiste na análise se as fontes dos dados são Datawarehouses. De acordo com o processo “Geolinked Open Data for the Municipality of Catania”, quando for o caso, destacar a necessidade da construção de rotinas de extração/conversão destes dados ao iniciar o processo de publicação, devendo os descritores dos dados ser traduzidos para o idioma inglês ou o idioma nativo do país, quando aplicável (Consoli, 2014) [8].



 
2.11. Identificar dados que podem ser conectados
Além da identificação dos dados que serão abertos, sugere-se que sejam identificados os dados que tem potencial para serem conectados com menor esforço. Quando se tratar de um enriquecimento e reuso de dados já abertos e publicados por exemplo, devem ser procurados dados similares e relacionados (que possam se conectar ao dado que será publicado) em outros catálogos governamentais, como sugerido pelo processo “Methodological Guidelines” (Villazon-Terrazas, 2011) [11]. É destacado que o êxito desta atividade está relacionada com a recomendação de identificar a documentação e os esquemas dos dados que serão publicados, bem como suas propriedades, relações e arquiteturas Web. Outros autores, também destacam a identificação destes requisitos, entretanto, na etapa posterior, de modelagem dos dados.

No próximo artigo desta série, veremos outras seis recomendações para a seleção de dados para a publicação de Dados Abertos Conectados.

Até a próxima!!!

* Este artigo foi desenvolvido a partir da pesquisa de Mestrado “Uma Proposta de Modelo de Processo para Publicação de Dados Abertos Conectados Governamentais”, de autoria de Thiago José Tavares Ávila, no âmbito do Programa de Pós-Graduação em Modelagem Computacional do Conhecimento, do Instituto de Computação da Universidade Federal de Alagoas (UFAL).

[1] ÁVILA, T. J. T. Uma proposta de modelo de processo para publicação de dados abertos conectados governamentais. 223 p. Dissertação (Mestrado) — Instituto de Computação, Universidade Federal de Alagoas, Maceió, Alagoas, Brasil, 2015. Dissertação de Mestrado em Modelagem Computacional do Conhecimento.
[2] BERNERS-LEE, T. Linked Data. 2006. Disponível em: 
<http://www.w3.org/DesignIssues/LinkedData.html>.
[3] BRASIL. Manual para Elaboração de Plano de Dados Abertos. [S.l.], 2014. v. 7, 38 p. Disponível em: <http://www.planejamento.gov.br/secretarias/upload/Arquivos/governoáberto/manual_elaboracao_plano_dados_abertos.pdf>.
[4] BRASIL. Lei No 12.527, de 18 de Novembro de 2011. 2011. Disponível em:
<http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2011/lei/l12527.htm>.
[5] CHILE. Norma Técnica para Publicación de Datos Abiertos en Chile.
[S.l.], 2013. 1-28 p. Disponível em: 
< http://instituciones.gobiernoabierto.cl/NormaTecnicaPublicacionDatosChile_v2-1.pdf>.
[6] COLOMBIA. Guía para la apertura de datos en Colombia. [S.l.], 2012. 67 p. Disponível em: 
< http://programa.gobiernoenlinea.gov.co/apc-aa-files/da4567033d075590cd3050598756222c/Datos_Abiertos_Guia_v2_0.pdf >.
[7] COMSODE. Methodology for publishing datasets as open data - COMSODE. [S.l.], 2014.1-31 p. Disponível em: <http://www.comsode.eu/index.php/deliverables/>.
[8] CONSOLI, S. et al. Geolinked Open Data for the Municipality of Catania. Proceedings of the 4th International Conference on Web Intelligence, Mining and Semantics (WIMS14), p. 58, 2014.
[9] ECUADOR. Guia de Política Pública de Datos Abiertos. [S.l.], 2014. 21 p. Disponível em: <http://www.gobiernoelectronico.gob.ec/wp-content/uploads/2014/12/GPP-DA-v01-20141128-SNAP-SGE.pdf>.
[10] OKF. Guia de Dados Abertos. 2015. Disponível em: <http://opendatahandbook.org/guide/pt_BR>.
[11] VILLAZÓN-TERRAZAS, B. et al. Methodological guidelines for publishing government linked data. Linking Government Data, p. 27-49, 2011.
[12] W3C. Best Practices for Publishing Linked Data. 2014. Acessado em 02/05/2017. Disponível em: <http://www.w3.org/TR/ld-bp/>.
[13] URUGUAY. Guía rápida de publicación em datos.gub.uy. Montevideo, 2012.
17 p. Disponível em: 
< https://www.agesic.gub.uy/innovaportal/file/2478/1/guia_publicacion_datos_abiertos.pdf>.

quinta-feira, 26 de outubro de 2017

O FACIN na prática com o Projeto GEO - Parte 7

No post anterior abordamos o detalhamento da visão Dados com a aplicação da dinâmica de Análise de Cenário utilizada na Oficina ABEP-FACIN, realizada pelo Serpro em parceria com a Associação Brasileira de Entidades Estaduais de Tecnologia da Informação e Comunicação (ABEP).
A dinâmica compreende as atividades de identificação do problema, modelagem, análise e construção dos cenários atual e proposto (solução do problema).
Na PRODEMGE o cenário utilizado foi a implantação de uma solução corporativa de geoprocessamento no Estado de Minas Gerais, aqui identificada apenas como Projeto GEO.
Nesta postagem abordaremos o detalhamento da visão Infraestrutura do Projeto GEO utilizando o Framework de Arquitetura Corporativa para Interoperabilidade no Apoio à Governança (FACIN), conforme figura 1.
Figura 1: Detalhamento da visão Infraestrutura do Projeto GEO

Podemos observar que a função de ”Geração e atualização e dados geoespaciais” é a principal entidade que define o serviço de “Desenvolvimento e manutenção do ambiente de dados geoespacais”.

A infraestrutura que suporta esse serviço de aplicativo é composta por ambientes de desenvolvimento e produção, os quais permitem a criação de diferentes mapas temáticos, formados por camadas sobrepostas de dados geoprocessados.

Permitem, também, a formulação de pesquisas e consultas sobre a localização, fotos e outras informações dos órgãos do Estado, referenciadas geograficamente.

O “Portal de Geoprocessamento” é um ambiente suportado pelo ArcGIS GEO e composto por servidores de aplicação, serviços e bando de dados, cuja principal função é o “Visualizador de camadas”.

Observa-se que o GEO.MG é a interface do Portal de Geoprocessamento que generaliza as interfaces para cada grupo de camadas a que o usuário tem acesso.

O usuário final é a população em geral que terá acesso à aplicação via internet. O sistema é baseado na Arquitetura Internet (WEB), onde a aplicação do cliente ficará no Servidor WEB GEO P01, que terá acesso direto ao servidor de banco de dados PostgreeSQL GEO P01.

A figura 2 ilustra a relação entre as camadas de aplicação e infraestrutura da IDE de Geoprocessamento.


Figura 2: IDE de Geoprocessamento - visão Infraestrutura

O Plano Diretor de Tecnologia da Informação e Comunicação – PDTIC do Estado de Minas Gerais diz:

“Enquanto a governança de TIC é o sistema pelo qual a atual e a futura utilização da TIC é dirigida e controlada, envolvendo avaliar e direcionar a utilização de TIC para apoiar o órgão e o acompanhamento deste uso para realizar planos, incluindo a estratégia e as políticas de utilização de TIC dentro de um órgão, a gestão de TIC é responsável pelo planejamento, desenvolvimento, execução e monitoramento das atividades de TIC em consonância com a direção.”

Para tanto o modelo de Governança de TIC atualmente em prática no Estado foi avaliado considerando modelos de referência do Control Objectives for Information and Related Technologies (COBIT 5) e a norma ISO/IEC 38500:2009. O modelo segue as recomendações e boas práticas de mercado.

Diante disto a figura 3 ilustra a aplicação dessas boas práticas através dos processos de governança e gestão priorizados pela Prodemge.

Figura 3: Governança de TI - COBIT 5

A aplicação na Prodemge das boas práticas de governança e gestão, em relação às atividades recomendadas pelo COBIT 5, estão perfeitamente alinhadas às atividades desempenhadas pelas pessoas nas diversas áreas da empresa e mapeadas no Plano de Capacidade TDABC Model.

As atividades mapeadas são disponibilizadas para toda a empresa, em consonância com a nossa política de Gestão do Conhecimento, através da plataforma de EAD -  Modelo de Responsabilidade Organizacional, conforme ilustrado na figura 4.


Figura 4: Plataforma EAD - MRO - visão Infraestrutura

O ambiente de Produção EAD é suportado por servidores de aplicação e banco de dados MYSQL, cuja principal função é o compartilhamento e o armazenamento da documentação das funções de Plano de Capacidade, Otimização da Produtividade e Experiência dos Empregados.

O próximo passo é preparar a infraestrutura para suportar o ambiente do Repositório de arquivos na plataforma DSPACE.

O modelo proposto utiliza-se de dois componentes: elementos e relacionamentos, descritos na tabela 1. As cores dos elementos representam as camadas do ArchiMate e sua respectiva correspondência com o TOGAF.

 Tabela 1: Elementos e Relacionamentos da visão Infraestrutura



Fonte: ArchiMate 3.0 – Um Guia de Bolso

Acesse aqui o detalhamento completo da aplicação da dinâmica de Análise de Cenário, apresentada na Oficina ABEP-FACIN e utilizada pela PRODEMGE, para implantar uma solução corporativa de geoprocessamento no Estado de Minas Gerais, utilizando o FACIN.

No próximo artigo abordaremos o detalhamento da visão Segurança do Projeto GEO utilizando o FACIN

Autores: Ademilson Monteiro, Antonio Plais, Guttenberg Ferreira Passos, Leonardo Grandinetti Chaves e Sandro Laudares