Anais do III Workshop de Iniciação Científica em

Transcrição

XII Simpósio Brasileiro de Sistemas de Informação
Anais do III Workshop de Iniciação
Científica em Sistemas de Informação
Castelmar Hotel – Florianópolis/SC – 17 a 20 de maio de 2016
Promoção
Organização
Patrocínio
Apoio
III Workshop de Iniciação Científica em
Sistemas de Informação (WICSI)
Evento integrante do XII Simpósio Brasileiro de
Sistemas de Informação
De 17 a 20 de maio de 2016
Florianópolis – SC
ANAIS
Sociedade Brasileira de Computação – SBC
Organizadores
Roberto Willrich
Vinícius Sebba Patto
Frank Augusto Siqueira
Patrícia Vilain
Realização
INE/UFSC – Departamento de Informática e Estatística/
Universidade Federal de Santa Catarina
Promoção
Sociedade Brasileira de Computação – SBC
Patrocínio Institucional
CAPES – Coordenação de Aperfeiçoamento de Pessoal de Nível Superior
CNPq - Conselho Nacional de Desenvolvimento Científico e Tecnológico
FAPESC - Fundação de Amparo à Pesquisa e Inovação do Estado de Santa Catarina
Catalogação na fonte pela Biblioteca Universitária
da
E56 a
Workshop de Iniciação Científica em Sistemas de Informação (WICSI)
(3. : 2016 : Florianópolis, SC)
Anais [do] Workshop de Iniciação Científica em Sistemas de Informação
(WICSI) [recurso eletrônico] / Organizadores Roberto Willrich...[et al.] ;
realização Departamento de Informática e Estatística/UFSC ; promoção:
Sociedade Brasileira de Computação. – Florianópolis : UFSC/Departamento
de Informática e Estatística, 2016.
1 e-book
Evento integrante do XII Simpósio Brasileiro de Sistemas de Informação
Disponível em: http://sbsi2016.ufsc.br/anais/
Evento realizado em Florianópolis de 17 a 20 de maio de 2016.
ISBN 978-85-7669-319-2
1. Sistemas de recuperação da informação – Congressos. 2. Tecnologia
– Serviços de informação – Congressos. 3. Internet na administração pública
– Congressos. I. Willrich, Roberto. II. Universidade Federal de Santa
Catarina. Departamento de Informática e Estatística. III. Sociedade
Brasileira de Computação. IV. Título.
CDU: 004.65
III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
III WICSI
III Workshop de Iniciação Científica em Sistemas de Informação (WICSI)
Evento integrante do XII Simpósio Brasileiro de Sistemas de Informação (SBSI)
17 a 20 de Maio de 2016
Florianópolis, Santa Catarina, Brazil.
Comitês
Coordenação Geral do SBSI 2016
Frank Augusto Siqueira (UFSC)
Patrícia Vilain (UFSC)
Coordenação do Comitê de Programa do WICSI 2016
Roberto Willrich (UFSC)
Vinicius Sebba Patto (UFG)
Comissão Especial de Sistemas de Informação
Clodis Boscarioli (UNIOESTE)
Sean Siqueira (UNIRIO)
Bruno Bogaz Zarpelão (UEL)
Fernanda Baião (UNIRIO)
Renata Araujo (UNIRIO)
Sérgio T. de Carvalho (UFG)
Valdemar Graciano Neto (UFG)
Comitê de Programa Científico do WICSI 2016
Alexander Roberto Valdameri (FURB)
Celia Ralha (UNB)
Christiane Gresse von Wangenheim (UFSC)
Clodis Boscarioli (UNIOESTE)
Cristiane Ferreira (UFG)
Daniel Kaster (UEL)
Elisa Huzita (UEM)
Ellen Francine Barbosa (ICMC-USP)
Fabiana Mendes (UnB)
Fabiane Barreto Vavassori Benitti (UFSC)
Fatima Nunes (EACH-USP)
Iwens Sene Jr (UFG)
Jean Hauck (UFSC)
João Porto de Albuquerque (ICMC-USP)
Luanna Lopes Lobato (UFG)
Marcello Thiry (UNIVALI)
Marcelo Morandini (USP)
Maria Inés Castiñeira (UNISUL)
Mauricio Capobianco Lopes (FURB)
Merisandra Côrtes de Mattos (UNESC)
Ovidio Felippe da Silva Júnior (UNIVALI)
Pablo Schoeffel (UDESC)
Renato Bulcão Neto (UFG)
Renato Fileto (UFSC)
Rosângela Penteado (UFSCar)
Vitório Mazzola (UFSC)
Revisores
Antônio Esteca (USP)
Flávia Horita (USP)
Kalinka Castelo Branco (USP)
Lívia Castro Degrossi (USP)
iv
Realização
INE/UFSC – Departamento de Informática e Estatística/ Universidade Federal de Santa Catarina
Promoção
SBC – Sociedade Brasileira de Computação
Patrocínio
CAPES – Coordenação de Aperfeiçoamento de Pessoal de Nível Superior
CNPq - Conselho Nacional de Desenvolvimento Científico e Tecnológico
FAPESC - Fundação de Amparo à Pesquisa e Inovação do Estado de Santa Catarina
FAPEU - Fundação de Amparo à Pesquisa e Extensão Universitária
Apoio
Centro Tecnológico - UFSC
Pixel Empresa júnior - UFSC
v
Apresentação
A iniciação científica é a base para formar futuros pesquisadores em todas as áreas de conhecimento. Com essa convicção, a
Comissão Especial de Sistemas de Informação da SBC criou o Workshop de Iniciação Científica em Sistemas de Informação
(WICSI). O WICSI é um evento nacional para divulgação de resultados de trabalhos de pesquisa em nível de Graduação na
área de Sistemas de Informação. O objetivo do WICSI é incentivar o desenvolvimento de pesquisas de Iniciação Científica e,
para tanto, busca estimular futuros pesquisadores da comunidade de Sistemas de Informação a apresentar seus trabalhos.
Em 2016, foi realizada a terceira edição do WICSI, contando com 41 artigos submetidos e, destes, 13 foram aprovados
(32%) com rigorosa e competente avaliação realizada pelos revisores. Durante o evento, os artigos aprovados foram apresentados oralmente pelos seus respectivos autores. Os temas tratados nos artigos envolvem o uso de técnicas de computação em
várias áreas de conhecimento ou atuação, tais como: metodologias de desenvolvimento de software, usabilidade, educação,
armazenamento e processamento de informações.
Agradecemos aos autores que submeteram seus trabalhos, aos revisores que prontamente nos atenderam e à coordenação
geral do SBSI 2016 pelo apoio para realização do III WICSI.
Florianópolis, Maio de 2016.
Coordenação do WICSI 2016
vi
Biografia dos Coordenadores do Comitê de Programa do WICSI 2016
Roberto Willrich possui graduação e mestrado em Engenharia Elétrica pela Universidade Federal de Santa Catarina (1987 e 1991) e doutorado em Informática pela Université de Toulouse
III/França (Paul Sabatier) (1996). Ele realizou um estágio pós-doutoral no Laboratoire d’Analyse
et d’Architecture des Systemes, LAAS, França (2005-2006). Atualmente é professor titular da
Universidade Federal de Santa Catarina. Tem experiência na área de Ciência da Computação,
com ênfase em Repositórios Digitais, Web Semântica, Anotações Digitais, Informática na Educação.
Vinícius Sebba Patto é professor adjunto pelo Instituto de Informática da Universidade Federal
de Goiás. Possui doutorado em Ciência da Computação pelo LIP6 - Laboratoire d’Informatique
de Paris 6 (2010). Possui mestrado em Engenharia de Computação pela Universidade Federal
de Goiás (2005) e graduação em Análise de Sistemas pela Universidade Salgado de Oliveira
(2000). Tem experiência na área de Ciência da Computação e Sistemas de Informação, com
ênfase em Sistemas Inteligentes, atuando principalmente nas seguintes áreas: lógica nebulosa,
sistemas multiagentes, sistemas de suporte a decisão, gerenciamento participativo, modelagem
de dados, simulação, modelagem de sistemas e linguagens de programação.
vii
Artigos Técnicos
ST1 - Aplicações e Aspectos Humanos de SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Desenvolvimento de um Jogo Digital como Objeto de Aprendizagem em um Curso de Sistemas para Internet . . . . . . . . 1
Alexandre Soares Silva (IFMS), Viviane Andrade da Silva (IFMS)
RNA Aplicada a Modelagem Hidrológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Marcos Rodrigo Momo (UNIFEBE), Pedro Sidnei Zanchett (UNIFEBE), Cristian Zimmermann de Araújo (UNIFEBE),
Wagner Correia (UNIFEBE), Christian R.C. de Abreu (Prefeitura de Blumenau)
Terceirização de Sistemas de Informação no Setor Público: Uma Revisão Sistemática de Literatura . . . . . . . . . . . . . . . . . 9
Matheus Icaro Agra Lins (IFAL), José da Silva Duda Junior (IFAL), Mônica Ximenes Carneiro da Cunha (IFAL)
Uma Comparação entre o Desenvolvimento de Aplicações Web Convencionais e Aplicações em Nuvem . . . . . . . . . . . . . 13
Bruno Lopes (IFSP), Kleber Manrique Trevisani (IFSP)
ST2 - Desenvolvimento e Gestão Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Seleção de Ferramenta de Gestão de Demandas de Desenvolvimento Ágil de Software para Órgão Público . . . . . . . . . . 17
Emilie Morais (UnB), Geovanni Oliveira (FGA/UnB), Rejane Maria da Costa Figueiredo (UnB), Elaine Venson (UnB)
Um Plugin para Discretização dos Dados para Suporte à Metodologia Agile ROLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Luan S. Melo (UENP), André Menolli (UENP), Glauco C. Silva (UENP), Ricardo G. Coelho (UENP),
Felipe Igawa Moskado (UENP)
ST3 - Desenvolvimento de Interfaces, Usabilidade e Testes em SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Análise de Usabilidade em Sistema de Resposta Audível automatizada, com base no Percurso Cognitivo,
Critérios Ergonômicos de Bastien e Scapin e Heurísticas de Nielsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Aline Cristina Antoneli de Oliveira (UFSC), Maria José Baldessar (UFSC),
Leonardo Roza Mello (Faculdade SENAI-Florianópolis), Priscila Basto Fagundes (Faculdade SENAI-Florianópolis)
Guia de Boas Práticas para Desenvolvimento de Interface e Interação para Desenvolvedores da Plataforma
Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Guaratã Alencar Ferreira de Lima Junior (Faculdade AVANTIS), Rodrigo Cezario da Silva (Faculdade AVANTIS)
Automação de Testes em Sistemas Legados: Um Estudo de Caso para a Plataforma Flex . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Augusto Boehme Tepedino Martins (UFSC), Jean Carlo Rossa Hauck (UFSC)
ST4 - Armazenamento e Processamento de Informações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Análise do uso de técnicas de pré-processamento de dados em algoritmos para classificação de proteínas . . . . . . . . . . . 39
Lucas Nascimento Vieira (Univille), Luiz Melo Romão (Univille)
Desenvolvimento da Técnica Data Mining como Apoio à Tomada de Decisão no Sistema Hidrológico para
Geração de Estatística das Estações de Telemetria da Defesa Civil de Brusque - SC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Jonathan Nau (UNIFEBE), Pedro Sidnei Zanchett (UNIFEBE), Wagner Correia (UNIFEBE),
Antonio Eduardo de Barros Ruano (Univ. de Algarve, Portugal), Marcos Rodrigo Momo (UNIFEBE)
Uma arquitetura de banco de dados distribuído para armazenar séries temporais provenientes de IoT . . . . . . . . . . . . . 48
Fernando Paladini (UFSC), Caique R. Marques (UFSC), Antonio Augusto Frohlich (UFSC), Lucas Wanner (UNICAMP)
viii
Utilização e Integração de Bases de Dados Relacionais por meio de Foreign Tables para utilização em
ferramentas OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Felipe Igawa Moskado (UENP), André Menolli (UENP), Glauco C. Silva (UENP), Ricardo G. Coelho (UENP),
Luan S. Melo (UENP)
Index of Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
ix
Desenvolvimento de um Jogo Digital como Objeto de
Aprendizagem em um Curso de Sistemas para Internet
Alternative Title: Development of a Digital Game as learning
object in a Systems for the Internet Course
Alexandre Soares da Silva
Viviane Andrade da Silva
Instituto Federal de Mato Grosso do Sul (IFMS)
R. Treze de Maio, 3086, campus Campo Grande
Centro, Campo Grande - MS
+55 (67) 3378-9500
Instituto Federal de Mato Grosso do Sul (IFMS)
R. Treze de Maio, 3086, campus Campo Grande
Centro, Campo Grande - MS
+55 (67) 3378-9500
[email protected]
[email protected]
RESUMO
Categories and Subject Descriptors
Devido sua característica lúdica e multidisciplinar, jogos digitais
são utilizados nas mais diversas áreas como ferramentas e objetos
de aprendizagem. Este artigo apresenta o desenvolvimento de um
jogo digital, planejado para rodar em navegadores web, cujo
conteúdo pretende contribuir para o desenvolvimento do
raciocínio lógico e habilidades em solucionar problemas de
estudantes de um curso Tecnológico de Sistemas para Internet. A
mecânica do jogo exibe, na forma de puzzles interativos,
problemas aplicados de lógica. Não obstante, sua arquitetura
também permite a inserção destes puzzles criados de forma
independente, sem muitas restrições de projeto. Deste modo, o
jogo é empregado como objeto de aprendizagem onde os
estudantes colaboram implementando recursos adicionais
enquanto paralelamente praticam algumas das habilidades
desejadas pelo curso.
K.3.2 [Computers an Education]: Computer and Information
Science Education – Information Systems education; K.8.0
[Personal Computing]: General – Games.
General Terms
Algorithms, Design
Keywords
digital games; programing; learning objects; web development
1.INTRODUÇÃO
Jogos digitais, videojogos ou ainda games, como são mais
comumente chamados, proveem uma forma lúdica de desenvolver
determinada tarefa proposta pelo próprio jogo. Para determinado
grupo de jogos, existe um conjunto de funções comuns entre eles
como, por exemplo, algoritmos de ocultação de superfícies,
rotinas de renderização, estruturas de dados para representar os
atores, bibliotecas com funções matemáticas, dentre outros. Este
conjunto de funções comuns entre um determinado grupo de jogos
é chamado motor ou engine. O motor existe para que, a cada novo
jogo não seja necessário implementar novamente todos os
recursos comuns, além de otimizar o tempo de desenvolvimento e
consequentemente os custos.
Palavras-chave
Jogos digitais; programação; objetos de aprendizagem;
desenvolvimento web
ABSTRACT
Because its playful and multidisciplinary aspects, games are used
in several areas as tools and learning objects. This paper presents
the development of a game designed to run on web browsers
which purpose is develop logical thinking and problems solving
skills in students of a Systems for the Internet Technology course.
The game mechanism displays, as interactive puzzles, applied
logic problems. Nevertheless, its architecture also allows the
addition of independently created puzzles, without many design
constraints. Thus, the game is used as an object of learning, where
students collaborate implementing additional features while at the
same time practicing some of the skills demanded by the course.
Permission to make digital or hard copies of all or part of
this work for personal or classroom use is granted without
fee provided that copies are not made or distributed for
profit or commercial advantage and that copies bear this
notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute
to lists, requires prior specific permission and/or a fee.
Do mesmo modo, o projeto e desenvolvimento de um jogo digital
por si só possui natureza multidisciplinar pois engloba arte,
cultura, processamento gráfico, comunicação via rede,
armazenamento de informações, engenharia de software,
sonorização, dentre outras áreas. Portanto, engloba áreas da
computação como computação gráfica, redes de computadores,
engenharia de software, métodos numéricos, dentre outras.
Levando em consideração esta multidisciplinaridade, em 2012
iniciamos um projeto de desenvolvimento de um motor 2D
simples para criação de jogos para web usando apenas recursos
nativos dos navegadores como HTML5, CSS e JavaScript, sem
qualquer plugin ou extensão. Essa decisão foi tomada porque a
intenção era criar um motor com objetivo primariamente didático,
sem intenção de competir com os motores já existentes. A ideia
era de utilizá-lo como ferramenta para ensinar o funcionamento
geral de um motor de jogos partindo de um código muito mais
simples do que os existentes. Os estudantes, neste caso do CST 1
em Sistemas para Internet, poderiam modificá-lo, visualizar o
efeito das alterações e ao mesmo tempo praticar programação em
SBSI 2016, May 17–20, 2016, Florianópolis, Santa Catarina, Brazil.
Copyright SBC 2016.
1
1
Curso Superior de Tecnologia
JavaScript – linguagem de script na qual o motor foi construído.
Todavia, o motor por si só não empolgava tanto os estudantes do
curso que não participaram das etapas de seu desenvolvimento,
era necessário desenvolver um jogo para que algo fosse
efetivamente visualizado e jogado. Em 2014, iniciamos o projeto
de construção de um jogo digital intitulado Brain Adventure com
objetivo de auxiliar o aprendizado de algoritmos e programação.
Trata-se de um cenário interativo com perspectiva isométrica onde
a personagem interage com outros objetos (Figura 1) ou atores
que disparam puzzles (quebra-cabeças ou desafios de lógica).
Baseados em desafios de lógica ou problemas algorítmicos
simples, o objetivo dos quebra-cabeças era permitir aos estudantes
construir um mapa mental dos tipos mais comuns de problemas de
lógica encontrados na programação, porém de uma forma mais
lúdica do que a convencional como, por exemplo, o problema da
travessia de um rio por barco, onde um agricultor pode levar
apenas a si mesmo e uma única de suas compras: o lobo, a cabra,
ou a maçã (na literatura há variantes do puzzle com outros itens).
Se forem deixados sozinhos em uma mesma margem, o lobo come
a cabra, e a cabra come a maçã. O desafio consiste em atravessar a
si mesmo e as suas compras para a margem oposta do rio,
deixando cada compra intacta (Figura 2).
Figura 2: Uma variação do desafio da travessia de compras
por um rio com interface arrastar e soltar. A ideia é que o
estudante perceba estruturas condicionais que devem ser
utilizadas para solucionar o problema.
2.FUNDAMENTAÇÃO TEÓRICA
Segundo o Comitê de Padrões de Tecnologia de Aprendizagem da
IEEE2, um objeto de aprendizagem pode ser caracterizado por uma
entidade, digital ou não, que pode ser usada para aprendizagem,
educação ou treinamento [4]. Wiley D. A. [9] dá uma visão mais
próxima dos objetos deste trabalho, definindo um objeto de
aprendizagem como qualquer recurso digital que pode ser reusado
para apoiar a aprendizagem. A ideia principal é quebrar o
conteúdo educacional em pequenos pedaços que possam ser
reusados em vários ambientes de aprendizagem, tal qual no
paradigma da programação orientada a objetos.
Com o amadurecimento do projeto e considerando os relatos dos
próprios estudantes, vimos que a programação dos puzzles do jogo
despertava mais interesse do que simplesmente jogá-lo. Além
disso, é possível construí-los utilizando como base o
conhecimento adquirido durante o próprio CST em Sistemas para
Internet. Quando finalizado, cada artefato desenvolvido pode ser
incluído no jogo completo devido a sua arquitetura desacoplada. A
criação de novos desafios para incrementar este jogo é uma
alternativa na elaboração de atividades inerentes ao próprio curso
como, por exemplo, atividades complementares, trabalhos de
disciplinas de desenvolvimento web ou programação de
computadores. Vale ressaltar que, mesmo sendo construído
colaborativamente pelos estudantes, o jogo não tem como
pretensão substituir as aulas tradicionais, mas sim atuar como uma
ferramenta alternativa de aprendizagem auxiliando na construção
de habilidades previstas pelo projeto pedagógico do curso.
Objetos de aprendizagem já são amplamente utilizados nas mais
diversas áreas. Umas dessas áreas é a da programação de
computadores e competências relacionadas. Isso ocorre
basicamente porque a capacidade cognitiva dos estudantes
novatos em entender um problema é base fundamental para a
leitura e escrita de programas; domínio dos conceitos básicos de
programação é vital para a escrita de um bom programa [8]. Para
aprender a programar é necessário o entendimento correto de
alguns conceitos abstratos, conhecimentos sobre linguagens de
programação, ferramentas, habilidades de solucionar problemas,
estratégias no planejamento e implementação de um programa.
Além disso, o maior problema de programadores novatos não é de
aprender os conceitos básicos, mas sim aprender como utilizá-los.
Dois fatores cognitivos apresentam-se como prováveis
responsáveis por deixar o aprendizado a programar mais difícil –
estilo de aprendizado e motivação [5]. Em outras palavras, é
possível que exista um estilo de aprendizagem particular que
permita ao estudante adquirir habilidades de programação mais
facilmente, ou pode ser que os estudantes precisem de uma forma
particular de motivação. Neste sentido, um jogo digital, se
convenientemente projetado, pode ser usado como objeto de
aprendizagem eficaz na construção do conhecimento e do
raciocínio. De fato, atualmente os jogos digitais têm sido
frequentemente empregados como ferramentas lúdicas para
auxiliar no aprendizado na área de informação e comunicação,
principalmente em relação a programação [1, 2, 3, 6, 7].
A Seção 2 apresenta a fundamentação teórica por trás da ideia do
projeto. Descrevemos pontos relevantes da metodologia de
desenvolvimento do jogo na Seção 3. Em seguida, na Seção 4,
relatamos os resultados obtidos até o momento e posteriormente
concluímos este trabalho na Seção 5.
Se por um lado sua característica lúdica é um dos recursos mais
motivadores de um jogo, grande parte dos jogos desenvolvidos
como objetos de aprendizagem pertencem a categoria dos
chamados jogos sérios, ou jogos educativos; estes por sua vez não
possuem a diversão como foco principal, o que em alguns casos,
pode torná-lo uma atividade entediante. O jogo desenvolvido
durante este projeto tem como principal contribuição a
participação dos estudantes também na sua criação,
Figura 1: Cenário isométrico com desafios. Desafios são
indicados por um sinal: verde se solucionado, amarelo caso
iniciado mas ainda não solucionado ou vermelho se ainda não
foi acessado.
2
2
Institute of Electrical and Electronics Engineers
programaticamente; não se limita a um jogo disponível apenas
para ser jogado. Além disso, há liberdade de que cada desafio seja
criado independentemente dos outros, de certa forma, sem muitas
restrições de projeto. As únicas restrições impostas são: não
utilizar plugins ou qualquer tecnologia que necessite instalação e
manter apenas quebra-cabeças relacionados às competências
cognitivas desejadas nos estudantes.
3.METODOLOGIA DE PESQUISA
Definidas as ideias iniciais do projeto de pesquisa, criamos um
documento de game design descrevendo o enredo, cenário,
personagens, fases e alguns quebra-cabeças, quais seriam os
elementos de jogo e sua interação com o jogador. Nesta primeira
versão definimos 6 (seis) desafios de raciocínio lógico como
quebra-cabeças disponíveis. A escolha dos quebra-cabeças é
baseada em desafios de lógica retirados de livros sobre puzzles
clássicos ou aplicados a algoritmos. O objetivo era iniciar a
implantação do jogo e futuramente expandir a ideia para outros
cursos da área. Nesta etapa, definimos também a arquitetura
básica do projeto: cada fase seria representada por uma página
web, em um cenário isométrico, onde haveriam objetos interativos
e cada um destes objetos poderiam disparar desafios
predeterminados. A escolha pela perspectiva isométrica deu-se
pelo fato de ser possível trabalhar com gráficos 2D e
posicionamento espacial de forma mais simples do que com
gráficos 3D, mas ainda sim simulando um aspecto tridimensional.
Não obstante, a modelagem tridimensional ocuparia um tempo
considerável da equipe e o projeto poderia ter seu escopo alterado.
Figura 3: Arquitetura básica do projeto do jogo
Criado o primeiro protótipo, o mesmo foi submetido a apreciação
de alguns estudantes e professores através de apresentações. Isso
serviu para reavaliar algumas decisões como, por exemplo,
utilizar os mesmos desafios para todos os personagens
disponíveis, evitando assim comparações de gênero, idade, ou
características físicas com a dificuldade dos desafios. Reavaliando
as contribuições esperadas, a principal contribuição passou a ser a
possibilidade de encaixar o desenvolvimento dos puzzles como
objeto de aprendizagem, pois o interesse era maior em criar
quebra-cabeças do que jogar. Planejamos então a aplicação de
algumas atividades (as quais serão expandidas futuramente):
O passo seguinte foi selecionar um motor para jogos adequado.
Primando por um motor com caráter mais didático do que
comercial, optamos pelo motor para jogos 2D desenvolvido
dentro da própria instituição de ensino por membros do grupo de
pesquisa NIJOD – Núcleo Interdisciplinar de Pesquisa para Jogos
Digitais. Para a implementação da lógica dos desafios e
manipulação das informações sobre os jogadores utilizamos a
tecnologia JSP3. Durante o processo, tomamos o cuidado de
permitir o desenvolvimento dos quebra-cabeças sem a
obrigatoriedade de conhecer o motor, recursos avançados do
HTML5 ou qualquer outra tecnologia em especial. Assim, bastaria
implementar a página web com o desafio e em seguida acoplá-la
ao cenário principal. Este acoplamento funciona através de uma
API do próprio jogo que recebe e envia dados no formato JSON4,
facilitando a integração. Essa integração não será necessariamente
tarefa de quem implementou o desafio; por exemplo, cada
estudante pode criar uma parte do puzzle como o layout, a arte, a
lógica em JavaScript, a consulta e gravação das respostas no
banco de dados ou chamadas dos controladores e assim por
diante. A Figura 3 mostra a ideia básica da arquitetura do jogo. O
projeto do banco de dados responsável por armazenar informações
sobre jogadores, progressos e desafios foi criado após a definição
de alguns dos desafios. Desejávamos uma modelagem que
atendesse todos os desafios de forma genérica, fornecendo as
respostas, dicas, dentre outras informações sem a necessidade de
remodelar a base de dados a cada novo desafio criado. Qualquer
que seja o quebra-cabeça, ele pode possuir atributos comuns aos
outros, por exemplo, dicas, resposta, descrição e título.
3

Implementação de desafios completos e funcionais
(layout, recursos, lógica) como parte de atividades
complementares do curso.

Criação ou melhoria de layouts dos desafios ou telas do
jogo (desenvolvimento web inicial)

Implementação da lógica e persistência de dados no
servidor para os layouts já desenvolvidos.
(desenvolvimento web mais avançado)

