Probatio

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
INSTITUTO DE MATEMÁTICA
JEAN DA SILVA FELIX
JÔNATAS CORRÊA BARBOSA
Desenvolvimento de um sistema Web
para auxiliar a geração de provas
Profa
. Carla Amor Divino Delgado, D.Sc.
Orientador
Prof. João Carlos Pereira da Silva, D.Sc.
Co-orientador
Rio de Janeiro, Abril de 2017

Desenvolvimento de um sistema Web para auxiliar a geração de provas
Jean da Silva Felix
Jônatas Corrêa Barbosa
Projeto Final de Curso submetido ao Departamento de Ciência da Computação do
Instituto de Matemática da Universidade Federal do Rio de Janeiro como parte dos
requisitos necessários para obtenção do grau de Bacharel em Ciência da Computação.
Apresentado por:
Jean da Silva Felix
Aprovado por:
Profa
. Carla Amor Divino Delgado, D.Sc.
Prof. João Carlos Pereira da Silva, D.Sc.
Profa
. Giseli Rabello Lopes, D.Sc.
Profa
. Silvana Rossetto, D.Sc.
RIO DE JANEIRO, RJ - BRASIL
Abril de 2017

Agradecimentos
Jean da Silva Felix
Sou grato a Deus por me auxiliar em minha jornada acadêmica, assim como em
toda minha vida. Gostaria de agradecer a meu pai Manoel, minha mãe Marta e
meu irmão Jeﬀerson os quais sempre me deram apoio em todas as coisas na vida.
As minhas tias que sempre incentivaram e apoiaram meus estudos, em especial a
Rute e Cira. Aos meus professores do Departamento de Ciência da Computação da
UFRJ que me capacitaram durante todo o curso.
Também gostaria de agradecer em especial a equipe de desenvolvimento do SIGA.
E a minha orientadora Carla e o meu coorientador João Carlos, ambos nos auxilia-
ram durante todo o tempo de projeto nos conduzindo a sua conclusão.
E a todos os meus colegas de classe e amigos que me acompanharam durante a
minha graduação deixo meus agradecimentos.
i

Em primeiro lugar, gostaria de agradecer a toda minha família que sempre foi o
meu alicerce para que eu pudesse realizar o sonho de me formar em Computação na
UFRJ: meu pai Jonas, minha mãe Valeria e meus irmãos Valério e Vanessa.
Agradeço também a todos os meus colegas de graduação da turma de 2010/1:
Felipe Lisboa, Júlio Zynger, Luiz Felipe, Fellipe Sombra, Emerson Yamamoto, Ga-
briel Rodrigues, André Brito e todos os outros que compartilharam comigo esse
desaﬁo da graduação.
Não posso deixar de agradecer aos meus amigos que trabalharam comigo na
equipe SIGA UFRJ: Ricardo Storino, Carlos Felippe Resende, Raphael Paiva, Diego
Mury, Carlos Martins, Tarcísio Miranda, Jean Felix, Thiago Machado e todos os
outros que tive o privilégio de trabalhar junto.
Gostaria de agradecer também aos mestres que tive durante a faculdade, em
especial aos professores Carla Delgado e João Carlos que tiveram toda a dedicação
e paciência de nos aconselhar e orientar por grande parte do nosso curso.
Por último, e não menos importante, gostaria de agradecer a Deus.
Muito obrigado a todos!
ii

RESUMO
Desenvolvimento de um sistema Web para auxiliar a geração de provas
Jean da Silva Felix e Jônatas Corrêa Barbosa
Abril/2017
Orientador: Carla Amor Divino Delgado, D.Sc.
A elaboração de provas é uma atividade comum entre os professores de uma uni-
versidade. No entanto, essa atividade pode se tornar cansativa e repetitiva quando
é necessário elaborar diversas provas em um curto espaço de tempo.
Este trabalho visa o desenvolvimento de uma aplicação Web que auxilia o pro-
cesso de criação de provas. Neste projeto foram aplicadas diversas técnicas de enge-
nharia de software juntamente com técnicas de recomendação. O resultado foi uma
aplicação que recomenda questões de um banco com base nas características de um
professor contribuindo para uma melhoria no processo de criação de provas.
iii

ABSTRACT
Developing a Web application to support exam elaboration
Jean da Silva Felix and Jônatas Corrêa Barbosa
Abril/2017
Advisor: Carla Amor Divino Delgado, D.Sc.
Exam elaboration is a common task between teachers of a university. However,
this task can be exhausting and monotonous when it’s necessary to design many tests
in a short space of time.
This project aims the development of a Web application that supports the process
of exam elaboration. Many software engineering and recommendation techiniques
were applied to this project. The result was an application that recommends questions
of a database improving the task to search and select questions.
iv

Lista de Figuras
Figura 2.1: Diagrama Criar Questão . . . . . . . . . . . . . . . . . . . . . . . 4
Figura 2.2: Diagrama Criar Prova . . . . . . . . . . . . . . . . . . . . . . . . 4
Figura 2.3: Tela de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figura 2.4: Cadastro inválido . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figura 2.5: Menu inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figura 2.6: Nova questão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figura 2.7: Campos de uma questão . . . . . . . . . . . . . . . . . . . . . . . 7
Figura 2.8: Código LaTeX de uma questão . . . . . . . . . . . . . . . . . . . 8
Figura 2.9: Erro de compilação de uma questão . . . . . . . . . . . . . . . . . 8
Figura 2.10: Montar prova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 2.11: Tabela de questões . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 2.12: Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figura 2.13: Tela de preenchimento do cabeçalho e rodapé . . . . . . . . . . . 10
Figura 2.14: Campos do cabeçalho e rodapé . . . . . . . . . . . . . . . . . . . 11
Figura 4.1: Desenvolvimento iterativo em espiral . . . . . . . . . . . . . . . . 21
Figura 4.2: Quadro de tarefas do Probatio no Trello . . . . . . . . . . . . . . 23
Figura 4.3: Funcionalidade de ﬁltrar questões no Probatio . . . . . . . . . . . 24
v

Figura 4.4: Testes do Probatio vistos no JUnit . . . . . . . . . . . . . . . . . 26
Figura 4.5: Arquitetura de um projeto utilizando integração contínua . . . . . 28
Figura 4.6: Repositório do Probatio no GitHub . . . . . . . . . . . . . . . . . 29
Figura 5.1: Recomendações da Amazon . . . . . . . . . . . . . . . . . . . . . 33
Figura 5.2: Perﬁl de Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 5.3: Recomendação Colaborativa . . . . . . . . . . . . . . . . . . . . . 34
Figura 5.4: Recomendação baseada em Conteúdo . . . . . . . . . . . . . . . . 35
Figura 5.5: Arquitetura do Sistema Cadmus . . . . . . . . . . . . . . . . . . . 38
Figura 5.6: Busca de Questões do Sistema Cadmus . . . . . . . . . . . . . . . 40
Figura 5.7: Recomendação no Probatio . . . . . . . . . . . . . . . . . . . . . 43
Figura 5.8: Modelo entidade relacionamento do Probatio . . . . . . . . . . . . 44
Figura 5.9: Filtro baseado em Conteúdo do Probatio . . . . . . . . . . . . . . 45
vi

Lista de Tabelas
Tabela 3.1: Domínio Cognitivo da Taxonomia de Bloom . . . . . . . . . . . . 15
Tabela 5.1: Valores dos Pesos . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Tabela 5.2: Valores das Questões . . . . . . . . . . . . . . . . . . . . . . . . . 42
Tabela 5.3: Valores do Perﬁl do Professor . . . . . . . . . . . . . . . . . . . . 42
Tabela 5.4: Questões de uma Prova . . . . . . . . . . . . . . . . . . . . . . . 46
Tabela 5.5: Perﬁl do Professor . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Tabela 5.6: Resultado da consulta . . . . . . . . . . . . . . . . . . . . . . . . 47
Tabela 5.7: Resultado da ordenação . . . . . . . . . . . . . . . . . . . . . . . 48
Tabela A.1: Questionário base da entrevista I . . . . . . . . . . . . . . . . . . 58
Tabela A.2: Questionário da entrevista II . . . . . . . . . . . . . . . . . . . . 59
vii

Lista de Abreviaturas e Siglas
CD Compact Disc
IDE Integrated Development Environment
LaTeX Lamport TeX
MVP Minimum Viable Product
SCM Source Code Management
UFRJ Universidade Federal do Rio de Janeiro
XP Extreme Programming
TDD Test Driven Development
PDF Portable Document Format
viii

Sumário
Agradecimentos i
Resumo iii
Abstract iv
Lista de Figuras v
Lista de Tabelas vii
Lista de Abreviaturas e Siglas viii
1 Introdução 1
2 O Probatio 3
2.1 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Sistemas de Montagem de Prova . . . . . . . . . . . . . . . . . . . . . 5
2.3 Telas do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Elaboração de Avaliações 12
3.1 Taxonomia de Bloom . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
ix

3.1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Domínios do Conhecimento . . . . . . . . . . . . . . . . . . . 14
3.1.3 Taxonomia de Bloom no Probatio . . . . . . . . . . . . . . . . 18
3.2 Entrevista com Professores . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Desenvolvimento Ágil de Software 20
4.1 Métodos Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1 Desenvolvimento Ágil . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.2 Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Mínimo Produto Viável . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 MVP no Probatio . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Desenvolvimento Guiado por Testes . . . . . . . . . . . . . . . . . . . 25
4.3.1 Testes no Probatio . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Integração Contínua . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.1 Processo de Integração Contínua . . . . . . . . . . . . . . . . 27
4.4.2 Integração Contínua no Probatio . . . . . . . . . . . . . . . . 28
4.5 Conclusão sobre o Desenvolvimento Ágil no Probatio . . . . . . . . . 30
5 Sistemas de Recomendação 32
5.1 Introdução aos Sistemas de Recomendação . . . . . . . . . . . . . . . 32
5.1.1 Conceitos Básicos . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.1.1 Recomendação Colaborativa . . . . . . . . . . . . . . 34
5.1.1.2 Recomendação baseada em Conteúdo . . . . . . . . . 35
5.1.1.3 Recomendação baseada em Conhecimento . . . . . . 35
x

