Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DA BAHIA-UFBADEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
INSTITUTO DE MATEMÁTICA E ESTATÍSTICA
WELBERT AZEVEDO SERRA
AVALIAÇÃO EXPERIMENTAL E MELHORIA DO GUIDEAUTOMATOR, UMAFERRAMENTA PARA CRIAÇÃO DE MANUAIS DE USUÁRIO
SALVADOR2017
Welbert Azevedo Serra
Avaliação experimental e melhoria do GuideAutomator, uma ferramenta para criação demanuais de usuário
Monografia apresentada como requisito parcialpara obtenção do grau de Bacharel em Instituto deMatemática e Estatística da Universidade Federalda Bahia - UFBA, Departamento de Ciência daComputação.
Orientador: Prof. Dr. Rodrigo Rocha Gomese Souza
Salvador2017
Aos meus pais, pelo incentivo e apoio constan-tes.
AGRADECIMENTOS
Agradeço especialmente aos meus pais, Bernadete Serra e Wellington Serra, que abdica-ram de muitas coisas por fornecer uma educação de qualidade para mim e minhas conquistasse tornaram também as suas conquistas. Gostaria também de agradecer a todos os meus pro-fessores/professoras, desde os dias escolares até a graduação na universidade, por todos osensinamentos. Agradeço a Universidade Federal da Bahia (UFBA) por todas as oportunidadesoferecidas, ao meu orientador Rodrigo Rocha Gomes e Souza pela orientação de todo estetrabalho, meus amigos e colegas pela companhia ao longo dos anos, para minha namoradaMayara Silva que trilhou esse caminho comigo e minha família por todo o apoio.
O fator decisivo para vencer o maior obstáculoé, invariavelmente, ultrapassar o obstáculoanterior.
Henry Ford
RESUMO
O GuideAutomator é uma ferramenta que utiliza texto e código-fonte para, de maneira auto-matizada, documentar um sistema web através de capturas de tela. Ele foi criado para reduziro custo de elaboração e manutenção de manuais para usuários. Para avaliar se a ferramentaproposta atende esse propósito, realizamos experimentos para analisar a eficiência e a eficá-cia do GuideAutomator em relação a método tradicional na elaboração de documentação ena evolução dessa documentação para uma nova versão dessa mesma documentação. Alémdisso, evoluímos o protótipo inicial da ferramenta para torná-la mais robusta e desenvolvemosuma extensão de navegador para tornar mais fácil o uso do GuideAutomator independente doconhecimento do usuário sobre web. Na análise dos resultados do experimento foi observadoque o GuideAutomator obteve menos eficiência e a mesma eficácia ao longo de duas versõesda documentação, contudo, foi percebido uma queda muito acentuada no tempo de execuçãoutilizado pelo GuideAutomator de uma versão para outra e ainda foi notado que pessoas commenos conhecimento em desenvolvimento web não tiveram seu desempenho prejudicado aoutilizar o GuideAutomator.
Palavras-chave: , , , .
ABSTRACT
GuideAutomator is a tool that uses text and source code to automate documenting a web systemthrough screen captures. It was created to reduce the cost of developing and maintaining manualsfor users. To evaluate if the proposed tool fulfills this purpose, we carried out experiments toanalyze the efficiency and effectiveness of GuideAutomator in relation to traditional methods inthe elaboration of documentation and in the evolution of this documentation to a new version. Inaddition, we have evolved the initial prototype of the tool to make it more robust, and we havedeveloped a browser extension to make it easier to use the GuideAutomator independent of theuser’s knowledge about web development. In the analysis of the results of the experiment it wasobserved that GuideAutomator obtained less efficiency and the same effectiveness throughouttwo versions of the documentation; however, we noticed a very sharp fall in the runtime used bythe GuideAutomator from one version to another and also that people with less knowledge inweb development did not have their performance impaired when using GuideAutomator.
Keywords: , , , .
LISTA DE FIGURAS
Figura 1 – Fluxo do GuideAutomator 1.0 (OLIVEIRA; SOUZA, 2016) . . . . . . . . . 17Figura 2 – Exemplo de sintaxe Markdown . . . . . . . . . . . . . . . . . . . . . . . . 18Figura 3 – Inspecionar elemento no Google Chrome . . . . . . . . . . . . . . . . . . . 20Figura 4 – Copiar Css Selector no Google Chrome . . . . . . . . . . . . . . . . . . . . 20Figura 5 – Exemplo de chamada pelo terminal (OLIVEIRA; SOUZA, 2016) . . . . . . 21Figura 6 – Exemplo de código do GuideAutomator 1.0 . . . . . . . . . . . . . . . . . 21Figura 7 – Exemplo de saída do GuideAutomator 1.0 . . . . . . . . . . . . . . . . . . 22Figura 8 – Exemplo de trecho GuideAutomator . . . . . . . . . . . . . . . . . . . . . 24Figura 9 – Exemplo de chamada pelo terminal . . . . . . . . . . . . . . . . . . . . . . 25Figura 10 – Demonstração da extensão do GuideAutomator . . . . . . . . . . . . . . . 27Figura 11 – Demonstração da extensão do GuideAutomator . . . . . . . . . . . . . . . 28Figura 12 – Fluxo do GuideAutomator 2.4 . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 13 – Processo Experimental (WOHLIN, 2012) . . . . . . . . . . . . . . . . . . 33Figura 14 – Exemplo de imagem modelo para o experimento . . . . . . . . . . . . . . . 35Figura 15 – Gráfico Tempo (minutos) X Versão MyBB . . . . . . . . . . . . . . . . . . 38Figura 16 – Gráfico Acertos X Versão MyBB . . . . . . . . . . . . . . . . . . . . . . . 38Figura 17 – Gráfico Tempo X Versão MyBB . . . . . . . . . . . . . . . . . . . . . . . 41Figura 18 – Gráfico Boxplot para o tempo utilizado na versão MyBB 2015 . . . . . . . 41Figura 19 – Gráfico Boxplot para o tempo utilizado na versão MyBB 2017 . . . . . . . 42Figura 20 – Gráfico Acertos X Versão MyBB . . . . . . . . . . . . . . . . . . . . . . . 43Figura 21 – Gráfico Boxplot para acerto utilizado na versão MyBB 2015 . . . . . . . . 43Figura 22 – Gráfico Boxplot para acerto utilizado na versão MyBB 2017 . . . . . . . . 44Figura 23 – Gráfico Conhecimento Web X Tempo (minutos) . . . . . . . . . . . . . . . 45Figura 24 – Gráfico de dispersão de Conhecimento Web X Tempo (minutos) para versão
MyBB 2015 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Figura 25 – Gráfico de dispersão de Conhecimento Web X Tempo (minutos) para versão
MyBB 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figura 26 – Gráfico Conhecimento Web X Nº Acerto . . . . . . . . . . . . . . . . . . . 46Figura 27 – Gráfico de dispersão de Conhecimento Web X Acerto para versão MyBB 2015 47Figura 28 – Gráfico de dispersão de Conhecimento Web X Acerto para versão MyBB 2017 47Figura 29 – Gráfico do feedback dos participantes sobre a extensão . . . . . . . . . . . 48
LISTA DE TABELAS
Tabela 1 – Lista de comandos do GuideAutomator 1.0.14 . . . . . . . . . . . . . . . . 23Tabela 2 – Exemplos de parâmetros CLI do GuideAutomator 2.4.0 . . . . . . . . . . . 26Tabela 3 – Lista de comandos do GuideAutomator 2.4.0 . . . . . . . . . . . . . . . . . 31
LISTA DE ABREVIATURAS E SIGLAS
IHC Interação humano-computador
GA GuideAutomator
NPM Node Package Manager
PDF Portable Document Format
HTML HyperText Markup Language
XHTML eXtensible Hypertext Markup Language
CLI Command-line interface
RTE Rich Text Editor
RTF Rich Text Format
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 CONCEITOS GERAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 GuideAutomator 1.0 e Tecnologias usadas . . . . . . . . . . . . . . . . . . 16
2.1.1 Markdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2 Selenium WebDriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3 Unique CSS Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.4 Funcionamento do GuideAutomator 1.0 . . . . . . . . . . . . . . . . . . . . 20
2.1.5 Análise experimental do GuideAutomator 1.0 . . . . . . . . . . . . . . . . 22
3 EVOLUÇÃO DO GUIDEAUTOMATOR . . . . . . . . . . . . . . . . . 24
3.1 Extração de bloco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Linha de comando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Extensão de navegador do GuideAutomator . . . . . . . . . . . . . . . . . 25
3.4 Re-escrita do código fonte . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Comandos GuideAutomator 2.4 . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Correções e melhorias menores . . . . . . . . . . . . . . . . . . . . . . . . 30
4 EXPERIMENTO CONTROLADO . . . . . . . . . . . . . . . . . . . . . 32
4.1 Conceito e Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.2 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.3 Operação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.4 Análise e Interpretação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.5 Apresentação e Empacotamento . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Experimento Piloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Experimento na turma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Análise de eficiência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2 Análise de eficácia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.3 Análise de perfil e feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
APÊNDICE A – TERMO DE CONSENTIMENTO . . . . . . . . . . . . . . . . . . 51
APÊNDICE B – QUESTIONÁRIO DE CARACTERIZAÇÃO DO PARTICIPANTE 54
APÊNDICE C – QUESTIONÁRIO DE PÓS-EXPERIMENTO . . . . . . . . . . . 56
APÊNDICE D – INFORMAÇÕES SOBRE O PERFIL DOS PARTICIPANTES . . 57
APÊNDICE E – DOCUMENTO ELABORADO NO EXPERIMENTO . . . . . . . 59
14
1 INTRODUÇÃO
Documentar é o ato de registrar informações em meio físico ou digital, gerando um
documento. De acordo a ISO 9000, um conjunto de documentos é denominado documentação
(ABNT, 2005). Um ato relativamente simples, nos dias atuais, vem tomando novas dimensões
e assumindo um lugar de grande importância em diversas áreas, principalmente na engenharia
de software. Documentar tornou-se, então, requisito de qualidade de um sistema. Por isso, é
necessário se ater na elaboração destes, quer seja a lista de requisitos do sistema ou manual para
o usuário.
Jakob Nielsen, PhD em IHC pela Technical University of Denmark em Copenhagen e
responsável por criar uma das mais importantes heurísticas de usabilidade, elenca a documentação
como facilitador na compreensão de qualquer sistema por um usuário (NIELSEN, 1992).
Em contraponto, implementar documentação e sistema de ajuda sempre acaba sendo um
ponto deixado de lado e muitos usuários têm o costume de ignorar ambos, mas, se for realmente
necessário, e quando o usuário de seu sistema necessitar buscar a documentação e ela não
trouxer a realidade de como está seu sistema? Diversos motivos podem trazer essa necessidade
para consultar o manual, como: usuários inexperientes e usuários que pela primeira vez podem
enfrentar dificuldades ao usar a aplicação; algumas ações críticas, como a exclusão de recursos,
podem suscitar dúvidas; Alguns recursos podem não ser explicitamente visíveis nem facilmente
dedutíveis.
Além de implementar a documentação, é necessário fazer com que ela evolua com o
sistema; isso é uma tarefa muitas vezes difícil de se realizar devido à necessidade de priorizar o
sistema e não a documentação do mesmo (SOARES, 2004).
Essa documentação, geralmente, é custosa e dependente de ferramentas como editor
de textos formatados (RTE, Rich Text Editor), como Microsoft Word e LibreOffice Writer,
acompanhadas de ferramentas gráficas, tais como Microsoft Paint e GIMP para realizar recorte
ou destaque em imagens. Isso, em sua grande maioria, torna o desenvolvimento desses manuais
lentos, ruim de evoluir e difícil de manter versões desses arquivos binários (WAITS T.; YANKEL,
2014), pois, se o software sofre alterações no layout, é necessário extrair novas imagens em
todos os pontos que foram modificados.
Para tentar solucionar esses problemas, foi proposto o GuideAutomator, uma ferramenta
que automatiza a extração de imagens em um sistema Web usando comandos informados pelo
15
usuário e utilizando como base o Selenium Web Driver 1 (um framework de automação de
navegadores), tornando mais fácil a evolução e o controle de versão do manual.
Foi desenvolvido um protótipo da ferramenta 2, mas em seus testes pilotos, foram
encontrados problemas com a usabilidade e a manutenção da mesma (OLIVEIRA; SOUZA,
2016). A ferramenta possuía uma linguagem própria para desenvolvimento dos manuais e muitas
vezes seu interpretador não funcionava corretamente devido a um simples espaço a mais antes do
código, entre outras coisas. Os códigos do GuideAutomator 1.0 estavam concentrados em apenas
um arquivo, o que não é favorável para evolução e manutenção da ferramenta. A ferramenta
necessitava de determinado conhecimento técnico para o desenvolvimento de manuais, requisito
este que pode não pertencer ao responsável por criar os manuais.
Para tornar mais atrativo e facilitar o uso da ferramenta para o desenvolvimento de
manuais, foram propostas algumas alterações no GuideAutomator, como re-escrita do código,
alteração da linguagem usada pelo usuário e criação de um mecanismo de auxílio na produção
desses comandos, como uma extensão de navegador 3.
Para avaliar se o GuideAutomator (GA) solucionaria os problemas na elaboração de
documentos, foram elaborados experimentos controlados para avaliar a criação de manuais de
usuários contra a criação desses manuais com método tradicional, e avaliar a evolução destes
documentos com ambos métodos, pois a experimentação é realizada para ajudar-nos a melhor
avaliar, prever, entender, controlar e melhorar o produto e o processo de desenvolvimento de
software (BASILI, 1996).
A partir deste ponto, o trabalho será divido em quatro capítulos, além da introdução. No
segundo capítulo serão apresentados conceitos gerais sobre o GuideAutomator e as tecnologias
que ele utiliza. No terceiro capítulo, será abordada a evolução da ferramenta sobre os pontos
relatados de sua primeira versão. No quarto, será demonstrada a elaboração do experimento
controlado e dos dados obtidos. No quinto e último capítulo será apresentado a conclusão do
trabalho.
1 Selenium automates browsers. - 2 GuideAutomator - 3 Extensão do Guide-Automator -
http://www.seleniumhq.org/https://www.npmjs.com/package/guide-automatorhttps://addons.mozilla.org/pt-BR/firefox/addon/guide-automator/
16
2 Conceitos Gerais
Os geradores de documentação são ferramentas que extraem comentários estruturados
no código-fonte de um programa e geram a documentação do código-fonte, esse documento
está destinado aos programadores. Os geradores de documentação incluem Doxygen e Java-
doc. GuideAutomator também é um gerador automatizado de documentação; No entanto, a
documentação é orientada para usuários finais, e não para os programadores.
Para os geradores de documentação que podem ser usado com foco no usuário final,
temos o Sphinx, desenvolvido em Python, ele utiliza a linguagem de marcação, reStructuredText
(reST), na escrita de sua documentação e com certas marcações, ele extrai códigos em python e
os executa. Para extração de fotos dos sistemas é necessário instalar complementos/extensões
para que o mesmo suporte a funcionalidade de extração de fotos, algo que já é nativo para o
GuideAutomator.
Para este capítulo será apresentado o GuideAutomator em suas primeiras versões seguido
das tecnologias que a ferramenta utiliza na produção de manuais usuários.
2.1 GUIDEAUTOMATOR 1.0 E TECNOLOGIAS USADAS
O GuideAutomator foi desenvolvido por Allan Oliveira em 2016 e essa ferramenta faz
o uso do Markdown 1 e o Selenium WebDriver 2. O GuideAutomator funcionava extraindo
blocos de código de um texto Markdown gerando um manual em
HTML/PDF, fluxo mostrado na Figura 1. Foi desenvolvido utilizando Node.js 3 e o projeto pode
ser obtido do repositório de aplicações do Node.js, o Node Package Manager (NPM). Ele foi
projetado para funcionar em múltiplas plataformas, sendo elas Windows, macOS e Linux. Para
entendermos melhor as tecnologias e a evolução da primeira versão, vamos destrinchar essas
tecnologias.1 Markdown - . Acesso em: 18 de jun. de 2017.2 Selenium - Acesso em: 18 de jun. de 2017.3 Node.js - . Acesso em: 18 de jun. de 2017.
https://daringfireball.net/projects/markdown/http://www.seleniumhq.org/projects/webdriver/http://nodejs.org/
17
Figura 1 – Fluxo do GuideAutomator 1.0 (OLIVEIRA; SOUZA, 2016)
2.1.1 Markdown
Markdown é uma sintaxe de formatação de texto simples criada em 2004 por John
Gruber, originalmente projetada para ser convertida em XHTML ou HTML válido. Ao longo
da última década, muitas extensões foram criadas, possibilitando a conversão de linguagem
de Markdown para muitos outros formatos, como PDF, LaTeX, RTF, entre outros. Com todas
essas possibilidades, sua facilidade de uso tornou o Markdown muito popular na comunidade
de software. Algumas aplicações populares que fazem uso do Markdown são GitHub4 e Stack
Overflow5. Essas aplicações e muitas outras utilizam a sintaxe padrão do Markdown ou uma
extensão personalizada da linguagem de marcação original.
A intenção do Markdown é ser simples, fácil de ler e fácil de escrever. Sua sintaxe é
composta por texto regular com alguns caracteres não alfabéticos, como visto na Figura 2. A4 GitHub Inc. Acesso em: 18 de jun.
de 2017.5 Stack Overflow Inc. Acesso em: 18 de jun. de 2017.
https://help.github.com/articles/about-writing-and-formatting-on-github/http://stackoverflow.com/help/formatting
18
definição de sua sintaxe pode ser obtida no site .
Figura 2 – Exemplo de sintaxe MarkdownComo o Markdown é um texto simples, é possível usar de maneira efetiva um controle de
versão sobre os textos escritos com essa marcação. O mesmo se aplica à facilidade de trabalhos
cooperativos permitindo que uma ou mais pessoas possam trabalhar sobre o mesmo arquivo.
Devido à popularização do Markdown, da facilidade de seu uso quanto a escrita e leitura
e à possibilidade de controle de versão, essa linguagem de marcação foi a escolhida para criação
do GuideAutomator.
2.1.2 Selenium WebDriver
Para que o GuideAutomator possa acessar os sistemas web a fim de extrair a captura de
tela, é necessário que ele funcione de maneira automatizada seguindo uma cadeia de passos. Para
que isso se torne possível, o GuideAutomator incorpora em seu núcleo o Selenium WebDriver,
uma poderosa ferramenta para automação de navegadores. Com ela é possível acessar o navegador
de maneira automatizada e executar ações como se fosse um humano acessando. Ele suporta
diversos navegadores, como Firefox, Chrome, Safari, Opera e Internet Explorer, e diversos
sistemas operacionais, como Windows, macOS e Linux. O Selenium pode ser incorporado em
diversas linguagens de programação, como Java, JavaScript, Objective-C, Perl, PHP, Python e
Ruby.
O Selenium WebDriver é usado principalmente para automatizar o processo de testes
funcionais (HOLMES A.; KELLOGG, 2006). O teste funcional é o processo de verificar se o
comportamento de uma aplicação de software está em conformidade com a sua especificação,
https://daringfireball.net/projects/markdown/syntaxhttps://daringfireball.net/projects/markdown/syntax
19
do ponto de vista do usuário final, executando casos de teste derivados de sua especificação
(MYERS G. J.; SANDLER, 2011). O GuideAutomator usa Selenium WebDriver para uma
finalidade diferente; ao invés de comparar a saída do aplicativo com uma saída esperada, ele
captura a saída para que ela possa ser exibida no manual do usuário.
O Selenium WebDriver possui uma vasta lista de comandos para manipulação de navega-
dores, tais como recuperar páginas web, localizar elementos nas páginas, preencher formulários
e tirar capturas de tela. O GuideAutomator utiliza essas funções e mais algumas outras.
Para utilizar o Selenium é necessário que o usuário possua um WebDriver instalado na
máquina nas variáveis de ambiente. O GuideAutomator em específico, utiliza o ChromeDriver6.
O GuideAutomator em sua primeira versão só suportava a versão 2.21 do ChromeDriver. Em
suas versões mais recentes a versão é indiferente desde que o ChromeDriver seja compatível
com a versão do Google Chrome7
2.1.3 Unique CSS Selector
Para o GuideAutomator executar os comandos que ela disponibiliza para o desenvolvedor,
o desenvolvedor necessita entender o que é e como extrair o Unique CSS Selector dos elementos.
O Unique CSS Selector é uma maneira de identificar um elemento na estrutura HTML de
maneira única; isso se torna muito útil quando é necessário trabalhar unicamente com aquele
elemento, isolando-o dos demais elementos existentes do HTML.
Sua estrutura pode ser identificada por #id quando o elemento possui um identificador
único em sua estrutura ou por cadeia de .class quando o elemento não possui um identificador
único.
A extração do Unique CSS Selector se torna prática através do uso dos navegadores e de
ferramenta de desenvolvedor desses navegadores que já fornecem formas de extrair esses seletores
de uma página da web, como podemos visualizar o uso dessa ferramenta de desenvolvedor do
navegador nas Figuras 3 e 4.6 Google Inc. ChromeDriver - WebDriver para Chrome
Acesso em: 18 de jun. de 2017.7 Google Inc. Google Chrome Acesso em: 18 de jun. de 2017.
https://sites. google.com/a/chromium.org/chromedriver/https://www.google.com/chrome/index.html
20
Figura 3 – Inspecionar elemento no Google Chrome
Figura 4 – Copiar Css Selector no Google Chrome
2.1.4 Funcionamento do GuideAutomator 1.0
Após o entendimento das tecnologias, é necessário entender como o GuideAutomator
funcionava na última versão liberada pelo seu desenvolvedor inicial, a versão 1.0.14.
O GuideAutomator é uma aplicação Command-Line Interface (CLI); a execução de
aplicações CLI é realizada pelo terminal de comando do sistema operacional. Sua execução era
feita através da chamada da aplicação guide-automator, seguida, obrigatoriamente, pelo caminho
do arquivo Markdown a ser lido e pasta em que será gerado o manual em PDF e HTML. Um
exemplo de chamada pode ser vista na Figura 5.
21
Figura 5 – Exemplo de chamada pelo terminal (OLIVEIRA; SOUZA, 2016)
O GuideAutomator fornece alguns comandos que encapsulam chamadas do Selenium
WebDriver com objetivo de torná-las mais simples ao desenvolvedor. Comandos como clicar
em elementos, preencher campos de formulários, capturar imagem da tela, entre outros podem
ser vistos na Tabela 1. O desenvolvedor do manual deve incluir blocos do GuideAutomator
no arquivo Markdown delimitados por e, após a execução desse
arquivo, é gerado o manual em PDF e HTML, como exemplo na Figura 6 e 7. Seus blocos de
códigos não permitiam indentações ou qualquer outro comando além dos citados na Tabela 1.
Figura 6 – Exemplo de código do GuideAutomator 1.0
22
Figura 7 – Exemplo de saída do GuideAutomator 1.0
2.1.5 Análise experimental do GuideAutomator 1.0
Foi realizado experimento piloto com duas pessoas; nesse experimento o participante
deveria escrever e extrair as imagens para o manual de usuário utilizando o GuideAutomator
e utilizando método tradicional de uma versão de um sistema de seleção de pós-graduação da
Universidade Federal da Bahia, SIPÓS. Logo após os participantes deveriam informar o tempo
gasto, a facilidade de uso de uma escala de 1 a 5, a curva de aprendizado de uma escala de 1 a 5,
vantagens e desvantagens de cada processo, GuideAutomator e método tradicional.
Foi observado no experimento um grande tempo gasto utilizando o GuideAutomator e
a necessidade de os desenvolvedores dos manuais possuírem conhecimentos técnicos sobre o
desenvolvimento Web (SOUZA; OLIVEIRA, 2017). Não foram realizados experimentos para
uma evolução desse sistema e assim validar se a ferramenta atende o propósito de facilitar a
evolução de um manual quando o sistema evoluir.
23
Tabela 1 – Lista de comandos do GuideAutomator 1.0.14
Comando Descrição
get(url)Navega para a página com a URLespecificada.
takeScreenshot([imageWidth])
Obtém uma captura de tela da viewportdo navegador. Pode levar um,parâmetroopcional: largura da imagem, para definira largura da imagem,da tela com valores css.
takeScreenshotOf(selector[,crop,outline,imageWidth])
Obtém uma captura de tela da viewportdo navegador depois que o elementoidentificado pelo seletor css foi deslocadopara exibição. Pode levar até três parâmetrosopcionais: crop, para cortar o elemento dacaptura detela e substituir a imagem dacaptura de tela; outline, para adicionar umcontorno vermelho em css ao elemento;Largura de imagem, para definir a largurada imagem da tela com valores css.
fillIn(selector,content)Preenche o conteúdo no elementoidentificado pelo seletor css.
submit(selector)Envia o formulário contendo o elementoidentificado pelo seletor css, se houver um.
click(selector)Executa um clique sobre o elementoidentificado pelo seletor css
clickByLinkText(text)Executa um clique no elemento âncoraque contém o texto especificado.
wait(selector)Faz com que a execução do driver daWeb aguarde até que o elementoidentificado pelo seletor css apareça na página.
sleep(milliseconds)Faz com que a execução da webdriverseja suspensa pelo número especificadode milissegundos.
24
3 Evolução do GuideAutomator
Com o objetivo de melhorar o GuideAutomator para seus usuários, foram realizadas
evoluções sobre a ferramenta com intuito de tornar sua usabilidade mais simples e dar mais
capacidade de uso para a ferramenta. A forma de extração de código do Markdown foi substituída,
o interpretador interno que executa as instruções GuideAutomator foi alterado, foi dada uma
maior capacidade na execução por linha de comando e foi desenvolvido uma extensão de
navegador para auxiliar o desenvolvimento dos códigos GuideAutomator.
3.1 EXTRAÇÃO DE BLOCO
Em suas primeiras versões o GuideAutomator lia o arquivo Markdown em busca de
blocos delimitados por ; esses códigos possuíam uma linguagem
própria definida na documentação do GuideAutomator; esses códigos após serem extraídos
e interpretados, eram executados pelo Selenium WebDriver e o mesmo fazia o processo de
automação seguindo as cadeias de passos pedidos.
O problema de se definir uma linguagem própria é que o usuário está dependente do
criador dessa linguagem para conseguir mais suporte e flexibilidade quanto ao desenvolvimento
de uma documentação utilizando o GuideAutomator e também há uma necessidade de aprender
uma nova linguagem. Para tentar simplificar e minimizar o impacto do uso do responsável por
escrever a documentação ao usar a ferramenta, foi utilizado o recurso disponível do Markdown
para delimitar blocos de códigos; sua sintaxe é bastante simples, ```(linguagem) códigos ```.
Como o GuideAutomator foi construído com o Node.js, e o mesmo utiliza JavaScript1, o
GuideAutomator passou a extrair códigos JavaScript delimitados por ```javascript códigos ```,
mostrado na Figura 8. Com essa mudança, é necessário adaptar os códigos produzidos para o
GuideAutomator 1.0 para a versão 2.0.
Figura 8 – Exemplo de trecho GuideAutomator
1 JavaScript - Acesso em: 18 de jun. de 2017.
https://www.javascript.com/
25
Além da extração do código, foi utilizada uma dependência externa do repositório NPM,
Vm2 2. O objetivo dessa dependência é isolar a execução dos códigos extraídos do Markdown da
execução do GuideAutomator e, assim, fornecer uma camada externa para execução e proteger a
aplicação de uma possível vulnerabilidade de injeção de código3 externo ao da aplicação.
3.2 LINHA DE COMANDO
Uma das características do GuideAutomator é a de ser uma aplicação Command-Line
Interface (CLI), ou seja, sua execução é realizada através de um terminal. Para execução do
GuideAutomator era necessário que no terminal o primeiro argumento fosse o próprio nome do
programa, seguido pelo arquivo lido e logo após, a pasta onde seria armazenado o manual. Em
sua nova versão, 2.4, o GuideAutomator foi alterado para permitir mais parâmetros e uma maior
flexibilidade na execução da aplicação pelo terminal. Sua chamada é feita através do nome da
aplicação seguida por parâmetros disponíveis na Tabela 2. É possível verificar um exemplo de
chamada da aplicação na Figura 9.
Figura 9 – Exemplo de chamada pelo terminal
Algumas dessas opções trazem diversas possibilidades de usos da ferramenta. Como
exemplo, o –headless permite a automação do navegador pelo Selenium WebDriver sem a
necessidade do uso da interface gráfica do Google Chrome, permitindo o uso do GuideAutomator
em servidores sem interface gráfica. Outro comando bastante útil é o –style, que permite uma
maior customização dos arquivos gerados e assim, os documentadores podem confeccionar
documentações com um visual voltado ao sistema documentado.
3.3 EXTENSÃO DE NAVEGADOR DO GUIDEAUTOMATOR
Antes de explicar a extensão de navegador do GuideAutomator, devemos entender o que
são e para que servem essas extensões. As Extensões de navegadores são usadas para estender as
funcionalidades ou dados disponíveis de um navegador, permitindo que ele realize operações
que não são nativas do navegador.
Extensões são criadas, muitas vezes, para tornar uma ação mais prática ou para contornar
algo que o navegador não dá suporte. Em média, entre 100.000.000 e 150.000.000 são usadas2 Vm2 - 3 Prática maliciosa com objetivo de alterar ou executar códigos externos no software utilizado
https://www.npmjs.com/package/vm2
26
Tabela 2 – Exemplos de parâmetros CLI do GuideAutomator 2.4.0
Comando Descrição-h, –help Fornece informações de usos da aplicação e seus comandos-V, –version Exibe a versão do GuideAutomator instalada.
-i, –input [file.md]Caminho do arquivo Markdown a ser interpretado peloGuideAutomator
-o, –output [folder]Caminho da saída dos arquivos gerado pelo GuideAutomator.O valor padrão é gerar na pasta onde o terminal está sendoexecutado.
-P, –pdf
No término da execução do GuideAutomator, será geradoarquivo PDF, exceto que seja solicitado outros formatos.Se nenhum formato for solicitado, será gerado em todos osformatos possíveis. Imagens sempre são geradas.
-H, –html
No término da execução do GuideAutomator, será geradosomente arquivo PDF, exceto que seja solicitado outrosformatos. Se nenhum formato for solicitado, será gerado emtodos os formatos possíveis. Imagens sempre são geradas.
-I, –image
No término da execução do GuideAutomator, será geradosomente as imagens extraídas e todos os outros tipos geradosserão ignorados. Se não for informado, será gerado todos osformatos possíveis por padrão.
-s, –style [style.css]
Esse comando permite uma maior customização do PDF eHTML gerado pela ferramenta. É possível utilizar algunstemas prontos como lightBluee lightOrange, ou o usuáriopode especificar o caminho do css para ser utilizado nacustomização.
-t, –autosleep [Millisecond]
Comando utilizado para executar um sleep automáticoantes de cada captura de tela, comando foi criado comintuito de forçar o sleep para usuários que não verificama necessidade do sleep ou caso realmente seja necessárioaguarda para cada captura. O valor padrão é de 200ms
-d, –debug
Caso o comando esteja ativo, traz informações durante aexecução do GuideAutomator, como, quantos blocos foraminterpretados, quantas linhas, tempo utilizado para capturade tela de cada takeScreenshot e o tempo gasto na execuçãodo GuideAutomator.
-b, –browser [path]Permite informar o caminho do executável do Google Chromecaso esse executável não esteja no caminho padrão.
-l, –headlessPermite que o GuideAutomator execute a automação nonavegador com o navegador em segundo plano, sem anecessidade da interface gráfica do navegador.
-w, –window [dimensions]Permite a execução da automação em navegadores na dimensãoespecificada, permitindo assim a extração de capturas de telasindependente da dimensão do monitor.
27
por dia e cerca de 1.100.000 são baixadas por dia, segundo o site do Firefox4 (dados obtidos
no mês de julho de 2017). Foi observando o uso e a prática dessas extensões que foi pensado o
desenvolvimento de uma extensão para o auxílio do GuideAutomator.
A extensão foi desenvolvida para o Mozilla Firefox 5 e está disponível em seu repositório
de extensões 6. Mesmo que o GuideAutomator tenha sido desenvolvido utilizando o ChromeDri-
ver, que faz uso do navegador Google Chrome, foi escolhido desenvolver uma extensão para o
Mozilla Firefox devido ao suporte da comunidade que pode ser obtido na criação de extensões
para esse navegador e que não era facilmente obtido na criação de extensões para o Google
Chrome no momento de seu desenvolvimento, mas futuramente ela pode ser implementada para
outros navegadores. A extensão, como pode ser vista na Figura 10, possui a lista de comandos
existente na ferramenta, juntamente com a descrição, parâmetros e exemplos do uso dos coman-
dos ao passar o mouse sobre esses comandos, sendo possível clicar e preencher os parâmetros no
campo de texto ao lado dos comandos.
Figura 10 – Demonstração da extensão do GuideAutomator
Outra funcionalidade da extensão e, provavelmente, a mais útil, é a seleção de contexto
(menu que aparece ao clicar com botão direito na interface), visto na Figura 11. Com as opções
disponíveis, é possível obter o Unique CSS selector dos elementos, que são usados nos comandos
do GuideAutomator, ou executar os comandos do GuideAutomator pelo menu, preenchendo4 Estatística sobre extensões do Firefox - 5 Mozilla Firefox - 6 GuideAutomator Extension -
https://addons.mozilla.org/pt-BR/statistics/https://www.mozilla.org/en-US/firefox/https://addons.mozilla.org/pt-BR/firefox/addon/guide-automator/
28
seus parâmetros; as opções escolhidas são armazenados na sua área de transferência e também
são copiados para o campo de texto da Figura 10.
Figura 11 – Demonstração da extensão do GuideAutomator
3.4 RE-ESCRITA DO CÓDIGO FONTE
O GuideAutomator é um projeto open source, ou seja, seu código fonte está disponível
para todos que desejarem olhar e até mesmo contribuírem com correções ou melhorias. O reposi-
tório utilizado é o GitHub e está acessível em .
Contudo, seu código fonte não era amigável, toda a lógica estava concentrada em apenas
um arquivo, com isso o projeto possuía baixa manutenibilidade e isso dificultava a evolução e
correções da ferramenta por pessoas novas no projeto. Devido a essas dificuldades, o código
fonte do GuideAutomator foi re-escrito.
O código foi modularizado com o intuito de tornar a manutenção mais eficiente; o
GuideAutomator apresenta funções como interpretar entrada do terminal, processar o arquivo
Markdown, automatizar passos informados pelo usuário no navegador e exportar o manual
produzido, em função disso, ele foi separado em quatro arquivos principais com funções distintas:
• guide-automator.js: Arquivo responsável por interpretar a entrada passada pelo terminal
e se comunicar com os outros arquivos.
https://github.com/aside-ufba/guide-automator
29
• guide-automator-parser.js: Arquivo responsável por interpretar o Markdown lido, ex-
traindo os blocos JavaScript e chamar as funções de guide-automator-function.
• guide-automator-function.js: Responsável pela lógica dos comandos GuideAutomator;
a chamada desse arquivo é feita quando o guide-automator-parser identifica nos blocos
JavaScript comandos GuideAutomator.
• guide-automator-parser.js: Responsável por gerar a saída do GuideAutomator após a
execução dela; esse arquivo produz os arquivos PDF e HTML.
Após essas mudanças, o fluxo do GuideAutomator foi alterado da Figura 1 para a Figura
12.
Figura 12 – Fluxo do GuideAutomator 2.4
30
3.5 COMANDOS GUIDEAUTOMATOR 2.4
Na produção de manuais é necessário às vezes destacar mais de um elemento, ou na
execução do GuideAutomator foi solicitado que o aguardasse por elemento, mas esse elemento
nunca existiu na interface. Avaliando essas necessidades, foram criados alguns novos comandos
e alterações em comandos já existentes. Esses comandos foram destacados em negrito e podem
ser vistos na Tabela 3.
3.6 CORREÇÕES E MELHORIAS MENORES
Além das evoluções e correções que foram apontadas ao longo do Capítulo 3, houve
diversas correções e melhorias menores que impactavam o uso da ferramenta desde da primeira
versão, tais como:
• Em sua primeira versão, não era permitido ter dois comandos takeScreenshot em um
mesmo bloco de código no Markdown; esse problema foi corrigido com a re-escrita do
código fonte.
• Algumas vezes, no manual gerado, uma mesma imagem se repetia duas ou mais vezes ao
longo do manual.
• Foi adicionado um sumário no conteúdo HTML gerado.
• Melhoria da documentação do GuideAutomator, explicando como instalar a ferramenta e
seus dependentes binários, breve descrição de seu uso seguido de exemplos, como é feita
a execução pelo terminal, como extrair CSS selector, mais detalhamento nos comandos
existentes.
• O encerramento do navegador em caso de erro no GuideAutomator; anteriormente, ao
dar alguma exceção não tratada e re-executar o código, era aberta uma nova instância do
navegador e a anterior continuava aberta.
• Corrigido o limite da margem superior do PDF e atribuídas informações no rodapé.
31
Tabela 3 – Lista de comandos do GuideAutomator 2.4.0
Comando Descrição
get(url)Navega para a página com a URLespecificada.
takeScreenshot([imageWidth])
Obtém uma captura de tela da viewportdo navegador. Pode levar um, parâmetroopcional: largura da imagem, para definira largura da imagem,da tela com valores css.
takeScreenshotOf(selector|array(selector)[,crop,outline,imageWidth])
Obtém uma captura de tela da viewportdo navegador depois que o(s) elemento(s)identificado(s) pelo(s) seletor(es) css foi deslocadopara exibição. Pode levar até três parâmetrosopcionais: crop, para cortar o elemento dacaptura detela e substituir a imagem dacaptura de tela; outline, para adicionar umcontorno vermelho em css ao elemento;Largura de imagem, para definir a largurada imagem da tela com valores css.
fillIn(selector,content)Preenche o conteúdo no elementoidentificado pelo seletor css.
submit(selector)Envia o formulário contendo o elementoidentificado pelo seletor css, se houver um.
click(selector)Executa um clique sobre o elementoidentificado pelo seletor css.
clickByLinkText(text)Executa um clique no elemento âncoraque contém o texto especificado.
wait(selector[,timeout])
Faz com que a execução do driver daWeb aguarde até que o elementoidentificado pelo seletor css apareça na páginaou até um determinado tempo limite.
sleep(milliseconds)Faz com que a execução da webdriverseja suspensa pelo número especificadode milissegundos.
highlight(selector) Adiciona um contorno vermelho emcss ao elemento
console.print(text) Permite a inserção de textos dinamicamente nomanual gerado pelo GuideAutomator
pageContext(seletor) Faz a troca de contexto para um Iframeexistente em uma página web.
GDGLOBAL[’Var’]Permite o uso de váriaveis globais pelos blocosGuideAutomator, permitindo uma comunicaçãoentre os blocos
GD.driver
Disponibilizado o driver do selenium para permite aexecução de comandos não disponibilizados peloGuideAutomator, seu uso só deve ser feito porusuários avançados.
32
4 Experimento Controlado
Para este capítulo, serão abordados conceitos gerais e objetivos do experimento contro-
lado, a execução do experimento piloto para validar o planejamento do experimento principal e
análise do experimento principal.
4.1 CONCEITO E OBJETIVO
A experimentação é utilizada para compreender os problemas, criar teorias, desenvolver
soluções, formular e testar hipóteses, comparar sistematicamente as soluções propostas em
relação às soluções existentes, etc (BASILI, 1996).
O objetivo do experimento, além dos citados acima, é mostrar que um particular método
ou ferramenta é superior, de alguma maneira, a outro, sendo a ferramenta em questão, o Gui-
deAutomator, comparado à forma tradicional de se desenvolver manuais de usuário, ou seja,
utilizando editores de textos formatos e editores de imagens.
O processo de realização de um experimento controlado é tipicamente composto das
seguintes fases: definição, planejamento, execução, análise e empacotamento (WOHLIN, 2012),
conforme ilustra a Figura 13:
1. Definição: Nessa fase o estudo deve ser caracterizado em termos de problema, objetivos e
metas. Ela determina a base para o experimento.
2. Planejamento: É uma preparação de como o experimento deve ser conduzido. Compreende
a definição da hipótese, seleção de variáveis (dependentes e independentes), seleção dos
participantes e determinação do design estatístico do experimento.
3. Operação (execução): Essa fase segue a determinação do design. É composta de:
a) Configuração do estudo (preparação), onde os participantes são escolhidos e os
materiais necessários são preparados.
b) Execução, que coleta os dados que devem ser analisados.
4. Análise e Interpretação: Responsável pela compilação dos dados coletados no estudo.
Compreende estatística descritiva, redução do conjunto de dados e teste de hipótese.
5. Apresentação e Empacotamento: Nesta fase a informação sobre o estudo é apresentada e o
pacote, montado ao longo de todo o processo, é gerado. É uma fase essencial para permitir
a replicação do estudo.
33
Figura 13 – Processo Experimental (WOHLIN, 2012)
4.1.1 Definição
Para esta fase, foi identificada a necessidade de avaliar se a ferramenta atende o propósito
para que ela foi feita, facilitar o desenvolvimento e evolução de manuais. Para verificar essa
necessidade de avaliação, foi proposta a elaboração de um experimento que avaliasse a eficiência
e eficácia na produção de manuais com o uso do GuideAutomator contra o uso de método
tradicional.
4.1.2 Planejamento
Nossa hipótese é de que:
1. O GuideAutomator desenvolva com maior eficiência sobre o método tradicional na evolu-
ção de manuais. Como variáveis dependentes temos a produtividade, que é a capacidade do
usuário desenvolver em menos tempo, e como variáveis independentes temos, experiência
pessoal e o método de produção de manuais, que pode ser utilizando o GuideAutomator
ou método tradicional.
2. O GuideAutomator desenvolva com maior eficácia sobre os método tradicional na evolu-
ção de manuais. Como variáveis dependentes temos a taxa de acerto, que é a capacidade
do usuário fazer capturas de telas próximos às imagens modelos, e como variáveis inde-
pendentes temos experiência pessoal e o método de produção de manuais, que pode ser
utilizando o GuideAutomator ou método tradicional.
Para aplicação do experimento, foi construída uma máquina virtual, utilizando o Oracle
VM VirtualBox1.1 Oracle Virtual Box. -
https://www.virtualbox.org
34
Essa máquina virtual possui as seguintes especificações:
• 1 Processador
• 1524 MB de RAM
• 128 MB de Memória de Vídeo
• 2,5 GB de Armazenamento
• Sistema Operacional: Lubuntu 14.04
Foi escolhido o Lubuntu como sistema operacional para que este não impacte no consumo
de memória e apresente um melhor desempenho no desenvolvimento do experimento pelos
participantes.
Foram instaladas as seguintes aplicações:
• Mozilla Firefox 52.0.2 2 com a extensão do Guide-Automator 0.1.1 3
• Shutter 0.90.1 4
• Atom 1.13.1 5
• WPS Office 10.1.0 6
• Chromium 53.0 7
• Guide-Automator 2.4.0 8
O objetivo da máquina virtual era fazer com que os participantes não possuam vantagens
sobre outro participante por usar uma ferramenta diferente. Antes de iniciar o experimento, foi
realizado um treinamento para o GuideAutomator e para a forma tradicional de se fazer manuais.
Antes da participação do experimento, o participante deveria preencher o formulário de
caracterização de perfil, visto no Apêndice B, a fim de obter conhecimento sobre o participante,
como conhecimento em desenvolvimento web, programação, entre outros, e utilizando esses
dados para verificar se os conhecimentos do participante influenciaram no desenvolvimento do2 Mozilla Firefox - 3 Extensão do Guide-Automator4 Shutter Screenshot Tool - 5 Atom, hackable text editor - 6 WPS Office - 7 The Chromium Projects - 8 Guide Automator -
https://www.mozilla.org/pt-BR/firefox/https://addons.mozilla.org/pt-BR/firefox/addon/guide-automator/http://shutter-project.org/https://atom.io/https://www.wps.com/https://www.chromium.org/https://www.npmjs.com/package/guide-automator
35
experimento. O participante também deveria preencher o termo de consentimento autorizando
o uso desses dados para análise, visto no Apêndice A. O perfil dos participantes pode ser
visualizado no Apêndice D.
Os participantes deveriam elaborar capturas de tela para quatro manuais de uma página
de administração de um fórum, o MyBB9. O sistema foi escolhido devido à grande difusão que
fóruns possuíam e que alguns ainda possuem nos dias de hoje; foram instaladas duas versões
do fórum, uma do ano 2015 e outra do ano 2017, e assim, cada participante deveria produzir
dois manuais para a versão do MyBB 2015, um usando a ferramenta e outro utilizando método
tradicional, e dois manuais para a versão do MyBB 2017, seguindo os mesmos princípios da
versão de 2015. Seriam disponibilizadas imagens modelo a serem exibidas em cada trecho
do documento, essas imagens possuiriam marca d’água para impossibilitar o participante de
reutilizar essas imagens modelo nos experimentos, como visto na Figura 14.
Para o experimento, os participantes deveriam atualizar um total de 15 imagens da
documentação. Foram criados previamente para o participante uma pasta que continha os arquivos
RTE e Markdown, necessários para a atualização de imagens, e os participantes deveriam replicar
esta pasta para a execução da segunda versão do fórum MyBB.
Figura 14 – Exemplo de imagem modelo para o experimento
Após o término do experimento, os participantes enviaram o produto de seu experimento,
tais como código, imagens e manuais, para um serviço de armazenamento em nuvens com o9 MyBB Fórum Software -
https://github.com/mybb/mybb
36
nome do participante e o tempo de início e fim de cada manual produzido. Os participantes
também deveriam responder um questionário para obter algumas informações do experimento,
como críticas e sugestões, visto no Apêndice C.
Para validar o planejamento, foram elaborados dois experimentos pilotos seguindo o
planejamento com intuito de verificar falhas na estrutura elaborada para o experimento.
4.1.3 Operação
Para a realização desse experimento foram escolhidos 18 alunos de graduação e pós-
graduação da área de computação da Universidade Federal da Bahia. Foi reservado um laboratório
para instalação das máquinas virtuais.
A execução dos experimentos seguiu o seguinte roteiro:
1. Os participantes foram instruídos e capacitados na ferramenta GuideAutomator e método
tradicional de extração de imagens para elaboração dos manuais; foi estimado um tempo
de 40 minutos.
2. Após a fase de capacitação, foi explicado o experimento, registro do tempo, imagem
modelo e repostas para possíveis dúvidas, estimando algo próximo dos 10 minutos.
3. Nessa fase, foi realizado o experimento, 2 horas.
4. Foi solicitado aos participantes que preenchessem o questionário pós-experimento e
enviassem o material produzido, 10 minutos.
4.1.4 Análise e Interpretação
Para esta etapa, foram considerados algumas análises:
1. Tempo total usado com a ferramenta e com o método tradicional.
2. A taxa de acerto entre as imagens do participante e as imagens modelos.
3. O impacto do nível de conhecimento web no tempo e no acerto ao utilizar o GuideAuto-
mator.
4. Análise dos prós e contra da ferramenta reportados no questionário pelo participante.
Para os itens 1 e 2, foram aplicados o teste de Shapiro-Wilk para testar a normalidade
dos dados e de acordo com o seu resultado, foi aplicado o teste t de Student pareado se os dados
37
são provenientes de uma população com distribuição normal ou aplicamos o teste de Wilcoxon
pareado se os dados não são provenientes de uma população com distribuição normal. Esses dois
testes têm como objetivo comparar as médias ou medianas de duas amostras. Para estes testes foi
utilizado um nível de significância de 5%.
Para o item 3, foi aplicado o teste de Kruskal-Wallis para analisar a distribuição dos
grupos das amostras; esse teste teve como objetivo comparar as medianas em um conjunto de
mais de duas amostras. Para estes testes foi utilizado um nível de significância de 5%.
Para o item 4, foi realizada uma análise qualitativa informal dos dados informados pelos
participantes.
Os testes foram executados no R10, uma linguagem e também um ambiente de desenvol-
vimento integrado para cálculos estatísticos e gráficos.
O objetivo dessas análises era de provar que o uso da ferramenta é superior em seu tempo
de produção e no custo de evolução do manual em relação ao método tradicional.
4.1.5 Apresentação e Empacotamento
Para esta fase foram elaborados gráficos, mostrando o comparativo da ferramenta com o
método tradicional, baseado em tempo e taxa de acerto. Foram elaboradas análises descritivas
sobre o tempo e taxa de acerto considerando os prós/contra da ferramenta e caracterização do
participante. Os produtos gerados no experimento pelos participantes foram armazenados na
nuvem para eventuais necessidades. Os dados do experimento e a máquina virtual utilizada
podem ser visualizadas através da url .
4.2 EXPERIMENTO PILOTO
Para este primeiro momento, foram elaborados experimentos pilotos com duas pessoas
da área de computação a fim de validar o processo do experimento controlado e ajustar os pontos
não observados ou planejados, como citado na Secção 4.1.2.
Foi observado na Figura 15 que o GuideAutomator teve uma desvantagem de aproximados
12 minutos, mas com a evolução do sistema, o método tradicional se manteve quase constante
em seu tempo, enquanto o GuideAutomator possuiu grandes ganhos em seu tempo.10 R-Project -
http://bit.ly/EXP_GAhttps://www.r-project.org/
38
Figura 15 – Gráfico Tempo (minutos) X Versão MyBB
Contudo, na Figura 16, o número de acertos das imagens modelos do GuideAutomator
não se mostrou superior ao modo tradicional, foi observado em anotações que os participantes
não verificavam todas as imagens geradas pela ferramenta, isso impactou na taxa de acerto.
Figura 16 – Gráfico Acertos X Versão MyBB
39
Os dois participantes possuíam conhecimento na linguagem JavaScript, facilitando o
entendimento do uso da ferramenta, tais como chamada de função, passagem de parâmetros,
vetores para destaque de múltiplos elementos. Ambos concordaram totalmente que a extensão
foi bastante útil no desenvolvimento do experimento; foi observado que para apenas um deles, a
ferramenta de desenvolvedor do navegador foi de grande auxílio.
Um dos participantes relatou que necessitou consultar a documentação do GuideAutoma-
tor muitas vezes para verificar o funcionamento de alguns comandos.
Em relação ao planejamento do experimento, a troca de uma versão da documentação do
MyBB de um experimento para outro confundiu ambos participantes, sendo necessário verificar
uma forma de melhorar essa troca de experimento para o próximo experimento controlado. Foi
percebido, também, que a marca d’água aplicada nas imagens modelos deveria ficar um pouco
mais transparente, pois dificultou a visão de alguns elementos para um dos participantes.
4.3 EXPERIMENTO NA TURMA
Houveram algumas alterações no que foi descrito no planejamento do experimento. Foi
observado na aplicação do experimento piloto que este se tornou extenso e, devido a isso, para o
experimento final, essa quantidade de imagem foi reduzida para 9 imagens. O PDF produzido
por um dos participantes pode ser visualizado no Apêndice E. Além disso, os participantes
tiveram problemas no experimento piloto, algumas vezes se confundiam ao replicar a pasta e,
por causa disso, já foram criadas as pastas das duas versões do MyBB que possuíam os arquivos
necessários para os participantes do experimento final na máquina virtual.
Para o experimento, os participantes foram divididos em dois grupos de maneira aleatória.
O primeiro grupo iniciou o experimento utilizando o método tradicional e, em seguida, o
GuideAutomator enquanto que o segundo grupo realizou o processo inverso, começando pelo
GuideAutomator . O intuito dessa divisão foi que o conhecimento adquirido na elaboração do
primeiro manual diminuísse o risco da influência na produção da segunda versão do manual.
Com a aplicação desse experimento, houveram um total de 18 participantes, onde foram obtidos
dados de 14 pessoas e 4 pessoas não tiveram seus dados analisados para o experimento, ou
por não terem concluído todo o experimento ou por não ter enviado corretamente o material
produzido.
40
4.3.1 Análise de eficiência
Antes de realizar a análise dos dados usados na Figura 17, foram feitos os testes para
validar se os dados obtidos podem ser usados para deduzir algo sobre essa análise, como dito
na Seção 4.1.4. Aplicamos o teste de Shapiro-Wilk para testar a normalidade dos dados e para
este teste foi observado que o p-valor para o método tradicional na versão MyBB 2015 é de
0.004052, que por sua vez é menor que 0.05, valor definido como significância. Em função
desse resultado, rejeitamos a hipótese de que os dados são provenientes de uma população com
distribuição normal. Para os dados da versão MyBB 2017, os dados possuem uma distribuição
normal, pois o p-valor retornados para o método tradicional e GuideAutomator foram 0.2511 e
0.2365, respectivamente, sendo estes valores maiores que 0.05.
Devido ao resultado do teste de Shapiro-Wilk, observamos que os dados não possuem
uma distribuição normal para versão MyBB 2015, aplicando o teste de Wilcoxon pareado e o
valor de p-valor é de 0.0002441. A diferença de tempo é estatisticamente significativa, pois o
p-valor é menor que 0.05, valor definido como significância; em função desse resultado, podemos
analisar e deduzir hipóteses sobre os dados que serão mostrados nessa seção. Para versão MyBB
2017, o teste de Shapiro-Wilk mostrou que a população possui uma distribuição normal e, em
função disso, aplicamos o teste t de Student pareado; o teste teve como resultado para p-valor de
0.0223; como este valor é menor que 0.05, a diferença observada é estatisticamente significativa.
Devidos a esses resultados, fizemos uma análise sobre os dados dos tempos utilizados pelos
participantes na execução do experimento.
Observando dados da Figura 17 e a distribuição de dados nas Figuras 18 e 19, notamos um
grande tempo gasto no desenvolvimento do primeiro experimento utilizando o GuideAutomator,
alguns participantes tiveram dificuldades em seu primeiro contato, mas teve seu tempo reduzido
drasticamente na utilização na segunda versão do MyBB 2017; contudo, o método tradicional
obteve vantagem e foi desenvolvido em menos tempo em ambas versões do experimento. Uma
das explicações possíveis para esse resultado contra-intuitivo é que alguns participantes não
entenderam a essência do GuideAutomator, que é poder reaproveitar o código para elaborar uma
nova versão da documentação e assim esses participantes reescreveram todo o código que faz a
geração da documentação. Essa ideia talvez não tenha ficado clara para o participante devido à
forma como foram planejadas as pastas do experimento, ou seja, já haviam sido criadas as pastas
e arquivos para as duas versões do sistema documentados previamente.
41
Figura 17 – Gráfico Tempo X Versão MyBB
Figura 18 – Gráfico Boxplot para o tempo utilizado na versão MyBB 2015
42
Figura 19 – Gráfico Boxplot para o tempo utilizado na versão MyBB 2017
4.3.2 Análise de eficácia
Aplicamos novamente o teste de Shapiro-Wilk, como feito na seção anterior, para testar a
normalidade das amostras usadas na Figura 20. Para o teste nos dados de número de acertos para
a versão MyBB 2015, foi retornado para o método tradicional e GuideAutomator os valores de
p-valor 8.168e-06 e 0.0004236, respectivamente, valores estes, menores que 0.05 e assim, não
considerados como uma distribuição normal. Para versão MyBB 2017, o p-valor para o método
tradicional foi de 0.0001092 e para o GuideAutomator foi de 0.0005363, descartando a hipótese
de que os dados são provenientes de uma população com distribuição normal.
Em função dos resultados do teste de Shapiro-Wilk, observamos que ambas versões do
MyBB a distribuição não é normal e em razão disso, aplicamos o teste de Wilcoxon pareado. O
p-valor retornado desse teste para a versão MyBB 2015 foi de 0.4717 e para a versão MyBB
2017 foi de 1, ambos valores são maiores que 0.05; logo, a diferença de tempo entre o método
tradicional e o GuideAutomator não é estatisticamente significativa.
Em virtude dos resultados apresentados, não podemos levantar hipóteses de comparações
sobre eficácia entre os dois métodos em relação aos dados apresentados nas Figura 20,21 e 22,
pois eles não são estatisticamente significativos, apresentando resultados próximos.
43
Figura 20 – Gráfico Acertos X Versão MyBB
Figura 21 – Gráfico Boxplot para acerto utilizado na versão MyBB 2015
44
Figura 22 – Gráfico Boxplot para acerto utilizado na versão MyBB 2017
4.3.3 Análise de perfil e feedback
No questionário de caracterização de perfil foram questionadas algumas coisas, entre elas,
o conhecimento em Desenvolvimento Web para o lado do cliente. Para validar se as diferenças
observadas nas Figuras 23 e 26 são estatisticamente significativas, foi aplicado o teste de Kruskal-
Wallis. O teste apresentou valores de p-valor 0.3199 e 0.09388 para as amostras de tempo e
acerto sobre conhecimento web, respectivamente, e devido a esses valores serem maiores que
0.05, as diferenças entre as amostras não são estatisticamente significativas. Esse resultado
pode ter ocorrido devido à pequena quantidade de elementos na nossa amostra, como podemos
visualizar no gráfico de dispersão nas Figuras 24, 25, 27 e 28.
Foi levantada a hipótese desse conhecimento influenciar no uso do GuideAutomator, mas
não podemos provar que diferentes grupos de conhecimentos possuem vantagens de tempo e
número de acertos sobre outros grupos de conhecimentos em razão dos testes realizados. Isso
pode ter se dado devido ao uso da extensão de navegador, permitindo assim que pessoas que não
possuam conhecimentos técnicos em desenvolvimento Web possam fazer o uso do GuideAuto-
mator. Visualizando as Figuras 23 e 26, podemos visualizar os grupos de conhecimentos e os
respectivos tempos gastos e número de acertos para cada método utilizado.
45
Figura 23 – Gráfico Conhecimento Web X Tempo (minutos)
Figura 24 – Gráfico de dispersão de Conhecimento Web X Tempo (minutos) para versão MyBB2015
46
Figura 25 – Gráfico de dispersão de Conhecimento Web X Tempo (minutos) para versão MyBB2017
Figura 26 – Gráfico Conhecimento Web X Nº Acerto
47
Figura 27 – Gráfico de dispersão de Conhecimento Web X Acerto para versão MyBB 2015
Figura 28 – Gráfico de dispersão de Conhecimento Web X Acerto para versão MyBB 2017
48
Na análise do formulário de pós-experimento, os participantes relataram a falta de
familiaridade com a ferramenta, mas disseram estar cientes que é algo normal para um produto
em desenvolvimento e que após o desenvolvimento da versão MyBB 2015 do experimento, a
versão MyBB 2017 se tornou mais prática de realizar. Foi recomendado que alguns erros na
execução do GuideAutomator retornassem mais claros para facilitar o entendimento e a correção
desses erros.
Os participantes, em sua maioria, concordaram totalmente ao serem questionados se a
extensão do Firefox foi útil para a execução das tarefas do experimento, como visto na Figura 29.
Contudo, foi observado um problema ou limitação na extensão, como a impossibilidade de des-
fazer o comando outline no elemento. A extensão se mostrou um diferencial no desenvolvimento
do experimento.
Figura 29 – Gráfico do feedback dos participantes sobre a extensão
Ao serem questionados sobre problemas que impactavam a execução do experimento, sete
pessoas alegaram que a máquina utilizada estava lenta; isso pode ter se dado devido à máquina
física que estava executando a máquina virtual ou pelas baixas configurações da máquina
virtual diferirem das configurações das máquinas pessoais dos participantes. Os demais pontos
levantados no questionário foram marcados por pessoas isoladas, totalizando uma pessoa para
alguns problemas como falta de conhecimento em Linux, a interface do blog é confusa, problemas
ao utilizar o editor Atom e falta de conhecimento ao utilizar a ferramenta de desenvolvedor do
navegador.
49
5 Conclusão
A proposta inicial do GuideAutomator 1.0 para automatizar a geração de manuais,
facilitando sua escrita, manutenção e evolução, além de permitir o controle de versão da docu-
mentação, de modo geral, foi aceita por aqueles que fizerem parte do seu experimento piloto
original (OLIVEIRA; SOUZA, 2016). Entretanto, foi percebido que existiam algumas ressalvas
tanto relacionadas à performance do uso do GuideAutomator sobre método tradicional como ao
conhecimento web prévio do usuário (OLIVEIRA; SOUZA, 2016). Devido a esses resultados,
foram propostas algumas mudanças na ferramenta e uma nova elaboração de experimentos.
O GuideAutomator 2.4 passa a interpretar código JavaScript informado pelo usuário
deixando de usar uma linguagem própria do GuideAutomator. Na nova versão da ferramenta
ela adquire um maior poder em sua aplicação CLI, com uma maior quantidade de parâmetros
em sua execução, a criação de uma extensão de navegador para auxiliar o desenvolvimento
do desenvolvedor GuideAutomator. A re-escrita do código minimiza o impacto de futuras
manutenções e evoluções do código.
Na realização do novo experimento para o GuideAutomator 2.4 foi observado que na
primeira e na segunda versão do MyBB, o GuideAutomator levou mais tempo que o método
tradicional, mas comparando a evolução do sistema, a ferramenta reduziu em mais do que
a metade do tempo gasto na evolução, mostrando que para uma mudança de versão de uma
documentação do sistema, a ferramenta pode ser eficaz. Os participantes relataram ter dificuldade
ao utilizar a ferramenta no primeiro momento, mas ao término do experimento admitiram uma
melhora significativa no uso desta.
Um ponto importante a ser levantado é que com a criação da extensão foi percebido
um menor impacto na necessidade de conhecimento web na produção de manuais com o uso
da ferramenta. Diante disso, diminui-se, então, as restrições dos tipos de usuários que podem
utilizar a ferramenta, abrangendo, assim, o público-alvo do GuideAutomator.
Para trabalhos futuros, será avaliado o uso da ferramenta no processo de integração
contínua para que a evolução da documentação acompanhe a evolução do sistema, além de outras
possibilidades para o GuideAutomator, como, produção de vídeos ou de slides.
50
REFERÊNCIAS
ABNT. In: NORMA Brasileira - ABNT NBR ISO 9000. Associação Brasileira de NormasTécnicas, 2005. Disponível em: . Acesso em: 06 ago. 2017.
BASILI, V. R. The role of experimentation in software engineering: past, current, andfuture. Washington, DC, USA: Proceedings of the 18th international conference on Softwareengineering (ICSE ’96)., 1996.
HOLMES A.; KELLOGG, M. Automating functional tests using selenium. [S.l.]: AGILE2006 (AGILE’06), 2006. p. 6 p.
MYERS G. J.; SANDLER, C. B. T. The art of software testing. [S.l.]: John Wiley & Sons,2011. p. 6 p.
NIELSEN, J. Usability Problems Through Heuristc Evaluation. California, USA:Proceedings of the SIGCHI Conference on Human Factors in Computing Systems., 1992.
OLIVEIRA, A.; SOUZA, R. GuideAutomator: Automated user manual generation withMarkdown. In: Proceedings of the VII Brazilian Conf. on Software (CBSOFT), tools track.[S.l.: s.n.], 2016.
SOARES, M. dos S. Metodologias Ágeis extreme programming e scrum para o desenvolvimentode software. Revista Eletrônica de Sistemas de Informação, Minas Gerais, 2004. Disponívelem: . Acesso em: 06Ago. 2017.
SOUZA, R.; OLIVEIRA, A. Guideautomator: continuous delivery of end user documentation. In:IEEE PRESS. Proceedings of the 39th International Conference on Software Engineering:New Ideas and Emerging Results Track. [S.l.], 2017. p. 31–34.
WAITS T.; YANKEL, J. Continuous system and user documentation integration. IEEEInternational Professional Communication Conference (IPCC).: IEEE., 2014.
WOHLIN, C. Experimentation in Software Engineering: An Introduction. Bos-ton/Dordrecht/London: Kluwer Academic Publishers, 2012.
www.abnt.org.brhttp://www.periodicosibepes.org.br/index.php/reinfo/article/view/146/38
51
APÊNDICE A – Termo de Consentimento
"Uma Avaliação Experimental do Guide-Automator para elaboração de documentação para usuário final”
Concordo em participar dos estudos não invasivos os quais serão conduzidos pelo Professor Rodrigo Rocha e pelo aluno de Graduação da UFBA Welbert Azevedo Serra, como parte da atividade de Término de Curso, realizada na UFBA. Esse estudo visa a comparar a eficiência do Guide-Automator sobre a elaboração de manuais para usuário finais utilizando métodos tradicionais. PROCEDIMENTO Eu entendo que, uma vez o experimento terminado, os trabalhos que desenvolvi serão estudados visando a entender a eficiência do Guide-Automator na elaboração de manuais. Os pesquisadores conduzirão o estudo consistindo da coleta, análise e relato dos dados das atividades desenvolvidas. Eu entendo que não tenho obrigação alguma em contribuir com informação sobre meu desempenho na atividade, e que posso solicitar a retirada de meus resultados do experimento a qualquer momento e sem qualquer penalidade ou prejuízo. Eu entendo também que quando os dados forem coletados e analisados, meu nome será removido dos dados e que este não será utilizado em nenhum momento durante a análise ou quando os resultados forem apresentados. CONFIDENCIALIDADE Toda informação coletada neste estudo é confidencial, e meu nome não será identificado em momento algum. Da mesma forma, me comprometo a não comunicar os meus resultados enquanto não terminar o estudo, bem como manter sigilo dos documentos apresentados e que fazem parte do experimento, e respeitar as regras declaradas no escopo do referido experimento. BENEFÍCIOS e LIBERDADE DE DESISTÊNCIA. Eu entendo que os benefícios que receberei deste estudo são limitados ao aprendizado do material que é distribuído e ensinado visando atender os requisitos do experimento, independentemente de participar ou não desse estudo, mas que os pesquisadores esperam aprender mais sobre quão eficiente é a utilização de tecnologias de software e os benefícios trazidos por esses estudos para o contexto da Engenharia de Software. Eu entendo que sou livre para realizar perguntas a qualquer momento ou solicitar que qualquer informação relacionada à minha pessoa não seja incluída no estudo. Eu entendo que participo de livre e espontânea vontade com o único intuito de contribuir para o avanço e desenvolvimento de técnicas e processos para a Engenharia de Software. Nome (em letra de forma): ________________________________________________ Assinatura: ________________________________ Data: _________
53
54
APÊNDICE B – Questionário de caracterização do participante
55
56
APÊNDICE C – Questionário de pós-experimento
57
APÊNDICE D – Informações sobre o perfil dos participantes
58
59
APÊNDICE E – Documento elaborado no experimento
122234
Índice
ÍndiceMyBB
Introdução a página AdminAdd New ForumSearch for UsersDatabase Backups
1Made with guide-automator.
MyBB
Introdução a página Admin
A página de administrador está acessível em "http://localhost/bb/admin/index.php"
Após acessar a página administradora, será necessário entrar com suas credenciais paraacessar a página de administrador.
No menu da esquerda estão situadas as opções principais de cada categoria administrativada página, vamos comentar um pouco sobre as mais importantes.
Add New Forum
Você pode acessar a página de adição de um novo fórum através da seção 'Quick Access'no menu “Home” ou através do menu “Forums & Posts > Forum Management > Add NewForum”.
2Made with guide-automator.
Essa página tem como objetivo criar novos fóruns onde ocorrerá a discussão.
É necessário preencher os campos “Title” e “Parent Forum”, que indica qual é o pai ougrupo ao qual esse novo fórum pertence. Os demais campos são opcionais mas, para umamelhor organização, é recomendado preenchê-los.
Logo abaixo ao cadastro das informações básicas temos as permissões, que servem paraalterar a visibilidade e usabilidade do fórum para cada grupo de usuário. Ao completar ocadastro, é só clicar em “Save Forum”.
Search for Users
3Made with guide-automator.
Você pode acessar a página de busca de usuários através do “Quick Access” no menu“Home” ou através do menu “Users & Groups > Users > Find Users”.
Essa página tem como objetivo localizar usuários cadastrados no fórum e alterar, visualizare/ou penalizar o usuário. Para localizar todos os usuários cadastrados, clique no botão“Find User” sem preencher nenhum campo.
Database Backups
Você pode acessar a página de backup de banco de dados através do “Quick Access” nomenu “Home” ou através do menu “Tools & Maintenance > Database Backups”.
4Made with guide-automator.
Essa página tem como objetivo realizar rotinas de backups, cópias dos dados do fórum,para medidas de segurança.
Para realizar o backup, é necessário selecionar "New Backup", preencher as opções dascópias de segurança e clicar em “Perform Backup”.
5Made with guide-automator.
Folha de RostoDedicatóriaEpígrafeLISTA DE FIGURASLISTA DE TABELASLISTA DE ABREVIATURAS E SIGLASINTRODUÇÃOConceitos GeraisGuideAutomator 1.0 e Tecnologias usadasMarkdownSelenium WebDriverUnique CSS SelectorFuncionamento do GuideAutomator 1.0Análise experimental do GuideAutomator 1.0
Evolução do GuideAutomator Extração de blocoLinha de comandoExtensão de navegador do GuideAutomator Re-escrita do código fonteComandos GuideAutomator 2.4Correções e melhorias menores
Experimento ControladoConceito e ObjetivoDefiniçãoPlanejamentoOperaçãoAnálise e InterpretaçãoApresentação e Empacotamento
Experimento PilotoExperimento na turmaAnálise de eficiênciaAnálise de eficáciaAnálise de perfil e feedback
ConclusãoREFERÊNCIASTermo de ConsentimentoQuestionário de caracterização do participanteQuestionário de pós-experimentoInformações sobre o perfil dos participantesDocumento elaborado no experimento