Implementação de algoritmos para os desafios como
validação, respostas, contagem de pontos, etc.
(programação de computadores)
Da mesma maneira vislumbramos a possibilidade de criar
atividades relacionados ao jogo em projetos integradores ou
trabalhos em cursos técnicos da área.
4.RESULTADOS
A princípio, o objetivo era criar um jogo para incentivar o
pensamento algorítmico nos estudantes do CST em Sistemas para
Internet. Entretanto, diante de sugestões da comunidade
acadêmica e consequentemente reavaliação dos objetivos, logo
percebemos que projeto não permanecerá limitado a cursos
superiores, passando a ser considerado também uma boa opção
para cursos técnicos da área.
Antes de publicar o primeiro protótipo jogável, optamos por usálo como ferramenta em algumas disciplinas do CST em Sistemas
para Internet local. A intenção era de que os estudantes criassem
uma série de desafios para o jogo e em consequência
disponibilizá-los à comunidade interna. Disciplinas como
desenvolvimento web, banco de dados, engenharia de software e
linguagem de programação foram as primeiras planejadas. A
iniciativa foi mais bem recebida do que o jogo em si, mesmo não
havendo opiniões negativas sobre o mesmo.
Java Server Pages
4
JSON (JavaScript Object Notation) é um formato de dados leve
para troca de informações.
3
Em linguagem de programação, um dos trabalhos da disciplina foi
criar um jogo de dedução de palavras, similar ao clássico jogo da
forca. Todos os estudantes frequentes finalizaram o trabalho, o
que é um bom indicativo em relação a motivação. Na área de
desenvolvimento web a atividade foi propor uma layout web para
um dos diversos problemas disponibilizados pelo professor. Neste
caso, houve a participação de aproximadamente 80% da turma,
não sendo tão efetivo. Ao questionar os estudantes, os mesmos
alegaram que por causa da grande quantidade de avaliações e
trabalhos no final do semestre priorizaram algumas disciplinas
que precisaram de maior dedicação.
6.REFERÊNCIAS
[1] Boyer, K., Buffum, P.S., et. al. 2015. ENGAGE: A Gamebased Learning Environment for Middle School
Computational Thinking. SIGCSE 15 Proceedings of the
46th ACM Technical Symposium on Computer Science
Education. Pages 440-440. ACM New York, NY, USA.
ISBN: 978-1-4503-2966-8.
DOI=http://dx.doi.org/10.1145/2676723.2691876
[2] Drake, P., Goadrich, M. 2014. Learn Java in N games.
SIGCSE 14 Proceedings of the 45th ACM technical
symposium on Computer science education. Pages 748-748.
ACM New York, NY, USA. ISBN: 978-1-4503-2605-6.
Ao ser apresentado ao primeiro semestre do curso, houve interesse
de aproximadamente 20 estudantes de um total de 30.
Infelizmente, devido a algumas situações atípicas como troca de
professores da disciplina e greve dos servidores as atividades
foram interrompidas. Neste meio tempo, dois estudantes do último
semestre paralelamente desenvolveram desafios completos para o
jogo, o que os ajudou a pontuar em atividades complementares
obrigatórias; os desafios destes estudantes foram mais simples,
pois havia um projeto de uma versão do jogo para crianças, com
puzzles menos complexos tais como jogo da memória, caçapalavras, coleta seletiva de lixo, dentre outros (Figura 4).
[3] Ghannem, A. 2014. Characterization of serious games
guided by the educational objectives. TEEM 14 Proceedings
of the Second International Conference on Technological
Ecosystems for Enhancing Multiculturality. Pages 227-233.
[4] IEEE 1484.12.1-2002. 2002. Draft Standard for Learning
Object Metadata. IEEE Learning Technology Standards
Committee (LTSC).15 July 2002. DOI=
http://standards.ieee.org/findstds/standard/1484.12.12002.html
Os próximos passos são expandir a ideia para novas turmas, pois
até o momento todos os testes foram realizados com uma
quantidade pequena de estudantes, em um único curso.
[5] Jenkins, T. 2002. On the Difficulty of Learning to Program.
In Proceedings of the 3rd annual Conference of LTSN Centre
for Information and Computer Sciences. vol 4, pp.53-58.
LTSN. August 23, 2002.
[6] John, M.D.H., et. al. 2003. Puzzles and games: addressing
different learning styles in teaching operating systems
concepts. SIGCSE 03 Proceedings of the 34th SIGCSE
technical symposium on Computer science education. ACM
New York, NY, USA. Volume 35 Issue 1, January 2003.
Pages 182-186.
[7] Li, F.W.B., Watson, C. 2011. Game-based concept
visualization for learning programming. MTDL 11
Proceedings of the third international ACM workshop on
Multimedia technologies for distance learning. Pages 37-42.
Figura 4: Exemplos de dois desafios desenvolvidos pelos
estudantes como atividades complementares do curso
5.CONCLUSÃO
Mesmo atuando sobre uma amostra pequena de estudantes,
tivemos alguns resultados interessantes, mas que podem ser
melhorados. Ao contrário de trabalhos tradicionais como
implementar um sistema de cadastro, criar um algoritmo sem
motivação real ou modelar um banco de dados para um ecommerce, o desenvolvimento de parte de um jogo cria novas
perspectivas: gerar um artefato com caráter mais lúdico e
interativo do que as atividades tradicionais além da expectativa de
criar algo para os próprios colegas.
[8] Matthews, R., Hin, H.S., Choo, K.A. 2009. Multimedia
learning object to build cognitive understanding in learning
introductory programming. MoMM 09 Proceedings of the
7th International Conference on Advances in Mobile
Computing and Multimedia. Pages 396-400. ACM New
York, NY, USA. 2009. ISBN: 978-1-60558-659-5.
[9] Wiley, D.A. 2000. Connecting learning objects to
instructional design theory: A definition, a metaphor, and a
taxonomy. In D. A. Wiley (Ed.), The Instructional Use of
Learning Objects: Online Version. Utah State University,
USA. DOI=http://reusability.org/read/chapters/wiley.doc
A possibilidade de criar jogos com temas e públicos variados
deixou também em aberto uma nova possibilidade: implementar a
ideia em outras áreas do conhecimento; não somente para
tecnologia da informação, assumindo o papel de um objeto de
aprendizagem que pode ser usado dentro ou fora de sala de aulas,
tanto como instrumento de apoio como motivador no ensino e
aprendizagem.
4
RNA Aplicada a Modelagem Hidrológica
Alternative Title: Applied ANN to Hydrologic Model
Marcos Rodrigo Momo
Pedro Sidnei Zanchet
Cristian Zimmermann de Araújo
Centro Universitário de Brusque
[email protected]
[email protected]
[email protected]
Wagner Correia
Christian R. C. de Abreu
[email protected]
Prefeitura Municipal de Blumenau
[email protected]
bacia hidrográfica do rio Itajaí-Açú, o histórico das enchentes é
bastante extenso devido principalmente ao relevo natural da área
e ao processo de ocupação ao longo dos rios deste vale. Os
primeiros registros de cheias datam de 1852. Na bacia do rio do
Itajaí-Mirim, as enchentes ocorrem periodicamente até os dias
atuais, sendo a mais recente ocorrida em 2011 quando o nível do
rio alcançou a marca de 13,03 metros no Município de Brusque.
RESUMO
As inundações são fenômenos naturais que vem ocorrendo em
várias partes do mundo. Na região do Vale do Itajaí, na bacia
hidrográfica do rio Itajaí-Mirim, o histórico das enchentes é
extenso. Para minimizar os danos causados por estes eventos,
medidas estruturais de prevenção vêm sendo realizados, tais
como, a construção de uma barragem. Entretanto, entender a
evolução hidrológica destes eventos é de fundamental
importância para apoiar as atividades de monitoramento. Neste
sentido, este trabalho tem como objetivo desenvolver um
modelo hidrológico chuva-vazão, utilizando técnicas de Redes
Neurais Artificiais (RNAs) para simular o sistema hidrológico
no rio Itajaí-Mirim no Município de Brusque.
As inundações situam-se entre os principais tipos de desastres
naturais na nossa região. São comumente deflagradas por chuvas
rápidas e fortes, chuvas intensas e de longa duração. Estes
fenômenos podem acontecer em regiões naturais, trazendo
alterações ambientais. Entretanto, também atingem locais
ocupados pelos seres humanos. Assim, as áreas urbanas, são as
mais delicadas, pois apresentam mais superfícies impermeáveis,
maior adensamento das construções. Além disso, a conservação
do calor e a poluição atmosférica propicia a aceleração dos
escoamentos, redução do tempo de pico e aumento das vazões
das máximas, causando danos cada vez maiores e sendo tratado
como desastres. O maior destes desastres nesta região foi de
deslizamentos acompanhados de enxurradas e enchentes, que
ocorreu em novembro de 2008 com o registro de 24 mortes, 6
pessoas desaparecidas, mais de 30.000 pessoas desalojadas ou
desabrigadas [3].
ABSTRACT
Floods are natural phenomena that have occurred in various
parts of the world. In the region of Itajaí Vale, in the basin of the
Itajaí-Mirim River the history of flooding is extensive. To
minimize the damage caused by these events, structural
prevention measures have been carried out, such as the
construction of a dam. However, understanding the hydrological
evolution of these events is crucial to support the monitoring
activities. In this sense, his work aims to develop a hydrological
rainfall-runoff model, using techniques of the artificial neural
network to simulate the hydrological system in Itajaí-Mirim
River in the city of Brusque/SC.
Na tentativa de monitorar e diminuir os danos causados por
estes desastres, alguns esforços estão sendo realizado em toda a
bacia do rio Itajaí. Na bacia do rio Itajaí-Mirim, área de estudo
deste trabalho, está em andamento o projeto para a construção
de uma barragem a montante do Município de Brusque,
localizada em Botuverá. Esta barragem terá a capacidade de
armazenamento do volume de 15.700.000 m³. Desta forma, a
expectativa é que a vazão máxima do rio Itajaí Mirim, em
Brusque seja reduzida de 720 m³/s para 570m³/s. Isso significa
dizer que se em 2011, durante o evento de cheias em Brusque, o
pico de 10,03 metros, baixaria para 8,75 metros. Além disso, a
barragem oferecerá potencial de abastecimento de água aos
municípios de Botuverá, Brusque, Itajaí e Balneário Camboriú.
Em 2012 a Prefeitura Municipal de Brusque mapeou toda a área
do Município e as cotas de inundação por ruas, denominadas de
Carta-Enchente e a Cota-Enchente, respectivamente. Este
mapeamento de áreas suscetíveis de inundação representa um
grande avanço para gestão e controle de cheias, possibilitando o
monitoramento em uma situação de possível ocorrência de
enchente. Recentemente a Defesa Civil de Brusque implantou
um sistema telemétrico para coleta de dados hidrológicos e
meteorológicos em vários pontos da bacia do rio Itajaí-Mirim,
possibilitando realizar o monitoramento hidrometeorológico em
tempo real. O sistema de telemetria instalado no Município de
Categories and Subject Descriptor
I. [Computing Methodologies]: I.2. Artificial Intelligence:
I.2.6.Learning: Connectionism and neural nets.
General Terms
Experimentation, Measurement, Verification.
Keywords
Modelo Chuva-Vazão; Simulação Hidrológica; Redes Neurais
Artificiais; Hidrometeorologia.
1. INTRODUÇÃO
As enchentes são fenômenos naturais que têm sido registrados
nas diversas partes do mundo e que muitas vezes geram
expressivos prejuízos ao homem e à natureza. Na região da
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee. SBSI 2016, May 17–20,
2016, Florianópolis, Santa Catarina, Brazil. Copyright SBC 2016.
5
Brusque é de vital importância, pois por um lado permite
realizar o monitoramento hidrometeorológico da bacia em
tempo real, e por outro, viabiliza dados que subsidiam as
pesquisas científicas nas áreas de hidrologia e meteorologia.
Neste sentido, o objetivo deste trabalho é realizar a modelagem
hidrológica baseada em redes neurais artificiais (RNAs), visando
simular o comportamento hidrológico do rio Itajaí-Mirins,
durante as ocorrências de cheias pretéritas. Estas informações
poderão integrar ao conjunto de medidas preventivas que vem
sendo realizadas na bacia ao longo do tempo. Estas medidas têm
o objetivo de minimizar os danos causados pelos eventos de
cheias.
longo prazo são para tempo de retorno de um evento de cheias,
relacionados às mudanças climáticas ou eventos cíclicos do tipo
El Niño e La Niña.
A previsão de curto prazo é realizada com horizontes pequenos
de tempo, variando de minutos até horas (ou dias). Estas
previsões são realizadas postos de medições a montante e dados
de precipitação ocorrida. São as mais utilizadas para controle de
inundações em regiões ribeirinhas [4].
2.4 Redes Neurais Artificiais (RNA)
A RNA é um paradigma de aprendizado e processamento
automático inspirado na forma que funciona o sistema cerebral
humano. Através de interconexões de neurônios artificiais
colabora para produzir estímulos de saída.
2. FUNDAMENTAÇÃO TEÓRICA
2.1 Modelos hidrológicos
Neurônios artificiais são funções matemáticas capazes de
receber uma série de entradas e emitir uma saída. Basicamente
um neurônio artificial da RNA é dado por três funções, são elas:
1) função de propagação, responsável por realizar a somatória
de cada entrada multicamada; 2) função de ativação, que
modifica a função anterior, caso a saída seja a mesma função
disponibilizada dada na função anterior, neste caso a função de
ativação não existe e 3) função de transferência que relaciona o
sinal de entrada com o sinal de saída da rede neural [5].
O modelo hidrológico é uma representação simplificada de um
sistema com o objetivo de entendê-lo e encontrar respostas para
distintas circunstâncias [10]. Através dos modelos hidrológicos
é possível encontrar respostas (saídas) de uma bacia hidrográfica
a partir de informações (entradas). A Figura 1 apresenta a
representação
esquemática
de
um
modelo
hidrológico
As Soluções baseadas em RNA iniciam de um conjunto de
dados de entrada suficientemente significativo com o objetivo
de que a rede aprenda automaticamente as propriedades
desejadas. O processo de adequação dos parâmetros da rede não
é obtido através de programação genérica e sim através do
treinamento neural. Neste sentido, para alcançar a solução
aceitável para um dado problema, é necessário previamente
adequar um tipo de modelo RNA e realizar a tarefa de préprocessamento dos dados, os quais que formarão o conjunto de
treinamentos. Estas características permitem a RNA oferecer
diversas vantagens, tais como, capacidade de aprendizagem,
auto-organização, tolerância a falhas, flexibilidade e a obtenção
de resultados em tempo real. Redes neurais têm sido utilizadas
com sucesso em vários campos da ciência. Na hidrologia sua
aplicabilidade tem feito evoluir a modelagem de sistemas não
lineares[4]. As principais vantagens na utilização da
metodologia de RNA na modelagem de bacias hidrográficas são:
a) possibilitam a resolução de problemas complexos e não bem
definidos; b) podem ser aplicados em sistemas sem soluções
específicas; c) não requerem conhecimento detalhado dos
processos físicos; d) não potencializam erros de medição; e)
permitem otimizar os dados de entrada e dados de saída; f)
possibilitam treinamento contínuo da rede; g) baseado em dados
históricos, permite extrair informação e generalizar respostas
adequadas para cenários diferentes daqueles já ocorridos.
Figura 1: Representação esquemática de um modelo
hidrológico [8].
Na modelagem hidrológica são utilizadas ferramentas
matemáticas para representar o comportamento dos principais
elementos que compõe o ciclo hidrológico. Desta forma, o
objetivo é reproduzir os resultados mais próximos possíveis aos
resultados encontrados na natureza. Devida à grande
complexidade de se representar todos os fenômenos naturais, a
modelagem hidrológica trabalha com simplificações desses
fenômenos [8].
2.2 Modelo Chuva-Vazão
Na literatura há uma grande quantidade de modelos chuvavazão, desde os mais simples, com métodos matemáticos, até os
mais complexos envolvendo modelos conceituais distribuídos
que consideram a variabilidade espacial e tempo de um evento
chuvoso, assim como as características da bacia [1]. Com a
evolução tecnológica, a modelagem chuva-vazão está sendo
aplicada para resolver situações específicas de como fazer
previsões de cheias, melhorando o ajuste dos parâmetros e
avaliando a interligação entre os parâmetros e as características
físicas da bacia [8].
2.4.1 Arquitetura da RNA
A rede neural é formada pelas camadas de entrada,
processamento e saída. Na camada de entrada, são apresentados
os dados de entradas da rede, que produzem sinais de saída,
estas por sua vez, estimularão os neurônios da camada
subsequente. Este processo segue até atingir a última camada,
chamada de camada de saída. Vale salientar que as camadas de
uma rede neural podem ter um ou vários neurônios por camadas.
Na Figura 2 se ilustra a arquitetura de uma rede neural [5].
Os principais usos destes modelos estão voltados para estudos
de comportamento de fenômenos hidrológicos, previsão de
nível, previsão de cenários de planejamento entre outros [10].
2.3 Previsão de nível do rio
A previsão de nível do rio é a estimativa das condições em um
determinado tempo específico futuro [1]. A previsão pode ser
classificada em função do intervalo de tempo, como sendo de
curto prazo ou de longo prazo. Alguns exemplos de previsão de
Para resolver um dado problema, não existe, todavia, uma
solução bem definida para a escolha do número de camadas e de
6
neurônios a serem criados na rede. Se por um lado uma rede
muito complexa pode causar um superajustamento (overfiting).
Por outro lado, a simplicidade excessiva da rede pode não
conseguir reproduzir o comportamento desejado, mais
conhecido como mínimos locais [5]. Para alcançar a melhor
arquitetura da rede neural, para cada configuração devem-se
realizar simulações e análises de resultados, através das etapas
de treinamento e testes da rede.
3.3 Área de estudo
A bacia hidrográfica do rio Itajaí-Mirim está localizada na
região do Vale do Itajaí entre as latitudes -27°6’2 e longitudes 48°55’0. O rio Itajaí-Mirim faz parte da bacia do rio Itajaí-Açú,
que por sua vez, faz parte do sistema de drenagem da vertente
Atlântico. O rio Itajaí-Mirim com a área de drenagem de
1.700km² é a maior sub-bacia da bacia de drenagem do rio
Itajaí-Açú, fazendo parte da região hidrográfica do Vale do
Itajaí [6]. Esta bacia engloba um total de nove municípios: Vidal
Ramos, Presidente Nereu, Botuverá, Guabiruba, Brusque,
Gaspar, Ilhota, Camboriú e Itajaí. Suas nascentes encontram-se
na Serra dos Faxinais, a cerca de 1.000 metros de altitude, e
deságua na região estuarina do Itajaí-Açú, tendo o leito
principal, uma extensão aproximada de 170 km. A figura 3
ilustra a área de estudo.
Figura 2: Arquitetura da rede neural artificial [5].
3. METODOLOGIA DE PESQUISA
3.1 Atividades desenvolvidas
Para atender aos objetivos deste trabalho foram realizadas as
seguintes atividades: 1–Criação das séries dados: consistiu na
identificação dos eventos de cheias pretéritas, ocorridos na bacia
do rio Itajaí Mirim e na obtenção dos dados dos níveis do rio
registrados nos pontos de Brusque e Vidal Ramos; 2–Criação,
treinamento e teste da RNA: nesta etapa foi utilizando o
software MatLab e o Toolbox Neural Network Tool [9]. Foram
criadas as RNAs, seguindo as seguintes etapas: a) divisão das
séries de dados para o treinamento e para os testes das RNAs; b)
treinamento da rede, que consistiu no ajuste dos pesos, no qual
se apresenta o conjunto de dados de entradas, para se obter a
saída desejada, c) testes das RNAs, com base das diversas
opções de configuração dos parâmetros de ajustes da rede
(número de neurônios, número de camadas, algoritmos de
treinamento etc.), foram realizados baterias de simulações para
encontrar o melhor resultado da RNA; 3-Análise de resultados:
com o objetivo de eleger a melhor configuração da RNA, para
cada simulação a análise de rendimento da rede, foi baseada no
coeficiente de determinação R². Este coeficiente permite obter o
ajuste entre o modelo de simulação e os dados observados que
variam entre 0 e 1. Desta forma, indica em percentagem o
quanto o modelo consegue explicar os valores observados,
quanto maior o valor de R² (mais próximo à 1), maior é o
rendimento do modelo, ou seja, melhor ele se ajusta à amostra.
Figura 3: Bacia hidrográfica Vale do Itajaí e sub-bacias [7].
4. RESULTADOS
No total foram criadas 10 RNAs utilizando as mesmas séries de
dados para as fases de treinamento e teste. Nas simulações foram
alterados os parâmetros de configuração para cada rede testada.
Com base no coeficiente de determinação R², verificou-se que o
melhor rendimento do modelo foi com a seguinte configuração
da RNA: rede Feed_Forward BackPropagation, com 50
neurônios, 2 camadas, algoritmo de treinamento TRAINLN,
camada escondida função TANSIG e de saída função
PURELIN. Nesta configuração da RNA obteve um índice de R²
= 0,3686. A figura 4 ilustra o nível observado e o nível simulado
pela RNA.
3.2 Dados utilizados
Para a realização deste trabalho, foram utilizados os dados do
nível do rio nos pontos de Brusque e Vidal Ramos, registrados
nas ocorrências de cheias dos seguintes eventos: 09/08/2011,
30/08/2011, 14/01/2012, 08/06/2014, 29/09/2014 e 01/10/2014.
Estes dados são provenientes da rede telemétrica de coleta de
dados hidrometeorológicos mantida pelo CEOPS/FURB [2]. O
ponto de Brusque é o local desejado da previsão de nível, ou
seja, na ponte Estaiada localizada centro da cidade.
Vale salientar que neste trabalho foram simuladas também as
redes neurais recorrentes Elman. Redes recorrentes são
adequadas para sistemas dinâmicos, entretanto, os resultados
obtidos para as mesmas séries de dados foram inadequados para
o estudo proposto.
Estudos similares ao apresentado aqui, utilizando RNA para
simulação hidrológica, nos quais mostraram uma eficiência na
utilização desta técnica. Em [11] utilizou técnicas de redes
7
neurais para realizar a previsão de cheias no rio Itajaí-Açú no
de Rio do Sul. O melhor desempenho foi com a RNA dom tipo
MLP com 9 neurônios na camada oculta. Para analisar a
performance do modelo, foram utilizados três coeficientes
estatísticos: Coeficiente de Eficiência de NS (Nash e Sutcliffe),
RMSE (Root Mean Square Error) e MAPE (Mean Absolute
Percentage Error), alcançando os valores de 0.9779, 0.0201 e
5.625, respectivamente.
Finalmente, vale destacar que a aplicabilidade das RNAs para
estudos hidrometeorológicos são promissoras, uma vez que
necessitam uma quantidade de dados relativamente pequena,
quando comparados aos modelos hidrológicos mais sofisticados
do tipo distribuídos, que consideram a variabilidade espacial nas
diversas variáveis do modelo, sendo necessário a discretização
da área, representando um conjunto elevado de parâmetros.
6. AGRADECIMENTOS
No trabalho de [8] apresenta os resultados do modelo de
previsão hidrológica de curto prazo utilizando RNA. Para
verificar o rendimento do modelo, foi aplicado como estatística
de qualidade o coeficiente de NS e apresentou como o menor
resultado 0,91 e o maior resultado 0,97.
Este trabalho de Iniciação Científica teve o apoio da Secretaria
de Estado da Educação de Santa Catarina, através da concessão
de bolsas com recursos do Artigo 170 da Constituição Estadual,
para os alunos de graduação regularmente matriculados na
UNIFEBE.
Em [12] apresenta um trabalho utilizando RNA de múltiplas
camadas para realizar a previsão de vazão mensal da bacia
hidrográfica do rio Piancó no Estado da Paraíba. A RNA
configurada com 15 neurônios na camada intermediária,
utilizando o coeficiente de NS, apresentou um resultado de 0,77.
7. REFERENCIAS
[1] CORDERO, Ademar; MOMO, Marcos Rodrigo; SEVERO,
Dirceu Luis. Prevenção de Cheias em Tempo Atual, com
um modelo ARMAX, para a Cidade de Rio do Sul-SC. In:
Simp. Brasileiro de Rec. Hídricos XIX, 2011, Maceió.
[2] CEOPS. Sistema de Alerta da Bacia do Rio Itajaí. 2016.
Disponível em: <www.ceops.furb.br>, Último acesso:
15/03/2016.
[3] Defesa Civil de Brusque. Estações de monitoramento
hidrometeorológico.
2016.
Disponível
em:
<
http://defesacivil.brusque.sc.gov.br/monitoramento.php>,
Último acesso: 15/04/2016.
[4] DORNELLES, Fernando. Previsão contínua de níveis
fluviais com redes neurais utilizando previsão de
precipitação: investigação metodológica da técnica. 2007.
97 p. Dissertação-IPH, UFRGS, Porto Alegre, 2007.
[5] HAYKIN, S. Redes neurais: princípios e prática. 2ª edição,
São Paulo, Bookman, 2001, 900 p.
Figura 4: Simulação hidrológica Observado/Simulado com
RNA.
[6] HOMECHIN, M. Jr & A.C. BEAUMOR. Caracterização
da qualidade das águas do trecho médio do Rio ItajaíMirim, S/C. Anais do VIII Congresso de Ecologia do
Brasil, 2007.
Este trabalho permitiu obter informações relacionadas à
simulação do processo hidrológico na bacia hidrográfica do rio
Itajaí-Mirim durante um evento de cheias. Estas informações são
de vital importância para entender o clico hidrológico,
objetivando prever com antecedência a subida do nível do rio e
apoiar no monitoramento hidrológico em situações de eventos
de cheias. O serviço de monitoramento hidrometeorológico do
Município de Brusque atende de forma direta ou indiretamente,
uma população de cerca de 100 mil habitantes. Desta forma,
estas informações poderão ser integrados ao Sistema de
Informação da Defesa Civil de Brusque para apoiar na tomada
de decisão em situações iminentes às enchentes. Por outro lado,
a continuidade destes estudos viabilizará a geração de novos
conhecimentos hidrológicos da bacia e o fortalecimento da
parceria entre a Defesa Civil municipal, UNIFEBE e a
comunidade acadêmica em geral.
[7] BACIAS. Bacias Hidrográficas do Brasil. GEO-Conceição.
Disponível
em:
<http://geoconceicao.blogspot.com.br/2011/08/baciashidrograficas-do-brasil.html.>, Último acesso: 15/04/2016.
[8] MATOS, Alex Bortolon de. Efeito do controle de montante
na previsão hidrológica de curto prazo com redes neurais:
aplicação à bacia do Ijuí. 2012.75 f. Dissertação (Mestrado
em Recursos Hídricos e Saneamento Ambiental) –
PPRHSA, UFRGS, 2012.
[9] TOOLBOX S. I., The MathWorks - MatLab and
Simulation, T. MathWorks, Editor. 2016. Disponível em:
www.mathworks.com. Último acesso: 15/03/2016.
[10] TUCCI, C.E.M., Modelos hidrológicos, Porto Alegre,
UFRS/ABRH, 1998, 668 p.
5. CONCLUSÃO
Com base nestes resultados, verifica-se a necessidade de realizar
um levantamento de uma maior quantidade de dados
hidrometeorológicos da bacia, assim como a inserção de novos
pontos de medição do nível do rio. Intui-se que uma quantidade
maior de dados, viabilizará uma melhor qualidade na fase de
treinamento da RNA, melhorando o rendimento do modelo de
simulação hidrológica na bacia do rio Itajaí-Mirim.
[11] SOARES, D. G.; TEIVE, R.. C. G. Previsão de Cheias do
Rio Itajaí-Açu Utilizando Redes Neurais Artificiais. Anais
do Computer on the Beach, p. 308-317, 2015.
[12] SOUZA, W. S.; SOUZA, F. A. S. Rede neural artificial
aplicada à previsão de vazão da Bacia Hidrográfica do Rio
Piancó. Rev. Bras. Eng. Agr. Amb., v.14, p.173-180. 2010.
8
Terceirização de Sistemas de Informação no Setor
Público: Uma Revisão Sistemática de Literatura
Alternative Title: Information Systems Outsourcing in the Public
Sector: A Sistematic Literature Review
Matheus Icaro Agra Lins
José da Silva Duda Junior
Instituto Federal de Alagoas
R. Mizael Domingues, 75 - Centro,
Maceió - AL
[email protected]
Maceió - AL
[email protected]
RESUMO
Mônica Ximenes Carneiro da
Cunha
Maceió - AL
[email protected]
General Terms
A terceirização de sistemas de informação (TSI) tornou-se uma
estratégia bastante procurada pelas organizações nos últimos anos.
Inúmeros estudos encontrados na literatura tratam dos principais
aspectos que envolvem esse fenômeno no setor privado. Devido a
escassez de estudos direcionados ao setor público, esse artigo tem
como objetivo analisar publicações científicas com propósito de
elencar riscos, benefícios e motivações da terceirização de
sistemas de informação no setor público através de uma revisão
sistemática de literatura (RSL). Os resultados da RSL sinalizaram
diferença na frequência de citações relacionadas às motivações,
riscos e benefícios quando comparados ao setor privado. Tudo
isso mostra a importância deste levantamento para contribuir com
um trabalho em andamento que pretende fazer um mapeamento
quantitativo desses três fatores em instituições do setor público
em um estado do nordeste brasileiro, bem como para trabalhos
futuros.
Management, Measurement, Documentation, Theory.
Palavras-Chave
Terceirização de SI; Setor Público; Outsourcing de TI.
Keywords
IS outsourcing; Public Sector; IT outsourcing.
1. INTRODUÇÃO
O fenômeno da terceirização não é algo recente. Desde o século
XVIII, Ingleses e Franceses terceirizavam alguns serviços e
atividades especializadas [2][6]. Terceirização refere-se à prática
de transferir parte das atividades comerciais de uma empresa para
um fornecedor externo [1]. Geralmente atividades muito
específicas ou que não fazem parte dos interesses comerciais são
transmitidas para que empresas ou pessoas externas à organização
possam fazê-las de maneira melhor [2].
ABSTRACT
Information Systems Outsourcing (ISO) has become a much
sought strategy by organizations in recent years. Numerous
studies in the literature deals with the main aspects surrounding
this phenomenon in the private sector. Due to the lack of studies
directed to the public sector, this article aims to analyze scientific
publications focused on this sector with purpose to list risks,
benefits and motivations through a systematic literature review
(SLR). The SLR results signed some difference in the frequency
of citations related to motivations, risks and benefits when
compared to the private sector. It shows the importance of this
survey to contribute with a work in progress which aims to make a
quantitative mapping of these risks, motivations and benefits in
public sector institutions in a state in northeastern Brazil, as well
as future works.
Empresas cujo negócio principal não está diretamente relacionado
a serviços de TI enxergam na terceirização algumas
possibilidades, dentre elas: ter acesso a novas tecnologias e
recursos humanos capacitados, direcionar os esforços para a
atividade principal e reduzir custos. Este último, por sua vez, é um
dos principais fatores motivadores indicados em estudos voltados
principalmente para empresas privadas [7][3].
Apesar de alguns fatores motivadores da TSI no setor público
serem semelhantes aos do privado, como foco nas competências
centrais, melhoria na qualidade dos serviços e acesso à expertise
[11], estes diferem quanto ao grau de importância e a frequência
com que são mencionados. Inclusive existem aspectos dissonantes
entre eles, como a carência de recursos humanos causada por
inexistência de cargos na área de TI dentro das instituições, e
também problemas na contratação devido a restrições burocráticas
ocasionada por leis [10].
O setor público tem seguido a tendência definida pelo setor
privado e atividades relacionadas a TI têm sido uma das que são
mais terceirizadas [13]. O risco de falhas nas parcerias enceta o
interesse dos órgãos públicos a se aprofundarem no formato de
gerência da terceirização, uma vez que a publicidade que cerca o
governo é fundamental para a gestão em exercício.
A1 [Introductory and Survey]
requires prior specific permission and/or a fee.
Copyright SBC 2016.
A escassez de estudos orientados ao setor público dificulta
comparações com a iniciativa privada, bem como o próprio
entendimento do comportamento do fenômeno neste setor.
9
Existem diferenças, principalmente no que tange riscos e
motivações [11][12]. Em virtude de tais diferenças entre setor
público e privado, não se pode fazer generalizações para estudar a
terceirização de SI como um todo. Para isso, é necessário um
aprofundamento no setor público com intuito de conseguir
conhecimento sólido de maneira a evitar viés nas pesquisas.
2.2 Estratégias de pesquisa e seleção
Elaboradas as questões da pesquisa, o próximo passo consistiu na
definição dos termos de busca (strings de busca) que foram
elaborados a partir da identificação da população (setor público),
intervenção (terceirização de sistemas de informação,
terceirização de tecnologia da informação), em conjunto com os
termos correlatos à população e intervenção identificadas. Por
fim, foram realizadas combinações com palavras chaves e
operadores booleanos.
Este artigo apresenta os resultados de uma RSL, que teve como
objetivo realizar um levantamento de artigos existentes sobre os
riscos, benefícios e motivações que envolvem a terceirização de
sistemas de informação no setor público. A intenção foi sumarizar
as informações obtidas, com finalidade de criar um arcabouço
teórico que servirá como fonte para embasar um survey com
intuito de confrontar as visões dos fornecedores e contratantes a
respeito dos riscos, benefícios e fatores motivadores da parceria
público-privada que envolvem sistemas de informação.
Assim sendo, foram construídas strings de busca com termos em
português e em inglês para cada questão.

Strings para Q1
Inglês: (("information systems outsourcing" OR "information
technology outsourcing" OR "IS outsourcing" OR "IT
Outsourcing") AND ("public sector" or "public service" OR
"public administration") AND (risk* or barrier* OR obstacle* or
challeng* or hurdle*))
A estruturação do restante do artigo é a seguinte: na seção 2 é
apresentado o procedimento metodológico, onde serão vistos os
conceitos de RSL, como foram definidos o protocolo e as etapas
da presente pesquisa; na seção 3 são exibidos os resultados das
buscas e seleções em torno das perguntas de pesquisa, além de
uma sucinta discussão. Por fim, as conclusões são apresentadas na
seção 4.
Português: (("terceirização de sistemas de informação OR
terceirização de tecnologia da informação OR terceirização de SI
OR terceirização de TI) AND ("Setor público" OR "Serviço
público" OR "administração pública") AND (riscos OR
obstáculos OR barreiras OR desafios)).
2. PROCEDIMENTO METODOLÓGICO
2.1 Revisão Sistemática

As revisões sistemáticas de literatura (RSL) são estudos
secundários que adotam um processo de pesquisa
metodologicamente bem definido para identificar, analisar e
interpretar as evidências disponíveis relacionadas a uma ou mais
questões de pesquisa especificas [8]. A RSL difere dos outros
tipos de revisões pelo fato de ser formalmente planejada e
executada de maneira metódica, dessa forma garante a
reprodutibilidade da pesquisa, proporcionando maior credibilidade
científica.
Strings para Q2
Inglês: (("Information systems outsourcing" OR "Information
Outsourcing") AND ("Public sector" OR "Public service" OR
"Public administration") AND (motivat* OR cause OR reason*))
Português: (("Terceirização de sistemas de informação” OR
“terceirização de tecnologia da informação” OR “terceirização de
SI” OR “terceirização de TI”) AND ("setor público" OR "serviço
público" OR “administração pública") AND (motivação OR
causa))
O ponto de partida de uma revisão sistemática se dá na elaboração
do protocolo de pesquisa, disponível em https://goo.gl/Yhg9Nh,
onde são listadas as questões de pesquisa e os procedimentos que
serão adotados durante a execução da revisão. Dessa forma, [9]
determinaram um conjunto de fases que são essenciais para o
desenvolvimento de uma RSL, sendo elas: planejamento,
execução e análise dos resultados.

