serviÇos de apoio ao planejamento de revisÕes...
TRANSCRIPT
SERVIÇOS DE APOIO AO PLANEJAMENTO DE REVISÕES SISTEMÁTICAS DA
LITERATURA
Rafael do Espirito Santo
Dissertação de Mestrado apresentada ao
Programa de Pós-graduação em Engenharia de
Sistemas e Computação, COPPE, da
Universidade Federal do Rio de Janeiro, como
parte dos requisitos necessários à obtenção do
título de Mestre em Engenharia de Sistemas e
Computação.
Orientador(es): Guilherme Horta Travassos
Rio de Janeiro
Março de 2012
SERVIÇOS DE APOIO AO PLANEJAMENTO DE REVISÕES SISTEMÁTICAS DA
LITERATURA
Rafael do Espirito Santo
DISSERTAÇÃO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO
LUIZ COIMBRA DE PÓS-GRADUAÇÃO E PESQUISA DE ENGENHARIA (COPPE)
DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS
REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM
CIÊNCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAÇÃO.
Examinada por:
________________________________________________
Prof. Guilherme Horta Travassos, D.Sc.
________________________________________________
Profa. Cláudia Maria Lima Werner, D.Sc.
________________________________________________
Prof. Márcio de Oliveira Barros, D.Sc.
________________________________________________
Prof. Jorge Calmon de Almeida Biolchini, D.Sc.
RIO DE JANEIRO, RJ – BRASIL
MARÇO DE 2012
iii
Espirito Santo, Rafael
Serviços de Apoio ao Planejamento de Revisões
Sistemáticas da Literatura / Rafael do Espirito Santo – Rio de
Janeiro: UFRJ/COPPE, 2012.
XII, 155 p.: il.; 29,7 cm.
Orientador: Guilherme Horta Travassos.
Dissertação (Mestrado) – UFRJ/COPPE/Programa de
Engenharia de Sistemas e Computação, 2012.
Referências Bibliográficas: p. 104-110.
1. Engenharia de Software Experimental. 2. Revisão
Sistemática da Literatura. 3.Ontologias. 4. Gerência de
Conhecimento Científico. I. Guilherme, Horta Travassos II.
Universidade Federal do Rio de Janeiro, COPPE, Programa de
Engenharia de Sistemas e Computação. III. Título.
iv
Agradecimentos
Agradeço a Deus, por me capacitar e guiar em todos os desafios que sou
submetido.
Aos meus pais, Rita e Pedro, por estarem sempre presentes na minha
formação com a maior atenção do mundo e amor. Cada um teve um papel
fundamental para conquista deste objetivo.
Ao meu irmão André, que sempre esteve presente para me ajudar e
aconselhar.
Ao meu orientador Prof. Guilherme Horta Travassos, pelo tempo, confiança e
compromisso depositados para garantir a qualidade final desta dissertação. Desde a
época de estagiário tenho aprendido muito com você.
Aos companheiros do grupo ESE, pela troca de conhecimento e pelo apoio
fornecido desde a minha entrada no grupo de pesquisa. Em especial ao companheiro
Vítor Pires Lopes, pelas idéias e ajuda fornecida enquanto este trabalho estava
apenas no início e ao Thiago Ferraz pelo apoio na configuração de parte do apoio
ferramental desenvolvido neste trabalho.
À professora Cláudia Maria Lima Werner e ao Rodrigo Pereira dos Santos pela
passagem de conhecimento e apoio fornecidos durante o período de graduação e
mestrado.
Aos professores Jorge Calmon de Almeida Biolchini, Márcio de Oliveira Barros
e Cláudia Maria Lima Werner, por participarem da banca de defesa de mestrado.
Aos amigos que fiz desde os tempos de graduação. Fico muito feliz por tê-los
conhecido, de modo que torço para que a amizade perdure por muito tempo. Em
especial ao amigo Alexandre Sardinha, pela amizade e companheirismo em todos os
momentos.
À fundação CAPES, Fundação COPPETEC e FAPERJ, pelo apoio financeiro
durante o mestrado.
v
Resumo da Dissertação apresentada à COPPE/UFRJ como parte dos requisitos
necessários para a obtenção do grau de Mestre em Ciências (M.Sc.)
SERVIÇOS DE APOIO AO PLANEJAMENTO DE REVISÕES SISTEMÁTICAS DA
LITERATURA
Rafael do Espirito Santo
Março/2012
Orientador: Guilherme Horta Travassos
Programa: Engenharia de Sistemas e Computação
Nesta dissertação apresentamos uma abordagem para evolução de um
repositório de conhecimento sobre experimentação em Engenharia de Software por
meio da inclusão de uma ontologia de estudos secundários e um guia de apoio ao
processo de condução de revisões sistemáticas da literatura. Além disto, fez-se
também uma revisão da literatura com o intuito de identificar tecnologias existentes
que apoiassem alguma das etapas de uma revisão sistemática. A partir das limitações
identificadas nas tecnologias existentes, é proposto um conjunto de serviços de apoio
ao planejamento, execução e empacotamento de revisões sistemáticas. Por fim, foi
construída e avaliada a utilidade e facilidade de uso de uma ferramenta voltada para
apoiar pesquisadores inexperientes a planejar revisões sistemáticas, tendo como base
o repositório de conhecimento anteriormente citado.
vi
Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the
requirements for the degree of Master of Science (M.Sc.)
SERVICES TO SUPPORT PLANNING OF SYSTEMATIC LITERATURE REVIEWS
Rafael do Espirito Santo
March/2012
Advisor: Guilherme Horta Travassos
Department: Computer Science and Systems Engineering
This dissertation presents an approach for the evolution of a body of knowledge
on experimentation in Software Engineering through the inclusion of an ontology
of secondary studies and a guide to support the process of conducting systematic
literature reviews in software engineering. Furthermore, it was conducted a literature
review in order to identify the existent technologies that would support any of the
phases of a systematic review. From the identified limitations in such technologies, we
proposed a set of services to support the planning, execution and packaging of
systematic reviews. Finally, a support tool has been built and evaluated regarding its
utility and facility of use. This tool aimed at supporting inexperienced researchers in the
planning of systematic reviews based on the body of knowledge previously mentioned.
vii
Índice
1 Introdução ........................................................................................................................................... 1
1.1 Motivação .................................................................................................................................. 1
1.2 Problema ................................................................................................................................... 3
1.3 Objetivo ...................................................................................................................................... 4
1.4 Contexto .................................................................................................................................... 4
1.5 Metodologia ............................................................................................................................... 5
1.6 Organização .............................................................................................................................. 5
2 Introdução ao Ambiente de Apoio à Experimentação eSEE....................................................... 7
2.1 Introdução.................................................................................................................................. 7
2.2 eSEE: experimental Software Engineering Enviroment ..................................................... 8
2.3 Repositório de Conhecimento em Engenharia de Software Experimental ................... 11
2.3.1 Glossário de Termos ......................................................................................................... 12
2.3.2 Modelos Conceituais (Ontologias) .................................................................................. 13
2.3.3 experimental Studies Planning Assistant (eSPA) ......................................................... 15
2.4 Conclusão................................................................................................................................ 19
3 Revisões Sistemáticas da Literatura............................................................................................. 21
3.1 Processo de Condução de Revisões Sistemáticas da Literatura ................................... 21
3.2 Dificuldades e Lições Aprendidas no Contexto de Revisões Sistemáticas ................... 24
3.2.1 Aplicação de Revisões Sistemáticas da Literatura no Contexto de Estudos Qualitativos ....................................................................................................................................... 24
3.2.2 Emprego de Critérios para Avaliação de Qualidade de Estudos Primários .............. 25
3.2.3 Metodologia para Extração de Dados de Estudos Primários e Reporte dos Resultados ........................................................................................................................................ 26
3.2.4 Elaboração de Estratégias de Busca para Identificação de Estudos Primários ...... 26
3.2.5 Tempo e Esforço Gasto na Elaboração e Execução de Revisões Sistemáticas da Literatura ........................................................................................................................................... 27
3.2.6 Evolução da Aplicação de Revisões Sistemáticas na Engenharia de Software ...... 28
3.2.7 Definição de Escopo para Busca por Estudos Primários ............................................ 29
3.2.8 Cenário Mais Atual a Respeito da Aplicação de Revisões Sistemáticas da Literatura no Contexto da Engenharia de Software ................................................................... 30
3.3 Tecnologias de Apoio a Condução de Revisões Sistemáticas da Literatura ................ 31
3.3.1 Ferramentas de Gerência de Referências Bibliográficas ............................................ 32
3.3.2 Uso de Text Mining para Avaliação de Artigos que Descrevem Estudos Primários 35
3.3.3 Abordagem Visual para Auxiliar a Seleção e Revisão da Seleção de Estudos Primários ........................................................................................................................................... 36
3.3.4 EPPI Reviewer ................................................................................................................... 38
3.3.5 SLR-TOOL - A Tool for Performing Systematic Literature Reviews .......................... 38
3.3.6 StArt ..................................................................................................................................... 40
3.3.7 Review Manager (RevMan) .............................................................................................. 41
viii
3.4 Conclusão................................................................................................................................ 43
4 Evolução do Repositório de Conhecimento do eSEE ................................................................ 45
4.1 Introdução................................................................................................................................ 45
4.2 Processo para Construção dos Modelos Conceituais ...................................................... 46
4.2.1 Planejamento ...................................................................................................................... 46
4.2.2 Especificação ..................................................................................................................... 47
4.2.3 Conceitualização ................................................................................................................ 47
4.2.4 Formalização ...................................................................................................................... 47
4.2.5 Integração ........................................................................................................................... 55
4.2.6 Implementação ................................................................................................................... 55
4.2.7 Manutenção ........................................................................................................................ 55
4.2.8 Documentação ................................................................................................................... 56
4.2.9 Avaliação ............................................................................................................................. 56
4.3 Guia de Apoio ao Processo de Condução de Revisões Sistemáticas da Literatura ... 56
4.4 Inspeção dos Modelos Conceituais sobre Estudos Secundários e Guia de Apoio...... 63
4.4.1 Experiências obtidas com a Aplicação do Método de Inspeção dos Modelos Conceituais e Guia de Apoio.......................................................................................................... 69
4.5 Conclusão................................................................................................................................ 71
5 Ferramenta de Apoio ao Planejamento de Revisões Sistemáticas da Literatura .................. 72
5.1 Introdução................................................................................................................................ 72
5.2 Abordagem Proposta ............................................................................................................. 72
5.3 Arquitetura e Funcionalidades do Componente de Planejamento ................................. 80
5.4 Conclusão................................................................................................................................ 88
6 Estudo de Avaliação de Utilidade e Facilidade de Uso da SSPlan.......................................... 90
6.1 Introdução................................................................................................................................ 90
6.2 Modelo para Avaliação da SSPlan ...................................................................................... 90
6.3 Resultados da Avaliação da SSPlan ................................................................................... 94
6.4 Conclusão................................................................................................................................ 98
7 Conclusão ......................................................................................................................................... 99
7.1 Conclusões .............................................................................................................................. 99
7.2 Contribuições ........................................................................................................................ 100
7.3 Limitações ............................................................................................................................. 101
7.4 Perspectivas Futuras ........................................................................................................... 102
Referências Bibliográficas .................................................................................................................... 104
Apêndice I – Introdução sobre Ontologias ......................................................................................... 111
Linguagem LINGO e OntoUML para Representação Visual de Ontologias ......................... 113
Linguagem OWL para Representação Formal de Ontologias ................................................ 114
Referências Bibliográficas ................................................................................................................ 115
Apêndice II – Introdução às Tecnologias Utilizadas na Construção da Ferramenta de Apoio ao Planejamento de Revisões Sistemáticas da Literatura .................................................................... 116
Joomla e ProjectFork .................................................................................................................... 116
JBoss Seam.................................................................................................................................... 120
jBPM ................................................................................................................................................ 122
ix
Referências Bibliográficas ................................................................................................................ 125
Apêndice III – Ferramentas de Gerência de Referências Bibliográficas Identificadas ............... 127
JabRef ................................................................................................................................................. 127
EndNote .............................................................................................................................................. 127
Reference Manager ........................................................................................................................... 127
Mendeley ............................................................................................................................................. 128
Zotero .................................................................................................................................................. 128
CiteULike ............................................................................................................................................. 129
RefWorks ............................................................................................................................................ 129
Outras ferramentas identificadas .................................................................................................... 130
Apêndice IV – Modelos Ontológicos de Estudos Secundários ....................................................... 131
Apêndice V – Diagramas do Guia de Apoio ao Processo de Condução de Revisões Sistemáticas da Literatura .................................................................................................................... 133
Apêndice VI – Agrupamento dos Defeitos Relativos à Inspeção da Ontologia de Estudos Secundários, Guia de Apoio ao Processo de Condução de Revisões Sistemáticas e Documento de Requisitos para Construção de Serviços de Apoio ao Planejamento, Execução e Empacotamento de Revisões Sistemáticas ...................................................................................... 138
Apêndice VII – Respostas dos Participantes do Estudo de Avaliação da Ferramenta SSPlan 145
x
Índice de Figuras
Figura 1 - Processo de Execução de Estudos Experimentais estendido (adaptado de (MAFRA, et al.,
2006)) ........................................................................................................................................................... 8 Figura 2 - Organização da estrutura conceitual do eSEE (adaptada de (MIAN, 2006)) ............................. 11 Figura 3 - Arquitetura eSEE com seus macro-componentes (adaptada de (LOPES & TRAVASSOS,
2009)) ......................................................................................................................................................... 11 Figura 4 - Repositório de Conhecimento (adaptada de (LOPES & TRAVASSOS, 2008)) ....................... 12 Figura 5 - Glossário de Termos do eSEE (extraída de http://ese.cos.ufrj.br/wikiese) ................................ 13 Figura 6 - Ontologia de Pesquisa Científica (adaptada de (LOPES & TRAVASSOS, 2009)) ................... 14 Figura 7 – Sub ontologia de Estrutura do Estudo (adaptada de (BIOLCHINI et al., 2007)) ...................... 15 Figura 8 – Sub ontologia de Procedimento Metodológico (adaptada de (BIOLCHINI et al., 2007)) ........ 15 Figura 9 – Sub ontologia de Qualidade do Estudo (adaptada de (BIOLCHINI et al., 2007)) .................... 15 Figura 10 - Mapeamento de conceitos nas linguagens LINGO e OWL (extraída de LOPES (2010)) ....... 17 Figura 11 - Interface Web da ferramenta eSPA (extraída de LOPES (2010)) ............................................ 17 Figura 12 - Sub ontologia de Estratégia do Estudo (extraída de LOPES (2010))....................................... 18 Figura 13 - Escolha da Estratégia de Estudo (extraída de LOPES (2010)) ................................................ 18 Figura 14 - Template de Protocolo de Estudo Primário (extraída de LOPES (2010)) ............................... 19 Figura 15 – Processo de condução de revisão sistemática (adaptada de (BIOLCHINI et al., 2005)) ........ 23 Figura 16 - Template de Protocolo de Revisão Sistemática (extraída de (BIOLCHINI et al., 2005)) ....... 23 Figura 17 - Modelo para extração de Dados (adaptada de (STAPLES & NIAZI, 2007)) .......................... 26 Figura 18 - Adição de novos campos na ferramenta JabRef ...................................................................... 33 Figura 19 - Interface da ferramenta Zotero................................................................................................. 34 Figura 20 - Funcionalidade timeline e notas de uma referência ................................................................. 34 Figura 21 - Análise estatística realizada pela ferramenta Mendeley .......................................................... 35 Figura 22 - Workflow de técnicas de text mining no contexto da revisão sistemática (adaptada de
(ANANIADOU et al., 2009)) ..................................................................................................................... 36 Figura 23 - Visualização de artigos incluídos e excluídos e, sob critérios de qualidade (extraída de
(FELIZARDO et al., 2009)) ....................................................................................................................... 37 Figura 24 - Rede de relacionamento entre artigos (extraída de (FELIZARDO et al., 2009)) .................... 38 Figura 25 - Funcionalidade de apoio à etapa execução oferecida pela ferramenta SLRTool (extraída de
(FERNÁNDEZ-SÁEZ et al., 2010)) .......................................................................................................... 39 Figura 26 – Resultados da classificação dos estudos considerados pela revisão (extraída de
(FERNÁNDEZ-SÁEZ et al., 2010)) .......................................................................................................... 39 Figura 27 – Interface gráfica da StArt (extraída de (ZAMBONI et al., 2010)) .......................................... 41 Figura 28 - Criação do protocolo/relatório de revisão sistemática ............................................................. 42 Figura 29 - Interface da ferramenta RevMan ............................................................................................. 42 Figura 30 - Identificação de modificações importantes no protocolo de revisão sistemática ..................... 43 Figura 31 - Organização das atividades da Methontology (adaptada de (FERNÁNDEZ et al., 1997)) ..... 46 Figura 32 – Primeiro nível da hierarquia da Ontologia de Estudos Secundários........................................ 48 Figura 33 – Sub ontologia de Estrutura do Estudo ..................................................................................... 48 Figura 34 – Sub ontologia de Qualidade do Estudo ................................................................................... 49 Figura 35 – Sub ontologia de Procedimento Metodológico ....................................................................... 50 Figura 36 - Sub ontologia Protocolo de Revisão Sistemática ..................................................................... 50 Figura 37 - Sub ontologia Questão de Pesquisa ......................................................................................... 51 Figura 38 - Sub ontologia Fontes de Estudos ............................................................................................. 52 Figura 39 - Sub ontologia Estudos Selecionados ....................................................................................... 53 Figura 40 - Sub ontologia Dados Extraídos ................................................................................................ 54 Figura 41 - Sub ontologia Dados Sumarizados .......................................................................................... 54 Figura 42 - Guia de Apoio ao Processo de Condução de Revisões Sistemáticas ....................................... 57 Figura 43 - Sub atividade Selecionar Pesquisadores .................................................................................. 58 Figura 44 - Sub atividade Reunir com Pesquisadores ................................................................................ 58 Figura 45 - Sub atividade Atribuir Atividade aos Pesquisadores ............................................................... 58 Figura 46 - Sub atividade Preencher Protocolo .......................................................................................... 59 Figura 47 - Sub atividade Preencher Dados Relacionados à Seleção de Fontes de Estudos ...................... 60 Figura 48 - Sub atividade Preencher Dados relacionados a Sumarização dos Resultados ......................... 62 Figura 49 - Sub atividade Avaliar Protocolo .............................................................................................. 62
xi
Figura 50 - Comparação de modelos antes e após a inspeção da ontologia ............................................... 67 Figura 51 - Comparação entre versões do guia antes e depois da inspeção ................................................ 68 Figura 52 - Comparação de versões da sub ontologia Estudos Selecionados ............................................. 70 Figura 53 - Estrutura Conceitual eSEE ....................................................................................................... 74 Figura 54 - Componentes de Apoio ao Processo de Condução de Revisões Sistemáticas ......................... 74 Figura 55 - Versão estendida do repositório de conhecimento ................................................................... 75 Figura 56 - Mecanismo de integração entre Joomla/Projectfork e SSPlan ................................................. 82 Figura 57 - Uso do JBPM para apoiar a geração do plano da revisão sistemática ..................................... 83 Figura 58 - Estrutura interna da SSPlan ..................................................................................................... 84 Figura 59 - Listagem de tarefas executadas na SSPlan .............................................................................. 84 Figura 60 - Listagem de tarefas associadas ao perfil de um pesquisador ................................................... 84 Figura 61 - Preenchimento de conceitos da Ontologia de Estudos Secundários ........................................ 85 Figura 62 - Tarefa que representa uma tomada de decisão ......................................................................... 85 Figura 63 - Diagrama jPDL do processo de preenchimento do protocolo de RSL ..................................... 86 Figura 64 - Preenchimento da estrutura PICO ............................................................................................ 87 Figura 65 - Prenchimento da estrutura Population ..................................................................................... 87 Figura 66 - Preenchimento da string de busca ............................................................................................ 88 Figura 67 - Download dos artefatos da revisão na SSPlan ......................................................................... 88 Figura 68 - Listagem de estudos executados na SSPlan ............................................................................. 88 Figura 69 - Uso do paradigma GQM para avaliação de tecnologia ............................................................ 91 Figura 70 - Formulário de avaliação da SSPlan ......................................................................................... 94 Figura 71 - Funcionalidade de edição de tarefas e informações sobre as seções do protocolo................... 97 Figura 72 - Tela de informações para preenchimento de seções do protocolo de RSL .............................. 97 Figura 73 - Ciclo de vida da Methontology (adaptada de (CORCHO et al., 2003)) ................................ 112 Figura 74 - Representação visual da linguagem LINGO (adaptada de (FERNÁNDEZ et al., 1997)) ..... 113 Figura 75 - Taxonomia da OntoUML (adaptada de (GUIZZARDI, 2005)) ............................................. 114 Figura 76 - Arquitetura do CMS Joomla (adaptado de (JOOMLA, 2011)) .............................................. 116 Figura 77 - Tela inicial do CMS Joomla com o componente Projectfork ................................................ 117 Figura 78 - Criação de grupos e usuários no Projectfork ......................................................................... 118 Figura 79 - Criação de um projeto no Projectfork .................................................................................... 119 Figura 80 - Criação de uma tarefa em um projeto .................................................................................... 120 Figura 81 - Ordenação de tarefas no Projectfork ...................................................................................... 120 Figura 82 - Relacionamento entre tecnologias presentes no framework Seam (adaptada de (ALLEN,
2009)) ....................................................................................................................................................... 121 Figura 83 - Editor gráfico de processos .................................................................................................... 123 Figura 84 - Linguagem jPDL para representação de processos ................................................................ 124
xii
Índice de Tabelas
Tabela 1 - Heurísticas de conversão de LINGO para OWL (adaptada de LOPES (2010)) ........................ 16 Tabela 2 - Níveis de apoio oferecidos pelas ferramentas investigadas quanto às etapas da RSL ............... 44 Tabela 3 - Distribuição dos artefatos entre as equipes ................................................................................ 65 Tabela 4 - Discrepâncias e defeitos identificados na Ontologia de Estudos Secundários .......................... 65 Tabela 5 - Discrepâncias e defeitos identificados no guia de apoio ao PCRSL ......................................... 65 Tabela 6 - Distribuição dos defeitos na ontologia ...................................................................................... 67 Tabela 7 - Distribuição dos defeitos no guia de apoio ao PCRSL .............................................................. 68 Tabela 8 - Modelo de interpretação do método Fleiss Kappa .................................................................... 76 Tabela 9 - Distribuição de discrepâncias e defeitos relativas ao documento de requisitos ......................... 78 Tabela 10 - Distribuição de defeitos no documento de requisitos por componente ................................... 78 Tabela 11 - Requisitos para o componente de planejamento ...................................................................... 78 Tabela 12 - Requisitos para construção do componente de execução ........................................................ 80 Tabela 13- Objetivo G1 .............................................................................................................................. 91 Tabela 14 - Objetivo G2 ............................................................................................................................. 91 Tabela 15 - Questões para avaliação da SSPlan ......................................................................................... 92 Tabela 16 - Ordenação decrescente das respostas possíveis para as questões do estudo ............................ 92 Tabela 17 - Métricas para avaliação da SSPlan .......................................................................................... 92 Tabela 18 - Configuração do valor atribuído a cada questão do modelo GQM ......................................... 93 Tabela 19 - Modelo de interpretação da facilidade de uso da SSPlan ........................................................ 93 Tabela 20 - Modelo de interpretação da utilidade da SSPlan ..................................................................... 93 Tabela 21 - Organização dos participantes do estudo ................................................................................. 94 Tabela 22 - Quantitativo de respostas fornecidas pelos pesquisadores ...................................................... 95 Tabela 23 - Percentual de respotas para cada pergunta do estudo de avaliação da SSPlan ........................ 95 Tabela 24 - Classificação das limitações identificadas na SSPlan ............................................................. 96 Tabela 25 - Nova configuração de níveis de apoio às etapas da RSL ...................................................... 100 Tabela 26 - Estruturas oferecidas pelo do framework jBPM (adpatada de (SALATINO, 2009)) ............ 124
1
1 Introdução
Neste capítulo apresentamos o contexto do trabalho, o que motivou
esta pesquisa e a questão de investigação. São também
apresentados os objetivos, a metodologia de pesquisa adotada e a
organização deste texto.
1.1 Motivação
Em Engenharia de Software (ES), experimentação visa desenvolver uma base de
evidência para compreensão e intervenção científica nos processos envolvidos no
desenvolvimento de tecnologias de software (TRAVASSOS, et al., 2008). A partir de
estudos experimentais, é possível gerar evidências que permitam caracterizar, avaliar,
prever, controlar e melhorar produtos, processos e teorias, entre outros. Com isto, a ES
pode se beneficiar do uso de experimentação visando à melhoria contínua de seus
processos.
O processo de execução de pesquisas com base em experimentação é apoiado
pelo uso de diferentes tipos de estudos. Estes estudos visam descobrir algo
desconhecido ou colocar à prova algo conhecido e podem ser classificados em estudos
primários, secundários e terciários. Os estudos primários são aqueles direcionados pelas
hipóteses as quais se deseja verificar ou inferir. Estes são conduzidos quando há a
necessidade de caracterizar uma determinada tecnologia em uso dentro de um contexto
específico. Segundo WÖHLIN et al. (2000) os estudos primários podem ser
classificados em três categorias: estudos de caso, survey e experimento. Recentemente,
novas estratégias vêm sendo acrescentadas, tais como pesquisa-ação (SANTOS &
TRAVASSOS, 2008) e estudo de observação (ROBINSON et al., 2007). Em relação
aos estudos secundários, seu objetivo é integrar os resultados provenientes de diversos
estudos primários correlatos. É importante observar que a execução de um estudo
secundário depende do resultado de estudos primários executados anteriormente.
Citando um exemplo de estudo secundário, (KITCHENHAM et al., 2007) revisaram
evidências sobre a utilização de modelos de estimativa de custos de projeto, de modo
que concluíram que é necessário determinar se, ou sobre que circunstâncias, os modelos
2
de estimativa de custos derivados de repositórios de dados podem apoiar as estimativas
para uma companhia específica. Já os estudos terciários representam a agregação ou
síntese de estudos secundários, podendo aqui assumir a mesma estratégia de
investigação dos estudos secundários (KITCHENHAM et al., 2009).
Este trabalho de pesquisa se relaciona com estudos secundários, particularmente
com a estratégia de revisão sistemática da literatura, de modo que esta abordagem de
pesquisa representa geralmente uma das primeiras atividades a ser executada em um
processo de pesquisa. A execução de uma revisão é importante, por exemplo, para o
mapeamento do conhecimento prévio adquirido sobre a pesquisa em questão. No
entanto, as revisões da literatura são comumente conduzidas de forma ad-hoc, sem um
protocolo pré-estabelecido, o que faz com que estas revisões sejam pouco abrangentes
(fontes importantes de estudos podem ser omitidas), não passíveis de repetição e
dependentes dos indivíduos que a conduziram, aumentando possivelmente o viés em
seus resultados (MAFRA & TRAVASSOS, 2006). Com o intuito de amenizar estes
problemas, a revisão sistemática da literatura consiste de uma abordagem de pesquisa
científica que vai além de uma revisão tradicional. Sua eficácia está no fato de ser uma
abordagem rigorosa, confiável e passível de auditagem (KITCHENHAM, 2004), já que
uma revisão sistemática deve possuir um protocolo, o que permite que a revisão possa
ser repetida e auditada por outros pesquisadores.
A carência de aplicação do método científico, no que se refere à revisão da
literatura, não é uma constatação exclusiva da área de Engenharia de Software (ES). No
final da década de 80, estudos conduzidos para avaliar a qualidade das publicações
médicas chamaram a atenção para o baixo nível de qualidade das revisões
convencionais (COCHRANE, 2011a). As primeiras iniciativas para a definição de uma
abordagem para condução de revisões da literatura ocorreram a partir da década de 70.
No trabalho elaborado por FELDMAN (1971), atividades para revisão da literatura são
descritas, enquanto que em LIGHT & SMITH (1971), uma abordagem de variações em
resultados de estudos primários foi desenvolvida. Além disso, psicólogos e cientistas
sociais tiveram suas atenções voltadas para a criação de diretrizes que minimizassem os
viéses e erros de futuras revisões da literatura.
Uma revisão sistemática da literatura é mais abrangente que uma revisão
tradicional, pois permite que dados coletados possam ser mais bem analisados com o
objetivo de gerar evidências. Além disto, a execução de revisões sistemáticas permite
3
um mapeamento de conceitos relacionados a um determinado tópico de pesquisa. Desta
forma, a partir da integração de resultados de estudos primários, é possível identificar
lacunas de conhecimento e direcionar novos esforços em pesquisas nos temas de
interesse da investigação. Consequentemente, a condução de revisões sistemáticas
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 análise de
inconsistências encontradas ao comparar estudos individuais com resultados
contrastantes entre si (MAFRA & TRAVASSOS, 2006).
O emprego de revisões sistemáticas na ES pode beneficiar diferentes
stakeholders. Devido ao alto nível de abrangência dos estudos primários obtidos a partir
da condução de uma revisão sistemática, pesquisadores podem identificar oportunidades
de pesquisa a serem investigadas. Além disto, o fato do protocolo de revisão sistemática
ser elaborado a partir de uma questão de pesquisa bem definida, auxilia o pesquisador a
manter o foco na pesquisa, evitando eventuais desvios ocasionados pela leitura de
artigos não relacionados ao escopo da investigação. Em relação à comunidade
acadêmica, a condução de revisões sistemáticas possibilita a contínua caracterização
experimental de diversas tecnologias em uso. Com isso, é possível gerar evidências
sobre a viabilidade, eficácia e eficiência de produtos ou processos. Por fim, a indústria
de software pode se utilizar dos resultados de revisões sistemáticas para apoiar a tomada
de decisões referentes a aquisição de tecnologias. Exemplos de aplicação de revisões
sistemáticas da literatura na área de ES podem ser encontrados em (SILVA et al., 2011).
1.2 Problema
Apesar da aplicação de estudos com base em revisão sistemática na ES ter
aumentado ao longo destes anos (SILVA et al., 2011), existem algumas questões que
necessitam ser tratadas visando à melhoria de sua aplicação. Dentre estas, cita-se o
tempo e esforço necessários para condução de uma revisão, principalmente quando
executada por pesquisadores menos experientes. Em (BABAR & ZHANG, 2009)
realizou-se um estudo cujo objetivo era capturar opiniões sobre a condução de revisões
sistemáticas por parte de pesquisadores em ES e identificar oportunidades de melhoria
para sua condução. Dentre os maiores desafios identificados, nota-se que há uma
preocupação com a elaboração do protocolo, principalmente em aspectos relacionados a
formulação de questões de pesquisa.
4
Outra questão está relacionada a diferenças entre bases de dados eletrônicas de
artigos científicos. Cada base possui diferentes linguagens e algoritmos para realização
de consultas ao conjunto de documentos indexados, o que demanda a elaboração e
aplicação de diferentes estratégias de busca (DIESTE & PADUA, 2007). Além disso, a
o reporte de resultados de estudos primários no contexto da ES tende a ser de baixa
qualidade, o que pode comprometer a extração de evidências destes estudos. Por fim, há
uma carência de bases de dados que armazenem resultados provenientes de condução de
revisões sistemáticas. Antes de conduzir uma revisão sistemática, deve-se buscar por
revisões conduzidas anteriormente relacionadas ao tema de pesquisa. Diferentemente da
área médica, a ES não possui uma infra-estrutura satisfatória que apóie a busca por
revisões sistemáticas executadas anteriormente. Conforme mencionado anteriormente, a
revisão sistemática da literatura é de grande auxílio para pesquisadores que desejam
realizar uma revisão da literatura com foco de pesquisa bem definido. No entanto, caso
haja necessidade de realizar uma revisão em curto prazo de tempo, pode não ser viável a
condução de uma revisão sistemática da literatura.
1.3 Objetivo
O objetivo deste trabalho é investigar, projetar, construir e avaliar um conjunto
de serviços que apóiem o Processo de Condução de Revisões Sistemáticas da Literatura
(PCRSL), visando guiar pesquisadores com pouca experiência nessa abordagem a
elaborar o protocolo de estudo secundário. Este trabalho possui ainda um segundo
objetivo, que aponta na agregação de conhecimento sobre revisões sistemáticas em um
repositório de conhecimento em experimentação em ES. Além de servir como fonte de
consulta, as estruturas de conhecimento presentes no repositório são empregadas como
insumos para a construção dos serviços de apoio ao PCRSL. Assim, espera-se amenizar
as dificuldades ligadas ao planejamento e execução de RSL.
1.4 Contexto
Este trabalho se encontra no contexto do eSEE (experimental Software
Engineering Enviroment) (TRAVASSOS et al., 2008), um ambiente de apoio a
experimentação (larga escala) em ES que vem sendo desenvolvido pelo grupo de
Engenharia de Software Experimental (ESE) da COPPE/UFRJ
(http://ese.cos.ufrj.br/ese). O eSEE provê facilidades para a instanciação de ambientes
de apoio às atividades de definição, planejamento, execução e empacotamento de
5
estudos em ES. Maiores detalhes da arquitetura do eSEE são apresentadas no Capítulo
2.
1.5 Metodologia
A metodologia adotada neste trabalho considerou a realização de uma revisão
informal da literatura visando identificar trabalhos que abordassem o uso de revisões
sistemáticas, sem restrições quanto às áreas de pesquisa. Tal revisão permitiu encontrar
dois grandes grupos de trabalhos, aqueles direcionados a identificar dificuldades e
questões que devem ser tratadas a fim de melhorar a aplicabilidade de revisões
sistemáticas e aqueles que propõem tecnologias visando facilitar a adoção deste tipo de
revisão. A justificativa para condução de uma revisão informal da literatura se deu pelo
prévio conhecimento a respeito do baixo número de tecnologias que apoiasse de alguma
forma a aplicação de revisões sistemáticas. Paralelamente, identificou-se a oportunidade
de evoluir o repositório de conhecimento sobre experimentação em ES do ambiente
eSEE por meio da elaboração de uma ontologia de estudos secundários. A construção
dos novos modelos baseou-se na metodologia utilizada para a construção da primeira
versão do repositório de conhecimento (LOPES & TRAVASSOS, 2009). Após a
construção dos novos modelos a respeito de estudos secundários, estes foram
inspecionados com o intuito de garantir maiores níveis de corretude e completude. Após
a investigação dos trabalhos relacionados a revisões sistemáticas e evolução do
repositório de conhecimento, foi proposta uma arquitetura e um conjunto de requisitos
para a construção de uma ferramenta que utilizasse as estruturas para representação de
conhecimento como insumos para prover serviços de apoio ao planejamento, execução e
empacotamento de revisões sistemáticas da literatura. Tendo os requisitos sido
inspecionados e a arquitetura discutida com o grupo de Engenharia de Software
Experimental da COPPE/UFRJ, partiu-se para a construção dos serviços que apoiassem
o planejamento de RSL. Por fim, fez-se um estudo de avaliação das funcionalidades
construídas que permitiu que a ferramenta construída fosse evoluída.
1.6 Organização
Além deste capítulo de introdução, este trabalho possui mais seis capítulos. No
Capítulo 2 é apresentado o ambiente de experimentação eSEE e seu repositório de
conhecimento sobre experimentação em ES, constituído por um glossário de termos e
6
uma ontologia de pesquisa científica. No Capítulo 3, é feita uma revisão da bibliográfica
a respeito do emprego de RSL. Este capítulo apresenta ainda uma análise sobre
dificuldades encontradas na aplicabilidade deste tipo de revisão bem como são
apresentados trabalhos que visam propor soluções para facilitar a condução do PCRSL.
O Capítulo 4 aborda e expansão do repositório de conhecimento, de maneira a
contemplar conhecimentos sobre estudos secundários. Neste capítulo, é feita ainda uma
avaliação da contribuição oferecida pela expansão do repositório. O Capítulo 5
apresenta a abordagem para construção de uma ferramenta de apoio ao PCRSL. Em
seguida, o Capítulo 6 apresenta os resultados obtidos com a execução de um estudo que
buscou avaliar a ferramenta construída quanto à utilidade e facilidade de uso. Por fim, o
Capítulo 7 apresenta as contribuições obtidas com a execução deste trabalho e discute
sobre as limitações existentes e perspectiva de trabalhos futuros.
7
2 Introdução ao Ambiente de Apoio à
Experimentação eSEE
Neste capítulo, é apresentado o ambiente de apoio à
experimentação denominado eSEE e suas estruturas para
representação de conhecimento.
2.1 Introdução
Um experimento deve ser tratado como um processo da formulação ou
verificação de uma teoria. A fim de que o processo ofereça os resultados válidos, ele
deve ser propriamente organizado e controlado ou, pelo menos, acompanhado
(TRAVASSOS et al., 2002). Assim, o processo de execução de estudos experimentais
em ES, originalmente apresentado por WÖHLIN et al. (2000) e estendido por
AMARAL (2003), é composto por cinco etapas: definição, planejamento, execução,
análise e interpretação, e empacotamento. A modificação do processo original foi feita
de forma que a etapa empacotamento seja conduzida paralelamente ao processo de
experimentação. A etapa definição expressa o estudo em termos dos problemas e
objetivos, visando definir o projeto do estudo, a instrumentação a ser utilizada e as
formas de analisar e validar os resultados obtidos. Na etapa planejamento, o plano do
estudo é definido. Este plano deve conter as atividades a serem realizadas, com o intuito
de minimizar a probabilidade de ocorrência dos possíveis riscos do estudo durante a
etapa execução. Uma vez que o plano do estudo esteja pronto, o estudo é executado e os
resultados obtidos são analisados e avaliados na etapa análise e interpretação,
utilizando os métodos definidos na etapa anterior. Para que o processo tenha maiores
chances de êxito, é importante que os indivíduos não afetados pelo estudo possam
participar, realizando revisões nos produtos de trabalho produzidos em cada etapa. Caso
algum tipo de problema seja identificado, volta-se à etapa anterior a fim de corrigir os
defeitos existentes. A Figura 1 exibe o processo de execução de estudos experimentais.
8
Figura 1 - Processo de Execução de Estudos Experimentais estendido (adaptado de (MAFRA, et al.,
2006))
Executar um estudo requer uma série de cuidados, em especial a necessidade de
um rigoroso planejamento considerando amplamente os detalhes de escolha das
estratégias de estudo, ou como também são denominados os diferentes métodos
experimentais aplicáveis. A condução de estratégias de estudo demanda que diferentes
questões de arranjo sejam consideradas, sendo todas específicas da estratégia escolhida.
A não-observância dos principais detalhes pertinentes a uma dada estratégia pode
introduzir ameaças à validade do estudo. A solução para esse desafio, a princípio,
requer: (1) explicitar o conhecimento sobre as diferentes estratégias de estudo e (2)
disponibilizar adequadamente o conhecimento ao pesquisador, de modo a apoiar as
diferentes tomadas de decisão comuns a essa atividade de planejamento.
Com o objetivo de atender os desafios citados anteriormente, o ambiente eSEE
(experimental Software Engineering Environment) (TRAVASSOS et al., 2008),
desenvolvido pelo grupo ESE (Experimental Software Engineering) da COPPE/UFRJ,
visa ampliar as possibilidades de uso e apoio efetivo da experimentação em Engenharia
de Software (ES). Assim, este capítulo tem por objetivo apresentar o referido ambiente,
tendo como foco as suas estruturas para representação de conhecimento. Para isto, a
Seção 2.2 apresenta a arquitetura conceitual do ambiente, enquanto que, na Seção 2.3,
são apresentadas as estruturas que o ambiente utiliza para representação do
conhecimento a respeito de experimentação em ES. Por fim, a Seção 2.4 apresenta a
conclusão do capítulo.
2.2 eSEE: experimental Software Engineering Enviroment
O ambiente eSEE fornece apoio à definição de meta-modelos de processo de
experimentação, que podem ser configurados pelo pesquisador a fim de acrescentar ou
9
remover atividades e ferramentas conforme as necessidades do estudo em questão e, a
organização de uma infra-estrutura conceitual que fornece ao pesquisador subsídios para
planejar, executar e empacotar um estudo em ES conforme suas reais necessidades. Os
requisitos do eSEE foram identificados a partir dos trabalhos de DIAS NETO et al.
(2004), CHAPETTA et al. (2004) e CHAPETTA (2006). A partir dos requisitos
identificados, a estrutura conceitual do eSEE foi organizada em três camadas, conforme
exibe a Figura 2:
Meta-eSEE: o meta-nível do ambiente contém o conhecimento geral sobre
experimentação, incluindo conhecimento sobre ES. Neste nível, estão definidos
um processo de experimentação padrão, modelos de documentos e serviços;
eSEE Configurado: no nível de configuração de experimentos, encontra-se o
conhecimento sobre os tipos específicos (TRAVASSOS & BARROS, 2003).
Nesse nível, é realizada a instanciação dos ambientes de experimentação
específicos. No momento da instanciação, deve-se definir qual tipo de estudo
experimental se necessita executar. O ambiente instanciado, então, é gerado com
o conhecimento específico a este tipo de estudo;
eSEE: ambiente de apoio à definição, planejamento e execução de estudos
experimentais. A cada novo estudo, um eSEE deve ser instanciado para
gerenciar aquele estudo experimental específico.
Adicionalmente, DIAS NETO et al. (2004) propôs uma arquitetura inicial para o
eSEE, composta por três macro componentes. A arquitetura proposta permite que seus
macro componentes possam existir de forma independente e estar distribuídos
geograficamente. Posteriormente, a arquitetura foi evoluída por SANTOS (2007), de
modo a incluir o componente de Mapeamento de Associações, responsável por integrar
o Repositório de Modelo de Processos, o Repositório de Modelo Processos e o
Repositório de Serviços Configurados. Em seguida, SOUZA (2007) evoluiu novamente
o ambiente ao adicionar o Componente de Configuração de Processos. O
relacionamento entre os macro componentes do eSEE é exibido na Figura 3:
Meta-Configurador: define e configura meta elementos que serão usados em
outros níveis. É composto pelos seguintes meta-elementos:
o Modelo de Documento: são descrições que servem como base
instanciação de artefatos produzidos ao longo do Processo de
Experimentação. O Meta-Configurador descreve modelos de documentos
10
a partir dos modelos de documentos estabelecidos em (AMARAL, 2003)
e que constituem a estrutura da base de conhecimento do eSEE;
o Modelo de Processo: serve como base para a definição e instanciação de
Processos de Experimentação. O Meta-Configurador descreve modelos
de processos de software configuráveis a partir de um meta-modelo de
processos pré-estabelecido. Entende-se como sendo um modelo
configurável de processo aquele que possui:
Alguma atividade opcional, ou;
Alguma atividade que não faz parte do processo padrão, ou;
Alguma ferramenta opcional, ou;
Algum papel opcional, ou;
Alguma pergunta.
o Serviço Configurado: são informações relativas à utilização de serviços
Web que possam apoiar diferentes atividades do Processo de
Experimentação. Esses serviços Web, ou simplesmente serviços,
disponibilizados têm de ser capazes de ter seus usos customizados para
serem disponibilizados na infra estrutura do eSEE.
Ambiente de Instanciação: provê funcionalidades para a instanciação de um
ambiente que permita o acompanhamento e execução de estudos experimentais,
baseados nos modelos de documento e processo (definidos pelo Meta-
Configurador) e no mapeamento das associação (definido neste componente)
entre modelo de documento, processo e serviço configurado;
Ambiente de Execução: provê facilidades para monitorar as atividades
relacionadas ao planejamento e execução de um estudo experimental. Este
monitoramento é realizado através do processo definido, respeitando o controle
de acesso à informação e às atividades do processo.
11
Figura 2 - Organização da estrutura conceitual do eSEE (adaptada de (MIAN, 2006))
Figura 3 - Arquitetura eSEE com seus macro-componentes (adaptada de (LOPES & TRAVASSOS,
2009))
2.3 Repositório de Conhecimento em Engenharia de Software Experimental
Para que o conhecimento relacionado ao domínio de Experimentação em ES
possa ser melhor explorado, é importante que os conceitos ligados ao domínio possam
ter suas definições, restrições e relacionamentos semânticos definidos armazenados em
um repositório de conhecimento de experimentação em ES. A organização deste
conhecimento foi concebida inicialmente no trabalho proposto por (LOPES &
TRAVASSOS, 2008) em uma estrutura que contém dois mecanismos de representação
12
do conhecimento (conforme exibe a Figura 4): glossário de termos (dicionário) e
modelos conceituais (ontologias), ambos pertencentes à camada Meta-eSEE.
Figura 4 - Repositório de Conhecimento (adaptada de (LOPES & TRAVASSOS, 2008))
2.3.1 Glossário de Termos
O Glossário de Termos é uma estrutura organizada através de uma ferramenta
Web do tipo Wiki que possui a definição de termos ligados a ESE nos idiomas inglês,
português e espanhol, além de referência de apoio (disponível em
http://ese.cos.ufrj.br/wikiese). Sua construção se deu a partir da reunião de
pesquisadores da comunidade ISERN (International Software Engineering Research
Network) e de edições do evento ESELAW (Experimental Software Engineering Latin
American Workshop). Com a construção do eSEE e a necessidade de um repositório de
conhecimento, o glossário passou a ser utilizado também como um mecanismo de
representação de conhecimento dentro deste repositório.
Ao acessar o glossário de termos, o pesquisador visualiza uma lista de termos
em ordem alfabética, cuja navegação se dá pelo uso de hiperlinks ou por meio do uso de
um hipergrafo. Ao acessar o link (ou nó do hipergrafo) correspondente a um
determinado conceito, o pesquisador é redirecionado para a página (Figura 5) que
possui a definição do conceito nos idiomas inglês, português e espanhol, e a lista de
referências para maiores detalhes sobre o conceito.
13
Figura 5 - Glossário de Termos do eSEE (extraída de http://ese.cos.ufrj.br/wikiese)
2.3.2 Modelos Conceituais (Ontologias)
Apesar do glossário de termos explicitar a definição dos termos ligados ao
domínio de Experimentação em ES, este não representa os relacionamentos e restrições
existentes entre os termos. Assim, o emprego de modelos conceituais (ontologias) pode
superar esta deficiência. Dentre as vantagens do advento de ontologias estão: (i) ex-
plicitação do conhecimento existente sobre um determinado domínio; (ii) definição de
um vocabulário comum entre aqueles que desejam compartilhar informações; (iii)
possibilidade de realizar inferências sob conceitos que compõe o domínio; e (iv)
reutilização de conhecimento (NOY & MCGUINNESS, 2001). No Apêndice I, é feita
uma introdução sobre o uso de ontologias, de modo que possa haver um melhor
entendimento a respeito dos termos e metodologias utilizadas no escopo desta
dissertação.
LOPES (2010) propõe uma Ontologia de Pesquisa Científica, que engloba
conceitos gerais sobre experimentação, contemplando as abordagens de pesquisa e
método científico (Figura 6). Para facilitar o entendimento dos modelos, o eSEE adota a
linguagem gráfica LINGO (FALBO et al., 1998) e organiza a Ontologia de Pesquisa
14
Científica através de sub ontologias. Desta forma, o modelo representado pela Figura 6
é especializado em sub ontologias. Dentre as sub ontologias presentes, podemos citar
(destacadas por meio de retângulos): (i) Sub ontologia de Estratégia de Estudo – define
uma classificação taxonômica para estudos primários; (ii) Sub ontologia de Método de
Pesquisa – define o conhecimento sobre os métodos de pesquisa quantitativo,
qualitativo e semi-quantitativo; e (iii) Sub ontologia de Tipo de Estudo – define os
conceitos relacionados a estudos in-vivo, in-vitro, in-virtuo e in-silico (TRAVASSOS
& BARROS, 2003). No entanto, a Ontologia de Pesquisa Científica não explora a fundo
conceitos relacionados a estudos secundários, notadamente do tipo Revisão Sistemática
da Literatura.
Figura 6 - Ontologia de Pesquisa Científica (adaptada de (LOPES & TRAVASSOS, 2009))
BIOLCHINI et al. (2007) propõem modelos ontológicos para representação de
conceitos referentes ao Processo de Condução de Revisões Sistemáticas. Devido à
íntima relação entre estudos primários e secundários, estruturas para representação de
estudos primários também são apresentadas. Os conceitos relacionados a estudos
primários presentes em BIOLCHINI et al. (2007) também são contemplados em
LOPES (2010). Já em relação a estudos secundários, são representados conceitos
ligados a estrutura do estudo, procedimento metodológico e qualidade do estudo.
Cada um destes conceitos é então especializado através de sub ontologias, conforme
exibem as Figuras 7, 8 e 9. No entanto, tais sub ontologias não são especializadas, o que
dificulta a criação de mecanismos de apoio à tomada de decisão.
15
Figura 7 – Sub ontologia de Estrutura do Estudo (adaptada de (BIOLCHINI et al., 2007))
Figura 8 – Sub ontologia de Procedimento Metodológico (adaptada de (BIOLCHINI et al., 2007))
Figura 9 – Sub ontologia de Qualidade do Estudo (adaptada de (BIOLCHINI et al., 2007))
2.3.3 experimental Studies Planning Assistant (eSPA)
A partir do Glossário de Termos e dos modelos conceituais, é possível construir
ferramentas inteligentes que consultam os artefatos constituintes do repositório de co-
nhecimento sobre experimentação em Engenharia de Software e ofereçam funcionalida-
des de apoio às atividades de planejamento, execução e empacotamento de estudos.
Visando atender pesquisadores no planejamento de estudos primários, o eSEE possui
uma ferramenta, denominada experimental Studies Planning Assistant (eSPA),
constituinte da camada eSEE Configurado. A ferramenta se caracteriza por recuperar
conhecimento do repositório de conhecimento sobre experimentação, disponibilizando-
o na forma de questões e respostas associadas aos conceitos de estratégias de estudo
e de subdomínios de conhecimento correlatos. Opções de resposta são fornecidas para
cada questão, na qual a ferramenta expõe o significado dos principais conceitos para
16
auxiliar o pesquisador na tomada de decisão sobre a resposta apropriada tendo em vista
as características do estudo que pretende planejar. Além disto, a ferramenta gera um
template para o documento de plano do estudo, com seções específicas e aderentes às
decisões tomadas pelo pesquisador. Esse template é organizado de acordo com as
respostas dadas para cada questão, e servirá de roteiro para o planejamento do estudo
(LOPES & TRAVASSOS, 2010).
Para que o conhecimento representado pelo repositório de conhecimento do
eSEE possa ser utilizado pela eSPA houve a necessidade de converter os modelos
conceituais estruturados na linguagem LINGO para a linguagem OWL (Web Ontology
Language) (W3C, 2011a), uma linguagem que implementa uma fração da lógica de
primeira ordem e, assim, permite que ontologias sejam passíveis de processamento.
Para que isto fosse possível, LOPES (2010) elaborou uma heurística de conversão de
alguns elementos de representação em LINGO para elementos OWL. Nesta heurística,
os principais elementos da notação UML são representados em elementos OWL
específicos, conforme sintetiza a Tabela 1.
Tabela 1 - Heurísticas de conversão de LINGO para OWL (adaptada de LOPES (2010))
Elemento LINGO (UML) Elemento OWL
Classe com esteriótipo “Conceito” e “Documento” Class
Atributo cujo tipo primitivo é string Data Property
Generalização/Especialização entre classes com
estereótipo “Conceito” Hierarquização
Agregação/ Composição entre classes com estereótipo
“Conceito” Object Property
Agregação/Composição entre classes com estereótipo
“Documento” Object Property
Associação Object Property
Atributo de classes com estereótipo “Documento” Object Property
Para a conversão dos modelos originais desenvolvidos na linguagem LINGO
para OWL, adotou-se a ferramenta Protégé (PROTÉGÉ, 2011). Na Figura 10, é possível
observar alguns conceitos modelados nas duas linguagens.
Com base nos conceitos representados em OWL, a ferramenta pode percorrer os
conceitos da ontologia de maneira organizada e por meio de uma interface Web
apresentar questionamentos ao pesquisador acompanhado por um conjunto de opções de
resposta (Figura 11). Com base na resposta fornecida, eSPA continua processando os
demais conceitos da ontologia, de maneira a apresentar novos questionamentos, porém
considerando apenas o sub-conjunto de conceitos pertencentes à hierarquia do conceito
fornecido como resposta ao questionamento imediatamente anterior.
17
Figura 10 - Mapeamento de conceitos nas linguagens LINGO e OWL (extraída de LOPES (2010))
Figura 11 - Interface Web da ferramenta eSPA (extraída de LOPES (2010))
Para facilitar o entendimento do processamento da Ontologia de Pesquisa
Científica pela eSPA, considere o questionamento apresentado pela ferramenta na
Figura 11. Observe que as opções de resposta para o questionamento sobre a abordagem
de pesquisa correspondem a conceitos que herdam de Abordagem de Pesquisa
Científica, conforme ilustra a Figura 10. Ao supor que a opção de resposta escolhida
tenha sido Estudo Primário, será apresentado ao pesquisador um novo questionamento,
de maneira a identificar a estratégia de estudo (representado pelo conceito Estratégia de
Estudo) a ser adotada. Ao processar a sub ontologia de Estratégia de Estudo (Figura
12), eSPA apresenta o questionamento sobre a estratégia e oferece as opções de
respostas possíveis para o questionamento.
18
Figura 12 - Sub ontologia de Estratégia do Estudo (extraída de LOPES (2010))
Ao observar a Figura 13, nota-se que as opções de respostas ao questionamento
sobre estratégia de estudo correspondem a conceitos que herdam do conceito Estratégia
do Estudo (por se tratar ainda de um protótipo, nem todos os conceitos da Ontologia de
Pesquisa Científica foram convertidos da linguagem LINGO para OWL). Supondo que
a resposta fornecida tenha sido Survey, prossegue-se no processamento da ontologia, de
forma a considerar a partir de agora somente aspectos ligados ao planejamento de
Surveys. Ao término dos questionamentos, a ferramenta disponibiliza o template de
protocolo de estudo primário adaptado às respostas fornecidas ao longo do
planejamento, conforme exibe a Figura 14.
Figura 13 - Escolha da Estratégia de Estudo (extraída de LOPES (2010))
19
Figura 14 - Template de Protocolo de Estudo Primário (extraída de LOPES (2010))
2.4 Conclusão
A Engenharia de Software Experimental provê meios pelos quais melhores
evidências provenientes da pesquisa possam ser integradas com experiência prática e
valores humanos no processo de tomada de decisão, considerando o desenvolvimento e
a manutenção do software (LOPES, 2010). Entretanto, executar um estudo
experimental, especialmente em Engenharia de Software, não é trivial, consome tempo
e recursos, gera um grande volume de informação e conhecimento cujo gerenciamento é
complexo (SHULL et al., 2001). Desta forma, o emprego de ambientes de apoio ao
planejamento e execução de atividades em um processo de experimentação, a partir de
uma infra estrutura computadorizada, pode trazer benefícios. Nesse sentido, este
capítulo apresentou a arquitetura do ambiente de experimentação eSEE, que consiste em
uma infra-estrutura capaz de instanciar ambientes para gerenciar o processo de
experimentação em ES. Este ambiente contempla estruturas para representação de
conhecimento acerca de experimentação de estudos primários. Além disso, o ambiente
possui uma ferramenta que auxilia pesquisadores na elaboração de templates de estudos
primários.
Conforme mencionado anteriormente, a Ontologia de Pesquisa Científica até
então não considerava conceitos a respeito de estudos secundários. Com isto, a
ferramenta eSPA, que consulta a ontologia representada na linguagem OWL, não é
capaz de apoiar pesquisadores na elaboração de templates de protocolo de RSL. Tendo
20
isto mente, o primeiro passo para evolução do ambiente eSEE e seu Repositório de
Conhecimento sobre Experimentação do eSEE se dá no sentido de expandir os modelos
de representação de estudos secundários elaborados por BIOLCHINI et al. (2007) e
incluí-los na Ontologia de Pesquisa Científica. Assim, no Capítulo 4, será apresentada a
abordagem utilizada para a evolução do repositório de conhecimento, bem como a
definição dos conceitos que tratam a respeito de estudos secundários. No entanto, para
que possa haver uma melhor compreensão destas definições, no Capítulo 3, é feita uma
introdução sobre revisões sistemáticas da literatura.
21
3 Revisões Sistemáticas da Literatura
Neste capítulo, apresenta-se uma revisão bibliográfica a respeito de
revisões sistemáticas da literatura. Além disto, são apresentados
trabalhos que apontam questões que precisam ser tratadas visando
a melhoria da aplicação desta abordagem na Engenharia de
Software. Por fim, são apresentadas também tecnologias que visam
prover algum tipo de apoio à esta abordagem de pesquisa.
3.1 Processo de Condução de Revisões Sistemáticas da Literatura
O Processo de Condução de Revisões Sistemáticas da Literatura (PCRSL) em
ES, inicialmente proposto por KITCHENHAM (2004), é composto por três etapas:
planejamento, execução e publicação dos resultados. No entanto, sob um ponto de vista
mais operacional, o processo é executado sob cinco etapas iterativas: formulação do
problema, coleta dos dados do estudo, avaliação dos dados coletados, análise e
interpretação dos estudos considerados válidos, conclusão e apresentação dos resultados
do estudo.
A primeira etapa, formulação do problema, possui o objetivo de identificar que
tipo de evidência o estudo deve investigar. Através da formulação do problema, é
possível definir que estudos são relevantes para a investigação em curso. Nesta etapa, é
definido o procedimento metodológico a ser utilizado na revisão, de modo que é
possível escolher entre uma quasi revisão sistemática (que representa um estudo de
caracterização, porém com rigor equivalente de uma revisão sistemática), revisão
sistemática (que considera a comparação de estudos executados anteriormente), meta-
análise (onde a síntese da pesquisa é produzida a partir da aplicação de métodos
estatísticos quantitativos), síntese e agregação. Em seguida, define-se a questão de
pesquisa que guiará o estudo. Uma vez que a questão de pesquisa tenha sido definida,
esta é organizada sob a estrutura PICO (Population, Intervention, Comparison e
Outcome)(PAI et al., 2004), de modo que seja possível traduzir a questão de pesquisa
sob a forma de strings de busca que serão aplicadas às bases de dados de artigos
científicos em busca de trabalhos que descrevam estudos de interesse. O termo
22
population corresponde às pessoas, grupos ou aplicações “afetadas” pela intervenção
(como indivíduos que atuam como inspetores, por exemplo). O termo intervention
corresponde às tecnologias/procedimentos que geram resultados (ex: técnica de
inspeção) enquanto que o termo outcome lista os fatores de interesse que devem ser
observados com a execução do tipo de estudo investigado (como tempo necessário para
identificação de defeitos ou número de defeitos identificados, por exemplo). Por fim, o
termo comparison é utilizado nos casos em que se deseja incluir qualquer tipo de
restrição em tipos de estudos (ex; outro tipo de intervenção) a serem considerados pela
revisão.
Uma vez que o protocolo tenha sido concluído, em uma etapa seguinte,
correspondente à coleta dos dados do estudo, o pesquisador deve seguir os
procedimentos definidos durante o planejamento, ou seja, aplicar as strings de busca
elaboradas nas diferentes bases de dados selecionadas para o estudo. Ressalta-se que a
escolha das bases de dados é feita com base em critérios definidos no planejamento da
revisão e que tais bases podem incluir aquelas que requerem buscas manuais (como
bibliotecas e anais de eventos, por exemplo). Já a terceira etapa tem a preocupação de
avaliar os dados coletados, onde critérios para separar os estudos que podem ser
considerados válidos daqueles considerados inválidos para a pesquisa são aplicados.
Recomenda-se que esta avaliação seja conduzida por mais de um pesquisador, de modo
a confrontar os resultados da avaliação e, assim, diminuir as chances de uma
classificação incorreta dos dados. Além disso, há situações em que se faz necessário
avaliar o grau de qualidade dos estudos considerados válidos com o intuito de
maximizar a validade interna (visando prevenir a ocorrência de inconsistências internas
que comprometam a revisão) e externa (de modo que os resultados sejam aplicáveis fora
do contexto de estudo) da revisão. Em seguida, dos estudos considerados válidos,
extrai-se os dados de interesse para a revisão (definidos anteriormente na etapa
planejamento). A quarta etapa tem por objetivo analisar e interpretar os estudos
considerados válidos. O objetivo desta etapa é definir que procedimentos devem ser
executados a fim de inferir teorias sobre os dados coletados como um todo. Um aspecto
importante desta etapa se deve ao fato de que um estudo pode ser interpretado de
maneira distinta por diferentes pesquisadores. Assim, faz-se necessário (no
planejamento da revisão) definir critérios para resolução de divergência entre
pesquisadores. Por fim, a quinta etapa está relacionada a conclusão e apresentação dos
23
resultados do estudo. Nesta etapa, é importante definir quais informações são
importantes de serem destacadas a fim de representar o conhecimento obtido através da
execução do estudo.
A partir desse processo, BIOLCHINI et al. (2005) organizam a execução de uma
revisão sistemática em fases, conforme ilustra a Figura 15. Neste processo, considera-se
a etapa empacotamento, que deve ser realizada paralelamente às etapas citadas
anteriormente. Nesta etapa, são organizados os artefatos gerados ao longo da condução
do processo, de modo que seja possível entender as decisões tomadas ao longo do
processo e que seja possível re-executar o estudo ou evoluir o protocolo de revisão
sistemática. Além disto, durante a execução da revisão sistemática, é importante que o
protocolo e o conjunto de dados extraídos da condução da revisão sejam avaliados para
diminuir a probabilidade da existência de defeitos. No entanto, embora organizadas
sequencialmente, nada impede que as etapas da revisão sejam executadas de forma
iterativa. Por fim, BIOLCHINI et al. (2005) propõem também um documento template
(Figura 16) para organização do protocolo de RSL.
Figura 15 – Processo de condução de revisão sistemática (adaptada de (BIOLCHINI et al., 2005))
Figura 16 - Template de Protocolo de Revisão Sistemática (extraída de (BIOLCHINI et al., 2005))
24
3.2 Dificuldades e Lições Aprendidas no Contexto de Revisões Sistemáticas
As primeiras iniciativas de emprego de Revisões Sistemáticas da Literatura
(RSL) em ES ocorreram a partir de 2004, incentivados pela elaboração de um guideline
proposto por KITCHENHAM (2004) que adapta a abordagem de pesquisa,
originalmente empregada nas áreas da saúde e ciências sociais, para o contexto da ES.
Desde então, a RSL propiciou melhorias na condução de estudos voltados a
identificação de novas frentes de pesquisas e identificação de limitações em tecnologias
existentes. Entretanto, por se tratar de um assunto relativamente recente no contexto da
ES, é importante que dificuldades e lições aprendidas na condução de RSL sejam
compartilhadas com a comunidade acadêmica para a contínua melhoria da abordagem.
Tendo isto em mente, esta seção procura abordar trabalhos que apontem nesta direção.
3.2.1 Aplicação de Revisões Sistemáticas da Literatura no Contexto de Estudos Qualitativos
DYBÅ et al. (2007) afirmam que boa parte dos guias de apoio a condução de
revisões sistemáticas e meta-análise são voltados para estudos quantitativos. No entanto,
a aplicação deste tipo de estudo é predominantemente menor no contexto da ES. Com
isso, os autores reportam a experiência na condução de uma revisão sistemática
envolvendo diferentes tipos de estudos primários. Neste trabalho, é apontada a
existência de dois tipos de revisões sistemáticas: integrativa – recomendada para síntese
de estudos quantitativos; e interpretativa – recomendada para síntese de estudos
qualitativos. Outro fato constatado está relacionado com a carência de métodos de
avaliação de qualidade e extração de dados de estudos qualitativos. Atualmente, não
existe consenso se os métodos de avaliação de estudos qualitativos devem ser iguais ou
diferentes aos utilizados em estudos quantitativos. A partir desta constatação, os autores
desenvolveram um método de avaliação de qualidade de artigos composto por 11
questões baseado no Critical Appraisal Skills Programme (CASP) (CASP, 2011). O
foco das questões leva em consideração o rigor, credibilidade e relevância das
informações reportadas em estudos primários. Já para interpretação dos dados, foi
utilizada a técnica meta-etnografia (DIXON-WOODS et al., 2005).
Durante a revisão, destacou-se a importância de execuções piloto como
indicador de pontos de melhoria no protocolo, bem como o esforço necessário a
adaptação de strings de busca para as diferentes bases de dados. O processo de
25
avaliação levou em consideração os títulos e resumos de cada artigo. Em uma primeira
fase, artigos foram excluídos com base no título. Na segunda fase, os resumos de cada
artigo foram lidos por dois revisores e um resultado de concordância entre as avaliações
foi atribuído utilizando o coeficiente Kappa (COHEN, 1960). Como forma de apoio,
foram utilizadas as ferramentas EndNote (REUTERS, 2011) e Excel. Para síntese de
dados qualitativos, foi utilizada a ferramenta NVivo (QSR, 2011). Esta síntese se
mostrou de difícil execução, devido a falta de informações presentes nos artigos
avaliados. No reporte dos resultados, é recomendado explicitar tabelas que indiquem o
sumário de revisões sistemáticas realizadas anteriormente, os resultados de avaliações
dos artigos, a organização das informações relacionadas aos estudos primários e os
resultados obtidos com a revisão. Por fim, os autores recomendam a união da
experiência do pesquisador com o conjunto de evidências obtidas através da condução
de uma revisão sistemática.
3.2.2 Emprego de Critérios para Avaliação de Qualidade de Estudos Primários
No trabalho desenvolvido por STAPLES & NIAZI (2007), os autores
compartilham as experiências obtidas na primeira experiência de condução de revisão
sistemática. Mais uma vez, é destacada a importância de elicitar critérios para avaliação
da qualidade dos artigos (possivelmente baseado em checklists para evitar o viés na
avaliação). Além disso, é reconhecida importância da participação de pesquisadores que
atuem como revisores dos produtos de trabalho produzidos. Durante a condução da
revisão, os autores utilizaram o coeficiente Kappa (COHEN, 1960) como índice de
concordância de avaliação dos artigos considerados na revisão. Os autores também
definiram um modelo para extração dos dados dos artigos, conforme exibe a Figura 17.
Após a conclusão da revisão, os seguintes pontos foram destacados: (i) a importância
de armazenamento do tempo gasto nas etapas da revisão, de modo que um timeline da
revisão possa ser construído; (ii) a importância de se conduzir estudos piloto, embora
não haja um consenso de quando a execução-piloto deve ser finalizada; (iii) em alguns
artigos, houve a necessidade de leitura das conclusões devido a baixa qualidade dos
títulos e resumos; e (iv) os autores reconhecem a dificuldade de extração de dados
automatizada, embora a ontologia desenvolvida por (HARS, 2001) seja um primeiro
passo nesta direção.
26
Figura 17 - Modelo para extração de Dados (adaptada de (STAPLES & NIAZI, 2007))
3.2.3 Metodologia para Extração de Dados de Estudos Primários e Reporte dos Resultados
BRERETON et al. (2007) também destacam lições aprendidas através da
condução de revisões sistemáticas. Dentre as lições aprendidas, destaca-se a importância
de anteriormente estudos que envolvam o mesmo tema em pesquisa, a uniformização
dos métodos de investigação e atenção na elaboração da conclusão da revisão. Segundo
os autores, somente a apresentação dos dados extraídos em forma de tabelas não é
suficiente para entendimento da revisão da literatura. Outros pontos de destaque no
estudo realizado apontam para o entendimento de como os critérios de avaliação de
qualidade são úteis para e a etapa de análise dos dados e a importância de definição de
guias de apoio a extração de dados.
3.2.4 Elaboração de Estratégias de Busca para Identificação de Estudos Primários
No trabalho proposto por DIESTE et al. (2009), os autores investigam
estratégias de elaboração de strings de busca. Para efeito de comparação, os autores
definem o termo estratégia ótima, calculado a partir dos valores de precisão e cobertura
(DICKERSIN et al., 1994). O intuito desta estratégia é obter o maior número de
evidências com baixo custo e esforço. No entanto, para poder comparar estratégias de
elaboração de string de busca, os valores de precisão e cobertura devem ser conhecidos
a priori. Assim, para poder obter estes valores, foi considerado o estudo elaborado por
SJØBERG et al. (2005) como baseline de comparação (o estudo abordava a condução
de experimentos no contexto da ES). Durante a execução das estratégias, os autores
identificaram dificuldades na manipulação das máquinas de buscas relacionadas a
limitação de documentos indexados, diferenças nos algoritmos de busca, falha no
reconhecimento de plural e falta de resumos ou artigo completo. O resultado do estudo
apontou uma variação de termos na denominação de experimentos ao longo dos anos.
Para cobrir todos os estudos considerados relevantes, diferentes strings de busca
27
tiveram de ser elaboradas para cada base de dados. Além disso, os autores apontaram
que esforços devem ser empreendidos na melhoria dos títulos e resumos de artigos que
tratem de estudos primários no contexto da ES.
3.2.5 Tempo e Esforço Gasto na Elaboração e Execução de Revisões Sistemáticas da Literatura
Já o trabalho elaborado por BABAR & ZHANG (2009) têm como objetivo a
coleta de informações a respeito de percepções e experiências de pesquisadores na
condução de revisões sistemáticas, a identificação de desafios e melhores práticas para
condução de revisões sistemáticas e avaliação dos guias existentes atualmente. O
processo de investigação se deu a partir de entrevistas (survey) com 17 pesquisadores
com experiência na condução de revisões sistemáticas. O survey foi elaborado com
questões abertas, de forma a capturar o máximo de informação dos pesquisadores
entrevistados. Após a coleta das respostas fornecidas pelos pesquisadores, métodos de
análise qualitativa foram empregados (SEAMAN, 1999).
A análise dos dados indicou que os guias mais influentes para condução de
revisões sistemáticas no contexto da ES foram desenvolvidos por KITCHENHAM
(2004) e KITCHENHAM & CHARTERS (2007). No entanto, guias de outras ciências,
como medicina e ciências sociais, por exemplo, devem ser considerados como fontes de
melhoria para os guias da ES. Em relação a avaliação da qualidade, todos os
pesquisadores apontaram a necessidade de elaboração de guias detalhados que auxiliem
os pesquisadores na processo de avaliação. Quanto às dificuldades ao se conduzir
revisões sistemáticas, as entrevistas indicaram deficiências nos algoritmos de busca das
bases de dados e carência de infra-estrutura responsável por armazenar resultados de
revisões sistemáticas. Entre as melhores práticas identificadas estão a condução de
estudos-piloto, armazenamento de tomadas de decisão e detalhamento e foco na
elaboração de questões de pesquisa. Além disso, alguns dos pesquisadores apontaram a
preocupação com o canal de comunicação em equipes grandes. Por fim, os principais
desafios apontados se relacionam à diminuição do tempo/esforço para condução da
revisão, formas de extrair evidências da literatura e elaboração de guias de apoio a
revisão.
28
3.2.6 Evolução da Aplicação de Revisões Sistemáticas na Engenharia de Software
O trabalho desenvolvido por KITCHENHAM et al. (2009), apresenta os
resultados de um estudo terciário (revisão sistemática feita a partir de outras revisões
sistemáticas) sobre o status da Engenharia de Software Baseada em Evidência (ESBE) a
partir do ano de 2004. O termo revisão sistemática da literatura só foi amplamente
utilizado a partir deste ano, embora os autores reconheçam que esforços na condução de
revisões sistemáticas foram empregados antes de 2004. O protocolo da revisão foi
elaborado a partir de 4 questões de pesquisa: (i) o quão tem se investido em revisões
sistemáticas desde 2004; (ii) quais são os tópicos de pesquisas investigados?; (iii) quem
investe mais em condução de revisões sistemáticas? e (iv) quais são as limitações das
pesquisas conduzidas atualmente?. Em relação à questão sobre as limitações atuais na
condução de revisões sistemáticas, 4 questões adicionais são consideradas: (i) aonde os
tópicos de pesquisa são limitados?; (ii) existe alguma evidência que a limitação de uso
de revisões sistemáticas é ocasionada pela limitação de estudos primários?; (iii) a
qualidade de revisões sistemáticas é apropriada, se não, está melhorando? e (iv) a
condução de revisões sistemáticas tem contribuído para definição de guias práticos de
apoio?.
O processo de busca por estudos secundários foi executado de forma manual e
utilizou como critério de inclusão/exclusão revisões sistemáticas que destacassem:
questões de pesquisa, o processo de busca, a extração e apresentação de informações.
Para a avaliação da qualidade dos artigos, foi utilizado o critério Database of Abstracts
of Reviews of Effects (DARE) (UCSF, 2011), que é baseado nos itens: (i) os critérios de
inclusão/exclusão são descritos e são apropriados?; (ii) a busca da literatura aparenta
ter coberto todos os estudos considerados relevantes?; (iii) os pesquisadores avaliaram
a qualidade/validade dos estudos incluídos?; e (iv) os dados dos estudos primários são
apresentados de forma apropriada?. Após o término das buscas, 18 artigos foram
considerados para extração de informações. Os resultados obtidos apontaram que o
número de revisões sistemáticas vem aumentando, embora poucas revisões tenham sido
executadas. Em relação a tendências de pesquisa, identificou-se que os maiores esforços
tem sido empreendidos nas áreas de estimativa de custos, métodos de teste e condução
de experimentos em ES. Foi observada também uma predominância por parte de
pesquisadores europeus na condução de revisões sistemáticas. Essa predominância se dá
pela existência de um banco de dados de estudos primários que aborda diversas áreas de
29
pesquisa. Por fim, identificou-se uma limitação de tópicos de ES que são abordados por
revisões sistemáticas.
3.2.7 Definição de Escopo para Busca por Estudos Primários
No trabalho desenvolvido por KITCHENHAM et al. (2009), estratégias de
condução de revisões sistemáticas são comparadas. Para realizar esta comparação, os
autores consideraram as seguintes questões de pesquisa: (i) o quão se pode restringir
uma questão de pesquisa de modo a responder uma questão de pesquisa específica?;
(ii) qual a extensão do uso de estudos com níveis menores de formalidade (grey
literature) em revisões sistemáticas? e (iii) é preferível utilizar estratégias de busca que
considerem buscas automatizadas a buscas manuais no contexto da ES? As questões de
pesquisa foram investigadas através de um estudo de caso participante-observador
baseado em (YIN, 2003). Para efeito de comparação das estratégias, foi utilizado como
baseline a revisão sistemática conduzida por KITCHENHAM et al. (2009). Além disso,
reutilizaram-se os critérios de inclusão/exclusão e os critérios de avaliação da qualidade
dos artigos considerados na revisão conduzida anteriormente. Para extração das
informações, 4 ou 5 artigos foram alocados a 5 revisores de modo que cada artigo fosse
avaliado por 2 revisores. Adicionalmente, um sexto revisor foi responsável por extrair
os dados de todos os artigos. Por fim, os autores afirmam (porém sem detalhes) que os
dados extraídos foram agregados utilizando mediana para a avaliação de qualidade dos
artigos e moda para a categoria.
Os resultados obtidos apontaram que a definição de uma busca mais ampla
retorna um conjunto maior de artigos. No entanto, esta busca retornou um alto número
de artigos de baixa qualidade e que contestavam o resultado obtido na revisão utilizada
como baseline. Em relação às fontes de artigos, identificou-se que textos provenientes
de livros e relatórios técnicos normalmente possuem baixa qualidade, geralmente
ocasionada por falta de revisões. No entanto, não se pode generalizar esta afirmação
para artigos provenientes de workshops. Neste caso, deve ser feita uma análise
cuidadosa do artigo. Por fim, em relação a automatização de buscas, observou-se que a
busca automatizada requer um esforço maior por parte dos pesquisadores. A busca
automatizada retorna um conjunto maior de artigos a serem avaliados. No entanto, este
resultado não implica que a busca automatizada seja necessariamente melhor que busca
manual.
30
3.2.8 Cenário Mais Atual a Respeito da Aplicação de Revisões Sistemáticas da Literatura no Contexto da Engenharia de Software
SILVA et al. (2011) apresentam os resultados de um estudo terciário, cujo
objetivo é atualizar os resultados obtidos pelos trabalhos produzidos por
KITCHENHAM & BRERETON (2009) e KITCHENHAM et al. (2009). Os autores do
estudo utilizaram o mesmo protocolo adotado no estudo original elaborado por
KITCHENHAM & BRERETON (2009). No entanto, diferentemente dos trabalhos
predecessores, SILVA et al. (2011) realizaram uma investigação de artigos que
descrevessem resultados de RSL através de uma estratégia que combinou buscas
manuais e buscas utilizando bases de dados de artigos científicos. Além disso, houve
uma preocupação em descobrir o número de RSL executadas nos períodos entre: (i)
janeiro de 2004 a dezembro de 2009; (ii) janeiro de 2004 a junho de 2008; e (iii) julho
de 2008 e dezembro de 2009.
A aplicação do procedimento de busca por artigos identificou um conjunto de
1389 artigos. Seis pesquisadores atuaram então nas etapas de análise dos artigos e
extração de dados. Para isto, os autores elaboraram um procedimento para definição de
consenso nos casos em que houvesse conflitos de interpretações. De forma semelhante
ao estudo original, os autores também empregaram o método DARE como instrumento
de avaliação de qualidade. Ao término da análise, foram considerados válidos 67
artigos.
Os resultados obtidos indicam que houve um aumento no número de trabalhos
que relatam resultados de RSL. Dentre os estudos identificados, 43% foram produzidos
entre julho de 2008 e dezembro de 2009. Além disso, mais áreas da ES estão sendo
contempladas (24 ao total). Outro ponto positivo indica que mais pesquisadores e de
diferentes instituições tem adotado RSL em suas pesquisas. Como pontos considerados
negativos, o estudo aponta que ainda há deficiências quanto a definição e aplicação de
critérios para avaliação de qualidade. Além disso, são raras as ocasiões onde métodos de
integração de resultados de estudos primários são empregados (como meta-análise, por
exemplo). Por fim, considera-se muito baixo o número de guias que provêem algum
tipo de auxílio para condução deste tipo de estudo.
Com base na análise dos trabalhos citados anteriormente, são identificadas
algumas questões que necessitam ser tratadas com o intuito de evoluir a aplicação de
RSL no contexto da ES:
31
Não observar-se a existência de um repositório central que organize RSL
conduzidas anteriormente. Isto dificulta a identificação de iniciativas prévias de
pesquisa a respeito de um tema que poderiam ser evoluídas por outros
pesquisadores;
Embora este cenário esteja evoluindo, diferentemente dos artigos científicos da
área médica, os artigos científicos na ES não são estruturados de modo que
possa identificar-se rapidamente o problema investigado, os métodos utilizados
e as conclusões obtidas acerca de um estudo realizado. Desta forma, acaba-se
tendo que investir mais tempo na leitura de artigos visando identificar se um
determinado estudo é relevante ou não no contexto de uma RSL;
Não há um consenso entre os pesquisadores na identificação de padrões que
facilitem a aplicação de critérios para avaliação de qualidade de estudos
primários. Além de facilitar o processo de revisão de artigos que descrevem
estudos primários, estes padrões poderiam inclusive servir de guia para
execução e reporte de estudos primários;
A RSL é uma abordagem de pesquisa que requer muito investimento em tempo
de planejamento e esforço para sua aplicação. As especificidades das bases de
dados de artigos científicos requerem a elaboração de diferentes estratégias de
busca. Além disso, há o desafio de “calibrar” as strings de busca de modo a
identificar um conjunto de artigos satisfatório para a revisão. Para que a revisão
possa gerar resultados adequados, é necessário que seja investido tempo no
planejamento da revisão (e na elaboração do protocolo que guiará sua
execução). Isto requer sólidos conhecimentos por parte dos pesquisadores a
respeito dos itens que compõem um protocolo de RSL.
3.3 Tecnologias de Apoio a Condução de Revisões Sistemáticas da Literatura
A partir do entendimento das dificuldades envolvidas no Processo de Condução
de Revisões Sistemáticas da Literatura (PCRSL), tecnologias e ferramentas podem ser
propostas visando diminuir o impacto causado por tais dificuldades. Desta forma, esta
seção visa abordar trabalhos existentes que proponham soluções para facilitar o
emprego de RSL. De uma maneira geral, o PCRSL pode ser contemplado pelo uso de
diferentes ferramentas, embora se tenha identificado que tais ferramentas apresentem
um foco maior na etapa de execução de RSL.
32
3.3.1 Ferramentas de Gerência de Referências Bibliográficas
O emprego de ferramentas de gerência de referências bibliográficas pode ser
muito útil no contexto de condução de revisões sistemáticas. Seu uso se dá na etapa
avaliar os dados coletados (Seção 3.1), uma vez que nesta etapa o pesquisador precisa
gerenciar os documentos (artigos) obtidos a partir das fontes de estudos para então
poder extrair as informações necessárias de cada estudo primário. Estas ferramentas
permitem o cadastro de diversos tipos de documentos através do preenchimento de
campos de informações relativas ao mesmo (título, abstract etc.) em arquivos que
funcionam como bibliotecas. Algumas ferramentas oferecem a seus usuários a
facilidade de criação de novos campos de informações. Essa facilidade permite o uso da
própria ferramenta como formulário de extração de dados referentes a estudos
primários. Após o cadastro, consultas relativas a questões de pesquisa podem ser
formuladas e aplicadas aos campos dos documentos gerenciados por este tipo de
ferramenta.
Observando as vantagens oferecidas por este tipo de ferramenta, uma
investigação foi realizada com o intuito de identificar ferramentas de gerência de
referências bibliográficas existentes e as funcionalidades oferecidas por estas. O
resultado desta investigação encontra-se no Apêndice III. Dentre as ferramentas
identificadas, destacam-se: JabRef, Zotero e Mendeley.
JabRef (JABREF, 2011) é uma ferramenta de referência bibliográfica open
source criada na linguagem de programação Java. A ferramenta possui compatibilidade
com diversos formatos de arquivo de referência bibliográfica (Refer/Endnote, RIS etc.)
tanto para importação como para exportação das referências. Possui ainda suporte para
catálogo de diversos tipos de documentos (artigos, livros, periódicos, revistas etc.).
Além disto, campos de informações adicionais podem ser incluídos (conforme em
destaque na Figura 18), a fim de customizar as informações necessárias para o
gerenciamento de referências bibliográficas. No contexto de revisões sistemáticas, tendo
como exemplo, novos campos podem ser adicionados com o intuito de armazenar se um
determinado artigo foi incluído ou não na lista de arquivos selecionados para leitura,
com base nos critérios de seleção da execução de uma revisão sistemática.
33
Figura 18 - Adição de novos campos na ferramenta JabRef
A ferramenta Zotero (ZOTERO, 2011) é um plugin open source do browser
Firefox. O plugin permite que referências bibliográficas disponíveis em várias máquinas
de busca sejam facilmente adicionadas a biblioteca de referências (Figura 19). Além
disso, permite o arquivamento de conteúdo proveniente de páginas Web, figuras, links,
arquivos etc. Uma funcionalidade interessante oferecida pela Zotero é o
compartilhamento da biblioteca de referências com outros usuários que utilizem a
ferramenta e a possibilidade de sincronização de referências presentes em uma
biblioteca entre outras instâncias da ferramenta (referências armazenadas em outros
computadores). Além disso, a funcionalidade timeline permite a visualização gráfica da
presença de determinados termos escolhidos pelo usuário da ferramenta nos resumos
(abstracts) de cada referência ao longo do tempo (Figura 20). Apesar de oferecer muitas
funcionalidades úteis para a condução de revisões sistemáticas, esta ferramenta não
oferece um mecanismo explícito de adição de novos campos, embora isso possa ser
feito através da adição de notas à referência (também exibido na Figura 20).
A ferramenta Mendeley (MENDELEY, 2011) permite que bibliotecas de
referências bibliográficas possam ser gerenciadas a partir de aplicativo desktop ou
interface Web. Assim, é possível sincronizar o conteúdo de uma biblioteca entre as duas
versões. Além das funcionalidades presentes em outras ferramentas, é oferecida a
possibilidade de indexar o conteúdo de documentos PDF (Portable Document Format)
e adicionar comentários ao conteúdo do documento. Isto permite que consultas possam
ser feitas ao conteúdo do documento e não somente aos campos oferecidos para
34
cadastro da referência (nome do artigo, abstract etc.). A interface Web oferece ainda
análises estatísticas que permitem identificar autores e publicações (e.g. Lecture Notes
in Computer Science) que contêm mais referências dentro de uma biblioteca. Esta
análise pode ser aplicada somente à biblioteca de um usuário ou a todos os usuários que
utilizam a ferramenta (Figura 21). Desta forma, é possível identificar tendências de
pesquisa, embora esta análise seja feita apenas com base em referências cadastradas por
usuários que utilizem esta ferramenta, o que pode não refletir a realidade de tendências
de pesquisa. Por fim, existe um mecanismo de integração com a ferramenta Zotero, que
permite que toda referência cadastrada na Zotero também seja cadastrada na Mendeley.
Figura 19 - Interface da ferramenta Zotero
Figura 20 - Funcionalidade timeline e notas de uma referência
35
Figura 21 - Análise estatística realizada pela ferramenta Mendeley
3.3.2 Uso de Text Mining para Avaliação de Artigos que Descrevem Estudos Primários
O trabalho desenvolvido por ANANIADOU et al. (2009) descreve o projeto
ASSERT, que utiliza técnicas de Text Mining como instrumento de apoio a diversas
etapas da revisão sistemática. As principais funcionalidades oferecidas pelo projeto são
organizadas em um workflow, levando em consideração as etapas da revisão
sistemática, conforme exibe a Figura 22. A extração de termos permite que trechos de
texto considerados relevantes possam ser identificados e ranqueados. A identificação
destes trechos é feita a partir da técnica de extração denominada C value (FRANTZI et
al., 2000) e da ferramenta TerMine. Outra ferramenta utilizada no projeto, denominada
Carrot2, permite o agrupamento de artigos considerados semelhantes em forma de
clusters, o que facilita identificar artigos alinhados com o foco da revisão sistemática.
No entanto, para que os resultados sejam satisfatórios, um grande volume de artigos é
necessário.
Além da formação de clusters, é possível também utilizar algoritmos de
classificação de artigos. Estes algoritmos permitem a identificação de padrões
subjacentes e características distintas em artigos que façam parte de um grupo ou classe
definida e, utiliza essas informações para atribuir novos artigos incluídos a classes
conhecidas. No contexto da revisão sistemática, artigos de controle podem ser utilizados
36
como base de aprendizado para algoritmos que visem classificar novos artigos incluídos
na revisão. Além disso, a identificação de termos sinônimos ou relacionados permite
que estratégias de busca mais bem elaboradas possam ser formuladas. Neste sentido, o
projeto ASSERT utiliza técnicas de busca associativa com o intuito de expandir
consultas através da adição de novos termos. Por fim, o projeto oferece ainda a
funcionalidade de sumarização de conteúdo de artigos.
Figura 22 - Workflow de técnicas de text mining no contexto da revisão sistemática
(adaptada de (ANANIADOU et al., 2009))
3.3.3 Abordagem Visual para Auxiliar a Seleção e Revisão da Seleção de Estudos Primários
No trabalho elaborado por MALHEIROS et al. (2007), além do uso de
ferramentas de Text Mining, são empregadas também ferramentas de visualização de
dados. Os autores demonstram as funcionalidades da ferramenta open source Projection
Explorer (PEx), desenvolvida na Universidade de São Paulo, como instrumento de
apoio a etapa de avaliação de artigos. No entanto, a ferramenta possui a desvantagem de
necessitar converter o texto do artigo para o formato aceito pela ferramenta. Uma vez
que os artigos tenham sido importados, estes são representados como círculos, dispostos
em um mapa 2D, de maneira que artigos considerados similares tendem a estar
próximos. A ferramenta permite a formação de clusters de artigos. Além disso, em cada
cluster gerado, termos considerados como relevantes nos artigos são destacados como
labels. Outra funcionalidade de interesse é a formação de uma rede de relacionamentos
entre as referências bibliográficas de artigos. Em conjunto, essas funcionalidades
reduzem o tempo gasto pelo pesquisador na avaliação de artigos.
Como exemplo de demonstração, os autores realizaram um estudo comparativo
entre um pesquisador que realizou a avaliação dos artigos de forma manual (pesquisador
37
A) e dois pesquisadores que realizaram a avaliação através da ferramenta PEx
(pesquisadores B e C). Como oráculo do estudo, foi considerado um conjunto de 40
artigos que tratavam sobre efetividade de aplicação de testes de software como forma de
melhorar a qualidade final do produto. Para medição de eficiência do processo de
avaliação dos artigos, considerou-se o número de artigos selecionados e o tempo gasto
na atividade. Os resultados obtidos indicaram que o pesquisador A selecionou 26 artigos
em 3 horas de atividades, o pesquisador B selecionou 22 artigos em 49 minutos e o
pesquisador C selecionou 23 artigos em 51 minutos. Já em relação a precisão dos
artigos ao tema proposto, o pesquisador A obteve 83.87%, enquanto que os
pesquisadores B e C obtiveram 81.28% e 92% de precisão.
FELIZARDO et al. (2009) também utilizam a ferramenta PEx como instrumento
de auxílio a avaliação de artigos no contexto de revisões sistemáticas. No entanto, no
trabalho apresentado, os autores demonstram a ferramenta como instrumento de auxílio
a revisão dos artigos selecionados anteriormente. Com este intuito, a ferramenta permite
a coloração de artigos baseado em critérios definidos pelo pesquisador. Este esquema de
coloração permite que artigos incluídos e excluídos da revisão possam ser agrupados em
clusters. Desta forma, é possível investigar inconsistências no processo de avaliação,
como o exemplificado na Figura 23.a. Neste exemplo, dois artigos considerados
semelhantes e pertencentes a um mesmo cluster possuem avaliações distintas (cluster
marcado com o número 1). Além disso, é possível colorir os artigos baseado em
critérios de qualidade definidos para a revisão (Figura 23.b). Outra funcionalidade de
apoio ao processo de revisão dos resultados permite a visualização da rede de
relacionamentos das referências dos artigos incluídos e excluídos (Figura 24). Através
dessa visualização é possível identificar, por exemplo, estudos que não estão conectados
aos demais, ou seja, não compartilham referências.
Figura 23 - Visualização de artigos incluídos e excluídos e, sob critérios de qualidade (extraída de
(FELIZARDO et al., 2009))
38
Figura 24 - Rede de relacionamento entre artigos (extraída de (FELIZARDO et al., 2009))
3.3.4 EPPI Reviewer
A ferramenta EPPI Reviewer (EPPI-CENTRE, 2010) é um aplicativo Web que
visa facilitar a etapa execução do Processo de Condução de Revisões Sistemáticas. Esta
oferece as funcionalidades de gerenciamento de artigos de forma similar às ferramentas
de gerência de referências bibliográficas (características deste tipo de ferramenta serão
abordadas na próxima seção), classificação de artigos a partir de critérios de
inclusão/exclusão definidos pelos participantes da revisão, criação de formulários de
extração de dados, suporte à meta-análise e geração de gráficos. Até o momento da
escrita desta dissertação, não foi possível ter acesso à ferramenta, o que impede obter
maiores detalhes sobre as funcionalidades oferecidas pela ferramenta.
3.3.5 SLR-TOOL - A Tool for Performing Systematic Literature Reviews
A ferramenta SLRTool (FERNÁNDEZ-SÁEZ et al., 2010) é um aplicativo
desktop voltado para o armazenamento de informações referentes às etapas
planejamento, execução e análise dos resultados do Processo de Condução de
Revisões Sistemáticas. Em relação ao planejamento, a ferramenta permite o cadastro
de dados relativos a questões de pesquisa, critérios de inclusão/exclusão, critérios de
avaliação de critérios de qualidade, pesquisadores envolvidos na revisão, estratégias de
pesquisa e comentários sobre critérios para extração de dados, resolução de conflitos,
síntese de dados e apresentação das conclusões do estudo. Referente à etapa execução, a
ferramenta facilita o gerenciamento das informações relacionadas aos estudos obtidos
através das fontes de estudos definidas no protocolo da revisão, conforme exibe a
Figura 25. A ferramenta permite ainda a classificação dos estudos em relação a critérios
definidos pelo usuário da ferramenta (incluindo critérios de qualidade) e a indicação de
39
quais estudos se enquadram nos critérios de inclusão e exclusão. Por fim, em relação à
etapa análise dos resultados, é possível visualizar a classificação dos estudos em
relação aos critérios definidos na etapa anterior (Figura 26). Adicionalmente, é possível
visualizar quais estudos atenderam aos critérios de qualidade, inclusão e exclusão, além
de poder exportar os resultados no formato de planilha eletrônica e as referências no
formato utilizado por ferramentas de gerência de referências bibliográficas.
Figura 25 - Funcionalidade de apoio à etapa execução oferecida pela ferramenta SLRTool (extraída
de (FERNÁNDEZ-SÁEZ et al., 2010))
Figura 26 – Resultados da classificação dos estudos considerados pela revisão (extraída de
(FERNÁNDEZ-SÁEZ et al., 2010))
40
3.3.6 StArt
State of Art Through Systematic Review (StArt) (ZAMBONI et al., 2010)
consiste em um projeto de reestruturação da ferramenta Systematic Review Automatic
Tool (SRAT) (MONTEBELO et al., 2007). O objetivo da StArt é automatizar tarefas
envolvidas durante a execução de RSL, com o intuito de tornar a execução deste tipo de
estudo mais ágil, precisa e replicável. A ferramenta, que contempla todas as etapas do
Processo de Condução de Revisões Sistemáticas, organiza a condução de RSL em três
grupos: planejamento, execução e sumarização dos resultados. A interface gráfica da
ferramenta é exibida na Figura 27.
A ferramenta possibilita ao pesquisador o preenchimento do protocolo de RSL.
No entanto, o template de protocolo utilizado pela ferramenta é estático, o que implica a
necessidade de conhecimento sob quais partes do template devem ser preenchidas de
modo a atender às necessidades do estudo. Neste quesito, a ferramenta não oferece um
apoio efetivo à tomada de decisão relativa ao planejamento do estudo. Uma vez que o
protocolo tenha sido preenchido, a ferramenta permite que, para cada base de dados de
artigos científicos, sejam criadas sessões de busca. Nestas sessões, o pesquisador deve
fornecer as strings de busca adaptadas às sintaxes utilizadas pelas bases de dados. Para
cada sessão de busca, deve-se fornecer o arquivo Bibtex que contenha os artigos
retornados pela aplicação de uma determinada string de busca.
Após a execução das consultas e a importação dos arquivos Bibtex na
ferramenta, StArt apóia as atividades de aplicação dos critérios de inclusão/exclusão,
avaliação de qualidade de estudos primários e extração de dados com base nos critérios
contidos no protocolo do estudo. Durante a análise dos artigos, a ferramenta permite
demarcar quais são os artigos que deverão ser utilizados para extração de dados. Em
relação à etapa de extração de dados, a ferramenta disponibiliza ainda o template do
formulário de extração (com base no protocolo que guia o estudo). Por fim, a ferramenta
permite gerar o relatório do estudo no formato de arquivo PDF.
41
Figura 27 – Interface gráfica da StArt (extraída de (ZAMBONI et al., 2010))
3.3.7 Review Manager (RevMan)
Review Manager (RevMan) (COCHRANE IMS, 2010) é uma ferramenta
destinada a elaboração e publicação de revisões sistemáticas disponibilizada pela
Instituição Cochrane (COCHRANE, 2011b). A ferramenta funciona como um editor de
protocolos e relatórios de revisão sistemática, que visa facilitar as tarefas de descrição
do estudo, inserção de tabelas comparativas etc. Permite também a condução de meta-
análises e apresentação de resultados de forma gráfica.
RevMan permite a elaboração de revisões que abordem estudos do tipo
diagnostic test accuracy studies, reviews of studies of methodology e overviews of
reviws (Figura 28.a). Permite ainda que seja criado o protocolo ou o relatório completo
da revisão (Figura 28.b). Após escolher o tipo de estudo desejado, é apresentada a tela
que permite a edição dos dados do protocolo (ou relatório), que é dividida em duas
partes (demarcadas por retângulos), conforme exibe a Figura 29. A parte da esquerda
exibe as seções contidas no documento correspondente ao protocolo proposto pela
instituição, enquanto que a parte direita exibe o conteúdo de cada seção. Embora a
ferramenta tenha sido concebida com o intuito de elaborar protocolos (ou relatórios) de
revisões voltados para publicação na instituição Cochrane, é possível elaborar
42
protocolos com outros fins. Desta forma, a ferramenta permite que algumas seções do
protocolo possam ser excluídas ou reordenadas.
Figura 28 - Criação do protocolo/relatório de revisão sistemática
Figura 29 - Interface da ferramenta RevMan
RevMan também permite que modificações no protocolo possam ser
identificadas. Isto é extremamente útil quando se deseja atualizar os dados de uma
revisão já publicada. Para isto, duas funcionalidades são oferecidas: What´s New e
43
History (Figura 30). A funcionalidade What´s New permite que modificações no
protocolo atual sejam destacadas a partir de três eventos: (i) amended – modificação
genérica; (ii) feedback incorporated – opinião externa incorporada; (iii) new citation:
no major change – novo estudo primário identificado que não apresenta grandes
impactos na revisão; e (iv) new citation: major change – novo estudo que acarreta em
grandes modificações na revisão. Já a funcionalidade History identifica as modificações
no protocolo que não sejam referentes à versão atual.
Por fim, RevMan permite que o protocolo da revisão possa ser editado de forma
colaborativa. Para que isto seja possível, os usuários que desejam participar da
elaboração do protocolo devem possuir uma conta de acesso ao serviço Archie, um
repositório de documentos e usuários pertencentes à Rede de Colaboração Cochrane.
Assim, é possível compartilhar e/ou editar (caso o responsável pela criação do
documento permita) protocolos de revisão sistemática (ou relatórios) com a comunidade
de usuários que utilizem este serviço. O esquema de edição colaborativa do protocolo
funciona a partir de um sistema de controle de versões que emprega um mecanismo de
lock pessimista. Cada documento armazenado no repositório possui identificador de
versão do documento, data em que o documento foi modificado, status do documento
(rascunho, aguardando revisão para ser publicado ou publicado) e usuário responsável
pela modificação. Apesar das vantagens oferecidas, esta ferramenta não oferece apoio a
tomada de decisão ou entendimento em como os elementos presentes no protocolo se
relacionam. Um pesquisador inexperiente na condução de revisões sistemáticas pode ter
dificuldades em identificar quais seções oferecidas pela ferramenta são necessárias para
o tipo de revisão sistemática que planeja.
Figura 30 - Identificação de modificações importantes no protocolo de revisão sistemática
3.4 Conclusão
As tecnologias identificadas neste capítulo representam uma importante
iniciativa da comunidade acadêmica em apresentar soluções que facilitem a condução
de RSL. No entanto, de uma maneira geral, observa-se que estas tecnologias são focadas
44
na execução da RSL em detrimento da etapa de planejamento, etapa fundamental para
que uma revisão possa apresentar resultados satisfatórios. Na Tabela 2, é feita uma
análise quanto aos diferentes níveis de apoio que cada tecnologia investigada oferece
em relação às etapas da RSL (com exceção da ferramenta EPPI Reviewer, a qual não foi
possível investigar). Além disso, embora haja guias para elaboração de documentos
correspondentes ao protocolo de RSL e relatório de reporte de resultados, acredita-se
que não há um consenso geral a respeito da definição e organização dos itens que
devem compor tais documentos. Assim, a identificação de limitações e oportunidades
de melhoria nos trabalhos citados neste capítulo permite pensar em requisitos adicionais
para a construção de serviços que apóiem o PCRSL: (i) facilitar o entendimento e
compartilhar os conceitos ligados ao PCRSL; (ii) apoiar pesquisadores com pouca
experiência nesta abordagem a planejar e executar RSL; (iii) oferecer mecanismos que
facilitem a execução deste tipo de revisão de forma colaborativa; e (iv) apoiar o
empacotamento dos artefatos produzidos pelo planejamento e execução deste tipo de
revisão. Para contemplar tais requisitos, este trabalho propõe uma ferramenta que possa
auxiliar o planejamento (auxiliando também o empacotamento dos artefatos produzidos
durante o planejamento) de estudos secundários seguindo uma abordagem semelhante à
ferramenta eSPA (apresentada no Capítulo 2).
Tabela 2 - Níveis de apoio oferecidos pelas ferramentas investigadas quanto às etapas da RSL
Planejamento Execução Análise dos
Resultados Empacotamento
JabRef Baixo Médio Baixo Baixo
Mendeley Baixo Médio Baixo Baixo
Zotero Baixo Médio Baixo Baixo
Assert Nenhum Alto Alto Baixo
PEx Nenhum Alto Alto Baixo
SLR-TOOL Médio Médio Alto Médio
Start Médio Médio Médio Médio
RevMan Médio Médio Alto Médio
45
4 Evolução do Repositório de Conhecimento do
eSEE
Neste capítulo, é apresentada a metodologia utilizada na evolução
do repositório de conhecimento do ambiente eSEE por meio de uma
ontologia de estudos secundários e um guia de apoio ao processo
de condução de revisões sistemáticas da literatura.
4.1 Introdução
Conforme mencionado no Capítulo 2, o ambiente eSEE possui um Repositório
de Conhecimento sobre Experimentação em Engenharia de Software fundamentado na
interdependência entre dois mecanismos de representação de conhecimento, que são um
glossário de termos (dicionário) de experimentação em ES e modelos conceituais
(ontologias). No entanto, apesar do repositório tratar conceitos gerais sobre
experimentação, este possui em sua primeira instância foco maior em estudos primários
(LOPES & TRAVASSOS, 2009). Com isto, conceitos ligados a estudos secundários
não são explorados de forma detalhada. Assim, o próximo passo para a evolução do
repositório de conhecimento do eSEE se dá na direção da inclusão de mecanismos para
representação do conhecimento a respeito de estudos secundários, tendo a preocupação
em garantir maiores níveis de corretude e completude dos novos modelos.
Neste capítulo, é apresentada a evolução dos mecanismos de representação de
conhecimento e o procedimento adotado (juntamente com as experiências obtidas
através da aplicação do método) para revisão dos modelos ontológicos referentes a
estudos secundários em ES constituintes do ambiente. Além desta seção, estrutura deste
capítulo esta organizada da seguinte forma: a Seção 4.2 apresenta o processo adotado
para construção das ontologias com base na metodologia Methontology e apresenta os
modelos conceituais elaborados neste trabalho. A Seção 4.3 aborda a construção de um
Guia de Apoio ao Processo de Condução de Revisões Sistemáticas da Literatura,
enquanto que a Seção 4.4 apresenta os procedimentos e resultados obtidos com a
aplicação de um procedimento de inspeção nas ontologias e guia de apoio. Por fim, a
Seção 4.5 apresenta a conclusão do capítulo.
46
4.2 Processo para Construção dos Modelos Conceituais
A metodologia adotada para expansão do repositório de conhecimento do eSEE
foi a Methontology (FERNÁNDEZ et al., 1997). Desenvolvida no laboratório de
Inteligência Artificial da Universidade Politécnica de Madri, a Methontology está em
conformidade com o processo padrão para desenvolvimento de software recomendado
pela IEEE e é amplamente utilizado pela comunidade acadêmica. A metodologia possui
um processo no qual suas etapas são divididas em três fases: gerenciamento,
desenvolvimento e suporte, conforme ilustra a Figura 31. A seguir, será abordado como
cada etapa foi conduzida ao longo da elaboração dos modelos que abordem estudos
secundários.
Figura 31 - Organização das atividades da Methontology (adaptada de (FERNÁNDEZ et al., 1997))
4.2.1 Planejamento
Nesta etapa, foi definido que os modelos que compõem a ontologia seriam
organizados em sub ontologias, visando facilitar a leitura dos modelos. Optou-se por,
inicialmente, construir a ontologia utilizando a linguagem LINGO. A escolha pela
linguagem foi para manter a compatibilidade com os modelos iniciais desenvolvidos por
LOPES & TRAVASSOS (2009). Ressalta-se que está linguagem não oferece suporte
adequado para expressão de cláusulas de existência. Entretanto, considerando a forma
como os modelos foram utilizados no escopo desta dissertação, a representação dos
modelos por meio de LINGO mostrou-se suficiente. Por fim, por não representar
impacto relevante nesta dissertação, características como tempo e custo de construção
da ontologia não foram alvo de avaliação.
47
4.2.2 Especificação
A etapa de Especificação envolveu definir a razão para a construção e a forma
de utilização da ontologia. Fundamentalmente, a razão e a forma de utilização estão
relacionadas diretamente com a construção do Repositório de Conhecimento sobre
Experimentação em ES do eSEE.
4.2.3 Conceitualização
A Conceitualização consistiu em investigar trabalhos que pudessem agregar
novos conceitos para a Ontologia de Estudos Secundários. Nesta etapa, os principais
trabalhos considerados para extração de conceitos foram KITCHENHAM (2004),
BIOLCHINI et al. (2005) e KITCHENHAM & CHARTERS (2007), tendo em vista seu
reconhecimento na comunidade de experimentação em Engenharia de Software.
4.2.4 Formalização
Na etapa Formalização, o modelo semi-formal da etapa Conceitualização foi
gerado utilizando a linguagem de representação visual de ontologias denoninada
LINGO (FALBO et al., 1998). Os modelos foram construídos utilizando a ferramenta
Enterprise Architect (SPARK SYSTEMS, 2012) e estão disponíveis no endereço
http://lens-ese.cos.ufrj.br/ontologiarevisaosistematica. Ao clicar em um dos conceitos, é
possível visualizar sua descrição. De forma semelhante à Ontologia de Pesquisa
Científica, a Ontologia de Estudos Secundários também foi organizada através de sub
ontologias. Assim, o primeiro nível da ontologia corresponde ao modelo apresentado na
Figura 32. Ainda se aproveitando da organização dos modelos contemplados em
BIOLCHINI et al. (2007), o conceito Estudo Secundário é composto de outros
conceitos, que são estruturados por meio de sub ontologias: (i) sub ontologia de
estrutura de estudo – define uma classificação taxonômica para estudos secundários;
(ii) sub ontologia de qualidade do estudo – define conceitos a respeito da qualidade e
validade do estudo; e (iii) sub ontologia de procedimento metodológico – define
abordagens de estudos secundários e conceitos ligados à elaboração do protocolo e
relatório de revisão sistemática. Ressalta-se que s modelos apresentados a seguir
correspondem à versão mais atualizada da Ontologia de Estudos Secundários.
48
Figura 32 – Primeiro nível da hierarquia da Ontologia de Estudos Secundários
Figura 33 – Sub ontologia de Estrutura do Estudo
A sub ontologia Estrutura do Estudo foi reorganizada, de modo que os
conceitos Intervention, Control, Outcome e Medição (Measurement) foram movidos
para outras partes da ontologia. Além disso, conceitos presentes na Ontologia de
Pesquisa Científica foram agregados à sub ontologia Estrutura do Estudo. Desta forma,
os conceitos presentes em ambos os modelos são destacados por meio de um retângulo
de cor cinza. No entanto, diferentemente da estrutura proposta por LOPES (2010), a
estrutura do conceito Objetivo de Pesquisa foi reorganizada de modo a contemplar os
conceitos Problema e Hipótese (e os conceitos que herdam de Hipótese, Hipótese Nula
e Hipótese Alternativa). Além disso, foram incluídos relacionamentos entre os conceitos
49
Objetivo de Pesquisa, Questões Primárias e Questões Secundárias. Esta modificação
foi realizada devido à necessidade de distinguir o conjunto de questões primárias do
conjunto de questões secundárias, no escopo da ferramenta de apoio ao planejamento de
estudos secundários.
A estrutura da sub ontologia Qualidade do Estudo não sofreu muitas
modificações em relação à versão original proposta por BIOLCHINI et al. (2007). As
modificações implementadas dizem respeito a agregação de conceitos que herdam do
conceito Validade do Estudo e a inclusão de relacionamento de influência entre os
conceitos Efeito do Tamanho e Validade do Estudo e entre os conceitos Viés do Estudo
e Validade do Estudo, conforme ilustra a Figura 34.
Figura 34 – Sub ontologia de Qualidade do Estudo
A sub ontologia Procedimento Metodológico (Figura 35) foi reorganizada de
forma a incluir conceitos ligados ao desenvolvimento do protocolo do estudo, ferra-
mentas possíveis de serem adotadas na condução do estudo e das possíveis abordagens a
serem aplicadas (Agregação, Meta-análise, Síntese e Revisão Sistemática e quasi
Revisão Sistemática). Além disso, o conceito Protocolo de Revisão Sistemática também
é especializado por meio de sub ontologias, de modo a conter conceitos ligados a
formulação de questão de pesquisa, seleção de fontes de estudos, seleção de estudos,
extração de dados e sumarização das informações do estudo, conforme exibe a Figura
36. A organização das sub ontologias Questão de Pesquisa, Fontes de Estudos,
Estudos Selecionados, Dados Extraídos e Dados Sumarizados se deu com o intuito
de estar aderente a organização das principais seções dos documentos que representam
templates de protocolos de RSL propostos por (KITCHENHAM, 2004), (BIOLCHINI
et al., 2005) e (KITCHENHAM & CHARTERS, 2007).
50
Figura 35 – Sub ontologia de Procedimento Metodológico
Figura 36 - Sub ontologia Protocolo de Revisão Sistemática
A sub ontologia Questão de Pesquisa expressa as questões que norteiam a
execução do estudo de modo mais estruturado. Ao visualizar o modelo apresentado na
Figura 37, observa-se que este apresenta os conceitos relacionados à elaboração de
strings de busca, de modo que estas strings possam ser aplicadas às bases de dados de
artigos científicos. Desta forma, os conceitos Intervention, Control (neste modelo
traduzido para Controle) e Outcome, originalmente pertencentes a sub ontologia
Estrutura do Estudo, foram incluídos neste modelo. Além disso, foi incluído também
o conceito Study Design, que permite restringir os resultados provenientes da aplicação
de uma string de busca em uma base de dados a tipos específicos de estudos primários
(estudo controlado, survey, action research etc.). Repare também que cada conceito que
compõe a estrutura PICO (Population, Intervention, Comparison e Outcome) possui um
relacionamento de agregação com o conceito Termo, de modo a representar os termos
que irão compor as strings de busca. Desta forma, é possível gerar strings de busca por
meio da aplicação dos conectores AND e OR aos termos contidos nos conceitos que
representam a estrutura PICO. Por fim, o conceito String de Busca Adaptada visa
51
representar as strings de busca adaptadas às especificidades das bases de dados de
artigos científicas adotadas no estudo.
Figura 37 - Sub ontologia Questão de Pesquisa
A sub ontologia Fontes de Estudos (Figura 38) representa o conhecimento
relacionado a restrição de idiomas de artigos científicos e os procedimentos e critérios
para seleção de fontes de estudos. Neste modelo, as fontes de estudos são representadas
pelos conceitos Base de Dados, Base de Dados Eletrônica (representa as máquinas de
busca de artigos científicos) e Base de Dados Manual (representa fontes de estudos
como bibliotecas, manuais, anais de eventos etc.). Repare que o relacionamento entre os
conceitos Fontes de Estudos, Bases de Dados Eletrônicas e Bases de Dados Manuais
permite distinguir as bases de dados selecionadas para avaliação sob os critérios de
seleção estipulados pelo pesquisador (representado pelo conceito Critério de Seleção de
Fontes de Estudos). Esta organização permite identificar quais os critérios de seleção
satisfeitos por cada base de dados. Além disso, esta sub ontologia representa também a
adaptação de strings de busca para a sintaxe adotada pelas diversas máquinas de busca.
Para que isto seja possível, o conceito Adaptação de String de Busca se comporta como
associação entre os conceitos Questão de Pesquisa e Base de Dados Eletrônica.
52
Figura 38 - Sub ontologia Fontes de Estudos
Os conceitos que tratam o conhecimento acerca de procedimentos e critérios
para inclusão/exclusão, avaliação de qualidade, hierarquização de estudos e
estabelecimento de procedimentos para resolução de divergência entre pesquisadores
são representados na sub ontologia Estudos Selecionados. Os estudos primários
selecionados pela aplicação do procedimento de seleção (considerando os critérios de
seleção especificados) são representados pelo conceito Estudos Primários Selecionados.
O conceito Revisão dos Estudos Primários Selecionados visa expressar o processo de
revisão dos estudos selecionados para extração de dados. Já conceito Características de
Qualidade (e suas especializações) foi concebido com o intuito de distinguir as
características de qualidade a serem observadas nos estudos em avaliação. Além disso,
este modelo permite representar os estudos em avaliação sob a seguinte taxonomia: (i)
in vivo – envolvem as pessoas em seus próprios ambientes; (ii) in vitro – executados e
controlados em ambientes tais como laboratórios ou comunidades controladas; (iii) in
virtuo – conduzido em um ambiente virtual, composto por modelos computacionais que
são manipulados por pessoas; e (iv) in silico – conduzido em um ambiente onde o
comportamento dos indivíduos envolvidos também é descrito por modelos
computacionais. O modelo que representa a sub ontologia Estudos Selecionados é
ilustrado na Figura 39.
53
Figura 39 - Sub ontologia Estudos Selecionados
A sub ontologia Dados Extraídos, ilustrada pela Figura 40, representa o
conhecimento sobre as ferramentas adotadas para catalogação e análise dos estudos
primários selecionados, a descrição do formulário para extração dos dados provenientes
dos estudos primários selecionados, o procedimento adotado para extração dos dados e
informações sobre os resultados da execução piloto do protocolo e possíveis
divergências entre os pesquisadores decorridas da aplicação do procedimento de
extração. Por fim, com o intuito de facilitar a organização dos dados a serem extraídos,
são contemplados os conceitos Dados Objetivos e Dados Subjetivos.
O último modelo que compõe os conceitos ligados ao protocolo de revisão
sistemática, a sub ontologia Dados Sumarizados (Figura 41), inclui conceitos
relacionados à análise de sensibilidade dos resultados obtidos e aos viéses do estudo.
São considerados, também, a análise de métodos estatísticos empregados no estudo
(normalmente empregados em estudos que contemplam meta-análises), a exibição
desses dados em formato gráfico (por meio do conceito Dados Plotados) e o resumo
final das conclusões obtidas com a execução da revisão.
54
Figura 40 - Sub ontologia Dados Extraídos
Figura 41 - Sub ontologia Dados Sumarizados
Por fim, o último modelo representado na Ontologia de Estudos Secundários é a
sub ontologia Template de Protocolo de Revisão Sistemática, cujo objetivo é filtrar os
conceitos pertencentes a Ontologia de Estudos Secundários de modo a exibir apenas os
conceitos que fazem parte do template do protocolo do estudo. Por questões de espaço,
o modelo da sub ontologia Template de Protocolo de Revisão Sistemática é
apresentado no Apêndice IV.
55
4.2.5 Integração
Planeja-se futuramente integrar a Ontologia de Estudos Secundários a Ontologia
de Pesquisa Científica elaborada por LOPES (2010). Neste sentido, conforme citado na
seção anterior, demarcou-se os conceitos presentes na Ontologia de Estudos
Secundários que também façam parte da Ontologia de Pesquisa Científica por meio de
um retângulo de cor acinzentada. No entanto, ainda não há um planejamento que aponte
os passos a serem contemplados para a integração das ontologias.
4.2.6 Implementação
A etapa Implementação especifica que a ontologia seja codificada através da
representação dos conceitos e relacionamentos utilizando uma linguagem formal para
ontologias, tornando-a assim passível de processamento, ou seja, em seu estado atual, a
ferramenta não executa qualquer tipo de inferência em cima dos conceitos presentes na
ontologia.
Na Ontologia de Estudos Secundários, não foram definidas as cláusulas que
definem as condições de existência dos conceitos propostos. Diferentemente da
ferramenta eSPA (ver Capítulo 2), o mecanismo de apoio a tomada de decisão se dá pela
consulta a um guia de apoio ao PCRSL. Desta forma, a ontologia atua como indicador
dos conceitos que devem ser tratados ao planejar-se um estudo secundário, não sendo
necessário convertê-la para notação de uma linguagem com maiores níveis de
formalidade (como OWL, por exemplo). Nesse sentido, os modelos desenvolvidos na
linguagem LINGO (que consiste num subconjunto de elementos UML) foram
convertidos para a notação da linguagem de programação utilizada na construção da
ferramenta de apoio ao planejamento de estudos secundários (classes Java).
4.2.7 Manutenção
Para realizar a manutenção dos modelos constituintes da Ontologia de Estudos
Secundários, é necessário registrar informações sobre a necessidade de modificação dos
modelos, usuário responsável pela modificação e a descrição da alteração realizada.
Além disso, recomenda-se também que a cada modificação feita seja criada uma nova
versão do arquivo correspondente à ontologia para fins de manutenção do histórico de
atualizações.
56
4.2.8 Documentação
Na etapa Documentação, o planejamento e a execução do processo foram
descritos, detalhando a construção dos artefatos em cada etapa. Foge ao escopo deste
trabalho fornecer detalhes de cronograma e outras informações que não estão
relacionadas diretamente ao conteúdo dos modelos.
4.2.9 Avaliação
A avaliação das ontologias se deu por meio de sessões de inspeção nos modelos
desenvolvidos na linguagem LINGO, conduzidas por alunos de pós graduação da
COPPE/UFRJ. Em conjunto a inspeção das ontologias, houve também a inspeção de um
guia de apoio ao PCRSL e de um documento de requisitos para construção dos serviços
que apóiem o planejamento e execução de RSL. Maiores detalhes sobre o procedimento
de inspeção adotado serão abordados na Seção 4.4.
4.3 Guia de Apoio ao Processo de Condução de Revisões Sistemáticas da Literatura
Apesar da Ontologia de Estudos Secundários representar os principais conceitos
envolvidos no planejamento e execução de revisões sistemáticas, não há uma definição
clara em como estes conceitos se relacionam com o Processo de Condução de Revisões
Sistemáticas da Literatura (PCRSL). Desta forma, integrou-se ao repositório de
conhecimento do eSEE, um guia de apoio ao PCRSL. Este guia contempla as principais
atividades ligadas ao planejamento e execução de revisões sistemáticas. O acesso ao
guia está disponível em http://lens-ese.cos.ufrj.br/guiarevisaosistematica.
Para representar o guia de apoio, foi adotado o diagrama de atividades em raias
da UML. As atividades foram divididas considerando quatro perfis de pesquisadores
atuantes em revisões sistemáticas: (i) coordenador da revisão – responsável pelo ge-
renciamento dos demais pesquisadores e atribuição de tarefas; (ii) desenvolvedor do
protocolo – responsável pelo planejamento da revisão; (iii) executor do protocolo –
responsável por aplicar as strings de buscas nas bases de dados, avaliação e extração
de dados; e (iv) revisor: responsável pela validação dos artefatos produzidos durante o
planejamento e execução da revisão sistemática.
57
Figura 42 - Guia de Apoio ao Processo de Condução de Revisões Sistemáticas
Na Figura 42, as atividades envolvidas através de um retângulo tracejado são
especializadas por meio de sub diagramas. A primeira sub atividade descrita pelo guia
de apoio, a atividade Selecionar Pesquisadores (Figura 43), contempla a seleção dos
responsáveis pela elaboração do plano do estudo, os responsáveis pela revisão dos
artefatos produzidos ao longo do PCRSL e os responsáveis pela execução do protocolo.
A sub atividade Reunir Pesquisadores, ilustrada na Figura 44, prevê que estes
utilizem algum meio de comunicação (síncrona ou assíncrona) para estipular um
cronograma inicial para as atividades a serem executadas e definirem possíveis apoios
ferramentais a serem empregados no planejamento e execução da revisão sistemática.
58
Figura 43 - Sub atividade Selecionar Pesquisadores
Figura 44 - Sub atividade Reunir com Pesquisadores
Uma vez que o cronograma inicial das atividades tenha sido estabelecido, a sub
atividade Atribuir Atividades aos Pesquisadores (Figura 45) recomenda que o
coordenador da revisão (mas não o obriga) divida as atividades de elaboração do
protocolo entre os pesquisadores com base nas principais seções do template de
protocolo de revisão sistemática.
Figura 45 - Sub atividade Atribuir Atividade aos Pesquisadores
59
Com o intuito de estruturar o preenchimento do protocolo de revisão sistemática,
a atividade Preencher Protocolo contempla as quatro principais seções do template de
protocolo descrito em BIOLCHINI et al. (2005): (i) formulação da questão de pesquisa;
(ii) seleção de fonte de estudos; (iii) seleção de estudos; e (iv) sumarização dos
resultados. Cada uma das atividades citadas anteriormente é sub-especializada em
demais diagramas de atividades, de forma a indicar os passos a serem seguidos no
preenchimento do protocolo de revisão sistemática. Neste sub diagrama, são
consideradas também as atividades relacionadas ao registro do tempo e modificações
feitas no protocolo, conforme exibe a Figura 46.
Figura 46 - Sub atividade Preencher Protocolo
As atividades ligadas à definição da questão de pesquisa, pertencentes a sub
atividade Preencher Dados Relacionados à Definição do Estudo e Questão de
Pesquisa, incluem o preenchimento de informações de identificação do protocolo,
resumo do contexto da revisão, definição do objetivo do estudo e especificação de
questões de pesquisa. Para definição do objetivo do estudo, é adotado o paradigma
GQM (Goal Question Metric) (BASILI et al., 1994). Ainda neste sub diagrama, é
definido também o procedimento metodológico a ser empregado no estudo, podendo-se
optar por conduzir uma quasi Revisão Sistemática, Revisão Sistemática ou Meta
análise. Outro ponto importante neste sub diagrama está relacionado à definição da
estrutura PICO (Population, Intervention, Comparison e Outcome) para cada questão de
pesquisa formulada (incluindo questões secundárias). Esta definição será útil na
elaboração de strings de busca com base nos termos pertencentes à estrutura PICO. Por
questões de espaço, o sub diagrama Preencher Dados Relacionados à Definição do
Estudo e Questão de Pesquisa é exibido no Apêndice V.
A sub atividade Preencher Dados Relacionados à Seleção de Fontes de
Estudos (Figura 47) inclui a definição do procedimento e critérios para seleção das
bases de dados (eletrônicas e manuais). Uma vez que tenha se definido um conjunto
inicial de bases de dados, estas devem ser avaliadas segundo os critérios e
procedimentos definidos anteriormente. Em seguida, deve ser conduzida uma revisão da
aplicação dos critérios com intuito de verificar se alguma base de dados foi
indevidamente incluída no conjunto de bases selecionadas para aplicação das strings de
60
busca definidas na sub atividade anterior. Por fim, a última atividade prevista neste
diagrama indica a elaboração de strings de busca adaptadas à sintaxe das bases de dados
eletrônicas selecionadas.
Figura 47 - Sub atividade Preencher Dados Relacionados à Seleção de Fontes de Estudos
A próxima sub atividade, Preencher Dados Relacionados à Seleção de
Estudos, prevê a definição dos critérios e procedimentos para inclusão e exclusão de
artigos que relatem estudos primários. Caso se julgue necessário, tais critérios e
procedimentos podem ser redefinidos. De forma semelhante, este sub diagrama inclui
também atividades de definição e revisão de critérios para avaliação de qualidade e
hierarquização dos estudos primários. Por fim, são consideradas atividades que tratam a
61
definição dos dados a serem extraídos dos estudos primários. Devido ao tamanho do
diagrama correspondente a está sub atividade, este é exibido no Apêndice V.
Já a sub atividade Preencher Dados Relacionados à Sumarização dos
Resultados, ilustrada na Figura 48, inclui a especificação de tabelas para apresentação
dos resultados, a definição de procedimentos a serem adotados para análise de
sensibilidade, análise estatística e a plotagem de gráficos correspondentes aos resultados
obtidos com a execução da revisão.
Ao término do preenchimento do protocolo de revisão sistemática, inicia-se a
sub atividade Revisão do Protocolo (ver Figura 42). Nesta sub atividade, representada
pela Figura 49, destaca-se a importância de registrar o relatório de avaliação do
documento correspondente ao plano de forma a manter um histórico de possíveis
alterações no plano do estudo.
Após a aprovação do protocolo por parte do(s) revisor(es) alocados ao estudo,
executa-se a sub atividade Executar Piloto. Nesta sub atividade há uma preocupação
em verificar se as strings de busca elaboradas se mostram adequadas às necessidades do
estudo. Caso se identifique a necessidade de reelaborar as strings de busca, tais
modificações devem ser registradas para entendimento da evolução do plano do estudo.
Uma vez que as strings de busca estejam adequadas, parte-se para remoção de artigos
duplicados e aplicação dos procedimentos de inclusão/exclusão de artigos. Para
executar tais atividades, recomenda-se o uso de algum apoio ferramental. Neste
processo de avaliação dos artigos, destaca-se a importância de registro de possíveis
divergências e consenso entre os pesquisadores alocados às atividades de avaliação dos
artigos. O mesmo procedimento adotado para a inclusão/exclusão de artigos é
empregado também na avaliação de qualidade e hierarquização dos estudos primários
(caso necessário). Por fim, são aplicados os procedimentos de extração dos dados e
análise dos resultados obtidos. Quanto a análise dos resultados, esta também é
representada como sub atividade e permite a elaboração de tabelas para exibição dos
resultados obtidos, aplicação de métodos de análise estatística e plotagem de gráficos
(caso necessário), relato de possíveis ameaças ao estudo e escrita do relatório de
conclusão do estudo. Devido ao tamanho do sub diagrama Executar Piloto, este é
exibido no Apêndice V.
62
Figura 48 - Sub atividade Preencher Dados relacionados a Sumarização dos Resultados
Figura 49 - Sub atividade Avaliar Protocolo
Uma vez que a execução piloto do protocolo tenha obtido resultados
satisfatórios, este é armazenado em forma de baseline e parte-se para real execução do
protocolo. A diferença entre a execução piloto do protocolo e a execução real é uma
questão de escala, de modo que as mesmas atividades previstas para execução do piloto
também são previstas no sub diagrama relativo à execução do protocolo. Em seguida, os
pesquisadores alocados como revisores avaliam os artefatos produzidos pela execução
do protocolo. Mais uma vez, destaca-se a importância do registro da avaliação para
entendimento de possíveis modificações na forma como o protocolo foi executado. Por
fim, as duas últimas atividades do guia de apoio ao PCRSL prevêem a análise dos
resultados obtidos com a execução do estudo (seguindo o mesmo procedimento adotado
63
na execução piloto do protocolo) e o empacotamento de todos os artefatos produzidos
ao longo do planejamento e execução do estudo.
4.4 Inspeção dos Modelos Conceituais sobre Estudos Secundários e Guia de Apoio
A metodologia adotada para construção de ontologias, denominada Me-
thontology (FERNÁNDEZ et al., 1997), indica a elaboração de um documento que
contenha a descrição dos procedimentos e técnicas adotadas, os tipos de defeitos
identificados durante o processo de construção e as fontes de conhecimento adotadas
para avaliação dos modelos ontológicos. No entanto, ainda nota-se uma carência de
descrições mais detalhadas em como executar as atividades envolvidas nesta etapa.
Considerando a necessidade de avaliar os modelos conceituais e guia de apoio
constituintes do eSEE e a carência de detalhes em como proceder com as atividades de
revisão dos modelos, foi necessário elaborar uma estratégia que permitisse que a revisão
dos modelos fosse conduzida de maneira a garantir maiores níveis de corretude e
completude. Para isso, considerou-se a realização de inspeção nos artefatos produzidos.
Tendo como base o procedimento realizado por LOPES & TRAVASSOS (2009) para
inspeção dos modelos que descrevem estudos primários, a inspeção dos modelos que
descrevem estudos secundários foi realizada no contexto de uma disciplina de ESE,
onde nove alunos, dois de doutorado e sete de mestrado, obtiveram, durante um período
de três meses, contato com os principais tópicos de estudos primários e secundários.
Durante a disciplina, os alunos receberam como atividade, a elaboração e execução de
um protocolo de revisão sistemática na área de atributos de qualidade de casos de uso, o
que permitiu a esses alunos absorver os conceitos relacionados ao planejamento e
execução de estudos secundários. Além disso, imediatamente antes da atribuição das
atividades e artefatos para inspeção, realizou-se um treinamento, de modo a relembrar
os principais conceitos e as atividades ligadas ao PCRSL. Neste treinamento, abordou-
se também a arquitetura conceitual do ambiente eSEE, suas estruturas para
representação de conhecimento acerca de estudos primários e a motivação de expandir o
repositório de conhecimento do ambiente. Em seguida, foram apresentados os conceitos
que compõem a ontologia de estudos secundários e como estes foram organizados sob a
forma de sub ontologias. Após isto, os inspetores foram apresentados ao guia de apoio
ao PCRSL. Nesta etapa do treinamento, explicou-se o papel dos perfis de pesquisadores
envolvidos na condução do processo (coordenador, desenvolvedor, executor e revisor) e
64
as principais atividades executadas por cada papel. Por fim, foi realizado um
treinamento sobre o uso de técnicas de inspeção e o procedimento para relato de
discrepâncias dos artefatos. Para auxiliar os inspetores na inspeção na identificação de
possíveis defeitos nos artefatos, foi disponibilizada uma série de referências
bibliográficas sobre revisões sistemáticas.
Para realizar as atividades de inspeção, os inspetores foram divididos em três
equipes (Earth, Wind e Fire), cada uma contendo três integrantes. Cada equipe ficou
responsável pela avaliação de dois artefatos, conforme exibe a Tabela 3: (i) ontologia de
estudos secundários; (ii) guia de apoio; (iii) documento contendo os requisitos para
construção da ferramenta de apoio ao planejamento e execução de revisões sistemáticas.
A escolha na distribuição dos artefatos foi feita de forma que cada artefato fosse
avaliado por duas equipes (6 inspetores). No entanto, apesar de os inspetores terem sido
divididos em equipes, com exceção da equipe Earth, estes realizaram as inspeções ad-
hoc individualmente.
Uma vez que a estrutura do eSEE foi evoluída por meio da inclusão da ontologia
de estudos secundários e o guia de apoio, identificou-se a oportunidade de construir
uma ferramenta que apóie o planejamento e execução de revisões sistemáticas. Com
base no estudo das limitações de ferramentas existentes, propôs-se um conjunto de
requisitos adicionais para construção de serviços de apoio ao PCRSL (SANTO &
TRAVASSOS, 2010). Estes requisitos foram propostos de modo a focar na etapa de
planejamento da revisão e estabelecer mecanismos de comunicação com ferramentas
existentes para apoiar a etapa de execução da revisão. Desta forma, os inspetores
também foram incumbidos de inspecionar o documento de requisitos com o intuito de
capturar novas idéias para construção da ferramenta bem como avaliar a corretude e
completude dos requisitos. Maiores detalhes sobre os requisitos e a avaliação dos
mesmos são abordados no Capítulo 5.
Para avaliação da ontologia, foi considerada a seguinte taxonomia de defeitos:
(i) omissão de conceitos; (ii) omissão de descrição de conceitos; (iii) descrição incorreta
de conceitos; (iv) relacionamento incorreto entre conceitos; e (v) omissão de ontolo-
gias/sub-ontologias. Para o guia de apoio, foi considerada a seguinte taxonomia: (i)
omissão de atividades; (ii) nome equivocado de atividade; (iii) seqüenciamento equivo-
cado de atividades; e (iv) atividades que não fazem parte do processo. Por fim, para
avaliação do documento de requisitos, utilizou-se a seguinte taxonomia de defeitos: (i)
65
omissão – informação necessária não incluída; (ii) ambigüidade – informação
passível de ter múltiplas interpretações; (iii) inconsistência – informações conflitantes;
(iv) fato incorreto – informação que não é verdadeira para as condições especificadas;
e (v) informação estranha – informação desnecessária. Neste contexto, o termo
discrepância é utilizado para denominar os relatos feitos pelos inspetores, sendo que
uma discrepância pode se configurar como falso positivo ou defeito. Para o relato das
discrepâncias foram elaboradas planilhas eletrônicas, com o objetivo de padronizar os
relatos dos inspetores e facilitar a identificação de defeitos nos artefatos avaliados. Cada
planilha possuía espaço para descrição da discrepância identificada, espaço para
classificar a discrepância segundo as taxonomias descritas anteriormente, campo para
classificação da discrepância em leve/grave/catastrófica e espaço para indicação da(s)
referência(s) bibliográfica(s) utilizada(s) como subsídio para relato da discrepância.
Tabela 3 - Distribuição dos artefatos entre as equipes
Equipe Artefatos avaliados
Earth Guia de Apoio
Documento de Requisitos
Wind Ontologia
Documento de Requisitos
Fire Guia de Apoio
Ontologia
Tabela 4 - Discrepâncias e defeitos identificados na Ontologia de Estudos Secundários
Equipe Inspetor Omissão de
conceitos
Omissão de
descrição
de conceitos
Descrição
incorreta de
conceitos
Relacionamento
incorreto entre
conceitos
Omissão de
ontologias/sub-
ontologias
Outros
Wind
Inspetor 4 0 (0) 31 (31) 0 (0) 5 (2) 0 (0) 0 (0)
Inspetor 5 0 (0) 20 (20) 0 (0) 8 (6) 0 (0) 0 (0)
Inspetor 6 1 (1) 5 (5) 1 (0) 2 (2) 6 (0) 0 (0)
Fire
Inspetor 7 3 (2) 1 (1) 4 (4) 2 (1) 0 (0) 1 (1)
Inspetor 8 3 (1) 0 (0) 0 (0) 1 (1) 0 (0) 0 (0)
Inspetor 9 0 (0) 45 (45) 0 (0) 1 (1) 0 (0) 4 (0)
Tabela 5 - Discrepâncias e defeitos identificados no guia de apoio ao PCRSL
Equipe Inspetor Omissão de
atividade
Nome
equivocado de
atividade
Sequenciamento
equivocado entre
atividades
Atividades que
não fazem parte
do processo
Outros
Earth ------------ 8 (8) 2 (2) 16 (8) 0 (0) 0 (0)
Fire
Inspetor 7 1 (1) 1 (1) 5 (5) 1 (1) 0 (0)
Inspetor 8 5 (5) 0 (0) 1 (1) 0 (0) 0 (0)
Inspetor 9 1 (1) 3 (0) 0 (0) 0 (0) 6 (5)
Após o prazo de uma semana para realização das atividades de inspeção, foi
dado início à atividade de discriminação de defeitos. O número de discrepâncias e o
número de defeitos reportados pelos inspetores na Ontologia de Estudos Secundários e
no guia de apoio ao PCRSL são discriminados nas Tabelas 4 e 5 (os valores entre
parênteses correspondem ao número de defeitos em relação ao número de discrepâncias
por categoria). As discrepâncias relacionadas ao documento de requisitos para
66
construção da ferramenta de apoio ao planejamento e execução de estudos secundários
serão abordadas no Capítulo 5. Em relação à analise da ontologia e do guia de apoio, a
primeira etapa da discriminação teve como objetivo a filtragem dos dados, com o intuito
de evitar que discrepâncias reportadas por mais de um pesquisador fossem
contabilizadas mais de uma vez. Após esta etapa, o procedimento para descarte de
discrepâncias se deu a partir da avaliação dos itens reportados em conjunto com um
especialista (doutor) em ESE.
Ao término da análise, foi identificado um total de 59 defeitos na ontologia de
estudos secundários (a distribuição dos defeitos entre as categorias é apresentada na
Tabela 6), 26 defeitos no guia de apoio e 9 defeitos no documento de requisitos. Os
defeitos encontrados na ontologia foram, em sua maioria, motivados pela omissão de
descrição de conceitos (45 defeitos). Ainda em relação a este tipo de defeito, o Inspetor
9 reportou cada defeito isoladamente, enquanto que o Inspetor 7 reportou as omissões
como um único defeito. Estes defeitos possuem baixo impacto e não ocasionam
mudanças na organização dos conceitos da ontologia. O único defeito classificado como
Outros considera que a propriedade descrição dos conceitos Questão Primária e
Questão Secundária deveria ser movido para o conceito Questão de Pesquisa, uma vez
que tal descrição é compartilhada por ambos os tipos de questões. Já em relação aos
defeitos considerados mais impactantes em termos de mudanças na organização de
conceitos, podemos citar aquele que identificou a omissão de conceitos e
relacionamento incorreto de conceitos que descrevem as hipóteses de uma questão de
pesquisa. Ao analisar a Figura 50.a, observa-se que, na organização antiga, não havia
conceitos que representassem hipóteses nulas e alternativas. Outro ponto de destaque é
o fato de o conceito Hipótese estar diretamente ligado ao conceito Objetivo de Pesquisa
por uma relação de composição, sendo que não há obrigatoriedade de existência de
hipóteses em uma RSL. Além disso, as propriedades que definem o objetivo de uma
questão de pesquisa sob o paradigma GQM (Goal, Question, Metric) (BASILI et al.,
1994) estavam sendo consideradas no conceito Objeto de Estudo. A análise dos
defeitos identificou que uma hipótese pode ser derivada a partir de diferentes questões
de pesquisa e não a partir do objetivo da pesquisa. Além disso, no contexto de uma
pesquisa científica, o conceito Questão de Pesquisa não está relacionado apenas ao
conceito Objetivo de Pesquisa, de modo que a nova ligação entre estes conceitos se dá
por um relacionamento de agregação. Por fim, foram incluídos os conceitos que
67
descrevem hipóteses nula e alternativa e propriedades que organizam o objetivo de uma
questão de pesquisa sob o paradigma GQM, conforme ilustra a Figura 50.b. Para evitar
se alongar na descrição de todos os defeitos encontrados, as planilhas contendo as os
defeitos de cada artefato inspecionado são apresentadas no Apêndice VI.
Figura 50 - Comparação de modelos antes e após a inspeção da ontologia
Tabela 6 - Distribuição dos defeitos na ontologia
Sub ontologia/Tipo de Defeito
Descrição
Incorreta de
Conceitos
Omissão de
Conceitos
Omissão de
Descrição de
Conceitos
Omissão
de
Ontologia
Relacionamento
Incorreto entre
Conceitos
Outros
Estrutura do Estudo 1 1 0 0 0 1
Extração de Dados 0 0 3 0 1 0
Formulação de Questão de
Pesquisa 0 2 4 0 3 0
Procedimento Metodológico 2 1 15 0 0 0
Protocolo de Revisão Sistemática 0 0 5 0 0 0
Seleção de Estudos 0 0 8 0 1 0
Seleção de Fonte de Estudos 0 0 4 0 1 0
Sumarização dos Resultados 0 0 6 0 1 0
Em relação ao guia de apoio, a maior parte dos defeitos encontrados
(apresentados na Tabela 7) se deu pelo sequenciamento incorreto de atividades (13
defeitos), sendo a maioria concentrada nos diagramas que representam a definição da
questão de pesquisa e a execução da revisão. Algumas atividades apresentavam
ausência de rótulos nas condições de desvios, de modo que estes defeitos foram
classificados como Outros. Os defeitos classificados como ausência de atividades se
relacionam a: (i) incluir notas no protocolo visando informar mudanças realizadas no
mesmo; (ii) incluir atividade que considera a avaliação da precisão das strings de busca
elaboradas; e (iii) dividir em duas a atividade que considera a necessidade de
implementar melhorias nos critérios de inclusão e exclusão (uma para critérios de
68
inclusão e outra para critérios de exclusão). Um exemplo de defeito ocasionado pelo
seqüenciamento equivocado de atividades é ilustrado nas Figuras 51.a (antes da
inspeção) e 51.b (após a inspeção). Ao analisar as figuras, percebe-se que a definição de
hipóteses só pode ocorrer após a elaboração das questões de pesquisa que guiaram a
revisão. Por fim, os defeitos identificados nas inspeções foram devidamente corrigidos,
incorporando novos conceitos, propriedades e relacionamentos, o que contribuiu
significativamente para aprimorar a corretude e completude dos artefatos inspecionados.
Desta forma, os modelos disponibilizados na Web encontram-se devidamente corrigidos
e disponíveis à comunidade.
Figura 51 - Comparação entre versões do guia antes e depois da inspeção
Tabela 7 - Distribuição dos defeitos no guia de apoio ao PCRSL
Diagrama/Tipo de Defeito
Atividade
que Não Faz
Parte do
Processo
Nome
Equivocado
de
Atividade
Sequenciamento
Equivocado de
Atividade
Omissão
de
Atividade
Outros
Processo de Condução de Revisões Sistemáticas 1 0 1 0 0
Preencher Dados Relacionados a Definição e
Questão de Pesquisa 0 1 4 0 1
Preencher Dados Relacionados a Seleção de
Fonte de Estudos 0 0 1 0 1
Preencher Dados Relacionados a Seleção de
Estudos 0 0 1 1 0
Realizar Análise dos Resultados 0 1 1 0 0
Preencher Dados Relacionados a Sumarização
dos Resultados 0 0 1 1 1
Executar Revisão 0 0 4 4 1
69
4.4.1 Experiências obtidas com a Aplicação do Método de Inspeção dos Modelos Conceituais e Guia de Apoio
Do ponto de vista de garantir maiores níveis de corretude e completude dos
modelos ontológicos e do guia de apoio, o procedimento de inspeção se mostrou
adequado ao objetivo inicial de qualidade. Além disso, a aplicação do procedimento
permitiu observar alguns pontos que podem, no futuro, facilitar o processo de
desenvolvimento de ontologias. Tais impressões foram capturadas por meio de
entrevistas informais com os inspetores após o término das atividades de inspeção.
Identificou-se que deve haver uma preocupação com o número de sub ontologias
presentes em um modelo de ontologia. Apesar da Ontologia de Estudos Secundários ter
sido dividida em vários sub modelos, visando facilitar a visualização dos mesmos, os
inspetores comentaram que um número excessivo de sub modelos exigia a constante
consulta aos demais modelos para o entendimento da ontologia como um todo. No
entanto, acredita-se que o elevado número de sub modelos esteja diretamente
relacionado à complexidade da ontologia, de modo que a diminuição do número de sub
modelos poderia afetar negativamente a expansão da ontologia e a compreensão dos
relacionamentos entre os conceitos. Outro fato observado foi que, por ter optado por
conduzir a inspeção em grupo, a equipe Earth reportou 26 discrepâncias no guia de
apoio, diferentemente dos inspetores 7, 8 e 9, que reportaram em média 8 discrepâncias
no artefato. No entanto, a equipe Earth apresentou também maior número de falsos
positivos (8 itens marcados como falso positivo), isto é, discrepâncias que não
correspondiam a defeitos reais. Este fato pode levar a consideração de que a realização
de atividades de inspeção em grupo tende a identificar um número maior de
discrepâncias. No entanto, esta é uma hipótese que deve ser posta sob prova.
Conforme mencionado anteriormente, a elaboração da Ontologia de Estudos
Secundários e do guia de apoio faz parte da iniciativa do desenvolvimento de uma
ferramenta que possa apoiar o PCRSL. Após o término das atividades de análise de
discrepâncias, iniciou-se o desenvolvimento da ferramenta. Durante esta etapa, foram
identificados novos defeitos na ontologia, o que indica que, mesmo os inspetores terem
tido contato durante 3 meses com os principais conceitos de estudos primários e
secundários, não foi possível identificar todos os defeitos existentes, de modo que os
modelos sofreram algumas evoluções ao longo do tempo. Na Figura 52.b, que
representa a versão final da sub ontologia Estudos Selecionados, foram incluídos novos
conceitos que descrevem o procedimento para resolução de divergência entre
70
pesquisadores, critérios para hierarquização e as características qualitativas e
quantitativas de estudos primários. No entanto, a inclusão destes conceitos não foi
motivada a partir do reporte de defeitos por parte dos inspetores, ou seja, os inspetores
não conseguiram identificar a necessidade destes novos conceitos. Na Figura 52.a, é
possível observar a organização antiga (anterior ao procedimento de inspeção) da sub
ontologia. Já as demais diferenças entre as duas versões da sub ontologia foram
motivadas pela identificação de defeitos por parte dos inspetores.
Figura 52 - Comparação de versões da sub ontologia Estudos Selecionados
Dentre as ameaças ao procedimento de inspeção, podemos citar a falta de
experiência por parte dos inspetores a respeito de metodologias para construção de
ontologias e a possível ausência de critérios para classificação de discrepâncias. Neste
71
sentido, o inspetor 9 teve dificuldade em classificar algumas das discrepâncias
identificadas na ontologia e no guia de apoio (que foram classificadas como Outros nas
Tabelas 4 e 5). Além disso, nenhum dos pesquisadores era especialista em RSL. Desta
forma, há a necessidade de refinar o procedimento de inspeção proposto. Para alcançar
este objetivo, pretende-se elaborar um questionário que vise capturar de forma mais
detalhada as impressões dos inspetores e identificar oportunidades de melhoria para o
procedimento de inspeção. Futuramente, planeja-se também realizar novas atividades de
inspeção dos modelos tendo como participantes especialistas em RSL.
4.5 Conclusão
Executar um estudo em ES requer uma série de cuidados, em especial a neces-
sidade de um rigoroso planejamento considerando amplamente os detalhes de escolha
das estratégias de estudo, ou como também são denominados os diferentes métodos
experimentais aplicáveis. Para evitar que a falta de tratamento desses cuidados ameace a
validade do estudo, pode-se pensar na disponibilização de mecanismos de representação
de conhecimento que contemplem os principais detalhes que compõem as diferentes
estratégias de estudos. Neste sentido, o ambiente eSEE disponibiliza um repositório de
conhecimento sobre experimentação em ES, composto por um dicionário de termos e
ontologias. Com o intuito de aumentar a cobertura desse repositório de conhecimento,
este capítulo apresentou uma iniciativa de agregação de conhecimento através da
elaboração de uma ontologia de estudos secundários e um guia de apoio ao PCRSL. A
construção dos modelos ontológicos e do guia de apoio baseou-se nas principais
literaturas que abordassem estudos secundários. Além disso, os artefatos construídos
foram inspecionados com intuito de garantir maiores níveis de corretude e completude.
Acredita-se que a disponibilização dos modelos ontológicos e do guia de apoio,
elaborados com um nível maior de detalhes em relação a trabalhos anteriores, possam
facilitar a aplicação de estudos secundários em Engenharia de Software. Assim, no
Capítulo 5, será apresentado o próximo passo dado na evolução do ambiente eSEE, que
se deu na direção de propor um conjunto de serviços de apoio ao planejamento,
execução e empacotamento de estudos secundários, tendo como base as limitações
identificadas nas tecnologias de apoio a estudos secundários existentes e as estruturas
para representação de conhecimento sobre revisões sistemáticas.
72
5 Ferramenta de Apoio ao Planejamento de
Revisões Sistemáticas da Literatura
Neste capítulo, é apresentada a abordagem adotada para
construção de uma ferramenta de apoio ao planejamento de
revisões sistemáticas da literatura. Além da abordagem, são
apresentadas também algumas das funcionalidades oferecidas pela
ferramenta.
5.1 Introdução
A partir da identificação de limitações nas ferramentas de apoio ao planejamento
e execução de estudos secundários (ver Capítulo 3) e na evolução do repositório de
conhecimento de experimentação em Engenharia de Software, descritas no Capítulo 4,
foi possível propor um conjunto de requisitos adicionais para evolução do ambiente
eSEE, de modo a oferecer funcionalidades que apóiem o planejamento, execução e
empacotamento de RSL, tendo como foco, pesquisadores inexperientes nesta
abordagem. Assim, o segundo passo para a evolução do eSEE se deu na direção de
propor uma arquitetura conceitual e um conjunto de requisitos para guiar a construção
de uma ferramenta de apoio ao planejamento, execução e empacotamento de RSL. Para
garantir maiores níveis de corretude e completude, os requisitos foram inspecionados,
de modo que só após a consolidação destes é que partiu-se para a construção dos
serviços de apoio ao planejamento de RSL.
Este capítulo está organizado da seguinte forma: a Seção 5.2 apresenta a
abordagem proposta para organização dos serviços de apoio ao planejamento, execução
e empacotamento de RSL; na Seção 5.3, são apresentados os requisitos elicitados,
arquitetura e principais funcionalidades da ferramenta construída; por fim, a Seção 5.4
apresenta a conclusão do capítulo.
5.2 Abordagem Proposta
Além de servir como fonte de consulta para pesquisadores que desejem interar-
se sobre a terminologia do domínio de revisões sistemáticas, a Ontologia de Estudos
73
Secundários e o guia de apoio ao Processo de Condução de Revisões Sistemáticas da
Literatura (PCRSL) também podem ser empregados como insumos para a construção de
um ambiente que apóie o planejamento e execução de revisões sistemáticas. Com isto,
pesquisadores em ES, principalmente aqueles inexperientes no planejamento deste tipo
de estudo, podem ser beneficiados. Conforme citado anteriormente (ver Capítulo 1), um
dos aspectos mais importantes do PCRSL é a definição do plano de estudo (através da
elaboração do protocolo de revisão sistemática). Durante o preenchimento do protocolo,
existem aspectos relacionados a tomadas de decisão que não podem ser negligenciados,
caso contrário o estudo terá alta probabilidade de ser inviabilizado. Para que isto não
ocorra, é importante que o pesquisador tenha conhecimento sobre todos os conceitos
envolvidos no processo. Desta forma, o repositório de conhecimento de experimentação
em ES poderia ser explorado no sentido de disponibilizar o conhecimento adequado ao
pesquisador para que este possa preencher o plano de estudo. Assim, uma ferramenta
responsável pelo planejamento de estudos secundários pode recuperar informações do
repositório e, através de uma sequência de questionamentos e opções de resposta, guiar
os pesquisadores na elaboração do plano que guiará o estudo. Embora a complexidade
do processo dificulte a automatização da elaboração do protocolo por completo,
acredita-se que geração deste parcialmente preenchido seja de grande utilidade. Com
isto, espera-se uma diminuição no tempo necessário para criação do plano de revisão
sistemática por parte de pesquisadores em ES.
Conforme mencionado no Capítulo 2, a estrutura conceitual do eSEE é dividida
em três camadas: (i) Meta-eSEE; (ii) eSEE Configurado; e (iii) eSEE. Na abordagem
proposta nesta dissertação, a primeira camada (Meta-eSEE) é evoluída por meio da
inclusão da Ontologia de Estudos Secundários no repositório de conhecimento de
experimentação em ES. Com isso, as demais camadas poderão utilizar a ontologia para
o planejamento e execução de estudos secundários. Em relação às camadas eSEE
Configurado e eSEE, estas são evoluídas através da construção de uma ferramenta
contendo dois componentes: componente de apoio ao planejamento e componente de
apoio a execução. A nova organização conceitual do eSEE, abrangendo a abordagem
proposta destacada por meio de um retângulo tracejado, é exibida na Figura 53,
enquanto que o relacionamento entre esses componentes e o processo é exibido na
Figura 54.
74
Figura 53 - Estrutura Conceitual eSEE
Figura 54 - Componentes de Apoio ao Processo de Condução de Revisões Sistemáticas
O componente de planejamento, que atua na camada eSEE Configurado,
funciona como um meta-ambiente configurável, sendo responsável por apoiar os
pesquisadores no preenchimento do protocolo da revisão sistemática e na instanciação
de ambientes de execução adequados para o protocolo descrito. Este componente
recebeu maior enfoque nesta dissertação, uma vez que a etapa do processo
planejamento é crítica para o sucesso da revisão e que, através de revisão informal da
literatura, observou-se a carência de apoio ferramental que apoiasse fortemente esta
etapa.
Tendo como base o repositório de conhecimento estruturado pelas ontologias, o
componente consulta o repositório para disponibilizar ao pesquisador conhecimento
sobre as principais características da revisão sistemática relacionadas as tomadas de
decisão na etapa planejamento. Assim, a partir do fornecimento de respostas pelo
pesquisador, o componente é capaz de disponibilizar um template do protocolo da
revisão sistemática parcialmente preenchido e gerar um arquivo de configuração
contendo informações de acordo com as decisões tomadas ao longo do planejamento do
protocolo. O arquivo de configuração pode então ser passado para o componente de
75
execução, de modo que este componente irá fornecer apoio à execução da revisão
seguindo os procedimentos adotados durante o planejamento. Isto permite que os
componentes de planejamento e execução possam existir independentemente, de
maneira que estes se comuniquem apenas através do arquivo de configuração gerado
pelo componente de planejamento. No futuro, espera-se que os arquivos de
configuração criados pelo componente de planejamento possam ser utilizados como
insumos para alimentação do repositório de conhecimento de experimentação em ES,
conforme exibe a Figura 55, que ilustra o relacionamento entre o ambiente eSEE e o
Repositório de Conhecimento de Experimentação em ES.
Figura 55 - Versão estendida do repositório de conhecimento
Com o intuito de apoiar o preenchimento do protocolo da revisão sistemática, o
componente de planejamento provê serviços que permitem ao pesquisador identificar e
realizar modificações e controlar as diferentes versões do protocolo da revisão. Estes
serviços são necessários, pois, uma vez que o processo de elaboração do protocolo
ocorre de maneira evolutiva, é importante que tais modificações sejam identificadas e
registradas, visando entender as decisões tomadas ao longo do tempo de vida do proto-
colo da revisão sistemática. Por fim, também é fornecido apoio às atividades de revisão
do protocolo.
Embora faça parte da abordagem conceitual, devido à questões de tempo, o
componente de execução, não foi alvo de trabalho no escopo desta dissertação, de
modo que a construção deste componente se dará em uma etapa posterior. No entanto,
76
houve uma preocupação em elicitar os requisitos que guiaram a construção do
componente de execução. Desta forma, este componente deverá conter um conjunto de
serviços que permitam aos pesquisadores executar a revisão sistemática de forma
cooperativa e distribuída. Para isto, deverão estar disponíveis serviços de comunicação
(mensagens, chats e fóruns), distribuição de artigos e o empacotamento dos artefatos
produzidos ao longo da execução de uma revisão. Para o desenvolvimento dos serviços
ligados ao componente de execução, pretende-se integrar tecnologias e/ou ferramentas
identificadas através de revisão de literatura que possam ser reaproveitadas e que não
afetem a arquitetura atual do eSEE.
Durante a revisão da literatura realizada para investigação de tecnologias que
apoiassem de alguma forma a condução de estudos secundários, observou-se que,
principalmente na área da medicina, os pesquisadores envolvidos na coleta e análise de
dados de estudos de interesse para a revisão utilizam um mecanismo de medição de
conformidade entre resultados de avaliações. O método utilizado é o Fleiss Kappa
(FLEISS, 1971), um método estatístico que considera um número fixo de participantes
atribuindo categorias a um conjunto de itens posto sob avaliação. Com base em uma
fórmula matemática, o método é capaz de gerar um valor k no intervalo -∞ < k ≤ 1, que
serve como indicador geral sob o nível de conformidade na aplicação de um processo de
classificação de itens. LANDIS & KOCH (1977) propõem um modelo de interpretação
do valor k, conforme exibe a Tabela 8. Assim, considerando o cenário onde vários
pesquisadores participam da etapa de avaliação de estudos, aplicando os critérios de
inclusão/exclusão (e também nos casos onde opta-se por aplicar critérios para avaliação
de qualidade), este método estatístico poderá apontar possíveis desvios na aplicação de
critérios definidos no planejamento da revisão sistemática, permitindo aos
pesquisadores definir procedimentos para resolução de divergências na avaliação dos
estudos considerados no contexto da revisão em execução. Assim, no momento em que
for construído o componente de apoio à execução, pretende-se oferecer algum tipo de
apoio a aplicação deste método.
Tabela 8 - Modelo de interpretação do método Fleiss Kappa
Valor k Interpretação
k < 0.0 Pobre
0.0 < k ≤ 0.2 Baixo
0.2 < k ≤ 0.4 Aceitável
0.4 < k ≤ 0.6 Moderado
0.6 < k ≤ 0.8 Substancial
0.8 < k ≤ 1.0 Quase perfeito
77
A fim de organizar a distribuição de tarefas ligadas ao PCRSL, os componentes
de planejamento e execução classificam os pesquisadores em ES nos seguintes papéis:
(i) coordenador da revisão – responsável pela distribuição de tarefas e coordenação dos
demais pesquisadores; (ii) desenvolvedor do protocolo – responsável pelo planejamento
da revisão; (iii) executor do protocolo – responsável por executar o protocolo, de forma
a obter artigos que descrevam estudos primários, aplicar critérios de
inclusão/exclusão/avaliação de qualidade, extrair e analisar dados obtidos de estudos
primários; e (iv) revisor – responsável por auditar o protocolo e produtos produzidos a
partir da sua execução.
Para guiar a construção dos componentes de planejamento e execução, um
documento contendo um conjunto de requisitos funcionais foi elaborado, de maneira
que a independência entre os componentes de planejamento e execução permitiu que a
elicitação de requisitos para os componentes também se desse de forma independente.
Assim, o documento também foi inspecionado com o intuito de identificar defeitos e
possíveis novos requisitos a serem contemplados com base em sugestões feitas pelos
inspetores. A inspeção do documento ocorreu em conjunto com a inspeção da ontologia
e do guia de apoio, de modo que a inspeção do documento ficou a cargo das equipes
Earth e Wind, e os procedimentos adotados na inspeção dos requisitos foram os mesmos
aplicados aos modelos ontológicos e guia de apoio.
De forma semelhante a inspeção das ontologias e do guia de apoio (ver Capítulo
4), no contexto da inspeção do documento de requisitos, novamente, o termo
discrepância é utilizado para denominar os relatos feitos pelos inspetores, sendo que
uma discrepância pode se configurar como falso positivo ou defeito. No entanto, para
classificação das discrepâncias em relação aos requisitos, utilizou-se uma taxonomia
diferente da utilizada na inspeção dos modelos ontológicos e guia de apoio: (i) omissão
– informação necessária não incluída; (ii) ambigüidade – informação passível de ter
múltiplas interpretações; (iii) inconsistência – informações conflitantes; (iv) fato
incorreto – informação que não é verdadeira para as condições especificadas; e (v)
informação estranha – informação desnecessária. Após a análise das discrepâncias, foi
considerado um conjunto de 14 defeitos, conforme expressam as Tabelas 9 e 10. Na
Tabela 9, os valores entre parênteses correspondem ao número de defeitos em relação
ao número de discrepâncias por categoria, sendo que o primeiro valor contido nos
78
parênteses corresponde ao número de defeitos identificados no componente de
planejamento e o segundo relativo ao componente de execução.
Tabela 9 - Distribuição de discrepâncias e defeitos relativas ao documento de requisitos
Equipe Inspetor Omissão Ambiguidade Inconsistência Fato incorreto Informação
estranha
Earth ------------ 7 (5, 2) 0 (0, 0) 0 (0, 0) 0 (0, 0) 1 (1, 0)
Wind
Inspetor 4 7 (5, 2) 0 (0, 0) 0 (0, 0) 1 (1, 0) 0 (0, 0)
Inspetor 5 4 (2, 2) 3 (2, 1) 0 (0, 0) 0 (0, 0) 1 (1, 0)
Inspetor 6 4 (2, 2) 4 (3, 1) 0 (0, 0) 0 (0, 0) 2 (2, 0)
Tabela 10 - Distribuição de defeitos no documento de requisitos por componente Componente/Tipo de
Defeito Omissão Ambiguidade Inconsistência Fato Incorreto
Informação
Estranha
Planejamento 4 4 0 1 1
Execução 2 2 0 0 0
Quanto aos defeitos do Componente de Planejamento, os da categoria Omissão
tratam a respeito de: (i) definição dos papéis dos usuários que atuam como coordenador,
desenvolvedor e revisor de protocolos de RSL; (ii) armazenamento do pesquisador
responsável e tempo gasto para realização de cada atividade; e (iii) definição do item
Comparison, da estrutura PICO, como obrigatório nos casos em que tenha-se optado
por conduzir uma Revisão Sistemática ao invés de uma quasi Revisão Sistemática. O
defeito considerado como Informação Estranha trata dois requisitos que estavam
duplicados e, por fim, os defeitos da categoria Ambiguidade tratam as funcionalidades
de comunicação entre pesquisadores, definição de um possível mecanismo de controle
de versão de artefatos, definição de conceitos que tratam a validade interna e externa do
estudo e definição de procedimentos para resolução de possíveis divergências entre
pesquisadores. A descrição final dos requisitos funcionais do componente de
planejamento é apresentada na Tabela 11.
Tabela 11 - Requisitos para o componente de planejamento
# Requisitos
RF01 O software deve permitir a classificação do estudo secundário em revisão sistemática ou quasi
revisão sistemática
RF02 Para os casos em que o estudo secundário for do tipo Revisão Sistemática, o preenchimento do
conceito Comparison, da estrutura PICO, deverá ser obrigatório
RF03 O software deve organizar os pesquisadores por perfil de uso (gerente da revisão – responsável
por atribuir tarefas aos pesquisadores; desenvolvedor do protocolo – responsável pelo
preenchimento do protocolo da revisão; e revisor – responsável pela avaliação e aprovação do
protocolo da revisão)
RF04 O software deve permitir que o desenvolvedor do protocolo especifique mecanismos de
resolução de divergência entre revisores na avaliação de artigos.
RF05 O software deve permitir o armazenamento de laudos de execução piloto do protocolo da revisão
sistemática
RF07 O software deve permitir ao desenvolvedor do protocolo a definição de um conjunto de critérios
que permita avaliar a validade interna (relacionamento tratamento-resultado), externa
(generalização do resultado), de construto (relação entre teoria e observação) e de conclusão
(análise estatística) da revisão
79
RF08 O software deve permitir o armazenamento do pesquisador responsável por executar determinada
tarefa e o tempo gasto na atividade
RF09 O software deve oferecer a possibilidade de construir strings de busca a partir da estrutura PICO.
No entanto, o desenvolvedor do protocolo poderá modificar a string de busca gerada
RF10 O software deve ser capaz de exportar as informações do plano da revisão através de um
documento Word/RTF parcialmente preenchido ou XML.
RF11 O software deve permitir que o desenvolvedor do protocolo informe modificações no protocolo
da revisão (contendo justificativas de modificação), de forma que se possa manter um controle
sobre a evolução do protocolo
RF12 O software deve permitir a definição de procedimentos e critérios para inclusão/exclusão de
artigos que relatem estudos primários
RF13 O software deve permitir, caso seja necessário, a definição de procedimentos para avaliação de
qualidade de artigos relatando estudos primários
RF14 O software deve oferecer ao desenvolvedor do protocolo a escolha de critérios pré-definidos para
avaliação de qualidade de artigos relatando estudos (DARE). No entanto, o software deve
permitir que o desenvolvedor do protocolo defina novos critérios (podendo ser quantitativos e/ ou
qualitativos)
RF15 O software deve ser capaz de exibir textos de ajuda para a elaboração do protocolo de revisão
sistemática
RF16 O software deve prover mecanismos de comunicação entre os envolvidos na elaboração do
protocolo (desenvolvedor do protocolo e revisor) através de fórum de discussão e salas de chat
RF17 O software deve permitir a organização dos usuários por áreas de pesquisa
RF18 O software deve permitir que o desenvolvedor do protocolo possa definir os dados a serem
extraídos de cada artigo que relate estudos primários. Além disso, deve-se permitir também a
definição do procedimento a ser adotado para extração dos dados
RF19 O software deve permitir ao desenvolvedor do protocolo a definição de apoio ferramental a ser
empregado durante a execução do protocolo
RF20 O software deve permitir que o pesquisador que atue como revisor possa avaliar o plano de
revisão sistemática e emitir laudos de avaliação
RF21 O software deve empacotar os produtos criados durante a elaboração do plano de revisão
sistemática (protocolo, ontologia laudos de execução piloto e laudos de avaliação do revisor)
RF22 O software deve permitir que o objeto de estudo da revisão seja descrito a partir da abordagem
GQM (Goal Question Metric).
RF23 O software deve permitir que o desenvolvedor do protocolo defina critérios e procedimentos para
seleção de bases de dados
RF24 O software deve, caso seja possível/necessário, permitir ao desenvolvedor do protocolo a
definição de métodos estatísticos para análise de dados e execução de meta-análise
RF25 O software deve permitir o cadastro de referência de artigos de controle (estes possivelmente
serão utilizados como base para avaliação da sensibilidade de strings de busca)
RF26 O software deve permitir o cadastro de bases de dados a serem avaliadas e as bases selecionadas
para servir como fonte de estudos primários
RF27 O software deve permitir, caso seja possível/necessário, que critérios e procedimentos para
hierarquização de estudos primários sejam definidos
Em relação ao componente de execução, fora identificados quatro defeitos,
sendo dois relativos a Omissão e dois a Ambiguidade. Estes defeitos abordaram
questões como ausência de definição do papel do pesquisador que atua como executor
do protocolo, a especificação dos mecanismos de comunicação entre os pesquisadores, a
ausência do laudo de execução piloto do protocolo de revisão sistemática no pacote do
estudo e na definição do mecanismo de colaboração entre os pesquisadores. Assim, os
requisitos foram corrigidos e encontram-se disponíveis na Tabela 12. Entretanto,
conforme mencionado anteriormente, o foco maior desta dissertação se deu na
80
especificação do componente de planejamento, de modo que no momento em que for
construído o componente de execução, deve-se realizar uma nova análise sob estes
requisitos.
Tabela 12 - Requisitos para construção do componente de execução
# Requisitos
RF01 O software deve organizar os pesquisadores por perfil de uso (gerente da revisão – responsável
por atribuir tarefas aos pesquisadores; executor do protocolo – responsável pela aplicação das
strings de buscas, avaliação dos artigos identificados, extração de dados e sumarização do
estudo; e revisor – responsável pela avaliação e aprovação do protocolo da revisão)
RF02 O software deve permitir que o desenvolvedor do protocolo defina uma estratégia de distribuição
de artigos entre executores do protocolo
RF03 O software deve ser capaz de importar documentos XML que representam as decisões tomadas
durante o planejamento de revisões sistemáticas
RF04 O software deve permitir que a execução do protocolo seja feita de forma colaborativa, de forma
que a avaliação de artigos (identificados após a aplicação das strings de busca) seja distribuída
entre os pesquisadores
RF05 O software deve prover mecanismos de comunicação entre os envolvidos na execução do
protocolo (executor do protocolo e revisor), através de fórum e chats
RF06 O software deve armazenar arquivos que contenham lista de referências bibliográficas
RF07 O software deve auxiliar a distribuição de artigos entre os pesquisadores que atuem como
executor do protocolo. Esta distribuição deve levar em conta a restrição de que um pesquisador
não possa avaliar um artigo de sua autoria
RF08 O software deve registrar o pesquisador responsável pela avaliação de um documento
RF09 O software deve armazenar os produtos produzidos pela execução do protocolo. A estrutura do
pacote da revisão é composta de: (i) arquivo contendo referências de artigos obtidos após
aplicação de strings de busca; (ii) arquivo contendo referências de artigos selecionados após
aplicação dos critérios de inclusão/exclusão; (iii) formulário contendo a pontuação dos artigos
com base nos critérios de avaliação de qualidade definidos no protocolo (requerido caso tenha se
optado por avaliar a qualidade de estudos primários); (iii) protocolo da revisão; (iv) laudos de
avaliação da execução da revisão, incluindo execuções piloto; (v) formulário contendo os dados
extraídos de cada estudo primário incluídos para análise; e (vi) relatório da execução da revisão.
Em virtude da ferramenta de apoio a ser utilizada durante a análise dos artigos, um ou mais
produtos podem estar agrupados em um único arquivo.
RF10 O software deve permitir que o pesquisador que atue como revisor possa avaliar os produtos
produzidos pela execução da revisão sistemática e emitir laudos de avaliação
RF11 O software deve ser capaz de avaliar a sensibilidade de uma string de busca
RF12 O software deve fornecer apoio à utilização do método estatístico Kappa, de modo a calcular o
índice de concordância entre os pesquisadores. Caso o índice seja inferior a 0.61, deve ser
emitido um aviso aos pesquisadores.
RF13 O software deve permitir a classificação de artigos com base em critérios de inclusão/exclusão e
critérios para avaliação de qualidade (caso tenha se optado por avaliar a qualidade dos estudos)
5.3 Arquitetura e Funcionalidades do Componente de Planejamento
Para construção do Componente de Planejamento foram utilizadas três
tecnologias: (i) joomla/Projectfork; (ii) jboss seam; e (iii) jbpm. Estas tecnologias
foram selecionadas por oferecerem a oportunidade de reaproveitar funcionalidades
previamente construídas, por apresentarem facilidade na construção de novas
funcionalidades e por apresentarem uma estrutura que permite construir funcionalidades
81
sob uma abordagem de processos de negócio. Maiores detalhes a respeito do
funcionamento destas tecnologias estão disponíveis no Apêndice II desta dissertação.
Ao analisarmos as características do planejamento de uma revisão sistemática, é
possível tratá-la como um projeto, uma vez que o plano da revisão é exclusivo,
temporário, iterativo, executado por pessoas e possui recursos limitados (PMI, 2011).
Assim, identificou-se a oportunidade de uso do framework Joomla (JOOMLA, 2011)
em conjunto com o componente Projectfork (PROJECTFORK, 2011). Projectfork atua
como um sistema gerenciador de projetos, apoiando o planejamento e acompanhamento
de atividades atribuídas a projetos. Com isso, o coordenador da revisão pode contar com
funcionalidades que o auxiliem na distribuição e controle de atividades e comunicação
com os pesquisadores envolvidos na elaboração e revisão do protocolo de revisão
sistemática. No entanto, por não ser orientado a workflow, Joomla/Projectfork não é
suficientemente adequado para conduzir a elaboração do protocolo de revisão
sistemática com base no guia de apoio ao Processo de Condução de Revisões
Sistemáticas da Literatura (PCRSL) proposto por esta dissertação. Desta forma, foi
construída uma ferramenta com o intuito de superar esta limitação.
Visando direcionar os pesquisadores no planejamento da revisão sistemática e
disponibilizar o protocolo do estudo parcialmente preenchido, foi construída uma
ferramenta baseada em workflow, denominada Secondary Study Planner (SSPlan), de
forma que esta ferramenta possa executar uma instância do processo descrito pelo guia
de apoio ao PCRSL. Na construção da SSPlan foi adotado o framework Web JBoss
Seam (SEAM, 2011) e a tecnologia de workflow JBPM (Java Business Process
Management) (JBOSS, 2011a), que permite a modelagem de processos através de uma
linguagem gráfica e que também oferece mecanismos de integração com outras
ferramentas. No entanto, o apoio oferecido pela SSPlan é restrito à sub atividade
preencher protocolo do guia de apoio ao PCRSL (ver Capítulo 4). Desta forma, as
atividades descritas no guia que tratam a organização e comunicação dos pesquisadores
se dão pelo uso do Projectfork.
Com base no que foi comentado anteriormente, o fluxo do planejamento de uma
revisão sistemática se inicia pela organização dos participantes do estudo no
componente Projectfork. Após a organização dos pesquisadores responsáveis pelo
planejamento e revisão do protocolo, o coordenador responsável pelo estudo define e
atribui as atividades entre os pesquisadores. Ressalta-se que neste ponto, as atividades
82
definidas pelo coordenador podem não estar necessariamente relacionadas àquelas
definidas no guia de apoio ao PCRSL, de forma que possam ser consideradas atividades
de suporte ao planejamento (e.g. criação de contas de acesso a ferramentas de busca). Já
as atividades de comunicação entre os envolvidos no planejamento do estudo são
apoiadas pelos componentes de chat e fórum disponibilizados pelo Joomla. Para apoiar
as atividades de elaboração do protocolo de revisão sistemática foi feita uma
modificação no componente Projectfork, de modo que este componente disponibiliza
um hiperlink de acesso a ferramenta SSPlan contendo informações necessárias para
identificação do projeto de revisão sistemática e do pesquisador que esteja utilizando o
Projectfork, conforme ilustra a Figura 56.
Figura 56 - Mecanismo de integração entre Joomla/Projectfork e SSPlan
Com base nos dados enviados pelo Projectfork, SSPlan pode localizar a
instância do processo de preenchimento de protocolo de revisão sistemática associada
ao projeto de revisão. Assim, a ferramenta consulta o processo instanciado e, com base
no mapeamento entre as atividades do guia e os conceitos da ontologia (ver Capítulo 4),
instancia os conceitos da ontologia de revisão sistemática necessários para
contemplação da atividade em execução. Com base nos conceitos associados a cada
atividade do processo, SSPlan apresenta páginas HTML contendo os campos
necessários para o preenchimento do plano da revisão. A partir das decisões tomadas e
das respostas fornecidas, a ferramenta disponibiliza o documento correspondente ao
template do plano da revisão parcialmente preenchido e o arquivo de configuração
contendo as decisões tomadas ao longo do planejamento, conforme ilustra a Figura 57.
83
Figura 57 - Uso do JBPM para apoiar a geração do plano da revisão sistemática
A organização dos pacotes que compõem SSPlan é exibida na Figura 58. Nesta
figura, observa-se que a ferramenta foi construída utilizando o padrão MVC (Model,
View, Control). Ao criar uma instância de processo, a ferramenta consulta o diagrama
que descreve o processo de planejamento (escrito na linguagem jPDL) com o intuito de
descobrir em que tarefa o processo se encontra. Em seguida, o fluxo de execução da
aplicação é repassado para as classes de controle. Para cada tarefa contida no arquivo
jPDL, há um controlador responsável pela instanciação dos conceitos da ontologia e
exibição de páginas XHTML. Em sua grande maioria, há uma página XHTML para
cada conceito da ontologia que retrate o template de protocolo de RSL. Isso permite que
cada página possa oferecer funcionalidades específicas que auxiliem o pesquisador a
preencher determinada seção do template. No entanto, em casos de manutenções na
ontologia, é necessário também atualizar as páginas XHTML correspondentes.
Ao acessar a ferramenta, é possível visualizar dois agrupamentos de tarefas,
conforme exibem as Figuras 59 e 60. No primeiro agrupamento (Figura 59), são listadas
as tarefas já executadas no contexto da instância do processo e as tarefas possíveis de
serem executadas. Note que as tarefas já executadas são destacadas por um ícone que
indica sua conclusão. Além disso, para cada tarefa concluída é possível também
visualizar o conteúdo das informações preenchidas no contexto da tarefa. Ainda no
primeiro agrupamento de tarefas, é possível observar as tarefas possíveis de serem
executadas e que não foram atribuídas ao perfil de um pesquisador (destacadas pelo
ícone +). Desta forma, para que uma tarefa possa ser executada, ela deve ser atribuída
84
antes ao pesquisador que esteja utilizando a ferramenta. Uma vez que uma tarefa tenha
sido atribuída ao perfil de um pesquisador, este pode optar por preencher as informações
associadas a atividade em questão ou devolver a atividade ao agrupamento de tarefas
possíveis de serem executadas, de modo a permitir que outros pesquisadores possam
atribuir a tarefa a seus perfis, conforme ilustra a Figura 60.
Figura 58 - Estrutura interna da SSPlan
Figura 59 - Listagem de tarefas executadas na SSPlan
Figura 60 - Listagem de tarefas associadas ao perfil de um pesquisador
Ao optar por preencher as informações associadas a uma tarefa, o pesquisador
visualiza os campos correspondentes aos conceitos da Ontologia de Estudos
Secundários associados à atividade em questão em conjunto com um texto de ajuda ao
preenchimento dos conceitos, como mostra a Figura 61. Ao término do preenchimento
das informações, SSPlan encerra a tarefa atual e avança no processo descrito pelo guia
85
de apoio, de modo a disponibilizar a próxima tarefa prevista no agrupamento de tarefas
possíveis de serem associadas ao perfil de um pesquisador.
Figura 61 - Preenchimento de conceitos da Ontologia de Estudos Secundários
Outro tipo de tarefa que a SSPlan disponibiliza ao pesquisador durante o
planejamento do estudo secundário está relacionada à tomada de decisão. No exemplo
ilustrado pela Figura 62.a, o pesquisador deve optar por qual procedimento
metodológico de pesquisa a ser adotado. Ao optar por uma das opções e concluir a
tarefa, SSPlan verifica em qual fluxo do processo deve-se prosseguir e disponibiliza
novas tarefas para serem executadas. Neste exemplo, observa-se no diagrama do
processo descrito na linguagem jPDL (Figura 63) que a escolha por uma revisão
sistemática disponibiliza um conjunto de tarefas que não seriam apresentadas ao
pesquisador, caso este optasse pela opção quasi revisão sistemática. Já no caso em que
o pesquisador optasse pela opção Revisão Sistemática, a próxima tarefa a ser
disponibilizada permitiria que este escolhesse por contemplar Meta-análise, conforme
ilustra a Figura 62.b.
Figura 62 - Tarefa que representa uma tomada de decisão
86
Figura 63 - Diagrama jPDL do processo de preenchimento do protocolo de RSL
Dentre as tarefas previstas pela SSPlan para preenchimento do protocolo de
RSL, destacam-se as tarefas de que contemplam o preenchimento das seções Artigos de
Controle, Estrutura da Questão de Pesquisa e Elaboração da String de Busca. Na
atividade que contempla os artigos de controle, a SSPlan permite que, para cada questão
de pesquisa contemplada pela revisão, o pesquisador associe o arquivo Bibtex que
contém a descrição dos artigos de controle. Com base nos conteúdos do arquivo Bibtex
(que incluem nome do artigo, abstract etc.), a SSPlan utiliza a API (Application
Program Interface) Lucene (APACHE, 2011) para identificação de possíveis termos
para compor a lista de keywords que irão estruturar as strings de busca a serem
aplicadas nas bases de dados de artigos científicos. Na escolha dos termos que servirão
como sugestão, SSPlan utiliza a API Lucene para indexar os títulos e os abstracts dos
artigos contidos no arquivo Bibtex e utiliza um algoritmo da API Lucene que identifica
termos considerados estatisticamente relevantes, tendo a preocupação em evitar que
termos comuns (conhecidos também como stop words) que compõem a descrição dos
títulos e abstracts sejam sugeridos como itens relevantes.
Na atividade que contempla a estruturação da questão de pesquisa, a SSPlan
permite que o pesquisador defina os itens que irão compor a estrutura PICO
(Population, Invervention, Comparison, Outcome). Na Figura 64, observam-se os links
que permitem o preenchimento da estrutura. No exemplo da Figura 64, o pesquisador
optou por realizar uma Quasi Revisão Sistemática, de modo que a ferramenta não exibe
um link que permita que a estrutura Comparison seja preenchida. Ao clicar nos links, é
exibida uma janela que solicita a descrição do item a ser preenchido (no exemplo da
figura, solicita-se o preenchimento da definição da população) e o conjunto de keywords
87
que compõem a estrutura, agrupadas por itens considerados como sinônimos (Figura
65).
Figura 64 - Preenchimento da estrutura PICO
Figura 65 - Prenchimento da estrutura Population
Uma vez que se tenha definido os artigos de controle e a estrutura da questão de
pesquisa, a SSPlan sugere ao pesquisador uma string de busca construída através da
permutação das keywords definidas na tarefa que define a estrutura PICO.
Externamente, os termos constituintes de cada item da estrutura são combinados por
meio do operador AND (conjunto de termos Population AND conjunto de termos
Intervention AND conjunto de termos Comparison AND conjunto de termos Outcome),
enquanto que os termos sinônimos pertencentes a cada item da estrutura são
combinados por meio do operador OR. No exemplo da Figura 66, a estrutura
Population possui dois sub conjuntos de termos sinônimos (sendo o sub conjunto 1
composto por keyword1, keyword 2 e keyword 3 e o sub conjunto 2 composto por
keyword 4 e keyword 5). Assim, o conjunto de termos do item Population é constituído
por: keyword 1 keyword 4 OR keyword 1 keyword 5 OR keyword 2 keyword 4 OR
keyword 2 keyword 5 OR keyword 3 keyword 4 OR keyword 3 keyword 5. O mesmo
procedimento se aplica para cada item da estrutura PICO. Além disso, caso o
pesquisador tenha optado por considerar a utilização de artigos de controle, a SSPlan
sugere também possíveis termos a serem incluídos na elaboração da string de busca,
conforme ilustra a Figura 66.
88
Figura 66 - Preenchimento da string de busca
Ao término das tarefas previstas pela SSPlan, a ferramenta disponibiliza ao
pesquisador links para o download do documento correspondente ao template de
protocolo de RSL contendo as informações fornecidas ao longo da elaboração do
protocolo e um arquivo XML contendo todas as decisões tomadas ao longo do
preenchimento do protocolo (Figura 67). Por fim, SSPlan permite também visualizar
todos os artefatos gerados para cada instância de processo de revisão sistemática
executada pela SSPlan (Figura 68).
Figura 67 - Download dos artefatos da revisão na SSPlan
Figura 68 - Listagem de estudos executados na SSPlan
5.4 Conclusão
Por meio da construção de uma ferramenta de apoio ao planejamento de revisões
sistemáticas, espera-se facilitar a condução do PCRSL por parte de pesquisadores em
ES, principalmente aqueles com pouca experiência nesta abordagem. Além disso, será
89
possível conduzir o processo de forma mais transparente, ou seja, todos os envolvidos
poderão ter acesso às informações relacionadas às atividades existentes no processo e o
acesso às informações geradas pelos envolvidos no planejamento da revisão. Com o
intuito de verificar a contribuição feita pela construção do componente de planejamento,
o próximo capítulo apresenta os resultados da aplicação de um plano de avaliação da
ferramenta SSPlan. Os resultados obtidos com a execução do plano foram úteis para
evolução da ferramenta, de modo a disponibilizar novas funcionalidades de apoio ao
planejamento de RSL.
90
6 Estudo de Avaliação de Utilidade e Facilidade
de Uso da SSPlan
Esse capítulo apresenta o procedimento adotado para avaliação da
ferramenta SSPlan quanto a utilidade e facilidade de uso e discute
os resultados obtidos pela avaliação
6.1 Introdução
O Capítulo 5 abordou uma proposta para evolução do ambiente eSEE por meio
da construção de uma ferramenta denominada SSPlan (Secondary Study Planner), que
oferece um conjunto de serviços de apoio ao planejamento de RSL, com foco em
pesquisadores inexperientes nesta abordagem. Para isso, a ferramenta direciona o
preenchimento do protocolo de estudo secundário por meio de um guia de apoio ao
Processo de Condução de Revisões Sistemáticas da Literatura (PCRSL) e uma
Ontologia de Estudos Secundários. Ao completar o guia de apoio, a SSPlan
disponibiliza um template de protocolo de estudo secundário parcialmente preenchido e
um arquivo de configuração contendo as decisões tomadas ao longo do planejamento.
Como passo posterior a construção da SSPlan, partiu-se para a elaboração de um
modelo que permitisse avaliar a utilidade e a facilidade de uso da ferramenta. Desta
forma, o objetivo deste capítulo é abordar o procedimento adotado para avaliação do
conjunto de serviços oferecidos pela SSPlan (Seção 6.2) bem como apresentar e discutir
os resultados oriundos da aplicação do procedimento (Seção 6.3).
6.2 Modelo para Avaliação da SSPlan
O modelo de avaliação da contribuição oferecida pela SSPlan consiste em uma
adaptação do modelo descrito em HERNANDES et al. (2010), que por sua vez utilizou
o modelo TAM (Technology Acceptance Model) (DAVIS, 1993), o qual procura
determinar os aspectos de utilidade e facilidade de uso de tecnologias. Para isso, TAM
se baseia em dois conceitos: (i) percepção sobre utilidade (PE – perceived usefullness) –
mede o quanto o usuário acredita que usando uma determinada tecnologia ele possa
melhorar seu desempenho; (ii) percepção sobre facilidade de uso (PEU – perceived ease
of use) – mede o quanto o indivíduo acredita que usando determinada tecnologia ele
91
possa ficar livre de esforço físico ou mental. Na Figura 69, observa-se o modelo
adaptado adotado no presente estudo, com base no paradigma goal/question/metric
(GQM) (BASILI et al., 1994). A definição dos objetivos (goals) do modelo são
descritas pelas Tabelas 13 e 14.
Figura 69 - Uso do paradigma GQM para avaliação de tecnologia
Tabela 13- Objetivo G1
Analisar A ferramenta SSPlan
Com o propósito de Caracterizar
Com respeito a Facilidade de uso
No contexto de Um Planejamento de RSL
Sob o ponto de vista de Pesquisadores de ES realizando o planejamento de RSL
Tabela 14 - Objetivo G2
Analisar A ferramenta SSPlan
Com o propósito de Caracterizar
Com respeito a Utilidade da ferramenta
No contexto de Um Planejamento de RSL
Sob o ponto de vista de Pesquisadores de ES realizando o planejamento de RSL
Observa-se na Figura 69 que há 7 questões (Q1 à Q7) associadas aos objetivos
G1 e G2 do modelo GQM. Tais questões foram elaboradas visando capturar as
dimensões de utilidade e facilidade de uso da SSPlan, conforme descreve a Tabela 15.
Para fornecer as respostas a cada questão, adotou-se um conjunto de atributos
organizados sob uma escala ordinal, conforme descreve a Tabela 16 (os valores são
apresentados em ordem decrescente de valor). Além disso, para cada questão,
disponibilizou-se um campo textual para que os participantes pudessem fazer
comentários sobre a motivação da resposta fornecida.
92
Tabela 15 - Questões para avaliação da SSPlan
Questões Descrição Dimensão
Q1 Foi fácil aprender a utilizar a SSPlan Facilidade de Uso
Q2 Consegui utilizar a SSPlan da forma que eu queria Facilidade de Uso
Q3 Entendi o que acontecia na minha interação com a
SSPlan Facilidade de Uso
Q4 Foi fácil lembrar como planejar uma revisão
sistemática com o uso da SSPlan
Facilidade de Uso
Utilidade
Q5 Considero SSPlan útil para realizar o planejamento
de protocolos de revisão sistemática Utilidade
Q6
A SSPlan permite realizar o planejamento do
protocolo da revisão sistemática em conformidade
com o processo definido no guia de apoio
Utilidade
Q7
O uso da SSPlan permite melhorar o desempenho do
pesquisador durante o planejamento do protocolo da
revisão sistemática
Utilidade
Tabela 16 - Ordenação decrescente das respostas possíveis para as questões do estudo
Concordo Totalmente
Concordo Amplamente
Concordo Parcialmente
Discordo Parcialmente
Discordo Amplamente
Discordo Totalmente
Finalmente, para cada questão considerada no estudo, há um conjunto de
métricas que se relacionam com as questões definidas anteriormente, conforme descreve
a Tabela 17.
Tabela 17 - Métricas para avaliação da SSPlan
Métrica Descrição
M1 Número de pessoas que escolheram “Concordo totalmente”
M2 Número de pessoas que escolheram “Concordo amplamente”
M3 Número de pessoas que escolheram “Concordo parcialmente”
M4 Número de pessoas que escolheram “Discordo totalmente”
M5 Número de pessoas que escolheram “Discordo amplamente”
M6 Número de pessoas que escolheram “Discordo parcialmente”
Para computar o valor final de cada questão presente no modelo, levou-se em
conta os valores contabilizados para as métricas do estudo, de forma a seguir a
configuração descrita pela Tabela 18.
Uma vez que cada questão tenha sido computada, parte-se para o modelo de
interpretação a respeito da facilidade de uso e utilidade da SSPlan. Devido ao elevado
número de combinações possíveis para a configuração de cada resposta, optou-se por
separar o modelo de interpretação da facilidade de uso e utilidade. Desta forma, são
considerados os conceitos atribuídos a cada questão do modelo GQM, com base na
configuração descrita pelas Tabelas 19 e 20.
93
Tabela 18 - Configuração do valor atribuído a cada questão do modelo GQM
Configuração das métricas Conceito atribuído
M1 > M2 + M3
M4, M5, M6 = 0 Concordo Totalmente (CT)
M1 ≤ M2 + M3
M2 > M3
M4, M5 = 0
M6 < M3
Concordo Amplamente (CA)
M1 ≤ M2 + M3
M2 ≤ M3
M4 = 0
M6 < M3
M6 > M5
Concordo Parcialmente (CP)
M1, M2, M3 = 0
M4 > M5 + M6 Discordo Totalmente (DT)
M1, M2 = 0
M4 ≤ M5 + M6
M5 > M6
M6 > M3
Discordo Amplamente (DA)
M1 = 0
M4 ≤ M5 + M6
M5 ≤ M6
M6 > M3
M3 > M2
Discordo Parcialmente (DP)
Tabela 19 - Modelo de interpretação da facilidade de uso da SSPlan
Configuração Interpretação
Q1, Q2, Q3, e Q4 = CT
SSPlan é fácil de ser utilizada, não sendo necessário implementar melhorias
na ferramenta quanto a aspectos de usabilidade, de modo que pode ser
empregada imediatamente no apoio ao planejamento de estudos secundários.
Q1, Q2, Q3 e Q4 = CA, CP ou DP SSPlan é fácil de ser utilizada. No entanto, os pesquisadores identificaram
oportunidades de melhorias quanto à facilidade de uso. Assim, depois de
implementadas melhorias na ferramenta, um novo estudo deve ser realizado.
Q1, Q2, Q3 e Q4 = DT ou DA SSPlan não possui facilidade de uso. Desta forma, o projeto de usabilidade da
ferramenta deve ser revisto, baseando-se em heurísticas de usabilidade
descritas na literatura técnica e nos comentários realizados pelos participantes
do estudo. Após o tratamento das limitações identificadas, um novo estudo
deve ser realizado com o intuito de verificar o efeito das melhorias
implementadas.
Tabela 20 - Modelo de interpretação da utilidade da SSPlan
Configuração Interpretação
Q4, Q5, Q6 e Q7 = CT
SSPlan é de grande utilidade para o planejamento de estudos secundários, não
sendo necessário implementar melhorias na ferramenta quanto a aspectos de
utilidade, de modo que pode ser empregada imediatamente no apoio ao
planejamento de estudos secundários.
Q4, Q5, Q6 e Q7 = CA, CP ou DP SSPlan é útil para o planejamento de estudos secundários. No entanto, os
pesquisadores identificaram oportunidades de melhorias quanto à utilidade da
ferramenta. Assim, depois de implementadas melhorias na ferramenta, um
novo estudo deve ser realizado.
Q4, Q5, Q6 e Q7 = DT ou DA SSPlan não é de grande utilidade para o planejamento de RSL. Desta forma,
o conjunto de requisitos que regem o desenvolvimento da ferramenta deve ser
revisto, de forma a identificar funcionalidades que possam prover maior
utilidade para o planejamento de estudos secundários. Após o tratamento das
limitações identificadas, um novo estudo deve ser realizado com o intuito de
verificar o efeito das melhorias implementadas.
Para execução do estudo de avaliação da SSPlan, contou-se com a participação
de 11 alunos de pós-graduação (1 doutorando e 10 mestrandos) da disciplina
94
Engenharia de Software Experimental II, ministrada na COPPE/UFRJ. Após o
treinamento dos participantes do estudo nas funcionalidades básicas da ferramenta, estes
foram organizados em equipes (conforme descreve a Tabela 21) e incumbidos de
aprimorar um protocolo de revisão sistemática cujo tema aborda características de
qualidade para especificação de casos de uso. Para que os participantes pudessem
avaliar a ferramenta, foi disponibilizada uma planilha eletrônica, conforme ilustra a
Figura 70.
Tabela 21 - Organização dos participantes do estudo
Equipe Apelido do Participante
Grupo 1 Participante A
Participante B
Grupo 2 Participante C
Participante D
Grupo 3
Participante E
Participante F
Participante G
Grupo 4 Participante H
Participante I
Grupo 5 Participante J
Participante K
Figura 70 - Formulário de avaliação da SSPlan
6.3 Resultados da Avaliação da SSPlan
Após a entrega dos formulários de avaliação da SSPlan pelos participantes do
estudo (disponíveis no Apêndice VII desta dissertação), foi dado início à etapa de
avaliação das respostas fornecidas. A primeira etapa consistiu no agrupamento das
respostas nas possíveis categorias propostas na etapa de planejamento do estudo. Tais
resultados são apresentados na Tabela 22. Em seguida, para cada questão, aplicou-se o
modelo de configuração descrito nas Tabelas 18 e 19.
95
Tabela 22 - Quantitativo de respostas fornecidas pelos pesquisadores
Uma vez que o número de combinações possíveis para atribuição de uma
resposta a uma dada pergunta é consideravelmente alto, optou-se por tratar apenas os
casos mais prováveis de ocorrência. No entanto, ao tentar categorizar o cenário descrito
pela Tabela 22 nas possíveis configurações descritas pela Tabela 18, observou-se que a
existência de algumas respostas do tipo Discordo Amplamente e Discordo Totalmente
faz com que este cenário não se encaixe com exatidão nas configurações descritas pela
Tabela 18. Entretanto, de uma maneira geral, observa-se uma tendência de concordância
com as questões propostas para avaliação da SSPlan. Assim, optou-se por realizar uma
análise mais ampla, considerando o percentual de respostas do tipo Concordo e
Discordo. Desta forma os resultados atribuídos a cada questão são apresentados na
Tabela 23. Por fim, tendo em mãos as respostas atribuídas a cada pergunta do estudo,
pode-se aplicar o modelo descrito pelas Tabelas 19 e 20, de modo que a interpretação
obtida nos diz que a SSPlan possui utilidade e facilidade de uso para o planejamento de
protocolos de revisão sistemática mas tendo necessidade de implementar melhorias para
tornar o uso da ferramenta plenamente satisfatório.
Tabela 23 - Percentual de respotas para cada pergunta do estudo de avaliação da SSPlan
96
Tabela 24 - Classificação das limitações identificadas na SSPlan
Outra análise realizada a partir das respostas fornecidas pelos participantes do
estudo se deu na direção de organizar as principais críticas realizadas em categorias, de
modo a facilitar o entendimento destas críticas e também propor soluções que amenizem
ou solucionem as limitações identificadas. Na Tabela 24, é possível observar alguns dos
comentários realizados pelos participantes do estudo, bem como a categoria na qual tal
comentário se encaixa. De uma maneira geral, as principais críticas realizadas pelos
pesquisadores estão relacionadas à dificuldade de editar seções do protocolo
previamente preenchidas e na quantidade de informações prestadas pela ferramenta que
esclareçam como cada seção do protocolo deve ser preenchida.
A limitação de edição de seções do protocolo foi solucionada. Na Figura 71,
observa-se a existência de um ícone que permite a edição de seções já preenchidas. No
entanto, esta funcionalidade não permite repetir tomadas de decisão, somente editar o
conteúdo de seções que já tenham sido preenchidas anteriormente. Isto se deve a uma
característica da tecnologia JBPM, que não permite executar tarefas já concluídas. Para
entender melhor tal situação, considere um exemplo onde um pesquisador ao utilizar a
ferramenta tenha decidido inicialmente por não considerar critérios para avaliação de
qualidade de artigos que descrevam estudos primários. Assim, a ferramenta não oferece
a possibilidade de reconsiderar a tomada de decisão de incluir tais critérios e então
97
preenchê-los. Já no caso em se tenha, desde o início, decidido considerar tais critérios, é
possível voltar atrás e editar tais critérios. Além disso, a funcionalidade de edição de
seções do protocolo só está disponível enquanto não for gerado o documento final que
representa o template do protocolo, ou seja, uma vez que o processo tenha sido
concluído, não é mais possível editar o protocolo a partir da ferramenta, somente
manualmente a partir de um processador de texto.
Figura 71 - Funcionalidade de edição de tarefas e informações sobre as seções do protocolo
Para solucionar a limitação relacionada à quantidade de informações prestadas
pela ferramenta para preenchimento das seções do protocolo, desenvolveu-se uma
funcionalidade que exibe, para cada atividade considerada pela ferramenta, os conceitos
da Ontologia de Estudos Secundários (contendo a descrição formal dos conceitos) e a
atividade do Guia de Apoio ao PCRSL associados à atividade em questão. Ainda na
Figura 71, observa-se a existência de um ícone que permite exibir maiores informações
sobre uma determinada atividade. Uma vez que o pesquisador clique no link, uma nova
janela é apresentada ao usuário contendo um recorte da Ontologia de Estudos
Secundários e um recorte do guia de apoio (Figura 72). Por questões de tempo, não foi
possível ainda tratar as demais críticas realizadas pelos participantes do estudo de
avaliação da SSPlan.
Figura 72 - Tela de informações para preenchimento de seções do protocolo de RSL
98
6.4 Conclusão
Este capítulo apresentou um procedimento para avaliação da ferramenta SSPlan
quanto aos aspectos de utilidade e facilidade de uso. Os resultados obtidos indicam que
a ferramenta desenvolvida é fácil de usar e útil para o planejamento de revisões
sistemáticas. Além disso, algumas das limitações identificadas pelos participantes do
estudo foram solucionadas por meio do desenvolvimento de novas funcionalidades. No
entanto, entende-se que a ferramenta necessita ser evoluída para atender
satisfatoriamente as necessidades de pesquisadores em ES. Uma vez que novas
funcionalidades sejam implementadas, um novo estudo deverá ser realizado com o
intuito de verificar o efeito das melhorias desenvolvidas.
99
7 Conclusão
Esse capítulo apresenta as principais conclusões, contribuições,
limitações e perspectivas de trabalhos futuros
7.1 Conclusões
Nesta dissertação realizou-se um estudo sobre tecnologias de apoio à condução
de Revisões Sistemáticas da Literatura (RSL). O estudo identificou que o emprego de
RSL em ES tem evoluído nos últimos anos (SILVA et al., 2011). No entanto, observou-
se também que existem desafios a serem perseguidos no sentido de auxiliar
pesquisadores em ES na condução da revisão, principalmente aqueles que possuem
menos experiência neste tipo de abordagem de pesquisa. Assim, este trabalho
apresentou uma proposta para evolução do ambiente de apoio à experimentação em ES
denominado eSEE de modo a contemplar serviços de apoio ao planejamento, execução
e empacotamento de RSL.
Para atingir o objetivo proposto, a metodologia adotada considerou evoluir o
Repositório de Conhecimento sobre Experimentação em Engenharia de Software (ver
Capítulo 2), contemplando estruturas para representação de conhecimento acerca de
estudos secundários e elaborar um conjunto de requisitos que guiam a construção de
serviços de apoio ao planejamento, execução e empacotamento de RSL. Após a
evolução do repositório de conhecimento, inspeções conduzidas na disciplina de
Engenharia de Software Experimental da COPPE/UFRJ permitiram identificar
oportunidades de melhoria tanto nos modelos ontológicos quanto no guia de apoio ao
PCRSL, contribuindo assim para melhoria da completude e corretude de ambos. Por
fim, construiu-se uma ferramenta fundamentada na ontologia e no guia de apoio que
auxilia pesquisadores no planejamento de RSL por meio de uma abordagem baseada em
perguntas e repostas. Ao término do planejamento, a ferramenta disponibiliza o
documento correspondente ao protocolo de RSL e um arquivo contendo as decisões
tomadas ao longo da elaboração do protocolo. No futuro, espera-se que os arquivos de
configuração criados pela ferramenta possam ser utilizados como insumos para
alimentação do Repositório de Conhecimento de Experimentação em ES.
100
Conforme mencionado no Capítulo 2, as tecnologias que apoiam a aplicação de
RSL possuem foco maior nas atividades relativas à etapa Execução do processo
proposto por Biolchini et al. (2005). Ao disponibilizar a ferramenta SSPlan, acredita-se
que a limitação de apoio ferramental para planejamento deste tipo de estudo tenha sido
superada. Assim, uma nova configuração de níveis de apoio às etapas do processo pode
ser definida (conforme descreve a Tabela 25). Atualmente, SSPlan não oferece apoio às
etapas Execução e Análise dos Resultados, embora tal apoio esteja previsto no
componente de execução da arquitetura da SSPlan. Quanto à etapa Empacotamento, as
tecnologias Joomla/Projectfork oferecem apoio ao empacotamento dos artefatos gerados
no planejamento da revisão. Entretanto, com exceção do template de protocolo de
revisão e o arquivo de configuração gerados após o planejamento, os demais artefatos
gerados devem ser empacotados manualmente (descritos no RF09 do documento de
requisitos do componente de execução da SSPlan). Por fim, embora os modelos
ontológicos, o guia de apoio e a ferramenta SSPlan tenham sido construídos de modo a
facilitar a aplicação de revisões sistemáticas em Engenharia de Software, tais
tecnologias podem ser empregadas em outras áreas de pesquisa.
Tabela 25 - Nova configuração de níveis de apoio às etapas da RSL
Planejamento Execução Análise dos
Resultados Empacotamento
SSPlan Alto Nenhum Nenhum Médio
JabRef Baixo Médio Baixo Baixo
Mendeley Baixo Médio Baixo Baixo
Zotero Baixo Médio Baixo Baixo
Assert Nenhum Alto Alto Baixo
PEx Nenhum Alto Alto Baixo
SLR-TOOL Médio Médio Alto Médio
Start Médio Médio Médio Médio
RevMan Médio Médio Alto Médio
7.2 Contribuições
As principais contribuições apresentadas por este trabalho foram:
Identificação, por meio de uma revisão informal da literatura, de tecnologias
que apoiam o planejamento e a execução de Revisões Sistemáticas da
Literatura (RSL);
Evolução das estruturas para representação de conhecimento do ambiente
eSEE por meio da evolução da Ontologia de Estudos Secundários
inicialmente proposta por BIOLCHINI et al. (2005) e da construção de um
101
Guia de Apoio ao Processo de Condução de Revisões Sistemáticas da
Literatura (PCRSL);
Definição de uma proposta e um conjunto de requisitos para construção de
um ambiente que apoie o planejamento, execução e empacotamento de RSL
com base no estudo das limitações nas ferramentas identificadas na revisão
da literatura;
Construção de uma ferramenta que apóie o planejamento de RSL
fundamentada na Ontologia de Estudos Secundários e no guia de apoio ao
PCRSL. Assim, a ferramenta guia o pesquisador na elaboração do protocolo
de RSL seguindo uma abordagem de perguntas e respostas, gerando ao
término do planejamento o documento que formaliza o protocolo e um
arquivo de configuração contendo as decisões tomadas ao longo da
elaboração do protocolo;
Definição de um pacote de laboratório visando realizar avaliação de
ferramentas de apoio à experimentação;
Evolução da arquitetura do ambiente eSEE.
7.3 Limitações
Ao longo da elaboração deste trabalho, identificaram-se as seguintes limitações:
A revisão da literatura que identificou tecnologias de apoio ao planejamento
e execução de RSL se deu de maneira ad-hoc. Apesar de a revisão não ter se
restringido à área de ES, é possível que outras tecnologias que apoiam RSL
não tenham sido identificadas;
Atualmente, a Ontologia de Estudos Secundários está representada apenas na
linguagem LINGO. Além disto, não foram definidas cláusulas de restrições
de existência dos conceitos da ontologia, de modo que não é possível realizar
inferências sobre os modelos;
O procedimento para inspeção dos modelos ontológicos e do guia de apoio
contou com uma participação relativamente pequena de inspetores. Além
disto, estes participantes não possuíam profundos conhecimentos sobre RSL.
Assim, não é possível garantir que todos os defeitos presentes na ontologia e
no guia tenham sido identificados;
102
Ao construir a ferramenta de apoio à elaboração de protocolos de RSL,
houve a necessidade de conversão dos modelos representados em LINGO
para a linguagem Java. Isto faz com que a arquitetura da ferramenta seja
fortemente dependente da forma como a ontologia é representada. Uma vez
que haja mudança na forma como os conceitos são organizados na ontologia,
é necessário que haja manutenção nos códigos fonte da ferramenta. Esta
limitação também se dá quanto a evoluções no guia de apoio ao PCRSL;
A ferramenta de apoio à elaboração de protocolos de RSL não permite editar
as seções do protocolo de RSL uma vez que o planejamento tenha sido
concluído. Assim, após a geração do documento correspondente ao
protocolo, se for necessário realizar alguma modificação no protocolo, esta
deverá ser realizada manualmente no documento;
De forma semelhante ao procedimento para inspeção das ontologias e do
guia de apoio, a inspeção da ferramenta de apoio à elaboração de protocolos
de RSL considerou um pequeno conjunto de inspetores.
7.4 Perspectivas Futuras
Ao término da pesquisa que resultou neste trabalho, foram identificadas as
seguintes oportunidades de trabalhos futuros:
Realizar a conversão dos modelos ontológicos desenvolvidos em LINGO
para a linguagem ONTO UML, visto que esta linguagem possui mais
estruturas para representação de conhecimento e possui também maiores
níveis de aceitação por parte da comunidade acadêmica;
Realizar uma nova rodada do procedimento de inspeção dos modelos
ontológicos e do guia de apoio considerando um conjunto maior de
pesquisadores em ES;
Evoluir a ferramenta de apoio ao planejamento de RSL com base nas
observações feitas pelos participantes do estudo de avaliação da ferramenta.
Dentre as evoluções previstas, inclui-se a funcionalidade que permite editar
protocolos previamente concluídos;
Construir o componente de execução previsto na abordagem apresentada
neste trabalho;
103
Realizar novos estudos de avaliação da funcionalidade e facilidade de uso
das ferramentas desenvolvidas considerando um conjunto maior de
pesquisadores em ES;
Avaliar a utilização da ferramenta por usuários inexperientes e experientes,
visando identificar oportunidades de melhoria na infra-estrutura
disponibilizada.
104
Referências Bibliográficas
ALLEN, D. Seam In Action. 1 ed. Manning, 2009.
AMARAL, E. A. G. G., 2003, Empacotamento de Experimentos em Engenharia de
Software. Dissertação de M.Sc. COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
ANANIADOU, S.; REA, B.; OKAZAKI, N.; PROCTER, R.; THOMAS, J. "Supporting
systematic reviews using text mining", Social Science Computer Review, v. 27,
n. 4, pp. 509-523, Nov. 2009.
APACHE. Apache Lucene, 2011. Disponível em
<http://lucene.apache.org/java/docs/index.html>, acesso em 21/09/2011.
BABAR, M. A.; ZHANG, H. "Systematic literature reviews in software engineering:
Preliminary results from interviews with researchers". In: Proceedings of the
2009 3rd International Symposium on Empirical Software Engineering and
Measurement (ESEM'09), pp. 346-355. Washington, DC., 2009.
BASILI, V., CALDIERA, G., ROMBACH, H. D. Goal Question Metric Paradigm.
John Wiley & Sons, 1994.
BIOLCHINI, J. C. D. A., MIAN, P. G., NATALI, A. C. C., CONTE, T. U.,
TRAVASSOS, G. H. "Scientific research ontology to support systematic review
in software engineering". Advanced Engineering Informatics, v. 21, n. 2, pp.
133-151, Apr. 2007.
BIOLCHINI, J. C. D. A.; MIAN, P. G.; NATALI, A. C. C.; TRAVASSOS, G. H.,
Systematic Review in Software Engineering, Relatório Técnico ES-679/05.
Programa de Engeharia de Sistemas e Computação, COPPE/UFRJ, Rio de
Janeiro, RJ, Brasil, 2005.
BRERETON, P.; KITCHENHAM, B.; BUDGEN, D.; TURNER, M.; KHALIL, M.
"Lessons from applying the systematic literature review process within the
software engineering domain". Journal of Systems and Software, v. 80, n. 4,
pp. 571-583, Apr. 2007.
CASP. Critical Appraisal Skills Programme, 2011. Disponível em
<www.phru.nhs.uk/casp/casp.htm >, acesso em 25/09/2011.
CHAPETTA, W. A., 2006, Uma Infra-estrutura para Planejamento, Execução e
Empacotamento de Estudos Experimentais em Engenharia de Software.
Dissertação de M.Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
CHAPETTA, W. A.; CONTE, T. U.; TRAVASSOS, G. H. Requisitos para um
Ambiente de Experimentação em Engenharia de Software, Relatório Técnico
da Equipe de Engenharia de Software Experimental. Programa de Engenharia de
Sistemas e Computação, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, 2004.
105
COCHRANE. Cochrane Reviewer´s Handbook, 2011a. Disponível em
<http://www.cochrane.dk/cochrane/handbook/hbook.html >, acesso em
25/09/2011.
COCHRANE. The Cochrane Collaboration, 2011b. Disponível em
<http://www.cochrane.org/>, acesso em 25/09/2011.
COCHRANE IMS. Review Manager, 2010. Disponível em <http://www.cc-
ims.net/revman >, acesso em 11/03/2010.
COHEN, J. "A coefficient of agreement for nominal scales". Educational and
Psychological Measurement, v. 1, n. 20, pp. 37-46, Apr. 1960.
CORCHO, O., FERNÁNDEZ-LÓPEZ, M., GÓMEZ-PÉREZ, A. "Methodologies, tools
and languages for building ontologies: where is their meeting point?" Data
Knowl. Engineering., v. 46, n. 1, pp. 41-64, Jul. 2003.
DAVIS, F. D. "User acceptance of information technology: system characteristics, user
perceptions and behavioral impacts". International Journal of Man-Machine
Studies, v. 38, n. 3, pp. 475-487, Mar. 1993.
DIAS NETO, A. C.; BARCELOS, R.; W., A. C. et al. "Infrastructure for SE
Experiments Definition and Planning". In: 1st Experimental Software
Engineering Latin American Workshop (ESELAW'04), pp. 34-44, Brasília,
2004.
DICKERSIN, K.; SCHERER, R.; LEFEBVRE, C. "Systematic Reviews: Identifying
relevant studies for systematic reviews". British Medical Journal, v. 310, n.
6972, pp. 1286-1291, Nov. 1994.
DIESTE, O., GRIMÁN, A., JURISTO, N. "Developing search strategies for detecting
relevant experiments". Empirical Software Engineering, v. 14, n. 5, pp. 513-
539, Oct 2009.
DIESTE, O.; PADUA, A. G. Developing search strategies for detecting relevant
experiments for systematic reviews. In: Proceedings of the 1st International
Symposium on Empirical Software Engineering and Measurement
(ESEM'07), pp.215-224, Madri, Sep. 2007.
DIXON-WOODS, M., AGARWAL, S., JONES, D., YOUNG, B., SUTTON, A.
"Synthesising Qualitative and Quantitative Evidence: A Review of Possible
Methods". Journal of Health Services Research & Policy, v. 10, n. 1, pp. 45-
53, Jan. 2005.
DYBÅ, T., DINGSØYR, T., HANSSEN, G. K. "Applying systematic reviews to
diverse study types: An experience report". In: Proceedings of the 1st
International Symposium on Empirical Software Engineering and
Measurement (ESEM'07), pp. 225-234, Madri, Sep. 2007.
106
EPPI-CENTRE. EPPI-Reviewer, 2010. Disponível em
<http://eppi.ioe.ac.uk/cms/Default.aspx?tabid=1913&language=en-US>, acesso
em 11/03/2010.
FALBO, R. A., MENEZES, C. S., ROCHA, A. R. "Using Ontologies to Improve
Knowledge Integration in Software Engineering Environments". In: World
Multiconference on Systemic, Cybernetics and Informatics and 4th
International Conference on Information Systems Analysis and Synthesis
(SCI98/ISAS98), pp.1-8, Orlando, Jul. 1998.
FELDMAN, K. A. "Using the work of others: Some observations on reviewing and
integrating". Sociology of Education, v. 44, n. 1, p. 86-102, 1971.
FELIZARDO, K. R., ANDERY, G. F., MALDONADO, J. C., MINGHIM, R. "Uma
Abordagem Visual para Auxiliar a Revisão da Seleção de Estudos Primários na
Revisão Sistemática". In: Proceedings of 6th Experimental Software
Engineering Latin American Workshop (ESELAW’09), pp. 83-92, São
Carlos, Nov. 2009.
FERNÁNDEZ, M., GOMEZ-PEREZ, A., JURISTO, N. "Methontology: From
ontological art towards ontological engineering". In: Proceedings of the
AAAI97 Spring Symposium Series on Artificial Intelligence, pp.33-44,
Standford, Mar. 1997.
FERNÁNDEZ-SÁEZ, A. M., BOCCO, M. G., ROMERO, F. P. "SLR-TOOL - A Tool
for Performing Systematic Literature Reviews". In: 5th International
Conference on Software and Data Technologies (ICSOFT), pp. 157-166,
Athen, Sep. 2010.
FLEISS, J. L. "Measuring nominal scale agreement among many raters". Psychological
Bulletin, v. 76, n. 5, pp. 378-382, Nov. 1971.
FRANTZI, K., ANANIADOU, S., MIMA, H. "Automatic recognition of multi-word
terms: The C-value/NC-value method". International Journal on Digital
Libraries, v. 3, n. 2, pp. 115-130, Aug. 2000.
HARS, A. "Designing scientific knowledge infrastructures: the contribution of
epistemology". Information Systems Frontiers, v. 3, n. 1, pp. 63-73, Mar.
2001.
HERNANDES, E., ZAMBONI, A., THOMMAZO, A. D., FABBRI, S. "Avaliação da
ferramenta StArt utilizando o modelo TAM e o paradigma GQM". In:
Proceedings of 7th Experimental Software Engineering Latin American
Workshop (ESELAW'10), pp. 30-39, Goiânia, Nov. 2010.
JABREF. JabRef Reference Manager, 2011. Disponível em
<http://jabref.sourceforge.net/>, acesso em 22/09/2011.
JBOSS. jBPM, 2011a. Disponível em <http://www.jboss.org/jbpm >, acesso em
10/01/2011.
107
JOOMLA. Joomla Content Management System, 2011. Disponível em
<http://www.joomla.org/>, acesso em 10/01/2011.
KITCHENHAM B. A., BRERETON, P. O., BUDGEN, D., TURNER, M., BAILEY J.,
LINKMAN S. "Systematic literature reviews in software engineering - A
systematic literature review". Information and Software Technology, v. 51, n.
1, pp. 7-15, Jan. 2009.
KITCHENHAM, B. A. Procedures for performing systematic reviews, Technical
Report TR/SE-0401. Department of Computer Science, Keele University, Keele,
Staffs, UK, 2004.
KITCHENHAM, B. A.; MENDES, E.; TRAVASSOS, G. H. "Cross versus Within-
Company Cost Estimation Studies: A Systematic Review". Software
Engineering, IEEE Transactions on, v. 33, n. 5, p. 316-329, May. 2007.
KITCHENHAM, B.; BRERETON, P. A.; TURNER, M. A., NIAZI, M., LINKMAN,
S.; PRETORIUS, R., BUDGEN, D. "The impact of limited search procedures
for systematic literature reviews - A participant-observer case study". In: 3rd
International Symposium on Empirical Software Engineering and
Measurement (ESEM'09) pp.336-345, Lake Buena Vista, Oct. 2009.
KITCHENHAM, B.; CHARTERS, S. Guidelines for performing Systematic
Literature Reviews in Software Engineering. Technical Report EBSE-2007-
01. Department of Computer Science, Keele University, Keele, Staffs, UK,
2007.
LANDIS, J. R.; KOCH, G. G. The measurement of observer agreement for categorical
data. Biometrics, v. 33, n. 1, pp. 159-174, Mar. 1977.
LIGHT, R. J.; SMITH, P. V. "Accumulating evidence: Procedures for resolving
contradictions among research studies". Harvard Educational Review, v. 41, n.
4, pp. 429-471, Nov. 1971.
LOPES, V. P., 2010, Repositório de Conhecimento de um Ambiente de Apoio à
Experimentação em Engenharia de Software. Dissertação de M.Sc.,
COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
LOPES, V. P.; TRAVASSOS, G. H. "Infra-estrutura Conceitual para Ambientes de
Experimentação em Engenharia de Software". In: Experimental Software
Engineering Latin American Workshop (ESELAW'08), pp. 34-44, Salvador,
Out. 2008.
LOPES, V. P., TRAVASSOS, G. H. "Knowledge Repository Structure of an
Experimental Software Engineering Environment". In: Anais do XXIII
Simpósio Brasileiro de Engenharia de Software (SBES), pp.32-42, Fortaleza,
Out. 2009.
LOPES, V. P.; TRAVASSOS, G. H. "Uma Ferramenta de Apoio ao Planejamento de
Estudos Experimentais em Engenharia de Software". In: Proceedings of VII
108
Experimental Software Engineering Latin American Workshop, pp 40-48,
Goiânia, Nov. 2010.
MAFRA, S. N., TRAVASSOS, G. H. 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, Rio
de Janeiro, RJ, Brasil, 2006.
MALHEIROS, V., HÖHN, E., PINHO, R., MENDONÇA, M. "A Visual Text Mining
approach for Systematic Reviews". In: Proceedings of First International
Symposium on Empirical Software Engineering and Measurement
(ESEM’07), pp. 245-254, Madri, Sep. 2007.
MENDELEY. Mendeley - Free reference manager and PDF organizer, 2011.
Disponível em <http://www.mendeley.com>, acesso em 22/09/2011.
MIAN, P. G. ODEd: Uma Ferramenta de Apoio ao Desenvolvimento de ontologias em
um Ambiente de Desenvolvimento de Software. Dissertação de M.Sc.,
Departamento de Informática, Universidade Federal do Espírito Santo, Espírito
Santo, ES, Brasil, 2003.
MIAN, P. G. Proposta de Infra-Estrutura Computacional para Apoiar Experimentação
em Engenharia de Software. Exame de Qualificação, Programa de Engenharia
de Sistemas e Computação, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, 2006.
MONTEBELO, R.; ORLANDO, A.; PORTO, D.; ZANIRO, D.; FABBRI, S. "SRAT
(Systematic Review Automatic Tool) – Uma Ferramenta Computacional de
Apoio à Revisão Sistemática". In: Experimental Software Engineering Latin
American Workshop (ESELAW’07), pp. 13-22, São Paulo, Dez. 2007.
PAI, M., MCCULLOVCH, M., GORMAN, J. D., PAI, N. ENANORIA, W.,
KENNEDY, G., THARYAN, P., COLFORD, J. J. "Systematic reviews and
meta-analysis: An illustrated, step by-step guide". The National Medical
Journal of India, v. 17, n. 2, pp. 86-95, Mar. 2004.
PMI. PMI - the World’s Leading Professional Association for Project Management,
2011. Disponível em <http://www.pmi.org>, acesso em 22/09/2011.
PROJECTFORK. Projectfork, 2011. Disponível em <http://projectfork.net/>, acesso em
10/01/2011.
PROTÉGÉ. Protégé, 2011. Disponível em <http://protege.stanford.edu/>, acesso em
10/01/2011.
QSR. NVivo, 2011. Disponível em
<http://www.qsrinternational.com/products_nvivo.aspx>, acesso em 22/09/2011.
REUTERS, T. EndNote, 2011. Disponível em <http://www.endnote.com/>, acesso em
22/09/2011.
109
ROBINSON, H., SEGAL, J., SHARP, H. "Ethnographically-informed empirical studies
of software practice". Information and Software Technology, v. 49, n. 6, pp.
540-551, Newton, Jun. 2007.
SANTO, R. E., TRAVASSOS, G. H. "Serviços de Apoio ao Planejamento e Execução
de Revisões Sistemáticas da Literatura". In: Anais do XV Workshop de Teses e
Dissertações em Engenharia de Software - Congresso Brasileiro de Software
(CBSoft), v. 6, pp. 55-60, Salvador, Out. 2010.
SANTOS, P. S. M., TRAVASSOS, G. H. "Colaboração entre Academia e Indústria:
oportunidades para Utilização da Pesquisa-Ação em Engenharia de Software".
In: Proceedings of the V Experimental Software Engineering Latin
American Workshop (ESELAW'08), pp. 46-58, Salvador, Out. 2008.
SANTOS, P. S. M, 2007, Ferramenta para Alocação de Serviços WEB em Ambientes
de Engenharia de Software Experimental. Monografia de Graduação, Instituto
de Matemática, Universidade Federal do Rio de Janeiro, Rio de Janeiro, RJ,
Brasil.
SEAM. JBoss Seam, 2011. Disponível em <http://www.seamframework.org>, acesso
em 10/01/2011.
SEAMAN, C. "Qualitative methods in empirical studies of software engineering".
IEEE Transactions on Software Engineering, v. 25, n. 4, pp. 557–572,
Piscataway, Jul. 1999.
SHULL, F.; CARVER, J.; TRAVASSOS, G. H. "An Empirical Methodology for
Introducing Software Processes". In: 8th European Software Engineering
Symposium and 9th ACM SIGSOFT Symposium on the Foundations of
Software Engineering (FSE-9) and 8th European Software Engineering
Conference (ESEC), USA, 2001.
SILVA, F. Q. B., SANTOS, A. L. M., SOARES, S. FRANÇA, A. C. C., MONTEIRO,
C. V. F., MACIEL, F. F. "Six years of systematic literature reviews in software
engineering: An updated tertiary study´". Information and Software
Technology, v. 53, n. 9, pp. 899-913, Newton, Sep. 2011.
SJØBERG, D. I. K.; HANNAY, J. E.; HANSEN, O., KAMPENES, V. B., LIBORG,
N., REDKAL, A. C. "A Survey of 116 Controlled Experiments in Software
Engineering". IEEE Transactions on Software Engineering, v. 31, n. 9, pp.
733-753, Piscataway, Sep. 2005.
SOUZA, A. B. O., 2007, Configuração de Processos de Experimentação em
Engenharia de Software. Monografia de Graduação, Instituto de Matemática,
Universidade Federal do Rio de Janeiro, Rio de Janeiro, RJ, Brasil.
SPARK SYSTEMS. Enterprise Architect, 2012. Disponível em
<http://www.sparxsystems.com.au/>, acesso em 14/04/2012.
110
STAPLES, M.; NIAZI, MAHMOOD. "Experiences using systematic review
guidelines". Journal of Systems and Software, v. 80, n. 9, pp. 1425-1437, Sept,
2007.
TRAVASSOS, G. H., BARROS, M. O. "Contributions of In Virtuo and In Silico
Experiments for the Future of Empirical Studies in Software Engineering". In:
Proceedings of the WSESE03, Roma, 2003.
TRAVASSOS, G. H., SANTOS, P. S. M., MIAN, P. G., DIAS NETO, A. C.,
BIOLCHINI, J. C. D. A. "An environment to support large scale
experimentation in software engineering". In: Proceedings of the IEEE
International Conference on Engineering of Complex Computer Systems,
ICECCS, pp.193-202, Belfast, Mar. 2008.
TRAVASSOS, G. H., GUROV, D., AMARAL, E. A. G. Introdução à Engenharia de
Software Experimental, Relatório Técnico ES-590/02. Programa de
Engenharia de Sistemas e Computação, COPPE/UFRJ, Rio de Janeiro, RJ,
Brasil, 2002.
UCSF. Database of Abstracts of Reviews of Effects (DARE), 2011. Disponível em
<http://www.library.ucsf.edu/db/database-abstracts-reviews-effects-dare>,
acesso em 22/09/2011.
W3C. The World Wide Web Consortium, 2011a. Disponível em <http://www.w3.org>,
acesso em 10/01/2011.
WÖHLIN, C., RUNESON, P., HÖST, M., Ohlsson, M. C., Regnell, B. Wesslén, A.
Experimentation in Software Engineering. 1 ed. Sweden, Kluwer Academic
Publishers, 2000.
YIN, R. K. Case Study Research: Design and Methods. 3 ed. London, Sage, 2003.
ZAMBONI, A., THOMMAZO, A. D., HERNANDES, E., FABBRI, S. "StArt – Uma
Ferramenta Computacional de Apoio à Revisão Sistemática". In: Sessão de
Ferramentas - Congresso Brasileiro de Software (CBSoft), pp. 91-96,
Salvador, Out. 2010.
ZOTERO. Zotero, 2011. Disponível em <http://www.zotero.org/>, acesso em
22/09/2011.
111
Apêndice I – Introdução sobre Ontologias
Uma ontologia representa “a descrição formal de conceitos de um domínio, de
propriedades de cada conceito descrevendo funcionalidades e atributos e, uso de
regras de restrição” (NOY & MCGUINNESS, 2001). Entre as vantagens do advento
de ontologias estão: (i) explicitação do conhecimento existente sobre um determinado
domínio; (ii) definição de um vocabulário comum entre aqueles que desejam
compartilhar informações; (iii) possibilidade de realizar inferências sob conceitos que
compõe o domínio; e (iv) reutilização de conhecimento.
Ontologias são representadas a partir das estruturas: indivíduos, propriedades e
classes. Os indivíduos são as instâncias, representando os objetos que pertencem à
ontologia. As propriedades são as relações a serem construídas entre os indivíduos
(relação binária) ou para o indivíduo (função, característica). As propriedades podem
ser inversas, transitivas ou simétricas. As classes podem ser vistas como conjuntos que
contem indivíduos, ou seja, a representação concreta de um conceito.
Para a construção destes modelos, existem diferentes abordagens descritas na
literatura técnica (CORCHO et al., 2003). Essas abordagens têm como preocupação
abordar questões a respeito de atividades padronizadas e ciclos de vida, bem como
apresentar um conjunto bem-definido de critérios de projeto, técnicas e ferramentas para
tornar o desenvolvimento de ontologias uma atividade de engenharia (FERNÁNDEZ et
al., 1997). Além disso, é importante que os conceitos representados por tais ontologias
estejam de acordo com o domínio ao qual a ontologia deseja representar. Assim, grande
parte das abordagens existentes indica verificação e validação como uma das etapas do
processo de construção de ontologias. Essas etapas visam garantir maiores níveis de
corretude e completude dos modelos ontológicos.
Dentre as abordagens para criação de ontologias existentes (CORCHO et al.,
2003), destaca-se a Methontology (FERNANDEZ et al., 1997), que apóia a construção
de ontologias de forma sistemática e organizada, permitindo que modelos possam ser
elaborados desde o início, a partir do reuso de modelos existentes ou a partir de
atividades de reengenharia nestes modelos. Ao observar a Figura 73, nota-se que o
framework provido pela Methontology inclui:
112
Identificação do processo de desenvolvimento de ontologias: identifica quais
tarefas devem ser executadas para construção de ontologias (planejamento,
controle, garantia da qualidade, especificação, aquisição de conhecimento,
conceitualização, formalização, integração, implementação, avaliação,
manutenção, documentação e gerenciamento);
Ciclo de vida para evolução de ontologias: identifica os estágios ao qual a
ontologia passa durante seu ciclo de vida, bem como as interdependências com o
ciclo de vida de outras ontologias;
Atividades para construção de ontologias: especifica quais técnicas devem ser
empregados em cada atividade, os produtos de cada atividade e como estes
podem ser avaliados.
Segundo CORCHO et al. (2003), a principal etapa no desenvolvimento de
ontologias utilizando Methontology é a conceitualização. Nesta etapa são identificados
os termos da ontologia. Diversas técnicas podem ser empregadas, inclusive aquelas
comumente empregadas em desenvolvimento de software ligadas à elicitação de
requisitos. Modelos semi-formais podem ser construídos para expressar o
relacionamento entre estes conceitos. Estes modelos são preferíveis no sentido de que
são mais formais que uma lista de termos em linguagem natural.
Figura 73 - Ciclo de vida da Methontology (adaptada de (CORCHO et al., 2003))
113
Linguagem LINGO e OntoUML para Representação Visual de Ontologias
Conforme citado anteriormente, durante a etapa conceitualização da
metodologia Methontology, linguagens visuais podem ser empregadas para modelagem
de ontologias. Dentre as linguagens existentes, a linguagem LINGO (FALBO et al.,
1998) consiste num subconjunto de elementos UML que, por ser amplamente utilizada
pela comunidade de ES, facilita o entendimento dos modelos. Além disso, como a
notação UML é considerada uma linguagem intermediária para construção de
ontologias (FERNANDEZ et al., 1997), detalhes de formalização da ontologia com
linguagens baixo-nível não precisam ser abordados nesta etapa inicial de construção dos
modelos. Os elementos utilizados para representação de conhecimento na linguagem
LINGO podem ser observados na Figura 74.
Figura 74 - Representação visual da linguagem LINGO (adaptada de (FERNÁNDEZ et al., 1997))
Para não prevalecer a semântica de “classe” em UML, a linguagem LINGO
adota o mecanismo de extensão de estereótipos. Classes com estereótipo <<conceito>>
representam conceitos da ontologia, da mesma forma que relações que contém
propriedades ou que possuem cardinalidade maior que dois, são representadas como
classes associativas com estereótipo <<relação>> (LOPES, 2010).
As relações binárias sem propriedades são definidas como associações
nomeadas. As propriedades de conceitos e relações são representadas como atributos de
classes estereotipadas. Relações de subtipo e todo-parte são representadas como
relações de generalização/especialização e de agregação/composição, respectivamente.
(MIAN, 2003). Além disso, LINGO permite que ontologias possam ser divididas em
subontologias com o intuito de facilitar a organização e visualização dos conceitos
representados.
114
De forma semelhante à linguagem LINGO, a OntoUML (GUIZZARDI, 2005)
também utiliza a UML como linguagem visual para representação de ontologias. No
entanto, OntoUML possui maior quantidade de estereótipos (Figura 75), o que permite
maior nível de riqueza para representação de conhecimento.
Figura 75 - Taxonomia da OntoUML (adaptada de (GUIZZARDI, 2005))
Linguagem OWL para Representação Formal de Ontologias
Dentre as linguagens para representação formal de ontologias (RDF, RDF-
Schema, DAML+OIL e OWL), a que possui maior destaque e oferece maiores
vantagens é a OWL (Web Ontology Language). Recomendada pela W3C (World Wide
Web Consortium) (W3C, 2011a), esta linguagem permite o uso de lógica descritiva
(fragmento da lógica de primeira ordem), o que permite verificar a consistência da
ontologia e o processamento automático da hierarquia de conceitos. A criação de
ontologias OWL pode se dar a partir da escolha de três sub-linguagens: OWL Lite,
OWL DL, OWL Full. OWL Lite é a versão mais simples e permite apenas a definição
de hierarquia de conceitos e regras de restrição simples. Esta pode ser empregada na
elaboração de Thesaurus (dicionário de sinônimos). OWL DL suporta a lógica
descritiva e é computável. Por fim, OWL Full permite o emprego de métodos de
modelagem mais complexos (e.g. meta-classes), mas não é computável. Assim, um
critério para escolha da sub-linguagem a ser utilizada deve levar em consideração a
115
complexidade dos conceitos a serem modelados e a necessidade de computação
automatizada.
Referências Bibliográficas
CORCHO, O., FERNÁNDEZ-LÓPEZ, M., GÓMEZ-PÉREZ, A. "Methodologies, tools
and languages for building ontologies: where is their meeting point?" Data
Knowl. Engineering., v. 46, n. 1, pp. 41-64, Jul. 2003.
FALBO, R. A., MENEZES, C. S., ROCHA, A. R. "Using Ontologies to Improve
Knowledge Integration in Software Engineering Environments". In: World
Multiconference on Systemic, Cybernetics and Informatics and 4th
International Conference on Information Systems Analysis and Synthesis
(SCI98/ISAS98), pp.1-8, Orlando, Jul. 1998.
FERNÁNDEZ, M., GOMEZ-PEREZ, A., JURISTO, N. "Methontology: From
ontological art towards ontological engineering". In: Proceedings of the
AAAI97 Spring Symposium Series on Artificial Intelligence, pp.33-44,
Standford, Mar. 1997.
GUIZZARDI, G., 2005, Ontological foundations for structural conceptual models.
Ph.D. dissertation, University of Twente, Netherlands.
LOPES, V. P., 2010, Repositório de Conhecimento de um Ambiente de Apoio à
Experimentação em Engenharia de Software. Dissertação de M.Sc.,
COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
MIAN, P. G. ODEd: Uma Ferramenta de Apoio ao Desenvolvimento de ontologias em
um Ambiente de Desenvolvimento de Software. Dissertação de M.Sc.,
Departamento de Informática, Universidade Federal do Espírito Santo, Espírito
Santo, ES, Brasil, 2003.
NOY, N. F., MCGUINNESS, D. L. Ontology Development 101: A Guide to Creating
Your First Ontology, 2001. Disponível em
<http://www.ksl.stanford.edu/people/dlm/papers/ontology101/ontology101-noy-
mcguinness.html >, acesso em 07/03/2010.
W3C. The World Wide Web Consortium, 2011a. Disponível em <http://www.w3.org>,
acesso em 10/01/2011.
116
Apêndice II – Introdução às Tecnologias
Utilizadas na Construção da Ferramenta de Apoio
ao Planejamento de Revisões Sistemáticas da
Literatura
Joomla e ProjectFork
Joomla (JOOMLA, 2011) é um framework CMS desenvolvido na linguagem de
programação PHP com o intuito de facilitar a gerência de conteúdo Web para usuários
com pouco conhecimento em programação de computadores. Entre as vantagens de uso
do Joomla estão a facilidade de instalação, de integração com banco de dados e de
configuração de um ambiente Web. A arquitetura do Joomla é exibida na Figura 76. As
facilidades apontadas permitem que um site esteja disponível para uso em um curto
espaço de tempo. Além disto, por se tratar de um framework amplamente utilizado pela
comunidade, existem várias extensões com o intuito de adicionar funcionalidades extras
ao site que esteja sendo desenvolvido.
Figura 76 - Arquitetura do CMS Joomla (adaptado de (JOOMLA, 2011))
Dentre as funcionalidades básicas oferecidas pelo Joomla estão: (i) controle de
usuários que têm acesso ao portal (criação de contas de acesso, restrição de acesso,
classificação do usuário por papéis etc.); (ii) controle de conteúdo textual (criação e
controle de notícias); (iii) criação de enquetes; (iv) criação de tópicos no fórum, de salas
de chat e de listas de discussão; (v) envio de e-mails; (vi) versionamento de conteúdo; e
(vii) ferramentas colaborativas (e.g., edição colaborativa de documentos). Através de
117
um menu especial, o administrador do portal tem a possibilidade de gerenciar o
conteúdo do site através da adição e remoção dos componentes de interesse.
O framework Joomla permite a classificação dos usuários do sistema em sete
papéis: registered, author, editor, publisher, manager, administrator e super
administrator. Estes papéis podem ser divididos em duas categorias: (i) public front-
end: usuários que irão interagir com o portal de uma maneira geral por meio de escrita
de artigos, participação em enquetes etc.; e (ii) public back-end: usuários responsáveis
pelo gerenciamento do conteúdo e estrutura do portal (adição de enquetes, controle dos
usuários que podem acessar o portal, criação de menu e de links etc.). Os usuários da
categoria public front-end são classificados como: registered, author, editor e publisher.
Já os usuários da categoria public back-end são classificados como: manager,
administrator e super administrator.
Conforme mencionado anteriormente, Joomla permite a adição de componentes
que agreguem novas funcionalidades. Neste sentido, o componente Projectfork
(PROJECTFORK, 2011) atua como um sistema gerenciador de projetos, apoiando o
planejamento e acompanhamento de atividades atribuídas a projetos. Ao acessar o
componente, é possível visualizar as tarefas disponíveis em um projeto bem como
selecionar outro projeto ao qual o usuário faça parte. Além disso, existe uma série de
opções que permitem a criação de novos projetos, tarefas, grupos de usuários, controle
de arquivos etc (destacadas por meio de um retângulo), conforme ilustra a Figura 77.
Figura 77 - Tela inicial do CMS Joomla com o componente Projectfork
Para que seja possível criar um novo projeto, o primeiro passo a ser dado é a
configuração de grupo de usuários. Esta opção permitirá definir as funcionalidades
permitidas a um determinado grupo de usuários. Conforme exibe a Figura 78.a, há uma
série de permissões a serem atribuídas, sendo as mais importantes aquelas relacionadas
118
a projetos e tarefas. Após este passo, é necessário cadastrar os usuários no Projectfork.
Reparem que neste passo é possível indicar a quais grupos o novo usuário irá pertencer
(representado por meio de um retângulo na Figura 78.b). Uma vez que usuários e
grupos tenham sido definidos, pode-se então partir para a criação de um novo projeto.
Neste passo, o usuário responsável pela criação do projeto fornecerá o nome do projeto
e uma descrição sobre o mesmo, além de poder atribuir uma data limite para seu
término. Por fim, é possível informar quais usuários irão participar do projeto
(considerando as permissões que cada usuário possui) e informar se o projeto aceitará
que novos usuários façam requisições para ingresso no projeto (Figura 79).
Figura 78 - Criação de grupos e usuários no Projectfork
Uma vez que um projeto tenha sido criado, é possível atribuir tarefas aos
participantes do projeto. Tais tarefas podem ser criadas isoladamente ou podem ser
associadas a um determinado marco (milestone) do projeto. Ao criar-se uma tarefa é
possível indicar a data estimada para conclusão, definir nível de prioridade e indicar os
responsáveis pela execução da tarefa, conforme exibe a Figura 80. Os usuários
responsáveis pela execução de uma tarefa podem então informar o percentual de
conclusão da tarefa bem como realizar comentários sobre as ações realizadas.
119
Figura 79 - Criação de um projeto no Projectfork
Embora o Projectfork ofereça diversas funcionalidades de apoio a
gerenciamento de projetos, este componente não oferece um controle rígido sobre a
ordem com que as tarefas de um projeto possam ser executadas. Conforme é possível
observar na Figura 81, a ordem com que as tarefas devem ser executadas é definida pela
atribuição de um algarismo (destacada por meio do retângulo situado ao lado esquerdo
da figura) à tarefa (quanto menor o algarismo maior a precedência da atividade). No
entanto, nada impede ao usuário participante do projeto indicar o término de uma
atividade (modificando o grau de conclusão da tarefa destacada pelo retângulo situado
ao lado direito da figura) sem respeitar a ordem de precedência das tarefas criadas.
Além disso, não há garantias que a modificação do grau de conclusão seja de fato
decorrente da execução de ações que contribuam para o término da atividade.
120
Figura 80 - Criação de uma tarefa em um projeto
Figura 81 - Ordenação de tarefas no Projectfork
JBoss Seam
O framework Web JBoss Seam (SEAM, 2011) se apresenta como uma iniciativa
de união de diversas tecnologias de desenvolvimento para a plataforma de Java
Enterprise Edition (ORACLE, 2011a). A integração de tecnologias de desenvolvimento
121
tende a ser uma das etapas mais complicadas no processo de desenvolvimento de
produtos de software, caso tais tecnologias não tenham sido projetadas para este fim. O
framework Seam permite que as principais tecnologias relacionadas a desenvolvimento
de visões para o usuário, persistência de dados e desenvolvimento de regras de negócio
sejam mais facilmente integradas, permitindo que os desenvolvedores possam dedicar
mais tempo às regras de negócio, que tangem o problema abordado. Por apresentar esta
proposta, muitos desenvolvedores preferem classificar o Seam como Application Stack
ao invés de um framework (ALLEN, 2009).
O framework Seam foi originalmente desenvolvimento para trabalhar com as
tecnologias JSF (ORACLE, 2011b) (Java Server Faces, para desenvolvimento de
visões para o usuário), JPA (ORACLE, 2011c) (Java Persistence API, que pode utilizar
as implementações Hibernate e Top Link para persistência de dados) e EJB (ORACLE,
2011d) (Enterprise Java Beans, para desenvolvimento de regras de negócio). O
relacionamento entre estas tecnologias está destacado na Figura 82.
Figura 82 - Relacionamento entre tecnologias presentes no framework Seam (adaptada de
(ALLEN, 2009))
Embora a Figura 82 faça referência ao uso da tecnologia EJB, este uso não é
obrigatório (o presente trabalho não utiliza a tecnologia EJB). A mesma observação vale
para a implementação do JSF (representada na Figura 82 pela implementação
Facelets/RichFaces). Entre as tecnologias de desenvolvimento de visões para o usuário,
existe o suporte nativo às tecnologias RichFaces e IceFaces (o presente trabalho utiliza a
tecnologia Facelets/RichFaces). No entanto, outras tecnologias para desenvolvimento
de visões para o usuário podem ser integradas (como a tecnologia Google Web Toolkit
122
(GOOGLE, 2011)). Todas estas tecnologias oferecem o uso de requisições AJAX
(W3C, 2011b) (Asynchronous Javascript And XML) para tornar as páginas Web mais
interativas com o usuário. Para apoiar a adoção do framework Seam, o presente trabalho
utilizou o servidor de aplicações JBoss Application Server (JBOSS, 2011b) em conjunto
com o servidor de banco de dados MySQL (MYSQL, 2011).
Uma das principais vantagens oferecidas por este framework é a criação de um
contexto que permite que instâncias de objetos permaneçam ativas durante a troca de
requisições HTTP. Isto permite ao desenvolvedor evitar o uso excessivo da sessão do
servidor de aplicação para persistência temporária de informações, o que, em muitos
casos, ocasiona um uso excessivo de memória. Outras vantagens de interesse oferecidas
por este framework estão relacionadas à criação de mecanismos que facilitam a
interação entre as tecnologias JSF, JPA e EJB. Estes mecanismos diminuem o número
de estruturas de adaptação para o funcionamento integrado destas tecnologias (glue
code). Além disto, algumas propostas de melhoria para problemas existentes nas
tecnologias utilizadas por este framework foram apresentadas (e.g., todas as requisições
HTTP na versão 1.2 do JSF são feitas por POST).
Além das vantagens citadas anteriormente, Seam possui ainda integração com o
framework de gerência de processo jBPM (JBOSS, 2011a). Tal integração diminui a
necessidade de criação de estruturas de comunicação entre os dois frameworks. Desta
forma, o desenvolvedor pode se concentrar mais na elaboração do processo a ser
executado e na codificação das regras de negócios descritas pelos requisitos do sistema
em questão.
jBPM
jBPM é um framework Java (também pode ser classificado como um BPMS –
Bussiness Process Management System) (BPMI, 2011) que auxilia o desenho de
processos de negócio. Além disso, oferece também um ambiente de execução de
processos e ferramentas que auxiliam no monitoramento de processos visando
identificar oportunidades de melhorias. Dentre as vantagens do uso deste framework,
destaca-se a facilidade de entendimento por parte dos analistas de negócios, cuja
responsabilidade é analisar e especificar processos de negócio, e por profissionais
responsáveis pela transformação do processo de negócios em sistemas de informação.
123
jBPM utiliza a abordagem Graph Oriented Programming (GOP) (SALATINO,
2009), que permite desacoplar a especificação do processo de negócio de cláusulas de
linguagens de programação. Nesta abordagem, processos de negócios são representados
visualmente através de um grafo. Para clarificar a abordagem GOP, considere o
processo descrito na Figura 83. Em uma abordagem de desenvolvimento tradicional, a
conversão do processo de negócio para cláusulas de linguagens de programação
envolveria a codificação de estruturas do tipo if e/ou switch ao longo do código fonte da
aplicação. Considere agora que, por algum motivo, chegou-se a conclusão que o
processo de negócio necessite de uma atividade extra. No caso da abordagem
tradicional, o desenvolvedor da aplicação terá que investigar o código fonte da
aplicação na busca pela cláusula que represente o ponto de transição entre atividades a
ser modificado, enquanto que na abordagem GOP o processo poderia ser modificado
por meio do editor de processos. Além disso, há um aumento no entendimento entre
analistas de negócios e desenvolvedores uma vez que ambos utilizam a mesma
linguagem para especificação de processos de negócio. Internamente, o jBPM interpreta
o processo de negócio e cria um ambiente que permite sua execução e monitoramento.
Para que isto seja possível, o grafo correspondente ao processo é representado através
de uma linguagem de marcação denominada jPDL (jBPM Process Description
Language) (SALATINO, 2009). Desta forma, a representação do processo descrito na
Figura 83 na linguagem jPDL pode ser observada na Figura 84.
Figura 83 - Editor gráfico de processos
124
Figura 84 - Linguagem jPDL para representação de processos
Tabela 26 - Estruturas oferecidas pelo do framework jBPM (adpatada de (SALATINO, 2009)) Estrutura Descrição
Start Representa o início do processo.
End Representa o término do processo.
State Empregado nos casos onde se deseja que a fluxo de execução do processo seja
interrompido até que algum evento externo ocorra.
Fork Utilizada nos casos onde se deseja dividir o fluxo de execução do processo de modo
a executar tarefas paralelamente.
Join Utilizada para unificação de fluxos distintos do processo. Desta forma, a execução do processo só é prosseguida caso todos os fluxos tenham sido concluídos.
Decision Representa pontos de desvio no processo com base em alguma variável a ser testada.
Node Utilizada para automatização de funcionalidades a serem executadas pelo
framework.
Task Node Representa tarefas que dependem da participação do usuário para sua conclusão
Mail Node Utilizada nos casos onde se deseja que o próprio framework se encarregue de enviar
e-mails.
ESB Service Utilizada nos casos onde se deseja conectar o processo a outras aplicações por meio da arquitetura Enterprise Service Bus.
Process State Representa sub-fluxos de tarefas, ou seja, a estrutura aponta para outro arquivo que
contem uma definição de processo.
Super State Utilizada quando se deseja agrupar as demais estruturas em blocos. Útil nos casos
em que um conjunto de estruturas represente uma fase do processo.
Transition Utilizada para conexão entre as demais estruturas
Ao visualizar a Figura 83, observa-se que existem 13 estruturas que podem ser adotadas para
desenho do processo de negócio. A descrição sobre a funcionalidade exercida por cada estrutura é
descrita na Tabela 26. Além das estruturas citadas anteriormente, jBPM possui ainda uma estrutura para
representação de atores (ou grupo de autores) responsáveis pela execução de uma tarefa. Isto permite que
processos possam ser executados de forma colaborativa. Cada ator possui um identificador e pode
participar de vários grupos de atores. No exemplo apresentado pela Figura 84, observa-se que a tarefa
atribuir atividade aos pesquisadores pode ser desempenhada somente pelo ator cujo identificador seja
125
coordenador (por meio da tag XML assignment), enquanto a tarefa elaborar protocolo pode ser
desempenhada por qualquer ator que faça parte do grupo pesquisadores.
Referências Bibliográficas
ALLEN, D. Seam In Action. 1 ed. Manning, 2009.
BPMI. Business Process Management Iniative, 2011. Disponível em
<http://www.bpmi.org/, 2011>, acesso em 10/01/2011.
GOOGLE. Google Web Toolkit, 2011. Disponível em <http://code.google.com/intl/pt-
BR/webtoolkit/>, acesso em 10/10/2011.
JBOSS. jBPM, 2011a. Disponível em <http://www.jboss.org/jbpm >, acesso em
10/01/2011.
JBOSS. JBoss Application Server, 2011b. Disponível em <http://jboss.org/jbossas >,
acesso em 10/01/2011.
JOOMLA. Joomla Content Management System, 2011. Disponível em
<http://www.joomla.org/>, acesso em 10/01/2011.
MYSQL. MySQL, 2011. Disponível em <http://www.mysql.com/>, acesso em
10/01/2011.
ORACLE. Java Enterprise Edition, 2011a. Disponível em
<http://www.oracle.com/technetwork/java/javaee/overview/index.html>, acesso
em 10/01/2011.
ORACLE. Java Server Faces, 2011b. Disponível em
<http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html>,
acesso em 10/01/2011.
ORACLE. Java Persistence API, 2011c. Disponível em
<http://www.oracle.com/technetwork/articles/javaee/jpa-137156.html>, acesso
em 10/01/2011.
ORACLE. Enterprise JavaBeans, 2011d. Disponível em
<http://www.oracle.com/technetwork/java/index-jsp-140203.html>, acesso em
10/01/2011.
PROJECTFORK. Projectfork, 2011. Disponível em <http://projectfork.net/>, acesso em
10/01/2011.
SALATINO, M. jBPM Developer Guide. 1 ed. Packt Publishing, 2009.
SEAM. JBoss Seam, 2011. Disponível em <http://www.seamframework.org>, acesso
em 10/01/2011.
126
W3C. Asynchronous Javascript And XML, 2011b. Disponível em
<http://www.w3.org/standards/webdesign/script.html >, acesso em 10/01/2011.
127
Apêndice III – Ferramentas de Gerência de
Referências Bibliográficas Identificadas
JabRef Categoria: Opensource
Plataforma: Windows, Linux, MacOS
Funcionalidades:
Trabalha com arquivos nos formatos BibTex, CSA, Refer/Endnote, ISI Web of Science,
SilverPlatter, Medline/Pubmed (xml), Scifinder, OVID, INSPEC, Biblioscape, Sixpack, JStor e
RIS;
Permite a realização de consultas nas coleções de referências (somente nos campos cadastrados);
Permite a classificação de referências por palavras-chave ou outros campos;
Permite a exportação de referências nos formatos HTML, Docbook, BibTeXML, MODS, RTF,
Refer/Endnote e OpenOffice.org;
Permite a criação de novos campos de dados;
Permite o armazenamento e visualização de arquivos PDF/PS;
Permite a inserção de citações nos editores LyX, Kile, LatexEDitor, Emacs, Vim e WinEdt;
Permite adição de informações (meta-dados) em documentos PDF;
Permite integração com o SGBD MySQL;
Permite o desenvolvimento de plugins com o objetivo de estender as funcionalidades oferecidas
pela ferramenta;
Permite a identificação de referências duplicadas.
EndNote Categoria: Proprietário
Plataforma: Windows, MacOS
Funcionalidades:
Possui serviço Web que permite a transferência de referências entre a ferramenta desktop e o
serviço Web (e o contrário também), busca por referências e identificação de referências
duplicadas;
Permite o compartilhamento de bibliotecas de referências com outros usuários;
Permite a criação de grupos dentro de uma biblioteca, cujo objetivo é facilitar a organização de
referências;
Possui plugin de integração com a ferramenta MS Word que permite que citações sobre
referências gerenciadas pelo EndNote sejam inseridas em documentos do Word (permitindo a
customização do formato de citação);
Permite a identificação de referências duplicadas;
Permite o armazenamento e visualização de arquivos PDF, imagens e outros tipos de arquivos;
Permite a importação de referências em diversos formatos;
Permite a exportação de referências bibliográficas nos formatos RTF, HTML, XML e TXT;
Permite a classificação de referências por palavras-chave ou outros campos (permite também
que termos sinônimos possam ser relacionados a um determinado termo);
Permite a realização de consultas nas coleções de referências (não ficou claro se a consulta é
feita somente a partir dos campos cadastrados ou se o documento PDF também é considerado na
consulta);
Permite a identificação de erros de ortografia em referências cadastradas;
Não foi possível identificar se a ferramenta permite a adição de novos campos;
Permite que consultas realizadas sejam salvas para posterior visualização.
Reference Manager Categoria: Proprietário
128
Plataforma: Windows
Funcionalidades:
Possui serviço Web que permite a transferência de referências entre a ferramenta desktop e o
serviço Web (não ficou claro se o contrário também é permitido);
Permite a identificação de referências duplicadas;
Possui plugin de integração com a ferramenta MS Word que permite que citações sobre
referências gerenciadas pelo Reference Manager sejam inseridas em documentos do Word
(permitindo a customização do formato de citação);
Permite a importação de referências em diversos formatos;
Permite a exportação de referências bibliográficas nos formatos RIS, MEDLARS, Comma
Delimited, Tab Delimited, XML;
Permite a identificação de erros de ortografia em referências cadastradas;
Permite a criação de novos campos de dados;
Permite o armazenamento e visualização de arquivos PDF, imagens e outros tipos de arquivos;
Permite a classificação de referências por palavras-chave ou outros campos (permite também
que termos sinônimos possam ser relacionados a um determinado termo);
Permite a realização de consultas nas coleções de referências (não ficou claro se a consulta é
feita somente a partir dos campos cadastrados ou se o documento PDF também é considerado na
consulta);
Permite a identificação de referências duplicadas;
Permite que consultas realizadas sejam salvas para posterior visualização.
Mendeley Categoria: Freeware
Plataforma: Windows, Linux, MacOS
Funcionalidades:
Permite o armazenamento e visualização de arquivos PDF, imagens e outros tipos de arquivos;
Permite a importação/exportação de referências nos formatos EndNote, BibTex, RIS;
Permite complementar dados sobre uma referência através de consulta ao Google Scholar;
Permite que resultados de provenientes de diversos sites (IEEEXplore, Google Scholar,
CiteseerX, SpringerLink, ScienceDirect etc.) sejam facilmente adicionados a biblioteca de
referências;
Possui serviço Web que permite a transferência de referências entre a ferramenta desktop e o
serviço Web (e o contrário também);
Possui serviço Web que permite realizar análises estatísticas sobre termos sinônimos, autores e
journals mais populares etc.;
Permite marcar referências como “favoritos”;
Permite a realização de consultas nas coleções de referências (também considerando o conteúdo
de documentos PDF);
Permite que trechos de um documento PDF possam ser destacados ou anotações sejam
adicionadas ao conteúdo do documento;
Permite a classificação de referências por palavras-chave ou outros campos;
Permite o compartilhamento de referências com outros usuários;
Possui plugin de integração com a ferramenta MS Word (possui integração também com as
ferramentas Open Office, Látex e editores de texto) que permite que citações sobre referências
gerenciadas pelo Reference Manager sejam inseridas em documentos do Word (permitindo a
customização do formato de citação);
Permite a criação de grupos dentro de uma biblioteca, cujo objetivo é facilitar a organização de
referências;
Possui integração com as ferramentas Zotero, CiteULike, EndNote e RefWorks;
Zotero Categoria: Opensource (plugin Firefox)
Plataforma: Todos
129
Funcionalidades:
Permite a identificação de referências duplicadas;
Permite o armazenamento e visualização de arquivos PDF, imagens e outros tipos de arquivos;
Permite que citações sobre referências gerenciadas pelo Zotero sejam inseridas em documentos
de texto (permitindo a customização do formato de citação);
Permite a criação de pastas dentro de uma biblioteca, cujo objetivo é facilitar a organização de
referências;
Permite que resultados de provenientes de diversos sites (e páginas Web) sejam facilmente
adicionados a biblioteca de referências;
Permite a classificação de referências por palavras-chave ou outros campos;
Permite que relacionamento entre referências seja criado;
Permite que consultas realizadas sejam salvas para posterior visualização;
Permite a sincronizar referências;
Permite a importação/exportação de referências em diversos formatos;
Possui serviço Web que permite a transferência de referências entre a ferramenta desktop e o
serviço Web (e o contrário também);
Permite que o serviço seja acessado através de dispositivos móveis;
Permite o compartilhamento de referências com outros usuários;
Permite a realização de consultas nas coleções de referências (também considerando o conteúdo
de documentos PDF);
Permite a criação de timelines, cujo objetivo é identificar o uso termos relevantes por faixas de
tempo;
Permite a geração de relatórios sobre referências;
Permite a adição de comentários/notas sobre uma determinada referência;
Permite o desenvolvimento de plugins com o objetivo de estender as funcionalidades oferecidas
pela ferramenta.
CiteULike Categoria: Serviço Web (gratuito)
Plataforma: Todos
Funcionalidades:
Permite a importação/exportação de referências nos formatos BibTex e RIS;
Permite o armazenamento e visualização de arquivos PDF, imagens e outros tipos de arquivos;
Permite a realização de consultas nas coleções de referências (também considerando o conteúdo
de documentos PDF);
Permite que resultados de provenientes de diversos sites (PubMed, SpringerLink, Google Reader
etc.) sejam facilmente adicionados a biblioteca de referências;
Permite a atribuição de prioridade na leitura de documentos inclusos na biblioteca;
Permite a identificação de referências duplicadas;
Permite a classificação de referências por palavras-chave ou outros campos;
Permite o compartilhamento de referências com outros usuários;
Permite a recomendação de novos documentos a serem lidos com base nas referências
cadastradas na biblioteca;
Permite identificar outros usuários que possuam bibliotecas que contenham referências
semelhantes;
Permite a adição de comentários/notas sobre uma determinada referência;
Permite que comentários sobre a referência sejam compartilhados entre os usuários da
ferramenta;
Permite a criação de uma rede de relacionamento entre os usuários que utilizam a ferramenta;
Permite que páginas que possuam documentos de interesse possam ser monitoradas com o
objetivo de identificar atualizações (também possui a opção de receber feeds RSS);
Oferece acesso a ferramentas de fórum e blog;
RefWorks Categoria: Serviço Web (pago)
Plataforma: Todos
130
Funcionalidades:
Permite a criação de pastas dentro de uma biblioteca, cujo objetivo é facilitar a organização de
referências;
Possui plugin de integração com a ferramenta MS Word (possui integração também com as
ferramentas Open Office, Látex e editores de texto) que permite que citações sobre referências
gerenciadas pelo RefWorks sejam inseridas em documentos do Word (permitindo a
customização do formato de citação);
Permite a importação/exportação de referências em diversos formatos;
Permite que referências sejam importadas através de feeds RSS;
Permite o armazenamento e visualização de arquivos PDF, imagens e outros tipos de arquivos
(embora esta opção, descrita no manual, não tenha sido encontrada após investigação da
ferramenta);
Permite o compartilhamento de referências com outros usuários;
Permite que consultas realizadas sejam salvas para posterior visualização;
Permite que resultados de provenientes de diversos sites sejam facilmente adicionados a
biblioteca de referências (desde que os resultados possuam como informação ISBN, PubMed ID
ou DOI);
Permite a identificação de referências duplicadas;
Permite que o serviço seja acessado através de dispositivos móveis.
Outras ferramentas identificadas
2collab;
Aigaion;
Bebop;
BibDesk;
Bibliographer;
Biblioscape;
BibSonomy;
Bibtex;
Bibus;
Bibwiki;
Bookends;
Cb2Bib;
Citavi;
Connotea;
GradeGuru Citation Manager;
I, Librarian;
Jumper 2.0;
KBib;
KBibTeX;
Papers;
Procite;
Pybliographer;
Refbase;
RefDB;
Referencer;
Reference Manager;
Scholar's Aid;
Sente;
Synapsen;
Wikindx.
131
Apêndice IV – Modelos Ontológicos de Estudos Secundários
Template de Protocolo de Revisão Sistemática
132
133
Apêndice V – Diagramas do Guia de Apoio ao Processo de Condução de Revisões Sistemáticas da Literatura
Sub-diagrama Preencher Dados Relacionados à Definição e Questão de Pesquisa
134
135
Sub-diagrama Preencher Dados Relacionados à Seleção de Estudos
136
Sub-diagrama Executar Piloto
137
138
Apêndice VI – Agrupamento dos Defeitos
Relativos à Inspeção da Ontologia de Estudos
Secundários, Guia de Apoio ao Processo de
Condução de Revisões Sistemáticas e
Documento de Requisitos para Construção de
Serviços de Apoio ao Planejamento, Execução e
Empacotamento de Revisões Sistemáticas
Defeitos da Ontologia de Estudos Secundários
Localização Conceito Tipo de
Defeito
Severidade Descrição
Sub-ontologia
de Estrutura do
Estudo
Objeto de
Estudo
Descrição
Incorreta de Conceitos
Problema leve - baixa
prioridade para consertá-lo
Mudar o nome do conceito para Objetivo
de Estudo, o objeto é algo dentro do objetivo, como uma técnica ou um
produto...
Sub-ontologia
de Estrutura do
Estudo
Questão de Pesquisa
Problema leve - baixa prioridade para
consertá-lo
Subir o atributo descrição para a "super classe", já que ambos os sub conceitos têm.
Sub-ontologia
de Estrutura do
Estudo
Hipótese Omissão de Conceitos
Problema grave - alta prioridade para
consertá-lo
Como descrever se a hipótese é nula ou alternativa?
Sub-ontologia
de
Procedimento
Metodológico
Escrita de Relatório de
Execução
Descrição Incorreta de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
Acho que esse conceito não existe, parece mais uma atividade que resulta em um
outro conceito (Relatório de Execução de
Revisão Sistemática)
Sub-ontologia
de
Procedimento
Metodológico
Formulação
de Protocolo
Descrição
Incorreta de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
Acho que esse conceito não existe, parece
mais uma atividade que resulta em um
outro conceito
Sub-ontologia
de Formulação
de Questão de
Pesquisa
String de
Busca
Omissão de
Conceitos
Problema leve - baixa
prioridade para consertá-lo
Faltou Coeficiente de Precisão
Sub-ontologia
de Seleção de
Estudos
Resultados da Revisão de
Estudos
Primários e Estudos
Primários
Selecionados
Relacionamento Incorreto entre
Conceitos
Problema leve - baixa prioridade para
consertá-lo
Deveria ser composição, já que o nome é "contem"?
Sub-ontologia
do Relatório de
Execução de
Revisão
Sistemática
Análise de
Sensitividade
Descrição
Incorreta de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
Não deveria ser "Sensibilidade"?
Sub-ontologia
de Formulação
de Questão de
Pesquisa
Questão Primária e
Secundária
Omissão de Conceitos
Problema grave - alta prioridade para
consertá-lo
Os conceitos de questão primário e secundário (caso houver) não estão
tratadas. Acredito que elas devam ser
herdadas do conceito Foco da Questão.
Sub-ontologia
de Seleção de
Fonte de
Estudos
String de
Busca
Adaptada
Relacionamento
Incorreto entre
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
Cada string de busca adaptada deveria
estar relacionada ao conceito Base de
Dados Identificadas, e não à Base de Dados.
Sub-ontologia
de
Sumarização
dos Resultados
Plotagem dos
dados
Relacionamento
Incorreto entre Conceitos
Problema grave - alta
prioridade para consertá-lo
Relacionamento com Sumarização dos
resultados deve ser de agregação, visto que Plotagem dos dados pode não existir
139
Sub-ontologia
de Formulação
de Questão de
Pesquisa
Population Relacionamento
Incorreto entre
Conceitos
Problema grave - alta
prioridade para
consertá-lo
Acredito neste casso que o relacionamento
seja de Composição (Mais forte que a
agregação, já que estamos seguindo a abordagem PICO). Outro ponto reside em
por que o conceito está em Inglês e todos
os outros em português?
Sub-ontologia
de Formulação
de Questão de
Pesquisa
Intervention Relacionamento
Incorreto entre
Conceitos
Problema grave - alta
prioridade para
consertá-lo
Acredito neste casso que o relacionamento
seja de Composição (Mais forte que a
agregação, já que estamos seguindo a abordagem PICO). Outro ponto reside em
por que o conceito está em Inglês e todos
os outros em português?
Sub-ontologia
de Formulação
de Questão de
Pesquisa
Outcome Relacionamento
Incorreto entre
Conceitos
Problema grave - alta
prioridade para
consertá-lo
Acredito neste casso que o relacionamento
seja de Composição (Mais forte que a
agregação, já que estamos seguindo a abordagem PICO). Outro ponto reside em
por que o conceito está em Inglês e todos
os outros em português?
Sub-ontologia
de Extração de
Dados
Execução
Piloto
Relacionamento
Incorreto entre
Conceitos
Problema grave - alta
prioridade para
consertá-lo
Parece ser obrigatório a execução de um
único piloto. Apesar de a descrição falar da
possibilidade de várias execuções, a representação não me fez entender que
podem ser executadas 0 .. * pilotos. Acho
que tentar colocar a cardinalidade pode melhorar
Sub-ontologia
de
Procedimento
Metodológico
Procedimento
metodológico
Omissão de
Conceitos
Problema grave - alta
prioridade para consertá-lo
O mais importante (talvez) dos
procedimentos metodológicos - a Revisão Sistemática - foi omitida. A diferença entre
este conceito e o conceito da Revisão
Quasi Sistemática é que na Revisão Sistemática existe uma baseline para
comparação, o que não acontece na Quasi
Sistemática
Sub-ontologia
de
Procedimento
Metodológico
Agregação Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Agregação Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Apoio
Ferramental
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Codificação
dos dados
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Escrita do relatório de
execução
Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Formulação
de protocolo
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Gerência da
unidade de análise
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Gerência de dados
omissos
Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Meta-análise Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Método de
análise
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Protocolo de revisão
sistemática
Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
140
Metodológico
Sub-ontologia
de
Procedimento
Metodológico
Relatório de
execução de revisão
sistemática
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Revisão quasi sistemática
Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Síntese Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Template de
Protocolo de Revisão
Sistemática
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Procedimento
Metodológico
Template de Relatório de
Execução de
Revisão Sistemática
Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Protocolo de
Revisão
Sistemática
Extração de
dados
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de Protocolo de
Revisão
Sistemática
Formulação de questão de
pesquisa
Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Protocolo de
Revisão
Sistemática
Seleção de
estudos
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Protocolo de
Revisão
Sistemática
Seleção de
fontes de estudos
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de Protocolo de
Revisão
Sistemática
Sumarização
dos
resultados
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Extração de
Dados
Dados
objetivos
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de Extração de
Dados
Dados
subjetivos
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de Extração de
Dados
Resolução de
divergências entre
revisores
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de Formulação
de Questão de
Pesquisa
Comparison Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Formulação
de Questão de
Pesquisa
Outcome Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Formulação
de Questão de
Pesquisa
Efeito Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito. Conceito
criado na Sub-ontologia de Estrutura do Estudo, porém o defeito foi detectado na
Sub-ontologia de Formulação de Questão
de Pesquisa, onde a inspeção foi realizada.
Sub-ontologia
de Formulação
de Questão de
Pesquisa
Aplicação Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito. Conceito
criado na Sub-ontologia de Estrutura do
Estudo, porém o defeito foi detectado na Sub-ontologia de Formulação de Questão
de Pesquisa, onde a inspeção foi realizada.
Sub-ontologia
de Seleção de
Estudos
Coeficiente de adequação
Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Seleção de
Estudos
Critérios de avaliação de
qualidade
Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
141
Sub-ontologia
de Seleção de
Estudos
Critérios
qualitativos
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Seleção de
Estudos
Critérios
quantitativos
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Seleção de
Estudos
Estudo in-
silico
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Seleção de
Estudos
Estudo in-
virtuo
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Seleção de
Estudos
Estudo in-
vitro
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Seleção de
Estudos
Estudo in-
vivo
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Seleção de
Fonte de
Estudos
Base de
dados
eletrônica
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Seleção de
Fonte de
Estudos
Base de
dados manual
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de Seleção de
Fonte de
Estudos
Base de dados
identificadas
Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de Seleção de
Fonte de
Estudos
Base de
dados
selecionadas
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Sumarização
dos Resultados
Análise de
sensitividade
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Sumarização
dos Resultados
Aplicação
dos
resultados
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Sumarização
dos Resultados
Apresentação
dos resultados em
tabelas
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Sumarização
dos Resultados
Métodos de análise
estatística
Omissão de Descrição de
Conceitos
Problema leve - baixa prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Sumarização
dos Resultados
Plotagem dos
dados
Omissão de
Descrição de
Conceitos
Problema leve - baixa
prioridade para
consertá-lo
O conceito não foi descrito
Sub-ontologia
de
Sumarização
dos Resultados
Variação de
conclusão entre
pesquisadores
Omissão de
Descrição de Conceitos
Problema leve - baixa
prioridade para consertá-lo
O conceito não foi descrito
142
Defeitos do Guia de Apoio ao Processo de Condução de Revisões Sistemáticas da Literatura
Localização Atividade Tipo de Defeito Severidade Descrição
Processo de
Condução de
Revisões
Sistemáticas
Iniciar Revisão Atividade que
Não Faz Parte do
Processo
Problema leve
- baixa
prioridade para consertá-
lo
Pra que serve essa atividade? Não seria
melhor deixa direto do nó de início para
a atividade seguinte? Ou algo é realizado nessa atividade?
Processo de
Condução de
Revisões
Sistemáticas
Reunir com Pesquisadores Sequenciamento Equivocado de
Atividade
Problema leve - baixa
prioridade
para consertá-lo
Atividades não paralelas
Preencher
Dados
Relacionados
a Definição e
Questão de
Pesquisa
Atividade que Não Faz Parte do
Processo
Problema leve - baixa
prioridade
para consertá-lo
Atividades não paralelas
Preencher
Dados
Relacionados
a Definição e
Questão de
Pesquisa
Definir Termos para a Estrutura Comparision
Nome Equivocado de
Atividade
Problema leve - baixa
prioridade
para consertá-lo
Comparision? --> Comparison
Preencher
Dados
Relacionados
a Definição e
Questão de
Pesquisa
Avaliar Necessidade de Restringir Design de
Estudos Primários
Sequenciamento Equivocado de
Atividade
Atividades antes do PICO, pois pode alterar População
Preencher
Dados
Relacionados
a Definição e
Questão de
Pesquisa
Avaliar Necessidade de Gerar String de Busca
Padrão a Partir da
Estrutura PICOS
Sequenciamento Equivocado de
Atividade
Problema grave - alta
prioridade
para consertá-lo
Deveria vir antes da definição do PICO, não faz sentido vir depois.
Preencher
Dados
Relacionados
a Seleção de
Estudos
Avaliar se os Critérios de Inclusão/Exclusão São
Suficientes
Omissão de Atividade
Problema grave - alta
prioridade
para consertá-lo
Na verdade, o problema é na decisão "Critérios São Suficientes?". Não tem o
fluxo em caso da resposta ser "não"
Executar
Piloto
Avaliar Sensibilidade da
String de Busca e Verificar se Artigos de
Controle Foram
Identificados
Sequenciamento
Equivocado de Atividade
Problema
grave - alta prioridade
para consertá-
lo
Só fazem sentido se foram determinados
controles no protocolo. Deve haver uma decisão antes.
Realizar
Análise dos
Resultados
Aplicar Procedimento
para Análise de
Sensitividade
Sequenciamento
Equivocado de
Atividade
Problema
grave - alta
prioridade para consertá-
lo
Falta fluxo para a atividade Verificar se
a Metodologia Escolhida Contempla
Meta-Análise
Preencher
Dados
Relacionados
a
Sumarização
dos
Resultados
Especificar Tabelas para Apresentação da
pontuação dos critérios de
qualidade dos estudos.
Omissão de Atividade
Problema leve - baixa
prioridade
para consertá-
lo
A tabelas para serem preenchidas, seuguindo os critérios de qualidade dos
estudos (caso houver), devem ser
listadas no protocolo.
Preencher
Dados
Relacionados
a Definição e
Questão de
Pesquisa
Avaliar
Necessidade/Possibilidade
de Definir Artigos de Controle
Sequenciamento
Equivocado de
Atividade
Problema
grave - alta
prioridade para consertá-
lo
Esta atividade deveria vir antes da
anterior (Avaliar Necessidade de Gerar
String de Busca Padrão a Partir da Estrutura PICOS), pois os artigos de
controle podem conter termos que deveriam estar na string de busca.
Executar
Piloto
Registrar mudança no
protocolo
Omissão de
Atividade
Problema
grave - alta prioridade
para consertá-
lo
Caso haja a necessidade de redefinir os
critérios para avaliação da qualidade de estudos primários, as mudanças devem
ser reportadas no protocolo.
Executar
Piloto
Registrar mudança no
protocolo
Omissão de
Atividade
Problema
grave - alta
prioridade para consertá-
Caso haja a necessidade de redefinir os
critérios para Hierarquização de estudos
primários, as mudanças devem ser reportadas no protocolo.
143
lo
Executar
Piloto
Registrar mudança no
protocolo
Omissão de
Atividade
Problema
grave - alta prioridade
para consertá-
lo
Caso haja a necessidade de redefinir
Dados a Serem Extraídos dos estudos primários, as mudanças devem ser
reportadas no protocolo.
Preencher
Dados
Relacionados
a
Sumarização
dos
Resultados
Verificar necessidade de
plotar dados
Problema
grave - alta
prioridade para consertá-
lo
Ausência do ponto de transição referente
a condição de guarda [não] para
"Plotagem de dados necessária?"
Preencher
Dados
Relacionados
a Definição e
Questão de
Pesquisa
Problema leve
- baixa prioridade
para consertá-
lo
Ausência de rótulos [sim][não] para
algumas condições de guarda
Preencher
Dados
Relacionados
a Seleção de
Fonte de
Estudos
Problema leve
- baixa prioridade
para consertá-
lo
Ausência de rótulos [sim][não] para
algumas condições de guarda
Executar
Piloto
Problema leve
- baixa prioridade
para consertá-
lo
Ausência de rótulos [sim][não] para
algumas condições de guarda
Executar
Piloto
Omissão de
Atividade
Problema
grave - alta
prioridade para consertá-
lo
O modelo não considera a atividade
"Avaliar precisão da string de busca"
Preencher
Dados
Relacionados
a Seleção de
Fonte de
Estudos
Avaliar Lista de Fontes de Estudos Obtida Após
Aplicação de Critérios de
Seleção
Sequenciamento Equivocado de
Atividade
Para os casos em que a Lista não for adequada deverá ser redefinido os
critérios para seleção de fontes de
estudos primários. Nestes casos fluxo de
controle deve direcionar a atividade
"Definir Critérios para Seleção de Fontes de Estudos Primários".
Preencher
Dados
Relacionados
a Seleção de
Estudos
Avaliar se os Critérios de
Inclusão/Exclusão São Suficientes
Sequenciamento
Equivocado de Atividade
Problema
grave - alta prioridade
para consertá-
lo
Redirecionamento do fluxo de controle
de negação ( quando os critérios não são suficientes ) deve ser realizado a partir
do simbolo de decisão para o inicio do
diagrama.
Preencher
Dados
Relacionados
a
Sumarização
dos
Resultados
Verificar Necessidade de
Plotar Dados
Sequenciamento
Equivocado de
Atividade
Problema leve
- baixa
prioridade para consertá-
lo
Nos casos em que não será necessario
eecutar a "Definir Procedimento para
Plotagem de dados" o fluxo de controle deve ser redirecionado para o fim do
diagrama.
Executar
Piloto
Avaliar aplicação do
Procedimento para Inclusão/Exclusao de
Estudos Primarios
Sequenciamento
Equivocado de Atividade
Problema
grave - alta prioridade
para consertá-
lo
Caso Criterio nâo foi aplicado
corretamente retornar o fluxo para atividade "Aplicar Procedimento para
Inclusao/Exclusao de estudos primarios"
Executar
Piloto
Avaliar aplicação do
Procedimento para
Avaliação de Qualidade de Estudos Primarios
Sequenciamento
Equivocado de
Atividade
Problema
grave - alta
prioridade para consertá-
lo
Caso Criterio nâo foi aplicado
corretamente retornar o fluxo para
atividade "Aplicar Procedimento para Avaliação de Qualidade de estudos
primarios"
Executar
Piloto
Avaliar aplicação do Procedimento para
Hieraquização de Estudos
Primarios
Sequenciamento Equivocado de
Atividade
Problema grave - alta
prioridade
para consertá-lo
Caso Criterio nâo foi aplicado corretamente retornar o fluxo para
atividade "Aplicar Procedimento para
Hierarquização de estudos primarios"
Realizar
Análise dos
Resultados
Relatar possiveis ameaças
a validade de Construção
Nome
Equivocado de Atividade
Problema leve
- baixa prioridade
para consertá-
lo
Alterar o nome da atividade para
"Relatar possiveis ameaças a validade do Construto"
144
Defeitos do Documento de Requisitos
Localização Componente Tipo de
Defeito
Severidade Descrição
RF02 Planejamento Omissão Problema leve -
baixa prioridade para consertá-lo
Na RN02 eu sugiro que um perfil de 'Lider'
também seja criado além dos desenvolvedor do protocolo e revisor.
RF02 Planejamento Omissão Problema grave -
alta prioridade para consertá-lo
Falta definir os papéis desenvolvedor do
protocolo e revisor
RF03 Planejamento Ambiguidade Problema leve - baixa prioridade
para consertá-lo
Não está claro se o mecanismo Kappa seria utilizado como opção default para resolução
de divergências entre revisores, no caso em
que o desenvolvedor do protocolo não especifique nenhum mecanismo.
RF06 Planejamento Ambiguidade Problema grave -
alta prioridade para consertá-lo
Não está claro o que seria a validade interna
e externa da revisão.
RF07 Planejamento Omissão Problema leve -
baixa prioridade para consertá-lo
Além do tempo, o software poderia
armazenar o usuário que está executando a atividade também.
RF10 Planejamento Ambiguidade Problema leve -
baixa prioridade para consertá-lo
As modificações informadas e justificadas
formariam uma espécie de controle de versão do protocolo?
RF15 Planejamento Ambiguidade Problema grave -
alta prioridade para consertá-lo
Não é possível determinar que tipos de
mecanismos de comunicação o software poderá prover. É necessário explicitar
melhor.
RF22 Planejamento Informação Estranha
Problema catastrófico – é
imperativo
consertá-lo
O requisito RF25 é igual ao requisito RF22.
RF28 Planejamento Omissão Problema leve -
baixa prioridade
para consertá-lo
Novo Requisito - Para os casos em que o
estudo secundario informado for do tipo
revisão sistematica no item do protocolo do padrão o Pico o software deverá considerar o
elemento comparision como obrigatório.
RF01 Execução Omissão Problema leve - baixa prioridade
para consertá-lo
Falta definir o papel de executor do protocolo
RF02 Execução Ambiguidade Problema leve - baixa prioridade
para consertá-lo
O que se entende por colaborativa neste contexto? Seria comunicação entre os
revisores?
RF04 Execução Ambiguidade Problema leve - baixa prioridade
para consertá-lo
Não é possível determinar que tipos de mecanismos de comunicação o software
poderá prover. É necessário explicitar
melhor.
RF08 Execução Omissão Problema grave -
alta prioridade
para consertá-lo
Falta incluir o laudo de execução do piloto,
entre os documentos a serem empacotados.
Também é importante que sejam listados os artigos de controle selecionados no estudo.
145
Apêndice VII – Respostas dos Participantes do
Estudo de Avaliação da Ferramenta SSPlan
Grupo 1
Pesquisador A
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a utilizar a SSPlan Concordo
parcialmente
Consegui utilizar a SSPlan da forma que eu queria Discordo
totalmente
Entendi o que acontecia na minha interação com a
SSPlan
Discordo
amplamente
Foi fácil lembrar como planejar uma revisão
sistemática com o uso da SSPlan
Discordo
amplamente
Utilidade
Foi fácil lembrar como planejar uma revisão
sistemática com o uso da SSPlan
Concordo
parcialmente
Considero SSPlan útil para realizar o planejamento de
protocolos de revisão sistemática
Discordo
totalmente
A SSPlan permite realizar o planejamento do protocolo
da revisão sistemática em conformidade com o
processo definido no guia de apoio
Concordo
parcialmente
O uso da SSPlan permite melhorar o desempenho do
pesquisador durante o planejamento do protocolo da
revisão sistemática
Discordo
totalmente
146
Pesquisador B
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a utilizar a
SSPlan
Concordo
parcialmente
Os textos dos linques não são intuitivos. A falta de um
linque para ajuda e um glóssário também foi sentida.
Consegui utilizar a SSPlan da
forma que eu queria
Discordo
amplamente
A ferramenta tem o propósito de guiar o pesquisador para
planejar seu protocolo. Mas não poder desfazer ações feitas
não permitiu que o procolo ficasse exatamente da forma
como intencionava. (Ex: Marquei sem querer que não faria
avaliação qualitativa e não pude mudar de idéia)
Entendi o que acontecia na minha
interação com a SSPlan
Concordo
amplamente
Foi fácil lembrar como planejar
uma revisão sistemática com o
uso da SSPlan
Concordo
amplamente
Utilidade
Foi fácil lembrar como planejar
uma revisão sistemática com o
uso da SSPlan
Concordo
amplamente
Considero SSPlan útil para
realizar o planejamento de
protocolos de revisão sistemática
Concordo
parcialmente
Não entendi exatamente em que a ferramenta é melhor que
um template. Mas acredito que existam mais funcionalidades
que ainda não foram implementadas. O conceito de
workflow poderia ser melhor explorado.
A SSPlan permite realizar o
planejamento do protocolo da
revisão sistemática em
conformidade com o processo
definido no guia de apoio
Concordo
amplamente
O uso da SSPlan permite melhorar
o desempenho do pesquisador
durante o planejamento do
protocolo da revisão sistemática
Concordo
amplamente
Desde que permita que o protocolo seja editado
completamente conforme a vontade do pesquisador.
147
Grupo 2
Pesquisador C
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a utilizar a SSPlan Concordo
totalmente
Consegui utilizar a SSPlan da forma que eu queria Concordo
amplamente
Entendi o que acontecia na minha interação com a
SSPlan
Concordo
totalmente
Foi fácil lembrar como planejar uma revisão
sistemática com o uso da SSPlan
Concordo
totalmente
Utilidade
Foi fácil lembrar como planejar uma revisão
sistemática com o uso da SSPlan
Concordo
totalmente
Considero SSPlan útil para realizar o planejamento de
protocolos de revisão sistemática
Concordo
totalmente
A SSPlan permite realizar o planejamento do protocolo
da revisão sistemática em conformidade com o
processo definido no guia de apoio
Concordo
totalmente
O uso da SSPlan permite melhorar o desempenho do
pesquisador durante o planejamento do protocolo da
revisão sistemática
Concordo
amplamente
148
Pesquisador D
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a
utilizar a SSPlan
Discordo
parcialmente
O menu está quebrando e o logotipo está abaixo do sistema, o que leva
a confundi um pouco. Também não é intuitivo os botões em texto, do
lado direito, com a definição do projeto, do lado esquerdo.
Consegui utilizar a
SSPlan da forma que eu
queria
Concordo
parcialmente
Consegui, mas com um certo esforço. Tive receio de acrescentar
tarefas e me ative as atividades do protocolo.
Entendi o que acontecia
na minha interação com
a SSPlan
Concordo
parcialmente
Sim, entendi. Depois de aprendido, o restante se comporta igualmente,
mas tem alguns pontos que podem ser revistos, para melhorar a
navegabilidade.
Foi fácil lembrar como
planejar uma revisão
sistemática com o uso
da SSPlan
Discordo
amplamente
Na verdade, precisei preencher totalmente o protocolo papel, para me
guiar. A falta de saber o que tem por vir e o não ter como voltar,
dificulta o entendimento do protocolo completo.
Utilidade
Foi fácil lembrar como
planejar uma revisão
sistemática com o uso
da SSPlan
Concordo
parcialmente
O sistema é bom, mas precisa melhorar. Ter a visibilidade do protolo
completo, com antecedência, assim como as perguntas que estão por
vir. Talvêz uma divisão por capítulos facilitaria. Ainda não terminei o
preenchimento, estou com dúvidas na pergunta de meta-análise e ainda
assim, não sei o que falta, mesmo tendo preenchido tantos campos. Não
sei se preenchi os campos corretamente, ou de forma redundante. O não
ter o "back", a navegação para trás, dificulta este tipo de ajuste.
Considero SSPlan útil
para realizar o
planejamento de
protocolos de revisão
sistemática
Concordo
parcialmente
Acredito ser bem legal, tem potencialidade, mas precisa ter sua
nevegação melhorada.
A SSPlan permite
realizar o planejamento
do protocolo da revisão
sistemática em
conformidade com o
processo definido no
guia de apoio
Concordo
totalmente
Com certeza. É rígido e vai orientar. Conforme viemos aprendendo e
vendo neste ano, o campo de experimentação de TI é flexível e
suscetível a erros. Este tipo de protocolo formal irá orientar.
O uso da SSPlan
permite melhorar o
desempenho do
pesquisador durante o
planejamento do
protocolo da revisão
sistemática
Discordo
parcialmente
Não acredito. O saber realizar a revisão é inerente ao processo, não a
ferramenta. Quem não conseguir sem a ferramenta, não irá conseguir
com a ferramenta. A ferramenta vem para apoiar e facilitar, se houver
estes ajustes.
149
Grupo 3
Pesquisador E
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a utilizar a
SSPlan
Concordo
totalmente
A aula de como utilizar o SSPlan foi bem ministrada, com
exemplos. Além disso, as tarefas são simples (basta responder o
que é pedido.
Consegui utilizar a SSPlan da
forma que eu queria
Concordo
parcialmente
Como o protocolo foi gerado por 3 pesquisadores, preferiu-se
juntar os pesquisadores numa mesma máquina e preencher o
protocolo juntos, deixando de lado o caráter colaborativo
Entendi o que acontecia na
minha interação com a SSPlan
Concordo
totalmente
Por ter acesso a um "fluxograma" explicando os passos da
iteração com o SSPlan, eu pude entender com mais facilidade.
Mas o único pré-requisito para utilizar a aplicação seria
entender conceitos de uma revisão sistemática.
Foi fácil lembrar como planejar
uma revisão sistemática com o
uso da SSPlan
Concordo
parcialmente
A especificação de tabelas para aprensentação de resultados
poderia ser melhor.
Utilidade
Foi fácil lembrar como planejar
uma revisão sistemática com o
uso da SSPlan
Concordo
totalmente
O programa auxilia em cada etapa da elaboração de um
protocolo de revisão sistemática.
Considero SSPlan útil para
realizar o planejamento de
protocolos de revisão
sistemática
Concordo
amplamente O único problema seria o idioma, que é sempre em português.
A SSPlan permite realizar o
planejamento do protocolo da
revisão sistemática em
conformidade com o processo
definido no guia de apoio
Concordo
parcialmente
Não comparei os passos do SSPlan com o "fluxograma" que ele
deveria seguir, mas pelo que eu ouvi dos integrantes do meu
grupo, nem tudo saiu como deveria.
O uso da SSPlan permite
melhorar o desempenho do
pesquisador durante o
planejamento do protocolo da
revisão sistemática
Concordo
totalmente Evita erros e esquecimentos.
150
Pesquisador F
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a
utilizar a SSPlan
Concordo
parcialmente
Embora algumas partes sejam intuitivas, algumas questões de
usabilidade podem ser melhoradas. Por exemplo, o uso de dicas
(tooltips) sobre determinados itens permitiria saber, de antemão, qual é
a funcionalidade implementada por eles.
Consegui utilizar a
SSPlan da forma que eu
queria
Discordo
parcialmente
Acho que faltaram informações mais completas para pessoas que nunca
realizaram uma revisão sistemática. Embora exista uma ontologia que
apóia o processo, é preciso que todos os conceitos estejam claramente
descritos. Se o objetivo da ferramenta é apoiar o processo, considero
que eu não deveria precisar ir a outro lugar entender o conceito.
Entendi o que acontecia
na minha interação com
a SSPlan
Concordo
parcialmente
Uma coisa que realmente incomoda é não saber quais são os próximos
passos. A partir de um determinado momento, tivemos que fazer com a
ontologia do lado, porque vimos que estávamos preenchendo alguns
dados antecipadamente, e eles eram solicitados em seguida. Como não
podíamos voltar atrás (isto foi realmente uma limitação grave), senti
falta desta visão geral de "em que momento do processo eu estou".
Foi fácil lembrar como
planejar uma revisão
sistemática com o uso
da SSPlan
Discordo
amplamente
A ferramenta foi utilizada duas semanas depois de a turma ser
apresentada a alguns conceitos e formalismos. Ainda "não entrou no
sangue". Talvez a ferramenta apoie especialistas em RS, mas não acho
que seja adequada a pessoas que estejam iniciando (embora a
estruturação que "força" o seguimento ao processo seja bastante útil
para não "atropelar" as etapas).
Utilidade
Foi fácil lembrar como
planejar uma revisão
sistemática com o uso
da SSPlan
Idem acima?
Considero SSPlan útil
para realizar o
planejamento de
protocolos de revisão
sistemática
Concordo
amplamente
É uma iniciativa muito interessante e que merece ser continuada.
Embora seja um protótipo acadêmico, o próprio grupo ESE e os demais
grupos da COPPE poderiam se beneficiar - e muito - com as facilidades
que a ferramenta busca trazer.
A SSPlan permite
realizar o planejamento
do protocolo da revisão
sistemática em
conformidade com o
processo definido no
guia de apoio
Discordo
parcialmente
Encontrei duas inconsistências (pelo que me lembro) entre o processo e
a ferramenta. Uma inconsistência foi na ordem de algumas tarefas,
alguns passos que estão mais adiante são antecipados, e a outra
inconsistência está no fork das atividades, que só vi acontecer ao final
(no processo ocorre mais de uma vez).
O uso da SSPlan
permite melhorar o
desempenho do
pesquisador durante o
planejamento do
protocolo da revisão
sistemática
Concordo
amplamente
O fato de se ter um processo bem definido (e, pelo que disseram,
avaliado) ajuda para que o pesquisador não tenha que "ir e voltar" em
algumas atividades por não saber a ordem exata de sua execução. No
entanto, para avaliar o desempenho, creio que este estudo não seja
suficiente.
151
Pesquisador G
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a
utilizar a SSPlan
Concordo
amplamente
Alguns campos como 'design da tabela tal' não me parecem adequados.
Não estava claro como preenche-los, e não foi útil (no final das contas,
tive que colocar a tabela manualmente no documento gerado)
Consegui utilizar a
SSPlan da forma que eu
queria
Concordo
parcialmente
A funcionalidade de Adcionar a atividade e depois preencher fica
bastante cansativa com o uso. Podia ter único botão "Adicionar e
Preencher". Alguma atividades que o preenchimento é apenas um
checkbox também poderiam ser concatenas com outras, para reduzir o
trabalho de preenche-las (se eu marquei o checkbox, dizendo que vou
realizar tal atividade, então faria sentido que o preenchimento dessa
atividade já ocorresse na mesma tela
Entendi o que acontecia
na minha interação com
a SSPlan
Concordo
totalmente
Ao adcionar novos itens (ex: critérios de exclusão) o sistema não
mostrar nenhuma indicação de que está carregando.. Eu clicava em
incluir, e nada acontecia, e depois de algum tempo o critério era
incluído.
Foi fácil lembrar como
planejar uma revisão
sistemática com o uso
da SSPlan
Concordo
totalmente
Utilidade
Foi fácil lembrar como
planejar uma revisão
sistemática com o uso
da SSPlan
Concordo
totalmente
Considero SSPlan útil
para realizar o
planejamento de
protocolos de revisão
sistemática
Concordo
totalmente
A SSPlan permite
realizar o planejamento
do protocolo da revisão
sistemática em
conformidade com o
processo definido no
guia de apoio
Concordo
parcialmente
Algumas coisas que existiam no procolo de exemplo fornecido, não
estavam na ferramenta. Além disso, a existencia de uma estrutura PICO
e uma string de busca para cada pergunta (primaria/secundária) não me
pareceu adequado ao que aprendi em sala. Deveria estar claro que a
string de busca da questão secundária deve ser um sub-conjunto dos
resultados da questão primária.
O uso da SSPlan
permite melhorar o
desempenho do
pesquisador durante o
planejamento do
protocolo da revisão
sistemática
Concordo
amplamente
Algumas melhorias precisam ser feitas para melhorar a eficiencia de
uso (vide comentários acima)
152
Grupo 4
Pesquisador H
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a utilizar a
SSPlan
Concordo
amplamente
Ao começo tivemos dificuldades com a edição das tarefas já
preenchidas, mas já foi solucionado
Consegui utilizar a SSPlan da
forma que eu queria
Concordo
parcialmente
Não foi fácil preencher todas as tarefas consecutivamente, já
que trabalhamos em duplas e cada quem tinha tarefas diferentes
Entendi o que acontecia na
minha interação com a SSPlan
Concordo
amplamente
Foi fácil lembrar como planejar
uma revisão sistemática com o
uso da SSPlan
Concordo
totalmente Muito bom, tem todos os passos para a SLR
Utilidade
Foi fácil lembrar como planejar
uma revisão sistemática com o
uso da SSPlan
pergunta repetida
Considero SSPlan útil para
realizar o planejamento de
protocolos de revisão
sistemática
Concordo
amplamente
A SSPlan permite realizar o
planejamento do protocolo da
revisão sistemática em
conformidade com o processo
definido no guia de apoio
Concordo
totalmente
O uso da SSPlan permite
melhorar o desempenho do
pesquisador durante o
planejamento do protocolo da
revisão sistemática
Concordo
totalmente
Reduze o tempo de planejamento, devido a que o pesquisador
já conhece que tarefas tem que fazer
153
Pesquisador I
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a utilizar a
SSPlan
Concordo
parcialmente
Consegui utilizar a SSPlan da forma
que eu queria
Discordo
parcialmente
Não foi possível editar seções do protocolo já salvos. Além
disto, a ferramenta permitiu acesso indevido ao resultado
de outro grupo.
Entendi o que acontecia na minha
interação com a SSPlan
Concordo
amplamente
A ferramenta permite ao usuário perceber o processo de
planejamento de um estudo secundário.
Foi fácil lembrar como planejar
uma revisão sistemática com o uso
da SSPlan
Discordo
parcialmente
Algumas limitações da ferramenta tornaram seu uso
inapropriado, trazendo consigo mais problema do que
solução. A simples edição de um template no formato
Word resultaria no mesmo documento com maior
facilidade.
Utilidade
Foi fácil lembrar como planejar
uma revisão sistemática com o uso
da SSPlan
Concordo
parcialmente
Considero SSPlan útil para realizar
o planejamento de protocolos de
revisão sistemática
Discordo
amplamente
A ferramenta precisa ser bastante melhorada para permitir
maior produtividade no processo de planejamento.
A SSPlan permite realizar o
planejamento do protocolo da
revisão sistemática em
conformidade com o processo
definido no guia de apoio
Concordo
totalmente
O uso da SSPlan permite melhorar
o desempenho do pesquisador
durante o planejamento do
protocolo da revisão sistemática
Discordo
totalmente
154
Grupo 5
Pesquisador J
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a utilizar a SSPlan Concordo
amplamente
Consegui utilizar a SSPlan da forma que eu
queria
Concordo
amplamente
Entendi o que acontecia na minha interação
com a SSPlan
Concordo
amplamente
Foi fácil lembrar como planejar uma revisão
sistemática com o uso da SSPlan
Concordo
parcialmente
Utilidade
Foi fácil lembrar como planejar uma revisão
sistemática com o uso da SSPlan
Concordo
parcialmente
Falta uma ajuda baseada em uma revisão
sistemática em cada tarefa, explicitanto exemplos.
E uma ideia do todo em formato de tutorial.
Considero SSPlan útil para realizar o
planejamento de protocolos de revisão
sistemática
Concordo
totalmente
A SSPlan permite realizar o planejamento do
protocolo da revisão sistemática em
conformidade com o processo definido no
guia de apoio
Concordo
totalmente
O uso da SSPlan permite melhorar o
desempenho do pesquisador durante o
planejamento do protocolo da revisão
sistemática
Concordo
totalmente
155
Pesquisador K
Quesito Questão Avaliação Comentários
Facilidade
de Uso
Foi fácil aprender a utilizar a SSPlan Concordo
totalmente
Com o treinamento dado, foi bem fácil utilizar a
ferramenta.
Consegui utilizar a SSPlan da forma que eu
queria
Concordo
parcialmente
Durante a execução de alguns passos ocorreram
erros que limitaram um pouco o trabalho e a falta
da opção de editar contribuiu um pouco para isso
também.
Entendi o que acontecia na minha interação
com a SSPlan
Concordo
totalmente
Foi fácil lembrar como planejar uma revisão
sistemática com o uso da SSPlan
Concordo
amplamente Se tivesse um help ajudaria mais um pouco.
Utilidade
Foi fácil lembrar como planejar uma revisão
sistemática com o uso da SSPlan
Concordo
amplamente Se tivesse um help ajudaria mais um pouco.
Considero SSPlan útil para realizar o
planejamento de protocolos de revisão
sistemática
Concordo
totalmente
A SSPlan permite realizar o planejamento do
protocolo da revisão sistemática em
conformidade com o processo definido no
guia de apoio
Concordo
totalmente
O uso da SSPlan permite melhorar o
desempenho do pesquisador durante o
planejamento do protocolo da revisão
sistemática
Concordo
totalmente