5.2 Estudo de Caso: Cadmus . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.2 Perfil de Usuário . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.3 Filtro baseado em Conteúdo . . . . . . . . . . . . . . . . . . . 41
5.2.4 Filtro baseado em Conhecimento . . . . . . . . . . . . . . . . 41
5.3 Recomendação no Probatio . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.2 Perfil de Usuário . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.3 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.4 Filtro baseado em Conteúdo . . . . . . . . . . . . . . . . . . . 45
5.3.5 Filtro baseado em Conhecimento . . . . . . . . . . . . . . . . 45
5.4 Comparação entre o Probatio e o Cadmus . . . . . . . . . . . . . . . 48
6 Resultados e Conclusão 50
6.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.1 Dificuldades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . 53
Referências 55
A Perguntas das Entrevistas 57
xi

Capítulo 1
Introdução
Sempre existiu a necessidade de se avaliar o conteúdo ensinado em um processo
de aprendizagem. Professores precisam mensurar os conhecimentos de seus alunos
para conhecer o progresso desses ao aprender algum tema. A prova escrita, ainda
que sofra diversas críticas, é um dos instrumentos de avaliação mais utilizados para
essa função. Professores rotineiramente se deparam com a tarefa de elaborar provas.
Pode ser uma tarefa cansativa quando se tem muitas provas para serem feitas ou
estressante quando se tem um tempo curto para sua criação.
Acreditamos que um sistema capaz de facilitar essa tarefa serviria de grande
ajuda a quem precisa criar provas com certa frequência. Por isso, começamos a
construção do sistema Probatio. Este sistema visa auxiliar a geração de provas atra-
vés de técnicas de recomendação e busca semântica. Utilizando-se dessas técnicas
teremos uma prova que atende aos critérios estabelecidos pelo professor, conseguindo
assim atender às características que aquele professor julga importante de se aprender
em uma determinada disciplina. Ao ﬁnal do processo, o professor terá um conjunto
de questões de maneira rápida e personalizada.
Para isso, contamos com um banco colaborativo de questões. Neste banco, os
próprios professores podem cadastrar suas questões e compartilhá-las entre si. Esses
professores irão montar suas provas consultando as questões do banco e escolhendo,
através de alguns critérios, as melhores para sua avaliação.

2
Como objetivos finais para o Probatio queremos mais que uma ferramenta de
busca. Gostaríamos de entregar aos professores um sistema que tenha uma maior
participação no processo de criação de provas. Queremos fornecer uma ferramenta
que aprenda com o professor a encontrar o conteúdo por ele desejado.
É importante ressaltar que o Probatio é um projeto que foi realizado por diversos
grupos de estudantes. Inicialmente, houve um trabalho de prova de conceito feito
pelas alunas Vanessa Rodrigues Pinto e Caroline da Silva Cecilio. A seguir, foram
criados três grupos de desenvolvimento e pesquisa: um grupo de desenvolvimento
Web e recomendação, um grupo de gamificação e um grupo de tagueamento. O
grupo de desenvolvimento Web e recomendação é composto pelos autores deste
texto. O grupo de gamificação é composto pelos alunos Ricardo Denilson e Matheus
Forny. Finalmente, o grupo de tagueamento é composto pelo aluno Hugo Siqueira
Gomes.
No próximo capitulo descrevemos como é o sistema Probatio, incluindo as suas
funcionalidades. Em seguida, serão apresentadas as pesquisas na área de educação
que foram realizadas ao longo do projeto. No quarto capítulo, mostramos as técnicas
de desenvolvimento que nos conduziram durante a criação desse sistema e as ferra-
mentas utilizadas em sua criação. No quinto capítulo apresentamos as técnicas de
recomendação estudadas durante o projeto, exibindo os estudos que fizemos de um
sistema com uma proposta bem semelhante. Ao final apresentamos uma conclusão
do nosso projeto. Todo o trabalho apresentado no escopo deste texto foi realizado
pelos autores.

Capítulo 2
O Probatio
O Probatio é um sistema Web1
e pode ser acessado através do seu endereço em
http://probatio.com.br. A seguir faremos uma breve apresentação das funciona-
lidades e das telas do sistema.
1
Web - https://en.wikipedia.org/wiki/World_Wide_Web

2.1. FUNCIONALIDADES 4
2.1 Funcionalidades
Existem duas funcionalidades essenciais no Probatio: criar questão e criar prova.
Essas funcionalidades são representadas através dos diagramas de atividades abaixo.
Figura 2.1: Diagrama Criar Questão
Figura 2.2: Diagrama Criar Prova

2.2. SISTEMAS DE MONTAGEM DE PROVA 5
Na funcionalidade de criar questão, o usuário precisa efetuar o login no sistema
e acessar a tela de criar questões. A partir daí, é necessário que ele preencha os
campos da questão. Caso ocorra um erro de compilação, um relatório de erros será
exibido. Caso não ocorra nenhum erro de compilação, a nova questão será inserida
no banco.
Já na funcionalidade de criar prova, o usuário também precisa efetuar o login no
sistema e acessar a tela de montar provas. Com isso, ele poderá ﬁltrar e selecionar
questões da tabela de questões. Caso ele tenha selecionado pelo menos uma questão,
o usuário será redirecionado para a tela de preenchimento de cabeçalho e rodapé onde
terá a opção de emitir o PDF da prova gerada.
2.2 Sistemas de Montagem de Prova
2.3 Telas do Sistema
A tela inicial do sistema é a tela de login apresentada na ﬁgura 2.3. Através
dessa tela é realizado o acesso ao sistema.
Figura 2.3: Tela de login

2.3. TELAS DO SISTEMA 6
Inicialmente, é necessário que o professor que esteja acessando pela primeira
vez efetue um cadastro informando alguns dados para o sistema. Caso o e-mail
informado já esteja cadastrado, o usuário é informado por meio de uma mensagem
apresentada na tela, como mostra a ﬁgura 2.4.
Figura 2.4: Cadastro inválido
Ao efetuar o acesso com sucesso (realizando o cadastro corretamente ou através
de um login válido), o usuário será redirecionado para a tela de menu inicial do
sistema que é apresentada na ﬁgura 2.5. O menu da lateral direita apresenta as
funcionalidades disponíveis para o professor que está logado.
Figura 2.5: Menu inicial

Ao clicar no botão “Criar Questão” o usuário será levado a uma tela ilustrada
na figura 2.6, onde poderá cadastrar os dados de uma nova questão. Os campos
destacados em vermelho são obrigatórios.
Figura 2.6: Nova questão
As questões inseridas ficam disponíveis para os demais usuários do sistema. Po-
dem ser acessadas através do filtro de questões quando um professor estiver mon-
tando uma prova.
No campo “Disciplina” o usuário deverá escolher uma dentre as diversas disci-
plinas cadastradas no sistema para caracterizar a questão, como ilustrado na figura
2.7. O campo “Tags” permite ao usuário adicionar uma ou mais características para
a questão. O campo “Ano” representa o ano em que a questão foi elaborada.
Figura 2.7: Campos de uma questão

O campo “Código LaTeX” deve ser preenchido com o código LaTeX correspon-
dente à questão a ser inserida, como ilustra a ﬁgura 2.8.
Figura 2.8: Código LaTeX de uma questão
Caso ocorra um erro de compilação no código LaTeX da questão, será exibido
uma janela com a mensagem de erro como mostra a ﬁgura 2.9.
Figura 2.9: Erro de compilação de uma questão
Caso a questão não possua erros de compilação, ela será inserida no banco de
dados. Esta nova questão será de domínio público e estará disponível para utilização
em provas por qualquer usuário do sistema.

Ao clicar no botão “Criar Prova” o usuário será conduzido a um filtro de questões
ilustrado na figura 2.10, onde poderá filtrar pelos campos tags e disciplina.
Figura 2.10: Montar prova
Serão exibidas ao usuário as questões ordenadas segundo a sua relevância con-
forme ilustrado na figura 2.11. A ordem das questões na tabela é gerada pelo sistema
de recomendação2
do Probatio.
Figura 2.11: Tabela de questões
2
Sistemas de Recomendação - Capítulo 5

Ao clicar no botão “Preview” será exibido uma prévia da prova que contém as
questões escolhidas pelo usuário até o momento, como mostra a ﬁgura 2.12.
Figura 2.12: Preview
Quando o usuário acaba de selecionar as questões que deseja em sua prova e
clica no botão “Montar Prova” ele será levado à tela de preenchimento de cabeçalho
e rodapé da prova ilustrada na ﬁgura 2.13.
Figura 2.13: Tela de preenchimento do cabeçalho e rodapé

Nesta tela é exibido para o usuário os campos “Cabeçalho da Prova” e “Rodapé
da Prova” onde ele poderá preencher com informações relevantes conforme ilustra a
ﬁgura 2.14. Estes campos assim como as questões e toda a prova é escrito no formato
LaTeX. Para trabalhar com a linguagem LaTeX em nosso sistema utilizamos uma
biblioteca chamada JLR (Java LaTex Report) [11]. Esta biblioteca nos permite a
compilação de um código LaTeX.
Ao clicar no botão “Emitir Prova” será feito o download da prova.
Figura 2.14: Campos do cabeçalho e rodapé
Os dados das provas geradas no sistema ﬁcam armazenados no banco de dados.
Estes são utilizados para a parte de recomendação que é abordada no capitulo 5.3.

Capítulo 3
Elaboração de Avaliações
Uma das etapas iniciais do projeto foi o estudo do domínio do problema, a
elaboração de avaliações acadêmicas. Para que pudéssemos aprender mais sobre o
assunto, coletamos diversas informações a respeito das características que levam a
escolha de uma determinada questão, bem como os objetivos educacionais que se
deseja alcançar ao empregar um determinado tipo de questão. Neste capítulo iremos
expor os estudos e entrevistas relacionados com a extração dessas informações.
3.1 Taxonomia de Bloom
Para que pudéssemos entender melhor o problema relacionado com a elabora-
ção de provas assim como o processo de ensino e aprendizagem como um todo, foi
necessário fazer uma pesquisa na área de educação. Nesta seção iremos abordar a
Taxonomia de Bloom, um conceito que foi estudado durante o início do desenvolvi-
mento do projeto.

