UNIVERSIDADE FEDERAL DA BAHIA-UFBA ......UNIVERSIDADE FEDERAL DA BAHIA-UFBA DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO INSTITUTO DE MATEMÁTICA E ESTATÍSTICA WELBERT AZEVEDO SERRA AVALIAÇÃO

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: _________

54

APÊNDICE B – Questionário de caracterização do participante

56

APÊNDICE C – Questionário de pós-experimento

57

APÊNDICE D – Informações sobre o perfil dos participantes

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


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


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


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


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

Documents

UNIVERSIDADE FEDERAL DA BAHIA-UFBA ......UNIVERSIDADE FEDERAL DA BAHIA-UFBA DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO INSTITUTO DE MATEMÁTICA E ESTATÍSTICA WELBERT AZEVEDO SERRA AVALIAÇÃO