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
Universidade Federal de Santa Catarina

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) Marcello Thiry (UNIVALI)
Celia Ralha (UNB) Marcelo Morandini (USP)
Christiane Gresse von Wangenheim (UFSC) Maria Inés Castiñeira (UNISUL)
Clodis Boscarioli (UNIOESTE) Mauricio Capobianco Lopes (FURB)
Cristiane Ferreira (UFG) Merisandra Côrtes de Mattos (UNESC)
Daniel Kaster (UEL) Ovidio Felippe da Silva Júnior (UNIVALI)
Elisa Huzita (UEM) Pablo Schoeffel (UDESC)
Ellen Francine Barbosa (ICMC-USP) Renato Bulcão Neto (UFG)
Fabiana Mendes (UnB) Renato Fileto (UFSC)
Fabiane Barreto Vavassori Benitti (UFSC) Roberto Willrich (UFSC)
Fatima Nunes (EACH-USP) Rosângela Penteado (UFSCar)
Iwens Sene Jr (UFG) Vinicius Sebba Patto (UFG)
Jean Hauck (UFSC) Vitório Mazzola (UFSC)
João Porto de Albuquerque (ICMC-USP)
Luanna Lopes Lobato (UFG)

Revisores
Antônio Esteca (USP)
Flávia Horita (USP)
Kalinka Castelo Branco (USP)
Lívia Castro Degrossi (USP)

iv
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

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 apresen-

tados 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.

Roberto Willrich (UFSC)

Vinicius Sebba Patto (UFG)

Coordenação do WICSI 2016

vi
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

Biografia dos Coordenadores do Comitê de Programa do WICSI 2016

Roberto Willrich possui graduação e mestrado em Engenharia Elétrica pela Universidade Fed-
eral 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 Edu-
caçã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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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
Instituto Federal de Mato Grosso do Sul (IFMS)
R. Treze de Maio, 3086, campus Campo Grande
Centro, Campo Grande - MS
+55 (67) 3378-9500
alexandre.silva@ifms.edu.br
RESUMO
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.
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.
SBSI 2016, May 17–20, 2016, Florianópolis, Santa Catarina, Brazil.
Copyright SBC 2016.
1
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
viviandrade.as@gmail.com
Categories and Subject Descriptors
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.
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
1
Curso Superior de Tecnologia
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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).
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.
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.
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
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.
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].
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,
2
Institute of Electrical and Electronics Engineers
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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
Java Server Pages
4
JSON (JavaScript Object Notation) é um formato de dados leve
para troca de informações.
3
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):
 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.
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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ça-
palavras, coleta seletiva de lixo, dentre outros (Figura 4).
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.
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 e-
commerce, 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.
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
6.REFERÊNCIAS
[1] Boyer, K., Buffum, P.S., et. al. 2015. ENGAGE: A Game-
based 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.
DOI=http://dx.doi.org/10.1145/2538862.2539009
[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.
ACM New York, NY, USA. ISBN: 978-1-4503-2896-8.
DOI=http://dx.doi.org/10.1145/2669711.2669904
[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.1-
2002.html
[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.
DOI=http://dx.doi.org/10.1145/792548.611964
[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.
ACM New York, NY, USA. ISBN: 978-1-4503-0994-3.
DOI=http://dx.doi.org/10.1145/2072598.2072607
[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.
DOI=http://dx.doi.org/10.1145/1821748.1821824
[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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
RNA Aplicada a Modelagem Hidrológica
Alternative Title: Applied ANN to Hydrologic Model
Marcos Rodrigo Momo Pedro Sidnei Zanchet
Centro Universitário de Brusque Centro Universitário de Brusque
momo@unifebe.edu.br pedrozanchett@gmail.com
Wagner Correia Christian R. C. de Abreu
Centro Universitário de Brusque Prefeitura Municipal de Blumenau
wagnercorreia@hotmail.com.br crca.com@gmail.com
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.
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.
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
Cristian Zimmermann de Araújo
Centro Universitário de Brusque
cristianz@unifebe.edu.br
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.
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].
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
2. FUNDAMENTAÇÃO TEÓRICA
2.1 Modelos hidrológicos
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
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 chuva-
vazã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].
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
6
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.
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].
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.
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].
Para resolver um dado problema, não existe, todavia, uma
solução bem definida para a escolha do número de camadas e de
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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.
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.
7
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 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.
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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.
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.
Figura 4: Simulação hidrológica Observado/Simulado com
RNA.
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.
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.
8
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
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.
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.
[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.
[7] BACIAS. Bacias Hidrográficas do Brasil. GEO-Conceição.
Disponível em:
<http://geoconceicao.blogspot.com.br/2011/08/bacias-
hidrograficas-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.
[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.
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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 Instituto Federal de Alagoas
R. Mizael Domingues, 75 - Centro, R. Mizael Domingues, 75 - Centro,
Maceió - AL Maceió - AL
matheusialins@gmail.com duda.ifal@gmail.com
RESUMO
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.
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.
Categories and Subject Descriptors
A1 [Introductory and Survey]
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.
9
Mônica Ximenes Carneiro da
Cunha
Instituto Federal de Alagoas
R. Mizael Domingues, 75 - Centro,
Maceió - AL
mxcc@hotmail.com
General Terms
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].
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].
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.
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].
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.
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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.
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.
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.
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.
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:
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?
Q3. Quais as benefícios da terceirização de sistemas de
informação no setor público?
10
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.
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*))
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)).
 Strings para Q2
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 (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))
 Strings para Q3
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 (benefit* OR advantage*))
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.
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.
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

2.4 Estratégias de inclusão e exclusão A seguir são apresentadas as respostas paras as questões de
pesquisa tendo como base os aspectos mais citados nos artigos
O procedimento para a inclusão e exclusão de documentos que selecionados:
retornaram após a aplicação dos argumentos de pesquisa (strings
de busca) nas bases de dados se deu em dois momentos. No Q1. Quais os riscos da terceirização de sistemas de
primeiro momento, foram definidos no protocolo de pesquisa informação no setor público?
como critérios de inclusão: a disponibilidade do documento na
internet para download e que esteja em formato PDF, Constatou-se que dos 24 documentos, 9 abordavam os riscos de
disponibilidade do documento em língua inglesa ou portuguesa, e maneira primaria, e 4 de maneira secundaria. Dentre os resultados,
a delimitação do tempo de publicação de dez anos, ou seja, conforme a Tabela 2, ficou evidente a preocupação com questões
publicados entre 2005 a 2015, tendo em vista que esta etapa da de segurança, uma vez que 6 dentre os 13 artigos que falam de
pesquisa iniciou em novembro de 2015 e encerrou em março de riscos, citam esse ponto. Isso ocorre, principalmente, pelo fato de
2016. Por fim, foram aceitos documentos que tratam de forma que os gestores das instituições públicas se preocupam
primária ou secundária sobre motivações, riscos e benefícios da demasiadamente com possíveis vazamentos e acesso não
TSI no setor público. Dessa forma, os critérios de exclusão foram autorizado às informações que são confidenciais. Além de
elaborados de forma que contrariem os critérios de inclusão. 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 Observou-se também o elevado número de citações com relação a
resultados que havia sido retornada após a aplicação dos dependência excessiva do fornecedor, fator que é refletido a partir
argumentos. Ao término dessa análise restaram 239 documentos. de outros riscos como, por exemplo, a perda de habilidades
Eles tiveram seu resumo e conclusão lidos para confirmar se críticas de TI. É comum que haja uma acomodação quando um
estavam de acordo com o que foi estabelecido nos critérios de serviço é prestado de maneira eficiente, e isso acarreta na falta de
inclusão, e no fim restaram 24 documentos relevantes, que foram interesse da organização em fazer novos investimentos internos
utilizados para responder as questões propostas pela revisão. A para capacitação e melhoria das atividades. Apesar da perda de
tabela 1 exibe os resultados obtidos durante toda a fase de busca e habilidades de TI estar como um dos menos citados na tabela,
seleção dos documentos primários. 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. Tabela 2. Principais riscos abordados nos artigos selecionados.
QTD DE FREQUÊNCIA
1ª Seleção 2ª Seleção RISCOS
CITAÇÕES DE CITAÇÕES
Fonte Quantidade (Título e (Abstract e
Questões de segurança 6 46%
Palavras-chave) Conclusão)
Dependência excessiva do fornecedor 6 46%
Periódicos Capes 32 7 4 Perda de competências centrais em TI 5 38%
ACM Digital library 45 13 1 Custos ocultos 4 31%
Science Direct 564 28 3 Perda de controle da atividade terceirizada 3 23%
ISI Web of Science 8 8 1 Falta de experiência do fornecedor na atividade Terceirizada 3 23%
Scopus 26 7 1 Diminuição da moral dos funcionários 3 23%
IEEE 13 7 1 Qualificação dos funcionários do fornecedor 3 23%
Google Scholar 2716 169 13 Perda de flexibilidade dos serviços de TI 3 23%
Total 3404 239 24 Diferenças culturais 3 23%
Instabilidade financeira do fornecedor 2 15%
3. RESULTADOS E DISCUSSÕES Perda de habilidades criticas de TI 2 15%
Dos 24 artigos que restaram após os processos de seleção,
identificou-se que, em alguns casos, um mesmo artigo tratava de Q2. Quais as motivações da terceirização de sistemas de
mais de um dos assuntos pesquisados: riscos, motivações e informação no setor público?
benefícios. O Gráfico 1 mostra o número de artigos que está A Tabela 3 sinaliza que a motivação relacionada a direcionar o
diretamente ligado a cada uma das perguntas de pesquisa, foco para as competências essenciais foi a mais citada. Em
separando pelas bases de dados onde foram encontrados. No total, segundo lugar está a redução de custos, que geralmente é a mais
17 artigos abordaram sobre motivações, 13 sobre riscos e 4 sobre citada nos estudos voltados para o setor privado. A intensidade de
benefícios. citações sobre este fator é compreendida pela possibilidade de
Gráfico 1. Quantidade de artigos por bases de dados que direcionamento do foco da empresa para as atividades principais,
falam em Motivação, Risco ou Benefício. com canalização dos investimentos financeiros que seriam feitos
no setor de TI sendo remanejados para as tarefas centrais. Outra
20 motivação bastante citada foi a busca pela melhoria na qualidade
15 dos serviços, viabilizada pelo acesso às novas tecnologias e novas
10 Motivações expertises. Isso se dá pelo fato de os fornecedores de serviços
5 terceirizados geralmente dispõem de recursos humanos e
0 Riscos tecnológicos mais capacitados e avançados, possibilitando a
substituição de tecnologias defasadas e suprindo a falta de
Benefícios profissionais, às vezes causada pela inexistência de cargos
específicos.

11
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