3.1. TAXONOMIA DE BLOOM 13
3.1.1 Motivação
Em educação, decidir e definir os objetivos de aprendizagem é uma parte
importante do processo de ensino. Um objetivo educacional é uma descrição clara
sobre o desempenho e a competência que os educadores gostariam que seus edu-
candos demonstrassem antes de serem considerados conhecedores de determinados
assuntos. [3]
Os objetivos de aprendizagem são importantes por diversos motivos. Em pri-
meiro lugar, eles são úteis para ajudar os estudantes a decidirem se querem ou não
participar de um determinado curso. Além disso, os objetivos educacionais ajudam
no processo de acompanhamento de um curso pois permitem que o estudante avalie
seu progresso observando a lista de objetivos, permitindo que o aluno tenha uma
ideia geral de quanto conteúdo ainda resta para finalizar o curso. [3]
Para os educadores, os objetivos de aprendizagem ajudam a manter o conteúdo
direcionado e focado durante a concepção de um curso. Todo o conteúdo de um
curso, assim como as suas avaliações, deve abordar um ou mais objetivos de apren-
dizagem. Caso o curso possua algum conteúdo que não esteja sendo contemplado,
deve-se revisar os objetivos definidos. [3]
Nesse contexto, um dos instrumentos existentes que podem auxiliar os educado-
res é a taxonomia proposta por Benjamin Bloom em 1956. A taxonomia de Bloom
tem como objetivo ajudar no planejamento, organização e controle dos objetivos de
aprendizagem. [3]

3.1.2 Domínios do Conhecimento
Segundo a taxonomia proposta por Bloom, o conhecimento pode ser dividido em
três grandes domínios: cognitivo, afetivo e psicomotor. Cada um destes domí-
nios possuem características diferentes. Estes domínios são divididos em diversas
categorias. Estas categorias são apresentadas numa hierarquia de complexidade e
dependências, da mais simples à mais complexa. Para que um aluno possa ascender
a uma nova categoria, é preciso ter obtido um desempenho adequado na anterior,
pois cada uma utiliza capacidades adquiridas nos níveis anteriores. [3]
O domínio cognitivo está relacionado com o aprender e com a habilidade de do-
minar um novo conhecimento. Já o domínio afetivo está relacionado a sentimentos e
posturas. Este domínio envolve categorias ligadas ao desenvolvimento da área emo-
cional e afetiva, que incluem comportamento, atitude, responsabilidade, respeito,
emoção e valores. Finalmente, o domínio psicomotor está relacionado com atividades
física especíﬁcas. Este domínio possui seis categorias e suas ideias estão relacionadas
a reﬂexos, percepção, habilidades físicas, movimentos aperfeiçoados e comunicação
não-verbal. [3]
Embora todos os três domínios (cognitivo, afetivo e psicomotor) tenham sido
amplamente discutidos e divulgados pela comunidade de educação, o foco do nosso
estudo foi o domínio cognitivo. Isso ocorreu porque o Probatio é um sistema para
elaborar provas escritas e o domínio cognitivo possui as habilidades que são aferi-
das neste tipo de avaliação. A Tabela 3.1 descreve o domínio cognitivo segundo a
Taxonomia de Bloom.

Tabela 3.1: Domínio Cognitivo da Taxonomia de Bloom
Categoria Descrição
1. Conhecimento Definição: Habilidade de lembrar informações e con-
teúdos previamente abordados como fatos, datas, pa-
lavras, teorias, métodos, classificações, lugares, regras,
critérios, procedimentos etc. A habilidade pode envolver
lembrar uma significativa quantidade de informação ou
fatos específicos. O objetivo principal desta categoria é
trazer à consciência esses conhecimentos.
Verbos: enumerar, definir, descrever, identificar, de-
nominar, listar, nomear, combinar, realçar, apontar, re-
lembrar, recordar, relacionar, reproduzir, solucionar, de-
clarar, distinguir, rotular, memorizar, ordenar e reco-
nhecer.
2. Compreensão Definição: Habilidade de compreender e dar significado
ao conteúdo. Essa habilidade pode ser demonstrada por
meio da tradução do conteúdo compreendido para uma
nova forma (oral, escrita, diagramas etc.) ou contexto.
Nessa categoria, encontra-se a capacidade de entender a
informação ou fato, de captar seu significado e de utilizá-
la em contextos diferentes.
Verbos: alterar, construir, converter, decodificar, de-
fender, definir, descrever, distinguir, discriminar, esti-
mar, explicar, generalizar, dar exemplos, ilustrar, in-
ferir, reformular, prever, reescrever, resolver, resumir,
classificar, discutir, identificar, interpretar, reconhecer,
redefinir, selecionar, situar e traduzir.

3. Aplicação Definição: Habilidade de usar informações, métodos
e conteúdos aprendidos em novas situações concretas.
Isso pode incluir aplicações de regras, métodos, modelos,
conceitos, princípios, leis e teorias.
Verbos: aplicar, alterar, programar, demonstrar, de-
senvolver, descobrir, dramatizar, empregar, ilustrar, in-
terpretar, manipular, modificar, operacionalizar, organi-
zar, prever, preparar, produzir, relatar, resolver, trans-
ferir, usar, construir, esboçar, escolher, escrever, operar
e praticar.
4. Análise Definição: Habilidade de subdividir o conteúdo em
partes menores com a finalidade de entender a estrutura
final. Essa habilidade pode incluir a identificação das
partes, análise de relacionamento entre as partes e re-
conhecimento dos princípios organizacionais envolvidos.
Identificar partes e suas inter-relações. Nesse ponto é ne-
cessário não apenas ter compreendido o conteúdo, mas
também a estrutura do objeto de estudo.
Verbos: analisar, reduzir, classificar, comparar, con-
trastar, determinar, deduzir, diagramar, distinguir, di-
ferenciar, identificar, ilustrar, apontar, inferir, relaci-
onar, selecionar, separar, subdividir, calcular, discri-
minar, examinar, experimentar, testar, esquematizar e
questionar.

5. Síntese Definição: Habilidade de agregar e juntar partes com
a finalidade de criar um novo todo. Essa habilidade en-
volve a produção de uma comunicação única (tema ou
discurso), um plano de operações (propostas de pesqui-
sas) ou um conjunto de relações abstratas (esquema para
classificar informações). Combinar partes não organiza-
das para formar um “todo”.
Verbos: categorizar, combinar, compilar, compor, con-
ceber, construir, criar, desenhar, elaborar, estabelecer,
explicar, formular, generalizar, inventar, modificar, or-
ganizar, originar, planejar, propor, reorganizar, relacio-
nar, revisar, reescrever, resumir, sistematizar, escrever,
desenvolver, estruturar, montar e projetar.
6. Avaliação Definição: Habilidade de julgar o valor do material
(proposta, pesquisa, projeto) para um propósito espe-
cífico. O julgamento é baseado em critérios bem defi-
nidos que podem ser externos (relevância) ou internos
(organização) e podem ser fornecidos ou conjuntamente
identificados. Julgar o valor do conhecimento.
Verbos: avaliar, averiguar, escolher, comparar, con-
cluir, contrastar, criticar, decidir, defender, discriminar,
explicar, interpretar, justificar, relatar, resolver, resu-
mir, apoiar, validar, escrever um review sobre, detectar,
estimar, julgar e selecionar.
Fonte: Taxonomia de Bloom: revisão teórica e apresentação das adequações do
instrumento para definição de objetivos instrucionais [3]

3.2. ENTREVISTA COM PROFESSORES 18
3.1.3 Taxonomia de Bloom no Probatio
Para que seja possível construir um sistema de recomendação baseado em con-
teúdo1
é necessário que estejam disponíveis alguns dados sobre os itens a serem
recomendados. [2]
No caso do Probatio, os itens a serem recomendados são as questões que os
professores usarão para elaborar suas provas. Estas questões podem ser classificadas
de diversas formas a partir de suas características básicas como dificuldade, tipo,
disciplina, assunto etc.
Além dessas formas já conhecidas de se classificar uma questão, também é pos-
sível utilizar a Taxonomia de Bloom e classificar uma questão com relação à sua
categoria no domínio cognitivo. Para isso, podem ser utilizados os verbos auxiliares
de cada categoria, fazendo uma classificação a partir do enunciado de cada questão.
3.2 Entrevista com Professores
Para descobrirmos a viabilidade de um sistema como o Probatio realizamos di-
versas entrevistas. Estas entrevistas foram importantes para nos ajudar a entender
como funciona o processo de elaboração de uma prova e para extrair as funcionali-
dades que um sistema poderia ter a fim de satisfazer as necessidades dos professo-
res. Dessa forma, selecionamos quatro professores do Departamento de Ciência da
Computação da UFRJ. Estes docentes possuem mais de dez anos de magistério e
ministram aulas na graduação do curso de Ciência da Computação.
1
Recomendação baseada em Conteúdo - Seção 5.1.1.2

