universidade federal do rio grande do norte instituto ... · aplicativo a fim de melhorar sua...
TRANSCRIPT
Universidade Federal do Rio Grande do Norte Instituto Metrópole Digital
Smart Metropolis – Plataformas e Aplicações para Cidades Inteligentes
WP2 − Aplicações
Relatório de Atividades do Sexto Trimestre
Natal-RN, Brasil Agosto de 2017
Equipe Técnica Docentes Prof. Dr. Everton Ranielly de Sousa Cavalcante (Coordenador) - DIMAp-UFRN Prof. Dr. Charles Andryê Galvão Madeira - IMD-UFRN Prof.ª Me. Daniela Estaregue Alves - EGR-UFSC Prof. Dr. Frederico Araújo da Silva Lopes - IMD-UFRN Prof. Dr. Gibeon Soares de Aquino Júnior - DIMAp-UFRN Prof. Dr. Jair Cavalcanti Leite - DIMAp-UFRN Prof. Dr. Nélio Alessandro Azevedo Cacho - DIMAp-UFRN Prof.ª Dra. Thais Vasconcelos Batista - DIMAp-UFRN Discentes Bárbara Gabriella da Silva Soares Bruno Cipolla Moreira Francisco Laércio de Morais Gabriela Mameri Tinôco Gustavo Alves Bezerra Jorge Pereira da Silva José Lucas Santos Ribeiro Juliana de Araújo Oliveira Ronaldo Gomes de Morais Júnior Thiago Cesar Morais Diniz de Lucena Colaboradores Prof. Me. Aluizio Ferreira da Rocha Neto - IMD-UFRN Maíla da Cunha Alves Marcus Vinicius Alves Maia
Sumário 1 Introdução ........................................................................................................................... 4
2 Aplicação Visit Natal .......................................................................................................... 6
2.1 Concepção de nova marca ............................................................................................ 6
2.2 Avaliação de usabilidade .............................................................................................. 8
2.2.1 Avaliação por inspeção ........................................................................................ 9
2.2.2 Avaliação com usuários ..................................................................................... 16
3 Aplicação Fala Natal ........................................................................................................ 24
4 Aplicação Smart Place ...................................................................................................... 26
4.1 Alterações na interface gráfica ................................................................................... 26
4.2 Nova arquitetura para a aplicação Smart Place ......................................................... 30
4.3 Ampliação da implantação ......................................................................................... 34
5 Jogos Educativos para Auxílio ao Combate às Drogas ..................................................... 36
5.1 Pesquisas e brainstorming.......................................................................................... 38
5.2 História do jogo .......................................................................................................... 39
5.3 Mecânicas do jogo ...................................................................................................... 40
5.3.1 Álcool ................................................................................................................ 41
5.3.2 Maconha ............................................................................................................ 41
5.3.3 Tabaco ................................................................................................................ 42
5.3.4 LSD .................................................................................................................... 42
5.3.5 Fase final ............................................................................................................ 42
6 Plataforma de Dados Abertos para a Cidade do Natal ...................................................... 44
6.1 Fundamentação teórica ............................................................................................... 44
6.2 Metodologia ............................................................................................................... 47
6.3 Resultados esperados ................................................................................................. 48
1 Introdução
O WP2-Aplicacoes do Projeto Smart Metropolis reune as atividades relativas ao planejamento e desenvolvimento de aplicacoes e/ou protótipos para aplicações com o intuito de possibilitar que os serviços oferecidos por uma cidade inteligente sejam mais eficientes. Tais aplicações tem como objetivo geral dar apoio aos cidadaos, a entidades responsaveis pela promocao de servicos publicos, entre outros possıveis interessados. Varias areas serao contempladas com aplicacoes durante a execucao do Projeto, tais como seguranca publica, turismo, transporte publico e privado, educacao, predios inteligentes, poluicao, servicos essenciais, etc.
Para o sexto trimestre de execução do Projeto, que corresponde aos meses de maio, junho e julho de 2017, foi planejada a entrega de versões incrementais das aplicações que vêm sendo desenvolvidas pelo grupo, a saber: (i) Visit Natal, voltada para o setor de turismo da cidade do Natal; (ii) Fala Natal, voltada para a comunicação entre a população e a Prefeitura Municipal do Natal no tocante ao registro de demandas, sugestões, denúncias e elogios; (iii) Smart Place, uma aplicação Web voltada para o gerenciamento inteligente de ambientes visando otimizar recursos disponíveis e contribuir com economia de energia elétrica, e; (iv) um jogo educativo para auxílio no combate às drogas, tendo como base o material do Programa Educacional de Resistência às Drogas (PROERD) da Polícia Militar do Estado do Rio Grande do Norte. Adicionalmente, durante o trimestre teve início o desenvolvimento de dois outros trabalhos no contexto do Projeto Smart Metropolis: (i) Campus Seguro, uma plataforma que abrange duas aplicações móveis e um dashboard Web no intuito de contribuir para melhorar a segurança no campus da Universidade Federal do Rio Grande do Norte (UFRN) por meio da gestão de ocorrências e acompanhamento em tempo real de ações de patrulha, e; (ii) a Plataforma de Dados Abertos da cidade do Natal, cujo propósito é divulgar as atividades e gastos públicos para a população, permitindo assim maior transparência, fiscalização, controle e participação das atividades do setor público tanto pela população quanto pelos órgãos competentes. Os avanços no desenvolvimento das aplicações mencionadas são detalhados nos demais capítulos do presente relatório e sumarizados no que segue. Visit Natal (Capítulo 2). Foram realizadas alterações na interface com o usuário do aplicativo a fim de melhorar sua usabilidade bem como testes para avaliar o aplicativo em termos de intuitividade de sua interface e funções disponibilizadas para os possíveis usuários. Os resultados obtidos através desses testes mostraram que o aplicativo possui um grau de usabilidade alto e que não carece de alterações emergenciais, ainda que os usuários que participaram das avaliações tenham sugerido algumas alterações pertinentes a serem desenvolvidas em versões futuras. Fala Natal (Capítulo 3). Foram feitos em ajustes para fins de padronização entre as versões do aplicativo para as plataformas Android e iOS, além da coordenação do
download/upload dos dados utilizados para contornar algumas restrições da própria plataforma iOS. Essa padronização não se refere apenas à interface, mas ao aplicativo como um todo, que se apresenta atualmente com funcionalidades, fluxos de execução e de atividades, textos e interface com o usuário o mais similar possível entre as duas versões, ressalvando as individualidades de cada uma das plataformas. Também foi iniciado o planejamento da realização dos testes para avaliar a usabilidade do aplicativo em suas versões para as plataformas Android e iOS, com enfoque na intuitividade de sua interface para os possíveis usuários, se ele atende às necessidades de tais usuários e se haveria possíveis falhas, dificuldade de navegação ou outros tipos de problemas para realizar as funções disponibilizadas pelo aplicativo. Smart Place (Capítulo 4). Foi dada continuidade ao desenvolvimento e aperfeiçoamento da interface gráfica do Smart Place, bem como elaborada uma nova arquitetura de implantação para a aplicação, a fim de lhe conferir maior escalabilidade e resiliência. Além disso, foram criados alguns protótipos de hardware e software seguindo essa nova arquitetura proposta e feitos testes em algumas das salas e laboratórios do IMD-UFRN. Jogo educativo para auxílio ao combate às drogas (Capítulo 5). Foi feito um estudo inicial acerca do material base para a concepção do jogo, bem como propostas existentes no mesmo contexto e outras que poderiam servir como inspiração. Mais ainda, começou-se a elaborar uma primeira proposta para o jogo, em termos da história abordada e mecânica de funcionamento. Portal de Dados Abertos (Capítulo 6). Após a elicitação dos requisitos, projeto arquitetural e seleção e estudo das tecnologias que seriam aplicadas, teve início o desenvolvimento da solução e avaliação da plataforma, além da indicação dos conjuntos de dados abertos candidatos à publicação.
2 Aplicação Visit Natal
A aplicação Visit Natal é um aplicativo móvel que possui a finalidade de auxiliar os turistas a aproveitar melhor a sua viagem para a cidade do Natal. Para isso, o serviço oferece um conjunto de funcionalidades que auxiliam o usuário nas atividades turísticas. A principal funcionalidade do aplicativo é apresentar ao turista uma gama de atrações turísticas categorizadas em tipos e subtipos, servindo assim como um guia turístico prático e de fácil acesso dentro do dispositivo móvel. Em deliberação entre a Secretaria Municipal de Turismo (SETUR) da Prefeitura Municipal do Natal e a equipe gestora do Projeto Smart Metropolis, foi decidido que o novo nome do aplicativo passaria a ser oficialmente Visit Natal, fazendo, portanto, alusão à atividade turística, além de ser facilmente pronunciável e fazer sentido tanto no idioma Português quanto Inglês.
Uma vez que os relatórios anteriores descreveram de forma detalhada as funcionalidades do Visit Natal implementadas, este capítulo do presente relatório apresenta as atividades desenvolvidas no trimestre em questão no tocante a (i) alterações na interface com o usuário do aplicativo a fim de melhorar sua usabilidade e (ii) a realização de testes para avaliar o aplicativo em termos de intuitividade de sua interface para os possíveis usuários e realizar os ajustes necessários para evitar que eles tenham problemas para realizar as funções disponibilizadas pelo aplicativo. Com essas duas atividades feitas, o aplicativo tornou-se apto a ser lançado oficialmente.
2.1 Concepção de nova marca
Para Philip Kotler, considerado um dos pais do marketing, o termo marca diz respeito à união do nome, termo ou símbolo, com o intuito de identificar produtos ou serviços1. Assim, para se desenvolver uma marca forte, ela deve ser construída levando-se em consideração o consumidor específico daquele produto ou serviço. Para os especialistas em marcas David A. Aaker e Erich Joachimsthaler, a imagem de marca é essencialmente tática, ou seja, ela deve ser construída e trabalhada de modo a impulsionar os resultados pretendidos pela empresa e sua gestão deve ser permanente. Para isso, primeiramente, uma marca precisa ser consumida e lembrada e posteriormente ser gerida com enfoque no seu ambiente de uso2.
Tendo em vista a mudança de seu nome, a marca Visit Natal foi redesenhada para atender as necessidades do aplicativo móvel e se adequar à política de turismo da SETUR. Para a concepção do novo desenho, enfatizou-se o cenário em que a aplicação será utilizada, com a finalidade de encontrar o “elemento inspirador” para gerar insumo para a
1 Philip Kotler. Administração de Marketing - 10ª ed. São Paulo, Brasil: Pearson Prentice Hall, 2003. 2 David A. Aaker, Erich Joachimsthaler. Como construir marcas líderes. São Paulo, Brasil: Bookman, 2007.
criação visual da nova marca. Assim, optou-se por dar continuidade ao conceito de marcação de percursos terrestres utilizado na antiga marca, Find Trip, pois tal conceito é visto como um dos principais norteadores do aplicativo móvel. Chegou-se, portanto, aos elementos descritos no que segue.
Símbolo. O novo símbolo (Figura 2.1) é composto por uma linha contínua, com um desenho atual, leve e flexível, formando o desenho do símbolo de marcação muito utilizado nos mapas digitais, aspecto que se alinha ao o conceito de percurso terrestre.
Figura 2.1 - Símbolo desenvolvido para nova marca
Tipografia. Para a escolha da tipografia (Figura 2.2), levou-se em consideração
fontes sem arestas ou serifas, com bordas arredondadas que trouxessem um desenho moderno, leve e que resgatasse o conceito de percurso/trajeto, complementando o desenho do ícone desenvolvido.
Figura 2.2 - Nova tipografia da marca Visit Natal
Cores. A paleta de cores (Figura 2.3) foi mantida a mesma da anterior com a finalidade de responder à memória associativa da marca antiga.
Figura 2.3 - Paleta de cores utilizadas no aplicativo Visit Natal
Conjunto. A marca Visit Natal é formada por dois elementos essenciais, a saber,
símbolo e nome, resultando na logomarca mostrada na Figura 2.4. É de extrema importância manter as orientações de disposição dos componentes para preservar uma identidade sólida e coerente, contribuindo para uma construção de consciência de marca mais precisa. Para tal finalidade, foi desenvolvido um manual que descrever as recomendações, especificações e normas essenciais para a utilização da marca.
Figura 2.4 - Nova marca do aplicativo móvel
2.2 Avaliação de usabilidade
Considerando que todas as funcionalidades do aplicativo foram desenvolvidas ao longo dos trimestres anteriores de execução do Projeto Smart Metropolis, objetivou-se no presente trimestre alcançar uma versão estável e definitiva do aplicativo Visit Natal para que este pudesse ser oficialmente lançado e disponibilizado para o público através das lojas Google Play Store (para Android) e Apple Store (para iOS). No entanto, antes de disponibilizar o produto final, é imprescindível a realização de testes de usabilidade, através dos quais avaliar-se-ia o aplicativo em termos da intuitividade de sua interface para os possíveis usuários, se ele atende às necessidades de tais usuários e se haveria possíveis falhas, dificuldade de navegação ou outros tipos de problemas para realizar as funções disponibilizadas pelo aplicativo. Realizar esse tipo de teste é muito importante, pois os
resultados aferidos através dele podem interferir diretamente na aceitação do aplicativo por parte de seus usuários.
Os testes de usabilidade foram realizados em duas vertentes. Na primeira, um grupo de usuários inspecionou o aplicativo de forma livre a fim de identificar problemas de uso e relatar observações acerca de sua interface. Na segunda, realizou-se uma avaliação de usabilidade convencional em que um grupo de usuários realizou um grupo de tarefas predefinidas simulando ações de rotina do aplicativo, com o intuito de analisar o comportamento de tais pessoas durante o uso e identificar problemas que interferissem na usabilidade, além de opiniões sobre o aplicativo. Esses dois testes são descritos nas subseções a seguir.
2.2.1 Avaliação por inspeção
A usabilidade é uma propriedade das interfaces gráficas dos sistemas interativos computacionais. Na norma internacional ISO/IEC 25010 (2011) para qualidade de produto de software, a qualidade com relação ao uso diz respeito ao grau em que um produto ou sistema pode ser utilizado por usuários específicos para atenderem às suas necessidades e alcançar seus objetivos com eficácia, eficiência, livre de riscos e satisfação em contextos específicos de uso3, caracterizando assim a usabilidade de um sistema. O termo usabilidade está relacionado ao diálogo que acontece entre a interface do sistema e o seu usuário, isto é, a capacidade do sistema em permitir que este usuário alcance suas metas de interação com o mesmo4.
Para verificar a usabilidade de um sistema são realizados processos avaliativos na interface gráfica do sistema. Existem muitos processos avaliativos propostos na literatura, mas o que mais se destaca é o proposto por Jakob Nielsen5, que engloba dez heurísticas da interface do sistema, conforme sumarizado na Tabela 2.1. Essas heurísticas descrevem propriedades comuns nas interfaces que são derivadas de estudos de aspectos psicológicos, computacionais e sociológicos do problema.
Tabela 2.1 - Heurísticas para avaliação de usabilidade em um sistema
Heurísticas Descrição
Status do sistema O usuário deve ser informado pelo sistema em tempo razoável sobre o que está acontecendo
3 ISO/IEC 25010:2011. Systems and software engineering -- Systems and software Quality Requirements and
Evaluation (SQuaRE) - System and software quality models. Geneva, Switzerland: ISO, 2011. 4 J. M. Christian Bastien, Dominique L. Scapin. Ergonomic criteria for the evaluation of human-computer
interfaces - Technical report. France: INRIA Rocquencourt, 1993. 5 Jakob Nielsen. Heuristic evaluation. In: Jakob Nielsen, Robert L. Mack (eds.) Usability inspection methods.
New York, USA: John Wiley & Sons, Inc., 1994.
Compatibilidade do sistema com o mundo real
O modelo lógico do sistema deve ser compatível com o modelo lógico do usuário
Controle do usuário e liberdade O sistema deve tornar disponíveis funções que possibilitem saídas de funções indesejadas
Consistência e padrões O sistema deve ser consistente quanto à utilização e sua simbologia e a sua plataforma de hardware e software
Prevenção de erros O sistema deve ter um design que se preocupe com as possibilidades de erro
Reconhecimento ao invés de lembrança
As instruções para o bom funcionamento do sistema devem estar visíveis no contexto em que o usuário se encontra
Flexibilidade e eficiência no uso O sistema deve prover o nível de proficiência do usuário em relação ao próprio sistema
Estética e design minimalista Os diálogos do sistema devem conter somente informações relevantes ao seu funcionamento
Ajuda aos usuários o reconhecimento, diagnóstico e correção de erros
As mensagens devem ser expressas em linguagem clara, indicando as possíveis soluções
Ajuda e documentação A informação desejada deve ser facilmente encontrada, ser preferencialmente contextualizada e não muito extensa
Experiências reportadas na literatura têm demonstrado que muitos desenvolvedores
acham caros, difíceis de usar e demorados muitos dos métodos de avaliação de usabilidade, apesar de sua fundamental importância6. Um modo de avaliar a usabilidade de uma interface gráfica de forma rápida e a um baixo custo é por meio de inspeção usando checklists, que permitem que um pequeno grupo de profissionais, não necessariamente especialistas em ergonomia, identifique problemas menores e repetitivos nas interfaces7.
Para aferir o grau de usabilidade do aplicativo Visit Natal, foi criado um checklist com 38 perguntas de múltipla escolha a serem respondidas pelo avaliador após a inspeção, tomando como base as dez heurísticas apresentadas na Tabela 2.1. Antes da realização da avaliação propriamente dita, foi realizado um teste piloto para avaliar se o roteiro estava adequado, através do qual observou-se que o checklist ainda necessitava de pequenos
6 Jakob Nielsen, Rolf Molich. Heuristic evaluation of user interfaces. In: Proceedings of the 1990 SIGCHI
Conference on Human Factors in Computer Systems (CHI’90). New York, NY, USA: ACM, 1990, pp. 249-256.
7 Walter de Abreu Cybis, Adriana Holtz Betiol, Richard Faust. Ergonomia e usabilidade: Conhecimentos, métodos e aplicações. São Paulo, Brasil: Novatec Editora, 2015.
ajustes para o teste funcionar de acordo com o planejado. Após alterado o checklist de acordo com as recomendações do teste piloto, iniciou-se a seleção dos avaliadores, dois na Universidade Federal do Rio Grande do Norte (UFRN), em Natal, e um na Universidade Federal de Santa Catarina (UFSC), em Florianópolis.
Os testes foram realizados em laboratório entre os dias 5 e 8 de junho de 2017 utilizando a versão do aplicativo Visit Natal para a plataforma Android. Antes de iniciar o teste, um membro da equipe de desenvolvimento apresentou brevemente o aplicativo, seu objetivo e o objetivo da avaliação, além de receber um papel com screenshots das principais telas do aplicativo com nomeação dos principais elementos para auxiliar o avaliador a identificar os problemas e descrevê-los.
Após coletar as informações preenchidas no checklist, foi realizada uma análise em grupo das respostas obtidas, através das quais foi possível detectar pontos importantes em relação à interface do aplicativo. As Tabelas 2.2 a 2.8 mostram os resultados obtidos para cada pergunta definida no checklist, organizadas em sete grupos.
Tabela 2.2 - Perguntas sobre o status do sistema
Tabela 2.3 - Perguntas relacionadas a consistência, padrões e compatibilidade no aplicativo
Tabela 2.4 - Perguntas relacionadas à estética do aplicativo
Tabela 2.5 - Perguntas relacionadas à prevenção de erros no aplicativo
Tabela 2.6 - Perguntas relacionadas à flexibilidade e eficiência de uso do aplicativo
Tabela 2.7 - Perguntas relacionadas às capacidades de ajuda e documentação do aplicativo
Tabela 2.8 - Perguntas relacionadas ao reconhecimento de informações no aplicativo
De modo geral, foi possível observar que as respostas fornecidas pelos avaliadores foram compatíveis e uniformes, demonstrando a qualidade do checklist aplicado. Ao final das questões, perguntou-se acerca do grau de confiança do avaliador sobre as suas respostas, obtendo-se 66,7% confiante em todas as questões e 33,3% confiante em muitas delas. Também foi apresentado ao final das questões um campo de observações, onde apenas um avaliador inseriu um comentário de forma livre. O comentário registrado foi sobre a página de avaliação dos destinos turísticos, que apresenta categorias predefinidas e não permite ao usuário inserir uma nova categoria, sugerindo assim incluir um campo para inserir outras categorias.
Uma observação comunicada por um avaliador ao membro da equipe de desenvolvimento (apesar de não ter sido registrada no campo de observações) foi que ele gostaria de encontrar um aplicativo de turismo que integrasse várias outras funcionalidades, como reservar um hotel, um passeio, alugar um carro, encontrar sugestões de passeio de
acordo com seu perfil ou de acordo com o número de dias que irá ficar no destino, entre outros. Com isso, não haveria necessidade de se ter vários aplicativos um para cada finalidade da viagem e que ficasse tudo armazenado em um único lugar.
Ao analisar as respostas do checklist, observou-se que mesmo realizando-se o teste piloto, ocorreram algumas dúvidas sobre o questionário, porém nada que comprometesse os resultados observados. Os problemas encontrados foram:
● Na Questão 4 (Há uso de valores pré-definidos que auxiliam o usuário no preenchimento de formulários?), os avaliadores precisaram recorrer a um membro da equipe que estava aplicando o checklist para esclarecimentos, sendo que a mesma pergunta era realizada de modo diferente na Questão 22 (Na entrada de dados, o aplicativo avisa sobre o tipo e o formato dos dados, indicando o formato correto?) e esta não apresentou problemas de interpretação. Assim, percebe-se a necessidade de excluir uma dessas questões que avaliam o mesmo processo, permanecendo apenas com a Questão 22.
● A Questão 9 (Funções semelhantes são apresentadas de forma similar?) também apresentou dúvidas, pois apresentou respostas diversas (66,7% dos participantes respondeu “Sim, totalmente” e 33,3% respondeu que “Não se aplica”). Uma solução seria inserir um exemplo do que seria uma função semelhante junto à questão.
● A Questão 12 (O usuário consegue preencher os campos de formulário com teclado virtual?) também apresentou respostas diversas, sendo que na plataforma Android é impossível preencher algum campo sem a utilização do teclado virtual. Isto posto, tal questão deve ser excluída do checklist. O mesmo deve acontecer com as Questões 15 e 30, que, para a avaliação do aplicativo, não se fazem necessárias.
● Na Questão 24 (O aplicativo indica claramente quando há um erro no processamento de uma operação pelo sistema?) é necessário incluir uma observação para que o avaliador provoque um erro para responder tal pergunta, pois com uma navegação rápida pelo aplicativo durante o teste dificilmente o mesmo apresentará um erro. A Questão 25 (O aplicativo oferece mensagens de erros que orientam o usuário a realizar a tarefa corretamente?) é um complemento da anterior, necessitando também de ajustes, como inserir um exemplo abaixo da questão para orientar o avaliador.
● Na Questão 29 (“Há comandos (teclas de atalho) que permitem fazer a tarefa mais rapidamente?) deve-se retirar das opções a resposta “Não se aplica”.
● As Questões 31 (O aplicativo oferece ajuda para as tarefas do usuário?) e 32 (É fácil encontrar a ajuda para as tarefas?) também precisam de mais informações para os avaliadores, como inserir exemplos, pois são questões que apresentaram divergências de respostas.
● Após o preenchimento das 38 questões, é apresentada uma pergunta para o avaliador informar o grau de confiança de suas respostas. Essa questão necessita de ligeira reformulação passando a Qual o grau de confiança que você atribui às suas respostas?.
As demais questões, não listadas anteriormente, foram respondidas sem dificuldades e sem divergência de respostas, o que mostra que o aplicativo possui um grau de usabilidade alto e que não carece de alterações emergenciais. Contudo, tais ajustes no checklist são necessários para futuras aplicações, pois ele pode ser utilizado como complemento em um teste de usabilidade com os usuários reais e/ou em outros aplicativos móveis.
2.2.2 Avaliação com usuários
Após a realização da avaliação de usabilidade por inspeção, foi proposta a realização de um teste de usabilidade convencional com usuários que não tiveram contato prévio com o aplicativo Visit Natal. Esse teste consistiu na realização de algumas tarefas cobrindo as principais funcionalidades do aplicativo no intuito de identificar outros problemas relacionados à usabilidade que não foram reportados na avaliação anterior. Antes da execução dos testes, foi realizado um teste piloto para validar os questionários, processo e ambiente de execução.
Para esta segunda avaliação, foram escolhidos cinco usuários levando em consideração diferentes idades, experiência de viagem, ambientação com tecnologia, plataforma (Android ou iOS) e nacionalidade (brasileira ou estrangeira). A escolha desse número alinha-se com a sugestão de Jakob Nielsen em que uma avaliação de usabilidade com apenas cinco usuários seria suficiente para identificar mais de 80% dos problemas existentes uma interface8.
Os testes foram realizados entre os dias 18 e 20 de junho de 2017 em laboratório. Inicialmente, foi aplicado um questionário para caracterizar o perfil de cada participante, que em seguida foi solicitado para realizar uma lista de tarefas. Após a conclusão dessas tarefas, o usuário foi solicitado a responder outro questionário para que fossem registradas suas impressões acerca da experiência de uso do aplicativo. A execução das tarefas foi acompanhada por um observador e registrada por meio de uma câmera de vídeo e o
8 Jakob Nielsen. Why you only need to test with 5 users. Disponível em:
https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/.
aplicativo Mobizen9, que efetua a gravação da tela de um smartphone durante o seu uso. Devido à disponibilidade do aplicativo Mobizen apenas para a plataforma Android e a ausência de um equivalente para a plataforma iOS, o teste realizado com a versão para iOS foi registrado apenas em vídeo. No que segue, são apresentadas as etapas realizadas durante o teste de usabilidade.
1) Aplicação de questionário para definir perfil do participante. Para cada participante, foram coletadas informações acerca de sua faixa etária, número de viagens realizadas para capitais e/ou grandes cidades, anos de experiência com smartphones, plataforma mais utilizada (Android ou iOS) e nacionalidade.
2) Execução de tarefas. Foram identificadas seis tarefas cobrindo as principais funcionalidades do aplicativo e que permitam ao usuário explorar de forma suficiente praticamente todas as telas. Após recomendações iniciais, cada usuário foi orientado a realizar as tarefas apresentadas na Tabela 2.9, na ordem em que foram dispostas e sem qualquer interação entre ele e o aplicador do teste.
Tabela 2.9 - Tarefas realizadas durante a avaliação de usabilidade com usuários
Tarefa Descrição
Tarefa 01 Você gostaria de saber como está a avaliação de algum restaurante em Natal. Faça uma busca para visualizar as informações deste restaurante.
Tarefa 02 Após pesquisar por hotéis em Natal, escolha um dentre os listados e ative o alerta de proximidade para ser avisado quando estiver próximo do hotel.
Tarefa 03 Encontre as sorveterias mais próximas do local onde você está.
Tarefa 04 A partir da pesquisa anterior, selecione uma sorveteria e encontre a melhor maneira de chegar até lá a partir do ponto onde está localizado.
Tarefa 05 Faça a avaliação de algum shopping que tenha visitado na cidade.
Tarefa 06 Considere que você é um turista e avalie sua visita à cidade do Natal.
3) Entrevista. Após a conclusão das tarefas, o aplicador do teste fez uma série de
perguntas para o usuário em forma de entrevista, conforme apresentado na Tabela 2.10. As perguntas foram inicialmente objetivas, com respostas mais fechadas, passando a perguntas mais especificamente relacionadas às tarefas realizadas pelo usuário e, por fim, encerrando com um conjunto de perguntas com respostas mais abertas sobre o teste.
9 RSUPPORT Co., Ltd. Mobizen Screen Recorder 3.4.1.2 para Android. Disponível em:
http://mobizen.br.uptodown.com/android
Tabela 2.10 - Perguntas realizadas na etapa final da avaliação de usabilidade
Categoria Perguntas Possibilidade de resposta
Perguntas fechadas
1) Facilidade de utilização 2) Organização das informações 3) Layout das telas 4) Assimilação das informações 5) Conteúdo disponível
Fácil/Difícil Boa/Ruim Confuso/Claro Fácil/Difícil Suficiente/Insuficiente
Perguntas sobre as tarefas
1) Na Tarefa 01, você conseguiu identificar facilmente a informação solicitada?
2) Na Tarefa 02, você preferiu usar a barra de busca ou procurar através do menu do aplicativo? Conseguiu identificar o alerta de proximidade?
3) Na Tarefa 03, foi fácil identificar as sorveterias mais próximas?
4) Na Tarefa 04, o aplicativo indica a melhor maneira de chegar ao ponto turístico?
5) Na Tarefa 05, você teve alguma dificuldade em fazer a avaliação solicitada?
6) Você achou a Tarefa 06 cansativa?
Sim/Não Comentários adicionais
Perguntas abertas
1) Aponte situações em que você achou fácil utilizar o aplicativo.
2) Aponte situações em que você sentiu dificuldades. 3) Você acha que o aplicativo atingiu o objetivo para o
qual foi desenvolvido? Explique. 4) Você já utilizou algum aplicativo similar? Qual foi? 5) Quais foram as vantagens e desvantagens que
encontrou no Visit Natal comparado com o aplicativo citado na Pergunta 4?
6) O espaço abaixo é reservado para que você exponha sua opinião e sugira melhorias no aplicativo.
Resposta livre
A Figura 2.5 mostra dados sobre o perfil dos usuários que realizaram os testes de usabilidade, incluindo o teste piloto. Todos os usuários tinham mais de 20 anos de idade, dois deles com mais de 30 anos e um deles com mais de 40. É possível verificar que todos os usuários são acostumados a realizar viagens turísticas, dois deles tendo viajado mais de 20 vezes, dois cinco vezes, um entre seis e dez vezes e um entre dez a vinte vezes. Isso é muito importante para o teste do aplicativo, já que é um aplicativo voltado para o público
turístico. A maioria dos usuários utiliza Android como plataforma de smartphone e faz uso do dispositivo há mais de cinco anos.
Figura 2.5 - Perfil dos usuários participantes do teste de usabilidade
A Figura 2.6 mostra as respostas dos usuários às perguntas fechadas na primeira parte do questionário, após a realização das tarefas e interação com o aplicativo. De uma forma geral, todos os usuários classificaram a utilização do aplicativo como fácil, a organização das informações como boa e como de fácil assimilação as informações fornecidas pelo aplicativo sobre as atrações turísticas. Em relação ao layout das telas, 20% dos usuários classificaram como confuso e 80% classificaram como claro. Além disso, para 60% dos participantes, o conteúdo apresentado é suficiente, contra 40% que o julgaram ainda insuficiente. Em particular, esses usuários relataram que faltam (i) informação sobre os comentários de outros turistas sobre uma atração, (ii) mais fotos das atrações, (iii) visualização das avaliações dos outros turistas e (iv) mais informações sobre a rota para um determinado local (em termos de distância, guia em tempo real, qualidade do trânsito, etc.).
Figura 2.10 - Respostas às perguntas fechadas do questionário pelos usuários participantes do teste de usabilidade
Durante os testes realizados com os usuários e mediante a análise dos registros feitos pelo aplicador, foram levantados alguns ajustes de menor escala a serem feitos no aplicativo, além de eventuais dificuldades encontradas e sugestões para adição de novas funcionalidades em próximas versões do aplicativo, conforme sumarizado na Tabela 2.11. Os ajustes identificados já foram implementados na versão atual do aplicativo tanto para a plataforma Android quanto para a iOS.
Tabela 2.11 - Resumo das observações feitas durante e depois do teste de usabilidade
Teste Ajustes Sugestões Observações
Teste 1 (iOS) ● Mostrar localização atual do usuário no mapa geral
● Nas telas de avaliação da cidade, algumas informações ainda estavam em Português
● Não reconhece clique para exibir rota até o ponto turístico, através do mapa geral
● Visualizar comentários de outros usuários que avaliaram os pontos turísticos
● Dificuldade de navegação, sendo necessário lembrar o nome das coisas
● A primeira tela de avaliação da cidade não se aplica a outros países
● Não se identificou facilmente que era possível abrir o website do ponto turístico apenas clicando
● Dificuldade para encontrar os shoppings
Teste 2 (Android)
● Refinar busca para realizar buscas mais gerais
● Buscar por categoria
● Ícone da rota insuficiente para que o usuário saiba que, clicando-se nele, é mostrada a rota
● Muita informação para avaliar na avaliação do ponto turístico
● Valores iniciais das avaliações ainda estão zero
Teste 3 ● Listar filtros em ● Na avaliação, ● Dúvidas sobre nomes
(Android) ordem alfabética no mapa geral e aumentar espaçamento entre os nomes
● Mostrar localização atual do usuário no mapa geral
permitir que o usuário, com um duplo clique, defina a meia-estrela
na avaliação (e.g., telecomunicações)
● Nem sempre os turistas fazem todas as atividades que são perguntadas na avaliação da cidade (e.g., aeroporto, rodoviária)
Teste 4 (Android)
● Descer automaticamente o teclado virtual
● Mostrar um balão indicando que é o alerta de proximidade
● Ordenar os pontos turísticos na listagem por proximidade
● Integrar com Waze ou Google Maps
● Colocar shopping no menu principal
● Adicionar a opção Uber na avaliação da cidade
● Incluir barra de progressão na avaliação da cidade
● Clique nas estrelas na tela de detalhes do ponto turístico para fazer a avaliação
● Identificação não-imediata da função dos ícones de alerta e rota
● Dificuldade de achar shopping
● Dúvida se o campo “Cidade” na avaliação refere-se à cidade onde nasceu ou a em que está residindo
● Dúvida se o campo “Guia” na avaliação refere-se ao guia turístico (livro) ou a um guia de turismo (pessoa)
● Não se identificou que a opção “Mapa” mostra os pontos turísticos mais próximos
Teste 5 (Android)
- ● Colocar shopping em “Serviços” e não em “Conheça Natal”
● Clique nas estrelas na tela de detalhes do ponto turístico para fazer a avaliação
● Ordenar os pontos turísticos por proximidade na listagem
● Acrescentar o idioma espanhol
● Adicionar detalhes sobre as avaliações do ponto turístico (comentários, fotos, avaliações, etc.)
● Integrar com Waze ou Google Maps
● Colocar telas de perfil no final da avaliação da cidade e não no início
● Não se identificou que a opção “Mapa” mostra os pontos turísticos mais próximos
● Ao mostrar a rota até o ponto turístico, o aplicativo não mostra informações adicionais (e.g., distância)
3 Aplicação Fala Natal
Fala Natal será o aplicativo oficial da Prefeitura Municipal de Natal que, em parceria com a Ouvidoria Geral do Município e as Secretarias Municipais, facilitará a comunicação entre a população e a Prefeitura. O aplicativo oferecerá ao cidadão uma nova alternativa para a realização de demandas, sugestões, elogios e denúncias, em adição às já existentes na Web, por telefone ou via e-mail.
As atividades desenvolvidas no presente trimestre concentraram-se em ajustes relativos para fins de padronização entre as versões do aplicativo para as plataformas Android e iOS, além da coordenação do download/upload dos dados. Essa padronização não se refere apenas à interface, mas ao aplicativo como um todo, que se apresenta atualmente com funcionalidades, fluxos de execução e de atividades, textos e interface com o usuário o mais similar possível entre as duas versões, ressalvando as individualidades de cada uma das plataformas. Com relação à coordenação do upload dos dados na versão iOS do aplicativo, ela foi implementada e está funcionando, mas a plataforma da Apple traz restrições referentes a serviços que rodam em background no aparelho. Por exemplo, no iOS, o aplicativo não pode ser fechado completamente para que os uploads possam ser feitos em background. Para tentar contornar a situação, foi implementada uma thread interna ao aplicativo (que executa enquanto o aplicativo está aberto, mas apenas se existirem uploads a serem feitos), para aproveitar o tempo em que o aplicativo está em foco, pois nesse momento é possível ter um maior controle sobre as atividades no aparelho. Essa thread é responsável por tentar continuamente fazer os uploads e é terminada quando não existir mais uploads a serem realizados. Já com relação ao download dos dados, no momento ele está sendo realizado apenas na primeira vez que o usuário acessa o aplicativo, não havendo possibilidade de atualização automática desses dados no futuro. Assim, para atualizar esses dados no futuro, será necessário fazer a atualização do aplicativo diretamente na loja Apple Store. Adicionalmente, neste trimestre foi iniciado o planejamento da realização dos testes para avaliar a usabilidade do aplicativo em suas versões para as plataformas Android e iOS, com enfoque na intuitividade de sua interface para os possíveis usuários, se ele atende às necessidades de tais usuários e se haveria possíveis falhas, dificuldade de navegação ou outros tipos de problemas para realizar as funções disponibilizadas pelo aplicativo. De maneira similar ao que foi realizado para o aplicativo Visit Natal (q.v. Capítulo 2), os testes serão realizados em duas vertentes. Na primeira, um grupo de usuários irá inspecionar o aplicativo de forma livre a fim de identificar problemas de uso e relatar observações acerca de sua interface. Na segunda, realizar-se-á uma avaliação de usabilidade convencional em que um grupo de usuários realizou um grupo de tarefas predefinidas simulando ações de rotina do aplicativo, com o intuito de analisar o comportamento de tais pessoas durante o uso e identificar problemas que interferissem na usabilidade, além de opiniões sobre o
aplicativo. Uma vez realizados, os resultados desses dois testes serão apresentados no próximo relatório.
4 Aplicação Smart Place
A aplicação Smart Place tem como objetivo realizar, de forma automática, o gerenciamento de recursos tais como aparelhos de ar condicionado e lâmpadas em prédios, contribuindo para a economia de eletricidade e proporcionando mais conforto e praticidade a seus usuários. A aplicação também tem como objetivo gerenciar, de forma automática, a presença de pessoas em ambientes, além de manter o registro dos recursos computacionais existentes em tais locais.
Conforme descrito no relatório do trimestre anterior, as últimas atividades realizadas até então foram: (i) o início do desenvolvimento de uma nova interface gráfica visualmente mais atraente para o sistema; (ii) a implementação de mecanismos de autenticação e autorização para garantir que somente usuários devidamente logados tenham acesso às funcionalidades restritas do sistema e que cada usuário tenha acesso somente às funcionalidades as quais lhe dizem respeito, e; (iii) a integração da aplicação a um dos habilitadores genéricos (GEs) da plataforma FIWARE10, o Orion Context Broker. No decorrer deste trimestre, as seguintes atividades foram realizadas:
1) foi dada continuidade ao desenvolvimento/aperfeiçoamento da interface gráfica do Smart Place;
2) uma nova arquitetura foi elaborada para o sistema, a fim de lhe conferir maior escalabilidade e resiliência;
3) foram criados alguns protótipos de hardware e software seguindo a nova arquitetura proposta para instalação e testes em algumas das salas e laboratórios do Instituto Metrópole Digital (IMD) da UFRN.
4.1 Alterações na interface gráfica
No trimestre anterior, foi dado início ao desenvolvimento de uma nova interface gráfica para o Smart Place, atividade essa para a qual foi dado prosseguimento durante este trimestre. Como mencionado no relatório anterior, há três perfis de usuários diferentes que podem fazer uso do Smart Place, a saber, administrador, professor e suporte técnico. Cada perfil de usuário possui diferentes responsabilidades e níveis de acesso. Embora os diferentes perfis de usuários tenham objetivos distintos no Smart Place, algumas funcionalidades e elementos gráficos que compõem as interfaces do sistema são comuns à todos os usuários, tais como a funcionalidade de edição da conta, visualização de notificações, adição da foto do perfil, etc. No trimestre em questão, alguns desses elementos gráficos foram inseridos nas interfaces do sistema. Além disso, parte dessas
10 FIWARE. Disponível em: http://www.fiware.org/
novas funcionalidades comuns, que ainda estavam com implementação pendente, foram implementadas.
Exibição de notificações. A funcionalidade de acesso a notificações, acessível através do ícone de notificações situado no canto superior direito da tela, foi implementada. Essa funcionalidade permite acessar rapidamente mensagens de notificações destinadas ao usuário. Por exemplo, supondo que um professor solicite a instalação de um software nos computadores do laboratório a fim de ministrar uma aula, uma mensagem endereçada ao usuário com perfil de suporte técnico será exibida na tela deste último. Quando o suporte técnico atender à solicitação do professor, ele será notificado através de uma mensagem informando que o software solicitado já está disponível nos computadores do laboratório.
Configuração da conta. A funcionalidade de configuração da conta do usuário, acessível através do ícone de configurações situado no canto superior direito da tela, também foi implementada. Atualmente essa funcionalidade permite editar o nome e senha do usuário.
Atualização da foto do perfil. Essa funcionalidade permite alterar a foto do perfil do usuário, podendo ser acessada através de um duplo clique na foto do usuário, situada no canto superior direito da tela. Uma vez que o usuário acesse essa funcionalidade, ele será direcionado para uma tela na qual ele poderá escolher uma nova foto de perfil para sua conta.
Nome e perfil do usuário. Um novo elemento gráfico, situado no canto superior direito da tela, que indica o nome e perfil do usuário logado no sistema também foi adicionado.
Além das alterações realizadas sobre as funcionalidades comuns, acessíveis por todos os perfis de usuários, também foram realizadas modificações nas telas acessíveis por perfis de usuários específicos. Com relação ao perfil de administrador, o menu lateral foi modificado com o intuito de deixar a página mais instrutiva. Na versão anterior, as funções para cadastrar e gerenciar estavam juntas em uma única página tanto para prédios quanto para salas, sensores e aparelhos de ar condicionado. Essa distribuição estava confusa e, por esse motivo, foi separada, resultando na tela apresentada na Figura 4.1. Com essa nova distribuição, o administrador poderá cadastrar novos prédios, salas, sensores e aparelhos de ar condicionados, bem como poderá também gerenciar todos esses recursos, ou seja, listar os existentes e editar e/ou remover.
Figura 4.1 - Página inicial do usuário administrador
Outra funcionalidade também atualizada foi a de visualizar gráficos, tanto da temperatura e umidade da sala quanto de presença detectada. Além disso, foi alterada a forma de apresentar o histórico de acionamento do aparelho de ar condicionado. Na nova versão, são apresentados, em uma linha do tempo, todos os comandos executados (ligar, desligar, aumentar e diminuir a temperatura) referentes ao aparelho de ar condicionado. A Figura 4.2 apresenta esse novo gráfico.
Figura 4.2 - Gráfico de histórico de acionamento de aparelho de ar condicionado
No tocante ao perfil do professor, as funcionalidades relacionadas às solicitações foram implementadas, assim como a de consultar os recursos disponíveis (Figura 4.3). Com relação às solicitações, o usuário poderá solicitar instalação de recursos nos computadores e verificar o status das suas solicitações. Dessa forma, ficará mais fácil verificar se o recurso estará disponível para data informada no ato da solicitação.
Figura 4.3 - Página inicial do usuário professor
Diante das funcionalidades do usuário professor, o usuário suporte ficará, então,
responsável por averiguar todas as solicitações feitas, atualizar o status da solicitação (se está em processamento, se foi realizada ou se houve algo que impediu a realização) e enfim cadastrar o novo recurso como disponível. Dessa forma, todos ficarão sabendo quais recursos estão disponíveis através da funcionalidade Consultar Recursos. Todas essas funcionalidades podem ser verificadas na Figura 4.4.
Figura 4.4 - Página inicial do usuário de suporte
Algumas atualizações serão feitas ao longo do próximo trimestre, a saber: (i) desenvolver uma logomarca para a aplicação Smart Place e adição à interface; (ii) demarcar a página atual bem como o caminho utilizado para chegar à página atual, e; (iii) adicionar legenda aos gráficos.
4.2 Nova arquitetura para a aplicação Smart Place
A fim de tornar a arquitetura do Smart Place mais escalável e eficiente, algumas alterações foram realizadas. Na arquitetura de implantação atual, mostrada no Diagrama UML de Implantação da Figura 4.5, sensores de temperatura e umidade estão conectados a um dispositivo Arduino Uno11 e os dados são aferidos e enviados para um sistema Web (SmartPlace Web). O sistema Web, por sua vez, concentra todas as regras que decidem quando acionar, desativar ou alterar a temperatura do aparelho de ar condicionado, além de registrar todas as informações usadas pelo sistema em um banco de dados relacional PostgreSQL12. Quando existe a necessidade de acionar, desativar ou alterar as configurações de temperatura do aparelho de ar condicionado, o sistema Web envia para a aplicação Smart Place Air Control, implantada em um dispositivo Raspberry Pi13, os comandos necessários para realizar a referida alteração. A aplicação Smart Place Air Control, por sua vez, recebe o comando enviado pelo sistema Web e envia um sinal infravermelho correspondente para o aparelho de ar condicionado através de um led
11 Arduino AG Arduino UNO. Disponível em: http://www.arduino.org/products/boards/arduino-uno 12 The PostgreSQL Global Development Group. PostgreSQL. Disponível em: https://www.postgresql.org/ 13 Raspberry Pi Foundation. Raspberry Pi. Disponível em: https://www.raspberrypi.org/
emissor infravermelho (IR Led). Por exemplo, supondo que o sistema Web solicite à aplicação Smart Place Air Control que desative um aparelho de ar condicionado, a aplicação irá verificar qual o sinal infravermelho (sequência de bits) deve ser enviado para desativar o aparelho e o enviará. O aparelho de ar condicionado receberá então o sinal infravermelho por meio de um fotossensor infravermelho (IR Fotossensor).
Figura 4.5 - Arquitetura de implantação atual da aplicação Smart Place
Na arquitetura atual de implantação, as capacidades dos dispositivos Raspberry Pi
instalados nas salas e laboratórios estão subutilizadas, uma vez que esses dispositivos possuem capacidade de memória e processamento considerável e que pode ser utilizada para executar outras aplicações além da aplicação Smart Place Air Control. Além disso, a aplicação fica suscetível a problemas de conectividade. Caso ocorra algum problema que afete a comunicação entre o dispositivo Arduino Uno e o sistema Web e/ou entre o sistema Web e o dispositivo Raspberry Pi, o sistema não será capaz de controlar corretamente os aparelhos de ar condicionado gerenciados. A fim de superar essas limitações, utilizar melhor os recursos disponíveis e tornar o sistema mais escalável e resiliente, foi proposta uma nova arquitetura, representada no Diagrama UML de Implantação mostrado na Figura 4.6. No que segue, são descritas as alterações necessárias à implementação para a realização dessa nova arquitetura de implantação, o que será feito durante as atividades conduzidas no próximo trimestre.
Figura 4.6 - Nova arquitetura de implantação proposta para a aplicação Smart Place
Implantação dos sensores nos dispositivos Raspberry Pi. Na nova arquitetura, todos os sensores que antes estavam implantados nos dispositivos Arduinos Uno passarão a ser implantados nos dispositivos Raspberry Pi. Além de melhor utilizar a capacidade ociosa destes últimos, essa alteração eliminará a necessidade de instalar dispositivos Arduino nas salas e laboratórios gerenciados. Além de dar suporte aos sensores de movimento e temperatura, também serão implantadas câmeras nos dispositivos Raspberry Pi, através das quais será possível identificar a presença e quantidade de pessoas existentes no ambiente. Com essas informações, será possível gerenciar melhor a temperatura do ambiente. Atualmente o sistema utiliza sensores de movimento (PIR sensors) para detectar a presença de pessoas no ambiente. No entanto, essa abordagem não tem se mostrado muito eficiente, pois, além de esse tipo de sensor possuir um raio de alcance limitado, ele não possui boa precisão e não é capaz de identificar a quantidade de pessoas presentes no ambiente. Esses sensores serão, portanto, substituídos gradualmente por câmeras, uma vez que as câmeras têm um custo mais elevado.
Substituição do PostgreSQL pelo Apache Cassandra. Atualmente, a aplicação Smart Place utiliza um banco de dados relacional PostgreSQL para armazenar os dados gerenciados. Em uma próxima versão, far-se-á uso do Apache Cassandra14, um banco de
14 Apache Software Foundation. Apache Cassandra. Disponível em: http://cassandra.apache.org/
dados não relacional distribuído e altamente escalável, além de ser mais adequado para gerenciar as séries temporais de dados. Com essa alteração, a aplicação Smart Place será capaz de gerenciar um volume bem maior de informações e os dados poderão ser facilmente replicados entre diversos servidores, garantindo maior desempenho e disponibilidade de acesso aos mesmos.
Alteração da aplicação Smart Place Air Control. Atualmente, a aplicação Smart Place Air Control tem o papel apenas de receber requisições oriundas do sistema Web e enviar os sinais infravermelhos correspondentes para o aparelho de ar condicionado. Em uma próxima versão, essa aplicação irá interagir com os sensores de movimento, temperatura e câmera instalados no dispositivo Raspberry Pi a fim de recuperar os dados por eles produzidos. Além disso, uma vez que essa aplicação tenha posse dos dados de presença e temperatura da sala onde se encontra instalada, ela será responsável por decidir quando acionar, desativar ou alterar a temperatura nos aparelhos de ar condicionado. Dessa forma, as decisões deixarão de ser tomadas de forma centralizada pelo sistema Web e passarão a ser tomadas pelos dispositivos instalados em cada sala. Com essas alterações, a aplicação Smart Place tornar-se-á mais escalável, uma vez que o processamento dos dados será realizado de forma distribuída pelos dispositivos Raspberry Pi instalados no ambiente. A aplicação tornar-se-á ainda mais resiliente, pois as decisões relacionadas ao controle dos aparelhos de ar condicionado serão tomadas localmente. Assim, mesmo que a comunicação via rede esteja indisponível, será possível controlar os aparelhos de ar condicionado. Todos os dados aferidos e ações realizadas sobre os aparelhos de ar condicionado serão informadas ao sistema Web para que sejam registradas em banco de dados.
Alteração do Sistema Web. Como explicado anteriormente, ficará a cargo da aplicação Smart Place Air Control decidir sobre quando interagir com os aparelhos de ar condicionado para alterar suas configurações. Dessa forma, no sistema Web, o módulo responsável pelo processamento dos dados aferidos pelos sensores será removido, fazendo com que ele fique responsável por gerenciar o armazenamento, acesso e visualização dos dados produzidos.
Inclusão de servidores e clientes SNTP para sincronização de tempo. Na aplicação Smart Place, todas as medições aferidas pelos sensores e atuações realizadas sobre os aparelhos de ar condicionado são associadas à data e hora em que aconteceram. Dessa forma, para garantir que o tempo em que essas tarefas foram realizadas seja informado de forma correta para futura análise e visualização dos dados, serão instalados clientes SNTP (Simple Network Time Protocol)15 para sincronizar os relógios do servidor e dos dispositivos Raspberry Pi espalhados pelo ambiente. Os clientes SNTP instalados serão sincronizados com o servidor SNTP disponível na rede da UFRN.
15 D. Mills. Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. USA: The Internet
Society, 2006. Disponível em: https://buildbot.tools.ietf.org/html/rfc4330
4.3 Ampliação da implantação
Como discutido na seção anterior, uma nova arquitetura foi proposta para a aplicação Smart Place. Na nova arquitetura de implantação, um dispositivo Raspberry Pi, presente em cada sala gerenciada, é utilizado para dar suporte a todos os sensores gerenciados e para tomar as decisões a respeito de como controlar os aparelhos de ar condicionado presentes na sala. Dessa forma, seguindo a nova arquitetura, foram criados alguns protótipos de hardware e software nos quais dispositivos Raspberry Pi agregam sensores de movimento (PIR sensors), temperatura/umidade (DHT11 sensors) e câmeras de vídeo. Foi discutido a indispensabilidade de otimizar o sistema que antes era composto por um dispositivo Arduino Uno, um dispositivo Raspberry Pi e os sensores. O software implantado no Raspberry Pi adquire os dados produzidos pelos sensores e câmeras gerenciadas e, com base neles, decide quando ligar/desligar os aparelhos de ar condicionado e quando elevar/diminuir a temperatura do ambiente. Além disso, o software registra no sistema Web todos os dados adquiridos através dos sensores. Essa nova versão do sistema foi implantada no Laboratório de Redes e na Sala B301 do IMD-UFRN para fase de testes, assim como a primeira versão que está funcionando até o momento no Laboratório B318. A nova arquitetura implantada no Laboratório de Redes é composta por um dispositivo Raspberry Pi 2, um sensor de temperatura e umidade, um sensor de movimento, um led emissor responsável por enviar comandos para o aparelho de ar condicionado e uma câmera do próprio Raspberry Pi (Figura 4.7). No momento, a câmera apenas mantém uma visão da sala e, quando ativada, filma por um período predefinido. A intenção é que, futuramente, algumas decisões sejam tomadas baseadas no retorno que a câmera fornecer. Por exemplo, se há um indivíduo na sala, porém ele se encontra em um ponto distante do sensor de movimento, a câmera evitará o desligamento do aparelho de ar condicionado uma vez que ela poderá detectar a presença e o sensor não. O sistema implantado na Sala B301, apresentado na Figura 4.8, é praticamente o mesmo, com a diferença de que não possui a câmera acoplada, mas conta com a adição de um display LCD que tem o propósito de apresentar os valores de temperatura e umidade.
Figura 4.7 - Sistema implantado na Sala A104 do IMD-UFRN
Figura 4.8 - Sistema implantado na Sala B301 do IMD-UFRN
Na versão anterior, o dispositivo Arduino monitorava os dados aferidos pelos sensores e os enviava, via rede, para a aplicação Smart Place, implantada em uma outra máquina. Ao receber os dados, a aplicação os analisava e, caso fosse necessário realizar alguma ação sobre o aparelho de ar condicionado, a aplicação interagia com o serviço Web implantado no dispositivo Raspberry Pi, que enviava um sinal infravermelho correspondente ao aparelho de ar condicionado. Na nova versão, todo o processo de monitoramento e decisão é feito pelo dispositivo Raspberry Pi, que, além disso, envia os dados via rede para a aplicação Smart Place. Essa nova arquitetura foi implantada com o intuito de não sobrecarregar a rede, uma vez que a intenção é que muitos sistemas sejam implantados e isso poderia causar congestionamento.
5 Jogos Educativos para Auxílio ao Combate às Drogas
A Pesquisa Nacional de Saúde do Escolar (PeNSE) referente ao ano 2015, traz dados alarmantes sobre os hábitos dos adolescentes brasileiros com idade entre 13 e 15 anos, estudantes concluintes do 9º ano de escolas públicas e privadas de todo o país. O percentual de jovens que já experimentou bebidas alcoólicas subiu de 50,3%, em 2012, para 55,5% em 2015. A taxa dos que usaram drogas ilícitas aumentou de 7,3% para 9% no mesmo período16.
Por outro lado, a incidência de ocorrências policiais envolvendo o uso de drogas em escolas é crescente. Infelizmente esta é uma realidade nacional evidenciada por outra pesquisa recente que mostra a presença do consumo de drogas em 32,1% das escolas brasileiras de Ensino Básico. O tráfico de entorpecentes aparece em 21,7% desses estabelecimentos17. A pesquisa mostra ainda que o problema provoca aumento de violência, pois as drogas chegam acompanhadas do aumento de agressões, roubo, furto, pichações, sujeira e depredação. Além disso, diminui consideravelmente a probabilidade de o aluno aprender e, consequentemente, ser aprovado.
No sentido de conter o avanço do uso de drogas nas escolas, estudos internacionais indicam que programas de prevenção devem abordar a dimensão socioeconômica e cultural dos indivíduos18. No Brasil, vários estados implantaram o Programa Educacional de Resistência às Drogas (PROERD)19 baseado nos modelos internacionais. No Rio Grande do Norte, o PROERD é desenvolvido desde 2002 e mais de 350 mil crianças, adolescentes e pais ou responsáveis passaram pelo programa desde sua implantação. Atualmente, seus policiais militares estão lotados na Companhia Independente de Prevenção ao Uso de Drogas (CIPRED) que, apesar de ter sofrido uma redução considerável em seu quadro em 201520, é a primeira e única unidade de Polícia Militar do país que tem suas atividades voltadas exclusivamente à realização de ações de prevenção a violência e ao uso e tráfico de drogas entre crianças em idade escolar e comunidade.
No entanto, o modelo atual do PROERD não faz uso de recursos tecnológicos que permitem auxiliar no trabalho de sensibilização das crianças e dos jovens de uma forma que
16 IBGE, Coordenação de População e Indicadores Sociais. Pesquisa Nacional de Saúde do Escolar 2015.
Rio de Janeiro, Brasil: IBGE, 2016. Disponível em: http://biblioteca.ibge.gov.br/visualizacao/livros/liv97870.pdf
17 Observatório do Crack. Disponível em: http://www2.crack.cnm.org.br/observatorio_crack/ 18 National Institute on Drug Abuse. Preventing drug use among children and adolescents: A research-based
guide for parents, educators and community leaders - 2nd ed. Bethesda, MA, USA: NIDA, 2010. 19 Governo do Estado do Rio Grande do Norte. Programa Educacional de Resistência às Drogas. Disponível
em: http://www.proerd.rn.gov.br/ 20 Ricardo Araújo. Transferências prejudicam Proerd. Tribuna do Norte [on-line], 3 dez. 2015. Disponível
em: http://www.tribunadonorte.com.br/noticia/transfera-ncias-prejudicam-proerd/331747
haja efetividade dos trabalhos realizados21. O modelo adotado ainda segue as características arcaicas e engessadas da educação tradicional que dificulta o desenvolvimento de atividades efetivamente criativas e inovadoras com o uso das tecnologias digitais.
É preciso, portanto, inovar fomentando novas estratégias pedagógicas e investigar, experimentar e implementar novas formas de sensibilizar, ensinar e aprender, indo além dos espaços formais de educação. Para isso, os educadores devem repensar as suas práticas e superar o paradigma das instituições de ensino como fontes de transmissão de informação, propondo aberturas para propostas e metodologias mais investigativas e que contemplem a experimentação, a mediação e a colaboração, tornando a educação mais interessante como agente motivador e modificador de todo o processo de conhecimento. Essas estratégias de ensino devem passar pelo empoderamento dos alunos, a criação de ambientes propícios para o compartilhamento de ideias, a transformação da sala de aula em uma verdadeira experiência engajadora, a integração entre diferentes conteúdos, o uso das tecnologias integradas ao currículo, o trabalho com projetos, tudo de forma com que as mudanças possam abranger aspectos didáticos e pedagógicos de uma educação baseada em resolução de problemas22.
Uma das possibilidades vislumbradas são os jogos digitais, uma vez que são ferramentas para as quais os jovens da atual geração apresentam forte predisposição. Além disso, os jogos digitais possuem características pedagógicas, nos quais o processo de ensino-aprendizagem apoiado pelo computador associado a estratégias lúdicas são integradas a fim de alcançar um objetivo educacional determinado23. Um jogo planejado adequadamente promove o interesse e a motivação, que por sua vez aumenta a atenção do aluno e cria a sensação de que aprender é divertido, proporcionando ao jogador desenvolver a capacidade de processar fatos e fazer inferências lógicas durante a resolução de um problema.
Nesse contexto, esta linha de trabalho do WP-Aplicações do Projeto Smart Metropolis tem como objetivo ajudar a promover a prevenção ao uso indevido de drogas em escolas do município de Natal, através do desenvolvimento e utilização de jogos digitais educativos para auxílio ao combate às drogas. Para se atingir este objetivo, o projeto está estruturado em ações articuladas com os seguintes objetivos específicos:
● identificar como jogos digitais podem contribuir para as formas atuais de prevenção de drogas;
21 Elizabeth Boyle, Thomas M. Connoly, Thomas Hainey. The role of psychology in understanding the
impact of computer games. Entertainment Computing, vol. 2, no. 2, Apr. 2011, pp. 69-74. 22 Alex Sandro Gomes, Pasqueline Dantas Scaico, Lays Rosiene Alves da Silva, Ivson Henrique Bezerra dos
Santos. Cultura Digital na escola: Habilidades, experiências e novas práticas. Recife, Brasil: Pipa Comunicação, 2015 (Série Professor Criativo I).
23 João Mattar. Games em Educação: Como os nativos digitais aprendem. São Paulo, Brasil: Pearson Prentice Hall, 2010
● propor e desenvolver jogos digitais com a temática de prevenção de drogas; ● estabelecer diálogo com a Polícia Militar e as escolas nas quais o projeto
poderá desenvolver suas atividades. De acordo com o planejamento do projeto, o presente trimestre foi dedicado ao
projeto de uma primeira proposta de jogo, de modo que este capítulo resume as atividades realizadas em termos pesquisas e brainstorms. O objetivo desta primeira proposta de jogo é ajudar a educar jovens de ensino fundamental sobre o consumo de drogas, baseado no material utilizado pelo PROERD.
5.1 Pesquisas e brainstorming
Como material inicial de pesquisa, foi utilizada a apostila do PROERD24 fornecida aos pais (q.v. Figura 5.1). Essa apostila foi usada como base principalmente para escolher quais drogas seriam tratadas no jogo e quais sintomas seriam mais focados. O livreto da PROERD introduz casos sobre os seguintes problemas: álcool, ecstasy, GHB, cetamina, rohypnol, anfetamina, LSD, tabaco, maconha, heroína, cocaína e bullying. De modo a abranger uma maior gama de contextos, os seguintes problemas foram escolhidos para serem inicialmente abordados: bullying, álcool, LSD, maconha e tabaco.
Figura 5.1 - Livreto do PROERD
24 D.A.R.E. America. Currículo para crianças do 5º Ano do Ensino Fundamental: Caindo na real. Belo
Horizonte, Brasil: PMMG, 2013. Disponível em: https://goo.gl/2cpqPq
É importante ressaltar que a metodologia do PROERD foi criada nos Estados Unidos, cujos métodos e eficiência foram questionados. Resultados muito curtos eram obtidos (reduzir o consumo apenas durante as primeiras semanas após o curso), bem como um efeito contrário, já que os adolescentes adquiriam conhecimento de substâncias das quais nunca tinham ouvido falar antes. É importante ressaltar também que, na época em que o programa foi desenvolvido, mídias como o YouTube não existiam. Como há muito pouco controle dos pais em relação ao acesso de tais plataformas, o conhecimento de tais drogas torna-se praticamente inevitável, com influência ou não do PROERD.
Para obter uma maior base de como projetar um jogo abordando o tema do assunto de drogas, alguns artigos foram lidos, a exemplo de um mapeamento sistemático da literatura publicado recentemente no Congresso Brasileiro de Informática na Educação (CBIE)25. No mapeamento apresentado nesse artigo, apenas uma quantidade limitada (menos de uma dezena) de trabalhos passou nos critérios da busca. Dessa dezena, apenas três jogos eram realmente interessantes para análise, mas depois de uma pesquisa mais detalhada, descobriu-se que esses jogos eram parte de uma trilogia e consideravelmente antigos, além de possuir mecânicas atrasadas e uma abordagem desinteressante para alunos de ensino fundamental, a saber, muito texto e pouco desafiador. Sendo assim, foi necessário começar a pensar novas ideias de jogos.
Optou-se por tratar o problema das drogas em segundo plano, focando mais na jogabilidade, o que não foi uma escolha aleatória. Por exemplo, God of War26 é um jogo que ocorre na Grécia Antiga abrangendo todos os mitos e crenças da época. O foco do jogo não é ensinar mitologia, mas divertir os jogadores, já que é um jogo de hack and slash, consistindo basicamente em derrotar todos os inimigos que aparecem à frente do jogador. Entretanto, muitos jogadores dizem ter aprendido mais sobre mitologia grega com God of War do que com aulas de História. Nessa perspectiva, a mecânica do jogo será uma associação de vários jogos simples famosos. Essa escolha se deve à facilidade de jogos com mecânicas simples, mas desafiadoras, prenderem a atenção do usuário, tais como os jogos Flappy Bird, Super Meat Boy e Tetris. O jogo irá basear-se principalmente em jogos como Crash Bandicoot, Guitar Hero, Pump It Up e Tony Hawk’s Pro Skater.
5.2 História do jogo
Há seis personagens principais, dos quais quatro jogáveis. A história começa com o personagem A sofrendo bullying de outro personagem B. Devido à problemas pessoais e por conta do bullying, o personagem A começa a consumir drogas como uma válvula de
25 André Nunes, Helder Oliveira, Maria de Lourdes Souza, Marcelo Hounsell. Jogos digitais e a dependência
química: Um mapeamento sistemático da literatura. In: Anais do XXVI Simpósio Brasileiro de Informática na Educação (SBIE 2015). [s.l., s.n.] 2015, pp. 479-488.
26 Santa Monica Studio. God of War. Disponível em: https://godofwar.playstation.com/
escape dos seus problemas. O personagem A é amigo dos outros quatro personagens restantes, os quais também estão passando por problemas pessoais e, influenciados por A, também começam a consumir drogas para esquecer dos problemas. Cada um desses quatro personagens tem um hobby diferente, a saber, jogos virtuais, basquete, skate e dança. Eles terão de lidar com uma das seguintes drogas: álcool, LSD, maconha e tabaco. Inicialmente o efeito das substâncias os trará satisfação. No decorrer do jogo, os malefícios das drogas se tornarão cada vez mais aparentes, interferindo na jogabilidade. Após perceberem que não vale a pena consumir as substâncias e que elas só trouxeram mais problemas, os quatro personagens principais irão tentar convencer o personagem A a largar seu vício (seria o chefe final do jogo). Após derrotar o chefe final do jogo, o personagem B aparece novamente, se desculpando pelos problemas que causou para o personagem A. No final, os seis se tornam grandes amigos.
A história é bem simples e com poucos detalhes para facilitar o entendimento de uma maior gama de jogadores. A simplicidade também facilita no modo como a história deve ser apresentada, isto é, com muitas imagens e textos curtos. Bons exemplos a se seguir são a história do jogo Super Meat Boy ou uma versão ainda mais simplificada do jogo Valiant Hearts.
5.3 Mecânicas do jogo
O seletor de fases será parecido com o do jogo Crash Bandicoot: Warped. Serão vinte e cinco fases ao todo, separadas em cinco grupos, cada grupo com cinco fases e dedicado a um personagem, com exceção do primeiro. O primeiro grupo consistirá de quatro fases introdutórias, para ensinar a mecânica de cada personagem e do nível final (batalha contra o personagem A). Esse último nível ficará bloqueado até que todos os outros níveis sejam devidamente zerados. Para desbloquear a fase final, é necessário atingir uma pontuação mínima em todas as outras fases. Poderá ser usado um sistema de estrelas parecido com o dos jogos Angry Birds e Overcooked, nos quais a pontuação varia de 0 a 3 estrelas. Para desbloquear a fase final seriam necessárias 72 estrelas, sendo 12 das fases introdutórias mais 15 dos quatro grupos restantes. Cada personagem terá um conjunto de três habilidades especiais, duas sendo desbloqueadas ao decorrer do jogo, ao término da segunda e quarta fase do seu grupo. Para conseguir as três estrelas em cada fase, será necessário utilizar as três habilidades especiais, forçando assim o jogador a jogar as quatro primeiras fases de cada grupo pelo menos duas vezes. Essa regra não se aplica às fases introdutórias, bastando terminá-las para obter as três estrelas. Esse mecanismo visa aumentar a vida útil do jogo, diminuir o tamanho das fases (e consequentemente o tempo de desenvolvimento) e forçar o jogador a sentir os efeitos negativos das drogas nos personagens, já que cada fase agravará os efeitos das substâncias.
5.3.1 Álcool
O hobby desse personagem são jogos virtuais e seus três ataques serão soco/chute, golpe com uma espada e uma bola de fogo. Ele enfrentará vários inimigos no decorrer das fases, cada um com uma fraqueza a pelo menos um dos ataques. Para adquirir a pontuação máxima, é necessário que o jogador derrote cada um dos inimigos utilizando sua fraqueza.
Esse grupo de fases terá obstáculos simples como barreiras e buracos que terão de ser pulados, mas o desafio principal será administrar os efeitos do álcool. O personagem ficará um pouco tonto e com ânsia de vômito. Caso o jogador faça muitos movimentos bruscos, o personagem cairá e ficará sujeito a levar dano dos inimigos até se levantar.Quão mais difícil a fase menor a quantidade de movimentos para cair e maior o tempo necessário para se levantar. Para representar a perda de coordenação, a resposta aos comandos ficará mais lenta a cada fase. Para simbolizar a ressaca, o personagem ficará com “dor de cabeça” com uma certa frequência, cada vez maior à medida que a passa de fase. Enquanto o personagem estiver com “dor de cabeça” não poderá fazer ações.
5.3.2 Maconha
O hobby dessa personagem será andar de skate e suas três habilidades serão manobras. A pontuação será dada de acordo com a variedade de manobras realizadas ao decorrer da fase. A mecânica desse grupo está mais voltada para desviar de obstáculos no caminho e pegar itens ao longo dele. Um bom exemplo seriam as fases jogadas com Pura no jogo Crash Bandicoot: Warped.
Os problemas abordados por esse grupo de fase serão ansiedade, pânico, larica e perda da definição de tempo e espaço (tempo passa mais lento e distâncias são calculadas maiores). O jogador poderá perder por ansiedade caso pegue poucos itens verdes pelo caminho (ficará visível para o jogador gestos como a personagem roendo unhas). Caso o limite de ansiedade seja atingido, a personagem tem um ataque de pânico. Coletar demasiados itens verdes pelo caminho também pode ser prejudicial pois as distâncias exibidas ao jogador não corresponderão às reais (por exemplo, o início de um precipício pode ser mostrado depois do que realmente é, fazendo com que o jogador descuidado caia nele). Por último, a larica: haverá comidas ao longo da fase para o jogador pegar. Caso o jogador colete muitos itens verdes, sua barra de fome irá diminuir mais rápido e a personagem morrerá de fome.
Esse grupo de fases consiste em administrar bem os recursos que aparecem: se coletar poucos itens verdes, a personagem morrerá de ansiedade e se coletar demais, morrerá de fome (ou por ter calculado a distância errado). A dificuldade aumentará em cada fase por conta da dependência, ou seja, o nível de ansiedade irá diminuir cada vez mais rápido, forçando o jogador a coletar mais itens verdes e contornar a larica e problemas de cálculo de distância.
5.3.3 Tabaco
O hobby desse personagem será o basquete. Ele será uma exceção ao número de habilidades, pois terá quatro: dois estilos de drible, um arremesso e enterrada, sendo o padrão um drible e um arremesso. As cestas funcionarão como checkpoint da fase. Desafios da fase incluirão saltos, driblar adversário e correr de alguns marcadores.
O problema tratado será a dificuldade respiratória e aumento da frequência cardíaca, fazendo com que o personagem se canse mais rápido. Tais aspectos ficarão mais visíveis, pois o fundo da fase será em preto e branco e a tonalidade do cinza ficará cada vez mais escura à medida que as fases forem passando. Para o jogador será exibida uma barra de estamina, a qual irá diminuir drasticamente a cada nível. Cabe ao jogador administrar a estamina adequadamente, pois caso ele zere a barra, o personagem precisará parar para recuperar o fôlego (encher toda a barra novamente). Alguns dos modos de como o jogador pode perder o jogo seriam ser alcançado por um marcador, não conseguir marcar a cesta antes do tempo, não conseguir driblar um adversário. É válido ressaltar que o jogo não é de basquete, sendo assim, é apenas necessário que o personagem esteja a uma distância mínima da cesta para acertá-la.
5.3.4 LSD
Como essa é uma droga comumente utilizada em festas, o hobby do personagem é dançar. As três habilidades serão passos de dança, e utilizá-los com uma certa variedade resultará em mais pontos. Entretanto, para usar cada passo é necessário coletar itens no caminho, funcionando como um “especial”, similar ao Star Power no jogo Guitar Hero. A mecânica será uma mistura dos jogos Guitar Hero, Pump It Up e Crypt of The Necrodancer. Logo, para o personagem continuar se movendo, será necessário acertar os comandos requisitados ao longo da fase no ritmo da música.
A dificuldade principal desse grupo de fases serão os efeitos psicodélicos provocados pela droga. Esses efeitos atrapalharão a visão do jogador em relação a onde ele deve ir e até mesmo dos movimentos que deve realizar.
5.3.5 Fase final
No final de cada grupo, os personagens terão percebido que o uso das substâncias não contribuiu positivamente de modo algum para a vida deles, deixando de consumi-las. Sendo assim, na fase final os personagens terão de lidar com os efeitos reduzidos. O personagem do álcool ficará tonto com mais dificuldade, a da maconha não sofrerá mais com ansiedade, mas terá que lidar com a larica, o do tabaco ganhará um pouco mais de fôlego e os efeitos alucinógenos do LSD terão diminuído.
Na fase final, o personagem A terá se tornado um monstro gigante (válido do ponto de vista dele devido ao consumo exacerbado das drogas) e os quatro personagens terão de resgatá-los. O jogador terá de jogar uma fase “quatro em um” para superar o chefe final, isto é, jogará com cada um dos personagens uma vez (os outros três estariam incapacitados por terem uma recaída). Os desafios serão os mesmos de cada grupo de fase e a dificuldade está em passar por eles de uma única vez. No final do jogo, o personagem B (que praticava bullying) aparecerá novamente para se desculpar.
6 Plataforma de Dados Abertos para a Cidade do Natal
As preocupações dos governos nacionais relacionadas à transparência e ao “direito de saber” do cidadão datam do Século XVIII e têm sido tratadas formalmente desde a década de 1950. Mais recentemente, com o avanço das tecnologias e o surgimento da Web 2.0, o tema tem recebido grande atenção novamente, com a criação em 2011 da Parceria de Governo Aberto (OGP – Open Government Partnership), tendo o Brasil como um dos seus fundadores. Dentre os objetivos da OGP estão o aumento da transparência e responsabilização pública, através da abertura dos dados governamentais para acesso pela população. Recentemente, o Ministério do Planejamento, Desenvolvimento e Gestão (MPOG) do Brasil lançou seu Plano de Dados Abertos (PDA), que tem por objetivo organizar os processos de publicação dos dados no Ministério e incentivar outras organizações públicas a adotarem a iniciativa, reforçando o compromisso do governo em disseminar essas informações para a sociedade.
Nesse contexto, esta linha de trabalho do WP-Aplicações tem como objetivo de desenvolver um Portal de Dados Abertos da cidade de natal, com o propósito de divulgar as atividades e gastos públicos para a população, permitindo assim uma maior transparência, fiscalização, controle e participação, tanto pela população quanto pelos órgãos competentes, das atividades do setor público. O trabalho a ser desenvolvido representa uma ação multidisciplinar ao abordar uma temática atual tanto para a área de Computação e desenvolvimento de software, quanto para a área jurídica e social, que é a utilização de dados abertos governamentais e o empoderamento da população a partir do acesso a esses dados. Adicionalmente, ter-se-ia uma relação direta com a sociedade, através da proposta de disponibilização gratuita de aplicações que tenham impacto real na sociedade e na democracia brasileira, além do acompanhamento e utilização prática da implementação das políticas públicas nacionais de acesso a informação, como a Lei de Acesso à Informação (Lei nº 12.527, de 18 de novembro de 2011), e as ações do governo federal junto à OGP.
Para melhor contextualização do problema, este capítulo apresenta a fundamentação teórica que serve de base para o desenvolvimento do trabalho, resultante de estudos feitos sobre a literatura, bem como a metodologia a ser seguida para condução das atividades nos próximos trimestres. Mais ainda, são discutidos os resultados esperados a partir da concepção e desenvolvimento da Plataforma de Dados Abertos para a cidade do Natal.
6.1 Fundamentação teórica
No artigo Open Government Principle: Applying the right to know under the constitution, Wallace Parks levanta a preocupação de que, após a Segunda Guerra Mundial, muitas informações governamentais estavam sendo publicadas de forma incompleta,
suprimida ou apenas muito tempo após terem sido criadas27. Duas décadas depois, em 1974, o governo dos Estados Unidos lançou a ideologia do Government in the Sunshine, que foi a lei de governo aberto adotada no Estado da Flórida e rapidamente adotada em quase todos os Estados norte-americanos28.
Posteriormente na mesma década, David Ivester argumentou que o “direito constitucional de saber” é fundamental para a democracia29. No cenário atual da era da informação, baseada na comunicação em tempo real da Internet, vivencia-se um novo momento na criação, compartilhamento e consumo de grandes massas de dados, também conhecido como Big Data30. Considerando que os governos lidam com grandes massas de dados, as novas tecnologias de Big Data se apresentam como um poderoso ferramental para criação do que vem sendo chamado de Governo Aberto (Open Government) ou de Dados Abertos Governamentais (Open Government Data). Este é um conceito novo, apesar de baseado em ideias bastante antigas, como mencionado anteriormente. Em 2011, Tim O’Reilly propôs uma definição de Governo Aberto bastante aceita tanto pela academia como pela indústria, em que diz que o Governo Aberto se caracteriza como o uso da tecnologia, especialmente as tecnologias colaborativas no coração da Web 2.0, para solucionar da melhor maneira problemas coletivos em níveis de cidade, estado, nações ou internacionalmente31.
A abertura dos governos usando as novas Tecnologias de Informação e Comunicação (TICs) podem trazer grandes benefícios para a população. No início do novo milênio, as práticas de transparência não tinham impacto significativo sobre a responsabilização pública, como discutido por Wilson Wong e Eric Welch, que analisaram dados até o ano 200032. Por outro lado, a partir dessa nova definição de Governo Aberto, iniciada nesta década, novos resultados começaram a ser obtidos. Thomas Andersen defendia em 2009 que as TICs podem ser utilizadas como uma estratégia contra a corrupção33. Um ano depois, John Bertot et al. chegaram a conclusões semelhantes, de que as TICs podem ser utilizadas para a criação de uma cultura de transparência e que a 27 Wallace Parks. The Open Government Principle: Applying the right to know under the Constitution. The
George Washington Law Review, vol. 26, no. 1, Oct. 1957. 28 Joseph W. Little, Thomas Tompkins. Open Government Laws: An insider’s view. North Carolina Law
Review, vol. 53, no. 3, 1975. 29 David Ivester. The constitutional right to know. Hastings Constitutional Law Quarterly, vol. 4, 1977, pp.
109-163. 30 Danah Boyd, Kate Crawford. Six provocations for Big Data. A decade in Internet Time: Symposium on the
Dynamics of the Internet and Society, Sep. 2011. 31 Tim O’Reilly. Government as a platform. Innovations: Technology, Governance, Globalization, vol. 6, no.
1, 2011, pp. 13-40. 32 Wilson Wong, Eric Welch. Does E-Government promote accountability? A comparative analysis of
website openness and government accountability. Governance, vol. 17, no. 2, Apr. 2004, pp. 275-297. 33 Thomas Andersen. E-Government as an anti-corruption strategy. Information Economics and Policy, vol.
21, no. 3, Aug. 2009, pp. 201-210.
popularização do Governo Aberto e Governo Eletrônico, aliado às mídias sociais, podem ser utilizadas pela sociedade como ferramentas efetivas contra a corrupção34. Mais recentemente, Djoko Sayogo e Teresa Harrison35 estudaram os efeitos da Internet e de fatores socioculturais sobre a transparência e responsabilização pública, a partir dos dados publicados pelos governos, concluindo que a difusão da Internet é um componente importante para o aumento da transparência e responsabilização. Adicionalmente, além desse cenário de transparência e responsabilização, o uso de TICs e Governo Aberto pode proporcionar outros benefícios para a população, como apresentado por Sergio Picazo-Vela et al., que concluem que a integração de iniciativas governamentais com as mídias sociais tem o potencial de promover a saúde pública36.
Apesar dessas vantagens, a utilização dos dados abertos governamentais apresenta alguns desafios, tanto técnicos quanto não-técnicos. Dentre os aspectos técnicos, David Robinson et al. destacam a dificuldade dos governos de criarem sites baseados em seus dados que sejam úteis para a população37. Além disso, Kellyton Brito et al. destacam problemas como a origem dos dados ser múltipla e descentralizada, a falta de padrões para publicação, a existência de dados “zumbis” e a predominância de dados de mão única, sem opção de retorno da população para os governos38. Considerando os aspectos não técnicos, Whasun Jho analisa os conflitos entre a abertura do governo da Coreia do Sul, com prioridade em eficiência, e os anseios da sociedade civil, com prioridade em privacidade39. Nesta mesma linha, Suzanne Piotrowski e Gregg Van Ryzin analisam a atitude da população nem sempre favorável a abertura dos governos40. Por fim, Danish Dada
34 John C. Bertot, Paul T. Jaeger, Justin M. Grimes. Using ICTs to create a culture of transparency: E-
Government and social media as openness and anti-corruption tools for societies. Government Information Quarterly, vol. 27, no. 3, Jul. 2010, pp. 264-271.
35 Djoko Sigit Sagoyo, Teresa Harrison. Effects f the Internet and sociocultural factors on budget transparency and accountability. In: Proceedings of the 13th Annual International Conference on Digital Government Research (dg.o’12), College Park, MA, USA. New York, NY, USA: ACM, 2012, pp. 11-20.
36 Sergio Picazo-Vela, Marilu Fernandez-Haddad, Luis F. Luna-Reyes. IT’s alive!! Social media to promote public health. In: Proceedings of the 14th Annual International Conference on Digital Government Research (dg.o’13), Québec, Canada. New York, NY, USA: ACM, 2013, pp. 111-119.
37 David Robinson, Harlan Yu, William P. Zeller, Edward W. Felten. Government data and the invisible hand. Yale Journal of Law & Technology, vol. 11, no. 1, 2009,
38 Kellyton dos Santos Brito, Marcos Antônio da Silva Costa, Vinicius Cardoso Garcia, Silvio Romero de Lemos Meira. Brazilian government open data: Implementation, challenges, and potential opportunities. In: Proceedings of the 15th Annual International Conference on Digital Government Research (dg.o’15), Aguascallientes, Mexico. New York, NY, USA: ACM, 2014, pp. 11-16.
39 Whasun Jho. Challenges for e-governance: Protests from civil society on the protection of privacy in e-government in Korea. International Review of Administrative Sciences, vol. 71, no. 1, 2005, pp. 151-166.
40 Suzanne J. Piotrowski, Gregg G. Van Ryzin. Citizen attitudes toward transparency in local government. The American Review of Public Administration, vol. 37, no. 3, 2016, pp. 306-323.
apresenta uma revisão da literatura em relação ao Governo Eletrônico, considerando que até então esta abordagem tinha falhado nos países em desenvolvimento41. Verifica-se, portanto, que a área de Governo Aberto é uma área multidisciplinar, abrangendo tanto a pesquisa em Computação quanto em áreas sociais. Além disso, tem recebido grande atenção da academia mundial, tentando consolidar os conceitos e aplicá-los na prática para obtenção de resultados para a sociedade.
6.2 Metodologia
No âmbito do Projeto Smart Metropolis, a presente linha de trabalho para o desenvolvimento do Portal de Dados Abertos da cidade do Natal será conduzida em cinco etapas. A primeira envolve o gerenciamento do trabalho e estabelecimento de parcerias. As demais etapas estão relacionadas com a preparação da infraestrutura, desenvolvimento da solução, organização das fontes de dados, coleta dos dados e testes individuais, bem como testes integrados da plataforma como um todo. As atividades referentes a essas etapas já foram iniciadas e seus resultados serão apresentados com maiores detalhes no próximo relatório.
1) Gerenciamento. Esta etapa diz respeito a planejamento, monitoramento e controle de escopo, prazos e custos, incluindo definição da liderança técnica, assim como a gerência de configuração. As fontes de dados para a plataforma também foram identificadas.
2) Definição das arquiteturas. Nesta etapa foram investigadas as tecnologias que poderiam ser aplicadas e também especificados e detalhados os requisitos de cada módulo. Também nesta etapa, foram definidas as arquiteturas a serem aplicadas a cada módulo. A organização das fontes que fornecerão os dados à plataforma foi executada nesta fase, bem como definidos métodos de coleta de dados.
3) Desenvolvimento da solução. Esta etapa diz respeito ao desenvolvimento dos algoritmos e implementação da solução de integração e divulgação dos dados. Além disso, tem-se o estudo dos diversos tipos de técnicas para análise de dados e desenvolvimento das ferramentas de análise, bem como o desenvolvimento dos módulos previstos de acordo com as especificações definidas nas etapas anteriores.
4) Avaliação da plataforma. Esta etapa refere-se à validação de toda a plataforma através de testes de robustez, desempenho e integridade das informações providas pela plataforma.
5) Catalogação e publicação do conjunto de dados abertos. Nesta etapa tem-se a indicação dos conjuntos de dados candidatos a serem publicados com a participação de diversos atores ligados à administração da cidade do Natal, além da priorização dos dados 41 Danish Dada. The failure of E-Government in developing countries: A literature review. The Electronic
Journal of Information Systems in Developing Countries, vol. 26, no. 7, 2006, pp. 1-10.
para abertura e publicação do primeiro conjunto de dados abertos. Esta etapa em particular está em andamento.
6.3 Resultados esperados
Como resultados mais específicos, visa-se a concepção e desenvolvimento de uma infraestrutura computacional para integração e publicação de dados governamentais abertos. Essa infraestrutura terá o Portal de Dados Abertos como o principal sistema visível aos usuários finais, mas diversos componentes precisarão ser desenvolvidos para recuperar os diferentes dados públicos e integrá-los em um repositório único, para então disponibilizá-los para o público alvo final. Tais dados serão disponibilizados através de APIs ou fontes de dados, sendo o primeiro o modo mais adequado para dados que mudam constantemente, enquanto o último é mais adequado para dados mais estáticos. A solução será inspirada em iniciativas bem-sucedidas no Brasil e em outros países, tais como Dados Abertos do Senado Federal42, Dados Abertos do Governo Federal43, Dados da Cidade do Recife44 e Dados do Governo de Pernambuco45.
Além da infraestrutura relacionada ao Portal de Dados Abertos, espera-se que sejam desenvolvidas aplicações e sistemas de software que façam uso dos dados abertos do Portal. Para viabilizar este resultado, serão realizadas ações de estímulo ao desenvolvimento destas soluções, através da promoção de competições e concursos, com o objetivo de estimular estudantes e pesquisadores a desenvolver projetos e aplicações envolvendo os dados abertos. Exemplos bem-sucedidos de ações como essa são os hackathons, que acontecem por todo o Brasil e pelo mundo.
Espera-se que ao longo da execução do presente trabalho sejam desenvolvidas pelo menos duas aplicações por pessoas externas ao projeto, de modo a confirmar o interesse da sociedade em fazer uso dos dados abertos. O mesmo tipo de estratégia já vem funcionando em outras regiões do Brasil, como é o caso do sistema Meu Congresso46, e também em outras iniciativas pelo mundo, a exemplo do Code for America47.
42 Senado do Brasil. Dados Abertos Legislativos. Disponível em: http://dadosabertos.senado.leg.br/ 43 Brasil. Portal Brasileiro de Dados Abertos. Disponível em: http://dados.gov.br/ 44 Prefeitura do Recife. Portal de Dados Abertos da Cidade do Recife. Disponível em:
http://dados.recife.pe.gov.br/ 45 Governo de Pernambuco. Portal de Dados Abertos. Disponível em: http://www.dadosabertos.pe.gov.br/ 46 Kellyton Brito et al. Meu Congresso Nacional. Disponível em: http://www.meucongressonacional.com/ 47 Code for America Labs, Inc. Code for America. Disponível em: https://www.codeforamerica.org/