Tabela 3. Principais aspectos motivadores citados nos artigos flexibilidade dos serviços de TI, melhoria dos produtos e serviços
selecionados. e acesso a novos recursos e habilidades.
Como trabalhos futuros pretende-se utilizar os conhecimentos
QTD DE FREQUÊNCIA
MOTIVAÇÃO
CITAÇÕES DE CITAÇÕES
gerados por este artigo para compor um survey para aferir a
opinião de gestores públicos estaduais e municipais sobre
FOCO NA COMPETÊNCIA PRINCIPAL 12 71% motivações, benefícios e riscos da parceria público-privada de
REDUÇÃO DE CUSTOS 11 65%
sistemas de informação, com vistas a atestar ou refutar as
MELHORIA QUALIDADE DOS SERVIÇOS 10 59% informações preliminares obtidas na revisão sistemática.
ACESSO A NOVAS TECNOLOGIAS/HABILIDADES 8 47%
FLEXIBILIDADE PARA RESPONDER RAPIDAMENTE
ÀS MUDANÇAS NA ÁREA DE TI
6 35% REFERÊNCIAS
ESCASSEZ DE RECURSOS INTERNOS 6 35% [1] GORLA, Narasimhaiah; CHIRAVURI, Ananth. 2011.
ACESSO A EXPERTISE 5 29% Information systems outsourcing success: a review. In: 2010
FALTA DE CONHECIMENTO INTERNO/EXPERTISE 3 18%
COMPARTILHAMENTO DE RISCOS 2 12%
International Conference on E-business, Management
REDUÇÃO DE PROBLEMAS ROTINEIROS DE TI 2 12% and Economics. 2011. p. 170-174.
ATENDIMENTO A DEMANDAS URGENTES DE TI 1 6% [2] BERGAMASCHI, S. Modelos de gestão da terceirização
TRATAMENTO DE FUNÇÕES DIFÍCEIS DE GERENCIAR
1 6% de Tecnologia da Informação: um estudo exploratório. Tese
OU FORA DE CONTROLE
PRESSÕES EXTERNAS 1 6%
(Doutorado em Administração) - Universidade de São Paulo,
PROBLEMAS COM RECRUTAMENTO DE PESSOAL 1 6% São Paulo, 2004.
[3] PRADO, E. P. V.; TAKAOKA, H.. 2000. Terceirização da
Q3. Quais as benefícios da terceirização de sistemas de
Tecnologia de Informação: Uma Avaliação dos Fatores que
informação no setor público?
Motivam sua Adoção em Empresas do Setor Industrial de
Apesar de restarem poucos documentos que falam em benefícios, São Paulo. Dissertação (Mestrado em Administração de
foi possível ter acesso às informações necessárias para responder Empresas) - Universidade de São Paulo, São Paulo, 2000.
a pergunta supracitada. Em meio aos 24 artigos selecionados, 4 [4] LOH, L.; VENKATRAMAN, N.. 1992. Diffusion of
deles citaram algum tipo de benefício. Conforme ilustrado na information technology outsourcing: influence sources and
Tabela 4, a metade dos artigos apontou que um dos principais the kodak effect. Information Systems Research, 1992.
benefícios é o acesso a novas capacidades e competências, visto
que, em muitas ocasiões, a equipe interna de TI não tem [5] DIBBERN, J. et al.. 2004. Information Systems
habilidade e expertise necessária para gerenciar problemas mais Outsourcing: A Survey and Analysis of the Literature. The
complexos e atender novas demandas. Consequentemente, junto DATA BASE for Advances in Information Systems, v.35,
das novas competências e recursos, tecnologias inovadoras n.4, 2004.
aparecem como o segundo mais citado, seguido da melhoria na [6] DOMBERGER, Simon. 1998. The contracting
qualidade dos serviços, que pode ser compreendido como organization: a strategic guide to outsourcing. Oxford:
resultado da soma dos demais benefícios. Oxford Univ. Press, 1998. 229p.
Tabela 4. Principais benefícios citados nos artigos. [7] LEITE, J. C.. 1994. Terceirização em informática. São
Paulo: Makron Books, 1994.
QTD DE FREQUÊNCIA
BENEFÍCIOS [8] KITCHENHAM, B. 2004. Procedures for performing
CITAÇÕES DE CITAÇÕES
systematic reviews. Keele, UK, Keele University, v. 33, n.
ACESSO A NOVAS CAPACIDADES, COMPETÊNCIAS E RECURSOS 2 50%
TR/SE-0401, p. 28, 2004.

MELHORIA DOS PRODUTOS E SERVIÇOS 2 50%

[9] BIOLCHINI, J. et al. 2005. Systematic Review in Software
AUMENTO DA FLEXIBILIDADE DOS SERVIÇOS 2 50% Engineering. Engineering, v. 679, n. May, p. 165–176,
REDUÇÃO DE CUSTOS 2 50%
2005.
ACESSO A NOVAS TECNOLOGIAS 2 50% [10] CUNHA, M.X.C. 2011. Aspectos e Fatores Motivadores
FOCO NAS COMPETÊNCIAS ESSENCIAIS 1 25% da Terceirização de Sistemas de Informação no Setor
MELHORIA DOS PROCESSOS E NEGÓCIOS 1 25% Público: Um Estudo em Instituições Públicas de Alagoas.
Tese (Doutorado em Administração) - Universidade Federal
4. CONCLUSÃO de Pernambuco, Recife, 2011.
A revisão sistemática conduzida neste artigo identificou as
[11] COX, Michael, Martyn Roberts, and John Walton. 2011. IT
principais contribuições na literatura, nos últimos dez anos, para
outsourcing in the public sector: experiences form local
terceirização de sistemas de informação no setor público.
government. The Electronic Journal Information Systems
Seguindo as etapas definidas no protocolo, foi possível responder
Evaluation 14.2 (2011): 193-203.
as três questões de pesquisa propostas.
[12] GANTMAN, Sonia. 2011. IT outsourcing in the public
Quanto aos riscos, os mais populares entre os artigos selecionados
sector: A literature analysis. Journal of Global Information
foram questões relacionadas à segurança, dependência dos
Technology Management, v. 14, n. 2, p. 48-83, 2011.
fornecedores e perda das competências centrais de TI. As
principais motivações foram o foco nas competências essenciais [13] LACITY, M. C.; Willcocks, L. 1997. Information systems
da organização, redução de custos e melhoria na qualidade dos sourcing: examining the privatization option in USA public
serviços. Já em relação aos benefícios, foi apontado o aumento na administration [Electronic version]. Information Systems
Journal, 7 (1997), 85–108.

12
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
Uma Comparação entre o Desenvolvimento de Aplicações
Web Convencionais e Aplicações em Nuvem
Bruno Lopes†
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
brunolp@hotmail.com.br
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.
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.
__________________________
†Discente e ‡Docente do Curso Superior de Tecnologia em
Análise e Desenvolvimento de Sistemas
CCS
• Information systems ➝ Information systems applications ➝
Computing platforms; • Networks ➝ Networks services ➝
Cloud computing;
Palavras-chave
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].
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.
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
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
kleber@ifsp.edu.br
os recursos são virtuais e ilimitados e que detalhes dos sistemas
físicos de software são abstraídos.
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.
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].
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.
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.
É 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.
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
em um único provedor de serviços de nuvem, nesse caso, o GAE
(Google App Engine).
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].
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).
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.
Figura 2. Interação entre os componentes. (a) Aplicação
convencional. (b) Aplicação em nuvem.
14
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].
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.
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].
public Long save(Cliente c) {
(a) ofy().save().entity(cliente).now();
return cliente.getId();
}
public void persist(Cliente c) {
(b) 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].
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

(a) <!-- Registro de entidades no Objectfy --> uma conta do Google. Cada conta pode ter mais de uma aplicação
<listener> implantada no GAE, porém cada aplicação possui um
<listener-class>
identificador para diferenciá-la das outras. Por essa razão, ao
config.ConfigStartup
</listener-class> realizar uma implantação ou atualização, é necessário fornecer o
</listener> título do projeto e o Application Identifier que foram previamente
criados no próprio site do GAE.
(b) <!-- Configuração do Objectify -->
<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) <!-- Desabilita o controle de threads -->

<context-param>
<param-name>
com.sun.faces.enableThreading
</param-name>
<param-value>false</param-value>
</context-param>

(d) <!-- Define o padrão de projeto -->
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>
javax.faces.webapp.FacesServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
Figura 3. Arquivo web.xml utilizado.
3.4 Implantação
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.
Figura 5. Console administrativo do Glassfish
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.
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.
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.

Já a aplicação em nuvem é implantada utilizando um botão no 5. AGRADECIMENTOS

Ecplise (deploy), disponibilizado pelo plugin do GAE, que invoca Os autores agradecem ao IFSP - Instituto Federal de Educação,
a interface apresentada pela Figura 6. Nesse caso, o Eclipse Ciência e Tecnologia de São Paulo pelo apoio financeiro durante
solicita que o desenvolvedor se autentique previamente utilizando o desenvolvimento deste trabalho.

15
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

6. REFERENCIAS computing-united-states-businesses-will-spend-13-billion-
on-it/>. Acesso em: 10 Mar 2016.
[1] Mell, Peter, and Tim Grance. "The NIST definition of cloud [7] Google App Engine Docs. Disponível em: <https://cloud.
computing." Communications of the ACM 53.6 (2010): 50. google.com/appengine/docs>. Acesso em: 10 Mar. 2016.
[2] Coulouris, George F., Jean Dollimore, and Tim Kindberg. [8] Schnitzer, J. et. al. Introduction to Objectify: Loading,
Distributed systems: concepts and design. pearson education, Saving, and Deleting Data. Disponível em: <https://github.
2005. 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:
[4] Sosinsky, B. Cloud computing bible. John Wiley & Sons, <www.ibm.com/developerworks/br/library/j-gaestorage/>.
2010. Acesso em: 10 Mar 2016.
[5] Marston, S., et al. "Cloud computing—The business [10] MEDEIROS, H. Padrões de Projeto: Introdução aos Padrões
perspective." Decision support systems 51.1 (2011): 176-189. Front Controller e Command. Disponível em: <http://www.
[6] Mccue, TJ. Cloud Computing: United States Businesses Will devmedia.com.br/padroes-de-projetos-introducao-aos-
Spend U$13 Billion On it. Disponível em: padroes-front-controller-e-command/30644>. Acesso em: 10
<http://www.forbes.com/sites/tjmccue/2014/01/29/cloud- Mar 2016.

16
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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
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.
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
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.
17
federal public organization. The tool is already in use.
Categories and Subject Descriptors
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.
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.
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
Lista de itens necessários ao produto. Origem única de
requisitos. [11]
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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.
2.1 Scrum
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].
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].
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].
3. METODOLOGIA DE PESQUISA
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.
3.1 Caracterização do Objeto
Foram caracterizados o órgão e seu processo de software.
3.1.1 Ministério
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.
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.
18
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].
3.1.2 Processo GeDDAS
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 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].
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.
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.
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 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 Produto,
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 Time de Desenvolvimento
aquisição de conhecimento
Priorização dos itens Proprietário do 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.2 Processo de Seleção da Ferramenta
O processo de seleção de ferramentas é composto pelas etapas:
identificação, seleção e avaliação, validação e treinamento.
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.
2
Identificação de estudos a partir de um estudo, através das
referências ou dos trabalhos que citam este estudo. [10]
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

3.2.2 Seleção e Análise Considerando os critérios estabelecidos foram selecionadas as