3.2. ENTREVISTA COM PROFESSORES 19
As perguntas realizadas nas entrevistas se encontram na Tabela A.1 deste tra-
balho. Apresentaremos as conclusões obtidas através da análise das respostas da
entrevista e exibiremos os dados importantes que refletiram na construção do nosso
sistema.
De acordo com as respostas, concluímos que cada professor possui um certo
padrão de criação de provas. Por exemplo, um dos entrevistados diz que tenta
manter uma mistura entre questões práticas e teóricas além de optar por questões
dissertativas. Três deles nos disseram que costumam reutilizar questões de suas
provas antigas. Esses professores certamente seguem um padrão na escolha de suas
questões. Por isso, inferimos que poderiam gostar de consultar um banco de questões
para montar suas avaliações assim como fazem utilizando suas avaliações passadas.
Quanto ao formato das avaliações, os professores tinham em comum pensarem
no tempo de duração da prova, além da dificuldade e ordenação das questões. Con-
seguimos identificar dois tipos de ordenação, da questão considerada mais fácil para
a mais difícil, e o que remete a ordenação cronológica do conteúdo ministrado em
sala de aula.
A princípio todos os professores se dispuseram a utilizar um sistema para ela-
borarem suas avaliações. Como características importantes para este sistema foram
citadas a possibilidade de edição de uma questão e também a disponibilidade do
gabarito das questões que compõem a prova. Concluindo a entrevista demos iní-
cio a implementação do primeiro MVP2
do sistema. Esta versão contou com duas
funcionalidades que consideramos básicas, a de inserir uma questão no banco e a
funcionalidade de montar uma prova selecionando questões do banco.
2
MVP - Seção 4.2

Capítulo 4
Desenvolvimento Ágil de Software
Para desenvolver o projeto nos baseamos em algumas técnicas e valores de desen-
volvimento de software conhecidas como desenvolvimento ágil. Desenvolvimento
ágil ou método ágil é um conjunto de valores e técnicas de desenvolvimento que tem
seu foco em responder a mudanças e entregar funcionalidades com qualidade e rapi-
dez [9]. Neste capítulo apresentamos os valores e técnicas empregados no Probatio
e as motivações que nos levaram a utilizá-los.
4.1 Métodos Ágeis
4.1.1 Desenvolvimento Ágil
O termo desenvolvimento ágil refere-se a um desenvolvimento iterativo que
propõe ciclos curtos.
Cada ciclo de desenvolvimento é chamado de iteração. Ao ﬁm de toda itera-
ção temos um software funcionando. Na primeira iteração teremos um software
com poucas funcionalidades. Na última iteração teremos o software com todas as
funcionalidades para atender a demanda do cliente.

4.1. MÉTODOS ÁGEIS 21
Este tipo de desenvolvimento também é conhecido como desenvolvimento em
espiral. Ao longo do tempo o número de funcionalidades do sistema cresce tendo,
ao final de cada ciclo, novas funcionalidades, como ilustrado na figura 4.1.
Figura 4.1: Desenvolvimento iterativo em espiral
Fonte: http://www.devmedia.com.br/introducao-ao-desenvolvimento-agil/5916
O desenvolvimento ágil é baseado na premissa de que o desenvolvedor de software
trabalha intensamente com o conhecimento. Isto significa que o desenvolvedor
aprende enquanto cria. A experimentação faz com que este, corrigindo o que fez,
busque um caminho melhor em sua criação. Este aprendizado vem de um conceito
conhecido como feedback.
O feedback é o ato de se observar algo e criticá-lo com o objetivo de torná-lo
melhor. [8]
Partindo dessa premissa, o desenvolvimento ágil sugere que não só o desenvol-
vedor mas também o cliente aprendem ao longo da duração do projeto. O cliente
pode solicitar alterações para adequar o software durante todo o processo. Tor-
nando o produto final a ferramenta que acredita ser a necessária para solução de
seus problemas.

4.1. MÉTODOS ÁGEIS 22
4.1.2 Valores
Dentro desta categoria que chamamos de desenvolvimento ágil, falaremos de
algumas práticas e valores que utilizamos na construção de nosso sistema.
O feedback é o que possibilita ao cliente e ao desenvolvedor aprenderem en-
quanto constroem o sistema. Garantindo que todas as funcionalidades sejam guiadas
para atender as suas necessidades. [8]
A comunicação, parte vital do processo, ajuda o cliente a passar ao desen-
volvedor o feedback que teve do sistema. Gerando a retroalimentação para que as
próximas iterações venham priorizando o mais importante e que gere mais valor para
o cliente. [8]
A simplicidade serve para que, a cada passo dado, o desenvolvedor implemente
apenas o que é suficiente para o cliente. Isto permite que o feedback seja colhido
de forma mais rápida. As funcionalidades são implementadas de forma simples
solucionando os problemas que o cliente tem no momento. Possibilitando que este
veja o sistema funcionando o quanto antes e aprenda com ele. [8]
No Probatio, realizamos reuniões com certa periodicidade para apresentar o sis-
tema aos nossos orientadores. Durantes estas reuniões discutimos sobre o que foi
implementado colhendo o feedback. Estas também serviam para combinarmos o que
seria feito na próxima entrega. Sempre realizamos entregas simples atentando para
o que foi combinado. Desenvolvendo o mínimo para que cada funcionalidade esti-
vesse pronta e atendesse a necessidade especificada, evitando retrabalho. A figura
4.2 ilustra o quadro utilizado para organizar as tarefas do Probatio no Trello1
.
Nas próximas seções focaremos nas práticas que adotamos durante a construção
do Probatio.
1
Trello - https://trello.com/

4.2. MÍNIMO PRODUTO VIÁVEL 23
Figura 4.2: Quadro de tarefas do Probatio no Trello
4.2 Mínimo Produto Viável
Na área de empreendedorismo, principalmente no contexto de startups, um pro-
duto mínimo viável (MVP do inglês Minimum Viable Product) é a versão mais
simples de um produto que pode ser disponibilizada para a validação de um pequeno
conjunto de hipóteses sobre o negócio. [7]
Por exemplo, imaginemos o início do desenvolvimento de um produto para cortar
grama. A princípio, temos como produto mais simples e que atende o requisito de
cortar grama, uma tesoura grande. Tentamos mostrá-la como solução para cortar
grama e, caso as pessoas aprovem esta solução, conhecemos que é razoável a ideia
de que se precisa cortar grama. Colhemos informações a respeito da tesoura grande,
fornecida por quem a utilizou. Evoluímos este produto, pouco a pouco, com novas
hipóteses a partir das informações colhidas.

4.2. MÍNIMO PRODUTO VIÁVEL 24
A motivação para a implementação do mínimo produto viável é evitar o desper-
dício de tempo, dinheiro e esforço construindo um produto que não vai atender às
expectativas dos usuários e de outros indivíduos interessados. [7]
4.2.1 MVP no Probatio
Durante a etapa inicial de desenvolvimento do Probatio foi utilizado o conceito
de produto mínimo viável. Para isso, pensamos na funcionalidade mais básica que
deveria existir no sistema para construirmos o primeiro MVP e validarmos a ideia
central do projeto.
A funcionalidade de ﬁltrar questões do banco de dados e selecionar um subgrupo
destas questões para elaborar uma prova foi a funcionalidade escolhida para compor
o MVP inicial. Com esta funcionalidade é possível validar um conjunto de hipóteses:
• Os professores utilizariam um sistema web para elaborar suas provas?
• Os professores utilizariam um banco de questões?
• Os professores utilizariam a linguagem LaTeX para representar questões?
Figura 4.3: Funcionalidade de ﬁltrar questões no Probatio

4.3. DESENVOLVIMENTO GUIADO POR TESTES 25
Utilizamos o primeiro MVP que criamos para validar a ideia inicial do produto.
Foi feito um experimento com quatro professores do Departamento de Ciência da
Computação da UFRJ, onde foi solicitado para que eles elaborassem uma prova
da disciplina Computação I utilizando o sistema Probatio. Estes quatro professores
responderam diversas perguntas que nos levaram a validação do nosso primeiro MVP.
A partir desse experimento, pudemos validar as nossas hipóteses iniciais e dar
continuidade ao projeto. Os quatro professores questionadas se mostraram positivos
com as ideias de se utilizar um sistema web para elaborar provas, um banco de
questões colaborativo e a linguagem LaTeX.
Com a validação dessas hipóteses poderíamos evoluir o produto para o próximo
MVP criando novas hipóteses. E se o sistema tivesse algum mecanismo de recomen-
dação de questões? E se tal sistema possuísse algum aspecto de gamiﬁcação? Assim
por diante até que o produto evolua de MVP em MVP.
4.3 Desenvolvimento Guiado por Testes
Os projetos de software, geralmente ultrapassam o prazo ou precisam ser feitos as
pressas para não ultrapassarem. Sobra pouquíssimo tempo para testar. A maioria
dos desenvolvedores enxerga esta tarefa como algo monótono e que consome muito
tempo. [8]
Tendo em vista que a criação de um sistema é algo complicado, ao escrever novas
linhas de código, sempre existe a possibilidade da inserção de um comportamento
indesejável, um possível erro. Estes erros podem ser ocasionados pelas mais diversas
causas: falta de atenção, erro de lógica, interpretação incorreta etc. Os testes nos
auxiliam a descobrir e corrigir estes erros. [8]
O desenvolvimento guiado por testes (TDD do inglês Test Driven Develop-
ment) prega que os testes sejam criados durante a implementação. O desenvolvedor
deve primeiro criar os testes e depois implementar o código para que os testes pas-
sem. Esta prática facilita a correção dos erros tendo em vista de que estes irão
aparecer ainda na codiﬁcação.

4.3. DESENVOLVIMENTO GUIADO POR TESTES 26
4.3.1 Testes no Probatio
Implementamos vários testes de unidade para verificar a lógica implementada em
nossas classes e o relacionamento destas com o banco de dados utilizado. Os testes
de unidade são realizados sobre cada classe do sistema. O JUnit2
, um framework
que nos permite automatizar os testes de forma simples, foi a ferramenta escolhida
para implementarmos os nossos testes. Com o plugin da IDE3
que utilizamos temos
uma ótima forma de visualizar os testes, como ilustrado na figura 4.4.
Figura 4.4: Testes do Probatio vistos no JUnit
Estes testes são escritos durante a codificação do sistema. Eles auxiliam a geração
de um código limpo, claro e que forneça o comportamento esperado. Servem para
averiguar que cada classe do sistema funciona da forma que deveria. Verificando se
os resultados obtidos por métodos e o comportamento gerado são os esperados.
Ao implementar, escreve-se o código mais simples o possível para que o teste
passe. Desta forma, o teste guia o desenvolvedor para que implemente somente o
necessário sem perder tempo com generalizações ou qualquer outra coisa que não
fosse aquela funcionalidade. Ajudando na simplicidade, um dos valores do desenvol-
vimento ágil.
2
JUnit - http://junit.org/junit4
3
IDE - https://pt.wikipedia.org/wiki/Ambiente_de_desenvolvimento_integrado