Strings para Q3
Inglês: (("information systems outsourcing" OR "information
Outsourcing") AND ("public sector" OR "public service" OR
"public administration") AND (benefit* OR advantage*))
As fases definidas por [9], e os conceitos de revisão sistemática
abordados por [8], serviram como diretrizes para a elaboração da
metodologia do presente trabalho. Os três aspectos (riscos,
benefícios, motivações) escolhidos como base para esta revisão
emergiram de estudos bibliográficos realizados por dois alunos de
iniciação científica que trabalharam neste artigo, em conjunto com
a orientadora. Observou-se durante o levantamento da literatura
que esses aspectos são costumeiramente citados quando se trata de
TSI de maneira geral. O propósito foi de ampliar os
conhecimentos acerca da terceirização de SI no setor público em
âmbito mundial. Dessa forma, foram elaboradas três questões de
pesquisa para serem respondidas após a obtenção dos estudos
primários. São elas:
Português: (("terceirização de sistemas de informação OR
terceirização de tecnologia da informação OR terceirização de SI
OR terceirização de TI) AND ("setor público" OR "serviço
público" OR “administração pública") AND (benefícios OR
vantagens))
2.3 Seleção das bases de dados
Os termos de busca definidos foram aplicados nas bases de dados
estabelecidas no protocolo da pesquisa. A seleção das bases se
deu a partir do reconhecimento acadêmico em âmbito nacional e
internacional. Com isso as selecionadas para a pesquisa foram:
Periódicos da CAPES; ACM Digital Library; Science Direct; ISI
Web of Science; Scopus; IEEE Xplore Digital Library; Google
Scholar.
Q1. Quais os riscos da terceirização de sistemas de informação
no setor público?
Q2. Quais as motivações da terceirização de sistemas de
informação no setor público?
Vale salientar que as respectivas bases de dados possuem
particularidades com relação ao seu mecanismo de pesquisa, com
isso surgiu a necessidade de realizar pequenas adequações nas
strings para se adequar a base e assim obter resultados
satisfatórios.
Q3. Quais as benefícios da terceirização de sistemas de
10
A seguir são apresentadas as respostas paras as questões de
pesquisa tendo como base os aspectos mais citados nos artigos
selecionados:
2.4 Estratégias de inclusão e exclusão
O procedimento para a inclusão e exclusão de documentos que
retornaram após a aplicação dos argumentos de pesquisa (strings
de busca) nas bases de dados se deu em dois momentos. No
primeiro momento, foram definidos no protocolo de pesquisa
como critérios de inclusão: a disponibilidade do documento na
internet para download e que esteja em formato PDF,
disponibilidade do documento em língua inglesa ou portuguesa, e
a delimitação do tempo de publicação de dez anos, ou seja,
publicados entre 2005 a 2015, tendo em vista que esta etapa da
pesquisa iniciou em novembro de 2015 e encerrou em março de
2016. Por fim, foram aceitos documentos que tratam de forma
primária ou secundária sobre motivações, riscos e benefícios da
TSI no setor público. Dessa forma, os critérios de exclusão foram
elaborados de forma que contrariem os critérios de inclusão.
Q1.
Quais os riscos da terceirização de sistemas de
Constatou-se que dos 24 documentos, 9 abordavam os riscos de
maneira primaria, e 4 de maneira secundaria. Dentre os resultados,
conforme a Tabela 2, ficou evidente a preocupação com questões
de segurança, uma vez que 6 dentre os 13 artigos que falam de
riscos, citam esse ponto. Isso ocorre, principalmente, pelo fato de
que os gestores das instituições públicas se preocupam
demasiadamente com possíveis vazamentos e acesso não
autorizado às informações que são confidenciais. Além de
prejudicar a organização e a população, pode também manchar a
imagem da corrente gestão do governo.
No segundo momento foi realizada uma análise do título e das
palavras chaves com finalidade de reduzir a enorme gama de
resultados que havia sido retornada após a aplicação dos
argumentos. Ao término dessa análise restaram 239 documentos.
Eles tiveram seu resumo e conclusão lidos para confirmar se
estavam de acordo com o que foi estabelecido nos critérios de
inclusão, e no fim restaram 24 documentos relevantes, que foram
utilizados para responder as questões propostas pela revisão. A
tabela 1 exibe os resultados obtidos durante toda a fase de busca e
seleção dos documentos primários.
Observou-se também o elevado número de citações com relação a
dependência excessiva do fornecedor, fator que é refletido a partir
de outros riscos como, por exemplo, a perda de habilidades
críticas de TI. É comum que haja uma acomodação quando um
serviço é prestado de maneira eficiente, e isso acarreta na falta de
interesse da organização em fazer novos investimentos internos
para capacitação e melhoria das atividades. Apesar da perda de
habilidades de TI estar como um dos menos citados na tabela,
possui características gradativas, visto que a dificuldade em
manter tais habilidades abre espaço para a dependência.
Tabela 1. Resultados das buscas por estudos primários nas
bases de dados.
Fonte
Periódicos Capes
ACM Digital library
Science Direct
ISI Web of Science
Scopus
IEEE
Google Scholar
Total
Tabela 2. Principais riscos abordados nos artigos selecionados.
RISCOS
1ª Seleção
2ª Seleção
Quantidade
(Título e
(Abstract e
Palavras-chave) Conclusão)
32
45
564
8
26
13
2716
3404
7
13
28
8
7
7
169
239
Questões de segurança
Dependência excessiva do fornecedor
Perda de competências centrais em TI
Custos ocultos
Perda de controle da atividade terceirizada
Falta de experiência do fornecedor na atividade Terceirizada
Diminuição da moral dos funcionários
Qualificação dos funcionários do fornecedor
Perda de flexibilidade dos serviços de TI
Diferenças culturais
Instabilidade financeira do fornecedor
Perda de habilidades criticas de TI
4
1
3
1
1
1
13
24
3. RESULTADOS E DISCUSSÕES
Dos 24 artigos que restaram após os processos de seleção,
identificou-se que, em alguns casos, um mesmo artigo tratava de
mais de um dos assuntos pesquisados: riscos, motivações e
benefícios. O Gráfico 1 mostra o número de artigos que está
diretamente ligado a cada uma das perguntas de pesquisa,
separando pelas bases de dados onde foram encontrados. No total,
17 artigos abordaram sobre motivações, 13 sobre riscos e 4 sobre
benefícios.
Q2. Quais as motivações da terceirização de sistemas de
A Tabela 3 sinaliza que a motivação relacionada a direcionar o
foco para as competências essenciais foi a mais citada. Em
segundo lugar está a redução de custos, que geralmente é a mais
citada nos estudos voltados para o setor privado. A intensidade de
citações sobre este fator é compreendida pela possibilidade de
direcionamento do foco da empresa para as atividades principais,
com canalização dos investimentos financeiros que seriam feitos
no setor de TI sendo remanejados para as tarefas centrais. Outra
motivação bastante citada foi a busca pela melhoria na qualidade
dos serviços, viabilizada pelo acesso às novas tecnologias e novas
expertises. Isso se dá pelo fato de os fornecedores de serviços
terceirizados geralmente dispõem de recursos humanos e
tecnológicos mais capacitados e avançados, possibilitando a
substituição de tecnologias defasadas e suprindo a falta de
profissionais, às vezes causada pela inexistência de cargos
específicos.
Gráfico 1. Quantidade de artigos por bases de dados que
falam em Motivação, Risco ou Benefício.
20
15
10
5
0
QTD DE FREQUÊNCIA
CITAÇÕES DE CITAÇÕES
6
46%
6
46%
5
38%
4
31%
3
23%
3
23%
3
23%
3
23%
3
23%
3
23%
2
15%
2
15%
Motivações
Riscos
Benefícios
11
flexibilidade dos serviços de TI, melhoria dos produtos e serviços
e acesso a novos recursos e habilidades.
Tabela 3. Principais aspectos motivadores citados nos artigos
selecionados.
Como trabalhos futuros pretende-se utilizar os conhecimentos
gerados por este artigo para compor um survey para aferir a
opinião de gestores públicos estaduais e municipais sobre
motivações, benefícios e riscos da parceria público-privada de
sistemas de informação, com vistas a atestar ou refutar as
informações preliminares obtidas na revisão sistemática.
QTD DE
CITAÇÕES
FREQUÊNCIA
DE CITAÇÕES
FOCO NA COMPETÊNCIA PRINCIPAL
12
71%
REDUÇÃO DE CUSTOS
MELHORIA QUALIDADE DOS SERVIÇOS
11
10
65%
59%
ACESSO A NOVAS TECNOLOGIAS/HABILIDADES
8
47%
6
35%
REFERÊNCIAS
6
5
3
2
2
1
35%
29%
18%
12%
12%
6%
[1] GORLA, Narasimhaiah; CHIRAVURI, Ananth. 2011.
Information systems outsourcing success: a review. In: 2010
International Conference on E-business, Management
and Economics. 2011. p. 170-174.
1
6%
1
1
6%
6%
MOTIVAÇÃO
FLEXIBILIDADE PARA RESPONDER RAPIDAMENTE
ÀS MUDANÇAS NA ÁREA DE TI
ESCASSEZ DE RECURSOS INTERNOS
ACESSO A EXPERTISE
FALTA DE CONHECIMENTO INTERNO/EXPERTISE
COMPARTILHAMENTO DE RISCOS
REDUÇÃO DE PROBLEMAS ROTINEIROS DE TI
ATENDIMENTO A DEMANDAS URGENTES DE TI
TRATAMENTO DE FUNÇÕES DIFÍCEIS DE GERENCIAR
OU FORA DE CONTROLE
PRESSÕES EXTERNAS
PROBLEMAS COM RECRUTAMENTO DE PESSOAL
[2] BERGAMASCHI, S. Modelos de gestão da terceirização
de Tecnologia da Informação: um estudo exploratório. Tese
(Doutorado em Administração) - Universidade de São Paulo,
São Paulo, 2004.
[3] PRADO, E. P. V.; TAKAOKA, H.. 2000. Terceirização da
Tecnologia de Informação: Uma Avaliação dos Fatores que
Motivam sua Adoção em Empresas do Setor Industrial de
São Paulo. Dissertação (Mestrado em Administração de
Empresas) - Universidade de São Paulo, São Paulo, 2000.
Q3. Quais as benefícios da terceirização de sistemas de
Apesar de restarem poucos documentos que falam em benefícios,
foi possível ter acesso às informações necessárias para responder
a pergunta supracitada. Em meio aos 24 artigos selecionados, 4
deles citaram algum tipo de benefício. Conforme ilustrado na
Tabela 4, a metade dos artigos apontou que um dos principais
benefícios é o acesso a novas capacidades e competências, visto
que, em muitas ocasiões, a equipe interna de TI não tem
habilidade e expertise necessária para gerenciar problemas mais
complexos e atender novas demandas. Consequentemente, junto
das novas competências e recursos, tecnologias inovadoras
aparecem como o segundo mais citado, seguido da melhoria na
qualidade dos serviços, que pode ser compreendido como
resultado da soma dos demais benefícios.
[4] LOH, L.; VENKATRAMAN, N.. 1992. Diffusion of
information technology outsourcing: influence sources and
the kodak effect. Information Systems Research, 1992.
[5] DIBBERN, J. et al.. 2004. Information Systems
Outsourcing: A Survey and Analysis of the Literature. The
DATA BASE for Advances in Information Systems, v.35,
n.4, 2004.
[6] DOMBERGER,
Simon.
1998.
The
contracting
organization: a strategic guide to outsourcing. Oxford:
Oxford Univ. Press, 1998. 229p.
[7] LEITE, J. C.. 1994. Terceirização em informática. São
Paulo: Makron Books, 1994.
Tabela 4. Principais benefícios citados nos artigos.
BENEFÍCIOS
QTD DE FREQUÊNCIA
CITAÇÕES DE CITAÇÕES
ACESSO A NOVAS CAPACIDADES, COMPETÊNCIAS E RECURSOS
2
50%
MELHORIA DOS PRODUTOS E SERVIÇOS
AUMENTO DA FLEXIBILIDADE DOS SERVIÇOS
2
2
50%
50%
REDUÇÃO DE CUSTOS
ACESSO A NOVAS TECNOLOGIAS
FOCO NAS COMPETÊNCIAS ESSENCIAIS
MELHORIA DOS PROCESSOS E NEGÓCIOS
2
2
1
1
50%
50%
25%
25%
[8] KITCHENHAM, B. 2004. Procedures for performing
systematic reviews. Keele, UK, Keele University, v. 33, n.
TR/SE-0401, p. 28, 2004.
[9] BIOLCHINI, J. et al. 2005. Systematic Review in Software
Engineering. Engineering, v. 679, n. May, p. 165–176,
2005.
[10] CUNHA, M.X.C. 2011. Aspectos e Fatores Motivadores
da Terceirização de Sistemas de Informação no Setor
Público: Um Estudo em Instituições Públicas de Alagoas.
Tese (Doutorado em Administração) - Universidade Federal
de Pernambuco, Recife, 2011.
4. CONCLUSÃO
A revisão sistemática conduzida neste artigo identificou as
principais contribuições na literatura, nos últimos dez anos, para
terceirização de sistemas de informação no setor público.
Seguindo as etapas definidas no protocolo, foi possível responder
as três questões de pesquisa propostas.
[11] COX, Michael, Martyn Roberts, and John Walton. 2011. IT
outsourcing in the public sector: experiences form local
government. The Electronic Journal Information Systems
Evaluation 14.2 (2011): 193-203.
[12] GANTMAN, Sonia. 2011. IT outsourcing in the public
sector: A literature analysis. Journal of Global Information
Technology Management, v. 14, n. 2, p. 48-83, 2011.
Quanto aos riscos, os mais populares entre os artigos selecionados
foram questões relacionadas à segurança, dependência dos
fornecedores e perda das competências centrais de TI. As
principais motivações foram o foco nas competências essenciais
da organização, redução de custos e melhoria na qualidade dos
serviços. Já em relação aos benefícios, foi apontado o aumento na
[13] LACITY, M. C.; Willcocks, L. 1997. Information systems
sourcing: examining the privatization option in USA public
administration [Electronic version]. Information Systems
Journal, 7 (1997), 85–108.
12
Uma Comparação entre o Desenvolvimento de Aplicações
Web Convencionais e Aplicações em Nuvem
Bruno Lopes†
Kleber Manrique Trevisani‡
IFSP - Instituto Federal de Educação, Ciência e
Tecnologia de São Paulo
Rua José Ramos Júnior, 27-50
CEP 19470-000 - Pres. Epitácio - SP
IFSP - Instituto Federal de Educação, Ciência e
Tecnologia de São Paulo
Rua José Ramos Júnior, 27-50
CEP 19470-000 - Pres. Epitácio - SP
[email protected]
[email protected]
os recursos são virtuais e ilimitados e que detalhes dos sistemas
físicos de software são abstraídos.
ABSTRACT
This paper compare aspects related to development of a same
Web application, when developed to a cloud application provider
and when developed to a non-cloud environment. This
comparison are mainly concerned about highlight the differences
for developers.
Já [5], analisa a computação em nuvens sob uma ótica diferente, e
afirma que o surgimento do fenômeno conhecido como
computação em nuvem representa uma mudança fundamental na
forma como a tecnologia da informação (TI) é inventada,
desenvolvida, implantada, escalada, atualizada, mantida e
mensurada monetariamente.
RESUMO
Este artigo compara aspectos relacionados ao desenvolvimento de
uma mesma aplicação Web, quando desenvolvida para um
provedor de aplicações em nuvem e quando desenvolvida para um
ambiente não classificado como nuvem. Nessa comparação são
consideradas principalmente as diferenças relevantes para os
programadores.
2. OBJETIVOS E JUSTIFICATIVAS
O mercado de computação em nuvens é dominado pela Amazon
seguida pelos seus concorrentes IBM, Apple, Cisco, Google,
Microsoft, Salesforce e Rackspace. Estima-se que o mercado
global de equipamentos em nuvem chegará a U$ 79,1 bilhões em
2018, em 2015 os gastos do usuário final em serviço de nuvem
podem ser maiores que US$ 180 bilhões [6].
__________________________
†Discente
e ‡Docente do Curso Superior de Tecnologia em
Análise e Desenvolvimento de Sistemas
Atualmente há uma considerável adesão de aplicações
implantadas em nuvens, como por exemplo, Google Drive, One
Drive, DropBox, ICloud, entre outras. No entanto, nota-se que as
aplicações mais difundidas têm o objetivo de armazenamento de
arquivos na nuvem e são classificadas como SaaS. Por outro lado,
o desenvolvimento de aplicações para provedores de serviço de
nuvens que oferecem PaaS, ainda não está amplamente
disseminado.
CCS
• Information systems ➝ Information systems applications ➝
Computing platforms; • Networks ➝ Networks services ➝
Cloud computing;
Palavras-chave
Este trabalho tem por objetivo comparar aspectos relacionados ao
desenvolvimento de uma determinada aplicação Web quando
desenvolvida para um provedor de serviços de nuvem que oferece
PaaS e quando desenvolvida para um ambiente não classificado
como nuvem (referenciada a partir desse ponto como aplicação
convencional). Foram levados em consideração nessa comparação
a dificuldade de desenvolvimento, a quantidade e qualidade das
bibliotecas de software disponibilizadas e a dificuldade de
implantação da infraestrutura necessária. Como resultado, serão
apresentados detalhes sobre o processo de desenvolvimento,
destacando as vantagens e desvantagens identificadas.
Cloud Computing, Software Development, Computing Platforms.
1. INTRODUÇÃO
Computação em nuvem é um modelo que permite acesso sob
demanda, de maneira ubíqua e conveniente, por meio de uma rede
de computadores, a um conjunto compartilhado de recursos
computacionais (ex. redes, servidores, armazenamento, aplicações
e serviços) que podem rapidamente ser provisionados e liberados
com mínimo esforço de gerenciamento ou interação com o
provedor de serviços [1]. Os serviços oferecidos pela nuvem
variam desde aspectos de baixo nível, como a infraestrutura lógica
e física (IaaS - Insfrastructure as a Service), serviços no nível de
aplicação (SaaS - Software as a Service) e plataformas de
software (PaaS - Platform as a Service) [2].
É importante ressaltar que o trabalho em questão foi totalmente
desenvolvido por um discente† e orientado por um docente‡,
ambos do curso superior de tecnologia em Analise e
Desenvolvimento de Sistemas do IFSP Campus Presidente
Epitácio.
Segundo [3], computação em nuvem é um termo utilizado para
descrever um ambiente de computação baseado em uma imensa
rede de servidores, sejam eles virtuais ou físicos. Um conjunto de
recursos como capacidade de processamento, conectividade,
plataformas, aplicações e serviços disponibilizados na Internet.
3. DESENVOLVIMENTO
3.1 Descrição do cenário
Considerando a necessidade de implementar operações CRUD
(Create, Retrieve, Update and Delete) para a grande maioria dos
sistemas de informação tradicionais, foi decidido que a aplicação
a ser desenvolvida deveria realizar tais operações. Devido a
limitações de tempo, somente foi possível implantar a aplicação
Com uma definição mais restrita, [4] descreve a computação em
nuvem referindo-se a aplicativos e serviços que são executados
em uma rede distribuída usando recursos virtualizados e acessados
por normas comuns de protocolo. Distingue-se pela noção de que
13
em um único provedor de serviços de nuvem, nesse caso, o GAE
(Google App Engine).
A plataforma de desenvolvimento GAE possui três formas de
armazenamento não relacionais (Bigtable, Blobstore, Google
Storage), todas elas utilizando a uma estrutura semelhante de
armazenamento, porém com algumas diferenças. O Bigtable é a
forma mais simples delas, porém limita o armazenamento de
arquivos do tipo blob (binários) a no máximo 1MB. O Blobstore
permite o armazenamento de arquivos maiores em relação ao
Bigtable, mas ele força o uso de uma URL única de upload [9].
Para facilitar a comparação, decidiu-se que ambas aplicações
fossem desenvolvidas utilizando uma mesma linguagem de
programação e um mesmo ambiente de desenvolvimento. Nesse
contexto, foram selecionados a linguagem Java e o ambiente de
desenvolvimento integrado Eclipse. É importante destacar que o
GAE também suporta implantação de aplicações desenvolvidas
em Python e PHP [7].
Em relação a desempenho, o Google Storage é a melhor das três
opções de armazenamento do GAE. Adicionalmente, ele é de
simples utilização após seu funcionamento ser compreendido. O
Google Storage tem muito em comum com o Amazon S3, pois os
dois usam o mesmo protocolo e possuem a mesma interface
RESTful, considerando que as bibliotecas desenvolvidas para
trabalhar com o S3, como a JetS3t, também funcionam no Google
Storage [9].
Como a aplicação desenvolvida não necessita da utilização de
blobs (binários) com tamanhos grandes e nem muito espaço de
armazenamento, foi selecionado o modelo do Bigtable,
considerando que o mesmo oferece recursos suficientes para o
desenvolvimento da aplicação em nuvem proposta, além de
simplificar a implementação.
Figura 1. Interface gráfica utilizada.
Com o mesmo objetivo, foi decidido que ambas aplicações
deveriam utilizar o mesmo layout para a interface gráfica,
conforme ilustrado pela Figura 1. Devido a utilização da mesma
linguagem de programação para o desenvolvimento das duas
aplicações, foi possível utilizar a mesma tecnologia para
elaboração de interfaces, nesse caso, o framework JSF (Java
Server Faces).
Para persistir um objeto no GAE, primeiramente é necessário
obter as informações preenchidas pelo usuário nos formulários
JSF, o que é possível utilizando métodos específicos do Manager
Bean.
A Figura 4 apresenta trechos de código que foram utilizados para
realizar a persistência de objetos nas aplicações desenvolvidas. É
possível observar que os dois métodos são bastantes similares,
porém o método da aplicação em nuvem utiliza o ofy(), que é
uma instancia da biblioteca Objectify utilizada para persistir os
dados na nuvem [8].
3.2 Persistência de dados
A manipulação de dados pela aplicação convencional foi
realizada utilizando uma API da linguagem Java que descreve
uma interface comum para frameworks de persistência de dados
chamada JPA (Java Persistence API) além do sistema gerenciador
de banco de dados PostgreSQL. O servidor de aplicações
GlassFish também foi utilizado para implantar a aplicação.
No GAE somente é possível realizar o armazenamento utilizando
persistência de dados, não havendo possibilidade de selecionar um
sistema gerenciador de banco de dados, considerando que essa
tarefa é realizada de forma transparente e o programador não
precisa conhecer detalhes sobre o SGBD utilizado. O GAE
fornece um framework de persistência que permite o
armazenamento dos objetos instanciados, chamado Objectify [8].
A Figura 2 ilustra a interação entre os componentes importantes
para realizar a persistência de dados na aplicação convencional e
na aplicação desenvolvida para nuvem.
(a)
public Long save(Cliente c) {
ofy().save().entity(cliente).now();
return cliente.getId();
}
(b)
public void persist(Cliente c) {
em.persist(c);
}
Figura 4. (a) Persistência no GAE. (b) Persistência JPA.
3.3 Detalhes do provedor de nuvem
O desenvolvimento da aplicação em nuvem necessita de algumas
atividades adicionais em relação ao desenvolvimento da aplicação
convencional, como por exemplo, importar a biblioteca Objectify,
instalar o plugin GAE no IDE Eclipse e editar o arquivo de
configuração web.xml (Figura 3). Nesse arquivo, um elemento
listener deve indicar a classe Java responsável pelo registro das
entidades (classes) que serão persistidas no Objectify (Figura 3a).
A configuração do Objectify também precisa ser descrita no
arquivo web.xml para que o servidor tenha conhecimento que o
framework Objectify está sendo utilizado no projeto (Figura 3b).
O controle de threads na aplicação convencional é gerenciado
pelo próprio JSF. Entretanto, na aplicação em nuvem, esse
controle é realizado pelo GAE, obrigando o desenvolvedor a
desabilitar tal funcionalidade para evitar incompatibilidades com
o JSF (Figura 3c). Ainda dentro desse arquivo, deve ser indicado
o padrão de projeto que será utilizado pelo framework JSF, nesse
caso em específico (Figura 3d), o Front Controller [10].
Figura 2. Interação entre os componentes. (a) Aplicação
convencional. (b) Aplicação em nuvem.
14
(a) 
<listener>
<listener-class>
config.ConfigStartup
</listener-class>
</listener>
uma conta do Google. Cada conta pode ter mais de uma aplicação
implantada no GAE, porém cada aplicação possui um
identificador para diferenciá-la das outras. Por essa razão, ao
realizar uma implantação ou atualização, é necessário fornecer o
título do projeto e o Application Identifier que foram previamente
criados no próprio site do GAE.
(b) 
<filter>
<filter-name>
ObjectifyFilter
</filter-name>
<filter-class>
com.googlecode.objectify.ObjectifyFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>
ObjectifyFilter
</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
(c) 
<context-param>
<param-name>
com.sun.faces.enableThreading
</param-name>
<param-value>false</param-value>
</context-param>
(d) 
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>
javax.faces.webapp.FacesServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
Figura 6. Implantação de aplicação no GAE via Eclipse
4. CONSIDERAÇÕES FINAIS
O desenvolvimento da aplicação em nuvem no GAE é bastante
similar em relação ao desenvolvimento de uma aplicação Web
para ambientes não classificados como nuvem, considerando a
utilização da linguagem Java e o cenário apresentado, pois é
possível utilizar os mesmos recursos para ambas, como por
exemplo, JSP (Java Server Pages) e JSF.
Figura 3. Arquivo web.xml utilizado.
3.4 Implantação
Em relação ao armazenamento de dados, nesse caso em
específico, pode-se dizer que um desenvolvedor que tem
conhecimento em JPA teria maior facilidade para a desenvolver a
aplicação em nuvem do que outro que domina somente o
armazenamento de dados utilizando técnicas que não realizam a
persistência de objetos, como por exemplo, JDBC.
A implantação de ambas aplicações apresenta complexidade
baixa. Para implantação da aplicação Web convencional no
servidor GlassFish é necessário utilizar o console administrativo
do mesmo (Figura 5) por meio de um navegador Web.
Posteriormente deve-se abrir a aba Applications, no canto
esquerdo do console, selecionar o botão deploy e indicar o
caminho local do projeto a ser implantado. Para atualização da
aplicação deve-se utilizar o mesmo procedimento, mas deve-se
pressionar o botão Redeploy e selecionar localmente o projeto a
ser atualizado.
Mesmo sendo uma comparação com abrangência restrita, devido a
utilização de um único provedor de serviços de nuvem e uma
única linguagem de programação, foi possível perceber que o
conhecimento da filosofia do provedor de nuvens, sua API e seus
mecanismos de armazenamento são muito importantes para o
desenvolvimento de aplicações para o mesmo. Esses
conhecimentos demandam tempo de aprendizado significativo,
principalmente para programadores inexperientes, como foi o caso
deste trabalho
Como trabalho futuro, pretende-se a utilização de outros
provedores de nuvem e outras linguagens de programação para
realizar a comparação. Também pretende-se utilizar outros
parâmetros que impactam na decisão de migrar uma aplicação
convencional para nuvem, como por exemplo, desempenho e
custo de hospedagem.
Figura 5. Console administrativo do Glassfish
5. AGRADECIMENTOS
Já a aplicação em nuvem é implantada utilizando um botão no
Ecplise (deploy), disponibilizado pelo plugin do GAE, que invoca
a interface apresentada pela Figura 6. Nesse caso, o Eclipse
solicita que o desenvolvedor se autentique previamente utilizando
Os autores agradecem ao IFSP - Instituto Federal de Educação,
Ciência e Tecnologia de São Paulo pelo apoio financeiro durante
o desenvolvimento deste trabalho.
15
computing-united-states-businesses-will-spend-13-billionon-it/>. Acesso em: 10 Mar 2016.
6. REFERENCIAS
[1] Mell, Peter, and Tim Grance. "The NIST definition of cloud
computing." Communications of the ACM 53.6 (2010): 50.
[7] Google App Engine Docs. Disponível em: <https://cloud.
google.com/appengine/docs>. Acesso em: 10 Mar. 2016.
[2] Coulouris, George F., Jean Dollimore, and Tim Kindberg.
Distributed systems: concepts and design. pearson education,
2005.
[8] Schnitzer, J. et. al. Introduction to Objectify: Loading,
Saving, and Deleting Data. Disponível em: <https://github.
com/objectify/objectify/wiki/BasicOperations>. Acesso em:
10 Mar 2016.
[3] Taurion, C. Cloud Computing-Computação em Nuvem.
Brasport, 2009.
[9] Wheeler, J. Armazenamento do GAE com Bigtable,
Blobstore e Google Storage. 2011. Disponível em:
<www.ibm.com/developerworks/br/library/j-gaestorage/>.
Acesso em: 10 Mar 2016.
[4] Sosinsky, B. Cloud computing bible. John Wiley & Sons,
2010.
[5] Marston, S., et al. "Cloud computing—The business
perspective." Decision support systems 51.1 (2011): 176-189.
[10] MEDEIROS, H. Padrões de Projeto: Introdução aos Padrões
Front Controller e Command. Disponível em: <http://www.
devmedia.com.br/padroes-de-projetos-introducao-aospadroes-front-controller-e-command/30644>. Acesso em: 10
Mar 2016.
[6] Mccue, TJ. Cloud Computing: United States Businesses Will
Spend
U$13
Billion
On
it.
Disponível
em:
<http://www.forbes.com/sites/tjmccue/2014/01/29/cloud-
16
Seleção de Ferramenta de Gestão de Demandas de
Desenvolvimento Ágil de Software para Órgão Público
Alternative Title: Selection tool to support a process of demand
management of agile development of a public organization
Emilie T. de Morais, Geovanni O. de Jesus, Rejane M. da C. Figueiredo, Elaine Venson
Information Technology Research and Application Center, Faculdade Gama, Universidade de Brasília, Brasil
{emiliemoraist, geovannirock}@gmail.com, {rejanecosta, elainevenson}@unb.br
federal public organization. The tool is already in use.
RESUMO
A contratação de fornecedores para serviços de Tecnologia da
Informação (TI) é uma realidade em órgãos públicos federais. E o
movimento dos órgãos na contratação de fábricas de software, a
partir da adoção de metodologias ágeis, tem sido recorrente. Neste
cenário, o apoio de uma ferramenta em processos de
desenvolvimento ágil pode ser essencial, dada a quantidade de
envolvidos e, muitas vezes, tendo os fornecedores
geograficamente dispersos. Este trabalho teve como objetivo a
identificação e configuração de ferramentas para apoio a um
processo de gestão de demandas de desenvolvimento Ágil de
software de um órgão público federal brasileiro. O estudo foi
realizado em duas vertentes, a definição e execução de um
processo de seleção de ferramentas e o emprego de estudo de caso
para levantamento dos requisitos específicos. Como resultado foi
definida e configurada uma ferramenta para um órgão. A
ferramenta encontra-se em uso.
D. Software. D.2 Software Engineering. D.2.2 Design Tools.
General Terms
Management.
Keywords
Tool; Agile methods; Backlog; Federal Public Organization.
1. INTRODUÇÃO
Os órgãos públicos não são responsáveis, em sua maioria, pela
produção de software, mas sim pela gestão de demandas para
contratação desse tipo de serviço. A terceirização de serviços de
desenvolvimento de software é uma realidade no setor público [3].
Nesse cenário a adoção da metodologia ágil tem sido crescente [2]
[12] [13][16] [9].
Nos métodos ágeis os requisitos geralmente são gerenciados com
papel e caneta, ou seja, com o uso de notas pregadas em um mural
ou uma parede [5] [1]. Isso acontece visto que a maioria dos times
ágeis é formada por poucas pessoas e estão alocadas no mesmo
lugar. A gestão desse desenvolvimento normalmente é realizada
no nível do time de desenvolvimento. Já no setor público, quando
o serviço é terceirizado, o time é formado por integrantes de
fábricas de software e deve ser realizada pelo contratante, que
deve gerenciar as demandas de serviços prestados pelo contratado,
que podem estar em outra região. Nesse cenário, é essencial o
apoio ferramental para o gerenciamento das demandas de
serviços, dos requisitos e do processo de execução.
Palavras-Chave
Ferramenta; Métodos ágeis; Backlog; Órgão público federal.
ABSTRACT
The hiring of supplier for Information Technology (IT) is a reality
for federal public organizations. And the movement of federal
public organization in hiring companies for offshore software
development, starting from the adoption of agile methodologies
has been recurrent. In this scenario the support of a tool for agile
software development processes might be essential, given the
amount of involved parts and, many times, the offshore companies
are geographically distant. The objective of this study was the
identification and setting of a tool to support a process of demand
management of agile software development of a Brazilian federal
public organization. The study has been done in two aspects, the
definition and the execution of tool selection process and the
employment of the study of case for gathering the specific
requirements. As result, it has been defined and set a tool for the
Este trabalho faz parte de um Projeto de Pesquisa e
Desenvolvimento, oriundo de um Termo de Cooperação entre
uma universidade e um órgão público federal, denominado neste
trabalho como Ministério. O Ministério possui um Processo de
Gestão de Demandas de Desenvolvimento Ágil de Software
(GeDDAS) [15]. Esse processo foi baseado no framework Scrum
[11]. Um dos artefatos gerados é o Backlog do Produto1 [15].
O objetivo deste trabalho foi definir um processo de identificação
e configuração de ferramentas para dar apoio à gestão de
demandas de serviços do processo de desenvolvimento ágil.
Copyright SBC 2016.
Este trabalho está organizado em seções. Na Seção 2 é
apresentada uma breve descrição de métodos ágeis e do
framework Scrum. Na Seção 3, apresentam-se os materiais e
1
17
Lista de itens necessários ao produto. Origem única de
requisitos. [11]
métodos adotados. Na Seção 4 apresentam-se a execução e análise
do processo de seleção da ferramenta definido. Na Seção 5, as
considerações finais.
Para desenvolvimento de software, o órgão possui dois processos,
um baseado na metodologia tradicional e outro processo baseado
no framework Scrum, conhecido como GeDDAS (Gestão de
Demandas de Desenvolvimento Ágil de Software) [15].
2. MÉTODOS ÁGEIS
A metodologia ágil tem atraído um grande interesse da indústria
de software [6] e a adoção da metodologia tem crescido no setor
público, como mostram os levantamentos feitos por [2], [9], [13] e
[16]. No levantamento feito pelo TCU [2] é percebido que a
abordagem mais adotada tem sido o Scrum.
3.1.2 Processo GeDDAS
2.1 Scrum
O GeDDAS [15] é composto por seis subprocessos: Planejar
Projeto, Planejar Release, Executar Sprints, Atestar Qualidade da
Release, Homologar Release e Implantar Release. E também são
previstos papéis e artefatos [15].
Dado que, neste trabalho, a identificação e configuração da
ferramenta foi realizada para apoiar o processo de
desenvolvimento de software do Ministério, nesta seção
apresenta-se uma breve descrição do processo GeDDAS.
O Scrum é definido como uma estrutura (framework) na qual se
pode empregar vários processos ou técnicas [11]. O framework é
composto de eventos, papéis e artefatos que auxiliam na busca das
melhores práticas de gerenciamento, orientando atividades de
desenvolvimento [11].
Um dos artefatos definidos é o Backlog do Produto e da Sprint. O
Backlog do Produto não é utilizado apenas no subprocesso de
Implantar Release. Assim, a ferramenta adequada ao Ministério
deve apoiar o emprego do Backlog em cada um dos subprocessos
por cada um dos papéis responsáveis.
Os eventos que formam o Scrum são: Sprint, Cancelamento da
Sprint, Reunião de Planejamento da Sprint, Reunião Diária,
Retrospectiva da Sprint. E os papéis estabelecidos são: Product
Owner (PO), Time de Desenvolvimento e Scrum Master [11].
No emprego do Backlog, os itens: Funcionalidades; Defeitos;
Histórias técnicas; Não Conformidades e Aquisição de
Conhecimento e seus status devem ser monitorados.
Dentre os artefatos propostos pelo Scrum constam o Backlog do
Produto e o Backlog da Sprint. Ambos consistem em uma lista dos
requisitos inerentes ao produto que deve ser entregue. No caso do
Backlog do Produto estão reunidos todos os itens que formam o
produto completo e no Backlog da Sprint contém os itens
referentes a um incremento de software [11].
Na Tabela 1 é apresentado o uso do Backlog de acordo com os
papéis do processo.
Tabela 1. Relação entre os papéis e a utilização do Backlog
Emprego do Backlog
Dado o objetivo de identificação, seleção e configuração de uma
ferramenta para um órgão brasileiro, essa pesquisa é considerada
descritiva [8], que geralmente utiliza a técnica de levantamento.
Também foi empregada a técnica de estudo de caso.
Este trabalho foi dividido em três principais fases: Planejamento;
Coleta e Análise de dados; e Redação dos resultados. No
planejamento foram previstas duas vertentes: caracterização do
objeto do estudo de caso, na qual são identificadas as demandas
do processo de desenvolvimento e caracterizados os
relacionamentos do órgão com seus usuários de negócio e seus
fornecedores, e outra vertente, relacionada à definição e execução
de um processo de seleção de ferramentas, composto pelas etapas:
Identificação, Seleção e avaliação; Validação; e Treinamento. Na
fase Coleta e análise de dados o processo estabelecido foi
executado. Os resultados foram redigidos.
Papéis
Visualização dos itens
Todos os envolvidos
Revisão (edição) dos itens
Proprietário do Produto,
Time de Desenvolvimento
Adição de itens de funcionalidades
Proprietário do
Usuários-chave
Adição de itens de não conformidade
Proprietário do Produto,
Equipe de Qualidade
Adição de itens de defeito
Equipe de Qualidade
Adição de itens de história técnica e
aquisição de conhecimento
Time de Desenvolvimento
Priorização dos itens
Proprietário do Produto
Produto,
Para a implantação do processo foi realizado um projeto-piloto
[15], no qual a gestão do Backlog do Produto era realizada em
uma planilha. Dessa forma, foi identificada a necessidade de uma
ferramenta que apoiasse o processo principalmente o Backlog.
3.1 Caracterização do Objeto
Foram caracterizados o órgão e seu processo de software.
3.2 Processo de Seleção da Ferramenta
3.1.1 Ministério
O processo de seleção de ferramentas é composto pelas etapas:
identificação, seleção e avaliação, validação e treinamento.
O setor de TI do órgão é composto por uma Coordenação-Geral,
uma Coordenação de Informática, duas Divisões, de Recursos e
Administração de Rede e de Desenvolvimento de Sistemas e uma
unidade de Serviço de Atendimento ao Usuário.
3.2.1 Identificação
Na etapa de identificação foi realizada uma pesquisa bibliográfica
para levantamento das ferramentas e definição de critérios de
seleção de ferramentas adequadas ao Ministério. A revisão foi
realizada pela busca em bases de dados, busca manual em
conferências brasileiras e utilização do processo de snowballing2.
No contrato vigente, o Ministério possui quatro fornecedores:
apoio à gestão, responsável por auxiliar nas atividades de
acompanhamento dos projetos e sistemas; apoio técnico, que
auxilia na garantia da qualidade; fábrica de software, responsável
pelo desenvolvimento de sistemas e pela manutenção dos legados
do Ministério; infraestrutura de TI, responsável pela
infraestrutura.
2
Identificação de estudos a partir de um estudo, através das
referências ou dos trabalhos que citam este estudo. [10]
18
3.2.2 Seleção e Análise
Considerando os critérios estabelecidos foram selecionadas as
ferramentas XPlanner, FireScrum, IceScrum e Redmine. Que,
embora gratuitas, algumas apresentavam limitações de uso.
Assim, como o órgão já utilizava o Redmine, em reunião com o
Ministério, optou-se por avaliar esta. Foram levantados três plugins do Redmine para apoio ao desenvolvimento ágil: Backlogs,
Scrum e Scrumbler.
Na etapa de seleção foram definidos critérios de seleção e análise
das ferramentas identificadas a partir da literatura, dos requisitos
do Ministério e de seu processo de desenvolvimento de software.
3.2.3 Validação
Na etapa de validação, uma vez selecionada a ferramenta, essa foi
configurada segundo os requisitos do GeDDAS. Em seguida, a
ferramenta configurada foi avaliada pelos envolvidos no processo.
No estudo realizado por Dimitrijević et al [5] foram definidas as
seguintes categorias de critérios: Suporte a modelagem de papéis
de usuário, Gestão de histórias de usuário e épicos, Suporte a
testes de aceitação, Planejamento de release, Planejamento de
iteração, Acompanhamento do processo. Aspectos como
usabilidade, integração com outros sistemas e opção de
customizações, foram utilizados por Azizyan et al [1].
3.2.4 Treinamento
Nesta etapa, após a validação da ferramenta foram previstos
treinamentos a distância e presencial para os usuários.
4. SELEÇÃO DAS FERRAMENTAS
Utilizando como base as categorias estabelecidas [5] [1] e os
aspectos do processo GeDDAS, os critérios de avaliação foram
estabelecidos e realizada a avaliação de cada plug-in, Tabela 3.
Nesta seção apresenta-se o processo de seleção das ferramentas.
4.1 Identificação das Ferramentas
Tabela 3. Avaliação dos plug-ins do Redmine
Para o levantamento das ferramentas nas bases de dados foram
empregadas as palavras-chave em inglês: Requirements
engineering, Agile practices, User story management, Software
support, Agile Backlog Management, Sprint Planning,
Application lifecycle Management, Global Software Development,
Global Software Engineering, Tool, Process, Development,
Methods, Task board, Project Management.
Em português, foi realizada a busca manual em duas conferências:
CBSoft e SBSI considerando as publicações dos últimos cinco
anos. Também foi utilizada a técnica de snowballing [10],
buscando trabalhos a partir das referências.
Assim, foi possível identificar as seguintes ferramentas: (MS
project, Rally, Trac, Mingle, ScrumWorks, JIRA, MS Team
Foundation Server, XPlanner, OutSystem, AgileZen, TinyPM,
Urban Turtle, Agile Tracking tool, Agilito, Agilo, Conchango
Scrum, Digite, EmForge, Axsoft, WoodRanch, KLL Software,
LeanKitKanban, Polarion, ScrumPad, Seenowdo, EMC, Silver
Catalyst, Assembla) [1]; (Planbox, tinyPM, Agilo for track,
ScrumDesk [5]); VersionOne [1][5][4]; Redmine [7][1] e
(TargetProcess, ScrumWorks, Agilo for Scrum e FireScrum [4]).
Considerando a avaliação realizada, foi possível observar que o
plug-in Backlogs atendeu a todos os critérios adotados. O
Backlogs foi considerado o mais adequado para o contexto.
4.2 Seleção e Análise das Ferramentas
Foram estabelecidos alguns critérios para seleção das ferramentas.
A motivação é apresentada na Error! Not a valid bookmark
self-reference..
4.3 Validação da Ferramenta
Com a seleção da ferramenta e do plug-in foi necessário
configurá-los para o GeDDAS. Em seguida buscou-se a validação
com os envolvidos no processo.
Tabela 2. Critérios para seleção das ferramentas
Motivações
Critérios
A gestão do Backlog deve ser o
principal aspecto considerado,
visto que motivou a adoção de
uma ferramenta
Permitir o gerenciamento do
Backlog, como a adição, edição e
exclusão de itens, bem como a
alocação em iterações e entregas
A aquisição de uma ferramenta
não foi prevista pelo órgão, e
não havia orçamento previsto
Ser gratuita
O processo de desenvolvimento
utilizado prevê vários papéis
que devem interagir com a
ferramenta e esses papéis
devem
possuir
diferentes
permissões
Possuir configuração de perfis de
acesso
4.3.1 Configuração da Ferramenta e do Plug-in
Considerando os aspectos do processo (Tabela 4), como os papéis,
os status dos itens e o tipo de item do Backlog que pode ser
criado, foram configurados: a pontuação das histórias, os tipos de
itens do Backlog, o status dos itens, o perfil de usuário e as
permissões necessárias.
Tabela 4. Itens configurados
19
4.3.2 Validação com os envolvidos
Práticas em Contratação de Soluções de Tecnologia da
Informação.
Para a validação da ferramenta e plug-in foi realizada uma
apresentação para o Ministério por meio de reunião com os
envolvidos no processo, representantes da DISIS, fornecedor de
apoio à gestão e fábrica de software. A ferramenta foi aprovada e
as configurações no ambiente do Ministério foram realizadas.
[4] Cavalcanti, E., Maciel, T.M. de M. and Albuquerque, J. 2009.
Ferramenta Open-Source para Apoio ao Uso do Scrum por
Equipes Distribuídas. III Workshop de Desenvolvimento
Distribuído de Software, (Oct. 2009), 51-60.
[5] Dimitrijević, S., Jovanović, J. and Devedžić, V. 2014. A
comparative study of software tools for user story management.
Information and Software Technology. (May 2014), 1-17. DOI =
10.1016/j.infsof.2014.05.012
4.4 Treinamento dos usuários
O treinamento da ferramenta foi realizado presencialmente e a
distância. Essa estratégia foi escolhida levando em consideração o
fato da fábrica de software ser de outra cidade.
[6] Dybå, T. and Dingsøyr, T. 2008. Empirical studies of agile
software development: A systematic review. Information and
Software Technology. 50, 9-10 (Aug. 2008), 833–859.
O Ministério possui a plataforma moodle. A equipe configurou a
plataforma para treinamentos dos processos e ferramentas
definidas. Pela plataforma, o treinamento a distância foi composto
de vídeos, slides e exercícios de fixação referentes à configuração
e utilização da ferramenta.
[7] Engum, E.., Racheva, Z. and Daneva, M. 2009. Sprint
Planning with a Digital Aid Tool: Lessons Learnt. 35th Euromicro
Conference on Software Engineering and Advanced Applications,
2009. SEAA ’09 (Aug. 2009), 259–262.
Para o treinamento presencial, professores e estudantes
ministraram os cursos. A utilização da ferramenta e do seu plug-in
foi simulada com os seus usuários em cada parte do processo.
[8] Gil, A.C. 2008. Como elaborar projetos de pesquisa. Atlas.
[9] Inglaterra National Audit Office 2012. Governance for Agile
delivery.
http://www.nao.org.uk/report/governance-for-agiledelivery-4/.
Os treinamentos aconteceram no mês de janeiro a março de 2015,
e foram direcionados a todos os envolvidos, desde usuários do
negócio do Ministério (Proprietário do Produto), servidores do
Ministério e fornecedores de fábrica e de apoio à gestão.
[10] Jalali, S. and Wohlin, C. 2012. Systematic literature studies:
database searches vs. backward snowballing. Proceedings of the
ACM-IEEE international symposium on Empirical software
engineering and measurement (Sep. 2012), 29–38.
A seleção, treinamento e configuração da ferramenta de suporte
para o GeDDAS no Ministério fez parte de uma melhoria do
processo, o que acarretou a substituição de planilhas para uma
ferramenta mais apropriada para realização das atividades.
[11] Jeff Sutherland, K.S. 2011. Guia do SCRUM: Um Guia
Definitio do SCRUM - As regras do Jogo. SCRUM Org.
[12] Melo, C. de O. and Ferreira, G.R. 2010. Adoção de métodos
ágeis em uma Instituição Pública de grande porte-um estudo de
caso. Workshop Brasileiro de Métodos Ágeis, Porto Alegre (Jun.
2010), 112-125.
Embora, a escolha da ferramenta tenha sido para um contexto
específico, os critérios analisados e a análise podem ser utilizados
para seleção de uma ferramenta para um contexto semelhante.
Atualmente, a ferramenta começou a ser utilizada em um projeto
no Ministério e como trabalho futuro será realizado o
monitoramento do uso da ferramenta.
[13] Melo, C. de O., Santos, V., Katayama, E., Corbucci, H.,
Prikladnicki, R., Goldman, A. and Kon, F. 2013. The evolution of
agile software development in Brazil. Journal of the Brazilian
Computer Society. 19, 4 (Nov. 2013), 523–552.
[14] Software Development: Effective Practices and Federal
Challenges
in
Applying
Agile
Methods:
2012.
http://www.gao.gov/assets/600/593091.pdf.
6. AGRADECIMENTOS
Nossos agradecimentos pelo apoio recebido da UnB.
[15] Sousa, T.L. de, Figueiredo, R.M. da C., Venson, E.,
Kosloski, R.A.D. and Ribeiro Junior, L.C.M. 2016. Using Scrum
in Outsourced Government Projects: An Action Research. 2016
49th Hawaii International Conference on System Science. (Jan.
2016), 5447-5456.
7. REFERÊNCIAS
[1] Azizyan, G., Magarian, M.K. and Kajko-Matsson, M. 2011.
Survey of Agile Tool Usage and Needs. Agile Conference
(AGILE), (Aug. 2011), 29–38.
[2] Brasil, Tribunal de Contas da União 2013. Acórdão 231433/13-Plenário. Levantamento de Auditoria. Conhecimento acerca
da utilização de métodos ágeis nas contratações para
desenvolvimentos de ágeis pela Administração Pública Federal.
[16] Vacari, I. and Prikladnicki, R. 2015. Adopting Agile Methods
in the Public Sector: A Systematic Literature Review.
International Conference On Software Engineering And
Knowledge Engineering, 27, 2015.
[3] Brasil, Tribunal de Contas da União 2012. Guia de Boas
20
Um Plugin para Discretização de Dados para Suporte à
Metodologia Agile Rolap
Alternative Title: A Plugin for Discretization of Data to Support the
Methodology Agile Rolap
Luan S. Melo, André Menolli, Glauco C. Silva, Ricardo G. Coelho, Felipe Igawa Moskado
Universidade Estadual do Norte do Paraná – UENP
Centro de Ciências Tecnológicas
Rod BR369 Km 64
[email protected], {menolli, glauco, rgcoelho}@uenp.edu.br, [email protected]
RESUMO
ABSTRACT
Os ambientes de Business Intelligence (BI) dão apoio aos
administradores das empresas a tomarem decisões mais precisas
para sua organização. Esses ambientes, em geral, utilizam da
tecnologia de Data Warehouse (DW), que é um banco de dados
integrado e voltado para consultas. Entretanto a construção de um
DW é um processo custoso e demorado, tornando então um
obstáculo principalmente para pequenas e médias empresas. Com
o intuito de reduzir este problema foi proposta a metodologia
Agile ROLAP, que visa auxiliar na utilização de ferramentas
OLAP a partir das bases relacionais das empresas. Porém, os
analistas na maioria das vezes necessitam visualizar os dados
categorizado (dados discretizados), sendo assim, algumas vezes é
preciso realizar essas transformações. No entanto, a metodologia
preza por não fazer modificações dentro das bases físicas e
também por minimizar o processo de Extract, Transform and
Load (ETL), o qual é necessário para fazer a discretização dos
dados. Assim, este trabalho apresenta o desenvolvimento de
plugins para a ferramenta Kettle e que auxilie na discretização de
dados de forma com que não sejam alteradas as bases originais.
The environments of Business Intelligence (BI) provide support to
managers of companies to make more accurate decisions for your
organization. These environments currently using the Data
Warehouse technology (DW), which is an integrated database and
prepared for query. However, the construction of a DW is a costly
and time consuming process, so making an obstacle mainly for
small and medium companies. In order to reduce this problem,
was proposed the Agile ROLAP methodology, which aims to
assist in the use of OLAP tools from relational databases of
companies. However, managers most often need to view
categorized data (discretized data), so sometimes these
transformations are needed. Nevertheless, the methodology
recommends not make changes in the physical basis and also to
minimize the process Extract, Transform and Load (ETL), in
which it is necessary to make the data discretization. Thus, this
work presents the development of plugins for Kettle tool that
assists in the data discretization helping that the physical
databases are not changed.
1.
As empresas com o decorrer do tempo guardam uma grande
quantidade de informações sobre a sua organização, e no intuito
de utilizar as informações futuramente, muitas utilizam os
ambientes de Business Intelligence (BI),no qual estes ambientes
auxiliam na análise dos dados de forma eficiente e na tomada de
decisão dos administradores da empresa, facilitando também o
conhecimento sobre a sua organização.
H.2.7 [Database Management]: Database Administration – data
warehouse and repository
H.2.8 [Database Management]: Database Applications – data
mining
General Terms
Algorithms, Management, Performance.
A implementação de BI demanda custo e tempo, tornando assim
algo não trivial, pois é necessário um Data Warehouse (DW), no
qual tem como finalidade armazenar informações sobre as
atividades da empresa de forma consolidada.
Keywords
Data Warehouse,
Discretização.
Agile
Rolap,
Business
INTRODUÇÃO
Inteligence,
O processo de criação de um DW normalmente é realizado de
modo iterativo, porém, mesmo assim são necessários em torno de
15 meses ou mais para o que entre em produção o primeiro
módulo[1]. Sendo assim, foi proposto o método Agile ROLAP, no
qual tem como seu objetivo corrigir alguns problemas encontrados
na implantação de um DW.
otherwise, or republish, to post on servers or to redistribu-te to lists,
O objetivo da metodologia Agile ROLAP é permitir uma
implementação de forma ágil de ambientes de BI em que se
utilizem bancos de dados relacionais, e ao mesmo tempo permitir
a utilização de ferramentas OLAP projetadas para ambientes
tradicionais por meio de um servidor ROLAP[2].
Copyright SBC 2016.
21
No entanto, é proposto no Agile ROLAP, que se utilize um
mecanismo intermediário, no qual permita que os dados de
diversas fontes de dados sejam integrados em uma única base,
fazendo com que se mantenha o conceito de DW. Porém na
maioria das vezes os dados das bases relacionais são de forma
continua, isto é, um dado continuo contém toda informação de um
determinado domínio.
baseado nas informações geradas, assim podendo o administrador
conhecer melhor sobre o seu negócio além de possibilitar uma
melhor competição no mercado.
Na Figura 1 é mostrado como é o funcionamento do Agile
ROLAP e a função de cada etapa apresentada na Figura 1 é
descrita a seguir:
Entretanto, os administradores das empresas geralmente desejam
que os dados estejam categorizados para que se possa fazer
analise dos mesmo de forma simples. Sendo assim, o processo de
transformar dados contínuos em dados categorizados é
denominado de discretização[3].