Na etapa de seleção foram definidos critérios de seleção e análise ferramentas XPlanner, FireScrum, IceScrum e Redmine. Que,
das ferramentas identificadas a partir da literatura, dos requisitos embora gratuitas, algumas apresentavam limitações de uso.
do Ministério e de seu processo de desenvolvimento de software. 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 plug-
3.2.3 Validação ins do Redmine para apoio ao desenvolvimento ágil: Backlogs,
Na etapa de validação, uma vez selecionada a ferramenta, essa foi Scrum e Scrumbler.
configurada segundo os requisitos do GeDDAS. Em seguida, a No estudo realizado por Dimitrijević et al [5] foram definidas as
ferramenta configurada foi avaliada pelos envolvidos no processo. 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
3.2.4 Treinamento testes de aceitação, Planejamento de release, Planejamento de
Nesta etapa, após a validação da ferramenta foram previstos iteração, Acompanhamento do processo. Aspectos como
treinamentos a distância e presencial para os usuários. usabilidade, integração com outros sistemas e opção de
customizações, foram utilizados por Azizyan et al [1].
4. SELEÇÃO DAS FERRAMENTAS
Nesta seção apresenta-se o processo de 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.
4.1 Identificação das Ferramentas
Para o levantamento das ferramentas nas bases de dados foram Tabela 3. Avaliação dos plug-ins do Redmine
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
4.2 Seleção e Análise das Ferramentas Backlogs foi considerado o mais adequado para o contexto.
Foram estabelecidos alguns critérios para seleção das ferramentas.
A motivação é apresentada na Error! Not a valid bookmark 4.3 Validação da Ferramenta
self-reference.. 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
Tabela 2. Critérios para seleção das ferramentas
com os envolvidos no processo.
Motivações Critérios
A gestão do Backlog deve ser o Permitir o gerenciamento do 4.3.1 Configuração da Ferramenta e do Plug-in
principal aspecto considerado, Backlog, como a adição, edição e Considerando os aspectos do processo (Tabela 4), como os papéis,
visto que motivou a adoção de exclusão de itens, bem como a os status dos itens e o tipo de item do Backlog que pode ser
uma ferramenta alocação em iterações e entregas criado, foram configurados: a pontuação das histórias, os tipos de
A aquisição de uma ferramenta Ser gratuita itens do Backlog, o status dos itens, o perfil de usuário e as
não foi prevista pelo órgão, e permissões necessárias.
não havia orçamento previsto Tabela 4. Itens configurados
O processo de desenvolvimento Possuir configuração de perfis de
utilizado prevê vários papéis acesso
que devem interagir com a
ferramenta e esses papéis
devem possuir diferentes
permissões