4.4. INTEGRAÇÃO CONTÍNUA 27
4.4 Integração Contínua
Durante o desenvolvimento de um sistema por uma equipe de software composta
por diversos membros é comum dividir as tarefas entre os desenvolvedores separando
quais responsabilidades serão de cada programador. Geralmente, o sistema é divi-
dido de uma forma que cada programador é responsável por uma única parte do
sistema. [8]
Quando a equipe de desenvolvimento espera meses, ou até mesmo semanas para
integrar todas as partes do sistema, é comum ocorrerem casos em que não se consiga
compilar ou até mesmo executá-lo devido às grandes diferenças existentes entre cada
parte. Em geral, quanto maior for o tempo entre uma integração e outra, mais a
equipe encontrará dificuldades para fazer o sistema funcionar e garantir que os testes
continuam passando. [8]
A integração contínua é uma prática de desenvolvimento de software que se origi-
nou da metodologia Extreme Programming (XP). Esta prática consiste em integrar
o trabalho feito por vários programadores de um mesmo sistema diversas vezes ao
dia, assegurando que a base de código permaneça consistente ao decorrer do desen-
volvimento do sistema. [10]
O Probatio é um projeto com diversos grupos de estudantes, onde cada grupo é
responsável por desenvolver um conjunto de funcionalidades diferente que irá fazer
parte do mesmo sistema. Por isso, foi necessário estudarmos e utilizarmos ferramen-
tas e práticas de integração contínua para garantir que novas funcionalidades não
criassem defeitos no sistema.
4.4.1 Processo de Integração Contínua
Inicialmente, o processo de integração contínua começa com algum programador
enviando mudanças no código-fonte do projeto para o repositório do sistema de con-
trole de versão. Enquanto isso, o servidor de integração contínua envia requisições
para o repositório do sistema de controle de versão, a fim de verificar se existem
novas mudanças. [6]

Assim que as mudanças são enviadas para o repositório, o servidor de integração
contínua detecta as mudanças que ocorreram e recupera a última revisão do código-
fonte do repositório e executa o processo de construção do projeto4
. [6]
Finalmente, o servidor de integração contínua gera um feedback sobre o status
da construção do projeto enviando um e-mail com o resultado para os membros
do projeto. Após esse procedimento, o ciclo se reinicia e o servidor volta a enviar
requisições para descobrir novas mudanças no repositório. [6]
Figura 4.5: Arquitetura de um projeto utilizando integração contínua
Fonte: http://www.devmedia.com.br
4.4.2 Integração Contínua no Probatio
Para implementar a integração contínua no Probatio foi necessário escolher um
sistema de controle de versão. A tecnologia escolhida para este ﬁm foi o Git5
junta-
mente com um repositório privado no GitHub6
.
4
Software build - https://en.wikipedia.org/wiki/Software_build
5
Git - https://git-scm.com
6
GitHub - https://github.com

Figura 4.6: Repositório do Probatio no GitHub
Além de um sistema de controle de versão, escolhemos uma ferramenta capaz
de executar a construção do projeto de uma forma automatizada. A ferramenta
escolhida neste caso foi o Gradle7
. Já o processo de integração contínua do projeto
foi implementado através da ferramenta Travis CI8
.
O Gradle nos permite executar todos os testes do projeto através de um comando.
Ele também possibilita a construção do projeto, o chamado build, onde executamos
os passos necessários para gerar o artefato que compõe a aplicação no servidor.
7
Gradle Build Tool - https://gradle.org
8
Travis CI - https://travis-ci.org

4.5. CONCLUSÃO SOBRE O DESENVOLVIMENTO ÁGIL NO
PROBATIO 30
O Travis CI é uma ferramenta na web que nos possibilita a integração contínua.
Possui integração com o GitHub. Através dele, cada versão nova de código enviada
para o GitHub força que todos os testes do projeto sejam executados. Uma versão
correta do código tem o build do Travis dito verde, isso ocorre quando todos os testes
executam com sucesso. É uma versão pronta para entrar em ambiente de produção.
Caso algum teste falhe, o build é dito vermelho. Esta versão possui algum erro que
o teste capturou. Indica que precisamos fazer correções no código antes de ir para
o ambiente de produção.
4.5 Conclusão sobre o Desenvolvimento Ágil no Probatio
Como vimos nas seções anteriores, através da utilização do desenvolvimento ágil
no Probatio foi possível construir um software funcionando em um período relativa-
mente curto de tempo e com uma quantidade limitada de desenvolvedores e recursos
ﬁnanceiros. A primeira versão do sistema foi colocada em produção após aproxima-
damente seis meses de desenvolvimento. Isso permitiu a prática do desenvolvimento
iterativo e a colheita do feedback constante sobre o sistema.
Utilizando-se a ideia de mínimo produto viável foi possível construir uma fer-
ramenta que fosse realmente útil para os professores, uma vez que as hipóteses do
projeto foram validadas em cada etapa do desenvolvimento do sistema. Dessa forma,
foi possível evitar o desperdício de tempo e de recursos dos integrantes do projeto e
dos orientadores. Não houve tempo desperdiçado construindo um produto que não
fosse interessante para os usuários.
A prática do desenvolvimento guiado por testes permitiu a construção de um
sistema com qualidade. O conceito de qualidade utilizado no Probatio refere-se ao
fato do sistema garantir que um determinado defeito, erro ou falha não irá se repetir
pois há um teste para impedir isso.

4.5. CONCLUSÃO SOBRE O DESENVOLVIMENTO ÁGIL NO
PROBATIO 31
Por último, temos que a integração contínua foi uma prática fundamental para
garantir que todos os membros do projeto pudessem contribuir sem que novos de-
feitos, erros ou falhas fossem incluídos no sistema. Uma nova versão do sistema
funcionando era sempre gerada a partir de cada uma das contribuições dos seus
integrantes.

Capítulo 5
Sistemas de Recomendação
5.1 Introdução aos Sistemas de Recomendação
A maioria dos usuários da Internet1
já se deparou com algum sistema de re-
comendação de alguma forma. Um exemplo clássico são os sites de venda como
a Amazon2
. Basta fazermos uma busca por algum livro e selecioná-lo na lista de
resultados que iremos para uma página onde será exibido uma seção com a des-
crição “clientes que compraram este livro também compraram” contendo uma lista
de sugestões de livros. O software responsável por gerar esta lista de sugestões é
conhecido como sistema de recomendação [2].
O exemplo da loja virtual de livros nos ajuda a entender um pouco mais alguns
aspectos relacionados aos sistemas de recomendação. O primeiro deles está relaci-
onado com a personalização da recomendação. Cada visitante do site irá receber
uma lista de recomendações diferente baseado em suas preferências.
No entanto, é importante notar que existem sistemas de recomendação não per-
sonalizados. Este tipo de recomendação é, em geral, mais fácil de se obter e são
baseadas em dados estatísticos [4]. Como exemplos deste tipo de recomendação
podemos citar: os livros mais vendidos, os CDs mais populares etc.
1
Internet - https://pt.wikipedia.org/wiki/Internet
2
Amazon - https://www.amazon.com

5.1. INTRODUÇÃO AOS SISTEMAS DE RECOMENDAÇÃO 33
Figura 5.1: Recomendações da Amazon
Fonte: http://www.amazon.com.br
Para que sejam geradas recomendações personalizadas é necessário mantermos
algumas informações sobre o usuário que está utilizando o sistema. Por isso, todo
sistema de recomendação mantém um perfil de usuário que contém, por exemplo,
as preferências de um determinado usuário [2]. No nosso exemplo da livraria virtual,
o sistema poderia manter informações sobre os livros que o usuário já visualizou ou
comprou no passado para prever novos livros que seriam de seu interesse.
Figura 5.2: Perfil de Usuário
Fonte: https://dzone.com/articles/recommendation-engine-models
Cada sistema de recomendação constrói um perfil de usuário de uma forma di-
ferente. As informações podem ser obtidas de forma implícita, monitorando cada
ação do usuário, ou explícita, perguntando-o sobre suas preferências [2].

Um outro aspecto interessante é relativo às informações adicionais utilizadas
para gerar recomendações. Além de informações especíﬁcas de cada usuário, podem
ser utilizados dados e preferências de uma comunidade composta por outros usuários
do mesmo sistema. Sistemas desse tipo são conhecidos como baseado em comunidade
ou sistemas colaborativos [2].
5.1.1 Conceitos Básicos
5.1.1.1 Recomendação Colaborativa
A principal premissa deste tipo de recomendação é que usuários que concordaram
no passado (se eles visualizaram ou compraram os mesmos livros, por exemplo)
continuarão a concordar no futuro. [2]
Podemos ilustrar este conceito com o seguinte cenário: imagine que temos dois
usuários A e B que possuem um histórico de compras de livros muito semelhante. Em
um determinado momento, o usuário A compra um livro que o usuário B ainda não
visualizou. Então, baseado na recomendação colaborativa, muito provavelmente
o usuário B também gostaria de comprar este mesmo livro.
Figura 5.3: Recomendação Colaborativa
Fonte: http://dzone.com/articles/recommendation-engine-models
Sistemas deste tipo não precisam armazenar dados sobre os itens que estão sendo
recomendados. No nosso exemplo da livraria, o sistema não precisaria guardar
nenhum dado sobre cada livro, como autor ou gênero. É necessário apenas armazenar
quais livros foram comprados por cada usuário.