Físico: Representa bases de dados originais. Nestas
estão armazenadas em tabelas todas as informações da
empresa obtidas com o decorrer do tempo.

FDW: Tem como finalidade agrupar todas as
informações da empresa em uma única base de dados.
Estas informações estão armazenadas em formas de
tabelas, porém são cópias das tabelas originais que estão
armazenadas no Físico. Quando um usuário acessa a
tabela, que está em base utilizando a tecnologia de
Foreign Data Wrapper (FDW), consulta diretamente a
base de origem de forma transparente, assim o usuário
acha que está acessando a base no PostgreSQL, mas na
verdade está consultado os dados da base original. Com
isso não tem o risco de que os dados da base original
não sejam modificados, pois o FDW permite apenas o
usuário a fazer consultas.

Schema: é um arquivo conhecido como schema XML.
Esse arquivo realiza o mapeamento dos dados que estão
armazenados na forma relacional, no caso no FDW, para
os dados que devem ser mostrados na forma dimensional. Basicamente esse schema indica onde estão os valores dos atributos na perspectiva multidimensional na
base de dados relacional.

OLAP: On-line Analytical Processing (OLAP) é a uma
forma de se analisar grandes dados sobre múltiplas
perspectiva, no qual é amplamente utilizado nos
ambientes de BI, pois facilita a análise rápida dos dados
gerados na implantação de tal ambiente.
Contudo, não consta na metodologia Agile ROLAP para se tornar
mais simples para sua criação, fez com a diminuísse a etapa do
Extract, Transform and Load (ETL), sendo esta importante para
realização da discretização de dados. Portanto, é proposto neste
trabalho a realização de um plugin para a ferramenta Kettle, em
que auxilie no processo de discretização de dados de forma com
que não se altere as bases originais, mantendo o que foi proposto
na metodologia Agile ROLAP.
2.
REVISÃO BIBLIOGRÁFICA
Esta seção apresenta uma visão geral de conceitos e elementos da
construção de um Data Warehouse utilizando a metodologia Agile
ROLAP, assim como uma breve revisão sobre discretização de
dados.
2.1
Agile ROLAP
A necessidade de armazenar as dados de uma empresa e fazer uma
análise eficiente das mesmas é um processo muito importante no
mercado atual, com isso originou-se o DW, no qual é um depósito
de dados em que consiste em armazenar uma grande quantidade
de dados sobre às atividades de uma empresa. O uso de um DW
favorece uma melhor análise de um grande volume de dados por
meio de ferramentas OLAP, auxiliando no processo de tomada de
decisão das grandes organizações.
DW é o resultado do processo de transformação dos dados obtidos
de sistemas legados e de bancos de dados transacionais que ficam
organizados sob um formato compreensível ao usuário, auxiliando
na tomada de decisão [4]. Além disso, o DW possui algumas
características no qual se diferencia de outros tipos de modelagem
de dados, que são: Orientação por assunto, Integração, Não
Volatilidade e Não Variação no Tempo.
Figura 1. Funcionamento do Agile Rolap
No entanto, como mencionado anteriormente, o processo de
criação de um DW é custosa e demorada, o que muitas vezes se
torna um empecilho para que, principalmente pequenas e médias
empresas o implantem. Dessa forma foi proposta a metodologia
Agile ROLAP, que tem como intuito mitigar alguns problemas
encontrados na implantação de BI, principalmente diminuindo
tempo com o processo de Extract, Transform and Load (ETL) .
Apesar da metodologia não utilizar o conceito tradicional de DW,
consegue-se por meio de seu uso utilizar as ferramentas Online
Analytical Processing (OLAP) disponíveis no mercado.
2.2
Discretização de Dados
O avanço da computação e tecnologia traz consigo grandes taxas
de informações, sendo elas explosivas, e que tendem a crescer
muito mais devido aos novos recursos tecnológicos que estão
surgindo no mercado atualmente [6].
Os dados dessa grande taxa de informação geralmente são
extraídos de forma continua, isto é, tendem vir com toda a
informação de um determinado problema. Os administradores de
empresas normalmente utilizam os dados categorizados para
fazerem suas consultas nas bases de dados.
Assim, a metodologia tem como intuito diminuir o tempo
despendido no processo de ETL, pois não há necessidade de criar
uma nova base de dados. Estima-se que mais de 1/3 do custo na
elaboração de um DW se dá no processo de ETL [5]. Isto permite
que pequenas empresas possam usufruir de ferramentas OLAP
voltadas para ambientes de BI tradicionais, proporcionando
auxilio na tomada de decisão do administrador da organização
Sendo assim, muitas vezes há uma necessidade de se transformar
os dados contínuos em dados categorizados, e essa transformação
de dados é denominada de discretização de dados.
A discretização de dados normalmente é aplicadas nos atributos
que são usados para a análise de classificação ou associação. Para
22
a realização da discretização de dados, ou seja, transformar um
dado contínuo em categorizado envolve duas subtarefas: decidir o
número de categorias; e determinar como mapear os valores do
atributo contínuo entre essas categorias [3]. Na primeira subtarefa,
os valores dos atributos contínuos são devidos em n intervalos,
denominado ponto de divisão. Na segunda, os valores de um
determinado intervalo são mapeados para o mesmo valor de
categoria.
Assim, com intuito de manter os preceitos da metodologia, o
plugin desenvolvido também utiliza o PostgreSQL para realizar as
suas funcionalidades, pois caso sejam necessários criar novos
atributos discretizados, estes serão criados na base intermediária e
não nas bases de origem. Dessa maneira, para o funcionamento do
plugin, são criadas views materializadas dentro da base de dados
intermediária. Uma view pode ser entendida com uma tabela
virtual, no qual se é criada por uma consulta. Isto acontece pois a
metodologia Agile ROLAP preza para que não se altere as tabelas
originais novos atributos são criados na view correspondente a
tabela original, acrescentando um novo campo, sendo este dado
por uma função que será responsável pela discretização dos dados.
Existem dois tipos de discretização de dados[3]:
 Discretização sem Supervisão: Discretização nãosupervisionada gera intervalos sem utilizar a informação da
classe, e é a única possibilidade na tarefa de agrupamento.
Esse tipo de discretização possui duas abordagens: largura
igual (divide a faixa dos atributos em um número de
intervalos especificados pelo usuário) e frequência igual
(tenta colocar o mesmo número de objetos em cada
intervalo).
 Discretização Supervisionada: Os intervalos são
