Departamento de Informática e Matemática Aplicada Bacharelado em Engenharia de Software
Custom Survey: Uma Ferrramenta para
Criação e Distribuição de Questionários
Customizados
Adelino Neto Segundo
Natal/RN Novembro 2017
Custom Survey: Uma Ferrramenta para Criação e
Administração de Surveys Customizados
Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte como requisito parcial para a ob-tenção do grau de bacharel em Engenharia de Software.
Orientador
Prof. Dr. Fernando Marques Figueira Filho
Universidade Federal do Rio Grande do Norte – UFRN Departamento de Informática e Matemática Aplicada – DIMAp
Natal-RN Novembro de 2017
Universidade Federal do Rio Grande do Norte – UFRN Sistema de Bibliotecas – SISBI
Catalogação da Publicação na Fonte - Biblioteca Central Zila Mamede Segundo, Adelino Neto.
Custom survey: uma ferramenta para criação e distribuição de questionários customizados / Adelino Neto Segundo. - 2017.
50 f. : il.
Monografia (graduação) - Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Curso de Engenharia de Software. Natal, RN, 2017
Orientador: Prof. Dr. Fernando Marques Figueira Filho.
1. Survey - Monografia. 2. Questionário - Monografia. 3. Pesquisa - Monografia. 4. Design participativo - Monografia. 5. Questionário customizado - Monografia. I. Figueira Filho, Fernando Marques. II. Título.
RN/UF/BCZM CDU
e Distribuição de Surveys Customizados apresentada por Adelino Neto Segundo e aceita pelo Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Prof. Dr. Fernando Marques Figueira Filho
Orientador
Departamento de Informática e Matemática Aplicada UFRN
Prof. Dr. Gibeon Soares de Aquino Junior
Departamento de Informática e Matemática Aplicada UFRN
Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena
Departamento de Informática e Matemática Aplicada UFRN
Meu pai, Sandro, pela educação e oportunidades que me deu ao longo da minha trajetória. Meu irmão, Diogo, por todos os conhecimentos que me passou em vida.
Distribuição de Questionários Customizados
Autor: Adelino Neto Segundo Orientador: Prof. Dr. Fernando Marques Figueira Filho
Resumo
Em um processo de desenvolvimento de software muitas vezes faz-se necessário rea-lizar uma pesquisa junto aos usuários finais do produto. O método mais frequentemente utilizado para a realização dessas pesquisas é o Survey, através da aplicação de questio-nários.
Os pesquisadores são limitados a elaboração de perguntas genéricas, que possam ser respondidas pela maior parte da amostra e, mesmo tendo informações pre-coletadas dos participantes, torna-se difícil elaborar questionários mais específicos para cada indivíduo da amostragem.
Dessa forma, este trabalho apresenta uma ferramenta que permite aos pesquisadores criarem e distribuirem questionários customizados com informações pre-coletadas sobre os participantes da pesquisa, além de descrever as etapas de desenvolvimento e utilização da ferramenta, através da construção da arquitetura do projeto, e do uso do método de Design Participativo ao longo do processo de desenvolvimento e validação do sistema. Palavras-chave: Survey. Questionário. Pesquisa. Design Participativo. Questionário Cus-tomizado.
of Context Surveys
Author: Adelino Neto segundo Advisor: Prof. Dr. Fernando Marques Figueira Filho
Abstract
In a software development process researches with the software users are often used. The most used method is the survey with questionnaires.
The researchers are limited to the elaboration of generic questions, that can be answe-red by the bigger part of the sample, even with pre-collected of the participants, it‘s difficult to elaborate specific questionnaires for each individual.
That way, this paper presents a tool that allows researchers to create and distribute custom questionnaires with pre-collected information about the participants, and also describe the tool development and use steps, through the project architecture build and the use of Participatory Design through development and validation process.
1 Arquitetura MVC Rails. . . p. 21 2 Diagrama de Classes. . . p. 22 3 Listagem de questionários. . . p. 25 4 Novo Questionário. . . p. 26 5 Arquivo CSV. . . p. 26 6 Edição de questões. . . p. 27 7 Adicionando uma mensagem. . . p. 28 8 Adicionando uma questão de texto. . . p. 29 9 Adicionando uma questão de múltipla escolha. . . p. 30 10 Adicionando uma página. . . p. 31 11 Distribuindo um questionário. . . p. 32 12 Distribuindo um questionário: Exemplo. . . p. 33 13 Email resultante. . . p. 33 14 Distribuindo um questionário: . . . p. 34 15 Respondendo um questionário: Página 1. . . p. 35 16 Respondendo um questionário: Página 2. . . p. 36 17 Respondendo um questionário: Página 2 com erros de validação. . . p. 37 18 Respondendo um questionário: Página final. . . p. 38 19 Resultados de um questionário. . . p. 39 20 Convidando colaboradores: Exemplo. . . p. 40 21 Template de email do primeiro uso da ferramenta. . . p. 42 22 Classes Importadas. . . p. 44
24 Importação de código: Rheco.me - Questionários. . . p. 46 25 Importação de código: Rheco.me - Emails. . . p. 47
1 Introdução p. 10 1.1 Motivação . . . p. 12 1.2 Estrutura do Trabalho . . . p. 13 2 Fundamentação Teórica p. 14 2.1 Design Participativo . . . p. 14 3 Metodologia p. 16
3.1 Estudo das Ferramentas Existentes . . . p. 16 3.1.1 Google Forms . . . p. 17 3.1.2 Survey Monkey . . . p. 17 3.1.3 Type Form . . . p. 18 3.2 Definição dos Requisitos da Ferramenta e Implementação . . . p. 18
4 Projeto de Solução p. 20
4.1 Arquitetura . . . p. 20 4.2 Custom Survey . . . p. 23 4.2.1 Listagem de Questionários . . . p. 24 4.2.2 Criação de um Questionários . . . p. 25 4.2.2.1 Criando um questionário Parte 1: Inserção de dados . p. 26 4.2.2.2 Criando um questionário Parte 2: Questões . . . p. 27 Adicionando uma mensagem . . . p. 28 Adicionando uma questão de texto . . . p. 29
Adicionando uma página . . . p. 31 4.2.3 Distribuindo um questionário . . . p. 32 4.2.4 Respondendo um questionário . . . p. 34 4.2.5 Resultados do questionário . . . p. 39 4.2.6 Convidando colaboradores . . . p. 40 4.2.7 Limitações da Ferramenta . . . p. 40 5 Estudos de Caso p. 41
5.1 Observação do uso da Ferramenta . . . p. 41 5.2 Importação do Código . . . p. 43 5.2.1 Portal Brasil Junior . . . p. 43 5.2.2 Rheco.me . . . p. 46
6 Considerações Finais p. 48
1
Introdução
A pesquisa é a atividade nuclear da Ciência (SILVEIRA; CóRDOVA, 2009). Os métodos de pesquisa podem ser quantitativos ou qualitativos, devendo sua escolha estar associada aos objetivos da pesquisa (FREITAS et al., 2000).
Segundo Fonseca, na pesquisa científica investiga-se uma pessoa ou grupo capacitado, abordando um aspecto da realidade, no sentido de comprovar experimentalmente hipóteses (FONSECA, 2002).
A elaboração de uma pesquisa deve ser feita a partir de critérios muito bem definidos, para que a margem de erro nos resultados seja mínima. A primeira coisa a ser definida é o método de pesquisa que será utilizado (SILVEIRA; CóRDOVA, 2009). Existem diversos mé-todos de pesquisa que podem ser utilizados, tais como a Pesquisa Experimental, Pesquisa Bibliográfica, Pesquisa Documental, Pesquisa de Campo entre outras, mas que não serão tratadas nesse projeto. O foco deste projeto está no método de Pesquisa com Survey.
A Pesquisa com Survey refere-se a obtenção de dados ou informações sobre as carac-terísticas ou as opiniões de determinado grupo de pessoas, indicado como representante de uma população-alvo, utilizando um questionário como instrumento de pesquisa ( FON-SECA, 2002).
Santos descreve a Pesquisa com Survey como sendo a busca de informação direta-mente com um grupo de interesse a respeito dos dados que se deseja obter, sendo útil principalmente em pesquisas exploratórias e descritivas (SANTOS, 1999).
Como citado, o método de pesquisa com survey faz uso de questionários, que podem ser utilizados tanto para pesquisas quantitativas como qualitativas, com perguntas abertas ou fechadas, pré-definidas e normalmente amplas, para que atinjam uma amostragem maior da população-alvo. Entretanto, quando mal elaborados, os questionários podem apresentar uma alta margem de erro em seus resultados, o que prejudica a pesquisa. Dessa forma, a elaboração deles deve ser feita de forma rigorosa, diminuindo essa margem de erro.
Em um processo de pesquisa podem ocorrer dois tipos de erros: amostrais e não-amostrais (CHAGAS, 2000). Os primeiros referem-se a má escolha da amostra e de seu tamanho. E o segundo está ligado a má elaboração do questionário e de suas perguntas.
Uma das principais etapas no desenvolvimento de uma pesquisa está na definição do grupo representativo da população-alvo, ou seja, a quem a pesquisa será direcionada. A má escolha desse grupo poderá acarretar em resultados errôneos para a pesquisa. Freitas afirma que um ponto primordial a ser observado é se os respondentes (indivíduos que for-necem a informação) realmente representam a unidade de análise (aquilo que se pretende analisar) (FREITAS et al., 2000).
Ademais, Freitas também afirma que outro aspecto que gera erros nos resultados de uma pesquisa, além da imprecisão na definição da população-alvo, refere-se a não-resposta, ou seja, quando a maior parte da amostra não responde o questionário, resultando assim em poucos dados (FREITAS et al., 2000).
Um outro aspecto considerado problemático na construção de uma pesquisa, e que acaba gerando erros, acontece no processo de elaboração do questionário e de suas per-guntas. Parasuraman afirma que construir um questionário não é uma tarefa fácil e que aplicar tempo e esforço adequados para a construção dele é uma necessidade, um fator de diferenciação favorável para os resultados da pesquisa (PARASURAMAN, 1991).
Em seu estudo, Selltiz et al [1974] falam sobre os fatores que influenciam os resul-tados de uma pesquisa por questionário, sendo um deles a sua má elaboração, quando apresentam questões tendenciosas, dúbias ou mal posicionadas (SELLTIZ, 1974).
Por isso Freitas enfatiza a importância de um questionário bem construído e apli-cado, tomando cuidado com a formulação das perguntas, de modo que tenham o mesmo significado tanto para o pesquisador como para o participante, garantindo dessa forma a redução no nível de erro não-amostral (FREITAS et al., 2000).
Ao longo do processo de construção de uma pesquisa, o pesquisador normalmente seleciona sua amostra a partir de um critério pré-definido e então aplica o questionário para obter mais informações sobre os participantes. No entanto, imaginemos o contrário, em que o pesquisador já selecionou os participantes através de um critério e também já possui todas as informações pertinentes sobre eles, mas deseja aprofundar esses dados através da aplicação de um questionário específico para os indivíduos dessa população.
Para aplicar um questionário com perguntas mais específicas para uma população-alvo, o pesquisador precisaria generalizar as perguntas de forma a abranger a maior parte
da população ou elaborar perguntas individuais para cada participante, ou seja, um ques-tionário diferente para cada participante, o que se torna inviável dependendo do tamanho da amostra.
Dessa forma, a construção de uma ferramenta capaz de elaborar questionários cus-tomizados para pesquisas, permitindo a elaboração de perguntas genéricas ou específicas para cada participante, fazendo uso de informações pré-coletadas sobre a população-alvo se torna essencial para melhorar os resultados de pesquisas.
Este estudo propôs a elaboração de tal ferramenta partindo das limitações existentes nas ferramentas de surveys similares. O Custom Survey é uma ferramenta para elaboração de questionários customizados, que permite ao pesquisador inserir dados pré-coletados e individuais dos participantes em suas perguntas, gerando dessa forma um questionário específico para cada indivíduo da amostra. As limitações das ferramentas similares e detalhes desta ferramenta serão melhor apresentados nas seções que seguem.
1.1
Motivação
Tomemos como exemplo João, um pesquisador que possui dados já coletados de 1000 usuários do sistema Quest3000, um fórum para compartilhamento de dúvidas sobre desen-volvimento. Em sua pesquisa, João deseja identificar quais são as motivações que levam indivíduos a compartilharem conteúdo dentro desse fórum. Assim, entre os dados cole-tados, tem-se o nome do usuário, email, número de perguntas e respostas já realizadas, alguns textos publicados pelos usuários, a data desses textos, e as áreas de interesse de cada um.
Na primeira parte de sua pesquisa, João identificou quais os usuários que mais com-partilham perguntas e respostas, e os que menos comcom-partilham. Dos usuários analisados foram pré-selecionados 1000 para irem para a próxima etapa da pesquisa.
Tendo os dados dos usuários pré-selecionados, João deseja compreender quais os pa-drões e diferenças entre os usuários mais participativos e os menos participativos do sis-tema; analisando o que motiva os usuários a compartilharem as perguntas e respostas e qual a opinião de cada um sobre os conteúdos que eles mesmos já compartilharem alguma vez.
Para isso, João precisará aplicar um questionário para cada usuário, pois precisa contextualizar nas perguntas dados específicos de cada um, como por exemplo “Senhor
<Mario José>, o senhor já respondeu um total de <100> tópicos na área de <desenvol-vimento mobile>, mas possui apenas <1> tópico como autor. Por que o senhor prefere responder tópicos já existentes ao invés de criar novos?”.
Entretanto, João percebe que se utilizar as ferramentas comuns de elaboração de questionários precisará construir um para cada usuário, ou seja, 1000 questionários dife-rentes. Dessa forma, João decide então utilizar o sistema Custom Survey, pois com essa ferramenta, elaborará as perguntas contextualizadas que deseja e, no lugar onde estará os dados individuais, colocar apenas uma « tag » que será interpretada com os dados de cada usuário, tirados de uma planilha CSV. Por exemplo, a pergunta já citada, de forma genérica ficaria “Senhor «nome do usuário>, o senhor já respondeu um total de «total de respostas» tópico(s) na área de «área de conhecimento», mas possui apenas «total de pu-blicações» tópico(s) como autor. Por que o senhor prefere responder tópicos já existentes ao invés de criar novos?”.
Além de elaborar um único questionário com perguntas contextualizadas para usuários diferentes. João também poderá enviar esse questionário por email para cada participante e, ao receberem o link do questionário, os dados entre as «tags» serão substituídos pelas informações dos usuários contidas na planilha. Com isso, João consegue um número maior de respostas para sua pesquisa, com conteúdo muito mais relevante e real, pois os usuários percebem que as perguntas são destinadas especificamente a eles.
1.2
Estrutura do Trabalho
A organização desta trabalho é apresentada através de Capítulos, da seguinte forma:
1. O Capítulo 2 apresenta o conceito de Design Participativo, utilizado no processo de construção da ferramenta Custom Survey.
2. No Capítulo 3 é explicado os procedimentos utilizados durante a concepção e análise da ferramenta, tomando como base o Design Participativo.
3. O Capítulo 4 apresenta a descrição da ferramenta Custom Survey. 4. O Capítulo 5 descreve estudos de caso da ferramenta e de seu código 5. O Capítulo 6 aborda as considerações finais sobre o trabalho
2
Fundamentação Teórica
2.1
Design Participativo
Uma grande dificuldade no processo de desenvolvimento de Software é entregar um produto que agrade totalmente o cliente. Isso acontece, pois em um processo normal o cliente está presente apenas na fase de elicitação dos requisitos do sistema, em que solicita as funcionalidades desejadas, e essas são trabalhadas pelos desenvolvedores.
A fase de elicitação de requisitos possui o desafio de entender os desejos e necessidades do cliente e usuário, mas o grande desafio aqui está na dificuldade de obtenção de uma visão real do que deve ser o sistema (ROSEMBERG et al., 2008), pois em muitos casos a visão do cliente não é completamente captada pelos designers e desenvolvedores, resultando em um produto diferente do esperado.
Morais et al afirmam que um dos problemas resultantes da fase de elicitação ocorre quando se desenvolvem funcionalidades e/ou interfaces de forma distorcida da desejada/ requerida pelo usuário, culminando na má ou nenhuma utilização do software (MORAIS; GOMES; PERES, 2012).
Esse tipo de metodologia de desenvolvimento gera muito desgaste e utiliza muito mais tempo que o necessário para o desenvolvimento do sistema, além de trazer muitos proble-mas junto aos clientes, pela falta de comunicação. Esses probleproble-mas podem ser minimizados com a participação ativa do cliente e usuário ao longo de todo o processo de concepção e desenvolvimento do sistema.
Segundo Nielsen, a participação dos usuários ao longo do processo de desenvolvimento é importante, pois eles levantam questões interessantes sobre as quais os designers não pensariam, pois as tarefas reais dos usuários podem ser diferentes dos modelos conceituais que os designers possuem dessas tarefas (NIELSEN, 1993).
Um dos métodos utilizados atualmente que faz uso da participação ativa dos usuários durante o processo de desenvolvimento do sistema é o Design Participativo (ou
Partici-patory Design).
O Design Participativo surgiu na Escandinava nos anos 70 e foi ganhando cada vez mais destaque ao longo dos anos, sendo utilizado nas mais diversas áreas, incluindo o desenvolvimento de software.
Esse método é tido como uma abordagem de projeto de interfaces onde os usuários estão ativamente envolvidos no processo de desenvolvimento, tornando-se parceiros dos demais membros da equipe de design (ROGERS; SHARP; PREECE, 2002).
Para Schuler e Namioka o Design Participativo descreve uma abordagem colaborativa do design de produtos, serviços, espaços ou sistemas que inclui todas as partes interessadas ao longo do processo criativo, tomando decisões críticas sobre o produto. E acreditam que essa abordagem colaborativa entre os designers e usuários leva a resultados mais eficazes, apropriados e desejados (SCHULER; NAMIOKA, 1993).
Este projeto fez uso da abordagem do Design Participativo ao longo de todo o processo de elicitação e desenvolvimento do produto, através da coleta, análise e projeção do sistema de forma colaborativa com os stakeholders envolvidos; Camargo e Fazani afirmam que os stakeholders do projeto podem ser os próprios usuários finais do sistema, os clientes ou mesmo a equipe de desenvolvimento (CAMARGO; FAZANI, 2014). Neste projeto, os stakeholders principais foram o desenvolvedor, papel tomado por mim; E o usuário/cliente, tomado pelo Prof. Fernando.
O Design participativo permite que todos os interessados e pessoas relevantes ao projeto participem ativamente no processo de elaboração de desenvolvimento dele. Dessa forma, diminui a margem de erro entre o que o cliente quer e o que será entregue a ele, resultando em uma maior aceitação do produto final.
3
Metodologia
Este trabalho descreve os processos de elaboração e desenvolvimento da ferramenta Custom Survey, que tem como objetivo possibilitar a elaboração e aplicação de questioná-rios customizados, com questões individualizadas para cada participante, de acordo com informações pré-coletadas sobre cada um deles.
Este Capítulo descreve a análise de algumas ferramentas já existentes no mercado. E também as etapas de elicitação de requisitos, desenvolvimento e testes do sistema Custom Survey.
3.1
Estudo das Ferramentas Existentes
Um aspecto primordial no desenvolvimento de uma Pesquisa com Survey está na forma da construção e distribuição dos questionários. Atualmente a maioria dos pesquisadores elabora e distribui suas pesquisas pelo meio virtual, através de ferramentas online como o Google Forms, TypeForms e Survey Monkey.
Entretanto, essas ferramentas apresentam limitações quanto a elaboração de pergun-tas contextualizadas, por exemplo, em algumas pesquisas faz-se necessária a aplicação de questionários mais específicos para os participantes de um grupo, com perguntas direciona-dos especificamente a cada um, e cujas respostas complementem os dadireciona-dos já pré-coletadireciona-dos. Para elaborar e aplicar essas perguntas atualmente faz-se necessário construir um questionário único para cada participante, o que torna-se trabalhoso dependendo do nú-mero de participantes da amostra.
Neste Capítulo analisamos algumas das ferramentas para construção e distribuição de Surveys online populares no mercado. Esta análise foi realizada com o intuito de verificar as principais características dessas ferramentas, identificando como são criadas as perguntas, como é realizada a distribuição dos questionários, e como são dadas as respostas, identificando dessa forma quais suas limitações.
As ferramentas para construção de distribuição de questionários analisadas foram o Google Forms, Survey Monkey e Type-Form, que são ferramentas populares e que oferecem uma versão de uso gratuita.
Percebemos que se quiséssemos elaborar questionários com perguntas específicas para cada participante utilizando as ferramentas citadas, seria necessário elaborar um ques-tionário individualizado para cada participante. Verificamos dessa forma uma limitação dentro desses sistemas, que foi utilizada como base na construção deste projeto.
3.1.1
Google Forms
O Google Forms (https://www.google.com/intl/pt-BR/forms/about/) é uma das fer-ramentas online distribuídas pela empresa Google. Essa ferramenta possibilita a criação de formulários personalizados online totalmente gratuitos.
Os formulários criados ficam ligados a sua conta da google e podem ser disponibilizados de forma pública através de um link de compartilhamento, ou de forma privada enviando o link individualmente para o email dos interessados.
Tanto o formulário, como as perguntas podem ser personalizados, existindo diversos tipos de perguntas, como texto, múltipla escolha, escala likert, etc. Além disso, é possível a criação de perguntas condicionadas a uma resposta específica, isto é, o usuário só é levado a uma pergunta X, se a resposta da pergunta anterior for exatamente Y. As respostas do formulário podem ser visualizadas através de gráficos, ou em um documento CSV.
3.1.2
Survey Monkey
Foi analizada a versão grátis da ferramenta Survey Monkey, e foi observado que essa faz a divisão do formulário em páginas. Para a elaboração dos questionários pode-se adicionar perguntas de múltipla escolha, texto, escala likert, barra deslizante, data e horário, além de informações multimídia.
Nesta ferramenta, assim como no Google forms, é possível criar perguntas condicio-nadas baseadas nas respostas de questões múltipla escolha. Também é possível a persona-lização do layout do questionário através de temas, permitindo a modificação das cores, tipografia e imagem de fundo.
As respostas do questionários podem ser exportadas para um arquivo em formato PDF, XLS, planilha Google ou SPSS.
3.1.3
Type Form
O TypeForm é uma ferramenta de elaboração de formulários que permite a persona-lização dos formulários e perguntas, com mudança da cor e da fonte, além da utipersona-lização de imagens nas perguntas e respostas, entre muitas outras opções de personalização.
Entretanto, essas opções mais avançadas são limitadas pela parte paga da ferramenta. A parte gratuita assemelha-se muito as opções disponibilizadas pelo google forms.
Através desse estudo, observamos que essas ferramentas apresentam possibilidades de elaboração de questionários excelentes. Com diversas opções de perguntas (múltipla escolha, escala likert, parágrafo, etc), mas que essas perguntas não podem ser customizadas com contextos únicos referentes a dados individuais de cada participantes.
3.2
Definição dos Requisitos da Ferramenta e
Imple-mentação
O método de desenvolvimento da ferramenta Custom Survey foi composto por ciclos de desenvolvimento. Iniciamos, através de reuniões presenciais, a elicitação dos requisi-tos, seguindo para a implementação desses requisitos e sua validação. Essa validação foi realizada pelo professor Fernando, que participou de todo o processo no papel de cliente in-teressado. Quando validados, iniciávamos a elicitação de novos requisitos. E assim seguiu, em forma de ciclo, todo o processo de desenvolvimento até a versão atual do sistema.
Nesse projeto, fizemos uso do conceito de Design Participativo ao longo de todo o processo de elicitação e desenvolvimento da ferramenta, desde a concepção da ideia, até a parte de testes do sistema, colhendo feedbacks de colegas desenvolvedores e possíveis usuários da ferramenta para validar.
Optamos por isso pois tínhamos uma equipe reduzida, sendo composta apenas por um desenvolvedor e um professor, este último tomou para si o papel de cliente e usuário final, participando de todo o processo de concepção e elicitação dos requisitos.
Tomando como base a necessidade inicial apresentada, e as limitações vistas em al-gumas das ferramentas mais fortes do mercado, definimos os requisitos necessários para o desenvolvimento da ferramenta Custom Survey.
Alguns requisitos, como a necessidade de recuperar informações do Github, definidos no princípio do desenvolvimento foram descartados, outros como a necessidade do
geren-ciamento da distribuição do survey foram adicionado. Com resultado final descrito abaixo como historias de usuários.
1. Eu, como pesquisador, quero:
(a) Cadastrar um questionário com título, descrição, um dicionário com informa-ções dos usuários, quebras de paginas, mensagens, questões de texto e de múl-tipla escolha.
(b) Editar as informações de um questionário (c) Excluir um questionário
(d) Cadastrar uma mensagem de email a ser enviada para os usuários presentes no dicionário cadastrado no questionário.
(e) Enviar a mensagem por email para os usuários presentes no dicionário cadas-trado no questionário contento um link pro questionário ou não.
(f) Re-enviar a mensagem por email para um ou mais usuários. (g) Exportar as resposta dos usuários em formato CVS.
2. Eu, como usuário, quero responder o questionário.
Após a elaboração dos requisitos base do sistema. Iniciamos o processo de implemen-tação. O desenvolvimento dessa ferramenta foi realizado tomando como base o processo de design participativo, de forma iterativa e incremental.
4
Projeto de Solução
Esse Capítulo apresenta a arquitetura utilizada no projeto solução, além de descrever o projeto com suas funcionalidades.
As tecnologias abaixo descritas foram escolhidas tendo como base experiencias de sucesso em outros projetos web em que foram utilizadas.
4.1
Arquitetura
O projeto foi desenvolvido na linguagem de programação Ruby, através do framework web Ruby on Rails. Esse framework baseia-se em dois conceitos: o DRY (Don’t repeat yourself - Não se repita) e o Convetion over configuration.
O conceito DRY afirma que cada parte do sistema deve possuir uma representação única, que será definida em apenas um lugar e então reutilizada em outros, evitando assim retrabalho e também ambiguidades em todo o sistema. Dessa forma, ao modificarmos uma determinada parte do sistema, não será gerada alterações em partes não relacionadas, além de as partes relacionadas mudarem de forma previsível.
Já o Convention over configuration afirma que configurar um framework leva muito tempo e é desnecessário, dessa forma o framework é "pré configurado"com convenções da comunidade, podendo ser alterado sob demanda.
Para atingir esses conceitos o framework implementa diversos padrões de projeto, tais como ActiveRecord, ActionPack, ActionMailer, ActiveSupport, ActionWebServices, sendo o principal deles o ActiveRecord. Esse padrão de projeto é um ORM (Object-relational mapping - Mapeamento objeto-relacional), técnica utilizada para mapear tabelas de um banco de dados relacional como um modelo, em que cada tabela representa uma classe, cada linha um objeto e cada coluna um atributo persistente.
in-serções, atualizações, exclusões, consultas e transações. Toda essa interface de métodos funciona independente do banco de dados escolhido, desde que este seja relacional. Dessa forma, a aplicação funciona independente da infraestrutura do servidor.
A arquitetura adota foi o MVC (Model-View-Controller, Modelo-Visão-Controlador), arquitetura padrão do framework utilizado. Nessa arquitetura, toda a lógica de negócio do sistema é implementada na camada de Modelo e utilizada pelas demais camadas do sistema. A camada de Controle é responsável por chamar os métodos implementados no Modelo aplicar os resultados em templates (html, planilhas, json, csv, etc) definidos na camada de Visão, e enviar o retorno para o servidor de aplicação. Na Figura 1 apresentada abaixo, podemos visualizar de forma mais completa o funcionamento de uma arquitetura MVC.
Com essa arquitetura foram implementadas as seguintes classes na camada de modelo, Figura 2.
Figura 2: Diagrama de Classes.
Para implementar a distribuição dos emails duas outras tecnologias foram utilizadas, Redis e Sidekiq.
O Redis é uma aplicação de armazenamento com estrutura de dados de chave-valor de código aberto e na memória. O Redis oferece um conjunto de estruturas versáteis de dados na memória que permite a fácil criação de várias aplicações personalizadas.
Sidekiq é uma biblioteca ruby (Gem) que gerencia múltiplos processos através da utilização de threads. Esse biblioteca se integra com o framework Rails, e a comunicação entre aplicação e Sidekiq ocorre através do Redis.
O Sidekiq foi utilizado para enviar emails em uma thread concorrente a aplicação, dessa forma a aplicação suporta o envio de uma grande quantidade de emails.
Para disparar os emails foi utilizado um serviço web, Mailgun, essa aplicação fornece o serviço de envio de emails com domínios próprios e se comunica com outras aplicações através de uma API Rest.
4.2
Custom Survey
O Custom Survey é uma ferramenta de código livre que já possui uma versão em execução1, que só está acessível aos stakeholders do projeto. Para obter informações sobre licença e o código da ferramenta basta acessar seu repositório público2.
Na ferramenta o usuário pode gerenciar, distribuir os questionários, ver e exportar seus resultados, e convidar colaboradores para gerenciar um questionário. Essas ações serão descritas nas seções abaixo.
Para cadastrar um questionário o usuário precisa de um arquivo CSV com as infor-mações dos destinatários. Um questionário é composto por páginas e cada pagina por questões de texto, questões de múltipla escolha e mensagens.
Um questionário possui três estados: Cadastrado, Enviado e Respondido. Ao ser cadastrado, o questionário vai para o estado Cadastrado, após o começo das distribui-ções, passa para o segundo estado, de Enviado e logo após a primeira resposta ele passa para o último estado, Respondido. Esses estados são utilizados para permitir ou proibir ações na ferramenta.
Para editar o questionário e suas questões, ele não deve possuir respostas, senão essa ação fica bloqueada. Também só é possível acessar a tela de resultados se houver no mínimo uma resposta enviada. Apenas o criador do questionário pode convidar colaboradores e apagar o questionário.
Para distribuir o questionário será necessário cadastrar a mensagem que será utilizada na distribuição por email.
1
http://survey.dimap.ufrn.br
2
4.2.1
Listagem de Questionários
A primeira tela acessada pelo usuário é a tela de autenticação. Nessa tela, o usuário deverá inserir seu login e senha que permitem acesso ao sistema. Ao logar no sistema, o usuário é levado para a tela principal da aplicação. Nessa tela apresentamos a listagem dos questionários já criados pelo usuário em forma de tabela, em que cada linha apresenta um questionário. Os usuários tem acesso apenas aos questionários criados por eles ou por outros usuários que tenham os convidado como colaborador. Na Figura 04 mostramos a tela principal do sistema, onde são listados os questionários.
Essa tela também possibilita a navegação para todas as ações que podem ser realizadas com os questionários, como "Distribuir (Delivery)", "Ver resultados (Results)", "Convidar colaboradores (Invite)", "Editar (Edit)", "Editar questões (Edit questions)"e "Apagar (Destroy)".
Figura 3: Listagem de questionários.
A partir dessa interface é possível também ser direcionado para a tela de criação de questionário (New Survey) que será descrita mais abaixo.
4.2.2
Criação de um Questionários
Qualquer usuário cadastrado no sistema pode criar um questionário. O fluxo de criação de questionário foi quebrado em duas partes facilitar a interação com usuário. Na primeira parte é informado os dados básicos do questionário; e na segunda parte, a criação das questões do questionário.
Os questionários são divididos em páginas e em questões/mensagens. Um questio-nário possui páginas e cada página possui questões e mensagens. Esses elementos serão apresentados na segunda parte criação do questionário.
4.2.2.1 Criando um questionário Parte 1: Inserção de dados
Aqui são inseridas as seguintes informações: nome (Name), que será utilizado na lista-gem interna; título (Title), que será mostrado para os destinatários; arquivo CSV (Users data file), de onde serão extraídas as informações para traduzir as tags; e o nome da coluna que contém os emails dos destinatários (Email tag) de acordo com as Figuras 4 e 5.
Figura 4: Novo Questionário.
4.2.2.2 Criando um questionário Parte 2: Questões
Aqui são inseridas as questões e suas respectivas informações, que serão descritas a seguir. Como podemos verificar, do lado direito dessa interface é possível visualizar as tags disponíveis para uso, também é possível visualizar os links para inserir os elementos do questionário de acordo com a Figura 6.
Figura 6: Edição de questões.
Para inserir uma nova página deve-se clicar no botão New page. Para cada página será possível inserir mensagens, questões de texto e questões de múltipla escolha através dos botões Message, Text Question, Multiple Choice Question respectivamente.
Para todos os elementos de uma página deve-se informar o numero do item (Item) que será utilizado para ordenar os elementos no questionário.
Em todos os campos do questionário, exceto o nome, títulos e campos numéricos, é possível utilizar a funcionalidade de tags.
A funcionalidade das tags funciona da seguinte forma, deve-se inserir no seguinte formato “« NomeDaColuna »“ em algum campo do survey e a coluna será traduzida para uma informação contida no CSV caso a mesma exista, caso contrário será deixado em branco a informação.
Adicionando uma mensagem
Figura 7: Adicionando uma mensagem.
Quando inserindo uma mensagem, deve-se informar o conteúdo da mensagem (Con-tent) como mostrado na Figura 7.
Adicionando uma questão de texto
Figura 8: Adicionando uma questão de texto.
Quando inserido uma questão de texto, deve-se informar o número da questão (Num-ber) - que será impresso para o destinatário independente da ordem, o título da questão (Title) e a descrição (Description). A questão de texto apresenta a opção “é obrigatório” (Is required), que quando marcada define a obrigatoriedade de resposta pelo destinatário. Segue um exemplo de preenchimento de uma questão de texto.
Adicionando uma questão de múltipla escolha
Figura 9: Adicionando uma questão de múltipla escolha.
Quando inserindo uma questão de múltipla escolha, Figura 9, também é necessário informar o número, título e descrição, além das alternativas (Alternatives) da questão.
Para adicionar uma alternativa, deve-se clicar no botão “+ add” localizado próximo ao label Alternatives.
Cada alternativa tem um campo para informar o valor (Value) da alternativa e um botão para eliminar a alternativa.
Adicionando uma página
Figura 10: Adicionando uma página.
Quando adicionada uma nova página, novos botões para adicionar elementos nela serão criados. A página contem um valor (Page) que será utilizado para ordenação
Atualmente só é possível utilizar esses quatro elementos para criação do questioná-rio, o que o torna limitado quando comparado as outras ferramentas do mercado. Essas limitações serão melhor descritas na sessão Limitações da Ferramenta.
4.2.3
Distribuindo um questionário
Nessa parte do sistema será possível cadastrar e alterar a mensagem que será utilizada para distribuir o questionário e acompanhar as informações de envio.
Figura 11: Distribuindo um questionário.
Na parte superior dessa página existe o formulário para cadastro e alteração do tem-plate de email a ser enviado, e ao seu lado as tags disponíveis para uso. Na parte inferior possível ver um botão para enviar os emails para os destinatários (Send All), e uma ta-bela com uma lista de destinatários, essa tata-bela so é preenchida após o preenchimento dos dados da mensagem de email.
O email contém dois campos: o assunto (Subject) e o conteúdo (Content).
Para a construção do email existe uma tag adicional, reply_link (Link para res-posta). Essa tag é traduzida para o link único de resposta do destinatário.
Segue um exemplo de mensagem com o email resultante nas figuras 12 e 13 respecti-vamente.
Figura 12: Distribuindo um questionário: Exemplo.
Figura 13: Email resultante.
Após preenchimento das informações de envio o botão Send All fica disponível assim como a listagem de destinatários.
Figura 14: Distribuindo um questionário: .
Nessa listagem aparecem as seguintes informações sobre o destinatário, o email, se o email foi enviado ou não para o mesmo (Sent), se ele respondeu ou não o questionário (Replied), um link para visualizar a página de respostas (Test Reply), e um botão para enviar o email apenas para o destinatário em questão (Send)
4.2.4
Respondendo um questionário
Essa é a interface de resposta do survey, as tags foram traduzidas utilizando o conteúdo do arquivo CSV da Figura 5.
Todas as páginas de respostas vão apresentar o título da survey, o conteúdo da página e o botão de envio.
O botão de envio pode se apresentar como "Próximo"(Next) ou "Enviar"(Send), va-riando caso haja ou não uma próxima página.
Figura 15: Respondendo um questionário: Página 1.
Na Figura 15 podemos ver a primeira página de resposta do questionário, onde é exibido a mensagem com a tag "UserName"traduzida.
Mensagem original: "Hi « UserName », this will be a short survey. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua."
Figura 16: Respondendo um questionário: Página 2.
Na Figura 16, podemos ver a segunda página de respostas do questionário, que contem duas questões, uma de múltipla escolha e uma de texto.
Título original da questão de número 1: "How often do check your repo « Repo(s) »?" Título original da questão de número 1: "How often do check your repo « Repo(s) »? Why?"
Figura 17: Respondendo um questionário: Página 2 com erros de validação.
Na Figura 17 podemos ver a exibição dos erros caso se tente enviar o questionário sem responder as questões cadastradas como obrigatórias.
Figura 18: Respondendo um questionário: Página final.
A Figura 18 mostra a tela final do processo de de resposta do questionário, que é uma mensagem de agradecimento pela participação.
4.2.5
Resultados do questionário
Na página de resultados será exibido as respostas do questionário. Figura 19: Resultados de um questionário.
Como podemos ver na Figura 19, a primeira informação exibida do questionário em questão é quantos destinatários (Recipients) existem, esse número varia de acordo com o arquivo CSV utilizado no cadastro, logo abaixo a quantidade de respostas (Answered) que foram obtidas. Após essa informação são listadas as questões e suas respostas no formato "email do destinatário | resposta".
Aqui é possível baixar um arquivo no formato CSV com as respostas através do botão CSV.
4.2.6
Convidando colaboradores
Aqui é possível convidar colaboradores pra administrar o questionário, um colaborador tem todas as permissões que o criador com exceção de convidar novos colaboradores, enviar os emails e apagar o questionário.
Figura 20: Convidando colaboradores: Exemplo.
4.2.7
Limitações da Ferramenta
Como citado anteriormente, a aplicação ainda possui algumas limitações em suas funcionalidades.
A respeito dos tipos de questões, apenas dois tipos de questões foram implementadas até a data em que este documento foi redigido, enquanto outras ferramentas chegam a ter mais de dez tipos de questões.
Além disso, a aplicação também não permite criação de múltiplos fluxos no questio-nário (caso resposta da questão ’X’ seja ’a’, pule para página ’B’).
5
Estudos de Caso
Após o desenvolvimento e implantação, a ferramenta foi utilizada pelo professor en-volvido e seu código foi importado para outras duas ferramentas comerciais. Este Capítulo descreve tais estudos.
5.1
Observação do uso da Ferramenta
Para testarmos a funcionalidade real da ferramenta, foi feito um teste inicial apenas para envio de email. Nesse teste, elaboramos um planilha (arquivo CSV) contendo infor-mações sobre alguns usuários do Github. Esses usuários foram amostras de uma pesquisa realizada pelo Prof. Fernando Marques, em que foram minerados dados de usuários que possuíam repositórios relacionados ao desenvolvimento de aplicativos android.
Na planilha elaborada, tinha-se o nome, email, e título dos repositórios dos usuários selecionados. Com essas informações, pudemos enviar e-mails individuais para cada usuá-rio, em que no texto do email apresentávamos informações específicas do usuáusuá-rio, que para este caso seria o nome e o repositório pertencente a ele. Além disso, foi enviado um link de um questionário elaborado com o Google Forms, mas as perguntas foram as mesmas para todos os usuários.
Apresentando essas informações aos usuários, mostramos que eles não foram escolhidos de forma aleatória para uma pesquisa, e sim foram pré-selecionados.
Figura 21: Template de email do primeiro uso da ferramenta.
Na Figura 21, podemos ver o template do email utilizado na distribuição desse ques-tionário.
Como resultado, foi obtido 10% de respostas dos questionários. Um resultado consi-derado bom, levando-se em conta que não se sabe quantos dos participantes utilizam o email associado a sua conta no Github.
5.2
Importação do Código
A funcionalidade de pesquisas não foi testada através do sistema Custom Survey, mas sim através de outros softwares desenvolvidos em Rails, nos quais o código da ferramenta foi importado.
Durante o processo de desenvolvimento da ferramenta Custom Survey, foram desenvol-vidas duas ferramentas comercias, Portal Brasil Junior1 e Rheco.me2, ambos necessitavam
da funcionalidade de aplicação de questionários internos, com os usuários do sistema. Dessa forma foi importado do Custom Survey as classes necessárias para executar tais surveys.
5.2.1
Portal Brasil Junior
O Portal Brasil Júnior é o portal que centraliza informações das Empresas Juniores (EJ) de todo o país, nele estão automatizados diversos serviços que a Brasil Junior provê para suas EJs.
Durante o processo de elicitação de requisitos dessa ferramenta foi identificada a neces-sidade de aplicar questionários dentro da ferramenta. Então reutilizou-se o código referente as funcionalidades de gerenciamento de questionários elaborado para o Custom Survey.
Como dito anteriormente todas as regras de negocio do sistema estão encapsuladas na camada de modelo, dessa forma seu código pode ser facilmente importado em uma segunda ferramenta e desenvolvida no com o mesmo framework.
1
https://brasiljunior.org.br
2
Figura 22: Classes Importadas.
Na Figura 22 podemos ver as classes importadas. Durante o processo de testes diversos errors foram identificados e corrigidos.
Após a importação do código na ferramenta comercial, todos as refatorações, novas funcionalidades e correção de erros detectados na gerencia e execução dos questionários foram implementados também no Custom Survey.
Figura 23: Importação de código: Portal Brasil Júnior.
Por se tratar de outra ferramenta o layout de criação dos questionários foi refeito, para se adequar ao padrão da ferramenta, como podemos ver na Figura 23.
5.2.2
Rheco.me
A ferramenta Rheco.me trata-se de uma ferramenta para indicação de funcionários, onde cada empresa pode criar uma vaga e receber indicações para essa vaga de funcionários da empresa. Para executar essa indicação o funcionário deve preencher um questionário. Foi identificada a necessidade de customização desses questionários por vaga, para suprir tal necessidade foi importada as funcionalidades de gerenciamento de questionários do Custom Survey.
Também foi identificada a necessidade de customização de emails automáticos dispa-rados pela ferramenta, logo foi importado as funcionalidades de emails customizados do Custom Survey, porém como os emails nessa ferramenta não são associados aos questio-nários foi necessário uma adaptação no código.
Figura 25: Importação de código: Rheco.me - Emails.
Essa importação ocorreu de forma mais estável, devido ao código dos questionários e emails já estarem testados em usos e reutilizações anteriores.
6
Considerações Finais
Ao longo do desenvolvimento desse estudo, foi proposta a elaboração de uma ferra-menta que oferecesse suporte a gestão de questionários contextualizados. Visou-se observar se a ferramenta de fato oferecia tal suporte, o que poderia ser melhorado nela e potenciais casos de uso segundo os usuários da ferramenta ou derivados da mesma.
A necessidade de informar o contexto do questionário ao destinatário deixam claro a demanda da ferramenta ou de suas funcionalidades.
Após sua implementação, se constatou que a ferramenta provê contextualização nos questionários, através da inserção de informação dinâmica associada ao destinatário. A ferramenta foi utilizada de forma direta e indireta, e se constatou que a contextualização de perguntas em ambientes controlados é um necessidade real do mercado.
Futuros usos da ferramenta ou de seu código, podem expandir suas funcionalidades, tanto em ralação a diversidade de questões, quanto de possibilidades de customização de fluxos de resposta.
Referências
CAMARGO, L. S. A.; FAZANI, A. J. Explorando o design participativo como prática de desenvolvimento de sistemas de informação. Revista de Ciência da Informação e Documentação, São Paulo, v. 5, p. 138–150, 2014.
CHAGAS, A. T. R. O questionário na pesquisa científica. São Paulo: [s.n.], 2000. Administração On Line http://www.fecap.br/adm_online/art11/anival.htm. Acessado em: 01/11/2017.
FONSECA, J. J. S. Metodologia da pesquisa científica. Fortaleza, UEC, 2002.
FREITAS, H. et al. O método de pesquisa survey. Revista de Administração., São Paulo, v. 25, p. 105–112, 2000.
MORAIS, D.; GOMES, T.; PERES, F. Desenvolvimento de jogos educacionais pelo usuário final: Uma abordagem além do design participativo. In: Proceedings of the 11th Brazilian Symposium on Human Factors in Computing Systems. Cuiaba, Brazil: ACM, 2012. p. 161–164.
NIELSEN, J. Participatory Design: Principles and Practices. 1st. ed. [S.l.]: Morgan Kaufmann, 1993.
PARASURAMAN, A. Marketing Research. 2nd. ed. [S.l.]: Addison-Wesley, 1991.
ROGERS, Y.; SHARP, H.; PREECE, J. Interaction Design - Beyond human-computer interaction. 1st. ed. [S.l.]: John Wiley & Sons, 2002.
ROSEMBERG, C. et al. Prototipação de software e design participativo: uma experiência do atlântico. In: Proceedings of the 11th Brazilian Symposium on Human Factors in Computing Systems. Porto alegre, RS: ACM, 2008. p. 312–315.
SANTOS, A. R. Metodologia científica: a construção do conhecimento. DP&A, Rio de Janeiro, 1999.
SCHULER, D.; NAMIOKA, A. Participatory Design: Principles and Practices. 1st. ed. [S.l.]: CRC Press, 1993.
SELLTIZ, C. e. a. Métodos de pesquisa nas relações sociais. EPU, São Paulo, 1974. SILVEIRA, D. T.; CóRDOVA, F. P. Métodos de Pesquisa. 1st. ed. [S.l.]: UFRGS Editora, 2009. 31–42 p.