5.1.1.2 Recomendação baseada em Conteúdo
Um segundo tipo de sistema de recomendação são os sistemas de recomendação
baseados em conteúdo. A ideia deste tipo de sistema de recomendação é sugerir
itens similares aos que o usuário avaliou como positivo no passado [4].
Como exemplo, podemos imaginar um usuário que avaliou como positivo um
ﬁlme do gênero de comédia, então o sistema pode recomendar outros ﬁlmes desse
gênero para esse mesmo usuário.
Figura 5.4: Recomendação baseada em Conteúdo
Fonte: http://dzone.com/articles/recommendation-engine-models
Comparando este tipo de sistema com o anterior, podemos observar duas van-
tagens. A primeira delas é com relação a quantidade de usuários que utilizam o
sistema: com apenas um único usuário já podemos iniciar o processo de recomenda-
ção. Em sistemas colaborativos é necessário que exista uma comunidade utilizando
o sistema para iniciar o processo de recomendação. Este aspecto é conhecido como
cold start nos sistemas colaborativos. A segunda vantagem é que novos itens podem
ser recomendados assim que suas características estejam disponíveis no sistema, ao
passo que na recomendação colaborativa é necessário que algum usuário avalie estes
novos itens para que a recomendação seja possível. [2]
5.1.1.3 Recomendação baseada em Conhecimento
Existem alguns contextos onde o usuário precisa realizar uma escolha apenas
uma única vez, como a compra de eletrônicos. Nesse domínio, não podemos contar
com um histórico de escolhas do usuário, o que inviabiliza os métodos anteriores [2].

No entanto, um conteúdo mais detalhado sobre os itens a serem recomendados pode
estar disponível, incluindo especificações técnicas.
Para ilustrar melhor este cenário podemos imaginar um sistema de recomen-
dação para auxiliar o processo de compra de uma câmera digital. Em geral, os
usuários compram câmeras apenas uma vez dentro de vários anos. Portanto, um
sistema de recomendação não pode construir um perfil de usuário baseado no histó-
rico de compras ou propor câmeras que outros usuários avaliaram como positivo. Se
isso ocorresse, o sistema acabaria apenas recomendando as câmeras mais vendidas,
perdendo o aspecto essencial de personalização da recomendação [2].
Para contornar esse problema é necessário que o sistema de recomendação ex-
plore um conhecimento adicional para gerar recomendações. Este tipo de sistema
é conhecido como baseado em conhecimento. Sistemas desse tipo utilizam in-
fomações adicionais, geralmente fornecida de forma manual, sobre o usuário e os
itens a serem recomendados. Sistemas baseados em restrições são um exemplo desse
tipo de sistema. No domínio de câmeras digitais, um sistema baseado em restrições
poderia utilizar informações detalhadas sobre as câmeras, como resolução, peso ou
preço. [2]
No entanto, apenas apresentar os itens que satisfaçam as condições das restri-
ções não é o suficiente, uma vez que o aspecto da personalização estaria faltando.
Portanto, um sistema baseado em conhecimento também precisa de um perfil de
usuário. No exemplo da loja de câmeras digitais, o sistema poderia perguntar
para o usuário a relevância das características da câmera, como “resolução é mais
importante que peso” por exemplo.

5.2. ESTUDO DE CASO: CADMUS 37
5.2 Estudo de Caso: Cadmus
Vamos analisar uma aplicação de sistemas de recomendação que possui um ob-
jetivo semelhante ao do Probatio, facilitar o trabalho de um professor no momento
de selecionar questões de um banco compartilhado para elaborar uma avaliação.
O Cadmus [5] é um sistema de recomendação híbrido que utiliza técnicas de re-
comendação baseada em conhecimento e conteúdo além de colher feedback implícito
e explícito do usuário para aprimorar suas recomendações.
Como cada técnica de recomendação possui vantagens e desvantagens, este sis-
tema optou por combinar mais de uma técnica para obter melhores resultados. [5]
Existem várias técnicas de hibridização de sistemas de recomendação como: Swit-
ching (o sistema alterna entre diversas técnicas dependendo da situação), Cascade
(o sistema utiliza uma técnica para gerar uma recomendação e uma segunda técnica
para quebrar “empates”) e Feature Augmentation (o sistema utiliza uma técnica para
gerar uma saída, que por sua vez é utilizada como entrada para um segundo sistema
de recomendação). O Cadmus optou por utilizar uma técnica de recomendação
híbrida do tipo Feature Augmentation. [5]

5.2.1 Arquitetura
A arquitetura do Cadmus é composta por dois níveis, onde o primeiro nível é
composto por um ﬁltro baseado em conteúdo e o segundo nível é composto por
um ﬁltro baseado em conhecimento. O sistema baseado em conteúdo irá reduzir a
busca em questões com conteúdo pertinente às necessidades do professor, e o sistema
baseado em conhecimento irá ordenar essas questões de acordo com as preferências
do professor.
Figura 5.5: Arquitetura do Sistema Cadmus
Fonte: Exam Question Recommender System [5]

5.2.2 Perfil de Usuário
O perfil de usuário armazena informações e dados sobre o professor. Essas in-
formações alimentam o filtro baseado em conhecimento. O perfil de usuário contém
o seguinte:
• Login: um identificador único do usuário
• Peso do Tipo: peso da opção tipo de questão que é informado pelo usuário
• Peso da Ocorrência: peso da opção ocorrência
• Peso da Dificuldade: peso da opção dificuldade
• Peso do Autor: peso da opção autor
• Peso de cada Tipo Individual: peso calculado pelo sistema para cada um
dos tipos de questão (ex.: peso para questão de verdadeiro/falso, para múltipla
escolha...)
• Peso de cada Ocorrência Individual: peso calculado pelo sistema para
cada um dos tipos de ocorrência de questão (ex.: peso para questão muito
utilizada, para questão pouco utilizada...)
• Peso de cada Dificuldade Individual: peso calculado pelo sistema para
cada dificuldade (ex.: peso para questões fáceis, questões difíceis...)
• Peso de cada Autor Individual: peso calculado pelo sistema para cada
autor individualmente
Os pesos especificados pelo professor como Tipo, Ocorrência, Dificuldade
e Autor são informados manualmente. Esses pesos representam a preferência do
professor indicando qual das quatros características é mais importante para ele. O
professor pode escolher um entre os cincos valores disponíveis (Tabela 5.1) que será
utilizado na função de distância explicada na seção 5.2.4.

É importante destacar que a deﬁnição desses pesos é feita para cada consulta
que o professor desejar realizar, o que torna o processo de montagem de prova
relativamente demorado. A ﬁgura 5.6 ilustra o processo de busca de questões no
sistema Cadmus.
Figura 5.6: Busca de Questões do Sistema Cadmus
Fonte: Exam Question Recommender System [5]
Os pesos calculados pelo sistema inferem a preferência do professor em relação
a cada uma das características. Por exemplo, a característica Tipo pode ser um dos
seguintes valores: Verdadeiro/Falso ou Múltipla Escolha. Logo, o sistema irá calcu-
lar um peso para o valor de Verdadeiro/Falso e outro peso para o valor de Múltipla
Escolha. Esse peso é calculado baseado no histórico de escolhas do professor, de
forma que cada peso representa a proporção de cada tipo de questão escolhida no
passado.
Tabela 5.1: Valores dos Pesos
Peso Muito baixa Baixa Normal Alta Muito alta
Valor 0.25 0.5 1 2 4

5.2.3 Filtro baseado em Conteúdo
No momento de criar uma nova avaliação, o professor deve especificar os critérios
para selecionar as questões como ilustrado na Figura 5.6. Esses critérios especifi-
cados são utilizados pelo filtro baseado em conteúdo. Os possíveis critérios são:
Linguagem, Tópico, Assunto, a opção de incluir ou não questões que são publica-
mente visíveis para os alunos, Objetivo, Tipo, Peso do Tipo (usada pelo professor
para especificar o quão importante esse critério é em relação aos outros), Dificul-
dade, Peso da Dificuldade, Ocorrência, Peso da Ocorrência, Palavras-chaves, Autor
e Peso do Autor.
5.2.4 Filtro baseado em Conhecimento
O filtro baseado em conhecimento possui como entrada as questões candidatas
(obtidas através do filtro baseado em conteúdo) e o peso de cada critério especificado
pelo professor. O filtro baseado em conhecimento recupera o perfil do professor de
um repositório de perfis de usuário, e aplica a função de distância (Equação 5.1)
para calcular a distância entre cada questão candidata e as preferências do professor.
S =
i=n
i=1
Wi ∗ wi (5.1)
A função de distância é a soma do produto de dois pesos, W e w, onde W é o
peso especificado pelo professor para o critério em questão e w é o peso calculado
pelo sistema. A multiplicação por W irá reforçar ou subestimar o peso do critério.
A quantidade de pesos definidos pelo usuário no filtro é representada por n.
Vamos considerar um exemplo para ilustrar melhor a função de distância. No
filtro baseado em conteúdo (Figura 5.6), o professor definiu os campos da seguinte
forma: WTipo = Alto, WDificuldade = Baixo, WOcorrencia = Muito baixa e WAutor =
Muito alta. A Tabela 5.2 ilustra o valor de duas questões diferentes, e a Tabela 5.3
contém apenas uma parte do perfil do professor que é relevante para esse exemplo.

Tabela 5.2: Valores das Questões
Tipo Dificuldade Ocorrência Autor
Questão 1 (Q1) Verdadeiro/Falso Fácil Alta Brazchri
Questão 2 (Q2) Múltipla Escolha Fácil Baixa Brazchri
Tabela 5.3: Valores do Perfil do Professor
Critério Tipo Dificuldade Ocorrência Autor
Valor Verdadeiro/Falso Múltipla Escolha Fácil Alta Baixa Brazchri
Peso 0.33 0.11 0.5 0.06 0.54 0.15
Calculando a função de distância para as duas questões obtemos o seguinte:
s1 = (WTipo ∗ wV erdadeiro/Falso) + (WDificuldade ∗ wFacil) + (WOcorrencia ∗ wAlta)
+ (WAutor ∗ wBrazchri)
s2 = (WTipo ∗ wMultiplaEscolha) + (WDificuldade ∗ wFacil) + (WOcorrencia ∗ wBaixa)
+ (WAutor ∗ wBrazchri)
s1 = (2 ∗ 0.33) + (0.5 ∗ 0.5) + (0.25 ∗ 0.06) + (4 ∗ 0.15) = 1.525
s2 = (2 ∗ 0.11) + (0.5 ∗ 0.5) + (0.25 ∗ 0.54) + (4 ∗ 0.15) = 1.25
(5.2)
Como podemos ver, apesar de existir uma grande diferença entre os pesos de
Ocorrência em favor de Q2, Q1 irá obter um ranqueamento maior pois o professor
marcou o critério de Tipo como mais importante que o critério de Ocorrência.