determinados em função dos valores do atributo e da classe
correspondente a cada valor. Esse tipo possui vários
métodos, sendo um deles a entropia, sendo ela uma das mais
promissoras para discretização.
Os plugins já desenvolvidos para a metodologia Agile ROLAP,
foram implementados na ferramenta Pentaho Data Integration
(Kettle), sendo este uma plataforma de integração de dados, que
possibilita a análise de dados de forma precisa, além de permitir a
obtenção de dados de diversas fonte de dados e permite a
visualização por meio de componentes visuais [7]. Foi
desenvolvido um novo plugin pois necessitava de algo que não se
alterasse a tabela original e que pudesse fazer discretizações
utilizando vários atributos.
Na Figura 2 é apresentada uma interface que mostra o
funcionamento da ferramenta Kettle. Nesta interface, pode-se
observar como é realizado o processo de ETL de forma prática e
simples por meio de plugins que executam tarefas especificas,
sendo então possível a realização de transformações complexas
nos dados, no qual estes plugins tendem a convergir para um
único objetivo.
A discretização de dados consiste em uma das etapas do processo
de
Extract, Transform and Load (ETL). Como mencionado
acima, ela é realizada para que possa determinar um padrão das
informações.
Um exemplo de uso da discretização dos dados é identificar a
faixa etária das pessoas que alugam filmes em uma locadora.
Suponha-se que no sistema possua somente a idade da pessoa,
porém não consta a sua faixa etária, com isto é feita a
discretização dos dados, transformando a idade da pessoa em
categorias de idade, para que possam ser analisadas futuramente.
Por a ferramenta Kettle ser open source, existem diversos
plugins para as mais várias tarefas da ETL, inclusive que auxiliem
na discretização de dados. No entanto, pelas particularidades da
metodologia Agile ROLAP foi estabelecido que seria necessário o
desenvolvimento de um novo plugin, que pudesse ser totalmente
integrado à outros plugins já desenvolvidos para dar suporte à
metodologia.
Contudo, ao realizar uma discretização pode ser necessário a
transformação de atributos, no qual se refere a uma transformação
que seja aplicada a todos os valores de um atributo, que é
realizado “se a apenas a magnitude de um atributo for importante,
então os valores dos atributos podem ser transformados pegandose o valor absoluto” [3]. Por exemplo, se ao invés de ter
armazenado na base de dados a idade das pessoas e sim a data de
nascimento, antes de realizar a categorização dos dados, seria
necessário transformar a data de nascimento em um atributo
contínuo idade.
3.
DESENVOLVIMENTO DO PLUGIN
Com o intuito a dar suporte às necessidades do administrador de
empresas que visa consultar as fontes de dados de forma que os
dados estejam categorizados, e para que pudesse agilizar o
processo de implantação de um ambiente de BI utilizando a
metodologia Agile ROLAP, foi desenvolvido um plugin de
discretização de dados.
Figura 2. Pentaho Data Integration (Kettle). Fonte: Pentaho (2016 )
Sendo assim, o plugin de discretização de dados é apresentado na
Figura 3. Como mostrado, este contém alguns campos que devem
ser preenchidos para o funcionamento do mesmo. Existem sete
campos dentro do plugins que podem ser preenchidos, porém seis
deles são obrigatórios.
O plugin de discretização de dados foi elaborado para ser
integrado a outros plugins que dão suporte à metodologia Agile
ROLAP. Em uma das etapas desta metodologia é previsto que os
dados de diversas fontes de dados, sejam agrupados em uma única
base de dados, utilizando a tecnologia Foreign Data Wrapper
(FDW). Com isso, é feito um mapeamento das bases de dados
relacionais para uma base intermediária, sendo esta base criada
dentro do Sistema de Gerenciamento de Banco de Dados (SGBD)
PostgreSQL.
O primeiro campo é onde se dá o nome da view materializada
criada pelo plugin. O segundo campo obrigatório é “connection”,
responsável por fazer a conexão com o banco de dados, esta
conexão serve para pegar os atributos das tabelas e também
servirá para indicar onde será criada a view materealizada. O
terceiro campo obrigatório é o campo tabela, responsável por
identificar qual tabela receberá os dados discretizados.
23
O quarto campo é responsável por identificar qual tipo de função
será usada para discretização, sendo elas: função criadas pelo
usuário; funções próprias do banco e uma outra que é nova
função. Cada função tem um objetivo especifico para
discretização dos dados.
Com estes preliminares realizados, pode-se comprovar que o
plugin é útil para a discretização dos dados, fácil de ser utilizado e
o mesmo agiliza o processo de discretização dos dados, pois o
mesmo trabalha de forma intuitiva. Por fim, verificou-se que o
mesmo está totalmente de acordo com a metodologia Agile
ROLAP, que era um dos principais objetivos do plugin.
O quinto campo, obtém as funções já implementadas, porém este
campo só é liberado caso seja escolhida no campo “tipo de
função”, a opção diferente de “nova função”.
Como principal limitação, constou-se que para utilização do
plugin é necessário o entendimento do mecanismo de criação de
funções por meio de PL/SQL.
O sexto campo conterá atributos no qual a função receberá para
fazer a discretização de dados. Para cada atributo selecionado é
necessário clicar no botão “adicionar” para que o mesmo possa ser
vinculado a regra da função.
5.
CONSIDERAÇÕES FINAIS
Com a proposição da metodologia Agile ROLAP [2], muitos
desafios surgiram na sua implantação, principalmente por não
existir ferramentas específicas para este fim. Com o tempo, foi
sendo percebido, que novos plugins eram necessários para que a
metodologia se tornasse viável de ser implantada de forma fácil e
rápida, e assim atingir o seu principal objetivo. Dentre estes
plugins identificados como necessários, está o de discretização de
dados.
O sétimo e último campo, só irá aparecer caso, no campo “tipo de
função”, for selecionado o atributo “nova função”. Neste caso irá
ser exibido um novo campo, que dará a liberdade de se criar uma
nova função para discretização dos dados.
Após todos os campos serem preenchidos, é realizadas então a
discretização dos dados, criando então uma view materializada já
com o novo campo criado no qual se refere a discretização dos
dados.
Assim, foram estudadas as necessidades específicas que este
plugin deveria abordar, assim como este deveria ser integrado a
outros plugins já existentes. Com o uso do plugin desenvolvido,
verificou-se que, apesar de necessitar do entendimento do
mecanismo de criação de funções por meio de PL/SQL, para sua
utilização, os resultados foram satisfatórios, pois o mesmo agiliza
no processo de discretização de dados, já que o mesmo tem uma
interface intuitiva e simples de ser usada.
6.
AGRADECIMENTOS
Meu agradecimento ao órgão CNPq (Conselho Nacional de
Pesquisas) pela bolsa que me foi concebida.
7.
REFERÊNCIAS
[1] MACHADO, Felipe N. R. “Tecnologia e Projeto de Data
Warehouse: Uma visão multidimensional” São Paulo: Érica
2010 5 ed.
[2] SOUZA, E. B.; MENOLLI, André; COELHO, Ricardo
Gonçalves. 2014 Uma Metodologia Agile ROLAP para
Implantação de Ambientes de Inteligência de Negócios. Em:
X Escola Regional de Banco de Dados, São Francisco do
Sul. Anais 10ª. edição da ERBD.
Figura 3. Plugin de Discretização de Dados
4.
RESULTADOS
A fim de verificar se o plugin desenvolvido é viável para
discretização de dados e se adequa à metodologia Agile ROLAP,
foram realizados dois testes, utilizando uma base de dados
exemplo Postgres, chamada Pagila, pela qual foi inspirada pela
Dell DVD Store para elaboração da mesma.
[3] MENDES, Luciana 2011. Data Mining – Estudo de Técnicas
e Aplicações na Área Bancária in Faculdade De Tecnologia
De São PauloFATECPaulo FATEC-SP.
[4] KIMBALL, R., Caseta, J. 2004. The Data Warehouse ETL
Toolkit: Practical Techniques for Extracting, Cleaning,
Conforming, and Delivering Data, John Wiley & Sons.
Os testes foram feitos empregando a tabela “film” e utilizou o
atributo “length” para fazer a discretização. Este atributo foi
escolhido, pois contém a duração de cada filme e também por
estar na forma continua, tornando necessário a discretização
desses dados para que ele fique na forma categorizada. Definiramse as categorias como sendo: curta, média e longa metragem,
conforme encontrado na literatura.
[5] MENOLLI, André 2006. A Data Warehouse Architeture em
Layers for Science and Technology in Proceedings of the
Eighteenth International Conference on Software
Engineering Knowledge Engineering (SEKE'2006), San
Francisco, CA, USA.
No primeiro teste realizado, como não foi encontradas funções
que possam realizar a categorização específica de tamanho de
filmes, foi necessária a criação de uma nova função, no qual a
mesma foi elaborada no plugin.
[6] BUENO, Michel Ferreira. 2012. Mineração de Dados:
Aplicações, Eficiência e Usabilidade. Em Anais do
Congresso de Iniciação Científica do INATEL.
[7] PENTAHO. 2014 Pentaho Data Integration: Power to access,
prepare and blend all data. Pentaho Corporation Disponível
em: <http://www.pentaho.com/product/data-integration/> em
2014.
O segundo teste realizado, foi utilizando a mesma função criada
no teste anterior, porém neste caso, não foi executada a etapa de
criação da função, pois a mesma já se encontrava na lista de
funções criadas.
24
Análise de Usabilidade em Sistema de Resposta Audível
automatizada, com base no Percurso Cognitivo, Critérios
Ergonômicos de Bastien e Scapin e Heurísticas de Nielsen
Alternative title: Usability Analysis of Automated Voice Response
System based on Cognitive Walkthrough, Bastien and Scapin’s
Ergonomic Criteria Bastien Nielsen’s Heuristics
Aline Cristina Antoneli de Oliveira1
Maria José Baldessar2
Leonardo Roza Melo3
Priscila Basto Fagundes4
Programa de Pós Graduação em Engenharia e Gestão
do Conhecimento – PPEGC/UFSC 1 2
[email protected]
[email protected]
Faculdade de Tecnologia SENAI Florianópolis 3 4
[email protected]
[email protected]
RESUMO
General Terms
A presente pesquisa tem como objetivo realizar avaliação de
usabilidade de um sistema que realiza atendimento para uma
empresa de telefonia, que possui recursos de interface de resposta
audível. A técnica aplicada para navegação no sistema foi o
Percurso Cognitivo. A avaliação da usabilidade foi baseada em 13
princípios selecionados com base nos critérios ergonômicos
Bastien e Scapin e heurísticas de Nielsen. A partir da análise do
percurso cognitivo, foi gerada uma tabela de criticidade, onde foi
possível avaliar as heurísticas respeitadas e violadas. Espera-se que
as técnicas apresentadas evoluam para um modelo de avaliação de
usabilidade de URA’s (Unidades de Resposta Audível).
Design, Human Factors.
Keywords
System Interactive Voice Response,
Cognitive Walkthrough.
Heuristics Usability,
1. INTRODUÇÃO
Ao desenvolver uma interface homem-máquina (IHM), nem
sempre o projetista leva em conta certas diferenças que existem
entre as pessoas. Nem todos os humanos são iguais e as diferenças
podem implicar em problemas tanto para o projetista como para
quem vai usar as interfaces [3].
Palavras-Chave
Sistema de Resposta Audível, Heurísticas de Usabilidade, Percurso
Cognitivo.
Problemas de interpretação podem atrapalhar ou impedir que
pessoas de diferentes particularidades executem tarefas simples ao
utilizar diversos tipos de interface. Pretende-se, neste trabalho,
avaliar o contexto das interfaces de resposta audível. As maiores
dificuldades encontradas por usuários neste tipo de interface são o
acompanhamento da informação, identificação de posição das
teclas e botões, navegação entre menus, dificuldades de adaptação
em novas ações, compreensão do áudio, entre outras.
ABSTRACT
This research aims to perform usability evaluation of a system that
performs service for a telephone company, which has voice
response interface features. The technique applied to navigation
system was the Cognitive Walkthrough. The evaluation of the
usability was based on 13 principles selected, which were based on
ergonomic criteria of Bastien and Scapin, and Nielsen’s heuristics.
From the cognitive walkthrough analysis, it generates a criticality
table, where it was possible to evaluate the respected and violated
heuristics. It is expected that the presented techniques evolve for
usability evaluation model for IVR’s (Interactive Voice Response)
systems.
A partir destas dificuldades, resolveu-se estudar melhorias de
usabilidade nesse segmento com a finalidade de facilitar o
entendimento dos usuários na utilização de interfaces de resposta
audível e facilitar a interatividade entre o homem e o sistema.
O presente trabalho objetiva, portanto, realizar avaliação de
usabilidade em um sistema que realiza atendimento para uma
empresa de telefonia, que conta com recursos de interface de
resposta audível. A avaliação será realizada com base na técnica do
Percurso Cognitivo[2], nos critérios ergonômicos de Bastien e
Scapin [1] e Heurísticas de Nielsen [10] [11] [12].
D.2.2 [Software Engineering]: Design tools and techniques – user
interfaces.
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise,
or republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee.
Copyright SBC 2016.
A utilização da técnica do Percurso Cognitivo juntamente com
Avaliações Heurísticas, normalmente são utilizadas para avaliação
de interfaces web, onde a interação é realizada basicamente através
de teclado [6] [7] [8]. Este trabalho, portanto, trouxe uma nova
perspectiva de utilização destas técnicas, aplicando-as em URA’s
(Unidades de Resposta Audível). A principal contribuição é trazer
à discussão a avaliação de usabilidade em interfaces de resposta
25
audível. Alguns autores já realizaram pesquisas sobre a importância
de aplicação de métodos de avaliação de usabilidade, que
fundamentalmente foram desenvolvidos para navegação através de
teclado, em sistemas multimodais (onde há múltiplas interações
simultâneas de dados e voz) [10], e softwares leitores de tela [13].
As técnicas apresentadas também já foram aplicadas em avaliação
de usabilidade sistemas web [7]. Porém, este trabalho apresenta
estas técnicas em sistemas onde o usuário, através de um aparelho
telefônico, liga para um número e interage com um sistema de
resposta audível, e através das técnicas apresentadas, heurísticas de
usabilidade são avaliadas, o que o torna relevante devido ao fato
deste conjunto de métodos ainda não haver sido aplicado em
interfaces desse tipo.
3. TESTE DE PERCURSO COGNITIVO
O percurso cognitivo é um método de inspeção, realizado por
especialistas, sem a participação de usuários. O Método de
Percurso Cognitivo foi proposto em 1994 por Wharton, Rieman,
Lewis e Polson [2]. Seu principal objetivo é avaliar a facilidade de
aprendizado de um sistema interativo, através da exploração da sua
interface. Considera principalmente a correspondência entre o
modelo conceitual dos usuários e a imagem do sistema, no que
tange à conceitualização da tarefa, ao vocabulário utilizado e à
resposta do sistema a cada ação realizada [2]. Objetiva encontrar
problemas de usabilidade relacionados à aprendizagem dos passos
necessários para realizar as tarefas [8]. Permite que os especialistas
simulem o percurso das tarefas realizadas pelos usuários,
verificando se a cada passo o usuário conseguiria alcançar o
objetivo correto, evoluindo na interação com a interface [8].
A Seção 02 trata dos aspectos conceituais sobre URA. A Seção 3
traz a respeito da Interação Humano Computador, conceitos sobre
Multimodalidade e URA Multimodal. A Seção 4 apresenta os
procedimentos e métodos adotados para que fosse realizada a
avaliação de usabilidade na interface multimodal apresentada. A
seção 5 apresenta os resultados da avaliação realizada, trazendo o
resultado do percurso cognitivo, assim como a Tabela de
Criticidade, onde são realizadas sugestões de melhorias na interface
analisada. A Seção 6 apresenta uma reflexão sobre o que foi
realizado, assim como sugestões para a continuação deste trabalho.
A aplicação da técnica consiste em:
a) definir quem são os usuários da interface, analisando suas
características e comportamentos.
b) definir as tarefas típicas que serão analisadas.
c) definir a sequência de ações para a realização correta de
cada tarefa.
c) definir a interface a ser analisada, que é a descrição de
informações necessárias para que as tarefas sejam realizadas, como
requisitos e regras funcionais [8].
2. INTERAÇÃO HUMANO-COMPUTADOR
(IHC) e UNIDADE DE RESPOSTA AUDÍVEL
(URA)
4. PROCEDIMENTOS E MÉTODOS
A URA é um sistema automatizado de atendimento ao usuário
muito utilizado por empresas de maior porte e de grande
comunicação via telefone. Com ela é possível atender ligações e
gerenciá-las em modo espera ou então transferi-las de acordo com
a especificação que o usuário disca no teclado do telefone. Para o
usuário, não é um sistema muito agradável, pois se vê obrigado a
interagir com uma espécie de robô. Já para as empresas, as URA’s
são de grande utilidade, visto que elas substituem pessoas,
redirecionam melhor as ligações sabendo exatamente para qual
setor encaminhar as mesmas e podem funcionar 24 horas por dia e
7 dias por semana, sem interrupções [10][15].
Para realizar as avaliações de usabilidade em interface de resposta
audível, utilizou-se a técnica do percurso cognitivo [2] juntamente
com as heurísticas de usabilidade de Nielsen [12] e os critérios
ergonômicos de Bastien e Scapin [1]. Para isso, foi selecionado um
sistema de resposta audível de uma empresa de telefonia. O critério
para a escolha do sistema foi feita com base na experiência do
pesquisador como usuário desta interface e cliente da referida
empresa. Necessário é mencionar que a experiência do especialista
no momento da utilização da interface é importante para a avaliação
do método a ser utilizado, pois como especialista ele precisa antever
os possíveis passos que os usuários realizarão para navegar pela
interface.
As interfaces de interação com computadores tem sido alvo de
diversas pesquisas nas últimas décadas. A IHC é a área responsável
pelo design, avaliação e implementação de sistemas
computacionais interativos para uso humano. Propicia o
desenvolvimento de sistemas mais amigáveis e úteis, provendo aos
usuários melhores experiências [17]. Procura também apoiar o
estudo de interfaces adaptativas e adaptáveis, objetivando melhores
maneiras de interação.
A presente pesquisa, classificada como qualitativa [5] [16], tem em
sua característica interpretativista [9], a visão de mundo do
pesquisador. Este fato foi levado em consideração na escolha do
sistema avaliado e mesmo que tenha sido com base em sua
experiência pessoal como usuário do sistema e cliente da empresa,
não influenciou nos resultados alcançados.
Alguns autores dizem que o ideal é que interfaces sejam o mais
minimalista possível, para que a operação do equipamento seja
possível com a menor necessidade de habilidade ou conhecimento
prévio. Deve ser intuitiva para qualquer pessoa, invisível, passando
despercebida [10].
4.1 Aplicação do teste de Percurso Cognitivo
Para a aplicação do teste de percurso cognitivo foi criado um
cenário e proposta uma tarefa, que é ligar para a empresa telefonia,
que aqui será denominada X. O avaliador é o especialista.
A relação entre um dispositivo de entrada ou saída (microfone,
teclado, tela sensível ao toque) e uma linguagem de interação
(linguagem natural, manipulação direta) é chamada modalidade.
Consequentemente, a interação multimodal pode ser definida como
a utilização de duas ou mais modalidades para interagir com um
sistema [14].
5.1.1 Cenário
O usuário está enfrentando problemas de navegação e seu provedor
de Internet é a empresa X. Ele já é cliente da empresa há muito
26
tempo, todas as configurações do aparelho estão corretas, porém
existe um problema de navegação na Internet. Ele deve ligar para a
central de atendimento e tentar resolver o problema de navegação.
Para a avaliação do sistema escolhido, foram utilizadas 13
recomendações, sendo que 07 (sete) delas foram escolhidas com
base nos 10 princípios de Jakob Nielsen [12], e 06 (seis) nos
critérios ergonômicos de Scapin e Bastien [1]. O critério utilizado
para a escolha destas recomendações é que, através de estudos do
pesquisador, as recomendações escolhidas são as mais adequadas
ao cenário da utilização do sistema de resposta audível. As
recomendações são:
5.1.2 Tarefa
Ligar para a empresa X para tentar resolver um problema de
conexão com a Internet.
H1. Visibilidade do status do sistema [12] - O sistema deve
informar aos usuários sobre o que está acontecendo, através de
feedback disparados a cada interação ou a cada escolha de opção.
5.1.3 Sequência de ações
H2. Correspondência entre o sistema e o mundo real [12] - O
sistema deve ter uma linguagem clara com os usuários. Com
palavras, frases e conceitos comuns ao usuário.
Passo 1 – Aguardar a URA informar qual é a opção referente ao
seu problema. Neste caso, o usuário não deve escolher nenhuma
opção e deixar a URA conduzir a ligação para a próxima etapa. A
URA informa que se o usuário quiser atendimento para outro
número, ele deve pressionar asterisco (*) em qualquer momento da
ligação.
H3. Controle do usuário e liberdade [12] - Os usuários
eventualmente escolhem algumas funções do sistema por engano e
deverão precisar de uma “saída de emergência” clara e distinta para
sair daquela opção indesejada.
Passo 2 – Neste passo, o usuário também não deve escolher
nenhuma opção, pois a URA o conduz para a próxima etapa para
resolver o problema. A URA informa que o usuário receberá um
torpedo com o protocolo inicial do atendimento e dá a opção do
usuário de digitar “1” para receber o protocolo naquele momento
ou que ele poderia aguardar em ligação para continuar.
H4. Prevenção de erros [12] - Prevenção de erros significa
permitir que os erros não aconteçam.
H5. Reconhecimento em vez de recordação [12] - O usuário não
precisa ter que lembrar da informação anterior para passar para a
próxima etapa.
problema do usuário. Neste caso, o usuário deve escolher a opção
“5”, que trata de como fazer, receber chamadas e acessar a Internet.
H6. Flexibilidade e eficiência de utilização [12] - O sistema deve
atender a ambos os usuários, inexperientes e experientes. Permitir
que os usuários possam personalizar ações mais frequentes.
seu problema. Neste caso, o usuário escolher a opção “1”, “Se não
consegue acessar a Internet, digite 1”.
H7. Estética e design minimalista [12] - Os diálogos não devem
conter informações desnecessárias ou raramente utilizadas, pois
irão competir com diálogos mais usuais confundindo ou poluindo a
visibilidade.
seu problema. Neste caso, escolher a opção 2 “Se você já
configurou e ainda permanece com dificuldades para acesso à
Internet, digite ‘2’”.
H8. Condução/convite [1] - O objetivo é conduzir o usuário a um
caminho correto na utilização do sistema.
H9. Condução/agrupamento e distinção de itens/agrupamento
e distinção por localização [1] - Proporciona mais facilidade a
todos os tipos de usuário, trata da organização dos itens de
informação levando em conta a relação que estes itens guardam
entre si.
5.1.4 Questões aplicadas à execução do percurso
As questões aplicadas serão as seguintes:
H10. Condução/Feedback imediato [1] - Feedback é um retorno
imediato que o sistema deve oferecer após as ações executadas
pelos usuários.
I. Os usuários farão a ação correta para atingir o resultado
desejado?
II. O usuário perceberá que a ação correta está disponível?
H11. Carga de trabalho/Brevidade/ações mínimas [1] Minimiza e simplifica um conjunto de ações necessárias para o
usuário alcançar seu objetivo.
III. O usuário associará o elemento de interface correto à meta
a ser atingida?
IV. Se a ação correta é tomada, o usuário perceberá que
progrediu em direção à solução da tarefa?
H12. Controle explícito/Controle do usuário [1] - Cabe ao
sistema deixar o usuário no controle dos processos, dando a
liberdade de cancelamento, reinício, retomada, interrupção ou a
finalização.
4.2 Análise heurística
H13. Gestão de erros/Correção de erros [1] - Permitir a correção
de seus erros, o sistema deve oferecer meios que permitam que o
usuário corrija os erros de forma fácil e amigável.
Análise heurística é uma técnica de inspeção feita por especialistas,
que tomam como base princípios e orientações práticas de
usabilidade. Segundo o mesmo autor, o objetivo é identificar os
problemas de usabilidade existentes nas interfaces, através da
rigorosa aplicação desses princípios durante o processo de análise
[7].
Os problemas encontrados foram classificados em 3 graus de
criticidade: alta, média e baixa. Essa classificação tem o objetivo
de identificar quais são os problemas mais graves, que impedem a
interação do usuário com a interface; quais são medianos, que tem
grande chance de causar problemas na interação; e quais são leves,
que eventualmente podem causar problemas de interação. Os graus
27
de criticidade são proporcionais à prioridade com que os problemas
devem ser solucionados. Problemas de criticidade alta devem ser
resolvidos em curto prazo; problemas médios têm prioridade média
de resolução; e problemas de criticidade baixa podem ser
solucionados em longo prazo.
5.2 Análise Heurística
A análise heurística foi feita nos passos onde se passam as quatro
perguntas analisadas no percurso cognitivo. Foi criada uma legenda
para identificar cada heurística e apresentado na Tabela 02.
A tabela de criticidade é onde estão cruzadas todas as informações
levantadas no percurso cognitivo, quais princípios e heurísticas as
etapas desrespeitam, e o grau de criticidade que irá informar qual é
a prioridade na manutenção do produto e ainda indica as
recomendações cabíveis para cada problema.
5 RESULTADOS E DISCUSSÕES
Após realizadas as tarefas, foi feito o cruzamento das informações
entre as questões do percurso cognitivo e os passos da tarefa
executada, onde foi avaliado se a etapa do sistema está de acordo
com os critérios de usabilidade escolhidos. Foi definido três tipos
de resposta para as questões: "Sim", "Sim, porém" e "Não”.
Passo 1
Questão II
Tabela 01 – Resultado do percurso cognitivo
Passo 01
Passo 02
Questão I – Sim
Questão I – Sim
Questão II - Sim, porém a opção a ser
escolhida não é informada pela URA, pois
ela deixa a opção “oculta”. O usuário deve
aguardar e não digitar. A URA, porém,
não informa isto ao usuário.
Questão II – Sim
Questão III – Não
Passo 2
Questão
III
Questão III - Sim, porém somente
usuários
mais
experientes
compreenderão o que está sendo
solicitado.
Passo 3
Questão I
e II
Questão IV – Sim
A opção a ser escolhida não
é informada pela URA,
pois ela deixa opção
"oculta", nesse caso a
opção é "aguardar sem
digitar nada" e a URA não
informa desta forma,
entretanto, somente o
usuário mais experiente
consegue entender isso
Nesse caso a URA está
falando sobre torpedo com
protocolo e não sobre o
suporte que está sendo
buscado o que dificulta no
entendimento da tarefa
O usuário deve aguardar
vários segundos até a URA
informar outros dados e
chegar na opção desejada
H1,
H2,
H6,
H7,
H8,
H10
Informar a
opção a ser
escolhida, não
deixá-la oculta
e acrescentar
feedback
Média
H2,
H6,
H7,
H8,
H9,
H10
H1,
H7,
H8,
H9
Retirar a
mensagem
sobre torpedo
Média
Média
Essa opção está junto com
outra na mesma escolha e
acaba confundindo o
usuário
A falta do feedback do
sistema deixa o usuário na
dúvida, ela não informa que
avançou para a próxima
etapa
H6,
H7,
H9
Informar a
opção a ser
escolhida,
diminuir o
tempo de
resposta
Separar as
opções
Acrescentar
feedback
Média
Questão IV – Sim
Passo 03
Passo 04
Questão I - Sim, porém a URA informa
dados sobre conta e usuário deve aguardar
até informar a opção desejada.
Questão II - Sim, porém o usuário deve
aguardar vários segundos até a URA
informar outros dados e chegar na opção
desejada.
Questão III – Não
Passo 3
Questão
IV
Questão I – Sim
Questão II – Sim
Passo 4
Questão
IV
Questão III – Sim
Questão IV - Sim, porém a falta
de feedback do sistema deixa o
usuário na dúvida, não informando
que o usuário avançou para a
próxima etapa.
Passo 05
Questão II – Sim
Questão III – Sim
Média
No Passo 1, Questão II e Passo 2, Questão III, praticamente os
mesmos princípios foram violados. Elas iniciam com a opção do
menu a ser escolhida não sendo informada pela URA, deixando
opção "oculta". Neste caso a opção é "aguardar sem digitar nada" e
a URA não deixa esta informação explícita. Somente o usuário mais
experiente consegue compreender que deve aguardar, o que
dificulta no entendimento da tarefa fazendo com que a interface
desrespeite a heurística H1, “Visibilidade do status do sistema”.
Desrespeitou também a heurística H2, “Correspondência entre o
sistema e o mundo real”, onde o sistema deve ter uma linguagem
clara com os usuários. Com palavras, frases e conceitos comuns ao
usuário. A heurística H6, “Flexibilidade e eficiência de utilização”
também foi desrespeitada, pois o sistema deve atender a ambos os
usuários, inexperientes e experientes. O princípio H7, “Estética e
design minimalista” foi desrespeitado, pois os diálogos não devem
conter informações desnecessárias ou raramente utilizadas. O
princípio H8, “Condução/convite” foi desrespeitado, pois a URA
deveria conduzir o usuário a um caminho correto na utilização do
sistema e o princípio H10, “Condução/Feedback imediato” foi
Questão IV - Sim, porém essa opção está
junto com outra função na mesma opção,
o que confunde o usuário.
Questão I – Sim
H1,
H6,
H10
Criticidade
Recomendações
A tarefa consistiu em ligar para a empresa X para resolver um
problema de conexão com a Internet. A tabela 1 apresenta os
resultados dos passos realizados pelo especialista ao utilizar a
interface multimodal, relacionando os passos apresentados em
5.1.3 e às questões do percurso cognitivo apresentadas em 5.1.4.
Problema
ID
5.1 Análise do percurso cognitivo
Heurísticas
Desrespeitadas
Tabela 2 – Tabela de Criticidade
Questão IV - Sim
Analisando a Tabela 01, percebe-se que no cruzamento das
respostas fornecidas, a avaliação do percurso identificou 12
respostas “Sim”, 6 respostas “Sim, porém” e 2 respostas “Não”.
Através desta análise, pode-se concluir que a tarefa proposta neste
sistema possui 60% das etapas para chegar ao objetivo estão claras
para o usuário.
Várias heurísticas dentre as levantadas em 5.2 foram
desrespeitadas. No próximo tópico, será possível verificar as
heurísticas e as recomendações para melhoria na navegabilidade da
URA analisada.
28
desrespeitado, pois a URA deveria fornecer um retorno imediato
após as ações executadas pelos usuários.
permitiu apresentar os testes realizados somente em um sistema de
telefonia, porém é interessante mencionar que os autores aplicaram
esta técnica também a outros sistemas de resposta audível, obtendo
resultados semelhantes, trazendo a possibilidade de validar as
técnicas como um futuro modelo.
No Passo 3, Questão I e II, a URA informa dados sobre conta e
usuário e demora alguns segundos para apresentar as opções
esperadas o que dificulta no entendimento da tarefa fazendo com
que a interface desrespeite o princípio H1, “Visibilidade do status
do sistema” e H7, “Estética e design minimalista”, onde os diálogos
não devem conter informações desnecessárias ou raramente
utilizadas.
Desrespeitou
também
o
princípio
H8,
“Condução/convite”, onde o objetivo é conduzir o usuário a um
caminho correto na utilização do sistema e o princípio H9,
“Condução/agrupamento e distinção de itens/agrupamento e
distinção por localização”. Desrespeitou o princípio H10,
“Condução/Feedback imediato”, onde o feedback é um retorno
pelos usuários.
As técnicas apresentadas, portanto, possuem potencial para evoluir
para um modelo de avaliação de usabilidade em sistemas de
interface de resposta audível. Sugere-se englobar testes de
usabilidade que envolvam usuários reais dos sistemas, não somente
especialistas. Seria interessante também que um conjunto de
especialistas apliquem o modelo proposto em outras interfaces
multimodais que envolvam URA’s, para que se verifique, com
outras pesquisas, a eficácia de um futuro modelo.
7. REFERÊNCIAS
No Passo 3, Questão IV, essa opção está junto com outra na
mesma escolha e acaba confundindo o usuário, o que dificulta no
entendimento da tarefa fazendo com que a interface desrespeite o
princípio H6, “Flexibilidade e eficiência de utilização”.
Desrespeita também o princípio H7, “Estética e design
minimalista”, onde os diálogos não devem conter informações
desnecessárias ou raramente utilizadas, pois irão competir com
diálogos mais usuais confundindo ou poluindo a audibilidade.
Desrespeitou o princípio H9, “Condução/agrupamento e distinção
de itens/agrupamento e distinção por localização”.
[1] Bastien, C., and Scapin, D. Ergonomic Criteria for the
Evaluation of Human Computer Interfaces. INRIA (1993).
[2] Cathleen Wharton, John Rieman, Clayton Lewis, and Peter
Polson. The cognitive walkthrough method: a practitioner's guide.
In Usability inspection methods, Jakob Nielsen and Robert L.
Mack (Eds.). John Wiley & Sons, Inc., New York, NY, USA,
(1994) 105-140.
[3] Cordeiro, Renato, and Oliveira, Marcos Roberto, and
Chanquini, Thaís Pereira. Utilização de conceitos de interface
homem-máquina para adaptação da disciplina de requisitos do
RUP. São Paulo: Laboratório de Pesquisa em Ciência de Serviços.
Centro Paula Souza, (2009).
No Passo 4, Questão IV, a falta do feedback do sistema deixa o
usuário na dúvida, não deixando claro que a navegação avançou
para a próxima etapa. Desrespeitou, portanto o princípio H1,
“Visibilidade do status do sistema”, onde o sistema deve informar
aos usuários sobre o que está acontecendo, através de feedback
disparados a cada interação ou a cada escolha de opção.
Desrespeitou o princípio H6, “Flexibilidade e eficiência de
utilização”, onde o sistema deve atender a ambos os usuários,
inexperientes e experientes. Desrespeitou o princípio H10,
“Condução/Feedback imediato”, onde o feedback é um retorno
pelos usuários.
[4] Costa, José Fabiano da Serra, and Felipe, Ada Priscila
Machado, and Rodrigues, Monique de Menezes. Avaliação da
escolha de unidade de resposta audível (URA) através do Método
de Análise Hierárquica (AHP). In: Revista GEPROS,
Departamento de Engenharia de Produção da Faculdade de
Engenharia da UNESP, Bauru/SP, year 3, n. 3, (2008) 147-161
[5] Creswell, J. W. Projeto de pesquisa: Métodos qualitativo,
quantitativo e misto. 3. ed. Porto Alegre: Artmed, 2010. p. 177205.
[6] Leite, S. F. C. (2013). Inspeção de usabilidade aplicada a
métodos ágeis: um estudo de caso. Monografia de Bacharelado.
Universidade Federal de Lavras-MG.
http://repositorio.ufla.br/bitstream/1/5484/1/MONOGRAFIA_Ins
pecao_de_usabilidade_aplicada_a_metodos_ageis_um_estudo_de
_caso.pdf
A presente pesquisa teve o objetivo de realizar avaliação de
usabilidade em um sistema de telefonia, que conta com recursos de
interface de resposta audível. Foram escolhidos 13 critérios
selecionados a partir dos Critérios Ergonômicos de Bastien e
Scapin e as Heurísticas de Nielsen para a avaliação que se
enquadram nesse tipo de sistema.
[7] Loureiro, Eduardo. Inspeção de usabilidade. Centro
Universitário de Belo Horizonte, Uni-BH, (2007). Disponível em:
<http://eduardoloureiro.com/EduardoLoureiro_InspecaoUsabilida
de_Relatorio.pdf>. Acesso em: 06 out. 2015.
O resultado esperado deste trabalho é que, através da estrutura
proposta, possa se consolidar um modelo que é capaz de realizar
avaliações de usabilidade de interfaces de resposta de voz que
podem ser monomodal ou multimodal. A ausência de trabalhos que
especificamente lidam com avaliações de usabilidade em URA’s
justificam a relevância do trabalho proposto.
[8] Magrinelli, J. V. B. (2010). Avaliação de usabilidade de
sistema para gerenciamento apícola: o caso laborapix. Monografia
de Bacharelado. Universidade Federal de Lavras-MG.
http://repositorio.ufla.br/bitstream/1/5313/1/MONOGRAFIA_Ava
liacao_de_usabilidade_de_sistema_para_gerenciamento_apicola_
o_caso_laborapix.pdf
Propomos que as técnicas possam ser aplicadas em outros sistemas,
monomodais ou multimodais, usando vários dispositivos de
interação simultâneas, tais como voz e teclado. Nós mostramos
neste trabalho a interação em um sistema de telefonia, mas muitos
outros tipos de serviços atualmente também utilizam interação
simultânea para servir os seus clientes, por exemplo, empresas de
cartões de crédito, operadoras móveis etc. O escopo deste trabalho
29
[9] Morgan, G. (1980). Paradigms, metaphors, and puzzle solving
in organization theory. Administrative science quarterly, 605-622.
[14] Santos, M. A. D. (2013). Interface multimodal de interação
humano-computador em sistema de recuperação de informação
baseado em voz e texto em português.
http://repositorio.unb.br/bitstream/10482/14843/1/2013_Marcelo
AlvesdosSantos.pdf
[10] Nielsen, J., and Molich, R. Heuristic evaluation of user
interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1-5 April),
(1990) 249-256.
[11] Nielsen, J. Enhancing the explanatory power of usability
heuristics. (1994a). Proc. ACM CHI'94 Conf. (Boston, MA, April
24-28), 152-158.
[15] Torezan, Eduardo Luiz Dalpiaz. Implementação de funções
avançadas em um gateway voip. 56 f. Trabalho de Conclusão de
Curso (Graduação) - Curso de Engenharia de Telecomunicações,
Universidade Regional de Blumenau - FURB, Blumenau, (2006).
[12] Nielsen, J.. Heuristic evaluation. In Nielsen, J., and Mack,
R.L. (Eds.). (1994b) Usability Inspection Methods, John Wiley &
Sons, New York, NY).
[16] Triviños, Augusto N.S. Introdução á pesquisa em ciências
sociais: a pesquisa qualitativa em educação. São Paulo: Atlas,
1987.
[13] Paes, D. M. C. (2015). Análise de problemas de
funcionalidade e usabilidade no processo de desenvolvimento do
software leitor de telas livre NVDA. Disponível em:
http://repositorio.ufla.br/bitstream/1/10743/1/TCC_An%C3%A1li
se_de_problemas_de_funcionalidade_e_usabilidade_no_processo
_de_desenvolvimento_do_software_leitor_de_telas_livre_nvda.pd
f
[17] Zuasnábar, D. H.; Cunha, A. M. da; Germano, J. S. 2003. Um
ambiente de aprendizagem via WWW Baseado em Interfaces
Inteligentes para o Ensino de Engenharia. In: COBENGE 2003,
Rio de Janeiro. Anais. Rio de Janeiro.
30
Guia de Boas Práticas para Desenvolvimento de Interface
e Interação para Desenvolvedores da Plataforma Android
Alternative Title: Good Practice Guide to Development of Interface
and Interaction for developers of the Android Platform
Guaratã Alencar Ferreira de Lima Junior
Rodrigo Cezario da Silva
Faculdade AVANTIS
Curso de Sistemas de Informação
Balneário Camboriú, SC, Brasil
Faculdade AVANTIS
Curso de Sistemas de Informação
Balneário Camboriú, SC, Brasil
[email protected]
[email protected]
RESUMO
Keywords
Alguns estudos apontam que a preocupação no desenvolvimento de
interfaces contribui para o sucesso de um projeto de softwares para
dispositivos móveis. Neste sentido, a Apple detém um processo
rigoroso para aprovação das aplicações desenvolvidas por terceiros
para seus dispositivos em sua loja. Em contraponto ao que acontece
na Apple, os aplicativos desenvolvidos para sua loja de aplicativos,
não passam por nenhum processo de aprovação. No entanto,
mesmo com a publicação das diretrizes de projeto “Android
Design”, as mesmas são tratadas pela maioria dos desenvolvedores
como conselhos a serem seguidos, não como obrigações a serem
cumpridas como são tratados os aspectos de design e interação do
guia da Apple. Neste sentido, este trabalho apresenta um guia
apoiado em boas práticas relacionadas a elementos de interface e
de interação aplicadas na plataforma da Apple para
desenvolvedores da plataforma Android. O objetivo é reunir a
essência do guia da Apple sem perder as características do Android.
Interface. UI Design. Android Design.
1. INTRODUÇÃO
Em um mundo em que a tecnologia está cada vez mais presente na
vida das pessoas, seja em casa, em carros, nas ruas, e até mesmo
em nossa própria mão, podem ser citados diversos dispositivos,
como tablets, vídeo games, televisores e os smartphones que vem
se popularizando cada vez mais. Só em 2013, o envio de
smartphones pelo mundo chegou a um bilhão. Os aparelhos mais
procurados são os com telas grandes e os de baixo custo [1].
Através dos smartphones vem 80% dos acessos à internet, segundo
a [2], e do tempo total gasto nos smartphones, 89% são em
aplicativos. O uso de aplicações por usuários de smartphones pode
ser bem variado, segundo [3], boa parte usa para jogos, notícias,
mapas e navegação, redes sociais, música, entretenimento,
operações bancárias e outros. O mercado de aplicativos cresce no
mundo a cada ano com mais de 1,8 milhão de Apps disponíveis aos
usuários segundo [4].
Palavras-Chave
Alguns estudos [5][6][7] apontam que a preocupação no
desenvolvimento de interfaces contribui para o sucesso de um
projeto de softwares para dispositivos móveis. No entanto, também
é sabido que desenvolvedores de software normalmente não têm o
conhecimento aprofundado sobre diversos aspectos de elaboração
de interface de usuário, a citar: usabilidade, ergonomia,
acessibilidade e demais conceitos de design centrado no usuário
[8]. Por sua vez, a Apple [9] detém um processo rigoroso para
aprovação das aplicações desenvolvidas por terceiros para seus
dispositivos em sua App Store. Segundo [9], o processo de
aprovação de aplicações na App Store existe para que a empresa
possa manter o status de qualidade conquistada junta aos seus
clientes. Neste sentido, a Apple [9] disponibiliza aos seus
desenvolvedores um guia chamado de “iOS Human Interface
Guidelines”. Neste guia são apresentados conceitos básicos de UI
Design, estratégias de design, tecnologias do Sistema iOS,
elementos de UI, entre outros. Cabe salientar que para que uma
aplicação seja aprovada no processo para ser comercializado na
App Store, é necessário que este passe por uma avaliação inicial em
relação ao cumprimento das recomendações presentes no guia de
interface da Apple, sendo que as principais causas de rejeições de
aplicações na App Store sejam devidas à violação as diretrizes
contidas no guia [10][11]. Também neste sentido, a Google [12]
apresenta um guia chamado de “Android Design”, que trata de
princípios básicos de design, materiais para design, dispositivos,
estilos, padrões, entre outros. Em contraponto do que acontece na
Apple, os aplicativos desenvolvidos para Play Store não passam por
ABSTRACT
Some studies indicate that the concern in the development of
interfaces contributes to the success of a software project for mobile
devices. In this sense, Apple has a rigorous process for the approval
of third-party applications for their devices in your store. In contrast
to what happens at Apple, applications developed for its application
store, do not go through any approval process. However, even with
the publication of design guidelines "Android Design", they are
treated by most developers as advice to be followed, not as
obligations to be fulfilled as the aspects of design and interaction of
the Apple Guide are treated. Thus, this work presents a guide
supported on good practices related to interface elements and
interaction applied to the Apple platform Android platform
developers. The goal is to gather the essence of Apple's tab without
losing the Android features.
D.2.m [Software Engineering]: Miscellaneous
General Terms
Copyright SBC 2016.
31
nenhum processo de aprovação. Sendo assim, o guia da Google não
é imposto como obrigação em relação às observações nela feita
para o desenvolvimento de interface do usuário [13]. No entanto,
mesmo com a publicação das diretrizes de projeto “Android
Design”, as mesmas são tratadas pela maioria dos desenvolvedores
como conselhos a serem seguidos, não como obrigações a serem
cumpridas como são tratados os aspectos de design e interação do
guia da Apple [14]. Para [15], a postura da Google em cumprimento
das recomendações da guideline permite “liberdade de
criatividade”, sendo que um desenvolvedor pode optar em ignorar
completamente as diretrizes e criar o seu próprio design. [14]
contribui em destacar que a Google ainda carece de uma linguagem
de design focada na interface e interação do usuário. Para [14], a
guideline carece de sentido, coerência e uniformidade nos
elementos de interface do usuário. Além de haver relatos de que os
aplicativos disponibilizados na App Store apresentam maior
qualidade nas suas interfaces em relação os aplicativos da Google
Play [16]. Como resposta a esses problemas, existem propostas para
melhorias como a utilização de padrões de projetos [17][18],
interfaces adaptativas [19] e heurísticas [20][7]. No entanto,
diversos problemas ainda estão relacionados aos aspectos de
interface e interação com o usuário. Neste sentido, este trabalho
apresenta um guia apoiado em boas práticas relacionadas a
elementos de interface e de interação aplicadas na plataforma da
Apple para desenvolvedores da plataforma Android. Este trabalho
está estruturado na seguinte forma: na Seção 2, é apresentada a
fundamentação teórica. A seção 3, apresentada a metodologia de
pesquisa utilizada. Na Seção 4 é apresentada os resultados, sendo
este um Guia com boas práticas para desenvolvedores da
plataforma Android. E por fim, a Seção 5 apresenta as conclusões.
2.2 Interações com o usuário de dispositivos
móveis
Também chamado de design de interações, de acordo com [22], é
um item que tem um foco maior no usuário, e em como será seu
comportamento a partir do momento em que ele abre a aplicação.
São utilizados elementos da interface, como botões, tipografia,
efeitos sonoros, ícones e cores para o usuário interagir com estes e
manipular o conteúdo da aplicação. Uma aplicação móvel com uma
boa interface deve ter uma boa interação do usuário com a tela, para
que o mesmo possa fazer suas tarefas da melhor forma possível. A
interface é onde o conteúdo que o usuário está buscando é exibido,
mas é através de ferramentas ou dispositivos que o usuário precisa
interagir com o conteúdo que está sendo exibido na interface. No
caso de computadores, essa interação ocorre através do mouse e do
teclado com o conteúdo que é exibido em um monitor. Em
dispositivos móveis, na maioria deles existe apenas uma tela, que
não é usada somente para a exibição do conteúdo, mas também para
a interação do usuário com o mesmo. O que faz com que
desenvolvedores considerem ergonomia, gestos, transições e
específicos padrões de interações de cada plataforma.
2.3 Características da plataforma de
dispositivos móveis
Os dispositivos móveis têm suas características que podem ser
distintas dependendo da plataforma, no entanto algumas
características são similares. A plataforma iOS tem algumas
características únicas, devido a Apple ser rígida quanto a avaliação
de aplicativos antes de serem publicados, estes seguem um padrão
e qualidade, proporcionando uma ótima experiência ao usuário
[23]. Algumas características são similares às duas plataformas,
como modo de orientação da tela, transições entre telas e
aplicativos, e para a interação dos usuários com os aplicativos
existem gestos, ao invés de cliques.
2. FUNDAMENTAÇÃO TEÓRICA
Esta seção apresenta as referências nas quais se norteia este
trabalho. Parte-se da reflexão sobre a importância de um bom
design de interface; Interações com o usuário de dispositivos
móveis; e, conclui-se com as características da plataforma de
dispositivos móveis.
Este trabalho quanto aos objetivos pode ser enquadrado como uma
pesquisa exploratória. Quanto aos procedimentos técnicos, foi
utilizado a pesquisa bibliográfica e pesquisa documental, sendo este
a primeira etapa realizada. A primeira etapa, oportunizou conhecer
as guidelines para desenvolvimento de interface das plataformas,
iOS e Android. A segunda etapa consistiu no desenvolvimento do
Guia, produto deste trabalho. Uma posterior etapa, compreendeu
em uma avaliação preliminar do guia a partir da visão de
especialistas.
2.1 Importância de um bom design de
interface
O design de uma interface é muito importante para o usuário [21],
pois os usuários ficam mais confortáveis em interagir com
interfaces que são fáceis de usar e entender e façam com que eles
consigam realizar suas tarefas com o mínimo de frustração. A
aparência de uma interface e o modo de navegação podem afetar
uma pessoa de várias formas. Por sua vez, se forem confusas e
ineficientes, dificultarão para as pessoas realizarem as tarefas que
gostariam, ou dependendo da aplicação, dificultará que as pessoas
façam seus trabalhos ou cometam erros. Interfaces mal projetadas
podem fazer com que pessoas se afastem do sistema
permanentemente, fiquem frustradas e podem aumentar o nível de
stress [21]. Para [21] a importância de um bom design pode ser
demonstrada de uma maneira interessante se tratando em termos
financeiros. Para as empresas, boas interfaces (no contexto deste
trabalho corresponde a presença das recomendações de usabilidade
apresentadas em [24]) podem trazer benefícios como satisfação do
trabalhador e maior produtividade. Economicamente, isso pode
trazer benefícios como custos mais baixos, levando em conta que
sistemas mais fáceis de usar requerem menos treinamento.
4. RESULTADOS
Nesta seção são apresentados os passos e processos adotados para
o desenvolvimento do guia de boas práticas para desenvolvimento
de interfaces para a plataforma Android. Para isso optou-se em
realizar uma comparação entre as recomendações da Apple
realizadas no “iOS Human Interface Guidelines” [9] e as
recomendações da Google no “Android Design” [12]. No guia [9],
são apresentados conceitos básicos de UI Design, estratégias de
design, tecnologias do Sistema iOS, elementos de UI, entre outros.
O guia [12] apresenta princípios básicos de design, materiais para
design, dispositivos, estilos, padrões, entre outros. Cabe dizer que,
houve a preocupação de seguir boas práticas que poderão ser
utilizadas na plataforma Android, e também não desrespeitam as
restrições adicionadas na nova versão do guia da Google. Para um
melhor entendimento para o desenvolvimento deste Guia, optou-se
em apresentar lado-a-lado as recomendações das plataformas iOS e
Android, organizada como (conforme retrata a Tabela 1): (i)
considerações básicas de UI (user interface) (6 recomendações);
32








(ii) estratégias de design (); e, (iii) elementos de UI. A User
Interface (UI), ou interface do usuário é a camada na qual o usuário
interage com a aplicação, tudo o que o usuário deseja fazer com a
aplicação, as tarefas que deseja executar, são feitos através de
interações com a interface.
Tabela 1. Classificação e organização do Guia
Classificações
Considerações
básicas de UI
(user interface)
Estratégias de
design
Elementos de
UI
Recomendações



















Conceitos Básicos para Interface
Layout e Adaptatividade
Navegação
Interatividade e Feedback
Animação
Cor e Tipografia
Integridade Estética e Consistência
Manipulação Direta
Metáforas
Barra de Status
Barra de Navegação
Barra de Ferramentas
Botões da Barra de Navegação e barra
de Ferramentas
Barra Tabulada
Barra de Busca
Barra de Escopo
Indicador de Atividade
Selecionador de Data
Paginador
Selecionador
Barra de Progresso
Controle de Recarga
Botão Segmentado
Slider
Stepper
Chaveador
Campo de Texto
Para compor esta interface são utilizados elementos de interface,
em conjunto com padrões para uso dos mesmos, cores e tipografia.
As estratégias de design consistem em vários componentes que são
utilizados para fazer com que a interface contenha os padrões e
elementos necessários para proporcionar uma boa experiência ao
usuário. No entendimento da [9], integridade estética trata de
aspectos da aparência visual de um software aplicada na interação
da sua interface. No entanto, este termo não é comumente utilizado
na literatura, sendo que talvez o termo mais apropriado seria
usabilidade. A Tabela 2 apresenta um exemplo elaborado na
construção do Guia, onde é descrito as recomendações para a
utilização da Barra de status. A norma ISO/IEC 9126-1 [24]
descreve que a usabilidade é composta de subcaracterísticas, sendo:
aprensibilidade, a capacidade do produto de software de possibilitar
que o usuário aprenda por si só a utilizar a aplicação;
operacionalidade, onde o produto dá a possibilidade ao usuário de
operá-lo e controlá-lo; inteligibilidade, sendo a capacidade do
software possibilitar o usuário de compreender se ele é apropriado
para o seu uso; e atratividade, o quanto o software é atraente ao
usuário.
Tabela 2. Elemento de Interface: Barra de Status (versão de desenvolvimento do guia)
Barra de Status
A Barra de status exibe informações importantes a respeito do dispositivo e do ambiente atual, como por exemplo, porcentagem de bateria,
data e hora ou sinal de comunicação.
IOS
ANDROID
Usada para exibir informações importantes sobre o dispositivo e
o ambiente atual. Ex.: Hora, informações sobre bateria, sinal,
provedor, e outras informações do dispositivo que podem ou não
estar ativadas, como bluetooth ou wifi.
No Android, a barra de status tem basicamente as mesmas
funcionalidades das utilizadas pela Apple (status da bateria,
horário, wi-fi, bluetooth e sinal do celular), com uma diferença
que nela também são exibidas as notificações de aplicativos.
Características
Características







É transparente;
Quando aparece está no topo da tela;
Não deve ser criada uma barra de status customizada, ela
pode ser escondida para mostrar toda a aplicação, mas não
customizada.
Evitar colocar conteúdo atrás da barra de status.
Pensar bem antes de esconder a barra, pois o usuário deverá
sair da aplicação para ver informações que ele poderia ver
diretamente na barra, sendo que ela é transparente, não
precisa necessariamente ser escondida, a não ser para jogos
ou vídeos.

