UNIVERSIDADE FEDERAL DO RIO DE JANEIROINSTITUTO DE MATEMÁTICA

CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

LEANDRO C. LEITERENAN H. BARBIERI

Motiva: uma ferramenta para incentivar o aprendizado fora de aula

RIO DE JANEIRO2019

LEANDRO C. LEITERENAN H. BARBIERI

Motiva: uma ferramenta para incentivar o aprendizado fora de aula

Trabalho de conclusão de curso de graduaçãoapresentado ao Departamento de Ciência daComputação da Universidade Federal do Riode Janeiro como parte dos requisitos para ob-tenção do grau de Bacharel em Ciência daComputação.

Orientador: Prof. Vinícius Gusmão Pereira de Sá

RIO DE JANEIRO2019

Leite, Leandro Carneiro

L533m Motiva: uma ferramenta para incentivar o aprendizado fora de

aula / Leandro Carneiro Leite, Renan Hozumi Barbieri. – 2019.

50 f.

Orientador: Vinícius Gusmão Pereira de Sá.

Trabalho de Conclusão de Curso (Bacharelado em Ciência da

Computação) - Universidade Federal do Rio de Janeiro, Instituto de

Matemática, Bacharel em Ciência da Computação, 2019.

1. Sistema. 2. Colaboração. 3. Comunicação. 4. Tempo real. 5.

Estudo. 6. Motivação. I. Barbieri, Renan Hozumi. II. Sá, Vinícius

Gusmão Pereira (Orient.). III. Universidade Federal do Rio de

Janeiro, Instituto de Matemática. IV. Título.

RESUMO

Este trabalho é um sistema – uma rede social – onde um usuário pode escrever, editar,gerenciar e publicar conteúdo para que os demais usuários possam interagir lendo e co-mentando. Criado sob a investigação de pontos de melhoria no curso de Bachareladoem Ciências da Computação da Universidade Federal do Rio de Janeiro e de acordo comtécnicas de gerência de desenvolvimento e de validação de ideias, seu objetivo principalé motivar o compartilhamento de conhecimento dentro do mesmo com a finalidade deampliar a capacidade de todos, utilizando ferramentas motivacionais como gamificaçãoe facilitadores como a comunicação em tempo real. Com esta publicação, espera-se queos interessados possam compreender melhor a ideia e implementar a proposta como umanova forma de comunicação e evolução para discentes e também para docentes.

Palavras-chave: sistema. colaboração. comunicação. tempo real. estudo. motivação.

ABSTRACT

Motiva is a system – as a social network – where a user can write, edit, manage, andpublish content so the other users can interact reading and commenting on those publica-tions. Created with a study about improvement points we could apply on the ComputerScience Bachelor’s Degree of the University of Rio de Janeiro and accordingly to man-agement techniques of software development and hypotesis validation, its main goal is touse motivational tools like gamification and facilitators like real time communication tomotivate the knowledgement sharing so everyone who’s on the system can improve theirskills. It’s expected that with this publishing the interested ones can understand betterthe idea of the system and be able to implement the solution as a new communicationand evolution way, both for students and professors.

Keywords: system. colaboration. communication. realtime. study. motivation.

LISTA DE ILUSTRAÇÕES