5.3. RECOMENDAÇÃO NO PROBATIO 43
5.3 Recomendação no Probatio
Em geral, sistemas de recomendação possuem duas principais aplicações. A
primeira delas é estimular o usuário a fazer alguma escolha, como comprar um
livro específico ou assistir a algum determinado filme. Por outro lado, sistemas
de recomendação podem ser vistos como ferramentas para lidar com um problema
conhecido como information overload [1], uma vez que estes sistemas possuem
como objetivo selecionar os itens mais interessantes de um dado conjunto maior. [2]
Como o Probatio é um sistema para a elaboração de avaliações acadêmicas, o
processo de selecionar um conjunto de questões de um dado conjunto maior será
um problema recorrente para a maioria dos usuários deste sistema. Por isso, foi
implementado um sistema de recomendação que ajuda o professor na tarefa de
selecionar questões que mais se adequam ao seu perfil para elaborar suas provas.
5.3.1 Arquitetura
A arquitetura do Probatio foi baseada na arquitetura do Cadmus3
onde o sistema
de recomendação é composto por dois níveis, onde o primeiro nível é um sistema de
recomendação baseado em conteúdo e o segundo nível é um sistema de recomendação
baseado em conhecimento. Além disso, os dois níveis interagem utilizando a técnica
feature augmentation4
, da mesma forma que o Cadmus.
Figura 5.7: Recomendação no Probatio
3
Cadmus - Seção 5.2
4
Feature Augmentation - Seção 5.2

5.3.2 Perfil de Usuário
Diferente do Cadmus, o perfil de usuário do Probatio é extremamente simples.
Ele consiste em armazenar todas as provas e suas respectivas questões já utilizadas
pelo professor, conforme ilustra o modelo a seguir.
Figura 5.8: Modelo entidade relacionamento do Probatio
Dado um determinado usuário, é possível obter quais provas já foram emitidas
por este, assim como quais questões e tags foram utilizadas.
5.3.3 Tags
As tags que o Probatio utiliza são produto de um trabalho elaborado pelo aluno
Hugo Siqueira Gomes, que participou do projeto de iniciação científica do Proba-
tio. Este trabalho consistiu na extração de tags a partir das ementas relativas às
disciplinas do curso de Ciência da Computação da UFRJ.
Esse projeto processou as ementas para extrair os conjuntos de palavras relevan-
tes às disciplinas. Após o processamento automatizado temos um grande conjunto
de palavras candidatas a serem tags. Após o processamento automatizado ocorreu

um processamento manual onde foram verificadas as tags geradas e escolhidas as
que de fato faziam sentido para alimentar o banco do Probatio.
5.3.4 Filtro baseado em Conteúdo
O primeiro nível de recomendação do Probatio é um filtro baseado em conteúdo
que é responsável por gerar um conjunto de questões candidatas para a prova que
está sendo elaborada. Neste filtro é possível selecionar questões a partir das carac-
terísticas Disciplina e Tags.
Figura 5.9: Filtro baseado em Conteúdo do Probatio
5.3.5 Filtro baseado em Conhecimento
O segundo nível de recomendação do Probatio é um filtro baseado em conhe-
cimento que é responsável por receber as questões candidatas gerada pelo filtro
baseado em conteúdo, e ordenar essas questões segundo a sua relevância para o
usuário. Esta relevância será calculada a partir da comparação entre o conjunto de
tags de cada questão e o conjunto de tags que compõem o perfil de usuário.
As tags que compõem o perfil de usuário são facilmente obtidas, como é possível
ver no modelo da figura 5.8. A partir de um dado usuário é possível recuperar quan-
tas vezes este utilizou uma determinada tag no momento de elaborar suas provas.
Dessa forma, quanto mais uma tag foi utilizada por um determinado usuário, maior

será a relevância desta tag para este usuário. A seguir vamos ilustrar um exemplo
de como é calculada a pontuação de uma questão para um usuário.
Suponha o cenário onde um professor já havia montado uma prova no sistema.
As questões dessa prova são ilustradas na tabela 5.4.
Tabela 5.4: Questões de uma Prova
Tag1 Tag2 Tag3 Tag4 Tag5
Questão 1 1 1 1 0 0
Questão 2 1 0 0 0 1
Questão 3 1 0 1 0 1
Cada linha dessa tabela representa uma determinada questão e cada coluna da
tabela representa uma tag. Se uma questão possui uma determinada tag então o
valor 1 será preenchido na coluna correspondente à esta tag e 0 caso contrário.
A partir da tabela 5.4 podemos derivar o perﬁl do professor ilustrado na tabela
5.5. Esta nova tabela representa a relevância de cada tag para o professor.
Tabela 5.5: Perﬁl do Professor
Professor 1 3 1 2 0 2

Agora vamos supor que a partir de uma busca realizada pelo professor obtemos
as questões 4, 5 e 6 da tabela 5.6 como o conjunto de questões candidatas para a
prova. Estas questões são inéditas para o professor e ainda não foram utilizadas em
nenhuma de suas provas.
Tabela 5.6: Resultado da consulta
Questão 4 1 1 1 0 0
Questão 5 0 0 0 1 1
Questão 6 0 0 1 1 1
Para calcularmos a pontuação de uma determinada questão basta aplicarmos a
fórmula 5.3 ilustrada a seguir.
Pontuacao(Questaoi) =
j=n
j=1
Tagj(Questaoi) ∗ Freq(Tagj) (5.3)
A fórmula 5.3 nos dá a pontuação de uma dada questão onde Freq(Tagj) repre-
senta a frequência de uso da Tagj por um professor em suas provas. Tagj(Questaoi)
é 1 se a Questaoi possui a Tagj e 0 se ela não possui. A quantidade de tags no
sistema é representada por n.

5.4. COMPARAÇÃO ENTRE O PROBATIO E O CADMUS 48
Aplicando a fórmula 5.3 para este professor obtemos:
sn = 3 ∗ Tag1(Questaon) + 1 ∗ Tag2(Questaon) + 2 ∗ Tag3(Questaon)+
0 ∗ Tag4(Questaon) + 2 ∗ Tag5(Questaon)
s4 = 3 ∗ 1 + 1 ∗ 1 + 2 ∗ 1 + 0 ∗ 0 + 2 ∗ 0 = 6
s5 = 3 ∗ 0 + 1 ∗ 0 + 2 ∗ 0 + 0 ∗ 1 + 2 ∗ 1 = 2
s6 = 3 ∗ 0 + 1 ∗ 0 + 2 ∗ 1 + 0 ∗ 1 + 2 ∗ 1 = 5
A tabela 5.7 ilustra a pontuação de cada uma das questões do exemplo.
Tabela 5.7: Resultado da ordenação
Pontuação
Questão 4 6
Questão 5 2
Questão 6 4
5.4 Comparação entre o Probatio e o Cadmus
Após o desenvolvimento do Probatio e o seu sistema de recomendação, fizemos
uma breve comparação com o sistema Cadmus a fim de constatar quais eram as suas
principais diferenças. Como foi ilustrado nas seções anteriores, podemos verificar que
o Probatio possui uma interface com poucos campos de busca, sendo possível montar
uma prova com poucos cliques. Basta filtrar as questões por disciplina ou tags que
iremos obter um conjunto personalizado de questões para elaborar uma prova.

5.4. COMPARAÇÃO ENTRE O PROBATIO E O CADMUS 49
Por outro lado, no sistema Cadmus, o processo de elaboração de provas é cansa-
tivo e repetitivo. Isso acontece porque além de especificar quais são os critérios de
busca para as questões, deve-se também definir um peso para cada um dos critérios
utilizados. Dessa forma, o usuário precisa preencher mais de oito campos, incluindo
a definição dos pesos. Com isso, o processo de elaboração de provas a longo prazo
fica prejudicado, principalmente quando o usuário precisa elaborar mais de uma
prova em um pequeno espaço de tempo.
Podemos concluir então que o Probatio possui uma pequena vantagem em relação
ao Cadmus no quesito de elaboração de provas. Além de possuir um sistema de
recomendação que funciona de forma similar ao do Cadmus, o Probatio possui uma
interface simples e enxuta, o que favorece a sua usabilidade.

Capítulo 6
Resultados e Conclusão
6.1 Resultados
No final do desenvolvimento da versão do Probatio apresentada neste texto, re-
alizamos uma nova entrevista com quatro docentes do Departamento de Ciência da
Computação da UFRJ. A ideia da realização desta nova entrevista foi colher feed-
back1
sobre o trabalho realizado até o momento. As perguntas da segunda entrevista
se encontram na tabela A.2. Além das perguntas disponíveis no questionário, foi
concedido um espaço para que os professores fizessem sugestões para a melhoria do
sistema.
Sobre a utilização da linguagem LaTeX2
, todos os quatros docentes entrevis-
tados utilizam ou já utilizaram essa linguagem para a elaboração de suas provas.
Além da utilização do LaTeX, dois docentes entrevistados afirmaram que utilizam
a classe exam3
, a mesma classe utilizada pelo Probatio para a geração de provas
em LaTeX. Os demais docentes que ainda não utilizavam a classe exam sentiram
falta de instruções no sistema sobre como utilizá-la. Além disso, dois dos quatros
docentes também afirmaram utilizar a plataforma ShareLaTeX4
para a elaboração
de material didático, incluindo a elaboração de listas de exercícios e avaliações.
1
Feedback - Seção 4.1.1
2
LaTeX - https://www.latex-project.org/
3
Exam - https://www.ctan.org/pkg/exam
4
ShareLaTeX - https://pt.sharelatex.com/