As mesmas características do IOS se aplicam aqui também.
A cor da barra de status deve seguir a cor primária da
aplicação, só que mais forte, seguindo a tonalidade 700 de
variação, podendo também ser transparente dependendo da
aplicação.
A barra de status exibe as notificações de aplicativos
através de ícones, estes que devem ser visualmente simples
evitando detalhes excessivos, facilitando assim com que o
usuário possa diferenciar os ícones que podem ali estar.
Estes ícones devem ser na cor branca com os detalhes
transparentes.
Recomendação do Guia
A barra de status deve estar obrigatoriamente posicionada na parte superior da tela. Deve-se seguir o padrão do material design para
definição da cor da barra (variação da tonalidade em 700 na escala de cor). A barra não deve ser customizada, no entanto pode ser ocultada
para uma melhora apresentação do conteúdo em rolagens para baixo, sendo restaurada quando houver rolagem da tela para cima. Em caso
de projetos de jogos ou apresentação de vídeos, para uma melhor imersão do usuário a barra de status poderá ser ocultada.
33
Por sua vez, a consistência em uma aplicação é aquilo que faz com
que o usuário possa interagir com diferentes partes da aplicação
com a mesma facilidade, e também consiga usar várias aplicações
diferentes com esta mesma facilidade. Uma aplicação consistente
não é uma cópia de outra, mas segue todos os padrões com os quais
os usuários já estão acostumados e confortáveis em interagir, que
são encontrados em outras aplicações, fazendo com que o App
proporcione uma experiência consistente. Por sua vez, são
elementos de interface aqueles que são utilizados para fazer a
interação do usuário com a interface, através dos componentes que
os usuários realizam as tarefas ou atingem o objetivo que desejam
com a App. Estes elementos podem ser botões, barras de tarefas ou
navegações, menus, ícones, etc.
[7] Neto, O. J. M., Usabilidade da Interface de dispositivos
móveis: heurísticas e diretrizes para o design, 2013.
Dissertação de mestrado do Instituto de Ciências
Matemáticas e Computação – ICMC-USP. Disponível em
<http://goo.gl/JftkJi>. Acessado em 17/03/2015
[8] Runija, Pooja, Importance of user interface design for mobile
app success, 2014. Disponível em < https://goo.gl/9PRpbs>.
Acessado em 28/03/2015
[9] Apple, iOS Human Interface Guidelines, 2015. Disponível
em < https://goo.gl/Mmvw4d >. Acessado em 10/05/2015
[10] Woodridge, D., Schneider, M. 2012. O Negócio De Apps
Para IPhone E IPad - Criando E Comercializando Aplicativos
De Sucesso, Elsevier Editora: Rio de Janeiro
5. CONCLUSÃO
[11] Pilone, D., Pilone, T. 2013. Use a Cabeça! Desenvolvendo
para iPhone e iPad, 2 ed., Alta Books: Rio de Janeiro
A partir da revisão bibliográfica, evidenciou-se que Android não
tem um cuidado tão grande em relação à interface e interação, em
contraste ao que acontece à plataforma da Apple. Entende-se que a
utilização deste guia no desenvolvimento de interfaces pode trazer
benefícios tanto para usuários como para desenvolvedores.
Observa-se que os desenvolvedores são beneficiados com
observações e/ou recomendações em diversas características de
qualidade, como também no uso de cada elemento da maneira
correta, permitindo assim também aumentar a produtividade do
desenvolvedor. Os benefícios para o usuário, estão relacionados ao
seguimento dos padrões e boas práticas de design e interface, assim,
apresentando certa qualidade implícita. Por sua vez, uma avaliação
do guia foi realizada utilizando o método GQM (Goal Question
Metrics) de [25], do ponto de vista de um especialista na área de
usabilidade de software. A avaliação demonstrou indícios de
viabilidade de uso do guia no desenvolvimento de aplicativos para
plataforma Android, e recomendações para melhoria da mesma.
Como próximo passo, destaca-se que uma revisão mais sistemática
no guia poderia melhorar as recomendações. Entende-se que
adicionar mais plataformas como o Windows Phone, poderia
contribuir com mais recomendações no guia. Outro ponto que
poderia ser considerado seria a utilização de ilustrações nas
recomendações, tanto as positivas (o que fazer), como nas negativas
(o que não fazer). Além disso, a utilização de exemplo e
contraexemplos poderia melhorar o guia. Também se recomenda a
realização de avaliações, tanto na perspectiva de especialista, como
desenvolvedores e usuários.
[12] Google, Android Design, 2015. Disponível em
<http://goo.gl/Pd5g8>. Acessado em 17/03/2015
[13] Burton, M., Felker, D. 2014. Desenvolvimento de
Aplicativos Android para Leigos, Alta Books: Rio de Janeiro
[14] Falconer, Joel. What Will Android’s New Design Guidelines
Mean for the Platform? 2012. Disponível em <
http://goo.gl/iMnogt>. Acessado em 17/03/2015
[15] David, M., Murman, C., 2014. Designing Apps for Success:
Developing Consistent App Design Practices, Focal Press
[16] Komarov, A., Yermolayev. 2013. Designing For a Maturing
Android, Smashing Magazine. Disponível em
<http://goo.gl/Dse1wg>. Acessado em 17/03/2015
[17] Nunes, I.D., Correia, R.S., 2013. A Importância da
usabilidade no desenvolvimento de aplicativos para
dispositivos móveis. Disponível em <http://goo.gl/Fgt2r5>.
[18] Unitid, Interaction designers, androidpatterns. Disponível em
<androidpatterns.com>. Acessado em 17/03/2015
[19] Júnior, M. A. P.; Castro, R. de O. 2011. Um estudo de caso
da plataforma Android com Interfaces Adaptativas, Revista
@LUMNI, Vol. 1 n. 1. Disponível em
<http://goo.gl/0DKIlP>. Acessado em 17/03/2015
[20] Rocha, L. C., et al., 2014. Heurísticas para avaliar a
usabilidade de aplicações móveis: estudo de caso para aulas
de campo em Geologia, In TISE 2014
6. REFERÊNCIAS
[1] Pcworld, 1 billion smartphones shiped worldwide in 2013,
2013. Disponível em < http://goo.gl/tMV3Zf >. Acessado em
28/03/2015
[21] Stone et al,. 2004. User Interface Design and Evaluation,
Steve Krug. Disponível em <https://goo.gl/CQEdLz>.
[2] Smart Insights, Statistics on mobile usage and adoption to
inform your mobile marketing strategy, 2015. Disponível em
< http://goo.gl/paQFV>. Acessado em 28/03/2015
[22] Banga, C., Weinhold, J. 2014. Essential Mobile Interaction
Design, Pearson Education
[3] Pew Research, The rise of apps culture, 2010. Disponível em
< http://goo.gl/Zwc5fK>. Acessado em 28/03/2015
[23] Dclick, Guideline iOS – Características da Plataforma – 1,
2012. Disponível em <http://goo.gl/Qyg8xM>. Acessado em
10/05/2015
[4] Sebrae, Aplicativos para celulares movem mercado
bilionário, 2014. Disponível em <http://goo.gl/tRp2zQ>.
[24] Abnt, Associação Brasileira De Normas Técnicas, NBR
ISO/IEC 9126-1: Engenharia de Software – Qualidade de
produto – parte 1: modelo de qualidade. Rio de Janeiro, 2003
[5] Pereira, R. S., Costa, C. C., A importância do projeto de
interface no desenvolvimento, 2012. Disponível em <
http://goo.gl/1FJVcX>. Acessado em 28/03/2015
[25] Basili, V., Caldiera, G., Rombach, H. D. Goal Question
Metric Approach, 1994, Encyclopedia of Software
Engineering, pp. 528-532, John Wiley & Sons, I
[6] Ellwanger, C., Santos, C. P., Moreira, G. J., Gamificação e
padrões de interface em dispositivos móveis: Uma aplicação
no contexto educacional, 2014. Disponível em <
https://goo.gl/Txjg5a>. Acessado em 08/12/2015
34
Automação de Testes em Sistemas Legados: Um Estudo
de Caso para a Plataforma Flex
Alternative Title: Test Automation on Legacy Systems: A Case
Study for Flex Platform
Augusto Boehme Tepedino Martins
Departamento de Informática e Estatística INE/CTC
(48) 9973-2889
[email protected]
Jean Carlo Rossa Hauck
Departamento de Informática e Estatística INE/CTC
(48) 3721-7507
[email protected]
RESUMO
General Terms
A realização de testes demonstra cada vez mais sua importância nas
organizações que desenvolvem software. Realizar testes, no
entanto, é caro e demorado e automatizar testes é uma alternativa
interessante e tecnicamente viável. Sistemas legados comumente
apresentam limitações para a automação de testes e isso ocorre
também em sistemas Web desenvolvidos utilizando a plataforma
Flex. Assim, este trabalho apresenta o desenvolvimento da
automação de testes para plataforma Flex. Casos de teste são
elaborados, uma ferramenta é selecionada, os scripts de teste são
desenvolvidos e executados em um estudo de caso em uma empresa
de desenvolvimento de software. Os resultados observados
apontam indícios de que a automação de que testes pode aumentar
inicialmente os esforços de elaboração dos casos de teste mas
reduzem o tempo de execução, tendendo a gerar benefícios futuros.
Reliability, Verification.
Keywords
Test. Integration. Automation. Flex.
INTRODUÇÃO
Com a tecnologia cada vez mais avançada, muitas pessoas acabam
não observando o quanto os softwares estão envolvidos em suas
vidas, possivelmente porque suas ações são de tal forma
transparentes aos seus usuários que se tornam algo trivial no seu
dia-a-dia.
Com essa dependência atual de softwares em grande parte das
atividades humanas, os produtos de software e o processo de
criação de um software passaram a ser objeto de estudo, mesmo que
um software gratuito venha a ser produzido, não será bem aceito se
não for de fácil manuseio ou se possuir defeitos nas suas
funcionalidades.
Palavras-Chave
Testes. Integração. Automação. Flex.
ABSTRACT
Especificamente falando de aplicativos que rodam na Web,
algumas características esperadas de qualidade, como:
disponibilidade de acesso, desempenho, evolução contínua e
segurança [1]. Entretanto, a qualidade esperada nem sempre é
alcançada. Algumas vezes, produtos de software têm sido entregues
aos clientes
cobrindo apenas os requisitos funcionais
especificados, sem eliminar possíveis erros. Uma das maneiras de
garantir que a qualidade de um produto de software seja atendida,
e que as funcionalidades que o cliente necessita estejam presentes,
é a aplicação de testes de software.
Software testing is increasing its importance in software
development organizations. Performing tests, however, is costly
and time consuming and automate testing is an interesting and
technically viable alternative. Legacy systems often have
limitations for test automation and it occurs on Web systems
developed using the Flex platform. Thus, this work presents the
development of test automation for Flex platform. Test cases are
developed, a tool is selected, test scripts are defined and
implemented in a case study on a software development company.
The observed results indicate initial evidence that test automation
may initially increase the development efforts of the test cases but
reduce the runtime, tending to generate future benefits.
Nesse sentido, a padronizações e a automação de testes destacamse na forma de garantir a qualidade de software. A padronização
dos testes, como por exemplo a documentação sobre casos de
testes, com o passo-a-passo de como o teste deve ser feito, diminui
a chance de variações na forma como os testes são realizados
interfiram nos seus resultados. Já a automação de testes tende a
diminuir a falha humana nos processos de testes. Assim, um grupo
menor de pessoas poderia automatizar alguns tipos de testes que
seriam repetidos toda vez que fosse necessário.
D.2.5 [Testing and Debugging]
Copyright SBC 2016.
1
Assim, o presente trabalho apresenta um estudo de caso de
desenvolvimento de automação de testes para a plataforma Flex1
http://www.adobe.com/products/flex.html
35

com objetivo de reduzir a falha humana e a necessidade de repetir
testes manuais no sistema legado.
R5: Suportar as versões mais recentes dos navegadores:
Firefox, Chrome, Internet Explorer, e Opera;

R6: Suportar testes automatizados em Aplicações Web;

R7: Possuir documentação abrangente;

