Sistema de apoio à interatividade em revisões sistemáticas em engenharia de software

(1)

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

(2)

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

(3)

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.

(4)

(5)

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.

(6)

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

(7)

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

(8)

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

(9)

7

Figura 33: Respostas referentes à Categoria 1 ...73

(10)

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

(11)

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.

(12)

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.

(13)

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.

(14)

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.

(15)

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

(16)

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.

(17)

[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

(18)

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.

(19)

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,

(20)

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

(21)

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.

(22)

Section Subsection Scope Comments

Title* 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 assessment Data extraction

Data synthesis Included and

excluded studies Inclusion and exclusion criteria List of excluded studies with rationale for exclusion

(23)

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 analysis

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

(24)

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

(25)

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,

(26)

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

(27)

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

(28)

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

(29)

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 de referências Exportação Customização de atributos

Classificação automática de

artigos

Web _usuáriosMulti- 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

(30)

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

(31)

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

(32)

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.

(33)

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

(34)

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.

(35)

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;

(36)

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;

(37)

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

(38)

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)

(39)

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;

(40)

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.

(41)

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

(42)

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

(43)

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