19
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
4.3.2 Validação com os envolvidos
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.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.
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.
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.
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.
5. CONSIDERAÇÕES FINAIS
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.
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.
6. AGRADECIMENTOS
Nossos agradecimentos pelo apoio recebido da UnB.
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 2314-
33/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.
[3] Brasil, Tribunal de Contas da União 2012. Guia de Boas
20
Práticas em Contratação de Soluções de Tecnologia da
Informação.
[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
[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.
[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.
[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-agile-
delivery-4/.
[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.
[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.
[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.
[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.
[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.
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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 BR­369 Km 64
luan.sm50@gmail.com, {menolli, glauco, rgcoelho}@uenp.edu.br, felipe.moskado@gmail.com
RESUMO
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.
Categories and Subject Descriptors
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.
Keywords
Data Warehouse, Agile Rolap, Business Inteligence,
Discretização.
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 redistribu-te to lists,
requires prior specific permission and/or a fee.
SBSI 2016, May 17–20, 2016, Florianópolis, Santa Catarina, Brazil.
Copyright SBC 2016.
21
ABSTRACT
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. INTRODUÇÃO
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.
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.
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.
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].
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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].
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.
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.
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
22
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:
 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 dimensio-
nal. Basicamente esse schema indica onde estão os valo-
res 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.
Figura 1. Funcionamento do Agile Rolap
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.
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
Existem dois tipos de discretização de dados[3]:
 Discretização sem Supervisão: Discretização não-
supervisionada 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.
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.
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 pegando-
se 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.
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.
23
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.
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.
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.
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 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.
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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”.
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.
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.
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.
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. Definiram-
se as categorias como sendo: curta, média e longa metragem,
conforme encontrado na literatura.
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.
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
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.
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.
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.
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.
[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.
[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.
[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.
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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
Programa de Pós Graduação em Engenharia e Gestão
do Conhecimento – PPEGC/UFSC 1 2
alineantonelioliveira@gmail.com1
mbaldessar@gmail.com2
RESUMO
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).
Palavras-Chave
Sistema de Resposta Audível, Heurísticas de Usabilidade, Percurso
Cognitivo.
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.
Categories and Subject Descriptors
D.2.2 [Software Engineering]: Design tools and techniques – user
interfaces.
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.
25
Leonardo Roza Melo3
Priscila Basto Fagundes4
Faculdade de Tecnologia SENAI Florianópolis 3 4
proinfotecnologia@gmail.com3
priscila@edu.sc.senai.br4
General Terms
Design, Human Factors.
Keywords
System Interactive Voice Response, Heuristics Usability,
Cognitive Walkthrough.
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].
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.
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].
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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.
2. INTERAÇÃO HUMANO-COMPUTADOR
(IHC) e UNIDADE DE RESPOSTA AUDÍVEL
(URA)
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].
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.
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].
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].
26
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 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].
4. PROCEDIMENTOS E MÉTODOS
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.
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.
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.
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
5.1.2 Tarefa
Ligar para a empresa X para tentar resolver um problema de
conexão com a Internet.
5.1.3 Sequência de ações
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.
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.
Passo 3 – Aguardar a URA informar qual é a opção referente ao
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.
Passo 4 – Aguardar a URA informar qual é a opção referente ao
seu problema. Neste caso, o usuário escolher a opção “1”, “Se não
consegue acessar a Internet, digite 1”.
Passo 5 – Aguardar a URA informar qual é a opção referente ao
seu problema. Neste caso, escolher a opção 2 “Se você já
configurou e ainda permanece com dificuldades para acesso à
Internet, digite ‘2’”.
5.1.4 Questões aplicadas à execução do percurso
As questões aplicadas serão as seguintes:
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?
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?
4.2 Análise heurística
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].
27
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:
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.
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.
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.
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.
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.
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.
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.
H10. Condução/Feedback imediato [1] - Feedback é um retorno
imediato que o sistema deve oferecer após as ações executadas
pelos usuários.
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.
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.
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.
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

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 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
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.
Tabela 2 – Tabela de Criticidade

Recomendações
de resposta para as questões: "Sim", "Sim, porém" e "Não”.

Desrespeitadas
Heurísticas

Criticidade
Problema
5.1 Análise do percurso cognitivo

ID
A opção a ser escolhida não H1, Informar a Média
A tarefa consistiu em ligar para a empresa X para resolver um Passo 1 é informada pela URA, H2, opção a ser
problema de conexão com a Internet. A tabela 1 apresenta os Questão II pois ela deixa opção H6, escolhida, não
resultados dos passos realizados pelo especialista ao utilizar a "oculta", nesse caso a H7, deixá-la oculta
opção é "aguardar sem H8, e acrescentar
interface multimodal, relacionando os passos apresentados em digitar nada" e a URA não H10 feedback
5.1.3 e às questões do percurso cognitivo apresentadas em 5.1.4. informa desta forma,
entretanto, somente o
Tabela 01 – Resultado do percurso cognitivo usuário mais experiente
consegue entender isso
Passo 01 Passo 02 Nesse caso a URA está H2, Retirar a Média
Questão I – Sim Questão I – Sim Passo 2 falando sobre torpedo com H6, mensagem
Questão protocolo e não sobre o H7, sobre torpedo
Questão II - Sim, porém a opção a ser Questão II – Sim III suporte que está sendo H8,
escolhida não é informada pela URA, pois buscado o que dificulta no H9,
ela deixa a opção “oculta”. O usuário deve Questão III - Sim, porém somente entendimento da tarefa H10
aguardar e não digitar. A URA, porém, usuários mais experientes O usuário deve aguardar H1, Informar a Média
não informa isto ao usuário. compreenderão o que está sendo Passo 3 vários segundos até a URA H7, opção a ser
solicitado. Questão I informar outros dados e H8, escolhida,
Questão III – Não e II chegar na opção desejada H9 diminuir o
Questão IV – Sim
tempo de
Questão IV – Sim
resposta
Passo 03 Passo 04 Essa opção está junto com H6, Separar as Média
Passo 3 outra na mesma escolha e H7, opções
Questão I - Sim, porém a URA informa Questão I – Sim Questão acaba confundindo o H9
dados sobre conta e usuário deve aguardar IV usuário
Questão II – Sim A falta do feedback do H1, Acrescentar Média
até informar a opção desejada.
Passo 4 sistema deixa o usuário na H6, feedback
Questão III – Sim
Questão II - Sim, porém o usuário deve Questão dúvida, ela não informa que H10
aguardar vários segundos até a URA Questão IV - Sim, porém a falta IV avançou para a próxima
informar outros dados e chegar na opção de feedback do sistema deixa o etapa
desejada. usuário na dúvida, não informando
que o usuário avançou para a
Questão III – Não
próxima etapa. No Passo 1, Questão II e Passo 2, Questão III, praticamente os
Questão IV - Sim, porém essa opção está mesmos princípios foram violados. Elas iniciam com a opção do
junto com outra função na mesma opção, menu a ser escolhida não sendo informada pela URA, deixando
o que confunde o usuário.
opção "oculta". Neste caso a opção é "aguardar sem digitar nada" e
Passo 05 a URA não deixa esta informação explícita. Somente o usuário mais
Questão I – Sim Questão II – Sim Questão III – Sim Questão IV - Sim experiente consegue compreender que deve aguardar, o que
dificulta no entendimento da tarefa fazendo com que a interface
Analisando a Tabela 01, percebe-se que no cruzamento das desrespeite a heurística H1, “Visibilidade do status do sistema”.
respostas fornecidas, a avaliação do percurso identificou 12 Desrespeitou também a heurística H2, “Correspondência entre o
respostas “Sim”, 6 respostas “Sim, porém” e 2 respostas “Não”. sistema e o mundo real”, onde o sistema deve ter uma linguagem
Através desta análise, pode-se concluir que a tarefa proposta neste clara com os usuários. Com palavras, frases e conceitos comuns ao
sistema possui 60% das etapas para chegar ao objetivo estão claras usuário. A heurística H6, “Flexibilidade e eficiência de utilização”
para o usuário. também foi desrespeitada, pois o sistema deve atender a ambos os
Várias heurísticas dentre as levantadas em 5.2 foram usuários, inexperientes e experientes. O princípio H7, “Estética e
desrespeitadas. No próximo tópico, será possível verificar as design minimalista” foi desrespeitado, pois os diálogos não devem
heurísticas e as recomendações para melhoria na navegabilidade da conter informações desnecessárias ou raramente utilizadas. O
URA analisada. 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

28
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
desrespeitado, pois a URA deveria fornecer um retorno imediato
após as ações executadas pelos usuários.
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
imediato que o sistema deve oferecer após as ações executadas
pelos usuários.
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”.
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
imediato que o sistema deve oferecer após as ações executadas
pelos usuários.
6. CONSIDERAÇÕES FINAIS
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.
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.
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
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.
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
[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).
[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. 177-
205.
[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
[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.
[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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
[9] Morgan, G. (1980). Paradigms, metaphors, and puzzle solving
in organization theory. Administrative science quarterly, 605-622.
[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.
[12] Nielsen, J.. Heuristic evaluation. In Nielsen, J., and Mack,
R.L. (Eds.). (1994b) Usability Inspection Methods, John Wiley &
Sons, New York, NY).
[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
30
[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
[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).
[16] Triviños, Augusto N.S. Introdução á pesquisa em ciências
sociais: a pesquisa qualitativa em educação. São Paulo: Atlas,
1987.
[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.
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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
Faculdade AVANTIS
Curso de Sistemas de Informação
Balneário Camboriú, SC, Brasil
guara_st@hotmail.com
RESUMO
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.
Palavras-Chave
Interface. UI Design. Android Design.
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.
Categories and Subject Descriptors
D.2.m [Software Engineering]: Miscellaneous
General Terms
Interface. UI Design. Android Design.
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.
Rodrigo Cezario da Silva
Faculdade AVANTIS
Curso de Sistemas de Informação
Balneário Camboriú, SC, Brasil
rodrigo.cezario@avantis.edu.br
Keywords
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].
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
31
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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. 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.
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.
32
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.
3. METODOLOGIA DE PESQUISA
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.
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);
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

(ii) estratégias de design (); e, (iii) elementos de UI. A User  Selecionador

Interface (UI), ou interface do usuário é a camada na qual o usuário  Barra de Progresso
interage com a aplicação, tudo o que o usuário deseja fazer com a  Controle de Recarga
aplicação, as tarefas que deseja executar, são feitos através de  Botão Segmentado
interações com a interface.  Slider
Tabela 1. Classificação e organização do Guia  Stepper
 Chaveador
Classificações Recomendações  Campo de Texto
 Conceitos Básicos para Interface
 Layout e Adaptatividade Para compor esta interface são utilizados elementos de interface,
Considerações
 Navegação em conjunto com padrões para uso dos mesmos, cores e tipografia.
básicas de UI
 Interatividade e Feedback As estratégias de design consistem em vários componentes que são
(user interface)
 Animação utilizados para fazer com que a interface contenha os padrões e
 Cor e Tipografia elementos necessários para proporcionar uma boa experiência ao
 Integridade Estética e Consistência usuário. No entendimento da [9], integridade estética trata de
Estratégias de aspectos da aparência visual de um software aplicada na interação
 Manipulação Direta
design da sua interface. No entanto, este termo não é comumente utilizado
 Metáforas
na literatura, sendo que talvez o termo mais apropriado seria
 Barra de Status
usabilidade. A Tabela 2 apresenta um exemplo elaborado na
 Barra de Navegação
construção do Guia, onde é descrito as recomendações para a
 Barra de Ferramentas utilização da Barra de status. A norma ISO/IEC 9126-1 [24]
 Botões da Barra de Navegação e barra descreve que a usabilidade é composta de subcaracterísticas, sendo:
de Ferramentas aprensibilidade, a capacidade do produto de software de possibilitar
Elementos de
 Barra Tabulada que o usuário aprenda por si só a utilizar a aplicação;
UI
 Barra de Busca operacionalidade, onde o produto dá a possibilidade ao usuário de
 Barra de Escopo operá-lo e controlá-lo; inteligibilidade, sendo a capacidade do
 Indicador de Atividade software possibilitar o usuário de compreender se ele é apropriado
 Selecionador de Data para o seu uso; e atratividade, o quanto o software é atraente ao
 Paginador 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.
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.
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
 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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
5. CONCLUSÃO
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.
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
[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
[3] Pew Research, The rise of apps culture, 2010. Disponível em
< http://goo.gl/Zwc5fK>. Acessado em 28/03/2015
[4] Sebrae, Aplicativos para celulares movem mercado
bilionário, 2014. Disponível em <http://goo.gl/tRp2zQ>.
Acessado em 28/03/2015
[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
[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
[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
[11] Pilone, D., Pilone, T. 2013. Use a Cabeça! Desenvolvendo
para iPhone e iPad, 2 ed., Alta Books: Rio de Janeiro
[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>.
Acessado em 10/05/2015
[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
[21] Stone et al,. 2004. User Interface Design and Evaluation,
Steve Krug. Disponível em <https://goo.gl/CQEdLz>.
Acessado em 10/05/2015
[22] Banga, C., Weinhold, J. 2014. Essential Mobile Interaction
Design, Pearson Education
[23] Dclick, Guideline iOS – Características da Plataforma – 1,
2012. Disponível em <http://goo.gl/Qyg8xM>. Acessado em
10/05/2015
[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
[25] Basili, V., Caldiera, G., Rombach, H. D. Goal Question
Metric Approach, 1994, Encyclopedia of Software
Engineering, pp. 528-532, John Wiley & Sons, I
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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
Universidade Federal de Santa Catarina
(48) 9973-2889
augusto.tepedino@gmail.com
RESUMO
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.
Palavras-Chave
Testes. Integração. Automação. Flex.
ABSTRACT
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.
Categories and Subject Descriptors
D.2.5 [Testing and Debugging]
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.
1
http://www.adobe.com/products/flex.html
35
Jean Carlo Rossa Hauck
Departamento de Informática e Estatística -
INE/CTC
Universidade Federal de Santa Catarina
(48) 3721-7507
jean.hauck@ufsc.br
General Terms
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.
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.
Nesse sentido, a padronizações e a automação de testes destacam-
se 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.
Assim, o presente trabalho apresenta um estudo de caso de
desenvolvimento de automação de testes para a plataforma Flex1
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

com objetivo de reduzir a falha humana e a necessidade de repetir 

R5: Suportar as versões mais recentes dos navegadores:
testes manuais no sistema legado. Firefox, Chrome, Internet Explorer, e Opera;
 R6: Suportar testes automatizados em Aplicações Web;
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  R7: Possuir documentação abrangente;
abordagem metodológica deste trabalho é brevemente apresentada;  R8: Ser capaz de utilizar um repositório central para que
na seção 4 o estudo de caso é descrito e na seção 5 as conclusões múltiplos usuarios possam utilizar os scripts gerados
são apresentadas. Após a execução das buscas nas ferramentas de pesquisa indicadas,
foram encontradas as seguintes ferramentas que satisfazem, ao
1. ESTADO DA ARTE menos em parte, os requisitos propostos (vide Tabela 1).
Como o presente trabalho trata da automação de testes de uma Tabela 1. Ferramentas selecionadas
aplicação legada sobre a plataforma Flex, este tópico apresenta Ferra Descrição R R R R R R R R
relatos na literatura de experiências similares, buscando por
menta 1 2 3 4 5 6 7 8
soluções de automação já experimentadas para essa plataforma.
Flex- Extensão da ferramenta + + + + + + - +
Assim, a busca por trabalhos similares foi realizada em consulta as Selenium para a plataforma
ui-
seguintes ferramentas de pesquisa: Google Flex, estendendo as
(http://www.google.com), Google Scholar Seleni possibilidades de uso do
(http://scholar.google.com), Portal CAPES (http://www- Selenium Webdriver, e
um2 pode gerar scrpits nas
periodicos-capes-gov-
linguagens Java, C#, Perl,
br.Ez46.periodicos.capes.gov.br/index.php?option=com_phome),
Ruby, e PHP.
pela facilidade de acesso e relevância como fontes de pesquisa, FlexM Aplicativo Adobe AIR + + - + + + + +
procurando envolver tanto referências da literatura quanto gratuito, desenvolvida pela
experiências da indústria. onkey3 GorillaLogic que permite
a criação de testes
Nessas ferramentas de busca, foram utilizadas as seguintes palavras automatizados em
de busca: “Software”, "Teste automatizado", "Flex" e algumas plataformas AIR e Flex.
variações/complementos: “Automação de testes de software”, Badbo Ferramenta de automação + + + - + + + +
“benefícios de testes automatizados”, “automatização de testes com de testes baseada na
Flex”, “Diferenças entre Flex e HTML”. Também foram utilizadas y4 interface gráfica do usuário
nas pesquisas as traduções na língua inglesa dos mesmos termos. (GUI - Graphics User
Interface), trabalhando
Sobre os resultados encontrados, para selecionar aqueles mais com a movimentação do
pertinentes a esta pesquisa, os seguintes critérios de inclusão foram mouse e com um script,
utilizados: usando de modo
Record/Playback para
 Ferramentas de automação de Testes com suporte à tornar ações do usuário em
plataforma Flex: pois uma ferramenta para automatizar Scripts.
testes que não suporta a plataforma Flex, não é relevante Testm Ferramenta gratuita que + + + ? - + -
ao trabalho; consegue tornar um script
aker5 de teste em um teste
 Plug-ins de automação de teste para Flex: tendo mesmo funcional, um teste de
motivo de procura como foi relatado no critério acima; carga, ou um teste de
 Relatos de experiência de automação de teste com Flex: performance, que cria
para saber como ferramentas trabalham nesta plataforma scripts em Java, Ruby,
e ter uma melhor decisão sobre o software escolhido Python, e PHP.
Para apoiar a busca, alguns requisitos de automação de testes para Sikuli6 Ferramenta de automações + + + + + + + +
uma ferramenta legada sobre plataforma Flex foram identificados, de teste hibrida, na qual
trabalha tanto com GUI,
com base: (i) nas características de ferramentas de automação de
como com scripts de
testes já previamente identificadas na literatura; (ii) nas usuário. Interage com a
necessidades para automação de testes coletadas por meio de tela a partir da captura de
entrevistas com analistas de testes da empresa desenvolvedora do imagens, ou regiões,
software (vide seção 4); e (iii) em entrevista com o gerente de definidas no script.
projetos da empresa desenvolvedora do software; e, especialmente, Bugbu Extensão feita para o + + + ? - + + -
(iv) nas limitações técnicas de automação de testes na plataforma Google Chrome,
ster
Flex, que impossibilita a utilização de webdrivers por não permitindo a criação de
manipular html diretamente: Test testes a partir de cliques
feitos na janela do browser
Recor
 R1: Possuir alguma versão gratuita
 R2: Suportar testes automatizados; d7
 R3: Estar atualizada e possuir comunidade ativa; Legenda: +: atende, -: não atende, ?: não foi possível determinar.
 R4: Suportar testes automatizados sobre Flex;

2 https://code.google.com/ p/flex-ui-selenium/ 6 http://www.sikuli.org/

3 https://www.gorillalogic.com/flexmonkey 7 https://bugbuster.com/
4
http://www.badboy.com.au/
5 http://www.pushtotest.com/index.php

36
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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. ESTUDO DE CASO
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.
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
8 11
http://www.oracle.com/technetwork/pt/java/javase/downloads/index.html
9 12
http://www.eclipse.org/downloads/
10
http://www.jython.org/
37
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.
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.
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.
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.
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
http://www.sparxsystems.com.au/products/ea/
http://www.pgadmin.org/
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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
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.
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.
Tabela 2 - Comparações entre teste manual e teste
automatizado
Métricas Teste Manual Teste
Automatizado
Elaboração dos casos de teste 05h00min 05h00min
Elaboração Scripts de Testes - 07h30min
Automatizados
Tempo médio de execução 00h08min 00h02min30seg
Total Duração 05h08min 12h32min30seg
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.
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.
Tabela 3 - Resultados do questionário
Questões Concordam
Facilidade na compreensão dos testes 80%
Cenários cobriram a funcionalidade proposta 80%
A infraestrutura disponibilizada para o ambiente de 80%
testes foi satisfatória para a execução dos testes
O tempo gasto com teste automatizado diminui 100%
esforços de custo e tempo com execuções repetitivas
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
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.
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.
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.
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.
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.
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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
l.nvieira@hotmail.com
RESUMO
Muitos problemas têm sido tratados pela bioinformática, en-
tre estes, se destaca a predição de funções biológicas de pro-
teı́nas. A complexidade deste tipo de aplicação vem da pró-
pria estrutura de organização da proteı́na que descreve estas
funções utilizando uma hierarquia estruturada em árvores
ou em grafos acı́clicos dirigidos. A maioria dos classifica-
dores de proteı́nas disponı́veis na literatura utiliza na etapa
de pré-processamento o método de discretização, que tem a
função de transformar os atributos contı́nuos das bases de
dados em intervalos discretos representados por atributos
nominais. Este artigo ilustra a alteração do funcionamento
do algoritmo HLCS-Multi que utiliza o método de discreti-
zação, para utilizar valores reais, que permitirá estimativas
mais precisas sobre os resultados.
Palavras-Chave
Descoberta do Connhecimento, Mineração de Dados, Pré-
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 co-
mes from the protein organization structure that describes
these functions using a structured hierarchy tree or directed
acyclic graph. Most protein binders available in the litera-
ture uses the pre-processing step the discretization method,
which has the function of transforming the continuous attri-
butes of databases in discrete intervals represented by no-
minal attributes. This article illustrates the change in the
functioning of the HLCS-Multi algorithm that uses the dis-
cretization method to use actual values, which will enable
more accurate predictions about the results.
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, 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
Luiz Melo Romão
Depto de Informática - Univille
Joinville - SC - Brasil
luiz.melo@univille.br
Categories and Subject Descriptors
H.4 [Information Systems]: Miscellaneous
General Terms
Information Systems
Keywords
Knowledge Discovery, Data Mining, Pre-Processing
1. INTRODUÇÃO
Muitos problemas têm sido tratados pela bioinformática,
entre estes, se destaca a predição de funções biológicas de
proteı́nas. A complexidade deste tipo de aplicação vem da
própria estrutura de organização da proteı́na que descreve
estas funções utilizando uma hierarquia estruturada em ár-
vores ou em grafos acı́clicos dirigidos.
Devido a essa diversidade de funções, as proteı́nas exer-
cem papel fundamental em quase todos os fenômenos bioló-
gicos, como produção de energia, defesa imunológica, contra-
ção muscular, atividade neuroquı́mica e reprodução [2]. De
acordo com [4], as proteı́nas podem variar na sua composi-
ção, sequência e número de aminoácidos, por isso, é possı́vel
uma enorme variação de sua estrutura e de sua função.
A maioria dos classificadores de proteı́nas disponı́veis na
literatura utiliza na etapa de pré-processamento o método
de discretização ou normalização que podem ocasionar perda
de informação no processo de classificação.
A proposta deste trabalho é desenvolver um algoritmo
para a classificação da função de proteı́nas que possa traba-
lhar durante todas as etapas da extração do conhecimento
com qualquer tipo de atributo, sendo este numérico ou ca-
tegórico. Para isso, será utilizado como base o algoritmo
HLCS – Multi (Hierarchical Learning Classifier System Mul-
tilabel) proposto em [11] que apresenta um modelo global
hierárquico multirrótulo para a predição de problemas hi-
erárquicos, mas que utiliza o método de discretização na
etapa de pré-processamento
Além desta seção introdutória, o artigo foi dividido nas
seguintes seções. A fundamentação teórica dos conceitos
principais utilizados no trabalho. Em seguida é relatada as
caracterı́sticas do algoritmo HLCS – Multi e as alterações
propostas para este projeto. Finalizando serão mostrados os
resultados alcançados e as considerações finais do trabalho
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
2. FUNDAMENTAÇÃO TEÓRICA
A Descoberta de Conhecimento em Banco de Dados (KDD
do inglês, Knowledge Discovery in Database), é um processo
de extração de informações de base de dados, que cria rela-
ções de interesse que não são observadas pelos especialistas
no assunto.
O KDD pode ser visto como o processo de descoberta de
padrões e tendências por análise de grandes conjuntos de
dados, tendo como principal etapa o processo de mineração,
consistindo na execução prática de análise e de algoritmos
especı́ficos que, sob limitações de eficiência computacionais
aceitáveis, produz uma relação particular de padrões a partir
de dados. A extração de conhecimento refere-se às etapas
que produzem conhecimentos a partir de dados relaciona-
dos, e sua principal caracterı́stica é a extração não-trivial de
informações implicitamente contidas em uma base de dados
[8].
A Figura 1 demonstra de uma maneira simplificada todas
as fases do KDD.
Figura 1: Fases do Processo de KDD [8].
O produto esperado da extração de conhecimento é uma
informação relevante para ser utilizada pelos tomadores de
decisão. Este processo leva a descoberta de informações aci-
onáveis em grandes conjuntos de dados à procura de pa-
drões consistentes, como regras de associação ou sequências
temporais, para detectar relacionamentos sistemáticos entre
variáveis, detectando assim novos subconjuntos de dados.
O pré-processamento de dados é frequentemente tido como
sendo uma fase que envolve uma grande quantidade de co-
nhecimento de domı́nio. Entende-se que essa fase depende
da capacidade de analisar os dados e identificar problemas
nos dados presentes. Esta fase de pré-processamento tende-
se a consumir a maior parte do tempo dedicado no pro-
cesso de descoberta do conhecimento. Como a necessidade
de apresentar os dados em uma forma apropriada para a
técnica de mineração de dados escolhida, requer toda uma
preparação para a classificaçã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 valo-
res desconhecidos, ruı́do (atributos com valores incorretos),
atributos de baixo valor preditivo, grande desproporção en-
tre o número de exemplos de cada classe, entre outros.
Entre as técnicas utilizadas na fase de pré-processamento
de dados pode se citar o uso de técnicas de discretização e
normalização, que são técnicas que transformam atributos
de dados contı́nuos, em valores categóricos.
40
O método de discretização tem a função de transformar os
atributos contı́nuos das bases de dados em intervalos discre-
tos representados por atributos nominais. A discretização
pode ser dividida em duas principais categorias: aprendiza-
gem supervisionada e não supervisionada, que é uma área
de inteligência artificial, cujo o objetivo é desenvolver téc-
nicas computacionais que possibilitem que o sistema tome
decisões baseadas nas experiências acumuladas. Conforme
[11] na discretização supervisionada, existe uma interdepen-
dência entre os valores das variáveis e a classe das instâncias
do conjunto de treinamento, já a não supervisionada não
leva em consideração a informação de classes das instâncias
do conjunto de treinamento. De acordo com [6], o objetivo
da discretização é reduzir o número de valores das variáveis
contı́nuas, agrupando as em um número n de intervalos.
A normalização de dados consiste em ajustar os valores de
cada atributo, de forma que os valores fiquem em pequenos
intervalos. É uma série de passos que é seguido para um
projeto de banco de dados, e a execução desses passos irá
permitir a criação de um formato lógico e adequado para as
estruturas dos dados, permitindo o armazenamento consis-
tente e eficiente dos dados.
Entretanto, o uso destas técnicas podem ocasionar em
perda de informações, pois em alguns casos estas técnicas
não consideram a relação entre atributos.
O uso de técnicas de discretização ou normalização po-
dem ser encontrados em diversos trabalhos disponı́veis na
literatura, para a classificação da função de proteı́nas. Os
principais trabalhos identificados, nesta pesquisa foram: [7],
[11], [1] e [5]
3. ALGORITMO HLCS MULTI
Conforme [11], o algoritmo Hierarchical Learning Classi-
fier System Multilabel (HLCS – Multi), apresenta uma so-
lução global hierárquica multirrótulo para a classificação da
função de proteı́nas respeitando a hierarquia das classes em
todas as fases de desenvolvimento do sistema. É desenvol-
vido especificamente para trabalhar com bases hierárquicas
e utiliza como modelo de desenvolvimento os Sistemas Clas-
sificadores (LCS), que é um método que gera seus resultados
em um conjunto de regras no formato SE-ENTÃO, que são
representações, de acordo com [9] mais compreensı́veis do
que outros modelos como redes neurais, máquinas de vetor
de suporte entre outros. O HLCS – Multi é o primeiro mo-
delo baseado em Sistemas Classificadores para a predição de
problemas hierárquicos multirrótulo.
Para trabalhar com dados hierárquicos, o HLCS – Multi
apresenta um componente especı́fico para esta tarefa que é
o componente de avaliação dos classificadores. Este com-
ponente tem a função de analisar as predições dos classi-
ficadores considerando a hierarquia das classes. Além do
componente de avaliação, a arquitetura HLCS – Multi con-
siste dos seguintes módulos: população de classificadores,
componente AG, componente de desempenho e componente
de cessão de créditos, que interagem entre si.
Em geral, o sistema HLCS – Multi cria sua população de
classificadores através da análise dos exemplos do ambiente,
que representam os dados de treinamento. A medida que o
HLCS – Multi interage com o ambiente, por meio dos compo-
nentes de desempenho e cessão de créditos, os classificadores
são avaliados e recebem um retorno na forma de uma re-
compensa que impulsiona o processo de aprendizagem. Este
processo de aprendizagem tem a intervenção do componente
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
de avaliação, que ajuda no cálculo da recompensa avaliando
as predições do sistema conforme a sua hierarquia. No fim
desta etapa, os classificadores passam por um mecanismo de
evolução através do componente AG, que utiliza algoritmos
genéticos como base para a melhoria do conhecimento atual
do sistema.
A questão multirrótulo é trabalhada durante todas as eta-
pas de treinamento e teste do modelo por meio de um pro-
cesso de decomposição das instâncias e na forma de análise
das predições.
4. SOLUÇÃO PROPOSTA
A solução proposta neste artigo é chamada de HLCS –
MultiND (Hierarchical Learning Classifier System Multila-
bel No Discretizate). Baseada no algoritmo HLCS – Multi,
esta versão tem como diferencial a possibilidade de traba-
lhar durante todas as etapas da extração do conhecimento
com qualquer tipo de atributo, sendo este numérico ou ca-
tegórico. Para isso foi realizada uma mudança no algoritmo
HLCS – Multi permitindo que as regras geradas pelo classi-
ficador possam criar condições de intervalos entre os atribu-
tos.
A primeira função do sistema é criar uma população inicial
de classificadores, através de uma análise feita nas instân-
cias da base de treinamento de tamanho N, que representa
a fonte de dados do sistema. Para formar cada classifica-
dor da população inicial, o algoritmo escolhe aleatoriamente
uma instância da base de treinamento como modelo. Cada
atributo da instância de treinamento será criado uma con-
dição no classificador. Está instância será definida por uma
condição que receberá como parâmetro OP, VL, A/I, sendo:
• OP: operador de relação (=, <= ou >=)
• VL: valor da condição
• A/I: opção de ativa (A) ou inativa (I) da condição, que
significa se a condição será utilizada na classificação ou
não.
No inı́cio as condições começam com o operador de relação
(OP) “= ou <= ou =>” a escolha dos operadores de compa-
ração ocorre de forma randômica. O valor da condição (VL)
recebe o valor do atributo da instância em treinamento e
aletoriamente, de acordo com a probabilidade definida nas
configurações iniciais do algoritmo, é decidido se a condição
ficará ativa (A) ou inativa (I).
Conforme relatado anteriormente, esta versão tem como
diferencial a possibilidade de trabalhar com qualquer tipo
de atributo, sendo este numérico ou categórico, possibili-
tando a leitura de bases com valores nominais e contı́nuos.
Para isso, foi desenvolvido um método intermediário, o qual
é executado sempre na leitura de bases ou comparação de
valores, para analisar a sequência de entrada de dados, as-
sim tornando possı́vel o processo de “parser” dos valores, que
possibilitou determinar sua estrutura gramatical, evitando a
necessidade de realizar a discretização na base. Na geração
de regras iniciais passou a utilizar o método de operado-
res randômicos, o qual pode retornar os operadores igual
=, maior igual >= e menor igual <=, que foi modificado
para contemplar mais operadores. Com essas modificações,
tornou-se necessário criar condições randômicas para as va-
riáveis também, onde é resgatado um valor aleatório dentro
de um intervalo de mı́nimo e máximo retirado da primeira
41
lista de regras iniciais. Está lista de mı́nimo e máximo é
criada após a leitura da base de dados, e a cada geração
de regra inicial, assim evitando a necessidade de ler a lista
de regras novamente e aumentando a performance. Para a
medição da performance foi implementado métodos que re-
gistraram o tempo inicial da execução e tempo final, os quais
são relatados no fim do processo.
Além das regras já listadas, também foi alterado o algo-
ritmo para sempre gerar uma nova população inicial, sempre
que não for identificada uma lista de regras iniciais para o
grupo corrente de atributos e valores que estão sendo proces-
sados. Com essas alterações foi possı́vel trabalhar durante
todas as etapas da extração do conhecimento com qualquer
tipo de atributo, possibilitando a execução do algoritmo em
bases com atributos nominais e contı́nuos, descartando a ne-
cessidade de utilizar o método de discretização, tornando o
algoritmo mais eficaz e compreensı́vel o bastante para que
os pesquisadores consigam analisar e confiar nas prediçõ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
versão HLCS – Multi publicados em [12]. Os experimentos
foram realizados em três conjuntos de dados de funções de
proteı́nas, Cellcycle, Church e Derisi que foram utilizados
em [13] e estão disponı́veis em (http://dtai. cs. kuleuven.be
/clus /hmcdatasets). Estas bases contêm informações de
classes baseadas nos termos da Ontologia Gênica (GO) e
são organizadas em uma estrutura em forma de um DAG.
A Tabela 1 apresenta os detalhes das bases utilizadas nesta
experiência.
Tabela 1: Resumo dos conjuntos de dados utili-
zados no experimento. A primeira coluna (’Base
de dados’) define o nome da base de dados, a se-
gunda coluna (’Trein.’) define o número de exem-
plos de treinamento, a terceira coluna (’Teste’) de-
fine o número de exemplos de teste, a quarta coluna
(’Atrib.’) define o número de atributos de cada base
e a quinta coluna (’Classes’) define o número de clas-
ses na classe hierárquica.
Base de Dados Trein. Teste Atrib. Classes
Cellcycle 2473 1278 77 4126
Church 1627 1278 27 4126
Derisi 2447 1272 63 4120
O desempenho dos resultados foi comparado utilizando as
medidas de precisã hierárquica (hP), revocação hierárquica
(hR) e Medida-hF (hF) proposto em [10]. Este método segue
o padrão das conhecidas medidas de Revocação, Precisão
e Medida – F, com as seguintes alterações: cada exemplo
pertence não somente a sua classe, mas também a todos os
ancestrais da classe em um gráfico hierárquico, exceto o nó
raiz.
Os experimentos foram realizados utilizando como proce-
dimento o método de validação cruzada fator 10 e os resul-
tados são descritos como valores-médios e desvio padrão.
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

cesso de discretização e aumentando o grau de confiabilidade

Tabela 2: Valores das medidas hR, hP e hF obtidas dos dados.
nos três conjuntos de dados. De acordo com os testes, os resultados apresentados pelo
algoritmo HLCS – Multi, ainda são melhores que os obti-
HLCS-Multi
dos pelo HLCS – MultiND. Entretanto é importante deixar
hP hR hF
claro que as regras criadas pelo algoritmo proposto, são mais
Cellcyle 0.2611 ± 0.04 0.4209 ± 0.02 0.3223 ± 0.03 compreensı́veis para que os pesquisadores consigam analisar
Church 0.2259 ± 0.02 0.6183 ± 0.03 0.3309 ± 0.04 e confiar nas predições recebidas. Acredita-se que através
Derisi 0.2948 ± 0.03 0.5655 ± 0.03 0.3873 ± 0.03 de alguns ajustes neste modelo, é provável que se consiga
HLCS-MultiND resultados parecidos ou até superiores.
hP hR hF Pretende-se também realizar testes com outros tipos de
Cellcyle 0.2052 ± 0.05 0.1803 ± 0.04 0.1919 ± 0.05 base de dados para auxiliar no refinamento do algoritmo.
Church 0.2048 ± 0.04 0.1800 ± 0.06 0.1916 ± 0.05
Derisi 0.2042 ± 0.04 0.1798 ± 0.05 0.1912 ± 0.05 7. 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,
De acordo com os testes, o HLCS – Multi mostrou me- 2008.
lhores resultados do que o HLCS – MultiND nas três bases [2] P. Balid and G. A. Pollastri. Machine-Learning
analisadas. Porém, segundo [9], um fator importante para a Strategy for Protein Analysis. IEEE Intelligent
predição da função de proteı́nas, é que o modelo de predi- Systems, 17, 2002.
ção desenvolvido, além de ser eficaz, deve ser compreensı́vel [3] G. E. A. P. Batista. Pré-processamento de dados em
o bastante para que os pesquisadores consigam analisar e aprendizado de máquina supervisionado. PhD thesis,
confiar nas predições recebidas. Sendo assim, a principal Universidade de São Paulo, 2003.
vantagem do modelo HLCS – MultiND com relação a ver-
[4] M. K. Campbell. Bioquı́mica. ArtMed, 2000.
são HLCS – Multi é a forma com o qual o modelo apresenta
[5] R. Cerri and A. C. P. L. F. Carvalho. New top-down
os resultados gerados.
methods using svms for hierarchical multilabel
Um exemplo desta diferença pode ser visto na tabela 3.
classification problems. In International Joint
Como o HLCS – Multi realiza o processo de discretização, as
Conference on Neural Networks, pages 1–8. IEEE,
regras geradas são imprecisas, pois utiliza intervalo de da-
2010.
dos como valores dos atributos, dificultando o trabalho dos
pesquisadores. Entretanto no modelo proposto os resultados [6] K. J. Cios, W. Pedrycz, R. W. Swiniarski, and L. A.
são mais especı́ficos e fáceis de serem interpretados. Kurgan. Data Mining: A Knowledge Discovery
Approach. Springer-Verlag New York, Inc., Secaucus,
NJ, USA, 2007.
Tabela 3: Exemplo de Regras geradas pelos Algorit- [7] A. Clare and R. D. King. Predicting gene function in
mos saccharomyces cerevisiae. Bioinformatics, 19:42–49,
2003.
Versão Exemplo Regra [8] U. M. Fayyad, G. Piatetsky-Shapiro, P. Smyth, and
SE cln3-1=(0.041-0.828) e R. Uthurusamy, editors. Advances in knowledge
cln3-2=(-0.228-0.45) e discovery and data mining. American Association for
HLCS – Multi e...e clb2-2=(-0.528-0.268) Artificial Intelligence, Menlo Park, CA, USA, 1996.
ENTÃO [9] A. A. Freitas, D. C. Wieser, and R. Apweiler. On the
Proteı́na é da classe GO0005634 importance of comprehensible classification models for
SE cln3-1>=-0.828 e protein function prediction. IEEE/ACM Trans.
cln3-2<=-0.15 e Comput. Biol. Bioinformatics, 7(1):172–182, Jan.
HLCS - MultiND e...e clb2-2>=-0.2158 2010.
ENTÃO [10] S. Kiritchenko, S. Matwin, and A. F. Famili.
Proteı́na é da classe GO0005634 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.
6. CONCLUSÃO [11] L. M. Romão. Classificação Global Hierárquica
A contribuição dessa pesquisa foi apresentar um estudo Multirrotulo da Função de Proteı́nas Utilizando
de caso de mineração de dados e o uso de técnicas de pré- Sistemas Classificadores. PhD thesis, Pontifı́cia
processamento de dados em algoritmos de classificação de Universidade Católica do Paraná, 2012.
proteı́nas, alterando o funcionamento do algoritmo HLCS [12] L. M. Romão and J. C. Nievola. Hierarchical
– Multi para uma nova versão chamada de HLCS - Mul- Multi-label Classification Problems: An LCS
tiND (Hierarchical Learning Classifier System Multilabel No Approach. Advances in Intelligent Systems and
Discretizate). Esta versão foi desenvolvida para trabalhar Computing, 373:97–104, 2015.
durante todas as etapas da extração do conhecimento com [13] C. Vens, J. Struyf, L. Schietgat, S. Džeroski, and
qualquer tipo de atributo, sendo este numérico ou categó- H. Blockeel. Decision trees for hierarchical multi-label
rico, diminuindo a perda de informação causada pelo pro- classification. Mach. Learn., 73(2):185–214, Nov. 2008.

42
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

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 - Centro Universitário de Brusque - Centro Universitário de Brusque -
UNIFEBE UNIFEBE UNIFEBE
Rua Dorval Luz, 123 Rua Dorval Luz, 123 Rua Dorval Luz, 123
Brusque – SC - Brasil Brusque – SC - Brasil Brusque – SC - Brasil
jonathan_nau@live.com pedrozanchett@gmail.com wagnercorreia@hotmail.com.br

Antonio Eduardo de Barros Marcos Rodrigo Momo

Ruano UNIFEBE
University of Algarve - Faro Rua Dorval Luz, 123
Email: aruano@ualg.pt Brusque – SC - Brasil
marcos.rodrigomomo@gmail.com

RESUMO
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.
Palavras-Chave
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.
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 Categories and Subject Descriptors
not made or distributed for profit or commercial advantage and that copies
E.2 Data Storage Representations. G.3 Probability and
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 Statistics: Statistical software. H. Information Systems: H. 2.8.
specific permission and/or a fee. Database Applications: Data mining.
SBSI 2016, May 17–20, 2016, Florianópolis, Santa Catarina, Brazil.
Copyright SBC 2016.

43
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

1. INTRODUÇÃO se definir como problemas as enchentes a ser analisado para uma

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].
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.

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.
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.
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.
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.

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 Figura 2. Ruído de dados.
do processo KDD mais detalhadamente.

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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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.
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.
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.
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
 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.
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 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.
Tabela 1. Mineração de dados da chuva
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

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.977
Nível do rio em Botuverá > 0.559
Nível do rio em Botuverá > 0.73
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
Nível do rio em Botuverá <= 1.393
Nível do rio em Botuverá > 0.554
THEN
Nível do rio em Brusque =
-0.0001 * Acumulado de chuva em Botuverá
+ 0.2425 * Nível do rio 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 Figura 6. Segunda regra;
dividir os dados em três cluster, cada cluster representa uma
massa de dados. O cluster 1 por exemplo representa apenas 2% IF
dos dados analisados, que correspondem a dezesseis meses em Nível do rio em Botuverá <= 1.846
que a precipitação de chuva chegou em aproximadamente 112 THEN
Nível do rio em Brusque =
milímetros de chuva, com desvio padrão de 19 milímetros. Nele 0.0203 * Nível do rio em Botuverá
ainda se observa que alguns meses tiveram mais ocorrência que + 1.4469 [192/55.59%]
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 Figura 7. Terceira regra
vez no cluster 2 temos uma média de 63 milímetros de IF
precipitação da chuva, este cluster possui um percentual de Nível do rio em Botuverá <= 2.793
ocorrência no valor de 30% e são destaques os meses de fevereiro, THEN
Nível do rio em Brusque =
março, setembro e dezembro. Por fim a precipitação que mais -0.003 * Acumulado de chuva em Botuverá
ocorre em Brusque com 68% de ocorrência fica na média de 29 - 0.121 * Nível do rio em Botuverá
milímetros, com os meses de maio a agosto em destaque. + 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.
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.
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].
Figura 8. Quarta regra.
Nível do rio em Brusque =
- 0.0254 * Acumulado de chuva em Botuverá
+ 1.1194 * Nível do rio em Botuverá
- 0.2767 [15/72.772%]
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.
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

A primeira grande fase demanda mais tempo no processo KDD, [4]. CARDOSO, O. N. P., MACHADO, R. T. M. Gestão do
geralmente fica em torno de 80% do trabalho realizado durante a conhecimento usando data mining: estudo de caso na
extração do conhecimento de uma base de dados. As etapas que Universidade Federal de Lavras. Revista de
foram descritas também podem ser repetidas durante a extração, Administração Pública. Rio de Janeiro 42(3): 495-528,
apesar de ser apresentado uma sequência para a extração dos Maio/Jun. 2008.
dados a mesma pode ser alterada conforme necessidade, também [5] ALBERG, D.; LAST, M.; KANDEL, A. Knowledge
é possível voltar para alguma etapa anterior caso seja necessário, discovery in data streams with regression tree methods,
é aconselhável voltar para evitar erros na consolidação do 2011.
conhecimento.
[6]. HOLMES, G.; HALL, M.; FRANK, E. Generating Rule
3. CONCLUSÕES E TRABALHOS Sets from Model Trees. In: Twelfth Australian Joint
FUTUROS Conference on Artificial Intelligence, 1999.
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

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 Caique R. Marques Lucas Wanner
Federal University of Santa Federal University of Santa UNICAMP
Catarina Catarina Campinas, Brazil
Florianópolis, Brazil Florianópolis, Brazil lucas@ic.unicamp.br
paladini@lisha.ufsc.br caique@lisha.ufsc.br
Antônio Augusto Fröhlich
Federal University of Santa
Catarina
Florianópolis, Brazil
guto@lisha.ufsc.br

RESUMO and queries; making possible to analyze data using tools

O crescimento das redes de sensores sem fio (WSN) e dos
sistemas de monitoramento de ambientes têm gerado dados
organizados em séries temporais. Bancos de dados relacio-
nais não são ideais para o armazenamento de dados organi-
zados em séries temporais. Como alternativa, apresentamos
uma solução usando um banco de dados distribuı́do especı́-
fico para séries temporais provenientes de redes de sensores
sem fio. Durante 5 meses um sistema de monitoramento real
coletou e armazenou medições em diferentes grandezas uti-
lizando a arquitetura proposta. A arquitetura mostrou ser
capaz de armazenar milhões de séries temporais, sendo um
ambiente confiável para inserções e consultas; assim abrindo
caminho para análise de dados com ferramentas como o Apa-
che 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 orga-
nized as time series. Relational databases are not recom-
mended to store time series data. As an alternative, we pro-
pose 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 architec-
ture. The architecture showed to be able to store millions
of time series, being a trustful environment to insertions
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, 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.
like Apache Spark.
Categories and Subject Descriptors
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 monito-
ramento de ambientes têm surgido [18, 19, 16] e gerado um
grande número de medições em um curto perı́odo de tempo,
tornando-se importante para áreas relacionadas à indústria
[17] e ao meio ambiente [5]. As medições podem ser fei-
tas sobre diversas grandezas, tais como temperatura, umi-
dade, turbidez da água, consumo de energia, presença, etc..
Embora não seja possı́vel prever que tipos de medições se-
rão realizadas, os dados medidos geralmente são organiza-
dos como séries temporais (time series), que são sequências
de observações sobre uma grandeza realizadas ao longo do
tempo. Como os sensores realizam medições periódicas em
intervalos de tempo que podem variar de milissegundos até
dias (de acordo com o ambiente), vários dados podem ser
gerados todos os dias. Banco de dados relacionais tradici-
onais baseados em arquitetura scale-up e SQL, tais como
MySQL e PostgreSQL, não escalam bem com as séries tem-
porais geradas por essas plataformas de monitoramento [2]
por oferecerem recursos que não são otimizados para séries
temporais. Por exemplo, uma vez que dados de séries tempo-
rais são observações realizadas em um determinado instante
de tempo, não é necessário modificar valores passados, desta
forma, utilizar um banco de dados que suporta operações de
alteração de valores (update) é desnecessário.
Para solucionar o problema de escalabilidade para supor-
tar melhor o armazenamento de séries temporais proveni-
entes de redes de sensores sem fio é proposto um banco de

48
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
Figura 1: Funcionamento do sistema de monitoramento.
dados distribuı́do especı́fico para séries temporais.
A seção 2 apresenta uma análise sucinta do ambiente uti-
lizado na coleta das séries temporais; a seção 3 descreve a
arquitetura utilizada; a seção 4 mostra alguns resultados que
puderam ser observados a partir da arquitetura utilizada e,
por fim, a seção 5 apresenta as conclusões obtidas através
da arquitetura apresentada para o problema descrito.
2. ANÁLISE DO AMBIENTE
O prédio Smart Solar Building, da Universidade Federal
de Santa Catarina (UFSC), possui 31 sensores EPOSMote[4]
que somados observam 5 grandezas (temperatura, lumino-
sidade, presença, consumo das tomadas e consumo dos ar
condicionados) e são responsáveis pelo monitoramento e au-
tomação das instalações. A coleta de dados realizada por
esses sensores tem como objetivo: (a) o monitoramento e
a supervisão do prédio; e (b) posterior análise dos dados
mensurados afim de criar uma automação inteligente para o
prédio.
Utilizando o sistema operacional EPOS[3] e o protocolo
TSTP[15], os EPOSMote reportam as medições realizadas
para um gateway, que tem como função se comunicar com
um software SCADA (responsável pelo monitoramento e su-
pervisão dos sensores) e também enviar as medições para um
banco de dados, onde uma futura mineração e análise de da-
dos poderá ser realizada. Uma visão geral do funcionamento
do sistema de monitoramento pode ser visto na Figura 1.
Cada grandeza é 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 medições em apenas 1 hora de observação. De
maneira similar, algumas dezenas de sensores podem gerar
dezenas de milhões de medições em 1 mês de observação.
Desta forma o banco de dados que armazenará as medições
precisa ser robusto, suportar bilhões de registros e uma in-
gestão elevada de dados por segundo. Os dados em formato
de série temporal raramente serão atualizados e têm de ter
registros que contenham, no mı́nimo, alguma marcação de
tempo[2]. Com isso, um sistema de gerenciamento de banco
de dados (SGBD) relacional pode possuir diversas opera-
ções desnecessárias, oferecendo, por exemplo, as operações
de update, transações entre dados e não armazenando uma
marcação de tempo por padrão (necessitando o uso de ı́ndi-
ces especı́ficos). Uma alternativa ao relacional é necessária.
3. ARQUITETURA
A arquitetura do Smart Solar Building começa com a
49
Tabela 1: Tipos de sensores do Smart Solar Building.
Variável Unidade
Presença Booleano (1 ou 0)
Temperatura Graus Celsius (◦ C)
Luminosidade Luminosidade (%)
Ar condicionado Watts (W)
Consumo das tomadas Watts (W)
coleta de dados atravé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 ser-
vidor 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. Porém, antes de os
dados chegarem ao banco de dados é necessário realizar al-
gumas conversões de acordo com o tipo de dado recebido
(temperatura, luminosidade, etc.), pois o dado medido nor-
malmente não se encontra na unidade desejada. Essa con-
versão pode ser feita de duas maneiras: (a) no momento
da medição do dado, utilizando o dispositivo que o mensu-
rou; e (b) em algum momento na cadeia de armazenamento
do dado, utilizando algum computador ou servidor mais ro-
busto. Como operações em ponto flutuante são muito caras
para um dispositivo de Internet das Coisas e estes primam
por economia de energia, escolhemos realizar a conversão
dos dados em algum momento na cadeia de armazenamento
do dado, o que é feito por um programa denominado Lehder
[11]. O Lehder é uma API intermediária entre o Gateway e
o banco de dados, sendo responsável por receber os dados
do Gateway (via HTTP), convertê-los e enviar os dados já
convertidos para o banco de dados.
Devido às caracterı́sticas das séries temporais e os pro-
blemas descritos, um banco de dados especı́fico para séries
temporais, distribuı́do e robusto é desejado. Além disso, um
banco de dados que esteja preparado para Big Data tam-
bém garante a escalabilidade necessária para numerosas e
esparsas redes de sensores sem fio, o que pode ser necessário
de acordo com o ambiente envolvido. Entre as opções de
banco de dados com essas caracterı́sticas estã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 con-
siste de uma interface que utiliza o Apache Cassandra como
banco de dados, otimizando-o para armazenamento de séries
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
Figura 2: Número de medições diárias feitas por sete sensores do Smart Solar Building.
Figura 3: Número de medições realizadas por hora em 2 de março de 2016 no Smart Solar Building.
Figura 4: Arquitetura do Smart Solar Building.
temporais. A escolha se deu justamente pelo KairosDB utili-
zar o Apache Cassandra como banco de dados, que é um dos
mais confiáveis e robustos banco de dados preparados para
Big Data [7]. O KairosDB fornece uma API HTTP para
ingestão e consulta de dados, de forma que a comunicação
com o Lehder é realizada via HTTP.
Uma visão geral da arquitetura descrita do Smart Solar
Building pode ser vista na Figura 4. A tabela 1 mostra os
tipos de sensores (ou variáveis medidas) existentes no Smart
Solar Building.
4. RESULTADOS
Com o ambiente configurado conforme a arquitetura des-
crita acima, pudemos armazenar 14.113.192 medições ao
longo de 5 meses de funcionamento do Smart Solar Building,
com o primeiro dado sendo armazenado em 20 de setembro
50
2015 e o último em 3 de março de 2016. O número de medi-
ções realizadas está abaixo do previsto, pois o prédio ainda
está em ambiente de teste, onde erros relacionados à indis-
ponibilidade de rede, às falhas nos sensores, à configuração
do ambiente e na falta de energia criaram intervalos conside-
ráveis de tempo onde nenhuma medição pôde ser realizada.
Um gráfico exibindo quantas medições cada sensor reali-
zou por dia (similar à Figura 2) foi disponibilizado online [9].
É importante notar que cada uma das 7 variáveis da Figura
2 são medidas por um e apenas um sensor, portanto ”Tem-
peratura 1”não é o número de medições de todos os sensores
de temperatura, mas sim o número de medições realizado
por um único sensor. Como é possı́vel observar na Figura 2,
o número de medições realizadas pelos sensores varia con-
sideravelmente, mas em tempos de estabilidade se mantêm
no intervalo de 3 mil a 9 mil medições por dia. Enquanto
isso, a média de medições realizadas por dia ao longo de 5
meses (”Avg”) gira em torno de 5 mil medições por dia. É
possı́vel notar através da Figura 3 (também disponı́vel on-
line [10]) que a ingestão de dados a cada hora não é muito
alta, ficando na média de 302.8 medições por hora.
Alguns problemas de instabilidade no banco de dados fo-
ram encontrados durante os meses de teste da arquitetura,
mas todos estavam relacionados a má configuração do Apa-
che Cassandra e limitações fı́sicas, como por exemplo falta
de memória RAM.
5. CONCLUSÃO
O crescimento do interesse em Internet das Coisas (IoT) e
Redes de Sensores Sem Fio (WSN) tem se tornado evidente
nos últimos anos e a criação de produtos baseados nessas
tecnologias é inevitável. Bancos de dados relacionais tradi-
cionais não estão preparados para tal cenário, fazendo-se ne-
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

cessário o uso de bancos de dados especı́ficos para o problema wicsi-contador-de-medicoes-hora-a-hora?from=

de armazenamento de dados provenientes de WSN. Com a 1456887600000&to=1456973999999. [Online; acessado
arquitetura apresentada foi possı́vel otimizar um problema em 03-Março-2016].
de armazenamento de milhões de medições em um banco [11] LISHA. Repositório Git Lehder.
de dados distribuı́do e especı́fico para séries temporais. Em- https://gitlab.com/lisha/lehder/. [Online;
bora uma elevada ingestão de dados não tenha sido obtida, a acessado em 29-Fevereiro-2016].
arquitetura se mostrou estável durante as inserções e consul- [12] Newts. Site oficial do Newts. http://newts.io/.
tas realizadas (inclusive com testes preliminares utilizando [Online; acessado em 26-Fevereiro-2016].
o Apache Spark para realizar análise dos dados). Conclui- [13] OpenTSDB. Site oficial do OpenTSDB.
se, portanto, que a arquitetura proposta pôde suportar um http://opentsdb.net/. [Online; acessado em
ambiente onde milhões de medições serão feitas sem grandes 26-Fevereiro-2016].
problemas, entretanto maiores testes precisam ser realizados [14] Prometheus. Site oficial do Prometheus.
para descobrir se a arquitetura consegue escalar para bilhões http://prometheus.io/. [Online; acessado em
de medições. 26-Fevereiro-2016].
Para trabalhos futuros é pretendido: (1) testar a arqui-
[15] D. Resner and A. A. Fröhlich. Design Rationale of a
tetura descrita com uma ingestão de dados mais elevada,
Cross-layer, Trustful Space-Time Protocol for Wireless
podendo chegar a bilhões de medições; (2) integrar a arqui-
Sensor Networks. In 20th IEEE International
tetura com ferramentas de processamento de dados parale-
Conference on Emerging Technologies and Factory
las, tais como Apache Spark, e realizar mineração de dados
Automation (ETFA 2015)., pages 1–8, Luxembourg,
sobre os dados coletados; (3) armazenar dados de sensores
Luxembourg, Sept. 2015.
utilizando geolocalização ao invés de associar medições com
um sensor especı́fico. [16] R. Rushikesh and C. M. R. Sivappagari. Development
of iot based vehicular pollution monitoring system. In
International Conference on Green Computing and
6. REFERÊNCIAS Internet of Things (ICGCIoT), pages 779–783. IEEE,
[1] C. Data. Site oficial do Warp10. October 2015.
http://www.warp10.io/. [Online; acessado em [17] A. Tiwari, P. Ballal, and F. L. Lewis. Energy-efficient
26-Fevereiro-2016]. wireless sensor network design and implementation for
[2] T. Dunning and E. Friedman. Time Series Databases: condition-based maintenance. ACM Transactions on
New Ways to Store and Access Data, pages 25–36. Sensor Networks (TOSN), 3, 3 2007.
O’Reilly Media, 2014. [18] C. Xiaojun, L. Xianpeng, and X. Peng. Iot-based air
[3] A. A. Fröhlich and W. Schröder-Preikschat. EPOS: an pollution monitoring and forecasting system. In
Object-Oriented Operating System. In 2nd ECOOP International Conference on Computer and
Workshop on Object-Orientation and Operating Computational Sciences (ICCCS), pages 257–260.
Systems, volume CSR-99-04 of Chemnitzer IEEE, January 2015.
Informatik-Berichte, pages 38–43, Lisbon, Portugal, [19] J. Zambada, R. Quintero, R. Isijara, R. Galeana, and
June 1999. L. Santillan. An iot based scholar bus monitoring
[4] A. A. Fröhlich, R. Steiner, and L. M. Rufino. A system. In IEEE First International Smart Cities
Trustful Infrastructure for the Internet of Things Conference (ISC2), pages 1–6. IEEE, October 2015.
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 mediçõ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-Março-2016].
[10] LISHA. Contador de medições (hora a hora).
https://iot.lisha.ufsc.br:3000/dashboard/db/

51
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
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
felipe.moskado@gmail.com, {menolli,glauco,rgcoelho}@uenp.edu.br,luan.sm50@gmail.com
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.
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.
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.
52
Categories and Subject Descriptors
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.
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.
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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

em uma única base de dados PostgreSQL, permitindo

permit a consulta estão os valores dos atributos na perspectiva
desses dados de fontes externasas por meio da d utilização da multidimensional na base de dados relacional.
tecnologia Foreign Data Wrapper (FDW), possibilitando uma  OLAP: São as ferramentas de consulta
Ferramentas OLAP
melhor análise em conjunto dos dados [3]. para os usuários finais.
finai Nesta fase, os dados já foram
mapeados e podem e devem ser visualizados de maneira
2. REVISÃO
EVISÃO BIBLIOGRÁFICA simples pelo responsável da tomada de decisão, que são
Nesta seção são apresentados alguns dos principais conceitos acessados por meio de um servidor ROLAP.
bases para o desenvolvimento do trabalho.
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
DW é o resultado do processo de transformação dos dados obtidos 2.2 FOREIGN DATA WRAPPER
de sistemas legados e de bancos de dados transacionais que ficam O FDW é um modelo para escrever um módulo para acessar
organizados sob um formato compreensível ao usuário, auxiliando dados externos baseado no padrão SQL/MED, este é um padrão
na tomada de decisão [5]. No entanto, como mencionado para acessar objetos remotos [6]. A Figura 2 ilustra como é
anteriormente, o processo de criação de um DW é custosa e aplicado este conceito no banco de dados PostgreSQL,
PostgreSQL pois o
demorada, o que muitas vezes se torna um empecilho para que, esmo oferece um melhor suporte para essa tecnologia.
mesmo tecnologia A
principalmente pequenas e médias empresas o implantem. Dessa estrutura é dividida em 3 partes dentro do Sistema Gerenciador de
forma foi proposta a metodologia Agile ROLAP,
ROLAP que tem como Banco de Dados (SGBD) são: os Wrappers, os “local” tables, e
intuito mitigar alguns problemas encontrados na implantação de as Foreign Tables.
BI, principalmente diminuindo tempo com o processo de Extract
Transformation Loading (ETL).. Apesar da metodologia não Os Wrappers são drivers que apontam para outros tipos de bancos
utilizar o conceito tradicional de DW, consegue-se
consegue por meio de de dados, além de existir um para o próprio PostgreSQL. Por
seu uso utilizar as ferramentas Online Analytical Processing exemplo, na Figura 2 existe um wrapper chamado mysql_fdw,
(OLAP) disponíveis no mercado. que automaticamente aponta para um banco de dados MySQL,
pois o PostgreSQL sabe que esse é o driver do MySQL e lá que
Assim, a metodologia visa diminuir o tempo despendido no n estão armazenados os dados originais.
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 As Foreign Tables são cópias da estrutura das tabelas originais da
DW se dá no processo de ETL [4]. Isto permite que pequenas base de dados de origem. Ass mesmas mantém uma imagem de
empresas possam usufruir de ferramentas OLAP voltadas para tempo real do que está sendo armazenado na tabela original e caso
ambientes de BI tradicionais, proporcionando auxilio na tomada esta seja modificada é também alterada a Foreign Table. Nestas
de decisão do administrador da organização baseado nas tabelas não é possível fazer alterações nos dados, somente
informações geradas,, assim podendo conhecer melhor sobre o seu consultas.
negócio
ócio além de competir melhor no mercado
mercado. O “local” tables ou servidor é onde as Foreign Tables são
A Figura 1 mostra como é o funcionamento do Agile ROLAP e a armazenadas. Esteste local pode ser chamado de servidor.
servidor Os
função de cada etapa apresentada na Figura 1 é descrita a seguir: 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
 Físico: representa bases de dados originais. Os dados desejadas. Um wrapper pode ter vários servidores que apontam
das empresas estão armazenadas em tabelas relacionais. para diferentes bases de dados do mesmo banco de dados.
 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á consultandodo 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, Figura 2 - Estrutura do Foreign Data Wrapper
paraa os dados que devem ser mostrados na forma pós ser criado toda a estrutura do FDW, esta tecnologia permite
Após
dimensional. Basicamente esse schema indica onde ao banco de dados PostgreSQL reunir inúmeros dados de

53
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

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 Após a base intermediária ser estruturada com as Foreign Tables,
todos plugins necessários para a implantação completa do Agile são utilizados três plugins que vão usufruir desses dados
Rolap. Além disso, o Kettle é uma ferramenta que permite a integrados, que são: O tempo, a dimensão e o fato. A Figura 4
utilização de plugins para realizar transformações de dados mostra como funcionam os plugins citados anteriormente em
complexos nos dados que darão origem a um ambiente de BI. conjunto no Kettle.
Basta utilizar um conjunto de plugins interligados entre si, além O plugin dimensão facilita a modelagem da dimensão que será
de facilitar o processo de ETL. O Kettle é uma plataforma de utilizada no ambiente de BI. Nele os dados são carregados na base
integração de dados completa, que permite a análise dos dados de intermediária, ou seja, por meio das Foreign Tables criadas. A
forma precisa, podendo obter os dados de qualquer fonte de dados Figura 4 mostra a dimensão Cliente e Produto que utilizam os
e permitindo sua manipulação por meio de componentes visuais, dados das Foreign Tables Cliente e Produto, das suas respectivas
eliminando assim a codificação e a complexidade na integração bases.
dos dados [7].
O plugin tempo auxilia a construção de tabelas de tempo que o
A Figura 3 ilustra a interface do plugin desenvolvido no Kettle. A ambiente de BI precisa, e por meio deste são geradas novas
tela é composta pela Conexão Destino, Conexão Origem e uma tabelas na base de dados intermediária utilizada pelo ambiente de
tabela. A Conexão Destino é responsável por fazer a conexão BI, com o objetivo de permitir uma análise temporal dos dados.
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 O plugin fato auxilia a criação de uma view que atua como o fato
foi criado o FDW, além do usuário e senha. Para conseguir ver o de um modelo dimensional. Como se utiliza diretamente os dados
conteúdo do campo “Servers do FDW” é necessário que todos os da base de dados da organização é necessário agrupar as medidas
campos anteriores estejam preenchidos, assim será mostrado todos em uma nova estrutura. Os dados desta view são carregados por
os servidores criados no FDW, diminuindo a chance de erro na meio das Foreign Tables criadas na base intermediária, assim
hora de criar a Foreign Table. 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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016
4. RESULTADOS
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.
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.
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 5 – Comparação do desempenho de acesso OLAP a
três tecnologias.
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.
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.
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
5. CONSIDERAÇÕES FINAIS
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.
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.
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.
[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”.
[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.
[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
 III Workshop de Iniciação Científica em Sistemas de Informação, Florianópolis, SC, 17 a 20 de Maio de 2016

Í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
W
Marques, Caique R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Wanner, Lucas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Martins, Augusto B.T. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Mello, Leonardo R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Z
Melo, Luan S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 52
Zanchett, Pedro S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5,43
Menolli, André . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 52
Momo, Marcos R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

56