6.1. RESULTADOS 51
Com relação a funcionalidade de inserir questões no banco de dados do Probatio,
foi sugerido uma espécie de pré-visualização da questão. A ideia seria que o usuário
tivesse certeza da questão gerada e, somente após visualiza-la, confirmasse sua inser-
ção. Também foi proposto que fosse implementado uma geração de relatório de erros
caso aconteça algum erro de compilação. Além disso, foi sugerido a possibilidade da
inclusão de questões com figuras.
A funcionalidade de consultar questões também recebeu algumas sugestões. Foi
afirmado que seria positivo a possibilidade de editar uma questão antes de utilizá-la
na prova. A intenção é que fosse possível alterar apenas alguns detalhes da questão,
com a opção de salvar estas alterações como uma nova versão da questão no banco.
Com relação aos critérios utilizados para filtrar questões, a maioria dos docentes
afirmou que utiliza critérios como assunto, dificuldade, habilidade envolvida (como
executar um determinado algoritmo ou criar um novo algoritmo, por exemplo) e
formato da questão (múltipla escolha ou discursiva, por exemplo).
Como sugestões adicionais temos a possibilidade de salvar a solução das questões
no momento de inseri-las. Além disso, foi mencionado a possibilidade de geração do
gabarito da prova no momento em que esta fosse emitida. Por último, a implemen-
tação de uma espécie de área pessoal, onde o docente pudesse salvar suas questões
de forma privada também foi uma ideia proposta.

6.2. CONCLUSÃO 52
6.2 Conclusão
Enxergamos o Probatio como uma ferramenta inovadora para o processo de cri-
ação de provas. Os resultados obtidos nos mostram que os professores gostaram da
ideia do nosso sistema. O sistema se mostrou uma solução ousada que auxilia o
professor a montar uma avaliação de forma rápida e simples.
Como facilitador, vimos que o Probatio se mostrou bom em resolver o problema
do information overload, pois limita a quantidade de resultados exibidos de forma a
se adaptar bem ao perfil de usuário.
Através da recomendação de questões que o professor ainda não conhece e poderá
gostar, o Probatio melhora a criação de avaliações, pois permite a diversificação do
conteúdo da prova.
6.2.1 Dificuldades
Durante o desenvolvimento do Probatio surgiram inúmeras dificuldades. Ini-
cialmente, foi necessário o aprendizado do framework Vaadin5
que possibilitou a
implementação de um sistema Web na linguagem de programação Java. Também
foi necessário o aprendizado de um SGBD6
para o armazenamento de dados do sis-
tema, além da utilização uma biblioteca como o Hibernate7
para fazer a comunicação
entre as duas partes.
Além do desenvolvimento em si, foi necessário um estudo sobre as tecnologias
relacionadas com a infraestrutura de uma aplicação Web. Para isso, realizamos
um estudo de tecnologias de computação em nuvem8
como a Amazon AWS9
e o
DigitalOcean10
.
5
Vaadin - https://vaadin.com/
6
SGBD - http://pt.wikipedia.org/wiki/SGBD
7
Hibernate - http://hibernate.org/
8
Computação em nuvem - https://en.wikipedia.org/wiki/Cloud_computing
9
Amazon AWS - https://aws.amazon.com/
10
Digital Ocean - https://www.digitalocean.com/

6.2. CONCLUSÃO 53
Uma terceira diﬁculdade foi conseguir popular o banco de dados com questões de
provas no formato LaTeX. Até o momento conseguimos obter questões da disciplina
Computação I que são lecionadas para as turmas do curso de BCMT11
da UFRJ.
Finalmente, como o sistema de recomendação implementado no Probatio utiliza
tags12
, foi necessário a obtenção de diversas tags relacionadas às questões das disci-
plinas do curso de Ciência da Computação da UFRJ. Para isso, foi feito um trabalho
de processamento de linguagem natural13
pelo aluno Hugo Siqueira Gomes onde foi
extraído diversas tags a partir da ementa das disciplinas do curso.
6.2.2 Trabalhos Futuros
Como trabalhos futuros, gostaríamos de aprimorar o sistema de recomendação
que foi implementado no Probatio para contornar os problemas conhecidos deste
tipo de sistema.
O primeiro deles é o cold start14
. Para contornar este problema, gostaríamos de
implementar um de questionário com os possíveis critérios que o professor utilizaria.
Também pediríamos para o professor avaliar algumas questões assim que entrasse no
sistema pela primeira vez. Poderíamos, assim, recomendar questões desde o primeiro
acesso.
Um segundo problema recorrente nos sistemas de recomendação baseado em
conteúdo é um problema conhecido como super especialização15
. Para contornar este
problema gostaríamos de implementar a utilização da Taxonomia de Bloom16
. Desta
forma, será possível generalizar a recomendação de questões e prever o interesse do
usuário em novas questões que possuam características diferentes daquelas que o
usuário já utiliza no momento.
11
BCMT - http://niteroi.dcc.ufrj.br/
12
Tag - https://en.wikipedia.org/wiki/Tag_(metadata)
13
NLP - https://en.wikipedia.org/wiki/Natural_language_processing
14
Recomendação baseada em Conteúdo - Seção 5.1.1.2
15
Super especialização - http://recommender-systems.org/content-based-filtering/
16
Taxonomia de Bloom - Seção 3.1

6.2. CONCLUSÃO 54
Também pretendemos criar um cadastro de disciplinas para facilitar sua inserção
em nosso banco de dados. Este cadastro seria sujeito a uma avaliação para que
se mantivesse a coerência em nossos dados. Além disso, um cadastro de tags é
necessário para que consigamos inserir novas tags.
A classiﬁcação de uma nova questão para lhe atribuir tags, segundo os verbos
da taxonomia de Bloom, como foi mencionado na seção 3.1, ﬁcou como um dos
trabalhos futuros propostos para este sistema.

Referências
[1] Christopher C. Yang, Hsinchun Chen, K. H. Visualization of large
category map for internet browsing. Decision Support Systems (2003).
[2] Dietmar Jannach, Markus Zanker, A. F. G. F. Recommender Systems:
An Introduction. Cambridge University Press, 2010.
[3] do Carmo Marcheti Ferraz; Renato Vairo Belhot, A. P. Taxonomia
de bloom: revisão teórica e apresentação das adequações do instrumento para
deﬁnição de objetivos instrucionais. Gest. Prod. 17, 2 (2010), 421–431.
[4] Francesco Ricci, Lior Rokach, B. S. P. B. K. Recommender Systems
Handbook. Springer, 2013.
[5] Hicham HAGE, E. A. Exam question recommender system. Proceedings of
the 2005 conference on Artiﬁcial Intelligence in Education: Supporting Learning
through Intelligent and Socially Informed Technology (2005), 249–257.
[6] Paul Duvall, Steve Matyas, A. G. Continuous Integration: Improving
Software Quality and Reducing Risk. Addison-Wesley Professional, 2007.
[7] Ries, E. The Lean Startup. Crown Business, 2011.
[8] Teles, V. M. Extreme Programming. Novatec, 2004.
[9] http://agilemanifesto.org/principles.html. Principles behind the agile
manifesto, 2001.
[10] http://www.desenvolvimentoagil.com.br. Um guia open source sobre de-
senvolvimento Ágil, 2014.

REFERÊNCIAS 56
[11] http://www.nixo-soft.de/tutorials/jlr/JLRTutorial.html. Java latex
report – tutorial, 2010.

Apêndice A
Perguntas das Entrevistas

58
Tabela A.1: Questionário base da entrevista I
1) Como você elabora as suas provas? Costuma ter um padrão?
2) Você monta a sua prova pensando na ementa do curso?
3) De onde vêm as questões da sua prova? Autoria própria, Internet, questões de
listas antigas, questões de outros professores?
4) Você possui temas específicos do conteúdo que considera importante de ser abor-
dado em cada prova?
5) Você baseia sua prova com temas relativos ao curso levantadas por alunos em
sala de aula?
6) Como você avalia o objetivo de cada questão?
7) Qual o formato de suas questões? Múltipla escolha, dissertativa, verdadeiro ou
falso?
8) Você pensa na dificuldade de correção de uma questão na hora de fazê-la?
9) As questões são pensadas levando em consideração a duração da prova?
10) Você monta a P1, P2 e PF de formas diferentes? O grau de dificuldade aumenta,
diminui ou permanece o mesmo?
11) Você distribui as questões em fácil, médio e difícil?
12) Depois de escolhidas as questões da prova, como você as organiza na mesma?
Existe algum tipo de ordenação? Da mais fácil para a mais difícil, o inverso ou não
aplica ordenação?
13) Como você distribui a pontuação da prova? Tem a ver com a dificuldade das
questões?
14) Quando uma questão tem um alto índice de erro você a repete ou coloca algo
parecido numa próxima prova ou não coloca mais questões sobre aquele assunto?
15) Você usaria um sistema de recomendação de questões para formular uma prova?
16) O que você considera importante nesse sistema?

59
Tabela A.2: Questionário da entrevista II
1) Quais matérias você ministra geralmente?
2) Você utiliza ou já utilizou algum sistema para elaborar provas?
3) Caso positivo, qual sistema?
4) Qual é a sua opinião sobre o Probatio? (Gostei muito, gostei, indiferente, não
gostei)
5) O que você menos gostou do Probatio?
6) O que você mais gostou do Probatio?
7) Se você pudesse modiﬁcar/adicionar alguma coisa no Probatio, o que seria?
8) Se você tivesse disponível um banco com centenas ou milhares de questões sobre
a sua disciplina, que critérios gostaria de ter disponível para ﬁltrar as questões na
hora de escolher um conjunto de questões candidatas para montar uma prova?

Probatio

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Probatio

Semelhante a Probatio (20)

Probatio