R8: Ser capaz de utilizar um repositório central para que
múltiplos usuarios possam utilizar os scripts gerados
Após a execução das buscas nas ferramentas de pesquisa indicadas,
foram encontradas as seguintes ferramentas que satisfazem, ao
menos em parte, os requisitos propostos (vide Tabela 1).
Tabela 1. Ferramentas selecionadas
As próximas seções são divididas da seguinte forma: na seção 2 é
apresentado o estado da arte, seguindo da seção 3 onde a
abordagem metodológica deste trabalho é brevemente apresentada;
na seção 4 o estudo de caso é descrito e na seção 5 as conclusões
são apresentadas.
1. ESTADO DA ARTE
Como o presente trabalho trata da automação de testes de uma
aplicação legada sobre a plataforma Flex, este tópico apresenta
relatos na literatura de experiências similares, buscando por
soluções de automação já experimentadas para essa plataforma.
Ferra
menta
Flex-
Assim, a busca por trabalhos similares foi realizada em consulta as
seguintes ferramentas de pesquisa:
Google
(http://www.google.com),
Google
Scholar
(http://scholar.google.com),
Portal
CAPES
(http://wwwperiodicos-capes-govbr.Ez46.periodicos.capes.gov.br/index.php?option=com_phome),
pela facilidade de acesso e relevância como fontes de pesquisa,
procurando envolver tanto referências da literatura quanto
experiências da indústria.
uiSeleni
um2
FlexM
onkey3
Nessas ferramentas de busca, foram utilizadas as seguintes palavras
de busca: “Software”, "Teste automatizado", "Flex" e algumas
variações/complementos: “Automação de testes de software”,
“benefícios de testes automatizados”, “automatização de testes com
Flex”, “Diferenças entre Flex e HTML”. Também foram utilizadas
nas pesquisas as traduções na língua inglesa dos mesmos termos.
Badbo
y4
Sobre os resultados encontrados, para selecionar aqueles mais
pertinentes a esta pesquisa, os seguintes critérios de inclusão foram
utilizados:

Ferramentas de automação de Testes com suporte à
plataforma Flex: pois uma ferramenta para automatizar
testes que não suporta a plataforma Flex, não é relevante
ao trabalho;

Plug-ins de automação de teste para Flex: tendo mesmo
motivo de procura como foi relatado no critério acima;

Relatos de experiência de automação de teste com Flex:
para saber como ferramentas trabalham nesta plataforma
e ter uma melhor decisão sobre o software escolhido
Para apoiar a busca, alguns requisitos de automação de testes para
uma ferramenta legada sobre plataforma Flex foram identificados,
com base: (i) nas características de ferramentas de automação de
testes já previamente identificadas na literatura; (ii) nas
necessidades para automação de testes coletadas por meio de
entrevistas com analistas de testes da empresa desenvolvedora do
software (vide seção 4); e (iii) em entrevista com o gerente de
projetos da empresa desenvolvedora do software; e, especialmente,
(iv) nas limitações técnicas de automação de testes na plataforma
Flex, que impossibilita a utilização de webdrivers por não
manipular html diretamente:




Descrição
Testm
aker5
Sikuli6
Bugbu
ster
Test
Recor
R1: Possuir alguma versão gratuita
R2: Suportar testes automatizados;
R3: Estar atualizada e possuir comunidade ativa;
R4: Suportar testes automatizados sobre Flex;
Extensão da ferramenta
Selenium para a plataforma
Flex, estendendo as
possibilidades de uso do
Selenium Webdriver, e
pode gerar scrpits nas
linguagens Java, C#, Perl,
Ruby, e PHP.
Aplicativo Adobe AIR
gratuito, desenvolvida pela
GorillaLogic que permite
a criação de testes
automatizados em
plataformas AIR e Flex.
Ferramenta de automação
de testes baseada na
interface gráfica do usuário
(GUI - Graphics User
Interface), trabalhando
com a movimentação do
mouse e com um script,
usando de modo
Record/Playback para
tornar ações do usuário em
Scripts.
Ferramenta gratuita que
consegue tornar um script
de teste em um teste
funcional, um teste de
carga, ou um teste de
performance, que cria
scripts em Java, Ruby,
Python, e PHP.
Ferramenta de automações
de teste hibrida, na qual
trabalha tanto com GUI,
como com scripts de
usuário. Interage com a
tela a partir da captura de
imagens, ou regiões,
definidas no script.
Extensão feita para o
Google Chrome,
permitindo a criação de
testes a partir de cliques
feitos na janela do browser
R
R
R
R
R
R
R
R
1
2
3
4
5
6
7
8
+
+
+
+
+
+
-
+
+
+
-
+
+
+
+
+
+
+
+
-
+
+
+
+
+
+
+
?
-
+
-
+
+
+
+
+
+
+
+
+
+
+
?
-
+
+
-
d7
Legenda: +: atende, -: não atende, ?: não foi possível determinar.
2
6
3
7
https://code.google.com/ p/flex-ui-selenium/
https://www.gorillalogic.com/flexmonkey
4
http://www.badboy.com.au/
5 http://www.pushtotest.com/index.php
36
http://www.sikuli.org/
https://bugbuster.com/
As ferramentas foram então instaladas e avaliadas uma a uma em
relação aos requisitos propostos. Após essa avaliação, a ferramenta
que melhor atendeu os requisitos foi a ferramenta Sikuli, que cobriu
todos os requisitos definidos.
automação) e dois testadores (graduandos de Ciências da
Computação)
3.2 Preparação
A coleta de dados corresponde ao conjunto das operações, através
das quais o modelo de análise é submetido ao teste dos fatos e
confrontado com dados observáveis [3]. Como a principal pergunta
de pesquisa do presente trabalho consiste em: "Seria possível
automatizar testes para um software Flex de forma a reduzir o
esforço, tempo e retrabalho, tomando por base uma ferramenta já
existente para modelagem e automatização de testes?", os seguintes
dados foram planejados para serem coletados:

Quantidade de pontos de caso de uso;

Quantidade de erros encontrados na execução dos testes
automatizados;

Avaliação subjetiva dos resultados observados pelos
envolvidos na área de testes;

Quantidade de esforço realizado para a elaboração dos
casos de testes automatizados.
2. ABORDAGEM METODOLÓGICA
Nesta seção, são apresentadas as etapas da abordagem
metodológica do presente trabalho.
Segundo [2], pode-se definir um estudo de caso como um estudo
focado de um fenômeno em seu contexto, especialmente quanto
quando os limites entre o fenômeno e o contexto não podem ser
bem definidos. [2] indica também que é compreensível aplicar
estudos de caso às áreas relacionadas à engenharia de software tais
como desenvolvimento, operação e manutenção de software. Cada
uma das etapas é brevemente apresentada na sequência.

Planejamento: objetivos são definidos e o estudo de caso
é planejado;

Preparação: procedimentos e protocolos para coleta de
dados são definidos;

Coleta: execução e coleta de dados do estudo de caso;

Análise: onde os dados coletados são analisados e
extraídas as conclusões;

Relatório: onde os dados analisados são reportados.
A seção 4 a seguir detalha as principais etapas desta pesquisa no
contexto do estudo de caso.
3.3 Execução e coleta de Dados
O estudo de caso foi executado no período de 5 de Maio de 2015
até 10 de Setembro de 2015, após a análise de qual ferramenta de
automação seria utilizada.
A ferramenta Sikuli, conforme já apresentado, é uma ferramenta de
automação de testes de GUI que mescla Scripts com imagens, que
são procuradas quando o programa está rodando.
3. ESTUDO DE CASO
Segundo [4], a ideia de utilizar imagens para auxiliar na automação
de testes vem da própria forma como ocorre interação na
comunicação humana. Assim, na ferramenta Sikuli, as imagens são
utilizadas como parâmetros, de maneira similar a constantes
declaradas em qualquer linguagem de programação, onde o usuário
pode definir o nome da imagem, o grau de similaridade que procura
na tela, e aonde irá selecionar a tecla quando necessário.
De acordo com [2], é essencial para o sucesso de um estudo de caso
que ele possua um bom planejamento. Assim, no contexto deste
trabalho, o estudo de caso foi planejado onde foram definidos: a
unidade de análise, os métodos utilizados para a coleta de dados,
cronograma, participantes, etc. De forma resumida, o planejamento
do estudo de caso é apresentado na sequência, iniciando pela
definição da unidade de análise.
Para utilizar a ferramenta, foi necessário instalar o Java JDK8.
Entretanto, durante os testes não foi possível integrá-la ao Eclipse9
e utilizar a linguagem Java pois não foi encontrada documentação
que facilitasse a utilização do script com a ferramenta. Assim, os
scripts de teste m implementados em Jython10.
3.1 Contextualização do Estudo de Caso
A empresa SPECTO Tecnologia é uma empresa que iniciou suas
atividades no início da década de 90, e vem desenvolvendo
produtos atualmente por meio de três linhas de produtos: CXM
(gestão de atendimento), DCIM (gestão de datacenters), e BMS
(gestão de prédios inteligentes).
O presente estudo de caso é realizado na divisão de gestão de
datacenters (DCIM) da empresa. A DCIM tem como objetivo o
desenvolvimento de produtos de software para monitorar e
controlar o ambiente de datacenters, permitindo por exemplo,
alertar o usuário que um ambiente está com muita fumaça, ou que
um dispositivo de monitoramento foi desconectado, por exemplo.
O sistema utilizado neste estudo de caso é o DataFaz Unity, um
gerenciador de infraestrutura de datacenters, monitorando
parâmetros físicos de ambiente, tais como: umidade, temperatura,
energia, controle de acesso, etc. O sistema utiliza Flex para o
desenvolvimento de sua interface com o usuário e o back end é
desenvolvido em Java, com banco de dados tipicamente utilizado
sendo PostgreSQL.
Neste estudo de caso são envolvidos os membros das equipes
responsáveis pelos testes do sistema DataFaz Unity (membros da
equipe de garantia de qualidade de produto), sendo três analistas de
testes (dois formados em ciências da computação e um em
Com a ferramenta instalada e pronta para executar os testes de
forma automatizada, foi preparado o ambiente com as demais
ferramentas necessárias e realizada a criação dos scripts de
automação de testes. Para efetuar os testes manuais, configurou-se
um computador para possuir o sistema DataFaz Unity instalado
localmente, e também o software Enterprise Architect11 utilizado
pela empresa para documentar a análise e modelagem do software
(para organizar e documentar os casos de uso e os casos de teste
com seus cenários), o PGadmin12 para administração do banco de
dados e recuperação do backup do banco de dados somente
contendo a configuração inicial.
Com esse ambiente instalado, foram elaborados os casos de teste
que seriam realizados tanto manualmente quanto de forma
automatizada, de forma a possibilitar a comparação mais objetiva
dos resultados da automação. Os casos de testes foram
documentados na ferramenta Enterprise Architect, conforme já
citado.
Foram elaborados, ao todo, dez casos de testes completos, cada um
possuindo de três a cinco diferentes cenários, tomando-se por base
8
11
9
12
http://www.oracle.com/technetwork/pt/java/javase/downloads/index.html
http://www.eclipse.org/downloads/
10
http://www.jython.org/
37
http://www.sparxsystems.com.au/products/ea/
http://www.pgadmin.org/
as principais funcionalidades do sistema Datafaz Unity. Os casos
de teste foram documentados seguindo as melhores práticas
definidas na norma ISO/IEC/IEEE 29119 [5]. Para cada caso de
teste foi realizada a implementação do seu correspondente em script
de teste automatizado
Da mesma forma, a empresa possui poucos analistas de testes na
unidade organizacional do estudo de caso, fazendo com que os
resultados obtidos fossem escassos, mais analistas trariam mais
respostas, e o resultado da aplicação questionário seria mais
abrangente.
Cada um dos casos de teste foi então executado manualmente por
dois testadores diferentes e cada um dos scripts de teste
automatizado foi executado dez vezes em um mesmo computador.
Ao final dos testes, os analistas de teste e testadores foram
submetidos a um questionário de avaliação, composto de quatro
perguntas utilizando escala Likert de respostas, procurando
identificar as percepções sobre o resultado da aplicação dos testes
automatizados.
Além disso, o autor do trabalho teve participação ativa na execução
do trabalho, e este envolvimento direto pode gerar viés de
interpretação de dados coletados.
4. CONCLUSÕES
Este trabalho apresenta uma experiência de automação de testes em
um sistema legado desenvolvido sobre plataforma Flex. Tendo em
mente as limitações de automação de testes em Flex, foram
analisadas diferentes abordagens de automação. Foi possível notar
que nenhuma ferramenta iria poder automatizar a aplicação em sua
totalidade, então foram criados requisitos para escolher qual
ferramenta seria utilizada no trabalho. A ferramenta Sikuli, que
cobriu a maior parte dos requisitos propostos, foi escolhida.
3.4 Análise dos Resultados
Durante toda a execução dos testes, os dados de duração foram
coletados por meio do registro das tarefas no sistema de gerência
de projetos utilizado pela empresa13. Como resultado, conforme
esperado, foi percebido que o tempo necessário para elaboração dos
testes automatizados e manuais apresentou grande diferença,
devido ao tempo utilizado na elaboração dos Scripts de testes
automatizados, conforme mostra a Tabela 2.
No contexto de um estudo de caso, casos de teste foram elaborados,
sendo implementados scripts de teste na linguagem aceita pelo
Sikuli. Os testes foram então executados de forma manual e
automatizada, em um ambiente controlado.
Tabela 2 - Comparações entre teste manual e teste
automatizado
Métricas
Teste Manual
Teste
Automatizado
Elaboração dos casos de teste
Elaboração Scripts de Testes
Automatizados
Tempo médio de execução
Total Duração
05h00min
-
05h00min
07h30min
00h08min
05h08min
00h02min30seg
12h32min30seg
Os dados coletados de esforço e tempo durante a elaboração e
realização dos testes no estudo de caso levantam indícios de que o
ganho de tempo na automação de testes é pequeno inicialmente.
Espera-se, entretanto, que a organização envolvida no estudo de
caso obtenha benefícios diretos com a redução de custos de
retrabalho e aumento de confiabilidade da aplicação com a
execução dos testes automatizados em futuros releases do sistema.
Como trabalhos futuros planeja-se a integração dos testes
automatizados com a ferramenta de documentação e modelagem
dos testes. Além disso, seria importante expandir os casos de teste
automatizados para o restante das funcionalidades do sistema.
Entretanto, conforme também mostra a Tabela 2, o tempo
necessário para execução dos testes automatizados foi
consideravelmente inferior. Espera-se que as futuras execuções dos
testes automatizados venham a compensar o maior esforço aplicado
na elaboração dos scripts de teste.
5. AGRADECIMENTOS
Os autores agradecem aos membros da equipe da empresa Specto
que participaram do estudo de caso. Também agradecem a
cooperação e interesse da gerência da empresa no estudo de caso.
Além dos dados de tempo de execução, a partir da aplicação do
questionário, foi possível coletar a impressão subjetiva dos
participantes em relação aos resultados da automação de testes no
sistema legado utilizando plataforma Flex.
6. REFERENCES
[1] Pressman, R. S. Engenharia de software: uma abordagem
profissional; Tradução Ariovaldo Griesi e Mario moro
Feccio. 7ª ed. São Paulo: AMGH, 2011.
[2] Runeson, P., and M. Höst. "Guidelines for conducting and
reporting case study research in software engineering."
Empirical Software Engineering 14.2, 2009.
[3] Quivy, R. et al. (1992). Manual de Investigação em Ciências
Sociais. Lisboa: Gradiva.
[4] Yeh, Tom, Chang, Tsung-Hsiang, Miller, Robert C. (2009):
Sikuli: using GUI screenshots for search and automation. In:
Proceedings of the ACM Symposium on User Interface
Software and Technology, 2009, pp. 183-192.
http://doi.acm.org/10.1145/1622176.1622213.
[5] International Organization for Standardization.
ISO/IEC/IEEE 29119. Software Testing Standard. 2010.
[6] Zelkowitz, M. V. “An update to experimental models for
validating computer technology,” J. Syst. Softw., vol. 82, pp.
373–376, 2009.
[7] Yin, R. K. Applications of case study research, vol. 34
Tabela 3 - Resultados do questionário
Questões
Facilidade na compreensão dos testes
Cenários cobriram a funcionalidade proposta
A infraestrutura disponibilizada para o ambiente de
testes foi satisfatória para a execução dos testes
O tempo gasto com teste automatizado diminui
esforços de custo e tempo com execuções repetitivas
Concordam
80%
80%
80%
100%
Conforme pode ser percebido pelas respostas dos participantes, a
automação de testes utilizando a ferramenta Sikuli, atendeu às
expectativas da maioria. Entretanto, foram percebidas
oportunidades de melhoria pela equipe, como por exemplo, a
possibilidade de integração direta com o Eclipse, possibilitando a
implementação dos scripts em Java.
3.4.1 Ameaças à validade
Como tipicamente ocorre em estudos de caso [6] [7], o presente
trabalho somente foi aplicado em um único software de uma única
empresa, não sendo possível desta forma, generalizar seus
resultados a outras empresa e cenários, mesmo que positivos.
13
http://www.jexperts.com.br/category/pse/pse-pch/
38
Análise do uso de técnicas de pré-processamento de
dados em algoritmos para classificação de proteínas
Alternative Title: Analysis of the use of data pre-processing techniques in
algorithms to classification proteins
Lucas Nascimento Vieira
Depto de Informática - Univille
Joinville - SC - Brasil
[email protected]
Luiz Melo Romão
Depto de Informática - Univille
Joinville - SC - Brasil
[email protected]
RESUMO
Muitos problemas têm sido tratados pela bioinformática, entre estes, se destaca a predição de funções biológicas de proteı́nas. A complexidade deste tipo de aplicação vem da própria estrutura de organização da proteı́na que descreve estas
funções utilizando uma hierarquia estruturada em árvores
ou em grafos acı́clicos dirigidos. A maioria dos classificadores de proteı́nas disponı́veis na literatura utiliza na etapa
de pré-processamento o método de discretização, que tem a
função de transformar os atributos contı́nuos das bases de
dados em intervalos discretos representados por atributos
nominais. Este artigo ilustra a alteração do funcionamento
do algoritmo HLCS-Multi que utiliza o método de discretização, para utilizar valores reais, que permitirá estimativas
mais precisas sobre os resultados.
H.4 [Information Systems]: Miscellaneous
Palavras-Chave
Descoberta do Connhecimento, Mineração de Dados, PréProcessamento
ABSTRACT
Many problems have been dealt with by bioinformatics, among
which stands out the prediction of biological functions of
proteins. The complexity of this type of application comes from the protein organization structure that describes
these functions using a structured hierarchy tree or directed
acyclic graph. Most protein binders available in the literature uses the pre-processing step the discretization method,
which has the function of transforming the continuous attributes of databases in discrete intervals represented by nominal attributes. This article illustrates the change in the
functioning of the HLCS-Multi algorithm that uses the discretization method to use actual values, which will enable
more accurate predictions about the results.
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SBSI 2016, May 17th-20th, 2016, Florianópolis, Santa Catarina, Brazil
Copyright SBC 2016.
39
General Terms
Information Systems
Keywords
Knowledge Discovery, Data Mining, Pre-Processing
1.
INTRODUÇÃO
Muitos problemas têm sido tratados pela bioinformática,
entre estes, se destaca a predição de funções biológicas de
proteı́nas. A complexidade deste tipo de aplicação vem da
própria estrutura de organização da proteı́na que descreve
estas funções utilizando uma hierarquia estruturada em árvores ou em grafos acı́clicos dirigidos.
Devido a essa diversidade de funções, as proteı́nas exercem papel fundamental em quase todos os fenômenos biológicos, como produção de energia, defesa imunológica, contração muscular, atividade neuroquı́mica e reprodução [2]. De
acordo com [4], as proteı́nas podem variar na sua composição, sequência e número de aminoácidos, por isso, é possı́vel
uma enorme variação de sua estrutura e de sua função.
A maioria dos classificadores de proteı́nas disponı́veis na
literatura utiliza na etapa de pré-processamento o método
de discretização ou normalização que podem ocasionar perda
de informação no processo de classificação.
A proposta deste trabalho é desenvolver um algoritmo
para a classificação da função de proteı́nas que possa trabalhar durante todas as etapas da extração do conhecimento
com qualquer tipo de atributo, sendo este numérico ou categórico. Para isso, será utilizado como base o algoritmo
HLCS – Multi (Hierarchical Learning Classifier System Multilabel) proposto em [11] que apresenta um modelo global
hierárquico multirrótulo para a predição de problemas hierárquicos, mas que utiliza o método de discretização na
etapa de pré-processamento
Além desta seção introdutória, o artigo foi dividido nas
seguintes seções. A fundamentação teórica dos conceitos
principais utilizados no trabalho. Em seguida é relatada as
caracterı́sticas do algoritmo HLCS – Multi e as alterações
propostas para este projeto. Finalizando serão mostrados os
resultados alcançados e as considerações finais do trabalho
2.
FUNDAMENTAÇÃO TEÓRICA
A Descoberta de Conhecimento em Banco de Dados (KDD
do inglês, Knowledge Discovery in Database), é um processo
de extração de informações de base de dados, que cria relações de interesse que não são observadas pelos especialistas
no assunto.
O KDD pode ser visto como o processo de descoberta de
padrões e tendências por análise de grandes conjuntos de
dados, tendo como principal etapa o processo de mineração,
consistindo na execução prática de análise e de algoritmos
especı́ficos que, sob limitações de eficiência computacionais
aceitáveis, produz uma relação particular de padrões a partir
de dados. A extração de conhecimento refere-se às etapas
que produzem conhecimentos a partir de dados relacionados, e sua principal caracterı́stica é a extração não-trivial de
informações implicitamente contidas em uma base de dados
[8].
A Figura 1 demonstra de uma maneira simplificada todas
as fases do KDD.
O método de discretização tem a função de transformar os
atributos contı́nuos das bases de dados em intervalos discretos representados por atributos nominais. A discretização
pode ser dividida em duas principais categorias: aprendizagem supervisionada e não supervisionada, que é uma área
de inteligência artificial, cujo o objetivo é desenvolver técnicas computacionais que possibilitem que o sistema tome
decisões baseadas nas experiências acumuladas. Conforme
[11] na discretização supervisionada, existe uma interdependência entre os valores das variáveis e a classe das instâncias
do conjunto de treinamento, já a não supervisionada não
leva em consideração a informação de classes das instâncias
do conjunto de treinamento. De acordo com [6], o objetivo
da discretização é reduzir o número de valores das variáveis
contı́nuas, agrupando as em um número n de intervalos.
A normalização de dados consiste em ajustar os valores de
cada atributo, de forma que os valores fiquem em pequenos
intervalos. É uma série de passos que é seguido para um
projeto de banco de dados, e a execução desses passos irá
permitir a criação de um formato lógico e adequado para as
estruturas dos dados, permitindo o armazenamento consistente e eficiente dos dados.
Entretanto, o uso destas técnicas podem ocasionar em
perda de informações, pois em alguns casos estas técnicas
não consideram a relação entre atributos.
O uso de técnicas de discretização ou normalização podem ser encontrados em diversos trabalhos disponı́veis na
literatura, para a classificação da função de proteı́nas. Os
principais trabalhos identificados, nesta pesquisa foram: [7],
[11], [1] e [5]
3.
Figura 1: Fases do Processo de KDD [8].
O produto esperado da extração de conhecimento é uma
informação relevante para ser utilizada pelos tomadores de
decisão. Este processo leva a descoberta de informações acionáveis em grandes conjuntos de dados à procura de padrões consistentes, como regras de associação ou sequências
temporais, para detectar relacionamentos sistemáticos entre
variáveis, detectando assim novos subconjuntos de dados.
O pré-processamento de dados é frequentemente tido como
sendo uma fase que envolve uma grande quantidade de conhecimento de domı́nio. Entende-se que essa fase depende
da capacidade de analisar os dados e identificar problemas
nos dados presentes. Esta fase de pré-processamento tendese a consumir a maior parte do tempo dedicado no processo de descoberta do conhecimento. Como a necessidade
de apresentar os dados em uma forma apropriada para a
técnica de mineração de dados escolhida, requer toda uma
preparação para a classificação dos dados.
Conforme, [3] esta fase busca-se aprimorar a qualidade
dos dados coletados. Frequentemente, os dados apresentam
diversos problemas, tais como grande quantidade de valores desconhecidos, ruı́do (atributos com valores incorretos),
atributos de baixo valor preditivo, grande desproporção entre o número de exemplos de cada classe, entre outros.
Entre as técnicas utilizadas na fase de pré-processamento
de dados pode se citar o uso de técnicas de discretização e
normalização, que são técnicas que transformam atributos
de dados contı́nuos, em valores categóricos.
40
ALGORITMO HLCS MULTI
Conforme [11], o algoritmo Hierarchical Learning Classifier System Multilabel (HLCS – Multi), apresenta uma solução global hierárquica multirrótulo para a classificação da
função de proteı́nas respeitando a hierarquia das classes em
todas as fases de desenvolvimento do sistema. É desenvolvido especificamente para trabalhar com bases hierárquicas
e utiliza como modelo de desenvolvimento os Sistemas Classificadores (LCS), que é um método que gera seus resultados
em um conjunto de regras no formato SE-ENTÃO, que são
representações, de acordo com [9] mais compreensı́veis do
que outros modelos como redes neurais, máquinas de vetor
de suporte entre outros. O HLCS – Multi é o primeiro modelo baseado em Sistemas Classificadores para a predição de
problemas hierárquicos multirrótulo.
Para trabalhar com dados hierárquicos, o HLCS – Multi
apresenta um componente especı́fico para esta tarefa que é
o componente de avaliação dos classificadores. Este componente tem a função de analisar as predições dos classificadores considerando a hierarquia das classes. Além do
componente de avaliação, a arquitetura HLCS – Multi consiste dos seguintes módulos: população de classificadores,
componente AG, componente de desempenho e componente
de cessão de créditos, que interagem entre si.
Em geral, o sistema HLCS – Multi cria sua população de
classificadores através da análise dos exemplos do ambiente,
que representam os dados de treinamento. A medida que o
HLCS – Multi interage com o ambiente, por meio dos componentes de desempenho e cessão de créditos, os classificadores
são avaliados e recebem um retorno na forma de uma recompensa que impulsiona o processo de aprendizagem. Este
processo de aprendizagem tem a intervenção do componente
de avaliação, que ajuda no cálculo da recompensa avaliando
as predições do sistema conforme a sua hierarquia. No fim
desta etapa, os classificadores passam por um mecanismo de
evolução através do componente AG, que utiliza algoritmos
genéticos como base para a melhoria do conhecimento atual
do sistema.
A questão multirrótulo é trabalhada durante todas as etapas de treinamento e teste do modelo por meio de um processo de decomposição das instâncias e na forma de análise
das predições.
4.
SOLUÇÃO PROPOSTA
A solução proposta neste artigo é chamada de HLCS –
MultiND (Hierarchical Learning Classifier System Multilabel No Discretizate). Baseada no algoritmo HLCS – Multi,
esta versão tem como diferencial a possibilidade de trabalhar durante todas as etapas da extração do conhecimento
com qualquer tipo de atributo, sendo este numérico ou categórico. Para isso foi realizada uma mudança no algoritmo
HLCS – Multi permitindo que as regras geradas pelo classificador possam criar condições de intervalos entre os atributos.
A primeira função do sistema é criar uma população inicial
de classificadores, através de uma análise feita nas instâncias da base de treinamento de tamanho N, que representa
a fonte de dados do sistema. Para formar cada classificador da população inicial, o algoritmo escolhe aleatoriamente
uma instância da base de treinamento como modelo. Cada
atributo da instância de treinamento será criado uma condição no classificador. Está instância será definida por uma
condição que receberá como parâmetro OP, VL, A/I, sendo:
• OP: operador de relação (=, <= ou >=)
lista de regras iniciais. Está lista de mı́nimo e máximo é
criada após a leitura da base de dados, e a cada geração
de regra inicial, assim evitando a necessidade de ler a lista
de regras novamente e aumentando a performance. Para a
medição da performance foi implementado métodos que registraram o tempo inicial da execução e tempo final, os quais
são relatados no fim do processo.
Além das regras já listadas, também foi alterado o algoritmo para sempre gerar uma nova população inicial, sempre
que não for identificada uma lista de regras iniciais para o
grupo corrente de atributos e valores que estão sendo processados. Com essas alterações foi possı́vel trabalhar durante
todas as etapas da extração do conhecimento com qualquer
tipo de atributo, possibilitando a execução do algoritmo em
bases com atributos nominais e contı́nuos, descartando a necessidade de utilizar o método de discretização, tornando o
algoritmo mais eficaz e compreensı́vel o bastante para que
os pesquisadores consigam analisar e confiar nas predições
recebidas.
5.
ANÁLISE DE DADOS E DISCUSSÃO DOS
RESULTADOS
A fim de demonstrar os resultados obtidos com o HLCS
– MultiND o algoritmo foi comparado com os resultados da
versão HLCS – Multi publicados em [12]. Os experimentos
foram realizados em três conjuntos de dados de funções de
proteı́nas, Cellcycle, Church e Derisi que foram utilizados
em [13] e estão disponı́veis em (http://dtai. cs. kuleuven.be
/clus /hmcdatasets). Estas bases contêm informações de
classes baseadas nos termos da Ontologia Gênica (GO) e
são organizadas em uma estrutura em forma de um DAG.
A Tabela 1 apresenta os detalhes das bases utilizadas nesta
experiência.
• VL: valor da condição
• A/I: opção de ativa (A) ou inativa (I) da condição, que
significa se a condição será utilizada na classificação ou
não.
No inı́cio as condições começam com o operador de relação
(OP) “= ou <= ou =>” a escolha dos operadores de comparação ocorre de forma randômica. O valor da condição (VL)
recebe o valor do atributo da instância em treinamento e
aletoriamente, de acordo com a probabilidade definida nas
configurações iniciais do algoritmo, é decidido se a condição
ficará ativa (A) ou inativa (I).
Conforme relatado anteriormente, esta versão tem como
diferencial a possibilidade de trabalhar com qualquer tipo
de atributo, sendo este numérico ou categórico, possibilitando a leitura de bases com valores nominais e contı́nuos.
Para isso, foi desenvolvido um método intermediário, o qual
é executado sempre na leitura de bases ou comparação de
valores, para analisar a sequência de entrada de dados, assim tornando possı́vel o processo de “parser” dos valores, que
possibilitou determinar sua estrutura gramatical, evitando a
necessidade de realizar a discretização na base. Na geração
de regras iniciais passou a utilizar o método de operadores randômicos, o qual pode retornar os operadores igual
=, maior igual >= e menor igual <=, que foi modificado
para contemplar mais operadores. Com essas modificações,
tornou-se necessário criar condições randômicas para as variáveis também, onde é resgatado um valor aleatório dentro
de um intervalo de mı́nimo e máximo retirado da primeira
41
Tabela 1: Resumo dos conjuntos de dados utilizados no experimento. A primeira coluna (’Base
de dados’) define o nome da base de dados, a segunda coluna (’Trein.’) define o número de exemplos de treinamento, a terceira coluna (’Teste’) define o número de exemplos de teste, a quarta coluna
(’Atrib.’) define o número de atributos de cada base
e a quinta coluna (’Classes’) define o número de classes na classe hierárquica.
Base de Dados
Cellcycle
Church
Derisi
Trein.
2473
1627
2447
Teste
1278
1278
1272
Atrib.
77
27
63
Classes
4126
4126
4120
O desempenho dos resultados foi comparado utilizando as
medidas de precisã hierárquica (hP), revocação hierárquica
(hR) e Medida-hF (hF) proposto em [10]. Este método segue
o padrão das conhecidas medidas de Revocação, Precisão
e Medida – F, com as seguintes alterações: cada exemplo
pertence não somente a sua classe, mas também a todos os
ancestrais da classe em um gráfico hierárquico, exceto o nó
raiz.
Os experimentos foram realizados utilizando como procedimento o método de validação cruzada fator 10 e os resultados são descritos como valores-médios e desvio padrão.
Tabela 2: Valores das medidas hR, hP e hF obtidas
nos três conjuntos de dados.
Cellcyle
Church
Derisi
Cellcyle
Church
Derisi
HLCS-Multi
hP
hR
0.2611 ± 0.04 0.4209 ± 0.02
0.2259 ± 0.02 0.6183 ± 0.03
0.2948 ± 0.03 0.5655 ± 0.03
HLCS-MultiND
hP
hR
0.2052 ± 0.05 0.1803 ± 0.04
0.2048 ± 0.04 0.1800 ± 0.06
0.2042 ± 0.04 0.1798 ± 0.05
hF
0.3223 ± 0.03
0.3309 ± 0.04
0.3873 ± 0.03
hF
0.1919 ± 0.05
0.1916 ± 0.05
0.1912 ± 0.05
7.
De acordo com os testes, o HLCS – Multi mostrou melhores resultados do que o HLCS – MultiND nas três bases
analisadas. Porém, segundo [9], um fator importante para a
predição da função de proteı́nas, é que o modelo de predição desenvolvido, além de ser eficaz, deve ser compreensı́vel
o bastante para que os pesquisadores consigam analisar e
confiar nas predições recebidas. Sendo assim, a principal
vantagem do modelo HLCS – MultiND com relação a versão HLCS – Multi é a forma com o qual o modelo apresenta
os resultados gerados.
Um exemplo desta diferença pode ser visto na tabela 3.
Como o HLCS – Multi realiza o processo de discretização, as
regras geradas são imprecisas, pois utiliza intervalo de dados como valores dos atributos, dificultando o trabalho dos
pesquisadores. Entretanto no modelo proposto os resultados
são mais especı́ficos e fáceis de serem interpretados.
Tabela 3: Exemplo de Regras geradas pelos Algoritmos
Versão
HLCS – Multi
HLCS - MultiND
6.
cesso de discretização e aumentando o grau de confiabilidade
dos dados.
De acordo com os testes, os resultados apresentados pelo
algoritmo HLCS – Multi, ainda são melhores que os obtidos pelo HLCS – MultiND. Entretanto é importante deixar
claro que as regras criadas pelo algoritmo proposto, são mais
compreensı́veis para que os pesquisadores consigam analisar
e confiar nas predições recebidas. Acredita-se que através
de alguns ajustes neste modelo, é provável que se consiga
resultados parecidos ou até superiores.
Pretende-se também realizar testes com outros tipos de
base de dados para auxiliar no refinamento do algoritmo.
Exemplo Regra
SE cln3-1=(0.041-0.828) e
cln3-2=(-0.228-0.45) e
e...e clb2-2=(-0.528-0.268)
ENTÃO
Proteı́na é da classe GO0005634
SE cln3-1>=-0.828 e
cln3-2<=-0.15 e
e...e clb2-2>=-0.2158
ENTÃO
Proteı́na é da classe GO0005634
CONCLUSÃO
A contribuição dessa pesquisa foi apresentar um estudo
de caso de mineração de dados e o uso de técnicas de préprocessamento de dados em algoritmos de classificação de
proteı́nas, alterando o funcionamento do algoritmo HLCS
– Multi para uma nova versão chamada de HLCS - MultiND (Hierarchical Learning Classifier System Multilabel No
Discretizate). Esta versão foi desenvolvida para trabalhar
durante todas as etapas da extração do conhecimento com
qualquer tipo de atributo, sendo este numérico ou categórico, diminuindo a perda de informação causada pelo pro-
42
REFERÊNCIAS
[1] R. T. Alves, M. R. Delgado, and A. A. Freitas.
Multi-label hierarchical classification of protein
functions with artificial immune systems. pages 1–12,
2008.
[2] P. Balid and G. A. Pollastri. Machine-Learning
Strategy for Protein Analysis. IEEE Intelligent
Systems, 17, 2002.
[3] G. E. A. P. Batista. Pré-processamento de dados em
aprendizado de máquina supervisionado. PhD thesis,
Universidade de São Paulo, 2003.
[4] M. K. Campbell. Bioquı́mica. ArtMed, 2000.
[5] R. Cerri and A. C. P. L. F. Carvalho. New top-down
methods using svms for hierarchical multilabel
classification problems. In International Joint
Conference on Neural Networks, pages 1–8. IEEE,
2010.
[6] K. J. Cios, W. Pedrycz, R. W. Swiniarski, and L. A.
Kurgan. Data Mining: A Knowledge Discovery
Approach. Springer-Verlag New York, Inc., Secaucus,
NJ, USA, 2007.
[7] A. Clare and R. D. King. Predicting gene function in
saccharomyces cerevisiae. Bioinformatics, 19:42–49,
2003.
[8] U. M. Fayyad, G. Piatetsky-Shapiro, P. Smyth, and
R. Uthurusamy, editors. Advances in knowledge
discovery and data mining. American Association for
Artificial Intelligence, Menlo Park, CA, USA, 1996.
[9] A. A. Freitas, D. C. Wieser, and R. Apweiler. On the
importance of comprehensible classification models for
protein function prediction. IEEE/ACM Trans.
Comput. Biol. Bioinformatics, 7(1):172–182, Jan.
2010.
[10] S. Kiritchenko, S. Matwin, and A. F. Famili.
Functional annotation of genes using hierarchical text
categorization. In Proc. of the BioLINK SIG: Linking
Literature, Information and Knowledge for Biology
(held at ISMB-05, 2005.
[11] L. M. Romão. Classificação Global Hierárquica
Multirrotulo da Função de Proteı́nas Utilizando
Sistemas Classificadores. PhD thesis, Pontifı́cia
Universidade Católica do Paraná, 2012.
[12] L. M. Romão and J. C. Nievola. Hierarchical
Multi-label Classification Problems: An LCS
Approach. Advances in Intelligent Systems and
Computing, 373:97–104, 2015.
[13] C. Vens, J. Struyf, L. Schietgat, S. Džeroski, and
H. Blockeel. Decision trees for hierarchical multi-label
classification. Mach. Learn., 73(2):185–214, Nov. 2008.
Desenvolvimento da Técnica Data Mining Como Apoio à
Tomada de Decisão no Sistema Hidrológico para Geração
de Estatística das Estações de Telemetria da Defesa Civil
de Brusque – SC
Alternative Title: Development of Data Mining Techniques as
Support for Decision Making in the Hydrological System for
Statistics Production of the Telemetry Stations of the Emergency
Management in Brusque-SC
Jonathan Nau
Pedro Sidnei Zanchett
Wagner Correia
Centro Universitário de Brusque UNIFEBE
Rua Dorval Luz, 123
Brusque – SC - Brasil
[email protected]
Rua Dorval Luz, 123
[email protected]
Rua Dorval Luz, 123
[email protected]
Antonio Eduardo de Barros
Ruano
Marcos Rodrigo Momo
University of Algarve - Faro
Email: [email protected]
UNIFEBE
Rua Dorval Luz, 123
[email protected]
RESUMO
Palavras-Chave
A quantidade de informação dos sistemas hidrológicos cresce a
cada medição realizada pelas estações. Com um volume tão alto
de informações acaba ficando difícil extrair conhecimento
olhando só os dados. O processo de extração de conhecimento
(KDD) tem o objetivo de auxiliar a extração do conhecimento a
partir de grandes bases de dados. Pensando em facilitar a
extração de conhecimento das grandes bases do sistema
hidrológico elaborou-se este projeto de pesquisa que visa
implantar o processo KDD para geração de estatísticas das
estações de telemetria mantidas pela defesa civil de Brusque –
SC, com base em dados de níveis de chuva e do rio em Brusque
e região oferecendo apoio a decisão estratégica. Através do Data
Mining utilizando-se o modelo cubo de decisão por associação
será possível extrair diversas visões à gestão de negócio,
transformando-se numa ferramenta de ajuda para ganho de
tempo no controle e prevenção à enchentes com antecipação e
segurança à população. A decisão baseada no conhecimento
extraído das grandes bases será mais assertiva, desta forma as
informações passadas para toda a população terá algum grau de
confiança e não precisam mais serem baseadas em inferências
das pessoas que possuem a base de dados em mãos.
Sistema de informação; Processo KDD; Data Mining.
Estatística.
ABSTRACT
The amount of information of hydrological systems grows each
measurement performed by the seasons. With such a high volume
of information ends up being difficult to extract knowledge just
looking at the data. The KDD process is intended to assist the
extraction of knowledge from large databases. Thinking about
facilitating the extraction of knowledge from large bases of the
hydrological system elaborated a work based on the KDD
process in an attempt to mine the data of hydrological systems
and extract knowledge to aid in decision making. A decision
based on knowledge extracted from large databases will be more
assertive in this way the information passed to the entire
population will have some degree of confidence and no longer
need to be based on inferences of the people who have the hands
on the database.
Keywords
Information System; KDD process; Data Mining. Statistic.
General Terms
Experimentation and Database Management.
Copyright SBC 2016.
E.2 Data Storage Representations. G.3 Probability and
Statistics: Statistical software. H. Information Systems: H. 2.8.
Database Applications: Data mining.
43
se definir como problemas as enchentes a ser analisado para uma
correta tomada de decisão. Na segunda fase o passo é realizar a
criação de um conjunto de dados que serão preparados para
posteriormente serem minerados. Utilizar-se-á três dados para a
mineração, que neste caso é o nível do rio, o nível de chuva e a
vazão do rio. Estes três dados serão importantes para a extração
de conhecimento de uma base de dados do sistema hidrológico.
1. INTRODUÇÃO
A cada dia que passa o volume de informação cresce
exponencialmente, obrigando o desenvolvimento de técnicas e
ferramentas que facilitem a busca e manipulação de todos esses
dados armazenados. A mineração de dados é uma tecnologia que
combina métodos tradicionais de análise de dados com algoritmos
sofisticados para processar grandes volumes de dados” [2].
A limpeza e o processamento dos dados serão trabalhados na
terceira fase do processo KDD. Nesta fase serão eliminados
ruídos dos dados que podem afetar a qualidade do conhecimento
extraído da base de dados. Como no sistema hidrológico os dados
são coletados automaticamente pelas estações de coleta, a
possibilidade de haver erros na leitura dos sensores é alta. Os
erros que ocorrem na leitura dos sensores são tratados como
ruídos no processo KDD e podem levar a uma conclusão
precipitada dos padrões identificados, devido a isso os ruídos
precisam ser eliminados. Por exemplo, nos dados armazenados
pela defesa civil de Brusque se possui muitos meses desde 1912
com falhas nas informações históricas coletadas, essas
informações primeiramente precisam ser tratadas para então se
prosseguir.
O sistema hidrológico de Brusque gera muita informação através
das estações de telemetria que se localizam ao longo do rio Itajaí
Mirim, os sensores das estações captam o volume de chuva e o
nível do rio. Apesar de serem captadas apenas duas variáveis o
volume de informação é gigantesco devido a captura dos dados
ser em questão de minutos.
“Dados de nível de rios usados para controle de cheias podem
demandar a coleta e transmissão de dados a cada 10 minutos” [3].
Devido à grande quantidade de informação gerada pelas estações
de telemetria da defesa civil de Brusque, é fundamental adotar
técnicas de mineração de dados para identificar padrões e
anomalias que antes passavam despercebidas e que agora podem
ajudar na tomada de decisão, como por exemplo alertar a
população de uma possível enchente.
Nas figuras 02 e 03 observa-se claramente o ruído causado por
uma estação de telemetria da defesa civil de Brusque. A imagem
mostra que em dois horários a estação captou valores acima de
três mil milímetros de chuva, logo depois o nível caiu para zero e
o nível do rio não teve alteração em nenhum momento. Estes
ruídos vão precisar ser corrigidos pois afetam diretamente na
extração de conhecimento da base de dados, apenas esses dois
valores causam uma variação enorme no nível de chuva do mês
em questão.
No momento a defesa civil de Brusque, não utiliza base de dados
históricas das estações de telemetria para tomada de decisões e
prestar orientações a sua população. As informações repassadas
são somente dos dados atualizados das estações. Esta pesquisa
teve por objetivo elaborar e aplicar técnicas de mineração de
dados na base de dados histórico da defesa civil para extrair
conhecimento que antes não se dava atenção e que agora podem
ser usados no processo de tomada de decisão.
2. METODOLOGIA DE EXTRAÇÃO DE
INFORMAÇÕES HIDROLÓGICAS
O processo de extração de dados é conhecido pela sigla KDD
(knowledge-discovery in databases). O conceito deste processo se
trata da extração de dados de uma grande base de dados, a fim de
identificar padrões para adquirir conhecimento.
A extração de conhecimento de uma base de dados consiste em
duas grandes fases. A primeira trata da preparação dos dados, que
consiste em selecionar os dados que serão utilizados onde faz a
limpeza e a projeção destes dados. Já a segunda etapa trata da
mineração dos dados, se faz a escolha dos algoritmos e tarefas de
mineração, a interpretação de padrões e a consolidação do
conhecimento descoberto. Na figura 1 pode-se observar as fases
do processo KDD mais detalhadamente.
Figura 2. Ruído de dados.
Figura 1. Etapas do processo KDD [1]
2.1 ETAPAS DO PROCESSO KDD
Na primeira etapa é definida quais tipos de informação será
extraída de uma base de dados. Para o sistema hidrológico pode-
44

Classificação: Classes de objetos são criadas para agrupar
objetos com características semelhantes. São utilizados
dados sobre o passado de determinada base para encontrar
padrões com valores significativos, aos quais irão levar a
regras sobre o futuro destes objetos.

Clusterização: Os dados heterogêneos são reagrupados em
grupos com características semelhantes, método conhecido
como clustering. A clusterização é a tarefa de segmentar uma
população heterogênea em um número de subgrupos (ou
clusters) mais homogêneos possíveis, de acordo com alguma
medida. O que diferencia a clusterização da classificação é a
não existência de grupos pré-definidos.
No sexto passo será escolhido os algoritmos de mineração de
dados. Os métodos selecionados para serem utilizados no sistema
hidrológico foram algoritmo associação, algoritmo de regressão
linear e algoritmo clusterização.
Descobrir o conhecimento oculto nas grandes bases de dados das
mais diversas organizações, seja de forma automática ou
semiautomática é o objetivo do Data Mining. Trata-se de um
processo da extração de padrões, considerados interessantes e não
corriqueiros, a partir de uma base de dados permitindo de forma
ágil e rápida a tomada de decisões.
Figura 3. Ruído de dados.
A correção dos dados é feita de maneira para acrescentar mais um
campo ao final da tabela, para que na mineração dos dados o
algoritmo saiba quais os dados que estão incorretos. Desta forma
além de eliminar os ruídos é possível treinar também o algoritmo
de forma que ele identifique os novos valores que estão sendo
registrados na base de dados, que com isso é possível garantir a
integridade dos dados e saber quando uma estação está
apresentando defeitos.
Isto vem ao encontro de Cardoso e Machado [4] que definem o
Data Mining como uma técnica que faz parte de uma das etapas
da descoberta de conhecimento em banco de dados. Ela é capaz
de revelar, automaticamente, o conhecimento que está implícito
em grandes quantidades de informações armazenadas nos bancos
de dados de uma organização. Essa técnica pode fazer, entre
outras, uma análise antecipada dos eventos, possibilitando prever
tendências e comportamentos futuros, permitindo aos gestores a
tomada de decisões baseada em fatos e não em suposições.
A quarta fase trata-se da redução e projeção dos dados, é mais
conhecida como transformação dos dados. Os dados precisam ser
armazenados e formatos de forma que os algoritmos consigam ser
aplicados e os dados possam ser minerados. Conforme figura 04
se utilizará apenas uma tabela com alguns campos (somente
números), para facilitar no momento da mineração dos dados. A
tabela vai conter como campos o código da estação de coleta, o
horário que foi realizado a coleta, os valores do nível do rio e das
chuvas.
A mineração de dados começa efetivamente no sétimo passo.
Nesta fase se irá minerar os dados na tentativa de identificar os
padrões de interesse, os interesses são necessários antes de
começar a mineração dos dados. Um interesse seria a previsão do
nível do rio nas horas seguintes, seria interessante também quais
são os meses que o risco de cheias aumenta, relação entre
quantidade chuva e nível do rio.
A tabela 01 demonstra a utilização do algoritmo EM
(expectation–maximization algorithm ou algoritmo de estimação
de máxima) para minerar dados dos níveis da chuva durante os
meses do ano. O algoritmo EM faz parte da técnica de mineração
conhecida como clusterização, o algoritmo é ideal para quando os
dados são realmente incompletos, quando existe perda de um
intervalo de dados na base de dados.
Figura 4. Dados utilizados
A próxima grande etapa é a de mineração dos dados, esta grande
fase é composta por quatro fases menores, que vão desde a
escolha de tarefas de mineração até a consolidação do
conhecimento descoberto por meio da base de dados selecionada
anteriormente.
Tabela 1. Mineração de dados da chuva
Na quinta fase vamos escolher quais serão as tarefas de mineração
que vão ser utilizadas. Nesta etapa se decide qual será o objetivo
dos processos de mineração dos dados, os mais comuns são os de
classificação, regressão e clusterização. No sistema hidrológico
vamos utilizar as três tarefas de mineração.
Segundo autores as três técnicas mais comuns no processo KDD
são:

Associação: Tem por objetivo a combinação de itens
considerados importantes, sendo que a presença de tal item
indica implicitamente na presença de outro item na mesma
transação. Este processo teve como precursor Agrawal, em
1993 [1].
45
Portanto ao utilizar o algoritmo M5RULES se queria criar regras
na tentativa de modelar a forma como se comporta o rio. Na
mineração dos dados se obteve as cinco regras, que serão
exploradas abaixo:
IF
Nível do rio em Botuverá <= 1.226
Nível do rio em Botuverá > 0.559
THEN
Nível do rio em Brusque =
-0 * Acumulado de chuva em Botuverá
+ 0.0308 * Nível do rio em Botuverá
+ 1.3311 [251/57.511%]
Figura 5. Primeira regra.
IF
THEN
-0.0001 * Acumulado de chuva em Botuverá
+ 1.0899 [466/68.005%]
A oitava fase é a interpretação dos dados obtidos por meio da
mineração de dados. A técnica do algoritmo EM consistiu em
dividir os dados em três cluster, cada cluster representa uma
massa de dados. O cluster 1 por exemplo representa apenas 2%
dos dados analisados, que correspondem a dezesseis meses em
que a precipitação de chuva chegou em aproximadamente 112
milímetros de chuva, com desvio padrão de 19 milímetros. Nele
ainda se observa que alguns meses tiveram mais ocorrência que
outros, como por exemplo, o mês de março com três ocorrências
e os meses de fevereiro e abril com duas ocorrências cada. Por sua
vez no cluster 2 temos uma média de 63 milímetros de
precipitação da chuva, este cluster possui um percentual de
ocorrência no valor de 30% e são destaques os meses de fevereiro,
março, setembro e dezembro. Por fim a precipitação que mais
ocorre em Brusque com 68% de ocorrência fica na média de 29
milímetros, com os meses de maio a agosto em destaque.
Figura 6. Segunda regra;
IF
THEN
0.0203 * Nível do rio em Botuverá
+ 1.4469 [192/55.59%]
Figura 7. Terceira regra
IF
THEN
-0.003 * Acumulado de chuva em Botuverá
- 0.121 * Nível do rio em Botuverá
+ 1.8809 [57/54.89%]
Esses dados mostram quais as possíveis eventualidades que
podem ocorrer durante o ano, por exemplo, o mês de agosto é
mais assertivo falar que as medias de precipitação da chuva vão
ficar em torno de 19 a 49 milímetros, pois sua a ocorrência dessa
media para esse mês é muito maior do que para as demais medias.
Figura 8. Quarta regra.
- 0.0254 * Acumulado de chuva em Botuverá
- 0.2767 [15/72.772%]
Outra mineração feita foi utilizando o algoritmo M5RULES [5],
que utilizou dados da estação de Botuverá e da estação de
Brusque. Os dados utilizados da estação de Botuverá foram o
acumulado de chuva do dia e a média do nível do rio também para
o dia, já na estação de Brusque foi apenas utilizado a média do rio
no dia.
Figura 9. Quinta regra.
O nono e último passo é a consolidação do conhecimento
descoberto. Nesta fase irá incorporar os resultados nos sistemas,
nas documentações necessárias e nos relatórios para quem se
interessar. Neste ponto também se faz aferições de conflitos e a
resolução dos mesmos por meio do conhecimento extraído.
O algoritmo funciona da seguinte forma: uma árvore de
aprendizado é aplicada sobre todo o conjunto de treinamento e
uma árvore podada é aprendida. Em seguida, a melhor
ramificação (de acordo com alguma heurística) gera uma regra e
a árvore é descartada. Todas as instâncias cobertas pela regra são
removidas do conjunto de dados, e o processo é aplicado de modo
recursivo para os exemplos restantes até que todas as instâncias
sejam cobertas por uma ou mais regras. Ao invés de criar uma
única regra de aprendizagem, constrói-se um modelo de árvore
completo em cada fase e faz-se da melhor ramificação uma nova
regra [6].
Para consolidar as regras propostas pelo algoritmo M5RULES é
necessário apenas ter os valores, utilizar as regras para realizar os
cálculos e chegar ao resultado final. Tem-se por exemplo o
seguinte conjunto de dados nível do rio em Botuverá com 0,66
metros, um volume de chuva no valor de 0,00 milímetros e o nível
do rio em Brusque com 1,38 metros. Utilizando a primeira regra
para o conjunto de informações chega-se a o valor aproximado de
1,351428 metros, que fica muito próximo ao valor esperado de
1,38 metros.
46
A primeira grande fase demanda mais tempo no processo KDD,
geralmente fica em torno de 80% do trabalho realizado durante a
extração do conhecimento de uma base de dados. As etapas que
foram descritas também podem ser repetidas durante a extração,
apesar de ser apresentado uma sequência para a extração dos
dados a mesma pode ser alterada conforme necessidade, também
é possível voltar para alguma etapa anterior caso seja necessário,
é aconselhável voltar para evitar erros na consolidação do
conhecimento.
[4]. CARDOSO, O. N. P., MACHADO, R. T. M. Gestão do
conhecimento usando data mining: estudo de caso na
Universidade Federal de Lavras. Revista de
Administração Pública. Rio de Janeiro 42(3): 495-528,
Maio/Jun. 2008.
[5] ALBERG, D.; LAST, M.; KANDEL, A. Knowledge
discovery in data streams with regression tree methods,
2011.
[6]. HOLMES, G.; HALL, M.; FRANK, E. Generating Rule
Sets from Model Trees. In: Twelfth Australian Joint
Conference on Artificial Intelligence, 1999.
3. CONCLUSÕES E TRABALHOS
FUTUROS
A técnica Data Minning contribui para extração precisa e
inteligente dos dados obtidos pelas estações de telemetria do
município de Brusque SC, mantidas pela Defesa Civil para
análise dos problemas ocorridos com cheias, fornecendo
informações de apoio à decisão para técnicos da área e população
em geral, de forma simples e rápida.
Com este trabalho conseguiu-se exibir os meses em que mais
ocorre chuva e quais são os meses mais propícios para chuva
durante o ano, com essa informação é possível verificar os meses
de risco, planejar as estratégias durante o ano e disponibilizar a
informação para a população. Também foi possível com este
trabalho a criação de regras para inferir o nível do rio na cidade
de Brusque a partir dos dados da estação da cidade vizinha
Botuverá.
No sistema hidrológico de Brusque as técnicas de mineração de
dados para extração de conhecimento foram utilizadas pela
primeira vez com esse trabalho, o que resulta em um grande
avanço para a cidade e para a população. Mesmo exibindo algum
resultado ainda é necessário mais estudo na aérea de Data Mining
com foco nos sistemas hidrológicos. A utilização das redes
neurais se mostra interessante para ampliar mais este trabalho,
pois com as redes neurais consegue-se modelar a bacia do rio
Itajaí Mirim de forma a utilizar todas as estações disponíveis ao
longo do rio e saber com precisão qual o nível do rio na última
estação. As redes neurais também permitem que os novos dados
sejam validados a partir dos ruídos que já foram encontrados.
4. AGRADECIMENTOS
Este trabalho de Iniciação Científica teve o apoio da Secretaria de
Estado da Educação de Santa Catarina, através da concessão de
bolsas com recursos do Artigo 170 da Constituição Estadual, para
os alunos de graduação regularmente matriculados na UNIFEBE.
5. REFERÊNCIAS
[1]. AGRAWAL, R.; IMIELINSKI, T.; SWAMI, A. Mining
associations between sets of items in massive databases.
ACM-SIGMOD, 1993. Proceedings... Int’l Conference on
Management of Data, Washington D.C., May 1993.
[2] . ANTUNES, J. F. G.; OLIVEIRA, S. R. M.; RODRIGUES,
L. H. A. Mineração de dados para classificação das fases
fenológicas da cultura da cana-de-açúcar utilizando
dados do sensor modis e de precipitação. VIII Congresso
Brasileiro de Agroinformática. Bento Gonçalves, 2011.
[3]. BLAINSKI, É.; GARBOSSA, L. H. P.; ANTUNES, E. N.
Estações hidrometeorológicas automáticas: recomendações
técnicas
para
instalação.
Disponível
em:
<http://ciram.epagri.sc.gov.br/recomendacoes_tecnicas_par
a_instalacao_de_estacoes.pdf >. Acesso em: 25 fev. 2016.
47
Uma arquitetura de banco de dados distribuído para
armazenar séries temporais provenientes de IoT
Alternative title: A distributed database architecture to store time series from IoT
Fernando Paladini
Federal University of Santa
Catarina
Florianópolis, Brazil
[email protected]
Caique R. Marques
Catarina
[email protected]
Antônio Augusto Fröhlich
Lucas Wanner
UNICAMP
Campinas, Brazil
[email protected]
Catarina
[email protected]
RESUMO
O crescimento das redes de sensores sem fio (WSN) e dos
sistemas de monitoramento de ambientes têm gerado dados
organizados em séries temporais. Bancos de dados relacionais não são ideais para o armazenamento de dados organizados em séries temporais. Como alternativa, apresentamos
uma solução usando um banco de dados distribuı́do especı́fico para séries temporais provenientes de redes de sensores
sem fio. Durante 5 meses um sistema de monitoramento real
coletou e armazenou medições em diferentes grandezas utilizando a arquitetura proposta. A arquitetura mostrou ser
capaz de armazenar milhões de séries temporais, sendo um
ambiente confiável para inserções e consultas; assim abrindo
caminho para análise de dados com ferramentas como o Apache Spark.
Palavras-Chave
Big data; internet of things; database; time series; WSN;
ABSTRACT
The increasing interest in wireless sensor networks (WSN)
and monitoring systems has generating measurements organized as time series. Relational databases are not recommended to store time series data. As an alternative, we propose a solution using a specific distributed database for time
series from wireless sensor network. During five months, a
real monitoring system collected and stored measurements
in different physical quantities using the proposed architecture. The architecture showed to be able to store millions
of time series, being a trustful environment to insertions
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SBSI 2016, May 17th-20th, 2016, Florianópolis, Santa Catarina, Brazil
Copyright SBC 2016.
48
and queries; making possible to analyze data using tools
like Apache Spark.
C.2.4 [Distributed Systems]: Distributed databases; G.3
[Probability and Statistics]: Time series analysis
Keywords
Big data; internet of things; database; time series; WSN;
1.
INTRODUÇÃO
Com o aumento do interesse em Internet das Coisas (IoT)
e Redes de Sensores Sem Fio (WSN), sistemas de monitoramento de ambientes têm surgido [18, 19, 16] e gerado um
grande número de medições em um curto perı́odo de tempo,
tornando-se importante para áreas relacionadas à indústria
[17] e ao meio ambiente [5]. As medições podem ser feitas sobre diversas grandezas, tais como temperatura, umidade, turbidez da água, consumo de energia, presença, etc..
Embora não seja possı́vel prever que tipos de medições serão realizadas, os dados medidos geralmente são organizados como séries temporais (time series), que são sequências
de observações sobre uma grandeza realizadas ao longo do
tempo. Como os sensores realizam medições periódicas em
intervalos de tempo que podem variar de milissegundos até
dias (de acordo com o ambiente), vários dados podem ser
gerados todos os dias. Banco de dados relacionais tradicionais baseados em arquitetura scale-up e SQL, tais como
MySQL e PostgreSQL, não escalam bem com as séries temporais geradas por essas plataformas de monitoramento [2]
por oferecerem recursos que não são otimizados para séries
temporais. Por exemplo, uma vez que dados de séries temporais são observações realizadas em um determinado instante
de tempo, não é necessário modificar valores passados, desta
forma, utilizar um banco de dados que suporta operações de
alteração de valores (update) é desnecessário.
Para solucionar o problema de escalabilidade para suportar melhor o armazenamento de séries temporais provenientes de redes de sensores sem fio é proposto um banco de
Figura 1: Funcionamento do sistema de monitoramento.
dados distribuı́do especı́fico para séries temporais.
A seção 2 apresenta uma análise sucinta do ambiente utilizado na coleta das séries temporais; a seção 3 descreve a
arquitetura utilizada; a seção 4 mostra alguns resultados que
puderam ser observados a partir da arquitetura utilizada e,
por fim, a seção 5 apresenta as conclusões obtidas através
da arquitetura apresentada para o problema descrito.
Tabela 1: Tipos de sensores do Smart Solar Building.
Variável
Unidade
Presença
Booleano (1 ou 0)
Temperatura
Graus Celsius (◦ C)
Luminosidade
Luminosidade (%)
Ar condicionado
Watts (W)
Consumo das tomadas
Watts (W)
2. ANÁLISE DO AMBIENTE
O prédio Smart Solar Building, da Universidade Federal
de Santa Catarina (UFSC), possui 31 sensores EPOSMote[4]
que somados observam 5 grandezas (temperatura, luminosidade, presença, consumo das tomadas e consumo dos ar
condicionados) e são responsáveis pelo monitoramento e automação das instalações. A coleta de dados realizada por
esses sensores tem como objetivo: (a) o monitoramento e
a supervisão do prédio; e (b) posterior análise dos dados
mensurados afim de criar uma automação inteligente para o
prédio.
Utilizando o sistema operacional EPOS[3] e o protocolo
TSTP[15], os EPOSMote reportam as medições realizadas
para um gateway, que tem como função se comunicar com
um software SCADA (responsável pelo monitoramento e supervisão dos sensores) e também enviar as medições para um
banco de dados, onde uma futura mineração e análise de dados poderá ser realizada. Uma visão geral do funcionamento
do sistema de monitoramento pode ser visto na Figura 1.
Cada grandeza é medida por um sensor em intervalos de
tempo que variam de 1 a 60 segundos, o que significa que
os 31 sensores no Smart Solar Building podem gerar cerca
de 110 mil medições em apenas 1 hora de observação. De
maneira similar, algumas dezenas de sensores podem gerar
dezenas de milhões de medições em 1 mês de observação.
Desta forma o banco de dados que armazenará as medições
precisa ser robusto, suportar bilhões de registros e uma ingestão elevada de dados por segundo. Os dados em formato
de série temporal raramente serão atualizados e têm de ter
registros que contenham, no mı́nimo, alguma marcação de
tempo[2]. Com isso, um sistema de gerenciamento de banco
de dados (SGBD) relacional pode possuir diversas operações desnecessárias, oferecendo, por exemplo, as operações
de update, transações entre dados e não armazenando uma
marcação de tempo por padrão (necessitando o uso de ı́ndices especı́ficos). Uma alternativa ao relacional é necessária.
3. ARQUITETURA
A arquitetura do Smart Solar Building começa com a
49
coleta de dados através de uma rede de sensores sem fio
(WSN) composta por EPOSMotes, que se comunicam com
um EPOSMote especı́fico conectado a um computador (ao
qual chamamos de Gateway). O computador possui um servidor que recebe os dados via MODBUS e os estrutura para
serem enviados via HTTP para (1) um software SCADA
(ScadaBR) e (2) um banco de dados. Porém, antes de os
dados chegarem ao banco de dados é necessário realizar algumas conversões de acordo com o tipo de dado recebido
(temperatura, luminosidade, etc.), pois o dado medido normalmente não se encontra na unidade desejada. Essa conversão pode ser feita de duas maneiras: (a) no momento
da medição do dado, utilizando o dispositivo que o mensurou; e (b) em algum momento na cadeia de armazenamento
do dado, utilizando algum computador ou servidor mais robusto. Como operações em ponto flutuante são muito caras
para um dispositivo de Internet das Coisas e estes primam
por economia de energia, escolhemos realizar a conversão
dos dados em algum momento na cadeia de armazenamento
do dado, o que é feito por um programa denominado Lehder
[11]. O Lehder é uma API intermediária entre o Gateway e
o banco de dados, sendo responsável por receber os dados
do Gateway (via HTTP), convertê-los e enviar os dados já
convertidos para o banco de dados.
Devido às caracterı́sticas das séries temporais e os problemas descritos, um banco de dados especı́fico para séries
temporais, distribuı́do e robusto é desejado. Além disso, um
banco de dados que esteja preparado para Big Data também garante a escalabilidade necessária para numerosas e
esparsas redes de sensores sem fio, o que pode ser necessário
de acordo com o ambiente envolvido. Entre as opções de
banco de dados com essas caracterı́sticas estão o InfluxDB
[6], OpenTSDB [13], KairosDB [8], Prometheus [14] e outros
bancos de dados mais recentes e menores, como Warp10 [1],
Newts [12], etc..
Para a nossa arquitetura escolhemos o KairosDB, que consiste de uma interface que utiliza o Apache Cassandra como
banco de dados, otimizando-o para armazenamento de séries
Figura 2: Número de medições diárias feitas por sete sensores do Smart Solar Building.
Figura 3: Número de medições realizadas por hora em 2 de março de 2016 no Smart Solar Building.
Figura 4: Arquitetura do Smart Solar Building.
temporais. A escolha se deu justamente pelo KairosDB utilizar o Apache Cassandra como banco de dados, que é um dos
mais confiáveis e robustos banco de dados preparados para
Big Data [7]. O KairosDB fornece uma API HTTP para
ingestão e consulta de dados, de forma que a comunicação
com o Lehder é realizada via HTTP.
Uma visão geral da arquitetura descrita do Smart Solar
Building pode ser vista na Figura 4. A tabela 1 mostra os
tipos de sensores (ou variáveis medidas) existentes no Smart
Solar Building.
2015 e o último em 3 de março de 2016. O número de medições realizadas está abaixo do previsto, pois o prédio ainda
está em ambiente de teste, onde erros relacionados à indisponibilidade de rede, às falhas nos sensores, à configuração
do ambiente e na falta de energia criaram intervalos consideráveis de tempo onde nenhuma medição pôde ser realizada.
Um gráfico exibindo quantas medições cada sensor realizou por dia (similar à Figura 2) foi disponibilizado online [9].
É importante notar que cada uma das 7 variáveis da Figura
2 são medidas por um e apenas um sensor, portanto ”Temperatura 1”não é o número de medições de todos os sensores
de temperatura, mas sim o número de medições realizado
por um único sensor. Como é possı́vel observar na Figura 2,
o número de medições realizadas pelos sensores varia consideravelmente, mas em tempos de estabilidade se mantêm
no intervalo de 3 mil a 9 mil medições por dia. Enquanto
isso, a média de medições realizadas por dia ao longo de 5
meses (”Avg”) gira em torno de 5 mil medições por dia. É
possı́vel notar através da Figura 3 (também disponı́vel online [10]) que a ingestão de dados a cada hora não é muito
alta, ficando na média de 302.8 medições por hora.
Alguns problemas de instabilidade no banco de dados foram encontrados durante os meses de teste da arquitetura,
mas todos estavam relacionados a má configuração do Apache Cassandra e limitações fı́sicas, como por exemplo falta
de memória RAM.
5.
4. RESULTADOS
Com o ambiente configurado conforme a arquitetura descrita acima, pudemos armazenar 14.113.192 medições ao
longo de 5 meses de funcionamento do Smart Solar Building,
com o primeiro dado sendo armazenado em 20 de setembro
50
CONCLUSÃO
O crescimento do interesse em Internet das Coisas (IoT) e
Redes de Sensores Sem Fio (WSN) tem se tornado evidente
nos últimos anos e a criação de produtos baseados nessas
tecnologias é inevitável. Bancos de dados relacionais tradicionais não estão preparados para tal cenário, fazendo-se ne-
cessário o uso de bancos de dados especı́ficos para o problema
de armazenamento de dados provenientes de WSN. Com a
arquitetura apresentada foi possı́vel otimizar um problema
de armazenamento de milhões de medições em um banco
de dados distribuı́do e especı́fico para séries temporais. Embora uma elevada ingestão de dados não tenha sido obtida, a
arquitetura se mostrou estável durante as inserções e consultas realizadas (inclusive com testes preliminares utilizando
o Apache Spark para realizar análise dos dados). Concluise, portanto, que a arquitetura proposta pôde suportar um
ambiente onde milhões de medições serão feitas sem grandes
problemas, entretanto maiores testes precisam ser realizados
para descobrir se a arquitetura consegue escalar para bilhões
de medições.
Para trabalhos futuros é pretendido: (1) testar a arquitetura descrita com uma ingestão de dados mais elevada,
podendo chegar a bilhões de medições; (2) integrar a arquitetura com ferramentas de processamento de dados paralelas, tais como Apache Spark, e realizar mineração de dados
sobre os dados coletados; (3) armazenar dados de sensores
utilizando geolocalização ao invés de associar medições com
um sensor especı́fico.
6.
[11]
[12]
[13]
[14]
[15]
[16]
REFERÊNCIAS
[1] C. Data. Site oficial do Warp10.
http://www.warp10.io/. [Online; acessado em
26-Fevereiro-2016].
[2] T. Dunning and E. Friedman. Time Series Databases:
New Ways to Store and Access Data, pages 25–36.
O’Reilly Media, 2014.
[3] A. A. Fröhlich and W. Schröder-Preikschat. EPOS: an
Object-Oriented Operating System. In 2nd ECOOP
Workshop on Object-Orientation and Operating
Systems, volume CSR-99-04 of Chemnitzer
Informatik-Berichte, pages 38–43, Lisbon, Portugal,
June 1999.
[4] A. A. Fröhlich, R. Steiner, and L. M. Rufino. A
Trustful Infrastructure for the Internet of Things
based on EPOSMote. In 9th IEEE International
Conference on Dependable, Autonomic and Secure
Computing, pages 63–68, Sydney, Australia, Dec. 2011.
[5] J. K. Hart and K. Martinez. Environmental sensor
networks: A revolution in the earth system science?
Earth-Science Reviews, 78:177–191, 10 2006.
[6] InfluxData. Site oficial do InfluxDB.
http://influxdata.com/. [Online; acessado em
26-Fevereiro-2016].
[7] T. Ivanov, R. Niemann, S. Izberovic, M. Rosselli,
K. Tolle, and R. V. Zicari. Performance evaluation of
enterprise big data platforms with hibench. In IEEE
Trustcom/BigDataSE/ISPA, pages 120–127, Helsinki,
Finland, August 2015. IEEE.
[8] KairosDB. Site oficial do KairosDB.
http://kairosdb.org/. [Online; acessado em
26-Fevereiro-2016].
[9] LISHA. Contador de medições (dia a dia).
https://iot.lisha.ufsc.br:3000/dashboard/db/
wicsi-contador-de-medicoes-dia-a-dia?from=
1444979068656&to=1457060399999. [Online; acessado
em 23-Março-2016].
[10] LISHA. Contador de medições (hora a hora).
https://iot.lisha.ufsc.br:3000/dashboard/db/
51
[17]
[18]
[19]
wicsi-contador-de-medicoes-hora-a-hora?from=
1456887600000&to=1456973999999. [Online; acessado
em 03-Março-2016].
LISHA. Repositório Git Lehder.
https://gitlab.com/lisha/lehder/. [Online;
acessado em 29-Fevereiro-2016].
Newts. Site oficial do Newts. http://newts.io/.
[Online; acessado em 26-Fevereiro-2016].
OpenTSDB. Site oficial do OpenTSDB.
http://opentsdb.net/. [Online; acessado em
26-Fevereiro-2016].
Prometheus. Site oficial do Prometheus.
http://prometheus.io/. [Online; acessado em
26-Fevereiro-2016].
D. Resner and A. A. Fröhlich. Design Rationale of a
Cross-layer, Trustful Space-Time Protocol for Wireless
Sensor Networks. In 20th IEEE International
Conference on Emerging Technologies and Factory
Automation (ETFA 2015)., pages 1–8, Luxembourg,
Luxembourg, Sept. 2015.
R. Rushikesh and C. M. R. Sivappagari. Development
of iot based vehicular pollution monitoring system. In
International Conference on Green Computing and
Internet of Things (ICGCIoT), pages 779–783. IEEE,
October 2015.
A. Tiwari, P. Ballal, and F. L. Lewis. Energy-efficient
wireless sensor network design and implementation for
condition-based maintenance. ACM Transactions on
Sensor Networks (TOSN), 3, 3 2007.
C. Xiaojun, L. Xianpeng, and X. Peng. Iot-based air
pollution monitoring and forecasting system. In
International Conference on Computer and
Computational Sciences (ICCCS), pages 257–260.
IEEE, January 2015.
J. Zambada, R. Quintero, R. Isijara, R. Galeana, and
L. Santillan. An iot based scholar bus monitoring
system. In IEEE First International Smart Cities
Conference (ISC2), pages 1–6. IEEE, October 2015.
Utilização e Integração de Bases de Dados Relacionais
por meio de Foreign Tables para utilização em
ferramentas OLAP.
Alternative Title: Utilization and Integration Database Relational
by means of Foreign Tables for utilization in OLAP tools.
Felipe Igawa Moskado, André Menolli, Glauco C. Silva, Ricardo G. Coelho, Luan S. Melo
Universidade Estadual do Norte do Paraná – UENP
Centro de Ciências Tecnológicas
Rod. Br 369 Km 64
[email protected], {menolli,glauco,rgcoelho}@uenp.edu.br,[email protected]
RESUMO
Os ambientes de Business Intelligence auxiliam os
administradores das empresas a tomarem decisões mais precisas
sobre o seu negócio. Estes ambientes normalmente utilizam o
Data Warehouse que é um banco de dados integrado e voltado à
consulta. No entanto, a implantação de um DW é muito cara e
demorada, sendo um grande obstáculo, principalmente para
pequenas e médias empresas. De forma a tentar minimizar estes
problemas foi proposta a metodologia Agile ROLAP, que visa
auxiliar na utilização de ferramentas OLAP a partir das bases
relacionais das empresas. No entanto, a fim de não utilizar
diretamente a base de dados original e integrar diferentes bases,
propõe-se um mecanismo intermediário que utilize a tecnologia
Foreign Data Wrapper. Assim este trabalho apresenta o
desenvolvimento de plugins para a ferramenta Kettle que auxilie
na criação de Foreign Tables e na integração de dados.
H.2.4 [Database Management]: Systems – Distributed databases.
H.2.7 [Database Management]: Database Administration – data
warehouse and repository.
General Terms
Algorithms, Management, Security.
Keywords
Foreign Data Wrapper, Agile ROLAP, Data Warehouse, Business
Intelligence.
1. INTRODUÇÃO
As empresas com o decorrer do tempo armazenam uma grande
quantidade de informações sobre o seu negócio, e no intuito de
utilizar as informações adquiridas no decorrer do tempo, muitas
fazem uso de ambientes de Business Intelligence (BI). Estes
ambientes de BI auxiliam na análise dos dados de forma eficiente
e na tomada de decisão dos administradores da organização,
facilitando também o conhecimento sobre o seu negócio.
Palavras-Chave
Foreign Data Wrapper, Agile ROLAP, Data Warehouse, Business
Intelligence.
ABSTRACT
The Business Intelligence environments assists the companies
administrators take more accurate decisions about your
businesses. These environments normally use the Data
Warehouse, which is an integrated database and prepared for
query. However, the implementation of a DW is very expensive
and times consuming, and a great obstacle, mainly for small and
medium enterprises. In order to try to minimize these problems
was proposed the Agile ROLAP methodology, which aims to help
in the use of OLAP tools from relational databases of companies.
However, in order to not use directly the original database and
integrate different databases, it is proposed an intermediate
mechanism that uses the Foreign Data Wrapper technology. Thus,
this work presents the development of plugins for Kettle tool that
assists in the creation of Foreign Tables and data integration.
A implementação de BI não é algo trivial, demanda custo e
tempo, pois é necessário um Data Warehouse (DW), que tem
como finalidade armazenar informações relativas às atividades da
organização de forma consolidada. O processo para a criação do
DW geralmente é desenvolvido de modo iterativo, mas mesmo
assim são necessários em média 15 ou mais meses para que o
primeiro módulo entre em produção [1].
Segundo [2], o método Agile ROLAP tem por objetivo permitir a
implantação de forma ágil de ambientes de BI que utilizem bancos
de dados relacionais, e ao mesmo tempo permitam a utilização de
ferramentas OLAP projetadas para ambientes tradicionais por
meio de um servidor ROLAP.
No entanto, é proposto no Agile Rolap, que se utilize um
mecanismo intermediário que permita integrar os dados de
diversas fontes de dados em uma única base, para que se
mantenha o conceito de DW e que possa utilizar ferramentas de
BI projetadas para serem utilizadas em DWs.
Copyright SBC 2016.
Essa integração deve ocorrer de maneira transparente ao usuário,
de forma a não migrá-los em uma nova base de dados, uma vez
que esse é o conceito de integração utilizado nos DWs. Portanto, é
proposta a criação de plugins para a ferramenta Kettle, que
auxiliem que dados de diferentes fontes de dados sejam integrados
52
em uma única base de dados PostgreSQL, permitindo
permit
a consulta
desses dados de fontes externas
as por meio da
d utilização da
tecnologia Foreign Data Wrapper (FDW), possibilitando uma
melhor análise em conjunto dos dados [3].