Figura 1 – Tela principal do Motiva . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figura 2 – Perfil de um usuário com suas conquistas e nível . . . . . . . . . . . . . 15Figura 3 – Retorno de uma busca por tópicos . . . . . . . . . . . . . . . . . . . . 16Figura 4 – Tela de criação de postagem . . . . . . . . . . . . . . . . . . . . . . . . 17Figura 5 – Quadro de validação (Lean Startup Machine, 2014) . . . . . . . . . . . 20Figura 6 – Diagrama de visão do produto (SUTHERLAND, 2016, p. I) . . . . . . 23Figura 7 – Representação de como funciona um VCS centralizado (CHACON,

2010, p. I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figura 8 – Representação de como funciona um VCS distribuído (CHACON, 2010,

p. I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figura 9 – Representação em camadas da arquitetura clean (MARTIN, 2017, p. I) 27Figura 10 – Medalhas de recompensa do MercadoLivre . . . . . . . . . . . . . . . . 35Figura 11 – Resultado do questionário - período dos entrevistados . . . . . . . . . . 37Figura 12 – Resultado do questionário - complemento de estudo fora da classe . . . 37Figura 13 – Resultado do questionário - suficiência dos conteúdos apresentados em

sala de aula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figura 14 – Resultado do questionário - aprendizado com os colegas do curso . . . 38Figura 15 – Resultado do questionário - interesse em compartilhar conhecimento . . 39Figura 16 – Resultado do questionário - material gerado durante estudo . . . . . . 39Figura 17 – Arquitetura de WebSockets do Motiva . . . . . . . . . . . . . . . . . . 42

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 Contribuição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Modelos atuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2.1 Moodle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.2 Grupo de Redes Sociais . . . . . . . . . . . . . . . . . . . . . . . . 111.2.3 Dontpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.4 Grupo de Mensageiro Instantâneo . . . . . . . . . . . . . . . . . 121.3 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 O SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1 Cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Área do usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Níveis e conquistas . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Realizando uma busca . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 Escrevendo uma postagem . . . . . . . . . . . . . . . . . . . . . . 16

2.6 Interagindo com uma postagem . . . . . . . . . . . . . . . . . . 16

2.7 Sugerindo um tópico de interesse . . . . . . . . . . . . . . . . . 17

3 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . 193.1 Validação da ideia . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Validation Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Product Backlog e Product Owner . . . . . . . . . . . . . . . . . 223.2.2 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 Sistema de controle de versão . . . . . . . . . . . . . . . . . . 23

3.3.1 Sistemas centralizados . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.2 Sistemas distribuídos . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4 Clean Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4.1 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4.2 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.3 Adaptadores de Interface . . . . . . . . . . . . . . . . . . . . . . . 283.4.4 Frameworks e Drivers . . . . . . . . . . . . . . . . . . . . . . . . . 283.5 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.1 REST aplicado ao HTTP . . . . . . . . . . . . . . . . . . . . . . . 293.5.1.1 REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6.1 Contexto histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6.2 Long polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.6.3 Surgimento do WebSocket . . . . . . . . . . . . . . . . . . . . . . 313.6.4 Como funciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.7 Gamificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.7.1 Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7.2 Motivações da Gamificação . . . . . . . . . . . . . . . . . . . . . . 323.7.2.1 Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7.2.2 Empoderamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.2.3 Influência Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.2.4 Imprevisibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.2.5 Evasão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.2.6 Escassez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.2.7 Sentimento de Posse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.2.8 Realização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.7.3 Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.7.4 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 IMPLEMENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . 364.1 Validação das premissas . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Desenvolvimento da Plataforma . . . . . . . . . . . . . . . . . 40

4.2.1 Visualização dos Dados . . . . . . . . . . . . . . . . . . . . . . . . 404.2.2 Armazenamento dos Dados . . . . . . . . . . . . . . . . . . . . . . 414.2.3 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.4 Integração das Tecnologias . . . . . . . . . . . . . . . . . . . . . . 434.3 Gamificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4 Gerenciamento do desenvolvimento . . . . . . . . . . . . . . . 44

4.4.1 Implementação do Scrum . . . . . . . . . . . . . . . . . . . . . . . 444.4.1.1 As sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4.1.2 O Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . 475.1 Sistemas de Recomendação . . . . . . . . . . . . . . . . . . . . . 47

5.2 Aplicação Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.4 Gamificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.5 Análise de Redes Sociais . . . . . . . . . . . . . . . . . . . . . . . 48

6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

9

1 INTRODUÇÃO

Durante o curso de uma disciplina optativa chamada Tópicos Especiais em Programa-ção, várias discussões foram geradas em sala de aula, diversos tópicos interessantes foramabordados, inúmeras particularidades de algoritmos foram apresentadas. Aquele tipo deconteúdo e aula poderia motivar qualquer aluno que não estivesse no auge da sua gradua-ção. O inconveniente, não apenas nessa disciplina, é que todo aquele ambiente era restritoà sala de aula. Nenhuma discussão era gerada durante qualquer tempo extra classe, poucomaterial de estudo era exposto por conta do estilo da aula. Seria muito interessante, nãosó para os alunos inscritos, também para os possíveis futuros ingressantes nas disciplinas,ter contato com o maior volume possível de conteúdo gerado nas salas de aula.

Muitas vezes o próprio professor não tem disponibilidade para gerar conteúdo e pre-fere, com razão, se dedicar à excelência na hora de ensinar um determinado assunto. Asala de aula é um ambiente colaborativo, e esse comportamento deveria ser estendido aosmomentos pós classe, afinal os encontros presenciais são apenas uma pequena parte doaprendizado. Nesse caso, os alunos também são responsáveis por entender e gerar mate-riais de estudo, e os que o fazem, sempre são lembrados e viram uma referência em salade aula.

Mesmo que a motivação seja um fator pessoal, uma comunidade de estudantes podeinfluenciar positivamente nesse aspecto. É muito comum ver o aumento de desempenhode um aluno, ou até mesmo sua recuperação durante um período letivo, quando se junta aoutros para estudar. Essa prática é constantemente influenciada pelos professores, inclu-sive utilizando canais oficiais de comunicação das disciplinas, mas raramente é executadade forma eficiente e duradoura, principalmente por conta da escolha da ferramenta degerenciamento de conteúdo e comunicação.

Dentro do cenário apresentado e com uma certa semelhança às salas de aulas e seusmomentos cooperativos, a proposta é apresentar o Motiva, um sistema colaborativo eorganizado que facilita a troca de conhecimento e gerenciamento de conteúdo, podendoser utilizado por professores e alunos independentemente de disciplinas, períodos, temas,experiência, horários disponíveis, entre outros. Os objetivos principais desse modelo pro-posto são motivar os alunos e melhorar não só a interação no ambiente acadêmico, mastambém o seu nível por conta do desempenho dos discentes e da colaboração extra classedos docentes.

1.1 CONTRIBUIÇÃO

Este projeto visa contribuir com a solução dos seguintes problemas:

• Falta de discussões de estudos extra classe

10

O tempo em sala de aula é limitado e muitas das vezes alguns bons debates sãointerrompidos para que o fluxo de ensino siga em frente. As discussões que ocorrem– quando ocorrem – após as aulas são, muitas das vezes, em grupos fechados erestritos. Seria mais benéfico que também pudessem participar todos os alunosinteressados, podendo até os mais experientes no tema discutido contribuir.

• Materiais de estudo desatualizados

Muitos materiais de estudo e conteúdo de disciplina estão desatualizados, sem res-postas ou possuem pequenos erros que não são ajustados período após período. Como material em um sistema colaborativo, todos podem apontar, discutir, encontrarsoluções de problemas e corrigir eventuais erros encontrados nos materiais.

• Desinteresse e desmotivação

Existe um modelo clássico de aula, onde o professor introduz um conceito teóricoapós outro para, ao final, o aluno formar um raciocínio e começar a dominar umdeterminado tema. No entanto, o excesso de foco na teoria pode desmotivar umagrande parte de estudantes que possui a curiosidade natural de não apenas saberem que determinado momento e como implementar uma definição, como tambémcolocá-la em prática em forma de pequenos projetos. Esse cenário pode mudar comcomunidades ativas em vários assuntos, gerando discussões e motivando a união dealunos para colocar em prática diversos conceitos que foram aprendidos durante asaulas.

• Gerenciamento de conteúdo e comunicação nas ferramentas utilizadas atualmente

A maioria das disciplinas utiliza grupos em rede sociais e mensageiros instantâneoscomo canais de comunicação. Além de gerar distrações a todo instante, o conteúdopostado não é fácil de ser gerenciado, categorizado e encontrado. Quando várioscanais de comunicação são criados para uma mesma disciplina de acordo com períodoou professor, os problemas encontrados se agravam.

1.2 MODELOS ATUAIS

São utilizadas diversas maneiras para estabelecer a comunicação entre o professor deuma disciplina e os estudantes inscritos em um determinado período. Algumas soluçõessão mais formais que outras, como por exemplo a utilização do Moodle oficial do DCCquando comparamos com a criação de um grupo na rede social Facebook.

Independente do sistema adotado, é possível estabelecer o mínimo de comunicaçãonecessária para administrar uma turma durante um período, ou seja, aplicar trabalhos,marcar provas, enviar comunicados e afins. Porém quanto menor a comunicação, mais

11

unilateral ela é, e isso faz com que os alunos apenas enviem suas respostas aos comunicadosdos professores.

O problema não está apenas na escolha e na usabilidade de um determinado sistema,mas também na restrição e controle de acesso dos modelos. Muitas vezes essas dificuldadesdiminuem a interação entre a classe e contribuem para a falta de discussões sobre temaspertinentes.

1.2.1 Moodle

Alguns docentes optam pela utilização do Ambiente Virtual de Aprendizagem daUFRJ, que é um sistema cujo objetivo é organizar o material de classe, enviar e recebertarefas. O mesmo funciona bem para tais propósitos, embora não tenha uma interface deusuário amigável.

Neste modelo, predomina a comunicação unilateral do professor aos alunos, fator in-tensificado pela falta de uma interface para comunicação entre os alunos. Além disso, osconteúdos são disponibilizados de acordo com o período letivo e o professor da disciplina,o que significa que diversos grupos serão abertos para uma mesma disciplina, fator quecontribui para duplicação e fragmentação desnecessária de conteúdo.

Um outro fator problemático é a presença de senhas para ingressar nos cursos. Umaluno não inscrito na disciplina não consegue acessar seu material para consulta, sejaantes ou após o curso. Não existe motivo para essa barreira de segurança, uma vez quediscentes não possuem permissão para fazer qualquer alteração no material.

1.2.2 Grupo de Redes Sociais

A utilização de redes sociais, seja por parte de alunos ou professores, está presente nocotidiano, inserida no mesmo como certeza de acesso por pelo menos algumas vezes. Poresse motivo, a praticidade, pode parecer uma boa ideia gerenciar um grupo de disciplinaem sites como o Facebook.

O acesso a esse tipo de sistema está, geralmente, ligado a lazer e vida pessoal. Logoquando ingressamos, estamos sujeitos às mais diversas formas de distração. Postagensde amigos, notificações, mensagens privadas, notícias, todos esses fatores influenciam notempo que os estudantes vão se dedicar, e também conseguir o foco necessário, paraacessar o conteúdo da sua disciplina acadêmica nesse ambiente.

Utilizando o Facebook – rede social atualmente mais utilizada – como exemplo, épossível notar que seu gerenciamento de grupos não funciona de maneira satisfatória,principalmente quando um usuário está ingressado em diversos deles. Por esse motivo,a maioria dos usuários acaba saindo dos que estão menos ativos, geralmente grupo dedisciplinas que já cursaram, uma vez que os mesmos interferem na experiência do usuáriono momento de utilização dos seus grupos pessoais.

12

O gerenciamento de grupos também carece das funcionalidades necessárias para gerirconteúdo acadêmico. A ferramenta de busca do grupo não é efetiva para esses casos etorna bastante difícil a navegação se um usuário necessita buscar uma informação passada.Outro fator que prejudica bastante a interação entre os membros é a falta de possibilidadede enviar arquivos de documentos para uma postagem, sendo possível apenas enviar fotos.

1.2.3 Dontpad

O Dontpad ganha usuários devido à sua praticidade, que torna muito convidativo ofato de apenas digitar um complemento em uma URL para obter o seu próprio espaço.No entanto a sua falta de segurança e ausência de gerenciamento de acesso – ponto quenão recebeu atenção pela proposta básica do sistema – tornam inviáveis sua utilização emsala de aula.

Qualquer usuário pode editar, até mesmo apagar, qualquer conteúdo existente casoacesse seu endereço eletrônico. Isso ocasiona uma perda de confiabilidade na qualidadematerial e até mesmo no seu acesso, uma vez que o mesmo pode deixar de existir subita-mente.

Outro ponto importante é que o site não possui nenhuma maneira de interação entreseus usuários, ou seja, não é possível trocar mensagens, enviar arquivos ou fotos, criarum grupo, entre outras funcionalidades que os usuários estão acostumados a utilizar nocotidiano.

1.2.4 Grupo de Mensageiro Instantâneo

Este meio de comunicação pode parecer mais prático devido à comunicação direta emenor tempo de resposta entre os usuários, porém existem outros fatores que contribuempara a falta de sucesso na utilização desse tipo de ferramenta como gerenciador de gruposde estudos e conteúdos.

Mesmo que seja possível enviar documentos e fotos de maneira prática e rápida utili-zando telefones celulares e aplicativos como WhatsApp e Telegram, não existe nenhumamaneira de categorizar ou indexar essas mídias. Consequentemente, a busca posterior poresse tipo de material é muito prejudicada, podendo gerar até materiais duplicados e umaumento significativo nas mensagens do grupo.

O volume de mensagens também é um transtorno. Nem todos os alunos possuema mesma rotina e seus momentos dedicados aos estudos variam, por esse motivo não éincomum estudantes encontrarem um número enorme de mensagens não lidas devido auma discussão que não puderam participar. Nesse caso, é mais difícil endereçar umadúvida e até mesmo conseguir rever o que ocorreu previamente no grupo.

É possível destacar, do mesmo modo, a questão da privacidade. Em muitos mensagei-ros instantâneos, é necessário que o usuário informe o seu número de telefone e, por mais

13

que essa prática seja cada vez mais comum, esse dado continua sendo um canal direto decomunicação com uma pessoa. Transtornos podem ocorrer caso o contato de um membroseja utilizado de forma inapropriada.

1.3 PROPOSTA

O Motiva é um sistema colaborativo organizado para facilitar a troca de conhecimentoe gerenciamento de conteúdo em tempo real. A ideia é que qualquer pessoa inseridano contexto acadêmico, seja aluno ou professor, possa gerar uma postagem sobre umdeterminado tópico e os demais usuários possam interagir de acordo com seu interesse.

No sistema, é possível que um usuário escreva uma postagem, receba notificaçõessobre novas publicações relacionadas a algum tema relevante, favorite postagens, façacomentários e ainda sugira temas que não possui conhecimento, porém gostaria que umoutro participante conhecedor do assunto escreva sobre.

O principal objetivo do Motiva é fazer com que todos os usuários possam compartilharconhecimento e gerar discussões em tempo real de maneira organizada, eliminando todosos problemas dos outros meios de comunicação citados anteriormente.

14

2 O SISTEMA

2.1 CADASTRO

Na versão inicial do Motiva, é necessário que o usuário seja um estudante com DREe email, ou um Grupo de Extensão reconhecido, ambos do curso de Bacharelado emCiência da Computação na UFRJ, ou um docente com email no domínio ufrj.com.br. Éextremamente importante que não haja anonimato para o bom funcionamento do sistema.

O cadastro é feito manualmente e o usuário recebe uma senha inicial por email. Umavez que o mesmo faça login no sistema, ele é direcionado para a ação de alterar a senhainicial e escolher uma nova para sua maior segurança. É importante ressaltar que apenasusuários cadastrados podem acessar o sistema e todo seu conteúdo.

2.2 ÁREA DO USUÁRIO

A área do usuário é a tela principal do sistema, nela está contida elementos comoresumo do usuário, barra de busca, área de notificação e postagens mais recentes catego-rizadas.

Ao lado esquerdo está o resumo do usuário. Nele é possível que o usuário veja suafoto de perfil e seu nível atual, assim como quantos pontos faltam para que ele avance denível e suas principais conquistas exibidas. Também existe a possibilidade de acessar oseu perfil detalhado, suas postagens favoritas, configurações do sistema e fazer logout.

Figura 1 – Tela principal do Motiva

15

2.3 NÍVEIS E CONQUISTAS

Existem recompensas de acordo com a interação de quem usa o sistema. Conforme osusuários têm suas publicações lidas e curtidas ou leem e curtem as publicações de outros,são somados pontos de experiência que são acumulados e ditam o nível de um usuário,como por exemplo, os níveis Calouro e Profissional.

Para situações mais pontuais, existem as conquistas. Elas também possuem diferentesestágios – do mais básico ao avançado – e são dadas como recompensa quando alguémrealiza uma determinada ação ou um conjunto de ações. Por exemplo, quando um usuáriopublica uma postagem pela primeira vez, ele recebe a conquista "Primeira postagem",assim como quando um usuário mais avançado realiza sua quinquagésima postagem, elerecebe a conquista "Publicador imparável".

Figura 2 – Perfil de um usuário com suas conquistas e nível

2.4 REALIZANDO UMA BUSCA

É possível inserir um termo de busca na barra que fica no topo da tela principal.Quando o usuário confirma a busca, os resultados retornados são divididos e classificadosentre usuários, tópicos e postagens. A procura por usuário é feita de acordo com seunome e sobrenome, assim como as postagens são encontradas pelo seu título ou peloconteúdo do seu texto. No caso dos tópicos, quanto uma postagem é escrita, o autorpode especificar os assuntos referentes à publicação por meio de tags, como por exemplo"Grafos", "Android", "Cálculo", etc. Então, a procura por tópicos retorna postagens quesejam classificadas de acordo com o tópico relacionado.

16

Figura 3 – Retorno de uma busca por tópicos

2.5 ESCREVENDO UMA POSTAGEM

Primeiramente, o autor tem a opção de escolher uma imagem para ilustrar a suapostagem. Não é uma etapa obrigatória, porém é altamente recomendada, pois a imagemescolhida será exibida tanto nas buscas quanto nas páginas iniciais de outros usuários.

Em seguida, o autor deve escolher um título para sua postagem e categorizá-la deacordo as tags já existentes no sistema ou criando novas quando necessário. Essa necessi-dade ficará clara, pois quando o usuário começa a escrever uma tag, o sistema identifica edá sugestões para autocompletar a mesma e, se não aparecer nenhuma opção para o caso,é porque a tag ainda não existe e será criada no momento da postagem.

Finalmente, é possível que o autor utilize uma caixa de texto que facilita a formataçãoe a escrita do conteúdo da publicação. Com essa ferramenta, é possível formatar o textocom os principais estilos e, inclusive, escrever fórmulas matemáticas.

Quando todo o conteúdo estiver pronto, o botão "Postar" publicará a postagem e oautor será levado à sua postagem publicada. A tela de postagem exibe tudo o que foipreviamente inserido pelo autor, com o adicional da média de tempo que uma pessoalevará para ler toda aquela publicação. Esse cálculo é baseado no total de palavras eutiliza a média normal de uma pessoa adulta, que é de 160 palavras por minuto.

2.6 INTERAGINDO COM UMA POSTAGEM

Ao encontrar uma publicação, existe a possibilidade de que o usuário interaja dealgumas maneiras. A mais básica é a simples leitura do conteúdo da postagem, que

17

Figura 4 – Tela de criação de postagem

já garante pontos de experiência ao leitor e ao autor. Outras ações rápidas são as decurtir e favoritar uma publicação. A curtida incentiva e reconhece o trabalho do autor, efavoritar uma postagem ajuda a não perder de vista uma leitura e facilita sua releituraposteriormente.

É possível, e recomendado, que as publicações gerem discussões. Para que esse cenárioaconteça, toda postagem possui uma seção de comentários onde todos os usuários dosistema podem interagir. Basta escrever no campo ao final do post e confirmar para queo comentário seja publicado.

Vale interessante ressaltar que das interações citadas, as ações de curtir e comentargeram notificações em tempo real para o autor e para quem está acompanhando a posta-gem. No caso da curtida, somente o autor é notificado, pois ele é o mais interessado nessetipo de interação. Quando surge um novo comentário, não só o autor, mas todas as outraspessoas que curtiram ou comentaram na publicação também recebem uma notificação.

2.7 SUGERINDO UM TÓPICO DE INTERESSE

Uma vez que algum utilizador do sistema não encontre um tópico específico que gosta-ria de aprender mais sobre, é possível que ele sugira esse assunto a fim de motivar algumentendedor a fazer uma publicação. Para que não aconteça facilmente casos de sugestõesde tópicos duplicados, o sistema oferece uma busca ao usuário antes da sua sugestão.

As propostas de assuntos são ordenadas de acordo com o interesse dos usuários dosistema. Caso alguém concorde em querer ver alguma publicação sobre determinadoassunto sugerido, basta sinalizar com uma curtida. Também é possível alertar sugestões

18

duplicadas e sinalizar que uma sugestão já foi atendida indicando com qual postagem.

19

3 REFERENCIAL TEÓRICO

3.1 VALIDAÇÃO DA IDEIA

Encontrar um problema no dia-a-dia pode não ser uma tarefa tão difícil, mas encontraruma solução para ele pode ser algo mais complicado. É necessário saber se o problemaencontrado é realmente um problema sem solução e se há mais pessoas que enfrentameste problema. Mesmo que esses dois pontos se confirmem, ainda é necessário saber se asolução proposta realmente resolve o problema.

Neste momento precisa-se ter cautela. Há um enorme risco em se desenvolver a solução,que por vezes, possui custos de desenvolvimento altíssimos. Desta forma, desenvolver asolução por completo para depois validar se ela de fato resolve o problema se torna umaopção arriscada demais. Para contornar esta limitação, recorremos ao desenvolvimentode um menor produto com valor para o usuário, mais conhecido como MVP.

"Um produto mínimo viável (MVP) ajuda os empreendedores a começar o processo deaprendizagem o mais rápido possível"(RIES, 2011, p. I). Diferentemente do modelo mais"tradicional" de desenvolvimento, onde há um período de desenvolvimento até se chegara uma "perfeição" de produto e daí disponibilizar para o usuário, o MVP se baseia naideia de começar o processo de aprendizado do comportamento do usuário.

Desta forma, o MVP se diferencia de um protótipo ou teste de conceito. A ideia é quehaja o início da construção de um produto o mais rápido possível, para que se aprenda e semolde ao comportamento e necessidades dos usuários. O MVP é apenas a "maneira maisrápida de percorrer o ciclo construir-medir-aprender de feedback com o menor esforçopossível"(RIES, 2011, p. I)

O ciclo construir-medir-aprender é uma atividade fundamental quando se busca trans-formar uma ideia em um produto. O processo que envolve esse ciclo consiste em construirum MVP, medir como os usuários reagem a ele e, então, aprender se é o caso de mudarde ideia ou mantê-la.

3.1.1 Validation Board

Validar a ideia de acordo com uma reação do usuário é uma tarefa bastante subje-tiva. Para ajudar nessa etapa, foi desenvolvido pela Lean Startup Machine (Lean StartupMachine, 2014) um quadro, demonstrado na figura 5, que auxilia nesse processo de vali-dação. Ele é composto por alguns espaços que colaboram para a análise dos resultadosdo produto.

Um dos primeiros espaços ser preenchido é o "Customer Hypothesis" (Hipótese doCliente, tradução nossa)(Lean Startup Machine, 2014). Trata-se do momento em que se"cria" o perfil do usuário alvo do projeto, sempre pensando em uma pessoa em específico.

20

Figura 5 – Quadro de validação (Lean Startup Machine, 2014)

Deve-se, como exemplo, preencher o campo com "aluno do segundo período de ciência dacomputação" ao invés de "alunos de computação".

Após identificado o perfil de usuário, deve-se preencher o campo de "Problem Hypothe-sis" (Hipótese do Problema, tradução nossa)(Lean Startup Machine, 2014). Neste espaçodeve-se conjecturar um problema do usuário identificado que pode ser resolvido pela aideia inicial. Este problema "deve ser específico para a pessoa"(Lean Startup Machine,2014)(tradução nossa), e não um problema generalizado.

Com a definição dos principais elementos da hipótese de problema, deve-se pensar emcomo serão feitos os experimentos para validar a ideia. Esta etapa da validação da ideiarequer um reflexão sobre o que deve ser aprendido. Desta forma, inicia-se o processo depreenchimento do espaço "Core Assumptions" (Suposições Centrais, tradução nossa)(LeanStartup Machine, 2014).

Esse espaço é preenchido com possíveis cenários que acredita-se que sejam fatos. Destaforma, lista-se todas as premissas necessárias para a realização da ideia, priorizando-asde acordo com o risco e grau de incerteza que tal suposição tem para que a ideia sejavalidada.

Com os cenários priorizados, seleciona-se o que possui mais risco para a ideia. Estaseleção é necessária para que a ideia seja invalidada já no primeiro cenário caso este sejainvalidado. O cenário mais arriscado é então levado para o campo "Riskiest Assumption"

21

(suposição mais arriscada, tradução nossa)(Lean Startup Machine, 2014).Neste momento da validação, têm-se o usuário-alvo, o problema que ele possui e um

cenário que deve ser verificado se é real. Para que isso ocorra, precisa-se definir qual ométodo a ser utilizado para validar (ou invalidar) a ideia e qual será o critério de aceitaçãodo mesmo.

Para a definição de qual método será adotado para validar um cenário, deve-se pensarem uma maneira rápida para a colheita dos resultados. Pode ser aplicado aqui um ques-tionário para os usuários, assim como ser desenvolvido um protótipo da ideia ou entãose simular o problema. Definido o método a ser utilizado, é preciso se estabelecer umcritério mínimo de sucesso. Este critério irá definir de tal suposição é válida e se deve-seprosseguir com a ideia.

Com os resultados em mãos, é preciso tomar a decisão para o próximo passo. Caso osresultados tenham sido positivos, ou seja, a suposição seja confirmada, move-se o cenáriopara a área de resultados validados e uma nova suposição deve ser validada. Caso osresultados sejam negativos, move-se o cenário para a área de resultados invalidados earmazena-se de alguma forma os dados e aprendizados adquiridos na fase de validação.

No caso em que o resultado é negativo, parte-se para o "pivoteamento". Esta etapaconsiste em realizar uma nova análise do usuário e seu problema, assim como gerar novassuposições de cenários. Ao fim desta reanálise, todo o processo de validação é iniciado.

3.2 SCRUM

O gerenciamento de um projeto é tão importante quanto o desenvolvimento do mesmo.Uma má gerência pode resultar em um projeto inacabado ou em um projeto terminado,mas que não resolve o problema inicial e, por vezes, adiciona mais problemas a seremsolucionados.

Um software deve ser desenvolvido para as pessoas que irão utilizá-lo. Sendo assim,é necessário que se haja transparência quanto ao que está sendo desenvolvido. Nestecenário, uma metodologia de gerenciamento que deixe a evolução do desenvolvimento esuas dificuldades às claras se torna um aliado. E o Scrum é uma metodologia com essesprincípios.

"Na essência, o Scrum se baseia em uma ideia simples: quando começamos um projeto,por que não verificar a intervalos regulares se ele está indo no caminho certo e se aquilo érealmente o que as pessoas querem? E por que não se perguntar se é possível aprimorara forma como você está trabalhando para obter resultados melhores e mais rápidos, eo que poderia estar impedindo você de fazer isso? O nome disso é ciclo de ’inspeção eadaptação’."(SUTHERLAND, 2016, p. I)

22

3.2.1 Product Backlog e Product Owner

Na metodologia Scrum, durante a análise de requisitos de um software, as funciona-lidades mapeadas são tratadas como histórias. Nelas, personagens são "criados para quefique mais fácil identificar o que o software precisa satisfazer. Todas essas histórias são"guardadas" no Product Backlog.

O Product Backlog possui todas as histórias que um software inicialmente possui. Essalista de histórias serve como um alicerce para saber o que ainda falta a ser feito para osoftware ficar pronto. Esta lista é alterada ao longo do desenvolvimento, sendo históriasremovidas conforme são feitas ou quando se mostram não mais necesárias para o sistema,assim como novas histórias podem ser adicionadas caso haja uma necessidade ainda nãomapeada para o sistema. Com todos as histórias mapeadas, é necessário identificar qualo caminho que o desenvolvimento vai seguir. Neste momento, se faz necessária a figurado Product Owner.

O Product Owner (P.O.) é a pessoa que definirá o que a equipe fará, produzirá ourealizará. "Ela leva em consideração os riscos e as recompensas, o que é possível, oque pode ser feito e aquilo pelo que tem paixão"(SUTHERLAND, 2016, p. I). O P.O.deve priorizar as tarefas levando em consideração alguns aspectos de cada tarefa. Comomostrado na figura 6, a história a ser desenvolvida deve ser possível de implementar,vender e amar. Para se chegar nessa valoração, é necessário priorizar e estimar cadahistória listada no backlog. Com todas as histórias priorizadas, pode-se iniciar a sprint.

3.2.2 Sprint

Na metodologia Scrum, os objetivos são sequenciais e devem ser atingidos em umintervalo definido. Ao final de cada intervalo, deve-se haver uma parte do produto entregueque seja funcional. Desta forma, é possível mostrar o andamento do projeto a queminteressa e, se necessário, adaptar as novas funcionalidades às necessidades encontradas.Estes intervalos de inspeção do produto e adaptação são chamados de sprints.

No início de cada sprint acontece uma reunião, chamada de "Sprint Planning Meeting",para o planejamento da mesma. "A equipe determina a quantidade de trabalho queacredita ser capaz de realizar nas duas semanas seguintes. As tarefas são selecionadas apartir daquela lista de prioridades e anotadas em post-its, que são colados na parede. Aequipe resolve quantas tarefas será capaz de executar durante o sprint"(SUTHERLAND,2016, p. I). Esta lista de tarefas a serem realizadas em uma sprint é denominada "SprintBacklog".

Ao final de cada sprint ocorre a "Sprint Review Meeting", uma reunião onde os inte-grantes do grupo de desenvolvedores mostram o que conseguiram realizar dento da sprinte analisam quantas tarefas foram concluídas. Nesta etapa é estabelecido o ritmo de tra-balho da equipe. Ao final de algumas sprints já se torna possível identificar a velocidade

23

Figura 6 – Diagrama de visão do produto (SUTHERLAND, 2016, p. I)

média da equipe e, portanto, quantas tarefas a equipe consegue realizar em cada sprint.Após a apresentação e análise das tarefas realizadas e não realizadas, a equipe discute

como cada coisa foi feita na sprint. O intuito desta etapa do processo, chamada de "SprintRetrospective", é identificar melhores formas de se trabalhar para aumentar a velocidadedo time. É neste momento que se identifica o que atrapalhou o andamento da sprint quepassou e o que pode ser feito para remover os obstáculos que atrapalham o andamento doprojeto (SUTHERLAND, 2016, p. I).

A figura responsável por remover obstáculos encontrados nas reuniões diárias, as"Daily Scrum", e nas Sprint Retrospective é o "Scrum Master". Além desta responsabili-dade, a pessoa que assumir este papel deve assegurar que a equipe não se comprometa aentregar muito mais do que é capaz de realizar. Normalmente a figura de Scrum Masteré realizada por um gerente de projeto ou então um líder técnico, mas não há objeções emser qualquer membro da equipe.

3.3 SISTEMA DE CONTROLE DE VERSÃO

Ao longo do desenvolvimento de um software é essencial que se possa restrear todasas modificações que foram realizadas, podendo assim, identificar de modo mais rápido as

24

causas de um possível problema. Desta forma é necessário possuir um sistema de controlede versão (VCS) para que essa rastreabilidade possa ser possível. Os sistemas de controlede versão disponíveis nos dias atuais, como Git, SVN e Perforce, permitem que um arquivopossa voltar para um estado anterior e marcar um estado do projeto com uma versão,possibilitando assim que o projeto possa ser completamente revertido para outra versão.Eles permitem também a comparação entre os arquivos de diferentes versões.(CHACON,2010, p. 2)

A utilização de um VCS permite também que o o projeto possa ser desenvolvido pormais de um colaborador, de modo que a integração entre as funcionalidades desenvolvidaspor diferentes pessoas sejam realizadas sem perda de dados e evitando falhas humanas.

Para que o projeto seja compartilhado por mais de uma pessoa de forma assíncrona,sem a necessidade de que todos estejam com o código atualizado ao mesmo tempo, se faznecessário possuir um repositório conectado à internet, de modo que a qualquer momentoseja possível atualizar a versão do código. Partindo dessa necessidade, há dois formatosde sistema aplicados por VCS para suprí-la.

3.3.1 Sistemas centralizados

Em um VCS com sistema centralizado, há um servidor único para armazenamento detodo o código versionado e o número de clientes que conferem os arquivos desse servidor(CHACON, 2010, p. 3). Essa abordagem, ilustrada na Figura 7, permite que todos osque estão participando do projeto tenham, até certo ponto, conhecimento do andamentodo projeto. Além disso, administradores conseguem saber exatamente o que foi feito epor quem foi feita cada modificação do sistema.

Contudo, a adoção desse tipo de sistema cria uma forte dependência com o servidoronde o código está armazenado. Caso ocorra algum problema com esse servidor, desdeataques de hackers a problemas de hardware, e nenhum backup tenha sido realizado, todoo histórico do código desenvolvido corre o risco de ser perdido, sendo mantido apenasalguns estados do código nos computadores dos desenvolvedores - o que não garante queo último estado esteja salvo.

3.3.2 Sistemas distribuídos

Em sistemas distribuídos, essa forte dependência do servidor não existe. Ao invés depegar apenas o último estado do código, os clientes fazem uma cópia de todo o repositório,incluindo todo seu histórico. Desta forma, caso o servidor tenha algum problema, qualquercliente possui um backup de todo o repositório, podendo assim recuperar o estado doprojeto (CHACON, 2010, p. 4). Podemos representar o funcionamento deste sistemacomo na Figura 8

25

Figura 7 – Representação de como funciona um VCS centralizado (CHACON, 2010, p. I)

3.4 CLEAN ARCHITECTURE

No processo de construção de um software, é comum encontrarmos algumas mudançasde escopo enquanto o software está sendo construído. Desta forma, se faz necessário sercapaz de construir um sistema em que se possa realizar as modificações sem estas tenhamum grande impacto sob o que já foi construído. Uma forma de se atingir esse resultado épensar em uma arquitetura de software que permita essas modificações.

Segundo Robert Cecil Martin, idealizador do Clean Architecture, "Quando um soft-ware é feito corretamente, ele necessita de uma fração dos recursos humanos para criare manter. Mudanças são simples e rápidas. Defeitos são poucos e ocorrem com poucafrequência. O esforço é minimizado, enquanto que a funcionalidade e flexibilidade sãomaximizadas."(MARTIN, 2017, p. I)(tradução nossa). Partindo desta afirmação, tem-secomo objetivo encontrar uma arquitetura que seja capaz de fornecer todas estas particu-laridades.

Existem hoje vários modelos de arquitetura que são amplamente usados pelos desen-volvedores para a construção de um software, tais como MVC (Model View Controller),MVVM (Model View ViewModel), EDA (Event-driven Architecture), entre outros. To-dos eles são recomendados para resolver alguns problemas específicos, mas nem sempreestão aptos a resolver outros problemas enfrentados na construção de um software robusto

26

Figura 8 – Representação de como funciona um VCS distribuído (CHACON, 2010, p. I)

como o Motiva.A proposta do Clean Architecture é fornecer uma solução em arquitetura que sirva

para, se não todos, quase todos os problemas hoje existentes. Ela tem como objetivo aseparação de responsabilidades entre as camadas e objetos dentro do projeto.

A separação de responsabilidades que permite modularizar e e tornar cada camada

27

independente entre si. Essas duas características são bastante importantes quando sequer criar um sistema que seja escalável e que possua uma manutenção de baixo custo.

Havendo camadas independentes entre si, pode-se verificar que o sistema é: indepen-dente de framework, de interface de usuário, de banco de dados e de agentes externos.Todas estas características permitem que haja uma troca - de banco de dados, por exemplo- sem que afete o funcionamento principal do software.

Desta forma, Robert Cecil Martin identificou as seguintes camadas de um software:Entidades, Casos de Uso, Adaptadores de Interface e Frameworks e Drivers (MARTIN,2017, p. I), conforme a figura 9. Todas estas independentes entre si, de modo que nenhumade fato sabe como a outra está implementada.

Figura 9 – Representação em camadas da arquitetura clean (MARTIN, 2017, p. I)

3.4.1 Entidades

Na camada de entidade estão inseridas as regras para negócio no qual o softwareestá sendo desenvolvido. São todas as particularidades que fazem ou salvam o dinheiroenvolvido no negócio da empresa. "Uma entidade pode ser um objeto com métodosou pode ser um conjunto de estruturas de dados e funções. Não importa o tamanho,

28

desde que as entidades possam ser usadas por diferentes aplicações."(MARTIN, 2017, p.I)(tradução nossa)

Nesta camada, não é esperado que hajam modificações caso a forma de se navegar emum site, por exemplo, seja modificada. Se não houver nenhuma modificação operacional,as entidades não devem ser alteradas.

3.4.2 Casos de Uso

Nesta camada estão inseridas as regras de negócio específicas do software. Essas regrasnão devem ser utilizadas em um ambiente onde não haja a automação do processo. Sãoregras que só fazem sentido no contexto do software.

"Um caso de uso é a descrição da forma como um sistema automatizado é usado. Elaespecifica a entrada a ser fornecida pelo usuário e o passos do processo envolvido paraproduzir uma saída"(MARTIN, 2017, p. I)(tradução nossa)

Sendo assim, não é esperado que uma modificação nesta camada afete as entidadesdo software. Assim como não é esperado que esta camada seja afetada por mudançasno endereço da base de dados, assim como a tecnologia utilizada para armazenagem dosdados ou qualquer outra modificação na interface do software. A camada de Casos deUso é isolada destes tipos de modificações.

3.4.3 Adaptadores de Interface

Nesta camada é realizada a conversão dos dados utilizados nas camadas de "casos deuso" e "entidade" para o formato mais adequado para agentes externos, como bancosde dados ou interfaces de usuário. Todos os componentes que estejam na camada de"entidade" ou "casos de uso" não devem saber nada sobre qual a tecnologia de banco dedados está sendo utilizada, ou então qual arquitetura de interface de usuário foi utilizada.

Também há necessidade nesta camada de haver um outro adaptador de dados, queconverte os dados utilizados nos agentes externos para os dados utilizados internamentena aplicação (i.e. casos de uso e entidades).

3.4.4 Frameworks e Drivers

Esta camada é a camada mais externa de toda a arquitetura. É nela que são realizadasas conexões com os bancos de dados, são criadas as telas para visualização dos dados, etc.Normalmente, a maior parte do código escrito nesta camada tem o objetivo de se conectarcom uma fonte de dados.

29

3.5 REST

Em um sistema onde a interação entre os usuários é a principal funcionalidade, sefaz necessário estar bem atento à forma como que as informações são trocadas. Escolheruma solução que esteja embutida dentro do software atual pode não ser uma boa escolha.Deve-se escolher uma arquitetura onde a troca de informações independa da origem dasolicitação dos dados.

Para que seja possível recuperar os dados independentemente da origem, é necessárioutilizar o conceito de separação de responsabilidades. Como já abordado, a separação deresponsabilidades permite modularizar as partes do software. Segundo Roy Thomas Fiel-ding, "ao separar as preocupações da interface do usuário do preocupações de armazena-mento de dados, melhoramos a portabilidade da interface do usuário através de múltiplasplataformas e a escalabilidade, simplificando os componentes de servidor"(FIELDING,2000, p. 78)(tradução nossa).

Buscando a separação de responsabilidades, pode-se utilizar um serviço remoto deacesso aos dados do sistema, deixando o cliente responsável apenas pela exibição dosdados e o servidor pela criação, atualização, recuperação de remoção dos dados. Dentreas diversas arquiteturas existentes, que se permite estabelecer essa conexão entre cliente-servidor, há uma denominada "Representational State Transfer" (REST).

A REST é uma arquitetura baseada em rede derivada de várias outras arquiteturas domesmo estilo, combinado com restrições adicionais que definem uma interface de conexãouniforme. Tais restrições permitem que a arquitetura do sistema seja simplificada e avisibilidade das iterações seja melhorada (FIELDING, 2000, p. 81).

A arquitetura REST é definida por seis restrições: arquitetura cliente-servidor, quesatisfaz o conceito de separação de responsabilidades; sem estado, onde cada solicitaçãodo cliente para o servidor deve possuir toda a informação necessária para se entendera solicitação (FIELDING, 2000, p. 78); possibilidade de persistência, onde os dadosa serem respondidos devem possuir um indicativo para "armazenamento temporário"(cache) habilitado ou não; sistema em camadas, que permite a implementação de umaarquitetura hierárquica, onde cada camada não pode "enxergar" além da camada queele está interagindo; código sob demanda, uma restrição opcional em que os servidorespodem estender uma funcionalidade do cliente realizando a transferência e executando ocódigo em forma de applets ou scripts; interface uniforme, em que a implementação decada método é desacoplada do serviço que é fornecido.

3.5.1 REST aplicado ao HTTP

O HTTP é um protocolo da camada de aplicação da Web que define as propriedadesque cada mensagem trocada entre cliente e servidor deve possuir (KUROSE; ROSS, 2013,p. 72). Mesmo havendo algumas incompatibilidades (FIELDING, 2000, p. 129) entre

30

REST e HTTP, há algumas características que satisfazem a arquitetura, como o fato deser um protocolo sem estado, com possibilidade de reaproveitamento de resposta (cache)e uma interface uniforme. Desta forma, é possível utilizar o HTTP para implementar umaaplicação baseada em REST.

3.5.1.1 REST API

Uma aplicação API é um sistema desenvolvido para o servidor que auxilia outrossites ou clientes a realizar suas necessidades. "De modo geral, uma API (acrônimo paraApplication Programming Interfaces) expõe um conjunto de dados e funções para facilitariterações entre programas e permite que eles troquem informações."(MASSé, 2012, p.5)(tradução nossa). Uma aplicação REST API é, portanto, uma API que mantém aconformidade com a arquitetura REST.

Para manter a conformidade com o protocolo HTTP e modularizar as funções, umaREST API utiliza os métodos HTTP disponíveis para executar diferentes ações. De modogeral, para obter dados é utilizado o método GET, enquanto que para a criação de dadosaplica-se o método POST. Caso seja desejado alterar um dado recorre-se ao método PUTe, para deletar um dado o método DELETE é usado.

3.6 WEBSOCKET

3.6.1 Contexto histórico

O conceito de WebSocket nasceu da necessidade de construir uma comunicação emtempo real e bilateral de maneira efetiva. Esse tipo de comunicação já era um desejo antigono desenvolvimento web, no entanto, para obter tal resultado era necessário contornar aimplementação de comunicações que não tinham exatamente esse propósito.

A web foi construída baseada no protocolo HTTP, que foi originalmente projetado paraatender o modelo de requisição e resposta. No caso, simplesmente abrir uma conexão,descrever um conteúdo, receber uma resposta e fechar a conexão anteriormente aberta.Esse tipo de comunicação se mostrou efetivo durante muito tempo, pois na maior partedo tempo, os usuários necessitavam apenas carregar algumas páginas simples com textoe imagens e, em alguns casos, algum link direto para realizar o download de outro tipode arquivo específico.

Com o avanço do ambiente online, as páginas foram se tornando cada vez mais pró-ximas dos sistemas offlines, com diversas funcionalidades e uma maior necessidade deinteração com o usuário. Durante essa mudança, alguns sites se destacavam por levarinformação ao usuário sem que o mesmo tivesse que atualizar o seu navegador. Era o sur-gimento de uma comunicação onde o servidor poderia enviar respostas sem ter recebidouma requisição imediata.

31

3.6.2 Long polling

O long polling foi uma das técnicas mais utilizadas para tentar exercer uma comu-nicação bilateral. Seu princípio era criar uma conexão HTTP e deixá-la aberta até quenão fosse mais necessária. Essa técnica se baseou na percepção de que não era necessárioresponder uma requisição de imediato. A maioria das requisições HTTP são respondi-das pela mesma conexão que foi criada, no entanto, caso a conexão HTTP permaneçaaberta após uma requisição, o servidor pode respondê-la momentos depois, ou até mesmoo cliente enviar novas requisições sem contexto algum com as anteriores.

Basicamente, o cliente fazia uma requisição HTTP inicial e sua conexão permaneciaaberta, ou seja, essa requisição só seria respondida ao final de uma sessão com o servidor.Nesse período, com o canal de comunicação estabelecido, o servidor pode enviar respostassem ter um conteúdo de dados padrão, o que significa que o mesmo pode atualizar diversaspartes do site ou trazer informações diferentes para diferentes contexto mesmo sem teruma requisição comandando esses retornos.

3.6.3 Surgimento do WebSocket

Por mais que o long polling pareça uma solução viável, além de ser uma adaptaçãode uma tecnologia com outra finalidade, sua implementação era bastante complicadae também era necessário lidar com complicações inesperadas da conexão via protocoloHTTP.

Em 2007, Michael Carter escreveu um artigo introduzindo a ideia de WebSocketsà comunidade web e, em 2010, o Google Chrome foi o primeiro navegador a adotar eembarcar o suporte nativo à nova tecnologia que estava surgindo. Logo em seguida, em2011, a RFC 6455 (FETTE; MELNIKOV, 2011) que abordava o protocolo WebSocket foipublicada. Hoje em dia, todos os navegadores modernos suportam o protocolo e ele fazparte do desenvolvimento web.

3.6.4 Como funciona

O WebSocket faz parte da pilha de protocolos TCP/IP, especificamente como parteda camada de transporte. Inicialmente, existe um handshake - processo automático denegociação e estabelecimento de conexão entre duas partes - entre o cliente e o servidor,feito por uma requisição HTTP do tipo Upgrade pelo cliente. O cabeçalho desse tipode requisição muda o protocolo de comunicação, pois quando o servidor interpreta essecabeçalho, percebe a troca do tipo de comunicação TCP e reage deixando de utilizar oHTTP para utilizar o protocolo WebSocket nas próximas interações. Em caso de utilizaçãode conexão sem criptografia, a comunicação é feita através das porta 80 no esquema ws.Caso seja utilizada conexão criptografada, o esquema passa a ser o wss e a porta 443.

32

Estabelecida a conexão, a comunicação pode ser feita de maneira bilateral, ou seja,tanto o servidor quanto o cliente podem enviar mensagens independente do destinatárioestar esperando por uma resposta. É intuitivo imaginar como esse tipo de ação ocorre nolado do servidor, uma vez que o modelo cliente-servidor é algo bem difundido e imple-mentado, além do fato de que durante anos a internet funcionou apenas com os servidoresreagindo às requisições dos usuários. Porém, é importante ressaltar que a comunicação doservidor para o cliente é feita por via de mensagens com conteúdo de dados sem nenhumapré definição, ou seja, o cliente deve saber interpretá-los. O cliente reage às mensagens,enquanto a conexão estiver ativa, por meio de eventos que ocorrem quando uma mensagemé recebida.

O interessante é que como a conexão entre o servidor e o cliente para utilização deWebSockets é persistente, é possível enviar mensagens aos clientes destinatários de formasdiferentes. Por exemplo, no ato de conexão e handshaking, o servidor pode identificar ocliente de maneira única e persistir essa informação de maneiras diferentes, como porexemplo, a criação de listas como canais de comunicação. Dessa maneira, é possível queo servidor não só envie mensagens para um destinatário, mas também para um grupo dedestinatários de uma só vez, fazendo com que todos os que estão ativos e conectados nomomento recebam a mensagem em tempo real.

3.7 GAMIFICAÇÃO

3.7.1 Conceito

O termo gamificação vem do inglês gamification, que nada mais é do que utilizarmecânicas e características de jogos para engajar, motivar comportamentos e facilitar oaprendizado de pessoas em situações reais que, normalmente, não são relacionadas a jogos.A prática de gamificar tem como diferencial despertar um maior engajamento do públicoe facilitar a obtenção de medidas dos resultados das ações de um determinado grupo depessoas.

3.7.2 Motivações da Gamificação

Segundo o Framework Octalysis (CHOU, 2015), existem oito pontos principais quesão tidos como alicerce da gamificação, que fazem com que o jogador seja envolvidopelo jogo. Esses pontos são chamados Propósito, Empoderamento, Influência Social,Imprevisibilidade, Evasão, Escassez, Sentimento de Posse e Realização.

3.7.2.1 Propósito

É nesse ponto que o jogador acredita que faz parte de um bem maior, que foi oescolhido para realizar algo. O sintoma imediato desse sentimento é se dedicar horas para

33

cumprir determinada tarefa.

3.7.2.2 Empoderamento

Além de precisar de maneiras para expressar sua criatividade, as pessoas tambémnecessitam ver resultados imediatos das sua ações e constantemente responder a estímulos.É nesse ponto que o jogador é provocado e, quando bem sucedido, exibe seus resultadospara os demais.

3.7.2.3 Influência Social

O elemento social direciona e afeta diretamente a motivação do jogador. Quando umjogador percebe o quão bom um amigo é, ou nota algo extraordinário que ele possui,esse jogador fica motivado e é direcionado a superar seu amigo, seja por um sentimentocompetitivo ou por inveja.

3.7.2.4 Imprevisibilidade

Quando não sabemos o que está por vir, o que vai acontecer em um determinado mo-mento, nosso cérebro reage com engajamento e muitas vezes acabamos pensando demaissobre, despertando um sentimento de curiosidade constante. É por essa razão que muitosassistem filmes e leem livros.

3.7.2.5 Evasão

É o sentimento que se tem no caso de um jogador abandonar o jogo, onde todo o seuprogresso é perdido. Perder um trabalho em andamento, ou simplesmente reconhecer ofato de que tudo o que foi feito até o momento será em vão caso o jogo termine, faz comque um jogador não queira abandonar um jogo.

3.7.2.6 Escassez

A escassez faz com que um jogador busque um objetivo que está diretamente ligadoao seu desejo. Por exemplo, é comum que em jogos existam níveis iniciais em que ospersonagens não podem obter determinados itens valiosos. Isso faz com que os jogadoresdesejem tanto algo, que passam a focar em jogar até que consigam atingir esses objetivos

3.7.2.7 Sentimento de Posse

Quando um jogador tem a sensação de que possui bens em um jogo, ele vai lutar paraque sempre possa melhorar os seus bens e até acumular cada vez mais.

34

3.7.2.8 Realização

As sensações que mais laçam os jogadores são as de realizar progresso, desenvolverhabilidades, crescer e superar cada vez mais novos desafios. Esse pilar da gamificação,geralmente, é aplicado junto com o pilar de Empoderamento, que ajuda no reconhecimentode uma realização.

3.7.3 Aplicação

Primeiramente, o cenário e o problema a ser resolvido devem ser mapeados. É ne-cessário implementar a gamificação para solucionar um problema. É nessa etapa quemapeamos o comportamento do usuário com a finalidade de entender suas ações, neces-sidades, pensamentos e objetivos que visa alcançar.

Em seguida, de acordo com a solução do problema proposto, definimos a missão dojogo. A missão é a razão de existir do jogo, o objetivo principal da iniciativa de gamifica-ção. Mesmo que o jogo não possua um fim, é necessário estabelecer uma missão para queo desenvolvimento do jogo seja guiado e vá de encontro ao objetivo do jogador.

Com o cenário montado, devemos definir quem são os jogadores. É preciso conhecera motivação dos envolvidos com o jogo, tais como seus hábitos e suas característicascomportamentais, que vão definir a estratégia para o desenvolvimento do jogo.

Finalmente, desenvolva a mecânica do jogo. Ela é o núcleo do jogo. É nessa etapaque são definidas as variáveis e tudo que pode ser visto ou manipulado no jogo, comopor exemplo, personagens, placares, regras e atividades que o jogador deve concluir. Éimportantíssimo definir nesse processo a forma de pontuação, as conquistas e recompensas,que são a base de uma gamificação bem sucedida.

3.7.4 Exemplos

O conceito de gamificação pode ser aplicado em qualquer situação. Citaremos, aseguir, alguns exemplos de diferentes setores, com e sem fins lucrativos.

A rede de supermercados Pão de Açúcar criou uma iniciativa em que os clientes preci-sam juntar selos para trocar por brindes. A cada R$ 30 em compras, os clientes recebemselos para colar em uma cartela e, a partir de um certo número de selos, a cartela podeser trocada por diversos utensílios domésticos.

O site de e-commerce MercadoLivre passou a adotar elementos de gamificação nas suascompras. Um usuário recebe pontos, de acordo com o valor, ao efetivar uma compra eesses pontos são acumulados e, a medida que vão aumentando, geram diversas vantagenscomo descontos e fretes grátis para o usuário. Além de trabalhar com recompensas, osite também trabalha com reconhecimento por meio de medalhas para cada nível que umusuário vai avançando.

35

Figura 10 – Medalhas de recompensa do MercadoLivre

A aplicação de mapas Google Maps também utiliza reconhecimento e empoderamentopara aumentar a confiabilidade das recomendações dos lugares disponíveis nos seus mapas.Cada usuário recebe uma pontuação diferente por comentário, avaliação e postagem defotos de um local. Ao acumular pontos, o usuário exibe uma medalha no seu perfil e todosos outros usuários passam a reconhecê-lo como um guia local dependendo do seu nível.Foi dessa maneira que a Google engajou os usuários a comentar e escrever resenhas deestabelecimentos e localidades que já frequentaram.

36

4 IMPLEMENTAÇÃO

4.1 VALIDAÇÃO DAS PREMISSAS

Com base nas experiências pessoais dos autores, foram elaboradas algumas premissasque eram necessárias serem validadas para que o desenvolvimento do software fosse justi-ficado. Desta forma, para guiar tal validação, foi utilizado o validation board , processodescrito na seção 3.1.

Para iniciar o procedimento, foi necessário definir o perfil de usuário do sistema. Assim,chegou-se aos perfis "alunos de computação da UFRJ que buscam uma plataforma paradivulgar conhecimento", um perfil produtor, e "alunos de computação da UFRJ quebuscam uma plataforma para buscar conhecimento", um perfil consumidor.

No início da segunda etapa foi primeiramente escolhido o perfil consumidor, dado queeste foi considerado um perfil essencial para a validação do Motiva. Sendo assim, elaborou-se a seguinte hipótese de problema: "os alunos de computação buscam conteúdo fora dasaulas", motivada pela premissa de que os alunos buscam se aprofundar em conteúdos forada sala de aula, sendo em casa ou em seu deslocamento.

Definidas as hipóteses iniciais de cliente e problema, iniciou-se a etapa de experimen-tação. Para validar a hipótese de problema, foi elaborado um questionário a ser aplicadoa alguns alunos de diferentes períodos do curso de ciência da computação da UFRJ.

O questionário foi aplicado para 44 alunos ativos ou formados, buscando-se sempreuma variedade de períodos entre os entrevistados. Foi conseguido obter pelo menos umrepresentante de cada período, como ilustrado na figura 11, sendo os alunos que já estãoalém do 9º os mais representados nesse resultado. Foram realizados questionamentos quefossem possível extrair a informação de que "os alunos de computação buscam conteúdofora das aulas". Para considerar um resultado positivo, foram estabelecidas metas deresposta para cada pergunta. A pergunta "De que maneira você complementa os seusestudos?" invalidaria a ideia se a opção "não complemento os meus estudos" possuíssemais de 20% das respostas. Se esta situação ocorresse, seria considerado que os alunosnão buscam informação extra para seus estudos. Como mostrado na figura 12, apenas6,8% não complementam os estudos. Para a pergunta "os conteúdos apresentados em salade aula são suficientes para total aprendizado de um determinado assunto", foi definidoque se 40% das respostas fossem mais próximas da opção "discordo", ou seja, as opções1 e 2 de uma escala de 1 até 5, onde 5 é "concordo com a afirmação", se teria umavalidação de que há a necessidade de conteúdo fora de sala de aula. Como mostrado nafigura 13, 50% dos entrevistados responderam que discordam da afirmação apresentada.A última pergunta considerada necessária para validar a premissa foi "Procuro aprendercom os meus colegas de faculdade". Em uma escala de 1 até 5, onde 5 é "concordo

37

Figura 11 – Resultado do questionário - período dos entrevistados

Figura 12 – Resultado do questionário - complemento de estudo fora da classe

com a afirmação", definiu-se que se 50% das respostas fossem mais próximas da opção"concordo", ou seja, as opções 4 e 5, teria-se a premissa "os alunos de computação buscamconteúdo fora das aulas" validada. Na figura 14 está ilustrado o resultado da pesquisa,onde 68,2% marcaram as opções 4 ou 5, concordando com a afirmação. Com o perfilconsumidor validado, partiu-se para a validação do perfil produtor, definindo a hipótesede problema "os alunos de computação estão dispostos a escrever sobre um determinadoassunto", motivada pela premissa de que os alunos estão dispostos a ensinar sobre um

38

Figura 13 – Resultado do questionário - suficiência dos conteúdos apresentados em salade aula

Figura 14 – Resultado do questionário - aprendizado com os colegas do curso

assunto de seu interesse.Com as novas hipóteses de problema e cliente definidas, iniciou-se a etapa de experi-

mentação. Foi aplicado um questionário para os mesmos 44 alunos da pesquisa anterior,buscando entender o perfil produtor de conteúdo.

Com a afirmação "gosto de compartilhar meus conhecimentos", buscou-se validar aideia de que há alunos interessados em escrever conteúdo para os demais colegas. Foidefinido que se 30% das respostas concordassem com a afirmação, ou seja, as opções 4 e 5em uma escala de 1 até 5, onde 5 é "concordo com a afirmação", poderia-se avançar como desenvolvimento da plataforma. Como mostrado na figura 15, 77,3% dos entrevistadosresponderam que concordam da afirmação apresentada. Validada a premissa de que há

39

Figura 15 – Resultado do questionário - interesse em compartilhar conhecimento

produtores de conteúdo para a plataforma, buscou-se entender qual tipo de conteúdoseria gerado. Para tal entendimento, foi realizada a seguinte pergunta: "Que tipo dematerial é gerado durante os seus estudos?", com o objetivo de verificar a afirmação deque há conteúdo a ser publicado no Motiva. Em caso de 30% ou mais de respostas naopção "Não gero material durante meus estudos", tal premissa seria invalidada. Com oresultado de 11,4%, conforme figura 16, de respostas nesta opção, a premissa foi validada.Com 63,6% das respostas para a opção "resumos", pode-se ainda pensar na seguinte

Figura 16 – Resultado do questionário - material gerado durante estudo

hipótese de problema: "os alunos de computação que produzem resumos em seus estudosbuscam uma plataforma para armazenar o conteúdo gerado". Para validar esta hipótese,optou-se pelo desenvolvimento da plataforma Motiva e o acompanhamento do uso dela.

40

Tal validação não foi concluída pelo motivo de não ter havido um momento em que sepudesse testar o uso da plataforma.

4.2 DESENVOLVIMENTO DA PLATAFORMA

A decisão de qual o modelo de controle de versão a ser utilizado para o Motiva levouem consideração alguns aspectos da estruturação do projeto. Para que o projeto fosseportável para outras tecnologias, decidiu-se que haveria uma divisão entre as lógicas dearmazenamento e de visualização de dados.

Por conta dessa divisão de responsabilidades, foi necessário criar dois projetos paraserem gerenciados separadamente. Cada projeto possuiu suas particularidades ao longodo desenvolvimento, mas em ambos projetos foi adotado o sistema de controle de versãodistribuído Git, sendo utilizado os servidores da empresa GitHub como repositório deorigem.

A utilização dos serviços dessa empresa foi escolhida pelo fato de ser um dos maisutilizados na comunidade de desenvolvedores. Outro fator que também agregou paraessa escolha foi pelo fato de possibilitar uma colaboração mais ampla, não limitando odesenvolvimento do projeto apenas para algumas pessoas, podendo qualquer usuário doGitHub poder solicitar autorização para colaborar com o desenvolvimento do Motiva.

4.2.1 Visualização dos Dados

Antes de se iniciar o desenvolvimento do projeto de visualização dos dados, foi precisoescolher a tecnologia a ser utilizada. Tinha-se como objetivo desenvolver uma soluçãode construção rápida, onde fosse possível utilizar a plataforma independentemente dodispositivo.

Desta forma, optou-se por desenvolver uma solução para ser utilizada via navega-dor, presente nos sistemas operacionais mais comuns da atualidade. Com esta restrição,buscou-se um framework que fornecesse facilidades no desenvolvimento de elementos visu-ais e que tivesse um bom desempenho ao processar as informações a serem apresentadas.

Somando-se às tais características, o framework a ser escolhida deveria ter como baseuma linguagem já conhecida pelos autores deste trabalho, para que o tempo de desenvol-vimento não se prolongasse demasiadamente. Sendo assim, definiu-se que o frameworkdeveria ter como base a linguagem Javascript, ou suas variações, Python ou PHP.

Com todas as características e restrições definidas, buscou-se os frameworks comu-mente utilizadas pela comunidade de desenvolvedores. Dentre as soluções pesquisadas, aque mais agradou foi o framework Angular, que, além de possuir os requisitos já listados,é de fácil configuração e já havia sido amplamente utilizado por um dos autores.

41

4.2.2 Armazenamento dos Dados

Com o intuito de se deixar a separação de responsabilidade bem definida, optou-se porcriar um projeto para o armazenamento de dados completamente separado do projeto devisualização de dados. Desta forma, foi feita uma análise de requisitos técnicos específicapara as necessidades de armazenamento de dados.

O principal conceito do projeto de armazenamento dados é fornecer a armazenagemde dados e possibilitar o consumo destes dados. Tais funcionalidades devem ser indepen-dentes de qual a tecnologia a ser utilizada para acessar essa troca de informação. Esseconjunto de características está presente no conceito de uma REST API.

Sendo assim, a tecnologia a ser escolhida deveria apresentar afinidade com a arquite-tura REST. Somando-se a isso, deve possuir um bom desempenho para processos assín-cronos, ser de fácil implementação e configuração e, assim como na escolha da tecnologiapara o projeto de visualização, deve ser uma linguagem já conhecida dos autores destetrabalho.

Após uma pesquisa sobre quais os frameworks que poderiam se adequar aos requisitoslevantados, chegou-se ao framework Django. Mesmo sendo um framework simples, oDjango é capaz de ser bastante escalável, além fornecer ferramentas que evitam que osdesenvolvedores cometam falhas de segurança e ser bastante rápido nos processamentos.

Além de tais características, o Django é um framework que possui Python como lin-guagem base, linguagem previamente conhecida pelos autores, e é de fácil configuraçãoe implementação. Somando-se tudo o que foi levantado, o Django se tornou uma boaescolha para o desenvolvimento do projeto de armazenamento de dados.

4.2.3 WebSocket

O WebSocket foi implementado no Motiva com o objetivo de trazer ao usuário aexperiência de comunicação e interação em tempo real por meio de notificações, similaràs diversas redes sociais atuais. A comunicação entre o servidor e os usuários é feitaatravés de um canal que é estabelecido ao logar no sistema ou ao retornar com um loginpreviamente salvo. A arquitetura abaixo ilustra como está estruturado o anúncio demensagens na aplicação do sistema.

Quando um usuário realiza a operação de login – inserindo suas credenciais ou auto-maticamente – é criado um canal de comunicação bilateral onde o nome de usuário é o seuidentificador. Isso significa que uma vez que o cliente esteja ativo no sistema, ele poderáreceber e enviar mensagens utilizando WebSockets. Para que isso fosse possível a nível deimplementação, utilizamos a biblioteca Django Channel no backend e a biblioteca WS nofrontend.

Também é necessário persistir os canais de comunicação criados e gerenciar esses dadosde uma maneira performática. Para isso, utilizamos o Redis, que é um banco de dados não

42

Figura 17 – Arquitetura de WebSockets do Motiva

relacional (NoSQL) que armazena dados em estrutura de pares chave-valor em memória.Uma vez que o canal de comunicação é criado pelo Django Channel, seus identificadoressão armazenados no banco de dados do Redis.

Uma implementação mais simples é a ação de gostar de uma postagem. Quando umleitor clica no botão gostar, uma requisição HTTP é enviada com a ação de gostar. Quandoo banco de dados atualiza com sucesso a contagem de likes, uma mensagem é disparadapelo servidor para o autor da postagem através do canal de comunicação WebSocket comseu nome de usuário. Essa mensagem contém a ação de notificação, a descrição de que foirealizada uma ação de gostar e o nome do leitor que gostou da publicação. A bibliotecaWS se encarrega de receber essa mensagem e, através de um indicador de ações, perceberque é uma notificação e exibi-la para o usuário autor.

A ação de inserir um comentário em uma postagem é uma implementação mais abran-gente. A regra utilizada é a seguinte: o autor, todos os usuários que gostaram de umapublicação e todos os usuários que comentaram na mesma receberão uma notificação casoum comentário seja feito nessa postagem. Essa comunicação ocorre um pouco diferente daanterior. Uma vez que a postagem seja criada, um canal com a identificação da postagemé criado e seu autor é inscrito nesse canal, da mesma forma que posteriormente os leitores

43

que gostarem da publicação também serão inscritos no canal da publicação. Quando umusuário faz um comentário, caso ele ainda não tenha gostado da postagem do autor, eletambém é inscrito no canal de comunicação da publicação e sua ação de comentar anunciapara todos os participantes – exceto ele mesmo – o seu comentário.

Caso um usuário desconecte, ou seja, feche a sessão ativa no navegador com o sistema,seu canal é removido do Redis e nenhuma mensagem será enviada até que o cliente seconecte novamente. Esse gerenciamento é feito para que nenhuma comunicação seja feitade forma desnecessária, visando a melhor performance do sistema.

4.2.4 Integração das Tecnologias

Para que o sistema tivesse um progresso mais completo, onde em todas as entregashouvesse uma parte do sistema completa e usável, optou-se por desenvolver os projetos devisualização e armazenamento de dados simultaneamente. Com esta decisão, foi necessárioencontrar uma forma de padronizar a comunicação entre os projetos.

Como a relação entre os desenvolvedores era bem próxima, decidiu-se inicialmenteestabelecer uma comunicação informal para o alinhamento entre os desenvolvedores decomo a troca de informação entre os projetos deveria ocorrer. Nessa abordagem ocorreramalguns problemas, como mudança de parâmetros sem nenhum aviso, adição de parâmetrosdesnecessários assim como a remoção de outras propriedades que eram essenciais para ofuncionamento do sistema como um todo.

Desta forma, buscou-se uma forma um pouco mais formal e com processos de validaçãobem definidos para que se evitasse um retrabalho ou mal funcionamento do sistema.Dentre todas as possibilidades encontradas, chegou-se à conclusão de que era necessárioconseguir simular o sistema de armazenamento de dados, simulando não só os modelos dedados como também a comunicação com o projeto de visualização, utilizando a mesmaarquitetura REST API.

Durante o processo de tentar simular esse ambiente com um baixo custo de implemen-tação, foi identificada a plataforma online apiary. Nela é possível criar uma REST APIde modo simples, escrevendo apenas um documento de texto onde declara-se os serviçosdisponíveis e seus respectivos atributos de entrada e saída. Sendo assim, foi possível pa-dronizar os formatos de entrada e saída de dados em um único arquivo, disponível paratodos os desenvolvedores.

Resolvido o problema de padronização de troca de informação, ainda havia uma faltade comunicação de mudanças realizadas. Como resolução para este problema, ficou esta-belecido que para toda modificação deveria ser criada uma tarefa de validação associada aodesenvolvedor não responsável pela modificação. Desta forma, todos os desenvolvedoresenvolvidos no projeto ficam cientes de todas as modificações, assim como se responsabi-lizam pela coesão e coerência do sistema.

44

4.3 GAMIFICAÇÃO

A Gamificação foi implementada no Motiva com a missão de engajar os usuários eestabelecer uma competição saudável a fim de tornar o aprendizado e o compartilhamentode conhecimento mais divertido. A mecânica do jogo é composta por níveis e pontos deexperiência, além de recompensas que visam incentivar tanto a participação como autorde postagens, assim como também a leitura de postagens.

Todos os usuários – que serão tratados como jogadores – quando ingressam no sis-tema, começam no nível 0, que é chamado Pré-Calouro. Para subir de nível, é necessárioacumular pontos de experiência, que são dados como recompensa de acordo com deter-minadas ações de autor e leitor. Por exemplo, para obter pontos de experiência comoautor é necessário ou publicar uma postagem e ganhar pontos imediatamente, ou ganharpontos com curtidas em postagens publicadas. Como leitor, é possível obter pontos deexperiência lendo postagens.

Especificamente, quando uma postagem é publicada, o autor ganha dez pontos deexperiência. Para cada curtida em sua publicação, dois pontos de experiência. Comoleitor, vale ressaltar que cada texto possui um tempo médio de leitura e, caso o usuáriopasse mais da metade desse tempo lendo um artigo, um ponto de experiência é obtido.O objetivo é motivar não somente o compartilhamento de conhecimento, mas tambémincentivar o reconhecimento pelo esforço e incentivar a leitura de diversos temas visandoum conhecimento abrangente.

Em conjunto com os pontos de experiência, existem as recompensas de desafios, quevisam motivar ainda mais os jogadores e fazer com que os mesmos compitam entre si emelhorem seus trabalhos. Por exemplo, entre várias, existem recompensas para postagenscom mais de 100 curtidas e para leitores que conseguirem ler pelo menos um artigo pordia em uma semana. Esses tipos de recompensas incentivam a qualidade das publicaçõese o ato de criar uma rotina de estudos, afetando os autores e também os leitores.

A mecânica do jogo consiste em sempre incentivar a publicação de postagens, uma vezque os autores ganham mais pontos de experiência do que os leitores. O jogo propostopela Gamificação não possui fim, ou seja, não possui nível máximo e torna necessário quesempre existam novas postagens para que os jogadores consigam atingir níveis maiorestanto como autores e como leitores.

4.4 GERENCIAMENTO DO DESENVOLVIMENTO

4.4.1 Implementação do Scrum

O desenvolvimento do Motiva teve algumas características que tornaram o gerencia-mento do projeto uma tarefa distante do que é comumente encontrado no desenvolvimentode outros softwares. Desta forma, a aplicação do Scrum conforme a literatura não foi pos-

45

sível de ser realizada, sendo necessária algumas adaptações para que o projeto tivessecontinuidade.

4.4.1.1 As sprints

A principal adaptação, e possivelmente a de mais impacto sob a evolução do projeto,foi realizada no conceito de sprint. Como definido na literatura, as sprints devem pos-suir intervalos regulares onde ao final deste intervalo deve haver parte do produto a serentregue. A definição do que deve ser entregue ao final de cada sprint é realizada numareunião, a Sprint Planning, antes do início da sprint.

Devido ao fato dos desenvolvedores possuírem outras tarefas de grande importância,que afetam a disponibilidade dos mesmos para o projeto, não foi possível seguir exata-mente como uma sprint deveria ser. Desta forma, pensou-se em duas maneiras de seimplementar as sprints.

A primeira opção seria manter os períodos, em dias, de término da sprint. Nestamaneira haveriam sprints em que nada de valor seria entregue, já em alguns momentosnão se teria tempo disponível para o desenvolvimento e, assim, os dados de velocidade dotime e de previsão de entrega seriam muito pouco confiáveis.

A segunda opção seria considerar o período de sprint de acordo com o tempo disponívelpara o desenvolvimento. Desta forma, ao final de cada sprint se teria algo de valor entreguee uma confiabilidade maior quanto a velocidade do time em relação ao tempo disponívelde desenvolvimento.

Mesmo possuindo uma falta de confiabilidade quanto à previsão de entrega, a segundaopção se mostrou ser mais coerente com os objetivos da metodologia Scrum. Desta formaaplicou-se a segunda opção, onde em cada sprit planning se definia também o dia em quea sprint terminaria, de acordo com o tempo disponível do time.

4.4.1.2 O Product Owner

Segundo a literatura, o Product Owner é a pessoa que deve entender do produto queestá sendo criado e o valor de negócio entregue em cada tarefa. Na implementação doMotiva, uma pequena mudança para este papel foi necessária.

Seria fundamental escolher uma pessoa da equipe que possuísse conhecimento do valordo produto para os diversos tipos de usuário que o sistema tem. Concentrar esse enten-dimento em uma pessoa apenas, em uma equipe onde há apenas duas pessoas, traria umcusto de tempo muito elevado, prejudicando a velocidade do time.

Desta forma, decidiu-se dividir essa responsabilidade em duas pessoas, de modo emque houvesse um entendimento melhor de todas as particularidades do projeto mas semter um alto custo. Sendo assim, foram definidos dois perfis de Product Owner. Um com

46

o conhecimento mais técnico de como o sistema está sendo desenvolvido e outro com umentendimento melhor de qual o valor a ser entregue pelo software.

Para executar o papel de P.O., as duas pessoas realizavam reuniões de tempos emtempos para definir e priorizar as tarefas a serem realizadas. Desta forma, se chegava aum consenso entre as partes e a pessoa com os conhecimentos mais técnicos repassava taisprioridades nas Sprint Planning do time de desenvolvimento.

47

5 TRABALHOS FUTUROS

Em diversas áreas da computação, muitas vezes é necessário um projeto completo paraque possamos apenas desenvolver e testar pequenas hipóteses. O Motiva é um projetoestruturado com uma arquitetura que facilita o entendimento e a manutenção do seucódigo, tanto frontend quanto backend, justamente para que possa ser reutilizado ouincrementado no futuro. Considerando o fato citado, este capítulo visa propor algunstrabalhos futuros a quem possa interessar e não deseje utilizar recursos para implementarum sistema completo para validar sua hipótese ou simplesmente desenvolver uma aptidãoprática em alguma área voltada para engenharia de software.

5.1 SISTEMAS DE RECOMENDAÇÃO

As postagens possuem identificadores que são propostas pelos seus autores de acordocom o conteúdo da publicação. Cada usuário tem sua preferência de tópicos para leiturae produção de conteúdo. Atentando a esse fato, estudantes interessados em Inteligên-cia Artificial podem propor um estudo de sistemas de recomendação com predição depublicações baseadas no gosto que cada usuário possui por determinado assunto.

5.2 APLICAÇÃO MOBILE

O Motiva possui seu backend estruturado como uma API REST que pode ser con-sumida por qualquer tipo de frontend. Dessa forma, é possível propor a construção deaplicações mobile Android e iOS nativas, assim como aplicações híbridas com React Nativee Flutter. Esse tipo de projeto poderia auxiliar pessoas que querem evoluir como desen-volvedor de aplicações móveis, designer de experiência de usuário e interfaces gráficas eaté papéis voltados para a visão de produto como Product Owner e Scrum Master.

5.3 TESTES

Como um conceito de produto, o sistema necessita de testes para manter a qualidadeda aplicação, ou seja, para garantir que todas as funcionalidades estão sendo executadasde maneira correta. É possível implementar todos os tipos de testes, de acordo com oconceito de pirâmide de testes, como testes unitários, testes end to end, testes de interfacee testes de integração. Além disso, também é possível trabalhar com o desenvolvimento decenários de testes com escrita funcional orientada ao comportamento (Behaviour DrivenDevelopment).

48

5.4 GAMIFICAÇÃO

A gamificação no Motiva é como um jogo sem fim, justamente porque não possui oconceito de nível máximo. Sendo assim, conforme os usuários vão colaborando e crescendojunto com o sistema, é necessário propor novos desafios, novos níveis e novas recompensascom a finalidade de manter a competitividade e motivação dos usuários.

5.5 ANÁLISE DE REDES SOCIAIS

A estrutura da aplicação pode ser vista sob a ótica de uma rede social. Partindo doprincípio que cada usuário é um nó de uma rede social, é possível fazer análises sobrea influência de cada usuário para um determinado tópico, o quanto um tópico podeconectar usuários, assim como quanto uma postagem e comentários podem fazer o mesmo,o desempenho de um aluno de acordo com a sua participação no Motiva, entre outrasdiversas análises.

49

6 CONCLUSÃO

O Motiva não foi criado apenas sob a ótica de um projeto de conclusão de curso.Além de reunir competências do curso de Bacharelado em Ciência da Computação, osistema forma um produto moderno – como uma rede social – que pode agregar valor aocurso se implementado em produção, como também ajudar os futuros profissionais comos trabalhos propostos.

Como produto, foi pensado com a possibilidade de atingir não só os alunos, mas tam-bém os professores, grupos de extensão e grupos de estudo. Existem alguns problemas queo Motiva pode solucionar, como a comunicação no curso, a separação, exposição e atuali-zação dos materiais de estudo durante a graduação. Seu formato de rede social, junto coma gamificação, propõe interação contínua de forma motivadora para os usuários do sis-tema, fazendo com que todos cresçam academicamente e profissionalmente simplesmenteconsumindo e gerando conteúdo.

Existem casos na graduação em que os debates e o conhecimento são privados, pro-positalmente ou não, e esse tipo de situação priva alguns de uma possível evolução. Parao curso, o sistema deixa um legado de motivação à implementação de uma forma de co-municação simples, direta, transparente e em tempo real, e também a possibilidade depropor e elevar o nível de discussões acadêmicas, fazendo com que cada vez mais pessoaspossam participar das mesmas.

Uma das principais razões de reclamações de alguns discentes é a falta de conteúdoprático em algumas disciplinas que são agravadas pelo excesso de teoria das mesmas.Dessa forma, o sistema foi pensado para também incentivar discussões que não sejamdiretamente acadêmicas e a formação de novos grupos com a finalidade de surgirem pro-jetos práticos paralelos ao curso de Ciência da Computação, visto que parte dos alunosnão visam seguir a carreira acadêmica. Com o mesmo pretexto, foram expostas ideias detrabalhos futuros que utilizariam o próprio Motiva como oficina prática.

Desde sempre, o Motiva foi criado sob a ótica de um sistema aberto e incremental,com a ideia de que qualquer pessoa que esteja apta a ajudar possa fazê-lo. Levá-lo àimplementação e produção é um trabalho conjunto para quem possuir disponibilidade easpiração de desenvolver e aperfeiçoar o curso de Bacharelado em Ciência da Computaçãoda Universidade Federal do Rio de Janeiro.

50

REFERÊNCIAS

CHACON, S. Pro Git. Apress, 2010. ISBN 9781430216803. Disponível em:<https://books.google.com.br/books?id=8qsXogEACAAJ>.

CHOU, Y. kai. Actionable Gamification: Beyond Points, Badges, andLeaderboards. [S.l.]: Octalysis Media, 2015. ISBN 1511744049.

FETTE, I.; MELNIKOV, A. The WebSocket Protocol. 2011. <https://www.rfc-editor.org/info/rfc6455>. Accessado: 13 de Abril de 2019.

FIELDING, R. T. Architectural Styles and the Design of Network-basedSoftware Architectures. 76–106 p. Tese (Dissertação de Doutorado), University ofCalifornia, Irvine, CA, 2000. Disponível em: <https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf>.

KUROSE, J. F.; ROSS, K. W. Redes de computadores e a Internet: umaabordagem top-down - 6ª edição. [S.l.]: Pearson Education do Brasil, 2013. ISBN978-85-430-1443-2.

Lean Startup Machine. Validation Board - Free tool for testing startup ideas,stop wasting time and money. 2014. <https://www.leanstartupmachine.com/validationboard/>. Accessado: 07 de Março de 2019.

MARTIN, R. C. Clean Architecture: A Craftsman’s Guide to SoftwareStructure and Design. Boston, MA: Prentice Hall, 2017. (Robert C. Martin Series).ISBN 978-0-13-449416-6. Disponível em: <https://www.safaribooksonline.com/library/view/clean-architecture-a/9780134494272/>.

MASSé, M. REST API Design Rulebook. Sebastopol, CA: O’Reilly Media, Inc.,2012. ISBN 978-1-449-31050-9.

RIES, E. The lean startup : how today’s entrepreneurs use continuousinnovation to create radically successful businesses. New York: Crown Business,2011. ISBN 0307887898.

SUTHERLAND, J. Scrum: A arte de fazer o dobro de trabalho nametade do tempo. LeYa, 2016. ISBN 978-8-544-10451-4. Disponível em:<https://www.amazon.com.br/Scrum-Fazer-Dobro-Trabalho-Metade/dp/8544104517/ref=sr_1_1?__mk_pt_BR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=scrum&qid=1551800185&s=gateway&sr=8-1>.