Embed Size (px)
Citation preview
SISTEMA DE APOIO À INTERATIVIDADE EM REVISÕES SISTEMÁTICAS EM ENGENHARIA DE
SOFTWARE
PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO – PPGSC
DISSERTAÇÃO DE MESTRADO
DIMAp
UFRN
NATAL
1
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA – DIMAp
UFRN
SISTEMA DE APOIO À INTERATIVIDADE EM REVISÕES SISTEMÁTICAS EM ENGENHARIA DE
SOFTWARE
WELLINGTON ALEXANDRE FERNANDES
Apresentado ao Departamento de Informática e Matemática Aplicada da UFRN, como pré-requisito para defesa de Dissertação de Mestrado do Programa de Pós-Graduação em Sistemas e Computação, sob a orientação do Prof. Dr. Eduardo Aranha.
NATAL – RN
2013
UFRN / Biblioteca Central Zila Mamede
Catalogação da Publicação na Fonte Fernandes, Wellington Alexandre. Sistema de apoio à interatividade em revisões sistemáticas em engenharia de software. / Wellington Alexandre Fernandes. – Natal, RN, 2013. 91 f.: il. Orientador: Prof. Dr. Eduardo Aranha.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação.
1. Engenharia de software experimental – Dissertação. 2.
Interatividade – Engenharia de software - Dissertação. 3. Colaboração virtual - Dissertação. 4. Revisão sistemática – Dissertação. I. Aranha, Eduardo. II. Universidade Federal do Rio Grande do Norte. III. Título.
RN/UF/BCZM CDU 004.41
3
RESUMO
A colaboração na pesquisa é uma das tarefas centrais da área acadêmica.
Atualmente, muitos pesquisadores estão utilizando meios modernos de troca de
arquivos digitais através de ferramentas assíncronas e também com o uso de
ferramentas mais sofisticadas, do tipo síncronas. Juntamente com o fato da crescente
quantidade de artigos sendo gerados, mais complexos, diversificados e aumentando de
forma desorganizada, o que trás ao pesquisador uma tarefa difícil para organizá-los de
forma a se extrair o melhor conteúdo destes, isto ocorre porque uma subárea da
Engenharia de Software (ES) ainda é bastante mal aproveitada, a Engenharia de
Software Experimental (ESE). Utilizando-se de um dos tipos de experimentos que a
ESE oferece, as revisões sistemáticas entram como uma solução bastante robusta, na
qual o pesquisador pode identificar o conhecimento existente em uma área e planejar
devidamente sua pesquisa, evitando a repetição de erros em pesquisas já efetivadas por
outros pesquisadores no passado. Contudo, estas duas abordagens, a colaboração virtual
de pesquisadores e a utilização de revisões sistemáticas, contem problemas: na primeira,
sistemas colaborativos são geralmente difíceis de configurar e usar; na segunda, apesar
da robustez da metodologia de revisões sistemáticas, ainda se torna necessário uma
rigorosa revisão na literatura para se conseguir um resultado satisfatório. Assim, com o
foco de unir estas duas abordagens, este trabalho propõe uma maneira de produzir
revisões sistemáticas de forma organizada e com a possibilidade de interação entre
usuários, com o desenvolvimento de um sistema interativo, no qual as revisões
sistemáticas possam ser geradas por usuários em colaboração com outros e também ser
avaliadas seguindo a orientação de um profissional da área, tornando o seu conteúdo
mais consistente e de melhor qualidade. O sistema não possui níveis de acesso, ou seja,
qualquer pessoa pode se cadastrar e usufruir de seus recursos, seja na área acadêmica ou
mesmo na área profissional.
Palavras-chave: Engenharia de Software Experimental, Interatividade, Colaboração
Virtual, Revisão Sistemática.
4
SUMÁRIO
1. Introdução ................................................................................................................9
1.1. Objetivos do trabalho e contribuições esperadas .........................................10
2. Engenharia de Software Experimental .................................................................10
2.1. Revisões de Literatura: Estado da Arte ........................................................13
2.2. Revisões Sistemáticas ......................................................................................16
2.2.1. Revisões Sistemáticas em Engenharia de Software ...........................16
2.2.2. Processo de Revisão Sistemática em Engenharia de Software .........17
2.2.3. Benefícios da Utilização de Revisões Sistemáticas .............................22
2.2.4. Vantagens e Desvantagens ...................................................................22
2.2.5. Conclusões .............................................................................................23
2.3. Trabalhos Relacionados ..................................................................................23
2.3.1. StArt (State of the Art through Systematic Review) .............................23
2.3.2. ReVis (Systematic Review Supported by Visual Analytics) .................25
2.3.3. Ferramentas relacionadas ....................................................................27
2.3.4. Conclusões .............................................................................................27
3. Interatividade ..........................................................................................................28
3.1. Colaboração em documentos ..........................................................................29
3.2. Ferramentas on-line para colaboração de documentos ...............................31
3.2.1. Zoho Writer ...........................................................................................31
3.2.2. ThinkFree ..............................................................................................32
3.2.3. Microsoft Office Live ............................................................................32
3.2.4. Google Docs ...........................................................................................33
3.3. Interatividade em Revisões Sistemáticas .......................................................34
3.4. Conclusões ........................................................................................................35
4. Sistema de Apoio à Interatividade em Revisões Sistemáticas em Engenharia de Software (SAEE) .....................................................................................................36
5
4.1. Hipóteses de Pesquisa ......................................................................................37
4.2. Especificação de Requisitos de Software .......................................................38
4.3. Tecnologia Utilizada no Sistema ....................................................................40
4.4. Definição do Banco de Dados do Sistema ......................................................40
4.5. Funcionamento do Sistema .............................................................................42
4.5.1. Menu do sistema ....................................................................................46
4.5.2. Tabelas dinâmicas .................................................................................46
4.5.3. Criação de revisões sistemáticas ..........................................................47
4.5.4. Listagem de revisões sistemáticas ........................................................48
4.5.5. Adição de contribuintes/avaliadores ...................................................50
4.5.6. Inserção de conteúdo na revisão sistemática ......................................51
4.6. Interatividade na ferramenta SAEE ..............................................................53
5. Planejamento e aplicação do Survey .....................................................................55
5.1. Planejamento e programação do Survey .......................................................55
5.2. Definição da população e tamanho da amostra ............................................57
5.3. Seleção de participantes e motivação .............................................................57
5.4. Produção e definição do questionário ............................................................58
5.5. Métodos para a análise de dados ....................................................................61
5.6. Avaliação do questionário ...............................................................................62
5.7. Análise dos dados .............................................................................................62
5.8. Conclusões ........................................................................................................77
6. Limitações da ferramenta SAEE ...........................................................................78
7. Conclusões e trabalhos futuros ..............................................................................78
APÊNDICE A. Estudo de caso: Aplicação da ferramenta SAEE ............................80
Referências Bibliográficas ............................................................................................87
6
LISTA DE FIGURAS
Figura 1: Processo para a condução de revisões sistemáticas definido em
[KITCHENHAM et al., 2004a] ....................................................................................17
Figura 2: Tela do sistema StArt [HERNANDES et al., 2012] ....................................24
Figura 3: Arquivo inicial de importação da ferramenta ReVis [ICMC-USP et al., 2012] ..............................................................................................................................25
Figura 4: Visualização dos tipos de seleções da ferramenta ReVis [ICMC-USP et al., 2012] ........................................................................................................................26
Figura 5: Diagrama Entidade-Relacionamento do banco de dados da ferramenta SAEE ..............................................................................................................................41
Figura 6: Diagrama de caso de uso da ferramenta SAEE ........................................44
Figura 7: Tela de login do sistema ...............................................................................45
Figura 8: Tela de login do sistema, acesso a “cadastro de usuários” .......................45
Figura 9: Tela de login do sistema, acesso à “esqueci minha senha” .......................45
Figura 10: Menu do sistema .........................................................................................46
Figura 11: Lista de usuários ........................................................................................47
Figura 12: Criação de revisões sistemáticas ...............................................................48
Figura 13: Listagem de revisões sistemáticas .............................................................49
Figura 14: Listagem de contribuintes .........................................................................50
Figura 15: Tela de criação de revisões sistemáticas, inserção de conteúdo .............51
Figura 16: Tela de criação de revisões sistemáticas, área de comentários ..............52
Figura 17: Diagrama de atividades (interação usuário/avaliador) ..........................54
Figura 18: Respostas referentes à questão 1 ..............................................................64
Figura 19: Respostas referentes à questão 2 ..............................................................64
Figura 20: Respostas referentes à questão 3 ..............................................................65
Figura 21: Respostas referentes à questão 4 ..............................................................65
Figura 22: Respostas referentes à questão 5 ..............................................................66
7
Figura 23: Respostas referentes à questão 6 ..............................................................67
Figura 24: Respostas referentes à questão 7 ..............................................................67
Figura 25: Respostas referentes à questão 8 ..............................................................68
Figura 26: Respostas referentes à questão 9 ..............................................................69
Figura 27: Respostas referentes à questão 10 ............................................................69
Figura 28: Respostas referentes à questão 11 ............................................................70
Figura 29: Respostas referentes à questão 12 ............................................................71
Figura 30: Respostas referentes à questão 13 ............................................................71
Figura 31: Respostas referentes à questão 14 ............................................................72
Figura 32: Respostas referentes à questão 15 ............................................................72
Figura 33: Respostas referentes à Categoria 1 ...........................................................73
Figura 34: Respostas referentes à Categoria 2 ...........................................................74
Figura 35: Respostas referentes à Categoria 3 ...........................................................74
Figura 36: Fórmula de cálculo do resultado da Categoria 1 de questões ................74
8
LISTA DE TABELAS
Tabela 1: Propostas de estruturação para relatar experiências controladas. Adaptado de [JEDLITSCHKA et al., 2007] ..............................................................15
Tabela 2: Processo para a condução de revisões sistemáticas [KITCHENHAM, 2007] ...............................................................................................................................21
Tabela 3: Funcionalidades de ferramentas relacionadas [HERNANDES et al., 2012] ..............................................................................................................................27
Tabela 4: Tempo de resposta do questionário definitivo ..........................................57
Tabela 5: Questões do questionário ............................................................................59
Tabela 6: Tipos de respostas contidas no questionário .............................................61
Tabela 7: Respostas dissertativas dos participantes ..................................................77
9
1. Introdução
A colaboração na pesquisa é uma das tarefas centrais da área acadêmica.
Atualmente, muitos pesquisadores estão utilizando meios modernos de troca de
arquivos digitais normalmente através de e-mails ou ferramentas assíncronas que fazem
a comunicação entre as partes em tempo não-real e, por vezes, com o uso de
ferramentas mais sofisticadas, nas quais se baseiam em sistemas de controle de versão,
como Concurrent Versioning System (CVS) e Subversion (SVN). No entanto, existem
razões das quais motivam usuários a não utilizarem estes tipos de sistemas, uma delas é
que sistemas colaborativos são geralmente difíceis de configurar e usar, a configuração
típica requer instalação e configuração de aplicativos de servidor e do lado do cliente; a
segunda razão é o fato de que sistemas como o CVS / SVN, algumas vezes, encontram
problemas em lidar com o conceito de conflitos.
Juntamente com o fato da crescente quantidade de artigos sendo gerados, cada
vez mais complexos, diversificados e aumentando de forma desorganizada, o que trás
ao pesquisador uma tarefa difícil, pois ao procurar por certo assunto, este encontrará
uma grande quantidade de conteúdo, o que é bom, porém maçante para organizá-los de
forma a se extrair o melhor conteúdo destes. Isto ocorre porque uma subárea da
Engenharia de Software (ES) ainda é bastante mal aproveitada ou até não utilizada em
alguns casos, a Engenharia de Software Experimental (ESE). Esta última fornece meios
de avaliar tecnologias de forma consistente e cientificamente embasada, em que todos
os resultados passam por uma experimentação que pode afirmar com certo grau de
probabilidade que certa tecnologia é melhor ou não que outra. Dessa forma, utilizando-
se de um dos tipos de estudos que a ESE oferece, as revisões sistemáticas entram como
uma solução bastante robusta, na qual o pesquisador pode revisar a literatura à procura
de indícios que possam levar à identificação de evidências sobre um tema de pesquisa, e
assim planejar devidamente sua pesquisa, evitando a repetição de erros em pesquisas já
efetivadas por outros pesquisadores no passado. Contudo, apesar da robustez da
metodologia de revisões sistemáticas, ainda se torna necessário uma rigorosa revisão na
literatura para se conseguir um resultado satisfatório.
Assim, com o foco de unir estas duas abordagens, a colaboração virtual de
pesquisadores e a utilização de revisões sistemáticas, este trabalho propõe uma maneira
de produzir revisões sistemáticas de forma organizada e com a possibilidade de
interação entre usuários, um aluno e um professor, por exemplo, com o
10
desenvolvimento de um sistema interativo, no qual as revisões sistemáticas possam ser
geradas por usuários em colaboração com outros e também ser avaliadas seguindo a
orientação de um profissional da área, tornando o seu conteúdo mais consistente e de
melhor qualidade. O sistema não possui níveis de acesso, ou seja, qualquer pessoa pode
se cadastrar e usufruir de seus recursos, seja na área acadêmica ou mesmo na área
profissional.
1.1. Objetivos do trabalho e contribuições esperadas
Este trabalho objetiva criar um sistema de apoio à interatividade em Revisões
Sistemáticas voltado à área acadêmica, como alunos, professores e pesquisadores. Dessa
forma, para avaliar a proposta deste sistema, foi aplicado um survey, o qual avaliou a
proposta do sistema mostrando um vídeo demonstrativo que expõe uma situação
comum entre pesquisadores de se unirem para realizar uma RS, e aplicado um
questionário para avaliar a proposta do sistema visto no vídeo. As contribuições
esperadas são a comprovação de que a área acadêmica possa receber com grande
expectativa uma ferramenta interativa para apoio a realização de RS, e também pretende
revelar quais as opiniões de pesquisadores que já utilizam RS em relação a proposta da
ferramenta.
2. Engenharia de Software Experimental
A Engenharia de Software Experimental, subárea da Engenharia de Software,
pode ser entendida como uma ferramenta utilizada para planejamento, análise, execução
e interpretação de resultados de estudos experimentais. Dessa forma, com o uso de
estudos, pode-se analisar o impacto de mudanças tecnológicas.
Com o propósito de avaliar teorias da ciência da computação, para que melhorias
nos processos e produtos da Engenharia de Software sejam obtidas e disponibilizadas
para a indústria, técnicas de investigação científica devem ser aplicadas. Para
[AMARAL et al., 2003], um dos grandes interesses nos estudos experimentais é a
crescente visão popular de que a Engenharia de Software deva ter fortes fundamentos de
uma disciplina científica de engenharia, e que as técnicas para melhorar o
desenvolvimento de software e sistemas e para a evolução dos processos devam estar
disponíveis aos profissionais. O experimento tem como objetivo não somente a
execução de estudos individuais, mas também estabelecer um melhor entendimento do
11
desenvolvimento do software, o custo e benefícios da utilização de várias técnicas e por
fim a consolidação de um corpo de conhecimento e o estabelecimento de modelos
adequados de desenvolvimento de software.
Os estudos experimentais devem ser realizados para garantir a credibilidade da
pesquisa em Engenharia de Software, tornando público a outros pesquisadores o
conhecimento utilizado na execução de um experimento e permitindo, desta forma, um
melhor entendimento e análise dos resultados obtidos no estudo realizado.
Assim, [WOHLIN et al., 2000] definiu quatro métodos relevantes para condução
de experimentos na área de Engenharia de Software: científico, de engenharia,
experimental, e analítico.
[AMARAL et al., 2003] diz que o método científico observa o mundo, sugerindo
o modelo ou a teoria de comportamento, medindo e analisando, verificando as hipóteses
do modelo ou da teoria. Iste é um paradigma indutivo, no qual tenta extrair do mundo
algum modelo que possa explicar um fenômeno, e avaliar se o modelo é realmente
representativo para o fenômeno que está sob observação. É uma abordagem para
construção de modelos.
O método de engenharia observa as soluções existentes, sugere as soluções mais
adequadas, desenvolve, mede e analisa, e repete até que nenhuma melhoria adicional
seja possível. Para [AMARAL et al., 2003], esta é uma abordagem orientada à melhoria
evolutiva que assume a existência de algum modelo do processo ou produto de software
e modifica este modelo com propósito de melhorar os objetos do estudo.
O método experimental sugere o modelo, desenvolve o método qualitativo e/ou
quantitativo, aplica um experimento, mede e analisa, avalia o modelo e repete o
processo. É uma abordagem orientada à melhoria revolucionária. Para [AMARAL et al.,
2003], o processo se inicia com o levantamento de um modelo novo, não
necessariamente baseado em um modelo já existente, e tenta estudar o efeito do
processo ou produto sugerido pelo modelo novo.
O método analítico (ou matemático) sugere uma teoria formal, desenvolve a
teoria, deriva os resultados e se possível, compara-a com as observações empíricas. Para
[AMARAL et al., 2003], este é um método dedutivo que não precisa de um projeto
experimental no sentido estatístico, mas oferece uma base analítica para o
desenvolvimento de modelos.
12
Para [TRAVASSOS et al., 2002], os objetivos relacionados à execução de
estudos em Engenharia de Software são a caracterização, avaliação, previsão, controle e
melhoria a respeito de produtos, processos, recursos, modelos, teorias entre outros.
Dessa forma, ele entende que a importância e o esforço aumentam de um estudo com o
objetivo "caracterização" a um estudo com o objetivo "melhoria", significando que é
bastante simples conduzir um estudo com a finalidade de caracterização respondendo
questionamentos como "o que está acontecendo?". Da mesma forma, ele diz que é mais
difícil medir algo, como um processo ou produto e defini-lo respondendo
questionamentos como "quão bom é isto?", os estudos com a finalidade de previsão
além da medição precisam de meios de estimativa para mostrar a possibilidade de:
"posso estimar algo no futuro?". Para atender a finalidade de controle deve existir a
possibilidade de gerenciar os atributos de um processo ou produto e dar a resposta a
"posso manipular o evento?". Finalmente, a finalidade da melhoria supõe que possamos
caracterizar, avaliar, predizer e controlar, e há os objetivos da melhoria de um processo
ou produto que possam ser atingidos respondendo a última questão "posso melhorar o
evento?".
Apesar de haver diferentes tipos de estudos, a literatura indica alguns deles como
sendo os principais em estratégias de estudo, são eles:
Survey: é uma investigação executada em retrospectiva, é conduzido quando
algumas técnicas ou ferramentas já tiverem sido utilizadas, tem como
objetivos: a descrição, que determina a distribuição de atributos ou
características; explanação, em que explica porque os desenvolvedores
escolheram uma das técnicas; e exploração, como um estudo preliminar para
uma investigação mais profunda. Sua coleta de informações é feita por
questionários.
Estudo de caso: monitora os projetos, atividades e atribuições, visam
observar um atributo específico e estabelecer o relacionamento entre atributos
diferentes. Existem três formas de utilizá-los: comparação dos resultados;
projetos semelhantes, que comparam resultados de projetos que utilizaram
diferentes tecnologias; e método aleatório, que aplica um método
aleatoriamente atribuído a um projeto e não atribuído aos outros.
Experimento: é geralmente realizado em laboratório e oferece maior nível de
controle, objetiva manipular uma ou algumas variáveis e manter as outras
13
fixas medindo o efeito do resultado, podem ser feitos in-vitro sob condições
de laboratório ou in-vivo sob condições normais.
Pesquisa ação: é toda tentativa continuada, sistemática e empiricamente
fundamentada de aprimorar a prática [TRIPP, 2006].
Revisão sistemática: é uma revisão rigorosa da literatura à procura de
indícios que possam levar à identificação de evidências sobre um tema de
pesquisa ou tópico na área em questão [TRAVASSOS et al., 2006].
Mapeamento Sistemático: é um tipo de revisão sistemática, onde se realiza
uma revisão mais ampla dos estudos primários, em busca de identificar quais
evidências estão disponíveis, bem como identificar lacunas no conjunto dos
estudos primários onde seja direcionado o foco de revisões sistemáticas
futuras e identificar áreas onde mais estudos primários precisam ser
conduzidos [KITCHENHAM et al., 2004].
Na próxima seção, são descritos como a necessidade e os conceitos desta última
estratégia, revisão sistemática, podem ser utilizadas para auxiliar na ESE.
2.1. Revisões de Literatura: Estado da Arte
A ES não é a primeira área de pesquisa a encontrar problemas com dados
insuficientes em relatórios técnicos gerados por outros pesquisadores. Outras áreas de
pesquisa como medicina e psicologia já partilharam do mesmo problema e, na tentativa
de solucionar o problema, alcançaram diversos meios de se padronizar o conhecimento
colhido das fontes de pesquisa, como é o caso de Moher [MOHER et al., 2001], que
realizou experimentos controlados de forma aleatória na área biomédica, e APA [APA,
2001], que gerou resultados empíricos de pesquisa psicológica.
Na área de pesquisa da ES, Singer [SINGER, 1999] descreveu como utilizar o
trabalho feito por APA em publicações de resultados de experimentações na ES.
Kitchenham [KITCHENHAM et al., 2002] forneceu as primeiras orientações sobre
como realizar, reportar, e coletar resultados obtidos de estudos empíricos na ES com
base nos padrões das pesquisas médicas. Shaw [SHAW, 2003] forneceu um tutorial
sobre como escrever artigos científicos, incluindo a apresentação da pesquisa empírica
como um caso especial. Além disso, livros sobre estudos empíricos de ES, como
Wohlin [WOHLIN et al., 2000] e Juristo e Moreno [JURISTO E MORENO, 2001],
abordam a questão de utilizar padrões de pesquisa. Wohlin sugere um esquema de
apresentar resultados de estudos empíricos. Juristo e Moreno fornecem uma lista de "os
14
pontos mais importantes a serem documentados de cada fase", na forma de "perguntas a
serem respondidas na documentação experimental".
Jedlitschka [JEDLITSCHKA et al., 2005a] apresentou uma primeira versão de
um guia para relatar experimentos controlados durante um workshop sobre ES, e com o
sucesso pela recepção da comunidade, foi incorporada uma segunda versão
[JEDLITSCHKA et al., 2005b]. Em paralelo, este guia foi avaliado por meio de uma
abordagem baseada em perspectiva feita por Kitchenham [KITCHENHAM et al.,
2006], em que destacou 42 questões em que este guia poderia ser aperfeiçoado, e oito
defeitos. Kitchenham então aprimorou e adaptou este guia podendo ser visualizado em
[KITCHENHAM et al., 2007].
A Tabela 1 mostra uma visão das propostas feitas pelos pesquisadores
mencionados acima, a qual evidencia a estrutura de uma revisão de literatura abordada
em suas pesquisas. A tabela caracteriza as propostas existentes para obter informações
de relatórios sobre pesquisas empíricas. A primeira linha da tabela lista as propostas,
organizadas pela data de publicação. A segunda linha da tabela descreve o foco dos
estudos. O termo "Pesquisa Empírica" indica que os estudos não são adaptados para um
tipo específico de pesquisa empírica, caso contrário, o tipo específico é explicitamente
mencionado, como por exemplo, "experiência controlada" ou "revisão sistemática." A
terceira linha descreve as fases de um experimento orientado pelo respectivo estudo. O
termo "Todas" indica que a diretriz abrange todas as fases de um estudo. O “*” indica
que os autores não mencionam explicitamente ou descrevem detalhes para este
elemento, mas presume-se que os elementos são utilizados implicitamente. As linhas
restantes listam os elementos estruturais das diretrizes propostas.
Observado os trabalhos dos autores na Tabela 1, foi evidenciado a forma de
utilização e construção de Revisões Sistemáticas sugeridas por Kitchenham
[KITCHENHAM et al., 2007], tornando o principal ponto de referência para a obtenção
de uma estrutura bem fundamentada e realizada para utilização neste trabalho.
Dessa forma, o Capítulo seguinte se refere a Revisões Sistemáticas, mostrando
suas características e descrevendo como a necessidade e os conceitos desta podem ser
utilizadas para auxiliar na ES.
[SINGER, 1999] [WOHLIN et al., 2000] [KITCHENHAM et al.,
2002]
[JURISTO E
MORENO, 2001]
[KITCHENHAM et al.,
2007]
Tipo de estudo Experimento controlado Experimento controlado Experimento controlado Experimento controlado Revisão sistemática
Fases do estudo Relatório técnico Todas Todas Todas Relatório técnico
Estrutura * * * * Título
* * * * Autor
* * * * Sumário ou Estrutura Abstrata
Abstract * * *
Introdução Introdução
Identificação do problema
Planejamento do experimento
* Definição de objetivos Referencial teórico
Contexto do experimento Questões de revisão
Identificação do problema Métodos de revisão
Método Planejamento do experimento Projeção do experimento Projeto Estudos inclusos e não-inclusos
Procedimento Operacionalização do
experimento
Condução do experimento e
coleta de dados
Execução do experimento Resultados
Resultados Análise de dados Análise e interpretação de
resultados
Análise do experimento Discussão
Discussão Interpretação de resultados Conclusão
Discussão e conclusão * Agradecimentos
- - - - Conflito de interesses
Referências Referências * * Referências
Apêndices Apêndices * * Apêndices
Tabela 1: Propostas de estruturação para relatar experiências controladas. Adaptado de [JEDLITSCHKA et al., 2007]
2.2. Revisões Sistemáticas
A ciência é uma atividade cooperativa e social, e o conhecimento científico é o
resultado do processo cumulativo dessa cooperação [BIOLCHINI et al., 2005]. Dessa
forma, a revisão de literatura é uma forma para o pesquisador poder identificar o
conhecimento existente em uma área e planejar devidamente sua pesquisa, evitando a
repetição de erros em pesquisas passadas. Porém, a revisão de literatura deve ser
confiável e abrangente, deve utilizar um protocolo pré-estabelecido a fim de gerar um
resultado consistente e confiável. Dessa forma, a revisão sistemática, descrita nas
subseções seguintes, mostra ser a estratégia que mais se adapta na resolução deste
problema.
2.2.1. Revisões Sistemáticas em Engenharia de Software
Apesar de a ESE prover uma grande contribuição a ES, ela não é definitiva, ou
seja, somente a condução de estudos experimentais não é suficiente para uma
caracterização adequada de uma tecnologia. Estudos podem conter fontes de variação
entre diferentes ambientes, exigindo-se que sejam repetidos em diferentes contextos
para uma maior precisão nos resultados. Dessa forma, para agregar novas formas de
estudo, as Revisões Sistemáticas podem ser utilizadas como estudos secundários.
Uma RS atua como um meio para identificar, avaliar e interpretar toda pesquisa
disponível e relevante sobre uma questão de pesquisa, um tópico ou um fenômeno de
interesse [TRAVASSOS, 2006]. A condução de uma RS supostamente apresenta uma
avaliação justa do tópico de pesquisa, à medida que utiliza uma metodologia de revisão
rigorosa, confiável e passível de auditagem [KITCHENHAM, 2004]. A RS também
permite a reutilização de seu conteúdo, parte e/ou integralmente, por outro usuário,
mantendo assim, a estrutura e informações de um estudo revisado e consistente.
Assim, pesquisadores conduzindo RS devem utilizar cada esforço na
identificação e relato de pesquisas que apoiam e que não apoiam suas hipóteses
[KITCHENHAM, 2004]. Fazendo, dessa forma, com que se os estudos identificados se
mostrem consistentes, a RS fornece então demonstrações de que o fenômeno estudado é
robusto e generalizável a outros contextos, caso contrário, suas variações podem ser
estudadas a fim de chegarem a um resultado consistente.
Nesse sentido, uma RS não é um simples rearranjo dos dados já conhecidos ou
publicados, mas sim um novo tipo de abordagem metodológica para fazer pesquisa,
com a finalidade de integrar resultados experimentais. Dessa forma, conduzir uma RS
17
enfatiza a descoberta de princípios gerais, em um nível mais elevado de abstração
conceitual no campo de pesquisa, além de incentivar o diagnóstico e a análise das
inconsistências externas encontradas ao comparar estudos individuais com resultados
contrastantes entre si. Nesse contexto, a condução de RS ajuda a elucidar novos
aspectos na área de investigação, direcionando esforços em pesquisa na área
[BIOLCHINI et al. 2005].
2.2.2. Processo de Revisão Sistemática em Engenharia de Software
Uma revisão sistemática envolve várias atividades, a literatura contém diferentes
tipos de sugestões sobre quantidade, ordem e quais das atividades utilizar. Porém, o
processo de condução das revisões sistemáticas definido por [KITCHENHAM et al.,
2004a] envolve três etapas principais: Planejamento da Revisão, Condução da Revisão e
Publicação dos Resultados; as quais podem ser vistas na Figura 1.
Figura 1: Processo para a condução de revisões sistemáticas definido em
[KITCHENHAM et al., 2004a].
Apesar das etapas parecerem sequenciais, elas envolvem iteração, ou seja,
podem voltar a um estágio para melhorá-lo, se necessário, se o estágio mais a frente
necessitar. Dessa forma, a seguir é mostrada a função de cada uma destas etapas
juntamente com seus estágios:
Planejamento da Revisão: é composta por dois estágios, identificação da
necessidade da revisão e desenvolvimento de um protocolo de revisão, em
que:
o Identificação da necessidade da revisão: vem da necessidade de
pesquisadores de resumir toda a informação existente sobre
algum fenômeno completa e imparcialmente. [KITCHENHAM,
2007] sugere uma checklist com questões sobre objetivos,
identificação de estudos primários, aplicação de critérios, quais e
18
como foram aplicados os critérios, extração de dados de estudos
primários e como foi sintetizado.
o Desenvolvimento de um protocolo de revisão: especifica os
métodos que serão usados para realizar uma revisão sistemática
específica e, para isso, um protocolo pré-definido é necessário
para melhorar as possibilidades do pesquisador. Os componentes
de um protocolo incluem todos os elementos de uma revisão mais
alguns adicionais como estudos anteriores, questionamentos que a
revisão deve responder, estratégia utilizada, critérios e
procedimentos de seleção de estudo, avaliação de qualidade de
estudo, estratégia de extração de dados, síntese dos dados
extraídos e cronograma de projeto.
Condução da Revisão: com o protocolo concluído, a revisão pode ser
iniciada, e esta envolve alguns estágios como identificação da pesquisa,
seleção de estudos, avaliação da qualidade do estudo, extração de dados e
monitoramento do progresso, e síntese de dados. Alguns destes estágios
devem ser sequenciais, porém, alguns podem ser feitos de forma simultânea:
o Identificação da pesquisa: a revisão sistemática tem como
objetivo encontrar o máximo possível de estudos primários
relacionados com a pesquisa em questão utilizando uma
estratégia de pesquisa imparcial, sendo este o rigor do processo
de pesquisa que distingue as revisões sistemáticas das análises
tradicionais.
o Seleção de estudos: quando os estudos primários potencialmente
relevantes estiverem sido obtidos, o estágio de avaliação de
relevância nestes estudos é feito. Neste, é identificado os estudos
que fornecem evidências diretas sobre a pesquisa em questão.
o Avaliação da qualidade do estudo: os critérios de exclusão e
inclusão são geralmente considerados importantes para avaliar a
qualidade dos estudos primários para fornecer ainda mais
detalhamento ao critério de inclusão/exclusão, investigar as
diferenças entre resultados de estudos, ponderar a importância
dos estudos individuais quando os resultados estiverem sendo
sintetizados, orientar a interpretação dos resultados e determinar a
19
importância de suas inferências, guiar recomendações para
futuras pesquisas.
o Extração de dados e monitoramento do progresso: objetiva criar
formas de extração de dados para registrar com precisão as
informações obtidas por pesquisadores nos estudos primários.
Para evitar problemas, a extração de dados deve ser definida e
testada após o protocolo do estudo estar definido.
o Síntese de dados: envolve o agrupamento e resumo dos resultados
dos estudos primários, pode ser especificada na revisão do
protocolo. Pode ser descritiva, ou seja, tabulando a informação
sobre os estudos de forma consistente às questões de revisão,
sendo estruturadas para salientar similaridades e diferenças entre
resultados dos estudos. E pode ser quantitativa, ou seja,
sintetizando os resultados de diferentes estudos, em que os
resultados devem ser apresentados de forma comparativa.
Publicação dos resultados: os resultados de uma revisão sistemática devem
ser comunicados de forma eficaz, sendo reportadas geralmente em dois
formatos, em um relatório técnico ou seção de Tese de Doutorado, ou em
uma publicação de artigo em uma conferência. Artigos podem referenciar um
relatório técnico ou uma Tese que contenha todos os detalhes. A estrutura
sugerida por [KITCHENHAM, 2007] é mostrada na Tabela 2, em que é
apropriada para relatórios técnicos e artigos, mas para Teses de Doutorados,
os itens com asterisco (*) não são relevantes.
Section Subsection Scope CommentsTitle* The title should be short but informative. It should be based on the question
being asked. In journal papers, it should indicate that the study is a systematic review.
Authorship* When research is done collaboratively, criteria for determining both who should be credited as an author, and the order of author’s names should be defined in advance. The contribution of workers not credited as authors should be noted in the Acknowledgements section.
Executive summary or Structured Abstract*
Context The importance of the research questions addressed by the review
A structured summary or abstract allows readers to assess quickly the relevance, quality and generality of a systematic review.
Objectives The questions addressed by the systematic review
Methods Data Sources, Study selection, Quality Assessment and Data extraction
Results Main finding including any meta- analysis results and sensitivity analyses.
Conclusions Implications for practice and future research
Background Justification of the need for the review. Summary of previous reviews
Description of the software engineering technique being investigated and its potential importance
Review questions Each review question should be specified
Identify primary and secondary review questions. Note this section may be included in the background section.
Review Methods Data sources and search strategy
This should be based on the research protocol. Any changes to the original protocol should be reported.
Study selection Study quality assessmentData extraction Data synthesis
Included and excluded studies
Inclusion and exclusion criteria List of excluded studies with rationale for exclusion
Study inclusion and exclusion criteria can sometimes best be represented as a flow diagram because studies will be excluded at different stages in the review for different reasons.
Results Findings Description of primary studies Results of any quantitative summaries Details of any meta-analysis
Non-quantitative summaries should be provided to summarise each of the studies and presented in tabular form. Quantitative summary results should be presented in tables and graphs
Sensitivity analysisDiscussion Principal findings These must correspond to the findings discussed in the results section
Strengths and Weaknesses Strength and weaknesses of the evidence included in the review Relation to other reviews, particularly considering any differences in quality and results.
A discussion of the validity of the evidence considering bias in the systematic review allows a reader to assess the reliance that may be placed on the collected evidence.
Meaning of findings Direction and magnitude of effect observed in summarised studies Applicability (generalisability) of the findings
Make clear to what extent the result imply causality by discussing the level of evidence. Discuss all benefits, adverse effects and risks. Discuss variations in effects and their reasons (for example are the treatment effects larger on larger projects).
Conclusions Recommendations Practical implications for software development
What are the implications of the results for practitioners?
Unanswered questions and implications for future research
Acknowledgements* All persons who contributed to the research but did fulfil authorship criteria
Conflict of Interest Any secondary interest on the part of the researchers (e.g. a financial interest in the technology being evaluated) should be declared.
References and Appendices
Appendices can be used to list studies included and excluded from the study, to document search strategy details, and to list raw data from the included studies.
Tabela 2: Processo para a condução de revisões sistemáticas [KITCHENHAM, 2007].
2.2.3. Benefícios da Utilização de Revisões Sistemáticas
Os benefícios da utilização de Revisões Sistemáticas na Engenharia de Software
são diversos, e podem auxiliar e beneficiar as comunidades acadêmicas e profissionais
da área direta ou indiretamente, dentre estes beneficiários estão:
Estudantes: que podem ser contemplados com maior quantidade de
informações de uma pesquisa pelo alto nível de abrangência na obtenção de
estudos primários conduzidos por revisões sistemáticas, podendo identificar
diversas oportunidades de pesquisa relatadas por outros pesquisadores.
Orientadores: diversos artigos de um determinado tema podem ser obtidos
com a execução do protocolo de revisão sistemática, estes devem passar por
um processo de avaliação, considerando os critérios de inclusão e exclusão
estabelecidos no protocolo. Isso permitiria ao orientador monitorar a pesquisa
a qual esta sendo efetuada por alunos.
Comunidade Acadêmica: a revisão sistemática possibilitaria para a
comunidade acadêmica dispor da caracterização experimental de diversas
tecnologias em uso, a qual poderiam ser continuamente incrementadas
utilizando a repetição dos estudos experimentais em outros contextos
fornecendo um acúmulo de conhecimento para qualquer ramo científico.
Indústria de Software: a revisão sistemática forneceria à indústria de software
resultados experimentais que indicassem a consistência de uma determinada
tecnologia sob certas circunstâncias, tais informações poderiam ser usadas
para tomada de decisão para a aquisição de certa tecnologia.
2.2.4. Vantagens e Desvantagens
A condução de revisões sistemáticas exige um considerável esforço
comparando-se a uma revisão tradicional, porém, sua maior vantagem é o fornecimento
de informações sobre os efeitos de um fenômeno em uma ampla gama de configurações
e métodos empíricos. Assim, com resultados consistentes de um estudo, as revisões
sistemáticas fornecem evidências de que o fenômeno é robusto e transferível, caso
contrário, fontes de variação destes estudos podem ser estudadas a fim de se chegar ao
resultado consistente.
23
2.2.5. Conclusões
A revisão sistemática é um meio bastante útil para tornar um trabalho ainda mais
consistente no que se refere à constatação de resultados em diferentes tipos de situações,
porém, exige-se um minucioso estudo dos resultados anteriores para poder adicionar
informações consistentes ao trabalho, o que muitas vezes torna o uso de revisões
sistemáticas bastante maçante, necessitando um grande esforço para fazer um bom
trabalho. Dessa forma, para auxiliar na geração de revisões sistemáticas, uma
ferramenta torna-se necessária, não apenas para criar, mas para gerenciar as revisões
sistemáticas, uma ferramenta também acadêmica, a qual poderia ser utilizada por alunos
e professores, em que ambos podem interagir, de forma a gerar sugestões e corrigir as
revisões sistemáticas geradas por alunos, em que toda a informação gerada pode ser
disponibilizada para consulta pública, fazendo da ferramenta uma fonte de
conhecimento e estudo de trabalhos científicos. O desenvolvimento desta ferramenta é
uma das propostas deste trabalho, a qual será mostrada nos Capítulos seguintes, seu
funcionamento e características. A seguir, será mostrado alguns sistemas relacionados
ao apoio à geração de revisões sistemáticas, porém, com algumas diferenças da proposta
deste trabalho.
2.3. Trabalhos Relacionados
Na tentativa de apoiar a utilização de RS, alguns pesquisadores e
desenvolvedores criaram ferramentas para dar este suporte, como é o caso de
ferramentas como a StArt (State of the Art through Systematic Review) [HERNANDES
et al., 2012] e a ReVis (Systematic Review Supported by Visual Analytics) [ICMC-USP
et al., 2012]. Dessa forma, um detalhamento maior será feito nas ferramentas
mencionadas e uma tabela apontando outras ferramentas relacionadas também será
mostrada, as quais ocorrem nos Capítulos seguintes.
2.3.1. StArt (State of the Art through Systematic Review)
Esta ferramenta foi desenvolvida por estudantes e pesquisadores da
Universidade Federal de São Carlos, e tem como objetivo ajudar o pesquisador, dando
suporte para a utilização e aplicação de RSs. A ferramenta StArt é bastante robusta,
armazena as revisões de forma bastante organizada, baseia-se na qualidade dos artigos e
trabalhos os quais reúne, salvando suas referências, atribuindo pontuação a estes e
fazendo um filtro dos trabalhos que atingiram uma boa qualidade para serem
24
selecionados e utilizados na revisão sistemática. Uma tabela de artigos consultados é
gerada e, através do objetivo requerido, são avaliados de excelente a ruim, e aceito ou
rejeitado, tornando uma ótima fonte de pesquisa orientada para o usuário. A Figura 2
mostra a tela do sistema com a situação mencionada.
Figura 2: Tela do sistema StArt [HERNANDES et al., 2012].
Na Figura 2 pode-se observar a tela de interação do sistema, em que: no item 1
está o acesso ao planejamento da revisão sistemática, o qual é composto por
informações semelhantes às da Tabela 2; no item 2, encontra-se a área de
armazenamento das informações dos artigos selecionados para a revisão sistemática, a
qual é categorizada em tipos de associações/instituições como IEEE e ACM, e também
contém os artigos separados em aceitáveis, rejeitados duplicados e indefinido; no item 3
está uma lista de artigos, estando nela todos os artigos associados a revisão sistemática,
avaliados e pontuados devidamente por nível de aproveitamento; o item 4 permite
acesso ao documento do artigo, no formato PDF, podendo acessá-los com seu conteúdo
completo.
A ferramenta StArt se mostrou uma ferramenta muito boa, porém, é uma
ferramenta local, ou seja, necessita instalar em uma máquina e utilizar individualmente,
para uso e organização própria, o que a torna limitada no que diz respeito a divulgação e
compartilhamento das RS geradas por uma pessoa.
25
2.3.2. ReVis (Systematic Review Supported by Visual Analytics)
Esta ferramenta foi desenvolvida por um estudante da Universidade de São
Paulo (USP), e tem como objetivo ajudar o pesquisador, dando suporte para a utilização
e aplicação de RS. Esta ferramenta permite a exploração visual de um conjunto de
documentos, ou seja, depois de alimentada com diversos tipos de documentos, é
possível ver quais destes são similares em relação a certos termos como título, abstract,
palavras chave, etc. O que facilita a obtenção de documentos relacionados dentre todos
os que a ferramenta contém. Sua instalação é simples, apenas descompactar um
conjunto de arquivos e iniciá-la. Sua utilização, porém, necessita de um arquivo inicial
o qual o usuário o cria e o importa para a ferramenta, dando assim, inicio ao processo de
criação de uma RS. O formato deste arquivo pode ser visto na Figura 3.
Figura 3: Arquivo “bib” inicial de importação da ferramenta ReVis [ICMC-USP et al., 2012].
Na Figura 3, é possível observar a estrutura do arquivo “bib”, no qual as linhas
têm seus significados, sendo (a) a definição de que o documento é um artigo, seguido de
sua numeração; (b) contém os nomes dos autores do artigo, em que podem ser escritos
com a primeira letra do nome seguido pelo sobrenome, e a separação de autores é feita
por uma vírgula; (c) descreve o título do artigo; (d) é o ano do artigo; (e) descreve o
26
abstract do artigo; (f) descreve as referências, em que cada uma é descrita apenas por
seu título, um por linha. O documento da Figura 3 deve ser gerado em qualquer
aplicativo de edição de texto e salvo com a extensão “bib”, que é a extensão que o
sistema reconhece para ser importada. Com o arquivo gerado e importado no sistema, o
projeto é iniciado, podendo-se atribuir critérios como qualidade e inclusão/exclusão dos
artigos. A principal característica deste sistema é a possibilidade de geração de gráficos
em que são mostrados os relacionamentos entre os artigos adicionados, sendo possível
visualizar diferentes tipos de seleções para apoiar os estudos primários, como é possível
observar na Figura 4.
Figura 4: Visualização dos tipos de seleções da ferramenta ReVis
[ICMC-USP et al., 2012].
Na Figura 4, podem-se observar três figuras, (a), (b) e (c), sendo que: (a)
apresenta o “Mapa de documentos”, em que os pontos indicam estudos primários e a
junção destes com outros, indicam similaridade referente a títulos, abstract e palavras
chave; (b) mostra a “Faixa de bordas”, em que representa uma técnica de visualização
hierárquica em formato de árvore, mostrando nós de estudos primários e
relacionamentos entre nós, as citações; e (c) mostra a “Utilização nas referências” dos
artigos estudados, em que o ponto de borda preta representa estudos primários e os de
borda cinza são as referências, as quais não fizeram parte do conjunto de estudos
primários.
A ferramenta ReVis se mostrou uma ferramenta boa, porém, necessita passar
todos os artigos a serem estudados no formato da Figura 3, o qual não se torna uma
27
forma prática para se descrever sobre um artigo e é uma ferramenta também local, o que
a torna com a mesma limitação da ferramenta StArt.
2.3.3. Ferramentas relacionadas
Na literatura há diferentes ferramentas que dão suporte ao gerenciamento de
referências bibliográficas, elas são geralmente utilizadas por pesquisadores da área
acadêmica. Porém, com exceção das ferramentas SLR Tool, ReVis e SAEE, as
ferramentas não foram desenvolvidas com o propósito de serem utilizadas para a
construção de uma RS, apesar de que podem ser utilizadas com esse fim extraindo os
resultados necessários para tal. Para observar melhor alguns recursos chave destas
ferramentas, a Tabela 3 mostra algumas das ferramentas.
Nome da ferramenta
Livre Gerência de referências
Exportação de referências
Customização de atributos
Classificação automática de
artigos Web
Multi-usuários
Interação entre
usuários JabRef S S S S N N N N EndNote N S S S N N N N ProCite N S N N N N N N Reference Manager N S N N N N N N RefWorks N S S N N N N N BibEdt S S N N N N N N Biblioscape N S N N N N N N Bookends S S S S N N N N Library Master N S S S N N N N Mendeley N S S S N N N N Mekentosj N S S N N N N N SLR Tool S S S N N N N N Review Manager S S N S N N N N StArt S S N S S N N N ReVis S S N N N N N N SAEE S S S/N* S/N* N S S S
Tabela 3: Funcionalidades de ferramentas relacionadas [HERNANDES et al., 2012].
Pode-se observar, na Tabela 3, que a ferramenta SAEE não contém alguns
recursos que outras ferramentas o fazem, porém, é a única que permite a utilização na
web, sem a necessidade de se instalar a ferramenta no computador do usuário, sendo
acessível de qualquer computador, necessitando apenas que este esteja conectado à
internet, e também permite a utilização de múltiplos usuários utilizando a ferramenta ao
mesmo tempo. Os recursos da ferramenta SAEE que foram assinalados com “*”
significam que estes recursos podem ser adicionados à ferramenta posteriormente.
2.3.4. Conclusões
Assim, uma ferramenta que possa ter sua utilização de forma ampliada, global,
que possa ser acessada de qualquer lugar, qualquer pessoa, e que também seja
acadêmica seria uma proposta ainda melhor, pois uma RS não mais seria vista apenas
28
por seu criador, mas sim por todos, e que haja também um incentivo pela parte
acadêmica, em que professores possam interagir nas RS feitas por alunos para que esta
seja mais consistente e que tenha mais qualidade em seu conteúdo.
Para fazer uso destas qualidades acima descritas, a proposta deste trabalho será
de atender a esta finalidade.
O Capítulo seguinte irá mostrar a outra proposta deste trabalho, a interatividade
entre usuários na colaboração para realização de pesquisas através de RS.
3. Interatividade
A interatividade entre usuários tem evoluído muito nas últimas décadas,
tornando possível não mais estar presente fisicamente para se comunicar e tratar de
assuntos diversos. A comunicação virtual tomou lugar neste espaço para facilitar não
somente a interação voltada à diversão e entretenimento, mas também para o avanço em
termos de pesquisas científicas e acadêmicas. Atualmente todos utilizam ferramentas
computacionais de comunicação virtual, algumas do tipo assíncronas e outras do tipo
síncronas, em que ambas são bastante específicas em sua utilização, pois observando
suas características abaixo, no sentido de colaboração de um texto, por exemplo, pode-
se ver como elas funcionam:
Comunicação síncrona: também chamada de comunicação em tempo real, ou
seja, dois usuários enxergam o conteúdo o qual está sendo preenchido um do
outro no momento em que o escrevem, porém, tratamentos de sincronismo
devem ser feitos para se respeitar o conteúdo sem que um usuário não
interfira no conteúdo do outro.
Comunicação assíncrona: também chamada de comunicação em tempo não-
real, ou seja, dois usuários inserem conteúdo em um mesmo documento um
por vez, não necessitando de preocupações voltadas à sincronização das
informações inseridas, pois não haverá simultaneidade na inserção do
conteúdo.
Para um conhecimento mais aprofundado sobre sincronismo na comunicação,
ver [MARTINS et al., 2010], [REIS et al., 2006] e [OTTER et al., 2007]. Observando
os dois tipos de comunicação, é bastante claro que a mais eficiente é do tipo síncrona,
pois uma colaboração entre duas ou mais partes sobre um mesmo documento sendo
feita de forma simultânea é mais proveitosa do que se for feito de forma assíncrona, no
29
qual cada parte poderá inserir o conteúdo no documento apenas um de cada vez.
Sistemas síncronos são baseados na utilização dos chamados CVS e SVN [GERMAN,
2004].
3.1. Colaboração em documentos
Os amplamente utilizados Concurrent Versioning System (CVS) e Subversion
(SVN) são usados para manter repositórios de arquivos textuais. São aplicações cliente-
servidor com características muito semelhantes, em que um único servidor mantém o
repositório de documentos. Um usuário usa o programa cliente para verificar um
documento, faz alterações na cópia local e, em seguida, carrega o documento de volta
para o servidor. Estes sistemas oferecem bons níveis de funcionamento simultâneo, pois
se um documento no repositório é modificado por outro usuário enquanto um deles
estava alterando o conteúdo, quando este primeiro o salvar, o sistema vai tentar fundir
os dois documentos e é geralmente bem sucedido, mas conflitos de atualizações podem
ocorrer que necessitam da intervenção manual para resolver. A probabilidade de
conflitos aumenta à medida que aumenta o tempo de salvamento. Estes tipos de
sistemas são robustos e comprovadamente efetivos, porém, contém uma série de
deficiências que desestimulam sua utilização:
Usuários necessitam aprender um conjunto de comandos e entender como
eles são usados.
Usuários necessitam aprender a lidar com verificação de conflitos. Os
sistemas geralmente fazem relatórios de conflitos, mas muitas vezes verifica-
los não é uma tarefa trivial.
Usuários necessitam ter o software cliente instalado em seu computador.
Um computador em rede deve estar disponível para hospedar o software do
servidor e repositório de documentos. O servidor deve ser configurado
manualmente para permitir que colaboradores possam compartilhar
documentos, necessitando de contas de usuário e senhas para tal.
Embora os documentos de qualquer formato possam ser armazenados no
repositório, somente texto (ACSII) pode ser editado e mesclado no
repositório, limitando a utilidade de tais sistemas para alguns tipos de
documentos que utilizem figuras ou caracteres especiais e/ou símbolos.
30
Porém, mesmo apresentando estes problemas, algumas ferramentas utilizando
CVS e/ou SVN foram desenvolvidas para atender aos usuários mais exigentes. Seguem
alguns sistemas e tecnologias que utilizam estas abordagens:
GOOD [RADAJEWSKI, 2004]: é um sistema proprietário de publicação
totalmente integrado que utiliza um único documento XML para descrever
um documento e fazer com que este esteja disponível em vários tipos de
mídia. Usuários podem colaborar com o documento através da utilização de
um editor XML. O editor é construído sobre um repositório CVS que torna
transparente a complexidade de sincronização para o usuário. No entanto, os
problemas associados com o uso de CVS e SVN ainda se aplicam. Alguns
sistemas ([DOBRATZ, 2005], [MULLER et al., 2005]) semelhantes ao
GOOD são utilizados por outras instituições acadêmicas.
ICE [SEFTON, 2006]: Integrated Content Environment, é outro sistema
desenvolvido com objetivo de colaborar em documentos. O sistema ICE tem
a capacidade de utilizar ferramentas textuais, as quais simulam editores de
texto, através de uma interface web. Para este fim, o ICE converte
documentos binários para o modelo ICE, que é fortemente baseada em
XHTML e estilos CSS, resultando em um formato textual que é gerenciado
por SVN para permitir a colaboração de documentos, porém, mais uma vez
algumas das complexidades e problemas associados com o uso de CVS e
SVN ainda se aplicam.
XML Concurrency: Uma abordagem completamente diferente para a
colaboração de documentos, necessita que os usuários estejam on-line com
um software especial de cliente que se comunica com o servidor de
documentos usando um protocolo específico de colaboração. Esta abordagem
é a utilizada pelo Google Docs. Um tipo diferente de protocolo pode ser visto
em [DEKEYSER, 2004], que utiliza um protocolo de bloqueio para garantir a
seriação e baseia-se na semântica do documento. Em comparação com as
outras abordagens descritas anteriormente, a técnica de controle de
concorrência XML apresenta uma propriedade única e valiosa: documentos
XML descrevendo informações não textuais como gráficos, por exemplo,
também podem ser inseridos, desde que o software cliente implemente o
protocolo do servidor, gerando a possibilidade, por exemplo, de usuários
trabalharem juntos. No entanto, apesar de bastante robusta e apresentar
31
melhores resultados que as ferramentas anteriores, esta abordagem também
contém problemas que possam vir a ser um desestímulo para os usuários.
Estes problemas serão mostrados nos Capítulos seguintes.
Outras ferramentas de colaboração mais conhecidas e de acesso livre que
também são baseadas em CVS e SVN serão mostradas nos Capítulos seguintes, das
quais serão evidenciadas suas características, vantagens e desvantagens.
3.2. Ferramentas on-line para colaboração de documentos
Baseadas na utilização de tecnologias como Javascript e XML/AJAX,
ferramentas de colaboração on-line veem ganhando espaço na vida dos usuários
tornando suas vidas profissionais um pouco mais fáceis em questões de praticidade e
armazenamento de documentos. Ferramentas de colaboração on-line demonstram ser
um grande avanço para os usuários mais exigentes, pois utilizam recursos leves, de
baixo processamento e com bom desempenho. Porém, apesar de robustas, também
contém problemas e/ou limitações que merecem ser consideradas dependendo do tipo
de trabalho que o usuário pretende fazer. Nestes casos ferramentas direcionadas podem
ser mais úteis. Assim, algumas ferramentas de colaboração de documentos on-line são
mostradas nos Capítulos seguintes.
3.2.1. Zoho Writer
Zoho é uma ferramenta de pesquisa colaborativa on-line e livre, disponível em
[ZOHO, 2008], e que oferece vários recursos que podem tornar sua utilização mais
atraente do que a ferramenta mais popular atualmente na internet, o Google Docs.
[DONOVAN, 2010] afirma que algumas características da ferramenta Zoho
podem ser especialmente úteis: no Google Docs, ao escrever um documento em que é
basicamente o formato HTML e, a fim de ver como ele aparece na página, deve-se
exportá-lo e manipulá-lo ainda mais, ao invés disso, a ferramenta Zoho permite a edição
do documento no seu modo de página, permitindo que possa ser visto como ele
aparecerá na página impressa.
Uma desvantagem da Zoho é que, ao contrário do Google Docs, o Zoho não
oferece a funcionalidade Autosave para salvar o trabalho a cada poucos segundos, no
qual usuários podem correr o risco de perder o conteúdo digitado se não salvar o mesmo
constantemente. Outra limitação é que, enquanto o Google Docs pode ser compartilhado
32
com qualquer outro usuário que não tenha uma conta Google, documentos Zoho podem
ser compartilhados apenas com os outros membros Zoho.
Tanto o Google Docs quanto o Zoho suportam edição offline de documentos,
estes são sincronizados na próxima vez que se conectar ao serviço.
3.2.2. ThinkFree
É uma ferramenta de colaboração on-line livre, disponível em [THINKFREE,
2009], se baseia em Javascript e XML, ou AJAX, e construído na linguagem Java.
Exige a criação de uma conta no site da ferramenta para utilização. Dá suporte a
ferramentas da Microsoft, como Word, PowerPoint e Excel, e também contém alguns de
seus recursos. Fornece um espaço máximo de 1GB para cada usuário e, segundo
[VANDERMOLEN, 2008], fornece colaboração on-line de documentos, porém, de
forma assíncrona. Contém um recurso interessante no qual o usuário pode optar por ver
como outros usuários utilizam a ferramenta, como um tutorial.
É uma ferramenta voltada a estudantes, e contém um espaço de armazenamento
bastante limitado, apesar de poder expandi-lo se assinar um pacote por um custo
mensal. Também não possui a possibilidade de colaboração simultânea de documentos.
3.2.3. Microsoft Office Live (Sky Drive)
Muitos usuários poderão ter a necessidade de converter documentos para os
formatos de uso comum como a extensão “doc” utilizada pela Microsoft na ferramenta
Word, dessa forma, usuários poderão estar mais interessados na ferramenta recém-
disponível Microsoft Office Live [MICROSOFT, 2012]. Este serviço permite o upload
de um arquivo no formato MS original, e quando um usuário decide editá-lo, irá utilizar
o a ferramenta Microsoft Office em seu computador, salvando as atualizações no
documento no servidor on-line.
De acordo com [DONOVAN, 2010], a configuração inicial para este serviço,
porém, pode ser um pouco desestimulante, pois para poder utilizar a ferramenta, é
necessário primeiro baixar um software e instalá-lo, em seguida, na primeira tentativa
de editar um documento, será necessário criar um login de ligação ao documento.
Office Live permite armazenar até 7 GB de arquivos, permitindo que qualquer
documento possa ser do tamanho máximo de 25 MB, e compartilhar com até 100
pessoas. Ao contrário das outras ferramentas, no entanto, apenas um usuário pode editar
um documento por vez.
33
3.2.4. Google Docs
Estudos feitos por [BLAU, 2009], [DEKEYSER, 2007], [GODWIN, 2008] e
[DONOVAN, 2010] afirmam que o Google Docs é a ferramenta gratuita mais famosa
existente atualmente, disponível em [GOOGLEDOCS, 2006], é baseado no XML
Concurrency e também na utilização de AJAX, no qual usuários utilizam um simples
navegador para editar seus documentos utilizando editores de texto baseados em
Javascript/AJAX. Usuários registrados neste serviço podem criar documentos e
convidar colaboradores, que podem fazer atualizações de forma simultânea com outros
usuários. Há também a possibilidade de deixar o documento como “somente leitura”
para outros usuários. Alterações no documento são automaticamente transmitidos para o
servidor, o que acontece em um intervalo de 30 segundos, porém, se algum conflito
ocorrer neste momento, o documento é revertido ao último estado sem conflitos
apresentado uma mensagem que mostra as partes do texto conflitantes. Se necessário,
esta atualização pode ser reaplicada ao documento. Devido a alta frequência da
aplicação de atualizações no repositório, conflitos são difíceis de ocorrer, mas se
ocorrer, é provável que seja muito pequeno e, portanto, mais fácil de tratar. O histórico
de atualizações é mantido e é possível ver todo o documento como ele se encontrava em
versões passadas. Os documentos podem ser salvos no computador do usuário nos
formatos PDF, HTML e Microsoft Word.
[DEKEYSER, 2007] aponta como as vantagens obtidas na utilização do Google
Docs:
É uma aplicação leve, não necessita de configuração adicional no computador
além da utilização de um navegador compatível, e uma conta do Google é
feita de forma simples.
A atualização de documentos baseada em concorrência por múltiplos usuários
funciona bem e conflitos são raros de ocorrer.
No entanto, o serviço do Google é baseado em caracteres e não exclui totalmente
o usuário final da resolução de conflitos, e apesar de bastante eficiente e robusta, a
ferramenta Google Docs também apresenta problemas que possam vir a ser difíceis de
tratar, assim, seguem alguns destes problemas que foram mais relatados na internet
[CAVALCANTE, 2012] e também por [EDUCAUSE, 2008] e [DEKEYSER, 2007]:
Não possui adição e personalização avançada de estilos;
Faltou um corretor gramatical, há apenas o ortográfico;
34
Não traz cliparts e formas de desenho mais avançadas;
Não permite usar fontes instaladas no PC, apenas as que a ferramenta oferece;
Não é possível fazer uma personalização avançada da ferramenta, quanto ao
seu funcionamento;
Não possui um editor de formulas matemáticas, para simplificar a exibição de
símbolos especiais;
Gera gráficos simples e apenas em 2D;
Não exibe corretamente conteúdo HTML, copiados e colados a partir de sites;
Não exibe com exatidão conteúdo copiado de editores de textos Desktop,
distorcendo tabelas, caixas de texto e gráficos, além de alterar a formatação
original.
Planilhas podem ter no máximo 256 colunas e 400 mil células. Edita arquivos
de no máximo 2 MB;
Depende de conexão com a Internet, podendo sofrer com a interrupção ou
baixa qualidade do serviço. Apesar de ser leve, tende a ter um desempenho
ruim em conexões muito lentas.
3.3. Interatividade em Revisões Sistemáticas
Como mencionado anteriormente, as Revisões Sistemáticas são feitas sobre um
processo bastante rigoroso de revisão da literatura, assim, a colaboração entre usuários
para este fim torna-se bastante útil, pois tarefas podem ser divididas e trabalhadas
separadamente para que o processo seja mais ágil. Além disso, comunicações com
orientadores podem ser necessárias ou mesmo úteis para os usuários colaboradores, as
quais ocorrem durante todo o processo da RS, seja para seleção de artigos quanto para a
orientação na definição dos resultados. Mas para que usuários colaboradores possam se
comunicar sobre conteúdos selecionados, ou mesmo para que um avaliador possa dar
sugestões de conteúdo ou opinar nas informações inseridas pelos usuários, torna-se
necessário um meio de comunicação para facilitar esta troca de informações. Dessa
forma, as interações que usuários colaboradores podem ter são:
Usuário colaborador X Usuário colaborador podem ter as interações:
o definição do processo da RS;
o definição de prazos de entrega de cada parte da RS;
o inserção de texto à RS;
35
o criação da string de busca;
o busca por artigos em sites de busca;
o seleção dos artigos que serão lidos;
o discussão entre eles sobre os conteúdos selecionados;
o extração de conteúdo dos artigos;
o estruturação dos resultados obtidos.
Usuário colaborador X Usuário avaliador/orientador podem ter as interações:
o correção de conteúdo inserido na RS;
o opinião sobre artigos relacionados para formação do acervo de consulta;
o discussão sobre estruturação de conteúdo;
o orientações gerais.
A melhor forma de permitir a colaboração entre os usuários em uma RS é unir
todos em um único ambiente para que discussões sejam feitas e as interações
mencionadas deem frutos, mas para evitar o deslocamento dos usuários e ter que fazer
com que todos estejam em um único lugar ao mesmo tempo, estas interações podem ser
feitas através de ferramentas de colaboração on-line, das quais podem ser utilizadas as
ferramentas já mencionadas, porém, uma ferramenta voltada ao objetivo de realização
de RS pode ser mais adequada, pois esta já poderia conter parte do trabalho que
usuários teriam ao realizar o processo de uma RS como, por exemplo, a estruturação das
informações, nas quais a RS é dividida em tópicos que poderiam conter orientações de
como preenchê-los. E, apesar da interação em tempo real ser bastante útil, como
mostrado em algumas das ferramentas de colaboração on-line existente, erros de
sincronização na colaboração simultânea podem ocorrer, podendo deixar o conteúdo
inconsistente, assim, uma comunicação assíncrona, de forma que os usuários possam
inserir seus conteúdos na ferramenta de forma livre de sugestões de outros
colaboradores pode ser mais adequado, pois irá gerar discussões sobre o conteúdo
inserido e assim poderá ser melhorado posteriormente por outros usuários colaboradores
de forma consecutiva, até que chegue a um conteúdo definitivo e de maior qualidade
após passar pela visão de todos os colaboradores e/ou de um orientador.
3.4. Conclusões
Apesar de haver muitas ferramentas Desktop para edição de documentos, as
ferramentas de edição de documentos on-line são melhores em relação a colaboração
simultânea de documentos, pois são bastante úteis para quem trabalha com documentos
36
e planilhas simples e deseja acessá-los a partir de qualquer lugar, ou trabalhar de forma
colaborativa com outras pessoas, não necessitando anexar documentos em e-mails ou
gerar arquivos duplicados no computador pessoal. E, apesar da grande quantidade de
ferramentas similares de colaboração de documentos on-line, o Google Docs continua
sendo a primeira opção, porém, não apenas este, mas todas as ferramentas mencionadas
contem problemas referentes à utilização simultânea ou mesmo não a fazem por
limitação da própria ferramenta, assim, ferramentas de colaboração on-line são bastante
úteis para colaboração de documentos diversos, mas podem não ser muito úteis para
utilização em documentos mais específicos, que devem ser tratados de forma mais
detalhada, como na geração de uma revisão sistemática, pois esta contém toda uma
estrutura de conteúdo que pode ser predefinida e tornar ainda mais simples sua
utilização se gerada em uma ferramenta específica, no qual a colaboração possa ser feita
não de forma simultânea, na qual possa gerar muitos erros de sincronismo e perda de
conteúdo, mas de forma assíncrona, para que o conteúdo gerado pelos colaboradores
possa ser discutido entre eles e assim gerar um conteúdo definitivo com as melhores
partes de cada colaborador melhorando a qualidade da revisão sistemática em si. O
sistema proposto neste trabalho para suprir esta deficiência é detalhado no Capítulo
seguinte.
4. Sistema de apoio à Interatividade em Revisões Sistemáticas em Engenharia de
Software (SAEE)
Utilizando das informações anteriormente expostas, este trabalho trás a proposta
de criação de uma ferramenta que objetiva apoiar a interatividade na geração de
revisões sistemáticas. RS são baseadas em estudos e pesquisas científicas, dessa forma,
a ferramenta deve ser flexível no que se refere ao tipo de usuário que irá utilizá-la,
adequando-se tanto a um fim acadêmico, em que uma revisão sistemática gerada possa
ter a aprovação de um profissional da área, um professor, para que esta seja gerada de
forma consistente e que tenha um conteúdo de qualidade, ou mesmo para uma utilização
pessoal, em que um usuário possa gerar seus estudos e armazenar os resultados na
ferramenta para posterior utilização dos mesmos. A ferramenta possui a característica de
utilização por múltiplos usuários, ou seja, vários usuários podem contribuir na mesma
RS simultaneamente, como também pode haver mais de um avaliador para cada revisão
sistemática, porém, a interatividade é feita de forma assíncrona, ou seja, usuários podem
contribuir simultaneamente na mesma RS mas não no mesmo conteúdo desta. A opção
37
de usuários poderem desenvolver uma RS de forma conjunta em um mesmo ambiente
foi inserida na ferramenta devido à necessidade e grande dificuldade dos usuários de se
reunirem para inserirem conteúdo em RS compartilhada, o que da forma que a
ferramenta trabalha, ela pretende solucionar este problema. A especificação de
requisitos pode ser vista no Capítulo seguinte.
4.1. Hipóteses de pesquisa
As hipóteses que orientam esta pesquisa referem-se, de modo central, à
interatividade oferecida à geração de RS de forma compartilhada. Ferramentas para
utilização desta existem, porém, é sempre necessário, na totalidade destas, a instalação
no computador do usuário, impossibilitando-o de utilizar a ferramenta em outro
computador que não o que tem a ferramenta instalada, além de, em alguns casos, serem
de difícil instalação. Outros problemas são identificados observando as reações de
estudantes ao se depararem com a atividade de fazer uma RS, em que necessitam fazê-
la, muitas vezes, em grupo, e necessitam também ter a visão de um orientador para
ajudar a guiar o estudante a gerar um conteúdo de qualidade. A maioria das ferramentas,
apesar de serem robustas em funcionalidades, não contém estas descritas acima. Assim,
as hipóteses desta pesquisa pretendem suprir estes problemas e adicionar melhorias, em
que, de maneira mais específica, indicam:
1. Que uma ferramenta interativa on-line facilita a comunicação de usuários
geograficamente distantes na produção de uma RS;
2. Que a colaboração on-line é mais proveitosa para geração de uma RS do que
a utilização de ferramentas locais;
3. Que a possibilidade de se adicionar usuários externos como avaliadores da
RS de seu grupo para poderem orientar com comentários em cada um dos
itens da RS melhora a qualidade desta;
4. Que a possibilidade de visualizar o histórico das informações inseridas na RS
em forma de versões poderá facilitar a compreensão dos passos do grupo para
se chegar à informação mais consistente inserida;
5. Que a possibilidade de tornar sua RS “pública” para divulgar seu trabalho, ou
mesmo para que outros usuários acessem e possam utilizar o conhecimento
gerado para gerar novas RS ou para pesquisas é de grande ajuda para a área
acadêmica.
38
Essas hipóteses serão colocadas em avaliação para serem validadas em uma
turma do curso de Qualidade de Sistemas. Mais detalhes sobre como serão feitas podem
ser visualizadas no Capítulo 4.7.
4.2. Especificação de requisitos de software
Os requisitos de software são objetivos ou restrições, estabelecidos por clientes e
usuários para definir as diversas propriedades do sistema em que, tradicionalmente, são
separados em requisitos funcionais e não-funcionais. Os requisitos funcionais são a
descrição das diversas funções que clientes e usuários querem ou precisam que o
software ofereça, definindo a funcionalidade desejada do software e deve determinar o
que se espera que o software faça, sem a preocupação de como ele faz. Requisitos não-
funcionais são as qualidades globais de um software, como manutenibilidade,
usabilidade, desempenho, custos, dentre outras, sendo este, a necessidade de se
estabelecer os requisitos de forma precisa e crítica na medida que o tamanho e a
complexidade do software aumentam. Assim, a especificação de requisitos de software
é uma atividade para determinar os objetivos de um software e as restrições associadas a
ele, bem como elaborar a especificação precisa do software. Apesar de importantes, a
especificação de requisitos é uma etapa longa e de muito conteúdo, assim, por não ser o
foco deste trabalho, apenas serão mostrados os principais requisitos funcionais e não-
funcionais do sistema.
Os principais requisitos funcionais do sistema são:
Cadastro de usuários
o Pode ser feito diretamente pelo próprio usuário na área de login do sistema,
preenchendo informações como: nome, e-mail, login (validação em tempo
de execução) e senha (validação em tempo de execução).
Inserção de Revisão Sistemática (RS)
o Uma RS é gerada definindo-se quais campos ela conterá inicialmente, e
quais as datas de entrega de cada um dos campos. Novos campos poderão
ser inseridos posteriormente. As datas de entrega são apenas referências para
o usuário, não implicando em penalidades no seu término.
o RS é gerada e armazenada, deve estar disponível, pode ser salva e
continuada posteriormente.
o Pode-se definir se a RS é ou não aberta para visualização de outros usuários.
o A RS pode ser feita por partes, item a item.
39
O avaliador
o Deve ter acesso à RS a qual é avaliador, porém, não pode editá-la, apenas
comentá-la.
o Recebe os itens enviados da RS do usuário e pode abri-la em modo de
avaliação, os itens enviados podem ser vistos em versões de envio, e podem
ser avaliados individualmente por versão.
o Os comentários feitos ficam disponíveis tanto para o avaliador como para o
usuário, a troca de informações via comentários deve servir como orientação
ao usuário.
Tela de Login
o Contém campos a serem preenchidos para acesso ao sistema: login e senha
o Contém botão para “esqueci minha senha”, o qual irá mandar um e-mail
para o usuário com a nova senha para seu acesso, posteriormente a senha
poderá ser alterada.
o Contém um acesso para o registro do usuários.
o Uma vez logado, o sistema deve gerar uma sessão que expira após 15
minutos. A sessão é renovada ao navegar pelo sistema, zerando o contador.
Cadastro de RSs
o O usuário pode criar RS inserindo inicialmente quais os itens que esta
deverá conter, com datas de entrega para controle de prazos.
o Novos itens devem poder ser inseridos em uma RS já criada.
Adição de usuários/avaliadores a uma RS
o Ao criar uma RS, o usuário que a criou, e apenas este, poderá
adicionar/remover usuários e/ou avaliadores a esta RS.
o Um usuário adicionado como grupo, poderá interagir com a RS de forma a
contribuir com seu conteúdo.
o Um avaliador adicionado poderá apenas avaliar e comentar as versões
enviadas de cada item da RS.
o Usuário/Avaliadores removidos podem ser reinseridos à RS a qualquer
momento.
Interação usuário(s)/avaliador(es)
o Na RS deve haver possibilidade de interação via comentários entre
usuário(s) e avaliador(es).
o A interação deve ocorrer da forma que ao enviar um item, o avaliador e o
usuário possam comentar sobre a versão enviada, formando um “chat” em
tempo não real.
40
o O “chat” deve ser individual por versão.
o Os comentários ao serem inseridos, armazenam o nome e hora de quem
comentou, separando usuários e avaliadores
Os principais requisitos não-funcionais do sistema são:
O sistema deve estar sempre disponível.
O sistema deve ter uma interface simples e de fácil entendimento.
O tempo de resposta para qualquer requisição não deve ultrapassar 20
segundos.
Com os principais requisitos apresentados, o Capítulo seguinte mostrará as
tecnologias utilizadas na construção do sistema.
4.3. Tecnologia utilizada no sistema
O sistema foi feito utilizando a linguagem de programação PHP por ser uma
linguagem bastante utilizada, de simples adaptação e multi-plataforma, de fácil
adaptação a bancos de dados e tem seu código fonte aberto; o banco de dados utilizado
é o MySQL, pois é um banco de dados bastante robusto e tem excelente adaptação ao
PHP. Este trabalho também faz uso da biblioteca JQuery, que é feita em
Javascript/AJAX e também tem seu código aberto.
A seguir, o banco de dados do sistema é apresentado, mostrando sua estrutura e
seus relacionamentos.
4.4. Definição do banco de dados do sistema
Para o sistema ser prático e dinâmico, é necessário que o banco seja simples,
porém consistente, de forma a receber novos dados sem a necessidade de alteração
deste, assim, o banco de dados está sendo feito seguindo a orientação da especificação
de requisitos definidas no Capítulo 4.2. Para facilitar a compreensão do banco de dados
do sistema, a Figura 5 mostra sua estrutura.
41
Figura 5: Diagrama Entidade-Relacionamento do banco de dados da ferramenta SAEE.
Na Figura 5, podem-se observar dez tabelas, sendo elas:
saee_usuario: contém as informações de cadastro do usuário, é a tabela mais
utilizada, contendo sua chave primária em várias outras tabelas;
saee_revisao: armazena revisões sistemáticas, porém, apenas algumas
informações desta, como nome, descrição e status, já os itens dos quais a
revisão irá conter é inserido na tabela saee_rs_revisao, e o conteúdo
preenchido dos itens são armazenados na tabela saee_rs_campo;
saee_rs_revisao: ao criar uma revisão sistemática, a revisão é criada na tabela
saee_revisao e seus itens são armazenados nesta tabela, porém, os itens são
referências da tabela saee_campos, a qual contém as informações de cada
item. Além dos itens, esta tabela também armazena datas de entrega das
versões de cada item, que servem como referência para o usuário;
saee_rs_campo: armazena os itens preenchidos das revisões sistemáticas, os
itens são divididos por versões, um item pode ser salvo várias vezes como
rascunho, o que significa uma atualização da linha da tabela, mas se for
enviado, a atualização o torna uma versão, a qual não pode ser alterada,
porém pode ser gerada novas versões de um mesmo item;
42
saee_campos: tabela pré-preenchida que contém os itens da Tabela 1, assim
como suas informações, as tabelas saee_rs_revisao e saee_rs_campo utilizam
sua chave para referenciar suas infomrações;
saee_status: tabela pré-preenchida que contém as atribuições de status que
uma revisão sistemática pode ter;
saee_revisao_usuario: uma revisão sistemática pode ser compartilhada para
ser preenchida por vários usuários ou mesmo ser avaliada por vários usuários,
esta tabela faz o vínculo de uma revisão sistemática com outros usuários,
podendo o usuário adicional ser contribuinte ou avaliador, contém referências
das tabelas saee_usuario e saee_revisao;
saee_interacao: armazena as interações entre usuários e avaliadores, as
interações são feitas apenas nas versões da cada item de uma revisão, ou seja,
uma versão pode conter várias interações e uma interação pertence a apenas
uma versão;
saee_critsug: armazena as críticas e/ou sugestões de usuários referentes ao
sistema;
saee_log: armazena todas as atividades realizadas por usuários, sendo estas:
criação de conta no sistema, login no sistema, acesso a listagem de revisões,
criação de revisões, adição e remoção de usuários em uma revisão,
salvamento de um item, envio de um item, comentário de um item,
crítica/sugestão do sistema, logout do sistema. Cada linha do log armazenado
contém o usuário e o dia/hora em que a ação ocorreu. A função do log é a de
poder estudar o comportamento de usuários na utilização do sistema.
As tabelas foram criadas respeitando a normalização de tabelas, assim, o sistema
suporta uma maior quantidade de dados sem que haja duplicação de dados. A seguir, o
sistema é apresentado, mostrando seu funcionamento, suas telas e interações.
4.5. Funcionamento do sistema
O sistema, apesar de aberto, não teve seu foco especificamente voltado a área
acadêmica, porém, pode ser muito bem utilizado para esse fim, pois considera a criação
e desenvolvimento de uma RS de forma individual ou mesmo em grupo, e pode haver
um avaliador que poderia ser um professor ou orientador para avaliar o conteúdo da RS,
além de auxiliar na construção de qualquer trabalho que exija um grande embasamento
43
teórico como uma Monografia de Graduação, Dissertação de Mestrado ou mesmo Tese
de Doutorado. Mas este sistema também pode ser utilizado por profissionais de
qualquer área que exija o mesmo tipo de esforço. O sistema não possui níveis de acesso,
uma vez que todos podem ser, de forma simultânea, contribuintes e avaliadores de uma
revisão sistemática. Os termos citados e que serão utilizados tem significado no sistema:
Usuário: dentro do sistema, todos são usuários, porém, podem assumir papéis
de contribuintes e avaliadores, fornecidos por outros usuários. Um usuário
pode criar revisões sistemáticas, alterá-las e adicionar/remover
contribuintes/avaliadores à revisão sistemática criada por ele.
Contribuinte: um usuário assume o papel de contribuinte quando outro
usuário adiciona este à sua RS como tal, uma vez contribuinte, o usuário pode
adicionar conteúdo livremente na RS compartilhada e fazer comentários nas
diversas versões de itens gerados, porém, apenas o usuário que criou a RS
pode adicionar/remover contribuinte/avaliador a esta.
Avaliador: um usuário assume o papel de avaliador quando outro usuário
adiciona este à RS como tal, uma vez avaliador, o usuário pode apenas
comentar as versões geradas de cada item da RS compartilhada, agindo como
um orientador.
Revisão Sistemática: pode ser criada e compartilhada por qualquer usuário e
para qualquer usuário, a criação exige a seleção dos itens os quais a RS irá
conter inicialmente.
Item: um item é o nome utilizado para se referir às sessões (sections)
mostradas no índice de mesmo nome da Tabela 2, representam as sessões e
subsessões das partes de uma RS.
Versão: é o termo utilizado para representar o preenchimento de um item e
envio deste, o que após ser enviado, se torna uma versão do item. Um item
pode conter diversas versões, porém, uma versão pertence a apenas um item.
Salvar/Enviar: um item pode ser preenchido e salvo, o que acarreta em poder
continuar seu conteúdo posteriormente, já se este for enviado, se torna uma
versão, podendo ser comentada e avaliada, caso haja compartilhamento da RS
com algum usuário avaliador.
Comentário: pode ser feito apenas se alguma versão existir, comentários são
feitos por contribuintes e avaliadores, e são identificados por nome e
44
data/hora de quem o fez, porém, contribuintes e avaliadores aparecem de
forma diferenciada, contribuintes à esquerda e avaliadores à direita na área de
comentários.
As funcionalidades do sistema referente aos usuários também podem ser vistas
no diagrama de caso de uso da Figura 6, em que é mostrado o usuário como papel
principal e os papéis secundários de contribuinte e avaliador.
Figura 6: Diagrama de caso de uso da ferramenta SAEE.
Na Figura 6, é possível observar o ator “usuário” como principal, e os atores
“contribuinte” e “avaliador” como atores secundários, ou seja, dependem do
compartilhamento da RS para serem ativados.
O sistema foi implementado de forma generalizada e aberta, ou seja,
generalizada por não atender uma área específica de conhecimento, seja ela humanas
exatas ou tecnológica, e aberta por não exigir um cadastro com informações demasiadas
ou mesmo necessitar de permissões para se cadastrar e utilizar o sistema, qualquer
pessoa pode se cadastrar inserindo seu nome, e-mail, login e senha e usufruir do
sistema. Assim, para atender a essas requisições, o cadastro de usuários deve ter seu
acesso antes do sistema ser acessado, ou seja, na tela de login do sistema. A Figura 7
mostra a tela de login do sistema.
45
Figura 7: Tela de login do sistema.
Figura 8: Tela de login do sistema, acesso a “cadastro de usuários”.
Figura 9: Tela de login do sistema, acesso à “esqueci minha senha”.
Em que, na Figura 7, está o login do sistema, neste há o acesso a criação de uma
conta de usuário no item 1, e o acesso a área de recuperação de senha no item 2, ambas
são acessadas sem a interação do servidor, apenas utilizando-se de recursos em
javascript/AJAX. A Figura 8 é o resultado do acesso ao formulário de cadastro de
46
usuários feito pelo item 1 da Figura 7, e a Figura 9 é o resultado do acesso a área de
recuperação de senha feito pelo item 2 da Figura 7. Dessa forma, qualquer usuário pode
se cadastrar e ter acesso ao sistema. O formulário de cadastro de usuários possui
validador de campos que tornam necessários seus preenchimentos para que o cadastro
seja efetivado, e a recuperação de senha deve ser feita preenchendo o e-mail do usuário,
para que uma nova senha seja enviada para seu e-mail.
Após observar a tela de login do sistema, será mostrado algumas telas, as quais
desempenham funcionalidades relevantes ou mesmo de interesse para o funcionamento
do sistema e que, apesar de o sistema não estar completamente terminado, podem ser
acessadas e visualizadas com o objetivo de demonstrar a interação usuário/sistema.
Dessa fomra, os Capítulos seguintes mostram as telas do sistema.
4.5.1. Menu do sistema
Após se cadastrar no sistema, o usuário poderá acessar o sistema e, uma vez
acessado, o usuário irá ver a tela inicial, contendo uma saudação e o menu. Este último
pode ser visualizado na Figura 10.
Figura 10: Menu do sistema.
O menu do sistema mostrado na Figura 10 contém os acessos do usuário, os
quais consistem no item 1 que acessa a tela inicial do sistema, o item 2 que dá acesso à
criação de RS e à listagem das revisões criadas e/ou compartilhadas do usuário, o item 3
da acesso a listagem de usuários do sistema e alteração de dados do usuário no qual
poderá trocar sua senha, o item 4 da acesso a uma área de avaliação do sistema por parte
do usuário, em que pode ser inseridas críticas e sugestões de melhoria, e o item 5 faz o
logout do sistema.
4.5.2. Tabelas dinâmicas
Para facilitar a visualização, certas funcionalidades do sistema serão exibidas
com tabelas dinâmicas, como por exemplo: uma listagem das RS que um usuário fez até
47
o momento; uma listagem de usuários existentes no sistema. Uma demonstração desta
tabela pode ser vista na Figura 11.
Figura 11: Lista de usuários.
Na tabela da Figura 11, é utilizada a biblioteca JQuery, que a torna bastante útil,
pois pode ser manipulada de algumas formas como: poder modificar a quantidade de
linhas exibidas por paginação, mostradas no item 1; um buscador que filtra o resultado
da tabela em tempo de digitação, no item 2; ordenação alfabética dos termos por coluna,
no item 3; e navegação por página, no item 4. A listagem contida na Figura 11 é de
usuários, a qual todos tem acesso, nela, pode ser visto o nome, login e e-mail do
usuário, e também a data da criação de seu cadastro.
4.5.3. Criação de Revisões Sistemáticas
A RS é um dos focos deste trabalho, e deve ser criada inicialmente com os itens
que o usuário desejar dentre os pré-estabelecidos, ou seja, se o usuário quer que a RS
contenha apenas os itens “Título”, “Sumário ou Estrutura Abstrata” e “Referencial
Teórico”, ele pode escolher apenas estes intens e, posteriormente modificar a RS
adicionando outros itens. A ilustração da tela de criação de RSs pode ser vista na Figura
12.
48
Figura 12: Criação de revisões sistemáticas.
A Figura 12 mostra o formulário de criação de RS que o usuário irá utilizar.
Nela, o item 1 mostra o campo do nome de RS, é um campo obrigatório, pois toda RS
necessita ser referenciada por um nome; no item 2, o usuário pode inserir a descrição da
RS, porém, este campo é opcional; o item 3 contem um tutorial que acompanha as telas
de interação com os usuários; e, como mencionado, o usuário poderá escolher quais os
itens que a RS deve conter, assim, o item 4 permite fazê-lo, selecionando apenas os
itens que o usuário necessita na RS. Cada linha da tabela do item 4 contem uma data
para entrega da primeira versão e também a data de entrega da última versão, isso
ocorre pois os itens da atividade devem ter datas determinadas para entrega, porém,
essas datas são apenas orientações para o usuário, prazos de controle de seu conteúdo e
quando ele se organiza para tê-los feito. Os calendários utilizados foram feitos com o
uso da biblioteca JQuery. A cada versão enviada, no preenchimento de um item da RS,
o avaliador poderá orientar comentando as correções para que o usuário avaliado
reenvie como uma nova versão, melhorando o conteúdo do item e deixando a RS mais
consistente.
4.5.4. Listagem de revisões sistemáticas
Uma vez criada a RS, o usuário poderá acessar sua lista de RS as quais tem
acesso, esta listagem mostra as RS que o usuário criou, que foi compartilhada com ele
como contribuinte (grupo) e compartilhada como avaliador. A ilustração da tela de
listagem de RS pode ser vista na Figura 13.
49
Figura 13: Listagem de revisões sistemáticas.
A Figura 13 mostra a tabela de listagem de RS do usuário, nela é possível
visualizar nas colunas o tipo de RS, que significa se o usuário a criou ou se foi
compartilhada com ele, o nome da RS, sua descrição, a quantidade de usuários que esta
tem como contribuinte (grupo), a quantidade de usuários que esta tem como avaliador, a
quantidade de itens que a RS tem no momento (campos), a data de criação da RS, seu
status de ativada ou desativada e as ações a serem realizadas nas RS. No item 1,
encontra-se a coluna da tabela que diz se a RS foi gerada pelo próprio usuário, indicada
pela letra “C”, se foi adicionada ao usuário para ser avaliada por ele, indicada pela letra
“A”, e se foi adicionada ao usuário para este ser um contribuinte se tornando parte do
grupo dos usuários que podem adicionar conteúdo à RS, indicada pela letra “G”. O item
2 contem uma legenda para facilitar a compreensão do usuário dentre as indicações do
item 1 e do item 3. No item 3, que mostra as ações sobre as RS, pode-se notar ícones
representativos das ações, dentre eles, estão: “adicionar usuário (grupo)” o qual leva o
usuário à página de seleção de usuários a serem adicionados à RS como contribuintes;
“adicionar avaliador” o qual leva o usuário à página de seleção de usuário a serem
adicionados como avaliadores; “abrir” leva o usuário à página de conteúdo da RS, a
qual usuários contribuintes e que criou a RS tem acesso, este também pode ser acessado
clicando no nome da RS; “editar” leva à página de edição da estrutura da RS, a qual
poderá ser adicionado novos itens à esta; “desab./hab. (breve)” habilita ou desabilita
uma RS, porém, este recurso não está disponivel na versão atual do sistema. Esta
listagem foi feita utilizando-se da biblioteca JQuery, ou seja, contem as mesmas
características da lista mostrada no Capítulo 5.4.2. Na Figura 13, ainda pode-se observar
algumas das regras que o sistema contem, como mostrado no item 1, um usuário pode
ser, de forma simultânea, contribuinte de uma RS e avaliador de outra, porém, nunca ser
contribuinte e avaliador da mesma RS, outra regra visualizada é que o usuário
50
contribuinte ou avaliador não pode adicionar/remover usuários à RS que está
compartilhada com ele, apenas o criador da RS pode adicionar/remover
contribuintes/avaliadores a uma RS, e a última regra visualizada é a de que apenas o
usuário que criou a RS poderá editá-la para adicionar novos itens a esta.
4.5.5. Adição de contribuintes/avaliadores
Como evidenciado nos Capítulos anteriores, após um usuário criar uma RS, este
pode compartilhá-la com outros usuários de duas formas, como contribuinte ou como
avaliador. A ilustração da tela de seleção de contribuintes pode ser vista na Figura 14.
Figura 14: Listagem de contribuintes.
A Figura 14 mostra uma listagem de seleção de contribuintes, como este
exemplo está em sequência da situação mostrada na Figura 13, esta tela mostra os
contribuintes da RS de nome “Revisao 1” mostrada na Figura 13 e, ainda nesta, pode-se
observar que a quantidade de usuários contribuintes (que estão no Grupo) é igual a 2, o
que explica os dois usuários selecionados na listagem da Figura 14 mostrados no item 1.
O sistema permite adicionar e remover usuários contribuintes, assim, para tal, apenas
deve-se selecionar os usuários a serem adicionados e desselecionar os usuários a serem
removidos. Uma vez terminada a seleção de usuarios, o botão mostrado no item 2
“Adicionar usuários” deve ser clicado e o procedimento será confirmado com uma
mensagem de sucesso acima da tabela de listagem. Para a adição de avaliadores, o
processo é o mesmo, porém, um usuário não pode ser contribuinte e avaliador de uma
mesma RS como já mencionado.
O sistema está preparado para aceitar multiplos usuários como contribuintes e
como avaliadores, os quais seguem a orientação de que uma RS pode ter um
contribuinte e um avaliador (1 x 1), um contribuinte para vários avaliadores (1 x n),
vários contribuintes para vários avaliadores (n x n) e vários contribuintes para um
51
avaliador (n x 1), além de ser possível utilizar o sistema de forma individual e/ou com
contribuintes sem a orientação de um avaliador.
4.5.6. Inserção de conteúdo na revisão sistemática
Uma vez criada a RS, o usuário poderá acessá-la através da listagem de RS
mostrada no Capítulo 5.4.4 e adicionar conteúdo. Neste momento, o usuário irá
observar um formulário que conterá todos os itens selecionados por ele quando a RS foi
criada. Para tornar mais fácil o entendimento, a Figura 15 mostra a tela de inserção de
conteúdo da RS.
Figura 15: Tela de criação de revisões sistemáticas, inserção de conteúdo.
Na Figura 15, pode-se observar vários nomes à direita em abas, no item 1 e 2,
que correspondem às infomrações a serem preenchidas da RS, os quais são os itens
selecionados na criação da mesma. A aba com o nome “Título” (item 1) encontra-se
selecionada e suas informações aparecem na tela, e as outras abas se encontram
esmaecidas, escondendo seu conteúdo até serem selecionadas. As informações
observadas na tela são específicas do item “Título”, e correspondem a informações
gerais como por exemplo de que forma o item deve ser preenchido e sobre o que deve
ser mencionado mostrados no item 3. O item 4 corresponde a indicação de que o texto a
ser preenchido no editor de texto é um rascunho, podendo ser salvo e reeditado quantas
vezes necessária sem ser enviado como uma versão. O item 5 é o editor de texto, o qual
simula um editor bastante robusto, pois contém grande quantidade de opções de
formatação do texto tornando desnecessário a utilização de uma outra ferramenta de
edição para depois inserir no sistema. Os itens 6 e 7 correspondem aos botões que
geram os eventos de salvamento e envio do conteúdo do editor de texto, os quais, neste
52
formulário, indica que: um salvamento salva o conteúdo digitado até o momento no
banco de dados do sistema; um envio, envia o conteúdo do editor de texto tornando
estre conteúdo uma versão do item, podendo ser vista por um avaliador, se houver. O
item 8 indica, no caso da situação mostrada na Figura 15, que duas versões já foram
enviadas, as quais podem ser visualizadas clicando no nome da versão a qual se quer
visualizar, um exemplo de visualização de uma versão pode ser visto no item 1 da
Figura 16, a qual expõe esta situação. Assim, cada aba localizada nos itens 1 e 2 há todo
um conjunto de infomrações citadas acima, sendo todas individuais e podendo ser
enviadas de forma individual. Ainda no item 1 é possível observar que existem datas em
baixo dos nomes, esta é uma indicação do sistema ao usuário de que este item deve ter
sua primeira versão enviada até esta data limite, porém, é apenas uma forma de controle
do usuário, não acarretando penalidades no sistema se não obedecidas.
Figura 16: Tela de criação de revisões sistemáticas, área de comentários.
Na Figura 16, encontra-se a visualização da interação entre usuários, o qual é o
segundo foco deste trabalho, o resultado do envio de uma versão por um contribuinte ao
avaliador e os comentários entre eles. No item 1, pode-se ver que a segunda versão
enviada pelo usuário está selecionada na tela. No item 2 encontra-se a segunda versão
do item “Título”, a qual não permite mais nenhuma modificação em seu conteúdo,
apenas comentários. Os itens 3 e 4 mostram como funcionam os comentários, em que o
usuário adiciona seu comentário no campo do item 4 e o envia, e no item 3 o
comentário aparece do lado esquerdo da tela, o lado direito é reservado para os
comentários do avaliador. Nos comentários, algumas infomrações são mostradas, como
quem comentou e a hora em que ocorreu, mantendo um histórico da conversa entre as
53
partes. As versões enviadas ficam disponíveis para visualização e para comentários,
podendo ser acessadas clicando nos nomes das versões como já mencionado. A
mudança de versões e rascunho são feitas utilizando um recurso da biblioteca JQuery, o
efeito “sanfona”, o qual “esconde” o conteúdo das versões não selecionadas, deixando
apenas a versão selecionada aparecendo na tela.
A tela de inserção de conteúdo contém muitas informações, sendo necessário
certa atenção para acessar e preencher o item a que realmente se quer preencher.
No Capítulo seguinte, será mostrado como funciona a interação entre usuários,
sejam contribuintes ou avaliadores de forma bem detalhada, com um diagrama para
melhor entendimento.
4.6. Interatividade na ferramenta SAEE
A ferramenta SAEE atende a alguns tipos de interação que uma RS exige,
observando a listagem de interações contidas no Capítulo 4.3, das interações existentes
entre usuários colaboradores, a ferramenta atende: a definição do processo da RS; a
definição de prazos de entrega de cada parte da RS; a inserção de texto à RS; a
discussão entre eles sobre os conteúdos selecionados; a estruturação dos resultados
obtidos. E da parte entre usuários colaboradores e avaliadores/orientadores, a
ferramenta atende a todos os tipos.
Assim, as interações mencionadas ocorrem no momento do envio de um item,
ou seja, uma RS é composta de itens a serem preenchidos, uma vez que estejam feitos,
os itens estão prontos e podem ser enviados ao avaliador para devida orientação, porém,
para aumentar a interação e melhorar o resultado e qualidade das RSs geradas, o sistema
proposto irá trabalhar de forma diferente. Quando um usuário inicializa uma RS, este
pode fazer item a item desta e enviá-lo, uma vez feito isso, a versão enviada encontra-se
aberta para os outros usuários contribuintes deste grupo discutirem sobre o conteúdo
gerado e para o avaliador dar suas devidas orientações, como por exemplo, o usuário
pode iniciar uma RS e criar apenas o Referencial Teórico e já enviar este item, neste
momento, outros usuários deste mesmo grupo interagem através de comentários e o
avaliador também, os usuários então podem ver as orientações, interagir com o
avaliador via comentários e então melhorar o conteúdo do item e enviá-lo novamente
como uma nova versão para que o avaliador veja as melhorias. Este processo pode ser
feito quantas vezes os usuários contribuintes necessitarem. Desta forma, a qualidade do
conteúdo melhora e incentiva os usuários a melhorarem cada vez mais o conteúdo,
54
discutindo entre eles mesmos sobre melhorias a serem feitas nas versões geradas através
de comentários e também devido à orientação do avaliador, que faz com que haja um
retorno do trabalho feito na RS criada. A interação ocorre no momento em que um item
é enviado, e a interação por comentários é individual por versão, ou seja, se foi enviado
uma versão de um item e comentários foram feitos sobre este item e uma nova versão
posteriormente deste item foi enviada, os novos comentários podem ser feitos nesta
nova versão ou nas anteriores, mantendo um histórico da evolução do conteúdo do item.
A Figura 17 mostra a interação mencionada em um diagrama de atividades.
Figura 17: Diagrama de atividades (interação usuário/avaliador).
No diagrama da Figura 17 é possível verificar a divisão do diagrama em três
partes, a primeira corresponde ao usuário, que inicia a criação de uma nova RS,
podendo compartilhá-la com outros usuários como contribuintes ou avaliadores e editar
a RS adicionando novos itens; a segunda corresponde às funcionalidades comuns ao
usuário que criou a RS e a um contribuinte, em que podem preencher um dos itens do
formulário da RS e, uma vez preenchido, o usuário contribuinte pode salvar o conteúdo
preenchido como um rascunho (é chamado de rascunho pois seu salvamento não indica
o envio ao avaliador, mas apenas o salvamento do conteúdo preenchido), preencher
outros itens do formulário, em que cada um funciona de forma individual no que se
refere a salvamento e envio, enviar a primeira versão do respectivo item; a última parte
se refere ao avaliador, que visualiza a versão de um item enviado pelos usuários e os
orienta através de comentários; e a parte da interação, que ocorre após o envio de uma
55
versão de um determinado item pelos usuários, neste momento os usuários e o avaliador
já podem trocar infomrações sobre esta versão do item através de comentários, que
podem ser desde dúvidas sobre o item, como questionamentos de melhoria por
exemplo. Os comentários são individuais por versão de um item, ou seja, se o usuário
enviar uma nova versão de um item, os comentários sobre esta nova versão são apenas
para esta versão do item, não correspondendo às versões anteriores enviadas pelo
usuário.
5. Planejamento e execução do Survey
O propósito deste Survey foi de validar as hipóteses de pesquisa contidas no
Capítulo 4.1, das quais consistem em demonstrar a necessidade de uma ferramenta mais
robusta para apoio à realização de RS e mostrar como uma ferramenta interativa para tal
será de grande ajuda para a área acadêmica. Além disso, os objetivos deste Survey
foram definidos segundo uma questão que envolve a proposta da ferramenta SAEE:
Questão: A área acadêmica necessita de uma ferramenta interativa que facilite a
geração de RS em grupo?
Este Survey foi baseado nas orientações de [KITCHENHAM et al., 2001], o
qual mostra todos os passos para se gerar um Survey. Assim, os Capítulos seguintes irão
mostrar os passos seguidos para a aplicação do questionário e a apuração dos resultados.
5.1. Planejamento e programação do Survey
O planejamento foi definido seguindo as orientações de [KITCHENHAM et al.,
2002a]. Este Survey é composto por duas partes principais, a primeira é um vídeo
introdutório, no qual é demonstrada a proposta da ferramenta SAEE, juntamente com
uma situação real de funcionamento para ajudar no entendimento do participante, e o
questionário, em que ocorre a pesquisa efetivamente.
Para o planejamento do vídeo de introdução, foi estudado qual seria um tempo
ideal para que um participante pudesse ver o vídeo sem se cansar e que fosse atrativo a
ele, assim, questões de conteúdo e temporização foram bastante discutidas até que se
chegasse à proposta ideal. Dessa forma, foi definido quantas informações o vídeo
deveria ter e quais delas são indispensáveis para mostrar ao participante, assim, foi
56
definido que o vídeo deveria conter uma pequena introdução à RS e mostrar as
dificuldades de se fazê-la em colaboração com outras pessoas que se encontram
geograficamente distantes uma da outra, mostrar algumas funcionalidades da ferramenta
e a funcionalidade de interatividade, a qual é a principal proposta da ferramenta. Assim,
o vídeo foi composto de animações e demonstrações em tempo real das funcionalidades
da ferramenta simulando três usuários contribuindo na mesma RS e interagindo entre si.
O vídeo completo possui cinco minutos de duração, o que foi julgado ideal para que o
participante possa vê-lo por inteiro sem se entediar com um tempo longo de
demonstração.
Para o planejamento do questionário, foi necessário verificar em quanto tempo o
participante conseguiria terminá-lo e se a quantidade de perguntas seria ideal para que
este possa respondê-las rapidamente e de forma simples, sem que este tenha a
necessidade de rever o vídeo novamente ou pesquisar sobre o que é uma RS. Além
disso, as formas de respostas também foram estudadas, dentre as quais: do tipo
dissertativa e aberta, a qual o participante poderia escolher com suas palavras a resposta
mais adequada, porém, apesar de ser uma resposta que seria bastante adequada, exigiria
muito tempo e esforço por parte do participante para escrever um texto adequado,
assim, esta opção foi logo descartada; o tipo múltipla escolha aberta, em que consiste
em respostas de múltipla escolha que representam a melhor opção em relação ao
participante, pois facilitaria e iria agilizar a resposta deste, porém, por ser aberta, cada
questão teria respostas de múltipla escolha diferentes, o que em estudos feitos por
[KITCHENHAM et al., 2002a] indicam que não é uma boa opção no caso de
participantes que não tenham nenhuma obrigação de responder ao questionário, pois
estes teriam que ler todas as respostas novamente após cada questão, o que faz com que
os participantes demorem ou mesmo desistam de responder ao questionário por esse
motivo; e tipo múltipla escolha fechada, que corresponde a imediatamente anterior com
exceção de que todas as questões tenham o mesmo conjunto de respostas, o que
facilitaria para o participante responder ao questionário sem a necessidade de ler todas
as respostas novamente. Contudo, mesmo que a utilização de questões de múltipla
escolha fechada seja a melhor opção, depende do tipo de resposta que a questão pede,
pois nem todo caso pode-se utilizar respostas de múltipla escolha fechadas em todo o
questionário, assim, para tornar o questionário mais flexível neste ponto, foram
utilizadas respostas dos três tipos, porém, a do tipo de múltipla escolha fechada foi a
mais utilizada. Aversão final do questionário foi feito contendo a quantidade de
57
dezesseis questões das quais quatorze delas são de múltipla escolha e duas são
dissertativas, em que uma delas é preenchido a Universidade ou local de trabalho do
participante e a outra é livre para que o participante possa escrever de forma como ele
quer sobre suas opiniões sobre a ferramenta.
O tempo necessário para se responder o questionário também foi estudado, pois
este não poderia ser muito longo para evitar que participantes desistam de respondê-lo.
Assim, dois estudantes de Mestrado responderam o questionário piloto para verificar o
tempo de resposta deste: o primeiro estudante completou o questionário em cinco
minutos; e o segundo o fez em dois minutos e quarenta segundos, indicando um tempo
médio de resposta de três minutos e cinquenta segundos, como mostrado na Tabela 4.
Tempo de resposta Estudante 1 5 minutos Estudante 2 2:40 minutos Média 3:50 minutos
Tabela 4: Tempo de resposta do questionário definitivo.
5.2. Definição da população e tamanho da amostra
O grupo de pessoas habilitadas a responder o questionário são estudantes de pós-
graduação em Computação, dos quais, já utilizaram RS em suas Dissertações ou Teses,
ou mesmo em alguma situação em suas vidas acadêmicas.
O questionário foi disponibilizado aos estudantes de pós-graduação da
Universidade Federal do Rio Grande do Norte, sendo estes dos cursos de Mestrado (72
estudantes) e Doutorado (43 estudantes) em Sistemas e Computação, dos quais integram
o total de 115 pessoas, e também disponibilizado em uma lista de discussão da
Sociedade Brasileira de Computação (SBC-L).
Apesar da quantidade significativa de pessoas habilitadas a responderem o
questionário e que o receberam, foram utilizadas a quantidade de 36 participantes,
apesar de o total ter sido de 54, foram selecionados apenas os participantes que já
utilizaram RS em algum momento de suas vidas acadêmicas.
5.3. Seleção de participantes e motivação
A amostra inclui todos os estudantes de pós-graduação do Departamento de
Informática e Matemática Aplicada (DIMAp) da Universidade Federal do Rio Grande
do Norte e todos os estudantes e profissionais contidos na SBC-L.
58
Para garantir que apenas estudantes de Mestrado e Doutorado teriam acesso ao
questionário, e também que estes já haviam realizado alguma RS, uma questão do
questionário foi feita para identificar estes participantes, e apenas estes seriam
considerados na apuração dos resultados, ou seja, os participantes seriam estudantes de
Mestrado ou Doutorado, ou algum profissional da área que tenha realizado uma RS,
removendo dos resultados qualquer outro tipo de participante que não esteja
efetivamente de acordo com a definição da população definida no Capítulo anterior.
A seleção destes tipos de participantes foi feita baseando-se em
[KITCHENHAM et al., 2002d] e no fato de que estudantes de graduação dificilmente
utilizam RS durante seu curso, assim, apenas estudantes de pós-graduação e
profissionais da área puderam ter contato com RS ou mesmo ter que fazê-la no
momento em que estiverem estudando para escrever suas Dissertações ou Teses. Além
disso, a utilização de RS para qualquer tipo de pesquisa mais elaborada é feita, quase
em sua totalidade, apenas pela área acadêmica, o que torna a seleção de estudantes de
pós-graduação os participantes mais indicados para entender e responder o questionário
sem muitas dificuldades, além de se tornar um incentivo para o desenvolvimento de
novas ferramentas de pesquisa on-line interativa.
5.4. Produção e definição do questionário
O questionário foi elaborado com o intuito de validar as hipóteses de pesquisa
mostradas no Capítulo 4.1, das quais em sua grande maioria referenciam a
interatividade que a ferramenta proporciona aos usuários.
O questionário é composto por duas partes: a primeira é um vídeo explicativo
sobre a proposta da ferramenta SAEE, contendo um pequeno exemplo de seu
funcionamento sobre uma situação em que estudantes de pós-graduação necessitam
gerar uma RS, mas estão geograficamente distantes, o que viabiliza a utilização da
ferramenta, o vídeo contém cinco minutos de duração; a segunda contém a descrição
dos objetivos da pesquisa, juntamente com a motivação para o mesmo e contém 14
perguntas de múltipla escolha e 2 perguntas abertas para que o participante possa opinar
livremente com suas palavras sobre a proposta da ferramenta.
As questões foram definidas seguindo as orientações de [KITCHENHAM et al.,
2002b] e [KITCHENHAM et al., 2002c], dessa forma, não foram apenas pensadas na
forma de validar as hipóteses de pesquisa, mas também em como o participante irá ver e
entender da melhor forma possível as intenções de cada uma das questões. Assim, o
59
questionário foi definido como mostrado na Tabela 5, a qual mostra as dezesseis
questões nele composto.
Q1. Qual a sua instituição de ensino ou local de trabalho? Q2. Qual a pós-graduação que você está fazendo? Q3. Você entendeu a proposta da ferramenta SAEE? Q4. Você já gerou uma Revisão Sistemática? Q5. Se você já gerou uma Revisão Sistemática em grupo, seu grupo teve dificuldades de se reunir para fazê-la, ou para trocar informações sobre esta? Q6. Como você avalia a proposta da ferramenta de apoiar a interatividade on-line de usuários que podem estar geograficamente distantes na geração de Revisões Sistemáticas? Q7. Em sua opinião, uma ferramenta interativa on-line para múltiplos usuários facilitaria a geração de Revisões Sistemáticas em grupo? Q8. Como você avalia a possibilidade de colaboração on-line entre múltiplos usuários para geração de uma Revisão Sistemática? Q9. Como você avalia a possibilidade de adicionar um avaliador externo à sua Revisão Sistemática? Q10. Como você avalia a possibilidade de interação on-line entre seu grupo de pesquisa e um avaliador externo para auxiliar na geração do conteúdo de uma Revisão Sistemática? Q11. Como você avalia a possibilidade de compartilhar, discutir e opinar as informações inseridas por seu grupo na geração de uma Revisão Sistemática sem a necessidade de se reunirem fisicamente? Q12. Como você avalia a possibilidade de interatividade entre usuários através de comentários, os quais simulam um fórum de discussão? Q13. Você acredita que a interatividade através de comentários entre usuários e/ou avaliadores melhoraria a qualidade da Revisão Sistemática? Q14. A ferramenta ainda dá a possibilidade de tornarem públicas as Revisões Sistemáticas geradas a fim divulgar seu trabalho. Como você avalia essa possibilidade? Q15. Como você avalia a possibilidade de ver todo o histórico e discussões sobre cada campo da revisão? Q16. Dê sua opinião sobre a proposta da ferramenta SAEE, suas sugestões e críticas. Fique a vontade para responder.
Tabela 5: Questões do questionário.
Em que a questão Q1 é dissertativa e corresponde a identificação da instituição
de ensino do participante; a questão Q2 foi utilizada para diferenciar os tipos de
participantes pelo seu nível de graduação, podendo categorizar os resultados; a questão
Q3 mostra a efetividade do vídeo de demonstração da ferramenta, o qual é exibido
primeiramente, antes do participante responder ao questionário; a questão Q4 foi
elaborada para também categorizar os participantes, dentre os quais somente serão
considerados os resultados que já tiverem realizado uma RS, ou seja, todo este Survey
foi considerado apenas com as respostas “Sim” da questão 4; a questão Q5 pretende
avaliar a quantidade de participantes dos quais a proposta da ferramenta será mais bem
60
vista; as questões Q6, Q7, Q8 e Q11 objetivam validar a proposta da ferramenta em
relação a interatividade entre usuários; as questões Q9 e Q10 foram elaboradas para
mostrar uma funcionalidade adicional que a ferramenta tem e que agrega a proposta
original de interatividade entre usuários, que é a possibilidade de inserção de um
usuário avaliador que se encontra externo a produção da RS para que este possa opinar e
orientar os usuários que compõe o grupo de pesquisa; as questões Q12, Q13 e Q15
foram utilizadas para validar a forma como a interatividade é feita na ferramenta,
validando não apenas a forma de interatividade através de comentários, mas também
expondo a forma como este é exposto, a qual mantém todo o histórico das versões e
discussões geradas sobre cada campo da RS; a questão Q14 foi elaborada para avaliar a
aceitação de outra funcionalidade não exposta no vídeo de demonstração, a qual se
refere a divulgação da RS gerada para expor seu trabalho para outros usuários terem
acesso; e a Questão Q16, a qual corresponde a uma questão aberta, ou seja, o
participante pode escrever o que julgar necessário como opinião, sugestão ou críticas
sobre a proposta da ferramenta.
As respostas do questionário foram padronizadas seguindo a orientação de
[KITCHENHAM et al., 2002b], a qual indica que para um melhor entendimento e
agilidade por parte do participante para responder o questionário, respostas
padronizadas e de múltipla escolha que utilizam escalas que variam entre péssimo,
ruim, indiferente, bom e ótimo são melhores recebidas pelos participantes por não
necessitar ler novamente cada uma das opções de respostas toda vez que for responder
uma questão diferente. Assim, foram gerados quatro tipos diferentes, porém
padronizados, de respostas que o participante poderá escolher, sendo três destas de
múltipla escolha e uma de texto livre, o qual o participante poderá escrever livremente
para responder à questão. As possíveis possibilidades de respostas podem ser
visualizadas na Tabela 6.
Tipo 1 Tipo 2 Tipo 3 Tipo 4 - Mestrado - Doutorado - Profissional da área
- Sim - Não - Não tenho opinião
- Ótimo - Bom - Indiferente - Ruim - Péssimo
Resposta dissertativa
Q1 X Q2 X Q3 X Q4 X
Tipos de respostas
Questões
61
Q5 X Q6 X Q7 X Q8 X Q9 X
Q10 X Q11 X Q12 X Q13 X Q14 X Q15 X Q16 X
Tabela 6: Tipos de respostas contidas no questionário.
Para melhorar a credibilidade do questionário foram escolhidas respostas para
atender também uma opção neutra, pois o participante, segundo [KITCHENHAM et al.,
2002b], deve poder escolher uma opção que não demonstre positividade nem
negatividade sobre a questão, assim, as respostas Tipos 2 e 3 demonstram a neutralidade
da resposta contendo o termo “Não tenho opinião” e “Indiferente” nas opções de
múltipla escolha respectivamente.
Uma vez finalizado, o questionário foi disponibilizado em forma de uma
pesquisa utilizando os recursos da ferramenta GoogleDocs, a qual permite a geração de
um formulário de pesquisa para ser disparado via e-mail para os participantes.
5.5. Métodos para a análise de dados
Para a análise dos dados, estes foram primeiramente consolidados em uma única
planilha e então as respostas foram discriminadas e somadas gerando seus valores
absolutos e então geradas suas porcentagens para que seja possível uma visão mais
detalhada das informações.
O questionário foi dividido em categorias que representaram o nível de
graduação dos participantes e se são profissionais da área.
A análise dos dados foi feita utilizando as orientações de [KITCHENHAM et al.,
2003], a qual mostra as formas de análise dos dados, dentre elas está uma forma de
categorização de questões, a qual separa as questões que sejam referentes a um
determinado tema e agrupam para representarem, com seus resultados, um único
resultado. Assim, separando as questões em categorias, estas puderam melhorar a leitura
e avaliação dos resultados, as questões foram separadas em: avaliação do vídeo de
62
demonstração, se os participantes já haviam utilizado RS, avaliação em relação à
interatividade proposta pela ferramenta, avaliação de funcionalidades adicionais da
ferramenta, avaliação da forma como a interatividade é feita na ferramenta e as
observações dos participantes em texto livre. As respostas de cada categoria foram
somadas para gerar uma única resposta de cada categoria para assim melhorar a
visualização dos resultados. Dessa forma, as categorias puderam representar as
hipóteses de pesquisa para uma análise mais específica.
5.6. Avaliação do questionário
Antes de aplicar o Survey, um questionário piloto foi feito utilizando dois
participantes estudantes de Mestrado externos à pesquisa, seguindo as orientações de
[KITCHENHAM et al., 2002d] e [KITCHENHAM et al., 2003], para se verificar
informações de tempo de resposta e entendimento do vídeo e do questionário. Estes
participantes foram selecionados por estarem disponíveis e por terem um conhecimento
prévio sobre RS, assim, eles foram monitorados do início ao fim da pesquisa, e foi
constatado que o entendimento do vídeo e do questionário estavam de acordo com o
nível de graduação dos participantes, assim como ambos já haviam utilizado RS durante
suas vidas acadêmicas. O participante 1 respondeu o questionário em cinco minutos e
demonstrou curiosidade de saber mais sobre a proposta da ferramenta, e o participante 2
respondeu o questionário em dois minutos e quarenta segundos, e também demonstrou
curiosidade sobre o funcionamento e sobre saber mais da proposta da ferramenta, além
de comentar que poderá dar um retorno melhor após testá-la efetivamente.
5.7. Análise dos dados
Neste capítulo são mostrados os resultados obtidos da aplicação do questionário.
Do total de pessoas que receberam o questionário, 54 destes o responderam, no entanto,
36 destes participantes foram selecionados para terem suas respostas consideradas nos
resultados do Survey, pois estes são os que já fizeram uma RS, permitindo que a
ferramenta seja devidamente avaliada por quem já tem conhecimento desta. A
quantidade de 36 participantes efetivos nos resultados foi considerado razoável em
relação à quantidade de pessoas que receberam o questionário, porém, devido a
experiência acadêmica/profissional destes com RS, o resultado foi considerado
satisfatório.
63
Na tentativa de entender o motivo pelo qual muitos dos estudantes e/ou
profissionais que não responderam ao questionário ou mesmo nem acessaram o vídeo
demonstrativo, percebeu-se que os motivos aparentes foram:
Falta de tempo;
Não recebeu o e-mail;
Não viu/percebeu o e-mail;
Não se sentiu motivado pela descrição do e-mail;
Não tinha conhecimento sobre RS o que não o motivou a visualizar o vídeo
demonstrativo;
Além disso, houve ocorrências das quais os estudantes visualizaram o vídeo
demonstrativo, mas não acessaram o questionário, o que mostra que estes não se
interessaram pela proposta da ferramenta ou não tinham interesse em assisti-lo no
momento, dessa forma, foi constatado que outros métodos de aplicação da pesquisa
poderiam ter sido feitas para a motivação dos estudantes ou mesmo para que estes se
interessassem a conhecer a proposta da ferramenta. Contudo, não foi encontrado
nenhum motivo relevante para se cancelar a pesquisa, uma vez que seus resultados
foram obtidos corretamente e de forma consistente. Dessa forma, a pesquisa foi
considerada consistente, contendo informações relevantes para concluir se a proposta da
ferramenta foi avaliada de forma positiva ou não.
Os resultados mostrados na Figura 18 indicaram em qual Universidade os
participantes estão estudando ou que já terminaram seu curso. A Figura 19 indica que,
dos 36 participantes, 17 destes são estudantes de Mestrado, 16 de Doutorado e 3
profissionais da área, o que indica que estudantes de Mestrado tiveram um maior
interesse sobre a proposta da ferramenta. A Figura 20 mostra a efetividade do vídeo
demonstrativo e seu entendimento em mostrar a proposta da ferramenta, pois este
alcançou 91,67% dos participantes que entenderam a mensagem contida no vídeo. Os
resultados também mostraram que a quantidade de estudantes que não conheciam ou
que não utilizaram RS foi menor do que os que já haviam utilizado, indicando que os
participantes de maior interesse sobre a proposta foram aqueles que já a conheciam,
pois dos 54, 18 não tinham conhecimento algum sobre RS e 36 destes o tinham, sendo
66,67% dos participantes os que já haviam utilizado RS e 33,33% os que ainda não
conheciam ou não a utilizaram até a aplicação deste questionário. A Figura 21 mostra
em detalhes o resultado desta análise.
64
Questão 1. Qual a sua instituição de ensino ou local de trabalho? Questão 1 Quantidade % UFRN 12 33,33% UFPE 12 33,33% USP 3 8,33% UFPR 1 2,78% UFABC 1 2,78% UFBA 2 5,56% UNEMAT 1 2,78% UFC 2 5,56% UNIFESP 1 2,78% UFLA 1 2,78%
Figura 18: Respostas referentes à questão 1.
Questão 2. Qual a pós-graduação que você está fazendo? Questão 2 Quantidade % Mestrado 17 47,22% Doutorado 16 44,44% Profissional da área 3 8,33%
Figura 19: Respostas referentes à questão 2.
65
Questão 3. Você entendeu a proposta da ferramenta SAEE?
Questão 3 Quantidade % Sim 33 91,67% Não 2 5,56% Não tenho opinião 1 2,78%
Figura 20: Respostas referentes à questão 3.
Questão 4. Você já gerou uma Revisão Sistemática?
A questão 4 deve ser considerada de forma diferente das outras, pois seus resultados
consideram o total dos participantes deste Survey, 54. As outras questões são baseadas
apenas nos participantes que responderam como “Sim” a esta questão, ou seja, o total de
participantes das outras questões é de 36.
Questão 4 Quantidade % Sim 36 66,67% Não 18 33,33% Nunca fiz uma 0 0,00%
Figura 21: Respostas referentes à questão 3.
66
As respostas referentes à questão 5 mostraram que 50% dos participantes
tiveram algum problema em se reunirem com seus grupos para fazer a RS, ou seja, a
proposta principal da ferramenta já seria atrativa para metade dos participantes, o que
confirma a necessidade de ferramentas de apoio à interatividade entre usuários. Uma
melhor visualização pode ser observada na Figura 22. Os resultados obtidos das
questões 6, 7, 8 e 11 indicam respectivamente que: 83,33% (soma dos resultados “Bom”
e “Ótimo”) dos participantes demonstram interesse em ferramentas de interação online
para RS, o que mostra a necessidade de ferramentas de apoio e reafirma a proposta da
ferramenta SAEE; 86,11% dos participantes demonstraram que teriam maior facilidade
na geração de RS com o uso de ferramentas interativas; 91,66% (soma dos resultados
“Bom” e “Ótimo”) dos participantes mostraram interesse e necessidade de ferramentas
de colaboração online para RS; e 91,66% (soma dos resultados “Bom” e “Ótimo”) dos
participantes afirmaram que a possibilidade de compartilhar, discutir e opinar
informações inseridas por seus grupos na geração de RS sem a necessidade de se
reunirem fisicamente seria bastante positiva. Para uma visão mais detalhada destes
resultados, visualizar as Figuras 23, 24, 25 e 28 respectivamente.
Questão 5. Se você já gerou uma Revisão Sistemática em grupo, seu grupo teve dificuldades de se reunir para fazê-la, ou para trocar informações sobre esta?
Questão 5 Quantidade % Sim 18 50,00% Não 14 38,89% Não tenho opinião 4 11,11%
Figura 22: Respostas referentes à questão 5.
67
Questão 6. Como você avalia a proposta da ferramenta de apoiar a interatividade on-line de usuários que podem estar geograficamente distantes na geração de Revisões Sistemáticas?
Questão 6 Quantidade % Ótimo 9 25,00% Bom 21 58,33% Indiferente 6 16,67% Ruim 0 0,00% Péssimo 0 0,00%
Figura 23: Respostas referentes à questão 6.
Questão 7. Em sua opinião, uma ferramenta interativa on-line para múltiplos usuários facilitaria a geração de Revisões Sistemáticas em grupo?
Questão 7 Quantidade % Sim 31 86,11% Não 3 8,33% Não tenho opinião 2 5,56%
Figura 24: Respostas referentes à questão 7.
68
Questão 8. Como você avalia a possibilidade de colaboração on-line entre múltiplos usuários para geração de uma Revisão Sistemática?
Questão 8 Quantidade % Ótimo 12 33,33% Bom 21 58,33% Indiferente 3 8,33% Ruim 0 0,00% Péssimo 0 0,00%
Figura 25: Respostas referentes à questão 8.
As questões 9 e 10 fazem referência a adição de avaliadores para auxiliar os
usuários na geração de RS, os resultados obtidos indicam respectivamente que: 97,22%
(soma dos resultados “Bom” e “Ótimo”) dos participantes concordam que as opiniões
de um avaliador seriam muito importante no andamento da RS; e 94,44% (soma dos
resultados “Bom” e “Ótimo”) dos participantes acreditam que a interação com um
avaliador ou avaliadores externos durante a geração da RS poderia ser bastante positiva.
Para obter mais detalhes sobre estas questões, visualizar as Figuras 26 e 27
respectivamente. É importante mencionar que a adição de avaliadores obteve resultados
positivos acima de 94%, indicando que usuários realmente necessitam de uma interação
maior de um profissional da área ou pesquisador mais experiente para melhorar a
qualidade tanto do documento gerado quanto de indicações de artigos e documentos a
serem estudados.
69
Questão 9. Como você avalia a possibilidade de adicionar um avaliador externo à sua Revisão Sistemática?
Questão 9 Quantidade % Ótimo 20 55,56% Bom 15 41,67% Indiferente 1 2,78% Ruim 0 0,00% Péssimo 0 0,00%
Figura 26: Respostas referentes à questão 9.
Questão 10. Como você avalia a possibilidade de interação on-line entre seu grupo de pesquisa e um avaliador externo para auxiliar na geração do conteúdo de uma Revisão Sistemática?
Questão 10 Quantidade % Ótimo 15 41,67% Bom 19 52,78% Indiferente 2 5,56% Ruim 0 0,00% Péssimo 0 0,00%
Figura 27: Respostas referentes à questão 10.
70
Questão 11. Como você avalia a possibilidade de compartilhar, discutir e opinar as informações inseridas por seu grupo na geração de uma Revisão Sistemática sem a necessidade de se reunirem fisicamente?
Questão 11 Quantidade % Ótimo 12 33,33% Bom 21 58,33% Indiferente 1 2,78% Ruim 1 2,78% Péssimo 1 2,78%
Figura 28: Respostas referentes à questão 11.
As questões 12, 13 e 15 referenciam a proposta central deste trabalho, a
interatividade. Dessa forma, estes resultados são de grande importância para uma
avaliação positiva ou negativa da proposta deste trabalho. Os resultados obtidos destas
questões foram respectivamente: 75% (soma dos resultados “Bom” e “Ótimo”) dos
participantes afirmaram que a interatividade através de comentários seria bem vinda
para geração de RS; 75% dos participantes acreditam que a interação entre usuários e/ou
avaliadores iria realmente melhorar a qualidade da RS gerada; e 94,44% (soma dos
resultados “Bom” e “Ótimo”) dos participantes afirmaram que ver o conteúdo do
histórico de discussões da geração dos campos da RS é bastante positivo. Os detalhes
destes resultados podem ser vistos nas Figuras 29, 30 e 32 respectivamente. Estes
resultados afirmam que a interatividade entre usuários e/ou avaliadores durante a
geração de uma RS em uma ferramenta seria muito positiva, pois permite que estes
concentrem seus comentários em um único lugar e especificamente sobre um campo, o
que torna fácil o entendimento de como eles chegaram ao resultado final de cada campo
da RS gerado.
71
Questão 12. Como você avalia a possibilidade de interatividade entre usuários através de comentários, os quais simulam um fórum de discussão?
Questão 12 Quantidade % Ótimo 7 19,44% Bom 20 55,56% Indiferente 7 19,44% Ruim 2 5,56% Péssimo 0 0,00%
Figura 29: Respostas referentes à questão 12.
Questão 13. Você acredita que a interatividade através de comentários entre usuários e/ou avaliadores melhoraria a qualidade da Revisão Sistemática?
Questão 13 Quantidade % Sim 27 75,00% Não 5 13,89% Não tenho opinião 4 11,11%
Figura 30: Respostas referentes à questão 13.
Os resultados da questão 14 indicam que 72,22% (soma dos resultados “Bom” e
“Ótimo”) acreditam que divulgar seus trabalhos seria uma funcionalidade positiva.
72
Questão 14. A ferramenta ainda dá a possibilidade de tornarem públicas as Revisões Sistemáticas geradas a fim divulgar seu trabalho. Como você avalia essa possibilidade?
Questão 14 Quantidade % Ótimo 12 33,33% Bom 14 38,89% Indiferente 7 19,44% Ruim 3 8,33% Péssimo 0 0,00%
Figura 31: Respostas referentes à questão 14.
Questão 15. Como você avalia a possibilidade de ver todo o histórico e discussões sobre cada campo da revisão?
Questão 15 Quantidade % Ótimo 17 47,22% Bom 17 47,22% Indiferente 2 5,56% Ruim 0 0,00% Péssimo 0 0,00%
Figura 32: Respostas referentes à questão 15.
73
Outras formas de visualizar os resultados das questões foram feitas seguindo as
orientações de [KITCHENHAM et al., 2002d] e [KITCHENHAM et al., 2003], em que
os resultados foram obtidos e agrupados em categorias de questões, das quais foram
descritas no Capítulo 5.4 e podem ser visualizadas abaixo:
Categoria 1 (Questões 6, 7, 8 e 11): Avaliação da proposta da ferramenta;
Categoria 2 (Questões 9 e 10): Avaliação da funcionalidade de adição de
avaliadores;
Categoria 3 (Questões 12, 13 e 15): Avaliação da forma como a ferramenta
aplica a interatividade.
Dessa forma, observando-se as Figuras 33, 34 e 35 pode-se afirmar que a
avaliação das categorias de questões foram efetivadas com um resultado bastante
satisfatório. Nos casos em que as respostas divergem de tipo, é considerado satisfatório
os resultados “Bom” e “Ótimo”, e insatisfatório os resultados “Indiferente”, “Ruim” e
“Péssimo”, e satisfatórios os resultados “Sim” e insatisfatórios os resultados “Não” e
“Não tenho opinião”.
Categoria 1: Avaliação da proposta da ferramenta. Categoria 1 Quantidade % Satisfatório 127 88,19%Insatisfatório 17 11,81%
Figura 33: Respostas referentes à Categoria 1.
74
Categoria 2: Avaliação da funcionalidade de adição de avaliadores. Categoria 2 Quantidade % Satisfatório 69 95,83% Insatisfatório 3 4,17%
Figura 34: Respostas referentes à Categoria 2.
Categoria 3: Avaliação da forma como a ferramenta aplica a interatividade. Categoria 3 Quantidade % Satisfatório 88 81,48%Insatisfatório 20 18,52%
Figura 35: Respostas referentes à Categoria 3.
O cálculo feito para se chegar ao resultado obtido em relação às Categorias 1, 2
e 3, foi a soma absoluta dos valores de cada questão envolvida, ou seja, no caso da
Categoria 1, seria:
Figura 36: Fórmula de cálculo do resultado da Categoria 1 de questões.
RF = RA‐Q6 + RA‐Q7 + RA‐Q8 + RA‐Q11
RF = resultado final RA‐Q4 = resposta absoluta da questão 4
75
Assim, a Categoria 1 alcançou a margem de 88,19% de satisfação, ou seja, a
proposta da ferramenta foi recebida com aprovação obtendo um ótimo resultado. A
Categoria 2 alcançou 95,83% de satisfação em relação a funcionalidade de poder
adicionar um avaliador na RS do usuário para que este possa orientar na melhoria do
conteúdo e sua qualidade. A Categoria 3 também teve um resultado bastante
satisfatório, apesar de ser a de menor valor em porcentagens, alcançando 81,48% de
resultados positivos.
Para a análise da última questão, a qual é uma questão aberta, em que os
participantes puderam adicionar qualquer tipo de pensamento que julgaram relevantes
sobre a proposta da ferramenta, dos quais a maioria se interessou pela proposta e
realmente sentiram muita curiosidade para utilizá-la. Muitos elogiaram a iniciativa e os
recursos mais precisamente de versionamento dos campos enviados e do
armazenamento de histórico de discussões. Contudo também houve críticas em relação
ao funcionamento não ser tão desejado e inovador, demonstrando outras necessidades,
porém, admitiram que a proposta da ferramenta e seus recursos adicionais iriam ajudar
bastante na realização de RS. A visualização completa das respostas dissertativas dos
participantes podem ser vistas na Tabela 7.
Q16. Dê sua opinião sobre a proposta da ferramenta SAEE, suas sugestões e críticas. Fique a vontade para responder. (Respostas com apenas um ponto (.) ou traço (-) foram desconsideradas). R: A ferramenta tem uma proposta interessante, vou querer conhecê-la quando estiver pronta. R: Eu não gostei do método de comentários. Acho que deve ter uma forma melhor de ter esta avaliação. O mais interessante para a ferramenta é ela guiar todo o processo, principalmente a parte de filtros quantitativos e qualitativos. R: É um sistema de boa utilização, principalmente quando os grupos são obrigatoriamente distantes geograficamente. Agora, precisa realmente tem o diferencial de outras ferramentas de compartilhamento de documentos, como o Google Docs. Sendo assim, é um trabalho relevante!!! Parabéns!!! R: Em uma análise prévia da ferramenta, com base no curto vídeo fornecido, existem ferramentas de colaboração (ex. google docs, dropxbox, documentos com track changes) que possibilita essa interatividade e cooperação entre os integrantes do grupo. R: Disponibilizar protótipo R: Bem, creio que quando iniciar a utilização da ferramenta, ficaria mais fácil dar criticas e sugestões, porem o uso continuo dela é que faz amadurecer o processo. R: Achei muito interessante essa proposta, pois realmente é difícil de reunir o pessoal, e ideia de poder ver o histórico das informações que fazemos também foi bem elaborada. R: Boa ferramenta, realmente precisamos de ferramentas assim. R: Boa proposta, seria bem vinda. R: Ajuda, mas não elimina um dos maiores problemas, que é o gerenciamento da quantidade de informações em planilhas, e das concordâncias/discordâncias.
76
R: Ajuda, mas não elimina um dos maiores problemas, que é o gerenciamento da quantidade de informações em planilhas, e das concordâncias/discordâncias. R: Interessante, gostei da proposta, mas queria poder utilizar a ferramenta para opinar mais. R: Legal essa ferramenta, mas ver seu funcionamento seria melhor. R: Boa iniciativa.
R: A interatividade só será útil se a ferramenta oferecer funcionalidades e usabilidade boa o suficiente para atrair os usuários. Sem funcionalidades, não existirão usuários para interagir.
R: Eu acho que a ideia da ferramenta pode ser interessante, no entanto tenho alguns comentários a fazer. Eu achei confuso um documento de revisão sistemática ser mantido através de abas para as diferentes seções (título, questões de pesquisa, etc), ou seja, não ser completamente corrido, como ele ficaria no protocolo de revisão sistemática. Além disso, também achei confusa a manutenção de versões em um fórum retrátil. Acho que o usuário vai ter mais trabalho em saber qual a versão que ele deve responder. Além disso, eu não consegui perceber nenhuma opção de controle de alterações para o texto... Se tudo for feito via criação de uma nova versão como foi no caso do vídeo apresentado, acho que pode ficar muito mais trabalhoso manter o documento dessa revisão sistemática.
R: Excelente a proposta da ferramenta! Fiquei curiosa para saber sobre o controle das bases de dados, extração dos documentos e controle da análise. Como a ferramenta auxilia nestes termos? Há a possibilidade de integrar com o Mendeley (por exemplo) ou outras ferramentas que auxiliam na condução e análise da Revisão? No mais, quero desejar parabéns pelo trabalho!
R: Uma ferramenta de Revisão Sistemática ideal necessitaria a geração de gráficos e tabelas para compor as extrações realizadas. O foto da ferramenta SAEE parece estar limitado a "facilidade" de comunicação entre os integrantes de um grupo que estão realizando uma Revisão Sistemática. É uma ideia, mas não sei se tão interessante quanto propõe tendo em vista os diversos meios de comunicação que existem hoje. Também é difícil analisar esse ponto relativo a comunicação uma vez que não tive dificuldades, nem estava tão distante geograficamente dos membros das revisões sistemáticas que fiz.
R: Acrescenta a opção para conferencias de vídeos pois tornaria as discussões melhores.
R: Ótima proposta. As questões de usabilidade da ferramenta devem ser bem pensadas para que ela efetivamente facilite o trabalho, e não gere mais necessidade de "preenchimento de campos". A integração com o e-mail dos participantes também parece ser uma funcionalidade fundamental.
R: Nada a declarar.
R: Bom, já tinha pensado em algo semelhante, no meu caso seria disponibilizar o arquivo (por exemplo em latex on line) e cada um ia melhorando (não sei se sua ferramenta faz isso) e deixando os comentários.
R: O maior problema de uma revisão sistemática distribuída não esta na dificuldade de comunicação, mas sim nas etapas que exigem a avaliação de trabalhos por mais de um usuário, ou sejam uma forma de adicionar um possível artigo a revisão e que de forma fácil os participantes possam avalia-los e ver a avaliação dos outros, e dai sair o resultado sobre aquele trabalho. Acho que o ponto principal deveria ser este, onde esta a maior dificuldade em uma revisão, pois são muitos artigos, o que torna o e-mail e chats inviáveis.
R: As reuniões presenciais são fundamentais para o desenvolvimento de uma SLR.
R: A ferramenta tem um propósito muito interessante. A inserção de comentários para colaboração em um RS é de suma importância, principalmente, na fase de análise de resultados. Nas RS que participei mantivemos o "controle" por meio de um "coordenador" e ele coletava e sumarizava os resultados. Os conflitos eram gerenciados por este coordenador que, em muitos casos, coletava a opinião de cada um dos revisores e tomava a decisão. Também, acho interessante a criação de chats on-line (tipo, gtalk) e, em um patamar mais elevado, a inserção de PDFs com possibilidade de anotações e resumos, meio que buscando criar um repositório dos papers selecionados. Além disso, a inclusão do protocolo e a criação de uma ferramenta para guiar durante as etapas da revisão, tipo um workflow. Em suma, é isso. De forma geral, achei muito interessante a ferramenta, mas senti que ela ainda carece de mais recursos e funcionalidades.
77
R: Ótima ideia. Mas achei que ficou faltando relacionar com uma base de dados bib ou coisa do tipo.
R: Precisaria ver as outras funcionalidades para poder opinar melhor.
R: Algumas sugestões: a) Video ficou ruim de ler o que estava na tela. Sugiro dar mais zooms durante a gravação.b) Que tal mandar um e-mail para os avaliadores quando um novo comentário/revisão for inserido no sistema. c) Para ampliar as possibilidades de uso da SAEE, sugiro dar uma olhada na ferramenta START e tentar implementar funções de busca de artigos, cadastro, extração de dados direto das fontes de busca, geração de relatórios, além de exportar e importar dados. d) É possível um áudio com todos os avaliadores da revisão? Isso seria bem interessante. Sei que existem ferramentas hoje (como o skype) que possibilitam isso, mas você poderia customizar a SAEE para que as discussões fossem focadas no artigo analisado. Por hora é só, espero ter a oportunidade de conhecer depois essa ferramenta e quem sabe dar mais sugestões.
R: Parabéns pela iniciativa. Ela está disponível? Seria interessante um exemplo mais completo, com resultados maiores para poder ser melhor visualizada. É possível "clonar" uma revisão já feita ou em andamento? Ela gera gráficos?
R: Acho que mapas mentais também são interessantes.
R: Mostrar mais funcionalidades no vídeo.
R: Aparentemente eu gostei, gostaria de testar para dar uma resposta mais concreta
R: A proposta é boa. Sugiro que disponibilizem uma versão de testes para que as pessoas possa avaliar melhor o sistema e assim poderem colaborar com sugestões mais construtivas.
Tabela 7: Respostas dissertativas dos participantes.
5.8. Conclusões
A aplicação do Survey foi considerada satisfatória, apesar da quantidade de
participantes não ser grande, porém, obteve um resultado consideravelmente consistente
no que se refere à proposta da ferramenta SAEE.
A proposta foi avaliada obtendo um resultado satisfatório, e com isso, foi
constatado que a comunidade acadêmica receberia uma ferramenta de apoio à realização
de revisões sistemáticas com muito agrado, pois muitos dos participantes tiveram
curiosidade de conhecer a ferramenta mais a fundo, para poder observar melhor suas
funcionalidades e assim poder contribuir com uma maior e mais consistente crítica, seja
esta positiva ou negativa.
Foi constatado também que muitos dos estudantes que receberam o e-mail com o
endereço lógico do vídeo demonstrativo e do questionário, não tiveram o interesse ou
curiosidade de verificar a ferramenta ou mesmo responder ao questionário, indicando
que, para uma pesquisa mais elaborada, é necessário se fazer uma forma mais intrusiva
de demonstração da proposta da ferramenta, como a visita em sala de aula ou mesmo
abordar os estudantes no campus universitário para que estes não tenham como ignorar
ou, ao menos, minimizar a ausência de participantes.
78
6. Limitações da ferramenta SAEE
A ferramenta SAEE possui algumas limitações no que se refere às suas
funcionalidades, por se tratar de um protótipo, ainda necessita de testes diversos. Com
seu foco voltado à interatividade de usuários, a ferramenta não trás algumas
funcionalidades reconhecidas por alguns participantes do Survey como realmente
relevantes em uma ferramenta para RS. Alguns exemplos são:
A possibilidade de se armazenar documentos PDF para compartilhamento;
Alertas de movimentação por e-mail;
Geração de gráficos e tabelas para auxiliar o andamento da RS;
Integração com ferramentas de comunicação por áudio em tempo real;
Integrar com uma base de dados “.bib”;
Avaliação on-line de documentos PDF e ranking de qualidade;
Geração de relatórios de atividades.
Assim, estas reivindicações foram consideradas e serão relevantes para o futuro
da ferramenta SAEE, podendo ser atribuídas para as novas versões, melhorando seu
funcionamento e atendendo melhor a comunidade acadêmica a qual exige uma
ferramenta que realmente possa fazer diferença na realização de RS.
7. Conclusões e trabalhos futuros
Este trabalho teve o objetivo de demonstrar a interatividade entre usuários na
geração de uma RS. Dessa forma, foi desenvolvido um sistema de apoio à interatividade
em revisões sistemáticas em engenharia de software para suprir a necessidade
constatada por estudantes de se reunirem para gerar uma RS, em que pudessem estar
geograficamente distantes, mas que a distância não os prejudicasse. Assim, através de
estudos realizados sobre as dificuldades mencionadas, o sistema desenvolvido foi feito
seguindo as orientações de autores renomados na área de RS em ES, em que consta não
apenas com as funcionalidades básicas para se construir uma RS de forma completa,
mas também que esta possa ser construída de forma interativa, ou seja, que usuários
possam colaborar uns com os outros para juntos gerarem uma RS na qual, durante todo
o processo, possam gerar versões de conteúdo e interagir através de comentários
voltados a estas versões.
79
Um estudo de caso foi inicialmente feito para avaliar a proposta da ferramenta
por estudantes de Mestrado do curso de Qualidade de Sistemas, em que estes utilizaram
e forneceram retornos sobre o funcionamento da ferramenta, porém, este foi cancelado
por motivos de organização. Os estudantes começaram a utilizar a ferramenta após
terem feito as RS, ou seja, para estes, foi um processo retroativo, o que não demonstrou
ser uma forma adequada de avaliar corretamente a utilização e a proposta da ferramenta.
Os estudantes não utilizaram a ferramenta da forma e pelo motivo desta ter sido
desenvolvida, ou seja, não utilizaram a interatividade que esta proporciona, tornando o
estudo inválido e não adequado para este trabalho.
Dessa forma, foi considerado um outro tipo de avaliação da proposta da
ferramenta, a aplicação de um Survey, o qual poderia considerar com uma maior
relevância a proposta da ferramenta, assim, foi disponibilizando um vídeo
demonstrativo que pôde ser evidenciado as funcionalidades de interatividade da
ferramenta com sua proposta original. Um e-mail foi feito e enviado ao grupo de
estudantes de Mestrado e Doutorado da Universidade Federal do Rio Grande do Norte e
à SBC-L a fim de realizar este Survey e, apesar da pouca quantidade de participantes, os
resultados obtidos foram satisfatórios, pois os participantes demonstraram uma grande
curiosidade sobre a ferramenta e suas funcionalidades, além de os resultados finais
apurados terem sido satisfatórios com resultados positivos acima dos 80%. A proposta
da ferramenta foi considerada satisfatória e esta poderá ser disponibilizada para
utilização.
Este trabalho também teve objetivos secundários, os quais foram os de mostrar a
validade da utilização de RS, pois esta ainda se encontra um pouco “escondida“ da área
acadêmica, demonstrando que o uso de RS poderia ser melhor aplicada na área de pós-
graduação. A aplicação do Survey mostrou ainda que existem muitos estudantes que
não tem conhecimento sobre esta forma de pesquisa e, por verem o vídeo demonstrativo
e responderem ao questionário, tiveram curiosidade de conhecê-la.
Como trabalhos futuros, pretende-se dar continuidade no desenvolvimento da
ferramenta SAEE, considerar as críticas e sugestões dos participantes da aplicação do
Survey e também do estudo de caso, o que apesar de ter sido cancelado, suas críticas e
sugestões puderam ser consideradas, adicionar melhorias e mais funcionalidades
referentes à interatividade dos usuários e tornar a ferramenta viável para um uso mais
amplo.
80
APÊNDICE A
Estudo de caso: Aplicação da ferramenta SAEE
Um estudo de caso foi feito para avaliar e obter dados preliminares sobre a
viabilidade de utilização da ferramenta SAEE. A avaliação foi aplicada em estudantes
de pós-graduação em Ciência da Computação (Mestrado), a qual foi aplicado um
questionário durante o curso de Qualidade de Sistemas. A avaliação foi feita
virtualmente, por meio do software gratuito Googledocs, e foi realizada durante duas
semanas, das quais os estudantes disponibilizaram para preencher e enviar o formulário.
Quinze estudantes estavam aptos para participaram da avaliação, dos quais foram
divididos em quatro grupos, gerando, assim, quatro RS.
Dessa forma, o questionário construído para a avaliação consiste de cinco
objetivos principais, mostrados na Tabela 1, e vinte e quatro questões, mostrados na
Tabela 2. Seguindo os objetivos, o questionário foi dividido em cinco partes das quais
foram transparentes aos participantes: a parte 1 (Q1 a Q4), se refere a coletar dados das
opiniões dos estudantes em relação a realizar a atividade com e sem a ferramenta
SAEE; a parte 2 (Q5, Q6, Q8, Q12, Q14, Q18 e Q21), se refere a opinião dos estudantes
sobre as funcionalidades específicas da ferramenta SAEE; a parte 3 (Q7, Q9, Q10, Q11,
Q13, Q15, Q16, Q17, Q19, Q20), se refere a interatividade proporcionada pela
ferramenta SAEE; a parte 4 (Q22), se refere a caracterização da ferramenta SAEE sobre
sua facilidade de uso; a parte 5 (Q23), se refere a caracterização da ferramenta SAEE
sobre sua utilidade. Além de uma questão que será aberta para o estudante opinar
livremente sobre a ferramenta ou sobre o processo de RS em si. Todas as partes
envolvidas acima podem ser vistas nos objetivos mostrados na Figura 1.
Figura 1: Distribuição de objetivos e questões.
81
Objetivos Descrição 1 Avaliar se há diferenças na geração de RS com e sem uma ferramenta de auxílio. 2 Avaliar as funcionalidades adicionais da ferramenta SAEE. 3 Avaliar a interatividade da ferramenta SAEE. 4 Avaliar a facilidade de uso da ferramenta SAEE. 5 Avaliar a utilidade da ferramenta SAEE.
Tabela 1: Objetivos do questionário.
Questão Descrição Q1 Em sua opinião, foi mais fácil gerar uma RS com o auxílio da ferramenta? Q2 Em sua opinião, houve fácil interação entre você e seu grupo na geração da RS
com o auxílio da ferramenta? Q3 Em sua opinião, a interação entre seu grupo e o professor foi melhor com o auxílio
da ferramenta? Q4 Em sua opinião, a organização do conteúdo gerado pelo grupo durante o processo
da RS foi melhor com o auxílio da ferramenta? Q5 As orientações contidas nas telas facilitaram o uso da ferramenta? Q6 As orientações de preenchimento contidas em cada item da RS melhorou o
entendimento destes? Q7 Como você avalia a interatividade entre usuários através de comentários? Q8 Como você avalia a possibilidade de poder adicionar um avaliador em sua RS? Q9 A interatividade através de comentários entre usuários de seu grupo melhorou a
qualidade da RS? Q10 A interatividade através de comentários melhorou: Q11 A interação entre usuários e avaliadores foi frequente e satisfatória? Q12 A possibilidade de ver o conteúdo das RS de outros usuários o ajudou a melhorar a
qualidade de sua RS? Q13 A utilização da ferramenta por múltiplos usuários inserindo conteúdo de forma
simultânea tornou o processo da RS mais rápido e satisfatório? Q14 A possibilidade de ver o conteúdo das versões geradas de cada item possibilitou
melhora de qualidade na geração de novas versões? Q15 A interatividade através de comentários entre usuário(s) e avaliador(es)
proporcionou alguma melhora na qualidade da RS? Q16 A interação com o avaliador foi mais frequente? Q17 A interação com o avaliador foi satisfatória? Q18 A possibilidade de ver o conteúdo das RS de outros usuários o ajudou a melhorar a
qualidade de sua RS? Q19 A utilização da ferramenta por múltiplos usuários inserindo conteúdo de forma
simultânea tornou o processo da RS mais rápido? Q20 A utilização da ferramenta por múltiplos usuários inserindo conteúdo de forma
simultânea foi satisfatória? Q21 A possibilidade de ver o conteúdo das versões geradas de cada item possibilitou
melhora de qualidade na geração de novas versões? Q22 Como você avalia a frase "Considerando o que sei sobre RS, o uso da ferramenta
facilitou a execução das atividades que compõem o processo de RS.”?
82
Q23 Como você avalia a frase "Considero a ferramenta útil para executar minhas RS.”? Q24 Dê sua opinião sobre a utilização da ferramenta SAEE, suas sugestões e críticas.
Fique a vontade para responder.
Tabela 2: Questões utilizadas na modelagem GQM..
As respostas das questões variaram de acordo com seu propósito, porém um
padrão foi feito para que o questionário fosse mais rápido de ser preenchido. As
respostas foram divididas em quatro tipos distintos, dos quais podem ser visualizados na
Tabela 3.
Tipo 1 Tipo 2 Tipo 3 Tipo 4 - Sim - Não
- 5 (Ótimo) - 4 (Bom) - 3 (Regular) - 2 (Ruim) - 1 (Péssimo)
- organização do conteúdo na RS - comunicação de seu grupo - qualidade da RS - não houve melhora
- Resposta dissertativa
Q1 X Q2 X Q3 X Q4 X Q5 X Q6 X Q7 X Q8 X Q9 X
Q10 X Q11 X Q12 X Q13 X Q14 X Q15 X Q16 X Q17 X Q18 X Q19 X Q20 X Q21 X Q22 X Q23 X Q24 X
Tabela 3: Tipos de resposta do questionário..
Questão
Tipo de resposta
83
Avaliação e análise do estudo
Apesar de ser um estudo real e voltado a um público específico, dos quais
participaram apenas estudantes de Mestrado de um curso também específico, Qualidade
de Software, os resultados não foram satisfatórios por uma série de fatores que
impediram que os estudantes utilizassem a ferramenta da forma como esta deveria ser
utilizada. Estes fatores foram enumerados e analisados abaixo:
1. As RS foram feitas antes de se aplicar este estudo;
2. Os estudantes já haviam passado pelos passos que a ferramenta proporciona;
3. A utilização da ferramenta era optativa;
4. A principal funcionalidade da ferramenta não foi utilizada;
5. Muitos estudantes resistiram à utilização da ferramenta por não atender às
requisições pessoais destes, apesar de seu foco ser a interatividade;
6. Por já terem feito as RS, os estudantes não viram motivos de utilizar a
ferramente.
Assim, os resultados obtidos da pesquisa feita se resumiram a apenas dois
estudantes que responderam ao questionário, dos quais responderam, em sua maioria,
como “regular”, que se encontra nas opções de respostas, porém, esta respostas
significou que os estudantes quiseram dizer na verdade uma resposta do tipo
“indiferente”, ou seja, que não tinham opinião para a questão respectiva, pois estes
argumentaram que as RS já haviam sido feitas, ou que a ferramenta não estava
proporcionando melhorias com funcionalidades que estes queriam que a ferramenta
tivesse.
Contudo, apesar da baixa quantidade de participantes, algumas respostas podem
ser consideradas positivas no que diz respeito à proposta da ferramenta, como as
respostas de algumas questões em que ambos os participantes acreditam que: a
possiblidade de adição de um avaliador à RS é bastante positiva; e a possibilidade de
ver o histórico de versões e discussões foi bem recebida; a ferramenta é de fácil
utilização; o entendimento do que acontecia durante a utilização da ferramenta foi
satisfatório; a ferramenta é simples e pode ser facilmente manipulada; a ferramenta
tornou a geração de RS mais fácil; a ferramenta seguiu o processo definido na literatura;
e a ferramenta facilitou o processo da RS. Um gráfico demonstrativo em que se pode
ver todas as respostas dos dois participantes encontra-se na Figura 2.
84
Figura 2: Gráfico de respostas do questionário.
Na Figura 2, as questões de 1 a 6 contém respostas do tipo 1, as quais podem ser
vistas na Tabela 3, porém, para o gráfico, foram representadas como a alternativa “Sim”
sendo uma resposta da relevância “4” e a alternativa “Não”, da “2”. A questão 10
também foi modificada, porém ambos os participantes selecionaram a resposta indicada
como “não houve melhora”, sendo então mapeada como relevância “3”.
As respostas da questão 24, por ser aberta, foram adicionadas integralmente, e
podem ser vistas na Tabela 4. Nesta, os participantes demonstraram suas críticas e
sugestões, além de mencionar muitos dos motivos pelos quais optaram por responder ao
questionário da forma como o fizeram, dentre eles estão os motivos listados no início
deste Capítulo.
Q24. Dê sua opinião sobre a utilização da ferramenta SAEE, suas sugestões e críticas. Fique a vontade para responder. R: A ferramenta no geral é apenas um conjunto de item de um RS que a pessoa vai preenchendo e o avaliador pode realizar "feedbacks". Na minha opinião, se o propósito inicial era ajudar na realização de uma RS como um todo, não apenas para a etapa da avaliação, a ferramenta deveria ser mais voltada ao fluxo da RS.
Etapa 1 >> Etapa 2 >> Etapa 3 >> Etapa 4 >> ... >> Etapa Final Cada etapa teria as datas limites e as tarefas que deveriam ser realizadas. E o percentual de cada etapa. 0% a 100%. Exemplo: Etapa 1: Definir a área da RS, o tema, a importância e a necessidade da RS Etapa 2: Definir os Métodos Fontes e Estratégias de Revisão Etapa 3: Pesquisa e update dos artigos selecionados na fase X da RS etc.. Era muito importante que a ferramenta servisse como um repositório dos artigos buscados, e que ela agrupasse esses artigos de acordo com os critérios de avaliação da RS. Compartilhando esses artigos com todos os participantes da RS. Isso pouparia o trabalho de ficar enviando artigos por email e organizando aqueles aprovados e reprovados em cada etapa da revisão, foi uma coisa que deu muito trabalho. Ao completar todas as etapas, ai sim
85
poderia ter um formulário para avalição com todos os itens da revisão. De forma que a ferramenta já preenchesse cada item com as informações coletadas em cada etapa do processo de realização da RS. Ps.: A ferramenta não foi usada desde o início da RS, então muitas das perguntas desse questionário não se aplicam, por isso receberam avaliação regular (nem bom, nem ruim), já que não tinha a alternativa "não se aplica". R: Quanto à ferramenta, eu senti bastante dificuldade de gerar novas versões. Inclusive, quando gerei a versão (cliquei em ENVIAR), o rascunho do meu trabalho atual continuava na tela... Então eu fazia algumas modificações e clicava em ENVIAR novamente, e dizia que havia sido enviado. Apareceu até mensagem de confirmação e tudo. Mas não aparecia uma nova versão ali embaixo... Então fiquei confusa... Mas acreditei que havia enviado devido a mensagem de confirmação. Porém, quando eu enviei tudo e reentrei na Revisão Sistemática, percebi que somente a primeira versão havia sido enviada. Fiquei bastante triste com isso... No lugar de novas versões, foram gerados comentários vazios em meu nome. Outro problema encontrado foi na criação de tabelas. A tabela criada no rascunho aparece sem bordas, mas quando atualizo, aparece as bordas (caso tenha 2 colunas, se houver mais continua sem aparece). E quando eu submeto e verifico a versão gerada, a tabela não possui bordas... Era para aparecer opção com bordas, caso contrário pode dificultar a leitura dos dados. Um último problema encontrado foi quanto atualizar a versão. Não encontrei nenhuma opção de "EDITAR ESTA VERSÃO". Por exemplo, estou lendo a versão e percebo um erro. Quero criar uma nova versão baseada naquela. Para fazer isso, eu copio e colo todo o conteúdo na área de trabalho. Porém, o COPIAR E COLAR ainda apresenta um problema: ele não copia os atributos de cores. Então se eu gerei uma versão com certas partes coloridas, se for alterar, quando copiar e colar vai vir tudo com a letra padrão: preto. Isso aconteceu comigo no caso do "Referências e Anexos". Apesar desses três problemas encontrados, a experiência foi positiva. As questões guiaram no processo de escrita do artigo visto que os nomes eram bem indicativos. Porém, não sabia que todos podiam mexer simultaneamente, então nem usamos a ferramenta para todo o processo da escrita em conjunto, usamos apenas para olhar os tópicos e depois submeter. A questão de não ter como deletar versões também não nos depositou confiança, e por isso só submetemos quando estava praticamente pronto. Mas eu gostei muito da questão de datas, que podia colocar o prazo, e depois alterar. Achei mais flexível, porque atrasamos o deadline, mas toda vez que alterava eu tinha que ir lá alterar cada uma... Achei bom porque me dava certo trabalho e me colocava mais culpa por estar atrasada no deadline, mas também foi bom porque nos propiciou o envio alterando somente a data limite de submissão. Agradeço desde já pela possibilidade de utilizar a ferramenta e postar minha opinião. Espero que os comentários ajudem.
Tabela 4: Respostas dissertativas dos estudantes.
Conclusão
Este estudo foi realizado com o intuito de validar a utilização de RS de forma
interativa e verificar como os participantes iriam responder à ferramenta, porém, muitos
problemas ocorreram dos quais inviabilizaram a utilização deste estudo para uma
indicação sólida de que a ferramenta e sua proposta atendem ou não os objetivos
definidos. Assim, os resultados obtidos não foram satisfatórios para tirar uma conclusão
86
concreta sobre a proposta da ferramenta, contudo, mesmo sendo um estudo inválido, as
respostas obtidas puderam ajudar na verificação das funcionalidades que foram aceitas e
que alcançaram um nível bom de satisfação por parte dos participantes.
87
Referências Bibliográficas
[AMARAL, 2003] Amaral, E. Empacotamento de Estudo Experimentais em
Engenharia de Software, Dissertação de Mestrado. COPPE/UFRJ, Programa de
Engenharia de Sistemas e Computação, Rio de Janeiro, RJ, Brasil, 2003.
[APA, 2001] American Psychological Association. Publication Manual of the
American Psychological Association. 5th edn, American Psychological Association,
Washington, DC.
[BASILI, 2000] Basili, V., Caldiera, G., Rombach, H. The Goal Question Metric
Approach. University Of Maryland College Park, Maryland.
[BIOLCHINI et al., 2005] Biolchini, J. Mian, P. Natali, A, Travassos, G.“Systematic
Review in Software Engineering: Relevance and Utility, Relatório Técnico ES-
679/05, PESC - COPPE/UFRJ, 2005.
[CAVALCANTE, 2012] Cavalcante, F. Microsoft Office vs. LibreOffice vs. Google
Docs. Matéria Superdownloads. Disponível em: <http://www.superdownloads.com.br/
materias/microsoft-office-vs-libreoffice-vs-google-docs.html>. Acesso em: 03 jan.
2013.
[DEKEYSER, 2004] Dekeyser, S. Towards a new approach to tightly coupled
document collaboration, In Ninth Australasian Document Computing Symposium,
Melbourne, 2004.
[DOBRATZ, 2005] Dobratz, S. Thinking the long term: the XML-based publishing
workflow for handling electronic theses and dissertations at Humboldt University,
In ETD2005: Evolution Through Discovery; the 8th Int'l Symposium on Electronic
Theses & Dissertations, Sydney, 2005.
[DONOVAN, 2010] Donovan, J. Playing Well With Others: Collaborative Tools for
Successful Group Projects, University of Georgia School of Law Library, 2010.
[EDUCAUSE, 2008] Educause Learning Initiative. 7 things you should know about
Google Apps. Disponível em <http://net.educause.edu/ir/library/pdf/ELI7035.pdf>.
Acesso em: 03 jan. 2013.
88
[GERMAN, 2004] German, D. Mining cvs repositories, the softchange experience,
Proceedings of the 1st International Workshop on Mining Software Repositories, 2004.
[GOOGLEDOCS, 2006] Google Docs. Disponível em: <https://docs.google.com/>.
Acesso em: 03 jan. 2013.
[HERNANDES et al., 2012] Hernandes, E. Zamboni, A. Fabbri, S. Thommazo, A.
Using GQM and TAM to evaluate StArt – a tool that supports Systematic Review.
CLEI Electronic Journal, volume 15, número 1, paper 2, 2012.
[ICMC-USP et al., 2012] ICMC-USP. Martins, R. ReVis: User´s Manual. Institute of
Mathematics and Computer Science - University of São Paulo, 2012.
[JEDLITSCHKA et al., 2005a] Jedlitschka, A., Pfahl, D. Reporting Guidelines for
Controlled Experiments in Software Engineering. IESE-Report IESE-035.5/E.
[JEDLITSCHKA et al., 2005b] Jedlitschka, A., Pfahl, D. Reporting Guidelines for
Controlled Experiments in Software Engineering. In Proceedings of ACM/IEEE
International Symposium on Software Engineering 2005 (ISESE2005). Noosa Heads,
Australia, pp. 95–104.
[JURISTO; MORENO, 2001] Juristo, N., Moreno, A. Basics of Software Engineering
Experimentation. Kluwer Academic Publishers, Boston, MA.
[KITCHENHAM et al., 2001] Kitchenham, B. Pfleeger, S. Principles of Survey
Research Part 1: Turning Lemons into Lemonade, ACM SIGSOFT, Software
Engineering Notes Vol. 26 nº 6, 2001.
[KITCHENHAM et al., 2002] Kitchenham, B.A. Pfleeger, S.L. Pickard, L.M. Jones,
P.W. Hoaglin, D.C. El Emam, K. Rosenberg, J. Preliminary Guidelines for Empirical
Research in Software Engineering. IEEE Transactions on Software Engineering, Vol.
28, No. 8, pp. 721–734.
[KITCHENHAM et al., 2002a] Kitchenham, B. Pfleeger, S. Principles of Survey
Research Part 2: Designing a Survey, ACM SIGSOFT, Software Engineering Notes
Vol. 27 nº 1, 2002.
89
[KITCHENHAM et al., 2002b] Kitchenham, B. Pfleeger, S. Principles of Survey
Research Part 3: Constructing a Survey Instrumen, ACM SIGSOFT, Software
Engineering Notes Vol. 27 nº 2, 2002.
[KITCHENHAM et al., 2002c] Kitchenham, B. Pfleeger, S. Principles of Survey
Research Part 4: Questionnaire Evaluation, ACM SIGSOFT, Software Engineering
Notes Vol. 27 nº 3, 2002.
[KITCHENHAM et al., 2002d] Kitchenham, B. Pfleeger, S. Principles of Survey
Research Part 5: Populations and Samples, ACM SIGSOFT, Software Engineering
Notes Vol. 27 nº 5, 2002.
[KITCHENHAM et al., 2003] Kitchenham, B. Pfleeger, S. Principles of Survey
Research Part 6: Data Analysis, ACM SIGSOFT, Software Engineering Notes Vol.
28 nº 2, 2003.
[KITCHENHAM et al., 2004] Kitchenham, B. Procedures for Performing Systematic
Reviews, Technical Report Software Engineering Group, Keele University, Australia,
2004.
[KITCHENHAM et al., 2004a] Kitchenham, B. Dybå, T. Jørgensen, M. Evidence-
Based Software Engineering, In Proceedings of 26th International Conference on
Software Engineering (ICSE’04), pp. 273–281.
[KITCHENHAM et al., 2006] Kitchenham, B. Al-Khilidar, H. Ali Babar, M. Berry, M.
Cox, C. Keung, J. Kurniawati, F. Staples, M. Zhang, H. Zhu, L. Evaluating Guidelines
for Empirical Software Engineering Studies, In Proceedings of ACM/IEEE
International Symposium on Software Engineering 2006, ISESE 2006.
[KITCHENHAM, 2007] Kitchenham, B. Guidelines for performing Systematic
Literature Reviews in Software Engineering, EBSE Technical Report EBSE-2007-
01, Software Engineering Group Department of Computer Science Keele University,
2007.
[MARTINS, 2012] Martins, R. Felizardo, K. Systematic Literature Review
Supported by Visual Analytics, Revis: User´s Manual, University of São Paulo, ICMC
90
- Institute of Mathematics and Computer Science, Departament of Computer Science,
2012.
[MARTINS et al., 2010] Martins, A., Justino, A., Gabriel, G. SBIDM: comunicação
síncrona, assíncrona e multidireccional, Serviços de Bibliotecas, Informação
Documental e Museologia da Universidade de Aveiro Campus universitário de
Santiago, 2010.
[MICROSOFT, 2012] Microsoft Office Live (Sky Drive). Disponível em:
<https://skydrive.live.com>. Acesso em: 03 jan. 2013.
[MOHER et al., 2001] Moher, D. Schulz, K.F. Altman, D. The CONSORT Statement,
Revised Recommendations for Improving the Quality of Reports of Parallel-Group
Randomized Trials. Journal of the American Medical Association (JAMA) Vol. 285,
No. 15, pp. 1987–1991.
[MULLER et al., 2005] Muller, S. Klatt, M. An XML-based publishing platform, In
ETD2005: Evolution Through Discovery; the 8th Int'l Symposium on Electronic Theses
& Dissertations, Sydney, 2005.
[OTTER et al., 2007] Otter, A., Emmitt, S. Exploring Effectiveness of Team
Communication: Balancing Synchronous and Asynchronous Communication in
Design Teams, Department of Architecture, Building and Planning, University of
Technology, Eindhoven, the Netherlands, 2007.
[RADAJEWSKI et al., 2004] Radakewski, J. MacFarlane, S. Dekeyser, S. GOOD
Publishing System: Generic Online/Offline Delivery, In Ninth Australasian
Document Computing Symposium, Melbourne, 2004.
[REIS et al., 2006] Reis, A., Rocha, J., Garmeiro, A., Carvalho, J. Sistemas de
Comunicação Síncrona e Assíncrona de Dados, Departamento de Física,
Universidade da Beira Interior Covilhã, 6200 Covilhã, Portugal, 2006.
[SEFTON, 2006] Sefton, P. The integrated content environment (ICE), In
AusWeb06: The 12th Australasian World Wide Web Conference, Noosa, Australia,
2006.
91
[SHAW, 2003] Shaw, M. Writing Good Software Engineering Research Papers –
Minitutorial. In Proceedings of the 25th International Conference on Software
Engineering (ICSE’03). IEEE Computer Society, Portland, Oregon, pp. 726–736.
[SINGER, 1999] Singer, J. Using the APA Style Guidelines to Report Experimental
Results. In Proceedings of Workshop on Empirical Studies in Software Maintenance,
pp. 71–75.
[THINKFREE, 2009] Thinkfree On-line. Disponível em: <http://online.thinkfree.com>.
Acesso em: 03 jan. 2013.
[TRAVASSOS, 2006] Travassos, G. Mafra, S. Estudos Primários e Secundários
apoiando a busca por Evidência em Engenharia de Software, Relatório Técnico– ES
687/06, Programa de Engenharia de Sistemas e Computação COPPE/UFRJ, 2006.
[TRIPP, 2006] Tripp, D. Action research: a methodological introduction,
Educational Action Research Journal, Murdoch University, 2005.
[VANDERMOLEN, 2008] VanderMolen, J. Collaborative Writing, Tech & Learning.
Disponível em <http://www.techlearning.com/article/14296>. Acesso em: 03 jan. 2013.
[WOHLIN et al., 2000] Wöhlin, C., Runeson, P., Höst, M., Ohlsson, M., Regnell, B.,
Wesslén, A. Experimentation in Software Engineering: An Introduction, The
Kluwer International Series in Software Engineering, Norwell, USA, Kluwer Academic
Publishers, 2000.
[ZOHO, 2008] Zoho Work On-line. Disponível em: <http://www.zoho.com>. Acesso
em: 03 jan. 2013.