2. REVISÃO
EVISÃO BIBLIOGRÁFICA
Nesta seção são apresentados alguns dos principais conceitos
bases para o desenvolvimento do trabalho.
estão os valores dos atributos na perspectiva
multidimensional na base de dados relacional.
OLAP: São as ferramentas de consulta
Ferramentas OLAP
para os usuários finais.
finai Nesta fase, os dados já foram
mapeados e podem e devem ser visualizados de maneira
simples pelo responsável da tomada de decisão, que são
acessados por meio de um servidor ROLAP.
2.1 AGILE ROLAP
A necessidade de armazenar as informações da empresa e
conseguir fazer uma análise eficiente das mesmas é um fator
muito importante no mercado de hoje, com isso originou-se
originou
o
conceito de DW, que é um depósito de dados que consiste em
armazenar uma grande quantidade
tidade de dados relativa às atividades
de uma empresa. Além de favorecer uma melhor análise de um
grande volume de dadoss por meio de ferramentas OLAP,
facilitando e auxiliando na tomada
omada de decisão das empresas.
Figura 1 - Funcionamento do Agile ROLAP
2.2 FOREIGN DATA WRAPPER
DW é o resultado do processo de transformação dos dados obtidos
de sistemas legados e de bancos de dados transacionais que ficam
organizados sob um formato compreensível ao usuário, auxiliando
na tomada de decisão [5]. No entanto, como mencionado
anteriormente, o processo de criação de um DW é custosa e
demorada, o que muitas vezes se torna um empecilho para que,
principalmente pequenas e médias empresas o implantem. Dessa
forma foi proposta a metodologia Agile ROLAP,
ROLAP que tem como
intuito mitigar alguns problemas encontrados na implantação de
BI, principalmente diminuindo tempo com o processo de Extract
Transformation Loading (ETL).. Apesar da metodologia não
utilizar o conceito tradicional de DW, consegue-se
consegue
por meio de
seu uso utilizar as ferramentas Online Analytical Processing
(OLAP) disponíveis no mercado.
O FDW é um modelo para escrever um módulo para acessar
dados externos baseado no padrão SQL/MED, este é um padrão
para acessar objetos remotos [6]. A Figura 2 ilustra como é
aplicado este conceito no banco de dados PostgreSQL,
PostgreSQL pois o
esmo oferece um melhor suporte para essa tecnologia.
mesmo
tecnologia A
estrutura é dividida em 3 partes dentro do Sistema Gerenciador de
Banco de Dados (SGBD) são: os Wrappers, os “local” tables, e
as Foreign Tables.
Os Wrappers são drivers que apontam para outros tipos de bancos
de dados, além de existir um para o próprio PostgreSQL. Por
exemplo, na Figura 2 existe um wrapper chamado mysql_fdw,
que automaticamente aponta para um banco de dados MySQL,
pois o PostgreSQL sabe que esse é o driver do MySQL e lá que
estão armazenados os dados originais.
Assim, a metodologia visa diminuir o tempo despendido no
n
processo de ETL, pois não há necessidade de criar uma nova base
de dados. Estima-se
se que mais de 1/3 do custo na elaboração de um
DW se dá no processo de ETL [4]. Isto permite que pequenas
empresas possam usufruir de ferramentas OLAP voltadas para
ambientes de BI tradicionais, proporcionando auxilio na tomada
de decisão do administrador da organização baseado nas
informações geradas,, assim podendo conhecer melhor sobre o seu
negócio
ócio além de competir melhor no mercado
mercado.
As Foreign Tables são cópias da estrutura das tabelas originais da
base de dados de origem. Ass mesmas mantém uma imagem de
tempo real do que está sendo armazenado na tabela original e caso
esta seja modificada é também alterada a Foreign Table. Nestas
tabelas não é possível fazer alterações nos dados, somente
consultas.
O “local” tables ou servidor é onde as Foreign Tables são
ste local pode ser chamado de servidor.
armazenadas. Este
servidor Os
servidores têm como objetivo fazer a conex
conexão com o banco de
dados externo, além de ser o local que armazena as tabelas
desejadas. Um wrapper pode ter vários servidores que apontam
para diferentes bases de dados do mesmo banco de dados.
A Figura 1 mostra como é o funcionamento do Agile ROLAP e a
função de cada etapa apresentada na Figura 1 é descrita a seguir:



Físico: representa bases de dados originais. Os dados
das empresas estão armazenadas em tabelas relacionais.
FDW: Tem como finalidade agrupar todas as
informações da empresa em uma única base de dados.
Estas informações estão armazenadas em formas de
tabelas, porém são mapeamentos para as tabelas
originais que estão armazenadas no Físico. Qua
Quando um
usuário acessa a tabela, o FDW consulta diretamente a
base de origem de forma transparente, assim o usuário
tem a impressão que está acessando a base original, mas
na verdade está consultando
do os dados da base original.
Com isso não tem o risco de qu
que os dados da base
original sejam modificados,, pois o FDW permite apenas
o usuário a fazer consultas.
Schema: é um arquivo conhecido como schema XML.
Esse arquivo realiza o mapeamento dos dados que estão
armazenados na forma relacional, no caso no FDW,
paraa os dados que devem ser mostrados na forma
dimensional. Basicamente esse schema indica onde
Figura 2 - Estrutura do Foreign Data Wrapper
pós ser criado toda a estrutura do FDW, esta tecnologia permite
Após
ao banco de dados PostgreSQL reunir inúmeros dados de
53
diferentes fontes. Ademais, pela possiblidade de se criar vários
servidores, é possível armazenar tabelas com os mesmos dados ou
nome, desde que estejam em servidores distintos, assim
facilitando ainda mais a integração e a análise dos dados.
3. DESENVOLVIMENTO DOS PLUGINS
Com o intuito de reduzir a complexidade e tempo da implantação
de um ambiente de BI utilizando DW, é proposto à utilização da
tecnologia FDW para criar uma base de dados intermediária,
conseguindo agilizar o processo da metodologia Agile ROLAP e
garantindo a integridade dos dados originais. Para tanto, foram
desenvolvidos alguns plugins que permitam definir este processo.
Além disso, mesmo não utilizando uma base de dados
multidimensional e criando um DW, é mantido o conceito de
integridade de dados e o não acesso direto da ferramenta OLAP às
bases de dados originais.
A base de dados intermediária tem a função de buscar os dados
que estão armazenados nas bases de dados da organização, e com
a utilização de Foreign Tables, pode-se criar cópia dessas tabelas
na base de dados intermediária. Estas bases intermediárias não
devem ser confundidas como um DW, pois, o formato dos dados
não é multidimensional, e não ocorre à limpeza e a transformação
dos dados. No entanto, o ambiente de BI utilizará esses dados da
forma com que estão armazenados e organizados. Estas bases são
criadas no SGBD PostgreSQL e foi desenvolvido plugins na
ferramenta Pentaho Data Integration (Kettle), que auxilie em todo
este processo.
Figura 3 - Plugin para criação de Foreign Tables.
Foi escolhida a ferramenta Kettle para implementação dos
plugins, pois assim é possível em um mesmo ambiente utilizar
todos plugins necessários para a implantação completa do Agile
Rolap. Além disso, o Kettle é uma ferramenta que permite a
utilização de plugins para realizar transformações de dados
complexos nos dados que darão origem a um ambiente de BI.
Basta utilizar um conjunto de plugins interligados entre si, além
de facilitar o processo de ETL. O Kettle é uma plataforma de
integração de dados completa, que permite a análise dos dados de
forma precisa, podendo obter os dados de qualquer fonte de dados
e permitindo sua manipulação por meio de componentes visuais,
eliminando assim a codificação e a complexidade na integração
dos dados [7].
Após a base intermediária ser estruturada com as Foreign Tables,
são utilizados três plugins que vão usufruir desses dados
integrados, que são: O tempo, a dimensão e o fato. A Figura 4
mostra como funcionam os plugins citados anteriormente em
conjunto no Kettle.
O plugin dimensão facilita a modelagem da dimensão que será
utilizada no ambiente de BI. Nele os dados são carregados na base
intermediária, ou seja, por meio das Foreign Tables criadas. A
Figura 4 mostra a dimensão Cliente e Produto que utilizam os
dados das Foreign Tables Cliente e Produto, das suas respectivas
bases.
O plugin tempo auxilia a construção de tabelas de tempo que o
ambiente de BI precisa, e por meio deste são geradas novas
tabelas na base de dados intermediária utilizada pelo ambiente de
BI, com o objetivo de permitir uma análise temporal dos dados.
A Figura 3 ilustra a interface do plugin desenvolvido no Kettle. A
tela é composta pela Conexão Destino, Conexão Origem e uma
tabela. A Conexão Destino é responsável por fazer a conexão
SGBD PostgresSQL, o qual o administrador do banco de dados
deverá informar o número da porta, a base de dados e o host onde
foi criado o FDW, além do usuário e senha. Para conseguir ver o
conteúdo do campo “Servers do FDW” é necessário que todos os
campos anteriores estejam preenchidos, assim será mostrado todos
os servidores criados no FDW, diminuindo a chance de erro na
hora de criar a Foreign Table.
O plugin fato auxilia a criação de uma view que atua como o fato
de um modelo dimensional. Como se utiliza diretamente os dados
da base de dados da organização é necessário agrupar as medidas
em uma nova estrutura. Os dados desta view são carregados por
meio das Foreign Tables criadas na base intermediária, assim
fazendo com que o tempo de consulta seja reduzido.
A Conexão Origem faz a conexão com o banco de dados onde
estão armazenadas as tabelas originais, e apenas quando a
conexão com a base de dados original estiver estabelecida o botão
“Obter Tabela” conseguirá ser executado. Este botão por sua vez,
irá abrir uma nova aba para selecionar a tabela que será copiada
para dentro da base intermediária. Por último tem uma aba
chamada “Tabelas” que mostrará quais tabelas foram selecionadas
pelo administrador naquele momento para a criação da Foreign
Table.
Figura 4 - Funcionamento dos plugins fato, dimensão, tempo
no kettle.
54
4. RESULTADOS
Além disso, a implantação de ambientes de BI utilizando a própria
base da organização faz com que seja necessária a permissão para
que sejam realizadas modificações na estrutura do banco, o que é
muito indesejável. Assim, é fortemente recomendado que na
utilização do Agile ROLAP seja criada uma base de dados
intermediária, que implementa a função de armazenar os dados
adicionais necessários para implantar o ambiente de BI.
Os resultados do uso desta tecnologia se mostraram satisfatórios
em termos de desempenho, o que mostra que seu uso é viável.
Como principal limitação, no estado em se encontra os plugins,
consegue-se acessar apenas dados de fontes de bases de dados
relacionais, não conseguindo acesso a outros tipos de fontes de
dados.
A fim de verificar se a utilização de bases intermediárias,
implantadas utilizando a tecnologia FDW, é viável em termos de
desempenho se comparado ao DW tradicional, algum testes foram
realizados. O Agile ROLAP não precisa necessariamente de uma
base intermediária para ser implantado, os dados podem ser
acessados diretamente das próprias bases transacionais utilizada
pela organização, no entanto isto dificulta a integração dos dados,
um dos preceitos do DW.
O uso do FDW como base intermediária se mostrou uma
alternativa viável para acessar de forma rápida os dados por meio
de ferramentas OLAP. O uso do FDW permite o acesso aos dados
das bases de origem de forma transparente, e ao mesmo tempo
não modifica esta base, pois caso seja necessário criar novas
tabelas, como as de Tempo, estas são criadas diretamente na base
FDW. Além disso, permite a integração de diferentes bases, um
preceito importante do DW.
Para realizar a comparação de desempenho, foi utilizada uma base
de dados exemplo do Postgres, chamada Pagila. Foram realizados
testes no qual a ferramenta OLAP acessa uma base intermediária
de três formas distintas: os dados do fato em tabela, em view e em
view materializada. Na Figura 5 é possível ver o desempenho
obtido por cada tecnologia.
Figura 6 – Comparação do desempenho entre FDW, DW e
Bases de Origem.
6. AGRADECIMENTOS
Meu agradecimento ao órgão Conselho Nacional de Pesquisas
(CNPq) pela bolsa que me foi concebida.
7. REFERÊNCIAS
[1] MACHADO, Felipe N. R. “Tecnologia e Projeto de Data
Warehouse: Uma visão multidimensional” São Paulo: Érica
2010 5 ed.
Figura 5 – Comparação do desempenho de acesso OLAP a
três tecnologias.
[2] SOUZA, Elielson B., MENOLLI, André L. A., COELHO,
Ricardo G. “Um método Agile ROLAP para implementação
de ambientes de inteligência de negócios”.
Observando a Figura 5, percebe-se que a utilização de fatos em
view tem um tempo de resposta gerado muito superior em relação
à utilização de fatos em tabelas e fatos em views materializadas.
Baseado nas comparações de tempo de resposta foi escolhida à
utilização de fatos em views materializadas para a implementação
método Agile ROLAP no ambiente de BI, pois não haverá
necessidade de reconstruir o objeto quando os dados forem
recarregados.
[3] SAVOV, Svetoslav. “How to use PostgreSQL Foreign Data
Wrappers for external data management”
[4] MENOLLI, André L. A. “A Data Warehouse Architeture in
Layers for Science and Tecnology” Proceedings of the
Eighteenth International Conference on Software
Engineering Knowledge Engineering (SEKE’2006), San
Francisco, CA, USA.
Na Figura 6 é mostrado o desempenho obtido na implantação de
ambientes de BI, utilizando o método Agile ROLAP, por meio de
bases intermediárias usando FDW para obter os dados das bases
transacionais. Nesta Figura, é comparado o desempenho do acesso
aos dados por meio de ferramentas OLAP, quando os dados são
armazenados utilizando a tecnologia FDW em comparação ao
acesso dos dados quando estão armazenados diretamente na
própria base de dados transacionais, e ainda comparando com a
utilização de um DW.
[5] KIMBALL, Ralph., CASERTA, Joe “The Data Warehouse
ETL Toolkit: Practical Techniques for Extracting, Cleaning,
Conforming, and Delivering Data”
[6] AHMED, Ibrar., FAYYAZ, Asif., SHAHZAD, Amjad.
“PostgreSQL Developer’s Guide”.
[7] PENTAHO. “Pentaho: Writing you own Pentaho Data
Integration Plug-in”. Pentaho Community, 2014.
http://wiki.pentaho.com/dislplay/EA/Writing+your+own+Pe
ntaho+Data+Intagration+Plug-in. Acessado em 11 de março
de 2016
Percebe-se que a utilização de base de dados intermediária tem
um desempenho inferior em relação ao método Agile ROLAP, que
utiliza a própria base de dados transacionais da empresa, porém
discrepância não foi tão significativa. Apenas na primeira consulta
resultou em uma diferença expressiva, nas demais consultas o
resultado foi equivalente ou muito próximo.
55
Índice Remissivo
Morais, Emilie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Moskado, Felipe I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 52
A
Abreu, Christian R.C. de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
N
Araújo, Cristian Z. de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Nau, Jonathan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B
O
Baldessar, Maria J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Oliveira, Aline C.A. de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Oliveira, Geovanni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
C
Coelho, Ricardo G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 52
P
Correia, Wagner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5, 43
Paladini, Fernando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Cunha, Mônica X.C. da . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
R
D
Romão, Luiz Melo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Duda Júnior, José da S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Ruano, Antonio E. de B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
F
S
Fagundes, Priscila B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Silva, Alexandre S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Figueiredo, Rejane M. da C. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Silva, Glauco C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 52
Frohlich, Antonio A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Silva, Rodrigo C. da . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Silva, Viviane A. da . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
H
Hauck, Jean C.R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
T
Trevisani, Kleber M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
L
Lima Junior, Guaratã A.F. de . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
V
Lins, Matheus I.A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Venson, Elaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Lopes, Bruno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Vieira, Lucas N. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
M
Marques, Caique R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Martins, Augusto B.T. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Mello, Leonardo R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Melo, Luan S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 52
Menolli, André . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 52
Momo, Marcos R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
W
Wanner, Lucas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Z
Zanchett, Pedro S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5,43
56

Anais do III Workshop de Iniciação Científica em

Transcrição

Documentos relacionados

(ANTONIO BOY) CPF: 719.746.107-30 Serra, 13 de julho de 2016 DE

termo de dispensa de licitação 022/2016

CONVOCAÇÃO CONVOCAÇÃO Convocamos o candidato

Decreto N.º 024 de 01 de abril de 2016 ? Nomeia Assessores

Best of ASCO - Instituto de Oncologia Kaplan

EXTRATO DE CONTRATO Nº 92/2016 CONTRATADA CHIQUITO E

autorização - Anime Friends

Gestão Fiscal - Câmara Municipal de Heliodora

VLADIMIR DE SÁ BARROS GUERREIRO Membro CLAUDIA

- Prefeitura Municipal de Riachão